All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Laurent Vivier <laurent@vivier.eu>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
	Patch Tracking <patches@linaro.org>,
	Riku Voipio <riku.voipio@iki.fi>
Subject: Re: [Qemu-devel] [PATCH 14/18] linux-user: Use __get_user() and __put_user() to handle structs in do_fcntl()
Date: Tue, 7 Jun 2016 22:20:54 +0100	[thread overview]
Message-ID: <CAFEAcA8sR=B9pmhDfJygK6ob59pBk+Hfu0409ZLJp2pDW79+LQ@mail.gmail.com> (raw)
In-Reply-To: <8e7c37a6-2df3-0c1c-e52c-07c2676195ea@vivier.eu>

On 7 June 2016 at 21:41, Laurent Vivier <laurent@vivier.eu> wrote:
>
> Le 06/06/2016 à 20:58, Peter Maydell a écrit :
>> Use the __get_user() and __put_user() to handle reading and writing the
>> guest structures in do_ioctl(). This has two benefits:
>>  * avoids possible errors due to misaligned guest pointers
>>  * correctly sign extends signed fields (like l_start in struct flock)
>>    which might be different sizes between guest and host
>>
>> To do this we abstract out into copy_from/to_user functions. We
>> also standardize on always using host flock64 and the F_GETLK64
>> etc flock commands, as this means we always have 64 bit offsets
>> whether the host is 64-bit or 32-bit and we don't need to support
>> conversion to both host struct flock and struct flock64.
>>
>> In passing we fix errors in converting l_type from the host to
>> the target (where we were doing a byteswap of the host value
>> before trying to do the convert-bitmasks operation rather than
>> otherwise, and inexplicably shifting left by 1).
>
> I  think the ">> 1" is coming from:
>
> 43f238d Support fcntl F_GETLK64, F_SETLK64, F_SETLKW64
>
> to convert arm to x86, and should have been removed then in:
>
> 2ba7f73 alpha-linux-user: Translate fcntl l_type
>
> So yes, the ">> 1" is wrong. I don't understand how it can work.

Thanks for tracking down where it came from. I suspect it
just didn't work and nobody noticed, because:
 * there's not much use of big-on-little-endian
 * a lot of the time the bug is just going to downgrade an
   exclusive lock to a shared lock, and you won't notice if
   there isn't actually any contention on the lock...

>> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
>> ---
>>  linux-user/syscall.c | 280 +++++++++++++++++++++++++++++----------------------
>>  1 file changed, 157 insertions(+), 123 deletions(-)
>>
>> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
>> index 4cf67c8..f3a487e 100644
>> --- a/linux-user/syscall.c
>> +++ b/linux-user/syscall.c
>> @@ -4894,11 +4894,11 @@ static int target_to_host_fcntl_cmd(int cmd)
>>       case TARGET_F_SETFL:
>>              return cmd;
>>          case TARGET_F_GETLK:
>> -         return F_GETLK;
>> -     case TARGET_F_SETLK:
>> -         return F_SETLK;
>> -     case TARGET_F_SETLKW:
>> -         return F_SETLKW;
>> +            return F_GETLK64;
>> +        case TARGET_F_SETLK:
>> +            return F_SETLK64;
>> +        case TARGET_F_SETLKW:
>> +            return F_SETLKW64;
>>       case TARGET_F_GETOWN:
>>           return F_GETOWN;
>>       case TARGET_F_SETOWN:
>
> I see no reason to have this in this patch.

The idea is that we want to use only one host flock struct,
which means it must be the one which supports 64-bit offsets.
On a 32-bit host, that's the flock64 struct, which must be
used with the F_GETLK64 fcntl, not F_GETLK.
On a 64-bit host, the system headers define that F_GETLK64
and F_GETLK are identical (and that the flock64 struct is flock),
so instead of having to specialcase 64-bit hosts, we can just
say "use the F_*64 constants and struct flock64 everywhere".

If we didn't have this hunk of the patch then on a 32-bit
host the code below would go wrong, because when we did
a guest F_GETLK we'd end up passing a (host) struct flock64
to the 32-bit F_GETLK.

>>      case TARGET_F_GETLK:
>> -        if (!lock_user_struct(VERIFY_READ, target_fl, arg, 1))
>> +        if (copy_from_user_flock(&fl64, arg)) {
>>              return -TARGET_EFAULT;
>
> why do you ignore the exact value returned by copy_from_user_flock()?
> You should return this value instead of guessing it.

Yeah, I was being lazy and not wanting to have an extra 'ret'
variable floating around. I'll fix this.

>> -        fl64.l_type =
>> -           target_to_host_bitmask(tswap16(target_fl64->l_type), flock_tbl) >> 1;
>
> The ">> 1" disappears...

...and it's correct that it disappears, right?

thanks
-- PMM

  reply	other threads:[~2016-06-07 21:21 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-06 18:58 [Qemu-devel] [PATCH 00/18] linux-user: Extend safe_syscall wrapper use Peter Maydell
2016-06-06 18:58 ` [Qemu-devel] [PATCH 01/18] linux-user: Use safe_syscall wrapper for readv and writev syscalls Peter Maydell
2016-06-06 18:58 ` [Qemu-devel] [PATCH 02/18] linux-user: Use safe_syscall wrapper for connect syscall Peter Maydell
2016-06-06 18:58 ` [Qemu-devel] [PATCH 03/18] linux-user: Use safe_syscall wrapper for send* and recv* syscalls Peter Maydell
2016-06-06 18:58 ` [Qemu-devel] [PATCH 04/18] linux-user: Use safe_syscall wrapper for msgsnd and msgrcv Peter Maydell
2016-06-06 18:58 ` [Qemu-devel] [PATCH 05/18] linux-user: Use safe_syscall wrapper for mq_timedsend and mq_timedreceive Peter Maydell
2016-06-06 18:58 ` [Qemu-devel] [PATCH 06/18] linux-user: Use safe_syscall wrapper for flock Peter Maydell
2016-06-06 18:58 ` [Qemu-devel] [PATCH 07/18] linux-user: Use safe_syscall wrapper for rt_sigtimedwait syscall Peter Maydell
2016-06-06 18:58 ` [Qemu-devel] [PATCH 08/18] linux-user: Use safe_syscall wrapper for sleep syscalls Peter Maydell
2016-06-06 18:58 ` [Qemu-devel] [PATCH 09/18] linux-user: Use safe_syscall wrapper for poll and ppoll syscalls Peter Maydell
2016-06-06 18:58 ` [Qemu-devel] [PATCH 10/18] linux-user: Use safe_syscall wrapper for epoll_wait syscalls Peter Maydell
2016-06-06 18:58 ` [Qemu-devel] [PATCH 11/18] linux-user: Use safe_syscall wrapper for semop Peter Maydell
2016-06-06 18:58 ` [Qemu-devel] [PATCH 12/18] linux-user: Use safe_syscall wrapper for accept and accept4 syscalls Peter Maydell
2016-06-06 18:58 ` [Qemu-devel] [PATCH 13/18] linux-user: Use safe_syscall wrapper for ioctl Peter Maydell
2016-06-06 18:58 ` [Qemu-devel] [PATCH 14/18] linux-user: Use __get_user() and __put_user() to handle structs in do_fcntl() Peter Maydell
2016-06-07 20:41   ` Laurent Vivier
2016-06-07 21:20     ` Peter Maydell [this message]
2016-06-08  9:33       ` Laurent Vivier
2016-06-06 18:58 ` [Qemu-devel] [PATCH 15/18] linux-user: Correct signedness of target_flock l_start and l_len fields Peter Maydell
2016-06-07 20:00   ` Laurent Vivier
2016-06-06 18:58 ` [Qemu-devel] [PATCH 16/18] linux-user: Use safe_syscall wrapper for fcntl Peter Maydell
2016-06-06 18:58 ` [Qemu-devel] [PATCH 17/18] linux-user: Make target_strerror() return 'const char *' Peter Maydell
2016-06-07 19:56   ` Laurent Vivier
2016-06-06 18:58 ` [Qemu-devel] [PATCH 18/18] linux-user: Special-case ERESTARTSYS in target_strerror() Peter Maydell
2016-06-07 19:53   ` Laurent Vivier
2016-06-07 21:31     ` Peter Maydell
2016-06-08  9:20 ` [Qemu-devel] [PATCH 00/18] linux-user: Extend safe_syscall wrapper use Riku Voipio
2016-06-08 11:26   ` Peter Maydell

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='CAFEAcA8sR=B9pmhDfJygK6ob59pBk+Hfu0409ZLJp2pDW79+LQ@mail.gmail.com' \
    --to=peter.maydell@linaro.org \
    --cc=laurent@vivier.eu \
    --cc=patches@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=riku.voipio@iki.fi \
    /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.