here is an update wrt. the latest checkpatch.pl-next version
(v11-to-be), about kernel/sched.c warnings:
> size # warnings
>
> 25383 checkpatch.pl.v6 5
> 26038 checkpatch.pl.v7 6
> 29603 checkpatch.pl.v8
Pavel Emelianov [EMAIL PROTECTED] wrote:
| Some time ago Sukadev noticed that the vmlinux size has
Cedric pointed it out to me first :-)
| grown 5Kb due to merged pid namespaces. One of the big
| problems with it was fat inline functions. The other thing
| was noticed by Matt - the checks for
Vivek Goyal wrote:
> On Thu, Oct 04, 2007 at 08:38:34PM +0900, Takenori Nagano wrote:
>> This patch adds new notifier function tunable_notifier_chain. Its base is
>> atomic_notifier_chain.
>>
>> Thanks,
>>
>> ---
>>
>> Signed-off-by: Takenori Nagano <[EMAIL PROTECTED]>
>>
>> ---
>> diff -uprN
On Oct 05, 2007, at 00:45:17, Eric W. Biederman wrote:
Kyle Moffett <[EMAIL PROTECTED]> writes:
On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote:
SElinux is not all encompassing or it is generally
incomprehensible I don't know which. Or someone long ago would
have said a better way
On Thu, Oct 04, 2007 at 08:38:50PM +0900, Takenori Nagano wrote:
> This patch implements new notifier function to panic_notifier_list. We can
> change the list of order by debugfs.
>
> Thanks,
>
> ---
>
> Signed-off-by: Takenori Nagano <[EMAIL PROTECTED]>
>
> ---
> diff -uprN
Vivek Goyal wrote:
> On Thu, Oct 04, 2007 at 08:38:05PM +0900, Takenori Nagano wrote:
>
> In summary, right now co-existence of kdb with kdump seems to be your pain
> point. I would prefer that kdb just puts a break point on panic() and we move
> on. If there are more candidates down the line and
On Thu, Oct 04, 2007 at 08:38:34PM +0900, Takenori Nagano wrote:
> This patch adds new notifier function tunable_notifier_chain. Its base is
> atomic_notifier_chain.
>
> Thanks,
>
> ---
>
> Signed-off-by: Takenori Nagano <[EMAIL PROTECTED]>
>
> ---
> diff -uprN
* Glauber de Oliveira Costa <[EMAIL PROTECTED]> wrote:
> On 10/2/07, Alistair John Strachan <[EMAIL PROTECTED]> wrote:
> > This is certainly a tool issue, but if I use Debian's kernel-image
> > "make-kpkg"
> > wrapper around the kernel build system, it fails with:
> >
> > cp: cannot stat
* Alistair John Strachan <[EMAIL PROTECTED]> wrote:
> On Tuesday 02 October 2007 04:41:49 Linus Torvalds wrote:
> [snip]
> > In other words, people who know they may be affected and would want to
> > prepare can look at (for example)
> >
> >
Introduce irq_desc_match_fist_irqaction() to support setup_irq()
code modularity.
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
Any ideas for a better method name ?
manage.c | 89 ---
1 file changed, 51 insertions(+), 38
Hi Thomas/lkml,
setup_irq() code contains a big chunk of 130 code lines that
can be divided to several smaller methods. These 2 patches introduce
those small functions to aid toward setup_irq() code modularity.
No major code logic changes exist.
Patches can be applied cleanly over
Randy Dunlap wrote:
> On Thu, 04 Oct 2007 20:38:34 +0900 Takenori Nagano wrote:
>> diff -uprN linux-2.6.23-rc9.orig/kernel/sys.c linux-2.6.23-rc9/kernel/sys.c
>> --- linux-2.6.23-rc9.orig/kernel/sys.c 2007-10-02 12:24:52.0
>> +0900
>> +++ linux-2.6.23-rc9/kernel/sys.c2007-10-03
Randy Dunlap wrote:
> On Thu, 04 Oct 2007 20:38:50 +0900 Takenori Nagano wrote:
>
>> This patch implements new notifier function to panic_notifier_list. We can
>> change the list of order by debugfs.
>>
>> Thanks,
>>
>> ---
>>
>> Signed-off-by: Takenori Nagano <[EMAIL PROTECTED]>
>>
>> ---
>> *
Kyle Moffett <[EMAIL PROTECTED]> writes:
> On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote:
>> What we want from the LSM is the ability to say -EPERM when we can clearly
>> articulate that we want to disallow something.
>
> This sort of depends on perspective; typically with security
On Thu, Oct 04, 2007 at 08:38:05PM +0900, Takenori Nagano wrote:
> Hi,
>
> These patches add new notifier function and implement it to
> panic_notifier_list.
> We used the hardcoded notifier chain so far, but it was not flexible. New
> notifier is very flexible, because user can change a list of
Hi Ingo,
I am seeing a problem on the latest -rt where lockdep completely overwhelms
the system to the point that it grinds to a halt on large (8-way+) systems.
The problem seems to be that the class->locks_before and locks_after grow
unbounded (I have observed over 1M+ entries in them) so
Doh! I guess there should be a rule about sending patches out after midnight
;)
The original patch I worked on was written before the code was moved to
validate_chain(), so my previous posting didnt quite translate when I merged
with git HEAD. Here is an updated patch. Sorry for the confusion.
> On 10/04/2007 07:39 PM, David Schwartz wrote:
> > But this is just a preposterous position to put him in. If there's no
> > reproduceable test case, then why should he care that one
> > program he can't
> > even see works badly? If you care, you fix it.
> People have been trying for years to
Rik van Riel wrote:
> Either of these two would work. Another alternative could be to
> let test_and_clear_pte_flags have an exception table entry, where
> we jump right to the next instruction if the instruction clearing
> the flag fails.
>
> That is the essentially variant you need for Xen,
Andrew Morton wrote:
> y'know, I think I think it's been several years since I saw a report of an
> honest to goodness, genuine SMP race in core kernel. We used to be
> infested by them, but the term has fallen into disuse. Interesting, but
> OT.
>
I was a bit surprised to find myself typing
hello,
Thanks rolf & roland.
pci_iomap() is not doing something extra. only it is some kind of
abstraction for IO-mapped OR memory mapped.
I know that my BARs are MMIO, so using ioremap() & readl()/writel()
combination should be fine.
But for the problem as explained in my first mail, any
gurudas pai wrote:
Hugh Dickins wrote:
On Thu, 4 Oct 2007, gurudas pai wrote:
Nick Piggin wrote:
While running Oracle database test on x86/6GB RAM machine panics with
following messages.
Hmm, seems like something in sys_remap_file_pages might have broken.
It's a bit hard to work out from the
On Thu, Oct 04, 2007 at 03:03:44PM +1000, David Chinner wrote:
> On Thu, Oct 04, 2007 at 10:21:33AM +0800, Fengguang Wu wrote:
> > On Wed, Oct 03, 2007 at 12:41:19PM +1000, David Chinner wrote:
> > > On Wed, Oct 03, 2007 at 09:34:39AM +0800, Fengguang Wu wrote:
> > > > On Wed, Oct 03, 2007 at
On Wed, Oct 03, 2007 at 04:59:51PM -0400, Steven Rostedt wrote:
> Paul,
>
> I ran your original preemption test of RCU torture, and after several
> minutes, my preempt boost patch had one Preemption stall. I then
> disabled preemption boosting, and ran the preempt torture again, and it
> seemed
On Thu, Oct 04, 2007 at 05:12:11PM -0700, Linus Torvalds wrote:
> I also tested that "ulimit -s" seems to do the right thing for me.
>
> I'm also assuming Mathieu is running x86 (or x86-64): HP-PA has a stack
> that grows upwards, and that has traditionally been exciting.
Correct, x86 it is but
> Subject: [Intel-IOMMU] Fix for IOMMU early crash
>
> pci_dev's->sysdata is highly overloaded and currently
> IOMMU is broken due to IOMMU code depending on this field.
>
> This patch introduces new field in pci_dev's dev.archdata struct to
> hold IOMMU specific per device IOMMU private data.
Hugh Dickins wrote:
> On Thu, 4 Oct 2007, Balbir Singh wrote:
>> Hugh Dickins wrote:
>>> Well, swap control is another subject. I guess for that you'll need
>>> to track which cgroup each swap page belongs to (rather more expensive
>>> than the current swap_map of unsigned shorts). And I doubt
On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote:
What we want from the LSM is the ability to say -EPERM when we can
clearly articulate that we want to disallow something.
This sort of depends on perspective; typically with security
infrastructure you actually want "... the ability to
On Thu, 4 Oct 2007 19:43:58 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> So there could still be page struct contention left if multiple
> processors frequently and simultaneously free to the same slab and
> that slab is not the per cpu slab of a cpu. That could be addressed
> by
Hugh Dickins wrote:
On Thu, 4 Oct 2007, gurudas pai wrote:
Nick Piggin wrote:
While running Oracle database test on x86/6GB RAM machine panics with
following messages.
Hmm, seems like something in sys_remap_file_pages might have broken.
It's a bit hard to work out from the backtrace, though.
On Tue, Oct 02, 2007 at 08:00:26PM +0200, Jan Engelhardt wrote:
> Add %S_IWUGO bit for files on ISO-9660 filesystems without RockRidge
Looks to me like you've added S_IWUSR, not S_IWUGO.
> - popt->mode = S_IRUGO | S_IXUGO; /*
> + popt->mode = S_IRUGO | S_IWUSR | S_IXUGO;
> -
On Thu, 04 Oct 2007 18:43:32 -0700 Jeremy Fitzhardinge <[EMAIL PROTECTED]>
wrote:
> David's change 10a8d6ae4b3182d6588a5809a8366343bc295c20, "i386: add
> ptep_test_and_clear_{dirty,young}" has introduced an SMP race which
> affects the Xen pv-ops backend.
y'know, I think I think it's been
I just spend some time looking at the functions that you see high in the
list. The trouble is that I have to speculate and that I have nothing to
verify my thoughts. If you could give me the hitlist for each of the
3 runs then this would help to check my thinking. I could be totally off
here.
Hi,
On Mon, 1 Oct 2007, Oleg Verych wrote:
> Today's kconfig was proposed and accepted in a very unpleasant
> circumstances, has very poor design, development and no working
> alternative (for 5+ years now).
If you want to make such statements, you have to offer a little more than
the hot air
Hi,
On Thu, 20 Sep 2007, Shlomi Fish wrote:
> Which specific problems do you see with the coding style of the patch? Can
> you
> comment on it?
Mostly whitespace around any braces, please keep it close to the other
source.
> > I would also prefer to move more of the search functionality
On Thursday 04 October 2007 3:17:03 pm Randy Dunlap wrote:
> On Thu, 04 Oct 2007 22:04:07 +0200 Vegard Nossum wrote:
> > Description: This patch largely implements the kprint API as previously
> > posted to the LKML and described in Documentation/kprint.txt (see patch).
> >
> > The main purpose of
Just as a quick update -- I seem to only be able to reproduce this
crash when my ppp session drops, which seems associated with marginal
signal. And unfortunately I have great coverage at home so I haven't
been able to reproduce this again today. Maybe on the train tomorrow
I can crash my
On Thu, 04 Oct 2007 18:43:32 -0700
Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> It seems to me that there are a few ways to fix this:
>
>1. Use asm-generic/pgtable.h when CONFIG_PARAVIRT is enabled. This
> will clearly work, but is pretty blunt.
>2. Make
Linus Torvalds <[EMAIL PROTECTED]> writes:
> To get back to security: I didn't want pluggable security because I
> thought that was a technically good solution. No, the reason Linux has LSM
> (and yes, I was the one who pushed hard for the whole thing, even if I
> didn't actually write any of
David's change 10a8d6ae4b3182d6588a5809a8366343bc295c20, "i386: add
ptep_test_and_clear_{dirty,young}" has introduced an SMP race which
affects the Xen pv-ops backend.
In Xen, pagetables are normally kept RO so that the hypervisor can
mediate all updates to them. If Xen sees a write to an active
On Thu, 2007-10-04 at 12:59 -0700, Andrew Morton wrote:
> On Thu, 04 Oct 2007 15:16:03 -0400
> Trond Myklebust <[EMAIL PROTECTED]> wrote:
>
> > > >
> > > > That would be perfect. It can even be in non-legacy mode by default,
> > > > just as long as you can go back to the old behaviour when/if
Mikael Pettersson wrote::
On Thu, 4 Oct 2007 21:47:30 +0900, KAMEZAWA Hiroyuki wrote:
On Thu, 04 Oct 2007 21:33:12 +0900
Shi Weihua <[EMAIL PROTECTED]> wrote:
KAMEZAWA Hiroyuki wrote::
On Thu, 04 Oct 2007 20:56:14 +0900
Shi Weihua <[EMAIL PROTECTED]> wrote:
stack.ss_sp = addr +
On Fri, 05 Oct 2007 02:12:30 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> >
> > I don't think I understand that. Sure, it _shouldn't_ be a problem. But it
> > _is_. That's what we're trying to fix, isn't it?
>
> The problem, I believe is in the memory allocation code, not in fuse.
fuse
On Thu, Oct 04, 2007 at 01:51:13PM -0700, David Miller wrote:
>
> I don't want to jump the gun on the analysis but it just might
> be the packet sharing fixes Herbert put in a short time ago.
I think the only change of mine that could affect ppp over a
serial line is this one. I couldn't see
On Friday, 5 October 2007 02:11, H. Peter Anvin wrote:
> Rafael J. Wysocki wrote:
> >
> > Subject:vga text console not working on 2.6.23-rc8
> > Submitter: Santiago Garcia Mantinan <[EMAIL PROTECTED]>
> > References: http://lkml.org/lkml/2007/9/28/342
> >
On Fri, 5 Oct 2007, Paul Mackerras wrote:
> Linus Torvalds writes:
> >
> > Well, since others definitely don't see this, including me, and I can do
> > things like 62MB exec arrays:
> >
> > [EMAIL PROTECTED] linux]$ echo $(find /home/torvalds/) | wc
> > 1 883304 63000962
>
>
> > > This is a somewhat general problem: a userspace process is in the IO
> > > path.
> > > Userspace block drivers, for example - pretty much anything which involves
> > > kernel->userspace upcalls for storage applications.
> > >
> > > I solved it once in the past by marking the userspace
Rafael J. Wysocki wrote:
Subject:vga text console not working on 2.6.23-rc8
Submitter: Santiago Garcia Mantinan <[EMAIL PROTECTED]>
References: http://lkml.org/lkml/2007/9/28/342
http://bugzilla.kernel.org/show_bug.cgi?id=9099
Handled-By: H. Peter Anvin
On 10/04/2007 07:58 PM, William Cattey wrote:
>
> Sadly, the effect of the patch is the same as the most recent candidate
> patch from Jeremy Fitzhardinge: The EDID transfer still comes up all
> zeros.
>
I think maybe a better question is: why does read_edid still work?
The X server might be
On 10/2/07, Tony Breeds <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 03, 2007 at 10:30:16AM +1000, Michael Ellerman wrote:
>
> > I realise it'll make the patch bigger, but this doesn't seem like a
> > particularly good name for the variable anymore.
>
> Sure, what about?
>
> Clarify when RTAS logging
Thanks very much for thinking about this and providing a revised
candidate patch.
Sadly, the effect of the patch is the same as the most recent
candidate patch from Jeremy Fitzhardinge: The EDID transfer still
comes up all zeros.
This is very perplexing to me. If I take the code that
On 10/04/2007 07:39 PM, David Schwartz wrote:
> But this is just a preposterous position to put him in. If there's no
> reproduceable test case, then why should he care that one program he can't
> even see works badly? If you care, you fix it.
>
People have been trying for years to make
On Fri, 05 Oct 2007 01:26:12 +0200
Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > This is a somewhat general problem: a userspace process is in the IO path.
> > Userspace block drivers, for example - pretty much anything which involves
> > kernel->userspace upcalls for storage applications.
> >
On Thu, Oct 04, 2007 at 07:18:47PM -0400, Chuck Ebbert wrote:
> > I ran firefox setuid to a different (not my main user), uid+gid, gave
> > my main account that gid as a supplemental group, and gave that uid
> > access to the X magic cookie.
>
> You need to use runxas to get any kind of real
David Miller wrote:
> Using an unpublishable benchmark, whose results even cannot be
> published, really stretches the limits of "reasonable" don't you
> think?
>
> This "SLUB isn't ready yet" bullshit is just a shamans dance which
> distracts attention away from the real problem, which is that
> Cute feature, but it is (I assume) a Linux-specific extension and is
> something which we'll need to maintain for ever and it invites
Actually it used to work on the old old Linux pipe code.
> unportability to older Linuxes and other OSes and it introduces some risk
> of breakage of existing
On Thu, Oct 04, 2007 at 12:54:17PM +0400, Pavel Emelyanov wrote:
> Matt Mackall wrote:
> > On Wed, Oct 03, 2007 at 06:20:43PM +0400, Pavel Emelyanov wrote:
> >> Just make the __pid_nr() etc functions that expect the argument
> >> to always be not NULL.
> >>
> >> Signed-off-by: Pavel Emelyanov
On Thu, Oct 04, 2007 at 07:32:52AM +0200, Torsten Kaiser wrote:
> On 10/3/07, Matt Mackall <[EMAIL PROTECTED]> wrote:
> > Well I can see no reason why the vma we just got to by the mm->mmap
> > would have a vm_mm != mm, but I've certainly been wrong before.
> >
> > Try changing it to:
> >
> >
> This is a somewhat general problem: a userspace process is in the IO path.
> Userspace block drivers, for example - pretty much anything which involves
> kernel->userspace upcalls for storage applications.
>
> I solved it once in the past by marking the userspace process as
> PF_MEMALLOC and I
On Tue, 2 Oct 2007 19:54:53 +0200 (CEST)
Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> [PATCH]: Fill the size of pipes
>
> Instead of reporting 0 in size when stating() a pipe, we give the number of
> queued bytes. This might avoid using ioctl(FIONREAD) to get this information.
>
> References and
Edward Shishkin wrote:
Dave Hansen wrote:
...
I think that stack allocation is a pretty nasty trick for a structure
that's supposed to be pretty persistent and dynamically allocated, and
is certainly something that needs to get fixed up in a proper way.
agreed.
This works around the
Jan Engelhardt wrote:
On Aug 23 2007 15:59, Martin Vogt wrote:
...
Even if knoppix should not be used as a rescue/live CD, then
the reiserfs module should not try to correct something,
this should be done by another tool.(fsck.reiserfs or a module option...)
The attached patch
On 10/04/2007 06:56 PM, Derek Fawcus wrote:
>
> I ran firefox setuid to a different (not my main user), uid+gid, gave
> my main account that gid as a supplemental group, and gave that uid
> access to the X magic cookie.
You need to use runxas to get any kind of real security.
-
To unsubscribe
Booting git snapshot of about 6 hours ago, getting the following:
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt Link [ALKB] enabled at IRQ 21
ACPI: PCI Interrupt :00:10.0[A] -> Link [ALKB] -> GSI 21 (level, low) ->
IRQ 18
ACPI: PCI interrupt for device :00:10.0
> hm. At no point in this patch series does anything actually get added to
> these lists, so this patch is presently a no-op.
>
> I'll assume that it will get used later. But it is a bit odd to add
> infrastructure in a patch series, then not use it. Why not hold the patch
> back and include
> > From: Miklos Szeredi <[EMAIL PROTECTED]>
> >
> > Allow the userspace filesystem to supply a blksize value to be
> > returned by stat() and friends. If the field is zero, it defaults to
> > the old PAGE_CACHE_SIZE value.
> >
>
> Why does fuse need this feature?
There are cases, when the
Andi Kleen wrote:
On Thu, Oct 04, 2007 at 12:19:35PM -0700, David Wilder wrote:
Andi Kleen wrote:
"David J. Wilder" <[EMAIL PROTECTED]> writes:
@@ -0,0 +1,160 @@
+Trace Setup and Control
+===
+In the kernel, the trace interface provides a simple mechanism for
+starting and
On Thu, 4 Oct 2007 16:40:44 -0600
Andreas Dilger <[EMAIL PROTECTED]> wrote:
> On Oct 04, 2007 13:12 -0700, Andrew Morton wrote:
> > On Mon, 01 Oct 2007 17:35:46 -0700
> > > ext2: Avoid rec_len overflow with 64KB block size
> > >
> > > into 16 bits we have for entry lenght. So we store 0x
On Fri, 05 Oct 2007 00:39:16 +0200
Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > throttle_vm_writeout() should be a per-zone thing, I guess. Perhaps fixing
> > that would fix your deadlock. That's doubtful, but I don't know anything
> > about your deadlock so I cannot say.
>
> No, doing the
On Wed, Oct 03, 2007 at 01:12:46AM +0100, Alan Cox wrote:
>
> The value of SELinux (or indeed any system compartmentalising access and
> limiting damage) comes into play when you get breakage - eg via a web
> browser exploit.
well, being sick of the number of times one has to upgrade the
On Tue, 02 Oct 2007 17:50:38 +0200
Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> Allow the userspace filesystem to supply a blksize value to be
> returned by stat() and friends. If the field is zero, it defaults to
> the old PAGE_CACHE_SIZE value.
>
> > @@ -228,6 +243,7 @@ static struct dentry *fuse_lookup(struct
> > struct fuse_conn *fc = get_fuse_conn(dir);
> > struct fuse_req *req;
> > struct fuse_req *forget_req;
> > + u64 attr_version;
> >
> > if (entry->d_name.len > FUSE_NAME_MAX)
> > return
On Tue, 02 Oct 2007 17:50:35 +0200
Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> Each WRITE request must carry a valid file descriptor. When a page is
> written back from a memory mapping, the file through which the page
> was dirtied is not available,
Hi
Got an AXIS 700 Lite thin client with a C7 CPU and CN700 chipset in it,
compiled today's git snapshot, and it Oopses in i2c_viapro:
BUG: unable to handle kernel paging request at virtual address 016c0555
printing eip:
c01a60ed
*pde =
Oops: [#1]
PREEMPT
Modules linked in:
On Thu, 04 Oct 2007 16:28:07 +0400
Rusev <[EMAIL PROTECTED]> wrote:
> All that should be moved to DEBUGFS under /sys/kernel/debug and so on
> - that's right, a bit other issue
> is of interest for me.
>
> My suggestion is that a few other problems with PROCFS exist:
>
> From my observation
On Tue, 02 Oct 2007 17:50:28 +0200
Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> @@ -228,6 +243,7 @@ static struct dentry *fuse_lookup(struct
> struct fuse_conn *fc = get_fuse_conn(dir);
> struct fuse_req *req;
> struct fuse_req *forget_req;
> + u64 attr_version;
>
>
On Oct 04, 2007 13:12 -0700, Andrew Morton wrote:
> On Mon, 01 Oct 2007 17:35:46 -0700
> > ext2: Avoid rec_len overflow with 64KB block size
> >
> > into 16 bits we have for entry lenght. So we store 0x instead and
> > convert value when read from / written to disk.
>
> This patch clashes
> None of the above.
>
> [PATCH] vm: pageout throttling
>
> With silly pageout testcases it is possible to place huge amounts of
> memory
> under I/O. With a large request queue (CFQ uses 8192 requests) it is
> possible to place _all_ memory under I/O at the same time.
>
The previous version of this patch missed a code path in
inserting the boot cpu into the cpu sibling and core maps.
This fix corrects that omission.
--
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
There are two versions of per_cpu_init() for ia64. This patch corrects
the problem that one of the versions did not insert the boot cpu
into the cpu sibling and core maps.
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
arch/ia64/kernel/setup.c |8
arch/ia64/mm/contig.c|
Am Freitag, 5. Oktober 2007 schrieb Chuck Ebbert:
> On 10/04/2007 05:10 PM, Christian Borntraeger wrote:
>
> >
>
> Alternative patch:
>
> procfs: Don't read runtime twice when computing task's stime
>
> Current code reads p->se.sum_exec_runtime twice and goes through
> multiple type
Linus Torvalds writes:
> Well, since others definitely don't see this, including me, and I can do
> things like 62MB exec arrays:
>
> [EMAIL PROTECTED] linux]$ echo $(find /home/torvalds/) | wc
> 1 883304 63000962
That wouldn't actually do an exec, assuming you're using
On Thu, Oct 04, 2007 at 03:07:18PM -0700, David Miller wrote:
> From: Chuck Ebbert <[EMAIL PROTECTED]> Date: Thu, 04 Oct 2007 17:47:48
> -0400
>
> > On 10/04/2007 05:11 PM, David Miller wrote:
> > > From: Chuck Ebbert <[EMAIL PROTECTED]> Date: Thu, 04 Oct 2007 17:02:17
> > > -0400
> > >
> > >>
We are pleased to announce the 2.6.23-rc9-rt2 tree, which can be
downloaded from the new location:
http://www.kernel.org/pub/linux/kernel/projects/rt/
Changes since 2.6.23-rc9-rt1
- x86_64 disable IST for debug (Andi Kleen)
- Better handling of dynticks going bad in RCU (Steven Rostedt)
From: Chuck Ebbert <[EMAIL PROTECTED]>
Date: Thu, 04 Oct 2007 17:47:48 -0400
> On 10/04/2007 05:11 PM, David Miller wrote:
> > From: Chuck Ebbert <[EMAIL PROTECTED]>
> > Date: Thu, 04 Oct 2007 17:02:17 -0400
> >
> >> How do you simulate reading 100TB of data spread across 3000 disks,
> >>
On 10/04/2007 05:10 PM, Christian Borntraeger wrote:
>
Alternative patch:
procfs: Don't read runtime twice when computing task's stime
Current code reads p->se.sum_exec_runtime twice and goes through
multiple type conversions to calculate stime. Read it once and
skip some of the conversions.
On Thu, Oct 04, 2007 at 07:17:50PM +0200, Peter Zijlstra wrote:
> what happens if you up the stack limit to say 128M ?
>
> Also, do you happen to have execve syscall audit stuff enabled?
Actually, you were right, not only it's enabled but it's also the
culprit. If I stop it, all is well...
On Thu, 04 Oct 2007 14:25:22 +0200
Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> By relying on the global diry limits, this can cause a deadlock when
> devices are stacked.
>
> If the stacking is done through a fuse filesystem, the __GFP_FS,
> __GFP_IO
Hi,
This message contains a list of some known regressions from 2.6.22 for which
there are no fixes in the mainline that I know of. If any of them have been
fixed
already, please let me know.
If you know of any other unresolved regressions from 2.6.22, please let me know
either and I'll add
On Thu, Oct 04, 2007 at 05:50:00PM -0400, Chuck Ebbert wrote:
> On 10/04/2007 01:05 PM, Mathieu Chouquet-Stringer wrote:
> > In the kernel source tree, if I run a stupid find | xargs ls, I now get
> > this:
> > xargs: ls: Argument list too long
> >
>
> Can you strace it to see what syscall is
The following patch is a generalization of the latency.c implementation
done by Arjan last year. It provides infrastructure for more than one
parameter, and exposes a user mode interface for processes to register
pm_qos expectations of processes.
This interface provides a kernel and user mode
On 10/04/2007 01:05 PM, Mathieu Chouquet-Stringer wrote:
> In the kernel source tree, if I run a stupid find | xargs ls, I now get
> this:
> xargs: ls: Argument list too long
>
Can you strace it to see what syscall is failing?
-
To unsubscribe from this list: send the line "unsubscribe
On 10/04/2007 05:11 PM, David Miller wrote:
> From: Chuck Ebbert <[EMAIL PROTECTED]>
> Date: Thu, 04 Oct 2007 17:02:17 -0400
>
>> How do you simulate reading 100TB of data spread across 3000 disks,
>> selecting 10% of it using some criterion, then sorting and
>> summarizing the result?
>
> You
On Thu, Oct 04, 2007 at 07:17:50PM +0200, Peter Zijlstra wrote:
> /me tries
>
> yep works like a charm, and that is a tree with a full git repo and
> several build dirs in it.
Well, what can I say? ;-)
> what happens if you up the stack limit to say 128M ?
It's unlimited.
> Also, do you
On Thu, 2007-10-04 at 18:13 +0200, Valerie Clement wrote:
> While running ffsb tests on my ext4 filesystem, I got an Oops in
> cache_alloc_refill().
> I turned on SLAB debugging and here is the message I got:
>
> slab: Internal list corruption detected in cache 'buffer_head'(30),
> slabp
Thank you for getting back to me.
On Thu, Oct 04, 2007 at 10:27:52AM -0700, Linus Torvalds wrote:
> What does your "ulimit -s" say?
That's actually the first thing I checked.
mchouque - /usr/src/kernel/linux %ulimit -s
unlimited
And for the record, ulimit -a yields:
-t: cpu time (seconds)
On Thu, 04 Oct 2007 10:54:51 +0200, Heiko Carstens said:
> > echo 2048 > /sys/kernel/uids/500/cpu_share
> >
> > this should just work too, regardless of there not being any UID 500
> > tasks yet. Likewise, once configured, the /sys/kernel/uids/* directories
> > (with the settings in them)
On Tue, 02 Oct 2007 16:41:47 +0800
Fengguang Wu <[EMAIL PROTECTED]> wrote:
> This patch fixes this bug. Though I'm not sure why __block_write_full_page()
> is called only to do nothing and who actually issued the writeback for us.
kjourald wrote the page's buffers back (ext3 in ordered-data
On Thu, 4 Oct 2007, Mathieu Chouquet-Stringer wrote:
>
> Anything else you'd like me to try?
Well, since others definitely don't see this, including me, and I can do
things like 62MB exec arrays:
[EMAIL PROTECTED] linux]$ echo $(find /home/torvalds/) | wc
1 883304
On Thu, Oct 04, 2007 at 12:19:35PM -0700, David Wilder wrote:
> Andi Kleen wrote:
> >"David J. Wilder" <[EMAIL PROTECTED]> writes:
> >>@@ -0,0 +1,160 @@
> >>+Trace Setup and Control
> >>+===
> >>+In the kernel, the trace interface provides a simple mechanism for
> >>+starting
1 - 100 of 902 matches
Mail list logo
