Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932269AbdGJNvs (ORCPT ); Mon, 10 Jul 2017 09:51:48 -0400 Received: from mx2.suse.de ([195.135.220.15]:51734 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932079AbdGJNvr (ORCPT ); Mon, 10 Jul 2017 09:51:47 -0400 Date: Mon, 10 Jul 2017 15:51:44 +0200 From: Petr Mladek To: Pierre Kuo Cc: sergey.senozhatsky@gmail.com, rostedt@goodmis.org, linux-kernel@vger.kernel.org, joe@perches.com Subject: Re: [PATCH] printk: Modify operators of printed_len Message-ID: <20170710135144.GN23069@pathway.suse.cz> References: <1499482273-10638-1-git-send-email-vichy.kuo@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1499482273-10638-1-git-send-email-vichy.kuo@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1531 Lines: 40 On Sat 2017-07-08 10:51:13, Pierre Kuo wrote: > In 8b1742c9c207, we remove printk-recursion detection code in > vprintk_emit(), where it is the first place that printed_len calculated. > After removing above detection, it seems we can directly assign the > result of log_output to printed_len. > > Signed-off-by: Pierre Kuo Great catch! I just noticed that the same applies also to text_len variable. Well, it was caused by another commit ddb9baa822265b55 ("printk: report lost messages in printk safe/nmi contexts"). Could you please send a patch for this as well? I would personally fix both variables in a single patch. But I do not have a strong opinion about it. This seems to be your first patch sent to the kernel mailing list. Let me share some hints that might help you to handle more complex patchsets ;-) There is a standard format how to reference older commits. It is 'commit <12+ chars of sha1> ("")', see my comment above for an example. A good practice is to run ./scripts/checkpatch.pl <patch> before you send the patch. Well, you need to use a common sense and ignore false positives or hints that make a particular patch less readable in the end. Also it is handy to bump the version of the patch when it is updated, e.g. use [PATCH v2] in the subject. People also summarize changes against the previous version(s) below the --- line. Well, this is more useful when there is a longer delay between the versions and the changes are more complicated. Best Regards, Petr