* Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> > > Isn't it better to call lock_release() with nested == 1 ?
> >
> > Not sure, Ingo?
>
> Ingo, could you also explain the meaning of "nested" parameter? Looks
> like it is just unneeded, lock_release_nested() does a quick check and
> use lock_rele
On Wed, 2007-07-04 at 14:21 +0200, Ingo Molnar wrote:
> well, in this case the lock/unlock should nest perfectly (i.e. it should
> always be balanced perfectly), so indeed calling with nested==1 leads to
> stricter checking.
>
> non-nested unlocks occur when people do stuff like:
>
> spi
On Wed, 2007-07-04 at 16:52 +0400, Oleg Nesterov wrote:
> Yes. And no other work (except a barrier) can run before the caller of
> wait_on_work() is woken.
Alright, thanks. Yes, then what you proposed makes a lot of sense, I'll
implement it.
> Aha, now I see where I was confused. Yes, we can't a
On 07/04, Johannes Berg wrote:
>
> On Tue, 2007-07-03 at 21:31 +0400, Oleg Nesterov wrote:
>
> > If A does NOT take a lock L1, then it is OK to do cancel_work_sync(A)
> > under L1, regardless of which other work_structs this workqueue has,
> > before or after A.
>
> Ah, cancel_work_sync() waits
* Johannes Berg <[EMAIL PROTECTED]> wrote:
> > > +#define create_workqueue(name) \
> > > +({ \
> > > + static struct lock_class_key __key; \
> > > + struct workqueue_struct *__wq; \
> > > +
* Johannes Berg <[EMAIL PROTECTED]> wrote:
> > > @@ -257,7 +260,9 @@ static void run_workqueue(struct cpu_wor
> > >
> > > BUG_ON(get_wq_data(work) != cwq);
> > > work_clear_pending(work);
> > > + lock_acquire(&cwq->wq->lockdep_map, 0, 0, 0, 2, _THIS_IP_);
> > >
Oleg,
Thanks for your comments. Shows how little I really understand the
workqueue API :)
On Tue, 2007-07-03 at 21:31 +0400, Oleg Nesterov wrote:
> > I think this could lead to false positives, but then I think we
> > shouldn't care about those. Let me explain. The thing is that with this
> > it
* Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> Now we have a false positive if some time we queue B into that
> workqueue, and this is not good.
>
> We can avoid this problem if we put lockdep_map into work_struct, so
> that wait_on_work() "locks" work->lockdep_map, while flush_workqueue()
> ta
On 07/02, Johannes Berg wrote:
>
> On Sat, 2007-06-30 at 15:46 +0400, Oleg Nesterov wrote:
>
> > Johannes, could you change wait_on_work() as well? Most users of
> > flush_workqueue() should be converted to use it.
(to avoid a possible confusion: I meant, most users of flush_workqueue()
should be
On Sat, 2007-06-30 at 15:46 +0400, Oleg Nesterov wrote:
[reordered a bit]
> And,
>
> > if (!list_empty(&cwq->worklist) || cwq->current_work !=
> > NULL) {
> > @@ -376,6 +388,8 @@ void fastcall flush_workqueue(struct wor
> > int cpu;
> >
> > might_sleep();
> > +
On Sat, 2007-06-30 at 15:46 +0400, Oleg Nesterov wrote:
> On 06/30, Ingo Molnar wrote:
> >
> > On Thu, 2007-06-28 at 19:33 +0200, Johannes Berg wrote:
> > > No, that's not right either, but Arjan just helped me a bit with how
> > > lockdep works and I think I have the right idea now. Ignore this fo
On 06/30, Ingo Molnar wrote:
>
> On Thu, 2007-06-28 at 19:33 +0200, Johannes Berg wrote:
> > No, that's not right either, but Arjan just helped me a bit with how
> > lockdep works and I think I have the right idea now. Ignore this for
> > now, I'll send a new patch in a few days.
>
> ok. But in ge
On Thu, 2007-06-28 at 19:33 +0200, Johannes Berg wrote:
> No, that's not right either, but Arjan just helped me a bit with how
> lockdep works and I think I have the right idea now. Ignore this for
> now, I'll send a new patch in a few days.
ok. But in general, this is a very nice idea!
i've Cc:-
On Thu, 2007-06-28 at 18:33 +0200, Johannes Berg wrote:
> I think I misunderstood how lockdep works because the output was
> actually wrong, should the key be part of the workqueue_struct as well?
No, that's not right either, but Arjan just helped me a bit with how
lockdep works and I think I hav
On Wed, 2007-06-27 at 20:40 +0200, Johannes Berg wrote:
> --- linux-2.6-git.orig/kernel/workqueue.c 2007-06-27 19:10:35.183199046
> +0200
> +++ linux-2.6-git/kernel/workqueue.c 2007-06-27 20:30:00.896667168 +0200
> @@ -61,8 +61,15 @@ struct workqueue_struct {
> const char *name;
>
15 matches
Mail list logo
