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
