Oleg Nesterov [EMAIL PROTECTED] writes:
On 12/09, Eric W. Biederman wrote:
Equally messed up is a our status in /proc at that point. Which
says our sleeping process is a zombie.
Yes, this is annoying.
I'm thinking we need to do at least some of the thread group leadership
transfer
Oleg Nesterov [EMAIL PROTECTED] writes:
do_wait(WSTOPPED) assumes that p-state must be == TASK_STOPPED, this is not
true if the leader is already dead. Check SIGNAL_STOP_STOPPED instead and use
-signal-group_exit_code.
This patch is not complete if not buggy. At the very minimum it needs
Neil Horman [EMAIL PROTECTED] writes:
On Fri, Dec 07, 2007 at 09:21:44AM -0500, Neil Horman wrote:
On Fri, Dec 07, 2007 at 01:22:04AM -0800, Yinghai Lu wrote:
On Dec 7, 2007 12:50 AM, Yinghai Lu [EMAIL PROTECTED] wrote:
On Dec 6, 2007 4:33 PM, Eric W. Biederman [EMAIL PROTECTED] wrote
Sorry to reply to myself, but do we have consensus on this patch? I'd like to
figure out its disposition if possible.
What the patch tries to do looks like the right thing. So if we can get
a version that is clean and actually works we should merge it.
Eric
--
To unsubscribe from this
Oleg Nesterov [EMAIL PROTECTED] writes:
On 12/09, Eric W. Biederman wrote:
Oleg below is my proof of concept patch, which really needs to be
broken up into a whole patch series, so the changes are small
enough we can do a thorough audit on them. Anyway take a look
and see what you think
Huang, Ying [EMAIL PROTECTED] writes:
This patch implements the functionality of jumping between the kexeced
kernel and the original kernel.
To support jumping between two kernels, before jumping to (executing)
the new kernel and jumping back to the original kernel, the devices
are put into
Neil Horman [EMAIL PROTECTED] writes:
Almost there.
On Mon, Dec 10, 2007 at 06:08:03PM -0700, Eric W. Biederman wrote:
Neil Horman [EMAIL PROTECTED] writes:
snip
Ok. This test is broken. Please remove the == 1. You are looking
for == (1 18). So just saying: if (htcfg (1 18
Huang, Ying [EMAIL PROTECTED] writes:
On Mon, 2007-12-10 at 19:25 -0700, Eric W. Biederman wrote:
Huang, Ying [EMAIL PROTECTED] writes:
[...]
/*
* Do not allocate memory (or fail in any way) in machine_kexec().
* We are past the point of no return, committed to rebooting now
Neil Horman [EMAIL PROTECTED] writes:
On Mon, Dec 10, 2007 at 09:48:11PM -0700, Eric W. Biederman wrote:
Neil Horman [EMAIL PROTECTED] writes:
Almost there.
cool! :)
snip
We should not need check_hypertransport_config as the generic loop
now does the work for us.
+
static void
Neil Horman [EMAIL PROTECTED] writes:
On Tue, Dec 11, 2007 at 08:29:20AM -0700, Eric W. Biederman wrote:
Neil Horman [EMAIL PROTECTED] writes:
On Mon, Dec 10, 2007 at 09:48:11PM -0700, Eric W. Biederman wrote:
Neil Horman [EMAIL PROTECTED] writes:
Ok. I just looked at read_pci_config
normally.
Regards
Neil
Signed-off-by: Neil Horman [EMAIL PROTECTED]
Acked-by: Eric W. Biederman [EMAIL PROTECTED]
Eric
--
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
Andi Kleen [EMAIL PROTECTED] writes:
It could enable the extended APIC IDs but not use them?
In which case complaining is still correct (the BIOS was out of sync),
enabling bit 17 is still correct and we are just in overkill mode.
Anyways I haven't got docs on that NV bridge so I might be
Neil Horman [EMAIL PROTECTED] writes:
I think this just leaves us with deciding on a mechanism for how to do
single-application quirks. I take Andi's point that adding a flag set to the
quirk data structure is a fine solution, but I'm really ok with static
integers
in individual functions.
Greg KH [EMAIL PROTECTED] writes:
On Wed, Dec 12, 2007 at 11:05:45AM -0800, H. Peter Anvin wrote:
Greg KH wrote:
This is a binary structure defined by protocol;
What protocol? Is this a standard documented somewhere?
Yes, see Documentation/i386/* (although some of it is documented by
Randy Dunlap [EMAIL PROTECTED] writes:
I don't know if this patch is trying to solve this (-) problem, but there
is a desire for drivers to have a decent way to tell if the kernel that
is executing is a kexec/crash kernel or not. If it is a kexec/crash
kernel, then (some) drivers may not
support is selected
so we at least know we have a conflict.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
lib/Kconfig.debug |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index cc42773..c8e81e6 100644
--- a/lib/Kconfig.debug
Ingo Molnar [EMAIL PROTECTED] writes:
* Eric W. Biederman [EMAIL PROTECTED] wrote:
/proc/timer_stats currently reports the user of a timer by pid, which
is a reasonable approach. However if you are not in the initial pid
namespace the pid that is reported is nonsense.
Therefore until
Ingo Molnar [EMAIL PROTECTED] writes:
* Eric W. Biederman [EMAIL PROTECTED] wrote:
What the heck??? Please solve this properly instead of hiding it.
/proc/timer_stats is damn useful and it's a must-have for powertop
to work.
Hmm. Perhaps the dependency conflict should go
Ingo Molnar [EMAIL PROTECTED] writes:
* Eric W. Biederman [EMAIL PROTECTED] wrote:
the problem is, this interface stores historic PIDs too - i.e. PIDs
of tasks that might have exited already.
Well struct pid * works in that case if you grab the reference to it.
but the display
Ingo Molnar [EMAIL PROTECTED] writes:
* Eric W. Biederman [EMAIL PROTECTED] wrote:
Well struct pid * works in that case if you grab the reference to
it.
but the display of the stats might happen much later. The point of
this API is to save pid+comm, which gives users a good idea
[EMAIL PROTECTED] writes:
Originally based on a patch from Eric Biederman, but heavily changed.
Forward port of pat-base.patch to x86 tree, with a bug fix.
Code was using 'PCD|PWT' i.e., PAT3 for WC mapping. So set the WC mapping at
correct PAT fields PA3/PA7.
Well that wasn't from my
[EMAIL PROTECTED] writes:
Forward port of coherent-mmap.patch and sysfs-bin-ioctl.patch to x86 tree.
TBD: Do we need the ioctl interface to sysfs or get the type attribute
through a different sysfs file. And then actually specify the attribute
while doing pci_mmap_page_range ;-)
This ioctl
[EMAIL PROTECTED] (Eric W. Biederman) writes:
We should use:
+pat = PAT(0,WB) | PAT(1,WT) | PAT(2,WC) | PAT(3,UC) |
+ PAT(4,WB) | PAT(5,WT) | PAT(6,WC) | PAT(7,UC);
Changing the UC- which currently allows write-combining if the MTRRs specify
it,
to WC
Roland Dreier [EMAIL PROTECTED] writes:
Also I didn't see anything like pgprot_wc() in the patchset (although
pgprot_writcombined.
Oh I see it now (pgprot_writecombine() actually).
However the same comment as before applies: there needs to be a
fallback to pgprot_noncached() for all
Roland Dreier [EMAIL PROTECTED] writes:
--- linux-2.6.24-rc4.orig/include/asm-x86/io_64.h 2007-12-11
14:24:56.0 -0800
+++ linux-2.6.24-rc4/include/asm-x86/io_64.h 2007-12-11 15:49:52.0
-0800
@@ -142,7 +142,8 @@
* it's useful if some control registers are in such an
Greg KH [EMAIL PROTECTED] writes:
On Thu, Dec 13, 2007 at 08:59:44PM -0700, Eric W. Biederman wrote:
[EMAIL PROTECTED] writes:
Forward port of coherent-mmap.patch and sysfs-bin-ioctl.patch to x86 tree.
TBD: Do we need the ioctl interface to sysfs or get the type attribute
through
Ingo Molnar [EMAIL PROTECTED] writes:
Eric,
you added these warnings, right?
Yes, and the particular warning that is triggering this is
the first time I have seen it. I didn't know we had any
sysctl users that were buggy in attempting to create the
same file twice.
This sounds like we have
Frans Pop [EMAIL PROTECTED] writes:
On Sunday 06 January 2008, Eric W. Biederman wrote:
Short of two programs coming in and simultaneously trying to claim
the parallel port and there being not exclusion in ppdev.c I don't
have a clue what could cause the reported error.
That could well
Hiroshi Shimamoto [EMAIL PROTECTED] writes:
Do we really have to introduce this function for 64bit? I remember some
issues were faced on i386 w.r.t kernel enabling the LAPIC against the
wishes of BIOS hence kernel was disabling it while shutting down. No
such problems were reported for x86_64
Thomas Gleixner [EMAIL PROTECTED] writes:
On Thu, 25 Oct 2007, Huang, Ying wrote:
This patch adds basic runtime services support for EFI x86_64
system. The main file of the patch is the addition of efi.c for
x86_64. This file is modeled after the EFI IA32 avatar.
modeled means copied and
Huang, Ying [EMAIL PROTECTED] writes:
+static void __init efi_call_phys_prelog(void) __acquires(efi_lock)
+{
+ unsigned long vaddress;
+
+ /*
+ * Lock sequence is different from normal case because
+ * efi_flags is global
+ */
+ spin_lock(efi_lock);
+
Arjan van de Ven [EMAIL PROTECTED] writes:
On Thu, 25 Oct 2007 10:55:44 -0600
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
I don't think there is a compelling case for us to use any efi
services at this time
I would almost agree with this if it wasn't for the 1 call that OS
installers
H. Peter Anvin [EMAIL PROTECTED] writes:
Andi Kleen wrote:
Especially for accessing the real time clock that has a well
defined hardware interface going through efi an additional
software emulation layer looks like asking for trouble.
I agree it's pointless for the hardware clock, but EFI
H. Peter Anvin [EMAIL PROTECTED] writes:
Arjan van de Ven wrote:
On Thu, 25 Oct 2007 10:55:44 -0600
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
I don't think there is a compelling case for us to use any efi
services at this time
I would almost agree with this if it wasn't for the 1 call
H. Peter Anvin [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Well, the original motivation for all of this was to enable implementation
of
a
EFI framebuffer (UGA/GOP). Now, you can say what you want about EFI (and I
definitely have my opinion on it), but that seems legitimate to me
H. Peter Anvin [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Ying claimed that GOP requires EFI runtime services. Is that not true?
None of the EFI framebuffer patches that I saw used EFI runtime services.
Ying, could you please clarify this situation?
(Eric: do note
bootloaders that could use this functionality.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
Cc: Jeremy Fitzhardinge [EMAIL PROTECTED]
Cc: Rusty Russell [EMAIL PROTECTED]
Cc: H. Peter Anvin [EMAIL PROTECTED]
Cc: Vivek Goyal [EMAIL PROTECTED]
Cc: James Bottomley [EMAIL PROTECTED]
Cc: Zachary Amsden
.
Heavy weight but it is simple and should work.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
fs/proc/generic.c | 38 +-
fs/proc/internal.h |2 ++
fs/proc/root.c |2 +-
3 files changed, 24 insertions(+), 18 deletions(-)
diff --git a/fs
H. Peter Anvin [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Both x86 and x86_64 support the same boot protocol so we need
to implement the KEEP_SEGMENTS on x86_64 as well. It isn't
just paravirt bootloaders that could use this functionality.
Out of curiousity, what other users do
Linus Torvalds [EMAIL PROTECTED] writes:
On Fri, 26 Oct 2007, Eric W. Biederman wrote:
It appears we overlooked support for removing generic proc files
when we added support for multiple proc super blocks. Handle
that now.
There seems to be more users of proc_mnt out
the flushing of the thread directories.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
fs/proc/base.c | 15 ++-
1 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index aeaf0d0..a17c268 100644
--- a/fs/proc/base.c
+++ b/fs/proc
of fixing any ABI or other bugs
we find as long as they are minor.
Allowing users of the kernel to avoid those bugs simply
by ensuring their kernel does not have support for multiple
pid namespaces.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
include/linux/pid_namespace.h | 22
This patch implements task_in_pid_ns and uses it to limit cap_set_all
and sys_kill(-1,) to only those tasks in the current pid namespace.
Without this we have a setup for a very nasty surprise.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
include/linux/pid_namespace.h |2
Kir Kolyshkin [EMAIL PROTECTED] writes:
Eric,
Could you please hold off the horses a bit and wait till Pavel Emelyanov
returns? It means next Monday; he's currently at a conference whose organisers
don't provide internet access.
When we decided to go top down (i.e. user interface first)
Kir Kolyshkin [EMAIL PROTECTED] writes:
Eric, this problem is a known one. Currently Pavel and Sukadev are working on
a
appropriate signal management for namespaces.
I'm fairly certain that the signal issue you they are dealing with
is how to keep children from killing the init of a pid
Kir Kolyshkin [EMAIL PROTECTED] writes:
Speaking of this particular patch -- I don't understand how you fix
innumerable little bugs by providing stubs instead of real functions.
I think it would be a disaster to use pid namespaces as currently
implemented 2.6.24-rc1 in a production
#ifdef sounds good to me.
Acked-by: Eric W. Biederman [EMAIL PROTECTED]
-- snip --
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
22ea6cd56e4fa844b0b1bbab2542f09eb6c9a5ab
diff --git a/net/core/sock.c b/net/core/sock.c
index febbcbc..ee1cc4f 100644
--- a/net/core/sock.c
+++ b/net/core
David Miller [EMAIL PROTECTED] writes:
From: Rick Jones [EMAIL PROTECTED]
Date: Fri, 26 Oct 2007 16:31:47 -0700
Eric W. Biederman wrote:
Adrian Bunk [EMAIL PROTECTED] writes:
This patch fixes the following build error with CONFIG_SYSCTL=n:
-- snip --
...
ERROR
Adrian Bunk [EMAIL PROTECTED] writes:
CONFIG_EXPERIMENTAL is a weak hint that some code might not (yet) be in
a perfect state, but it does not have any semantics regarding
userspace ABIs.
Code that might not (yet) be in a perfect state sums it up pretty
well. There is not plan or
Andrew Morton [EMAIL PROTECTED] writes:
On Sat, 27 Oct 2007 04:04:08 +0200 Adrian Bunk [EMAIL PROTECTED] wrote:
be happy to hear if someone has a better idea.
There is a difference between complete the feature and early adopters
to start playing with the feature on the one side, and
Adrian Bunk [EMAIL PROTECTED] writes:
There isn't any hard semantics behind what is marked EXPERIMENTAL and
what not. In it's current state, we could even consider removing the
EXPERIMENTAL option and all dependencies on EXPERIMENTAL.
Well I do know at least some of the things that depend
Jeff Garzik [EMAIL PROTECTED] writes:
Arjan van de Ven wrote:
On Fri, 26 Oct 2007 20:37:47 -0400
Jeff Garzik [EMAIL PROTECTED] wrote:
Arjan van de Ven wrote:
the other serious question is.. how is IRQ_HANDLER_V3 different
from a #ifdef VERSION = 2.6.24 .
it's not really ;)
Note my
Andrew Morton [EMAIL PROTECTED] writes:
Given that a lot of this development will hopefully happen over the next
two months, ...
A lot. Various pieces are a major effort in their own right.
Improving the kthread API so it can be used universally and
allow removal all of the kernel_thread
Dobriyan [EMAIL PROTECTED]
Acked-by: Eric W. Biederman [EMAIL PROTECTED]
For ambiguous cases like directories this looks like a serious
help.
-
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
Adrian Bunk [EMAIL PROTECTED] writes:
On Sun, Oct 28, 2007 at 09:12:34AM -0700, Jeremy Fitzhardinge wrote:
Eric W. Biederman wrote:
Roughly that sounds like CONFIG_EXPERIMENTAL to me. But I would
be happy to hear if someone has a better idea.
Rather than overload an existing config
Randy Dunlap [EMAIL PROTECTED] writes:
From: Randy Dunlap [EMAIL PROTECTED]
cc: Eric W. Biederman [EMAIL PROTECTED]
Correct the token-ring sysctl procname.
Reported by: Daniel Exner [EMAIL PROTECTED]:
Ah, and token ring tells me something like
/net/token-ring ,3.14 sysctl failed check
Kirill Korotaev [EMAIL PROTECTED] writes:
I dislike this patch:
it's not scalable/efficient to travers all the tasks
while we know the pid namespace we care about.
Well the unix way is to implement it simple and stupid and then to
optimize, where needed. We don't currently have a per pid
Dave Hansen [EMAIL PROTECTED] writes:
On Fri, 2007-10-26 at 14:37 -0600, Eric W. Biederman wrote:
+static int pid_in_pid_ns(struct pid *pid, struct pid_namespace *ns)
+{
+ return pid (ns-level = pid-level)
+ pid-numbers[ns-level].ns == ns;
+}
Could we blow this out
Cedric Le Goater [EMAIL PROTECTED] writes:
Pavel also has a CONFIG_NAMESPACES patch that he should be resending to
andrew when 2.6.24-rc1-mm1 is released. pidns will go under this option,
like all the other namespaces, and should protect the distros from shipping
any immature namespace.
Kirill Korotaev [EMAIL PROTECTED] writes:
Can you please send namespace related patches to containers@ ML first
before sending them to Linus/Andrew?
If you are so anxious to review my patches can you please review them?
I'd love to see an acked-by or an actual bug found.
I only did what I
Cedric Le Goater [EMAIL PROTECTED] writes:
The outstanding issues I can think of off the top of my head:
- signal handling for init on secondary pid namespaces.
- Properly setting si_pid on signals that cross namespaces.
these are being addressed by suka patches, and also you with the latest
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
Bug is in the new dev_ifname32:
uifr = compat_alloc_user_space(sizeof(struct ifreq));
if (copy_in_user(uifr, compat_ptr(arg), sizeof(struct ifreq32)));
return -EFAULT;
There's a stray ; after the if statement, that
Christian Borntraeger [EMAIL PROTECTED] writes:
Eric,
Am Dienstag, 16. Oktober 2007 schrieb Christian Borntraeger:
Am Dienstag, 16. Oktober 2007 schrieb Eric W. Biederman:
fs/buffer.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
drivers/block/rd.c | 13
Nick Piggin [EMAIL PROTECTED] writes:
On Wednesday 17 October 2007 20:30, Eric W. Biederman wrote:
Nick Piggin [EMAIL PROTECTED] writes:
On Tuesday 16 October 2007 18:08, Nick Piggin wrote:
On Tuesday 16 October 2007 14:57, Eric W. Biederman wrote:
What magic restrictions on page
Chris Mason [EMAIL PROTECTED] writes:
In this case, the commit block isn't allowed to be dirty before reiserfs
decides it is safe to write it. The journal code expects it is the only
spot in the kernel setting buffer heads dirty, and it only does so after
the rest of the log blocks are
Chris Mason [EMAIL PROTECTED] writes:
Thinking about it. I don't believe anyone has ever intentionally built
a filesystem tool that depends on being able to modify a file systems
metadata buffer heads while the filesystem is running, and doing that
would seem to be fragile as it would
Christian Borntraeger [EMAIL PROTECTED] writes:
Am Mittwoch, 17. Oktober 2007 schrieb Eric W. Biederman:
Did you have both of my changes applied?
To init_page_buffer() and to the ramdisk_set_dirty_page?
Yes, I removed my patch and applied both patches from you.
Thanks.
Grr. Inconsistent
Chris Mason [EMAIL PROTECTED] writes:
So, the problem is using the Dirty bit to indicate pinned. You're
completely right that our current setup of buffer heads and pages and
filesystpem metadata is complex and difficult.
But, moving the buffer heads off of the page cache pages isn't going
Chris Mason [EMAIL PROTECTED] writes:
On Wed, 2007-10-17 at 17:28 -0600, Eric W. Biederman wrote:
Chris Mason [EMAIL PROTECTED] writes:
So, the problem is using the Dirty bit to indicate pinned. You're
completely right that our current setup of buffer heads and pages and
filesystpem
cleanups to diverge and simplify the
address_space_operations of the buffer cache and block device
page cache.
As a side effect of this cleanup the current ramdisk code should
be safe from dropping pages because we never place any buffer heads
on ramdisk pages.
Signed-off-by: Eric W. Biederman [EMAIL
Jeff Garzik [EMAIL PROTECTED] writes:
commit 654f4a242cac0148ffe98ce288c9116e65b08e44
Author: Jeff Garzik [EMAIL PROTECTED]
Date: Fri Oct 19 00:47:17 2007 -0400
[IRQ ARG REMOVAL] non-trivial driver updates
Ok. You have some random cleanups as buried in this patch
as well as the
Jeff Garzik [EMAIL PROTECTED] writes:
commit 008b5fcf3c1d8456005de26ddd4256b1369225e8
Author: Jeff Garzik [EMAIL PROTECTED]
Date: Fri Oct 19 00:45:51 2007 -0400
[IRQ ARG REMOVAL] core interrupt delivery infrastructure updates
include/asm-generic/irq_regs.h | 25
Nick Piggin [EMAIL PROTECTED] writes:
[*] The ramdisk code is simply buggy, right? (and not the buffer
cache)
From the perspective of the ramdisk it expects the buffer cache to
simply be a user of the page cache, and thus the buffer cache
is horribly buggy.
From the perspective of the
Andrew Morton [EMAIL PROTECTED] writes:
I don't think we little angels want to tread here. There are so many
weirdo things out there which will break if we bust the coherence between
the fs and /dev/hda1.
We broke coherence between the fs and /dev/hda1 when we introduced
the page cache
fix it.
Sorry about that.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
kernel/Makefile |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/kernel/Makefile b/kernel/Makefile
index 05c3e6d..79f017e 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -9,8 +9,9
Jeff Garzik [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Jeff Garzik [EMAIL PROTECTED] writes:
Do you think set_irqfunc_irq() should be called at all the callsites of
set_irq_regs(), or one the fix you mention is applied, do you think current
model is sufficient?
Good question
not loose the contents of the ramdisk. Most
of all this ensures we don't loose data during normal use of the
ramdisk.
I deliberately avoid the cleanup that is now possible because this
patch is intended to be a bug fix.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
drivers/block/rd.c | 19
Jeff Garzik [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
In this case we can easily pass the irqno into request_irq, allowing
us to do unsigned int intno = (unsigned int)dev_id;.
I suspect this is the case for the majority of the non-trivial users
as well.
Not that easy, alas
Ingo Molnar [EMAIL PROTECTED] writes:
* Eric W. Biederman [EMAIL PROTECTED] wrote:
thanks for doing this.
Yes. keeping this alive is good.
The practical question is how do we make this change without breaking
the drivers that use their irq argument.
the get_irq_regs() approach
Jeff Garzik [EMAIL PROTECTED] writes:
Do you think set_irqfunc_irq() should be called at all the callsites of
set_irq_regs(), or one the fix you mention is applied, do you think current
model is sufficient?
Good question. At first glance I think the call sites are ok, that
is where we have
Jeff Garzik [EMAIL PROTECTED] writes:
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 80eab7a..92e1456 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -455,7 +455,7 @@ void free_irq(unsigned int irq, void *dev_id)
*/
Christian Borntraeger [EMAIL PROTECTED] writes:
Am Donnerstag, 18. Oktober 2007 schrieb Eric W. Biederman:
Grr. Inconsistent rules on a core piece of infrastructure.
It looks like that if there is any trivial/minimal fix it
is based on your patch suppressing try_to_free_buffers. Ugh.
Eric
Thomas Gleixner [EMAIL PROTECTED] writes:
On Fri, 19 Oct 2007, Jeff Garzik wrote:
WARNING NOT FOR MERGE WARNING NOT FOR MERGE WARNING NOT FOR MERGE
This posting is just to demonstrate something that I have been keeping
alive in the background. I have no urge to push it upstream anytime
Jeff Garzik [EMAIL PROTECTED] writes:
commit 8d45690dd90b18daaa21b981ab20caf393220bf0
Author: Jeff Garzik [EMAIL PROTECTED]
Date: Fri Oct 19 00:46:23 2007 -0400
[IRQ ARG REMOVAL] various non-trivial arch updates
arch/x86/kernel/vm86_32.c |3 ++-
Nick Piggin [EMAIL PROTECTED] writes:
On Saturday 20 October 2007 07:27, Eric W. Biederman wrote:
Andrew Morton [EMAIL PROTECTED] writes:
I don't think we little angels want to tread here. There are so many
weirdo things out there which will break if we bust the coherence between
the fs
Nick Piggin [EMAIL PROTECTED] writes:
On Saturday 20 October 2007 08:51, Eric W. Biederman wrote:
Currently the ramdisk tries to keep the block device page cache pages
from being marked clean and dropped from memory. That fails for
filesystems that use the buffer cache because the buffer
Nick Piggin [EMAIL PROTECTED] writes:
Yes it does. It is exactly breaking the coherency between block
device and filesystem metadata coherency that Andrew cared about.
Whether or not that matters, that is a much bigger conceptual
change than simply using slightly more (reclaimable) memory in
Nick Piggin [EMAIL PROTECTED] writes:
On Sunday 21 October 2007 14:53, Eric W. Biederman wrote:
Nick Piggin [EMAIL PROTECTED] writes:
On Saturday 20 October 2007 07:27, Eric W. Biederman wrote:
Andrew Morton [EMAIL PROTECTED] writes:
I don't think we little angels want to tread here
Christian Borntraeger [EMAIL PROTECTED] writes:
Am Sonntag, 21. Oktober 2007 schrieb Eric W. Biederman:
Nick. Reread the patch. The only thing your arguments have
established for me is that this patch is not obviously correct. Which
makes it ineligible for a back port. Frankly I suspect
Nick Piggin [EMAIL PROTECTED] writes:
OK, I missed that you set the new inode's aops to the ramdisk_aops
rather than the bd_inode. Which doesn't make a lot of sense because
you just have a lot of useless aops there now.
Not totally useless as you have mentioned they are accessed by
the lru so
Nick Piggin [EMAIL PROTECTED] writes:
On Sunday 21 October 2007 18:23, Eric W. Biederman wrote:
Christian Borntraeger [EMAIL PROTECTED] writes:
Let me put it another way. Looking at /proc/slabinfo I can get
37 buffer_heads per page. I can allocate 10% of memory in
buffer_heads before we
to check up on sysctl values.
This should fix it.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
diff --git a/kernel/sysctl_check.c b/kernel/sysctl_check.c
index 3c9ef5a..ed6fe51 100644
--- a/kernel/sysctl_check.c
+++ b/kernel/sysctl_check.c
@@ -731,7 +731,7 @@ static struct trans_ctl_table
801199ce805a2412bbcd9bfe213092ec656013dd
Author: Eric W. Biederman [EMAIL PROTECTED]
Date: Mon Oct 2 02:18:48 2006 -0700
Rationale is very weak and patch adds considerable complexity
for no good reason. Besides, it's obfuscated just for the hell of it:
if (!IS_ERR(result) || PTR_ERR(result) != -ENOENT
Adrian Bunk [EMAIL PROTECTED] writes:
Struct proc_net_ns_ops can become static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Acked-by: Eric W. Biederman [EMAIL PROTECTED]
Don't have a clue why I didn't make it static originally.
---
5ae49d45bc25eed356ecbe3592db270bfa1d9b73
diff --git
Neil Horman [EMAIL PROTECTED] writes:
Neil, is it possible to do some serial console debugging to find out
where exactly we are hanging? Beats me, what's that operation which can
not be executed while being in NMI handler and makes system to hang. I am
also curious to know if it is nested
Arvid Brodin arvid.bro...@xdin.com writes:
Hi,
Below is a patch that adds a file /proc/PID/text_md5sum which when read
returns the md5
checksum of a process' text segment. (This would be used e.g. to make sure a
process'
code hasn't been tampered with.)
However, I have a few questions:
the user_id and group_id mount options
into kuids and kgids at mount time, and use uid_eq and gid_eq to
compare the in fuse_allow_task.
Cc: Miklos Szeredi mik...@szeredi.hu
Acked-by: Serge Hallyn serge.hal...@canonical.com
Signed-off-by: Eric W. Biederman ebied...@xmission.com
---
fs/fuse/dev.c|4
Mitsuhiro Tanino mitsuhiro.tanino...@hitachi.com writes:
Hi Vivek,
(2012/10/31 23:14), Vivek Goyal wrote:
If hwpoision functionality is not available in hardware, then respective
bit will not be even set in struct page and it will be saved by default.
So it should not matter whether
Gao feng gaof...@cn.fujitsu.com writes:
we should call pid_ns_release_proc to unmount pid_namespace's
proc_mnt when copy_net_ns failed in function create_new_namespaces.
otherwise,the proc_mnt will not be freed and because the super_block
of proc_mnt also add the reference of the
Matthew Garrett mj...@srcf.ucam.org writes:
On Thu, Nov 01, 2012 at 09:58:17PM +, Alan Cox wrote:
On Thu, 1 Nov 2012 21:34:52 +
Matthew Garrett mj...@srcf.ucam.org wrote:
I think you've misunderstood. Blacklist updates are append only.
I think you've misunderstood - thats a
801 - 900 of 10702 matches
Mail list logo
