Am Montag, den 22.01.2007, 11:56 -0800 schrieb Andrew Morton:
> There has been a long history of similar problems when raid and dm-crypt
> are used together. I thought a couple of months ago that we were hot on
> the trail of a fix, but I don't think we ever got there. Perhaps
> Christophe can
Am Montag, den 22.01.2007, 11:56 -0800 schrieb Andrew Morton:
There has been a long history of similar problems when raid and dm-crypt
are used together. I thought a couple of months ago that we were hot on
the trail of a fix, but I don't think we ever got there. Perhaps
Christophe can
Am Freitag, den 01.12.2006, 19:49 -0800 schrieb Chris Wright:
> * Christophe Saout ([EMAIL PROTECTED]) wrote:
> > Fix corruption issue with dm-crypt on top of software raid5. Cancelled
> > readahead bio's that report no error, just have BIO_UPTODATE cleared
> > were reporte
Am Freitag, den 01.12.2006, 19:49 -0800 schrieb Chris Wright:
* Christophe Saout ([EMAIL PROTECTED]) wrote:
Fix corruption issue with dm-crypt on top of software raid5. Cancelled
readahead bio's that report no error, just have BIO_UPTODATE cleared
were reported as successful reads
Fix corruption issue with dm-crypt on top of software raid5. Cancelled
readahead bio's that report no error, just have BIO_UPTODATE cleared
were reported as successful reads to the higher layers (and leaving
random content in the buffer cache). Already fixed in 2.6.19.
Signed-off-by: Christophe
Fix corruption issue with dm-crypt on top of software raid5. Cancelled
readahead bio's that report no error, just have BIO_UPTODATE cleared
were reported as successful reads to the higher layers (and leaving
random content in the buffer cache). Already fixed in 2.6.19.
Signed-off-by: Christophe
Am Mittwoch, den 06.04.2005, 13:14 +0300 schrieb Denis Vlasenko:
> Oh shit. I was trying to be too clever. I still run with this patch,
> so it must be happening very rarely.
Yes, that's right, it happened with code that's not in the mainline tree
but could have happened anywhere.
> Does this
Am Mittwoch, den 06.04.2005, 13:14 +0300 schrieb Denis Vlasenko:
Oh shit. I was trying to be too clever. I still run with this patch,
so it must be happening very rarely.
Yes, that's right, it happened with code that's not in the mainline tree
but could have happened anywhere.
Does this one
Hi Andrew,
> - Nobody said anything about the PM resume and DRI behaviour in
> 2.6.12-rc1-mm4. So it's all perfect now?
Yes, works for me. DRI (i915) is working again and USB is now happy
after a PM resume too.
signature.asc
Description: This is a digitally signed message part
Hi Denis,
the new i386 memcpy macro is a ticking timebomb.
I've been debugging a new mISDN crash, just to find out that a memcpy
was not inlined correctly.
Andrew, you should drop the fix-i386-memcpy.patch (or have it fixed).
This source code:
mISDN_pid_t pid;
[...]
Hi Andrew,
- Nobody said anything about the PM resume and DRI behaviour in
2.6.12-rc1-mm4. So it's all perfect now?
Yes, works for me. DRI (i915) is working again and USB is now happy
after a PM resume too.
signature.asc
Description: This is a digitally signed message part
Hi Denis,
the new i386 memcpy macro is a ticking timebomb.
I've been debugging a new mISDN crash, just to find out that a memcpy
was not inlined correctly.
Andrew, you should drop the fix-i386-memcpy.patch (or have it fixed).
This source code:
mISDN_pid_t pid;
[...]
Am Sonntag, den 27.03.2005, 19:26 +0200 schrieb Andi Kleen:
> > preempt_schedule_irq is not an i386 specific function and seems to take
> > special care of BKL preemption and since reiserfs does use the BKL to do
> > certain things I think this actually might be the problem...?
>
> Hmm,
Hi Robert,
it looks like you shouldn't call iput with spinlocks held. iput might
call down into the filesystem to delete the inode and this can sleep.
Mar 27 14:38:18 server Debug: sleeping function called from invalid
context at include/asm/semaphore.h:102
Mar 27 14:38:18 server in_atomic():1,
Hi Robert,
it looks like you shouldn't call iput with spinlocks held. iput might
call down into the filesystem to delete the inode and this can sleep.
Mar 27 14:38:18 server Debug: sleeping function called from invalid
context at include/asm/semaphore.h:102
Mar 27 14:38:18 server in_atomic():1,
Am Sonntag, den 27.03.2005, 19:26 +0200 schrieb Andi Kleen:
preempt_schedule_irq is not an i386 specific function and seems to take
special care of BKL preemption and since reiserfs does use the BKL to do
certain things I think this actually might be the problem...?
Hmm,
ucible filesystem errors I've seen (with reiserfs, which
heavily relies on the BKL).
Signed-off-by: Christophe Saout <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm2.orig/arch/x86_64/kernel/entry.S2005-03-24
17:32:22.0 +0100
+++ linux-2.6.12-rc1-mm2/arch/x86_64/kernel/entry.S
filesystem errors I've seen (with reiserfs, which
heavily relies on the BKL).
Signed-off-by: Christophe Saout [EMAIL PROTECTED]
--- linux-2.6.12-rc1-mm2.orig/arch/x86_64/kernel/entry.S2005-03-24
17:32:22.0 +0100
+++ linux-2.6.12-rc1-mm2/arch/x86_64/kernel/entry.S 2005-03-26
23
Hi,
> +x86_64-fix-config_preempt.patch
>
> x86_64-fix-config_preempt.patch
> x86_64: Fix CONFIG_PREEMPT
Has this one been stress-tested?
I've got the impression that things have become a lot worse.
I've been seeing things like these:
Mar 25 01:00:48 websrv2 REISERFS: panic (device dm-1):
Hi,
+x86_64-fix-config_preempt.patch
x86_64-fix-config_preempt.patch
x86_64: Fix CONFIG_PREEMPT
Has this one been stress-tested?
I've got the impression that things have become a lot worse.
I've been seeing things like these:
Mar 25 01:00:48 websrv2 REISERFS: panic (device dm-1):
Am Dienstag, den 08.03.2005, 00:08 -0500 schrieb Kyle Moffett:
> Did you include support for the new key/keyring infrastructure
> introduced
> a couple versions ago by David Howells? It allows userspace to create
> and
> manage various sorts of "keys" in kernelspace. If you create and
>
Am Dienstag, den 08.03.2005, 00:08 -0500 schrieb Kyle Moffett:
Did you include support for the new key/keyring infrastructure
introduced
a couple versions ago by David Howells? It allows userspace to create
and
manage various sorts of keys in kernelspace. If you create and
register
a
d to extend to adjust the size of the operands for the address
calculation. Right?
Since size_t is unsigned I also had to modify the two loops since I
can't check for any of the variables becoming negative. Tested with all
kinds of array sizes.
Signed-off-by: Christophe Saout <[EMAIL PROTECTED]>
of the operands for the address
calculation. Right?
Since size_t is unsigned I also had to modify the two loops since I
can't check for any of the variables becoming negative. Tested with all
kinds of array sizes.
Signed-off-by: Christophe Saout [EMAIL PROTECTED]
diff -Nur linux-2.6.11-rc4-mm1.orig
Am Mittwoch, den 09.02.2005, 17:19 -0800 schrieb Andrew Morton:
> > It must be
> > possible to process more than 2 mappings in softirq context.
>
> Adding a few more fixmap slots wouldn't hurt anyone. But if you want an
> arbitrarily large number of them then no, we cannot do that.
>
>
Am Mittwoch, den 09.02.2005, 17:19 -0800 schrieb Andrew Morton:
It must be
possible to process more than 2 mappings in softirq context.
Adding a few more fixmap slots wouldn't hurt anyone. But if you want an
arbitrarily large number of them then no, we cannot do that.
Possibly one
Am Mittwoch, den 02.02.2005, 20:05 -0800 schrieb Matt Mackall:
> Dunno here, seems that having one tool that gave the kernel a key named
> "foo" and then telling dm-crypt to use key "foo" is probably not a bad
> way to go. Then we don't have stuff like "echo | dmsetup create"
> and the like and
Hi,
I was investigating a way to hide the dm-crypt key from device-mapper
configuration IOCTLs since the key might accidentally end up somewhere
it shouldn't (see other thread).
Then I stumbled across the new key retention service. This is exectly
what I was looking for.
The idea is to add the
Hi,
I was investigating a way to hide the dm-crypt key from device-mapper
configuration IOCTLs since the key might accidentally end up somewhere
it shouldn't (see other thread).
Then I stumbled across the new key retention service. This is exectly
what I was looking for.
The idea is to add the
Am Mittwoch, den 02.02.2005, 20:05 -0800 schrieb Matt Mackall:
Dunno here, seems that having one tool that gave the kernel a key named
foo and then telling dm-crypt to use key foo is probably not a bad
way to go. Then we don't have stuff like echo key | dmsetup create
and the like and the
Am Mittwoch, den 02.02.2005, 20:05 -0800 schrieb Matt Mackall:
> On Thu, Feb 03, 2005 at 03:34:29AM +0100, Christophe Saout wrote:
> > The keyring API seems very flexible. You can define your own type of
> > keys and give them names. Well, the name is probably irrelevant here
Am Mittwoch, den 02.02.2005, 20:05 -0800 schrieb Matt Mackall:
On Thu, Feb 03, 2005 at 03:34:29AM +0100, Christophe Saout wrote:
The keyring API seems very flexible. You can define your own type of
keys and give them names. Well, the name is probably irrelevant here and
should be chosen
Am Mittwoch, den 02.02.2005, 17:52 -0800 schrieb Matt Mackall:
> > An alternativ would be to use some form of handle to point to the key
> > after it has been given to the kernel. But that would require some more
> > infrastructure.
>
> There's been some talk about such infrastructure already. I
Am Mittwoch, den 02.02.2005, 13:19 -0800 schrieb Matt Mackall:
> From looking at the dm_crypt code, it appears that it can be
> interrogated to report the current key. Some quick testing shows:
>
> # dmsetup table /dev/mapper/volume1
> 0 200 crypt aes-plain 0123456789abcdef0123456789abcdef 0
Am Mittwoch, den 02.02.2005, 13:19 -0800 schrieb Matt Mackall:
From looking at the dm_crypt code, it appears that it can be
interrogated to report the current key. Some quick testing shows:
# dmsetup table /dev/mapper/volume1
0 200 crypt aes-plain 0123456789abcdef0123456789abcdef 0 7:0
Am Mittwoch, den 02.02.2005, 17:52 -0800 schrieb Matt Mackall:
An alternativ would be to use some form of handle to point to the key
after it has been given to the kernel. But that would require some more
infrastructure.
There's been some talk about such infrastructure already. I believe
Am Dienstag, den 25.01.2005, 18:28 +0100 schrieb Michael Buesch:
> I set up swap on an encrypted dmcrypt device.
> While stressing swap usage with make -j200 in the
> kernel tree, the machine crashes:
>
> Adding 1461872k swap on /dev/mapper/swap. Priority:-2 extents:1
> [ cut here
Am Dienstag, den 25.01.2005, 18:28 +0100 schrieb Michael Buesch:
I set up swap on an encrypted dmcrypt device.
While stressing swap usage with make -j200 in the
kernel tree, the machine crashes:
Adding 1461872k swap on /dev/mapper/swap. Priority:-2 extents:1
[ cut here
38 matches
Mail list logo
