* Re: Linux 3.0 release
From: Ben Greear @ 2011-07-22 19:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David, Linux Kernel Mailing List, netdev
In-Reply-To: <CA+55aFy1FnVGH4C_0T8fXwZPUdz5-SCczMwy1K8kydLwTx89RQ@mail.gmail.com>
On 07/22/2011 12:21 PM, Linus Torvalds wrote:
> On Fri, Jul 22, 2011 at 12:11 PM, David<david@unsolicited.net> wrote:
>>
>> I'm getting the following warning at boot from 3.0, everything seems to be fine otherwise though.
>>
>> Jul 22 19:40:02 server kernel: [ 15.526629] ------------[ cut here ]------------
>> Jul 22 19:40:02 server kernel: [ 15.526635] WARNING: at kernel/timer.c:1011 del_timer_sync+0x4e/0x50()
>
> Hmm. That looks like a real bug: you shouldn't do a "del_timer_sync()"
> from an interrupt. It probably works, but it sounds like a really bad
> idea.
>
>> Jul 22 19:40:02 server kernel: [ 15.526677] [<ffffffff81054b4e>] del_timer_sync+0x4e/0x50
>> Jul 22 19:40:02 server kernel: [ 15.526679] [<ffffffff8145e224>] linkwatch_schedule_work+0x84/0xa0
>> Jul 22 19:40:02 server kernel: [ 15.526681] [<ffffffff8145e2bc>] linkwatch_fire_event+0x7c/0x100
>> Jul 22 19:40:02 server kernel: [ 15.526684] [<ffffffff8146b1ed>] netif_carrier_on+0x2d/0x40
>> Jul 22 19:40:02 server kernel: [ 15.526689] [<ffffffffa006b6fb>] __rtl8169_check_link_status+0x4b/0xc0 [r8169]
>> Jul 22 19:40:02 server kernel: [ 15.526693] [<ffffffffa006c016>] rtl8169_interrupt+0x166/0x3a0 [r8169]
>> Jul 22 19:40:02 server kernel: [ 15.526696] [<ffffffff810a4385>] handle_irq_event_percpu+0x55/0x1f0
>> Jul 22 19:40:02 server kernel: [ 15.526698] [<ffffffff810a4551>] handle_irq_event+0x31/0x50
>
> I'm not seeing a lot of changes in any of these areas, though. I
> wonder what made it start happen.
This has been around since at least 2.6.38. I haven't tested recently
on my rtl8169 system, but I don't recall seeing any attempts to fix
it...
http://permalink.gmane.org/gmane.linux.network/193565
http://lists.openwall.net/netdev/2011/05/04/183
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 10/13] net: add paged frag destructor to skb_fill_page_desc()
From: Michał Mirosław @ 2011-07-22 19:58 UTC (permalink / raw)
To: Ian Campbell
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
David S. Miller, James E.J. Bottomley, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
Patrick McHardy, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-s390-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA, devel-s9riP+hp16TNLxjTenLetw
In-Reply-To: <1311340653-19336-10-git-send-email-ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
2011/7/22 Ian Campbell <ian.campbell@citrix.com>:
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 9818fe2..faee8d3 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -1134,12 +1134,14 @@ static inline int skb_pagelen(const struct sk_buff *skb)
> * Does not take any additional reference on the fragment.
> */
> static inline void __skb_fill_page_desc(struct sk_buff *skb, int i,
> - struct page *page, int off, int size)
> + struct page *page,
> + struct skb_frag_destructor *destroy,
> + int off, int size)
> {
> skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
>
> frag->page.p = page;
> - frag->page.destructor = NULL;
> + frag->page.destructor = destroy;
> frag->page_offset = off;
> frag->size = size;
> }
You could just rename this function to e.g.
__skb_fill_fragile_page_desc() (or whatever name) add an inline
wrapper calling it with destroy == NULL. This will avoid touching all
those drivers which won't ever need this functionality.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: Linux 3.0 release
From: Stephen Hemminger @ 2011-07-22 20:32 UTC (permalink / raw)
To: Ben Greear, Linus Torvalds, David, Tejun Heo
Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <4E29D326.7070403@candelatech.com>
This a regression which probably began with
commit e22bee782b3b00bd4534ae9b1c5fb2e8e6573c5c
Author: Tejun Heo <tj@kernel.org>
Date: Tue Jun 29 10:07:14 2010 +0200
workqueue: implement concurrency managed dynamic worker pool
Before that it was perfectly legal for link watch code to
call schedule_delayed_work from IRQ. This should be allowable;
the code to manage the worker pool should handle it.
Network devices call netif_carrier_on/off from IRQ all the
time. The problem is that the new pool code breaks this
if link watch tries to schedule work before there enough worker
threads.
The workqueue code should have a fallback and not try and
do anything if being called from IRQ.
^ permalink raw reply
* Re: Linux 3.0 release
From: Linus Torvalds @ 2011-07-22 20:35 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Ben Greear, David, Tejun Heo, Linux Kernel Mailing List, netdev
In-Reply-To: <20110722133220.0baf2199@nehalam.ftrdhcpuser.net>
On Fri, Jul 22, 2011 at 1:32 PM, Stephen Hemminger
<shemminger@vyatta.com> wrote:
>
> The workqueue code should have a fallback and not try and
> do anything if being called from IRQ.
Fair enough. Especially since one of the *points* of workqueues is
indeed to schedule stuff from irqs and that cannot be done
immediately.
Tejun?
Linus
^ permalink raw reply
* Re: [PATCH net-next v2] bonding: fix strlen errors in sysfs
From: Andy Gospodarek @ 2011-07-22 20:51 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: Vitalii Demianets, Andy Gospodarek, netdev, Takuma Umeya
In-Reply-To: <9576.1310659326@death>
On Thu, Jul 14, 2011 at 09:02:06AM -0700, Jay Vosburgh wrote:
> Vitalii Demianets <vitas@nppfactor.kiev.ua> wrote:
>
> >On Thursday 14 July 2011 04:57:45 Andy Gospodarek wrote:
> >> - if (strnicmp
> >> - (slave->dev->name, buf,
> >> - strlen(slave->dev->name)) == 0) {
> >> + int max_len = max(strlen(slave->dev->name),
> >> + strlen(buf) - 1);
> >> + if (strnicmp(slave->dev->name, buf, max_len) == 0) {
> >
> >As for me there is no sense in preventing "address out of range" errors in
> >strnicmp by calculating length with strlen first. If there is missing \0 at
> >the end of the string you just shift failure point from stricmp to the strlen
> >function call.
> >IMHO "maximum length" argument in strnicmp should be some appropriate constant
> >instead. Alternatively we can use count:
>
> I agree about using a constant, and I nominate IFNAMSIZ for that
> constant.
>
A constant like IFNAMSIZ can work, but only if buf has the '\n' removed
from the string that is added by echo or other command first.
> Also, should we really be using strnicmp? I.e., case
> insensitive? Aren't interface names case sensitive?
Probably not.
I'll roll a patch next week that drops the newline and uses IFNAMSIZ if
that is the preference. I didn't think it was worth the trouble
initially, so I didn't do it that way the first time.
^ permalink raw reply
* Re: [PATCH 10/13] net: add paged frag destructor to skb_fill_page_desc()
From: Ian Campbell @ 2011-07-22 21:07 UTC (permalink / raw)
To: Michał Mirosław
Cc: netdev@vger.kernel.org, linux-nfs@vger.kernel.org,
David S. Miller, James E.J. Bottomley, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
Patrick McHardy, linux-rdma@vger.kernel.org,
linux-s390@vger.kernel.org, linux-scsi@vger.kernel.org,
devel@open-fcoe.org
In-Reply-To: <CAHXqBFLQFKqK=ORpDQx6s2ud8mWkx=YC_AT60GVS+4XK0H61pw@mail.gmail.com>
On Fri, 2011-07-22 at 20:58 +0100, Michał Mirosław wrote:
> 2011/7/22 Ian Campbell <ian.campbell@citrix.com>:
> > diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> > index 9818fe2..faee8d3 100644
> > --- a/include/linux/skbuff.h
> > +++ b/include/linux/skbuff.h
> > @@ -1134,12 +1134,14 @@ static inline int skb_pagelen(const struct sk_buff *skb)
> > * Does not take any additional reference on the fragment.
> > */
> > static inline void __skb_fill_page_desc(struct sk_buff *skb, int i,
> > - struct page *page, int off, int size)
> > + struct page *page,
> > + struct skb_frag_destructor *destroy,
> > + int off, int size)
> > {
> > skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
> >
> > frag->page.p = page;
> > - frag->page.destructor = NULL;
> > + frag->page.destructor = destroy;
> > frag->page_offset = off;
> > frag->size = size;
> > }
>
> You could just rename this function to e.g.
> __skb_fill_fragile_page_desc() (or whatever name) add an inline
> wrapper calling it with destroy == NULL. This will avoid touching all
> those drivers which won't ever need this functionality.
I could call this variant __skb_frag_init (which I think better fits
into the pattern of the new functions) and leave the existing
__skb_fill_page_desc as a compat wrapper if that's preferred but I was
trying to avoid duplicating up constructors just for different sets of
defaults.
Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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: Linux 3.0 release
From: Francois Romieu @ 2011-07-22 21:26 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Ben Greear, Linus Torvalds, David, Tejun Heo,
Linux Kernel Mailing List, netdev
In-Reply-To: <20110722133220.0baf2199@nehalam.ftrdhcpuser.net>
Stephen Hemminger <shemminger@vyatta.com> :
> This a regression which probably began with
>
> commit e22bee782b3b00bd4534ae9b1c5fb2e8e6573c5c
> Author: Tejun Heo <tj@kernel.org>
> Date: Tue Jun 29 10:07:14 2010 +0200
>
> workqueue: implement concurrency managed dynamic worker pool
>
> Before that it was perfectly legal for link watch code to
> call schedule_delayed_work from IRQ. This should be allowable;
> the code to manage the worker pool should handle it.
I beg to differ: see Ben's first report
(http://lists.openwall.net/netdev/2011/05/04/183).
^^
One of the code path in the netif_carrier code leads it to try and disable
a late workqueue to reenable it immediately (mod_workqueue anyone ?):
netif_carrier_on
-> linkwatch_fire_event
-> linkwatch_schedule_work
-> cancel_delayed_work
-> del_timer_sync
The del_timer_sync has been here for ages. Afaiks it is not a new pool code
nor a schedule_delayed_work only problem.
--
Ueimor
^ permalink raw reply
* Re: [Bugme-new] [Bug 39742] New: 2.6.39.3 crash and hangs in 1-2 minutes with igb-RSS and L2TP PPTP services on the NAS server
From: Andrew Morton @ 2011-07-22 21:42 UTC (permalink / raw)
To: netdev; +Cc: bugme-daemon, cpulinker, Patrick McHardy
In-Reply-To: <bug-39742-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Fri, 22 Jul 2011 10:32:45 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=39742
>
> Summary: 2.6.39.3 crash and hangs in 1-2 minutes with igb-RSS
> and L2TP PPTP services on the NAS server
> Product: Networking
> Version: 2.5
> Kernel Version: 2.6.39.3
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: IPV4
> AssignedTo: shemminger@linux-foundation.org
> ReportedBy: cpulinker@yandex.ru
> Regression: No
>
>
> Created an attachment (id=66342)
> --> (https://bugzilla.kernel.org/attachment.cgi?id=66342)
> full trap log, dmesg, iptables, lsmod, ipset
>
> Hi!
> I set up the server with the new software. It must serves users with VPN
> connections (l2tp,pptp - kernel mode).
> As soon as I start the users it hangs. With latest drivers from Intel (igb) and
> the latest kernel (2.6.39.3)
> it hangs (rarely) or a kernel panic (most often) in 1-2 minutes,
> when users log on to the NAS server and starts to go traffic on VPN
> connections.
> I tried to turn off the incoming shaper on the ifb, disable, conntrack(-j
> NOTRACK in the RAW table),
> was trying to use only PPTP - the kernel still hangs or falls into a panic.
> Hardare is ASUS RS100 - Intel P4 Q6600, x86_64, 4GB RAM, SATA HDD, Intel 82576
> 2 ports (igb with enabled RSS)
> Main software:
> Kernel is 2.6.39 upped to the 2.6.39.3 by patch from
> ftp://ftp.altlinux.org/pub/distributions/ALTLinux/Sisyphus/files/SRPMS/kernel-image-std-def-2.6.39-alt3.src.rpm
>
> iproute2 2.6.39
> ipset 4.4
> igb 3.1.16
> iptables 1.4.10
> git://accel-ppp.git.sourceforge.net/gitroot/accel-ppp/accel-ppp
>
> [ 6089.358502] BUG: unable to handle kernel NULL pointer dereference at
> (null)
> [ 6089.362482] IP: [<ffffffffa0264e24>] __nf_conntrack_confirm+0x2b4/0x480
> [nf_conntrack]
> [ 6089.362482] PGD 117822067 PUD 117823067 PMD 0
> [ 6089.362482] Oops: 0002 [#1] SMP
> [ 6089.362482] last sysfs file: /sys/devices/virtual/net/ppp6/uevent
> [ 6089.362482] CPU 1
> [ 6089.362482] Modules linked in: act_mirred act_skbedit cls_u32 sch_ingress
> arc4 ecb ppp_mppe l2tp_ppp l2tp_netlink l2tpd
> [ 6089.362482]
> [ 6089.362482] Pid: 0, comm: kworker/0:0 Not tainted 2.6.39-std-def-alt3 #1
> ASUS RS100-E4/PI2/P5M2-M/RS100-E4
> [ 6089.362482] RIP: 0010:[<ffffffffa0264e24>] [<ffffffffa0264e24>]
> __nf_conntrack_confirm+0x2b4/0x480 [nf_conntrack]
> [ 6089.362482] RSP: 0018:ffff88011fc83a80 EFLAGS: 00010202
> [ 6089.362482] RAX: 00000000000047cd RBX: ffff88011fc94620 RCX:
> 0000000000000000
> [ 6089.362482] RDX: 000000000000fa10 RSI: 00000000d00dd719 RDI:
> ffffffffa026f680
> [ 6089.362482] RBP: ffff88011fc83ac0 R08: 00000000e753847a R09:
> ffff880117f00000
> [ 6089.362482] R10: 0000000000004000 R11: 0000000000000001 R12:
> 0000000000000000
> [ 6089.362482] R13: ffff880116a95080 R14: ffffffff81a4e1c0 R15:
> 00000000000114d8
> [ 6089.362482] FS: 0000000000000000(0000) GS:ffff88011fc80000(0000)
> knlGS:0000000000000000
> [ 6089.362482] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 6089.362482] CR2: 0000000000000000 CR3: 0000000117821000 CR4:
> 00000000000006e0
> [ 6089.362482] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [ 6089.362482] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> [ 6089.362482] Process kworker/0:0 (pid: 0, threadinfo ffff880118ef6000, task
> ffff880118ef42c0)
> [ 6089.362482] Stack:
> [ 6089.362482] 000000007d09da80 0000400016bd4400 0000000116ea2000
> ffff880116a95080
> [ 6089.362482] 0000000000000001 ffff88011fc94620 0000000000000002
> ffff880116ea2000
> [ 6089.362482] ffff88011fc83b30 ffffffffa02b1dd8 ffff880116ea2000
> 0000000000000000
> [ 6089.362482] Call Trace:
> [ 6089.362482] <IRQ>
> [ 6089.362482] [<ffffffffa02b1dd8>] ipv4_confirm+0x188/0x1c0
> [nf_conntrack_ipv4]
> [ 6089.362482] [<ffffffff81382004>] nf_iterate+0x84/0xa0
> [ 6089.362482] [<ffffffff81389390>] ? ip_rcv_finish+0x390/0x390
> [ 6089.362482] [<ffffffff81382096>] nf_hook_slow+0x76/0x130
> [ 6089.362482] [<ffffffff81389390>] ? ip_rcv_finish+0x390/0x390
> [ 6089.362482] [<ffffffff813897d7>] ip_local_deliver+0x67/0x90
> [ 6089.362482] [<ffffffff81389135>] ip_rcv_finish+0x135/0x390
> [ 6089.362482] [<ffffffff81389a1c>] ip_rcv+0x21c/0x2e0
> [ 6089.362482] [<ffffffff81356f5a>] __netif_receive_skb+0x52a/0x690
> [ 6089.362482] [<ffffffff813572d0>] netif_receive_skb+0x60/0x90
> [ 6089.362482] [<ffffffff8124de9c>] ? is_swiotlb_buffer+0x3c/0x50
> [ 6089.362482] [<ffffffff81357440>] napi_skb_finish+0x50/0x70
> [ 6089.362482] [<ffffffff813579bd>] napi_gro_receive+0xbd/0xd0
> [ 6089.362482] [<ffffffffa012129b>] igb_poll+0x6fb/0xae0 [igb]
> [ 6089.362482] [<ffffffff8107fb61>] ? enqueue_hrtimer+0x31/0x80
> [ 6090.302391] [<ffffffff81357be5>] net_rx_action+0x135/0x270
> [ 6090.302391] [<ffffffff81062705>] __do_softirq+0xa5/0x1d0
> [ 6090.302391] [<ffffffff8141301c>] call_softirq+0x1c/0x30
> [ 6090.302391] [<ffffffff8100d355>] do_softirq+0x65/0xa0
> [ 6090.302391] [<ffffffff81062a96>] irq_exit+0x86/0xa0
> [ 6090.302391] [<ffffffff8100cf01>] do_IRQ+0x61/0xe0
> [ 6090.302391] [<ffffffff8140a593>] common_interrupt+0x13/0x13
> [ 6090.302391] <EOI>
> [ 6090.302391] [<ffffffff81012deb>] ? mwait_idle+0x9b/0x1d0
> [ 6090.302391] [<ffffffff8140de35>] ? atomic_notifier_call_chain+0x15/0x20
> [ 6090.302391] [<ffffffff8100a1e6>] cpu_idle+0x56/0xa0
> [ 6090.302391] [<ffffffff81403729>] start_secondary+0x197/0x19c
> [ 6090.302391] Code: ff 74 09 40 0f b6 ff 41 0f b7 0c 38 66 41 39 cc 0f 84 f1
> fe ff ff 48 8b 00 a8 01 0f 84 51 ff ff ff 4
>
^ permalink raw reply
* Re: [PATCH 10/13] net: add paged frag destructor to skb_fill_page_desc()
From: Michał Mirosław @ 2011-07-22 21:44 UTC (permalink / raw)
To: Ian Campbell
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
David S. Miller, James E.J. Bottomley, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
Patrick McHardy,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-s390-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devel-s9riP+hp16TNLxjTenLetw@public.gmane.org
In-Reply-To: <1311368872.4027.76.camel-ztPmHsLffjjnO4AKDKe2m+kiAK3p4hvP@public.gmane.org>
W dniu 22 lipca 2011 23:07 użytkownik Ian Campbell
<Ian.Campbell-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org> napisał:
> On Fri, 2011-07-22 at 20:58 +0100, Michał Mirosław wrote:
>> 2011/7/22 Ian Campbell <ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>:
>> > diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
>> > index 9818fe2..faee8d3 100644
>> > --- a/include/linux/skbuff.h
>> > +++ b/include/linux/skbuff.h
>> > @@ -1134,12 +1134,14 @@ static inline int skb_pagelen(const struct sk_buff *skb)
>> > * Does not take any additional reference on the fragment.
>> > */
>> > static inline void __skb_fill_page_desc(struct sk_buff *skb, int i,
>> > - struct page *page, int off, int size)
>> > + struct page *page,
>> > + struct skb_frag_destructor *destroy,
>> > + int off, int size)
>> > {
>> > skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
>> >
>> > frag->page.p = page;
>> > - frag->page.destructor = NULL;
>> > + frag->page.destructor = destroy;
>> > frag->page_offset = off;
>> > frag->size = size;
>> > }
>>
>> You could just rename this function to e.g.
>> __skb_fill_fragile_page_desc() (or whatever name) add an inline
>> wrapper calling it with destroy == NULL. This will avoid touching all
>> those drivers which won't ever need this functionality.
>
> I could call this variant __skb_frag_init (which I think better fits
> into the pattern of the new functions) and leave the existing
> __skb_fill_page_desc as a compat wrapper if that's preferred but I was
> trying to avoid duplicating up constructors just for different sets of
> defaults.
It's just Huffman coding: since most users need destroy = NULL, it's
good to have a wrapper for this case as it will then take less time to
write and understand the code (you won't need to think what is this
NULL for in all those places).
Best Regards,
Michał Mirosław
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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
* Hello
From: Lathrop Zachary @ 2011-07-22 21:23 UTC (permalink / raw)
Hello
I am Mr. John Galvan, I have a very urgent business proposal worth (15,500,000.00 Pounds Starlings) from private offshore bank (AIG Private Bank). Please email me at (mrjohngalvan8@yahoo.com.hk) for details.
Best Regards,
Mr. John Galvan
^ permalink raw reply
* Re: Linux 3.0 release
From: Stephen Hemminger @ 2011-07-22 22:09 UTC (permalink / raw)
To: Francois Romieu
Cc: Ben Greear, Linus Torvalds, David, Tejun Heo,
Linux Kernel Mailing List, netdev
In-Reply-To: <20110722212629.GA10833@electric-eye.fr.zoreil.com>
On Fri, 22 Jul 2011 23:26:29 +0200
Francois Romieu <romieu@fr.zoreil.com> wrote:
> Stephen Hemminger <shemminger@vyatta.com> :
> > This a regression which probably began with
> >
> > commit e22bee782b3b00bd4534ae9b1c5fb2e8e6573c5c
> > Author: Tejun Heo <tj@kernel.org>
> > Date: Tue Jun 29 10:07:14 2010 +0200
> >
> > workqueue: implement concurrency managed dynamic worker pool
> >
> > Before that it was perfectly legal for link watch code to
> > call schedule_delayed_work from IRQ. This should be allowable;
> > the code to manage the worker pool should handle it.
>
> I beg to differ: see Ben's first report
> (http://lists.openwall.net/netdev/2011/05/04/183).
> ^^
>
> One of the code path in the netif_carrier code leads it to try and disable
> a late workqueue to reenable it immediately (mod_workqueue anyone ?):
> netif_carrier_on
> -> linkwatch_fire_event
> -> linkwatch_schedule_work
> -> cancel_delayed_work
> -> del_timer_sync
>
> The del_timer_sync has been here for ages. Afaiks it is not a new pool code
> nor a schedule_delayed_work only problem.
>
That path can be fixed by calling _cancel_delayed_work() instead.
^ permalink raw reply
* pull request: wireless-next-2.6 2011-07-22
From: John W. Linville @ 2011-07-22 22:23 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
Here is the last big pull request of new wireless bits intended
for 3.1. This includes the usual big batch of updates to iwlagn,
a number of updates to ath9k, mwifiex, carl9170, libertas, and other
drivers, and soem updates to mac80211 and cfg80211 from Johannes.
The most noteworth bits are most of the final push from Rafał for
supporting current Broadcom wireless hardware in b43.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 415b3334a21aa67806c52d1acf4e72e14f7f402f:
icmp: Fix regression in nexthop resolution during replies. (2011-07-22 06:22:10 -0700)
are available in the git repository at:
ssh://master.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git for-davem
Amitkumar Karwar (3):
mwifiex: put multicast/broadcast packets to the same RA
mwifiex: check SDIO multi-port aggregation buffer room correctly
mwifiex: disable auto deep sleep before unloading the driver
Andy Shevchenko (3):
wireless: rtlwifi: throw away MAC_FMT and use %pM instead
wireless: ath9k: use %pM to print MAC
wireless: mwifiex: print hw address via %pM
Bing Zhao (1):
MAINTAINERS: add entry for Marvell mwifiex wireless driver
Christian Lamparter (3):
carl9170 firmware: update firmware headers
carl9170: move beacon_update into tx.c
carl9170: set beacon xmit power to the max
Daniel Drake (2):
libertas: mesh: misc cleanup
libertas: only enable mesh when interface is active
Eliad Peller (3):
mac80211: reconfigure tx on device reconfiguration
cfg80211: enter psm when working as p2p_cli
mac80211: check sta_info_get() return value
Emmanuel Grumbach (21):
iwlagn: move Tx datapath to transport layer
iwlagn: move the tasklet / irq to the transport layer
iwlagn: move sync_irq to transport layer
iwlagn: move the Rx dispatching to the upper layer
iwlagn: add comment to tx and get_tx_cmd in iwl_trans_ops
iwlagn: move rx transport functions to iwl-trans-rx-pcie.c
iwlagn: move tx transport functions to iwl-trans-tx-pcie.c
iwlagn: move iwlagn_stop_device to transport layer
iwlagn: move all the ICT related functions to iwl-trans-rx-pcie.c
iwlagn: add tx start API to transport layer
iwlagn: add kick_nic API to transport layer
iwlagn: kill iwlagn_rx_handler_setup
iwlagn: kill iwlagn_setup_deferred_work
iwlagn: SCD configuration for AMPDU moves to transport layer
iwlagn: move more functions from the start flow to the transport layer
iwlagn: move iwl_prepare_card_hw to the transport layer
iwlagn: transport layer receives struct iwl_trans*
iwlagn: simplify the bus architecture
iwlagn: iwl_bus holds drv_data as void * instead of iwl_priv
iwlagn: add comment to warn about WoWLAN in resume / suspend flows
iwlagn: probe would crash with DEBUG_SHIRQ
Felix Fietkau (2):
ath9k: improve reliability of MIC error detection
ath9k_hw: validate and fix broken eeprom chainmask settings
Fry, Donald H (1):
iwlagn: remove indirection for iwlagn_hw_valid_rtc_data_addr
Hsu, Kenny (1):
iwlagn: set default of uCode ownership to driver
Joe Perches (1):
rtlwifi: Convert printks to pr_<level>
Johannes Berg (15):
nl80211: advertise GTK rekey support, new triggers
mac80211: allow driver access to TKIP RX P1K
mac80211: let key iteration get keys in install order
mac80211: be more careful in suspend/resume
iwlagn: simplify TX flags assignments
cfg80211: allow userspace to control supported rates in scan
mac80211: implement scan supported rates
mac80211: sync driver before TX
cfg80211: fix scan crash on single-band cards
iwlagn: remove keyinfo cache
iwlagn: remove forgotten debugfs function
iwlagn: rewrite HW crypto
iwlagn: implement WoWLAN
iwlagn: track beacon interval sent to device
iwlagn: rename iwlagn_set_dynamic_key
John W. Linville (2):
bcma: fix 'SSB_PCICORE_BFL_NOPCI' undeclared build breakage
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-next-2.6 into for-davem
Kalle Valo (1):
ieee80211: add few wmm tspec values
Luciano Coelho (3):
nl80211/cfg80211: add max_sched_scan_ssids in the hw description
nl80211/cfg80211: add max_sched_scan_ie_len in the hw description
MAINTAINERS: change maintainer of the wl1251 driver
Pavel Roskin (11):
orinoco: minor fixes for problems found by checkpatch.pl
carl9170: fix formatting issues found by checkpatch
ath: use get_unaligned_le{16,32} in ath_hw_keysetmac()
ath9k: use get_unaligned_{b16, le16, le32} where possible
ath9k: remove defines in reg.h that exist in ../reg.h
ath9k: use ath_opmode_to_string()
ath5k: merge ath5k_hw and ath5k_softc
carl9170: fix sparse warnings enabled by CONFIG_SPARSE_RCU_POINTER
ath5k: merge ath5k_{init, deinit}_hw() with their thin wrappers
ath5k: remove ath5k_hw_get_capability(), don't use VEOL on AR5210
ath5k: use get_unaligned_le32() in ath5k_write_pwr_to_pdadc_table()
Rafał Miłecki (25):
ssb: SPROM: add LED duty cycle fields
bcma: cc: set GPIOTIMER register
bcma: extract SPROM rev 9 the same way as rev 8
b43: bus: drop inline from SSB functions
b43: use agent R/W ops for BCMA_IOCTL
b43: HT-PHY: switch to channel after enabling radio
b43: HT-PHY: find channel entry with regs data
b43: HT-PHY: fix typo in 0x2059 radio init
bcma: handle alternative SPROM location
bcma: define IO status register
b43: bcma: define 80211 core specific IO status bits
b43: bcma: read info about supported bands
b43: HT-PHY: fix masks in radio ctl
b43: correctly display longer chipsets ids
bcma: move define of BCMA_CLKCTLST register
bcma: trivial: add helpers for masking/setting
bcma: allow setting FAST clockmode for a core
bcma: allow enabling PLL
b43: bcma: implement full core reset
b43: disable parity check on BCMA devices
ssb: return correct translation bit for 64-bit DMA
bcma: inform drivers about translation bits needed for the core
b43: bcma: get DMA translation bits
b43: (un)initialize driver on the BCMA bus
b43legacy: dma: cache translation (routing bits)
Rajkumar Manoharan (2):
ath9k: Fix sparse warnings
ath9k: Fix some smatch warnings
Wey-Yi Guy (13):
iwlagn: remove un-necessary file
iwlagn: remove dual-indirect call to simply the code
iwlagn: another double indirect removed
iwlagn: comments for iwl_cfg
iwlagn: calibration bitmap
iwlagn: set correct calibration flag
iwlagn: remove legacy calibration command
iwlagn: define valid init calibration mask
iwlagn: radio sensor offset in le16 format
iwlagn: testmode fixed rate available for testmode only
iwlagn: remove un-necessary "_agn"
iwlagn: write iq invert register for 105/135 device
iwlagn: remove "disable otp refresh" W/A
Yogesh Ashok Powar (1):
mwl8k: Fixing sta dereference when ieee80211_tx_info->control.sta is NULL
MAINTAINERS | 10 +-
drivers/bcma/core.c | 72 ++
drivers/bcma/driver_chipcommon.c | 14 +
drivers/bcma/driver_pci.c | 2 +
drivers/bcma/sprom.c | 14 +-
drivers/net/wireless/ath/ath5k/ahb.c | 44 +-
drivers/net/wireless/ath/ath5k/ani.c | 84 +-
drivers/net/wireless/ath/ath5k/ath5k.h | 272 ++++-
drivers/net/wireless/ath/ath5k/attach.c | 31 +-
drivers/net/wireless/ath/ath5k/base.c | 1138 ++++++++---------
drivers/net/wireless/ath/ath5k/base.h | 205 +---
drivers/net/wireless/ath/ath5k/caps.c | 45 -
drivers/net/wireless/ath/ath5k/debug.c | 218 ++--
drivers/net/wireless/ath/ath5k/debug.h | 21 +-
drivers/net/wireless/ath/ath5k/desc.c | 10 +-
drivers/net/wireless/ath/ath5k/dma.c | 12 +-
drivers/net/wireless/ath/ath5k/eeprom.c | 4 +-
drivers/net/wireless/ath/ath5k/initvals.c | 2 +-
drivers/net/wireless/ath/ath5k/led.c | 68 +-
drivers/net/wireless/ath/ath5k/mac80211-ops.c | 257 ++--
drivers/net/wireless/ath/ath5k/pci.c | 38 +-
drivers/net/wireless/ath/ath5k/pcu.c | 24 +-
drivers/net/wireless/ath/ath5k/phy.c | 41 +-
drivers/net/wireless/ath/ath5k/qcu.c | 9 +-
drivers/net/wireless/ath/ath5k/reset.c | 44 +-
drivers/net/wireless/ath/ath5k/rfkill.c | 65 +-
drivers/net/wireless/ath/ath5k/sysfs.c | 32 +-
drivers/net/wireless/ath/ath5k/trace.h | 12 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 12 +-
drivers/net/wireless/ath/ath9k/btcoex.c | 8 +-
drivers/net/wireless/ath/ath9k/debug.c | 22 +-
drivers/net/wireless/ath/ath9k/eeprom_4k.c | 12 +-
drivers/net/wireless/ath/ath9k/eeprom_9287.c | 12 +-
drivers/net/wireless/ath/ath9k/eeprom_def.c | 12 +-
drivers/net/wireless/ath/ath9k/hif_usb.c | 9 +-
drivers/net/wireless/ath/ath9k/htc_drv_debug.c | 7 +-
drivers/net/wireless/ath/ath9k/hw.c | 22 +
drivers/net/wireless/ath/ath9k/init.c | 25 +-
drivers/net/wireless/ath/ath9k/recv.c | 53 +-
drivers/net/wireless/ath/ath9k/reg.h | 23 -
drivers/net/wireless/ath/ath9k/xmit.c | 4 +
drivers/net/wireless/ath/carl9170/carl9170.h | 10 +-
drivers/net/wireless/ath/carl9170/cmd.h | 4 +-
drivers/net/wireless/ath/carl9170/debug.c | 2 +-
drivers/net/wireless/ath/carl9170/fwdesc.h | 3 +
drivers/net/wireless/ath/carl9170/hw.h | 41 +-
drivers/net/wireless/ath/carl9170/led.c | 2 +-
drivers/net/wireless/ath/carl9170/mac.c | 129 --
drivers/net/wireless/ath/carl9170/main.c | 2 +-
drivers/net/wireless/ath/carl9170/phy.c | 6 +-
drivers/net/wireless/ath/carl9170/tx.c | 290 ++++-
drivers/net/wireless/ath/key.c | 7 +-
drivers/net/wireless/b43/b43.h | 7 +
drivers/net/wireless/b43/bus.c | 27 +-
drivers/net/wireless/b43/dma.c | 27 +-
drivers/net/wireless/b43/dma.h | 4 +
drivers/net/wireless/b43/main.c | 106 ++-
drivers/net/wireless/b43/phy_ht.c | 21 +-
drivers/net/wireless/b43/phy_n.c | 4 +-
drivers/net/wireless/b43/radio_2059.c | 9 +
drivers/net/wireless/b43legacy/b43legacy.h | 2 +
drivers/net/wireless/b43legacy/dma.c | 7 +-
drivers/net/wireless/iwlwifi/Makefile | 8 +-
drivers/net/wireless/iwlwifi/iwl-1000.c | 11 +-
drivers/net/wireless/iwlwifi/iwl-2000.c | 46 +-
drivers/net/wireless/iwlwifi/iwl-5000.c | 22 +-
drivers/net/wireless/iwlwifi/iwl-6000.c | 58 +-
drivers/net/wireless/iwlwifi/iwl-agn-calib.c | 65 +-
drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c | 210 ----
drivers/net/wireless/iwlwifi/iwl-agn-ict.c | 306 -----
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 504 +-------
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 8 +-
drivers/net/wireless/iwlwifi/iwl-agn-rxon.c | 115 ++-
drivers/net/wireless/iwlwifi/iwl-agn-sta.c | 380 +++----
drivers/net/wireless/iwlwifi/iwl-agn-tx.c | 411 +------
drivers/net/wireless/iwlwifi/iwl-agn-ucode.c | 179 +---
drivers/net/wireless/iwlwifi/iwl-agn.c | 1234 ++++++++++---------
drivers/net/wireless/iwlwifi/iwl-agn.h | 65 +-
.../net/wireless/iwlwifi/{iwl-pci.h => iwl-bus.h} | 70 +
drivers/net/wireless/iwlwifi/iwl-commands.h | 180 +++-
drivers/net/wireless/iwlwifi/iwl-core.c | 28 +-
drivers/net/wireless/iwlwifi/iwl-core.h | 64 +-
drivers/net/wireless/iwlwifi/iwl-csr.h | 1 +
drivers/net/wireless/iwlwifi/iwl-debug.h | 10 +-
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 87 +-
drivers/net/wireless/iwlwifi/iwl-dev.h | 197 +--
drivers/net/wireless/iwlwifi/iwl-eeprom.c | 10 +-
drivers/net/wireless/iwlwifi/iwl-hcmd.c | 271 ----
drivers/net/wireless/iwlwifi/iwl-io.h | 7 +-
drivers/net/wireless/iwlwifi/iwl-led.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-pci.c | 101 +-
drivers/net/wireless/iwlwifi/iwl-power.c | 8 +-
drivers/net/wireless/iwlwifi/iwl-prph.h | 82 +-
drivers/net/wireless/iwlwifi/iwl-rx.c | 212 +---
drivers/net/wireless/iwlwifi/iwl-scan.c | 8 +-
drivers/net/wireless/iwlwifi/iwl-sta.c | 8 +-
drivers/net/wireless/iwlwifi/iwl-sta.h | 5 +-
drivers/net/wireless/iwlwifi/iwl-sv-open.c | 10 +-
drivers/net/wireless/iwlwifi/iwl-trans-int-pcie.h | 82 ++
drivers/net/wireless/iwlwifi/iwl-trans-rx-pcie.c | 979 +++++++++++++++
.../iwlwifi/{iwl-tx.c => iwl-trans-tx-pcie.c} | 484 +++++++-
drivers/net/wireless/iwlwifi/iwl-trans.c | 643 +++++++++-
drivers/net/wireless/iwlwifi/iwl-trans.h | 154 ++-
drivers/net/wireless/libertas/dev.h | 2 -
drivers/net/wireless/libertas/main.c | 2 +-
drivers/net/wireless/libertas/mesh.c | 1320 +++++++++-----------
drivers/net/wireless/libertas/mesh.h | 31 -
drivers/net/wireless/libertas/tx.c | 2 +-
drivers/net/wireless/mwifiex/debugfs.c | 33 +-
drivers/net/wireless/mwifiex/ioctl.h | 1 +
drivers/net/wireless/mwifiex/main.h | 1 +
drivers/net/wireless/mwifiex/sdio.c | 5 +-
drivers/net/wireless/mwifiex/sta_ioctl.c | 14 +
drivers/net/wireless/mwifiex/wmm.c | 2 +
drivers/net/wireless/mwl8k.c | 6 +-
drivers/net/wireless/orinoco/airport.c | 9 +-
drivers/net/wireless/orinoco/cfg.c | 6 +-
drivers/net/wireless/orinoco/fw.c | 7 +-
drivers/net/wireless/orinoco/fw.h | 2 +-
drivers/net/wireless/orinoco/hermes.c | 40 +-
drivers/net/wireless/orinoco/hermes.h | 37 +-
drivers/net/wireless/orinoco/hermes_dld.c | 8 +-
drivers/net/wireless/orinoco/hermes_dld.h | 12 +-
drivers/net/wireless/orinoco/hw.c | 48 +-
drivers/net/wireless/orinoco/hw.h | 2 +-
drivers/net/wireless/orinoco/main.c | 46 +-
drivers/net/wireless/orinoco/mic.c | 8 +-
drivers/net/wireless/orinoco/orinoco.h | 16 +-
drivers/net/wireless/orinoco/orinoco_cs.c | 6 +-
drivers/net/wireless/orinoco/orinoco_nortel.c | 3 +-
drivers/net/wireless/orinoco/orinoco_pci.c | 4 +-
drivers/net/wireless/orinoco/orinoco_plx.c | 6 +-
drivers/net/wireless/orinoco/orinoco_tmd.c | 2 +-
drivers/net/wireless/orinoco/orinoco_usb.c | 23 +-
drivers/net/wireless/orinoco/spectrum_cs.c | 10 +-
drivers/net/wireless/orinoco/wext.c | 14 +-
drivers/net/wireless/rtlwifi/base.c | 20 +-
drivers/net/wireless/rtlwifi/cam.c | 8 +-
drivers/net/wireless/rtlwifi/core.c | 6 +-
drivers/net/wireless/rtlwifi/debug.h | 5 -
drivers/net/wireless/rtlwifi/rtl8192c/fw_common.c | 5 +-
drivers/net/wireless/rtlwifi/rtl8192ce/hw.c | 2 +-
drivers/net/wireless/rtlwifi/rtl8192cu/hw.c | 69 +-
drivers/net/wireless/rtlwifi/rtl8192cu/mac.c | 11 +-
drivers/net/wireless/rtlwifi/rtl8192de/hw.c | 2 +-
drivers/net/wireless/rtlwifi/rtl8192de/sw.c | 8 +-
drivers/net/wireless/rtlwifi/rtl8192se/hw.c | 12 +-
drivers/net/wireless/rtlwifi/rtl8192se/phy.c | 5 +-
drivers/net/wireless/rtlwifi/rtl8192se/rf.c | 4 +-
drivers/net/wireless/rtlwifi/rtl8192se/sw.c | 6 +-
drivers/net/wireless/rtlwifi/usb.c | 12 +-
drivers/ssb/main.c | 5 +-
include/linux/bcma/bcma.h | 21 +
include/linux/bcma/bcma_driver_chipcommon.h | 13 +-
include/linux/bcma/bcma_regs.h | 27 +-
include/linux/ieee80211.h | 37 +
include/linux/nl80211.h | 33 +-
include/linux/ssb/ssb.h | 2 +
include/net/cfg80211.h | 33 +-
include/net/mac80211.h | 60 +
net/mac80211/agg-rx.c | 10 +-
net/mac80211/cfg.c | 4 +
net/mac80211/driver-ops.h | 31 +
net/mac80211/driver-trace.h | 43 +
net/mac80211/ieee80211_i.h | 7 +-
net/mac80211/key.c | 2 +-
net/mac80211/mlme.c | 30 +-
net/mac80211/pm.c | 3 +
net/mac80211/scan.c | 6 +-
net/mac80211/tkip.c | 11 +
net/mac80211/util.c | 71 +-
net/mac80211/work.c | 28 +-
net/wireless/core.c | 7 +-
net/wireless/core.h | 4 +
net/wireless/nl80211.c | 109 ++-
net/wireless/scan.c | 4 +
net/wireless/util.c | 38 +
177 files changed, 7327 insertions(+), 6261 deletions(-)
delete mode 100644 drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c
delete mode 100644 drivers/net/wireless/iwlwifi/iwl-agn-ict.c
rename drivers/net/wireless/iwlwifi/{iwl-pci.h => iwl-bus.h} (61%)
delete mode 100644 drivers/net/wireless/iwlwifi/iwl-hcmd.c
create mode 100644 drivers/net/wireless/iwlwifi/iwl-trans-int-pcie.h
create mode 100644 drivers/net/wireless/iwlwifi/iwl-trans-rx-pcie.c
rename drivers/net/wireless/iwlwifi/{iwl-tx.c => iwl-trans-tx-pcie.c} (53%)
Omnibus patch is available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2011-07-22.patch.bz2
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH] net: allow netif_carrier to be called safely from IRQ
From: Stephen Hemminger @ 2011-07-22 22:53 UTC (permalink / raw)
To: David Miller
Cc: Francois Romieu, Ben Greear, Linus Torvalds, David, Tejun Heo,
Linux Kernel Mailing List, netdev
In-Reply-To: <20110722150956.5b341488@nehalam.ftrdhcpuser.net>
As reported by Ben Greer and Froncois Romieu. The code path in
the netif_carrier code leads it to try and disable
a late workqueue to reenable it immediately
netif_carrier_on
-> linkwatch_fire_event
-> linkwatch_schedule_work
-> cancel_delayed_work
-> del_timer_sync
If __cancel_delayed_work is used instead then there is no
problem of waiting for running linkwatch_event.
There is a race between linkwatch_event running re-scheduling
but it is harmless to schedule an extra scan of the linkwatch queue.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/net/core/link_watch.c 2011-07-22 15:25:31.027533604 -0700
+++ b/net/core/link_watch.c 2011-07-22 15:31:27.531520028 -0700
@@ -126,7 +126,7 @@ static void linkwatch_schedule_work(int
return;
/* It's already running which is good enough. */
- if (!cancel_delayed_work(&linkwatch_work))
+ if (!__cancel_delayed_work(&linkwatch_work))
return;
/* Otherwise we reschedule it again for immediate execution. */
^ permalink raw reply
* Re: [PATCH] sbni: use pci_dev->subsystem_device
From: David Miller @ 2011-07-23 0:15 UTC (permalink / raw)
To: sshtylyov; +Cc: netdev
In-Reply-To: <201107221950.25960.sshtylyov@ru.mvista.com>
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Date: Fri, 22 Jul 2011 19:50:25 +0400
> The driver reads PCI subsystem ID from the PCI configuration register while it's
> already stored by the PCI subsystem in the 'subsystem_device' field of 'struct
> pci_dev'...
>
> Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Applied.
^ permalink raw reply
* Re: [PATCH] r8169: use pci_dev->subsystem_{vendor|device}
From: David Miller @ 2011-07-23 0:15 UTC (permalink / raw)
To: sshtylyov; +Cc: netdev, nic_swsd, romieu
In-Reply-To: <201107221937.24383.sshtylyov@ru.mvista.com>
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Date: Fri, 22 Jul 2011 19:37:24 +0400
> The driver reads PCI subsystem IDs from the PCI configuration registers while
> they are already stored by the PCI subsystem in the 'subsystem_{vendor|device}'
> fields of 'struct pci_dev'...
>
> Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Applied.
^ permalink raw reply
* Re: [PATCH 0/5] bridge patchs
From: David Miller @ 2011-07-23 0:15 UTC (permalink / raw)
To: shemminger; +Cc: davem, netdev
In-Reply-To: <20110722174705.144993799@vyatta.com>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Fri, 22 Jul 2011 10:47:05 -0700
> Bridge patches. These are order by urgency from important to trivial.
All applied.
^ permalink raw reply
* Re: [PATCH] dm9000: Make the driver follow the IRQF_SHARED contract
From: David Miller @ 2011-07-23 0:15 UTC (permalink / raw)
To: daniel.morsing; +Cc: broonie, netdev, linux-kernel
In-Reply-To: <1311357162-16200-1-git-send-email-daniel.morsing@gmail.com>
From: Daniel Morsing <daniel.morsing@gmail.com>
Date: Fri, 22 Jul 2011 19:52:42 +0200
> The dm9000 driver requests a shared interrupt but doesn't return
> IRQ_NONE when the device didn't generate the interrupt. This could lead
> to the other devices sharing the irq never getting an interrupt. This
> patch makes the routine return IRQ_NONE for the path where no work was
> done.
>
> Signed-off-by: Daniel Morsing <daniel.morsing@gmail.com>
> Cc: stable@kernel.org
Applied.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2011-07-22
From: David Miller @ 2011-07-23 0:16 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20110722222308.GA3048@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Fri, 22 Jul 2011 18:23:09 -0400
> Here is the last big pull request of new wireless bits intended
> for 3.1. This includes the usual big batch of updates to iwlagn,
> a number of updates to ath9k, mwifiex, carl9170, libertas, and other
> drivers, and soem updates to mac80211 and cfg80211 from Johannes.
> The most noteworth bits are most of the final push from Rafał for
> supporting current Broadcom wireless hardware in b43.
>
> Please let me know if there are problems!
A little late to be submitting this since the merge window is
already open, but I pulled anyways.
Thanks!
^ permalink raw reply
* Re: [PATCH 00/10] bna: driver fixes and cleanup
From: David Miller @ 2011-07-23 0:15 UTC (permalink / raw)
To: rmody; +Cc: netdev, adapter_linux_open_src_team
In-Reply-To: <1311358069-32067-1-git-send-email-rmody@brocade.com>
From: Rasesh Mody <rmody@brocade.com>
Date: Fri, 22 Jul 2011 11:07:39 -0700
> The following patch set adds fixes and clean ups for current upstream driver.
>
> The driver has been compiled and tested against net-next-2.6(3.0.0-rc7)
All applied.
^ permalink raw reply
* Re: [PATCH] net: allow netif_carrier to be called safely from IRQ
From: David Miller @ 2011-07-23 0:16 UTC (permalink / raw)
To: shemminger; +Cc: romieu, greearb, torvalds, david, tj, linux-kernel, netdev
In-Reply-To: <20110722155356.5911225f@nehalam.ftrdhcpuser.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Fri, 22 Jul 2011 15:53:56 -0700
> As reported by Ben Greer and Froncois Romieu. The code path in
> the netif_carrier code leads it to try and disable
> a late workqueue to reenable it immediately
> netif_carrier_on
> -> linkwatch_fire_event
> -> linkwatch_schedule_work
> -> cancel_delayed_work
> -> del_timer_sync
>
> If __cancel_delayed_work is used instead then there is no
> problem of waiting for running linkwatch_event.
>
> There is a race between linkwatch_event running re-scheduling
> but it is harmless to schedule an extra scan of the linkwatch queue.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: Linux 3.0 release
From: Tejun Heo @ 2011-07-23 2:27 UTC (permalink / raw)
To: Linus Torvalds
Cc: Stephen Hemminger, Ben Greear, David, Linux Kernel Mailing List,
netdev
In-Reply-To: <CA+55aFwX55HhzyPsb5vx-=xkHpWJBH0481ZFWcXnNzH1M6zhdg@mail.gmail.com>
Hello, Stephen, Linus.
On Fri, Jul 22, 2011 at 01:35:16PM -0700, Linus Torvalds wrote:
> On Fri, Jul 22, 2011 at 1:32 PM, Stephen Hemminger
> <shemminger@vyatta.com> wrote:
> >
> > The workqueue code should have a fallback and not try and
> > do anything if being called from IRQ.
>
> Fair enough. Especially since one of the *points* of workqueues is
> indeed to schedule stuff from irqs and that cannot be done
> immediately.
>
> Tejun?
It seems to have been already tracked down but, just to be clear.
Nothing changed regarding synchronization requirements for all the
queue, flush and cancel functions. If it worked before cmwq, it
should work with cmwq.
While on the topic, we do have some workqueue API problems. The
delayed ones are a bit screwy. e.g. requeueing an already pending
delayed work item should probably update the timer but it doesn't andp
we have a bunch of users doing cancel/requeue or using separate timers
for that. Also, the cancel/flush[_sync] variants are subtly different
making using the correct one difficult, which has possibility of
introducing bugs which are extremely difficult to reproduce.
Again, most of these had accumulated well before cmwq came into the
picture. I think we need to make workqueue simpler and easier to use.
Thanks.
--
tejun
^ permalink raw reply
* Re: Linux 3.0 release
From: Tejun Heo @ 2011-07-23 2:30 UTC (permalink / raw)
To: Linus Torvalds
Cc: Stephen Hemminger, Ben Greear, David, Linux Kernel Mailing List,
netdev
In-Reply-To: <20110723022715.GB21089@mtj.dyndns.org>
On Sat, Jul 23, 2011 at 04:27:15AM +0200, Tejun Heo wrote:
> While on the topic, we do have some workqueue API problems. The
> delayed ones are a bit screwy. e.g. requeueing an already pending
> delayed work item should probably update the timer but it doesn't andp
> we have a bunch of users doing cancel/requeue or using separate timers
> for that.
(after reading the other branch of the thread) Ooh, bingo, this
actually was the issue which triggered the problem reported here. :)
--
tejun
^ permalink raw reply
* Re: [PATCH] net: Fix security_socket_sendmsg() bypass problem.
From: Tetsuo Handa @ 2011-07-23 5:20 UTC (permalink / raw)
To: davem; +Cc: casey, anton, netdev, linux-security-module
In-Reply-To: <201107230331.GHE48423.QFHJMFOLtOOSVF@I-love.SAKURA.ne.jp>
Tetsuo Handa wrote:
> Tetsuo Handa wrote:
> > David Miller wrote:
> > > Ugh, this takes away a non-trivial part of the performance gain of
> > > sendmmsg().
> > >
> > > I would instead rather that you check ahead of time whether this
> > > actually is a send to different addresses. If they are all the
> > > same, keep the nosec code path.
> > >
> > OK. Something like this? Not tested at all.
>
> No. We can't compare destination address before entering __sys_sendmsg(), for
> it is copied to kernel memory by verify_iovec()/verify_compat_iovec().
>
OK. Something like this? Not tested at all.
----------------------------------------
[PATCH] net: Fix security_socket_sendmsg() bypass problem.
The sendmmsg() introduced by commit 228e548e "net: Add sendmmsg socket system
call" is capable of sending to multiple different destinations. However,
security_socket_sendmsg() is called for only once even if multiple different
destination's addresses are passed to sendmmsg().
SMACK is using destination's address for checking sendmsg() permission.
Therefore, we need to call security_socket_sendmsg() for each destination
address rather than the first destination address.
Fix this problem by maintaining a list of already-checked destination address.
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@kernel.org> [3.0+]
---
net/socket.c | 84 +++++++++++++++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 79 insertions(+), 5 deletions(-)
--- linux-3.0.orig/net/socket.c
+++ linux-3.0/net/socket.c
@@ -1871,8 +1871,19 @@ SYSCALL_DEFINE2(shutdown, int, fd, int,
#define COMPAT_NAMELEN(msg) COMPAT_MSG(msg, msg_namelen)
#define COMPAT_FLAGS(msg) COMPAT_MSG(msg, msg_flags)
+/*
+ * Structure for remembering destination's address used by send_mmsg().
+ * This is for calling security_socket_sendms() only once for each destination.
+ */
+struct sendmmsg_dest_info {
+ struct list_head list;
+ unsigned int address_len;
+ struct sockaddr_storage address;
+};
+
static int __sys_sendmsg(struct socket *sock, struct msghdr __user *msg,
- struct msghdr *msg_sys, unsigned flags, int nosec)
+ struct msghdr *msg_sys, unsigned flags,
+ struct list_head *list)
{
struct compat_msghdr __user *msg_compat =
(struct compat_msghdr __user *)msg;
@@ -1883,6 +1894,7 @@ static int __sys_sendmsg(struct socket *
/* 20 is size of ipv6_pktinfo */
unsigned char *ctl_buf = ctl;
int err, ctl_len, iov_size, total_len;
+ bool nosec = false;
err = -EFAULT;
if (MSG_CMSG_COMPAT & flags) {
@@ -1953,6 +1965,58 @@ static int __sys_sendmsg(struct socket *
if (sock->file->f_flags & O_NONBLOCK)
msg_sys->msg_flags |= MSG_DONTWAIT;
+ if (list) {
+ /*
+ * We need to pass destination address to
+ * security_socket_sendmsg() since some LSM modules want it.
+ * But passing already-checked destination address twice is
+ * waste of time.
+ *
+ * Therefore, check for already-checked destination address in
+ * order to see whether we can omit security_socket_sendmsg()
+ * call or not.
+ *
+ * This optimization assumes that LSM modules use only
+ * destination address (i.e. "struct msghdr"->msg_name and
+ * "struct msghdr"->msg_namelen). We can't use this assumption
+ * if LSM modules want to use other factors (e.g. total_len
+ * argument below).
+ */
+ struct sendmmsg_dest_info *ptr;
+ list_for_each_entry(ptr, list, list) {
+ /*
+ * verify_iovec()/verify_compat_iovec() above assigned
+ * appropriate values to msg_sys->msg_namelen and
+ * msg_sys->msg_name.
+ */
+ if (ptr->address_len != msg_sys->msg_namelen ||
+ memcmp(&ptr->address, msg_sys->msg_name,
+ ptr->address_len))
+ continue;
+ nosec = true;
+ break;
+ }
+ if (!nosec) {
+ /*
+ * Remember the destination address passed to
+ * sendmmsg() so that we can avoid calling
+ * security_sendmsg_permission() again for
+ * already-checked destination address.
+ *
+ * Out of memory error is not fatal here because
+ * calling security_sendmsg_permission() again for
+ * already-checked destination address should be
+ * harmless.
+ */
+ ptr = kmalloc(sizeof(*ptr), GFP_KERNEL);
+ if (ptr) {
+ ptr->address_len = msg_sys->msg_namelen;
+ memcpy(&ptr->address, msg_sys->msg_name,
+ ptr->address_len);
+ list_add(&ptr->list, list);
+ }
+ }
+ }
err = (nosec ? sock_sendmsg_nosec : sock_sendmsg)(sock, msg_sys,
total_len);
@@ -1979,7 +2043,7 @@ SYSCALL_DEFINE3(sendmsg, int, fd, struct
if (!sock)
goto out;
- err = __sys_sendmsg(sock, msg, &msg_sys, flags, 0);
+ err = __sys_sendmsg(sock, msg, &msg_sys, flags, NULL);
fput_light(sock->file, fput_needed);
out:
@@ -1998,6 +2062,7 @@ int __sys_sendmmsg(int fd, struct mmsghd
struct mmsghdr __user *entry;
struct compat_mmsghdr __user *compat_entry;
struct msghdr msg_sys;
+ LIST_HEAD(list); /* List for finding duplicated destination address. */
datagrams = 0;
@@ -2014,18 +2079,19 @@ int __sys_sendmmsg(int fd, struct mmsghd
while (datagrams < vlen) {
/*
- * No need to ask LSM for more than the first datagram.
+ * No need to ask LSM for more than the first datagram for
+ * each destination.
*/
if (MSG_CMSG_COMPAT & flags) {
err = __sys_sendmsg(sock, (struct msghdr __user *)compat_entry,
- &msg_sys, flags, datagrams);
+ &msg_sys, flags, &list);
if (err < 0)
break;
err = __put_user(err, &compat_entry->msg_len);
++compat_entry;
} else {
err = __sys_sendmsg(sock, (struct msghdr __user *)entry,
- &msg_sys, flags, datagrams);
+ &msg_sys, flags, &list);
if (err < 0)
break;
err = put_user(err, &entry->msg_len);
@@ -2038,6 +2104,14 @@ int __sys_sendmmsg(int fd, struct mmsghd
}
out_put:
+ { /* Clean up destination addresses. */
+ struct sendmmsg_dest_info *ptr;
+ struct sendmmsg_dest_info *tmp;
+ list_for_each_entry_safe(ptr, tmp, &list, list) {
+ list_del(&ptr->list);
+ kfree(ptr);
+ }
+ }
fput_light(sock->file, fput_needed);
if (err == 0)
^ permalink raw reply
* [PATCH net-2.6 v2] gre: fix improper error handling
From: xeb @ 2011-07-23 6:49 UTC (permalink / raw)
To: davem; +Cc: netdev
[-- Attachment #1: Type: text/plain, Size: 180 bytes --]
Fix improper protocol err_handler, current implementation is fully
unapplicable and may cause kernel crash due to double kfree_skb.
Signed-off-by: Dmitry Kozlov <xeb@mail.ru>
---
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 1156 bytes --]
net/ipv4/gre.c | 21 ++++++---------------
1 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/net/ipv4/gre.c b/net/ipv4/gre.c
index 9dbe108..dbfc21d 100644
--- a/net/ipv4/gre.c
+++ b/net/ipv4/gre.c
@@ -15,6 +15,7 @@
#include <linux/kmod.h>
#include <linux/skbuff.h>
#include <linux/in.h>
+#include <linux/ip.h>
#include <linux/netdevice.h>
#include <linux/spinlock.h>
#include <net/protocol.h>
@@ -96,27 +97,17 @@ drop:
static void gre_err(struct sk_buff *skb, u32 info)
{
const struct gre_protocol *proto;
- u8 ver;
-
- if (!pskb_may_pull(skb, 12))
- goto drop;
+ const struct iphdr *iph = (const struct iphdr *)skb->data;
+ u8 ver = skb->data[(iph->ihl<<2) + 1]&0x7f;
- ver = skb->data[1]&0x7f;
if (ver >= GREPROTO_MAX)
- goto drop;
+ return;
rcu_read_lock();
proto = rcu_dereference(gre_proto[ver]);
- if (!proto || !proto->err_handler)
- goto drop_unlock;
- proto->err_handler(skb, info);
- rcu_read_unlock();
- return;
-
-drop_unlock:
+ if (proto && proto->err_handler)
+ proto->err_handler(skb, info);
rcu_read_unlock();
-drop:
- kfree_skb(skb);
}
static const struct net_protocol net_gre_protocol = {
^ permalink raw reply related
* Re: [PATCH] net: Fix security_socket_sendmsg() bypass problem.
From: Michael Tokarev @ 2011-07-23 7:04 UTC (permalink / raw)
To: David Miller; +Cc: penguin-kernel, casey, anton, netdev, linux-security-module
In-Reply-To: <20110722.082224.688620059032914637.davem@davemloft.net>
22.07.2011 19:22, David Miller wrote:
> From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Date: Sat, 23 Jul 2011 00:12:53 +0900
>
>> I think the regression for SMACK can be fixed with below patch.
>>
>> Should I pass nosec flags down to "struct security_operations"->sendmsg()
>> so that SELinux checks sock_has_perm() for only once when multiple different
>> destination's addresses are passed to sendmmsg()?
>>
>> static int selinux_socket_sendmsg(struct socket *sock, struct msghdr *msg,
>> int size, int nosec)
>> {
>> return nosec ? 0 : sock_has_perm(current, sock->sk, SOCKET__WRITE);
>> }
>
> Ugh, this takes away a non-trivial part of the performance gain of
> sendmmsg().
>
> I would instead rather that you check ahead of time whether this
> actually is a send to different addresses. If they are all the
> same, keep the nosec code path.
Why to optimize for this case when destination addresses are the
same? How common this usage case is, or even where it _can_
happen alot (I noticed samba.org address in the Cc list).
When I saw recvmmsg()/sendmmsg() here, my first thought was an
authoritative DNS server which can read several requests at a
time and answer them all at once too - this way it all will go
to different addresses.
I understand the initial change takes away good portion of
performance improvement, but I think the optimisation should
be performed in a different place than for a not-so-common
cenario.
Thanks,
/mjt
^ 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