On Tue, May 10, 2022 at 06:27:41PM +0100, Matthew Wilcox wrote: > On Tue, May 10, 2022 at 08:50:47AM -0700, Kees Cook wrote: > > On Tue, May 10, 2022 at 12:27:53AM -0700, Christoph Hellwig wrote: > > > On Mon, May 09, 2022 at 03:23:33PM -0700, Kees Cook wrote: > > > > The randstruct GCC plugin gets upset when it sees struct addresspace > > > > (which is randomized) being assigned to a struct page (which is not > > > > randomized): > > > > > > Well, the right fix here is to remove this abuse from the driver, not > > > to legitimize it as part of a "driver" patch touching a core mm header > > > > Right, I didn't expect anyone to like the new "overloaded" member. > > Mainly I'd just like to understand how niu _should_ be fixed. Is using > > the "private" member the correct thing here? > > Well ... no. We're not entirely set up yet to go to the good answer > that means we don't have to touch this driver again, and yet we're also > in a situation where we'll need to touch this driver at some point in > order to get rid of the way it abuses struct page before we can get to > our good place. > > The eventual good answer is that we declare a driver-private memdesc > variant that has a ->link, ->base ->refcount and ->pfn (maybe it has more > than that; I'd have to really understand this driver to be completely > certain about what it needs). Or perhaps there's a better way to handle > driver-allocated memory for this kind of networking card that this driver > should be converted to use. > > I haven't looked into this case deeply enough to have strong thoughts > about how we should handle it, both now and in the glorious future. Okay, in the meantime, I'll just add a casting wrapper with a big comment to explain what I understand about it with some pointers back to this and prior threads. :) Thanks! -- Kees Cook
