Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [GIT PULL] Please pull proc and exec work for 5.7-rc1
From:   Bernd Edlinger <bernd.edlinger@hotmail.de>
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     "Eric W. Biederman" <ebiederm@xmission.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Alexey Gladkov <gladkov.alexey@gmail.com>
References: <87blobnq02.fsf@x220.int.ebiederm.org>
 <CAHk-=wgYCUbEmwieOBzVNZbSAM9wCZA8Z0665onpNnEcC-UpDg@mail.gmail.com>
 <AM6PR03MB517026CDE64EC57DE37C6080E4C70@AM6PR03MB5170.eurprd03.prod.outlook.com>
 <CAHk-=wjqNnpsBJR1xM_Ce91cNh=24CDt6ibpL2G=vDUbSFGR8g@mail.gmail.com>
 <AM6PR03MB517004C9D4F4E39816E926D9E4C40@AM6PR03MB5170.eurprd03.prod.outlook.com>
 <AM6PR03MB5170DF7DC6986CC3759B041AE4C40@AM6PR03MB5170.eurprd03.prod.outlook.com>
Message-ID: <AM6PR03MB5170CFC06260511B79C81E71E4C20@AM6PR03MB5170.eurprd03.prod.outlook.com>
Date:   Mon, 6 Apr 2020 08:41:30 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.6.1
In-Reply-To: <AM6PR03MB5170DF7DC6986CC3759B041AE4C40@AM6PR03MB5170.eurprd03.prod.outlook.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [192.168.1.101] (92.77.140.102) by AM0PR10CA0047.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:150::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15 via Frontend Transport; Mon, 6 Apr 2020 06:41:31 +0000
X-Microsoft-Original-Message-ID: <9d330a9f-593c-e371-23e7-c1edfbf6fcbc@hotmail.de>
X-TMN:  [ot9qlohUNOneCO85sCFvhNWoMYPwz+Bj]
X-MS-PublicTrafficType: Email
X-IncomingHeaderCount: 50
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-Correlation-Id: c48b7832-cb79-41f0-db41-08d7d9f58ac1
X-MS-TrafficTypeDiagnostic: VE1EUR03HT115:
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: j/RR/w1TTnhW0qbDP4Fjt5XAACKA/B+mhcjosvny0M/I+jjKPiHYyESCZTsvg5LymY6t9mToscr/v1A9fjj1hmmRQ6LRmgE9HQ5g4DN0I/gvpL6UcrLHpo6PVcd3Y1HI6xFicRTsAPThI+7ypN+5DhPLfaO8FBRngwlQaOX19j70/nJQRua9JQYvvbFOcNIx
X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:0;SRV:;IPV:NLI;SFV:NSPM;H:AM6PR03MB5170.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFTY:;SFS:;DIR:OUT;SFP:1901;
X-MS-Exchange-AntiSpam-MessageData: V9YIcr1KUExSlUsOGmwSfPMgCWLqNXu37ehvA2U2HEYcpvDz1C6DAd3vZ9R0ug6bCUjdpjNI4IgIWs4xYJluuSRLaHHY1FBwz+x6MgIFG8RfCfEtHai7tTbxQYeiDydSFobfl2WymvgEb1AQsbQyhQ==
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c48b7832-cb79-41f0-db41-08d7d9f58ac1
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Apr 2020 06:41:31.9866
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1EUR03HT115
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On 4/4/20 7:48 AM, Bernd Edlinger wrote:
> 
> 
> On 4/4/20 7:43 AM, Bernd Edlinger wrote:
>>
>>
>> On 4/3/20 6:23 PM, Linus Torvalds wrote:
>>> On Fri, Apr 3, 2020 at 8:09 AM Bernd Edlinger <bernd.edlinger@hotmail.de> wrote:
>>>>
>>>> On 4/2/20 9:04 PM, Linus Torvalds wrote:
>>>>> In fact, then you could drop the
>>>>>
>>>>>                         mutex_unlock(&tsk->signal->exec_update_mutex);
>>>>>
>>>>> in the error case of exec_mmap(), because now the error handling in
>>>>> free_bprm() would do the cleanup automatically.
>>>>>
>>>>
>>>> The error handling is sometimes called when the exec_update_mutex is
>>>> not taken, in fact even de_thread not called.
>>>
>>> But that's the whole point of the flag. Make the flag be about "do I
>>> hold the mutex", and then the error handling does the right thing
>>> regardless.
>>>
>>>> Can you say how you would suggest that to be done?
>>>
>>> I think the easiest thing to do to explain is to just write the patch.
>>>
>>> This is entirely untested, but see what the difference is? I make the
>>> flag be about exactly where I take the lock, not about some "I have
>>> called exec_mmap".
>>>
>>> Which means that now exec_mmap() doesn't even need to unlock it in the
>>> error case, because the unlocking will happen properly in the
>>> bprm_exit regardless.
>>>
>>> This makes that unconditional unlocking logic much more obvious.
>>>
>>> That said, Eric says he can make it all properly static so that it
>>> doesn't need that kind of dynamic "if (x) unlock()" logic at all,
>>> which is much better.
>>>
>>> So this patch is not for consumption, it's purely for "look, something
>>> like this"
>>>
>>
>>
>> Just one suggestion, in general It would feel pretty much okay if you
>> like to improve the naming, and the consistency in any of my patches.
>>

I mean it, I could not imagine a greater honor, than You improving
one of my patches.

Just please consider what I said below before you do it.


Thanks
Bernd.

>>> @@ -1067,7 +1069,6 @@ static int exec_mmap(struct mm_struct *mm)
>>>  		down_read(&old_mm->mmap_sem);
>>>  		if (unlikely(old_mm->core_state)) {
>>>  			up_read(&old_mm->mmap_sem);
>>> -			mutex_unlock(&tsk->signal->exec_update_mutex);
>>
>> I was trying to replicate the behavior of prepare_bprm_creds
>> which also unlocks the mutex in the error case, therefore it felt
>> okay to unlock the mutex here, but it will work either way.
>>
>> I should further note, that the mutex would be locked if this
>> error exit is taken, and unlocked if this error happens:
>>
>>         ret = mutex_lock_killable(&tsk->signal->exec_update_mutex);
>>         if (ret)
>>                 return ret;
>>
>> so at least the function comment I introduced above should be updated:
>>  * Maps the mm_struct mm into the current task struct.
>>  * On success, this function returns with the mutex
>>  * exec_update_mutex locked.
>>
>>
>>>  		put_binfmt(fmt);
>>> -		if (retval < 0 && bprm->called_exec_mmap) {
>>> +		if (retval < 0 && !bprm->mm) {
>>
>> Using bprm->mm like this feels like a hack to me.  It works here,
>> but nowhere else.  Therefore I changed this line.
>>
>> Using !bprm->mm in the error handling code made Eric's patch fail.
>>
> 
> That does probably work better it the boolean is named
> after_the_point_of_no_return or something....
> 
> 
>>
>> Thanks
>> Bernd.
>>
>>
>>>               Linus
>>>