lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 6 Nov 2006 10:05:09 -0500 (EST)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Oleg Nesterov <oleg@...sign.ru>
cc:	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...l.org>,
	Linus Torvalds <torvalds@...l.org>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	sct@...hat.com
Subject: Re: PATCH? hrtimer_wakeup: fix a theoretical race wrt rt_mutex_slowlock()


On Mon, 6 Nov 2006, Steven Rostedt wrote:

> But...
>
> Doing a quick search on wake_up, I came across loop.c (also my first hit).
>
> Here we have: (some funcs pulled in).
>
> loop_make_request:
>   lo->lo_bio = lo->lo_biotail = bio;
>   wake_up(&lo->lo_event);
>
> And with wait_event_interruptible(lo->lo_event, lo->lo_bio)
> we have:
>
>   prepare_to_wait(..., TASK_INTERRUPTIBLE);
>   if (lo->bio)
>      break;
>   schedule_timeout();
>
>
> So this probably also has the same bug!
>
> There's nothing to prevent the CPU from showing lo->bio has changed
> *after* setting wake_up to TASK_RUNNING.
>
> So maybe this *is* a race condition that is all over the kernel for other
> architectures!

Talking this over with Stephen Tweedie, he pointed out to me that the
setting of the task state is done within the wait queue locks, and thus,
the above is not a problem.

But the old paradigm of:

  add_wait_queue();
  for (;;) {
	task->state = TASK_INTERRUPTIBLE;
	if (condition)
		break;
	schedule();
  }

Can still be a bug, since the other CPU might hold off the condition
to after it set the state to TASK_RUNNING.

-- Steve
-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ