The x64 bpf jit expects bpf images converge within the given passes, but
it could fail to do so with some corner cases. For example:
l0: ja 40
l1: ja 40
[... repeated ja 40 ]
l39:ja 40
l40:ret #0
This bpf program contains 40 "ja 40" instructions w
There are two tests added into verifier's jit tests to trigger x64
jit jump padding. The first test can be represented as the following
assembly code:
1: bpf_call bpf_get_prandom_u32
2: if r0 == 0 goto pc+128
3: if r0 == 1 goto pc+128
...
129: if r0 == 127 goto pc+12
With NOPs padding, x64 jit now can handle the jump cases like
bpf_fill_maxinsns11().
Signed-off-by: Gary Lin
---
lib/test_bpf.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/lib/test_bpf.c b/lib/test_bpf.c
index ca7d635bccd9..272a9fd143ab 100644
--- a/lib/test_bpf.c
+
This patch series implements jump padding to x64 jit to cover some
corner cases that used to consume more than 20 passes and caused
failure.
v2:
- Simplify the sample code in the commit description and provide the
jit code
- Check the expected padding bytes with WARN_ONCE
- Move the 'pad
On 17-12-20, 16:34, 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 Thu, Dec 17, 2020 at 10:19:37PM +0100, Alexandre Belloni wrote:
> Hello,
>
> On 05/12/2020 16:51:36+0100, Greg KH wrote:
> > > To me, the documentation was written, and reviewed, more from the
> > > perspective of "why not open code a custom bus instead". So I can see
> > > after the fact how t
Remove tcp_low_latency, since it is not functional After commit
e7942d0633c4 (tcp: remove prequeue support)
Signed-off-by: lyl
---
net/ipv4/sysctl_net_ipv4.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index 3e5f4f2..d03e
On Tue, Dec 15, 2020 at 07:45:16PM +0200, Andy Shevchenko wrote:
> On Tue, Dec 15, 2020 at 6:44 PM Calvin Johnson
> wrote:
> >
> > Using fwnode_get_id(), get the reg property value for DT node
> > and get the _ADR object value for ACPI node.
>
> and -> or
>
> ...
>
> > +/**
> > + * fwnode_get_i
Hi Laurent,
Thanks for reviewing.
On Tue, Dec 15, 2020 at 07:00:28PM +0200, Laurent Pinchart wrote:
> Hi Calvin,
>
> Thank you for the patch.
>
> On Tue, Dec 15, 2020 at 10:13:11PM +0530, Calvin Johnson wrote:
> > Using fwnode_get_id(), get the reg property value for DT node
> > and get the _ADR
On Tue, Dec 15, 2020 at 07:55:01PM +0200, Andy Shevchenko wrote:
> On Tue, Dec 15, 2020 at 6:44 PM Calvin Johnson
> wrote:
> >
> > fwnode_mdiobus_register() internally takes care of both DT
> > and ACPI cases to register mdiobus. Replace existing
> > of_mdiobus_register() with fwnode_mdiobus_regis
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:
> >
> > Introduce fwnode_mdiobus_register() to register PHYs on the mdiobus.
> > If the fwnode is DT node, then call of_mdiobus_register().
> > If it is an ACPI node, then:
>
> From: Parav Pandit
> Sent: Friday, December 18, 2020 10:51 AM
>
> > 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 designe
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:
> >
> > Introduce fwnode_mdiobus_register_phy() to register PHYs on the
> > mdiobus. From the compatible string, identify whether the PHY is
> > c45 and based on this create a
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, shall
> we
> allow the user to access
> 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 as a network switch
> fabric and when we start talking about a 400Gb
> On Dec 17, 2020, at 6:34 PM, Alexei Starovoitov
> wrote:
>
> On Thu, Dec 17, 2020 at 10:08:31PM +, Song Liu wrote:
>>
>>
>>> On Dec 17, 2020, at 11:03 AM, Alexei Starovoitov
>>> wrote:
>>>
>>> On Tue, Dec 15, 2020 at 03:36:59PM -0800, Song Liu wrote:
+/*
+ * Key informati
pneigh_enqueue() tries to obtain a random delay by mod
NEIGH_VAR(p, PROXY_DELAY). However, NEIGH_VAR(p, PROXY_DELAY)
migth be zero at that point because someone could write zero
to /proc/sys/net/ipv4/neigh/[device]/proxy_delay after the
callers check it.
This patch double-checks NEIGH_VAR(p, PROXY
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 became a problem and it was easily shown that bypassing the
>>> N
Hi Stefan,
czw., 17 gru 2020 o 15:54 napisał(a):
>
> From: Stefan Chulski
>
> Force link UP can be enabled by bootloader during tftpboot
> and breaks NFS support.
> Force link UP disabled during port init procedure.
>
> Fixes: f84bf386f395 ("net: mvpp2: initialize the GoP")
> Signed-off-by: Stef
Hi Stefan,
czw., 17 gru 2020 o 13:40 napisał(a):
>
> From: Stefan Chulski
>
> During GoP port 2 Networking Complex Control mode of operation configurations,
> also GoP port 3 mode of operation was wrongly set.
> Patch removes these configurations.
> GENCONF_CTRL0_PORTX naming also fixed.
>
> Cc:
On 12/17/20 6:34 PM, Alexei Starovoitov wrote:
On Thu, Dec 17, 2020 at 10:08:31PM +, Song Liu wrote:
On Dec 17, 2020, at 11:03 AM, Alexei Starovoitov
wrote:
On Tue, Dec 15, 2020 at 03:36:59PM -0800, Song Liu wrote:
+/*
+ * Key information from vm_area_struct. We need this because w
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 became a problem and it was easily shown that bypassing the
> > NIC for traffic was significantly faster.
>
> If
On 2020/12/18 上午6:28, Michael S. Tsirkin wrote:
On Thu, Dec 17, 2020 at 05:02:49PM +0800, Jason Wang wrote:
On 2020/12/17 下午3:58, Michael S. Tsirkin wrote:
On Thu, Dec 17, 2020 at 11:30:18AM +0800, Jason Wang wrote:
On 2020/12/16 下午5:47, Michael S. Tsirkin wrote:
On Wed, Dec 16, 2020 at 02:
/git/davem/net-next.git
13458ffe0a953e17587f172a8e5059c243e6850a
config: powerpc-randconfig-r025-20201217 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
cee1e7d14f4628d6174b33640d502bff3b54ae45)
reproduce (this is a W=1 build):
wget
https
On Thu, Dec 17, 2020 at 1:20 PM Alexandre Belloni
wrote:
>
> Hello,
>
> On 05/12/2020 16:51:36+0100, Greg KH wrote:
> > > To me, the documentation was written, and reviewed, more from the
> > > perspective of "why not open code a custom bus instead". So I can see
> > > after the fact how that is a
On Thu, Dec 17, 2020 at 10:08:31PM +, Song Liu wrote:
>
>
> > On Dec 17, 2020, at 11:03 AM, Alexei Starovoitov
> > wrote:
> >
> > On Tue, Dec 15, 2020 at 03:36:59PM -0800, Song Liu wrote:
> >> +/*
> >> + * Key information from vm_area_struct. We need this because we cannot
> >> + * assume
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 types.
Larger types (e.g. 1024 bits) are possible but I am unaware of a use
case for these.
This requires the _ExtInt
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 became a problem and it was easily shown that bypassing the
> NIC for traffic was significantly faster.
If a deployment expects a lot of east-west traffic *within a host* w
On 12/7/20 2:06 PM, Boris Pismenny wrote:
> +struct sk_buff*
> +mlx5e_nvmeotcp_handle_rx_skb(struct net_device *netdev, struct sk_buff *skb,
> + struct mlx5_cqe64 *cqe, u32 cqe_bcnt,
> + bool linear)
> +{
> + int ccoff, cclen, hlen, ccid, remain
On 12/17/20 12:06 PM, Boris Pismenny wrote:
>
>
> On 15/12/2020 7:19, David Ahern wrote:
>> On 12/13/20 11:21 AM, Boris Pismenny wrote:
> as zerocopy for the following reasons:
> (1) The former places buffers *exactly* where the user requests
> regardless of the order of response arri
On Thu, Dec 17, 2020 at 01:05:03PM -0800, Alexander Duyck wrote:
> > I view the SW bypass path you are talking about similarly to
> > GSO/etc. It should be accessed by the HW driver as an optional service
> > provided by the core netdev, not implemented as some wrapper netdev
> > around a HW imple
On Thu, Dec 17, 2020 at 12:21 AM Bjorn Helgaas wrote:
>
> On Wed, Dec 16, 2020 at 12:20:53PM +0100, Ian Kumlien wrote:
> > On Wed, Dec 16, 2020 at 1:08 AM Bjorn Helgaas wrote:
> > > On Tue, Dec 15, 2020 at 02:09:12PM +0100, Ian Kumlien wrote:
> > > > On Tue, Dec 15, 2020 at 1:40 AM Bjorn Helgaas
On Thu, Dec 17, 2020 at 2:57 PM Ben Greear wrote:
> On 12/17/20 2:24 PM, Brian Norris wrote:
> > I'd also note that we don't operate in AP mode -- only STA -- and IIRC
> > Ben, you've complained about AP mode in the past.
>
> I complain about all sorts of things, but I'm usually running
> station
Just like MGMT_OP_START_DISCOVERY, we should reject
MGMT_OP_START_SERVICE_DISCOVERY with MGMT_STATUS_BUSY when we are paused
for suspend.
Signed-off-by: Abhishek Pandit-Subedi
---
On ChromeOS, we started getting reports of scanning failing after
resuming from suspend. The root cause was that Star
On 12/17/20 2:24 PM, Brian Norris wrote:
On Tue, Dec 15, 2020 at 10:23:33AM -0800, Ben Greear wrote:
On 12/15/20 9:21 AM, Youghandhar Chintala wrote:
From: Rakesh Pillai
Currently in case of target hardware restart ,we just reconfig and
re-enable the security keys and enable the network queue
This moves msft_do_close() from hci_dev_do_close() to
hci_unregister_dev() to avoid clearing MSFT extension info. This also
avoids retrieving MSFT info upon every msft_do_open() if MSFT extension
has been initialized.
The following test steps were performed.
(1) boot the test device and verify the
On 12/16/20 1:22 AM, Cong Wang wrote:
On Tue, Dec 15, 2020 at 3:23 PM Daniel Borkmann wrote:
On 12/15/20 11:03 PM, Andrii Nakryiko wrote:
On Tue, Dec 15, 2020 at 12:06 PM Cong Wang wrote:
On Tue, Dec 15, 2020 at 11:27 AM Andrii Nakryiko
wrote:
On Mon, Dec 14, 2020 at 12:17 PM Cong Wang
From: Sylwester Dziedziuch
When removing VFs for PF added to bridge there was
an error I40E_AQ_RC_EINVAL. It was caused by not properly
resetting and reinitializing PF when adding/removing VFs.
Changed how reset is performed when adding/removing VFs
to properly reinitialize PFs VSI.
Fixes: fc608
This series contains updates to i40e and iavf drivers.
Sylwester fixes an issue where PF was not properly being rebuilt
following VF removal for i40e.
Jakub Kicinski fixes a double release of rtnl_lock on
iavf_lan_add_device() error for iavf.
The following are changes since commit 44d4775ca51805
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 to begin without a '/'.
Let's fix this before i
From: Jakub Kicinski
This code does not jump to exit on an error in iavf_lan_add_device(),
so the rtnl_unlock() from the normal path will follow.
Fixes: b66c7bc1cd4d ("iavf: Refactor init state machine")
Signed-off-by: Jakub Kicinski
Reviewed-by: Tony Nguyen
Tested-by: Konrad Jankowski
Signed
On Tue, Dec 15, 2020 at 10:51:13PM +0530, Youghandhar Chintala wrote:
> From: Rakesh Pillai
I meant to mention in my other reply: the threading on this series is
broken (as in, it doesn't exist). It looks like you're using
git-send-email (good!), but somehow it doesn't have any In-Reply-To or
Ref
On Thu, Dec 17, 2020 at 05:02:49PM +0800, Jason Wang wrote:
>
> On 2020/12/17 下午3:58, Michael S. Tsirkin wrote:
> > On Thu, Dec 17, 2020 at 11:30:18AM +0800, Jason Wang wrote:
> > > On 2020/12/16 下午5:47, Michael S. Tsirkin wrote:
> > > > On Wed, Dec 16, 2020 at 02:47:57PM +0800, Jason Wang wrote:
On Tue, Dec 15, 2020 at 10:23:33AM -0800, Ben Greear wrote:
> On 12/15/20 9:21 AM, Youghandhar Chintala wrote:
> > From: Rakesh Pillai
> >
> > Currently in case of target hardware restart ,we just reconfig and
> > re-enable the security keys and enable the network queues to start
> > data traffic
> On Dec 17, 2020, at 11:03 AM, Alexei Starovoitov
> wrote:
>
> On Tue, Dec 15, 2020 at 03:36:59PM -0800, Song Liu wrote:
>> +/*
>> + * Key information from vm_area_struct. We need this because we cannot
>> + * assume the vm_area_struct is still valid after each iteration.
>> + */
>> +struct
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
See Documentation/core-api/printk-formats.rst.
h should n
Hello:
This patch was applied to bpf/bpf.git (refs/heads/master):
On Mon, 14 Dec 2020 09:51:27 +0100 you wrote:
> From: Magnus Karlsson
>
> Fix a possible memory leak when a bind of an AF_XDP socket fails. When
> the fill and completion rings are created, they are tied to the
> socket. But when
The pull request you sent on Thu, 17 Dec 2020 13:02:04 -0800:
> git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git tags/net-5.11-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d64c6f96ba86bd8b97ed8d6762a8c8cc1770d214
Thank you!
--
Deet-doot-dot, I am a
taprio_graft() can insert a NULL element in the array of child qdiscs. As
a consquence, taprio_reset() might not reset child qdiscs completely, and
taprio_destroy() might leak resources. Fix it by ensuring that loops that
iterate over q->qdiscs[] don't end when they find the first NULL item.
Fixes
On Thu, Dec 17, 2020 at 2:48 PM Jakub Kicinski wrote:
>
> On Tue, 15 Dec 2020 18:51:17 +0200 Baruch Siach wrote:
> > Before commit 889b8f964f2f ("packet: Kill CONFIG_PACKET_MMAP.") there
> > used to be a CONFIG_PACKET_MMAP config symbol that depended on
> > CONFIG_PACKET. The text still refers to
Hello,
On 05/12/2020 16:51:36+0100, Greg KH wrote:
> > To me, the documentation was written, and reviewed, more from the
> > perspective of "why not open code a custom bus instead". So I can see
> > after the fact how that is a bit too much theory and justification and
> > not enough practical app
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 should be justification enough
> > to at least consider other optio
On Thu, Dec 17, 2020 at 11:40 AM Jason Gunthorpe wrote:
>
> On Thu, Dec 17, 2020 at 10:48:48AM -0800, Alexander Duyck wrote:
>
> > Just to clarify I am not with Intel, nor do I plan to work on any
> > Intel drivers related to this.
>
> Sure
>
> > I disagree here. In my mind a design where two inte
Hi Linus,
quick PR with some fixes which already came in this week,
since I'm not planning on sending one next week.
Happy Holidays!
The following changes since commit 3db1a3fa98808aa90f95ec3e0fa2fc7abf28f5c9:
Merge tag 'staging-5.11-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/greg
On Thu, 2020-12-17 at 12:45 -0800, Jakub Kicinski wrote:
> Right, but that's init, look at taprio_graft(). The child qdiscs can be
> replaced at any time. And the replacement can be NULL otherwise why
> would graft check "if (new)"
good point, you are right. I'll send a follow-up patch right now.
On Thu, 17 Dec 2020 21:32:29 +0100 Davide Caratti wrote:
> hello Jakub, and thanks for checking!
>
> On Thu, 2020-12-17 at 11:05 -0800, Jakub Kicinski wrote:
> > On Wed, 16 Dec 2020 19:33:29 +0100 Davide Caratti wrote:
> > > + if (q->qdiscs) {
> > > + for (i = 0; i < dev->num_tx_queues &
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 :
drivers/net/wireless/intel/iwlwifi/pcie/tx.c:1529:
tso_build_hdr(skb, hdr_page->po
hello Jakub, and thanks for checking!
On Thu, 2020-12-17 at 11:05 -0800, Jakub Kicinski wrote:
> On Wed, 16 Dec 2020 19:33:29 +0100 Davide Caratti wrote:
> > + if (q->qdiscs) {
> > + for (i = 0; i < dev->num_tx_queues && q->qdiscs[i]; i++)
> > + qdisc_reset(q->qdiscs[
On Thu, 2020-12-17 at 19:28 +0100, Maciej Fijalkowski wrote:
> On Thu, Dec 17, 2020 at 10:16:06AM -0800, Saeed Mahameed wrote:
> > On Wed, 2020-12-16 at 16:01 +0100, Lorenzo Bianconi wrote:
> > > > On Tue, 15 Dec 2020 14:47:10 +0100
> > > > Lorenzo Bianconi wrote:
> > > >
> > > > > [...]
> > > >
Hi Jason,
I love your patch! Perhaps something to improve:
[auto build test WARNING on vhost/linux-next]
[also build test WARNING on linus/master v5.10]
[cannot apply to next-20201217]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest
It was <2020-12-17 czw 11:08>, when Jakub Kicinski wrote:
> On Thu, 17 Dec 2020 12:53:30 +0100 Łukasz Stelmach wrote:
>> ASIX AX88796[1] is a versatile ethernet adapter chip, that can be
>> connected to a CPU with a 8/16-bit bus or with an SPI. This driver
>> supports SPI connection.
>>
>> The dri
On 17.12.20 18:59, Jakub Kicinski wrote:
> On Thu, 17 Dec 2020 09:25:48 +0100 Ahmad Fatoum wrote:
>> On 17.12.20 02:13, Jakub Kicinski wrote:
+ netdev_warn(priv->dev, "HW Timestamping init failed:
%pe\n",
+ ERR_PTR(ret));
>>>
>>> w
On Thu, 2020-12-17 at 10:52 -0800, Jakub Kicinski wrote:
> On Wed, 16 Dec 2020 16:14:45 -0800 Jakub Kicinski wrote:
> > On Mon, 14 Dec 2020 12:08:46 -0800 Saeed Mahameed wrote:
> > > I will change this and attach this patch to my PR of the SF
> > > support.
> >
> > Looks like the SF discussion w
On Thu, Dec 17, 2020 at 10:48:48AM -0800, Alexander Duyck wrote:
> Just to clarify I am not with Intel, nor do I plan to work on any
> Intel drivers related to this.
Sure
> I disagree here. In my mind a design where two interfaces, which both
> exist in the kernel, have to go to hardware in ord
On Thu, 17 Dec 2020 12:53:30 +0100 Łukasz Stelmach wrote:
> ASIX AX88796[1] is a versatile ethernet adapter chip, that can be
> connected to a CPU with a 8/16-bit bus or with an SPI. This driver
> supports SPI connection.
>
> The driver has been ported from the vendor kernel for ARTIK5[2]
> boards
On Thu, 17 Dec 2020 12:53:27 +0100 Łukasz Stelmach wrote:
> This is a driver for AX88796C Ethernet Adapter connected in SPI mode as
> found on ARTIK5 evaluation board. The driver has been ported from a
> v3.10.9 vendor kernel for ARTIK5 board.
# Form letter - net-next is closed
We have already se
On 15/12/2020 7:19, David Ahern wrote:
> On 12/13/20 11:21 AM, Boris Pismenny wrote:
as zerocopy for the following reasons:
(1) The former places buffers *exactly* where the user requests
regardless of the order of response arrivals, while the latter places
packets
in a
On Wed, 16 Dec 2020 19:33:29 +0100 Davide Caratti wrote:
> + if (q->qdiscs) {
> + for (i = 0; i < dev->num_tx_queues && q->qdiscs[i]; i++)
> + qdisc_reset(q->qdiscs[i]);
Are you sure that we can't graft a NULL in the middle of the array?
Shouldn't this be:
On Wed, 16 Dec 2020 15:57:01 +0100 Simon Horman wrote:
> The indirect block cleanup may cause control messages to be sent
> if offloaded flows are present. However, by the time the flower app
> cleanup callback is called txbufs are no longer available and attempts
> to send control messages result
On Wed, 16 Dec 2020 11:01:54 -0800 Vinicius Costa Gomes wrote:
> Davide Caratti writes:
>
> > syzkaller shows that packets can still be dequeued while taprio_destroy()
> > is running. Let sch_taprio use the reset() function to cancel the advance
> > timer and drop all skbs from the child qdiscs.
On Tue, Dec 15, 2020 at 03:36:59PM -0800, Song Liu wrote:
> +/*
> + * Key information from vm_area_struct. We need this because we cannot
> + * assume the vm_area_struct is still valid after each iteration.
> + */
> +struct __vm_area_struct {
> + __u64 start;
> + __u64 end;
> + __u64 fl
On Thu, 17 Dec 2020 05:24:34 + George Cherian wrote:
> > From: Colin Ian King
> >
> > Currently the check for an unmap PF error is always going to be false
> > because
> > intr_val is a 32 bit int and is being bit-mask checked against 1ULL << 32.
> > Fix
> > this by making intr_val a u64 t
Hello:
This patch was applied to netdev/net.git (refs/heads/master):
On Wed, 16 Dec 2020 11:38:04 +0300 you wrote:
> Return -EINVAL if we can't find the correct device. Currently it
> returns success.
>
> Fixes: 13159183ec7a ("qlcnic: 83xx base driver")
> Signed-off-by: Dan Carpenter
> ---
>
Hello:
This patch was applied to netdev/net.git (refs/heads/master):
On Wed, 16 Dec 2020 12:00:20 + you wrote:
> From: Colin Ian King
>
> There is a spelling mistake in the Kconfig. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/net/ethernet/ni/Kconfig | 2 +-
> 1 file changed
On 15/12/2020 15:33, Shai Malin wrote:
> On 12/14/2020 08:38, Boris Pismenny wrote:
>> On 10/12/2020 19:15, Shai Malin wrote:
>>> diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c index
>>> c0c33320fe65..ef96e4a02bbd 100644
>>> --- a/drivers/nvme/host/tcp.c
>>> +++ b/drivers/nvme/h
On Wed, 16 Dec 2020 16:14:45 -0800 Jakub Kicinski wrote:
> On Mon, 14 Dec 2020 12:08:46 -0800 Saeed Mahameed wrote:
> > I will change this and attach this patch to my PR of the SF support.
>
> Looks like the SF discussion will not wind down in time to make this
> merge window, so I think I'm goi
On Wed, Dec 16, 2020 at 4:38 PM Jason Gunthorpe wrote:
>
> On Wed, Dec 16, 2020 at 02:53:07PM -0800, Alexander Duyck wrote:
>
> > It isn't about the association, it is about who is handling the
> > traffic. Going back to the macvlan model what we did is we had a group
> > of rings on the device th
On Thu, Dec 17, 2020 at 06:11:50PM +0530, Divya Koppera wrote:
> +struct lan8814_ptphdr {
> + u8 tsmt; /* transportSpecific | messageType */
> + u8 ver; /* reserved0 | versionPTP */
> + __be16 msglen;
> + u8 domain;
> + u8 rsrvd1;
> + __be16 flags;
> + __be64 correctio
On 12/17/20 11:30 AM, Victor Stewart wrote:
> might this still make it into 5.11?
Doesn't meet the criteria to go in at this point. I sometimes
make exceptions, but generally speaking, something going into
5.11 should have been completed at least a week ago.
So I'd feel more comfortable pushing t
From: Stefan Chulski
Current PPPoE+IPv6 entry is jumping to 'next-hdr'
field and not to 'DIP' field as done for IPv4.
Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network
unit")
Reported-by: Liron Himi
Signed-off-by: Stefan Chulski
---
Changes in v2:
- Fix "fixes tag
On Thu, Dec 17, 2020 at 10:16:06AM -0800, Saeed Mahameed wrote:
> On Wed, 2020-12-16 at 16:01 +0100, Lorenzo Bianconi wrote:
> > > On Tue, 15 Dec 2020 14:47:10 +0100
> > > Lorenzo Bianconi wrote:
> > >
> > > > [...]
> > > > > > xdp_act = bpf_prog_run_xdp(xdp_prog, &xdp);
> > > > > > diff --gi
On Tue, 15 Dec 2020 19:18:19 +0200 Baruch Siach wrote:
> Signed-off-by: Baruch Siach
> ---
> Documentation/networking/netdev-FAQ.rst | 18 +++---
> 1 file changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/networking/netdev-FAQ.rst
> b/Documentation/networking/
On 12/17/20 8:53 AM, Shuah Khan wrote:
On 12/17/20 6:07 AM, Mark Brown wrote:
On Wed, Dec 16, 2020 at 04:05:58PM -0600, Seth Forshee wrote:
On Thu, Dec 10, 2020 at 06:52:33PM +, Mark Brown wrote:
as part of the wider kselftest build by specifying SKIP_TARGETS,
including setting an empty
From: Stefan Chulski
Issue:
Flow control frame used to pause GoP(MAC) was delivered to the CPU
and created a load on the CPU. Since XOFF/XON frames are used only
by MAC, these frames should be dropped inside MAC.
Fix:
According to 802.3-2012 - IEEE Standard for Ethernet pause frame
has unique de
On Wed, Dec 16, 2020 at 09:09:58PM +0100, Tobias Waldekranz wrote:
> On Wed, Dec 16, 2020 at 20:44, Vladimir Oltean wrote:
> > On Wed, Dec 16, 2020 at 05:00:54PM +0100, Tobias Waldekranz wrote:
> >> diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
> >> index 183003e45762..deee4c0ecb31 100644
> >> ---
might this still make it into 5.11?
On Thu, Dec 17, 2020 at 3:49 PM Jens Axboe wrote:
>
> On 12/16/20 3:56 PM, Victor Stewart wrote:
> > This patch adds PROTO_CMSG_DATA_ONLY to inet_dgram_ops and inet6_dgram_ops
> > so that UDP_SEGMENT (GSO) and UDP_GRO can be used through io_uring.
> >
> > GSO
Hello:
This series was applied to netdev/net.git (refs/heads/master):
On Wed, 16 Dec 2020 12:48:31 +0100 you wrote:
> This series pulls a few fixes for the MPTCP datapath.
> Most issues addressed here has been recently introduced
> with the recent reworks, with the notable exception of
> the firs
> -Original Message-
> From: Denis Kirjanov
> Sent: Tuesday, November 17, 2020 6:43 PM
> To: Radhey Shyam Pandey
> Cc: da...@davemloft.net; netdev@vger.kernel.org; k...@kernel.org;
> Michal Simek ; mchehab+sams...@kernel.org;
> gre...@linuxfoundation.org; nicolas.fe...@microchip.com; linu
On Thu, Dec 17, 2020 at 05:46:42PM +, Alan Maguire wrote:
>
>
> On Wed, 16 Dec 2020, Alexei Starovoitov wrote:
>
> > > > $ ksnoop "ip_send_skb(skb->sk)"
> > > >
> > > > ...will trace the skb->sk value. The user-space side of the program
> > > > matches the function/arg name and looks up the
On Tue, 15 Dec 2020 18:51:17 +0200 Baruch Siach wrote:
> Before commit 889b8f964f2f ("packet: Kill CONFIG_PACKET_MMAP.") there
> used to be a CONFIG_PACKET_MMAP config symbol that depended on
> CONFIG_PACKET. The text still refers to PACKET_MMAP as the name of this
> feature, implying that it can b
On Wed, 2020-12-16 at 16:01 +0100, Lorenzo Bianconi wrote:
> > On Tue, 15 Dec 2020 14:47:10 +0100
> > Lorenzo Bianconi wrote:
> >
> > > [...]
> > > > > xdp_act = bpf_prog_run_xdp(xdp_prog, &xdp);
> > > > > diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
> > > > > b/drivers/net/ethe
On Mon, 14 Dec 2020 17:29:06 -0800 Ivan Babrou wrote:
> Without this change the driver tries to allocate too many queues,
> breaching the number of available msi-x interrupts on machines
> with many logical cpus and default adapter settings:
>
> Insufficient resources for 12 XDP event queues (24 o
On 12/17/2020 10:07 AM, Eric Dumazet wrote:
On Thu, Dec 17, 2020 at 6:56 PM Ben Greear wrote:
On 12/17/20 2:11 AM, Eric Dumazet wrote:
On Thu, Dec 17, 2020 at 12:59 AM Ben Greear wrote:
On 12/16/20 3:09 PM, Ben Greear wrote:
Hello Eric,
The patch below evidently causes TCP throughput to
> Quoting stef...@marvell.com (2020-12-17 18:45:06)
> > From: Stefan Chulski
> >
> > Issue:
> > Flow control frame used to pause GoP(MAC) was delivered to the CPU and
> > created a load on the CPU. Since XOFF/XON frames are used only by MAC,
> > these frames should be dropped inside MAC.
> >
> > F
Quoting stef...@marvell.com (2020-12-17 18:45:06)
> From: Stefan Chulski
>
> Issue:
> Flow control frame used to pause GoP(MAC) was delivered to the CPU
> and created a load on the CPU. Since XOFF/XON frames are used only
> by MAC, these frames should be dropped inside MAC.
>
> Fix:
> According
> External Email
>
> --
> Hi Stefan,
>
> Quoting stef...@marvell.com (2020-12-17 18:23:11)
> > From: Stefan Chulski
> >
> > Current PPPoE+IPv6 entry is jumping to 'next-hdr'
> > field and not to 'DIP' field as done for IPv4.
> >
On Thu, 17 Dec 2020 09:25:48 +0100 Ahmad Fatoum wrote:
> On 17.12.20 02:13, Jakub Kicinski wrote:
> >> + netdev_warn(priv->dev, "HW Timestamping init failed:
> >> %pe\n",
> >> + ERR_PTR(ret));
> >
> > why convert to ERR_PTR and use %pe and not j
On 12/17/20 2:11 AM, Eric Dumazet wrote:
On Thu, Dec 17, 2020 at 12:59 AM Ben Greear wrote:
On 12/16/20 3:09 PM, Ben Greear wrote:
Hello Eric,
The patch below evidently causes TCP throughput to be about 50Mbps instead of
700Mbps
when using ax200 to upload tcp traffic.
When I disable TSO, p
On Thu, 17 Dec 2020 10:57:10 +0200 Danielle Ratson wrote:
> From: Danielle Ratson
>
> Some speeds can be achieved with different number of lanes. For example,
> 100Gbps can be achieved using two lanes of 50Gbps or four lanes of
> 25Gbps. This patch set adds a new selector that allows ethtool to
>
Hi Stefan,
Quoting stef...@marvell.com (2020-12-17 18:23:11)
> From: Stefan Chulski
>
> Current PPPoE+IPv6 entry is jumping to 'next-hdr'
> field and not to 'DIP' field as done for IPv4.
>
> Fixes: db9d7d36eecc ("net: mvpp2: Split the PPv2 driver to a dedicated
> directory")
That's not the co
1 - 100 of 185 matches
Mail list logo
