[PATCH resend] scripts: teach extract-vmlinux about LZ4 and ZSTD

Note that the LZ4 signature is different than that of modern LZ4 as we use the "legacy" format which suffers from some downsides like inability to disable compression. Signed-off-by: Adam Borowski --- The first time this was sent I managed to screw up both the subject and scissors lin

Re: [PATCH v2 0/4] have the vt console preserve unicode characters

On Wed, Jun 20, 2018 at 10:59:08PM -0400, Nicolas Pitre wrote: > On Thu, 21 Jun 2018, Adam Borowski wrote: > > > On Tue, Jun 19, 2018 at 11:34:34AM -0400, Nicolas Pitre wrote: > > > On Tue, 19 Jun 2018, Adam Borowski wrote: > > > > Thus, it'd be nice to use the st

Re: [PATCH v2 0/4] have the vt console preserve unicode characters

On Wed, Jun 20, 2018 at 10:59:08PM -0400, Nicolas Pitre wrote: > On Thu, 21 Jun 2018, Adam Borowski wrote: > > > On Tue, Jun 19, 2018 at 11:34:34AM -0400, Nicolas Pitre wrote: > > > On Tue, 19 Jun 2018, Adam Borowski wrote: > > > > Thus, it'd be nice to use the st

Re: [PATCH v2 0/4] have the vt console preserve unicode characters

On Wed, Jun 20, 2018 at 10:21:37PM -0400, Dave Mielke wrote: > [quoted lines by Adam Borowski on 2018/06/21 at 03:43 +0200] > > >It's meant for displaying braille to _sighted_ people. And in real world, > >the main [ab]use is a way to show images that won't get corrupted by >

Re: [PATCH v2 0/4] have the vt console preserve unicode characters

On Wed, Jun 20, 2018 at 10:21:37PM -0400, Dave Mielke wrote: > [quoted lines by Adam Borowski on 2018/06/21 at 03:43 +0200] > > >It's meant for displaying braille to _sighted_ people. And in real world, > >the main [ab]use is a way to show images that won't get corrupted by >

Re: [PATCH v2 0/4] have the vt console preserve unicode characters

On Tue, Jun 19, 2018 at 11:34:34AM -0400, Nicolas Pitre wrote: > On Tue, 19 Jun 2018, Adam Borowski wrote: > > Thus, it'd be nice to use the structure you add to implement full Unicode > > range for the vast majority of people. This includes even U+2800..FF. :) > > Be

Re: [PATCH v2 0/4] have the vt console preserve unicode characters

On Tue, Jun 19, 2018 at 11:34:34AM -0400, Nicolas Pitre wrote: > On Tue, 19 Jun 2018, Adam Borowski wrote: > > Thus, it'd be nice to use the structure you add to implement full Unicode > > range for the vast majority of people. This includes even U+2800..FF. :) > > Be

Re: [PATCH v2 0/4] have the vt console preserve unicode characters

On Tue, Jun 19, 2018 at 09:52:13AM -0400, Dave Mielke wrote: > [quoted lines by Adam Borowski on 2018/06/19 at 15:09 +0200] > > >You're thinking small. That 256 possible values for Braille are easily > >encodable within the 512-glyph space (256 char + stolen fg brightness b

Re: [PATCH v2 0/4] have the vt console preserve unicode characters

On Tue, Jun 19, 2018 at 09:52:13AM -0400, Dave Mielke wrote: > [quoted lines by Adam Borowski on 2018/06/19 at 15:09 +0200] > > >You're thinking small. That 256 possible values for Braille are easily > >encodable within the 512-glyph space (256 char + stolen fg brightness b

Re: [PATCH v2 0/4] have the vt console preserve unicode characters

On Sun, Jun 17, 2018 at 03:07:02PM -0400, Nicolas Pitre wrote: > The vt code translates UTF-8 strings into glyph index values and stores > those glyph values directly in the screen buffer. Because there can only > be at most 512 glyphs, it is impossible to represent most unicode > characters, in

Re: [PATCH v2 0/4] have the vt console preserve unicode characters

On Sun, Jun 17, 2018 at 03:07:02PM -0400, Nicolas Pitre wrote: > The vt code translates UTF-8 strings into glyph index values and stores > those glyph values directly in the screen buffer. Because there can only > be at most 512 glyphs, it is impossible to represent most unicode > characters, in

On Tue, Apr 24, 2018 at 11:08:34AM +0200, Paul Menzel wrote:

0886e965e7aeae8d3729c4bacf614a19e103cea Mon Sep 17 00:00:00 2001 From: Adam Borowski <kilob...@angband.pl> Date: Wed, 25 Apr 2018 02:29:18 +0200 Subject: [PATCH] scripts: teach extract-vmlinux about LZ4 and ZSTD Note that the LZ4 signature is different than that of modern LZ4 as we us

On Tue, Apr 24, 2018 at 11:08:34AM +0200, Paul Menzel wrote:

0886e965e7aeae8d3729c4bacf614a19e103cea Mon Sep 17 00:00:00 2001 From: Adam Borowski Date: Wed, 25 Apr 2018 02:29:18 +0200 Subject: [PATCH] scripts: teach extract-vmlinux about LZ4 and ZSTD Note that the LZ4 signature is different than that of modern LZ4 as we use the "legacy" format

Re: How to disable Linux kernel self-extraction (KERNEL_GZIP, KERNEL_BZIP2, …)?

On Tue, Apr 24, 2018 at 11:08:34AM +0200, Paul Menzel wrote: > On 04/24/18 04:08, Adam Borowski wrote: > > On Mon, Apr 23, 2018 at 07:02:30PM +0200, Pavel Machek wrote: > > > > > > > I try to decrease boot time, and my system has an SSD and enough > > > >

Re: How to disable Linux kernel self-extraction (KERNEL_GZIP, KERNEL_BZIP2, …)?

On Tue, Apr 24, 2018 at 11:08:34AM +0200, Paul Menzel wrote: > On 04/24/18 04:08, Adam Borowski wrote: > > On Mon, Apr 23, 2018 at 07:02:30PM +0200, Pavel Machek wrote: > > > > > > > I try to decrease boot time, and my system has an SSD and enough > > > >

Re: How to disable Linux kernel self-extraction (KERNEL_GZIP, KERNEL_BZIP2, …)?

On Mon, Apr 23, 2018 at 07:02:30PM +0200, Pavel Machek wrote: > > > >>I try to decrease boot time, and my system has an SSD and enough space, > > > >>so > > > >>loading 18 instead of 12 MB doesn’t make a difference, but the > > > >>self-extraction is noticeable. So, I like to disable it. > > > >

Re: How to disable Linux kernel self-extraction (KERNEL_GZIP, KERNEL_BZIP2, …)?

On Mon, Apr 23, 2018 at 07:02:30PM +0200, Pavel Machek wrote: > > > >>I try to decrease boot time, and my system has an SSD and enough space, > > > >>so > > > >>loading 18 instead of 12 MB doesn’t make a difference, but the > > > >>self-extraction is noticeable. So, I like to disable it. > > > >

Re: [PATCH 1/2] lib: vsprintf: Implement %pCOW

On Sun, Apr 01, 2018 at 10:56:21AM +0200, Richard Weinberger wrote: > + .cow_lines = { > + "\\ ^__^", > + " \\ (oo)\\___", > + "(__)\\ )\\/\\", > + "||w |", > +

Re: [PATCH 1/2] lib: vsprintf: Implement %pCOW

On Sun, Apr 01, 2018 at 10:56:21AM +0200, Richard Weinberger wrote: > + .cow_lines = { > + "\\ ^__^", > + " \\ (oo)\\___", > + "(__)\\ )\\/\\", > + "||w |", > +

Re: [RFC] new SYSCALL_DEFINE/COMPAT_SYSCALL_DEFINE wrappers

On Fri, Mar 30, 2018 at 12:58:02PM +0200, Ingo Molnar wrote: > * John Paul Adrian Glaubitz wrote: > > > On 03/27/2018 12:40 PM, Linus Torvalds wrote: > > > On Mon, Mar 26, 2018 at 4:37 PM, John Paul Adrian Glaubitz > > > wrote: > > >>

Re: [RFC] new SYSCALL_DEFINE/COMPAT_SYSCALL_DEFINE wrappers

On Fri, Mar 30, 2018 at 12:58:02PM +0200, Ingo Molnar wrote: > * John Paul Adrian Glaubitz wrote: > > > On 03/27/2018 12:40 PM, Linus Torvalds wrote: > > > On Mon, Mar 26, 2018 at 4:37 PM, John Paul Adrian Glaubitz > > > wrote: > > >> > > >> What about a tarball with a minimal Debian x32

Re: [RESEND PATCH v2 0/2] Add support for ZSTD-compressed kernel

On Thu, Mar 22, 2018 at 12:09:45PM +0100, René Rebe wrote: > Should this currently just work without any arch change on e.g. > ppc64, sparc64 et al.? I could do a test build and boot if that is > of any value, ... Initrd: no reason it wouldn't work, although for anything related to the boot

Re: [RESEND PATCH v2 0/2] Add support for ZSTD-compressed kernel

On Thu, Mar 22, 2018 at 12:09:45PM +0100, René Rebe wrote: > Should this currently just work without any arch change on e.g. > ppc64, sparc64 et al.? I could do a test build and boot if that is > of any value, ... Initrd: no reason it wouldn't work, although for anything related to the boot

Re: [RESEND PATCH v2 0/2] Add support for ZSTD-compressed kernel

On Wed, Mar 21, 2018 at 06:29:41PM -0700, Nick Terrell wrote: > This patch set adds support for a ZSTD-compressed kernel and ramdisk > images in the kernel boot process. It only integrates the support with > x86, though the first patch is generic to all architectures. I'm running this patch set

Re: [RESEND PATCH v2 0/2] Add support for ZSTD-compressed kernel

On Wed, Mar 21, 2018 at 06:29:41PM -0700, Nick Terrell wrote: > This patch set adds support for a ZSTD-compressed kernel and ramdisk > images in the kernel boot process. It only integrates the support with > x86, though the first patch is generic to all architectures. I'm running this patch set

[PATCH] [NOT FOR MERGING] lib: Be noisy about used decompression method.

It's too easy to build the initrd with wrong options during testing, after which it may silently work anyway. Signed-off-by: Adam Borowski <kilob...@angband.pl> --- lib/decompress.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lib/decompress.c b/lib/decompress.c

[PATCH] [NOT FOR MERGING] lib: Be noisy about used decompression method.

It's too easy to build the initrd with wrong options during testing, after which it may silently work anyway. Signed-off-by: Adam Borowski --- lib/decompress.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lib/decompress.c b/lib/decompress.c index ab3fc90ffc64

Re: [PATCH 1/2] vsprintf: distinguish between (null), (err) and (invalid) pointer derefs

On Wed, Mar 07, 2018 at 03:17:19PM +0200, Andy Shevchenko wrote: > On Tue, 2018-03-06 at 19:11 +0100, Adam Borowski wrote: > > Thanks for the patch, my comments below. (Review snipped.) It looks pretty obvious that it'd take a lot less of your time to roll new patch[es] from scratch th

Re: [PATCH 1/2] vsprintf: distinguish between (null), (err) and (invalid) pointer derefs

On Wed, Mar 07, 2018 at 03:17:19PM +0200, Andy Shevchenko wrote: > On Tue, 2018-03-06 at 19:11 +0100, Adam Borowski wrote: > > Thanks for the patch, my comments below. (Review snipped.) It looks pretty obvious that it'd take a lot less of your time to roll new patch[es] from scratch th

Re: [PATCH 1/2] vsprintf: distinguish between (null), (err) and (invalid) pointer derefs

On Tue, Mar 06, 2018 at 09:22:17PM +0300, Alexey Dobriyan wrote: > > +#define BAD_PTR_STRING(x) (!(x) ? "(null)" : IS_ERR(x) ? "(err)" : > > "(invalid)") > > This is getting ridiculous. > > Instead of simply printing a pointer as %08lx or %016llx, not only glibc > (null) stupidity is propagated

Re: [PATCH 1/2] vsprintf: distinguish between (null), (err) and (invalid) pointer derefs

On Tue, Mar 06, 2018 at 09:22:17PM +0300, Alexey Dobriyan wrote: > > +#define BAD_PTR_STRING(x) (!(x) ? "(null)" : IS_ERR(x) ? "(err)" : > > "(invalid)") > > This is getting ridiculous. > > Instead of simply printing a pointer as %08lx or %016llx, not only glibc > (null) stupidity is propagated

[PATCH 1/2] vsprintf: distinguish between (null), (err) and (invalid) pointer derefs

Attempting to print an object pointed to by a bad (usually ERR_PTR) pointer is a not so surprising error. Our code handles them inconsistently: * two places print (null) if ptr --- lib/vsprintf.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/lib/vsprintf.c

[PATCH 1/2] vsprintf: distinguish between (null), (err) and (invalid) pointer derefs

Attempting to print an object pointed to by a bad (usually ERR_PTR) pointer is a not so surprising error. Our code handles them inconsistently: * two places print (null) if ptr --- lib/vsprintf.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/lib/vsprintf.c

[PATCH 2/2] vsprintf: don't dereference pointers to the first or last page

As old code to avoid so is inconsistent, let's unify it within a single macro. Signed-off-by: Adam Borowski <kilob...@angband.pl> --- lib/vsprintf.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/lib/vsprintf.c b/lib/vsprintf.c index 1c2c3cc5a321..4914da

[PATCH 2/2] vsprintf: don't dereference pointers to the first or last page

As old code to avoid so is inconsistent, let's unify it within a single macro. Signed-off-by: Adam Borowski --- lib/vsprintf.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/lib/vsprintf.c b/lib/vsprintf.c index 1c2c3cc5a321..4914dac03f0a 100644 --- a/lib

Re: Removing architectures without upstream gcc support

On Fri, Feb 23, 2018 at 02:32:08PM -0500, James Bottomley wrote: > On Fri, 2018-02-23 at 18:19 +, Al Viro wrote: > [...] > > IIRC, parisc/qemu stuff had been announced a while ago; > > I have, but it didn't work sufficiently for me to either boot a kernel > using system emulation or start an

Re: Removing architectures without upstream gcc support

On Fri, Feb 23, 2018 at 02:32:08PM -0500, James Bottomley wrote: > On Fri, 2018-02-23 at 18:19 +, Al Viro wrote: > [...] > > IIRC, parisc/qemu stuff had been announced a while ago; > > I have, but it didn't work sufficiently for me to either boot a kernel > using system emulation or start an

Re: [PATCH 00/31 v2] PTI support for x86_32

On Sat, Feb 10, 2018 at 12:22:59PM -0800, Linus Torvalds wrote: > On Sat, Feb 10, 2018 at 1:15 AM, Adam Borowski <kilob...@angband.pl> wrote: > > > > Alas, we got some data: > > https://popcon.debian.org/ says 20% of x86 users have i386 as their main ABI > > (curr

Re: [PATCH 00/31 v2] PTI support for x86_32

On Sat, Feb 10, 2018 at 12:22:59PM -0800, Linus Torvalds wrote: > On Sat, Feb 10, 2018 at 1:15 AM, Adam Borowski wrote: > > > > Alas, we got some data: > > https://popcon.debian.org/ says 20% of x86 users have i386 as their main ABI > > (current; people with

Re: [PATCH 00/31 v2] PTI support for x86_32

On Fri, Feb 09, 2018 at 08:11:12PM +0100, Joerg Roedel wrote: > On Fri, Feb 09, 2018 at 05:47:43PM +, Andy Lutomirski wrote: > > One thing worth noting is that performance of this whole series is > > going to be abysmal due to the complete lack of 32-bit PCID. Maybe > > any kernel built with

Re: [PATCH 00/31 v2] PTI support for x86_32

On Fri, Feb 09, 2018 at 08:11:12PM +0100, Joerg Roedel wrote: > On Fri, Feb 09, 2018 at 05:47:43PM +, Andy Lutomirski wrote: > > One thing worth noting is that performance of this whole series is > > going to be abysmal due to the complete lack of 32-bit PCID. Maybe > > any kernel built with

Re: [PATCH v2 0/4] ARM/arm64: exynos: Fix missing missing reg warning for syscon restart nodes

On Thu, Feb 08, 2018 at 02:46:32PM +0100, Marek Szyprowski wrote: > Hi Krzysztof, > > On 2018-01-30 22:18, Krzysztof Kozlowski wrote: > > Hi, > > > > Changes since v1: > > 1. New patch (1/4) calling devm_of_platform_populate() in PMU driver, > > following Rob's advice. > > 2. The DTS patches

Re: [PATCH v2 0/4] ARM/arm64: exynos: Fix missing missing reg warning for syscon restart nodes

On Thu, Feb 08, 2018 at 02:46:32PM +0100, Marek Szyprowski wrote: > Hi Krzysztof, > > On 2018-01-30 22:18, Krzysztof Kozlowski wrote: > > Hi, > > > > Changes since v1: > > 1. New patch (1/4) calling devm_of_platform_populate() in PMU driver, > > following Rob's advice. > > 2. The DTS patches

Re: [PATCH] vsprintf: avoid misleading "(null)" for %px

e: > >> > On Sun 2018-02-04 18:45:21, Adam Borowski wrote: > >> >> Like %pK already does, print "" instead. > >> >> > >> >> This confused people -- the convention is that "(null)" means you tried > >> &

Re: [PATCH] vsprintf: avoid misleading "(null)" for %px

On Tue, Feb 06, 2018 at 07:32:32AM +1100, Kees Cook wrote: > On Tue, Feb 6, 2018 at 7:15 AM, Tobin C. Harding wrote: > > On Tue, Feb 06, 2018 at 05:57:17AM +1100, Kees Cook wrote: > >> On Mon, Feb 5, 2018 at 8:44 PM, Petr Mladek wrote: > >> > On Sun 2018-02-04

Re: [PATCH] vsprintf: avoid misleading "(null)" for %px

On Mon, Feb 05, 2018 at 09:03:05PM +1100, Tobin C. Harding wrote: > On Mon, Feb 05, 2018 at 10:44:38AM +0100, Petr Mladek wrote: > > On Sun 2018-02-04 18:45:21, Adam Borowski wrote: > > > Like %pK already does, print "" instead. > > > > &g

Re: [PATCH] vsprintf: avoid misleading "(null)" for %px

On Mon, Feb 05, 2018 at 09:03:05PM +1100, Tobin C. Harding wrote: > On Mon, Feb 05, 2018 at 10:44:38AM +0100, Petr Mladek wrote: > > On Sun 2018-02-04 18:45:21, Adam Borowski wrote: > > > Like %pK already does, print "" instead. > > > > &g

[PATCH] vsprintf: avoid misleading "(null)" for %px

Like %pK already does, print "" instead. This confused people -- the convention is that "(null)" means you tried to dereference a null pointer as opposed to printing the address. Signed-off-by: Adam Borowski <kilob...@angband.pl> --- lib/vsprintf.c | 2 +- 1

[PATCH] vsprintf: avoid misleading "(null)" for %px

Like %pK already does, print "" instead. This confused people -- the convention is that "(null)" means you tried to dereference a null pointer as opposed to printing the address. Signed-off-by: Adam Borowski --- lib/vsprintf.c | 2 +- 1 file changed, 1 insertion(+),

Re: [PATCH v3] drm/nouveau: Move irq setup/teardown to pci ctor/dtor

On Thu, Jan 25, 2018 at 06:29:53PM -0500, Lyude Paul wrote: > This was made apparent by what appeared to be a regression in the > mainline kernel that started introducing suspend/resume issues for > nouveau: > > a0c9259dc4e1 (irq/matrix: Spread interrupts on allocation) I'm just a dumb

Re: [PATCH v3] drm/nouveau: Move irq setup/teardown to pci ctor/dtor

On Thu, Jan 25, 2018 at 06:29:53PM -0500, Lyude Paul wrote: > This was made apparent by what appeared to be a regression in the > mainline kernel that started introducing suspend/resume issues for > nouveau: > > a0c9259dc4e1 (irq/matrix: Spread interrupts on allocation) I'm just a dumb

Re: [RESEND PATCH] blackfin: defconfig: Cleanup from old Kconfig options

On Wed, Dec 27, 2017 at 12:29:33PM +0100, Linus Walleij wrote: > On Tue, Dec 26, 2017 at 2:30 PM, Krzysztof Kozlowski wrote: > > > Remove old, dead Kconfig options (in order appearing in this commit): > > > > Signed-off-by: Krzysztof Kozlowski > > Acked-by:

Re: [RESEND PATCH] blackfin: defconfig: Cleanup from old Kconfig options

On Wed, Dec 27, 2017 at 12:29:33PM +0100, Linus Walleij wrote: > On Tue, Dec 26, 2017 at 2:30 PM, Krzysztof Kozlowski wrote: > > > Remove old, dead Kconfig options (in order appearing in this commit): > > > > Signed-off-by: Krzysztof Kozlowski > > Acked-by: Linus Walleij > > This

[PATCH] MAINTAINERS: mark arch/blackfin/ and its gubbins as orphaned

ries either. Signed-off-by: Adam Borowski <kilob...@angband.pl> --- Obviously, plankton like me with no relation to the architecture in question shouldn't be orphaning it, but consider this mail telling Linus that in the state of Denmark there is an odor of decay. I also did not pester Scot

[PATCH] MAINTAINERS: mark arch/blackfin/ and its gubbins as orphaned

ries either. Signed-off-by: Adam Borowski --- Obviously, plankton like me with no relation to the architecture in question shouldn't be orphaning it, but consider this mail telling Linus that in the state of Denmark there is an odor of decay. I also did not pester Scott Jiang (BLACKFIN MEDIA DRIVER)

Re: [PATCH] drm/nouveau/imem/nv50: fix incorrect use of refcount API

On Fri, Dec 08, 2017 at 06:30:34PM +, Ard Biesheuvel wrote: > Commit be55287aa5b ("drm/nouveau/imem/nv50: embed nvkm_instobj directly > into nv04_instobj") introduced some new calls to the refcount api to > the nv50 mapping code. In one particular instance, it does the > following: > > if

Re: [PATCH] drm/nouveau/imem/nv50: fix incorrect use of refcount API

On Fri, Dec 08, 2017 at 06:30:34PM +, Ard Biesheuvel wrote: > Commit be55287aa5b ("drm/nouveau/imem/nv50: embed nvkm_instobj directly > into nv04_instobj") introduced some new calls to the refcount api to > the nv50 mapping code. In one particular instance, it does the > following: > > if

Re: [PATCH 0/2] Add support for ZSTD-compressed kernel

On Wed, Oct 11, 2017 at 02:01:41AM +, Nick Terrell wrote: > On 10/10/17, 5:08 PM, "Adam Borowski" <kilob...@angband.pl> wrote: > > On Tue, Oct 10, 2017 at 10:40:13PM +, Nick Terrell wrote: > > > On 10/10/17, 2:56 PM, "h...@zytor.com" <h...@zy

Re: [PATCH 0/2] Add support for ZSTD-compressed kernel

On Wed, Oct 11, 2017 at 02:01:41AM +, Nick Terrell wrote: > On 10/10/17, 5:08 PM, "Adam Borowski" wrote: > > On Tue, Oct 10, 2017 at 10:40:13PM +, Nick Terrell wrote: > > > On 10/10/17, 2:56 PM, "h...@zytor.com" wrote: > > > >On Oc

Re: [PATCH 0/2] Add support for ZSTD-compressed kernel

On Tue, Oct 10, 2017 at 10:40:13PM +, Nick Terrell wrote: > On 10/10/17, 2:56 PM, "h...@zytor.com" wrote: > >On October 10, 2017 2:22:42 PM PDT, Nick Terrell wrote: > >>This patch set adds support for a ZSTD-compressed kernel and ramdisk > >>images in the

Re: [PATCH 0/2] Add support for ZSTD-compressed kernel

On Tue, Oct 10, 2017 at 10:40:13PM +, Nick Terrell wrote: > On 10/10/17, 2:56 PM, "h...@zytor.com" wrote: > >On October 10, 2017 2:22:42 PM PDT, Nick Terrell wrote: > >>This patch set adds support for a ZSTD-compressed kernel and ramdisk > >>images in the kernel boot process. It only

Re: Linux 4.14: Reported regressions as of Sunday, 2017-10-08

On Sun, Oct 08, 2017 at 02:37:41PM +0200, Thorsten Leemhuis wrote: > Hi! Find below my second regression report for Linux 4.14. It lists 8 > regressions I'm currently aware of. One regression was fixed since last > weeks report. One was in there that shouldn't have been there. > > == Current

Re: Linux 4.14: Reported regressions as of Sunday, 2017-10-08

On Sun, Oct 08, 2017 at 02:37:41PM +0200, Thorsten Leemhuis wrote: > Hi! Find below my second regression report for Linux 4.14. It lists 8 > regressions I'm currently aware of. One regression was fixed since last > weeks report. One was in there that shouldn't have been there. > > == Current

Re: [PATCH] vfs: hard-ban creating files with control characters in the name

On Tue, Oct 03, 2017 at 12:40:12PM -0400, Theodore Ts'o wrote: > On Tue, Oct 03, 2017 at 03:07:24AM +0100, Al Viro wrote: > > That essay is full of shit, and you've even mentioned parts of that just > > above... > > NAK; you'd _still_ need proper quoting (or a shell with something > > resembling

Re: [PATCH] vfs: hard-ban creating files with control characters in the name

On Tue, Oct 03, 2017 at 12:40:12PM -0400, Theodore Ts'o wrote: > On Tue, Oct 03, 2017 at 03:07:24AM +0100, Al Viro wrote: > > That essay is full of shit, and you've even mentioned parts of that just > > above... > > NAK; you'd _still_ need proper quoting (or a shell with something > > resembling

Re: [PATCH] vfs: hard-ban creating files with control characters in the name

On Tue, Oct 03, 2017 at 03:07:24AM +0100, Al Viro wrote: > On Tue, Oct 03, 2017 at 02:50:42AM +0200, Adam Borowski wrote: > > Anything with bytes 1-31,127 will get -EACCES. > > > > Especially \n is bad: instead of natural file-per-line, you need an > > user-unfriend

Re: [PATCH] vfs: hard-ban creating files with control characters in the name

On Tue, Oct 03, 2017 at 03:07:24AM +0100, Al Viro wrote: > On Tue, Oct 03, 2017 at 02:50:42AM +0200, Adam Borowski wrote: > > Anything with bytes 1-31,127 will get -EACCES. > > > > Especially \n is bad: instead of natural file-per-line, you need an > > user-unfriend

[PATCH] vfs: hard-ban creating files with control characters in the name

st write * many filesystems already disallow certain characters (like invalid Unicode), thus returning an error is consistent An example of a write-up of this issue can be found at: https://www.dwheeler.com/essays/fixing-unix-linux-filenames.html Signed-off-by: Adam Borowski <kilob...@angband.pl&

[PATCH] vfs: hard-ban creating files with control characters in the name

st write * many filesystems already disallow certain characters (like invalid Unicode), thus returning an error is consistent An example of a write-up of this issue can be found at: https://www.dwheeler.com/essays/fixing-unix-linux-filenames.html Signed-off-by: Adam Borowski --- I really care

Re: random insta-reboots on AMD Phenom II

On Sat, Sep 30, 2017 at 01:53:02PM +0200, Borislav Petkov wrote: > On Sat, Sep 30, 2017 at 01:29:03PM +0200, Adam Borowski wrote: > > On Sat, Sep 30, 2017 at 01:11:37PM +0200, Borislav Petkov wrote: > > > On Sat, Sep 30, 2017 at 04:05:16AM +0200, Adam Borowski wrote: > B

Re: random insta-reboots on AMD Phenom II

On Sat, Sep 30, 2017 at 01:53:02PM +0200, Borislav Petkov wrote: > On Sat, Sep 30, 2017 at 01:29:03PM +0200, Adam Borowski wrote: > > On Sat, Sep 30, 2017 at 01:11:37PM +0200, Borislav Petkov wrote: > > > On Sat, Sep 30, 2017 at 04:05:16AM +0200, Adam Borowski wrote: > B

Re: random insta-reboots on AMD Phenom II

On Sat, Sep 30, 2017 at 01:11:37PM +0200, Borislav Petkov wrote: > On Sat, Sep 30, 2017 at 04:05:16AM +0200, Adam Borowski wrote: > > Any hints how to debug this? > > Do > rdmsr -a 0xc0010015 > as root and paste it here. 110 110 110 110 110 110 on

Re: random insta-reboots on AMD Phenom II

On Sat, Sep 30, 2017 at 01:11:37PM +0200, Borislav Petkov wrote: > On Sat, Sep 30, 2017 at 04:05:16AM +0200, Adam Borowski wrote: > > Any hints how to debug this? > > Do > rdmsr -a 0xc0010015 > as root and paste it here. 110 110 110 110 110 110 on

random insta-reboots on AMD Phenom II

Hi! I'm afraid I see random instant reboots on current -rc, approximately once per day, only under CPU load. There's nothing on serial/etc -- just an immediate reboot. 4.13 works perfectly; last kernel I've tried is v4.14-rc2-165-g770b782f555d. gcc 7.2.0-7 (Debian). CPU is AMD Phenom II X6

random insta-reboots on AMD Phenom II

Hi! I'm afraid I see random instant reboots on current -rc, approximately once per day, only under CPU load. There's nothing on serial/etc -- just an immediate reboot. 4.13 works perfectly; last kernel I've tried is v4.14-rc2-165-g770b782f555d. gcc 7.2.0-7 (Debian). CPU is AMD Phenom II X6

Re: [PATCH 2/2] zram: remove zlib from the list of recommended algorithms

On Wed, Sep 13, 2017 at 04:12:46PM +0900, Minchan Kim wrote: > On Tue, Sep 12, 2017 at 02:00:05PM +0900, Sergey Senozhatsky wrote: > > ZSTD tends to outperform deflate/inflate, thus we remove > > zlib from the list of recommended algorithms and recommend > > zstd instead. > > I did test with my

Re: [PATCH 2/2] zram: remove zlib from the list of recommended algorithms

On Wed, Sep 13, 2017 at 04:12:46PM +0900, Minchan Kim wrote: > On Tue, Sep 12, 2017 at 02:00:05PM +0900, Sergey Senozhatsky wrote: > > ZSTD tends to outperform deflate/inflate, thus we remove > > zlib from the list of recommended algorithms and recommend > > zstd instead. > > I did test with my

Re: [PATCH 00/13] mmu_notifier kill invalidate_page callback

On Tue, Aug 29, 2017 at 08:56:15PM -0400, Jerome Glisse wrote: > I will wait for people to test and for result of my own test before > reposting if need be, otherwise i will post as separate patch. > > > But from a _very_ quick read-through this looks fine. But it obviously > > needs testing. > >

Re: [PATCH 00/13] mmu_notifier kill invalidate_page callback

On Tue, Aug 29, 2017 at 08:56:15PM -0400, Jerome Glisse wrote: > I will wait for people to test and for result of my own test before > reposting if need be, otherwise i will post as separate patch. > > > But from a _very_ quick read-through this looks fine. But it obviously > > needs testing. > >

Re: kvm splat in mmu_spte_clear_track_bits

On Tue, Aug 29, 2017 at 02:45:41PM +0200, Takashi Iwai wrote: > [Put more people to Cc, sorry for growing too much...] We're all interested in 4.13.0 not crashing on us, so that's ok. > On Tue, 29 Aug 2017 11:19:13 +0200, > Bernhard Held wrote: > > > > On 08/28/2017 at 06:56 PM, Nadav Amit

Re: kvm splat in mmu_spte_clear_track_bits

On Tue, Aug 29, 2017 at 02:45:41PM +0200, Takashi Iwai wrote: > [Put more people to Cc, sorry for growing too much...] We're all interested in 4.13.0 not crashing on us, so that's ok. > On Tue, 29 Aug 2017 11:19:13 +0200, > Bernhard Held wrote: > > > > On 08/28/2017 at 06:56 PM, Nadav Amit

Re: 4.13-rc7: WARNING at arch/x86/kvm/mmu.c:717 (and a crash thereafter)

On Mon, Aug 28, 2017 at 02:26:06PM +0200, Takashi Iwai wrote: > I seem to get a kernel warning when running KVM on Dell desktop with > IvyBridge like below. As you can see, a bad page BUG is triggered > after that, too. The problem is not triggered always, but it happens > occasionally. See the

Re: 4.13-rc7: WARNING at arch/x86/kvm/mmu.c:717 (and a crash thereafter)

On Mon, Aug 28, 2017 at 02:26:06PM +0200, Takashi Iwai wrote: > I seem to get a kernel warning when running KVM on Dell desktop with > IvyBridge like below. As you can see, a bad page BUG is triggered > after that, too. The problem is not triggered always, but it happens > occasionally. See the

Re: kvm splat in mmu_spte_clear_track_bits

On Fri, Aug 25, 2017 at 03:40:50PM +0200, Paolo Bonzini wrote: > On 25/08/2017 15:14, Adam Borowski wrote: > >>> I would also try commit 1372324b328cd5dabaef5e345e37ad48c63df2a9 to > >>> identify whether it was caused by a KVM change in 4.13 or something > >>&

Re: kvm splat in mmu_spte_clear_track_bits

On Fri, Aug 25, 2017 at 03:40:50PM +0200, Paolo Bonzini wrote: > On 25/08/2017 15:14, Adam Borowski wrote: > >>> I would also try commit 1372324b328cd5dabaef5e345e37ad48c63df2a9 to > >>> identify whether it was caused by a KVM change in 4.13 or something > >>&

Re: kvm splat in mmu_spte_clear_track_bits

On Thu, Aug 24, 2017 at 03:43:55PM +0800, Wanpeng Li wrote: > 2017-08-23 20:22 GMT+08:00 Paolo Bonzini <pbonz...@redhat.com>: > > On 22/08/2017 00:32, Adam Borowski wrote: > >> On Mon, Aug 21, 2017 at 09:58:34PM +0200, Radim Krčmář wrote: > >>> 2017-08-21 21

Re: kvm splat in mmu_spte_clear_track_bits

On Thu, Aug 24, 2017 at 03:43:55PM +0800, Wanpeng Li wrote: > 2017-08-23 20:22 GMT+08:00 Paolo Bonzini : > > On 22/08/2017 00:32, Adam Borowski wrote: > >> On Mon, Aug 21, 2017 at 09:58:34PM +0200, Radim Krčmář wrote: > >>> 2017-08-21 21:12+0200, Adam Borowski: >

Re: [PATCH] zram: add zstd to the supported algorithms list

On Fri, Aug 25, 2017 at 04:45:33PM +0900, Sergey Senozhatsky wrote: > that may lead to a bigger/more general question: > > - if zstd is so much better, then do we need deflate/inflate at all in > the kernel? may be zstd can replace it? zram and vmlinuz/modules are about the only cases that can

Re: [PATCH] zram: add zstd to the supported algorithms list

On Fri, Aug 25, 2017 at 04:45:33PM +0900, Sergey Senozhatsky wrote: > that may lead to a bigger/more general question: > > - if zstd is so much better, then do we need deflate/inflate at all in > the kernel? may be zstd can replace it? zram and vmlinuz/modules are about the only cases that can

Re: kvm splat in mmu_spte_clear_track_bits

On Mon, Aug 21, 2017 at 09:58:34PM +0200, Radim Krčmář wrote: > 2017-08-21 21:12+0200, Adam Borowski: > > On Mon, Aug 21, 2017 at 09:26:57AM +0800, Wanpeng Li wrote: > > > 2017-08-21 7:13 GMT+08:00 Adam Borowski <kilob...@angband.pl>: > > > > I'm afraid I keep

Re: kvm splat in mmu_spte_clear_track_bits

On Mon, Aug 21, 2017 at 09:58:34PM +0200, Radim Krčmář wrote: > 2017-08-21 21:12+0200, Adam Borowski: > > On Mon, Aug 21, 2017 at 09:26:57AM +0800, Wanpeng Li wrote: > > > 2017-08-21 7:13 GMT+08:00 Adam Borowski : > > > > I'm afraid I keep getting a quite re

Re: kvm splat in mmu_spte_clear_track_bits

On Mon, Aug 21, 2017 at 09:26:57AM +0800, Wanpeng Li wrote: > 2017-08-21 7:13 GMT+08:00 Adam Borowski <kilob...@angband.pl>: > > Hi! > > I'm afraid I keep getting a quite reliable, but random, splat when running > > KVM: > > I reported something similar before. h

Re: kvm splat in mmu_spte_clear_track_bits

On Mon, Aug 21, 2017 at 09:26:57AM +0800, Wanpeng Li wrote: > 2017-08-21 7:13 GMT+08:00 Adam Borowski : > > Hi! > > I'm afraid I keep getting a quite reliable, but random, splat when running > > KVM: > > I reported something similar before. https://lkml.org/lkml/2017/

kvm splat in mmu_spte_clear_track_bits

Hi! I'm afraid I keep getting a quite reliable, but random, splat when running KVM: [ cut here ] WARNING: CPU: 5 PID: 5826 at arch/x86/kvm/mmu.c:717 mmu_spte_clear_track_bits+0x123/0x170 Modules linked in: tun nbd arc4 rtl8xxxu mac80211 cfg80211 rfkill nouveau video ttm

kvm splat in mmu_spte_clear_track_bits

Hi! I'm afraid I keep getting a quite reliable, but random, splat when running KVM: [ cut here ] WARNING: CPU: 5 PID: 5826 at arch/x86/kvm/mmu.c:717 mmu_spte_clear_track_bits+0x123/0x170 Modules linked in: tun nbd arc4 rtl8xxxu mac80211 cfg80211 rfkill nouveau video ttm

Re: [PATCH v5 3/5] btrfs: Add zstd support

On Wed, Aug 09, 2017 at 07:39:02PM -0700, Nick Terrell wrote: > Add zstd compression and decompression support to BtrFS. Re-tested on arm64, amd64 and i386, this time everything seems fine so far. As I'm too lazy to have a separate test setup for the zlib level patch, I'm using a dummy

Re: [PATCH v5 3/5] btrfs: Add zstd support

On Wed, Aug 09, 2017 at 07:39:02PM -0700, Nick Terrell wrote: > Add zstd compression and decompression support to BtrFS. Re-tested on arm64, amd64 and i386, this time everything seems fine so far. As I'm too lazy to have a separate test setup for the zlib level patch, I'm using a dummy

Re: [PATCH] fbcon: Use background color for margins

On Mon, Jul 31, 2017 at 12:25:28PM -0500, David Lechner wrote: > On 07/30/2017 04:51 PM, Pavel Machek wrote: > > > > > Screens that don't have a black border around the active area will > > > > > have > > > > > ugly black bars for the margin when the text background color is not > > > > > black.

Re: [PATCH] fbcon: Use background color for margins

On Mon, Jul 31, 2017 at 12:25:28PM -0500, David Lechner wrote: > On 07/30/2017 04:51 PM, Pavel Machek wrote: > > > > > Screens that don't have a black border around the active area will > > > > > have > > > > > ugly black bars for the margin when the text background color is not > > > > > black.

Re: Problematic culture around Signed-off-by

On Sun, Jul 30, 2017 at 08:52:36PM +0200, Pavel Machek wrote: > > I've been away from kernel development for a bit, but I've returned and > > I'm troubled by what seems to be an entrenched and widespread (IMO) > > misuse of the "Signed-off-by:" in commits. > > > > I've now either been asked to

<    1   2   3   4   5   >