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]
Message-ID: <20111026205455.GG24261@google.com>
Date:	Wed, 26 Oct 2011 13:54:55 -0700
From:	Tejun Heo <tj@...nel.org>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	axboe@...nel.dk, ctalbott@...gle.com, rni@...gle.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 10/13] block, cfq: unlink cfq_io_context's immediately

Hello, Vivek.

On Wed, Oct 26, 2011 at 04:38:46PM -0400, Vivek Goyal wrote:
> So the only reason that cic needs to be rcu protected because in
> cfq_cic_lookup() we can access ioc->ioc_data which can point to a 
> cic which is not ours and we are not holding queue lock for that and
> we can't access cic->q ?

About right but to be more exact.

* Indexes from ioc are protected by ioc->lock - both the radix tree
  and hint.  Both are RCU managed.

* cic structures themselves are protected by cic->q->queue_lock and
  RCU managed.

* Additions and removals are done holding both ioc and q locks.

* Lookup is performed with RCU read locked and q->queue_lock held.
  Indexes and cic's themselves are RCU protected so can be traversed
  and cic can be dereferenced even if it's pointing to a different
  queue (and thus protected under different queue_lock).

  However, cic's pointing to the q which is being looked up can be
  added only under the same queue_lock, so on "cic->q == q" we're
  guaranteed to be looking at the right thing.

> I am wondering if there should be a small text file explaining all
> the locking in this area.

Oh, I'm gonna be restructuring ioc interface and adding ample
explanations on locking rules there.

Thanks.

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