On Mon, Apr 23, 2007 at 12:04:01PM -0600, Eric W. Biederman wrote:
Simon Horman [EMAIL PROTECTED] writes:
Update the list information for kexec and kdump
Signed-off-by: Simon Horman [EMAIL PROTECTED]
---
Is it too early for this change?
It looks like the new list is working, and
David Wagner wrote:
James Morris wrote:
[...] you can change the behavior of the application and then bypass
policy entirely by utilizing any mechanism other than direct filesystem
access: IPC, shared memory, Unix domain sockets, local IP networking,
remote networking etc.
I don't know if we've discussed this or not. Since both CFS and SD claim
to be fair, I'd like to hear more opinions on the fairness aspect of
these designs. In areas such as OS, networking, and real-time, fairness,
and its more general form, proportional fairness, are well-defined
terms. In fact,
On Tue, 24 Apr 2007, Neil Brown wrote:
kobject_set_name actually takes a format and arbitrary args and uses
vsnprintf, so it has to make it's own copy.
Ok then this should be fine...
SLAB: Fix sysfs directory handling
This fixes the problem that SLUB does not track the names of aliased
slabs
(text reformatted to less than 80 cols. Please, we'll get along a lot
better if you don't send 1000-column emails)
Sorry. I am afraid we are from a different background, and so very
poorly versed in these things. My email client does not seem
to have an option to tell it to format in 80 cols.
Rik van Riel wrote:
Use TLB batching for MADV_FREE. Adds another 10-15% extra performance
to the MySQL sysbench results on my quad core system.
Signed-off-by: Rik van Riel [EMAIL PROTECTED]
---
Nick Piggin wrote:
3) because of this, we can treat any such accesses as
happening
On Mon, Apr 23, 2007 at 05:31:29PM -0700, H. Peter Anvin wrote:
Heh. sys_read_tree() -- walk a directory tree and return it as a data
structure in memory :)
But maybe you don't want every single file in the directory, but some
subset of the files in the directory tree. So before you know it:
From: Roland McGrath [EMAIL PROTECTED]
wait* syscalls return -ECHILD even when an individual PID of a live child
was requested explicitly, when security_task_wait denies the operation.
This means that something like a broken SELinux policy can produce an
unexpected failure that looks just like a
On Mon, Apr 23, 2007 at 02:56:54PM -0700, Jeremy Fitzhardinge wrote:
Implement a Xen back-end for hvc console.
From: Gerd Hoffmann [EMAIL PROTECTED]
Signed-off-by: Jeremy Fitzhardinge [EMAIL PROTECTED]
---
arch/i386/xen/Kconfig |1
arch/i386/xen/events.c|3 -
Roland McGrath wrote:
+ * It should contain:
+ * hwcap 0 nosegneg
+ * to match the mapping of bit to name that we give here.
This needs to be hwcap 0 nosegneg to match:
+NOTE_KERNELCAP_BEGIN(1, 2)
+NOTE_KERNELCAP(1, nosegneg)
+NOTE_KERNELCAP_END
The actual bits you are
Simon Horman [EMAIL PROTECTED] writes:
On Mon, Apr 23, 2007 at 12:04:01PM -0600, Eric W. Biederman wrote:
Simon Horman [EMAIL PROTECTED] writes:
Update the list information for kexec and kdump
Signed-off-by: Simon Horman [EMAIL PROTECTED]
---
Is it too early for this change?
On Mon, 23 Apr 2007, Amit Gud wrote:
On Mon, 23 Apr 2007, Arjan van de Ven wrote:
The other thing which we should consider is that chunkfs really
requires a 64-bit inode number space, which means either we only allow
does it?
I'd think it needs a chunk space number and a 32 bit local
The only reason for using threads here is to get the error recovery
out of an interrupt context (where errors may be detected), and then,
an hour later, decrement a counter (which is how we limit these to
6 per hour). Thread reaping is trivial, the thread just exits
after an hour.
In
On Mon, Apr 23, 2007 at 02:57:00PM -0700, Jeremy Fitzhardinge wrote:
Netfront's use of nh.raw and h.raw for storing page+offset is a bit
hinky, and it breaks with upcoming network stack updates which reduce
these fields to sub-pointer sizes. Fortunately, skb offers the cb
field specifically
[1] Summary:
Kernel Reports Oops: 0002 [1] SMP and the system becomes unstable
[2] Full Description:
Sometimes, randomly i get this Oops message and the system becomes
unstable. By unstable i mean all applications segmentation faults when i
execute (after the Oops). Sometimes X crashes,
On Monday 23 April 2007, Niel Lambrechts wrote:
Gene Heskett wrote:
This message prompted me to do some checking in re context switches
myself, and I've come to the conclusion that there could be a bug in
vmstat itself.
Perhaps. perhaps not. :)
Run singly the context switching is reasonable
At 22:42 07/04/23, Hugh Dickins wrote:
On Mon, 23 Apr 2007, Hisashi Hifumi wrote:
No. The PG_lru flag bit is just one bit amongst many others:
what of concurrent operations changing other bits in that same
unsigned long e.g. trying to lock the page by setting PG_locked?
There are some
This should fix the MADV_FREE code for PPC's hashed tlb.
Signed-off-by: Rik van Riel [EMAIL PROTECTED]
---
Nick Piggin wrote:
Nick Piggin wrote:
3) because of this, we can treat any such accesses as
happening simultaneously with the MADV_FREE and
as illegal, aka undefined behaviour
On Mon, Apr 23, 2007 at 05:59:06PM -0700, Li, Tong N wrote:
I don't know if we've discussed this or not. Since both CFS and SD claim
to be fair, I'd like to hear more opinions on the fairness aspect of
these designs. In areas such as OS, networking, and real-time, fairness,
and its more
Crispin Cowan wrote:
David Wagner wrote:
James Morris wrote:
[...] you can change the behavior of the application and then bypass
policy entirely by utilizing any mechanism other than direct filesystem
access: IPC, shared memory, Unix domain sockets, local IP networking,
remote
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
The only reason for using threads here is to get the error recovery
out of an interrupt context (where errors may be detected), and then,
an hour later, decrement a counter (which is how we limit these to
6 per hour). Thread reaping is
Rik van Riel wrote:
This should fix the MADV_FREE code for PPC's hashed tlb.
Signed-off-by: Rik van Riel [EMAIL PROTECTED]
---
Nick Piggin wrote:
Nick Piggin wrote:
3) because of this, we can treat any such accesses as
happening simultaneously with the MADV_FREE and
as illegal, aka
On 4/24/07, Christoph Lameter [EMAIL PROTECTED] wrote:
There are a series of open coded reimplementation of memclear_highpage_flush
all over the page cache code. Call memclear_highpage_flush in those locations.
Consolidates code and eases maintenance.
If I remember right, a very similar
On Tue, 24 Apr 2007 07:49:45 +0530 Satyam Sharma [EMAIL PROTECTED] wrote:
On 4/24/07, Christoph Lameter [EMAIL PROTECTED] wrote:
There are a series of open coded reimplementation of memclear_highpage_flush
all over the page cache code. Call memclear_highpage_flush in those
locations.
On Tue, 24 Apr 2007, Satyam Sharma wrote:
On 4/24/07, Christoph Lameter [EMAIL PROTECTED] wrote:
There are a series of open coded reimplementation of memclear_highpage_flush
all over the page cache code. Call memclear_highpage_flush in those
locations.
Consolidates code and eases
On Tue, 24 Apr 2007 10:54:27 +0900
Hisashi Hifumi [EMAIL PROTECTED] wrote:
In the case that changing the same bit concurrently, lock prefix or other
spinlock is needed. But, I think that concurrent bit operation on different
bits
is just like OR operation , so lock prefix is not needed.
Hi Matt,
On 4/24/07, Matt Ranon [EMAIL PROTECTED] wrote:
The obvious question is: what's _wrong_ with doing all this in some
cut-down userspace environment like busybox? Why is this stuff better?
Obviously some embedded developers have considered that option and
have rejected it. But we
On Mon, 2007-04-23 at 20:08 -0600, Eric W. Biederman wrote:
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
The only reason for using threads here is to get the error recovery
out of an interrupt context (where errors may be detected), and then,
an hour later, decrement a counter (which
On Fri, 13 Apr 2007 11:31:16 +0400 Oleg Nesterov [EMAIL PROTECTED] wrote:
On top of Eric's
kthread-dont-depend-on-work-queues-take-2.patch
Currently kernel threads use sigprocmask(SIG_BLOCK) to protect against
signals.
This doesn't prevent the signal delivery, this only blocks
Hisashi Hifumi wrote:
At 22:42 07/04/23, Hugh Dickins wrote:
On Mon, 23 Apr 2007, Hisashi Hifumi wrote:
No. The PG_lru flag bit is just one bit amongst many others:
what of concurrent operations changing other bits in that same
unsigned long e.g. trying to lock the page by setting
Nick Piggin wrote:
What the tlb flush used to be able to assume is that the page
has been removed from the pagetables when they are put in the
tlb flush batch.
I think this is still the case, to a degree. There should be
no harm in removing the TLB entries after the page table has
been
On 4/24/07, Christoph Lameter [EMAIL PROTECTED] wrote:
On Tue, 24 Apr 2007, Satyam Sharma wrote:
If I remember right, a very similar patchset was recently submitted
that Andrew merged in -mm(?). It also renamed memclear_highpage_flush
to something like zero_user_page (though I wonder how good
I am not in any way argue that your driver architecture is wrong or that you
should change anything. My point was simple. [tifm_sd] can only work with
[tifm_7xx1]. If you add support for let's say [tifm_8xx2] in the future, which
would have port offsets different that [tifm_7xx1], you would
On Friday April 20, [EMAIL PROTECTED] wrote:
Scale writeback cache per backing device, proportional to its writeout speed.
So it works like this:
We account for writeout in full pages.
When a page has the Writeback flag cleared, we account that as a
successfully retired write for the
On Mon, 23 Apr 2007 22:53:49 -0400 Rik van Riel [EMAIL PROTECTED] wrote:
I don't see why we need the attached, but in case you find
a good reason, here's my signed-off-by line for Andrew :)
Andew is in a defensive crouch trying to work his way through all the bugs
he's been sent. After I've
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
Not sure... I can see places where I might want to spawn an arbitrary
number of these without having to preallocate structures... and if I
allocate on the fly, then I need a way to free that structure when the
kthread is reaped which I don't
Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
@@ -1212,10 +1212,10 @@ static int netif_poll(struct net_device
int pages_flipped = 0;
int err;
- spin_lock(np-rx_lock);
+ spin_lock_bh(np-rx_lock);
if (unlikely(!netfront_carrier_ok(np))) {
-
Jiri Kosina [EMAIL PROTECTED] wrote:
Hmm, *sigh*. I guess the patch below fixes the problem, but it is a
masterpiece in the field of ugliness. And I am not sure whether it is
completely correct either. Are there any immediate ideas for better
solution with respect to how struct sock
Linus Torvalds wrote:
On Mon, 23 Apr 2007, Ingo Molnar wrote:
The give scheduler money transaction can be both an implicit
transaction (for example when writing to UNIX domain sockets or
blocking on a pipe, etc.), or it could be an explicit transaction:
sched_yield_to(). This latter i've
On Sat, 2007-04-21 at 11:48 +0200, Andi Kleen wrote:
Lots of people want kgdb. One person is famously less keen on it, but
we'll be able to talk him around, as long as the patches aren't daft.
The big question is if the kgdb developers seriously want mainline.
At least in the past this
This bug occurs in linux-2.6.20 and 2.6.21-rc7-git5, and does not occur in
linux-2.6.19-git22.
After running pktsetup 0 /dev/hdd, I get (timestamps removed):
pktcdvd: pkt_get_last_written failed
BUG: unable to handle kernel NULL pointer dereference at virtual address
000e
printing eip:
I have to admit I still don't really understand all this. Is it
documented somewhere?
I have explained it in public more than once, but I don't know off hand
anywhere that was helpfully recorded.
What does hwcap 0 nosegneg actually mean? What does the 0 mean here?
ldconfig is usually run
Not having tested it or anything, that looks good to me.
Thanks,
Roland
-
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
Herbert Xu wrote:
Thanks Jeremy. The patch looks good.
Could you give netfront an overall review as well? I know you're
already pretty familiar with it, but if you could cast a fresh eye over
it, that would be helpful.
Thanks,
J
-
To unsubscribe from this list: send the line unsubscribe
Eric W. Biederman writes:
Well the basic problem is that for any piece of code that can be modular
we need a way to ensure all threads it has running are shutdown when we
remove the module.
The EEH code can't be modular, and wouldn't make any sense to be
modular, since it's part of the
oom_kill_task() calls __oom_kill_task() to OOM kill a selected task.
When finding other threads that share an mm with that task, we need to
kill those individual threads and not the same one.
Cc: Andi Kleen [EMAIL PROTECTED]
Cc: Christoph Lameter [EMAIL PROTECTED]
Signed-off-by: David Rientjes
On Mon, 2007-04-23 at 17:55 -0400, Bill Davidsen wrote:
Based on just this script as load I would say renice on X isn't a good
thing. Based on one small test, I would say that renice of X in
conjunction with heavy disk i/o and a single fast scrolling xterm (think
kernel compile) seems to
Herbert Xu wrote:
You don't need to disable BH in netif_poll since it's always called
with BH disabled.
Ah, yes, you mentioned that before. I'll fix it up.
J
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
David Miller wrote:
From: voron [EMAIL PROTECTED]
Date: Tue, 24 Apr 2007 00:13:27 +0300
As I see, nonblocking mode is enabled - sendfile sends less than asked.
The socket is marked as non-blocking, but the disk I/O is not.
It's blocking on the disk I/O not the socket part of the
Rik van Riel writes:
I guess we'll need to call tlb_remove_tlb_entry() inside the
MADV_FREE code to keep powerpc happy.
I don't see why; once ptep_test_and_clear_young has returned, the
entry in the hash table has already been removed. Adding the
tlb_remove_tlb_entry call certainly won't do
On Monday 23 April 2007, Paul Sokolovsky wrote:
Hello David,
Thursday, April 19, 2007, 5:22:44 AM, you wrote:
So, talking about what an (optional) implementation framework might
look like (and which could handle the SOC, FPGA, I2C, and MFD cases
I've looked at):
See patches
Paul Mackerras [EMAIL PROTECTED] writes:
Eric W. Biederman writes:
Well the basic problem is that for any piece of code that can be modular
we need a way to ensure all threads it has running are shutdown when we
remove the module.
The EEH code can't be modular, and wouldn't make any sense
Within reason, it's not the number of clients that X has that causes its
CPU bandwidth use to sky rocket and cause problems. It's more to to
with what type of clients they are. Most GUIs (even ones that are
constantly updating visual data (e.g. gkrellm -- I can open quite a
large
David Schwartz пишет:
You have a misunderstanding about the semantics of 'sendfile'. The 'sendfile'
function is just a more efficient version of a read followed by a write. If you
did a read followed by a write, it would block as well (in the read).
DS
sendfile function is not just a more
Further in general it doesn't make sense to grab a module reference
and call that sufficient because we would like to request that the
module exits.
Which is, btw, I think a total misdesign of our module stuff, but heh, I
remember that lead to some flamewars back then...
Like anything else,
Ian Kirk wrote:
Hi,
I just wondered if the below type of crash was a known thing, and if
there are any obvious things I can do to prevent/fix it ?
BUG: spinlock bad magic on CPU#0, kswapd0/242 (Not tainted)
lock: c06c9380, .magic: c06c9380, .owner:
[c06eba2a] _raw_spin_lock+0x1a/0xd9
Madhusudhan c wrote:
Suppose a host controller is capable of suporting 8-bit and it tells
the core that it can support 8-bit. Now the card that is plugged in
might or might not support 8-bit based on the type of the card. There
is no field in the ext_csd which will tell you what bus width
On Mon, 23 Apr 2007, Andrew Morton wrote:
On Tue, 24 Apr 2007 04:09:18 + (GMT) William Heimbigner [EMAIL PROTECTED]
wrote:
This bug occurs in linux-2.6.20 and 2.6.21-rc7-git5, and does not occur in
linux-2.6.19-git22.
After running pktsetup 0 /dev/hdd, I get (timestamps removed):
Paul Mackerras wrote:
Rik van Riel writes:
I guess we'll need to call tlb_remove_tlb_entry() inside the
MADV_FREE code to keep powerpc happy.
I don't see why; once ptep_test_and_clear_young has returned, the
entry in the hash table has already been removed.
OK, so this one won't be
I tested this patch. It worked well.
So, I fixed its description.
Please apply.
--
The current panic_on_oom may not work if there is a process using
cpusets/mempolicy, because other nodes' memory may remain.
But some people want failover by panic ASAP even if they are used.
This
On Tue, 24 Apr 2007 05:10:04 + (GMT) William Heimbigner [EMAIL PROTECTED]
wrote:
--- a/drivers/block/pktcdvd.c~packet-fix-error-handling
+++ a/drivers/block/pktcdvd.c
@@ -777,7 +777,8 @@ static int pkt_generic_packet(struct pkt
rq-cmd_flags |= REQ_QUIET;
This is a first step as there are still cleanups to be done in various
areas touched by that code but I think it's probably good to go as is and
at least enables me to implement what I need for PowerPC.
(Andrew, this is also candidate for 2.6.22 since I haven't had any real
objection, mostly
Handle MAP_FIXED in powerpc's arch_get_unmapped_area() in all 3
implementations of it.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Acked-by: William Irwin [EMAIL PROTECTED]
arch/powerpc/mm/hugetlbpage.c | 21 +
1 file changed, 21 insertions(+)
Index:
Handle MAP_FIXED in alpha's arch_get_unmapped_area(), simple case, just
return the address as passed in
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
arch/alpha/kernel/osf_sys.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-cell/arch/alpha/kernel/osf_sys.c
ARM already had a case for MAP_FIXED in arch_get_unmapped_area() though
it was not called before. Fix the comment to reflect that it will now
be called.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
arch/arm/mm/mmap.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Index:
generic arch_get_unmapped_area() now handles MAP_FIXED. Now that
all implementations have been fixed, change the toplevel
get_unmapped_area() to call into arch or drivers for the MAP_FIXED
case.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
mm/mmap.c | 25 +++--
Generic hugetlb_get_unmapped_area() now handles MAP_FIXED by just
calling prepare_hugepage_range()
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Acked-by: William Irwin [EMAIL PROTECTED]
fs/hugetlbfs/inode.c |6 ++
1 file changed, 6 insertions(+)
Index:
Remove the hugetlbfs specific hacks in toplevel get_unmapped_area() now
that all archs and hugetlbfs itself do the right thing for both cases.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Acked-by: William Irwin [EMAIL PROTECTED]
mm/mmap.c | 16
1 file changed, 16
Handle MAP_FIXED in x86_64 arch_get_unmapped_area(), simple case, just
return the address as passed in
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
arch/x86_64/kernel/sys_x86_64.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-cell/arch/x86_64/kernel/sys_x86_64.c
Handle MAP_FIXED in hugetlb_get_unmapped_area on sparc64
by just using prepare_hugepage_range()
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Acked-by: William Irwin [EMAIL PROTECTED]
arch/sparc64/mm/hugetlbpage.c |6 ++
1 file changed, 6 insertions(+)
Index:
Handle MAP_FIXED in parisc arch_get_unmapped_area(), just return the
address. We might want to also check for possible cache aliasing
issues now that we get called in that case (like ARM or MIPS),
leave a comment for the maintainers to pick up.
Signed-off-by: Benjamin Herrenschmidt [EMAIL
Handle MAP_FIXED in ia64 arch_get_unmapped_area and
hugetlb_get_unmapped_area(), just call prepare_hugepage_range
in the later and is_hugepage_only_range() in the former.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Acked-by: William Irwin [EMAIL PROTECTED]
Handle MAP_FIXED in i386 hugetlb_get_unmapped_area(), just call
prepare_hugepage_range.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Acked-by: William Irwin [EMAIL PROTECTED]
arch/i386/mm/hugetlbpage.c |6 ++
1 file changed, 6 insertions(+)
Index:
Handle MAP_FIXED in arch_get_unmapped_area on frv. Trivial case, just
return the address.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
arch/frv/mm/elf-fdpic.c |4
1 file changed, 4 insertions(+)
Index: linux-cell/arch/frv/mm/elf-fdpic.c
On Mon, 23 Apr 2007, Andrew Morton wrote:
On Tue, 24 Apr 2007 05:10:04 + (GMT) William Heimbigner [EMAIL PROTECTED]
wrote:
--- a/drivers/block/pktcdvd.c~packet-fix-error-handling
+++ a/drivers/block/pktcdvd.c
@@ -777,7 +777,8 @@ static int pkt_generic_packet(struct pkt
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
Further in general it doesn't make sense to grab a module reference
and call that sufficient because we would like to request that the
module exits.
Which is, btw, I think a total misdesign of our module stuff, but heh, I
remember that lead
On Mon, Apr 23, 2007 at 09:36:13PM -0700, David Rientjes wrote:
oom_kill_task() calls __oom_kill_task() to OOM kill a selected task.
When finding other threads that share an mm with that task, we need to
kill those individual threads and not the same one.
ISTR shooting down something of this
On Mon, 23 Apr 2007, David Rientjes wrote:
oom_kill_task() calls __oom_kill_task() to OOM kill a selected task.
When finding other threads that share an mm with that task, we need to
kill those individual threads and not the same one.
Obvious fix. It was broken by
From: Alan Cox [EMAIL PROTECTED]
Date: Mon, 23 Apr 2007 14:58:40 +0100
Signed-off-by: Alan Cox [EMAIL PROTECTED]
Applied, thanks Alan.
-
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 Tue, 24 Apr 2007 05:44:42 + (GMT) William Heimbigner [EMAIL PROTECTED]
wrote:
On Mon, 23 Apr 2007, Andrew Morton wrote:
On Tue, 24 Apr 2007 05:10:04 + (GMT) William Heimbigner [EMAIL
PROTECTED] wrote:
--- a/drivers/block/pktcdvd.c~packet-fix-error-handling
+++
On Mon, Apr 23, 2007 at 09:34:55PM -0700, Jeremy Fitzhardinge wrote:
Could you give netfront an overall review as well? I know you're
already pretty familiar with it, but if you could cast a fresh eye over
it, that would be helpful.
Sure thing. I'll look over it soon.
Actually there is
801 - 881 of 881 matches
Mail list logo
