All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yehuda Sadeh <yehuda@inktank.com>
To: Jeff Mitchell <jeffrey.mitchell@gmail.com>
Cc: Henry C Chang <henry.cy.chang@gmail.com>,
	Sage Weil <sage@inktank.com>,
	Aleksey Leonov <aleonov@nazarianin.com>,
	ceph-devel <ceph-devel@vger.kernel.org>
Subject: Re: test osd on zfs
Date: Wed, 17 Apr 2013 10:04:23 -0700	[thread overview]
Message-ID: <CABBk=J93+1TRnjtr5D2cJWmre+tf85hAw3H1JnOL8hwKJuHDJA@mail.gmail.com> (raw)
In-Reply-To: <516ECFB6.8090107@gmail.com>

On Wed, Apr 17, 2013 at 9:37 AM, Jeff Mitchell
<jeffrey.mitchell@gmail.com> wrote:
> Henry C Chang wrote:
>>
>> I looked into this problem earlier. The problem is that zfs does not
>> return ERANGE when the size of value buffer passed to getxattr is too
>> small. zfs returns with truncated xattr value.
>
>
> Is this a bug in ZFS, or simply different behavior?

Took a brief look at the zfs code, seems like a zfs bug.

diff --git a/module/zfs/zpl_xattr.c b/module/zfs/zpl_xattr.c
index c03764f..96db7dd 100644
--- a/module/zfs/zpl_xattr.c
+++ b/module/zfs/zpl_xattr.c
@@ -263,6 +263,9 @@ zpl_xattr_get_sa(struct inode *ip, const char
*name, void *value, size_t size)
        if (!size)
                return (nv_size);

+       if (size < nv_size)
+               return (-ERANGE);
+
        memcpy(value, nv_value, MIN(size, nv_size));

        return (MIN(size, nv_size));


This should fix it. Not tested of course.

Yehuda

  parent reply	other threads:[~2013-04-17 17:04 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <516E7D5C.7080309@nazarianin.com>
2013-04-17 15:19 ` test osd on zfs Sage Weil
2013-04-17 15:57   ` Henry C Chang
2013-04-17 16:37     ` Jeff Mitchell
2013-04-17 17:00       ` Henry C Chang
2013-04-17 17:00       ` Sage Weil
2013-04-17 17:04       ` Yehuda Sadeh [this message]
2013-04-17 17:05         ` Sage Weil
2013-04-17 17:15           ` Yehuda Sadeh
2013-04-17 18:06             ` Brian Behlendorf
2013-04-17 18:57             ` Brian Behlendorf
2013-04-17 19:07               ` Yehuda Sadeh
2013-04-17 19:09                 ` Stefan Priebe
2013-04-17 20:16                   ` Mark Nelson
2013-04-17 20:49                     ` Jeff Mitchell
2013-04-17 21:14                     ` Brian Behlendorf
2013-04-18  2:20                       ` Henry C Chang
2013-04-18  5:56                       ` Stefan Priebe - Profihost AG
2013-04-18 14:50                         ` Sage Weil
2013-04-18 20:07                           ` Alex Elsayed
2013-04-19 10:47                             ` Jeff Mitchell

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='CABBk=J93+1TRnjtr5D2cJWmre+tf85hAw3H1JnOL8hwKJuHDJA@mail.gmail.com' \
    --to=yehuda@inktank.com \
    --cc=aleonov@nazarianin.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=henry.cy.chang@gmail.com \
    --cc=jeffrey.mitchell@gmail.com \
    --cc=sage@inktank.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.