From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: scsi: BUG in scsi_init_io Date: Sun, 19 Feb 2017 09:25:41 -0800 Message-ID: <20170219172541.GA29867@infradead.org> References: <20170131092048.GB3687@linux-x5ow.site> <1485877311.3199.4.camel@linux.vnet.ibm.com> <20170219071522.GI29622@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20170219071522.GI29622@ZenIV.linux.org.uk> Sender: linux-kernel-owner@vger.kernel.org To: Al Viro Cc: James Bottomley , Dmitry Vyukov , Johannes Thumshirn , "Martin K. Petersen" , linux-scsi , LKML , syzkaller , Hannes Reinecke , Linus Torvalds List-Id: linux-scsi@vger.kernel.org On Sun, Feb 19, 2017 at 07:15:27AM +0000, Al Viro wrote: > The root cause is unfixable without access to TARDIS and dose of > antipsychotics sufficient to prevent /dev/sg API creation. > > What happens is that write to /dev/sg is given a request with non-zero > ->iovec_count combined with zero ->dxfer_len. Or with ->dxferp pointing > to an array full of empty iovecs. > > AFAICS, the minimal fix would be something like this: > > YAMissingSanityCheck in /dev/sg > > write permission to /dev/sg shouldn't be equivalent to the ability to trigger > BUG_ON() while holding spinlocks... Looks fine to me: Reviewed-by: Christoph Hellwig The other thing we really need to consider is to finally merge the SG_IO implementations for /dev/sg with the common block layer one.