On Mon, Nov 19, 2018 at 07:59:24AM -0800, Daniel Colascione wrote:
> On Mon, Nov 19, 2018 at 2:32 AM, Christian Brauner
> wrote:
> > The kill() syscall operates on process identifiers. After a process has
> > exited its pid can be reused by another process. If a caller sends a signal
> > to a
On Mon, Nov 19, 2018 at 07:59:24AM -0800, Daniel Colascione wrote:
> On Mon, Nov 19, 2018 at 2:32 AM, Christian Brauner
> wrote:
> > The kill() syscall operates on process identifiers. After a process has
> > exited its pid can be reused by another process. If a caller sends a signal
> > to a
On 11/19/2018 07:00 AM, Thomas Gleixner wrote:
> On Fri, 16 Nov 2018, Tim Chen wrote:
>> +DEFINE_STATIC_KEY_FALSE(spectre_v2_app_lite);
>> +EXPORT_SYMBOL_GPL(spectre_v2_app_lite);
>
> Why would this be exported? The only usage site outside of this code is in
> tlb.c which is hardly modular.
That
On Sun, Nov 11, 2018 at 12:59:41PM +0800, Leo Yan wrote:
> As described in OpenCSD (CoreSight decoder lib), in the decoding stream
> it includes one trace element with type OCSD_GEN_TRC_ELEM_NO_SYNC; the
> element indicates 'either at start of decode, or after overflow / bad
> packet', we should
On 11/19/2018 07:00 AM, Thomas Gleixner wrote:
> On Fri, 16 Nov 2018, Tim Chen wrote:
>> +DEFINE_STATIC_KEY_FALSE(spectre_v2_app_lite);
>> +EXPORT_SYMBOL_GPL(spectre_v2_app_lite);
>
> Why would this be exported? The only usage site outside of this code is in
> tlb.c which is hardly modular.
That
On Sun, Nov 11, 2018 at 12:59:41PM +0800, Leo Yan wrote:
> As described in OpenCSD (CoreSight decoder lib), in the decoding stream
> it includes one trace element with type OCSD_GEN_TRC_ELEM_NO_SYNC; the
> element indicates 'either at start of decode, or after overflow / bad
> packet', we should
* Nathan Chancellor [181017 17:48]:
> When compiling the kernel with Clang, the following warning appears:
>
> arch/arm/boot/dts/omap3-gta04.dtsi:385:56: warning: '/*' within block comment
> [-Wcomment]
> /* OMAP3_CORE1_IOPAD(0x2194, PIN_INPUT | MUX_MODE0)
> /*
* Nathan Chancellor [181017 17:48]:
> When compiling the kernel with Clang, the following warning appears:
>
> arch/arm/boot/dts/omap3-gta04.dtsi:385:56: warning: '/*' within block comment
> [-Wcomment]
> /* OMAP3_CORE1_IOPAD(0x2194, PIN_INPUT | MUX_MODE0)
> /*
On Mon, Nov 19, 2018 at 11:11 AM Manivannan Sadhasivam
wrote:
>
> Add initial device tree for RDA8810PL SoC from RDA Microelectronics.
>
> Signed-off-by: Andreas Färber
> Signed-off-by: Manivannan Sadhasivam
> ---
> arch/arm/boot/dts/rda8810pl.dtsi | 95
> 1
On Mon, Nov 19, 2018 at 11:11 AM Manivannan Sadhasivam
wrote:
>
> Add initial device tree for RDA8810PL SoC from RDA Microelectronics.
>
> Signed-off-by: Andreas Färber
> Signed-off-by: Manivannan Sadhasivam
> ---
> arch/arm/boot/dts/rda8810pl.dtsi | 95
> 1
On Mon, Nov 19, 2018 at 06:10:53PM +0100, Eugene Syromiatnikov wrote:
> On Mon, Nov 19, 2018 at 11:32:39AM +0100, Christian Brauner wrote:
> > diff --git a/arch/x86/entry/syscalls/syscall_32.tbl
> > b/arch/x86/entry/syscalls/syscall_32.tbl
> > index 3cf7b533b3d1..e637eab883e9 100644
> > ---
On Mon, Nov 19, 2018 at 06:10:53PM +0100, Eugene Syromiatnikov wrote:
> On Mon, Nov 19, 2018 at 11:32:39AM +0100, Christian Brauner wrote:
> > diff --git a/arch/x86/entry/syscalls/syscall_32.tbl
> > b/arch/x86/entry/syscalls/syscall_32.tbl
> > index 3cf7b533b3d1..e637eab883e9 100644
> > ---
On Mon, Nov 19, 2018 at 07:32:33AM -0800, Andy Lutomirski wrote:
> On Mon, Nov 19, 2018 at 2:33 AM Christian Brauner
> wrote:
> >
> > With this patch an open() call on /proc/ will give userspace a handle
> > to struct pid of the process associated with /proc/. This allows to
> > maintain a
On Mon, Nov 19, 2018 at 07:32:33AM -0800, Andy Lutomirski wrote:
> On Mon, Nov 19, 2018 at 2:33 AM Christian Brauner
> wrote:
> >
> > With this patch an open() call on /proc/ will give userspace a handle
> > to struct pid of the process associated with /proc/. This allows to
> > maintain a
> On Nov 19, 2018, at 10:19 AM, Jarkko Sakkinen
> wrote:
>
>> On Mon, Nov 19, 2018 at 04:22:54PM +, Jethro Beekman wrote:
>>> On 2018-11-19 20:36, Jarkko Sakkinen wrote:
>>> Question: should be dissolve the driver completely and move this code to
>>> arch/x86/kernel/cpu/sgx/ (and rename
> On Nov 19, 2018, at 10:19 AM, Jarkko Sakkinen
> wrote:
>
>> On Mon, Nov 19, 2018 at 04:22:54PM +, Jethro Beekman wrote:
>>> On 2018-11-19 20:36, Jarkko Sakkinen wrote:
>>> Question: should be dissolve the driver completely and move this code to
>>> arch/x86/kernel/cpu/sgx/ (and rename
On 2018-11-08 12:12:52 [+0100], Paolo Bonzini wrote:
> On 07/11/2018 20:48, Sebastian Andrzej Siewior wrote:
> > index 375226055a413..5b33985d9f475 100644
> > --- a/arch/x86/kernel/fpu/xstate.c
> > +++ b/arch/x86/kernel/fpu/xstate.c
> > @@ -811,7 +811,7 @@ void fpu__resume_cpu(void)
> > *
> >
On 2018-11-08 12:12:52 [+0100], Paolo Bonzini wrote:
> On 07/11/2018 20:48, Sebastian Andrzej Siewior wrote:
> > index 375226055a413..5b33985d9f475 100644
> > --- a/arch/x86/kernel/fpu/xstate.c
> > +++ b/arch/x86/kernel/fpu/xstate.c
> > @@ -811,7 +811,7 @@ void fpu__resume_cpu(void)
> > *
> >
On Mon, Nov 19, 2018 at 6:10 AM, Muchun Song wrote:
> The elements of the heads array are a linked list of timer events that
> expire at the current time. And it can contain up to LVL_DEPTH levels
> and the lower the level represents the smaller the time granularity.
>
> Now the result is that
On Mon, Nov 19, 2018 at 6:10 AM, Muchun Song wrote:
> The elements of the heads array are a linked list of timer events that
> expire at the current time. And it can contain up to LVL_DEPTH levels
> and the lower the level represents the smaller the time granularity.
>
> Now the result is that
On 11/19/2018 11:28 AM, Greg Kroah-Hartman wrote:
> 3.18-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Prarit Bhargava
>
> [ Upstream commit f69ffc5d3db8f1f03fd6d1df5930f9a1fbd787b6 ]
Greg, as previously mentioned to Sasha, this
On 11/19/2018 11:28 AM, Greg Kroah-Hartman wrote:
> 3.18-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Prarit Bhargava
>
> [ Upstream commit f69ffc5d3db8f1f03fd6d1df5930f9a1fbd787b6 ]
Greg, as previously mentioned to Sasha, this
On Mon, Nov 19, 2018 at 2:32 AM Masahiro Yamada
wrote:
>
> The kernel can only be compiled with an optimization option (-O2, -Os,
> or the currently proposed -Og). Hence, __OPTIMIZE__ is always defined
> in the kernel source.
>
> The fallback for the -O0 case is just hypothetical and pointless.
>
On Mon, Nov 19, 2018 at 2:32 AM Masahiro Yamada
wrote:
>
> The kernel can only be compiled with an optimization option (-O2, -Os,
> or the currently proposed -Og). Hence, __OPTIMIZE__ is always defined
> in the kernel source.
>
> The fallback for the -O0 case is just hypothetical and pointless.
>
On Mon, Nov 19, 2018 at 05:04:10PM +0100, Sebastian Andrzej Siewior wrote:
> The sequence
>fpu->initialized = 1; /* step A */
>preempt_disable(); /* step B */
>fpu__restore(fpu);
>preempt_enable();
>
> is racy in regard to a context switch.
> For 32bit frames __fpu__restore_sig()
On Mon, Nov 19, 2018 at 05:04:10PM +0100, Sebastian Andrzej Siewior wrote:
> The sequence
>fpu->initialized = 1; /* step A */
>preempt_disable(); /* step B */
>fpu__restore(fpu);
>preempt_enable();
>
> is racy in regard to a context switch.
> For 32bit frames __fpu__restore_sig()
On 11/19/2018 06:57 AM, Peter Zijlstra wrote:
> On Fri, Nov 16, 2018 at 05:53:51PM -0800, Tim Chen wrote:
>> In later code, STIBP will be turned on/off in the context switch code
>> path when SMT is enabled. Checks for SMT is best
>> avoided on such hot paths.
>>
>> Create cpu_smt_enabled static
On 11/19/2018 06:57 AM, Peter Zijlstra wrote:
> On Fri, Nov 16, 2018 at 05:53:51PM -0800, Tim Chen wrote:
>> In later code, STIBP will be turned on/off in the context switch code
>> path when SMT is enabled. Checks for SMT is best
>> avoided on such hot paths.
>>
>> Create cpu_smt_enabled static
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: SivapiriyanKumarasamy
[ Upstream commit 30049754ab7c4b6148dd3cd64af7d54850604582 ]
[WHY]
Previously night light forced a full update by
applying a transfer function update regardless of if
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: SivapiriyanKumarasamy
[ Upstream commit 30049754ab7c4b6148dd3cd64af7d54850604582 ]
[WHY]
Previously night light forced a full update by
applying a transfer function update regardless of if
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Alexandru Ardelean
[ Upstream commit 4ee033301c898dd0835d035d0e0eb768a3d35da1 ]
Fixes commit 17be2a2905a6ec9aa27cd59521495e2f490d2af0 ("staging: iio:
ad7606: replace range/range_available
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Alexandru Ardelean
[ Upstream commit 4ee033301c898dd0835d035d0e0eb768a3d35da1 ]
Fixes commit 17be2a2905a6ec9aa27cd59521495e2f490d2af0 ("staging: iio:
ad7606: replace range/range_available
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Nicholas Mc Guire
[ Upstream commit c5d59528e24ad22500347b199d52b9368e686a42 ]
altera_hw_filt_init() which calls append_internal() assumes
that the node was successfully linked in while in
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Nicholas Mc Guire
[ Upstream commit c5d59528e24ad22500347b199d52b9368e686a42 ]
altera_hw_filt_init() which calls append_internal() assumes
that the node was successfully linked in while in
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Giridhar Malavali
commit bcc71cc3cde1468958a3ea859276d8d1a1a68265 upstream.
This patch fixes issue during switch command query where driver was freeing
SRB resources multiple times
Following
Hi gengdongjiu,
On 17/11/2018 15:41, gengdongjiu wrote:
> In the current kernel, it only handles three kinds of error, which is
> memory error, PCIE device and ARM process. But now the SMMU already
> support the RAS, how to handle the SMMU RAS error in the kernel?
What errors are being detected
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Giridhar Malavali
commit bcc71cc3cde1468958a3ea859276d8d1a1a68265 upstream.
This patch fixes issue during switch command query where driver was freeing
SRB resources multiple times
Following
Hi gengdongjiu,
On 17/11/2018 15:41, gengdongjiu wrote:
> In the current kernel, it only handles three kinds of error, which is
> memory error, PCIE device and ARM process. But now the SMMU already
> support the RAS, how to handle the SMMU RAS error in the kernel?
What errors are being detected
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Quinn Tran
commit 5c6400536481d9ef44ef94e7bf2c7b8e81534db7 upstream.
This patch fixes issue where driver clears NPort ID map instead of marking
handle in use. Once driver clears NPort ID from
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Quinn Tran
commit 5c6400536481d9ef44ef94e7bf2c7b8e81534db7 upstream.
This patch fixes issue where driver clears NPort ID map instead of marking
handle in use. Once driver clears NPort ID from
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Gao Xiang
[ Upstream commit 37ec35a6cc2b99eb7fd6b85b7d7b75dff46bc353 ]
This patch fixes a missing endian conversion in
vle_get_logical_extent_head.
Reviewed-by: Chao Yu
Signed-off-by: Gao
On 9 November 2018 at 06:27, Kishon Vijay Abraham I wrote:
> Hi Arnd,
>
> On 06/11/18 6:21 PM, Arnd Bergmann wrote:
>> On 11/5/18, Kishon Vijay Abraham I wrote:
>>> On 05/11/18 8:46 AM, Chunyan Zhang wrote:
+ sdhci_switch_extdma(host, true);
>>>
>>> A number of devices using
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Gao Xiang
[ Upstream commit 37ec35a6cc2b99eb7fd6b85b7d7b75dff46bc353 ]
This patch fixes a missing endian conversion in
vle_get_logical_extent_head.
Reviewed-by: Chao Yu
Signed-off-by: Gao
On 9 November 2018 at 06:27, Kishon Vijay Abraham I wrote:
> Hi Arnd,
>
> On 06/11/18 6:21 PM, Arnd Bergmann wrote:
>> On 11/5/18, Kishon Vijay Abraham I wrote:
>>> On 05/11/18 8:46 AM, Chunyan Zhang wrote:
+ sdhci_switch_extdma(host, true);
>>>
>>> A number of devices using
Hi,
On Mon, Nov 19, 2018 at 11:58:32AM +0200, Peter Ujfalusi wrote:
> On 2018-11-18 22:19, Aaro Koskinen wrote:
> > Tested on OMAP15XX/OMAP310 (Palm TE), OMAP1710 (Nokia 770)
> > and OMAP2420 (Nokia N810).
>
> Do you know if the DMA is enabled for the MMC? It might not work via
> DMAengine.
DMA
Hi,
On Mon, Nov 19, 2018 at 11:58:32AM +0200, Peter Ujfalusi wrote:
> On 2018-11-18 22:19, Aaro Koskinen wrote:
> > Tested on OMAP15XX/OMAP310 (Palm TE), OMAP1710 (Nokia 770)
> > and OMAP2420 (Nokia N810).
>
> Do you know if the DMA is enabled for the MMC? It might not work via
> DMAengine.
DMA
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Richard Weinberger
commit 0676b957c24bfb6e495449ba7b7e72c5b5d79233 upstream.
32bit UML used to define PTRACE_SYSEMU and PTRACE_SYSEMU_SINGLESTEP
own its own because many years ago not all
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Richard Weinberger
commit 0676b957c24bfb6e495449ba7b7e72c5b5d79233 upstream.
32bit UML used to define PTRACE_SYSEMU and PTRACE_SYSEMU_SINGLESTEP
own its own because many years ago not all
On Mon, Nov 12, 2018 at 01:55:19PM +0100, Artem Savkov wrote:
> Because find_symbol_by_name() traverses the same lists as read_symbols()
> changing sym->name in place without copying it affects the result of
> find_symbol_by_name() and, in case when ".cold" function precedes it's
> parent in
On Mon, Nov 12, 2018 at 01:55:19PM +0100, Artem Savkov wrote:
> Because find_symbol_by_name() traverses the same lists as read_symbols()
> changing sym->name in place without copying it affects the result of
> find_symbol_by_name() and, in case when ".cold" function precedes it's
> parent in
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Filipe Manana
commit 11023d3f5fdf89bba5e1142127701ca6e6014587 upstream.
If we attempt to deduplicate the last block of a file A into the middle of
a file B, and file A's size is not a
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Filipe Manana
commit 11023d3f5fdf89bba5e1142127701ca6e6014587 upstream.
If we attempt to deduplicate the last block of a file A into the middle of
a file B, and file A's size is not a
On Mon, Nov 19, 2018 at 4:37 AM Luc Van Oostenryck
wrote:
>
> On Mon, Nov 19, 2018 at 07:31:43PM +0900, Masahiro Yamada wrote:
> > The introduction of these dummy BUILD_BUG_ON stubs dates back to
> > commit 903c0c7cdc21 ("sparse: define dummy BUILD_BUG_ON definition
> > for sparse").
> >
> > At
* Nathan Chancellor [181017 17:54]:
> When building the kernel with Clang, the following section mismatch
> warning appears:
>
> WARNING: vmlinux.o(.text+0x38b3c): Section mismatch in reference from
> the function omap44xx_prm_late_init() to the function
>
On Mon, Nov 19, 2018 at 4:37 AM Luc Van Oostenryck
wrote:
>
> On Mon, Nov 19, 2018 at 07:31:43PM +0900, Masahiro Yamada wrote:
> > The introduction of these dummy BUILD_BUG_ON stubs dates back to
> > commit 903c0c7cdc21 ("sparse: define dummy BUILD_BUG_ON definition
> > for sparse").
> >
> > At
* Nathan Chancellor [181017 17:54]:
> When building the kernel with Clang, the following section mismatch
> warning appears:
>
> WARNING: vmlinux.o(.text+0x38b3c): Section mismatch in reference from
> the function omap44xx_prm_late_init() to the function
>
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Ard Biesheuvel
commit 6282e916f774e37845c65d1eae9f8c649004f033 upstream.
Due to what appears to be a copy/paste error, the opening ENTRY()
of cpu_v7_hvc_switch_mm() lacks a matching
* Nathan Chancellor [181017 17:52]:
> When building the kernel with Clang, the following section mismatch
> warnings appears:
>
> WARNING: vmlinux.o(.text+0x2d398): Section mismatch in reference from
> the function _setup() to the function .init.text:_setup_iclk_autoidle()
> The function
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Ard Biesheuvel
commit 6282e916f774e37845c65d1eae9f8c649004f033 upstream.
Due to what appears to be a copy/paste error, the opening ENTRY()
of cpu_v7_hvc_switch_mm() lacks a matching
* Nathan Chancellor [181017 17:52]:
> When building the kernel with Clang, the following section mismatch
> warnings appears:
>
> WARNING: vmlinux.o(.text+0x2d398): Section mismatch in reference from
> the function _setup() to the function .init.text:_setup_iclk_autoidle()
> The function
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Mike Kravetz
commit 5e41540c8a0f0e98c337dda8b391e5dda0cde7cf upstream.
This bug has been experienced several times by the Oracle DB team. The
BUG is in remove_inode_hugepages() as follows:
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Mike Kravetz
commit 5e41540c8a0f0e98c337dda8b391e5dda0cde7cf upstream.
This bug has been experienced several times by the Oracle DB team. The
BUG is in remove_inode_hugepages() as follows:
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Alex Deucher
commit d9997b64c52b70bd98c48f443f068253621d1ffc upstream.
This caused a confusing error message, but there is functionally
no problem since the default method is DIRECT.
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Alex Deucher
commit d9997b64c52b70bd98c48f443f068253621d1ffc upstream.
This caused a confusing error message, but there is functionally
no problem since the default method is DIRECT.
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Akshu Agrawal
commit 51ef434a15b450bfbef1e06cc87ee4e98a224486 upstream.
We observe black lines (underflow) on display when playing a
4K video with UVD. On Disabling Low memory P state this
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Akshu Agrawal
commit 51ef434a15b450bfbef1e06cc87ee4e98a224486 upstream.
We observe black lines (underflow) on display when playing a
4K video with UVD. On Disabling Low memory P state this
On Mon, Nov 12, 2018 at 01:55:18PM +0100, Artem Savkov wrote:
> If read_symbols() fails during second list traversal (the one dealing
> with ".cold" subfunctions) it frees the symbol, but never deletes it
> from the list/hash_table resulting in symbol being freed again in
> elf_close().
>
>
On 11/17/18 8:33 AM, Rob Herring wrote:
On Thu, Nov 08, 2018 at 05:50:07PM -0800, Atish Patra wrote:
cpu-map binding can be used to described cpu topology for both
RISC-V & ARM. It makes more sense to move the binding to document
to a common place.
The relevant discussion can be found here.
On 19/11/2018 17:09, Manivannan Sadhasivam wrote:
> Add clock driver for RDA Micro RDA8810PL SoC supporting OSTIMER
> and HWTIMER.
>
> Signed-off-by: Andreas Färber
> Signed-off-by: Manivannan Sadhasivam
> ---
> arch/arm/mach-rda/Kconfig | 1 +
> drivers/clocksource/Kconfig | 7
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Dmitry V. Levin
commit aba118389a6fb2ad7958de0f37b5869852bd38cf upstream.
Consistently use types provided by via
to fix the following linux/kfd_ioctl.h userspace compilation errors:
On Mon, Nov 12, 2018 at 01:55:18PM +0100, Artem Savkov wrote:
> If read_symbols() fails during second list traversal (the one dealing
> with ".cold" subfunctions) it frees the symbol, but never deletes it
> from the list/hash_table resulting in symbol being freed again in
> elf_close().
>
>
On 11/17/18 8:33 AM, Rob Herring wrote:
On Thu, Nov 08, 2018 at 05:50:07PM -0800, Atish Patra wrote:
cpu-map binding can be used to described cpu topology for both
RISC-V & ARM. It makes more sense to move the binding to document
to a common place.
The relevant discussion can be found here.
On 19/11/2018 17:09, Manivannan Sadhasivam wrote:
> Add clock driver for RDA Micro RDA8810PL SoC supporting OSTIMER
> and HWTIMER.
>
> Signed-off-by: Andreas Färber
> Signed-off-by: Manivannan Sadhasivam
> ---
> arch/arm/mach-rda/Kconfig | 1 +
> drivers/clocksource/Kconfig | 7
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Dmitry V. Levin
commit aba118389a6fb2ad7958de0f37b5869852bd38cf upstream.
Consistently use types provided by via
to fix the following linux/kfd_ioctl.h userspace compilation errors:
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Ville Syrjälä
commit df5e31c204b34e8d9e5ec33f5b28e960c4f25e14 upstream.
We're no longer programming any watermarks when we're disabling
a pipe. That means ilk_wm_merge() & co. will keep
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Ville Syrjälä
commit df5e31c204b34e8d9e5ec33f5b28e960c4f25e14 upstream.
We're no longer programming any watermarks when we're disabling
a pipe. That means ilk_wm_merge() & co. will keep
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Lyude Paul
commit 7c4512300cfa5a4dcc8c1c52ae61e3fa4bd11a39 upstream.
This hasn't caused any issues yet that I'm aware of, but as Ville
Syrjälä pointed out - we need to make sure that
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Lyude Paul
commit 7c4512300cfa5a4dcc8c1c52ae61e3fa4bd11a39 upstream.
This hasn't caused any issues yet that I'm aware of, but as Ville
Syrjälä pointed out - we need to make sure that
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Lyude Paul
commit 80c188695a77eddaa6e8885510ff4ef59fd478c3 upstream.
Currently we set intel_connector->mst_port to NULL to signify that the
MST port has been removed from the system so that
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Lyude Paul
commit 80c188695a77eddaa6e8885510ff4ef59fd478c3 upstream.
Currently we set intel_connector->mst_port to NULL to signify that the
MST port has been removed from the system so that
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Daniel Axtens
[ Upstream commit f5e284803a7206d43e26f9ffcae5de9626d95e37 ]
When enumerating page size definitions to check hardware support,
we construct a constant which is (1U <<
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Nicholas Piggin
[ Upstream commit b851ba02a6f3075f0f99c60c4bc30a4af80cf428 ]
The recent module relocation overflow crash demonstrated that we
have no range checking on REL32 relative
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Daniel Axtens
[ Upstream commit f5e284803a7206d43e26f9ffcae5de9626d95e37 ]
When enumerating page size definitions to check hardware support,
we construct a constant which is (1U <<
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Nicholas Piggin
[ Upstream commit b851ba02a6f3075f0f99c60c4bc30a4af80cf428 ]
The recent module relocation overflow crash demonstrated that we
have no range checking on REL32 relative
From: Kan Liang
The client IMC bandwidth events return very huge result.
perf stat -e uncore_imc/data_reads/ -e uncore_imc/data_writes/ -I
1 -a
10.000117222 34,788.76 MiB uncore_imc/data_reads/
10.000117222 8.26 MiB uncore_imc/data_writes/
20.000374584 34,842.89 MiB
From: Kan Liang
The client IMC bandwidth events return very huge result.
perf stat -e uncore_imc/data_reads/ -e uncore_imc/data_writes/ -I
1 -a
10.000117222 34,788.76 MiB uncore_imc/data_reads/
10.000117222 8.26 MiB uncore_imc/data_writes/
20.000374584 34,842.89 MiB
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Vasily Averin
commit cea5794122125bf67559906a0762186cf417099c upstream.
Fixes: 33afdcc5402d ("ext4: add a function which sets up group blocks ...")
Cc: sta...@kernel.org # 3.3
Signed-off-by:
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Vasily Averin
commit cea5794122125bf67559906a0762186cf417099c upstream.
Fixes: 33afdcc5402d ("ext4: add a function which sets up group blocks ...")
Cc: sta...@kernel.org # 3.3
Signed-off-by:
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Dan Williams
commit 3fa58dcab50a0aa16817f16a8d38aee869eb3fb9 upstream.
When the platform BIOS is unable to report all the media error records
it requires the OS to restart the scrub at a
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Scott Mayhew
commit 01310bb7c9c98752cc763b36532fab028e0f8f81 upstream.
Make sure we have a saved filehandle, otherwise we'll oops with a null
pointer dereference in
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Scott Mayhew
commit 01310bb7c9c98752cc763b36532fab028e0f8f81 upstream.
Make sure we have a saved filehandle, otherwise we'll oops with a null
pointer dereference in
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Dan Williams
commit 3fa58dcab50a0aa16817f16a8d38aee869eb3fb9 upstream.
When the platform BIOS is unable to report all the media error records
it requires the OS to restart the scrub at a
On 11/15/18 10:31 AM, Jeffrey Hugo wrote:
On 11/8/2018 6:50 PM, Atish Patra wrote:
The cpu-map DT entry in ARM64 can describe the CPU topology in
much better way compared to other existing approaches. RISC-V can
easily adopt this binding to represent it's own CPU topology.
Thus, both cpu-map DT
On 11/15/18 10:31 AM, Jeffrey Hugo wrote:
On 11/8/2018 6:50 PM, Atish Patra wrote:
The cpu-map DT entry in ARM64 can describe the CPU topology in
much better way compared to other existing approaches. RISC-V can
easily adopt this binding to represent it's own CPU topology.
Thus, both cpu-map DT
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Theodore Ts'o
commit 4f32c38b4662312dd3c5f113d8bdd459887fb773 upstream.
Fixes: b40971426a83 ("ext4: add error checking to calls to ...")
Reported-by: Vasily Averin
Signed-off-by: Theodore
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Theodore Ts'o
commit 4f32c38b4662312dd3c5f113d8bdd459887fb773 upstream.
Fixes: b40971426a83 ("ext4: add error checking to calls to ...")
Reported-by: Vasily Averin
Signed-off-by: Theodore
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Joel Stanley
[ Upstream commit ee9d21b3b3583712029a0db65a4b7c081d08d3b3 ]
When building with clang crt0's _zimage_start is not marked weak, which
breaks the build when linking the kernel
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Joel Stanley
[ Upstream commit ee9d21b3b3583712029a0db65a4b7c081d08d3b3 ]
When building with clang crt0's _zimage_start is not marked weak, which
breaks the build when linking the kernel
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Dengcheng Zhu
[ Upstream commit dc57aaf95a516f70e2d527d8287a0332c481a226 ]
After changing CPU online status, it will not be sent any IPIs such as in
__flush_cache_all() on software coherency
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Dengcheng Zhu
[ Upstream commit dc57aaf95a516f70e2d527d8287a0332c481a226 ]
After changing CPU online status, it will not be sent any IPIs such as in
__flush_cache_all() on software coherency
601 - 700 of 3448 matches
Mail list logo
