* [PATCH net v2 2/2] net: bcmgenet: fix skb_len in bcmgenet_xmit_single()
From: Petri Gynther @ 2016-03-24 18:27 UTC (permalink / raw)
To: netdev; +Cc: davem, f.fainelli, jaedon.shin, edumazet, Petri Gynther
In-Reply-To: <1458844041-71532-1-git-send-email-pgynther@google.com>
skb_len needs to be skb_headlen(skb) in bcmgenet_xmit_single().
Fragmented skbs can have only Ethernet + IP + TCP headers (14+20+20=54 bytes)
in the linear buffer, followed by the rest in fragments. Bumping skb_len to
ETH_ZLEN would be incorrect for this case, as it would introduce garbage
between TCP header and the fragment data.
This also works with regular/non-fragmented small packets < ETH_ZLEN bytes.
Successfully tested this on GENETv3 with 42-byte ARP frames.
For testing, I used:
ethtool -K eth0 tx-checksum-ipv4 off
ethtool -K eth0 tx-checksum-ipv6 off
echo 0 > /proc/sys/net/ipv4/tcp_timestamps
Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file")
Signed-off-by: Petri Gynther <pgynther@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index c1c7c0e..cf6445d 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -1297,7 +1297,7 @@ static int bcmgenet_xmit_single(struct net_device *dev,
tx_cb_ptr->skb = skb;
- skb_len = skb_headlen(skb) < ETH_ZLEN ? ETH_ZLEN : skb_headlen(skb);
+ skb_len = skb_headlen(skb);
mapping = dma_map_single(kdev, skb->data, skb_len, DMA_TO_DEVICE);
ret = dma_mapping_error(kdev, mapping);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH net v2 1/2] net: bcmgenet: fix dev->stats.tx_bytes accounting
From: Petri Gynther @ 2016-03-24 18:27 UTC (permalink / raw)
To: netdev; +Cc: davem, f.fainelli, jaedon.shin, edumazet, Petri Gynther
1. Add bytes_compl local variable to __bcmgenet_tx_reclaim() to collect
transmitted bytes. dev->stats updates can then be moved outside the
while-loop. bytes_compl is also needed for future BQL support.
2. When bcmgenet device uses Tx checksum offload, each transmitted skb
gets an extra 64-byte header prepended to it. Before this header is
prepended to the skb, we need to save the skb "wire" length in
GENET_CB(skb)->bytes_sent, so that proper Tx bytes accounting can
be done in __bcmgenet_tx_reclaim().
3. skb->len covers the entire length of skb, whether it is linear or
fragmented. Thus, when we clean the fragments, do not increase
transmitted bytes.
Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file")
Signed-off-by: Petri Gynther <pgynther@google.com>
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 14 ++++++++++----
drivers/net/ethernet/broadcom/genet/bcmgenet.h | 6 ++++++
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index 6746fd0..c1c7c0e 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -1171,6 +1171,7 @@ static unsigned int __bcmgenet_tx_reclaim(struct net_device *dev,
struct enet_cb *tx_cb_ptr;
struct netdev_queue *txq;
unsigned int pkts_compl = 0;
+ unsigned int bytes_compl = 0;
unsigned int c_index;
unsigned int txbds_ready;
unsigned int txbds_processed = 0;
@@ -1193,16 +1194,13 @@ static unsigned int __bcmgenet_tx_reclaim(struct net_device *dev,
tx_cb_ptr = &priv->tx_cbs[ring->clean_ptr];
if (tx_cb_ptr->skb) {
pkts_compl++;
- dev->stats.tx_packets++;
- dev->stats.tx_bytes += tx_cb_ptr->skb->len;
+ bytes_compl += GENET_CB(tx_cb_ptr->skb)->bytes_sent;
dma_unmap_single(&dev->dev,
dma_unmap_addr(tx_cb_ptr, dma_addr),
dma_unmap_len(tx_cb_ptr, dma_len),
DMA_TO_DEVICE);
bcmgenet_free_cb(tx_cb_ptr);
} else if (dma_unmap_addr(tx_cb_ptr, dma_addr)) {
- dev->stats.tx_bytes +=
- dma_unmap_len(tx_cb_ptr, dma_len);
dma_unmap_page(&dev->dev,
dma_unmap_addr(tx_cb_ptr, dma_addr),
dma_unmap_len(tx_cb_ptr, dma_len),
@@ -1220,6 +1218,9 @@ static unsigned int __bcmgenet_tx_reclaim(struct net_device *dev,
ring->free_bds += txbds_processed;
ring->c_index = (ring->c_index + txbds_processed) & DMA_C_INDEX_MASK;
+ dev->stats.tx_packets += pkts_compl;
+ dev->stats.tx_bytes += bytes_compl;
+
if (ring->free_bds > (MAX_SKB_FRAGS + 1)) {
txq = netdev_get_tx_queue(dev, ring->queue);
if (netif_tx_queue_stopped(txq))
@@ -1464,6 +1465,11 @@ static netdev_tx_t bcmgenet_xmit(struct sk_buff *skb, struct net_device *dev)
goto out;
}
+ /* Retain how many bytes will be sent on the wire, without TSB inserted
+ * by transmit checksum offload
+ */
+ GENET_CB(skb)->bytes_sent = skb->len;
+
/* set the SKB transmit checksum */
if (priv->desc_64b_en) {
skb = bcmgenet_put_tx_csum(dev, skb);
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.h b/drivers/net/ethernet/broadcom/genet/bcmgenet.h
index 9673675..1e2dc34 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.h
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.h
@@ -531,6 +531,12 @@ struct bcmgenet_hw_params {
u32 flags;
};
+struct bcmgenet_skb_cb {
+ unsigned int bytes_sent; /* bytes on the wire (no TSB) */
+};
+
+#define GENET_CB(skb) ((struct bcmgenet_skb_cb *)((skb)->cb))
+
struct bcmgenet_tx_ring {
spinlock_t lock; /* ring lock */
struct napi_struct napi; /* NAPI per tx queue */
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* Re: [PATCH net] net: ipv4: Multipath needs to handle unreachable nexthops
From: David Miller @ 2016-03-24 18:26 UTC (permalink / raw)
To: eric.dumazet; +Cc: dsa, netdev
In-Reply-To: <1458837934.12033.6.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 24 Mar 2016 09:45:34 -0700
> On Thu, 2016-03-24 at 08:25 -0700, David Ahern wrote:
>> Multipath route lookups should consider knowledge about next hops and not
>> select a hop that is known to be failed.
>
> Does not look a net candidate to me.
>
>> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
>> ---
>> net/ipv4/fib_semantics.c | 34 ++++++++++++++++++++++++++++++++--
>> 1 file changed, 32 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
>> index d97268e8ff10..28fc6700c2b1 100644
>> --- a/net/ipv4/fib_semantics.c
>> +++ b/net/ipv4/fib_semantics.c
>> @@ -1563,13 +1563,43 @@ int fib_sync_up(struct net_device *dev, unsigned int nh_flags)
>> void fib_select_multipath(struct fib_result *res, int hash)
>> {
>> struct fib_info *fi = res->fi;
>> + struct neighbour *n;
>> + int state;
>>
>> for_nexthops(fi) {
>> if (hash > atomic_read(&nh->nh_upper_bound))
>> continue;
>>
>> - res->nh_sel = nhsel;
>> - return;
>> + state = NUD_NONE;
>> + n = neigh_lookup(&arp_tbl, &nh->nh_gw, fi->fib_dev);
>> + if (n) {
>> + state = n->nud_state;
>> + neigh_release(n);
>> + }
>
> This looks like something that could use RCU to avoid expensive
> refcounting ?
Indeed, this is way too expensive as-is.
^ permalink raw reply
* Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode
From: Willy Tarreau @ 2016-03-24 18:24 UTC (permalink / raw)
To: Tolga Ceylan
Cc: Daniel Borkmann, Tom Herbert, Eric Dumazet, Craig Gallek,
Josh Snyder, Aaron Conole, David S. Miller,
Linux Kernel Network Developers
In-Reply-To: <CALmu+SxF5dDEBwpk-R=V5DGZBed1rvjYGEJ+cU8ZhyAdLWshug@mail.gmail.com>
On Thu, Mar 24, 2016 at 11:20:49AM -0700, Tolga Ceylan wrote:
> I would appreciate a conceptual description on how this would work
> especially for a common scenario
> as described by Willy. My initial impression was that a coordinator
> (master) process takes this
> responsibility to adjust BPF filters as children come and go.
Indeed that would help, I don't know where to start from for now.
> Two popular software has similar use cases: nginx and haproxy. Another
> concern is with the
> introduction of BPF itself, should we expect a performance drop in
> these applications?
Knowing how picky Eric is about performance in such areas, I'm not
worried a single second about adopting something he recommends :-)
I just need to ensure it covers our users' needs. And maybe the
solution I mentionned in the other e-mail could work.
Willy
^ permalink raw reply
* Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode
From: Willy Tarreau @ 2016-03-24 18:21 UTC (permalink / raw)
To: Eric Dumazet
Cc: Tolga Ceylan, Tom Herbert, cgallek, Josh Snyder, Aaron Conole,
David S. Miller, Linux Kernel Network Developers
In-Reply-To: <20160324180011.GB7585@1wt.eu>
On Thu, Mar 24, 2016 at 07:00:11PM +0100, Willy Tarreau wrote:
> Since it's not about
> load distribution and that processes are totally independant, I don't see
> well how to (ab)use BPF to achieve this.
>
> The pattern is :
>
> t0 : unprivileged processes 1 and 2 are listening to the same port
> (sock1@pid1) (sock2@pid2)
> <------ listening ------>
>
> t1 : new processes are started to replace the old ones
> (sock1@pid1) (sock2@pid2) (sock3@pid3) (sock4@pid4)
> <------ listening ------> <------ listening ------>
>
> t2 : new processes signal the old ones they must stop
> (sock1@pid1) (sock2@pid2) (sock3@pid3) (sock4@pid4)
> <------- draining ------> <------ listening ------>
>
> t3 : pids 1 and 2 have finished, they go away
> (sock3@pid3) (sock4@pid4)
> <------ gone -----> <------ listening ------>
>
Thinking a bit more about it, would it make sense to consider that in order
to address such a scenario, the only the new (still privileged) process
reconfigures the BPF to deliver traffic only to its own sockets and that
by doing so it will result in the old one not to receive any of it anymore ?
If so that could possibly be reasonably doable then. Ie: the old processes
don't have to do anything to stop receiving traffic.
Thanks,
Willy
^ permalink raw reply
* Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode
From: Tolga Ceylan @ 2016-03-24 18:20 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Tom Herbert, Eric Dumazet, Willy Tarreau, Craig Gallek,
Josh Snyder, Aaron Conole, David S. Miller,
Linux Kernel Network Developers
In-Reply-To: <56F42A00.7050002@iogearbox.net>
On Thu, Mar 24, 2016 at 10:55 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 03/24/2016 06:26 PM, Tom Herbert wrote:
>>
>> I completely agree with this, but I wonder if we now need a repository
>> of useful BPF modules. So in the case of implementing functionality
>> like in SO_REUSEPORT_LISTEN_OFF that might just become a common BPF
>> program we could direct people to use.
>
>
> Good point. There's tools/testing/selftests/net/ containing already
> reuseport
> BPF example, maybe it could be extended.
I would appreciate a conceptual description on how this would work
especially for a common scenario
as described by Willy. My initial impression was that a coordinator
(master) process takes this
responsibility to adjust BPF filters as children come and go.
Two popular software has similar use cases: nginx and haproxy. Another
concern is with the
introduction of BPF itself, should we expect a performance drop in
these applications?
Best Regards,
Tolga Ceylan
^ permalink raw reply
* Re: [PATCH 1/1] net: macb: remove BUG_ON() and reset the queue to handle RX errors
From: Sergei Shtylyov @ 2016-03-24 18:19 UTC (permalink / raw)
To: Cyrille Pitchen, nicolas.ferre, davem, linux-arm-kernel, netdev,
soren.brinkmann, narmstrong
Cc: linux-kernel
In-Reply-To: <1458830232-6159-1-git-send-email-cyrille.pitchen@atmel.com>
Hello.
On 03/24/2016 05:37 PM, Cyrille Pitchen wrote:
> This patch removes two BUG_ON() used to notify about RX queue corruptions
> on macb (not gem) hardware without actually handling the error.
>
> The new code skips corrupted frames but still processes faultless frames.
> Then it resets the RX queue before restarting the reception from a clean
> state.
>
> This patch is a rework of an older patch proposed by Neil Armstrong:
> http://patchwork.ozlabs.org/patch/371525/
>
> Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
> ---
> drivers/net/ethernet/cadence/macb.c | 59 ++++++++++++++++++++++++++++++-------
> 1 file changed, 49 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
> index 6619178ed77b..39447a337149 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
[...]
> @@ -945,11 +948,26 @@ static int macb_rx_frame(struct macb *bp, unsigned int first_frag,
> return 0;
> }
>
> +static inline void macb_init_rx_ring(struct macb *bp)
> +{
> + int i;
> + dma_addr_t addr;
DaveM prefers that longer declarations precede the shorter.
[...]
> static int macb_rx(struct macb *bp, int budget)
> {
> int received = 0;
> unsigned int tail;
> int first_frag = -1;
> + int reset_rx_queue = 0;
*bool*, please.
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode
From: Willy Tarreau @ 2016-03-24 18:00 UTC (permalink / raw)
To: Eric Dumazet
Cc: Tolga Ceylan, Tom Herbert, cgallek, Josh Snyder, Aaron Conole,
David S. Miller, Linux Kernel Network Developers
In-Reply-To: <1458838897.12033.10.camel@edumazet-glaptop3.roam.corp.google.com>
On Thu, Mar 24, 2016 at 10:01:37AM -0700, Eric Dumazet wrote:
> On Thu, 2016-03-24 at 17:50 +0100, Willy Tarreau wrote:
> > On Thu, Mar 24, 2016 at 09:33:11AM -0700, Eric Dumazet wrote:
> > > > --- a/net/ipv4/inet_hashtables.c
> > > > +++ b/net/ipv4/inet_hashtables.c
> > > > @@ -189,6 +189,8 @@ static inline int compute_score(struct sock *sk, struct net *net,
> > > > return -1;
> > > > score += 4;
> > > > }
> > > > + if (sk->sk_reuseport)
> > > > + score++;
> > >
> > > This wont work with BPF
> > >
> > > > if (sk->sk_incoming_cpu == raw_smp_processor_id())
> > > > score++;
> > >
> > > This one does not work either with BPF
> >
> > But this *is* in 4.5. Does this mean that this part doesn't work anymore or
> > just that it's not usable in conjunction with BPF ? In this case I'm less
> > worried, because it would mean that we have a solution for non-BPF aware
> > applications and that BPF-aware applications can simply use BPF.
> >
>
> BPF can implement the CPU choice/pref itself. It has everything needed.
Well I don't need the CPU choice, it was already there, it's not my code,
I only need the ability for an independant process to stop receiving new
connections without altering the other processes nor dropping some of these
connections.
In fact initially I didn't even need anything related to incoming connection
load-balancing, just the ability to start a new process without stopping the
old one, as it used to work in 2.2 and for which I used to keep a patch in
2.4 and 2.6. When SO_REUSEPORT was reintroduced in 3.9, that solved the issue
and some users started to complain that between the old and the new processes,
some connections were lost. Hence the proposal above. Since it's not about
load distribution and that processes are totally independant, I don't see
well how to (ab)use BPF to achieve this.
The pattern is :
t0 : unprivileged processes 1 and 2 are listening to the same port
(sock1@pid1) (sock2@pid2)
<------ listening ------>
t1 : new processes are started to replace the old ones
(sock1@pid1) (sock2@pid2) (sock3@pid3) (sock4@pid4)
<------ listening ------> <------ listening ------>
t2 : new processes signal the old ones they must stop
(sock1@pid1) (sock2@pid2) (sock3@pid3) (sock4@pid4)
<------- draining ------> <------ listening ------>
t3 : pids 1 and 2 have finished, they go away
(sock3@pid3) (sock4@pid4)
<------ gone -----> <------ listening ------>
> > - it seems to me that for BPF to be usable on process shutting down, we'd
> > need to have some form of central knowledge if the goal is to redefine
> > how to distribute the load. In my case there are multiple independant
> > processes forked on startup, so it's unclear to me how each of them could
> > reconfigure BPF when shutting down without risking to break the other ones.
> > - the doc makes me believe that BPF would require privileges to be unset, so
> > that would not be compatible with a process shutting down which has already
> > dropped its privileges after startup, but I could be wrong.
> >
> > Thanks for your help on this,
> > Willy
> >
>
> The point is : BPF is the way to go, because it is expandable.
OK so this means we have to find a way to expand it to allow an individual
non-privileged process to change the distribution algorithm without impacting
other processes.
I need to discover it better to find what can be done, but unfortunately at
this point the sole principle makes me think of a level of complexity that
doesn't seem obvious to solve at all :-/
Regards,
Willy
^ permalink raw reply
* Re: [PATCH net] net: ipv4: Multipath needs to handle unreachable nexthops
From: Eric Dumazet @ 2016-03-24 17:55 UTC (permalink / raw)
To: David Ahern; +Cc: netdev
In-Reply-To: <56F4274C.70707@cumulusnetworks.com>
On Thu, 2016-03-24 at 11:43 -0600, David Ahern wrote:
> On 3/24/16 10:45 AM, Eric Dumazet wrote:
> > On Thu, 2016-03-24 at 08:25 -0700, David Ahern wrote:
> >> Multipath route lookups should consider knowledge about next hops and not
> >> select a hop that is known to be failed.
> >
> > Does not look a net candidate to me.
>
> you don't consider this a bug? certainly not a feature.
For a bug that lasted years, certainly the fix can be properly tested in
net-next, then eventually backported to stable once validated.
Unless there is a sudden concern about known ways to crash linux
hosts ;)
^ permalink raw reply
* Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode
From: Daniel Borkmann @ 2016-03-24 17:55 UTC (permalink / raw)
To: Tom Herbert, Eric Dumazet
Cc: Willy Tarreau, Tolga Ceylan, Craig Gallek, Josh Snyder,
Aaron Conole, David S. Miller, Linux Kernel Network Developers
In-Reply-To: <CALx6S36Ej1es8qFi2Q3=199f+rmG=Za02N5ZBWT5DCRqrBEWvQ@mail.gmail.com>
On 03/24/2016 06:26 PM, Tom Herbert wrote:
> On Thu, Mar 24, 2016 at 10:01 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> On Thu, 2016-03-24 at 17:50 +0100, Willy Tarreau wrote:
>>> On Thu, Mar 24, 2016 at 09:33:11AM -0700, Eric Dumazet wrote:
>>>>> --- a/net/ipv4/inet_hashtables.c
>>>>> +++ b/net/ipv4/inet_hashtables.c
>>>>> @@ -189,6 +189,8 @@ static inline int compute_score(struct sock *sk, struct net *net,
>>>>> return -1;
>>>>> score += 4;
>>>>> }
>>>>> + if (sk->sk_reuseport)
>>>>> + score++;
>>>>
>>>> This wont work with BPF
>>>>
>>>>> if (sk->sk_incoming_cpu == raw_smp_processor_id())
>>>>> score++;
>>>>
>>>> This one does not work either with BPF
>>>
>>> But this *is* in 4.5. Does this mean that this part doesn't work anymore or
>>> just that it's not usable in conjunction with BPF ? In this case I'm less
>>> worried, because it would mean that we have a solution for non-BPF aware
>>> applications and that BPF-aware applications can simply use BPF.
>>
>> BPF can implement the CPU choice/pref itself. It has everything needed.
>>
>>> I don't try to reimplement something already available, but I'm confused
>>> by a few points :
>>> - the code above already exists and you mention it cannot be used with BPF
>>
>> _If_ you use BPF, then you can implement a CPU preference using BPF
>> instructions. It is a user choice.
>>
>>> - for the vast majority of applications not using BPF, would the above *still*
>>> work (it worked in 4.4-rc at least)
>>
>>> - it seems to me that for BPF to be usable on process shutting down, we'd
>>> need to have some form of central knowledge if the goal is to redefine
>>> how to distribute the load. In my case there are multiple independant
>>> processes forked on startup, so it's unclear to me how each of them could
>>> reconfigure BPF when shutting down without risking to break the other ones.
>>> - the doc makes me believe that BPF would require privileges to be unset, so
>>> that would not be compatible with a process shutting down which has already
>>> dropped its privileges after startup, but I could be wrong.
>>>
>>> Thanks for your help on this,
>>> Willy
>>
>> The point is : BPF is the way to go, because it is expandable.
>>
>> No more hard points coded forever in the kernel.
>>
>> Really, when BPF can be the solution, we wont allow adding new stuff in
>> the kernel in the old way.
>
> I completely agree with this, but I wonder if we now need a repository
> of useful BPF modules. So in the case of implementing functionality
> like in SO_REUSEPORT_LISTEN_OFF that might just become a common BPF
> program we could direct people to use.
Good point. There's tools/testing/selftests/net/ containing already reuseport
BPF example, maybe it could be extended.
^ permalink raw reply
* Re: [PATCH net] net: ipv4: Multipath needs to handle unreachable nexthops
From: David Ahern @ 2016-03-24 17:43 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1458837934.12033.6.camel@edumazet-glaptop3.roam.corp.google.com>
On 3/24/16 10:45 AM, Eric Dumazet wrote:
> On Thu, 2016-03-24 at 08:25 -0700, David Ahern wrote:
>> Multipath route lookups should consider knowledge about next hops and not
>> select a hop that is known to be failed.
>
> Does not look a net candidate to me.
you don't consider this a bug? certainly not a feature.
>
>> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
>> ---
>> net/ipv4/fib_semantics.c | 34 ++++++++++++++++++++++++++++++++--
>> 1 file changed, 32 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
>> index d97268e8ff10..28fc6700c2b1 100644
>> --- a/net/ipv4/fib_semantics.c
>> +++ b/net/ipv4/fib_semantics.c
>> @@ -1563,13 +1563,43 @@ int fib_sync_up(struct net_device *dev, unsigned int nh_flags)
>> void fib_select_multipath(struct fib_result *res, int hash)
>> {
>> struct fib_info *fi = res->fi;
>> + struct neighbour *n;
>> + int state;
>>
>> for_nexthops(fi) {
>> if (hash > atomic_read(&nh->nh_upper_bound))
>> continue;
>>
>> - res->nh_sel = nhsel;
>> - return;
>> + state = NUD_NONE;
>> + n = neigh_lookup(&arp_tbl, &nh->nh_gw, fi->fib_dev);
>> + if (n) {
>> + state = n->nud_state;
>> + neigh_release(n);
>> + }
>
> This looks like something that could use RCU to avoid expensive
> refcounting ?
Yes, good point.
^ permalink raw reply
* Re: [PATCH 0/3] Control ethernet PHY LEDs via LED subsystem
From: Vishal Thanki @ 2016-03-24 17:35 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Florian Fainelli, Matus Ujhelyi, netdev
In-Reply-To: <20160324132935.GA15624@lunn.ch>
>> >> The eth-phy-activity trigger uses the blink_set which I think uses the
>> >> hardware acceleration if available. I am not sure how to handles LEDs
>> >> which does not have hardware acceleration for this (eth-phy-activity)
>> >> trigger.
>> >
>> > We want the LED to blink on activity, real packets coming in and
>> > out. The PHY can do this, so let the PHY control the LED. In this
>> > case, the trigger is just mechanism for the user to say what the LED
>> > should be used for. The trigger is not itself controlling the LED, it
>> > has no idea about packets coming and going.
>> >
>>
>> Yes, I understand that. But PHY can only control the LEDs attached to
>> it directly. The at803x led driver configures the PHY to blink the
>> activity LED based on traffic but I think it is not possible for PHY
>> to control other LEDs in system, for example some other LEDs in system
>> controlled only via GPIO. In such cases, putting PHY activity trigger
>> on the GPIO LEDs would not make sense. Correct me if I am wrong.
>
> Hi Vishal
>
> All correct. Which is why i said in my original email, you need to
> extend the LED core to associate triggers to LEDs. You can then
> associate the eth-phy-activity trigger to only PHY leds which can
> implement that functionality.
>
> drivers/leds/led-triggers.c contains a global list
> LIST_HEAD(trigger_list) which triggers get added to using
> led_trigger_register(). You could add a second list to the
> led_classdev structure, and add an led_trigger_register_to_led()
Hi Andrew,
I still have some questions. Will the phylib call this
led_trigger_register_to_led() function for registering the trigger
instead of calling led_trigger_register()?
> function which registers a trigger to a specific LED, on its own
> trigger list. led_trigger_store() and led_trigger_show() would use
> both lists.
In case of led_trigger_store(), how to stop the non-PHY LEDs to
register themselves from eth-phy-activity trigger. Should there be a
LED class field which distinguishes different LEDs types (GPIO, PHY
etc..) ? And only PHY LEDs have the privilege to register to
eth-phy-activity trigger?
Thanks you very much for your guidance and patience with me.
Regards,
Vishal
>
> Andrew
^ permalink raw reply
* Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode
From: Tom Herbert @ 2016-03-24 17:26 UTC (permalink / raw)
To: Eric Dumazet
Cc: Willy Tarreau, Tolga Ceylan, Craig Gallek, Josh Snyder,
Aaron Conole, David S. Miller, Linux Kernel Network Developers
In-Reply-To: <1458838897.12033.10.camel@edumazet-glaptop3.roam.corp.google.com>
On Thu, Mar 24, 2016 at 10:01 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2016-03-24 at 17:50 +0100, Willy Tarreau wrote:
>> On Thu, Mar 24, 2016 at 09:33:11AM -0700, Eric Dumazet wrote:
>> > > --- a/net/ipv4/inet_hashtables.c
>> > > +++ b/net/ipv4/inet_hashtables.c
>> > > @@ -189,6 +189,8 @@ static inline int compute_score(struct sock *sk, struct net *net,
>> > > return -1;
>> > > score += 4;
>> > > }
>> > > + if (sk->sk_reuseport)
>> > > + score++;
>> >
>> > This wont work with BPF
>> >
>> > > if (sk->sk_incoming_cpu == raw_smp_processor_id())
>> > > score++;
>> >
>> > This one does not work either with BPF
>>
>> But this *is* in 4.5. Does this mean that this part doesn't work anymore or
>> just that it's not usable in conjunction with BPF ? In this case I'm less
>> worried, because it would mean that we have a solution for non-BPF aware
>> applications and that BPF-aware applications can simply use BPF.
>>
>
> BPF can implement the CPU choice/pref itself. It has everything needed.
>
>> I don't try to reimplement something already available, but I'm confused
>> by a few points :
>> - the code above already exists and you mention it cannot be used with BPF
>
> _If_ you use BPF, then you can implement a CPU preference using BPF
> instructions. It is a user choice.
>
>> - for the vast majority of applications not using BPF, would the above *still*
>> work (it worked in 4.4-rc at least)
>
>
>> - it seems to me that for BPF to be usable on process shutting down, we'd
>> need to have some form of central knowledge if the goal is to redefine
>> how to distribute the load. In my case there are multiple independant
>> processes forked on startup, so it's unclear to me how each of them could
>> reconfigure BPF when shutting down without risking to break the other ones.
>> - the doc makes me believe that BPF would require privileges to be unset, so
>> that would not be compatible with a process shutting down which has already
>> dropped its privileges after startup, but I could be wrong.
>>
>> Thanks for your help on this,
>> Willy
>>
>
> The point is : BPF is the way to go, because it is expandable.
>
> No more hard points coded forever in the kernel.
>
> Really, when BPF can be the solution, we wont allow adding new stuff in
> the kernel in the old way.
I completely agree with this, but I wonder if we now need a repository
of useful BPF modules. So in the case of implementing functionality
like in SO_REUSEPORT_LISTEN_OFF that might just become a common BPF
program we could direct people to use.
Tom
>
>
>
^ permalink raw reply
* Re: [RFC PATCH 7/9] GSO: Support partial segmentation offload
From: Edward Cree @ 2016-03-24 17:12 UTC (permalink / raw)
To: Alexander Duyck
Cc: Or Gerlitz, Alexander Duyck, Netdev, David Miller, Tom Herbert
In-Reply-To: <CAKgT0UfyOc4tYhZq7CC5G4S5HdzPW3iSifdcwe20Vxsqu8C3LQ@mail.gmail.com>
On 23/03/16 23:15, Alexander Duyck wrote:
> Right, but the problem becomes how do you identify what tunnel wants
> what. So for example we could theoretically have a UDP tunnel in a
> UDP with checksum. How would we tell which one want to have the
> checksum set and which one doesn't? The fact is we cannot.
I think we can still handle that, assuming the device is only touching the
innermost checksum (i.e. it's obeying csum_start/offset). We don't need
flags to tell us what to fill in in GSO, we can work it all out:
Make the series of per-protocol callbacks for GSO partial run inner-
outwards, by using recursion at the head. Make each return a csum_edit
value. Then for example:
For IPv4 header, our checksum covers only our header, so we fold any edits
into our own checksum, and pass csum_edit through unchanged.
For UDP header, we look to see if the current checksum field is zero. If
so, we leave it as zero, fold our edits into csum_edit and return the
result. Otherwise, we fold our edits and csum_edit into our checksum
field, and return zero.
For GRE, we look at the checksumming bit in the GRE header, and behave
similarly to UDP.
Etcetera...
This should even be a worthwhile simplification of the non-nested case,
because (if I understand correctly) it means GSO partial doesn't need the
various gso_type flags we already have to specify tunnel type and checksum
status; it just figures it out as it goes.
If your device is touching other checksums as well, then of course you need
to figure that out in your driver so you can cancel it out. But the device
will only fiddle with the headers you tell it about (in your case I think
that's outermost L3), not any others in the middle. So it should still all
work, without the driver having to know about the nesting.
> You are
> looking too far ahead. We haven't gotten to tunnel in tunnel yet.
IMHO, if our offloads are truly generic, tunnel in tunnel should be low-
hanging fruit. (In principle, "VxLAN + Ethernet + IP + GRE" is just
another encapsulation header, albeit a rather long one). Therefore, if
it _isn't_ low-hanging fruit for us, we should suspect that we aren't
generic. So even if it's not currently useful in itself, it's still a
convenient canary.
-Ed
^ permalink raw reply
* Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode
From: Eric Dumazet @ 2016-03-24 17:01 UTC (permalink / raw)
To: Willy Tarreau
Cc: Tolga Ceylan, Tom Herbert, cgallek, Josh Snyder, Aaron Conole,
David S. Miller, Linux Kernel Network Developers
In-Reply-To: <20160324165047.GA7585@1wt.eu>
On Thu, 2016-03-24 at 17:50 +0100, Willy Tarreau wrote:
> On Thu, Mar 24, 2016 at 09:33:11AM -0700, Eric Dumazet wrote:
> > > --- a/net/ipv4/inet_hashtables.c
> > > +++ b/net/ipv4/inet_hashtables.c
> > > @@ -189,6 +189,8 @@ static inline int compute_score(struct sock *sk, struct net *net,
> > > return -1;
> > > score += 4;
> > > }
> > > + if (sk->sk_reuseport)
> > > + score++;
> >
> > This wont work with BPF
> >
> > > if (sk->sk_incoming_cpu == raw_smp_processor_id())
> > > score++;
> >
> > This one does not work either with BPF
>
> But this *is* in 4.5. Does this mean that this part doesn't work anymore or
> just that it's not usable in conjunction with BPF ? In this case I'm less
> worried, because it would mean that we have a solution for non-BPF aware
> applications and that BPF-aware applications can simply use BPF.
>
BPF can implement the CPU choice/pref itself. It has everything needed.
> I don't try to reimplement something already available, but I'm confused
> by a few points :
> - the code above already exists and you mention it cannot be used with BPF
_If_ you use BPF, then you can implement a CPU preference using BPF
instructions. It is a user choice.
> - for the vast majority of applications not using BPF, would the above *still*
> work (it worked in 4.4-rc at least)
> - it seems to me that for BPF to be usable on process shutting down, we'd
> need to have some form of central knowledge if the goal is to redefine
> how to distribute the load. In my case there are multiple independant
> processes forked on startup, so it's unclear to me how each of them could
> reconfigure BPF when shutting down without risking to break the other ones.
> - the doc makes me believe that BPF would require privileges to be unset, so
> that would not be compatible with a process shutting down which has already
> dropped its privileges after startup, but I could be wrong.
>
> Thanks for your help on this,
> Willy
>
The point is : BPF is the way to go, because it is expandable.
No more hard points coded forever in the kernel.
Really, when BPF can be the solution, we wont allow adding new stuff in
the kernel in the old way.
^ permalink raw reply
* Re: [PATCH] stmmac: Fix phy without MDIO subnode
From: John Keeping @ 2016-03-24 17:01 UTC (permalink / raw)
To: Giuseppe CAVALLARO; +Cc: Gabriel Fernandez, netdev, linux-kernel
In-Reply-To: <56F3E3E2.6070001@st.com>
On Thu, 24 Mar 2016 13:56:02 +0100, Giuseppe CAVALLARO wrote:
> This should be fixed by some work done some days
> ago and not yet committed.
>
> Pls see "stmmac: MDIO fixes" patch-set and let me know
> if ok on your side.
Yes, that works for me.
Thanks,
John
> On 3/24/2016 11:56 AM, John Keeping wrote:
> > Since commit 88f8b1bb41c6 ("stmmac: Fix 'eth0: No PHY found'
> > regression") we no longer allocate mdio_bus_data unless there is a MDIO
> > subnode. This breaks the ethernet on the Radxa Rock2 (using
> > rk3288-rock2-square.dts) which does not have an MDIO subnode.
> >
> > That commit was correct that the phy_bus_name test is unhelpful since we
> > allocate "plat" in the same function and never set phy_bus_name so let's
> > just drop the test which restores the previous behaviour.
> >
> > Fixes: 88f8b1bb41c6 ("stmmac: Fix 'eth0: No PHY found' regression")
> > Signed-off-by: John Keeping <john@metanate.com>
> > ---
> > drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> > index dcbd2a1..e0fa060 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> > @@ -189,7 +189,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, const char **mac)
> > if (of_property_read_u32(np, "snps,phy-addr", &plat->phy_addr) == 0)
> > dev_warn(&pdev->dev, "snps,phy-addr property is deprecated\n");
> >
> > - if ((plat->phy_node && !of_phy_is_fixed_link(np)) || !plat->mdio_node)
> > + if ((plat->phy_node && !of_phy_is_fixed_link(np)))
> > plat->mdio_bus_data = NULL;
> > else
> > plat->mdio_bus_data =
> >
>
^ permalink raw reply
* RE: [PATCH v2] mwifiex: advertise low priority scan feature
From: Amitkumar Karwar @ 2016-03-24 17:00 UTC (permalink / raw)
To: Wei-Ning Huang, Linux Wireless
Cc: LKML, djkurtz@chromium.org, Nishant Sarmukadam,
kvalo@codeaurora.org, netdev@vger.kernel.org
In-Reply-To: <1458619796-7694-1-git-send-email-wnhuang@chromium.org>
> From: Wei-Ning Huang [mailto:wnhuang@chromium.org]
> Sent: Tuesday, March 22, 2016 9:40 AM
> To: Linux Wireless
> Cc: LKML; Amitkumar Karwar; djkurtz@chromium.org; Wei-Ning Huang;
> Nishant Sarmukadam; kvalo@codeaurora.org; netdev@vger.kernel.org
> Subject: [PATCH v2] mwifiex: advertise low priority scan feature
>
> From: Amitkumar Karwar <akarwar@marvell.com>
>
> Low priority scan handling code which delays or aborts scan operation
> based on Tx traffic is removed recently. The reason is firmware already
> takes care of it in our new feature scan channel gap. Hence we should
> advertise low priority scan support to cfg80211.
>
> This patch fixes a problem in which OBSS scan request from
> wpa_supplicant was being rejected by cfg80211.
>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> Signed-off-by: Wei-Ning Huang <wnhuang@chromium.org>
> ---
> drivers/net/wireless/marvell/mwifiex/cfg80211.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> index bb7235e..7dafc5b 100644
> --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> @@ -4086,6 +4086,7 @@ int mwifiex_register_cfg80211(struct
> mwifiex_adapter *adapter)
>
> wiphy->features |= NL80211_FEATURE_HT_IBSS |
> NL80211_FEATURE_INACTIVITY_TIMER |
> + NL80211_FEATURE_LOW_PRIORITY_SCAN |
> NL80211_FEATURE_NEED_OBSS_SCAN;
>
> if (ISSUPP_TDLS_ENABLED(adapter->fw_cap_info))
> --
> 2.8.0.rc3.226.g39d4020
Acked-by: Amitkumar Karwar <akarwar@marvell.com>
Regards,
Amitkumar
^ permalink raw reply
* Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode
From: Willy Tarreau @ 2016-03-24 16:50 UTC (permalink / raw)
To: Eric Dumazet
Cc: Tolga Ceylan, Tom Herbert, cgallek, Josh Snyder, Aaron Conole,
David S. Miller, Linux Kernel Network Developers
In-Reply-To: <1458837191.12033.4.camel@edumazet-glaptop3.roam.corp.google.com>
On Thu, Mar 24, 2016 at 09:33:11AM -0700, Eric Dumazet wrote:
> > --- a/net/ipv4/inet_hashtables.c
> > +++ b/net/ipv4/inet_hashtables.c
> > @@ -189,6 +189,8 @@ static inline int compute_score(struct sock *sk, struct net *net,
> > return -1;
> > score += 4;
> > }
> > + if (sk->sk_reuseport)
> > + score++;
>
> This wont work with BPF
>
> > if (sk->sk_incoming_cpu == raw_smp_processor_id())
> > score++;
>
> This one does not work either with BPF
But this *is* in 4.5. Does this mean that this part doesn't work anymore or
just that it's not usable in conjunction with BPF ? In this case I'm less
worried, because it would mean that we have a solution for non-BPF aware
applications and that BPF-aware applications can simply use BPF.
> Whole point of BPF was to avoid iterate through all sockets [1],
> and let user space use whatever selection logic it needs.
>
> [1] This was okay with up to 16 sockets. But with 128 it does not scale.
Indeed.
> If you really look at how BPF works, implementing another 'per listener' flag
> would break the BPF selection.
OK.
> You can certainly implement the SO_REUSEPORT_LISTEN_OFF by loading an
> updated BPF, why should we add another way in the kernel to do the same,
> in a way that would not work in some cases ?
I don't try to reimplement something already available, but I'm confused
by a few points :
- the code above already exists and you mention it cannot be used with BPF
- for the vast majority of applications not using BPF, would the above *still*
work (it worked in 4.4-rc at least)
- it seems to me that for BPF to be usable on process shutting down, we'd
need to have some form of central knowledge if the goal is to redefine
how to distribute the load. In my case there are multiple independant
processes forked on startup, so it's unclear to me how each of them could
reconfigure BPF when shutting down without risking to break the other ones.
- the doc makes me believe that BPF would require privileges to be unset, so
that would not be compatible with a process shutting down which has already
dropped its privileges after startup, but I could be wrong.
Thanks for your help on this,
Willy
^ permalink raw reply
* Re: [PATCH net] net: ipv4: Multipath needs to handle unreachable nexthops
From: Eric Dumazet @ 2016-03-24 16:45 UTC (permalink / raw)
To: David Ahern; +Cc: netdev
In-Reply-To: <1458833154-39091-1-git-send-email-dsa@cumulusnetworks.com>
On Thu, 2016-03-24 at 08:25 -0700, David Ahern wrote:
> Multipath route lookups should consider knowledge about next hops and not
> select a hop that is known to be failed.
Does not look a net candidate to me.
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
> ---
> net/ipv4/fib_semantics.c | 34 ++++++++++++++++++++++++++++++++--
> 1 file changed, 32 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
> index d97268e8ff10..28fc6700c2b1 100644
> --- a/net/ipv4/fib_semantics.c
> +++ b/net/ipv4/fib_semantics.c
> @@ -1563,13 +1563,43 @@ int fib_sync_up(struct net_device *dev, unsigned int nh_flags)
> void fib_select_multipath(struct fib_result *res, int hash)
> {
> struct fib_info *fi = res->fi;
> + struct neighbour *n;
> + int state;
>
> for_nexthops(fi) {
> if (hash > atomic_read(&nh->nh_upper_bound))
> continue;
>
> - res->nh_sel = nhsel;
> - return;
> + state = NUD_NONE;
> + n = neigh_lookup(&arp_tbl, &nh->nh_gw, fi->fib_dev);
> + if (n) {
> + state = n->nud_state;
> + neigh_release(n);
> + }
This looks like something that could use RCU to avoid expensive
refcounting ?
^ permalink raw reply
* Attn My Dear
From: Mrs. Ann @ 2016-03-24 16:19 UTC (permalink / raw)
To: Recipients
Attn My Dear
We have finally arranged to deliver your package worth $5.8m USD
Through (DHL) Company. We were able to accomplish this through the help
Of IMF director Anderson Morgan and every necessary arrangement has
Been made successfully.
Contact Dr.mark milliams
Telephone: (+229-99653283)
Email: (dhlbenin35@yahoo.in)
Contact the (DHL) with your delivery information such as:
(1) Full names ---
(2) Phone line ---
(3) Country -----
(4) Age/sex ------
(5) Occupation:---
(6)Home address:--
And also be informed that delivery agent will leave to this country as
soon as you proceed with (DHL) Company and please ask them how much is they Security Keeping fee to enable the agent live this country by tomorrow morning please I am waiting to hear from you thank you and God bless
Sincerely
Mrs. Ann Godwin
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as drain mode
From: Eric Dumazet @ 2016-03-24 16:33 UTC (permalink / raw)
To: Willy Tarreau
Cc: Tolga Ceylan, Tom Herbert, cgallek, Josh Snyder, Aaron Conole,
David S. Miller, Linux Kernel Network Developers
In-Reply-To: <20160324153053.GA7569@1wt.eu>
On Thu, 2016-03-24 at 16:30 +0100, Willy Tarreau wrote:
> Hi Eric,
>
> (just lost my e-mail, trying not to forget some points)
>
> On Thu, Mar 24, 2016 at 07:45:44AM -0700, Eric Dumazet wrote:
> > On Thu, 2016-03-24 at 15:22 +0100, Willy Tarreau wrote:
> > > Hi Eric,
> >
> > > But that means that any software making use of SO_REUSEPORT needs to
> > > also implement BPF on Linux to achieve the same as what it does on
> > > other OSes ? Also I found a case where a dying process would still
> > > cause trouble in the accept queue, maybe it's not redistributed, I
> > > don't remember, all I remember is that my traffic stopped after a
> > > segfault of only one of them :-/ I'll have to dig a bit regarding
> > > this.
> >
> > Hi Willy
> >
> > Problem is : If we add a SO_REUSEPORT_LISTEN_OFF, this wont work with
> > BPF.
>
> I wasn't for adding SO_REUSEPORT_LISTEN_OFF either. Instead the idea was
> just to modify the score in compute_score() so that a socket which disables
> SO_REUSEPORT scores less than one which still has it. The application
> wishing to terminate just has to clear the SO_REUSEPORT flag and wait for
> accept() reporting EAGAIN. The patch simply looked like this (copy-pasted
> hence space-mangled) :
>
> --- a/net/ipv4/inet_hashtables.c
> +++ b/net/ipv4/inet_hashtables.c
> @@ -189,6 +189,8 @@ static inline int compute_score(struct sock *sk, struct net *net,
> return -1;
> score += 4;
> }
> + if (sk->sk_reuseport)
> + score++;
This wont work with BPF
> if (sk->sk_incoming_cpu == raw_smp_processor_id())
> score++;
This one does not work either with BPF
> }
>
> > BPF makes a decision without knowing individual listeners states.
>
> But is the decision taken without considering compute_score() ? The point
> really was to be the least possibly intrusive and quite logical for the
> application : "disable SO_REUSEPORT when you don't want to participate to
> incoming load balancing anymore".
Whole point of BPF was to avoid iterate through all sockets [1],
and let user space use whatever selection logic it needs.
[1] This was okay with up to 16 sockets. But with 128 it does not scale.
If you really look at how BPF works, implementing another 'per listener' flag
would break the BPF selection.
You can certainly implement the SO_REUSEPORT_LISTEN_OFF by loading an
updated BPF, why should we add another way in the kernel to do the same,
in a way that would not work in some cases ?
^ permalink raw reply
* Attn My Dear
From: Mrs. Ann @ 2016-03-24 16:29 UTC (permalink / raw)
To: Recipients
Attn My Dear
We have finally arranged to deliver your package worth $5.8m USD
Through (DHL) Company. We were able to accomplish this through the help
Of IMF director Anderson Morgan and every necessary arrangement has
Been made successfully.
Contact Dr.mark milliams
Telephone: (+229-99653283)
Email: (dhlbenin35@yahoo.in)
Contact the (DHL) with your delivery information such as:
(1) Full names ---
(2) Phone line ---
(3) Country -----
(4) Age/sex ------
(5) Occupation:---
(6)Home address:--
And also be informed that delivery agent will leave to this country as
soon as you proceed with (DHL) Company and please ask them how much is they Security Keeping fee to enable the agent live this country by tomorrow morning please I am waiting to hear from you thank you and God bless
Sincerely
Mrs. Ann Godwin
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
^ permalink raw reply
* [PATCH] netpoll: Fix extra refcount release in netpoll_cleanup()
From: Bjorn Helgaas @ 2016-03-24 16:13 UTC (permalink / raw)
To: David S. Miller
Cc: Nikolay Aleksandrov, netdev, Neil Horman, Alexander Duyck,
linux-kernel
netpoll_setup() does a dev_hold() on np->dev, the netpoll device. If it
fails, it correctly does a dev_put() but leaves np->dev set. If we call
netpoll_cleanup() after the failure, np->dev is still set so we do another
dev_put(), which decrements the refcount an extra time.
It's questionable to call netpoll_cleanup() after netpoll_setup() fails,
but it can be difficult to find the problem, and we can easily avoid it in
this case. The extra decrements can lead to hangs like this:
unregister_netdevice: waiting for bond0 to become free. Usage count = -3
In __netpoll_setup(), don't set np->dev until we know we're going to
succeed.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
---
net/core/netpoll.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 94acfc8..32e373e 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -603,7 +603,6 @@ int __netpoll_setup(struct netpoll *np, struct net_device *ndev)
const struct net_device_ops *ops;
int err;
- np->dev = ndev;
strlcpy(np->dev_name, ndev->name, IFNAMSIZ);
INIT_WORK(&np->cleanup_work, netpoll_async_cleanup);
@@ -628,7 +627,7 @@ int __netpoll_setup(struct netpoll *np, struct net_device *ndev)
atomic_set(&npinfo->refcnt, 1);
- ops = np->dev->netdev_ops;
+ ops = ndev->netdev_ops;
if (ops->ndo_netpoll_setup) {
err = ops->ndo_netpoll_setup(ndev, npinfo);
if (err)
@@ -639,6 +638,7 @@ int __netpoll_setup(struct netpoll *np, struct net_device *ndev)
atomic_inc(&npinfo->refcnt);
}
+ np->dev = ndev;
npinfo->netpoll = np;
/* last thing to do is link it to the net device structure */
^ permalink raw reply related
* [PATCH net] switchdev: fix typo in comments/doc
From: Nicolas Dichtel @ 2016-03-24 15:50 UTC (permalink / raw)
To: davem; +Cc: netdev, Nicolas Dichtel
Two minor typo.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
Documentation/networking/switchdev.txt | 2 +-
net/switchdev/switchdev.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/networking/switchdev.txt b/Documentation/networking/switchdev.txt
index fad63136ee3e..2f659129694b 100644
--- a/Documentation/networking/switchdev.txt
+++ b/Documentation/networking/switchdev.txt
@@ -386,7 +386,7 @@ used. First phase is to "prepare" anything needed, including various checks,
memory allocation, etc. The goal is to handle the stuff that is not unlikely
to fail here. The second phase is to "commit" the actual changes.
-Switchdev provides an inftrastructure for sharing items (for example memory
+Switchdev provides an infrastructure for sharing items (for example memory
allocations) between the two phases.
The object created by a driver in "prepare" phase and it is queued up by:
diff --git a/net/switchdev/switchdev.c b/net/switchdev/switchdev.c
index 8b5833c1ff2e..2b9b98f1c2ff 100644
--- a/net/switchdev/switchdev.c
+++ b/net/switchdev/switchdev.c
@@ -1079,7 +1079,7 @@ nla_put_failure:
* @filter_dev: filter device
* @idx:
*
- * Delete FDB entry from switch device.
+ * Dump FDB entries from switch device.
*/
int switchdev_port_fdb_dump(struct sk_buff *skb, struct netlink_callback *cb,
struct net_device *dev,
--
2.4.2
^ permalink raw reply related
* [PATCH iproute2 master 2/2] geneve: add support to set flow label
From: Daniel Borkmann @ 2016-03-24 15:49 UTC (permalink / raw)
To: stephen; +Cc: netdev, Daniel Borkmann
In-Reply-To: <cover.1458833866.git.daniel@iogearbox.net>
Follow-up for kernel commit 8eb3b99554b8 ("geneve: support setting
IPv6 flow label") to allow setting the label for the device config.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
ip/iplink_geneve.c | 29 ++++++++++++++++++++++++-----
man/man8/ip-link.8.in | 6 ++++++
2 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/ip/iplink_geneve.c b/ip/iplink_geneve.c
index 16e70fd..685a0eb 100644
--- a/ip/iplink_geneve.c
+++ b/ip/iplink_geneve.c
@@ -18,14 +18,15 @@
static void print_explain(FILE *f)
{
fprintf(f, "Usage: ... geneve id VNI remote ADDR\n");
- fprintf(f, " [ ttl TTL ] [ tos TOS ]\n");
+ fprintf(f, " [ ttl TTL ] [ tos TOS ] [ flowlabel LABEL ]\n");
fprintf(f, " [ dstport PORT ] [ [no]external ]\n");
fprintf(f, " [ [no]udpcsum ] [ [no]udp6zerocsumtx ] [ [no]udp6zerocsumrx ]\n");
fprintf(f, "\n");
- fprintf(f, "Where: VNI := 0-16777215\n");
- fprintf(f, " ADDR := IP_ADDRESS\n");
- fprintf(f, " TOS := { NUMBER | inherit }\n");
- fprintf(f, " TTL := { 1..255 | inherit }\n");
+ fprintf(f, "Where: VNI := 0-16777215\n");
+ fprintf(f, " ADDR := IP_ADDRESS\n");
+ fprintf(f, " TOS := { NUMBER | inherit }\n");
+ fprintf(f, " TTL := { 1..255 | inherit }\n");
+ fprintf(f, " LABEL := 0-1048575\n");
}
static void explain(void)
@@ -40,6 +41,7 @@ static int geneve_parse_opt(struct link_util *lu, int argc, char **argv,
int vni_set = 0;
__u32 daddr = 0;
struct in6_addr daddr6 = IN6ADDR_ANY_INIT;
+ __u32 label = 0;
__u8 ttl = 0;
__u8 tos = 0;
__u16 dstport = 0;
@@ -90,6 +92,15 @@ static int geneve_parse_opt(struct link_util *lu, int argc, char **argv,
tos = uval;
} else
tos = 1;
+ } else if (!matches(*argv, "label") ||
+ !matches(*argv, "flowlabel")) {
+ __u32 uval;
+
+ NEXT_ARG();
+ if (get_u32(&uval, *argv, 0) ||
+ (uval & ~LABEL_MAX_MASK))
+ invarg("invalid flowlabel", *argv);
+ label = htonl(uval);
} else if (!matches(*argv, "dstport")) {
NEXT_ARG();
if (get_u16(&dstport, *argv, 0))
@@ -150,6 +161,7 @@ static int geneve_parse_opt(struct link_util *lu, int argc, char **argv,
addattr_l(n, 1024, IFLA_GENEVE_REMOTE, &daddr, 4);
if (memcmp(&daddr6, &in6addr_any, sizeof(daddr6)) != 0)
addattr_l(n, 1024, IFLA_GENEVE_REMOTE6, &daddr6, sizeof(struct in6_addr));
+ addattr32(n, 1024, IFLA_GENEVE_LABEL, label);
addattr8(n, 1024, IFLA_GENEVE_TTL, ttl);
addattr8(n, 1024, IFLA_GENEVE_TOS, tos);
if (dstport)
@@ -214,6 +226,13 @@ static void geneve_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[])
fprintf(f, "tos %#x ", tos);
}
+ if (tb[IFLA_GENEVE_LABEL]) {
+ __u32 label = rta_getattr_u32(tb[IFLA_GENEVE_LABEL]);
+
+ if (label)
+ fprintf(f, "flowlabel %#x ", ntohl(label));
+ }
+
if (tb[IFLA_GENEVE_PORT])
fprintf(f, "dstport %u ",
ntohs(rta_getattr_u16(tb[IFLA_GENEVE_PORT])));
diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in
index f115c19..8055114 100644
--- a/man/man8/ip-link.8.in
+++ b/man/man8/ip-link.8.in
@@ -752,6 +752,8 @@ the following additional arguments are supported:
.BI ttl " TTL "
] [
.BI tos " TOS "
+] [
+.BI flowlabel " FLOWLABEL "
]
.in +8
@@ -771,6 +773,10 @@ the following additional arguments are supported:
.BI tos " TOS"
- specifies the TOS value to use in outgoing packets.
+.sp
+.BI flowlabel " FLOWLABEL"
+- specifies the flow label to use in outgoing packets.
+
.in -8
.TP
--
1.9.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox