Jarod Wilson wrote:
>Broadcast mode bonds transmit a copy of all traffic simultaneously out of
>all interfaces, so the "speed" of the bond isn't really the aggregate of
>all interfaces, but rather, the speed of the lowest active interface.
Did you mean "slowest" here?
>Also, the type of
On 12.08.20 19:46, Jakub Kicinski wrote:
> On Wed, 12 Aug 2020 16:39:50 +0200 Stefan Assmann wrote:
>> drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c: In function
>> ‘i40e_set_vsi_promisc’:
>> drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:1176:14: error: ‘aq_ret’
>> may be used uninitial
syzbot has found a reproducer for the following issue on:
HEAD commit:06a7a37b ipv4: tunnel: fix compilation on ARCH=um
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=115caa1690
kernel config: https://syzkaller.appspot.com/x/.config?x=7bb894f55faf8242
dashbo
Nivedita Singhvi wrote:
>Removed obsolete resources from bonding.rst doc:
> - bonding-de...@lists.sourceforge.net hasn't been used since 2008
> - admin interface is 404
> - Donald Becker's domain/content no longer online
>
>Signed-off-by: Nivedita Singhvi
Acked-by: Jay Vosburgh
>---
> D
syzbot has found a reproducer for the following issue on:
HEAD commit:ce8056d1 wip: changed copy_from_user where instrumented
git tree: https://github.com/google/kmsan.git master
console output: https://syzkaller.appspot.com/x/log.txt?x=1041a3be90
kernel config: https://syzkaller.ap
Removed obsolete resources from bonding.rst doc:
- bonding-de...@lists.sourceforge.net hasn't been used since 2008
- admin interface is 404
- Donald Becker's domain/content no longer online
Signed-off-by: Nivedita Singhvi
---
Documentation/networking/bonding.rst | 18 --
The kci_test_encap_fou() test from kci_test_encap() in rtnetlink.sh
needs the fou module to work. Otherwise it will fail with:
$ ip netns exec "$testns" ip fou add port ipproto 47
RTNETLINK answers: No such file or directory
Error talking to the kernel
Add the CONFIG_NET_FOU into the c
Broadcast mode bonds transmit a copy of all traffic simultaneously out of
all interfaces, so the "speed" of the bond isn't really the aggregate of
all interfaces, but rather, the speed of the lowest active interface.
Also, the type of the speed field is u32, not unsigned long, so adjust
that accor
syzbot has found a reproducer for the following issue on:
HEAD commit:fb893de3 Merge tag 'tag-chrome-platform-for-v5.9' of git:/..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1742b31c90
kernel config: https://syzkaller.appspot.com/x/.config?x=f1fedc6
On Thu, Jul 16, 2020 at 1:43 AM Jarod Wilson wrote:
>
> On Wed, Jul 15, 2020 at 11:18 PM Andrew Lunn wrote:
...
> > I really think that before we consider changes like this, somebody
> > needs to work on git tooling, so that it knows when mass renames have
> > happened, and can do the same sort o
syzbot has found a reproducer for the following issue on:
HEAD commit:ce8056d1 wip: changed copy_from_user where instrumented
git tree: https://github.com/google/kmsan.git master
console output: https://syzkaller.appspot.com/x/log.txt?x=12985a1690
kernel config: https://syzkaller.ap
On Wed, Aug 12, 2020 at 3:15 PM Daniel Díaz wrote:
>
> When using a cross-compilation environment, such as OpenEmbedded,
> the CC an CXX variables are set to something more than just a
> command: there are arguments (such as --sysroot) that need to be
> passed on to the compiler so that the right
On Fri, Aug 07, 2020 at 09:32:20PM +0200, Fabian Frederick wrote:
> Avoid noise like the following:
> nft_flowtable.sh: line 250: kill: (4691) - No such process
Applied, thanks.
On Fri, Aug 07, 2020 at 09:31:50PM +0200, Fabian Frederick wrote:
> Add some documentation, default values defined in original
> script and Originator/Link/Responder arguments
> using getopts like in tools/power/cpupower/bench/cpufreq-bench_plot.sh
Also applied, thanks.
On Fri, Aug 07, 2020 at 09:31:11PM +0200, Fabian Frederick wrote:
> avoid repeating the same test for different toolcheck
Applied to nf.git, thanks.
On Thu, Aug 06, 2020 at 03:42:23PM +0100, Alan Maguire wrote:
>
> The bpf_trace_printk tracepoint is augmented with a "trace_id"
> field; it is used to allow tracepoint filtering as typed display
> information can easily be interspersed with other tracing data,
> making it hard to read. Specifyin
On Tue, Aug 11, 2020 at 02:59:59PM +0200, Simon Horman wrote:
> On Tue, Aug 11, 2020 at 01:29:04PM +0300, Julian Anastasov wrote:
> >
> > Hello,
> >
> > On Tue, 11 Aug 2020, Peilin Ye wrote:
> >
> > > do_ip_vs_set_ctl() is referencing uninitialized stack value when `len` is
> > > zero. Fix i
On Wed, Aug 12, 2020 at 8:27 AM Song Liu wrote:
>
>
>
> > On Aug 12, 2020, at 5:31 AM, Jiri Olsa wrote:
> >
> > Currently when we look for build id within bpf_get_stackid helper
> > call, we check the first NOTE section and we fail if build id is
> > not there.
> >
> > However on some system (Fed
On Wed, Aug 12, 2020 at 8:35 AM Song Liu wrote:
>
>
>
> > On Aug 11, 2020, at 7:59 PM, Andrii Nakryiko wrote:
> >
> > Seems like C++17 standard mode doesn't recognize typeof() anymore. This can
> > be tested by compiling test_cpp test with -std=c++17 or -std=c++1z options.
> > The use of typeof i
On Wed, Aug 12, 2020 at 8:48 AM Stanislav Fomichev wrote:
>
> On Wed, Aug 12, 2020 at 2:24 AM Toke Høiland-Jørgensen
> wrote:
> >
> > Andrii Nakryiko writes:
> >
> > > Enforce XDP_FLAGS_UPDATE_IF_NOEXIST only if new BPF program to be
> > > attached is
> > > non-NULL (i.e., we are not detaching
On Fri, Aug 07, 2020 at 07:39:20PM +0530, Srujana Challa wrote:
>
> +static inline int is_any_alg_used(void)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(otx2_cpt_skciphers); i++)
> + if (refcount_read(&otx2_cpt_skciphers[i].base.cra_refcnt) != 1)
> + r
On Fri, Aug 07, 2020 at 07:39:19PM +0530, Srujana Challa wrote:
>
> +#if defined(CONFIG_ARM64)
> +static inline long otx2_lmt_flush(void *ioreg)
> +{
> + long result = 0;
> +
> + __asm__ volatile(".cpu generic+lse\n"
> + "ldeor xzr, %0, [%1]\n"
> +
On Fri, Aug 07, 2020 at 07:39:19PM +0530, Srujana Challa wrote:
>
> +/*
> + * On OcteonTX2 platform the parameter insts_num is used as a count of
> + * instructions to be enqueued. The valid values for insts_num are:
> + * 1 - 1 CPT instruction will be enqueued during LMTST operation
> + * 2 - 2 CP
On Fri, Aug 07, 2020 at 06:03:00PM +, Dexuan Cui wrote:
From: Dexuan Cui
Sent: Monday, July 27, 2020 6:55 PM
To: gre...@linuxfoundation.org; eduma...@google.com;
sta...@vger.kernel.org
Cc: w...@1wt.eu; Dexuan Cui ; Joseph Salisbury
; Michael Kelley ;
v...@zeniv.linux.org.uk; netdev@vger.kern
On Wed, Aug 12, 2020 at 4:32 PM Joe Perches wrote:
>
> On Wed, 2020-08-12 at 14:36 -0600, Rob Herring wrote:
> > Clean-up incorrect indentation, extra spaces, long lines, and missing
> > EOF newline in schema files. Most of the clean-ups are for list
> > indentation which should always be 2 spaces
On Wed, Aug 12, 2020 at 3:34 PM Sam Ravnborg wrote:
>
> Hi Rob.
>
> On Wed, Aug 12, 2020 at 02:36:18PM -0600, Rob Herring wrote:
> > Clean-up incorrect indentation, extra spaces, long lines, and missing
> > EOF newline in schema files. Most of the clean-ups are for list
> > indentation which shoul
On Wed, 2020-08-12 at 14:36 -0600, Rob Herring wrote:
> Clean-up incorrect indentation, extra spaces, long lines, and missing
> EOF newline in schema files. Most of the clean-ups are for list
> indentation which should always be 2 spaces more than the preceding
When using a cross-compilation environment, such as OpenEmbedded,
the CC an CXX variables are set to something more than just a
command: there are arguments (such as --sysroot) that need to be
passed on to the compiler so that the right set of headers and
libraries are used.
For the particular cas
From: Mathieu Desnoyers
Date: Tue, 11 Aug 2020 15:50:02 -0400
> @@ -465,6 +465,7 @@ static struct rtable *icmp_route_lookup(struct net *net,
> int type, int code,
> struct icmp_bxm *param)
> {
> + struct net_device *
Hi Rob.
On Wed, Aug 12, 2020 at 02:36:18PM -0600, Rob Herring wrote:
> Clean-up incorrect indentation, extra spaces, long lines, and missing
> EOF newline in schema files. Most of the clean-ups are for list
> indentation which should always be 2 spaces more than the preceding
> keyword.
>
> Found
Hi Asmaa
Please wrap your emails at about 75 characters.
> So let me explain further and would greatly appreciate your input.
> Technically, when this driver gets loaded, we shouldn't need the interrupt
> when bringing up the link for the first time, do we?
> Correct me if I am wrong, "phy_star
From: Eric Dumazet
Date: Tue, 11 Aug 2020 18:34:40 -0700
> We must accept an empty mask in store_rps_map(), or we are not able
> to disable RPS on a queue.
>
> Fixes: 07bbecb34106 ("net: Restrict receive packets queuing to housekeeping
> CPUs")
> Signed-off-by: Eric Dumazet
> Reported-by: Maci
Hello everybody!
Could you help me, please?
I use Debian 10 and iproute2 version iproute2
dpkg -l iproute2
iproute2 4.20.0-2 amd64
My problem is this:
I can't convert "tc -j filter show u32" command to json format.
Here it is command:
tc qdisc add dev eno1 ingress
tc filter add dev eno1
On 8/11/20 3:55 PM, Ramamurthy, Harshitha wrote:
> is a pre-cursor to potentially calling the in-kernel flow dissector from
> a helper function.
>
That is going to be a challenge to do in a way that does not impact the
kernel's ability to change as needed, and I suspect it will be much
slower tha
On Tue, Aug 11, 2020 at 04:25:43PM -0700, Cong Wang wrote:
> On Sun, Aug 9, 2020 at 4:41 PM Jamal Hadi Salim wrote:
> >
> > Interesting idea. Note: my experience is that typical setup is
> > to have only one of those (from offload perspective). Ariel,
> > are your use cases requiring say both fiel
On 08/12, Jianlin Lv wrote:
test_xdp_vlan.sh reports the error as below:
$ sudo ./test_xdp_vlan_mode_native.sh
+ '[' -z xdp_vlan_mode_native ']'
+ XDP_MODE=xdpgeneric
……
+ export XDP_PROG=xdp_vlan_remove_outer2
+ XDP_PROG=xdp_vlan_remove_outer2
+ ip netns exec ns1 ip link set veth1 xdpdrv off
> -Original Message-
> From: Andrew Lunn
> Sent: Tuesday, August 11, 2020 4:07 PM
> To: Asmaa Mnebhi
> Cc: David Thompson ;
> netdev@vger.kernel.org; da...@davemloft.net; k...@kernel.org; Jiri
> Pirko ; Asmaa Mnebhi
> Subject: Re: [PATCH net-next] Add Mellanox BlueField Gigabit Ethern
From: Eric Dumazet
Date: Wed, 12 Aug 2020 13:01:16 -0700
>
>
> On 8/12/20 12:08 PM, Johannes Berg wrote:
>> From: Johannes Berg
>>
>> With certain configurations, a 64-bit ARCH=um errors
>> out here with an unknown csum_ipv6_magic() function.
>> Include the right header file to always have it
On Mon, 2020-08-10 at 13:02 -0600, David Ahern wrote:
> On 8/10/20 12:28 PM, Harshitha Ramamurthy wrote:
> > This patch adds a helper function called bpf_get_skb_hash to
> > calculate
> > the skb hash for a packet at the XDP layer. In the helper function,
>
> Why? i.e., expected use case?
>
> Pul
From: Jonathan McDowell
Date: Wed, 12 Aug 2020 20:36:54 +0100
> This pair of patches are the result of discovering a failure to
> correctly receive IPv6 multicast packets on such a device (in particular
> DHCPv6 requests and RA solicitations). Putting the device into
> promiscuous mode, or allmul
From: Johannes Berg
Date: Wed, 12 Aug 2020 21:08:53 +0200
> From: Johannes Berg
>
> With certain configurations, a 64-bit ARCH=um errors
> out here with an unknown csum_ipv6_magic() function.
> Include the right header file to always have it.
>
> Signed-off-by: Johannes Berg
Applied, thank y
From: Stefano Garzarella
Date: Wed, 12 Aug 2020 14:56:02 +0200
> syzbot reported this issue where in the vsock_poll() we find the
> socket state at TCP_ESTABLISHED, but 'transport' is null:
> general protection fault, probably for non-canonical address
> 0xdc12: [#1] PREEMPT S
From: Edward Cree
Date: Wed, 12 Aug 2020 10:32:49 +0100
> The handling of the RXQ/TXQ size granularity design-params had two
> problems: it had a 64-bit divide that didn't build on 32-bit platforms,
> and it could divide by zero if the NIC supplied 0 as the value of the
> design-param. Fix bo
On 8/12/20 12:08 PM, Johannes Berg wrote:
> From: Johannes Berg
>
> With certain configurations, a 64-bit ARCH=um errors
> out here with an unknown csum_ipv6_magic() function.
> Include the right header file to always have it.
>
> Signed-off-by: Johannes Berg
> ---
> net/ipv4/ip_tunnel_core
The IPQ806x does not appear to have a functional multicast ethernet
address filter. This was observed as a failure to correctly receive IPv6
packets on a LAN to the all stations address. Checking the vendor driver
shows that it does not attempt to enable the multicast filter and
instead falls back
This pair of patches are the result of discovering a failure to
correctly receive IPv6 multicast packets on such a device (in particular
DHCPv6 requests and RA solicitations). Putting the device into
promiscuous mode, or allmulti, both resulted in such packets correctly
being received. Examination
If we don't have a hardware multicast filter available then instead of
silently failing to listen for the requested ethernet broadcast
addresses fall back to receiving all multicast packets, in a similar
fashion to other drivers with no multicast filter.
Cc: sta...@vger.kernel.org
Signed-off-by: J
On 8/12/20 6:37 AM, mastertheknife wrote:
> Hello David,
>
> I tried and it seems i can reproduce it:
>
> # Create test NS
> root@host:~# ip netns add testns
> # Create veth pair, veth0 in host, veth1 in NS
> root@host:~# ip link add veth0 type veth peer name veth1
> root@host:~# ip link set veth
From: Johannes Berg
With certain configurations, a 64-bit ARCH=um errors
out here with an unknown csum_ipv6_magic() function.
Include the right header file to always have it.
Signed-off-by: Johannes Berg
---
net/ipv4/ip_tunnel_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4
Hi, i'm Curtis from US, i have something to discuss with you, hope we
can establish a relationship from here. i will be waiting for your
reply. Thanks.
On Wed, Aug 12, 2020 at 2:21 AM linmiaohe wrote:
>
> Hi all:
> David Miller wrote:
> >From: Cong Wang
> >Date: Tue, 11 Aug 2020 16:02:51 -0700
> >
> >>> @@ -3406,6 +3406,16 @@ static void sock_inuse_add(struct net *net,
> >>> int val) } #endif
> >>>
> >>> +static void tw_prot_cleanup(struct ti
On Wed, 12 Aug 2020 13:10:57 +0300 Shay Agroskin wrote:
> This patch also removes the destruction of the timer and reset services
> from ena_remove() since the timer is destroyed by the destruction
> routine and the reset work is handled by this patch.
You'd still have a use after free if the work
On Wed, 12 Aug 2020 16:39:50 +0200 Stefan Assmann wrote:
> drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c: In function
> ‘i40e_set_vsi_promisc’:
> drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:1176:14: error: ‘aq_ret’
> may be used uninitialized in this function [-Werror=maybe-uninitiali
On Wed, Aug 12, 2020 at 6:25 PM Eric Dumazet wrote:
>
> On Wed, Aug 12, 2020 at 9:20 AM Sedat Dilek wrote:
> >
> > On Wed, Aug 12, 2020 at 5:16 PM Eric Dumazet wrote:
> > >
> > >
> > >
> > > On 8/11/20 11:03 PM, Sedat Dilek wrote:
> > > > [ CC netdev ]
> > > > [ Please CC me I am not subscribed
On Wed, Aug 12, 2020 at 06:28:17PM +0200, Marek Behún wrote:
> On Wed, 12 Aug 2020 17:22:32 +0100
> Russell King - ARM Linux admin wrote:
>
> > On Wed, Aug 12, 2020 at 06:13:33PM +0200, Marek Behún wrote:
> > > The MACTYPE is not being lost. But changing it requires Port
> > > Software Reset, whi
On Wed, 12 Aug 2020 17:22:32 +0100
Russell King - ARM Linux admin wrote:
> On Wed, Aug 12, 2020 at 06:13:33PM +0200, Marek Behún wrote:
> > The MACTYPE is not being lost. But changing it requires Port
> > Software Reset, which resets the link, so it cannot be done for
> > example in read_status.
On Wed, Aug 12, 2020 at 06:13:33PM +0200, Marek Behún wrote:
> The MACTYPE is not being lost. But changing it requires Port Software
> Reset, which resets the link, so it cannot be done for example in
> read_status.
Wouldn't the right place to configure it be in the config_init()
method - which is
On Wed, Aug 12, 2020 at 5:16 PM Eric Dumazet wrote:
>
>
>
> On 8/11/20 11:03 PM, Sedat Dilek wrote:
> > [ CC netdev ]
> > [ Please CC me I am not subscribed to this mailing-list ]
> >
> > Hi Eric,
> >
> > I have added your diffs from [0] and have some troubles to display the
> > prandom_32 trace-e
On Wed, 12 Aug 2020 17:01:31 +0100
Russell King - ARM Linux admin wrote:
> That's fine, because you also have the patches further down in
> net-queue. So, what you list above are basically not all the patches.
>
> net: mvpp2: fill in phy interface mode bitmap
> net: mvneta: fill in phy interfac
On Wed, 12 Aug 2020 16:48:37 +0100
Russell King - ARM Linux admin wrote:
> On Wed, Aug 12, 2020 at 05:37:16PM +0200, Marek Behún wrote:
> > On Wed, 12 Aug 2020 16:00:54 +0100
> > Russell King - ARM Linux admin wrote:
> >
> > > On Wed, Aug 12, 2020 at 04:44:31PM +0200, Marek Behún wrote:
> >
On Wed, Aug 12, 2020 at 05:37:16PM +0200, Marek Behún wrote:
> On Wed, 12 Aug 2020 16:00:54 +0100
> Russell King - ARM Linux admin wrote:
>
> > On Wed, Aug 12, 2020 at 04:44:31PM +0200, Marek Behún wrote:
> > > There is another problem though: I think the PHY driver, when
> > > deciding whether t
On Wed, 12 Aug 2020 16:48:37 +0100
Russell King - ARM Linux admin wrote:
> On Wed, Aug 12, 2020 at 05:37:16PM +0200, Marek Behún wrote:
> > On Wed, 12 Aug 2020 16:00:54 +0100
> > Russell King - ARM Linux admin wrote:
> >
> > > On Wed, Aug 12, 2020 at 04:44:31PM +0200, Marek Behún wrote:
> >
On Wed, Aug 12, 2020 at 05:44:36PM +0200, Andrew Lunn wrote:
> > I'm aware of that problem. I have some experimental patches which add
> > PHY interface mode bitmaps to the MAC, PHY, and SFP module parsing
> > functions. I have stumbled on some problems though - it's going to be
> > another API c
On Wed, Aug 12, 2020 at 05:37:16PM +0200, Marek Behún wrote:
> On Wed, 12 Aug 2020 16:00:54 +0100
> Russell King - ARM Linux admin wrote:
>
> > On Wed, Aug 12, 2020 at 04:44:31PM +0200, Marek Behún wrote:
> > > There is another problem though: I think the PHY driver, when
> > > deciding whether t
> I'm aware of that problem. I have some experimental patches which add
> PHY interface mode bitmaps to the MAC, PHY, and SFP module parsing
> functions. I have stumbled on some problems though - it's going to be
> another API change (and people are already whinging about the phylink
> API changi
On Wed, 12 Aug 2020 16:00:54 +0100
Russell King - ARM Linux admin wrote:
> On Wed, Aug 12, 2020 at 04:44:31PM +0200, Marek Behún wrote:
> > There is another problem though: I think the PHY driver, when
> > deciding whether to set MACTYPE from the XFI with rate matching
> > mode to the 10GBASE-R/5
> On Aug 11, 2020, at 7:59 PM, Andrii Nakryiko wrote:
>
> Seems like C++17 standard mode doesn't recognize typeof() anymore. This can
> be tested by compiling test_cpp test with -std=c++17 or -std=c++1z options.
> The use of typeof in skeleton generated code is unnecessary, all types are
> wel
> On Aug 12, 2020, at 5:31 AM, Jiri Olsa wrote:
>
> Currently when we look for build id within bpf_get_stackid helper
> call, we check the first NOTE section and we fail if build id is
> not there.
>
> However on some system (Fedora) there can be multiple NOTE sections
> in binaries and build
On Wed, Aug 12, 2020 at 10:32:49AM +0100, Edward Cree wrote:
> The handling of the RXQ/TXQ size granularity design-params had two
> problems: it had a 64-bit divide that didn't build on 32-bit platforms,
> and it could divide by zero if the NIC supplied 0 as the value of the
> design-param. Fix
On 8/12/20 1:00 AM, pet...@infradead.org wrote:
> On Tue, Aug 11, 2020 at 06:45:23PM -0700, Maciej Żenczykowski wrote:
>> On Tue, Aug 11, 2020 at 6:34 PM Eric Dumazet wrote:
>>
>>> We must accept an empty mask in store_rps_map(), or we are not able
>>> to disable RPS on a queue.
>>>
>>> Fixes:
On 8/11/20 11:03 PM, Sedat Dilek wrote:
> [ CC netdev ]
> [ Please CC me I am not subscribed to this mailing-list ]
>
> Hi Eric,
>
> I have added your diffs from [0] and have some troubles to display the
> prandom_32 trace-events (I mostly followed [1]):
>
> I did:
>
> echo prandom_u32 >> /s
On 2020-08-12 17:34:30 [+0300], Vladimir Oltean wrote:
> I expect the driver maintainers to have something to say about this. I
> didn't test on stable kernels, and at least for dpaa2-eth, the change
> would need to go pretty deep down the stable line.
Yes, each affected and maintained stable kern
On Wed, Aug 12, 2020 at 04:44:31PM +0200, Marek Behún wrote:
> There is another problem though: I think the PHY driver, when deciding
> whether to set MACTYPE from the XFI with rate matching mode to the
> 10GBASE-R/5GBASE-R/2500BASE-X/SGMII with AN mode, should check which
> modes the underlying MA
On Tue, 11 Aug 2020 16:21:44 +0100
Russell King - ARM Linux admin wrote:
> On Tue, Aug 11, 2020 at 12:06:44AM +0200, Marek Behún wrote:
> > RollBall SFPs contain Marvell 88X3310 PHY, but they have
> > configuration pins strapped so that MACTYPE is configured in XFI
> > with Rate Matching mode.
>
On Wed, 12 Aug 2020 15:33:04 +0100
Russell King - ARM Linux admin wrote:
> On Wed, Aug 12, 2020 at 03:33:26PM +0200, Marek Behún wrote:
> > On Tue, 11 Aug 2020 16:15:53 +0100
> > Russell King - ARM Linux admin wrote:
> >
> > > > + if (rollball) {
> > > > + /* TODO: try to
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c: In function
‘i40e_set_vsi_promisc’:
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:1176:14: error: ‘aq_ret’ may
be used uninitialized in this function [-Werror=maybe-uninitialized]
i40e_status aq_ret;
In case the code inside the if statem
On Wed, Aug 12, 2020 at 03:51:44PM +0200, Sebastian Andrzej Siewior wrote:
> On 2020-08-03 18:21:45 [-0700], David Miller wrote:
> > From: Vladimir Oltean
> > > The driver calls napi_schedule_irqoff() from a context where, in RT,
> > > hardirqs are not disabled, since the IRQ handler is force-thre
On Wed, Aug 12, 2020 at 03:33:26PM +0200, Marek Behún wrote:
> On Tue, 11 Aug 2020 16:15:53 +0100
> Russell King - ARM Linux admin wrote:
>
> > > + if (rollball) {
> > > + /* TODO: try to write this to EEPROM */
> > > + id.base.extended_cc = SFF8024_ECC_10GBASE_T_SFI;
> >
> > S
On Tue, 11 Aug 2020 16:08:09 +0100
Russell King - ARM Linux admin wrote:
> On Tue, Aug 11, 2020 at 12:06:41AM +0200, Marek Behún wrote:
> > Hi Russell,
> >
> > this series should apply on linux-arm git repository, on branch
> > clearfog.
> >
> > Some internet providers are already starting to o
On Mon, Aug 10, 2020 at 8:31 PM Marcelo Ricardo Leitner
wrote:
>
> On Mon, Aug 10, 2020 at 08:37:18AM -0700, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:fffe3ae0 Merge tag 'for-linus-hmm' of git://git.kernel.org..
> > git tree: upstream
> > c
test_xdp_vlan.sh reports the error as below:
$ sudo ./test_xdp_vlan_mode_native.sh
+ '[' -z xdp_vlan_mode_native ']'
+ XDP_MODE=xdpgeneric
……
+ export XDP_PROG=xdp_vlan_remove_outer2
+ XDP_PROG=xdp_vlan_remove_outer2
+ ip netns exec ns1 ip link set veth1 xdpdrv off
Error: XDP program already attac
On 2020-08-03 18:21:45 [-0700], David Miller wrote:
> From: Vladimir Oltean
> > The driver calls napi_schedule_irqoff() from a context where, in RT,
> > hardirqs are not disabled, since the IRQ handler is force-threaded.
…
> >
> > Signed-off-by: Jiafei Pan
> > Signed-off-by: Vladimir Oltean
>
> From: Stefano Garzarella
> Sent: Wednesday, August 12, 2020 2:56 PM
> To: da...@davemloft.net
> Cc: linux-ker...@vger.kernel.org; Dexuan Cui ;
> netdev@vger.kernel.org; Stefan Hajnoczi ; Jakub
> Kicinski ; Jorgen Hansen ;
> Stefano Garzarella
> Subject: [PATCH net v2] vsock: fix potential null
On Tue, 11 Aug 2020 16:15:53 +0100
Russell King - ARM Linux admin wrote:
> > + if (rollball) {
> > + /* TODO: try to write this to EEPROM */
> > + id.base.extended_cc = SFF8024_ECC_10GBASE_T_SFI;
>
> Should we really be "fixing" vendors EEPROMs for them?
>
Are you reffe
syzbot reported this issue where in the vsock_poll() we find the
socket state at TCP_ESTABLISHED, but 'transport' is null:
general protection fault, probably for non-canonical address
0xdc12: [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0090-0x0
On 8/11/20 9:34 PM, Eric Dumazet wrote:
> We must accept an empty mask in store_rps_map(), or we are not able
> to disable RPS on a queue.
>
> Fixes: 07bbecb34106 ("net: Restrict receive packets queuing to housekeeping
> CPUs")
> Signed-off-by: Eric Dumazet
> Reported-by: Maciej Żenczykowski
>
> With networking protocols you often also have a requirement to minimize
> packet reordering, so I understand it's a careful balance. But it is possible
> to serialize the important stuff and still do the crypto out-of-order, which
> would be really beneficial on _some_ platforms (which have HW cr
Hello David,
I tried and it seems i can reproduce it:
# Create test NS
root@host:~# ip netns add testns
# Create veth pair, veth0 in host, veth1 in NS
root@host:~# ip link add veth0 type veth peer name veth1
root@host:~# ip link set veth1 netns testns
# Configure veth1 (NS)
root@host:~# ip netns
Kees,
> Was a Coccinelle script used for any of these conversions? I wonder if
> it'd be easier to do a single treewide patch for the more mechanical
> changes.
No, I should have written one. Will do it.
> And, actually, I still think the "prepare" patches should just be
> collapsed into the act
On Wed, 12 Aug 2020 14:31:03 +0200
Marek Behún wrote:
> On Tue, 11 Aug 2020 16:08:09 +0100
> Russell King - ARM Linux admin wrote:
>
> > Are you sure they are 10GBASE-KR, and not 10GBASE-R ? Please send
> > me the contents of MMD 31 register 0xf001. Also knowing MMD 1
> > registers 2 and 3 wo
Currently when we look for build id within bpf_get_stackid helper
call, we check the first NOTE section and we fail if build id is
not there.
However on some system (Fedora) there can be multiple NOTE sections
in binaries and build id data is not always the first one, like:
$ readelf -a /usr/bi
On Tue, 11 Aug 2020 16:08:09 +0100
Russell King - ARM Linux admin wrote:
> Are you sure they are 10GBASE-KR, and not 10GBASE-R ? Please send me
> the contents of MMD 31 register 0xf001. Also knowing MMD 1 registers
> 2 and 3 would be useful to confirm exactly which version of the PHY
> has been
syzbot has bisected this issue to:
commit 786a2aa281f4c4ba424ea8b8ea1e85ab62c4a57c
Author: Jarkko Sakkinen
Date: Mon Jul 6 20:53:42 2020 +
Revert commit e918e570415c ("tpm_tis: Remove the HID IFX0102")
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=12fc36d690
start c
>
> I have a patch set to convert the remaining tasklet usage in sound
> drivers to either the threaded IRQ or the work, but it wasn't
> submitted / merged for 5.8 due to the obvious conflict with your API
> changes.
> Each conversion is rather simple, but it's always a question of the
> nature of
> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org
> On Behalf Of Sabrina Dubroca
> Sent: Wednesday, August 12, 2020 12:05 PM
> To: Scott Dial
> Cc: linux-cry...@vger.kernel.org; Ryan Cox ;
> netdev@vger.kernel.org; da...@davemloft.net; Antoine Tenart
> ; ebigg...@google.co
Most statistics in ena driver are incremented, meaning that a stat's
value is a sum of all increases done to it since driver/queue
initialization.
This patch makes all statistics this way, effectively making missed_tx
statistic incremental.
Also added a comment regarding rx_drops and tx_drops to m
The ena_del_napi_in_range() function unregisters the napi handler for
rings in a given range.
This function had the following WARN_ON macro:
WARN_ON(ENA_IS_XDP_INDEX(adapter, i) &&
adapter->ena_napi[i].xdp_ring);
This macro prints the call stack if the expression inside of it is
t
This series adds the following:
- Fix possible NULL dereference after returning from suspend
- Fix condition inside a WARN_ON
- Fix overriding previous value when updating missed_tx statistic
Shay Agroskin (3):
net: ena: Prevent reset after device destruction
net: ena: Change WARN_ON expressio
The reset work is scheduled by the timer routine whenever it
detects that a device reset is required (e.g. when a keep_alive signal
is missing).
When releasing device resources in ena_destroy() the driver cancels the
scheduling of the timer routine without destroying the reset
work explicitly.
Thi
2020-08-10, 12:09:40 -0400, Scott Dial wrote:
> On 8/10/2020 9:34 AM, Sabrina Dubroca wrote:
> > [adding the linux-crypto list]
> >
> > 2020-08-06, 23:48:16 -0400, Scott Dial wrote:
> >> On 8/6/2020 5:11 PM, Ryan Cox wrote:
> >>> With 5.7 I get:
> >>> * 9.90 Gb/s with no macsec at all
> >>> * 1.80
1 - 100 of 109 matches
Mail list logo
