Re: 2.4.8 Resource leaks + limits

Re: 2.4.8 Resource leaks + limits

[Magnus Naeslund(f)]

From: "Rik van Riel" <riel@conectiva.com.br>
[snip]
> 
> Morale of the story:  whenever you find a bug, try if you
> can reproduce it with Alan's kernel ;)
> 

Ok, i got it.
I tried with 2.4.8ac5 and it seems to hold nicely.
Too bad this isn't so much documented.
The whole pam_limit thing is pretty poorly detailed.
Like the prio limit, it doesn't say what ranges and so on.
(well it's the same as nice, but it doesnt say that eihter i think :))

> Rik
> 

Magnus

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Programmer/Networker [|] Magnus Naeslund
 PGP Key: http://www.genline.nu/mag_pgp.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: 2.4.8 Resource leaks + limits

[Szabolcs Szakacsits]

On Fri, 17 Aug 2001, Rik van Riel wrote:
> The fix is to disable the check for RLIMIT_NPROC in
> kernel/fork.c when the user is root. I made this patch
> a while back for Conectiva's kernel RPM and sent it off
> to Alan and Linus.
> This fix was merged in the -ac kernels while Linus just
> ignored it.

That's funny. This problem came up in linux-kernel in last year
November by Jan Rekorajski purposing basically the same patch,
http://groups.google.com/groups?hl=en&safe=off&th=6507453d081541,15&seekm=linux.kernel.20001128221155.G2680%40sith.mimuw.edu.pl#p

Everybody told him, including Alan, go away and fix PAM. He went away
and fixed PAM in 2 days. Up to day none of the main distributions ship
the correct[ly configured] PAM, so the problem still bites. Feel free to
rebut me.

Personally I think Linus was right when he didn't apply the patch. If
one sets RLIMIT_NPROC even for root in a shell, he expects EAGAIN when
limit is hit and not to blow up the system.

	Szaka

Re: 2.4.8 Resource leaks + limits

[Rik van Riel]

On Sat, 18 Aug 2001, Szabolcs Szakacsits wrote:
> On Fri, 17 Aug 2001, Rik van Riel wrote:
> > The fix is to disable the check for RLIMIT_NPROC in
> > kernel/fork.c when the user is root. I made this patch

> Everybody told him, including Alan, go away and fix PAM. He went away
> and fixed PAM in 2 days. Up to day none of the main distributions ship
> the correct[ly configured] PAM, so the problem still bites. Feel free
> to rebut me.

Wouldn't that involve fixing login, sshd, and all other
programs using pam to set the limits before fork()ing ?

I know the pam library is responsible for setting the
user limits, but it's the program linked to libpam which
is responsible for the order in which the other things
are done, right ?

(then again, I don't know enough about the userspace side
of things here, I'd be happy if somebody could enlighten
me)

cheers,

Rik
--
IA64: a worthy successor to i860.

http://www.surriel.com/		http://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: 2.4.8 Resource leaks + limits

[Alan Cox]

> 
> On Sat, 18 Aug 2001, Szabolcs Szakacsits wrote:
> > On Fri, 17 Aug 2001, Rik van Riel wrote:
> > > The fix is to disable the check for RLIMIT_NPROC in
> > > kernel/fork.c when the user is root. I made this patch
> 
> > Everybody told him, including Alan, go away and fix PAM. He went away
> > and fixed PAM in 2 days. Up to day none of the main distributions ship
> > the correct[ly configured] PAM, so the problem still bites. Feel free
> > to rebut me.
> 
> Wouldn't that involve fixing login, sshd, and all other
> programs using pam to set the limits before fork()ing ?
> 
> I know the pam library is responsible for setting the
> user limits, but it's the program linked to libpam which
> is responsible for the order in which the other things
> are done, right ?
> 
> (then again, I don't know enough about the userspace side
> of things here, I'd be happy if somebody could enlighten
> me)
> 
> cheers,
> 
> Rik
> --
> IA64: a worthy successor to i860.
> 
> http://www.surriel.com/		http://distro.conectiva.com/
> 
> Send all your spam to aardvark@nl.linux.org (spam digging piggy)
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: 2.4.8 Resource leaks + limits

[Alan Cox]

Argh lets try that reply again.

> I know the pam library is responsible for setting the
> user limits, but it's the program linked to libpam which
> is responsible for the order in which the other things
> are done, right ?

Its really the pam modules job to do most of the work, and the order is
pretty much config driven

Re: 2.4.8 Resource leaks + limits

[Alan Cox]

> Linux has had (for a while now) a "struct user" that is actually quickly
> accessible through a direct pointer off every process that is associated
> with that user, and we could (and _will_) start adding these kinds of
> limits. However, part of the problem is that because the limits haven't
> historically existed, there is also no accepted and nice way of setting
> the limits.

For that to work we need to seperate struct user from the uid a little, or
provide heirarchical pools (which seems overcomplex). Its common to want
to take a group of users (eg the chemists) and give them a shared limit
rather than per user limits

Alan

Re: 2.4.8 Resource leaks + limits

[Linus Torvalds]

On Wed, 15 Aug 2001, Alan Cox wrote:
>
> > Linux has had (for a while now) a "struct user" that is actually quickly
> > accessible through a direct pointer off every process that is associated
> > with that user, and we could (and _will_) start adding these kinds of
> > limits. However, part of the problem is that because the limits haven't
> > historically existed, there is also no accepted and nice way of setting
> > the limits.
>
> For that to work we need to seperate struct user from the uid a little, or
> provide heirarchical pools (which seems overcomplex). Its common to want
> to take a group of users (eg the chemists) and give them a shared limit
> rather than per user limits

No, I think the answer there is to do all the same things for "struct
group" as we do for user.

Yes, it would mean that the primary group is _really_ primary, but from a
system management standpoint that's probably preferable (ie you can give
group read-write access to a person without giving group "resource" access
to him)

		Linus

Re: 2.4.8 Resource leaks + limits

[Alan Cox]

> Yes, it would mean that the primary group is _really_ primary, but from a
> system management standpoint that's probably preferable (ie you can give
> group read-write access to a person without giving group "resource" access
> to him)

Non unix systems generally have a separate accounting uid - one reason for
that is the problem of charging for setuid apps and things done in your
name. Otherwise its all too easy to attack a bug in a setuid app to make it
expand to fill memory.

I'd rather we had an luid or equivalent personally.

Alan

Re: 2.4.8 Resource leaks + limits

[Ingo Oeser]

On Wed, Aug 15, 2001 at 09:53:09AM -0700, Linus Torvalds wrote:
> > For that to work we need to seperate struct user from the uid a little, or
> > provide heirarchical pools (which seems overcomplex). Its common to want
> > to take a group of users (eg the chemists) and give them a shared limit
> > rather than per user limits
> 
> No, I think the answer there is to do all the same things for "struct
> group" as we do for user.
 
Not really. Large installations use ACLs instead of groups. 

Why? Because if we have 2^31 users, there might be a slight
chance, that we need more then 32 group memberships per user.

So let's better stop relying more and more on this group brain
damage and start supporting ACLs. We can support building ACL
groups, but please let the user and not the admin build them.

It's called user data, because the user owns it and should
decide, which people are allowed to access it. 

Please look at AFS groups, to see what I mean.

All serious admins I know miss the ACL feature in Linux. One
product even emulates them via groups.


Regards

Ingo Oeser
-- 
I just found out that the brain is like a computer.
If that's true, then there really aren't any stupid people.
Just people running Windows.

Re: 2.4.8 Resource leaks + limits

[Alan Cox]

> Not really. Large installations use ACLs instead of groups. 

Umm you can't use ACL's for resource management. You have to be able to
charge an entity. Its not a permission to access, its a "who is paying" and
that requires a real entity to charge to

Re: 2.4.8 Resource leaks + limits

[Jesse Pollard]

> > Not really. Large installations use ACLs instead of groups. 
> 
> Umm you can't use ACL's for resource management. You have to be able to
> charge an entity. Its not a permission to access, its a "who is paying" and
> that requires a real entity to charge to

And that calls for an accounting id or a project id. As well as the possiblity
of a user having multiple accounting ids.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: 2.4.8 Resource leaks + limits

[Anton Altaparmakov]

At 21:15 15/08/2001, Alan Cox wrote:
> > Not really. Large installations use ACLs instead of groups.
>
>Umm you can't use ACL's for resource management. You have to be able to
>charge an entity. Its not a permission to access, its a "who is paying" and
>that requires a real entity to charge to

While we are on this topic, wouldn't it make sense to introduce unique 
identifiers, which can be associated with users, groups, or any other 
kernel object for that matter, then this is the entity you charge. The 
kernel can then map the id to the user or group (or whatever object).

When ACLs are introduced they would grant/deny permissions and in general 
operate only on unique identifiers.

This would have the benefit that the identifiers can be made sufficiently 
unique to work on a whole network (or even larger scales), which would make 
user management much easier for large corporations, much akin to what 
Netware and Windows servers do in fact...

Just my 2p.

Anton


-- 
   "Nothing succeeds like success." - Alexandre Dumas
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: 2.4.8 Resource leaks + limits

[Jesse Pollard]

On Wed, 15 Aug 2001, Ingo Oeser wrote:
>On Wed, Aug 15, 2001 at 09:53:09AM -0700, Linus Torvalds wrote:
>> > For that to work we need to seperate struct user from the uid a little, or
>> > provide heirarchical pools (which seems overcomplex). Its common to want
>> > to take a group of users (eg the chemists) and give them a shared limit
>> > rather than per user limits
>> 
>> No, I think the answer there is to do all the same things for "struct
>> group" as we do for user.
> 
>Not really. Large installations use ACLs instead of groups. 
>
>Why? Because if we have 2^31 users, there might be a slight
>chance, that we need more then 32 group memberships per user.
>
>So let's better stop relying more and more on this group brain
>damage and start supporting ACLs. We can support building ACL
>groups, but please let the user and not the admin build them.
>
>It's called user data, because the user owns it and should
>decide, which people are allowed to access it. 
>
>Please look at AFS groups, to see what I mean.
>
>All serious admins I know miss the ACL feature in Linux. One
>product even emulates them via groups.

ACLs are good and very usefull.

HOWEVER, there are cases of users giving away their files to users
that are not authorized to recieve that data.

The advantage of groups is that the facility managment defines the
list of users authorized to view the data. It up to the user to
grant/deny that group access authorization.

Alternatively, it is possible to view the system as you describe - the
user can add others to the ACL to grant access. There should still be
some method that facility management can deny access.... On many systems
(Trusted Solaris, UNICOS, Trix,...) this is done with compartmentalization.
Now, it is subsets of the members of the compartment that the user can
grant access to.

Still more flexible than generic groups, but more restricted than no
limits on members of the ACL.

-- 
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: jesse@cats-chateau.net

Any opinions expressed are solely my own.

Re: 2.4.8 Resource leaks + limits

[Horst von Brand]

Linus Torvalds <torvalds@transmeta.com> said:

[...]

> No, I think the answer there is to do all the same things for "struct
> group" as we do for user.
> 
> Yes, it would mean that the primary group is _really_ primary, but from a
> system management standpoint that's probably preferable (ie you can give
> group read-write access to a person without giving group "resource" access
> to him)

No good. Some setups (e.g. Red Hat) have a group for each user.
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616

2.4.8 Resource leaks + limits

[Magnus Naeslund(f)]

Can anyone please explain something to me?
I saw Alan's comments on Ivan Kalvatchev's malloc "bomb".
So i thought maybe i should test to impose some limits, and try some changes
with Ivan's code.

Box:

Linux UltraSparc 2.4.8 #3 Tue Aug 14 01:03:31 CEST 2001 sparc64 unknown
(a Sun Ultra10)

Code:

--------8<-------8<-------8<-------8<-------8<-----------
struct entry { struct entry *next; char *p;} * head=0;

int main() {
   int i;
   struct entry *e;
   for(i=0;;i+=2*4) {
      if (!(e=malloc(4096)) || !(e->p = malloc(4096)))
        break;
      e->next = head;
      head = e;
      if (!(i%1024)) printf("malloc @ %dkb\n",i);
   }

   printf("Stopped at %dkb \nTouching-in-a-loop.\n",i);

   for (e=head ;; e=e->next?e->next:head )
     memset(e->p,++i % 256,4096);

   return 0;
}
--------8<-------8<-------8<-------8<-------8<-----------

Memory is (after run + swapoff + swapon):

[root@UltraSparc src]# free -m
             total       used       free     shared    buffers     cached
Mem:           122         38         83          0          1         17
-/+ buffers/cache:         20        101
Swap:         1057          0       1057

And the limits are:

*               -       rss             64000
*               -       memlock         32000
*               -       as              128000
*               -       data            64000
*               hard    nproc           50
*               soft    nproc           40
*               -       stack           666
*               soft    priority        16
*               hard    priority        12


I ran maybe 20-30 instances at once.
All process allocated the 64MB that it was allowed by the "data" limit.
The system went down to really crawling (but never locked up completly).
After a while the oom killer kicked in as well, when i ran out of swap+ram.

Question: why isn't there a limit for global memory usage per user?
No way could i stop these processes without decreasing the nproc stuff.
That's not really what one want's some time, you know :)

The more "real" issue here is that after this run i couldn't log on as
another user than root.
Even now (after swapoff -a and so) i can't log on as another user:

[root@UltraSparc src]# su -l mag2
can not fork user shell: Resource temporarily unavailable

How can i get my fargin resources back? :)

Nice that the system survived (kinda, took 15 min to get logged on via ssh
;) ), but it's not cool if i have to reboot anyways because my resources are
farged.

Can i do anything, or what?

Magnus

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Programmer/Networker [|] Magnus Naeslund
 PGP Key: http://www.genline.nu/mag_pgp.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: 2.4.8 Resource leaks + limits

[Linus Torvalds]

In article <3ce801c12548$b7971750$020a0a0a@totalmef> you write:
>
>Question: why isn't there a limit for global memory usage per user?

Answer: because traditionally Linux (or UNIX) hasn't had a good and
efficient way to have per-user statistics. 

This is why you mainly find per-process stuff in all the limits. 

Linux has had (for a while now) a "struct user" that is actually quickly
accessible through a direct pointer off every process that is associated
with that user, and we could (and _will_) start adding these kinds of
limits. However, part of the problem is that because the limits haven't
historically existed, there is also no accepted and nice way of setting
the limits.

Oh, well.

		Linus

Re: 2.4.8 Resource leaks + limits

[Ulrich Drepper]

Linus Torvalds <torvalds@transmeta.com> writes:

> However, part of the problem is that because the limits haven't
> historically existed, there is also no accepted and nice way of
> setting the limits.

This should be the least of the problems.  Simply add new RLIMIT_*
values[1] (and possibly [gs]etrlimit64 syscalls).  The shell's ulimit
command can easily pick those up.  Non-standard, but every other
solution will be, too.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: 2.4.8 Resource leaks + limits

[Nadav Har'El]

On Tue, Aug 14, 2001, Ulrich Drepper wrote about "Re: 2.4.8 Resource leaks + limits":
> Linus Torvalds <torvalds@transmeta.com> writes:
> 
> > However, part of the problem is that because the limits haven't
> > historically existed, there is also no accepted and nice way of
> > setting the limits.
> 
> This should be the least of the problems.  Simply add new RLIMIT_*
> values[1] (and possibly [gs]etrlimit64 syscalls).  The shell's ulimit
> command can easily pick those up.  Non-standard, but every other
> solution will be, too.

I don't see how this would work without confusing users. ulimit currently
fits the model where limits are enforced per process, because each process
can have its own different limits.
If add per-user limits, what do you do if the user has several processes with
different per-user limits? You'll need to have "ulimit" and the likes set a
per-user limit shared by all processes of this user, and the last one
set by any process "wins" and takes effect. But this will not be expected by
the users who expect ulimits to effect only children processes (e.g., now it's
common to lower a limit and fork/exec a program which you want to limit).

So it's doable this way, but the manuals will have to be very clear as to
which limits are inherited how.

-- 
Nadav Har'El                        |       Wednesday, Aug 15 2001, 26 Av 5761
nyh@math.technion.ac.il             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |I used to work in a pickle factory, until
http://nadav.harel.org.il           |I got canned.

Re: 2.4.8 Resource leaks + limits

[dmaynor]

> This is why you mainly find per-process stuff in all the limits. 
> 
> Linux has had (for a while now) a "struct user" that is actually quickly
> accessible through a direct pointer off every process that is associated
> with that user, and we could (and _will_) start adding these kinds of
> limits. However, part of the problem is that because the limits haven't
> historically existed, there is also no accepted and nice way of setting
> the limits.
So when you do impose this, where will it be setable, will there be a flat file in /etc
like solaris, or compile time for the kernel?

Re: 2.4.8 Resource leaks + limits

[J Sloan]

dmaynor@iceland.oit.gatech.edu wrote:

> > This is why you mainly find per-process stuff in all the limits.
> >
> > Linux has had (for a while now) a "struct user" that is actually quickly
> > accessible through a direct pointer off every process that is associated
> > with that user, and we could (and _will_) start adding these kinds of
> > limits. However, part of the problem is that because the limits haven't
> > historically existed, there is also no accepted and nice way of setting
> > the limits.
> So when you do impose this, where will it be setable, will there be a flat file in /etc
> like solaris, or compile time for the kernel?

Eh?

Why wouldn't it be like most parameters in Linux,
e.g. dynamically adjustable via a sysctl or /proc?

IMHO, of course...

cu

jjs

Re: 2.4.8 Resource leaks + limits

[Brian]

Probably both -- he's thinking more about the userspace side of it, though.

Since you want these settings to vary by user and persist across reboots, 
the default levels will need to be stored in some table/database and /etc 
seems like the appropriate place.  Of course, that's more PAM's domain 
than a kernel issue, but the userspace connection is still important.

Will there be a utility for viewing/changing per-user limits?  If so, what 
should it be called?  Will we just pile more values into ulimit?  We're 
running a little short on intuitive flags.

/proc entries are okay for tweaking kernel parameters, but it seems a 
little weak as a primary interface.  You might as well have ps say 'Go 
grep it yourself!'

	-- Brian

On Wednesday 15 August 2001 01:56 am, J Sloan wrote:
> dmaynor@iceland.oit.gatech.edu wrote:
> > > This is why you mainly find per-process stuff in all the limits.
> > >
> > > Linux has had (for a while now) a "struct user" that is actually
> > > quickly accessible through a direct pointer off every process that
> > > is associated with that user, and we could (and _will_) start adding
> > > these kinds of limits. However, part of the problem is that because
> > > the limits haven't historically existed, there is also no accepted
> > > and nice way of setting the limits.
> >
> > So when you do impose this, where will it be setable, will there be a
> > flat file in /etc like solaris, or compile time for the kernel?
>
> Eh?
>
> Why wouldn't it be like most parameters in Linux,
> e.g. dynamically adjustable via a sysctl or /proc?
>
> IMHO, of course...
>
> cu
>
> jjs
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4.8 Resource leaks + limits

[J Sloan]

Brian wrote:

> Probably both -- he's thinking more about the userspace side of it, though.
>
> /proc entries are okay for tweaking kernel parameters, but it seems a
> little weak as a primary interface.  You might as well have ps say 'Go
> grep it yourself!'

Something along the lines of the nice little program
sysctlconfig-gtk, to set the values with a gui interface,
stores them in e.g. /etc/sysctl.conf, and activtates the
new parameters with a mouse click....

Real men could edit /etc/sysctl.conf themselves,
while newbies could use the GUI program -

cu

jjs

Re: 2.4.8 Resource leaks + limits

[Admin Mailing Lists]

i would think to put global limits in /proc or in a flat text /etc
and per user limits in something like /etc/passwd or /etc/shadow?
Is it against any standard to have extra fields in those files?

-Tony
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco                       Network Administrator/Engineer
thelittleprince@asteroid-b612.org       Intergrafix Internet Services

    "Dream as if you'll live forever, live as if you'll die today"
http://www.asteroid-b612.org                http://www.intergrafix.net
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.

On Tue, 14 Aug 2001, J Sloan wrote:

> dmaynor@iceland.oit.gatech.edu wrote:
> 
> > > This is why you mainly find per-process stuff in all the limits.
> > >
> > > Linux has had (for a while now) a "struct user" that is actually quickly
> > > accessible through a direct pointer off every process that is associated
> > > with that user, and we could (and _will_) start adding these kinds of
> > > limits. However, part of the problem is that because the limits haven't
> > > historically existed, there is also no accepted and nice way of setting
> > > the limits.
> > So when you do impose this, where will it be setable, will there be a flat file in /etc
> > like solaris, or compile time for the kernel?
> 
> Eh?
> 
> Why wouldn't it be like most parameters in Linux,
> e.g. dynamically adjustable via a sysctl or /proc?
> 
> IMHO, of course...
> 
> cu
> 
> jjs
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: 2.4.8 Resource leaks + limits

[dmaynor]

I was thinking along the lines of a /etc/system file where all the memconfig can be set
can be set in one fail swoop..

Re: 2.4.8 Resource leaks + limits

[Alan Cox]

> i would think to put global limits in /proc or in a flat text /etc
> and per user limits in something like /etc/passwd or /etc/shadow?
> Is it against any standard to have extra fields in those files?

Take a look at the pam modules, they already handle limit configuration per
user, and I think all the major Linux (and also stuff like Solaris) distros
run PAM based auth

Re: 2.4.8 Resource leaks + limits

[Rik van Riel]

On Wed, 15 Aug 2001, Alan Cox wrote:

> > i would think to put global limits in /proc or in a flat text /etc
> > and per user limits in something like /etc/passwd or /etc/shadow?
> > Is it against any standard to have extra fields in those files?
>
> Take a look at the pam modules, they already handle limit
> configuration per user, and I think all the major Linux (and
> also stuff like Solaris) distros run PAM based auth

Alan, would you accept the trivial version of per-user
CPU scheduling for 2.4 if there is a lot of demand ?

The code has been running in Conectiva's kernel RPM for
over a year now, is implemented entirely in the recalculate
part of the scheduler, leaves the scheduler fast path all
alone and only needs to be properly ported to newer 2.4
kernels now...

regards,

Rik
--
IA64: a worthy successor to the i860.

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/

Re: 2.4.8 Resource leaks + limits

[Alan Cox]

> Alan, would you accept the trivial version of per-user
> CPU scheduling for 2.4 if there is a lot of demand ?

I'd rather it was a patch outside the main tree

Re: 2.4.8 Resource leaks + limits

[Rik van Riel]

On Fri, 17 Aug 2001, Alan Cox wrote:

> > Alan, would you accept the trivial version of per-user
> > CPU scheduling for 2.4 if there is a lot of demand ?
>
> I'd rather it was a patch outside the main tree

Ok, I'll just keep it the way it was, then ;)

Rik
--
IA64: a worthy successor to i860.

http://www.surriel.com/		http://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: 2.4.8 Resource leaks + limits

[Magnus Naeslund(f)]

"Linus Torvalds" <torvalds@transmeta.com> wrote in message
news:200108150532.f7F5WGq01653@penguin.transmeta.com...
> In article <3ce801c12548$b7971750$020a0a0a@totalmef> you write:
> >
> >Question: why isn't there a limit for global memory usage per user?
>
> Answer: because traditionally Linux (or UNIX) hasn't had a good and
> efficient way to have per-user statistics.
>

Well this problem is not so hard, i'll just set "nproc = maxglobal / data"
or something like that for now.
Too bad if any of my users want to run many diet processes, but that's life.

The more serious part of my little alloc adventure is much more dangerous:

Whattaheck happened to my resources?
I _still_ can't log in to that box as a luser (root works).

[snip]
> Linus
>

Magnus

Re: 2.4.8 Resource leaks + limits

[Alexander Viro]

On Wed, 15 Aug 2001, Magnus Naeslund(f) wrote:

> The more serious part of my little alloc adventure is much more dangerous:
> 
> Whattaheck happened to my resources?
> I _still_ can't log in to that box as a luser (root works).

May be memory fragmentation. You need an order 1 allocation for fork(), just
to allocate task_struct...

Re: 2.4.8 Resource leaks + limits

[Magnus Naeslund(f)]

From: "Alexander Viro" <viro@math.psu.edu>
>
[snap[crackle[pop]]]
>
> May be memory fragmentation. You need an order 1 allocation for fork(),
just
> to allocate task_struct...
>
>

1) Does that mean i'm screwed (then why, i got about 80 MB free here + 1gb
swap, howto defrag?)

2) I can ssh in as root, why does that still work?

:-)

Magnus

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Programmer/Networker [|] Magnus Naeslund
 PGP Key: http://www.genline.nu/mag_pgp.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: 2.4.8 Resource leaks + limits

[Szabolcs Szakacsits]

On Wed, 15 Aug 2001, Alexander Viro wrote:
> > The more serious part of my little alloc adventure is much more dangerous:
> > Whattaheck happened to my resources?
> > I _still_ can't log in to that box as a luser (root works).
> May be memory fragmentation. You need an order 1 allocation for fork(), just
> to allocate task_struct...

No, 2.4.8 seems to like to soft lockup in cases after it used up all
swap. I also run some trivial memory stressing tests on a UP, 128 MB,
256 swap, 7 MB/sec UDMA disk subsytem box and after a couple of
successful recovery [couple = max 1 in my case] the system soft locks.
swap space was 0, no disk activity, CPU apparently spins in kswapd, all
relevant zones, inactive_* had plenty free pages and no memory
fragmentation. After it soft locked none of the VM stat value changed
at all. Rik also called for help in another thread but the problem seems
to be not out_of_memory() tuning (when to jump in) however either
accounting bug or other (kswapd related?) thing - kernel stacks were a
bit strange [using Right_ALT+Scroll_Lock when soft locked], like
page_launder
do_try_to_free_pages
kswapd
kswapd
kswapd

	Szaka

Re: 2.4.8 Resource leaks + limits

[Magnus Naeslund(f)]

From: "Szabolcs Szakacsits" <szaka@f-secure.com>
[snip]
>
> No, 2.4.8 seems to like to soft lockup in cases after it used up all
> swap. I also run some trivial memory stressing tests on a UP, 128 MB,
> 256 swap, 7 MB/sec UDMA disk subsytem box and after a couple of
> successful recovery [couple = max 1 in my case] the system soft locks.
> swap space was 0, no disk activity, CPU apparently spins in kswapd, all
> relevant zones, inactive_* had plenty free pages and no memory
> fragmentation. After it soft locked none of the VM stat value changed
> at all. Rik also called for help in another thread but the problem seems
> to be not out_of_memory() tuning (when to jump in) however either
> accounting bug or other (kswapd related?) thing - kernel stacks were a
> bit strange [using Right_ALT+Scroll_Lock when soft locked], like
> page_launder
> do_try_to_free_pages
> kswapd
> kswapd
> kswapd
>

Well as i said, my system _never_ locks up completly ( but it might look
that way because it's crawlin'-like-a-dog ).
The problem is that i can shh in as root, but not as any other user ( not
via login or su or either ).
Root always works, and mind you, this is _after_ the "attack", and the
system resources is back to normal as far as i can tell.

It leads me to think something is wrong with the nproc rlimit accounting or
something like that, maybe in the oom kill code?

> Szaka
>


Magnus

Re: 2.4.8 Resource leaks + limits

[Szabolcs Szakacsits]

On Wed, 15 Aug 2001, Magnus Naeslund(f) wrote:

> The problem is that i can shh in as root, but not as any other user ( not
> via login or su or either ).

Are you using < 0.73 PAM without the change_uid pam_limit option? You
set in /etc/security/limits.conf:
*               soft    nproc           40

the '*' valid for users but not for root, the relevant parts of
a default login/pam works like:

<running as root>
setrlimit()
fork()
setuid(user_uid)

So if you have at least 40 root processes running already for whatever
reason then the result is what you see.

The livelocks what I mentioned is indeed different and fixed in 2.4.9 (I
guess the 'kswapd thought shortage for highmem zone when its size is
actually 0' issue what Linus said in the 'kswapd using all cpu for long
periods' thread). Sorry for the confusion, hope the above fixes your
problem.

	Szaka

Re: 2.4.8 Resource leaks + limits

[Szabolcs Szakacsits]

On Thu, 16 Aug 2001, Szabolcs Szakacsits wrote:
> On Wed, 15 Aug 2001, Magnus Naeslund(f) wrote:
> > The problem is that i can shh in as root, but not as any other user ( not
> > via login or su or either ).
> Are you using < 0.73 PAM without the change_uid pam_limit option? You

Uhm, this wanted to be "... < 0.73 OR >= 0.73 without the ...."

	Szaka

Re: 2.4.8 Resource leaks + limits

[Magnus Naeslund(f)]

From: "Szabolcs Szakacsits" <szaka@f-secure.com>
>
> On Wed, 15 Aug 2001, Magnus Naeslund(f) wrote:
>
> > The problem is that i can shh in as root, but not as any other user (
not
> > via login or su or either ).
>
> Are you using < 0.73 PAM without the change_uid pam_limit option? You
> set in /etc/security/limits.conf:
> *               soft    nproc           40
>
> the '*' valid for users but not for root, the relevant parts of
> a default login/pam works like:
>
> <running as root>
> setrlimit()
> fork()
> setuid(user_uid)
>
> So if you have at least 40 root processes running already for whatever
> reason then the result is what you see.
>

Well root is unlimited, and i have _no_ processes running as the user i'm
trying to log on as.
This must be a bug then.
I even tried adduser <newuser>, but i couldn't log in as that either.

> The livelocks what I mentioned is indeed different and fixed in 2.4.9 (I
> guess the 'kswapd thought shortage for highmem zone when its size is
> actually 0' issue what Linus said in the 'kswapd using all cpu for long
> periods' thread). Sorry for the confusion, hope the above fixes your
> problem.
>

I never had any lockups.

Magnus

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Programmer/Networker [|] Magnus Naeslund
 PGP Key: http://www.genline.nu/mag_pgp.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: 2.4.8 Resource leaks + limits

[Tobias Ringstrom]

On Wed, 15 Aug 2001, Szabolcs Szakacsits wrote:

> On Wed, 15 Aug 2001, Alexander Viro wrote:
> > > The more serious part of my little alloc adventure is much more dangerous:
> > > Whattaheck happened to my resources?
> > > I _still_ can't log in to that box as a luser (root works).
> > May be memory fragmentation. You need an order 1 allocation for fork(), just
> > to allocate task_struct...
>
> No, 2.4.8 seems to like to soft lockup in cases after it used up all
> swap. I also run some trivial memory stressing tests on a UP, 128 MB,

This may be related to another thread.  See the mail "Re: kswapd using all
cpu for long periods in 2.4.9-pre4" posted by Linus a couple of hours ago.

/Tobias