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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 14 Nov 2006 08:40:00 +0100
From:	Pierre Ossman <drzeus-list@...eus.cx>
To:	Russell King <rmk+lkml@....linux.org.uk>,
	LKML <linux-kernel@...r.kernel.org>
Subject: device_del() and references

Hi Russell,

I'm trying to wrap my head around the dependencies in the MMC layer and
there are some gaps I am suspicious about. Since you've been looking at
this a lot longer than I have, I thought you could have some valuable
insight.

When a card driver has obtained a reference to a card, what makes sure
we do not destroy that card from under its feet? The reference count on
the device structure in the card only makes sure the structure itself is
in memory, not that the data is valid. E.g. the host might be removed
leaving the host pointer invalid.

I suspect that device_del() doesn't return until remove() has been
called and that our requirement is that the card driver must have
released all references to the card before its remove routine exits.

If so, then there is the risk of a race in mmc_block. What guarantees
that the request handler isn't running in parallel with the remove
function? Again, I suspect that del_gendisk() might grab the queue lock,
but as there might be stuff left in the queue, this seems insufficient.

Perhaps there is a is_gendisk_valid() we can stick at the top of the
request handler?

Rgds
-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org
-
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