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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230509133620.GA14772@wunner.de>
Date: Tue, 9 May 2023 15:36:20 +0200
From: Lukas Wunner <lukas@...ner.de>
To: Leon Romanovsky <leon@...nel.org>
Cc: "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	netdev@...r.kernel.org,
	Philipp Rosenberger <p.rosenberger@...bus.com>,
	Zhi Han <hanzhi09@...il.com>
Subject: Re: [PATCH net-next] net: enc28j60: Use threaded interrupt instead
 of workqueue

On Tue, May 09, 2023 at 11:06:27AM +0300, Leon Romanovsky wrote:
> On Tue, May 09, 2023 at 06:28:56AM +0200, Lukas Wunner wrote:
> > From: Philipp Rosenberger <p.rosenberger@...bus.com>
> > 
> > The Microchip ENC28J60 SPI Ethernet driver schedules a work item from
> > the interrupt handler because accesses to the SPI bus may sleep.
> > 
> > On PREEMPT_RT (which forces interrupt handling into threads) this
> > old-fashioned approach unnecessarily increases latency because an
> > interrupt results in first waking the interrupt thread, then scheduling
> > the work item.  So, a double indirection to handle an interrupt.
> > 
> > Avoid by converting the driver to modern threaded interrupt handling.
> > 
> > Signed-off-by: Philipp Rosenberger <p.rosenberger@...bus.com>
> > Signed-off-by: Zhi Han <hanzhi09@...il.com>
> > [lukas: rewrite commit message, linewrap request_threaded_irq() call]
> 
> This is part of changelog which doesn't belong to commit message. The
> examples which you can find in git log, for such format like you used,
> are usually reserved to maintainers when they apply the patch.

Is that a new rule?

Honestly I think it's important to mention changes applied to
someone else's patch, if only to let it be known who's to blame
for any mistakes.

I'm seeing plenty of recent precedent in the git history where
non-committers fixed up patches and made their changes known in
this way, e.g.:

commit 99669259f3361d759219811e670b7e0742668556
Author:     Maxime Bizon <mbizon@...ebox.fr>
AuthorDate: Thu Mar 16 16:33:16 2023 -0700
Commit:     David S. Miller <davem@...emloft.net>
CommitDate: Sun Mar 19 10:48:35 2023 +0000

    [florian: fix kdoc, added Fixes tag]
    Signed-off-by: Florian Fainelli <f.fainelli@...il.com>
    Signed-off-by: David S. Miller <davem@...emloft.net>

commit 0c9ef08a4d0fd6c5e6000597b506235d71a85a61
Author:     Nathan Huckleberry <nhuck@...gle.com>
AuthorDate: Tue Nov 8 17:26:30 2022 -0700
Commit:     Paolo Abeni <pabeni@...hat.com>
CommitDate: Thu Nov 10 12:28:30 2022 +0100

    [nathan: Rebase on net-next and resolve conflicts
             Add note about new clang warning]
    Signed-off-by: Nathan Chancellor <nathan@...nel.org>
    Signed-off-by: Paolo Abeni <pabeni@...hat.com>

commit 91e87045a5ef6f7003e9a2cb7dfa435b9b002dbe
Author:     Steffen BÀtz <steffen@...osonix.de>
AuthorDate: Fri Oct 28 13:31:58 2022 -0300
Commit:     Jakub Kicinski <kuba@...nel.org>
CommitDate: Mon Oct 31 20:00:20 2022 -0700

    [fabio: Improved commit log and extended it to mv88e6321_ops]
    Signed-off-by: Fabio Estevam <festevam@...x.de>
    Signed-off-by: Jakub Kicinski <kuba@...nel.org>

commit ebe73a284f4de8c5d401adeccd9b8fe3183b6e95
Author:     David Ahern <dsahern@...nel.org>
AuthorDate: Tue Jul 12 21:52:30 2022 +0100
Commit:     Jakub Kicinski <kuba@...nel.org>
CommitDate: Tue Jul 19 14:20:54 2022 -0700

    [pavel: move callback into msghdr]
    Signed-off-by: Pavel Begunkov <asml.silence@...il.com>
    Signed-off-by: Jakub Kicinski <kuba@...nel.org>

Thanks,

Lukas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ