netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Breno Leitao <leitao@debian.org>
To: Pavel Begunkov <asml.silence@gmail.com>
Cc: Akinobu Mita <akinobu.mita@gmail.com>,
	kuba@kernel.org, davem@davemloft.net, edumazet@google.com,
	pabeni@redhat.com, Jonathan Corbet <corbet@lwn.net>,
	horms@kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Mina Almasry <almasrymina@google.com>,
	Willem de Bruijn <willemb@google.com>,
	Alexander Lobakin <aleksander.lobakin@intel.com>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>
Subject: Re: [PATCH net-next] net: Implement fault injection forcing skb reallocation
Date: Tue, 8 Oct 2024 12:09:46 +0100	[thread overview]
Message-ID: <ZwUDnGlhB09Widej@gmail.com> (raw)
In-Reply-To: <058e38c4-ead9-42bf-8a11-a97d0ead35fb@gmail.com>

On Mon, Oct 07, 2024 at 07:00:28PM +0100, Pavel Begunkov wrote:
> On 10/7/24 18:09, Breno Leitao wrote:
> > Hello Pavel,
> > 
> > On Mon, Oct 07, 2024 at 05:48:39PM +0100, Pavel Begunkov wrote:
> > > On 10/7/24 17:20, Breno Leitao wrote:
> > > > On Sat, Oct 05, 2024 at 01:38:59PM +0900, Akinobu Mita wrote:
> > > > > 2024年10月2日(水) 20:37 Breno Leitao <leitao@debian.org>:
> > > > > > 
> > > > > > Introduce a fault injection mechanism to force skb reallocation. The
> > > > > > primary goal is to catch bugs related to pointer invalidation after
> > > > > > potential skb reallocation.
> > > > > > 
> > > > > > The fault injection mechanism aims to identify scenarios where callers
> > > > > > retain pointers to various headers in the skb but fail to reload these
> > > > > > pointers after calling a function that may reallocate the data. This
> > > > > > type of bug can lead to memory corruption or crashes if the old,
> > > > > > now-invalid pointers are used.
> > > > > > 
> > > > > > By forcing reallocation through fault injection, we can stress-test code
> > > > > > paths and ensure proper pointer management after potential skb
> > > > > > reallocations.
> > > > > > 
> > > > > > Add a hook for fault injection in the following functions:
> > > > > > 
> > > > > >    * pskb_trim_rcsum()
> > > > > >    * pskb_may_pull_reason()
> > > > > >    * pskb_trim()
> > > > > > 
> > > > > > As the other fault injection mechanism, protect it under a debug Kconfig
> > > > > > called CONFIG_FAIL_SKB_FORCE_REALLOC.
> > > > > > 
> > > > > > This patch was *heavily* inspired by Jakub's proposal from:
> > > > > > https://lore.kernel.org/all/20240719174140.47a868e6@kernel.org/
> > > > > > 
> > > > > > CC: Akinobu Mita <akinobu.mita@gmail.com>
> > > > > > Suggested-by: Jakub Kicinski <kuba@kernel.org>
> > > > > > Signed-off-by: Breno Leitao <leitao@debian.org>
> > > > > 
> > > > > This new addition seems sensible.  It might be more useful to have a filter
> > > > > that allows you to specify things like protocol family.
> > > > 
> > > > I think it might make more sense to be network interface specific. For
> > > > instance, only fault inject in interface `ethx`.
> > > 
> > > Wasn't there some error injection infra that allows to optionally
> > > run bpf? That would cover the filtering problem. ALLOW_ERROR_INJECTION,
> > > maybe?
> > 
> > Isn't ALLOW_ERROR_INJECTION focused on specifying which function could
> > be faulted? I.e, you can mark that function as prone for fail injection?
> > 
> > In my the case I have in mind, I want to pass the interface that it
> > would have the error injected. For instance, only inject errors in
> > interface eth1. In this case, I am not sure ALLOW_ERROR_INJECTION will
> > help.
> 
> I've never looked into it and might be wrong, but I view
> ALLOW_ERROR_INJECTION'ed functions as a yes/no (err code) switch on
> steroids enabling debug code but not doing actual failing. E.g.

Right. I think there are two things here:

1) A function that could fail depending on your failure injection
request. For instance, you can force ALLOW_ERROR_INJECTION functions to
fail in certain conditions. See the documentation:

	/*
	 * Whitelist generating macro. Specify functions which can be error-injectable
	 * using this macro. (ALLOW_ERROR_INJECTION)

For instance, you can mark any random function as part error injectable.
This is not the case for the problem this patch is solving.

2) There are helpers that will query the fault injection mechanism to
decide if a given function should fail or not. This is exactly what
should_fail_bio() does. These are helpers that will eventually call
should_fail().

in my patch, this is done by skb_might_realloc() function, where it
calls should_fail(), and if the fault injection mechanism says it is
time to "fail", then it does (in this patch context, failure means
forcing the skb to be reallocated).

That said, it is unclear to me how ALLOW_ERROR_INJECTION could help to
solve the skb reallocation mechanism.

      reply	other threads:[~2024-10-08 11:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-02 11:32 [PATCH net-next] net: Implement fault injection forcing skb reallocation Breno Leitao
2024-10-02 14:23 ` kernel test robot
2024-10-02 15:33   ` Breno Leitao
2024-10-02 15:25 ` Kuniyuki Iwashima
2024-10-07 16:19   ` Breno Leitao
2024-10-05  4:38 ` Akinobu Mita
2024-10-07 16:20   ` Breno Leitao
2024-10-07 16:48     ` Pavel Begunkov
2024-10-07 17:09       ` Breno Leitao
2024-10-07 18:00         ` Pavel Begunkov
2024-10-08 11:09           ` Breno Leitao [this message]

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=ZwUDnGlhB09Widej@gmail.com \
    --to=leitao@debian.org \
    --cc=akinobu.mita@gmail.com \
    --cc=aleksander.lobakin@intel.com \
    --cc=almasrymina@google.com \
    --cc=asml.silence@gmail.com \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=willemb@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).