linux-kernel - Re: [PATCH] loop: drop caches if offset or block

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPUE2uushZ3Zc6mt01q3OkSx63YmQLq7SKqAktdZVnrb9bVnHA@mail.gmail.com>
Date:   Wed, 13 Mar 2019 22:07:43 -0700
From:   Gwendal Grignou <gwendal@...omium.org>
To:     axboe@...nel.dk
Cc:     jaegeuk@...nel.org, linux-block@...r.kernel.org,
        linux-f2fs-devel@...ts.sourceforge.net,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] loop: drop caches if offset or block_size are changed

Jaegeuk,

We have observed an issue in production with this patch.
(ihttps://bugs.chromium.org/p/chromium/issues/detail?id=938958#c38)
If we mount -o loop,offset=... $file, mount will issue 2 ioctl back to back:
- LOOP_SET_FD
- LOOP_SET_STATUS64 with offset change.

Looking at kill_bdev, it calls truncate_inode_pages(). From its
comment, mapping->nrpages can still be non-zero:
"""
 * Note: When this function returns, there can be a page in the process of
 * deletion (inside __delete_from_page_cache()) in the specified range.  Thus
 * mapping->nrpages can be non-zero when this function returns even after
 * truncation of the whole mapping.
"""
It is therefore possible to have truncated all the pages, but nr_page
still be !0.
We would fail the mount with -EAGAIN while it was perfectly valid.

Is the test for nrpages really necessary in the second part of the patch?

Gwendal.