On 10/15/18 4:26 PM, Alexander Duyck wrote:
> This change makes it so that we use the same approach that was already in
> use on Sparc on all the archtectures that support a 64b long.
>
> This is mostly motivated by the fact that 8 to 10 store/move instructions
> are likely always going to be
On 10/15/18 4:26 PM, Alexander Duyck wrote:
> This change makes it so that we use the same approach that was already in
> use on Sparc on all the archtectures that support a 64b long.
>
> This is mostly motivated by the fact that 8 to 10 store/move instructions
> are likely always going to be
On Mon, 15 Oct 2018 23:56:46 +0900
Masami Hiramatsu wrote:
> This patch looks good to me.
> But if the concern is real, all regs_get_kernel_stack_nth() user must move
> onto _safe() version, at least all tracers code.
Doing a git grep on regs_get_kernel_stack_nth(), I think you are right.
I'll
On Mon, 15 Oct 2018 23:56:46 +0900
Masami Hiramatsu wrote:
> This patch looks good to me.
> But if the concern is real, all regs_get_kernel_stack_nth() user must move
> onto _safe() version, at least all tracers code.
Doing a git grep on regs_get_kernel_stack_nth(), I think you are right.
I'll
On Fri, 12 Oct 2018 at 16:35, Greg Kroah-Hartman
wrote:
>
> On Thu, Oct 11, 2018 at 08:33:34PM +0100, Sudip Mukherjee wrote:
> > Hi Greg,
> >
> > On Thu, Oct 11, 2018 at 4:54 PM Greg Kroah-Hartman
> > wrote:
> > >
> > > 4.14-stable review patch. If anyone has any objections, please let me
> >
On Fri, 12 Oct 2018 at 16:35, Greg Kroah-Hartman
wrote:
>
> On Thu, Oct 11, 2018 at 08:33:34PM +0100, Sudip Mukherjee wrote:
> > Hi Greg,
> >
> > On Thu, Oct 11, 2018 at 4:54 PM Greg Kroah-Hartman
> > wrote:
> > >
> > > 4.14-stable review patch. If anyone has any objections, please let me
> >
Adding some people to the CC list.
Em Mon, Oct 15, 2018 at 04:02:46PM -0700, David Miller escreveu:
> From: Arnaldo Carvalho de Melo
> Date: Mon, 15 Oct 2018 19:25:46 -0300
> > But I think we should have it as a property of 'struct machine', because we
> > may
> > be processing on, say, x86,
Adding some people to the CC list.
Em Mon, Oct 15, 2018 at 04:02:46PM -0700, David Miller escreveu:
> From: Arnaldo Carvalho de Melo
> Date: Mon, 15 Oct 2018 19:25:46 -0300
> > But I think we should have it as a property of 'struct machine', because we
> > may
> > be processing on, say, x86,
On Tue, 16 Oct 2018 23:55:14 +0530
Sai Prakash Ranjan wrote:
> On 10/16/2018 11:46 PM, Steven Rostedt wrote:
> >
> > [ Removed ivan.iva...@linaro.org due to getting mail delivery errors ]
> >
> > On Tue, 16 Oct 2018 23:35:00 +0530
> > Sai Prakash Ranjan wrote:
> >
> >> Ok got it, this
On Tue, 16 Oct 2018 23:55:14 +0530
Sai Prakash Ranjan wrote:
> On 10/16/2018 11:46 PM, Steven Rostedt wrote:
> >
> > [ Removed ivan.iva...@linaro.org due to getting mail delivery errors ]
> >
> > On Tue, 16 Oct 2018 23:35:00 +0530
> > Sai Prakash Ranjan wrote:
> >
> >> Ok got it, this
On Tue, 16 Oct 2018 11:43:29 -0600
Shuah Khan wrote:
> On 10/16/2018 11:02 AM, Daniel Díaz wrote:
> > If test is being directly executed (with stdout opened on the
> > terminal) and the terminal capabilities indicate enough
> > colors, then use the existing scheme of green, red, and blue
> > to
On Tue, 16 Oct 2018 11:43:29 -0600
Shuah Khan wrote:
> On 10/16/2018 11:02 AM, Daniel Díaz wrote:
> > If test is being directly executed (with stdout opened on the
> > terminal) and the terminal capabilities indicate enough
> > colors, then use the existing scheme of green, red, and blue
> > to
On 10/16/18 19:03, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.18.15 release.
Gave this a try since I have r8169 NICs. Applied over .14 and now running
on three different machines. No observed regressions in dmesg or behaviour;
all smooth sailing.
cheers!
On 10/16/18 19:03, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.18.15 release.
Gave this a try since I have r8169 NICs. Applied over .14 and now running
on three different machines. No observed regressions in dmesg or behaviour;
all smooth sailing.
cheers!
On Wed, 10 Oct 2018 15:19:24 -0400
Mathieu Desnoyers wrote:
> + * vm_unmap_user_ram - unmap linear kernel address space set up by
> vm_map_user_ram
> + * @mem: the pointer returned by vm_map_user_ram
> + * @count: the count passed to that vm_map_user_ram call (cannot unmap
> partial)
> + */
>
On Wed, 10 Oct 2018 15:19:24 -0400
Mathieu Desnoyers wrote:
> + * vm_unmap_user_ram - unmap linear kernel address space set up by
> vm_map_user_ram
> + * @mem: the pointer returned by vm_map_user_ram
> + * @count: the count passed to that vm_map_user_ram call (cannot unmap
> partial)
> + */
>
Hi Peter,
> On Oct 15, 2018, at 3:09 PM, Song Liu wrote:
>
>
>
>> On Oct 15, 2018, at 1:34 AM, Peter Zijlstra wrote:
>>
>> On Mon, Oct 15, 2018 at 10:26:06AM +0300, Alexey Budankov wrote:
>>> Hi,
>>>
>>> On 10.10.2018 13:45, Peter Zijlstra wrote:
Hi all,
There have been
Hi Peter,
> On Oct 15, 2018, at 3:09 PM, Song Liu wrote:
>
>
>
>> On Oct 15, 2018, at 1:34 AM, Peter Zijlstra wrote:
>>
>> On Mon, Oct 15, 2018 at 10:26:06AM +0300, Alexey Budankov wrote:
>>> Hi,
>>>
>>> On 10.10.2018 13:45, Peter Zijlstra wrote:
Hi all,
There have been
> On Oct 16, 2018, at 11:10 AM, Peter Zijlstra wrote:
>
> On Tue, Oct 16, 2018 at 04:34:05PM +, Song Liu wrote:
3. perf_event_pmu_context owns RB tree of events. Since we don't
need rotation across multiple hardware PMUs, the rotation is
within same
> On Oct 16, 2018, at 11:10 AM, Peter Zijlstra wrote:
>
> On Tue, Oct 16, 2018 at 04:34:05PM +, Song Liu wrote:
3. perf_event_pmu_context owns RB tree of events. Since we don't
need rotation across multiple hardware PMUs, the rotation is
within same
On Dienstag, 16. Oktober 2018 18:14:18 CEST Colin King wrote:
> From: Colin Ian King
>
> Static analysis with CoverityScan is throwing warnings that specific
> case statements are missing breaks. Rather than adding breaks, add
> return -EINVAL to the specific case statements to clarify the
>
On Dienstag, 16. Oktober 2018 18:14:18 CEST Colin King wrote:
> From: Colin Ian King
>
> Static analysis with CoverityScan is throwing warnings that specific
> case statements are missing breaks. Rather than adding breaks, add
> return -EINVAL to the specific case statements to clarify the
>
On 10/16/2018 11:46 PM, Steven Rostedt wrote:
[ Removed ivan.iva...@linaro.org due to getting mail delivery errors ]
On Tue, 16 Oct 2018 23:35:00 +0530
Sai Prakash Ranjan wrote:
Ok got it, this sounds fun. I'll give it a try.
Awesome, I'm looking forward to seeing what you come up with.
On 10/16/2018 11:46 PM, Steven Rostedt wrote:
[ Removed ivan.iva...@linaro.org due to getting mail delivery errors ]
On Tue, 16 Oct 2018 23:35:00 +0530
Sai Prakash Ranjan wrote:
Ok got it, this sounds fun. I'll give it a try.
Awesome, I'm looking forward to seeing what you come up with.
Quoting Manu Gautam (2018-10-16 00:22:06)
> Fix HSTX_TRIM tuning logic which instead of using fused value
> as HSTX_TRIM, incorrectly performs bitwise OR operation with
> existing default value.
>
> Fixes: ca04d9d3e1b1 ("phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom
> chips")
>
Quoting Manu Gautam (2018-10-16 00:22:07)
> Tune1 register on sdm845 is used to update HSTX_TRIM with fused
> setting. Enable same by specifying update_tune1_with_efuse flag
> for sdm845, otherwise driver ends up programming tune2 register.
>
> Fixes: ef17f6e212ca ("phy: qcom-qusb2: Add QUSB2
Quoting Manu Gautam (2018-10-16 00:22:06)
> Fix HSTX_TRIM tuning logic which instead of using fused value
> as HSTX_TRIM, incorrectly performs bitwise OR operation with
> existing default value.
>
> Fixes: ca04d9d3e1b1 ("phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom
> chips")
>
Quoting Manu Gautam (2018-10-16 00:22:07)
> Tune1 register on sdm845 is used to update HSTX_TRIM with fused
> setting. Enable same by specifying update_tune1_with_efuse flag
> for sdm845, otherwise driver ends up programming tune2 register.
>
> Fixes: ef17f6e212ca ("phy: qcom-qusb2: Add QUSB2
On Tue, 2018-10-09 at 15:27 +0200, Håkon Bugge wrote:
> SMPs were not printed at all. Added printing of port number and TID to
> all MADs
>
>
> Håkon Bugge (2):
> IB/mlx4: Enable debug print of SMPs
> IB/mlx4: Add port and TID to MAD debug print
>
> drivers/infiniband/hw/mlx4/mad.c | 20
On Tue, 2018-10-09 at 15:27 +0200, Håkon Bugge wrote:
> SMPs were not printed at all. Added printing of port number and TID to
> all MADs
>
>
> Håkon Bugge (2):
> IB/mlx4: Enable debug print of SMPs
> IB/mlx4: Add port and TID to MAD debug print
>
> drivers/infiniband/hw/mlx4/mad.c | 20
The vlan configuration is not restored after interface donw/up sequence
(if dual-emac - both interfaces). Tested on am572x EVM.
Steps to check:
~# ip link add link eth1 name eth1.100 type vlan id 100
~# ifconfig eth0 down
~# ifconfig eth1 down
This is TI sdk tool, dumping all ALE entries, see
The vlan configuration is not restored after interface donw/up sequence
(if dual-emac - both interfaces). Tested on am572x EVM.
Steps to check:
~# ip link add link eth1 name eth1.100 type vlan id 100
~# ifconfig eth0 down
~# ifconfig eth1 down
This is TI sdk tool, dumping all ALE entries, see
Hello!
On Tue, 16 Oct 2018 at 12:43, Shuah Khan wrote:
> On 10/16/2018 11:02 AM, Daniel Díaz wrote:
> > If test is being directly executed (with stdout opened on the
> > terminal) and the terminal capabilities indicate enough
> > colors, then use the existing scheme of green, red, and blue
> >
Hello!
On Tue, 16 Oct 2018 at 12:43, Shuah Khan wrote:
> On 10/16/2018 11:02 AM, Daniel Díaz wrote:
> > If test is being directly executed (with stdout opened on the
> > terminal) and the terminal capabilities indicate enough
> > colors, then use the existing scheme of green, red, and blue
> >
Quoting Enric Balletbo i Serra (2018-10-16 06:41:44)
> Fixes the signedness bug returning '(-22)' on the return type by removing the
> sanity checker in rockchip_ddrclk_get_parent(). The function should return
> and unsigned value only and it's safe to remove the sanity checker as the
> core
Quoting Enric Balletbo i Serra (2018-10-16 06:41:44)
> Fixes the signedness bug returning '(-22)' on the return type by removing the
> sanity checker in rockchip_ddrclk_get_parent(). The function should return
> and unsigned value only and it's safe to remove the sanity checker as the
> core
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Addresses-Coverity-ID: 1195463 ("Missing break in switch")
Addresses-Coverity-ID: 1195464 ("Missing break in switch")
Addresses-Coverity-ID: 1195465 ("Missing break in switch")
On Tue, 2018-10-16 at 20:06 +0200, Slawomir Stepien wrote:
> On paź 15, 2018 18:25, Gabriel Capella wrote:
> > This patch adds 3 comments in 2 different files.
> > These comments warn to don't correct the checks of type:
> > "CHECK: spaces preferred around that '-'"
> >
> > Signed-off-by: Gabriel
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Addresses-Coverity-ID: 1195463 ("Missing break in switch")
Addresses-Coverity-ID: 1195464 ("Missing break in switch")
Addresses-Coverity-ID: 1195465 ("Missing break in switch")
On Tue, 2018-10-16 at 20:06 +0200, Slawomir Stepien wrote:
> On paź 15, 2018 18:25, Gabriel Capella wrote:
> > This patch adds 3 comments in 2 different files.
> > These comments warn to don't correct the checks of type:
> > "CHECK: spaces preferred around that '-'"
> >
> > Signed-off-by: Gabriel
[ Removed ivan.iva...@linaro.org due to getting mail delivery errors ]
On Tue, 16 Oct 2018 23:35:00 +0530
Sai Prakash Ranjan wrote:
> Ok got it, this sounds fun. I'll give it a try.
Awesome, I'm looking forward to seeing what you come up with.
-- Steve
[ Removed ivan.iva...@linaro.org due to getting mail delivery errors ]
On Tue, 16 Oct 2018 23:35:00 +0530
Sai Prakash Ranjan wrote:
> Ok got it, this sounds fun. I'll give it a try.
Awesome, I'm looking forward to seeing what you come up with.
-- Steve
Hi Dmitry,
On 10/16/18 7:21 PM, Dmitry Torokhov wrote:
> Hi Gustavo,
>
> On Tue, Oct 16, 2018 at 01:13:13PM +0200, Gustavo A. R. Silva wrote:
>> setup.code can be indirectly controlled by user-space, hence leading to
>> a potential exploitation of the Spectre variant 1 vulnerability.
>>
>> This
Hi Dmitry,
On 10/16/18 7:21 PM, Dmitry Torokhov wrote:
> Hi Gustavo,
>
> On Tue, Oct 16, 2018 at 01:13:13PM +0200, Gustavo A. R. Silva wrote:
>> setup.code can be indirectly controlled by user-space, hence leading to
>> a potential exploitation of the Spectre variant 1 vulnerability.
>>
>> This
On Tue, Oct 16, 2018 at 04:34:05PM +, Song Liu wrote:
> >> 3. perf_event_pmu_context owns RB tree of events. Since we don't
> >> need rotation across multiple hardware PMUs, the rotation is
> >> within same perf_event_pmu_context.
> >
> > By keeping the RB trees in perf_event_context,
On Tue, Oct 16, 2018 at 04:34:05PM +, Song Liu wrote:
> >> 3. perf_event_pmu_context owns RB tree of events. Since we don't
> >> need rotation across multiple hardware PMUs, the rotation is
> >> within same perf_event_pmu_context.
> >
> > By keeping the RB trees in perf_event_context,
On 10/16/18 8:09 PM, Dmitry Torokhov wrote:
>
> /dev/uinput
I've got it. This explains it all. :)
> must be 0600, or accessible to equally privileged user, or you'll be opening
> your system to much mischief.
>
Thanks, Dmitry.
--
Gustavo
On 10/16/18 8:09 PM, Dmitry Torokhov wrote:
>
> /dev/uinput
I've got it. This explains it all. :)
> must be 0600, or accessible to equally privileged user, or you'll be opening
> your system to much mischief.
>
Thanks, Dmitry.
--
Gustavo
On October 16, 2018 10:52:58 AM PDT, "Gustavo A. R. Silva"
wrote:
>Hi Dmitry,
>
>On 10/16/18 7:21 PM, Dmitry Torokhov wrote:
>> Hi Gustavo,
>>
>> On Tue, Oct 16, 2018 at 01:13:13PM +0200, Gustavo A. R. Silva wrote:
>>> setup.code can be indirectly controlled by user-space, hence leading
>to
>>>
Jiri,
Thanks for looking into this.
Yeah, I don't think you need a kernel patch to make this work.
You can poll in the app.
Let me try this out.
On Tue, Oct 16, 2018 at 9:25 AM Jiri Olsa wrote:
>
> On Tue, Oct 16, 2018 at 01:03:41PM +0200, Jiri Olsa wrote:
> > On Fri, Oct 12, 2018 at
On October 16, 2018 10:52:58 AM PDT, "Gustavo A. R. Silva"
wrote:
>Hi Dmitry,
>
>On 10/16/18 7:21 PM, Dmitry Torokhov wrote:
>> Hi Gustavo,
>>
>> On Tue, Oct 16, 2018 at 01:13:13PM +0200, Gustavo A. R. Silva wrote:
>>> setup.code can be indirectly controlled by user-space, hence leading
>to
>>>
Jiri,
Thanks for looking into this.
Yeah, I don't think you need a kernel patch to make this work.
You can poll in the app.
Let me try this out.
On Tue, Oct 16, 2018 at 9:25 AM Jiri Olsa wrote:
>
> On Tue, Oct 16, 2018 at 01:03:41PM +0200, Jiri Olsa wrote:
> > On Fri, Oct 12, 2018 at
On Tue, Oct 16, 2018 at 05:26:45PM +0100, Mark Rutland wrote:
> On Wed, Oct 10, 2018 at 12:45:59PM +0200, Peter Zijlstra wrote:
> > +struct perf_event_pmu_context {
> > + struct pmu *pmu;
> > + struct perf_event_context *ctx;
> > +
> > + struct list_head
On Tue, Oct 16, 2018 at 05:26:45PM +0100, Mark Rutland wrote:
> On Wed, Oct 10, 2018 at 12:45:59PM +0200, Peter Zijlstra wrote:
> > +struct perf_event_pmu_context {
> > + struct pmu *pmu;
> > + struct perf_event_context *ctx;
> > +
> > + struct list_head
On Mon, Oct 15, 2018 at 11:37:08AM +0200, Alessandro Rubini wrote:
> OTOH I admit you can compare any value with -EINVAL, after PTR_ERR.
> But in general you first detect the error condition and then split
> among error (or print a message according to the exact value.
if (IS_ERR(p) &&
On Mon, Oct 15, 2018 at 11:37:08AM +0200, Alessandro Rubini wrote:
> OTOH I admit you can compare any value with -EINVAL, after PTR_ERR.
> But in general you first detect the error condition and then split
> among error (or print a message according to the exact value.
if (IS_ERR(p) &&
On paź 15, 2018 18:25, Gabriel Capella wrote:
> This patch adds 3 comments in 2 different files.
> These comments warn to don't correct the checks of type:
> "CHECK: spaces preferred around that '-'"
>
> Signed-off-by: Gabriel Capella
> ---
> drivers/staging/iio/adc/ad7192.c | 1 +
>
On paź 15, 2018 18:25, Gabriel Capella wrote:
> This patch adds 3 comments in 2 different files.
> These comments warn to don't correct the checks of type:
> "CHECK: spaces preferred around that '-'"
>
> Signed-off-by: Gabriel Capella
> ---
> drivers/staging/iio/adc/ad7192.c | 1 +
>
On 10/16/2018 11:18 PM, Steven Rostedt wrote:
On Tue, 16 Oct 2018 23:06:24 +0530
Sai Prakash Ranjan wrote:
On 10/16/2018 10:27 PM, Steven Rostedt wrote:
OK, can you add to the command line:
ftrace=function ftrace_filter=*schedule*
to see if it's a specific function that may be causing
On 10/16/2018 11:18 PM, Steven Rostedt wrote:
On Tue, 16 Oct 2018 23:06:24 +0530
Sai Prakash Ranjan wrote:
On 10/16/2018 10:27 PM, Steven Rostedt wrote:
OK, can you add to the command line:
ftrace=function ftrace_filter=*schedule*
to see if it's a specific function that may be causing
On Tue, Oct 16, 2018 at 11:23:10AM +0200, Richard Leitner wrote:
> of_touchscreen.c provides a common interface for a axis invertion and
> swapping of touchscreens. Therefore use it in the sx8654 driver.
>
> Signed-off-by: Richard Leitner
> ---
> drivers/input/touchscreen/sx8654.c | 37
On Tue, Oct 16, 2018 at 11:23:10AM +0200, Richard Leitner wrote:
> of_touchscreen.c provides a common interface for a axis invertion and
> swapping of touchscreens. Therefore use it in the sx8654 driver.
>
> Signed-off-by: Richard Leitner
> ---
> drivers/input/touchscreen/sx8654.c | 37
Em Tue, Oct 16, 2018 at 02:49:23PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Mon, Oct 15, 2018 at 10:51:36PM +0200, Milian Wolff escreveu:
> > On Donnerstag, 11. Oktober 2018 21:39:20 CEST Arnaldo Carvalho de Melo
> > wrote:
> > > Em Thu, Oct 11, 2018 at 08:23:31PM +0200, Milian Wolff
Em Tue, Oct 16, 2018 at 02:49:23PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Mon, Oct 15, 2018 at 10:51:36PM +0200, Milian Wolff escreveu:
> > On Donnerstag, 11. Oktober 2018 21:39:20 CEST Arnaldo Carvalho de Melo
> > wrote:
> > > Em Thu, Oct 11, 2018 at 08:23:31PM +0200, Milian Wolff
Em Mon, Oct 15, 2018 at 10:51:36PM +0200, Milian Wolff escreveu:
> On Donnerstag, 11. Oktober 2018 21:39:20 CEST Arnaldo Carvalho de Melo wrote:
> > Em Thu, Oct 11, 2018 at 08:23:31PM +0200, Milian Wolff escreveu:
> > > On Donnerstag, 27. September 2018 21:10:37 CEST Arnaldo Carvalho de Melo
> > >
Em Mon, Oct 15, 2018 at 10:51:36PM +0200, Milian Wolff escreveu:
> On Donnerstag, 11. Oktober 2018 21:39:20 CEST Arnaldo Carvalho de Melo wrote:
> > Em Thu, Oct 11, 2018 at 08:23:31PM +0200, Milian Wolff escreveu:
> > > On Donnerstag, 27. September 2018 21:10:37 CEST Arnaldo Carvalho de Melo
> > >
On Tue, Oct 16, 2018 at 11:22:48AM +0200, Richard Leitner wrote:
> The sx8654 and sx8650 are quite similar, therefore add support for the
> sx8650 within the sx8654 driver.
>
> Signed-off-by: Richard Leitner
> ---
> drivers/input/touchscreen/sx8654.c | 186
>
On Tue, Oct 16, 2018 at 11:22:48AM +0200, Richard Leitner wrote:
> The sx8654 and sx8650 are quite similar, therefore add support for the
> sx8650 within the sx8654 driver.
>
> Signed-off-by: Richard Leitner
> ---
> drivers/input/touchscreen/sx8654.c | 186
>
On Tue, 16 Oct 2018 23:06:24 +0530
Sai Prakash Ranjan wrote:
> On 10/16/2018 10:27 PM, Steven Rostedt wrote:
> >
> > OK, can you add to the command line:
> >
> > ftrace=function ftrace_filter=*schedule*
> >
> > to see if it's a specific function that may be causing the issue (but
> >
On Tue, 16 Oct 2018 23:06:24 +0530
Sai Prakash Ranjan wrote:
> On 10/16/2018 10:27 PM, Steven Rostedt wrote:
> >
> > OK, can you add to the command line:
> >
> > ftrace=function ftrace_filter=*schedule*
> >
> > to see if it's a specific function that may be causing the issue (but
> >
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Jianfeng Tan
[ Upstream commit 9d2f67e43b73e8af7438be219b66a5de0cfa8bd9 ]
When we use raw socket as the vhost backend, a packet from virito with
gso offloading information, cannot be sent out
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit 64199fc0a46ba211362472f7f942f900af9492fd ]
Caching ip_hdr(skb) before a call to pskb_may_pull() is buggy,
do not do it.
Fixes: 2efd4fca703a ("ip: in cmsg
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Jianfeng Tan
[ Upstream commit 9d2f67e43b73e8af7438be219b66a5de0cfa8bd9 ]
When we use raw socket as the vhost backend, a packet from virito with
gso offloading information, cannot be sent out
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit 64199fc0a46ba211362472f7f942f900af9492fd ]
Caching ip_hdr(skb) before a call to pskb_may_pull() is buggy,
do not do it.
Fixes: 2efd4fca703a ("ip: in cmsg
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Jianbo Liu
[ Upstream commit cee26487620bc9bc3c7db21b6984d91f7bae12ae ]
In flow steering, if asked to, the hardware matches on the first ethertype
which is not vlan. It's possible to set a
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Jianbo Liu
[ Upstream commit cee26487620bc9bc3c7db21b6984d91f7bae12ae ]
In flow steering, if asked to, the hardware matches on the first ethertype
which is not vlan. It's possible to set a
This is the start of the stable review cycle for the 4.18.15 release.
There are 135 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Thu Oct 18 17:04:43 UTC 2018.
Anything
This is the start of the stable review cycle for the 4.18.15 release.
There are 135 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Thu Oct 18 17:04:43 UTC 2018.
Anything
On 10/16/2018 11:02 AM, Daniel Díaz wrote:
> If test is being directly executed (with stdout opened on the
> terminal) and the terminal capabilities indicate enough
> colors, then use the existing scheme of green, red, and blue
> to show when tests pass, fail or end in a different way.
>
> When
On 10/16/2018 11:02 AM, Daniel Díaz wrote:
> If test is being directly executed (with stdout opened on the
> terminal) and the terminal capabilities indicate enough
> colors, then use the existing scheme of green, red, and blue
> to show when tests pass, fail or end in a different way.
>
> When
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Roman Gushchin
[ Upstream commit 172b06c32b949759fe6313abec514bc4f15014f4 ]
9092c71bb724 ("mm: use sc->priority for slab shrink targets") changed the
way that the target slab pressure is
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Roman Gushchin
[ Upstream commit 172b06c32b949759fe6313abec514bc4f15014f4 ]
9092c71bb724 ("mm: use sc->priority for slab shrink targets") changed the
way that the target slab pressure is
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Jay Kamat
[ Upstream commit a987785dcd6c8ae2915460582aebd6481c81eb67 ]
Add tests for memory.oom.group for the following cases:
- Killing all processes in a leaf cgroup, but leaving the
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Jay Kamat
[ Upstream commit a987785dcd6c8ae2915460582aebd6481c81eb67 ]
Add tests for memory.oom.group for the following cases:
- Killing all processes in a leaf cgroup, but leaving the
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Dan Carpenter
[ Upstream commit cbe3fd39d223f14b1c60c80fe9347a3dd08c2edb ]
We should first do the le16_to_cpu endian conversion and then apply the
FCP_CMD_LENGTH_MASK mask.
Fixes:
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Dan Carpenter
[ Upstream commit cbe3fd39d223f14b1c60c80fe9347a3dd08c2edb ]
We should first do the le16_to_cpu endian conversion and then apply the
FCP_CMD_LENGTH_MASK mask.
Fixes:
Hi Fenghua,
On 10/16/2018 11:56 AM, Fenghua Yu wrote:
> With more and more resctrl features are being added by Intel, AMD
> and ARM, a test tool is becoming more and more useful to validate
> that both hardware and software functionalities work as expected.
I like the initiative here. It is
Hi Fenghua,
On 10/16/2018 11:56 AM, Fenghua Yu wrote:
> With more and more resctrl features are being added by Intel, AMD
> and ARM, a test tool is becoming more and more useful to validate
> that both hardware and software functionalities work as expected.
I like the initiative here. It is
Hi Lucas,
On 16/10/18 17:42, Lucas Stach wrote:
> The irqsteer block is a interrupt multiplexer/remapper found on the
> i.MX8 line of SoCs.
>
> Signed-off-by: Fugang Duan
> Signed-off-by: Lucas Stach
> ---
> This submission is a heavily cleaned up version of the downstream driver.
> ---
>
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Jérôme Glisse
commit bfba8e5cf28f413aa05571af493871d74438979f upstream.
Inside set_pmd_migration_entry() we are holding page table locks and thus
we can not sleep so we can not call
Hi Richard,
On Tue, Oct 16, 2018 at 11:16:48AM +0200, Richard Leitner wrote:
> The sx8654 features a NRST input which may be connected to a GPIO.
> Therefore add support for hard-resetting the sx8654 via this NRST.
>
> If the reset-gpio property is provided the sx8654 is resetted via NRST
>
Hi Lucas,
On 16/10/18 17:42, Lucas Stach wrote:
> The irqsteer block is a interrupt multiplexer/remapper found on the
> i.MX8 line of SoCs.
>
> Signed-off-by: Fugang Duan
> Signed-off-by: Lucas Stach
> ---
> This submission is a heavily cleaned up version of the downstream driver.
> ---
>
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Jérôme Glisse
commit bfba8e5cf28f413aa05571af493871d74438979f upstream.
Inside set_pmd_migration_entry() we are holding page table locks and thus
we can not sleep so we can not call
Hi Richard,
On Tue, Oct 16, 2018 at 11:16:48AM +0200, Richard Leitner wrote:
> The sx8654 features a NRST input which may be connected to a GPIO.
> Therefore add support for hard-resetting the sx8654 via this NRST.
>
> If the reset-gpio property is provided the sx8654 is resetted via NRST
>
On 10/16/2018 10:27 PM, Steven Rostedt wrote:
OK, can you add to the command line:
ftrace=function ftrace_filter=*schedule*
to see if it's a specific function that may be causing the issue (but
hopefully it's not one of the scheduling functions that caused it).
Target boots fine with
On 10/16/2018 10:27 PM, Steven Rostedt wrote:
OK, can you add to the command line:
ftrace=function ftrace_filter=*schedule*
to see if it's a specific function that may be causing the issue (but
hopefully it's not one of the scheduling functions that caused it).
Target boots fine with
Hi Gustavo,
On Tue, Oct 16, 2018 at 01:13:13PM +0200, Gustavo A. R. Silva wrote:
> setup.code can be indirectly controlled by user-space, hence leading to
> a potential exploitation of the Spectre variant 1 vulnerability.
>
> This issue was detected with the help of Smatch:
>
>
Hi Gustavo,
On Tue, Oct 16, 2018 at 01:13:13PM +0200, Gustavo A. R. Silva wrote:
> setup.code can be indirectly controlled by user-space, hence leading to
> a potential exploitation of the Spectre variant 1 vulnerability.
>
> This issue was detected with the help of Smatch:
>
>
Hi Dennis,
On Fri, 2018-10-12 at 08:38 -0500, Dennis Gilmore wrote:
> El jue, 26-04-2018 a las 15:09 +, Pandruvada, Srinivas escribió:
> > On Thu, 2018-04-26 at 07:42 -0500, Dennis Gilmore wrote:
> > > Hi Srinivas,
> > >
> > > El jue, 26-04-2018 a las 05:34 +, Pandruvada, Srinivas
> > >
Hi Dennis,
On Fri, 2018-10-12 at 08:38 -0500, Dennis Gilmore wrote:
> El jue, 26-04-2018 a las 15:09 +, Pandruvada, Srinivas escribió:
> > On Thu, 2018-04-26 at 07:42 -0500, Dennis Gilmore wrote:
> > > Hi Srinivas,
> > >
> > > El jue, 26-04-2018 a las 05:34 +, Pandruvada, Srinivas
> > >
501 - 600 of 2214 matches
Mail list logo
