netdev - Re: [PATCH net-next] net: enc28j60: Use threaded interrupt instead of workqueue

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]

Date: Thu, 11 May 2023 08:36:46 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Jakub Kicinski <kuba@...nel.org>, Leon Romanovsky <leon@...nel.org>
Cc: Lukas Wunner <lukas@...ner.de>, "David S. Miller" <davem@...emloft.net>,
  Eric Dumazet <edumazet@...gle.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 Wed, 2023-05-10 at 19:05 -0700, Jakub Kicinski wrote:
> On Tue, 9 May 2023 16:56:13 +0300 Leon Romanovsky wrote:
> > > > 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?  
> > 
> > No, this rule always existed, just some of the maintainers didn't care
> > about it.
> > 
> > > 
> > > 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.  
> > 
> > Right, this is why maintainers use this notation when they apply
> > patches. In your case, you are submitter, patch is not applied yet
> > and all changes can be easily seen through lore web interface.
> > 
> > > 
> > > 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.:  
> > 
> > It doesn't make it correct.
> > Documentation/maintainer/modifying-patches.rst
> 
> TBH I'm not sure if this is the correct reading of this doc.
> I don't see any problem with Lukas using the common notation.
> It makes it quite obvious what he changed and the changes are
> not invasive enough to warrant a major rewrite of the commit msg.

My reading of such documentation is that (sub-)maintainers could be
(more frequently) called to this kind of editing, but such editing is
not restricted.

In this specific case I could not find quickly via lore references to
the originating patch, so I find the editing useful.

The rationale of the mentioned process documentation is avoiding - when
possible and sensible - unneeded back and forth: I think we could and
should accept the patch in its current form.

I'm leaving it on PW a little more, in case there are strong, different
opinions.

Cheers,

Paolo