On Thu, Jul 29, 2021 at 02:11:27PM +0200, Daniel Vetter wrote: > On Wed, Jul 28, 2021 at 07:56:40AM +0200, Greg Kroah-Hartman wrote: > > On Tue, Jul 27, 2021 at 01:58:16PM -0700, Kees Cook wrote: > > > In preparation for FORTIFY_SOURCE performing compile-time and run-time > > > field bounds checking for memcpy(), memmove(), and memset(), avoid > > > intentionally writing across neighboring fields. > > > > > > Use struct_group() in struct drm32_mga_init around members chipset, sgram, > > > maccess, fb_cpp, front_offset, front_pitch, back_offset, back_pitch, > > > depth_cpp, depth_offset, depth_pitch, texture_offset, and texture_size, > > > so they can be referenced together. This will allow memcpy() and sizeof() > > > to more easily reason about sizes, improve readability, and avoid future > > > warnings about writing beyond the end of chipset. > > > > > > "pahole" shows no size nor member offset changes to struct drm32_mga_init. > > > "objdump -d" shows no meaningful object code changes (i.e. only source > > > line number induced differences and optimizations). > > > > > > Note that since this includes a UAPI header, struct_group() has been > > > explicitly redefined local to the header. > > > [...] > > > > Why can you use __struct_group in this uapi header, but not the > > networking one? > > If there's others, maybe we can stuff the uapi __struct_group into > linux/types.h where all the other __ uapi types hang out? Ah yeah; it looks like include/uapi/linux/stddef.h is the place for it. > Anyway mga is very dead, I don't anyone cares. > > Acked-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > > I'm assuming this goes in through a topic pull from you? Thanks! Yeah, my intention is to carry this as topic branch for Linus. -Kees -- Kees Cook
