[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1285417423.2478.475.camel@edumazet-laptop>
Date: Sat, 25 Sep 2010 14:23:43 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: Namhyung Kim <namhyung@...il.com>
Cc: Oleg Nesterov <oleg@...hat.com>,
Roland McGrath <roland@...hat.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] signal: annotate siglock acquisition
Le samedi 25 septembre 2010 à 20:33 +0900, Namhyung Kim a écrit :
> What's the difference? I didn't change the semantics of likely clause
> but simply exchange the order of then-else part because IMHO a
> negative expression make it hard to understand, generally.
> I've checked compiled binaries for both cases on x86 and they
> produced exactly same code.
>
Anyway, re-reading your patch, I just dont get why you use __cond_lock()
two times, but not on this part ?
if (!likely(__cond_lock(&t->sighand->siglock,
lock_task_sighand(t, &flags))))
goto ret;
This way, your patch would not be misleading.
Another way to deal with this sparse mess is to use a macro, like we do
for read_trylock() :
#define read_trylock(lock) __cond_lock(lock, _raw_read_trylock(lock))
-->
#define lock_task_sighand(t, flags) \
__cond_lock(&(t)->sighand->siglock, \
_raw_lock_task_sighand(t, flags))
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists