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: <20140722190120.GM13851@htj.dyndns.org>
Date:	Tue, 22 Jul 2014 15:01:20 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
Cc:	Thierry Reding <thierry.reding@...il.com>,
	Stephen Warren <swarren@...dotorg.org>,
	linux-pci@...r.kernel.org, linux-tegra@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] resource: Add device-managed
 request/release_resource()

Hello,

On Tue, Jul 22, 2014 at 12:50:02PM -0600, Bjorn Helgaas wrote:
> [+cc Tejun, LKML]
> 
> On Fri, Jul 11, 2014 at 09:08:24AM +0200, Thierry Reding wrote:
> > From: Thierry Reding <treding@...dia.com>
> > 
> > Provide device-managed implementations of the request_resource() and
> > release_resource() functions. Upon failure to request a resource, the
> > new devm_request_resource() function will output an error message for
> > consistent error reporting.
> > 
> > Signed-off-by: Thierry Reding <treding@...dia.com>
> 
> This seems OK to me, but I don't consider myself a devres maintainer.  I
> added Tejun and LKML for any comment.  Minor nit below.

If there are gonna be users of the interface, sure.

> > +int devm_request_resource(struct device *dev, struct resource *root,
> > +			  struct resource *new)
> > +{
> > +	struct resource *conflict, **ptr;
> > +
> > +	ptr = devres_alloc(devm_resource_release, sizeof(*ptr), GFP_KERNEL);
> > +	if (!ptr)
> > +		return -ENOMEM;
> > +
> > +	*ptr = new;
> > +
> > +	conflict = request_resource_conflict(root, new);
> > +	if (!conflict) {
> > +		devres_add(dev, ptr);
> > +		return 0;
> > +	}
> > +
> > +	dev_err(dev, "resource collision: %pR conflicts with %s %pR\n", new,
> > +		conflict->name, conflict);
> > +	devres_free(ptr);
> > +	return -EBUSY;
> 
> Personally I would write this as:
> 
>   conflict = request_resource_conflict(...);
>   if (conflict) {
>     dev_err(...);
>     devres_free(...);
>     return -EBUSY;
>   }
> 
>   devres_add(...);
>   return 0;
> 
> so the straight-line path is the normal, non-error path and errors are
> detected and dealt with in the "if" bodies.  Right now the "if" bodies
> are a mix of error handling and normal path.  But that's just my personal
> preference.

Agreed.

> > +static int devm_resource_match(struct device *dev, void *res, void *data)
> > +{
> > +	struct resource **ptr = res;
> > +
> > +	if (WARN_ON(!ptr || !*ptr))
> > +		return 0;

How would !ptr or !*ptr possibly happen?  Wouldn't that be a bug
already?

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