On Wed, Aug 31, 2005 at 08:20:51PM +0200, Pavel Machek wrote:
> Well, you could remove everything that is not valid kernel text from
> backtrace.
What if the corruption wrote the ssh key inside a the kernel text?
As suggested before, I suspect the only way would be to make it
optional.
> Oh and
On Wed, Aug 31, 2005 at 08:32:00PM +0200, Pavel Machek wrote:
> I'd say "ignore suspend". Machines using it are probably not connected
> to network, anyway, and it stresses system quite a lot.
Currently even if you're not connected to the network it's fine. As long
as you connect sometime. If a pa
op
174 counts
kill
exit_code 0 signal 0
The seccomp_test.py completed successfully, thank you for testing.
Thanks.
Signed-off-by: Andrea Arcangeli <[EMAIL PROTECTED]>
diff -r 1df7bfbb783f arch/i386/kernel/ptrace.c
--- a/arch/i386/kernel/ptrace.c Fri Sep 2 09:01:35 2005
+++ b/arch/i386/kernel/
On Wed, Aug 31, 2005 at 09:47:01PM +0200, Andrea Arcangeli wrote:
> I'm thinking to add optional aggregations for (\d+)\.(\d+)\.(\d+)\D and
> for different archs. So you can watch ia64 only or 2.6.13 only etc...
>
> The "-tiger-smp/-generic-up" makes life harder indeed
On Tue, Sep 06, 2005 at 12:05:07AM +0200, Marc Giger wrote:
> Hi Andrea
>
> Two little details:
>
> The following line does not print what you expect on
> alpha's:
>
> MHZ = int(re.search(r' (\d+)\.?\d?',
> os.popen("grep -i mhz /proc/cpuinfo | head -n
> 1").read()).group(1))
On Thu, Jan 17, 2008 at 08:32:52PM +0100, Andrea Arcangeli wrote:
> To make this work we still need notification from the VM about memory
> pressure [..]
Ok I thought some more at the aging issue of the hot kvm pages (to
prevent the guest-OS very-hot working set to be swapped out). So
On Tue, Jan 22, 2008 at 04:12:34PM +0200, Avi Kivity wrote:
> Andrea Arcangeli wrote:
>> diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
>> --- a/include/asm-generic/pgtable.h
>> +++ b/include/asm-generic/pgtable
&w=2
Signed-off-by: Andrea Arcangeli <[EMAIL PROTECTED]>
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -46,6 +46,7 @@
__young = ptep_test_and_clear_young(__vma, __a
On Tue, Jan 22, 2008 at 08:28:47PM +0100, Peter Zijlstra wrote:
> I think we can get rid of this rwlock as I think this will seriously
> hurt larger machines.
Yep, I initially considered it, nevertheless given you solved part of
the complication I can add it now ;). The only technical reason for
n
Hi Christoph,
Just a few early comments.
First it makes me optimistic this can be merged sooner than later to
see a second brand new implementation of this ;).
On Tue, Jan 22, 2008 at 12:34:46PM -0800, Christoph Lameter wrote:
> On Tue, 22 Jan 2008, Andrea Arcangeli wrote:
>
> &g
Hi Christoph,
On Tue, Jan 22, 2008 at 02:53:12PM -0800, Christoph Lameter wrote:
> On Tue, 22 Jan 2008, Andrea Arcangeli wrote:
>
> > First it makes me optimistic this can be merged sooner than later to
> > see a second brand new implementation of this ;).
>
> Brand new
On Wed, Jan 23, 2008 at 04:52:47AM -0600, Robin Holt wrote:
> But 100 callouts holding spinlocks will not work for our implementation
> and even if the callouts are made with spinlocks released, we would very
> strongly prefer a single callout which messages the range to the other
> side.
But you
Hi Kraxel,
On Wed, Jan 23, 2008 at 01:51:23PM +0100, Gerd Hoffmann wrote:
> That would render the notifies useless for Xen too. Xen needs to
> intercept the actual pte clear and instead of just zapping it use the
> hypercall to do the unmap and release the grant.
I think it has yet to be demonst
On Wed, Jan 23, 2008 at 06:32:30AM -0600, Robin Holt wrote:
> Christoph, Maybe you can clear one thing up. Was this proposal an
> addition to or replacement of Andrea's? I assumed an addition. I am
> going to try to restrict my responses to ones appropriate for that
> assumption.
It wasn't imme
On Thu, Jan 24, 2008 at 07:56:43AM +0200, Avi Kivity wrote:
> What I need is a list of (mm, va) that map the page. kvm doesn't have
> access to that, export notifiers do. It seems reasonable that export
> notifier do that rmap walk since they are part of core mm, not kvm.
Yes. Like said in ear
On Wed, Jan 23, 2008 at 12:18:45PM -0800, Christoph Lameter wrote:
> On Wed, 23 Jan 2008, Andrea Arcangeli wrote:
>
> > > [..] The linux instance with the
> > > secondary mmu must call back to the exporting machine in order to
> > > reinstantiate the
On Thu, Jan 24, 2008 at 03:34:54PM +0100, Andrea Arcangeli wrote:
> set_page_dirty can be called inside ->invalidate_page if needed. But
> I'm not against artificially setting the dirty bit of the pteval
> returned by set_page_dirty, perhaps that's mor
On Wed, Jan 23, 2008 at 12:27:47PM -0800, Christoph Lameter wrote:
> There are still dirty bit issues.
Yes, but no big issues given ->invalidate_page is fully capable of
running set_page_dirty if needed.
> > The window that you must close with that bitflag is the request coming
> > from the remot
On Tue, Jan 22, 2008 at 04:21:56PM -0800, Randy Dunlap wrote:
> On Tue, 22 Jan 2008 15:41:58 +0100 Helmut Grohne wrote:
>
> > Hi,
> >
> > I didn't find out whom to report this bug to and thus report to
> > linux-kernel@vger.kernel.org as described in
> > http://kernel.org/pub/linux/docs/lkml/repo
to offload that work to a kernel thread, but
I don't think a reschedule for this is worth it, the vm should be able
to collect those entries for the synchronous release_task.
Signed-off-by: Andrea Arcangeli <[EMAIL PROTECTED]>
diff --git a/fs/proc/base.c b/fs/proc/base.c
--- a/fs/proc
r ways, still a kernel crashing bug
there is. Or is there some magic that prevents call_rcu + schedule to
invoke the rcu callback?
So you may need to apply this one too (this one is needed to fix the
second bug, my previous patch is needed after applying this one):
Signed-off-by: Andrea Arcangel
On Wed, Nov 28, 2007 at 02:21:29AM +0100, Andrea Arcangeli wrote:
> On Tue, Nov 27, 2007 at 02:38:52PM -0800, Andrew Morton wrote:
> > I don't see why the schedule() will not return? Because the task has
> > PF_EXITING set? Doesn't TASK_DEAD do that?
>
> Ouc
, incidentally like in KVM case. containerof is
an efficient and standard way to do things. OTOH I kept passing down
the 'mm' like below just in case others don't have 'mm' saved in the
container for other reasons like we have in struct kvm, and they
prefer to get it through reg
On Mon, Jan 14, 2008 at 12:02:42PM -0800, Christoph Lameter wrote:
> Hmmm... In most of the callsites we hold a writelock on mmap_sem right?
Not in all, like Marcelo pointed out in kvm-devel, so the lowlevel
locking can't relay on the VM locks.
About your request to schedule in the mmu notifier m
On Wed, Jan 16, 2008 at 07:18:53AM +1100, Benjamin Herrenschmidt wrote:
> Do you have cases where it's -not- called with the PTE lock held ?
For invalidate_page no because currently it's only called next to the
ptep_get_and_clear that modifies the pte and requires the pte
lock. invalidate_range/re
On Wed, Jan 16, 2008 at 10:01:32AM +0100, Brice Goglin wrote:
> One of the difference with my patch is that you attach the notifier list to
> the mm_struct while my code attached it to vmas. But I now don't think it
> was such a good idea since it probably didn't reduce the number of notifier
>
On Wed, Jan 16, 2008 at 07:48:06PM +0200, Izik Eidus wrote:
> Rik van Riel wrote:
>> On Sun, 13 Jan 2008 17:24:18 +0100
>> Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
>>
>>
>>> In my basic initial patch I only track the tlb flushes which should be
>
On Thu, Jan 17, 2008 at 08:21:16PM +0200, Izik Eidus wrote:
> ohh i like it, this is cleaver solution, and i guess the cost of the
> vmexits wont be too high if it will
> be not too much aggressive
Yes, and especially during swapping, the system isn't usually CPU
bound. The idea is to pay wit
On Thu, Jan 24, 2008 at 09:56:06PM -0800, Christoph Lameter wrote:
> Andrea's mmu_notifier #4 -> RFC V1
>
> - Merge subsystem rmap based with Linux rmap based approach
> - Move Linux rmap based notifiers out of macro
> - Try to account for what locks are held while the notifiers are
> called.
>
On Mon, Jan 28, 2008 at 06:10:39PM +0200, Izik Eidus wrote:
> i dont understand how is that better than notification on tlb flush?
I certainly agree. The quoted call wasn't actually the one that could
be moved in a single place in the .h file though. But the 4/4 patch
could be reduced to a few lin
On Mon, Jan 28, 2008 at 11:04:43AM -0800, Christoph Lameter wrote:
> On Mon, 28 Jan 2008, Andrea Arcangeli wrote:
>
> > So I'd like to know what can we do to help to merge the 4 patches from
> > Christoph in mainline, I'd appreciate comments on them so we can help
&g
On Mon, Jan 28, 2008 at 12:28:41PM -0800, Christoph Lameter wrote:
> +struct mmu_notifier_head {
> + struct hlist_head head;
> +};
> +
> struct mm_struct {
> struct vm_area_struct * mmap; /* list of VMAs */
> struct rb_root mm_rb;
> @@ -219,6 +223,8 @@ struct mm_struct {
On Mon, Jan 28, 2008 at 12:28:42PM -0800, Christoph Lameter wrote:
> Index: linux-2.6/mm/fremap.c
> ===
> --- linux-2.6.orig/mm/fremap.c2008-01-25 19:31:05.0 -0800
> +++ linux-2.6/mm/fremap.c 2008-01-25 19:32:49.000
On Tue, Jan 29, 2008 at 02:59:14PM +0100, Andrea Arcangeli wrote:
> The down_write is garbage. The caller should put it around
> mmu_notifier_register if something. The same way the caller should
> call synchronize_rcu after mmu_notifier_register if it needs
> synchronous behav
l) so I fail to see how this will not be cleaned
up eventually, the same way the tlb flushes have been cleaned up
already. Nevertheless I back your implementation and I'm not even
trying at changing it with the risk to slowdown merging.
Signed-off-by: Andrea Arcangeli <[EMAIL PROTECTED]&
On Mon, Jan 28, 2008 at 12:28:44PM -0800, Christoph Lameter wrote:
> if (!migration && ((vma->vm_flags & VM_LOCKED) ||
> - (ptep_clear_flush_young(vma, address, pte {
> + (ptep_clear_flush_young(vma, address, pte) ||
> +
On Tue, Jan 29, 2008 at 11:55:10AM -0800, Christoph Lameter wrote:
> I am not sure. AFAICT you wrote that code.
Actually I didn't need to change a single line in do_wp_page because
ptep_clear_flush was already doing everything transparently for
me. This was the memory.c part of my last patch I pos
On Tue, Jan 29, 2008 at 01:35:58PM -0800, Christoph Lameter wrote:
> On Tue, 29 Jan 2008, Andrea Arcangeli wrote:
>
> > > It seems to be okay to invalidate range if you hold mmap_sem writably. In
> > > that case no additional faults can happen that would create new ptes
On Tue, Jan 29, 2008 at 12:30:06PM -0800, Christoph Lameter wrote:
> On Tue, 29 Jan 2008, Andrea Arcangeli wrote:
>
> > diff --git a/mm/fremap.c b/mm/fremap.c
> > --- a/mm/fremap.c
> > +++ b/mm/fremap.c
> > @@ -212,8 +212,8 @@ asmlinkage long sys_remap_file_pages(u
te_range returns. If the pte
is unmapped and the page is mapped back in with a minor fault that's
ok, as long as the physical page remains the same for that mm+address,
until all sptes are gone.
Signed-off-by: Andrea Arcangeli <[EMAIL PROTECTED]>
diff --git a/mm/fremap.c b/mm/frem
On Tue, Jan 29, 2008 at 01:53:05PM -0800, Christoph Lameter wrote:
> On Tue, 29 Jan 2008, Andrea Arcangeli wrote:
>
> > > We invalidate the range *after* populating it? Isnt it okay to establish
> > > references while populate_range() runs?
> >
> > It
On Tue, Jan 29, 2008 at 02:55:56PM -0800, Christoph Lameter wrote:
> On Tue, 29 Jan 2008, Andrea Arcangeli wrote:
>
> > But now I think there may be an issue with a third thread that may
> > show unsafe the removal of invalidate_page from ptep_clear_flush.
> >
> &g
On Tue, Jan 29, 2008 at 02:39:00PM -0800, Christoph Lameter wrote:
> If it does not run in write mode then concurrent faults are permissible
> while we remap pages. Weird. Maybe we better handle this like individual
> page operations? Put the invalidate_page back into zap_pte. But then there
> wo
On Wed, Jan 30, 2008 at 01:00:39AM +0100, Andrea Arcangeli wrote:
> get_user_pages, regular linux writes don't fault unless it's
> explicitly writeprotect, which is mandatory in a few archs, x86 not).
actually get_user_pages doesn't fault either but it calls into
se
On Tue, Jan 29, 2008 at 04:22:46PM -0800, Christoph Lameter wrote:
> That is only partially true. pte are created wronly in order to track
> dirty state these days. The first write will lead to a fault that switches
> the pte to writable. When the page undergoes writeback the page again
> become
On Tue, Jan 29, 2008 at 06:28:05PM -0600, Jack Steiner wrote:
> On Tue, Jan 29, 2008 at 04:20:50PM -0800, Christoph Lameter wrote:
> > On Wed, 30 Jan 2008, Andrea Arcangeli wrote:
> >
> > > > invalidate_range after populate allows access to memory for which ptes
On Tue, Jan 29, 2008 at 06:29:10PM -0800, Christoph Lameter wrote:
> +void mmu_notifier_release(struct mm_struct *mm)
> +{
> + struct mmu_notifier *mn;
> + struct hlist_node *n, *t;
> +
> + if (unlikely(!hlist_empty(&mm->mmu_notifier.head))) {
> + rcu_read_lock();
> +
On Wed, Jan 30, 2008 at 09:53:06AM -0600, Jack Steiner wrote:
> That will also resolve the problem we discussed yesterday.
> I want to unregister my mmu_notifier when a GRU segment is
> unmapped. This would not necessarily be at task termination.
My proof that there is something wrong in the smp
On Wed, Jan 30, 2008 at 10:11:24AM -0600, Robin Holt wrote:
> > Robin, if you don't mind, could you please post or upload somewhere
> > your GPLv2 code that registers itself in Christoph's V2 notifiers? Or
> > is it top secret? I wouldn't mind to have a look so I can better
> > understand what's th
On Wed, Jan 30, 2008 at 11:30:09AM -0600, Robin Holt wrote:
> I don't think I saw the answer to my original question. I assume your
> original patch, extended in a way similar to what Christoph has done,
> can be made to work to cover both the KVM and GRU (Jack's) case.
Yes, I think so.
> XPMEM,
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 f
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
secc
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 y
If we've done a decent amount of scanning and
This below is an untested attempt at bringing dquot a bit more in line
with the API, to make the whole thing a bit more consistent, though I
doubt you're using quotas, so it's only the above one that's going to be
interesting for y
On Wed, Mar 16, 2005 at 09:28:51AM +0100, Ingo Molnar wrote:
> in fact, we had bugs on x86 where if userspace set up a specific value
> for %ebx the kernel would crash, because the irq entry code was
> incorrect. (this might even have been exploitable) So yes, if seccomp
> would be backported to th
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
expect
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 http://v
On Tue, Feb 08, 2005 at 04:26:26PM +, Hugh Dickins wrote:
> Seems it was okay after all, I got confused by an unrelated issue.
> Here's what I had in mind, what do you think? Does it indeed help
> with your problem? I'm copying Andrea because it was he who devised
> that fix to the get_user_p
On Thu, Feb 10, 2005 at 11:16:44AM -0800, Dave Hansen wrote:
> We actually do that, in addition to the more active methods of capturing
> the memory that we're about to remove.
This sounds the best way to go. btw, is this a different codebase from
the one that Toshihiro is testing?
> You're right
On Thu, Feb 10, 2005 at 08:19:47PM +, Hugh Dickins wrote:
> On Thu, 10 Feb 2005, Andrea Arcangeli wrote:
> >
> > The reason pinned pages cannot be unmapped is that if they're being
> > unmapped while a rawio read is in progress, a cow on some shared
> >
On Fri, Feb 11, 2005 at 07:23:09AM +, Hugh Dickins wrote:
> And it's fine for the behaviour to be somewhat undefined in this
> peculiar case: the important thing is just that the page must not
> be freed and reused while I/O occurs, hence get_user_page raising
> the page_count - which I'm _not_
> By the way, while we're talking of remove_exclusive_swap_page:
> a more functional issue I sometimes wonder about, why don't we
> remove_exclusive_swap_page on write fault? Keeping the swap slot
> is valuable if read fault, but once the page is dirtied, wouldn't
> it usually be better to free th
On Mon, Feb 14, 2005 at 06:36:43PM +, Hugh Dickins wrote:
> On Mon, 14 Feb 2005, Andrea Arcangeli wrote:
> > > By the way, while we're talking of remove_exclusive_swap_page:
> > > a more functional issue I sometimes wonder about, why don't we
> > > r
r to fix it right for me in a single place than to
hand edit the (not single) change_page_attr callers. I'd like the right
fix to obsolete the hand editing of arch code in multiple places that
breaks the layering. Thanks.
From: Andrea Arcangeli <[EMAIL PROTECTED]>
Subject: reject zero p
On Sun, Jan 23, 2005 at 07:34:24AM +, David Wagner wrote:
> What if 6 months from now we discover that we really should have enabled
> one more syscall in seccomp to accomodate other applications?
This is why there's a seccomp mode number, and you've to choose it, I
only implemented mode 0 so
Hello,
This is the latest version against 2.6.11-rc4:
http://www.kernel.org/pub/linux/kernel/people/andrea/patches/v2.6/2.6.11-rc4/seccomp
I'd need it merged into mainline at some point, unless anybody has
strong arguments against it. All I can guarantee here, is that I'll back
it out m
On Tue, Feb 15, 2005 at 11:39:15AM +0100, Andi Kleen wrote:
> On Tue, Feb 15, 2005 at 12:15:54AM +0100, Andrea Arcangeli wrote:
> > Hello,
> >
> > the fix for this bug in 2.6.11-rc3 for this bug is wrong, I thought I
>
> Can you describe what exactly is wrong?
t
On Tue, Feb 15, 2005 at 11:51:52AM +0100, Andi Kleen wrote:
> Ok, so it is merely a cosmetic issue.
In practice it's solved, I didn't mean we had a bug still, I'm just
suggesting to fix it in a diffeerent way.
It's not just for cosmetic reasons that I suggest to change this. My
point is that the
On Wed, Feb 16, 2005 at 06:25:03AM +0100, Herbert Poetzl wrote:
> hmm, just an idea, but have you thought about using
> an indirect syscall table for your purposes?
>
> current->syscall_table
>
> and have a table for every 'mode' you want to use ...
That would add an additional level of indire
On Mon, Feb 14, 2005 at 12:05:44PM -0800, Larry McVoy wrote:
> That's not how others are reading it and when we requested clarification
> from the legal firm we use for contracts (Fenwick&West if you care) they
> said that it could well be interpreted that if you use BK you are giving
> up your rig
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
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 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
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 applica
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 __oom_kil
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 s
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 numb
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
> mak
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 em
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/unlo
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
ore sense to me for a
"write-only" fd IMHO, and I had no pratical problems with this patch
yet (not that I've run any big stress test though, just normal misc
usage with all sort of desktop apps and twisted). Comments welcome thanks!
Patch is against 2.6.11-rc5.
Signed-off-by: An
> > 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 no
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 r
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 conf
ence of POLLIN and POLLRDNORM, I
suspect there's no difference for pipe(2) that has a single band (I
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).
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
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
There are a number of changes in kernel API visisble to userspace that
are unregistered in 2.4 mainline. I recommend to merge them ASAP to
avoid generating collisions across different versions of the kernel.
I'll attach here a number of patches that should make us to return in
sync. They must be
On Thu, Jun 14, 2001 at 07:12:19PM +0200, Andrea Arcangeli wrote:
> is not definitive yet, O_DIRECTIO of tru64 is our O_NOFOLLOW so we're
> just screwed as we just need a wrapper anyways to make complex programs like
I just got the email from Richard that he prefers to break O_NOFOL
On Thu, Jun 14, 2001 at 07:16:34PM +0200, Andrea Arcangeli wrote:
> I just got the email from Richard that he prefers to break O_NOFOLLOW
Richard are you sure we can break O_NOFOLLOW and still expect the machine to
boot?
./elf/cache.c: fd = open (temp_name, O_CREAT|O_WRONLY|O_TRUNC|O_NOFOL
On Thu, Jun 14, 2001 at 01:25:10PM -0400, Jeff Garzik wrote:
> They don't hurt but it's also a bad precedent - you don't want to add a
> ton of CONFIG_xxx to the Linus tree for stuff outside the Linus tree.
> disagree with this patch.
If tux will ever be merged into mainline eventually I don't t
On Thu, Jun 14, 2001 at 10:32:49AM -0700, Richard Henderson wrote:
> within glibc, and (2) making these accesses slower since they
> will be considered O_DIRECT after the change.
and then read/write will return -EINVAL which is life-threatening.
O_DIRECT like rawio via /dev/raw imposes special bu
On Thu, Jun 14, 2001 at 01:52:44PM -0400, Jeff Garzik wrote:
> You're missing the point -- it's a bad precedent.
>
> How many kernel forks and patches exist out there on the net?
How many of them are applied to 90% of kernels running out there? How
many of them will get merged eventually? How ma
901 - 1000 of 2012 matches
Mail list logo
