public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Luiz Capitulino <luizcap@amazon.com>
Cc: Eduard Zingerman <eddyz87@gmail.com>,
	"sashal@kernel.org" <sashal@kernel.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	ast@kernel.org, gilad.reti@gmail.com,
	Mykola Lysenko <mykolal@fb.com>, andrii <andrii@kernel.org>
Subject: Re: [5.10, 5.15] New bpf kselftest failure
Date: Fri, 21 Jul 2023 07:30:04 +0200	[thread overview]
Message-ID: <2023072139-shriek-ranging-bd9e@gregkh> (raw)
In-Reply-To: <96204082-4cb8-038c-ac83-6b1a9f367f3b@amazon.com>

On Tue, Jul 18, 2023 at 10:58:45AM -0400, Luiz Capitulino wrote:
> 
> 
> On 2023-07-18 09:52, Eduard Zingerman wrote:
> 
> > 
> > 
> > 
> > On Tue, 2023-07-18 at 15:23 +0200, Greg KH wrote:
> > > On Tue, Jul 18, 2023 at 03:31:25PM +0300, Eduard Zingerman wrote:
> > > > On Tue, 2023-07-18 at 01:57 +0300, Eduard Zingerman wrote:
> > > > > [...]
> > > > > Still, when I cherry-pick [0,1,2,3] `./test_progs -a setget_sockopt` is failing.
> > > > > I'll investigate this failure but don't think I'll finish today.
> > > > > 
> > > > > ---
> > > > > 
> > > > > Alternatively, if the goal is to minimize amount of changes, we can
> > > > > disable or modify the 'precise: ST insn causing spi > allocated_stack'.
> > > > > 
> > > > > ---
> > > > > 
> > > > > Commits (in chronological order):
> > > > > [0] be2ef8161572 ("bpf: allow precision tracking for programs with subprogs")
> > > > > [1] f63181b6ae79 ("bpf: stop setting precise in current state")
> > > > > [2] 7a830b53c17b ("bpf: aggressively forget precise markings during state checkpointing")
> > > > > [3] 4f999b767769 ("selftests/bpf: make test_align selftest more robust")
> > > > > [4] 07d90c72efbe ("Merge branch 'BPF verifier precision tracking improvements'")
> > > > > [5] ecdf985d7615 ("bpf: track immediate values written to stack by BPF_ST instruction")
> > > > 
> > > > I made a mistake, while resolving merge conflict for [0] yesterday.
> > > > After correction the `./test_progs -a setget_sockopt` passes.
> > > > I also noted that the following tests fail on v6.1.36:
> > > > 
> > > >    ./test_progs -a sk_assign,fexit_bpf2bpf
> > > > 
> > > > These tests are fixed by back-porting the following upstream commits:
> > > > - 7ce878ca81bc ("selftests/bpf: Fix sk_assign on s390x")
> > > > - 63d78b7e8ca2 ("selftests/bpf: Workaround verification failure for fexit_bpf2bpf/func_replace_return_code")
> > > > 
> > > > I pushed modified version of v6.1.36 to my github account, it has
> > > > test_verifier, test_progs, test_progs-no_alu32 and test_maps passing
> > > > (on my x86 setup):
> > > > 
> > > >    https://github.com/eddyz87/bpf/commits/v6.1.36-with-fixes
> > > > 
> > > > Do you need any additional actions from my side?
> > > 
> > > I don't understand, what can I do with a github link?  Can you send us
> > > the patches backported so we can apply them to the stable tree?
> > 
> > Sorry, I'm not familiar with procedure for stable tree patches or
> > who decides what's being picked.
> 
> I'm by no means an authority here, but I'll try to help with what I would
> do myself.
> 
> > Looks like this situation is "Option 3" from [1], rigth?
> 
> Right.
> 
> > After reading that page I'm not sure:
> > - can I bundle all the necessary commits as a patch-set?
> 
> Yes.
> 
> > - a few commits need merging, others could be cherry-picked,
> >    is it possible to submit all of them with [ Upstream commit ... ] marks?
> 
> Yes.
> 
> > Also, as I wrote above, there are two possible solutions:
> > - backport above mentioned patches
> > - adjust the test log
> 
> I think we want to avoid deviating from upstream (Linus tree), but I'm not
> sure if there are valid exceptions.

backporting the mentioned patches is best, can someone send them to us
in email so that we can apply them?

thanks,

greg k-h

  reply	other threads:[~2023-07-21  5:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-17 13:04 [5.10, 5.15] New bpf kselftest failure Luiz Capitulino
2023-07-17 14:55 ` Eduard Zingerman
2023-07-17 14:59   ` Luiz Capitulino
2023-07-17 19:14     ` Eduard Zingerman
2023-07-17 22:57     ` Eduard Zingerman
2023-07-18 12:31       ` Eduard Zingerman
2023-07-18 13:23         ` Greg KH
2023-07-18 13:52           ` Eduard Zingerman
2023-07-18 14:58             ` Luiz Capitulino
2023-07-21  5:30               ` Greg KH [this message]
2023-07-21 14:34                 ` Eduard Zingerman
2023-07-18 14:06         ` Luiz Capitulino
2023-07-18 14:35           ` Eduard Zingerman
2023-07-18 14:39             ` Luiz Capitulino

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=2023072139-shriek-ranging-bd9e@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=eddyz87@gmail.com \
    --cc=gilad.reti@gmail.com \
    --cc=luizcap@amazon.com \
    --cc=mykolal@fb.com \
    --cc=sashal@kernel.org \
    --cc=stable@vger.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