Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 10 Sep 2019 12:27:10 -0400 (EDT)
From:   Jan Stancek <jstancek@redhat.com>
To:     OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Cc:     linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
        systemd-devel@lists.freedesktop.org,
        Jan Stancek <jstancek@redhat.com>
Message-ID: <1802022622.11216716.1568132830207.JavaMail.zimbra@redhat.com>
In-Reply-To: <87r24o24eo.fsf@mail.parknet.co.jp>
References: <fc8878aeefea128c105c49671b2a1ac4694e1f48.1567468225.git.jstancek@redhat.com> <87v9u3xf5q.fsf@mail.parknet.co.jp> <339755031.10549626.1567969588805.JavaMail.zimbra@redhat.com> <87r24o24eo.fsf@mail.parknet.co.jp>
Subject: Re: [PATCH] fat: fix corruption in fat_alloc_new_dir()
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Thread-Topic: fix corruption in fat_alloc_new_dir()
Thread-Index: btCRHWvdReVkaymHhT2xSAQwL/tLmw==
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


----- Original Message -----
> Jan Stancek <jstancek@redhat.com> writes:
> 
> >> Using the device while mounting same device doesn't work reliably like
> >> this race. (getblk() is intentionally used to get the buffer to write
> >> new data.)
> >
> > Are you saying this is expected even if 'usage' is just read?
> 
> Yes, assuming exclusive access.

Seems we were lucky so far to only hit this with FAT.

I also tried couple variations of reproducer:

- Disabling udevd and running just "blkid --probe" in parallel
  also reproduced it
- Disabling udevd and running read() on first 1024 sectors in parallel
  also reproduced it
- aio_read() submitted prior to mount could reproduce it,
  as long as fd was held open
- I couldn't reproduce it with fadvise/madvise WILLNEED submitted prior to mount

> 
> >> mount(2) internally opens the device by EXCL mode, so I guess udev opens
> >> without EXCL (I dont know if it is intent or not).
> >
> > I gave this a try and added O_EXCL to udev-builtin-blkid.c. My system had
> > trouble
> > booting, it was getting stuck on mounting LVM volumes.
> >
> > So, I'm not sure how to move forward here.
> 
> OK. I'm still think the userspace should avoid to use blockdev while
> mounting though, this patch will workaround this race with small race.

https://systemd.io/BLOCK_DEVICE_LOCKING.html mentions flock(LOCK_EX) as a way
to avoid probing while "another program concurrently modifies a superblock or
partition table". Adding flock(LOCK_EX) works around the problem too, but that
would address problem only for LTP (and tools/scripts that use this approach).

> 
> Can you test this?
> 
> Thanks.
> --
> OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
> 
> 
> [PATCH] fat: Workaround the race with userspace's read via blockdev while
> mounting

I ran reproducer on patched kernel for 5 hours, it made over 25000 iterations,
there was no corruption. Thank you for looking at this.

Regards,
Jan