linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Linux FS Devel <linux-fsdevel@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH v1] seq_file: convert mangle_path() to use string_escape_str()
Date: Thu, 10 Jan 2019 02:19:53 +0200	[thread overview]
Message-ID: <CAHp75VfZq7NhDX8c9EGa_4v-5nApiqF5RLbw49HO--H6h-YWnQ@mail.gmail.com> (raw)
In-Reply-To: <20190109100414.4de13e06ecbdeb89cb8c4e40@linux-foundation.org>

On Wed, Jan 9, 2019 at 8:21 PM Andrew Morton <akpm@linux-foundation.org> wrote:
> On Wed,  9 Jan 2019 17:40:22 +0200 Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
>
> > Since string_escape_str() does not support overlapping buffer first we check if
> > there is enough room in the buffer and then update a path. The side effect of
> > this change is in case of failure the buffer is left unchanged.

> >  char *mangle_path(char *s, const char *p, const char *esc)
> >  {

> > +     size_t len = p + strlen(p) - s;
> > +     int ret;
> > +
> > +     ret = string_escape_str(p, NULL, 0, ESCAPE_OCTAL, esc);
> > +     if (ret < len)
> > +             return s + string_escape_str(p, s, len, ESCAPE_OCTAL, esc);
> > +
> >       return NULL;
> >  }

> Confusing.
>
> I think the objective of the patch is to use an existing library
> function rather than open-coding, but the library function doesn't
> support in-place operation on the string.  So the old mangle_path() was
> OK with in-place conversion, but the new mangle_path() is not.  Is that
> correct?

As long as source buffer wouldn't be changed during conversion. Here
the same technique is used as in kasprintf(), i.e. first iteration we
would like to check if the buffer has enough size for the output, on
second do actual conversion.

Probably I need to add some test cases.

>  Do we know that all existing mangle_path() callers are OK
> with this?  Please make all this clear in the changelog.
>
> Also, the identifier `ret' is widely understood to mean "the value
> which this function will return", but that is not the case here.
> Please use a more appropriate identifier.

The meaning of it is a destination length. I will rename it.

-- 
With Best Regards,
Andy Shevchenko

      reply	other threads:[~2019-01-10  0:20 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-09 15:40 [PATCH v1] seq_file: convert mangle_path() to use string_escape_str() Andy Shevchenko
2019-01-09 18:04 ` Andrew Morton
2019-01-10  0:19   ` Andy Shevchenko [this message]

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=CAHp75VfZq7NhDX8c9EGa_4v-5nApiqF5RLbw49HO--H6h-YWnQ@mail.gmail.com \
    --to=andy.shevchenko@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=keescook@chromium.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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).