Re: [PATCH] scsi: eata: drop VLA in reorder()

On Mon, 12 Mar 2018 14:08:34 +1100, "Tobin C. Harding" said: > removal patch that 768 was a lot of stack space. That comment did, > however say 'deep in some transfer call chain'. I don't know what a > 'transfer call chain' (the transfer bit) is but is there some heuristic > we can use to know h

UBSAN whinge in scsi_devinfo.c

Seen at boot in a UBSAN-enabled kernel: [2.936388] [2.936392] UBSAN: Undefined behaviour in drivers/scsi/scsi_devinfo.c:457:21 [2.936396] index 8 is out of range for type 'char [8]' The code: 452

Re: [PATCH] mvsas:Fix possible NULL pointer deference in mvs_dev_found_notify

On Wed, 09 Mar 2016 22:33:47 +0200, Dāvis Mosāns said: > About whether mvs_find_dev_mvi can return NULL it looks like it's possible, > but I'm not sure if it practically happens. I guess it did hence patch. Or the "bug" was found by incorrect code inspection. Nick has a history of submitting p

Re: What still uses the block layer?

On Mon, 15 Oct 2007 03:04:00 CDT, Rob Landley said: > I note that the eth0 and eth1 names are dynamically assigned on a first come > first serve basis (like scsi). This never causes me a problem because the > driver loading order is constant, and once you figure out that eth0 is > gigabit and eth1

Re: [PATCH 0/3] debloat aic7xxx and aic79xx drivers

On Fri, 31 Aug 2007 16:13:59 BST, Denys Vlasenko said: > >textdata bss dec hex filename > 261433 500181172 312623 4c52f > linux-2.6.23-rc1.org.t/drivers/scsi/aic7xxx/built-in.o > 199654 500181172 250844 3d3dc > linux-2.6.23-rc1.aic.t/drivers/scsi/aic7xxx/bu