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 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. See f.e. Pekka's test at
http://marc.info/?l
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 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
objects per slab because SLUB can
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
n'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 our time.
--
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's emul
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's emulation of slabs is so thin, it doesn't have the
relevant
3917508 833603 624736 5375847 520767 vmlinux-slowpath
Nice!
Acked-by: Matt Mackall [EMAIL PROTECTED]
--
Mathematics is the supreme nostalgia of our time.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
t;
> 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_foo naming scheme (
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
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 instead (on top
vmlinux.before
3090006293455 2760704 6144165 5dc0a5 vmlinux.after
Signed-off-by: Arjan van de Ven [EMAIL PROTECTED]
I hate the do_foo naming scheme (how about __warn_on?), but otherwise:
Acked-by: Matt Mackall [EMAIL PROTECTED]
+ printk(KERN_WARNING WARNING: at %s:%d %s()\n
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.
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. All of
the
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.
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.
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
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 tends to exit
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
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 swap
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:
maps4-add-proc-kpagecount-interface.patch
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 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 forget h
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 forget how to deal
with the source address issue
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)
> >>+
; >
> >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... what's your suggestion?
For
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
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 from various
; 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... what's your suggestion?
For the record:
RANDOM NUMBER DRIVER
P: Matt Mackall
M: [EMAIL PROTECTED
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)
+
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 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
> > > >
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 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
But as the function doesn't actually show up in your stack trace
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
known
issue or
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
> >
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
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
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
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 any space
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
state
and after a
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 the two
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 produces
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
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
> statement or such.
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 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 + 3) / 4);
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
statement or such.
I tried to compile it away but Matt Mackall pointed out
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 expression
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
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
> > sid
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
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-off-
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
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__,
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
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
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__, __FUNCTION__,
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/cache.h
+++ b/include/asm-x86/cache.h
-#define __read_mostly
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-off-by: Joe Perches [EMAIL
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 WARN_ON
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 data
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
side-effects. And if code does
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 the physical
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;
If I hadn't wanted to return -EFAULT in this case, I would
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 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:
The distinction between /dev/random and /dev
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://homepage
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 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
network, then /dev/random
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
take the 96 bits that were changed
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://homepages.tesco.net/~J.deBoynePollard/FGA/smtp-spf
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 b
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
hing 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/slob.c
> in
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
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
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 a
/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 bug is still occuring en masse during random bootups:
I was hoping for some discussion about
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 MAC, address
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 very vocal
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 we simply
change)
(b) don't warn about atomic GFP_ZERO's - unless they have GFP_HIGHMEM set
*too*.
So which warning is it that triggers the bogus error?
While I think the whole GFP_ZERO thing is a bit broken here, this is
an improvement on my original patch, so:
Acked-by: Matt Mackall [EMAIL
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 single
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
RNG entropy gathering daemon...
I wish somebody (not me
201 - 300 of 1967 matches
Mail list logo
