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: <CAPXgP10Du4nJ_hdfwqV0Fr6XEVkTMO6jZ_TS_T-J-grDG7nKJw@mail.gmail.com>
Date:	Wed, 18 Jan 2012 19:50:20 +0100
From:	Kay Sievers <kay.sievers@...y.org>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	"Luck, Tony" <tony.luck@...el.com>, Greg KH <gregkh@...e.de>,
	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>,
	Sergei Trofimovich <slyich@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linux PM mailing list <linux-pm@...r.kernel.org>,
	Borislav Petkov <bp@...64.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"prasad@...ux.vnet.ibm.com" <prasad@...ux.vnet.ibm.com>,
	Ming Lei <tom.leiming@...il.com>,
	Djalal Harouni <tixxdz@...ndz.org>,
	Borislav Petkov <borislav.petkov@....com>,
	Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>,
	Andi Kleen <ak@...ux.intel.com>,
	"gouders@...bocholt.fh-gelsenkirchen.de" 
	<gouders@...bocholt.fh-gelsenkirchen.de>,
	Marcos Souza <marcos.mage@...il.com>,
	"justinmattock@...il.com" <justinmattock@...il.com>,
	Jeff Chua <jeff.chua.linux@...il.com>
Subject: Re: [PATCH] mce: fix warning messages about static struct mce_device

On Wed, Jan 18, 2012 at 19:10, Alan Stern <stern@...land.harvard.edu> wrote:

> There's nothing special about the driver model code in this respect.
> The same restriction applies wherever object lifetimes are controlled
> by reference counting.

Right. But it might not be obvious what 's the background here:

An allocated device object(memory) usually represents an actual
device(hardware). The object can have N users. Every of the users is
required to take a reference to the object, which pins the object's
memory as long as any of the N users might need to access it.

In a hotplug world, we deal with device-removal.  On disconnect, we
usually just orphan the object, we remove it from visibility,
disconnect the device <-> object relation.

All of the  N users with a reference can still access the memory, they
just do not talk to a real device anymore. The invalidated/orphaned
state is communicated otherwise by locks and flags in the device
object. Only after all of the N users left the object alone, the
memory of the orphan if free'd.

If in the time-window between disconnecting the object from the device
and freeing the orphaned object's memory, the same device comes back,
we allocate a new object which is associated with the device. It
usually has the same name and same properties as the original one.

This way, the new object is full functional, does not conflict with
the older one, and also all the users of the old memory are still fine
and can cleanup a lazy as they need without much synchronization.

Now, all that might not apply to machinecheck, and it might be that
machinecheck is fully able to handle all that just fine with the
statically allocated same memory -- allocating new device memory on
hotplug is still the model that should always be preferred over any
other, if possible.

It's usually the simplest safest and most flexible for anything that
can come and go at any time, and memory which might be in used by
other running code.

And hey, filesystems work successful with this model since ages.
Nobody invented anything new here. Device hotplug/unplug/cleanup is
not much different from create/unlink/release. Open/truncate is
usually much harder to manage in concurrency situations. :)

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