All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Anirban Sinha <ani@anirban.org>
Cc: linux-kernel@vger.kernel.org, David Miller <davem@davemloft.net>,
	netdev@vger.kernel.org, Anirban Sinha <asinha@zeugmasystems.com>
Subject: Re: Kernel oops when clearing bgp neighbor info with TCP MD5SUM enabled
Date: Mon, 19 Oct 2009 14:13:27 +0200	[thread overview]
Message-ID: <20091019121327.GA11423@redhat.com> (raw)
In-Reply-To: <4ADB7856.7000803@anirban.org>

Hi Anirban,

On 10/18, Anirban Sinha wrote:
>
> I have a question for you. The queue_work() routine which is called from
> schedule_work() does a put_cpu() which in turn does a enable_preempt(). Is
> this an attempt to trigger the scheduler?

No. please note that queue_work() does get_cpu() + put_cpu() to protect
against cpu_down() in between.

This can trigger the scheduler of course, but everything should be OK.

> One of the side affects of
> this enable_preempt() is the crash that we see below. What is happening
> is that  a timer callback routine, in  this case inet_twdr_hangman(),
> tries a bunch of cleanup until a threshold is reached. If further cleanups
> needs to be done beyond the threshold, it queues a work function. Now when
> the timer callback is run in __run_timers(), the routine grabs the value
> of preempt_count before and after the callback function call. If the two
> counts do not match, it calls BUG() (line 1037 in kernel/timer.c).

Yes, but I can't see how queue_work() can be involved, it doesn't change
->preempt_count. Note again it does put after get.

> Is is
> it illegal to schedule a work function from within a timer callback?

Yes sure.

I'd suppose that this unbalance comes from inet_twdr_hangman() pathes.

Could you verify this?

Oleg.


  reply	other threads:[~2009-10-19 12:18 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-08 22:19 Kernel oops when clearing bgp neighbor info with TCP MD5SUM enabled Anirban Sinha
2009-10-08 22:54 ` David Miller
2009-10-08 23:33   ` Anirban Sinha
2009-10-09  0:57     ` David Miller
2009-10-17 17:57       ` Anirban Sinha
2009-10-18  2:35         ` Anirban Sinha
2009-10-18 20:19           ` Anirban Sinha
2009-10-18 20:19             ` Anirban Sinha
2009-10-19 12:13             ` Oleg Nesterov [this message]
2009-10-19 15:32               ` Anirban Sinha
2009-10-19 15:36                 ` Oleg Nesterov
2009-10-19 16:01                   ` Anirban Sinha
2009-10-20  0:56               ` Anirban Sinha
2009-10-20  1:08                 ` [PATCH] " Anirban Sinha
2009-10-20  1:13                   ` David Miller
2009-10-20  1:17                     ` Anirban Sinha

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091019121327.GA11423@redhat.com \
    --to=oleg@redhat.com \
    --cc=ani@anirban.org \
    --cc=asinha@zeugmasystems.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.