* ISA: BPF_MSH and deprecated packet access instructions @ 2024-01-27 18:50 ` dthaler1968=40googlemail.com 0 siblings, 0 replies; 32+ messages in thread From: dthaler1968 @ 2024-01-27 18:50 UTC (permalink / raw) To: 'Yonghong Song'; +Cc: bpf, bpf Under "Load and store instructions", various mode modifiers are documented. I notice that BPF_MSH (0xa0) is not documented, but appears to be in use in various projects, including Linux, BSD, seccomp, etc. and is even documented in various books such as https://www.google.com/books/edition/Programming_Linux_Hacker_Tools_Uncovere d/yqHVAwAAQBAJ?hl=en&gbpv=1&dq=%22BPF_MSH%22&pg=PA129&printsec=frontcover Should we document it as deprecated and add it to the set of deprecated instructions (the legacy conformance group) like BPF_ABS and BPF_IND already are? Also, for purposes of the IANA registry of instructions where we list which opcodes are "(deprecated, implementation-specific)", I currently list all possible BPF_ABS and BPF_IND opcodes regardless of whether they were ever used (I didn't check which were used and which might not have been), so I could just list all possible BPF_MSH opcodes similarly. But if we know that some were never used then I don't need to do so, so I guess I should ask: do we have a list of which combinations were actually used or should we continue to just deprecate all combinations? As an example, https://github.com/seccomp/libseccomp/blob/main/tools/scmp_bpf_disasm.c#L68 lists 6 variants of BPF_MSH: LD and LDX, for B, H, and W (but not DW). Other sources like the book page referenced above, and the BSD man page, list only BPF_LDX | BPF_B | BPF_MSH, which is in Linux sources such as https://elixir.bootlin.com/linux/v6.8-rc1/source/lib/test_bpf.c#L368 So, should we list the DW variants as deprecated, or never assigned? Should we list the H, W, and LD variants as deprecated, or never assigned? What about DW and LDX variants of BPF_IND and BPF_ABS? Dave ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bpf] ISA: BPF_MSH and deprecated packet access instructions @ 2024-01-27 18:50 ` dthaler1968=40googlemail.com 0 siblings, 0 replies; 32+ messages in thread From: dthaler1968=40googlemail.com @ 2024-01-27 18:50 UTC (permalink / raw) To: 'Yonghong Song'; +Cc: bpf, bpf Under "Load and store instructions", various mode modifiers are documented. I notice that BPF_MSH (0xa0) is not documented, but appears to be in use in various projects, including Linux, BSD, seccomp, etc. and is even documented in various books such as https://www.google.com/books/edition/Programming_Linux_Hacker_Tools_Uncovere d/yqHVAwAAQBAJ?hl=en&gbpv=1&dq=%22BPF_MSH%22&pg=PA129&printsec=frontcover Should we document it as deprecated and add it to the set of deprecated instructions (the legacy conformance group) like BPF_ABS and BPF_IND already are? Also, for purposes of the IANA registry of instructions where we list which opcodes are "(deprecated, implementation-specific)", I currently list all possible BPF_ABS and BPF_IND opcodes regardless of whether they were ever used (I didn't check which were used and which might not have been), so I could just list all possible BPF_MSH opcodes similarly. But if we know that some were never used then I don't need to do so, so I guess I should ask: do we have a list of which combinations were actually used or should we continue to just deprecate all combinations? As an example, https://github.com/seccomp/libseccomp/blob/main/tools/scmp_bpf_disasm.c#L68 lists 6 variants of BPF_MSH: LD and LDX, for B, H, and W (but not DW). Other sources like the book page referenced above, and the BSD man page, list only BPF_LDX | BPF_B | BPF_MSH, which is in Linux sources such as https://elixir.bootlin.com/linux/v6.8-rc1/source/lib/test_bpf.c#L368 So, should we list the DW variants as deprecated, or never assigned? Should we list the H, W, and LD variants as deprecated, or never assigned? What about DW and LDX variants of BPF_IND and BPF_ABS? Dave -- Bpf mailing list Bpf@ietf.org https://www.ietf.org/mailman/listinfo/bpf ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions @ 2024-01-27 18:59 ` Jose E. Marchesi 0 siblings, 0 replies; 32+ messages in thread From: Jose E. Marchesi @ 2024-01-27 18:59 UTC (permalink / raw) To: dthaler1968=40googlemail.com; +Cc: 'Yonghong Song', bpf, bpf We do not support any load/sotre instruction with mode BPF_MSH in binutils. Should we do so? What are these? > Under "Load and store instructions", various mode modifiers are documented. > I notice that BPF_MSH (0xa0) is not documented, but appears to be in use in > various projects, including Linux, BSD, seccomp, etc. and is even documented > in various books such as > https://www.google.com/books/edition/Programming_Linux_Hacker_Tools_Uncovere > d/yqHVAwAAQBAJ?hl=en&gbpv=1&dq=%22BPF_MSH%22&pg=PA129&printsec=frontcover > > Should we document it as deprecated and add it to the set of deprecated > instructions (the legacy conformance group) like BPF_ABS and BPF_IND > already are? > > Also, for purposes of the IANA registry of instructions where we list which > opcodes are "(deprecated, implementation-specific)", I currently list all > possible BPF_ABS and BPF_IND opcodes regardless of whether they were > ever used (I didn't check which were used and which might not have been), > so I could just list all possible BPF_MSH opcodes similarly. But if we know > that some were never used then I don't need to do so, so I guess I should > ask: > do we have a list of which combinations were actually used or should we > continue to just deprecate all combinations? > > As an example, > https://github.com/seccomp/libseccomp/blob/main/tools/scmp_bpf_disasm.c#L68 > lists 6 variants of BPF_MSH: LD and LDX, for B, H, and W (but not DW). > Other sources like the book page referenced above, and the BSD man page, > list only BPF_LDX | BPF_B | BPF_MSH, which is in Linux sources such as > https://elixir.bootlin.com/linux/v6.8-rc1/source/lib/test_bpf.c#L368 > > So, should we list the DW variants as deprecated, or never assigned? > Should we list the H, W, and LD variants as deprecated, or never assigned? > > What about DW and LDX variants of BPF_IND and BPF_ABS? > > Dave ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions @ 2024-01-27 18:59 ` Jose E. Marchesi 0 siblings, 0 replies; 32+ messages in thread From: Jose E. Marchesi @ 2024-01-27 18:59 UTC (permalink / raw) To: dthaler1968=40googlemail.com; +Cc: 'Yonghong Song', bpf, bpf We do not support any load/sotre instruction with mode BPF_MSH in binutils. Should we do so? What are these? > Under "Load and store instructions", various mode modifiers are documented. > I notice that BPF_MSH (0xa0) is not documented, but appears to be in use in > various projects, including Linux, BSD, seccomp, etc. and is even documented > in various books such as > https://www.google.com/books/edition/Programming_Linux_Hacker_Tools_Uncovere > d/yqHVAwAAQBAJ?hl=en&gbpv=1&dq=%22BPF_MSH%22&pg=PA129&printsec=frontcover > > Should we document it as deprecated and add it to the set of deprecated > instructions (the legacy conformance group) like BPF_ABS and BPF_IND > already are? > > Also, for purposes of the IANA registry of instructions where we list which > opcodes are "(deprecated, implementation-specific)", I currently list all > possible BPF_ABS and BPF_IND opcodes regardless of whether they were > ever used (I didn't check which were used and which might not have been), > so I could just list all possible BPF_MSH opcodes similarly. But if we know > that some were never used then I don't need to do so, so I guess I should > ask: > do we have a list of which combinations were actually used or should we > continue to just deprecate all combinations? > > As an example, > https://github.com/seccomp/libseccomp/blob/main/tools/scmp_bpf_disasm.c#L68 > lists 6 variants of BPF_MSH: LD and LDX, for B, H, and W (but not DW). > Other sources like the book page referenced above, and the BSD man page, > list only BPF_LDX | BPF_B | BPF_MSH, which is in Linux sources such as > https://elixir.bootlin.com/linux/v6.8-rc1/source/lib/test_bpf.c#L368 > > So, should we list the DW variants as deprecated, or never assigned? > Should we list the H, W, and LD variants as deprecated, or never assigned? > > What about DW and LDX variants of BPF_IND and BPF_ABS? > > Dave -- Bpf mailing list Bpf@ietf.org https://www.ietf.org/mailman/listinfo/bpf ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions @ 2024-01-27 19:06 ` Jose E. Marchesi 0 siblings, 0 replies; 32+ messages in thread From: Jose E. Marchesi @ 2024-01-27 19:06 UTC (permalink / raw) To: dthaler1968=40googlemail.com; +Cc: 'Yonghong Song', bpf, bpf > We do not support any load/sotre instruction with mode BPF_MSH in > binutils. Should we do so? What are these? > >> Under "Load and store instructions", various mode modifiers are documented. >> I notice that BPF_MSH (0xa0) is not documented, but appears to be in use in >> various projects, including Linux, BSD, seccomp, etc. and is even documented >> in various books such as >> https://www.google.com/books/edition/Programming_Linux_Hacker_Tools_Uncovere >> d/yqHVAwAAQBAJ?hl=en&gbpv=1&dq=%22BPF_MSH%22&pg=PA129&printsec=frontcover >> >> Should we document it as deprecated and add it to the set of deprecated >> instructions (the legacy conformance group) like BPF_ABS and BPF_IND >> already are? >> >> Also, for purposes of the IANA registry of instructions where we list which >> opcodes are "(deprecated, implementation-specific)", I currently list all >> possible BPF_ABS and BPF_IND opcodes regardless of whether they were >> ever used (I didn't check which were used and which might not have been), >> so I could just list all possible BPF_MSH opcodes similarly. But if we know >> that some were never used then I don't need to do so, so I guess I should >> ask: >> do we have a list of which combinations were actually used or should we >> continue to just deprecate all combinations? >> >> As an example, >> https://github.com/seccomp/libseccomp/blob/main/tools/scmp_bpf_disasm.c#L68 >> lists 6 variants of BPF_MSH: LD and LDX, for B, H, and W (but not DW). >> Other sources like the book page referenced above, and the BSD man page, >> list only BPF_LDX | BPF_B | BPF_MSH, which is in Linux sources such as >> https://elixir.bootlin.com/linux/v6.8-rc1/source/lib/test_bpf.c#L368 >> >> So, should we list the DW variants as deprecated, or never assigned? >> Should we list the H, W, and LD variants as deprecated, or never assigned? >> >> What about DW and LDX variants of BPF_IND and BPF_ABS? These we support: /* Absolute load instructions, designed to be used in socket filters. */ {BPF_INSN_LDABSB, "ldabsb%W%i32", "r0 = * ( u8 * ) skb [ %i32 ]", BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_B|BPF_MODE_ABS}, {BPF_INSN_LDABSH, "ldabsh%W%i32", "r0 = * ( u16 * ) skb [ %i32 ]", BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_H|BPF_MODE_ABS}, {BPF_INSN_LDABSW, "ldabsw%W%i32", "r0 = * ( u32 * ) skb [ %i32 ]", BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_W|BPF_MODE_ABS}, {BPF_INSN_LDABSDW, "ldabsdw%W%i32", "r0 = * ( u64 * ) skb [ %i32 ]", BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_DW|BPF_MODE_ABS}, /* Generic load instructions (to register.) */ {BPF_INSN_LDXB, "ldxb%W%dr , [ %sr %o16 ]", "%dr = * ( u8 * ) ( %sr %o16 )", BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_B|BPF_MODE_MEM}, {BPF_INSN_LDXH, "ldxh%W%dr , [ %sr %o16 ]", "%dr = * ( u16 * ) ( %sr %o16 )", BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_H|BPF_MODE_MEM}, {BPF_INSN_LDXW, "ldxw%W%dr , [ %sr %o16 ]", "%dr = * ( u32 * ) ( %sr %o16 )", BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_W|BPF_MODE_MEM}, {BPF_INSN_LDXDW, "ldxdw%W%dr , [ %sr %o16 ]","%dr = * ( u64 * ) ( %sr %o16 )", BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_DW|BPF_MODE_MEM}, >> Dave -- Bpf mailing list Bpf@ietf.org https://www.ietf.org/mailman/listinfo/bpf ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions @ 2024-01-27 19:06 ` Jose E. Marchesi 0 siblings, 0 replies; 32+ messages in thread From: Jose E. Marchesi @ 2024-01-27 19:06 UTC (permalink / raw) To: dthaler1968=40googlemail.com; +Cc: 'Yonghong Song', bpf, bpf > We do not support any load/sotre instruction with mode BPF_MSH in > binutils. Should we do so? What are these? > >> Under "Load and store instructions", various mode modifiers are documented. >> I notice that BPF_MSH (0xa0) is not documented, but appears to be in use in >> various projects, including Linux, BSD, seccomp, etc. and is even documented >> in various books such as >> https://www.google.com/books/edition/Programming_Linux_Hacker_Tools_Uncovere >> d/yqHVAwAAQBAJ?hl=en&gbpv=1&dq=%22BPF_MSH%22&pg=PA129&printsec=frontcover >> >> Should we document it as deprecated and add it to the set of deprecated >> instructions (the legacy conformance group) like BPF_ABS and BPF_IND >> already are? >> >> Also, for purposes of the IANA registry of instructions where we list which >> opcodes are "(deprecated, implementation-specific)", I currently list all >> possible BPF_ABS and BPF_IND opcodes regardless of whether they were >> ever used (I didn't check which were used and which might not have been), >> so I could just list all possible BPF_MSH opcodes similarly. But if we know >> that some were never used then I don't need to do so, so I guess I should >> ask: >> do we have a list of which combinations were actually used or should we >> continue to just deprecate all combinations? >> >> As an example, >> https://github.com/seccomp/libseccomp/blob/main/tools/scmp_bpf_disasm.c#L68 >> lists 6 variants of BPF_MSH: LD and LDX, for B, H, and W (but not DW). >> Other sources like the book page referenced above, and the BSD man page, >> list only BPF_LDX | BPF_B | BPF_MSH, which is in Linux sources such as >> https://elixir.bootlin.com/linux/v6.8-rc1/source/lib/test_bpf.c#L368 >> >> So, should we list the DW variants as deprecated, or never assigned? >> Should we list the H, W, and LD variants as deprecated, or never assigned? >> >> What about DW and LDX variants of BPF_IND and BPF_ABS? These we support: /* Absolute load instructions, designed to be used in socket filters. */ {BPF_INSN_LDABSB, "ldabsb%W%i32", "r0 = * ( u8 * ) skb [ %i32 ]", BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_B|BPF_MODE_ABS}, {BPF_INSN_LDABSH, "ldabsh%W%i32", "r0 = * ( u16 * ) skb [ %i32 ]", BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_H|BPF_MODE_ABS}, {BPF_INSN_LDABSW, "ldabsw%W%i32", "r0 = * ( u32 * ) skb [ %i32 ]", BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_W|BPF_MODE_ABS}, {BPF_INSN_LDABSDW, "ldabsdw%W%i32", "r0 = * ( u64 * ) skb [ %i32 ]", BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_DW|BPF_MODE_ABS}, /* Generic load instructions (to register.) */ {BPF_INSN_LDXB, "ldxb%W%dr , [ %sr %o16 ]", "%dr = * ( u8 * ) ( %sr %o16 )", BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_B|BPF_MODE_MEM}, {BPF_INSN_LDXH, "ldxh%W%dr , [ %sr %o16 ]", "%dr = * ( u16 * ) ( %sr %o16 )", BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_H|BPF_MODE_MEM}, {BPF_INSN_LDXW, "ldxw%W%dr , [ %sr %o16 ]", "%dr = * ( u32 * ) ( %sr %o16 )", BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_W|BPF_MODE_MEM}, {BPF_INSN_LDXDW, "ldxdw%W%dr , [ %sr %o16 ]","%dr = * ( u64 * ) ( %sr %o16 )", BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_DW|BPF_MODE_MEM}, >> Dave ^ permalink raw reply [flat|nested] 32+ messages in thread
* RE: [Bpf] ISA: BPF_MSH and deprecated packet access instructions @ 2024-01-28 6:59 ` dthaler1968=40googlemail.com 0 siblings, 0 replies; 32+ messages in thread From: dthaler1968 @ 2024-01-28 6:59 UTC (permalink / raw) To: 'Jose E. Marchesi'; +Cc: 'Yonghong Song', bpf, bpf I asked: > >> What about DW and LDX variants of BPF_IND and BPF_ABS? Jose E. Marchesi <jose.marchesi@oracle.com> wrote: > These we support: > > /* Absolute load instructions, designed to be used in socket filters. */ > {BPF_INSN_LDABSB, "ldabsb%W%i32", "r0 = * ( u8 * ) skb [ %i32 ]", > BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_B|BPF_MODE_ABS}, > {BPF_INSN_LDABSH, "ldabsh%W%i32", "r0 = * ( u16 * ) skb [ %i32 ]", > BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_H|BPF_MODE_ABS}, > {BPF_INSN_LDABSW, "ldabsw%W%i32", "r0 = * ( u32 * ) skb [ %i32 ]", > BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_W|BPF_MODE_ABS}, > {BPF_INSN_LDABSDW, "ldabsdw%W%i32", "r0 = * ( u64 * ) skb [ %i32 ]", > BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_DW|BPF_MODE_ABS}, > > /* Generic load instructions (to register.) */ > {BPF_INSN_LDXB, "ldxb%W%dr , [ %sr %o16 ]", "%dr = * ( u8 * ) ( %sr %o16 )", > BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_B|BPF_MODE_MEM}, > {BPF_INSN_LDXH, "ldxh%W%dr , [ %sr %o16 ]", "%dr = * ( u16 * ) ( %sr %o16 > )", > BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_H|BPF_MODE_MEM}, > {BPF_INSN_LDXW, "ldxw%W%dr , [ %sr %o16 ]", "%dr = * ( u32 * ) ( %sr %o16 > )", > BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_W|BPF_MODE_MEM}, > {BPF_INSN_LDXDW, "ldxdw%W%dr , [ %sr %o16 ]","%dr = * ( u64 * ) ( %sr > %o16 )", > BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_DW|BPF_MODE_MEM}, Yonghong Song <yonghong.song@linux.dev> wrote: > I don't know how to do proper wording in the standard. But DW and LDX > variants of BPF_IND/BPF_ABS are not supported by verifier for now and they > are considered illegal insns. Although the Linux verifier doesn't support them, the fact that gcc does support them tells me that it's probably safest to list the DW and LDX variants as deprecated as well, which is what the draft already did in the appendix so that's good (nothing to change there, I think). Dave ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions @ 2024-01-28 6:59 ` dthaler1968=40googlemail.com 0 siblings, 0 replies; 32+ messages in thread From: dthaler1968=40googlemail.com @ 2024-01-28 6:59 UTC (permalink / raw) To: 'Jose E. Marchesi'; +Cc: 'Yonghong Song', bpf, bpf I asked: > >> What about DW and LDX variants of BPF_IND and BPF_ABS? Jose E. Marchesi <jose.marchesi@oracle.com> wrote: > These we support: > > /* Absolute load instructions, designed to be used in socket filters. */ > {BPF_INSN_LDABSB, "ldabsb%W%i32", "r0 = * ( u8 * ) skb [ %i32 ]", > BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_B|BPF_MODE_ABS}, > {BPF_INSN_LDABSH, "ldabsh%W%i32", "r0 = * ( u16 * ) skb [ %i32 ]", > BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_H|BPF_MODE_ABS}, > {BPF_INSN_LDABSW, "ldabsw%W%i32", "r0 = * ( u32 * ) skb [ %i32 ]", > BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_W|BPF_MODE_ABS}, > {BPF_INSN_LDABSDW, "ldabsdw%W%i32", "r0 = * ( u64 * ) skb [ %i32 ]", > BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_DW|BPF_MODE_ABS}, > > /* Generic load instructions (to register.) */ > {BPF_INSN_LDXB, "ldxb%W%dr , [ %sr %o16 ]", "%dr = * ( u8 * ) ( %sr %o16 )", > BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_B|BPF_MODE_MEM}, > {BPF_INSN_LDXH, "ldxh%W%dr , [ %sr %o16 ]", "%dr = * ( u16 * ) ( %sr %o16 > )", > BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_H|BPF_MODE_MEM}, > {BPF_INSN_LDXW, "ldxw%W%dr , [ %sr %o16 ]", "%dr = * ( u32 * ) ( %sr %o16 > )", > BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_W|BPF_MODE_MEM}, > {BPF_INSN_LDXDW, "ldxdw%W%dr , [ %sr %o16 ]","%dr = * ( u64 * ) ( %sr > %o16 )", > BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_DW|BPF_MODE_MEM}, Yonghong Song <yonghong.song@linux.dev> wrote: > I don't know how to do proper wording in the standard. But DW and LDX > variants of BPF_IND/BPF_ABS are not supported by verifier for now and they > are considered illegal insns. Although the Linux verifier doesn't support them, the fact that gcc does support them tells me that it's probably safest to list the DW and LDX variants as deprecated as well, which is what the draft already did in the appendix so that's good (nothing to change there, I think). Dave -- Bpf mailing list Bpf@ietf.org https://www.ietf.org/mailman/listinfo/bpf ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions @ 2024-01-28 23:59 ` Alexei Starovoitov 0 siblings, 0 replies; 32+ messages in thread From: Alexei Starovoitov @ 2024-01-28 23:59 UTC (permalink / raw) To: Dave Thaler; +Cc: Jose E. Marchesi, Yonghong Song, bpf, bpf On Sat, Jan 27, 2024 at 10:59 PM <dthaler1968@googlemail.com> wrote: > > I asked: > > >> What about DW and LDX variants of BPF_IND and BPF_ABS? > > Jose E. Marchesi <jose.marchesi@oracle.com> wrote: > > These we support: > > > > /* Absolute load instructions, designed to be used in socket filters. > */ > > {BPF_INSN_LDABSB, "ldabsb%W%i32", "r0 = * ( u8 * ) skb [ %i32 ]", > > BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_B|BPF_MODE_ABS}, > > {BPF_INSN_LDABSH, "ldabsh%W%i32", "r0 = * ( u16 * ) skb [ %i32 ]", > > BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_H|BPF_MODE_ABS}, > > {BPF_INSN_LDABSW, "ldabsw%W%i32", "r0 = * ( u32 * ) skb [ %i32 ]", > > BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_W|BPF_MODE_ABS}, > > {BPF_INSN_LDABSDW, "ldabsdw%W%i32", "r0 = * ( u64 * ) skb [ %i32 ]", > > BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_DW|BPF_MODE_ABS}, > > > > /* Generic load instructions (to register.) */ > > {BPF_INSN_LDXB, "ldxb%W%dr , [ %sr %o16 ]", "%dr = * ( u8 * ) ( %sr %o16 > )", > > BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_B|BPF_MODE_MEM}, > > {BPF_INSN_LDXH, "ldxh%W%dr , [ %sr %o16 ]", "%dr = * ( u16 * ) ( %sr > %o16 > > )", > > BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_H|BPF_MODE_MEM}, > > {BPF_INSN_LDXW, "ldxw%W%dr , [ %sr %o16 ]", "%dr = * ( u32 * ) ( %sr > %o16 > > )", > > BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_W|BPF_MODE_MEM}, > > {BPF_INSN_LDXDW, "ldxdw%W%dr , [ %sr %o16 ]","%dr = * ( u64 * ) ( %sr > > %o16 )", > > BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_DW|BPF_MODE_MEM}, > > Yonghong Song <yonghong.song@linux.dev> wrote: > > I don't know how to do proper wording in the standard. But DW and LDX > > variants of BPF_IND/BPF_ABS are not supported by verifier for now and they > > are considered illegal insns. > > Although the Linux verifier doesn't support them, the fact that gcc does > support > them tells me that it's probably safest to list the DW and LDX variants as > deprecated as well, which is what the draft already did in the appendix so > that's good (nothing to change there, I think). DW never existed in classic bpf, so abs/ind never had DW flavor. If some assembler/compiler decided to "support" them it's on them. The standard must not list such things as deprecated. They never existed. So nothing is deprecated. Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed. It's a legacy insn. Just like abs/ind. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions @ 2024-01-28 23:59 ` Alexei Starovoitov 0 siblings, 0 replies; 32+ messages in thread From: Alexei Starovoitov @ 2024-01-28 23:59 UTC (permalink / raw) To: Dave Thaler; +Cc: Jose E. Marchesi, Yonghong Song, bpf, bpf On Sat, Jan 27, 2024 at 10:59 PM <dthaler1968@googlemail.com> wrote: > > I asked: > > >> What about DW and LDX variants of BPF_IND and BPF_ABS? > > Jose E. Marchesi <jose.marchesi@oracle.com> wrote: > > These we support: > > > > /* Absolute load instructions, designed to be used in socket filters. > */ > > {BPF_INSN_LDABSB, "ldabsb%W%i32", "r0 = * ( u8 * ) skb [ %i32 ]", > > BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_B|BPF_MODE_ABS}, > > {BPF_INSN_LDABSH, "ldabsh%W%i32", "r0 = * ( u16 * ) skb [ %i32 ]", > > BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_H|BPF_MODE_ABS}, > > {BPF_INSN_LDABSW, "ldabsw%W%i32", "r0 = * ( u32 * ) skb [ %i32 ]", > > BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_W|BPF_MODE_ABS}, > > {BPF_INSN_LDABSDW, "ldabsdw%W%i32", "r0 = * ( u64 * ) skb [ %i32 ]", > > BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_DW|BPF_MODE_ABS}, > > > > /* Generic load instructions (to register.) */ > > {BPF_INSN_LDXB, "ldxb%W%dr , [ %sr %o16 ]", "%dr = * ( u8 * ) ( %sr %o16 > )", > > BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_B|BPF_MODE_MEM}, > > {BPF_INSN_LDXH, "ldxh%W%dr , [ %sr %o16 ]", "%dr = * ( u16 * ) ( %sr > %o16 > > )", > > BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_H|BPF_MODE_MEM}, > > {BPF_INSN_LDXW, "ldxw%W%dr , [ %sr %o16 ]", "%dr = * ( u32 * ) ( %sr > %o16 > > )", > > BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_W|BPF_MODE_MEM}, > > {BPF_INSN_LDXDW, "ldxdw%W%dr , [ %sr %o16 ]","%dr = * ( u64 * ) ( %sr > > %o16 )", > > BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_DW|BPF_MODE_MEM}, > > Yonghong Song <yonghong.song@linux.dev> wrote: > > I don't know how to do proper wording in the standard. But DW and LDX > > variants of BPF_IND/BPF_ABS are not supported by verifier for now and they > > are considered illegal insns. > > Although the Linux verifier doesn't support them, the fact that gcc does > support > them tells me that it's probably safest to list the DW and LDX variants as > deprecated as well, which is what the draft already did in the appendix so > that's good (nothing to change there, I think). DW never existed in classic bpf, so abs/ind never had DW flavor. If some assembler/compiler decided to "support" them it's on them. The standard must not list such things as deprecated. They never existed. So nothing is deprecated. Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed. It's a legacy insn. Just like abs/ind. -- Bpf mailing list Bpf@ietf.org https://www.ietf.org/mailman/listinfo/bpf ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions @ 2024-01-29 12:07 ` Jose E. Marchesi 0 siblings, 0 replies; 32+ messages in thread From: Jose E. Marchesi @ 2024-01-29 12:07 UTC (permalink / raw) To: Alexei Starovoitov; +Cc: Dave Thaler, Yonghong Song, bpf, bpf > On Sat, Jan 27, 2024 at 10:59 PM <dthaler1968@googlemail.com> wrote: >> >> I asked: >> > >> What about DW and LDX variants of BPF_IND and BPF_ABS? >> >> Jose E. Marchesi <jose.marchesi@oracle.com> wrote: >> > These we support: >> > >> > /* Absolute load instructions, designed to be used in socket filters. >> */ >> > {BPF_INSN_LDABSB, "ldabsb%W%i32", "r0 = * ( u8 * ) skb [ %i32 ]", >> > BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_B|BPF_MODE_ABS}, >> > {BPF_INSN_LDABSH, "ldabsh%W%i32", "r0 = * ( u16 * ) skb [ %i32 ]", >> > BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_H|BPF_MODE_ABS}, >> > {BPF_INSN_LDABSW, "ldabsw%W%i32", "r0 = * ( u32 * ) skb [ %i32 ]", >> > BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_W|BPF_MODE_ABS}, >> > {BPF_INSN_LDABSDW, "ldabsdw%W%i32", "r0 = * ( u64 * ) skb [ %i32 ]", >> > BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_DW|BPF_MODE_ABS}, >> > >> > /* Generic load instructions (to register.) */ >> > {BPF_INSN_LDXB, "ldxb%W%dr , [ %sr %o16 ]", "%dr = * ( u8 * ) ( %sr %o16 >> )", >> > BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_B|BPF_MODE_MEM}, >> > {BPF_INSN_LDXH, "ldxh%W%dr , [ %sr %o16 ]", "%dr = * ( u16 * ) ( %sr >> %o16 >> > )", >> > BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_H|BPF_MODE_MEM}, >> > {BPF_INSN_LDXW, "ldxw%W%dr , [ %sr %o16 ]", "%dr = * ( u32 * ) ( %sr >> %o16 >> > )", >> > BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_W|BPF_MODE_MEM}, >> > {BPF_INSN_LDXDW, "ldxdw%W%dr , [ %sr %o16 ]","%dr = * ( u64 * ) ( %sr >> > %o16 )", >> > BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_DW|BPF_MODE_MEM}, >> >> Yonghong Song <yonghong.song@linux.dev> wrote: >> > I don't know how to do proper wording in the standard. But DW and LDX >> > variants of BPF_IND/BPF_ABS are not supported by verifier for now and they >> > are considered illegal insns. >> >> Although the Linux verifier doesn't support them, the fact that gcc does >> support >> them tells me that it's probably safest to list the DW and LDX variants as >> deprecated as well, which is what the draft already did in the appendix so >> that's good (nothing to change there, I think). > > DW never existed in classic bpf, so abs/ind never had DW flavor. > If some assembler/compiler decided to "support" them it's on them. > The standard must not list such things as deprecated. They never > existed. So nothing is deprecated. We have no reason to support these instructions in the assembler, and GCC certainly never generates these. So I will remove the ABS/IND DW instructions from the assembler today. > Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed. > It's a legacy insn. Just like abs/ind. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions @ 2024-01-29 12:07 ` Jose E. Marchesi 0 siblings, 0 replies; 32+ messages in thread From: Jose E. Marchesi @ 2024-01-29 12:07 UTC (permalink / raw) To: Alexei Starovoitov; +Cc: Dave Thaler, Yonghong Song, bpf, bpf > On Sat, Jan 27, 2024 at 10:59 PM <dthaler1968@googlemail.com> wrote: >> >> I asked: >> > >> What about DW and LDX variants of BPF_IND and BPF_ABS? >> >> Jose E. Marchesi <jose.marchesi@oracle.com> wrote: >> > These we support: >> > >> > /* Absolute load instructions, designed to be used in socket filters. >> */ >> > {BPF_INSN_LDABSB, "ldabsb%W%i32", "r0 = * ( u8 * ) skb [ %i32 ]", >> > BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_B|BPF_MODE_ABS}, >> > {BPF_INSN_LDABSH, "ldabsh%W%i32", "r0 = * ( u16 * ) skb [ %i32 ]", >> > BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_H|BPF_MODE_ABS}, >> > {BPF_INSN_LDABSW, "ldabsw%W%i32", "r0 = * ( u32 * ) skb [ %i32 ]", >> > BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_W|BPF_MODE_ABS}, >> > {BPF_INSN_LDABSDW, "ldabsdw%W%i32", "r0 = * ( u64 * ) skb [ %i32 ]", >> > BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_DW|BPF_MODE_ABS}, >> > >> > /* Generic load instructions (to register.) */ >> > {BPF_INSN_LDXB, "ldxb%W%dr , [ %sr %o16 ]", "%dr = * ( u8 * ) ( %sr %o16 >> )", >> > BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_B|BPF_MODE_MEM}, >> > {BPF_INSN_LDXH, "ldxh%W%dr , [ %sr %o16 ]", "%dr = * ( u16 * ) ( %sr >> %o16 >> > )", >> > BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_H|BPF_MODE_MEM}, >> > {BPF_INSN_LDXW, "ldxw%W%dr , [ %sr %o16 ]", "%dr = * ( u32 * ) ( %sr >> %o16 >> > )", >> > BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_W|BPF_MODE_MEM}, >> > {BPF_INSN_LDXDW, "ldxdw%W%dr , [ %sr %o16 ]","%dr = * ( u64 * ) ( %sr >> > %o16 )", >> > BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_DW|BPF_MODE_MEM}, >> >> Yonghong Song <yonghong.song@linux.dev> wrote: >> > I don't know how to do proper wording in the standard. But DW and LDX >> > variants of BPF_IND/BPF_ABS are not supported by verifier for now and they >> > are considered illegal insns. >> >> Although the Linux verifier doesn't support them, the fact that gcc does >> support >> them tells me that it's probably safest to list the DW and LDX variants as >> deprecated as well, which is what the draft already did in the appendix so >> that's good (nothing to change there, I think). > > DW never existed in classic bpf, so abs/ind never had DW flavor. > If some assembler/compiler decided to "support" them it's on them. > The standard must not list such things as deprecated. They never > existed. So nothing is deprecated. We have no reason to support these instructions in the assembler, and GCC certainly never generates these. So I will remove the ABS/IND DW instructions from the assembler today. > Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed. > It's a legacy insn. Just like abs/ind. -- Bpf mailing list Bpf@ietf.org https://www.ietf.org/mailman/listinfo/bpf ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions @ 2024-01-30 12:13 ` Jose E. Marchesi 0 siblings, 0 replies; 32+ messages in thread From: Jose E. Marchesi @ 2024-01-30 12:13 UTC (permalink / raw) To: Alexei Starovoitov; +Cc: Dave Thaler, Yonghong Song, bpf, bpf >> On Sat, Jan 27, 2024 at 10:59 PM <dthaler1968@googlemail.com> wrote: >>> >>> I asked: >>> > >> What about DW and LDX variants of BPF_IND and BPF_ABS? >>> >>> Jose E. Marchesi <jose.marchesi@oracle.com> wrote: >>> > These we support: >>> > >>> > /* Absolute load instructions, designed to be used in socket filters. >>> */ >>> > {BPF_INSN_LDABSB, "ldabsb%W%i32", "r0 = * ( u8 * ) skb [ %i32 ]", >>> > BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_B|BPF_MODE_ABS}, >>> > {BPF_INSN_LDABSH, "ldabsh%W%i32", "r0 = * ( u16 * ) skb [ %i32 ]", >>> > BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_H|BPF_MODE_ABS}, >>> > {BPF_INSN_LDABSW, "ldabsw%W%i32", "r0 = * ( u32 * ) skb [ %i32 ]", >>> > BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_W|BPF_MODE_ABS}, >>> > {BPF_INSN_LDABSDW, "ldabsdw%W%i32", "r0 = * ( u64 * ) skb [ %i32 ]", >>> > BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_DW|BPF_MODE_ABS}, >>> > >>> > /* Generic load instructions (to register.) */ >>> > {BPF_INSN_LDXB, "ldxb%W%dr , [ %sr %o16 ]", "%dr = * ( u8 * ) ( %sr %o16 >>> )", >>> > BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_B|BPF_MODE_MEM}, >>> > {BPF_INSN_LDXH, "ldxh%W%dr , [ %sr %o16 ]", "%dr = * ( u16 * ) ( %sr >>> %o16 >>> > )", >>> > BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_H|BPF_MODE_MEM}, >>> > {BPF_INSN_LDXW, "ldxw%W%dr , [ %sr %o16 ]", "%dr = * ( u32 * ) ( %sr >>> %o16 >>> > )", >>> > BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_W|BPF_MODE_MEM}, >>> > {BPF_INSN_LDXDW, "ldxdw%W%dr , [ %sr %o16 ]","%dr = * ( u64 * ) ( %sr >>> > %o16 )", >>> > BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_DW|BPF_MODE_MEM}, >>> >>> Yonghong Song <yonghong.song@linux.dev> wrote: >>> > I don't know how to do proper wording in the standard. But DW and LDX >>> > variants of BPF_IND/BPF_ABS are not supported by verifier for now and they >>> > are considered illegal insns. >>> >>> Although the Linux verifier doesn't support them, the fact that gcc does >>> support >>> them tells me that it's probably safest to list the DW and LDX variants as >>> deprecated as well, which is what the draft already did in the appendix so >>> that's good (nothing to change there, I think). >> >> DW never existed in classic bpf, so abs/ind never had DW flavor. >> If some assembler/compiler decided to "support" them it's on them. >> The standard must not list such things as deprecated. They never >> existed. So nothing is deprecated. > > We have no reason to support these instructions in the assembler, and > GCC certainly never generates these. So I will remove the ABS/IND DW > instructions from the assembler today. This has been done now in upstream binutils. >> Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed. >> It's a legacy insn. Just like abs/ind. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions @ 2024-01-30 12:13 ` Jose E. Marchesi 0 siblings, 0 replies; 32+ messages in thread From: Jose E. Marchesi @ 2024-01-30 12:13 UTC (permalink / raw) To: Alexei Starovoitov; +Cc: Dave Thaler, Yonghong Song, bpf, bpf >> On Sat, Jan 27, 2024 at 10:59 PM <dthaler1968@googlemail.com> wrote: >>> >>> I asked: >>> > >> What about DW and LDX variants of BPF_IND and BPF_ABS? >>> >>> Jose E. Marchesi <jose.marchesi@oracle.com> wrote: >>> > These we support: >>> > >>> > /* Absolute load instructions, designed to be used in socket filters. >>> */ >>> > {BPF_INSN_LDABSB, "ldabsb%W%i32", "r0 = * ( u8 * ) skb [ %i32 ]", >>> > BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_B|BPF_MODE_ABS}, >>> > {BPF_INSN_LDABSH, "ldabsh%W%i32", "r0 = * ( u16 * ) skb [ %i32 ]", >>> > BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_H|BPF_MODE_ABS}, >>> > {BPF_INSN_LDABSW, "ldabsw%W%i32", "r0 = * ( u32 * ) skb [ %i32 ]", >>> > BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_W|BPF_MODE_ABS}, >>> > {BPF_INSN_LDABSDW, "ldabsdw%W%i32", "r0 = * ( u64 * ) skb [ %i32 ]", >>> > BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_DW|BPF_MODE_ABS}, >>> > >>> > /* Generic load instructions (to register.) */ >>> > {BPF_INSN_LDXB, "ldxb%W%dr , [ %sr %o16 ]", "%dr = * ( u8 * ) ( %sr %o16 >>> )", >>> > BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_B|BPF_MODE_MEM}, >>> > {BPF_INSN_LDXH, "ldxh%W%dr , [ %sr %o16 ]", "%dr = * ( u16 * ) ( %sr >>> %o16 >>> > )", >>> > BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_H|BPF_MODE_MEM}, >>> > {BPF_INSN_LDXW, "ldxw%W%dr , [ %sr %o16 ]", "%dr = * ( u32 * ) ( %sr >>> %o16 >>> > )", >>> > BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_W|BPF_MODE_MEM}, >>> > {BPF_INSN_LDXDW, "ldxdw%W%dr , [ %sr %o16 ]","%dr = * ( u64 * ) ( %sr >>> > %o16 )", >>> > BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_DW|BPF_MODE_MEM}, >>> >>> Yonghong Song <yonghong.song@linux.dev> wrote: >>> > I don't know how to do proper wording in the standard. But DW and LDX >>> > variants of BPF_IND/BPF_ABS are not supported by verifier for now and they >>> > are considered illegal insns. >>> >>> Although the Linux verifier doesn't support them, the fact that gcc does >>> support >>> them tells me that it's probably safest to list the DW and LDX variants as >>> deprecated as well, which is what the draft already did in the appendix so >>> that's good (nothing to change there, I think). >> >> DW never existed in classic bpf, so abs/ind never had DW flavor. >> If some assembler/compiler decided to "support" them it's on them. >> The standard must not list such things as deprecated. They never >> existed. So nothing is deprecated. > > We have no reason to support these instructions in the assembler, and > GCC certainly never generates these. So I will remove the ABS/IND DW > instructions from the assembler today. This has been done now in upstream binutils. >> Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed. >> It's a legacy insn. Just like abs/ind. -- Bpf mailing list Bpf@ietf.org https://www.ietf.org/mailman/listinfo/bpf ^ permalink raw reply [flat|nested] 32+ messages in thread
* RE: [Bpf] ISA: BPF_MSH and deprecated packet access instructions @ 2024-01-30 15:51 ` dthaler1968=40googlemail.com 0 siblings, 0 replies; 32+ messages in thread From: dthaler1968 @ 2024-01-30 15:51 UTC (permalink / raw) To: 'Alexei Starovoitov' Cc: 'Jose E. Marchesi', 'Yonghong Song', bpf, 'bpf' Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: [...] > > Although the Linux verifier doesn't support them, the fact that gcc > > does support them tells me that it's probably safest to list the DW > > and LDX variants as deprecated as well, which is what the draft > > already did in the appendix so that's good (nothing to change there, I > > think). > > DW never existed in classic bpf, so abs/ind never had DW flavor. > If some assembler/compiler decided to "support" them it's on them. > The standard must not list such things as deprecated. They never existed. So > nothing is deprecated. Ack, I will remove the ABS/IND + DW lines from the appendix. > Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed. > It's a legacy insn. Just like abs/ind. Should it be listed in the legacy conformance group then? Currently it's not mentioned in instruction-set.rst at all, so the opcode is available to use by any new instruction. If we do list it in instruction-set.rst then, like abs/ind, it will be avoided by anyone proposing new instructions. Dave ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions @ 2024-01-30 15:51 ` dthaler1968=40googlemail.com 0 siblings, 0 replies; 32+ messages in thread From: dthaler1968=40googlemail.com @ 2024-01-30 15:51 UTC (permalink / raw) To: 'Alexei Starovoitov' Cc: 'Jose E. Marchesi', 'Yonghong Song', bpf, 'bpf' Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: [...] > > Although the Linux verifier doesn't support them, the fact that gcc > > does support them tells me that it's probably safest to list the DW > > and LDX variants as deprecated as well, which is what the draft > > already did in the appendix so that's good (nothing to change there, I > > think). > > DW never existed in classic bpf, so abs/ind never had DW flavor. > If some assembler/compiler decided to "support" them it's on them. > The standard must not list such things as deprecated. They never existed. So > nothing is deprecated. Ack, I will remove the ABS/IND + DW lines from the appendix. > Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed. > It's a legacy insn. Just like abs/ind. Should it be listed in the legacy conformance group then? Currently it's not mentioned in instruction-set.rst at all, so the opcode is available to use by any new instruction. If we do list it in instruction-set.rst then, like abs/ind, it will be avoided by anyone proposing new instructions. Dave -- Bpf mailing list Bpf@ietf.org https://www.ietf.org/mailman/listinfo/bpf ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions @ 2024-01-30 16:22 ` Alexei Starovoitov 0 siblings, 0 replies; 32+ messages in thread From: Alexei Starovoitov @ 2024-01-30 16:22 UTC (permalink / raw) To: Dave Thaler; +Cc: Jose E. Marchesi, Yonghong Song, bpf, bpf On Tue, Jan 30, 2024 at 7:51 AM <dthaler1968@googlemail.com> wrote: > > Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > [...] > > > Although the Linux verifier doesn't support them, the fact that gcc > > > does support them tells me that it's probably safest to list the DW > > > and LDX variants as deprecated as well, which is what the draft > > > already did in the appendix so that's good (nothing to change there, I > > > think). > > > > DW never existed in classic bpf, so abs/ind never had DW flavor. > > If some assembler/compiler decided to "support" them it's on them. > > The standard must not list such things as deprecated. They never existed. So > > nothing is deprecated. > > Ack, I will remove the ABS/IND + DW lines from the appendix. > > > Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed. > > It's a legacy insn. Just like abs/ind. > > Should it be listed in the legacy conformance group then? > > Currently it's not mentioned in instruction-set.rst at all, so the opcode > is available to use by any new instruction. If we do list it in instruction-set.rst > then, like abs/ind, it will be avoided by anyone proposing new instructions. Yeah. The standard needs to mention it as legacy insn. It's such a weird ultra specialized insn introduced for one specific purpose parsing IP header. tcpdump only. Effectively. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions @ 2024-01-30 16:22 ` Alexei Starovoitov 0 siblings, 0 replies; 32+ messages in thread From: Alexei Starovoitov @ 2024-01-30 16:22 UTC (permalink / raw) To: Dave Thaler; +Cc: Jose E. Marchesi, Yonghong Song, bpf, bpf On Tue, Jan 30, 2024 at 7:51 AM <dthaler1968@googlemail.com> wrote: > > Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > [...] > > > Although the Linux verifier doesn't support them, the fact that gcc > > > does support them tells me that it's probably safest to list the DW > > > and LDX variants as deprecated as well, which is what the draft > > > already did in the appendix so that's good (nothing to change there, I > > > think). > > > > DW never existed in classic bpf, so abs/ind never had DW flavor. > > If some assembler/compiler decided to "support" them it's on them. > > The standard must not list such things as deprecated. They never existed. So > > nothing is deprecated. > > Ack, I will remove the ABS/IND + DW lines from the appendix. > > > Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed. > > It's a legacy insn. Just like abs/ind. > > Should it be listed in the legacy conformance group then? > > Currently it's not mentioned in instruction-set.rst at all, so the opcode > is available to use by any new instruction. If we do list it in instruction-set.rst > then, like abs/ind, it will be avoided by anyone proposing new instructions. Yeah. The standard needs to mention it as legacy insn. It's such a weird ultra specialized insn introduced for one specific purpose parsing IP header. tcpdump only. Effectively. -- Bpf mailing list Bpf@ietf.org https://www.ietf.org/mailman/listinfo/bpf ^ permalink raw reply [flat|nested] 32+ messages in thread
* RE: [Bpf] ISA: BPF_MSH and deprecated packet access instructions @ 2024-01-30 16:42 ` dthaler1968=40googlemail.com 0 siblings, 0 replies; 32+ messages in thread From: dthaler1968 @ 2024-01-30 16:42 UTC (permalink / raw) To: 'Alexei Starovoitov', 'Dave Thaler' Cc: 'Jose E. Marchesi', 'Yonghong Song', bpf, 'bpf' [...] > > > Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed. > > > It's a legacy insn. Just like abs/ind. > > > > Should it be listed in the legacy conformance group then? > > > > Currently it's not mentioned in instruction-set.rst at all, so the > > opcode is available to use by any new instruction. If we do list it > > in instruction-set.rst then, like abs/ind, it will be avoided by anyone proposing > new instructions. > > Yeah. The standard needs to mention it as legacy insn. > It's such a weird ultra specialized insn introduced for one specific purpose > parsing IP header. tcpdump only. Effectively. Thanks for the quick answer on this one. Will do. Dave ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions @ 2024-01-30 16:42 ` dthaler1968=40googlemail.com 0 siblings, 0 replies; 32+ messages in thread From: dthaler1968=40googlemail.com @ 2024-01-30 16:42 UTC (permalink / raw) To: 'Alexei Starovoitov', 'Dave Thaler' Cc: 'Jose E. Marchesi', 'Yonghong Song', bpf, 'bpf' [...] > > > Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed. > > > It's a legacy insn. Just like abs/ind. > > > > Should it be listed in the legacy conformance group then? > > > > Currently it's not mentioned in instruction-set.rst at all, so the > > opcode is available to use by any new instruction. If we do list it > > in instruction-set.rst then, like abs/ind, it will be avoided by anyone proposing > new instructions. > > Yeah. The standard needs to mention it as legacy insn. > It's such a weird ultra specialized insn introduced for one specific purpose > parsing IP header. tcpdump only. Effectively. Thanks for the quick answer on this one. Will do. Dave -- Bpf mailing list Bpf@ietf.org https://www.ietf.org/mailman/listinfo/bpf ^ permalink raw reply [flat|nested] 32+ messages in thread
* RE: [Bpf] ISA: BPF_MSH and deprecated packet access instructions @ 2024-01-30 16:39 ` dthaler1968=40googlemail.com 0 siblings, 0 replies; 32+ messages in thread From: dthaler1968 @ 2024-01-30 16:39 UTC (permalink / raw) To: bpf, 'bpf' Cc: 'Jose E. Marchesi', 'Alexei Starovoitov', 'Yonghong Song' > Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > [...] > > > Although the Linux verifier doesn't support them, the fact that gcc > > > does support them tells me that it's probably safest to list the DW > > > and LDX variants as deprecated as well, which is what the draft > > > already did in the appendix so that's good (nothing to change there, > > > I think). > > > > DW never existed in classic bpf, so abs/ind never had DW flavor. > > If some assembler/compiler decided to "support" them it's on them. > > The standard must not list such things as deprecated. They never > > existed. So nothing is deprecated. > > Ack, I will remove the ABS/IND + DW lines from the appendix. > > > Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed. > > It's a legacy insn. Just like abs/ind. > > Should it be listed in the legacy conformance group then? > > Currently it's not mentioned in instruction-set.rst at all, so the opcode is > available to use by any new instruction. If we do list it in instruction-set.rst > then, like abs/ind, it will be avoided by anyone proposing new instructions. Here's my understanding of this thread so far: * (IND/ABS) | (W/H/B) | LD : these are accepted by the Linux verifier and are supported by clang and gcc. They should be in the legacy conformance group of deprecated instructions. * (IND/ABS) | DW | (LD/LDX) : these are not accepted by the Linux verifier and were never used. Clang doesn't generate them but gcc did which is now removed based on this discussion. They should NOT be in the legacy conformance group of deprecated instructions because they were never defined in the first place, and instruction-set.rst should be updated to clarify this. * (IND/ABS) | (W/H/B) | LDX : these are not accepted by the Linux verifier and were never used. Clang doesn't generate them but gcc does. They should NOT be in the legacy conformance group of deprecated instructions because they were never defined in the first place, and instruction-set.rst should be updated to clarify this. * (IND/ABS) | (W/H/B/DW) | (ST/STX): these are not accepted by the Linux verifier and were never used. I don't know whether clang or gcc generates them. They should NOT be in the legacy conformance group of deprecated instructions because they were never defined in the first place, and instruction-set.rst should be updated to clarify this. * MSH | B | LDX: this existed in classic BPF but does not exist in (e)BPF since it is not accepted by the Linux verifier. I don't know whether clang ever generated them, but gcc never did. The "Legacy BPF Packet access instructions" section of instruction-set.rst says > BPF previously introduced special instructions for access to packet data that were carried > over from classic BPF. However, these instructions are deprecated and should no longer be used. I read Alexei's comment "It's a legacy insn. Just like abs/ind" as a possible argument that MSH|B|LDX should be mentioned in instruction-set.rst, pointing to the above section, like IND/ABS do. But Yonghong argued that it was never accepted by the verifier, so need not be mentioned. * MSH | (W/H/DW) | (LD/ST/STX): These are not accepted by the Linux verifier and were never used. They should NOT be in the legacy conformance group of deprecated instructions because they were never defined in the first place. Let me know if any of the above is incorrect and I can submit a doc patch. Dave ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions @ 2024-01-30 16:39 ` dthaler1968=40googlemail.com 0 siblings, 0 replies; 32+ messages in thread From: dthaler1968=40googlemail.com @ 2024-01-30 16:39 UTC (permalink / raw) To: bpf, 'bpf' Cc: 'Jose E. Marchesi', 'Alexei Starovoitov', 'Yonghong Song' > Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > [...] > > > Although the Linux verifier doesn't support them, the fact that gcc > > > does support them tells me that it's probably safest to list the DW > > > and LDX variants as deprecated as well, which is what the draft > > > already did in the appendix so that's good (nothing to change there, > > > I think). > > > > DW never existed in classic bpf, so abs/ind never had DW flavor. > > If some assembler/compiler decided to "support" them it's on them. > > The standard must not list such things as deprecated. They never > > existed. So nothing is deprecated. > > Ack, I will remove the ABS/IND + DW lines from the appendix. > > > Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed. > > It's a legacy insn. Just like abs/ind. > > Should it be listed in the legacy conformance group then? > > Currently it's not mentioned in instruction-set.rst at all, so the opcode is > available to use by any new instruction. If we do list it in instruction-set.rst > then, like abs/ind, it will be avoided by anyone proposing new instructions. Here's my understanding of this thread so far: * (IND/ABS) | (W/H/B) | LD : these are accepted by the Linux verifier and are supported by clang and gcc. They should be in the legacy conformance group of deprecated instructions. * (IND/ABS) | DW | (LD/LDX) : these are not accepted by the Linux verifier and were never used. Clang doesn't generate them but gcc did which is now removed based on this discussion. They should NOT be in the legacy conformance group of deprecated instructions because they were never defined in the first place, and instruction-set.rst should be updated to clarify this. * (IND/ABS) | (W/H/B) | LDX : these are not accepted by the Linux verifier and were never used. Clang doesn't generate them but gcc does. They should NOT be in the legacy conformance group of deprecated instructions because they were never defined in the first place, and instruction-set.rst should be updated to clarify this. * (IND/ABS) | (W/H/B/DW) | (ST/STX): these are not accepted by the Linux verifier and were never used. I don't know whether clang or gcc generates them. They should NOT be in the legacy conformance group of deprecated instructions because they were never defined in the first place, and instruction-set.rst should be updated to clarify this. * MSH | B | LDX: this existed in classic BPF but does not exist in (e)BPF since it is not accepted by the Linux verifier. I don't know whether clang ever generated them, but gcc never did. The "Legacy BPF Packet access instructions" section of instruction-set.rst says > BPF previously introduced special instructions for access to packet data that were carried > over from classic BPF. However, these instructions are deprecated and should no longer be used. I read Alexei's comment "It's a legacy insn. Just like abs/ind" as a possible argument that MSH|B|LDX should be mentioned in instruction-set.rst, pointing to the above section, like IND/ABS do. But Yonghong argued that it was never accepted by the verifier, so need not be mentioned. * MSH | (W/H/DW) | (LD/ST/STX): These are not accepted by the Linux verifier and were never used. They should NOT be in the legacy conformance group of deprecated instructions because they were never defined in the first place. Let me know if any of the above is incorrect and I can submit a doc patch. Dave -- Bpf mailing list Bpf@ietf.org https://www.ietf.org/mailman/listinfo/bpf ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions @ 2024-01-30 18:39 ` Yonghong Song 0 siblings, 0 replies; 32+ messages in thread From: Yonghong Song @ 2024-01-30 18:39 UTC (permalink / raw) To: dthaler1968, bpf, 'bpf' Cc: 'Jose E. Marchesi', 'Alexei Starovoitov' On 1/30/24 8:39 AM, dthaler1968@googlemail.com wrote: >> Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: >> [...] >>>> Although the Linux verifier doesn't support them, the fact that gcc >>>> does support them tells me that it's probably safest to list the DW >>>> and LDX variants as deprecated as well, which is what the draft >>>> already did in the appendix so that's good (nothing to change there, >>>> I think). >>> DW never existed in classic bpf, so abs/ind never had DW flavor. >>> If some assembler/compiler decided to "support" them it's on them. >>> The standard must not list such things as deprecated. They never >>> existed. So nothing is deprecated. >> Ack, I will remove the ABS/IND + DW lines from the appendix. >> >>> Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed. >>> It's a legacy insn. Just like abs/ind. >> Should it be listed in the legacy conformance group then? >> >> Currently it's not mentioned in instruction-set.rst at all, so the opcode is >> available to use by any new instruction. If we do list it in instruction-set.rst >> then, like abs/ind, it will be avoided by anyone proposing new instructions. > Here's my understanding of this thread so far: > > * (IND/ABS) | (W/H/B) | LD : these are accepted by the Linux verifier and are supported > by clang and gcc. They should be in the legacy conformance group of deprecated > instructions. > > * (IND/ABS) | DW | (LD/LDX) : these are not accepted by the Linux verifier and were > never used. Clang doesn't generate them but gcc did which is now removed > based on this discussion. They should NOT be in the legacy conformance group of > deprecated instructions because they were never defined in the first place, and > instruction-set.rst should be updated to clarify this. > > * (IND/ABS) | (W/H/B) | LDX : these are not accepted by the Linux verifier and were > never used. Clang doesn't generate them but gcc does. They should NOT > be in the legacy conformance group of deprecated instructions because they were > never defined in the first place, and instruction-set.rst should be updated to clarify this. > > * (IND/ABS) | (W/H/B/DW) | (ST/STX): these are not accepted by the Linux verifier and were > never used. I don't know whether clang or gcc generates them. They should NOT > be in the legacy conformance group of deprecated instructions because they were > never defined in the first place, and instruction-set.rst should be updated to clarify this. > > * MSH | B | LDX: this existed in classic BPF but does not exist in (e)BPF since it is not accepted > by the Linux verifier. I don't know whether clang ever generated them, but gcc never did. clang never generated this insn either. > The "Legacy BPF Packet access instructions" section of instruction-set.rst says > > BPF previously introduced special instructions for access to packet data that were carried > > over from classic BPF. However, these instructions are deprecated and should no longer be used. > I read Alexei's comment "It's a legacy insn. Just like abs/ind" as a possible argument that MSH|B|LDX > should be mentioned in instruction-set.rst, pointing to the above section, like IND/ABS do. > But Yonghong argued that it was never accepted by the verifier, so need not be mentioned. It is just my opinion. Standardization is complicated. I guess adding it to the legacy insn is okay to prevent anybody using the same opcode. > > * MSH | (W/H/DW) | (LD/ST/STX): These are not accepted by the Linux verifier and were > never used. They should NOT be in the legacy conformance group of deprecated instructions > because they were never defined in the first place. > > Let me know if any of the above is incorrect and I can submit a doc patch. > > Dave > ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions @ 2024-01-30 18:39 ` Yonghong Song 0 siblings, 0 replies; 32+ messages in thread From: Yonghong Song @ 2024-01-30 18:39 UTC (permalink / raw) To: dthaler1968, bpf, 'bpf' Cc: 'Jose E. Marchesi', 'Alexei Starovoitov' On 1/30/24 8:39 AM, dthaler1968@googlemail.com wrote: >> Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: >> [...] >>>> Although the Linux verifier doesn't support them, the fact that gcc >>>> does support them tells me that it's probably safest to list the DW >>>> and LDX variants as deprecated as well, which is what the draft >>>> already did in the appendix so that's good (nothing to change there, >>>> I think). >>> DW never existed in classic bpf, so abs/ind never had DW flavor. >>> If some assembler/compiler decided to "support" them it's on them. >>> The standard must not list such things as deprecated. They never >>> existed. So nothing is deprecated. >> Ack, I will remove the ABS/IND + DW lines from the appendix. >> >>> Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed. >>> It's a legacy insn. Just like abs/ind. >> Should it be listed in the legacy conformance group then? >> >> Currently it's not mentioned in instruction-set.rst at all, so the opcode is >> available to use by any new instruction. If we do list it in instruction-set.rst >> then, like abs/ind, it will be avoided by anyone proposing new instructions. > Here's my understanding of this thread so far: > > * (IND/ABS) | (W/H/B) | LD : these are accepted by the Linux verifier and are supported > by clang and gcc. They should be in the legacy conformance group of deprecated > instructions. > > * (IND/ABS) | DW | (LD/LDX) : these are not accepted by the Linux verifier and were > never used. Clang doesn't generate them but gcc did which is now removed > based on this discussion. They should NOT be in the legacy conformance group of > deprecated instructions because they were never defined in the first place, and > instruction-set.rst should be updated to clarify this. > > * (IND/ABS) | (W/H/B) | LDX : these are not accepted by the Linux verifier and were > never used. Clang doesn't generate them but gcc does. They should NOT > be in the legacy conformance group of deprecated instructions because they were > never defined in the first place, and instruction-set.rst should be updated to clarify this. > > * (IND/ABS) | (W/H/B/DW) | (ST/STX): these are not accepted by the Linux verifier and were > never used. I don't know whether clang or gcc generates them. They should NOT > be in the legacy conformance group of deprecated instructions because they were > never defined in the first place, and instruction-set.rst should be updated to clarify this. > > * MSH | B | LDX: this existed in classic BPF but does not exist in (e)BPF since it is not accepted > by the Linux verifier. I don't know whether clang ever generated them, but gcc never did. clang never generated this insn either. > The "Legacy BPF Packet access instructions" section of instruction-set.rst says > > BPF previously introduced special instructions for access to packet data that were carried > > over from classic BPF. However, these instructions are deprecated and should no longer be used. > I read Alexei's comment "It's a legacy insn. Just like abs/ind" as a possible argument that MSH|B|LDX > should be mentioned in instruction-set.rst, pointing to the above section, like IND/ABS do. > But Yonghong argued that it was never accepted by the verifier, so need not be mentioned. It is just my opinion. Standardization is complicated. I guess adding it to the legacy insn is okay to prevent anybody using the same opcode. > > * MSH | (W/H/DW) | (LD/ST/STX): These are not accepted by the Linux verifier and were > never used. They should NOT be in the legacy conformance group of deprecated instructions > because they were never defined in the first place. > > Let me know if any of the above is incorrect and I can submit a doc patch. > > Dave > -- Bpf mailing list Bpf@ietf.org https://www.ietf.org/mailman/listinfo/bpf ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions @ 2024-01-30 19:40 ` Alexei Starovoitov 0 siblings, 0 replies; 32+ messages in thread From: Alexei Starovoitov @ 2024-01-30 19:40 UTC (permalink / raw) To: Dave Thaler; +Cc: bpf, bpf, Jose E. Marchesi, Yonghong Song On Tue, Jan 30, 2024 at 8:39 AM <dthaler1968@googlemail.com> wrote: > > > Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > > [...] > > > > Although the Linux verifier doesn't support them, the fact that gcc > > > > does support them tells me that it's probably safest to list the DW > > > > and LDX variants as deprecated as well, which is what the draft > > > > already did in the appendix so that's good (nothing to change there, > > > > I think). > > > > > > DW never existed in classic bpf, so abs/ind never had DW flavor. > > > If some assembler/compiler decided to "support" them it's on them. > > > The standard must not list such things as deprecated. They never > > > existed. So nothing is deprecated. > > > > Ack, I will remove the ABS/IND + DW lines from the appendix. > > > > > Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed. > > > It's a legacy insn. Just like abs/ind. > > > > Should it be listed in the legacy conformance group then? > > > > Currently it's not mentioned in instruction-set.rst at all, so the opcode is > > available to use by any new instruction. If we do list it in instruction-set.rst > > then, like abs/ind, it will be avoided by anyone proposing new instructions. > > Here's my understanding of this thread so far: > > * (IND/ABS) | (W/H/B) | LD : these are accepted by the Linux verifier and are supported > by clang and gcc. They should be in the legacy conformance group of deprecated > instructions. yes > * (IND/ABS) | DW | (LD/LDX) : these are not accepted by the Linux verifier and were > never used. Clang doesn't generate them but gcc did which is now removed > based on this discussion. They should NOT be in the legacy conformance group of > deprecated instructions because they were never defined in the first place, and > instruction-set.rst should be updated to clarify this. yes > * (IND/ABS) | (W/H/B) | LDX : these are not accepted by the Linux verifier and were > never used. Clang doesn't generate them but gcc does. They should NOT > be in the legacy conformance group of deprecated instructions because they were > never defined in the first place, and instruction-set.rst should be updated to clarify this. yes. > * (IND/ABS) | (W/H/B/DW) | (ST/STX): these are not accepted by the Linux verifier and were > never used. I don't know whether clang or gcc generates them. They should NOT > be in the legacy conformance group of deprecated instructions because they were > never defined in the first place, and instruction-set.rst should be updated to clarify this. yes > * MSH | B | LDX: this existed in classic BPF but does not exist in (e)BPF since it is not accepted > by the Linux verifier. I don't know whether clang ever generated them, but gcc never did. > The "Legacy BPF Packet access instructions" section of instruction-set.rst says > > BPF previously introduced special instructions for access to packet data that were carried > > over from classic BPF. However, these instructions are deprecated and should no longer be used. > I read Alexei's comment "It's a legacy insn. Just like abs/ind" as a possible argument that MSH|B|LDX > should be mentioned in instruction-set.rst, pointing to the above section, like IND/ABS do. > But Yonghong argued that it was never accepted by the verifier, so need not be mentioned. Yonghong is actually more correct here. MSH | B | LDX is only accepted by _classic_ BPF. It was never accepted by eBPF verifier, so I have to back track my earlier suggestion. I think it's undefined opcode from 'eBPF standardization' pov. The standard doesn't talk about 'classic BPF' at all. So it's fine to use MSH | B | LDX for something in the future. > * MSH | (W/H/DW) | (LD/ST/STX): These are not accepted by the Linux verifier and were > never used. They should NOT be in the legacy conformance group of deprecated instructions > because they were never defined in the first place. yes. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions @ 2024-01-30 19:40 ` Alexei Starovoitov 0 siblings, 0 replies; 32+ messages in thread From: Alexei Starovoitov @ 2024-01-30 19:40 UTC (permalink / raw) To: Dave Thaler; +Cc: bpf, bpf, Jose E. Marchesi, Yonghong Song On Tue, Jan 30, 2024 at 8:39 AM <dthaler1968@googlemail.com> wrote: > > > Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > > [...] > > > > Although the Linux verifier doesn't support them, the fact that gcc > > > > does support them tells me that it's probably safest to list the DW > > > > and LDX variants as deprecated as well, which is what the draft > > > > already did in the appendix so that's good (nothing to change there, > > > > I think). > > > > > > DW never existed in classic bpf, so abs/ind never had DW flavor. > > > If some assembler/compiler decided to "support" them it's on them. > > > The standard must not list such things as deprecated. They never > > > existed. So nothing is deprecated. > > > > Ack, I will remove the ABS/IND + DW lines from the appendix. > > > > > Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed. > > > It's a legacy insn. Just like abs/ind. > > > > Should it be listed in the legacy conformance group then? > > > > Currently it's not mentioned in instruction-set.rst at all, so the opcode is > > available to use by any new instruction. If we do list it in instruction-set.rst > > then, like abs/ind, it will be avoided by anyone proposing new instructions. > > Here's my understanding of this thread so far: > > * (IND/ABS) | (W/H/B) | LD : these are accepted by the Linux verifier and are supported > by clang and gcc. They should be in the legacy conformance group of deprecated > instructions. yes > * (IND/ABS) | DW | (LD/LDX) : these are not accepted by the Linux verifier and were > never used. Clang doesn't generate them but gcc did which is now removed > based on this discussion. They should NOT be in the legacy conformance group of > deprecated instructions because they were never defined in the first place, and > instruction-set.rst should be updated to clarify this. yes > * (IND/ABS) | (W/H/B) | LDX : these are not accepted by the Linux verifier and were > never used. Clang doesn't generate them but gcc does. They should NOT > be in the legacy conformance group of deprecated instructions because they were > never defined in the first place, and instruction-set.rst should be updated to clarify this. yes. > * (IND/ABS) | (W/H/B/DW) | (ST/STX): these are not accepted by the Linux verifier and were > never used. I don't know whether clang or gcc generates them. They should NOT > be in the legacy conformance group of deprecated instructions because they were > never defined in the first place, and instruction-set.rst should be updated to clarify this. yes > * MSH | B | LDX: this existed in classic BPF but does not exist in (e)BPF since it is not accepted > by the Linux verifier. I don't know whether clang ever generated them, but gcc never did. > The "Legacy BPF Packet access instructions" section of instruction-set.rst says > > BPF previously introduced special instructions for access to packet data that were carried > > over from classic BPF. However, these instructions are deprecated and should no longer be used. > I read Alexei's comment "It's a legacy insn. Just like abs/ind" as a possible argument that MSH|B|LDX > should be mentioned in instruction-set.rst, pointing to the above section, like IND/ABS do. > But Yonghong argued that it was never accepted by the verifier, so need not be mentioned. Yonghong is actually more correct here. MSH | B | LDX is only accepted by _classic_ BPF. It was never accepted by eBPF verifier, so I have to back track my earlier suggestion. I think it's undefined opcode from 'eBPF standardization' pov. The standard doesn't talk about 'classic BPF' at all. So it's fine to use MSH | B | LDX for something in the future. > * MSH | (W/H/DW) | (LD/ST/STX): These are not accepted by the Linux verifier and were > never used. They should NOT be in the legacy conformance group of deprecated instructions > because they were never defined in the first place. yes. -- Bpf mailing list Bpf@ietf.org https://www.ietf.org/mailman/listinfo/bpf ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: ISA: BPF_MSH and deprecated packet access instructions @ 2024-01-28 0:26 ` Yonghong Song 0 siblings, 0 replies; 32+ messages in thread From: Yonghong Song @ 2024-01-28 0:26 UTC (permalink / raw) To: dthaler1968; +Cc: bpf, bpf On 1/27/24 10:50 AM, dthaler1968@googlemail.com wrote: > Under "Load and store instructions", various mode modifiers are documented. > I notice that BPF_MSH (0xa0) is not documented, but appears to be in use in > various projects, including Linux, BSD, seccomp, etc. and is even documented > in various books such as > https://www.google.com/books/edition/Programming_Linux_Hacker_Tools_Uncovere > d/yqHVAwAAQBAJ?hl=en&gbpv=1&dq=%22BPF_MSH%22&pg=PA129&printsec=frontcover > > Should we document it as deprecated and add it to the set of deprecated > instructions (the legacy conformance group) like BPF_ABS and BPF_IND > already are? > > Also, for purposes of the IANA registry of instructions where we list which > opcodes are "(deprecated, implementation-specific)", I currently list all > possible BPF_ABS and BPF_IND opcodes regardless of whether they were > ever used (I didn't check which were used and which might not have been), > so I could just list all possible BPF_MSH opcodes similarly. But if we know > that some were never used then I don't need to do so, so I guess I should > ask: > do we have a list of which combinations were actually used or should we > continue to just deprecate all combinations? > > As an example, > https://github.com/seccomp/libseccomp/blob/main/tools/scmp_bpf_disasm.c#L68 > lists 6 variants of BPF_MSH: LD and LDX, for B, H, and W (but not DW). > Other sources like the book page referenced above, and the BSD man page, > list only BPF_LDX | BPF_B | BPF_MSH, which is in Linux sources such as > https://elixir.bootlin.com/linux/v6.8-rc1/source/lib/test_bpf.c#L368 From kernel source code (net/core/filter.c), the only supported format is BPF_LDX | BPF_MSH | BPF_B The insn (BPF_LDX | BPF_MSH | BPF_B) is only used when cBPF (classic BPF) is converted to BPF insn set. If the current BPF program has this insn, verifier will reject it and bpf kernel interpreter does not support this insn either. So technically, (BPF_LDX | BPF_MSH | BPF_B) is not supported by BPF program. > > So, should we list the DW variants as deprecated, or never assigned? > Should we list the H, W, and LD variants as deprecated, or never assigned? > > What about DW and LDX variants of BPF_IND and BPF_ABS? > > > ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions @ 2024-01-28 0:26 ` Yonghong Song 0 siblings, 0 replies; 32+ messages in thread From: Yonghong Song @ 2024-01-28 0:26 UTC (permalink / raw) To: dthaler1968; +Cc: bpf, bpf On 1/27/24 10:50 AM, dthaler1968@googlemail.com wrote: > Under "Load and store instructions", various mode modifiers are documented. > I notice that BPF_MSH (0xa0) is not documented, but appears to be in use in > various projects, including Linux, BSD, seccomp, etc. and is even documented > in various books such as > https://www.google.com/books/edition/Programming_Linux_Hacker_Tools_Uncovere > d/yqHVAwAAQBAJ?hl=en&gbpv=1&dq=%22BPF_MSH%22&pg=PA129&printsec=frontcover > > Should we document it as deprecated and add it to the set of deprecated > instructions (the legacy conformance group) like BPF_ABS and BPF_IND > already are? > > Also, for purposes of the IANA registry of instructions where we list which > opcodes are "(deprecated, implementation-specific)", I currently list all > possible BPF_ABS and BPF_IND opcodes regardless of whether they were > ever used (I didn't check which were used and which might not have been), > so I could just list all possible BPF_MSH opcodes similarly. But if we know > that some were never used then I don't need to do so, so I guess I should > ask: > do we have a list of which combinations were actually used or should we > continue to just deprecate all combinations? > > As an example, > https://github.com/seccomp/libseccomp/blob/main/tools/scmp_bpf_disasm.c#L68 > lists 6 variants of BPF_MSH: LD and LDX, for B, H, and W (but not DW). > Other sources like the book page referenced above, and the BSD man page, > list only BPF_LDX | BPF_B | BPF_MSH, which is in Linux sources such as > https://elixir.bootlin.com/linux/v6.8-rc1/source/lib/test_bpf.c#L368 From kernel source code (net/core/filter.c), the only supported format is BPF_LDX | BPF_MSH | BPF_B The insn (BPF_LDX | BPF_MSH | BPF_B) is only used when cBPF (classic BPF) is converted to BPF insn set. If the current BPF program has this insn, verifier will reject it and bpf kernel interpreter does not support this insn either. So technically, (BPF_LDX | BPF_MSH | BPF_B) is not supported by BPF program. > > So, should we list the DW variants as deprecated, or never assigned? > Should we list the H, W, and LD variants as deprecated, or never assigned? > > What about DW and LDX variants of BPF_IND and BPF_ABS? > > > -- Bpf mailing list Bpf@ietf.org https://www.ietf.org/mailman/listinfo/bpf ^ permalink raw reply [flat|nested] 32+ messages in thread
* RE: ISA: BPF_MSH and deprecated packet access instructions @ 2024-01-28 0:53 ` dthaler1968=40googlemail.com 0 siblings, 0 replies; 32+ messages in thread From: dthaler1968 @ 2024-01-28 0:53 UTC (permalink / raw) To: 'Yonghong Song'; +Cc: bpf, bpf > -----Original Message----- > From: Yonghong Song <yonghong.song@linux.dev> > Sent: Saturday, January 27, 2024 4:27 PM > To: dthaler1968@googlemail.com > Cc: bpf@ietf.org; bpf@vger.kernel.org > Subject: Re: ISA: BPF_MSH and deprecated packet access instructions > > > On 1/27/24 10:50 AM, dthaler1968@googlemail.com wrote: > > Under "Load and store instructions", various mode modifiers are > documented. > > I notice that BPF_MSH (0xa0) is not documented, but appears to be in > > use in various projects, including Linux, BSD, seccomp, etc. and is > > even documented in various books such as > > > https://www.google.com/books/edition/Programming_Linux_Hacker_Tools_Un > > covere > > > d/yqHVAwAAQBAJ?hl=en&gbpv=1&dq=%22BPF_MSH%22&pg=PA129&printsec > =frontco > > ver > > > > Should we document it as deprecated and add it to the set of > > deprecated instructions (the legacy conformance group) like BPF_ABS > > and BPF_IND already are? > > > > Also, for purposes of the IANA registry of instructions where we list > > which opcodes are "(deprecated, implementation-specific)", I currently > > list all possible BPF_ABS and BPF_IND opcodes regardless of whether > > they were ever used (I didn't check which were used and which might > > not have been), so I could just list all possible BPF_MSH opcodes > > similarly. But if we know that some were never used then I don't need > > to do so, so I guess I should > > ask: > > do we have a list of which combinations were actually used or should > > we continue to just deprecate all combinations? > > > > As an example, > > https://github.com/seccomp/libseccomp/blob/main/tools/scmp_bpf_disasm. > > c#L68 lists 6 variants of BPF_MSH: LD and LDX, for B, H, and W (but > > not DW). > > Other sources like the book page referenced above, and the BSD man > > page, list only BPF_LDX | BPF_B | BPF_MSH, which is in Linux sources > > such as > > https://elixir.bootlin.com/linux/v6.8-rc1/source/lib/test_bpf.c#L368 > > From kernel source code (net/core/filter.c), the only supported format is > BPF_LDX | BPF_MSH | BPF_B > > The insn (BPF_LDX | BPF_MSH | BPF_B) is only used when cBPF (classic BPF) is > converted to BPF insn set. If the current BPF program has this insn, verifier will > reject it and bpf kernel interpreter does not support this insn either. So > technically, (BPF_LDX | BPF_MSH | BPF_B) is not supported by BPF program. > > > So, should we list the DW variants as deprecated, or never assigned? > > Should we list the H, W, and LD variants as deprecated, or never assigned? Thanks for confirming. I think the doc is ok as is for this part. > > What about DW and LDX variants of BPF_IND and BPF_ABS? What about this question? Dave ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions @ 2024-01-28 0:53 ` dthaler1968=40googlemail.com 0 siblings, 0 replies; 32+ messages in thread From: dthaler1968=40googlemail.com @ 2024-01-28 0:53 UTC (permalink / raw) To: 'Yonghong Song'; +Cc: bpf, bpf > -----Original Message----- > From: Yonghong Song <yonghong.song@linux.dev> > Sent: Saturday, January 27, 2024 4:27 PM > To: dthaler1968@googlemail.com > Cc: bpf@ietf.org; bpf@vger.kernel.org > Subject: Re: ISA: BPF_MSH and deprecated packet access instructions > > > On 1/27/24 10:50 AM, dthaler1968@googlemail.com wrote: > > Under "Load and store instructions", various mode modifiers are > documented. > > I notice that BPF_MSH (0xa0) is not documented, but appears to be in > > use in various projects, including Linux, BSD, seccomp, etc. and is > > even documented in various books such as > > > https://www.google.com/books/edition/Programming_Linux_Hacker_Tools_Un > > covere > > > d/yqHVAwAAQBAJ?hl=en&gbpv=1&dq=%22BPF_MSH%22&pg=PA129&printsec > =frontco > > ver > > > > Should we document it as deprecated and add it to the set of > > deprecated instructions (the legacy conformance group) like BPF_ABS > > and BPF_IND already are? > > > > Also, for purposes of the IANA registry of instructions where we list > > which opcodes are "(deprecated, implementation-specific)", I currently > > list all possible BPF_ABS and BPF_IND opcodes regardless of whether > > they were ever used (I didn't check which were used and which might > > not have been), so I could just list all possible BPF_MSH opcodes > > similarly. But if we know that some were never used then I don't need > > to do so, so I guess I should > > ask: > > do we have a list of which combinations were actually used or should > > we continue to just deprecate all combinations? > > > > As an example, > > https://github.com/seccomp/libseccomp/blob/main/tools/scmp_bpf_disasm. > > c#L68 lists 6 variants of BPF_MSH: LD and LDX, for B, H, and W (but > > not DW). > > Other sources like the book page referenced above, and the BSD man > > page, list only BPF_LDX | BPF_B | BPF_MSH, which is in Linux sources > > such as > > https://elixir.bootlin.com/linux/v6.8-rc1/source/lib/test_bpf.c#L368 > > From kernel source code (net/core/filter.c), the only supported format is > BPF_LDX | BPF_MSH | BPF_B > > The insn (BPF_LDX | BPF_MSH | BPF_B) is only used when cBPF (classic BPF) is > converted to BPF insn set. If the current BPF program has this insn, verifier will > reject it and bpf kernel interpreter does not support this insn either. So > technically, (BPF_LDX | BPF_MSH | BPF_B) is not supported by BPF program. > > > So, should we list the DW variants as deprecated, or never assigned? > > Should we list the H, W, and LD variants as deprecated, or never assigned? Thanks for confirming. I think the doc is ok as is for this part. > > What about DW and LDX variants of BPF_IND and BPF_ABS? What about this question? Dave -- Bpf mailing list Bpf@ietf.org https://www.ietf.org/mailman/listinfo/bpf ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: ISA: BPF_MSH and deprecated packet access instructions @ 2024-01-28 1:24 ` Yonghong Song 0 siblings, 0 replies; 32+ messages in thread From: Yonghong Song @ 2024-01-28 1:24 UTC (permalink / raw) To: dthaler1968; +Cc: bpf, bpf On 1/27/24 4:53 PM, dthaler1968@googlemail.com wrote: >> -----Original Message----- >> From: Yonghong Song <yonghong.song@linux.dev> >> Sent: Saturday, January 27, 2024 4:27 PM >> To: dthaler1968@googlemail.com >> Cc: bpf@ietf.org; bpf@vger.kernel.org >> Subject: Re: ISA: BPF_MSH and deprecated packet access instructions >> >> >> On 1/27/24 10:50 AM, dthaler1968@googlemail.com wrote: >>> Under "Load and store instructions", various mode modifiers are >> documented. >>> I notice that BPF_MSH (0xa0) is not documented, but appears to be in >>> use in various projects, including Linux, BSD, seccomp, etc. and is >>> even documented in various books such as >>> >> https://www.google.com/books/edition/Programming_Linux_Hacker_Tools_Un >>> covere >>> >> d/yqHVAwAAQBAJ?hl=en&gbpv=1&dq=%22BPF_MSH%22&pg=PA129&printsec >> =frontco >>> ver >>> >>> Should we document it as deprecated and add it to the set of >>> deprecated instructions (the legacy conformance group) like BPF_ABS >>> and BPF_IND already are? >>> >>> Also, for purposes of the IANA registry of instructions where we list >>> which opcodes are "(deprecated, implementation-specific)", I currently >>> list all possible BPF_ABS and BPF_IND opcodes regardless of whether >>> they were ever used (I didn't check which were used and which might >>> not have been), so I could just list all possible BPF_MSH opcodes >>> similarly. But if we know that some were never used then I don't need >>> to do so, so I guess I should >>> ask: >>> do we have a list of which combinations were actually used or should >>> we continue to just deprecate all combinations? >>> >>> As an example, >>> https://github.com/seccomp/libseccomp/blob/main/tools/scmp_bpf_disasm. >>> c#L68 lists 6 variants of BPF_MSH: LD and LDX, for B, H, and W (but >>> not DW). >>> Other sources like the book page referenced above, and the BSD man >>> page, list only BPF_LDX | BPF_B | BPF_MSH, which is in Linux sources >>> such as >>> https://elixir.bootlin.com/linux/v6.8-rc1/source/lib/test_bpf.c#L368 >> From kernel source code (net/core/filter.c), the only supported format is >> BPF_LDX | BPF_MSH | BPF_B >> >> The insn (BPF_LDX | BPF_MSH | BPF_B) is only used when cBPF (classic BPF) is >> converted to BPF insn set. If the current BPF program has this insn, verifier will >> reject it and bpf kernel interpreter does not support this insn either. So >> technically, (BPF_LDX | BPF_MSH | BPF_B) is not supported by BPF program. >> >>> So, should we list the DW variants as deprecated, or never assigned? >>> Should we list the H, W, and LD variants as deprecated, or never assigned? > Thanks for confirming. I think the doc is ok as is for this part. > >>> What about DW and LDX variants of BPF_IND and BPF_ABS? > What about this question? I don't know how to do proper wording in the standard. But DW and LDX variants of BPF_IND/BPF_ABS are not supported by verifier for now and they are considered illegal insns. > > Dave > ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions @ 2024-01-28 1:24 ` Yonghong Song 0 siblings, 0 replies; 32+ messages in thread From: Yonghong Song @ 2024-01-28 1:24 UTC (permalink / raw) To: dthaler1968; +Cc: bpf, bpf On 1/27/24 4:53 PM, dthaler1968@googlemail.com wrote: >> -----Original Message----- >> From: Yonghong Song <yonghong.song@linux.dev> >> Sent: Saturday, January 27, 2024 4:27 PM >> To: dthaler1968@googlemail.com >> Cc: bpf@ietf.org; bpf@vger.kernel.org >> Subject: Re: ISA: BPF_MSH and deprecated packet access instructions >> >> >> On 1/27/24 10:50 AM, dthaler1968@googlemail.com wrote: >>> Under "Load and store instructions", various mode modifiers are >> documented. >>> I notice that BPF_MSH (0xa0) is not documented, but appears to be in >>> use in various projects, including Linux, BSD, seccomp, etc. and is >>> even documented in various books such as >>> >> https://www.google.com/books/edition/Programming_Linux_Hacker_Tools_Un >>> covere >>> >> d/yqHVAwAAQBAJ?hl=en&gbpv=1&dq=%22BPF_MSH%22&pg=PA129&printsec >> =frontco >>> ver >>> >>> Should we document it as deprecated and add it to the set of >>> deprecated instructions (the legacy conformance group) like BPF_ABS >>> and BPF_IND already are? >>> >>> Also, for purposes of the IANA registry of instructions where we list >>> which opcodes are "(deprecated, implementation-specific)", I currently >>> list all possible BPF_ABS and BPF_IND opcodes regardless of whether >>> they were ever used (I didn't check which were used and which might >>> not have been), so I could just list all possible BPF_MSH opcodes >>> similarly. But if we know that some were never used then I don't need >>> to do so, so I guess I should >>> ask: >>> do we have a list of which combinations were actually used or should >>> we continue to just deprecate all combinations? >>> >>> As an example, >>> https://github.com/seccomp/libseccomp/blob/main/tools/scmp_bpf_disasm. >>> c#L68 lists 6 variants of BPF_MSH: LD and LDX, for B, H, and W (but >>> not DW). >>> Other sources like the book page referenced above, and the BSD man >>> page, list only BPF_LDX | BPF_B | BPF_MSH, which is in Linux sources >>> such as >>> https://elixir.bootlin.com/linux/v6.8-rc1/source/lib/test_bpf.c#L368 >> From kernel source code (net/core/filter.c), the only supported format is >> BPF_LDX | BPF_MSH | BPF_B >> >> The insn (BPF_LDX | BPF_MSH | BPF_B) is only used when cBPF (classic BPF) is >> converted to BPF insn set. If the current BPF program has this insn, verifier will >> reject it and bpf kernel interpreter does not support this insn either. So >> technically, (BPF_LDX | BPF_MSH | BPF_B) is not supported by BPF program. >> >>> So, should we list the DW variants as deprecated, or never assigned? >>> Should we list the H, W, and LD variants as deprecated, or never assigned? > Thanks for confirming. I think the doc is ok as is for this part. > >>> What about DW and LDX variants of BPF_IND and BPF_ABS? > What about this question? I don't know how to do proper wording in the standard. But DW and LDX variants of BPF_IND/BPF_ABS are not supported by verifier for now and they are considered illegal insns. > > Dave > -- Bpf mailing list Bpf@ietf.org https://www.ietf.org/mailman/listinfo/bpf ^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2024-01-30 19:40 UTC | newest] Thread overview: 32+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-01-27 18:50 ISA: BPF_MSH and deprecated packet access instructions dthaler1968 2024-01-27 18:50 ` [Bpf] " dthaler1968=40googlemail.com 2024-01-27 18:59 ` Jose E. Marchesi 2024-01-27 18:59 ` Jose E. Marchesi 2024-01-27 19:06 ` Jose E. Marchesi 2024-01-27 19:06 ` Jose E. Marchesi 2024-01-28 6:59 ` dthaler1968 2024-01-28 6:59 ` dthaler1968=40googlemail.com 2024-01-28 23:59 ` Alexei Starovoitov 2024-01-28 23:59 ` Alexei Starovoitov 2024-01-29 12:07 ` Jose E. Marchesi 2024-01-29 12:07 ` Jose E. Marchesi 2024-01-30 12:13 ` Jose E. Marchesi 2024-01-30 12:13 ` Jose E. Marchesi 2024-01-30 15:51 ` dthaler1968 2024-01-30 15:51 ` dthaler1968=40googlemail.com 2024-01-30 16:22 ` Alexei Starovoitov 2024-01-30 16:22 ` Alexei Starovoitov 2024-01-30 16:42 ` dthaler1968 2024-01-30 16:42 ` dthaler1968=40googlemail.com 2024-01-30 16:39 ` dthaler1968 2024-01-30 16:39 ` dthaler1968=40googlemail.com 2024-01-30 18:39 ` Yonghong Song 2024-01-30 18:39 ` Yonghong Song 2024-01-30 19:40 ` Alexei Starovoitov 2024-01-30 19:40 ` Alexei Starovoitov 2024-01-28 0:26 ` Yonghong Song 2024-01-28 0:26 ` [Bpf] " Yonghong Song 2024-01-28 0:53 ` dthaler1968 2024-01-28 0:53 ` [Bpf] " dthaler1968=40googlemail.com 2024-01-28 1:24 ` Yonghong Song 2024-01-28 1:24 ` [Bpf] " Yonghong Song
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.