Hi Vladimir,
On Thu Dec 17 2020, Vladimir Oltean wrote:
> Since the introduction of the switchdev API, port attributes were
> transmitted to drivers for offloading using a two-step transactional
> model, with a prepare phase that was supposed to catch all errors, and a
> commit phase that was supp
Hi Yonghong,
Thank you for the detailed review.
On Thu, Dec 17, 2020 at 06:12:11PM -0800, Yonghong Song wrote:
> On 12/17/20 7:01 AM, Sean Young wrote:
> > clang supports arbitrary length ints using the _ExtInt extension. This
> > can be useful to hold very large values, e.g. 256 bit or 512 bit t
Hi Vladimir,
On Thu Dec 17 2020, Vladimir Oltean wrote:
> It should be the driver's business to logically separate its VLAN
> offloading into a preparation and a commit phase, and some drivers don't
> need / can't do this.
>
> So remove the transactional shim from DSA and let drivers to propagate
Hi David,
Thanks for the comment.
On Thu, Dec 17, 2020 at 09:07:03AM -0700, David Ahern wrote:
> > + return n - nframes; /* dropped frames count */
>
> just return nframes here, since ...
>
> > + xdp_drop = dev_map_bpf_prog_run(bq->xdp_prog, bq->q, cnt, dev);
> > + cnt -=
On 2020-12-17 17:09, Jamal Hadi Salim wrote:
On 2020-12-16 6:47 a.m., Maxim Mikityanskiy wrote:
On 2020-12-15 18:37, Jamal Hadi Salim wrote:
[..]
Same question above:
Is there a limit to the number of classes that can be created?
Yes, the commit message of the mlx5 patch lists the limitat
On Thu, 17 Dec 2020 18:26:50 +0100
Jesper Dangaard Brouer wrote:
> Adding selftest for BPF-helper bpf_check_mtu(). Making sure
> it can be used from both XDP and TC.
>
> Signed-off-by: Jesper Dangaard Brouer
> ---
> tools/testing/selftests/bpf/prog_tests/check_mtu.c | 204
> +
This is three bug fixes that fell out of a series of cleanups of the
ucc_geth driver. Please consider applying via the net tree.
v2: reorder and split off from larger series; add Andrew's R-b to
patch 1; only move the free_netdev() call in patch 3.
Rasmus Villemoes (3):
ethernet: ucc_geth: set
Table 8-53 in the QUICC Engine Reference manual shows definitions of
fields up to a size of 192 bytes, not just 128. But in table 8-111,
one does find the text
Base Address of the Global Transmitter Parameter RAM Page. [...]
The user needs to allocate 128 bytes for this page. The address must
All the buffers and registers are already set up appropriately for an
MTU slightly above 1500, so we just need to expose this to the
networking stack. AFAICT, there's no need to implement .ndo_change_mtu
when the receive buffers are always set up to support the max_mtu.
This fixes several warnings
ugeth is the netdiv_priv() part of the netdevice. Accessing the memory
pointed to by ugeth (such as done by ucc_geth_memclean() and the two
of_node_puts) after free_netdev() is thus use-after-free.
Signed-off-by: Rasmus Villemoes
---
drivers/net/ethernet/freescale/ucc_geth.c | 2 +-
1 file chang
Hi Jakub, David,
The following patchset contains Netfilter fixes for net:
1) Incorrect loop in error path of nft_set_elem_expr_clone(),
from Colin Ian King.
2) Missing xt_table_get_private_protected() to access table
private data in x_tables, from Subash Abhinov Kasiviswanathan.
3) Possib
From: Colin Ian King
The intention of the err_expr cleanup path is to iterate over the
allocated expr_array objects and free them, starting from i - 1 and
working down to the start of the array. Currently the loop counter
is being incremented instead of decremented and also the index i is
being u
From: Subash Abhinov Kasiviswanathan
This fixes the dereference to fetch the RCU pointer when holding
the appropriate xtables lock.
Reported-by: kernel test robot
Fixes: cc00bcaa5899 ("netfilter: x_tables: Switch synchronization to RCU")
Signed-off-by: Subash Abhinov Kasiviswanathan
Reviewed-b
From: Vasily Averin
currently mtype_resize() can cause oops
t = ip_set_alloc(htable_size(htable_bits));
if (!t) {
ret = -ENOMEM;
goto out;
}
t->hregion = ip_set_alloc(ahash_sizeof_regions(htable_bits));
Increased htable_bits can fo
From: Vasily Averin
htable_bits() can call jhash_size(32) and trigger shift-out-of-bounds
UBSAN: shift-out-of-bounds in net/netfilter/ipset/ip_set_hash_gen.h:151:6
shift exponent 32 is too large for 32-bit type 'unsigned int'
CPU: 0 PID: 8498 Comm: syz-executor519
Not tainted 5.10.0-rc7-next-20
On Thu, 17 Dec 2020, Rob Herring wrote:
> The correct syntax for JSON pointers begins with a '/' after the '#'.
> Without a '/', the string should be interpretted as a subschema
> identifier. The jsonschema module currently doesn't handle subschema
> identifiers and incorrectly allows JSON pointer
On Fri, Dec 18, 2020 at 08:10:51AM +0100, Greg KH wrote:
> On Thu, Dec 17, 2020 at 10:19:37PM +0100, Alexandre Belloni wrote:
> > There is something I don't get from the documentation and it is what is
> > this introducing that couldn't already be done using platform drivers
> > and platform devic
This patch set contains two bug fixes to the Tx SKB path. Details can
be found in the individual commit messages. Special thanks to Xuan
Zhuo for spotting both of them.
v1 -> v2:
* Rebase
Thanks: Magnus
Magnus Karlsson (2):
xsk: fix race in SKB mode transmit with shared cq
xsk: rollback rese
From: Magnus Karlsson
Fix a race when multiple sockets are simultaneously calling sendto()
when the completion ring is shared in the SKB case. This is the case
when you share the same netdev and queue id through the
XDP_SHARED_UMEM bind flag. The problem is that multiple processes can
be in xsk_g
On Fri, 18 Dec 2020, Mark Brown wrote:
> On Fri, Dec 18, 2020 at 08:10:51AM +0100, Greg KH wrote:
> > On Thu, Dec 17, 2020 at 10:19:37PM +0100, Alexandre Belloni wrote:
>
> > > There is something I don't get from the documentation and it is what is
> > > this introducing that couldn't already be
From: Magnus Karlsson
Rollback the reservation in the completion ring when we get a
NETDEV_TX_BUSY. When this error is received from the driver, we are
supposed to let the user application retry the transmit again. And in
order to do this, we need to roll back the failed send so it can be
retried
On Thu, Dec 17, 2020 at 2:25 AM Jakub Kicinski wrote:
>
> On Wed, 16 Dec 2020 21:02:39 +0800 Zheng Yongjun wrote:
> > The parameter of kfree function is NULL, so kfree code is useless, delete
> > it.
> >
> > Signed-off-by: Zheng Yongjun
>
> To be clear the subject tags is misleading we're not ta
On Fri, Dec 18, 2020 at 01:17:09PM +, Mark Brown wrote:
> As previously discussed this will need the auxilliary bus extending to
> support at least interrupts and possibly also general resources.
I thought the recent LWN article summed it up nicely, auxillary bus is
for gluing to subsystems t
On Thu, Dec 17, 2020 at 06:39:55PM -0800, Dan Williams wrote:
> There is room for documentation improvement here. I realize reading it
> back now that much of the justification for "why not platform bus?"
> happened on the list, but only a small mention made it into the
It wasn't clear from the l
On 12/17/20 2:34 PM, Rob Herring wrote:
> The correct syntax for JSON pointers begins with a '/' after the '#'.
> Without a '/', the string should be interpretted as a subschema
> identifier. The jsonschema module currently doesn't handle subschema
> identifiers and incorrectly allows JSON pointers
On Mon, Dec 14, 2020 at 03:38:32PM +0200, Shmulik Ladkani wrote:
> When setting xfrm replay_window to values higher than 32, a rare
> page-fault occurs in xfrm_replay_advance_bmp:
>
> BUG: unable to handle page fault for address: 8af350ad7920
> #PF: supervisor write access in kernel mode
>
Hello:
This series was applied to bpf/bpf.git (refs/heads/master):
On Fri, 18 Dec 2020 14:45:23 +0100 you wrote:
> This patch set contains two bug fixes to the Tx SKB path. Details can
> be found in the individual commit messages. Special thanks to Xuan
> Zhuo for spotting both of them.
>
> v1 -
Hello:
This patch was applied to bpf/bpf.git (refs/heads/master):
On Mon, 14 Dec 2020 22:35:39 + you wrote:
> From: Colin Ian King
>
> There are two spelling mistakes in output messages. Fix these.
>
> Signed-off-by: Colin Ian King
> ---
> tools/testing/selftests/bpf/xdpxceiver.c | 4 ++-
Hi Antoine,
I love your patch! Yet something to improve:
[auto build test ERROR on net/master]
url:
https://github.com/0day-ci/linux/commits/Antoine-Tenart/net-sysfs-fix-race-conditions-in-the-xps-code/20201218-002852
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
Hello:
This patch was applied to bpf/bpf.git (refs/heads/master):
On Wed, 16 Dec 2020 10:47:15 +0800 you wrote:
> Remove including that don't need it.
>
> Signed-off-by: Tian Tao
> ---
> kernel/bpf/syscall.c | 1 -
> 1 file changed, 1 deletion(-)
Here is the summary with links:
- bpf: remo
On Fri, 18 Dec 2020 16:16:12 +0100
Steffen Klassert wrote:
> Applied, thanks a lot Shmulik!
Thanks Steffen, please make sure this hits -stable
On Fri, Dec 18, 2020 at 7:34 AM Calvin Johnson
wrote:
>
> On Tue, Dec 15, 2020 at 07:33:40PM +0200, Andy Shevchenko wrote:
> > On Tue, Dec 15, 2020 at 6:44 PM Calvin Johnson
> > wrote:
...
> > > + /* phy->mii_ts may already be defined by the PHY driver. A
> > > +*
On Fri, Dec 18, 2020 at 7:40 AM Calvin Johnson
wrote:
> On Tue, Dec 15, 2020 at 07:53:26PM +0200, Andy Shevchenko wrote:
> > On Tue, Dec 15, 2020 at 6:44 PM Calvin Johnson
> > wrote:
...
> > I would rather see this as simple as
> >
> > if (is_of_node(fwnode))
> >return of_m
On Fri, Dec 18, 2020 at 10:08:54AM -0400, Jason Gunthorpe wrote:
> On Fri, Dec 18, 2020 at 01:17:09PM +, Mark Brown wrote:
> > As previously discussed this will need the auxilliary bus extending to
> > support at least interrupts and possibly also general resources.
> I thought the recent LWN
On Thu, Dec 17, 2020 at 7:55 PM David Ahern wrote:
>
> On 12/17/20 8:11 PM, Alexander Duyck wrote:
> > On Thu, Dec 17, 2020 at 5:30 PM David Ahern wrote:
> >>
> >> On 12/16/20 3:53 PM, Alexander Duyck wrote:
> >>> The problem in my case was based on a past experience where east-west
> >>> traffic
On Thu, Dec 17, 2020 at 9:20 PM Parav Pandit wrote:
>
>
> > From: Alexander Duyck
> > Sent: Friday, December 18, 2020 8:41 AM
> >
> > On Thu, Dec 17, 2020 at 5:30 PM David Ahern wrote:
> > >
> > > On 12/16/20 3:53 PM, Alexander Duyck wrote:
> > The problem is PCIe DMA wasn't designed to function
ci/linux/commits/Antoine-Tenart/net-sysfs-fix-race-conditions-in-the-xps-code/20201218-002852
> base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
> 3ae32c07815a24ae12de2e7838d9d429ba31e5e0
> config: riscv-randconfig-r014-20201217 (attached as .config)
> compiler: clan
On Fri, Dec 18, 2020 at 03:52:04PM +, Mark Brown wrote:
> On Fri, Dec 18, 2020 at 10:08:54AM -0400, Jason Gunthorpe wrote:
> > On Fri, Dec 18, 2020 at 01:17:09PM +, Mark Brown wrote:
>
> > > As previously discussed this will need the auxilliary bus extending to
> > > support at least inter
On 12/17/20 9:23 PM, Alexei Starovoitov wrote:
On Thu, Dec 17, 2020 at 8:33 PM Song Liu wrote:
ahh. I missed that. Makes sense.
vm_file needs to be accurate, but vm_area_struct should be accessed as
ptr_to_btf_id.
Passing pointer of vm_area_struct into BPF will be tricky. For example, sh
Hi,
On Thu, Dec 17, 2020 at 04:34:29PM -0600, Rob Herring wrote:
> The correct syntax for JSON pointers begins with a '/' after the '#'.
> Without a '/', the string should be interpretted as a subschema
> identifier. The jsonschema module currently doesn't handle subschema
> identifiers and incorr
On 12/11/20 9:11 AM, Jonathan Lemon wrote:
From: Jonathan Lemon
On some systems, some variant of the following splat is
repeatedly seen. The common factor in all traces seems
to be the entry point to task_file_seq_next(). With the
patch, all warnings go away.
rcu: INFO: rcu_sched sel
On 12/17/20 2:34 PM, Rob Herring wrote:
> The correct syntax for JSON pointers begins with a '/' after the '#'.
> Without a '/', the string should be interpretted as a subschema
> identifier. The jsonschema module currently doesn't handle subschema
> identifiers and incorrectly allows JSON pointers
On 18/12/2020 12:28:17-0400, Jason Gunthorpe wrote:
> On Fri, Dec 18, 2020 at 03:52:04PM +, Mark Brown wrote:
> > On Fri, Dec 18, 2020 at 10:08:54AM -0400, Jason Gunthorpe wrote:
> > > On Fri, Dec 18, 2020 at 01:17:09PM +, Mark Brown wrote:
> >
> > > > As previously discussed this will nee
> On Dec 18, 2020, at 8:38 AM, Yonghong Song wrote:
>
>
>
> On 12/17/20 9:23 PM, Alexei Starovoitov wrote:
>> On Thu, Dec 17, 2020 at 8:33 PM Song Liu wrote:
ahh. I missed that. Makes sense.
vm_file needs to be accurate, but vm_area_struct should be accessed as
ptr_to_
The driver is already allocating receive buffers of 2KiB and the
Ethernet MAC is configured to accept frames up to UMAC_MAX_MTU_SIZE.
Fixes: bfcb813203e6 ("net: dsa: configure the MTU for switch ports")
Signed-off-by: Florian Fainelli
---
drivers/net/ethernet/broadcom/bcmsysport.c | 1 +
1 file
> From: Alexander Duyck
> Sent: Friday, December 18, 2020 9:31 PM
>
> On Thu, Dec 17, 2020 at 9:20 PM Parav Pandit wrote:
> >
> >
> > > From: Alexander Duyck
> > > Sent: Friday, December 18, 2020 8:41 AM
> > >
> > > On Thu, Dec 17, 2020 at 5:30 PM David Ahern
> wrote:
> > > >
> > > > On 12/16
On Thu, 17 Dec 2020 14:03:07 -0800 Tom Rix wrote:
> On 12/17/20 9:28 AM, Jakub Kicinski wrote:
> > On Thu, 17 Dec 2020 05:17:24 -0800 Tom Rix wrote:
> >> On 12/16/20 4:45 PM, Jakub Kicinski wrote:
> >>> On Tue, 15 Dec 2020 06:22:28 -0800 t...@redhat.com wrote:
> From: Tom Rix
>
>
On Thu, Dec 17, 2020 at 04:34:29PM -0600, Rob Herring wrote:
> The correct syntax for JSON pointers begins with a '/' after the '#'.
> Without a '/', the string should be interpretted as a subschema
> identifier. The jsonschema module currently doesn't handle subschema
> identifiers and incorrectly
On Fri, Dec 18, 2020 at 12:28:17PM -0400, Jason Gunthorpe wrote:
> On Fri, Dec 18, 2020 at 03:52:04PM +, Mark Brown wrote:
> > On Fri, Dec 18, 2020 at 10:08:54AM -0400, Jason Gunthorpe wrote:
> > > I thought the recent LWN article summed it up nicely, auxillary bus is
> > > for gluing to subsy
On Fri, Dec 18, 2020 at 08:53:22AM -0800, Yonghong Song wrote:
>
>
> On 12/11/20 9:11 AM, Jonathan Lemon wrote:
> > From: Jonathan Lemon
> >
> > On some systems, some variant of the following splat is
> > repeatedly seen. The common factor in all traces seems
> > to be the entry point to task_
On 12/18/20 10:06 AM, Jonathan Lemon wrote:
On Fri, Dec 18, 2020 at 08:53:22AM -0800, Yonghong Song wrote:
On 12/11/20 9:11 AM, Jonathan Lemon wrote:
From: Jonathan Lemon
On some systems, some variant of the following splat is
repeatedly seen. The common factor in all traces seems
to be
On Fri, Dec 18, 2020 at 06:03:10PM +, Mark Brown wrote:
> On Fri, Dec 18, 2020 at 12:28:17PM -0400, Jason Gunthorpe wrote:
> > On Fri, Dec 18, 2020 at 03:52:04PM +, Mark Brown wrote:
> > > On Fri, Dec 18, 2020 at 10:08:54AM -0400, Jason Gunthorpe wrote:
>
> > > > I thought the recent LWN a
From: Jonathan Lemon
v3->v4:
Split commit into separate patches.
v2->v3:
Add splat to commitlog descriptions
v1->v2
Use Fixes: shas from correct tree
Jonathan Lemon (3):
bpf: save correct stopping point in file seq iteration.
bpf: Use thread_group_leader()
bpf: optimize task iteratio
From: Jonathan Lemon
On some systems, some variant of the following splat is
repeatedly seen. The common factor in all traces seems
to be the entry point to task_file_seq_next(). With the
patch, all warnings go away.
rcu: INFO: rcu_sched self-detected stall on CPU
rcu: \x0926-: (20
From: Jonathan Lemon
Instead of directly comparing task->tgid and task->pid, use the
thread_group_leader() helper. This helps with readability, and
there should be no functional change.
Signed-off-by: Jonathan Lemon
---
kernel/bpf/task_iter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
From: Jonathan Lemon
Only obtain the task reference count at the end of the RCU section
instead of repeatedly obtaining/releasing it when iterating though
a thread group.
Jump to the correct branch when it is known that the task is NULL.
Signed-off-by: Jonathan Lemon
---
kernel/bpf/task_iter.
On Fri, 18 Dec 2020, Jason Gunthorpe wrote:
> On Fri, Dec 18, 2020 at 06:03:10PM +, Mark Brown wrote:
> > On Fri, Dec 18, 2020 at 12:28:17PM -0400, Jason Gunthorpe wrote:
> > > On Fri, Dec 18, 2020 at 03:52:04PM +, Mark Brown wrote:
> > > > On Fri, Dec 18, 2020 at 10:08:54AM -0400, Jason G
On Wed, Dec 16, 2020 at 10:29 PM Cong Wang wrote:
>
> On Wed, Dec 16, 2020 at 10:35 AM Andrii Nakryiko
> wrote:
> >
> > On Tue, Dec 15, 2020 at 4:15 PM Cong Wang wrote:
> > >
> > > On Tue, Dec 15, 2020 at 2:08 PM Andrii Nakryiko
> > > wrote:
> > > >
> > > > On Tue, Dec 15, 2020 at 12:06 PM Cong
On Thu, Dec 17, 2020 at 1:14 PM Cong Wang wrote:
>
> On Wed, Dec 16, 2020 at 10:29 PM Cong Wang wrote:
> >
> > On Wed, Dec 16, 2020 at 10:35 AM Andrii Nakryiko
> > wrote:
> > > Minimize duplication of the code, no one said copy/paste all the code.
> > > But memory bloat is a real problem and sho
This series contains a couple of fixes and improvements on lib/fs.c
- in functions get_cgroup2_id() and get_cgroup2_path(), fixes cleanup on
single return point;
- in function make_path(), avoid to call mkdir() two times in a row.
Andrea Claudi (2):
lib/fs: avoid double call to mkdir on make_p
Functions get_cgroup2_id() and get_cgroup2_path() uncorrectly performs
cleanup on the single return point. Both of them may get to use close()
with a negative argument, if open() fails.
Fix this adding proper labels and gotos to make sure we clean up only
resources we are effectively used before.
make_path() function calls mkdir two times in a row. The first one it
stores mkdir return code, and then it calls it again to check for errno.
This seems unnecessary, as we can use the return code from the first
call and check for errno if not 0.
Signed-off-by: Andrea Claudi
---
lib/fs.c | 2 +-
On Fri, Dec 18, 2020 at 10:01 AM Parav Pandit wrote:
>
>
> > From: Alexander Duyck
> > Sent: Friday, December 18, 2020 9:31 PM
> >
> > On Thu, Dec 17, 2020 at 9:20 PM Parav Pandit wrote:
> > >
> > >
> > > > From: Alexander Duyck
> > > > Sent: Friday, December 18, 2020 8:41 AM
> > > >
> > > > On
On Fri, Dec 18, 2020 at 10:08 AM Jonathan Lemon
wrote:
>
> On Fri, Dec 18, 2020 at 08:53:22AM -0800, Yonghong Song wrote:
> >
> >
> > On 12/11/20 9:11 AM, Jonathan Lemon wrote:
> > > From: Jonathan Lemon
> > >
> > > On some systems, some variant of the following splat is
> > > repeatedly seen. T
On Thu, Dec 17, 2020 at 1:54 AM Christophe Leroy
wrote:
>
>
>
> Le 17/12/2020 à 07:11, Alexei Starovoitov a écrit :
> > On Wed, Dec 16, 2020 at 10:07:37AM +, Christophe Leroy wrote:
> >> Implement Extended Berkeley Packet Filter on Powerpc 32
> >>
> >> Test result with test_bpf module:
> >>
>
This comes from an end-user request, where they're running multiple VMs on
hosts with bonded interfaces connected to some interest switch topologies,
where 802.3ad isn't an option. They're currently running a proprietary
solution that effectively achieves load-balancing of VMs and bandwidth
utiliza
On Wed, 16 Dec 2020 20:44:21 -0800 Saeed Mahameed wrote:
> On Wed, 2020-12-16 at 15:59 -0800, Jakub Kicinski wrote:
> > On Wed, 16 Dec 2020 03:42:51 + Parav Pandit wrote:
> > > > From: Jakub Kicinski
> > > > So subfunctions don't have a VF id but they may have a
> > > > controller?
> > > >
On Thu, 17 Dec 2020 05:46:45 + Parav Pandit wrote:
> > From: Jakub Kicinski
> > Sent: Thursday, December 17, 2020 5:39 AM
> >
> > On Wed, 16 Dec 2020 05:15:04 + Parav Pandit wrote:
> > > > From: Jakub Kicinski
> > > > Sent: Wednesday, December 16, 2020 6:08 AM
> > > >
> > > > On Tue, 1
On Thu, 17 Dec 2020 05:23:10 + Parav Pandit wrote:
> > From: Jakub Kicinski
> > Sent: Thursday, December 17, 2020 5:42 AM
> >
> > On Wed, 16 Dec 2020 05:19:15 + Parav Pandit wrote:
> > > > From: Jakub Kicinski
> > > > Sent: Wednesday, December 16, 2020 6:14 AM
> > > >
> > > > On Tue, 1
On Thu, Dec 17, 2020 at 9:30 AM Jesper Dangaard Brouer
wrote:
>
> Adding selftest for BPF-helper bpf_check_mtu(). Making sure
> it can be used from both XDP and TC.
>
> Signed-off-by: Jesper Dangaard Brouer
> ---
> tools/testing/selftests/bpf/prog_tests/check_mtu.c | 204
>
On Fri, Dec 18, 2020 at 07:09:11PM +, Lee Jones wrote:
> ACPI, DT and MFD are not busses.
And yet ACPI and PNP have a bus:
extern struct bus_type acpi_bus_type;
extern struct bus_type pnp_bus_type;
Why? Because in the driver core if you subclass struct device and want
to bind drivers,
On Thu, 17 Dec 2020 12:40:26 -0800 Ben Greear wrote:
> On 12/17/20 10:20 AM, Eric Dumazet wrote:
> > On Thu, Dec 17, 2020 at 7:13 PM Ben Greear wrote:
> >
> >> It is the iwlwifi/mvm logic that supports ax200.
> >
> > Let me ask again :
> >
> > I see two different potential call points :
> >
From: Jonathan Lemon
In preparation for further work, the zcopy* routines will
become basic building blocks, while the zerocopy* ones will
be specific for the existing zerocopy implementation.
All uargs should have a callback function, (unless nouarg
is set), so push all special case logic handl
From: Jonathan Lemon
Currently, an ubuf is attached to a new skb, the skb zc_flags
is initialized to a fixed value. Instead of doing this, set
the default zc_flags in the ubuf, and have new skb's inherit
from this default.
This is needed when setting up different zerocopy types.
Signed-off-by:
From: Jonathan Lemon
This is set of cleanup patches for zerocopy which are intended
to allow a introduction of a different zerocopy implementation.
The top level api will use the skb_zcopy_*() functions, while
the current TCP specific zerocopy would use the sock_zerocopy_*()
calls.
There should
From: Jonathan Lemon
skb_zcopy_abort() has no in-tree consumers, remove it.
Signed-off-by: Jonathan Lemon
---
include/linux/skbuff.h | 11 ---
1 file changed, 11 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 69588b304f83..fb6dd6af0f82 100644
--- a/inc
From: Jonathan Lemon
Add an optional skb parameter to the zerocopy callback parameter,
which is passed down from skb_zcopy_clear(). This gives access
to the original skb, which is needed for upcoming RX zero-copy
error handling.
Signed-off-by: Jonathan Lemon
---
drivers/net/tap.c
From: Jonathan Lemon
Rename the get routines for consistency.
Signed-off-by: Jonathan Lemon
---
include/linux/skbuff.h | 4 ++--
net/core/skbuff.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index df98d61e8c51..638
From: Jonathan Lemon
The sock_zerocopy_put_abort function contains logic which is
specific to the current zerocopy implementation. Add a wrapper
which checks the callback and dispatches apppropriately.
Signed-off-by: Jonathan Lemon
---
include/linux/skbuff.h | 10 ++
net/core/skbuff.c
From: Jonathan Lemon
In preparation for expanded zerocopy (TX and RX), move
the ZC related bits out of tx_flags into their own flag
word.
Signed-off-by: Jonathan Lemon
---
drivers/net/tap.c | 3 +--
drivers/net/tun.c | 3 +--
drivers/net/xen-netback/interf
From: Jonathan Lemon
RX zerocopy fragment pages which are not allocated from the
system page pool require special handling. Give the callback
in skb_zcopy_clear() a chance to process them first.
Signed-off-by: Jonathan Lemon
---
net/core/skbuff.c | 3 ++-
1 file changed, 2 insertions(+), 1 de
From: Jonathan Lemon
Replace direct assignments with skb_zcopy_set() for clarity.
Signed-off-by: Jonathan Lemon
---
drivers/net/tap.c | 3 +--
drivers/net/tun.c | 3 +--
drivers/vhost/net.c | 1 +
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/tap.c b/drivers/ne
On Fri, Dec 18, 2020 at 11:22:12AM -0800, Alexander Duyck wrote:
> Also as far as the patch count complaints I have seen in a few threads
> I would be fine with splitting things up so that the devlink and aux
> device creation get handled in one set, and then we work out the
> details of mlx5 atta
On Thu, 17 Dec 2020 16:34:29 -0600 Rob Herring wrote:
> The correct syntax for JSON pointers begins with a '/' after the '#'.
> Without a '/', the string should be interpretted as a subschema
> identifier. The jsonschema module currently doesn't handle subschema
> identifiers and incorrectly allows
Hi Florian,
On Fri, Dec 18, 2020 at 09:38:43AM -0800, Florian Fainelli wrote:
> The driver is already allocating receive buffers of 2KiB and the
> Ethernet MAC is configured to accept frames up to UMAC_MAX_MTU_SIZE.
>
> Fixes: bfcb813203e6 ("net: dsa: configure the MTU for switch ports")
> Signed
Hello:
This patch was applied to netdev/net.git (refs/heads/master):
On Wed, 16 Dec 2020 09:28:04 +0200 you wrote:
> On 64-bit systems the packet procfs header field names following 'sk'
> are not aligned correctly:
>
> sk RefCnt Type Proto Iface R Rmem User Inode
> 605d2c64 3
On 12/18/20 12:24 PM, Vladimir Oltean wrote:
> Hi Florian,
>
> On Fri, Dec 18, 2020 at 09:38:43AM -0800, Florian Fainelli wrote:
>> The driver is already allocating receive buffers of 2KiB and the
>> Ethernet MAC is configured to accept frames up to UMAC_MAX_MTU_SIZE.
>>
>> Fixes: bfcb813203e6 ("n
On Fri, Dec 18, 2020 at 02:41:50PM -0400, Jason Gunthorpe wrote:
> On Fri, Dec 18, 2020 at 06:03:10PM +, Mark Brown wrote:
> > If it's not supposed to use platform devices so I'm assuming that the
> > intention is that it should use aux devices, otherwise presumably it'd
> > be making some new
On Fri, Dec 18, 2020 at 3:23 PM Jonathan Lemon wrote:
>
> From: Jonathan Lemon
>
> This is set of cleanup patches for zerocopy which are intended
> to allow a introduction of a different zerocopy implementation.
Can you describe in more detail what exactly is lacking in the current
zerocopy inte
On Fri, Dec 18, 2020 at 12:30:20PM -0800, Florian Fainelli wrote:
> On 12/18/20 12:24 PM, Vladimir Oltean wrote:
> > Hi Florian,
> >
> > On Fri, Dec 18, 2020 at 09:38:43AM -0800, Florian Fainelli wrote:
> >> The driver is already allocating receive buffers of 2KiB and the
> >> Ethernet MAC is conf
On 12/18/20 12:52 PM, Vladimir Oltean wrote:
> On Fri, Dec 18, 2020 at 12:30:20PM -0800, Florian Fainelli wrote:
>> On 12/18/20 12:24 PM, Vladimir Oltean wrote:
>>> Hi Florian,
>>>
>>> On Fri, Dec 18, 2020 at 09:38:43AM -0800, Florian Fainelli wrote:
The driver is already allocating receive bu
On Fri, Dec 18, 2020 at 08:32:11PM +, Mark Brown wrote:
> > So, I strongly suspect, MFD should create mfd devices on a MFD bus
> > type.
>
> Historically people did try to create custom bus types, as I have
> pointed out before there was then pushback that these were duplicating
> the platfor
On Fri, Dec 18, 2020 at 12:47 PM Jonathan Lemon
wrote:
>
> From: Jonathan Lemon
>
> On some systems, some variant of the following splat is
> repeatedly seen. The common factor in all traces seems
> to be the entry point to task_file_seq_next(). With the
> patch, all warnings go away.
>
> r
On Fri, Dec 18, 2020 at 12:47 PM Jonathan Lemon
wrote:
>
> From: Jonathan Lemon
>
> Instead of directly comparing task->tgid and task->pid, use the
> thread_group_leader() helper. This helps with readability, and
> there should be no functional change.
>
> Signed-off-by: Jonathan Lemon
> ---
A
On Fri, Dec 18, 2020 at 12:54:33PM -0800, Florian Fainelli wrote:
> On 12/18/20 12:52 PM, Vladimir Oltean wrote:
> > On Fri, Dec 18, 2020 at 12:30:20PM -0800, Florian Fainelli wrote:
> >> On 12/18/20 12:24 PM, Vladimir Oltean wrote:
> >>> Hi Florian,
> >>>
> >>> On Fri, Dec 18, 2020 at 09:38:43AM -
On Fri, Dec 18, 2020 at 12:47 PM Jonathan Lemon
wrote:
>
> From: Jonathan Lemon
>
> Only obtain the task reference count at the end of the RCU section
> instead of repeatedly obtaining/releasing it when iterating though
> a thread group.
>
> Jump to the correct branch when it is known that the ta
On 12/18/20 1:02 PM, Vladimir Oltean wrote:
> On Fri, Dec 18, 2020 at 12:54:33PM -0800, Florian Fainelli wrote:
>> On 12/18/20 12:52 PM, Vladimir Oltean wrote:
>>> On Fri, Dec 18, 2020 at 12:30:20PM -0800, Florian Fainelli wrote:
On 12/18/20 12:24 PM, Vladimir Oltean wrote:
> Hi Florian,
>
On Fri, Dec 18, 2020 at 01:08:58PM -0800, Florian Fainelli wrote:
> On 12/18/20 1:02 PM, Vladimir Oltean wrote:
> > On Fri, Dec 18, 2020 at 12:54:33PM -0800, Florian Fainelli wrote:
> >> On 12/18/20 12:52 PM, Vladimir Oltean wrote:
> >>> On Fri, Dec 18, 2020 at 12:30:20PM -0800, Florian Fainelli wr
On Fri, Dec 18, 2020 at 03:49:44PM -0500, Willem de Bruijn wrote:
> On Fri, Dec 18, 2020 at 3:23 PM Jonathan Lemon
> wrote:
> >
> > From: Jonathan Lemon
> >
> > This is set of cleanup patches for zerocopy which are intended
> > to allow a introduction of a different zerocopy implementation.
>
>
On 18/12/2020 16:58:56-0400, Jason Gunthorpe wrote:
> On Fri, Dec 18, 2020 at 08:32:11PM +, Mark Brown wrote:
>
> > > So, I strongly suspect, MFD should create mfd devices on a MFD bus
> > > type.
> >
> > Historically people did try to create custom bus types, as I have
> > pointed out before
1 - 100 of 141 matches
Mail list logo
