* Re: [net 0/3][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2013-03-27 18:10 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1364382333-14721-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 27 Mar 2013 04:05:30 -0700
> This series contains updates to e1000, ixgb and e1000e for Christoph.
>
> Christoph provides 3 patches to resolve missing dma_error_call's to
> provided Intel drivers which did not have this fix.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH] rtnetlink: fix error return code in rtnl_link_fill()
From: David Miller @ 2013-03-27 18:10 UTC (permalink / raw)
To: weiyj.lk; +Cc: john.r.fastabend, jiri, edumazet, vyasevic, yongjun_wei, netdev
In-Reply-To: <CAPgLHd8F8-uRfAi4R=xqHa76X8N9P+-UosF-6zC=OXStKbcP-A@mail.gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Wed, 27 Mar 2013 21:22:45 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Fix to return a negative error code from the error handling case
> instead of 0(possible overwrite to 0 by ops->fill_xstats call),
> as returned elsewhere in this function.
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Applied.
^ permalink raw reply
* Re: pull-request: can 2013-03-27
From: David Miller @ 2013-03-27 18:10 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can
In-Reply-To: <1364393128-19701-1-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Wed, 27 Mar 2013 15:05:26 +0100
> Hello David,
>
> here's a patch series for net for the v3.9 release cycle. Fengguang Wu found
> two problems with the sja1000 drivers:
>
> A macro in the SH architecture collides with one in the sja1000 driver. I
> created a minimal patch suited for stable, only changing this particular
> define. (Once net is merged back to net-next, I'll post a patch to uniformly
> use a SJA1000_ prefix for the sja100 private defines.) If you prefer, I can
> squash both patches together.
>
> Fengguang further noticed that the peak pcmcia driver will not compile on archs
> without ioport support. I created a patch to limit the driver to archs which
> select HAS_IOPORT in Kconfig.
Pulled, thanks Marc.
^ permalink raw reply
* Re: [net-next PATCH 0/2] network performance improvement patches for TI CPSW and Davinci EMAC drivers
From: David Miller @ 2013-03-27 18:10 UTC (permalink / raw)
To: mugunthanvnm; +Cc: netdev, linux-omap
In-Reply-To: <1364395320-14973-1-git-send-email-mugunthanvnm@ti.com>
From: Mugunthan V N <mugunthanvnm@ti.com>
Date: Wed, 27 Mar 2013 20:11:58 +0530
> This patch series improves network performance of TI CPSW and Davinci EMAC
> drivers during bulk transfer. During heavy Tx load CPDMA may run out of
> descriptors and tx queue is stopped. When it descriptors are available it
> is reported to the stack via netif_start_queue which doesn't schedule tx
> queue immediately, so there can be dead time during continuous transfer,
> this can be fixed by using netif_wake_queue api which will schedule tx queue
> immediately.
Both applied to 'net'.
^ permalink raw reply
* Re: [PATCH] sch: add missing u64 in psched_ratecfg_precompute()
From: David Miller @ 2013-03-27 18:11 UTC (permalink / raw)
To: popovich_sergei; +Cc: eric.dumazet, netdev
In-Reply-To: <10857839.dV42UeFzbk@tuxracer.localdomain>
From: Sergey Popovich <popovich_sergei@mail.ru>
Date: Wed, 27 Mar 2013 17:41:59 +0200
> It seems that commit
>
> commit 292f1c7ff6cc10516076ceeea45ed11833bb71c7
> Author: Jiri Pirko <jiri@resnulli.us>
> Date: Tue Feb 12 00:12:03 2013 +0000
>
> sch: make htb_rate_cfg and functions around that generic
>
> adds little regression.
...
> Signed-off-by: Sergey Popovich <popovich_sergei@mail.ru>
Applied.
^ permalink raw reply
* Re: [PATCH] tg3: fix length overflow in VPD firmware parsing
From: David Miller @ 2013-03-27 18:11 UTC (permalink / raw)
To: keescook; +Cc: linux-kernel, mcarlson, mchan, netdev, oded, spender, benli
In-Reply-To: <20130327164050.GA26838@www.outflux.net>
From: Kees Cook <keescook@chromium.org>
Date: Wed, 27 Mar 2013 09:40:50 -0700
> Commit 184b89044fb6e2a74611dafa69b1dce0d98612c6 ("tg3: Use VPD fw version
> when present") introduced VPD parsing that contained a potential length
> overflow.
>
> Limit the hardware's reported firmware string length (max 255 bytes) to
> stay inside the driver's firmware string length (32 bytes). On overflow,
> truncate the formatted firmware string instead of potentially overwriting
> portions of the tg3 struct.
>
> http://cansecwest.com/slides/2013/PrivateCore%20CSW%202013.pdf
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Reported-by: Oded Horovitz <oded@privatecore.com>
> Reported-by: Brad Spengler <spender@grsecurity.net>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] line up comment for ndo_bridge_getlink
From: David Miller @ 2013-03-27 18:11 UTC (permalink / raw)
To: dmitry; +Cc: netdev
In-Reply-To: <1364403241-9061-1-git-send-email-dmitry@broadcom.com>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Wed, 27 Mar 2013 18:54:00 +0200
> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
This bug exists in 'net' so that's where I applied this patch.
^ permalink raw reply
* Re: /128 link-local subnet on 6in4 (sit) tunnels?
From: Hannes Frederic Sowa @ 2013-03-27 18:11 UTC (permalink / raw)
To: Wilco Baan Hofman; +Cc: netdev
In-Reply-To: <1364398673.21709.4.camel@localhost>
On Wed, Mar 27, 2013 at 04:37:53PM +0100, Wilco Baan Hofman wrote:
>
> On Wed, 2013-03-27 at 16:12 +0100, Hannes Frederic Sowa wrote:
> > On Tue, Mar 26, 2013 at 11:04:17PM +0100, Wilco Baan Hofman wrote:
> > > So I was wondering, is there any particular reason for the use of a /128
> > > link-local or is this just a bug?
> >
> > Can you show me the commands how you set up the tunnel. It does create /64 ll
> > with embedded ipv4 addresses for me here on v3.8.
> >
>
> Weird, but sure, here goes:
>
> ip tunnel add tunv6-uplink1 mode sit remote 192.168.1.1 local
> 192.168.1.21
> ip link set tunv6-uplink1 up mtu 1472
In my test I didn't specify the local address so addr.s6_addr32[3]
seems to be zero. I'll have to search the RFCs why this is the case.
^ permalink raw reply
* Re: [PATCH] yam: avoid null pointer dereference error
From: Ben Hutchings @ 2013-03-27 18:12 UTC (permalink / raw)
To: Colin Ian King; +Cc: David Miller, jpr, linux-hams, netdev
In-Reply-To: <5153358A.5010505@canonical.com>
On Wed, 2013-03-27 at 18:08 +0000, Colin Ian King wrote:
> On 27/03/13 17:46, David Miller wrote:
> > From: Ben Hutchings <bhutchings@solarflare.com>
> > Date: Wed, 27 Mar 2013 17:44:17 +0000
> >
> >> On Wed, 2013-03-27 at 11:19 +0000, Colin King wrote:
> >>> From: Colin Ian King <colin.king@canonical.com>
> >>>
> >>> yam_open checks if dev is null, however, before that check it
> >>> accesses some of the fields from dev in a proceeding printk which
> >>> will cause a null pointer dereference error if dev is nul. Move
> >>> the printk to after the null check.
> >>
> >> This function will never be called with dev == NULL.
> >
> > Then let's remove at least that part of the check.
> >
> Good point. How about the following..
> From 564f111f196d9d7293e922a68ba973210d191129 Mon Sep 17 00:00:00 2001
> From: Colin Ian King <colin.king@canonical.com>
> Date: Wed, 27 Mar 2013 13:59:05 -0400
> Subject: [PATCH] yam: remove redundant null check on dev
>
> yam_open has a redundant null check on null, it will
> never be called with dev == NULL. Remove this redundant check.
> This also cleans up a smatch warning:
>
> drivers/net/hamradio/yam.c:869 yam_open() warn: variable
> dereferenced before check 'dev' (see line 867)
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
(for what it's worth)
> ---
> drivers/net/hamradio/yam.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/hamradio/yam.c b/drivers/net/hamradio/yam.c
> index 4cf8f10..b2d863f 100644
> --- a/drivers/net/hamradio/yam.c
> +++ b/drivers/net/hamradio/yam.c
> @@ -866,7 +866,7 @@ static int yam_open(struct net_device *dev)
>
> printk(KERN_INFO "Trying %s at iobase 0x%lx irq %u\n",
> dev->name, dev->base_addr, dev->irq);
>
> - if (!dev || !yp->bitrate)
> + if (!yp->bitrate)
> return -ENXIO;
> if (!dev->base_addr || dev->base_addr > 0x1000 - YAM_EXTENT ||
> dev->irq < 2 || dev->irq > 15) {
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] yam: avoid null pointer dereference error
From: David Miller @ 2013-03-27 18:14 UTC (permalink / raw)
To: bhutchings; +Cc: colin.king, jpr, linux-hams, netdev
In-Reply-To: <1364407953.2922.12.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 27 Mar 2013 18:12:33 +0000
> On Wed, 2013-03-27 at 18:08 +0000, Colin Ian King wrote:
>> On 27/03/13 17:46, David Miller wrote:
>> > From: Ben Hutchings <bhutchings@solarflare.com>
>> > Date: Wed, 27 Mar 2013 17:44:17 +0000
>> >
>> >> On Wed, 2013-03-27 at 11:19 +0000, Colin King wrote:
>> >>> From: Colin Ian King <colin.king@canonical.com>
>> >>>
>> >>> yam_open checks if dev is null, however, before that check it
>> >>> accesses some of the fields from dev in a proceeding printk which
>> >>> will cause a null pointer dereference error if dev is nul. Move
>> >>> the printk to after the null check.
>> >>
>> >> This function will never be called with dev == NULL.
>> >
>> > Then let's remove at least that part of the check.
>> >
>> Good point. How about the following..
>
>> From 564f111f196d9d7293e922a68ba973210d191129 Mon Sep 17 00:00:00 2001
>> From: Colin Ian King <colin.king@canonical.com>
>> Date: Wed, 27 Mar 2013 13:59:05 -0400
>> Subject: [PATCH] yam: remove redundant null check on dev
>>
>> yam_open has a redundant null check on null, it will
>> never be called with dev == NULL. Remove this redundant check.
>> This also cleans up a smatch warning:
>>
>> drivers/net/hamradio/yam.c:869 yam_open() warn: variable
>> dereferenced before check 'dev' (see line 867)
>>
>> Signed-off-by: Colin Ian King <colin.king@canonical.com>
>
> Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
Colin, please formally resubmit this using a fresh mailing list
posting rather than as a reply in this thread. Please incorporate
Ben's reviewed-by tag when doing so, thanks.
^ permalink raw reply
* Re: /128 link-local subnet on 6in4 (sit) tunnels?
From: Wilco Baan Hofman @ 2013-03-27 18:20 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: netdev
In-Reply-To: <20130327181146.GB23223@order.stressinduktion.org>
On Wed, 2013-03-27 at 19:11 +0100, Hannes Frederic Sowa wrote:
> On Wed, Mar 27, 2013 at 04:37:53PM +0100, Wilco Baan Hofman wrote:
> >
> > Weird, but sure, here goes:
> >
> > ip tunnel add tunv6-uplink1 mode sit remote 192.168.1.1 local
> > 192.168.1.21
> > ip link set tunv6-uplink1 up mtu 1472
>
> In my test I didn't specify the local address so addr.s6_addr32[3]
> seems to be zero. I'll have to search the RFCs why this is the case.
See section 3.7, rfc4213:
The interface identifier [RFC3513] for such an interface may be based
on the 32-bit IPv4 address of an underlying interface, or formed
using some other means, as long as it is unique from the other tunnel
endpoint with a reasonably high probability.
http://tools.ietf.org/html/rfc4213
-- Wilco
^ permalink raw reply
* [PATCH v2] yam: remove redundant null check on dev
From: Colin King @ 2013-03-27 18:25 UTC (permalink / raw)
To: Jean-Paul Roubelat, linux-hams, netdev
From: Colin Ian King <colin.king@canonical.com>
yam_open has a redundant null check on null, it will
never be called with dev == NULL. Remove this redundant check.
This also cleans up a smatch warning:
drivers/net/hamradio/yam.c:869 yam_open() warn: variable
dereferenced before check 'dev' (see line 867)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/hamradio/yam.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/hamradio/yam.c b/drivers/net/hamradio/yam.c
index 4cf8f10..b2d863f 100644
--- a/drivers/net/hamradio/yam.c
+++ b/drivers/net/hamradio/yam.c
@@ -866,7 +866,7 @@ static int yam_open(struct net_device *dev)
printk(KERN_INFO "Trying %s at iobase 0x%lx irq %u\n", dev->name, dev->base_addr, dev->irq);
- if (!dev || !yp->bitrate)
+ if (!yp->bitrate)
return -ENXIO;
if (!dev->base_addr || dev->base_addr > 0x1000 - YAM_EXTENT ||
dev->irq < 2 || dev->irq > 15) {
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v2] yam: remove redundant null check on dev
From: David Miller @ 2013-03-27 18:31 UTC (permalink / raw)
To: colin.king; +Cc: jpr, linux-hams, netdev
In-Reply-To: <1364408704-27359-1-git-send-email-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Wed, 27 Mar 2013 18:25:04 +0000
> From: Colin Ian King <colin.king@canonical.com>
>
> yam_open has a redundant null check on null, it will
> never be called with dev == NULL. Remove this redundant check.
> This also cleans up a smatch warning:
>
> drivers/net/hamradio/yam.c:869 yam_open() warn: variable
> dereferenced before check 'dev' (see line 867)
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: Is there a preferred way to get the VXLAN port number?
From: Alexander Duyck @ 2013-03-27 18:32 UTC (permalink / raw)
To: Jesse Gross
Cc: netdev, Gasparakis, Joseph, Stephen Hemminger, pshelar,
David Miller
In-Reply-To: <CAEP_g=9cXwxNE=Fxis2F_qStp1gPsjyXr2wE2agHO9rLZcquXA@mail.gmail.com>
On 03/27/2013 10:26 AM, Jesse Gross wrote:
> On Tue, Mar 26, 2013 at 3:02 PM, Alexander Duyck
> <alexander.h.duyck@intel.com> wrote:
>> I was wondering if someone would happen to know if there is already a
>> preferred way to get the VXLAN port number for things such as
>> configuring a device to recognize a VXLAN frame on receive for parsing
>> purposes?
>>
>> I just wanted to check to make sure I hadn't missed something before
>> submitting a patch that would export a simple function for supplying the
>> vxlan_port value.
> There isn't a good way to do this at the moment. One thing that would
> be nice though is if we can make this as generic as possible to
> different tunneling formats that might need to be configured in this
> way rather than specific to VXLAN.
>
> Another area think about is how best to supply the information to
> GRO/RPS to do the software version of these offloads.
The problem is what I am looking for is very specific to VXLAN. I need
the port number so I can tell the hardware where to expect the VXLAN
frames to be bound to so that the hardware will recognize them and parse
them correctly.
In the case of GRO/RPS the situation is somewhat reversed. You have a
packet with a given port number and you need to offload it. In that
case you can probably do a socket search to determine which offload to
use and have those offloads associated with the socket via something
like the encap_rcv pointer that exists in the udp socket.
The main think I want to do is keep this simple since I would prefer to
not build up any infrastructure that will just get in the way. My
thought for now is to just export a function to allow drivers to fetch
the port number of VXLAN. The only downside is that it forces the VXLAN
module to load if a driver comes up with offload support, similar to how
we have been loading the 8021q module for many of the drivers that
support VLAN offloads. Hopefully if the fixed port number approach wins
out we can simplify things by replacing the function call with a static
define.
Thanks,
Alex
^ permalink raw reply
* Re: /128 link-local subnet on 6in4 (sit) tunnels?
From: Hannes Frederic Sowa @ 2013-03-27 18:35 UTC (permalink / raw)
To: Wilco Baan Hofman; +Cc: netdev, YOSHIFUJI Hideaki
In-Reply-To: <1364408454.15362.1.camel@localhost>
On Wed, Mar 27, 2013 at 07:20:54PM +0100, Wilco Baan Hofman wrote:
>
>
> On Wed, 2013-03-27 at 19:11 +0100, Hannes Frederic Sowa wrote:
> > On Wed, Mar 27, 2013 at 04:37:53PM +0100, Wilco Baan Hofman wrote:
> > >
> > > Weird, but sure, here goes:
> > >
> > > ip tunnel add tunv6-uplink1 mode sit remote 192.168.1.1 local
> > > 192.168.1.21
> > > ip link set tunv6-uplink1 up mtu 1472
> >
> > In my test I didn't specify the local address so addr.s6_addr32[3]
> > seems to be zero. I'll have to search the RFCs why this is the case.
>
> See section 3.7, rfc4213:
>
> The interface identifier [RFC3513] for such an interface may be based
> on the 32-bit IPv4 address of an underlying interface, or formed
> using some other means, as long as it is unique from the other tunnel
> endpoint with a reasonably high probability.
>
> http://tools.ietf.org/html/rfc4213
Thanks, I have seen that already. The sit driver is used for more than 6in4
(6to4, isatap, 6rd). So such a change has to be ok with all the other
protocols implemented by sit. I also looked in the historic git archive for a
rationale of this but couldn't find one. Commit messages 2002 where not as
descriptive as today("Import changeset"). :)
I also added YOSHIFUJI Hideaki as Cc, perhaps he knows the reason.
^ permalink raw reply
* [PATCH -next] GRE: Use strlcat() for size checking
From: Geert Uytterhoeven @ 2013-03-27 18:48 UTC (permalink / raw)
To: Pravin B Shelar, David S. Miller
Cc: netdev, linux-kernel, linux-next, Geert Uytterhoeven
On m68k, gcc tries to be smart and turns
strncat(name, "%d", 2);
into a call to strlen() and a 16-bit store, causing a link failure,
as arch/m68k/include/asm/string.h provides strlen() using a macro:
ERROR: "strlen" [net/ipv4/ip_tunnel.ko] undefined!
Use strlcat() instead to avoid this, which also allows to simplify the
check for buffer overflows.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
--
Compile-tested only
http://kisskb.ellerman.id.au/kisskb/buildresult/8462108/
---
net/ipv4/ip_tunnel.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index 9d96b68..8dbe672 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -284,12 +284,11 @@ static struct net_device *__ip_tunnel_create(struct net *net,
if (parms->name[0])
strlcpy(name, parms->name, IFNAMSIZ);
else {
- if (strlen(ops->kind) + 3 >= IFNAMSIZ) {
+ strlcpy(name, ops->kind, IFNAMSIZ);
+ if (strlcat(name, "%d", IFNAMSIZ) >= IFNAMSIZ) {
err = -E2BIG;
goto failed;
}
- strlcpy(name, ops->kind, IFNAMSIZ);
- strncat(name, "%d", 2);
}
ASSERT_RTNL();
--
1.7.0.4
^ permalink raw reply related
* Re: Is there a preferred way to get the VXLAN port number?
From: David Stevens @ 2013-03-27 18:35 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Alexander Duyck, David Miller, Gasparakis, Joseph, netdev,
netdev-owner, pshelar, Stephen Hemminger
In-Reply-To: <20130327105254.2e10de02@nehalam.linuxnetplumber.net>
netdev-owner@vger.kernel.org wrote on 03/27/2013 01:52:54 PM:
> On Tue, 26 Mar 2013 15:02:45 -0700
> Alexander Duyck <alexander.h.duyck@intel.com> wrote:
>
> > I was wondering if someone would happen to know if there is already a
> > preferred way to get the VXLAN port number for things such as
> > configuring a device to recognize a VXLAN frame on receive for parsing
> > purposes?
> >
> > I just wanted to check to make sure I hadn't missed something before
> > submitting a patch that would export a simple function for supplying
the
> > vxlan_port value.
To answer your question, though, the current vxlan can only listen
on one port per host, supplied with by a module parameter. You can find
what port it's listening on by:
cat /sys/modules/vxlan/parameters/udp_port
[which you can also read with a program, of course].
If multi-port server support is added, that should probably include the
port as part of the current "ip -d link show dev XXX" output, where other
per-device parameters are found.
+-DLS
^ permalink raw reply
* Re: ieee802154: Source addr fix for dgram and some small at86rf230 driver enhancements
From: Stefan Schmidt @ 2013-03-27 18:52 UTC (permalink / raw)
To: David Miller; +Cc: stefan, netdev, linux-zigbee-devel, alan
In-Reply-To: <20130327.005318.1058473513349640907.davem@davemloft.net>
Hello.
On Wed, 2013-03-27 at 00:53, David Miller wrote:
> From: Stefan Schmidt <stefan@datenfreihafen.org>
> Date: Tue, 26 Mar 2013 22:41:28 +0000
>
> > Hello.
> >
> > Second version. Changes since version 1:
> > - Obey 80 chars rules
> > - Switch logging mode to vdbg to avoid noise
> > - Remove uneeded might_sleep()
> >
> > Thanks Alan, Werner and Alex for the feedback.
> >
> > I feel these are ready so I added DaveM and netdev to pick them up if they think
> > the same.
>
> All applied.
Thanks. That was quick. :)
I wonder what happened to the from of two of my commits. Looking at
your repo they only show up my email address:
https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=1486774d69f6e58da16cdae8f17c77ec6569f711
https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=028889b0b32064a3a23d6d8d4ef589a42a6d43c7
The one from Stephen is fine
https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=6364e6ee788ae60f1c2de5c59e39adb157327e6c
The later as an explicit from as he was the author and I just the
sender. For the two problematic ones git am should have picked up the
normal mail from header, no?
I did the patches from my local branch with git format-patch and git
send-email as I have done quite often already. Looking at the mails I
got as CC the from line looks fine too. Also I just saved the mails
here from my mutt and did a git am on it and the name was picked up
correctly.
Is there still some error on my side? I would really like to get it
fixed if there is one. :) Or was it juts a glitch on your side?
regards
Stefan Schmidt
^ permalink raw reply
* [PATCH net-next] bnx2x: fix compilation without CONFIG_BNX2X_SRIOV
From: Dmitry Kravkov @ 2013-03-27 18:56 UTC (permalink / raw)
To: davem, netdev; +Cc: Dmitry Kravkov
Move mutex initialization by allocation of the mailbox it protects.
introduced in commit 1d6f3cd89 'bnx2x: Prevent VF race'
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 1 -
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 2 ++
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 10af03e..fdfe33b 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -12522,7 +12522,6 @@ static int bnx2x_init_one(struct pci_dev *pdev,
*/
if (IS_VF(bp)) {
bp->doorbells = bnx2x_vf_doorbells(bp);
- mutex_init(&bp->vf2pf_mutex);
rc = bnx2x_vf_pci_alloc(bp);
if (rc)
goto init_one_exit;
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
index db63d86..2ce7c74 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
@@ -3425,6 +3425,8 @@ void __iomem *bnx2x_vf_doorbells(struct bnx2x *bp)
int bnx2x_vf_pci_alloc(struct bnx2x *bp)
{
+ mutex_init(&bp->vf2pf_mutex);
+
/* allocate vf2pf mailbox for vf to pf channel */
BNX2X_PCI_ALLOC(bp->vf2pf_mbox, &bp->vf2pf_mbox_mapping,
sizeof(struct bnx2x_vf_mbx_msg));
--
1.7.7.2
^ permalink raw reply related
* Re: ieee802154: Source addr fix for dgram and some small at86rf230 driver enhancements
From: David Miller @ 2013-03-27 19:10 UTC (permalink / raw)
To: stefan; +Cc: netdev, linux-zigbee-devel, alan
In-Reply-To: <20130327185204.GH22584@novatech.datenfreihafen.org>
From: Stefan Schmidt <stefan@datenfreihafen.org>
Date: Wed, 27 Mar 2013 18:52:05 +0000
> Hello.
>
> On Wed, 2013-03-27 at 00:53, David Miller wrote:
>> From: Stefan Schmidt <stefan@datenfreihafen.org>
>> Date: Tue, 26 Mar 2013 22:41:28 +0000
>>
>> > Hello.
>> >
>> > Second version. Changes since version 1:
>> > - Obey 80 chars rules
>> > - Switch logging mode to vdbg to avoid noise
>> > - Remove uneeded might_sleep()
>> >
>> > Thanks Alan, Werner and Alex for the feedback.
>> >
>> > I feel these are ready so I added DaveM and netdev to pick them up if they think
>> > the same.
>>
>> All applied.
>
> Thanks. That was quick. :)
>
> I wonder what happened to the from of two of my commits. Looking at
> your repo they only show up my email address:
>
> https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=1486774d69f6e58da16cdae8f17c77ec6569f711
> https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=028889b0b32064a3a23d6d8d4ef589a42a6d43c7
>
> The one from Stephen is fine
> https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=6364e6ee788ae60f1c2de5c59e39adb157327e6c
>
> The later as an explicit from as he was the author and I just the
> sender. For the two problematic ones git am should have picked up the
> normal mail from header, no?
I don't understand what the problem is.
The first two patches list you as the author, as that is the sender in
the From: field.
Oh, I see, the name, have a look at:
http://patchwork.ozlabs.org/patch/231579/
That's where I take the patches from, click on Download "mbox" and you'll
see that it gave me the headers as:
Date: Tue, 26 Mar 2013 12:41:30 -0000
From: stefan@datenfreihafen.org
^ permalink raw reply
* Re: Is there a preferred way to get the VXLAN port number?
From: David Stevens @ 2013-03-27 19:01 UTC (permalink / raw)
To: Alexander Duyck
Cc: David Miller, Jesse Gross, Gasparakis, Joseph, netdev,
netdev-owner, pshelar, Stephen Hemminger
In-Reply-To: <51533B5B.9030405@intel.com>
netdev-owner@vger.kernel.org wrote on 03/27/2013 02:32:59 PM:
> The main think I want to do is keep this simple since I would prefer to
> not build up any infrastructure that will just get in the way. My
> thought for now is to just export a function to allow drivers to fetch
> the port number of VXLAN. The only downside is that it forces the VXLAN
> module to load if a driver comes up with offload support, similar to how
> we have been loading the 8021q module for many of the drivers that
> support VLAN offloads. Hopefully if the fixed port number approach wins
> out we can simplify things by replacing the function call with a static
> define.
I guess you mean you need to find it within the kernel.
I think whether or not it remains a single port for the machine,
it would be just silly to make it a fixed port, period. Virtually any
service allows an administrator to specify an alternate port to run a
service on.
I think one of the primary reasons is that you may want to run
more than one instance on the same host (e.g., a sandbox installation
alongside a production installation) -- a capability not there now,
even though you can specify an alternate port now.
But if for whatever reason an adminstrator cares that it uses
a particular port number, even in a single instance, there is no
technical reason to disallow it. It'd be bad to assume all VXLAN
must be on the particular port, and equally bad to assume all traffic
for that port is VXLAN (esp. on a host that is not using VXLAN at all,
but very well may want to use a lot of ports, including 8472).
I think it ought to be fully general -- different devices may
use different ports and one device may use multiple listeners on different
ports (to split flows for security, load balancing, or whatever).
I'd make it a per-device function interface that gives you a port
list
for that device (e.g., an array and length or count). Right now, all
devices
would return the single module parameter value, but in the future those
ought
to be capable of being entirely distinct lists of ports.
+-DLS
^ permalink raw reply
* Re: /128 link-local subnet on 6in4 (sit) tunnels?
From: Wilco Baan Hofman @ 2013-03-27 19:12 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: netdev, YOSHIFUJI Hideaki
In-Reply-To: <20130327183558.GC23223@order.stressinduktion.org>
On Wed, 2013-03-27 at 19:35 +0100, Hannes Frederic Sowa wrote:
> On Wed, Mar 27, 2013 at 07:20:54PM +0100, Wilco Baan Hofman wrote:
> > http://tools.ietf.org/html/rfc4213
>
> Thanks, I have seen that already. The sit driver is used for more than 6in4
> (6to4, isatap, 6rd). So such a change has to be ok with all the other
> protocols implemented by sit. I also looked in the historic git archive for a
> rationale of this but couldn't find one. Commit messages 2002 where not as
> descriptive as today("Import changeset"). :)
>
> I also added YOSHIFUJI Hideaki as Cc, perhaps he knows the reason.
Fair enough, I sort of expected a comment to be there as to why it would
be a /128 as well.. :)
-- Wilco
^ permalink raw reply
* [PATCH net-next] bnx2x: handle spurious interrupts
From: Yuval Mintz @ 2013-03-27 18:19 UTC (permalink / raw)
To: davem, netdev; +Cc: Yuval Mintz, Ariel Elior, Eilon Greenstein
In scenarios in which a previous driver was removed without proper cleanup
(e.g., kdump), it is possible for the chip to generate an interrupt without
any apparent reason once interrupts are enabled.
This patch causes the driver to ignore any interrupt which arrives in an
inappropriate time, i.e., when the driver has not yet properly configured
its interrupt routines.
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
Hi Dave,
This was previously sent as part of a patch series - which you rejected due
to this patch. As the merge window opened the following day, I did not
argue on behalf of this patch (but I intend to do so now).
Your issue with the patch was that we've encountered a NULL pointer dereference
once said interrupt was generated, as bnx2x requests the IRQ from the kernel
prior to the initialization of all structs required for its handling.
However, my claim is that the 2 issues are orthogonal -
Perhaps this area in the bnx2x needs to be changed (even though no interrupts
should be generated until all structs are initialized), but the behaviour
added in current patch would still be unchanged.
Since the interrupt is unintentional, the proper driver behaviour should still
be to ignore it, as ACKing the HW for it might be harmful.
Since the driver must request the IRQ prior to enabling HW generation of
interrupts, it would still need to ignore every interrupt arriving during that
interval.
Thanks,
Yuval
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 1 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 11 +++++++++++
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 3 +++
drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c | 3 ++-
4 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
index e4605a9..3e26eb5 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
@@ -1379,6 +1379,7 @@ struct bnx2x {
#define USING_SINGLE_MSIX_FLAG (1 << 20)
#define BC_SUPPORTS_DCBX_MSG_NON_PMF (1 << 21)
#define IS_VF_FLAG (1 << 22)
+#define INTERRUPTS_ENABLED_FLAG (1 << 23)
#define BP_NOMCP(bp) ((bp)->flags & NO_MCP_FLAG)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
index ecac04a3..525c2b5 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@ -1037,6 +1037,17 @@ static irqreturn_t bnx2x_msix_fp_int(int irq, void *fp_cookie)
DP(NETIF_MSG_INTR,
"got an MSI-X interrupt on IDX:SB [fp %d fw_sd %d igusb %d]\n",
fp->index, fp->fw_sb_id, fp->igu_sb_id);
+
+ /* It's possible for a spurious interrupt to be received, if the
+ * driver was loaded above a previous configured function (e.g., kdump).
+ * We simply ignore such interrupts.
+ */
+ if (unlikely(!(bp->flags & INTERRUPTS_ENABLED_FLAG))) {
+ WARN_ONCE(1, "%s: Got Spurious interrupts",
+ bp->dev ? bp->dev->name : "?");
+ return IRQ_HANDLED;
+ }
+
bnx2x_ack_sb(bp, fp->igu_sb_id, USTORM_ID, 0, IGU_INT_DISABLE, 0);
#ifdef BNX2X_STOP_ON_ERROR
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index c4daee1..1776b8b 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -868,6 +868,7 @@ static void bnx2x_int_disable(struct bnx2x *bp)
bnx2x_hc_int_disable(bp);
else
bnx2x_igu_int_disable(bp);
+ bp->flags &= ~INTERRUPTS_ENABLED_FLAG;
}
void bnx2x_panic_dump(struct bnx2x *bp, bool disable_int)
@@ -1607,6 +1608,8 @@ static void bnx2x_igu_int_enable(struct bnx2x *bp)
void bnx2x_int_enable(struct bnx2x *bp)
{
+ bp->flags |= INTERRUPTS_ENABLED_FLAG;
+
if (bp->common.int_block == INT_BLOCK_HC)
bnx2x_hc_int_enable(bp);
else
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c
index 3624612..df9209e 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c
@@ -268,7 +268,8 @@ int bnx2x_vfpf_acquire(struct bnx2x *bp, u8 tx_count, u8 rx_count)
bp->mf_mode = 0;
bp->common.flash_size = 0;
bp->flags |=
- NO_WOL_FLAG | NO_ISCSI_OOO_FLAG | NO_ISCSI_FLAG | NO_FCOE_FLAG;
+ NO_WOL_FLAG | NO_ISCSI_OOO_FLAG | NO_ISCSI_FLAG | NO_FCOE_FLAG |
+ INTERRUPTS_ENABLED_FLAG;
bp->igu_sb_cnt = 1;
bp->igu_base_sb = bp->acquire_resp.resc.hw_sbs[0].hw_sb_id;
strlcpy(bp->fw_ver, bp->acquire_resp.pfdev_info.fw_ver,
--
1.7.9.GIT
^ permalink raw reply related
* Re: [PATCH net-next] bnx2x: handle spurious interrupts
From: David Miller @ 2013-03-27 19:27 UTC (permalink / raw)
To: yuvalmin; +Cc: netdev, ariele, eilong
In-Reply-To: <1364408379-4353-1-git-send-email-yuvalmin@broadcom.com>
From: "Yuval Mintz" <yuvalmin@broadcom.com>
Date: Wed, 27 Mar 2013 20:19:39 +0200
> Since the driver must request the IRQ prior to enabling HW generation of
> interrupts, it would still need to ignore every interrupt arriving during that
> interval.
This is the real issue.
request_irq() must not be invoked until you are ready to handle
interrupts, and this means initializing any and all software
datastructures that might be accessed in the interrupt handler.
If this requirement is met, seeing NULL pointers is not possible.
I still reject this patch, please fix the fundamental issue instead,
thanks.
^ permalink raw reply
* [PATCH v2 6/6] sctp: convert sctp_assoc_set_id to use idr_alloc_cyclic
From: Jeff Layton @ 2013-03-27 19:29 UTC (permalink / raw)
To: akpm
Cc: linux-kernel, tj, Vlad Yasevich, Sridhar Samudrala, Neil Horman,
David S. Miller, linux-sctp, netdev
In-Reply-To: <1364412578-7462-1-git-send-email-jlayton@redhat.com>
(Note: compile-tested only)
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Cc: Vlad Yasevich <vyasevich@gmail.com>
Cc: Sridhar Samudrala <sri@us.ibm.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-sctp@vger.kernel.org
Cc: netdev@vger.kernel.org
---
net/sctp/associola.c | 16 ++--------------
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/net/sctp/associola.c b/net/sctp/associola.c
index d2709e2..fa261a3 100644
--- a/net/sctp/associola.c
+++ b/net/sctp/associola.c
@@ -66,13 +66,6 @@ static void sctp_assoc_bh_rcv(struct work_struct *work);
static void sctp_assoc_free_asconf_acks(struct sctp_association *asoc);
static void sctp_assoc_free_asconf_queue(struct sctp_association *asoc);
-/* Keep track of the new idr low so that we don't re-use association id
- * numbers too fast. It is protected by they idr spin lock is in the
- * range of 1 - INT_MAX.
- */
-static u32 idr_low = 1;
-
-
/* 1st Level Abstractions. */
/* Initialize a new association from provided memory. */
@@ -1601,13 +1594,8 @@ int sctp_assoc_set_id(struct sctp_association *asoc, gfp_t gfp)
if (preload)
idr_preload(gfp);
spin_lock_bh(&sctp_assocs_id_lock);
- /* 0 is not a valid id, idr_low is always >= 1 */
- ret = idr_alloc(&sctp_assocs_id, asoc, idr_low, 0, GFP_NOWAIT);
- if (ret >= 0) {
- idr_low = ret + 1;
- if (idr_low == INT_MAX)
- idr_low = 1;
- }
+ /* 0 is not a valid assoc_id, must be >= 1 */
+ ret = idr_alloc_cyclic(&sctp_assocs_id, asoc, 1, 0, GFP_NOWAIT);
spin_unlock_bh(&sctp_assocs_id_lock);
if (preload)
idr_preload_end();
--
1.7.11.7
^ 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