There's a surprisingly long document at https://docs.kernel.org/process/submitting-patches.html
But basically make a git commit, make sure the commit message looks like other commit messages in the area (look at "git log drivers/gpu/drm/nouveau" for inspiration). Make sure your Signed-off-by is on there. Then git format-patch the commit, and use git send-email to send the resulting file to this mailing list + dri-devel (or any other method of causing the contents of that file to end up as the email that's sent rather than an attachment). Cheers, -ilia On Fri, Jan 21, 2022 at 12:07 AM Nick Lopez <[email protected]> wrote: > > If it’s correct I’d like to see it make its way upstream. I have no idea what > the submission procedure is. > > > > From: Ilia Mirkin > Sent: Thursday, January 20, 2022 11:24 AM > To: Nick Lopez > Cc: [email protected] > Subject: Re: [Nouveau] Off-by-one or bad BIOS image? Apple eMac 800 GeForce > 2MX > > > > This stuff is always so confusing. Let's think this through.... if > > bios size is 4, and we're trying to read a 4-byte thing starting at > > address 0, that _ought_ to work, I think. So in my strawman case, > > bios->size == 4, and size == 4. So we should only error if size > > > bios->size, not if they're ==. Looks like your patch is right. > > > > Want to make a linux kernel patch submission with this? (i.e. > > including changelog, signoff, etc?) > > > > Cheers, > > > > -ilia > > > > On Thu, Jan 20, 2022 at 1:17 PM Nick Lopez <[email protected]> wrote: > > > > > > Because I watch too much retro YouTube I decided it was a good idea to try > > installing Adelie Linux on my old G4/800 eMac, but the Live installer would > > freeze. By blacklisting nouveau I was able to get it booted and manually > > installed and, after hours and hours of compiling, get a working kernel > > tree to poke at. After only a few iterations with dump_stack() and > > nvkm_debug and the output of envytools/nvbios I worked out at the last > > initscript instruction was stored in the last byte of the ROM. I think the > > bounds check in the nvbios_addr() function is miscalculating the limit as > > one byte short, that’s why I was seeing this in the syslog: > > > > > > > > > > > > nouveau 0000:00:10.0: bios: OOB 1 000007b2 000007b2 > > > > > > nouveau 0000:00:10.0: devinit: 0x000007b2[ ]: unknown opcode 0x00 > > > > > > nouveau 0000:00:10.0: preinit failed with -22 > > > > > > nouveau: DRM-master:00000000:00000080: init failed with -22 > > > > > > nouveau 0000:00:10.0: DRM-master: Device allocation failed: -22 > > > > > > nouveau: probe of 0000:00:10.0 failed with error -22 > > > > > > > > > > > > After I changed the limit check from: > > > > > > if (unlikely(*addr + size >= bios->size)) { > > > > > > to: > > > > > > if (unlikely(*addr + size > bios->size)) { > > > > > > > > > > > > it initialized the card properly, brought up the fbconsole and even seems > > to be working in X with DRI. So the question is: was the bounds check > > wrong, or is the NVDA,BMP image provided by OpenFirmware truncated? I’m > > guess this doesn’t turn up elsewhere because the ROM images read through > > any of the other methods are the size of flash chip they’re stored on so > > there’s always unused space at the end and they never use the last byte > > where the NVDA,BMP provided by OpenFirmware is just the active section. > > > > > > > > > > > > The patch is against the Adelie easy-kernel patch 5.4 tree, but it looks > > like that code is still there in the current upstream torvalds/linux git. > >
