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 *sys_table_a
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 ot
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 dele
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
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 chang
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 --
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
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 you'
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 not
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. :)
>
>
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 corrup
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 t
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 other
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. Ev
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
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 address.
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
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
> >> > [...]
>
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..0d
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 us
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 mak
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
---
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 b/
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
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 scrat
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 ab3fc90
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 si
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 proces
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 Conduct
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 caller).
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 used
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
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 wh
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 brightn
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
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 `l1tf_vm
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:
> > >
> >
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 tested
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
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
>
On Thu, Dec 13, 2018 at 10:37:31AM +0100, Sven Hartrumpf wrote:
> Will the proposed patch ("only") remove the possibility to build x32 kernels
> or will it make impossible to compile and run any x32 binaries?
There's no such thing as x32 kernels. It's an ABI atop amd64 kernels; the
kernel is alwa
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 p
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
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 smarter
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
represe
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
for most users.
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
ind
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
--- a
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,
resu
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 1
other consoles: 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 +
, 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
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
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
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(+)
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
> > > >
>From 30886e965e7aeae8d3729c4bacf614a19e103cea 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"
On Thu, Apr 25, 2019 at 11:32:38AM +0200, Nico Schottelius wrote:
> running some IPv6 only
> networks. The systems in the IPv6 only networks do not need any IPv4
> support anymore and thus for switches/routers we turned the support off.
> Today we tried to turn off IPv4 in the Linux kernel at comp
On Thu, Apr 25, 2019 at 01:38:06AM +1000, Aleksa Sarai wrote:
> * openat(2) ignores unknown flags, meaning that old kernels will ignore
>new programs trying to use O_THISROOT and might end up causing
>security issues. Yes, it'd be trivial to check whether the new O_*
>flags are support
On Mon, Feb 08, 2021 at 07:08:05AM +, Wadepohl, Wolfram wrote:
> I'm sad to hear that 5.10 has still an EOL of Dec, 2022. We are in
> development of our 1st GNU/Linux based System, 50k devices for IoT.
[...]
> In general a 2 year support for embedded systems in automation is not a
> reasonable
On Fri, Dec 04, 2020 at 10:10:16AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Dec 04, 2020 at 09:51:07AM +0100, Jiri Slaby wrote:
> > > > > On Fri, Dec 04, 2020 at 08:22:41AM +0100, Jiri Slaby wrote:
> > > > > > On 03. 12. 20, 3:03, Jann Horn wrote:
> > > > > > > Delete this dead code; but leave th
On Tue, Mar 16, 2021 at 04:45:02PM +0100, Jiri Olsa wrote:
> hi,
> when running 'perf top' on AMD Rome (/proc/cpuinfo below)
> with fedora 33 kernel 5.10.22-200.fc33.x86_64
>
> we got unknown NMI messages:
>
> [ 226.700160] Uhhuh. NMI received for unknown reason 3d on CPU 90.
> [ 226.700162] Do
On Wed, Mar 10, 2021 at 02:26:43PM +, Matthew Wilcox wrote:
> On Wed, Mar 10, 2021 at 08:21:59AM -0600, Goldwyn Rodrigues wrote:
> > DAX on btrfs has been attempted[1]. Of course, we could not
>
> But why? A completeness fetish? I don't understand why you decided
> to do this work.
* xfs ca
On Sat, Mar 13, 2021 at 11:24:00AM -0500, Neal Gompa wrote:
> On Sat, Mar 13, 2021 at 8:09 AM Adam Borowski wrote:
> >
> > On Wed, Mar 10, 2021 at 02:26:43PM +, Matthew Wilcox wrote:
> > > On Wed, Mar 10, 2021 at 08:21:59AM -0600, Goldwyn Rodrigues wrote:
>
On Tue, Mar 09, 2021 at 08:39:10PM +0100, Pavel Machek wrote:
> > I'd like people from Intel to contact me. There's more to fix there,
> > and AFAICT original author went away.
>
> The following message to was
> undeliverable.
> : Recipient
> +address rejected: User unknown in virtual mailbox ta
On Mon, Jan 25, 2021 at 11:55:11AM -0800, Scott Branden wrote:
> The 5.10 LTS kernel being officially LTS supported for 2 years presents a
> problem:
> why would anyone select a 5.10 kernel with 2 year LTS when 5.4 kernel has a 6
> year LTS.
>
> Yet, various unofficial reports indicate it will b
On Sun, Jan 03, 2021 at 05:45:16PM +, David Laight wrote:
> From: Ilkka Prusi
> > Note that /sbin is now just a symlink to /usr/sbin on Debian since 10
> > (Buster) as per FHS[1][2].
> >
> > [1] https://wiki.linuxfoundation.org/lsb/fhs
> > [2]
> > https://arstechnica.com/information-technolo
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/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 r
uch a code
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
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 or
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
of address 81c021c8 with insufficient space
for an object of type 'const u64'
Signed-off-by: Adam Borowski
---
arch/x86/events/amd/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c
index 86a9bec..5fa1b8e 100644
--- a/arch/x
On Wed, Apr 27, 2016 at 10:03:45AM +0200, Ingo Molnar wrote:
> * Adam Borowski wrote:
> > diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c
> > index 86a9bec..5fa1b8e 100644
> > --- a/arch/x86/events/amd/core.c
> > +++ b/arch/x86/events/amd/core.c
>
ur in arch/x86/events/amd/core.c:132:9
load of address 81c021c8 with insufficient space
for an object of type 'const u64'
Signed-off-by: Adam Borowski
---
arch/x86/events/amd/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/events/amd/core.c b
On Wed, 6 Apr 2016, Geert Uytterhoeven wrote:
> On Wed, Apr 6, 2016 at 12:08 AM, Yury Norov wrote:
>> v6:
>> - time_t, __kenel_off_t and other types turned to be 32-bit
>>for compatibility reasons (after v5 discussion);
Introducing a new arch today with y2038 problems is not a good idea.
Li
On Tue, Mar 19, 2019 at 04:31:21PM +, Alan Cox wrote:
> On Sat, 16 Mar 2019 10:35:43 +0100
> Samuel Thibault wrote:
> > Chris Brannon, le ven. 15 mars 2019 18:19:39 -0700, a ecrit:
> > > What kind of reproducer do you need here? It's straightforward to
> > > reproduce in casual use, at least
On Wed, Aug 21, 2019 at 11:59:53PM +, Ghannam, Yazen wrote:
> I've also added RFC patches to avoid the "ECC disabled" message for
> nodes without memory. I haven't fully tested these, but I wanted to get
> your thoughts. Here's an earlier discussion:
> https://lkml.kernel.org/r/20180321191335.7
On Thu, Aug 22, 2019 at 10:35:48AM +0200, Borislav Petkov wrote:
> On Thu, Aug 22, 2019 at 02:50:20AM +0200, Adam Borowski wrote:
> > While you're editing that code, could you please also cut the spam if ECC is
> > actually disabled? For example, a 2990WX with non-ECC
shutdown meant widespread breakage, but it's no longer
a reasonable filesystem for any non-special use.
Signed-off-by: Adam Borowski
---
Documentation/admin-guide/sysrq.rst | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/Documentation/admin-guide/sysr
On Thu, Oct 03, 2019 at 10:13:39AM +, David Laight wrote:
> From: Kurt Roeckx
> > Sent: 02 October 2019 17:56
> > As OpenSSL, we want cryptograhic secure random numbers. Before
> > getrandom(), Linux never provided a good API for that, both
> > /dev/random and /dev/urandom have problems. getran
On Tue, Apr 28, 2020 at 09:45:27AM +0200, Borislav Petkov wrote:
> On Tue, Apr 21, 2020 at 03:32:34AM +0200, Adam Borowski wrote:
> > Hi!
> > With kernels compiled with gcc-10, on two different machines (AMD Phenom2,
> > AMD 2990WX) I get the following panic during boot:
>
On Wed, Feb 20, 2019 at 09:20:20PM +0100, Juerg Haefliger wrote:
> On Wed, 20 Feb 2019 14:49:34 -0500
> Steven Rostedt wrote:
>
> > On Wed, 20 Feb 2019 17:13:33 +0100
> > Juerg Haefliger wrote:
> >
> > > echo -e and \e are not POSIX. Depending on what /bin/sh is, we can get
> > > incorrect outp
Drivers under MIT, BSD-17-clause, or uncle-Bob's-newest-take-on-PD are
all fine, not just GPL.
Signed-off-by: Adam Borowski
---
Not reformatting to fill lines, it'll semi-conflict with another patch
that's been acked but not yet pushed.
Documentation/process/stable-api-nonsense
On Thu, Jan 24, 2019 at 04:31:10PM +0100, Enrico Weigelt, metux IT consult
wrote:
> On 23.01.19 21:46, Ivan Ivanov wrote:
>
> > Linux really needs to stop adding new features and
> > refactor itself to a smaller and more secure codebase before going
> > forward. Maybe 1 year break would be nice.
On Fri, Aug 02, 2019 at 09:59:06PM +0200, Paul Menzel wrote:
> On 02.08.19 18:02, Greg Kroah-Hartman wrote:
> > On Fri, Aug 02, 2019 at 03:23:08PM +0200, Paul Menzel wrote:
> > > On a lot of devices, like servers, you have more than one serial console,
> > > and you do not always know, how they are
On Sat, Aug 03, 2019 at 03:55:37PM +0200, Greg Kroah-Hartman wrote:
> On Sat, Aug 03, 2019 at 03:23:23PM +0200, Adam Borowski wrote:
> > On Fri, Aug 02, 2019 at 09:59:06PM +0200, Paul Menzel wrote:
> > > Because the cable is always connected to the port on the back side, and
&
On Tue, Jun 25, 2019 at 11:02:36AM +0200, John Paul Adrian Glaubitz wrote:
> On 6/25/19 10:56 AM, Christoph Hellwig wrote:
> > arch/sh seems pretty much unmaintained these days. The last time I got
> > any reply to sh patches from the list maintainers, and the last maintainer
> > pull request was
On Fri, Jun 07, 2019 at 07:20:46PM +, Nick Terrell wrote:
> We'd love to get this mainlined as well!
>
> We're using these patches internally as well. We're seeing an improvement on
> an
> Intel Atom N3710, where boot time is reduced by one second over using an xz
> compressed kernel. It look
On Wed, Jan 09, 2019 at 06:38:58AM +0100, Mike Galbraith wrote:
> KVM seems to be busted in master ATM. All I have to do to have host
> start screaming and maybe exploding (if the guest doesn't do so first)
> is to try to install a (obese in this case) kernel over nfs mount of
> the host in a gues
r patch, no badness happened so far. Thanks!
> Reported-by: Adam Borowski
> Fixes: ac46d4f3c432 ("mm/mmu_notifier: use structure for
> invalidate_range_start/end calls v2")
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> - mmu_notifier_range_init(&range, vma->vm_mm,
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
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 chroot?
On Sun, Apr 01, 2018 at 10:56:21AM +0200, Richard Weinberger wrote:
> + .cow_lines = {
> + "\\ ^__^",
> + " \\ (oo)\\___",
> + "(__)\\ )\\/\\",
> + "||w |",
> +
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.
> > > >
>
On Tue, Dec 06, 2016 at 08:31:01AM -0500, Jan Stancek wrote:
> Starting with 4.9-rc8 / commit 8ab2ae655b ("default exported asm symbols to
> zero")
> I'm running into issue with kernel built with CONFIG_MODVERSIONS=y
> and (older) binutils (binutils-2.25.1-20.base.el7.ppc64le).
>
> Modules fail
On Tue, Nov 22, 2016 at 05:56:42PM +0100, Manuel Schölling wrote:
> On Mo, 2016-11-21 at 21:17 +0100, Adam Borowski wrote:
> > On Sun, Nov 20, 2016 at 10:58:08PM +0100, Manuel Schölling wrote:
> > > Add a scrollback buffers for each VGA console. The benefit is that
> > >
On Wed, Nov 23, 2016 at 09:08:28PM +0100, Philip Müller wrote:
> > due to following commit it seems the 64bit architecture of linux 4.9-rc
> > is not able to boot at all, as it is unable to find its root device:
> you have to apply following patch also:
>
> provide-asm-prototypes.h-for-x86.patch:
86, and an architecture-independent file that
can be used for common symbols.
User impact: kernels may fail to load modules at all when
CONFIG_MODVERSIONS=y.
Signed-off-by: Adam Borowski
Tested-by: Kalle Valo
Acked-by: Nicholas Piggin
Tested-by: Peter Wu
Tested-by: Oliver Hartkopp
---
Changes:
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 f
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
1 - 100 of 222 matches
Mail list logo
