All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Vineeth Remanan Pillai <vineethp@amazon.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	kamatam@amazon.com, aliguori@amazon.com
Subject: Re: [PATCH] namei: revert old behaviour for filename_lookup with LOOKUP_PARENT flag
Date: Thu, 13 Oct 2016 22:24:04 +0100	[thread overview]
Message-ID: <20161013212404.GU19539@ZenIV.linux.org.uk> (raw)
In-Reply-To: <5d487c39-25e9-2903-1fd9-ca6d870c0e7b@amazon.com>

On Thu, Oct 13, 2016 at 01:41:11PM -0700, Vineeth Remanan Pillai wrote:

> Yes, the use case is out-of-tree and the code snippet above depicts the use
> .
> Since kern_path_locked is also not exported, out-of-tree code used kern_path
> for the existence check for directories.
> 
> One reference about this issue can be seen here.
> 
> http://www.gossamer-threads.com/lists/linux/kernel/2459690?do=post_view_flat#2459690

... and in that thread I have asked for details and got no reply whatsoever.
 
> We also have a customer who complained about this functionality change.
> 
> I understand that there has been no API promises been made to this API. But
> since this is an
> exported function, the change in function could cause break in out-of-tree
> kernel code. I will
> rephrase the commit message to say "change in functionality" instead of
> regression

In principle, I have no strong objections against exporting kern_path_locked,
provided it really matches what they (whoever they are) need.  I'm still
curious about the context, though - what is that code trying to do?  Depending
on the actual stuff it wants to implement, there might be better primitives
for doing that *and* there might be something worth adding and exporting
that would be a better match.

It's not that kern_path_locked() isn't a sane interface, but... using it
might be a sign of trying to work around something missing in API.  So again,
please post more details.

  parent reply	other threads:[~2016-10-13 21:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-13 19:58 [PATCH] namei: revert old behaviour for filename_lookup with LOOKUP_PARENT flag Vineeth Remanan Pillai
2016-10-13 20:06 ` Al Viro
2016-10-13 20:09 ` Christoph Hellwig
2016-10-13 20:26   ` Al Viro
2016-10-13 20:41     ` Vineeth Remanan Pillai
2016-10-13 20:44       ` Christoph Hellwig
2016-10-13 21:24       ` Al Viro [this message]
2016-10-13 22:14         ` Vineeth Remanan Pillai
2016-10-13 23:31           ` Al Viro
2016-10-14  0:02             ` Remanan Pillai, Vineeth

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=20161013212404.GU19539@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=aliguori@amazon.com \
    --cc=hch@infradead.org \
    --cc=kamatam@amazon.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vineethp@amazon.com \
    /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.