* Re: surprising memory request
From: Eric Dumazet @ 2013-01-18 17:54 UTC (permalink / raw)
To: Dirk Hohndel; +Cc: Jason Wang, netdev, David Woodhouse
In-Reply-To: <1358531190.11051.402.camel@edumazet-glaptop>
On Fri, 2013-01-18 at 09:46 -0800, Eric Dumazet wrote:
> Thats because Jason thought that tun device had to have an insane number
> of queues to get good performance.
>
> #define MAX_TAP_QUEUES 1024
>
> Thats crazy if your machine has say 8 cpus.
>
> And Jason didnt care to adapt the memory allocations done in
> alloc_netdev_mqs(), in order to switch to vmalloc() when kmalloc()
> fails.
I suggest using the more reasonable :
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index c81680d..ec18fbf 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -113,7 +113,7 @@ struct tap_filter {
* the order of 100-200 CPUs so this leaves us some breathing space if we want
* to match a queue per guest CPU.
*/
-#define MAX_TAP_QUEUES 1024
+#define MAX_TAP_QUEUES DEFAULT_MAX_NUM_RSS_QUEUES
#define TUN_FLOW_EXPIRE (3 * HZ)
^ permalink raw reply related
* Re: surprising memory request
From: David Woodhouse @ 2013-01-18 17:59 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Dirk Hohndel, Jason Wang, netdev
In-Reply-To: <1358531190.11051.402.camel@edumazet-glaptop>
[-- Attachment #1: Type: text/plain, Size: 294 bytes --]
On Fri, 2013-01-18 at 09:46 -0800, Eric Dumazet wrote:
>
> #define MAX_TAP_QUEUES 1024
>
> Thats crazy if your machine has say 8 cpus.
Even crazier if your userspace is never going to *use* MQ. Can't we
default to one queue unless userspace explicitly requests more?
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply
* Re: surprising memory request
From: Waskiewicz Jr, Peter P @ 2013-01-18 18:09 UTC (permalink / raw)
To: Dirk Hohndel; +Cc: netdev, David Woodhouse
In-Reply-To: <20130118085818.147220.FMU5901@air.gr8dns.org>
On Fri, Jan 18, 2013 at 08:58:18AM -0800, Dirk Hohndel wrote:
>
> Running openconnect on a very recent 3.8 (a few commits before Linus cut
> RC4) I get this allocation failure. I'm unclear why we would need 128
> contiguous pages here...
>
> /D
[...]
> [66015.674074] 541777 total pagecache pages
> [66015.674075] 142 pages in swap cache
> [66015.674078] Swap cache stats: add 4420, delete 4278, find 106/118
> [66015.674080] Free swap = 9197216kB
> [66015.674082] Total swap = 9213948kB
> [66015.710738] 2094576 pages RAM
> [66015.710745] 85536 pages reserved
> [66015.710746] 1755663 pages shared
> [66015.710748] 1488520 pages non-shared
> [66015.710752] netdev: Unable to allocate 1024 tx queues
What device are you using that is trying to allocate so many Tx queues?
Assuming this is coming from the VPN device coming online; is SELinux
in enforcing mode? There have been a number of changes in the tun
driver recently around the multiqueue area with SELinux, just a theory
at this point. I can keep digging.
Cheers,
-PJ
^ permalink raw reply
* Re: surprising memory request
From: Waskiewicz Jr, Peter P @ 2013-01-18 18:11 UTC (permalink / raw)
To: Dirk Hohndel; +Cc: netdev, David Woodhouse
In-Reply-To: <20130118180930.GA15466@ppwaskie-mobl2.amr.corp.intel.com>
On Fri, Jan 18, 2013 at 10:09:30AM -0800, Waskiewicz Jr, Peter P wrote:
> On Fri, Jan 18, 2013 at 08:58:18AM -0800, Dirk Hohndel wrote:
> >
> > Running openconnect on a very recent 3.8 (a few commits before Linus cut
> > RC4) I get this allocation failure. I'm unclear why we would need 128
> > contiguous pages here...
> >
> > /D
>
> [...]
>
> > [66015.674074] 541777 total pagecache pages
> > [66015.674075] 142 pages in swap cache
> > [66015.674078] Swap cache stats: add 4420, delete 4278, find 106/118
> > [66015.674080] Free swap = 9197216kB
> > [66015.674082] Total swap = 9213948kB
> > [66015.710738] 2094576 pages RAM
> > [66015.710745] 85536 pages reserved
> > [66015.710746] 1755663 pages shared
> > [66015.710748] 1488520 pages non-shared
> > [66015.710752] netdev: Unable to allocate 1024 tx queues
>
> What device are you using that is trying to allocate so many Tx queues?
> Assuming this is coming from the VPN device coming online; is SELinux
> in enforcing mode? There have been a number of changes in the tun
> driver recently around the multiqueue area with SELinux, just a theory
> at this point. I can keep digging.
Or I can see Eric's mail before replying, nevermind.
^ permalink raw reply
* Re: [PATCH] ping doc: Fix typo.
From: YOSHIFUJI Hideaki @ 2013-01-18 18:20 UTC (permalink / raw)
To: Jan Synacek; +Cc: netdev, YOSHIFUJI Hideaki
In-Reply-To: <1358508096-19915-1-git-send-email-jsynacek@redhat.com>
(2013年01月18日 20:21), Jan Synacek wrote:
> Signed-off-by: Jan Synacek <jsynacek@redhat.com>
> ---
> doc/ping.sgml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/doc/ping.sgml b/doc/ping.sgml
> index 4e0e65f..eec92a2 100644
> --- a/doc/ping.sgml
> +++ b/doc/ping.sgml
> @@ -600,7 +600,7 @@ Many Hosts and Gateways ignore the RECORD_ROUTE option.
> <listitem><para>
> The maximum IP header length is too small for options like
> RECORD_ROUTE to be completely useful.
> -There's not much that that can be done about this, however.
> +There's not much that can be done about this, however.
> </para></listitem>
> <listitem><para>
> Flood pinging is not recommended in general, and flood pinging the
>
Applied, thanks.
--yoshfuji
^ permalink raw reply
* Re: ip6_dst_lookup_tail oops
From: Neil Horman @ 2013-01-18 18:25 UTC (permalink / raw)
To: Dave Jones; +Cc: netdev
In-Reply-To: <20130118152023.GA2116@redhat.com>
On Fri, Jan 18, 2013 at 10:20:23AM -0500, Dave Jones wrote:
> On Fri, Jan 18, 2013 at 07:48:09AM -0500, Neil Horman wrote:
> > > Now I've hit it with rt->n = 2000000000000010. So I'm starting to
> > > think this is getting passed in directly from userspace somehow, as
> > > these values look like the output of my 'set a few random bits' routine
> > > that sometimes gets called for params.
> > >
> > > I'm having trouble mapping a corrupt sendmsg parameter to a messed up rt->n though.
> > >
> > Well, neighbor table entries for ipv6 get added over rtnetlink,
>
> ah, that's helpful. That explains why just fuzzing sendmsg alone won't hit this.
>
Yeah, I expect the failure is going to be preceded by a RTM_NEWNEIGH message at
some point, or possibly some combination of RTM_NEWNEIGH and RTM_ROUTE that
erroneously sets up that bogus neighbor pointer.
> > but it seems you
> > would have to be able to memory map the socket to get a pointer like that into
> > place. Trinity doesn't record the syscalls it makes does it? That might be
> > helpful in tracking this down.
>
> It does, but when it takes two days to hit something like this, you end up
> with gigabytes of data to look through.
>
Yeah, thats a bit much. I suppose at this point I'd suggest running a stap
script or just modifying the kernel to dump the neighbour table every time you
add a neighbor entry in __neigh_create. That might at least get us closer to
the point at which we introduce the problem.
Best
Neil
> Dave
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH for 3.8] iproute2: Add "ip netns pids" and "ip netns identify"
From: Eric W. Biederman @ 2013-01-18 18:49 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Stephen Hemminger, netdev, Serge E. Hallyn
In-Reply-To: <1358517218.21229.6.camel@deadeye.wl.decadent.org.uk>
Ben Hutchings <bhutchings@solarflare.com> writes:
> On Thu, 2013-01-17 at 17:27 -0800, Eric W. Biederman wrote:
>> Ben Hutchings <bhutchings@solarflare.com> writes:
>>
>> > On Thu, 2013-01-17 at 16:23 -0800, Eric W. Biederman wrote:
>> >> Ben Hutchings <bhutchings@solarflare.com> writes:
>> >>
>> >> > On Mon, 2012-11-26 at 17:16 -0600, Eric W. Biederman wrote:
>> > [...]
>> >> >> --- a/ip/ipnetns.c
>> >> >> +++ b/ip/ipnetns.c
>> > [...]
>> >> >> +static int is_pid(const char *str)
>> >> >> +{
>> >> >> + int ch;
>> >> >> + for (; (ch = *str); str++) {
>> >> >> + if (!isdigit(ch))
>> >> >
>> >> > ch must be cast to unsigned char before passing to isdigit().
>> >>
>> >> isdigit is defined to take an int. A legacy of the implicit casts in
>> >> the K&R C days. Casting to unsigned char would be pointless and silly.
>> > [...]
>> >
>> > It's not pointless. This is explained in the very first line of the
>> > description in the manual page...
>>
>> If it's not pointless it is an implementation bug.
>
> You can either get in your time machine and go back to 1978 and fix it,
> or add the cast like every C programmer who knows what the C standards
> say about these functions.
So I took a moment to look. The C standard is indeed does not say
anything about this and supporting signed char becomes a quality of
implementation issue. glibc supports being passed signed character
values.
> Testing on one implementation doesn't prove anything. 'char' can be
> signed or unsigned depending on the architecture, and some C libraries
> work around buggy applications that . That's no reason to write another
> buggy application.
This code by it's very nature is not portable. The code is not suid
so insane level of paranoia don't need to be maintained. The definition
in the C standard is a least common denominator requirement. Posix
copies that least common denominator requirement. Glibc does not
implment the least common denominator.
There is no advantage for an implemenation to implement only the least
common denominator of functionality in isdigit. There is a huge
advantage for an implementation of the cypte functions on platforms with
signed char to have an array with 384 entries. It is nearly humanly
impossible to remember you need to type isdigit((unsigned)string[n]),
not to mention how easy it is for casts to go wrong.
So no I do not consider programs that are not strictly conformant with
the C standard broken. I consider implementations of isdigit that are
strictly conformat with the C standard to be canidadates for patches.
At this point I will happily add support to any ctype implemenation I
meet that has such a poor quality of implementation that you have to be
a language lawyer in top form to use isdigit properly.
Eric
^ permalink raw reply
* Re: [PATCH net] net: cdc_ncm: workaround for missing CDC Union
From: Oliver Neukum @ 2013-01-18 19:11 UTC (permalink / raw)
To: Bjørn Mork
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
Greg Suarez, Alexey Orishko
In-Reply-To: <1358519147-10073-1-git-send-email-bjorn-yOkvZcmFvRU@public.gmane.org>
On Friday 18 January 2013 15:25:47 Bjørn Mork wrote:
> Adding support for the MBIM mode in some Sierra Wireless devices.
>
> Some Sierra Wireless firmwares support CDC MBIM but have no CDC
> Union funtional descriptor. This violates the MBIM specification,
> but we can easily work around the bug by looking at the Interface
> Association Descriptor instead. This is most likely what
> Windows uses too, which explains how the firmware bug has gone
> unnoticed until now.
Should we do this for everything CDC?
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* Re: [net-next v2 00/12][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2013-01-18 19:11 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1358521487-28610-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 18 Jan 2013 07:04:35 -0800
> This series contains updates to e1000e and igb. Most notably is the
> added timestamp support in e1000e and additional software timestamp
> support in igb. As well as, the added thermal data support and SR-IOV
> configuration support in igb.
>
> v2- dropped the following patches from the previous 14 patch series
> because changes were requested from the community:
> e1000e: add support for IEEE-1588 PTP
> igb: Report L4 Rx hash via skb->l4_rxhash
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH] ipv6: check if dereference of ipv6 header is safe
From: Eric Dumazet @ 2013-01-18 19:12 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: netdev
In-Reply-To: <20130118030819.GA20324@order.stressinduktion.org>
On Fri, 2013-01-18 at 04:08 +0100, Hannes Frederic Sowa wrote:
> Please correct me if I am wrong:
>
> The callstack as captured in ipip6_rcv:
> ipip6_rcv+0xcd/0x680 [sit]
> tunnel64_rcv+0x4a/0x174 [tunnel4]
> ip_local_deliver+0x152/0x470
> ? ip_local_deliver+0x75/0x470
> ip_rcv+0x36d/0x650
>
> ip_rcv does first check if the ipv4 header is complete (inclusive options) and
> passes control to ip_local_deliver which calls __skb_pull(skb,
> ip_hdrlen(skb)). So ->data is forwarded behind the ipv4 header. The next
> pskb_may_pull check would check if the necessary amount of data behind the
> ipv4 header is available hence I assume the check in tunnel64_rcv is enough:
Oh, yes, thats fine.
^ permalink raw reply
* Re: [PATCH v3 1/2] net: asix: init ASIX AX88772B MAC from EEPROM
From: David Miller @ 2013-01-18 19:14 UTC (permalink / raw)
To: dev; +Cc: netdev, linux-usb, oneukum, christian.riesch, eric.dumazet
In-Reply-To: <1358346247-10579-1-git-send-email-dev@lynxeye.de>
From: Lucas Stach <dev@lynxeye.de>
Date: Wed, 16 Jan 2013 15:24:06 +0100
> The device comes up with a MAC address of all zeros. We need to read the
> initial device MAC from EEPROM so it can be set properly later.
>
> Signed-off-by: Lucas Stach <dev@lynxeye.de>
Applied.
^ permalink raw reply
* Re: [PATCH v3 2/2] net: asix: handle packets crossing URB boundaries
From: David Miller @ 2013-01-18 19:14 UTC (permalink / raw)
To: dev-8ppwABl0HbeELgA04lAiVw
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
oneukum-l3A5Bk7waGM, christian.riesch-3mrvs1K0uXizZXS1Dc/lvw,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1358346247-10579-2-git-send-email-dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
From: Lucas Stach <dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
Date: Wed, 16 Jan 2013 15:24:07 +0100
> ASIX AX88772B started to pack data even more tightly. Packets and the ASIX packet
> header may now cross URB boundaries. To handle this we have to introduce
> some state between individual calls to asix_rx_fixup().
>
> Signed-off-by: Lucas Stach <dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* Re: [PATCH] net: calxedaxgmac: throw away overrun frames
From: David Miller @ 2013-01-18 19:15 UTC (permalink / raw)
To: robherring2; +Cc: netdev, rob.herring, linux-kernel
In-Reply-To: <1358379397-7152-1-git-send-email-robherring2@gmail.com>
From: Rob Herring <robherring2@gmail.com>
Date: Wed, 16 Jan 2013 17:36:37 -0600
> From: Rob Herring <rob.herring@calxeda.com>
>
> The xgmac driver assumes 1 frame per descriptor. If a frame larger than
> the descriptor's buffer size is received, the frame will spill over into
> the next descriptor. So check for received frames that span more than one
> descriptor and discard them. This prevents a crash if we receive erroneous
> large packets.
>
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Applied.
^ permalink raw reply
* Re: [PATCH v3 1/1 net-next] net: fec: enable pause frame to improve rx prefomance for 1G network
From: David Miller @ 2013-01-18 19:16 UTC (permalink / raw)
To: Frank.Li
Cc: lznuaa, shawn.guo, B38611, linux-arm-kernel, netdev, bhutchings,
s.hauer
In-Reply-To: <1358391358-27977-1-git-send-email-Frank.Li@freescale.com>
From: Frank Li <Frank.Li@freescale.com>
Date: Thu, 17 Jan 2013 10:55:58 +0800
> The limition of imx6 internal bus cause fec can't achieve 1G perfomance.
> There will be many packages lost because FIFO over run.
>
> This patch enable pause frame flow control.
...
> Signed-off-by: Frank Li <Frank.Li@freescale.com>
> Signed-off-by: Fugang Duan <B38611@freescale.com>
Applied.
^ permalink raw reply
* [PATCH] ipv6: remove unneeded check to pskb_may_pull in ipip6_rcv
From: Hannes Frederic Sowa @ 2013-01-18 19:18 UTC (permalink / raw)
To: netdev
This is already checked by the caller (tunnel64_rcv) and brings ipip6_rcv
in line with ipip_rcv.
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
net/ipv6/sit.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index cfba99b..98fe536 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -592,15 +592,10 @@ out:
static int ipip6_rcv(struct sk_buff *skb)
{
- const struct iphdr *iph;
+ const struct iphdr *iph = ip_hdr(skb);
struct ip_tunnel *tunnel;
int err;
- if (!pskb_may_pull(skb, sizeof(struct ipv6hdr)))
- goto out;
-
- iph = ip_hdr(skb);
-
tunnel = ipip6_tunnel_lookup(dev_net(skb->dev), skb->dev,
iph->saddr, iph->daddr);
if (tunnel != NULL) {
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH v2 1/2] 6lowpan: Refactor packet delivery into a function
From: David Miller @ 2013-01-18 19:18 UTC (permalink / raw)
To: alan-yzvJWuRpmD1zbRFIqnYvSA
Cc: eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1358399388-30062-2-git-send-email-alan-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org>
From: Alan Ott <alan-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org>
Date: Thu, 17 Jan 2013 00:09:47 -0500
> Refactor the handing of the skb's to the individual lowpan devices into a
> function.
>
> Signed-off-by: Alan Ott <alan-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org>
Applied.
------------------------------------------------------------------------------
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812
^ permalink raw reply
* Re: [PATCH v2 2/2] 6lowpan: Handle uncompressed IPv6 packets over 6LoWPAN
From: David Miller @ 2013-01-18 19:18 UTC (permalink / raw)
To: alan-yzvJWuRpmD1zbRFIqnYvSA
Cc: eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1358399388-30062-3-git-send-email-alan-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org>
From: Alan Ott <alan-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org>
Date: Thu, 17 Jan 2013 00:09:48 -0500
> Handle the reception of uncompressed packets (dispatch type = IPv6).
>
> Signed-off-by: Alan Ott <alan-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org>
Applied.
------------------------------------------------------------------------------
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812
^ permalink raw reply
* Re: [PATCH] ipv6: Add an error handler for icmp6
From: David Miller @ 2013-01-18 19:20 UTC (permalink / raw)
To: steffen.klassert; +Cc: djduanjiong, netdev
In-Reply-To: <20130117080949.GA24987@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Thu, 17 Jan 2013 09:09:49 +0100
> pmtu and redirect events are now handled in the protocols error handler,
> so add an error handler for icmp6 to do this. It is needed in the case
> when we have no socket context. Based on a patch by Duan Jiong.
>
> Reported-by: Duan Jiong <djduanjiong@gmail.com>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Applied and queued up for -stable, thanks Steffen.
^ permalink raw reply
* Re: [PATCH, resubmit] ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit ethernet adapter driver
From: David Miller @ 2013-01-18 19:23 UTC (permalink / raw)
To: freddy; +Cc: netdev, linux-usb, linux-kernel, louis
In-Reply-To: <1358415174-4348-1-git-send-email-freddy@asix.com.tw>
From: Freddy Xin <freddy@asix.com.tw>
Date: Thu, 17 Jan 2013 17:32:54 +0800
> +struct ax88179_rx_pkt_header {
> +
> + u8 l4_csum_err:1,
Get rid of such extraneous empty lines. They do not add clarity,
rather they just take up space.
> + ret = fn(dev, cmd, USB_DIR_IN | USB_TYPE_VENDOR |
> + USB_RECIP_DEVICE, value, index, data, size);
This is not indented properly. When a function call takes up
multiple lines, the text on the second and subsequent lines must
be left justified to the first column after the openning parenthesis
of the function call, like this:
function(arg1, arg2,
arg3, arg4);
You must use the appropriate combination of TAB and space characters
to achieve this. If you are trying to only use TAB characters, you
are doing it wrong.
This code has a lot of other similar coding style errors, please
put some effort into fixing them up before you consider resubmitting
this driver.
All of the coding style errors are probably why nobody reviewed your
driver the first time around, there's already enough properly styled
submissions to review.
^ permalink raw reply
* Re: [PATCH net 0/2] net/mlx4: two virtualization bug fixes
From: David Miller @ 2013-01-18 19:25 UTC (permalink / raw)
To: ogerlitz; +Cc: netdev, amirv, jackm, yevgenyp
In-Reply-To: <1358436643-1326-1-git-send-email-ogerlitz@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Thu, 17 Jan 2013 17:30:41 +0200
> These are two fixes to driver bugs which were introduced during the integration
> of the SRIOV patches, would love see them going to -stable too.
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH v5 1/1] net: ethernet: davinci_cpdma: Add boundary for rx and tx descriptors
From: David Miller @ 2013-01-18 19:28 UTC (permalink / raw)
To: mugunthanvnm; +Cc: netdev, s.hauer
In-Reply-To: <1358440294-13676-1-git-send-email-mugunthanvnm@ti.com>
From: Mugunthan V N <mugunthanvnm@ti.com>
Date: Thu, 17 Jan 2013 22:01:34 +0530
> When there is heavy transmission traffic in the CPDMA, then Rx descriptors
> memory is also utilized as tx desc memory looses all rx descriptors and the
> driver stops working then.
>
> This patch adds boundary for tx and rx descriptors in bd ram dividing the
> descriptor memory to ensure that during heavy transmission tx doesn't use
> rx descriptors.
>
> This patch is already applied to davinci_emac driver, since CPSW and
> davici_dmac shares the same CPDMA, moving the boundry seperation from
> Davinci EMAC driver to CPDMA driver which was done in the following
> commit
>
> commit 86d8c07ff2448eb4e860e50f34ef6ee78e45c40c
> Author: Sascha Hauer <s.hauer@pengutronix.de>
> Date: Tue Jan 3 05:27:47 2012 +0000
>
> net/davinci: do not use all descriptors for tx packets
...
> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] net: usb: initialize tmp in dm9601.c to avoid warning
From: David Miller @ 2013-01-18 19:29 UTC (permalink / raw)
To: sque; +Cc: jacmet, netdev, msb
In-Reply-To: <1358450989-25205-1-git-send-email-sque@chromium.org>
From: Simon Que <sque@chromium.org>
Date: Thu, 17 Jan 2013 11:29:49 -0800
> In two places, tmp is initialized implicitly by being passed as a
> pointer during a function call. However, this is not obvious to the
> compiler, which logs a warning.
>
> Signed-off-by: Simon Que <sque@chromium.org>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] ipv6: add anti-spoofing checks for 6to4 and 6rd
From: David Miller @ 2013-01-18 19:32 UTC (permalink / raw)
To: hannes; +Cc: yoshfuji, netdev
In-Reply-To: <20130117200733.GA2055@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Thu, 17 Jan 2013 21:07:33 +0100
> +#ifdef CONFIG_IPV6_SIT_6RD
> + if (ipv6_prefix_equal(addr6, &tunnel->ip6rd.prefix,
> + tunnel->ip6rd.prefixlen) &&
> + *addr != try_6rd(addr6, tunnel))
> + return 0;
> +#else
> + if (addr6->s6_addr16[0] == htons(0x2002) &&
> + *addr != try_6rd(addr6, tunnel))
> + return 0;
> +#endif
> + return 1;
> +}
...
> + } else if (!sit_chk_encap_addr(tunnel, &iph->saddr,
> + &ipv6_hdr(skb)->saddr) ||
> + !sit_chk_encap_addr(tunnel, &iph->daddr,
> + &ipv6_hdr(skb)->daddr)) {
None of these conditionals are indented properly, please fix this up.
Both conditionals and function calls that span multiple lines must use
the column after the openning parenthesis of the initial line as the
left justification of subsequent lines.
I see what you're doing, just using TAB characters exclusively to
ident, don't do that. You must use the appropriate combination of
TAB and space characters to achieve the correct indentaiton.
^ permalink raw reply
* Re: [PATCH] smsc: smc911x: Fix sparse warnings
From: David Miller @ 2013-01-18 19:33 UTC (permalink / raw)
To: festevam; +Cc: netdev, fabio.estevam
In-Reply-To: <1358477163-7582-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <festevam@gmail.com>
Date: Fri, 18 Jan 2013 00:46:02 -0200
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> ioremap returns 'void __iomem *' type.
>
> Fix the following build warnings:
...
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [patch] enic: change sprintf() to snprintf()
From: David Miller @ 2013-01-18 19:35 UTC (permalink / raw)
To: dan.carpenter
Cc: benve, roprabhu, neepatel, nistrive, netdev, kernel-janitors
In-Reply-To: <20130118074618.GC31793@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Fri, 18 Jan 2013 10:46:18 +0300
> These are copying data into 16 char arrays. They all specify that the
> first string can't be more than 11 characters but once you add on the
> "-rx-" and the NUL character there isn't space for the %d.
>
> The first string is probably never going to be 11 characters, but if it
> is then let's truncate the string instead of corrupting memory.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied to net-next, thanks.
^ 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