* Re: System freeze on reboot - general protection fault
From: Zdenek Kabelac @ 2009-09-02 22:31 UTC (permalink / raw)
To: Eric Dumazet
Cc: Patrick McHardy, Christoph Lameter, Robin Holt,
Linux Kernel Mailing List, Pekka Enberg, Jesper Dangaard Brouer,
Linux Netdev List, Netfilter Developers
In-Reply-To: <4A9EEF07.5070800@gmail.com>
2009/9/3 Eric Dumazet <eric.dumazet@gmail.com>:
> Zdenek Kabelac a écrit :
>> 2009/8/17 Patrick McHardy <kaber@trash.net>:
>>> Eric Dumazet wrote:
>>>> Zdenek Kabelac a écrit :
>>>>> [<ffffffffa02c502f>] nf_conntrack_ftp_fini+0x2f/0x70 [nf_conntrack_ftp]
>>>>> [<ffffffff8027bcc5>] sys_delete_module+0x1a5/0x270
>>>>> [<ffffffff8020d329>] ? retint_swapgs+0xe/0x13
>>>>> [<ffffffff80271bf2>] ? trace_hardirqs_on_caller+0x162/0x1b0
>>>>> [<ffffffff80292121>] ? audit_syscall_entry+0x191/0x1c0
>>>>> [<ffffffff80526dae>] ? trace_hardirqs_on_thunk+0x3a/0x3f
>>>>> [<ffffffff8020c84b>] system_call_fastpath+0x16/0x1b
>>>>> Code: c6 00 00 0f 82 66 ff ff ff 49 8b 9e d8 05 00 00 48 85 db 75 16
>>>>> e9 8e 00 00 00 0f 1f 44 00 00 48 85 c0 0f 84 80 00 00 00 48 89 c3 <0f>
>>>>> b6 4b 37 48 8b 03 48 8d 14 cd 00 00 00 00 0f 18 08 48 29 ca
>>>>> RIP [<ffffffffa02b2c2c>] nf_conntrack_helper_unregister+0x16c/0x320
>>>>> [nf_conntrack]
>>>>> RSP <ffff88013982fe68>
>>>>> CR2: 0000000000000038
>>>>> ---[ end trace bc3a0ede3d0084db ]---
>>>>>
>>>> I am currently traveling and wont be able to help you before next week.
>>>>
>>>> I added netdev, Patrick, and netfilter-devel in CC so that more eyes can take a look.
>>> Thanks for the report, I'll have a look at this. Zdenek, please
>>> send me the nf_conntrack.ko file used in the above oops. Thanks.
>>>
>>
>> Ok
>>
>> I've found the solution for my problem.
>>
>> http://thread.gmane.org/gmane.comp.security.firewalls.netfilter.devel/30483
>>
>> I've made this small fix from this thread:
>>
>> diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core
>> index b5869b9..68488f8 100644
>> --- a/net/netfilter/nf_conntrack_core.c
>> +++ b/net/netfilter/nf_conntrack_core.c
>> @@ -1108,6 +1108,7 @@ static void nf_conntrack_cleanup_init_net(void)
>> {
>> nf_conntrack_helper_fini();
>> nf_conntrack_proto_fini();
>> + rcu_barrier();
>> kmem_cache_destroy(nf_conntrack_cachep);
>> }
>>
>> @@ -1266,7 +1267,7 @@ static int nf_conntrack_init_init_net(void)
>>
>> nf_conntrack_cachep = kmem_cache_create("nf_conntrack",
>> sizeof(struct nf_conn),
>> - 0, SLAB_DESTROY_BY_RCU, NULL);
>> + 0, 0, NULL);
>> if (!nf_conntrack_cachep) {
>> printk(KERN_ERR "Unable to create nf_conn slab cache\n");
>> ret = -ENOMEM;
>>
>>
>> As the thread nf_conntrack: Use rcu_barrier() and fix kmem_cache_create flags
>> seems to be samewhat 'unfinished' and already a bit old and I've no
>> idea whether it actually fixes problem completely or just hides it in
>> my case - I'm leaving it to some RCU gurus to fix this issue.
>>
>> All I could say is - this this extra rcu_barrier() and removal of
>> SLAB_DESTROY removes my GPF on reboot.
>>
>> Zdenek
>
> Ouch..
>
> Dont think such a patch makes your kernel better, it'll crash too.
>
> You cannot remove SLAB_DESTROY_BY_RCU like this, it's there for very good reasons.
>
Well I'm not noticing any ill behavior - also note - rcu_barrier() is
there before the cache is destroyed.
But as I said - it's just my shot into the dark - which seems to work for me...
Zdenek
^ permalink raw reply
* Re: Crypto oops in async_chainiv_do_postponed
From: Brad Bosch @ 2009-09-02 23:47 UTC (permalink / raw)
To: Herbert Xu; +Cc: Brad Bosch, linux-crypto, netdev, offbase0
In-Reply-To: <20090902215712.GA16941@gondor.apana.org.au>
Herbert Xu writes:
> On Wed, Sep 02, 2009 at 09:08:38AM -0500, Brad Bosch wrote:
> >
> > Assume the worker thread is executing between the dequeue in
> > async_chainiv_do_postponed and the clear_bit call in
> > async_chainiv_schedule_work. Further assume that we are processing
>
> It cannot. The worker thread can only execute when it owns
> the INUSE bit. In that case do_postponed will never call the
> schedule_work function.
In the example I cited (one entry in the queue when the worker
function starts), async_chainiv_schedule_work is indeed executed.
(indirectly) by async_chainiv_givencrypt_tail from the worker thread.
I'm sorry I didn't make it more clear that it is that code path I was
talking about.
>
> Perhaps you were misled by the clear_bit call in schedule_work.
> That is only used if we end up not scheduling the work.
No, I was not misled. But apparently, I was not clear. I do
understand how you use the INUSE bit. I did not say above that
INUSE is not set when the worker thread is running (at least not for
the first part of my example). If you had read further, you might
have noticed that the following paragraphs showed that indeed I do
understand that INUSE is set in the worker thread as evidenced by
"thread one calls test_and_set_bit which returns 1" I have added one
sentence (marked by **) to my event description below to make my
understanding more clear. Please read on.
Assume the worker thread is executing between the dequeue in
async_chainiv_do_postponed and the clear_bit call in
async_chainiv_schedule_work. Further assume that we are processing
the last item on the queue so durring this time, ctx->queue.qlen =
0. **INUSE is still set at this point.
Meanwhile, three threads enter async_chainiv_givencrypt for the same
ctx at about the same time.
Thread one calls test_and_set_bit which returns 1 and calls
async_cahiniv_postpone_request but suppose it has not yet enqueued.
Now INUSE is set and qlen=0.
Next, the worker thread calls clear_bit in async_chainiv_schedule_work
but it is interrupted before it can call test_and_set_bit. Now INUSE
is clear and qlen=0
The test_and_set_bit in thread two is called at this moment and
returns 0 and then calls async_chainiv_givencrypt_tail. Now INUSE is
set and qlen=0.
Thread one now locks the ctx and calls skcipher_enqueue_givcrypt and
unlocks. Now INUSE is set and qlen=1.
Thread three calls test_and_set_bit which returns 1 and then it clears
INUSE since qlen=1 and it calls postpone with INUSE clear and qlen=1
Now thread three will use ctx->err to hold the return value of
skcipher_enqueue_givcrypt at the same time as thread two uses ctx->err
to hold the return value of crypto_ablkcipher_encrypt!
Did I make a mistake above? I suspect more bad things can happen as
well in this scenario, but I'm just focusing on the use of ctx->err here.
Thanks
--Brad
^ permalink raw reply
* Re: [PATCH net-next-2.6] vlan: multiqueue vlan devices
From: David Miller @ 2009-09-03 1:04 UTC (permalink / raw)
To: eric.dumazet; +Cc: shemminger, brian.haley, kaber, jarkao2, netdev
In-Reply-To: <4A9EC383.4070304@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 02 Sep 2009 21:12:03 +0200
> [PATCH net-next-2.6] vlan: multiqueue vlan device
>
> vlan devices are currently not multi-queue capable.
>
> We can do that with a new rtnl_link_ops method,
> get_tx_queues(), called from rtnl_create_link()
>
> This new method gets num_tx_queues/real_num_tx_queues
> from real device.
>
> register_vlan_device() is also handled.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, but now I need you to do an audit :-)
I believe that drivers will change the number of TX queues
in use at times where we'll need to trigger an event or
something so that vlan's can learn about the value changing.
^ permalink raw reply
* [PATCH] slub: fix slab_pad_check() and SLAB_DESTROY_BY_RCU
From: Eric Dumazet @ 2009-09-03 1:04 UTC (permalink / raw)
To: Zdenek Kabelac
Cc: Patrick McHardy, Christoph Lameter, Robin Holt,
Linux Kernel Mailing List, Pekka Enberg, Jesper Dangaard Brouer,
Linux Netdev List, Netfilter Developers
In-Reply-To: <c4e36d110909021531v324a9ce2x3ff2c93b7c5a57de@mail.gmail.com>
Zdenek Kabelac a écrit :
>
> Well I'm not noticing any ill behavior - also note - rcu_barrier() is
> there before the cache is destroyed.
> But as I said - it's just my shot into the dark - which seems to work for me...
>
Reading again your traces, I do believe there are two bugs in slub
Maybe not explaining your problem, but worth to fix !
Thank you
[PATCH] slub: fix slab_pad_check() and SLAB_DESTROY_BY_RCU
When SLAB_POISON is used and slab_pad_check() finds an overwrite of the
slab padding, we call restore_bytes() on the whole slab, not only
on the padding.
kmem_cache_destroy() should call rcu_barrier() *after* kmem_cache_close()
and *before* sysfs_slab_remove() or risk rcu_free_slab()
being called after kmem_cache is deleted (kfreed).
rmmod nf_conntrack can crash the machine because it has to
kmem_cache_destroy() a SLAB_DESTROY_BY_RCU enabled cache.
Reported-by: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/mm/slub.c b/mm/slub.c
index b9f1491..0ac839f 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -646,7 +646,7 @@ static int slab_pad_check(struct kmem_cache *s, struct page *page)
slab_err(s, page, "Padding overwritten. 0x%p-0x%p", fault, end - 1);
print_section("Padding", end - remainder, remainder);
- restore_bytes(s, "slab padding", POISON_INUSE, start, end);
+ restore_bytes(s, "slab padding", POISON_INUSE, end - remainder, end);
return 0;
}
@@ -2594,8 +2594,6 @@ static inline int kmem_cache_close(struct kmem_cache *s)
*/
void kmem_cache_destroy(struct kmem_cache *s)
{
- if (s->flags & SLAB_DESTROY_BY_RCU)
- rcu_barrier();
down_write(&slub_lock);
s->refcount--;
if (!s->refcount) {
@@ -2606,6 +2604,8 @@ void kmem_cache_destroy(struct kmem_cache *s)
"still has objects.\n", s->name, __func__);
dump_stack();
}
+ if (s->flags & SLAB_DESTROY_BY_RCU)
+ rcu_barrier();
sysfs_slab_remove(s);
} else
up_write(&slub_lock);
^ permalink raw reply related
* Re: [PATCH net-next-2.6] ip: Report qdisc packet drops
From: David Miller @ 2009-09-03 1:05 UTC (permalink / raw)
To: eric.dumazet; +Cc: cl, sri, dlstevens, netdev, niv, mtk.manpages
In-Reply-To: <4A9EF113.9030102@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 03 Sep 2009 00:26:27 +0200
> Here is an updated version of the patch, after Christoph comments.
>
>
>
> [PATCH net-next-2.6] ip: Report qdisc packet drops
Looks great, applied!
^ permalink raw reply
* Re: [PATCH net-next-2.6] vlan: multiqueue vlan devices
From: Eric Dumazet @ 2009-09-03 1:05 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, brian.haley, kaber, jarkao2, netdev
In-Reply-To: <20090902.180401.155663057.davem@davemloft.net>
David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 02 Sep 2009 21:12:03 +0200
>
>> [PATCH net-next-2.6] vlan: multiqueue vlan device
>>
>> vlan devices are currently not multi-queue capable.
>>
>> We can do that with a new rtnl_link_ops method,
>> get_tx_queues(), called from rtnl_create_link()
>>
>> This new method gets num_tx_queues/real_num_tx_queues
>> from real device.
>>
>> register_vlan_device() is also handled.
>>
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Applied, but now I need you to do an audit :-)
>
> I believe that drivers will change the number of TX queues
> in use at times where we'll need to trigger an event or
> something so that vlan's can learn about the value changing.
Yes, I know :)
This is why I kept both num_tx_queues and real_num_tx_queues values,
and not the later :)
Thanks
^ permalink raw reply
* Re: [PATCH net-next-2.6] ip: Report qdisc packet drops
From: David Miller @ 2009-09-03 1:09 UTC (permalink / raw)
To: cl; +Cc: eric.dumazet, sri, dlstevens, netdev, niv, mtk.manpages
In-Reply-To: <alpine.DEB.1.10.0909021318490.21832@V090114053VZO-1>
From: Christoph Lameter <cl@linux-foundation.org>
Date: Wed, 2 Sep 2009 13:22:25 -0500 (CDT)
> There may be a minor issue here in that IP_RECVERR sometimes sends error
> packets that have to be intercepted using special code. Or can those be
> simply ignored? If so then I will ask UDP app vendors to use IP_RECVERR.
If you don't set MSG_ERRQUEUE, no special error reports will be
given to the application.
And this only matters for recvmsg() handling.
On send, the only behavior difference is this error code reporting
(and before Eric's patch, SNMP statistics handling).
^ permalink raw reply
* Re: [PATCH 2/2] fec: don't enable irqs in hard irq context
From: Greg Ungerer @ 2009-09-03 1:14 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: linux-rt-users, Ben Hutchings, Patrick McHardy, Sascha Hauer,
Matt Waddel, netdev, Tim Sander
In-Reply-To: <1251882856-23549-2-git-send-email-u.kleine-koenig@pengutronix.de>
Hi Uwe,
Uwe Kleine-König wrote:
> fec_enet_mii, fec_enet_rx and fec_enet_tx are both only called by
> fec_enet_interrupt in interrupt context. So they must not use
> spin_lock_irq/spin_unlock_irq.
>
> This fixes:
> WARNING: at kernel/lockdep.c:2140 trace_hardirqs_on_caller+0x130/0x194()
> ...
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> Cc: Greg Ungerer <gerg@uclinux.org>
Looks good.
Acked-by: Greg Ungerer <gerg@uclinux.org>
> Cc: Ben Hutchings <ben@decadent.org.uk>
> Cc: Patrick McHardy <kaber@trash.net>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Matt Waddel <Matt.Waddel@freescale.com>
> Cc: netdev@vger.kernel.org
> Cc: Tim Sander <tim01@vlsi.informatik.tu-darmstadt.de>
> ---
> drivers/net/fec.c | 12 ++++++------
> 1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/fec.c b/drivers/net/fec.c
> index ef82606..9c49d56 100644
> --- a/drivers/net/fec.c
> +++ b/drivers/net/fec.c
> @@ -427,7 +427,7 @@ fec_enet_tx(struct net_device *dev)
> struct sk_buff *skb;
>
> fep = netdev_priv(dev);
> - spin_lock_irq(&fep->hw_lock);
> + spin_lock(&fep->hw_lock);
> bdp = fep->dirty_tx;
>
> while (((status = bdp->cbd_sc) & BD_ENET_TX_READY) == 0) {
> @@ -486,7 +486,7 @@ fec_enet_tx(struct net_device *dev)
> }
> }
> fep->dirty_tx = bdp;
> - spin_unlock_irq(&fep->hw_lock);
> + spin_unlock(&fep->hw_lock);
> }
>
>
> @@ -509,7 +509,7 @@ fec_enet_rx(struct net_device *dev)
> flush_cache_all();
> #endif
>
> - spin_lock_irq(&fep->hw_lock);
> + spin_lock(&fep->hw_lock);
>
> /* First, grab all of the stats for the incoming packet.
> * These get messed up if we get called due to a busy condition.
> @@ -604,7 +604,7 @@ rx_processing_done:
> }
> fep->cur_rx = bdp;
>
> - spin_unlock_irq(&fep->hw_lock);
> + spin_unlock(&fep->hw_lock);
> }
>
> /* called from interrupt context */
> @@ -615,7 +615,7 @@ fec_enet_mii(struct net_device *dev)
> mii_list_t *mip;
>
> fep = netdev_priv(dev);
> - spin_lock_irq(&fep->mii_lock);
> + spin_lock(&fep->mii_lock);
>
> if ((mip = mii_head) == NULL) {
> printk("MII and no head!\n");
> @@ -633,7 +633,7 @@ fec_enet_mii(struct net_device *dev)
> writel(mip->mii_regval, fep->hwp + FEC_MII_DATA);
>
> unlock:
> - spin_unlock_irq(&fep->mii_lock);
> + spin_unlock(&fep->mii_lock);
> }
>
> static int
--
-----------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH 1/2] fec: fix recursive locking of mii_lock
From: Greg Ungerer @ 2009-09-03 1:16 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: linux-rt-users, Ben Hutchings, Patrick McHardy, Sascha Hauer,
Matt Waddel, netdev, Tim Sander
In-Reply-To: <1251882856-23549-1-git-send-email-u.kleine-koenig@pengutronix.de>
Hi Uwe,
Uwe Kleine-König wrote:
> mii_discover_phy is only called by fec_enet_mii (via mip->mii_func). So
> &fep->mii_lock is already held and mii_discover_phy must not call
> mii_queue which locks &fep->mii_lock, too.
>
> This was noticed by lockdep:
>
> =============================================
> [ INFO: possible recursive locking detected ]
> 2.6.31-rc8-00038-g37d0892 #109
> ---------------------------------------------
> swapper/1 is trying to acquire lock:
> (&fep->mii_lock){-.....}, at: [<c01569f8>] mii_queue+0x2c/0xcc
>
> but task is already holding lock:
> (&fep->mii_lock){-.....}, at: [<c0156328>] fec_enet_interrupt+0x78/0x460
>
> other info that might help us debug this:
> 2 locks held by swapper/1:
> #0: (rtnl_mutex){+.+.+.}, at: [<c0183534>] rtnl_lock+0x18/0x20
> #1: (&fep->mii_lock){-.....}, at: [<c0156328>] fec_enet_interrupt+0x78/0x460
>
> stack backtrace:
> Backtrace:
> [<c00226fc>] (dump_backtrace+0x0/0x108) from [<c01eac14>] (dump_stack+0x18/0x1c)
> r6:c781d118 r5:c03e41d8 r4:00000001
> [<c01eabfc>] (dump_stack+0x0/0x1c) from [<c005bae4>] (__lock_acquire+0x1a20/0x1a88)
> [<c005a0c4>] (__lock_acquire+0x0/0x1a88) from [<c005bbac>] (lock_acquire+0x60/0x74)
> [<c005bb4c>] (lock_acquire+0x0/0x74) from [<c01edda8>] (_spin_lock_irqsave+0x54/0x68)
> r7:60000093 r6:c01569f8 r5:c785e468 r4:00000000
> [<c01edd54>] (_spin_lock_irqsave+0x0/0x68) from [<c01569f8>] (mii_queue+0x2c/0xcc)
> r7:c785e468 r6:c0156b24 r5:600a0000 r4:c785e000
> [<c01569cc>] (mii_queue+0x0/0xcc) from [<c0156b78>] (mii_discover_phy+0x54/0xa8)
> r8:00000002 r7:00000032 r6:c785e000 r5:c785e360 r4:c785e000
> [<c0156b24>] (mii_discover_phy+0x0/0xa8) from [<c0156354>] (fec_enet_interrupt+0xa4/0x460)
> r5:c785e360 r4:c077a170
> [<c01562b0>] (fec_enet_interrupt+0x0/0x460) from [<c0066674>] (handle_IRQ_event+0x48/0x120)
> [<c006662c>] (handle_IRQ_event+0x0/0x120) from [<c0068438>] (handle_level_irq+0x94/0x11c)
> ...
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> Cc: Greg Ungerer <gerg@uclinux.org>
Looks good too.
Acked-by: Greg Ungerer <gerg@uclinux.org>
> Cc: Ben Hutchings <ben@decadent.org.uk>
> Cc: Patrick McHardy <kaber@trash.net>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Matt Waddel <Matt.Waddel@freescale.com>
> Cc: netdev@vger.kernel.org
> Cc: Tim Sander <tim01@vlsi.informatik.tu-darmstadt.de>
> ---
> drivers/net/fec.c | 22 +++++++++++++++++-----
> 1 files changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/fec.c b/drivers/net/fec.c
> index c9fd82d..ef82606 100644
> --- a/drivers/net/fec.c
> +++ b/drivers/net/fec.c
> @@ -637,16 +637,15 @@ unlock:
> }
>
> static int
> -mii_queue(struct net_device *dev, int regval, void (*func)(uint, struct net_device *))
> +mii_queue_unlocked(struct net_device *dev, int regval,
> + void (*func)(uint, struct net_device *))
> {
> struct fec_enet_private *fep;
> - unsigned long flags;
> mii_list_t *mip;
> int retval;
>
> /* Add PHY address to register command */
> fep = netdev_priv(dev);
> - spin_lock_irqsave(&fep->mii_lock, flags);
>
> regval |= fep->phy_addr << 23;
> retval = 0;
> @@ -667,6 +666,19 @@ mii_queue(struct net_device *dev, int regval, void (*func)(uint, struct net_devi
> retval = 1;
> }
>
> + return retval;
> +}
> +
> +static int
> +mii_queue(struct net_device *dev, int regval,
> + void (*func)(uint, struct net_device *))
> +{
> + struct fec_enet_private *fep;
> + unsigned long flags;
> + int retval;
> + fep = netdev_priv(dev);
> + spin_lock_irqsave(&fep->mii_lock, flags);
> + retval = mii_queue_unlocked(dev, regval, func);
> spin_unlock_irqrestore(&fep->mii_lock, flags);
> return retval;
> }
> @@ -1373,11 +1385,11 @@ mii_discover_phy(uint mii_reg, struct net_device *dev)
>
> /* Got first part of ID, now get remainder */
> fep->phy_id = phytype << 16;
> - mii_queue(dev, mk_mii_read(MII_REG_PHYIR2),
> + mii_queue_unlocked(dev, mk_mii_read(MII_REG_PHYIR2),
> mii_discover_phy3);
> } else {
> fep->phy_addr++;
> - mii_queue(dev, mk_mii_read(MII_REG_PHYIR1),
> + mii_queue_unlocked(dev, mk_mii_read(MII_REG_PHYIR1),
> mii_discover_phy);
> }
> } else {
--
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
^ permalink raw reply
* Re: Crypto oops in async_chainiv_do_postponed
From: Herbert Xu @ 2009-09-03 1:53 UTC (permalink / raw)
To: Brad Bosch; +Cc: linux-crypto, netdev, offbase0
In-Reply-To: <19103.1061.50828.809996@waldo.imnotcreative.homeip.net>
On Wed, Sep 02, 2009 at 06:47:49PM -0500, Brad Bosch wrote:
>
> Assume the worker thread is executing between the dequeue in
> async_chainiv_do_postponed and the clear_bit call in
> async_chainiv_schedule_work. Further assume that we are processing
> the last item on the queue so durring this time, ctx->queue.qlen =
> 0. **INUSE is still set at this point.
>
> Meanwhile, three threads enter async_chainiv_givencrypt for the same
> ctx at about the same time.
>
> Thread one calls test_and_set_bit which returns 1 and calls
> async_cahiniv_postpone_request but suppose it has not yet enqueued.
> Now INUSE is set and qlen=0.
>
> Next, the worker thread calls clear_bit in async_chainiv_schedule_work
> but it is interrupted before it can call test_and_set_bit. Now INUSE
> is clear and qlen=0
>
> The test_and_set_bit in thread two is called at this moment and
> returns 0 and then calls async_chainiv_givencrypt_tail. Now INUSE is
> set and qlen=0.
>
> Thread one now locks the ctx and calls skcipher_enqueue_givcrypt and
> unlocks. Now INUSE is set and qlen=1.
>
> Thread three calls test_and_set_bit which returns 1 and then it clears
> INUSE since qlen=1 and it calls postpone with INUSE clear and qlen=1
How can thread three clear INUSE if test_and_set_bit returned 1?
If thread three sees it set then it will postpone. It can only
clear it if it was not set originally.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC][PATCH][v5] net/ethtool: Add support for the ethtool feature to flash firmware image from a specified file.
From: Ajit Khaparde @ 2009-09-03 3:02 UTC (permalink / raw)
To: David Miller, jgarzik; +Cc: netdev
In-Reply-To: <20090902.144047.191136129.davem@davemloft.net>
On 02/09/09 14:40 -0700, David Miller wrote:
> From: Ajit Khaparde <ajitk@serverengines.com>
> Date: Wed, 2 Sep 2009 21:20:09 +0530
>
> > Is this patch good enough for being accepted? Please let me know if
> > any more work has to be done on this. Also, I want to send the
> > changes to the be2net driver which would use this ethtool feature.
>
> My impression was that the patch was still under review and
> people were still making change requests.
>
> I guess not :-)
>
> Please resubmit the kernel side patch, it'll get into patchwork
> and I'll apply it.
>
> Thanks.
Thanks David.
I am resending both the user space and the kernel side patches.
-Ajit
^ permalink raw reply
* [PATCH net-next-2.6] net/ethtool: Add support for the ethtool feature to flash firmware image from a specified file.
From: Ajit Khaparde @ 2009-09-03 3:02 UTC (permalink / raw)
To: davem, jgarzik; +Cc: netdev
This patch adds support to flash a firmware image to a device using ethtool.
The driver gets the filename of the firmware image and flashes the image
using the request firmware path.
The region "on the chip" to be flashed can be specified by an option.
It is upto the device driver to enumerate the region number passed by ethtool,
to the region to be flashed.
The default behavior is to flash all the regions on the chip.
Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
---
include/linux/ethtool.h | 14 ++++++++++++++
net/core/ethtool.c | 16 ++++++++++++++++
2 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index 90c4a36..15e4eb7 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -362,6 +362,18 @@ struct ethtool_rxnfc {
__u32 rule_locs[0];
};
+#define ETHTOOL_FLASH_MAX_FILENAME 128
+enum ethtool_flash_op_type {
+ ETHTOOL_FLASH_ALL_REGIONS = 0,
+};
+
+/* for passing firmware flashing related parameters */
+struct ethtool_flash {
+ __u32 cmd;
+ __u32 region;
+ char data[ETHTOOL_FLASH_MAX_FILENAME];
+};
+
#ifdef __KERNEL__
struct net_device;
@@ -489,6 +501,7 @@ struct ethtool_ops {
int (*get_stats_count)(struct net_device *);/* use get_sset_count */
int (*get_rxnfc)(struct net_device *, struct ethtool_rxnfc *, void *);
int (*set_rxnfc)(struct net_device *, struct ethtool_rxnfc *);
+ int (*flash_device)(struct net_device *, struct ethtool_flash *);
};
#endif /* __KERNEL__ */
@@ -545,6 +558,7 @@ struct ethtool_ops {
#define ETHTOOL_GRXCLSRLALL 0x00000030 /* Get all RX classification rule */
#define ETHTOOL_SRXCLSRLDEL 0x00000031 /* Delete RX classification rule */
#define ETHTOOL_SRXCLSRLINS 0x00000032 /* Insert RX classification rule */
+#define ETHTOOL_FLASHDEV 0x00000033 /* Flash firmware to device */
/* compatibility with older code */
#define SPARC_ETH_GSET ETHTOOL_GSET
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 44e5711..4c12ddb 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -898,6 +898,19 @@ static int ethtool_set_value(struct net_device *dev, char __user *useraddr,
return actor(dev, edata.data);
}
+static int ethtool_flash_device(struct net_device *dev, char __user *useraddr)
+{
+ struct ethtool_flash efl;
+
+ if (copy_from_user(&efl, useraddr, sizeof(efl)))
+ return -EFAULT;
+
+ if (!dev->ethtool_ops->flash_device)
+ return -EOPNOTSUPP;
+
+ return dev->ethtool_ops->flash_device(dev, &efl);
+}
+
/* The main entry point in this file. Called from net/core/dev.c */
int dev_ethtool(struct net *net, struct ifreq *ifr)
@@ -1111,6 +1124,9 @@ int dev_ethtool(struct net *net, struct ifreq *ifr)
case ETHTOOL_SGRO:
rc = ethtool_set_gro(dev, useraddr);
break;
+ case ETHTOOL_FLASHDEV:
+ rc = ethtool_flash_device(dev, useraddr);
+ break;
default:
rc = -EOPNOTSUPP;
}
--
1.6.0.4
^ permalink raw reply related
* [PATCH] ethtool: Add a new ethtool option to flash a firmware image from the specified file to a device.
From: Ajit Khaparde @ 2009-09-03 3:03 UTC (permalink / raw)
To: davem, jgarzik; +Cc: netdev
This patch adds a new "-f" option to the ethtool utility
to flash a firmware image specified by a file, to a network device.
The filename is passed to the network driver which will flash the image
on the chip using the request_firmware path.
The region "on the chip" to be flashed can be specified by an option.
It is upto the device driver to enumerate the region number passed by ethtool,
to the region to be flashed.
The default behavior is to flash all the regions on the chip.
Usage:
ethtool -f <interface name> <filename of firmware image>
ethtool -f <interface name> <filename of firmware image> [ REGION-NUMBER-TO-FLASH ]
Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
---
ethtool-copy.h | 13 +++++++++++++
ethtool.8 | 15 +++++++++++++++
ethtool.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-
3 files changed, 82 insertions(+), 1 deletions(-)
diff --git a/ethtool-copy.h b/ethtool-copy.h
index 3ca4e2c..66429e5 100644
--- a/ethtool-copy.h
+++ b/ethtool-copy.h
@@ -272,6 +272,18 @@ struct ethtool_perm_addr {
__u8 data[0];
};
+#define ETHTOOL_FLASH_MAX_FILENAME 128
+enum ethtool_flash_op_type {
+ ETHTOOL_FLASH_ALL_REGIONS = 0,
+};
+
+/* for passing firmware flashing related parameters */
+struct ethtool_flash {
+ __u32 cmd;
+ __u32 region;
+ char data[ETHTOOL_FLASH_MAX_FILENAME];
+};
+
/* boolean flags controlling per-interface behavior characteristics.
* When reading, the flag indicates whether or not a certain behavior
* is enabled/present. When writing, the flag indicates whether
@@ -338,6 +350,7 @@ struct ethtool_rxnfc {
#define ETHTOOL_SRXFH 0x0000002a /* Set RX flow hash configuration */
#define ETHTOOL_GGRO 0x0000002b /* Get GRO enable (ethtool_value) */
#define ETHTOOL_SGRO 0x0000002c /* Set GRO enable (ethtool_value) */
+#define ETHTOOL_FLASHDEV 0x00000033 /* Flash firmware to device */
/* compatibility with older code */
#define SPARC_ETH_GSET ETHTOOL_GSET
diff --git a/ethtool.8 b/ethtool.8
index 178f6ea..e42da55 100644
--- a/ethtool.8
+++ b/ethtool.8
@@ -207,6 +207,11 @@ ethtool \- Display or change ethernet card settings
.I ethX
.RB [ rx-flow-hash \ \*(FL
.RB \ \*(HO]
+
+.B ethtool \-f|\-\-flash
+.I ethX
+.RI FILE
+.RI [ N ]
.SH DESCRIPTION
.BI ethtool
is used for querying settings of an ethernet device and changing them.
@@ -501,6 +506,16 @@ Hash on bytes 2 and 3 of the Layer 4 header of the rx packet.
Discard all packets of this flow type. When this option is set, all other options are ignored.
.PD
.RE
+.TP
+.B \-f \-\-flash \ FILE
+Flash firmware image from the specified file to a region on the adapter.
+By default this will flash all the regions on the adapter.
+.TP
+.B N
+A number to identify flash region where the image should be flashed.
+Default region is 0 which denotes all regions in the flash.
+.PD
+.RE
.SH BUGS
Not supported (in part or whole) on all ethernet drivers.
.SH AUTHOR
diff --git a/ethtool.c b/ethtool.c
index 0110682..6b21bf2 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -77,6 +77,7 @@ static char *unparse_rxfhashopts(u64 opts);
static int dump_rxfhash(int fhash, u64 val);
static int do_srxclass(int fd, struct ifreq *ifr);
static int do_grxclass(int fd, struct ifreq *ifr);
+static int do_flash(int fd, struct ifreq *ifr);
static int send_ioctl(int fd, struct ifreq *ifr);
static enum {
@@ -101,6 +102,7 @@ static enum {
MODE_GSTATS,
MODE_GNFC,
MODE_SNFC,
+ MODE_FLASHDEV,
} mode = MODE_GSET;
static struct option {
@@ -192,6 +194,9 @@ static struct option {
"classification options",
" [ rx-flow-hash tcp4|udp4|ah4|sctp4|"
"tcp6|udp6|ah6|sctp6 p|m|v|t|s|d|f|n|r... ]\n" },
+ { "-f", "--flash", MODE_FLASHDEV, "FILENAME " "Flash firmware image "
+ "from the specified file to a region on the device",
+ " [ REGION-NUMBER-TO-FLASH ]\n" },
{ "-h", "--help", MODE_HELP, "Show this help" },
{}
};
@@ -304,6 +309,9 @@ static int rx_fhash_get = 0;
static int rx_fhash_set = 0;
static u32 rx_fhash_val = 0;
static int rx_fhash_changed = 0;
+static char *flash_file = NULL;
+static int flash = -1;
+static int flash_region = -1;
static enum {
ONLINE=0,
OFFLINE,
@@ -496,7 +504,8 @@ static void parse_cmdline(int argc, char **argp)
(mode == MODE_GSTATS) ||
(mode == MODE_GNFC) ||
(mode == MODE_SNFC) ||
- (mode == MODE_PHYS_ID)) {
+ (mode == MODE_PHYS_ID) ||
+ (mode == MODE_FLASHDEV)) {
devname = argp[i];
break;
}
@@ -516,6 +525,10 @@ static void parse_cmdline(int argc, char **argp)
if (phys_id_time < 0)
show_usage(1);
break;
+ } else if (mode == MODE_FLASHDEV) {
+ flash_file = argp[i];
+ flash = 1;
+ break;
}
/* fallthrough */
default:
@@ -590,6 +603,12 @@ static void parse_cmdline(int argc, char **argp)
show_usage(1);
break;
}
+ if (mode == MODE_FLASHDEV) {
+ flash_region = strtol(argp[i], NULL, 0);
+ if ((flash_region < 0))
+ show_usage(1);
+ break;
+ }
if (mode == MODE_SNFC) {
if (!strcmp(argp[i], "rx-flow-hash")) {
i += 1;
@@ -1504,6 +1523,8 @@ static int doit(void)
return do_grxclass(fd, &ifr);
} else if (mode == MODE_SNFC) {
return do_srxclass(fd, &ifr);
+ } else if (mode == MODE_FLASHDEV) {
+ return do_flash(fd, &ifr);
}
return 69;
@@ -2398,6 +2419,38 @@ static int do_grxclass(int fd, struct ifreq *ifr)
return 0;
}
+static int do_flash(int fd, struct ifreq *ifr)
+{
+ struct ethtool_flash efl;
+ int err;
+
+ if (flash < 0) {
+ fprintf(stdout, "Missing filename argument\n");
+ show_usage(1);
+ return 98;
+ }
+
+ if (strlen(flash_file) > ETHTOOL_FLASH_MAX_FILENAME - 1) {
+ fprintf(stdout, "Filename too long\n");
+ return 99;
+ }
+
+ efl.cmd = ETHTOOL_FLASHDEV;
+ strcpy(efl.data, flash_file);
+
+ if (flash_region < 0)
+ efl.region = ETHTOOL_FLASH_ALL_REGIONS;
+ else
+ efl.region = flash_region;
+
+ ifr->ifr_data = (caddr_t)&efl;
+ err = send_ioctl(fd, ifr);
+ if (err < 0)
+ perror("Flashing failed");
+
+ return err;
+}
+
static int send_ioctl(int fd, struct ifreq *ifr)
{
return ioctl(fd, SIOCETHTOOL, ifr);
--
1.6.0.4
^ permalink raw reply related
* [PATCH][RESEND] tcp: replace hard coded GFP_KERNEL with sk_allocation
From: Wu Fengguang @ 2009-09-03 4:04 UTC (permalink / raw)
To: David Miller
Cc: herbert@gondor.apana.org.au, Arnaldo Carvalho de Melo,
linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org,
netdev@vger.kernel.org
This fixed a lockdep warning which appeared when doing stress
memory tests over NFS:
inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage.
page reclaim => nfs_writepage => tcp_sendmsg => lock sk_lock
mount_root => nfs_root_data => tcp_close => lock sk_lock =>
tcp_send_fin => alloc_skb_fclone => page reclaim
David raised a concern that if the allocation fails in tcp_send_fin(), and it's
GFP_ATOMIC, we are going to yield() (which sleeps) and loop endlessly waiting
for the allocation to succeed.
But fact is, the original GFP_KERNEL also sleeps. GFP_ATOMIC+yield() looks
weird, but it is no worse the implicit sleep inside GFP_KERNEL. Both could
loop endlessly under memory pressure.
CC: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
CC: David S. Miller <davem@davemloft.net>
CC: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
---
net/ipv4/tcp.c | 4 ++--
net/ipv4/tcp_ipv4.c | 5 +++--
net/ipv4/tcp_output.c | 5 +++--
3 files changed, 8 insertions(+), 6 deletions(-)
--- linux.orig/net/ipv4/tcp_ipv4.c
+++ linux/net/ipv4/tcp_ipv4.c
@@ -970,8 +970,9 @@ static int tcp_v4_parse_md5_keys(struct
if (!tcp_sk(sk)->md5sig_info) {
struct tcp_sock *tp = tcp_sk(sk);
- struct tcp_md5sig_info *p = kzalloc(sizeof(*p), GFP_KERNEL);
+ struct tcp_md5sig_info *p;
+ p = kzalloc(sizeof(*p), sk->sk_allocation);
if (!p)
return -EINVAL;
@@ -979,7 +980,7 @@ static int tcp_v4_parse_md5_keys(struct
sk->sk_route_caps &= ~NETIF_F_GSO_MASK;
}
- newkey = kmemdup(cmd.tcpm_key, cmd.tcpm_keylen, GFP_KERNEL);
+ newkey = kmemdup(cmd.tcpm_key, cmd.tcpm_keylen, sk->sk_allocation);
if (!newkey)
return -ENOMEM;
return tcp_v4_md5_do_add(sk, sin->sin_addr.s_addr,
--- linux.orig/net/ipv4/tcp_output.c
+++ linux/net/ipv4/tcp_output.c
@@ -2100,7 +2100,8 @@ void tcp_send_fin(struct sock *sk)
} else {
/* Socket is locked, keep trying until memory is available. */
for (;;) {
- skb = alloc_skb_fclone(MAX_TCP_HEADER, GFP_KERNEL);
+ skb = alloc_skb_fclone(MAX_TCP_HEADER,
+ sk->sk_allocation);
if (skb)
break;
yield();
@@ -2358,7 +2359,7 @@ int tcp_connect(struct sock *sk)
sk->sk_wmem_queued += buff->truesize;
sk_mem_charge(sk, buff->truesize);
tp->packets_out += tcp_skb_pcount(buff);
- tcp_transmit_skb(sk, buff, 1, GFP_KERNEL);
+ tcp_transmit_skb(sk, buff, 1, sk->sk_allocation);
/* We change tp->snd_nxt after the tcp_transmit_skb() call
* in order to make this packet get counted in tcpOutSegs.
--- linux.orig/net/ipv4/tcp.c
+++ linux/net/ipv4/tcp.c
@@ -1834,7 +1834,7 @@ void tcp_close(struct sock *sk, long tim
/* Unread data was tossed, zap the connection. */
NET_INC_STATS_USER(sock_net(sk), LINUX_MIB_TCPABORTONCLOSE);
tcp_set_state(sk, TCP_CLOSE);
- tcp_send_active_reset(sk, GFP_KERNEL);
+ tcp_send_active_reset(sk, sk->sk_allocation);
} else if (sock_flag(sk, SOCK_LINGER) && !sk->sk_lingertime) {
/* Check zero linger _after_ checking for unread data. */
sk->sk_prot->disconnect(sk, 0);
@@ -2666,7 +2666,7 @@ static struct tcp_md5sig_pool **__tcp_al
struct tcp_md5sig_pool *p;
struct crypto_hash *hash;
- p = kzalloc(sizeof(*p), GFP_KERNEL);
+ p = kzalloc(sizeof(*p), sk->sk_allocation);
if (!p)
goto out_free;
*per_cpu_ptr(pool, cpu) = p;
^ permalink raw reply
* Re: [PATCH net-next-2.6] net/ethtool: Add support for the ethtool feature to flash firmware image from a specified file.
From: Jeff Garzik @ 2009-09-03 5:33 UTC (permalink / raw)
To: Ajit Khaparde; +Cc: davem, netdev
In-Reply-To: <20090903030241.GA19390@serverengines.com>
On 09/02/2009 11:02 PM, Ajit Khaparde wrote:
> This patch adds support to flash a firmware image to a device using ethtool.
> The driver gets the filename of the firmware image and flashes the image
> using the request firmware path.
>
> The region "on the chip" to be flashed can be specified by an option.
> It is upto the device driver to enumerate the region number passed by ethtool,
> to the region to be flashed.
>
> The default behavior is to flash all the regions on the chip.
>
> Signed-off-by: Ajit Khaparde<ajitk@serverengines.com>
> ---
> include/linux/ethtool.h | 14 ++++++++++++++
> net/core/ethtool.c | 16 ++++++++++++++++
> 2 files changed, 30 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> index 90c4a36..15e4eb7 100644
> --- a/include/linux/ethtool.h
> +++ b/include/linux/ethtool.h
> @@ -362,6 +362,18 @@ struct ethtool_rxnfc {
> __u32 rule_locs[0];
> };
>
> +#define ETHTOOL_FLASH_MAX_FILENAME 128
> +enum ethtool_flash_op_type {
> + ETHTOOL_FLASH_ALL_REGIONS = 0,
> +};
> +
> +/* for passing firmware flashing related parameters */
> +struct ethtool_flash {
> + __u32 cmd;
> + __u32 region;
> + char data[ETHTOOL_FLASH_MAX_FILENAME];
> +};
It passes a _filepath_ directly into the kernel? That seems quite wrong...
we fixed kernel drivers to _not_ think they could read directly from the
userland filesystem many years ago.
Seems like passing in an mmap'd fd would be far preferable.
Jeff
^ permalink raw reply
* Re: [PATCH net-next-2.6] net/ethtool: Add support for the ethtool feature to flash firmware image from a specified file.
From: David Miller @ 2009-09-03 5:43 UTC (permalink / raw)
To: jgarzik; +Cc: ajitk, netdev
In-Reply-To: <4A9F550D.1090105@pobox.com>
From: Jeff Garzik <jgarzik@pobox.com>
Date: Thu, 03 Sep 2009 01:33:01 -0400
> It passes a _filepath_ directly into the kernel? That seems quite
> wrong...
>
> we fixed kernel drivers to _not_ think they could read directly from
> the userland filesystem many years ago.
>
> Seems like passing in an mmap'd fd would be far preferable.
Jeff, it's passing in something that's going to requested via
the firmware loading infrastructure in the kernel.
It is the most appropriate way to do this.
^ permalink raw reply
* Re: [PATCH] tc: Fix unitialized kernel memory leak
From: David Miller @ 2009-09-03 5:51 UTC (permalink / raw)
To: shemminger; +Cc: eric.dumazet, netdev
In-Reply-To: <20090902120540.34e2a198@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 2 Sep 2009 12:05:40 -0700
> On Wed, 02 Sep 2009 14:40:09 +0200
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>> Three bytes of uninitialized kernel memory are currently leaked to user
>>
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>> ---
>> diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
>> index 24d17ce..fdb694e 100644
>> --- a/net/sched/sch_api.c
>> +++ b/net/sched/sch_api.c
>> @@ -1456,6 +1456,8 @@ static int tc_fill_tclass(struct sk_buff *skb, struct Qdisc *q,
>> nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*tcm), flags);
>> tcm = NLMSG_DATA(nlh);
>> tcm->tcm_family = AF_UNSPEC;
>> + tcm->tcm__pad1 = 0;
>> + tcm->tcm__pad2 = 0;
>> tcm->tcm_ifindex = qdisc_dev(q)->ifindex;
>> tcm->tcm_parent = q->handle;
>> tcm->tcm_handle = q->handle;
>
> Perhaps __nlmsg_put should just always call memset() for the whole
> added chunk. It is not like it is critical path in any way, and
> avoid any of this possible class of errors.
Doing it in __nlmsg_put would effect a lot of code paths. I don't
think you can say with certainty that it won't matter, tree wide.
What about things like the netfilter conntrack event monitor? Doesn't
that emit hundreds of thousands of events per second on a busy
firewall?
^ permalink raw reply
* Re: [PATCH] tc: Fix unitialized kernel memory leak
From: David Miller @ 2009-09-03 5:51 UTC (permalink / raw)
To: jpirko; +Cc: eric.dumazet, netdev
In-Reply-To: <20090902180935.GA2849@psychotron.redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Wed, 2 Sep 2009 20:09:36 +0200
> Wed, Sep 02, 2009 at 02:40:09PM CEST, eric.dumazet@gmail.com wrote:
>>Three bytes of uninitialized kernel memory are currently leaked to user
>>
>>Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Reviewed-by: Jiri Pirko <jpirko@redhat.com>
I'll apply this to net-2.6, thanks everyone.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net/ethtool: Add support for the ethtool feature to flash firmware image from a specified file.
From: Jeff Garzik @ 2009-09-03 5:55 UTC (permalink / raw)
To: Ajit Khaparde, davem; +Cc: netdev
In-Reply-To: <4A9F550D.1090105@pobox.com>
On 09/03/2009 01:33 AM, Jeff Garzik wrote:
>> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
>> index 90c4a36..15e4eb7 100644
>> --- a/include/linux/ethtool.h
>> +++ b/include/linux/ethtool.h
>> @@ -362,6 +362,18 @@ struct ethtool_rxnfc {
>> __u32 rule_locs[0];
>> };
>>
>> +#define ETHTOOL_FLASH_MAX_FILENAME 128
>> +enum ethtool_flash_op_type {
>> + ETHTOOL_FLASH_ALL_REGIONS = 0,
>> +};
>> +
>> +/* for passing firmware flashing related parameters */
>> +struct ethtool_flash {
>> + __u32 cmd;
>> + __u32 region;
>> + char data[ETHTOOL_FLASH_MAX_FILENAME];
>> +};
>
> It passes a _filepath_ directly into the kernel? That seems quite wrong...
doh, nevermind. Catching up...
Jeff
^ permalink raw reply
* [GIT]: Networking
From: David Miller @ 2009-09-03 6:02 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Packet scheduler classifier code can leak some uninitialized
kernel bytes to userspace. Fix from Eric Dumazet.
2) Revert tasklet_hrtimer conversions, naggling problems exist
and -rcX is not the time to be tinkering with it.
3) Sockets can leak when sk_free()'d shortly after sk_alloc()
with some protocols due to initialization order of
sk->sk_mem_alloc. Fix from Jarek Poplawski and Eric Dumazet.
4) gianfar frees netdev without unregistering it resulting in
crashes on unload. Fix from Toru UCHIYAMA.
5) ipw2200 uses large linear memory area (ie. high order allocation)
for firmware loading via DMA, which easily can (and does) fail.
Fix from Zhu Yi via John Linville.
Please pull, thanks a lot!
The following changes since commit 37d0892c5a94e208cf863e3b7bac014edee4346d:
Ian Kent (1):
autofs4 - fix missed case when changing to use struct path
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
David S. Miller (2):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
pkt_sched: Revert tasklet_hrtimer changes.
Eric Dumazet (1):
tc: Fix unitialized kernel memory leak
Jarek Poplawski (1):
net: sk_free() should be allowed right after sk_alloc()
Toru UCHIYAMA (1):
gianfar: gfar_remove needs to call unregister_netdev()
Zhu Yi (1):
ipw2200: firmware DMA loading rework
drivers/net/gianfar.c | 1 +
drivers/net/wireless/ipw2x00/ipw2200.c | 120 ++++++++++++++++++--------------
include/net/pkt_sched.h | 4 +-
net/core/sock.c | 2 +-
net/sched/sch_api.c | 12 ++--
net/sched/sch_cbq.c | 25 +++----
6 files changed, 89 insertions(+), 75 deletions(-)
^ permalink raw reply
* Re: [PATCH net-next-2.6] drivers: Kill now superfluous ->last_rx stores
From: David Miller @ 2009-09-03 6:09 UTC (permalink / raw)
To: eric.dumazet; +Cc: nhorman, netdev
In-Reply-To: <4A9BFBAA.10705@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 31 Aug 2009 18:34:50 +0200
> Eric Dumazet a écrit :
>> Neil Horman a écrit :
>>> I still see a large number of drivers that update dev->last_rx, although its
>>> not all as I look through the list, so something definately seems amiss.
>>
>> Some drivers still update dev->last_rx for their own needs, not a core
>> network concern.
>>
>> But a cleanup is certainly possible on few other drivers, about a dozen
>> if I count correctly.
>
> Well, a litle bit more if we look outside of drivers/net
>
> [PATCH net-next-2.6] drivers: Kill now superfluous ->last_rx stores
>
> The generic packet receive code takes care of setting
> netdev->last_rx when necessary, for the sake of the
> bonding ARP monitor.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net/ethtool: Add support for the ethtool feature to flash firmware image from a specified file.
From: David Miller @ 2009-09-03 6:10 UTC (permalink / raw)
To: ajitk; +Cc: jgarzik, netdev
In-Reply-To: <20090903030241.GA19390@serverengines.com>
From: Ajit Khaparde <ajitk@serverengines.com>
Date: Thu, 3 Sep 2009 08:32:55 +0530
> This patch adds support to flash a firmware image to a device using ethtool.
> The driver gets the filename of the firmware image and flashes the image
> using the request firmware path.
>
> The region "on the chip" to be flashed can be specified by an option.
> It is upto the device driver to enumerate the region number passed by ethtool,
> to the region to be flashed.
>
> The default behavior is to flash all the regions on the chip.
>
> Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH][RESEND] tcp: replace hard coded GFP_KERNEL with sk_allocation
From: David Miller @ 2009-09-03 6:10 UTC (permalink / raw)
To: fengguang.wu-ral2JQCrhuEAvxtiuMwx3w
Cc: herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q,
acme-f8uhVLnGfZaxAyOMLChx1axOck334EZe,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20090903040407.GA20094@localhost>
From: Wu Fengguang <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date: Thu, 3 Sep 2009 12:04:07 +0800
> This fixed a lockdep warning which appeared when doing stress
> memory tests over NFS:
>
> inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage.
>
> page reclaim => nfs_writepage => tcp_sendmsg => lock sk_lock
>
> mount_root => nfs_root_data => tcp_close => lock sk_lock =>
> tcp_send_fin => alloc_skb_fclone => page reclaim
>
> David raised a concern that if the allocation fails in tcp_send_fin(), and it's
> GFP_ATOMIC, we are going to yield() (which sleeps) and loop endlessly waiting
> for the allocation to succeed.
>
> But fact is, the original GFP_KERNEL also sleeps. GFP_ATOMIC+yield() looks
> weird, but it is no worse the implicit sleep inside GFP_KERNEL. Both could
> loop endlessly under memory pressure.
>
> CC: Arnaldo Carvalho de Melo <acme-f8uhVLnGfZaxAyOMLChx1axOck334EZe@public.gmane.org>
> CC: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> CC: Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
> Signed-off-by: Wu Fengguang <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Applied to net-next-2.6, thanks!
--
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
* Re: [PATCH] NET: Fix possible corruption in bpqether driver
From: David Miller @ 2009-09-03 6:10 UTC (permalink / raw)
To: ralf; +Cc: netdev, linux-hams, thomas, jann
In-Reply-To: <20090902085841.GA5910@linux-mips.org>
From: Ralf Baechle <ralf@linux-mips.org>
Date: Wed, 2 Sep 2009 09:58:52 +0100
> The bpq ether driver is modifying the data art of the skb by first
> dropping the KISS byte (a command byte for the radio) then prepending the
> length + 4 of the remaining AX.25 packet to be transmitted as a little
> endian 16-bit number. If the high byte of the length has a different
> value than the dropped KISS byte users of clones of the skb may observe
> this as corruption. This was observed with by running listen(8) -a which
> uses a packet socket which clones transmit packets. The corruption will
> then typically be displayed for as a KISS "TX Delay" command for AX.25
> packets in the range of 252..508 bytes or any other KISS command for
> yet larger packets.
>
> Fixed by using skb_cow to create a private copy should the skb be cloned.
> Using skb_cow also allows us to cleanup the old logic to ensure sufficient
> headroom in the skb.
>
> While at it, replace a return of 0 from bpq_xmit with the proper constant
> NETDEV_TX_OK which is now being used everywhere else in this function.
>
> Affected: all 2.2, 2.4 and 2.6 kernels.
>
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
> Reported-by: Jann Traschewski <jann@gmx.de>
Applied to net-next-2.6, thanks!
^ permalink raw reply
* Re: [PATCH] WARNING: some request_irq() failures ignored in el2_open()
From: David Miller @ 2009-09-03 6:10 UTC (permalink / raw)
To: roel.kluin; +Cc: netdev, akpm
In-Reply-To: <4A9D4AD5.1010404@gmail.com>
From: Roel Kluin <roel.kluin@gmail.com>
Date: Tue, 01 Sep 2009 18:24:53 +0200
> Request_irq() may fail in different ways, handle accordingly.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
> Don't we have to do something like this?
Looks good, applied to net-next-2.6, thanks!
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox