| 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
| ||
|
Message-ID: <20070517114250.GA2141@chiva> Date: Thu, 17 May 2007 13:42:50 +0200 From: Johann Lombardi <johann@...sterfs.com> To: Andrew Morton <akpm@...ux-foundation.org> Cc: linux-kernel@...r.kernel.org Subject: Re: Clear PG_error before reading a page On Wed, May 16, 2007 at 09:12:17AM -0700, Andrew Morton wrote: > > Basically, my problem is that afterwards, when the device no longer returns > > any errors, the PG_error flag is never cleared and, as a result, I keep > > getting -EIO. That's the problem I'd like to address. > > > > hm, OK. So, where are we up to? Once the errors reported by the underlying device are corrected, we must unmount/remount the filesystem if we want to use it. In fact, since readahead ignores I/O errors, the pagecache is populated with pages having the PG_error flag set and buffers attached. Since PG_error is then never cleared, we keep getting EIO despite that the underlying device works just fine. > What is the actual real-world operational scenario here? Would it be a > hotplugged disk? A transient network failure in a SAN? IOW, is it > something from which the kernel should automatically recover, or it is a > situation in which manual intervention would be better? The real-world operational scenario is a storage system reporting medium errors which can be corrected by a manual intervention. Johann - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists