linux-kernel - Re: [PATCH 5.14 298/334] time: Handle negative seconds correctly in timespec64_to

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:   Fri, 17 Sep 2021 21:29:32 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Arnd Bergmann <arnd@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "# 3.4.x" <stable@...r.kernel.org>,
        Lukas Hannen <lukas.hannen@...nsource.tttech-industrial.com>
Subject: Re: [PATCH 5.14 298/334] time: Handle negative seconds correctly in
 timespec64_to_ns()

Greg,

On Fri, Sep 17 2021 at 17:20, Greg Kroah-Hartman wrote:
> On Fri, Sep 17, 2021 at 12:38:43PM +0200, Thomas Gleixner wrote:
>> Nah. I try to pay more attention. I'm not against AUTOSEL per se, but
>> could we change the rules slightly?
>> 
>> Any change which is selected by AUTOSEL and lacks a Cc: stable@... is
>> put on hold until acked by the maintainer unless it is a prerequisite
>> for applying a stable tagged fix?
>> 
>> This can be default off and made effective on maintainer request.
>> 
>> Hmm?
>
> The whole point of the AUTOSEL patches are for the huge numbers of
> subsystems where maintainers and developers do not care about the stable
> trees at all, and so they do not mark patches to be backported.  So
> requireing an opt-in like this would defeat the purpose.
>
> We do allow the ability to take files/subsystems out of the AUTOSEL
> process as there are many maintainers that do do this right and get
> annoyed when patches are picked that they feel shouldn't have.  That's
> the best thing we can do for stuff like this.

I guess I was not able to express myself correctly. What I wanted to say
is:

  1) Default is AUTOSEL

  2) Maintainer can take files/subsystems out of AUTOSEL completely

     Exists today

  3) Maintainer allows AUTOSEL, but anything picked from files/subsystems
     without a stable tag requires an explicit ACK from the maintainer
     for the backport.

     Is new and I would be the first to opt-in :)

My rationale for #3 is that even when being careful about stable tags,
it happens that one is missing. Occasionaly AUTOSEL finds one of those
in my subsystems which I appreciate.

Does that make more sense now?

Thanks,

        tglx