* [PATCH net-next 0/4] ipv6: coding style improvements
From: Ian Morris @ 2014-09-02 19:16 UTC (permalink / raw)
To: netdev; +Cc: Ian Morris
This sequences of patches makes adjustments to the ipv6 code to try to better
follow the kernel coding style guidelines. No changes to the resultant object
code is detected by objdiff.
Ian Morris (4):
ipv6: coding style - no assignment in if statements
ipv6: coding style - min to min_t conversion
ipv6: coding style - convert printk
ipv6: coding style - cleanse bracing
net/ipv6/addrconf.c | 30 ++++++++++++++++------------
net/ipv6/addrconf_core.c | 3 +--
net/ipv6/ah6.c | 7 ++++---
net/ipv6/datagram.c | 3 ++-
net/ipv6/esp6.c | 3 ++-
net/ipv6/exthdrs_core.c | 6 +++---
net/ipv6/icmp.c | 3 ++-
net/ipv6/ip6_fib.c | 4 ++--
net/ipv6/ip6_flowlabel.c | 9 ++++++---
net/ipv6/ip6_gre.c | 4 ++--
net/ipv6/ip6_input.c | 16 +++++++--------
net/ipv6/ip6_output.c | 32 ++++++++++++++++--------------
net/ipv6/ip6_tunnel.c | 22 ++++++++++-----------
net/ipv6/ip6_vti.c | 4 ++--
net/ipv6/ip6mr.c | 13 ++++++------
net/ipv6/ipv6_sockglue.c | 7 ++++---
net/ipv6/mcast.c | 48 ++++++++++++++++++++++++++-------------------
net/ipv6/ndisc.c | 25 ++++++++++-------------
net/ipv6/ping.c | 8 ++++----
net/ipv6/raw.c | 3 ++-
net/ipv6/reassembly.c | 3 ++-
net/ipv6/route.c | 25 +++++++++++------------
net/ipv6/sit.c | 7 ++++---
net/ipv6/tcp_ipv6.c | 10 ++++++----
net/ipv6/udp.c | 26 ++++++++++++------------
net/ipv6/xfrm6_output.c | 4 ++--
net/ipv6/xfrm6_protocol.c | 25 ++++++++++++++---------
net/ipv6/xfrm6_tunnel.c | 3 ++-
28 files changed, 191 insertions(+), 162 deletions(-)
--
1.7.9.5
^ permalink raw reply
* Re: RTNL: assertion failed at net/ipv6/addrconf.c (1699)
From: Vlad Yasevich @ 2014-09-02 19:08 UTC (permalink / raw)
To: Cong Wang, Eric Dumazet
Cc: Hannes Frederic Sowa, Sabrina Dubroca, Tommi Rantala,
David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, trinity,
Dave Jones
In-Reply-To: <CAHA+R7PY=Pu7VKA3wp1DxeJRckxPNWL-xfv2XXkpaY935kt61A@mail.gmail.com>
On 09/02/2014 02:15 PM, Cong Wang wrote:
> On Tue, Sep 2, 2014 at 11:11 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> On Tue, 2014-09-02 at 11:04 -0700, Cong Wang wrote:
>>> On Tue, Sep 2, 2014 at 10:58 AM, Hannes Frederic Sowa
>>
>>>> I definitely don't have a problem cleaning this up in net-next. I wanted
>>>> a minimal patch for stable because I didn't check history where and when
>>>> additional users of dev_get_by_flags_rcu were removed.
>>>
>>> `git grep` should show you we only have one caller. Apparently we don't
>>> care about any out-of-tree module.
>>
>> Point is : you did not check if some stable versions had more callers.
>>
>> Its very nice you checked current version, but it is not enough for a
>> stable candidate.
>
> That is what we do when backporting patches, I can do that if David asks
> me to backport it, but you know for netdev that is David's work.
>
> (I am not saying I don't want to help him, I just want to point out the fact.
> I am very pleased to help David for stable backports as long as he asks)
Instead of helping after the fact, why not arrange the patches so that it's
not such a big issue. Leave the _rcu variant alone. Add an _rtnl variant
of the function and use that in the patch. Have a follow-on patch that
removes the _rcu variant all by itself. This way backports become easier,
and if anyone wants the _rcu variant back, all they have to do is revert
a very simple commit.
-vlad
^ permalink raw reply
* Re: RTNL: assertion failed at net/ipv6/addrconf.c (1699)
From: Hannes Frederic Sowa @ 2014-09-02 19:02 UTC (permalink / raw)
To: Cong Wang
Cc: Sabrina Dubroca, Tommi Rantala, David S. Miller, Alexey Kuznetsov,
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML,
trinity, Dave Jones
In-Reply-To: <CAHA+R7MMe+O9-sNHQvgOO78tBzDy+hO+GtJFsuJPKx0eG6eMaw@mail.gmail.com>
On Di, 2014-09-02 at 11:40 -0700, Cong Wang wrote:
> On Tue, Sep 2, 2014 at 11:18 AM, Hannes Frederic Sowa
> <hannes@stressinduktion.org> wrote:
> > Those ASSERT_RTNLs were misplaced and only caught the callers mostly
> > from addrconf.c. I don't mind getting reports from stable kernel users
> > and fixing those, too (or help fixing those). ASSERT_RTNL is not
> > dangerous.
> >
> > We had a long history in not correctly using rtnl lock in ipv6/multicast
> > code and those wrongfully placed ASSERT_RTNLs were my bad when I fixed
> > the duplicate address detection handling.
> >
> > If enough multicast addresses are subscribed to an interface we might
> > again get those splats because enabling promisc mode on an interface
> > will also check for rtnl lock.
> >
>
> Sure, I never doubt adding ASSERT_RTNL() is helpful, I just still think
> this should be for net-next, or at least a separated patch. I don't want
> my patch to be blamed in others' "Fixes:". :)
Come on, that's why we have community review. Nobody blames anyone
because of added regressions. It's more a fault of the community then,
and it works out fairly good I think! Even others are keen on fixing
your bugs sometimes. ;)
If fixes tag is well researched, it won't point to the addition of
ASSERT_RTNL() but your patch would help to discover a bug somewhere else
in the stack.
I think for this patch a fixes-tag is hard to find because it is hard to
find because it dates back to the beginning of the git history IMHO.
Bye,
Hannes
^ permalink raw reply
* Re: [net PATCH 1/1] drivers: net: cpsw: dual_emac: fix reducing of rx descriptor during ifdown
From: David Miller @ 2014-09-02 18:54 UTC (permalink / raw)
To: mugunthanvnm; +Cc: netdev
In-Reply-To: <54058C01.3010402@ti.com>
From: Mugunthan V N <mugunthanvnm@ti.com>
Date: Tue, 2 Sep 2014 14:51:05 +0530
> When ifup and ifdown is run continuously, for each spilled packet (for
> interface which is down) from DMA, the total number of rx descriptor
> goes down and at one instance all the descriptor is lost and both the
> interface stops working.
>
> To recover from this we need to put down both the interface and open the
> interface which will re-init the DMA which intern queues fresh set of
> skbs for rx.
But you still should not receive packets for a netdev which is down.
As far as I can tell, you're feeding it into the stack still.
Also this doesn't explain why the "status < 0" case applies to this
new logic, you have not explained that at all.
^ permalink raw reply
* Re: [RFC PATCH] netlink: Safer deletion of sk_bind_node
From: David Miller @ 2014-09-02 18:52 UTC (permalink / raw)
To: harish_kandiga
Cc: dborkman, tgraf, ebiederm, darkjames-ws, rgb, eric.dumazet,
stephen, netdev, linux-kernel
In-Reply-To: <54058376.9090700@mentor.com>
From: Harish Jenny Kandiga Nagaraj <harish_kandiga@mentor.com>
Date: Tue, 2 Sep 2014 14:14:38 +0530
> In one of our random test runs we observed the crash mentioned in the previous mail.
>
> After debugging we found out that the call flow of the inline and static functions were
> netlink_release
> -----netlink_remove
> ---------__sk_del_bind_node
> --------------__hlist_del
>
> *pprev was NULL in __hlist_del function while deleting &sk->sk_bind_node hlist_node. Hence the patch was given.
>
> In netlink_remove function , first the sk_del_node_init function will be called. This internally calls __sk_del_node_init function. While deleting &sk->sk_node hlist_node using __sk_del_node function there is a NULL check with sk_hashed function.
>
> Why there is no NULL check for *pprev while deleting &sk->sk_bind_node ?
Because if ->subscriptions is non-zero, it must be on a list, and therefore
pprev must be non-NULL.
^ permalink raw reply
* Re: [PATCH net-next v3 2/2] ipv4: implement igmp_qrv sysctl to tune igmp robustness variable
From: Flavio Leitner @ 2014-09-02 18:51 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: netdev
In-Reply-To: <b24ad902c532616c7683565df3a0fcc9d925da9c.1409665378.git.hannes@stressinduktion.org>
On Tue, Sep 02, 2014 at 03:49:26PM +0200, Hannes Frederic Sowa wrote:
> As in IPv6 people might increase the igmp query robustness variable to
> make sure unsolicited state change reports aren't lost on the network. Add
> and document this new knob to igmp code.
>
> RFCs allow tuning this parameter back to first IGMP RFC, so we also use
> this setting for all counters, including source specific multicast.
>
> Also take over sysctl value when upping the interface and don't reuse
> the last one seen on the interface.
>
> Cc: Flavio Leitner <fbl@redhat.com>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> ---
Thanks again,
Acked-by: Flavio Leitner <fbl@redhat.com>
^ permalink raw reply
* Re: [PATCH net-next v3 1/2] ipv6: add sysctl_mld_qrv to configure query robustness variable
From: Flavio Leitner @ 2014-09-02 18:50 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: netdev
In-Reply-To: <3f38fb1c0c5544de4cea8bb13e0adcbba17bebd3.1409665378.git.hannes@stressinduktion.org>
On Tue, Sep 02, 2014 at 03:49:25PM +0200, Hannes Frederic Sowa wrote:
> This patch adds a new sysctl_mld_qrv knob to configure the mldv1/v2 query
> robustness variable. It specifies how many retransmit of unsolicited mld
> retransmit should happen. Admins might want to tune this on lossy links.
>
> Also reset mld state on interface down/up, so we pick up new sysctl
> settings during interface up event.
>
> IPv6 certification requests this knob to be available.
>
> I didn't make this knob netns specific, as it is mostly a setting in a
> physical environment and should be per host.
>
> Cc: Flavio Leitner <fbl@redhat.com>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> ---
Thanks very much Hannes!
Acked-by: Flavio Leitner <fbl@redhat.com>
^ permalink raw reply
* Re: spam anyone?
From: David Miller @ 2014-09-02 18:49 UTC (permalink / raw)
To: xiaodi; +Cc: netdev
In-Reply-To: <54056E17.10606@sjtu.edu.cn>
From: Larry Xiao <xiaodi@sjtu.edu.cn>
Date: Tue, 02 Sep 2014 15:13:27 +0800
> I didn't see anyone complain about spam before.
> So I don't know if it's only me receiving many spams like this one.
>
> (I don't know if this email will go through .. )
It happens, the best I can do is continue teaching bogofilter about
it.
^ permalink raw reply
* Re: RTNL: assertion failed at net/ipv6/addrconf.c (1699)
From: Cong Wang @ 2014-09-02 18:40 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: Sabrina Dubroca, Tommi Rantala, David S. Miller, Alexey Kuznetsov,
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML,
trinity, Dave Jones
In-Reply-To: <1409681914.978561.162800349.5A7FA784@webmail.messagingengine.com>
On Tue, Sep 2, 2014 at 11:18 AM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> Those ASSERT_RTNLs were misplaced and only caught the callers mostly
> from addrconf.c. I don't mind getting reports from stable kernel users
> and fixing those, too (or help fixing those). ASSERT_RTNL is not
> dangerous.
>
> We had a long history in not correctly using rtnl lock in ipv6/multicast
> code and those wrongfully placed ASSERT_RTNLs were my bad when I fixed
> the duplicate address detection handling.
>
> If enough multicast addresses are subscribed to an interface we might
> again get those splats because enabling promisc mode on an interface
> will also check for rtnl lock.
>
Sure, I never doubt adding ASSERT_RTNL() is helpful, I just still think
this should be for net-next, or at least a separated patch. I don't want
my patch to be blamed in others' "Fixes:". :)
^ permalink raw reply
* Re: RTNL: assertion failed at net/ipv6/addrconf.c (1699)
From: Cong Wang @ 2014-09-02 18:37 UTC (permalink / raw)
To: Eric Dumazet
Cc: Hannes Frederic Sowa, Sabrina Dubroca, Tommi Rantala,
David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, trinity,
Dave Jones
In-Reply-To: <1409682093.26422.5.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, Sep 2, 2014 at 11:21 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2014-09-02 at 11:15 -0700, Cong Wang wrote:
>
>> That is what we do when backporting patches, I can do that if David asks
>> me to backport it, but you know for netdev that is David's work.
>>
>> (I am not saying I don't want to help him, I just want to point out the fact.
>> I am very pleased to help David for stable backports as long as he asks)
>
> Problem is : your patch submission do not identify bug origin.
>
> You claim you want to help, but you do not provide the basic thing that
> _really_ helps.
>
> The proper way to identify bug origin is to add in the headers one
> line :
>
> Fixes: 12-digit-SHA1 ("patch title")
>
Since when "Fixes:" tag becomes mandatory for a stable patch?
At least netdev-FAQ is not updated. ;-) I 100% agree "Fixes:"
is helpful when backporting patches, but it is not mandatory currently.
For this patch, I was too lazy to dig the history, it looks like this is
caused by the following commit:
commit c15b1ccadb323ea50023e8f1cca2954129a62b51
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Thu Mar 27 18:28:07 2014 +0100
ipv6: move DAD and addrconf_verify processing to workqueue
Thanks.
^ permalink raw reply
* Re: [PATCH net] core: Don't attempt to load the "" driver.
From: Cong Wang @ 2014-09-02 18:25 UTC (permalink / raw)
To: David Laight; +Cc: Linux Netdev List, David Miller
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D174856B9@AcuExch.aculab.com>
On Tue, Sep 2, 2014 at 6:48 AM, David Laight <David.Laight@aculab.com> wrote:
> While the applications shouldn't be calling an SIOCxxx ioctl with ifr_name[0] == 0
> the kernel shouldn't be tracing the error either.
>
Why don't we reject this empty string? It doesn't look like a valid one.
I assume this is for compatibility?
^ permalink raw reply
* Re: RTNL: assertion failed at net/ipv6/addrconf.c (1699)
From: Eric Dumazet @ 2014-09-02 18:21 UTC (permalink / raw)
To: Cong Wang
Cc: Hannes Frederic Sowa, Sabrina Dubroca, Tommi Rantala,
David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, trinity,
Dave Jones
In-Reply-To: <CAHA+R7PY=Pu7VKA3wp1DxeJRckxPNWL-xfv2XXkpaY935kt61A@mail.gmail.com>
On Tue, 2014-09-02 at 11:15 -0700, Cong Wang wrote:
> That is what we do when backporting patches, I can do that if David asks
> me to backport it, but you know for netdev that is David's work.
>
> (I am not saying I don't want to help him, I just want to point out the fact.
> I am very pleased to help David for stable backports as long as he asks)
Problem is : your patch submission do not identify bug origin.
You claim you want to help, but you do not provide the basic thing that
_really_ helps.
The proper way to identify bug origin is to add in the headers one
line :
Fixes: 12-digit-SHA1 ("patch title")
^ permalink raw reply
* Re: RTNL: assertion failed at net/ipv6/addrconf.c (1699)
From: Hannes Frederic Sowa @ 2014-09-02 18:18 UTC (permalink / raw)
To: Cong Wang
Cc: Sabrina Dubroca, Tommi Rantala, David S. Miller, Alexey Kuznetsov,
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML,
trinity, Dave Jones
In-Reply-To: <CAHA+R7Mwy1SCpEUgGf9BdLEro6N-3t89KU=xL0iuzgOppXELrQ@mail.gmail.com>
On Tue, Sep 2, 2014, at 20:04, Cong Wang wrote:
> On Tue, Sep 2, 2014 at 10:58 AM, Hannes Frederic Sowa
> <hannes@stressinduktion.org> wrote:
> > Hi Cong,
> >
> > On Tue, Sep 2, 2014, at 18:50, Cong Wang wrote:
> >> On Fri, Aug 29, 2014 at 6:51 PM, Hannes Frederic Sowa
> >> <hannes@stressinduktion.org> wrote:
> >> >
> >> > Also rtnl_lock and rcu_read_lock compose in that order, so we don't need
> >> > to change dev_get_by_flags, but as this is the only user it sure is
> >> > possible. RCU locked version is just easier composeable, so I wouldn't
> >> > touch that if needed in future, just also take rcu lock as before.
> >>
> >> There is no point to keep RCU read lock if we have rtnl lock,
> >> I don't know why you don't want to change dev_get_by_flags(),
> >> it is pretty easy to do since it only has one caller.
> >
> > I definitely don't have a problem cleaning this up in net-next. I wanted
> > a minimal patch for stable because I didn't check history where and when
> > additional users of dev_get_by_flags_rcu were removed.
>
> `git grep` should show you we only have one caller. Apparently we don't
> care about any out-of-tree module.
Sure, I don't care about out-of-tree modules either. I just wanted to
make it easier to backport. Current patch is almost headache free to
backport.
> >> Even if you really need RCU in future, you are always welcome
> >> to bring it back when you do, sorry we should never be blocked by
> >> code NOT merged yet.
> >>
> >> >
> >> > Also we should move ASSERT_RTNL checks from addrconf_join_solict to
> >> > ipv6_dev_mc_inc/dec.
> >> >
> >>
> >> Make it another patch.
> >
> > It is just one logical change, moving ASSERT_RTNLs to places where they
> > better catch invalid callstacks.
> >
>
> Conflicts with what you claimed above. :)
Those ASSERT_RTNLs were misplaced and only caught the callers mostly
from addrconf.c. I don't mind getting reports from stable kernel users
and fixing those, too (or help fixing those). ASSERT_RTNL is not
dangerous.
We had a long history in not correctly using rtnl lock in ipv6/multicast
code and those wrongfully placed ASSERT_RTNLs were my bad when I fixed
the duplicate address detection handling.
If enough multicast addresses are subscribed to an interface we might
again get those splats because enabling promisc mode on an interface
will also check for rtnl lock.
Bye,
Hannes
^ permalink raw reply
* [PATCH net-next] net: systemport: update UMAC_CMD only when link is detected
From: Florian Fainelli @ 2014-09-02 18:17 UTC (permalink / raw)
To: netdev; +Cc: davem, Florian Fainelli
When we bring the interface down, phy_stop() will schedule the PHY
state machine to call our link adjustment callback. By the time we do so,
we may have clock gated off the SYSTEMPORT hardware block, and this will
cause bus errors to happen in bcm_sysport_adj_link():
Make sure that we only touch the UMAC_CMD register when there is an
actual link. This is safe to do for two reasons:
- updating the Ethernet MAC registers only make sense when a physical
link is present
- the PHY library state machine first set phydev->link = 0 before
invoking phydev->adjust_link in the PHY_HALTED case
This is a similar fix to the GENET one:
c677ba8b3c47650358572091ed8a6af50bfca877 ("net: bcmgenet: update
UMAC_CMD only when link is detected").
Fixes: 80105befdb4b ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/broadcom/bcmsysport.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c b/drivers/net/ethernet/broadcom/bcmsysport.c
index 8f91de169663..662cf2222873 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -1071,16 +1071,19 @@ static void bcm_sysport_adj_link(struct net_device *dev)
if (!phydev->pause)
cmd_bits |= CMD_RX_PAUSE_IGNORE | CMD_TX_PAUSE_IGNORE;
- if (changed) {
+ if (!changed)
+ return;
+
+ if (phydev->link) {
reg = umac_readl(priv, UMAC_CMD);
reg &= ~((CMD_SPEED_MASK << CMD_SPEED_SHIFT) |
CMD_HD_EN | CMD_RX_PAUSE_IGNORE |
CMD_TX_PAUSE_IGNORE);
reg |= cmd_bits;
umac_writel(priv, reg, UMAC_CMD);
-
- phy_print_status(priv->phydev);
}
+
+ phy_print_status(priv->phydev);
}
static int bcm_sysport_init_tx_ring(struct bcm_sysport_priv *priv,
--
1.9.1
^ permalink raw reply related
* Re: RTNL: assertion failed at net/ipv6/addrconf.c (1699)
From: Cong Wang @ 2014-09-02 18:15 UTC (permalink / raw)
To: Eric Dumazet
Cc: Hannes Frederic Sowa, Sabrina Dubroca, Tommi Rantala,
David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, trinity,
Dave Jones
In-Reply-To: <1409681487.26422.1.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, Sep 2, 2014 at 11:11 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2014-09-02 at 11:04 -0700, Cong Wang wrote:
>> On Tue, Sep 2, 2014 at 10:58 AM, Hannes Frederic Sowa
>
>> > I definitely don't have a problem cleaning this up in net-next. I wanted
>> > a minimal patch for stable because I didn't check history where and when
>> > additional users of dev_get_by_flags_rcu were removed.
>>
>> `git grep` should show you we only have one caller. Apparently we don't
>> care about any out-of-tree module.
>
> Point is : you did not check if some stable versions had more callers.
>
> Its very nice you checked current version, but it is not enough for a
> stable candidate.
That is what we do when backporting patches, I can do that if David asks
me to backport it, but you know for netdev that is David's work.
(I am not saying I don't want to help him, I just want to point out the fact.
I am very pleased to help David for stable backports as long as he asks)
^ permalink raw reply
* Re: RTNL: assertion failed at net/ipv6/addrconf.c (1699)
From: Eric Dumazet @ 2014-09-02 18:11 UTC (permalink / raw)
To: Cong Wang
Cc: Hannes Frederic Sowa, Sabrina Dubroca, Tommi Rantala,
David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, trinity,
Dave Jones
In-Reply-To: <CAHA+R7Mwy1SCpEUgGf9BdLEro6N-3t89KU=xL0iuzgOppXELrQ@mail.gmail.com>
On Tue, 2014-09-02 at 11:04 -0700, Cong Wang wrote:
> On Tue, Sep 2, 2014 at 10:58 AM, Hannes Frederic Sowa
> > I definitely don't have a problem cleaning this up in net-next. I wanted
> > a minimal patch for stable because I didn't check history where and when
> > additional users of dev_get_by_flags_rcu were removed.
>
> `git grep` should show you we only have one caller. Apparently we don't
> care about any out-of-tree module.
Point is : you did not check if some stable versions had more callers.
Its very nice you checked current version, but it is not enough for a
stable candidate.
^ permalink raw reply
* [Patch net] ipv6: fix rtnl lock assertion failure in ipv6_sock_ac_join()
From: Cong Wang @ 2014-09-02 18:07 UTC (permalink / raw)
To: netdev; +Cc: Cong Wang, David S. Miller, Hannes Frederic Sowa, Sabrina Dubroca
Tommi reported the following RTNL lock assertion failure:
[ 77.297196] RTNL: assertion failed at net/ipv6/addrconf.c (1699)
[ 77.298080] CPU: 0 PID: 4842 Comm: trinity-main Not tainted 3.17.0-rc2+ #30
[ 77.299039] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 77.299789] ffff88003d76a618 ffff880026133c50 ffffffff8238ba79
ffff880037c84520
[ 77.300829] ffff880026133c90 ffffffff820bd52b 0000000000000000
ffffffff82d86c40
[ 77.301869] 0000000000000000 00000000f76fd1e1 ffff8800382d8000
ffff8800382d8220
[ 77.302906] Call Trace:
[ 77.303246] [<ffffffff8238ba79>] dump_stack+0x4d/0x66
[ 77.303928] [<ffffffff820bd52b>] addrconf_join_solict+0x4b/0xb0
[ 77.304731] [<ffffffff820b031b>] ipv6_dev_ac_inc+0x2bb/0x330
[ 77.305498] [<ffffffff820b0060>] ? ac6_seq_start+0x260/0x260
[ 77.306257] [<ffffffff820b05fe>] ipv6_sock_ac_join+0x26e/0x360
[ 77.307046] [<ffffffff820b0429>] ? ipv6_sock_ac_join+0x99/0x360
[ 77.307798] [<ffffffff820cdd60>] do_ipv6_setsockopt.isra.5+0xa70/0xf20
This is due to we don't hold rtnl lock when calling addrconf_join_solict()
in ipv6_sock_ac_join(). So hold rtnl lock instead of RCU lock here,
after all it is not a hot path.
BTW, mcast _might_ have similar problem, but I don't touch it since no one
reports so far.
Reported-by: Tommi Rantala <tt.rantala@gmail.com>
Tested-by: Sabrina Dubroca <sd@queasysnail.net>
Cc: David S. Miller <davem@davemloft.net>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
include/linux/netdevice.h | 4 ++--
net/core/dev.c | 13 +++++++------
net/ipv6/anycast.c | 22 +++++++++++-----------
3 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 38377392..71838bb 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2074,8 +2074,8 @@ void __dev_remove_pack(struct packet_type *pt);
void dev_add_offload(struct packet_offload *po);
void dev_remove_offload(struct packet_offload *po);
-struct net_device *dev_get_by_flags_rcu(struct net *net, unsigned short flags,
- unsigned short mask);
+struct net_device *__dev_get_by_flags(struct net *net, unsigned short flags,
+ unsigned short mask);
struct net_device *dev_get_by_name(struct net *net, const char *name);
struct net_device *dev_get_by_name_rcu(struct net *net, const char *name);
struct net_device *__dev_get_by_name(struct net *net, const char *name);
diff --git a/net/core/dev.c b/net/core/dev.c
index ab9a165..343847a 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -897,23 +897,24 @@ struct net_device *dev_getfirstbyhwtype(struct net *net, unsigned short type)
EXPORT_SYMBOL(dev_getfirstbyhwtype);
/**
- * dev_get_by_flags_rcu - find any device with given flags
+ * __dev_get_by_flags - find any device with given flags
* @net: the applicable net namespace
* @if_flags: IFF_* values
* @mask: bitmask of bits in if_flags to check
*
* Search for any interface with the given flags. Returns NULL if a device
* is not found or a pointer to the device. Must be called inside
- * rcu_read_lock(), and result refcount is unchanged.
+ * rtnl_lock(), and result refcount is unchanged.
*/
-struct net_device *dev_get_by_flags_rcu(struct net *net, unsigned short if_flags,
- unsigned short mask)
+struct net_device *__dev_get_by_flags(struct net *net, unsigned short if_flags,
+ unsigned short mask)
{
struct net_device *dev, *ret;
+ ASSERT_RTNL();
ret = NULL;
- for_each_netdev_rcu(net, dev) {
+ for_each_netdev(net, dev) {
if (((dev->flags ^ if_flags) & mask) == 0) {
ret = dev;
break;
@@ -921,7 +922,7 @@ struct net_device *dev_get_by_flags_rcu(struct net *net, unsigned short if_flags
}
return ret;
}
-EXPORT_SYMBOL(dev_get_by_flags_rcu);
+EXPORT_SYMBOL(__dev_get_by_flags);
/**
* dev_valid_name - check if name is okay for network device
diff --git a/net/ipv6/anycast.c b/net/ipv6/anycast.c
index 2101832..484ed23 100644
--- a/net/ipv6/anycast.c
+++ b/net/ipv6/anycast.c
@@ -77,7 +77,7 @@ int ipv6_sock_ac_join(struct sock *sk, int ifindex, const struct in6_addr *addr)
pac->acl_next = NULL;
pac->acl_addr = *addr;
- rcu_read_lock();
+ rtnl_lock();
if (ifindex == 0) {
struct rt6_info *rt;
@@ -90,11 +90,11 @@ int ipv6_sock_ac_join(struct sock *sk, int ifindex, const struct in6_addr *addr)
goto error;
} else {
/* router, no matching interface: just pick one */
- dev = dev_get_by_flags_rcu(net, IFF_UP,
- IFF_UP | IFF_LOOPBACK);
+ dev = __dev_get_by_flags(net, IFF_UP,
+ IFF_UP | IFF_LOOPBACK);
}
} else
- dev = dev_get_by_index_rcu(net, ifindex);
+ dev = __dev_get_by_index(net, ifindex);
if (dev == NULL) {
err = -ENODEV;
@@ -136,7 +136,7 @@ int ipv6_sock_ac_join(struct sock *sk, int ifindex, const struct in6_addr *addr)
}
error:
- rcu_read_unlock();
+ rtnl_unlock();
if (pac)
sock_kfree_s(sk, pac, sizeof(*pac));
return err;
@@ -171,11 +171,11 @@ int ipv6_sock_ac_drop(struct sock *sk, int ifindex, const struct in6_addr *addr)
spin_unlock_bh(&ipv6_sk_ac_lock);
- rcu_read_lock();
- dev = dev_get_by_index_rcu(net, pac->acl_ifindex);
+ rtnl_lock();
+ dev = __dev_get_by_index(net, pac->acl_ifindex);
if (dev)
ipv6_dev_ac_dec(dev, &pac->acl_addr);
- rcu_read_unlock();
+ rtnl_unlock();
sock_kfree_s(sk, pac, sizeof(*pac));
return 0;
@@ -198,7 +198,7 @@ void ipv6_sock_ac_close(struct sock *sk)
spin_unlock_bh(&ipv6_sk_ac_lock);
prev_index = 0;
- rcu_read_lock();
+ rtnl_lock();
while (pac) {
struct ipv6_ac_socklist *next = pac->acl_next;
@@ -211,7 +211,7 @@ void ipv6_sock_ac_close(struct sock *sk)
sock_kfree_s(sk, pac, sizeof(*pac));
pac = next;
}
- rcu_read_unlock();
+ rtnl_unlock();
}
static void aca_put(struct ifacaddr6 *ac)
@@ -331,7 +331,7 @@ int __ipv6_dev_ac_dec(struct inet6_dev *idev, const struct in6_addr *addr)
return 0;
}
-/* called with rcu_read_lock() */
+/* called with rtnl_lock() */
static int ipv6_dev_ac_dec(struct net_device *dev, const struct in6_addr *addr)
{
struct inet6_dev *idev = __in6_dev_get(dev);
--
1.8.3.1
^ permalink raw reply related
* Re: RTNL: assertion failed at net/ipv6/addrconf.c (1699)
From: Cong Wang @ 2014-09-02 18:04 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: Sabrina Dubroca, Tommi Rantala, David S. Miller, Alexey Kuznetsov,
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML,
trinity, Dave Jones
In-Reply-To: <1409680684.972417.162793869.03CF8A61@webmail.messagingengine.com>
On Tue, Sep 2, 2014 at 10:58 AM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> Hi Cong,
>
> On Tue, Sep 2, 2014, at 18:50, Cong Wang wrote:
>> On Fri, Aug 29, 2014 at 6:51 PM, Hannes Frederic Sowa
>> <hannes@stressinduktion.org> wrote:
>> >
>> > Also rtnl_lock and rcu_read_lock compose in that order, so we don't need
>> > to change dev_get_by_flags, but as this is the only user it sure is
>> > possible. RCU locked version is just easier composeable, so I wouldn't
>> > touch that if needed in future, just also take rcu lock as before.
>>
>> There is no point to keep RCU read lock if we have rtnl lock,
>> I don't know why you don't want to change dev_get_by_flags(),
>> it is pretty easy to do since it only has one caller.
>
> I definitely don't have a problem cleaning this up in net-next. I wanted
> a minimal patch for stable because I didn't check history where and when
> additional users of dev_get_by_flags_rcu were removed.
`git grep` should show you we only have one caller. Apparently we don't
care about any out-of-tree module.
>
>> Even if you really need RCU in future, you are always welcome
>> to bring it back when you do, sorry we should never be blocked by
>> code NOT merged yet.
>>
>> >
>> > Also we should move ASSERT_RTNL checks from addrconf_join_solict to
>> > ipv6_dev_mc_inc/dec.
>> >
>>
>> Make it another patch.
>
> It is just one logical change, moving ASSERT_RTNLs to places where they
> better catch invalid callstacks.
>
Conflicts with what you claimed above. :)
^ permalink raw reply
* Re: [net-next PATCH 0/3] qdisc bulk dequeuing and utilizing delayed tailptr updates
From: Tom Herbert @ 2014-09-02 18:04 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: David S. Miller, Linux Netdev List, Florian Westphal,
Hannes Frederic Sowa, Daniel Borkmann
In-Reply-To: <20140902143254.1918.8419.stgit@dragon>
On Tue, Sep 2, 2014 at 7:35 AM, Jesper Dangaard Brouer
<brouer@redhat.com> wrote:
> This patchset uses DaveM's recent API changes to dev_hard_start_xmit(),
> from the qdisc layer, to implement dequeue bulking.
>
> Open questions:
>
> - For now set bulk limit to 8 packets, don't want to stress the driver
> avail ring_buffer space.
>
Please get limit from BQL also, see:
[PATCH net-next] net: Functions to report space available in device TX queues
> - We are not doing proper accounting for weight_p/quota in __qdisc_run(). Do we care?
>
> - Is the (!skb->next) check in dequeue necessary?
>
> - Do we need some checks in dev_requeue_skb() as we could be requeuing a SKB list?
>
> - Should we rename dequeue_skb() to dequeue_skb_list() ?
>
>
> Based on top of:
> commit 364a9e93243d ("sock: deduplicate errqueue dequeue")
>
> ---
>
> Jesper Dangaard Brouer (3):
> qdisc: sysctl to adjust bulk dequeue limit
> qdisc: bulk dequeue support for qdiscs with TCQ_F_ONETXQUEUE
> qdisc: adjustments for API allowing skb list xmits
>
>
> include/net/sch_generic.h | 2 ++
> net/core/sysctl_net_core.c | 9 +++++++++
> net/sched/sch_generic.c | 33 ++++++++++++++++++++++++++++-----
> 3 files changed, 39 insertions(+), 5 deletions(-)
>
> --
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: RTNL: assertion failed at net/ipv6/addrconf.c (1699)
From: Hannes Frederic Sowa @ 2014-09-02 17:58 UTC (permalink / raw)
To: Cong Wang
Cc: Sabrina Dubroca, Tommi Rantala, David S. Miller, Alexey Kuznetsov,
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML,
trinity, Dave Jones
In-Reply-To: <CAHA+R7ODa+LrdwSrS7HcBfwwq8_fpj-Ld0OCDtcOqkpCdZCvxg@mail.gmail.com>
Hi Cong,
On Tue, Sep 2, 2014, at 18:50, Cong Wang wrote:
> On Fri, Aug 29, 2014 at 6:51 PM, Hannes Frederic Sowa
> <hannes@stressinduktion.org> wrote:
> >
> > Also rtnl_lock and rcu_read_lock compose in that order, so we don't need
> > to change dev_get_by_flags, but as this is the only user it sure is
> > possible. RCU locked version is just easier composeable, so I wouldn't
> > touch that if needed in future, just also take rcu lock as before.
>
> There is no point to keep RCU read lock if we have rtnl lock,
> I don't know why you don't want to change dev_get_by_flags(),
> it is pretty easy to do since it only has one caller.
I definitely don't have a problem cleaning this up in net-next. I wanted
a minimal patch for stable because I didn't check history where and when
additional users of dev_get_by_flags_rcu were removed.
> Even if you really need RCU in future, you are always welcome
> to bring it back when you do, sorry we should never be blocked by
> code NOT merged yet.
>
> >
> > Also we should move ASSERT_RTNL checks from addrconf_join_solict to
> > ipv6_dev_mc_inc/dec.
> >
>
> Make it another patch.
It is just one logical change, moving ASSERT_RTNLs to places where they
better catch invalid callstacks.
Bye,
Hannes
^ permalink raw reply
* Re: [PATCH net-next] core: Simplify logic in dev_load().
From: Sergei Shtylyov @ 2014-09-02 17:49 UTC (permalink / raw)
To: David Laight, Linux Netdev List, David Miller
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D174856D6@AcuExch.aculab.com>
Hello.
On 09/02/2014 05:51 PM, David Laight wrote:
> The code in dev_load() is convoluted.
> Return early and remove the 'no_module' variable.
You forgot to sign off on the patch, so it can't be applied.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH net v2] tg3: prevent ifup/ifdown during PCI error recovery
From: Prashant Sreedharan @ 2014-09-02 17:32 UTC (permalink / raw)
To: Ivan Vecera; +Cc: netdev, Michael Chan
In-Reply-To: <1409574117-19435-1-git-send-email-ivecera@redhat.com>
On Mon, 2014-09-01 at 14:21 +0200, Ivan Vecera wrote:
> The patch fixes race conditions between PCI error recovery callbacks and
> potential ifup/ifdown.
>
> First, if ifup (tg3_open) is called between tg3_io_error_detected() and
> tg3_io_resume() then tp->timer is armed twice before expiry. Once during
> tg3_open() and again during tg3_io_resume(). This results in BUG
> at kernel/time/timer.c:945.
>
> Second, if ifdown (tg3_close) is called between tg3_io_error_detected()
> and tg3_io_resume() then tg3_napi_disable() is called twice without
> a tg3_napi_enable between. Once during tg3_io_error_detected() and again
> during tg3_close(). The tg3_io_resume() then hangs on rtnl_lock().
>
> v2: Added logging messages per Prashant's request
>
> Cc: Prashant Sreedharan <prashant@broadcom.com>
> Cc: Michael Chan <mchan@broadcom.com>
>
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Acked-by: Prashant Sreedharan <prashant@broadcom.com>
--
^ permalink raw reply
* Re: [PATCH net-next 2/2] sunvnet: Re-check for a VIO_DESC_READY data descriptor after short udelay()
From: Raghuram Kothakota @ 2014-09-02 17:33 UTC (permalink / raw)
To: Sowmini Varadhan; +Cc: David Miller, netdev
In-Reply-To: <20140902165659.GH31516@oracle.com>
On Sep 2, 2014, at 9:56 AM, Sowmini Varadhan <sowmini.varadhan@oracle.com> wrote:
> On (09/02/14 09:43), Raghuram Kothakota wrote:
>> We could optimize this a bit by not wait for normal traffic, I mean,
>> non-burst traffic
>> and apply the retry only when we detect a stream of packets?
>
> How could you tell the difference efficiently? You'd need to
> track some kind of history/state for inter-packet arrival time.
> All seems like over-kill (more useful to go and optimize other
> parts of the system, such as do less work in interrupt context).
>From what I see, the vnet_walk_rx() picks up packets in a while loop,
we could count the number of packets picked up in that loop and use
that count as a method to determine if we need to apply this retry or not.
That is, retry only if that counter is > x, that may avoid waiting for cases
where peer sent one packet only? It may be worth trying it
and see if it still keeps up the improvement that you saw.
-Raghuram
>
>> We could detect a stream based on how many packets are picked
>> up in this function, picking up 3 or more could be considered as a stream,
>> of course tune based on testing.
>>
>> You probably tried it already, but checking to see if you tried with
>> less number
>> of iterations, we could reduce the iterations if the numbers are equally good
>> with less iterations.
>
> yes, the 3 * 4 micro-seconds was arrived at heuristically.
>
> --Sowmini
>
^ permalink raw reply
* Re: [PATCH net-next 2/2] sunvnet: Re-check for a VIO_DESC_READY data descriptor after short udelay()
From: Sowmini Varadhan @ 2014-09-02 16:56 UTC (permalink / raw)
To: Raghuram Kothakota; +Cc: David Miller, netdev
In-Reply-To: <665366D4-384B-45E1-B371-239EA87F5A15@oracle.com>
On (09/02/14 09:43), Raghuram Kothakota wrote:
> We could optimize this a bit by not wait for normal traffic, I mean,
> non-burst traffic
> and apply the retry only when we detect a stream of packets?
How could you tell the difference efficiently? You'd need to
track some kind of history/state for inter-packet arrival time.
All seems like over-kill (more useful to go and optimize other
parts of the system, such as do less work in interrupt context).
> We could detect a stream based on how many packets are picked
> up in this function, picking up 3 or more could be considered as a stream,
> of course tune based on testing.
>
> You probably tried it already, but checking to see if you tried with
> less number
> of iterations, we could reduce the iterations if the numbers are equally good
> with less iterations.
yes, the 3 * 4 micro-seconds was arrived at heuristically.
--Sowmini
^ permalink raw reply
* [PATCH] 3c59x: avoid panic in boomerang_start_xmit when finding page address:
From: Neil Horman @ 2014-09-02 16:51 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, klassert, David S. Miller
This bug was reported on a very old kernel (RHEL6, 2.6.32-491.el6):
BUG: unable to handle kernel paging request at 00800000
IP: [<c04107b5>] nommu_map_page+0x15/0x110
*pdpt = 000000003454f001 *pde = 000000003f03d067
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/system/cpu/online
Modules linked in: nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs p4_clockmod
ipv6 ppdev parport_pc parport microcode iTCO_wdt iTCO_vendor_support 3c59x mii
dcdbas serio_raw snd_intel8x0 snd_ac97_codec ac97_bus snd_seq snd_seq_device
snd_pcm snd_timer snd soundcore snd_page_alloc i2c_i801 sg lpc_ich mfd_core ext4
jbd2 mbcache sr_mod cdrom sd_mod crc_t10dif pata_acpi ata_generic ata_piix
radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core dm_mirror dm_region_hash
dm_log dm_mod [last unloaded: mperf]
Pid: 4219, comm: nfsd Not tainted 2.6.32-491.el6.i686 #1 Dell Computer
Corporation OptiPlex GX240 /OptiPlex GX240
EIP: 0060:[<c04107b5>] EFLAGS: 00010246 CPU: 0
EIP is at nommu_map_page+0x15/0x110
EAX: 00000000 EBX: c0a83480 ECX: 00000000 EDX: 00800000
ESI: 00000000 EDI: f70e7860 EBP: e2d09b54 ESP: e2d09b24
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process nfsd (pid: 4219, ti=e2d08000 task=e2ceaaa0 task.ti=e2d08000)
Stack:
00000056 00000000 0000000e c65efd38 00000020 00000296 00000206 00000206
<0> c050c850 c0a83480 e2cef154 00000001 e2d09ba8 f8fcd585 00000510 00000001
<0> 00000000 00000000 f5172200 f8fdac00 0039ef8c f5277020 f70e7860 00000510
Call Trace:
[<c050c850>] ? page_address+0xd0/0xe0
[<f8fcd585>] ? boomerang_start_xmit+0x3b5/0x520 [3c59x]
[<c07b2975>] ? dev_hard_start_xmit+0xe5/0x400
[<f9182b00>] ? ip6_output_finish+0x0/0xf0 [ipv6]
[<c07ca053>] ? sch_direct_xmit+0x113/0x180
[<c07d5588>] ? nf_hook_slow+0x68/0x120
[<c07b2ea5>] ? dev_queue_xmit+0x1b5/0x290
[<f9182b6d>] ? ip6_output_finish+0x6d/0xf0 [ipv6]
[<f9184cb8>] ? ip6_xmit+0x3e8/0x490 [ipv6]
[<f91ab9f9>] ? inet6_csk_xmit+0x289/0x2f0 [ipv6]
[<c07f6451>] ? tcp_transmit_skb+0x431/0x7f0
[<c07a403f>] ? __alloc_skb+0x4f/0x140
[<c07f85a2>] ? tcp_write_xmit+0x1c2/0xa50
[<c07f90b1>] ? __tcp_push_pending_frames+0x31/0xe0
[<c07ea47a>] ? tcp_sendpage+0x44a/0x4b0
[<c07ea030>] ? tcp_sendpage+0x0/0x4b0
[<c079be1e>] ? kernel_sendpage+0x4e/0x90
[<f8457bb9>] ? svc_send_common+0xc9/0x120 [sunrpc]
[<f8457c85>] ? svc_sendto+0x75/0x1f0 [sunrpc]
[<c060d0d9>] ? _atomic_dec_and_lock+0x59/0x90
[<f87d55d0>] ? nfs3svc_encode_readres+0x0/0xc0 [nfsd]
[<f845876d>] ? svc_authorise+0x2d/0x40 [sunrpc]
[<f87d4410>] ? nfs3svc_release_fhandle+0x0/0x10 [nfsd]
[<f8455721>] ? svc_process_common+0xf1/0x5a0 [sunrpc]
[<f8457e86>] ? svc_tcp_sendto+0x36/0xa0 [sunrpc]
[<f8461778>] ? svc_send+0x98/0xd0 [sunrpc]
[<f87c698c>] ? nfsd+0xac/0x140 [nfsd]
[<c04470e0>] ? complete+0x40/0x60
[<f87c68e0>] ? nfsd+0x0/0x140 [nfsd]
[<c04802ac>] ? kthread+0x7c/0xa0
[<c0480230>] ? kthread+0x0/0xa0
[<c0409f9f>] ? kernel_thread_helper+0x7/0x10
Code: 8d b6 00 00 00 00 eb f8 8d b4 26 00 00 00 00 8d bc 27 00 00 00 00 55 89 e5
83 ec 30 89 75 f8 31 f6 89 7d fc 89 c7 89 c8 89 5d f4 <8b> 1a 8b 4d 08 c1 eb 19
c1 e3 04 8b 9b c0 29 c7 c0 83 e3 fc 29
But the problem seems to still exist upstream. It seems on 32 bit kernels
page_address() can reutrn a NULL value in some circumstances, and the
pci_map_single api isn't prepared to handle that (on this system it results in a
bogus pointer deference in nommu_map_page.
The fix is pretty easy, if we convert the 3c59x driver to use the more
convieient skb_frag_dma_map api we don't need to find the virtual address of the
page at all, and page gets mapped to the hardware properly. Verified to fix the
problem as described by the reporter.
Applies to the net tree
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: klassert@mathematik.tu-chemnitz.de
CC: "David S. Miller" <davem@davemloft.net>
---
drivers/net/ethernet/3com/3c59x.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/3com/3c59x.c b/drivers/net/ethernet/3com/3c59x.c
index 059c741..e55f39c 100644
--- a/drivers/net/ethernet/3com/3c59x.c
+++ b/drivers/net/ethernet/3com/3c59x.c
@@ -2177,10 +2177,10 @@ boomerang_start_xmit(struct sk_buff *skb, struct net_device *dev)
skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
vp->tx_ring[entry].frag[i+1].addr =
- cpu_to_le32(pci_map_single(
- VORTEX_PCI(vp),
- (void *)skb_frag_address(frag),
- skb_frag_size(frag), PCI_DMA_TODEVICE));
+ cpu_to_le32(skb_frag_dma_map(
+ &VORTEX_PCI(vp)->dev,
+ frag,
+ frag->page_offset, frag->size, PCI_DMA_TODEVICE));
if (i == skb_shinfo(skb)->nr_frags-1)
vp->tx_ring[entry].frag[i+1].length = cpu_to_le32(skb_frag_size(frag)|LAST_FRAG);
--
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