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
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
>
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 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
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
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
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
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
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]>
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,
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(-)
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 +++--
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
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
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;
> >
>
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
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
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):
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
> 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
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:
[] _raw_spin_lock+0x1a/0xd9
[]
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
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
> 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
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
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 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
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
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
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
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
> 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
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:
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
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
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
Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
>
> @@ -1212,10 +1212,10 @@ static int netif_poll(struct net_device
>int pages_flipped = 0;
>int err;
>
> - spin_lock(>rx_lock);
> + spin_lock_bh(>rx_lock);
>
>if (unlikely(!netfront_carrier_ok(np))) {
> -
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
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
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 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
>
> 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
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
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
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
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
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.
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.
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
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
> >
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
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
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
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
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
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
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
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
[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 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
> 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.
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
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
>>
>
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
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 -
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
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
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
> (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
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
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,
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.
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
On Monday April 23, [EMAIL PROTECTED] wrote:
> On Tue, 24 Apr 2007, Neil Brown wrote:
>
> > On Monday April 23, [EMAIL PROTECTED] wrote:
> > > Would this work? Contains a solution somewhat along the lines of your
> > > thoughts on the subject.
> > >
> >
> > Concept seems sound.
> > Code needs
On Tue, 24 Apr 2007, Neil Brown wrote:
> On Monday April 23, [EMAIL PROTECTED] wrote:
> > Would this work? Contains a solution somewhat along the lines of your
> > thoughts on the subject.
> >
>
> Concept seems sound.
> Code needs a kfree of the name returned by create_unique_id, and I
> think
On Mon, 23 Apr 2007, Roland McGrath wrote:
> As I said in some earlier discussion following my original patch, that
> would be fine with me. I haven't coded up that variant, but it's simple
> enough. Would you like to do it?
Sure.
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from
On Monday April 23, [EMAIL PROTECTED] wrote:
> Would this work? Contains a solution somewhat along the lines of your
> thoughts on the subject.
>
Concept seems sound.
Code needs a kfree of the name returned by create_unique_id, and I
think ID_STR_LENGTH needs to be at least 34.
Maybe that
Theodore Tso wrote:
Now, to be fair, there are probably a number of cases where
open/lseek/readv/close and open/lseek/writev/close would be worth doing
as a single system call. The big problem as far as I can see involves
EINTR handling; such a system call has serious restartability
On Mon, 23 Apr 2007 19:32:46 +0100
[EMAIL PROTECTED] (Mel Gorman) wrote:
> > > I wasn't even aware of this kernelcore thing. It's pretty nasty-looking.
> > > yet another reminder that this code hasn't been properly reviewed in the
> > > past year or three.
> >
> > Just now, I'm making
> On Thu, 15 Mar 2007, Roland McGrath wrote:
>
> > This patch makes do_wait return -EPERM instead of -ECHILD if some
> > children were ruled out solely because security_task_wait failed.
>
> What about using the return value from the security_task_wait hook (which
> should be -EACCES) ?
As I
Neil Brown wrote:
Our you could think outside the circle:
Store all your "small files" as symlinks, then use "symlink" to create
them and "readlink" to read them. (You would probably end up use
symlinkat and readlinkat).
Only one system call instead of three.
I guess you don't get meaningful
On Mon, Apr 23, 2007 at 04:53:03PM -0700, H. Peter Anvin wrote:
> Theodore Tso wrote:
> >
> >One of the big problems of using a filesystem as a DB is the system
> >call overheads. If you use huge numbers of tiny files, then each
> >attempt read an atom of information from the DB takes three
On Monday April 23, [EMAIL PROTECTED] wrote:
> Theodore Tso wrote:
> >
> > One of the big problems of using a filesystem as a DB is the system
> > call overheads. If you use huge numbers of tiny files, then each
> > attempt read an atom of information from the DB takes three system
> > calls ---
When we get an SDB FIS with the 'N' bit set, we should send
an event to user space to indicate that there has been a
media change. This will be done via the block device.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
Index: 2.6-git/drivers/ata/ahci.c
Allow user space to determine if a disk supports Asynchronous Notification
of media changes. This is done by adding a new sysfs file "capability_flags",
which is documented in (insert file name). This sysfs file will export all
disk capabilities flags to user space. We also define a new flag to
Give anyone who has access to scsi_device access to the genhd struct as well.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
Index: 2.6-git/drivers/scsi/sd.c
===
--- 2.6-git.orig/drivers/scsi/sd.c
+++
If Asynchronous Notification of media change events is supported,
pass that information up to the SCSI layer.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
Index: 2.6-git/drivers/ata/libata-scsi.c
===
---
This patch series implements Asynchronous Notification (AN) for SATA
ATAPI devices as defined in SATA 2.5 and AHCI 1.1 and higher. Drives
which support this feature will send a notification when new media is
inserted and removed, preventing the need for user space to poll for
new media. This
Get media change notification capability from disk and pass this information
to genhd by setting appropriate flag.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
Index: 2.6-git/drivers/scsi/sr.c
===
---
Send an uevent to user space to indicate that a media change event has occurred.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
Index: 2.6-git/block/genhd.c
===
--- 2.6-git.orig/block/genhd.c
+++ 2.6-git/block/genhd.c
@@
Check to see if an ATAPI device supports Asynchronous Notification.
If so, enable it.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
Index: 2.6-git/drivers/ata/libata-core.c
===
--- 2.6-git.orig/drivers/ata/libata-core.c
Am 22.04.2007 17:17 schrieb Alan Cox:
> Well once it ends up && BROKEN perhaps patches will appear, or before
> that. If not well the pain factor will resolve the problem.
>
>>> No risk of deadlock. It'll progress to && BROKEN which will either cause
>>> sufficient pain for someone to get off
1 - 100 of 881 matches
Mail list logo