On 11/19/18 9:28 AM, Jarkko Sakkinen wrote:
> Ah, you are correct.
>
> You should add a boolean flag instead of introducing a new variable for
> holding amount that has been read because obviously one read operation
> is enough for backwards compatibility.
>
> The code could read the code to
On 11/19/18 9:28 AM, Jarkko Sakkinen wrote:
> Ah, you are correct.
>
> You should add a boolean flag instead of introducing a new variable for
> holding amount that has been read because obviously one read operation
> is enough for backwards compatibility.
>
> The code could read the code to
On Wed, Nov 14, 2018 at 11:04 AM Firoz Khan wrote:
> Adding a new table entry consisting of:
> - System call number.
> - ABI.
> - System call name.
> - Entry point name.
> - Compat entry name, if required.
>
> syscallhdr.sh and syscalltbl.sh will generate
On Wed, Nov 14, 2018 at 11:04 AM Firoz Khan wrote:
> Adding a new table entry consisting of:
> - System call number.
> - ABI.
> - System call name.
> - Entry point name.
> - Compat entry name, if required.
>
> syscallhdr.sh and syscalltbl.sh will generate
4.14-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.14-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.14-stable review patch. If anyone has any objections, please let me know.
--
From: Miklos Szeredi
commit 4c316f2f3ff315cb48efb7435621e5bfb81df96d upstream.
Otherwise fuse_dev_do_write() could come in and finish off the request, and
the set_bit(FR_SENT, ...) could trigger
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Miklos Szeredi
commit 4c316f2f3ff315cb48efb7435621e5bfb81df96d upstream.
Otherwise fuse_dev_do_write() could come in and finish off the request, and
the set_bit(FR_SENT, ...) could trigger
On Mon, Nov 19, 2018 at 9:56 PM Mike Rapoport wrote:
>
> On Mon, Nov 19, 2018 at 08:43:09PM +0530, Souptick Joarder wrote:
> > Hi Mike,
> >
> > On Sat, Nov 17, 2018 at 8:07 PM Matthew Wilcox wrote:
> > >
> > > On Sat, Nov 17, 2018 at 12:26:38PM +0530, Souptick Joarder wrote:
> > > > On Fri, Nov
On Mon, Nov 19, 2018 at 9:56 PM Mike Rapoport wrote:
>
> On Mon, Nov 19, 2018 at 08:43:09PM +0530, Souptick Joarder wrote:
> > Hi Mike,
> >
> > On Sat, Nov 17, 2018 at 8:07 PM Matthew Wilcox wrote:
> > >
> > > On Sat, Nov 17, 2018 at 12:26:38PM +0530, Souptick Joarder wrote:
> > > > On Fri, Nov
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Gustavo A. R. Silva
commit e9a2310fb689151166df7fd9971093362d34bd79 upstream.
There is a potential execution path in which function
platform_get_resource() returns NULL. If this happens,
we
On Mon, Nov 19, 2018 at 06:31:36PM +0100, Sebastian Andrzej Siewior wrote:
> I though about __fpregs_changes_begin() in the last patch of the commit:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/bigeasy/staging.git/commit/?h=x86_fpu_rtu_v4
Also a good spot - api.h talks about preemption
On Mon, Nov 19, 2018 at 06:31:36PM +0100, Sebastian Andrzej Siewior wrote:
> I though about __fpregs_changes_begin() in the last patch of the commit:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/bigeasy/staging.git/commit/?h=x86_fpu_rtu_v4
Also a good spot - api.h talks about preemption
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Gustavo A. R. Silva
commit e9a2310fb689151166df7fd9971093362d34bd79 upstream.
There is a potential execution path in which function
platform_get_resource() returns NULL. If this happens,
we
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Quinn Tran
commit f635e48e866ee1a47d2d42ce012fdcc07bf55853 upstream.
This patch initializes port speed so that firmware does not set lower
operating speed. Setting lower speed in firmware
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Quinn Tran
commit f635e48e866ee1a47d2d42ce012fdcc07bf55853 upstream.
This patch initializes port speed so that firmware does not set lower
operating speed. Setting lower speed in firmware
On 11/19/18 4:43 AM, Kalle Valo wrote:
Larry Finger writes:
@@ -1570,10 +1571,10 @@ static u16 b43_nphy_gen_load_samples(struct b43_wldev
*dev, u32 freq, u16 max,
angle = 0;
for (i = 0; i < len; i++) {
- samples[i] = b43_cordic(angle);
+ samples[i]
On 11/19/18 4:43 AM, Kalle Valo wrote:
Larry Finger writes:
@@ -1570,10 +1571,10 @@ static u16 b43_nphy_gen_load_samples(struct b43_wldev
*dev, u32 freq, u16 max,
angle = 0;
for (i = 0; i < len; i++) {
- samples[i] = b43_cordic(angle);
+ samples[i]
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Andrea Arcangeli
commit ac5b2c18911ffe95c08d69273917f90212cf5659 upstream.
THP allocation might be really disruptive when allocated on NUMA system
with the local node full or hard to reclaim.
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Andrea Arcangeli
commit ac5b2c18911ffe95c08d69273917f90212cf5659 upstream.
THP allocation might be really disruptive when allocated on NUMA system
with the local node full or hard to reclaim.
On Mon, 19 Nov 2018 12:41:10 +
vitor wrote:
> Hi Coling,
>
>
> Thanks for your report.
>
> On 16/11/18 18:42, Colin King wrote:
> > From: Colin Ian King
> >
> > The masking operation on status is using a bitwise 'or' rather than
> > a bitwise 'and' operator, and hence the result is
On Mon, 19 Nov 2018 12:41:10 +
vitor wrote:
> Hi Coling,
>
>
> Thanks for your report.
>
> On 16/11/18 18:42, Colin King wrote:
> > From: Colin Ian King
> >
> > The masking operation on status is using a bitwise 'or' rather than
> > a bitwise 'and' operator, and hence the result is
On Thu, Nov 15, 2018 at 07:00:07AM +0800, Aubrey Li wrote:
> Add a /proc//arch_state interface to expose per-task cpu specific
> state values.
>
> Exposing AVX-512 Hi16_ZMM registers usage is for the user space job
> scheduler to cluster AVX-512 using tasks together, because these tasks
> could
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Max Filippov
commit 40dc948f234b73497c3278875eb08a01d5854d3f upstream.
The bootloader may pass physical address of the boot parameters structure
to the MMUv3 kernel in the register a2. Code
On Thu, Nov 15, 2018 at 07:00:07AM +0800, Aubrey Li wrote:
> Add a /proc//arch_state interface to expose per-task cpu specific
> state values.
>
> Exposing AVX-512 Hi16_ZMM registers usage is for the user space job
> scheduler to cluster AVX-512 using tasks together, because these tasks
> could
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Max Filippov
commit 40dc948f234b73497c3278875eb08a01d5854d3f upstream.
The bootloader may pass physical address of the boot parameters structure
to the MMUv3 kernel in the register a2. Code
On 11/18/18 9:44 PM, Anshuman Khandual wrote:
> IIUC NUMA re-work in principle involves these functional changes
>
> 1. Enumerating compute and memory nodes in heterogeneous environment
> (short/medium term)
This patch set _does_ that, though.
> 2. Enumerating memory node attributes as seen
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Vasily Averin
commit 61a9c11e5e7a0dab5381afa5d9d4dd5ebf18f7a0 upstream.
Fixes: 01f795f9e0d6 ("ext4: add online resizing support for meta_bg ...")
Signed-off-by: Vasily Averin
Signed-off-by:
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Vasily Averin
commit 61a9c11e5e7a0dab5381afa5d9d4dd5ebf18f7a0 upstream.
Fixes: 01f795f9e0d6 ("ext4: add online resizing support for meta_bg ...")
Signed-off-by: Vasily Averin
Signed-off-by:
On 11/18/18 9:44 PM, Anshuman Khandual wrote:
> IIUC NUMA re-work in principle involves these functional changes
>
> 1. Enumerating compute and memory nodes in heterogeneous environment
> (short/medium term)
This patch set _does_ that, though.
> 2. Enumerating memory node attributes as seen
Manivannan,
On 19/11/2018 17:09, Manivannan Sadhasivam wrote:
> Add interrupt driver for RDA Micro RDA8810PL SoC.
>
> Signed-off-by: Andreas Färber
> Signed-off-by: Manivannan Sadhasivam
> ---
> arch/arm/mach-rda/Kconfig | 1 +
> drivers/irqchip/Kconfig| 4 ++
>
On Fri, 16 Nov 2018 19:09:36 PST (-0800), Olof Johansson wrote:
On Thu, Nov 8, 2018 at 11:32 AM Palmer Dabbelt wrote:
On Thu, 08 Nov 2018 11:07:00 PST (-0800), david.abdurachma...@gmail.com wrote:
> Fixes warning: 'struct module' declared inside parameter list will not be
> visible outside of
Manivannan,
On 19/11/2018 17:09, Manivannan Sadhasivam wrote:
> Add interrupt driver for RDA Micro RDA8810PL SoC.
>
> Signed-off-by: Andreas Färber
> Signed-off-by: Manivannan Sadhasivam
> ---
> arch/arm/mach-rda/Kconfig | 1 +
> drivers/irqchip/Kconfig| 4 ++
>
On Fri, 16 Nov 2018 19:09:36 PST (-0800), Olof Johansson wrote:
On Thu, Nov 8, 2018 at 11:32 AM Palmer Dabbelt wrote:
On Thu, 08 Nov 2018 11:07:00 PST (-0800), david.abdurachma...@gmail.com wrote:
> Fixes warning: 'struct module' declared inside parameter list will not be
> visible outside of
4.14-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.14-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.9-stable review patch. If anyone has any objections, please let me know.
--
From: Dominique Martinet
[ Upstream commit 62e3941776fea8678bb8120607039410b1b61a65 ]
p9stat_free is more of a cleanup function than a 'free' function as it
only frees the content of the struct;
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Dominique Martinet
[ Upstream commit 62e3941776fea8678bb8120607039410b1b61a65 ]
p9stat_free is more of a cleanup function than a 'free' function as it
only frees the content of the struct;
On 11/19/18 3:30 AM, Alexey Brodkin wrote:
> It turned out we used to use default implementation of sched_clock()
> from kernel/sched/clock.c which was as precise as 1/HZ, i.e.
> by default we had 10 msec granularity of time measurement.
>
> Now given ARC built-in timers are clocked with the same
On 11/12/2018 11:42 AM, Valentin Schneider wrote:
> Hi Steve,
>
> On 09/11/2018 12:50, Steve Sistare wrote:
>> From: Steve Sistare
>>
>> Define and initialize a sparse bitmap of overloaded CPUs, per
>> last-level-cache scheduling domain, for use by the CFS scheduling class.
>> Save a pointer to
On 11/19/18 3:30 AM, Alexey Brodkin wrote:
> It turned out we used to use default implementation of sched_clock()
> from kernel/sched/clock.c which was as precise as 1/HZ, i.e.
> by default we had 10 msec granularity of time measurement.
>
> Now given ARC built-in timers are clocked with the same
On 11/12/2018 11:42 AM, Valentin Schneider wrote:
> Hi Steve,
>
> On 09/11/2018 12:50, Steve Sistare wrote:
>> From: Steve Sistare
>>
>> Define and initialize a sparse bitmap of overloaded CPUs, per
>> last-level-cache scheduling domain, for use by the CFS scheduling class.
>> Save a pointer to
4.9-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 4dc69c1c1fff2f587f8e737e70b4a4e7565a5c94 ]
Using memcpy() from a string that is shorter than the length copied means
the destination buffer is being filled with arbitrary data from
4.9-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 4dc69c1c1fff2f587f8e737e70b4a4e7565a5c94 ]
Using memcpy() from a string that is shorter than the length copied means
the destination buffer is being filled with arbitrary data from
4.9-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.9-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
On Mon 19-11-18 15:10:16, Michal Hocko wrote:
[...]
> In other words. Why cannot we do the following?
Baoquan, this is certainly not the right fix but I would be really
curious whether it makes the problem go away.
> diff --git a/mm/migrate.c b/mm/migrate.c
> index f7e4bfdc13b7..7ccab29bcf9a
On 11/9/2018 12:38 PM, Valentin Schneider wrote:
> Hi Steve,
>
> On 09/11/2018 12:50, Steve Sistare wrote:
> [...]
>> @@ -482,6 +484,10 @@ static void update_top_cache_domain(int cpu)
>> dirty_sched_domain_sysctl(cpu);
>> destroy_sched_domains(tmp);
>>
>> +sd =
On 11/9/2018 12:38 PM, Valentin Schneider wrote:
> Hi Steve,
>
> On 09/11/2018 12:50, Steve Sistare wrote:
> [...]
>> @@ -482,6 +484,10 @@ static void update_top_cache_domain(int cpu)
>> dirty_sched_domain_sysctl(cpu);
>> destroy_sched_domains(tmp);
>>
>> +sd =
On Mon 19-11-18 15:10:16, Michal Hocko wrote:
[...]
> In other words. Why cannot we do the following?
Baoquan, this is certainly not the right fix but I would be really
curious whether it makes the problem go away.
> diff --git a/mm/migrate.c b/mm/migrate.c
> index f7e4bfdc13b7..7ccab29bcf9a
4.9-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit d06f8a2f1befb5a3d0aa660ab1c05e9b744456ea ]
Masking/unmasking the CPU UART irq in CP0_Status (and redirecting it to
other CPUs) may cause interrupts be lost, especially in
4.9-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit d06f8a2f1befb5a3d0aa660ab1c05e9b744456ea ]
Masking/unmasking the CPU UART irq in CP0_Status (and redirecting it to
other CPUs) may cause interrupts be lost, especially in
On 11/19/18 9:27 AM, Borislav Petkov wrote:
>>> I was really hoping for code comments. :)
>> I though we agreed to make those in the larger series because those
>> comments in __fpu__restore_sig() would be removed anyway (as part of the
>> series).
> Also, over local_bh_disable() does not really
On 11/9/2018 2:07 PM, Valentin Schneider wrote:
> Hi Steve,
>
> On 09/11/2018 12:50, Steve Sistare wrote:
>> Move the update of idle_stamp from idle_balance to the call site in
>> pick_next_task_fair, to prepare for a future patch that adds work to
>> pick_next_task_fair which must be included in
On 11/19/2018 11:53 AM, Keith Busch wrote:
On Mon, Nov 19, 2018 at 11:53:05AM -0500, Tyler Baicar wrote:
On Thu, Nov 15, 2018 at 8:49 PM Sinan Kaya wrote:
On 11/15/2018 3:16 PM, Alexandru Gagniuc wrote:
I've asked around a few people at Dell and they unanimously agree that
_OSC is the
On 11/19/18 9:27 AM, Borislav Petkov wrote:
>>> I was really hoping for code comments. :)
>> I though we agreed to make those in the larger series because those
>> comments in __fpu__restore_sig() would be removed anyway (as part of the
>> series).
> Also, over local_bh_disable() does not really
On 11/9/2018 2:07 PM, Valentin Schneider wrote:
> Hi Steve,
>
> On 09/11/2018 12:50, Steve Sistare wrote:
>> Move the update of idle_stamp from idle_balance to the call site in
>> pick_next_task_fair, to prepare for a future patch that adds work to
>> pick_next_task_fair which must be included in
On 11/19/2018 11:53 AM, Keith Busch wrote:
On Mon, Nov 19, 2018 at 11:53:05AM -0500, Tyler Baicar wrote:
On Thu, Nov 15, 2018 at 8:49 PM Sinan Kaya wrote:
On 11/15/2018 3:16 PM, Alexandru Gagniuc wrote:
I've asked around a few people at Dell and they unanimously agree that
_OSC is the
On 2018-11-19 18:27:43 [+0100], Borislav Petkov wrote:
> On Mon, Nov 19, 2018 at 06:11:29PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2018-11-19 09:02:45 [-0800], Dave Hansen wrote:
> > > On 11/19/18 8:04 AM, Sebastian Andrzej Siewior wrote:
> > > > v1…v2: A more verbose commit as message.
>
On 2018-11-19 18:27:43 [+0100], Borislav Petkov wrote:
> On Mon, Nov 19, 2018 at 06:11:29PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2018-11-19 09:02:45 [-0800], Dave Hansen wrote:
> > > On 11/19/18 8:04 AM, Sebastian Andrzej Siewior wrote:
> > > > v1…v2: A more verbose commit as message.
>
On Mon, Nov 19, 2018 at 06:22:02PM +0100, Andreas Färber wrote:
> Am 19.11.18 um 18:09 schrieb Manivannan Sadhasivam:
> > From: Andreas Färber
> >
> > RDA Microelectronics is a Chinese SoC manufacturer.
> >
> > Cc: serv...@rdamicro.com
> > Signed-off-by: Andreas Färber
>
> This one is lacking
On Mon, Nov 19, 2018 at 06:22:02PM +0100, Andreas Färber wrote:
> Am 19.11.18 um 18:09 schrieb Manivannan Sadhasivam:
> > From: Andreas Färber
> >
> > RDA Microelectronics is a Chinese SoC manufacturer.
> >
> > Cc: serv...@rdamicro.com
> > Signed-off-by: Andreas Färber
>
> This one is lacking
This patch adds __must_check annotations to kasan hooks that return a
pointer to make sure that a tagged pointer always gets propagated.
Suggested-by: Andrey Ryabinin
Signed-off-by: Andrey Konovalov
---
include/linux/kasan.h | 16 ++--
mm/kasan/common.c | 14 --
2
This commit adds rountines, that print tag-based KASAN error reports.
Those are quite similar to generic KASAN, the difference is:
1. The way tag-based KASAN finds the first bad shadow cell (with a
mismatching tag). Tag-based KASAN compares memory tags from the shadow
memory to the pointer
Tag-based KASAN inline instrumentation mode (which embeds checks of shadow
memory into the generated code, instead of inserting a callback) generates
a brk instruction when a tag mismatch is detected.
This commit adds a tag-based KASAN specific brk handler, that decodes the
immediate value passed
This patch adds __must_check annotations to kasan hooks that return a
pointer to make sure that a tagged pointer always gets propagated.
Suggested-by: Andrey Ryabinin
Signed-off-by: Andrey Konovalov
---
include/linux/kasan.h | 16 ++--
mm/kasan/common.c | 14 --
2
This commit adds rountines, that print tag-based KASAN error reports.
Those are quite similar to generic KASAN, the difference is:
1. The way tag-based KASAN finds the first bad shadow cell (with a
mismatching tag). Tag-based KASAN compares memory tags from the shadow
memory to the pointer
Tag-based KASAN inline instrumentation mode (which embeds checks of shadow
memory into the generated code, instead of inserting a callback) generates
a brk instruction when a tag mismatch is detected.
This commit adds a tag-based KASAN specific brk handler, that decodes the
immediate value passed
On Mon, Nov 19, 2018 at 08:44:49AM -0800, Tadeusz Struk wrote:
> On 11/19/18 5:58 AM, Jarkko Sakkinen wrote:
> > Please explain a scenario where "!ret_size" would no work given that
> > both size and partial_data have always positive value?
>
> Right, I only looked at the one line above before
On Mon, Nov 19, 2018 at 08:44:49AM -0800, Tadeusz Struk wrote:
> On 11/19/18 5:58 AM, Jarkko Sakkinen wrote:
> > Please explain a scenario where "!ret_size" would no work given that
> > both size and partial_data have always positive value?
>
> Right, I only looked at the one line above before
On Mon, Nov 19, 2018 at 06:11:29PM +0100, Sebastian Andrzej Siewior wrote:
> On 2018-11-19 09:02:45 [-0800], Dave Hansen wrote:
> > On 11/19/18 8:04 AM, Sebastian Andrzej Siewior wrote:
> > > v1…v2: A more verbose commit as message.
> >
> > I was really hoping for code comments. :)
>
> I though
On Mon, Nov 19, 2018 at 06:11:29PM +0100, Sebastian Andrzej Siewior wrote:
> On 2018-11-19 09:02:45 [-0800], Dave Hansen wrote:
> > On 11/19/18 8:04 AM, Sebastian Andrzej Siewior wrote:
> > > v1…v2: A more verbose commit as message.
> >
> > I was really hoping for code comments. :)
>
> I though
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Enric Balletbo i Serra
commit 665636b2940d0897c4130253467f5e8c42eea392 upstream.
Fixes the signedness bug returning '(-22)' on the return type by removing the
sanity checker in
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Enric Balletbo i Serra
commit 665636b2940d0897c4130253467f5e8c42eea392 upstream.
Fixes the signedness bug returning '(-22)' on the return type by removing the
sanity checker in
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Omar Sandoval
[ Upstream commit 1448a2a5360ae06f25e2edc61ae070dff5c0beb4 ]
If we fail to allocate the request queue for a disk, we still need to
free that disk, not just the previous ones.
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Omar Sandoval
[ Upstream commit 1448a2a5360ae06f25e2edc61ae070dff5c0beb4 ]
If we fail to allocate the request queue for a disk, we still need to
free that disk, not just the previous ones.
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Shaohua Li
[ Upstream commit d595567dc4f0c1d90685ec1e2e296e2cad2643ac ]
If we change the number of array's device after device is removed from array,
then add the device back to array, we can
Hi,
On Fri, Nov 16, 2018 at 7:21 PM Mark Brown wrote:
>
> The stub implementation of _set_load() returns a mode value which is
> within the bounds of valid return codes for success (the documentation
> just says that failures are negative error codes) but not sensible or
> what the actual
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Shaohua Li
[ Upstream commit d595567dc4f0c1d90685ec1e2e296e2cad2643ac ]
If we change the number of array's device after device is removed from array,
then add the device back to array, we can
Hi,
On Fri, Nov 16, 2018 at 7:21 PM Mark Brown wrote:
>
> The stub implementation of _set_load() returns a mode value which is
> within the bounds of valid return codes for success (the documentation
> just says that failures are negative error codes) but not sensible or
> what the actual
Am 19.11.18 um 18:09 schrieb Manivannan Sadhasivam:
> From: Andreas Färber
>
> RDA Microelectronics is a Chinese SoC manufacturer.
>
> Cc: serv...@rdamicro.com
> Signed-off-by: Andreas Färber
This one is lacking your Signed-off-by, all others that I was CC'ed on
had it.
Cheers,
Andreas
--
Am 19.11.18 um 18:09 schrieb Manivannan Sadhasivam:
> From: Andreas Färber
>
> RDA Microelectronics is a Chinese SoC manufacturer.
>
> Cc: serv...@rdamicro.com
> Signed-off-by: Andreas Färber
This one is lacking your Signed-off-by, all others that I was CC'ed on
had it.
Cheers,
Andreas
--
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Jeff Mahoney
commit 0be88e367fd8fbdb45257615d691f4675dda062f upstream.
We check whether any device the file system is using supports discard in
the ioctl call, but then we attempt to trim free
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Jeff Mahoney
commit 0be88e367fd8fbdb45257615d691f4675dda062f upstream.
We check whether any device the file system is using supports discard in
the ioctl call, but then we attempt to trim free
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 intel_sgx.c as main.c)? Swapping
> > patch removes the possibility to
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 intel_sgx.c as main.c)? Swapping
> > patch removes the possibility to
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Lukas Wunner
commit 746a923b863a1065ef77324e1e43f19b1a3eab5c upstream.
Commit 1e77d0a1ed74 ("genirq: Sanitize spurious interrupt detection of
threaded irqs") made detection of spurious
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Phil Elwell
[ Upstream commit 8344498721059754e09d30fe255a12dab8fb03ef ]
The SC16IS752 is a dual-channel device. The two channels are largely
independent, but the IRQ signals are wired
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Lukas Wunner
commit 746a923b863a1065ef77324e1e43f19b1a3eab5c upstream.
Commit 1e77d0a1ed74 ("genirq: Sanitize spurious interrupt detection of
threaded irqs") made detection of spurious
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Phil Elwell
[ Upstream commit 8344498721059754e09d30fe255a12dab8fb03ef ]
The SC16IS752 is a dual-channel device. The two channels are largely
independent, but the IRQ signals are wired
at 8:20 PM, Masahiro Yamada wrote:
> On Sat, Nov 17, 2018 at 6:02 AM Nadav Amit wrote:
>> From: Masahiro Yamada
>> Sent: November 16, 2018 at 7:45:45 AM GMT
>>> To: Nadav Amit
>>> Cc: Ingo Molnar , Michal Marek ,
>>> Thomas Gleixner , Borislav Petkov , H.
>>> Peter Anvin , X86 ML , Linux
at 8:20 PM, Masahiro Yamada wrote:
> On Sat, Nov 17, 2018 at 6:02 AM Nadav Amit wrote:
>> From: Masahiro Yamada
>> Sent: November 16, 2018 at 7:45:45 AM GMT
>>> To: Nadav Amit
>>> Cc: Ingo Molnar , Michal Marek ,
>>> Thomas Gleixner , Borislav Petkov , H.
>>> Peter Anvin , X86 ML , Linux
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Max Filippov
commit 4119ba211bc4f1bf638f41e50b7a0f329f58aa16 upstream.
This section collects all source .note.* sections together in the
vmlinux image. Without it .note.Linux section may be
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Max Filippov
commit 4119ba211bc4f1bf638f41e50b7a0f329f58aa16 upstream.
This section collects all source .note.* sections together in the
vmlinux image. Without it .note.Linux section may be
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Vasily Averin
commit feaf264ce7f8d54582e2f66eb82dd9dd124c94f3 upstream.
Fixes: d745a8c20c1f ("ext4: reduce contention on s_orphan_lock")
Fixes: 6e3617e579e0 ("ext4: Handle non empty on-disk
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Vasily Averin
commit feaf264ce7f8d54582e2f66eb82dd9dd124c94f3 upstream.
Fixes: d745a8c20c1f ("ext4: reduce contention on s_orphan_lock")
Fixes: 6e3617e579e0 ("ext4: Handle non empty on-disk
On 11/19/18 8:04 AM, Sebastian Andrzej Siewior wrote:
> v1…v2: A more verbose commit as message.
I was really hoping for code comments. :)
On 11/19/18 8:04 AM, Sebastian Andrzej Siewior wrote:
> v1…v2: A more verbose commit as message.
I was really hoping for code comments. :)
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Finn Thain
[ Upstream commit fd47d919d0c336e7c22862b51ee94927ffea227a ]
If a target disconnects during a PIO data transfer the command may fail
when the target reconnects:
scsi host1: DMA
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Finn Thain
[ Upstream commit fd47d919d0c336e7c22862b51ee94927ffea227a ]
If a target disconnects during a PIO data transfer the command may fail
when the target reconnects:
scsi host1: DMA
701 - 800 of 3448 matches
Mail list logo
