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
next prev 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