Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp909924pxb; Sat, 18 Sep 2021 23:47:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxVoeHgDgryBZ75YbQMojllM2PTdSAi1cikZMXYX/ssZWbG3a1M0ybtYI/moE+fl27vFVKB X-Received: by 2002:a05:6638:2050:: with SMTP id t16mr14853493jaj.101.1632034043676; Sat, 18 Sep 2021 23:47:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632034043; cv=none; d=google.com; s=arc-20160816; b=c1j5oAJZxK4WaxoXBIc3kvr/Cl151muw5eZub2CHZlGf4eVIIYu2u/+OZFoeXVQlvl Q0pZd3f3NJ3HZIcKr44HD8Yc8qSpqBD2Apmf1tIOndo3CdfklkYnSVZh92hcjUiR6x5G 7kxu5+6QuXTJEnB6b+Kzn5qgHVJBBO0cUzoIFDeZHspf62OfAgaMsv5pSYPbhX6ndFig X3GTeEnVTPargn/nuttudro/Pv613IGJqKavfyuW4FDCmK4A4uooHcDwNMgUXLz5vm/V HRb+rzgPfBi5jQQGV30LyXaAX9tAVj1A5Ux0KG5IF14MJ16bqBJ9lQ6YnKasLsGmhuW4 7onw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=Imedf1r2gV/Z8969vGsBaF3EURqq1rqknXNWd0X8KVM=; b=gTVQNk7Dh5/GL9CLRSz4U1Pdf0Si4zIVamxTGg/DFmyYY/ovD8Th0QQl7z3Fg54C1A k56x7TdXQAW7D1XaZUg+/slt/xVE3DWHGwqRDhALUEnLud2XRjIiO1UIRoQccWRgQMOr Q97dVPrDVMG0KUa0rYXuqvlDdVhIlxlx7my8bfmqlE9nrdFcewa5+Ru53ouqrU5mewrz K6pCs8ncyg8u+BrLnnBC6xnpIumchN9dZF72PxmWDI/Bsjzhep2GEqSpKBBFrxlJoWiD W2ksMi6uybvDbVRV66hbEss4nSWlaN55aiKi/bupxOhRV92u8DnknzxNIOxa0V9bkac+ 0zxQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=1JKPdqVx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u3si9176454jae.21.2021.09.18.23.47.12; Sat, 18 Sep 2021 23:47:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=1JKPdqVx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239921AbhIRPsY (ORCPT + 99 others); Sat, 18 Sep 2021 11:48:24 -0400 Received: from mail.kernel.org ([198.145.29.99]:40766 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229575AbhIRPsY (ORCPT ); Sat, 18 Sep 2021 11:48:24 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id CA2886127A; Sat, 18 Sep 2021 15:46:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1631980020; bh=J5aL1LjIIzmZdFjro8IKYFFV9x4jCgd4GhcHKNXFQiE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=1JKPdqVxRJCrPzbhxY5BrVIJ5FEMw0I42ZOXMkA14V9IW3JklXkvGu3G1A6puzmVc MytYCCl2dYnJEwNrrHS8AltghN0p6gMkd/KzMVoEHYZ+Edzi87S1P1vAo7IArUm2pK duSXHMJG27Fgswzb5k81jdDq1GCbi6/FV1KQ5EJ0= Date: Sat, 18 Sep 2021 17:46:57 +0200 From: Greg Kroah-Hartman To: Thomas Gleixner , Sasha Levin Cc: Arnd Bergmann , Linux Kernel Mailing List , "# 3.4.x" , Lukas Hannen Subject: Re: [PATCH 5.14 298/334] time: Handle negative seconds correctly in timespec64_to_ns() Message-ID: References: <20210913131113.390368911@linuxfoundation.org> <20210913131123.500712780@linuxfoundation.org> <874kak9moe.ffs@tglx> <87sfy38p1o.ffs@tglx> <87ee9n80gz.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ee9n80gz.ffs@tglx> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 17, 2021 at 09:29:32PM +0200, Thomas Gleixner wrote: > 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? Ah, yes, that makes much more sense, sorry for the confusion. Sasha, what do you think? You are the one that scripts all of this, not me :) greg k-h