All of lore.kernel.org
 help / color / mirror / Atom feed
From: piaojun <piaojun@huawei.com>
To: Eric Blake <eblake@redhat.com>, <virtio-fs@redhat.com>,
	<qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] virtiofsd: fix compile error if 'F_OFD_GETLK' not defined
Date: Tue, 30 Jul 2019 22:00:37 +0800	[thread overview]
Message-ID: <5D404D85.1050109@huawei.com> (raw)
In-Reply-To: <4ec43f2f-1d72-5fe1-3b93-2c75ee6f87b4@redhat.com>

Hi Eric,

On 2019/7/30 21:28, Eric Blake wrote:
> On 7/29/19 7:27 PM, piaojun wrote:
>> Use F_GETLK for fcntl when F_OFD_GETLK not defined.
> 
> Which system are you hitting this problem on?
> 
> The problem with F_GETLK is that it is NOT as safe as F_OFD_GETLK.
> 
> We already have fcntl_op_getlk and qemu_probe_lock_ops() in util/osdep.c
> to not only determine which form to use, but also to emit a warning to
> the end user if we had to fall back to the unsafe F_GETLK. Why is your
> code not reusing that logic?

virtiofsd compile error due to missed 'F_OFD_GETLK'. My kernel version is
3.10.

linux-PUALcm:/home/code/virtiofs/qemu # make -j 8 virtiofsd

make[1]: Entering directory `/home/code/virtiofs/qemu/slirp'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/code/virtiofs/qemu/slirp'
	CHK version_gen.h
  CC      contrib/virtiofsd/passthrough_ll.o
  CC      qapi/qapi-clone-visitor.o
  CC      qapi/qmp-event.o
  CC      qapi/qapi-util.o
  CC      qapi/qapi-builtin-types.o
  CC      qapi/qapi-types-audio.o
  CC      qapi/qapi-types-authz.o
  CC      qapi/qapi-types-block-core.o
contrib/virtiofsd/passthrough_ll.c: In function ‘lo_getlk’:
contrib/virtiofsd/passthrough_ll.c:1622:25: error: ‘F_OFD_GETLK’ undeclared (first use in this function)
  ret = fcntl(plock->fd, F_OFD_GETLK, lock);
                         ^
contrib/virtiofsd/passthrough_ll.c:1622:25: note: each undeclared identifier is reported only once for each function it appears in
contrib/virtiofsd/passthrough_ll.c: In function ‘lo_setlk’:
contrib/virtiofsd/passthrough_ll.c:1671:25: error: ‘F_OFD_SETLK’ undeclared (first use in this function)

> 
>>
>> Signed-off-by: Jun Piao <piaojun@huawei.com>
>> ---
>>  contrib/virtiofsd/passthrough_ll.c | 9 +++++++++
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/contrib/virtiofsd/passthrough_ll.c b/contrib/virtiofsd/passthrough_ll.c
>> index 9ae1381..757785b 100644
>> --- a/contrib/virtiofsd/passthrough_ll.c
>> +++ b/contrib/virtiofsd/passthrough_ll.c
>> @@ -1619,7 +1619,11 @@ static void lo_getlk(fuse_req_t req, fuse_ino_t ino,
>>  		return;
>>  	}
>>
>> +#ifdef F_OFD_GETLK
>>  	ret = fcntl(plock->fd, F_OFD_GETLK, lock);
>> +#else
>> +	ret = fcntl(plock->fd, F_GETLK, lock);
>> +#endif
> 
> Hmm. Since this is in contrib, you are trying to compile something that
> is independent of util/osdep.c (at least, I assume that's the case, as
> contrib/virtiofsd/ is not even part of qemu.git master yet - in which
> case, why is this not being squashed in to the patch introducing that
> file, rather than sent standalone).  On the other hand, that raises the
> question - who is trying to use virtiofsd on a kernel that is too old to
> provid F_OFD_GETLK?  Isn't the whole point of virtiofsd to be speeding
> up modern usage, at which point an old kernel is just gumming up the
> works?  It seems like you are better off letting compilation fail on a
> system that is too old to support decent F_OFD_GETLK, rather than
> silently falling back to something that is unsafe.

Perhaps reusing qemu_lock_fd() looks a better way to solve this.

Thanks,
Jun

> 



  reply	other threads:[~2019-07-30 14:02 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-30  0:27 [Qemu-devel] [PATCH] virtiofsd: fix compile error if 'F_OFD_GETLK' not defined piaojun
2019-07-30 12:22 ` [Virtio-fs] " Liam Merwick
2019-07-30 12:22   ` Liam Merwick
2019-07-30 13:08   ` piaojun
2019-07-30 13:28 ` [Virtio-fs] " Eric Blake
2019-07-30 13:28   ` Eric Blake
2019-07-30 14:00   ` piaojun [this message]
2019-08-01 14:20   ` [Virtio-fs] " Dr. David Alan Gilbert
2019-08-01 14:20     ` [Qemu-devel] [Virtio-fs] " Dr. David Alan Gilbert
2019-08-01 14:26     ` [Virtio-fs] [Qemu-devel] " Dr. David Alan Gilbert
2019-08-01 14:26       ` [Qemu-devel] [Virtio-fs] " Dr. David Alan Gilbert
2019-08-02  8:16       ` [Virtio-fs] [Qemu-devel] " piaojun
2019-08-02  8:16         ` [Qemu-devel] [Virtio-fs] " piaojun

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=5D404D85.1050109@huawei.com \
    --to=piaojun@huawei.com \
    --cc=eblake@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=virtio-fs@redhat.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.