The process involved was a mail delivery utility called tmail (part of
imap-utils which complements the UW imapd package). The user (a test
username) was at or just below quota. tmail was trying to deliver into
an INBOX file (in mbx format) which already existed of size 2766 bytes.
strace showed tmail doing roughly the following:
open("/foo/bar/INBOX", O_RDWR|O_CREAT, 0600) = 5
fstat(5, {st_mode=0, st_size=2766, ...}) = 0
lseek(5, 2766, SEEK_SET) = 2766
write(5, "09-Feb-1999 13:22:55 +0000,26208"..., 56) = 56
write(5, "Received: via tmail-4.1(10) (inv"..., 26208) = 1276
write(5, "********************************"..., 24576) = -1 EFAULT (Bad address)
This was reproducible. The above strace, however, is reconstructed
from memory. The two figures 26208 and 1276 are the only things I'm
not certain I've remembered correctly (just in case the problem
depends on precise details of 512-block v. 4k page things).
After deleting files to go back under quota and then going back to
just under/at the quota limit, the write started giving EDQUOT as
expected.
I've looked though fs/read_write.c, ext2/file.c, ext2/inode.c and
ext2/balloc.c and tried to follow the call chain sys_write,_file_write,
ext2_getblk, ext2_getblk/block_getblk, ext2_alloc_block, ext2_new_block
and I can't find anywhere where an EFAULT would creep in (it's
certainly seems not to be from a verify_area). Could it possible be
from somewhere like ext2_getblk where there are some lines like
"bh = inode_getblk" which aren't checked for NULL returns? They could
fail for quota reasons (perhaps unexpectedly in the middle of
allocating several blocks for indirect stuff) and the callers could be
trying to do something nasty by writing to never-created buffers.
--Malcolm
-- Malcolm Beattie <mbeattie@sable.ox.ac.uk> Unix Systems Programmer Oxford University Computing Services- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/