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 <f...@redhat.com>
> ---
> 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.
