* Re: [PATCH 2/2] net: wireless: fix to uses struct
From: Ozgur Karatas @ 2016-12-21 23:01 UTC (permalink / raw)
To: Paul Bolle, johannes, David Miller
Cc: Thomas Gleixner, linux-wireless, netdev, linux-kernel
In-Reply-To: <601101482360611@web25o.yandex.ru>
My previous patch is invalid, I'm sorry.
The last patc will be fellow because "regulatory_request" is defined as a "static struct".
Signed-off-by: Ozgur Karatas <okaratas@member.fsf.org>
---
net/wireless/reg.c | 10 +++++-----
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 5dbac37..5b70970 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -490,7 +490,7 @@ static int reg_query_builtin(const char *alpha2)
if (!regdom)
return -ENODATA;
- request = kzalloc(sizeof(struct reg_regdb_apply_request), GFP_KERNEL);
+ request = kzalloc(sizeof(*reg_regdb_apply_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
@@ -2661,7 +2661,7 @@ int regulatory_hint_found_beacon(struct wiphy *wiphy,
if (processing)
return 0;
- reg_beacon = kzalloc(sizeof(struct reg_beacon), gfp);
+ reg_beacon = kzalloc(sizeof(*reg_beacon), gfp);
if (!reg_beacon)
return -ENOMEM;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 2/2] net: wireless: fix to uses struct
From: Ozgur Karatas @ 2016-12-21 22:50 UTC (permalink / raw)
To: Paul Bolle, johannes, David Miller
Cc: Thomas Gleixner, linux-wireless, netdev, linux-kernel
In-Reply-To: <1482359625.28171.2.camel@tiscali.nl>
22.12.2016, 00:34, "Paul Bolle" <pebolle@tiscali.nl>:
> On Thu, 2016-12-22 at 00:23 +0200, Ozgur Karatas wrote:
>> I compiled and didn't to errors.
>
> Really?
I'm very sorry. The "regulatory_request" is defined a static struct. I missed.
line: static struct regulatory_request core_request_world = {
I send to wrong line please can ignore last message and should be fix to as follows:
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 5dbac37..5b70970 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -490,7 +490,7 @@ static int reg_query_builtin(const char *alpha2)
if (!regdom)
return -ENODATA;
- request = kzalloc(sizeof(struct reg_regdb_apply_request), GFP_KERNEL);
+ request = kzalloc(sizeof(*reg_regdb_apply_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
@@ -2291,7 +2291,7 @@ static int regulatory_hint_core(const char *alpha2)
{
struct regulatory_request *request;
- request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+ request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
@@ -2313,7 +2313,7 @@ int regulatory_hint_user(const char *alpha2,
if (WARN_ON(!alpha2))
return -EINVAL;
- request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+ request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
@@ -2385,7 +2385,7 @@ int regulatory_hint(struct wiphy *wiphy, const char *alpha2)
wiphy->regulatory_flags &= ~REGULATORY_CUSTOM_REG;
- request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+ request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
@@ -2661,7 +2661,7 @@ int regulatory_hint_found_beacon(struct wiphy *wiphy,
if (processing)
return 0;
- reg_beacon = kzalloc(sizeof(struct reg_beacon), gfp);
+ reg_beacon = kzalloc(sizeof(*reg_beacon), gfp);
if (!reg_beacon)
return -ENOMEM;
--
2.1.4
> $ make net/wireless/reg.o
> CHK include/config/kernel.release
> CHK include/generated/uapi/linux/version.h
> CHK include/generated/utsrelease.h
> CHK include/generated/bounds.h
> CHK include/generated/timeconst.h
> CHK include/generated/asm-offsets.h
> CALL scripts/checksyscalls.sh
> CC net/wireless/reg.o
> net/wireless/reg.c: In function ‘regulatory_hint_core’:
> net/wireless/reg.c:2294:28: error: ‘regulatory_request’ undeclared (first use in this function)
> request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
> ^~~~~~~~~~~~~~~~~~
> net/wireless/reg.c:2294:28: note: each undeclared identifier is reported only once for each function it appears in
> net/wireless/reg.c: In function ‘regulatory_hint_user’:
> net/wireless/reg.c:2316:28: error: ‘regulatory_request’ undeclared (first use in this function)
> request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
> ^~~~~~~~~~~~~~~~~~
> net/wireless/reg.c: In function ‘regulatory_hint’:
> net/wireless/reg.c:2388:28: error: ‘regulatory_request’ undeclared (first use in this function)
> request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
> ^~~~~~~~~~~~~~~~~~
> scripts/Makefile.build:293: recipe for target 'net/wireless/reg.o' failed
> make[1]: *** [net/wireless/reg.o] Error 1
> Makefile:1640: recipe for target 'net/wireless/reg.o' failed
> make: *** [net/wireless/reg.o] Error 2
$ make M=net/wireless/
CC net/wireless//core.o
CC net/wireless//sysfs.o
CC net/wireless//radiotap.o
CC net/wireless//util.o
CC net/wireless//reg.o
CC net/wireless//scan.o
CC net/wireless//nl80211.o
CC net/wireless//mlme.o
CC net/wireless//ibss.o
CC net/wireless//sme.o
CC net/wireless//chan.o
CC net/wireless//ethtool.o
CC net/wireless//mesh.o
CC net/wireless//ap.o
CC net/wireless//trace.o
CC net/wireless//ocb.o
LD net/wireless//cfg80211.o
LD net/wireless//built-in.o
Building modules, stage 2.
MODPOST 0 modules
$ make net/wireless/reg.o
scripts/kconfig/conf --silentoldconfig Kconfig
*
* Restart config...
*
*
* Memory power savings
*
> Didn't Thomas Gleixner suggest that you do a basic C course just yesterday?
I don't have a problem with C programming, So only I'm learning the kernel.
Also, this is a lie if say "I'm expert to C".
I think be re-learned every day. wrong?
> Paul Bolle
Regards,
~ Ozgur
^ permalink raw reply related
* Re: [PATCH 2/2] net: wireless: fix to uses struct
From: Paul Bolle @ 2016-12-21 22:33 UTC (permalink / raw)
To: Ozgur Karatas, johannes, David Miller
Cc: Thomas Gleixner, linux-wireless, netdev, linux-kernel
In-Reply-To: <608881482358981@web17g.yandex.ru>
On Thu, 2016-12-22 at 00:23 +0200, Ozgur Karatas wrote:
> I compiled and didn't to errors.
Really?
$ make net/wireless/reg.o
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CHK include/generated/bounds.h
CHK include/generated/timeconst.h
CHK include/generated/asm-offsets.h
CALL scripts/checksyscalls.sh
CC net/wireless/reg.o
net/wireless/reg.c: In function ‘regulatory_hint_core’:
net/wireless/reg.c:2294:28: error: ‘regulatory_request’ undeclared (first use in this function)
request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
^~~~~~~~~~~~~~~~~~
net/wireless/reg.c:2294:28: note: each undeclared identifier is reported only once for each function it appears in
net/wireless/reg.c: In function ‘regulatory_hint_user’:
net/wireless/reg.c:2316:28: error: ‘regulatory_request’ undeclared (first use in this function)
request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
^~~~~~~~~~~~~~~~~~
net/wireless/reg.c: In function ‘regulatory_hint’:
net/wireless/reg.c:2388:28: error: ‘regulatory_request’ undeclared (first use in this function)
request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
^~~~~~~~~~~~~~~~~~
scripts/Makefile.build:293: recipe for target 'net/wireless/reg.o' failed
make[1]: *** [net/wireless/reg.o] Error 1
Makefile:1640: recipe for target 'net/wireless/reg.o' failed
make: *** [net/wireless/reg.o] Error 2
Didn't Thomas Gleixner suggest that you do a basic C course just yesterday?
Paul Bolle
^ permalink raw reply
* Re: [kernel-hardening] Re: HalfSipHash Acceptable Usage
From: Jason A. Donenfeld @ 2016-12-21 22:29 UTC (permalink / raw)
To: kernel-hardening, Theodore Ts'o, George Spelvin, Eric Dumazet,
Jason, Andi Kleen, David Miller, David Laight,
Daniel J . Bernstein, Eric Biggers, Hannes Frederic Sowa,
Jean-Philippe Aumasson, Linux Crypto Mailing List, LKML,
Andy Lutomirski, Netdev, Tom Herbert, Linus Torvalds,
Vegard Nossum
On Wed, Dec 21, 2016 at 11:27 PM, Theodore Ts'o <tytso@mit.edu> wrote:
> And "with enough registers" includes ARM and MIPS, right? So the only
> real problem is 32-bit x86, and you're right, at that point, only
> people who might care are people who are using a space-radiation
> hardened 386 --- and they're not likely to be doing high throughput
> TCP connections. :-)
Plus the benchmark was bogus anyway, and when I built a more specific
harness -- actually comparing the TCP sequence number functions --
SipHash was faster than MD5, even on register starved x86. So I think
we're fine and this chapter of the discussion can come to a close, in
order to move on to more interesting things.
^ permalink raw reply
* Re: HalfSipHash Acceptable Usage
From: Theodore Ts'o @ 2016-12-21 22:27 UTC (permalink / raw)
To: George Spelvin
Cc: eric.dumazet, Jason, ak, davem, David.Laight, djb, ebiggers3,
hannes, jeanphilippe.aumasson, kernel-hardening, linux-crypto,
linux-kernel, luto, netdev, tom, torvalds, vegard.nossum
In-Reply-To: <20161221183751.1123.qmail@ns.sciencehorizons.net>
On Wed, Dec 21, 2016 at 01:37:51PM -0500, George Spelvin wrote:
> SipHash annihilates the competition on 64-bit superscalar hardware.
> SipHash dominates the field on 64-bit in-order hardware.
> SipHash wins easily on 32-bit hardware *with enough registers*.
> On register-starved 32-bit machines, it really struggles.
And "with enough registers" includes ARM and MIPS, right? So the only
real problem is 32-bit x86, and you're right, at that point, only
people who might care are people who are using a space-radiation
hardened 386 --- and they're not likely to be doing high throughput
TCP connections. :-)
- Ted
^ permalink raw reply
* [PATCH 2/2] net: wireless: fix to uses struct
From: Ozgur Karatas @ 2016-12-21 22:23 UTC (permalink / raw)
To: johannes, David Miller; +Cc: linux-wireless, netdev, linux-kernel
The patch fixed to struct uses in reg.c, I think doesn't need to be use to "struct".
There is dataype not have to logical link and each is different definitons.
I'm undecided on this patch. I compiled and didn't to errors.
Signed-off-by: Ozgur Karatas <okaratas@member.fsf.org>
---
net/wireless/reg.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 5dbac37..5b70970 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -490,7 +490,7 @@ static int reg_query_builtin(const char *alpha2)
if (!regdom)
return -ENODATA;
- request = kzalloc(sizeof(struct reg_regdb_apply_request), GFP_KERNEL);
+ request = kzalloc(sizeof(*reg_regdb_apply_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
@@ -2291,7 +2291,7 @@ static int regulatory_hint_core(const char *alpha2)
{
struct regulatory_request *request;
- request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+ request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
@@ -2313,7 +2313,7 @@ int regulatory_hint_user(const char *alpha2,
if (WARN_ON(!alpha2))
return -EINVAL;
- request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+ request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
@@ -2385,7 +2385,7 @@ int regulatory_hint(struct wiphy *wiphy, const char *alpha2)
wiphy->regulatory_flags &= ~REGULATORY_CUSTOM_REG;
- request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+ request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
@@ -2661,7 +2661,7 @@ int regulatory_hint_found_beacon(struct wiphy *wiphy,
if (processing)
return 0;
- reg_beacon = kzalloc(sizeof(struct reg_beacon), gfp);
+ reg_beacon = kzalloc(sizeof(*reg_beacon), gfp);
if (!reg_beacon)
return -ENOMEM;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH net] ipvlan: fix various issues in ipvlan_process_multicast()
From: Mahesh Bandewar (महेश बंडेवार) @ 2016-12-21 22:21 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1482355800.8944.75.camel@edumazet-glaptop3.roam.corp.google.com>
On Wed, Dec 21, 2016 at 1:30 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> 1) netif_rx() / dev_forward_skb() should not be called from process
> context.
>
> 2) ipvlan_count_rx() should be called with preemption disabled.
>
> 3) We should check if ipvlan->dev is up before feeding packets
> to netif_rx()
>
> 4) We need to prevent device from disappearing if some packets
> are in the multicast backlog.
>
> 5) One kfree_skb() should be a consume_skb() eventually
>
Thank you Eric for all these fixes.
> Fixes: ba35f8588f47 ("ipvlan: Defer multicast / broadcast processing to a work-queue")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Mahesh Bandewar <maheshb@google.com>
> Cc: Mahesh Bandewar <maheshb@google.com>
> ---
> drivers/net/ipvlan/ipvlan_core.c | 38 +++++++++++++++++++----------
> 1 file changed, 25 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/net/ipvlan/ipvlan_core.c b/drivers/net/ipvlan/ipvlan_core.c
> index b4e990743e1da0cb3a946f5473d02cce7447bd1a..ea6bc1e12cdf6827a69d8d54d96b4b59106ede96 100644
> --- a/drivers/net/ipvlan/ipvlan_core.c
> +++ b/drivers/net/ipvlan/ipvlan_core.c
> @@ -207,6 +207,9 @@ void ipvlan_process_multicast(struct work_struct *work)
> spin_unlock_bh(&port->backlog.lock);
>
> while ((skb = __skb_dequeue(&list)) != NULL) {
> + struct net_device *dev = skb->dev;
> + bool consumed = false;
> +
> ethh = eth_hdr(skb);
> hlocal = ether_addr_equal(ethh->h_source, port->dev->dev_addr);
> mac_hash = ipvlan_mac_hash(ethh->h_dest);
> @@ -219,27 +222,29 @@ void ipvlan_process_multicast(struct work_struct *work)
> dlocal = false;
> rcu_read_lock();
> list_for_each_entry_rcu(ipvlan, &port->ipvlans, pnode) {
> - if (hlocal && (ipvlan->dev == skb->dev)) {
> + if (hlocal && (ipvlan->dev == dev)) {
> dlocal = true;
> continue;
> }
> if (!test_bit(mac_hash, ipvlan->mac_filters))
> continue;
> -
> + if (!(ipvlan->dev->flags & IFF_UP))
> + continue;
> ret = NET_RX_DROP;
> len = skb->len + ETH_HLEN;
> nskb = skb_clone(skb, GFP_ATOMIC);
> - if (!nskb)
> - goto acct;
> -
> - nskb->pkt_type = pkt_type;
> - nskb->dev = ipvlan->dev;
> - if (hlocal)
> - ret = dev_forward_skb(ipvlan->dev, nskb);
> - else
> - ret = netif_rx(nskb);
> -acct:
> + local_bh_disable();
> + if (nskb) {
> + consumed = true;
> + nskb->pkt_type = pkt_type;
> + nskb->dev = ipvlan->dev;
> + if (hlocal)
> + ret = dev_forward_skb(ipvlan->dev, nskb);
> + else
> + ret = netif_rx(nskb);
> + }
> ipvlan_count_rx(ipvlan, len, ret == NET_RX_SUCCESS, true);
> + local_bh_enable();
> }
> rcu_read_unlock();
>
> @@ -249,8 +254,13 @@ void ipvlan_process_multicast(struct work_struct *work)
> skb->pkt_type = pkt_type;
> dev_queue_xmit(skb);
> } else {
> - kfree_skb(skb);
> + if (consumed)
> + consume_skb(skb);
> + else
> + kfree_skb(skb);
> }
> + if (dev)
> + dev_put(dev);
> }
> }
>
> @@ -479,6 +489,8 @@ static void ipvlan_multicast_enqueue(struct ipvl_port *port,
>
> spin_lock(&port->backlog.lock);
> if (skb_queue_len(&port->backlog) < IPVLAN_QBACKLOG_LIMIT) {
> + if (skb->dev)
> + dev_hold(skb->dev);
> __skb_queue_tail(&port->backlog, skb);
> spin_unlock(&port->backlog.lock);
> schedule_work(&port->wq);
>
>
^ permalink raw reply
* [PATCH 1/2] net: wireless: fixed to checkpatch errors
From: Ozgur Karatas @ 2016-12-21 22:13 UTC (permalink / raw)
To: johannes, David Miller; +Cc: linux-wireless, netdev, linux-kernel
Fixed to checkpatch errors, Normally, comment's */ had to be finish on the next line.
The patch fix to readability and Coding Style.
Sİgned-off-by: Ozgur Karatas <okaratas@member.fsf.org>
---
net/wireless/chan.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index 5497d022..8c7ac7f 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -891,7 +891,8 @@ cfg80211_get_chan_state(struct wireless_dev *wdev,
: CHAN_MODE_EXCLUSIVE;
/* consider worst-case - IBSS can try to return to the
- * original user-specified channel as creator */
+ * original user-specified channel as creator
+ */
if (wdev->ibss_dfs_possible)
*radar_detect |= BIT(wdev->chandef.width);
return;
--
2.1.4
^ permalink raw reply related
* Re: ipv6: handle -EFAULT from skb_copy_bits
From: Hannes Frederic Sowa @ 2016-12-21 21:33 UTC (permalink / raw)
To: David Miller; +Cc: xiyou.wangcong, davej, netdev
In-Reply-To: <20161221.140431.1651188849352763159.davem@davemloft.net>
On Wed, 2016-12-21 at 14:04 -0500, David Miller wrote:
> From: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Date: Wed, 21 Dec 2016 13:41:13 +0100
>
> > On Wed, 2016-12-21 at 13:27 +0100, Hannes Frederic Sowa wrote:
> >> @@ -555,8 +566,8 @@ static int rawv6_push_pending_frames(struct sock *sk, struct flowi6 *fl6,
> >> goto out;
> >>
> >> offset = rp->offset;
> >> - total_len = inet_sk(sk)->cork.base.length;
> >> - if (offset >= total_len - 1) {
> >> + transport_len = raw6_corked_transport_len(sk);
> >> + if (offset >= transport_len - 1) {
> >> err = -EINVAL;
> >> ip6_flush_pending_frames(sk);
> >> goto out;
> >> @@ -598,7 +609,7 @@ static int rawv6_push_pending_frames(struct sock *sk, struct flowi6 *fl6,
> >> tmp_csum = csum_sub(tmp_csum, csum_unfold(csum));
> >>
> >> csum = csum_ipv6_magic(&fl6->saddr, &fl6->daddr,
> >> - total_len, fl6->flowi6_proto, tmp_csum);
> >> + transport_len, fl6->flowi6_proto, tmp_csum);
> >>
> >>
> >
> > Ops, here we need actually the total_len plus the opt->opt_nflen to
> > always calculate the correct checksum.
>
> It's a real shame we can't just use skb_transport_offset(). This value
> has essentially been calculated for us already.
This code path is called when we want to send out the socket write
queue. Because of MSG_MORE we might have multiple skbs in there, but
only the first one actually carries the true header, the others are
optimized for the ipv6 fragmentation fast path, thus we need to use
skb_transport_offset to find the correct offset but we must not
touch/read the data area before, as it is undefined data at that point.
Basically total_len so far accumulated all the payload length written
to the socket from the syscall argument from the user, but
unfortunately it also accounts for the first sendmsg's synthesized
extension header length in the write queue. We need to reverse this
calculation at this point in time.
So total_len is independent from the loop we do below and the length
should always reflect the length of all skbs stored in the write queue.
The loop adjusts the offset of the checksum in case the checksum offset
points to data in one of the later skbs, but we know before if that can
happen or not because of the cork length.
> Also, if we iterate over multiple SKBs in the write queue, don't you have
> to redo this calculation for every SKB we iterate over?
All the skb's payload length are summed up in the cork's length field,
so we don't need to sum it up again but just can use that value as is
minus the extension header adjustment.
> Furthermore, what if the user queued up some SKBs in the raw socket
> with MSG_MORE, and then changed some of the options for a subsequent
> sendmsg() call?
We only refresh the extension headers the next time we prepare an ipv6
header, which is the first sendmsg after one without MSG_MORE. We are
protected in this situation and don't change header lengths later
during further MSG_MORE sendmsgs.
> Given all of this, I think the best thing to do is validate the offset
> after the queue walks, which is pretty much what Dave Jones's original
> patch was doing.
I think both approaches protect against the bug reasonably well, but
Dave's patch has a bug: we must either call ip6_flush_pending_frames to
clear the socket write queue with the buggy send request.
> Sigh... well, at least we now understand what's going on here.
Yep, the code is more than a bit complex. :/
Bye,
Hannes
^ permalink raw reply
* [PATCH net] ipvlan: fix various issues in ipvlan_process_multicast()
From: Eric Dumazet @ 2016-12-21 21:30 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Mahesh Bandewar
From: Eric Dumazet <edumazet@google.com>
1) netif_rx() / dev_forward_skb() should not be called from process
context.
2) ipvlan_count_rx() should be called with preemption disabled.
3) We should check if ipvlan->dev is up before feeding packets
to netif_rx()
4) We need to prevent device from disappearing if some packets
are in the multicast backlog.
5) One kfree_skb() should be a consume_skb() eventually
Fixes: ba35f8588f47 ("ipvlan: Defer multicast / broadcast processing to a work-queue")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Mahesh Bandewar <maheshb@google.com>
---
drivers/net/ipvlan/ipvlan_core.c | 38 +++++++++++++++++++----------
1 file changed, 25 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ipvlan/ipvlan_core.c b/drivers/net/ipvlan/ipvlan_core.c
index b4e990743e1da0cb3a946f5473d02cce7447bd1a..ea6bc1e12cdf6827a69d8d54d96b4b59106ede96 100644
--- a/drivers/net/ipvlan/ipvlan_core.c
+++ b/drivers/net/ipvlan/ipvlan_core.c
@@ -207,6 +207,9 @@ void ipvlan_process_multicast(struct work_struct *work)
spin_unlock_bh(&port->backlog.lock);
while ((skb = __skb_dequeue(&list)) != NULL) {
+ struct net_device *dev = skb->dev;
+ bool consumed = false;
+
ethh = eth_hdr(skb);
hlocal = ether_addr_equal(ethh->h_source, port->dev->dev_addr);
mac_hash = ipvlan_mac_hash(ethh->h_dest);
@@ -219,27 +222,29 @@ void ipvlan_process_multicast(struct work_struct *work)
dlocal = false;
rcu_read_lock();
list_for_each_entry_rcu(ipvlan, &port->ipvlans, pnode) {
- if (hlocal && (ipvlan->dev == skb->dev)) {
+ if (hlocal && (ipvlan->dev == dev)) {
dlocal = true;
continue;
}
if (!test_bit(mac_hash, ipvlan->mac_filters))
continue;
-
+ if (!(ipvlan->dev->flags & IFF_UP))
+ continue;
ret = NET_RX_DROP;
len = skb->len + ETH_HLEN;
nskb = skb_clone(skb, GFP_ATOMIC);
- if (!nskb)
- goto acct;
-
- nskb->pkt_type = pkt_type;
- nskb->dev = ipvlan->dev;
- if (hlocal)
- ret = dev_forward_skb(ipvlan->dev, nskb);
- else
- ret = netif_rx(nskb);
-acct:
+ local_bh_disable();
+ if (nskb) {
+ consumed = true;
+ nskb->pkt_type = pkt_type;
+ nskb->dev = ipvlan->dev;
+ if (hlocal)
+ ret = dev_forward_skb(ipvlan->dev, nskb);
+ else
+ ret = netif_rx(nskb);
+ }
ipvlan_count_rx(ipvlan, len, ret == NET_RX_SUCCESS, true);
+ local_bh_enable();
}
rcu_read_unlock();
@@ -249,8 +254,13 @@ void ipvlan_process_multicast(struct work_struct *work)
skb->pkt_type = pkt_type;
dev_queue_xmit(skb);
} else {
- kfree_skb(skb);
+ if (consumed)
+ consume_skb(skb);
+ else
+ kfree_skb(skb);
}
+ if (dev)
+ dev_put(dev);
}
}
@@ -479,6 +489,8 @@ static void ipvlan_multicast_enqueue(struct ipvl_port *port,
spin_lock(&port->backlog.lock);
if (skb_queue_len(&port->backlog) < IPVLAN_QBACKLOG_LIMIT) {
+ if (skb->dev)
+ dev_hold(skb->dev);
__skb_queue_tail(&port->backlog, skb);
spin_unlock(&port->backlog.lock);
schedule_work(&port->wq);
^ permalink raw reply related
* Re: [PATCH net] net, sched: fix soft lockup in tc_classify
From: Daniel Borkmann @ 2016-12-21 21:07 UTC (permalink / raw)
To: Cong Wang
Cc: David Miller, Shahar Klein, Or Gerlitz, Roi Dayan, Jiri Pirko,
John Fastabend, Linux Kernel Network Developers
In-Reply-To: <CAM_iQpUEUmJpjQYV7HV+4NVtGe6D-yZs6=YizcDtf7dogkNR0Q@mail.gmail.com>
On 12/21/2016 09:47 PM, Cong Wang wrote:
> On Wed, Dec 21, 2016 at 12:02 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
>> On 12/21/2016 08:10 PM, Cong Wang wrote:
>>> On Wed, Dec 21, 2016 at 10:51 AM, Cong Wang <xiyou.wangcong@gmail.com>
>>> wrote:
>>>> On Wed, Dec 21, 2016 at 9:04 AM, Daniel Borkmann <daniel@iogearbox.net>
>>>> wrote:
>>>>>
>>>>> What happens is that in tc_ctl_tfilter(), thread A allocates a new
>>>>> tp, initializes it, sets tp_created to 1, and calls into
>>>>> tp->ops->change()
>>>>> with it. In that classifier callback we had to unlock/lock the rtnl
>>>>> mutex and returned with -EAGAIN. One reason why we need to drop there
>>>>> is, for example, that we need to request an action module to be loaded.
>>>>
>>>> Excellent catch!
>>>>
>>>> But why do we have to replay the request here? Shouldn't we just return
>>>> EAGAIN to user-space and let user-space decide to retry or not?
>>>> Replaying is the root of the evil here.
>>>
>>> Answer myself: probably due to historical reasons, but still replaying
>>> inside such a big function is just error-prone, we should promote it
>>> out:
>>
>> Have no strong opinion, I guess it could be done as a simplification
>> for net-next, why not, along with moving out the netlink_ns_capable()
>> check or possibly other things after careful analysis that don't need
>> to be redone in that circumstance.
>
> It is only slightly bigger than your current one so could fit for -stable too.
> Also, it could fix all potential problems like this one. Let compiler do the
> work, not human. ;)
Ok, you mean for net. In that case I prefer the smaller sized fix to be
honest. It also covers everything from the point where we fetch the chain
via cops->tcf_chain() to the end of the function, which is where most of
the complexity resides, and only the two mentioned commits do the relock,
so as a fix I think it's fine as-is. As mentioned, if there's need to
refactor tc_ctl_tfilter() net-next would be better, imho.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH] at86rf230: Allow slow GPIO pins for "rstn"
From: Stefan Schmidt @ 2016-12-21 21:01 UTC (permalink / raw)
To: Chris Healy
Cc: Alexander Aring, Andrey Smirnov, linux-kernel, netdev, linux-wpan
In-Reply-To: <CAFXsbZpgiTM2qngYERVpfXHvePW8M8DN91YnZwc-voKO=FDUUA@mail.gmail.com>
Hello.
On 21/12/16 19:30, Chris Healy wrote:
>
>
> On Dec 21, 2016 5:11 AM, "Stefan Schmidt" <stefan@osg.samsung.com
> <mailto:stefan@osg.samsung.com>> wrote:
>
> Hello.
>
>
> On 19/12/16 00:25, Andrey Smirnov wrote:
>
> Driver code never touches "rstn" signal in atomic context, so
> there's
> no need to implicitly put such restriction on it by using
> gpio_set_value
> to manipulate it. Replace gpio_set_value to
> gpio_set_value_cansleep to
> fix that.
>
>
> We need to make sure we are not assuming it can be called in such a
> context in the future now. But that is something we can worry about
> if it comes up.
>
>
> As a an example of where such restriction might be inconvenient,
> consider a hardware design where "rstn" is connected to a pin of
> I2C/SPI
> GPIO expander chip.
>
>
> Is this a real life issue you run into?
>
>
> I have a platform with this configuration. The DTS for the platform is
> in the process of being mainlined right now.
Thanks for letting us know. What platform is that? I'm always interested
in hearing about devices that use the Linux ieee802154 subsystem. :)
regards
Stefan Schmidt
^ permalink raw reply
* Re: [PATCH net] net, sched: fix soft lockup in tc_classify
From: Cong Wang @ 2016-12-21 20:47 UTC (permalink / raw)
To: Daniel Borkmann
Cc: David Miller, Shahar Klein, Or Gerlitz, Roi Dayan, Jiri Pirko,
John Fastabend, Linux Kernel Network Developers
In-Reply-To: <585ADFEB.3030206@iogearbox.net>
On Wed, Dec 21, 2016 at 12:02 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 12/21/2016 08:10 PM, Cong Wang wrote:
>>
>> On Wed, Dec 21, 2016 at 10:51 AM, Cong Wang <xiyou.wangcong@gmail.com>
>> wrote:
>>>
>>> On Wed, Dec 21, 2016 at 9:04 AM, Daniel Borkmann <daniel@iogearbox.net>
>>> wrote:
>>>>
>>>> What happens is that in tc_ctl_tfilter(), thread A allocates a new
>>>> tp, initializes it, sets tp_created to 1, and calls into
>>>> tp->ops->change()
>>>> with it. In that classifier callback we had to unlock/lock the rtnl
>>>> mutex and returned with -EAGAIN. One reason why we need to drop there
>>>> is, for example, that we need to request an action module to be loaded.
>>>
>>>
>>> Excellent catch!
>>>
>>> But why do we have to replay the request here? Shouldn't we just return
>>> EAGAIN to user-space and let user-space decide to retry or not?
>>> Replaying is the root of the evil here.
>>
>>
>> Answer myself: probably due to historical reasons, but still replaying
>> inside such a big function is just error-prone, we should promote it
>> out:
>
>
> Have no strong opinion, I guess it could be done as a simplification
> for net-next, why not, along with moving out the netlink_ns_capable()
> check or possibly other things after careful analysis that don't need
> to be redone in that circumstance.
It is only slightly bigger than your current one so could fit for -stable too.
Also, it could fix all potential problems like this one. Let compiler do the
work, not human. ;)
^ permalink raw reply
* Re: [PATCH] net: fddi: skfp: use %p format specifier for addresses rather than %x
From: David Miller @ 2016-12-21 20:35 UTC (permalink / raw)
To: colin.king; +Cc: netdev, linux-kernel
In-Reply-To: <20161221160323.27780-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Wed, 21 Dec 2016 16:03:23 +0000
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix: Addresses should be printed using the %p format specifier
> rather than using %x.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* [PATCH v4 3/3] Bluetooth: btusb: Configure Marvell to use one of the pins for oob wakeup
From: Rajat Jain @ 2016-12-21 20:33 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Marcel Holtmann, Gustavo Padovan,
Johan Hedberg, Amitkumar Karwar, Wei-Ning Huang, Xinming Hu,
netdev, devicetree, linux-bluetooth, Brian Norris, linux-kernel
Cc: Rajat Jain, rajatxjain
In-Reply-To: <1482352432-38302-1-git-send-email-rajatja@google.com>
The Marvell devices may have many gpio pins, and hence for wakeup
on these out-of-band pins, the chip needs to be told which pin is
to be used for wakeup, using an hci command.
Thus, we read the pin number etc from the device tree node and send
a command to the chip.
Signed-off-by: Rajat Jain <rajatja@google.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Acked-by: Rob Herring <robh@kernel.org>
---
v4: same as v3
v3: * remove the Marvell specific id table and check
* Add reference to marvell-bt-8xxx.txt in btusb.txt
* Add "Reviewed-by" and "Acked-by"
v2: Fix the binding document to specify to use "wakeup" interrupt-name
Documentation/devicetree/bindings/net/btusb.txt | 3 ++
.../{marvell-bt-sd8xxx.txt => marvell-bt-8xxx.txt} | 46 +++++++++++++++----
drivers/bluetooth/btusb.c | 51 ++++++++++++++++++++++
3 files changed, 92 insertions(+), 8 deletions(-)
rename Documentation/devicetree/bindings/net/{marvell-bt-sd8xxx.txt => marvell-bt-8xxx.txt} (50%)
diff --git a/Documentation/devicetree/bindings/net/btusb.txt b/Documentation/devicetree/bindings/net/btusb.txt
index 2c0355c..01fa2d4 100644
--- a/Documentation/devicetree/bindings/net/btusb.txt
+++ b/Documentation/devicetree/bindings/net/btusb.txt
@@ -10,6 +10,9 @@ Required properties:
"usb1286,204e" (Marvell 8997)
+Also, vendors that use btusb may have device additional properties, e.g:
+Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
+
Optional properties:
- interrupt-parent: phandle of the parent interrupt controller
diff --git a/Documentation/devicetree/bindings/net/marvell-bt-sd8xxx.txt b/Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
similarity index 50%
rename from Documentation/devicetree/bindings/net/marvell-bt-sd8xxx.txt
rename to Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
index 6a9a63c..9be1059 100644
--- a/Documentation/devicetree/bindings/net/marvell-bt-sd8xxx.txt
+++ b/Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
@@ -1,16 +1,21 @@
-Marvell 8897/8997 (sd8897/sd8997) bluetooth SDIO devices
+Marvell 8897/8997 (sd8897/sd8997) bluetooth devices (SDIO or USB based)
------
+The 8997 devices supports multiple interfaces. When used on SDIO interfaces,
+the btmrvl driver is used and when used on USB interface, the btusb driver is
+used.
Required properties:
- compatible : should be one of the following:
- * "marvell,sd8897-bt"
- * "marvell,sd8997-bt"
+ * "marvell,sd8897-bt" (for SDIO)
+ * "marvell,sd8997-bt" (for SDIO)
+ * "usb1286,204e" (for USB)
Optional properties:
- marvell,cal-data: Calibration data downloaded to the device during
initialization. This is an array of 28 values(u8).
+ This is only applicable to SDIO devices.
- marvell,wakeup-pin: It represents wakeup pin number of the bluetooth chip.
firmware will use the pin to wakeup host system (u16).
@@ -18,10 +23,15 @@ Optional properties:
platform. The value will be configured to firmware. This
is needed to work chip's sleep feature as expected (u16).
- interrupt-parent: phandle of the parent interrupt controller
- - interrupts : interrupt pin number to the cpu. Driver will request an irq based
- on this interrupt number. During system suspend, the irq will be
- enabled so that the bluetooth chip can wakeup host platform under
- certain condition. During system resume, the irq will be disabled
+ - interrupt-names: Used only for USB based devices (See below)
+ - interrupts : specifies the interrupt pin number to the cpu. For SDIO, the
+ driver will use the first interrupt specified in the interrupt
+ array. For USB based devices, the driver will use the interrupt
+ named "wakeup" from the interrupt-names and interrupt arrays.
+ The driver will request an irq based on this interrupt number.
+ During system suspend, the irq will be enabled so that the
+ bluetooth chip can wakeup host platform under certain
+ conditions. During system resume, the irq will be disabled
to make sure unnecessary interrupt is not received.
Example:
@@ -29,7 +39,9 @@ Example:
IRQ pin 119 is used as system wakeup source interrupt.
wakeup pin 13 and gap 100ms are configured so that firmware can wakeup host
using this device side pin and wakeup latency.
-calibration data is also available in below example.
+
+Example for SDIO device follows (calibration data is also available in
+below example).
&mmc3 {
status = "okay";
@@ -54,3 +66,21 @@ calibration data is also available in below example.
marvell,wakeup-gap-ms = /bits/ 16 <0x64>;
};
};
+
+Example for USB device:
+
+&usb_host1_ohci {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mvl_bt1: bt@1 {
+ compatible = "usb1286,204e";
+ reg = <1>;
+ interrupt-parent = <&gpio0>;
+ interrupt-names = "wakeup";
+ interrupts = <119 IRQ_TYPE_LEVEL_LOW>;
+ marvell,wakeup-pin = /bits/ 16 <0x0d>;
+ marvell,wakeup-gap-ms = /bits/ 16 <0x64>;
+ };
+};
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 2b45f1c..91dcd8a 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -2343,6 +2343,50 @@ static int btusb_shutdown_intel(struct hci_dev *hdev)
return 0;
}
+#ifdef CONFIG_PM
+/* Configure an out-of-band gpio as wake-up pin, if specified in device tree */
+static int marvell_config_oob_wake(struct hci_dev *hdev)
+{
+ struct sk_buff *skb;
+ struct btusb_data *data = hci_get_drvdata(hdev);
+ struct device *dev = &data->udev->dev;
+ u16 pin, gap, opcode;
+ int ret;
+ u8 cmd[5];
+
+ /* Move on if no wakeup pin specified */
+ if (of_property_read_u16(dev->of_node, "marvell,wakeup-pin", &pin) ||
+ of_property_read_u16(dev->of_node, "marvell,wakeup-gap-ms", &gap))
+ return 0;
+
+ /* Vendor specific command to configure a GPIO as wake-up pin */
+ opcode = hci_opcode_pack(0x3F, 0x59);
+ cmd[0] = opcode & 0xFF;
+ cmd[1] = opcode >> 8;
+ cmd[2] = 2; /* length of parameters that follow */
+ cmd[3] = pin;
+ cmd[4] = gap; /* time in ms, for which wakeup pin should be asserted */
+
+ skb = bt_skb_alloc(sizeof(cmd), GFP_KERNEL);
+ if (!skb) {
+ bt_dev_err(hdev, "%s: No memory\n", __func__);
+ return -ENOMEM;
+ }
+
+ memcpy(skb_put(skb, sizeof(cmd)), cmd, sizeof(cmd));
+ hci_skb_pkt_type(skb) = HCI_COMMAND_PKT;
+
+ ret = btusb_send_frame(hdev, skb);
+ if (ret) {
+ bt_dev_err(hdev, "%s: configuration failed\n", __func__);
+ kfree_skb(skb);
+ return ret;
+ }
+
+ return 0;
+}
+#endif
+
static int btusb_set_bdaddr_marvell(struct hci_dev *hdev,
const bdaddr_t *bdaddr)
{
@@ -2917,6 +2961,13 @@ static int btusb_probe(struct usb_interface *intf,
err = btusb_config_oob_wake(hdev);
if (err)
goto out_free_dev;
+
+ /* Marvell devices may need a specific chip configuration */
+ if (id->driver_info & BTUSB_MARVELL && data->oob_wake_irq) {
+ err = marvell_config_oob_wake(hdev);
+ if (err)
+ goto out_free_dev;
+ }
#endif
if (id->driver_info & BTUSB_CW6622)
set_bit(HCI_QUIRK_BROKEN_STORED_LINK_KEY, &hdev->quirks);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH v4 2/3] Bluetooth: btusb: Add out-of-band wakeup support
From: Rajat Jain @ 2016-12-21 20:33 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Marcel Holtmann, Gustavo Padovan,
Johan Hedberg, Amitkumar Karwar, Wei-Ning Huang, Xinming Hu,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA, Brian Norris,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Rajat Jain, rajatxjain-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1482352432-38302-1-git-send-email-rajatja-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Some onboard BT chips (e.g. Marvell 8997) contain a wakeup pin that
can be connected to a gpio on the CPU side, and can be used to wakeup
the host out-of-band. This can be useful in situations where the
in-band wakeup is not possible or not preferable (e.g. the in-band
wakeup may require the USB host controller to remain active, and
hence consuming more system power during system sleep).
The oob gpio interrupt to be used for wakeup on the CPU side, is
read from the device tree node, (using standard interrupt descriptors).
A devcie tree binding document is also added for the driver. The
compatible string is in compliance with
Documentation/devicetree/bindings/usb/usb-device.txt
Signed-off-by: Rajat Jain <rajatja-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Reviewed-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
v4: Move the set_bit(BTUSB_OOB_WAKE_DISABLED,..) call to the beginning of
btusb_config_oob_wake() - caught by Brian.
v3: Add Brian's "Reviewed-by"
v2: * Use interrupt-names ("wakeup") instead of assuming first interrupt.
* Leave it on device tree to specify IRQ flags (level /edge triggered)
* Mark the device as non wakeable on exit.
Documentation/devicetree/bindings/net/btusb.txt | 40 ++++++++++++
drivers/bluetooth/btusb.c | 84 +++++++++++++++++++++++++
2 files changed, 124 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/btusb.txt
diff --git a/Documentation/devicetree/bindings/net/btusb.txt b/Documentation/devicetree/bindings/net/btusb.txt
new file mode 100644
index 0000000..2c0355c
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/btusb.txt
@@ -0,0 +1,40 @@
+Generic Bluetooth controller over USB (btusb driver)
+---------------------------------------------------
+
+Required properties:
+
+ - compatible : should comply with the format "usbVID,PID" specified in
+ Documentation/devicetree/bindings/usb/usb-device.txt
+ At the time of writing, the only OF supported devices
+ (more may be added later) are:
+
+ "usb1286,204e" (Marvell 8997)
+
+Optional properties:
+
+ - interrupt-parent: phandle of the parent interrupt controller
+ - interrupt-names: (see below)
+ - interrupts : The interrupt specified by the name "wakeup" is the interrupt
+ that shall be used for out-of-band wake-on-bt. Driver will
+ request this interrupt for wakeup. During system suspend, the
+ irq will be enabled so that the bluetooth chip can wakeup host
+ platform out of band. During system resume, the irq will be
+ disabled to make sure unnecessary interrupt is not received.
+
+Example:
+
+Following example uses irq pin number 3 of gpio0 for out of band wake-on-bt:
+
+&usb_host1_ehci {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mvl_bt1: bt@1 {
+ compatible = "usb1286,204e";
+ reg = <1>;
+ interrupt-parent = <&gpio0>;
+ interrupt-name = "wakeup";
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+ };
+};
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index ce22cef..2b45f1c 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -24,6 +24,8 @@
#include <linux/module.h>
#include <linux/usb.h>
#include <linux/firmware.h>
+#include <linux/of_device.h>
+#include <linux/of_irq.h>
#include <asm/unaligned.h>
#include <net/bluetooth/bluetooth.h>
@@ -369,6 +371,7 @@ static const struct usb_device_id blacklist_table[] = {
#define BTUSB_BOOTING 9
#define BTUSB_RESET_RESUME 10
#define BTUSB_DIAG_RUNNING 11
+#define BTUSB_OOB_WAKE_DISABLED 12
struct btusb_data {
struct hci_dev *hdev;
@@ -416,6 +419,8 @@ struct btusb_data {
int (*recv_bulk)(struct btusb_data *data, void *buffer, int count);
int (*setup_on_usb)(struct hci_dev *hdev);
+
+ int oob_wake_irq; /* irq for out-of-band wake-on-bt */
};
static inline void btusb_free_frags(struct btusb_data *data)
@@ -2728,6 +2733,65 @@ static int btusb_bcm_set_diag(struct hci_dev *hdev, bool enable)
}
#endif
+#ifdef CONFIG_PM
+static irqreturn_t btusb_oob_wake_handler(int irq, void *priv)
+{
+ struct btusb_data *data = priv;
+
+ /* Disable only if not already disabled (keep it balanced) */
+ if (!test_and_set_bit(BTUSB_OOB_WAKE_DISABLED, &data->flags)) {
+ disable_irq_nosync(irq);
+ disable_irq_wake(irq);
+ }
+ pm_wakeup_event(&data->udev->dev, 0);
+ return IRQ_HANDLED;
+}
+
+static const struct of_device_id btusb_match_table[] = {
+ { .compatible = "usb1286,204e" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, btusb_match_table);
+
+/* Use an oob wakeup pin? */
+static int btusb_config_oob_wake(struct hci_dev *hdev)
+{
+ struct btusb_data *data = hci_get_drvdata(hdev);
+ struct device *dev = &data->udev->dev;
+ int irq, ret;
+
+ set_bit(BTUSB_OOB_WAKE_DISABLED, &data->flags);
+
+ if (!of_match_device(btusb_match_table, dev))
+ return 0;
+
+ /* Move on if no IRQ specified */
+ irq = of_irq_get_byname(dev->of_node, "wakeup");
+ if (irq <= 0) {
+ bt_dev_dbg(hdev, "%s: no OOB Wakeup IRQ in DT", __func__);
+ return 0;
+ }
+
+ ret = devm_request_irq(&hdev->dev, irq, btusb_oob_wake_handler,
+ 0, "OOB Wake-on-BT", data);
+ if (ret) {
+ bt_dev_err(hdev, "%s: IRQ request failed", __func__);
+ return ret;
+ }
+
+ ret = device_init_wakeup(dev, true);
+ if (ret) {
+ bt_dev_err(hdev, "%s: failed to init_wakeup\n", __func__);
+ return ret;
+ }
+
+ data->oob_wake_irq = irq;
+ disable_irq(irq);
+ bt_dev_info(hdev, "OOB Wake-on-BT configured at IRQ %u\n", irq);
+ return 0;
+}
+#endif
+
static int btusb_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
@@ -2849,6 +2913,11 @@ static int btusb_probe(struct usb_interface *intf,
hdev->send = btusb_send_frame;
hdev->notify = btusb_notify;
+#ifdef CONFIG_PM
+ err = btusb_config_oob_wake(hdev);
+ if (err)
+ goto out_free_dev;
+#endif
if (id->driver_info & BTUSB_CW6622)
set_bit(HCI_QUIRK_BROKEN_STORED_LINK_KEY, &hdev->quirks);
@@ -3061,6 +3130,9 @@ static void btusb_disconnect(struct usb_interface *intf)
usb_driver_release_interface(&btusb_driver, data->isoc);
}
+ if (data->oob_wake_irq)
+ device_init_wakeup(&data->udev->dev, false);
+
hci_free_dev(hdev);
}
@@ -3089,6 +3161,12 @@ static int btusb_suspend(struct usb_interface *intf, pm_message_t message)
btusb_stop_traffic(data);
usb_kill_anchored_urbs(&data->tx_anchor);
+ if (data->oob_wake_irq && device_may_wakeup(&data->udev->dev)) {
+ clear_bit(BTUSB_OOB_WAKE_DISABLED, &data->flags);
+ enable_irq_wake(data->oob_wake_irq);
+ enable_irq(data->oob_wake_irq);
+ }
+
/* Optionally request a device reset on resume, but only when
* wakeups are disabled. If wakeups are enabled we assume the
* device will stay powered up throughout suspend.
@@ -3126,6 +3204,12 @@ static int btusb_resume(struct usb_interface *intf)
if (--data->suspend_count)
return 0;
+ /* Disable only if not already disabled (keep it balanced) */
+ if (!test_and_set_bit(BTUSB_OOB_WAKE_DISABLED, &data->flags)) {
+ disable_irq(data->oob_wake_irq);
+ disable_irq_wake(data->oob_wake_irq);
+ }
+
if (!test_bit(HCI_RUNNING, &hdev->flags))
goto done;
--
2.8.0.rc3.226.g39d4020
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 1/3] Bluetooth: btusb: Use an error label for error paths
From: Rajat Jain @ 2016-12-21 20:33 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Marcel Holtmann, Gustavo Padovan,
Johan Hedberg, Amitkumar Karwar, Wei-Ning Huang, Xinming Hu,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA, Brian Norris,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Rajat Jain, rajatxjain-Re5JQEeQqe8AvxtiuMwx3w
Use a label to remove the repetetive cleanup, for error cases.
Signed-off-by: Rajat Jain <rajatja-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Reviewed-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
v4: same as v3
v3: Added Brian's "Reviewed-by"
v2: same as v1
drivers/bluetooth/btusb.c | 19 +++++++++----------
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 2f633df..ce22cef 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -2991,18 +2991,15 @@ static int btusb_probe(struct usb_interface *intf,
err = usb_set_interface(data->udev, 0, 0);
if (err < 0) {
BT_ERR("failed to set interface 0, alt 0 %d", err);
- hci_free_dev(hdev);
- return err;
+ goto out_free_dev;
}
}
if (data->isoc) {
err = usb_driver_claim_interface(&btusb_driver,
data->isoc, data);
- if (err < 0) {
- hci_free_dev(hdev);
- return err;
- }
+ if (err < 0)
+ goto out_free_dev;
}
#ifdef CONFIG_BT_HCIBTUSB_BCM
@@ -3016,14 +3013,16 @@ static int btusb_probe(struct usb_interface *intf,
#endif
err = hci_register_dev(hdev);
- if (err < 0) {
- hci_free_dev(hdev);
- return err;
- }
+ if (err < 0)
+ goto out_free_dev;
usb_set_intfdata(intf, data);
return 0;
+
+out_free_dev:
+ hci_free_dev(hdev);
+ return err;
}
static void btusb_disconnect(struct usb_interface *intf)
--
2.8.0.rc3.226.g39d4020
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH net] tcp: add a missing barrier in tcp_tasklet_func()
From: David Miller @ 2016-12-21 20:31 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, edumazet, madalin.bucur
In-Reply-To: <1482327763.8944.26.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 21 Dec 2016 05:42:43 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> Madalin reported crashes happening in tcp_tasklet_func() on powerpc64
>
> Before TSQ_QUEUED bit is cleared, we must ensure the changes done
> by list_del(&tp->tsq_node); are committed to memory, otherwise
> corruption might happen, as an other cpu could catch TSQ_QUEUED
> clearance too soon.
>
> We can notice that old kernels were immune to this bug, because
> TSQ_QUEUED was cleared after a bh_lock_sock(sk)/bh_unlock_sock(sk)
> section, but they could have missed a kick to write additional bytes,
> when NIC interrupts for a given flow are spread to multiple cpus.
>
> Affected TCP flows would need an incoming ACK or RTO timer to add more
> packets to the pipe. So overall situation should be better now.
>
> Fixes: b223feb9de2a ("tcp: tsq: add shortcut in tcp_tasklet_func()")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Madalin Bucur <madalin.bucur@nxp.com>
> Tested-by: Madalin Bucur <madalin.bucur@nxp.com>
Applied, thanks Eric.
^ permalink raw reply
* BUG/panic in ctnetlink_conntrack_event in 4.8.11
From: Chris Boot @ 2016-12-21 20:20 UTC (permalink / raw)
To: Netfilter Development Mailing list
Cc: Linux Kernel Network Developers, coreteam, linux-kernel
Hi all,
I've encountered this BUG three times in the last few days, though I
must admit I've only captured the trace once so far so I can't be
completely certain it was exactly this the last few times. I did not
experience this with a 4.7 kernel; it only seemed to start with 4.8.
For some background: I use conntrackd (this is an "HA" firewall pair),
plenty of IPv6, IPsec with vti6 interfaces, conntrack, some NAT on IPv4
but definitely not with IPv6.
Without further ado, here is my crash:
[147965.209318] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
[147965.217347] IP: [<ffffffffb4bb8b19>] icmp6_send+0x229/0x9f0
[147965.223051] PGD 0
[147965.225184] Oops: 0000 [#1] SMP
[147965.228424] Modules linked in: sch_fq_codel sch_htb pppoe pppox ppp_generic slhc ip6_vti ip6_tunnel tunnel6 drbg ansi_cprng seqiv esp6 xfrm4_mode_tunnel xfrm6_mode_tunnel ghash_generic gcm twofish_generic twofish_x86_64_3way twofish_x86_64 twofish_common serpent_sse2_x86_64 serpent_generic blowfish_generic blowfish_x86_64 blowfish_common cast5_generic cast_common ctr des_generic cbc algif_skcipher camellia_generic camellia_x86_64 xts xcbc sha512_ssse3 sha512_generic md4 algif_hash af_alg xfrm_user xfrm4_tunnel tunnel4 ipcomp xfrm_ipcomp esp4 ah4 af_key xfrm_algo tun hmac xt_nat xt_policy xt_statistic xt_helper xt_CLASSIFY xt_recent ip6table_nat xt_dscp xt_length binfmt_misc ip6t_REJECT xt_hashlimit nf_reject_ipv6 ip6table_mangle xt_comment iptable_nat ipt_REJECT nf_reject_ipv4 xt_addrtype xt_set ip_set_hash_ip ip_set xt_connmark xt_mark iptable_mangle xt_tcpudp iptable_raw xt_CT ip6table_raw xt_multiport xt_conntrack nf_log_ipv4 nf_nat_tftp nf_nat_snmp_basic nf_conntrack_snmp xt_NFLOG nf_nat_sip xt_LOG nf_log_ipv6 nf_nat_pptp nf_log_common nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip nf_conntrack_proto_udplite nf_conntrack_proto_sctp nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp ip6table_filter ip6_tables iptable_filter openvswitch nf_conntrack_ipv6 nf_nat_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_defrag_ipv6 nf_nat nf_conntrack 8021q garp mrp stp llc dummy nfnetlink_log nfnetlink evdev kvm_amd kvm irqbypass pcspkr k10temp sp5100_tco i2c_piix4 sg shpchp acpi_cpufreq tpm_tis tpm_tis_core tpm button drbd lru_cache libcrc32c ip_tables x_tables autofs4 ext4 crc16 jbd2 crc32c_generic fscrypto ecb glue_helper lrw gf128mul ablk_helper cryptd aes_x86_64 mbcache dm_mod sd_mod uas usb_storage ohci_pci ehci_pci ohci_hcd ehci_hcd usbcore ahci libahci libata scsi_mod usb_common r8169 mii
[147965.409769] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0-2-amd64 #1 Debian 4.8.11-1
[147965.417773] Hardware name: PC Engines APU, BIOS SageBios_PCEngines_APU-45 04/05/2014
[147965.425607] task: ffff96d2d940aec0 task.stack: ffff96d2d9410000
[147965.431622] RIP: 0010:[<ffffffffb4bb8b19>] [<ffffffffb4bb8b19>] icmp6_send+0x229/0x9f0
[147965.439742] RSP: 0018:ffff96d2ded03d30 EFLAGS: 00010246
[147965.445150] RAX: 0000000000000000 RBX: ffff96d2861e1700 RCX: 0000000000000020
[147965.452377] RDX: 0000000000000001 RSI: 0000000000000200 RDI: ffff96d1cb42799e
[147965.459597] RBP: ffff96d2ded03e60 R08: 0000000000000000 R09: ffff96d299832000
[147965.466823] R10: 0000000000000001 R11: 0000000000000000 R12: ffff96d1cb427996
[147965.474042] R13: ffffffffb50da680 R14: 0000000000000000 R15: 0000000000000003
[147965.481263] FS: 0000000000000000(0000) GS:ffff96d2ded00000(0000) knlGS:0000000000000000
[147965.489444] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[147965.495283] CR2: 0000000000000018 CR3: 0000000116d59000 CR4: 00000000000006e0
[147965.502501] Stack:
[147965.504607] ffff96d291d14880 0000000000000000 ffff96d289288400 0000000000000000
[147965.512189] 0000000000000000 0000000000000000 ffff96d1cb42799e 0000000000000000
[147965.519772] 0000000000000001 ffff96d200000001 ffff96d1cb4279ae ffff96d280fb2900
[147965.527356] Call Trace:
[147965.529895] <IRQ>
[147965.531932] [<ffffffffc07330df>] ? ctnetlink_conntrack_event+0x3ff/0x620 [nf_conntrack_netlink]
[147965.541005] [<ffffffffc068e94a>] ? nf_nat_cleanup_conntrack+0xea/0x1a0 [nf_nat]
[147965.548492] [<ffffffffb4b74653>] ? get_frag_bucket_locked+0x43/0x70
[147965.554939] [<ffffffffc0696330>] ? nf_ct_net_init+0x130/0x130 [nf_defrag_ipv6]
[147965.562338] [<ffffffffb4bbff78>] ? ip6_expire_frag_queue+0xf8/0x100
[147965.568787] [<ffffffffb46e6e80>] ? call_timer_fn+0x30/0x120
[147965.574539] [<ffffffffb46e7406>] ? run_timer_softirq+0x216/0x4b0
[147965.580728] [<ffffffffb46f7ac0>] ? tick_sched_handle.isra.12+0x20/0x50
[147965.587434] [<ffffffffb46f7b28>] ? tick_sched_timer+0x38/0x70
[147965.593363] [<ffffffffb4bf2598>] ? __do_softirq+0xf8/0x290
[147965.599030] [<ffffffffb4681abb>] ? irq_exit+0x9b/0xa0
[147965.604266] [<ffffffffb4bf23ae>] ? smp_apic_timer_interrupt+0x3e/0x50
[147965.610884] [<ffffffffb4bf16c2>] ? apic_timer_interrupt+0x82/0x90
[147965.617155] <EOI>
[147965.619184] [<ffffffffb4ab0f06>] ? cpuidle_enter_state+0x126/0x2d0
[147965.625740] [<ffffffffb4ab0ef3>] ? cpuidle_enter_state+0x113/0x2d0
[147965.632100] [<ffffffffb46bd742>] ? cpu_startup_entry+0x2a2/0x350
[147965.638291] [<ffffffffb464eddd>] ? start_secondary+0x14d/0x190
[147965.644299] Code: 8b 44 24 38 75 46 f6 c2 02 74 05 f6 c2 30 75 3c 48 8b 43 58 4c 89 44 24 20 44 89 5c 24 38 44 89 54 24 40 89 54 24 48 48 83 e0 fe <48> 8b 78 18 e8 8e 88 02 00 8b 54 24 48 41 89 c1 44 8b 54 24 40
[147965.664907] RIP [<ffffffffb4bb8b19>] icmp6_send+0x229/0x9f0
[147965.670686] RSP <ffff96d2ded03d30>
[147965.674267] CR2: 0000000000000018
[147965.677683] ---[ end trace d5725bb00a2f3d6b ]---
[147965.682396] Kernel panic - not syncing: Fatal exception in interrupt
[147965.688898] Kernel Offset: 0x33600000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[147965.699764] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
[147965.707009] ------------[ cut here ]------------
[147965.711730] WARNING: CPU: 1 PID: 0 at /build/linux-lIgGMF/linux-4.8.11/arch/x86/kernel/smp.c:125 check_preempt_curr+0x50/0x90
[147965.723108] Modules linked in: sch_fq_codel sch_htb pppoe pppox ppp_generic slhc ip6_vti ip6_tunnel tunnel6 drbg ansi_cprng seqiv esp6 xfrm4_mode_tunnel xfrm6_mode_tunnel ghash_generic gcm twofish_generic twofish_x86_64_3way twofish_x86_64 twofish_common serpent_sse2_x86_64 serpent_generic blowfish_generic blowfish_x86_64 blowfish_common cast5_generic cast_common ctr des_generic cbc algif_skcipher camellia_generic camellia_x86_64 xts xcbc sha512_ssse3 sha512_generic md4 algif_hash af_alg xfrm_user xfrm4_tunnel tunnel4 ipcomp xfrm_ipcomp esp4 ah4 af_key xfrm_algo tun hmac xt_nat xt_policy xt_statistic xt_helper xt_CLASSIFY xt_recent ip6table_nat xt_dscp xt_length binfmt_misc ip6t_REJECT xt_hashlimit nf_reject_ipv6 ip6table_mangle xt_comment iptable_nat ipt_REJECT nf_reject_ipv4 xt_addrtype xt_set ip_set_hash_ip ip_set xt_connmark xt_mark iptable_mangle xt_tcpudp iptable_raw xt_CT ip6table_raw xt_multiport xt_conntrack nf_log_ipv4 nf_nat_tftp nf_nat_snmp_basic nf_conntrack_snmp xt_NFLOG nf_nat_sip xt_LOG nf_log_ipv6 nf_nat_pptp nf_log_common nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip nf_conntrack_proto_udplite nf_conntrack_proto_sctp nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp ip6table_filter ip6_tables iptable_filter openvswitch nf_conntrack_ipv6 nf_nat_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_defrag_ipv6 nf_nat nf_conntrack 8021q garp mrp stp llc dummy nfnetlink_log nfnetlink evdev kvm_amd kvm irqbypass pcspkr k10temp sp5100_tco i2c_piix4 sg shpchp acpi_cpufreq tpm_tis tpm_tis_core tpm button drbd lru_cache libcrc32c ip_tables x_tables autofs4 ext4 crc16 jbd2 crc32c_generic fscrypto ecb glue_helper lrw gf128mul ablk_helper cryptd aes_x86_64 mbcache dm_mod sd_mod uas usb_storage ohci_pci ehci_pci ohci_hcd ehci_hcd usbcore ahci libahci libata scsi_mod usb_common r8169 mii
[147965.904454] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 4.8.0-2-amd64 #1 Debian 4.8.11-1
[147965.913671] Hardware name: PC Engines APU, BIOS SageBios_PCEngines_APU-45 04/05/2014
[147965.921496] 0000000000000086 2c0493b5e5995666 ffffffffb49269f5 0000000000000000
[147965.929080] 0000000000000000 ffffffffb467c16e ffff96d2dec18180 ffff96d2c17fee40
[147965.936662] ffff96d2dec18180 0000000000000004 0000000000000046 ffff96d2dec18180
[147965.944244] Call Trace:
[147965.946786] <IRQ> [<ffffffffb49269f5>] ? dump_stack+0x5c/0x77
[147965.952830] [<ffffffffb467c16e>] ? __warn+0xbe/0xe0
[147965.957893] [<ffffffffb46a4720>] ? check_preempt_curr+0x50/0x90
[147965.963993] [<ffffffffb46a4774>] ? ttwu_do_wakeup+0x14/0xe0
[147965.969745] [<ffffffffb46a5441>] ? try_to_wake_up+0x191/0x3a0
[147965.975675] [<ffffffffb46bce93>] ? autoremove_wake_function+0x13/0x40
[147965.982293] [<ffffffffb46bc76e>] ? __wake_up_common+0x4e/0x90
[147965.988221] [<ffffffffb46bc7e4>] ? __wake_up+0x34/0x50
[147965.993545] [<ffffffffb475b943>] ? irq_work_run_list+0x43/0x70
[147965.999557] [<ffffffffb46318da>] ? smp_irq_work_interrupt+0x2a/0x30
[147966.006005] [<ffffffffb4bf2202>] ? irq_work_interrupt+0x82/0x90
[147966.012108] [<ffffffffb477a7b4>] ? panic+0x1e6/0x226
[147966.017254] [<ffffffffb477a7ad>] ? panic+0x1df/0x226
[147966.022404] [<ffffffffb462fa42>] ? oops_end+0xc2/0xd0
[147966.027635] [<ffffffffb46651e8>] ? no_context+0x128/0x370
[147966.033217] [<ffffffffb46a56d0>] ? wake_up_q+0x60/0x60
[147966.038538] [<ffffffffb4bf0e58>] ? page_fault+0x28/0x30
[147966.043948] [<ffffffffb4bb8b19>] ? icmp6_send+0x229/0x9f0
[147966.049532] [<ffffffffc07330df>] ? ctnetlink_conntrack_event+0x3ff/0x620 [nf_conntrack_netlink]
[147966.058404] [<ffffffffc068e94a>] ? nf_nat_cleanup_conntrack+0xea/0x1a0 [nf_nat]
[147966.065888] [<ffffffffb4b74653>] ? get_frag_bucket_locked+0x43/0x70
[147966.072340] [<ffffffffc0696330>] ? nf_ct_net_init+0x130/0x130 [nf_defrag_ipv6]
[147966.079738] [<ffffffffb4bbff78>] ? ip6_expire_frag_queue+0xf8/0x100
[147966.086186] [<ffffffffb46e6e80>] ? call_timer_fn+0x30/0x120
[147966.091941] [<ffffffffb46e7406>] ? run_timer_softirq+0x216/0x4b0
[147966.098127] [<ffffffffb46f7ac0>] ? tick_sched_handle.isra.12+0x20/0x50
[147966.104835] [<ffffffffb46f7b28>] ? tick_sched_timer+0x38/0x70
[147966.110764] [<ffffffffb4bf2598>] ? __do_softirq+0xf8/0x290
[147966.116431] [<ffffffffb4681abb>] ? irq_exit+0x9b/0xa0
[147966.121664] [<ffffffffb4bf23ae>] ? smp_apic_timer_interrupt+0x3e/0x50
[147966.128285] [<ffffffffb4bf16c2>] ? apic_timer_interrupt+0x82/0x90
[147966.134557] <EOI> [<ffffffffb4ab0f06>] ? cpuidle_enter_state+0x126/0x2d0
[147966.141555] [<ffffffffb4ab0ef3>] ? cpuidle_enter_state+0x113/0x2d0
[147966.147916] [<ffffffffb46bd742>] ? cpu_startup_entry+0x2a2/0x350
[147966.154103] [<ffffffffb464eddd>] ? start_secondary+0x14d/0x190
[147966.160117] ---[ end trace d5725bb00a2f3d6c ]---
Regards,
Chris
--
Chris Boot
bootc@bootc.net
^ permalink raw reply
* Re: [PATCH RFC net-next 3/7] sctp: add dst_pending_confirm flag
From: Julian Anastasov @ 2016-12-21 20:19 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev, linux-sctp, YueHaibing
In-Reply-To: <20161221141108.GB23197@hmsreliant.think-freely.org>
Hello,
On Wed, 21 Dec 2016, Neil Horman wrote:
> On Sun, Dec 18, 2016 at 10:56:32PM +0200, Julian Anastasov wrote:
> > - tp->af_specific->sctp_xmit(head, tp);
> > + confirm = tp->dst_pending_confirm;
> > + if (confirm)
> > + head->dst_pending_confirm = 1;
> Why not use your confirm helper function here?
It is for sk, I can add a skb_set_dst_pending_confirm(skb,int)
helper, if needed.
> > + if (!t->dst_pending_confirm)
> > + t->dst_pending_confirm = 1;
> I'm not sure why you check it for being zero before setting it here, just set it
> unilaterally instead, or are you trying to avoid dirtying a cacheline?
Yes, no other reason. I'll change it in the next version.
Regards
^ permalink raw reply
* Re: [PATCH v5] net: dummy: Introduce dummy virtual functions
From: Phil Sutter @ 2016-12-21 20:06 UTC (permalink / raw)
To: David Miller; +Cc: netdev, sd
In-Reply-To: <20161221.133200.173665554896949124.davem@davemloft.net>
On Wed, Dec 21, 2016 at 01:32:00PM -0500, David Miller wrote:
> From: Phil Sutter <phil@nwl.cc>
> Date: Tue, 20 Dec 2016 23:26:21 +0100
>
> > The idea for this was born when testing VF support in iproute2 which was
> > impeded by hardware requirements. In fact, not every VF-capable hardware
> > driver implements all netdev ops, so testing the interface is still hard
> > to do even with a well-sorted hardware shelf.
> >
> > To overcome this and allow for testing the user-kernel interface, this
> > patch allows to turn dummy into a PF with a configurable amount of VFs.
> >
> > Due to the assumption that all PFs are PCI devices, this implementation
> > is not completely straightforward: In order to allow for
> > rtnl_fill_ifinfo() to see the dummy VFs, a fake PCI parent device is
> > attached to the dummy netdev. This has to happen at the right spot so
> > register_netdevice() does not get confused. This patch abuses
> > ndo_fix_features callback for that. In ndo_uninit callback, the fake
> > parent is removed again for the same purpose.
> >
> > Joint work with Sabrina Dubroca.
> >
> > Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
> > Signed-off-by: Phil Sutter <phil@nwl.cc>
>
> Please resubmit when net-next opens back up, thanks.
Sure, thanks for the heads-up!
Cheers, Phil
^ permalink raw reply
* Re: [PATCH net] net, sched: fix soft lockup in tc_classify
From: Daniel Borkmann @ 2016-12-21 20:02 UTC (permalink / raw)
To: Cong Wang
Cc: David Miller, Shahar Klein, Or Gerlitz, Roi Dayan, Jiri Pirko,
John Fastabend, Linux Kernel Network Developers
In-Reply-To: <CAM_iQpX3Sk_YGDmvY-yj0CxPbG5qfT7P7ioNgY5Lb_DqsTWh6Q@mail.gmail.com>
On 12/21/2016 08:10 PM, Cong Wang wrote:
> On Wed, Dec 21, 2016 at 10:51 AM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>> On Wed, Dec 21, 2016 at 9:04 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
>>> What happens is that in tc_ctl_tfilter(), thread A allocates a new
>>> tp, initializes it, sets tp_created to 1, and calls into tp->ops->change()
>>> with it. In that classifier callback we had to unlock/lock the rtnl
>>> mutex and returned with -EAGAIN. One reason why we need to drop there
>>> is, for example, that we need to request an action module to be loaded.
>>
>> Excellent catch!
>>
>> But why do we have to replay the request here? Shouldn't we just return
>> EAGAIN to user-space and let user-space decide to retry or not?
>> Replaying is the root of the evil here.
>
> Answer myself: probably due to historical reasons, but still replaying
> inside such a big function is just error-prone, we should promote it
> out:
Have no strong opinion, I guess it could be done as a simplification
for net-next, why not, along with moving out the netlink_ns_capable()
check or possibly other things after careful analysis that don't need
to be redone in that circumstance.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH 2/5 net-next] inet: kill smallest_size and smallest_port
From: Josef Bacik @ 2016-12-21 19:32 UTC (permalink / raw)
To: David Miller; +Cc: hannes, kraigatgoog, eric.dumazet, tom, netdev, kernel-team
In-Reply-To: <20161221.133003.1401543777326711002.davem@davemloft.net>
On Wed, Dec 21, 2016 at 1:30 PM, David Miller <davem@davemloft.net>
wrote:
> From: Josef Bacik <jbacik@fb.com>
> Date: Tue, 20 Dec 2016 15:07:01 -0500
>
>> In inet_csk_get_port we seem to be using smallest_port to figure
>> out where the
>> best place to look for a SO_REUSEPORT sk that matches with an
>> existing set of
>> SO_REUSEPORT's. However if we get to the logic
>>
>> if (smallest_size != -1) {
>> port = smallest_port;
>> goto have_port;
>> }
>>
>> we will do a useless search, because we would have already done the
>> inet_csk_bind_conflict for that port and it would have returned 1,
>> otherwise we
>> would have gone to found_tb and succeeded. Since this logic makes
>> us do yet
>> another trip through inet_csk_bind_conflict for a port we know
>> won't work just
>> delete this code and save us the time.
>>
>> Signed-off-by: Josef Bacik <jbacik@fb.com>
>
> So the "all else being equal, use 'tb' with smallest socket count"
> logic
> wasn't being used at all?
>
> Instead of removing it why don't we make it work properly again?
> Something
> obviously broke it somewhere along the line, because I am pretty sure
> this
> heuristic worked at some point in the past.
Yeah as soon as we would find a tb with no bind conflicts we'd
immediately jump to found_tb: and subsequently exit, so if we did
manage to get to the point of checking smallest_size it would be
redundant as we would have had to hit a bind conflict for that port to
even reach that code.
How do you want me to add it back? The logic only kicked in if we were
SO_REUSEPORT with snum == 0, but Tom tells me that is basically
useless, so we've disallowed that behavior. Should we call a
bind_conflict() for every port and then go back and pick the one with
the smallest tb? That's a lot of scanning. Can you tell me what
behavior you desire and I'll add another patch to reintroduce it?
Thanks,
Josef
^ permalink raw reply
* Re: [PATCH 2/5 net-next] inet: kill smallest_size and smallest_port
From: Eric Dumazet @ 2016-12-21 19:29 UTC (permalink / raw)
To: David Miller; +Cc: jbacik, hannes, kraigatgoog, tom, netdev, kernel-team
In-Reply-To: <20161221.133003.1401543777326711002.davem@davemloft.net>
On Wed, 2016-12-21 at 13:30 -0500, David Miller wrote:
> From: Josef Bacik <jbacik@fb.com>
> Date: Tue, 20 Dec 2016 15:07:01 -0500
>
> > In inet_csk_get_port we seem to be using smallest_port to figure out where the
> > best place to look for a SO_REUSEPORT sk that matches with an existing set of
> > SO_REUSEPORT's. However if we get to the logic
> >
> > if (smallest_size != -1) {
> > port = smallest_port;
> > goto have_port;
> > }
> >
> > we will do a useless search, because we would have already done the
> > inet_csk_bind_conflict for that port and it would have returned 1, otherwise we
> > would have gone to found_tb and succeeded. Since this logic makes us do yet
> > another trip through inet_csk_bind_conflict for a port we know won't work just
> > delete this code and save us the time.
> >
> > Signed-off-by: Josef Bacik <jbacik@fb.com>
>
> So the "all else being equal, use 'tb' with smallest socket count" logic
> wasn't being used at all?
>
> Instead of removing it why don't we make it work properly again? Something
> obviously broke it somewhere along the line, because I am pretty sure this
> heuristic worked at some point in the past.
Yeah, but heuristic to choose the smallest list was hurting a lot, since
it tends to consume all ports.
At connect() time we prefer to have another heuristic, actually leaving
some slots absolutely empty, so that a bind() will succeed later.
Remember I had more than 30 ms latency as described in the 2nd commit
changelog :
References :
commit ea8add2b190395408b22a9127bed2c0912aecbc8
Author: Eric Dumazet <edumazet@google.com>
Date: Thu Feb 11 16:28:50 2016 -0800
tcp/dccp: better use of ephemeral ports in bind()
Implement strategy used in __inet_hash_connect() in opposite way :
Try to find a candidate using odd ports, then fallback to even ports.
We no longer disable BH for whole traversal, but one bucket at a time.
We also use cond_resched() to yield cpu to other tasks if needed.
I removed one indentation level and tried to mirror the loop we have
in __inet_hash_connect() and variable names to ease code maintenance.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 1580ab63fc9a03593072cc5656167a75c4f1d173
Author: Eric Dumazet <edumazet@google.com>
Date: Thu Feb 11 16:28:49 2016 -0800
tcp/dccp: better use of ephemeral ports in connect()
In commit 07f4c90062f8 ("tcp/dccp: try to not exhaust ip_local_port_range
in connect()"), I added a very simple heuristic, so that we got better
chances to use even ports, and allow bind() users to have more available
slots.
It gave nice results, but with more than 200,000 TCP sessions on a typical
server, the ~30,000 ephemeral ports are still a rare resource.
I chose to go a step further, by looking at all even ports, and if none
was available, fallback to odd ports.
The companion patch does the same in bind(), but in opposite way.
I've seen exec times of up to 30ms on busy servers, so I no longer
disable BH for the whole traversal, but only for each hash bucket.
I also call cond_resched() to be gentle to other tasks.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH net] net, sched: fix soft lockup in tc_classify
From: Daniel Borkmann @ 2016-12-21 19:16 UTC (permalink / raw)
To: Cong Wang
Cc: David Miller, Shahar Klein, Or Gerlitz, Roi Dayan, Jiri Pirko,
John Fastabend, Linux Kernel Network Developers
In-Reply-To: <CAM_iQpXadrGWJYqizEkq+xmMKVV9krrcCWKur=ZCRZBS9Mx_8w@mail.gmail.com>
On 12/21/2016 07:51 PM, Cong Wang wrote:
> On Wed, Dec 21, 2016 at 9:04 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
>> What happens is that in tc_ctl_tfilter(), thread A allocates a new
>> tp, initializes it, sets tp_created to 1, and calls into tp->ops->change()
>> with it. In that classifier callback we had to unlock/lock the rtnl
>> mutex and returned with -EAGAIN. One reason why we need to drop there
>> is, for example, that we need to request an action module to be loaded.
>
> Excellent catch!
>
> But why do we have to replay the request here? Shouldn't we just return
> EAGAIN to user-space and let user-space decide to retry or not?
> Replaying is the root of the evil here.
Right, this behavior is already pretty old (2005), see history
tree 8d7c694553dc ("[PKT_SCHED]: act_api.c: drop rtnl for loading
modules") and 437293de63d8 ("[PKT_SCHED]: cls_api.c: drop rtnl
for loading modules"), some binaries could rely on that behavior
in one way or another I'd presume.
^ 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