Re: [PATCH] libertas: Avoid reading past end of buffer

On Wed, 2017-05-10 at 12:24 -0700, Kees Cook wrote: > Using memcpy() from a string that is shorter than the length copied means [] > diff --git a/drivers/net/wireless/marvell/libertas/mesh.c > b/drivers/net/wireless/marvell/libertas/mesh.c [] > @@ -1170,17 +1170,11 @@ int

Re: [PATCH] libertas: Avoid reading past end of buffer

On Wed, 2017-05-10 at 12:24 -0700, Kees Cook wrote: > Using memcpy() from a string that is shorter than the length copied means [] > diff --git a/drivers/net/wireless/marvell/libertas/mesh.c > b/drivers/net/wireless/marvell/libertas/mesh.c [] > @@ -1170,17 +1170,11 @@ int

[RFC] adding of TGID to ftrace output

Hi Steven, Can we add TGID information along with PID to ftrace output? Something like: # _-=> irqs-off # / _=> need-resched # | / _---=> hardirq/softirq #

[RFC] adding of TGID to ftrace output

Hi Steven, Can we add TGID information along with PID to ftrace output? Something like: # _-=> irqs-off # / _=> need-resched # | / _---=> hardirq/softirq #

[PATCH v2] mm: vmscan: scan until it founds eligible pages

Although there are a ton of free swap and anonymous LRU page in elgible zones, OOM happened. balloon invoked oom-killer: gfp_mask=0x17080c0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOTRACK), nodemask=(null), order=0, oom_score_adj=0 CPU: 7 PID: 1138 Comm: balloon Not tainted

[PATCH v2] mm: vmscan: scan until it founds eligible pages

Although there are a ton of free swap and anonymous LRU page in elgible zones, OOM happened. balloon invoked oom-killer: gfp_mask=0x17080c0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOTRACK), nodemask=(null), order=0, oom_score_adj=0 CPU: 7 PID: 1138 Comm: balloon Not tainted

Is there an recommended way to refer to bitkeepr commits?

(Apologies resent as I forgot to include linux-kernel when I sent this the first time) I am in the process of digging through the intersection of threads, signals, ptrace, and exec and I am encountering bugs that predate 2.6.12-rc2 the first version in our current git tree. I am trying to

Is there an recommended way to refer to bitkeepr commits?

(Apologies resent as I forgot to include linux-kernel when I sent this the first time) I am in the process of digging through the intersection of threads, signals, ptrace, and exec and I am encountering bugs that predate 2.6.12-rc2 the first version in our current git tree. I am trying to

Re: [RFC GIT PULL, v2] RCU changes for v4.12

On Wed, May 10, 2017 at 02:08:55PM -0700, Linus Torvalds wrote: > On Wed, May 10, 2017 at 1:51 PM, Paul E. McKenney > wrote: > > On Wed, May 10, 2017 at 01:17:54PM -0700, Linus Torvalds wrote: > >> > >> It kind of implies that the prep work that linux-next does doesn't

Re: [RFC GIT PULL, v2] RCU changes for v4.12

On Wed, May 10, 2017 at 02:08:55PM -0700, Linus Torvalds wrote: > On Wed, May 10, 2017 at 1:51 PM, Paul E. McKenney > wrote: > > On Wed, May 10, 2017 at 01:17:54PM -0700, Linus Torvalds wrote: > >> > >> It kind of implies that the prep work that linux-next does doesn't get > >> fully used. > > >

[PATCH] x86/efi: Add EFI_PGT_DUMP support for x86_32, kexec and efi=old_map

From: Sai Praneeth EFI_PGT_DUMP, as the name suggests dumps efi page tables to dmesg during kernel boot. This feature is very useful while debugging page faults/null pointer dereferences to efi related addresses. Presently, this feature is limited only to x86_64,

[PATCH] x86/efi: Add EFI_PGT_DUMP support for x86_32, kexec and efi=old_map

From: Sai Praneeth EFI_PGT_DUMP, as the name suggests dumps efi page tables to dmesg during kernel boot. This feature is very useful while debugging page faults/null pointer dereferences to efi related addresses. Presently, this feature is limited only to x86_64, so let's extend it to other efi

Re: WMI and Kernel:User interface

On Wed, May 10, 2017 at 3:02 PM, wrote: > So here's a "more" realistic scenario: > > OEM has support through a WMI function to control keyboard backlight timeouts > and intensity. That same WMI function also can support turning on/off an > individual > USB port.

Re: WMI and Kernel:User interface

On Wed, May 10, 2017 at 3:02 PM, wrote: > So here's a "more" realistic scenario: > > OEM has support through a WMI function to control keyboard backlight timeouts > and intensity. That same WMI function also can support turning on/off an > individual > USB port. Backlight timeouts are done by

Re: [PATCH v2 1/5] pinctrl: qcom: Add ipq8074 pinctrl driver

On Thu 04 May 04:53 PDT 2017, Varadarajan Narayanan wrote: > Add initial pinctrl driver to support pin configuration with > pinctrl framework for ipq8074. > > Signed-off-by: Manoharan Vijaya Raghavan > Signed-off-by: Varadarajan Narayanan > --- >

Re: [PATCH v2 1/5] pinctrl: qcom: Add ipq8074 pinctrl driver

On Thu 04 May 04:53 PDT 2017, Varadarajan Narayanan wrote: > Add initial pinctrl driver to support pin configuration with > pinctrl framework for ipq8074. > > Signed-off-by: Manoharan Vijaya Raghavan > Signed-off-by: Varadarajan Narayanan > --- > .../bindings/pinctrl/qcom,ipq8074-pinctrl.txt

Re: [RFC 09/10] x86/mm: Rework lazy TLB to track the actual loaded mm

On Wed, May 10, 2017 at 1:24 AM, Ingo Molnar wrote: > > * Thomas Gleixner wrote: > >> On Wed, 10 May 2017, Ingo Molnar wrote: >> > >> > * Thomas Gleixner wrote: >> > >> > > On Sun, 7 May 2017, Andy Lutomirski wrote: >> > > > /*

Re: [RFC 09/10] x86/mm: Rework lazy TLB to track the actual loaded mm

On Wed, May 10, 2017 at 1:24 AM, Ingo Molnar wrote: > > * Thomas Gleixner wrote: > >> On Wed, 10 May 2017, Ingo Molnar wrote: >> > >> > * Thomas Gleixner wrote: >> > >> > > On Sun, 7 May 2017, Andy Lutomirski wrote: >> > > > /* context.lock is held for us, so we don't need any locking. */ >> >

Lockdep splat involving all_q_mutex

Hello! I got the lockdep splat shown below during some rcutorture testing (which does CPU hotplug operations) on mainline at commit dc9edaab90de ("Merge tag 'acpi-extra-4.12-rc1' of git://git.kernel.org/.../rafael/linux-pm"). My kneejerk reaction was just to reverse the "mutex_lock(_q_mutex);"

Lockdep splat involving all_q_mutex

Hello! I got the lockdep splat shown below during some rcutorture testing (which does CPU hotplug operations) on mainline at commit dc9edaab90de ("Merge tag 'acpi-extra-4.12-rc1' of git://git.kernel.org/.../rafael/linux-pm"). My kneejerk reaction was just to reverse the "mutex_lock(_q_mutex);"

Re: [PATCH 1/3] s390/dasd: Adjust buffer output in dasd_hosts_print()

Hi Markus, [auto build test WARNING on s390/features] [also build test WARNING on v4.11 next-20170510] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/SF-Markus-Elfring/S390-DASD-Fine-tuning

Re: [PATCH 1/3] s390/dasd: Adjust buffer output in dasd_hosts_print()

Hi Markus, [auto build test WARNING on s390/features] [also build test WARNING on v4.11 next-20170510] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/SF-Markus-Elfring/S390-DASD-Fine-tuning

Re: [PATCH v3] LSM: Enable multiple calls to security_add_hooks() for the same LSM

On 5/10/2017 1:48 PM, Mickaël Salaün wrote: > The commit d69dece5f5b6 ("LSM: Add /sys/kernel/security/lsm") extend > security_add_hooks() with a new parameter to register the LSM name, > which may be useful to make the list of currently loaded LSM available > to userspace. However, there is no

Re: [PATCH v3] LSM: Enable multiple calls to security_add_hooks() for the same LSM

On 5/10/2017 1:48 PM, Mickaël Salaün wrote: > The commit d69dece5f5b6 ("LSM: Add /sys/kernel/security/lsm") extend > security_add_hooks() with a new parameter to register the LSM name, > which may be useful to make the list of currently loaded LSM available > to userspace. However, there is no

Re: WMI and Kernel:User interface

On Wed, May 10, 2017 at 10:02:46PM +, mario.limoncie...@dell.com wrote: > > -Original Message- > > From: Darren Hart [mailto:dvh...@infradead.org] > > Sent: Wednesday, May 10, 2017 1:12 AM > > To: Greg Kroah-Hartman > > Cc: Linus Torvalds

Re: WMI and Kernel:User interface

On Wed, May 10, 2017 at 10:02:46PM +, mario.limoncie...@dell.com wrote: > > -Original Message- > > From: Darren Hart [mailto:dvh...@infradead.org] > > Sent: Wednesday, May 10, 2017 1:12 AM > > To: Greg Kroah-Hartman > > Cc: Linus Torvalds ; Limonciello, Mario > > ; Pali Rohár ; Andy >

RE: WMI and Kernel:User interface

> -Original Message- > From: Darren Hart [mailto:dvh...@infradead.org] > Sent: Wednesday, May 10, 2017 1:12 AM > To: Greg Kroah-Hartman > Cc: Linus Torvalds ; Limonciello, Mario > ; Pali Rohár

RE: WMI and Kernel:User interface

> -Original Message- > From: Darren Hart [mailto:dvh...@infradead.org] > Sent: Wednesday, May 10, 2017 1:12 AM > To: Greg Kroah-Hartman > Cc: Linus Torvalds ; Limonciello, Mario > ; Pali Rohár ; Andy > Shevchenko ; Rafael Wysocki > ; Andy Lutomirski ; LKML ker...@vger.kernel.org>;

Re: [PATCH 07/14] Implement fsopen() to prepare for a mount

On Wed, May 10, 2017 at 9:19 AM, David Howells wrote: > Provide an fsopen() system call that starts the process of preparing to > mount, using an fd as a context handle. fsopen() is given the name of the > filesystem that will be used: > > int mfd = fsopen(const char

Re: [PATCH 07/14] Implement fsopen() to prepare for a mount

On Wed, May 10, 2017 at 9:19 AM, David Howells wrote: > Provide an fsopen() system call that starts the process of preparing to > mount, using an fd as a context handle. fsopen() is given the name of the > filesystem that will be used: > > int mfd = fsopen(const char *fsname, int

Re: [PATCHv3 1/2] Input: pwm-vibra: new driver

On Mon, May 08, 2017 at 08:51:28PM +0200, Sebastian Reichel wrote: > On Sun, May 07, 2017 at 02:38:00PM -0700, Dmitry Torokhov wrote: > > > +static int __maybe_unused pwm_vibrator_suspend(struct device *dev) > > > +{ > > > + struct platform_device *pdev = to_platform_device(dev); > > > + struct

Re: [PATCHv3 1/2] Input: pwm-vibra: new driver

On Mon, May 08, 2017 at 08:51:28PM +0200, Sebastian Reichel wrote: > On Sun, May 07, 2017 at 02:38:00PM -0700, Dmitry Torokhov wrote: > > > +static int __maybe_unused pwm_vibrator_suspend(struct device *dev) > > > +{ > > > + struct platform_device *pdev = to_platform_device(dev); > > > + struct

[patch] mm, thp: copying user pages must schedule on collapse

We have encountered need_resched warnings in __collapse_huge_page_copy() while doing {clear,copy}_user_highpage() over HPAGE_PMD_NR source pages. mm->mmap_sem is held for write, but the iteration is well bounded. Reschedule as needed. Signed-off-by: David Rientjes ---

[patch] mm, thp: copying user pages must schedule on collapse

We have encountered need_resched warnings in __collapse_huge_page_copy() while doing {clear,copy}_user_highpage() over HPAGE_PMD_NR source pages. mm->mmap_sem is held for write, but the iteration is well bounded. Reschedule as needed. Signed-off-by: David Rientjes --- mm/khugepaged.c | 7

Re: [RFC 09/10] ima: move to generic async completion

On Sat, 2017-05-06 at 15:59 +0300, Gilad Ben-Yossef wrote: > ima starts several async. crypto ops and waits for their completions. > Move it over to generic code doing the same. > > Signed-off-by: Gilad Ben-Yossef Acked-by: Mimi Zohar > --- >

Re: [RFC 09/10] ima: move to generic async completion

On Sat, 2017-05-06 at 15:59 +0300, Gilad Ben-Yossef wrote: > ima starts several async. crypto ops and waits for their completions. > Move it over to generic code doing the same. > > Signed-off-by: Gilad Ben-Yossef Acked-by: Mimi Zohar > --- > security/integrity/ima/ima_crypto.c | 56 >

[GIT PULL] RTC for 4.12

Hi Linus, Here is the pull-request for the RTC subsystem for 4.12. I had to generate a new GPG subkey so you may have to refresh my key before verifying the signature The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201: Linux 4.11-rc1 (2017-03-05 12:59:56 -0800) are

[GIT PULL] RTC for 4.12

Hi Linus, Here is the pull-request for the RTC subsystem for 4.12. I had to generate a new GPG subkey so you may have to refresh my key before verifying the signature The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201: Linux 4.11-rc1 (2017-03-05 12:59:56 -0800) are

Re: [PATCH v3] LSM: Enable multiple calls to security_add_hooks() for the same LSM

On Wed, May 10, 2017 at 1:48 PM, Mickaël Salaün wrote: > The commit d69dece5f5b6 ("LSM: Add /sys/kernel/security/lsm") extend > security_add_hooks() with a new parameter to register the LSM name, > which may be useful to make the list of currently loaded LSM available > to

Re: [PATCH v3] LSM: Enable multiple calls to security_add_hooks() for the same LSM

On Wed, May 10, 2017 at 1:48 PM, Mickaël Salaün wrote: > The commit d69dece5f5b6 ("LSM: Add /sys/kernel/security/lsm") extend > security_add_hooks() with a new parameter to register the LSM name, > which may be useful to make the list of currently loaded LSM available > to userspace. However,

Re: [v3 0/9] parallelized "struct page" zeroing

On Wed, May 10, 2017 at 02:00:26PM -0400, David Miller wrote: > From: Matthew Wilcox > Date: Wed, 10 May 2017 10:17:03 -0700 > > On Wed, May 10, 2017 at 11:19:43AM -0400, David Miller wrote: > >> I guess it might be clearer if you understand what the block > >> initializing

Re: [v3 0/9] parallelized "struct page" zeroing

On Wed, May 10, 2017 at 02:00:26PM -0400, David Miller wrote: > From: Matthew Wilcox > Date: Wed, 10 May 2017 10:17:03 -0700 > > On Wed, May 10, 2017 at 11:19:43AM -0400, David Miller wrote: > >> I guess it might be clearer if you understand what the block > >> initializing stores do on sparc64.

Re: [RFC GIT PULL, v2] RCU changes for v4.12

On Wed, May 10, 2017 at 1:51 PM, Paul E. McKenney wrote: > On Wed, May 10, 2017 at 01:17:54PM -0700, Linus Torvalds wrote: >> >> It kind of implies that the prep work that linux-next does doesn't get >> fully used. > > I did see that from linux-next. For future

Re: [RFC GIT PULL, v2] RCU changes for v4.12

On Wed, May 10, 2017 at 1:51 PM, Paul E. McKenney wrote: > On Wed, May 10, 2017 at 01:17:54PM -0700, Linus Torvalds wrote: >> >> It kind of implies that the prep work that linux-next does doesn't get >> fully used. > > I did see that from linux-next. For future reference, what should I > have

[PATCH] scsi: zero per-cmd driver data for each MQ I/O

From: Long Li Lower layer driver may not initialize private data before use. Zero them out to prevent use of stale data. Signed-off-by: Long Li --- drivers/scsi/scsi_lib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] scsi: zero per-cmd driver data for each MQ I/O

From: Long Li Lower layer driver may not initialize private data before use. Zero them out to prevent use of stale data. Signed-off-by: Long Li --- drivers/scsi/scsi_lib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c

Re: [kernel-hardening] Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Wed, 2017-05-10 at 21:29 +0100, Alan Cox wrote: > > In addition your change to allow it to be used by root in the guest > completely invalidates any protection you have because I can push > > "rm -rf /\n" > > as root in my namespace and exit > > The tty buffers are not flushed across the

Re: [kernel-hardening] Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Wed, 2017-05-10 at 21:29 +0100, Alan Cox wrote: > > In addition your change to allow it to be used by root in the guest > completely invalidates any protection you have because I can push > > "rm -rf /\n" > > as root in my namespace and exit > > The tty buffers are not flushed across the

Re: sparse on scripts/kconfig/*.c

I have created some new tools to make this process easier. 1) First you still have to edit the Makefile: -HOSTCC = gcc +HOSTCC = ~/progs/smatch/devel/cgcc 2) Build the data with this command: ~/progs/smatch/devel/smatch_scripts/build_generic_data.sh --target scripts/ The

Re: sparse on scripts/kconfig/*.c

I have created some new tools to make this process easier. 1) First you still have to edit the Makefile: -HOSTCC = gcc +HOSTCC = ~/progs/smatch/devel/cgcc 2) Build the data with this command: ~/progs/smatch/devel/smatch_scripts/build_generic_data.sh --target scripts/ The

Re: [PATCH] leds/trigger: system can't enter suspend.

Hi Zhang, Thanks for the patch. I'd rather keep sending uevent on setting trigger to "none". We could get rid of the problem you're trying to fix, by modifying heartbeat_pm_notifier() so that it didn't go through the whole procedure of unregistering/registering the trigger on suspend/resume.

Re: [PATCH] leds/trigger: system can't enter suspend.

Hi Zhang, Thanks for the patch. I'd rather keep sending uevent on setting trigger to "none". We could get rid of the problem you're trying to fix, by modifying heartbeat_pm_notifier() so that it didn't go through the whole procedure of unregistering/registering the trigger on suspend/resume.

Re: [RFC GIT PULL, v2] RCU changes for v4.12

On Wed, May 10, 2017 at 01:17:54PM -0700, Linus Torvalds wrote: > On Wed, May 10, 2017 at 12:54 PM, Paul E. McKenney > wrote: > > > > I am testing a merge with current linus/master, and I looked through > > the commits in -next selected by: > > > > gitk v4.11..

Re: [RFC GIT PULL, v2] RCU changes for v4.12

On Wed, May 10, 2017 at 01:17:54PM -0700, Linus Torvalds wrote: > On Wed, May 10, 2017 at 12:54 PM, Paul E. McKenney > wrote: > > > > I am testing a merge with current linus/master, and I looked through > > the commits in -next selected by: > > > > gitk v4.11.. --no-merges --all-match

[PATCH v3] LSM: Enable multiple calls to security_add_hooks() for the same LSM

The commit d69dece5f5b6 ("LSM: Add /sys/kernel/security/lsm") extend security_add_hooks() with a new parameter to register the LSM name, which may be useful to make the list of currently loaded LSM available to userspace. However, there is no clean way for an LSM to split its hook declarations

[PATCH v3] LSM: Enable multiple calls to security_add_hooks() for the same LSM

The commit d69dece5f5b6 ("LSM: Add /sys/kernel/security/lsm") extend security_add_hooks() with a new parameter to register the LSM name, which may be useful to make the list of currently loaded LSM available to userspace. However, there is no clean way for an LSM to split its hook declarations

Re: [PATCH 4/6] tty: serial: lpuart: add imx7ulp support

On 2017-05-09 23:14, Dong Aisheng wrote: > Hi Stefan, > > On Wed, May 10, 2017 at 12:10 PM, Stefan Agner wrote: >> On 2017-05-09 00:50, Dong Aisheng wrote: >>> The lpuart of imx7ulp is basically the same as ls1021a. It's also >>> 32 bit width register, but unlike ls1021a, it's

Re: [PATCH 4/6] tty: serial: lpuart: add imx7ulp support

On 2017-05-09 23:14, Dong Aisheng wrote: > Hi Stefan, > > On Wed, May 10, 2017 at 12:10 PM, Stefan Agner wrote: >> On 2017-05-09 00:50, Dong Aisheng wrote: >>> The lpuart of imx7ulp is basically the same as ls1021a. It's also >>> 32 bit width register, but unlike ls1021a, it's little endian. >>>

[PATCH] of/unittest: Delete an error message for a failed memory allocation in three functions

From: Markus Elfring Date: Wed, 10 May 2017 22:20:52 +0200 Omit an extra message for a memory allocation failure in these functions. This issue was detected by using the Coccinelle software. Link:

[PATCH] of/unittest: Delete an error message for a failed memory allocation in three functions

From: Markus Elfring Date: Wed, 10 May 2017 22:20:52 +0200 Omit an extra message for a memory allocation failure in these functions. This issue was detected by using the Coccinelle software. Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf

Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Fri, 5 May 2017 19:20:16 -0400 Matt Brown wrote: > This patchset introduces the tiocsti_restrict sysctl, whose default is > controlled via CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this > control restricts all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users. > >

Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Fri, 5 May 2017 19:20:16 -0400 Matt Brown wrote: > This patchset introduces the tiocsti_restrict sysctl, whose default is > controlled via CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this > control restricts all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users. > > This patch was

Re: [RFC GIT PULL, v2] RCU changes for v4.12

On Wed, May 10, 2017 at 12:54 PM, Paul E. McKenney wrote: > > I am testing a merge with current linus/master, and I looked through > the commits in -next selected by: > > gitk v4.11.. --no-merges --all-match --grep=drm --grep=selftest > > I didn't find anything

Re: [RFC GIT PULL, v2] RCU changes for v4.12

On Wed, May 10, 2017 at 12:54 PM, Paul E. McKenney wrote: > > I am testing a merge with current linus/master, and I looked through > the commits in -next selected by: > > gitk v4.11.. --no-merges --all-match --grep=drm --grep=selftest > > I didn't find anything obvious. If the tests

Re: [PATCH v2] kexec_file: Adjust declaration of kexec_purgatory

Kees Cook writes: > Defining kexec_purgatory as a zero-length char array upsets compile > time size checking. Since this is built on a per-arch basis, define > it as an unsized char array (like is done for other similar things, > e.g. linker sections). This silences the

Re: [PATCH v2] kexec_file: Adjust declaration of kexec_purgatory

Kees Cook writes: > Defining kexec_purgatory as a zero-length char array upsets compile > time size checking. Since this is built on a per-arch basis, define > it as an unsized char array (like is done for other similar things, > e.g. linker sections). This silences the warning generated by the

[PATCH v2] sched/fair: WARN and refuse to set buddy when !se->on_rq

If we set a next or last buddy for a se that is not on_rq, we will end up taking a NULL pointer dereference in wakeup_preempt_entity via pick_next_task_fair. Detect when we would be about to do that, throw a warning and then refuse to actually set it. This has been suggested at least

[PATCH v2] sched/fair: WARN and refuse to set buddy when !se->on_rq

If we set a next or last buddy for a se that is not on_rq, we will end up taking a NULL pointer dereference in wakeup_preempt_entity via pick_next_task_fair. Detect when we would be about to do that, throw a warning and then refuse to actually set it. This has been suggested at least

Re: [PATCH] hwmon: (coretemp) Handle frozen hotplug state correctly

On Wed, May 10, 2017 at 10:16:33PM +0300, Tommi Rantala wrote: > 2017-05-10 17:30 GMT+03:00 Thomas Gleixner : > > The recent conversion to the hotplug state machine missed that the original > > hotplug notifiers did not execute in the frozen state, which is used on > > suspend

Re: [PATCH] hwmon: (coretemp) Handle frozen hotplug state correctly

On Wed, May 10, 2017 at 10:16:33PM +0300, Tommi Rantala wrote: > 2017-05-10 17:30 GMT+03:00 Thomas Gleixner : > > The recent conversion to the hotplug state machine missed that the original > > hotplug notifiers did not execute in the frozen state, which is used on > > suspend on resume. > > > >

Re: [PATCH] hwmon: (coretemp) Handle frozen hotplug state correctly

On Wed, May 10, 2017 at 04:30:12PM +0200, Thomas Gleixner wrote: > The recent conversion to the hotplug state machine missed that the original > hotplug notifiers did not execute in the frozen state, which is used on > suspend on resume. > > This does not matter on single socket machines, but on

Re: [PATCHv3 0/2] arm64: fix hotplug rwsem boot fallout

On Wed, 10 May 2017, Mark Rutland wrote: > As a heads-up, with next-20170510 I'm seeing a warning here that I don't > recall seeing when I tested the above, and I'm not sure how to fix it: > > [0.180998] CPU features: enabling workaround for ARM erratum 832075 >

Re: [PATCHv3 0/2] arm64: fix hotplug rwsem boot fallout

On Wed, 10 May 2017, Mark Rutland wrote: > As a heads-up, with next-20170510 I'm seeing a warning here that I don't > recall seeing when I tested the above, and I'm not sure how to fix it: > > [0.180998] CPU features: enabling workaround for ARM erratum 832075 >

Re: [PATCH] hwmon: (coretemp) Handle frozen hotplug state correctly

On Wed, May 10, 2017 at 04:30:12PM +0200, Thomas Gleixner wrote: > The recent conversion to the hotplug state machine missed that the original > hotplug notifiers did not execute in the frozen state, which is used on > suspend on resume. > > This does not matter on single socket machines, but on

Re: [GIT PULL] Please pull NFS client fixes for 4.12

On Wed, May 10, 2017 at 9:47 AM, Trond Myklebust wrote: > > Features: > - Removal of the unmaintained and unused OSD pNFS layout > - Cleanup and removal of lots of unnecessary dprintk()s > - Cleanup and removal of some memory failure paths now that > .. > 56 files

Re: [GIT PULL] Please pull NFS client fixes for 4.12

On Wed, May 10, 2017 at 9:47 AM, Trond Myklebust wrote: > > Features: > - Removal of the unmaintained and unused OSD pNFS layout > - Cleanup and removal of lots of unnecessary dprintk()s > - Cleanup and removal of some memory failure paths now that > .. > 56 files changed, 949 insertions(+),

[PATCH v2] kexec_file: Adjust declaration of kexec_purgatory

Defining kexec_purgatory as a zero-length char array upsets compile time size checking. Since this is built on a per-arch basis, define it as an unsized char array (like is done for other similar things, e.g. linker sections). This silences the warning generated by the future

[PATCH v2] kexec_file: Adjust declaration of kexec_purgatory

Defining kexec_purgatory as a zero-length char array upsets compile time size checking. Since this is built on a per-arch basis, define it as an unsized char array (like is done for other similar things, e.g. linker sections). This silences the warning generated by the future

Re: [RFC GIT PULL, v2] RCU changes for v4.12

On Wed, May 10, 2017 at 12:54 PM, Ingo Molnar wrote: > > Yeah, you are right and sorry about that - I have removed the patch > generation from my pull request scripts, so it shouldn't happen in > the future. I do have to say, that during the later -rc series in particular when

Re: [RFC GIT PULL, v2] RCU changes for v4.12

On Wed, May 10, 2017 at 12:54 PM, Ingo Molnar wrote: > > Yeah, you are right and sorry about that - I have removed the patch > generation from my pull request scripts, so it shouldn't happen in > the future. I do have to say, that during the later -rc series in particular when people send me

Re: [RFC GIT PULL, v2] RCU changes for v4.12

On Wed, May 10, 2017 at 10:27:24AM -0700, Linus Torvalds wrote: [ . . . ] > parts, namely how the RCU changes apparently mess with the DRM > selftest changes. I am testing a merge with current linus/master, and I looked through the commits in -next selected by: gitk v4.11.. --no-merges

Re: [RFC GIT PULL, v2] RCU changes for v4.12

On Wed, May 10, 2017 at 10:27:24AM -0700, Linus Torvalds wrote: [ . . . ] > parts, namely how the RCU changes apparently mess with the DRM > selftest changes. I am testing a merge with current linus/master, and I looked through the commits in -next selected by: gitk v4.11.. --no-merges

Re: [RFC GIT PULL, v2] RCU changes for v4.12

* Linus Torvalds wrote: > On Tue, May 9, 2017 at 12:26 AM, Ingo Molnar wrote: > > > > The main changes are: > > So I've pulled it now (although it is showing signs of semantic > conflicts, so I'll have to look at those), but I've got two

Re: [RFC GIT PULL, v2] RCU changes for v4.12

* Linus Torvalds wrote: > On Tue, May 9, 2017 at 12:26 AM, Ingo Molnar wrote: > > > > The main changes are: > > So I've pulled it now (although it is showing signs of semantic > conflicts, so I'll have to look at those), but I've got two requests, > one for Ingo, one for Paul. > > Ingo:

Re: [PATCH] kexec_file: Adjust type of kexec_purgatory

On Tue, May 9, 2017 at 5:15 PM, Eric W. Biederman wrote: > Kees Cook writes: >> kernel/kexec_file.c:33:13: warning: array ‘kexec_purgatory’ assumed to >> have one element >> char __weak kexec_purgatory[]; >> ^~~ > > Nor does

Re: [PATCH] kexec_file: Adjust type of kexec_purgatory

On Tue, May 9, 2017 at 5:15 PM, Eric W. Biederman wrote: > Kees Cook writes: >> kernel/kexec_file.c:33:13: warning: array ‘kexec_purgatory’ assumed to >> have one element >> char __weak kexec_purgatory[]; >> ^~~ > > Nor does "void *kexec_purgatory" as that says at the

Re: [PATCH v2] scsi: sg: don't return bogus Sg_requests

On 2017-05-10 03:53 AM, Johannes Thumshirn wrote: If the list search in sg_get_rq_mark() fails to find a valid request, we return a bogus element. This then can later lead to a GPF in sg_remove_scat(). So don't return bogus Sg_requests in sg_get_rq_mark() but NULL in case the list search

Re: [PATCH v2] scsi: sg: don't return bogus Sg_requests

On 2017-05-10 03:53 AM, Johannes Thumshirn wrote: If the list search in sg_get_rq_mark() fails to find a valid request, we return a bogus element. This then can later lead to a GPF in sg_remove_scat(). So don't return bogus Sg_requests in sg_get_rq_mark() but NULL in case the list search

Re: [PATCH] efi/libstub: Indicate clang the relocation mode for arm64

El Wed, May 10, 2017 at 09:05:28PM +0200 Ard Biesheuvel ha dit: > > > > On 10 May 2017, at 20:38, Matthias Kaehlcke wrote: > > > > Hoi Ard, > > > > El Wed, May 10, 2017 at 08:51:44AM +0100 Ard Biesheuvel ha dit: > > > >> On 9 May 2017 at 22:49, Matthias Kaehlcke

Re: [PATCH] efi/libstub: Indicate clang the relocation mode for arm64

El Wed, May 10, 2017 at 09:05:28PM +0200 Ard Biesheuvel ha dit: > > > > On 10 May 2017, at 20:38, Matthias Kaehlcke wrote: > > > > Hoi Ard, > > > > El Wed, May 10, 2017 at 08:51:44AM +0100 Ard Biesheuvel ha dit: > > > >> On 9 May 2017 at 22:49, Matthias Kaehlcke wrote: > >>> El Tue, May

Re: [patch 1/1] staging: speakup: flush tty buffers and ensure hardware flow control

> + if (!(tmp_termios.c_cflag & CRTSCTS)) { > + tmp_termios.c_cflag |= CRTSCTS; > + ret = tty_set_termios(tty, _termios); > + if (ret) > + pr_warn("speakup: Failed to set hardware flow > control\n"); You should check the tty c_cflag

Re: [patch 1/1] staging: speakup: flush tty buffers and ensure hardware flow control

> + if (!(tmp_termios.c_cflag & CRTSCTS)) { > + tmp_termios.c_cflag |= CRTSCTS; > + ret = tty_set_termios(tty, _termios); > + if (ret) > + pr_warn("speakup: Failed to set hardware flow > control\n"); You should check the tty c_cflag

[GIT PULL] clk changes for v4.12

The following changes since commit e7590308d17e578e47f298cc3fec359108341cb6: Merge tag 'sunxi-clk-fixes-for-4.11-2-bis' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into clk-fixes (2017-04-17 11:04:12 -0700) are available in the git repository at:

[GIT PULL] clk changes for v4.12

The following changes since commit e7590308d17e578e47f298cc3fec359108341cb6: Merge tag 'sunxi-clk-fixes-for-4.11-2-bis' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into clk-fixes (2017-04-17 11:04:12 -0700) are available in the git repository at:

(radeon?) WARNING: drivers/gpu/drm/drm_irq.c:1195 drm_vblank_put (v4.11-12441-g56868a4)

Hi, I just tested v4.11-12441-g56868a4 on HP xw6600 with radeon graphics, and I'm seeing the following WARNING triggered constantly. I have not seen this earlier e.g. with the distro kernel 4.10.13-200.fc25.x86_64 $ lspci|grep -i amd 60:00.0 VGA compatible controller: Advanced Micro Devices,

(radeon?) WARNING: drivers/gpu/drm/drm_irq.c:1195 drm_vblank_put (v4.11-12441-g56868a4)

Hi, I just tested v4.11-12441-g56868a4 on HP xw6600 with radeon graphics, and I'm seeing the following WARNING triggered constantly. I have not seen this earlier e.g. with the distro kernel 4.10.13-200.fc25.x86_64 $ lspci|grep -i amd 60:00.0 VGA compatible controller: Advanced Micro Devices,

pinctrl-sx150x.c broken in 4.11

Hi Looks like recent pinctrl changes - possibly commit 99e4f67508e1 ("pinctrl: core: Use delayed work for hogs") - breaks pinctrl-sx150x driver in all setups where it has any pinctrl settings in device tree. AFAIU, pinctrl-sx150x is not a real pinctrl/pinmux driver, but it uses pinctrl subsystem

Re: Updating kernel.org cross compilers?

On Wed, May 10, 2017 at 3:40 PM, Segher Boessenkool wrote: > Hi Arnd, long time no see, > > On Wed, May 10, 2017 at 09:58:13AM +0200, Arnd Bergmann wrote: >> >> So in addition to GCC 7.1 I'd like to have at least GCC 6.3 around, >> >> which builds kernels without

pinctrl-sx150x.c broken in 4.11

Hi Looks like recent pinctrl changes - possibly commit 99e4f67508e1 ("pinctrl: core: Use delayed work for hogs") - breaks pinctrl-sx150x driver in all setups where it has any pinctrl settings in device tree. AFAIU, pinctrl-sx150x is not a real pinctrl/pinmux driver, but it uses pinctrl subsystem

Re: Updating kernel.org cross compilers?

On Wed, May 10, 2017 at 3:40 PM, Segher Boessenkool wrote: > Hi Arnd, long time no see, > > On Wed, May 10, 2017 at 09:58:13AM +0200, Arnd Bergmann wrote: >> >> So in addition to GCC 7.1 I'd like to have at least GCC 6.3 around, >> >> which builds kernels without warnings today. >> > >> > If you

<    1   2   3   4   5   6   7   8   9   10   >