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]
Date:	Tue, 29 Aug 2006 21:48:34 +0100
From:	Richard Purdie <rpurdie@...ys.net>
To:	LKML <linux-kernel@...r.kernel.org>
Subject: end_swap_bio_write error handling

I've been experimenting with a swap block device driver which under
certain conditions generates write failures for pages. I'd presumed the
kernel would recover from a write error by restoring the copy it still
has in memory. In an ideal world it would then mark that page of the
swap device as bad although I'm fairly sure this doesn't happen. I'm not
sure about the restoring the in memory page but if it does happen, I'm
having trouble identifying the code.

When I tested this, it doesn't appear to recover and processes on the
system, presumably the ones using swap just disappear when write
failures occur.

end_swap_bio_write() simply does:

if (!uptodate)
	SetPageError(page);

I know the uptodate flag is being cleared in the error cases. I'm having
trouble working out which code the setting of an error flag for a swap
page should trigger (any pointers appreciated!). I noticed its also used
for the read case which is unrecoverable.

Should this code be marking the page as dirty and the section of the
swap device as bad instead, does it already do that or is that not
possible for some reason?

Any comments and/or pointers to documentation on this would be
appreciated.

Thanks,

Richard

-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ