Re: [PATCH 9/9] Protect SELinux initialized state with pmalloc

Hi Igor, Thank you for the patch! Yet something to improve: [auto build test ERROR on mmotm/master] [also build test ERROR on v4.17-rc2] [cannot apply to next-20180423] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https

Re: [PATCH 9/9] Protect SELinux initialized state with pmalloc

Hi Igor, Thank you for the patch! Yet something to improve: [auto build test ERROR on mmotm/master] [also build test ERROR on v4.17-rc2] [cannot apply to next-20180423] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https

[PATCH] f2fs: give message and set need_fsck given broken node id

syzbot hit the following crash on upstream commit 83beed7b2b26f232d782127792dd0cd4362fdc41 (Fri Apr 20 17:56:32 2018 +) Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal syzbot dashboard link:

[PATCH] f2fs: give message and set need_fsck given broken node id

syzbot hit the following crash on upstream commit 83beed7b2b26f232d782127792dd0cd4362fdc41 (Fri Apr 20 17:56:32 2018 +) Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal syzbot dashboard link:

Re: [PATCH] Input: xen-kbdfront - allow better run-time configuration

On 04/23/2018 09:53 PM, Dmitry Torokhov wrote: On Thu, Apr 19, 2018 at 02:44:19PM +0300, Oleksandr Andrushchenko wrote: On 04/19/2018 02:25 PM, Juergen Gross wrote: On 18/04/18 17:04, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko It is now

Re: [PATCH] Input: xen-kbdfront - allow better run-time configuration

On 04/23/2018 09:53 PM, Dmitry Torokhov wrote: On Thu, Apr 19, 2018 at 02:44:19PM +0300, Oleksandr Andrushchenko wrote: On 04/19/2018 02:25 PM, Juergen Gross wrote: On 18/04/18 17:04, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko It is now only possible to control if

Re: [PATCH] proc/stat: Separate out individual irq counts into /proc/stat_irqs

On Sat, 21 Apr 2018, Alexey Dobriyan wrote: > > On Thu, Apr 19, 2018 at 04:23:02PM -0700, Joel Fernandes (Google) wrote: > > > Can we not just remove per-IRQ stats from /proc/stat (since I gather > > > from this discussion it isn't scalable), and just have applications > > > that need per-IRQ

Re: [PATCH] proc/stat: Separate out individual irq counts into /proc/stat_irqs

On Sat, 21 Apr 2018, Alexey Dobriyan wrote: > > On Thu, Apr 19, 2018 at 04:23:02PM -0700, Joel Fernandes (Google) wrote: > > > Can we not just remove per-IRQ stats from /proc/stat (since I gather > > > from this discussion it isn't scalable), and just have applications > > > that need per-IRQ

Re: [Xen-devel] [RFC 0/2] To introduce xenwatch multithreading (xen mtwatch)

Hi Juergen, On 04/24/2018 01:22 PM, Juergen Gross wrote: > On 24/04/18 01:55, Dongli Zhang wrote: >> Hi Wei, >> >> On 04/23/2018 10:09 PM, Wei Liu wrote: >>> On Sat, Apr 07, 2018 at 07:25:53PM +0800, Dongli Zhang wrote: About per-domU xenwatch thread create/destroy, a new type of xenstore

Re: [Xen-devel] [RFC 0/2] To introduce xenwatch multithreading (xen mtwatch)

Hi Juergen, On 04/24/2018 01:22 PM, Juergen Gross wrote: > On 24/04/18 01:55, Dongli Zhang wrote: >> Hi Wei, >> >> On 04/23/2018 10:09 PM, Wei Liu wrote: >>> On Sat, Apr 07, 2018 at 07:25:53PM +0800, Dongli Zhang wrote: About per-domU xenwatch thread create/destroy, a new type of xenstore

Re: [v2 00/10] arm/arm64: mediatek: Fix mmsys device probing

On Mon, 23 Apr 2018, matthias@kernel.org wrote: > From: Matthias Brugger > > Changes since v1: > - add binding documentation > - ddp: use regmap_update_bits > - ddp: ignore EPROBE_DEFER on clock probing > - mfd: delete mmsys_private > - add Reviewed-by and Acked-by tags

Re: [v2 00/10] arm/arm64: mediatek: Fix mmsys device probing

On Mon, 23 Apr 2018, matthias@kernel.org wrote: > From: Matthias Brugger > > Changes since v1: > - add binding documentation > - ddp: use regmap_update_bits > - ddp: ignore EPROBE_DEFER on clock probing > - mfd: delete mmsys_private > - add Reviewed-by and Acked-by tags I'm confused by the

[PATCH v2 2/3] lightnvm: pblk: garbage collect lines with failed writes

From: Hans Holmberg Write failures should not happen under normal circumstances, so in order to bring the chunk back into a known state as soon as possible, evacuate all the valid data out of the line and let the fw judge if the block can be written to in the next

[PATCH v2 2/3] lightnvm: pblk: garbage collect lines with failed writes

From: Hans Holmberg Write failures should not happen under normal circumstances, so in order to bring the chunk back into a known state as soon as possible, evacuate all the valid data out of the line and let the fw judge if the block can be written to in the next reset cycle. Do this by

[PATCH v2 1/3] lightnvm: pblk: rework write error recovery path

From: Hans Holmberg The write error recovery path is incomplete, so rework the write error recovery handling to do resubmits directly from the write buffer. When a write error occurs, the remaining sectors in the chunk are mapped out and invalidated and the request

[PATCH v2 1/3] lightnvm: pblk: rework write error recovery path

From: Hans Holmberg The write error recovery path is incomplete, so rework the write error recovery handling to do resubmits directly from the write buffer. When a write error occurs, the remaining sectors in the chunk are mapped out and invalidated and the request inserted in a resubmit list.

Re: [PATCH] mfd: tps65911-comparator: Fix a build error

On Fri, 20 Apr 2018, Dan Carpenter wrote: > In 2012, we changed the tps65910 API and fixed most drivers but forgot > to update this one. > > Fixes: 3f7e82759c69 ("mfd: Commonize tps65910 regmap access through header") > Signed-off-by: Dan Carpenter Applied, thanks.

Re: [PATCH] mfd: tps65911-comparator: Fix a build error

On Fri, 20 Apr 2018, Dan Carpenter wrote: > In 2012, we changed the tps65910 API and fixed most drivers but forgot > to update this one. > > Fixes: 3f7e82759c69 ("mfd: Commonize tps65910 regmap access through header") > Signed-off-by: Dan Carpenter Applied, thanks. -- Lee Jones [李琼斯] Linaro

Re: [PATCH v2] mfd: tps65911-comparator: Fix an off by one bug

On Mon, 23 Apr 2018, Dan Carpenter wrote: > I really don't want authorship credit for a patch that does: > > #define COMP1 0 > #define COMP2 1 > > It just makes me itch to look at it... As I say, I get where you're coming from, but it was the decision made by the H/W engineers. Doesn't mean

[PATCH v2 0/3] Rework write error handling in pblk

From: Hans Holmberg This patch series fixes the(currently incomplete) write error handling in pblk by: * queuing and re-submitting failed writes in the write buffer * evacuating valid data data in lines with write failures, so the chunk(s) with write failures

[PATCH v2 3/3] lightnvm: pblk: fix smeta write error path

From: Hans Holmberg Smeta write errors were previously ignored. Skip these lines instead and throw them back on the free list, so the chunks will go through a reset cycle before we attempt to use the line again. Signed-off-by: Hans Holmberg

Re: [PATCH v2] mfd: tps65911-comparator: Fix an off by one bug

On Mon, 23 Apr 2018, Dan Carpenter wrote: > I really don't want authorship credit for a patch that does: > > #define COMP1 0 > #define COMP2 1 > > It just makes me itch to look at it... As I say, I get where you're coming from, but it was the decision made by the H/W engineers. Doesn't mean

[PATCH v2 0/3] Rework write error handling in pblk

From: Hans Holmberg This patch series fixes the(currently incomplete) write error handling in pblk by: * queuing and re-submitting failed writes in the write buffer * evacuating valid data data in lines with write failures, so the chunk(s) with write failures can be reset to a known state

[PATCH v2 3/3] lightnvm: pblk: fix smeta write error path

From: Hans Holmberg Smeta write errors were previously ignored. Skip these lines instead and throw them back on the free list, so the chunks will go through a reset cycle before we attempt to use the line again. Signed-off-by: Hans Holmberg --- drivers/lightnvm/pblk-core.c | 7 --- 1 file

Re: [PATCH 1/6] powerpc/64s: Add barrier_nospec

On Tue, 24 Apr 2018 14:15:54 +1000 Michael Ellerman wrote: > From: Michal Suchanek > > A no-op form of ori (or immediate of 0 into r31 and the result stored > in r31) has been re-tasked as a speculation barrier. The instruction > only acts as a barrier

Re: [PATCH 1/6] powerpc/64s: Add barrier_nospec

On Tue, 24 Apr 2018 14:15:54 +1000 Michael Ellerman wrote: > From: Michal Suchanek > > A no-op form of ori (or immediate of 0 into r31 and the result stored > in r31) has been re-tasked as a speculation barrier. The instruction > only acts as a barrier on newer machines with appropriate

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

On 04/24/2018 01:41 AM, Boris Ostrovsky wrote: On 04/23/2018 08:10 AM, Oleksandr Andrushchenko wrote: On 04/23/2018 02:52 PM, Wei Liu wrote: On Fri, Apr 20, 2018 at 02:25:20PM +0300, Oleksandr Andrushchenko wrote: the gntdev. I think this is generic enough that it could be implemented

Re: [PATCH] rave-sp: Remove VLA

On Mon, 23 Apr 2018, Kyle Spiers wrote: > As part of the effort to remove VLAs from the kernel[1], this creates > constants for the checksum lengths of CCITT and 8B2C and changes > crc_calculated to be the maximum size of a checksum. > > https://lkml.org/lkml/2018/3/7/621 > > Signed-off-by:

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

On 04/24/2018 01:41 AM, Boris Ostrovsky wrote: On 04/23/2018 08:10 AM, Oleksandr Andrushchenko wrote: On 04/23/2018 02:52 PM, Wei Liu wrote: On Fri, Apr 20, 2018 at 02:25:20PM +0300, Oleksandr Andrushchenko wrote: the gntdev. I think this is generic enough that it could be implemented

Re: [PATCH] rave-sp: Remove VLA

On Mon, 23 Apr 2018, Kyle Spiers wrote: > As part of the effort to remove VLAs from the kernel[1], this creates > constants for the checksum lengths of CCITT and 8B2C and changes > crc_calculated to be the maximum size of a checksum. > > https://lkml.org/lkml/2018/3/7/621 > > Signed-off-by:

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaperunmap

On Tue, 24 Apr 2018, Tetsuo Handa wrote: > > > We can call __oom_reap_task_mm() from exit_mmap() (or __mmput()) before > > > exit_mmap() holds mmap_sem for write. Then, at least memory which could > > > have been reclaimed if exit_mmap() did not hold mmap_sem for write will > > > be guaranteed to

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaperunmap

On Tue, 24 Apr 2018, Tetsuo Handa wrote: > > > We can call __oom_reap_task_mm() from exit_mmap() (or __mmput()) before > > > exit_mmap() holds mmap_sem for write. Then, at least memory which could > > > have been reclaimed if exit_mmap() did not hold mmap_sem for write will > > > be guaranteed to

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

On 2018-04-24 00:38, Frank Rowand wrote: > Hi Jan, > > + Alan Tull for fpga perspective > > On 04/22/18 03:30, Jan Kiszka wrote: >> On 2018-04-11 07:42, Jan Kiszka wrote: >>> On 2018-04-05 23:12, Rob Herring wrote: On Thu, Apr 5, 2018 at 2:28 PM, Frank Rowand

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

On 2018-04-24 00:38, Frank Rowand wrote: > Hi Jan, > > + Alan Tull for fpga perspective > > On 04/22/18 03:30, Jan Kiszka wrote: >> On 2018-04-11 07:42, Jan Kiszka wrote: >>> 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

Re: [PATCH] mmc: mediatek: add 64G DRAM DMA support

Hi Chaotian, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.17-rc2 next-20180423] [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

Re: [PATCH] mmc: mediatek: add 64G DRAM DMA support

Hi Chaotian, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.17-rc2 next-20180423] [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

Re: [PATCH 9/9] ath10k: re-enable the firmware fallback mechanism for testmode

Andres Rodriguez writes: > The ath10k testmode uses request_firmware_direct() in order to avoid > producing firmware load warnings. Disabling the fallback mechanism was a > side effect of disabling warnings. > > We now have a new API that allows us to avoid warnings while

Re: [PATCH 3/5] powerpc: use time64_t in read_persistent_clock

Hi Arnd, I love your patch! Yet something to improve: [auto build test ERROR on powerpc/next] [also build test ERROR on v4.17-rc2 next-20180423] [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

Re: [PATCH 9/9] ath10k: re-enable the firmware fallback mechanism for testmode

Andres Rodriguez writes: > The ath10k testmode uses request_firmware_direct() in order to avoid > producing firmware load warnings. Disabling the fallback mechanism was a > side effect of disabling warnings. > > We now have a new API that allows us to avoid warnings while keeping the > fallback

Re: [PATCH 3/5] powerpc: use time64_t in read_persistent_clock

Hi Arnd, I love your patch! Yet something to improve: [auto build test ERROR on powerpc/next] [also build test ERROR on v4.17-rc2 next-20180423] [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

Re: [PATCH 1/3] PM / devfreq: Actually support providing freq_table

On Mon 23 Apr 19:48 PDT 2018, Chanwoo Choi wrote: > Hi, > > On 2018??? 04??? 24??? 09:20, Bjorn Andersson wrote: > > The code in devfreq_add_device() handles the case where a freq_table is > > passed by the client, but then requests min and max frequences from > > the, in this case absent, opp

Re: [PATCH 1/3] PM / devfreq: Actually support providing freq_table

On Mon 23 Apr 19:48 PDT 2018, Chanwoo Choi wrote: > Hi, > > On 2018??? 04??? 24??? 09:20, Bjorn Andersson wrote: > > The code in devfreq_add_device() handles the case where a freq_table is > > passed by the client, but then requests min and max frequences from > > the, in this case absent, opp

Re: [RFC PATCH] kernel/sched/core: busy wait before going idle

On Mon, 23 Apr 2018 15:47:40 +0530 Pavan Kondeti wrote: > Hi Nick, > > On Sun, Apr 15, 2018 at 11:31:49PM +1000, Nicholas Piggin wrote: > > This is a quick hack for comments, but I've always wondered -- > > if we have a short term polling idle states in cpuidle for

Re: [RFC PATCH] kernel/sched/core: busy wait before going idle

On Mon, 23 Apr 2018 15:47:40 +0530 Pavan Kondeti wrote: > Hi Nick, > > On Sun, Apr 15, 2018 at 11:31:49PM +1000, Nicholas Piggin wrote: > > This is a quick hack for comments, but I've always wondered -- > > if we have a short term polling idle states in cpuidle for performance > > -- why not

Re: [PATCH] mfd: qcom-spmi-pmic: Add support for pm8005,pm8998,pmi8998

Hi, On Thu, Apr 19, 2018 at 4:00 PM, Stephen Boyd wrote: > diff --git a/drivers/mfd/qcom-spmi-pmic.c b/drivers/mfd/qcom-spmi-pmic.c > index 2022bdfa7ab4..0b26387c22e7 100644 > --- a/drivers/mfd/qcom-spmi-pmic.c > +++ b/drivers/mfd/qcom-spmi-pmic.c > @@ -39,6 +39,9 @@ >

Re: [PATCH] mfd: qcom-spmi-pmic: Add support for pm8005,pm8998,pmi8998

Hi, On Thu, Apr 19, 2018 at 4:00 PM, Stephen Boyd wrote: > diff --git a/drivers/mfd/qcom-spmi-pmic.c b/drivers/mfd/qcom-spmi-pmic.c > index 2022bdfa7ab4..0b26387c22e7 100644 > --- a/drivers/mfd/qcom-spmi-pmic.c > +++ b/drivers/mfd/qcom-spmi-pmic.c > @@ -39,6 +39,9 @@ > #define PM8916_SUBTYPE

Re: [PATCH] cpufreq: powernv: Fix the hardlockup by synchronus smp_call in timer interrupt

Hi, On 04/24/2018 10:40 AM, Stewart Smith wrote: > Shilpasri G Bhat writes: >> gpstate_timer_handler() uses synchronous smp_call to set the pstate >> on the requested core. This causes the below hard lockup: >> >> [c03fe566b320] [c01d5340]

Re: [PATCH] cpufreq: powernv: Fix the hardlockup by synchronus smp_call in timer interrupt

Hi, On 04/24/2018 10:40 AM, Stewart Smith wrote: > Shilpasri G Bhat writes: >> gpstate_timer_handler() uses synchronous smp_call to set the pstate >> on the requested core. This causes the below hard lockup: >> >> [c03fe566b320] [c01d5340] smp_call_function_single+0x110/0x180 >>

Re: [Xen-devel] [RFC 0/2] To introduce xenwatch multithreading (xen mtwatch)

On 24/04/18 01:55, Dongli Zhang wrote: > Hi Wei, > > On 04/23/2018 10:09 PM, Wei Liu wrote: >> On Sat, Apr 07, 2018 at 07:25:53PM +0800, Dongli Zhang wrote: >>> About per-domU xenwatch thread create/destroy, a new type of xenstore node >>> is >>> introduced: '/local/domain/0/mtwatch/'. >>> >>>

Re: [Xen-devel] [RFC 0/2] To introduce xenwatch multithreading (xen mtwatch)

On 24/04/18 01:55, Dongli Zhang wrote: > Hi Wei, > > On 04/23/2018 10:09 PM, Wei Liu wrote: >> On Sat, Apr 07, 2018 at 07:25:53PM +0800, Dongli Zhang wrote: >>> About per-domU xenwatch thread create/destroy, a new type of xenstore node >>> is >>> introduced: '/local/domain/0/mtwatch/'. >>> >>>

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaperunmap

> On Sun, 22 Apr 2018, Tetsuo Handa wrote: > > > > I'm wondering why you do not see oom killing of many processes if the > > > victim is a very large process that takes a long time to free memory in > > > exit_mmap() as I do because the oom reaper gives up trying to acquire > > > mm->mmap_sem

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaperunmap

> On Sun, 22 Apr 2018, Tetsuo Handa wrote: > > > > I'm wondering why you do not see oom killing of many processes if the > > > victim is a very large process that takes a long time to free memory in > > > exit_mmap() as I do because the oom reaper gives up trying to acquire > > > mm->mmap_sem

Re: [PATCH] cpufreq: powernv: Fix the hardlockup by synchronus smp_call in timer interrupt

Shilpasri G Bhat writes: > gpstate_timer_handler() uses synchronous smp_call to set the pstate > on the requested core. This causes the below hard lockup: > > [c03fe566b320] [c01d5340] smp_call_function_single+0x110/0x180 > (unreliable) >

Re: [PATCH] cpufreq: powernv: Fix the hardlockup by synchronus smp_call in timer interrupt

Shilpasri G Bhat writes: > gpstate_timer_handler() uses synchronous smp_call to set the pstate > on the requested core. This causes the below hard lockup: > > [c03fe566b320] [c01d5340] smp_call_function_single+0x110/0x180 > (unreliable) > [c03fe566b390] [c01d55e0]

Re: [PATCH] KVM: X86: Allow userspace to define the microcode version

On 24/04/2018 05:14, Konrad Rzeszutek Wilk wrote: > You would need to include the microcode version in the migration stream. > > But this brings another point - what if we want to manifest certain > new CPUID bits? You don't do that across migration. Generally if you want to do live migration

Re: [PATCH] KVM: X86: Allow userspace to define the microcode version

On 24/04/2018 05:14, Konrad Rzeszutek Wilk wrote: > You would need to include the microcode version in the migration stream. > > But this brings another point - what if we want to manifest certain > new CPUID bits? You don't do that across migration. Generally if you want to do live migration

linux-next: Tree for Apr 24

Hi all, News: There will be no linux-next release tomorrow. Changes since 20180423: Non-merge commits (relative to Linus' tree): 2197 1973 files changed, 81135 insertions(+), 37356 deletions(-) I have created

linux-next: Tree for Apr 24

Hi all, News: There will be no linux-next release tomorrow. Changes since 20180423: Non-merge commits (relative to Linus' tree): 2197 1973 files changed, 81135 insertions(+), 37356 deletions(-) I have created

Re: [PATCH 1/3] big key: get rid of stack array allocation

Hi Tycho, On Mon, Apr 23, 2018 at 07:03:19PM -0600, Tycho Andersen wrote: > We're interested in getting rid of all of the stack allocated arrays in the > kernel [1]. This patch simply hardcodes the iv length to match that of the > hardcoded cipher. > > [1]: https://lkml.org/lkml/2018/3/7/621 >

Re: [PATCH 1/3] big key: get rid of stack array allocation

Hi Tycho, On Mon, Apr 23, 2018 at 07:03:19PM -0600, Tycho Andersen wrote: > We're interested in getting rid of all of the stack allocated arrays in the > kernel [1]. This patch simply hardcodes the iv length to match that of the > hardcoded cipher. > > [1]: https://lkml.org/lkml/2018/3/7/621 >

Re: [PATCH v14 8/9] PCI/AER/DPC: Align FATAL error handling for AER and DPC

Hi Oza, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on v4.16] [cannot apply to pci/next linus/master v4.17-rc1 next-20180423] [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

[RFC PATCH] PCI/AER/DPC: pcie_do_fatal_recovery() can be static

Fixes: 3d7db543cb99 ("PCI/AER/DPC: Align FATAL error handling for AER and DPC") Signed-off-by: Fengguang Wu --- err.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c index 99d52a0..9d8d7ef 100644 ---

Re: [PATCH v14 8/9] PCI/AER/DPC: Align FATAL error handling for AER and DPC

Hi Oza, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on v4.16] [cannot apply to pci/next linus/master v4.17-rc1 next-20180423] [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

[RFC PATCH] PCI/AER/DPC: pcie_do_fatal_recovery() can be static

Fixes: 3d7db543cb99 ("PCI/AER/DPC: Align FATAL error handling for AER and DPC") Signed-off-by: Fengguang Wu --- err.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c index 99d52a0..9d8d7ef 100644 --- a/drivers/pci/pcie/err.c

[PATCH] cpufreq: powernv: Fix the hardlockup by synchronus smp_call in timer interrupt

gpstate_timer_handler() uses synchronous smp_call to set the pstate on the requested core. This causes the below hard lockup: [c03fe566b320] [c01d5340] smp_call_function_single+0x110/0x180 (unreliable) [c03fe566b390] [c01d55e0] smp_call_function_any+0x180/0x250

[PATCH] cpufreq: powernv: Fix the hardlockup by synchronus smp_call in timer interrupt

gpstate_timer_handler() uses synchronous smp_call to set the pstate on the requested core. This causes the below hard lockup: [c03fe566b320] [c01d5340] smp_call_function_single+0x110/0x180 (unreliable) [c03fe566b390] [c01d55e0] smp_call_function_any+0x180/0x250

Re: [PATCH net-next] net: init sk_cookie for inet socket

On Tue, Apr 24, 2018 at 12:09 AM, Eric Dumazet wrote: > > > On 04/23/2018 08:58 AM, David Miller wrote: >> From: Yafang Shao >> Date: Sun, 22 Apr 2018 21:50:04 +0800 >> >>> With sk_cookie we can identify a socket, that is very helpful for >>>

Re: [PATCH net-next] net: init sk_cookie for inet socket

On Tue, Apr 24, 2018 at 12:09 AM, Eric Dumazet wrote: > > > On 04/23/2018 08:58 AM, David Miller wrote: >> From: Yafang Shao >> Date: Sun, 22 Apr 2018 21:50:04 +0800 >> >>> With sk_cookie we can identify a socket, that is very helpful for >>> traceing and statistic, i.e. tcp tracepiont and ebpf.

Re: [PATCH net-next 0/4] mm,tcp: provide mmap_hook to solve lockdep issue

On 04/23/2018 07:04 PM, Andy Lutomirski wrote: > On Mon, Apr 23, 2018 at 2:38 PM, Eric Dumazet wrote: >> Hi Andy >> >> On 04/23/2018 02:14 PM, Andy Lutomirski wrote: > >>> I would suggest that you rework the interface a bit. First a user would >>> call mmap() on a TCP

Re: [PATCH net-next 0/4] mm,tcp: provide mmap_hook to solve lockdep issue

On 04/23/2018 07:04 PM, Andy Lutomirski wrote: > On Mon, Apr 23, 2018 at 2:38 PM, Eric Dumazet wrote: >> Hi Andy >> >> On 04/23/2018 02:14 PM, Andy Lutomirski wrote: > >>> I would suggest that you rework the interface a bit. First a user would >>> call mmap() on a TCP socket, which would

Re: [PATCH v6 03/17] media: rkisp1: Add user space ABI definitions

On Thu, Mar 8, 2018 at 6:48 PM Jacob Chen wrote: [snip] > +/** > + * struct cifisp_lsc_config - Configuration used by Lens shading correction > + * > + * refer to REF_01 for details > + */ > +struct cifisp_lsc_config { > + __u32 r_data_tbl[CIFISP_LSC_DATA_TBL_SIZE]; >

Re: [PATCH v6 03/17] media: rkisp1: Add user space ABI definitions

On Thu, Mar 8, 2018 at 6:48 PM Jacob Chen wrote: [snip] > +/** > + * struct cifisp_lsc_config - Configuration used by Lens shading correction > + * > + * refer to REF_01 for details > + */ > +struct cifisp_lsc_config { > + __u32 r_data_tbl[CIFISP_LSC_DATA_TBL_SIZE]; > + __u32

RE: [PATCH 6/6] devfreq: rk3399_dmc: register devfreq notification to dmc driver.

>From: Lin Huang > >Because dmc may also access the PMU_BUS_IDLE_REQ register, we need to >ensure that the pd driver and the dmc driver will not access at this >register at the same time. > >Signed-off-by: Lin Huang >Signed-off-by: Enric Balletbo i Serra

RE: [PATCH 6/6] devfreq: rk3399_dmc: register devfreq notification to dmc driver.

>From: Lin Huang > >Because dmc may also access the PMU_BUS_IDLE_REQ register, we need to >ensure that the pd driver and the dmc driver will not access at this >register at the same time. > >Signed-off-by: Lin Huang >Signed-off-by: Enric Balletbo i Serra >--- > > drivers/devfreq/rk3399_dmc.c

Re: [RFC PATCH v2 3/4] acpi: apei: Do not panic() when correctable errors are marked as fatal.

On 04/22/2018 05:48 AM, Borislav Petkov wrote: On Thu, Apr 19, 2018 at 05:55:08PM -0500, Alex G. wrote: How does such an error look like, in detail? It's green on the soft side, with lots of red accents, as well as some textured white shades: [ 51.414616] pciehp :b0:06.0:pcie204:

Re: [RFC PATCH v2 3/4] acpi: apei: Do not panic() when correctable errors are marked as fatal.

On 04/22/2018 05:48 AM, Borislav Petkov wrote: On Thu, Apr 19, 2018 at 05:55:08PM -0500, Alex G. wrote: How does such an error look like, in detail? It's green on the soft side, with lots of red accents, as well as some textured white shades: [ 51.414616] pciehp :b0:06.0:pcie204:

[PATCH 3/6] powerpc/64s: Patch barrier_nospec in modules

From: Michal Suchanek Note that unlike RFI which is patched only in kernel the nospec state reflects settings at the time the module was loaded. Iterating all modules and re-patching every time the settings change is not implemented. Based on lwsync patching. Signed-off-by:

[PATCH 3/6] powerpc/64s: Patch barrier_nospec in modules

From: Michal Suchanek Note that unlike RFI which is patched only in kernel the nospec state reflects settings at the time the module was loaded. Iterating all modules and re-patching every time the settings change is not implemented. Based on lwsync patching. Signed-off-by: Michal Suchanek

[PATCH 2/6] powerpc/64s: Add support for ori barrier_nospec patching

From: Michal Suchanek Based on the RFI patching. This is required to be able to disable the speculation barrier. Only one barrier type is supported and it does nothing when the firmware does not enable it. Also re-patching modules is not supported So the only meaningful thing

[PATCH 2/6] powerpc/64s: Add support for ori barrier_nospec patching

From: Michal Suchanek Based on the RFI patching. This is required to be able to disable the speculation barrier. Only one barrier type is supported and it does nothing when the firmware does not enable it. Also re-patching modules is not supported So the only meaningful thing that can be done

[PATCH 2/2] ata: ahci: mvebu: override ahci_stop_engine for mvebu AHCI

From: Evan Wang There is an issue(Errata Ref#226) that the SATA can not be detected via SATA Port-MultiPlayer(PMP) with following error log: ata1.15: PMP product ID mismatch ata1.15: SATA link up 6.0 Gbps (SStatus 133 SControl 300) ata1.15: Port Multiplier vendor

[PATCH 1/2] libahci: Allow drivers to override stop_engine

From: Evan Wang Marvell armada37xx, armada7k and armada8k share the same AHCI sata controller IP, and currently there is an issue (Errata Ref#226)that the SATA can not be detected via SATA Port-MultiPlayer(PMP). After debugging, the reason is found that the value of Port-x

[PATCH 2/2] ata: ahci: mvebu: override ahci_stop_engine for mvebu AHCI

From: Evan Wang There is an issue(Errata Ref#226) that the SATA can not be detected via SATA Port-MultiPlayer(PMP) with following error log: ata1.15: PMP product ID mismatch ata1.15: SATA link up 6.0 Gbps (SStatus 133 SControl 300) ata1.15: Port Multiplier vendor mismatch '0x1b4b'!='0x0'

[PATCH 1/2] libahci: Allow drivers to override stop_engine

From: Evan Wang Marvell armada37xx, armada7k and armada8k share the same AHCI sata controller IP, and currently there is an issue (Errata Ref#226)that the SATA can not be detected via SATA Port-MultiPlayer(PMP). After debugging, the reason is found that the value of Port-x FIS-based Switching

[PATCH 1/6] powerpc/64s: Add barrier_nospec

From: Michal Suchanek A no-op form of ori (or immediate of 0 into r31 and the result stored in r31) has been re-tasked as a speculation barrier. The instruction only acts as a barrier on newer machines with appropriate firmware support. On older CPUs it remains a harmless

[PATCH 6/6] powerpc/64: Use barrier_nospec in syscall entry

Our syscall entry is done in assembly so patch in an explicit barrier_nospec. Based on a patch by Michal Suchanek. Signed-off-by: Michal Suchanek Signed-off-by: Michael Ellerman --- mpe: Move the barrier to immediately prior to the vulnerable load,

[PATCH 5/6] powerpc: Use barrier_nospec in copy_from_user()

Based on the x86 commit doing the same. See commit 304ec1b05031 ("x86/uaccess: Use __uaccess_begin_nospec() and uaccess_try_nospec") and b3bbfb3fb5d2 ("x86: Introduce __uaccess_begin_nospec() and uaccess_try_nospec") for more detail. In all cases we are ordering the load from the potentially

[PATCH 6/6] powerpc/64: Use barrier_nospec in syscall entry

Our syscall entry is done in assembly so patch in an explicit barrier_nospec. Based on a patch by Michal Suchanek. Signed-off-by: Michal Suchanek Signed-off-by: Michael Ellerman --- mpe: Move the barrier to immediately prior to the vulnerable load, and add a comment trying to explain why.

[PATCH 5/6] powerpc: Use barrier_nospec in copy_from_user()

Based on the x86 commit doing the same. See commit 304ec1b05031 ("x86/uaccess: Use __uaccess_begin_nospec() and uaccess_try_nospec") and b3bbfb3fb5d2 ("x86: Introduce __uaccess_begin_nospec() and uaccess_try_nospec") for more detail. In all cases we are ordering the load from the potentially

[PATCH 1/6] powerpc/64s: Add barrier_nospec

From: Michal Suchanek A no-op form of ori (or immediate of 0 into r31 and the result stored in r31) has been re-tasked as a speculation barrier. The instruction only acts as a barrier on newer machines with appropriate firmware support. On older CPUs it remains a harmless no-op. Implement

[PATCH 4/6] powerpc/64s: Enable barrier_nospec based on firmware settings

From: Michal Suchanek Check what firmware told us and enable/disable the barrier_nospec as appropriate. We err on the side of enabling the barrier, as it's no-op on older systems, see the comment for more detail. Signed-off-by: Michael Ellerman ---

[PATCH 0/2] Allow drivers to override stop_engine

From: Evan Wang There maybe some special operations needed when stop engine for AHCI IP of different vendors, so it is necessary to override ahci_stop_engine() when stop the engine like overriding start_engine(). Evan Wang (2): libahci: Allow drivers to override

[PATCH 0/2] Allow drivers to override stop_engine

From: Evan Wang There maybe some special operations needed when stop engine for AHCI IP of different vendors, so it is necessary to override ahci_stop_engine() when stop the engine like overriding start_engine(). Evan Wang (2): libahci: Allow drivers to override stop_engine ata: ahci:

[PATCH 4/6] powerpc/64s: Enable barrier_nospec based on firmware settings

From: Michal Suchanek Check what firmware told us and enable/disable the barrier_nospec as appropriate. We err on the side of enabling the barrier, as it's no-op on older systems, see the comment for more detail. Signed-off-by: Michael Ellerman --- arch/powerpc/include/asm/setup.h | 1

Re: [PATCH 6/6] devfreq: rk3399_dmc: register devfreq notification to dmc driver.

Hi, On 2018년 04월 19일 19:40, Enric Balletbo i Serra wrote: > From: Lin Huang > > Because dmc may also access the PMU_BUS_IDLE_REQ register, we need to > ensure that the pd driver and the dmc driver will not access at this > register at the same time. > > Signed-off-by: Lin

Re: [PATCH 6/6] devfreq: rk3399_dmc: register devfreq notification to dmc driver.

Hi, On 2018년 04월 19일 19:40, Enric Balletbo i Serra wrote: > From: Lin Huang > > Because dmc may also access the PMU_BUS_IDLE_REQ register, we need to > ensure that the pd driver and the dmc driver will not access at this > register at the same time. > > Signed-off-by: Lin Huang >

[RFC v4 PATCH] mm: shmem: make stat.st_blksize return huge page size if THP is on

Since tmpfs THP was supported in 4.8, hugetlbfs is not the only filesystem with huge page support anymore. tmpfs can use huge page via THP when mounting by "huge=" mount option. When applications use huge page on hugetlbfs, it just need check the filesystem magic number, but it is not enough for

[RFC v4 PATCH] mm: shmem: make stat.st_blksize return huge page size if THP is on

Since tmpfs THP was supported in 4.8, hugetlbfs is not the only filesystem with huge page support anymore. tmpfs can use huge page via THP when mounting by "huge=" mount option. When applications use huge page on hugetlbfs, it just need check the filesystem magic number, but it is not enough for

Re: [PATCH 4/6] dt-bindings: devfreq: rk3399_dmc: remove interrupts as is not required.

Hi, On 2018년 04월 19일 19:40, Enric Balletbo i Serra wrote: > In ATF we already wait for DDR dvfs finish, so don't need to do this in > kernel, so remove the interrupts properties as is not longer required. > > Signed-off-by: Enric Balletbo i Serra > --- > >

Re: [PATCH 4/6] dt-bindings: devfreq: rk3399_dmc: remove interrupts as is not required.

Hi, On 2018년 04월 19일 19:40, Enric Balletbo i Serra wrote: > In ATF we already wait for DDR dvfs finish, so don't need to do this in > kernel, so remove the interrupts properties as is not longer required. > > Signed-off-by: Enric Balletbo i Serra > --- > >

  1   2   3   4   5   6   7   8   9   10   >