[PATCH] Re: [NETPOLL] netconsole: fix soft lockup when removing module

From my recent patch:

quoted

   #1
   Until kernel ver. 2.6.21 (including) cancel_rearming_delayed_work()
   required a work function should always (unconditionally) rearm with
   delay > 0 - otherwise it would endlessly loop. This patch replaces
   this function with cancel_delayed_work(). Later kernel versions don't
   require this, so here it's only for uniformity.

But Oleg Nesterov [off-list ref] found:

But 2.6.22 doesn't need this change, why it was merged?

In fact, I suspect this change adds a race,

...

His description was right (thanks), so this patch reverts #1.

Signed-off-by: Jarek Poplawski <redacted>

---

diff -Nurp 2.6.22-rc7-/net/core/netpoll.c 2.6.22-rc7/net/core/netpoll.c

--- 2.6.22-rc7-/net/core/netpoll.c	2007-07-02 09:03:27.000000000 +0200
+++ 2.6.22-rc7/net/core/netpoll.c	2007-07-02 09:32:34.000000000 +0200

@@ -72,8 +72,7 @@ static void queue_process(struct work_st
 			netif_tx_unlock(dev);
 			local_irq_restore(flags);
 
-			if (atomic_read(&npinfo->refcnt))
-				schedule_delayed_work(&npinfo->tx_work, HZ/10);
+			schedule_delayed_work(&npinfo->tx_work, HZ/10);
 			return;
 		}
 		netif_tx_unlock(dev);

@@ -786,7 +785,7 @@ void netpoll_cleanup(struct netpoll *np)
 			if (atomic_dec_and_test(&npinfo->refcnt)) {
 				skb_queue_purge(&npinfo->arp_tx);
 				skb_queue_purge(&npinfo->txq);
-				cancel_delayed_work(&npinfo->tx_work);
+				cancel_rearming_delayed_work(&npinfo->tx_work);
 				flush_scheduled_work();
 
 				/* clean after last, unfinished work */

On 07/02, Jarek Poplawski wrote:

While you are here, could you also delete this flush_scheduled_work() ?
It is not needed any longer.

Oleg.

On Mon, Jul 02, 2007 at 12:59:49PM +0400, Oleg Nesterov wrote:
...

While you are here, could you also delete this flush_scheduled_work() ?
It is not needed any longer.

Yes. I've thought about this, and even planned to mention, but then
forgotten... Of course, you are right, but since it stayed so long
and doesn't seem to be dangerous, and there is -rc7 I wasn't so brave.
But now I have an explanation...

Jarek P.

---------->

Subject: [PATCH][NETPOLL] netconsole: delete flush_scheduled_work

flush_scheduled_work() isn't needed after cancel_rearming_delayed_work(),
so here it's removed from netpoll_cleanup().

PS: This patch was prepared on 2.6.22-rc7 with my other today's patch:
netconsole: fix soft lockup ...

Noticed-by: Oleg Nesterov [off-list ref]

Signed-off-by: Jarek Poplawski <redacted>

---

diff -Nurp 2.6.22-rc7-plus-revert1-/net/core/netpoll.c 2.6.22-rc7-plus-revert1/net/core/netpoll.c

--- 2.6.22-rc7-plus-revert1-/net/core/netpoll.c	2007-07-02 09:32:34.000000000 +0200
+++ 2.6.22-rc7-plus-revert1/net/core/netpoll.c	2007-07-02 11:43:29.000000000 +0200

@@ -786,7 +786,6 @@ void netpoll_cleanup(struct netpoll *np)
 				skb_queue_purge(&npinfo->arp_tx);
 				skb_queue_purge(&npinfo->txq);
 				cancel_rearming_delayed_work(&npinfo->tx_work);
-				flush_scheduled_work();
 
 				/* clean after last, unfinished work */
 				if (!skb_queue_empty(&npinfo->txq)) {

On Mon, Jul 02, 2007 at 09:52:26AM +0200, Jarek Poplawski wrote:

From my recent patch:

quoted

quoted

   #1
   Until kernel ver. 2.6.21 (including) cancel_rearming_delayed_work()
   required a work function should always (unconditionally) rearm with
   delay > 0 - otherwise it would endlessly loop. This patch replaces
   this function with cancel_delayed_work(). Later kernel versions don't
   require this, so here it's only for uniformity.

But Oleg Nesterov [off-list ref] found:

quoted

But 2.6.22 doesn't need this change, why it was merged?

In fact, I suspect this change adds a race,

...

His description was right (thanks), so this patch reverts #1.

Signed-off-by: Jarek Poplawski <redacted>

Oleg,

I think maybe you could ack these 2 netconsole patches...
They were done on your request but it looks like Andrew
is waiting on something...

Thanks,
Jarek P.

From: Jarek Poplawski <redacted>
Date: Wed, 4 Jul 2007 08:41:59 +0200

On Mon, Jul 02, 2007 at 09:52:26AM +0200, Jarek Poplawski wrote:

quoted

From my recent patch:

quoted

quoted

   #1
   Until kernel ver. 2.6.21 (including) cancel_rearming_delayed_work()
   required a work function should always (unconditionally) rearm with
   delay > 0 - otherwise it would endlessly loop. This patch replaces
   this function with cancel_delayed_work(). Later kernel versions don't
   require this, so here it's only for uniformity.

But Oleg Nesterov [off-list ref] found:

quoted

But 2.6.22 doesn't need this change, why it was merged?

In fact, I suspect this change adds a race,

...

His description was right (thanks), so this patch reverts #1.

Signed-off-by: Jarek Poplawski <redacted>

Oleg,

I think maybe you could ack these 2 netconsole patches...
They were done on your request but it looks like Andrew
is waiting on something...

I plan to apply this patch, don't worry about it :)

On Tue, Jul 03, 2007 at 11:47:18PM -0700, David Miller wrote:
...

I plan to apply this patch, don't worry about it :)

 
Now I'm really worried! Don't you evere sleep?

Good night,
Jarek P.

On Wed, Jul 04, 2007 at 08:41:59AM +0200, Jarek Poplawski wrote:
...

They were done on your request but it looks like Andrew
is waiting on something...

Andrew,

This time I'm not sorry for my English because I've just
found I could speak "Chiefly Midland and Southern U.S.".

Jarek P.