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 of the table are unique) and reverse
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 when adding and extracting
Second
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 extract
- wipe extract
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 case of the secondary pools. Thus
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 bytes extracted from the pool
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
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 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
and widely used userspace interface like /dev/urandom
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_2.6.23
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 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 use of entropy
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
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
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*
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
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
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 found out
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 the
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
tapped? In principle, this'd leave more
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* claim where
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
931
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. Can we find out what
kernels
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-b8b1-9db0fa8aa15a
402
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 CVE process.
The only other bits in there are wall time
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
u'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 -0600
@@ -104
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 -0600
@@ -1041,6 +1041,7 @@ write_pool(struct
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-tree kernel
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
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 using
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. Lo
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 like kzalloc switched from doing a memset to
passing
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 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 (version 1.6.2
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
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
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
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:11PM +0100,
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, then all
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
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
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]
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 run into one
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, then allow it to be called from
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, Evgeniy Polyakov ([EMAIL
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, Andrew Morton ([EMAIL
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] [80120364]
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
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
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
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 problem
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 thanksgiving holiday
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
group?) and my real RT I/O
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-filesystem and
thus this change has
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
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 highest possible.
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
be considered real-time I/O (e.g
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
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
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 memory, which
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.
can't
easily protect the uniquness
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 too
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
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 contains the
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
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 quite
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 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.
I'll also
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
d 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 <[EMAIL PRO
the following crash:
http://bugzilla.kernel.org/show_bug.cgi?id=9379
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Signed-off-by: Matt Mackall [EMAIL PROTECTED]
Andrew, please cue this for 2.6.24 and -stable.
---
mm/slob.c |3 ++-
1 file
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 blocks. For
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, is
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: 1680 b
On Wed, Nov 14, 2007 at 08:10:22AM -0500, David P. Reed wrote:
> Will make two patches and resend.
I've already got a set of patches brewing to fix the UIP problem across all
the affected arches (11+).
--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send
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: 1680 bytes left
> [ 61.386859] list_add corruption. prev->next should be next (407d973c), but
> was
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: 1680 bytes left
[ 61.386859] list_add corruption. prev-next should be next (407d973c), but
was 418cf818.
On Wed, Nov 14, 2007 at 08:10:22AM -0500, David P. Reed wrote:
Will make two patches and resend.
I've already got a set of patches brewing to fix the UIP problem across all
the affected arches (11+).
--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the
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: 1680 bytes left
[ 61.386859] list_add
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 next
(407d973c), but was 418cf818. (prev=41877098
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, is there any user tracking facility at
all
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 surprise
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 debugging facilities.
Ok, so
On Tue, Nov 13, 2007 at 01:46:46PM +0100, Peter Zijlstra wrote:
>
> On Tue, 2007-11-13 at 03:18 -0800, Andrew Morton wrote:
> > On Tue, 13 Nov 2007 10:57:31 + David Howells <[EMAIL PROTECTED]> wrote:
> >
> > > SL Baur <[EMAIL PROTECTED]> wrote:
> > >
> > > > Please take the emacsism out of
On Tue, Nov 13, 2007 at 01:46:46PM +0100, Peter Zijlstra wrote:
On Tue, 2007-11-13 at 03:18 -0800, Andrew Morton wrote:
On Tue, 13 Nov 2007 10:57:31 + David Howells [EMAIL PROTECTED] wrote:
SL Baur [EMAIL PROTECTED] wrote:
Please take the emacsism out of the file as it
On Fri, Nov 09, 2007 at 11:36:56PM +1100, Nick Piggin wrote:
> Hi,
>
> Just ran some tbench numbers (from dbench-3.04), on a 2 socket, 8
> core x86 system, with 1 NUMA node per socket. With kernel 2.6.24-rc2,
> comparing slab vs slub allocators.
Damn your misleading subject! I thought this was
On Fri, Nov 09, 2007 at 11:36:56PM +1100, Nick Piggin wrote:
Hi,
Just ran some tbench numbers (from dbench-3.04), on a 2 socket, 8
core x86 system, with 1 NUMA node per socket. With kernel 2.6.24-rc2,
comparing slab vs slub allocators.
Damn your misleading subject! I thought this was going
On Thu, Nov 08, 2007 at 01:28:31PM -0800, Christoph Lameter wrote:
> On Thu, 8 Nov 2007, Matt Mackall wrote:
>
> > But perhaps I should just add a lightweight RNG to random.c and be
> > done with it.
>
> It would be appreciated.
As someone pointed out privately, the
301 - 400 of 1967 matches
Mail list logo
