Announce loop-AES-v3.7t file/swap crypto package
loop-AES changes since previous release: - Worked around kernel interface changes on 5.11 kernels bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7t.tar.bz2 md5sum 974a0705207d97772b8c1388c43aee58 http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7t.tar.bz2.sign -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Re: 5.10 LTS Kernel: 2 or 6 years?
On Saturday, February 20, 2021 6:05 PM, Greg Kroah-Hartman wrote: > On Sat, Feb 20, 2021 at 01:29:21PM +0000, Jari Ruusu wrote: > > I have been able to narrow the beginning of the problem to these kernels: > > 4.14.188 ... 4.14.202 > > Same "fix" that went info 4.14.y is also bugging 4.19.y kernels. > > Great, any chance you can narrow this down to the commit itself? I am not able to test WiFi on that laptop computer anymore, because that laptop now connects to world using wired connection. It was that WiFI->wired connection change that led me to realize the buggyness of in-tree iwlwifi in 4.19.y kernels. I did that narrowing to specific kernel versions by digging my archived backup files and their notes. No tests were run. Problems started triggering in those kernels that I mentioned in earlier email. That does not mean that the bugs were not already there in kernels older that those. Maybe some change just widened "window of opportunity" enough for me to see the issues. In-tree iwlwifi in 4.19.y is missing locking fixes. No amount of smooth-talking is going to change that. -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Re: 5.10 LTS Kernel: 2 or 6 years?
On Friday, February 19, 2021 5:23 PM, Jari Ruusu wrote: > My contribution here is trying to point you guys to right direction. I have been able to narrow the beginning of the problem to these kernels: 4.14.188 ... 4.14.202 Same "fix" that went info 4.14.y is also bugging 4.19.y kernels. -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Re: 5.10 LTS Kernel: 2 or 6 years?
On Friday, February 19, 2021 1:16 PM, Greg Kroah-Hartman wrote: > Great! Can you run 'git bisect' on the 4.14.y stable tree to find the > offending change? As I tried to explain earlier, that laptop's connection to world is no longer iwlwifi based but ethernet connection to fibre. I can't do much bisecting when iwlwifi is not being used at all. Sorry. My contribution here is trying to point you guys to right direction. -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Re: 5.10 LTS Kernel: 2 or 6 years?
On Friday, February 19, 2021 12:37 PM, Greg Kroah-Hartman wrote: > Did you report that breakage to us and the developers of the driver? > Sounds like a regression that people would love to hear about and get > fixed. At that time I didn't know where the problem was, so I did not report it. I only recently connected-the-dots that problem is in-tree iwlwifi, so I am reporting it now. -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Re: 5.10 LTS Kernel: 2 or 6 years?
On Friday, February 19, 2021 10:22 AM, Greg Kroah-Hartman wrote: > That's not the goal of stable kernel releases/trees. If the driver > version that is in 4.19.y does not work for you on release 4.19.0, odds > of that "changing" in later stable releases is slim to none. But in-tree iwlwifi worked fine on 4.9.y and 4.14.y , and then got broken in later 4.14.y versions. I tried later versions of 4.19.y in an attempt to fix the breakage. Basically you are are saying that I should have NOT attempted to upgrage 4.9.y -> 4.14.y -> 4.19.y -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Re: 5.10 LTS Kernel: 2 or 6 years?
On Thursday, February 18, 2021 7:44 PM, Greg Kroah-Hartman wrote: > > It was the other way around. Fine working in-tree driver got > > broken by backported "fixes". I did mention bit-rot. > > It did? Please let us stable maintainers know about, we will always > gladly revert problems patches. What commits caused the problem? I don't have a list of commits for you. It took me long time to figure out that it was iwlwifi that was causing those problems. In-tree iwlwifi on 4.19.y kernels needs professional quality locking audit and backporting of necessary fixes from upstream Intel out-of-tree version. > So something in the 4.9.y and 4.14.y stable kernels caused a regression, > can you please do 'git bisect' to let us know what broke? My ability to do WiFi tests on that laptop computer are limited for now. Earlier that laptop's connectivity to world was through mobile WiFi router. That mobile WiFi router no longer has a SIM-card, so no connectivity through that anymore. That laptop's connectivity to world is now through wired ethernet to fiber. It was actually this switch to ethernet/fiber that made me realize the brokenness on in-tree iwlwifi on 4.19.y kernels. When in-tree WiFi was not used, those problems never triggered. Switched back to in-tree WiFi, and problems came back. Switched to out-of-tree Intel version of iwlwifi, problems went away again. Then I looked at the fixes in out-of-tree Intel version of iwlwifi that were missing in in-tree version, and I understood why that was so. Those stability issues on in-tree iwlwifi on 4.19.y kernels are difficult to trigger. Sometimes it may take days to trigger it once. Sometimes I was unlucky enough to trigger them more than once a day. I say that two weeks of operation without issues are needed to pronounce those issues gone. Currently, special arrangements are needed for me to test WiFi at all on that laptop computer, and those arrangements are something I am not willing to commit for multi-week testing run. Sorry. > And if 4.19.0 was always broken, why didn't you report that as well? I didn't test early 4.19.y kernels. -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Re: 5.10 LTS Kernel: 2 or 6 years?
On Thursday, February 18, 2021 4:33 PM, Willy Tarreau wrote: > Usually you pick an LTS kernel for a specific hardware. If it > works that's great. But you cannot expect hardware to suddenly start to > work in the middle of a stable kernel. Sometimes it happens (PCI IDs) but > that's basically all and that's not their purpose. It was the other way around. Fine working in-tree driver got broken by backported "fixes". I did mention bit-rot. In-tree iwlwifi worked half-ok on early 4.9.y stable. If connection somehow de-autheticated (out of radio range or whatever) it crashed the kernel spectacularly. Eventually that was fixed and in-tree iwlwifi worked fine on 4.9.y and 4.14.y stable kernels. On second half of year 2020 (don't remember exactly when) iwlwifi started causing erratic behavior when some random process terminated, as if some exit processing left some resources un-freed or something weird like that. Upgraded to 4.19.y kernels in hope to fix the issue. Nope, same problems continued there as well. Replacing in-tree iwlwifi with out-of-tree upstream Intel version solved the problem for me. -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Re: 5.10 LTS Kernel: 2 or 6 years?
Willy Tarreau wrote: > The only set of fixes that can be trusted are the "official" stable > kernels, because they are the only ones that are approved by the patches > authors themselves. Adding more stuff on top of stable kernels is fine > (and done at your own risk), but randomly dropping stuff from stable > kernels just because you don't think you need that is totally non-sense > and must not be done anymore! This may be little bit off-topic... but stable kernel.org kernels can also bit-rot badly because of "selective" backporting... as in anything that does not apply cleanly gets dropped regardless of how critical they are. I will give you one example: Intel WiFi (iwlwifi) on 4.19.y kernel.org stable kernels is currently missing many critical locking fixes. As a result, that in-tree iwlwifi driver causes erratic behavior to random unrelated processes, and has been doing so for many months now. My not-so-politically correct opinion is that in-tree iwlwifi is completely FUBAR unless someone steps up to do professional quality backport of those locking fixes from upstream out-of-tree Intel version [1] [2] of the driver. For me only way to get properly working WiFi on my laptop computer is to compile that Intel out-of-tree version. Sad, but true. [1] https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/core_release [2] https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/backport-iwlwifi.git/ -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Kernel version numbers after 4.9.255 and 4.4.255
Greg, I hope that your linux kernel release scripts are implemented in a way that understands that PATCHLEVEL= and SUBLEVEL= numbers in top-level linux Makefile are encoded as 8-bit numbers for LINUX_VERSION_CODE and KERNEL_VERSION() macros, and must stay in range 0...255. These 8-bit limits are hardcoded in both kernel source and userspace ABI. After 4.9.255 and 4.4.255, your scripts should be incrementing a number in EXTRAVERSION= in top-level linux Makefile. -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Re: Linux 4.19.154
Greg Kroah-Hartman wrote:
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -2127,11 +2127,10 @@ static void handle_bad_sector(struct bio *bio,
> sector_t maxsector)
> {
> char b[BDEVNAME_SIZE];
>
> - printk(KERN_INFO "attempt to access beyond end of device\n");
> - printk(KERN_INFO "%s: rw=%d, want=%Lu, limit=%Lu\n",
> - bio_devname(bio, b), bio->bi_opf,
> - (unsigned long long)bio_end_sector(bio),
> - (long long)maxsector);
> + pr_info_ratelimited("attempt to access beyond end of device\n"
> + "%s: rw=%d, want=%llu, limit=%llu\n",
> + bio_devname(bio, b), bio->bi_opf,
> + bio_end_sector(bio), maxsector);
> }
>
> #ifdef CONFIG_FAIL_MAKE_REQUEST
Above change "block: ratelimit handle_bad_sector() message"
upstream commit f4ac712e4fe009635344b9af5d890fe25fcc8c0d
in 4.19.154 kernel is not completely OK.
Removing casts from arguments 4 and 5 produces these compile warnings:
In file included from ./include/linux/kernel.h:14:0,
from block/blk-core.c:14:
block/blk-core.c: In function 'handle_bad_sector':
./include/linux/kern_levels.h:5:18: warning: format '%llu' expects argument of
type 'long long unsigned int', but argument 4 has type 'sector_t {aka long
unsigned int}' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
./include/linux/printk.h:424:10: note: in definition of macro
'printk_ratelimited'
printk(fmt, ##__VA_ARGS__);\
^~~
./include/linux/kern_levels.h:14:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
^~~~
./include/linux/printk.h:444:21: note: in expansion of macro 'KERN_INFO'
printk_ratelimited(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^
block/blk-core.c:2130:2: note: in expansion of macro 'pr_info_ratelimited'
pr_info_ratelimited("attempt to access beyond end of device\n"
^~~
./include/linux/kern_levels.h:5:18: warning: format '%llu' expects argument of
type 'long long unsigned int', but argument 5 has type 'sector_t {aka long
unsigned int}' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
./include/linux/printk.h:424:10: note: in definition of macro
'printk_ratelimited'
printk(fmt, ##__VA_ARGS__);\
^~~
./include/linux/kern_levels.h:14:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
^~~~
./include/linux/printk.h:444:21: note: in expansion of macro 'KERN_INFO'
printk_ratelimited(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^
block/blk-core.c:2130:2: note: in expansion of macro 'pr_info_ratelimited'
pr_info_ratelimited("attempt to access beyond end of device\n"
^~~
For 64 bit systems it is only compile time cosmetic warning. For 32 bit
system + CONFIG_LBDAF=n it introduces bugs: output formats are "%llu" and
passed parameters are 32 bits. That is not OK.
Upstream kernels have hardcoded 64 bit sector_t. In older stable trees
sector_t can be either 64 or 32 bit. In other words, backport of above patch
needs to keep those original casts.
--
Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Announce loop-AES-v3.7s file/swap crypto package
loop-AES changes since previous release: - Worked around kernel interface changes on 5.9 kernels - Partial re-write of ioctl handling to get rid of set_fs() which is expected to be removed from mainline kernels in near future. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7s.tar.bz2 md5sum 154fabeb1976dc6dc111c96918d4c128 http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7s.tar.bz2.sign -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Announce loop-AES-v3.7r file/swap crypto package
loop-AES changes since previous release: - Worked around kernel interface changes on 5.8 kernels bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7r.tar.bz2 md5sum e264e305c829d002a7a94376789f4adc http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7r.tar.bz2.sign -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Announce loop-AES-v3.7q file/swap crypto package
loop-AES changes since previous release: - Worked around kernel interface changes on 5.7 kernels bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7q.tar.bz2 md5sum b9628468b35e92feee63eccfee8e4863 http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7q.tar.bz2.sign -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Re: [PATCH 3.16 043/157] ext4: brelse all indirect buffer inext4_ind_remove_space()
Ben Hutchings wrote:
> From: "zhangyi (F)"
>
> commit 674a2b27234d1b7afcb0a9162e81b2e53aeef217 upstream.
[snip]
> --- a/fs/ext4/indirect.c
> +++ b/fs/ext4/indirect.c
> @@ -1481,10 +1481,14 @@ end_range:
>partial->p + 1,
>partial2->p,
>(chain+n-1) - partial);
> - BUFFER_TRACE(partial->bh, "call brelse");
> - brelse(partial->bh);
> - BUFFER_TRACE(partial2->bh, "call brelse");
> - brelse(partial2->bh);
> + while (partial > chain) {
> + BUFFER_TRACE(partial->bh, "call brelse");
> + brelse(partial->bh);
> + }
> + while (partial2 > chain2) {
> + BUFFER_TRACE(partial2->bh, "call brelse");
> + brelse(partial2->bh);
> + }
> return 0;
> }
>
Above patch is really messed up. Alone that patch is livelocking
and file system corrupting. Look at those new while loops. Once the
while condition is true once, it is ALWAYS true, so it livelocks.
It absolutely needs follow-up patch from
"ext4: cleanup bh release code in ext4_ind_remove_space()"
upstream commit 5e86bdda41534e17621d5a071b294943cae4376e.
For more info about how to trigger that bug, see this earlier email
https://marc.info/?l=linux-kernel=155419973129522=2
For 3.16 kernels you may need to set CONFIG_EXT4_USE_FOR_EXT23=y
so that ext4 code handles ext3 file systems.
--
Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Re: [PATCH 4.9 00/42] 4.9.188-stable review
Greg Kroah-Hartman wrote:
> On Mon, Aug 05, 2019 at 11:11:01PM +0300, Jari Ruusu wrote:
> > Peter Zijlstra's "x86/atomic: Fix smp_mb__{before,after}_atomic()"
> > upstream commit 69d927bba39517d0980462efc051875b7f4db185 seems to
> > be missing/lost from 4.9 and older stable kernels.
>
> Can you send properly backported and tested patches?
linux-4.4 backport of "x86/atomic: Fix smp_mb__{before,after}_atomic()".
Tested.
Signed-off-by: Jari Ruusu
--- a/arch/x86/include/asm/atomic.h
+++ b/arch/x86/include/asm/atomic.h
@@ -49,7 +49,7 @@
{
asm volatile(LOCK_PREFIX "addl %1,%0"
: "+m" (v->counter)
-: "ir" (i));
+: "ir" (i) : "memory");
}
/**
@@ -63,7 +63,7 @@
{
asm volatile(LOCK_PREFIX "subl %1,%0"
: "+m" (v->counter)
-: "ir" (i));
+: "ir" (i) : "memory");
}
/**
@@ -89,7 +89,7 @@
static __always_inline void atomic_inc(atomic_t *v)
{
asm volatile(LOCK_PREFIX "incl %0"
-: "+m" (v->counter));
+: "+m" (v->counter) :: "memory");
}
/**
@@ -101,7 +101,7 @@
static __always_inline void atomic_dec(atomic_t *v)
{
asm volatile(LOCK_PREFIX "decl %0"
-: "+m" (v->counter));
+: "+m" (v->counter) :: "memory");
}
/**
--- a/arch/x86/include/asm/atomic64_64.h
+++ b/arch/x86/include/asm/atomic64_64.h
@@ -44,7 +44,7 @@
{
asm volatile(LOCK_PREFIX "addq %1,%0"
: "=m" (v->counter)
-: "er" (i), "m" (v->counter));
+: "er" (i), "m" (v->counter) : "memory");
}
/**
@@ -58,7 +58,7 @@
{
asm volatile(LOCK_PREFIX "subq %1,%0"
: "=m" (v->counter)
-: "er" (i), "m" (v->counter));
+: "er" (i), "m" (v->counter) : "memory");
}
/**
@@ -85,7 +85,7 @@
{
asm volatile(LOCK_PREFIX "incq %0"
: "=m" (v->counter)
-: "m" (v->counter));
+: "m" (v->counter) : "memory");
}
/**
@@ -98,7 +98,7 @@
{
asm volatile(LOCK_PREFIX "decq %0"
: "=m" (v->counter)
- : "m" (v->counter));
+: "m" (v->counter) : "memory");
}
/**
--- a/arch/x86/include/asm/barrier.h
+++ b/arch/x86/include/asm/barrier.h
@@ -116,7 +116,7 @@
#endif
/* Atomic operations are already serializing on x86 */
-#define smp_mb__before_atomic()barrier()
-#define smp_mb__after_atomic() barrier()
+#define smp_mb__before_atomic()do { } while (0)
+#define smp_mb__after_atomic() do { } while (0)
#endif /* _ASM_X86_BARRIER_H */
--
Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Re: [PATCH 4.9 00/42] 4.9.188-stable review
Greg Kroah-Hartman wrote:
> On Mon, Aug 05, 2019 at 11:11:01PM +0300, Jari Ruusu wrote:
> > Peter Zijlstra's "x86/atomic: Fix smp_mb__{before,after}_atomic()"
> > upstream commit 69d927bba39517d0980462efc051875b7f4db185 seems to
> > be missing/lost from 4.9 and older stable kernels.
>
> Can you send properly backported and tested patches?
linux-4.9 backport of "x86/atomic: Fix smp_mb__{before,after}_atomic()".
Tested.
Signed-off-by: Jari Ruusu
--- a/arch/x86/include/asm/atomic.h
+++ b/arch/x86/include/asm/atomic.h
@@ -49,7 +49,7 @@
{
asm volatile(LOCK_PREFIX "addl %1,%0"
: "+m" (v->counter)
-: "ir" (i));
+: "ir" (i) : "memory");
}
/**
@@ -63,7 +63,7 @@
{
asm volatile(LOCK_PREFIX "subl %1,%0"
: "+m" (v->counter)
-: "ir" (i));
+: "ir" (i) : "memory");
}
/**
@@ -89,7 +89,7 @@
static __always_inline void atomic_inc(atomic_t *v)
{
asm volatile(LOCK_PREFIX "incl %0"
-: "+m" (v->counter));
+: "+m" (v->counter) :: "memory");
}
/**
@@ -101,7 +101,7 @@
static __always_inline void atomic_dec(atomic_t *v)
{
asm volatile(LOCK_PREFIX "decl %0"
-: "+m" (v->counter));
+: "+m" (v->counter) :: "memory");
}
/**
--- a/arch/x86/include/asm/atomic64_64.h
+++ b/arch/x86/include/asm/atomic64_64.h
@@ -44,7 +44,7 @@
{
asm volatile(LOCK_PREFIX "addq %1,%0"
: "=m" (v->counter)
-: "er" (i), "m" (v->counter));
+: "er" (i), "m" (v->counter) : "memory");
}
/**
@@ -58,7 +58,7 @@
{
asm volatile(LOCK_PREFIX "subq %1,%0"
: "=m" (v->counter)
-: "er" (i), "m" (v->counter));
+: "er" (i), "m" (v->counter) : "memory");
}
/**
@@ -85,7 +85,7 @@
{
asm volatile(LOCK_PREFIX "incq %0"
: "=m" (v->counter)
-: "m" (v->counter));
+: "m" (v->counter) : "memory");
}
/**
@@ -98,7 +98,7 @@
{
asm volatile(LOCK_PREFIX "decq %0"
: "=m" (v->counter)
- : "m" (v->counter));
+: "m" (v->counter) : "memory");
}
/**
--- a/arch/x86/include/asm/barrier.h
+++ b/arch/x86/include/asm/barrier.h
@@ -105,8 +105,8 @@
#endif
/* Atomic operations are already serializing on x86 */
-#define __smp_mb__before_atomic() barrier()
-#define __smp_mb__after_atomic() barrier()
+#define __smp_mb__before_atomic() do { } while (0)
+#define __smp_mb__after_atomic() do { } while (0)
#include
--
Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Re: [PATCH 4.9 00/42] 4.9.188-stable review
Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.188 release.
Peter Zijlstra's "x86/atomic: Fix smp_mb__{before,after}_atomic()"
upstream commit 69d927bba39517d0980462efc051875b7f4db185 seems to
be missing/lost from 4.9 and older stable kernels.
That patch has 10 hunks, first one of those does not apply cleanly to
4.9 kernel because it attempts to modify Documentation/atomic_t.txt
file which does not exist in older kernels. Other 9 hunks apply with
small offsets and fuzz, but modifications find their correct places anyway.
Those other 9 hunks are the important ones, first hunk can be ignored.
Greg,
Please take Peter Zijlstra's original patch and "force" apply it like this
to 4.9 kernels:
patch -p1 -f
Re: [PATCH 4.19 079/271] x86/atomic: Fix smp_mb__{before,after}_atomic()
On 7/26/19, Peter Zijlstra wrote: > On Fri, Jul 26, 2019 at 01:18:06PM +0300, Jari Ruusu wrote: >> Shouldn't those clobber contraints actually be: "memory","cc" >> That is because addl subl (and other) machine instructions >> actually modify the flags register too. >> >> gcc docs say: The "cc" clobber indicates that the assembler >> code modifies the flags register. > > GCC x86 assumes any asm() will clobber "cc". No worries then. Thanks for your clarification. -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Re: [PATCH 4.19 079/271] x86/atomic: Fix smp_mb__{before,after}_atomic()
Greg Kroah-Hartman wrote:
> [ Upstream commit 69d927bba39517d0980462efc051875b7f4db185 ]
>
> Recent probing at the Linux Kernel Memory Model uncovered a
> 'surprise'. Strongly ordered architectures where the atomic RmW
> primitive implies full memory ordering and
> smp_mb__{before,after}_atomic() are a simple barrier() (such as x86)
> fail for:
>
> *x = 1;
> atomic_inc(u);
> smp_mb__after_atomic();
> r0 = *y;
[snip]
> --- a/arch/x86/include/asm/atomic.h
> +++ b/arch/x86/include/asm/atomic.h
> @@ -54,7 +54,7 @@ static __always_inline void arch_atomic_add(int i, atomic_t
> *v)
> {
> asm volatile(LOCK_PREFIX "addl %1,%0"
> : "+m" (v->counter)
> -: "ir" (i));
> +: "ir" (i) : "memory");
> }
>
> /**
Shouldn't those clobber contraints actually be: "memory","cc"
That is because addl subl (and other) machine instructions
actually modify the flags register too.
gcc docs say: The "cc" clobber indicates that the assembler
code modifies the flags register.
--
Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
ext3 file system livelock and file system corruption, 4.9.166 stable kernel
To trigger this ext4 file system bug, you need a sparse file with
correct sparse pattern on old-school ext3 file system. I tried
more simpler ways to trigger this but those attempts did not
trigger the bug. I have provided compressed sparse file that
reliably triggers the bug. Size of compressed sparse file 1667256
bytes. Size of uncompressed sparse file 7369850880 bytes.
Following commands will demo the problem.
wget http://www.elisanet.fi/jariruusu/123/sparse-demo.data.xz
xz -d sparse-demo.data.xz
mkfs -t ext3 -b 4096 -e remount-ro -O "^dir_index" /dev/sdc1
mount -t ext3 /dev/sdc1 /mnt
cp -v --sparse=always sparse-demo.data /mnt/aa
cp -v --sparse=always sparse-demo.data /mnt/bb
umount /mnt
mount -t ext3 /dev/sdc1 /mnt
cp -v --sparse=always /mnt/bb /mnt/aa
That last cp command reliably triggers the bug that livelocks and
after reset you have file system corruption to deal with. Deeply
unfunny.
The bug is caused by
"ext4: brelse all indirect buffer in ext4_ind_remove_space()"
upstream commit 674a2b27234d1b7afcb0a9162e81b2e53aeef217, from
, who provided a follow-up patch
"ext4: cleanup bh release code in ext4_ind_remove_space()"
upstream commit 5e86bdda41534e17621d5a071b294943cae4376e. The
problem with that follow-up patch is that it is almost criminally
mislabeled. It should have said "fixes ext3 livelock and file
system corrupting bug" or something like that, so that Greg KH &
Co would have understood that it must be backported to stable
kernels too. Now the bug appears to be in all/most stable kernels
already.
Below is the buggy patch that causes the problem. Look at those
new while loops. Once the while condition is true once, it is
ALWAYS true, so it livelocks.
> --- a/fs/ext4/indirect.c
> +++ b/fs/ext4/indirect.c
> @@ -1385,10 +1385,14 @@ end_range:
> partial->p + 1,
> partial2->p,
> (chain+n-1) - partial);
> - BUFFER_TRACE(partial->bh, "call brelse");
> - brelse(partial->bh);
> - BUFFER_TRACE(partial2->bh, "call brelse");
> - brelse(partial2->bh);
> + while (partial > chain) {
> + BUFFER_TRACE(partial->bh, "call brelse");
> + brelse(partial->bh);
> + }
> + while (partial2 > chain2) {
> + BUFFER_TRACE(partial2->bh, "call brelse");
> + brelse(partial2->bh);
> + }
> return 0;
> }
>
Greg & Co,
Please revert that above patch from stable kernels or backport the
follow-up patch that fixes the problem.
--
Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Re: [PATCH 4.14 121/146] x86/fpu: Disable bottom halves while loading FPU registers
Greg Kroah-Hartman wrote:
> commit 68239654acafe6aad5a3c1dc7237e60accfebc03 upstream.
>
> The sequence
>
> fpu->initialized = 1; /* step A */
> preempt_disable();/* step B */
> fpu__restore(fpu);
> preempt_enable();
>
> in __fpu__restore_sig() is racy in regard to a context switch.
That same race appears to be present in older kernel branches also.
The context is sligthly different, so the patch for 4.14 does not
apply cleanly to older kernels. For 4.9 branch, this edit works:
s/fpu->initialized/fpu->fpstate_active/
--- a/arch/x86/kernel/fpu/signal.c
+++ b/arch/x86/kernel/fpu/signal.c
@@ -342,10 +342,10 @@ static int __fpu__restore_sig(void __use
sanitize_restored_xstate(tsk, , xfeatures, fx_only);
}
+ local_bh_disable();
fpu->fpstate_active = 1;
- preempt_disable();
fpu__restore(fpu);
- preempt_enable();
+ local_bh_enable();
return err;
} else {
Re: [PATCH 4.14 121/146] x86/fpu: Disable bottom halves while loading FPU registers
Greg Kroah-Hartman wrote:
> commit 68239654acafe6aad5a3c1dc7237e60accfebc03 upstream.
>
> The sequence
>
> fpu->initialized = 1; /* step A */
> preempt_disable();/* step B */
> fpu__restore(fpu);
> preempt_enable();
>
> in __fpu__restore_sig() is racy in regard to a context switch.
That same race appears to be present in older kernel branches also.
The context is sligthly different, so the patch for 4.14 does not
apply cleanly to older kernels. For 4.9 branch, this edit works:
s/fpu->initialized/fpu->fpstate_active/
--- a/arch/x86/kernel/fpu/signal.c
+++ b/arch/x86/kernel/fpu/signal.c
@@ -342,10 +342,10 @@ static int __fpu__restore_sig(void __use
sanitize_restored_xstate(tsk, , xfeatures, fx_only);
}
+ local_bh_disable();
fpu->fpstate_active = 1;
- preempt_disable();
fpu__restore(fpu);
- preempt_enable();
+ local_bh_enable();
return err;
} else {
Announce loop-AES-v3.7m file/swap crypto package
loop-AES changes since previous release: - Worked around kernel interface changes on 4.14 and 4.15-rc kernels. - Fixed possible timer delete race condition at loop detach time when key scrubbing was enabled. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7m.tar.bz2 md5sum 288105b86f7733224ddd5f7369b6a025 http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7m.tar.bz2.sign -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Announce loop-AES-v3.7m file/swap crypto package
loop-AES changes since previous release: - Worked around kernel interface changes on 4.14 and 4.15-rc kernels. - Fixed possible timer delete race condition at loop detach time when key scrubbing was enabled. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7m.tar.bz2 md5sum 288105b86f7733224ddd5f7369b6a025 http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7m.tar.bz2.sign -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Announce loop-AES-v3.7l file/swap crypto package
loop-AES changes since previous release: - Worked around kernel interface changes on 4.13 kernels. - Added second util-linux patch to work around gpg 2 pinentry-mode bug. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7l.tar.bz2 md5sum e77d0b5092d652984f0bd2ffb357deb8 http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7l.tar.bz2.sign -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Announce loop-AES-v3.7l file/swap crypto package
loop-AES changes since previous release: - Worked around kernel interface changes on 4.13 kernels. - Added second util-linux patch to work around gpg 2 pinentry-mode bug. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7l.tar.bz2 md5sum e77d0b5092d652984f0bd2ffb357deb8 http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7l.tar.bz2.sign -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Announce loop-AES-v3.7k file/swap crypto package
loop-AES changes since previous release: - Worked around kernel interface changes on 4.10 and 4.11-rc kernels. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7k.tar.bz2 md5sum 942bff99a0361f209ce8de66404b64b3 http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7k.tar.bz2.sign -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Announce loop-AES-v3.7k file/swap crypto package
loop-AES changes since previous release: - Worked around kernel interface changes on 4.10 and 4.11-rc kernels. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7k.tar.bz2 md5sum 942bff99a0361f209ce8de66404b64b3 http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7k.tar.bz2.sign -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Announce loop-AES-v3.7j file/swap crypto package
loop-AES changes since previous release: - Worked around block layer interface changes on 4.8 kernels. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7j.tar.bz2 md5sum 335238a7cfd45f157935c59156533a05 http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7j.tar.bz2.sign -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Announce loop-AES-v3.7j file/swap crypto package
loop-AES changes since previous release: - Worked around block layer interface changes on 4.8 kernels. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7j.tar.bz2 md5sum 335238a7cfd45f157935c59156533a05 http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7j.tar.bz2.sign -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Re: [PATCH 3.10 099/180] fix d_walk()/non-delayed __d_free() race
This patch for 3.10 branch appears to be missing one important + dentry->d_flags |= DCACHE_RCUACCESS; in fs/dcache.c __d_materialise_dentry() function. When Ben Hutchings backported Al Viro's original fix to stable branches that he maintains, he added that one additional line to both 3.2 and 3.16 branches. Please consider including that additional one line fix for 3.10 stable branch also. Ben Hutchings said this on his 3.2.82-rc1 patch: [bwh: Backported to 3.2: - Adjust context - Also set the flag in __d_materialise_dentry())] http://marc.info/?l=linux-kernel=147117565612275=2 Ben Hutchings said this on his 3.16.37-rc1 patch: [bwh: Backported to 3.16: - Adjust context - Also set the flag in __d_materialise_dentry())] http://marc.info/?l=linux-kernel=147117433412006=2 Also mentioned by Sasha Levin on 3.18 and 4.1 commits: Cc: sta...@vger.kernel.org # v3.2+ (and watch out for __d_materialise_dentry()) http://marc.info/?l=linux-stable-commits=146648034410827=2 http://marc.info/?l=linux-stable-commits=146647471009771=2 -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Re: [PATCH 3.10 099/180] fix d_walk()/non-delayed __d_free() race
This patch for 3.10 branch appears to be missing one important + dentry->d_flags |= DCACHE_RCUACCESS; in fs/dcache.c __d_materialise_dentry() function. When Ben Hutchings backported Al Viro's original fix to stable branches that he maintains, he added that one additional line to both 3.2 and 3.16 branches. Please consider including that additional one line fix for 3.10 stable branch also. Ben Hutchings said this on his 3.2.82-rc1 patch: [bwh: Backported to 3.2: - Adjust context - Also set the flag in __d_materialise_dentry())] http://marc.info/?l=linux-kernel=147117565612275=2 Ben Hutchings said this on his 3.16.37-rc1 patch: [bwh: Backported to 3.16: - Adjust context - Also set the flag in __d_materialise_dentry())] http://marc.info/?l=linux-kernel=147117433412006=2 Also mentioned by Sasha Levin on 3.18 and 4.1 commits: Cc: sta...@vger.kernel.org # v3.2+ (and watch out for __d_materialise_dentry()) http://marc.info/?l=linux-stable-commits=146648034410827=2 http://marc.info/?l=linux-stable-commits=146647471009771=2 -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Announce loop-AES-v3.7i file/swap crypto package
loop-AES changes since previous release: - Worked around block layer interface changes on 4.7 kernels. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7i.tar.bz2 md5sum dd465844a650ea4d4856ee26756a0235 http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7i.tar.bz2.sign -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Announce loop-AES-v3.7i file/swap crypto package
loop-AES changes since previous release: - Worked around block layer interface changes on 4.7 kernels. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7i.tar.bz2 md5sum dd465844a650ea4d4856ee26756a0235 http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7i.tar.bz2.sign -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Announce loop-AES-v3.7h file/swap crypto package
loop-AES changes since previous release: - Worked around block layer interface changes on 4.6 kernels. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7h.tar.bz2 md5sum babef8f6d30ac13db76c8cde0d8879f5 http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7h.tar.bz2.sign -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Announce loop-AES-v3.7h file/swap crypto package
loop-AES changes since previous release: - Worked around block layer interface changes on 4.6 kernels. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7h.tar.bz2 md5sum babef8f6d30ac13db76c8cde0d8879f5 http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7h.tar.bz2.sign -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
Announce loop-AES-v3.7f file/swap crypto package
loop-AES changes since previous release: - Worked around block layer interface changes on 4.3 kernels. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7f.tar.bz2 md5sum 5f50564b9aa67b6c96e363e81899a92c http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7f.tar.bz2.sign -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Announce loop-AES-v3.7f file/swap crypto package
loop-AES changes since previous release: - Worked around block layer interface changes on 4.3 kernels. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7f.tar.bz2 md5sum 5f50564b9aa67b6c96e363e81899a92c http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7f.tar.bz2.sign -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Announce loop-AES-v3.7e file/swap crypto package
loop-AES changes since previous release: - Worked around block layer interface changes on 4.2 kernels. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7e.tar.bz2 md5sum 209fd5f3e658d6527bc1607f8726acda http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7e.tar.bz2.sign -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Announce loop-AES-v3.7e file/swap crypto package
loop-AES changes since previous release: - Worked around block layer interface changes on 4.2 kernels. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7e.tar.bz2 md5sum 209fd5f3e658d6527bc1607f8726acda http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7e.tar.bz2.sign -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.10 14/46] d_walk() might skip too much
On 6/27/15, Greg Kroah-Hartman wrote: > That's insane, and not how my tools work :( I asked you to do that apply-patch-two-more-times thing because I assumed that you trust Al Viro's Signed-off-by more than you trust my Signed-off-by. > Can you provide the needed backport? If it was in an earlier email in > this series, sorry, it's long gone from my mailbox, can you resend it? Willy Tarreau re-posted that patch to you yesterday. No need for me to repeat that here. -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.10 14/46] d_walk() might skip too much
On 6/27/15, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: That's insane, and not how my tools work :( I asked you to do that apply-patch-two-more-times thing because I assumed that you trust Al Viro's Signed-off-by more than you trust my Signed-off-by. Can you provide the needed backport? If it was in an earlier email in this series, sorry, it's long gone from my mailbox, can you resend it? Willy Tarreau re-posted that patch to you yesterday. No need for me to repeat that here. -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.10 14/46] d_walk() might skip too much
On 6/19/15, Greg Kroah-Hartman wrote: > I would much rather just include the "real" upstream patches, instead of > an odd backport. > > Jari, can you just backport the above referenced patches instead and > provide those backports? I won't do that, sorry. It is more complicated than you think. It would involve backporting more VFS-re-write-patch-bombs than would be acceptable to stable kernel branch. Above mentioned d_walk() function that Al Viro modified in mainline don't even exist in 3.10.y and older brances. My understanding is that complete backport of above mentioned "deal with deadlock in d_walk()" and "d_walk() might skip too much" patches to 3.10.y branch is to apply all these patches: (a) backport of "deal with deadlock in d_walk()", by Ben Hutchings (b) dcache: Fix locking bugs in backported "deal with deadlock in d_walk()" (c) Al Viro's "d_walk() might skip too much" applied THREE times. Of those, you merged (a) and (b) to 3.10.76 stable, and one copy of (c) to 3.10.80 stable. The problem is that you didn't realize that "deal with deadlock in d_walk()" was applied to three different places in Ben Hutchings' backport, and that latest Al Viro's fix had to be also applied to three different places. Considering the sh*t that you have to deal with, nobody is blaming you for that mistake. I am asking that you apply Al Viro's original "d_walk() might skip too much" patch TWO more times to 3.10.y stable branch. On both times, your patch tool will find the correct place of source file to modify, but with different offsets each time. -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.10 14/46] d_walk() might skip too much
On 6/19/15, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: I would much rather just include the real upstream patches, instead of an odd backport. Jari, can you just backport the above referenced patches instead and provide those backports? I won't do that, sorry. It is more complicated than you think. It would involve backporting more VFS-re-write-patch-bombs than would be acceptable to stable kernel branch. Above mentioned d_walk() function that Al Viro modified in mainline don't even exist in 3.10.y and older brances. My understanding is that complete backport of above mentioned deal with deadlock in d_walk() and d_walk() might skip too much patches to 3.10.y branch is to apply all these patches: (a) backport of deal with deadlock in d_walk(), by Ben Hutchings (b) dcache: Fix locking bugs in backported deal with deadlock in d_walk() (c) Al Viro's d_walk() might skip too much applied THREE times. Of those, you merged (a) and (b) to 3.10.76 stable, and one copy of (c) to 3.10.80 stable. The problem is that you didn't realize that deal with deadlock in d_walk() was applied to three different places in Ben Hutchings' backport, and that latest Al Viro's fix had to be also applied to three different places. Considering the sh*t that you have to deal with, nobody is blaming you for that mistake. I am asking that you apply Al Viro's original d_walk() might skip too much patch TWO more times to 3.10.y stable branch. On both times, your patch tool will find the correct place of source file to modify, but with different offsets each time. -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.10 14/46] d_walk() might skip too much
When Al Viro's VFS deadlock fix "deal with deadlock in d_walk()" was
backported to 3.10.y 3.4.y and 3.2.y stable kernel brances, the deadlock fix
was copied to 3 different places. Later, a bug in that code was discovered.
Al Viro's fix involved fixing only one part of code in mainline kernel. That
fix is called "d_walk() might skip too much".
3.10.y 3.4.y and 3.2.y stable kernel brances need that later fix copied to 3
different places. Greg Kroah-Hartman included Al Viro's "d_walk() might skip
too much" fix only once in 3.10.80 kernel, leaving 2 more places without a
fix.
The patch below was not written by me. I only applied Al Viro's "d_walk()
might skip too much" fix 2 more times to 3.10.80 kernel, and cheched that
the fixes went to correct places. With this patch applied, all 3 places that
I am aware of 3.10.y stable branch are now fixed.
Signed-off-by: Jari Ruusu
--- linux-3.10.80/fs/dcache.c.OLD 2015-06-11 19:22:31.0 +0300
+++ linux-3.10.80/fs/dcache.c 2015-06-11 19:32:59.0 +0300
@@ -1053,13 +1053,13 @@
/* might go back up the wrong parent if we have had a rename. */
if (!locked && read_seqretry(_lock, seq))
goto rename_retry;
- next = child->d_child.next;
- while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED)) {
+ /* go into the first sibling still alive */
+ do {
+ next = child->d_child.next;
if (next == _parent->d_subdirs)
goto ascend;
child = list_entry(next, struct dentry, d_child);
- next = next->next;
- }
+ } while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED));
rcu_read_unlock();
goto resume;
}
@@ -2977,13 +2977,13 @@
/* might go back up the wrong parent if we have had a rename. */
if (!locked && read_seqretry(_lock, seq))
goto rename_retry;
- next = child->d_child.next;
- while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED)) {
+ /* go into the first sibling still alive */
+ do {
+ next = child->d_child.next;
if (next == _parent->d_subdirs)
goto ascend;
child = list_entry(next, struct dentry, d_child);
- next = next->next;
- }
+ } while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED));
rcu_read_unlock();
goto resume;
}
--
Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.10 14/46] d_walk() might skip too much
When Al Viro's VFS deadlock fix deal with deadlock in d_walk() was
backported to 3.10.y 3.4.y and 3.2.y stable kernel brances, the deadlock fix
was copied to 3 different places. Later, a bug in that code was discovered.
Al Viro's fix involved fixing only one part of code in mainline kernel. That
fix is called d_walk() might skip too much.
3.10.y 3.4.y and 3.2.y stable kernel brances need that later fix copied to 3
different places. Greg Kroah-Hartman included Al Viro's d_walk() might skip
too much fix only once in 3.10.80 kernel, leaving 2 more places without a
fix.
The patch below was not written by me. I only applied Al Viro's d_walk()
might skip too much fix 2 more times to 3.10.80 kernel, and cheched that
the fixes went to correct places. With this patch applied, all 3 places that
I am aware of 3.10.y stable branch are now fixed.
Signed-off-by: Jari Ruusu jariru...@users.sourceforge.net
--- linux-3.10.80/fs/dcache.c.OLD 2015-06-11 19:22:31.0 +0300
+++ linux-3.10.80/fs/dcache.c 2015-06-11 19:32:59.0 +0300
@@ -1053,13 +1053,13 @@
/* might go back up the wrong parent if we have had a rename. */
if (!locked read_seqretry(rename_lock, seq))
goto rename_retry;
- next = child-d_child.next;
- while (unlikely(child-d_flags DCACHE_DENTRY_KILLED)) {
+ /* go into the first sibling still alive */
+ do {
+ next = child-d_child.next;
if (next == this_parent-d_subdirs)
goto ascend;
child = list_entry(next, struct dentry, d_child);
- next = next-next;
- }
+ } while (unlikely(child-d_flags DCACHE_DENTRY_KILLED));
rcu_read_unlock();
goto resume;
}
@@ -2977,13 +2977,13 @@
/* might go back up the wrong parent if we have had a rename. */
if (!locked read_seqretry(rename_lock, seq))
goto rename_retry;
- next = child-d_child.next;
- while (unlikely(child-d_flags DCACHE_DENTRY_KILLED)) {
+ /* go into the first sibling still alive */
+ do {
+ next = child-d_child.next;
if (next == this_parent-d_subdirs)
goto ascend;
child = list_entry(next, struct dentry, d_child);
- next = next-next;
- }
+ } while (unlikely(child-d_flags DCACHE_DENTRY_KILLED));
rcu_read_unlock();
goto resume;
}
--
Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.10 14/46] d_walk() might skip too much
My understanding is that this patch is trying to fix bugs in this commit: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-3.10.y=5f03ac13d87590b0ee879c77e68df63a3d9b3e07 The 3.10.y branch applied the original patch to three different places. Quote from original commit: "As we only have try_to_ascend() and not d_walk(), apply this change to all callers of try_to_ascend()" Shouldn't this "d_walk() might skip too much" fix to 3.10.y branch be applied to all three places too? -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.10 14/46] d_walk() might skip too much
My understanding is that this patch is trying to fix bugs in this commit: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-3.10.yid=5f03ac13d87590b0ee879c77e68df63a3d9b3e07 The 3.10.y branch applied the original patch to three different places. Quote from original commit: As we only have try_to_ascend() and not d_walk(), apply this change to all callers of try_to_ascend() Shouldn't this d_walk() might skip too much fix to 3.10.y branch be applied to all three places too? -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Announce loop-AES-v3.7d file/swap crypto package
loop-AES changes since previous release: - Fixed endianness bug on little-endian PowerPC. More common big-endian PowerPC was OK. Bug reported by Fernando Seiti Furusato. - Worked around VFS changes on 4.1-rc kernels. - Some #ifdef spaghetti removed for 4.x kernels. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7d.tar.bz2 md5sum 78b8d93e4b03a42ef9be99ad1eea7db2 http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7d.tar.bz2.sign -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Announce loop-AES-v3.7d file/swap crypto package
loop-AES changes since previous release: - Fixed endianness bug on little-endian PowerPC. More common big-endian PowerPC was OK. Bug reported by Fernando Seiti Furusato. - Worked around VFS changes on 4.1-rc kernels. - Some #ifdef spaghetti removed for 4.x kernels. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7d.tar.bz2 md5sum 78b8d93e4b03a42ef9be99ad1eea7db2 http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7d.tar.bz2.sign -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: usb serial: pl2303 driver TxD "break" stays after close() bug
On 2/20/15, Johan Hovold wrote: > On Thu, Feb 19, 2015 at 03:38:39PM +0200, Jari Ruusu wrote: >> To clear it, you need to poke it with ioctl(fd, TIOCCBRK, 0) >> or disconnect the device. > > That's definitely a bug. > > Care to test the patch below? Your patch fixes the bug. Thanks. -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: usb serial: pl2303 driver TxD break stays after close() bug
On 2/20/15, Johan Hovold jo...@kernel.org wrote: On Thu, Feb 19, 2015 at 03:38:39PM +0200, Jari Ruusu wrote: To clear it, you need to poke it with ioctl(fd, TIOCCBRK, 0) or disconnect the device. That's definitely a bug. Care to test the patch below? Your patch fixes the bug. Thanks. -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: usb serial: pl2303 driver TxD "break" stays after close() bug
On 2/19/15, Johan Hovold wrote: > What happens when you reopen the port? Is the break state cleared then? Stuck "break" signal is not cleared on re-open. To clear it, you need to poke it with ioctl(fd, TIOCCBRK, 0) or disconnect the device. -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: usb serial: pl2303 driver TxD break stays after close() bug
On 2/19/15, Johan Hovold jo...@kernel.org wrote: What happens when you reopen the port? Is the break state cleared then? Stuck break signal is not cleared on re-open. To clear it, you need to poke it with ioctl(fd, TIOCCBRK, 0) or disconnect the device. -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Announce loop-AES-v3.7c file/swap crypto package
loop-AES changes since previous release: - Makefile changed so that alternative makes can be used. Fix from Alon Bar-Lev. - Worked around vanished #define on 3.19 kernel. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7c.tar.bz2 md5sum 73f1ffbe9108d24e70abc9f06ff3bbc0 http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7c.tar.bz2.sign -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Announce loop-AES-v3.7c file/swap crypto package
loop-AES changes since previous release: - Makefile changed so that alternative makes can be used. Fix from Alon Bar-Lev. - Worked around vanished #define on 3.19 kernel. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7c.tar.bz2 md5sum 73f1ffbe9108d24e70abc9f06ff3bbc0 http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7c.tar.bz2.sign -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
usb serial: pl2303 driver TxD "break" stays after close() bug
Tested on 3.10.67 and 3.18.5 kernels with ATEN UC-232A usb-serial adapter.
No patch, sorry. To actually see the stuck "break" signal on TxD line, you
need either some sort of LED or voltmeter connected to the data transmit
line. Other RS-232 serial ports that I have access to (normal PC hardware
serial ports and FTDI usb-serial adapters) do not have this bug.
/* pl2303 TxD "break" stays after close() demo */
#include
#include
#include
#include
#include
#include
#include
#include
int main(int argc, char **argv)
{
struct termios tt;
int fd;
if(argc < 2) {
fprintf(stderr, "usage: %s /dev/ttyUSB0\n", argv[0]);
exit(1);
}
if((fd = open(argv[1], O_RDWR | O_NOCTTY, 0)) == -1) {
perror("serial port open failed");
exit(1);
}
tcgetattr(fd, );
cfmakeraw();
tcsetattr(fd, TCSANOW, );
if(ioctl(fd, TIOCSBRK, 0) == -1) {
perror("set BRK failed");
exit(1);
}
close(fd);
exit(0);
}
--
Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
usb serial: pl2303 driver TxD break stays after close() bug
Tested on 3.10.67 and 3.18.5 kernels with ATEN UC-232A usb-serial adapter.
No patch, sorry. To actually see the stuck break signal on TxD line, you
need either some sort of LED or voltmeter connected to the data transmit
line. Other RS-232 serial ports that I have access to (normal PC hardware
serial ports and FTDI usb-serial adapters) do not have this bug.
/* pl2303 TxD break stays after close() demo */
#include stdio.h
#include unistd.h
#include sys/types.h
#include sys/stat.h
#include sys/ioctl.h
#include termios.h
#include fcntl.h
#include stdlib.h
int main(int argc, char **argv)
{
struct termios tt;
int fd;
if(argc 2) {
fprintf(stderr, usage: %s /dev/ttyUSB0\n, argv[0]);
exit(1);
}
if((fd = open(argv[1], O_RDWR | O_NOCTTY, 0)) == -1) {
perror(serial port open failed);
exit(1);
}
tcgetattr(fd, tt);
cfmakeraw(tt);
tcsetattr(fd, TCSANOW, tt);
if(ioctl(fd, TIOCSBRK, 0) == -1) {
perror(set BRK failed);
exit(1);
}
close(fd);
exit(0);
}
--
Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Announce loop-AES-v3.7b file/swap crypto package
loop-AES changes since previous release: - Worked around block layer interface changes on 3.14 kernels. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7b.tar.bz2 md5sum 204572f246eddd08705f88189dd3b44d http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7b.tar.bz2.sign I have new release signing key. New key is signed with the old key. -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Announce loop-AES-v3.7b file/swap crypto package
loop-AES changes since previous release: - Worked around block layer interface changes on 3.14 kernels. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7b.tar.bz2 md5sum 204572f246eddd08705f88189dd3b44d http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7b.tar.bz2.sign I have new release signing key. New key is signed with the old key. -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Announce loop-AES-v3.7a file/swap crypto package
loop-AES changes since previous release: - Code and struct cleanup, make it work on 3.11-rc kernels. - Fixed directory permissions bug in util-linux-2.23.2 when "mount -a" set up encrypted file system using ramdom keys. util-linux-2.21.2 and older versions are not affected. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7a.tar.bz2 md5sum f267cb2108ee94b09a30b2fc7e292104 http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7a.tar.bz2.sign -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Announce loop-AES-v3.7a file/swap crypto package
loop-AES changes since previous release: - Code and struct cleanup, make it work on 3.11-rc kernels. - Fixed directory permissions bug in util-linux-2.23.2 when mount -a set up encrypted file system using ramdom keys. util-linux-2.21.2 and older versions are not affected. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7a.tar.bz2 md5sum f267cb2108ee94b09a30b2fc7e292104 http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7a.tar.bz2.sign -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Announce loop-AES-v3.6i file/swap crypto package
loop-AES changes since previous release: - Worked around block layer interface changes on 3.10 kernels. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.6i.tar.bz2 md5sum 105fe6386a159bd36b36444790804485 http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.6i.tar.bz2.sign -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Announce loop-AES-v3.6i file/swap crypto package
loop-AES changes since previous release: - Worked around block layer interface changes on 3.10 kernels. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.6i.tar.bz2 md5sum 105fe6386a159bd36b36444790804485 http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.6i.tar.bz2.sign -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Announce loop-AES-v3.6h file/swap crypto package
loop-AES changes since previous release: - Fixed bug that caused compile failure if kernel configuration has CONFIG_UIDGID_STRICT_TYPE_CHECKS=y. Patch from Hank Leininger. - Worked around block layer interface changes on 3.9 kernels. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.6h.tar.bz2 md5sum 7c5ad5761e58fc8eb0176b00c69b6b75 http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.6h.tar.bz2.sign -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Announce loop-AES-v3.6h file/swap crypto package
loop-AES changes since previous release: - Fixed bug that caused compile failure if kernel configuration has CONFIG_UIDGID_STRICT_TYPE_CHECKS=y. Patch from Hank Leininger. - Worked around block layer interface changes on 3.9 kernels. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.6h.tar.bz2 md5sum 7c5ad5761e58fc8eb0176b00c69b6b75 http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.6h.tar.bz2.sign -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Announce loop-AES-v3.6g file/swap crypto package
loop-AES changes since previous release: - Fixed bug that could cause hang if backing device is stacking device, for example /dev/md* device. Many thanks to Norbert Warmuth for reporting and chasing this bug. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.6g.tar.bz2 md5sum ffe4aee7004cdac8d181f2d64f4d51a8 http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.6g.tar.bz2.sign -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Announce loop-AES-v3.6g file/swap crypto package
loop-AES changes since previous release: - Fixed bug that could cause hang if backing device is stacking device, for example /dev/md* device. Many thanks to Norbert Warmuth for reporting and chasing this bug. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.6g.tar.bz2 md5sum ffe4aee7004cdac8d181f2d64f4d51a8 http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.6g.tar.bz2.sign -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Announce loop-AES-v3.6f file/swap crypto package
loop-AES changes since previous release: - Worked around block layer interface changes on 3.7-rc kernels. - Fixed bug that caused loop device to report un-optimal I/O size on some backing devices. This bug caused bad performance. - Fixed bug that assumed /bin/sh -> bash. For /bin/sh -> dash case some auto-detections failed. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.6f.tar.bz2 md5sum 0b5bfe4538fd8439b84c586846726507 http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.6f.tar.bz2.sign -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Announce loop-AES-v3.6f file/swap crypto package
loop-AES changes since previous release: - Worked around block layer interface changes on 3.7-rc kernels. - Fixed bug that caused loop device to report un-optimal I/O size on some backing devices. This bug caused bad performance. - Fixed bug that assumed /bin/sh - bash. For /bin/sh - dash case some auto-detections failed. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.6f.tar.bz2 md5sum 0b5bfe4538fd8439b84c586846726507 http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.6f.tar.bz2.sign -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Announce loop-AES-v3.2b file/swap crypto package
loop-AES changes since previous release: - Fixed compatibility detection problem involving separate obj/source trees. - Fixed request size problem on unencrypted device backed USB device. - Added initramfs type initrd build option to build-initrd.sh script. Patch from Fix pr0gress0r AT ngs.ru - Added gcc version override option to build-initrd.sh script. - Fixed losetup -P cleartext key option which always failed to work and printed error message saying so. - Added util-linux-ng patch. - Worked around block layer interface breakage on linux-2.6.24-rc1 kernel. bzip2 compressed tarball is here: http://dl.sourceforge.net/sourceforge/loop-aes/loop-AES-v3.2b.tar.bz2 md5sum 2c5642ccfa1a780ef4bd76eb873076aa http://dl.sourceforge.net/sourceforge/loop-aes/loop-AES-v3.2b.tar.bz2.sign -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Announce loop-AES-v3.2b file/swap crypto package
loop-AES changes since previous release: - Fixed compatibility detection problem involving separate obj/source trees. - Fixed request size problem on unencrypted device backed USB device. - Added initramfs type initrd build option to build-initrd.sh script. Patch from Fix pr0gress0r AT ngs.ru - Added gcc version override option to build-initrd.sh script. - Fixed losetup -P cleartext key option which always failed to work and printed error message saying so. - Added util-linux-ng patch. - Worked around block layer interface breakage on linux-2.6.24-rc1 kernel. bzip2 compressed tarball is here: http://dl.sourceforge.net/sourceforge/loop-aes/loop-AES-v3.2b.tar.bz2 md5sum 2c5642ccfa1a780ef4bd76eb873076aa http://dl.sourceforge.net/sourceforge/loop-aes/loop-AES-v3.2b.tar.bz2.sign -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce loop-AES-v3.2a file/swap crypto package
markus reichelt wrote: > * Jari Ruusu <[EMAIL PROTECTED]> wrote: > > loop-AES changes since previous release: > > - loop_twofish.c loop_serpent.c loop_blowfish.c modules included. > > They are not built by default. Add EXTRA_CIPHERS=y make parameter > > to build them. > > Just curious, will the ciphers package also be continued/available > separately as before or is it merged from now on into the loop-aes > package? Since loop-AES package now provides equivalent funtionality, it doesn't make sense to maintain second package providing redundant functionality. The merge was done because of difficulties getting versioned symbols to match between two separately compiled packages. Even if separate package were to be maintained (it won't be), it would not work well with versioned symbols. If you want to blame someone for that, then blame mainline linux kbuild guys. I forgot to clearly say following in loop-AES-v3.2a README: This command builds loop module with AES cipher integrated, as usual: make KEYSCRUB=y LINUX_SOURCE=/some/path/here This command builds loop module with AES cipher integrated, and separate twofish, serpent, and blowfish loop cipher modules: make KEYSCRUB=y EXTRA_CIPHERS=y LINUX_SOURCE=/some/path/here This command builds only twofish, serpent, and blowfish loop cipher modules. This assumes that kernel patch version of loop-AES is being used and is enabled in kernel configuration: make EXTRA_CIPHERS=y BUILD_LOOP=n LINUX_SOURCE=/some/path/here Key scrubbing, as enabled by KEYSCRUB=y make command line parameter, currently only works for AES cipher. It has no effect on twofish, serpent, and blowfish ciphers. -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Announce loop-AES-v3.2a file/swap crypto package
loop-AES changes since previous release: - loop_twofish.c loop_serpent.c loop_blowfish.c modules included. They are not built by default. Add EXTRA_CIPHERS=y make parameter to build them. - Makefile rewritten to always use kbuild method on 2.6 kernels. - Work around invalidate_bdev() changes on recent 2.6 kernels. bzip2 compressed tarball is here: http://osdn.dl.sourceforge.net/sourceforge/loop-aes/loop-AES-v3.2a.tar.bz2 md5sum d0b5b0f104ce0e1ee9e3ba9608f24ec4 http://osdn.dl.sourceforge.net/sourceforge/loop-aes/loop-AES-v3.2a.tar.bz2.sign -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Announce loop-AES-v3.2a file/swap crypto package
loop-AES changes since previous release: - loop_twofish.c loop_serpent.c loop_blowfish.c modules included. They are not built by default. Add EXTRA_CIPHERS=y make parameter to build them. - Makefile rewritten to always use kbuild method on 2.6 kernels. - Work around invalidate_bdev() changes on recent 2.6 kernels. bzip2 compressed tarball is here: http://osdn.dl.sourceforge.net/sourceforge/loop-aes/loop-AES-v3.2a.tar.bz2 md5sum d0b5b0f104ce0e1ee9e3ba9608f24ec4 http://osdn.dl.sourceforge.net/sourceforge/loop-aes/loop-AES-v3.2a.tar.bz2.sign -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce loop-AES-v3.2a file/swap crypto package
markus reichelt wrote: * Jari Ruusu [EMAIL PROTECTED] wrote: loop-AES changes since previous release: - loop_twofish.c loop_serpent.c loop_blowfish.c modules included. They are not built by default. Add EXTRA_CIPHERS=y make parameter to build them. Just curious, will the ciphers package also be continued/available separately as before or is it merged from now on into the loop-aes package? Since loop-AES package now provides equivalent funtionality, it doesn't make sense to maintain second package providing redundant functionality. The merge was done because of difficulties getting versioned symbols to match between two separately compiled packages. Even if separate package were to be maintained (it won't be), it would not work well with versioned symbols. If you want to blame someone for that, then blame mainline linux kbuild guys. I forgot to clearly say following in loop-AES-v3.2a README: This command builds loop module with AES cipher integrated, as usual: make KEYSCRUB=y LINUX_SOURCE=/some/path/here This command builds loop module with AES cipher integrated, and separate twofish, serpent, and blowfish loop cipher modules: make KEYSCRUB=y EXTRA_CIPHERS=y LINUX_SOURCE=/some/path/here This command builds only twofish, serpent, and blowfish loop cipher modules. This assumes that kernel patch version of loop-AES is being used and is enabled in kernel configuration: make EXTRA_CIPHERS=y BUILD_LOOP=n LINUX_SOURCE=/some/path/here Key scrubbing, as enabled by KEYSCRUB=y make command line parameter, currently only works for AES cipher. It has no effect on twofish, serpent, and blowfish ciphers. -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: entropy of /dev/random vs. openssl rand
Gisle Sælensminde wrote: > Some people argue that a periodically reseeded cryptographic-quality > random number generator is as secure as a true random number generator for > all practical purposes. [snip] > I personally can't think of any realistic scenario where /dev/random would > make you safe while /dev/urandom would make you sorry. No problem if cryptographic-quality random number generator is reseeded using high quality entropy. But saving/reseeding PRNG using a plaintext file as most distros seem to do at shutdown and boot does not count as secure. /dev/urandom state may be predictable for some time after boot. /dev/random at least waits for new entropy before handing out random bits, and avoids that predictable state pitfall. Do most distros attempt to overwrite /var/lib/urandom/random-seed or whatever after it has been used to reseed /dev/urandom? Does any distro attempt to overwrite that file? For the record, loop-AES versions of mount/losetup/swapon that set up random key loop devices, use /dev/urandom. But they also attempt to work-around possibly predictable boot-time /dev/urandom bits. The work-around is basically random-seed save/restore (to backing device) but with 20 overwrites of saved-state after it has been used to create new encryption keys. See source for more details. -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: entropy of /dev/random vs. openssl rand
Gisle Sælensminde wrote: Some people argue that a periodically reseeded cryptographic-quality random number generator is as secure as a true random number generator for all practical purposes. [snip] I personally can't think of any realistic scenario where /dev/random would make you safe while /dev/urandom would make you sorry. No problem if cryptographic-quality random number generator is reseeded using high quality entropy. But saving/reseeding PRNG using a plaintext file as most distros seem to do at shutdown and boot does not count as secure. /dev/urandom state may be predictable for some time after boot. /dev/random at least waits for new entropy before handing out random bits, and avoids that predictable state pitfall. Do most distros attempt to overwrite /var/lib/urandom/random-seed or whatever after it has been used to reseed /dev/urandom? Does any distro attempt to overwrite that file? For the record, loop-AES versions of mount/losetup/swapon that set up random key loop devices, use /dev/urandom. But they also attempt to work-around possibly predictable boot-time /dev/urandom bits. The work-around is basically random-seed save/restore (to backing device) but with 20 overwrites of saved-state after it has been used to create new encryption keys. See source for more details. -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Loop device - Tracking page writes made to a loop devicethrough mmap
Kandan Venkataraman wrote: > All comments have been taken care of. Your patch still does not do conversions of existing user space visible 'struct loop_info64' which is pretty much cast in stone. Blindly overwriting larger structure over smaller user space buffer of existing userspace binaries is the wrong way to do this. There was a time when folks at least pretended that breaking user space ABI was not tolerable. -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Loop device - Tracking page writes made to a loop devicethrough mmap
Kandan Venkataraman wrote: All comments have been taken care of. Your patch still does not do conversions of existing user space visible 'struct loop_info64' which is pretty much cast in stone. Blindly overwriting larger structure over smaller user space buffer of existing userspace binaries is the wrong way to do this. There was a time when folks at least pretended that breaking user space ABI was not tolerable. -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: encrypting jffs2 filesystem with DM-crypt or what else?
markus reichelt wrote: > * emin ak <[EMAIL PROTECTED]> wrote: > > I need to encrypt a jffs2/mtd formatted flash filesystem for an > > embedded device, Normally using a loopback interface (cryptoloop, > > DM-crypt or loop-aes) solves this problem but they are not well > > known on journalling file systems (like jffs2) because of cached > > write etc.. Also I could'nt find any guideline for encrypting > > fikesystem on a flash. > > device-backed loops are ok, file-based once aren't. The cache issue > you talk about concerns writing caches of HDDs f.e., I haven't seen a > flash device with writing cache. However, in most cases writing cache > can be turned off. Flash devices behave differently than hard disks. If I remember correcly, bits can be flipped in one direction (set or reset) without erasing whole block, but flipping a bit in reverse direction requires that whole block be erased first. If jffs2 takes advantage of this one-direction-bit-flipping, then adding encryption layer between jffs2 and flash device makes it completely different game that is guaranteed to require lots of flash block erases that wears down the device much faster than expected. -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: encrypting jffs2 filesystem with DM-crypt or what else?
markus reichelt wrote: * emin ak [EMAIL PROTECTED] wrote: I need to encrypt a jffs2/mtd formatted flash filesystem for an embedded device, Normally using a loopback interface (cryptoloop, DM-crypt or loop-aes) solves this problem but they are not well known on journalling file systems (like jffs2) because of cached write etc.. Also I could'nt find any guideline for encrypting fikesystem on a flash. device-backed loops are ok, file-based once aren't. The cache issue you talk about concerns writing caches of HDDs f.e., I haven't seen a flash device with writing cache. However, in most cases writing cache can be turned off. Flash devices behave differently than hard disks. If I remember correcly, bits can be flipped in one direction (set or reset) without erasing whole block, but flipping a bit in reverse direction requires that whole block be erased first. If jffs2 takes advantage of this one-direction-bit-flipping, then adding encryption layer between jffs2 and flash device makes it completely different game that is guaranteed to require lots of flash block erases that wears down the device much faster than expected. -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Announce loop-AES-v3.1f file/swap crypto package
loop-AES changes since previous release: - Work around dash /bin/sh shell and make-3.81 incompatibilities. - Work around block layer breakage in 2.6.20-rcX-mmX kernels. - Added "cleartextkey=file" mount option to mount, and "-P file" command line option to losetup. These options help automounters. - Added loop-aes-keygen script from Max Vozeler. bzip2 compressed tarball is here: http://osdn.dl.sourceforge.net/sourceforge/loop-aes/loop-AES-v3.1f.tar.bz2 md5sum 1020b93d723f1d573bacfe4a3362fc25 http://osdn.dl.sourceforge.net/sourceforge/loop-aes/loop-AES-v3.1f.tar.bz2.sign Additional ciphers package changes since previous release: - Work around dash /bin/sh shell and make-3.81 incompatibilities. bzip2 compressed tarball is here: http://osdn.dl.sourceforge.net/sourceforge/loop-aes/ciphers-v3.0e.tar.bz2 md5sum 10aeb23387a1e2d635cfe9345c21b444 http://osdn.dl.sourceforge.net/sourceforge/loop-aes/ciphers-v3.0e.tar.bz2.sign Note: As of this writing, files at http://loop-aes.sourceforge.net/ have not been updated yet. -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Announce loop-AES-v3.1f file/swap crypto package
loop-AES changes since previous release: - Work around dash /bin/sh shell and make-3.81 incompatibilities. - Work around block layer breakage in 2.6.20-rcX-mmX kernels. - Added cleartextkey=file mount option to mount, and -P file command line option to losetup. These options help automounters. - Added loop-aes-keygen script from Max Vozeler. bzip2 compressed tarball is here: http://osdn.dl.sourceforge.net/sourceforge/loop-aes/loop-AES-v3.1f.tar.bz2 md5sum 1020b93d723f1d573bacfe4a3362fc25 http://osdn.dl.sourceforge.net/sourceforge/loop-aes/loop-AES-v3.1f.tar.bz2.sign Additional ciphers package changes since previous release: - Work around dash /bin/sh shell and make-3.81 incompatibilities. bzip2 compressed tarball is here: http://osdn.dl.sourceforge.net/sourceforge/loop-aes/ciphers-v3.0e.tar.bz2 md5sum 10aeb23387a1e2d635cfe9345c21b444 http://osdn.dl.sourceforge.net/sourceforge/loop-aes/ciphers-v3.0e.tar.bz2.sign Note: As of this writing, files at http://loop-aes.sourceforge.net/ have not been updated yet. -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Announce loop-AES-v3.0c file/swap crypto package
loop-AES changes since previous release: - Changed gpg pipe code in losetup/mount to use '--no-options' instead of '--options /dev/null'. Fix from Lars Packschies. - Changed losetup/mount programs to warn about unknown key data format. - Added workaround for vanished QUEUE_FLAG_ORDERED define in 2.6.11-rc3-mm1 kernel. - Changed gcc command line parameter order to be same as in kernel Makefile. Wrong parameter order caused miscompilation with Xen architecture (2.6 kernels). bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.0c.tar.bz2 md5sum 3ba40e971da6a18df3e82fbbd3795ac8 http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.0c.tar.bz2.sign Additional ciphers package changes since previous release: - Changed gcc command line parameter order to be same as in kernel Makefile. Wrong parameter order caused miscompilation with Xen architecture (2.6 kernels). bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/ciphers/ciphers-v3.0b.tar.bz2 md5sum 603b188299dfbe1d05e3bca7d281a9a2 http://loop-aes.sourceforge.net/ciphers/ciphers-v3.0b.tar.bz2.sign -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Announce loop-AES-v3.0c file/swap crypto package
loop-AES changes since previous release: - Changed gpg pipe code in losetup/mount to use '--no-options' instead of '--options /dev/null'. Fix from Lars Packschies. - Changed losetup/mount programs to warn about unknown key data format. - Added workaround for vanished QUEUE_FLAG_ORDERED define in 2.6.11-rc3-mm1 kernel. - Changed gcc command line parameter order to be same as in kernel Makefile. Wrong parameter order caused miscompilation with Xen architecture (2.6 kernels). bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.0c.tar.bz2 md5sum 3ba40e971da6a18df3e82fbbd3795ac8 http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.0c.tar.bz2.sign Additional ciphers package changes since previous release: - Changed gcc command line parameter order to be same as in kernel Makefile. Wrong parameter order caused miscompilation with Xen architecture (2.6 kernels). bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/ciphers/ciphers-v3.0b.tar.bz2 md5sum 603b188299dfbe1d05e3bca7d281a9a2 http://loop-aes.sourceforge.net/ciphers/ciphers-v3.0b.tar.bz2.sign -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce loop-AES-v3.0b file/swap crypto package
jerome etienne wrote: > 3 years ago i published a paper describing how an attacker would be able > to modify the content of the encrypted device without being detected. > http://off.net/~jme/loopdev_vul.html > > i was just curious about the current state of loop-aes. Is it still > vulnerable to this attack ? Quote from loop-AES README file " Loop device encrypts data but does not authenticate ciphertext. In other words, it delivers data privacy, but does not guarantee that data has not been tampered with. Admins setting up encrypted file systems should ensure that neither ciphertext, nor tools used to access ciphertext (kernel + kernel modules, mount, losetup, and other utilities) can be trojaned or tampered. " -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce loop-AES-v3.0b file/swap crypto package
Fruhwirth Clemens wrote: > Nothing about kernel crypto is backdoored. If Ruusu thinks different, he > should show me source code. Till then, treat it as FUD. I have been submitting fix for this weakness to mainline mount (part of util-linux package) since 2001, about 2 or 3 times a year. Refusing to fix it for *years* counts as intentional backdoor. You call it whatever you want. I call it backdoor. -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce loop-AES-v3.0b file/swap crypto package
Fruhwirth Clemens wrote: Nothing about kernel crypto is backdoored. If Ruusu thinks different, he should show me source code. Till then, treat it as FUD. I have been submitting fix for this weakness to mainline mount (part of util-linux package) since 2001, about 2 or 3 times a year. Refusing to fix it for *years* counts as intentional backdoor. You call it whatever you want. I call it backdoor. -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce loop-AES-v3.0b file/swap crypto package
jerome etienne wrote: 3 years ago i published a paper describing how an attacker would be able to modify the content of the encrypted device without being detected. http://off.net/~jme/loopdev_vul.html i was just curious about the current state of loop-aes. Is it still vulnerable to this attack ? Quote from loop-AES README file Loop device encrypts data but does not authenticate ciphertext. In other words, it delivers data privacy, but does not guarantee that data has not been tampered with. Admins setting up encrypted file systems should ensure that neither ciphertext, nor tools used to access ciphertext (kernel + kernel modules, mount, losetup, and other utilities) can be trojaned or tampered. -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce loop-AES-v3.0b file/swap crypto package
Bill Davidsen wrote: > Is this eventually going in the mainline kernel? I'd like to use it, but > if I'm going to have to maintain my own crypto kernels indefinitely this > probably isn't the one for me. Unlikely to go to mainline kernel. Mainline folks are just too much in love with their backdoored device crypto implementations [1]. If you want strong device crypto in mainline kernel, maybe you should take a look at FreeBSD gbde. [1] http://marc.theaimsgroup.com/?l=linux-kernel=107419912024246=2 -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce loop-AES-v3.0b file/swap crypto package
Bill Davidsen wrote: Is this eventually going in the mainline kernel? I'd like to use it, but if I'm going to have to maintain my own crypto kernels indefinitely this probably isn't the one for me. Unlikely to go to mainline kernel. Mainline folks are just too much in love with their backdoored device crypto implementations [1]. If you want strong device crypto in mainline kernel, maybe you should take a look at FreeBSD gbde. [1] http://marc.theaimsgroup.com/?l=linux-kernelm=107419912024246w=2 -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Announce loop-AES-v3.0b file/swap crypto package
loop-AES changes since previous release: - Fixed externally compiled module version multi-key-v3 ioctl incompatibility with boxes running 64 bit kernel and 32 bit userland. Kernel patch versions were not affected (2.4 and 2.6 kernels). - Fixed bug that made v3 on-disk format always use file backed code path on some 2.6 kernels that did not have LO_FLAGS_DO_BMAP defined. No data loss, but file backed code path is not journaled file system safe. Same bug also had cosmetic side effect of "losetup -a" status query always displaying file backed v2 on-disk format as v3 on-disk format. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.0b.tar.bz2 md5sum b295ff982cd4503603b38fdc54e604cc http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.0b.tar.bz2.sign -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Announce loop-AES-v3.0b file/swap crypto package
loop-AES changes since previous release: - Fixed externally compiled module version multi-key-v3 ioctl incompatibility with boxes running 64 bit kernel and 32 bit userland. Kernel patch versions were not affected (2.4 and 2.6 kernels). - Fixed bug that made v3 on-disk format always use file backed code path on some 2.6 kernels that did not have LO_FLAGS_DO_BMAP defined. No data loss, but file backed code path is not journaled file system safe. Same bug also had cosmetic side effect of losetup -a status query always displaying file backed v2 on-disk format as v3 on-disk format. bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.0b.tar.bz2 md5sum b295ff982cd4503603b38fdc54e604cc http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.0b.tar.bz2.sign -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: loop device corruption in 2.4.6
Mark Swanson wrote: > I get repeatable errors with 2.4.6 patched with the international encryption > patch patch-int-2.4.3.1.bz2 when building loop device filesystems on top of > Reiserfs. International crypto patch assumes that block size never changes. Everyone and their brother knows that it isn't true. And when block size does get changed, international crypto patch gets the IV completely wrong, and corrupts your data. To see block size changes in file systems alone, use command something like this: grep set_blocksize `find /usr/src/linux-2.4.6/fs -name "*.c" -print` And the block size thing is not the only thing wrong with international crypto patch. The whole cryptoapi thing is just bloat that does not belong in kernel. Cipher name string to number code mappings should be done in user space instead of kernel. And the ice on the cake is that cryptoapi ciphers are non-re-entrant and are actually used in re-entrant code path. This non-re-entrant code in re-entrant code path is another source of data corruption. Loop-AES is a superior replacement for international crypto patch, for more information about loop-AES, see this announcement: http://mail.nl.linux.org/linux-crypto/2001-06/msg00016.html http://lwn.net/2001/0628/a/file-crypto.php3 Regards, Jari Ruusu <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: loop device corruption in 2.4.6
Mark Swanson wrote: I get repeatable errors with 2.4.6 patched with the international encryption patch patch-int-2.4.3.1.bz2 when building loop device filesystems on top of Reiserfs. International crypto patch assumes that block size never changes. Everyone and their brother knows that it isn't true. And when block size does get changed, international crypto patch gets the IV completely wrong, and corrupts your data. To see block size changes in file systems alone, use command something like this: grep set_blocksize `find /usr/src/linux-2.4.6/fs -name *.c -print` And the block size thing is not the only thing wrong with international crypto patch. The whole cryptoapi thing is just bloat that does not belong in kernel. Cipher name string to number code mappings should be done in user space instead of kernel. And the ice on the cake is that cryptoapi ciphers are non-re-entrant and are actually used in re-entrant code path. This non-re-entrant code in re-entrant code path is another source of data corruption. Loop-AES is a superior replacement for international crypto patch, for more information about loop-AES, see this announcement: http://mail.nl.linux.org/linux-crypto/2001-06/msg00016.html http://lwn.net/2001/0628/a/file-crypto.php3 Regards, Jari Ruusu [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: loop device broken in 2.4.6-pre5
Anton Altaparmakov wrote: > At 18:59 26/06/2001, Jari Ruusu wrote: > >[EMAIL PROTECTED] wrote: > > > From [EMAIL PROTECTED] Tue Jun 26 10:20:51 2001 > > > > > > This patch fixes the problem. Please consider applying. > > > > > > --- linux-2.4.6-pre5/drivers/block/loop.cSat Jun 23 07:52:39 2001 > > > +++ linux/drivers/block/loop.cTue Jun 26 09:21:47 2001 > > > @@ -653,7 +653,7 @@ > > > bs = 0; > > > if (blksize_size[MAJOR(lo_device)]) > > > bs = blksize_size[MAJOR(lo_device)][MINOR(lo_device)]; > > > -if (!bs) > > > +if (!bs || S_ISREG(inode->i_mode)) > > > bs = BLOCK_SIZE; > > > > > > set_blocksize(dev, bs); > > > > > > But why 1024? Next week your neighbour comes and has a file-backed > > > loop device with an odd number of 512-byte sectors. > > > If you want a guarantee, then I suppose one should pick 512. > > > (Or make the set blocksize ioctl also work on loop devices.) > > > >Because 1024 was the previous default. Keeping the same default that was > >used before offers least surprises to users and tools. > > But also makes it not work for odd number of sectors which is much worse IMHO. > > Also it is far more surprising to find that the last sector is lost > silently than to have a difference in behaviour, incorrect behaviour needs > to be corrected not kept for backwards compatibility till the end of time. > And the sooner that happens, the better. Both people and utilities will get > used to it. Due to that 1024, mkntfs has to mark the disk dirty because it > can never be sure just how many sectors there really are and hence can't be > sure whether the backup boot sector was written to the correct place or not... > > Also, the loop device is currently not consistent with the rest of the kernel: > > * kernel physical block device: get_nr_sectors_sys_call returns the real > number of 512 byte sectors > * file mounted on loop device: sam sys_call returns the number of sectors & ~1. > > This difference in behaviour causes a much bigger surprise than anything > else if we are talking about surprises! OK. My original complaint was that the default could be larger than 1024. I am happy with 512. Regards, Jari Ruusu <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: loop device broken in 2.4.6-pre5
Anton Altaparmakov wrote: At 18:59 26/06/2001, Jari Ruusu wrote: [EMAIL PROTECTED] wrote: From [EMAIL PROTECTED] Tue Jun 26 10:20:51 2001 This patch fixes the problem. Please consider applying. --- linux-2.4.6-pre5/drivers/block/loop.cSat Jun 23 07:52:39 2001 +++ linux/drivers/block/loop.cTue Jun 26 09:21:47 2001 @@ -653,7 +653,7 @@ bs = 0; if (blksize_size[MAJOR(lo_device)]) bs = blksize_size[MAJOR(lo_device)][MINOR(lo_device)]; -if (!bs) +if (!bs || S_ISREG(inode-i_mode)) bs = BLOCK_SIZE; set_blocksize(dev, bs); But why 1024? Next week your neighbour comes and has a file-backed loop device with an odd number of 512-byte sectors. If you want a guarantee, then I suppose one should pick 512. (Or make the set blocksize ioctl also work on loop devices.) Because 1024 was the previous default. Keeping the same default that was used before offers least surprises to users and tools. But also makes it not work for odd number of sectors which is much worse IMHO. Also it is far more surprising to find that the last sector is lost silently than to have a difference in behaviour, incorrect behaviour needs to be corrected not kept for backwards compatibility till the end of time. And the sooner that happens, the better. Both people and utilities will get used to it. Due to that 1024, mkntfs has to mark the disk dirty because it can never be sure just how many sectors there really are and hence can't be sure whether the backup boot sector was written to the correct place or not... Also, the loop device is currently not consistent with the rest of the kernel: * kernel physical block device: get_nr_sectors_sys_call returns the real number of 512 byte sectors * file mounted on loop device: sam sys_call returns the number of sectors ~1. This difference in behaviour causes a much bigger surprise than anything else if we are talking about surprises! OK. My original complaint was that the default could be larger than 1024. I am happy with 512. Regards, Jari Ruusu [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: loop device broken in 2.4.6-pre5
[EMAIL PROTECTED] wrote: > From [EMAIL PROTECTED] Tue Jun 26 10:20:51 2001 > > This patch fixes the problem. Please consider applying. > > --- linux-2.4.6-pre5/drivers/block/loop.cSat Jun 23 07:52:39 2001 > +++ linux/drivers/block/loop.cTue Jun 26 09:21:47 2001 > @@ -653,7 +653,7 @@ > bs = 0; > if (blksize_size[MAJOR(lo_device)]) > bs = blksize_size[MAJOR(lo_device)][MINOR(lo_device)]; > -if (!bs) > +if (!bs || S_ISREG(inode->i_mode)) > bs = BLOCK_SIZE; > > set_blocksize(dev, bs); > > But why 1024? Next week your neighbour comes and has a file-backed > loop device with an odd number of 512-byte sectors. > If you want a guarantee, then I suppose one should pick 512. > (Or make the set blocksize ioctl also work on loop devices.) Because 1024 was the previous default. Keeping the same default that was used before offers least surprises to users and tools. Regards, Jari Ruusu <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
