Re: [PATCH] posix-timer: fix deletion race

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 24 Jul 2007, Oleg Nesterov wrote:

On 07/23, Jeremy Katz wrote:

On Fri, 20 Jul 2007, Oleg Nesterov wrote:

I still can't believe we have a double-free problem, this looks imposiible.
Do you see the

	"idr_remove called for id=%d which is not allocated.\n"

in syslog?

No.  I also added some accounting with atomic counters, and don't see
evidence of a second call to release_posix_timer.

Interesting. Could you show the patch? Where does sys_timer_create() set
counter == 1?

--- kernel/posix-timers.c.old      2007-07-24 11:21:29.000000000 -0700
+++ kernel/posix-timers.c       2007-07-20 15:49:51.000000000 -0700
@@ -409,13 +409,17 @@ static struct k_itimer * alloc_posix_tim
 #define IT_ID_NOT_SET  0
 static void release_posix_timer(struct k_itimer *tmr, int it_id_set)
 {
+       atomic_inc(&tmr->freecount);
@@ -443,6 +447,7 @@ sys_timer_create(const clockid_t which_c
        new_timer = alloc_posix_timer();
        if (unlikely(!new_timer))
                return -EAGAIN;
+       atomic_set(&new_timer->freecount, 0);

--- include/linux/posix-timers.h.old  2007-07-24 11:32:36.000000000 -0700
+++ include/linux/posix-timers.h      2007-07-20 15:15:44.000000000 -0700
@@ -62,6 +62,7 @@ struct k_itimer {
                        unsigned long expires;
                } mmtimer;
        } it;
+       atomic_t freecount;
 };

 struct k_clock {


Examination was done through a kgdb session when it caught the bug. freecount always had the expected value, 1 during a delete operation, and 0 otherwise.

Could you try the patch below? Perhaps we have some wierd problem with
->sigq corruption.

Tried, with apparent effect.

You mean, "null pointer dereference" in release_posix_timer() ? Or it was
BUG_ON(timr && !timr->sigq) in lock_timer() ?

Sorry.  That should have been "without apparent effect".

I assume you didn't apply any other patches except Thomas's, yes?

Alone, as well as with Thomas' patch. Neither way changed the behavior.

Jeremy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux