Re: [PATCH bpf 11/12] selftests/bpf: add __not_msg annotation for test_loader based tests

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Nov 17, 2023 at 1:53 PM Eduard Zingerman <eddyz87@xxxxxxxxx> wrote:
>
> On Fri, 2023-11-17 at 11:45 -0500, Andrii Nakryiko wrote:
> [...]
> > I think this implementation has an undesired surprising behavior.
> > Imagine you have a log like this:
> >
> > A
> > C
> > D
> > B
> >
> >
> > And you specify
> >
> > __msg("A")
> > __nomsg("B")
> > __msg("C")
> > __msg("D")
> > __msg("B")
> >
> > Log matches the spec, right? But your implementation will eagerly reject it.
> >
> > I think you can implement more coherent behavior if you only strstr()
> > __msg() specs, skipping __nomsg() first. But on each __msg one, if
> > successful, you go back and validate that there are no matches for all
> > __nomsg() specs that you skipped, taking into account matched
> > positions for current __msg() and last __msg() (or the start of the
> > log, of course).
> >
> > Not sure if I explained clearly, but the idea is to postpone __nomsg()
> > until we anchor ourselves between two __msg()s. And beginning/end of
> > verifier log are two other anchoring positions.
>
> Yes, makes total sense, thank you for spotting it. I can fix this and
> submit this patch as an unrelated change or just drop it, what would
> you prefer?
>
>

I think it's useful in general, I believe I had few cases where this
would be helpful. So submitting separately makes sense. But I think
this patch set doesn't need it if we can validate logic in last patch
without relying on this feature.





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux