BPF List
 help / color / mirror / Atom feed
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: David Vernet <void@manifault.com>, bpf@ietf.org, bpf@vger.kernel.org
Subject: Re: [Bpf] IETF 118 BPF WG summary
Date: Tue, 28 Nov 2023 10:43:36 +0100	[thread overview]
Message-ID: <539475.1701164616@dyas> (raw)
In-Reply-To: <20231127201817.GB5421@maniforge>

[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]


David Vernet <void@manifault.com> wrote:
    > We had a productive BPF working group meeting at IETF 118, and we
    > wanted to provide a summary to recap what was discussed.

David, this is a most excellent summary, thank you.
(I wasn't there, I had a conflict)

    > subset. Existing language MMs do not properly handle control
    > dependencies, and suffer from issues such as OOTA (Out-of-Thin-Air)
    > reads. The presentation outlined the control dependencies proposed for
    > various types of BPF instructions, such as atomics, jumps, etc.

I didn't know what an OOTA read was, but I think that hte first answer at:
  https://stackoverflow.com/questions/42588079/what-is-out-of-thin-air-safety

explained it, but I just wnated to be sure that this was the same term.

I think that we don't expect compilers emitting BPF code to do things like
the tearing example:
        void threadA() {
            g = 0xAB00;  // "tearing"
            g += 0x00CD;
        }

but an underlying BPF JIT might do this kind of thing, and of course, the
reads could be anywhere, and the variable could be written by C-code (or
RUST!).


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*




[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: David Vernet <void@manifault.com>, bpf@ietf.org, bpf@vger.kernel.org
Subject: Re: [Bpf] IETF 118 BPF WG summary
Date: Tue, 28 Nov 2023 10:43:36 +0100	[thread overview]
Message-ID: <539475.1701164616@dyas> (raw)
Message-ID: <20231128094336.hoSgvfkJy7GgxAhuODquDC3Y9XUGwlKWyI8seyBxLiE@z> (raw)
In-Reply-To: <20231127201817.GB5421@maniforge>


[-- Attachment #1.1: Type: text/plain, Size: 1273 bytes --]


David Vernet <void@manifault.com> wrote:
    > We had a productive BPF working group meeting at IETF 118, and we
    > wanted to provide a summary to recap what was discussed.

David, this is a most excellent summary, thank you.
(I wasn't there, I had a conflict)

    > subset. Existing language MMs do not properly handle control
    > dependencies, and suffer from issues such as OOTA (Out-of-Thin-Air)
    > reads. The presentation outlined the control dependencies proposed for
    > various types of BPF instructions, such as atomics, jumps, etc.

I didn't know what an OOTA read was, but I think that hte first answer at:
  https://stackoverflow.com/questions/42588079/what-is-out-of-thin-air-safety

explained it, but I just wnated to be sure that this was the same term.

I think that we don't expect compilers emitting BPF code to do things like
the tearing example:
        void threadA() {
            g = 0xAB00;  // "tearing"
            g += 0x00CD;
        }

but an underlying BPF JIT might do this kind of thing, and of course, the
reads could be anywhere, and the variable could be written by C-code (or
RUST!).


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*




[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

[-- Attachment #2: Type: text/plain, Size: 76 bytes --]

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

  parent reply	other threads:[~2023-11-28  9:43 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-27 20:18 IETF 118 BPF WG summary David Vernet
2023-11-27 20:18 ` [Bpf] " David Vernet
2023-11-28  9:43 ` Michael Richardson [this message]
2023-11-28  9:43   ` Michael Richardson
2023-12-02 19:51 ` BPF ISA conformance groups dthaler1968
2023-12-02 19:51   ` [Bpf] " dthaler1968=40googlemail.com
2023-12-07 21:51   ` David Vernet
2023-12-07 21:51     ` David Vernet
2023-12-10  3:10     ` Alexei Starovoitov
2023-12-10  3:10       ` Alexei Starovoitov
2023-12-10 21:13       ` Watson Ladd
2023-12-10 21:13         ` Watson Ladd
2023-12-12 21:45       ` David Vernet
2023-12-12 21:45         ` David Vernet
2023-12-12 22:01         ` dthaler1968
2023-12-12 22:01           ` dthaler1968=40googlemail.com
2023-12-12 22:55           ` Alexei Starovoitov
2023-12-12 22:55             ` Alexei Starovoitov
2023-12-12 23:35             ` David Vernet
2023-12-12 23:35               ` David Vernet
2023-12-13  1:32               ` Alexei Starovoitov
2023-12-13  1:32                 ` Alexei Starovoitov
2023-12-13 18:56                 ` David Vernet
2023-12-13 18:56                   ` David Vernet
2023-12-14  0:12                   ` Alexei Starovoitov
2023-12-14  0:12                     ` Alexei Starovoitov
2023-12-14 17:44                     ` David Vernet
2023-12-14 17:44                       ` David Vernet
2023-12-15  5:29                       ` Christoph Hellwig
2023-12-15  5:29                         ` Christoph Hellwig
2023-12-19  1:15                         ` Alexei Starovoitov
2023-12-19  1:15                           ` Alexei Starovoitov
2023-12-19 18:10                           ` dthaler1968
2023-12-19 18:10                             ` dthaler1968=40googlemail.com
2023-12-20  3:28                             ` Alexei Starovoitov
2023-12-20  3:28                               ` Alexei Starovoitov
2023-12-21  7:00                               ` Christoph Hellwig
2023-12-21  7:00                                 ` Christoph Hellwig
2024-01-05 22:07                                 ` David Vernet
2024-01-05 22:07                                   ` David Vernet
2024-01-08 16:00                                   ` Christoph Hellwig
2024-01-08 21:51                                     ` Alexei Starovoitov
2024-01-08 21:51                                       ` Alexei Starovoitov
2024-01-09 11:35                                       ` Jose E. Marchesi
2024-01-09 11:35                                         ` Jose E. Marchesi
2024-01-23 21:39                                         ` David Vernet
2024-01-23 21:39                                           ` David Vernet
2024-01-23 23:29                                           ` dthaler1968
2024-01-23 23:29                                             ` dthaler1968=40googlemail.com
2024-01-25  2:55                                             ` Alexei Starovoitov
2024-01-25  2:55                                               ` Alexei Starovoitov
2024-01-09 15:26                                       ` Christoph Hellwig
2023-12-19 18:15                 ` dthaler1968
2023-12-19 18:15                   ` dthaler1968=40googlemail.com
2023-12-13 16:59         ` Christoph Hellwig
2023-12-13 16:59           ` Christoph Hellwig

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=539475.1701164616@dyas \
    --to=mcr+ietf@sandelman.ca \
    --cc=bpf@ietf.org \
    --cc=bpf@vger.kernel.org \
    --cc=void@manifault.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