[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: VFS bug in 2.4.10+ which applies ulimits to block devices

Hello Stephen,

On Mon, Nov 26, 2001 at 04:10:13PM +0000, Stephen C. Tweedie wrote:
> Hi,
> On Mon, Nov 26, 2001 at 03:26:17PM +0100, Andrea Arcangeli wrote:
> > On Mon, Nov 26, 2001 at 10:00:39PM +0800, Yusuf Goolamabbas wrote:
> > > Hi Andrea, The following is a thread on ext3-users in which sct mentions
> > > that this is due to a core VFS bug introduced in 2.4.10 which applies
> > > ulimits to block devices. Maybe this could be due to some interaction
> > > with your blockdevice in pagecache
> > > 
> > > I don't know if you already have a fix in your tree. Maybe sct can
> > > provide you with more info
> > 
> > You need to upgrade glibc to something recent like 2.2.1, so that the
> > ulimit will be correctly set to ~0UL. We could also fix this problem in
> > the kernel but even if we do you will still run into troubles with LFS
> > with the mounted filesystems.
> I don't think that we should be applying _any_ of the LFS or ulimit
> logic to device inodes, should we?  It's not as if we're allocating
> space by writing beyond the ulimit max offset in this case.

I don't much connection between "allocation of space" and "maxfilesize
ulimit", the maxfile limit is about i_size, not i_blocks. We can run out
of the filesize ulimit without allocating any data space by simply
truncating an empty inode over the limit.

I certainly can see the backwards compatibility problem though.

If you're sure the current semantics are wrong for blkdev feel free to
add an IS_BLK check in generic_file_write (in vmtruncate it isn't
necessary, truncating a blkdev doesn't make sense anyways). This will
workaround the ulimit userspace breakage as well.

--- 2.4.15aa1/mm/filemap.c.~1~	Sat Nov 24 06:55:30 2001
+++ 2.4.15aa1/mm/filemap.c	Mon Nov 26 17:30:28 2001
@@ -2908,7 +2908,7 @@
 	err = -EFBIG;
-	if (limit != RLIM_INFINITY) {
+	if (!S_ISBLK(inode->i_mode) && limit != RLIM_INFINITY) {
 		if (pos >= limit) {
 			send_sig(SIGXFSZ, current, 0);
 			goto out;

I'd prefer if we wouldn't need to add the above (branch in a fast path)
but I can live with it.  Infact as you can see I had to add another
backwards compatibility cruft just before the rlimit checks:

	/* FIXME: this is for backwards compatibility with 2.4 */
	if (!S_ISBLK(inode->i_mode) && file->f_flags & O_APPEND)
		pos = inode->i_size;

and this above one I like even less but honouring O_APPEND was
triggering bugs in applications (they were wrongly opening the blkdev
with O_APPEND).


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]