netdev - Re: [PATCH net] r8169: fix jumbo packet handling on resume from suspend

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20191012152845.6ff9430d@cakuba.netronome.com>
Date:   Sat, 12 Oct 2019 15:28:45 -0700
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Heiner Kallweit <hkallweit1@...il.com>
Cc:     David Miller <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Mariusz Bialonczyk <manio@...boo.net>
Subject: Re: [PATCH net] r8169: fix jumbo packet handling on resume from
 suspend

On Fri, 11 Oct 2019 08:03:24 +0200, Heiner Kallweit wrote:
> On 11.10.2019 01:36, Jakub Kicinski wrote:
> > On Wed, 9 Oct 2019 20:55:48 +0200, Heiner Kallweit wrote:  
> >> Mariusz reported that invalid packets are sent after resume from
> >> suspend if jumbo packets are active. It turned out that his BIOS
> >> resets chip settings to non-jumbo on resume. Most chip settings are
> >> re-initialized on resume from suspend by calling rtl_hw_start(),
> >> so let's add configuring jumbo to this function.
> >> There's nothing wrong with the commit marked as fixed, it's just
> >> the first one where the patch applies cleanly.
> >>
> >> Fixes: 7366016d2d4c ("r8169: read common register for PCI commit")
> >> Reported-by: Mariusz Bialonczyk <manio@...boo.net>
> >> Tested-by: Mariusz Bialonczyk <manio@...boo.net>
> >> Signed-off-by: Heiner Kallweit <hkallweit1@...il.com>  
> > 
> > Applied, somewhat begrudgingly - this really isn't the way the Fixes
> > tag should be used, but I appreciate it may be hard at this point to
> > pin down a commit to blame given how many generations of HW this driver
> > supports and how old it is.. perhaps I should have removed the tag in
> > this case, hm.
> > 
> > Since the selected commit came in 5.4 I'm not queuing for stable.
> >   
> The issue seems to have been there forever, but patch applies from a
> certain kernel version only. I agree that using the Fixes tag to provide
> this information is kind of a misuse. How would you prefer to get that
> information, add a comment below the commit message similar to the list
> of changes in a new version of a patch series?

I'd put the backport help under the --- lines, maybe additionally
mentioning its presence in the commit message (lore link would
complete the picture). Like we do for merges. 

Although I think Dave queues for stable immediately when patch is 
merged to net, so if the backport is to last release or two I think 
the info under --- could be as useful as in the commit message.

Another way would be posting the backported patch (say for the most
recent LTS) if the backport is hard and fix important 🤔