All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarek Poplawski <jarkao2@gmail.com>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: David Miller <davem@davemloft.net>,
	emil.s.tantilov@intel.com, jeffrey.t.kirsher@intel.com,
	netdev@vger.kernel.org
Subject: Re: [BUG] NULL pointer dereference in skb_dequeue
Date: Tue, 12 Aug 2008 06:36:22 +0000	[thread overview]
Message-ID: <20080812063622.GA5066@ff.dom.local> (raw)
In-Reply-To: <20080811232657.GQ6762@linux.vnet.ibm.com>

On Mon, Aug 11, 2008 at 04:26:57PM -0700, Paul E. McKenney wrote:
> On Mon, Aug 11, 2008 at 10:01:26AM +0000, Jarek Poplawski wrote:
> > On 10-08-2008 21:04, Jarek Poplawski wrote:
> > ...
> > > Hmm.. Actually, it's completely unreasonable. Let's forget this.
> > 
> > But accidentally it might even sometimes work here...
> > 
> > Currently, the most suspicious place to me seems to be
> > __netif_schedule(). Is it legal to store RCU protected pointers out of
> > rcu_read_lock() sections?
> 
> Yes, but:
> 
> 1.	You need to use one of the update-side primitives to do the
> 	store: rcu_assign_pointer(), list_add_rcu(), etc.
> 
> 2.	There has to be some way for multiple updaters to coordinate,
> 	for example:
> 
> 	a.	Only a single task is permitted to update.
> 
> 	b.	Locking is used to coordinate among multiple updaters
> 		(so that only one such updater may proceed at a given
> 		time).
> 
> 	c.	Atomic operations are used to coordinate multiple
> 		updaters.  Here be dragons, go for (a) or (b)
> 		instead unless you have an extremely good reason
> 		-and- you have both a proof of correctness and
> 		a totally brutal and malign test suite.
> 
> The main reason to update RCU-protected pointers within rcu_read_lock()
> regions is when sharing code between RCU readers and updaters, or when
> an RCU reader can see the need to do an update.

Sure, but I'm concerned here with pure RCU reading:

>From net/sched/sch_generic.c:

void __qdisc_run(struct Qdisc *q)
{
        unsigned long start_time = jiffies;

        while (qdisc_restart(q)) {
                /*
                 * Postpone processing if
                 * 1. another process needs the CPU;
                 * 2. we've been doing it for too long.
                 */
                if (need_resched() || jiffies != start_time) {
                        __netif_schedule(q);

This function is run from dev_queue_xmit() (net/core/dev.c) under
rcu_read_lock_bh(), and this "q" pointer is passed here for later use
(reading) by softirq run net_tx_action(). Alas in net/ RCU primitives
are probably omitted in a few places...

Thanks for the explanation,
Jarek P.

                        break;
                }
        }

        clear_bit(__QDISC_STATE_RUNNING, &q->state);
}

  reply	other threads:[~2008-08-12  6:36 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-01 23:40 [BUG] NULL pointer dereference in skb_dequeue Jeff Kirsher
2008-08-02  1:03 ` David Miller
2008-08-02  1:20   ` David Miller
2008-08-02  9:36     ` Tantilov, Emil S
2008-08-02 13:37       ` Jarek Poplawski
2008-08-02 16:27         ` Jarek Poplawski
2008-08-02 19:18           ` David Miller
2008-08-02 19:22             ` David Miller
2008-08-02 19:45               ` Tantilov, Emil S
2008-08-02 21:46                 ` Tantilov, Emil S
2008-08-03  2:26                   ` David Miller
2008-08-08 19:38                     ` Tantilov, Emil S
2008-08-09  7:29                       ` David Miller
2008-08-09 22:32                         ` Jarek Poplawski
2008-08-10 19:04                           ` Jarek Poplawski
2008-08-11 10:01                             ` Jarek Poplawski
2008-08-11 23:26                               ` Paul E. McKenney
2008-08-12  6:36                                 ` Jarek Poplawski [this message]
2008-08-12 13:42                                   ` Paul E. McKenney
2008-08-12 18:09                                     ` Jarek Poplawski
2008-08-12 20:18                                       ` Paul E. McKenney
2008-08-12 21:15                                         ` Jarek Poplawski
2008-08-12 22:33                                           ` Paul E. McKenney
2008-08-02 20:19             ` Jarek Poplawski
2008-08-03  9:29               ` Jarek Poplawski
2008-08-03  9:50                 ` Jarek Poplawski
2008-08-03  9:56                 ` David Miller
2008-08-03 10:08                   ` Jarek Poplawski

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=20080812063622.GA5066@ff.dom.local \
    --to=jarkao2@gmail.com \
    --cc=davem@davemloft.net \
    --cc=emil.s.tantilov@intel.com \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    /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.