Re: [PATCH v3] writeback: safer lock nesting

On Tue 10-04-18 13:48:37, Andrew Morton wrote: > On Tue, 10 Apr 2018 08:33:57 +0200 Michal Hocko wrote: > > > > Reported-by: Wang Long > > > Signed-off-by: Greg Thelen > > > Change-Id: Ibb773e8045852978f6207074491d262f1b3fb613 > >

Re: [PATCH v3] writeback: safer lock nesting

On Tue 10-04-18 13:48:37, Andrew Morton wrote: > On Tue, 10 Apr 2018 08:33:57 +0200 Michal Hocko wrote: > > > > Reported-by: Wang Long > > > Signed-off-by: Greg Thelen > > > Change-Id: Ibb773e8045852978f6207074491d262f1b3fb613 > > > > Not a stable material IMHO > > Why's that? Wang Long

Re: KMSAN: uninit-value in tipc_subscrb_rcv_cb

syzbot has found reproducer for the following crash on https://github.com/google/kmsan.git/master commit 35ff515e4bda2646f6c881d33951c306ea9c282a (Tue Apr 10 08:59:43 2018 +) Merge pull request #11 from parkerduckworth/readme syzbot dashboard link:

Re: KMSAN: uninit-value in tipc_subscrb_rcv_cb

syzbot has found reproducer for the following crash on https://github.com/google/kmsan.git/master commit 35ff515e4bda2646f6c881d33951c306ea9c282a (Tue Apr 10 08:59:43 2018 +) Merge pull request #11 from parkerduckworth/readme syzbot dashboard link:

Re: [PATCH v2 00/14] chrome_laptop: stop being a platform driver

Hi Dmitry, On Tue, Mar 20, 2018 at 03:31:24PM -0700, Dmitry Torokhov wrote: > Hi, > > This series is a combination of Atmel touchscreen driver stopping using > platform data and moving over to generic device properties, and > chromeos-laptop switching from being platform driver, which is the

Re: [PATCH v2 00/14] chrome_laptop: stop being a platform driver

Hi Dmitry, On Tue, Mar 20, 2018 at 03:31:24PM -0700, Dmitry Torokhov wrote: > Hi, > > This series is a combination of Atmel touchscreen driver stopping using > platform data and moving over to generic device properties, and > chromeos-laptop switching from being platform driver, which is the

Re: [PATCH v7 2/5] of: change overlay apply input data from unflattened to FDT

On 2018-04-05 23:12, Rob Herring wrote: > On Thu, Apr 5, 2018 at 2:28 PM, Frank Rowand wrote: >> On 04/05/18 12:13, Jan Kiszka wrote: >>> On 2018-04-05 20:59, Frank Rowand wrote: Hi Jan, On 04/04/18 15:35, Jan Kiszka wrote: > Hi Frank, > > On

Re: [PATCH v7 2/5] of: change overlay apply input data from unflattened to FDT

On 2018-04-05 23:12, Rob Herring wrote: > On Thu, Apr 5, 2018 at 2:28 PM, Frank Rowand wrote: >> On 04/05/18 12:13, Jan Kiszka wrote: >>> On 2018-04-05 20:59, Frank Rowand wrote: Hi Jan, On 04/04/18 15:35, Jan Kiszka wrote: > Hi Frank, > > On 2018-03-04 01:17,

[GIT PULL] Immutable branch between MFD and Platform due for the v4.17 merge window

Hi Lee, Please take a look at this IB that incorporates v4 of Enric's cros_ec debugfs and sysfs series. Thanks! Benson The following changes since commit 3eb2ce825ea1ad89d20f7a3b5780df850e4be274: Linux 4.16-rc7 (2018-03-25 12:44:30 -1000) are available in the Git repository at:

[GIT PULL] Immutable branch between MFD and Platform due for the v4.17 merge window

Hi Lee, Please take a look at this IB that incorporates v4 of Enric's cros_ec debugfs and sysfs series. Thanks! Benson The following changes since commit 3eb2ce825ea1ad89d20f7a3b5780df850e4be274: Linux 4.16-rc7 (2018-03-25 12:44:30 -1000) are available in the Git repository at:

Re: [PATCH] net: dsa: b53: Replace mdelay with msleep in b53_switch_reset_gpio

On 11/04/2018 09:51, Jia-Ju Bai wrote: b53_switch_reset_gpio() is never called in atomic context. The call chain ending up at b53_switch_reset_gpio() is: [1] b53_switch_reset_gpio() <- b53_switch_reset() <- b53_reset_switch() <- b53_setup() b53_switch_reset_gpio() is set as ".setup" in

Re: [PATCH] net: dsa: b53: Replace mdelay with msleep in b53_switch_reset_gpio

On 11/04/2018 09:51, Jia-Ju Bai wrote: b53_switch_reset_gpio() is never called in atomic context. The call chain ending up at b53_switch_reset_gpio() is: [1] b53_switch_reset_gpio() <- b53_switch_reset() <- b53_reset_switch() <- b53_setup() b53_switch_reset_gpio() is set as ".setup" in

[GIT PULL] apparmor updates for v4.17

Hi, Please pull these apparmor changes for v4.17 Thanks! - John The following changes since commit d8a5b80568a9cb66810e75b182018e9edb68e8ff: Linux 4.15 (2018-01-28 13:20:33 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor

[GIT PULL] apparmor updates for v4.17

Hi, Please pull these apparmor changes for v4.17 Thanks! - John The following changes since commit d8a5b80568a9cb66810e75b182018e9edb68e8ff: Linux 4.15 (2018-01-28 13:20:33 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor

[PATCH v5 2/3] pinctrl: bcm2835: Add support for generic pinctrl binding

To keep driver up to date we add generic pinctrl binding support, which covers the features used in this driver and has additional node properties that this SoC has compatibility, so enabling future implementations of these properties without the need to create new node properties in the device

[PATCH v5 2/3] pinctrl: bcm2835: Add support for generic pinctrl binding

To keep driver up to date we add generic pinctrl binding support, which covers the features used in this driver and has additional node properties that this SoC has compatibility, so enabling future implementations of these properties without the need to create new node properties in the device

[PATCH v5 3/3] pinctrl: bcm2835: Add support for output-low output-high properties

Properties to set initial value of pin output buffer. This can be useful for configure hardware in overlay files, and in early boot for checking it states in QA sanity tests. Signed-off-by: Matheus Castello --- drivers/pinctrl/bcm/pinctrl-bcm2835.c | 5 + 1 file

[PATCH v5 3/3] pinctrl: bcm2835: Add support for output-low output-high properties

Properties to set initial value of pin output buffer. This can be useful for configure hardware in overlay files, and in early boot for checking it states in QA sanity tests. Signed-off-by: Matheus Castello --- drivers/pinctrl/bcm/pinctrl-bcm2835.c | 5 + 1 file changed, 5 insertions(+)

[PATCH v5 1/3] dt-bindings: pinctrl: bcm2835-gpio: Add generic pinctrl support

Added generic pin configuration and multiplexing support, and should be preferred than brcm legacy one. Signed-off-by: Matheus Castello --- .../devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt | 18 ++ 1 file changed, 18 insertions(+) diff --git

[PATCH v5 1/3] dt-bindings: pinctrl: bcm2835-gpio: Add generic pinctrl support

Added generic pin configuration and multiplexing support, and should be preferred than brcm legacy one. Signed-off-by: Matheus Castello --- .../devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt | 18 ++ 1 file changed, 18 insertions(+) diff --git

Re: [PATCH v5 0/3] pinctrl: bcm2835: Add generic pinctrl support

This series adds support for generic binding for pinctrl bcm2835 driver, and add the code for set output buffer of a pin using the output-low and output-high generic properties. Tested on Raspberry Pi Zero W, based on bcm2835 SoC. Changes since v4: (Suggested by Rob Herring) - Change dt-bindings

Re: [PATCH v5 0/3] pinctrl: bcm2835: Add generic pinctrl support

This series adds support for generic binding for pinctrl bcm2835 driver, and add the code for set output buffer of a pin using the output-low and output-high generic properties. Tested on Raspberry Pi Zero W, based on bcm2835 SoC. Changes since v4: (Suggested by Rob Herring) - Change dt-bindings

[PATCH] sched/fair: remove stale comments about tg_unthrottle_up

After commit 82958366cfea ("sched: Replace update_shares weight distribution with per-entity computation"), tg_unthrottle_up did not update the weight Signed-off-by: Li RongQing --- kernel/sched/fair.c | 1 - 1 file changed, 1 deletion(-) diff --git a/kernel/sched/fair.c

[PATCH] sched/fair: remove stale comments about tg_unthrottle_up

After commit 82958366cfea ("sched: Replace update_shares weight distribution with per-entity computation"), tg_unthrottle_up did not update the weight Signed-off-by: Li RongQing --- kernel/sched/fair.c | 1 - 1 file changed, 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c

[PATCH] dt-bindings: pinctrl: sunxi: Fix reference to driver

Bindings describe hardware, not drivers. Use reference to hardware Allwinner A1X Pin Controller instead driver. Signed-off-by: Matheus Castello --- .../devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 6 +++--- 1 file changed, 3 insertions(+), 3

[PATCH] dt-bindings: pinctrl: sunxi: Fix reference to driver

Bindings describe hardware, not drivers. Use reference to hardware Allwinner A1X Pin Controller instead driver. Signed-off-by: Matheus Castello --- .../devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

Re: [PATCH v9 5/5] iommu/arm-smmu: Add support for qcom,smmu-v2 variant

Hi Yisheng, On 4/11/2018 6:52 AM, Yisheng Xie wrote: Hi Tomasz, On 2018/4/10 21:14, Tomasz Figa wrote: Hi Yisheng, Sorry, I think we missed your question here. On Wed, Mar 28, 2018 at 3:12 PM Yisheng Xie wrote: Hi Vivek, On 2018/3/28 12:37, Vivek Gautam wrote:

Re: [PATCH v9 5/5] iommu/arm-smmu: Add support for qcom,smmu-v2 variant

Hi Yisheng, On 4/11/2018 6:52 AM, Yisheng Xie wrote: Hi Tomasz, On 2018/4/10 21:14, Tomasz Figa wrote: Hi Yisheng, Sorry, I think we missed your question here. On Wed, Mar 28, 2018 at 3:12 PM Yisheng Xie wrote: Hi Vivek, On 2018/3/28 12:37, Vivek Gautam wrote: Hi Yisheng On 3/28/2018

Re: [PATCH] staging: comedi: cb_pcidas64: fix alignment of function parameters

On Tue, 10 Apr 2018, Gabriel Francisco Mandaji wrote: > Fix most checkpatch.pl issues of type: > > CHECK: Alignment should match open parenthesis > > Signed-off-by: Gabriel Francisco Mandaji > --- > drivers/staging/comedi/drivers/cb_pcidas64.c | 6 +++--- > 1 file

Re: [PATCH] staging: comedi: cb_pcidas64: fix alignment of function parameters

On Tue, 10 Apr 2018, Gabriel Francisco Mandaji wrote: > Fix most checkpatch.pl issues of type: > > CHECK: Alignment should match open parenthesis > > Signed-off-by: Gabriel Francisco Mandaji > --- > drivers/staging/comedi/drivers/cb_pcidas64.c | 6 +++--- > 1 file changed, 3 insertions(+), 3

Re: AMD graphics performance regression in 4.15 and later

>2018-04-11 6:00 GMT+02:00 Gabriel C : > 2018-04-09 11:42 GMT+02:00 Christian König : >> Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin: ... > I can help testing code for 4.17/++ if you wish but that is *different* > storry. > Quick tested

Re: AMD graphics performance regression in 4.15 and later

>2018-04-11 6:00 GMT+02:00 Gabriel C : > 2018-04-09 11:42 GMT+02:00 Christian König : >> Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin: ... > I can help testing code for 4.17/++ if you wish but that is *different* > storry. > Quick tested an 4.16.0-11490-gb284d4d5a678 , amdgpu and radeon driver

Re: [PATCH v3 2/4] gpio: pca953x: add register definitions for pcal6524 and fix address calculation

Hi Andy, > Am 10.04.2018 um 20:06 schrieb Andy Shevchenko : > > On Tue, Apr 10, 2018 at 7:07 PM, H. Nikolaus Schaller > wrote: >> PCAL chips ("L" seems to stand for "latched") have additional >> registers starting at address 0x40 to control the

Re: [PATCH v3 2/4] gpio: pca953x: add register definitions for pcal6524 and fix address calculation

Hi Andy, > Am 10.04.2018 um 20:06 schrieb Andy Shevchenko : > > On Tue, Apr 10, 2018 at 7:07 PM, H. Nikolaus Schaller > wrote: >> PCAL chips ("L" seems to stand for "latched") have additional >> registers starting at address 0x40 to control the latches, >> interrupt mask, pull-up and pull down

linux-next: Tree for Apr 11

Hi all, Please do not add any v4.18 destined stuff to your linux-next included trees until after v4.17-rc1 has been released. Changes since 20180410: The parisc-hd tree still had its build failure for which I applied a patch. Non-merge commits (relative to Linus' tree): 1234 1303 files

linux-next: Tree for Apr 11

Hi all, Please do not add any v4.18 destined stuff to your linux-next included trees until after v4.17-rc1 has been released. Changes since 20180410: The parisc-hd tree still had its build failure for which I applied a patch. Non-merge commits (relative to Linus' tree): 1234 1303 files

Re: [Letux-kernel] [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5

Hi Ladis, On Tue, 10 Apr 2018 22:56:43 +0200 Ladislav Michl wrote: > Hi Nikolaus, > > On Tue, Apr 10, 2018 at 06:25:17PM +0200, H. Nikolaus Schaller wrote: > > Hi, > > we just started testing the v4.16 kernel and found the > > device no longer bootable (works with v4.15).

Re: [Letux-kernel] [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5

Hi Ladis, On Tue, 10 Apr 2018 22:56:43 +0200 Ladislav Michl wrote: > Hi Nikolaus, > > On Tue, Apr 10, 2018 at 06:25:17PM +0200, H. Nikolaus Schaller wrote: > > Hi, > > we just started testing the v4.16 kernel and found the > > device no longer bootable (works with v4.15). It turned > > out

Re: [PATCH v3 1/4] gpio: pca953x: set the PCA_PCAL flag also when matching by DT

> Am 10.04.2018 um 20:10 schrieb Andy Shevchenko : > > #define PCA_LATCH_INT (PCA_PCAL | PCA_INT) Looks the best. I have queued it for v4. BR and thanks, Nikolaus

Re: [PATCH v3 1/4] gpio: pca953x: set the PCA_PCAL flag also when matching by DT

> Am 10.04.2018 um 20:10 schrieb Andy Shevchenko : > > #define PCA_LATCH_INT (PCA_PCAL | PCA_INT) Looks the best. I have queued it for v4. BR and thanks, Nikolaus

Re: [PATCH v5 1/5] mm: page_alloc: remain memblock_next_valid_pfn() on arm and arm64

On 4/2/2018 3:53 PM, Ard Biesheuvel Wrote: On 2 April 2018 at 09:49, Jia He wrote: On 4/2/2018 2:55 PM, Ard Biesheuvel Wrote: On 2 April 2018 at 04:30, Jia He wrote: Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns where

Re: [PATCH v5 1/5] mm: page_alloc: remain memblock_next_valid_pfn() on arm and arm64

On 4/2/2018 3:53 PM, Ard Biesheuvel Wrote: On 2 April 2018 at 09:49, Jia He wrote: On 4/2/2018 2:55 PM, Ard Biesheuvel Wrote: On 2 April 2018 at 04:30, Jia He wrote: Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns where possible") optimized the loop in

[PATCH] dm/raid1: Remove VLA usage

On the quest to remove all VLAs from the kernel[1], this avoids VLAs in dm-raid1.c by just using the maximum size for the stack arrays. The nr_mirrors value was already capped at 9, so this makes it a trivial adjustment to the array sizes. [1] https://lkml.org/lkml/2018/3/7/621 Signed-off-by:

[PATCH] dm/raid1: Remove VLA usage

On the quest to remove all VLAs from the kernel[1], this avoids VLAs in dm-raid1.c by just using the maximum size for the stack arrays. The nr_mirrors value was already capped at 9, so this makes it a trivial adjustment to the array sizes. [1] https://lkml.org/lkml/2018/3/7/621 Signed-off-by:

[RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

From: Ian W MORRISON As the Geminilake firmware is now merged to linux-firmware.git use MODUE_FIRMWARE to load the firmware. This removes the error message in the dmesg log: i915 :00:02.0: Direct firmware load for i915/glk_dmc_ver1_04.bin failed with

[RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

From: Ian W MORRISON As the Geminilake firmware is now merged to linux-firmware.git use MODUE_FIRMWARE to load the firmware. This removes the error message in the dmesg log: i915 :00:02.0: Direct firmware load for i915/glk_dmc_ver1_04.bin failed with error -2 i915

Re: [PATCH V7 00/13] drivers: Boot Constraint core

On 10-04-18, 15:40, Lucas Stach wrote: > Can you please describe how this bootconstraints core integration is > simpler than a "run things at max performance until late kernel init", > which could be triggered by a simple initcall similar to what is done > for clocks and regulators? > > To me the

Re: [PATCH V7 00/13] drivers: Boot Constraint core

On 10-04-18, 15:40, Lucas Stach wrote: > Can you please describe how this bootconstraints core integration is > simpler than a "run things at max performance until late kernel init", > which could be triggered by a simple initcall similar to what is done > for clocks and regulators? > > To me the

Re: [PATCH v5 01/10] drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs

Quoting Lina Iyer (2018-04-05 09:18:25) > Add controller driver for QCOM SoCs that have hardware based shared > resource management. The hardware IP known as RSC (Resource State > Coordinator) houses multiple Direct Resource Voter (DRV) for different > execution levels. A DRV is a unique voter on

Re: [PATCH v5 01/10] drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs

Quoting Lina Iyer (2018-04-05 09:18:25) > Add controller driver for QCOM SoCs that have hardware based shared > resource management. The hardware IP known as RSC (Resource State > Coordinator) houses multiple Direct Resource Voter (DRV) for different > execution levels. A DRV is a unique voter on

Re: [PATCH v2] cpufreq/schedutil: Cleanup, document and fix iowait boost

On 10-04-18, 16:59, Patrick Bellasi wrote: > The iowait boosting code has been recently updated to add a progressive > boosting behavior which allows to be less aggressive in boosting tasks > doing only sporadic IO operations, thus being more energy efficient for > example on mobile platforms. >

Re: [PATCH v2] cpufreq/schedutil: Cleanup, document and fix iowait boost

On 10-04-18, 16:59, Patrick Bellasi wrote: > The iowait boosting code has been recently updated to add a progressive > boosting behavior which allows to be less aggressive in boosting tasks > doing only sporadic IO operations, thus being more energy efficient for > example on mobile platforms. >

RE: [PATCH 0/8] Input: support for latest Lenovo thinkpads (series 80)

Hi Benjamin, -Original Message- From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com] Sent: Tuesday, April 10, 2018 3:35 PM To: 廖崇榮 Cc: Dmitry Torokhov; Oliver Haessler; Benjamin Berg; open list:HID CORE LAYER; lkml Subject: Re: [PATCH 0/8] Input: support for latest Lenovo

RE: [PATCH 0/8] Input: support for latest Lenovo thinkpads (series 80)

Hi Benjamin, -Original Message- From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com] Sent: Tuesday, April 10, 2018 3:35 PM To: 廖崇榮 Cc: Dmitry Torokhov; Oliver Haessler; Benjamin Berg; open list:HID CORE LAYER; lkml Subject: Re: [PATCH 0/8] Input: support for latest Lenovo

Re: update-binfmts breaking suspend

Ping? On Fri, Apr 06, 2018 at 07:43:55AM -0700, Matthew Wilcox wrote: > Pavel Machek wrote: > > > Failure is not a hang, as they expect, but... machine locks up, but > > > does not suspend, and then continues running after a delay.. > > > > > > [ 35.038766] PM: Syncing

Re: update-binfmts breaking suspend

Ping? On Fri, Apr 06, 2018 at 07:43:55AM -0700, Matthew Wilcox wrote: > Pavel Machek wrote: > > > Failure is not a hang, as they expect, but... machine locks up, but > > > does not suspend, and then continues running after a delay.. > > > > > > [ 35.038766] PM: Syncing filesystems ... done.

Re: [PATCH v2 7/9] trace_uprobe/sdt: Fix multiple update of same reference counter

Hi Oleg, On 04/10/2018 04:36 PM, Oleg Nesterov wrote: > Hi Ravi, > > On 04/10, Ravi Bangoria wrote: >>> and what if __mmu_notifier_register() fails simply because signal_pending() >>> == T? >>> see mm_take_all_locks(). >>> >>> at first glance this all look suspicious and sub-optimal, >> Yes. I

Re: [PATCH v2 7/9] trace_uprobe/sdt: Fix multiple update of same reference counter

Hi Oleg, On 04/10/2018 04:36 PM, Oleg Nesterov wrote: > Hi Ravi, > > On 04/10, Ravi Bangoria wrote: >>> and what if __mmu_notifier_register() fails simply because signal_pending() >>> == T? >>> see mm_take_all_locks(). >>> >>> at first glance this all look suspicious and sub-optimal, >> Yes. I

Re: Q: Can we get rid of __copy_siginfo_to_user32?

> On Apr 10, 2018, at 6:26 PM, Eric W. Biederman wrote: > > > Andy, > > I am looking at copy_siginfo_to_user32 and find it very unfortunate > that x86 with _sigchld_x32 needs to be the odd man out. I am looking > at ways to simplify the special case. > > The core of the

Re: Q: Can we get rid of __copy_siginfo_to_user32?

> On Apr 10, 2018, at 6:26 PM, Eric W. Biederman wrote: > > > Andy, > > I am looking at copy_siginfo_to_user32 and find it very unfortunate > that x86 with _sigchld_x32 needs to be the odd man out. I am looking > at ways to simplify the special case. > > The core of the special case comes from:

Re: [PATCH] MAINTAINERS: Update ASPEED entry with details

Hey Arnd, On 22 February 2018 at 15:33, Joel Stanley wrote: > I am interested in all ASPEED drivers, and the previous match wasn't > grabbing files in nested directories. Use N instead. > > Add the arm kernel mailing list so that patches get reviewed there, and > the linux-aspeed

Re: [PATCH] MAINTAINERS: Update ASPEED entry with details

Hey Arnd, On 22 February 2018 at 15:33, Joel Stanley wrote: > I am interested in all ASPEED drivers, and the previous match wasn't > grabbing files in nested directories. Use N instead. > > Add the arm kernel mailing list so that patches get reviewed there, and > the linux-aspeed list which

Re: AMD graphics performance regression in 4.15 and later

2018-04-09 11:42 GMT+02:00 Christian König : > Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin: >> >> Hi Christian, >> >> Thanks for the info. FYI, I've also opened a Firefox bug for that at: >> https://bugzilla.mozilla.org/show_bug.cgi?id=1448778 >> Feel free to

Re: AMD graphics performance regression in 4.15 and later

2018-04-09 11:42 GMT+02:00 Christian König : > Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin: >> >> Hi Christian, >> >> Thanks for the info. FYI, I've also opened a Firefox bug for that at: >> https://bugzilla.mozilla.org/show_bug.cgi?id=1448778 >> Feel free to comment since you have a better

[PATCH 2/2] module: Allow to always show the status of modsign

The sig_enforce parameter could be always shown to reflect the current status of modsign. For the case of CONFIG_MODULE_SIG_FORCE=y, this modification does nothing harmless. Signed-off-by: Jia Zhang --- kernel/module.c | 2 -- 1 file changed, 2 deletions(-) diff

[PATCH 2/2] module: Allow to always show the status of modsign

The sig_enforce parameter could be always shown to reflect the current status of modsign. For the case of CONFIG_MODULE_SIG_FORCE=y, this modification does nothing harmless. Signed-off-by: Jia Zhang --- kernel/module.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/kernel/module.c

[PATCH 1/2] module: Do not access sig_enforce directly

Call is_module_sig_enforced() instead. Signed-off-by: Jia Zhang --- kernel/module.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/module.c b/kernel/module.c index a6e43a5..f695474 100644 --- a/kernel/module.c +++ b/kernel/module.c @@

Re: [RFC PATCH 1/1] vmscan: Support multiple kswapd threads per node

> On Apr 3, 2018, at 12:07 PM, Matthew Wilcox wrote: > > On Tue, Apr 03, 2018 at 03:31:15PM +0200, Michal Hocko wrote: >> On Mon 02-04-18 09:24:22, Buddy Lumpkin wrote: >>> The presence of direct reclaims 10 years ago was a fairly reliable >>> indicator that too much was

[PATCH 1/2] module: Do not access sig_enforce directly

Call is_module_sig_enforced() instead. Signed-off-by: Jia Zhang --- kernel/module.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/module.c b/kernel/module.c index a6e43a5..f695474 100644 --- a/kernel/module.c +++ b/kernel/module.c @@ -2785,7 +2785,7 @@ static int

Re: [RFC PATCH 1/1] vmscan: Support multiple kswapd threads per node

> On Apr 3, 2018, at 12:07 PM, Matthew Wilcox wrote: > > On Tue, Apr 03, 2018 at 03:31:15PM +0200, Michal Hocko wrote: >> On Mon 02-04-18 09:24:22, Buddy Lumpkin wrote: >>> The presence of direct reclaims 10 years ago was a fairly reliable >>> indicator that too much was being asked of a Linux

[PATCH] spi: cadence: Add usleep_range() for cdns_spi_fill_tx_fifo()

In case of xspi work in busy condition, may send bytes failed. Add one bytes delay Signed-off-by: sxauwsk Signed-off-by: guojian Signed-off-by: wangshikai --- drivers/spi/spi-cadence.c |6 ++ 1 file changed, 6

[PATCH] spi: cadence: Add usleep_range() for cdns_spi_fill_tx_fifo()

In case of xspi work in busy condition, may send bytes failed. Add one bytes delay Signed-off-by: sxauwsk Signed-off-by: guojian Signed-off-by: wangshikai --- drivers/spi/spi-cadence.c |6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/spi/spi-cadence.c

Re: Regression caused by commit bc976233a872, ethernet r8169 stops working after system S3

Hi, On Apr 3, 2018, at 4:51 PM, Thomas Gleixner wrote: Bah. The patch is broken. New version written with brain awake below. Actually I can't reproduce this issue anymore on latest Linus' tree. I'll do a bisect and ask linux-stable maintainer to include the commit.

Re: Regression caused by commit bc976233a872, ethernet r8169 stops working after system S3

Hi, On Apr 3, 2018, at 4:51 PM, Thomas Gleixner wrote: Bah. The patch is broken. New version written with brain awake below. Actually I can't reproduce this issue anymore on latest Linus' tree. I'll do a bisect and ask linux-stable maintainer to include the commit. Thanks for your help!

Re: [PATCH v2] selftests/livepatch: introduce tests

Hi Joe, Thank you for the patch! Yet something to improve: [auto build test ERROR on v4.16] [also build test ERROR on next-20180410] [cannot apply to linus/master jikos-livepatching/for-next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url

Re: [PATCH v2] selftests/livepatch: introduce tests

Hi Joe, Thank you for the patch! Yet something to improve: [auto build test ERROR on v4.16] [also build test ERROR on next-20180410] [cannot apply to linus/master jikos-livepatching/for-next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url

[PATCH 1/2] isdn: hisax_fcpcipnp: Replace mdelay with usleep_range in fcpci_init

fcpci_init() is never called in atomic context. The call chain ending up at fcpci_init() is: [1] fcpci_init() <- fcpcipnp_setup() <- fcpnp_probe() fcpnp_probe() is set as ".probe" in struct pnp_driver. This function is not called in atomic context. Despite never getting called from atomic

[PATCH 1/2] isdn: hisax_fcpcipnp: Replace mdelay with usleep_range in fcpci_init

fcpci_init() is never called in atomic context. The call chain ending up at fcpci_init() is: [1] fcpci_init() <- fcpcipnp_setup() <- fcpnp_probe() fcpnp_probe() is set as ".probe" in struct pnp_driver. This function is not called in atomic context. Despite never getting called from atomic

Re: [PATCH v3 0/2] vhost: fix vhost_vq_access_ok() log check

On 2018年04月11日 10:35, Stefan Hajnoczi wrote: v3: * Rebased onto net/master and resolved conflict [DaveM] v2: * Rewrote the conditional to make the vq access check clearer [Linus] * Added Patch 2 to make the return type consistent and harder to misuse [Linus] The first patch fixes the

[PATCH 2/2] isdn: hisax_fcpcipnp: Replace mdelay with usleep_range in fcpcipnp_setup

fcpcipnp_setup() is never called in atomic context. The call chain ending up at fcpcipnp_setup() is: [1] fcpcipnp_setup() <- fcpnp_probe() fcpnp_probe() is set as ".probe" in struct pnp_driver. This function is not called in atomic context. Despite never getting called from atomic context,

Re: [PATCH v3 0/2] vhost: fix vhost_vq_access_ok() log check

On 2018年04月11日 10:35, Stefan Hajnoczi wrote: v3: * Rebased onto net/master and resolved conflict [DaveM] v2: * Rewrote the conditional to make the vq access check clearer [Linus] * Added Patch 2 to make the return type consistent and harder to misuse [Linus] The first patch fixes the

[PATCH 2/2] isdn: hisax_fcpcipnp: Replace mdelay with usleep_range in fcpcipnp_setup

fcpcipnp_setup() is never called in atomic context. The call chain ending up at fcpcipnp_setup() is: [1] fcpcipnp_setup() <- fcpnp_probe() fcpnp_probe() is set as ".probe" in struct pnp_driver. This function is not called in atomic context. Despite never getting called from atomic context,

[PATCH 3/3] media: dvb-usb: Replace GFP_ATOMIC with GFP_KERNEL in usb_isoc_urb_init

usb_isoc_urb_init() is never called in atomic context. The call chains ending up at usb_isoc_urb_init() are: [1] usb_isoc_urb_init() <- usb_urb_init() <- dvb_usb_adapter_stream_init() <- dvb_usb_adapter_init <- dvb_usb_init() <- dvb_usb_device_init() <- xxx_probe() xxx_probe

[PATCH 3/3] media: dvb-usb: Replace GFP_ATOMIC with GFP_KERNEL in usb_isoc_urb_init

usb_isoc_urb_init() is never called in atomic context. The call chains ending up at usb_isoc_urb_init() are: [1] usb_isoc_urb_init() <- usb_urb_init() <- dvb_usb_adapter_stream_init() <- dvb_usb_adapter_init <- dvb_usb_init() <- dvb_usb_device_init() <- xxx_probe() xxx_probe

Re: [PATCH] selftests/filesystems: Don't run dnotify_test by default

Shuah Khan writes: > On 04/10/2018 03:45 AM, Christian Brauner wrote: >> On Tue, Apr 10, 2018 at 04:20:53PM +1000, Michael Ellerman wrote: >>> In commit ce290a19609d ("selftests: add devpts selftests"), the >>> filesystems directory was added to the top-level selftests

Re: [PATCH] selftests/filesystems: Don't run dnotify_test by default

Shuah Khan writes: > On 04/10/2018 03:45 AM, Christian Brauner wrote: >> On Tue, Apr 10, 2018 at 04:20:53PM +1000, Michael Ellerman wrote: >>> In commit ce290a19609d ("selftests: add devpts selftests"), the >>> filesystems directory was added to the top-level selftests Makefile. >>> >>> That had

[PATCH 2/3] media: dvb-usb: Replace GFP_ATOMIC with GFP_KERNEL in usb_bulk_urb_init

usb_bulk_urb_init() is never called in atomic context. The call chains ending up at usb_bulk_urb_init() are: [1] usb_bulk_urb_init() <- usb_urb_init() <- dvb_usb_adapter_stream_init() <- dvb_usb_adapter_init <- dvb_usb_init() <- dvb_usb_device_init() <- xxx_probe() xxx_probe

[PATCH 2/3] media: dvb-usb: Replace GFP_ATOMIC with GFP_KERNEL in usb_bulk_urb_init

usb_bulk_urb_init() is never called in atomic context. The call chains ending up at usb_bulk_urb_init() are: [1] usb_bulk_urb_init() <- usb_urb_init() <- dvb_usb_adapter_stream_init() <- dvb_usb_adapter_init <- dvb_usb_init() <- dvb_usb_device_init() <- xxx_probe() xxx_probe

[PATCH 1/3] media: dvb-usb: Replace GFP_ATOMIC with GFP_KERNEL in usb_allocate_stream_buffers

usb_allocate_stream_buffers() is never called in atomic context. The call chains ending up at usb_allocate_stream_buffers() are: [1] usb_allocate_stream_buffers() <- usb_bulk_urb_init() <- usb_urb_init() <- dvb_usb_adapter_stream_init() <- dvb_usb_adapter_init <- dvb_usb_init()

[PATCH 1/3] media: dvb-usb: Replace GFP_ATOMIC with GFP_KERNEL in usb_allocate_stream_buffers

usb_allocate_stream_buffers() is never called in atomic context. The call chains ending up at usb_allocate_stream_buffers() are: [1] usb_allocate_stream_buffers() <- usb_bulk_urb_init() <- usb_urb_init() <- dvb_usb_adapter_stream_init() <- dvb_usb_adapter_init <- dvb_usb_init()

Re: [PATCH v3 1/3] resource: Use list_head to link resource sibling

On Tue, Apr 10, 2018 at 09:44:16PM +0800, Baoquan He wrote: >Hi Rob, > >Thanks a lot for looking into this and involve Nico to this thread! > >On 04/09/18 at 09:49am, Rob Herring wrote: >> +Nico who has been working on tinification of the kernel. >> >> On Mon, Apr 9, 2018 at 4:08 AM, Baoquan He

Re: [PATCH v3 1/3] resource: Use list_head to link resource sibling

On Tue, Apr 10, 2018 at 09:44:16PM +0800, Baoquan He wrote: >Hi Rob, > >Thanks a lot for looking into this and involve Nico to this thread! > >On 04/09/18 at 09:49am, Rob Herring wrote: >> +Nico who has been working on tinification of the kernel. >> >> On Mon, Apr 9, 2018 at 4:08 AM, Baoquan He

RE: Re: [RFC PATCH 2/2] ACPI/IORT: use swiotlb_dma_ops when smmu probe failed

> -Original Message- > From: linux-acpi-ow...@vger.kernel.org > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Robin Murphy > Sent: Monday, April 09, 2018 8:11 PM > To: Wang, Dongsheng ; Lorenzo Pieralisi > > Cc:

RE: Re: [RFC PATCH 2/2] ACPI/IORT: use swiotlb_dma_ops when smmu probe failed

> -Original Message- > From: linux-acpi-ow...@vger.kernel.org > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Robin Murphy > Sent: Monday, April 09, 2018 8:11 PM > To: Wang, Dongsheng ; Lorenzo Pieralisi > > Cc: r...@rjwysocki.net; gre...@linuxfoundation.org;

Re: [PATCH] writeback: safer lock nesting

On Tue, Apr 10, 2018 at 7:44 PM Wang Long wrote: > > Hi, > > > > [This is an automated email] > > > > This commit has been processed by the -stable helper bot and determined > > to be a high probability candidate for -stable trees. (score: 44.5575) > > > > The bot has

Re: [PATCH] writeback: safer lock nesting

On Tue, Apr 10, 2018 at 7:44 PM Wang Long wrote: > > Hi, > > > > [This is an automated email] > > > > This commit has been processed by the -stable helper bot and determined > > to be a high probability candidate for -stable trees. (score: 44.5575) > > > > The bot has tested the following trees:

Re: usercopy whitelist woe in scsi_sense_cache

On Tue, Apr 10, 2018 at 10:16 AM, Oleksandr Natalenko wrote: > Hi, Kees, Paolo et al. > > 10.04.2018 08:53, Kees Cook wrote: >> >> Unfortunately I only had a single hang with no dumps. I haven't been >> able to reproduce it since. :( > > > For your convenience I've

Re: usercopy whitelist woe in scsi_sense_cache

On Tue, Apr 10, 2018 at 10:16 AM, Oleksandr Natalenko wrote: > Hi, Kees, Paolo et al. > > 10.04.2018 08:53, Kees Cook wrote: >> >> Unfortunately I only had a single hang with no dumps. I haven't been >> able to reproduce it since. :( > > > For your convenience I've prepared a VM that contains a

Re: [virtio-dev] Re: [PATCH v2] virtio_balloon: export hugetlb page allocation counts

On 2018年04月10日 05:11, Jonathan Helman wrote: On 03/22/2018 07:38 PM, Jason Wang wrote: On 2018年03月22日 11:10, Michael S. Tsirkin wrote: On Thu, Mar 22, 2018 at 09:52:18AM +0800, Jason Wang wrote: On 2018年03月20日 12:26, Jonathan Helman wrote: On Mar 19, 2018, at 7:31 PM, Jason

Re: [virtio-dev] Re: [PATCH v2] virtio_balloon: export hugetlb page allocation counts

On 2018年04月10日 05:11, Jonathan Helman wrote: On 03/22/2018 07:38 PM, Jason Wang wrote: On 2018年03月22日 11:10, Michael S. Tsirkin wrote: On Thu, Mar 22, 2018 at 09:52:18AM +0800, Jason Wang wrote: On 2018年03月20日 12:26, Jonathan Helman wrote: On Mar 19, 2018, at 7:31 PM, Jason Wang 

  1   2   3   4   5   6   7   8   9   10   >