linux-kernel - Re: [PATCH v9 1/5] driver core: Find an existing link between two devices

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:   Tue, 13 Mar 2018 12:49:37 +0000
From:   Robin Murphy <robin.murphy@....com>
To:     Vivek Gautam <vivek.gautam@...eaurora.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:     "list@....net:IOMMU DRIVERS" <iommu@...ts.linux-foundation.org>,
        Joerg Roedel <joro@...tes.org>, joro@...tes.org,
        robh+dt <robh+dt@...nel.org>,
        "list@....net:IOMMU DRIVERS" <iommu@...ts.linux-foundation.org>,
        Joerg Roedel <joro@...tes.org>,
        iommu@...ts.linux-foundation.org, devicetree@...r.kernel.org,
        open list <linux-kernel@...r.kernel.org>,
        Mark Rutland <mark.rutland@....com>,
        Will Deacon <will.deacon@....com>,
        Rob Clark <robdclark@...il.com>,
        Tomasz Figa <tfiga@...omium.org>,
        Sricharan R <sricharan@...eaurora.org>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Archit Taneja <architt@...eaurora.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH v9 1/5] driver core: Find an existing link between two
 devices

On 13/03/18 09:55, Vivek Gautam wrote:
> On Tue, Mar 13, 2018 at 3:10 PM, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
>> On Tuesday, March 13, 2018 9:55:30 AM CET Vivek Gautam wrote:
>>> The lists managing the device-links can be traversed to
>>> find the link between two devices. The device_link_add() APIs
>>> does traverse these lists to check if there's already a link
>>> setup between the two devices.
>>> So, add a new APIs, device_link_find(), to find an existing
>>> device link between two devices - suppliers and consumers.
>>>
>>> Signed-off-by: Vivek Gautam <vivek.gautam@...eaurora.org>
>>> Cc: Rafael J. Wysocki <rjw@...ysocki.net>
>>> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
>>> ---
>>>
>>>   * New patch added to this series.
>>>
>>>   drivers/base/core.c    | 30 +++++++++++++++++++++++++++---
>>>   include/linux/device.h |  2 ++
>>>   2 files changed, 29 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/base/core.c b/drivers/base/core.c
>>> index 5847364f25d9..e8c9774e4ba2 100644
>>> --- a/drivers/base/core.c
>>> +++ b/drivers/base/core.c
>>> @@ -144,6 +144,30 @@ static int device_reorder_to_tail(struct device *dev, void *not_used)
>>>        return 0;
>>>   }
>>>
>>> +/**
>>> + * device_link_find - find any existing link between two devices.
>>> + * @consumer: Consumer end of the link.
>>> + * @supplier: Supplier end of the link.
>>> + *
>>> + * Returns pointer to the existing link between a supplier and
>>> + * and consumer devices, or NULL if no link exists.
>>> + */
>>> +struct device_link *device_link_find(struct device *consumer,
>>> +                                  struct device *supplier)
>>> +{
>>> +     struct device_link *link = NULL;
>>> +
>>> +     if (!consumer || !supplier)
>>> +             return NULL;
>>> +
>>> +     list_for_each_entry(link, &supplier->links.consumers, s_node)
>>> +             if (link->consumer == consumer)
>>> +                     break;
>>> +
>>
>> Any mutual exclusion?
>>
>> Or is the caller expected to take care of it?  And if so, then how?
> 
> I think it's better that we take care of lock here in the code rather
> than depending
> on the caller.
> But i can't take device_links_write_lock() since device_link_add()
> already takes that.

Well, the normal pattern is to break out the internal helper function 
as-is, then add a public wrapper which validates inputs, handles 
locking, etc., equivalently to existing caller(s). See what 
device_link_del() and others do, e.g.:

static struct device_link *__device_link_find(struct device *consumer,
		struct device *supplier)
{
	list_for_each_entry(link, &supplier->links.consumers, s_node)
		if (link->consumer == consumer)
			return link;
	return NULL;
}

struct device_link *device_link_find(struct device *consumer,
		struct device *supplier)
{
	struct device_link *link;

	if (!consumer || !supplier)
		return NULL;

	device_links_write_lock();
	link = __device_link_find(consumer, supplier);	
	device_links_write_unlock();
	return link;
}

where device_link_add() would call __device_link_find() directly.

However, as Tomasz points out (and I hadn't really considered), if the 
only reasonable thing to with a link once you've found it is to delete 
it, then in terms of the public API it may well make more sense to just 
implement something like a device_link_remove() which does both in one go.

Robin.