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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 013DEC3DA4A for ; Thu, 8 Aug 2024 20:16:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5BF8B6B0089; Thu, 8 Aug 2024 16:16:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 56F926B008A; Thu, 8 Aug 2024 16:16:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 437066B008C; Thu, 8 Aug 2024 16:16:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 2654E6B0089 for ; Thu, 8 Aug 2024 16:16:13 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id BF4861615CB for ; Thu, 8 Aug 2024 20:16:12 +0000 (UTC) X-FDA: 82430184984.28.470D35C Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) by imf12.hostedemail.com (Postfix) with ESMTP id D5C324002B for ; Thu, 8 Aug 2024 20:16:09 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=SO9X0fuI; spf=pass (imf12.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.208.180 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723148104; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=5WswxgKgPlMEM9A/VnwmibPK7y43zuvqRAPNbAJdAqw=; b=OkXH5Olcr5e7XY9Kw3zoCQWBYkqeTv/sJqTMAXIYnk5orpbkfX14Z47j9SYeYGUdSkUigD xXpsvGiomtPKdd3yIxTvVFrxpDQ2yKy2UsX8LF7/AUKWgrZB9z4njfI8SFdjZj4T/i5PYc rIILNuTnktmqBuCOfNyOzpRrPYqKjmo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723148104; a=rsa-sha256; cv=none; b=7dmCGLzzdUKVUCVfty7iau4I5Z8VIq5MdqjdIKyk7jY7JuXrVrAugKmfw4THM7y9K8JnTg phDXLP9hV9nO4Z6Xjr7TULLLddTksX/s/V1iFhNJ6qOrE2yxv5answJiRLMppCRcsRCC7f fgzhWUO3iAEYVnJOVNd0t9Bfivjdt9Q= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=SO9X0fuI; spf=pass (imf12.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.208.180 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-lj1-f180.google.com with SMTP id 38308e7fff4ca-2f0271b0ae9so13268011fa.1 for ; Thu, 08 Aug 2024 13:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723148168; x=1723752968; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=5WswxgKgPlMEM9A/VnwmibPK7y43zuvqRAPNbAJdAqw=; b=SO9X0fuI2hHno04bTGGh9EYXPbyei7bnryZIkdR+FQcWYgsI+B7WkSZGPPVa10ad9a QvBLSgcNb5xFMlmY6igKi2gWferFQ590W/4zmj+JsO828MnrVsTT3SCRrfzFGKC6guh+ TpbJ1pVSRUAOFnyT5LyNKNh5V/ULE+BOirHxKJVRK5yFG0B4lHGvLkIValKwU12e5Bfj TdTxMbgpF2UVB+UrQxYNY9g+fgOUVDTD7fGHKx/sceIUIo/UOmg0hUS1RkW7YQ2dZnJH U7idrm/Waktrq2mc5QRsX6djmuTYl9iZBNrNuL084iE7U5F1AnzqJjbJrL0KDDcETO2s ychw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723148168; x=1723752968; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5WswxgKgPlMEM9A/VnwmibPK7y43zuvqRAPNbAJdAqw=; b=w/WvFyKxDweA05NVuor/3ETiz4Tjylq2gpLqZr8kZoVTNFx7RuencCBnDZ4d3m6tVl XE4imP+bkSPRpN4HiyUXL4g96UbmXMkWK4FK+HTxzaAIVIJF4Np5EV8qI+2tfnYUYGoF 6mZ6nTOVpgrIyq7spOb16KgSEF6E4GuYFKAGFaa35NGKcKswOhXnsGfzrFCd+zAZXIgr ueyujaI2MXJELyi3Yq65cBo4+YJWNgOrsaZ0dr2X9HVZl0ZxJbtIGdqj1+4iRX1idWIc 5+jm2HFRvPsYHS65Zwa2f0XwU3XAKHiB6QO1/09Hbttt+UPymjtNl3SYbfVJYKFlehCX Gshw== X-Forwarded-Encrypted: i=1; AJvYcCVxBLgLRH0TmrtIwqCdKv/Sr4ELNpdWY7FPMQcKktbugWyz5y6AcYWtVK+6GI2Drh48OjcmmgPaLBjacfHTO1ulE6Q= X-Gm-Message-State: AOJu0YzCtMrpw8oB6FNC8JQfcMvmVZd5vIBrRE/t9ySZYS6tSgi9ENAt r0EYOXuFtCA5JyIwP8XrcmfmjcRM2ZO+Ll3mohFSiQQl5ea5EyCU3ANIvKkdljNpB1Gkbil95mu OnwmhQz1Vui6UbcQEBGTjtM1qrp8= X-Google-Smtp-Source: AGHT+IG5sK/sBO7DQ99xdhWCFp9Zi1Ta/VcdaHjVkbOOcjHIlN9UPaqOTevYdJddqyhsk0T7fJPaN77INrnqhXT63ec= X-Received: by 2002:a05:6512:b8f:b0:52c:e030:1450 with SMTP id 2adb3069b0e04-530e5829a11mr1761286e87.14.1723148167572; Thu, 08 Aug 2024 13:16:07 -0700 (PDT) MIME-Version: 1.0 References: <20240807234029.456316-1-andrii@kernel.org> <20240807234029.456316-7-andrii@kernel.org> In-Reply-To: From: Andrii Nakryiko Date: Thu, 8 Aug 2024 13:15:52 -0700 Message-ID: Subject: Re: [PATCH v4 bpf-next 06/10] lib/buildid: implement sleepable build_id_parse() API To: Shakeel Butt Cc: Andrii Nakryiko , bpf@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, adobriyan@gmail.com, hannes@cmpxchg.org, ak@linux.intel.com, osandov@osandov.com, song@kernel.org, jannh@google.com, linux-fsdevel@vger.kernel.org, willy@infradead.org, Omar Sandoval Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: D5C324002B X-Stat-Signature: 4ke5u89dw1paxbs3wk1qmhtph5h3m855 X-HE-Tag: 1723148169-322519 X-HE-Meta: U2FsdGVkX1/gLlJV1Mh9BTLpFvIjlM1iAWRCoYISVkUhOyp+oXeKyphbPsQ4gCfm4XwN+NSm0KuIYKctnai50Jxiyvd5LK0+er3qab5G9/j8zwMri8i1av3WGA1q6nVGx/A4swmozjUSohHp2E9YkIFDQhNJaE3+AB/dNXFeRR8Mse0dE2Ff4P66R7SeaPTrESHmbp/dIrmFDNKAeQAQ/4eV/Igr+dkHwOsLU1vrUQZnINLQv8akSf7XNHAqiEkjKMiOQQJWaqB0/gxjX2u/hvHTshqXA/IwlURM8cIUSDNDzMIpMcFmR+u21ZVVLRjQ93AyB+wb9UWdOD2/BoNKO4UMbNwFY6gBAkK3u1ISSjUNwp5ilYl8fgbFD3upOj41pnZsFM2X9oO4eW07iTVtyNuDrzZqYPdUvbSNC3SeCLS56UfkWPxGCWsg+Q70y3LErdzLxJIXMqsrWpIunOEX0yb/8IGZgjFQw8qePBYIA/20tEJpyNrvOc1X7GdBSkV30I9KAcVc7DjuXL5z3Co18NqAhDAYRym/U2YINRcZkjR4u/MGaAuzTYDAkuw8GT9tCLLjpxXGAwLjroam86NeMy9/9YezLIX27cwMWu4JF4Li2IgF4gpNCetW3uSg1+AixFT2xFebTCaX8fZxQLxL+tNBJhrjTZzxHxt8yxLjKPu5jhpAPdw/UCzCX5qIFer3Dr6Z0lodEuiE23jpJf43XSJqgDAL77u2zmKRfTx4HoV0Um8hb1fPxLLh4NO/4qPBENFWgP/hXWdwGpIVCEqRpoQPxY7erx+c+MJDjdCnCiAKut+TkE9fcDA9OgNpVbHNWJPJqlnqpYxAd6r3d3EjoBg5iUnZosUtlTGvwvgWREGBNL/DNWnXzDAmOO0zVvBXev/3mV1IPQrElx+7a1qcfkNNwi54Uhes4t7VeUaHtPjzNR1usdTsJNfueYVyrbPizCVxoBQxuE6a8WTGcgR zaW1fz+z UD6fbOZodNt3n0q2suBaKuvOf6LPYO+odrvlo3NGp2dBwNz7kcSFuypwaGpF/wIzMzgvEtSn1RUqhcN2e+cCO25mh6K++IaD1noMzppTWT2USEQ1+Ut3pbaGstYMKZY8X2SCe2ZllTo96oSQXrFmhHwYOkzxVG8x/RIHOwzxGEdy5ZVjzC1V5pEM9s3XBbxsKwKBpVYSV7Hgf4MZYo+90jDxYuYHSSBIANzoNQg4erBFHFNWnYGr9ruKt3/NyKxA87E7XMoJAZp4HdXM584aHtYiL9v6fyrTuPJlAcmpZb8PA9txcCeFxsPCX5ynSpa0MXm5H3oUSCJRSa/htlTOHgrsAVUSOXrGkua1TlqQAB2P5/28hm2orRrcbdkGf3ouJOAbM0FoZwJ70ZP2IDDBGes2SEf3SgBy0jC2QS0ZtBruICHh4i4dgWTAeLNY2rlGaKHwbOBrGOIftLS4GacbD1pJtu6dnHXGPd99raAKjGaG1+RNr2MLqNAUWGEyMlJxrqPgcsIWXnO4Qd+KsTc6qExAyKD01OJsCKSX8kkYAmIcvSfg= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Aug 8, 2024 at 11:40=E2=80=AFAM Shakeel Butt wrote: > > On Wed, Aug 07, 2024 at 04:40:25PM GMT, Andrii Nakryiko wrote: > > Extend freader with a flag specifying whether it's OK to cause page > > fault to fetch file data that is not already physically present in > > memory. With this, it's now easy to wait for data if the caller is > > running in sleepable (faultable) context. > > > > We utilize read_cache_folio() to bring the desired folio into page > > cache, after which the rest of the logic works just the same at folio l= evel. > > > > Suggested-by: Omar Sandoval > > Cc: Shakeel Butt > > Cc: Johannes Weiner > > Signed-off-by: Andrii Nakryiko > > --- > > lib/buildid.c | 44 ++++++++++++++++++++++++++++---------------- > > 1 file changed, 28 insertions(+), 16 deletions(-) > > > > diff --git a/lib/buildid.c b/lib/buildid.c > > index 5e6f842f56f0..e1c01b23efd8 100644 > > --- a/lib/buildid.c > > +++ b/lib/buildid.c > > @@ -20,6 +20,7 @@ struct freader { > > struct folio *folio; > > void *addr; > > loff_t folio_off; > > + bool may_fault; > > }; > > struct { > > const char *data; > > @@ -29,12 +30,13 @@ struct freader { > > }; > > > > static void freader_init_from_file(struct freader *r, void *buf, u32 b= uf_sz, > > - struct address_space *mapping) > > + struct address_space *mapping, bool ma= y_fault) > > { > > memset(r, 0, sizeof(*r)); > > r->buf =3D buf; > > r->buf_sz =3D buf_sz; > > r->mapping =3D mapping; > > + r->may_fault =3D may_fault; > > } > > > > static void freader_init_from_mem(struct freader *r, const char *data,= u64 data_sz) > > @@ -63,6 +65,11 @@ static int freader_get_folio(struct freader *r, loff= _t file_off) > > freader_put_folio(r); > > > > r->folio =3D filemap_get_folio(r->mapping, file_off >> PAGE_SHIFT= ); > > + > > + /* if sleeping is allowed, wait for the page, if necessary */ > > + if (r->may_fault && (IS_ERR(r->folio) || !folio_test_uptodate(r->= folio))) > > + r->folio =3D read_cache_folio(r->mapping, file_off >> PAG= E_SHIFT, NULL, NULL); > > Willy's network fs comment is bugging me. If we pass NULL for filler, > the kernel will going to use fs's read_folio() callback. I have checked > read_folio() for fuse and nfs and it seems like for at least these two > filesystems the callback is accessing file->private_data. So, if the elf > file is on these filesystems, we might see null accesses. > Isn't that just a huge problem with the read_cache_folio() interface then? That file is optional, in general, but for some specific FS types it's not. How generic code is supposed to know this? Or maybe it's a bug with the nfs_read_folio() and fuse_read_folio() implementation that they can't handle NULL file argument? netfs_read_folio(), for example, seems to be working with file =3D=3D NULL just fine. Matthew, can you please advise what's the right approach here? I can, of course, always get file refcount, but most of the time it will be just an unnecessary overhead, so ideally I'd like to avoid that. But if I have to check each read_folio callback implementation to know whether it's required or not, then that's not great...