linux-ext4 - -ENOSPC return from xattr functions

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>] [day] [month] [year] [list]

Message-ID: <20070713162733.GI5880@schatzie.adilger.int>
Date:	Fri, 13 Jul 2007 10:27:33 -0600
From:	Andreas Dilger <adilger@...sterfs.com>
To:	Andreas Gruenbacher <agruen@...e.de>
Cc:	linux-ext4@...r.kernel.org
Subject: -ENOSPC return from xattr functions

Hello Andreas,
I noticed in ext3_xattr_block_set() that if i->value_len > sb->s_blocksize
it returns -ENOSPC.  However, in ext3_xattr_set_handle() it returns -ERANGE
when the name length is > 255.

It seems a bit misleading to return -ENOSPC when the filesystem isn't
actually out of space.  I think it would probably make more sense to
return -ERANGE or -EOVERFLOW in this case.

Also, I don't know if you noticed in "[EXT4 set 5][PATCH 1/1] expand inode
i_extra_isize to support features in larger inode" the discussion about
GFP_KERNEL allocations under xattr_sem.  It seems there is risk of deadlock
in this case because we are inside a journal handle and might get blocked
waiting on a new journal_start() trying to flush memory.

Should these allocations be GFP_NOFS instead?  They shouldn't be a big
source of memory contention because the buffer is freed immediately at
the end of the function.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

-
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