[PATCH 1/1] staging: exfat: Update MAINTAINERS file

Add a L: tag so get_maintainers.pl output includes the linux-fsdevel list Signed-off-by: Valdis Kletnieks --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 3d09efe69508..188435ae 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6186,6 +6186,7

[PATCH 1/8] staging: exfat: Clean up namespace pollution, part 1

Make as much as possible static. We're over-exuberant here for the benefit of a following patch, as the compiler will flag now-unused static code Signed-off-by: Valdis Kletnieks --- drivers/staging/exfat/exfat.h | 156 ++--- drivers/staging/exfat/exfat_core.c | 142

[PATCH 6/8] staging: exfat: More static cleanups for exfat_core.c

Move static function bodies before first use, remove the definition in exfat.h Signed-off-by: Valdis Kletnieks --- drivers/staging/exfat/exfat.h | 6 - drivers/staging/exfat/exfat_core.c | 500 ++--- 2 files changed, 250 insertions(+), 256 deletions(-) diff --git

[PATCH 7/8] staging: exfat: Finished code movement for static cleanups in exfat_core.c

Move static function bodies before first use, remove the definition in exfat.h Signed-off-by: Valdis Kletnieks --- drivers/staging/exfat/exfat.h | 10 - drivers/staging/exfat/exfat_core.c | 661 ++--- 2 files changed, 330 insertions(+), 341 deletions(-) diff --git

[PATCH 4/8] staging: exfat: Cleanup static entries in exfat.h

Many of the static definitions that remain are not needed, as the function definition is already before the first use. Signed-off-by: Valdis Kletnieks --- drivers/staging/exfat/exfat.h | 53 --- 1 file changed, 53 deletions(-) diff --git a/drivers/staging/exfat

[PATCH 8/8] staging: exfat: Update TODO

Signed-off-by: Valdis Kletnieks --- drivers/staging/exfat/TODO | 20 1 file changed, 8 insertions(+), 12 deletions(-) diff --git a/drivers/staging/exfat/TODO b/drivers/staging/exfat/TODO index b60e50b9cf4e..110c30834bd2 100644 --- a/drivers/staging/exfat/TODO +++ b/drivers

[PATCH 5/8] staging: exfat: Clean up static definitions in exfat_cache.c

Move static function bodies before first use, remove the definition in exfat.h Signed-off-by: Valdis Kletnieks --- drivers/staging/exfat/exfat.h | 4 -- drivers/staging/exfat/exfat_cache.c | 94 +++-- 2 files changed, 48 insertions(+), 50 deletions(-) diff --git

[PATCH 3/8] staging: exfat: Remove FAT/VFAT mount support, part 2

Remove no longer referenced FAT/VFAT routines. Signed-off-by: Valdis Kletnieks --- drivers/staging/exfat/exfat.h | 49 +- drivers/staging/exfat/exfat_core.c | 755 - 2 files changed, 2 insertions(+), 802 deletions(-) diff --git a/drivers/staging/exfat/exfat.h

[PATCH 2/8] staging: exfat: Remove FAT/VFAT mount support, part 1

Remove the top-level mount functionality, to make this driver handle only exfat file systems. Signed-off-by: Valdis Kletnieks --- drivers/staging/exfat/Kconfig | 9 -- drivers/staging/exfat/exfat.h | 2 - drivers/staging/exfat/exfat_core.c | 142

[PATCH 0/8] staging: exfat: Code cleanups

Two main goals here - remove the code to mount FAT and VFAT filesystes, and make a lot of functions static to reduce namespace pollution. Valdis Kletnieks (8): staging: exfat: Clean up namespace pollution, part 1 staging: exfat: Remove FAT/VFAT mount support, part 1 staging: exfat: Remove

[tip:ras/core] RAS: Build debugfs.o only when enabled in Kconfig

Commit-ID: b6ff24f7b5101101ff897dfdde3f37924e676bc2 Gitweb: https://git.kernel.org/tip/b6ff24f7b5101101ff897dfdde3f37924e676bc2 Author: Valdis Kletnieks AuthorDate: Thu, 8 Aug 2019 16:32:27 +0200 Committer: Borislav Petkov CommitDate: Thu, 8 Aug 2019 17:44:02 +0200 RAS: Build

[tip:perf/core] perf/core: Make perf_swevent_init_cpu() static

Commit-ID: d18bf4229b1772e91c0c36772737c01cf9726720 Gitweb: https://git.kernel.org/tip/d18bf4229b1772e91c0c36772737c01cf9726720 Author: Valdis Kletnieks AuthorDate: Tue, 12 Mar 2019 04:06:37 -0400 Committer: Ingo Molnar CommitDate: Wed, 3 Apr 2019 09:52:34 +0200 perf/core: Make

[tip:x86/urgent] x86/mm/pti: Make local symbols static

Commit-ID: 4fe64a62e04cfb2dc1daab0d8f05d212aa014161 Gitweb: https://git.kernel.org/tip/4fe64a62e04cfb2dc1daab0d8f05d212aa014161 Author: Valdis Kletnieks AuthorDate: Tue, 12 Mar 2019 03:47:53 -0400 Committer: Thomas Gleixner CommitDate: Fri, 22 Mar 2019 13:31:28 +0100 x86/mm/pti: Make

[tip:core/urgent] watchdog/core: Make variables static

Commit-ID: 48084abf212052ca1d39fae064c581b1ce5b1fdf Gitweb: https://git.kernel.org/tip/48084abf212052ca1d39fae064c581b1ce5b1fdf Author: Valdis Kletnieks AuthorDate: Tue, 12 Mar 2019 05:33:48 -0400 Committer: Thomas Gleixner CommitDate: Fri, 22 Mar 2019 13:40:17 +0100 watchdog/core

[tip:timers/urgent] time/jiffies: Make refined_jiffies static

Commit-ID: e8750053d64a3317cbc15f8341f0f11ca751bfeb Gitweb: https://git.kernel.org/tip/e8750053d64a3317cbc15f8341f0f11ca751bfeb Author: Valdis Kletnieks AuthorDate: Tue, 12 Mar 2019 04:38:35 -0400 Committer: Thomas Gleixner CommitDate: Fri, 22 Mar 2019 13:38:26 +0100 time/jiffies

[tip:irq/urgent] genirq/devres: Remove excess parameter from kernel doc

Commit-ID: bb2e320565f997273fe04035bb6c17f643da6f8a Gitweb: https://git.kernel.org/tip/bb2e320565f997273fe04035bb6c17f643da6f8a Author: Valdis Kletnieks AuthorDate: Tue, 12 Mar 2019 04:17:56 -0400 Committer: Thomas Gleixner CommitDate: Fri, 22 Mar 2019 13:34:12 +0100 genirq/devres

Re: [PATCH] drivers/platform/x86/dell-rbtn.c - add missing #include

On Tue, 12 Mar 2019 23:46:11 +0100, Pali Rohar said: > Can you identify in which commit was introduced this problem? If yes, > then Fixes: keyword should be added into commit message. I admit not knowing how long that's been there - I mostly found myself with a large amount of free time, a good

Re: [bpf] 568f196756: BUG:assuming_atomic_context_at_kernel/seccomp.c

On Sat, 23 Feb 2019 00:15:38 +0100, Jann Horn said: > On Fri, Feb 22, 2019 at 11:42 PM wrote: > > Is there a reason this commit appeared in next-20190221 but did not seem to > > be > > in next-20190222 (confirmed via 'git tag --contains')?y ast@, he wanted to > > fix it in a different way: >

Re: [bpf] 568f196756: BUG:assuming_atomic_context_at_kernel/seccomp.c

On Thu, 21 Feb 2019 14:39:27 +0100, Daniel Borkmann said: > Fyi, false positive and already fixed in bpf-next. > > (https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=435b3ff5b08a99a15647be32735abf8db66cea9a) Is there a reason this commit appeared in next-20190221 but did

Re: [regression -next0117] What is kcompactd and why is he eating 100% of my cpu?

On Tue, 29 Jan 2019 20:06:39 -0500, valdis.kletni...@vt.edu said: > On Mon, 28 Jan 2019 10:16:27 +0100, Jan Kara said: > > > So my buffer_migrate_page_norefs() is certainly buggy in its current > > incarnation (as a result block device page cache is not migratable at all). > > I've sent Andrew a

Re: [regression -next0117] What is kcompactd and why is he eating 100% of my cpu?

On Mon, 28 Jan 2019 10:16:27 +0100, Jan Kara said: > So my buffer_migrate_page_norefs() is certainly buggy in its current > incarnation (as a result block device page cache is not migratable at all). > I've sent Andrew a patch over week ago but so far it got ignored. The patch > is attached, can

[PATCH] init/calibrate.c - provide proper prototype.

one to prevent surprises. Signed-off-by: Valdis Kletnieks diff --git a/include/linux/delay.h b/include/linux/delay.h index b78bab4395d8..8e6828094c1e 100644 --- a/include/linux/delay.h +++ b/include/linux/delay.h @@ -55,6 +55,7 @@ static inline void ndelay(unsigned long x) extern unsigned long

[PATCH] kernel/bpf/cgroup.c - clean up kerneldoc warnings

' Add a kerneldoc line for 'flags'. Fixing the warning for 'unused_flags' is best approached by removing the unused parameter on the function call. Signed-off-by: Valdis Kletnieks diff --git a/include/linux/bpf-cgroup.h b/include/linux/bpf-cgroup.h index 588dd5f0bd85..695b2a880d9a 100644

[PATCH] include/linux/bpf.h - fix missing prototype warnings...

__weak bpf_jit_free_exec(void *addr) | ^ All three are weak functions that archs can override, although none do so currently. Provide prototypes for when a new arch provides its own. Signed-off-by: Valdis Kletnieks diff --git a/include/linux/bpf.h b/include

[PATCH] kernel/bpf/core.c - fix bitrotted kerneldoc.

Over the years, the function signature has changed, the kerneldoc block hasn't. Signed-off-by: Valdis Kletnieks diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c index 2a81b8af3748..2728b6247091 100644 --- a/kernel/bpf/core.c +++ b/kernel/bpf/core.c @@ -1216,8 +1216,9 @@ bool

Re: [PATCH] bpf/core.c - silence warning messages

On Tue, 29 Jan 2019 00:22:26 +0100, Daniel Borkmann said: > I think moving in separate file would be overkill, imho. However, lets get > the kdoc and prototype warning fixed. I have a bunch of spare time at the moment, so the kdoc and prototype warnings are on my to-do list.

Re: [PATCH] bpf/core.c - silence warning messages

On Mon, 28 Jan 2019 09:18:45 -0800, Song Liu said: > On Sun, Jan 27, 2019 at 8:43 PM wrote: > > The attached patch silences the warnings, because we *know* we're > > overwriting > > the default initializer. That leaves bpf/core.c with only 6 other warnings, > > which become more visible in

Re: next-20190125 - objtool complains about dumpstack

On Sun, 27 Jan 2019 22:18:25 -0600, Josh Poimboeuf said: > On Sun, Jan 27, 2019 at 10:45:03PM -0500, valdis.kletni...@vt.edu wrote: > > Seen in a build: > > > > CC arch/x86/kernel/dumpstack.o > > arch/x86/kernel/dumpstack.o: warning: objtool: oops_begin()+0x9: undefined > > stack state >

[PATCH] kernel/hung_task.c - fix sparse warnings

it be static? kernel/hung_task.c:219:5: warning: symbol 'proc_dohung_task_timeout_secs' was not declared. Should it be static? Add the appropriate header file to provide declarations. Signed-off-by: Valdis Kletnieks diff --git a/kernel/hung_task.c b/kernel/hung_task.c index 4a9191617076

[PATCH] bpf/core.c - silence warning messages

initializer. That leaves bpf/core.c with only 6 other warnings, which become more visible in comparison. Signed-off-by: Valdis Kletnieks diff --git a/kernel/bpf/Makefile b/kernel/bpf/Makefile index 4c2fa3ac56f6..2606665f2cb5 100644 --- a/kernel/bpf/Makefile +++ b/kernel/bpf/Makefile @@ -21,3

next-20190125 - objtool complains about dumpstack

Seen in a build: CC arch/x86/kernel/dumpstack.o arch/x86/kernel/dumpstack.o: warning: objtool: oops_begin()+0x9: undefined stack state arch/x86/kernel/dumpstack.o: warning: objtool: oops_begin()+0x0: stack state mismatch: cfa1=6+16 cfa2=7+8 Probably a gcc9 code generation that objtool

Re: [PATCH] staging:iio:ad7152: Rename misspelled RESEVERD -> RESERVED

On Fri, 25 Jan 2019 22:14:32 -0200, Rodrigo Ribeiro said: > Maybe, one checkstyle patch is enough, right? Which drivers can I truly > contribute to? I'll give you a pointer to the "How to contribute" the Kernel Newbies list and IRC channel uses:

Re: [PATCH] drivers: iio: industrialio-core: add check when kzalloc fails

On Thu, 24 Jan 2019 19:58:00 +0530, Bharath Vedartham said: > add code to handle the case when kzalloc fails to allocate memory to dev > > Signed-off-by: Bharath Vedartham > dev_set_name(>dev, "iio:device%d", dev->id); > INIT_LIST_HEAD(>buffer_list); > + } else {

Re: [regression -next0117] What is kcompactd and why is he eating 100% of my cpu?

On Sun, 27 Jan 2019 17:00:27 +0100, Pavel Machek said: > > > I've noticed this as well on earlier kernels (next-20181224 to 20190115) > > > Some more info: > > > 1) echo 3 > /proc/sys/vm/drop_caches unwedges kcompactd in 1-3 seconds. > > This aspect is curious as it indicates that kcompactd could

Re: [regression -next0117] What is kcompactd and why is he eating 100% of my cpu?

On Sat, 26 Jan 2019 21:00:05 +0100, Pavel Machek said: > top - 13:38:51 up 1:42, 16 users, load average: 1.41, 1.93, 1.62 > Tasks: 182 total, 3 running, 138 sleeping, 0 stopped, 0 zombie > %Cpu(s): 2.3 us, 57.8 sy, 0.0 ni, 39.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 > st > KiB Mem:

Re: Heads up: next-20190115 and GCC 9.0 don't play nice.

On Fri, 25 Jan 2019 22:02:05 -0500, valdis.kletni...@vt.edu said: > So a GCC 9 escaped to Fedora Rawhide in the last few days, and things didn't > go well. Fortunately, I had the 8.2.1-7 RPMs still around. > > Issue 1: There's a new warning added for taking the address of a member of > a packed

Heads up: next-20190115 and GCC 9.0 don't play nice.

So a GCC 9 escaped to Fedora Rawhide in the last few days, and things didn't go well. Fortunately, I had the 8.2.1-7 RPMs still around. Issue 1: There's a new warning added for taking the address of a member of a packed array. It wasn't *too* noisy. Issue 2: Looks like it's not ready for prime

Re: [PATCH v3 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd

On Fri, 19 Oct 2018 10:57:31 -0700, Joel Fernandes said: > On Fri, Oct 19, 2018 at 10:32 AM, wrote: > > What is supposed to happen if some other process has an already existing R/W > > mmap of the region? (For that matter, the test program doesn't seem to > > actually test that the existing

Re: [PATCH v3 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd

On Fri, 19 Oct 2018 10:57:31 -0700, Joel Fernandes said: > On Fri, Oct 19, 2018 at 10:32 AM, wrote: > > What is supposed to happen if some other process has an already existing R/W > > mmap of the region? (For that matter, the test program doesn't seem to > > actually test that the existing

Re: [PATCH v3 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd

On Wed, 17 Oct 2018 23:59:07 -0700, "Joel Fernandes (Google)" said: > This usecase cannot be implemented with the existing F_SEAL_WRITE seal. > To support the usecase, this patch adds a new F_SEAL_FUTURE_WRITE seal > which prevents any future mmap and write syscalls from succeeding while > keeping

Re: [PATCH v3 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd

On Wed, 17 Oct 2018 23:59:07 -0700, "Joel Fernandes (Google)" said: > This usecase cannot be implemented with the existing F_SEAL_WRITE seal. > To support the usecase, this patch adds a new F_SEAL_FUTURE_WRITE seal > which prevents any future mmap and write syscalls from succeeding while > keeping

Re: [PATCH v2] of: overlay: user space synchronization

On Mon, 15 Oct 2018 17:27:01 -0700, frowand.l...@gmail.com said: > From: Frank Rowand > > When an overlay is applied or removed, the live devicetree visible in > /proc/device-tree/, aka /sys/firmware/devicetree/base/, reflects the > changes. There is no method for user space to determine whether

Re: [PATCH v2] of: overlay: user space synchronization

On Mon, 15 Oct 2018 17:27:01 -0700, frowand.l...@gmail.com said: > From: Frank Rowand > > When an overlay is applied or removed, the live devicetree visible in > /proc/device-tree/, aka /sys/firmware/devicetree/base/, reflects the > changes. There is no method for user space to determine whether

Re: [PATCH] kernel/signal: Signal-based pre-coredump notification

On Mon, 15 Oct 2018 18:28:03 -0500, Eric W. Biederman said: > Enke Chen writes: > > > For simplicity and consistency, this patch provides an implementation > > for signal-based fault notification prior to the coredump of a child > > process. A new prctl command, PR_SET_PREDUMP_SIG, is defined

Re: [PATCH] kernel/signal: Signal-based pre-coredump notification

On Mon, 15 Oct 2018 18:28:03 -0500, Eric W. Biederman said: > Enke Chen writes: > > > For simplicity and consistency, this patch provides an implementation > > for signal-based fault notification prior to the coredump of a child > > process. A new prctl command, PR_SET_PREDUMP_SIG, is defined

[BUG] ext4 null pointer crash in linux-next

I'm seeing a fairly replicable crash/hang with a traceback implicating ext4 (or possibly the block layer). next-20180918 seemed stable, but next-20180926 and -next-20181005 have a habit of crashing while dnf is updating software (so far, I've hit it 6 times with identical tracebacks while

[BUG] ext4 null pointer crash in linux-next

I'm seeing a fairly replicable crash/hang with a traceback implicating ext4 (or possibly the block layer). next-20180918 seemed stable, but next-20180926 and -next-20181005 have a habit of crashing while dnf is updating software (so far, I've hit it 6 times with identical tracebacks while

Re: [PATCH 11/11] ASoC: wm8994: Mark expected switch fall-through

On Fri, 03 Aug 2018 11:56:12 -0500, "Gustavo A. R. Silva" said: > On 08/03/2018 11:45 AM, Mark Brown wrote: > > Basically nobody ever uses OPCLK so I'd be susprised if anyone ever > > noticed. I wonder if nobody uses it because any attempts to do so get an error? :) > I see. I wonder what's the

Re: [PATCH 11/11] ASoC: wm8994: Mark expected switch fall-through

On Fri, 03 Aug 2018 11:56:12 -0500, "Gustavo A. R. Silva" said: > On 08/03/2018 11:45 AM, Mark Brown wrote: > > Basically nobody ever uses OPCLK so I'd be susprised if anyone ever > > noticed. I wonder if nobody uses it because any attempts to do so get an error? :) > I see. I wonder what's the

Re: [PATCH 11/11] ASoC: wm8994: Mark expected switch fall-through

On Wed, 01 Aug 2018 14:56:16 -0500, "Gustavo A. R. Silva" said: > diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c > index 7fdfdf3..62f8c5b 100644 > --- a/sound/soc/codecs/wm8994.c > +++ b/sound/soc/codecs/wm8994.c > @@ -2432,6 +2432,7 @@ static int wm8994_set_dai_sysclk(struct

Re: [PATCH 11/11] ASoC: wm8994: Mark expected switch fall-through

On Wed, 01 Aug 2018 14:56:16 -0500, "Gustavo A. R. Silva" said: > diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c > index 7fdfdf3..62f8c5b 100644 > --- a/sound/soc/codecs/wm8994.c > +++ b/sound/soc/codecs/wm8994.c > @@ -2432,6 +2432,7 @@ static int wm8994_set_dai_sysclk(struct

Re: [PATCH] radix-tree: avoid NULL dereference

On Fri, 06 Jul 2018 14:41:44 +0100, Mark Rutland said: > I beleive this is what Valdis hit [1] back in March. I spotted this while > booting an arm64 machine. Yes, the stack trace is the same. The odd part is that I was consistently seeing it until next-20180626, but it evaporated in sometime

Re: [PATCH] radix-tree: avoid NULL dereference

On Fri, 06 Jul 2018 14:41:44 +0100, Mark Rutland said: > I beleive this is what Valdis hit [1] back in March. I spotted this while > booting an arm64 machine. Yes, the stack trace is the same. The odd part is that I was consistently seeing it until next-20180626, but it evaporated in sometime

Re: [PATCH v2 1/4] vt: preserve unicode values corresponding to screen characters

On Sun, 17 Jun 2018 19:17:51 -0400, Nicolas Pitre said: > On Sun, 17 Jun 2018, valdis.kletni...@vt.edu wrote: > > This preprocessor variable seems to be dangling in the breeze, with > > no way for it to get set? As a result, we pick up the #else define by > > default. > > That's actually what's

Re: [PATCH v2 1/4] vt: preserve unicode values corresponding to screen characters

On Sun, 17 Jun 2018 19:17:51 -0400, Nicolas Pitre said: > On Sun, 17 Jun 2018, valdis.kletni...@vt.edu wrote: > > This preprocessor variable seems to be dangling in the breeze, with > > no way for it to get set? As a result, we pick up the #else define by > > default. > > That's actually what's

Re: wmi: usercopy: Kernel memory overwrite attempt detected to spans multiple pages (offset 0, size 4104)

On Sun, 17 Jun 2018 22:30:27 +0300, Mihai Donțu said: > Your patch works OK for me, thank you. The libsmbios tool, however, not > so much. It appears to be behind latest developments. > > # echo "+keyboard" >/sys/class/leds/dell\:\:kbd_backlight/start_triggers > > is all that is needed today.

Re: wmi: usercopy: Kernel memory overwrite attempt detected to spans multiple pages (offset 0, size 4104)

On Sun, 17 Jun 2018 22:30:27 +0300, Mihai Donțu said: > Your patch works OK for me, thank you. The libsmbios tool, however, not > so much. It appears to be behind latest developments. > > # echo "+keyboard" >/sys/class/leds/dell\:\:kbd_backlight/start_triggers > > is all that is needed today.

Re: [PATCH v2 1/4] vt: preserve unicode values corresponding to screen characters

On Sun, 17 Jun 2018 15:07:03 -0400, Nicolas Pitre said: > diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c > index 1eb1a376a0..7b636638b3 100644 > --- a/drivers/tty/vt/vt.c > +++ b/drivers/tty/vt/vt.c > @@ -317,6 +317,171 @@ void schedule_console_callback(void) > schedule_work(_work);

Re: [PATCH v2 1/4] vt: preserve unicode values corresponding to screen characters

On Sun, 17 Jun 2018 15:07:03 -0400, Nicolas Pitre said: > diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c > index 1eb1a376a0..7b636638b3 100644 > --- a/drivers/tty/vt/vt.c > +++ b/drivers/tty/vt/vt.c > @@ -317,6 +317,171 @@ void schedule_console_callback(void) > schedule_work(_work);

Re: [PATCH] staging: rtl8192u: fix line over 80 characters

On Sat, 16 Jun 2018 15:00:31 +0900, Hyunil Kim said: > *fix checkpatch.pl warnings: > WARNING: line over 80 characters > + if (((ieee->wpa_ie[0] == 0xdd) && > + (!memcmp(&(ieee->wpa_ie[14]), ccmp_ie, 4))) || > + ((ieee->wpa_ie[0] == 0x30) && > +

Re: [PATCH] staging: rtl8192u: fix line over 80 characters

On Sat, 16 Jun 2018 15:00:31 +0900, Hyunil Kim said: > *fix checkpatch.pl warnings: > WARNING: line over 80 characters > + if (((ieee->wpa_ie[0] == 0xdd) && > + (!memcmp(&(ieee->wpa_ie[14]), ccmp_ie, 4))) || > + ((ieee->wpa_ie[0] == 0x30) && > +

Re: [PATCH v2 6/7] vmw_balloon: update copyright message

On Thu, 14 Jun 2018 05:33:46 -, Nadav Amit said: > >> In addition, updating the year and adding a license tag. > >> +// SPDX-License-Identifier: GPL-2.0 > > You still have a lot of boiler-plate text in here that can be removed. > > Please do so. > But what else do you want me to remove?

Re: [PATCH v2 6/7] vmw_balloon: update copyright message

On Thu, 14 Jun 2018 05:33:46 -, Nadav Amit said: > >> In addition, updating the year and adding a license tag. > >> +// SPDX-License-Identifier: GPL-2.0 > > You still have a lot of boiler-plate text in here that can be removed. > > Please do so. > But what else do you want me to remove?

Re: linux-next 20180515 - ACPI disabled..

On Wed, 16 May 2018 13:58:04 +0200, "Rafael J. Wysocki" said: > On Wednesday, May 16, 2018 12:25:30 AM CEST valdis.kletni...@vt.edu wrote: > > On Tue, 15 May 2018 15:49:15 -0600, Al Stone said: > > > > > Not off-hand. Could you please send me a copy of > > > /sys/firmware/acpi/tables/APIC >

Re: linux-next 20180515 - ACPI disabled..

On Wed, 16 May 2018 13:58:04 +0200, "Rafael J. Wysocki" said: > On Wednesday, May 16, 2018 12:25:30 AM CEST valdis.kletni...@vt.edu wrote: > > On Tue, 15 May 2018 15:49:15 -0600, Al Stone said: > > > > > Not off-hand. Could you please send me a copy of > > > /sys/firmware/acpi/tables/APIC >

Re: linux-next 20180515 - ACPI disabled..

On Tue, 15 May 2018 15:49:15 -0600, Al Stone said: > Not off-hand. Could you please send me a copy of > /sys/firmware/acpi/tables/APIC cat /sys/firmware/acpi/tables/APIC | od -x 000 5041 4349 0072 3903 4544 4c4c 2020 020 4243 3358 2020 0020 2009 0107 4d41 2049 040 0013 0001

Re: linux-next 20180515 - ACPI disabled..

On Tue, 15 May 2018 15:49:15 -0600, Al Stone said: > Not off-hand. Could you please send me a copy of > /sys/firmware/acpi/tables/APIC cat /sys/firmware/acpi/tables/APIC | od -x 000 5041 4349 0072 3903 4544 4c4c 2020 020 4243 3358 2020 0020 2009 0107 4d41 2049 040 0013 0001

linux-next 20180515 - ACPI disabled..

Seeing this at boot with linux-next 20180415. ACPI gets disabled, hilarity and hijinks result - everything from a lot of stuff can't find an IRQ to the dual-core w/ HT CPU coming up as just 1 core no HT. 20180430 works just fine... [0.00] ACPI: Early table checksum verification

linux-next 20180515 - ACPI disabled..

Seeing this at boot with linux-next 20180415. ACPI gets disabled, hilarity and hijinks result - everything from a lot of stuff can't find an IRQ to the dual-core w/ HT CPU coming up as just 1 core no HT. 20180430 works just fine... [0.00] ACPI: Early table checksum verification

Re: next-20180416 - warnings from 'make tools/perf'

On Mon, 23 Apr 2018 08:52:04 +0200, Ingo Molnar said: > The warnings are harmless, and they should be fixed in v4.17-rc2. Having been burnt all too many times over the past 4 decades by mismatched headers, I figured I should mention it... I see that in next-20180423 it's down to 2 warnings

Re: next-20180416 - warnings from 'make tools/perf'

On Mon, 23 Apr 2018 08:52:04 +0200, Ingo Molnar said: > The warnings are harmless, and they should be fixed in v4.17-rc2. Having been burnt all too many times over the past 4 decades by mismatched headers, I figured I should mention it... I see that in next-20180423 it's down to 2 warnings

next-20180416 - warnings from 'make tools/perf'

Seeing these warnings. 'diff' tells me that the files are in fact significantly different. Warning: Kernel ABI header at 'tools/include/uapi/linux/kvm.h' differs from latest version at 'include/uapi/linux/kvm.h' Warning: Kernel ABI header at 'tools/include/uapi/linux/prctl.h' differs from

next-20180416 - warnings from 'make tools/perf'

Seeing these warnings. 'diff' tells me that the files are in fact significantly different. Warning: Kernel ABI header at 'tools/include/uapi/linux/kvm.h' differs from latest version at 'include/uapi/linux/kvm.h' Warning: Kernel ABI header at 'tools/include/uapi/linux/prctl.h' differs from

Re: Softlockup and Hardlockup sample test module

On Sun, 15 Apr 2018 13:17:27 +0530, Ivid Suvarna said: > I had tried with the module where I put a busy loop inside spinlock > but was not able to cause any lockups. Maybe this is because of SMP > which schedule the job to other CPU. "How do I make a task to run on > single CPU only?" So you get

Re: Softlockup and Hardlockup sample test module

On Sun, 15 Apr 2018 13:17:27 +0530, Ivid Suvarna said: > I had tried with the module where I put a busy loop inside spinlock > but was not able to cause any lockups. Maybe this is because of SMP > which schedule the job to other CPU. "How do I make a task to run on > single CPU only?" So you get

Re: linux-next 20180327 - "SELinux: (dev dm-3, type ext4) getxattr errno 34"

On Thu, 29 Mar 2018 21:32:21 -0400, "Theodore Y. Ts'o" said: > Yes, the breakage is my fault; my apologies. The new version of the > patch is already posted in bugzilla (and on linux-ext4). I'll be > pushing out a refreshed ext4.git branch shortly. Confirming that reverting

Re: linux-next 20180327 - "SELinux: (dev dm-3, type ext4) getxattr errno 34"

On Thu, 29 Mar 2018 21:32:21 -0400, "Theodore Y. Ts'o" said: > Yes, the breakage is my fault; my apologies. The new version of the > patch is already posted in bugzilla (and on linux-ext4). I'll be > pushing out a refreshed ext4.git branch shortly. Confirming that reverting

linux-next 20180327 - "SELinux: (dev dm-3, type ext4) getxattr errno 34"

Seeing this error trying to mount ext4 disks. next-20180320 was OK. SELinux: (dev dm-3, type ext4) getxattr errno 34 and for /var, it refused to mount entirely (which brought the boot process to a screeching halt). git log shows commits in the past few days against both selinux and ext4, but

linux-next 20180327 - "SELinux: (dev dm-3, type ext4) getxattr errno 34"

Seeing this error trying to mount ext4 disks. next-20180320 was OK. SELinux: (dev dm-3, type ext4) getxattr errno 34 and for /var, it refused to mount entirely (which brought the boot process to a screeching halt). git log shows commits in the past few days against both selinux and ext4, but

Re: linux-next 20180320 compile failure - tools/lib/str_error_r.c

On Wed, 21 Mar 2018 10:29:38 -0300, Arnaldo Carvalho de Melo said: > Em Tue, Mar 20, 2018 at 12:43:32PM -0400, valdis.kletni...@vt.edu escreveu: > > next-20180320 with "gcc (GCC) 8.0.1 20180317 (Red Hat 8.0.1-0.19)" dies a > > horrid death early > > during the compile: > > > > CC

Re: linux-next 20180320 compile failure - tools/lib/str_error_r.c

On Wed, 21 Mar 2018 10:29:38 -0300, Arnaldo Carvalho de Melo said: > Em Tue, Mar 20, 2018 at 12:43:32PM -0400, valdis.kletni...@vt.edu escreveu: > > next-20180320 with "gcc (GCC) 8.0.1 20180317 (Red Hat 8.0.1-0.19)" dies a > > horrid death early > > during the compile: > > > > CC

Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns

On Tue, 20 Mar 2018 18:39:47 +0200, Liran Alon said: > What is your opinion in regards if it's OK to put the flag enabling this > "fix" in /proc/sys/net/core? Do you think it's sufficient? Umm.. *which* /proc/sys/net/core? These could differ for things that are in different namespaces. Or are

Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns

On Tue, 20 Mar 2018 18:39:47 +0200, Liran Alon said: > What is your opinion in regards if it's OK to put the flag enabling this > "fix" in /proc/sys/net/core? Do you think it's sufficient? Umm.. *which* /proc/sys/net/core? These could differ for things that are in different namespaces. Or are

linux-next 20180320 compile failure - tools/lib/str_error_r.c

Not sure who to blame here, or what changed in gcc between 0.16 and 0.19, or what the proper fix is here next-20180307 with "gcc version 8.0.1 20180222 (Red Hat 8.0.1-0.16)" built and runs fine. next-20180320 with "gcc (GCC) 8.0.1 20180317 (Red Hat 8.0.1-0.19)" dies a horrid death early

linux-next 20180320 compile failure - tools/lib/str_error_r.c

Not sure who to blame here, or what changed in gcc between 0.16 and 0.19, or what the proper fix is here next-20180307 with "gcc version 8.0.1 20180222 (Red Hat 8.0.1-0.16)" built and runs fine. next-20180320 with "gcc (GCC) 8.0.1 20180317 (Red Hat 8.0.1-0.19)" dies a horrid death early

Re: linux-next: ip6tables *broken* - last base chain position %u doesn't match underflow %u (hook %u

On Tue, 20 Mar 2018 16:48:42 +0100, Florian Westphal said: > valdis.kletni...@vt.edu wrote: > > (Resending because I haven't heard anything) > [ ip6tables broken ] > > Sorry, did not see this email before. > > I'll investigate asap, thanks for the detailed report. No

Re: linux-next: ip6tables *broken* - last base chain position %u doesn't match underflow %u (hook %u

On Tue, 20 Mar 2018 16:48:42 +0100, Florian Westphal said: > valdis.kletni...@vt.edu wrote: > > (Resending because I haven't heard anything) > [ ip6tables broken ] > > Sorry, did not see this email before. > > I'll investigate asap, thanks for the detailed report. No problem, it reverts cleanly

linux-next: ip6tables *broken* - last base chain position %u doesn't match underflow %u (hook %u

(Resending because I haven't heard anything) Am hitting an issue with this commit: commit 0d7df906a0e78079a02108b06d32c3ef2238ad25 Author: Florian Westphal Date: Tue Feb 27 19:42:37 2018 +0100 netfilter: x_tables: ensure last rule in base chain matches underflow/policy

linux-next: ip6tables *broken* - last base chain position %u doesn't match underflow %u (hook %u

(Resending because I haven't heard anything) Am hitting an issue with this commit: commit 0d7df906a0e78079a02108b06d32c3ef2238ad25 Author: Florian Westphal Date: Tue Feb 27 19:42:37 2018 +0100 netfilter: x_tables: ensure last rule in base chain matches underflow/policy This trips on my

linux-next 20180307 - UBSAN whine in lib/radix-tree.c

Seen in the dmesg: [0.00] [0.00] UBSAN: Undefined behaviour in lib/radix-tree.c:123:14 [0.00] member access within null pointer of type 'const struct radix_tree_node' [0.00] CPU: 0

linux-next 20180307 - UBSAN whine in lib/radix-tree.c

Seen in the dmesg: [0.00] [0.00] UBSAN: Undefined behaviour in lib/radix-tree.c:123:14 [0.00] member access within null pointer of type 'const struct radix_tree_node' [0.00] CPU: 0

Re: [PATCH] scsi: eata: drop VLA in reorder()

On Mon, 12 Mar 2018 14:08:34 +1100, "Tobin C. Harding" said: > removal patch that 768 was a lot of stack space. That comment did, > however say 'deep in some transfer call chain'. I don't know what a > 'transfer call chain' (the transfer bit) is but is there some heuristic > we can use to know

Re: [PATCH] scsi: eata: drop VLA in reorder()

On Mon, 12 Mar 2018 14:08:34 +1100, "Tobin C. Harding" said: > removal patch that 768 was a lot of stack space. That comment did, > however say 'deep in some transfer call chain'. I don't know what a > 'transfer call chain' (the transfer bit) is but is there some heuristic > we can use to know

ip6tables - last base chain position %u doesn't match underflow %u (hook %u

Am hitting an issue with this commit: commit 0d7df906a0e78079a02108b06d32c3ef2238ad25 Author: Florian Westphal Date: Tue Feb 27 19:42:37 2018 +0100 netfilter: x_tables: ensure last rule in base chain matches underflow/policy This trips on my system: [ 64.402790]

ip6tables - last base chain position %u doesn't match underflow %u (hook %u

Am hitting an issue with this commit: commit 0d7df906a0e78079a02108b06d32c3ef2238ad25 Author: Florian Westphal Date: Tue Feb 27 19:42:37 2018 +0100 netfilter: x_tables: ensure last rule in base chain matches underflow/policy This trips on my system: [ 64.402790] ip6_tables: last

Re: [PATCH 2/2] x86/speculation: Support "Enhanced IBRS" on future CPUs

On Mon, 19 Feb 2018 23:42:24 +, "Van De Ven, Arjan" said: > the guest is not the problem; guests obviously will already honor if Enhanced > IBRS is enumerated. The problem is mixed migration pools where the hypervisor > may need to decide to not pass this enumeration through to the guest.

Re: [PATCH 2/2] x86/speculation: Support "Enhanced IBRS" on future CPUs

On Mon, 19 Feb 2018 23:42:24 +, "Van De Ven, Arjan" said: > the guest is not the problem; guests obviously will already honor if Enhanced > IBRS is enumerated. The problem is mixed migration pools where the hypervisor > may need to decide to not pass this enumeration through to the guest.

Re: [PATCH v1 2/2] PCI: Allow user to request power management of conventional and hotplug bridges

On Mon, 19 Feb 2018 17:14:06 -0600, Bjorn Helgaas said: > Change "pcie_port_pm=force" to enable power management of conventional PCI > bridges and hotplug bridges as well as PCIe ports. As with the previous > PCIe port-only behavior, this is not expected to work in all systems. This part says

Re: [PATCH v1 2/2] PCI: Allow user to request power management of conventional and hotplug bridges

On Mon, 19 Feb 2018 17:14:06 -0600, Bjorn Helgaas said: > Change "pcie_port_pm=force" to enable power management of conventional PCI > bridges and hotplug bridges as well as PCIe ports. As with the previous > PCIe port-only behavior, this is not expected to work in all systems. This part says

Re: [RFC] Warn the user when they could overflow mapcount

On Thu, 08 Feb 2018 03:56:26 +0100, Jann Horn said: > I wouldn't be too surprised if there are more 32-bit overflows that > start being realistic once you put something on the order of terabytes > of memory into one machine, given that refcount_t is 32 bits wide - > for example, the i_count. See

  1   2   3   4   5   6   7   8   9   10   >