Prev: uml: Remove unused variable from line driver
Next: [PATCH] Mass Storage Gadget: Handle eject request
From: David Miller on 27 Apr 2010 19:50
From: "Paul E. McKenney" <paulmck(a)linux.vnet.ibm.com>
Date: Tue, 27 Apr 2010 16:31:11 -0700

> Thank you both! I have added Eric's Acked-by and Miles's Tested-by.

How can you? It's in net-next-2.6 already :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Paul E. McKenney on 27 Apr 2010 20:00
On Tue, Apr 27, 2010 at 04:42:39PM -0700, David Miller wrote:
> From: "Paul E. McKenney" <paulmck(a)linux.vnet.ibm.com>
> Date: Tue, 27 Apr 2010 16:31:11 -0700
>
> > Thank you both! I have added Eric's Acked-by and Miles's Tested-by.
>
> How can you? It's in net-next-2.6 already :-)

OK, OK, I will drop my copy. ;-)

Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Paul E. McKenney on 28 Apr 2010 17:40
On Wed, Apr 28, 2010 at 04:58:54PM -0400, Miles Lane wrote:
> On Sat, Apr 24, 2010 at 10:34 PM, Paul E. McKenney <
> paulmck(a)linux.vnet.ibm.com> wrote:
> On Fri, Apr 23, 2010 at 06:59:12PM -0400, Miles Lane wrote:

[ . . . ]

> > commit 0868dd631def762ba00c2f0f397a53c5cdf24ae2
> > Author: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com>
> > Date: Sat Apr 24 19:23:30 2010 -0700
> >
> > block-cgroup: fix RCU-lockdep splat in blkiocg_add_blkio_group()
> >
> > It is necessary to be in an RCU read-side critical section when invoking
> > css_id(), so this patch adds one to blkiocg_add_blkio_group(). This is
> > actually a false positive, because this is called at initialization
> > time,
> > and hence always refers to the root cgroup, which cannot go away.
> >
> > Located-by: Miles Lane <miles.lane(a)gmail.com>
> > Suggested-by: Vivek Goyal <vgoyal(a)redhat.com>
> > Signed-off-by: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com>
> >
> > diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
> > index 5fe03de..55c8c73 100644
> > --- a/block/blk-cgroup.c
> > +++ b/block/blk-cgroup.c
> > @@ -71,7 +71,9 @@ void blkiocg_add_blkio_group(struct blkio_cgroup *blkcg,
> >
> > spin_lock_irqsave(&blkcg->lock, flags);
> > rcu_assign_pointer(blkg->key, key);
> > + rcu_read_lock();
> > blkg->blkcg_id = css_id(&blkcg->css);
> > + rcu_read_unlock();
> > hlist_add_head_rcu(&blkg->blkcg_node, &blkcg->blkg_list);
> > spin_unlock_irqrestore(&blkcg->lock, flags);
> > #ifdef CONFIG_DEBUG_BLK_CGROUP
> >
>
> Hi Paul,
> Did this patch make it into your patch set? Has your patch set gone into
> the Linus tree?
> I just tested 2.6.34-rc5-git8 and hit one of the issues again. I think this
> patch is intended to correct this issue?

I replaced the above with an improved patch from Vivek Goyal, which has
not yet reached mainline. I will resend my patch stack.

Thanx, Paul

> [ 2.289598] [ INFO: suspicious rcu_dereference_check() usage. ]
> [ 2.289604] ---------------------------------------------------
> [ 2.289610] kernel/cgroup.c:4438 invoked rcu_dereference_check() without
> protection!
> [ 2.289615]
> [ 2.289617] other info that might help us debug this:
> [ 2.289619]
> [ 2.289624]
> [ 2.289626] rcu_scheduler_active = 1, debug_locks = 1
> [ 2.289632] 2 locks held by async/1/575:
> [ 2.289637] #0: (&shost->scan_mutex){+.+.+.}, at: [<c121063d>]
> __scsi_add_device+0x5b/0xab
> [ 2.289660] #1: (&(&blkcg->lock)->rlock){......}, at: [<c1143acb>]
> blkiocg_add_blkio_group+0x1a/0x73
> [ 2.289678]
> [ 2.289680] stack backtrace:
> [ 2.289688] Pid: 575, comm: async/1 Not tainted 2.6.34-rc5-git8 #17
> [ 2.289693] Call Trace:
> [ 2.289704] [<c12ee273>] ? printk+0xf/0x14
> [ 2.289715] [<c1050fbd>] lockdep_rcu_dereference+0x74/0x7d
> [ 2.289725] [<c106227d>] css_id+0x37/0x46
> [ 2.289734] [<c1143adc>] blkiocg_add_blkio_group+0x2b/0x73
> [ 2.289744] [<c1146a19>] cfq_init_queue+0xd6/0x2a3
> [ 2.289755] [<c120d657>] ? scsi_request_fn+0x0/0x3ea
> [ 2.289764] [<c113a316>] elevator_init+0xa1/0xd5
> [ 2.289774] [<c113bc3f>] blk_init_queue_node+0x103/0x109
> [ 2.289783] [<c113bc50>] blk_init_queue+0xb/0xd
> [ 2.289792] [<c120da58>] __scsi_alloc_queue+0x17/0xef
> [ 2.289802] [<c120db40>] scsi_alloc_queue+0x10/0x49
> [ 2.289811] [<c120f381>] scsi_alloc_sdev+0x14f/0x1ef
> [ 2.289821] [<c120f617>] scsi_probe_and_add_lun+0xb5/0x7ed
> [ 2.289831] [<c10517dc>] ? trace_hardirqs_on_caller+0x119/0x141
> [ 2.289843] [<c1210669>] __scsi_add_device+0x87/0xab
> [ 2.289854] [<c1232dfe>] ata_scsi_scan_host+0x64/0x136
> [ 2.289865] [<c12312c3>] async_port_probe+0x9e/0xa4
> [ 2.289876] [<c10479c8>] async_thread+0xf0/0x1d4
> [ 2.289887] [<c102b474>] ? default_wake_function+0x0/0xd
> [ 2.289896] [<c10478d8>] ? async_thread+0x0/0x1d4
> [ 2.289906] [<c1041a2a>] kthread+0x6a/0x6f
> [ 2.289916] [<c10419c0>] ? kthread+0x0/0x6f
> [ 2.289926] [<c1003742>] kernel_thread_helper+0x6/0x1a
> [ 2.289934]
> [ 2.289935] ===================================================
> [ 2.289941] [ INFO: suspicious rcu_dereference_check() usage. ]
> [ 2.289946] ---------------------------------------------------
> [ 2.289951] kernel/cgroup.c:1651 invoked rcu_dereference_check() without
> protection!
> [ 2.289957]
> [ 2.289958] other info that might help us debug this:
> [ 2.289961]
> [ 2.289966]
> [ 2.289967] rcu_scheduler_active = 1, debug_locks = 1
> [ 2.289973] 1 lock held by async/1/575:
> [ 2.289978] #0: (&shost->scan_mutex){+.+.+.}, at: [<c121063d>]
> __scsi_add_device+0x5b/0xab
> [ 2.289995]
> [ 2.289996] stack backtrace:
> [ 2.290003] Pid: 575, comm: async/1 Not tainted 2.6.34-rc5-git8 #17
> [ 2.290008] Call Trace:
> [ 2.290016] [<c12ee273>] ? printk+0xf/0x14
> [ 2.290025] [<c1050fbd>] lockdep_rcu_dereference+0x74/0x7d
> [ 2.290035] [<c106423a>] cgroup_path+0x4a/0x110
> [ 2.290045] [<c1143b12>] blkiocg_add_blkio_group+0x61/0x73
> [ 2.290055] [<c1146a19>] cfq_init_queue+0xd6/0x2a3
> [ 2.290065] [<c120d657>] ? scsi_request_fn+0x0/0x3ea
> [ 2.290074] [<c113a316>] elevator_init+0xa1/0xd5
> [ 2.290083] [<c113bc3f>] blk_init_queue_node+0x103/0x109
> [ 2.290093] [<c113bc50>] blk_init_queue+0xb/0xd
> [ 2.290102] [<c120da58>] __scsi_alloc_queue+0x17/0xef
> [ 2.290111] [<c120db40>] scsi_alloc_queue+0x10/0x49
> [ 2.290120] [<c120f381>] scsi_alloc_sdev+0x14f/0x1ef
> [ 2.290131] [<c120f617>] scsi_probe_and_add_lun+0xb5/0x7ed
> [ 2.290140] [<c10517dc>] ? trace_hardirqs_on_caller+0x119/0x141
> [ 2.290152] [<c1210669>] __scsi_add_device+0x87/0xab
> [ 2.290162] [<c1232dfe>] ata_scsi_scan_host+0x64/0x136
> [ 2.290172] [<c12312c3>] async_port_probe+0x9e/0xa4
> [ 2.290182] [<c10479c8>] async_thread+0xf0/0x1d4
> [ 2.290192] [<c102b474>] ? default_wake_function+0x0/0xd
> [ 2.290202] [<c10478d8>] ? async_thread+0x0/0x1d4
> [ 2.290211] [<c1041a2a>] kthread+0x6a/0x6f
> [ 2.290221] [<c10419c0>] ? kthread+0x0/0x6f
> [ 2.290230] [<c1003742>] kernel_thread_helper+0x6/0x1a
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Paul E. McKenney on 1 May 2010 18:00
On Sat, May 01, 2010 at 01:26:15PM -0400, Miles Lane wrote:
> On Tue, Apr 20, 2010 at 9:52 AM, Paul E. McKenney
> <paulmck(a)linux.vnet.ibm.com> wrote:
> > On Tue, Apr 20, 2010 at 08:45:28AM -0400, Miles Lane wrote:
> >> Is there a patch set for 2.6.34-rc5 I can test?
> >
> > I will be sending a patchset out later today after testing, but
> > please see below for a sneak preview collapsed into a single patch.
> >
> > � � � � � � � � � � � � � � � � � � � � � � � � � � � �Thanx, Paul
> >
> >> On Tue, Apr 20, 2010 at 8:31 AM, Eric Paris <eparis(a)redhat.com> wrote:
> >>
> >> > On Tue, 2010-04-20 at 16:23 +0800, Lai Jiangshan wrote:
> >> >
> >> > > [PATCH] RCU: don't turn off lockdep when find suspicious
> >> > rcu_dereference_check() usage
> >> > >
> >> > > When suspicious rcu_dereference_check() usage is detected, lockdep is
> >> > still
> >> > > available actually, so we should not call debug_locks_off() in
> >> > > lockdep_rcu_dereference().
> >> > >
> >> > > For get rid of too much "suspicious rcu_dereference_check() usage"
> >> > > output when the "if(!debug_locks_off())" statement is removed. This patch
> >> > uses
> >> > > static variable '__warned's for very usage of "rcu_dereference*()".
> >> > >
> >> > > One variable per usage, so, Now, we can get multiple complaint
> >> > > when we detect multiple different suspicious rcu_dereference_check()
> >> > usage.
> >> > >
> >> > > Requested-by: Eric Paris <eparis(a)redhat.com>
> >> > > Signed-off-by: Lai Jiangshan <laijs(a)cn.fujitsu.com>
> >> >
> >> > Although mine was a linux-next kernel and it doesn't appear that I have
> >> > rcu_dereference_protected() at all, so I dropped that bit of the patch,
> >> > it worked great! �I got 4 more complaints to harass people with. �Feel
> >> > free to add my tested by if you care to.
> >> >
> >> > Tested-by: Eric Paris <eparis(a)redhat.com>
> >
> > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> > index 07db2fe..ec9ab49 100644
> > --- a/include/linux/rcupdate.h
> > +++ b/include/linux/rcupdate.h
> > @@ -190,6 +190,15 @@ static inline int rcu_read_lock_sched_held(void)
> >
> > �#ifdef CONFIG_PROVE_RCU
> >
> > +#define __do_rcu_dereference_check(c) � � � � � � � � � � � � � � � � �\
> > + � � � do { � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �\
> > + � � � � � � � static bool __warned; � � � � � � � � � � � � � � � � � \
> > + � � � � � � � if (debug_lockdep_rcu_enabled() && !__warned && !(c)) { \
> > + � � � � � � � � � � � __warned = true; � � � � � � � � � � � � � � � �\
> > + � � � � � � � � � � � lockdep_rcu_dereference(__FILE__, __LINE__); � �\
> > + � � � � � � � } � � � � � � � � � � � � � � � � � � � � � � � � � � � \
> > + � � � } while (0)
> > +
> > �/**
> > �* rcu_dereference_check - rcu_dereference with debug checking
> > �* @p: The pointer to read, prior to dereferencing
> > @@ -219,8 +228,7 @@ static inline int rcu_read_lock_sched_held(void)
> > �*/
> > �#define rcu_dereference_check(p, c) \
> > � � � �({ \
> > - � � � � � � � if (debug_lockdep_rcu_enabled() && !(c)) \
> > - � � � � � � � � � � � lockdep_rcu_dereference(__FILE__, __LINE__); \
> > + � � � � � � � __do_rcu_dereference_check(c); \
> > � � � � � � � �rcu_dereference_raw(p); \
> > � � � �})
> >
> > @@ -237,8 +245,7 @@ static inline int rcu_read_lock_sched_held(void)
> > �*/
> > �#define rcu_dereference_protected(p, c) \
> > � � � �({ \
> > - � � � � � � � if (debug_lockdep_rcu_enabled() && !(c)) \
> > - � � � � � � � � � � � lockdep_rcu_dereference(__FILE__, __LINE__); \
> > + � � � � � � � __do_rcu_dereference_check(c); \
> > � � � � � � � �(p); \
> > � � � �})
> >
> > diff --git a/kernel/cgroup_freezer.c b/kernel/cgroup_freezer.c
> > index da5e139..e5c0244 100644
> > --- a/kernel/cgroup_freezer.c
> > +++ b/kernel/cgroup_freezer.c
> > @@ -205,9 +205,12 @@ static void freezer_fork(struct cgroup_subsys *ss, struct task_struct *task)
> > � � � � * No lock is needed, since the task isn't on tasklist yet,
> > � � � � * so it can't be moved to another cgroup, which means the
> > � � � � * freezer won't be removed and will be valid during this
> > - � � � �* function call.
> > + � � � �* function call. �Nevertheless, apply RCU read-side critical
> > + � � � �* section to suppress RCU lockdep false positives.
> > � � � � */
> > + � � � rcu_read_lock();
> > � � � �freezer = task_freezer(task);
> > + � � � rcu_read_unlock();
> >
> > � � � �/*
> > � � � � * The root cgroup is non-freezable, so we can skip the
> > diff --git a/kernel/lockdep.c b/kernel/lockdep.c
> > index 2594e1c..03dd1fa 100644
> > --- a/kernel/lockdep.c
> > +++ b/kernel/lockdep.c
> > @@ -3801,8 +3801,6 @@ void lockdep_rcu_dereference(const char *file, const int line)
> > �{
> > � � � �struct task_struct *curr = current;
> >
> > - � � � if (!debug_locks_off())
> > - � � � � � � � return;
> > � � � �printk("\n===================================================\n");
> > � � � �printk( �"[ INFO: suspicious rcu_dereference_check() usage. ]\n");
> > � � � �printk( �"---------------------------------------------------\n");
> > diff --git a/kernel/sched.c b/kernel/sched.c
> > index 6af210a..14c44ec 100644
> > --- a/kernel/sched.c
> > +++ b/kernel/sched.c
> > @@ -323,6 +323,15 @@ static inline struct task_group *task_group(struct task_struct *p)
> > �/* Change a task's cfs_rq and parent entity if it moves across CPUs/groups */
> > �static inline void set_task_rq(struct task_struct *p, unsigned int cpu)
> > �{
> > + � � � /*
> > + � � � �* Strictly speaking this rcu_read_lock() is not needed since the
> > + � � � �* task_group is tied to the cgroup, which in turn can never go away
> > + � � � �* as long as there are tasks attached to it.
> > + � � � �*
> > + � � � �* However since task_group() uses task_subsys_state() which is an
> > + � � � �* rcu_dereference() user, this quiets CONFIG_PROVE_RCU.
> > + � � � �*/
> > + � � � rcu_read_lock();
> > �#ifdef CONFIG_FAIR_GROUP_SCHED
> > � � � �p->se.cfs_rq = task_group(p)->cfs_rq[cpu];
> > � � � �p->se.parent = task_group(p)->se[cpu];
> > @@ -332,6 +341,7 @@ static inline void set_task_rq(struct task_struct *p, unsigned int cpu)
> > � � � �p->rt.rt_rq �= task_group(p)->rt_rq[cpu];
> > � � � �p->rt.parent = task_group(p)->rt_se[cpu];
> > �#endif
> > + � � � rcu_read_unlock();
> > �}
> >
> > �#else
> >
>
> Hi Paul.
>
> Has this patch made it into the Linus tree?
> Thanks!

Hello, Miles,

Not yet -- working with Ingo to get a variant of it into -tip on
its way to Linus's tree. The latest patch stack may be found at
http://lkml.org/lkml/2010/4/30/500.

Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Paul E. McKenney on 2 May 2010 00:20
On Sat, May 01, 2010 at 10:00:43PM -0400, Miles Lane wrote:
> On Sat, May 1, 2010 at 5:55 PM, Paul E. McKenney
> <paulmck(a)linux.vnet.ibm.com> wrote:
> > On Sat, May 01, 2010 at 01:26:15PM -0400, Miles Lane wrote:
> >> On Tue, Apr 20, 2010 at 9:52 AM, Paul E. McKenney
> >> <paulmck(a)linux.vnet.ibm.com> wrote:
> >> > On Tue, Apr 20, 2010 at 08:45:28AM -0400, Miles Lane wrote:
> >> >> Is there a patch set for 2.6.34-rc5 I can test?
> >> >
> >> > I will be sending a patchset out later today after testing, but
> >> > please see below for a sneak preview collapsed into a single patch.
> >> >
> >> > � � � � � � � � � � � � � � � � � � � � � � � � � � � �Thanx, Paul
> >> >
> >> >> On Tue, Apr 20, 2010 at 8:31 AM, Eric Paris <eparis(a)redhat.com> wrote:
> >> >>
> >> >> > On Tue, 2010-04-20 at 16:23 +0800, Lai Jiangshan wrote:
> >> >> >
> >> >> > > [PATCH] RCU: don't turn off lockdep when find suspicious
> >> >> > rcu_dereference_check() usage
> >> >> > >
> >> >> > > When suspicious rcu_dereference_check() usage is detected, lockdep is
> >> >> > still
> >> >> > > available actually, so we should not call debug_locks_off() in
> >> >> > > lockdep_rcu_dereference().
> >> >> > >
> >> >> > > For get rid of too much "suspicious rcu_dereference_check() usage"
> >> >> > > output when the "if(!debug_locks_off())" statement is removed. This patch
> >> >> > uses
> >> >> > > static variable '__warned's for very usage of "rcu_dereference*()".
> >> >> > >
> >> >> > > One variable per usage, so, Now, we can get multiple complaint
> >> >> > > when we detect multiple different suspicious rcu_dereference_check()
> >> >> > usage.
> >> >> > >
> >> >> > > Requested-by: Eric Paris <eparis(a)redhat.com>
> >> >> > > Signed-off-by: Lai Jiangshan <laijs(a)cn.fujitsu.com>
> >> >> >
> >> >> > Although mine was a linux-next kernel and it doesn't appear that I have
> >> >> > rcu_dereference_protected() at all, so I dropped that bit of the patch,
> >> >> > it worked great! �I got 4 more complaints to harass people with. �Feel
> >> >> > free to add my tested by if you care to.
> >> >> >
> >> >> > Tested-by: Eric Paris <eparis(a)redhat.com>
> >> >
> >> > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> >> > index 07db2fe..ec9ab49 100644
> >> > --- a/include/linux/rcupdate.h
> >> > +++ b/include/linux/rcupdate.h
> >> > @@ -190,6 +190,15 @@ static inline int rcu_read_lock_sched_held(void)
> >> >
> >> > �#ifdef CONFIG_PROVE_RCU
> >> >
> >> > +#define __do_rcu_dereference_check(c) � � � � � � � � � � � � � � � � �\
> >> > + � � � do { � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �\
> >> > + � � � � � � � static bool __warned; � � � � � � � � � � � � � � � � � \
> >> > + � � � � � � � if (debug_lockdep_rcu_enabled() && !__warned && !(c)) { \
> >> > + � � � � � � � � � � � __warned = true; � � � � � � � � � � � � � � � �\
> >> > + � � � � � � � � � � � lockdep_rcu_dereference(__FILE__, __LINE__); � �\
> >> > + � � � � � � � } � � � � � � � � � � � � � � � � � � � � � � � � � � � \
> >> > + � � � } while (0)
> >> > +
> >> > �/**
> >> > �* rcu_dereference_check - rcu_dereference with debug checking
> >> > �* @p: The pointer to read, prior to dereferencing
> >> > @@ -219,8 +228,7 @@ static inline int rcu_read_lock_sched_held(void)
> >> > �*/
> >> > �#define rcu_dereference_check(p, c) \
> >> > � � � �({ \
> >> > - � � � � � � � if (debug_lockdep_rcu_enabled() && !(c)) \
> >> > - � � � � � � � � � � � lockdep_rcu_dereference(__FILE__, __LINE__); \
> >> > + � � � � � � � __do_rcu_dereference_check(c); \
> >> > � � � � � � � �rcu_dereference_raw(p); \
> >> > � � � �})
> >> >
> >> > @@ -237,8 +245,7 @@ static inline int rcu_read_lock_sched_held(void)
> >> > �*/
> >> > �#define rcu_dereference_protected(p, c) \
> >> > � � � �({ \
> >> > - � � � � � � � if (debug_lockdep_rcu_enabled() && !(c)) \
> >> > - � � � � � � � � � � � lockdep_rcu_dereference(__FILE__, __LINE__); \
> >> > + � � � � � � � __do_rcu_dereference_check(c); \
> >> > � � � � � � � �(p); \
> >> > � � � �})
> >> >
> >> > diff --git a/kernel/cgroup_freezer.c b/kernel/cgroup_freezer.c
> >> > index da5e139..e5c0244 100644
> >> > --- a/kernel/cgroup_freezer.c
> >> > +++ b/kernel/cgroup_freezer.c
> >> > @@ -205,9 +205,12 @@ static void freezer_fork(struct cgroup_subsys *ss, struct task_struct *task)
> >> > � � � � * No lock is needed, since the task isn't on tasklist yet,
> >> > � � � � * so it can't be moved to another cgroup, which means the
> >> > � � � � * freezer won't be removed and will be valid during this
> >> > - � � � �* function call.
> >> > + � � � �* function call. �Nevertheless, apply RCU read-side critical
> >> > + � � � �* section to suppress RCU lockdep false positives.
> >> > � � � � */
> >> > + � � � rcu_read_lock();
> >> > � � � �freezer = task_freezer(task);
> >> > + � � � rcu_read_unlock();
> >> >
> >> > � � � �/*
> >> > � � � � * The root cgroup is non-freezable, so we can skip the
> >> > diff --git a/kernel/lockdep.c b/kernel/lockdep.c
> >> > index 2594e1c..03dd1fa 100644
> >> > --- a/kernel/lockdep.c
> >> > +++ b/kernel/lockdep.c
> >> > @@ -3801,8 +3801,6 @@ void lockdep_rcu_dereference(const char *file, const int line)
> >> > �{
> >> > � � � �struct task_struct *curr = current;
> >> >
> >> > - � � � if (!debug_locks_off())
> >> > - � � � � � � � return;
> >> > � � � �printk("\n===================================================\n");
> >> > � � � �printk( �"[ INFO: suspicious rcu_dereference_check() usage. ]\n");
> >> > � � � �printk( �"---------------------------------------------------\n");
> >> > diff --git a/kernel/sched.c b/kernel/sched.c
> >> > index 6af210a..14c44ec 100644
> >> > --- a/kernel/sched.c
> >> > +++ b/kernel/sched.c
> >> > @@ -323,6 +323,15 @@ static inline struct task_group *task_group(struct task_struct *p)
> >> > �/* Change a task's cfs_rq and parent entity if it moves across CPUs/groups */
> >> > �static inline void set_task_rq(struct task_struct *p, unsigned int cpu)
> >> > �{
> >> > + � � � /*
> >> > + � � � �* Strictly speaking this rcu_read_lock() is not needed since the
> >> > + � � � �* task_group is tied to the cgroup, which in turn can never go away
> >> > + � � � �* as long as there are tasks attached to it.
> >> > + � � � �*
> >> > + � � � �* However since task_group() uses task_subsys_state() which is an
> >> > + � � � �* rcu_dereference() user, this quiets CONFIG_PROVE_RCU.
> >> > + � � � �*/
> >> > + � � � rcu_read_lock();
> >> > �#ifdef CONFIG_FAIR_GROUP_SCHED
> >> > � � � �p->se.cfs_rq = task_group(p)->cfs_rq[cpu];
> >> > � � � �p->se.parent = task_group(p)->se[cpu];
> >> > @@ -332,6 +341,7 @@ static inline void set_task_rq(struct task_struct *p, unsigned int cpu)
> >> > � � � �p->rt.rt_rq �= task_group(p)->rt_rq[cpu];
> >> > � � � �p->rt.parent = task_group(p)->rt_se[cpu];
> >> > �#endif
> >> > + � � � rcu_read_unlock();
> >> > �}
> >> >
> >> > �#else
> >> >
> >>
> >> Hi Paul.
> >>
> >> Has this patch made it into the Linus tree?
> >> Thanks!
> >
> > Hello, Miles,
> >
> > Not yet -- working with Ingo to get a variant of it into -tip on
> > its way to Linus's tree. �The latest patch stack may be found at
> > http://lkml.org/lkml/2010/4/30/500.
>
> What is the rationale for defaulting to showing only one RCU splat?
> That setting seems likely to reduce the rate at which things get
> cleaned up.

Hello, Miles,

The discussion is at http://lkml.org/lkml/2010/4/21/304. It might
reduce it or even increase it. The increase might come from people
who might disable CONFIG_PROVE_RCU completely if they kept getting
too many splats. This way people can choose how much they want to
contribute to cleaning up.

And regardless of how this is eventually settled, let me say again
that I very much appreciate your testing efforts!!!

Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: uml: Remove unused variable from line driver
Next: [PATCH] Mass Storage Gadget: Handle eject request