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:	Thu, 4 Jun 2015 10:39:53 +0200
From:	Jan Kara <jack@...e.cz>
To:	linux-mm@...ck.org
Cc:	linux-fsdevel@...r.kernel.org, xfs@....sgi.com, mfasheh@...e.de,
	mgorman@...e.de, linux-ext4@...r.kernel.org
Subject: Rules for calling ->releasepage()

  Hello,

  we were recently debugging an issue where customer was hitting warnings
in xfs_vm_releasepage() which was complaining that the page it was called
for has delay-allocated buffers. After some debugging we realized that
indeed try_to_release_page() call from shrink_active_list() can happen for
a page in arbitrary state (that call happens only if
buffer_heads_over_limit is set so that is the reason why we normally don't
see that).

Hence comes my question: What are the rules for when can ->releasepage() be
called? And what is the expected outcome? We are certainly guaranteed to
hold page lock. try_to_release_page() also makes sure the page isn't under
writeback.  But what is ->releasepage() supposed to do with a dirty page?
Generally IFAIU we aren't supposed to discard dirty data but I wouldn't bet
on all filesystems getting it right because the common call paths make sure
page is clean. I would almost say we should enforce !PageDirty in
try_to_release_page() if it was not for that ext3 nastyness of cleaning
buffers under a dirty page - hum, but maybe the right answer for that is
ripping ext3 out of tree (which would also allow us to get rid of some code
in the blocklayer for bouncing journaled data buffers when stable writes
are required).

Thoughts?

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
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

Powered by blists - more mailing lists