linux-kernel - Re: [PATCH v3 1/4] ext4: fix WARNING in ext4_expand_extra_isize

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: <Y5LJHI1cHDK0Stjq@mit.edu>
Date:   Fri, 9 Dec 2022 00:35:24 -0500
From:   "Theodore Ts'o" <tytso@....edu>
To:     Ye Bin <yebin@...weicloud.com>
Cc:     adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org,
        linux-kernel@...r.kernel.org, jack@...e.cz,
        Ye Bin <yebin10@...wei.com>,
        syzbot+4d99a966fd74bdeeec36@...kaller.appspotmail.com
Subject: Re: [PATCH v3 1/4] ext4: fix WARNING in ext4_expand_extra_isize_ea

In general, please don't use commit summaries like:

	ext4: fix WARNING in ext4_expand_extra_isize_ea

The commit summary should be a summary of what the change *does*.  A
description of *why* the change is needed is properly placed in the
body of the description.  So something like "ext4: clamp
EXT4_XATTR_SIZE_MAX to XATTR_SIZE_MAX" would be a better one-line
commit summary.

That being said, I've decided to not apply this patch.  A 16 MB
extended attribute size is not _that_ insane, although admittedly it's
quite bit larger than any other file system or OS supports (unless you
include Solaris and NTFS's alternate data forks as "extended
attributes").

I personally don't think the mm/page_alloc warning is that big of a
deal (even if it does cause a Syzbot report), and if you really do
care about suppressing the warning, using the kvmalloc() instead of
kmalloc() will do that --- and it does make ext4 friendly in the case
of where we are storing, say, a 30KB Windows ACL as an extended
attribute, since it avoided needing to make a order 3 page allocation.
(Which again, as far as I'm concerned, is more important than the
suppressing the page_alloc warning.)

We may ultimately decide to clamp EXT4_XATTR_SIZE_MAX to
XATTR_SIZE_MAX, but one could imagine some system attribute that in
the future might want to be larger than 32k, that wouldn't be accessed
via the standard xattr API.  That seems unlikely, but I want to keep
our options open.

Cheers,

					- Ted