linux-ext4 - Re: [PATCH 1/2] ext4: Prevent panic for destroyed devices

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: <20160219051334.GC12743@thunk.org>
Date:	Fri, 19 Feb 2016 00:13:34 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Dmitry Monakhov <dmonakhov@...nvz.org>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 1/2] ext4: Prevent panic for destroyed devices

On Thu, Feb 18, 2016 at 12:35:34PM +0300, Dmitry Monakhov wrote:
> Hm...
> Actually there are many places where we submit BHs w/o checks
> nojournal code is full of such places.
> It looks like we need some sort of AOP_TRUNCATE_PAGE error code
> for generic buffer submission path

Might it be enough to simply return have submit_bh check for the
unmapped buffer and return EIO?  I'm not sure we need a magic error
code....

That being said, I've always wished that there was a struct super
operation, s_block_device_gone() that would allow information about
the status of the block device to be communicated up the storage
stack.  Another useful thing that might be useful is an indication
that for whatever reason, the storage device has turned read-only on
us (so we might as well remounte the file system read-only instead of
letting userspace continue to dirty pages that have no hope of getting
written out).

					- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html