Re: [PATCH] usb: dwc3: Fix the USB 3.0 hub detection bug after warm boot

Hello, On Thu, Jul 13, 2017 at 01:58:26PM +0800, Baolin Wang wrote: Hi, On 13 July 2017 at 07:20, gustavo panizzo wrote: Hello Wang thanks for your response On Wed, Jul 12, 2017 at 02:08:04PM +0800, Baolin Wang wrote: Hi, On 12 July 2017 at 11:52, gustavo panizzo

Re: [PATCH] usb: dwc3: Fix the USB 3.0 hub detection bug after warm boot

Hello, On Thu, Jul 13, 2017 at 01:58:26PM +0800, Baolin Wang wrote: Hi, On 13 July 2017 at 07:20, gustavo panizzo wrote: Hello Wang thanks for your response On Wed, Jul 12, 2017 at 02:08:04PM +0800, Baolin Wang wrote: Hi, On 12 July 2017 at 11:52, gustavo panizzo wrote: The dwc3

[RFC PATCH] exec: Avoid recursive modprobe for binary format handlers

When the kernel does not have a binary format handler for an executable it is attempting to load, when CONFIG_MODULES is enabled it will attempt to load a module for that format. If the kernel does not have a binary format handler for the modprobe executable, this will trigger another module load.

[RFC PATCH] exec: Avoid recursive modprobe for binary format handlers

When the kernel does not have a binary format handler for an executable it is attempting to load, when CONFIG_MODULES is enabled it will attempt to load a module for that format. If the kernel does not have a binary format handler for the modprobe executable, this will trigger another module load.

[GIT PULL] tracing: Minor updates for v4.13-rc1

Linus, Three minor updates - Use of the new GFP_RETRY_MAYFAIL to be more aggressive in allocating memory for the ring buffer without causing OOMs - Fix a memory leak in adding and removing instances - Add __rcu annotation to be able to debug RCU usage of function tracing a bit

[GIT PULL] tracing: Minor updates for v4.13-rc1

Linus, Three minor updates - Use of the new GFP_RETRY_MAYFAIL to be more aggressive in allocating memory for the ring buffer without causing OOMs - Fix a memory leak in adding and removing instances - Add __rcu annotation to be able to debug RCU usage of function tracing a bit

Re: [PATCH v2 1/2] livepatch: introduce shadow variable API

On 07/21/2017 05:13 AM, Petr Mladek wrote: > On Thu 2017-07-20 16:30:37, Joe Lawrence wrote: >> Going back to existing kpatch use-cases, since we paired shadow variable >> creation to their parent object creation, -EEXIST was never an issue. I >> think we concocted one proof-of-concept kpatch

Re: [PATCH v2 1/2] livepatch: introduce shadow variable API

On 07/21/2017 05:13 AM, Petr Mladek wrote: > On Thu 2017-07-20 16:30:37, Joe Lawrence wrote: >> Going back to existing kpatch use-cases, since we paired shadow variable >> creation to their parent object creation, -EEXIST was never an issue. I >> think we concocted one proof-of-concept kpatch

Re: [PATCH v7 06/16] lockdep: Detect and handle hist_lock ring buffer overwrite

On Fri, Jul 14, 2017 at 03:42:10PM +0900, Byungchul Park wrote: > On Thu, Jul 13, 2017 at 08:23:33PM +0900, Byungchul Park wrote: > > On Thu, Jul 13, 2017 at 8:12 PM, Peter Zijlstra > > wrote: > > > On Thu, Jul 13, 2017 at 12:29:05PM +0200, Peter Zijlstra wrote: > > >> On

Re: [PATCH v7 06/16] lockdep: Detect and handle hist_lock ring buffer overwrite

On Fri, Jul 14, 2017 at 03:42:10PM +0900, Byungchul Park wrote: > On Thu, Jul 13, 2017 at 08:23:33PM +0900, Byungchul Park wrote: > > On Thu, Jul 13, 2017 at 8:12 PM, Peter Zijlstra > > wrote: > > > On Thu, Jul 13, 2017 at 12:29:05PM +0200, Peter Zijlstra wrote: > > >> On Thu, Jul 13, 2017 at

Re: linux-next: manual merge of the btrfs-kdave tree with Linus' tree

On Tue, Jul 18, 2017 at 10:18:02AM +1000, Stephen Rothwell wrote: > Hi David, > > Today's linux-next merge of the btrfs-kdave tree got a conflict in: > > fs/btrfs/extent_io.c > > between commit: > > e6959b9350c6 ("btrfs: add support for passing in write hints for buffered > writes") > >

Re: linux-next: manual merge of the btrfs-kdave tree with Linus' tree

On Tue, Jul 18, 2017 at 10:18:02AM +1000, Stephen Rothwell wrote: > Hi David, > > Today's linux-next merge of the btrfs-kdave tree got a conflict in: > > fs/btrfs/extent_io.c > > between commit: > > e6959b9350c6 ("btrfs: add support for passing in write hints for buffered > writes") > >

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

On Fri, Jul 21, 2017 at 10:40:01AM -0300, Mauro Carvalho Chehab wrote: > What happens when the error can be corrected? Does it still report it to > userspace, or just silently hide the error? > > If I remember well about a past discussion with some vendor, I was told > that the firmware can hide

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

On Fri, Jul 21, 2017 at 10:40:01AM -0300, Mauro Carvalho Chehab wrote: > What happens when the error can be corrected? Does it still report it to > userspace, or just silently hide the error? > > If I remember well about a past discussion with some vendor, I was told > that the firmware can hide

[PATCH v2 1/4] fs/dcache: Limit numbers of negative dentries

The number of positive dentries is limited by the number of files in the filesystems. The number of negative dentries, however, has no limit other than the total amount of memory available in the system. So a rogue application that generates a lot of negative dentries can potentially exhaust most

[PATCH v2 1/4] fs/dcache: Limit numbers of negative dentries

The number of positive dentries is limited by the number of files in the filesystems. The number of negative dentries, however, has no limit other than the total amount of memory available in the system. So a rogue application that generates a lot of negative dentries can potentially exhaust most

[PATCH v2 0/4] fs/dcache: Limit # of negative dentries

v1->v2: - Move the new nr_negative field to the end of dentry_stat_t structure as suggested by Matthew Wilcox. - With the help of Miklos Szeredi, fix incorrect locking order in dentry_kill() by using lock_parent() instead of locking the parent's d_lock directly. - Correctly

[PATCH v2 3/4] fs/dcache: Enable automatic pruning of negative dentries

Having a limit for the number of negative dentries does have an undesirable side effect that no new negative dentries will be allowed when the limit is reached. This will have performance implication for some types of workloads. So we need a way to prune the negative dentries so that new ones can

[PATCH v2 4/4] fs/dcache: Protect negative dentry pruning from racing with umount

The negative dentry pruning is done on a specific super_block set in the ndblk.prune_sb variable. If the super_block is also being un-mounted concurrently, the content of the super_block may no longer be valid. To protect against such racing condition, a new lock is added to the ndblk structure

[PATCH v2 0/4] fs/dcache: Limit # of negative dentries

v1->v2: - Move the new nr_negative field to the end of dentry_stat_t structure as suggested by Matthew Wilcox. - With the help of Miklos Szeredi, fix incorrect locking order in dentry_kill() by using lock_parent() instead of locking the parent's d_lock directly. - Correctly

[PATCH v2 3/4] fs/dcache: Enable automatic pruning of negative dentries

Having a limit for the number of negative dentries does have an undesirable side effect that no new negative dentries will be allowed when the limit is reached. This will have performance implication for some types of workloads. So we need a way to prune the negative dentries so that new ones can

[PATCH v2 4/4] fs/dcache: Protect negative dentry pruning from racing with umount

The negative dentry pruning is done on a specific super_block set in the ndblk.prune_sb variable. If the super_block is also being un-mounted concurrently, the content of the super_block may no longer be valid. To protect against such racing condition, a new lock is added to the ndblk structure

[PATCH v2 2/4] fs/dcache: Report negative dentry number in dentry-state

The number of negative dentries currently in the system is now reported in the /proc/sys/fs/dentry-state file. Signed-off-by: Waiman Long --- fs/dcache.c| 16 +++- include/linux/dcache.h | 7 --- 2 files changed, 19 insertions(+), 4 deletions(-)

[PATCH v2 2/4] fs/dcache: Report negative dentry number in dentry-state

The number of negative dentries currently in the system is now reported in the /proc/sys/fs/dentry-state file. Signed-off-by: Waiman Long --- fs/dcache.c| 16 +++- include/linux/dcache.h | 7 --- 2 files changed, 19 insertions(+), 4 deletions(-) diff --git

[PATCH] staging: rtl8192u: fix incorrect mask and shift on u8 data

From: Colin Ian King The cfg_action bit comes from the high bit of pmsg[4] so the current mask and shift are in correct and always result in zero. Fix this by using the correct mask and shif to get the correct cfg_action bit value. Detected by CoverityScan, CID#142890

[PATCH] staging: rtl8192u: fix incorrect mask and shift on u8 data

From: Colin Ian King The cfg_action bit comes from the high bit of pmsg[4] so the current mask and shift are in correct and always result in zero. Fix this by using the correct mask and shif to get the correct cfg_action bit value. Detected by CoverityScan, CID#142890 ("Operands don't affect

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

Em Fri, 21 Jul 2017 15:34:41 +0200 Borislav Petkov escreveu: > On Thu, Jul 20, 2017 at 07:50:03PM +, Kani, Toshimitsu wrote: > > GHES / firmware-first still requires OS recovery actions when an error > > cannot be corrected by the platform. They are handled by ghes_proc(), >

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

Em Fri, 21 Jul 2017 15:34:41 +0200 Borislav Petkov escreveu: > On Thu, Jul 20, 2017 at 07:50:03PM +, Kani, Toshimitsu wrote: > > GHES / firmware-first still requires OS recovery actions when an error > > cannot be corrected by the platform. They are handled by ghes_proc(), > > and ghes_edac

Problem to compile Kernel 3.18.55 in fork.c:341

Hi all ! I try to compile the kernel 3.18.55 I got this error message during 'make deb-pkg' : kernel/built-in.o: In function `dup_task_struct': /home/samp/kernel/linux-3.18.55/kernel/fork.c:341: undefined reference to `get_random_long' Makefile:927: recipe for target 'vmlinux' failed

Problem to compile Kernel 3.18.55 in fork.c:341

Hi all ! I try to compile the kernel 3.18.55 I got this error message during 'make deb-pkg' : kernel/built-in.o: In function `dup_task_struct': /home/samp/kernel/linux-3.18.55/kernel/fork.c:341: undefined reference to `get_random_long' Makefile:927: recipe for target 'vmlinux' failed

[PATCH net 2/2] bpf/verifier: fix min/max handling in BPF_SUB

We have to subtract the src max from the dst min, and vice-versa, since (e.g.) the smallest result comes from the largest subtrahend. Fixes: 484611357c19 ("bpf: allow access into map value arrays") Signed-off-by: Edward Cree --- kernel/bpf/verifier.c | 21

[PATCH net 2/2] bpf/verifier: fix min/max handling in BPF_SUB

We have to subtract the src max from the dst min, and vice-versa, since (e.g.) the smallest result comes from the largest subtrahend. Fixes: 484611357c19 ("bpf: allow access into map value arrays") Signed-off-by: Edward Cree --- kernel/bpf/verifier.c | 21 +++-- 1 file changed,

[PATCH net 1/2] selftests/bpf: subtraction bounds test

There is a bug in the verifier's handling of BPF_SUB: [a,b] - [c,d] yields was [a-c, b-d] rather than the correct [a-d, b-c]. So here is a test which, with the bogus handling, will produce ranges of [0,0] and thus allowed accesses; whereas the correct handling will give a range of [-255, 255]

[PATCH net 1/2] selftests/bpf: subtraction bounds test

There is a bug in the verifier's handling of BPF_SUB: [a,b] - [c,d] yields was [a-c, b-d] rather than the correct [a-d, b-c]. So here is a test which, with the bogus handling, will produce ranges of [0,0] and thus allowed accesses; whereas the correct handling will give a range of [-255, 255]

[PATCH net 0/2] bpf: fix verifier min/max handling in BPF_SUB

I managed to come up with a test for the swapped bounds in BPF_SUB, so here it is along with a patch that fixes it, separated out from my 'rewrite everything' series so it can go to -stable. Edward Cree (2): selftests/bpf: subtraction bounds test bpf/verifier: fix min/max handling in

Re: [RESEND PATCH] c6x: defconfig: Cleanup from old Kconfig options

On Thu, 2017-07-20 at 06:58 +0200, Krzysztof Kozlowski wrote: > Remove old, dead Kconfig options (in order appearing in this commit): > - EXPERIMENTAL is gone since v3.9; > - MISC_DEVICES: commit 7c5763b8453a ("drivers: misc: Remove >MISC_DEVICES config option"); > > Signed-off-by:

[PATCH net 0/2] bpf: fix verifier min/max handling in BPF_SUB

I managed to come up with a test for the swapped bounds in BPF_SUB, so here it is along with a patch that fixes it, separated out from my 'rewrite everything' series so it can go to -stable. Edward Cree (2): selftests/bpf: subtraction bounds test bpf/verifier: fix min/max handling in

Re: [RESEND PATCH] c6x: defconfig: Cleanup from old Kconfig options

On Thu, 2017-07-20 at 06:58 +0200, Krzysztof Kozlowski wrote: > Remove old, dead Kconfig options (in order appearing in this commit): > - EXPERIMENTAL is gone since v3.9; > - MISC_DEVICES: commit 7c5763b8453a ("drivers: misc: Remove >MISC_DEVICES config option"); > > Signed-off-by:

Re: [PATCH v5 0/2] add UniPhier thermal support

Hello, 2017-07-21 22:24 GMT+09:00 Masahiro Yamada : > 2017-07-21 20:21 GMT+09:00 Kunihiko Hayashi : >> This series adds support for CPU temperature monitor modules implemented >> on UniPhier LD20 and PXs2 SoCs. This driver supports

Re: [PATCH v5 0/2] add UniPhier thermal support

Hello, 2017-07-21 22:24 GMT+09:00 Masahiro Yamada : > 2017-07-21 20:21 GMT+09:00 Kunihiko Hayashi : >> This series adds support for CPU temperature monitor modules implemented >> on UniPhier LD20 and PXs2 SoCs. This driver supports temperature monitoring >> and alert function on the module. >> >>

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

On Thu, Jul 20, 2017 at 07:50:03PM +, Kani, Toshimitsu wrote: > GHES / firmware-first still requires OS recovery actions when an error > cannot be corrected by the platform. They are handled by ghes_proc(), > and ghes_edac remains its error-reporting wrapper. I mean all the recovery actions

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

On Thu, Jul 20, 2017 at 07:50:03PM +, Kani, Toshimitsu wrote: > GHES / firmware-first still requires OS recovery actions when an error > cannot be corrected by the platform. They are handled by ghes_proc(), > and ghes_edac remains its error-reporting wrapper. I mean all the recovery actions

Re: [PATCH] lib/int_sqrt.c: Optimize square root function

On Fri, Jul 21, 2017 at 03:26:21PM +0200, Peter Zijlstra wrote: > > EVENT=0 -DNEW=1 -DFLS=1 > event: 19.626050 +- 0.038995 > EVENT=0 -DNEW=1 -DFLS=1 -DWIPE_BTB=1 > event: 109.610670 +- 0.425667 > > EVENT=0 -DNEW=1 -DFLS=1 -DANSHUL=1 > event: 21.445680 +- 0.043782 > EVENT=0 -DNEW=1 -DFLS=1

Re: [PATCH] lib/int_sqrt.c: Optimize square root function

On Fri, Jul 21, 2017 at 03:26:21PM +0200, Peter Zijlstra wrote: > > EVENT=0 -DNEW=1 -DFLS=1 > event: 19.626050 +- 0.038995 > EVENT=0 -DNEW=1 -DFLS=1 -DWIPE_BTB=1 > event: 109.610670 +- 0.425667 > > EVENT=0 -DNEW=1 -DFLS=1 -DANSHUL=1 > event: 21.445680 +- 0.043782 > EVENT=0 -DNEW=1 -DFLS=1

Re: [PATCH 3/4] ACPI / APEI: Drop uninformative messages during boot

On Thu, Jul 20, 2017 at 06:50:51PM +0100, Punit Agrawal wrote: > "Firmware does not support APEI firmware first mode" > > Thoughts? I guess the simplest would be to add a third state to that hest_disable to denote "HEST table not found" and then exit ghes_init() early, based on checking it.

Re: [PATCH 3/4] ACPI / APEI: Drop uninformative messages during boot

On Thu, Jul 20, 2017 at 06:50:51PM +0100, Punit Agrawal wrote: > "Firmware does not support APEI firmware first mode" > > Thoughts? I guess the simplest would be to add a third state to that hest_disable to denote "HEST table not found" and then exit ghes_init() early, based on checking it.

Re: [PATCH] lib/int_sqrt.c: Optimize square root function

On Fri, Jul 21, 2017 at 05:15:10AM -0700, Joe Perches wrote: > On Fri, 2017-07-21 at 13:40 +0200, Peter Zijlstra wrote: > > @@ -21,7 +22,11 @@ unsigned long int_sqrt(unsigned long x) > > if (x <= 1) > > return x; > > > > - m = 1UL << (BITS_PER_LONG - 2); > > + m = 1UL <<

Re: [PATCH] lib/int_sqrt.c: Optimize square root function

On Fri, Jul 21, 2017 at 05:15:10AM -0700, Joe Perches wrote: > On Fri, 2017-07-21 at 13:40 +0200, Peter Zijlstra wrote: > > @@ -21,7 +22,11 @@ unsigned long int_sqrt(unsigned long x) > > if (x <= 1) > > return x; > > > > - m = 1UL << (BITS_PER_LONG - 2); > > + m = 1UL <<

Re: [PATCH] GFS2: fix code parameter error in inode_go_lock

- Original Message - | In inode_go_lock() function, the parameter order of list_add() is error. | According to the define of list_add(), the first parameter is new entry | and the second is the list head, so ip->i_trunc_list should be the | first parameter and the sdp->sd_trunc_list should

Re: [PATCH] GFS2: fix code parameter error in inode_go_lock

- Original Message - | In inode_go_lock() function, the parameter order of list_add() is error. | According to the define of list_add(), the first parameter is new entry | and the second is the list head, so ip->i_trunc_list should be the | first parameter and the sdp->sd_trunc_list should

Re: [PATCH v2 8/8] KVM: arm/arm64: register DEOI irq bypass consumer on ARM/ARM64

On Thu, Jun 15, 2017 at 02:52:40PM +0200, Eric Auger wrote: > This patch selects IRQ_BYPASS_MANAGER and HAVE_KVM_IRQ_BYPASS > configs for ARM/ARM64. > > kvm_arch_has_irq_bypass() now is implemented and returns true. > As a consequence the irq bypass consumer will be registered for > ARM/ARM64

Re: [PATCH v2 8/8] KVM: arm/arm64: register DEOI irq bypass consumer on ARM/ARM64

On Thu, Jun 15, 2017 at 02:52:40PM +0200, Eric Auger wrote: > This patch selects IRQ_BYPASS_MANAGER and HAVE_KVM_IRQ_BYPASS > configs for ARM/ARM64. > > kvm_arch_has_irq_bypass() now is implemented and returns true. > As a consequence the irq bypass consumer will be registered for > ARM/ARM64

Re: [PATCH v5 0/2] add UniPhier thermal support

2017-07-21 20:21 GMT+09:00 Kunihiko Hayashi : > This series adds support for CPU temperature monitor modules implemented > on UniPhier LD20 and PXs2 SoCs. This driver supports temperature monitoring > and alert function on the module. > > Changes in v4: > - fix

Re: [PATCH v5 0/2] add UniPhier thermal support

2017-07-21 20:21 GMT+09:00 Kunihiko Hayashi : > This series adds support for CPU temperature monitor modules implemented > on UniPhier LD20 and PXs2 SoCs. This driver supports temperature monitoring > and alert function on the module. > > Changes in v4: > - fix warnings from sparse by replacing

Re: [PATCH] Revert "x86/uaccess: Add stack frame output operand in get_user() inline asm"

On Fri, Jul 21, 2017 at 12:13:31PM +0300, Andrey Ryabinin wrote: > > Still, unfortunately, I don't think that's going to work for GCC. > > Changing the '__sp' register variable to global in the header file > > causes it to make a *bunch* of changes across the kernel, even in > > functions which

Re: [PATCH] Revert "x86/uaccess: Add stack frame output operand in get_user() inline asm"

On Fri, Jul 21, 2017 at 12:13:31PM +0300, Andrey Ryabinin wrote: > > Still, unfortunately, I don't think that's going to work for GCC. > > Changing the '__sp' register variable to global in the header file > > causes it to make a *bunch* of changes across the kernel, even in > > functions which

[RFC PATCH 4/9] housekeeping: Make housekeeping cpumask private

Nobody needs to access this detail. housekeeping_cpumask() already takes care about it. Signed-off-by: Frederic Weisbecker Cc: Chris Metcalf Cc: Rik van Riel Cc: Peter Zijlstra Cc: Thomas Gleixner

[RFC PATCH 4/9] housekeeping: Make housekeeping cpumask private

Nobody needs to access this detail. housekeeping_cpumask() already takes care about it. Signed-off-by: Frederic Weisbecker Cc: Chris Metcalf Cc: Rik van Riel Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Mike Galbraith Cc: Ingo Molnar Cc: Christoph Lameter Cc: Paul E. McKenney Cc: Wanpeng

Re: [PATCH v5 2/2] thermal: uniphier: add UniPhier thermal driver

2017-07-21 20:21 GMT+09:00 Kunihiko Hayashi : > +static int uniphier_tm_initialize_sensor(struct uniphier_tm_dev *tdev) > +{ > + struct regmap *map = tdev->regmap; > + u32 val; > + int ret; > + > + /* stop PVT */ > +

Re: [PATCH v5 2/2] thermal: uniphier: add UniPhier thermal driver

2017-07-21 20:21 GMT+09:00 Kunihiko Hayashi : > +static int uniphier_tm_initialize_sensor(struct uniphier_tm_dev *tdev) > +{ > + struct regmap *map = tdev->regmap; > + u32 val; > + int ret; > + > + /* stop PVT */ > + regmap_write_bits(map, tdev->data->block_base +

[RFC PATCH 2/9] watchdog: Use housekeeping_cpumask() instead of ad-hoc version

While trying to disable the watchog on nohz_full CPUs, the watchdog implements an ad-hoc version of housekeeping_cpumask(). Lets replace those re-invented lines. Signed-off-by: Frederic Weisbecker Cc: Chris Metcalf Cc: Rik van Riel

[RFC PATCH 2/9] watchdog: Use housekeeping_cpumask() instead of ad-hoc version

While trying to disable the watchog on nohz_full CPUs, the watchdog implements an ad-hoc version of housekeeping_cpumask(). Lets replace those re-invented lines. Signed-off-by: Frederic Weisbecker Cc: Chris Metcalf Cc: Rik van Riel Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Mike Galbraith

[RFC PATCH 6/9] housekeeping: Rename is_housekeeping_cpu to housekeeping_cpu

To keep a proper housekeeping namespace. Signed-off-by: Frederic Weisbecker Cc: Chris Metcalf Cc: Rik van Riel Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Mike Galbraith Cc:

[RFC PATCH 6/9] housekeeping: Rename is_housekeeping_cpu to housekeeping_cpu

To keep a proper housekeeping namespace. Signed-off-by: Frederic Weisbecker Cc: Chris Metcalf Cc: Rik van Riel Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Mike Galbraith Cc: Ingo Molnar Cc: Christoph Lameter Cc: Paul E. McKenney Cc: Wanpeng Li Cc: Luiz Capitulino ---

[RFC PATCH 8/9] housekeeping: Move it under own config, independant from NO_HZ

Complete the housekeeping split from CONFIG_NO_HZ_FULL by moving it under its own config. This way we finally separate the isolation code from nohz. Signed-off-by: Frederic Weisbecker Cc: Chris Metcalf Cc: Rik van Riel Cc: Peter

[RFC PATCH 8/9] housekeeping: Move it under own config, independant from NO_HZ

Complete the housekeeping split from CONFIG_NO_HZ_FULL by moving it under its own config. This way we finally separate the isolation code from nohz. Signed-off-by: Frederic Weisbecker Cc: Chris Metcalf Cc: Rik van Riel Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Mike Galbraith Cc: Ingo

[RFC PATCH 1/9] housekeeping: Move housekeeping related code to its own file

The housekeeping code is currently tied to the nohz code. As we are planning to make housekeeping independant from it, start with moving the relevant code to its own file. Signed-off-by: Frederic Weisbecker Cc: Chris Metcalf Cc: Rik van Riel

[RFC PATCH 1/9] housekeeping: Move housekeeping related code to its own file

The housekeeping code is currently tied to the nohz code. As we are planning to make housekeeping independant from it, start with moving the relevant code to its own file. Signed-off-by: Frederic Weisbecker Cc: Chris Metcalf Cc: Rik van Riel Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Mike

[RFC PATCH 7/9] housekeeping: Use own boot option, independant from nohz

The housekeeping is currently driven by nohz_full where any CPU that is not in the nohz_full range is considered as a housekeeper. This is a design mistake because nohz is just a detail among all the existing isolation features. Nohz shouldn't imply anything else than tick related things. We

[RFC PATCH 7/9] housekeeping: Use own boot option, independant from nohz

The housekeeping is currently driven by nohz_full where any CPU that is not in the nohz_full range is considered as a housekeeper. This is a design mistake because nohz is just a detail among all the existing isolation features. Nohz shouldn't imply anything else than tick related things. We

[RFC PATCH 0/9] Introduce housekeeping subsystem

I'm leaving for two weeks so this is food for thoughts in the meantime :) We have a design issue with nohz_full: it drives the isolation features through the *housekeeping*() functions: kthreads, unpinned timers, watchdog, ... But things should work the other way around because the tick is just

[RFC PATCH 9/9] workqueue: Affine unbound workqueues to housekeeping cpumask

Although the unbound workqueue cpumask can be overriden through sysfs, the housekeeping cpumask which drives the CPU isolation provides a relevant default value. Signed-off-by: Frederic Weisbecker Cc: Chris Metcalf Cc: Rik van Riel

[RFC PATCH 3/9] housekeeping: Provide a dynamic off-case to housekeeping_any_cpu()

housekeeping_any_cpu() doesn't handle correctly the case where CONFIG_NO_HZ_FULL=y and no CPU is in nohz_full mode. So far no caller needs this but lets prepare to avoid any future surprise. Signed-off-by: Frederic Weisbecker Cc: Chris Metcalf Cc: Rik

[RFC PATCH 0/9] Introduce housekeeping subsystem

I'm leaving for two weeks so this is food for thoughts in the meantime :) We have a design issue with nohz_full: it drives the isolation features through the *housekeeping*() functions: kthreads, unpinned timers, watchdog, ... But things should work the other way around because the tick is just

[RFC PATCH 9/9] workqueue: Affine unbound workqueues to housekeeping cpumask

Although the unbound workqueue cpumask can be overriden through sysfs, the housekeeping cpumask which drives the CPU isolation provides a relevant default value. Signed-off-by: Frederic Weisbecker Cc: Chris Metcalf Cc: Rik van Riel Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Mike Galbraith

[RFC PATCH 3/9] housekeeping: Provide a dynamic off-case to housekeeping_any_cpu()

housekeeping_any_cpu() doesn't handle correctly the case where CONFIG_NO_HZ_FULL=y and no CPU is in nohz_full mode. So far no caller needs this but lets prepare to avoid any future surprise. Signed-off-by: Frederic Weisbecker Cc: Chris Metcalf Cc: Rik van Riel Cc: Peter Zijlstra Cc: Thomas

[RFC PATCH 5/9] housekeeping: Use its own static key

Housekeeping code still depends on nohz_full static key. Since we want to decouple housekeeping from nohz, lets create a housekeeping own static key. It's mostly relevant for calls to is_housekeeping_cpu() from the scheduler. Signed-off-by: Frederic Weisbecker Cc: Chris

[RFC PATCH 5/9] housekeeping: Use its own static key

Housekeeping code still depends on nohz_full static key. Since we want to decouple housekeeping from nohz, lets create a housekeeping own static key. It's mostly relevant for calls to is_housekeeping_cpu() from the scheduler. Signed-off-by: Frederic Weisbecker Cc: Chris Metcalf Cc: Rik van Riel

Re: [PATCH v5 2/2] thermal: uniphier: add UniPhier thermal driver

2017-07-21 20:21 GMT+09:00 Kunihiko Hayashi : > +static int uniphier_tm_initialize_sensor(struct uniphier_tm_dev *tdev) > +{ > + struct regmap *map = tdev->regmap; > + u32 val; > + int ret; > + > + /* stop PVT */ > +

Re: [PATCH v5 2/2] thermal: uniphier: add UniPhier thermal driver

2017-07-21 20:21 GMT+09:00 Kunihiko Hayashi : > +static int uniphier_tm_initialize_sensor(struct uniphier_tm_dev *tdev) > +{ > + struct regmap *map = tdev->regmap; > + u32 val; > + int ret; > + > + /* stop PVT */ > + regmap_write_bits(map, tdev->data->block_base +

Re: [PATCH v6 RESEND] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions

On 07/21/17 at 12:37pm, Ingo Molnar wrote: > > * Baoquan He wrote: > > > +/* > > + * Returns true if mirror region found (and must have been processed > > + * for slots adding) > > + */ > > +static bool process_efi_entries(unsigned long minimum, > > +

Re: [PATCH v6 RESEND] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions

On 07/21/17 at 12:37pm, Ingo Molnar wrote: > > * Baoquan He wrote: > > > +/* > > + * Returns true if mirror region found (and must have been processed > > + * for slots adding) > > + */ > > +static bool process_efi_entries(unsigned long minimum, > > + unsigned long

Re: [PATCH] powerpc/44x/fsp2: correct dtb reg property for /sdhci@020c0000

On Fri, 2017-07-21 at 15:54 +0300, Ivan Mikhaylov wrote: > Hi Ian, > > Building the split device-tree tree[0] highlighted that upstream commit > > 9eec6cb142bd ("powerpc/44x/fsp2: Add device tree for FSP2 board") introduced > > this warning when building the device tree: > > > > $ make

Re: [PATCH] powerpc/44x/fsp2: correct dtb reg property for /sdhci@020c0000

On Fri, 2017-07-21 at 15:54 +0300, Ivan Mikhaylov wrote: > Hi Ian, > > Building the split device-tree tree[0] highlighted that upstream commit > > 9eec6cb142bd ("powerpc/44x/fsp2: Add device tree for FSP2 board") introduced > > this warning when building the device tree: > > > > $ make

Re: [PATCH v2 6/8] KVM: arm/arm64: vgic: Implement forwarding setting

On Thu, Jun 15, 2017 at 02:52:38PM +0200, Eric Auger wrote: > Implements kvm_vgic_[set|unset]_forwarding. > > Handle low-level VGIC programming and consistent irqchip > programming. > > Signed-off-by: Eric Auger > > --- > > v1 -> v2: > - change the parameter names used

Re: [PATCH v2 6/8] KVM: arm/arm64: vgic: Implement forwarding setting

On Thu, Jun 15, 2017 at 02:52:38PM +0200, Eric Auger wrote: > Implements kvm_vgic_[set|unset]_forwarding. > > Handle low-level VGIC programming and consistent irqchip > programming. > > Signed-off-by: Eric Auger > > --- > > v1 -> v2: > - change the parameter names used in the declaration > -

Re: [PATCH 0/3] livepatch: introduce atomic replace

On Wed, 19 Jul 2017, Jason Baron wrote: > Hi, > > In testing livepatch, I found that when doing cumulative patches, if a patched > function is completed reverted by a subsequent patch (back to its original > state) > livepatch does not revert the funtion to its original state. Specifically, if

Re: [PATCH 0/3] livepatch: introduce atomic replace

On Wed, 19 Jul 2017, Jason Baron wrote: > Hi, > > In testing livepatch, I found that when doing cumulative patches, if a patched > function is completed reverted by a subsequent patch (back to its original > state) > livepatch does not revert the funtion to its original state. Specifically, if

Re: [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks

On Thu, Jul 13, 2017 at 12:14:37PM +0530, Viresh Kumar wrote: > diff --git a/drivers/cpufreq/cpufreq_governor.c > b/drivers/cpufreq/cpufreq_governor.c > index 47e24b5384b3..606b1a37a1af 100644 > --- a/drivers/cpufreq/cpufreq_governor.c > +++ b/drivers/cpufreq/cpufreq_governor.c > @@ -275,6

Re: [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks

On Thu, Jul 13, 2017 at 12:14:37PM +0530, Viresh Kumar wrote: > diff --git a/drivers/cpufreq/cpufreq_governor.c > b/drivers/cpufreq/cpufreq_governor.c > index 47e24b5384b3..606b1a37a1af 100644 > --- a/drivers/cpufreq/cpufreq_governor.c > +++ b/drivers/cpufreq/cpufreq_governor.c > @@ -275,6

Re: [PATCH v2 5/8] KVM: arm/arm64: vgic: Handle mapped level sensitive SPIs

On Fri, Jul 07, 2017 at 09:41:42AM +0200, Auger Eric wrote: > Hi Marc, > > On 04/07/2017 14:15, Marc Zyngier wrote: > > Hi Eric, > > > > On 15/06/17 13:52, Eric Auger wrote: > >> Currently, the line level of unmapped level sensitive SPIs is > >> toggled down by the maintenance IRQ

Re: [PATCH v2 5/8] KVM: arm/arm64: vgic: Handle mapped level sensitive SPIs

On Fri, Jul 07, 2017 at 09:41:42AM +0200, Auger Eric wrote: > Hi Marc, > > On 04/07/2017 14:15, Marc Zyngier wrote: > > Hi Eric, > > > > On 15/06/17 13:52, Eric Auger wrote: > >> Currently, the line level of unmapped level sensitive SPIs is > >> toggled down by the maintenance IRQ

[PATCH 1/2] PM / suspend: Use mem_sleep_labels[] strings in messages

From: Rafael J. Wysocki Some messages in suspend.c currently print state names from pm_states[], but that may be confusing if the mem_sleep sysfs attribute is changed to anything different from "mem", because in those cases the messages will say either "freeze" or

[PATCH 1/2] PM / suspend: Use mem_sleep_labels[] strings in messages

From: Rafael J. Wysocki Some messages in suspend.c currently print state names from pm_states[], but that may be confusing if the mem_sleep sysfs attribute is changed to anything different from "mem", because in those cases the messages will say either "freeze" or "standby" after writing "mem"

[PATCH 0/2] PM / suspend: Messaging updates

Hi, The first patch addresses a potential confusion regarding messages printed by the suspend core code to the kernel log and the second one adds a pr_fmt() to kernel/power/suspend.c. The patches are on top of the series I posted yesterday: http://marc.info/?l=linux-pm=150059650805506=2

[PATCH 2/2] PM / suspend: Define pr_fmt() in suspend.c

From: Rafael J. Wysocki Define a common prefix ("PM:") for messages printed by the code in kernel/power/suspend.c. Signed-off-by: Rafael J. Wysocki --- kernel/power/suspend.c | 16 +--- 1 file changed, 9 insertions(+), 7

[PATCH 0/2] PM / suspend: Messaging updates

Hi, The first patch addresses a potential confusion regarding messages printed by the suspend core code to the kernel log and the second one adds a pr_fmt() to kernel/power/suspend.c. The patches are on top of the series I posted yesterday: http://marc.info/?l=linux-pm=150059650805506=2

[PATCH 2/2] PM / suspend: Define pr_fmt() in suspend.c

From: Rafael J. Wysocki Define a common prefix ("PM:") for messages printed by the code in kernel/power/suspend.c. Signed-off-by: Rafael J. Wysocki --- kernel/power/suspend.c | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) Index: linux-pm/kernel/power/suspend.c

Re: [PATCH] powerpc/44x/fsp2: correct dtb reg property for /sdhci@020c0000

Hi Ian, >Building the split device-tree tree[0] highlighted that upstream commit >9eec6cb142bd ("powerpc/44x/fsp2: Add device tree for FSP2 board") introduced >this warning when building the device tree: > >$ make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc fsp2.dtb > CHK

Re: [PATCH] powerpc/44x/fsp2: correct dtb reg property for /sdhci@020c0000

Hi Ian, >Building the split device-tree tree[0] highlighted that upstream commit >9eec6cb142bd ("powerpc/44x/fsp2: Add device tree for FSP2 board") introduced >this warning when building the device tree: > >$ make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc fsp2.dtb > CHK

<    4   5   6   7   8   9   10   11   12   13   >