Re: [PATCH 10/11] pragma once: delete few backslashes

On 28/02/2021 17:05, Alexey Dobriyan wrote: > From 251ca5673886b5bb0a42004944290b9d2b267a4a Mon Sep 17 00:00:00 2001 > From: Alexey Dobriyan > Date: Fri, 19 Feb 2021 13:37:24 +0300 > Subject: [PATCH 10/11] pragma once: delete few backslashes > > Some macros contain one backslash too many and end

Re: [PATCH] drivers: net: ethernet: sun: Fix couple of spells in the file sunhme.c

On 05/02/2021 12:47, Bhaskar Chowdhury wrote: > > > s/fuck/mess/ > s/fucking/s/ > > Signed-off-by: Bhaskar Chowdhury Right or wrong, these are not "spelling fixes". Please do not misrepresent your patch in your Subject: line. (Also, subsystem prefix should probably just be "net:

Re: [PATCH net-next] sfc: reduce the number of requested xdp ev queues

other channels, max 32) > > Which in turn triggers EINVAL on XDP processing: > > sfc :86:00.0 ext0: XDP TX failed (-22) > > Signed-off-by: Ivan Babrou Acked-by: Edward Cree

Re: [PATCH net-next 0/5] skbuff: introduce skbuff_heads bulking and reusing

Without wishing to weigh in on whether this caching is a good idea... Wouldn't it be simpler, rather than having two separate "alloc" and "flush" caches, to have a single larger cache, such that whenever it becomes full we bulk flush the top half, and when it's empty we bulk alloc the bottom

Re: [PATCH net-next] sfc: reduce the number of requested xdp ev queues

On 16/12/2020 08:45, Jesper Dangaard Brouer wrote: > So, what I hear is that this fix is just pampering over the real issue. Yes, it is, but it's better than nothing in the meantime while we work out the complete fix. > I suggest that you/we detect the situation, and have a code path that > will

Re: [PATCH net-next] sfc: reduce the number of requested xdp ev queues

es from the driver's channel structures having been designed a decade ago when 32 cpus ought to be enough for anybody... AFAIR the hardware is capable of giving us something like 1024 evqs if we ask for them, it just might not have that many msi-x vectors for us.) Anyway, the patch looks correct, so Acked-by: Edward Cree -ed

Re: [PATCH] net: flow_offload: remove trailing semicolon in macro definition

On 27/11/2020 19:37, t...@redhat.com wrote: > From: Tom Rix > > The macro use will already have a semicolon. > > Signed-off-by: Tom Rix > --- > net/core/flow_offload.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/core/flow_offload.c b/net/core/flow_offload.c >

Re: [PATCH 000/141] Fix fall-through warnings for Clang

On 24/11/2020 21:25, Kees Cook wrote: > I still think this isn't right -- it's a case statement that runs off > the end without an explicit flow control determination. Proves too much — for instance case foo: case bar: thing; break; doesn't require a fallthrough; after

Re: [PATCH 000/141] Fix fall-through warnings for Clang

On 25/11/2020 00:32, Miguel Ojeda wrote: > I have said *authoring* lines of *this* kind takes a minute per line. > Specifically: lines fixing the fallthrough warning mechanically and > repeatedly where the compiler tells you to, and doing so full-time for > a month. > It is useful since it makes

Re: [PATCH AUTOSEL 5.9 054/147] sfc: add and use efx_tx_send_pending in tx.c

On 26/10/2020 23:47, Sasha Levin wrote: > From: Edward Cree > > [ Upstream commit 1c0544d24927e4fad04f858216b8ea767a3bd123 ] > > Instead of using efx_tx_queue_partner(), which relies on the assumption > that tx_queues_per_channel is 2, efx_tx_send_pending() ite

Re: [RFC PATCH net-next] sfc: replace in_interrupt() usage

> On Mon, Sep 28 2020 at 21:05, Edward Cree wrote: >> Only compile-tested so far, because I'm waiting for my kernel to >> finish rebuilding with CONFIG_DEBUG_ATOMIC_SLEEP I've now tested and confirmed that the might_sleep warning goes away with this patch. Thomas, do y

[RFC PATCH net-next] sfc: replace in_interrupt() usage

, which are happy with being called from atomic contexts. Fixes: f00bf2305cab ("sfc: don't update stats on VF when called in atomic context") Reported-by: Sebastian Andrzej Siewior Signed-off-by: Edward Cree --- Only compile-tested so far, because I'm waiting for my kernel to finish

Re: [patch 15/35] net: sfc: Replace in_interrupt() usage.

eck and the code concerned  doesn't seemto have changed a great deal since. Anyway, this fix looks correct, and you can have my Acked-by: Edward Cree  but I thinkit might be cleaner to avoid having to have this unused  can_sleep argument on all the NICs that don't need it, by instead  adding an upd

Re: [PATCH 5.4 086/129] net: core: use listified Rx for GRO_NORMAL in napi_gro_receive()

ropped by the core stack, but it seems to have no impact on related > drivers' functionality. > gro_normal_batch is left untouched as it's very individual for every > single system configuration and might be tuned in manual order to > achieve an optimal performance. > > Signed-

Re: [PATCH] sfc_ef100: Fix build failure on powerpc

On 13/08/2020 15:39, Christophe Leroy wrote: > ppc6xx_defconfig fails building sfc.ko module, complaining > about the lack of _umoddi3 symbol. > > This is due to the following test > > if (EFX_MIN_DMAQ_SIZE % reader->value) { > > Because reader->value is u64. Already fixed in net.git

Re: [linux-next:master 13398/13940] drivers/net/ethernet/sfc/ef100_nic.c:610: undefined reference to `__umoddi3'

On 10/08/2020 16:51, Guenter Roeck wrote: > On Thu, Aug 06, 2020 at 07:17:43PM +0100, Edward Cree wrote: >> Maybe I should add a >> >> static inline u32 mod_u64(u64 dividend, u32 divisor) >> { >>     return do_div(dividend, divisor); >> } > Yo

Re: [linux-next:master 13398/13940] drivers/net/ethernet/sfc/ef100_nic.c:610: undefined reference to `__umoddi3'

On 06/08/2020 00:48, kernel test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git > master > head: d15fe4ec043588beee823781602ddb51d0bc84c8 > commit: adcfc3482813fa2c34e5902005853f79c2aa [13398/13940] sfc_ef100: > read Design Parameters at probe

Re: [PATCH] net: sfc: fix possible buffer overflow caused by bad DMA value in efx_siena_sriov_vfdi()

On 02/08/2020 16:39, Jia-Ju Bai wrote: > To fix this problem, "req->op" is assigned to a local variable, and then > the driver accesses this variable instead of "req->op". > > Signed-off-by: Jia-Ju Bai Not sure how necessary this is (or even if anyone's still usingSiena  SR-IOV, since it needed a

Re: [PATCH 2/7] sfc: drop unnecessary list_empty

On 26/07/2020 11:58, Julia Lawall wrote: > list_for_each_safe is able to handle an empty list. > The only effect of avoiding the loop is not initializing the > index variable. > Drop list_empty tests in cases where these variables are not > used. Sure, why not. Acked-by: Edward Cree

Re: [PATCH net-next v3 1/2] hinic: add support to handle hw abnormal event

On 23/07/2020 20:08, David Miller wrote: > From: Luo bin > Date: Thu, 23 Jul 2020 22:40:37 +0800 > >> +static int hinic_fw_reporter_dump(struct devlink_health_reporter *reporter, >> + struct devlink_fmsg *fmsg, void *priv_ctx, >> + struct

Re: [PATCH v2 net-next] net: core: use listified Rx for GRO_NORMAL in napi_gro_receive()

On 24/06/2020 22:06, Jason A. Donenfeld wrote: > Hi Alexander, > > This patch introduced a behavior change around GRO_DROP: > > napi_skb_finish used to sometimes return GRO_DROP: > >> -static gro_result_t napi_skb_finish(gro_result_t ret, struct sk_buff *skb) >> +static gro_result_t

Re: [PATCH ethtool v1] netlink: add master/slave configuration support

Disclaimer: *definitely* not speaking for my employer. On 09/06/2020 18:19, Stephen Hemminger wrote: > How many times have you or Linus argued about variable naming. > Yes, words do matter and convey a lot of implied connotation and meaning. Connotation, unlike denotation, is widely variable. I

Re: [PATCH v3 1/7] Documentation: dynamic-debug: Add description of level bitmask

On 09/06/2020 18:56, Joe Perches wrote: > These are _not_ netif_ control flags. Some are though. > For instance: > > $ git grep "MODULE_PARM.*\bdebug\b" drivers/net | head -10 > [...] > > These are all level/class output controls. TIL, thanks!  I should have looked deeperrather than assuming  they

Re: [PATCH v3 1/7] Documentation: dynamic-debug: Add description of level bitmask

On 09/06/2020 17:58, Joe Perches wrote: > On Tue, 2020-06-09 at 13:16 +0200, Greg Kroah-Hartman wrote: >> What is wrong with the existing control of dynamic >> debug messages that you want to add another type of arbitrary grouping >> to it? > There is no existing grouping mechanism. > > Many

Re: [PATCH] [net-next] sfc: avoid an unused-variable warning

On 28/05/2020 20:49, David Miller wrote: > From: Arnd Bergmann > Date: Wed, 27 May 2020 15:41:06 +0200 > >> 'nic_data' is no longer used outside of the #ifdef block >> in efx_ef10_set_mac_address: >> >> drivers/net/ethernet/sfc/ef10.c:3231:28: error: unused variable 'nic_data' >>

Re: [PATCH][next] sfc: fix dereference of table before it is null checked

checking table before dereferencing it when checking for a null > table->must_restore_filters. > > Addresses-Coverity: ("Dereference before null check") > Fixes: e4fe938cff04 ("sfc: move 'must restore' flags out of ef10-specific > nic_data") > Signed-off-by: Colin Ian King Acked-by: Edward Cree

Re: [PATCH net-next1/2] net: core: use listified Rx for GRO_NORMAL in napi_gro_receive()

in a way more common napi_gro_receive() >>> to speed up non-merged (GRO_NORMAL) skbs for a wide range of drivers, >>> including gro_cells and mac80211 users. >>> >>> Signed-off-by: Alexander Lobakin Acked-by: Edward Cree but I think this needs review from the socionext folks as well.

Re: [PATCH net-next1/2] net: core: use listified Rx for GRO_NORMAL in napi_gro_receive()

On 10/10/2019 15:42, Alexander Lobakin wrote: > Commit 323ebb61e32b4 ("net: use listified RX for handling GRO_NORMAL > skbs") made use of listified skb processing for the users of > napi_gro_frags(). > The same technique can be used in a way more common napi_gro_receive() > to speed up non-merged

Re: [PATCH net-next 2/2] net: core: increase the default size of GRO_NORMAL skb lists to flush

On 10/10/2019 15:42, Alexander Lobakin wrote: > Commit 323ebb61e32b ("net: use listified RX for handling GRO_NORMAL > skbs") have introduced a sysctl variable gro_normal_batch for defining > a limit for listified Rx of GRO_NORMAL skbs. The initial value of 8 is > purely arbitrary and has been

Re: [PATCH] net: sfc: falcon: convert to i2c_new_dummy_device

ject & description are incomplete, you're also changing i2c_new_device() to i2c_new_client_device(). Other than that, Acked-by: Edward Cree > Solarflare folks, please review/test. > > Thank you. Falcon isn't likely to get tested by us, I think we only have about three  of them lef

Re: [PATCH net-next 03/10] sfc: Use dev_get_drvdata where possible

On 24/07/2019 12:26, Chuhong Yuan wrote: > Instead of using to_pci_dev + pci_get_drvdata, > use dev_get_drvdata to make code simpler. > > Signed-off-by: Chuhong Yuan Acked-by: Edward Cree > --- > drivers/net/ethernet/sfc/ef10.c | 4 ++-- > drivers/net/ethernet/sfc/efx.c

Re: [PATCH] rds: ib: force endiannes annotation

On 29/04/2019 12:18, Nicholas Mc Guire wrote: > On Mon, Apr 29, 2019 at 12:00:06PM +0100, Edward Cree wrote: >> Again, a __force cast doesn't seem necessary here.  It looks like the >>  code is just using the wrong types; if all of src, dst and uncongested >>  were __le6

Re: [RFC PATCH v2 0/4] dynamic indirect call promotion

On 05/02/19 08:50, Nadav Amit wrote: >> In cases where RCU cannot be used (e.g. because some callees need to RCU >> synchronise), it might be possible to add a variant that uses >> synchronize_rcu_tasks() when updating, but this series does not attempt this. > I wonder why. Mainly because I have

[RFC PATCH v2 3/4] net: core: use a dynamic_call for dst_input

Typically there will be a small number of callees, such as ip_local_deliver or ip_forward, which will cover most packets. Signed-off-by: Edward Cree --- include/net/dst.h | 5 - net/core/dst.c| 2 ++ 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/include/net/dst.h b

[RFC PATCH v2 2/4] net: core: use a dynamic_call for pt_prev->func() in RX path

Typically a small number of callees, such as ip[v6]_rcv or packet_rcv, will cover most packets. Signed-off-by: Edward Cree --- net/core/dev.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/net/core/dev.c b/net/core/dev.c index 8e276e0192a1..7b38a33689d8 100644

[RFC PATCH v2 4/4] net: core: use a dynamic_call for pt_prev->list_func() in list RX path

There are currently only two possible callees, ip_list_rcv and ipv6_list_rcv. Even when more are added, most packets will typically follow one of a small number of callees on any given system. Signed-off-by: Edward Cree --- net/core/dev.c | 6 +- 1 file changed, 5 insertions(+), 1

[RFC PATCH v2 1/4] static_call: add indirect call promotion (dynamic_call) infrastructure

(and depends on a static_call implementation being available). Signed-off-by: Edward Cree --- include/linux/dynamic_call.h | 300 +++ init/Kconfig | 11 ++ kernel/Makefile | 1 + kernel/dynamic_call.c| 131

[RFC PATCH v2 0/4] dynamic indirect call promotion

to crashes; I have not yet determined whether they were the fault of my patch or of the static calls series. Edward Cree (4): static_call: add indirect call promotion (dynamic_call) infrastructure net: core: use a dynamic_call for pt_prev->func() in RX path net: core: use a dynamic_call

Re: [PATCH v3 2/6] static_call: Add basic static call infrastructure

On 09/01/19 22:59, Josh Poimboeuf wrote: > Static calls are a replacement for global function pointers. They use > code patching to allow direct calls to be used instead of indirect > calls. They give the flexibility of function pointers, but with > improved performance. This is especially

Re: [PATCH v2 0/4] Static calls

On 12/12/18 21:15, Nadav Amit wrote: >> On Dec 12, 2018, at 10:33 AM, Edward Cree wrote: >> >> AIUI the outline version uses a tail-call (i.e. jmpq *target) rather than an >> additional call and ret. So I wouldn't expect it to be too expensive. >> More to the po

Re: [PATCH 6/7] selftest/bpf: remove redundant parenthesis

On 12/12/18 19:04, Jakub Kicinski wrote: > On Tue, 11 Dec 2018 20:56:06 +0900, Alice Ferrazzi wrote: >> Signed-off-by: Alice Ferrazzi >> --- >> tools/testing/selftests/bpf/test_offload.py | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git

Re: [PATCH v2 0/4] Static calls

On 12/12/18 18:14, Nadav Amit wrote: > Second, (2i) is not very intuitive for me. Using the out-of-line static > calls seems to me as less performant than the inline (potentially, I didn’t > check). > > Anyhow, the use of out-of-line static calls seems to me as > counter-intuitive. I think (didn’t

[RFC PATCH 2/2] net: core: rather hacky PoC implementation of dynamic calls

; this is sad. It's also full of printk()s right now to display what it's doing for debugging purposes; obviously those wouldn't be quite the same in a finished version. Signed-off-by: Edward Cree --- net/core/dev.c | 222 +++-- 1 file changed

[RFC PATCH 1/2] static_call: fix out-of-line static call implementation

Actually call __static_call_update() from static_call_update(), and fix the former so it can actually compile. Also make it update key.func. Signed-off-by: Edward Cree --- include/linux/static_call.h | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/include/linux

[RFC/WIP PATCH 0/2] dynamic calls

c calls present). Edward Cree (2): static_call: fix out-of-line static call implementation net: core: rather hacky PoC implementation of dynamic calls include/linux/static_call.h | 6 +- net/core/dev.c | 222 +++- 2 files changed, 221 ins

Re: [PATCH v2 0/4] Static calls

On 12/12/18 05:59, Nadav Amit wrote: > Thanks for cc’ing me. (I didn’t know about the other patch-sets.) Well in my case, that's because I haven't posted any yet.  (Will follow up  shortly with what I currently have, though it's not pretty.) Looking at your patches, it seems you've got a much

Re: [PATCH v2 0/4] Static calls

On 07/12/18 16:06, Edward Cree wrote: > Sorry if this has been pointed out before (it's a very long thread), but > in the out-of-line implementation, it appears that static_call_update() > never alters key->func. Am I right in thinking that this should be > fixed by adding

Re: [PATCH v2 0/4] Static calls

On 07/12/18 16:06, Edward Cree wrote: > Sorry if this has been pointed out before (it's a very long thread), but > in the out-of-line implementation, it appears that static_call_update() > never alters key->func. Am I right in thinking that this should be > fixed by adding

Re: [PATCH v2 0/4] Static calls

Sorry if this has been pointed out before (it's a very long thread), but in the out-of-line implementation, it appears that static_call_update() never alters key->func. Am I right in thinking that this should be fixed by adding 'WRITE_ONCE(key->func, func);' just after the call to

Re: [PATCH v2 0/4] Static calls

Sorry if this has been pointed out before (it's a very long thread), but in the out-of-line implementation, it appears that static_call_update() never alters key->func. Am I right in thinking that this should be fixed by adding 'WRITE_ONCE(key->func, func);' just after the call to

[PATCH bpf] bpf: fix off-by-one error in adjust_subprog_starts

oducer). Fixes: cc8b0b92a169 ("bpf: introduce function calls (function boundaries)") Reported-by: syzbot+4fc427c7af994b094...@syzkaller.appspotmail.com Signed-off-by: Edward Cree --- I'm assuming I don't need to get a Signed-off-by from syzkaller to use its reproducer like this; I

[PATCH bpf] bpf: fix off-by-one error in adjust_subprog_starts

oducer). Fixes: cc8b0b92a169 ("bpf: introduce function calls (function boundaries)") Reported-by: syzbot+4fc427c7af994b094...@syzkaller.appspotmail.com Signed-off-by: Edward Cree --- I'm assuming I don't need to get a Signed-off-by from syzkaller to use its reproducer like this; I

Re: Code of Conduct: Let's revamp it.

On 20/09/18 10:27, unconditionedwitn...@redchan.it wrote: > Contributors can, at any time, rescind the license grant regarding their > property via written notice to those whom they are rescinding the grant > from (regarding their property (code)). I know others have already said it, but: This is

Re: Code of Conduct: Let's revamp it.

On 20/09/18 10:27, unconditionedwitn...@redchan.it wrote: > Contributors can, at any time, rescind the license grant regarding their > property via written notice to those whom they are rescinding the grant > from (regarding their property (code)). I know others have already said it, but: This is

Re: Code of Conduct: Let's revamp it.

On 20/09/18 02:16, Olof Johansson wrote: > I would be very surprised if any of my peers on the TAB ever had those > intentions, and I know I would not have them myself. In case my references to individualsmade it unclear: I have no reason to  suspect _any_ of the present TAB members would;

Re: Code of Conduct: Let's revamp it.

On 20/09/18 02:16, Olof Johansson wrote: > I would be very surprised if any of my peers on the TAB ever had those > intentions, and I know I would not have them myself. In case my references to individualsmade it unclear: I have no reason to  suspect _any_ of the present TAB members would;

Re: Code of Conduct: Let's revamp it.

On 19/09/18 15:18, Jonathan Corbet wrote: > I'd like to address just this part, speaking only for myself. > The LF is not in the position of arbitrating anything here. The body > charged with that is the LF Technical Advisory Board, which is a > different thing. Thank you for clarifying that.

Re: Code of Conduct: Let's revamp it.

On 19/09/18 15:18, Jonathan Corbet wrote: > I'd like to address just this part, speaking only for myself. > The LF is not in the position of arbitrating anything here. The body > charged with that is the LF Technical Advisory Board, which is a > different thing. Thank you for clarifying that.

Re: Code of Conduct: Let's revamp it.

The new Code of Conduct makes me feel threatened and uncomfortable. No, really.  As a person with (diagnosed) Asperger's, I'm a member of,  objectively, a marginalised minority.  Effectively (i.e. this is a massive  oversimplification), I was born without the hard-wired circuitry for social  

Re: Code of Conduct: Let's revamp it.

The new Code of Conduct makes me feel threatened and uncomfortable. No, really.  As a person with (diagnosed) Asperger's, I'm a member of,  objectively, a marginalised minority.  Effectively (i.e. this is a massive  oversimplification), I was born without the hard-wired circuitry for social  

Re: [PATCH net-next 1/2] docs: Add rest label the_canonical_path_format

On 25/07/18 03:50, Tobin C. Harding wrote: > In preparation to convert Documentation/network/netdev-FAQ.rst to > restructured text format we would like to be able to reference 'the > canonical patch format' section. > > Add rest label: 'the_canonical_path_format'. Here and in the Subject, 'patch'

Re: [PATCH net-next 1/2] docs: Add rest label the_canonical_path_format

On 25/07/18 03:50, Tobin C. Harding wrote: > In preparation to convert Documentation/network/netdev-FAQ.rst to > restructured text format we would like to be able to reference 'the > canonical patch format' section. > > Add rest label: 'the_canonical_path_format'. Here and in the Subject, 'patch'

Re: [PATCH] net: vxge: fix spelling mistake in macro VXGE_HW_ERR_PRIVILAGED_OPEARATION

On 22/05/18 16:36, Colin King wrote: > From: Colin Ian King > > Rename VXGE_HW_ERR_PRIVILAGED_OPEARATION to VXGE_HW_ERR_PRIVILAGED_OPERATION > to fix spelling mistake. > > Signed-off-by: Colin Ian King "Privilaged" doesn't look right either,

Re: [PATCH] net: vxge: fix spelling mistake in macro VXGE_HW_ERR_PRIVILAGED_OPEARATION

On 22/05/18 16:36, Colin King wrote: > From: Colin Ian King > > Rename VXGE_HW_ERR_PRIVILAGED_OPEARATION to VXGE_HW_ERR_PRIVILAGED_OPERATION > to fix spelling mistake. > > Signed-off-by: Colin Ian King "Privilaged" doesn't look right either, maybe fix both at once?  ->

Re: [PATCH v2 net-next 2/4] net: add skeleton of bpfilter kernel module

On 03/05/18 05:36, Alexei Starovoitov wrote: > bpfilter.ko consists of bpfilter_kern.c (normal kernel module code) > and user mode helper code that is embedded into bpfilter.ko > > The steps to build bpfilter.ko are the following: > - main.c is compiled by HOSTCC into the bpfilter_umh elf

Re: [PATCH v2 net-next 2/4] net: add skeleton of bpfilter kernel module

On 03/05/18 05:36, Alexei Starovoitov wrote: > bpfilter.ko consists of bpfilter_kern.c (normal kernel module code) > and user mode helper code that is embedded into bpfilter.ko > > The steps to build bpfilter.ko are the following: > - main.c is compiled by HOSTCC into the bpfilter_umh elf

Re: [PATCH] ethtool: fix a potential missing-check bug

On 30/04/18 02:31, Wenwen Wang wrote: > In ethtool_get_rxnfc(), the object "info" is firstly copied from > user-space. If the FLOW_RSS flag is set in the member field flow_type of > "info" (and cmd is ETHTOOL_GRXFH), info needs to be copied again from > user-space because FLOW_RSS is newer and has

Re: [PATCH] ethtool: fix a potential missing-check bug

On 30/04/18 02:31, Wenwen Wang wrote: > In ethtool_get_rxnfc(), the object "info" is firstly copied from > user-space. If the FLOW_RSS flag is set in the member field flow_type of > "info" (and cmd is ETHTOOL_GRXFH), info needs to be copied again from > user-space because FLOW_RSS is newer and has

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On 09/03/18 18:58, Alexei Starovoitov wrote: > It's not waiting for the whole thing, because once bpfilter starts it > stays running/sleeping because it's stateful. So, this has been bugging me a bit. If bpfilter takes a signal and crashes, all that state goes away. Does that mean your

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On 09/03/18 18:58, Alexei Starovoitov wrote: > It's not waiting for the whole thing, because once bpfilter starts it > stays running/sleeping because it's stateful. So, this has been bugging me a bit. If bpfilter takes a signal and crashes, all that state goes away. Does that mean your

[PATCH net-next] sfc: mark some unexported symbols as static

e TX queues for TX timestamps") Signed-off-by: Fengguang Wu <fengguang...@intel.com> [ec...@solarflare.com: rewrote commit message] Signed-off-by: Edward Cree <ec...@solarflare.com> --- drivers/net/ethernet/sfc/efx.c | 2 +- drivers/net/ethernet/sfc/ptp.c | 4 ++-- 2 files changed,

[PATCH net-next] sfc: mark some unexported symbols as static

t;) Signed-off-by: Fengguang Wu [ec...@solarflare.com: rewrote commit message] Signed-off-by: Edward Cree --- drivers/net/ethernet/sfc/efx.c | 2 +- drivers/net/ethernet/sfc/ptp.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/sfc/efx.c b/drivers/ne

Re: [RFC PATCH net-next] sfc: efx_default_channel_want_txqs() can be static

On 26/01/18 01:03, kbuild test robot wrote: > Fixes: 2935e3c38228 ("sfc: on 8000 series use TX queues for TX timestamps") > Signed-off-by: Fengguang Wu <fengguang...@intel.com> Acked-by: Edward Cree <ec...@solarflare.com> Dave, can you take this directly or do you

Re: [RFC PATCH net-next] sfc: efx_default_channel_want_txqs() can be static

On 26/01/18 01:03, kbuild test robot wrote: > Fixes: 2935e3c38228 ("sfc: on 8000 series use TX queues for TX timestamps") > Signed-off-by: Fengguang Wu Acked-by: Edward Cree Dave, can you take this directly or do you need it reposted without RFC tags?  I'm not sure wh

Re: [PATCH] bpf, doc: Correct one wrong value in "Register value tracking"

egister state can also be updated by conditional > branches. For instance, if a SCALAR_VALUE is compared > 8, in the 'true' > branch Acked-by: Edward Cree <ec...@solarflare.com>

Re: [PATCH] bpf, doc: Correct one wrong value in "Register value tracking"

itional > branches. For instance, if a SCALAR_VALUE is compared > 8, in the 'true' > branch Acked-by: Edward Cree

Re: [PATCH] kernel:bpf Remove structure passing and assignment to save stack and no coping structures

On 13/01/18 22:03, Karim Eshapa wrote: > Use pointers to structure as arguments to function instead of coping > structures and less stack size. Also transfer TNUM(_v, _m) to > tnum.h file to be used in differnet files for creating anonymous structures > statically. > > Signed-off-by: Karim Eshapa

Re: [PATCH] kernel:bpf Remove structure passing and assignment to save stack and no coping structures

On 13/01/18 22:03, Karim Eshapa wrote: > Use pointers to structure as arguments to function instead of coping > structures and less stack size. Also transfer TNUM(_v, _m) to > tnum.h file to be used in differnet files for creating anonymous structures > statically. > > Signed-off-by: Karim Eshapa

Re: BPF: bug without effect in BPF_RSH case of adjust_scalar_min_max_vals()

On 04/12/17 17:03, Jann Horn wrote: > As far as I can tell, commit b03c9f9fdc37 ("bpf/verifier: track signed > and unsigned min/max values") introduced the following effectless bug > in the BPF_RSH case of adjust_scalar_min_max_vals() (unless that's > intentional): > > `dst_reg->smax_value` is

Re: BPF: bug without effect in BPF_RSH case of adjust_scalar_min_max_vals()

On 04/12/17 17:03, Jann Horn wrote: > As far as I can tell, commit b03c9f9fdc37 ("bpf/verifier: track signed > and unsigned min/max values") introduced the following effectless bug > in the BPF_RSH case of adjust_scalar_min_max_vals() (unless that's > intentional): > > `dst_reg->smax_value` is

Re: selftests/bpf doesn't compile

On 15/09/17 17:02, Alexei Starovoitov wrote: > On Thu, Sep 14, 2017 at 09:33:48AM -0600, Shuah Khan wrote: >> Is bpf test intended to be run in kselftest run? The clang dependency might >> not be met on majority of the systems. Is this a hard dependency?? > It is a hard dependency and clang should

Re: selftests/bpf doesn't compile

On 15/09/17 17:02, Alexei Starovoitov wrote: > On Thu, Sep 14, 2017 at 09:33:48AM -0600, Shuah Khan wrote: >> Is bpf test intended to be run in kselftest run? The clang dependency might >> not be met on majority of the systems. Is this a hard dependency?? > It is a hard dependency and clang should

Re: [PATCH v3 net-next] bpf/verifier: track liveness for pruning

On 21/08/17 21:27, Daniel Borkmann wrote: > On 08/21/2017 08:36 PM, Edward Cree wrote: >> On 19/08/17 00:37, Alexei Starovoitov wrote: > [...] >> I'm tempted to just rip out env->varlen_map_value_access and always check >> the whole thing, because honestly I don't k

Re: [PATCH v3 net-next] bpf/verifier: track liveness for pruning

On 21/08/17 21:27, Daniel Borkmann wrote: > On 08/21/2017 08:36 PM, Edward Cree wrote: >> On 19/08/17 00:37, Alexei Starovoitov wrote: > [...] >> I'm tempted to just rip out env->varlen_map_value_access and always check >> the whole thing, because honestly I don't k

Re: [PATCH v3 net-next] bpf/verifier: track liveness for pruning

On 18/08/17 15:16, Edward Cree wrote: > On 18/08/17 04:21, Alexei Starovoitov wrote: >> It seems you're trying to sort-of do per-fake-basic block liveness >> analysis, but our state_list_marks are not correct if we go with >> canonical basic block definition, since

Re: [PATCH v3 net-next] bpf/verifier: track liveness for pruning

On 18/08/17 15:16, Edward Cree wrote: > On 18/08/17 04:21, Alexei Starovoitov wrote: >> It seems you're trying to sort-of do per-fake-basic block liveness >> analysis, but our state_list_marks are not correct if we go with >> canonical basic block definition, since

Re: [PATCH v3 net-next] bpf/verifier: track liveness for pruning

On 19/08/17 00:37, Alexei Starovoitov wrote: > that '14: safe' above is not correct. > > Disabling liveness as: > @@ -3282,7 +3288,7 @@ static bool regsafe(struct bpf_reg_state *rold, > struct bpf_reg_state *rcur, > bool varlen_map_access, struct idpair

Re: [PATCH v3 net-next] bpf/verifier: track liveness for pruning

On 19/08/17 00:37, Alexei Starovoitov wrote: > that '14: safe' above is not correct. > > Disabling liveness as: > @@ -3282,7 +3288,7 @@ static bool regsafe(struct bpf_reg_state *rold, > struct bpf_reg_state *rcur, > bool varlen_map_access, struct idpair

Re: [PATCH v3 net-next] bpf/verifier: track liveness for pruning

On 18/08/17 04:21, Alexei Starovoitov wrote: > On 8/15/17 12:34 PM, Edward Cree wrote: >> State of a register doesn't matter if it wasn't read in reaching an exit; >> a write screens off all reads downstream of it from all explored_states >> upstream of it. >> This a

Re: [PATCH v3 net-next] bpf/verifier: track liveness for pruning

On 18/08/17 04:21, Alexei Starovoitov wrote: > On 8/15/17 12:34 PM, Edward Cree wrote: >> State of a register doesn't matter if it wasn't read in reaching an exit; >> a write screens off all reads downstream of it from all explored_states >> upstream of it. >> This a

[PATCH v3 net-next] bpf/verifier: track liveness for pruning

62 31 bpf_overlay.o15 13 Signed-off-by: Edward Cree <ec...@solarflare.com> --- v3: cleaner code around marking caller-saved regs, again spotted by Daniel Borkmann. Should have no functional effect. v2: update liveness in LD_ABS|IND, as pointed out by

[PATCH v3 net-next] bpf/verifier: track liveness for pruning

62 31 bpf_overlay.o15 13 Signed-off-by: Edward Cree --- v3: cleaner code around marking caller-saved regs, again spotted by Daniel Borkmann. Should have no functional effect. v2: update liveness in LD_ABS|IND, as pointed out by Daniel Borkmann. The numbers

Re: [PATCH v2 net-next] bpf/verifier: track liveness for pruning

On 15/08/17 17:33, Daniel Borkmann wrote: > On 08/15/2017 03:53 PM, Edward Cree wrote: >> State of a register doesn't matter if it wasn't read in reaching an exit; >> a write screens off all reads downstream of it from all explored_states >> upstream of it. >> This a

Re: [PATCH v2 net-next] bpf/verifier: track liveness for pruning

On 15/08/17 17:33, Daniel Borkmann wrote: > On 08/15/2017 03:53 PM, Edward Cree wrote: >> State of a register doesn't matter if it wasn't read in reaching an exit; >> a write screens off all reads downstream of it from all explored_states >> upstream of it. >> This a

[PATCH v2 net-next] bpf/verifier: track liveness for pruning

62 31 bpf_overlay.o15 13 Signed-off-by: Edward Cree <ec...@solarflare.com> --- v2: update liveness in LD_ABS|IND, as pointed out by Daniel Borkmann. The numbers are mostly unchanged; bpf_lxc_opt_-DUNKNOWN.o dropped about 300 insns and 20ms, while bpf_lx

[PATCH v2 net-next] bpf/verifier: track liveness for pruning

62 31 bpf_overlay.o15 13 Signed-off-by: Edward Cree --- v2: update liveness in LD_ABS|IND, as pointed out by Daniel Borkmann. The numbers are mostly unchanged; bpf_lxc_opt_-DUNKNOWN.o dropped about 300 insns and 20ms, while bpf_lxc_opt_-DDROP_ALL.o (despite

Re: [PATCH net-next] bpf/verifier: track liveness for pruning

On 15/08/17 12:52, Daniel Borkmann wrote: > On 08/14/2017 07:55 PM, Edward Cree wrote: >> if (arg_type == ARG_ANYTHING) { >> if (is_pointer_value(env, regno)) { >> @@ -1639,10 +1675,13 @@ static int check_call(struct bpf_verifier_env *env, >>

Re: [PATCH net-next] bpf/verifier: track liveness for pruning

On 15/08/17 12:52, Daniel Borkmann wrote: > On 08/14/2017 07:55 PM, Edward Cree wrote: >> if (arg_type == ARG_ANYTHING) { >> if (is_pointer_value(env, regno)) { >> @@ -1639,10 +1675,13 @@ static int check_call(struct bpf_verifier_env *env, >>

[PATCH net-next] bpf/verifier: track liveness for pruning

62 31 bpf_overlay.o15 13 Signed-off-by: Edward Cree <ec...@solarflare.com> --- include/linux/bpf_verifier.h | 11 ++- kernel/bpf/verifier.c| 181 +-- 2 files changed, 151 insertions(+), 41 deletions(-) diff

[PATCH net-next] bpf/verifier: track liveness for pruning

62 31 bpf_overlay.o15 13 Signed-off-by: Edward Cree --- include/linux/bpf_verifier.h | 11 ++- kernel/bpf/verifier.c| 181 +-- 2 files changed, 151 insertions(+), 41 deletions(-) diff --git a/include/linux

  1   2   3   >