linux-kernel - Re: [PATCH v2 1/6] serial: 8250: Store to lsr_save

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: <20220607103229.f4hniwkcyfwlgem2@pengutronix.de>
Date:   Tue, 7 Jun 2022 12:32:29 +0200
From:   Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Jonathan Corbet <corbet@....net>,
        Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        linux-serial <linux-serial@...r.kernel.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        "Matwey V. Kornilov" <matwey@....msu.ru>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/6] serial: 8250: Store to lsr_save_flags after lsr
 read

Hello,

On Tue, Jun 07, 2022 at 12:09:39PM +0200, Andy Shevchenko wrote:
> > > > > I believe you haven't preserved the authorship that way (since From
> > > > > line is different), but since you have done non-trivial changes and
> > > > > Uwe is okay with them, the straightforward tag chain would be (with
> > > > > your authorship implied):
> > > > > Co-developed-by: Uwe
> > > > > SoB: Uwe
> > > > > SoB: yours
> > > >
> > > > I don't care much, but IMHO the initial set of tags made sense to me.
> > >
> > > > It
> > > > has my S-o-b because the change is (somewhat) taken from me and it has
> > > > my ack because the modification looked good to me.
> > >
> > > According to
> > > https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by
> > > the SoB already implies that you developed that, but Ack if not. It
> > > also clarifies Co-developed-by for cases like this.

Reading that by the letter, it doesn't say you must not use Ack if there
is a S-o-b.

	If a person was not directly involved in the preparation or
	handling of a patch but wishes to signify and record their
	approval of it then they can ask to have an Acked-by: line added
	to the patch’s changelog.

It's "If" and not "Iff". Not sure if that is intended?!

> > That's unintuitive (and wrong) in my opinion.
> 
> I have the opposite opinion.
> 
> > For me, Acked-by is a
> > confirmation of the respective person, that the patch in question is ok.
> > If I take a hunk of a random reverted patch and add the S-o-b of the big
> > patch's author, can I really assume the original author "acks" the
> > result? I would expect that in most cases they don't. (And if they do,
> > there is no way to record it, because the usual way of adding an Ack is
> > blocked as there is already a S-o-b?)
> 
> It's very logical to me. If you allowed (by not NAKing) the other
> developer to use your SoB you imply Ack for every change they made.

So you assume that you notice each patch with your S-o-b in time to send
a NAK. I don't claim that for me and I would be surprised if a major
part of the kernel contributors did.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)