linux-kernel - Re: [PATCH -mm 0/2] Use freezeable workqueues to avoid suspend-related XFS corruptions

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: <200611202140.47322.rjw@sisk.pl>
Date:	Mon, 20 Nov 2006 21:40:46 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	nigel@...pend2.net
Cc:	David Chinner <dgc@....com>, Andrew Morton <akpm@...l.org>,
	LKML <linux-kernel@...r.kernel.org>, Pavel Machek <pavel@....cz>
Subject: Re: [PATCH -mm 0/2] Use freezeable workqueues to avoid suspend-related XFS corruptions

Hi,

On Monday, 20 November 2006 12:02, Nigel Cunningham wrote:
> Hi all.
> 
> I've did some testing this afternoon with bdev freezing disabled and
> without any non-vanilla code to freeze kthreads (Rafael's or my older
> version).

Thanks for testing this.

> If I put a BUG_ON() in submit_bio for non suspend2 I/O, it catches this
> trace:
> 
> submit_bio
> xfs_buf_iorequest
> xlog_bdstrat_cb
> xlog_state_release_iclog
> xlog_state_sync_all
> xfs_log_force
> xfs_syncsub
> xfs_sync
> vfs_sync
> vfs_sync_worker
> xfssyncd
> keventd_create_kthread

Well, this trace apparently comes from xfssyncd wich explicitly calls
try_to_freeze().  When does this happen?

> I haven't yet reproduced anything on another code path (eg pdflush).
> 
> So, it would appear that freezing kthreads without freezing bdevs should
> be a possible solution. It may however leave some I/O unsynced
> pre-resume and therefore result in possible dataloss if no resume
> occurs. I therefore wonder whether it's better to stick with bdev
> freezing

It looks like xfs is the only filesystem that really implements bdev freezing,
so for other filesystems it's irrelevant.  However, it may affect the dm, and
I'm not sure what happens if someone tries to use a swap file on a dm
device for the suspend _after_ we have frozen bdevs.

> or create some variant wherein XFS is taught to fully flush 
> pending writes and not create new I/O.

I think we should prevent filesystems from submitting any new I/O after
processes have been frozen, this way or another.

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller
-
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/