From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9A796C432BE for ; Wed, 1 Sep 2021 17:26:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7BC166101B for ; Wed, 1 Sep 2021 17:26:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344594AbhIAR1S (ORCPT ); Wed, 1 Sep 2021 13:27:18 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:48834 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344419AbhIAR1R (ORCPT ); Wed, 1 Sep 2021 13:27:17 -0400 Received: from in01.mta.xmission.com ([166.70.13.51]:36124) by out01.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1mLU0C-00BPFm-40; Wed, 01 Sep 2021 11:26:20 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95]:50202 helo=email.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1mLU0A-00E0Lo-Ry; Wed, 01 Sep 2021 11:26:19 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Greg Kroah-Hartman Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org, syzbot+01985d7909f9468f013c@syzkaller.appspotmail.com, Alexey Gladkov , Sasha Levin In-Reply-To: (Greg Kroah-Hartman's message of "Wed, 1 Sep 2021 18:40:25 +0200") References: <20210901122300.503008474@linuxfoundation.org> <20210901122301.773759848@linuxfoundation.org> <87v93k4bl6.fsf@disp2133> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Date: Wed, 01 Sep 2021 12:26:10 -0500 Message-ID: <875yvk1a31.fsf@disp2133> MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1mLU0A-00E0Lo-Ry;;;mid=<875yvk1a31.fsf@disp2133>;;;hst=in01.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19f0m9OYwI8n0/+ppm82Kvgc8OcOnANoWU= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH 5.10 036/103] ucounts: Increase ucounts reference counter before the security hook X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org Greg Kroah-Hartman writes: > On Wed, Sep 01, 2021 at 09:25:25AM -0500, Eric W. Biederman wrote: >> Greg Kroah-Hartman writes: >> >> > From: Alexey Gladkov >> > >> > [ Upstream commit bbb6d0f3e1feb43d663af089c7dedb23be6a04fb ] >> > >> > We need to increment the ucounts reference counter befor security_prepare_creds() >> > because this function may fail and abort_creds() will try to decrement >> > this reference. >> >> Has the conversion of the rlimits to ucounts been backported? >> >> Semantically the code is an improvement but I don't know of any cases >> where it makes enough of a real-world difference to make it worth >> backporting the code. >> >> Certainly the ucount/rlimit conversions do not meet the historical >> criteria for backports. AKA simple obviously correct patches. >> >> The fact we have been applying fixes for the entire v5.14 stabilization >> period is a testament to the code not quite being obviously correct. >> >> Without backports the code only affects v5.14 so I have not been >> including a Cc stable on any of the commits. >> >> So color me very puzzled about what is going on here. > > Sasha picked this for some reason, but if you think it should be > dropped, we can easily do so. My question is what is the reason Sasha picked this up? If this patch even applies to v5.10 the earlier patches have been backported. So we can't just drop this patch. Either the earlier backports need to be reverted, or we need to make certain all of the patches are backported. I really am trying to understand what is going on and why. I work on a lot of stuff that has been imperfect for years. Generally I clean up the code and the semantics so the old imperfect code does not impede new development (user or kernel). Updating a couple of rlimits to the ucount infrastructure was one of those improvements to imperfect code. As I expect this situation to come up again and again, I am asking what is going on? What are the rules under which code is backported? I am hoping to get a clear answer on why what looks to me like feature development has been backported into v5.10, and v5.13. If the answer is going to be random commits are going to be backported whenever the stable reviewers think it is a good idea, with no explanation of why they think so, can I please not be Cc'd during stable review as I have no basis on which to perform a review. Eric