Kumar Gala <[EMAIL PROTECTED]> wrote:
> For source lines I've seen both:
>
> source "arch/powerpc/platforms/52xx/Kconfig"
>
> and
>
> source arch/powerpc/platforms/85xx/Kconfig
>
> Is there a preferred style? Quotes or not?
$ find . -name Kconfig -exec grep ^source '{}' \;|grep \"|wc -l
Pekka J Enberg wrote:
Hi Nick,
On Fri, 16 Mar 2007, Nick Piggin wrote:
Could you try something like walk the i_mmap lists to find mms with vmas that
haven't need revoking, then each time you find one, take a ref on the mm, drop
i_mmap_lock, take mmap_sem, and walk all its vmas looking for any
On Fri, 16 Mar 2007, Nick Piggin wrote:
> So I think you really do need to get back to the mm, and then search its
> vmas.
You're right.
-
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.kerne
On 3/16/07, Horms <[EMAIL PROTECTED]> wrote:
On Fri, Mar 16, 2007 at 08:52:30AM +0530, Vivek Goyal wrote:
> So it will now be left to the user. If he tries to kexec to a 64bit kernel
> on a machine not supporting 32bit extensions, then kexec will not give
> any advance warning.
I feel comfortabl
Hi Nick,
On Fri, 16 Mar 2007, Nick Piggin wrote:
> Could you try something like walk the i_mmap lists to find mms with vmas that
> haven't need revoking, then each time you find one, take a ref on the mm, drop
> i_mmap_lock, take mmap_sem, and walk all its vmas looking for any that
> reference the
On Thu, 2007-03-15 at 16:02 -0700, Davide Libenzi wrote:
> > > + /*
> > > + * When we call this, the initialization must be complete, since
> > > + * aino_getfd() will install the fd.
> > > + */
> > > + error = aino_getfd(&ufd, &inode, &file, "[timerfd]",
Correcting my previous message, and confirming Leroy's one :
linux-2.6.20.tar.gz : bad
linux-2.6.20.1.tar.gz: bad
linux-2.6.20.2.tar.gz: good
linux-2.6.20.3.tar.gz: good
With :
COMPAT_VDSO=y
CONFIG_HIGHMEM64G=y
So problem have been solved with 2.6.20.2
Nilshar.
2007/3/15, Leroy van Lo
On Thu, 2007-03-15 at 17:22 -0700, Davide Libenzi wrote:
> +static void timerfd_setup(struct timerfd_ctx *ctx, int clockid, int flags,
> + const struct itimerspec *ktmr)
> +{
> + enum hrtimer_mode htmode;
> +
> + htmode = (flags & TFD_TIMER_ABSTIME) ? HRTIMER_MODE_ABS:
Pekka J Enberg wrote:
Pekka J Enberg wrote:
/*
-* Not holding ->mmap_sem here.
+* Not holding ->mmap_sem here but we must watch out for page
+* faults and after the shared mappings have been taken down
+* and sys_mmap() trying to remap the revoked range.
On Fri, Mar 16, 2007 at 07:17:43AM +, Ian Campbell wrote:
> On Fri, 2007-03-16 at 08:48 +0900, Horms wrote:
> > > >
> > > > Signed-off-by: Ian Campbell <[EMAIL PROTECTED]>
> > > >
> > > > diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
> > > > index d960507..523e109 100644
> > > > --- a/fs/p
On Fri, Mar 16, 2007 at 08:52:30AM +0530, Vivek Goyal wrote:
> On Fri, Mar 16, 2007 at 11:40:07AM +0900, Magnus Damm wrote:
> > On 3/16/07, Horms <[EMAIL PROTECTED]> wrote:
> > >On Thu, Mar 15, 2007 at 06:56:16PM +0530, Vivek Goyal wrote:
> > >> On Thu, Mar 15, 2007 at 12:22:57PM +, Ian Campbel
On Fri, 2007-03-16 at 08:12 +0530, Vivek Goyal wrote:
> I did not investigate deeper but I got a basic question. How will kexec
> know that underlying 32bit machine supports 64bit extensions or not?
It looks like /proc/cpuinfo flags contains "lm" (which is long mode,
right?) even if the machine is
Pekka J Enberg wrote:
> > /*
> > -* Not holding ->mmap_sem here.
> > +* Not holding ->mmap_sem here but we must watch out for page
> > +* faults and after the shared mappings have been taken down
> > +* and sys_mmap() trying to remap the revoked range.
> > */
> > vma->vm_fla
On Fri, 2007-03-16 at 11:40 +0900, Magnus Damm wrote:
> Right. And maybe it's a good idea to make sure that this feature is
> actually supported by kexec-tools before adding code to the kernel?
I sent patches to the fastboot list at the same time I sent these ones
to support differences in the und
On 3/16/07, Greg KH <[EMAIL PROTECTED]> wrote:
Is there any way you can use 'git bisect' to try to track down the root
cause of this?
Chris, If 2.6.19 works for you, could you please do a git bisect for
this bug? See the following URL for details:
http://www.kernel.org/pub/software/scm/git/doc
On Tue, Mar 13, 2007 at 08:03:49AM +0100, Benjamin Herrenschmidt wrote:
>> Hmm. The crash came back after I booted into Mac OS X and back. It was
>> however
>> a different crash, I believe it was coming from the USB modules (as it would
>> keep going when it happened, and get another crash, which
Pekka J Enberg wrote:
From: Pekka Enberg <[EMAIL PROTECTED]>
This is a rollup patch of the following fixes to address some of Andrew's
review comments:
- Fix return value type of system calls to long
- Add comment for vma->vm_flag barrier
- No need for GFP_NOFS for inode allocation, use G
From: Pekka Enberg <[EMAIL PROTECTED]>
This is a rollup patch of the following fixes to address some of Andrew's
review comments:
- Fix return value type of system calls to long
- Add comment for vma->vm_flag barrier
- No need for GFP_NOFS for inode allocation, use GFP_KERNEL instead
- Re
From: Pekka Enberg <[EMAIL PROTECTED]>
On 3/16/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> This all looks very strange. If the calling process expires its timeslice,
> the entire system call fails?
This changes revoke_mapping() to restart after cond_resched() to fix an
obvious goof made by me
From: Pekka Enberg <[EMAIL PROTECTED]>
Move REVOKEFS_MAGIC to where it belongs.
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
fs/revoke.c |1 +
include/linux/magic.h|1 +
include/linux/revoked_fs_i.h |2 --
3 files changed, 2 insertions(+), 2 deletions
On Fri, 2007-03-16 at 08:48 +0900, Horms wrote:
> > >
> > > Signed-off-by: Ian Campbell <[EMAIL PROTECTED]>
> > >
> > > diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
> > > index d960507..523e109 100644
> > > --- a/fs/proc/vmcore.c
> > > +++ b/fs/proc/vmcore.c
> > > @@ -514,7 +514,7 @@ static i
Am Freitag, 16. März 2007 03:06 schrieben Sie:
> Check out http://bugzilla.kernel.org/show_bug.cgi?id=8067 which is a
> duplicate of http://bugzilla.kernel.org/show_bug.cgi?id=7727 which is
> fixed. There is a patch available on the bugzilla if you want to try it
> out.
Thank you, I'll test this
Hi Andrew,
On Sun, 11 Mar 2007 13:30:49 +0200 (EET) Pekka J Enberg
<[EMAIL PROTECTED]> wrote:
On 3/16/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
n all system calls must return long.
Fixed.
On 3/16/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
so the modification of vm_flags is
Applied.
On Thursday 15 March 2007 15:15, Henrique de Moraes Holschuh wrote:
> This patch allows for ibm-acpi to coexist (with diminished functionality) with
> other drivers like ACPI_BAY. ibm-acpi will simply disable the functions it is
> not able to register ACPI notifiers for.
>
> Signed-off
Hello Mel,
> > > > > Today after +- 24h of uptime I found some more page allocation
> > > > > failures ('eth1: Can't allocate skb for Rx'). You'll find more here:
> > > > >
> > > > > http://tuxland.pl/misc/2.6.21-rc3-mm1-page-allocation-failure.txt
> > > > >
> > > > > System wasn't doing a
On Thu, 15 Mar 2007, Ulrich Drepper wrote:
> On 3/7/07, Davide Libenzi wrote:
> > Let's do this. How about you throw this way one of the case that would
> > possibly break, and I test it?
>
> Since you make such claims I assume your signalfd() implementation
> considers a signal delivered once i
On Thu, Mar 15, 2007 at 12:34:07PM -0400, Chuck Ebbert wrote:
> I've been holding off sending these in for -stable until they're
> merged, but now I wonder when that will happen.
Feel free to send them to stable@ when they go to Linus as it sounds
like they are almost there.
Thanks,
greg k-h
-
T
Jeremy Fitzhardinge wrote:
+} else if (strcmp(secstrings+sechdrs[i].sh_name,
".dynamic") == 0) {
+Elf32_Dyn *dyn = (void *)hdr + sechdrs[i].sh_offset;
+int tag;
+while ((tag = (++dyn)->d_tag) != DT_NULL)
Um, no.
Walk based
On Thursday 15 March 2007 21:24, Norberto Bensa wrote:
> Hello,
>
> is this output, normal? I meant, why counters on CPU1 is zero? Isn't this
> balanced?
yes, it is normal.
If you had an interrupt-limited workload then irqbalance
would pick things up and spread them out.
-Len
> $ cat /proc/i
On 3/7/07, Davide Libenzi wrote:
Let's do this. How about you throw this way one of the case that would
possibly break, and I test it?
Since you make such claims I assume your signalfd() implementation
considers a signal delivered once it is reported to an epoll() caller.
Right?
This is not w
Robert P. J. Day writes:
> Delete apparently unused header file arch/ppc/syslib/cpc710.h.
I suggest you send this to [EMAIL PROTECTED] and Matt Porter
<[EMAIL PROTECTED]> for review.
Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EM
Zachary Amsden wrote:
> Well testing that is not so fun. I installed SUSE Pro 9.0, and
> strings on ld.so contains the magic at_sysinfo assert! But it doesn't
> install TLS libraries, so I'll have to install them by hand.
>
> In works - in theory. Look, a puppy!
>
> Scratchbox is rumored to prod
On Thursday 15 March 2007 15:16, Peter Osterlund wrote:
> If bytes get lost in the communication with a serial mouse using the
> MS protocol, the kernel driver could do a better job getting back in
> sync. The first byte in a packet has bit 6 set, and no other bytes
> have that bit set. Therefore,
On Thu, 15 Mar 2007 11:06:21 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Tue, 13 Mar 2007 18:33:20 +0200 Dan Aloni <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> > This question is relevent to 2.6.20.
> >
> > I noticed that if the RSS for the stack size is say, 8MB, running
> > a single-t
On Thu, 15 Mar 2007, Steven Rostedt wrote:
> On Thu, 2007-03-15 at 17:06 +0100, Andi Kleen wrote:
>
> > Well I just see a lot of pain from these patches but I doubt
> > they will avoid any bugs. If people don't compile test both
> > archs they will always likely break on another. There are lots
On Wed, 2007-03-14 at 01:08 -0400, Steven Rostedt wrote:
> [Hopefully fixed email client to make it to the list this time]
> [This series has changed by using git-diff -M]
> Seems appropriate, but I really don't care what it's called. One thing about
> this name, is that typing arch/x86 doesn't t
[EMAIL PROTECTED] wrote:
On the other hand, Andreas suggested only marking it once every 32 calls,
but that required a helper variable. Statistically, jiffies%32 should
end up about the same as a helper variable %32.
This of course, if just calling mark_page_accessed() is actually expensive
en
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 pid_nr() to retreive a task's
On Thu, 2007-03-15 at 18:12 -0400, Mariusz Kozlowski wrote:
> Hello,
>
> This patch (against 2.6.21-rc3-mm1) balances parenthesis in blackfin
> header files.
>
> Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
>
> include/asm-blackfin/mach-bf535/bf535.h |4 ++--
> include/asm-b
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Invoke black magic to relocate the VDSO even when COMPAT_VDSO is enabled
by fixing up the ELF object.
So does it actually work? Can you boot the broken distros with this in
place?
Well testing that is not so fun. I installed SU
On Thu, 15 Mar 2007 14:35:17 EDT, Rik van Riel said:
> [EMAIL PROTECTED] wrote:
> > On Wed, 14 Mar 2007 22:33:17 BST, Andreas Mohr said:
> >
> >> it'd seem we need some kind of state management here to figure out good
> >> intervals of when to call mark_page_accessed() *again* for this page. E.g.
On Tue, 13 Mar 2007 16:30:27 -0700 Jeremy Fitzhardinge wrote:
> smp_call_function and smp_call_function_single are almost complete
> duplicates of the same logic. This patch combines them by
> implementing them in terms of the more general
> smp_call_function_mask().
The kernel-doc is still not
On Fri, Mar 16, 2007 at 11:40:07AM +0900, Magnus Damm wrote:
> On 3/16/07, Horms <[EMAIL PROTECTED]> wrote:
> >On Thu, Mar 15, 2007 at 06:56:16PM +0530, Vivek Goyal wrote:
> >> On Thu, Mar 15, 2007 at 12:22:57PM +, Ian Campbell wrote:
> >> > On Thu, 2007-03-15 at 11:17 +0530, Vivek Goyal wrote:
On Mon, 12 Mar 2007 18:22:45 + Andy Whitcroft <[EMAIL PROTECTED]> wrote:
> Following this email are three patches which represent the
> current state of the lumpy reclaim patches; collectively lumpy V5.
So where do we stand with this now?Does it make anything get better?
I (continue to)
Zachary Amsden wrote:
> Invoke black magic to relocate the VDSO even when COMPAT_VDSO is enabled
> by fixing up the ELF object.
>
So does it actually work? Can you boot the broken distros with this in
place?
> Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
>
> Index: linux-2.6.21/arch/i386
On Thu, 15 Mar 2007 18:29:51 -0500 Josh Boyer wrote:
> On Thu, Mar 15, 2007 at 02:24:10PM -0700, Randy Dunlap wrote:
> > On Thu, 15 Mar 2007 11:07:03 -0800 Andrew Morton wrote:
> >
> > >
> > > There's way too much code here to expect it to get decently reviewed,
> > > alas.
> >
> > Yes.
> >
>
plz allow me to explain more.
"Why register-stack/memory-stack upside down is bad" is a bit complicated.
So...this is a test and result for explaining bug.
This is a sample code and its result on 2.6.21-rc3.
Note: base address of memory'stack can be randomly change.
== sample code ==
[EMAIL PRO
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 address this. Jan had cooked up
a patch fo
On Fri, Mar 16, 2007 at 08:48:08AM +0900, Horms wrote:
> On Thu, Mar 15, 2007 at 06:56:16PM +0530, Vivek Goyal wrote:
> > On Thu, Mar 15, 2007 at 12:22:57PM +, Ian Campbell wrote:
> > > On Thu, 2007-03-15 at 11:17 +0530, Vivek Goyal wrote:
> > > > > > But I think changing this macro might run i
On 3/16/07, Horms <[EMAIL PROTECTED]> wrote:
On Thu, Mar 15, 2007 at 06:56:16PM +0530, Vivek Goyal wrote:
> On Thu, Mar 15, 2007 at 12:22:57PM +, Ian Campbell wrote:
> > On Thu, 2007-03-15 at 11:17 +0530, Vivek Goyal wrote:
> > > > > But I think changing this macro might run into issues. It i
On Tue, 13 Mar 2007 17:37:35 +1100 Rusty Russell wrote:
> On Tue, 2007-03-13 at 00:56 +0100, Andi Kleen wrote:
> > On Tue, Mar 13, 2007 at 10:18:03AM +1100, Rusty Russell wrote:
> > > OK, this confused me:
> > >
> > > Function reordering (REORDER) [N/y/?] (NEW) ?
> > >
> > >
On Thu, Mar 15, 2007 at 01:42:39PM +, Ian Campbell wrote:
> On Thu, 2007-03-15 at 18:56 +0530, Vivek Goyal wrote:
> >
> > Ideal place for this probably should have been arch dependent
> > crash_dump.h file. But we don't have one and no point introducing one
> > just for this macro.
>
> Agree
Chuck Ebbert wrote:
If you try to load both the pata_atiixp and the ahci driver
(for the same ATI SB600 adapter), very strange things happen.
The AHCI driver churns for three minutes or so, spewing
messages like this, then nothing works:
<6>ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Joerg Platte naasa.net> writes:
> Pid: 14, comm: events/0 Not tainted 2.6.18-4-amd64 #1
> RIP: 0010:[] [] keyring_destroy+0x32/0x96
[Snip]
> Can this oops be caused by a known and already
> fixed problem in a newer kernel versions? In this case I would submit a bug
> to the Debian BTS. Other
This patch moves scc_pata from ide/ppc to ide/pci in order to
build it in normal module.
Signed-off-by: Kou Ishizaki <[EMAIL PROTECTED]>
Signed-off-by: Akira Iguchi <[EMAIL PROTECTED]>
---
diff -Nrpu -X linux-2.6.21-rc3/Documentation/dontdiff
linux-2.6.21-rc3/drivers/ide/pci/scc_pata.c
linux-2.
This patch fixes:
* the dependency of scc_pata on BLK_DEV_IDEDMA_PCI
* incorrect link to ide-core
* move scc_pata from ide/ppc to ide/pci
Signed-off-by: Kou Ishizaki <[EMAIL PROTECTED]>
Signed-off-by: Akira Iguchi <[EMAIL PROTECTED]>
---
diff -Nrpu -X linux-2.6.21-rc3/Documentation/dontdiff
linu
On Thu, 15 Mar 2007, linux-os (Dick Johnson) wrote:
> It's not the same hardware and all the machines that I tried that
> have keyboards end up WORKING with the USB keyboard as well! But
> Dmitry Torokhov was right! I just burned a CD with all three modules,
> and the keyboard works! I didn't bot
On Sun, 11 Mar 2007 20:04:56 +0300 Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
> Differences from version 4:
> Updated in-code comments. Largely rewritten changelog.
> Lockdep please. --akpm
> ->read_proc, ->write_proc aren't special, Extend protection to
> most methods for
From: Christoph Hellwig <[EMAIL PROTECTED]>
Date: Thu, 15 Mar 2007 19:18:34 +
> On Thu, Mar 15, 2007 at 12:38:13PM +, Jan Beulich wrote:
> > While the kernel headers provide for this, there don't appear to be any
> > in-tree users (which seems contrary to general Linux policies). Would the
On Sun, 11 Mar 2007 13:30:49 +0200 (EET) Pekka J Enberg <[EMAIL PROTECTED]>
wrote:
> From: Pekka Enberg <[EMAIL PROTECTED]>
>
> The revokeat(2) and frevoke(2) system calls invalidate open file
> descriptors and shared mappings of an inode. After an successful
> revocation, operations on file des
On Thu, Mar 15, 2007 at 12:12:50PM -0700, Paul Menage wrote:
> There are some things that benefit from having an abstract
> container-like object available to store state, e.g. "is this
> container deleted?", "should userspace get a callback when this
> container is empty?".
IMO we can still get
Hi,
> Bart wrote:
>> Al wrote:
>> So AFAICS the minimal fix for that sucker is dependency on BLK_DEV_IDE=y;
>> however, I really wonder if
>> * it needs to be linked into ide-core (as opposed to being a normal
>> module of its own)
>
>AFAICS there are no legacy device ordering issues with scc
Hello,
is this output, normal? I meant, why counters on CPU1 is zero? Isn't this
balanced?
$ cat /proc/interrupts
CPU0 CPU1
0:4180170 0 IO-APIC-edge timer
1: 8060 0 IO-APIC-edge i8042
7: 0 0 IO-APIC-edge pa
On Wed, Mar 14, 2007 at 12:34:29PM +0100, Marco Berizzi wrote:
> Hello everybody.
> Since 2.6.19.2 + commit 7fbbb01dca7704d52ace6f45a805c98a5b0362f9
What commit is that? gitweb search tells me it's an nmi watchdog
change. Doesn't seem likely to change XFS behaviour - can
you post a url to the comm
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 bug with
wait or ptrace or something.
T
Hi,
I already sent this e-mail to Luc and on the pwc mailing list,
and got no answer. I'm trying again with the hope that this patch
would go in the kernel...
I have a Cisco VT Camera, and it was just collecting dust. I
decided to try connecting it to my Linux box at home
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.
-
Hello Stephen,
> yesterday I pulled from Linus tree because I saw the sky2 updated and I
> tried to break it but it seems that my problems are gone. I let you know
> if anything pops up in the future.
bad news. I today tried the sky2 driver which is in Linus Kernel Tree
(HEAD) on a machine with v
On Thu, 2007-03-15 at 01:13 -0400, Steven Rostedt wrote:
> Once again here's an attempt to put the shared files of x86_64 and i386
> into a separate directory.
OK, that's fine, but the next step is to have "make ARCH=x86" compile,
with a config option as to whether to build 32 or 64 bit. This wil
Bernhard Walle wrote:
Because the command line is increased to 2048 characters after 2.6.21,
it's not possible for boot loaders and userspace tools to determine the length
of the command line the kernel can understand. The benefit of knowing the
length is that users can be warned if the command l
This is an example about how to add eventfd support to the current KAIO code,
in order to enable KAIO to post readiness events to a pollable fd
(hence compatible with POSIX select/poll). The KAIO code simply signals
the eventfd fd when events are ready, and this triggers a POLLIN in the fd.
This pa
This patch implement the necessary compat code for the timerfd system call.
Signed-off-by: Davide Libenzi
- Davide
Index: linux-2.6.21-rc3.quilt/fs/compat.c
===
--- linux-2.6.21-rc3.quilt.orig/fs/compat.c 2007-03-15 15:53:1
This patch wire the timerfd system call to the x86_64 architecture.
Signed-off-by: Davide Libenzi
- Davide
Index: linux-2.6.21-rc3.quilt/arch/x86_64/ia32/ia32entry.S
===
--- linux-2.6.21-rc3.quilt.orig/arch/x86_64/ia32/ia32ent
This patch wire the eventfd system call to the x86_64 architecture.
Signed-off-by: Davide Libenzi
- Davide
Index: linux-2.6.21-rc3.quilt/arch/x86_64/ia32/ia32entry.S
===
--- linux-2.6.21-rc3.quilt.orig/arch/x86_64/ia32/ia32ent
This patch wire the eventfd system call to the i386 architecture.
Signed-off-by: Davide Libenzi
- Davide
Index: linux-2.6.21-rc3.quilt/arch/i386/kernel/syscall_table.S
===
--- linux-2.6.21-rc3.quilt.orig/arch/i386/kernel/syscal
> > > With a typical size as a fuzz factor preaccounted in later kernels.
> >
> > Where's that done?
>
> I don't know what Alan is referring to there.
fs/exec.c - we add 20 pages to the stack vma size initially.
> We've no more committed to providing each instance with 8MB of stack,
> than we'v
This patch wire the timerfd system call to the i386 architecture.
Signed-off-by: Davide Libenzi
- Davide
Index: linux-2.6.21-rc3.quilt/arch/i386/kernel/syscall_table.S
===
--- linux-2.6.21-rc3.quilt.orig/arch/i386/kernel/sysca
This patch wire the signalfd system call to the i386 architecture.
Signed-off-by: Davide Libenzi
- Davide
Index: linux-2.6.21-rc3.quilt/arch/i386/kernel/syscall_table.S
===
--- linux-2.6.21-rc3.quilt.orig/arch/i386/kernel/sysc
This is a very simple and light file descriptor, that can be used as
event wait/dispatch by userspace (both wait and dispatch) and by the
kernel (dispatch only). It can be used instead of pipe(2) in all cases
where those would simply be used to signal events. Their kernel overhead
is much lower tha
This patch implement the necessary compat code for the signalfd system call.
Signed-off-by: Davide Libenzi
- Davide
Index: linux-2.6.21-rc3.quilt/fs/compat.c
===
--- linux-2.6.21-rc3.quilt.orig/fs/compat.c 2007-02-04 10:44:
This patch add an anonymous inode source, to be used for files that need
and inode only in order to create a file*. We do not care of having an
inode for each file, and we do not even care of having different names in
the associated dentries (dentry names will be same for classes of file*).
This
This patch series implements the new signalfd() system call.
I took part of the original Linus code (and you know how
badly it can be broken :), and I added even more breakage ;)
Signals are fetched from the same signal queue used by the process,
so signalfd will compete with standard kernel delive
This patch introduces a new system call for timers events delivered
though file descriptors. This allows timer event to be used with
standard POSIX poll(2), select(2) and read(2). As a consequence of
supporting the Linux f_op->poll subsystem, they can be used with
epoll(2) too.
The system call is d
This patch wire the signalfd system call to the x86_64 architecture.
Signed-off-by: Davide Libenzi
- Davide
Index: linux-2.6.21-rc3.quilt/include/asm-x86_64/unistd.h
===
--- linux-2.6.21-rc3.quilt.orig/include/asm-x86_64/unist
On Thu, Mar 15, 2007 at 01:42:39PM +, Ian Campbell wrote:
> On Thu, 2007-03-15 at 18:56 +0530, Vivek Goyal wrote:
> >
> > Ideal place for this probably should have been arch dependent
> > crash_dump.h file. But we don't have one and no point introducing one
> > just for this macro.
>
> Agree
On Thu, Mar 15, 2007 at 06:56:16PM +0530, Vivek Goyal wrote:
> On Thu, Mar 15, 2007 at 12:22:57PM +, Ian Campbell wrote:
> > On Thu, 2007-03-15 at 11:17 +0530, Vivek Goyal wrote:
> > > > > But I think changing this macro might run into issues. It is
> > > > > being used at few places in kernel,
On Thursday, 15 March 2007 23:23, Andrew Morton wrote:
> On Thu, 15 Mar 2007 23:19:02 +0100 (CET)
> Jiri Kosina <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 15 Mar 2007, Andrew Morton wrote:
> >
> > > > > And why _does_ suspend use GFP_ATOMIC all over the place?
> > > > Generally, because it cannot s
On Thu, Mar 15, 2007 at 03:36:13PM -0700, Andrew Morton wrote:
>
> > > > > Is this the intended behaviour?
> > > >
> > > > That sounds like a bug to me.
> > >
> > > I'm suspecting it's an oddity rather than a bug.
> >
> > It is intended behaviour.
>
> Each instance of
>
> main()
> {
> s
Alon Bar-Lev wrote:
Hello,
I really don' t understand why you insist that the boot protocol
=2.02 had 255 limit!
Please remove this from the description.
You want to add size, that's OK, but please don't mess with previous
definitions.
Boot protocol 2.02 introduced the null terminated string t
On Thu, Mar 15, 2007 at 06:15:45PM -0500, Dave Kleikamp wrote:
> On Thu, 2007-03-15 at 23:59 +0100, Andrea Arcangeli wrote:
> > On Thu, Mar 15, 2007 at 05:44:01PM +, Hugh Dickins wrote:
> > > who removed the !offset condition, he should be consulted on its
> > > reintroduction.
> >
> > the !of
Andrew Morton wrote:
> Hopeless, sorry. It's probably time to start thinking about raising x86
> patches against the x86 tree (at least).
>
How's this?
J
Subject: Simplify smp_call_function*() by using common implementation
smp_call_function and smp_call_function_single are almost comp
On Thu, Mar 15, 2007 at 02:24:10PM -0700, Randy Dunlap wrote:
> On Thu, 15 Mar 2007 11:07:03 -0800 Andrew Morton wrote:
>
> >
> > There's way too much code here to expect it to get decently reviewed, alas.
>
> Yes.
>
> /me repeats wish that Not Everything Should Be Sent to lkml. :(
Just curio
On Thu, Mar 15, 2007 at 11:07:08AM -0800, Andrew Morton wrote:
> Looks OK, thanks.
>
> It would be nice as a followup patch to simply remove ucchar, uclong and
> all that gunk altogether from that driver and just use u8, u16 etc.
>
> But if you decide to do that, please fix your email client fir
On Thu, 2007-03-15 at 23:59 +0100, Andrea Arcangeli wrote:
> On Thu, Mar 15, 2007 at 05:44:01PM +, Hugh Dickins wrote:
> > who removed the !offset condition, he should be consulted on its
> > reintroduction.
>
> the !offset check looks a pretty broken heuristic indeed, it would
> break random
On Thu, Mar 15, 2007 at 03:06:01PM -0700, Andrew Morton wrote:
> On Thu, 15 Mar 2007 22:49:23 +0100
> Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Mar 15, 2007 at 11:07:35AM -0800, Andrew Morton wrote:
> > > > On Thu, 15 Mar 2007 01:22:45 -0400 (EDT) Ashif Harji <[EMAIL
> > > > PROTE
On Tue, Mar 13, 2007 at 06:12:44PM -0700, William Lee Irwin III wrote:
> There are furthermore distinctions to make between fork() and execve().
> fork() stomps over the entire process address space copying pagetables
> en masse. After execve() a process incrementally faults in PTE's one at
> a tim
On Thu, 15 Mar 2007, Andrew Morton wrote:
> On Thu, 15 Mar 2007 23:33:43 +
> Alan Cox <[EMAIL PROTECTED]> wrote:
>
> > > Stack RSS should certainly be included in Committed_AS,
> > > but RLIMIT_STACK merely limits how big the stack vma may grow to:
> > > at any moment the stack vma is probably
On Thu, 15 Mar 2007, Thomas Gleixner wrote:
> Davide,
>
> On Wed, 2007-03-14 at 15:19 -0700, Davide Libenzi wrote:
>
> > +static int timerfd_tmrproc(struct hrtimer *htmr)
> > +{
> > + struct timerfd_ctx *ctx = container_of(htmr, struct timerfd_ctx, tmr);
> > + int rval = HRTIMER_NORESTART;
>
Hi!
> > > > On Mon, 12 Mar 2007 22:19:20 +0100 "Rafael J. Wysocki" <[EMAIL
> > > > PROTECTED]> wrote:
> > > > +int create_basic_memory_bitmaps(void)
> > > > +{
> > > > + struct memory_bitmap *bm1, *bm2;
> > > > + int error = 0;
> > > > +
> > > > + BUG_ON(forbidden_pages_map || f
On Fri, Mar 16, 2007 at 07:25:53AM +1100, Nick Piggin wrote:
> I would just avoid the complexity and setup/teardown costs, and just
> use a vmalloc'ed global hash for NUMA.
This patch is not the way to go, but neither are vmalloc()'d global
hashtables. When you just happen to hash to the wrong nod
1 - 100 of 409 matches
Mail list logo
