lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 29 Jul 2008 00:47:56 -0700 From: Andrew Morton <akpm@...ux-foundation.org> To: Alan Cox <alan@...rguk.ukuu.org.uk> Cc: linux-kernel@...r.kernel.org, Markus Lidel <Markus.Lidel@...dowconnect.com>, Vasily Averin <vvs@...ru> Subject: Re: [PATCH]: Proposed fix to the I2O problems with > 4GB space On Fri, 25 Jul 2008 13:16:37 +0100 Alan Cox <alan@...rguk.ukuu.org.uk> wrote: > From: Alan Cox <alan@...hat.com> > > The I2O ioctls assume 32bits. In itself that is fine as they are old cards > and nobody uses 64bit. However on LKML it was noted this assumption is also > made for some ioctl allocated memory and is unsafe on 64bit systems. > > Fixing this is a mess. It turns out there is tons of crap buried in a header > file that does racy 32/64bit filtering on the masks. > > So we: > - Verify all callers of the racy code can sleep (i2o_dma_[re]alloc) > - Move the code into a new i2o/memory.c file > - Remove the gfp_mask argument so nobody can try and misuse the function > - Wrap a mutex around the problem area (a single mutex is easy to do and > none of this is performance relevant) > - Switch the remaining problem kmalloc holdout to use i2o_dma_alloc > > There is a remaining race but that causes 32bit allocations to occur very > rarely during block I/O when 64bit could be used. I don't think that is worth > the cost of fixing as the impact is just a negligible performance loss. > > Signed-off-by: Alan Cox <alan@...hat.com> > I think you sent the wrong version of this patch - i2o_dma_alloc() is all mucked up. Sometimes takes three args, sometimes four. When it's four the fourth arg is sometimes a gfp_t, sometimes a PCI_DMA_foo. It fell afoul of the dma_mapping_error() interface change too. > (but could do with more testing, especially on 64bit > 4GB boxes with 64bit > capable I2O cards) A bit of git-trolling indicates that Vasily might be able to help out with a bit of testing? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists