Hi Linus.
On Fri, Feb 22, 2008 at 11:29:37AM +1100, James Morris wrote:
> I've been getting an immediate hang on boot since:
>
> e06b8b98da071f7dd78fb7822991694288047df0 kbuild: allow -fstack-protector to
> take effect
>
> This is on an x86_64 system (actually an Intel SDV -- so it might be
> "
yield_task_fair has some duplicate code, that can be replaced with
rb_last(). This code reuses rb_next and removes the duplicate code.
As a side effect, we don't do an rb_entry for each node as we walk
along the path.
Comments, flames?
Description
---
pick_task_entity() duplicates existi
(cc's added)
On Mon, 18 Feb 2008 21:09:22 -0500 "David M. Strang" <[EMAIL PROTECTED]> wrote:
> Greetings -
>
> A couple months back I purchased a LSI Logic MegaRAID ATA 150-4
> controller, as well as 3 Seagate 500GB SATA-II hard drives to use in my
> system. Previously, I was using a pair of W
Nick Andrew wrote:
> Rewrite the help descriptions for clarity, accuracy and consistency.
>
> Kernel config options affected:
>
> - NAMESPACES
> - UTS_NS
> - IPC_NS
> - USER_NS
> - PID_NS
>
> Signed-off-by: Nick Andrew <[EMAIL PROTECTED]>
Acked-by: Pavel Emelyanov <[EMAIL PROTECTED]>
On Tue, 19 Feb 2008 20:47:08 + Paul Martin <[EMAIL PROTECTED]> wrote:
> Now, this was working in 2.6.23, but is not in any later kernel. Previously
> reported, but I guess that the previous report was ignored due to the kernel
> being tainted.
Not really. A lot of acpi-related bug reports ge
Hi Max,
> [ ... ]
> Last patch to the stop machine is potentially unsafe and is marked as
> experimental. Unfortunately
> it's currently the only option that allows dynamic module insertion/removal
> for above scenarios.
I'm puzzled by the following part (can be a misunderstanding from my si
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
KaiGai,
I've just tried to build this with a separate obj tree: make O=/path.../
~ the build failed as follows:
~ CC security/dummy.o
~ CC security/inode.o
~ CAPSsecurity/cap_names.h
/bin/sh: security/../scripts/mkcapnames.sh: No su
On Fri, 2008-02-22 at 07:25 +0100, Nadia Derbey wrote:
> Subrata Modak wrote:
> >>Nadia Derbey wrote:
> >>
> >>>Matt Helsley wrote:
> >>>
> >>>
> On Tue, 2008-02-19 at 18:16 +0100, Nadia Derbey wrote:
>
>
>
> >+#define MAX_MSGQUEUES 16 /* MSGMNI as defined in linux/msg.
On Thu, 2008-02-21 at 20:02 -0500, Pavel Roskin wrote:
> Hello!
>
> What are the chances that incorrect tainting of ndiswrapper will be
> fixed in 2.6.25?
> Please let's not turn it into another empty discussion.
>
>
Seconded. Please.
--
Sorry for the disclaimer --- ¡I cannot stop it!
On Thu, 21 Feb 2008 17:41:05 +0100
Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
> From: Atsushi Nemoto <[EMAIL PROTECTED]>
>
> Fix NCFGR.SPD setting on 10Mbps. This bug was introduced by
> conversion to generic PHY layer in kernel 2.6.23.
>
> Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]>
>
On Fri, 2008-02-22 at 09:51 +0100, Thomas Renninger wrote:
> On Thu, 2008-02-21 at 19:46 +0100, Éric Piel wrote:
> > 12/02/08 06:37, Christoph Hellwig wrote/a écrit:
> > > [skipping the populate_rootfs discussion as it seems you have a better
> > > handle on that than me]
> > >
> > > On Sun, Feb
* Roland McGrath <[EMAIL PROTECTED]> wrote:
> Simple typo fix for regression introduced by the user_regset changes.
> - ret = putreg(target, pos, *k++);
> + ret = putreg32(target, pos, *k++);
> - ret = putreg(target, pos, word);
> +
On Tue, Feb 19, 2008 at 9:47 AM, Kay Sievers <[EMAIL PROTECTED]> wrote:
> On Feb 18, 2008 9:06 PM, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> > On Mon, 18 Feb 2008 19:42:25 + (GMT)
> > Chris Rankin <[EMAIL PROTECTED]> wrote:
> >
> > > --- Stephen Hemminger <[EMAIL PROTECTED]> wrote:
>
On Thu, Feb 21, 2008 at 10:29:09PM -0800, Junio C Hamano wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> > So I'd be happier with warnings about deep indentation (but how do you
> > count it? Will people then try to fake things out by using 4-space indents
> > and then "deep" indentation
>-Original Message-
>From: Roland McGrath [mailto:[EMAIL PROTECTED]
>Sent: Donnerstag, 21. Februar 2008 22:00
>Sorry I haven't replied in this thread sooner.
Thanks for your comments. I hope we get this resolved quickly.
>For the user-level interface, we should not be hasty with cookin
On Thu, 2008-02-21 at 19:46 +0100, Éric Piel wrote:
> 12/02/08 06:37, Christoph Hellwig wrote/a écrit:
> > [skipping the populate_rootfs discussion as it seems you have a better
> > handle on that than me]
> >
> > On Sun, Feb 10, 2008 at 12:58:09PM +0100, Eric Piel wrote:
> >>> And while we're at
* Dave Anderson <[EMAIL PROTECTED]> wrote:
> The 2.6.25 ptrace_bts_config structure in asm-x86/ptrace-abi.h is
> defined with u32 types:
thanks, applied.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More m
On Thu, 21 Feb 2008, Pioz wrote:
> I have a problem.
> I want handle the keyboard interrupt and for this purpose I have write
> this module (I have kernel 2.6.23):
[ ... ]
> res = request_irq (1, irq_myhandler, IRQF_SHARED, "bao", dev_id);
[ ... ]
> The return value of request_irq() func
Hi all,
I would like to be personally CC'ed the answers/comments posted to the
list in response to my posting.
I have following CPU
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Pentium(R) 4 CPU 3.00GHz
stepping: 1
cpu MHz :
* Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> > This is on an x86_64 system (actually an Intel SDV -- so it might be
> > "special").
>
> This is a regression. Can you please revert this commit. We can redo
> it wehn the -fstack-protector stuff are properly fixed in x86.
No!
James, could you ple
Al Viro wrote:
> On Fri, Feb 15, 2008 at 12:35:23PM +0100, Mikael Pettersson wrote:
>> Andi Kleen writes:
>> > Pavel Emelyanov <[EMAIL PROTECTED]> writes:
>> > >this subdir;
>> > > 3. sysctl inodes are now smaller than the procfs ones.
>> >
>> > That's always a good thing.
>> >
>> > >
> I'd been meaning to ask this. So the machines you have which don't
> describe 0xf as reserved also don't describe it as RAM? (I guess
> it's either a hole in the table or one of the other e820 types).
Making 0xf bus addresses RAM is probably a bad idea anyway. Most OS's
treat the E820 ma
* Balbir Singh <[EMAIL PROTECTED]> wrote:
> yield_task_fair has some duplicate code, that can be replaced with
> rb_last(). This code reuses rb_next and removes the duplicate code. As
> a side effect, we don't do an rb_entry for each node as we walk along
> the path.
thanks, applied.
--- Kay Sievers <[EMAIL PROTECTED]> wrote:
> Greg,
> it seems that:
> arch/x86/pci/legacy.c :: pci_legacy_init()
>
> tries to create already created "bridge" symlinks in 2.6.24. So we
> discover the same devices twice? Can this be a reason for the hang?
No, it can't be because it's *not* hangin
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
>> I'm not sure how we could detect pure Qemu instances - perhaps it
>> should define some special MSR or something?
>
> Perhaps they should fix the Qemu BIOS to actually simulate working
> MSRs; if nothing else, they should set up the default MTRR to
> Which is probably a good idea.
> AFAIK Numa, possibly Apic tables must be available quite early.
NUMA setup does not use the DSDT, but separate special tables
(SRAT/SLIT). It also doesn't require the ACPI interpreter, these
are all simple static tables.
-Andi
--
To unsubscribe from this list:
On Thu, 21 Feb 2008 20:02:55 -0500
Pavel Roskin <[EMAIL PROTECTED]> wrote:
> Hello!
>
> What are the chances that incorrect tainting of ndiswrapper will be
> fixed in 2.6.25? I'm worried that it still hasn't happened in the
> mainline repository. It's unfortunate to see that a long discussion
>
Al Viro writes:
> On Fri, Feb 15, 2008 at 12:35:23PM +0100, Mikael Pettersson wrote:
> > Andi Kleen writes:
> > > Pavel Emelyanov <[EMAIL PROTECTED]> writes:
> > > >this subdir;
> > > > 3. sysctl inodes are now smaller than the procfs ones.
> > >
> > > That's always a good thing.
Kohei KaiGai 写道:
> [2/3] Exporting capability code/name pairs
>
> This patch enables to export code/name pairs of capabilities the running
> kernel supported.
>
supported or supports ?
> A newer kernel sometimes adds new capabilities, like CAP_MAC_ADMIN
> at 2.6.25. However, we have no interfac
Hi Dave!
On Thursday 21 February 2008, David Brownell wrote:
> > David, do you think writing 0 bytes is a valid use of this API?
>
> Just a zero byte transfer ... no, though it depends what you mean
> by "valid". (I'm not sure I'd expect all controller drivers to
> reject such requests.) That h
The definitions of struct pci_device_id arrays should generally follow
the same pattern across the entire kernel. This macro defines this
array as const and puts it into the __devinitconst section.
There are currently many definitions scattered about the kernel that
omit the __devinitdata modifie
On Fri, Feb 22, 2008 at 12:03:50PM +1030, David Newall wrote:
> Greg KH wrote:
> > On Thu, Feb 21, 2008 at 10:00:58PM +0100, Willy Tarreau wrote:
> >
> >> I too agree to merge, it especially since it fixed several problems
> >> for David. However, I would like to know first if the same problems
> Actually I switched 64bit over to trust e820 completely and not
> reserve 640k-1MB explicitly some time ago
> and AFAIK there hasn't been any reports that it causes problems.
>
> So presumably trusting e802 is ok on modern systems (2003+)
Apparently so - at least 64bit capable ones. We do still
On Fri, 22 Feb 2008 09:48:28 +
Alan Cox <[EMAIL PROTECTED]> wrote:
> > Signed-off-by: Crane Cai <[EMAIL PROTECTED]>
> > Acked-by: Jeff Garzik <[EMAIL PROTECTED]>
> > Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
>
> Vomitted-upon-by: Alan Cox <[EMAIL PROTECTED]>
>
> > -
Alan Cox wrote:
>> Actually I switched 64bit over to trust e820 completely and not
>> reserve 640k-1MB explicitly some time ago
>> and AFAIK there hasn't been any reports that it causes problems.
>>
>> So presumably trusting e802 is ok on modern systems (2003+)
>
> Apparently so - at least 64bit c
>-Original Message-
>From: Ingo Molnar [mailto:[EMAIL PROTECTED]
>Sent: Freitag, 22. Februar 2008 10:53
>To: Metzger, Markus T
>> The ptrace API is the user interface for the debugging/BTS aspect of
>> it. As such, it will remain stable.
>
>your last patch does this to arch/x86/kernel/pt
On Fri, 22 Feb 2008 01:05:26 +0100
Krzysztof Halasa <[EMAIL PROTECTED]> wrote:
> Jeff Garzik <[EMAIL PROTECTED]> writes:
>
> > If a driver is full of lines of length >80, that's a problem.
>
> I'm not sure.
> We all have more than 80-chars wide displays for years, don't we? The
Even a vt132 ser
* Metzger, Markus T <[EMAIL PROTECTED]> wrote:
> The ptrace API is the user interface for the debugging/BTS aspect of
> it. As such, it will remain stable.
your last patch does this to arch/x86/kernel/ptrace.c:
266 insertions(+), 174 deletions(-)
doesnt that change the ptrace bits and the p
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
>> * H. Peter Anvin <[EMAIL PROTECTED]> wrote:
>>
I'm not sure how we could detect pure Qemu instances - perhaps it should
define some special MSR or something?
>>> Perhaps they should fix the Qemu BIOS to actually simula
> Signed-off-by: Crane Cai <[EMAIL PROTECTED]>
> Acked-by: Jeff Garzik <[EMAIL PROTECTED]>
> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
Vomitted-upon-by: Alan Cox <[EMAIL PROTECTED]>
> - if ((pdev->class >> 8) == PCI_CLASS_STORAGE_IDE) {
> - u8 tmp;
> +
Alan Cox wrote:
>> I'd been meaning to ask this. So the machines you have which don't
>> describe 0xf as reserved also don't describe it as RAM? (I guess
>> it's either a hole in the table or one of the other e820 types).
>
> Making 0xf bus addresses RAM is probably a bad idea anyway. Most
> > I've added locks in my test tree and now I've finally got -mm to build
> > will do some testing then push more stuff upstream
>
> Thanks. At the tty layer that was probably me.
> Most of the instances already appear to be nested in some other kind of
> locking, but that doesn't make no additi
Ingo Molnar wrote:
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
I'm not sure how we could detect pure Qemu instances - perhaps it
should define some special MSR or something?
Perhaps they should fix the Qemu BIOS to actually simulate working
MSRs; if nothing else, they should set up the default
Andrew G. Morgan wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
KaiGai,
I've just tried to build this with a separate obj tree: make O=/path.../
~ the build failed as follows:
~ CC security/dummy.o
~ CC security/inode.o
~ CAPSsecurity/cap_names.h
/bin/sh: security/../scr
Ingo Molnar wrote:
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
Ingo Molnar wrote:
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
I'm not sure how we could detect pure Qemu instances - perhaps it should
define some special MSR or something?
Perhaps they should fix the Qemu BIOS to actually simul
Mark Hounschell wrote:
> James Bottomley wrote:
>> On Thu, 2008-02-21 at 10:15 -0500, Mark Hounschell wrote:
>>> I seem to have run into some sort of regression in the SG_IO interface of
>>> 2.6.24.2.
>>> I have an application that up until 2.6.24 worked fine. The 2.6.23.16
>>> kernel works fine
* Glauber Costa <[EMAIL PROTECTED]> wrote:
> > Looks way overkill. Doesn't something like:
> > > struct create_idle create_idle = {
> > > - .work = __WORK_INITIALIZER(create_idle.work, do_fork_idle),
> > > .cpu = cpu,
> > > .done = COMPLETION_IN
Balbir Singh wrote:
> Andi Kleen wrote:
>>> 1. We could create something similar to mem_map, we would need to handle 4
>> 4? At least x86 mainline only has two ways now. flatmem and vmemmap.
>>
>>> different ways of creating mem_map.
>> Well it would be only a single way to create the "aux memory c
Hello Henk,
On Fri, Feb 22, 2008 at 10:36:01AM +0100, belcampo wrote:
> Kernel 2.6.22.9 smp hyperthreading
> BENCHMARKs: VC: 334.042s VO: 0.053s A: 0.000s Sys: 4.049s = 338.143s
> Kernel 2.6.22.9 nonsmp/hyperthreading
> BENCHMARKs: VC: 262.008s VO: 0.031s A: 0.000s Sys: 3.528s = 265.
On 02/22/2008 11:02 AM, Alan Cox wrote:
On Fri, 22 Feb 2008 09:48:28 +
Alan Cox <[EMAIL PROTECTED]> wrote:
Signed-off-by: Crane Cai <[EMAIL PROTECTED]>
Acked-by: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
Vomitted-upon-by: Alan Cox <[E
On Fri, 22 Feb 2008, Ingo Molnar wrote:
>
> * Sam Ravnborg <[EMAIL PROTECTED]> wrote:
>
> > > This is on an x86_64 system (actually an Intel SDV -- so it might be
> > > "special").
> >
> > This is a regression. Can you please revert this commit. We can redo
> > it wehn the -fstack-protector st
Andi Kleen <[EMAIL PROTECTED]> writes:
> On Wed, Feb 20, 2008 at 02:57:34PM +0100, Arne Georg Gleditsch wrote:
>> Hi,
>>
>> I'm looking at 2.6.25-rc2. vsyscall_sysctl_change contains code to NOP
>> out the actual system call instructions of the vsyscall page when
>> vsyscall64 is enabled. This s
Hello.
The bcm43xx driver won't work any more, if the b44 Ethernet
driver is enabled. This happens because the b44 driver
needlessly enables the b43_pci_bridge code, which claims
the same pci ids as the bcm43xx driver. The b43_pci_bridge
code is needed for the b43{legacy} drivers, but for the
b4
On Fri, Feb 22, 2008 at 08:42:15AM +0800, Jeff Chua wrote:
> On Fri, Feb 22, 2008 at 8:23 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
>
> > Your system (either your distro suspend/resume scripts or your platform)
> > must
> > be running the video BIOS at resume time, otherwise it would probably
> Either the test of port->tty here is unneeded:
>
> if (port->tty)
>port->tty->low_latency = low_latency;
>
> ...or the lack of test of port->tty here is a mistake:
>
>edge_set_termios (port, port->tty->termios);
Interesting - so coverity doesn't understand the BKL. It
On Fri, Feb 22, 2008 at 01:49:20PM +0800, Cai, Crane wrote:
> > On Thu, Feb 21, 2008 at 03:47:33PM -0800, Greg Kroah-Hartman wrote:
> > > +static void __devinit quirk_amd_ide_mode(struct pci_dev *pdev)
> > > {
> > > - /* set sb600 sata to ahci mode */
> > > - if ((pdev->class >> 8) == PCI_CLASS_ST
On Fri, 22 Feb 2008, Anders Eriksson wrote:
> I found this is a newly booted 2.6.25-rc2's syslog.
> Feb 21 20:46:33 tippex BUG: rwlock wrong owner on CPU#0, runscript.sh/2633,
> d2c04084
> Feb 21 20:46:33 tippex Pid: 2633, comm: runscript.sh Not tainted 2.6.25-rc2 #3
> Feb 21 20:46:33 tippex [] r
On Fri, Feb 22, 2008 at 11:00:44AM +0100, Ingo Molnar wrote:
>
> * H. Peter Anvin <[EMAIL PROTECTED]> wrote:
>
> > Ingo Molnar wrote:
> >> * H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> >>
> I'm not sure how we could detect pure Qemu instances - perhaps it should
> define some special M
Hi Jean,
>> +/*
>> + * Wait for patch from Jon Smirl
>> + * #include "powerpc-common.h"
>> + */
>
> It doesn't make sense to merge this comment upstream.
I know you don't like the patch from Jon Smirl and you also explained your
reasons.
Fortunately, I2c no longer uses numeric device IDs but na
I found this is a newly booted 2.6.25-rc2's syslog.
Feb 21 20:46:33 tippex BUG: rwlock wrong owner on CPU#0, runscript.sh/2633,
d2c04084
Feb 21 20:46:33 tippex Pid: 2633, comm: runscript.sh Not tainted 2.6.25-rc2 #3
Feb 21 20:46:33 tippex [] rwlock_bug+0x50/0x60
Feb 21 20:46:33 tippex [] _raw_wr
On Thu, Feb 21, 2008 at 11:54:00AM -0800, Yinghai Lu wrote:
> On Thu, Feb 21, 2008 at 6:50 AM, Joerg Roedel <[EMAIL PROTECTED]> wrote:
> > Inside a KVM virtual machine the MTRRs are usually blank. This confuses
> > Linux
> > and causes a warning message at boot. This patch removes that warning
>
Hi,
As paravirtualized xen guests won't work with !X86_PAE, change the Kconfig
accordingly.
Signed-off-by: Arnd Hannemann <[EMAIL PROTECTED]>
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 4d5f264..2035238 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -6,7 +6,7
On Fri, 2008-02-22 at 08:23 +0100, Thomas Gleixner wrote:
>
> + del_timer(&conn->info_timer);
> +
> hcon->l2cap_data = NULL;
> kfree(conn);
Shouldn't that be del_timer_sync() ?
--
dwmw2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
On Fri, 22 Feb 2008, David Woodhouse wrote:
> On Fri, 2008-02-22 at 08:23 +0100, Thomas Gleixner wrote:
> >
> > + del_timer(&conn->info_timer);
> > +
> > hcon->l2cap_data = NULL;
> > kfree(conn);
>
> Shouldn't that be del_timer_sync() ?
Hmm, probably yes.
tglx
--
To
On Thu, 2008-02-21 at 18:38 -0800, Max Krasnyanskiy wrote:
> As you suggested I'm sending CPU isolation patches for review/inclusion into
> sched-devel tree. They are against 2.6.25-rc2.
> You can also pull them from my GIT tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/maxk/cpuis
Max Krasnyanskiy <[EMAIL PROTECTED]> writes:
>
> static struct module *load_module(void __user *umod,
> unsigned long len,
> const char __user *uargs)
> {
> ...
>
> /* Now sew it into the lists so we can get lockdep and oop
On Thu, Feb 21, 2008 at 9:24 PM, Gordon Farquharson
<[EMAIL PROTECTED]> wrote:
> Hi Sam
>
>
> On Wed, Feb 20, 2008 at 12:37 PM, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
>
> > Option 1) is the worst of the three as that can cost
> > of many hours bug-hunting.
> > Option 3) may seem optimal but
Hi!
> > Does this fit what you had in mind?
>
> Yes it does.
>
> Now I'll ask if you think embedding this information in one of the C
> files for a module would be even nicer?
I kind of like to be able to grep over just Kconfig files, to find out
what is going on...
--
(english) http://www.liv
Hi!
> It's "snapshot-and-restore", and my opinion is that:
>
> - it should *never* call "suspend()"/"resume()" at all (that should be
>reserved purely for suspend-to-RAM and has real power management
>issues!)
Hmm, entering S4 seems like good place to call suspend() for... unless
you w
Steps to reproduce:
vi -t NETFILTER
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
Makefile |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/Makefile
+++ b/Makefile
@@ -1396,7 +1396,7 @@ define xtags
$(all-kconfigs) | xargs $1 -a \
Hi,
sorry that I step in so late, procmail sorted this thread in the wrong
box.
Normally I reserved the complete last week for working on mISDN to get it
ready to submit it to -mm, but reality did hit me and I had to do some
other importent stuff :-(
On Thu, Feb 21, 2008 at 11:33:04AM +0100, Simo
Yinghai Lu <[EMAIL PROTECTED]> writes:
> quad core 8 socket system will have apic id lifting.the apic id range could
> be [4, 0x23]. or [8, 0x27]. apic_is_clustered_box will think that need to
> three clusters
> and that is large than 2. So it is treated as clustered_box.
>
> and will get
>
> Mar
From: Jeff Dike <[EMAIL PROTECTED]>
Subject: Re: [PATCH 09/16] um: use get_personality()
Date: Wed, 20 Feb 2008 11:27:34 -0500
Message-ID: <[EMAIL PROTECTED]>
> On Wed, Feb 20, 2008 at 07:19:13PM +0800, WANG Cong wrote:
> > Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
>
> Looks good - you should
Both sig_ignored() and do_sigactoin() check for signr to be explicitly
or implicitly ignored. Introduce a helper for them.
This patch is aimed to help handling signals by pid namespace's
init, and was derived from one of Oleg's patches
https://lists.linux-foundation.org/pipermail/containers/2007-
* Joerg Roedel <[EMAIL PROTECTED]> wrote:
> > ok. Then i guess we should just leave the warning and the backtrace
> > in place until they get a fix done?
>
> No. I don't agree. The MTRRs are set up by the BIOS because it knows
> the hardware best (I know this is only true in theory). The OS sh
On Thu, Feb 21, 2008 at 01:58:19AM +0800, Herbert Xu wrote:
> On Wed, Feb 20, 2008 at 06:47:58PM +0100, Milan Broz wrote:
> >
> > I just tested one affected configuration and problem was in missing
> > "chainiv.ko" module on ramdisk.
>
> Ah OK. We probably should merge chainiv into the blkcipher
* James Morris <[EMAIL PROTECTED]> wrote:
> > works fine for you? That has all the current stackprotector fixes. I
> > plan to send a separate pull request with just the stackprotector
> > fixes to Linus, they are looking good in testing so far.
>
> Nope, same problem.
>
> (I followed your in
On Fri, Feb 22, 2008 at 2:46 AM, David Newall <[EMAIL PROTECTED]> wrote:
> Krzysztof Halasa wrote:
> > Perhaps we should increase line length limit, 132 should be fine.
> > Especially useful with long printk() lines and long arithmetic
> > expressions.
>
> Yes; or even longer. 80 characters mi
Andi Kleen wrote:
> Balbir Singh wrote:
>> Andi Kleen wrote:
1. We could create something similar to mem_map, we would need to handle 4
>>> 4? At least x86 mainline only has two ways now. flatmem and vmemmap.
>>>
different ways of creating mem_map.
>>> Well it would be only a single way t
Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> (*) I keed, I keed. Of *course* I'll have to fix things like this in the
> future too. But hopefully not quite as often.
The pragmatic solution would be to just fix the scripts to accept From
everywhere @)
-Andi
--
To unsubscribe from this list: sen
Daniel Phillips <[EMAIL PROTECTED]> wrote:
> > The way the client works is like this:
>
> Thanks for the excellent ascii art, that cleared up the confusion right
> away.
You know what they say about pictures... :-)
> > What are you trying to do exactly? Are you actually playing with it, or
> >
The signr variable may be declared without initialization -
it is set ro the return value from __dequeue_signal() right
at the function beginning.
Besides, after recalc_sigpending() two checks for signr to
be not 0 may be merged into one. Both if-s become easier
to read.
Thanks to Oleg for poin
On Thu, Feb 21, 2008 at 09:59:24PM +0100, Thomas Gleixner wrote:
> On Thu, 21 Feb 2008, Thomas Gleixner wrote:
> > > That or we need to do the NOP/un-NOP part in the update_vsyscall code
> > > dependent on if the current clocksource supports vread, instead of on
> > > the /proc entry access.
> >
>
On Fri, Feb 22, 2008 at 05:44:47PM +0530, Balbir Singh wrote:
>
> My concern with all the points you mentioned is that this solution might need
> to
> change again,
No why would it need to change again?
> depending on the factors you've mentioned. vmalloc() is good and
> straightforward, but it
On Fri, 22 Feb 2008, Ingo Molnar wrote:
>
> * James Morris <[EMAIL PROTECTED]> wrote:
>
> > > works fine for you? That has all the current stackprotector fixes. I
> > > plan to send a separate pull request with just the stackprotector
> > > fixes to Linus, they are looking good in testing so f
* Matthew Garrett <[EMAIL PROTECTED]> wrote:
> The s2ram command has a built-in whitelist used to set up video
> rePOSTing. If you want to test, reboot and do
>
> echo mem >/sys/power/state
>
> without i915 being loaded. If you get a console back on resume then
> the platform is reinitialisin
Casey Schaufler <[EMAIL PROTECTED]> wrote:
> > +static int smack_task_kernel_act_as(struct task_struct *p,
> > + struct task_security *sec, u32 secid)
> > +{
> > + return -ENOTSUPP;
> > +}
> ...
> > +static int smack_task_create_files_as(struct task_struct *p,
> > +
Sam Ravnborg ravnborg.org> writes:
>
> In at least 99% of the cases this is OK and the check has found
> several bugs where things would not have worked due to different
> alignmnet between kernel and userland. Just think about the
> issues in a mixed 32/64 bit world.
>
I don't see how this che
On Thu, Feb 21, 2008 at 08:45:53PM +0100, Thomas Gleixner wrote:
> On Thu, 21 Feb 2008, Andi Kleen wrote:
>
> > On Wed, Feb 20, 2008 at 02:57:34PM +0100, Arne Georg Gleditsch wrote:
> > > Hi,
> > >
> > > I'm looking at 2.6.25-rc2. vsyscall_sysctl_change contains code to NOP
> > > out the actual
[EMAIL PROTECTED] said:
> This needs to be CCed to netdev.
> Any chance that
> git revert 69cc64d8d92
> makes this report go away?
I'll have to install a git repo to check, or maybe you can send me the diff to
reverse vs. 2.6.25-rc2?
--
To unsubscribe from this list: send the line "unsu
Both function do the same thing after proper locking, but
with different sigpening structs, so move the common code
into a helper.
After this we have 4 places that look very similar:
send_sigqueue: calls do_send_sigqueue and signal_wakeup
send_group_sigqueue: calls do_send_sigqueue and __group_com
RFC: Update coding standard to avoid split up printk format strings
Common occurrence: You see some error message in the kernel log you don't
understand, Standard way to handle this is to grep the kernel source code
for that error message and then look at the code and figure out what
is wrong fro
On Fri, 22 Feb 2008, Gregory Haskins wrote:
> Gregory Haskins wrote:
> > @@ -732,14 +741,15 @@ rt_spin_lock_slowlock(struct rt_mutex *lock)
> >
> > debug_rt_mutex_print_deadlock(&waiter);
> >
> > - schedule_rt_mutex(lock);
> > + update_current(TASK_UNINTERRUPTIBLE,
* Gregory Haskins <[EMAIL PROTECTED]> wrote:
> My assumption is that the xchg() (inside update_current()) acts as an
> effective wmb(). If xchg() does not have this property, then this
> code is broken and patch 6/14 should also add a:
xchg() is a strong implicit memory barrier, it implies sm
On Fri, 2008-02-22 at 12:00 +0100, Arnd Hannemann wrote:
> As paravirtualized xen guests won't work with !X86_PAE, change the Kconfig
> accordingly.
Really? Xen guests should work on non-PAE if you have a non-PAE
hypervisor (which most distros don't ship but which does exist).
Ian.
--
Ian Camp
Peter Zijlstra wrote:
> On Thu, 2008-02-21 at 18:38 -0800, Max Krasnyanskiy wrote:
>
>> As you suggested I'm sending CPU isolation patches for review/inclusion into
>> sched-devel tree. They are against 2.6.25-rc2.
>> You can also pull them from my GIT tree at
>> git://git.kernel.org/pub/scm
On Fri, 2008-02-22 at 08:35 -0500, Steven Rostedt wrote:
> > My assumption is that the xchg() (inside update_current()) acts as an
> > effective wmb(). If xchg() does not have this property, then this code
> > is broken and patch 6/14 should also add a:
> >
> >
> > + smp_wmb();
>
On Fri, 22 Feb 2008, Ingo Molnar wrote:
>
> * Gregory Haskins <[EMAIL PROTECTED]> wrote:
>
> > My assumption is that the xchg() (inside update_current()) acts as an
> > effective wmb(). If xchg() does not have this property, then this
> > code is broken and patch 6/14 should also add a:
>
> xchg
Gregory,
I guess we should have just read Documentation/memory-barriers.text
Here's the snippet:
Any atomic operation that modifies some state in memory and returns
information
about the state (old or new) implies an SMP-conditional general memory
barrier
(smp_mb()) on each side of the actual
Gregory Haskins wrote:
@@ -732,14 +741,15 @@ rt_spin_lock_slowlock(struct rt_mutex *lock)
debug_rt_mutex_print_deadlock(&waiter);
- schedule_rt_mutex(lock);
+ update_current(TASK_UNINTERRUPTIBLE, &saved_state);
I have a question for everyone out there about this particula
1 - 100 of 562 matches
Mail list logo
