* [PATCH net-next 0/5] sctp: fully support for dscp and flowlabel per transport
From: Xin Long @ 2018-06-25 2:14 UTC (permalink / raw)
To: network dev, linux-sctp; +Cc: Marcelo Ricardo Leitner, Neil Horman, davem
Now dscp and flowlabel are set from sock when sending the packets,
but being multi-homing, sctp also supports for dscp and flowlabel
per transport, which is described in section 8.1.12 in RFC6458.
Xin Long (5):
ipv4: add __ip_queue_xmit() that supports tos param
sctp: add support for dscp and flowlabel per transport
sctp: add spp_ipv6_flowlabel and spp_dscp for sctp_paddrparams
sctp: add support for setting flowlabel when adding a transport
sctp: check for ipv6_pinfo legal sndflow with flowlabel in
sctp_v6_get_dst
include/linux/sctp.h | 7 ++
include/net/ip.h | 2 +
include/net/sctp/structs.h | 9 +++
include/uapi/linux/sctp.h | 4 ++
net/ipv4/ip_output.c | 13 +++-
net/sctp/associola.c | 15 +++++
net/sctp/ipv6.c | 20 +++++-
net/sctp/protocol.c | 16 +++--
net/sctp/socket.c | 157 +++++++++++++++++++++++++++++++++++++++++++++
9 files changed, 234 insertions(+), 9 deletions(-)
--
2.1.0
^ permalink raw reply
* [PATCHv2 net-next] sctp: add support for SCTP_REUSE_PORT sockopt
From: Xin Long @ 2018-06-25 2:06 UTC (permalink / raw)
To: network dev, linux-sctp
Cc: Marcelo Ricardo Leitner, Neil Horman, Michael Tuexen, davem
This feature is actually already supported by sk->sk_reuse which can be
set by socket level opt SO_REUSEADDR. But it's not working exactly as
RFC6458 demands in section 8.1.27, like:
- This option only supports one-to-one style SCTP sockets
- This socket option must not be used after calling bind()
or sctp_bindx().
Besides, SCTP_REUSE_PORT sockopt should be provided for user's programs.
Otherwise, the programs with SCTP_REUSE_PORT from other systems will not
work in linux.
To separate it from the socket level version, this patch adds 'reuse' in
sctp_sock and it works pretty much as sk->sk_reuse, but with some extra
setup limitations that are needed when it is being enabled.
"It should be noted that the behavior of the socket-level socket option
to reuse ports and/or addresses for SCTP sockets is unspecified", so it
leaves SO_REUSEADDR as is for the compatibility.
Note that the name SCTP_REUSE_PORT is kind of confusing, it is identical
to SO_REUSEADDR with some extra restriction, so here it uses 'reuse' in
sctp_sock instead of 'reuseport'. As for sk->sk_reuseport support for
SCTP, it will be added in another patch.
Thanks to Neil to make this clear.
v1->v2:
- add sctp_sk->reuse to separate it from the socket level version.
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
include/net/sctp/structs.h | 1 +
include/uapi/linux/sctp.h | 1 +
net/sctp/socket.c | 62 ++++++++++++++++++++++++++++++++++++++++------
3 files changed, 57 insertions(+), 7 deletions(-)
diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
index e0f962d..701a517 100644
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -220,6 +220,7 @@ struct sctp_sock {
__u32 adaptation_ind;
__u32 pd_point;
__u16 nodelay:1,
+ reuse:1,
disable_fragments:1,
v4mapped:1,
frag_interleave:1,
diff --git a/include/uapi/linux/sctp.h b/include/uapi/linux/sctp.h
index b64d583..c02986a 100644
--- a/include/uapi/linux/sctp.h
+++ b/include/uapi/linux/sctp.h
@@ -100,6 +100,7 @@ typedef __s32 sctp_assoc_t;
#define SCTP_RECVNXTINFO 33
#define SCTP_DEFAULT_SNDINFO 34
#define SCTP_AUTH_DEACTIVATE_KEY 35
+#define SCTP_REUSE_PORT 36
/* Internal Socket Options. Some of the sctp library functions are
* implemented using these socket options.
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 0e91e83..bf11f9c 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -4170,6 +4170,28 @@ static int sctp_setsockopt_interleaving_supported(struct sock *sk,
return retval;
}
+static int sctp_setsockopt_reuse_port(struct sock *sk, char __user *optval,
+ unsigned int optlen)
+{
+ int val;
+
+ if (!sctp_style(sk, TCP))
+ return -EOPNOTSUPP;
+
+ if (sctp_sk(sk)->ep->base.bind_addr.port)
+ return -EFAULT;
+
+ if (optlen < sizeof(int))
+ return -EINVAL;
+
+ if (get_user(val, (int __user *)optval))
+ return -EFAULT;
+
+ sctp_sk(sk)->reuse = !!val;
+
+ return 0;
+}
+
/* API 6.2 setsockopt(), getsockopt()
*
* Applications use setsockopt() and getsockopt() to set or retrieve
@@ -4364,6 +4386,9 @@ static int sctp_setsockopt(struct sock *sk, int level, int optname,
retval = sctp_setsockopt_interleaving_supported(sk, optval,
optlen);
break;
+ case SCTP_REUSE_PORT:
+ retval = sctp_setsockopt_reuse_port(sk, optval, optlen);
+ break;
default:
retval = -ENOPROTOOPT;
break;
@@ -7197,6 +7222,26 @@ static int sctp_getsockopt_interleaving_supported(struct sock *sk, int len,
return retval;
}
+static int sctp_getsockopt_reuse_port(struct sock *sk, int len,
+ char __user *optval,
+ int __user *optlen)
+{
+ int val;
+
+ if (len < sizeof(int))
+ return -EINVAL;
+
+ len = sizeof(int);
+ val = sctp_sk(sk)->reuse;
+ if (put_user(len, optlen))
+ return -EFAULT;
+
+ if (copy_to_user(optval, &val, len))
+ return -EFAULT;
+
+ return 0;
+}
+
static int sctp_getsockopt(struct sock *sk, int level, int optname,
char __user *optval, int __user *optlen)
{
@@ -7392,6 +7437,9 @@ static int sctp_getsockopt(struct sock *sk, int level, int optname,
retval = sctp_getsockopt_interleaving_supported(sk, len, optval,
optlen);
break;
+ case SCTP_REUSE_PORT:
+ retval = sctp_getsockopt_reuse_port(sk, len, optval, optlen);
+ break;
default:
retval = -ENOPROTOOPT;
break;
@@ -7429,6 +7477,7 @@ static struct sctp_bind_bucket *sctp_bucket_create(
static long sctp_get_port_local(struct sock *sk, union sctp_addr *addr)
{
+ bool reuse = (sk->sk_reuse || sctp_sk(sk)->reuse);
struct sctp_bind_hashbucket *head; /* hash list */
struct sctp_bind_bucket *pp;
unsigned short snum;
@@ -7501,13 +7550,11 @@ static long sctp_get_port_local(struct sock *sk, union sctp_addr *addr)
* used by other socket (pp->owner not empty); that other
* socket is going to be sk2.
*/
- int reuse = sk->sk_reuse;
struct sock *sk2;
pr_debug("%s: found a possible match\n", __func__);
- if (pp->fastreuse && sk->sk_reuse &&
- sk->sk_state != SCTP_SS_LISTENING)
+ if (pp->fastreuse && reuse && sk->sk_state != SCTP_SS_LISTENING)
goto success;
/* Run through the list of sockets bound to the port
@@ -7525,7 +7572,7 @@ static long sctp_get_port_local(struct sock *sk, union sctp_addr *addr)
ep2 = sctp_sk(sk2)->ep;
if (sk == sk2 ||
- (reuse && sk2->sk_reuse &&
+ (reuse && (sk2->sk_reuse || sctp_sk(sk2)->reuse) &&
sk2->sk_state != SCTP_SS_LISTENING))
continue;
@@ -7549,12 +7596,12 @@ static long sctp_get_port_local(struct sock *sk, union sctp_addr *addr)
* SO_REUSEADDR on this socket -sk-).
*/
if (hlist_empty(&pp->owner)) {
- if (sk->sk_reuse && sk->sk_state != SCTP_SS_LISTENING)
+ if (reuse && sk->sk_state != SCTP_SS_LISTENING)
pp->fastreuse = 1;
else
pp->fastreuse = 0;
} else if (pp->fastreuse &&
- (!sk->sk_reuse || sk->sk_state == SCTP_SS_LISTENING))
+ (!reuse || sk->sk_state == SCTP_SS_LISTENING))
pp->fastreuse = 0;
/* We are set, so fill up all the data in the hash table
@@ -7685,7 +7732,7 @@ int sctp_inet_listen(struct socket *sock, int backlog)
err = 0;
sctp_unhash_endpoint(ep);
sk->sk_state = SCTP_SS_CLOSED;
- if (sk->sk_reuse)
+ if (sk->sk_reuse || sctp_sk(sk)->reuse)
sctp_sk(sk)->bind_hash->fastreuse = 1;
goto out;
}
@@ -8550,6 +8597,7 @@ void sctp_copy_sock(struct sock *newsk, struct sock *sk,
newsk->sk_no_check_tx = sk->sk_no_check_tx;
newsk->sk_no_check_rx = sk->sk_no_check_rx;
newsk->sk_reuse = sk->sk_reuse;
+ sctp_sk(newsk)->reuse = sp->reuse;
newsk->sk_shutdown = sk->sk_shutdown;
newsk->sk_destruct = sctp_destruct_sock;
--
2.1.0
^ permalink raw reply related
* Re: [PATCH 0/4] docs: e100[0] fix build errors
From: Tobin C. Harding @ 2018-06-25 2:06 UTC (permalink / raw)
To: Kirsher, Jeffrey T
Cc: Randy Dunlap, Jonathan Corbet, David S. Miller,
linux-doc@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <91A1572C-63A6-4420-B01B-A0DD5F84200A@intel.com>
On Mon, Jun 25, 2018 at 01:11:33AM +0000, Kirsher, Jeffrey T wrote:
>
>
> > On Jun 24, 2018, at 16:41, Tobin C. Harding <me@tobin.cc> wrote:
> >
> >> On Fri, Jun 22, 2018 at 01:22:37PM -0700, Randy Dunlap wrote:
> >> Hi Tobin,
> >>
> >>> On 06/21/2018 05:37 PM, Tobin C. Harding wrote:
> >>> Hi Jonathan,
> >>>
> >>> This patch set fixes current docs build failure on Linus' mainline
> >>>
> >>> commit: (ba4dbdedd3ed Merge tag 'jfs-4.18' of git://github.com/kleikamp/linux-shaggy)
> >>>
> >>> (FYI this is 8 commits after Linux 4.18-rc1).
> >>>
> >>> And also same build errors on today's linux-next
> >>>
> >>> 8439c34f07a3 (tag: next-20180621, linux-next/master, linux-next) Add linux-next specific files for 20180621
> >>>
> >>>
> >>> I split the patches in between the two drivers to enable use of the
> >>> 'Fixes:' tag.
> >>>
> >>> Tobin C. Harding (4):
> >>> Documentation: e100: Use correct heading adornment
> >>> Documentation: e1000: Use correct heading adornment
> >>> Documentation: e100: Fix docs build error
> >>> Documentation: e1000: Fix docs build error
> >>>
> >>> Documentation/networking/e100.rst | 112 +++++++++++++++--------------
> >>> Documentation/networking/e1000.rst | 76 ++++++++++----------
> >>> 2 files changed, 96 insertions(+), 92 deletions(-)
> >>
> >> I am still seeing a few warnings (your 4 patches applied to
> >> linux-next-20180622):
> >>
> >> linux-next-20180622/Documentation/networking/e100.rst:57: WARNING: Literal block expected; none found.
> >> linux-next-20180622/Documentation/networking/e100.rst:68: WARNING: Literal block expected; none found.
> >> linux-next-20180622/Documentation/networking/e100.rst:75: WARNING: Literal block expected; none found.
> >> linux-next-20180622/Documentation/networking/e100.rst:84: WARNING: Literal block expected; none found.
> >> linux-next-20180622/Documentation/networking/e100.rst:93: WARNING: Inline emphasis start-string without end-string.
> >> linux-next-20180622/Documentation/networking/e1000.rst:83: ERROR: Unexpected indentation.
> >> linux-next-20180622/Documentation/networking/e1000.rst:84: WARNING: Block quote ends without a blank line; unexpected unindent.
> >> linux-next-20180622/Documentation/networking/e1000.rst:173: WARNING: Definition list ends without a blank line; unexpected unindent.
> >> linux-next-20180622/Documentation/networking/e1000.rst:236: WARNING: Definition list ends without a blank line; unexpected unindent.
> >>
> >>
> >> You didn't get these warnings? or they weren't important?
> >> or "perfect" was not your primary goal? :) [which is fine]
> >>
> >> [I see around 50 similar doc formatting warnings/errors in the entire
> >> Documentation build.]
> >
> > Thanks for testing this Randy. You are right there are a bunch of
> > warnings, I did not think to grep for warnings on these files - sloppy
> > work by me. The series has been applied already but I'll add clearing
> > these warnings to my TODO list.
>
> Thanks, already on it. I have a set of patches that I will push once Dave open’s up his net-next tree.
Oh cool, even better.
thanks,
Tobin.
^ permalink raw reply
* Re: [PATCH 0/4] docs: e100[0] fix build errors
From: Kirsher, Jeffrey T @ 2018-06-25 1:11 UTC (permalink / raw)
To: Tobin C. Harding
Cc: Randy Dunlap, Jonathan Corbet, David S. Miller,
linux-doc@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20180624234135.GE3006@eros>
> On Jun 24, 2018, at 16:41, Tobin C. Harding <me@tobin.cc> wrote:
>
>> On Fri, Jun 22, 2018 at 01:22:37PM -0700, Randy Dunlap wrote:
>> Hi Tobin,
>>
>>> On 06/21/2018 05:37 PM, Tobin C. Harding wrote:
>>> Hi Jonathan,
>>>
>>> This patch set fixes current docs build failure on Linus' mainline
>>>
>>> commit: (ba4dbdedd3ed Merge tag 'jfs-4.18' of git://github.com/kleikamp/linux-shaggy)
>>>
>>> (FYI this is 8 commits after Linux 4.18-rc1).
>>>
>>> And also same build errors on today's linux-next
>>>
>>> 8439c34f07a3 (tag: next-20180621, linux-next/master, linux-next) Add linux-next specific files for 20180621
>>>
>>>
>>> I split the patches in between the two drivers to enable use of the
>>> 'Fixes:' tag.
>>>
>>> Tobin C. Harding (4):
>>> Documentation: e100: Use correct heading adornment
>>> Documentation: e1000: Use correct heading adornment
>>> Documentation: e100: Fix docs build error
>>> Documentation: e1000: Fix docs build error
>>>
>>> Documentation/networking/e100.rst | 112 +++++++++++++++--------------
>>> Documentation/networking/e1000.rst | 76 ++++++++++----------
>>> 2 files changed, 96 insertions(+), 92 deletions(-)
>>
>> I am still seeing a few warnings (your 4 patches applied to
>> linux-next-20180622):
>>
>> linux-next-20180622/Documentation/networking/e100.rst:57: WARNING: Literal block expected; none found.
>> linux-next-20180622/Documentation/networking/e100.rst:68: WARNING: Literal block expected; none found.
>> linux-next-20180622/Documentation/networking/e100.rst:75: WARNING: Literal block expected; none found.
>> linux-next-20180622/Documentation/networking/e100.rst:84: WARNING: Literal block expected; none found.
>> linux-next-20180622/Documentation/networking/e100.rst:93: WARNING: Inline emphasis start-string without end-string.
>> linux-next-20180622/Documentation/networking/e1000.rst:83: ERROR: Unexpected indentation.
>> linux-next-20180622/Documentation/networking/e1000.rst:84: WARNING: Block quote ends without a blank line; unexpected unindent.
>> linux-next-20180622/Documentation/networking/e1000.rst:173: WARNING: Definition list ends without a blank line; unexpected unindent.
>> linux-next-20180622/Documentation/networking/e1000.rst:236: WARNING: Definition list ends without a blank line; unexpected unindent.
>>
>>
>> You didn't get these warnings? or they weren't important?
>> or "perfect" was not your primary goal? :) [which is fine]
>>
>> [I see around 50 similar doc formatting warnings/errors in the entire
>> Documentation build.]
>
> Thanks for testing this Randy. You are right there are a bunch of
> warnings, I did not think to grep for warnings on these files - sloppy
> work by me. The series has been applied already but I'll add clearing
> these warnings to my TODO list.
Thanks, already on it. I have a set of patches that I will push once Dave open’s up his net-next tree.
>
>> Anyway, much better than it was. Thanks.
>>
>> Tested-by: Randy Dunlap <rdunlap@infradead.org>
>
> Thanks again,
> Tobin.
^ permalink raw reply
* Re: [PATCH 0/4] docs: e100[0] fix build errors
From: Tobin C. Harding @ 2018-06-24 23:41 UTC (permalink / raw)
To: Randy Dunlap
Cc: Jonathan Corbet, Jeff Kirsher, David S. Miller, linux-doc, netdev,
linux-kernel
In-Reply-To: <ba768d6c-dd21-3600-5cba-151b5d6185f1@infradead.org>
On Fri, Jun 22, 2018 at 01:22:37PM -0700, Randy Dunlap wrote:
> Hi Tobin,
>
> On 06/21/2018 05:37 PM, Tobin C. Harding wrote:
> > Hi Jonathan,
> >
> > This patch set fixes current docs build failure on Linus' mainline
> >
> > commit: (ba4dbdedd3ed Merge tag 'jfs-4.18' of git://github.com/kleikamp/linux-shaggy)
> >
> > (FYI this is 8 commits after Linux 4.18-rc1).
> >
> > And also same build errors on today's linux-next
> >
> > 8439c34f07a3 (tag: next-20180621, linux-next/master, linux-next) Add linux-next specific files for 20180621
> >
> >
> > I split the patches in between the two drivers to enable use of the
> > 'Fixes:' tag.
> >
> > Tobin C. Harding (4):
> > Documentation: e100: Use correct heading adornment
> > Documentation: e1000: Use correct heading adornment
> > Documentation: e100: Fix docs build error
> > Documentation: e1000: Fix docs build error
> >
> > Documentation/networking/e100.rst | 112 +++++++++++++++--------------
> > Documentation/networking/e1000.rst | 76 ++++++++++----------
> > 2 files changed, 96 insertions(+), 92 deletions(-)
>
> I am still seeing a few warnings (your 4 patches applied to
> linux-next-20180622):
>
> linux-next-20180622/Documentation/networking/e100.rst:57: WARNING: Literal block expected; none found.
> linux-next-20180622/Documentation/networking/e100.rst:68: WARNING: Literal block expected; none found.
> linux-next-20180622/Documentation/networking/e100.rst:75: WARNING: Literal block expected; none found.
> linux-next-20180622/Documentation/networking/e100.rst:84: WARNING: Literal block expected; none found.
> linux-next-20180622/Documentation/networking/e100.rst:93: WARNING: Inline emphasis start-string without end-string.
> linux-next-20180622/Documentation/networking/e1000.rst:83: ERROR: Unexpected indentation.
> linux-next-20180622/Documentation/networking/e1000.rst:84: WARNING: Block quote ends without a blank line; unexpected unindent.
> linux-next-20180622/Documentation/networking/e1000.rst:173: WARNING: Definition list ends without a blank line; unexpected unindent.
> linux-next-20180622/Documentation/networking/e1000.rst:236: WARNING: Definition list ends without a blank line; unexpected unindent.
>
>
> You didn't get these warnings? or they weren't important?
> or "perfect" was not your primary goal? :) [which is fine]
>
> [I see around 50 similar doc formatting warnings/errors in the entire
> Documentation build.]
Thanks for testing this Randy. You are right there are a bunch of
warnings, I did not think to grep for warnings on these files - sloppy
work by me. The series has been applied already but I'll add clearing
these warnings to my TODO list.
> Anyway, much better than it was. Thanks.
>
> Tested-by: Randy Dunlap <rdunlap@infradead.org>
Thanks again,
Tobin.
^ permalink raw reply
* Suspend of SDIO function devices
From: Daniel Mack @ 2018-06-24 20:46 UTC (permalink / raw)
To: Ulf Hansson, Chris Ball
Cc: linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
libertas-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Hi,
I'm currently looking into the suspend callbacks of drivers of hardware
that use an SDIO interface, specifically the libertas_sdio driver:
drivers/net/wireless/marvell/libertas/if_sdio.c
The comments in if_sdio_suspend() suggest that by returning -ENOSYS due
to runtime-dependant circumstances, the MMC core will remove the card
entirely at suspend time. I then searched for the bits that do that and
failed, until I came across this old commit, which first appeared in 3.16:
573185cc7e6 mmc: core: Invoke sdio func driver's PM callbacks from
the sdio bus
Before that commit, the mmc core did in fact invoke the card's
.suspend() callback manually and if it returned a non-zero result, it
would remove the card. Now that the generic pm functions are in place,
this does no longer happen because the host and its clients are
independent entities. Consequently, systems fail to suspend when the
libertas_sdio module is loaded.
The pm notifier code in drivers/mmc/core/core.c does still handle cases
where no pm functions are provided at all (in which case it removes the
card), but it doesn't handle -ENOSYS return values at runtime.
Now I'm wondering how this is supposed to work, and which end needs
fixing. The mmc/sdio core by restoring the old logic from before
573185cc7e6, or the libertas driver.
The platform I'm working on does not retain power for the SDIO slaves,
so a complete re-init is necessary after resume.
Please advise, I'm happy to test approaches and send patches.
Thanks,
Daniel
^ permalink raw reply
* [PATCH net-next] tls: Removed unused variable
From: Vakul Garg @ 2018-06-24 20:07 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, borisp, aviadye, davejwatson, Vakul Garg
Removed unused variable 'rxm' from tls_queue().
Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
---
net/tls/tls_sw.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index f127fac88acf..727433b37bb5 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -990,9 +990,6 @@ static void tls_queue(struct strparser *strp, struct sk_buff *skb)
{
struct tls_context *tls_ctx = tls_get_ctx(strp->sk);
struct tls_sw_context_rx *ctx = tls_sw_ctx_rx(tls_ctx);
- struct strp_msg *rxm;
-
- rxm = strp_msg(skb);
ctx->decrypted = false;
--
2.13.6
^ permalink raw reply related
* Re: [PATCH rdma-next 06/12] RDMA/uverbs: Don't overwrite NULL pointer with ZERO_SIZE_PTR
From: Jason Gunthorpe @ 2018-06-24 19:57 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, Leon Romanovsky, RDMA mailing list, Hadar Hen Zion,
Matan Barak, Michael J Ruhl, Noa Osherovich, Raed Salem,
Yishai Hadas, Saeed Mahameed, linux-netdev
In-Reply-To: <20180624082353.16138-7-leon@kernel.org>
On Sun, Jun 24, 2018 at 11:23:47AM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@mellanox.com>
>
> Number of specs is provided by user and in valid case can be equal to zero.
> Such argument causes to call to kcalloc() with zero-length request and in
> return the ZERO_SIZE_PTR is assigned. This pointer is different from NULL
> and makes various if (..) checks to success.
The one seems really weird. There is nothing wrong with ZERO_SIZE_PTR,
but this description and fix suggest that something did
ptr = kalloc(0);
ptr[0] = ...;
Which is not allowed of course. Doesn't this mean there is also a
missing range check someplace?
Jason
^ permalink raw reply
* Re: [PATCH rdma-next 09/12] RDMA/mlx5: Fix shift overflow in mlx5_ib_create_wq
From: Jason Gunthorpe @ 2018-06-24 19:56 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, Leon Romanovsky, RDMA mailing list, Hadar Hen Zion,
Matan Barak, Michael J Ruhl, Noa Osherovich, Raed Salem,
Yishai Hadas, Saeed Mahameed, linux-netdev
In-Reply-To: <20180624082353.16138-10-leon@kernel.org>
On Sun, Jun 24, 2018 at 11:23:50AM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@mellanox.com>
>
> [ 61.182439] UBSAN: Undefined behaviour in drivers/infiniband/hw/mlx5/qp.c:5366:34
> [ 61.183673] shift exponent 4294967288 is too large for 32-bit type 'unsigned int'
> [ 61.185530] CPU: 0 PID: 639 Comm: qp Not tainted 4.18.0-rc1-00037-g4aa1d69a9c60-dirty #96
> [ 61.186981] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014
> [ 61.188315] Call Trace:
> [ 61.188661] dump_stack+0xc7/0x13b
> [ 61.190427] ubsan_epilogue+0x9/0x49
> [ 61.190899] __ubsan_handle_shift_out_of_bounds+0x1ea/0x22f
> [ 61.197040] mlx5_ib_create_wq+0x1c99/0x1d50
> [ 61.206632] ib_uverbs_ex_create_wq+0x499/0x820
> [ 61.213892] ib_uverbs_write+0x77e/0xae0
> [ 61.248018] vfs_write+0x121/0x3b0
> [ 61.249831] ksys_write+0xa1/0x120
> [ 61.254024] do_syscall_64+0x7c/0x2a0
> [ 61.256178] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [ 61.259211] RIP: 0033:0x7f54bab70e99
> [ 61.262125] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89
> [ 61.268678] RSP: 002b:00007ffe1541c318 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
> [ 61.271076] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f54bab70e99
> [ 61.273795] RDX: 0000000000000070 RSI: 0000000020000240 RDI: 0000000000000003
> [ 61.276982] RBP: 00007ffe1541c330 R08: 00000000200078e0 R09: 0000000000000002
> [ 61.280035] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004005c0
> [ 61.283279] R13: 00007ffe1541c420 R14: 0000000000000000 R15: 0000000000000000
>
> Cc: <stable@vger.kernel.org> # 4.7
> Fixes: 79b20a6c3014 ("IB/mlx5: Add receive Work Queue verbs")
> Cc: syzkaller <syzkaller@googlegroups.com>
> Reported-by: Noa Osherovich <noaos@mellanox.com>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> drivers/infiniband/hw/mlx5/qp.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/hw/mlx5/qp.c b/drivers/infiniband/hw/mlx5/qp.c
> index 6034a670859f..8e40263fd40e 100644
> +++ b/drivers/infiniband/hw/mlx5/qp.c
> @@ -5377,7 +5377,11 @@ static int set_user_rq_size(struct mlx5_ib_dev *dev,
>
> rwq->wqe_count = ucmd->rq_wqe_count;
> rwq->wqe_shift = ucmd->rq_wqe_shift;
> - rwq->buf_size = (rwq->wqe_count << rwq->wqe_shift);
> + rwq->buf_size =
> + shift_overflow((size_t)rwq->wqe_count, (size_t)rwq->wqe_shift);
The casts are redundant, the function argument is already size_t so
implicit promotion is guaranteed.
Jason
^ permalink raw reply
* Re: [V2] brcmfmac: stop watchdog before detach and free everything
From: Kalle Valo @ 2018-06-24 16:58 UTC (permalink / raw)
To: Michael Trimarchi
Cc: Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, David S. Miller, Pieter-Paul Giesberts, Ian Molton,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
netdev, linux-kernel
In-Reply-To: <20180530090633.GA15390@panicking>
Michael Trimarchi <michael@amarulasolutions.com> wrote:
> Using built-in in kernel image without a firmware in filesystem
> or in the kernel image can lead to a kernel NULL pointer deference.
> Watchdog need to be stopped in brcmf_sdio_remove
>
> The system is going down NOW!
> [ 1348.110759] Unable to handle kernel NULL pointer dereference at virtual address 000002f8
> Sent SIGTERM to all processes
> [ 1348.121412] Mem abort info:
> [ 1348.126962] ESR = 0x96000004
> [ 1348.130023] Exception class = DABT (current EL), IL = 32 bits
> [ 1348.135948] SET = 0, FnV = 0
> [ 1348.138997] EA = 0, S1PTW = 0
> [ 1348.142154] Data abort info:
> [ 1348.145045] ISV = 0, ISS = 0x00000004
> [ 1348.148884] CM = 0, WnR = 0
> [ 1348.151861] user pgtable: 4k pages, 48-bit VAs, pgdp = (____ptrval____)
> [ 1348.158475] [00000000000002f8] pgd=0000000000000000
> [ 1348.163364] Internal error: Oops: 96000004 [#1] PREEMPT SMP
> [ 1348.168927] Modules linked in: ipv6
> [ 1348.172421] CPU: 3 PID: 1421 Comm: brcmf_wdog/mmc0 Not tainted 4.17.0-rc5-next-20180517 #18
> [ 1348.180757] Hardware name: Amarula A64-Relic (DT)
> [ 1348.185455] pstate: 60000005 (nZCv daif -PAN -UAO)
> [ 1348.190251] pc : brcmf_sdiod_freezer_count+0x0/0x20
> [ 1348.195124] lr : brcmf_sdio_watchdog_thread+0x64/0x290
> [ 1348.200253] sp : ffff00000b85be30
> [ 1348.203561] x29: ffff00000b85be30 x28: 0000000000000000
> [ 1348.208868] x27: ffff00000b6cb918 x26: ffff80003b990638
> [ 1348.214176] x25: ffff0000087b1a20 x24: ffff80003b94f800
> [ 1348.219483] x23: ffff000008e620c8 x22: ffff000008f0b660
> [ 1348.224790] x21: ffff000008c6a858 x20: 00000000fffffe00
> [ 1348.230097] x19: ffff80003b94f800 x18: 0000000000000001
> [ 1348.235404] x17: 0000ffffab2e8a74 x16: ffff0000080d7de8
> [ 1348.240711] x15: 0000000000000000 x14: 0000000000000400
> [ 1348.246018] x13: 0000000000000400 x12: 0000000000000001
> [ 1348.251324] x11: 00000000000002c4 x10: 0000000000000a10
> [ 1348.256631] x9 : ffff00000b85bc40 x8 : ffff80003be11870
> [ 1348.261937] x7 : ffff80003dfc7308 x6 : 000000078ff08b55
> [ 1348.267243] x5 : 00000139e1058400 x4 : 0000000000000000
> [ 1348.272550] x3 : dead000000000100 x2 : 958f2788d6618100
> [ 1348.277856] x1 : 00000000fffffe00 x0 : 0000000000000000
>
> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Tested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Patch applied to wireless-drivers.git, thanks.
373c83a801f1 brcmfmac: stop watchdog before detach and free everything
--
https://patchwork.kernel.org/patch/10437931/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH net-next 3/3] r8169: don't check WoL when powering down PHY and interface is down
From: Heiner Kallweit @ 2018-06-24 16:40 UTC (permalink / raw)
To: Realtek linux nic maintainers, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <f8a65bb4-aed5-7264-1e1c-b8c76ee79717@gmail.com>
We can power down the PHY irregardless of WOL settings if interface
is down. So far we would have left the PHY enabled if WOL options
are set and the interface is brought down.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/r8169.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index f8a1309a..1d33672c 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4635,7 +4635,7 @@ static void rtl_wol_suspend_quirk(struct rtl8169_private *tp)
static bool rtl_wol_pll_power_down(struct rtl8169_private *tp)
{
- if (!tp->saved_wolopts)
+ if (!netif_running(tp->dev) || !tp->saved_wolopts)
return false;
rtl_speed_down(tp);
--
2.18.0
^ permalink raw reply related
* [PATCH net-next 2/3] r8169: improve saved_wolopts handling
From: Heiner Kallweit @ 2018-06-24 16:39 UTC (permalink / raw)
To: Realtek linux nic maintainers, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <f8a65bb4-aed5-7264-1e1c-b8c76ee79717@gmail.com>
Let's make saved_wolopts a shadow copy of the WoL options. This allows
to simplify the code and get rid of calls to now unneeded function
__rtl8169_get_wol(). However don't remove __rtl8169_get_wol()
completely to be prepared for the case that we can respect BIOS WOL
settings again.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/r8169.c | 34 ++++++++++++----------------
1 file changed, 14 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 480fb141..f8a1309a 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -1587,6 +1587,12 @@ static void rtl8169_check_link_status(struct net_device *dev,
#define WAKE_ANY (WAKE_PHY | WAKE_MAGIC | WAKE_UCAST | WAKE_BCAST | WAKE_MCAST)
+/* Currently we only enable WoL if explicitly told by userspace to circumvent
+ * issues on certain platforms, see commit bde135a672bf ("r8169: only enable
+ * PCI wakeups when WOL is active"). Let's keep __rtl8169_get_wol() for the
+ * case that we want to respect BIOS settings again.
+ */
+#if 0
static u32 __rtl8169_get_wol(struct rtl8169_private *tp)
{
u8 options;
@@ -1621,25 +1627,16 @@ static u32 __rtl8169_get_wol(struct rtl8169_private *tp)
return wolopts;
}
+#endif
static void rtl8169_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
{
struct rtl8169_private *tp = netdev_priv(dev);
- struct device *d = tp_to_dev(tp);
-
- pm_runtime_get_noresume(d);
rtl_lock_work(tp);
-
wol->supported = WAKE_ANY;
- if (pm_runtime_active(d))
- wol->wolopts = __rtl8169_get_wol(tp);
- else
- wol->wolopts = tp->saved_wolopts;
-
+ wol->wolopts = tp->saved_wolopts;
rtl_unlock_work(tp);
-
- pm_runtime_put_noidle(d);
}
static void __rtl8169_set_wol(struct rtl8169_private *tp, u32 wolopts)
@@ -1719,14 +1716,14 @@ static int rtl8169_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
rtl_lock_work(tp);
+ tp->saved_wolopts = wol->wolopts & WAKE_ANY;
+
if (pm_runtime_active(d))
- __rtl8169_set_wol(tp, wol->wolopts);
- else
- tp->saved_wolopts = wol->wolopts;
+ __rtl8169_set_wol(tp, tp->saved_wolopts);
rtl_unlock_work(tp);
- device_set_wakeup_enable(d, wol->wolopts);
+ device_set_wakeup_enable(d, tp->saved_wolopts);
pm_runtime_put_noidle(d);
@@ -4638,7 +4635,7 @@ static void rtl_wol_suspend_quirk(struct rtl8169_private *tp)
static bool rtl_wol_pll_power_down(struct rtl8169_private *tp)
{
- if (!(__rtl8169_get_wol(tp) & WAKE_ANY))
+ if (!tp->saved_wolopts)
return false;
rtl_speed_down(tp);
@@ -7219,7 +7216,6 @@ static int rtl_open(struct net_device *dev)
rtl_unlock_work(tp);
- tp->saved_wolopts = 0;
pm_runtime_put_sync(&pdev->dev);
rtl8169_check_link_status(dev, tp);
@@ -7367,7 +7363,6 @@ static int rtl8169_runtime_suspend(struct device *device)
}
rtl_lock_work(tp);
- tp->saved_wolopts = __rtl8169_get_wol(tp);
__rtl8169_set_wol(tp, WAKE_ANY);
rtl_unlock_work(tp);
@@ -7392,7 +7387,6 @@ static int rtl8169_runtime_resume(struct device *device)
rtl_lock_work(tp);
__rtl8169_set_wol(tp, tp->saved_wolopts);
- tp->saved_wolopts = 0;
rtl_unlock_work(tp);
__rtl8169_resume(dev);
@@ -7462,7 +7456,7 @@ static void rtl_shutdown(struct pci_dev *pdev)
rtl8169_hw_reset(tp);
if (system_state == SYSTEM_POWER_OFF) {
- if (__rtl8169_get_wol(tp) & WAKE_ANY) {
+ if (tp->saved_wolopts) {
rtl_wol_suspend_quirk(tp);
rtl_wol_shutdown_quirk(tp);
}
--
2.18.0
^ permalink raw reply related
* [PATCH net-next 1/3] r8169: improve phy initialization when resuming
From: Heiner Kallweit @ 2018-06-24 16:37 UTC (permalink / raw)
To: Realtek linux nic maintainers, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <f8a65bb4-aed5-7264-1e1c-b8c76ee79717@gmail.com>
Let's move calling rtl8169_init_phy() to __rtl8169_resume().
It simplifies the code and avoids rtl8169_init_phy() being called
when resuming whilst interface is down. rtl_open() will initialize
the PHY when the interface is brought up.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/r8169.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 44715958..480fb141 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -7334,6 +7334,7 @@ static void __rtl8169_resume(struct net_device *dev)
netif_device_attach(dev);
rtl_pll_power_up(tp);
+ rtl8169_init_phy(dev, tp);
rtl_lock_work(tp);
napi_enable(&tp->napi);
@@ -7347,9 +7348,6 @@ static int rtl8169_resume(struct device *device)
{
struct pci_dev *pdev = to_pci_dev(device);
struct net_device *dev = pci_get_drvdata(pdev);
- struct rtl8169_private *tp = netdev_priv(dev);
-
- rtl8169_init_phy(dev, tp);
if (netif_running(dev))
__rtl8169_resume(dev);
@@ -7397,8 +7395,6 @@ static int rtl8169_runtime_resume(struct device *device)
tp->saved_wolopts = 0;
rtl_unlock_work(tp);
- rtl8169_init_phy(dev, tp);
-
__rtl8169_resume(dev);
return 0;
--
2.18.0
^ permalink raw reply related
* [PATCH net-next 0/3] r8169: improve PHY initialization and WoL handling
From: Heiner Kallweit @ 2018-06-24 16:35 UTC (permalink / raw)
To: Realtek linux nic maintainers, David Miller; +Cc: netdev@vger.kernel.org
Series with smaller improvements regarding PHY initialization and
WoL handling.
Heiner Kallweit (3):
r8169: improve phy inititalization when resuming
r8169: improve saved_wolopts handling
r8169: don't check WoL when powering down PHY and interface is down
drivers/net/ethernet/realtek/r8169.c | 40 +++++++++++-----------------
1 file changed, 15 insertions(+), 25 deletions(-)
--
2.18.0
^ permalink raw reply
* Re: [RFC] net: Add new LoRaWAN subsystem
From: Andreas Färber @ 2018-06-24 15:49 UTC (permalink / raw)
To: Jian-Hong Pan
Cc: Marcel Holtmann, David S. Miller, Alexander Aring, Stefan Schmidt,
linux-wpan - ML, netdev, linux-kernel
In-Reply-To: <CAC=mGzj-GNQ0Xz3PodDHyypNtFsOEfBdNBnNkysW2ZZ8Wwuijg@mail.gmail.com>
Hi Jian-Hong Pan,
Am 13.05.2018 um 04:42 schrieb Jian-Hong Pan:
> Hi Jiri and Marcel,
>
> 2018-05-11 23:39 GMT+08:00 Marcel Holtmann <marcel@holtmann.org>:
>> Hi Jian-Hong,
>>
>>> A Low-Power Wide-Area Network (LPWAN) is a type of wireless
>>> telecommunication wide area network designed to allow long range
>>> communications at a low bit rate among things (connected objects), such
>>> as sensors operated on a battery. It can be used widely in IoT area.
>>> LoRaWAN, which is one kind of implementation of LPWAN, is a medium
>>> access control (MAC) layer protocol for managing communication between
>>> LPWAN gateways and end-node devices, maintained by the LoRa Alliance.
>>> LoRaWAN™ Specification could be downloaded at:
>>> https://lora-alliance.org/lorawan-for-developers
>>>
>>> However, LoRaWAN is not implemented in Linux kernel right now, so I am
>>> trying to develop it. Here is my repository:
>>> https://github.com/starnight/LoRa/tree/lorawan-ndo/LoRaWAN
>>>
>>> Because it is a kind of network, the ideal usage in an user space
>>> program should be like "socket(PF_LORAWAN, SOCK_DGRAM, 0)" and with
>>> other socket APIs. Therefore, the definitions like AF_LORAWAN,
>>> PF_LORAWAN ..., must be listed in the header files of glibc.
>>> For the driver in kernel space, the definitions also must be listed in
>>> the corresponding Linux socket header files.
>>> Especially, both are for the testing programs.
>>>
>>> Back to the mentioned "LoRaWAN is not implemented in Linux kernel now".
>>> Could or should we add the definitions into corresponding kernel header
>>> files now, if LoRaWAN will be accepted as a subsystem in Linux?
>>
>> when you submit your LoRaWAN subsystem to netdev for review, include a patch that adds these new address family definitions. Just pick the next one available. There will be no pre-allocation of numbers until your work has been accepted upstream. Meaning, that the number might change if other address families get merged before yours. So you have to keep updating. glibc will eventually follow the number assigned by the kernel.
>
> Thanks for your guidance. I will follow the steps.
I have been working on a similar thing on and off since proposing it at
FOSDEM 2017:
At https://github.com/afaerber/lora-modules you will find my proof of
concept of PF_LORA with SOCK_DGRAM and stub drivers for various modules.
My idea was to layer LoRaWAN on top of LoRa later.
The way I have developed this was to simply reuse numbers unused in our
distro kernel and built my modules against the distro kernel, to avoid
frequent reboots and full kernel builds.
Not having looked at your code yet, do you think our implementations are
fairly independent at this point, or do you see conflicts apart from
number allocation? Like, I am currently using lora0 as name - are you
planning to use lorawan0 or rather something more generic like lpwan0?
We might place your code in net/lora/lorawan/ and mine in net/lora/?
More problematic would be the actual device drivers, where some devices
would support both modes - some with soft MAC, others with full MAC. Do
you have any ideas how to handle that in a sane way?
Please keep me CC'ed on any follow-ups.
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v2 net-next] net/sched: add skbprio scheduler
From: Jamal Hadi Salim @ 2018-06-24 15:43 UTC (permalink / raw)
To: Nishanth Devarajan, xiyou.wangcong, jiri, davem
Cc: netdev, doucette, michel, alexander.duyck
In-Reply-To: <20180623204745.GA4337@gmail.com>
On 23/06/18 04:47 PM, Nishanth Devarajan wrote:
[..]
> + /* Drop the packet at the tail of the lowest priority qdisc. */
> + lp_qdisc = &q->qdiscs[lp];
> + to_drop = __skb_dequeue_tail(lp_qdisc);
> + BUG_ON(!to_drop);
> + qdisc_qstats_backlog_dec(sch, to_drop);
> + qdisc_drop(to_drop, sch, to_free);
> +
Maybe also increase overlimit stat here? It will keep track
of low prio things dropped because you were congested.
Such a stat helps when debugging or collecting analytics.
Per Alex's comment, how about:
-----------
Skbprio (SKB Priority Queue) is a queueing discipline that
prioritizes packets according to their skb->priority field.
Under congestion, already-enqueued lower priority packets
will be dropped to make space available for higher priority
packets. Skbprio was conceived as a solution for
denial-of-service defenses that need to route packets with
different priorities as a means to overcome DoS attacks
as described in paper xxxx...
cheers,
jamal
^ permalink raw reply
* [PATCH RFT] net: dsa: Allow configuring CPU port VLANs
From: Florian Fainelli @ 2018-06-24 15:33 UTC (permalink / raw)
To: netdev
Cc: petrm, jiri, ilias.apalodimas, Florian Fainelli, Andrew Lunn,
Vivien Didelot, David S. Miller, open list
Up until now there was no way to specifically target the VLAN attributes and
membership of the CPU port of a DSA switch. This forced drivers to either
always have the CPU port be "VLAN tagged" (b53) in every VLAN that gets added
to the front-panel/user facing ports, or when the switch supports it, use an
"unmodified" semantic (mv88e6xxx).
This is less than ideal because there are cases where we might not even want to
have the CPU port be part of the same VLAN than its user facing ports, e.g: to
isolate a group of noisy stations. There are also cases where we want to
control exactly how the CPU port receives VLAN traffic such that proper
separation/identification can occur.
Make this possible by flagging events targeting an orig_dev which is a bridge
master and using that as a hint to mean that we want to configure the
CPU/management port. This is compatible with multiple bridges over the same
switch in that, an user still has the responsibility to create separate
broadcast domains with separate VLAN databases/IDs per bridge.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Andrew, Vivien,
Could you test this on mv88e6xxx to make sure there is no regression? Thanks
net/dsa/port.c | 4 ++--
net/dsa/switch.c | 5 ++++-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/dsa/port.c b/net/dsa/port.c
index ed0595459df1..37385e491117 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -253,7 +253,7 @@ int dsa_port_vlan_add(struct dsa_port *dp,
};
if (netif_is_bridge_master(vlan->obj.orig_dev))
- return -EOPNOTSUPP;
+ info.port = dp->cpu_dp->index;
if (br_vlan_enabled(dp->bridge_dev))
return dsa_port_notify(dp, DSA_NOTIFIER_VLAN_ADD, &info);
@@ -271,7 +271,7 @@ int dsa_port_vlan_del(struct dsa_port *dp,
};
if (netif_is_bridge_master(vlan->obj.orig_dev))
- return -EOPNOTSUPP;
+ info.port = dp->cpu_dp->index;
if (br_vlan_enabled(dp->bridge_dev))
return dsa_port_notify(dp, DSA_NOTIFIER_VLAN_DEL, &info);
diff --git a/net/dsa/switch.c b/net/dsa/switch.c
index b93511726069..d69bcc8f9ba2 100644
--- a/net/dsa/switch.c
+++ b/net/dsa/switch.c
@@ -211,8 +211,11 @@ static int dsa_switch_vlan_add(struct dsa_switch *ds,
bitmap_zero(members, ds->num_ports);
if (ds->index == info->sw_index)
set_bit(info->port, members);
+ /* CPU port is configured via dsa_port_vlan_add() with events
+ * targeting the bridge device
+ */
for (port = 0; port < ds->num_ports; port++)
- if (dsa_is_cpu_port(ds, port) || dsa_is_dsa_port(ds, port))
+ if (dsa_is_dsa_port(ds, port))
set_bit(port, members);
if (switchdev_trans_ph_prepare(trans))
--
2.14.1
^ permalink raw reply related
* Wohltätigkeitsspende in Höhe von € 2.000.000,00 EUR
From: jcsilva @ 2018-06-24 9:41 UTC (permalink / raw)
To: Recipients
Lieber Freund,
Ich bin Herr Richard Wahl der Mega-Gewinner von $ 533M In Mega Millions Jackpot spende ich an 5 zufällige Personen, wenn Sie diese E-Mail erhalten, dann wurde Ihre E-Mail nach einem Spinball ausgewählt. Ich habe den größten Teil meines Vermögens auf eine Reihe von Wohltätigkeitsorganisationen und Organisationen verteilt. Ich habe mich freiwillig dazu entschieden, Ihnen den Betrag von € 2.000.000,00 EUR zu spenden eine der ausgewählten 5, um meine Gewinne zu überprüfen, finden Sie auf meiner You Tube Seite unten.
UHR MICH HIER: https://www.youtube.com/watch?v=NejIUDafu3U
Das ist dein Spendencode: [DF00430342018]
Antworten Sie mit dem Spendencode auf diese E-Mail: richardwahldonations@housemail.com
Ich hoffe, Sie und Ihre Familie glücklich zu machen.
Grüße
Herr Richard Wahl
^ permalink raw reply
* Re: [PATCH net-next] tls: Removed unused variable
From: David Miller @ 2018-06-24 14:54 UTC (permalink / raw)
To: vakul.garg; +Cc: netdev, linux-kernel, borisp, aviadye, davejwatson
In-Reply-To: <20180624200750.26192-1-vakul.garg@nxp.com>
From: Vakul Garg <vakul.garg@nxp.com>
Date: Mon, 25 Jun 2018 01:37:50 +0530
> Removed unused variable 'rxm' from tls_queue().
>
> Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
Applied.
^ permalink raw reply
* Re: [PATCH] sfc: make function efx_rps_hash_bucket static
From: David Miller @ 2018-06-24 14:08 UTC (permalink / raw)
To: colin.king
Cc: linux-net-drivers, ecree, bkenward, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20180624105731.5167-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Sun, 24 Jun 2018 11:57:31 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> The function efx_rps_hash_bucket is local to the source and
> does not need to be in global scope, so make it static.
>
> Cleans up sparse warning:
> symbol 'efx_rps_hash_bucket' was not declared. Should it be static?
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* [PATCH net-next] tcp: add SNMP counter for zero-window drops
From: Yafang Shao @ 2018-06-24 14:02 UTC (permalink / raw)
To: davem; +Cc: netdev, Yafang Shao
It will be helpful if we could display the drops due to zero window or no
enough window space.
So a new SNMP MIB entry is added to track this behavior.
This entry is named LINUX_MIB_TCPZEROWINDOWDROP and published in
/proc/net/netstat in TcpExt line as TCPZeroWindowDrop.
Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
---
include/uapi/linux/snmp.h | 1 +
net/ipv4/proc.c | 1 +
net/ipv4/tcp_input.c | 8 ++++++--
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/snmp.h b/include/uapi/linux/snmp.h
index 750d891..97517f3 100644
--- a/include/uapi/linux/snmp.h
+++ b/include/uapi/linux/snmp.h
@@ -279,6 +279,7 @@ enum
LINUX_MIB_TCPDELIVERED, /* TCPDelivered */
LINUX_MIB_TCPDELIVEREDCE, /* TCPDeliveredCE */
LINUX_MIB_TCPACKCOMPRESSED, /* TCPAckCompressed */
+ LINUX_MIB_TCPZEROWINDOWDROP, /* TCPZeroWindowDrop */
__LINUX_MIB_MAX
};
diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
index 77350c1..225ef34 100644
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -287,6 +287,7 @@ static int sockstat_seq_show(struct seq_file *seq, void *v)
SNMP_MIB_ITEM("TCPDelivered", LINUX_MIB_TCPDELIVERED),
SNMP_MIB_ITEM("TCPDeliveredCE", LINUX_MIB_TCPDELIVEREDCE),
SNMP_MIB_ITEM("TCPAckCompressed", LINUX_MIB_TCPACKCOMPRESSED),
+ SNMP_MIB_ITEM("TCPZeroWindowDrop", LINUX_MIB_TCPZEROWINDOWDROP),
SNMP_MIB_SENTINEL
};
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 76ca88f..9c5b341 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4668,8 +4668,10 @@ static void tcp_data_queue(struct sock *sk, struct sk_buff *skb)
* Out of sequence packets to the out_of_order_queue.
*/
if (TCP_SKB_CB(skb)->seq == tp->rcv_nxt) {
- if (tcp_receive_window(tp) == 0)
+ if (tcp_receive_window(tp) == 0) {
+ NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPZEROWINDOWDROP);
goto out_of_window;
+ }
/* Ok. In sequence. In window. */
queue_and_out:
@@ -4735,8 +4737,10 @@ static void tcp_data_queue(struct sock *sk, struct sk_buff *skb)
/* If window is closed, drop tail of packet. But after
* remembering D-SACK for its head made in previous line.
*/
- if (!tcp_receive_window(tp))
+ if (!tcp_receive_window(tp)) {
+ NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPZEROWINDOWDROP);
goto out_of_window;
+ }
goto queue_and_out;
}
--
1.8.3.1
^ permalink raw reply related
* Re: Route fallback issue
From: Erik Auerswald @ 2018-06-24 13:45 UTC (permalink / raw)
To: Julian Anastasov
Cc: Grant Taylor, Akshat Kakkar, netdev, cronolog+lartc, lartc
In-Reply-To: <alpine.LFD.2.20.1806212218070.2159@ja.home.ssi.bg>
Hello Julien,
On Thu, Jun 21, 2018 at 10:57:14PM +0300, Julian Anastasov wrote:
> On Wed, 20 Jun 2018, Grant Taylor wrote:
> > On 06/20/2018 01:00 PM, Julian Anastasov wrote:
> > > You can also try alternative routes.
> >
> > "Alternative routes"? I can't say as I've heard that description as a
> > specific technique / feature / capability before.
> >
> > Is that it's official name?
>
> I think so
>
> > Where can I find out more about it?
>
> You can search on net. I have some old docs on
> these issues, they should be actual:
>
> http://ja.ssi.bg/dgd-usage.txt
Thanks for that info!
Can you tell us what parts from the above text is actually implemented
in the upstream Linux kernel, and starting with which version(s)
(approximately)? The text describes ideas and patches from nearly two
decades ago, is more recent documentation available somewhere?
Thanks,
Erik
--
In the beginning, there was static routing.
-- RFC 1118
^ permalink raw reply
* [PATCH net] strparser: Corrected typo in documentation.
From: Vakul Garg @ 2018-06-24 12:44 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, linux-doc, corbet, Vakul Garg
Replaced strp_pause() with strp_unpause() to correct a seemingly copy
paste documentation mistake.
Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
---
Resending for 'net' as advised.
Documentation/networking/strparser.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/networking/strparser.txt b/Documentation/networking/strparser.txt
index 13081b3decef..a7d354ddda7b 100644
--- a/Documentation/networking/strparser.txt
+++ b/Documentation/networking/strparser.txt
@@ -48,7 +48,7 @@ void strp_pause(struct strparser *strp)
Temporarily pause a stream parser. Message parsing is suspended
and no new messages are delivered to the upper layer.
-void strp_pause(struct strparser *strp)
+void strp_unpause(struct strparser *strp)
Unpause a paused stream parser.
--
2.13.6
^ permalink raw reply related
* [PATCH net-next] strparser: Corrected typo in documentation.
From: Vakul Garg @ 2018-06-24 12:37 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, linux-doc, corbet, Vakul Garg
Replaced strp_pause() with strp_unpause() to correct a seemingly copy
paste documentation mistake.
Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
---
Documentation/networking/strparser.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/networking/strparser.txt b/Documentation/networking/strparser.txt
index 13081b3decef..a7d354ddda7b 100644
--- a/Documentation/networking/strparser.txt
+++ b/Documentation/networking/strparser.txt
@@ -48,7 +48,7 @@ void strp_pause(struct strparser *strp)
Temporarily pause a stream parser. Message parsing is suspended
and no new messages are delivered to the upper layer.
-void strp_pause(struct strparser *strp)
+void strp_unpause(struct strparser *strp)
Unpause a paused stream parser.
--
2.13.6
^ permalink raw reply related
* [PATCH] sfc: make function efx_rps_hash_bucket static
From: Colin King @ 2018-06-24 10:57 UTC (permalink / raw)
To: Solarflare linux maintainers, Edward Cree, Bert Kenward,
David S . Miller, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The function efx_rps_hash_bucket is local to the source and
does not need to be in global scope, so make it static.
Cleans up sparse warning:
symbol 'efx_rps_hash_bucket' was not declared. Should it be static?
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/sfc/efx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/sfc/efx.c b/drivers/net/ethernet/sfc/efx.c
index ad4a354ce570..570ec72266f3 100644
--- a/drivers/net/ethernet/sfc/efx.c
+++ b/drivers/net/ethernet/sfc/efx.c
@@ -3180,6 +3180,7 @@ bool efx_rps_check_rule(struct efx_arfs_rule *rule, unsigned int filter_idx,
return true;
}
+static
struct hlist_head *efx_rps_hash_bucket(struct efx_nic *efx,
const struct efx_filter_spec *spec)
{
--
2.17.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox