Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <fbc98bb0-a2d6-a450-e6fc-878701e5906d@fb.com>
Date:   Thu, 21 Jul 2022 08:53:08 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.11.0
Subject: Re: [PATCH 1/1] bpf: Drop unprotected find_vpid() in favour of
 find_get_pid()
Content-Language: en-US
To:     Jiri Olsa <olsajiri@gmail.com>, Lee Jones <lee@kernel.org>
Cc:     linux-kernel@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        John Fastabend <john.fastabend@gmail.com>,
        Andrii Nakryiko <andrii@kernel.org>,
        Martin KaFai Lau <martin.lau@linux.dev>,
        Song Liu <song@kernel.org>, KP Singh <kpsingh@kernel.org>,
        Stanislav Fomichev <sdf@google.com>,
        Hao Luo <haoluo@google.com>, bpf@vger.kernel.org
References: <20220721111430.416305-1-lee@kernel.org> <Ytk+/npvvDGg9pBP@krava>
 <Ytk/jT+zyNZpafgn@google.com> <YtlDPYQWDcORbP0o@krava>
From:   Yonghong Song <yhs@fb.com>
In-Reply-To: <YtlDPYQWDcORbP0o@krava>
Content-Type: text/plain; charset=UTF-8; format=flowed
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NG1XOVJ3UGR6aGZBYnUvektXRFBXbXQvSUE2MGc3ZVcxdldUWlQrRWVFV2VT?=
 =?utf-8?B?VTFScGhIMkJkY3pncncxK2o3UVNNZ1VJeDJ2Qk5uZko3TXlkK21JUmdJNVR2?=
 =?utf-8?B?bkNWSHZsamZFN1Zac3lzc0lUcmFRcHd3K2h4bzlCbnJqdyszM0lSeGRuMC9I?=
 =?utf-8?B?cGpYVVhaWjY5eWZwcTdOdjM3MysrK2N4c05lSmlvV1BaNDlielpEaTQ0YUlq?=
 =?utf-8?B?bGhQTW8yYnNhVTZ6cUR4L0hPNVJKdkg0Z3JhTFUySTYwYXhaUzNkRlhLTEpZ?=
 =?utf-8?B?UXA1WUNwUmZ2dUdqWm5mWDNPK0xuM29rRFdMbWNmZjNibU1nZ2NGLzJka3o2?=
 =?utf-8?B?NWJob2hzaWdYR2ZzQWF3TUE5Vlc1ZnlsQytXOU9zVkhkSzZFaWcxVlNGa1JH?=
 =?utf-8?B?VmFEeVlySlBMVEZhOTZsaHdQN0VUeHpRbWJrYVRZTEYzd3AvWGJlcFNPVkE1?=
 =?utf-8?B?OC9ycjJuVjZSbVBGYXA3OHE2TVFTUEN5TTM0V1gyalVvRThwb20vMEVMT2lQ?=
 =?utf-8?B?RWsyL3hYUkFhVWd0U29kMmRXcVVqT3hIOWJHTkZPK29Jdm03cjFpdDFCSUJi?=
 =?utf-8?B?TTg0S3BlT0NMZWwwWjNnaTRXZVRvdWo1UFZNOXlEYzRhMjRoalNUMDRPR3F5?=
 =?utf-8?B?aUpqNkhjS3RqTDhISnNzSHZITGpqbFZzQ0R3dksxVkMvUDRoYnY0anAzckxp?=
 =?utf-8?B?WllML3llNmowMFdDcE5HNjRzdkFrdGtGb3FwOG5sVTR5WEMxeEdtaTl4U3Zr?=
 =?utf-8?B?NTU0MlRHaS9xb1lYa2pkMURROTBVU0svL2psYnNOZEdVZG1NQThHeU0xOEMr?=
 =?utf-8?B?NHh3MTJ3dk5CNE1jWG1xRDBtSXhvUnFkU1NOTnhOSVA3Q2JrMXpoS3U1VWZw?=
 =?utf-8?B?YTRRR1hPMVdpckExQ1ppY1Y0R2pBN25vaDlSUjNIN0Q5QUNDTFRDRU5oOUVL?=
 =?utf-8?B?ZCs3N0FUL2ZOaDV5TGNvMGdzS0p0UzVONVlETzFDNldXS2JaN1M2cE9OQUFq?=
 =?utf-8?B?c1B0ZFV6WSsyVjlQZWdZU043bjgya2JNY25oNmIwTTdkU1N0WElWZ1V3dnpV?=
 =?utf-8?B?UEF0dFFhWFpiV1lCL0h3dGZ4N3VHT2dLUjdCU053Mkc2Z2xoc2pKRGlsU3JH?=
 =?utf-8?B?dDdteE5jVzdzL1JyOXYxeXZzamd3dk1lY0J3TG1xRCtlbSsyYnM1cjNHbVFV?=
 =?utf-8?B?bFZqV0xOTk14emZrekpIU2x4TUFZUkdZYk91eHNQeTdHbUxPY2VaQkYzNEVF?=
 =?utf-8?B?ZWNMaVUva0hiV09QaWZVRDRDa3pjZURmQVdwOFErdzBNNHJPYXMzL1ZYWDhB?=
 =?utf-8?B?NHYwelc2ZTY5bnlRTDF1ekpVSDBhVVY2SnRNdE5DWUlhS3lPTDZXejFiUjRt?=
 =?utf-8?B?ZzJMYmt3OFFzcFo1SFl3b2xWWFQ5dm01Z1FibnFDYzBDVk0vSFlDRXRwbzlu?=
 =?utf-8?B?OXgxRGFoWWJnQ3hIcnE0S0VJU2MvS1Y4dTQwTzVvMjl3c0hhTVV4VDh3VVJK?=
 =?utf-8?B?L2ZRRFlrZGxORUc1QUpETVFDTlU1YWNKWWhzSjNqTHExcFYwVEFvSmQwUEZt?=
 =?utf-8?B?OGlIZlNCenduUHRDaHZpK2g5bENRZUlraWpBM2xWSDE5U0RnMjdKaEZ0Q3p4?=
 =?utf-8?B?VlkvL3JaZysrQnArK3dPWTVaOFh2aE1LMFZ0UHAxcWh4MHAwVnpsZVRmR0FR?=
 =?utf-8?B?TUdRNEk0MzROWHVRSlo1NTIwQ2ZjY1l5dHRuVDZNdldhTGVRMjZ4YyszRFY5?=
 =?utf-8?B?S3BCUkhjZGp3UmNZM0lMb2dhVjhWNVJvdEs0SHNySFFrRVl2eThYb2VqUzJQ?=
 =?utf-8?B?RzlLV2Q4U0F4QytERTNxR3pocGVweGM2MEpUWWYzVnhCOHBINkhnMFVDZkU0?=
 =?utf-8?B?bE9pUS91T0RhOWtQblRJcTVYUTVxQUptZ2JBR2k0bDlRUmFab2FqZjZ5UlZ1?=
 =?utf-8?B?Mmd0NzRkbmNsU3pmUE15amNPSWVQZnh5cWh6bWlpb3dZQm0wWmdlV0hZYm4v?=
 =?utf-8?B?VysrTEd3NmtTK3FLcitNaEZnS2txZTNnM2ZxdGJLQWYyMlNuUG14SHlNd2ta?=
 =?utf-8?B?ditsT1dvT2Z6dUxhSEY5MnAvV1Z3eVJaWXlBZU5GL2MrYWhOeitld0NwZm9O?=
 =?utf-8?Q?IDmSQ4T+ZaUiI7aEOWkARh5Oi?=
X-OriginatorOrg: fb.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dac499a8-ae66-4c3f-4d75-08da6b311e09
X-MS-Exchange-CrossTenant-AuthSource: SN6PR1501MB2064.namprd15.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jul 2022 15:53:12.9560
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: eYrwzhBAUj7SheS6Q3KXEqgjWIla9+tnyq7i9BB9urRW1lHuuOnzp797bLBjlJul
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR1501MB4126
X-Proofpoint-GUID: nbHQ6H4D1oqpSEjqzrb3gaf7xkqNkeKV
X-Proofpoint-ORIG-GUID: nbHQ6H4D1oqpSEjqzrb3gaf7xkqNkeKV
Content-Transfer-Encoding: 8bit
X-Proofpoint-UnRewURL: 0 URL was un-rewritten
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1
 definitions=2022-07-21_22,2022-07-20_01,2022-06-22_01
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,
        RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,
        SPF_NONE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On 7/21/22 5:14 AM, Jiri Olsa wrote:
> On Thu, Jul 21, 2022 at 12:59:09PM +0100, Lee Jones wrote:
>> On Thu, 21 Jul 2022, Jiri Olsa wrote:
>>
>>> On Thu, Jul 21, 2022 at 12:14:30PM +0100, Lee Jones wrote:
>>>> The documentation for find_pid() clearly states:
> 
> typo find_vpid
> 
>>>>
>>>>    "Must be called with the tasklist_lock or rcu_read_lock() held."
>>>>
>>>> Presently we do neither.
> 
> just curious, did you see crash related to this or you just spot that
> 
>>>>
>>>> In an ideal world we would wrap the in-lined call to find_vpid() along
>>>> with get_pid_task() in the suggested rcu_read_lock() and have done.
>>>> However, looking at get_pid_task()'s internals, it already does that
>>>> independently, so this would lead to deadlock.
>>>
>>> hm, we can have nested rcu_read_lock calls, right?
>>
>> I assumed not, but that might be an oversight on my part.

 From kernel documentation, nested rcu_read_lock is allowed.
https://www.kernel.org/doc/Documentation/RCU/Design/Requirements/Requirements.html

RCU's grace-period guarantee allows updaters to wait for the completion 
of all pre-existing RCU read-side critical sections. An RCU read-side 
critical section begins with the marker rcu_read_lock() and ends with 
the marker rcu_read_unlock(). These markers may be nested, and RCU 
treats a nested set as one big RCU read-side critical section. 
Production-quality implementations of rcu_read_lock() and 
rcu_read_unlock() are extremely lightweight, and in fact have exactly 
zero overhead in Linux kernels built for production use with 
CONFIG_PREEMPT=n.

>>
>> Would that be your preference?
> 
> seems simpler than calling get/put for ppid

The current implementation seems okay since we can hide
rcu_read_lock() inside find_get_pid(). We can also avoid
nested rcu_read_lock(), which is although allowed but
not pretty.

> 
> jirka
> 
>>
>>>> Instead, we'll use find_get_pid() which searches for the vpid, then
>>>> takes a reference to it preventing early free, all within the safety
>>>> of rcu_read_lock().  Once we have our reference we can safely make use
>>>> of it up until the point it is put.
>>>>
>>>> Cc: Alexei Starovoitov <ast@kernel.org>
>>>> Cc: Daniel Borkmann <daniel@iogearbox.net>
>>>> Cc: John Fastabend <john.fastabend@gmail.com>
>>>> Cc: Andrii Nakryiko <andrii@kernel.org>
>>>> Cc: Martin KaFai Lau <martin.lau@linux.dev>
>>>> Cc: Song Liu <song@kernel.org>
>>>> Cc: Yonghong Song <yhs@fb.com>
>>>> Cc: KP Singh <kpsingh@kernel.org>
>>>> Cc: Stanislav Fomichev <sdf@google.com>
>>>> Cc: Hao Luo <haoluo@google.com>
>>>> Cc: Jiri Olsa <jolsa@kernel.org>
>>>> Cc: bpf@vger.kernel.org
>>>> Fixes: 41bdc4b40ed6f ("bpf: introduce bpf subcommand BPF_TASK_FD_QUERY")
>>>> Signed-off-by: Lee Jones <lee@kernel.org>
>>>> ---
>>>>   kernel/bpf/syscall.c | 5 ++++-
>>>>   1 file changed, 4 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
>>>> index 83c7136c5788d..c20cff30581c4 100644
>>>> --- a/kernel/bpf/syscall.c
>>>> +++ b/kernel/bpf/syscall.c
>>>> @@ -4385,6 +4385,7 @@ static int bpf_task_fd_query(const union bpf_attr *attr,
>>>>   	const struct perf_event *event;
>>>>   	struct task_struct *task;
>>>>   	struct file *file;
>>>> +	struct pid *ppid;
>>>>   	int err;
>>>>   
>>>>   	if (CHECK_ATTR(BPF_TASK_FD_QUERY))
>>>> @@ -4396,7 +4397,9 @@ static int bpf_task_fd_query(const union bpf_attr *attr,
>>>>   	if (attr->task_fd_query.flags != 0)
>>>>   		return -EINVAL;
>>>>   
>>>> -	task = get_pid_task(find_vpid(pid), PIDTYPE_PID);
>>>> +	ppid = find_get_pid(pid);
>>>> +	task = get_pid_task(ppid, PIDTYPE_PID);
>>>> +	put_pid(ppid);
>>>>   	if (!task)
>>>>   		return -ENOENT;
>>>>   
>>
>> -- 
>> Lee Jones [李琼斯]