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

MikeeUSA warning (Re: Yes you have standing to sue GRSecurity.)

Note that this is quite clearly yet another of MikeeUSA's sockpuppets. And you guys really don't want to be caught in another of his troll threads. Yeah, GRsecurity is a problem, but don't let our dear Mikee milk it. -- ⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition: ⣾⠁⢰⠒⠀⣿⡁ • multiplay with

MikeeUSA warning (Re: Yes you have standing to sue GRSecurity.)

Note that this is quite clearly yet another of MikeeUSA's sockpuppets. And you guys really don't want to be caught in another of his troll threads. Yeah, GRsecurity is a problem, but don't let our dear Mikee milk it. -- ⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition: ⣾⠁⢰⠒⠀⣿⡁ • multiplay with

Re: [PATCH 0/3] Add ethernet0 alias for several A64 boards

On Tue, Jul 25, 2017 at 11:04:24AM +0800, icen...@aosc.io wrote: > 在 2017-07-24 15:58，Maxime Ripard 写道： > > On Sat, Jul 22, 2017 at 10:28:49AM +0800, Icenowy Zheng wrote: > > > Allwinner A64 SoC has an EMAC which is used to provide Ethernet > > > function on several boards. > > > > > > The EMAC

Re: [PATCH 0/3] Add ethernet0 alias for several A64 boards

On Tue, Jul 25, 2017 at 11:04:24AM +0800, icen...@aosc.io wrote: > 在 2017-07-24 15:58，Maxime Ripard 写道： > > On Sat, Jul 22, 2017 at 10:28:49AM +0800, Icenowy Zheng wrote: > > > Allwinner A64 SoC has an EMAC which is used to provide Ethernet > > > function on several boards. > > > > > > The EMAC

Re: [PATCH v3 0/4] Add xxhash and zstd modules

On Fri, Jul 21, 2017 at 11:56:21AM -0400, Austin S. Hemmelgarn wrote: > On 2017-07-20 17:27, Nick Terrell wrote: > > This patch set adds xxhash, zstd compression, and zstd decompression > > modules. It also adds zstd support to BtrFS and SquashFS. > > > > Each patch has relevant summaries,

Re: [PATCH v3 0/4] Add xxhash and zstd modules

On Fri, Jul 21, 2017 at 11:56:21AM -0400, Austin S. Hemmelgarn wrote: > On 2017-07-20 17:27, Nick Terrell wrote: > > This patch set adds xxhash, zstd compression, and zstd decompression > > modules. It also adds zstd support to BtrFS and SquashFS. > > > > Each patch has relevant summaries,

Re: nbd drops connection on most writes

On Fri, Jul 21, 2017 at 12:22:51PM +, Josef Bacik wrote: > Oh shit the default timeout is 0 if you don't set it in the client. Use > the timeout option with nbd client and it should fix it for you. I'll > send something up to make this a sane default. Confirmed, adding a timeout=XXX

Re: nbd drops connection on most writes

On Fri, Jul 21, 2017 at 12:22:51PM +, Josef Bacik wrote: > Oh shit the default timeout is 0 if you don't set it in the client. Use > the timeout option with nbd client and it should fix it for you. I'll > send something up to make this a sane default. Confirmed, adding a timeout=XXX

nbd drops connection on most writes

Hi! I'm afraid that 4.13-rc1 nbd aborts connection on writes for me: [ 251.938384] block nbd0: Send data failed (result -11) [ 251.943484] block nbd0: Request send failed trying another connection [ 251.950034] block nbd0: Receive control failed (result -32) [ 251.955676] block nbd0:

nbd drops connection on most writes

Hi! I'm afraid that 4.13-rc1 nbd aborts connection on writes for me: [ 251.938384] block nbd0: Send data failed (result -11) [ 251.943484] block nbd0: Request send failed trying another connection [ 251.950034] block nbd0: Receive control failed (result -32) [ 251.955676] block nbd0:

Re: [PATCH v2 3/4] btrfs: Add zstd support

On Tue, Jul 11, 2017 at 06:01:38AM +, Nick Terrell wrote: > On 7/10/17, 9:57 PM, "Nick Terrell" wrote: > > The problem is caused by a gcc-7 bug [1]. It miscompiles > > ZSTD_wildcopy(void *dst, void const *src, ptrdiff_t len) when len is 0. > > Sorry, my patch still triggered

Re: [PATCH v2 3/4] btrfs: Add zstd support

On Tue, Jul 11, 2017 at 06:01:38AM +, Nick Terrell wrote: > On 7/10/17, 9:57 PM, "Nick Terrell" wrote: > > The problem is caused by a gcc-7 bug [1]. It miscompiles > > ZSTD_wildcopy(void *dst, void const *src, ptrdiff_t len) when len is 0. > > Sorry, my patch still triggered the gcc bug, I

Re: [PATCH v2 3/4] btrfs: Add zstd support

On Sat, Jul 08, 2017 at 01:40:18AM +0200, Adam Borowski wrote: > On Fri, Jul 07, 2017 at 11:17:49PM +, Nick Terrell wrote: > > On 7/6/17, 9:32 AM, "Adam Borowski" <kilob...@angband.pl> wrote: > > > Got a reproducible crash on amd64: > > >

Re: [PATCH v2 3/4] btrfs: Add zstd support

On Sat, Jul 08, 2017 at 01:40:18AM +0200, Adam Borowski wrote: > On Fri, Jul 07, 2017 at 11:17:49PM +, Nick Terrell wrote: > > On 7/6/17, 9:32 AM, "Adam Borowski" wrote: > > > Got a reproducible crash on amd64: > > > Thanks for the bug report Adam! I'm

Re: [PATCH v2 3/4] btrfs: Add zstd support

On Fri, Jul 07, 2017 at 11:17:49PM +, Nick Terrell wrote: > On 7/6/17, 9:32 AM, "Adam Borowski" <kilob...@angband.pl> wrote: > > Got a reproducible crash on amd64: > > > > [98235.266511] BUG: unable to handle kernel paging request at &g

Re: [PATCH v2 3/4] btrfs: Add zstd support

On Fri, Jul 07, 2017 at 11:17:49PM +, Nick Terrell wrote: > On 7/6/17, 9:32 AM, "Adam Borowski" wrote: > > Got a reproducible crash on amd64: > > > > [98235.266511] BUG: unable to handle kernel paging request at > > c90001251000 > > [98235.314

Re: [PATCH v2 3/4] btrfs: Add zstd support

On Thu, Jun 29, 2017 at 12:41:07PM -0700, Nick Terrell wrote: > Add zstd compression and decompression support to BtrFS. zstd at its > fastest level compresses almost as well as zlib, while offering much > faster compression and decompression, approaching lzo speeds. Got a reproducible crash on

Re: [PATCH v2 3/4] btrfs: Add zstd support

On Thu, Jun 29, 2017 at 12:41:07PM -0700, Nick Terrell wrote: > Add zstd compression and decompression support to BtrFS. zstd at its > fastest level compresses almost as well as zlib, while offering much > faster compression and decompression, approaching lzo speeds. Got a reproducible crash on

Re: [PATCH v2 3/4] btrfs: Add zstd support

On Thu, Jun 29, 2017 at 12:41:07PM -0700, Nick Terrell wrote: > Add zstd compression and decompression support to BtrFS. zstd at its > fastest level compresses almost as well as zlib, while offering much > faster compression and decompression, approaching lzo speeds. > +static int

Re: [PATCH v2 3/4] btrfs: Add zstd support

On Thu, Jun 29, 2017 at 12:41:07PM -0700, Nick Terrell wrote: > Add zstd compression and decompression support to BtrFS. zstd at its > fastest level compresses almost as well as zlib, while offering much > faster compression and decompression, approaching lzo speeds. > +static int

Re: [PATCH] lib/zstd: use div_u64() to let it build on 32-bit

On Tue, Jun 27, 2017 at 05:27:51AM +, Nick Terrell wrote: > Adam, I’ve applied the same patch in my tree. I’ll send out the update [1] > once it's reviewed, since I also reduced the stack usage of functions > using over 1 KB of stack space. > > I have userland tests set up mocking the linux

Re: [PATCH] lib/zstd: use div_u64() to let it build on 32-bit

On Tue, Jun 27, 2017 at 05:27:51AM +, Nick Terrell wrote: > Adam, I’ve applied the same patch in my tree. I’ll send out the update [1] > once it's reviewed, since I also reduced the stack usage of functions > using over 1 KB of stack space. > > I have userland tests set up mocking the linux

[PATCH] lib/zstd: use div_u64() to let it build on 32-bit

ted to 2³²-1 elsewhere despite being declared as size_t, so it's ok to use 64/32 -- it's much faster on eg. x86-32 than 64/64. Signed-off-by: Adam Borowski <kilob...@angband.pl> --- lib/zstd/fse_compress.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/lib/zst

[PATCH] lib/zstd: use div_u64() to let it build on 32-bit

ted to 2³²-1 elsewhere despite being declared as size_t, so it's ok to use 64/32 -- it's much faster on eg. x86-32 than 64/64. Signed-off-by: Adam Borowski --- lib/zstd/fse_compress.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/lib/zstd/fse_compress.c b/lib/zstd

Re: [PATCH 3/4] btrfs: Add zstd support

On Mon, Jun 26, 2017 at 03:03:17AM +0800, kbuild test robot wrote: > Hi Nick, > > url: > https://github.com/0day-ci/linux/commits/Nick-Terrell/lib-Add-xxhash-module/20170625-214344 > config: i386-allmodconfig (attached as .config) > compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 > reproduce:

Re: [PATCH 3/4] btrfs: Add zstd support

On Mon, Jun 26, 2017 at 03:03:17AM +0800, kbuild test robot wrote: > Hi Nick, > > url: > https://github.com/0day-ci/linux/commits/Nick-Terrell/lib-Add-xxhash-module/20170625-214344 > config: i386-allmodconfig (attached as .config) > compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 > reproduce:

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

[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 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 --- drivers/tty/vt/consolemap.c | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/drivers/tty/vt/consolemap.c

[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 --- drivers/tty/vt/consolemap.c | 31 +++ 1 file changed, 7 insertions(+), 24 deletions(-) diff --git

[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

[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 --- 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 c6a692f63a9b..a5f88cf0f61d 100644

[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 5/5] vt: drop access_ok() calls in unimap ioctls

Done by copy_{from,to}_user(). Signed-off-by: Adam Borowski --- 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_ioctl.c +++ b/drivers/tty/vt

[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 CC: sta...@vger.kernel.org # v3.7- --- drivers/tty/vt/vt.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/tty/vt/vt.c b/drivers/tty

[PATCH 0/5] vt: get rid of worst cases of __put_user/__get_user

a few patches applying the lessons from that discussion to vt. None of the uses is performance-critical, but at least we get a nice bit of code simplification. And, it's a start of manual review + conversion that Al Viro wants. Adam Borowski (5): vt: use copy_from/to_user instead of __get

[PATCH 0/5] vt: get rid of worst cases of __put_user/__get_user

a few patches applying the lessons from that discussion to vt. None of the uses is performance-critical, but at least we get a nice bit of code simplification. And, it's a start of manual review + conversion that Al Viro wants. Adam Borowski (5): vt: use copy_from/to_user instead of __get

[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] 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 --- Compare this if clause with the two above it. Nice copypaste. :) drivers/tty/vt/vt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers

Re: [PATCH 0/2] blackfin: Remove dead DSA code

On Sun, May 28, 2017 at 04:59:47PM -0700, Florian Fainelli wrote: > Hello? anyone still maintaining blackfin here? Looks like people edit arch/blackfin/ a lot whenever it interferes with some other work, but the only blackfin-specific fixes seem to be a couple of drive-by ones by Al Viro, then

Re: [PATCH 0/2] blackfin: Remove dead DSA code

On Sun, May 28, 2017 at 04:59:47PM -0700, Florian Fainelli wrote: > Hello? anyone still maintaining blackfin here? Looks like people edit arch/blackfin/ a lot whenever it interferes with some other work, but the only blackfin-specific fixes seem to be a couple of drive-by ones by Al Viro, then

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 07:57:45AM +0100, Al Viro wrote: > On Fri, May 12, 2017 at 06:00:44PM -0700, Linus Torvalds wrote: > > But the *first* thing I'd like to do would be to just get rid of > > __get_user/__put_user as a thing. It really does generate nasty code, > > and we might as well just

Re: [git pull] uaccess-related bits of vfs.git

On Sat, May 13, 2017 at 07:57:45AM +0100, Al Viro wrote: > On Fri, May 12, 2017 at 06:00:44PM -0700, Linus Torvalds wrote: > > But the *first* thing I'd like to do would be to just get rid of > > __get_user/__put_user as a thing. It really does generate nasty code, > > and we might as well just

Re: sun50i-a64-pinctrl WARN_ON drivers/base/dd.c:349

On Fri, Apr 28, 2017 at 06:03:14PM -0400, Tejun Heo wrote: > On Tue, Apr 18, 2017 at 10:12:16AM +0100, Andre Przywara wrote: > > Yeah, so I stack-dumped on the zero allocations and indeed they are > > called from cleanup functions: > > drivers/pinctrl/pinmux.c:pinmux_generic_free_functions(): > >

Re: sun50i-a64-pinctrl WARN_ON drivers/base/dd.c:349

On Fri, Apr 28, 2017 at 06:03:14PM -0400, Tejun Heo wrote: > On Tue, Apr 18, 2017 at 10:12:16AM +0100, Andre Przywara wrote: > > Yeah, so I stack-dumped on the zero allocations and indeed they are > > called from cleanup functions: > > drivers/pinctrl/pinmux.c:pinmux_generic_free_functions(): > >

Re: [PATCH] btrfs: scrub: use do_div() for 64-by-32 division

On Sun, Apr 09, 2017 at 05:58:54AM +0200, Adam Borowski wrote: > On Sat, Apr 08, 2017 at 11:07:37PM +0200, Adam Borowski wrote: > > Unbreaks ARM and possibly other 32-bit architectures. > > Turns out those "other 32-bit architectures" happen to include i386. >

Re: [PATCH] btrfs: scrub: use do_div() for 64-by-32 division

On Sun, Apr 09, 2017 at 05:58:54AM +0200, Adam Borowski wrote: > On Sat, Apr 08, 2017 at 11:07:37PM +0200, Adam Borowski wrote: > > Unbreaks ARM and possibly other 32-bit architectures. > > Turns out those "other 32-bit architectures" happen to include i386. >

Re: [PATCH] btrfs: scrub: use do_div() for 64-by-32 division

On Sat, Apr 08, 2017 at 11:07:37PM +0200, Adam Borowski wrote: > Unbreaks ARM and possibly other 32-bit architectures. Turns out those "other 32-bit architectures" happen to include i386. A modular build: ERROR: "__udivdi3" [fs/btrfs/btrfs.ko] undefined! With the

Re: [PATCH] btrfs: scrub: use do_div() for 64-by-32 division

On Sat, Apr 08, 2017 at 11:07:37PM +0200, Adam Borowski wrote: > Unbreaks ARM and possibly other 32-bit architectures. Turns out those "other 32-bit architectures" happen to include i386. A modular build: ERROR: "__udivdi3" [fs/btrfs/btrfs.ko] undefined! With the

[PATCH] btrfs: scrub: use do_div() for 64-by-32 division

Unbreaks ARM and possibly other 32-bit architectures. Fixes: 7d0ef8b4d: Btrfs: update scrub_parity to use u64 stripe_len Reported-by: Icenowy Zheng <icen...@aosc.io> Signed-off-by: Adam Borowski <kilob...@angband.pl> --- You'd probably want to squash this with Liu's commit, to be ni

[PATCH] btrfs: scrub: use do_div() for 64-by-32 division

Unbreaks ARM and possibly other 32-bit architectures. Fixes: 7d0ef8b4d: Btrfs: update scrub_parity to use u64 stripe_len Reported-by: Icenowy Zheng Signed-off-by: Adam Borowski --- You'd probably want to squash this with Liu's commit, to be nice to future bisects. Tested on amd64 where all

Re: Linux next-20170407 failed to build on ARM due to usage of mod in btrfs code

On Sat, Apr 08, 2017 at 02:45:34PM -0300, Fabio Estevam wrote: > On Sat, Apr 8, 2017 at 1:02 PM, Icenowy Zheng wrote: > > Hello everyone, > > Today I tried to build a kernel with btrfs enabled on ARM, then when linking > > I met such an error: > > > > ``` > > fs/built-in.o: In

Re: Linux next-20170407 failed to build on ARM due to usage of mod in btrfs code

On Sat, Apr 08, 2017 at 02:45:34PM -0300, Fabio Estevam wrote: > On Sat, Apr 8, 2017 at 1:02 PM, Icenowy Zheng wrote: > > Hello everyone, > > Today I tried to build a kernel with btrfs enabled on ARM, then when linking > > I met such an error: > > > > ``` > > fs/built-in.o: In function

Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

On Mon, Apr 03, 2017 at 04:09:38PM -0400, Nicolas Pitre wrote: > On Mon, 3 Apr 2017, Adam Borowski wrote: > > > On Mon, Apr 03, 2017 at 08:31:03AM -0700, Andi Kleen wrote: > > > Except for that (and possibly VT) it is unlikely that people really > > > rely on the o

Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

On Mon, Apr 03, 2017 at 04:09:38PM -0400, Nicolas Pitre wrote: > On Mon, 3 Apr 2017, Adam Borowski wrote: > > > On Mon, Apr 03, 2017 at 08:31:03AM -0700, Andi Kleen wrote: > > > Except for that (and possibly VT) it is unlikely that people really > > > rely on the o

Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

On Mon, Apr 03, 2017 at 08:31:03AM -0700, Andi Kleen wrote: > Except for that (and possibly VT) it is unlikely that people really > rely on the obsolete terminal features from the 70ies. So it's a kind > of cleanup. But... but... but what shall we do without OLCUC?!? I guess sending these

Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

On Mon, Apr 03, 2017 at 08:31:03AM -0700, Andi Kleen wrote: > Except for that (and possibly VT) it is unlikely that people really > rely on the obsolete terminal features from the 70ies. So it's a kind > of cleanup. But... but... but what shall we do without OLCUC?!? I guess sending these

[PATCH 3/4] n_tty: support th, ae and ng runes

relationship to keep alignment, thus you need to write 'þ', 'æ' or 'ŋ' (or uppercase). Unless you're Icelandic, it's easiest to use the Compose key. Signed-off-by: Adam Borowski <kilob...@angband.pl> --- drivers/tty/n_tty.c | 35 +-- 1 file changed, 33 insertions

[PATCH 3/4] n_tty: support th, ae and ng runes

relationship to keep alignment, thus you need to write 'þ', 'æ' or 'ŋ' (or uppercase). Unless you're Icelandic, it's easiest to use the Compose key. Signed-off-by: Adam Borowski --- drivers/tty/n_tty.c | 35 +-- 1 file changed, 33 insertions(+), 2 deletions(-) diff

[PATCH 2/4] n_tty: use runes rather than uppercase in IUTF8 OLCUC mode

is shared with 'k', I sacrificed period accuracy for usability. 'q' 'v' 'x' are from Medieval runes (12th to 15th centuries). 'x' could use Anglo-Saxon eolhx but that's same glyph (and Unicode codepoint) as Elder Futhark algiz 'z'. Signed-off-by: Adam Borowski <kilob...@angband.pl> --- dri

[PATCH 2/4] n_tty: use runes rather than uppercase in IUTF8 OLCUC mode

is shared with 'k', I sacrificed period accuracy for usability. 'q' 'v' 'x' are from Medieval runes (12th to 15th centuries). 'x' could use Anglo-Saxon eolhx but that's same glyph (and Unicode codepoint) as Elder Futhark algiz 'z'. Signed-off-by: Adam Borowski --- drivers/tty/n_

[PATCH 4/4] n_tty: wrap all OLCUC code in a config option

Setting it to N, beside dropping runes, also disables old-style support for all-caps OLCUC. To get those 40 years old terminals to work, set CONFIG_TTY_RUNES=y which will DTRT when stty iutf8 is off. Signed-off-by: Adam Borowski <kilob...@angband.pl> --- drivers/tty/Kconfi

[PATCH 4/4] n_tty: wrap all OLCUC code in a config option

Setting it to N, beside dropping runes, also disables old-style support for all-caps OLCUC. To get those 40 years old terminals to work, set CONFIG_TTY_RUNES=y which will DTRT when stty iutf8 is off. Signed-off-by: Adam Borowski --- drivers/tty/Kconfig | 17 + drivers/tty

[PATCH 1/4] n_tty: don't mangle tty codes in OLCUC mode

as of Linux 0.11 and I see it in 0.01 sources (whose images fail to boot for me, I didn't try very hard). It was less of a failure then as the shell didn't produce tty codes for normal operation. Signed-off-by: Adam Borowski <kilob...@angband.pl> --- drivers/tty/n_tty.

[PATCH 1/4] n_tty: don't mangle tty codes in OLCUC mode

as of Linux 0.11 and I see it in 0.01 sources (whose images fail to boot for me, I didn't try very hard). It was less of a failure then as the shell didn't produce tty codes for normal operation. Signed-off-by: Adam Borowski --- drivers/tty/n_tty.c | 58

[GIT PULL] runes

. Meow! -- sorry, ᛗᛖᛟᚹ! Commits up to 14f34ba1d8748f252f941b5bb87efd7b1ed55868 on top of c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201. Adam Borowski (4): n_tty: don't mangle tty codes in OLCUC mode n_tty: use runes rather than

[GIT PULL] runes

. Meow! -- sorry, ᛗᛖᛟᚹ! Commits up to 14f34ba1d8748f252f941b5bb87efd7b1ed55868 on top of c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201. Adam Borowski (4): n_tty: don't mangle tty codes in OLCUC mode n_tty: use runes rather than

[PATCH v2 2/2] vt: make mouse selection of non-ASCII consistent

ot special-case any non-ASCII anymore. Attempts to set these via ioctl will be silently ignored. As an extra bonus, we debloat the kernel by 128 bytes. Signed-off-by: Adam Borowski <kilob...@angband.pl> --- v2: Got rid of hard-coded array sizes. drivers/tty/vt/selection.c | 16 ++--

[PATCH v2 2/2] vt: make mouse selection of non-ASCII consistent

ot special-case any non-ASCII anymore. Attempts to set these via ioctl will be silently ignored. As an extra bonus, we debloat the kernel by 128 bytes. Signed-off-by: Adam Borowski --- v2: Got rid of hard-coded array sizes. drivers/tty/vt/selection.c | 16 ++-- 1 file changed, 6

[PATCH v2 1/2] vt: set mouse selection word-chars to gpm's default

Since forever, gpm was this code's only user, and it overrides the table on start so the default was never seen -- until Bill Allombert's "consolation" came in. The in-kernel set is "A-Za-z0-9_" which fails to catch typical file names, etc. Let's change this to gpm's conservative default, ie

[PATCH v2 1/2] vt: set mouse selection word-chars to gpm's default

Since forever, gpm was this code's only user, and it overrides the table on start so the default was never seen -- until Bill Allombert's "consolation" came in. The in-kernel set is "A-Za-z0-9_" which fails to catch typical file names, etc. Let's change this to gpm's conservative default, ie

[PATCH 1/2] vt: set mouse selection word-chars to gpm's default

Since forever, gpm was this code's only user, and it overrides the table on start so the default was never seen -- until Bill Allombert's "consolation" came in. The in-kernel set is "A-Za-z0-9_" which fails to catch typical file names, etc. Let's change this to gpm's conservative default, ie

[PATCH 1/2] vt: set mouse selection word-chars to gpm's default

Since forever, gpm was this code's only user, and it overrides the table on start so the default was never seen -- until Bill Allombert's "consolation" came in. The in-kernel set is "A-Za-z0-9_" which fails to catch typical file names, etc. Let's change this to gpm's conservative default, ie

[PATCH 2/2] vt: make mouse selection of non-ASCII consistent

ot special-case any non-ASCII anymore. Attempts to set these via ioctl will be silently ignored. As an extra bonus, we debloat the kernel by 128 bytes. Signed-off-by: Adam Borowski <kilob...@angband.pl> --- drivers/tty/vt/selection.c | 16 ++-- 1 file changed, 6 insertions(

[PATCH 2/2] vt: make mouse selection of non-ASCII consistent

ot special-case any non-ASCII anymore. Attempts to set these via ioctl will be silently ignored. As an extra bonus, we debloat the kernel by 128 bytes. Signed-off-by: Adam Borowski --- drivers/tty/vt/selection.c | 16 ++-- 1 file changed, 6 insertions(+), 10 deletions(-) diff --git

[PATCH 0/2] vt: mouse selection word boundaries

Hi! Here's a couple of really low priority fixes to how "word chars" for mouse selection are determined. Patch 1 (adds "-./") is an epitome of "apply if bored": for two decades, only gpm used this, and it always ignored the defaults. Bill Allombert made a second implementation, "consolation",

[PATCH 0/2] vt: mouse selection word boundaries

Hi! Here's a couple of really low priority fixes to how "word chars" for mouse selection are determined. Patch 1 (adds "-./") is an epitome of "apply if bored": for two decades, only gpm used this, and it always ignored the defaults. Bill Allombert made a second implementation, "consolation",

Re: [PATCH linux-next] tty: Disable default console blanking interval

On Wed, Mar 22, 2017 at 07:50:32AM -0600, Tim Gardner wrote: > BugLink: http://bugs.launchpad.net/bugs/869017 > > I'm not particularly knowledgable about console issues. Is a blaknking > interval > relevant in a post CRT world ? The argument in the bug description seems > compelling. I have no

Re: [PATCH linux-next] tty: Disable default console blanking interval

On Wed, Mar 22, 2017 at 07:50:32AM -0600, Tim Gardner wrote: > BugLink: http://bugs.launchpad.net/bugs/869017 > > I'm not particularly knowledgable about console issues. Is a blaknking > interval > relevant in a post CRT world ? The argument in the bug description seems > compelling. I have no

Re: [PATCHv3] x86/mm: set x32 syscall bit in SET_PERSONALITY()

On Tue, Mar 21, 2017 at 08:47:11PM +0300, Dmitry Safonov wrote: > After my changes to mmap(), its code now relies on the bitness of > performing syscall. According to that, it chooses the base of allocation: > mmap_base for 64-bit mmap() and mmap_compat_base for 32-bit syscall. > It was done by: >

Re: [PATCHv3] x86/mm: set x32 syscall bit in SET_PERSONALITY()

On Tue, Mar 21, 2017 at 08:47:11PM +0300, Dmitry Safonov wrote: > After my changes to mmap(), its code now relies on the bitness of > performing syscall. According to that, it chooses the base of allocation: > mmap_base for 64-bit mmap() and mmap_compat_base for 32-bit syscall. > It was done by: >

Re: linux-next: x86: Unalbe to run x32 processes on the x86_64 kernel

On Tue, Mar 21, 2017 at 07:45:39AM +0100, Ingo Molnar wrote: > * Andrei Vagin wrote: > > > # first bad commit: [45fc8757d1d2128e342b4e7ef39adedf7752faac] x86: > > Make the GDT remapping read-only on 64-bit > > Just wondering, does the following commit fix it: > >

Re: linux-next: x86: Unalbe to run x32 processes on the x86_64 kernel

On Tue, Mar 21, 2017 at 07:45:39AM +0100, Ingo Molnar wrote: > * Andrei Vagin wrote: > > > # first bad commit: [45fc8757d1d2128e342b4e7ef39adedf7752faac] x86: > > Make the GDT remapping read-only on 64-bit > > Just wondering, does the following commit fix it: > > 5b781c7e317f x86/tls:

Re: linux-next: x86: Unalbe to run x32 processes on the x86_64 kernel

On Mon, Mar 20, 2017 at 04:57:39PM -0700, Andrei Vagin wrote: > We run CRIU tests on linux-next. And today we found that when we start > x32 processes, a kernel bug is triggered: > > [root@fc24 ~]# uname -a > Linux fc24 4.11.0-rc2-next-20170320 #159 SMP Mon Mar 20 16:53:58 PDT > 2017 x86_64

Re: linux-next: x86: Unalbe to run x32 processes on the x86_64 kernel

On Mon, Mar 20, 2017 at 04:57:39PM -0700, Andrei Vagin wrote: > We run CRIU tests on linux-next. And today we found that when we start > x32 processes, a kernel bug is triggered: > > [root@fc24 ~]# uname -a > Linux fc24 4.11.0-rc2-next-20170320 #159 SMP Mon Mar 20 16:53:58 PDT > 2017 x86_64

Re: sun50i-a64-pinctrl WARN_ON drivers/base/dd.c:349

On Fri, Mar 17, 2017 at 10:44:22AM -0400, Tejun Heo wrote: > On Fri, Mar 17, 2017 at 10:28:34PM +0800, Icenowy Zheng wrote: > > > It's warning that the device has resources associated with it on > > > probe. There gotta be something fishy going on with the probing > > > sequence. How reproducible

Re: sun50i-a64-pinctrl WARN_ON drivers/base/dd.c:349

On Fri, Mar 17, 2017 at 10:44:22AM -0400, Tejun Heo wrote: > On Fri, Mar 17, 2017 at 10:28:34PM +0800, Icenowy Zheng wrote: > > > It's warning that the device has resources associated with it on > > > probe. There gotta be something fishy going on with the probing > > > sequence. How reproducible

Re: [PATCH v9 4/4] console: Make persistent scrollback a boot parameter

On Fri, Feb 03, 2017 at 05:04:15PM +0100, Manuel Schölling wrote: > On Thu, 2017-02-02 at 15:07 -0500, Paul Gortmaker wrote: > > On Tue, Jan 10, 2017 at 4:28 PM, Manuel Schölling > > wrote: > > > The impact of the persistent scrollback feature on the code size is > > >

Re: [PATCH v9 4/4] console: Make persistent scrollback a boot parameter

On Fri, Feb 03, 2017 at 05:04:15PM +0100, Manuel Schölling wrote: > On Thu, 2017-02-02 at 15:07 -0500, Paul Gortmaker wrote: > > On Tue, Jan 10, 2017 at 4:28 PM, Manuel Schölling > > wrote: > > > The impact of the persistent scrollback feature on the code size is > > > rather small, so the config

Re: [PATCH v10 3/4] console: Add persistent scrollback buffers for all VGA consoles

On Fri, Jan 20, 2017 at 02:31:56PM +0100, Greg KH wrote: > On Fri, Jan 20, 2017 at 02:16:11PM +0100, Adam Borowski wrote: > > On Fri, Jan 20, 2017 at 12:04:12AM +0100, Adam Borowski wrote: > > > On Thu, Jan 19, 2017 at 05:33:14PM +0100, Greg KH wrote: > > > >

Re: [PATCH v10 3/4] console: Add persistent scrollback buffers for all VGA consoles

On Fri, Jan 20, 2017 at 02:31:56PM +0100, Greg KH wrote: > On Fri, Jan 20, 2017 at 02:16:11PM +0100, Adam Borowski wrote: > > On Fri, Jan 20, 2017 at 12:04:12AM +0100, Adam Borowski wrote: > > > On Thu, Jan 19, 2017 at 05:33:14PM +0100, Greg KH wrote: > > > >

Re: [PATCH v10 3/4] console: Add persistent scrollback buffers for all VGA consoles

On Fri, Jan 20, 2017 at 12:04:12AM +0100, Adam Borowski wrote: > On Thu, Jan 19, 2017 at 05:33:14PM +0100, Greg KH wrote: > > On Thu, Jan 19, 2017 at 05:12:15PM +0100, Manuel Schölling wrote: > > > On Thu, 2017-01-19 at 14:23 +0100, Greg KH wrote: > > > > On Fri, Ja

Re: [PATCH v10 3/4] console: Add persistent scrollback buffers for all VGA consoles

On Fri, Jan 20, 2017 at 12:04:12AM +0100, Adam Borowski wrote: > On Thu, Jan 19, 2017 at 05:33:14PM +0100, Greg KH wrote: > > On Thu, Jan 19, 2017 at 05:12:15PM +0100, Manuel Schölling wrote: > > > On Thu, 2017-01-19 at 14:23 +0100, Greg KH wrote: > > > > On Fri, Ja

Re: [PATCH v10 3/4] console: Add persistent scrollback buffers for all VGA consoles

On Thu, Jan 19, 2017 at 05:33:14PM +0100, Greg KH wrote: > On Thu, Jan 19, 2017 at 05:12:15PM +0100, Manuel Schölling wrote: > > On Thu, 2017-01-19 at 14:23 +0100, Greg KH wrote: > > > On Fri, Jan 13, 2017 at 09:07:57PM +0100, Manuel Schölling wrote: > > > > +   This feature might break your

Re: [PATCH v10 3/4] console: Add persistent scrollback buffers for all VGA consoles

On Thu, Jan 19, 2017 at 05:33:14PM +0100, Greg KH wrote: > On Thu, Jan 19, 2017 at 05:12:15PM +0100, Manuel Schölling wrote: > > On Thu, 2017-01-19 at 14:23 +0100, Greg KH wrote: > > > On Fri, Jan 13, 2017 at 09:07:57PM +0100, Manuel Schölling wrote: > > > > +   This feature might break your

Re: [PATCH v10 3/4] console: Add persistent scrollback buffers for all VGA consoles

On Thu, Jan 19, 2017 at 05:12:15PM +0100, Manuel Schölling wrote: > On Thu, 2017-01-19 at 14:23 +0100, Greg KH wrote: > > On Fri, Jan 13, 2017 at 09:07:57PM +0100, Manuel Schölling wrote: > > > Add a scrollback buffers for each VGA console. The benefit is that > > > the scrollback history is not

<    1   2   3   4   5   >