All of lore.kernel.org
 help / color / mirror / Atom feed
From: srinivas.kandagatla@linaro.org (Srinivas Kandagatla)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/3] nvmem: core: make default user binary file root-access only
Date: Wed, 07 Oct 2015 14:46:56 +0100	[thread overview]
Message-ID: <56152250.2000200@linaro.org> (raw)
In-Reply-To: <20151007113349.GJ21513@n2100.arm.linux.org.uk>



On 07/10/15 12:33, Russell King - ARM Linux wrote:
> On Wed, Oct 07, 2015 at 12:00:47PM +0100, Srinivas Kandagatla wrote:
>> As required by many providers like at24/at25/mxs-ocotp/qfprom and may be
>> other providers would want to allow root-only to read the nvmem content.
>> So making the defaults to be root-only access would address the request
>> and also provide flexibility to providers to specify there own permissions
>> on top of the root-only using the perm flag in nvmem_config.
>> Making this dynamic did cut down lot of static binary attributes in the
>> code.
>
> Check what the lifetime of a struct bin_attribute is before you embed it
> into any other structure.  Sorry, but I think you're going to have to

Lifetime of the "static struct bin_attribute bin_attr_template" is 
static and a memcpy of which is made into nvmem->bin whose lifetime is 
till the nvmem_release() which happens at device_release(), so there 
should be no issue in using a copy of bin_attribute.

However there are other issues as Greg pointed, so am dropping this 
series altogether.

--srini
> read up on the driver model, sysfs, and kernfs implementations to find
> out - I don't know the answer to this without doing the same.
>
> However, this is basic checking that anyone should do when embedding
> a structure within another.
>

WARNING: multiple messages have this Message-ID (diff)
From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: gregkh@linuxfoundation.org, stefan.wahren@i2se.com,
	andrew@lunn.ch, s.hauer@pengutronix.de,
	pantelis.antoniou@konsulko.com, linux-kernel@vger.kernel.org,
	maitysanchayan@gmail.com, p.zabel@pengutronix.de,
	maxime.ripard@free-electrons.com,
	linux-arm-kernel@lists.infradead.org, wxt@rock-chips.com
Subject: Re: [PATCH v2 1/3] nvmem: core: make default user binary file root-access only
Date: Wed, 07 Oct 2015 14:46:56 +0100	[thread overview]
Message-ID: <56152250.2000200@linaro.org> (raw)
In-Reply-To: <20151007113349.GJ21513@n2100.arm.linux.org.uk>



On 07/10/15 12:33, Russell King - ARM Linux wrote:
> On Wed, Oct 07, 2015 at 12:00:47PM +0100, Srinivas Kandagatla wrote:
>> As required by many providers like at24/at25/mxs-ocotp/qfprom and may be
>> other providers would want to allow root-only to read the nvmem content.
>> So making the defaults to be root-only access would address the request
>> and also provide flexibility to providers to specify there own permissions
>> on top of the root-only using the perm flag in nvmem_config.
>> Making this dynamic did cut down lot of static binary attributes in the
>> code.
>
> Check what the lifetime of a struct bin_attribute is before you embed it
> into any other structure.  Sorry, but I think you're going to have to

Lifetime of the "static struct bin_attribute bin_attr_template" is 
static and a memcpy of which is made into nvmem->bin whose lifetime is 
till the nvmem_release() which happens at device_release(), so there 
should be no issue in using a copy of bin_attribute.

However there are other issues as Greg pointed, so am dropping this 
series altogether.

--srini
> read up on the driver model, sysfs, and kernfs implementations to find
> out - I don't know the answer to this without doing the same.
>
> However, this is basic checking that anyone should do when embedding
> a structure within another.
>

  reply	other threads:[~2015-10-07 13:46 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-07 10:58 [PATCH v2 0/3] nvmem: make sysfs binary file permissions more flexible Srinivas Kandagatla
2015-10-07 10:58 ` Srinivas Kandagatla
2015-10-07 11:00 ` [PATCH v2 1/3] nvmem: core: make default user binary file root-access only Srinivas Kandagatla
2015-10-07 11:00   ` Srinivas Kandagatla
2015-10-07 11:33   ` Russell King - ARM Linux
2015-10-07 11:33     ` Russell King - ARM Linux
2015-10-07 13:46     ` Srinivas Kandagatla [this message]
2015-10-07 13:46       ` Srinivas Kandagatla
2015-10-07 16:23       ` Russell King - ARM Linux
2015-10-07 16:23         ` Russell King - ARM Linux
2015-10-07 12:55   ` Greg KH
2015-10-07 12:55     ` Greg KH
2015-10-07 13:18     ` Srinivas Kandagatla
2015-10-07 13:18       ` Srinivas Kandagatla
2015-10-07 16:12       ` Greg KH
2015-10-07 16:12         ` Greg KH
2015-10-07 11:00 ` [PATCH v2 2/3] nvmem: core: set the size for the nvmem binary file Srinivas Kandagatla
2015-10-07 11:00   ` Srinivas Kandagatla
2015-10-07 12:56   ` Greg KH
2015-10-07 12:56     ` Greg KH
2015-10-07 13:21     ` Srinivas Kandagatla
2015-10-07 13:21       ` Srinivas Kandagatla
2015-10-07 11:01 ` [PATCH v2 3/3] nvmem: core: add sysfs file mode flag in nvmem_config Srinivas Kandagatla
2015-10-07 11:01   ` Srinivas Kandagatla
2015-10-07 12:56   ` Greg KH
2015-10-07 12:56     ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56152250.2000200@linaro.org \
    --to=srinivas.kandagatla@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.