On Mon, 2008-01-07 at 20:06 +0200, Pekka J Enberg wrote:
> Hi Matt,
>
> On Sun, 6 Jan 2008, Matt Mackall wrote:
> > I don't have any particular "terrible" workloads for SLUB. But my
> > attempts to simply boot with all three allocators to init=/bin/bash in,
&g
On Sat, 2008-01-05 at 16:11 +0100, Ingo Molnar wrote:
> * Eric Dumazet <[EMAIL PROTECTED]> wrote:
>
> > # size vmlinux.before vmlinux.after
> >textdata bss dec hex filename
> > 4619942 422838 458752 5501532 53f25c vmlinux.before
> > 4610534 422838 458752 5492124 53cd9c v
On Mon, 2008-01-07 at 20:06 +0200, Pekka J Enberg wrote:
> Hi Matt,
>
> On Sun, 6 Jan 2008, Matt Mackall wrote:
> > I don't have any particular "terrible" workloads for SLUB. But my
> > attempts to simply boot with all three allocators to init=/bin/bash in,
&g
On Sat, 2008-01-05 at 18:21 +0200, Pekka J Enberg wrote:
> Hi Matt,
>
> On Thu, 3 Jan 2008, Matt Mackall wrote:
> > > SLUB can align these without a 2 byte
> > > overhead. In some configurations this results in SLUB using even less
> > > memory than SLOB.
On Fri, 2008-01-04 at 13:36 -0800, Christoph Lameter wrote:
> Ok. So lets try a worst case scenario. If we do a 128 byte kmalloc
> then we
> can allocate the following number of object from one 4k slab
>
> SLUB 32 (all memory of the 4k page is used for 128 byte objects)
> SLAB 29/30 (
On Fri, 2008-01-04 at 12:34 -0800, Christoph Lameter wrote:
> On Thu, 3 Jan 2008, Matt Mackall wrote:
>
> > > The advantage of SLOB is to be able to put objects of multiple sizes into
> > > the same slab page. That advantage goes away once we have more than a few
> &
On Fri, 2008-01-04 at 03:45 +0100, Andi Kleen wrote:
> > I still have trouble to see that SLOB still has much to offer. An embedded
> > allocator that in many cases has more allocation overhead than the default
> > one? Ok you still have advantages if allocations are rounded up to the
> > next
On Thu, 2008-01-03 at 18:21 -0800, Christoph Lameter wrote:
> On Thu, 3 Jan 2008, Matt Mackall wrote:
>
> > There are three downsides with the slab-like approach: internal
> > fragmentation, under-utilized slabs, and pinning.
> >
> > The first is the situation wh
e gcc doesn't need to store the function
> string twice now:
>
> 3936367 833603 624736 5394706 525112 vmlinux.before
> 3917508 833603 624736 5375847 520767 vmlinux-slowpath
Nice!
Acked-by: Matt Mackall <[EMAIL PROTECTED]>
--
Mathematics is the supreme nostalgia of ou
On Thu, 2008-01-03 at 09:52 +0100, Ingo Molnar wrote:
> * Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> > > Which means that SLOB could also trivially implement the same thing,
> > > with no new #ifdef'fery or other crud.
> >
> > Except SLOB'
le
> .config):
>
> text data bss dec hex filename
> 3096493293455 2760704 6150652 5dd9fc vmlinux.before
> 3090006293455 2760704 6144165 5dc0a5 vmlinux.after
>
> Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
I hate the do
On Wed, 2008-01-02 at 11:35 -0800, Linus Torvalds wrote:
>
> On Wed, 2 Jan 2008, Pekka Enberg wrote:
> >
> > I already sent the remaining bits to Linus but this looks much
> > cleaner. Thanks Hugh!
> >
> > Acked-by: Pekka Enberg <[EMAIL PROTECTED]>
>
> Actually, I'd much rather just do this in
On Sun, 2007-12-23 at 20:11 -0500, Rik van Riel wrote:
> On Mon, 24 Dec 2007 04:29:36 +0530
> Balbir Singh <[EMAIL PROTECTED]> wrote:
> > Rik van Riel wrote:
>
> > > In the real world, users with large JVMs on their servers, which
> > > sometimes go a little into swap, can trigger this system. A
With 2.6.24-rc2, plugging and unplugging power results in a sudden
reboot. After the reboot, the machine boots normally until it switches
to graphics mode, at which point the screen is scrambled. It may hang or
repeatedly reboot at this point. Easily repeatable after just a few plug
cycles.
Switch
On Sat, 2007-12-22 at 01:28 +0100, Andi Kleen wrote:
> Ingo Molnar <[EMAIL PROTECTED]> writes:
>
> > Christoph, /proc/slabinfo is an _ABI_. You HAVE to provide it. slabtop
> > relies on it, people use it every day to monitor memory consumption.
>
> It's definitely not a stable ABI. slabtop tend
On Thu, Dec 20, 2007 at 04:17:26PM -0800, David Miller wrote:
> From: Mariusz Kozlowski <[EMAIL PROTECTED]>
> Date: Thu, 20 Dec 2007 20:47:55 +0100
>
> > [ 145.128915] TSTATE: 004411009603 TPC: 005119ac TNPC:
> > 005119b0 Y: Not tainted
> > [ 145.128940] TPC:
>
On Thu, Dec 20, 2007 at 04:53:59AM -0800, David Miller wrote:
> From: Matt Mackall <[EMAIL PROTECTED]>
> Date: Mon, 17 Dec 2007 08:55:54 -0600
>
> > On Sun, Dec 16, 2007 at 10:39:17PM -0800, Andrew Morton wrote:
> > Actually, you may only need these two:
> >
On Thu, Dec 20, 2007 at 05:53:41PM +0100, Peter Zijlstra wrote:
>
> On Thu, 2007-12-20 at 15:26 +, Hugh Dickins wrote:
>
> > The asynch code: perhaps not worth doing for MADV_WILLNEED alone,
> > but might prove useful for more general use when swapping in.
> > Not really the same as Con's swa
On Wed, Dec 19, 2007 at 06:22:55PM +0200, Ramagudi Naziir wrote:
> On 12/6/07, Matt Mackall <[EMAIL PROTECTED]> wrote:
> > netpoll will ignore incoming UDP -from- the wrong port/ip/mac, since
> > it's otherwise bypassing the firewall layer.
> ...
> > I for
On Tue, Dec 18, 2007 at 10:25:50PM +0100, Eric Dumazet wrote:
> Some 'extern struct seq_operations' are wrongly defined in
> fs/proc/proc_misc.c (they miss a const qualifier)
>
> In order to fix this correctly, move the "extern ... " declaration from .c
> file to an appropriate include file, as
On Tue, Dec 18, 2007 at 10:06:14AM -0800, Arjan van de Ven wrote:
> Linus Torvalds wrote:
> >
> >On Mon, 17 Dec 2007, Arjan van de Ven wrote:
> >>+char *get_boot_uuid(void)
> >>+{
> >>+ static char target[38];
> >>+ unsigned char *uuid;
> >>+
> >>+ if (sysctl_bootid[8] == 0)
> >>+ g
>
> >Heh. UUID's don't have to be readable; just universally unique. Code
> >on the other hand should be readable. :-)
>
> Linus' suggested... improvement should either be done in all 3 places or
> none ;)
> Since you're the maintainer... wha
On Mon, Dec 17, 2007 at 01:36:31PM -0800, Arjan van de Ven wrote:
> On Mon, 17 Dec 2007 18:23:31 +0100
> Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> >
> > * Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> >
> > > The http://www.kerneloops.org website collects kernel oops and
> > > warning reports f
On Mon, Dec 17, 2007 at 11:24:57AM -0800, Randy Dunlap wrote:
> On Sun, 16 Dec 2007 21:55:20 + Mel Gorman wrote:
>
> > > > Just using cp to read the file is enough to cause problems but I
> > > > included
> > > > a very basic program below that produces the BUG_ON checks. Is this a
> > > > k
On Sun, Dec 16, 2007 at 10:39:17PM -0800, Andrew Morton wrote:
> On Sun, 16 Dec 2007 20:26:11 -0800 (PST) David Miller <[EMAIL PROTECTED]>
> wrote:
>
> > From: Matt Mackall <[EMAIL PROTECTED]>
> > Date: Sun, 16 Dec 2007 20:11:49 -0600
> >
> > >
On Sun, Dec 16, 2007 at 08:10:10PM +0100, Mariusz Kozlowski wrote:
> > > Can you change line 710 of fs/proc/proc_misc.c to:
> > >
> > > ppage = NULL;
> >
> > Sure.
> >
> > > ..and see if it still breaks?
> >
> > Yes it does - the same way as eariler. Box is locked, processes stuck in D
> > s
On Sun, Dec 16, 2007 at 07:38:14PM +0100, Eric Dumazet wrote:
> Adrian Bunk a ??crit :
> >On Sun, Dec 16, 2007 at 06:42:57PM +0100, Eric Dumazet wrote:
> >>Adrian Bunk a ??crit :
> >>...
> >>>And even more funny, with gcc 4.2 and CONFIG_CC_OPTIMIZE_FOR_SIZE=y your
> >>>patch doesn't seem to make a
On Sun, Dec 16, 2007 at 12:40:53PM +0100, Mariusz Kozlowski wrote:
> > cat /proc/kpageflags on sparc64 causes the box to lock.
> > I can not write on any terminal - but I can issue sysrqs and switch
> > between consoles.
> >
> > cat process hangs in read(3, ...
>
> cat /proc/kpagecount pr
On Sun, Dec 16, 2007 at 12:45:01PM +0100, Eric Dumazet wrote:
> While examining vmlinux namelist on i686, I noticed :
>
> c0581300 D random_table
> c0581480 d input_pool
> c0581580 d random_read_wakeup_thresh
> c0581584 d random_write_wakeup_thresh
> c0581600 d blocking_pool
>
> That means that t
On Sat, Dec 15, 2007 at 02:34:42PM +0800, Herbert Xu wrote:
> On Sat, Dec 15, 2007 at 05:31:30PM +1100, Benjamin Herrenschmidt wrote:
> >
> > That's something I've actually never quite liked... the fact that we
> > evaluate the expression anyway. I'm pretty happy with -not- evaluating
> > the expre
and add a new primitive.
>
> [PATCH] Added BARF_ON/BARF_ON_ONCE
>
> The description of CONFIG_BUG clearly states that both BUG and
> WARN_ON may be skipped. However, our actual implementation still
> checks the condition on WARN_ON if it's used as part of an if
> stat
On Sat, Dec 15, 2007 at 03:13:19PM +0800, Herbert Xu wrote:
> John Reiser <[EMAIL PROTECTED]> wrote:
> >
> > If speed matters that much, then please recoup 33 cycles on x86
> > by using shifts instead of three divides, such as (gcc 4.1.2):
> >
> >add_entropy_words(r, tmp, (bytes +
On Sat, Dec 15, 2007 at 02:04:49PM +0800, Herbert Xu wrote:
> On Fri, Dec 14, 2007 at 11:52:18PM -0600, Matt Mackall wrote:
> >
> > No. The code as written above should reduce to:
> >
> > if (val == NULL)
> > return -EFAULT;
> >
> >
On Fri, Dec 14, 2007 at 06:02:06PM -0800, Andrew Morton wrote:
> On Sat, 15 Dec 2007 01:09:41 + Mel Gorman <[EMAIL PROTECTED]> wrote:
>
> > On (13/12/07 14:29), Andrew Morton didst pronounce:
> > > > The simple way seems to be to malloc a large area, touch every page and
> > > > then look at t
On Sat, Dec 15, 2007 at 12:16:59PM +0800, Herbert Xu wrote:
> On Fri, Dec 14, 2007 at 12:02:46PM -0600, Matt Mackall wrote:
> >
> > I added CONFIG_BUG, and I think the current behavior is correct. As
> > you've noticed, we have to evaluate condition, it may have
> >
On Fri, Dec 14, 2007 at 11:34:09AM -0800, John Reiser wrote:
> xfer_secondary_pool() in drivers/char/random.c tells add_entropy_words()
> to use uninitialized tmp[] whenever bytes is not a multiple of 4.
> Besides being unfriendly to automated dynamic checkers, this is a
> potential leak of user da
On Fri, Dec 14, 2007 at 11:00:35AM -0800, Joe Perches wrote:
> Makes an embedded image a bit smaller
Looks good to me. This should probably go to Andrew first though. And
it wouldn't hurt to see some size(1) results.
Acked-by: Matt Mackall <[EMAIL PROTECTED]>
>
> Signed
On Fri, Dec 14, 2007 at 09:27:55PM +0800, Herbert Xu wrote:
> Hi:
>
> [PATCH] Make WARN_ON/WARN_ON_ONCE no-ops when CONFIG_BUG is off
>
> The description of CONFIG_BUG clearly states that both BUG and
> WARN_ON may be skipped. However, our actual implementation still
> checks the condition on WA
On Fri, Dec 14, 2007 at 04:38:04PM +0100, Eric Dumazet wrote:
> Matt Mackall a ?crit :
> >On Thu, Dec 13, 2007 at 11:20:44PM +0100, Adrian Bunk wrote:
> >
> >>I tried the following patch with a full x86 .config [1]:
> >>
> >>--- a/include/asm-x86
On Thu, Dec 13, 2007 at 08:30:41PM -0500, Dave Jones wrote:
> #ifndef HAVE_ARCH_BUG
> #define BUG() do { \
> - printk("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__,
> __FUNCTION__); \
> + printk(KERN_ERR "BUG: failure at %s:%d/%s()! (%s)\n",
> + __FILE__, __LINE__, __FU
On Thu, Dec 13, 2007 at 11:20:44PM +0100, Adrian Bunk wrote:
> I tried the following patch with a full x86 .config [1]:
>
> --- a/include/asm-x86/cache.h
> +++ b/include/asm-x86/cache.h
> -#define __read_mostly __attribute__((__section__(".data.read_mostly")))
> +/* #define __read_mostly __attribu
On Tue, Dec 11, 2007 at 12:06:43AM +0100, Marc Haber wrote:
> On Sun, Dec 09, 2007 at 10:16:05AM -0600, Matt Mackall wrote:
> > On Sun, Dec 09, 2007 at 01:42:00PM +0100, Marc Haber wrote:
> > > On Wed, Dec 05, 2007 at 03:26:47PM -0600, Matt Mackall wrote:
> > > >
On Sun, Dec 09, 2007 at 07:55:41AM -0500, Theodore Tso wrote:
> On Sat, Dec 08, 2007 at 10:22:04PM -0600, Matt Mackall wrote:
> >
> > It did. My laptop didn't relay them through my smarthost and my domain
> > has an SPF record.
>
> Ah, yes:
>
> http://hom
On Sun, Dec 09, 2007 at 08:33:00AM -0500, Theodore Tso wrote:
> On Sat, Dec 08, 2007 at 11:43:37PM -0600, Matt Mackall wrote:
> > > If you are trying to find the value of the 80 bits that were
> > > extracted, and you know the current state of the pool, yes, you can
> &
On Sun, Dec 09, 2007 at 01:42:00PM +0100, Marc Haber wrote:
> On Wed, Dec 05, 2007 at 03:26:47PM -0600, Matt Mackall wrote:
> > The distinction between /dev/random and /dev/urandom boils down to one
> > word: paranoia. If you are not paranoid enough to mistrust your
> > netw
On Sat, Dec 08, 2007 at 07:35:54PM -0500, Theodore Tso wrote:
> On Sat, Dec 08, 2007 at 05:20:17PM -0600, Matt Mackall wrote:
> > random: do extraction before mixing
> >
> > If an attacker manages to capture the current pool state, she can
> > determine the last 10 by
On Sat, Dec 08, 2007 at 08:45:50PM -0500, Theodore Tso wrote:
> On Sat, Dec 08, 2007 at 05:20:38PM -0600, Matt Mackall wrote:
> > random: make backtracking attacks harder
> >
> > At each extraction, we change (poolbits / 16) + 32 bits in the pool,
> > or 96 bits in the
On Sat, Dec 08, 2007 at 08:51:54PM -0500, Theodore Tso wrote:
> On Sat, Dec 08, 2007 at 05:21:00PM -0600, Matt Mackall wrote:
> > random: improve variable naming, clear extract buffer
> >
> > - split the SHA variables apart into hash and workspace
> > - rename data to
On Sat, Dec 08, 2007 at 08:00:55PM -0800, Andrew Morton wrote:
> On Sat, 8 Dec 2007 20:48:20 -0500 Theodore Tso <[EMAIL PROTECTED]> wrote:
>
> > On Sat, Dec 08, 2007 at 05:20:39PM -0600, Matt Mackall wrote:
> > > random: step more rapidly through the pool
On Sat, Dec 08, 2007 at 07:01:04PM -0500, Theodore Tso wrote:
> On Sat, Dec 08, 2007 at 05:20:16PM -0600, Matt Mackall wrote:
> > random: use xor for mixing
> >
> > With direct assignment, we can determine the twist table element used
> > for mixing (the high 3 bits o
On Sat, Dec 08, 2007 at 03:04:32PM -0500, Jeff Garzik wrote:
> Matt Mackall wrote:
> >On Sat, Dec 08, 2007 at 02:36:33PM -0500, Jeff Garzik wrote:
> >>As an aside...
> >>
> >>Speaking as the maintainer rng-tools, which is the home of the hardware
> >&
On Sat, Dec 08, 2007 at 02:36:33PM -0500, Jeff Garzik wrote:
>
> As an aside...
>
> Speaking as the maintainer rng-tools, which is the home of the hardware
> RNG entropy gathering daemon...
>
> I wish somebody (not me) would take rngd and several other projects, and
> combine them into a singl
hole GFP_ZERO thing is a bit broken here, this is
an improvement on my original patch, so:
Acked-by: Matt Mackall <[EMAIL PROTECTED]>
> ---
> mm/slob.c |2 +-
> mm/slub.c |3 +++
> 2 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/mm/slob.c b/mm
On Sat, Dec 08, 2007 at 09:54:06AM -0800, Linus Torvalds wrote:
>
>
> On Sat, 8 Dec 2007, Linus Torvalds wrote:
> >
> > But I'll apply it anyway, because it looks "obviously correct" from the
> > standpoint that the _other_??slob user already clears the end result
> > explicitly later on, and
On Sat, Dec 08, 2007 at 12:49:08PM -0500, Theodore Tso wrote:
> On Sat, Dec 08, 2007 at 11:33:57AM -0600, Mike McGrath wrote:
> >> Huh? What's the concern? All you are submitting is a list of
> >> hardware devices in your system. That's hardly anything sensitive
> >
> > We actually had a ver
On Sat, Dec 08, 2007 at 12:32:04PM -0500, Theodore Tso wrote:
> On Sat, Dec 08, 2007 at 02:37:57AM -0500, Jon Masters wrote:
> > > BTW, You may be better off using "uuidgen -t" to generate the UUID in
> > > the smolt RPM, since that will use 12 bits of randomness from
> > > /dev/random, plus the MA
L PROTECTED]>
> > References : http://lkml.org/lkml/2007/11/29/157
> > http://bugzilla.kernel.org/show_bug.cgi?id=9497
> > Handled-By : Matt Mackall <[EMAIL PROTECTED]>
> > Patch : http://lkml.org/lkml/2007/11/29/387
>
> Matt, the above
On Thu, Dec 06, 2007 at 08:22:15PM +0200, Ramagudi Naziir wrote:
> Hi all,
>
> It's probably only me, but I can't connect to a kgdb host because
> of bouncing ICMP unreachables. I'll be glad if you could take a look
> to see if it's a bug or not.
>
> Details:
> - running a cloned version of kgdb
On Thu, Dec 06, 2007 at 08:02:33AM +0100, Eric Dumazet wrote:
> Matt Mackall a ?crit :
> >On Tue, Dec 04, 2007 at 07:17:58PM +0100, Eric Dumazet wrote:
> >>Alan Cox a ?crit :
> >>>>No matter what you consider as being better, changing a 12 years old
> >>
On Tue, Dec 04, 2007 at 07:17:58PM +0100, Eric Dumazet wrote:
> Alan Cox a ?crit :
> >>No matter what you consider as being better, changing a 12 years old and
> >>widely used userspace interface like /dev/urandom is simply not an
> >>option.
> >>
> >
> >Fixing it to be more efficient in its
On Tue, Dec 04, 2007 at 04:23:12PM -0600, Mike McGrath wrote:
> Matt Mackall wrote:
> >On Tue, Dec 04, 2007 at 03:18:27PM -0600, Mike McGrath wrote:
> >
> >>Matt Mackall wrote:
> >>
> >>>which would have been in v2.6.22-rc4 through the normal C
On Tue, Dec 04, 2007 at 04:12:51PM -0600, Mike McGrath wrote:
> Theodore Tso wrote:
> >On Tue, Dec 04, 2007 at 02:48:12PM -0600, Mike McGrath wrote:
> >
> >>Alan Cox wrote:
> >>
> Here's the top 5:
>
> 266 28caf2c3-9766-4fe1-9e4c-d6b0ba8a0132
> 336 810e7126-1c69-4aff-b8
On Tue, Dec 04, 2007 at 03:18:27PM -0600, Mike McGrath wrote:
> Matt Mackall wrote:
> >which would have been in v2.6.22-rc4 through the normal CVE process.
> >The only other bits in there are wall time and utsname, so systems
> >with no CMOS clock would behave repeatably.
On Tue, Dec 04, 2007 at 02:48:12PM -0600, Mike McGrath wrote:
> Alan Cox wrote:
> >>Here's the top 5:
> >>
> >> 266 28caf2c3-9766-4fe1-9e4c-d6b0ba8a0132
> >> 336 810e7126-1c69-4aff-b8b1-9db0fa8aa15a
> >> 402 c8dbb9d3-a9bd-4ba6-b92e-4a294ba5a95f
> >> 884 06e84493-e024-44b1-9b32-32d78af04039
On Tue, Dec 04, 2007 at 08:40:36PM +, Alan Cox wrote:
> > Alan, are you sure you're not talking about Helge Deller's attempt to
> > push a Time-based UUID generator into the kernel because you can get
> > duplicates from the current userspace library?
>
> Yes
>
> > I've not heard of *any* cla
On Tue, Dec 04, 2007 at 02:50:21PM -0500, Theodore Tso wrote:
> On Tue, Dec 04, 2007 at 12:02:37PM -0600, Matt Mackall wrote:
> > On Tue, Dec 04, 2007 at 04:55:02PM +, Alan Cox wrote:
> > > > cryptographically strong stream it'll provide when /dev/random is
> >
On Tue, Dec 04, 2007 at 04:55:02PM +, Alan Cox wrote:
> > cryptographically strong stream it'll provide when /dev/random is
> > tapped? In principle, this'd leave more entropy available for
> > applications that really need it, especially on platforms that don't
> > generate a lot of entropy in
On Tue, Dec 04, 2007 at 08:54:52AM -0800, Ray Lee wrote:
> (Why hasn't anyone been cc:ing Matt on this?)
>
> On Dec 4, 2007 8:18 AM, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > On Tue, Dec 04, 2007 at 12:41:25PM +0100, Marc Haber wrote:
> >
> > > While debugging Exim4's GnuTLS interface, I recently
On Mon, Dec 03, 2007 at 04:07:33PM +0200, Pekka Enberg wrote:
> Hi,
>
> On Mon, Dec 03, 2007 at 08:41:44PM +0900, Tetsuo Handa wrote:
> > > We couldn't know how much memory was allocated by kmalloc() in 2.4 era,
> > > and we can know it 2.6 era.
> > > But are we going back to 2.4 era for out-of-t
ke you're right.
Reduce latency for large writes to /dev/[u]random
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
diff -r c60016ba6237 drivers/char/random.c
--- a/drivers/char/random.c Tue Nov 13 09:09:36 2007 -0800
+++ b/drivers/char/random.c Mon Dec 03 12:48:30 2007 -06
On Thu, Nov 29, 2007 at 03:53:23PM +0300, Evgeniy Polyakov wrote:
>
> Distributed storage documentation.
>
> Algorithms used in the system, userspace interfaces
> (sysfs dirs and files), design and implementation details
> are described here.
Can you give us a summary of how this differs from us
On Fri, Nov 30, 2007 at 10:14:18AM +0100, Ingo Molnar wrote:
>
> * Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> > > plus, and this is a slob question i guess, how come we drop into
> > > clear_highpage() for a kzalloc()??
> >
> > Good question. Looks
On Thu, Nov 29, 2007 at 03:39:20PM +0100, Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > i'm getting this on 32-bit (with the kmap-atomic debugging patch
> > applied):
> >
> > >
> > Calling initcall 0x78b67c00: tipc_init+0x0/0xc0()
> > TIPC: Activated (
On Fri, Nov 23, 2007 at 01:01:15PM +0100, Andi Kleen wrote:
> On Fri, Nov 23, 2007 at 03:03:29PM +1100, David Chinner wrote:
> > On Fri, Nov 23, 2007 at 03:53:17AM +0100, Andi Kleen wrote:
> > > On Fri, Nov 23, 2007 at 12:15:39AM +1100, David Chinner wrote:
> > > > On Thu, Nov 22, 2007 at 01:06:11P
Simon, can you test this patch? I think it's the most straightforward
2.6.24 fix.
diff -r c60016ba6237 net/core/netpoll.c
--- a/net/core/netpoll.cTue Nov 13 09:09:36 2007 -0800
+++ b/net/core/netpoll.cFri Nov 23 13:10:28 2007 -0600
@@ -203,6 +203,12 @@ static void refill_skbs(void)
On Fri, Nov 23, 2007 at 10:54:11PM +0300, Evgeniy Polyakov wrote:
> On Fri, Nov 23, 2007 at 01:41:39PM -0600, Matt Mackall ([EMAIL PROTECTED])
> wrote:
> > Here's another thought: move all this logic into the networking core,
> > unify it with current softirq zapper, the
On Fri, Nov 23, 2007 at 10:32:22PM +0300, Evgeniy Polyakov wrote:
> On Fri, Nov 23, 2007 at 01:11:20PM -0600, Matt Mackall ([EMAIL PROTECTED])
> wrote:
> > On Fri, Nov 23, 2007 at 09:59:06PM +0300, Evgeniy Polyakov wrote:
> > > On Fri, Nov 23, 2007 at 09:51:01PM +0300, Evg
On Fri, Nov 23, 2007 at 10:15:24PM +0300, Evgeniy Polyakov wrote:
> On Fri, Nov 23, 2007 at 12:59:43PM -0600, Matt Mackall ([EMAIL PROTECTED])
> wrote:
> > So I'd be surprised if that was a problem. But I can imagine having
> > problems for skbs without destructors which r
On Fri, Nov 23, 2007 at 09:59:06PM +0300, Evgeniy Polyakov wrote:
> On Fri, Nov 23, 2007 at 09:51:01PM +0300, Evgeniy Polyakov ([EMAIL
> PROTECTED]) wrote:
> > On Fri, Nov 23, 2007 at 09:48:51PM +0300, Evgeniy Polyakov ([EMAIL
> > PROTECTED]) wrote:
> > > Stop, we are trying to free skb without d
On Fri, Nov 23, 2007 at 08:57:57PM +0300, Evgeniy Polyakov wrote:
> On Fri, Nov 23, 2007 at 11:07:56AM -0600, Matt Mackall ([EMAIL PROTECTED])
> wrote:
> > On Fri, Nov 23, 2007 at 01:55:19PM +0300, Evgeniy Polyakov wrote:
> > > On Fri, Nov 23, 2007 at 12:21:57AM -0800,
On Fri, Nov 23, 2007 at 01:55:19PM +0300, Evgeniy Polyakov wrote:
> On Fri, Nov 23, 2007 at 12:21:57AM -0800, Andrew Morton ([EMAIL PROTECTED])
> wrote:
> > > [2059664.615816] __iptables__: init4 IN=ppp0 OUT=ppp0 WARNING: at
> > > kernel/softirq.c:139 local_bh_enable()
> > > [2059664.620535] [<8
On Fri, Nov 23, 2007 at 10:09:22AM +1100, David Chinner wrote:
> On Fri, Nov 23, 2007 at 09:29:09AM +1100, David Chinner wrote:
> > On Thu, Nov 22, 2007 at 12:10:29PM -0600, Matt Mackall wrote:
> > > If I've got XFS on filesystems A and B on the same spindle (or volume
>
On Fri, Nov 23, 2007 at 09:29:09AM +1100, David Chinner wrote:
> On Thu, Nov 22, 2007 at 12:10:29PM -0600, Matt Mackall wrote:
> > On Thu, Nov 22, 2007 at 09:31:59PM +1100, David Chinner wrote:
> > [...]
> > > > In other words, I/O priority is per-spindle and not per-
On Wed, Nov 21, 2007 at 09:58:10PM -0500, Jie Chen wrote:
> Simon Holm Th??gersen wrote:
> >ons, 21 11 2007 kl. 20:52 -0500, skrev Jie Chen:
>
> >There is a backport of the CFS scheduler to 2.6.21, see
> >http://lkml.org/lkml/2007/11/19/127
> >
> Hi, Simon:
>
> I will try that after the thanksgiv
On Thu, Nov 22, 2007 at 09:31:59PM +1100, David Chinner wrote:
[...]
> > In other words, I/O priority is per-spindle and not per-filesystem and
> > thus this change has consequences that leak outside the filesystem in
> > question. That's bad.
>
> This has nothing to do with this patch - it's a pr
On Thu, Nov 22, 2007 at 02:41:06PM +1100, David Chinner wrote:
> On Wed, Nov 21, 2007 at 08:57:27PM -0600, Matt Mackall wrote:
> > On Thu, Nov 22, 2007 at 12:12:14PM +1100, David Chinner wrote:
> > > In all the cases that I know of where ppl are using what could
> > >
On Thu, Nov 22, 2007 at 12:12:14PM +1100, David Chinner wrote:
> On Thu, Nov 22, 2007 at 01:49:25AM +0100, Andi Kleen wrote:
> > David Chinner <[EMAIL PROTECTED]> writes:
> >
> > > To ensure that log I/O is issued as the highest priority I/O, set
> > > the I/O priority of the log I/O to the highes
On Wed, Nov 21, 2007 at 12:06:57AM +0100, [EMAIL PROTECTED] wrote:
> - be root
That's your first mistake.
> - cat /dev/watchdog or dd if=/dev/watchdog of=/dev/zero bs=1 count=1 or .
> - wait one minute
>
> *reboot*!
And that's the defined behavior of /dev/watchdog, yes. Many years
On Wed, Nov 21, 2007 at 12:11:57AM +0100, Helge Deller wrote:
> On Tuesday 20 November 2007, Matt Mackall wrote:
> > On Tue, Nov 20, 2007 at 10:59:58PM +0100, Helge Deller wrote:
> > > > > Current implemenations use userspace-libraries. In userspace you e.g.
> >
On Tue, Nov 20, 2007 at 10:59:58PM +0100, Helge Deller wrote:
> > > Current implemenations use userspace-libraries. In userspace you e.g.
> > > can't
> > > easily protect the uniquness of a UUID against other running _processes_.
> > > If you try do, you'll need to do locking e.g. with shared mem
On Sun, Nov 18, 2007 at 10:40:34PM +0100, Helge Deller wrote:
> On Sunday 18 November 2007, Andrew Morton wrote:
> > On Sun, 18 Nov 2007 20:38:21 +0100 Helge Deller <[EMAIL PROTECTED]> wrote:
> >
> > > Title: Add time-based RFC 4122 UUID generator
> > >
> > > The current Linux kernel currently co
On Sun, Nov 18, 2007 at 07:52:36AM -0800, Abhishek Rai wrote:
> Thanks for the suggestion Matt.
>
> It took me some time to get compilebench working due to the known
> issue with drop_caches due to circular lock dependency between
> j_list_lock and inode_lock (compilebench triggers drop_caches qui
On Fri, Nov 16, 2007 at 09:39:58PM +0200, Matti Aarnio wrote:
> On Fri, Nov 16, 2007 at 02:35:29PM -0500, Mark Lord wrote:
> > Greg Kroah-Hartman wrote:
> >> We (the -stable team) are announcing the release of the 2.6.23.2 kernel.
> >> It contains a number of bugfixes for the core kernel code.
> >>
On Thu, Nov 15, 2007 at 11:02:19PM -0800, Andrew Morton wrote:
> On Thu, 15 Nov 2007 21:02:46 -0800 "Abhishek Rai" <[EMAIL PROTECTED]> wrote:
...
> > 3. e2fsck speedup with metaclustering varies from disk
> > to disk with most benefit coming from disks which have a large number
> > of indirect bloc
and
> bad things would happen.
>
> It seems a bit hairy to be doing list operations with the list marker as
> an entry, rather than a head, but...
>
> this resolves the following crash:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=9379
>
> Signed-off-by: Nick Piggin
On Wed, Nov 14, 2007 at 03:41:43PM -0800, David Miller wrote:
> From: Matt Mackall <[EMAIL PROTECTED]>
> Date: Wed, 14 Nov 2007 17:37:13 -0600
>
> > No, the usual strategy for debugging problems -outside- SLOB is to
> > switch to another allocator with more extensive de
On Wed, Nov 14, 2007 at 03:10:13PM -0800, David Miller wrote:
> From: Matt Mackall <[EMAIL PROTECTED]>
> Date: Wed, 14 Nov 2007 16:53:36 -0600
>
> > He hit the bug using SLOB and there are no kmem (or any other) caches
> > in SLOB.
>
> That's unfortunate,
On Wed, Nov 14, 2007 at 02:39:38PM -0800, David Miller wrote:
> From: Ingo Molnar <[EMAIL PROTECTED]>
> Date: Wed, 14 Nov 2007 20:05:01 +0100
>
> > the bug went away - and the only thing i did was a networking config
> > tweak. So maybe something in networking corrupts memory?
>
> This wouldn't
On Wed, Nov 14, 2007 at 08:05:01PM +0100, Ingo Molnar wrote:
>
> * Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> > > > [ 61.245190] rc.sysinit used greatest stack depth: 1680 bytes left
> > > > [ 61.386859] list_add corruption. prev->next should be
On Wed, Nov 14, 2007 at 11:36:11AM -0600, Matt Mackall wrote:
> On Wed, Nov 14, 2007 at 12:20:01PM +0100, Ingo Molnar wrote:
> >
> > there's a new SLOB regression - the attached config crashes with:
> >
> > [ 61.245190] rc.sysinit used greatest stack depth: 1
101 - 200 of 1002 matches
Mail list logo
