Hi Pablo,
I love your patch! Yet something to improve:
[auto build test ERROR on nf-next/master]
[also build test ERROR on v4.16 next-20180413]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits
> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> Sent: Friday, March 30, 2018 5:07 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: Gomes, Vinicius ; Kirsher, Jeffrey T
> ; netdev@vger.kernel.org; Sanchez-Palencia,
> Jesus ; Guedes, An
> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> Sent: Tuesday, April 10, 2018 10:50 AM
> To: intel-wired-...@lists.osuosl.org
> Cc: Gomes, Vinicius ; Kirsher, Jeffrey T
> ; netdev@vger.kernel.org; Sanchez-Palencia,
> Jesus
> Subject
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Vinicius Costa Gomes
> Sent: Tuesday, April 10, 2018 10:50 AM
> To: intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus palen...@intel.com>
> Subject: [Intel-wired-lan] [next-queue
> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> Sent: Tuesday, April 10, 2018 10:50 AM
> To: intel-wired-...@lists.osuosl.org
> Cc: Gomes, Vinicius ; Kirsher, Jeffrey T
> ; netdev@vger.kernel.org; Sanchez-Palencia,
> Jesus
> Subject
> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> Sent: Tuesday, April 10, 2018 10:50 AM
> To: intel-wired-...@lists.osuosl.org
> Cc: Gomes, Vinicius ; Kirsher, Jeffrey T
> ; netdev@vger.kernel.org; Sanchez-Palencia,
> Jesus
> Subject
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Vinicius Costa Gomes
> Sent: Tuesday, April 10, 2018 10:50 AM
> To: intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus palen...@intel.com>
> Subject: [Intel-wired-lan] [next-queue
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Vinicius Costa Gomes
> Sent: Tuesday, April 10, 2018 10:50 AM
> To: intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus palen...@intel.com>
> Subject: [Intel-wired-lan] [next-queue
> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> Sent: Tuesday, April 10, 2018 10:50 AM
> To: intel-wired-...@lists.osuosl.org
> Cc: Gomes, Vinicius ; Kirsher, Jeffrey T
> ; netdev@vger.kernel.org; Sanchez-Palencia,
> Jesus
> Subject
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Vinicius Costa Gomes
> Sent: Tuesday, April 10, 2018 10:50 AM
> To: intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus palen...@intel.com>
> Subject: [Intel-wired-lan] [next-queue
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Vinicius Costa Gomes
> Sent: Tuesday, April 10, 2018 10:50 AM
> To: intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus palen...@intel.com>
> Subject: [Intel-wired-lan] [next-queue
> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> Sent: Tuesday, April 10, 2018 10:50 AM
> To: intel-wired-...@lists.osuosl.org
> Cc: Gomes, Vinicius ; Kirsher, Jeffrey T
> ; netdev@vger.kernel.org; Sanchez-Palencia,
> Jesus
> Subject
Eric Dumazet wrote on Fri, Apr 13, 2018:
> Ah sorry, your trace was truncated, we need more packets _before_ the excerpt.
Ah, sorry as well. I tried to go far back enough to include the replayed
packets, but I see it didn't include the original ack for that packet.
I'm resending both full traces f
On 04/13/2018 06:09 PM, Dominique Martinet wrote:
> Thank you for the replies,
>
> Eric Dumazet wrote on Fri, Apr 13, 2018:
>> There is no way a regular TCP stack (including linux) could send the
>> following frame.
>>
>>> 16:49:27.048760 IP .13317 > .31872:
>>> Flags [.], seq 32004:33378, ack
On 04/13/2018 05:39 PM, Subash Abhinov Kasiviswanathan wrote:
> We are seeing a warning followed by a crash on an ARM64 device with
> Android 4.14 based kernel.
>
> It looks like both sk->sk_write_queue and sk->sk_send_head are NULL.
> Since the sk->sk_write_queue is NULL and is dereferenced in
Thank you for the replies,
Eric Dumazet wrote on Fri, Apr 13, 2018:
> There is no way a regular TCP stack (including linux) could send the
> following frame.
>
> > 16:49:27.048760 IP .13317 > .31872:
> > Flags [.], seq 32004:33378, ack 4190, win 307, options [nop,nop,TS val
> > 1313937955 ecr
On Fri, Apr 13, 2018 at 9:57 AM, Kostas Peletidis wrote:
> Hello,
>
> I am having trouble with a particular case of setting up a fou tunnel
> and I would really appreciate your help.
>
> I have a remote multihomed host behind a NAT box and I want to create
> a fou tunnel for each of its IP address
We are seeing a warning followed by a crash on an ARM64 device with
Android 4.14 based kernel.
It looks like both sk->sk_write_queue and sk->sk_send_head are NULL.
Since the sk->sk_write_queue is NULL and is dereferenced in
tcp_rto_delta_us()
to get the skb->skb_mstamp, there is crash observed.
> Subject: RE: [Resend Patch 3/3] Storvsc: Select channel based on available
> percentage of ring buffer to write
>
> > -Original Message-
> > From: linux-kernel-ow...@vger.kernel.org
> > On Behalf Of Long Li
> > Sent: Tuesday, March 27, 2018 5:49 PM
> > To: KY Srinivasan ; Haiyang Zhang
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> On Behalf
> Of Long Li
> Sent: Tuesday, March 27, 2018 5:49 PM
> To: KY Srinivasan ; Haiyang Zhang
> ; Stephen
> Hemminger ; James E . J . Bottomley
> ;
> Martin K . Petersen ;
> de...@linuxdriverproject.org; linux-
> s.
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> On Behalf
> Of Long Li
> Sent: Tuesday, March 27, 2018 5:49 PM
> To: KY Srinivasan ; Haiyang Zhang
> ; Stephen
> Hemminger ; James E . J . Bottomley
> ;
> Martin K . Petersen ;
> de...@linuxdriverproject.org; linux-
> s.
On 4/13/2018 1:16 PM, Or Gerlitz wrote:
On Fri, Apr 13, 2018 at 7:49 PM, Samudrala, Sridhar
wrote:
On 4/13/2018 1:57 AM, Or Gerlitz wrote:
in overlay networks scheme, the uplink rep has the VTEP ip and is not connected
to the bridge, e.g you use ovs you have vf reps and vxlan ports connecte
Hi,
Serhey Popovych writes:
[...]
> diff --git a/tc/q_mqprio.c b/tc/q_mqprio.c
> index 89b4600..207d644 100644
> --- a/tc/q_mqprio.c
> +++ b/tc/q_mqprio.c
> @@ -173,8 +173,7 @@ static int mqprio_parse_opt(struct qdisc_util *qu, int
> argc,
> argc--; argv++;
> }
>
> -
Patches for Cavium's Octeon III network driver were submitted by
David Daney back on 20180222. David has since left the company and
I am now responsible for the upstreaming effort. When looking at
they are marked as "Not Applicable". What
steps do I take next? Thanks.
Steve
Signed-off-by: Roman Mashak
---
tc/m_ife.c | 54 --
1 file changed, 32 insertions(+), 22 deletions(-)
diff --git a/tc/m_ife.c b/tc/m_ife.c
index d7e61703f666..15d09a167450 100644
--- a/tc/m_ife.c
+++ b/tc/m_ife.c
@@ -240,22 +240,24 @@ static in
I started getting this since 4.15.15. It's easy to trigger,
for example I get new IP address via dhcp (NetworkManager),
then ss -K the_old_ip_address .
Happens on Ryzen and SandyBridge systems.
My guess of the cause: commit 960058fe196397aecb16bb14e64980e265d2bc5e
(didn't try reverting)
BUG: una
On 4/13/18 11:19 AM, Peter Zijlstra wrote:
On Tue, Apr 10, 2018 at 02:28:04PM -0700, Alexei Starovoitov wrote:
Instead of
#ifdef CC_HAVE_ASM_GOTO
we can replace it with
#ifndef __BPF__
or some other name,
I would prefer the BPF specific hack; otherwise we might be encouraging
people to build t
On 4/13/18 2:23 PM, Jeff Barnhill wrote:
> It seems that the ENETUNREACH response is still desirable in the VRF
> case since the only difference (when using VRF vs. not) is that the
> lookup should be restrained to a specific VRF.
VRF is just policy routing to a table. If the table wants the looku
Thanks for the response, David. I'm not questioning the need to stop
the fib lookup once the end of the VRF table is reached - I agree that
is needed. I'm concerned with the difference in the response/error
returned from the failed lookup.
For instance, with vrf "unreachable default" route, I get
On Fri, Apr 13, 2018 at 7:49 PM, Samudrala, Sridhar
wrote:
> On 4/13/2018 1:57 AM, Or Gerlitz wrote:
>>> in overlay networks scheme, the uplink rep has the VTEP ip and is not
>>> connected
>>> to the bridge, e.g you use ovs you have vf reps and vxlan ports connected
>>> to ovs and the ip stack
From: Cathy Zhou
Sparse complains valid conversions between restricted types, force
attribute is used to avoid those warnings.
Signed-off-by: Cathy Zhou
Reviewed-by: Shannon Nelson
---
drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c | 13 ++-
drivers/net/ethernet/intel/ixgbe/ixgbe_com
2018-04-12 17:28 UTC-0700 ~ Alexei Starovoitov
> On Tue, Apr 10, 2018 at 03:41:53PM +0100, Quentin Monnet wrote:
>> Add documentation for eBPF helper functions to bpf.h user header file.
>> This documentation can be parsed with the Python script provided in
>> another commit of the patch series, i
A misconfigured system (e.g. with all interrupts affinitised to all CPUs)
may produce a storm of ARFS steering events. With the existing sfc ARFS
implementation, that could create a backlog of workitems that grinds the
system to a halt. To prevent this, limit the number of workitems that
may
Necessary to allow redirecting a flow when the application moves.
Fixes: 3af0f34290f6 ("sfc: replace asynchronous filter operations")
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/rx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/sfc/rx.c b/d
When we inserted an ARFS filter for ndo_rx_flow_steer(), we didn't know
what the filter ID would be, so we just returned 0. Thus, we must also
pass 0 as the filter ID when calling rps_may_expire_flow() for it, and
rely on the flow_id to identify what we're talking about.
Fixes: 3af0f34290f6 ("
Currently the pcie_print_link_status() will print PCIe bandwidth
and link width information but does not mention it is pertaining
to the PCIe. Since this and related functions are used exclusively
by networking drivers today users may get confused into thinking
that it's the NIC bandwidth that is
Three issues introduced by my recent asynchronous filter handling changes:
1. The old filter_rfs_insert would replace a matching filter of equal
priority; we need to pass the appropriate argument to filter_insert to
make it do the same.
2. We're lying to the kernel with our return value from
ethtool version 4.16 has been released.
Home page: https://www.kernel.org/pub/software/network/ethtool/
Download link:
https://www.kernel.org/pub/software/network/ethtool/ethtool-4.16.tar.xz
Release notes:
* Feature: add support for extra RSS contexts and RSS steering filters
* F
From: Paolo Abeni
Date: Fri, 13 Apr 2018 13:59:25 +0200
> When parsing the options provided by the user space,
> team_nl_cmd_options_set() insert them in a temporary list to send
> multiple events with a single message.
> While each option's attribute is correctly validated, the code does
> not c
On Mon, Apr 09, 2018 at 03:38:44PM +0900, Kunihiko Hayashi wrote:
> Add "socionext,syscon-phy-mode" property to specify system controller that
> configures the settings about phy-mode.
>
> Signed-off-by: Kunihiko Hayashi
> ---
> Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt |
On Fri, Apr 13, 2018 at 10:12:41AM -0700, Tushar Dave wrote:
> I guess there is nothing we need to do!
>
> On x86, in case of no intel iommu or iommu is disabled, you end up in
> swiotlb for DMA API calls when system has 4G memory.
> However, AFAICT, for 64bit DMA capable devices swiotlb DMA APIs d
On Mon, Apr 09, 2018 at 03:38:43PM +0900, Kunihiko Hayashi wrote:
> When the link is becoming up for Pro4 SoC, the kernel is stalled
> due to some missing clocks and resets.
>
> The AVE block for Pro4 is connected to the GIO bus in the SoC.
> Without its clock/reset, the access to the AVE register
On 04/12/2018 07:56 AM, Christoph Hellwig wrote:
On Thu, Apr 12, 2018 at 04:51:23PM +0200, Christoph Hellwig wrote:
On Thu, Apr 12, 2018 at 03:50:29PM +0200, Jesper Dangaard Brouer wrote:
---
Implement support for keeping the DMA mapping through the XDP return
call, to remove RX m
Hello,
I am having trouble with a particular case of setting up a fou tunnel
and I would really appreciate your help.
I have a remote multihomed host behind a NAT box and I want to create
a fou tunnel for each of its IP addresses, from my machine.
A typical case would be something like that (out
On Thu, Apr 12, 2018 at 05:31:31PM +0200, Jesper Dangaard Brouer wrote:
> > I guess that is because x86 selects it as the default as soon as
> > we have more than 4G memory.
>
> I were also confused why I ended up using SWIOTLB (SoftWare IO-TLB),
> that might explain it. And I'm not hitting the b
On 4/13/2018 1:57 AM, Or Gerlitz wrote:
On Fri, Apr 13, 2018 at 11:56 AM, Or Gerlitz wrote:
On Thu, Apr 12, 2018 at 11:33 PM, Samudrala, Sridhar
wrote:
On 4/12/2018 1:20 PM, Or Gerlitz wrote:
On Thu, Apr 12, 2018 at 8:05 PM, Samudrala, Sridhar
wrote:
On 11/12/2017 11:49 AM, Or Gerlitz wrot
Thomas reported a change in behavior with respect to autodectecting
address families. Specifically, 'ip ro add default via fe80::1'
syntax was failing to treat fe80::1 as an IPv6 address as it did in
prior releases. The root causes appears to be a change in family when
the default keyword is parsed
On Fri, Apr 06, 2018 at 11:07:20AM +0200, Dominique Martinet wrote:
> 16:49:26.735042 IP .13317 > .31872: Flags
> [.], seq 70476:71850, ack 4190, win 307, options [nop,nop,TS val 1313937641
> ecr 1617129473], length 1374
> 16:49:26.735046 IP .13317 > .31872: Flags
> [.], seq 71850:73224, ack 419
On 13/04/18 17:14, David Miller wrote:
> Is the issue that you learn about the hardware reset asynchronously,
> and therefore cannot determine if filter insertion programming
> happened afterwards and thus is still in the chip?
Yes, pretty much.
> You must have a table of all the entries, so that
From: Guillaume Nault
Date: Fri, 13 Apr 2018 18:09:12 +0200
> On Fri, Apr 13, 2018 at 10:57:03AM -0400, David Miller wrote:
>> From: Guillaume Nault
>> Date: Thu, 12 Apr 2018 20:50:33 +0200
>>
>> > l2tp_tunnel_find_nth() is unsafe: no reference is held on the returned
>> > tunnel, therefore it
From: Edward Cree
Date: Fri, 13 Apr 2018 16:59:07 +0100
> On 13/04/18 16:03, David Miller wrote:
>> Whilst you may not be able to program the filter into the hardware
>> synchronously, you should be able to allocate the ID and get all of
>> the software state setup.
> That's what we were doing be
On Fri, Apr 13, 2018 at 10:57:03AM -0400, David Miller wrote:
> From: Guillaume Nault
> Date: Thu, 12 Apr 2018 20:50:33 +0200
>
> > l2tp_tunnel_find_nth() is unsafe: no reference is held on the returned
> > tunnel, therefore it can be freed whenever the caller uses it.
> > This patch defines l2tp
On 13/04/18 16:03, David Miller wrote:
> Whilst you may not be able to program the filter into the hardware
> synchronously, you should be able to allocate the ID and get all of
> the software state setup.
That's what we were doing before commit 3af0f34290f6 ("sfc: replace
asynchronous filter oper
On Fri, Apr 13, 2018 at 2:43 PM, Dan Streetman wrote:
> On Thu, Apr 12, 2018 at 8:15 AM, Dmitry Vyukov wrote:
>> On Wed, Feb 21, 2018 at 3:53 PM, Tommi Rantala
>> wrote:
>>> On 20.02.2018 18:26, Neil Horman wrote:
On Tue, Feb 20, 2018 at 09:14:41AM +0100, Dmitry Vyukov wrote:
>
>>>
> -Original Message-
> From: Bjorn Helgaas [mailto:helg...@kernel.org]
> Sent: Friday, April 13, 2018 7:07 AM
> To: Jakub Kicinski
> Cc: Tal Gilboa ; Tariq Toukan ;
> Keller, Jacob E ; Ariel Elior
> ;
> Ganesh Goudar ; Kirsher, Jeffrey T
> ; everest-linux...@cavium.com; intel-wired-
> l
From: Jason Wang
Date: Fri, 13 Apr 2018 14:58:25 +0800
> We tends to batch submitting packets during XDP_TX. This requires to
> kick virtqueue after a batch, we tried to do it through
> xdp_do_flush_map() which only makes sense for devmap not XDP_TX. So
> explicitly kick the virtqueue in this cas
On Sun, Apr 01, 2018 at 10:12:16PM +0800, Tiwei Bie wrote:
> +static inline bool more_used(const struct vring_virtqueue *vq)
> +{
> + return vq->packed ? more_used_packed(vq) : more_used_split(vq);
> +}
> +
> +void *virtqueue_get_buf_ctx_split(struct virtqueue *_vq, unsigned int *len,
> +
On Fri, Apr 13, 2018 at 03:22:37PM +0200, Jesper Dangaard Brouer wrote:
> Hi Peter,
>
> Your commit d0266046ad54 ("x86: Remove FAST_FEATURE_TESTS") broke build
> for several samples/bpf programs. I'm unsure what the best way forward
> is to unbreak these...
>
> The issue is that these samples are
From: Edward Cree
Date: Fri, 13 Apr 2018 15:52:25 +0100
> On 13/04/18 15:45, David Miller wrote:
>> I understand the constraints you are working under, but do realize
>> that the real root of the problems is that you are implementing what
>> is defined clearly as a synchronous operation as asynch
On 04/06/2018 02:07 AM, Dominique Martinet wrote:
> (current kernel: vanilla 4.14.29)
>
> I've been running into troubles recently where a sockets "fills up" (as
> in, select() will no longer return it in its outfd / attempting to write
> to it after setting it to NONBLOCK will return -EWOULDBLO
From: Guillaume Nault
Date: Thu, 12 Apr 2018 20:50:33 +0200
> l2tp_tunnel_find_nth() is unsafe: no reference is held on the returned
> tunnel, therefore it can be freed whenever the caller uses it.
> This patch defines l2tp_tunnel_get_nth() which works similarly, but
> also takes a reference on t
On Fri, Apr 13, 2018 at 3:15 PM, Pablo Neira Ayuso wrote:
> On Mon, Apr 09, 2018 at 04:43:40PM +0200, Arnd Bergmann wrote:
>> On Mon, Apr 9, 2018 at 4:37 PM, Pablo Neira Ayuso
>> wrote:
>> > Hi Arnd,
>> >
>> > On Mon, Apr 09, 2018 at 12:53:12PM +0200, Arnd Bergmann wrote:
>> >> We get a new link
On 13/04/18 13:36, Edward Cree wrote:
> It turns out this may all be moot anyway: I figured out why I was seeing
> ARFS storms and it wasn't the configuration issue I originally blamed.
Hmm, correction, while the fix I mentioned in my previous email is needed,
it doesn't prevent the ARFS storms (
From: Edward Cree
Date: Fri, 13 Apr 2018 13:36:28 +0100
> It turns out this may all be moot anyway: I figured out why I was seeing
> ARFS storms and it wasn't the configuration issue I originally blamed.
> My current ndo_rx_flow_steer() implementation, efx_filter_rfs(), returns
> 0 for success,
From: Igor Russkikh
Date: Fri, 13 Apr 2018 15:03:29 +0300
> Could you please consider queuing to v4.16:
>
> 9a11aff net: aquantia: oops when shutdown on already stopped device
> cce96d1 net: aquantia: Regression on reset with 1.x firmware
>
> These are both critical and well tested by our team.
On Thu, Apr 12, 2018 at 09:32:49PM -0700, Jakub Kicinski wrote:
> On Fri, 30 Mar 2018 16:05:18 -0500, Bjorn Helgaas wrote:
> > + if (bw_avail >= bw_cap)
> > + pci_info(dev, "%d Mb/s available bandwidth (%s x%d link)\n",
> > +bw_cap, PCIE_SPEED2STR(speed_cap), width_c
Hi Peter,
Your commit d0266046ad54 ("x86: Remove FAST_FEATURE_TESTS") broke build
for several samples/bpf programs. I'm unsure what the best way forward
is to unbreak these...
The issue is that these samples are build with LLVM/clang (which
doesn't like 'asm goto' constructs). And they end up in
On Mon, Apr 09, 2018 at 04:43:40PM +0200, Arnd Bergmann wrote:
> On Mon, Apr 9, 2018 at 4:37 PM, Pablo Neira Ayuso wrote:
> > Hi Arnd,
> >
> > On Mon, Apr 09, 2018 at 12:53:12PM +0200, Arnd Bergmann wrote:
> >> We get a new link error with CONFIG_NFT_REJECT_INET=y and
> >> CONFIG_NF_REJECT_IPV6=m
On Thu, Apr 12, 2018 at 8:15 AM, Dmitry Vyukov wrote:
> On Wed, Feb 21, 2018 at 3:53 PM, Tommi Rantala
> wrote:
>> On 20.02.2018 18:26, Neil Horman wrote:
>>>
>>> On Tue, Feb 20, 2018 at 09:14:41AM +0100, Dmitry Vyukov wrote:
On Tue, Feb 20, 2018 at 8:56 AM, Tommi Rantala
wrote:
>
It turns out this may all be moot anyway: I figured out why I was seeing
ARFS storms and it wasn't the configuration issue I originally blamed.
My current ndo_rx_flow_steer() implementation, efx_filter_rfs(), returns
0 for success, but the caller expects a filter ID to be returned (which
we can'
Hi David,
Could you please consider queuing to v4.16:
9a11aff net: aquantia: oops when shutdown on already stopped device
cce96d1 net: aquantia: Regression on reset with 1.x firmware
These are both critical and well tested by our team.
Thanks in advance!
When parsing the options provided by the user space,
team_nl_cmd_options_set() insert them in a temporary list to send
multiple events with a single message.
While each option's attribute is correctly validated, the code does
not check for duplicate entries before inserting into the event
list.
Ex
On Thu, Apr 12, 2018 at 02:15:30PM +0200, Dmitry Vyukov wrote:
> On Wed, Feb 21, 2018 at 3:53 PM, Tommi Rantala
> wrote:
> > On 20.02.2018 18:26, Neil Horman wrote:
> >>
> >> On Tue, Feb 20, 2018 at 09:14:41AM +0100, Dmitry Vyukov wrote:
> >>>
> >>> On Tue, Feb 20, 2018 at 8:56 AM, Tommi Rantala
>
On Thu, Apr 12, 2018 at 12:03:15PM -0700, Jacek Kalwas wrote:
> Status checking in xfrm_input doesn't cover CRYPTO_GENERIC_ERROR and
> CRYPTO_INVALID_PACKET_SYNTAX.
>
> Given patch adds additional check for CRYPTO_INVALID_PACKET_SYNTAX and
> treats CRYPTO_GENERIC_ERROR as status matching LINUX_MIB
Note this is mostly me talking to myself, but in case anyone else hits
the same issues I might as well post my meagre progress.
Dominique Martinet wrote on Fri, Apr 06, 2018:
> (current kernel: vanilla 4.14.29)
reproduced in a fedora VM on that host with a 4.16.1-300.fc28.x86_64
kernel, since th
If the kernel headers aren't installed we can't build all the tests.
Add a new make target rule 'khdr' in the file lib.mk to generate the
kernel headers and that gets include for every test-dir Makefile that
includes lib.mk If the testdir in turn have its own sub-dirs the
top_srcdir needs to be set
On Fri, Apr 13, 2018 at 11:56 AM, Or Gerlitz wrote:
> On Thu, Apr 12, 2018 at 11:33 PM, Samudrala, Sridhar
> wrote:
>> On 4/12/2018 1:20 PM, Or Gerlitz wrote:
>>>
>>> On Thu, Apr 12, 2018 at 8:05 PM, Samudrala, Sridhar
>>> wrote:
On 11/12/2017 11:49 AM, Or Gerlitz wrote:
>
> Hi
On Thu, Apr 12, 2018 at 11:33 PM, Samudrala, Sridhar
wrote:
> On 4/12/2018 1:20 PM, Or Gerlitz wrote:
>>
>> On Thu, Apr 12, 2018 at 8:05 PM, Samudrala, Sridhar
>> wrote:
>>>
>>> On 11/12/2017 11:49 AM, Or Gerlitz wrote:
Hi Dave and all,
During and after the BoF on SRIOV switch
On Fri, Apr 13, 2018 at 10:20 AM, Toshiaki Makita
wrote:
> On 2018/04/12 17:03, Dmitry Vyukov wrote:
>> On Thu, Apr 12, 2018 at 10:01 AM, syzbot
>> wrote:
>>> Hello,
>>>
>>> syzbot hit the following crash on https://github.com/google/kmsan.git/master
>>> commit
>>> e2ab7e8abba47a2f2698216258e5d87
On 2018/04/12 17:03, Dmitry Vyukov wrote:
> On Thu, Apr 12, 2018 at 10:01 AM, syzbot
> wrote:
>> Hello,
>>
>> syzbot hit the following crash on https://github.com/google/kmsan.git/master
>> commit
>> e2ab7e8abba47a2f2698216258e5d8727ae58717 (Fri Apr 6 16:24:31 2018 +)
>> kmsan: temporarily dis
On 2018/04/12 17:03, Dmitry Vyukov wrote:
> On Thu, Apr 12, 2018 at 10:01 AM, syzbot
> wrote:
>> Hello,
>>
>> syzbot hit the following crash on https://github.com/google/kmsan.git/master
>> commit
>> e2ab7e8abba47a2f2698216258e5d8727ae58717 (Fri Apr 6 16:24:31 2018 +)
>> kmsan: temporarily dis
On Fri, Apr 13, 2018 at 12:30:24PM +0800, Jason Wang wrote:
> On 2018年04月01日 22:12, Tiwei Bie wrote:
> > Hello everyone,
> >
> > This RFC implements packed ring support for virtio driver.
> >
> > The code was tested with DPDK vhost (testpmd/vhost-PMD) implemented
> > by Jens at http://dpdk.org/ml
stmmac reception handler calls stmmac_rx_vlan() to strip the vlan before
calling napi_gro_receive().
The function assumes VLAN tagged frames are always tagged with 802.1Q
protocol,
and assigns ETH_P_8021Q to the skb by hard-coding the parameter on call
to __vlan_hwaccel_put_tag() .
This causes pa
83 matches
Mail list logo
