linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Richard Weinberger <richard@nod.at>
Cc: Artem Bityutskiy <dedekind1@gmail.com>,
	Boris Brezillon <boris.brezillon@free-electrons.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Brian Norris <computersforpeace@gmail.com>
Subject: Re: [PATCH v2 2/2] UBI: Make mtd parameter readable
Date: Tue, 10 Jan 2017 16:11:36 +0200	[thread overview]
Message-ID: <1484057496.2133.18.camel@linux.intel.com> (raw)
In-Reply-To: <71c71f00-dcb1-081b-ec55-bc7c39ad32d5@nod.at>

On Tue, 2017-01-10 at 14:54 +0100, Richard Weinberger wrote:
> Am 10.01.2017 um 14:48 schrieb Andy Shevchenko:
> > > > -module_param_call(mtd, ubi_mtd_param_parse, NULL, NULL, 000);
> > > > +module_param_call(mtd, ubi_mtd_param_parse, NULL, NULL, 0400);
> > > What is the use case?
> > > AFAIKT the permissions are 000
> > 
> > If it's not 0 in current case than you easily crash the kernel
> > because
> > parser will be gone at that time. This is fixed by patch 1.
> 
> Before your changes it was non-issue, right? ;)

If annoying section mismatch is not an issue, then yes, correct.

> > >  because a parser is involved and to
> > > "understand" the parameter,
> > > a reader needs the ubi_mtd_param_parse() function.
> > 
> > Are you implying that writer is a bot and reader is human being? 
> > The use case is obvious (any security reasons are implied?) -- allow
> > user to see what was written there in the first place.
> 
> I'm asking for the use case, why is exposing this parameter to user
> space
> a good thing? Who will use it?

Any user. I like the idea to have initial string to be stored somewhere
and visible (imagine the case when it's module and history is gone). It
might be useful for debugging (okay, this case perhaps not anymore, but
in general).

> > Permissions 0000 are error prone.
> 
> Why?

Because of a trick is being used here.

P.S. If you strongly against it I will give up, it doesn't cost my
efforts anymore. That's why one of the possible "solution" is to put
comment there for other brave guys.

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

  reply	other threads:[~2017-01-10 14:12 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-10 12:56 [PATCH v2 1/2] UBI: Fix section mismatch Andy Shevchenko
2017-01-10 12:56 ` [PATCH v2 2/2] UBI: Make mtd parameter readable Andy Shevchenko
2017-01-10 13:33   ` Richard Weinberger
2017-01-10 13:48     ` Andy Shevchenko
2017-01-10 13:54       ` Richard Weinberger
2017-01-10 14:11         ` Andy Shevchenko [this message]
2017-01-10 14:16           ` Richard Weinberger
2017-01-10 14:35             ` Andy Shevchenko
2017-01-10 15:31               ` Richard Weinberger
2017-01-10 15:38                 ` Andy Shevchenko

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=1484057496.2133.18.camel@linux.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=boris.brezillon@free-electrons.com \
    --cc=computersforpeace@gmail.com \
    --cc=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard@nod.at \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).