* Re: [PATCH] sh_eth: fix napi_{en|dis}able() calls racing against interrupts
From: David Miller @ 2013-09-04 18:56 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: netdev, nobuhiro.iwamatsu.yj, linux-sh
In-Reply-To: <201309040241.27834.sergei.shtylyov@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Wed, 4 Sep 2013 02:41:27 +0400
> While implementing NAPI for the driver, I overlooked the race conditions where
> interrupt handler might have called napi_schedule_prep() before napi_enable()
> was called or after napi_disable() was called. If RX interrupt happens, this
> would cause the endless interrupts and messages like:
>
> sh-eth eth0: ignoring interrupt, status 0x00040000, mask 0x01ff009f.
>
> The interrupt wouldn't even be masked by the kernel eventually since the handler
> would return IRQ_HANDLED all the time.
>
> As a fix, move napi_enable() call before request_irq() call and napi_disable()
> call after free_irq() call.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Applied and queued up for -stable, thanks!
^ permalink raw reply
* Re: [PATCH net-next v2 0/8] IPv6 MLD updates
From: David Miller @ 2013-09-04 18:54 UTC (permalink / raw)
To: dborkman; +Cc: netdev
In-Reply-To: <1378246784-21067-1-git-send-email-dborkman@redhat.com>
From: Daniel Borkmann <dborkman@redhat.com>
Date: Wed, 4 Sep 2013 00:19:36 +0200
> This set contains the non-RFC version of the previous submission entitled
> "[RFC PATCH net-next 0/7] IPv6 MLD updates". Most importantly it contains
> a fix for MLDv1/v2 switchback timeout where hosts currently are switching
> back from v1 compat mode to normal v2 too early (i.e. switchback time was
> <= 30secs instead of >= 260secs on default), and the set also contains a
> patch that allows for v2-only mode as per RFC recommendation. The rest is
> related to cleanups that make the code more readable resp. maintainable.
Series applied, thanks in particular for the 'net' merge conflict resolution
as that helps me a lot.
^ permalink raw reply
* Re: [PATCH] ipv6: fix null pointer dereference in __ip6addrlbl_add
From: Hannes Frederic Sowa @ 2013-09-04 18:51 UTC (permalink / raw)
To: David Miller; +Cc: michele, netdev, yoshfuji, sasha.levin
In-Reply-To: <20130904.141301.41040920905693536.davem@davemloft.net>
On Wed, Sep 04, 2013 at 02:13:01PM -0400, David Miller wrote:
> From: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Date: Tue, 3 Sep 2013 02:13:31 +0200
>
> > Hi!
> >
> > On Mon, Sep 02, 2013 at 10:31:28PM +0100, Michele Baldessari wrote:
> >> with the latest linux master git tree from Linus
> >> (248d296d6d9df384996c2ed95676b367d876d48c - 2 Sep) I can reproduceably oops
> >> the kernel with the following commands:
> >> ip addrlabel flush
> >> ip addrlabel add prefix ::1/128 label 0
> >> ip addrlabel add prefix ::/0 label 1
> >
> > Thanks for the report! This patch should fix this issue:
> >
> > [PATCH] ipv6: fix null pointer dereference in __ip6addrlbl_add
> >
> > Commit b67bfe0d42cac56c512dd5da4b1b347a23f4b70a ("hlist: drop
> > the node parameter from iterators") changed the behavior of
> > hlist_for_each_entry_safe to leave the p argument NULL.
> >
> > Fix this up by tracking the last argument.
> >
> > Reported-by: Michele Baldessari <michele@acksyn.org>
> > Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
> > Cc: Sasha Levin <sasha.levin@oracle.com>
> > Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
>
> Applied.
Sorry I forgot to mention that this patch is also applicable to solve
this issue in the longterm 3.10 kernel. Maybe this should go to stable?
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH] xen-netback: count number required slots for an skb more carefully
From: David Miller @ 2013-09-04 18:48 UTC (permalink / raw)
To: david.vrabel
Cc: xen-devel, konrad.wilk, boris.ostrovsky, ian.campbell, netdev
In-Reply-To: <1378229390-12919-1-git-send-email-david.vrabel@citrix.com>
Can you guys just post the patch you want applied once this thread
moves closer to a consensus? Thanks.
^ permalink raw reply
* Re: [PATCH net-next] tcp: better comments for RTO initiallization
From: David Miller @ 2013-09-04 18:42 UTC (permalink / raw)
To: ycheng; +Cc: ncardwell, edumazet, netdev
In-Reply-To: <1378242875-5172-1-git-send-email-ycheng@google.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Tue, 3 Sep 2013 14:14:35 -0700
> Commit 1b7fdd2ab585("tcp: do not use cached RTT for RTT estimation")
> removes important comments on how RTO is initialized and updated.
> Hopefully this patch puts those information back.
>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] vxlan: Optimize vxlan rcv
From: David Miller @ 2013-09-04 18:42 UTC (permalink / raw)
To: pshelar; +Cc: netdev, stephen
In-Reply-To: <1378226684-7751-1-git-send-email-pshelar@nicira.com>
From: Pravin B Shelar <pshelar@nicira.com>
Date: Tue, 3 Sep 2013 09:44:44 -0700
> vxlan-udp-recv function lookup vxlan_sock struct on every packet
> recv by using udp-port number. we can use sk->sk_user_data to
> store vxlan_sock and avoid lookup.
> I have open coded rcu-api to store and read vxlan_sock from
> sk_user_data to avoid sparse warning as sk_user_data is not
> __rcu pointer.
>
> Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 2/2] atm: he: print MAC via %pM
From: David Miller @ 2013-09-04 18:42 UTC (permalink / raw)
To: andriy.shevchenko; +Cc: chas, linux-atm-general, netdev
In-Reply-To: <1378210424-14781-2-git-send-email-andriy.shevchenko@linux.intel.com>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Tue, 3 Sep 2013 15:13:44 +0300
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 1/2] atm: nicstar: re-use native mac_pton() helper
From: David Miller @ 2013-09-04 18:42 UTC (permalink / raw)
To: andriy.shevchenko; +Cc: chas, linux-atm-general, netdev, andy.shevchenko
In-Reply-To: <1378210424-14781-1-git-send-email-andriy.shevchenko@linux.intel.com>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Tue, 3 Sep 2013 15:13:43 +0300
> From: Andy Shevchenko <andy.shevchenko@gmail.com>
>
> There is a nice helper to parse MAC. Let's use it and remove custom
> implementation.
>
> Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2] ipv6: Don't depend on per socket memory for neighbour discovery messages
From: David Miller @ 2013-09-04 18:41 UTC (permalink / raw)
To: tgraf; +Cc: netdev, eric.dumazet, hannes, swarren, festevam
In-Reply-To: <e4600dac657e1160da7a5e7758dcb973b616a10e.1378207925.git.tgraf@suug.ch>
From: Thomas Graf <tgraf@suug.ch>
Date: Tue, 3 Sep 2013 13:37:01 +0200
> Allocating skbs when sending out neighbour discovery messages
> currently uses sock_alloc_send_skb() based on a per net namespace
> socket and thus share a socket wmem buffer space.
>
> If a netdevice is temporarily unable to transmit due to carrier
> loss or for other reasons, the queued up ndisc messages will cosnume
> all of the wmem space and will thus prevent from any more skbs to
> be allocated even for netdevices that are able to transmit packets.
>
> The number of neighbour discovery messages sent is very limited,
> use of alloc_skb() bypasses the socket wmem buffer size enforcement
> while the manual call to skb_set_owner_w() maintains the socket
> reference needed for the IPv6 output path.
>
> This patch has orginally been posted by Eric Dumazet in a modified
> form.
>
> Signed-off-by: Thomas Graf <tgraf@suug.ch>
Applied, and queued up for -stable along with Cong Wang's ndisc_send_rs()
locking change.
Thanks.
^ permalink raw reply
* Re: [PATCH v5] ipv6:introduce function to find route for redirect
From: Hannes Frederic Sowa @ 2013-09-04 18:36 UTC (permalink / raw)
To: Duan Jiong; +Cc: davem, netdev
In-Reply-To: <52271D15.1000806@cn.fujitsu.com>
On Wed, Sep 04, 2013 at 07:44:21PM +0800, Duan Jiong wrote:
> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>
> RFC 4861 says that the IP source address of the Redirect is the
> same as the current first-hop router for the specified ICMP
> Destination Address, so the gateway should be taken into
> consideration when we find the route for redirect.
>
> There was once a check in commit
> a6279458c534d01ccc39498aba61c93083ee0372 ("NDISC: Search over
> all possible rules on receipt of redirect.") and the check
> went away in commit b94f1c0904da9b8bf031667afc48080ba7c3e8c9
> ("ipv6: Use icmpv6_notify() to propagate redirect, instead of
> rt6_redirect()").
>
> The bug is only "exploitable" on layer-2 because the source
> address of the redirect is checked to be a valid link-local
> address but it makes spoofing a lot easier in the same L2
> domain nonetheless.
>
> Thanks very much for Hannes's help.
>
> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Tested and looks good!
Thanks!
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
^ permalink raw reply
* Re: [PATCH RFC] solos-pci: Fix BUG() with shared skb
From: David Miller @ 2013-09-04 18:30 UTC (permalink / raw)
To: dwmw2; +Cc: netdev, simon, linux-atm-general, nathan
In-Reply-To: <1378223125.4210.11.camel@i7.infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
Date: Tue, 03 Sep 2013 16:45:25 +0100
> Simon reported this BUG():
>
> kernel BUG at net/core/skbuff.c:1065!
> Call Trace:
> [<f9b7c12c>] ? pppoatm_send+0x3f/0x1a0 [pppoatm]
> [<f8751797>] psend+0xa9/0x14a [solos_pci]
> [<f9b7c248>] pppoatm_send+0x15b/0x1a0 [pppoatm]
> [<f8a2f77d>] ppp_push+0x76/0x533 [ppp_generic]
>
> (Rest of backtrace at http://s85.org/mn0aOxMN ― the skb appears to be
> IPv6, forwarded from another interface over PPPoATM.)
>
> I wasn't expecting to see shared skbs in the ATM driver's ->send()
> function. Is this the right fix?
skb_realloc_headroom() should do everything you need.
This is what ethernet drivers do to prepend custom headers
when skb_headroom() is not large enough.
For example, see drivers/net/ethernet/sun/niu.c:niu_start_xmit().
There, the driver is attempting to prepend a TX descriptor to the
SKB.
If the SKB is shared, skb_realloc_headroom() will do the clone
for you if necessary.
^ permalink raw reply
* [PATCH] icplus: Use netif_running to determine device state
From: Jon Mason @ 2013-09-04 18:26 UTC (permalink / raw)
To: netdev; +Cc: Francois Romieu, Sorbica Shieh
Remove the __LINK_STATE_START check to verify the device is running, in
favor of netif_running(). netif_running() performs the same check of
__LINK_STATE_START, so the code should behave the same.
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Cc: Francois Romieu <romieu@fr.zoreil.com>
Cc: Sorbica Shieh <sorbica@icplus.com.tw>
---
drivers/net/ethernet/icplus/ipg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/icplus/ipg.c b/drivers/net/ethernet/icplus/ipg.c
index 1fde90b..bdf5023 100644
--- a/drivers/net/ethernet/icplus/ipg.c
+++ b/drivers/net/ethernet/icplus/ipg.c
@@ -1004,7 +1004,7 @@ static struct net_device_stats *ipg_nic_get_stats(struct net_device *dev)
/* Check to see if the NIC has been initialized via nic_open,
* before trying to read statistic registers.
*/
- if (!test_bit(__LINK_STATE_START, &dev->state))
+ if (!netif_running(dev))
return &sp->stats;
sp->stats.rx_packets += ipg_r32(IPG_FRAMESRCVDOK);
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] net: fec: fix the error to get the previous BD entry
From: David Miller @ 2013-09-04 18:13 UTC (permalink / raw)
To: B38611; +Cc: b20596, netdev, bhutchings, stephen
In-Reply-To: <1378176078-10380-1-git-send-email-B38611@freescale.com>
From: Fugang Duan <B38611@freescale.com>
Date: Tue, 3 Sep 2013 10:41:18 +0800
> Bug: error to get the previous BD entry. When the current BD
> is the first BD, the previous BD entry must be the last BD,
> not "bdp - 1" in current logic.
...
> Reviewed-by: Li Frank <B20596@freescale.com>
> Signed-off-by: Fugang Duan <B38611@freescale.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ipv6: fix null pointer dereference in __ip6addrlbl_add
From: David Miller @ 2013-09-04 18:13 UTC (permalink / raw)
To: hannes; +Cc: michele, netdev, yoshfuji, sasha.levin
In-Reply-To: <20130903001331.GA8820@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Tue, 3 Sep 2013 02:13:31 +0200
> Hi!
>
> On Mon, Sep 02, 2013 at 10:31:28PM +0100, Michele Baldessari wrote:
>> with the latest linux master git tree from Linus
>> (248d296d6d9df384996c2ed95676b367d876d48c - 2 Sep) I can reproduceably oops
>> the kernel with the following commands:
>> ip addrlabel flush
>> ip addrlabel add prefix ::1/128 label 0
>> ip addrlabel add prefix ::/0 label 1
>
> Thanks for the report! This patch should fix this issue:
>
> [PATCH] ipv6: fix null pointer dereference in __ip6addrlbl_add
>
> Commit b67bfe0d42cac56c512dd5da4b1b347a23f4b70a ("hlist: drop
> the node parameter from iterators") changed the behavior of
> hlist_for_each_entry_safe to leave the p argument NULL.
>
> Fix this up by tracking the last argument.
>
> Reported-by: Michele Baldessari <michele@acksyn.org>
> Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
> Cc: Sasha Levin <sasha.levin@oracle.com>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Applied.
^ permalink raw reply
* Re: [PATCH] sh_eth: NAPI requires netif_receive_skb()
From: David Miller @ 2013-09-04 18:12 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: netdev, nobuhiro.iwamatsu.yj, linux-sh
In-Reply-To: <201309030303.11381.sergei.shtylyov@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Tue, 3 Sep 2013 03:03:10 +0400
> Driver supporting NAPI should use NAPI-specific function for receiving packets,
> so netif_rx() should be changed to netif_receive_skb().
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Applied.
^ permalink raw reply
* Re: merge window warning
From: David Miller @ 2013-09-04 18:05 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, linux-wireless, netfilter-devel
In-Reply-To: <CAL3LdT5s=8E123aR8rwCZjjGUjv3jTzyJxX3fzu56kge6PHh2g@mail.gmail.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 4 Sep 2013 10:40:45 -0700
> Would Jesse's i40e series be acceptable if I push today, since 4
> versions have been sent previously for review? I ask, because I was
> in the process of submitting v5 and want to make sure it is ok before
> submitting.
It's a new driver, so it should be OK.
^ permalink raw reply
* Re: [-next] openvswitch BUILD_BUG_ON failed
From: Jesse Gross @ 2013-09-04 17:53 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: David Miller, Andy Zhou, dev@openvswitch.org, netdev,
Linux Kernel Mailing List, Linux-Next
In-Reply-To: <CAMuHMdVvB+GMwMrP2mieXbqAM7mn3nF_1ezbiYVBLKdsL5aCJg@mail.gmail.com>
On Tue, Sep 3, 2013 at 11:55 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Tue, Sep 3, 2013 at 11:44 PM, Jesse Gross <jesse@nicira.com> wrote:
>> On Sat, Aug 31, 2013 at 5:11 AM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>>> On Fri, Aug 30, 2013 at 3:11 AM, Jesse Gross <jesse@nicira.com> wrote:
>>>> On Thu, Aug 29, 2013 at 3:10 PM, David Miller <davem@davemloft.net> wrote:
>>>>> From: Jesse Gross <jesse@nicira.com>
>>>>> Date: Thu, 29 Aug 2013 14:42:22 -0700
>>>>>
>>>>>> On Thu, Aug 29, 2013 at 2:21 PM, Geert Uytterhoeven
>>>>>> <geert@linux-m68k.org> wrote:
>>>>>>> However, I have some doubts about other alignment "enforcements":
>>>>>>>
>>>>>>> "__aligned(__alignof__(long))" makes the whole struct aligned to the
>>>>>>> alignment rule for "long":
>>>>>>> 1. This is only 2 bytes on m68k, i.e. != sizeof(long).
>>>>>>> 2. This is 4 bytes on many 32-bit platforms, which may be less than the
>>>>>>> default alignment for "__be64" (cfr. some members of struct
>>>>>>> ovs_key_ipv4_tunnel), so this may make those 64-bit members unaligned.
>>>>>>
>>>>>> Do any of those 32-bit architectures actually care about alignment of
>>>>>> 64 bit values? On 32-bit x86, a long is 32 bits but the alignment
>>>>>> requirement of __be64 is also 32 bit.
>>>>>
>>>>> All except x86-32 do, it is in fact the odd man out with respect to this
>>>>> issue.
>>>>
>>>> Thanks, good to know.
>>>>
>>>> Andy, do you want to modify your patch to just drop the alignment
>>>> specification as Geert suggested (but definitely keep the new build
>>>> assert that you added)? It's probably better to just send the patch to
>>>> netdev (against net-next) as well since you'll likely get better
>>>> comments there and we can fix this faster if you cut out the
>>>> middleman.
>>>
>>> Why do you want to keep the build asserts?
>>> Is this in-memory structure also transfered as-is over the network?
>>> If yes, you definitely want the padding.
>>
>> Well they caught this bug and really don't cost anything.
>>
>>> Nevertheless, as the struct contains u32 and even __be64 members, the
>>> size of the struct will always be a multiple of the alignment unit for
>>> 64-bit quantities (and thus also for long), as per the C standard.
>>> Hence the check
>>>
>>> BUILD_BUG_ON(sizeof(struct sw_flow_key) % __alignof__(long));
>>>
>>> will only catch bad compiler bugs or people adding __packed to the struct.
>>
>> It's possible that we might want to pack the structure in the future.
>> More generally though, the contents of the struct is really
>> independent of the alignment requirements here because we're accessing
>> it as an array of bytes in long-sized chunks so implicitly depending
>> on the size of the members is not that great.
>
> So you're accessing it as an array of bytes in long-sized chunks.
> What are you doing with this accessed data?
> Transfering over the network?
> Storing on disk?
> Then it must be portable across machines and architectures, right?
It's just an in-memory hash table lookup. No one else ever sees it.
^ permalink raw reply
* Re: linux-next: Tree for Sep 4 (netfilter: xt_TPROXY)
From: Randy Dunlap @ 2013-09-04 17:46 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, netfilter-devel, netdev@vger.kernel.org
In-Reply-To: <20130904181300.06fbf0698863cfaacf9fad9a@canb.auug.org.au>
On 09/04/13 01:13, Stephen Rothwell wrote:
> Hi all,
>
> Please do not add any code for v3.13 to your linux-next included branches
> until after v3.12-rc1 is released.
>
> Changes since 20130902:
>
on x86_64:
when CONFIG_IPV6=m
and CONFIG_NETFILTER_XT_TARGET_TPROXY=y:
net/built-in.o: In function `tproxy_tg6_v1':
xt_TPROXY.c:(.text+0x5dc05): undefined reference to `udp6_lib_lookup'
xt_TPROXY.c:(.text+0x5e32f): undefined reference to `udp6_lib_lookup'
xt_TPROXY.c:(.text+0x5e432): undefined reference to `udp6_lib_lookup'
net/built-in.o: In function `tproxy_tg_init':
xt_TPROXY.c:(.init.text+0x1540): undefined reference to `nf_defrag_ipv6_enable'
--
~Randy
^ permalink raw reply
* Re: merge window warning
From: Jeff Kirsher @ 2013-09-04 17:40 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless, netfilter-devel
In-Reply-To: <20130904.131001.1189384206727310769.davem@davemloft.net>
Would Jesse's i40e series be acceptable if I push today, since 4
versions have been sent previously for review? I ask, because I was
in the process of submitting v5 and want to make sure it is ok before
submitting.
On Wed, Sep 4, 2013 at 10:10 AM, David Miller <davem@davemloft.net> wrote:
>
> The merge window is now open.
>
> This means if a feature patch isn't in patchwork already, and
> completely ready to apply, you should not submit it at this time.
>
> I will just automatically reject any inappropriate patches sent from
> now until the net-next tree opens again after the merge window closes,
> in order to assist with my ability to process the current backlog
> efficiently.
>
> Thanks.
>
> --
> 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
--
Cheers,
Jeff
^ permalink raw reply
* Re: [PATCH 5/7] ixgbe: use pcie_capability_read_word() to simplify code
From: Keller, Jacob E @ 2013-09-04 17:24 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Yijing Wang, Benjamin Herrenschmidt, Gavin Shan,
James E.J. Bottomley, David S. Miller,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
Hanjun Guo, e1000-devel@lists.sourceforge.net,
netdev@vger.kernel.org, Kirsher, Jeffrey T
In-Reply-To: <20130904162022.GE24733@google.com>
On Wed, 2013-09-04 at 10:20 -0600, Bjorn Helgaas wrote:
> [+cc Jacob, Jeff]
>
> On Tue, Sep 03, 2013 at 03:35:13PM +0800, Yijing Wang wrote:
> > use pcie_capability_read_word() to simplify code.
> >
> > Signed-off-by: Yijing Wang <wangyijing@huawei.com>
> > Cc: e1000-devel@lists.sourceforge.net
> > Cc: netdev@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > ---
> > drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 6 ++----
> > 1 files changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> > index bad8f14..bfa0b06 100644
> > --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> > +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> > @@ -152,7 +152,6 @@ MODULE_VERSION(DRV_VERSION);
> > static int ixgbe_read_pci_cfg_word_parent(struct ixgbe_adapter *adapter,
> > u32 reg, u16 *value)
> > {
> > - int pos = 0;
> > struct pci_dev *parent_dev;
> > struct pci_bus *parent_bus;
> >
> > @@ -164,11 +163,10 @@ static int ixgbe_read_pci_cfg_word_parent(struct ixgbe_adapter *adapter,
> > if (!parent_dev)
> > return -1;
> >
> > - pos = pci_find_capability(parent_dev, PCI_CAP_ID_EXP);
> > - if (!pos)
> > + if (!pci_is_pcie(parent_dev))
> > return -1;
> >
> > - pci_read_config_word(parent_dev, pos + reg, value);
> > + pcie_capability_read_word(parent_dev, reg, value);
> > return 0;
> > }
> >
>
> Here's the caller of ixgbe_read_pci_cfg_word_parent():
>
> /* Get the negotiated link width and speed from PCI config space of the
> * parent, as this device is behind a switch
> */
> err = ixgbe_read_pci_cfg_word_parent(adapter, 18, &link_status);
>
> This should be using PCI_EXP_LNKSTA instead of "18".
Absolutely.. Not sure why I didn't do this originally.....
>
> But it would be even better if we could drop ixgbe_get_parent_bus_info()
> completely. It seems redundant after merging Jacob's new
> pcie_get_minimum_link() stuff [1].
I don't know if we can fully drop it. We need this in order to read the
parent device on some quad port Ethernet adapters which have an internal
PCIe switch to link two parts together. There are a few places we read
the parent cfg word. At least one for sure.. but maybe others.. Can't
recall. The parent bus info is still used to print out the slot width
and speed. I don't know if it would be better to just print the response
from get_minimum_link or still print the actual slot.
>
> ixgbe_disable_pcie_master() looks like it should be using
> pcie_capability_read_word() with PCI_EXP_DEVSTA instead of using
> IXGBE_PCI_DEVICE_STATUS. If fact, it looks like it could use the
> new pci_wait_for_pending_transaction() interface [2].
>
I can look at doing this. I know it was done this way for historic
reasons, (and likely for code share with non Linux drivers.. but that's
not really an excuse)
> It looks like all the #defines in the "PCI Bus Info" block
> (IXGBE_PCI_DEVICE_STATUS, IXGBE_PCI_DEVICE_STATUS_TRANSACTION_PENDING,
> IXGBE_PCI_LINK_STATUS, etc.) [3] are really for PCIe-generic things. If
> so, the IXGBE-specific ones should be dropped in favor of the generic
> ones.
Agreed.
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH] net: sctp: Fix data chunk fragmentation for MTU values which are not multiple of 4
From: David Miller @ 2013-09-04 17:20 UTC (permalink / raw)
To: alexander.sverdlin
Cc: linux-sctp, vyasevich, matija.glavinic-pecotic.ext, netdev
In-Reply-To: <52249981.8040006@nsn.com>
From: Alexander Sverdlin <alexander.sverdlin@nsn.com>
Date: Mon, 02 Sep 2013 15:58:25 +0200
> From: Alexander Sverdlin <alexander.sverdlin@nsn.com>
>
> net: sctp: Fix data chunk fragmentation for MTU values which are not multiple of 4
>
> Initially the problem was observed with ipsec, but later it became clear that
> SCTP data chunk fragmentation algorithm has problems with MTU values which are
> not multiple of 4. Test program was used which just transmits 2000 bytes long
> packets to other host. tcpdump was used to observe re-fragmentation in IP layer
> after SCTP already fragmented data chunks.
...
> Here problem in data portion limit calculation leads to re-fragmentation in IP,
> which is sub-optimal. The problem is max_data initial value, which doesn't take
> into account the fact, that data chunk must be padded to 4-bytes boundary.
> It's enough to correct max_data, because all later adjustments are correctly
> aligned to 4-bytes boundary.
>
> After the fix is applied, everything is fragmented correctly for uneven MTUs:
...
> The bug was there for years already, but
> - is a performance issue, the packets are still transmitted
> - doesn't show up with default MTU 1500, but possibly with ipsec (MTU 1438)
>
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nsn.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/2] drivers:net: delete premature free_irq
From: David Miller @ 2013-09-04 17:18 UTC (permalink / raw)
To: Julia.Lawall
Cc: mcuos.com, kernel-janitors, linux-arm-kernel, netdev,
linux-kernel
In-Reply-To: <1378115661-5371-3-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
Date: Mon, 2 Sep 2013 11:54:21 +0200
> From: Julia Lawall <Julia.Lawall@lip6.fr>
>
> Free_irq is not needed if there has been no request_irq. Free_irq is
> removed from both the probe and remove functions. The correct request_irq
> and free_irq are found in the open and close functions.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
...
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net] bnx2x: bail out if unable to acquire stats_sema
From: Neal Cardwell @ 2013-09-04 17:17 UTC (permalink / raw)
To: Dmitry Kravkov
Cc: Michal Schmidt, davem@davemloft.net, netdev@vger.kernel.org,
Ariel Elior, Eilon Greenstein
In-Reply-To: <504C9EFCA2D0054393414C9CB605C37F20D8F504@SJEXCHMB06.corp.ad.broadcom.com>
On Tue, Sep 3, 2013 at 11:51 AM, Dmitry Kravkov <dmitry@broadcom.com> wrote:
>> -----Original Message-----
>> From: Michal Schmidt [mailto:mschmidt@redhat.com]
>> Sent: Tuesday, September 03, 2013 6:46 PM
>> To: davem@davemloft.net
>> Cc: netdev@vger.kernel.org; Dmitry Kravkov; Ariel Elior; Eilon Greenstein
>> Subject: [PATCH net] bnx2x: bail out if unable to acquire stats_sema
>>
>> If we fail to acquire stats_sema in the specified time limit, the chip is
>> probably dead. It probably does not matter whether we try to continue or
>> not, but certainly we should not up() the semaphore afterwards.
>>
>> Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
>> ---
>> drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c | 24
>> +++++++++++++++++------
It seems like this patch has the downside that if the down_timeout()
fails, then bnx2x_stats_handle() ends up updating the stats state
machine's state without really executing the real body of the
action().
In fact it seems like there is a more general pre-existing problem of
this flavor with the bnx2x stats state machine: the
bnx2x_stats_handle() function updates the state machine
bp->stats_state while holding the spin lock, but does not execute the
action() while holding any sort of synchronization, so AFAICT there is
nothing to guarantee that the state machine actions happen in the
order the state machine wants them to happen. For example, if stats
events fire such that we want to execute actions that disable and then
enable stats, we could instead end up executing the actions in the
order that would attempt to enable and then disable them, if we get
unlucky with respect to when interrupts fire, etc.
It seems to me that instead of having all of the callees of
bnx2x_stats_handle() try to down/up the semaphore, instead
bnx2x_stats_handle() should try to down the stats_sema at the top, and
then if successful, it should change the bp->stats_state, call the
action, and up the stats_sema. Would that work?
neal
^ permalink raw reply
* Re: [Patch net-next v2] net: sync some IP headers with glibc
From: David Miller @ 2013-09-04 17:13 UTC (permalink / raw)
To: amwang; +Cc: netdev, tmb, libc-alpha, yoshfuji, carlos
In-Reply-To: <1376558891-26221-1-git-send-email-amwang@redhat.com>
From: Cong Wang <amwang@redhat.com>
Date: Thu, 15 Aug 2013 17:28:10 +0800
> Solution:
> =========
>
> - Synchronize linux's `include/uapi/linux/in6.h'
> with glibc's `inet/netinet/in.h'.
> - Synchronize glibc's `inet/netinet/in.h with linux's
> `include/uapi/linux/in6.h'.
> - Allow including the headers in either other.
> - First header included defines the structures and macros.
Applied, thanks for being so patient. I want to spend the past few
weeks making sure this is the right way to handle all of this and
now I am confident that it is.
Thanks!
^ permalink raw reply
* merge window warning
From: David Miller @ 2013-09-04 17:10 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA
The merge window is now open.
This means if a feature patch isn't in patchwork already, and
completely ready to apply, you should not submit it at this time.
I will just automatically reject any inappropriate patches sent from
now until the net-next tree opens again after the merge window closes,
in order to assist with my ability to process the current backlog
efficiently.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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