All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Yonatan Linik <yonatanlinik@gmail.com>
Cc: davem@davemloft.net, ast@kernel.org, daniel@iogearbox.net,
	kafai@fb.com, songliubraving@fb.com, yhs@fb.com, andriin@fb.com,
	john.fastabend@gmail.com, kpsingh@chromium.org,
	willemb@google.com, john.ogness@linutronix.de, arnd@arndb.de,
	maowenan@huawei.com, colin.king@canonical.com,
	orcohen@paloaltonetworks.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, bpf@vger.kernel.org
Subject: Re: [PATCH 1/1] net: Fix use of proc_fs
Date: Sat, 12 Dec 2020 11:48:02 -0800	[thread overview]
Message-ID: <20201212114802.21a6b257@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> (raw)
In-Reply-To: <20201211163749.31956-2-yonatanlinik@gmail.com>

On Fri, 11 Dec 2020 18:37:49 +0200 Yonatan Linik wrote:
> proc_fs was used, in af_packet, without a surrounding #ifdef,
> although there is no hard dependency on proc_fs.
> That caused the initialization of the af_packet module to fail
> when CONFIG_PROC_FS=n.
> 
> Specifically, proc_create_net() was used in af_packet.c,
> and when it fails, packet_net_init() returns -ENOMEM.
> It will always fail when the kernel is compiled without proc_fs,
> because, proc_create_net() for example always returns NULL.
> 
> The calling order that starts in af_packet.c is as follows:
> packet_init()
> register_pernet_subsys()
> register_pernet_operations()
> __register_pernet_operations()
> ops_init()
> ops->init() (packet_net_ops.init=packet_net_init())
> proc_create_net()
> 
> It worked in the past because register_pernet_subsys()'s return value
> wasn't checked before this Commit 36096f2f4fa0 ("packet: Fix error path in
> packet_init.").
> It always returned an error, but was not checked before, so everything
> was working even when CONFIG_PROC_FS=n.
> 
> The fix here is simply to add the necessary #ifdef.
> 
> Signed-off-by: Yonatan Linik <yonatanlinik@gmail.com>

Hm, I'm guessing you hit this on a kernel upgrade of a real system?
It seems like all callers to proc_create_net (and friends) interpret
NULL as an error, but only handful is protected by an ifdef.

I checked a few and none of them cares about the proc_dir_entry pointer
that gets returned. Should we perhaps rework the return values of the
function so that we can return success if !CONFIG_PROC_FS without
having to yield a pointer?

Obviously we can apply this fix so we can backport to 5.4 if you need
it. I think the ifdef is fine, since it's what other callers have.

> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> index 2b33e977a905..031f2b593720 100644
> --- a/net/packet/af_packet.c
> +++ b/net/packet/af_packet.c
> @@ -4612,9 +4612,11 @@ static int __net_init packet_net_init(struct net *net)
>  	mutex_init(&net->packet.sklist_lock);
>  	INIT_HLIST_HEAD(&net->packet.sklist);
>  
> +#ifdef CONFIG_PROC_FS
>  	if (!proc_create_net("packet", 0, net->proc_net, &packet_seq_ops,
>  			sizeof(struct seq_net_private)))
>  		return -ENOMEM;
> +#endif /* CONFIG_PROC_FS */
>  
>  	return 0;
>  }


  parent reply	other threads:[~2020-12-12 19:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-11 16:37 [PATCH 0/1] net: Fix use of proc_fs Yonatan Linik
2020-12-11 16:37 ` [PATCH 1/1] " Yonatan Linik
2020-12-11 20:59   ` Arnd Bergmann
2020-12-12  8:39     ` Yonatan Linik
2020-12-12 19:48   ` Jakub Kicinski [this message]
2020-12-12 21:39     ` Yonatan Linik
2020-12-12 21:51       ` Jakub Kicinski
2020-12-13  9:48         ` Yonatan Linik
2020-12-14 19:07           ` Jakub Kicinski

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=20201212114802.21a6b257@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com \
    --to=kuba@kernel.org \
    --cc=andriin@fb.com \
    --cc=arnd@arndb.de \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=colin.king@canonical.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=john.fastabend@gmail.com \
    --cc=john.ogness@linutronix.de \
    --cc=kafai@fb.com \
    --cc=kpsingh@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maowenan@huawei.com \
    --cc=netdev@vger.kernel.org \
    --cc=orcohen@paloaltonetworks.com \
    --cc=songliubraving@fb.com \
    --cc=willemb@google.com \
    --cc=yhs@fb.com \
    --cc=yonatanlinik@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.