linux-kernel - Re: [RFC] component: Fix: Unassign components' masters if bringing up master fails

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, 15 Feb 2016 23:01:11 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	"Jon Medhurst (Tixy)" <tixy@...aro.org>
Cc:	Archit Taneja <architt@...eaurora.org>,
	linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
	Daniel Stone <daniel@...ishbar.org>
Subject: Re: [RFC] component: Fix: Unassign components' masters if bringing
 up master fails

On Mon, Feb 15, 2016 at 07:32:02PM +0000, Jon Medhurst (Tixy) wrote:
> It seems to me that for other error cases (that don't result in deletion
> of objects) we would want to leave the references between components and
> masters intact once they have been created.

Indeed we do - because we want to avoid having to redo the matching
work each and every time we try to bring up the master.  It's needless
expense to keep re-running all the matches every time.

> The other components or master should subsequently get cleaned up by
> calling component_del() or component_master_del(), which take care of
> updating the relevant references between components and master.

Correct.

> For component_master_del this is not immediately obvious, but 
> take_down_master calls devres_release_group which causes
> devm_component_match_release to be called.

Also correct.

For component_master_del(), the list of components will be going away,
so there's no point cleaning that list (it's freed when the device
model releases its devres group.)

However, the components themselves must not be left pointing at the
freed memory, otherwise they'll effectively be marked "in-use" by a
non-existent master - that's what "free_master()" is about - ensuring
that when 'struct master' is freed, there are no components left
pointing at the to-be-freed master device.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.