* Re: [PATCH 1/2] igb: fix rtnl race in PM resume path
From: Jeff Kirsher @ 2012-04-05 23:02 UTC (permalink / raw)
To: Benjamin Poirier
Cc: Alex Duyck, Bruce Allan, Carolyn Wyborny, David S. Miller,
Don Skidmore, e1000-devel, Emil Tantilov, Eric Dumazet, Greg Rose,
Jesse Brandeburg, John Fastabend, John Ronciak, linux-kernel,
netdev, Peter P Waskiewicz Jr
In-Reply-To: <1333638664-17062-1-git-send-email-bpoirier@suse.de>
[-- Attachment #1: Type: text/plain, Size: 523 bytes --]
On Thu, 2012-04-05 at 11:11 -0400, Benjamin Poirier wrote:
> Since the caller (PM resume code) is not the one holding rtnl, when
> taking the
> 'else' branch rtnl may be released at any moment, thereby defeating
> the whole
> purpose of this code block.
>
> Signed-off-by: Benjamin Poirier <bpoirier@suse.de>
> ---
> drivers/net/ethernet/intel/igb/igb_main.c | 20 ++++++--------------
> 1 files changed, 6 insertions(+), 14 deletions(-)
Thanks Benjamin, I will add the patch to my igb queue of patches.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* RE: [net-next 3/3] ixgbe: add syfs interface for to export read only driver information
From: Skidmore, Donald C @ 2012-04-05 23:01 UTC (permalink / raw)
To: David Miller, bhutchings@solarflare.com
Cc: florian@openwrt.org, Kirsher, Jeffrey T, netdev@vger.kernel.org,
gospo@redhat.com, sassmann@redhat.com
In-Reply-To: <20120405.184935.422690748002137749.davem@davemloft.net>
>-----Original Message-----
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Thursday, April 05, 2012 3:50 PM
>To: bhutchings@solarflare.com
>Cc: florian@openwrt.org; Kirsher, Jeffrey T; Skidmore, Donald C;
>netdev@vger.kernel.org; gospo@redhat.com; sassmann@redhat.com
>Subject: Re: [net-next 3/3] ixgbe: add syfs interface for to export read
>only driver information
>
>From: Ben Hutchings <bhutchings@solarflare.com>
>Date: Thu, 5 Apr 2012 17:32:05 +0100
>
>> On Thu, 2012-04-05 at 14:19 +0200, Florian Fainelli wrote:
>>> Hi,
>>>
>>> Le 04/05/12 12:47, Jeff Kirsher a écrit :
>>> > From: Don Skidmore<donald.c.skidmore@intel.com>
>>> >
>>> > This patch exports non-thermal (which was done via hwmon in an
>earlier
>>> > patch) data to syfs. All of the fields are read only as this
>interface
>>> > is to only export driver data.
>>> >
>>> > Signed-off-by: Don Skidmore<donald.c.skidmore@intel.com>
>>> > Tested-by: Stephen Ko<stephen.s.ko@intel.com>
>>> > Signed-off-by: Jeff Kirsher<jeffrey.t.kirsher@intel.com>
>>> > ---
>>>
>>> I only looked briefly at the exported attributes, but most of them
>can
>>> already be queried using ethtool, can't they?
>> [...]
>>
>> I agree, it looks like most of these are:
>>
>> (1) already exposed through ethtool commands (ETHTOOL_GSET,
>> ETHTOOL_GDRVINFO, ETHTOOL_GLINK and ETHTOOL_GPERMADDR), or
>> (2) already exposed through rtnetlink or the net device in sysfs, or
>> (3) statistics that should be exposed through ETHTOOL_GSTATS
>>
>> I imagine there are some that don't fall into those categories, but I
>> don't see why they should *all* be exposed in a non-standard and/or
>> redundant way.
>
>Agreed.
Thanks for the input. I'll start on refactoring the patch to exclude all items that are exposed in any other way.
-Don Skidmore <donald.c.skidmore@intel.com>
^ permalink raw reply
* Re: [net-next 3/3] ixgbe: add syfs interface for to export read only driver information
From: David Miller @ 2012-04-05 22:49 UTC (permalink / raw)
To: bhutchings
Cc: florian, jeffrey.t.kirsher, donald.c.skidmore, netdev, gospo,
sassmann
In-Reply-To: <1333643525.2652.10.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 5 Apr 2012 17:32:05 +0100
> On Thu, 2012-04-05 at 14:19 +0200, Florian Fainelli wrote:
>> Hi,
>>
>> Le 04/05/12 12:47, Jeff Kirsher a écrit :
>> > From: Don Skidmore<donald.c.skidmore@intel.com>
>> >
>> > This patch exports non-thermal (which was done via hwmon in an earlier
>> > patch) data to syfs. All of the fields are read only as this interface
>> > is to only export driver data.
>> >
>> > Signed-off-by: Don Skidmore<donald.c.skidmore@intel.com>
>> > Tested-by: Stephen Ko<stephen.s.ko@intel.com>
>> > Signed-off-by: Jeff Kirsher<jeffrey.t.kirsher@intel.com>
>> > ---
>>
>> I only looked briefly at the exported attributes, but most of them can
>> already be queried using ethtool, can't they?
> [...]
>
> I agree, it looks like most of these are:
>
> (1) already exposed through ethtool commands (ETHTOOL_GSET,
> ETHTOOL_GDRVINFO, ETHTOOL_GLINK and ETHTOOL_GPERMADDR), or
> (2) already exposed through rtnetlink or the net device in sysfs, or
> (3) statistics that should be exposed through ETHTOOL_GSTATS
>
> I imagine there are some that don't fall into those categories, but I
> don't see why they should *all* be exposed in a non-standard and/or
> redundant way.
Agreed.
^ permalink raw reply
* Re: [RFC] net/hsr: Add support for IEC 62439-3 High-availability Seamless Redundancy
From: David Miller @ 2012-04-05 22:31 UTC (permalink / raw)
To: bhutchings; +Cc: arvid.brodin, shemminger, netdev, balferreira, arvid.brodin
In-Reply-To: <1333653668.2652.13.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 5 Apr 2012 20:21:08 +0100
> On Wed, 2012-04-04 at 20:17 -0400, David Miller wrote:
>> From: Arvid Brodin <arvid.brodin@enea.com>
>> Date: Thu, 5 Apr 2012 01:09:48 +0200
>>
>> > - icmp_param.data.icmph = *icmp_hdr(skb);
>> > + memcpy(&icmp_param.data.icmph, icmp_hdr(skb),
>> > + sizeof(icmp_param.data.icmph));
>>
>> GCC can and will optimize this into an inline assignment, and thus
>> have the same unaligned access problems, because it determines
>> alignment based upon the types involved.
>
> So presumably icmp_hdr() should be changed to skb_transport_header().
I would not say so. Otherwise we introduce ugly casts everywhere.
^ permalink raw reply
* net: kernel BUG() in net/netns/generic.h:45
From: Sasha Levin @ 2012-04-05 22:20 UTC (permalink / raw)
To: davem, Eric Dumazet, Eric Van Hensbergen, ebiederm
Cc: Dave Jones, linux-kernel, netdev
Hi all,
When an initialization of a network namespace in setup_net() fails, we
try to undo everything by executing each of the exit callbacks of every
namespace in the network.
The problem is, it might be possible that the net_generic array wasn't
initialized before we fail and try to undo everything. At that point,
some of the networks assume that since we're already calling the exit
callback, the net_generic structure is initialized and we hit the BUG()
in net/netns/generic.h:45 .
I'm not quite sure whether the right fix from the following three
options is, and would be happy to figure it out before fixing it:
1. Don't assume net_generic was initialized in the exit callback, which
is a bit problematic since we can't query that nicely anyway (a
sub-option here would be adding an API to query whether the net_generic
structure is initialized.
2. Remove the BUG(), switch it to a WARN() and let each subsystem
handle the case of NULL on it's own. While it sounds a bit wrong, it's
worth mentioning that that BUG() was initially added in an attempt to
fix an issue in CAIF, which was fixed in a completely different way
afterwards, so it's not strictly necessary here.
3. Only call the exit callback for subsystems we have called the init
callback for.
Thanks!
--
Sasha.
^ permalink raw reply
* Re: [PATCH] m68k/atari: EtherNEC - rewrite to use mainstream ne.c, take two
From: Michael Schmitz @ 2012-04-05 22:10 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Paul Gortmaker, linux-m68k, netdev
In-Reply-To: <CAMuHMdWSzG4npwjpJ=cwNFKhyBZjvgPn1sp6nZ2re6QsRWPpXg@mail.gmail.com>
Geert,
>> How much lower? Enough to matter? Implicit in that question is
>> the assumption that this is largely a hobbyist platform and nobody
>> is using it in a closet to route gigabytes of traffic.
>>
>
> One other thing we could do is increase CONFIG_HZ to 250.
>
Making 3.x kernels run even more sluggish than they already do?
>> Also, the only advantage to modifying ne.c is to allow dumping
>> the old driver. What is the "remove soon" plan? Any reason
>> for it to not be synchronous? That would eliminate the Kconfig
>> churn and the introduction of the _OLD option. Modifying ne.c
>> and then deciding to keep the old driver because it is "faster"
>> would make this change pointless.
>>
>
> From my point of view, "remove soon" means it will never hit mainline.
>
That's what I meant to say - my patch is based on the m68k tree which
currently has another driver for this hardware, based on an older
version of ne.c which was never submitted to mainline. The old driver
would be removed from the m68k tree as soon as possible.
>> This seems more klunky than it needs to be. If we assume that anyone
>> building ne.c on atari is hence trying to drive an ethernec device
>> than it can just be
>>
>> #ifdef CONFIG_ATARI
>> #define EI_IRQ_FLAGS IRQF_SHARED
>> #else
>> #define EI_IRQ_FLAGS 0
>> #endif
>>
>
> Indeed, with a small modification (keep multi-platform kernels in mind):
>
> #ifdef CONFIG_ATARI
> #define EI_IRQ_FLAGS (MACH_IS_ATARI ? IRQF_SHARED : 0)
> #else
> #define EI_IRQ_FLAGS 0
> #endif
>
Right you are. Is any other m68k platform using ne.c directly, or do you
plan to convert all other NE2000 based drivers to ne.c now?
Cheers,
Michael
^ permalink raw reply
* Re: [3.4-rc1][Regression][network wireless] 'task xxxx blocked for more than 120 seconds' after resume
From: Francois Romieu @ 2012-04-05 21:01 UTC (permalink / raw)
To: Johannes Berg
Cc: maciej.rutecki, Stanislaw Gruszka, Linux Kernel Mailing List,
Rafael J. Wysocki, linux-wireless, netdev
In-Reply-To: <1333657409.3494.22.camel@jlt3.sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> :
> On Thu, 2012-04-05 at 22:08 +0200, Maciej Rutecki wrote:
>
> > Dmesg when CONFIG_LOCKDEP is set:
> >
> > http://mrutecki.pl/download/kernel/3.4-rc1/netdev_resume/dmesg-lockdep.txt
>
> Looks like rtl8169's fault:
Fix is on the way to mainline, see http://patchwork.ozlabs.org/patch/150541
--
Ueimor
Will code drivers for food.
^ permalink raw reply
* Re: [3.4-rc1][Regression][network wireless] 'task xxxx blocked for more than 120 seconds' after resume
From: Johannes Berg @ 2012-04-05 20:23 UTC (permalink / raw)
To: maciej.rutecki
Cc: Stanislaw Gruszka, Linux Kernel Mailing List, Rafael J. Wysocki,
linux-wireless, netdev, Francois Romieu
In-Reply-To: <201204052208.21270.maciej.rutecki@gmail.com>
On Thu, 2012-04-05 at 22:08 +0200, Maciej Rutecki wrote:
> Dmesg when CONFIG_LOCKDEP is set:
>
> http://mrutecki.pl/download/kernel/3.4-rc1/netdev_resume/dmesg-lockdep.txt
Looks like rtl8169's fault:
[ 240.541718] 2 locks held by ifconfig/4964:
[ 240.541722] #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff8138c86c>]
rtnl_lock+0x12/0x14
[ 240.541737] #1: (&tp->wk.mutex){+.+...}, at: [<ffffffffa00c1556>]
rtl_lock_work+0x12/0x14 [r8169]
[ 360.350345] INFO: task nmbd:2378 blocked for more than 120 seconds.
[ 360.353186] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 360.356124] nmbd D ffffffff81a76ab8 0 2378 1
0x00000000
[ 360.359078] ffff88022f573ab8 0000000000000046 ffff880233aa8040
ffff88022f573fd8
[ 360.362098] ffff88022f573fd8 0000000000013a40 ffff8802351b8040
ffff880233aa8040
[ 360.365170] ffffffff814532aa 000000001e3e7680 ffffffff81a76ab0
ffff880233aa8040
[ 360.368208] Call Trace:
[ 360.371129] [<ffffffff814532aa>] ? __mutex_lock_common+0x230/0x36e
[ 360.374159] [<ffffffff814543ca>] schedule+0x5f/0x61
[ 360.377195] [<ffffffff8145458e>] schedule_preempt_disabled+0x9/0xb
[ 360.380240] [<ffffffff814532b7>] __mutex_lock_common+0x23d/0x36e
[ 360.383262] [<ffffffff8138c86c>] ? rtnl_lock+0x12/0x14
[ 360.386260] [<ffffffff8139fe60>] ? netlink_lookup+0x2b/0x7e
[ 360.389279] [<ffffffff8138c86c>] ? rtnl_lock+0x12/0x14
[ 360.392352] [<ffffffff814534a7>] mutex_lock_nested+0x2a/0x31
[ 360.395393] [<ffffffff8138c86c>] rtnl_lock+0x12/0x14
[ 360.398376] [<ffffffff8138c87f>] rtnetlink_rcv+0x11/0x28
[ 360.401292] [<ffffffff813a1d9a>] netlink_unicast+0xe7/0x151
[ 360.404192] [<ffffffff813a2002>] netlink_sendmsg+0x1fe/0x236
[ 360.407089] [<ffffffff8136cd79>] sock_sendmsg+0xea/0x10d
[ 360.409971] [<ffffffff81080679>] ? lock_acquire+0xef/0xfe
[ 360.412825] [<ffffffff810e6bf8>] ? might_fault+0x40/0x90
[ 360.415640] [<ffffffff81080679>] ? lock_acquire+0xef/0xfe
[ 360.418447] [<ffffffff810e6bf8>] ? might_fault+0x40/0x90
[ 360.421239] [<ffffffff8108057e>] ? lock_release+0x175/0x181
[ 360.424039] [<ffffffff810e6c41>] ? might_fault+0x89/0x90
[ 360.426896] [<ffffffff8136b5ec>] ? copy_from_user+0x2a/0x2c
[ 360.429661] [<ffffffff8136e9e5>] sys_sendto+0x12a/0x16c
[ 360.432430] [<ffffffff8107d74f>] ? trace_hardirqs_off_caller
+0x33/0x90
[ 360.435219] [<ffffffff81455515>] ? retint_swapgs+0x13/0x1b
[ 360.437978] [<ffffffff81080a85>] ? trace_hardirqs_on_caller
+0x121/0x158
[ 360.440795] [<ffffffff8121250e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 360.443868] [<ffffffff8145acb9>] system_call_fastpath+0x16/0x1b
johannes
^ permalink raw reply
* Re: [PATCH 1/1] bonding: properly unset current_arp_slave on slave link up
From: Marcelo Leitner @ 2012-04-05 20:22 UTC (permalink / raw)
To: Veaceslav Falico; +Cc: netdev, Jay Vosburgh, Andy Gospodarek, linux-kernel
In-Reply-To: <20120405134743.GB16870@darkmag.usersys.redhat.com>
On 04/05/2012 10:47 AM, Veaceslav Falico wrote:
> When a slave comes up, we're unsetting the current_arp_slave without
> removing active flags from it, which can lead to situations where we have
> more than one slave with active flags in active-backup mode.
>
> To avoid this situation we must remove the active flags from a slave before
> removing it as a current_arp_slave.
>
> Signed-off-by: Veaceslav Falico<vfalico@redhat.com>
Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
^ permalink raw reply
* Re: [3.4-rc1][Regression][network wireless] 'task xxxx blocked for more than 120 seconds' after resume
From: Maciej Rutecki @ 2012-04-05 20:08 UTC (permalink / raw)
To: Johannes Berg
Cc: Stanislaw Gruszka, Linux Kernel Mailing List, Rafael J. Wysocki,
linux-wireless, netdev
In-Reply-To: <1333652183.3494.21.camel@jlt3.sipsolutions.net>
On czwartek, 5 kwietnia 2012 o 20:56:23 Johannes Berg wrote:
> On Thu, 2012-04-05 at 20:37 +0200, Maciej Rutecki wrote:
> > On czwartek, 5 kwietnia 2012 o 12:32:54 Stanislaw Gruszka wrote:
> > > On Tue, Apr 03, 2012 at 10:07:49AM +0200, Johannes Berg wrote:
> > > > -ilw
> > > > +netdev
> > > >
> > > > I have no idea what this could be, but I'm almost certain it's not
> > > > caused by our wireless driver. Looks more like rtl8169 is to blame.
> > >
> > > I'm not sure. Looks like there is deadlock or infinite loop in process
> > > that holds rtnl lock. This can be wireless driver, wired driver or
> > > generic network code bug.
> > >
> > > Maciej, please recompile with CONFIG_LOCKDEP and check if it will not
> > > find any deadlock. If not, when problem will happen please do
> >
> > Did you mean "CONFIG_LOCKDEP_SUPPORT"?
>
> No, _SUPPORT means you could enable CONFIG_LOCKDEP, but we would like to
> see this with CONFIG_LOCKDEP enabled.
>
> johannes
Dmesg when CONFIG_LOCKDEP is set:
http://mrutecki.pl/download/kernel/3.4-rc1/netdev_resume/dmesg-lockdep.txt
Regards
--
Maciej Rutecki
http://www.mrutecki.pl
^ permalink raw reply
* Re: [PATCH net-next] tcp: Fix bug when gap in rcv sequence is filled
From: chetan loke @ 2012-04-05 19:21 UTC (permalink / raw)
To: Vijay Subramanian; +Cc: netdev, davem, ncardwell, ilpo.jarvinen
In-Reply-To: <1333651563-3279-1-git-send-email-subramanian.vijay@gmail.com>
On Thu, Apr 5, 2012 at 2:46 PM, Vijay Subramanian
<subramanian.vijay@gmail.com> wrote:
> +static int tcp_ofo_queue(struct sock *sk)
> {
> struct tcp_sock *tp = tcp_sk(sk);
> __u32 dsack_high = tp->rcv_nxt;
> struct sk_buff *skb;
> + bool requeued = false; /*true if an skb is requeued to receive_queue*/
why introduce a bool then ? Change it to int(init to 0) and then
'return requeued' ?
Chetan
^ permalink raw reply
* Re: [RFC] net/hsr: Add support for IEC 62439-3 High-availability Seamless Redundancy
From: Ben Hutchings @ 2012-04-05 19:21 UTC (permalink / raw)
To: David Miller; +Cc: arvid.brodin, shemminger, netdev, balferreira, arvid.brodin
In-Reply-To: <20120404.201739.672373176675875061.davem@davemloft.net>
On Wed, 2012-04-04 at 20:17 -0400, David Miller wrote:
> From: Arvid Brodin <arvid.brodin@enea.com>
> Date: Thu, 5 Apr 2012 01:09:48 +0200
>
> > - icmp_param.data.icmph = *icmp_hdr(skb);
> > + memcpy(&icmp_param.data.icmph, icmp_hdr(skb),
> > + sizeof(icmp_param.data.icmph));
>
> GCC can and will optimize this into an inline assignment, and thus
> have the same unaligned access problems, because it determines
> alignment based upon the types involved.
So presumably icmp_hdr() should be changed to skb_transport_header().
Ben.
--
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 v2] phonet: Check input from user before allocating
From: Rémi Denis-Courmont @ 2012-04-05 19:14 UTC (permalink / raw)
To: Sasha Levin; +Cc: remi.denis-courmont, davem, davej, netdev, linux-kernel
In-Reply-To: <1333663665-3999-1-git-send-email-levinsasha928@gmail.com>
Le vendredi 6 avril 2012 01:07:45 Sasha Levin, vous avez écrit :
> A phonet packet is limited to USHRT_MAX bytes, this is never checked during
> tx which means that the user can specify any size he wishes, and the kernel
> will attempt to allocate that size.
>
> In the good case, it'll lead to the following warning, but it may also
> cause the kernel to kick in the OOM and kill a random task on the server.
>
> [ 8921.744094] WARNING: at mm/page_alloc.c:2255
> __alloc_pages_slowpath+0x65/0x730() [ 8921.749770] Pid: 5081, comm:
> trinity Tainted: G W 3.4.0-rc1-next-20120402-sasha #46 [
> 8921.756672] Call Trace:
> [ 8921.758185] [<ffffffff810b2ba7>] warn_slowpath_common+0x87/0xb0
> [ 8921.762868] [<ffffffff810b2be5>] warn_slowpath_null+0x15/0x20
> [ 8921.765399] [<ffffffff8117eae5>] __alloc_pages_slowpath+0x65/0x730
> [ 8921.769226] [<ffffffff81179c8a>] ? zone_watermark_ok+0x1a/0x20
> [ 8921.771686] [<ffffffff8117d045>] ? get_page_from_freelist+0x625/0x660
> [ 8921.773919] [<ffffffff8117f3a8>] __alloc_pages_nodemask+0x1f8/0x240
> [ 8921.776248] [<ffffffff811c03e0>] kmalloc_large_node+0x70/0xc0
> [ 8921.778294] [<ffffffff811c4bd4>] __kmalloc_node_track_caller+0x34/0x1c0
> [ 8921.780847] [<ffffffff821b0e3c>] ? sock_alloc_send_pskb+0xbc/0x260
> [ 8921.783179] [<ffffffff821b3c65>] __alloc_skb+0x75/0x170
> [ 8921.784971] [<ffffffff821b0e3c>] sock_alloc_send_pskb+0xbc/0x260
> [ 8921.787111] [<ffffffff821b002e>] ? release_sock+0x7e/0x90
> [ 8921.788973] [<ffffffff821b0ff0>] sock_alloc_send_skb+0x10/0x20
> [ 8921.791052] [<ffffffff824cfc20>] pep_sendmsg+0x60/0x380
> [ 8921.792931] [<ffffffff824cb4a6>] ? pn_socket_bind+0x156/0x180
> [ 8921.794917] [<ffffffff824cb50f>] ? pn_socket_autobind+0x3f/0x90
> [ 8921.797053] [<ffffffff824cb63f>] pn_socket_sendmsg+0x4f/0x70
> [ 8921.798992] [<ffffffff821ab8e7>] sock_aio_write+0x187/0x1b0
> [ 8921.801395] [<ffffffff810e325e>] ? sub_preempt_count+0xae/0xf0
> [ 8921.803501] [<ffffffff8111842c>] ? __lock_acquire+0x42c/0x4b0
> [ 8921.805505] [<ffffffff821ab760>] ? __sock_recv_ts_and_drops+0x140/0x140
> [ 8921.807860] [<ffffffff811e07cc>] do_sync_readv_writev+0xbc/0x110
> [ 8921.809986] [<ffffffff811958e7>] ? might_fault+0x97/0xa0
> [ 8921.811998] [<ffffffff817bd99e>] ? security_file_permission+0x1e/0x90
> [ 8921.814595] [<ffffffff811e17e2>] do_readv_writev+0xe2/0x1e0
> [ 8921.816702] [<ffffffff810b8dac>] ? do_setitimer+0x1ac/0x200
> [ 8921.818819] [<ffffffff810e2ec1>] ? get_parent_ip+0x11/0x50
> [ 8921.820863] [<ffffffff810e325e>] ? sub_preempt_count+0xae/0xf0
> [ 8921.823318] [<ffffffff811e1926>] vfs_writev+0x46/0x60
> [ 8921.825219] [<ffffffff811e1a3f>] sys_writev+0x4f/0xb0
> [ 8921.827127] [<ffffffff82658039>] system_call_fastpath+0x16/0x1b
> [ 8921.829384] ---[ end trace dffe390f30db9eb7 ]---
>
> Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Acked-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
> ---
> net/phonet/pep.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/net/phonet/pep.c b/net/phonet/pep.c
> index 9f60008..caee99e 100644
> --- a/net/phonet/pep.c
> +++ b/net/phonet/pep.c
> @@ -1130,6 +1130,9 @@ static int pep_sendmsg(struct kiocb *iocb, struct
> sock *sk, int flags = msg->msg_flags;
> int err, done;
>
> + if (len > USHRT_MAX)
> + return -EMSGSIZE;
> +
> if ((msg->msg_flags & ~(MSG_DONTWAIT|MSG_EOR|MSG_NOSIGNAL|
> MSG_CMSG_COMPAT)) ||
> !(msg->msg_flags & MSG_EOR))
--
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis
^ permalink raw reply
* [PATCH v2] phonet: Check input from user before allocating
From: Sasha Levin @ 2012-04-05 22:07 UTC (permalink / raw)
To: remi.denis-courmont, davem; +Cc: davej, netdev, linux-kernel, Sasha Levin
A phonet packet is limited to USHRT_MAX bytes, this is never checked during
tx which means that the user can specify any size he wishes, and the kernel
will attempt to allocate that size.
In the good case, it'll lead to the following warning, but it may also cause
the kernel to kick in the OOM and kill a random task on the server.
[ 8921.744094] WARNING: at mm/page_alloc.c:2255 __alloc_pages_slowpath+0x65/0x730()
[ 8921.749770] Pid: 5081, comm: trinity Tainted: G W 3.4.0-rc1-next-20120402-sasha #46
[ 8921.756672] Call Trace:
[ 8921.758185] [<ffffffff810b2ba7>] warn_slowpath_common+0x87/0xb0
[ 8921.762868] [<ffffffff810b2be5>] warn_slowpath_null+0x15/0x20
[ 8921.765399] [<ffffffff8117eae5>] __alloc_pages_slowpath+0x65/0x730
[ 8921.769226] [<ffffffff81179c8a>] ? zone_watermark_ok+0x1a/0x20
[ 8921.771686] [<ffffffff8117d045>] ? get_page_from_freelist+0x625/0x660
[ 8921.773919] [<ffffffff8117f3a8>] __alloc_pages_nodemask+0x1f8/0x240
[ 8921.776248] [<ffffffff811c03e0>] kmalloc_large_node+0x70/0xc0
[ 8921.778294] [<ffffffff811c4bd4>] __kmalloc_node_track_caller+0x34/0x1c0
[ 8921.780847] [<ffffffff821b0e3c>] ? sock_alloc_send_pskb+0xbc/0x260
[ 8921.783179] [<ffffffff821b3c65>] __alloc_skb+0x75/0x170
[ 8921.784971] [<ffffffff821b0e3c>] sock_alloc_send_pskb+0xbc/0x260
[ 8921.787111] [<ffffffff821b002e>] ? release_sock+0x7e/0x90
[ 8921.788973] [<ffffffff821b0ff0>] sock_alloc_send_skb+0x10/0x20
[ 8921.791052] [<ffffffff824cfc20>] pep_sendmsg+0x60/0x380
[ 8921.792931] [<ffffffff824cb4a6>] ? pn_socket_bind+0x156/0x180
[ 8921.794917] [<ffffffff824cb50f>] ? pn_socket_autobind+0x3f/0x90
[ 8921.797053] [<ffffffff824cb63f>] pn_socket_sendmsg+0x4f/0x70
[ 8921.798992] [<ffffffff821ab8e7>] sock_aio_write+0x187/0x1b0
[ 8921.801395] [<ffffffff810e325e>] ? sub_preempt_count+0xae/0xf0
[ 8921.803501] [<ffffffff8111842c>] ? __lock_acquire+0x42c/0x4b0
[ 8921.805505] [<ffffffff821ab760>] ? __sock_recv_ts_and_drops+0x140/0x140
[ 8921.807860] [<ffffffff811e07cc>] do_sync_readv_writev+0xbc/0x110
[ 8921.809986] [<ffffffff811958e7>] ? might_fault+0x97/0xa0
[ 8921.811998] [<ffffffff817bd99e>] ? security_file_permission+0x1e/0x90
[ 8921.814595] [<ffffffff811e17e2>] do_readv_writev+0xe2/0x1e0
[ 8921.816702] [<ffffffff810b8dac>] ? do_setitimer+0x1ac/0x200
[ 8921.818819] [<ffffffff810e2ec1>] ? get_parent_ip+0x11/0x50
[ 8921.820863] [<ffffffff810e325e>] ? sub_preempt_count+0xae/0xf0
[ 8921.823318] [<ffffffff811e1926>] vfs_writev+0x46/0x60
[ 8921.825219] [<ffffffff811e1a3f>] sys_writev+0x4f/0xb0
[ 8921.827127] [<ffffffff82658039>] system_call_fastpath+0x16/0x1b
[ 8921.829384] ---[ end trace dffe390f30db9eb7 ]---
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
---
net/phonet/pep.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/net/phonet/pep.c b/net/phonet/pep.c
index 9f60008..caee99e 100644
--- a/net/phonet/pep.c
+++ b/net/phonet/pep.c
@@ -1130,6 +1130,9 @@ static int pep_sendmsg(struct kiocb *iocb, struct sock *sk,
int flags = msg->msg_flags;
int err, done;
+ if (len > USHRT_MAX)
+ return -EMSGSIZE;
+
if ((msg->msg_flags & ~(MSG_DONTWAIT|MSG_EOR|MSG_NOSIGNAL|
MSG_CMSG_COMPAT)) ||
!(msg->msg_flags & MSG_EOR))
--
1.7.8.5
^ permalink raw reply related
* Re: [3.4-rc1][Regression][network wireless] 'task xxxx blocked for more than 120 seconds' after resume
From: Johannes Berg @ 2012-04-05 18:56 UTC (permalink / raw)
To: maciej.rutecki-Re5JQEeQqe8AvxtiuMwx3w
Cc: Stanislaw Gruszka, Linux Kernel Mailing List, Rafael J. Wysocki,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, netdev
In-Reply-To: <201204052037.37497.maciej.rutecki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, 2012-04-05 at 20:37 +0200, Maciej Rutecki wrote:
> On czwartek, 5 kwietnia 2012 o 12:32:54 Stanislaw Gruszka wrote:
> > On Tue, Apr 03, 2012 at 10:07:49AM +0200, Johannes Berg wrote:
> > > -ilw
> > > +netdev
> > >
> > > I have no idea what this could be, but I'm almost certain it's not
> > > caused by our wireless driver. Looks more like rtl8169 is to blame.
> >
> > I'm not sure. Looks like there is deadlock or infinite loop in process
> > that holds rtnl lock. This can be wireless driver, wired driver or
> > generic network code bug.
> >
> > Maciej, please recompile with CONFIG_LOCKDEP and check if it will not
> > find any deadlock. If not, when problem will happen please do
>
> Did you mean "CONFIG_LOCKDEP_SUPPORT"?
No, _SUPPORT means you could enable CONFIG_LOCKDEP, but we would like to
see this with CONFIG_LOCKDEP enabled.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH net-next] tcp: Fix bug when gap in rcv sequence is filled
From: Vijay Subramanian @ 2012-04-05 18:46 UTC (permalink / raw)
To: netdev; +Cc: davem, ncardwell, ilpo.jarvinen, Vijay Subramanian
As per RFC2581 and the newer RFC5681, "the receiver SHOULD send an immediate ACK
when it receives a data segment that fills in all or part of a gap in the
sequence space." When TCP receiver gets the next in-sequence packet, we move
data from ofo queue to receive queue. At this point, we should send an immediate
ack by entering quickack mode. In the current code, instead of entering
quickack mode upon requeing packets from ofo queue to receive_queue, we enter
quickack mode only when ofo queue becomes empty after requeuing. This ignores
the possibility that there may be further packets left in ofo queue. This patch
fixes this behavior and enters quickack mode whenever packets are moved from ofo
queue to receive queue.
Also, comment has been updated to reflect that RFC5681 obsoletes RFC2581.
Signed-off-by: Vijay Subramanian <subramanian.vijay@gmail.com>
---
net/ipv4/tcp_input.c | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index e886e2f..ebed78d 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4388,12 +4388,14 @@ static void tcp_sack_remove(struct tcp_sock *tp)
/* This one checks to see if we can put data from the
* out_of_order queue into the receive_queue.
+ * Return 1 if data is moved from ofo queue to receive_queue and 0 otherwise.
*/
-static void tcp_ofo_queue(struct sock *sk)
+static int tcp_ofo_queue(struct sock *sk)
{
struct tcp_sock *tp = tcp_sk(sk);
__u32 dsack_high = tp->rcv_nxt;
struct sk_buff *skb;
+ bool requeued = false; /*true if an skb is requeued to receive_queue*/
while ((skb = skb_peek(&tp->out_of_order_queue)) != NULL) {
if (after(TCP_SKB_CB(skb)->seq, tp->rcv_nxt))
@@ -4418,10 +4420,12 @@ static void tcp_ofo_queue(struct sock *sk)
__skb_unlink(skb, &tp->out_of_order_queue);
__skb_queue_tail(&sk->sk_receive_queue, skb);
+ requeued = true;
tp->rcv_nxt = TCP_SKB_CB(skb)->end_seq;
if (tcp_hdr(skb)->fin)
tcp_fin(sk);
}
+ return requeued ? 1 : 0 ;
}
static int tcp_prune_ofo_queue(struct sock *sk);
@@ -4636,12 +4640,11 @@ queue_and_out:
tcp_fin(sk);
if (!skb_queue_empty(&tp->out_of_order_queue)) {
- tcp_ofo_queue(sk);
- /* RFC2581. 4.2. SHOULD send immediate ACK, when
- * gap in queue is filled.
+ /* RFC5681 (which obsoletes RFC2581.) 4.2. SHOULD send
+ * immediate ACK, when gap in queue is filled.
*/
- if (skb_queue_empty(&tp->out_of_order_queue))
+ if (tcp_ofo_queue(sk))
inet_csk(sk)->icsk_ack.pingpong = 0;
}
--
1.7.0.4
^ permalink raw reply related
* Re: [3.4-rc1][Regression][network wireless] 'task xxxx blocked for more than 120 seconds' after resume
From: Maciej Rutecki @ 2012-04-05 18:37 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Johannes Berg, Linux Kernel Mailing List, Rafael J. Wysocki,
linux-wireless, netdev
In-Reply-To: <20120405103254.GE2378@redhat.com>
On czwartek, 5 kwietnia 2012 o 12:32:54 Stanislaw Gruszka wrote:
> On Tue, Apr 03, 2012 at 10:07:49AM +0200, Johannes Berg wrote:
> > -ilw
> > +netdev
> >
> > I have no idea what this could be, but I'm almost certain it's not
> > caused by our wireless driver. Looks more like rtl8169 is to blame.
>
> I'm not sure. Looks like there is deadlock or infinite loop in process
> that holds rtnl lock. This can be wireless driver, wired driver or
> generic network code bug.
>
> Maciej, please recompile with CONFIG_LOCKDEP and check if it will not
> find any deadlock. If not, when problem will happen please do
Did you mean "CONFIG_LOCKDEP_SUPPORT"?
$ cat /boot/config-3.4.0-rc1 | grep CONFIG_LOCKDEP
CONFIG_LOCKDEP_SUPPORT=y
>
> echo w > /proc/sysrq-trigger
> dmesg -c > dmesg1.txt
http://mrutecki.pl/download/kernel/3.4-rc1/netdev_resume/dmesg1.txt
> echo t > /proc/sysrq-trigger
> dmesg > dmesg2.txt
http://mrutecki.pl/download/kernel/3.4-rc1/netdev_resume/dmesg2.txt
>
> and provide those files.
>
> Additionally there are also lot in dmesg:
>
> netlink: 140 bytes leftover after parsing attributes.
>
> This need to be investigated as well. Perhaps you could modify error
> message, to show what netlink messages/attributes are processed.
>
> Thanks
> Stanislaw
BTW. From tomorrow till Tuesday I'll be on vacation, so until then I could
respond to the e-mails.
Regards
--
Maciej Rutecki
http://www.mrutecki.pl
^ permalink raw reply
* Re: [PATCH 1/1] bonding: properly unset current_arp_slave on slave link up
From: Andy Gospodarek @ 2012-04-05 18:06 UTC (permalink / raw)
To: Veaceslav Falico; +Cc: netdev, Jay Vosburgh, Andy Gospodarek, linux-kernel
In-Reply-To: <20120405134743.GB16870@darkmag.usersys.redhat.com>
On Thu, Apr 05, 2012 at 03:47:43PM +0200, Veaceslav Falico wrote:
> When a slave comes up, we're unsetting the current_arp_slave without
> removing active flags from it, which can lead to situations where we have
> more than one slave with active flags in active-backup mode.
>
> To avoid this situation we must remove the active flags from a slave before
> removing it as a current_arp_slave.
>
> Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
>
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
^ permalink raw reply
* [PATCH] SUNRPC: register PipeFS file system after pernet sybsystem
From: Stanislav Kinsbursky @ 2012-04-05 17:04 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, jbottomley,
bfields, davej, davem, devel
PipeFS superblock creation routine relays on SUNRPC pernet data presense, which
is created on register_pernet_subsys() call in SUNRPC module init function.
Registering of PipeFS filesystem prior to registering of per-net subsystem
leads to races (mount of PipeFS can dereference uninitialized data).
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
net/sunrpc/sunrpc_syms.c | 17 +++++++++--------
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/net/sunrpc/sunrpc_syms.c b/net/sunrpc/sunrpc_syms.c
index 8adfc88..3d6498a 100644
--- a/net/sunrpc/sunrpc_syms.c
+++ b/net/sunrpc/sunrpc_syms.c
@@ -75,20 +75,21 @@ static struct pernet_operations sunrpc_net_ops = {
static int __init
init_sunrpc(void)
{
- int err = register_rpc_pipefs();
+ int err = rpc_init_mempool();
if (err)
goto out;
- err = rpc_init_mempool();
- if (err)
- goto out2;
err = rpcauth_init_module();
if (err)
- goto out3;
+ goto out2;
cache_initialize();
err = register_pernet_subsys(&sunrpc_net_ops);
if (err)
+ goto out3;
+
+ err = register_rpc_pipefs();
+ if (err)
goto out4;
#ifdef RPC_DEBUG
rpc_register_sysctl();
@@ -98,11 +99,11 @@ init_sunrpc(void)
return 0;
out4:
- rpcauth_remove_module();
+ unregister_pernet_subsys(&sunrpc_net_ops);
out3:
- rpc_destroy_mempool();
+ rpcauth_remove_module();
out2:
- unregister_rpc_pipefs();
+ rpc_destroy_mempool();
out:
return err;
}
^ permalink raw reply related
* Re: [RFC PATCH 0/1] NUMA aware scheduling per cpu vhost thread patch
From: Shirley Ma @ 2012-04-05 16:48 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Jason Wang, netdev, kvm, tahm, vivek
In-Reply-To: <1333639327.6061.20.camel@oc3660625478.ibm.com>
On Thu, 2012-04-05 at 08:22 -0700, Shirley Ma wrote:
> Haven't had time to focus on single stream result yet.
I forgot to mention that if I switch the vhost scheduling to per-device
based from per vq based, this minor single stream test regression will
be gone. However the improvement of tcp_rrs, udp_rrs and other stream
case performance will also gone.
Shirley
^ permalink raw reply
* Re: [PATCH 1/1] bonding: properly unset current_arp_slave on slave link up
From: Jay Vosburgh @ 2012-04-05 16:43 UTC (permalink / raw)
To: Veaceslav Falico; +Cc: netdev, Andy Gospodarek, linux-kernel
In-Reply-To: <20120405134743.GB16870@darkmag.usersys.redhat.com>
Veaceslav Falico <vfalico@redhat.com> wrote:
>When a slave comes up, we're unsetting the current_arp_slave without
>removing active flags from it, which can lead to situations where we have
>more than one slave with active flags in active-backup mode.
>
>To avoid this situation we must remove the active flags from a slave before
>removing it as a current_arp_slave.
>
>Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
>---
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index 0c76186..ad731a1 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -3001,7 +3001,11 @@ static void bond_ab_arp_commit(struct bonding *bond, int delta_in_ticks)
> trans_start + delta_in_ticks)) ||
> bond->curr_active_slave != slave) {
> slave->link = BOND_LINK_UP;
>- bond->current_arp_slave = NULL;
>+ if (bond->current_arp_slave) {
>+ bond_set_slave_inactive_flags(
>+ bond->current_arp_slave);
>+ bond->current_arp_slave = NULL;
>+ }
>
> pr_info("%s: link status definitely up for interface %s.\n",
> bond->dev->name, slave->dev->name);
>
^ permalink raw reply
* Cloud Hosting and Server
From: woody @ 2012-04-05 16:27 UTC (permalink / raw)
Dear All,
We are one of the top Cloud Solution provider base in Hong Kong, with over 10+ years experience,
we providing better than good and lower cost service of CLoud Hosting (Cloud Server / Hosting / CDN)
Starting at $1.99, let's come to experience and enjoy our powerful cloud system.
Thanks for your time and appreciated to look arround our website.
http://www.dedicatedserver.com.hk/
Best Regards,
The 36cloud Team
If you do not wish to further receive this event message, email "subscriber@dedicatedserver.com.hk" to unsubscribe this message or revoe your email from the list.
^ permalink raw reply
* Re: [net-next 3/3] ixgbe: add syfs interface for to export read only driver information
From: Ben Hutchings @ 2012-04-05 16:32 UTC (permalink / raw)
To: Florian Fainelli
Cc: Jeff Kirsher, davem, Don Skidmore, netdev, gospo, sassmann
In-Reply-To: <4F7D8DD4.5080205@openwrt.org>
On Thu, 2012-04-05 at 14:19 +0200, Florian Fainelli wrote:
> Hi,
>
> Le 04/05/12 12:47, Jeff Kirsher a écrit :
> > From: Don Skidmore<donald.c.skidmore@intel.com>
> >
> > This patch exports non-thermal (which was done via hwmon in an earlier
> > patch) data to syfs. All of the fields are read only as this interface
> > is to only export driver data.
> >
> > Signed-off-by: Don Skidmore<donald.c.skidmore@intel.com>
> > Tested-by: Stephen Ko<stephen.s.ko@intel.com>
> > Signed-off-by: Jeff Kirsher<jeffrey.t.kirsher@intel.com>
> > ---
>
> I only looked briefly at the exported attributes, but most of them can
> already be queried using ethtool, can't they?
[...]
I agree, it looks like most of these are:
(1) already exposed through ethtool commands (ETHTOOL_GSET,
ETHTOOL_GDRVINFO, ETHTOOL_GLINK and ETHTOOL_GPERMADDR), or
(2) already exposed through rtnetlink or the net device in sysfs, or
(3) statistics that should be exposed through ETHTOOL_GSTATS
I imagine there are some that don't fall into those categories, but I
don't see why they should *all* be exposed in a non-standard and/or
redundant way.
Ben.
--
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: [RFC PATCH 2/2] PID-based packet filtering support
From: chetan loke @ 2012-04-05 16:29 UTC (permalink / raw)
To: Nuno Martins; +Cc: netdev, Alfredo Matos, Paulo Trezentos
In-Reply-To: <CALKxAXVK9EhJiNOuq0JYqWiw75q3TYCScp+bGf-qqF_irKYtbA@mail.gmail.com>
On Thu, Apr 5, 2012 at 5:41 AM, Nuno Martins
<nuno.martins@caixamagica.pt> wrote:
> Our tests with 1024 node tree gives us something like 1.3 us on
> average. Your suggestion makes a lot of sense, and we will definitely
> look into.
> This doesn't seem hard to do as we are considering introducing a pid
> based hash table, with a tree in each entry, which can and possibly
> should be pre-allocated.
Also as a defensive mechanism(and if not present already) it may not
be a bad idea to add the following check whenever you are adding or
deleting a node:
if (pidmonitor->curr_num_monitored_pid_nodes >
pidmax_or_whichever_runtime_max_scheduler_uses) {
WARN_ONCE(....);
delete_all_nodes_from_the_tree(); // including the current one -
if you were in the middle of a new insert.
// This way at least your monitoring tool might pick this up and
the user/sysadmin might dig into it.
}
Note: pidmonitor is some global struct and
curr_num_monitored_pid_nodes == number of pids you are currently
monitoring.
By adding this minimal code, if there are any stray nodes in the
tree(over a period of time) because of a bug in the clean up logic
then we might be able to detect it.
> Nuno Martins
Chetan
^ permalink raw reply
* Re: kernel BUG at include/net/netns/generic.h:41
From: Stanislav Kinsbursky @ 2012-04-05 16:14 UTC (permalink / raw)
To: Dave Jones, Myklebust, Trond, Linux Kernel,
netdev@vger.kernel.org
In-Reply-To: <20120405161241.GA23658@redhat.com>
05.04.2012 20:12, Dave Jones пишет:
> On Thu, Apr 05, 2012 at 08:08:31PM +0400, Stanislav Kinsbursky wrote:
>
> > So, there are few questions to you, Dave:
> > 1) can this happen (PipeFS mount attempt before SUNPRC module insertion has
> > returned any value) in your case?
>
> I don't know enough of what systemd is doing to answer this.
>
> > 2) how often do you experience this problem? Not every boot, I suppose?
> > 3) And is it easy for you to reproduce?
>
> It happens most the time, but not every time.
>
Ok, I'll send the patch soon.
Hope, it will help.
--
Best regards,
Stanislav Kinsbursky
^ 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