From: Vladimir Oltean
Described in fd5736bf9f23 ("enetc: Workaround for MDIO register access
issue") is a workaround for a hardware bug that requires a register
access of the MDIO controller to never happen concurrently with a
register access of a port PF. To avoid that, a mutual exclusion scheme
Standalone ports always have VLAN filtering (Port Control 2, 802.1Q
Mode) disabled. So adding VIDs for any VLAN uppers to the VTU does not
make one bit of difference on the ingress filtering, the CPU will
still receive traffic from all VLANs.
It does however needlessly consume a precious global re
From: Yevgeny Kliteynik
Add HW specific action apply logic to STEv1.
Since STEv0 and STEv1 actions format is different, each
version has its implementation.
Signed-off-by: Alex Vesker
Signed-off-by: Yevgeny Kliteynik
Signed-off-by: Saeed Mahameed
---
.../mellanox/mlx5/core/steering
From: David Ahern
When a single instance of nettest is used for client and server
make sure address validation is only done for client mode.
Signed-off-by: David Ahern
---
tools/testing/selftests/net/nettest.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/tools/testing/selftests/ne
From: David Ahern
When a single instance of nettest is used for client and server
make sure address validation is only done for client mode.
Signed-off-by: David Ahern
---
tools/testing/selftests/net/nettest.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/tools/testing/selftests/ne
From: David Ahern
When a single instance of nettest is used for client and server
make sure address validation is only done for client mode.
Signed-off-by: David Ahern
---
tools/testing/selftests/net/nettest.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/tools/testing/selftests/ne
From: David Ahern
When a single instance of nettest is used for client and server
make sure address validation is only done for client mode.
Signed-off-by: David Ahern
---
tools/testing/selftests/net/nettest.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/tools/testing/selftests/ne
From: Yevgeny Kliteynik
Use STE tx/rx actions per-device API: move HW specific
action apply logic from dr_ste to STEv0 file - STEv0 and
STEv1 actions format is different, each version should
have its own implementation.
Signed-off-by: Alex Vesker
Signed-off-by: Yevgeny Kliteynik
Reviewed-by
From: Yevgeny Kliteynik
The action apply logic is device specific per STE version,
moving to the STE layer will allow implementing it for
both devices while keeping DR upper layers the same.
Signed-off-by: Alex Vesker
Signed-off-by: Yevgeny Kliteynik
Reviewed-by: Saeed Mahameed
Signed-off-by
From: Ido Schimmel
In case a router interface (RIF) is configured for a LAG, make sure its
configuration is applied on the new LAG member.
Signed-off-by: Ido Schimmel
Reviewed-by: Jiri Pirko
---
.../net/ethernet/mellanox/mlxsw/spectrum.c| 17 --
.../net/ethernet/mellanox/mlxsw/spe
From: Marek Majtyka
Update xdpsock sample so that it utilizes netlink ethtool interface
to get available XDP/XSK modes. This allows to automatically choose
the best available mode of operation, if these are not provided explicitly.
Signed-off-by: Marek Majtyka
---
samples/bpf/xdpsock_user.c |
generalize the "seq_show" seq file support in btf.c to support
a generic show callback of which we support two instances; the
current seq file show, and a show with snprintf() behaviour which
instead writes the type data to a supplied string.
Both classes of show function call btf_type_show() with
On Wed, Sep 23, 2020 at 06:46:24PM +0100, Alan Maguire wrote:
>
> +/* Chunk size we use in safe copy of data to be shown. */
> +#define BTF_SHOW_OBJ_SAFE_SIZE 256
sizeof(struct btf_show) == 472
It's allocated on stack and called from bpf prog.
It's a leaf function, but it still wor
generalize the "seq_show" seq file support in btf.c to support
a generic show callback of which we support two instances; the
current seq file show, and a show with snprintf() behaviour which
instead writes the type data to a supplied string.
Both classes of show function call btf_type_show() with
generalize the "seq_show" seq file support in btf.c to support
a generic show callback of which we support two instances; the
current seq file show, and a show with snprintf() behaviour which
instead writes the type data to a supplied string.
Both classes of show function call btf_type_show() with
On Sat, 2020-08-22 at 18:08 +0200, Andrew Lunn wrote:
> On Fri, Aug 21, 2020 at 09:21:46AM +0200, Matthias Schiffer wrote:
> > These DT bindings are already in use by the imx7-mba7 DTS, but they
> > were
> > not supported by the PHY driver so far.
> >
> > Signed-off-by: Matthias Schiffer > >
>
>
On Fri, Aug 21, 2020 at 09:21:46AM +0200, Matthias Schiffer wrote:
> These DT bindings are already in use by the imx7-mba7 DTS, but they were
> not supported by the PHY driver so far.
>
> Signed-off-by: Matthias Schiffer
Sorry, but NACK.
Please look at the work Marek Behún is doing
https://lkm
These DT bindings are already in use by the imx7-mba7 DTS, but they were
not supported by the PHY driver so far.
Signed-off-by: Matthias Schiffer
---
drivers/net/phy/dp83867.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/net/phy/dp83867.c b/drivers/
On Tue, Aug 18, 2020 at 10:12:05AM +0100, Alan Maguire wrote:
>
> Fair enough. I'm thinking a helper like
>
> long bpf_btf_snprintf(char *str, u32 str_size, struct btf_ptr *ptr,
> u32 ptr_size, u64 flags);
>
> Then the user can choose perf event or ringbuf interfaces
> to sha
On Fri, 14 Aug 2020, Alexei Starovoitov wrote:
> On Fri, Aug 14, 2020 at 02:06:37PM +0100, Alan Maguire wrote:
> > On Wed, 12 Aug 2020, Alexei Starovoitov wrote:
> >
> > > On Thu, Aug 06, 2020 at 03:42:23PM +0100, Alan Maguire wrote:
> > > >
> > > > The bpf_trace_printk tracepoint is augmented
On Fri, Aug 14, 2020 at 02:06:37PM +0100, Alan Maguire wrote:
> On Wed, 12 Aug 2020, Alexei Starovoitov wrote:
>
> > 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
On Wed, 12 Aug 2020, Alexei Starovoitov wrote:
> 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 wit
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
generalize the "seq_show" seq file support in btf.c to support
a generic show callback of which we support three instances;
- the current seq file show
- a show which triggers the bpf_trace/bpf_trace_printk tracepoint
for each portion of the data displayed
Both classes of show function call btf
educe snd_cwnd and result in a
> low throughput. It would be hard to mitigate this with filtering in
> the congestion control module, because the proper floor to apply would
> depend on the method of RTT sampling (using timestamp options or
> internally-saved transmission timestamps).
>
On Fri, Jul 10, 2020 at 02:08:48PM +0200, Oleksij Rempel wrote:
> The ksz8873 and ksz8863 switches are affected by following errata:
This should really be a patch on its own, aimed at net, so it gets
back ported to stable.
Andrew
int ret;
+
+ /* Apply errata workaround for KSZ8863 and KSZ8873:
+* Receiver error in 100BASE-TX mode following Soft Power Down
+*
+* When exiting Soft Power Down mode, the receiver blocks may not start
+* up properly, causing the PHY to miss data and exhib
generalize the "seq_show" seq file support in btf.c to support
a generic show callback of which we support two instances; the
current seq file show, and a show with snprintf() behaviour which
instead writes the type data to a supplied string.
Both classes of show function call btf_type_show() with
On Tue, 2020-05-19 at 17:06 +0100, David Howells wrote:
> Okay, how about this incremental change, then? If fixes the typo, only prints
> the "READ CONFIG" line in verbose mode, filters escape chars in the config
> file and reduces the expiration time to 5s.
>
> David
> ---
> diff --git a/key.dns
On Tue, May 19, 2020 at 17:06:49 +0100, David Howells wrote:
> Okay, how about this incremental change, then? If fixes the typo, only prints
> the "READ CONFIG" line in verbose mode, filters escape chars in the config
> file and reduces the expiration time to 5s.
Thanks! Looks good to me.
Review
Okay, how about this incremental change, then? If fixes the typo, only prints
the "READ CONFIG" line in verbose mode, filters escape chars in the config
file and reduces the expiration time to 5s.
David
---
diff --git a/key.dns_resolver.c b/key.dns_resolver.c
index c241eda3..7a7ec424 100644
--- a
* David Howells:
> Fix this to apply a default TTL of 10mins in the event that we haven't got
> one. This can be configured in /etc/keyutils/key.dns_resolver.conf by
> adding the line:
>
> default_ttl:
>
> to the file.
If the name resolution is not needed cont
On Tue, May 19, 2020 at 14:39:40 +0100, David Howells wrote:
> Ben Boeckel wrote:
> > Is there precedent for this config file format?
>
> Okay, I can change it to:
>
> default_ttl =
>
> and strip spaces all over the place.
Thanks. This is at least a subset of other formats with specs th
with a
.so directive in it.
Anyway, how about the attached?
David
---
commit cbf0457e0fc99aa5beabe54daeda57be70dfdfce
Author: David Howells
Date: Tue Apr 14 16:07:26 2020 +0100
dns: Apply a default TTL to records obtained from getaddrinfo()
Address records obtained from getaddrinfo()
On 5/18/20 2:46 AM, Alan Maguire wrote:
On Wed, 13 May 2020, Yonghong Song wrote:
+struct btf_show {
+ u64 flags;
+ void *target; /* target of show operation (seq file, buffer) */
+ void (*showfn)(struct btf_show *show, const char *fmt, ...);
+ const struct btf *b
n dns_resolver
> records unless they include a component obtained directly from the DNS,
> such as an SRV or AFSDB record.
>
> Fix this to apply a default TTL of 10mins in the event that we haven't got
> one. This can be configured in /etc/keyutils/key.dns_resolver.conf by
> ad
DNS,
such as an SRV or AFSDB record.
Fix this to apply a default TTL of 10mins in the event that we haven't got
one. This can be configured in /etc/keyutils/key.dns_resolver.conf by
adding the line:
default_ttl:
to the file.
Signed-off-by: David Howells
---
Makefile
On Wed, 13 May 2020, Yonghong Song wrote:
>
> > +struct btf_show {
> > + u64 flags;
> > + void *target; /* target of show operation (seq file, buffer) */
> > + void (*showfn)(struct btf_show *show, const char *fmt, ...);
> > + const struct btf *btf;
> > + /* below are used during iter
Only helps for testing while the kernel side patches are not applied.
Signed-off-by: Vinicius Costa Gomes
---
uapi/linux/ethtool.h | 49 ++-
uapi/linux/ethtool_netlink.h | 267 +++
2 files changed, 315 insertions(+), 1 deletion(-)
diff --git a/uapi/l
From: Jérôme Pouiller
Strings are allowed to exceed 80 columns but, in this case, the format
arguments should be placed on a new line. Apply this rule to the whole
code of the driver.
Signed-off-by: Jérôme Pouiller
---
drivers/staging/wfx/bus_sdio.c | 3 ++-
drivers/staging/wfx/data_tx.c
On 5/11/20 10:56 PM, Alan Maguire wrote:
generalize the "seq_show" seq file support in btf.c to support
a generic show callback of which we support two instances; the
current seq file show, and a show with snprintf() behaviour which
instead writes the type data to a supplied string.
Both clas
generalize the "seq_show" seq file support in btf.c to support
a generic show callback of which we support two instances; the
current seq file show, and a show with snprintf() behaviour which
instead writes the type data to a supplied string.
Both classes of show function call btf_type_show() with
etronome.com;
> pa...@netfilter.org; mo...@mellanox.com; m-kariche...@ti.com;
> andre.gue...@linux.intel.com; step...@networkplumber.org
> Subject: Re: [v5,net-next 0/4] Introduce a flow gate control action
> and apply IEEE
>
> From: Po Liu
> Date: Fri, 1 May 2020 08:53:14 +0800
&g
From: Po Liu
Date: Fri, 1 May 2020 08:53:14 +0800
...
> These patches add stream gate action policing in IEEE802.1Qci (Per-Stream
> Filtering and Policing) software support and hardware offload support in
> tc flower, and implement the stream identify, stream filtering and
> stream gate filteri
From: Michael Walle
Date: Wed, 29 Apr 2020 01:06:58 +0200
> The lower three bits of the phy_id specifies the chip stepping. The
> workaround is specifically for the B0 stepping. Apply it only on these
> chips.
>
> Signed-off-by: Michael Walle
> Reviewed-by: Andrew Lunn
>
Changes from V4:
0001:
Fix and modify according to Vlid Buslov suggestions:
- Change spin_lock_bh() to spin_lock() since tcf_gate_act() already in
software irq.
- Remove spin lock protect in the ops->cleanup function.
- Enable the CONFIG_DEBUG_ATOMIC_SLEEP and CONFIG_PROVE_LOCKING
The lower three bits of the phy_id specifies the chip stepping. The
workaround is specifically for the B0 stepping. Apply it only on these
chips.
Signed-off-by: Michael Walle
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
---
changes since v1:
- added reviewed-by tags
drivers/net
On 4/28/20 2:08 PM, Michael Walle wrote:
> The lower three bits of the phy_id specifies the chip stepping. The
> workaround is specifically for the B0 stepping. Apply it only on these
> chips.
>
> Signed-off-by: Michael Walle
Reviewed-by: Florian Fainelli
--
Florian
On Tue, Apr 28, 2020 at 11:08:53PM +0200, Michael Walle wrote:
> The lower three bits of the phy_id specifies the chip stepping. The
> workaround is specifically for the B0 stepping. Apply it only on these
> chips.
>
> Signed-off-by: Michael Walle
Reviewed-by: Andrew Lunn
Andrew
The lower three bits of the phy_id specifies the chip stepping. The
workaround is specifically for the B0 stepping. Apply it only on these
chips.
Signed-off-by: Michael Walle
---
drivers/net/phy/bcm54140.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers
--
Hello,
We are private lenders based in UK.
Do you need a loan (credit) as soon as possible. Are you in search of
money to solve your personal needs or finance your business venture,
then get Your desired loan today! Consult us at Sunrise Funding Ltd.
* We offer personal loan & huge capital l
On Fri, Aug 02, 2019 at 09:58:12PM +0200, Bernd wrote:
> 2019-08-02 21:14 GMT+02:00, Neal Cardwell :
> > What's the exact kernel version you are using?
>
> It is the RHEL errata kernel 3.10.0-957.21.3.el7 (rhsa-2019:1481), i
> need to check if there is a newer one.
FWIW, this one doesn't have the
2019-08-02 21:14 GMT+02:00, Neal Cardwell :
> What's the exact kernel version you are using?
It is the RHEL errata kernel 3.10.0-957.21.3.el7 (rhsa-2019:1481), i
need to check if there is a newer one.
> Eric submitted a patch recently that may address your issue:
>tcp: be more careful in tcp_
On Fri, Aug 2, 2019 at 3:03 PM Bernd wrote:
>
> Hello,
>
> While analyzing a aborted upload packet capture I came across a odd
> trace where a sender was not responding to a duplicate SACK but
> sending further segments until it stalled.
>
> Took me some time until I remembered this fix, and actua
Hello,
While analyzing a aborted upload packet capture I came across a odd
trace where a sender was not responding to a duplicate SACK but
sending further segments until it stalled.
Took me some time until I remembered this fix, and actually the
problems started since the security fix was applied
From: Pablo Neira Ayuso
Date: Tue, 16 Jul 2019 20:52:20 +0200
> On Sat, Jul 06, 2019 at 07:55:21PM +0300, Alexey Dobriyan wrote:
>> From: "Hallsmark, Per"
>>
>> proc_net_mkdir() should be used to create stuff under /proc/net,
>> so that dentry revalidation kicks in.
>>
>> See
>>
>> commi
On Sat, Jul 06, 2019 at 07:55:21PM +0300, Alexey Dobriyan wrote:
> From: "Hallsmark, Per"
>
> proc_net_mkdir() should be used to create stuff under /proc/net,
> so that dentry revalidation kicks in.
>
> See
>
> commit 1fde6f21d90f8ba5da3cb9c54ca991ed72696c43
> proc: fix /proc/net/*
On 7/11/2019 11:15 PM, Prout, Andrew - LLSC - MITLL wrote:
> I in no way intended to imply that I had confirmed the small SO_SNDBUF was a
> prerequisite to our problem. With my synthetic test, I was looking for a
> concise reproducer and trying things to > stress the system.
I've looked into th
On 7/11/19 9:04 PM, Jonathan Lemon wrote:
> I discovered we have some production services that set SO_SNDBUF to
> very small values (~4k), as they are essentially doing interactive
> communications, not bulk transfers. But there's a difference between
> "terrible performance" and "TCP stops w
On 11 Jul 2019, at 11:28, Eric Dumazet wrote:
On 7/11/19 7:14 PM, Prout, Andrew - LLSC - MITLL wrote:
In my opinion, if a small SO_SNDBUF below a certain value is no
longer supported, then SOCK_MIN_SNDBUF should be adjusted to reflect
this. The RCVBUF/SNDBUF sizes are supposed to be hints
On 7/11/19 8:26 PM, Michal Kubecek wrote:
>
> I'm aware it's not a realistic test. It was written as quick and simple
> check of the pre-4.19 patch, but it shows that even TLP may not get
> through.
Most of TLP probes send new data, not rtx.
But yes, I get your point.
SO_SNDBUF=15000 in yo
On 7/11/19 7:14 PM, Prout, Andrew - LLSC - MITLL wrote:
>
> In my opinion, if a small SO_SNDBUF below a certain value is no longer
> supported, then SOCK_MIN_SNDBUF should be adjusted to reflect this. The
> RCVBUF/SNDBUF sizes are supposed to be hints, no error is returned if they
> are not
On Thu, Jul 11, 2019 at 11:19:45AM +0200, Eric Dumazet wrote:
>
>
> On 7/11/19 9:28 AM, Christoph Paasch wrote:
> >
> >
> >> On Jul 10, 2019, at 9:26 PM, Eric Dumazet wrote:
> >>
> >>
> >>
> >> On 7/10/19 8:53 PM, Prout, Andrew - LLSC - MITLL wrote:
> >>>
> >>> Our initial rollout was v4.14.13
On 7/10/19 3:27 PM, Eric Dumazet wrote:
> On 7/10/19 8:53 PM, Prout, Andrew - LLSC - MITLL wrote:
>>
>> Our initial rollout was v4.14.130, but I reproduced it with v4.14.132 as
>> well, reliably for the samba test and once (not reliably) with synthetic
>> test I was trying. A patched v4.14.132
On 7/11/19 9:28 AM, Christoph Paasch wrote:
>
> Would it make sense to always allow the alloc in tcp_fragment when coming
> from __tcp_retransmit_skb() through the retransmit-timer ?
>
> AFAICS, the crasher was when an attacker sends "fake" SACK-blocks. Thus, we
> would still be protected f
On 7/11/19 9:28 AM, Christoph Paasch wrote:
>
>
>> On Jul 10, 2019, at 9:26 PM, Eric Dumazet wrote:
>>
>>
>>
>> On 7/10/19 8:53 PM, Prout, Andrew - LLSC - MITLL wrote:
>>>
>>> Our initial rollout was v4.14.130, but I reproduced it with v4.14.132 as
>>> well, reliably for the samba test and o
> On Jul 10, 2019, at 9:26 PM, Eric Dumazet wrote:
>
>
>
> On 7/10/19 8:53 PM, Prout, Andrew - LLSC - MITLL wrote:
>>
>> Our initial rollout was v4.14.130, but I reproduced it with v4.14.132 as
>> well, reliably for the samba test and once (not reliably) with synthetic
>> test I was tryin
On 7/10/19 8:53 PM, Prout, Andrew - LLSC - MITLL wrote:
>
> Our initial rollout was v4.14.130, but I reproduced it with v4.14.132 as
> well, reliably for the samba test and once (not reliably) with synthetic test
> I was trying. A patched v4.14.132 with this patch partially reverted (just
>
ing / dying off without disconnecting. They're stuck and
>> never recover.
>>
>> I bisected the problem to 4.14.127 commit
>> 9daf226ff92679d09aeca1b5c1240e3607153336 (commit
>> f070ef2ac66716357066b683fb0baf55f8191a2e upstream): tcp: tcp_fragment()
>> should ap
ating our kernel, we’ve been having a problem with TCP
connections stalling / dying off without disconnecting. They're stuck and never
recover.
I bisected the problem to 4.14.127 commit
9daf226ff92679d09aeca1b5c1240e3607153336 (commit
f070ef2ac66716357066b683fb0baf55f8191a2e upstream): tcp
I bisected the problem to 4.14.127 commit
> 9daf226ff92679d09aeca1b5c1240e3607153336 (commit
> f070ef2ac66716357066b683fb0baf55f8191a2e upstream): tcp: tcp_fragment()
> should apply sane memory limits. That lead me to this thread.
>
> Our environment is a supercomputing center: lots of ser
From: "Hallsmark, Per"
proc_net_mkdir() should be used to create stuff under /proc/net,
so that dentry revalidation kicks in.
See
commit 1fde6f21d90f8ba5da3cb9c54ca991ed72696c43
proc: fix /proc/net/* after setns(2)
[added more chunks --adobriyan]
Signed-off-by: "Hallsm
From: Shalom Toledo
Apply by filling the PTP shaper parameters array.
Signed-off-by: Shalom Toledo
Reviewed-by: Petr Machata
Acked-by: Jiri Pirko
Signed-off-by: Ido Schimmel
---
.../ethernet/mellanox/mlxsw/spectrum_ptp.c| 44 +++
1 file changed, 44 insertions(+)
diff
On 6/17/19 8:53 PM, Christoph Paasch wrote:
> On Mon, Jun 17, 2019 at 8:44 PM Eric Dumazet wrote:
>>
>>
>>
>> On 6/17/19 8:19 PM, Christoph Paasch wrote:
>>>
>>> Yes, this does the trick for my packetdrill-test.
>>>
>>> I wonder, is there a way we could end up in a situation where we can't
>>>
On Mon, Jun 17, 2019 at 8:44 PM Eric Dumazet wrote:
>
>
>
> On 6/17/19 8:19 PM, Christoph Paasch wrote:
> >
> > Yes, this does the trick for my packetdrill-test.
> >
> > I wonder, is there a way we could end up in a situation where we can't
> > retransmit anymore?
> > For example, sk_wmem_queued h
On 6/17/19 8:19 PM, Christoph Paasch wrote:
>
> Yes, this does the trick for my packetdrill-test.
>
> I wonder, is there a way we could end up in a situation where we can't
> retransmit anymore?
> For example, sk_wmem_queued has grown so much that the new test fails.
> Then, if we legitimately
On Mon, Jun 17, 2019 at 7:28 PM Eric Dumazet wrote:
>
>
>
> On 6/17/19 5:18 PM, Christoph Paasch wrote:
> >
> > Hi Eric, I now have a packetdrill test that started failing (see
> > below). Admittedly, a bit weird test with the SO_SNDBUF forced so low.
> >
> > Nevertheless, previously this test wou
On 6/17/19 5:18 PM, Christoph Paasch wrote:
>
> Hi Eric, I now have a packetdrill test that started failing (see
> below). Admittedly, a bit weird test with the SO_SNDBUF forced so low.
>
> Nevertheless, previously this test would pass, now it stalls after the
> write() because tcp_fragment()
On Mon, Jun 17, 2019 at 10:05 AM Eric Dumazet wrote:
>
> Jonathan Looney reported that a malicious peer can force a sender
> to fragment its retransmit queue into tiny skbs, inflating memory
> usage and/or overflow 32bit counters.
>
> TCP allows an application to queue up to sk_sndbuf bytes,
> so
On 17 Jun 2019, at 10:03, Eric Dumazet wrote:
> Jonathan Looney reported that a malicious peer can force a sender
> to fragment its retransmit queue into tiny skbs, inflating memory
> usage and/or overflow 32bit counters.
>
> TCP allows an application to queue up to sk_sndbuf bytes,
> so we nee
Jonathan Looney reported that a malicious peer can force a sender
to fragment its retransmit queue into tiny skbs, inflating memory
usage and/or overflow 32bit counters.
TCP allows an application to queue up to sk_sndbuf bytes,
so we need to give some allowance for non malicious splitting
of retra
CPCMD_QUIRK_MASK isn't specific to certain chip versions. The vendor
driver applies this mask to all 8168 versions. Therefore remove QUIRK
from the mask name and apply it on all chip versions.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c
From: Harini Katakam
[ Upstream commit e501070e4db0b67a4c17a5557d1e9d098f3db310 ]
The interrupt handler contains a workaround for RX hang applicable
to Zynq and AT91RM9200 only. Subsequent versions do not need this
workaround. This workaround unnecessarily resets RX whenever RX used
bit read is
From: Harini Katakam
[ Upstream commit e501070e4db0b67a4c17a5557d1e9d098f3db310 ]
The interrupt handler contains a workaround for RX hang applicable
to Zynq and AT91RM9200 only. Subsequent versions do not need this
workaround. This workaround unnecessarily resets RX whenever RX used
bit read is
From: Tariq Toukan
Take into a function the common code structure of opening
a side set of channels followed by a call to apply them.
Signed-off-by: Tariq Toukan
Signed-off-by: Saeed Mahameed
---
drivers/net/ethernet/mellanox/mlx5/core/en.h | 6 +--
.../ethernet/mellanox/mlx5/core
From: Beniamino Galvani
Date: Fri, 15 Feb 2019 13:20:42 +0100
> The 1199:68C0 USB ID is reused by Sierra WP7607 which requires the DTR
> quirk to be detected. Apply QMI_QUIRK_SET_DTR unconditionally as
> already done for other IDs shared between different devices.
>
> Signed-of
Beniamino Galvani writes:
> The 1199:68C0 USB ID is reused by Sierra WP7607 which requires the DTR
> quirk to be detected. Apply QMI_QUIRK_SET_DTR unconditionally as
> already done for other IDs shared between different devices.
>
> Signed-off-by: Beniamino Galvani
Thanks. Looks
The 1199:68C0 USB ID is reused by Sierra WP7607 which requires the DTR
quirk to be detected. Apply QMI_QUIRK_SET_DTR unconditionally as
already done for other IDs shared between different devices.
Signed-off-by: Beniamino Galvani
---
drivers/net/usb/qmi_wwan.c | 4 ++--
1 file changed, 2
From: Harini Katakam
Date: Tue, 29 Jan 2019 15:20:03 +0530
> The interrupt handler contains a workaround for RX hang applicable
> to Zynq and AT91RM9200 only. Subsequent versions do not need this
> workaround. This workaround unnecessarily resets RX whenever RX used
> bit read is observed, which
The interrupt handler contains a workaround for RX hang applicable
to Zynq and AT91RM9200 only. Subsequent versions do not need this
workaround. This workaround unnecessarily resets RX whenever RX used
bit read is observed, which can be often under heavy traffic. There
is no other action performed
Hi Nicolas,
On Fri, Jan 25, 2019 at 3:58 PM wrote:
>
> On 24/01/2019 at 14:38, Harini Katakam wrote:
> > The interrupt handler contains a workaround for RX hang applicable
> > to Zynq and AT91 only. Subsequent versions do not need this
>
> AT91RM9200 only. It's not the case for other AT91 SoCs (r
On 24/01/2019 at 14:38, Harini Katakam wrote:
> The interrupt handler contains a workaround for RX hang applicable
> to Zynq and AT91 only. Subsequent versions do not need this
AT91RM9200 only. It's not the case for other AT91 SoCs (reading errata
list for them).
That being said I have to add a
The interrupt handler contains a workaround for RX hang applicable
to Zynq and AT91 only. Subsequent versions do not need this
workaround. This workaround unecessarily resets RX whenever RX used
bit read is observed, which can be often under heavy traffic. Hence
introduce an CAPS mask and a check t
If a testcase has alignment problems but is expected to be ACCEPT,
verify it using F_NEEDS_EFFICIENT_UNALIGNED_ACCESS too.
Maybe in the future if we add some architecture specific code to elide
the unaligned memory access warnings during the test, we can execute
these as well.
Signed-off-by: Da
If a testcase has alignment problems but is expected to be ACCEPT,
verify it using F_NEEDS_EFFICIENT_UNALIGNED_ACCESS too.
Maybe in the future if we add some architecture specific code to elide
the unaligned memory access warnings during the test, we can execute
these as well.
Signed-off-by: Da
Good Day,
Getting a legitimate loan have always been a huge problem to clients who are in
financial needs.The issue of credit and collateral are something that clients
are always worried about when seeking a loan from a legitimate lender. Sun
Finance Company has made that difference in the lendi
On 29.11.2018 12:38, Harini Katakam wrote:
> Hi Claudiu,
> On Thu, Nov 29, 2018 at 3:51 PM wrote:
>>
>>
>>
>> On 23.11.2018 11:59, Harini Katakam wrote:
>
>>> - if (status & MACB_BIT(RXUBR)) {
>>> + if ((bp->errata & MACB_ERRATA_RXLOCKUP) &&
>>> + (status
Hi Claudiu,
On Thu, Nov 29, 2018 at 3:51 PM wrote:
>
>
>
> On 23.11.2018 11:59, Harini Katakam wrote:
> > - if (status & MACB_BIT(RXUBR)) {
> > + if ((bp->errata & MACB_ERRATA_RXLOCKUP) &&
> > + (status & MACB_BIT(RXUBR))) {
>
> Just asking, did you manage
On 23.11.2018 11:59, Harini Katakam wrote:
> The interrupt handler contains a workaround for RX hang applicable
> to Zynq and AT91 only. Subsequent versions do not need this
> workaround. This workaround unecessarily reset RX whenever RX used
> bit read is observed, which can be often under heavy
On 28.11.2018 23:09, Brandon Streiff wrote:
> On 11/23/2018 3:59 AM, Harini Katakam wrote:
>> +/* Errata mask bits */
>> +#define MACB_ERRATA_RXLOCKUP0x0001
>> +
>> /* LSO settings */
>> #define MACB_LSO_UFO_ENABLE 0x01
>> #define MACB_LSO_TSO_ENABLE
1 - 100 of 309 matches
Mail list logo
