Dave Hansen [EMAIL PROTECTED] writes:
On Mon, 2007-03-12 at 20:07 +0300, Kirill Korotaev wrote:
On Mon, 2007-03-12 at 19:23 +0300, Kirill Korotaev wrote:
For these you essentially need per-container page-_mapcount counter,
otherwise you can't detect whether rss group still has the page in
Herbert Poetzl [EMAIL PROTECTED] writes:
On Mon, Mar 12, 2007 at 09:50:08AM -0700, Dave Hansen wrote:
On Mon, 2007-03-12 at 19:23 +0300, Kirill Korotaev wrote:
For these you essentially need per-container page-_mapcount counter,
otherwise you can't detect whether rss group still has the
Kirill Korotaev [EMAIL PROTECTED] writes:
Eric,
And misses every resource sharing opportunity in sight.
that was my point too.
Except for
filtering the which pages are eligible for reclaim an RSS limit should
not need to change the existing reclaim logic, and with things like the
memory
Nick Piggin [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
First touch page ownership does not guarantee give me anything useful
for knowing if I can run my application or not. Because of page
sharing my application might run inside the rss limit only because
I got lucky and happened
Ugh. I missed this one, when I fixed this. Sorry I thought the loop in
con_init() covered all of the consoles and we initialized all of them
at boot time :(
Bernhard Walle [EMAIL PROTECTED] writes:
This patch initialises the SAK member of the vc_cons variable on all virtual
terminals, not
Here is a quick summary of the regressions I am looking at.
- Currently we appear to have a pid leak in tty_io.c
http://lkml.org/lkml/2007/3/8/222
- There is a missing init_WORK in vt.c that cases oops
when we attempt to use SAK.
http://lkml.org/lkml/2007/3/11/148
- We have a network ABI
Catalin Marinas [EMAIL PROTECTED] writes:
On 09/03/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
If I can manage to focus on this, it looks like the information I need to
start fixing this.
I had a look at the second leak reported it seems to be caused by the
same proc_set_tty() call
Greg KH [EMAIL PROTECTED] writes:
I do not think this should be reverted, as the odds that some one will
rename their network device to be irq or something else that is in the
pci device's directory is pretty slim. It also only shows up if
CONFIG_SYSFS_DEPRECATED is disabled, not the common
Ingo Molnar [EMAIL PROTECTED] writes:
* Alexey Dobriyan [EMAIL PROTECTED] wrote:
On 3/14/07, Ingo Molnar [EMAIL PROTECTED] wrote:
#define PROCNAME_PMLsys/kernel/preempt_max_latency
static __init int latency_fs_init(void)
{
struct proc_dir_entry *entry;
if
Pavel Emelianov [EMAIL PROTECTED] writes:
Hi.
I'm looking at how alloc_pid() works and can't understand
one (simple/stupid) thing.
It first kmem_cache_alloc()-s a strct pid, then calls
alloc_pidmap() and at the end it taks a global pidmap_lock()
to add new pid to hash.
The question is -
How does this look?
I don't have the setup to test this easily, but this bit makes seems to make
sense. I will keep code reviewing and see if I can convince myself that this
is correct or incorrect in the mean time...
diff --git a/drivers/char/tty_io.c b/drivers/char/tty_io.c
index
William Lee Irwin III [EMAIL PROTECTED] writes:
On Wed, Mar 14, 2007 at 08:12:35AM -0600, Eric W. Biederman wrote:
If we do dig into this more we need to consider a radix_tree to hold
the pid values. That could replace both the pid map and the hash
table, gracefully handle but large
Bjorn Helgaas [EMAIL PROTECTED] writes:
In 2.6.21-rc3-mm2 (plus some move_freepages() bugfixes), I hit one
of the warnings added by Eric's msi-debug-code.patch. This is on an
ia64 box, an HP rx2600. Let me know if I can collect more information.
I think we are good. How pci_save_state and
Dave Jones [EMAIL PROTECTED] writes:
On Tue, Mar 13, 2007 at 10:22:53AM +0100, Rafael J. Wysocki wrote:
On Tuesday, 13 March 2007 05:08, Dave Jones wrote:
I spent considerable time over the last day or so bisecting to
find out why an X60 stopped resuming somewhen between 2.6.20 and
Pavel Emelianov [EMAIL PROTECTED] writes:
Srivatsa Vaddagiri wrote:
On Tue, Mar 13, 2007 at 06:41:05PM +0300, Pavel Emelianov wrote:
right, but atomic ops have much less impact on most
architectures than locks :)
Right. But atomic_add_unless() is slower as it is
essentially a loop. See my
Dave Jones [EMAIL PROTECTED] writes:
I just did a build of top of tree, including those commits, and
it's still broken. Booting with pci=nomsi no longer 'fixes' it
though, which may indicate that the MSI changes were a red herring.
(Or that the subsequent changes have regressed it even more,
Catalin Marinas [EMAIL PROTECTED] writes:
On 14/03/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
How does this look?
It seems to fix the leak. I looked at the logs and proc_set_tty calls
put_pid twice for pid 245 (the unresolved leak) and get_pid for pid
296, which is later passed
Alan Cox [EMAIL PROTECTED] writes:
stuff is happening by comparing page-count and page-_mapcount, but it
certainly wouldn't be conclusive. But, does this kind of nonsense even
happen in practice?
Is it useful for me as a bad guy to make it happen ?
To create a DOS attack.
- Allocate
Ian Kent [EMAIL PROTECTED] writes:
On Mon, 12 Mar 2007, [EMAIL PROTECTED] wrote:
From: Sukadev Bhattiprolu [EMAIL PROTECTED]
Subject: [PATCH 2/2] Replace pid_t in autofs with struct pid reference.
Make autofs container-friendly by caching struct pid reference rather
than pid_t and using
at 10:54:07AM -0600, Eric W. Biederman wrote:
Possibly. We aren't that sparsely populated when it comes to pids.
Hash tables aren't good at saving space either, and when they are space
efficient they are on the edge of long hash chains so they are on
the edge of performance problems
Oleg Nesterov [EMAIL PROTECTED] writes:
Sukadev Bhattiprolu wrote:
This means that idle threads (except swapper) are visible to
for_each_process()
and do_each_thread(). Looks dangerous and somewhat strange to me.
Could you explain this change?
Good catch. I've been so busy pounding
Dave Hansen [EMAIL PROTECTED] writes:
On Thu, 2007-03-15 at 18:55 -0600, Eric W. Biederman wrote:
To create a DOS attack.
- Allocate some memory you know your victim will want in the future,
(shared libraries and the like).
- Wait until your victim is using the memory you allocated
Ian Kent [EMAIL PROTECTED] writes:
On Fri, 2007-03-16 at 15:44 +0100, Cedric Le Goater wrote:
How about you send over the autofs4 bit and I'll have a look (the autofs
patch looked fine). That would save me a bit of time and if there are
any changes needed I can send an updated patch for
William Lee Irwin III [EMAIL PROTECTED] writes:
On Fri, Mar 16, 2007 at 07:04:28AM -0600, Eric W. Biederman wrote:
Grr. s/patricia tree/fib tree/. We use that in the networking for
the forwarding information base and I got mis-remembered it. Anyway
the interesting thing with the binary
Catalin Marinas [EMAIL PROTECTED] writes:
On 14/03/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
How does this look?
It seems to fix the leak. I looked at the logs and proc_set_tty calls
put_pid twice for pid 245 (the unresolved leak) and get_pid for pid
296, which is later passed
Zachary Amsden [EMAIL PROTECTED] writes:
Paravirt-ops guests which move the fixmap also end up moving the syscall VDSO.
This fails if it is prelinked at a fixed address, which is why COMPAT_VDSO is
broken under CONFIG_VMI (and also under CONFIG_XEN). Several options are
available to try to
Jeremy Fitzhardinge [EMAIL PROTECTED] writes:
Ingo Molnar wrote:
that's what is the case right now, but much of the intention behind the
vma based vDSO is to enable per-process randomized vdso locations, and
various distributions do that. So the 'modern' vDSO concept is very much
Srivatsa Vaddagiri [EMAIL PROTECTED] writes:
On Thu, Mar 15, 2007 at 12:12:50PM -0700, Paul Menage wrote:
Yes me too. But maybe to keep in simple in initial versions, we should
avoid that optimisation and at the same time get statistics on duplicates?.
That's an implementation detail - we
I have recently been investigating why we reprogram ioapic irqs in the
interrupt handler, because it significantly complicates the code, and
makes things more fragile. Eventually I found the commit with the
justification, see below.
There are not enough details in the justification to really
Zwane Mwaikambo [EMAIL PROTECTED] writes:
On Sat, 10 Feb 2007, Eric W. Biederman wrote:
There are not enough details in the justification to really understand
the issue so I'm asking to see if someone has some more details.
The description makes the assertion that reprograming the ioapic
Andi Kleen [EMAIL PROTECTED] writes:
From: Ingo Molnar [EMAIL PROTECTED]
Default to physical mode on hotplug CPU kernels. Furher simplify and clean up
the APIC initialization code.
Where is the code that the subject describes?
I have two problems here.
- I don't see anything handling the
Etienne Lorrain [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Etienne Lorrain writes:
Well, a self relocating image cannot be an ELF file because the code
to relocate the ELF cannot be executed at the wrong place.
If relocation is needed, I would better like not to link vmlinux
Natalie Protasevich [EMAIL PROTECTED] writes:
On 2/11/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
The code currently in the kernel does:
pending
mask
read io_apic
ack
reprogram vector and destination
unmask
So I guess it does retain the bug fix
Zwane Mwaikambo [EMAIL PROTECTED] writes:
The 7500 issue isn't actually a race but a disease, if you mask a pending
irq in its RTE, the PCI hub generates an INTx message corresponding to
that irq. This apparently was done to support booting OSes without APIC
support. So the following would
Zwane Mwaikambo [EMAIL PROTECTED] writes:
On Sun, 11 Feb 2007, Eric W. Biederman wrote:
2.15.2 PCI Express* Legacy INTx Support and Boot Interrupt
http://download.intel.com/design/chipsets/datashts/30262802.pdf
Ouch. And this kind of thing isn't exactly uncommon.
However if we have
Etienne Lorrain [EMAIL PROTECTED] writes:
--- Eric W. Biederman wrote:
So I really don't care if we move whole real mode section into a note
or if we just put a pointer to it into a note. What is important is
that we use a note to find it.
Well, we can advertise by a note the section
H. Peter Anvin [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
With ELF we get a single file format that works on multiple
architectures and for multiple OS-s, with well understood rules. This
allows for a broader audience who can review and maintain the code.
In addition to the real
://download.intel.com/design/chipsets/e8501/datashts/30962001.pdf,
specifically on page 334.
Signed-off-by: Benjamin M Romer [EMAIL PROTECTED]
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
Cc: Andi Kleen [EMAIL PROTECTED]
Cc: Eric W. Biederman [EMAIL PROTECTED]
Cc: Vivek Goyal [EMAIL PROTECTED]
Signed
Andi Kleen [EMAIL PROTECTED] writes:
What experimental evidence did you have?
But I'm tempted to drop this unless the hotplug mystery can be cleared
up. There was past information that logical is unsafe for hotplug.
Basically as I commented in genapic_flat, that at least on hyperthreading
Nadia Derbey [EMAIL PROTECTED] writes:
So, should I understand from this that automatic tuning and the AKT framework
itself would make sense, given that I find the rigth tunables it should be
applied to?
Sort of. The concept of things tuning themselves automatically makes
a lot of sense.
Alexey Dobriyan [EMAIL PROTECTED] writes:
kernel BUG at kernel/workqueue.c:212! 100% reproducable
queue_work
__handle_sysrq
kbd_event
add_timer_randomness
kbd_event
input_event
atkbd_interrupt
serio_interrupt
i8042_interrupt
PREPARE_WORK calls that are now gone.
If we call schedule_work again before it has processed it
has generated the first SAK it will simply ignore the duplicate
schedule_work request.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
drivers/char/keyboard.c |1 -
drivers/char/sysrq.c
Jeremy Fitzhardinge [EMAIL PROTECTED] writes:
Andi Kleen wrote:
+#ifdef CONFIG_XEN
+#include ../xen/xen-head.S
+#endif
Can this really not be linked separately?
I did a patch to do this (attached). In principle it should be pretty
simple, but I think I'm running into toolchain
Jeremy Fitzhardinge [EMAIL PROTECTED] writes:
There need to be alignment directives for the page aligned chunks.
Placing the page aligned chunks in a special section is nice in that
it ensures the linker packs everything tightly but should be
completely unnecessary if the alignment is correct.
Jeremy Fitzhardinge [EMAIL PROTECTED] writes:
Add Xen interface header files. These are taken fairly directly from
the Xen tree and hence the style is not entirely in accordance with
Linux guidelines. There is a tension between fitting with Linux coding
rules and ease of maintenance.
Define
Jeremy Fitzhardinge [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Well I did a little by hand parsing and the not I parsed looked ok.
How does the output differ from a what you get when xen-head.S is
included?
Ah!
The .notes section gets SHT_NOTE in vmlinux when xen-head.S
Jeremy Fitzhardinge [EMAIL PROTECTED] writes:
+++ b/drivers/xen/Kconfig.net
@@ -0,0 +1,14 @@
+menu Xen network device drivers
+depends on NETDEVICES XEN
+
+config XEN_NETDEV_FRONTEND
+ tristate Network-device frontend driver
+ depends on XEN
+ default y
+ help
Nadia Derbey [EMAIL PROTECTED] writes:
But, what do you do with Oracle that's asking maxfiles to be set to 0x1,
while the default value might be enough for a system that's not running
Oracle.
I'm afraid that giving boot time values to the max_* tunables we will loose
all
the benefits
Jeremy Fitzhardinge [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Ok. If that is all this may be a difference that makes no difference.
binutils has a bad habit of looking at sections (which are fully
optional) instead of segments on ET_EXEC and ET_DYN objects. Only
ET_REL objects (.o
Jeremy Fitzhardinge [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Reasonable and it's probably worth letting the binutils developer know.
I do agree that it is weird. It might be that something in binutils
doesn't like us dropping some of the notes.
What do you mean by dropping
Jeremy Fitzhardinge [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
I'm pretty certain we explicitly drop the weird GNU note that
is automatically generated by gcc and specifies something informational.
But that's something else again, since it appears as a PT_GNU_STACK phdr
Andrew Morton [EMAIL PROTECTED] writes:
That's shm-make-sysv-ipc-shared-memory-use-stacked-files.patch, brought to
us by Eric-who-hasnt-read-Documentation/SubmitChecklist.
Sorry I thought I had all of the interesting debugging enabled in my
kernel build. It must of fallen out someplace. I
Len Brown [EMAIL PROTECTED] writes:
e1000 faults in 2.6.20-git, while 2.6.20 worked fine.
System is a D875PBZ with LOM.
clues?
I'm guessing this is an old bug found by the following bit of
debug coded added into since v2.6.20
+#ifdef CONFIG_DEBUG_SHIRQ
+ if (irqflags IRQF_SHARED) {
.
This is also a bit of a general scrub on the error handling.
Everything is now forced through the single return statement
for clarity, and the handling of the return address now uses
fewer casts.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
ipc/shm.c | 56
drivers/video/Kconfig:1606:warning: 'select' used by config symbol 'FB_PS3'
refer to undefined symbol 'PS3_PS3AV'
/mnt/md0/devel/linux-mm/ipc/shm.c: In function 'do_shmat':
/mnt/md0/devel/linux-mm/ipc/shm.c:945: warning: passing argument 1 of 'IS_ERR'
makes pointer from integer without a cast
Len Brown [EMAIL PROTECTED] writes:
This code makes simple systems complex:
ACPI: PCI Interrupt :03:04.0[A] - GSI 18 (level, low) - IRQ 16
ACPI: PCI Interrupt :00:1d.0[A] - GSI 16 (level, low) - IRQ 17
ACPI: PCI Interrupt :00:1d.1[B] - GSI 19 (level, low) - IRQ 18
ACPI: PCI
Zachary Amsden [EMAIL PROTECTED] writes:
We do support different HZ values, although 100HZ is actually preferable for
us,
so I don't object to that. PREEMPT is supported by us, but not as tested as I
would like, so I also don't object to dropping it for generic paravirt guests
-
Rusty -
Ian Campbell [EMAIL PROTECTED] writes:
On Fri, 2007-02-16 at 00:33 -0700, Eric W. Biederman wrote:
I know there actually has been some work to get kexec actually working under
Xen but I don't know where that has gone.
kexec/kdump works with Xen 3.0.4 but it's a dom0 only thing so it
doesn't
Looking at irq handling in the kernel from a generic perspective I
see two problems.
- There are a huge number of possible interrupt sources but in
practice very few of them are used. So we need a large
irq_desc[NR_IRQS] array that mostly goes unused. If we try for
tighter pacing we get
[EMAIL PROTECTED] (Eric W. Biederman) writes:
By itself I don't think we are going to observe any real problems
with this patch.
However if we are going to be serious about this we need to do a
few more things.
- kill ioapic_renumber_irq.
Looking closer ioapic_renumber_irq does not appear
Natalie Protasevich [EMAIL PROTECTED] writes:
This routine actually renumbers gsi's. I don't think you can kill
ioapic_renumber_irq without bringing down ES7000 that have swapped
legacy/PCI ranges and are still out there. Moreover, mach-es7000
purpose is to define and use the range swapper on
and NR_IRQ_VECTORS into just
NR_IRQS and raises NR_IRQS where appropriate above the number of irqs
we can use at one time.
Allowing the kernel to work on big machines without complicated
and error prone irq remapping logic.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
arch/i386/kernel
Andi Kleen [EMAIL PROTECTED] writes:
Allowing the kernel to work on big machines without complicated
and error prone irq remapping logic.
How much memory does this use by default? If it's much there should
be at least a CONFIG_* to make it smaller.
If you don't build a generic kernel and
Ingo Molnar [EMAIL PROTECTED] writes:
* Eric W. Biederman [EMAIL PROTECTED] wrote:
So I propose we remove all assumptions from the code that we actually
have an array of irqs. That will allow for irq_desc to be dynamically
allocated instead of statically allocated saving memory
Andi Kleen [EMAIL PROTECTED] writes:
I expect the most it makes sense to aim for 2.6.22 are the genirq
changes so the internal arch code is passing struct irq_desc
everywhere internally.
Are there any livetime issues with passing pointers around?
e.g. what happens on APIC hotunplug etc.?
Ingo Molnar [EMAIL PROTECTED] writes:
or am i missing something fundamental?
One piece.
At the driver level this not a big scary change.
This is just a change with widespread effect.
It should be no worse than enabling a very revealing new compiler
warning.
Every fix should be purely
Jeremy Fitzhardinge [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
So I propose we remove all assumptions from the code that we actually
have an array of irqs. That will allow for irq_desc to be dynamically
allocated instead of statically allocated saving memory and reducing
kernel
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
On Fri, 2007-02-16 at 05:10 -0700, Eric W. Biederman wrote:
Getting the drivers changed actually looks to be pretty straight
forward it will just be a very large mechanical change. We change the
type where of variables where appropriate
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
In addition, if we remove the numbers, archs will need basically the
exact same services provided by the powerpc irq core for reverse mapping
(going from a HW irq number on a given PIC back to an irq_desc *).
Ben you seem to be under
Russell King [EMAIL PROTECTED] writes:
On Fri, Feb 16, 2007 at 08:45:58PM +0100, Arnd Bergmann wrote:
On Friday 16 February 2007 13:10, Eric W. Biederman wrote:
To do this I believe will require a s/unsigned int irq/struct irq_desc
*irq/
throughout the entire kernel. Getting the arch
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
We might need this. But I don't think we need reference counting in
the traditional sense. For all practical purpose we already have
dynamic irq allocation and it hasn't proven necessary. I would
prefer to go to lengths to avoid having to
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
The only time it really makes sense to me to let the irq number vary
arbitrary are when things are truly dynamic, like with MSI, a
hypervisor, or hot plug interrupt controllers.
I don't understand why you would go to all that lenght to replace
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
On Sat, 2007-02-17 at 02:06 -0700, Eric W. Biederman wrote:
However, PowerPC is a good example because it has such a diversity of
very different hardware setups to deal with, ranging from the multiple
layers of cascading controllers all over
Oleg Nesterov [EMAIL PROTECTED] writes:
On 03/16, Eric W. Biederman wrote:
Oleg Nesterov [EMAIL PROTECTED] writes:
Sukadev Bhattiprolu wrote:
This means that idle threads (except swapper) are visible to
for_each_process()
and do_each_thread(). Looks dangerous and somewhat strange
Oleg Nesterov [EMAIL PROTECTED] writes:
On 03/17, Oleg Nesterov wrote:
Well the initial kernel process does not have a struct pid so when
it's children start doing:
attach_pid(p, PIDTYPE_PGID, task_group(p));
attach_pid(p, PIDTYPE_SID, task_session(p));
We will get an oops.
Oleg Nesterov [EMAIL PROTECTED] writes:
Yes! I meant we should change INIT_SIGNALS(), currently it does
#define INIT_SIGNALS(sig) {
...
.pgrp = 1,
{ .__session = 1},
and this confuses (I think) set_special_pids(1,1) above.
Dave Hansen [EMAIL PROTECTED] writes:
On Mon, 2007-03-12 at 23:41 +0100, Herbert Poetzl wrote:
let me give a real world example here:
- typical guest with 600MB disk space
- about 100MB guest specific data (not shared)
- assumed that 80% of the libs/tools are used
I get the general
Dave Hansen [EMAIL PROTECTED] writes:
On Fri, 2007-03-16 at 12:54 -0600, Eric W. Biederman wrote:
Dave Hansen [EMAIL PROTECTED] writes:
- Why do limits have to apply to the unmapped page cache?
To me, it is just because it consumes memory. Unmapped cache is, of
couse, much more easily
and obviously correct so I am doing that first.
Fixing the places that should be performing hangup processing is much
less obviously correct. So those I'm aiming those patches at -mm.
for now, so the can age a while before they are merged.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
drivers
Andrew the following tty fixes turned up while I was reviewing the
code to see if I was fixing the pid leaks properly. I don't think
they are critical so at this point so they are probably not 2.6.21
material.
The do appear to be changes worth making though.
Eric
-
To unsubscribe from this
All of the users of proc_clear_tty are compiled into
the kernel so exporting this symbol appears gratuitous.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
drivers/char/tty_io.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/char/tty_io.c b/drivers/char
of the complications from the code
introduced by my misunderstanding, making the code a little
more readable.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
drivers/char/tty_io.c | 23 ++-
1 files changed, 6 insertions(+), 17 deletions(-)
diff --git a/drivers/char/tty_io.c b
even make some part of user space happy
because it received a SIGHUP it was expecting.
In addition since this removes the last user of proc_set_tty outside
of tty_io.c proc_set_tty is made static and removed from tty.h
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
drivers/char/tty_io.c
this fix
should remove the last path into proc_clear_tty that has a session
or a process group.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
drivers/char/tty_io.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/char/tty_io.c b/drivers/char/tty_io.c
index
Michael S. Tsirkin [EMAIL PROTECTED] writes:
Why is neighbour-dev changed here?
It holds reference to device and prevents its destruction.
If dst is held somewhere, we cannot destroy the device and deadlock
while unregister.
BTW, can this ever happen for the loopback device itself?
Is
David Miller [EMAIL PROTECTED] writes:
From: Michael S. Tsirkin [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 00:42:34 +0200
Hmm. Then the code moving dst-dev to point to the loopback
device will have to be fixed too. I'll post a patch a bit later.
Does this look sane (untested)?
Jeremy Fitzhardinge [EMAIL PROTECTED] writes:
Andi Kleen wrote:
On Wednesday 14 March 2007 23:24, Jeremy Fitzhardinge wrote:
The reboot_fixups stuff seems to be a bit of a mess, specifically the
header is in linux/ when its a purely i386-specific piece of code. I'm
not sure why it has
Davide Libenzi davidel@xmailserver.org writes:
struct signalfd_siginfo {
__u32 signo;/* si_signo */
__s32 err; /* si_errno */
__s32 code; /* si_code */
__u32 pid; /* si_pid */
__u32 uid; /* si_uid */
__s32 fd; /* si_fd */
Paul Menage [EMAIL PROTECTED] writes:
On 3/13/07, Dave Hansen [EMAIL PROTECTED] wrote:
How do we determine what is shared, and goes into the shared zones?
Once we've allocated a page, it's too late because we already picked.
Do we just assume all page cache is shared? Base it on filesystem,
Oliver Falk [EMAIL PROTECTED] writes:
Hi!
We have a discussion on alpha mailinglist at the moment, because of uname
-mpi.
AFAIK, uname -m should do some glibc call, which calls kernel, right?
However, I have two machines:
AS1000A:
[EMAIL PROTECTED] ~]# uname -mpi cat /proc/cpuinfo |
Davide Libenzi davidel@xmailserver.org writes:
On Mon, 19 Mar 2007, Eric W. Biederman wrote:
Davide Libenzi davidel@xmailserver.org writes:
struct signalfd_siginfo {
__u32 signo;/* si_signo */
__s32 err; /* si_errno */
__s32 code; /* si_code */
__u32 pid
Chris Wright [EMAIL PROTECTED] writes:
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
ENTRY(swapper_pg_dir)
+ .align PAGE_SIZE_asm
.fill 1024,4,0
does the native kernel lose memory here?
Not in my builds.
Shouldn't the align be before the label. Otherwise padding
would be inserted
I'm just trying to digest this a little.
As I understand your description for non-shared mappings the VMAs are
per process.
For shared mappings you share in some sense the page cache.
My gut feel says just keep a vma per process of the regions the
process has and do the appropriate book
H. Peter Anvin [EMAIL PROTECTED] writes:
Avi Kivity wrote:
It definitely should, especially on x86-64, where the page size isn't
guaranteed by the ABI (on i386, the ABI guarantees a 4K page size; on x86-64
it can be up to 64K.)
Wouldn't that be ia64?
No, the x86-64 EFI ABI permits page
Serge E. Hallyn [EMAIL PROTECTED] writes:
Index: 2.6.20/fs/autofs4/waitq.c
===
--- 2.6.20.orig/fs/autofs4/waitq.c
+++ 2.6.20/fs/autofs4/waitq.c
@@ -292,8 +292,8 @@ int autofs4_wait(struct autofs_sb_info *
Avi Kivity [EMAIL PROTECTED] writes:
I don't understand why interrupt latency suffers. Sure, the interrupt that's
being masked is delayed, but on the other hand the interrupt that's doing the
masking is not. We're moving the latency from the first interrupt to the
second, probably with a
Serge E. Hallyn [EMAIL PROTECTED] writes:
True, current-pid can probably always be legitimately taken as the pid
number in the current task's cloning namespace. But task-pid is
wrong.
Agreed.
So if as you say it's worth caching (not saying I doubt you, just that I
haven't verified), then
Rusty Russell [EMAIL PROTECTED] writes:
On Sun, 2007-03-18 at 13:08 +0100, Andi Kleen wrote:
The idea is _NOT_ that you go look for references to the paravirt_ops
members structure, that would be stupid and you wouldn't be able to
use the most efficient addressing mode on a given cpu,
David Miller [EMAIL PROTECTED] writes:
From: Linus Torvalds [EMAIL PROTECTED]
Date: Mon, 19 Mar 2007 20:18:14 -0700 (PDT)
Please don't subject us to another couple months of hair-pulling only
to have Linus yank the thing out again, there are certainly more
useful things to spend time
David Howells [EMAIL PROTECTED] writes:
Eric W. Biederman [EMAIL PROTECTED] wrote:
As I understand your description for non-shared mappings the VMAs are
per process.
Are you talking about the current state of play? If so, not precisely. In
the current scheme of things, *all* VMAs
301 - 400 of 10702 matches
Mail list logo
