Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1617906 > unrolled thread

[PATCH 1/5] bh: Prevent panic on invalid BHs

Started byDmitry Monakhov <dmonakhov@openvz.org>
First post2017-04-06 14:10 +0200
Last post2017-04-06 18:10 +0200
Articles 3 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  [PATCH 1/5] bh: Prevent panic on invalid BHs Dmitry Monakhov <dmonakhov@openvz.org> - 2017-04-06 14:10 +0200
    Re: [PATCH 1/5] bh: Prevent panic on invalid BHs Christoph Hellwig <hch@infradead.org> - 2017-04-06 17:50 +0200
      Re: [PATCH 1/5] bh: Prevent panic on invalid BHs Dmitry Monakhov <dmonakhov@openvz.org> - 2017-04-06 18:10 +0200

#1617906 — [PATCH 1/5] bh: Prevent panic on invalid BHs

FromDmitry Monakhov <dmonakhov@openvz.org>
Date2017-04-06 14:10 +0200
Subject[PATCH 1/5] bh: Prevent panic on invalid BHs
Message-ID<tteoF-8jD-5@gated-at.bofh.it>
- Convert BUG_ON to WARN_ON+EIO on submit_bh.
  Leave BUG_ON(!bh->b_end_io) as is because this is static bug in
  submission logic which can not be handled at runtime anyway.
  unmapped BH is also special case which signal about user
 misbehavior, so just dump error messageю

- guard __find_get_block from null pointer bdev.

Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
---
 fs/buffer.c | 24 +++++++++++++++++++-----
 1 file changed, 19 insertions(+), 5 deletions(-)

diff --git a/fs/buffer.c b/fs/buffer.c
index 9196f2a..4c8ce74 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -1355,8 +1355,12 @@ lookup_bh_lru(struct block_device *bdev, sector_t block, unsigned size)
 struct buffer_head *
 __find_get_block(struct block_device *bdev, sector_t block, unsigned size)
 {
-	struct buffer_head *bh = lookup_bh_lru(bdev, block, size);
+	struct buffer_head *bh;
+
+	if (WARN_ON_ONCE(!bdev))
+		return NULL;
 
+	bh = lookup_bh_lru(bdev, block, size);
 	if (bh == NULL) {
 		/* __find_get_block_slow will mark the page accessed */
 		bh = __find_get_block_slow(bdev, block);
@@ -3099,11 +3103,18 @@ static int submit_bh_wbc(int op, int op_flags, struct buffer_head *bh,
 {
 	struct bio *bio;
 
-	BUG_ON(!buffer_locked(bh));
-	BUG_ON(!buffer_mapped(bh));
 	BUG_ON(!bh->b_end_io);
-	BUG_ON(buffer_delay(bh));
-	BUG_ON(buffer_unwritten(bh));
+
+	if (WARN_ON_ONCE(!buffer_locked(bh)))
+		goto bad_bh;
+	if (WARN_ON_ONCE(buffer_delay(bh)))
+		goto bad_bh;
+	if (WARN_ON_ONCE(buffer_unwritten(bh)))
+		goto bad_bh;
+	if (unlikely(!buffer_mapped(bh))) {
+		buffer_io_error(bh, ", bh not mapped");
+		goto bad_bh;
+	}
 
 	/*
 	 * Only clear out a write error when rewriting
@@ -3143,6 +3154,9 @@ static int submit_bh_wbc(int op, int op_flags, struct buffer_head *bh,
 
 	submit_bio(bio);
 	return 0;
+bad_bh:
+	bh->b_end_io(bh, 0);
+	return -EIO;
 }
 
 int _submit_bh(int op, int op_flags, struct buffer_head *bh,
-- 
2.9.3

[toc] | [next] | [standalone]


#1618120

FromChristoph Hellwig <hch@infradead.org>
Date2017-04-06 17:50 +0200
Message-ID<tthPA-2yp-11@gated-at.bofh.it>
In reply to#1617906
This look ok, but how did you manage to trigger this case?  I think
we might have a deeper problem here.

[toc] | [prev] | [next] | [standalone]


#1618142

FromDmitry Monakhov <dmonakhov@openvz.org>
Date2017-04-06 18:10 +0200
Message-ID<tti8W-33D-21@gated-at.bofh.it>
In reply to#1618120
Christoph Hellwig <hch@infradead.org> writes:

> This look ok, but how did you manage to trigger this case? 

# testcases
# TEST1
# Via bug in fallocate
truncate -l 1G img
losetup  /dev/loop img
mkfs.ext4 -qF /dev/loop0
mkdir m
mount /dev/loop0 m
# command above truncate bdevs pagecache
xfs_io -c "falloc -k 0 32G" -d /dev/loop0
for ((i=0;i<100;i++));do
    xfs_io -c "pwrite 0 4k" -d m/test-$i;
done
sync



# TEST2: NBD close_sock -> kill_bdev
mkdir  -p a/mnt
cd a
truncate -s 1G img
mkfs.ext4 -qF img
qemu-nbd -c /dev/nbd0 img
mount /dev/nbd0 /mnt
cp -r /bin/ /mnt&
# Disconnect nbd while cp is active
qemu-nbd -d /dev/nbd0
sync

> I think
> we might have a deeper problem here.
Probably. It seems that !buffer_locked(bh) case should stay BUG_ON
because it is hard to make semi-correct decesion here.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web