Linux filesystem development
 help / color / mirror / Atom feed
From: Paulo Alcantara <pc@manguebit.com>
To: Song Liu <song@kernel.org>,
	netfs@lists.linux.dev, linux-fsdevel@vger.kernel.org
Cc: dhowells@redhat.com, kernel-team@fb.com, Song Liu <song@kernel.org>
Subject: Re: [PATCH] netfs: Let netfs depends on PROC_FS
Date: Mon, 07 Apr 2025 21:51:41 -0300	[thread overview]
Message-ID: <b395436343d8df2efdebb737580fe976@manguebit.com> (raw)
In-Reply-To: <notmuch-sha1-7bf7bb81673494d9bbe96c6cfbeaf9005a6bd491>

Hi Song,

Paulo Alcantara <pc@manguebit.com> writes:

> Song Liu <song@kernel.org> writes:
>
>> When testing a special config:
>>
>> CONFIG_NETFS_SUPPORTS=y
>> CONFIG_PROC_FS=n
>>
>> The system crashes with something like:
>>
>> [    3.766197] ------------[ cut here ]------------
>> [    3.766484] kernel BUG at mm/mempool.c:560!
>> [    3.766789] Oops: invalid opcode: 0000 [#1] SMP NOPTI
>> [    3.767123] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G        W
>> [    3.767777] Tainted: [W]=WARN
>> [    3.767968] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
>> [    3.768523] RIP: 0010:mempool_alloc_slab.cold+0x17/0x19
>> [    3.768847] Code: 50 fe ff 58 5b 5d 41 5c 41 5d 41 5e 41 5f e9 93 95 13 00
>> [    3.769977] RSP: 0018:ffffc90000013998 EFLAGS: 00010286
>> [    3.770315] RAX: 000000000000002f RBX: ffff888100ba8640 RCX: 0000000000000000
>> [    3.770749] RDX: 0000000000000000 RSI: 0000000000000003 RDI: 00000000ffffffff
>> [    3.771217] RBP: 0000000000092880 R08: 0000000000000000 R09: ffffc90000013828
>> [    3.771664] R10: 0000000000000001 R11: 00000000ffffffea R12: 0000000000092cc0
>> [    3.772117] R13: 0000000000000400 R14: ffff8881004b1620 R15: ffffea0004ef7e40
>> [    3.772554] FS:  0000000000000000(0000) GS:ffff8881b5f3c000(0000) knlGS:0000000000000000
>> [    3.773061] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> [    3.773443] CR2: ffffffff830901b4 CR3: 0000000004296001 CR4: 0000000000770ef0
>> [    3.773884] PKRU: 55555554
>> [    3.774058] Call Trace:
>> [    3.774232]  <TASK>
>> [    3.774371]  mempool_alloc_noprof+0x6a/0x190
>> [    3.774649]  ? _printk+0x57/0x80
>> [    3.774862]  netfs_alloc_request+0x85/0x2ce
>> [    3.775147]  netfs_readahead+0x28/0x170
>> [    3.775395]  read_pages+0x6c/0x350
>> [    3.775623]  ? srso_alias_return_thunk+0x5/0xfbef5
>> [    3.775928]  page_cache_ra_unbounded+0x1bd/0x2a0
>> [    3.776247]  filemap_get_pages+0x139/0x970
>> [    3.776510]  ? srso_alias_return_thunk+0x5/0xfbef5
>> [    3.776820]  filemap_read+0xf9/0x580
>> [    3.777054]  ? srso_alias_return_thunk+0x5/0xfbef5
>> [    3.777368]  ? srso_alias_return_thunk+0x5/0xfbef5
>> [    3.777674]  ? find_held_lock+0x32/0x90
>> [    3.777929]  ? netfs_start_io_read+0x19/0x70
>> [    3.778221]  ? netfs_start_io_read+0x19/0x70
>> [    3.778489]  ? srso_alias_return_thunk+0x5/0xfbef5
>> [    3.778800]  ? lock_acquired+0x1e6/0x450
>> [    3.779054]  ? srso_alias_return_thunk+0x5/0xfbef5
>> [    3.779379]  netfs_buffered_read_iter+0x57/0x80
>> [    3.779670]  __kernel_read+0x158/0x2c0
>> [    3.779927]  bprm_execve+0x300/0x7a0
>> [    3.780185]  kernel_execve+0x10c/0x140
>> [    3.780423]  ? __pfx_kernel_init+0x10/0x10
>> [    3.780690]  kernel_init+0xd5/0x150
>> [    3.780910]  ret_from_fork+0x2d/0x50
>> [    3.781156]  ? __pfx_kernel_init+0x10/0x10
>> [    3.781414]  ret_from_fork_asm+0x1a/0x30
>> [    3.781677]  </TASK>
>> [    3.781823] Modules linked in:
>> [    3.782065] ---[ end trace 0000000000000000 ]---
>>
>> This is caused by the following error path in netfs_init():
>>
>>         if (!proc_mkdir("fs/netfs", NULL))
>>                 goto error_proc;
>>
>> Fix this by letting netfs depends on PROC_FS.
>>
>> Signed-off-by: Song Liu <song@kernel.org>
>> ---
>>  fs/netfs/Kconfig | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> Reviewed-by: Paulo Alcantara (Red Hat) <pc@manguebit.com>

Sorry, I take it back.  Reviewed it way too soon :-/

It wouldn't make sense to make it depend on PROC_FS.

I see two problems here:

(1) We shouldn't be creating /proc/fs/netfs if CONFIG_PROC_FS=n

(2) There's a wrong assumption in the API that @netfs_request_pool and
@netfs_subrequest_pool will always be initialized.  For example, we
should return an error from netfs_alloc_[sub]rquest() functions in case
@mempool == NULL.

Dave, any thoughts?

  parent reply	other threads:[~2025-04-08  0:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-07 18:47 [PATCH] netfs: Let netfs depends on PROC_FS Song Liu
2025-04-07 19:18 ` Paulo Alcantara
     [not found] ` <notmuch-sha1-7bf7bb81673494d9bbe96c6cfbeaf9005a6bd491>
2025-04-08  0:51   ` Paulo Alcantara [this message]
2025-04-08  7:31     ` David Howells
2025-04-08 15:05       ` Paulo Alcantara
2025-04-08 16:14         ` Song Liu
2025-04-09 11:56           ` David Howells
2025-04-09 15:03       ` David Howells

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b395436343d8df2efdebb737580fe976@manguebit.com \
    --to=pc@manguebit.com \
    --cc=dhowells@redhat.com \
    --cc=kernel-team@fb.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=netfs@lists.linux.dev \
    --cc=song@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox