Re: [Qemu-block] [PATCH] block: Don't lock /dev/null and /dev/zero automatically

[John Snow]

On 07/18/2018 11:41 PM, Fam Zheng wrote:
> On my Fedora 28, /dev/null is locked by some other process (couldn't
> inspect it due to the current lslocks limitation), so iotests 226 fails
> with some unexpected image locking errors because it uses qemu-io to
> open it.
> 
> Actually it's safe to not use any lock on /dev/null or /dev/zero.
> 
> Signed-off-by: Fam Zheng <address@hidden>
> ---
>  block/file-posix.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/block/file-posix.c b/block/file-posix.c
> index 60af4b3d51..8bf034108a 100644
> --- a/block/file-posix.c
> +++ b/block/file-posix.c
> @@ -503,7 +503,12 @@ static int raw_open_common(BlockDriverState *bs, QDict 
> *options,
>          s->use_lock = false;
>          break;
>      case ON_OFF_AUTO_AUTO:
> -        s->use_lock = qemu_has_ofd_lock();
> +        if (!strcmp(filename, "/dev/null") ||
> +                   !strcmp(filename, "/dev/zero")) {
> +            s->use_lock = false;
> +        } else {
> +            s->use_lock = qemu_has_ofd_lock();
> +        }
>          break;
>      default:
>          abort();
> 

I apparently caused a lot of failures with 226, oops!

Should we instead modify the test in this case to not attempt to take a
lock on a device we know cannot meaningfully store state, or is it your
preference to attempt to maintain such a list in the raw driver itself?

I guess we never want QEMU to try to lock things like /dev/zero, but I
don't know if there are more such pseudo-devices we should never try to
lock and if so, what common property unifies them such that we don't
have to maintain a list.