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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAHp75VeoKxaEWB7F=d6ocZ563Oq+6yZGSPumUZJJ_V7rveXBGA@mail.gmail.com>
Date:   Tue, 7 Jun 2022 12:54:32 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>
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

On Tue, Jun 7, 2022 at 12:32 PM Uwe Kleine-König
<u.kleine-koenig@...gutronix.de> wrote:
> 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?!

Yes, it's a bit ambiguous, but I use common sense. Acking yourself
code seems awkward to me.

...

> > > 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.

Yes. That's why `git send-email` is always Cc'ing people whose SoB
tags in the patch.

The flaw that you may notice here is that anybody can potentially add
anybody's SoB to any garbage and send it to a mailing list. It has
non-zero chances to pass review (a person whose SoB has been abused on
a sick leave, for example). But this is more process and QA related.

-- 
With Best Regards,
Andy Shevchenko