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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 s
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:
> htt
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
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 pa
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 y
. Let's provide 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)
cribed in '__cgroup_bpf_detach'
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/linu
__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
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 @@
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.
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 compa
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
> >
tl_hung_task_panic' was not
declared. Should 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
s, because we *know* we're overwriting
the default 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
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 do
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:
https://lists.kernelnewbies.org/pipermail/kernelne
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->dev, "iio:device%d", dev->id);
> INIT_LIST_HEAD(&dev->buffer_list);
> +
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
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: 30200
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 arr
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 ti
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 mmap
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
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
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 that
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 attemptin
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 b
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 s
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 be
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 i
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.
If
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(&console
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) &&
> +
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? Thi
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
> The
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 000
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 disabled
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 (prct
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
lates
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
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 de57a63ea4389e39b1cd
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 not
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 /usr/sr
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 yo
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
du
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 a
(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 s
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 PI
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 h
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 ba
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.
For
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 th
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
>
GCC requires another #include to get the gcc-plugins to build cleanly.
Signed-off-by: Valdis Kletnieks
diff --git a/scripts/gcc-plugins/gcc-common.h b/scripts/gcc-plugins/gcc-common.h
index ffd1dfaa1cc1..f46750053377 100644
--- a/scripts/gcc-plugins/gcc-common.h
+++ b/scripts/gcc-plugins/gcc
ef-ery won't be needed. Do we know any gcc experts to ask?
Signed-off-by: Valdis Kletnieks
--- diff --git a/scripts/gcc-plugins/latent_entropy_plugin.c
b/scripts/gcc-plugins/latent_entropy_plugin.c
index 65264960910d..15a6df3592c5 100644
--- a/scripts/gcc-plugins/latent_entropy
On Tue, 23 Jan 2018 18:07:25 +0530, Pintu Kumar said:
> My uname says:
> 4.9--amd-x86-64
Literally 4.9-? No 3rd number? And why ''? (Hint - obfuscating doesn't
help here, it's hard to debug when we don't see the *actual* string.)
Some unames from my various machines:
4.15.0-rc7-nex
On Wed, 15 Nov 2017 14:21:13 -0600, Mario Limonciello said:
> On machines using rfkill interface the buffer needs to have been
> allocated before the initial use (memset) of it.
>
> Reported-by: Valdis Kletnieks
> Signed-off-by: Mario Limonciello
> ---
> drivers/platform/
Seen at boot. Dell Latitude E6530, A20 bios.
Only obvious commit in 'git log' is:
commit 549b4930f057658dc50d8010e66219233119a4d8
Author: Mario Limonciello
Date: Wed Nov 1 14:25:31 2017 -0500
platform/x86: dell-smbios: Introduce dispatcher for SMM calls
Looks like it managed to get to d
strings not supported
Signed-off-by: Valdis Kletnieks
---
diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index eb4101aee787..b44ab176418e 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -32,7 +32,7 @@ config BT_HCIBTUSB
kernel or say M to
I've hit this 6 times now, across 3 boots:
Nov 3 11:04:54 turing-police kernel: [ 547.814748] BUG: sleeping function
called from invalid context at mm/slab.h:422
Nov 3 20:24:11 turing-police kernel: [ 60.093793] BUG: sleeping function
called from invalid context at mm/slab.h:422
Nov 4 20:
On Mon, 02 Oct 2017 10:11:34 +0200, Kamil Konieczny said:
> What about /usr/bin/ssh as init replacement ?
Well, if you are OK with your system panicking right away. :)
(Hint - the init process needs to be something that can run as a daemon).
If you use /usr/sbin/sshd, that has a *slightly* bett
On Fri, 29 Sep 2017 19:56:41 +0530, Pintu Kumar said:
> 1) If you have pointers on how to setup ssh/net connection on QEMU
> with busybox, do let me know.
Busybox doesn't do that as far as I know, as it's intended as a single-user
/sbin/init replacement. You'll need a full-featured userspace with
On Fri, 29 Sep 2017 16:08:07 +0530, Pintu Kumar said:
> I have a general question.
> How do we normally verify linux-next tree?
The same exact way you "verify" any other Linux kernel, for whatever
definition of "verify" you plan to use.
> 1) For Oracle virtual box 5.1.26 with ubuntu-32 bit, the
On Thu, 10 Aug 2017 17:42:51 +0200, Thomas Meyer said:
> 1.) make with multiple targets
>
> When running
> $ make -j4 clean all
> I get error from make (probably in scripts/Makefile.modbuiltin):
> Output from above with V=1:
Possibly unrelated, but I suspect there's a bunch of weirdness lurking i
;mm, gup: ensure real head page is ref-counted when
> using hugepages". We should look for a head *before* the loop. Otherwise
> 'page' may point to the first page beyond the compound page.
>
> The patch below should help.
Confirmed that fixes the BUGs that I was hitting.
Tested-By: Valdis Kletnieks
pgps_LhDroUqh.pgp
Description: PGP signature
Saw this at boot of next-20170620. Not sure how I managed to hit 4 BUG in a
row...
Looked in 'git log -- mm/' but not seeing anything blatantly obvious.
This ringing any bells? I'm not in a position to recreate or bisect this until
the weekend.
[ 315.409076] BUG: Bad rss-counter state mm:fff
Pretty drastic. Hit ^S to pause scrolling, and instantly hung terminal.
Seen on both urxvt and xterm under x11, and on virtual console screens.
This appears in dmesg:
[ 1844.182058] INFO: task kworker/u8:3:129 blocked for more than 120 seconds.
[ 1844.182073] Tainted: G OE 4.
Seeing problems with programs that use semaphores. The one
that I'm getting bit by is jackd. strace says:
getuid()= 967
semget(0x282929, 0, 000)= 229376
semop(229376, [{0, -1, SEM_UNDO}], 1) = -1 EIDRM (Identifier removed)
write(2, "JACK semaphor
Seen in next-20170207:
[/usr/src/linux-next] gcc --version
gcc (GCC) 7.0.1 20170204 (Red Hat 7.0.1-0.6)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PU
On Fri, 03 Feb 2017 13:42:46 -0500, Waiman Long said:
> This patch set does guarantee some minimum performance level, but it
> can't guarantee fairness for all the lock waiters.
OK, sounds like it's a situation that's statistically unlikely, but it has
protections against starvation so the system
On Fri, 03 Feb 2017 13:03:50 -0500, Waiman Long said:
> On a 2-socket 36-core E5-2699 v3 system (HT off) running on a 4.10
> WW futex TP futex Glibc
> -
> Total locking ops35,707,234
Booted next-20170130 with a flash memory card forgotten in the reader slot,
and it produced a truly impressive amount of splattage - managing to trigger
both a BUG for sleeping in an invalid context *and* a lockdep whinge. I can't
tell if it's 2 mmc bugs, or if lockdep got confused due to the BUG
linux-next 20170110 didn't exhibit this.
Am seeing at boot a lockdep whine, followed by 3 BUGs. ata_scsi_rbuf_fill() is
in the traceback for all of them.'git log' hints that it's one of 6 commits
against drivers/ata/libata-scsi.c by Christoph, but none of them spring out
as being the guilty pa
On Tue, 03 Jan 2017 11:55:36 -0800, Jessica Yu said:
> Hm, you and Larry Finger sent the exact same fix at around the same
> time, although I think people are leaning towards the other patch
> (it's just a naming preference), see here:
>
>https://lkml.kernel.org/r/20161224195532.15128-1-larry.
On Mon, 26 Dec 2016 20:34:17 +0800, yi zhang said:
> Because of the disk and hardware issue, the ext4 filesystem have
> many errors, the inode->i_nlink of ext4 becomes zero abnormally
> but the dentry is still positive, it will cause memory corruption
> after the following process:
>
> 1) Due to t
On Thu, 29 Dec 2016 17:25:59 +0800, Liang Li said:
> x86-64 is currently limited physical address width to 46 bits, which
> can support 64 TiB of memory. Some vendors require to support more for
> some use case. Intel plans to extend the physical address width to
> 52 bits in some of the future pro
On Wed, 28 Dec 2016 15:03:02 +0100, Wolfram Sang said:
> > I have absolutely no idea how to you want to achieve calling that
> > i2c_new_device() registration
> > without kernel patches.
>
> Documentation/i2c/instantiating-devices lists all supported methods.
> Method 4 is userspace instantiation.
On Wed, 28 Dec 2016 00:15:30 +0200, Andy Shevchenko said:
> On Tue, Dec 27, 2016 at 3:51 PM, Pali Rohár wrote:
> > I have no idea how to do it (properly) outside of i2c-i801.c file.
>
> I doubt we need a single line of code for this. See [1] and perhaps
> create an EFI variable with necessary upg
/* also show as a per-module taint flag */
+};
and hilarity ensues when an out-of-tree module has this:
# ifndef true
# define true (1)
# endif
# ifndef false
# define false (0)
# endif
Change the field names to not shadow something likely to be used
by third-party modules.
Signed-off-
On Fri, 23 Dec 2016 12:59:35 +0100, Petr Mladek said:
> On Thu 2016-12-22 13:56:38, Valdis Kletnieks wrote:
> > commit 7fd8329ba502ef76dd91db561c7aed696b2c7720
> > Author: Petr Mladek
> > Date: Wed Sep 21 13:47:22 2016 +0200
> >
> > taint/module: Clean
the field names to not shadow something likely to be used
by third-party modules.
Signed-off-by: Valdis Kletnieks
---
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 56aec84237ad..420d4b87feb0 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -514,8 +514,8
Yes, I know that usually out-of-tree modules are on their own.
However, this one may require a rethink..
(Sorry for not catching this sooner, I hadn't tried to deal with the
affected module since this patch hit linux-next in next-20161128)
commit 7fd8329ba502ef76dd91db561c7aed696b2c7720
Author: P
May or may not be related to the BUG I just reported - the first hit
on that one was right after this in the log
[2.740391] ===
[2.740433] suspicious RCU usage. ]
[2.740463] 4.9.0-rc7-next-20161129-dirty #361 Not tainted
[2.740464] --
Seeing this same BUG all over the place at boot - some 30 times just getting
to a single-user prompt and saving a dmesg. Everything from netlink to execve
to ext4 file I/O to process exit time.
[3.746004] BUG: sleeping function called from invalid context at
mm/page_alloc.c:3775
[3.74609
1 - 100 of 1041 matches
Mail list logo
