linux-kernel - [PATCH 0/5] falloc on blockdevice: what possibly can go whong?

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-next>] [day] [month] [year] [list]

Message-Id: <1491480169-1889-1-git-send-email-dmonakhov@openvz.org>
Date:   Thu,  6 Apr 2017 16:02:44 +0400
From:   Dmitry Monakhov <dmonakhov@...nvz.org>
To:     linux-kernel@...r.kernel.org
Cc:     darrick.wong@...cle.com, axboe@...nel.dk, tytso@....edu,
        jack@...e.cz, hch@...radead.org,
        Dmitry Monakhov <dmonakhov@...nvz.org>
Subject: [PATCH 0/5] falloc on blockdevice:  what possibly can go whong?

If you saw a command "fallocate -k -l 1G /dev/vda" you probably think
that user want to preallocate space on thin-provision blkdev. Right?
What possibly can go wrong? Unfortunately you may destroy your filesystem
and kernel panic. The reason is the bug in blkdev_fallocate() which
unconditionally truncate bdev cache. But even if we fix this particular bug
there are other places where we still have to truncate blkdev cache even
if FS is mounted and holds some bh's

1) nbd: If server disconnected we call kill_bdev() which destroy bdev cache
2) bdev falloc{ FALLOC_FL_ZERO_RANGE, FALLOC_FL_PUNCH_HOLE } definitely
   expect bdev cache to be truncated.
3) ioctl: BLKDISCARD also must truncate bdev cache

There is a discussion whenever we have to permit (2) and (3) on bdev with
active filesytem, why shouldn't we force bd_claim for this? But this is
advisory user-space interface, because by historical reasons we allow
direct_io to blkdev while fs is mounted.

I prefer to treat all three cases while FS is mounted as runtime errors.
Fs may be corrupted, but we should not panic.
This patchset guard fs/blk layer from panic in case of such runtime errors.
0001-bh-Prevent-panic-on-invalid-BHs
0002-block-protect-bdevname-from-null-pointer-bdev
0003-bio-Protect-submit_bio-from-bdevless-bio-s
0004-jbd2-use-stable-bdev-pointer
# Finally fix the bug with unconditional cache truncate on bdev
0005-block-truncate-page-cache-only-when-necessary-on-falloc

Testcases:
  xfstests: ./check blockdev/004 blockdev/005
  https://github.com/dmonakhov/xfstests/tree/blkdev-falloc-tests-v1

TODO: Prepare patch for util-linux fallocate(2) should claim bdev.