linux-ext4 - Re: [RFC] Heads up on sys

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: <45E86858.20900@us.ibm.com>
Date:	Fri, 02 Mar 2007 10:09:28 -0800
From:	Mingming Cao <cmm@...ibm.com>
To:	Dave Kleikamp <shaggy@...ux.vnet.ibm.com>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	"Amit K. Arora" <aarora@...ux.vnet.ibm.com>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-ext4@...r.kernel.org, suparna@...ibm.com, alex@...sterfs.com,
	suzuki@...ibm.com, Ulrich Drepper <drepper@...hat.com>
Subject: Re: [RFC] Heads up on sys_fallocate()

Dave Kleikamp wrote:
> On Thu, 2007-03-01 at 14:59 -0800, Andrew Morton wrote:
> 
>>On Thu, 01 Mar 2007 22:44:16 +0000
>>Dave Kleikamp <shaggy@...ux.vnet.ibm.com> wrote:
>>
>>
>>>On Thu, 2007-03-01 at 14:25 -0800, Andrew Morton wrote:
>>>
>>>>On Fri, 2 Mar 2007 00:04:45 +0530
>>>>"Amit K. Arora" <aarora@...ux.vnet.ibm.com> wrote:
>>>
>>>>>+asmlinkage long sys_fallocate(int fd, loff_t offset, loff_t len)
>>>>>+{
>>>>>+	struct file *file;
>>>>>+	struct inode *inode;
>>>>>+	long ret = -EINVAL;
>>>>>+	file = fget(fd);
>>>>>+	if (!file)
>>>>>+		goto out;
>>>>>+	inode = file->f_path.dentry->d_inode;
>>>>>+	if (inode->i_op && inode->i_op->fallocate)
>>>>>+		ret = inode->i_op->fallocate(inode, offset, len);
>>>>>+	else
>>>>>+		ret = -ENOTTY;
>>>>>+	fput(file);
>>>>>+out:
>>>>>+        return ret;
>>>>>+}
>>>>
>>>>ENOTTY is a bit unconventional - we often use EINVAL for this sort of
>>>>thing.  But EINVAL has other meanings for posix_fallocate() and isn't
>>>>really appropriate here anyway.  So I'm not sure what would be better...
>>>
>>>Would EINVAL (or whatever) make it back to the caller of
>>>posix_fallocate(), or would glibc fall back to its current
>>>implementation?
>>>
>>>Forgive me if I haven't put enough thought into it, but would it be
>>>useful to create a generic_fallocate() that writes zeroed pages for any
>>>non-existent pages in the range?  I don't know how glibc currently
>>>implements posix_fallocate(), but maybe the kernel could do it more
>>>efficiently, even in generic code.  Maybe we don't care, since the major
>>>file systems can probably do something better in their own code.
>>
>>Given that glibc already implements fallocate for all filesystems, it will
>>need to continue to do so for filesystems which don't implement this
>>syscall - otherwise applications would start breaking.
> 
> 
> I didn't make it clear, but my point was to call generic_fallocate if
> the file system did not define i_op->allocate().
> 
> if (inode->i_op && inode->i_op->fallocate)
> 	ret = inode->i_op->fallocate(inode, offset, len);
> else
> 	ret = generic_fallocate(inode, offset, len);
> 
> I'm not sure it's worth the effort, but I thought I'd throw the idea out
> there.
> 
I think this is useful.

Mingming

-
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