All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrei Matei <andreimatei1@gmail.com>
To: Yonghong Song <yhs@fb.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next 2/2] selftest/bpf: fix rst formatting in readme
Date: Tue, 24 Nov 2020 13:29:57 -0500	[thread overview]
Message-ID: <CABWLseujFiAtv5fWDwxjL__+6MSxrcYRp9ejkp6dC4=EM1mNQw@mail.gmail.com> (raw)
In-Reply-To: <dbb95d56-0700-c8b6-1f6b-d632144075bb@fb.com>

Hi Yonghong! Thanks for looking at my patch!
This is my first patch to the Linux kernel / first time using an
email-based patch workflow, so I don't know what I'm doing. I hope to
contribute more to BPF in the future, though.

The patches apply fine to me on bpf-next master (am I supposed to be
targeting a different branch?), and I've asked someone else to confirm
too. I've tested with your exact git version. I have a theory about
what might be going wrong for you, see below.

Here's what I'm doing:

# prove I'm on bpf-next master
$ git show | head -n 5
commit 91b2db27d3ff9ad29e8b3108dfbf1e2f49fe9bd3
Author: Song Liu <songliubraving@fb.com>
Date:   Thu Nov 19 16:28:33 2020 -0800

    bpf: Simplify task_file_seq_get_next()

# Download the patches - these are the "raw" links published by
lore.kernel.org for each of the two emails.
$ curl https://lore.kernel.org/bpf/20201122022205.57229-1-andreimatei1@gmail.com/raw
> p1.patch
$ curl https://lore.kernel.org/bpf/20201122022205.57229-2-andreimatei1@gmail.com/raw
> p2.patch
$ git am p1.patch
Applying: selftest/bpf: fix link in readme
$ git am p2.patch
Applying: selftest/bpf: fix rst formatting in readme

So, it all "works for me". The patches were produced with `git
format-patch` and sent with `git send-email`. Please let me know if I
was supposed to do something else.

With the risk of continuing to not know what I'm talking about, I
perhaps have a guess about why the patches don't apply for you: if you
simply copy-pasted the email into your p2.txt, that might not apply
because a space might be lost from the end of one of the one lines
that I'm deleting. The patch has a line that reads: "-This is due to a
llvm BPF backend bug. The fix ". Notice the space at the end of the
line. At least Gmail doesn't render that space, so if I simply
copy-paste the patch from my browser, I end up with a corrupted line
and so it doesn't apply. Perhaps that's your situation?

Thanks Yonghong, I appreciate your time!

- Andrei

On Mon, Nov 23, 2020 at 2:22 AM Yonghong Song <yhs@fb.com> wrote:
>
>
>
> On 11/21/20 6:22 PM, Andrei Matei wrote:
> > A couple of places in the readme had invalid rst formatting causing the
> > rendering to be off. This patch fixes them with minimal edits.
> >
> > Signed-off-by: Andrei Matei <andreimatei1@gmail.com>
> > ---
> >   tools/testing/selftests/bpf/README.rst | 28 ++++++++++++++------------
> >   1 file changed, 15 insertions(+), 13 deletions(-)
>
> I cannot apply patch #2 with my current bpf-next branch.
>
> -bash-4.4$ git apply ~/p1.txt
> -bash-4.4$ git apply ~/p2.txt
> /home/yhs/p2.txt:34: trailing whitespace.
> __
> https://reviews.llvm.org/D85570
>
> /home/yhs/p2.txt:52: trailing whitespace.
> __
> https://reviews.llvm.org/D78466
>
> /home/yhs/p2.txt:70: trailing whitespace.
> .. _0:
> https://reviews.llvm.org/D74572
>
> /home/yhs/p2.txt:71: trailing whitespace.
> .. _1:
> https://reviews.llvm.org/D74668
>
> /home/yhs/p2.txt:72: trailing whitespace.
> .. _2:
> https://reviews.llvm.org/D85174
>
> error: patch failed: tools/testing/selftests/bpf/README.rst:33
> error: tools/testing/selftests/bpf/README.rst: patch does not apply
> -bash-4.4$ git --version
> git version 2.24.1
> -bash-4.4$
>
> Could you help check what is the issue? Maybe the links are presented
> differently in the patch vs. in the README.rst?
>
> >
> > diff --git a/tools/testing/selftests/bpf/README.rst b/tools/testing/selftests/bpf/README.rst
> > index 3b8d8885892d..ca064180d4d0 100644
> > --- a/tools/testing/selftests/bpf/README.rst
> > +++ b/tools/testing/selftests/bpf/README.rst
> > @@ -33,11 +33,12 @@ The verifier will reject such code with above error.
> >   At insn 18 the r7 is indeed unbounded. The later insn 19 checks the bounds and
> >   the insn 20 undoes map_value addition. It is currently impossible for the
> >   verifier to understand such speculative pointer arithmetic.
> > -Hence
> > -    https://reviews.llvm.org/D85570
> > -addresses it on the compiler side. It was committed on llvm 12.
> > +Hence `this patch`__ addresses it on the compiler side. It was committed on llvm 12.
> > +
> > +__ https://reviews.llvm.org/D85570
> >
> >   The corresponding C code
> > +
> >   .. code-block:: c
> >
> >     for (int i = 0; i < MAX_CGROUPS_PATH_DEPTH; i++) {
> > @@ -80,10 +81,11 @@ The symptom for ``bpf_iter/netlink`` looks like
> >     17: (7b) *(u64 *)(r7 +0) = r2
> >     only read is supported
> >
> > -This is due to a llvm BPF backend bug. The fix
> > -  https://reviews.llvm.org/D78466
> > +This is due to a llvm BPF backend bug. `The fix`__
> >   has been pushed to llvm 10.x release branch and will be
> > -available in 10.0.1. The fix is available in llvm 11.0.0 trunk.
> > +available in 10.0.1. The patch is available in llvm 11.0.0 trunk.
> > +
> > +__  https://reviews.llvm.org/D78466
> >
> >   BPF CO-RE-based tests and Clang version
> >   =======================================
> > @@ -97,11 +99,11 @@ them to Clang/LLVM. These sub-tests are going to be skipped if Clang is too
> >   old to support them, they shouldn't cause build failures or runtime test
> >   failures:
> >
> > -  - __builtin_btf_type_id() ([0], [1], [2]);
> > -  - __builtin_preserve_type_info(), __builtin_preserve_enum_value() ([3], [4]).
> > +- __builtin_btf_type_id() [0_, 1_, 2_];
> > +- __builtin_preserve_type_info(), __builtin_preserve_enum_value() [3_, 4_].
> >
> > -  [0] https://reviews.llvm.org/D74572
> > -  [1] https://reviews.llvm.org/D74668
> > -  [2] https://reviews.llvm.org/D85174
> > -  [3] https://reviews.llvm.org/D83878
> > -  [4] https://reviews.llvm.org/D83242
> > +.. _0: https://reviews.llvm.org/D74572
> > +.. _1: https://reviews.llvm.org/D74668
> > +.. _2: https://reviews.llvm.org/D85174
> > +.. _3: https://reviews.llvm.org/D83878
> > +.. _4: https://reviews.llvm.org/D83242
> >

  reply	other threads:[~2020-11-24 18:30 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-22  2:22 [PATCH bpf-next 1/2] selftest/bpf: fix link in readme Andrei Matei
2020-11-22  2:22 ` [PATCH bpf-next 2/2] selftest/bpf: fix rst formatting " Andrei Matei
2020-11-23  7:22   ` Yonghong Song
2020-11-24 18:29     ` Andrei Matei [this message]
2020-11-24 19:09       ` Yonghong Song
2020-11-24 19:11   ` Yonghong Song
2020-11-24 19:10 ` [PATCH bpf-next 1/2] selftest/bpf: fix link " Yonghong Song
2020-11-24 22:10 ` patchwork-bot+netdevbpf

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='CABWLseujFiAtv5fWDwxjL__+6MSxrcYRp9ejkp6dC4=EM1mNQw@mail.gmail.com' \
    --to=andreimatei1@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=yhs@fb.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.