Heads up: linux-2.4.36 on kernel.org is dated 01/01/07 (ie six months
before linux-2.4.35.) Surely a mistake.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Andrea Righi wrote:
[I/O-intensive] processes can noticeably impact the system responsiveness
for some time and playing with tasks' priority is not always an
acceptable solution.
Why?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
Jacob Meuser wrote:
when I see the linux community start to take credit for works they
did not create and I see the linux community respond to warnings
that people in the community are going overboard and jeopardizing
the linux community, which we do all benefit from, with a more or
less
Normal users cannot use chroot() themselves so they can't use chroot to
get back out
I think Bill is right, that this is to fix a method that non-root
processes can use to escape their chroot. The exploit, which is
documented in chroot(2)*, is to chdir(..) your way out. Who'd have
thought
Philipp Marek wrote:
- User starts a small wrapper,
- that opens /,
- chroot()s into a directory and starts fsvs.
- fsvs gets its libraries loaded
- and chroot()s back to the original system.
Isn't that what pivot_root was meant for?
-
To unsubscribe from this list: send the line unsubscribe
Philipp Marek wrote:
AFAIK pivot_root() changes the / mapping for *all* processes, no?
The manual page is confusing. It even admits to being intentionally
vague. However the goal seems clear:
pivot_root() moves the root file system of the current process to
the directory put_old
Tuomo Valkonen wrote:
Well, I'm using two years old 2.6.7 kernel, because the newer
ones have become utter and total crap. (See the link in the
previous post.) It will likely be my last Linux kernel ever,
that I will use until this system becomes simply too obsolete,
at which point, if not
There are a couple of points I would make about your python test
harness. Your program compares real+system jiffies for both cpus; an
ideal result would be 1.00. The measurement is taken over a relatively
short period of approximately a half-second, and you kill the CPU hogs
before taking
There seems something too-specific to PC-architecture in kernel/dma.c,
which is that DMA4 is reserved for cascade. Perhaps it should be
reserved in architecture-specific initialisation. What do other
architectures do with that?
-
To unsubscribe from this list: send the line unsubscribe
Tetsuo Handa wrote:
If Bob is malicious and creates /dev/sda1 with block-8-2 attribute [...]
Bob can't do that. Only root can.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Theodore Tso wrote:
On Mon, Dec 17, 2007 at 07:52:53PM -0500, Andy Lutomirski wrote:
It runs on a freshly booted machine (no
DSA involved, so we're not automatically hosed), so an attacker knows the
initial pool state.
Not just a freshly booted system. The system has to be a
Theodore Tso wrote:
On Tue, Dec 18, 2007 at 01:43:28PM +1030, David Newall wrote:
On a server, keyboard and mouse are rarely used. As you've described it,
that leaves only the disk, and during the boot process, disk accesses and
timing are somewhat predictable. Whether this is sufficient
Mark Lord wrote:
But.. pity there's no mount flag override for smaller systems,
where bind mounts might be more useful with link(2) actually working.
I don't see it. You always can make hard link on the underlying
filesystem. If you need to make it on the bound mount, that is, if you
can't
Mark Lord wrote:
David Newall wrote:
Mark Lord wrote:
But.. pity there's no mount flag override for smaller systems,
where bind mounts might be more useful with link(2) actually working.
I don't see it. You always can make hard link on the underlying
filesystem. If you need to make
On Montag, 17. Dezember 2007, you wrote:
and another one, this time tainted with the nvidia module:
5194.130985] Unable to handle kernel paging request at 0300
RIP:
Numbers like that don't suggest hardware faults. All those zeros: It's
far too round. Sounds very like software.
Hi Arjan,
I've not been able to find this file, drivers/bluetooth/hci_tty.c, but
anyway, This seems to be what happens: Hci_uart_close() flushes using
hci_uart_flush(). Subsequently, in hci_dev_do_close(), (one step in
hci_unregister_dev()), hci_uart_flush() is called again. The comment in
David Miller wrote:
From: Jan Engelhardt [EMAIL PROTECTED]
Date: Fri, 21 Dec 2007 11:10:38 +0100 (CET)
Can we get back to programming?
With respect to the vast majority of log messages, nobody confounded by
punctuation is truly trying to analyze a problem!
--
To unsubscribe from this
David Miller wrote:
From: David Newall [EMAIL PROTECTED]
Date: Sat, 22 Dec 2007 00:13:07 +1030
David Miller wrote:
From: Jan Engelhardt [EMAIL PROTECTED]
Date: Fri, 21 Dec 2007 11:10:38 +0100 (CET)
Can we get back to programming?
With respect to the vast majority
Pavel Machek wrote:
On Sat 2007-12-22 13:42:47, Richard D wrote:
Cant you, modify bootmem allocator to test with memtest patterns and then
use kexec (as Pavel suggested) to test the one where kernel was sitting
earlier?
I do not think you need to modify anything in kernel. Just use
Pavel Machek wrote:
memtest has following problems:
0) it is kind of hard to run memtest over ssh
It's kind of hard to run anything over SSH if it has to be run before
userspace is up. But the kernel can collect results from a modified
memtest, after it chains back.
Pavel Machek wrote:
On Sun 2007-12-23 07:06:58, David Newall wrote:
It's kind of hard to run anything over SSH if it has to be run before
userspace is up. But the kernel can collect results from a modified
memtest, after it chains back.
memtest can be ran from userspace, that's
Jan Engelhardt wrote:
On Nov 30 2007 11:20, Xavier Bestel wrote:
On Fri, 2007-11-30 at 19:09 +0900, KOSAKI Motohiro wrote:
Has Objective-C ever been considered for kernel development?
Why not C# instead ?
Why not Haskell nor Erlang instead ? :-D
I heard of
Chris Snook wrote:
Ben Crowhurst wrote:
Has Objective-C ever been considered for kernel development?
No. Kernel programming requires what is essentially assembly language
with a lot of syntactic sugar, which C provides.
I somewhat disagree. Kernel programming requires and deserves the
Kyle Moffett wrote:
On Dec 06, 2007, at 00:30:16, Renzo Davoli wrote:
AF_IPN is different. AF_IPN is the broadcast and peer-to-peer
extension of AF_UNIX. It supports communication among *user* processes.
Ok, you say it's different, but then you describe how IP unicast and
broadcast work.
Andi Kleen wrote:
Renzo also described something new (in the socket() arena): the
multi-reader, multi-writer is just not available in IP.
How is that different from a multicast group?
Good question. I don't know much about multicast IP. It's a bit new
for me. I knew it uses
(``-_-´´) -- Fernando wrote:
I used to see stuff like this happening on my University students test servers.
Once they started doing forks inside for(;;), the server would go down.
Then they replaced the servers by vwmare machines, and now reboots are faster.
UNIX (and Linux) already has a
Michael H. Warfield wrote:
On Sat, 2007-11-24 at 23:36 +0300, Andrey Borzenkov wrote:
I have no COM port on notebook (without port replicator which I do not have)
so COM is disabled in BIOS. No ttyS* is detected during boot (and no device
created) but I just noticed that serial modules are
Josh Goldsmith wrote:
The problem comes when I try to untar a large file (in this case
linux-2.6.23.tar.bz2). Regardless if I kill off every other process,
eventually the oom-killer will appear and kill either the tar or the
shell.
What's the actual command you are executing?
-
To
Josh Goldsmith wrote:
David: The exact command this time was a tar jxf
linux-2.6.23.tar.bz2 as part of an emerge (gentoo). Gnu tar version
1.18 but has happened with prior versions too. I replicated it after
my post by manually untarring it on the command line and can almost
always
Thanos Chatziathanassiou wrote:
help
I KNOW OF PLACES, ACTIONS, AND THINGS. MOST OF MY VOCABULARY
DESCRIBES PLACES AND IS USED TO MOVE YOU THERE. TO MOVE TRY
WORDS LIKE FOREST, BUILDING, DOWNSTREAM, ENTER, EAST, WEST
NORTH, SOUTH, UP, OR DOWN. I KNOW ABOUT A FEW SPECIAL OBJECTS,
LIKE A BLACK
Where did the 8us delay come from? The documentation and source is
careful not to say how long the delay is. Would changing it to, say
1us, be technically wrong? Is code that requires 8us correct?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
H. Peter Anvin wrote:
David Newall wrote:
Where did the 8us delay come from? The documentation and source is
careful not to say how long the delay is. Would changing it to, say
1us, be technically wrong? Is code that requires 8us correct?
I think a single ISA bus transaction is 1 µs, so
Rene Herman wrote:
On 11-12-07 08:40, Paul Rolland wrote:
Well, if the delay is so much unspecified, what about _reading_ port
0x80 ?
Will the delay be shorter ?
The delay is completely and fully specified in terms of the ISA/LPC clock
That would be the delay on the i386 (sic)
Rene Herman wrote:
This particular discussion isn't about anything in general but solely
about the delay an outb_p gives you on x86 since what is under
discussion is not using an output to port 0x80 on that platform to
generate it.
That could be true if outb_p were used only in architecture
linux-os (Dick Johnson) wrote:
But there are some things that get set up long before
udelay() is calibrated! The interrupt controllers,
the timer, etc. You can't just substitute or you
will end up with machines that won't boot!
The initial value could be set conservatively high.
--
To
Alan Cox wrote:
without need. Not surprising since it has such a vague specific
meaning. One could say, Linux on i386 is liberally sprinkled with
vague specific ? sorry don't follow you.
The _p variants are a universal fixture, defined as ending with a pause,
but without
Siva Prasad wrote:
I am looking at how exactly does the printf in user programs succeeds in
displaying characters to the serial console.
Is it a student assignment? This is so not the right mailing list.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
Tetsuo Handa wrote:
/dev needs to be writable, but this means that files on /dev might be
tampered with.
I infer that you mean /dev needs to be writable by anyone, not by just
its owner or owner and group (conventionally root/root.) This goes
against conventional wisdom, which is that
Tetsuo Handa wrote:
David Newall wrote:
Tetsuo Handa wrote:
/dev needs to be writable, but this means that files on /dev might be
tampered with.
I infer that you mean /dev needs to be writable by anyone, not by just
its owner or owner and group (conventionally root/root
Tetsuo Handa wrote:
I meant that /dev must be mounted for read-write mode
Again, why?
You won't be able to login to the system because /sbin/mingetty
fails to chown/chmod /dev/tty* if /dev is mounted for read-only mode.
Good point. So, if only root can modify files in /dev,
dean gaudet wrote:
On Wed, 19 Dec 2007, David Newall wrote:
Mark Lord wrote:
But.. pity there's no mount flag override for smaller systems,
where bind mounts might be more useful with link(2) actually working.
I don't see it. You always can make hard link on the underlying
dean gaudet wrote:
Pffuff. That's what volume managers are for! You do have (at least) two
independent spindles in your RAID1 array, which give you less need to worry
about head-stack contention.
this system is write intensive and writes go to all spindles, so you're
assertion is wrong.
On Tue, 1 Jan 2008 15:36:32 +0100 Andi Kleen [EMAIL PROTECTED] wrote:
ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/remove-aout-interpreter
Also removal of the old unused iBCS hooks while I was on it
ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/remove-ibcs-support
Is iBCS
Richard Purdie wrote:
I've got a problem I keep running into. My computers have buggy software
which can sometimes run out of control.
Ulimit them.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Jan Engelhardt wrote:
On Nov 1 2007 12:51, Peter Dolding wrote:
This is above me doing code. No matter how many fixes I do to the
core that will not fix dysfunction in the LSM section. Strict
policies on fixing the main security model will be required.
If there is no one wanting to
Jaroslav Sykora wrote:
Let's say we have an archive file hello.zip with a hello world program source
code. We want to do this:
cat hello.zip^/hello.c
gcc hello.zip^/hello.c -o hello
etc..
Wouldn't you do this as a user space filesystem?
-
To unsubscribe from this
David Newall wrote:
Jaroslav Sykora wrote:
Let's say we have an archive file hello.zip with a hello world
program source
code. We want to do this:
cat hello.zip^/hello.c
gcc hello.zip^/hello.c -o hello
etc..
Wouldn't you do this as a user space filesystem?
Which is what you
David Newall wrote:
David Newall wrote:
Jaroslav Sykora wrote:
Let's say we have an archive file hello.zip with a hello world
program source
code. We want to do this:
cat hello.zip^/hello.c
gcc hello.zip^/hello.c -o hello
etc..
Wouldn't you do this as a user space filesystem
Jaroslav Sykora wrote:
If anybody can think of any other solution of the redirector problem, possibly
even non-kernel based one, let me know and I'd be glad :-)
If I understand your problem, you wish to treat an archive file as if it
was a directory. Thus, in the ideal situation, you could
Al Viro wrote:
On Fri, Oct 19, 2007 at 06:07:45AM +0930, David Newall wrote:
considerations of this whole scheme. Linux, like most Unix systems,
has never allowed hard links to directories for a number of reasons;
The claim is wrong. UNIX systems have traditionally allowed
Greg KH wrote:
A driver is not an application as you tried to reference in your
prior quotes.
I think your treating what the learned Professors said to literally.
It is a tiny portion of the whole kernel,
The Copyright Act draws no such a distinction.
and as such,
does fall under the
Consider a USB-attached serial port that is set to do RTS/CTS (or
DSR/DTR) handshaking: What stops the kernel sending more data to it when
the remote end lowers CTS (or DTR)?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
Greg KH wrote:
On Thu, Feb 14, 2008 at 01:15:37AM +1030, David Newall wrote:
Consider a USB-attached serial port that is set to do RTS/CTS (or
DSR/DTR) handshaking: What stops the kernel sending more data to it when
the remote end lowers CTS (or DTR)?
The tty layer should look
Alan Cox wrote:
To make it clear: Even aside from the buffer in 2.6's pl2303.c, there's
a race: An in-flight write URB can fill all hardware buffers, making
unsafe what previously appeared to be a safe write. I think it's
essential to delay submission of the URB on a stop-transmit condition.
Arjan van de Ven wrote:
Bill Davidsen wrote:
Note that because the hardware is old, it's highly likely that most
of it will be retired before that sk98lin driver needs a change. I
can't see anyone using sk98lin on a new system, so it would be less
contentious to let the hardware (or users)
Alan Cox wrote:
byte of a packet is being thrown away about .1% of the time for the pl2303,
but I'm not sure if the FTDI driver still suffers from a similar rash. I
A 20 byte low speed message is too small for flow control to account for
it.
I agree. I've observed the first byte of
Greg KH wrote:
On Thu, Feb 14, 2008 at 07:55:44PM +1030, David Newall wrote:
The current 2.6 driver maintains it's own buffer. I think that's a bad
thing: usbserial already buffers writes, and the extra buffer copy seems
unnecessary, however it does solve the putchar problem. Buffered
Bill Davidsen wrote:
there is no question that pivot_root is intended to have breadth for
more than one process.
I think it's clear from the man page that the original idea was to be
able to pivot_root for individual processes. The reason it doesn't do
that, the reason it affects all
Paul Rolland (???) wrote:
Hell, IRQ 23 is shared between libata and my modem !!!
Tried using the modem?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Dave Jones wrote:
On Mon, Sep 24, 2007 at 05:56:39PM +0100, Antoine Martin wrote:
# rm -fr tmp/chroot.broken
rm: cannot remove directory (...)
Same result when trying to do anything to those files chown/chmod/touch:
Operation not permitted
Various files in the directories it complains
Serge E. Hallyn wrote:
No reason for any new parameters to pivot_root. Just clone your mounts
namespace first.
unshare(CLONE_NEWNS);
chdir(new_dir);
pivot_root(new_dir, oldroot);
Since pivot_root actually fiddles with the vfsmnts, this is really the
only way to go
Serge E. Hallyn wrote:
Quoting David Newall ([EMAIL PROTECTED]):
It might be tidy if pivot_root could be used (instead of a hack based on a
chroot bug), but it'd still be unportable.
It can.
Please re-read my previous msg.
I read it. Currently pivot_root can't be used to affect
Serge E. Hallyn wrote:
Quoting David Newall ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
Quoting David Newall ([EMAIL PROTECTED]):
It might be tidy if pivot_root could be used (instead of a hack based on
a chroot bug), but it'd still be unportable.
It can
Miloslav Semler pointed out that a root process can chdir(..) out of
its chroot. Although this is documented in the man page, it conflicts
with the essential function, which is to change the root directory of
the process. In addition to any creative uses, for example Philipp
Marek's loading
Alan Cox wrote:
Marek's loading dynamic libraries, it seems clear that the prime purpose
of chroot is to aid security. Being able to cd your way out is handy
Does it - I can't find any evidence for that.
It seems self-evident to me. What do you think is it prime purpose?
A root
Jan Engelhardt wrote:
On Sep 26 2007 00:40, David Newall wrote:
Miloslav Semler pointed out that a root process can chdir(..) out of its
chroot.
So what? Just do this: chdir into the root after chroot.
I don't think so. His exploit just got me all the way out of a chroot
within
Jan Engelhardt wrote:
On Sep 26 2007 01:11, David Newall wrote:
Jan Engelhardt wrote:
On Sep 26 2007 00:40, David Newall wrote:
Miloslav Semler pointed out that a root process can chdir(..) out of its
chroot.
So what? Just do this: chdir into the root after chroot
Alan Cox wrote:
On Wed, 26 Sep 2007 01:05:07 +0930
David Newall [EMAIL PROTECTED] wrote:
Alan Cox wrote:
Marek's loading dynamic libraries, it seems clear that the prime purpose
of chroot is to aid security. Being able to cd your way out is handy
Does it - I can't find
Alan Cox wrote:
Good call. Though I suppose, since it's used 24x7 to aid security on
countless production servers, that security dwarfs testing. Still,
debugging, yes that's valid.
I don't suppose it makes and difference; whatever the purpose, a chroot
that doesn't change the root is
Kyle Moffett wrote:
David, please do tell myself and Adrian how locking down chroot()
the way you want will avoid letting root break out through any of the
above ways?
As has been said, there are thousands of ways to break out of a chroot.
It's just that one of them should not be that
Al Viro wrote:
Oh, for fsck sake... Folks, it's standard-required behaviour. Ability
to chroot() implies the ability to break out of it. Could we please
add that (along with reference to SuS) to l-k FAQ and be done with that
nonsense?
I'm pretty confident that it's only standard behavior
Alan Cox wrote:
The dot-dot entry in the root directory is interpreted to mean the
root directory itself. Thus, dot-dot cannot be used to access files
outside the subtree rooted at the root directory.
Which is behaviour chroot preserves properly.
And yet it is the dot-dot entry
Olivier Galibert wrote:
chroot does not allow you to walk out if you're in.
You're mistaken. Or more properly, further use of chroot lets you walk
out. This really has been said before, and before, and before.
chroot(subtree); // enter chroot
chdir(/);// now at subtree
Alan Cox wrote:
On Wed, 26 Sep 2007 20:04:14 +0930
David Newall [EMAIL PROTECTED] wrote:
Al Viro wrote:
Oh, for fsck sake... Folks, it's standard-required behaviour. Ability
to chroot() implies the ability to break out of it. Could we please
add that (along with reference to SuS
Alan Cox wrote:
Now see I've been working on Unix systems since 1988 or so and in that
time I've learned to read the documentation properly (you haven't)
My, my, you can be unpleasant when you try. There's no need for it. As
it happens I have years of UNIX experience on you. (Newbie!)
Alan,
Alan Cox wrote:
therefore it must be right. You present no reasoning to explain why the
behavior is correct; instead you use insults. I've exhausted my
tolerance for rudeness.
Well if citing standards documents at people is rudeness so be it.
Did you just tell a porky? Did
Alan Cox wrote:
You quoted the standard, I merely pointed out you forgot to read it
properly. Thats your problem not mine.
How bizarre. Last email you claimed to quote the standards (but you
never did.) Your becoming an embarrassment. You were rude, and
multiple times. Please just
Alan Cox wrote:
** Plonk **
Welcome to my killfile.
Well that's a relief.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Christer Weinigel wrote:
*spends five minutes with Google*
From the OpenBSD FAQ (an operating system most know for being really,
really focused on security):
http://www.openbsd.org/faq/faq10.html
Any application which has to assume root privileges to operate is
pointless to
Adrian Bunk wrote:
You are claiming They went so far as to say that dot-dot wouldn't let
you out?
I phrased it in a somewhat conversational way. The promise, which I've
now quoted from multiple sources, is expressed variously, including:
The dot-dot entry in the root directory is
Adrian Bunk wrote:
You claimed:
-- snip --
Look, when chroot was being designed, I think they intended that even root
should be unable to get out. They went so far as to say that dot-dot
wouldn't let you out; and it doesn't.
-- snip --
You were clearly saying that whom you call they
Bill Davidsen wrote:
It seems there are (at least) two parts to this, one regarding
changing working directory which is clearly stated in the standards
and must work as it does, and the various issues regarding getting out
of the chroot after the cwd has entered that changed root. That second
/.
I hope I haven't crossed the line between determined and annoying. I
thought we were done, but now I find meat still on this bone.
Posit a normal process having some filesystem root, and a current
working directory (pwd) lying within that root subtree. When chroot is
performed, pwd is
Giuliano Gagliardi wrote:
I have a server that has to switch to different user ids, but because it does
other complex things, I would rather not have it run as root. I only need the
server to be able to switch to certain pre-defined user ids.
Why don't you use group security instead of user
linux-os (Dick Johnson) wrote:
Just don't expect the kernel developers to authorize
its use, or show you how to do it!
Well of course you can be totally up-front and public about it. That,
after all, is the point of GPL.
-
To unsubscribe from this list: send the line unsubscribe
Jan Engelhardt wrote:
On Sep 4 2007 13:53, Guilherme Vilela wrote:
I'm tryng to mount a nfs file system with the option async and run a
program that writes to the file system. The problem is that the
program keep writing even when the file system is full.
man 5 exports
async This
Robert P. J. Day wrote:
while killing some time between compiles and ridding the
kernel-parameters.txt file of out-of-date or incorrect cruft, it
occurs to me that that file is borderline valueless since it
apparently tries to document every possible boot-time parameter,
including those
Robert P. J. Day wrote:
if the goal is to simply put all of the basic boot-time kernel parms
along with the module-specific ones into a single file, sorted in
alphabetical order, then i contend that this is, in fact, silly.
Or even, messy. There's no doubt that it should be maintained with
help
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Is it actually necessary to change the license? With the dual-license,
you can keep a single code-base for both BSD and Linux platforms, which
seems terribly important to me. It'd be awful to lose that. It would
be a maintenance nightmare for BSD. Is it even possible--in real life,
I
Eric W. Biederman wrote:
This isn't Oh some apps are using it let's get them to stop, because
it is inconvenient. This is No apps seems to be using this, we
keep goofing up the maintenance and no one notices, and so it is
likely a source of security problems and other nasties
This first
Gustavo Chain wrote:
I think it's necessary to reserve some pids to the super user.
5 must be sufficient.
Why? (Sorry if I missed something.)
Shouldn't you test for error return before the pid is allocated?
Otherwise, I think, you have to free it. Thus:
long do_fork(unsigned long
Gustavo Chain wrote:
El Wed, 10 Oct 2007 11:19:27 +0930
David Newall [EMAIL PROTECTED] escribió:
Gustavo Chain wrote:
I think it's necessary to reserve some pids to the super user.
5 must be sufficient.
Why? (Sorry if I missed something.)
¿ To prevent a posible DoS
Gustavo Chain wrote:
El Wed, 10 Oct 2007 15:14:06 +0930
David Newall [EMAIL PROTECTED] escribió:
Gustavo Chain wrote:
El Wed, 10 Oct 2007 11:19:27 +0930
David Newall [EMAIL PROTECTED] escribió:
Gustavo Chain wrote:
I think it's necessary to reserve some pids
[EMAIL PROTECTED] wrote:
What David meant was that root will always have a slot doesn't *actually*
help unless you *also* have a way to actually *spawn* such a process. In order
to do the ps, kill, and so on that you need to recover, you need to already
have either a root shell available, or a
Russ Dill wrote:
I've been having a back and forth going for a while with my TA and OS
professor on the meaning of profile=3 and have been unable to convince
either of them. The basic question is if profile=3 is passed to kernel
with an 8MB text section, how big is the allocated profile buffer.
Matthew Wilcox wrote:
You really need to get the fuck over yourself.
That is so rude. You need to learn some manners.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Nick Piggin wrote:
On Monday 15 October 2007 19:52, Rob Landley wrote:
On Monday 15 October 2007 8:37:44 am Nick Piggin wrote:
You really shouldn't configure
so much [swap] unless you do want the kernel to actually use it all, right?
Two words: Software suspend. I've actually
Greg KH wrote:
It comes down to the simple fact, if you wish to use Linux, abide by the
license it comes under. To do otherwise is both disenginous and
illegal[1].
By the way, I'm almost certain that the COPYING file is the first, last
and only document specifying licence conditions, and
Greg KH wrote:
It comes down to the simple fact, if you wish to use Linux, abide by the
license it comes under. To do otherwise is both disenginous and
illegal[1].
I think you're being dishonest. This isn't really about Linux and it
being licensed under GPL, is it? Not if you're being 100%
1 - 100 of 397 matches
Mail list logo
