[PATCH] vt: fix \e[2m using the wrong placeholder color on graphical consoles

Only vgacon and sisusbcon did it right, the rest (via generic code) tried underline (usually cyan). Signed-off-by: Adam Borowski <kilob...@angband.pl> --- Compare this if clause with the two above it. Nice copypaste. :) drivers/tty/vt/vt.c | 2 +- 1 file changed, 1 insertion(+), 1 de

[PATCH 5/5] vt: drop access_ok() calls in unimap ioctls

Done by copy_{from,to}_user(). Signed-off-by: Adam Borowski <kilob...@angband.pl> --- drivers/tty/vt/vt_ioctl.c | 8 1 file changed, 8 deletions(-) diff --git a/drivers/tty/vt/vt_ioctl.c b/drivers/tty/vt/vt_ioctl.c index 0cbfe1ff6f6c..96d389cb506c 100644 --- a/drivers/tty/vt/vt_i

[PATCH 2/5] vt: fix unchecked __put_user() in tioclinux ioctls

in the future. If anyone cares about 3.7 and earlier, this is a security hole (untested) on real 80386 CPUs. Signed-off-by: Adam Borowski <kilob...@angband.pl> CC: sta...@vger.kernel.org # v3.7- --- drivers/tty/vt/vt.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drive

[PATCH 3/5] vt: use copy_to_user instead of __put_user in GIO_UNIMAP ioctl

A nice big linear transfer, no need to flip stac/PAN/etc every half-entry. Also, yay __put_user() after checking only read. Signed-off-by: Adam Borowski <kilob...@angband.pl> --- drivers/tty/vt/consolemap.c | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff

[PATCH 1/5] vt: use copy_from/to_user instead of __get/put_user for scrnmap ioctls

Linus wants to get rid of these functions, and these uses are especially egregious: they copy a big linear array element by element. Signed-off-by: Adam Borowski <kilob...@angband.pl> --- drivers/tty/vt/consolemap.c | 31 +++ 1 file changed, 7 insertions(

[PATCH 4/5] vt: use memdup_user in PIO_UNIMAP ioctl

Again, a nice linear transfer that simplifies the code. Signed-off-by: Adam Borowski <kilob...@angband.pl> --- drivers/tty/vt/consolemap.c | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/drivers/tty/vt/consolemap.c b/drivers/tty/vt/consolemap.c index c6a692

Re: [PATCH] checkpatch: Change format of --color argument to --color[=WHEN]

On Mon, Jun 05, 2017 at 04:10:30PM -0700, Joe Perches wrote: > On Mon, 2017-06-05 at 18:27 -0400, John Brooks wrote: > > The boolean --color argument did not offer the ability to force colourized > > output even if stdout is not a terminal. > > OK, but why is colorizing output not to terminals

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

[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&

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 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: 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

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: [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: 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: [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 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: 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 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 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 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: [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 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 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] 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 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 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 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 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

[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

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

[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

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 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 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 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] 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: 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: [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: [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: get_maintainer.pl and change of email

On Wed, Aug 01, 2018 at 11:36:23AM -0700, Nick Desaulniers wrote: > It seems that get_maintainer.pl will make recommendations based on > commit history to a file, but over time, people change emails that > they commit from, then get_maintainer.pl recommends the possibly now > invalid email

Re: Linux 4.18.1

Hi! On Thu, Aug 16, 2018 at 12:14:29PM +0200, Greg KH wrote: > I'm announcing the release of the 4.18.1 kernel. I'm afraid that I get a build failure; v4.18 is ok, v4.18.1 fails with: ld: arch/x86/kvm/x86.o: in function `kvm_get_arch_capabilities': (.text+0x43b2): undefined reference to

Re: Linux 4.18.1

On Thu, Aug 16, 2018 at 05:11:21PM +0200, Greg KH wrote: > On Thu, Aug 16, 2018 at 03:59:58PM +0200, Sven Joachim wrote: > > On 2018-08-16 15:05 +0200, Adam Borowski wrote: > > > I'm afraid that I get a build failure; v4.18 is ok, v4.18.1 fails with: > > > > > >

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

On Fri, Aug 17, 2018 at 09:54:03AM -0700, Andi Kleen wrote: > On Fri, Aug 17, 2018 at 06:15:45PM +0200, René Rebe wrote: > > Hey, > > > > is there any mainline future for this zstd support? > > Currently my most favourite compressor for this, and for what it’s worth > > zstd/initrd now even

Re: Kernel-only deployments?

On Thu, Aug 23, 2018 at 10:43:59AM -0700, Paul E. McKenney wrote: > The mkinitramfs approach results in about 40MB of initrd, and dracut > about 10MB. Most of this is completely useless for rcutorture, which > isn't interested in mounting filesystems, opening devices, and almost > all of the

Re: linux-next: build warnings from Linus' tree

On Sun, Aug 19, 2018 at 04:21:57PM -0700, Linus Torvalds wrote: > On Sun, Aug 19, 2018 at 3:13 PM Stephen Rothwell > wrote: > > > > Today's linux-next build (powerpc ppc64_defconfig) produced these > > warnings: > > > > fs/cifs/cifssmb.c:605:3: warning: 'strncpy' writing 16 bytes into a region

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

On Fri, Aug 17, 2018 at 12:22:44PM -0700, Andi Kleen wrote: > On Fri, Aug 17, 2018 at 07:57:46PM +0200, Adam Borowski wrote: > > > The "favourite compressor" seems to roughly change every year, so if > > > we keep adding new ones things will get more and more

[PATCH 2/3] vt: selection: handle storing of characters above U+FFFF

Those above U+10 get replaced with U+FFFD. Signed-off-by: Adam Borowski --- drivers/tty/vt/selection.c | 23 ++- 1 file changed, 18 insertions(+), 5 deletions(-) diff --git a/drivers/tty/vt/selection.c b/drivers/tty/vt/selection.c index 34e7110f310d..69ca337d3220 100644

[PATCH 3/3] vt: selection: take screen contents from uniscr if available

. Signed-off-by: Adam Borowski --- drivers/tty/vt/selection.c | 11 +++ drivers/tty/vt/vt.c| 10 ++ include/linux/selection.h | 1 + 3 files changed, 18 insertions(+), 4 deletions(-) diff --git a/drivers/tty/vt/selection.c b/drivers/tty/vt/selection.c index 69ca337d3220

[PATCH 1/3] vt: don't reinvent min()

All the helper function saved us was a cast. Signed-off-by: Adam Borowski --- drivers/tty/vt/selection.c | 14 -- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/drivers/tty/vt/selection.c b/drivers/tty/vt/selection.c index 90ea1cc52b7a..34e7110f310d 100644

[PATCH 0/3] use unicode for vt mouse paste

Hi! Based on Nicolas' nice work (in tty-next), let's avoid corrupting characters that have been copy+pasted via mouse selection. The uniscr array holds their original identity even if they got mangled by glyph conversion. The glyph conversion lossily turns similar-looking characters into a

Re: [PATCH 1/3] vt: avoid a VLA in the unicode screen scroll function

On Tue, Jul 17, 2018 at 09:02:40PM -0400, Nicolas Pitre wrote: > The nr argument is typically small: most often nr == 1. However this > could be abused with a very large explicit scroll in a resized screen. > Make the code scroll lines one at a time in all cases to avoid the VLA. > Anything

[PATCH 0/6] vt: no blinking on console, 256/24-bit color improvements

Hi! Here's a patchset with two entangled improvements: * it'd be good to get rid of blinking where possible. Even CGA (thus VGA) allows disabling it, rendering such characters with a bright background instead. * due to my error, 256-color mode uses a much darker palette for conversion,

[PATCH 1/6] vt: drop unused struct vt_struct

Hasn't been ever used within historic (ie, git) times. Signed-off-by: Adam Borowski --- include/linux/console_struct.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/include/linux/console_struct.h b/include/linux/console_struct.h index 2c8d3239899b..fea64f2692a0 100644

[PATCH 2/6] vt: add console flag "unblinking"

: newport looks like it shows bright bg, sti can't do either, mda appears to blink, etc -- but confirmation would be needed. Signed-off-by: Adam Borowski --- drivers/tty/vt/vt.c | 1 + drivers/video/fbdev/core/fbcon.c | 1 + include/linux/console_struct.h | 1 + 3 files changed, 3

[PATCH 5/6] vt: compensate for brightening the 256-color palette

, thus there are some differences, among others: * values very close to black go to 0 (black) rather than 8 (dark grey) * grayscale ramp is more even A comparison of the old vs new vs FreeBSD's teken is at: https://github.com/kilobyte/colorkernel Signed-off-by: Adam Borowski --- drivers/tty/vt/vt.c

[PATCH 4/6] vt: change 256-color palette to match all(?) modern terminals

into only 16 values, but recently 24-bit codes turned from an oddity to something widespread, thus it's better to handle 256 vs 24-bit consistently. Signed-off-by: Adam Borowski --- drivers/tty/vt/vt.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/tty/vt/vt.c

[PATCH 6/6] vt: support bright backgrounds for \e[48m if unblinking

for dark and better for bright inputs. Signed-off-by: Adam Borowski --- drivers/tty/vt/vt.c | 38 +- 1 file changed, 17 insertions(+), 21 deletions(-) diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c index c777f4c91df0..7fcb0ff2dccf 100644 --- a/drivers/tty

[PATCH 3/6] vt: let \e[100m use bright background if unblinking

Let's keep \e[5m setting this bit, it's a nice way to convey the information, and it preserves old behaviour. Some other terminals that can't or don't want to blink do so as well. Signed-off-by: Adam Borowski --- drivers/tty/vt/vt.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers

Re: [PATCH 0/6] vt: no blinking on console, 256/24-bit color improvements

On Sat, Jul 21, 2018 at 09:43:19AM +0200, Greg Kroah-Hartman wrote: > On Wed, Jul 18, 2018 at 05:01:52AM +0200, Adam Borowski wrote: > > Here's a patchset with two entangled improvements: > > > > * it'd be good to get rid of blinking where possible. Even CGA (thus VGA) &

Re: [PATCH 0/6] vt: no blinking on console, 256/24-bit color improvements

On Mon, Jul 23, 2018 at 10:53:29AM +0200, Geert Uytterhoeven wrote: > On Sat, Jul 21, 2018 at 11:39 PM Adam Borowski wrote: > > Technically, every console can be made to blink by drawing/clearing affected > > characters a few times per second, but that'd be quite a waste of

Re: [PATCH 0/6] vt: no blinking on console, 256/24-bit color improvements

On Thu, Jul 19, 2018 at 11:47:49AM +0100, Alan Cox wrote: > On Wed, 18 Jul 2018 05:01:52 +0200 > Adam Borowski wrote: > > > Hi! > > Here's a patchset with two entangled improvements: > > > > * it'd be good to get rid of blinking where possible. Even CGA

[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 v3 1/3] vt: preserve unicode values corresponding to screen characters

On Wed, Jul 11, 2018 at 01:39:56PM -0700, Kees Cook wrote: > On Wed, Jul 11, 2018 at 2:18 AM, Greg Kroah-Hartman > wrote: > > On Tue, Jul 10, 2018 at 05:52:01PM -0700, Kees Cook wrote: > >> On Tue, Jun 26, 2018 at 8:56 PM, Nicolas Pitre > >> wrote: > >> > +++ b/drivers/tty/vt/vt.c > >> > [...]

[PATCH] .gitignore: add ZSTD-compressed files

For now, that's arch/x86/boot/compressed/vmlinux.bin.zst but probably more will come, thus let's be consistent with all other compressors. Signed-off-by: Adam Borowski --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 97ba6b79834c..0d09cf1c053c

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 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

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

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

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: [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: [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: [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

[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

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

drivers by default (was Re: Another HID problem this merge window..)

On Sat, Oct 27, 2018 at 11:13:17AM -0700, Linus Torvalds wrote: > Ok, so this is a much smaller issue than the i2c one that cause boot > problems, but it's annoying. > > We do *not* enable new random drivers by default. And we most > *definitely* don't do it when they are odd-ball ones that most

Re: Official Linux system wrapper library?

On Sun, Nov 11, 2018 at 12:46:35PM +0100, Florian Weimer wrote: > A lot of multi-threaded applications assume that most high-level > functionality remains usable even after fork in a multi-threaded > process. How would this be even possible? Currently fork kills all threads (save for the

[PATCH 01/17] lib: Add support for ZSTD-compressed kernel

From: Nick Terrell Add support for extracting ZSTD-compressed kernel images, as well as ZSTD-compressed ramdisk images in the kernel boot process. When neither `fill' nor `flush' are used, the decompression function requires a constant amount of memory (192 KB is sufficient). When either is

[PATCH 16/17] Kconfig: Update the prose for selection of compression algorithm

It was really obsolete, and some entries contradicted each other. Let's not recommend ZSTD for kernel compression yet as it's available only on x86, and some distros might not have the tool installed. Proposing ZSTD for initrd is safer but let's test it first. Signed-off-by: Adam Borowski

Re: POSIX violation by writeback error

On Tue, Sep 25, 2018 at 11:46:27AM -0400, Theodore Y. Ts'o wrote: > P.S. One thought: it might be cool if there was some way for > userspace applications to mark files with "nuke if not closed" flag, > such that if the system crashes, the file systems would automatically > unlink the file after a

Re: Contributors can not just rescind the license (Legal Opinion)

On Fri, Sep 28, 2018 at 11:31:32AM +0200, www.Advocati.org wrote: > CONTRIBUTORS CAN NOT JUST RESCIND THE LICENSE > THEY GRANTED UNDER GPLv2. IT IS *COPYLEFTED* > A letter from 17.09.2018 by @observerofaffairs > titled 'GPL version 2 is a bare license. Recind. (Regarding (future) > Code of

Re: [...] an apology, and a maintainership note

On Sun, Sep 16, 2018 at 12:22:43PM -0700, Linus Torvalds wrote: > This is my reality. I am not an emotionally empathetic kind of person > and that probably doesn't come as a big surprise to anybody. Least of > all me. The fact that I then misread people and don't realize (for > years) how badly

Re: [PATCH] vt: detect and ignore OSC codes.

On Thu, Feb 13, 2014 at 10:39:12AM -0800, Greg Kroah-Hartman wrote: > On Wed, Jan 15, 2014 at 07:21:04AM +0100, Adam Borowski wrote: > > These can be used to send commands consisting of an arbitrary string to the > > terminal, most often used to set a terminal's window title

[PATCH] perf: tools: fix missing casts for printf arguments.

Because of -Werror, they caused build failure at least on x32, as time_t is of different size than "unsigned long". In another place, __suseconds_t is not compatible with "long int". Signed-off-by: Adam Borowski --- tools/perf/bench/sched-messaging.c | 4 ++-- tools/per

[PATCH] vt: detect and ignore OSC codes.

-by: Adam Borowski --- drivers/tty/vt/vt.c | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c index b7bde54..3ad0b61 100644 --- a/drivers/tty/vt/vt.c +++ b/drivers/tty/vt/vt.c @@ -1592,7 +1592,7 @@ static void restore_cur

Re: [PATCH 09/17] Move unicode to ASCII conversion to shared function.

On Mon, Sep 16, 2013 at 09:11:25PM -0700, Roy Franz wrote: > +/* Convert the unicode UEFI command line to ASCII to pass to kernel. > + * Size of memory allocated return in *cmd_line_len. > + * Returns NULL on error. > + */ > +static char *efi_convert_cmdline_to_ascii(efi_system_table_t

Re: [PATCH 09/17] Move unicode to ASCII conversion to shared function.

On Wed, Sep 18, 2013 at 09:48:44PM -0700, Roy Franz wrote: > On Wed, Sep 18, 2013 at 8:44 PM, Adam Borowski wrote: > > [UCS2 truncation] > > I stuck to re-arranging the code that was there, as I don't know enough > about character encodings to propose changes. I on the oth

Re: Copy on write hard links?

On Tue, Sep 24, 2013 at 08:36:56PM +0200, Thomas Meyer wrote: > Is there such a thing? In mainline, AFAIK no. The vserver patchset, on the other hand, adds a new xattr, iunlink, that copies the whole file when needed. That works on most filesystems. That's quite a hack, though, and I think

[PATCH] vt: properly ignore xterm-256 colour codes

colour ones tend to turn blinking on before invoking an arbitrary unrelated command. This commit doesn't add such support, merely skips such codes without ill effects. Signed-off-by: Adam Borowski --- drivers/tty/vt/vt.c | 26 -- 1 file changed, 20 insertions(+), 6 deletions

Re: [PATCH] vt: properly ignore xterm-256 colour codes

On Mon, Sep 09, 2013 at 05:53:19PM +0200, David Herrmann wrote: > On Fri, Jul 12, 2013 at 10:23 PM, Adam Borowski wrote: > > drivers/tty/vt/vt.c | 26 -- > > 1 file changed, 20 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/tty/vt

[PATCH 1/2] vt: break a couple of obsolete SCOish codes.

No modern terminal supports them, and SGR 38 conflicts with detecting xterm-256 colours. This also makes SGR 39 consistent with other popular terminals. Neither are used by ncurses' terminfo. Signed-off-by: Adam Borowski --- drivers/tty/vt/vt.c | 15 +-- 1 file changed, 1

[PATCH 2/2] vt: properly ignore xterm-256 colour codes

colour ones tend to turn blinking on before invoking an arbitrary unrelated command. This commit doesn't add such support, merely skips such codes without ill effects. Signed-off-by: Adam Borowski --- drivers/tty/vt/vt.c | 22 ++ 1 file changed, 22 insertions(+) diff --git

Re: [PATCH] vt: properly ignore xterm-256 colour codes

On Thu, Sep 12, 2013 at 02:37:26PM +0200, David Herrmann wrote: > On Mon, Sep 9, 2013 at 6:46 PM, Adam Borowski wrote: > > On Mon, Sep 09, 2013 at 05:53:19PM +0200, David Herrmann wrote: > > [...] > >> Btw., you should put Greg Kroah-Hartman and Andrew Morton on CC. Both

[PATCH] vt: detect and ignore OSC codes.

unconditionally. Not following Ecma-48, this commit recognizes 7-bit forms (ESC ] ... 0x07, ESC ] .. ESC \) but not 8-bit (0x9D ... 0x9C). Signed-off-by: Adam Borowski --- drivers/tty/vt/vt.c | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/tty/vt/vt.c b

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 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

[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

<    1   2   3   4   5   >