From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Snitzer Subject: Re: [PATCH 2/6] dm: introduce dm_accept_partial_bio Date: Mon, 17 Mar 2014 20:49:52 -0400 Message-ID: <20140318004951.GD4037@redhat.com> References: <20140317132740.GA7184@redhat.com> <20140317174324.GA2285@redhat.com> <20140317190907.GA3269@redhat.com> <20140317194701.GB3269@redhat.com> Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Mikulas Patocka Cc: dm-devel@redhat.com, Edward Thornber , "Alasdair G. Kergon" List-Id: dm-devel.ids On Mon, Mar 17 2014 at 6:45pm -0400, Mikulas Patocka wrote: > > > On Mon, 17 Mar 2014, Mike Snitzer wrote: > > > > > I do however want you to add yet another BUG_ON for any bio that isn't > > > > meant to be sent to this interface (only one so far is REQ_FLUSH AFAIK). > > > > > > Then, it triggers NULL pointer dereference. You don't have to add BUG_ON > > > for it, it crashes anyway. > > > > I understand it'll NULL pointer, but that is _always_ confusing for > > someone who wasn't the original developer. Please add the explicit > > BUG_ON() for REQ_FLUSH. > > The user will not hit a BUG with REQ_FLUSH. Regarding the developer - it > is expected that the kernel developer is able to decode the oops message, > compare it with disassembled code and find out which variable was NULL. > The function is small, so it's an easy task. By that logic then no BUG_ON() should ever be needed. You need to know to quit while you're ahead ;) > We don't really need > BUG_ON(!pointer); > variable = *pointer; Right, we don't.. but it helps resolve issues quicker if thoughtful BUG_ON()s hit before more obscure crashes do. Whereby obviating the need to reverse engineer _why_ the NULL pointer occurred.