On Wed, 2007-10-24 at 18:11 +0200, Peter Zijlstra wrote:
> On Wed, 2007-10-24 at 17:55 +0200, Ingo Molnar wrote:
> >
> > hm, this lockdep warning caused lockdep to turn itself off - hence we
> > wont get to the really interesting warnings. We'll try to come up with a
> > solution for this.
>
Just a heads up that we will now finally start to submit CRIS patches.
The first patches will make CRIS compile in the official tree. Further
patches will then add functionality and correct bugs.
A new machine called Artpec-3 will also be added.
/Mikael and Jepser
-
To unsubscribe from this
On 10/25/07, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Thu, 25 Oct 2007 18:53:18 -0700 Yinghai Lu wrote:
>
> > On 10/25/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> > > From 6654a98eb8587f0538904c9bdb9aeaf9d577f182 Mon Sep 17 00:00:00 2001
> > > From: Sam Ravnborg <[EMAIL PROTECTED]>
> > >
On Thu, Oct 25, 2007 at 11:03:51PM -0600, Robert Hancock wrote:
> Greg KH wrote:
>> On Thu, Oct 25, 2007 at 04:22:35PM -0700, Jesse Barnes wrote:
>>> I think Greg doesn't like it, even though we don't have an alternative at
>>> this point...
>> Yes, I didn't like it, Ivan didn't like it, and I
Ok lets get to a good point.
Lets define a key bit. What is a good software security lock?
My define is that its available to be used everywhere its needed and
when ever its need without flaw.
This is where most LSM fall in a heap. Because you have to have the
LSM loaded to have its security
On Thu, 25 Oct 2007 22:03:21 -0700 "Russ Dill" <[EMAIL PROTECTED]> wrote:
> > > Format: [schedule,]
> > > Param: "schedule" - profile schedule points.
> > > Param: - step/bucket size as a power of 2
> > > for
> > > -
Hi,
This patch adds the symbol "init_level4_pgt" to the vmcoreinfo data so
that makedumpfile (dump filtering command) supports x86_64 sparsemem
kernel of linux-2.6.24.
makedumpfile creates a small dumpfile by excluding unnecessary pages for
the analysis. It checks attributes in page structures
Perhaps have an sb_alloc function and a failure mode that
uses printk when sb_alloc fails or sb_append is passed null?
Perhaps something like:
stringbuf *sb_alloc(char* level, gfp_t priority)
{
stringbuf *sb = kmalloc(sizeof(*sb), priority);
if (sb)
sb>len =
On Thu, Oct 25, 2007 at 04:53:18PM -0700, Jesse Barnes wrote:
> Ok, here's yet another version that uses the device model for the
> suspend/resume, rather than pci hooks.
>
> Greg, DRM desperately needs review of its device model usage, can you
> take a look at this patch and the current
On Fri, Oct 26, 2007 at 01:42:37AM +0200, Andi Kleen wrote:
> On Friday 26 October 2007 01:32:53 Linus Torvalds wrote:
> >
> > On Fri, 26 Oct 2007, Andi Kleen wrote:
> > >
> > > No it can't (at least not on x86) as I have explained in the rest of the
> > > mail
> > > you conveniently snipped.
On 10/25/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Tue, 16 Oct 2007 22:16:47 -0700
> "Russ Dill" <[EMAIL PROTECTED]> wrote:
>
> > Be more explicit on what the step/bucket size accomplishes.
> >
> > Signed-off-by: Russ Dill <[EMAIL PROTECTED]>
> > ---
> >
Greg KH wrote:
On Thu, Oct 25, 2007 at 04:22:35PM -0700, Jesse Barnes wrote:
I think Greg doesn't like it, even though we don't have an alternative
at this point...
Yes, I didn't like it, Ivan didn't like it, and I got reports that it
wasn't even needed at all once you upgraded your BIOS to
Linus Torvalds writes:
> Nobody should *ever* walk the list to find the length. Does anybody really
> do that? Yes, we pass the thing down, but do people *need* it?
Yes, I need it for devices that use the macintosh DBDMA
(descriptor-based DMA) hardware. The DBDMA hardware reads an array of
On Fri, Oct 26, 2007 at 10:57:45AM +0800, Wang, Baojun wrote:
>hi, list
>
> I've upgraded my kernel from 2.6.22.9 to 2.6.23 when it was out, After that
>I can't install ELDK 4.1 anymore (The one I installed was crashed), it always
>stopped at preparing install package XXX (or YYY sometimes),
On 10/26/07, Greg KH <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 26, 2007 at 11:11:22AM +0800, Dave Young wrote:
> > On 10/26/07, Greg KH <[EMAIL PROTECTED]> wrote:
> > > > Anyway the sysfs_dirent_exist is useful for extern use, How about add
> > > > and export this function? Greg, If you agree, I
David wrote:
> I think that documenting the change in the man page as saying that
> "the nodemask will include all allowed nodes if the mems_allowed
> of a memory_spread_user cpuset is expanded" is better.
Ok. I'm inclined the other way, but not certain enough of my
position to push the point
On Fri, 2007-10-26 at 13:47 +1000, Nick Piggin wrote:
> I don't think the previous code was wrong... it's not a locked section
> > and we don't care about ordering previous stores. It's an
> allocation, it
> > should be fine. In general, bitmap allocators should be allright.
>
> Well if it is
On Thu, Oct 25, 2007 at 04:30:48PM -0700, Yinghai Lu wrote:
> > config EARLY_PRINTK
> > bool "Early printk" if EMBEDDED && DEBUG_KERNEL
> > default y
> > + depends on X86_32
> > help
> > Write kernel log output directly into the VGA buffer or to a
> >
From: Randy Dunlap <[EMAIL PROTECTED]>
Coding style cleanups in x86/bitops_32.h:
- drop space in "* addr"
- whitespace & indentation fixes
- spello fixes
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
include/asm-x86/bitops_32.h | 48 ++--
1 file
Huang, Ying wrote:
- 3 files: efi.c, efi_32.c, efi_64.c, common code goes in efi.c, EFI
32/64 specific code goes in efi_32/64.c. This will make some variable,
function external instead of static.
This is preferred.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe
On Fri, Oct 26, 2007 at 11:11:22AM +0800, Dave Young wrote:
> On 10/26/07, Greg KH <[EMAIL PROTECTED]> wrote:
> > > Anyway the sysfs_dirent_exist is useful for extern use, How about add
> > > and export this function? Greg, If you agree, I would send it as
> > > another patch.
> >
> > What would
On Fri, 26 Oct 2007 05:56:49 +0200
Bodo Eggert <[EMAIL PROTECTED]> wrote:
> Rik van Riel <[EMAIL PROTECTED]> wrote:
> > On Thu, 25 Oct 2007 16:20:41 +0100
> > Richard Purdie <[EMAIL PROTECTED]> wrote:
>
> >> Advice on solving this welcome preferably in mainline but I'll
> >> happily hack my
Tejun Heo wrote:
> [please don't drop cc. restored]
>
> Steen Eugen Poulsen wrote:
> >Tejun Heo skrev:
> >>All these are caused by smartd. Updating should fix the problem.
> >
> >Okay, but there is no newer smartd than what I'm using. (5.37)
>
> Bruce? Original thread can be read from...
>
>
On Thursday 25 October 2007 4:55:07 pm Thomas Renninger wrote:
> On Thu, 2007-10-25 at 09:06 -0600, Bjorn Helgaas wrote:
> > Isn't the real problem that we have a bunch of drivers that use some of
> > the same resources, and if ACPI reserved all the right resources, all
> > those drivers would
On Thu, 25 Oct 2007, Paul Jackson wrote:
> The user space man pages for set_mempolicy(2) are now even more
> behind the curve, by not mentioning that MPOL_INTERLEAVE's mask
> might mean nothing, if (1) in a cpuset marked memory_spread_user,
> (2) after the cpuset has changed 'mems'.
>
Yeah.
Rik van Riel <[EMAIL PROTECTED]> wrote:
> On Thu, 25 Oct 2007 16:20:41 +0100
> Richard Purdie <[EMAIL PROTECTED]> wrote:
>> Advice on solving this welcome preferably in mainline but I'll happily
>> hack my kernels with a workaround if need be.
>
> I can't see any easy hacks or workarounds to fix
On Friday 26 October 2007 13:35, Benjamin Herrenschmidt wrote:
[acks]
Thanks for those...
> > Index: linux-2.6/include/asm-powerpc/mmu_context.h
> > ===
> > --- linux-2.6.orig/include/asm-powerpc/mmu_context.h
> > +++
On Fri, 2007-10-26 at 12:11 +1000, Rusty Russell wrote:
> On Thursday 25 October 2007 05:59:49 Matthew Wilcox wrote:
> > Consecutive calls to printk are non-atomic, which leads to various
> > implementations for accumulating strings which can be printed in one call.
> > This is a generic string
On Thu, 25 Oct 2007, Alan Cox wrote:
There is a ton of evidence both in computing and outside of it which
shows that poor security can be very much worse than no security at all.
(So, I take it that you *don't* lock your bike up, as poor security is
worse than none?)
On the contrary because
On Thu, 25 Oct 2007 13:40:44 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > Now rc1 is released. Any chances for this patch?
> > If none, I should push other workaround to fix this issue on 2.6.24.
>
> I don't know what patch you're referring to. I don't appear to have
>
On Fri, Oct 26, 2007 at 01:09:14AM +0200, Tilman Schmidt wrote:
> Am 25.10.2007 00:31 schrieb Adrian Bunk:
> > Generally, the goal is to get external modules included into the kernel.
> > [...] even though it might sound harsh breaking
> > external modules and thereby making people aware that
> Index: linux-2.6/arch/powerpc/mm/hash_native_64.c
> ===
> --- linux-2.6.orig/arch/powerpc/mm/hash_native_64.c
> +++ linux-2.6/arch/powerpc/mm/hash_native_64.c
> @@ -113,7 +113,7 @@ static inline void native_lock_hpte(stru
>
On Thu, 2007-10-25 at 18:09 +0200, Thomas Gleixner wrote:
> 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.
>
Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> I think the last remaining bit to cleanup is the symlink from
> arch/x86/boot/bzImage.
BTW: Is it useful to have (b)zimage under $ARCH while vmlinux is in the root
dir? (Besides being compatible to external scripts)
--
I always tell customers/clients
On Thu, Oct 25, 2007 at 04:22:35PM -0700, Jesse Barnes wrote:
> I think Greg doesn't like it, even though we don't have an alternative
> at this point...
Yes, I didn't like it, Ivan didn't like it, and I got reports that it
wasn't even needed at all once you upgraded your BIOS to the latest
On 10/25/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> This patch removes the unused mm_{ptov,vtop}().
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> ---
>
> include/asm-blackfin/io.h |2 --
Acked-by: Bryan Wu <[EMAIL PROTECTED]>
Thanks a lot
> include/asm-h8300/io.h
David wrote:
> - tmp = cpuset_mems_allowed(current);
> + tmp = *newmask;
I see this as a nice little optimization, not a change in
what the code does. That is, *newmask happens to already
hold cpuset_mems_allowed(current), so can be used for such.
Is that
David wrote:
> Yes, when using cpusets for resource control. If memory pressure is being
> felt for that cpuset and additional mems are added to alleviate possible
> OOM conditions, it is insufficient to allow tasks within that cpuset to
> continue using memory policies that prohibit them from
On 10/26/07, Greg KH <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 26, 2007 at 10:01:49AM +0800, Dave Young wrote:
> > On 10/26/07, Greg KH <[EMAIL PROTECTED]> wrote:
> > > On Thu, Oct 25, 2007 at 05:06:59PM +0800, Dave Young wrote:
> > > > On 10/19/07, Greg KH <[EMAIL PROTECTED]> wrote:
> > > > >On
On Thu, 25 Oct 2007 04:06:13 -0400 (EDT)
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> The __deprecated marker is quite useful in highlighting the remnants
> of old APIs that want removing.
>
> However, it is quite normal for one or more years to pass, before the
> (usually ancient, bitrotten) code
hi, list
I've upgraded my kernel from 2.6.22.9 to 2.6.23 when it was out, After that
I can't install ELDK 4.1 anymore (The one I installed was crashed), it always
stopped at preparing install package XXX (or YYY sometimes), I've waited for
a very long time(more than 1 hour), but it still the
Jeff Garzik wrote:
> Andrey Borzenkov wrote:
>> Jeff Garzik wrote:
>>
>>> * Asynchronous notification -- finally userspace CD-ROM polling can go
>>> away!
>>> (NOTE: waiting on James B to apply the piece that actually makes this
>>> work...)
>>
>> Does it depend on hardware offering suitable
On 10/25/07, Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> On 10/25/2007 07:10 PM, john stultz wrote:
> >
> > What was the last kernel version you were using that didn't show the issue?
> > Couple of things to try below:
> >
> >
> > Could you disable CONFIG_HANGCHECK_TIMER in your .config? Just to
>
On Friday 26 October 2007 10:21:21 Jeff Garzik wrote:
> Linux Kernel Mailing List wrote:
> > lguest: Add to maintainers file.
> thanks for adding this!
Glad to make you happy: TBH it hadn't occurred to me until you mentioned it
oh-so-subtly. MAINTAINERS seems something of a relic these
On Fri, Oct 26, 2007 at 10:01:49AM +0800, Dave Young wrote:
> On 10/26/07, Greg KH <[EMAIL PROTECTED]> wrote:
> > On Thu, Oct 25, 2007 at 05:06:59PM +0800, Dave Young wrote:
> > > On 10/19/07, Greg KH <[EMAIL PROTECTED]> wrote:
> > > >On Wed, Oct 17, 2007 at 10:48:52AM -0400, Alan Stern wrote:
> >
On Thu, 25 Oct 2007 18:53:18 -0700 Yinghai Lu wrote:
> On 10/25/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> > From 6654a98eb8587f0538904c9bdb9aeaf9d577f182 Mon Sep 17 00:00:00 2001
> > From: Sam Ravnborg <[EMAIL PROTECTED]>
> > Date: Thu, 25 Oct 2007 21:04:16 +0200
> > Subject: [PATCH] x86:
David wrote:
> + if (pol->policy != MPOL_DEFAULT)
Good catch - thanks.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401
-
To unsubscribe from this list: send the line
On Thu, 25 Oct 2007, Paul Jackson wrote:
> Are you seeing this in a real world situation? Can you describe the
> situation? I don't mean just describing how it looks to this kernel
> code, but what is going on in the system, what sort of job mix or
> applications, what kind of users, ... In
On Thu, Oct 25, 2007 at 06:46:54PM -0700, David Miller wrote:
>
> Since I keep hitting this when I try to test IPSEC on my systems
> I'm going to apply this to my net-2.6 tree.
>
> Herbert, I hope you don't mind :-)
It looks good to me. Thanks Dave!
--
Visit Openswan at
Instead of using current's mems_allowed, which may differ from the
mems_allowed of the cpuset being updated, the newmask passed to
mpol_rebind_mm() is used as the interleave mask in the
memory_spread_user case.
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: Paul Jackson <[EMAIL PROTECTED]>
Cc: Christoph
> Yes, when a task with MPOL_INTERLEAVE has its cpuset mems_allowed expanded
> to include more memory. The task itself can't access all that memory with
> the memory policy of its choice.
That much I could have guessed (did guess, actually.)
Are you seeing this in a real world situation? Can
On Thu, 2007-10-25 at 15:29 -0700, H. Peter Anvin wrote:
> Eric W. Biederman wrote:
> > "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
Matthew Wilcox wrote:
On Thu, Oct 25, 2007 at 10:07:17PM -0400, Jeff Garzik wrote:
Is this warning of value to anybody but you?
Yup. It signals this driver isn't production quality yet.
Is this information worth printing out on everyone else's kernel build?
I thnk that's worth noting to
Hi,
Just out of interest, I did a grep for files containing test_and_set_bit
as well as clear_bit (excluding obvious ones like include/asm-*/bitops.h).
Quite a few interesting things. There is a lot of stuff in drivers/* that
could be suspect, WRT memory barriers, including lots I didn't touch.
Adds a new 'memory_spread_user' option to cpusets.
When a task with an MPOL_INTERLEAVE memory policy is attached to a cpuset
with this option set, the interleaved nodemask becomes the cpuset's
mems_allowed. When the cpuset's mems_allowed changes, the interleaved
nodemask for all tasks with
On Thu, 2007-10-25 at 13:36 -0700, H. Peter Anvin wrote:
> 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
Extract a helper function from update_nodemask() to load an array of
mm_struct pointers with references to each task's mm_struct that is
currently attached to a given cpuset.
This will be used later for other purposes where memory policies need to
be rebound for each task attached to a cpuset.
Set the memory policy nodemask to the new nodemask on rebind only in one
place. The only memory policy that does not need an associated mpolmask
is MPOL_DEFAULT.
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: Christoph Lameter <[EMAIL PROTECTED]>
Cc: Lee Schermerhorn <[EMAIL PROTECTED]>
Signed-off-by:
On Thu, Oct 25, 2007 at 10:07:17PM -0400, Jeff Garzik wrote:
> Is this warning of value to anybody but you?
Yup. It signals this driver isn't production quality yet.
> Is this information worth printing out on everyone else's kernel build?
I thnk that's worth noting to anyone who's enabled it.
On 10/24/07, Ralf Baechle <[EMAIL PROTECTED]> wrote:
> Nothing should ever include this file.
>
> Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
>
> arch/blackfin/mach-common/interrupt.S |1 -
> arch/blackfin/mm/blackfin_sram.c |1 -
Acked, thanks Ralf
-Bryan
>
On Thu, 25 Oct 2007, Paul Jackson wrote:
> David - could you describe the real world situation in which you
> are finding that this new 'interleave_over_allowed' option, aka
> 'memory_spread_user', is useful? I'm not always opposed to special
> case solutions; but they do usually require special
On Thursday 25 October 2007 05:59:49 Matthew Wilcox wrote:
> Consecutive calls to printk are non-atomic, which leads to various
> implementations for accumulating strings which can be printed in one call.
> This is a generic string buffer which can also be used for non-printk
> purposes. There is
On Thu, 2007-10-25 at 11:30 -0600, Eric W. Biederman wrote:
> "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
Richard Purdie wrote:
I've got a problem I keep running into. My computers have buggy software
which can sometimes run out of control.
Ulimit them.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Matthew Wilcox wrote:
drivers/scsi/advansys.c:71:2: warning: #warning this driver is still
not properly converted to the DMA API
I'll be removing this #warning from advansys when I get rid of the
last bus_to_virt. Which I've already done ... it's just that the
resulting driver works on
On Thursday October 25, [EMAIL PROTECTED] wrote:
> On Mon, 22 Oct 2007, Pekka Enberg wrote:
> > On 10/22/07, Hugh Dickins <[EMAIL PROTECTED]> wrote:
> > > Only ramdisk and shmem have been returning AOP_WRITEPAGE_ACTIVATE.
> > > Both of those set BDI_CAP_NO_WRITEBACK. ramdisk never returned it
> >
On 10/26/07, Greg KH <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 25, 2007 at 05:06:59PM +0800, Dave Young wrote:
> > On 10/19/07, Greg KH <[EMAIL PROTECTED]> wrote:
> > >On Wed, Oct 17, 2007 at 10:48:52AM -0400, Alan Stern wrote:
> > >> On Tue, 16 Oct 2007, Matthew Dharm wrote:
> > >>
> > >> > On
Andi wrote:
> When a bitmap is empty bitmap_scnlistprintf would leave the buffer
> uninitialized.
> Set it to an empty string in this case.
Acked-by: Paul Jackson <[EMAIL PROTECTED]>
--
I won't rest till it's the best ...
Programmer, Linux Scalability
On 10/25/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> Randy Dunlap wrote:
> >
> > It doesn't do that. EARLY_PRINTK for x86_64 lives in
> > arch/x86_64/Kconfig (i.e., a different file).
> >
> > Patches welcome.
> >
>
> I think Sam's patchset already takes care of that.
Paul M wrote:
> -LL=cgroup_mutex
> +(cgroup_mutex held by caller)
Thanks.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401
-
To unsubscribe from this list: send the line
Christoph wrote:
> With that MPOL_INTERLEAVE would be context dependent and no longer
> needs translation. Lee had similar ideas. Lee: Could we make
> MPOL_INTERLEAVE generally cpuset context dependent?
Well ... MPOL_INTERLEAVE already is essentially cpuset relative.
So long as the cpuset size
On 10/25/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> From 6654a98eb8587f0538904c9bdb9aeaf9d577f182 Mon Sep 17 00:00:00 2001
> From: Sam Ravnborg <[EMAIL PROTECTED]>
> Date: Thu, 25 Oct 2007 21:04:16 +0200
> Subject: [PATCH] x86: move i386 and x86_64 Kconfig files to x86 directory
>
> After a
From: Vlad Yasevich <[EMAIL PROTECTED]>
Date: Thu, 25 Oct 2007 16:07:17 -0400
> Crypto now uses SG helper functions. Fix hmac_digest to use those
> functions correctly and fix the oops associated with it.
>
> Signed-off-by: Vlad Yasevich <[EMAIL PROTECTED]>
Since I keep hitting this when I try
Move cgroups destroy() callbacks to cgroup_diput()
Move the calls to the cgroup subsystem destroy() methods from
cgroup_rmdir() to cgroup_diput(). This allows control file reads and
writes to access their subsystem state without having to be concerned
with locking against cgroup destruction -
When a bitmap is empty bitmap_scnlistprintf would leave the buffer
uninitialized.
Set it to an empty string in this case.
I didn't see any in normal kernel callers hitting this, but some custom debug
code of mine did.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Index:
[please don't drop cc. restored]
Steen Eugen Poulsen wrote:
Tejun Heo skrev:
All these are caused by smartd. Updating should fix the problem.
Okay, but there is no newer smartd than what I'm using. (5.37)
Bruce? Original thread can be read from...
Hi LKML,
My computer running kernel 2.6.23 does not "hibernate" (suspend to disk
using
the kernel's methods) with a program (named stringTest) running in gdb, but
has received a SIGABRT.
The hibernate is successful when running kernel 2.6.22.7 !
Here is the message from gdb:
pj wrote:
> Check out the assembly code generated by:
>
> BUG_ON(sizeof(cgrp->root->release_agent_path) < PATH_MAX));
>
> (Hint: you can't find it ;)
>
> It -is- compile time!
To be clear, BUG_ON() in general is a runtime check.
But the compiler can optimize out constant expressions,
and
On Thu, Oct 25, 2007 at 06:24:25PM -0700, Paul Jackson wrote:
> Paul M wrote:
> > Sounds reasonable to me. Is there any kind of compile-time assert
> > macro in the kernel?
>
> Check out the assembly code generated by:
>
> BUG_ON(sizeof(cgrp->root->release_agent_path) < PATH_MAX));
>
>
On Thu, 25 Oct 2007, Paul Jackson wrote:
> Can we call this "memory_spread_user" instead, or something else
> matching "memory_spread_*" ?
>
Sounds better. I was hoping somebody was going to come forward with an
alternative that sounded better than interleave_over_allowed.
> How
On Thu, 2007-10-25 at 11:06 -0600, Eric W. Biederman wrote:
> 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
>
On 10/25/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
> Paul M wrote:
> > Sounds reasonable to me. Is there any kind of compile-time assert
> > macro in the kernel?
>
> Check out the assembly code generated by:
>
> BUG_ON(sizeof(cgrp->root->release_agent_path) < PATH_MAX));
>
> (Hint: you can't
On 10/23/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
>
> agreed, we need to be reporting idle time in (milli)seconds, although
> the requirement we had was to report it back in percentage. I guess the
> percentage figure can be derived from the raw idle time number.
>
> How about:
>
>
Bartlomiej Zolnierkiewicz wrote:
On Thursday 25 October 2007, Jeff Garzik wrote:
Store our hwif indices at probe time, in order to eliminate a needless
and ugly loop across all hwifs, searching for our pci device.
It seems that we can simplify it even further and remove knowledge about
hwifs
Paul M wrote:
> Sounds reasonable to me. Is there any kind of compile-time assert
> macro in the kernel?
Check out the assembly code generated by:
BUG_ON(sizeof(cgrp->root->release_agent_path) < PATH_MAX));
(Hint: you can't find it ;)
It -is- compile time!
--
I won't
On Thu, Oct 25, 2007 at 04:41:55PM -0700, Tim Bird wrote:
> Matt Mackall wrote:
> > On Thu, Oct 25, 2007 at 03:52:28PM -0700, Tim Bird wrote:
> >> Mathieu Desnoyers wrote:
> >>> It might help to read this thread I posted on LKML in January 2006
> >>> explaining the problem, which led to some
On Thu, Oct 25, 2007 at 06:10:24PM -0700, Paul Menage wrote:
> On 10/24/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
> > Paul M wrote:
> > > I think I'd rather not make this change - if we later changed the size
> > > of release_agent_path[] this could silently fail. Can we get around
> > > the
On Thu, 2007-10-25 at 16:57 -0700, Linus Torvalds wrote:
>
> On Fri, 26 Oct 2007, Andi Kleen wrote:
> >
> > The conditional add/sub using carry trick is not generally bogus.
> > But for registers it's a fine optimization.
>
> For registers it's fine. For memory, it's a disaster. It's more than
On 10/24/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
> From: Paul Jackson <[EMAIL PROTECTED]>
>
> Coding style fix - one line conditionals don't get braces.
>
> Signed-off-by: Paul Jackson <[EMAIL PROTECTED]>
Not a coding style that I'm in favor of, but I suppose it is the
kernel standard.
On 10/24/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
> From: Paul Jackson <[EMAIL PROTECTED]>
>
> Simplify the space stripping code in cgroup file write.
>
> Signed-off-by: Paul Jackson <[EMAIL PROTECTED]>
Acked-by: Paul Menage <[EMAIL PROTECTED]>
>
> ---
>
> This patch applies after both:
>
On Thu, 2007-10-25 at 11:01 -0600, Eric W. Biederman wrote:
> > +static efi_status_t __init phys_efi_set_virtual_address_map(
> > + unsigned long memory_map_size,
> > + unsigned long descriptor_size,
> > + u32 descriptor_version,
> > + efi_memory_desc_t *virtual_map)
> > +{
> > +
I'm probably going to be ok with this ... after a bit.
1) First concern - my primary issue:
One thing I really want to change, the name of the per-cpuset file
that controls this option. You call it "interleave_over_allowed".
Take a look at the existing per-cpuset file names:
On 10/24/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
> Paul M wrote:
> > I think I'd rather not make this change - if we later changed the size
> > of release_agent_path[] this could silently fail. Can we get around
> > the coverity checker somehow?
>
> Perhaps we can simplify this check then, to:
On Thu, 2007-10-25 at 18:09 +0200, Thomas Gleixner wrote:
> > EFI runtime
> > services initialization are implemented in efi.c. Some x86_64
> > specifics are worth noting here. On x86_64, parameters passed to UEFI
> > firmware services need to follow the UEFI calling convention. For this
> >
Karsten Keil wrote:
On Thu, Oct 25, 2007 at 04:06:16AM -0400, Jeff Garzik wrote:
drivers/isdn/capi/capidrv.c: In function 'if_sendbuf':
drivers/isdn/capi/capidrv.c:1865: warning: cast from pointer to integer
of different size
We are passing a kernel pointer, skb->data, but the interface itself
>>> Steven Rostedt <[EMAIL PROTECTED]> 10/25/07 8:03 PM >>>
>
>> Why do you think moving the logic to pick_next_highest is a better
>> design? To be honest, I haven't really studied your new logic in
>> push_rt_tasks to understand why you might feel this way. If you can
>> make the case that it
Signed-off-by: Brian Gerst <[EMAIL PROTECTED]>
---
include/asm-x86/cpufeature.h| 185 ++-
include/asm-x86/cpufeature_32.h | 176 -
include/asm-x86/cpufeature_64.h | 30 --
3 files changed, 183 insertions(+), 208
Alan Cox wrote:
On Fri, 26 Oct 2007 01:36:37 +0200
Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
Need to check if the host is a PCI one before reading IDE_ALTSTATUS_REG.
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
Umm why ? The altstatus register goes back to ST-506
> I found Chris's comment about negative block numbers, I'll send a patch
> out for that.
>
> You mentioned back in 99 about racing with ftruncate. Is it sufficient
> to mutex_lock(i_mutex) and down_read(i_alloc_sem)?
One for the fs guys. That code has changed far beyond anything I
understand
On Thu, Oct 25, 2007 at 02:46:17PM -0400, Jun'ichi Nomura wrote:
> So as far as I understand, the point is:
> 1. it's preferable to resize inode after the resume, if possible
Not quite - I'm not expressing a preference yet.
I'm saying the patches you presented were one option to resolve the
1 - 100 of 1144 matches
Mail list logo
