All of lore.kernel.org
 help / color / mirror / Atom feed
From: miquels@cistron.nl (Miquel van Smoorenburg)
To: linux-kernel@vger.kernel.org
Subject: Re: Random "File size limit exceeded" under 2.4
Date: Wed, 5 Dec 2001 22:33:19 +0000 (UTC)	[thread overview]
Message-ID: <9um7bf$lsp$1@ncc1701.cistron.net> (raw)
In-Reply-To: <1007573331.1809.6.camel@two> <3C0E813D.F5B1F84E@zip.com.au>

In article <3C0E813D.F5B1F84E@zip.com.au>,
Andrew Morton  <akpm@zip.com.au> wrote:
>Derek Glidden wrote:
>> 
>> I've been experiencing random and occasional encounters with "File size
>> limit exceeded" errors under 2.4 kernels when trying to make
>> filesystems.
>
>I don't know if anyone has come forth to fix this yet.
>
>Apparently it's something to do with your shell setting
>rlimits, and block devices are (bogusly) honouring those
>settings.

Perhaps the old app is calling sys_old_getrlimit() from
linux/kernel/sys.c. It truncates rlimits to 0x7FFFFFFF
if it's bigger than that. 0x7FFFFFFF used to be the old
RLIM_INFINITY in 2.2 [actually, ((long)(~0UL>>1))]. In
2.4, RLIM_INFINITY is (~0UL).

So if you call sys_setrlimit() with the old RLIM_INFINITY from 2.2
OR with the result from sys_old_getrlimit(), then the new limit
will be 0x7FFFFFFF instead of unlimited.

Looks like someone forgot to implement sys_old_setrlimit(),
which would have been the right thing to do.

Now all we can do is to hack sys_setrlimit and let it translate
0x7FFFFFFF to RLIM_INFINITY.

The following untested and uncompiled patch might do it, or not...

--- linux-2.4.17-pre2/kernel/sys.c.orig	Tue Sep 18 23:10:43 2001
+++ linux-2.4.17-pre2/kernel/sys.c	Wed Dec  5 23:30:50 2001
@@ -1120,6 +1120,16 @@
 		return -EINVAL;
 	if(copy_from_user(&new_rlim, rlim, sizeof(*rlim)))
 		return -EFAULT;
+#if !defined(__ia64__)
+	/*
+	 * 	In 2.2, RLIMIT_INFINITY was defined as ((long)(~0UL>>1)).
+	 * 	Reckognize it and translate it to the new RLIMIT_INFINITY.
+	 */
+	if ((long)new_rlim.rlim_cur == ((long)(~0UL>>1)))
+		new_rlim.rlim_cur = RLIMIT_INFINITY;
+	if ((long)new_rlim.rlim_max == ((long)(~0UL>>1)))
+		new_rlim.rlim_max = RLIMIT_INFINITY;
+#endif
 	old_rlim = current->rlim + resource;
 	if (((new_rlim.rlim_cur > old_rlim->rlim_max) ||
 	     (new_rlim.rlim_max > old_rlim->rlim_max)) &&

Mike.
-- 
"Only two things are infinite, the universe and human stupidity,
 and I'm not sure about the former" -- Albert Einstein.


  reply	other threads:[~2001-12-05 22:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-05 17:28 Random "File size limit exceeded" under 2.4 Derek Glidden
2001-12-05 20:19 ` Andrew Morton
2001-12-05 22:33   ` Miquel van Smoorenburg [this message]
2001-12-15  7:40     ` Ken Brownfield

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='9um7bf$lsp$1@ncc1701.cistron.net' \
    --to=miquels@cistron.nl \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.