On Mon, Feb 14, 2005 at 10:03:45AM -0500, Steven Rostedt wrote:
were employed by bitmover, or signed an NDA to look at the code. But
just the act of using it is ridicules. Can you see Ford Motors telling
someone that you can't go work for GM if you drive a Ford?
Your point makes sense to me
On Thu, Feb 17, 2005 at 06:24:53PM -0800, Tupshin Harper wrote:
small to medium sized ones). Last I checked, Arch was still too slow in
some areas, though that might have changed in recent months. Also, many
IMHO someone needs to rewrite ARCH using the RCS or SCCS format for the
backend and a
On Fri, Feb 18, 2005 at 12:53:09PM +0100, Erik Bågfors wrote:
RCS/SCCS format doesn't make much sence for a changeset oriented SCM.
The advantage it will provide is that it'll be compact and a backup will
compress at best too. Small compressed tarballs compress very badly
instead, it wouldn't be
On Tue, Mar 15, 2005 at 12:27:12PM +0100, Ingo Molnar wrote:
this combination of arguments i think tips the balance in favor of
seccomp, but still, i hate the fact that the anti-ptrace sentiment was
used as a vehicle to get this feature into the kernel.
Why should I use excuses to get this
On Tue, Mar 15, 2005 at 03:44:28PM +0100, Ingo Molnar wrote:
let me put it another way: this is a security hole. seccomp is now a way
to evade the auditing of read/write syscalls done to an opened file.
Please fix this.
This is not true, the auditing of read/write will work fine on the
Oe Tue, Mar 15, 2005 at 04:05:26PM +0100, Ingo Molnar wrote:
ugh? Where do i claim any such thing?
You never said such a thing, but you said you believe it's not provable
that sys_read/write and hardware irq processing is secure in linux, so
I wanted to get some statistical significance about
area (the shrink_slab itself seems overkill
complicated for no good reason and different methods returns random
stuff, dcache returns a percentage of the free entries, dquot instead
returns the allocated inuse entries too which makes the whole API
looking unreliable).
Signed-off-by: Andrea Arcangeli
On Wed, Mar 16, 2005 at 01:31:34AM +0100, Andrea Arcangeli wrote:
In short I think we can start by trying this fix (which has some risk,
since now it might become harder to detect an oom condition, but I don't
Some testing shows that oom conditions are still detected fine (I
expected this but I
On Wed, Mar 16, 2005 at 02:41:50PM +0100, Ingo Molnar wrote:
password issue. (But i guess after many years i should be wiser not to
get into such arguments with you.) [..]
Your last emails about math proofs, social engineering and selfish NIH
syndrome were ridiculous, and now you get personal.
On Wed, Mar 16, 2005 at 04:04:35AM -0800, Andrew Morton wrote:
+ if (!reclaim_state-reclaimed_slab
+ zone-pages_scanned = (zone-nr_active +
+ zone-nr_inactive) * 4)
On Thu, Mar 17, 2005 at 11:27:26AM +0100, Ingo Molnar wrote:
maybe because i ended up agreeing with you? ;)
ok ;) I'm very happy that we agree.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Wed, Mar 23, 2005 at 03:42:32PM -0800, Andrew Morton wrote:
I'm suspecting here that we simply leaked a refcount on every darn
pagecache page in the machine. Note how mapped memory has shrunk down to
less than a megabyte and everything which can be swapped out has been
swapped out.
If
On Mon, Mar 07, 2005 at 07:10:05PM +1100, Nick Piggin wrote:
[EMAIL PROTECTED] wrote:
If you do 'echo 0 0 /proc/sys/vm/lowmem_reserve_ratio' the kernel gets a
divide-by-zero.
Prevent that, and fiddle with some whitespace too.
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Can we
On Mon, Mar 07, 2005 at 12:20:48AM -0800, Andrew Morton wrote:
I haven't thought about it yet, but there must be some way to avoid leaving
huge amounts of lowmem free. It should be OK to allow lowmem to be fully
used, as long as there's sufficent reclaimable stuff in there - slab,
blockdev
it, though my compiler fails to compile 2.4, so it's not
immediate to verify it. If any problem showup I'll post a followup.
This is a noop for all systems 800M (1G shouldn't be noticeable
either). This is why most people can't notice.
Thanks.
Signed-off-by: Andrea Arcangeli [EMAIL PROTECTED
Hello Marcelo,
On Fri, Mar 11, 2005 at 01:04:13PM -0300, Marcelo Tosatti wrote:
Out of curiosity, that was SuSE not mainline ?
yep.
Do we really want to limit dirty cache to low mem on HIGHIO capable
machines? I'm afraid doing so might hurt performance on such systems.
I think it might
simpler. I also verified it still compiles and works fine on x86
and x86-64.
Instead of the TIF_32BIT redefine, if you want to change x86-64 to use
TIF_32BIT too (instead of TIF_IA32), let me know.
Thanks.
Signed-off-by: Andrea Arcangeli [EMAIL PROTECTED]
--- 2.6.12/arch/ppc64/Kconfig 2005-03-25
On Mon, Mar 28, 2005 at 09:42:00AM +1000, Benjamin Herrenschmidt wrote:
suggest I just don't do any control ? Or should I implement a double
buffer scheme with software gain as well in the kernel driver ?
I recall to have sometime clicked on volume controls that weren't
hardware related, I
textual disable we can change this of course.
Comments welcome.
From: Andrea Arcangeli [EMAIL PROTECTED]
Subject: oom killer protection
iscsi/lvm2/multipath needs guaranteed protection from the oom-killer.
Signed-off-by: Andrea Arcangeli [EMAIL PROTECTED]
--- 2.6.12-seccomp/fs/proc/base.c.~1
On Sat, Feb 19, 2005 at 04:10:18AM -0500, Patrick McFarland wrote:
In the case of darcs, RCS/SCCS works exactly opposite of how darcs does. By
using it's super magical method, it represents how code is written and how it
changes (patch theory at its best). You can clearly see the direction
On Sat, Feb 19, 2005 at 12:15:02PM -0500, David Roundy wrote:
The linux-2.5 tree right now (I'm re-doing the conversion, and am up to
October of last year, so far) is at 141M, if you don't count the pristine
cache or working directory. That's already compressed, so you don't get
any extra
Hello Miles,
On Mon, Feb 21, 2005 at 02:39:05PM +0900, Miles Bader wrote:
Yeah, the basic way arch organizes its repository seems _far_ more sane
than the crazy way CVS (or BK) does, for a variety of reasons[*]. No
doubt there are certain usage patterns which stress it, but I think it
makes
Hello Adrian,
On Thu, Feb 24, 2005 at 10:51:36PM +0100, Adrian Bunk wrote:
seccomp might be a nice feature under some circumstances.
But the suggestion in the help text is IMHO too strong and therefore
removed by this patch.
Why too strong? The reason there is a config option is for the
On Fri, Feb 25, 2005 at 03:38:06PM -0800, Chris Wright wrote:
I don't have a good sampling of applications. The one's I've used are
temporal like gpg, or they mlockall the whole thing and never look back.
But I did a quick benchmark since I was curious, a simple loop of a
million lock/unlock
On Fri, Feb 25, 2005 at 10:14:54PM +0100, Adrian Bunk wrote:
You don't need this feature unless you know you need it.
But you may not know that you need it since in the help text I
intentionally didn't mention which software requires the option to be
set to Y (I didn't mention it, since I didn't
normal misc
usage with all sort of desktop apps and twisted). Comments welcome thanks!
Patch is against 2.6.11-rc5.
Signed-off-by: Andrea Arcangeli [EMAIL PROTECTED]
--- xx/fs/pipe.c.~1~2005-02-28 00:43:42.0 +0100
+++ xx/fs/pipe.c2005-02-28 04:47:26.0 +0100
@@ -235,6
IMHO the really wrong thing is that we always set POLLIN (even for
output filedescriptors that will never allow any data to be read).
On Mon, Feb 28, 2005 at 08:25:07AM -0800, Linus Torvalds wrote:
However, that has always been true. Look at the old code: it would set
POLLIN for a
On Mon, Feb 28, 2005 at 11:22:18AM -0800, Linus Torvalds wrote:
I wonder. It migth just be a latent bug in python-twisted, rather than any
designed behaviour.
Twisted is doing this for the process writer doRead operation:
def doRead(self):
The only way this pipe can become
On Tue, Mar 01, 2005 at 01:32:47AM +0100, Adrian Bunk wrote:
If you want to use Cpushare, you know that you have to enable seccomp.
Oh yeah, I know it, you know it, but not everyone will know it while
configuring the kernel, infact I doubt they'll even know what Cpushare
is about while they
guess it probably matters only for protocols with multiple bands like
TCP that can send a out of band message and have it arrive to userland
first regardless of the window size already on the wire).
- Forwarded message from Andrea Arcangeli [EMAIL PROTECTED] -
Date: Tue, 1 Mar 2005 01:37
On Mon, Feb 28, 2005 at 05:16:35PM -0800, Linus Torvalds wrote:
I assume you mean 2.6.11-rc5, not 2.6.5-rc11.
Indeed sorry, I've probably typed that 2.6.5 number too many times ;)
As you say, for pipes, none. It only matters on sockets that can have
urgent data (aka oob - out-of-band data).
On Thu, Mar 03, 2005 at 03:51:47PM +0100, Adrian Bunk wrote:
My point is simply:
The help text for an option you need only under very specific
circumstances shouldn't sound as if this option was nearly was
mandatory.
For me, that's a question principle, not of risks of breakage or code
On Thu, Mar 03, 2005 at 03:17:52PM -0800, Andrew Morton wrote:
That's the only way it _can_ work. The maintainer of 2.6.x.y shouldn't be
Andrew, what about my suggestion of shifting left x.y of 8 bits? ;) Do
we risk the magic 2.7 number to get us stuck in unstable mode for 2
years instead of 2
On Thu, Mar 03, 2005 at 05:32:03PM -0500, Jeff Garzik wrote:
On Thu, Mar 03, 2005 at 10:15:46PM +, Alan Cox wrote:
We still need 2.6.x.y updates on a more official footing and with more
than one person as the 2.6.x.y maintainer. I think that is actually
more important.
That appears
On Mon, Jan 24, 2005 at 10:45:47PM -0500, Dave Jones wrote:
On Tue, Jan 25, 2005 at 02:19:24PM +1100, Andrew Tridgell wrote:
The problem I've hit now is a severe memory leak. I have applied the
patch from Linus for the leak in free_pipe_info(), and still I'm
leaking memory at the rate of
On Tue, Jan 25, 2005 at 02:31:03PM +0100, Andreas Gruenbacher wrote:
On Tue, 2005-01-25 at 13:51, Andrea Arcangeli wrote:
If somebody could fix the kernel CVS I could have a look at the
interesting changesets between 2.6.11-rc1-bk8 and 2.6.11-rc2.
What's not okay?
I already prepared
Hello,
sorry to annoy you about this, but something is going wrong with either
cvsps or the kernel CVS.
I reproducibly get this as the last changeset, note the date. The
--bkcvs breaks completely too, but that would be a minor issue since
cvsps by default will get it right from the dates that
On Tue, Jan 25, 2005 at 11:58:07AM -0500, Daniel Jacobowitz wrote:
FYI, I haven't tried using cvsps on the kernel CVS, but I used to use it on
GCC - and it fell down like this on a constant basis.
Interesting, for me it always worked fine on the kernel until last
month.
You might want to take
On Tue, Jan 25, 2005 at 05:10:17PM +, Catalin Marinas wrote:
I noticed this problem some time ago when trying to see whether the
darcs repository is consistent with the BK one:
http://marc.theaimsgroup.com/?l=linux-kernelm=110026570201544w=2
A solution is to use the (Logical change
On Tue, Jan 25, 2005 at 08:11:19PM -0400, Mauricio Lin wrote:
Sometimes the first application to be killed is XFree. AFAIK the
This makes more sense now. You need somebody trapping sigterm in order
to lockup and X sure traps it to recover the text console.
Can you replace this:
if
On Thu, Jan 27, 2005 at 02:54:13PM -0400, Mauricio Lin wrote:
Hi Andrea,
On Wed, 26 Jan 2005 01:49:01 +0100, Andrea Arcangeli [EMAIL PROTECTED]
wrote:
On Tue, Jan 25, 2005 at 08:11:19PM -0400, Mauricio Lin wrote:
Sometimes the first application to be killed is XFree. AFAIK
On Thu, Jan 27, 2005 at 02:29:43PM -0800, Andrew Morton wrote:
I've already queued a patch for this:
--- 25/mm/oom_kill.c~mm-fix-several-oom-killer-bugs-fix Thu Jan 27
13:56:58 2005
+++ 25-akpm/mm/oom_kill.c Thu Jan 27 13:57:19 2005
@@ -198,12 +198,7 @@ static void
On Thu, Jan 27, 2005 at 03:35:35PM -0800, Andrew Morton wrote:
On x86 we could perhaps test for non-nullness of tsk-thread-io_bitmap_ptr?
yes for ioports. But I'm afraid I was too optimistic about eflags for
iopl, that's not in the per-task tss, it's only stored at the very top
of the kernel
On Fri, Jan 28, 2005 at 11:21:11AM -0400, Mauricio Lin wrote:
As you know, Andrew generated the patch. Here goes some test results
about your OOM Killer and the Original OOm Killer. We accomplished 10
experiments for each OOM Killer and below are average values.
Invocations is the number of
Diff between 2.4.7pre2aa1 and 2.4.7pre3aa1:
-
Only in 2.4.7pre2aa1: 00_3c59x-zerocopy-1
Only in 2.4.7pre3aa1: 00_3c59x-zerocopy-2
Right fix for enabling zerocopy on highmem kernels.
(nice to have)
Only in 2.4.7pre3aa1:
With pre3 there are bugs introduced into mainline that are getting
extended to all architectures.
First of all nucking the handle_softirq from entry.S is wrong. ppc
copied without thinking and we'll need to resurrect it too for example
so please arch maintainers don't kill that check (alpha in
On Fri, Jun 29, 2001 at 10:50:15AM +0100, Alan Cox wrote:
the boss say If Linux makes Sybase go through the page cache on
reads, maybe we'll just have to switch to Solaris. That's
a serious performance problem.
Thats something you'd have to benchmark. It depends on a very large number
On Sun, Jul 08, 2001 at 07:26:01PM +0100, Mark Hemment wrote:
On Sun, 8 Jul 2001, Linus Torvalds wrote:
On Sun, 8 Jul 2001 [EMAIL PROTECTED] wrote:
mm/highmem.c/copy_from_high_bh() blocks interrupts while copying down
to a bounce buffer, for writing.
This function is only ever
Diff between 2.4.7pre6aa1 and 2.4.7pre8aa1 (besides moving on top
of 2.4.7pre8).
Only in 2.4.7pre8aa1/: 00_do_swap_page-fix-1
Account major faults for swapins. (from -ac)
Only in 2.4.7pre6aa1: 00_drop_async-io-get_bh-1
Only in 2.4.7pre8aa1/: 00_drop_async-io-get_bh-2
Rediffed
On Thu, Jul 19, 2001 at 06:45:38PM -0400, Jeff Dike wrote:
Only in 2.4.7pre6aa1: 51_uml-ac-to-aa-2.bz2
Only in 2.4.7pre8aa1/: 51_uml-ac-to-aa-3.bz2
Moved part of it in the tux directory so it can compile
without tux (in reality I got errno compilation error
but
On Wed, Jan 19, 2005 at 09:13:23AM -0800, Tony Lindgren wrote:
HZ=100 does not allow improving the idle loop much further
from what we have. We should be able to take advantage of the
longer idle/sleep periods inbetween the skipped ticks.
OTOH servers aren't just doing idle power saving, if
On Wed, Jan 19, 2005 at 10:19:47AM -0800, Tony Lindgren wrote:
If you have a chance, can you please provide me with some more info
on your system, see my recent reply to Pavel in this thread for the
It's a normal UP athlon 1ghz, it should be quite widespread hardware.
I know at least another
On Wed, Jan 19, 2005 at 11:34:20AM -0800, Tony Lindgren wrote:
It could be HPET that kills it. I don't have any boxes with HPET
timer, can you try without HPET?
There's no hpet hardware in that system. Also the problem I'm having is
not with your patch but on some code that should be exercised
On Thu, Jan 20, 2005 at 02:15:56PM +0100, Andries Brouwer wrote:
On Thu, Jan 20, 2005 at 01:34:06PM +0100, Jens Axboe wrote:
Using current BK on my x86-64 workstation, it went completely nuts today
killing tasks left and right with oodles of free memory available.
Yes, the fact that the
On Thu, Jan 20, 2005 at 03:57:07PM -0600, Chris Friesen wrote:
Andries Brouwer wrote:
But let me stress that I also consider the earlier situation
unacceptable. It is really bad to lose a few weeks of computation.
Shouldn't the application be backing up intermediate results to disk
is inherited between parent and child so it's easy to write a
wrapper for complex apps.
I made used_math a char at the light of later patches. Current patch
breaks alpha, but future patches will fix it.
Signed-off-by: Andrea Arcangeli [EMAIL PROTECTED]
--- mainline/fs/proc/base.c 2005-01-15
From: Andrea Arcangeli [EMAIL PROTECTED]
Subject: keep balance between different classzones
This is the forward port to 2.6 of the lowmem_reserved algorithm I
invented in 2.4.1*, merged in 2.4.2x already and needed to fix workloads
like google (especially without swap) on x86 with 1G of ram
From: Andrea Arcangeli [EMAIL PROTECTED]
Subject: fix several oom killer bugs, most important avoid spurious oom kills
badness algorithm tweaked by Thomas Gleixner to deal with fork bombs
This is the core of the oom-killer fixes I developed partly taking the
idea from Thomas's patches of getting
From: Andrea Arcangeli [EMAIL PROTECTED]
Subject: convert memdie to an atomic thread bitflag
On Sat, Dec 25, 2004 at 03:27:21AM +0100, Andrea Arcangeli wrote:
So my current plan is to make used_math a PF_USED_MATH, and memdie a
TIF_MEMDIE. And of course oomtaskadj an int (that one requires more
From: Andrea Arcangeli [EMAIL PROTECTED]
Subject: Convert the unsafe signed (16bit) used_math to a safe and optimal
PF_USED_MATH
On Sat, Dec 25, 2004 at 04:24:30AM +0100, Andrea Arcangeli wrote:
Here it is the first part. This makes memdie a TIF_MEMDIE. It's
And here is the final incremental
instead. This should prevent heavy block device writers from pushing
the VM over the edge and triggering OOM kills.
Signed-off-by: Rik van Riel [EMAIL PROTECTED]
Acked-by: Andrea Arcangeli [EMAIL PROTECTED]
--- x/mm/page-writeback.c.orig 2005-01-04 01:13:30.0 +0100
+++ x/mm/page
On Thu, Jan 20, 2005 at 10:20:56PM -0800, Andrew Morton wrote:
Andrea Arcangeli [EMAIL PROTECTED] wrote:
This is the forward port to 2.6 of the lowmem_reserved algorithm I
invented in 2.4.1*, merged in 2.4.2x already and needed to fix workloads
like google (especially without swap
On Thu, Jan 20, 2005 at 10:26:30PM -0800, Andrew Morton wrote:
Andrea Arcangeli [EMAIL PROTECTED] wrote:
This needed highmem fix from Rik is still missing too, so please apply
along the other 5 (it's orthogonal so you can apply this one in any
order you want).
From: Rik van Riel
On Fri, Jan 21, 2005 at 05:36:14PM +1100, Nick Piggin wrote:
I think it should be turned on by default. I can't recall what
I think it too, since the number of people that can be bitten by this is
certainly higher than the number of people who knows the VM internals
and for what kind of
IIRC), but I've
been upgraded to latest bk so I had to fixup quickly or I would have to
run the racy code on my smp systems to test new kernels.
From: Andrea Arcangeli [EMAIL PROTECTED]
Subject: fixup smp race introduced in 2.6.11-rc1
Signed-off-by: Andrea Arcangeli [EMAIL PROTECTED]
--- x/mm
On Thu, Jan 20, 2005 at 11:00:16PM -0800, Andrew Morton wrote:
Last time we dicsussed this you pointed out that reserving more lowmem from
highmem-capable allocations may actually *help* things. (Tries to remember
why) By reducing inode/dentry eviction rates? I asked Martin Bligh if he
could
On Fri, Jan 21, 2005 at 06:04:25PM +1100, Nick Piggin wrote:
OK this is a fairly lame example... but the current code is more or
less just lucky that ZONE_DMA doesn't usually fill up with pinned mem
on machines that need explicit ZONE_DMA allocations.
Yep. For the DMA zone all slab cache will
On Fri, Jan 21, 2005 at 08:08:21AM +0100, Andi Kleen wrote:
So at least for GFP_DMA it seems to be definitely needed.
Indeed. Plus if you add pci32 zone, it'll be needed for it too on
x86-64, like for the normal zone on x86, since ptes will go in highmem
while pci32 allocations will not. So
On Fri, Jan 21, 2005 at 08:42:08AM +0100, Jens Axboe wrote:
And especially not with 500MB of zone normal free, thanks :)
;) Are you sure you had 500m free even before the _first_ oom killing?
I assumed what you posted was not the first one of the oom killing
messages. If it was the first then
On Fri, Jan 21, 2005 at 09:09:41AM +0100, Jens Axboe wrote:
Jan 20 13:22:15 wiggum kernel: oom-killer: gfp_mask=0xd1
This was a GFP_KERNEL|GFP_DMA allocation triggering this. However it
didn't look so much out of DMA zone, there's 4M of ram free. Could be
the ram was relased by another CPU in
@@
+/*
+ * linux/kernel/seccomp.c
+ *
+ * Copyright 2004-2005 Andrea Arcangeli [EMAIL PROTECTED]
+ *
+ * This defines a simple but solid secure-computing mode.
+ */
+
+#include linux/seccomp.h
+#include linux/sched.h
+#include asm/unistd.h
+#ifdef TIF_IA32
+#include asm/ia32_unistd.h
+#endif
+
+/* #define
On Fri, Jan 21, 2005 at 01:47:01PM +0100, Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
This is the seccomp patch ported to 2.6.11-rc1-bk8, that I need for
Cpushare (until trusted computing will hit the hardware market).
[...]
why do you need any kernel code for
On Fri, Jan 21, 2005 at 08:55:22PM +0100, Ingo Molnar wrote:
* Chris Wright [EMAIL PROTECTED] wrote:
* Rik van Riel ([EMAIL PROTECTED]) wrote:
Yes, but do you care about the performance of syscalls
which the program isn't allowed to call at all ? ;)
Heh, no, but it's for every
On Fri, Jan 21, 2005 at 09:54:16PM +0100, Ingo Molnar wrote:
- the second barrier is the 'jail' of the ptraced task. Especially with
PTRACE_SYSCALL, the things a child ptraced process can do are
extremely limited, everything it tries to do will trap, the task will
suspend and the parent
On Fri, Jan 21, 2005 at 05:27:11PM -0400, Mauricio Lin wrote:
Hi Andrea,
I applied your patch and I am checking your code. It is really a very
interesting work. I have a question about the function
__set_current_state(TASK_INTERRUPTIBLE) you put in out_of_memory
function. Do not you think
On Fri, Jan 21, 2005 at 01:31:46PM -0800, Roland McGrath wrote:
When gdb has a bug, people want to be able to kill it and get on with using
their program, not have their program always be killed too.
What I need is that the program is killed right away synchronously as
soon as the debugger
On Fri, Jan 21, 2005 at 05:45:13PM -0400, Mauricio Lin wrote:
Hi Andrew,
I have another question. You included an oom_adj entry in /proc for
each process. This was the approach you used in order to allow someone
or something to interfere the ranking algorithm from userland, right?
So if i
so it's easy to write a
wrapper for complex apps.
I made used_math a char at the light of later patches. Current patch
breaks alpha, but future patches will fix it.
Signed-off-by: Andrea Arcangeli [EMAIL PROTECTED]
--- x/fs/proc/base.c2005-01-15 20:44:58.0 +0100
+++ xx/fs/proc/base.c
On Sat, Jan 22, 2005 at 11:32:42AM +0100, Pavel Machek wrote:
Well, seccomp is also getting very little testing, when ptrace gets a
lot of testing; I know that seccomp is simple, but I believe testing
coverage still make ptrace better choice.
It's not testing that makes code more secure.
On Sat, Jan 22, 2005 at 08:42:42PM +0100, Pavel Machek wrote:
Well, then you can help auditing ptrace()... It is probably also true
that more people audited ptrace() than seccomp :-).
Why should I spend time auditing ptrace when I have a superior solution
that doesn't require me any auditing at
On Sun, Jan 23, 2005 at 01:07:04AM +0100, Pavel Machek wrote:
Adding code is easy, but in the long term would lead to maintainance
nightmare. Adding seccomp code that does subset of ptrace, just
because ptrace audit is lot of work, seems like a wrong thing to
do. Sorry.
Even if I do the
On Sat, Jan 22, 2005 at 07:43:26PM -0500, Rik van Riel wrote:
On Sun, 23 Jan 2005, Andrea Arcangeli wrote:
I'm doing something that requires the maximum level of
security ever,
You're kidding, right ?
Why should I be kidding? The client code I'm doing, has to be at least as secure
as ssh
On Sat, Jan 22, 2005 at 11:43:06PM -0500, [EMAIL PROTECTED] wrote:
It's a poor idea to confuse secure with can't break out of the sandbox.
The only point I'm making with seccomp, is that if it can't break out of
the sandbox it's secure. I didn't mean that the only way to make it
secure is to put
On Mon, Jul 02, 2012 at 12:14:11AM -0400, Rik van Riel wrote:
On 06/28/2012 08:56 AM, Andrea Arcangeli wrote:
Without this, follow_page wouldn't trigger the NUMA hinting faults.
Signed-off-by: Andrea Arcangeliaarca...@redhat.com
follow_page is called from many different places, not just
On Fri, Jul 13, 2012 at 09:19:06AM -0500, Christoph Lameter wrote:
On Thu, 12 Jul 2012, Johannes Weiner wrote:
On Thu, Jul 12, 2012 at 08:08:28PM +0200, Andrea Arcangeli wrote:
On Sat, Jun 30, 2012 at 01:12:18AM -0400, Konrad Rzeszutek Wilk wrote:
On Thu, Jun 28, 2012 at 02:56:00PM
Hello everyone,
With the collaboration of Petr Holasek we released a first 0.1 version
of the AutoNUMA benchmark.
It's now trivial to run it without the chance of mistakes, and you can
also see how fast the NUMA algorithms in the kernel converge the load
by checking the pdf charts it creates
/huge_memory.c | 43 +--
1 file changed, 21 insertions(+), 22 deletions(-)
Reviewed-by: Andrea Arcangeli aarca...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
+ * the set_pte_at() write.
+ */
s/after/before/
After the above correction it looks nice cleanup, thanks!
Acked-by: Andrea Arcangeli aarca...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
the effects are, but maybe you do (or you could
explain to me why I am wrong :)).
commit a8aed3e0752b4beb2e37cbed6df69faae88268da
Author: Andrea Arcangeli aarca...@redhat.com
Date: Fri Feb 22 15:11:51 2013 -0800
x86/mm/pageattr: Prevent PSE and GLOABL leftovers to confuse
pmd
On Mon, Apr 08, 2013 at 03:53:31PM +0100, Andy Whitcroft wrote:
On Sat, Apr 06, 2013 at 04:58:04PM +0200, Andrea Arcangeli wrote:
You're right, so this location clearly didn't trigger the problem so I
didn't notice the noop here. I only exercised the fix in the other
locations of the file
it to the right variable in the new
location.
Reported-by: Stefan Bader stefan.ba...@canonical.com
Signed-off-by: Andrea Arcangeli aarca...@redhat.com
---
arch/x86/mm/pageattr.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
Hi,
On Thu, Apr 11, 2013 at 02:29:18PM +0200, Ingo Molnar wrote:
* tip-bot for Andrea Arcangeli tip...@zytor.com wrote:
Commit-ID: f76cfa3c2496c462b5bc01bd0c9340c2715b73ca
Gitweb:
http://git.kernel.org/tip/f76cfa3c2496c462b5bc01bd0c9340c2715b73ca
Author: Andrea Arcangeli
If the pmd is not present, _PAGE_PSE will not be set anymore. Fix the
false positive.
Reported-by: Ingo Molnar mi...@kernel.org
Signed-off-by: Andrea Arcangeli aarca...@redhat.com
---
arch/x86/mm/pageattr-test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/mm
Hi Michel,
On Sun, Feb 03, 2013 at 11:17:12PM -0800, Michel Lespinasse wrote:
munlock_vma_pages_range() was always incrementing addresses by PAGE_SIZE
at a time. When munlocking THP pages (or the huge zero page), this resulted
in taking the mm-page_table_lock 512 times in a row.
We can do
Hi everyone,
On Tue, Jan 29, 2013 at 04:26:13AM +0200, Izik Eidus wrote:
On 01/29/2013 02:49 AM, Izik Eidus wrote:
On 01/29/2013 01:54 AM, Andrew Morton wrote:
On Fri, 25 Jan 2013 17:53:10 -0800 (PST)
Hugh Dickins hu...@google.com wrote:
Here's a KSM series
Sanity check: do you have
Hello,
During the Kernel Summit somebody raised the point that it's not clear
how much testing each rc/pre/git kernel gets before the final release.
So I setup a server to track automatically the amount of testing that
each kernel gets. Clearly this will be a very rough approximation and it
On Tue, Aug 30, 2005 at 10:29:01AM +0200, Rogier Wolff wrote:
sending a packet on the first day) The number of these random packets
recieved is a measure of the number of CPU-months that the kernel
runs.
This is more or less what klive currently does, except it's a bit more
sophisticated than
On Tue, Aug 30, 2005 at 10:01:21AM +0200, Sven Ladegast wrote:
[..] combined
with an automatic oops/panic/bug-report this would be _very_ useful I think.
That would be nice addition IMHO. It'll be more complex since it'll
involve netconsole dumping and passing the klive session to the kernel
On Tue, Aug 30, 2005 at 11:40:58AM +0200, Rogier Wolff wrote:
packets also wouldn't. So if it is so unimportant as here, why bother
with the more overhead of the TCP connection?
I agree TCP isn't needed, I also don't see SSL very useful here, I use
it extensively for other projects and it would
On Tue, Aug 30, 2005 at 05:33:38PM +0100, Alan Cox wrote:
Just follow the LSB specification and about the only thing thats totally
out of field is Slackware.
Fair enough, though one line like '(sleep 60; twistd ...) in
/etc/init.d/boot.local would have been a bit simpler for a quick and
dirty
801 - 900 of 3668 matches
Mail list logo
