Looks good as the lesser evil:
Reviewed-by: Christoph Hellwig
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.
On Feb 3, 2014, at 15:25, Christoph Hellwig wrote:
> On Mon, Feb 03, 2014 at 03:22:15PM -0500, Trond Myklebust wrote:
>> FWIW, here is the alternative patch. I've tested it, and it seems to
>> work.
>
> I much prefer the original one. One major point of the series was to
> get individual files
On Mon, Feb 03, 2014 at 03:22:15PM -0500, Trond Myklebust wrote:
> On Mon, 2014-02-03 at 10:45 -0500, Trond Myklebust wrote:
> > On Feb 3, 2014, at 9:57, Christoph Hellwig wrote:
> >
> > > On Mon, Feb 03, 2014 at 09:17:30AM -0500, Trond Myklebust wrote:
> > >> As I said above, that causes posix_a
On Mon, Feb 03, 2014 at 03:22:15PM -0500, Trond Myklebust wrote:
> FWIW, here is the alternative patch. I've tested it, and it seems to
> work.
I much prefer the original one. One major point of the series was to
get individual filesystems out of the business of providing xattr
handlers for ACLs.
On Mon, 2014-02-03 at 10:45 -0500, Trond Myklebust wrote:
> On Feb 3, 2014, at 9:57, Christoph Hellwig wrote:
>
> > On Mon, Feb 03, 2014 at 09:17:30AM -0500, Trond Myklebust wrote:
> >> As I said above, that causes posix_acl_xattr_get() to return the wrong
> >> answer (ENODATA instead of EOPNOTS
On Feb 3, 2014, at 9:57, Christoph Hellwig wrote:
> On Mon, Feb 03, 2014 at 09:17:30AM -0500, Trond Myklebust wrote:
>> As I said above, that causes posix_acl_xattr_get() to return the wrong
>> answer (ENODATA instead of EOPNOTSUPP).
>
> Is it really the wrong answer? How does userspace care
On Mon, Feb 03, 2014 at 09:17:30AM -0500, Trond Myklebust wrote:
> As I said above, that causes posix_acl_xattr_get() to return the wrong answer
> (ENODATA instead of EOPNOTSUPP).
Is it really the wrong answer? How does userspace care wether this
server doesn't support ACLs at all or none is set
At Mon, 3 Feb 2014 09:21:16 -0500,
Trond Myklebust wrote:
>
>
> On Feb 3, 2014, at 4:43, Takashi Iwai wrote:
>
> > At Sun, 02 Feb 2014 17:04:38 -0500,
> > Trond Myklebust wrote:
> >>
> >> On Sun, 2014-02-02 at 12:27 +, Russell King - ARM Linux wrote:
> >>> On Sat, Feb 01, 2014 at 01:03:28A
On Feb 3, 2014, at 4:43, Takashi Iwai wrote:
> At Sun, 02 Feb 2014 17:04:38 -0500,
> Trond Myklebust wrote:
>>
>> On Sun, 2014-02-02 at 12:27 +, Russell King - ARM Linux wrote:
>>> On Sat, Feb 01, 2014 at 01:03:28AM +, Russell King - ARM Linux wrote:
On Fri, Jan 31, 2014 at 03:59:3
On Feb 3, 2014, at 3:03, Christoph Hellwig wrote:
> On Fri, Jan 31, 2014 at 03:59:30PM -0500, Trond Myklebust wrote:
>> posix_acl_xattr_get requires get_acl() to return EOPNOTSUPP if the
>> filesystem cannot support acls. This is needed for NFS, which can't
>> know whether or not the server supp
At Sun, 02 Feb 2014 17:04:38 -0500,
Trond Myklebust wrote:
>
> On Sun, 2014-02-02 at 12:27 +, Russell King - ARM Linux wrote:
> > On Sat, Feb 01, 2014 at 01:03:28AM +, Russell King - ARM Linux wrote:
> > > On Fri, Jan 31, 2014 at 03:59:30PM -0500, Trond Myklebust wrote:
> > > > On Thu, 201
On Fri, Jan 31, 2014 at 03:59:30PM -0500, Trond Myklebust wrote:
> posix_acl_xattr_get requires get_acl() to return EOPNOTSUPP if the
> filesystem cannot support acls. This is needed for NFS, which can't
> know whether or not the server supports acls until it tries to get/set
> one.
> This patch co
On Sun, 2014-02-02 at 12:27 +, Russell King - ARM Linux wrote:
> On Sat, Feb 01, 2014 at 01:03:28AM +, Russell King - ARM Linux wrote:
> > On Fri, Jan 31, 2014 at 03:59:30PM -0500, Trond Myklebust wrote:
> > > On Thu, 2014-01-30 at 15:38 +, Russell King - ARM Linux wrote:
> > > > On Thu
On Sat, Feb 01, 2014 at 01:03:28AM +, Russell King - ARM Linux wrote:
> On Fri, Jan 31, 2014 at 03:59:30PM -0500, Trond Myklebust wrote:
> > On Thu, 2014-01-30 at 15:38 +, Russell King - ARM Linux wrote:
> > > On Thu, Jan 30, 2014 at 06:32:08AM -0800, Christoph Hellwig wrote:
> > > > On Thu
On Fri, Jan 31, 2014 at 03:59:30PM -0500, Trond Myklebust wrote:
> On Thu, 2014-01-30 at 15:38 +, Russell King - ARM Linux wrote:
> > On Thu, Jan 30, 2014 at 06:32:08AM -0800, Christoph Hellwig wrote:
> > > On Thu, Jan 30, 2014 at 02:27:52PM +, Russell King - ARM Linux wrote:
> > > > Yes an
On Thu, 2014-01-30 at 15:38 +, Russell King - ARM Linux wrote:
> On Thu, Jan 30, 2014 at 06:32:08AM -0800, Christoph Hellwig wrote:
> > On Thu, Jan 30, 2014 at 02:27:52PM +, Russell King - ARM Linux wrote:
> > > Yes and no. I still end up with an empty /etc/mtab, but the file now
> > > exi
On Thu, Jan 30, 2014 at 12:17:04PM -0300, Ezequiel Garcia wrote:
> Hi Russell, Trond:
>
> On Thu, Jan 30, 2014 at 02:08:34PM +, Russell King - ARM Linux wrote:
> > I just booted Linus' tip (plus a few other patches to imx-drm and imx
> > code), and stumbled into this interesting scenario:
> >
On Thu, Jan 30, 2014 at 06:32:08AM -0800, Christoph Hellwig wrote:
> On Thu, Jan 30, 2014 at 02:27:52PM +, Russell King - ARM Linux wrote:
> > Yes and no. I still end up with an empty /etc/mtab, but the file now
> > exists. However, I can create and echo data into /etc/mtab, but it seems
> >
Hi Russell, Trond:
On Thu, Jan 30, 2014 at 02:08:34PM +, Russell King - ARM Linux wrote:
> I just booted Linus' tip (plus a few other patches to imx-drm and imx
> code), and stumbled into this interesting scenario:
>
[..]
> CONFIG_NFS_FS=y
> CONFIG_NFS_V2=y
> CONFIG_NFS_V3=y
> CONFIG_NFS_V3_
On Jan 30, 2014, at 9:30, Russell King - ARM Linux
wrote:
> On Thu, Jan 30, 2014 at 09:17:00AM -0500, Trond Myklebust wrote:
>>
>> On Jan 30, 2014, at 9:08, Russell King - ARM Linux
>> wrote:
>>
>>> I just booted Linus' tip (plus a few other patches to imx-drm and imx
>>> code), and stumble
On Thu, Jan 30, 2014 at 09:17:00AM -0500, Trond Myklebust wrote:
>
> On Jan 30, 2014, at 9:08, Russell King - ARM Linux
> wrote:
>
> > I just booted Linus' tip (plus a few other patches to imx-drm and imx
> > code), and stumbled into this interesting scenario:
> >
> > # touch test
> > touch: c
On Thu, Jan 30, 2014 at 02:27:52PM +, Russell King - ARM Linux wrote:
> Yes and no. I still end up with an empty /etc/mtab, but the file now
> exists. However, I can create and echo data into /etc/mtab, but it seems
> that can't happen at boot time.
Odd. Can you disable CONFIG_NFSD_V3_ACL f
On Thu, Jan 30, 2014 at 06:14:05AM -0800, Christoph Hellwig wrote:
> On Thu, Jan 30, 2014 at 02:08:34PM +, Russell King - ARM Linux wrote:
> > into nfs3_proc_create(), but this ends up calling down into nfs3_get_acl(),
> > which does this:
> >
> > if (!nfs_server_capable(inode, NFS_CAP
On Thu, Jan 30, 2014 at 02:08:34PM +, Russell King - ARM Linux wrote:
> into nfs3_proc_create(), but this ends up calling down into nfs3_get_acl(),
> which does this:
>
> if (!nfs_server_capable(inode, NFS_CAP_ACLS))
> return ERR_PTR(-EOPNOTSUPP);
Does replacing that r
On Jan 30, 2014, at 9:08, Russell King - ARM Linux
wrote:
> I just booted Linus' tip (plus a few other patches to imx-drm and imx
> code), and stumbled into this interesting scenario:
>
> # touch test
> touch: cannot touch `test': Operation not supported
>
> I also tried mkdir and mknod, all
I just booted Linus' tip (plus a few other patches to imx-drm and imx
code), and stumbled into this interesting scenario:
# touch test
touch: cannot touch `test': Operation not supported
I also tried mkdir and mknod, all result in the same error. Hard and
symlinks links are creatable.
However,
26 matches
Mail list logo
