* [net-next 0/4 v2][pull request] Intel Wired LAN Driver Updates
From: Jeff Kirsher @ 2012-09-20 10:07 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo, sassmann
This series contains updates to igb and ixgbevf.
v2: updated patch description in 04 patch (ixgbevf: scheduling while
atomic in reset hw path)
The following are changes since commit aee77e4accbeb2c86b1d294cd84fec4a12dde3bd:
r8169: use unlimited DMA burst for TX
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
Akeem G. Abodunrin (1):
igb: Support to enable EEE on all eee_supported devices
Alexander Duyck (2):
igb: Remove artificial restriction on RQDPC stat reading
ixgbevf: Add support for VF API negotiation
John Fastabend (1):
ixgbevf: scheduling while atomic in reset hw path
drivers/net/ethernet/intel/igb/e1000_82575.c | 17 +++++++---
drivers/net/ethernet/intel/igb/e1000_defines.h | 3 +-
drivers/net/ethernet/intel/igb/e1000_regs.h | 1 +
drivers/net/ethernet/intel/igb/igb_main.c | 8 +++--
drivers/net/ethernet/intel/ixgbevf/defines.h | 1 +
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 23 +++++++++++++
drivers/net/ethernet/intel/ixgbevf/mbx.h | 21 ++++++++++--
drivers/net/ethernet/intel/ixgbevf/vf.c | 39 ++++++++++++++++++++++-
drivers/net/ethernet/intel/ixgbevf/vf.h | 3 ++
9 files changed, 105 insertions(+), 11 deletions(-)
--
1.7.11.4
^ permalink raw reply
* Re: [PATCH v2] USB: remove dbg() usage in USB networking drivers
From: Joe Perches @ 2012-09-20 10:07 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: netdev, linux-usb, linux-kernel
In-Reply-To: <20120919194614.GA17585@kroah.com>
On Wed, 2012-09-19 at 20:46 +0100, Greg Kroah-Hartman wrote:
> The dbg() USB macro is so old, it predates me. The USB networking drivers are
> the last hold-out using this macro, and we want to get rid of it, so replace
> the usage of it with the proper netdev_dbg() or dev_dbg() (depending on the
> context) calls.
OK, one more bit of trivia
> diff --git a/drivers/net/usb/net1080.c b/drivers/net/usb/net1080.c
[]
> @@ -422,8 +419,9 @@ static int net1080_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
> if (!(skb->len & 0x01)) {
> #ifdef DEBUG
> struct net_device *net = dev->net;
> - dbg("rx framesize %d range %d..%d mtu %d", skb->len,
> - net->hard_header_len, dev->hard_mtu, net->mtu);
> + netdev_dbg(dev->net, "rx framesize %d range %d..%d mtu %d\n",
> + skb->len, net->hard_header_len, dev->hard_mtu,
> + net->mtu);
> #endif
maybe
netdev_dbg(net, ...
or remove the odd #ifdef DEBUG surround used to guard
the otherwise unused net variable and use:
netdev_dbg(dev->net, "rx framesize %d range %d..%d mtu %d\n",
skb->len, dev->net->hard_header_len, dev->hard_mtu,
dev->net->mtu);
^ permalink raw reply
* Re: [PATCH] tcp: restore rcv_wscale in a repair mode (v2)
From: Pavel Emelyanov @ 2012-09-20 9:31 UTC (permalink / raw)
To: David S. Miller
Cc: Andrew Vagin, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy
In-Reply-To: <1348083600-3881500-1-git-send-email-avagin@openvz.org>
On 09/19/2012 11:40 PM, Andrew Vagin wrote:
> rcv_wscale is a symetric parameter with snd_wscale.
>
> Both this parameters are set on a connection handshake.
>
> Without this value a remote window size can not be interpreted correctly,
> because a value from a packet should be shifted on rcv_wscale.
>
> And one more thing is that wscale_ok should be set too.
>
> This patch doesn't break a backward compatibility.
> If someone uses it in a old scheme, a rcv window
> will be restored with the same bug (rcv_wscale = 0).
>
> v2: Save backward compatibility on big-endian system. Before
> the first two bytes were snd_wscale and the second two bytes were
> rcv_wscale. Now snd_wscale is opt_val & 0xFFFF and rcv_wscale >> 16.
> This approach is independent on byte ordering.
>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
> Cc: James Morris <jmorris@namei.org>
> Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
> Cc: Patrick McHardy <kaber@trash.net>
> CC: Pavel Emelyanov <xemul@parallels.com>
> Signed-off-by: Andrew Vagin <avagin@openvz.org>
Acked-by: Pavel Emelyanov <xemul@parallels.com>
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (net-next tree related)
From: Mika Westerberg @ 2012-09-20 9:10 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: David Miller, netdev, linux-next, linux-kernel
In-Reply-To: <20120920173622.2aa7209cd241a3945f4384d4@canb.auug.org.au>
On Thu, Sep 20, 2012 at 05:36:22PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the final tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> drivers/net/ethernet/i825xx/znet.c: In function 'hardware_init':
> drivers/net/ethernet/i825xx/znet.c:868:2: error: implicit declaration of function 'isa_virt_to_bus' [-Werror=implicit-function-declaration]
>
> Caused by commit 1d3ff76759b7 ("i825xx: znet: fix compiler warnings when
> building a 64-bit kernel"). Is there some Kconfig dependency missing (CONFIG_ISA)?
If we make it dependent on CONFIG_ISA then the driver cannot be built with
64-bit kernel. Then again is there someone running 64-bit kernel on Zenith
Z-note notebook? From the pictures it looks like very ancient "laptop".
An alternative is to make it depend on X86 like this:
diff --git a/drivers/net/ethernet/i825xx/Kconfig b/drivers/net/ethernet/i825xx/Kconfig
index fed5080..959faf7 100644
--- a/drivers/net/ethernet/i825xx/Kconfig
+++ b/drivers/net/ethernet/i825xx/Kconfig
@@ -150,7 +150,7 @@ config SUN3_82586
config ZNET
tristate "Zenith Z-Note support (EXPERIMENTAL)"
- depends on EXPERIMENTAL && ISA_DMA_API
+ depends on EXPERIMENTAL && ISA_DMA_API && X86
---help---
The Zenith Z-Note notebook computer has a built-in network
(Ethernet) card, and this is the Linux driver for it. Note that the
^ permalink raw reply related
* Re: Regarding ethernet directory between IP and SoC chip vendor.
From: Jeff Kirsher @ 2012-09-20 8:35 UTC (permalink / raw)
To: byungho an
Cc: netdev, davem, peppe.cavallaro, deepak.silki, francesco.virlinzi,
eilong, alexander.h.duyck, bhutchings, linville, wey-ty.w.guy,
coelho, e.wahlig, aditya.ps, ihlee215
In-Reply-To: <CAG4h5ywgCS0n8t70uUNmSOVhKBPkOLeVLaO+D4tYfUT2qN7qTg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1456 bytes --]
On Wed, 2012-09-19 at 21:39 +0900, byungho an wrote:
> Hi all,
>
> I have one suggestion for ethernet dir.
> Currently It is well-defined and good for management.
>
> But if IP vendor is different from SoC vender, It is a bit confusing
> to guess dir name.
> For example, stmmac is using Synopsys dwmac.
> In this case, if another SoC vendors try to use Synopsys IP, they
> sould make their own dir under the their name? Even the IP is same...
>
> If there is common dir of IP vendor, It would be more clear.
> If that, other SoC vendors that try to use the IP can make their own
> directory and drivers intuitionally.
>
> What do you think about it?
> I want to exchange opinion and find a resonable and rational way.
>
> Thank you.
> Andy
A lot of thought went into how to organize all the Ethernet drivers, and
after much discussion, it seemed best to organize the drivers by the
manufacturer rather than by who was supporting/writing the driver. The
reason being is that the manufacturer of the silicon was not going to
change as frequently as the driver supporters. We did not want to have
to change the location of a driver every time a company was bought.
I personally am open to suggestions on improving the directory structure
so if have an idea on how to improve the directory structure please
provide a patch. Keep in mind, that drivers can not keep moving because
some company bought another company.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 0/3] usbnet: support runtime PM triggered by link change
From: Bjørn Mork @ 2012-09-20 8:30 UTC (permalink / raw)
To: Ming Lei
Cc: Oliver Neukum, David S. Miller, Greg Kroah-Hartman, Fink Dmitry,
Rafael Wysocki, Alan Stern, netdev, linux-usb
In-Reply-To: <CACVXFVONb+pKkydhp3iesLt0tKvc+56uv6sd5S0UwUnGZiowYA@mail.gmail.com>
Ming Lei <ming.lei@canonical.com> writes:
> On Mon, Sep 17, 2012 at 4:04 PM, Oliver Neukum <oneukum@suse.de> wrote:
>
>> 1) Does it actually save power? You are constantly waking up a CPU.
>
> Of course, it does. I don't know it will save how much power just on
> usbnet device, but it may save power from usb hub and usb host
> controller in the bus at least.
>
> Anyway we don't need to waste power if the link of usbnet is down.
>
> It just wake up CPU one time each 3sec. In modern linux distribution,
> the CPU will be wakup tens times per second, so it shouldn't be a
> big problem.
I do not buy that constantly polling a device necessarily saves any
power compared to keeping the USB link to the device alive. You need to
measure the savings if you want us to believe that.
You are not only waking the host CPU. You are also waking the device
CPU.
Any usbnet device will consist of more than one building block, having
at least a network block, a USB block and a CPU. For all you know, the
device CPU might be in deep sleep until it has to service either the
network or USB block, and those might also be sleeping until they see an
interrupt. Constantly polling the device to receive network link status
might use considerably more power than keeping the USB link up waiting
for a link notification.
If you were to implement this feature anyway, then I would prefer a
userspace based approach instead. I see no reason to keep the timer in
the kernel. You could decide to suspend whenever the netdev is down,
and only poll the link when userspace tries to bring up the netdev.
That would let a userspace daemon implement the same feature by trying
to bring up the netdev every 3 seconds (or whatever frequency the user
selected). And it would allow me to avoid the polling until I know I
have plugged in a cable.
>> From that perspective it is possible that leaving on the ethernet is actually
>> better in terms of power. Only measurements can answer that question.
>
> You know it is a bit difficult to test power save for this situation. And
> most of runtime PM patches didn't provide power save data. In fact,
> I'd like to do it, but I have not some equipment to measure it, :-(.
We don't know, you don't know. But you claim that your change saves
power, so please provide some documentation showing that it does.
>> 2) Do we have many devices that would be serviced with this approach?
>
> At least I found asix can be serviced by this approach. Considered asix
> is quite popular, it is worthy of the effort. Also the below devices can be
> serviced by the patch in theory:
>
> dm9601.c / mcs7830.c / sierra_net.c
The sierra_net.c driver is only used for wireless devices AFAIK. I
really don't see the use case for network link based resume of that.
There is no cable to plug. Userspace will have to initiate a
connection.
And the DirectIP device I've got (MC7710) supports remote wakeup. I
assume that will be the case for all such devices, given that this is
mostly a firmware feature. So the correct fix for sierra_net.c is to add
support for remote wakeup. Then you will be able to suspend the device
regardless of whether the link is up or down, without the constant
polling.
Bjørn
^ permalink raw reply
* [PATCH v2] ucc_geth: Reduce IRQ off in xmit path
From: Joakim Tjernlund @ 2012-09-20 8:17 UTC (permalink / raw)
To: netdev, Francois Romieu; +Cc: Joakim Tjernlund
In-Reply-To: <20120919223416.GA16087@electric-eye.fr.zoreil.com>
Currently ucc_geth_start_xmit wraps IRQ off for the
whole body just to be safe.
Reduce the IRQ off period to a minimum.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
v2: Move assignment of ugeth->tx_skbuff[txQ][ugeth->skb_curtx[txQ]]
inside IRQ off section to prevent racing against
ucc_geth_tx(). Spotted by Francois Romieu <romieu@fr.zoreil.com>
drivers/net/ethernet/freescale/ucc_geth.c | 11 +++++------
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c
index 9ac14f8..0100bca 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -3181,21 +3181,20 @@ static int ucc_geth_start_xmit(struct sk_buff *skb, struct net_device *dev)
ugeth_vdbg("%s: IN", __func__);
- spin_lock_irqsave(&ugeth->lock, flags);
-
dev->stats.tx_bytes += skb->len;
/* Start from the next BD that should be filled */
bd = ugeth->txBd[txQ];
bd_status = in_be32((u32 __iomem *)bd);
- /* Save the skb pointer so we can free it later */
- ugeth->tx_skbuff[txQ][ugeth->skb_curtx[txQ]] = skb;
/* Update the current skb pointer (wrapping if this was the last) */
ugeth->skb_curtx[txQ] =
(ugeth->skb_curtx[txQ] +
1) & TX_RING_MOD_MASK(ugeth->ug_info->bdRingLenTx[txQ]);
+ spin_lock_irqsave(&ugeth->lock, flags);
+ /* Save the skb pointer so we can free it later */
+ ugeth->tx_skbuff[txQ][ugeth->skb_curtx[txQ]] = skb;
/* set up the buffer descriptor */
out_be32(&((struct qe_bd __iomem *)bd)->buf,
dma_map_single(ugeth->dev, skb->data,
@@ -3207,6 +3206,8 @@ static int ucc_geth_start_xmit(struct sk_buff *skb, struct net_device *dev)
/* set bd status and length */
out_be32((u32 __iomem *)bd, bd_status);
+ spin_unlock_irqrestore(&ugeth->lock, flags);
+
/* Move to next BD in the ring */
if (!(bd_status & T_W))
@@ -3238,8 +3239,6 @@ static int ucc_geth_start_xmit(struct sk_buff *skb, struct net_device *dev)
uccf = ugeth->uccf;
out_be16(uccf->p_utodr, UCC_FAST_TOD);
#endif
- spin_unlock_irqrestore(&ugeth->lock, flags);
-
return NETDEV_TX_OK;
}
--
1.7.8.6
^ permalink raw reply related
* Re: [PATCH 1/5] ucc_geth: Reduce IRQ off in xmit path
From: Joakim Tjernlund @ 2012-09-20 8:06 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
In-Reply-To: <20120919223416.GA16087@electric-eye.fr.zoreil.com>
Francois Romieu <romieu@fr.zoreil.com> wrote on 2012/09/20 00:34:16:
>
> Joakim Tjernlund <Joakim.Tjernlund@transmode.se> :
> > Currently ucc_geth_start_xmit wraps IRQ off for the
> > whole body just to be safe.
> > Reduce the IRQ off period to a minimum.
>
> It opens a window in ucc_geth_start_xmit where the skb slot in
> ugeth->tx_skbuff[txQ] is set and T_RA has not been written into
> the descriptor status. Consider a racing poll : the !skb test in
> ucc_geth_tx may not work as expected.
Right, good catch!
Surprisingly the driver never showed any malfunction even though I hit
it pretty hard.
I will send a V2 of this patch where I move the assignment inside the IRQ
off part:
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -3200,8 +3200,6 @@ static int ucc_geth_start_xmit(struct sk_buff *skb, struct net_device *dev)
/* Start from the next BD that should be filled */
bd = ugeth->txBd[txQ];
bd_status = in_be32((u32 __iomem *)bd);
- /* Save the skb pointer so we can free it later */
- ugeth->tx_skbuff[txQ][ugeth->skb_curtx[txQ]] = skb;
/* Update the current skb pointer (wrapping if this was the last) */
ugeth->skb_curtx[txQ] =
@@ -3209,6 +3207,8 @@ static int ucc_geth_start_xmit(struct sk_buff *skb, struct net_device *dev)
1) & TX_RING_MOD_MASK(ugeth->ug_info->bdRingLenTx[txQ]);
spin_lock_irqsave(&ugeth->lock, flags);
+ /* Save the skb pointer so we can free it later */
+ ugeth->tx_skbuff[txQ][ugeth->skb_curtx[txQ]] = skb;
/* set up the buffer descriptor */
out_be32(&((struct qe_bd __iomem *)bd)->buf,
dma_map_single(ugeth->dev, skb->data,
Jocke
^ permalink raw reply
* Re: [PATCH net-next 01/11] pps/ptp: Allow PHC devices to adjust PPS events for known delay
From: Rodolfo Giometti @ 2012-09-20 7:29 UTC (permalink / raw)
To: Ben Hutchings
Cc: David Miller, netdev, linux-net-drivers, Richard Cochran,
Andrew Jackson
In-Reply-To: <1348082024.2636.16.camel@bwh-desktop.uk.solarflarecom.com>
On Wed, Sep 19, 2012 at 08:13:44PM +0100, Ben Hutchings wrote:
> Initial version by Stuart Hodgson <smhodgson@solarflare.com>
>
> Some PHC device drivers may deliver PPS events with a significant
> and variable delay, but still be able to measure precisely what
> that delay is.
>
> Add a pps_sub_ts() function for subtracting a delay from the
> timestamp(s) in a PPS event, and a PTP event type (PTP_CLOCK_PPSUSR)
> for which the caller provides a complete PPS event.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Acked-by: Rodolfo Giometti <giometti@enneenne.com>
--
GNU/Linux Solutions e-mail: giometti@enneenne.com
Linux Device Driver giometti@linux.it
Embedded Systems phone: +39 349 2432127
UNIX programming skype: rodolfo.giometti
Freelance ICT Italia - Consulente ICT Italia - www.consulenti-ict.it
^ permalink raw reply
* Re: [PATCH] at91ether: return PTR_ERR if call to clk_get fails
From: Nicolas Ferre @ 2012-09-20 7:42 UTC (permalink / raw)
To: Devendra Naga, netdev, David Miller; +Cc: linux-arm-kernel
In-Reply-To: <1348124676-6627-1-git-send-email-devendra.aaru@gmail.com>
On 09/20/2012 09:04 AM, Devendra Naga :
> we are currently returning ENODEV, as the clk_get may give a exact
> error code in its returned pointer, assign it to the ret by using the
> PTR_ERR function, so that the subsequent goto label will jump to the
> error path and clean the driver and return the error correctly.
>
> Signed-off-by: Devendra Naga <devendra.aaru@gmail.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Thanks,
> ---
> drivers/net/ethernet/cadence/at91_ether.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/at91_ether.c b/drivers/net/ethernet/cadence/at91_ether.c
> index 7788419..4e980a7 100644
> --- a/drivers/net/ethernet/cadence/at91_ether.c
> +++ b/drivers/net/ethernet/cadence/at91_ether.c
> @@ -1086,7 +1086,7 @@ static int __init at91ether_probe(struct platform_device *pdev)
> /* Clock */
> lp->ether_clk = clk_get(&pdev->dev, "ether_clk");
> if (IS_ERR(lp->ether_clk)) {
> - res = -ENODEV;
> + res = PTR_ERR(lp->ether_clk);
> goto err_ioumap;
> }
> clk_enable(lp->ether_clk);
>
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH 2/4] ipv6: unify conntrack reassembly expire code with standard one
From: Cong Wang @ 2012-09-20 7:41 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: netdev, Netfilter Developers, Herbert Xu, Michal Kubeček,
David Miller, Hideaki YOSHIFUJI, Patrick McHardy,
Pablo Neira Ayuso
In-Reply-To: <Pine.LNX.4.64.1209191659150.12601@ask.diku.dk>
On Wed, 2012-09-19 at 17:12 +0200, Jesper Dangaard Brouer wrote:
> On Wed, 19 Sep 2012, Cong Wang wrote:
>
> [cut]
> > With this patch applied, I can see ICMP Time Exceeded sent
> > from the receiver when the sender sent out 3/4 fragmented
> > IPv6 UPD packet.
>
> Typo "UPD" -> "UDP"
>
> If people want to redo the IPv6 UDP fragment tests, they can use my scapy
> script, and comment out sending the last fragment:
> https://github.com/netoptimizer/network-testing/blob/master/scapy/ipv6_fragment01.py
>
> Another thing, could you please "mark"/put the version of the patch in the
> subject line, like:
>
> [PATCH V4 2/4] ipv6: ...
>
> This makes it easier, to follow on which version of the patch people are
> replying to.
>
> With git send-email I think you have to do:
>
> git send-email --subject-prefix="PATCH V4"
>
> And with stg (stacked git) I usually do:
>
> stg mail --version "V4" --to netdev ...
Thanks, Jesper!
Unfortunately, git-send-email on F16 doesn't have --subject-prefix
option (git-format-patch does), that is why I didn't add "V4" to every
patch. Perhaps I should use git-format-patch + git-send-email next time.
^ permalink raw reply
* Re: [PATCH 5/6] xfrm_user: ensure user supplied esn replay window is valid
From: Mathias Krause @ 2012-09-20 7:37 UTC (permalink / raw)
To: Steffen Klassert
Cc: Ben Hutchings, David S. Miller, netdev, linux-kernel,
Martin Willi
In-Reply-To: <20120920070508.GA4221@secunet.com>
On Thu, Sep 20, 2012 at 9:05 AM, Steffen Klassert
<steffen.klassert@secunet.com> wrote:
> On Thu, Sep 20, 2012 at 08:12:11AM +0200, Mathias Krause wrote:
>> On Thu, Sep 20, 2012 at 12:38 AM, Ben Hutchings
>> <bhutchings@solarflare.com> wrote:
>> > On Wed, 2012-09-19 at 23:33 +0200, Mathias Krause wrote:
>>
>> > I'm a little worried that the user-provided
>> > xfrm_replay_state_esn::bmp_len is not being directly validated anywhere.
>>
>> That's what my P.S. in the cover letter tried to hint at -- a missing
>> upper limit check. But as I wanted to avoid lengthy discussions about
>> the concrete value and the possible need for some sysctl knob to tune
>> this even further, I just left this as an exercise for someone else
>> who is more familiar with the code ;)
>>
>
> I think we should limit bmp_len to some sane value. RFC 4303 recommends
> an anti replay window size of 64 packets, so limiting bmp_len to cover
> 4096 packets should be more that enough. Also we can increase this value
> later without changing the user API if this is needed.
Okay. If no-one objects, I'll at add a upper limit check for 4096
packets to verify_replay().
>> [...]
>> I disagree. The value of nla_len() is ensured to be in the range of
>> [sizeof(*up), USHRT_MAX-NLA_HDRLEN], i.e. a positive 16 bit number,
>> when it passes nlmsg_parse() in xfrm_user_rcv_msg(). This in turn
>> allows us to assume the int value returned by nla_len() is actually
>> positive and the compiler can safely make it unsigned for the compare
>> -- no sign bit, no hassle.
>
> I think xfrm_replay_state_esn_len() should return the same type as
> nla_len(), no matter what we can assume from the current code base.
The type of the expression calculated in xfrm_replay_state_esn_len()
is size_t; the functions the value get passed onto (k*alloc, kmemdup,
memcpy, memcmp) expect a size_t argument; expressions where the value
is evaluated to calculate sizes (e.g. in xfrm_sa_len) operate on
size_t types. So size_t feels just natural.
> Also it should not return anything else than the other xfrm length
> calculation functions.
So the other functions should have a return type of size_t, too?
Anyway, such a cleanup should go into a separate patch as the other
functions are not vulnerable to an overflow like it could happen in
xfrm_replay_state_esn_len().
> Once we limited bmp_len, xfrm_replay_state_esn_len() should return
> always a positive value.
True. So int it'll be then again for xfrm_replay_state_esn_len() in v3
of the patch.
Thanks,
Mathias
^ permalink raw reply
* Re: [Patch net-next] l2tp: fix compile error when CONFIG_IPV6=m and CONFIG_L2TP=y
From: Cong Wang @ 2012-09-20 7:36 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20120919.164403.1265757047954729748.davem@davemloft.net>
On Wed, 2012-09-19 at 16:44 -0400, David Miller wrote:
> From: Cong Wang <amwang@redhat.com>
> Date: Tue, 18 Sep 2012 13:54:02 +0800
>
> > When CONFIG_IPV6=m and CONFIG_L2TP=y, I got the following compile error:
> ...
> > This is due to l2tp uses symbols from IPV6, so when l2tp is
> > builtin, IPV6 has to be builtin too.
> >
> > Cc: David Miller <davem@davemloft.net>
> > Signed-off-by: Cong Wang <amwang@redhat.com>
>
> The correct way to express this is:
>
> depends on (IPV6 || IPV6=n)
>
> Which results in the KCONFIG option only being offers in modes
> compatible with the dependency. Using a 'select' doesn't work
> properly in these kinds of cases.
>
> Anyways, grep for that string to see how it is used in other similar
> situations.
>
Thanks for the hints! I will update this patch.
^ permalink raw reply
* linux-next: build failure after merge of the final tree (net-next tree related)
From: Stephen Rothwell @ 2012-09-20 7:36 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Mika Westerberg
[-- Attachment #1: Type: text/plain, Size: 593 bytes --]
Hi all,
After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:
drivers/net/ethernet/i825xx/znet.c: In function 'hardware_init':
drivers/net/ethernet/i825xx/znet.c:868:2: error: implicit declaration of function 'isa_virt_to_bus' [-Werror=implicit-function-declaration]
Caused by commit 1d3ff76759b7 ("i825xx: znet: fix compiler warnings when
building a 64-bit kernel"). Is there some Kconfig dependency missing (CONFIG_ISA)?
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Oops with latest (netfilter) nf-next tree, when unloading iptable_nat
From: Patrick McHardy @ 2012-09-20 7:31 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Pablo Neira Ayuso, Florian Westphal, netfilter-devel, netdev,
yongjun_wei
In-Reply-To: <1348126142.2761.172.camel@localhost>
On Thu, 20 Sep 2012, Jesper Dangaard Brouer wrote:
> On Thu, 2012-09-20 at 08:57 +0200, Patrick McHardy wrote:
>> On Wed, 19 Sep 2012, Jesper Dangaard Brouer wrote:
>>
>>> On Fri, 2012-09-14 at 15:15 +0200, Patrick McHardy wrote:
>>>> On Fri, 14 Sep 2012, Pablo Neira Ayuso wrote:
>>>>
>>> [...cut...]
>>>>>> Patrick, any other idea?
>>>>>
>>> [...cut...]
> [... (hair)cut(?)...]
>
>>> No it does not work :-(
>>
>> Ok I think I understand the problem now, we're invoking the NAT cleanup
>> callback twice with clean->hash = true, once for each direction of the
>> conntrack.
>>
>> Does this patch fix the problem?
>
> Yes, it fixes the problem :-)
>
> Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
Great, thanks for testing.
^ permalink raw reply
* Re: [RFC net-next] netpoll: use static branch
From: Cong Wang @ 2012-09-20 7:30 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, Eric Dumazet, netdev
In-Reply-To: <20120919130059.7b7ebc83@s6510.linuxnetplumber.net>
On Wed, 2012-09-19 at 13:00 -0700, Stephen Hemminger wrote:
> On Wed, 19 Sep 2012 12:50:10 +0800
> Cong Wang <amwang@redhat.com> wrote:
>
> > On Tue, 2012-09-18 at 14:10 -0700, Stephen Hemminger wrote:
> > > This is an attempt to optimize netpoll when not used.
> > >
> > > Since distro's enable everything and netpoll is only occasionally
> > > used, improve performance by getting netpoll condition check
> > > out of the Rx fastpath.
> > >
> > > Compile tested only, I have no real use for netpoll.
> > >
> > > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> > >
> > >
> > > ---
> > > include/linux/netpoll.h | 28 ++++++++++++++++++++--------
> > > net/core/netpoll.c | 8 +++++++-
> > > 2 files changed, 27 insertions(+), 9 deletions(-)
> > >
> > > --- a/include/linux/netpoll.h 2012-09-18 13:25:15.575750004 -0700
> > > +++ b/include/linux/netpoll.h 2012-09-18 13:29:16.245323347 -0700
> > > @@ -66,10 +66,16 @@ static inline void netpoll_send_skb(stru
> > >
> > >
> > > #ifdef CONFIG_NETPOLL
> > > +extern struct static_key netpoll_needed;
> > > +
> > > static inline bool netpoll_rx_on(struct sk_buff *skb)
> > > {
> > > - struct netpoll_info *npinfo = rcu_dereference_bh(skb->dev->npinfo);
> > > + struct netpoll_info *npinfo;
> > > +
> > > + if (static_key_true(&netpoll_needed))
> > > + return false;
> > >
> >
> > I think we should use static_key_false() here, as netpoll is an
> > "unlikely" code path.
> >
> > Using static branch is a good idea though.
> >
> > Thanks.
>
> But static_key_true is just a wrapper around !static_key_false()
For !HAVE_JUMP_LABEL arch, the definition is below:
static __always_inline bool static_key_false(struct static_key *key)
{
if (unlikely(atomic_read(&key->enabled)) > 0)
return true;
return false;
}
static __always_inline bool static_key_true(struct static_key *key)
{
if (likely(atomic_read(&key->enabled)) > 0)
return true;
return false;
}
^ permalink raw reply
* Re: Oops with latest (netfilter) nf-next tree, when unloading iptable_nat
From: Jesper Dangaard Brouer @ 2012-09-20 7:29 UTC (permalink / raw)
To: Patrick McHardy
Cc: Pablo Neira Ayuso, Florian Westphal, netfilter-devel, netdev,
yongjun_wei
In-Reply-To: <Pine.GSO.4.63.1209200855500.8409@stinky-local.trash.net>
On Thu, 2012-09-20 at 08:57 +0200, Patrick McHardy wrote:
> On Wed, 19 Sep 2012, Jesper Dangaard Brouer wrote:
>
> > On Fri, 2012-09-14 at 15:15 +0200, Patrick McHardy wrote:
> >> On Fri, 14 Sep 2012, Pablo Neira Ayuso wrote:
> >>
> > [...cut...]
> >>>> Patrick, any other idea?
> >>>
> > [...cut...]
[... (hair)cut(?)...]
> > No it does not work :-(
>
> Ok I think I understand the problem now, we're invoking the NAT cleanup
> callback twice with clean->hash = true, once for each direction of the
> conntrack.
>
> Does this patch fix the problem?
Yes, it fixes the problem :-)
Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
^ permalink raw reply
* Re: [PATCH 6/6] xfrm_user: don't copy esn replay window twice for new states
From: Steffen Klassert @ 2012-09-20 7:27 UTC (permalink / raw)
To: Mathias Krause; +Cc: David S. Miller, netdev, linux-kernel
In-Reply-To: <1348090423-32665-7-git-send-email-minipli@googlemail.com>
On Wed, Sep 19, 2012 at 11:33:43PM +0200, Mathias Krause wrote:
> The ESN replay window was already fully initialized in
> xfrm_alloc_replay_state_esn(). No need to copy it again.
>
> Cc: Steffen Klassert <steffen.klassert@secunet.com>
> Signed-off-by: Mathias Krause <minipli@googlemail.com>
Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
^ permalink raw reply
* Re: [PATCH 4/6] xfrm_user: fix info leak in copy_to_user_tmpl()
From: Steffen Klassert @ 2012-09-20 7:26 UTC (permalink / raw)
To: Mathias Krause; +Cc: David S. Miller, netdev, linux-kernel, Brad Spengler
In-Reply-To: <1348090423-32665-5-git-send-email-minipli@googlemail.com>
On Wed, Sep 19, 2012 at 11:33:41PM +0200, Mathias Krause wrote:
> The memory used for the template copy is a local stack variable. As
> struct xfrm_user_tmpl contains multiple holes added by the compiler for
> alignment, not initializing the memory will lead to leaking stack bytes
> to userland. Add an explicit memset(0) to avoid the info leak.
>
> Initial version of the patch by Brad Spengler.
>
> Cc: Brad Spengler <spender@grsecurity.net>
> Signed-off-by: Mathias Krause <minipli@googlemail.com>
Patches 1-4:
Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
^ permalink raw reply
* [PATCH net-next] net: qmi_wwan: adding Huawei E367, ZTE MF683 and Pantech P4200
From: Bjørn Mork @ 2012-09-20 7:18 UTC (permalink / raw)
To: netdev
Cc: linux-usb, Bjørn Mork, Fangxiaozhi (Franko),
Thomas Schäfer, Dan Williams, Shawn J. Goff
In-Reply-To: <1348085016-30850-1-git-send-email-bjorn@mork.no>
One of the modes of Huawei E367 has this QMI/wwan interface:
I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=07 Driver=(none)
E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=2ms
E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
Huawei use subclass and protocol to identify vendor specific
functions, so adding a new vendor rule for this combination.
The Pantech devices UML290 (106c:3718) and P4200 (106c:3721) use
the same subclass to identify the QMI/wwan function. Replace the
existing device specific UML290 entries with generic vendor matching,
adding support for the Pantech P4200.
The ZTE MF683 has 6 vendor specific interfaces, all using
ff/ff/ff for cls/sub/prot. Adding a match on interface #5 which
is a QMI/wwan interface.
Cc: Fangxiaozhi (Franko) <fangxiaozhi@huawei.com>
Cc: Thomas Schäfer <tschaefer@t-online.de>
Cc: Dan Williams <dcbw@redhat.com>
Cc: Shawn J. Goff <shawn7400@gmail.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
Hello David,
This is the net-next version of the previously posted patch with the
same title. I totally forgot that I had messed with the .driver_info
fields, making it impossible to apply the same patch to both net and
net-next.
Sorry about that. Please apply this version to net-next. The other
one should still be applied to net (if still possible) and stable.
Thanks,
Bjørn
drivers/net/usb/qmi_wwan.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index e7b53f0..ca25320 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -353,16 +353,20 @@ static const struct usb_device_id products[] = {
},
/* 2. Combined interface devices matching on class+protocol */
+ { /* Huawei E367 and possibly others in "Windows mode" */
+ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, USB_CLASS_VENDOR_SPEC, 1, 7),
+ .driver_info = (unsigned long)&qmi_wwan_info,
+ },
{ /* Huawei E392, E398 and possibly others in "Windows mode" */
USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, USB_CLASS_VENDOR_SPEC, 1, 17),
.driver_info = (unsigned long)&qmi_wwan_info,
},
- { /* Pantech UML290 */
- USB_DEVICE_AND_INTERFACE_INFO(0x106c, 0x3718, USB_CLASS_VENDOR_SPEC, 0xf0, 0xff),
+ { /* Pantech UML290, P4200 and more */
+ USB_VENDOR_AND_INTERFACE_INFO(0x106c, USB_CLASS_VENDOR_SPEC, 0xf0, 0xff),
.driver_info = (unsigned long)&qmi_wwan_info,
},
{ /* Pantech UML290 - newer firmware */
- USB_DEVICE_AND_INTERFACE_INFO(0x106c, 0x3718, USB_CLASS_VENDOR_SPEC, 0xf1, 0xff),
+ USB_VENDOR_AND_INTERFACE_INFO(0x106c, USB_CLASS_VENDOR_SPEC, 0xf1, 0xff),
.driver_info = (unsigned long)&qmi_wwan_info,
},
@@ -370,6 +374,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x19d2, 0x0055, 1)}, /* ZTE (Vodafone) K3520-Z */
{QMI_FIXED_INTF(0x19d2, 0x0063, 4)}, /* ZTE (Vodafone) K3565-Z */
{QMI_FIXED_INTF(0x19d2, 0x0104, 4)}, /* ZTE (Vodafone) K4505-Z */
+ {QMI_FIXED_INTF(0x19d2, 0x0157, 5)}, /* ZTE MF683 */
{QMI_FIXED_INTF(0x19d2, 0x0167, 4)}, /* ZTE MF820D */
{QMI_FIXED_INTF(0x19d2, 0x0326, 4)}, /* ZTE MF821D */
{QMI_FIXED_INTF(0x19d2, 0x1008, 4)}, /* ZTE (Vodafone) K3570-Z */
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 5/6] xfrm_user: ensure user supplied esn replay window is valid
From: Mathias Krause @ 2012-09-20 7:13 UTC (permalink / raw)
To: Ben Hutchings
Cc: David S. Miller, Steffen Klassert, netdev, linux-kernel,
Martin Willi
In-Reply-To: <CA+rthh8Q464Jw5okH5aXds0QZztay9dpcyniahtWFxev8tpN9w@mail.gmail.com>
On Thu, Sep 20, 2012 at 8:12 AM, Mathias Krause <minipli@googlemail.com> wrote:
> What still might happen is the overflow in xfrm_replay_state_esn_len()
> resulting in a to small bitmap allocation for the requested replay
> size. But that gets catched in xfrm_init_replay(). Little late, but
> hey.
Sorry, I mixed that up. The replay_window check in xfrm_init_replay()
has only little to do with the bmp_len overflow. But changing the
return type of xfrm_replay_state_esn_len() to size_t and by doing so,
making the all the size compares operating on positive values, we'll
at least allocate enough memory to not run into memory corruptions.
Though, the replay window will be much smaller, than requested -- due
to the overflow. But userland should expect this. A check for some
upper limit in verify_replay() could catch this early.
Mathias
^ permalink raw reply
* [PATCH] rds: Error on offset mismatch if not loopback
From: John Jolly @ 2012-09-20 7:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Venkat Venkatsubra, netdev
Attempting an rds connection from the IP address of an IPoIB interface
to itself causes a kernel panic due to a BUG_ON() being triggered. Making
the test less strict allows rds-ping to work without crashing the machine.
A local unprivileged user could use this flaw to crash the sytem.
---
net/rds/ib_send.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/rds/ib_send.c b/net/rds/ib_send.c
index e590949..7920c85 100644
--- a/net/rds/ib_send.c
+++ b/net/rds/ib_send.c
@@ -544,7 +544,7 @@ int rds_ib_xmit(struct rds_connection *conn, struct rds_message *rm,
int flow_controlled = 0;
int nr_sig = 0;
- BUG_ON(off % RDS_FRAG_SIZE);
+ BUG_ON(!conn->c_loopback && off % RDS_FRAG_SIZE);
BUG_ON(hdr_off != 0 && hdr_off != sizeof(struct rds_header));
/* Do not send cong updates to IB loopback */
--
1.7.7
^ permalink raw reply related
* RE: [PATCH net-next] mlx4: use dev_kfree_skb() instead of dev_kfree_skb_any()
From: Yevgeny Petrilin @ 2012-09-20 7:03 UTC (permalink / raw)
To: Ying Cai, Eric Dumazet; +Cc: David Miller, netdev, Or Gerlitz
In-Reply-To: <CAL1qit_pkQ7YBzcAPMSWF4zeFS6yFj18P1yJMvj_Z-7SRMxeRg@mail.gmail.com>
Hi Ying,
> It seems all the TxQs are sharing the same interrupt for Tx
> completions. Will it be better to have separate interrupt per
> num_tx_rings_p_up (8) queues? E.g. for a 16 core system, with 16 * 8
> Tx queues, to have 16 interrupts for Tx completions of those 128 Tx
> queues?
Actually not all TxQs share same interrupt vector.
In commit 76532d0c we assigned an interrupt vector for each TX ring.
When the number of Queues is higher than number of interrupt vectors, there are queues that share interrupts
And actually reaching the assignment you specified.
>
> Also I'm looking at mlx4_en_select_queue(), it is using
> __skb_tx_hash(). Use something to achieve XPS may bring better
> performances.
>
We are considering this change.
^ permalink raw reply
* Re: [PATCH 5/6] xfrm_user: ensure user supplied esn replay window is valid
From: Steffen Klassert @ 2012-09-20 7:05 UTC (permalink / raw)
To: Mathias Krause
Cc: Ben Hutchings, David S. Miller, netdev, linux-kernel,
Martin Willi
In-Reply-To: <CA+rthh8Q464Jw5okH5aXds0QZztay9dpcyniahtWFxev8tpN9w@mail.gmail.com>
On Thu, Sep 20, 2012 at 08:12:11AM +0200, Mathias Krause wrote:
> On Thu, Sep 20, 2012 at 12:38 AM, Ben Hutchings
> <bhutchings@solarflare.com> wrote:
> > On Wed, 2012-09-19 at 23:33 +0200, Mathias Krause wrote:
>
> > I'm a little worried that the user-provided
> > xfrm_replay_state_esn::bmp_len is not being directly validated anywhere.
>
> That's what my P.S. in the cover letter tried to hint at -- a missing
> upper limit check. But as I wanted to avoid lengthy discussions about
> the concrete value and the possible need for some sysctl knob to tune
> this even further, I just left this as an exercise for someone else
> who is more familiar with the code ;)
>
I think we should limit bmp_len to some sane value. RFC 4303 recommends
an anti replay window size of 64 packets, so limiting bmp_len to cover
4096 packets should be more that enough. Also we can increase this value
later without changing the user API if this is needed.
> > Currently xfrm_replay_state_esn_len() may overflow, and as its return
> > type is int it may unexpectedly return a negative value.
>
> So xfrm_replay_state_esn_len() should return size_t instead as it's
> value should always be positive -- it represents a length. Negative
> lengths make no sense. It can overflow, still. But it cannot get
> negative, at least. Still, the upper limit check would be required to
> avoid other user induced nastiness.
>
> >
> > [...]
> >> --- a/net/xfrm/xfrm_user.c
> >> +++ b/net/xfrm/xfrm_user.c
> > [...]
> >> @@ -370,14 +378,15 @@ static inline int xfrm_replay_verify_len(struct xfrm_replay_state_esn *replay_es
> >> struct nlattr *rp)
> >> {
> >> struct xfrm_replay_state_esn *up;
> >> + size_t ulen;
> >
> > I would normally expect to see sizes declared as size_t but mixing
> > size_t and int in comparisons tends to result in bugs. So I think this
> > should to be int, matching the return types of nla_len() and
> > xfrm_replay_state_esn_len() (and apparently all lengths in netlink...)
>
> I disagree. The value of nla_len() is ensured to be in the range of
> [sizeof(*up), USHRT_MAX-NLA_HDRLEN], i.e. a positive 16 bit number,
> when it passes nlmsg_parse() in xfrm_user_rcv_msg(). This in turn
> allows us to assume the int value returned by nla_len() is actually
> positive and the compiler can safely make it unsigned for the compare
> -- no sign bit, no hassle.
I think xfrm_replay_state_esn_len() should return the same type as
nla_len(), no matter what we can assume from the current code base.
Also it should not return anything else than the other xfrm length
calculation functions.
Once we limited bmp_len, xfrm_replay_state_esn_len() should return
always a positive value.
^ permalink raw reply
* [PATCH] at91ether: return PTR_ERR if call to clk_get fails
From: Devendra Naga @ 2012-09-20 7:04 UTC (permalink / raw)
To: Nicolas Ferre, netdev; +Cc: Devendra Naga
we are currently returning ENODEV, as the clk_get may give a exact
error code in its returned pointer, assign it to the ret by using the
PTR_ERR function, so that the subsequent goto label will jump to the
error path and clean the driver and return the error correctly.
Signed-off-by: Devendra Naga <devendra.aaru@gmail.com>
---
drivers/net/ethernet/cadence/at91_ether.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/cadence/at91_ether.c b/drivers/net/ethernet/cadence/at91_ether.c
index 7788419..4e980a7 100644
--- a/drivers/net/ethernet/cadence/at91_ether.c
+++ b/drivers/net/ethernet/cadence/at91_ether.c
@@ -1086,7 +1086,7 @@ static int __init at91ether_probe(struct platform_device *pdev)
/* Clock */
lp->ether_clk = clk_get(&pdev->dev, "ether_clk");
if (IS_ERR(lp->ether_clk)) {
- res = -ENODEV;
+ res = PTR_ERR(lp->ether_clk);
goto err_ioumap;
}
clk_enable(lp->ether_clk);
--
1.7.1
^ 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