From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Brown Date: Fri, 17 Sep 2010 03:18:53 +0000 Subject: Re: [PATCH] md: do not use ++ in rcu_dereference() argument Message-Id: <20100917131853.225f6fa1@notabene> List-Id: References: <1283711539-7123-1-git-send-email-segooon@gmail.com> <20100905190139.GA3163@merkur.ravnborg.org> <20100905192335.GA8140@albatros> <20100905203908.GA3228@merkur.ravnborg.org> <20100906152931.1d4a1d07@notabene> <4C921385.2080205@redhat.com> In-Reply-To: <4C921385.2080205@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Avi Kivity Cc: Sam Ravnborg , Kulikov Vasiliy , kernel-janitors@vger.kernel.org, Jens Axboe , linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org On Thu, 16 Sep 2010 14:54:29 +0200 Avi Kivity wrote: > On 09/06/2010 08:29 AM, Neil Brown wrote: > > I've taken the opportunity to substantially re-write that code. > > > > > > It's better to have two patches, one a backportable one liner that fixes > the bug, the other, on top, that cleans up the code but has no sematic > changes. > > This makes it substantially easier to review. When considering the > first patch you see the change plainly. When reviewing the second patch > you make sure no semantic changes were made at all. > Good advice, I agree. However the conversation seem have drifted towards viewing the new macro definition as the bug, and the pre-increment in an argument as a valid thing to do. In that case, there is no bug to fix, just a code clean up required. So I'm currently planning on just submitting that cleanup in the next merge window, and leaving the rcu guys to 'fix' the macro. Thanks, NeilBrown From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Brown Subject: Re: [PATCH] md: do not use ++ in rcu_dereference() argument Date: Fri, 17 Sep 2010 13:18:53 +1000 Message-ID: <20100917131853.225f6fa1@notabene> References: <1283711539-7123-1-git-send-email-segooon@gmail.com> <20100905190139.GA3163@merkur.ravnborg.org> <20100905192335.GA8140@albatros> <20100905203908.GA3228@merkur.ravnborg.org> <20100906152931.1d4a1d07@notabene> <4C921385.2080205@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4C921385.2080205@redhat.com> Sender: linux-kernel-owner@vger.kernel.org To: Avi Kivity Cc: Sam Ravnborg , Kulikov Vasiliy , kernel-janitors@vger.kernel.org, Jens Axboe , linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org List-Id: linux-raid.ids On Thu, 16 Sep 2010 14:54:29 +0200 Avi Kivity wrote: > On 09/06/2010 08:29 AM, Neil Brown wrote: > > I've taken the opportunity to substantially re-write that code. > > > > > > It's better to have two patches, one a backportable one liner that fixes > the bug, the other, on top, that cleans up the code but has no sematic > changes. > > This makes it substantially easier to review. When considering the > first patch you see the change plainly. When reviewing the second patch > you make sure no semantic changes were made at all. > Good advice, I agree. However the conversation seem have drifted towards viewing the new macro definition as the bug, and the pre-increment in an argument as a valid thing to do. In that case, there is no bug to fix, just a code clean up required. So I'm currently planning on just submitting that cleanup in the next merge window, and leaving the rcu guys to 'fix' the macro. Thanks, NeilBrown