* [PATCH] Bluetooth: hidp: might sleep error in hidp_session_thread
From: Jeffy Chen @ 2017-01-20 13:52 UTC (permalink / raw)
To: linux-bluetooth
Cc: Brian Norris, Douglas Anderson, Jeffy Chen, Johan Hedberg, netdev,
linux-kernel, David S. Miller, Marcel Holtmann, Gustavo Padovan
[ 39.044329] do not call blocking ops when !TASK_RUNNING; state=1 set
at [<ffffffbffc290358>] hidp_session_thread+0x110/0x568 [hidp]
...
[ 40.159664] Call trace:
[ 40.162122] [<ffffffc00024ae08>] __might_sleep+0x64/0x90
[ 40.167443] [<ffffffc00080568c>] lock_sock_nested+0x30/0x78
[ 40.173047] [<ffffffbffc1b3ca0>] l2cap_sock_sendmsg+0x90/0xf0
[bluetooth]
[ 40.179842] [<ffffffc0008012c4>] sock_sendmsg+0x4c/0x68
[ 40.185072] [<ffffffc000801414>] kernel_sendmsg+0x54/0x68
[ 40.190477] [<ffffffbffc28f4d0>] hidp_send_frame+0x78/0xa0 [hidp]
[ 40.196574] [<ffffffbffc28f53c>] hidp_process_transmit+0x44/0x98
[hidp]
[ 40.203191] [<ffffffbffc2905ac>] hidp_session_thread+0x364/0x568
[hidp]
Following (https://lwn.net/Articles/628628/).
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
---
net/bluetooth/hidp/core.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
index 0bec458..bfd3fb8 100644
--- a/net/bluetooth/hidp/core.c
+++ b/net/bluetooth/hidp/core.c
@@ -1180,7 +1180,9 @@ static void hidp_session_run(struct hidp_session *session)
struct sock *ctrl_sk = session->ctrl_sock->sk;
struct sock *intr_sk = session->intr_sock->sk;
struct sk_buff *skb;
+ DEFINE_WAIT_FUNC(wait, woken_wake_function);
+ add_wait_queue(sk_sleep(intr_sk), &wait);
for (;;) {
/*
* This thread can be woken up two ways:
@@ -1188,12 +1190,10 @@ static void hidp_session_run(struct hidp_session *session)
* session->terminate flag and wakes this thread up.
* - Via modifying the socket state of ctrl/intr_sock. This
* thread is woken up by ->sk_state_changed().
- *
- * Note: set_current_state() performs any necessary
- * memory-barriers for us.
*/
- set_current_state(TASK_INTERRUPTIBLE);
+ /* Ensure session->terminate is updated */
+ smp_mb__before_atomic();
if (atomic_read(&session->terminate))
break;
@@ -1227,11 +1227,14 @@ static void hidp_session_run(struct hidp_session *session)
hidp_process_transmit(session, &session->ctrl_transmit,
session->ctrl_sock);
- schedule();
+ wait_woken(&wait, TASK_INTERRUPTIBLE, MAX_SCHEDULE_TIMEOUT);
}
+ remove_wait_queue(sk_sleep(intr_sk), &wait);
atomic_inc(&session->terminate);
- set_current_state(TASK_RUNNING);
+
+ /* Ensure session->terminate is updated */
+ smp_mb__after_atomic();
}
/*
--
2.1.4
^ permalink raw reply related
* [PATCH net-next] gre6: Clean up unused struct ipv6_tel_txoption definition
From: Jakub Sitnicki @ 2017-01-20 13:53 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Commit b05229f44228 ("gre6: Cleanup GREv6 transmit path, call common GRE
functions") removed the ip6gre specific transmit function, but left the
struct ipv6_tel_txoption definition. Clean it up.
Signed-off-by: Jakub Sitnicki <jkbs@redhat.com>
---
net/ipv6/ip6_gre.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index 75b6108..65bdfd1 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -484,11 +484,6 @@ static int gre_rcv(struct sk_buff *skb)
return 0;
}
-struct ipv6_tel_txoption {
- struct ipv6_txoptions ops;
- __u8 dst_opt[8];
-};
-
static int gre_handle_offloads(struct sk_buff *skb, bool csum)
{
return iptunnel_handle_offloads(skb,
--
2.7.4
^ permalink raw reply related
* Re: [PATCH][V2] net: sctp: fix array overrun read on sctp_timer_tbl
From: Marcelo Ricardo Leitner @ 2017-01-20 13:58 UTC (permalink / raw)
To: Colin King
Cc: Vlad Yasevich, Neil Horman, David S . Miller, linux-sctp, netdev,
linux-kernel
In-Reply-To: <20170120134542.21104-1-colin.king@canonical.com>
On Fri, Jan 20, 2017 at 01:45:42PM +0000, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Table sctp_timer_tbl is missing a TIMEOUT_RECONF string so
> add this in. Also compare timeout with the size of the array
> sctp_timer_tbl rather than SCTP_EVENT_TIMEOUT_MAX. Also add
> a build time check that SCTP_EVENT_TIMEOUT_MAX is correct
> so we don't ever get this kind of mismatch between the table
> and SCTP_EVENT_TIMEOUT_MAX in the future.
>
> Kudos to Marcel Ricardo Leitner for spotting the missing string
> and suggesting the build time sanity check.
>
> Fixes CoverityScan CID#1397639 ("Out-of-bounds read")
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Not sure I can add the Fixes tag for you here, but:
Fixes: 7b9438de0cd4 ("sctp: add stream reconf timer")
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Thanks
> ---
> net/sctp/debug.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/net/sctp/debug.c b/net/sctp/debug.c
> index 95d7b15..2e47eb2 100644
> --- a/net/sctp/debug.c
> +++ b/net/sctp/debug.c
> @@ -159,6 +159,7 @@ static const char *const sctp_timer_tbl[] = {
> "TIMEOUT_T4_RTO",
> "TIMEOUT_T5_SHUTDOWN_GUARD",
> "TIMEOUT_HEARTBEAT",
> + "TIMEOUT_RECONF",
> "TIMEOUT_SACK",
> "TIMEOUT_AUTOCLOSE",
> };
> @@ -166,7 +167,9 @@ static const char *const sctp_timer_tbl[] = {
> /* Lookup timer debug name. */
> const char *sctp_tname(const sctp_subtype_t id)
> {
> - if (id.timeout <= SCTP_EVENT_TIMEOUT_MAX)
> + BUILD_BUG_ON(SCTP_EVENT_TIMEOUT_MAX + 1 != ARRAY_SIZE(sctp_timer_tbl));
> +
> + if (id.timeout < ARRAY_SIZE(sctp_timer_tbl))
> return sctp_timer_tbl[id.timeout];
> return "unknown_timer";
> }
> --
> 2.10.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH iproute2 net-next] ipmroute: add support for RTNH_F_UNRESOLVED
From: Nikolay Aleksandrov @ 2017-01-20 14:05 UTC (permalink / raw)
To: netdev; +Cc: stephen, roopa
In-Reply-To: <1484921062-23379-1-git-send-email-nikolay@cumulusnetworks.com>
On 20/01/17 15:04, Nikolay Aleksandrov wrote:
> This patch adds a new field that is printed in the end of the line which
> denotes the real entry state. Before this patch an entry's IIF could
> disappear and it would look like an unresolved one (iif = unresolved):
> (3.0.16.1, 225.11.16.1) Iif: unresolved
> with no way to really distinguish it from an unresolved entry.
> After the patch if the dumped entry has RTNH_F_UNRESOLVED set we get:
> (3.0.16.1, 225.11.16.1) Iif: unresolved State: unresolved
> for unresolved entries and:
> (0.0.0.0, 225.11.11.11) Iif: eth4 Oifs: eth3 State: resolved
> for resolved entries after the OIF list. Note that "State:" has ':' in
> it so it cannot be mistaken for an interface name.
> And for the example above, we'd get:
> (0.0.0.0, 225.11.11.11) Iif: unresolved State: resolved
>
> Also when dumping all routes via ip route show table all, it will show
> up as:
> multicast 225.11.16.1/32 from 3.0.16.1/32 table default proto 17 unresolved
>
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
> ---
> ip/ipmroute.c | 6 ++++++
> ip/iproute.c | 2 ++
> 2 files changed, 8 insertions(+)
>
Oops, sent the wrong version. v2 coming up, sorry for the noise
^ permalink raw reply
* Re: [PATCH net] net: mpls: Fix multipath selection for LSR use case
From: Robert Shearman @ 2017-01-20 14:09 UTC (permalink / raw)
To: David Ahern, netdev; +Cc: roopa
In-Reply-To: <1484873463-11699-1-git-send-email-dsa@cumulusnetworks.com>
On 20/01/17 00:51, David Ahern wrote:
> MPLS multipath for LSR is broken -- always selecting the first nexthop
> in the one label case. For example:
>
> $ ip netns exec ns1 ip -f mpls ro ls
> 100
> nexthop as to 200 via inet 172.16.2.2 dev virt12
> nexthop as to 300 via inet 172.16.3.2 dev virt13
> 101
> nexthop as to 201 via inet6 2000:2::2 dev virt12
> nexthop as to 301 via inet6 2000:3::2 dev virt13
>
> In this example incoming packets have a single MPLS labels which means
> BOS bit is set. The BOS bit is passed from mpls_forward down to
> mpls_multipath_hash which never processes the hash loop because BOS is 1.
>
> Removing the bos arg from mpls_multipath_hash uncovers a number of other
> problems with the hash loop that processes the MPLS label stack -- from
> incorrect assumptions on the skb (skb has already pulled the first mpls
> label in mpls_forward yet loop assumes it is there)
This was intentional because it doesn't really add anything to include
the top-most label in the entropy since all traffic for the mpls_route
will have the same top-most label, until support for sharing of
mpls_routes is added.
Having said that, it costs very little to do this, makes the code
simpler and avoids the need to remember to change this if sharing is
added, so it's fine with me.
> to incorrect
> pskb_may_pull checks (label_index starts at 0 and pskb_may_pull checks
> all use sizeof() * label_index).
>
> This patch addresses all problems by moving the skb_pull in mpls_forward
> after mpls_select_multipath. This allows mpls_multipath_hash to see the
> skb with the entire label stack as it arrived.
>
> From there mpls_multipath_hash is modified to additively compute the
> total mpls header length on each pass (on pass N mpls_hdr_len is
> N * sizeof(mpls_shim_hdr)). When the label is found with the BOS set it
> verifies the skb has sufficient header for ipv4 or ipv6, and find the
> IPv4 and IPv6 header by using the last mpls_hdr pointer and adding 1 to
> advance past it.
>
> With these changes I have verified the code correctly sees the label,
> BOS, IPv4 and IPv6 addresses in the network header and icmp/tcp/udp
> traffic for ipv4 and ipv6 are distributed across the nexthops.
>
> Fixes: 1c78efa8319ca ("mpls: flow-based multipath selection")
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Acked-by: Robert Shearman <rshearma@brocade.com>
Good catch, thanks for fixing.
^ permalink raw reply
* [PATCH iproute2 net-next] ipmroute: add support for RTNH_F_UNRESOLVED
From: Nikolay Aleksandrov @ 2017-01-20 14:04 UTC (permalink / raw)
To: netdev; +Cc: stephen, roopa, Nikolay Aleksandrov
This patch adds a new field that is printed in the end of the line which
denotes the real entry state. Before this patch an entry's IIF could
disappear and it would look like an unresolved one (iif = unresolved):
(3.0.16.1, 225.11.16.1) Iif: unresolved
with no way to really distinguish it from an unresolved entry.
After the patch if the dumped entry has RTNH_F_UNRESOLVED set we get:
(3.0.16.1, 225.11.16.1) Iif: unresolved State: unresolved
for unresolved entries and:
(0.0.0.0, 225.11.11.11) Iif: eth4 Oifs: eth3 State: resolved
for resolved entries after the OIF list. Note that "State:" has ':' in
it so it cannot be mistaken for an interface name.
And for the example above, we'd get:
(0.0.0.0, 225.11.11.11) Iif: unresolved State: resolved
Also when dumping all routes via ip route show table all, it will show
up as:
multicast 225.11.16.1/32 from 3.0.16.1/32 table default proto 17 unresolved
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
ip/ipmroute.c | 6 ++++++
ip/iproute.c | 2 ++
2 files changed, 8 insertions(+)
diff --git a/ip/ipmroute.c b/ip/ipmroute.c
index 512afcd2086e..913f3fd28e14 100644
--- a/ip/ipmroute.c
+++ b/ip/ipmroute.c
@@ -159,6 +159,12 @@ int print_mroute(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
nh = RTNH_NEXT(nh);
}
}
+ fprintf(fp, " State: ");
+ if (r->rtm_flags & RTNH_F_UNRESOLVED)
+ fprintf(fp, "unresolved");
+ else
+ fprintf(fp, "resolved");
+
if (show_stats && tb[RTA_MFC_STATS]) {
struct rta_mfc_stats *mfcs = RTA_DATA(tb[RTA_MFC_STATS]);
diff --git a/ip/iproute.c b/ip/iproute.c
index e433de8be189..c19578337f71 100644
--- a/ip/iproute.c
+++ b/ip/iproute.c
@@ -448,6 +448,8 @@ int print_route(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
fprintf(fp, "notify ");
if (r->rtm_flags & RTNH_F_LINKDOWN)
fprintf(fp, "linkdown ");
+ if (r->rtm_flags & RTNH_F_UNRESOLVED)
+ fprintf(fp, "unresolved ");
if (tb[RTA_MARK]) {
unsigned int mark = *(unsigned int *)RTA_DATA(tb[RTA_MARK]);
--
2.1.4
^ permalink raw reply related
* RE: [PATCH] rtlwifi: rtl8192x: Enabling and disabling hardware interrupts after enabling local irq flags
From: Bharat Kumar Gogada @ 2017-01-20 14:14 UTC (permalink / raw)
To: Larry Finger, chaoming_li@realsil.com.cn,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: kvalo@codeaurora.org, netdev@vger.kernel.org, Ravikiran Gummaluri
In-Reply-To: <b2e783f6-fa09-e287-8119-266299cdae22@lwfinger.net>
> On 01/19/2017 04:14 AM, Bharat Kumar Gogada wrote:
> > -Realtek 8192CE chipset maintains local irq flags after enabling/disabling
> > hardware interrupts.
> > -Hardware interrupts are enabled before enabling the local irq
> > flags(these flags are being checked in interrupt handler),
> > leading to race condition on some RP, where the irq line between
> > bridge and GIC goes high at ASSERT_INTx and goes low only
> > at DEASSERT_INTx. In this kind of RP by the time ASSERT_INTx is seen
> > irq_enable flag is still set to false, resulting in continuous
> > interrupts seen by CPU as DEASSERT_INTx cannot be sent since
> > flag is still false and making CPU stall.
> > -Changing the sequence of setting these irq flags.
> >
> > Signed-off-by: Bharat Kumar Gogada <bharatku@xilinx.com>
> > ---
>
> This patch should be enhanced with the smb_xx() calls as suggested by by Lino.
>
> The subject should be changed. I would suggest something like "rtlwifi:
> rtl8192ce: Prevent race condition when enabling interrupts", as it explains the
> condition you are preventing.
>
> The other PCI drivers also have the same problem. Do you want to prepare the
> patches, or should I do it?
>
Thanks Larry. Please send out the patches adding the above enhancements suggested by Lino.
Bharat
^ permalink raw reply
* Re: [PATCH] net: phy: micrel: add KSZ8795 ethernet switch
From: Andrew Lunn @ 2017-01-20 14:17 UTC (permalink / raw)
To: Sean Nyekjaer; +Cc: netdev
In-Reply-To: <20170120125049.121307-1-sean.nyekjaer@prevas.dk>
On Fri, Jan 20, 2017 at 01:50:49PM +0100, Sean Nyekjaer wrote:
> This ethernet switch have unfortunately the same phy id as KSZ8051.
Hi Sean
Please could you explain some more. You are adding PHY support here,
not switch support. So is this to enable the PHY driver for the PHYs
embedded in the switch?
Andrew
^ permalink raw reply
* [PATCH iproute2 net-next v2] ipmroute: add support for RTNH_F_UNRESOLVED
From: Nikolay Aleksandrov @ 2017-01-20 14:15 UTC (permalink / raw)
To: netdev; +Cc: stephen, roopa, Nikolay Aleksandrov
In-Reply-To: <1484921062-23379-1-git-send-email-nikolay@cumulusnetworks.com>
This patch adds a new field that is printed in the end of the line which
denotes the real entry state. Before this patch an entry's IIF could
disappear and it would look like an unresolved one (iif = unresolved):
(3.0.16.1, 225.11.16.1) Iif: unresolved
with no way to really distinguish it from an unresolved entry.
After the patch if the dumped entry has RTNH_F_UNRESOLVED set we get:
(3.0.16.1, 225.11.16.1) Iif: unresolved State: unresolved
for unresolved entries and:
(0.0.0.0, 225.11.11.11) Iif: eth4 Oifs: eth3 State: resolved
for resolved entries after the OIF list. Note that "State:" has ':' in
it so it cannot be mistaken for an interface name.
And for the example above, we'd get:
(0.0.0.0, 225.11.11.11) Iif: unresolved State: resolved
Also when dumping all routes via ip route show table all, it will show
up as:
multicast 225.11.16.1/32 from 3.0.16.1/32 table default proto 17 unresolved
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
v2: sent latest version, with dumping the state in one line
ip/ipmroute.c | 2 ++
ip/iproute.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/ip/ipmroute.c b/ip/ipmroute.c
index 512afcd2086e..593ce3a1bd95 100644
--- a/ip/ipmroute.c
+++ b/ip/ipmroute.c
@@ -159,6 +159,8 @@ int print_mroute(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
nh = RTNH_NEXT(nh);
}
}
+ fprintf(fp, " State: %s",
+ r->rtm_flags & RTNH_F_UNRESOLVED ? "unresolved" : "resolved");
if (show_stats && tb[RTA_MFC_STATS]) {
struct rta_mfc_stats *mfcs = RTA_DATA(tb[RTA_MFC_STATS]);
diff --git a/ip/iproute.c b/ip/iproute.c
index e433de8be189..c19578337f71 100644
--- a/ip/iproute.c
+++ b/ip/iproute.c
@@ -448,6 +448,8 @@ int print_route(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
fprintf(fp, "notify ");
if (r->rtm_flags & RTNH_F_LINKDOWN)
fprintf(fp, "linkdown ");
+ if (r->rtm_flags & RTNH_F_UNRESOLVED)
+ fprintf(fp, "unresolved ");
if (tb[RTA_MARK]) {
unsigned int mark = *(unsigned int *)RTA_DATA(tb[RTA_MARK]);
--
2.1.4
^ permalink raw reply related
* [PATCH] sock: use hlist_entry_safe
From: Geliang Tang @ 2017-01-20 14:27 UTC (permalink / raw)
To: David S. Miller; +Cc: Geliang Tang, netdev, linux-kernel
Use hlist_entry_safe() instead of open-coding it.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
---
include/net/sock.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index 4077ec4..c4e1caf1 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -544,8 +544,7 @@ static inline struct sock *sk_nulls_head(const struct hlist_nulls_head *head)
static inline struct sock *sk_next(const struct sock *sk)
{
- return sk->sk_node.next ?
- hlist_entry(sk->sk_node.next, struct sock, sk_node) : NULL;
+ return hlist_entry_safe(sk->sk_node.next, struct sock, sk_node);
}
static inline struct sock *sk_nulls_next(const struct sock *sk)
--
2.9.3
^ permalink raw reply related
* Re: [PATCH v7 11/13] net: ethernet: aquantia: Ethtool support
From: Rami Rosen @ 2017-01-20 14:33 UTC (permalink / raw)
To: Netdev
In-Reply-To: <733a83f4-892e-f77b-3c90-8a3a26642e3e@gmail.com>
+1
Many times this information is needed, and "ethtool -i" is a
convenient way to get it.
Rami Rosen
^ permalink raw reply
* [PATCH] net/mlx4: use rb_entry()
From: Geliang Tang @ 2017-01-20 14:36 UTC (permalink / raw)
To: Yishai Hadas; +Cc: Geliang Tang, netdev, linux-rdma, linux-kernel
In-Reply-To: <c6a809ea5820242a4ae126b03cdcd910a36e5cae.1484817152.git.geliangtang@gmail.com>
To make the code clearer, use rb_entry() instead of container_of() to
deal with rbtree.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
---
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
index 1822382..6da6e01 100644
--- a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
+++ b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
@@ -236,8 +236,8 @@ static void *res_tracker_lookup(struct rb_root *root, u64 res_id)
struct rb_node *node = root->rb_node;
while (node) {
- struct res_common *res = container_of(node, struct res_common,
- node);
+ struct res_common *res = rb_entry(node, struct res_common,
+ node);
if (res_id < res->res_id)
node = node->rb_left;
@@ -255,8 +255,8 @@ static int res_tracker_insert(struct rb_root *root, struct res_common *res)
/* Figure out where to put new node */
while (*new) {
- struct res_common *this = container_of(*new, struct res_common,
- node);
+ struct res_common *this = rb_entry(*new, struct res_common,
+ node);
parent = *new;
if (res->res_id < this->res_id)
--
2.9.3
^ permalink raw reply related
* [PATCH] 6lowpan: use rb_entry()
From: Geliang Tang @ 2017-01-20 14:36 UTC (permalink / raw)
To: Alexander Aring, Jukka Rissanen, David S. Miller
Cc: Geliang Tang, linux-bluetooth, linux-wpan, netdev, linux-kernel
To make the code clearer, use rb_entry() instead of container_of() to
deal with rbtree.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
---
net/6lowpan/nhc.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/6lowpan/nhc.c b/net/6lowpan/nhc.c
index 7008d53..4fa2fdd 100644
--- a/net/6lowpan/nhc.c
+++ b/net/6lowpan/nhc.c
@@ -27,8 +27,8 @@ static int lowpan_nhc_insert(struct lowpan_nhc *nhc)
/* Figure out where to put new node */
while (*new) {
- struct lowpan_nhc *this = container_of(*new, struct lowpan_nhc,
- node);
+ struct lowpan_nhc *this = rb_entry(*new, struct lowpan_nhc,
+ node);
int result, len_dif, len;
len_dif = nhc->idlen - this->idlen;
@@ -69,8 +69,8 @@ static struct lowpan_nhc *lowpan_nhc_by_nhcid(const struct sk_buff *skb)
const u8 *nhcid_skb_ptr = skb->data;
while (node) {
- struct lowpan_nhc *nhc = container_of(node, struct lowpan_nhc,
- node);
+ struct lowpan_nhc *nhc = rb_entry(node, struct lowpan_nhc,
+ node);
u8 nhcid_skb_ptr_masked[LOWPAN_NHC_MAX_ID_LEN];
int result, i;
--
2.9.3
^ permalink raw reply related
* RE: [PATCHv3 net-next 3/4] sctp: add support for generating stream reconf add incoming/outgoing streams request chunk
From: David Laight @ 2017-01-20 14:50 UTC (permalink / raw)
To: 'Xin Long', network dev, linux-sctp@vger.kernel.org
Cc: Marcelo Ricardo Leitner, Neil Horman, Vlad Yasevich,
davem@davemloft.net
In-Reply-To: <0d8d8e5482205ead64a2cfd2d414e918ce5602dd.1484845510.git.lucien.xin@gmail.com>
From: Xin Long
> Sent: 19 January 2017 17:19
> This patch is to define Add Incoming/Outgoing Streams Request
> Parameter described in rfc6525 section 4.5 and 4.6. They can
> be in one same chunk trunk as rfc6525 section 3.1-7 describes,
> so make them in one function.
...
> +struct sctp_strreset_addstrm {
> + sctp_paramhdr_t param_hdr;
> + __u32 request_seq;
> + __u16 number_of_streams;
> + __u16 reserved;
> +} __packed;
...
> + addstrm.param_hdr.type = SCTP_PARAM_RESET_ADD_OUT_STREAMS;
> + addstrm.param_hdr.length = htons(size);
> + addstrm.number_of_streams = htons(out);
> + addstrm.request_seq = htonl(asoc->strreset_outseq);
> + addstrm.reserved = 0;
> +
> + sctp_addto_chunk(retval, size, &addstrm);
Since you allocate the sctp_strreset_addstrm structure on stack
there is no requirement for it to be packed.
David
^ permalink raw reply
* Re: [PATCH] inet: don't use sk_v6_rcv_saddr directly
From: Josef Bacik @ 2017-01-20 14:18 UTC (permalink / raw)
To: davem, tom, netdev, kafai
In-Reply-To: <1484866066-25407-1-git-send-email-jbacik@fb.com>
On Thu, Jan 19, 2017 at 5:47 PM, Josef Bacik <jbacik@fb.com> wrote:
> When comparing two sockets we need to use inet6_rcv_saddr so we get a
> NULL
> sk_v6_rcv_saddr if the socket isn't AF_INET6, otherwise our
> comparison function
> can be wrong.
>
> Fixes: 637bc8b ("inet: reset tb->fastreuseport when adding a
> reuseport sk")
> Signed-off-by: Josef Bacik <jbacik@fb.com>
> ---
> net/ipv4/inet_connection_sock.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv4/inet_connection_sock.c
> b/net/ipv4/inet_connection_sock.c
> index 096a085..a336c42 100644
> --- a/net/ipv4/inet_connection_sock.c
> +++ b/net/ipv4/inet_connection_sock.c
> @@ -99,7 +99,7 @@ int inet_rcv_saddr_equal(const struct sock *sk,
> const struct sock *sk2,
> #if IS_ENABLED(CONFIG_IPV6)
> if (sk->sk_family == AF_INET6)
> return ipv6_rcv_saddr_equal(&sk->sk_v6_rcv_saddr,
> - &sk2->sk_v6_rcv_saddr,
> + inet6_rcv_saddr(sk2),
> sk->sk_rcv_saddr,
> sk2->sk_rcv_saddr,
> ipv6_only_sock(sk),
> --
> 2.5.5
Sorry I forgot to tag this, it's for net-next. Thanks,
Josef
^ permalink raw reply
* Re: [PATCH 2/2] at803x: double check SGMII side autoneg
From: Zefir Kurtisi @ 2017-01-20 15:31 UTC (permalink / raw)
To: Timur Tabi, netdev; +Cc: andrew, f.fainelli
In-Reply-To: <44eb0b95-1868-396b-db6b-18d233eff853@codeaurora.org>
On 01/20/2017 03:38 AM, Timur Tabi wrote:
> Zefir Kurtisi wrote:
>> It always operates at 675MHz, which with two lines gives 1.25Gbps,
>> which at 10/8 coding gives exactly 1Gbps net data rate. If the
>> at803x's copper side autonegotiates to 1Gbps, the bits traversing
>> over the SGMII match the copper side 1:1. In case the copper side
>> autonegotiates to e.g. 100Mbps, each bit at the copper side on the
>> SGMII bus is replicated and sent 10x times - or 100x times in case of
>> 10Mbps. The MAC side of the ETH needs to be aware of how the SGMII
>> data has to be interpreted, and this is why you have to set the bits
>> you are referring to.
>
> So does this mean that the SGMII link should not be autonegotiated? I currently
> have this code:
>
> if (phydev->autoneg == AUTONEG_ENABLE) {
> val &= ~(FORCE_AN_RX_CFG | FORCE_AN_TX_CFG);
> val |= AN_ENABLE;
> writel(val, phy->base + EMAC_SGMII_PHY_AUTONEG_CFG2);
> } else {
> ...
>
> So if the external PHY is set to autonegotiate, then the SGMII block is set to
> also negotiate. Now that I think about it, this seems wrong. And in fact, I'm not
> sure how it works. It seems that the this only makes sense if the SGMII block is
> configured to act as the only PHY. This is an option that the hardware supports
> but my driver does not. So perhaps I should remove this part, and just do the rest:
>
>
> u32 speed_cfg;
>
> switch (phydev->speed) {
> case SPEED_10:
> speed_cfg = SPDMODE_10;
> break;
> case SPEED_100:
> speed_cfg = SPDMODE_100;
> break;
> case SPEED_1000:
> speed_cfg = SPDMODE_1000;
> break;
> default:
> return -EINVAL;
> }
>
> if (phydev->duplex == DUPLEX_FULL)
> speed_cfg |= DUPLEX_MODE;
>
> val &= ~AN_ENABLE;
> writel(speed_cfg, phy->base + EMAC_SGMII_PHY_SPEED_CFG1);
> writel(val, phy->base + EMAC_SGMII_PHY_AUTONEG_CFG2);
>
> Should I be doing this all the time?
>
Hm, that might be product dependent. From my experience with the gianfar/at8031
this is what I can share: there is a known flaw in some revisions of the eTSEC
that causes random failures in SGMII autonegotiation. As a workaround FSL proposes
to use fixed speed. I spent lots of time getting this working, but in the end it
turned out it does not. Setting fixed Gbps speed on both ends of the link is
reported to be ok (link failure bits clean, page transmitted ok), but no data goes
through the link.
>From a source I can't remember atm I was told that autonegotiation is mandatory
for SGMII, therefore I believe there is no need to change the autoneg bits for
SGMII in your case. I'd assume that resetting the link before setting the speed
value should be enough, i.e. the second write to EMAC_SGMII_PHY_AUTONEG_CFG2 might
be useless. YMMV
>> To track down who is causing the additional message, I would proceed
>> with following technique that helped me dig down a similar problem:
>> since you control the events in question and there is no risk of
>> flooding the kernel log, in the top of phy.c::phy_print_status() add
>> a dump_stack() call. In the debug log ensure that all of the traces
>> end up in the same phydev->adjust_link() callback handler (in your
>> case emac_adjust_link()).
>
> That's a good idea, thanks.
>
As Florian responded, it seems you need to double check for real changes before
printing the link status to get rid of the double printed notifications.
Good Luck.
^ permalink raw reply
* Re: [PATCH] stmmac: adding EEE to GMAC4
From: Joao Pinto @ 2017-01-20 15:49 UTC (permalink / raw)
To: Rayagond Kokatanur, Joao Pinto
Cc: David Miller, Giuseppe Cavallaro, Alexandre Torgue, linux-kernel,
netdev
In-Reply-To: <CAJ3bTp7XHNd+oc9QsX25iX_umARFjSveehPY_a+quJBnj-okkA@mail.gmail.com>
Hi Rayagond,
Às 6:01 AM de 1/19/2017, Rayagond Kokatanur escreveu:
> On Thu, Dec 29, 2016 at 10:40 PM, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
>> This patch adds Energy Efficiency Ethernet to GMAC4.
>>
>> Signed-off-by: Joao Pinto <jpinto@synopsys.com>
>> ---
>> drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 12 +++++
>> drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 59 +++++++++++++++++++++++
>> 2 files changed, 71 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>> index b524598..73d1dab 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>> @@ -90,6 +90,18 @@ enum power_event {
>> power_down = 0x00000001,
>> };
>>
>> +/* Energy Efficient Ethernet (EEE) for GMAC4
>> + *
>> + * LPI status, timer and control register offset
>> + */
>> +#define GMAC4_LPI_CTRL_STATUS 0xd0
>> +#define GMAC4_LPI_TIMER_CTRL 0xd4
>> +
>> +/* LPI control and status defines */
>> +#define GMAC4_LPI_CTRL_STATUS_LPITXA BIT(19) /* Enable LPI TX Automate */
>> +#define GMAC4_LPI_CTRL_STATUS_PLS BIT(17) /* PHY Link Status */
>> +#define GMAC4_LPI_CTRL_STATUS_LPIEN BIT(16) /* LPI Enable */
>> +
>> /* MAC Debug bitmap */
>> #define GMAC_DEBUG_TFCSTS_MASK GENMASK(18, 17)
>> #define GMAC_DEBUG_TFCSTS_SHIFT 17
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
>> index ecfbf57..02eab79 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
>> @@ -137,6 +137,61 @@ static void dwmac4_get_umac_addr(struct mac_device_info *hw,
>> GMAC_ADDR_LOW(reg_n));
>> }
>>
>> +static void dwmac4_set_eee_mode(struct mac_device_info *hw)
>> +{
>> + void __iomem *ioaddr = hw->pcsr;
>> + u32 value;
>> +
>> + /* Enable the link status receive on RGMII, SGMII ore SMII
>> + * receive path and instruct the transmit to enter in LPI
>> + * state.
>> + */
>> + value = readl(ioaddr + GMAC4_LPI_CTRL_STATUS);
>> + value |= GMAC4_LPI_CTRL_STATUS_LPIEN | GMAC4_LPI_CTRL_STATUS_LPITXA;
>> +
>> + writel(value, ioaddr + GMAC4_LPI_CTRL_STATUS);
>> +}
>> +
>> +static void dwmac4_reset_eee_mode(struct mac_device_info *hw)
>> +{
>> + void __iomem *ioaddr = hw->pcsr;
>> + u32 value;
>> +
>> + value = readl(ioaddr + GMAC4_LPI_CTRL_STATUS);
>> + value &= ~(GMAC4_LPI_CTRL_STATUS_LPIEN | GMAC4_LPI_CTRL_STATUS_LPITXA);
>> + writel(value, ioaddr + GMAC4_LPI_CTRL_STATUS);
>> +}
>> +
>> +static void dwmac4_set_eee_pls(struct mac_device_info *hw, int link)
>> +{
>> + void __iomem *ioaddr = hw->pcsr;
>> + u32 value;
>> +
>> + value = readl(ioaddr + GMAC4_LPI_CTRL_STATUS);
>> +
>> + if (link)
>> + value |= GMAC4_LPI_CTRL_STATUS_PLS;
>> + else
>> + value &= ~GMAC4_LPI_CTRL_STATUS_PLS;
>> +
>> + writel(value, ioaddr + GMAC4_LPI_CTRL_STATUS);
>> +}
>> +
>> +static void dwmac4_set_eee_timer(struct mac_device_info *hw, int ls, int tw)
>> +{
>> + void __iomem *ioaddr = hw->pcsr;
>> + int value = ((tw & 0xffff)) | ((ls & 0x7ff) << 16);
>
> If I am not wrong, LS field is 10 bits wide not 11 bits, hence we
> should AND 0x3ff.
>
> int value = ((tw & 0xffff)) | ((ls & 0x3ff) << 16);
You are absolutely right. LS is related to 25:16 (10 bits).
Thank you for checking it!
Joao
>
>> +
>> + /* Program the timers in the LPI timer control register:
>> + * LS: minimum time (ms) for which the link
>> + * status from PHY should be ok before transmitting
>> + * the LPI pattern.
>> + * TW: minimum time (us) for which the core waits
>> + * after it has stopped transmitting the LPI pattern.
>> + */
>> + writel(value, ioaddr + GMAC4_LPI_TIMER_CTRL);
>> +}
>> +
>> static void dwmac4_set_filter(struct mac_device_info *hw,
>> struct net_device *dev)
>> {
>> @@ -410,6 +465,10 @@ static const struct stmmac_ops dwmac4_ops = {
>> .pmt = dwmac4_pmt,
>> .set_umac_addr = dwmac4_set_umac_addr,
>> .get_umac_addr = dwmac4_get_umac_addr,
>> + .set_eee_mode = dwmac4_set_eee_mode,
>> + .reset_eee_mode = dwmac4_reset_eee_mode,
>> + .set_eee_timer = dwmac4_set_eee_timer,
>> + .set_eee_pls = dwmac4_set_eee_pls,
>> .pcs_ctrl_ane = dwmac4_ctrl_ane,
>> .pcs_rane = dwmac4_rane,
>> .pcs_get_adv_lp = dwmac4_get_adv_lp,
>> --
>> 2.9.3
>>
>
>
>
^ permalink raw reply
* [PATCH net] ipv6: seg6_genl_set_tunsrc() must check kmemdup() return value
From: Eric Dumazet @ 2017-01-20 15:57 UTC (permalink / raw)
To: David Miller; +Cc: netdev, David Lebrun
From: Eric Dumazet <edumazet@google.com>
seg6_genl_get_tunsrc() and set_tun_src() do not handle tun_src being
possibly NULL, so we must check kmemdup() return value and abort if
it is NULL
Fixes: 915d7e5e5930 ("ipv6: sr: add code base for control plane support of SR-IPv6")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: David Lebrun <david.lebrun@uclouvain.be>
---
net/ipv6/seg6.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv6/seg6.c b/net/ipv6/seg6.c
index b172d85c650a376f541ea05d72046c76b8404303..a855eb325b030a666fe92c56a2d432c77d9dfe7a 100644
--- a/net/ipv6/seg6.c
+++ b/net/ipv6/seg6.c
@@ -176,6 +176,8 @@ static int seg6_genl_set_tunsrc(struct sk_buff *skb, struct genl_info *info)
val = nla_data(info->attrs[SEG6_ATTR_DST]);
t_new = kmemdup(val, sizeof(*val), GFP_KERNEL);
+ if (!t_new)
+ return -ENOMEM;
mutex_lock(&sdata->lock);
^ permalink raw reply related
* Re: [PATCH net] virtio-net: restore VIRTIO_HDR_F_DATA_VALID on receiving
From: David Miller @ 2017-01-20 16:03 UTC (permalink / raw)
To: jasowang; +Cc: rolf.neugebauer, netdev, mst, linux-kernel, virtualization
In-Reply-To: <1484893962-7614-1-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Fri, 20 Jan 2017 14:32:42 +0800
> Commit 501db511397f ("virtio: don't set VIRTIO_NET_HDR_F_DATA_VALID on
> xmit") in fact disables VIRTIO_HDR_F_DATA_VALID on receiving path too,
> fixing this by adding a hint (has_data_valid) and set it only on the
> receiving path.
>
> Cc: Rolf Neugebauer <rolf.neugebauer@docker.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Applied, thanks Jason.
^ permalink raw reply
* Re: [PATCH] stmmac: adding EEE to GMAC4
From: Joao Pinto @ 2017-01-20 15:58 UTC (permalink / raw)
To: Rayagond Kokatanur, Joao Pinto
Cc: David Miller, Giuseppe Cavallaro, Alexandre Torgue, linux-kernel,
netdev
In-Reply-To: <CAJ3bTp7XHNd+oc9QsX25iX_umARFjSveehPY_a+quJBnj-okkA@mail.gmail.com>
Sorry, please ignore, wrong patch file.
Joao Pinto
Às 6:01 AM de 1/19/2017, Rayagond Kokatanur escreveu:
> On Thu, Dec 29, 2016 at 10:40 PM, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
>> This patch adds Energy Efficiency Ethernet to GMAC4.
>>
>> Signed-off-by: Joao Pinto <jpinto@synopsys.com>
>> ---
>> drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 12 +++++
>> drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 59 +++++++++++++++++++++++
>> 2 files changed, 71 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>> index b524598..73d1dab 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>> @@ -90,6 +90,18 @@ enum power_event {
>> power_down = 0x00000001,
>> };
>>
>> +/* Energy Efficient Ethernet (EEE) for GMAC4
>> + *
>> + * LPI status, timer and control register offset
>> + */
>> +#define GMAC4_LPI_CTRL_STATUS 0xd0
>> +#define GMAC4_LPI_TIMER_CTRL 0xd4
>> +
>> +/* LPI control and status defines */
>> +#define GMAC4_LPI_CTRL_STATUS_LPITXA BIT(19) /* Enable LPI TX Automate */
>> +#define GMAC4_LPI_CTRL_STATUS_PLS BIT(17) /* PHY Link Status */
>> +#define GMAC4_LPI_CTRL_STATUS_LPIEN BIT(16) /* LPI Enable */
>> +
>> /* MAC Debug bitmap */
>> #define GMAC_DEBUG_TFCSTS_MASK GENMASK(18, 17)
>> #define GMAC_DEBUG_TFCSTS_SHIFT 17
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
>> index ecfbf57..02eab79 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
>> @@ -137,6 +137,61 @@ static void dwmac4_get_umac_addr(struct mac_device_info *hw,
>> GMAC_ADDR_LOW(reg_n));
>> }
>>
>> +static void dwmac4_set_eee_mode(struct mac_device_info *hw)
>> +{
>> + void __iomem *ioaddr = hw->pcsr;
>> + u32 value;
>> +
>> + /* Enable the link status receive on RGMII, SGMII ore SMII
>> + * receive path and instruct the transmit to enter in LPI
>> + * state.
>> + */
>> + value = readl(ioaddr + GMAC4_LPI_CTRL_STATUS);
>> + value |= GMAC4_LPI_CTRL_STATUS_LPIEN | GMAC4_LPI_CTRL_STATUS_LPITXA;
>> +
>> + writel(value, ioaddr + GMAC4_LPI_CTRL_STATUS);
>> +}
>> +
>> +static void dwmac4_reset_eee_mode(struct mac_device_info *hw)
>> +{
>> + void __iomem *ioaddr = hw->pcsr;
>> + u32 value;
>> +
>> + value = readl(ioaddr + GMAC4_LPI_CTRL_STATUS);
>> + value &= ~(GMAC4_LPI_CTRL_STATUS_LPIEN | GMAC4_LPI_CTRL_STATUS_LPITXA);
>> + writel(value, ioaddr + GMAC4_LPI_CTRL_STATUS);
>> +}
>> +
>> +static void dwmac4_set_eee_pls(struct mac_device_info *hw, int link)
>> +{
>> + void __iomem *ioaddr = hw->pcsr;
>> + u32 value;
>> +
>> + value = readl(ioaddr + GMAC4_LPI_CTRL_STATUS);
>> +
>> + if (link)
>> + value |= GMAC4_LPI_CTRL_STATUS_PLS;
>> + else
>> + value &= ~GMAC4_LPI_CTRL_STATUS_PLS;
>> +
>> + writel(value, ioaddr + GMAC4_LPI_CTRL_STATUS);
>> +}
>> +
>> +static void dwmac4_set_eee_timer(struct mac_device_info *hw, int ls, int tw)
>> +{
>> + void __iomem *ioaddr = hw->pcsr;
>> + int value = ((tw & 0xffff)) | ((ls & 0x7ff) << 16);
>
> If I am not wrong, LS field is 10 bits wide not 11 bits, hence we
> should AND 0x3ff.
>
> int value = ((tw & 0xffff)) | ((ls & 0x3ff) << 16);
>
>> +
>> + /* Program the timers in the LPI timer control register:
>> + * LS: minimum time (ms) for which the link
>> + * status from PHY should be ok before transmitting
>> + * the LPI pattern.
>> + * TW: minimum time (us) for which the core waits
>> + * after it has stopped transmitting the LPI pattern.
>> + */
>> + writel(value, ioaddr + GMAC4_LPI_TIMER_CTRL);
>> +}
>> +
>> static void dwmac4_set_filter(struct mac_device_info *hw,
>> struct net_device *dev)
>> {
>> @@ -410,6 +465,10 @@ static const struct stmmac_ops dwmac4_ops = {
>> .pmt = dwmac4_pmt,
>> .set_umac_addr = dwmac4_set_umac_addr,
>> .get_umac_addr = dwmac4_get_umac_addr,
>> + .set_eee_mode = dwmac4_set_eee_mode,
>> + .reset_eee_mode = dwmac4_reset_eee_mode,
>> + .set_eee_timer = dwmac4_set_eee_timer,
>> + .set_eee_pls = dwmac4_set_eee_pls,
>> .pcs_ctrl_ane = dwmac4_ctrl_ane,
>> .pcs_rane = dwmac4_rane,
>> .pcs_get_adv_lp = dwmac4_get_adv_lp,
>> --
>> 2.9.3
>>
>
>
>
^ permalink raw reply
* Re: [PATCH net] ipv6: seg6_genl_set_tunsrc() must check kmemdup() return value
From: David Lebrun @ 2017-01-20 16:06 UTC (permalink / raw)
To: Eric Dumazet, David Miller; +Cc: netdev
In-Reply-To: <1484927862.16328.123.camel@edumazet-glaptop3.roam.corp.google.com>
[-- Attachment #1: Type: text/plain, Size: 1083 bytes --]
On 01/20/2017 04:57 PM, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> seg6_genl_get_tunsrc() and set_tun_src() do not handle tun_src being
> possibly NULL, so we must check kmemdup() return value and abort if
> it is NULL
>
> Fixes: 915d7e5e5930 ("ipv6: sr: add code base for control plane support of SR-IPv6")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: David Lebrun <david.lebrun@uclouvain.be>
> ---
> net/ipv6/seg6.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/ipv6/seg6.c b/net/ipv6/seg6.c
> index b172d85c650a376f541ea05d72046c76b8404303..a855eb325b030a666fe92c56a2d432c77d9dfe7a 100644
> --- a/net/ipv6/seg6.c
> +++ b/net/ipv6/seg6.c
> @@ -176,6 +176,8 @@ static int seg6_genl_set_tunsrc(struct sk_buff *skb, struct genl_info *info)
>
> val = nla_data(info->attrs[SEG6_ATTR_DST]);
> t_new = kmemdup(val, sizeof(*val), GFP_KERNEL);
> + if (!t_new)
> + return -ENOMEM;
>
> mutex_lock(&sdata->lock);
>
>
>
Thanks :)
Acked-by: David Lebrun <david.lebrun@uclouvain.be>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]
^ permalink raw reply
* Re: [PATCH net] r8152: fix rtl8152_post_reset function
From: David Miller @ 2017-01-20 16:06 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1394712342-15778-234-Taiwan-albertk@realtek.com>
From: Hayes Wang <hayeswang@realtek.com>
Date: Fri, 20 Jan 2017 14:33:55 +0800
> The rtl8152_post_reset() should sumbit rx urb and interrupt transfer,
> otherwise the rx wouldn't work and the linking change couldn't be
> detected.
>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Applied, thank you.
^ permalink raw reply
* [PATCH] net: stmicro: fix LS field mask in EEE configuration
From: Joao Pinto @ 2017-01-20 16:00 UTC (permalink / raw)
To: davem; +Cc: rayagond, netdev, Joao Pinto
This patch fixes the LS mask when setting EEE timer.
LS field is 10 bits long and not 11 as currently.
Signed-off-by: Joao Pinto <jpinto@synopsys.com>
Reported-By: Rayagond Kokatanur <rayagond@vayavyalabs.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index 834f40f..202216c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -184,7 +184,7 @@ static void dwmac4_set_eee_pls(struct mac_device_info *hw, int link)
static void dwmac4_set_eee_timer(struct mac_device_info *hw, int ls, int tw)
{
void __iomem *ioaddr = hw->pcsr;
- int value = ((tw & 0xffff)) | ((ls & 0x7ff) << 16);
+ int value = ((tw & 0xffff)) | ((ls & 0x3ff) << 16);
/* Program the timers in the LPI timer control register:
* LS: minimum time (ms) for which the link
--
2.9.3
^ permalink raw reply related
* [PATCH net-next] ipv6: add NUMA awareness to seg6_hmac_init_algo()
From: Eric Dumazet @ 2017-01-20 16:08 UTC (permalink / raw)
To: David Miller; +Cc: netdev, David Lebrun
From: Eric Dumazet <edumazet@google.com>
Since we allocate per cpu storage, let's also use NUMA hints.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv6/seg6_hmac.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/seg6_hmac.c b/net/ipv6/seg6_hmac.c
index 5215e1eba01030dc9345b847eee5ac5ef3bed1b9..b274f1d95e037c93e8e0e6531cfc51709f71297c 100644
--- a/net/ipv6/seg6_hmac.c
+++ b/net/ipv6/seg6_hmac.c
@@ -389,7 +389,8 @@ static int seg6_hmac_init_algo(void)
return -ENOMEM;
for_each_possible_cpu(cpu) {
- shash = kzalloc(shsize, GFP_KERNEL);
+ shash = kzalloc_node(shsize, GFP_KERNEL,
+ cpu_to_node(cpu));
if (!shash)
return -ENOMEM;
*per_cpu_ptr(algo->shashs, cpu) = shash;
^ permalink raw reply related
* Re: [PATCH net] ipv6: seg6_genl_set_tunsrc() must check kmemdup() return value
From: David Miller @ 2017-01-20 16:09 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, david.lebrun
In-Reply-To: <1484927862.16328.123.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 20 Jan 2017 07:57:42 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> seg6_genl_get_tunsrc() and set_tun_src() do not handle tun_src being
> possibly NULL, so we must check kmemdup() return value and abort if
> it is NULL
>
> Fixes: 915d7e5e5930 ("ipv6: sr: add code base for control plane support of SR-IPv6")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
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