Re: [PATCH] mtd: spi-nor: add support for Microchip 25LC256

On 05/18/2018 03:00 PM, Radu Pirea wrote: > > > On 05/18/2018 01:03 PM, Marek Vasut wrote: >> On 05/18/2018 11:50 AM, Radu Pirea wrote: >>> >>> >>> On 05/16/2018 04:47 PM, Marek Vasut wrote: On 05/16/2018 12:05 PM, Radu Pirea wrote: > On Wed, 2018-05-16 at 00:17 +0200, Marek Vasut

Re: [PATCH] mtd: spi-nor: add support for Microchip 25LC256

On 05/18/2018 03:00 PM, Radu Pirea wrote: > > > On 05/18/2018 01:03 PM, Marek Vasut wrote: >> On 05/18/2018 11:50 AM, Radu Pirea wrote: >>> >>> >>> On 05/16/2018 04:47 PM, Marek Vasut wrote: On 05/16/2018 12:05 PM, Radu Pirea wrote: > On Wed, 2018-05-16 at 00:17 +0200, Marek Vasut

Re: [PATCH] audit: use existing session info function

On Thu, May 17, 2018 at 10:01 PM, Richard Guy Briggs wrote: > Use the existing audit_log_session_info() function rather than > hardcoding its functionality. > > Signed-off-by: Richard Guy Briggs > --- > kernel/auditfilter.c | 4 +--- > 1 file changed, 1

Re: [PATCH] audit: use existing session info function

On Thu, May 17, 2018 at 10:01 PM, Richard Guy Briggs wrote: > Use the existing audit_log_session_info() function rather than > hardcoding its functionality. > > Signed-off-by: Richard Guy Briggs > --- > kernel/auditfilter.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) Merged into

Re: [PATCH INTERNAL 3/3] PCI: iproc: Disable MSI parsing in certain PAXC blocks

Hi Lorenzo, On 5/18/2018 6:56 AM, Lorenzo Pieralisi wrote: On Fri, May 18, 2018 at 02:53:41PM +0530, p...@codeaurora.org wrote: On 2018-05-17 22:51, Ray Jui wrote: The internal MSI parsing logic in certain revisions of PAXC root complexes does not work properly and can casue corruptions on

Re: [PATCH INTERNAL 3/3] PCI: iproc: Disable MSI parsing in certain PAXC blocks

Hi Lorenzo, On 5/18/2018 6:56 AM, Lorenzo Pieralisi wrote: On Fri, May 18, 2018 at 02:53:41PM +0530, p...@codeaurora.org wrote: On 2018-05-17 22:51, Ray Jui wrote: The internal MSI parsing logic in certain revisions of PAXC root complexes does not work properly and can casue corruptions on

Re: [PATCH] isdn: eicon: fix a missing-check bug

Thanks for your suggestion, David! I will revise the patch and resubmit it. Wenwen On Fri, May 11, 2018 at 2:50 PM, David Miller wrote: > From: Wenwen Wang > Date: Sat, 5 May 2018 14:32:46 -0500 > >> To avoid such issues, this patch adds a check after

Re: [PATCH] isdn: eicon: fix a missing-check bug

Thanks for your suggestion, David! I will revise the patch and resubmit it. Wenwen On Fri, May 11, 2018 at 2:50 PM, David Miller wrote: > From: Wenwen Wang > Date: Sat, 5 May 2018 14:32:46 -0500 > >> To avoid such issues, this patch adds a check after the second copy in the >> function

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

On May 18, 2018 12:36:20 PM PDT, Nadav Amit wrote: >h...@zytor.com wrote: > >> On May 18, 2018 12:21:00 PM PDT, Linus Torvalds > wrote: >>> On Fri, May 18, 2018 at 12:18 PM Nadav Amit >wrote: >>> Gnu ASM manual says: "Each

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

On May 18, 2018 12:36:20 PM PDT, Nadav Amit wrote: >h...@zytor.com wrote: > >> On May 18, 2018 12:21:00 PM PDT, Linus Torvalds > wrote: >>> On Fri, May 18, 2018 at 12:18 PM Nadav Amit >wrote: >>> Gnu ASM manual says: "Each time you run as it assembles exactly one >>> source program.

Re: [PATCH v6 17/28] x86/asm: use SYM_INNER_LABEL instead of GLOBAL

On Fri, May 18, 2018 at 2:17 AM Jiri Slaby wrote: > GLOBAL had several meanings and is going away. In this patch, convert > all the inner function labels marked with GLOBAL to use SYM_INNER_LABEL > instead. > Note that retint_user needs not be global, perhaps since commit >

Re: [PATCH v6 17/28] x86/asm: use SYM_INNER_LABEL instead of GLOBAL

On Fri, May 18, 2018 at 2:17 AM Jiri Slaby wrote: > GLOBAL had several meanings and is going away. In this patch, convert > all the inner function labels marked with GLOBAL to use SYM_INNER_LABEL > instead. > Note that retint_user needs not be global, perhaps since commit > 2ec67971facc

Re: [PATCH v4 2/2] vfio/mdev: Re-order sysfs attribute creation

On 5/19/2018 12:40 AM, Alex Williamson wrote: > There exists a gap at the end of mdev_device_create() where the device > is visible to userspace, but we're not yet ready to handle removal, as > triggered through the 'remove' attribute. We handle this properly in > mdev_device_remove() with an

Re: [PATCH v4 2/2] vfio/mdev: Re-order sysfs attribute creation

On 5/19/2018 12:40 AM, Alex Williamson wrote: > There exists a gap at the end of mdev_device_create() where the device > is visible to userspace, but we're not yet ready to handle removal, as > triggered through the 'remove' attribute. We handle this properly in > mdev_device_remove() with an

Re: [PATCH v4 0/2] vfio/mdev: Device namespace protection

On 5/19/2018 12:40 AM, Alex Williamson wrote: > v4: Fix the 'create' racing 'remove' gap noted by Kirti by moving > removal from mdev_list to mdev_device_release(). Fix missing > mdev_put_parent() cases in mdev_device_create(), also noted > by Kirti. Added documention update

Re: [PATCH v4 0/2] vfio/mdev: Device namespace protection

On 5/19/2018 12:40 AM, Alex Williamson wrote: > v4: Fix the 'create' racing 'remove' gap noted by Kirti by moving > removal from mdev_list to mdev_device_release(). Fix missing > mdev_put_parent() cases in mdev_device_create(), also noted > by Kirti. Added documention update

Re: [PATCH v4 1/2] vfio/mdev: Check globally for duplicate devices

On 5/19/2018 12:40 AM, Alex Williamson wrote: > When we create an mdev device, we check for duplicates against the > parent device and return -EEXIST if found, but the mdev device > namespace is global since we'll link all devices from the bus. We do > catch this later in

Re: [PATCH v4 1/2] vfio/mdev: Check globally for duplicate devices

On 5/19/2018 12:40 AM, Alex Williamson wrote: > When we create an mdev device, we check for duplicates against the > parent device and return -EEXIST if found, but the mdev device > namespace is global since we'll link all devices from the bus. We do > catch this later in

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

h...@zytor.com wrote: > On May 18, 2018 12:21:00 PM PDT, Linus Torvalds > wrote: >> On Fri, May 18, 2018 at 12:18 PM Nadav Amit wrote: >> >>> Gnu ASM manual says: "Each time you run as it assembles exactly one >> source >>> program. The source

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

h...@zytor.com wrote: > On May 18, 2018 12:21:00 PM PDT, Linus Torvalds > wrote: >> On Fri, May 18, 2018 at 12:18 PM Nadav Amit wrote: >> >>> Gnu ASM manual says: "Each time you run as it assembles exactly one >> source >>> program. The source program is made up of one or more files.” >> >>

Re: [PATCH] perf tests: Fix regex for record+probe_libc_inet_pton.sh

Em Fri, May 18, 2018 at 04:29:16PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Fri, May 18, 2018 at 04:21:02PM -0300, Arnaldo Carvalho de Melo escreveu: > > Here it went from failing with: > > > > [root@seventh ~]# perf test -v pton > > 64: probe libc's inet_pton & backtrace it with ping

Re: [PATCH] perf tests: Fix regex for record+probe_libc_inet_pton.sh

Em Fri, May 18, 2018 at 04:29:16PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Fri, May 18, 2018 at 04:21:02PM -0300, Arnaldo Carvalho de Melo escreveu: > > Here it went from failing with: > > > > [root@seventh ~]# perf test -v pton > > 64: probe libc's inet_pton & backtrace it with ping

Re: [PATCH] perf tests: Fix regex for record+probe_libc_inet_pton.sh

Em Fri, May 18, 2018 at 04:21:02PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Fri, May 18, 2018 at 12:54:17PM +0530, Sandipan Das escreveu: > > This test currently fails because the regular expressions for > > matching the output of perf script do not consider the symbol > > offsets to be part

Re: [PATCH] perf tests: Fix regex for record+probe_libc_inet_pton.sh

Em Fri, May 18, 2018 at 04:21:02PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Fri, May 18, 2018 at 12:54:17PM +0530, Sandipan Das escreveu: > > This test currently fails because the regular expressions for > > matching the output of perf script do not consider the symbol > > offsets to be part

Re: [PATCH] perf tests: Fix regex for record+probe_libc_inet_pton.sh

Hi Arnaldo, On 05/19/2018 12:51 AM, Arnaldo Carvalho de Melo wrote: > Em Fri, May 18, 2018 at 12:54:17PM +0530, Sandipan Das escreveu: >> This test currently fails because the regular expressions for >> matching the output of perf script do not consider the symbol >> offsets to be part of the

Re: [PATCH] perf tests: Fix regex for record+probe_libc_inet_pton.sh

Hi Arnaldo, On 05/19/2018 12:51 AM, Arnaldo Carvalho de Melo wrote: > Em Fri, May 18, 2018 at 12:54:17PM +0530, Sandipan Das escreveu: >> This test currently fails because the regular expressions for >> matching the output of perf script do not consider the symbol >> offsets to be part of the

Re: [PATCH v2 1/2] i2c: core-smbus: fix a potential uninitialization bug

Yes, this patch does not aim to "fix" all potential driver bugs but adds an additional protection in case the implementation of .master_xfer is incorrect. >From this perspective, it is still necessary to apply this patch, as pointed out by Peter. Thanks, Wenwen On Mon, May 14, 2018 at 3:31 PM,

Re: [PATCH v2 1/2] i2c: core-smbus: fix a potential uninitialization bug

Yes, this patch does not aim to "fix" all potential driver bugs but adds an additional protection in case the implementation of .master_xfer is incorrect. >From this perspective, it is still necessary to apply this patch, as pointed out by Peter. Thanks, Wenwen On Mon, May 14, 2018 at 3:31 PM,

Re: [PATCH 4.16 00/55] 4.16.10-stable review

On 18 May 2018 at 13:44, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.16.10 release. > There are 55 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please

Re: [PATCH 4.16 00/55] 4.16.10-stable review

On 18 May 2018 at 13:44, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.16.10 release. > There are 55 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

Re: [PATCHv2][SMB3] Add kernel trace support

On Thu, May 17, 2018 at 09:36:36PM -0500, Steve French via samba-technical wrote: > Patch updated with additional tracepoint locations and some formatting > improvements. There are some obvious additional tracepoints that could > be added, but this should be a reasonable group to start with. > >

Re: [PATCHv2][SMB3] Add kernel trace support

On Thu, May 17, 2018 at 09:36:36PM -0500, Steve French via samba-technical wrote: > Patch updated with additional tracepoint locations and some formatting > improvements. There are some obvious additional tracepoints that could > be added, but this should be a reasonable group to start with. > >

Re: [PATCH v2] selftests/cgroup: memory controller self-tests

On 05/11/2018 02:22 PM, Shuah Khan wrote: > On 05/11/2018 02:02 PM, Tejun Heo wrote: >> On Fri, May 11, 2018 at 01:33:26PM -0600, Shuah Khan wrote: >>> Yeah. I see that. You have a switch for the KSFT_ values. Since there is no >>> dependency on the cgroup tree, I would recommend having this patch

Re: [PATCH v2] selftests/cgroup: memory controller self-tests

On 05/11/2018 02:22 PM, Shuah Khan wrote: > On 05/11/2018 02:02 PM, Tejun Heo wrote: >> On Fri, May 11, 2018 at 01:33:26PM -0600, Shuah Khan wrote: >>> Yeah. I see that. You have a switch for the KSFT_ values. Since there is no >>> dependency on the cgroup tree, I would recommend having this patch

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

On May 18, 2018 12:21:00 PM PDT, Linus Torvalds wrote: >On Fri, May 18, 2018 at 12:18 PM Nadav Amit wrote: > >> Gnu ASM manual says: "Each time you run as it assembles exactly one >source >> program. The source program is made up of one or more

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

On May 18, 2018 12:21:00 PM PDT, Linus Torvalds wrote: >On Fri, May 18, 2018 at 12:18 PM Nadav Amit wrote: > >> Gnu ASM manual says: "Each time you run as it assembles exactly one >source >> program. The source program is made up of one or more files.” > >Ok, that counts as documentation,

Re: [PATCH] kernel: sys: fix potential Spectre v1

On 05/18/2018 02:04 PM, Gustavo A. R. Silva wrote: On 05/15/2018 05:57 PM, Dan Williams wrote: On Tue, May 15, 2018 at 3:29 PM, Thomas Gleixner wrote: On Tue, 15 May 2018, Andrew Morton wrote: On Mon, 14 May 2018 22:00:38 -0500 "Gustavo A. R. Silva"

Re: [PATCH] kernel: sys: fix potential Spectre v1

On 05/18/2018 02:04 PM, Gustavo A. R. Silva wrote: On 05/15/2018 05:57 PM, Dan Williams wrote: On Tue, May 15, 2018 at 3:29 PM, Thomas Gleixner wrote: On Tue, 15 May 2018, Andrew Morton wrote: On Mon, 14 May 2018 22:00:38 -0500 "Gustavo A. R. Silva" wrote: resource can be controlled

Re: [PATCH] perf tests: Fix regex for record+probe_libc_inet_pton.sh

Em Fri, May 18, 2018 at 12:54:17PM +0530, Sandipan Das escreveu: > This test currently fails because the regular expressions for > matching the output of perf script do not consider the symbol > offsets to be part of the output. > > The symbol offsets are seen because of the default behaviour >

Re: [PATCH] perf tests: Fix regex for record+probe_libc_inet_pton.sh

Em Fri, May 18, 2018 at 12:54:17PM +0530, Sandipan Das escreveu: > This test currently fails because the regular expressions for > matching the output of perf script do not consider the symbol > offsets to be part of the output. > > The symbol offsets are seen because of the default behaviour >

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

On Fri, May 18, 2018 at 12:18 PM Nadav Amit wrote: > Gnu ASM manual says: "Each time you run as it assembles exactly one source > program. The source program is made up of one or more files.” Ok, that counts as documentation, although it's confusing as hell. Is it one source

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

On Fri, May 18, 2018 at 12:18 PM Nadav Amit wrote: > Gnu ASM manual says: "Each time you run as it assembles exactly one source > program. The source program is made up of one or more files.” Ok, that counts as documentation, although it's confusing as hell. Is it one source program or multiple

Re: [PATCH] selftest: intel_pstate: debug support message from aperf.c and return value fix.

On 05/18/2018 08:05 AM, Jeffrin Jose T wrote: > Additional message along with an error message which is more > verbose for debug support from aperf.c and updated with the > new return value "KSFT_SKIP". > > Signed-off-by: Jeffrin Jose T > --- >

Re: [PATCH] selftest: intel_pstate: debug support message from aperf.c and return value fix.

On 05/18/2018 08:05 AM, Jeffrin Jose T wrote: > Additional message along with an error message which is more > verbose for debug support from aperf.c and updated with the > new return value "KSFT_SKIP". > > Signed-off-by: Jeffrin Jose T > --- > tools/testing/selftests/intel_pstate/aperf.c | 6

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

Linus Torvalds wrote: > On Fri, May 18, 2018 at 12:02 PM Nadav Amit wrote: > >> I can add a -Wa,[filename.s] switch. It works, but sort of undocumented. > > Oh, if it assembles things together, then that sounds optimal. > > And yes, like hpa

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

Linus Torvalds wrote: > On Fri, May 18, 2018 at 12:02 PM Nadav Amit wrote: > >> I can add a -Wa,[filename.s] switch. It works, but sort of undocumented. > > Oh, if it assembles things together, then that sounds optimal. > > And yes, like hpa says, we should make sure that behavior is

[PATCH v4 2/2] vfio/mdev: Re-order sysfs attribute creation

There exists a gap at the end of mdev_device_create() where the device is visible to userspace, but we're not yet ready to handle removal, as triggered through the 'remove' attribute. We handle this properly in mdev_device_remove() with an -EAGAIN return, but we can marginally reduce this gap by

[PATCH v4 1/2] vfio/mdev: Check globally for duplicate devices

When we create an mdev device, we check for duplicates against the parent device and return -EEXIST if found, but the mdev device namespace is global since we'll link all devices from the bus. We do catch this later in sysfs_do_create_link_sd() to return -EEXIST, but with it comes a kernel

[PATCH v4 2/2] vfio/mdev: Re-order sysfs attribute creation

There exists a gap at the end of mdev_device_create() where the device is visible to userspace, but we're not yet ready to handle removal, as triggered through the 'remove' attribute. We handle this properly in mdev_device_remove() with an -EAGAIN return, but we can marginally reduce this gap by

[PATCH v4 1/2] vfio/mdev: Check globally for duplicate devices

When we create an mdev device, we check for duplicates against the parent device and return -EEXIST if found, but the mdev device namespace is global since we'll link all devices from the bus. We do catch this later in sysfs_do_create_link_sd() to return -EEXIST, but with it comes a kernel

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

On Fri, May 18, 2018 at 12:02 PM Nadav Amit wrote: > I can add a -Wa,[filename.s] switch. It works, but sort of undocumented. Oh, if it assembles things together, then that sounds optimal. And yes, like hpa says, we should make sure that behavior is acknowledged by the GNU as

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

On Fri, May 18, 2018 at 12:02 PM Nadav Amit wrote: > I can add a -Wa,[filename.s] switch. It works, but sort of undocumented. Oh, if it assembles things together, then that sounds optimal. And yes, like hpa says, we should make sure that behavior is acknowledged by the GNU as people, so that

Re: [PATCH 10/10] Dynamic fault injection

On Fri, May 18, 2018 at 01:05:20PM -0600, Andreas Dilger wrote: > On May 18, 2018, at 1:49 AM, Kent Overstreet > wrote: > > > > Signed-off-by: Kent Overstreet > > I agree with Christoph that even if there was some explanation in the cover

Re: [PATCH 10/10] Dynamic fault injection

On Fri, May 18, 2018 at 01:05:20PM -0600, Andreas Dilger wrote: > On May 18, 2018, at 1:49 AM, Kent Overstreet > wrote: > > > > Signed-off-by: Kent Overstreet > > I agree with Christoph that even if there was some explanation in the cover > letter, there should be something at least as good

Re: [PATCH 4.14 00/45] 4.14.42-stable review

On 18 May 2018 at 13:45, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.42 release. > There are 45 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please

Re: [PATCH 4.14 00/45] 4.14.42-stable review

On 18 May 2018 at 13:45, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.42 release. > There are 45 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

[PATCH v4 0/2] vfio/mdev: Device namespace protection

v4: Fix the 'create' racing 'remove' gap noted by Kirti by moving removal from mdev_list to mdev_device_release(). Fix missing mdev_put_parent() cases in mdev_device_create(), also noted by Kirti. Added documention update regarding serialization as noted by Cornelia. Added

[PATCH v4 0/2] vfio/mdev: Device namespace protection

v4: Fix the 'create' racing 'remove' gap noted by Kirti by moving removal from mdev_list to mdev_device_release(). Fix missing mdev_put_parent() cases in mdev_device_create(), also noted by Kirti. Added documention update regarding serialization as noted by Cornelia. Added

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

On May 18, 2018 12:02:50 PM PDT, Nadav Amit wrote: >h...@zytor.com wrote: > >> On May 18, 2018 11:50:12 AM PDT, Linus Torvalds > wrote: >>> On Fri, May 18, 2018 at 11:34 AM wrote: >>> On May 18, 2018 11:25:32 AM PDT, Linus

Re: [PATCH 10/10] Dynamic fault injection

On May 18, 2018, at 1:49 AM, Kent Overstreet wrote: > > Signed-off-by: Kent Overstreet I agree with Christoph that even if there was some explanation in the cover letter, there should be something at least as good in the patch itself. The

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

On May 18, 2018 12:02:50 PM PDT, Nadav Amit wrote: >h...@zytor.com wrote: > >> On May 18, 2018 11:50:12 AM PDT, Linus Torvalds > wrote: >>> On Fri, May 18, 2018 at 11:34 AM wrote: >>> On May 18, 2018 11:25:32 AM PDT, Linus Torvalds < >>> torva...@linux-foundation.org> wrote: >>>

Re: [PATCH 10/10] Dynamic fault injection

On May 18, 2018, at 1:49 AM, Kent Overstreet wrote: > > Signed-off-by: Kent Overstreet I agree with Christoph that even if there was some explanation in the cover letter, there should be something at least as good in the patch itself. The cover letter is not saved, but the commit stays around

Re: [PATCH] kernel: sys: fix potential Spectre v1

On 05/15/2018 05:57 PM, Dan Williams wrote: On Tue, May 15, 2018 at 3:29 PM, Thomas Gleixner wrote: On Tue, 15 May 2018, Andrew Morton wrote: On Mon, 14 May 2018 22:00:38 -0500 "Gustavo A. R. Silva" wrote: resource can be controlled by

Re: [PATCH] kernel: sys: fix potential Spectre v1

On 05/15/2018 05:57 PM, Dan Williams wrote: On Tue, May 15, 2018 at 3:29 PM, Thomas Gleixner wrote: On Tue, 15 May 2018, Andrew Morton wrote: On Mon, 14 May 2018 22:00:38 -0500 "Gustavo A. R. Silva" wrote: resource can be controlled by user-space, hence leading to a potential

Re: [PATCH v3] vfio/mdev: Check globally for duplicate devices

On 5/18/2018 11:00 PM, Alex Williamson wrote: > On Fri, 18 May 2018 12:34:03 +0530 > Kirti Wankhede wrote: > >> On 5/18/2018 3:07 AM, Alex Williamson wrote: >>> On Fri, 18 May 2018 01:56:50 +0530 >>> Kirti Wankhede wrote: >>> On 5/17/2018

Re: [PATCH v3] vfio/mdev: Check globally for duplicate devices

On 5/18/2018 11:00 PM, Alex Williamson wrote: > On Fri, 18 May 2018 12:34:03 +0530 > Kirti Wankhede wrote: > >> On 5/18/2018 3:07 AM, Alex Williamson wrote: >>> On Fri, 18 May 2018 01:56:50 +0530 >>> Kirti Wankhede wrote: >>> On 5/17/2018 9:50 PM, Alex Williamson wrote: > On

Re: [PATCH 4.9 00/33] 4.9.101-stable review

On 18 May 2018 at 13:45, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.101 release. > There are 33 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please

Re: [PATCH 4.9 00/33] 4.9.101-stable review

On 18 May 2018 at 13:45, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.101 release. > There are 33 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

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

h...@zytor.com wrote: > On May 18, 2018 11:50:12 AM PDT, Linus Torvalds > wrote: >> On Fri, May 18, 2018 at 11:34 AM wrote: >> >>> On May 18, 2018 11:25:32 AM PDT, Linus Torvalds < >> torva...@linux-foundation.org> wrote: >> >>> Unfortunately

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

h...@zytor.com wrote: > On May 18, 2018 11:50:12 AM PDT, Linus Torvalds > wrote: >> On Fri, May 18, 2018 at 11:34 AM wrote: >> >>> On May 18, 2018 11:25:32 AM PDT, Linus Torvalds < >> torva...@linux-foundation.org> wrote: >> >>> Unfortunately gcc doesn't guarantee that global assembly

Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"

On Thu, May 17, 2018 at 1:22 PM, Lars-Peter Clausen wrote: > On 05/17/2018 06:20 PM, Frank Mori Hess wrote: > The problem is not so much on the software side but even more so on the > hardware side. Not all hardware even supports aborting a transfer with no > data loss because

Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"

On Thu, May 17, 2018 at 1:22 PM, Lars-Peter Clausen wrote: > On 05/17/2018 06:20 PM, Frank Mori Hess wrote: > The problem is not so much on the software side but even more so on the > hardware side. Not all hardware even supports aborting a transfer with no > data loss because there is no precise

RE: [RFC PATCH 09/09] Introduce cache=rdma moutning option

> Subject: Re: [RFC PATCH 09/09] Introduce cache=rdma moutning option > > On Thu, May 17, 2018 at 05:22:14PM -0700, Long Li wrote: > > From: Long Li > > > > When cache=rdma is enabled on mount options, CIFS do not allocate > > internal data buffer pages for I/O, data is

RE: [RFC PATCH 09/09] Introduce cache=rdma moutning option

> Subject: Re: [RFC PATCH 09/09] Introduce cache=rdma moutning option > > On Thu, May 17, 2018 at 05:22:14PM -0700, Long Li wrote: > > From: Long Li > > > > When cache=rdma is enabled on mount options, CIFS do not allocate > > internal data buffer pages for I/O, data is read/writen directly to

Re: WARNING in ip_recv_error

On Fri, May 18, 2018 at 2:46 PM, Willem de Bruijn wrote: > On Fri, May 18, 2018 at 2:44 PM, Willem de Bruijn > wrote: >> On Fri, May 18, 2018 at 1:09 PM, Willem de Bruijn >> wrote: >>> On Fri, May

Re: WARNING in ip_recv_error

On Fri, May 18, 2018 at 2:46 PM, Willem de Bruijn wrote: > On Fri, May 18, 2018 at 2:44 PM, Willem de Bruijn > wrote: >> On Fri, May 18, 2018 at 1:09 PM, Willem de Bruijn >> wrote: >>> On Fri, May 18, 2018 at 11:44 AM, David Miller wrote: From: Eric Dumazet Date: Fri, 18 May 2018

Re: [PATCH] riscv: Fix the bug in memory access fixup code

On Mon, 07 May 2018 19:59:33 PDT (-0700), alan...@andestech.com wrote: A piece of fixup code is currently shared by __copy_user and __clear_user. It first disables the access to user-space memory and then returns the "n" argument, which represents #(bytes not processed). However,__copy_user's

Re: [PATCH] riscv: Fix the bug in memory access fixup code

On Mon, 07 May 2018 19:59:33 PDT (-0700), alan...@andestech.com wrote: A piece of fixup code is currently shared by __copy_user and __clear_user. It first disables the access to user-space memory and then returns the "n" argument, which represents #(bytes not processed). However,__copy_user's

Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"

On Fri, May 18, 2018 at 12:03 AM, Vinod wrote: > > You are simply mixing things up! It certainly feels like I'm mixed up. If I have to resolve this, I'd like to be a little less mixed up before I submit more patches which are going to inevitably result in subtly broken code

Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"

On Fri, May 18, 2018 at 12:03 AM, Vinod wrote: > > You are simply mixing things up! It certainly feels like I'm mixed up. If I have to resolve this, I'd like to be a little less mixed up before I submit more patches which are going to inevitably result in subtly broken code suddenly becoming

[PATCH v2] schedutil: Allow cpufreq requests to be made even when kthread kicked

From: "Joel Fernandes (Google)" Currently there is a chance of a schedutil cpufreq update request to be dropped if there is a pending update request. This pending request can be delayed if there is a scheduling delay of the irq_work and the wake up of the schedutil

[PATCH v2] schedutil: Allow cpufreq requests to be made even when kthread kicked

From: "Joel Fernandes (Google)" Currently there is a chance of a schedutil cpufreq update request to be dropped if there is a pending update request. This pending request can be delayed if there is a scheduling delay of the irq_work and the wake up of the schedutil governor kthread. A very bad

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

On May 18, 2018 11:50:12 AM PDT, Linus Torvalds wrote: >On Fri, May 18, 2018 at 11:34 AM wrote: > >> On May 18, 2018 11:25:32 AM PDT, Linus Torvalds < >torva...@linux-foundation.org> wrote: > >> Unfortunately gcc doesn't guarantee that global

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

On May 18, 2018 11:50:12 AM PDT, Linus Torvalds wrote: >On Fri, May 18, 2018 at 11:34 AM wrote: > >> On May 18, 2018 11:25:32 AM PDT, Linus Torvalds < >torva...@linux-foundation.org> wrote: > >> Unfortunately gcc doesn't guarantee that global assembly inlines will >appear at the top of the

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

On Fri, May 18, 2018 at 11:34 AM wrote: > On May 18, 2018 11:25:32 AM PDT, Linus Torvalds < torva...@linux-foundation.org> wrote: > Unfortunately gcc doesn't guarantee that global assembly inlines will appear at the top of the file. Yeah. It really would be better to do the

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

On Fri, May 18, 2018 at 11:34 AM wrote: > On May 18, 2018 11:25:32 AM PDT, Linus Torvalds < torva...@linux-foundation.org> wrote: > Unfortunately gcc doesn't guarantee that global assembly inlines will appear at the top of the file. Yeah. It really would be better to do the "asm version of

[PULL REQUEST] i2c for 4.17

Linus, I2C has a bunch of driver bugfixes and a MAINTAINERS addition. Please pull. Thanks, Wolfram The following changes since commit 75bc37fefc4471e718ba8e651aa74673d4e0a9eb: Linux 4.17-rc4 (2018-05-06 16:57:38 -1000) are available in the git repository at:

[PULL REQUEST] i2c for 4.17

Linus, I2C has a bunch of driver bugfixes and a MAINTAINERS addition. Please pull. Thanks, Wolfram The following changes since commit 75bc37fefc4471e718ba8e651aa74673d4e0a9eb: Linux 4.17-rc4 (2018-05-06 16:57:38 -1000) are available in the git repository at:

Re: WARNING in ip_recv_error

On Fri, May 18, 2018 at 2:44 PM, Willem de Bruijn wrote: > On Fri, May 18, 2018 at 1:09 PM, Willem de Bruijn > wrote: >> On Fri, May 18, 2018 at 11:44 AM, David Miller wrote: >>> From: Eric Dumazet

Re: WARNING in ip_recv_error

On Fri, May 18, 2018 at 2:44 PM, Willem de Bruijn wrote: > On Fri, May 18, 2018 at 1:09 PM, Willem de Bruijn > wrote: >> On Fri, May 18, 2018 at 11:44 AM, David Miller wrote: >>> From: Eric Dumazet >>> Date: Fri, 18 May 2018 08:30:43 -0700 >>> We probably need to revert Willem patch

Re: WARNING in ip_recv_error

On Fri, May 18, 2018 at 1:09 PM, Willem de Bruijn wrote: > On Fri, May 18, 2018 at 11:44 AM, David Miller wrote: >> From: Eric Dumazet >> Date: Fri, 18 May 2018 08:30:43 -0700 >> >>> We probably need to revert Willem

Re: WARNING in ip_recv_error

On Fri, May 18, 2018 at 1:09 PM, Willem de Bruijn wrote: > On Fri, May 18, 2018 at 11:44 AM, David Miller wrote: >> From: Eric Dumazet >> Date: Fri, 18 May 2018 08:30:43 -0700 >> >>> We probably need to revert Willem patch >>> (7ce875e5ecb8562fd44040f69bda96c999e38bbc) >> >> Is it really valid

Re: [PATCH] locking/atomics: Simplify the op definitions in atomic.h some more

On Sun, 06 May 2018 07:57:27 PDT (-0700), mi...@kernel.org wrote: > > * Andrea Parri wrote: > >> Hi Ingo, >> >> > From 5affbf7e91901143f84f1b2ca64f4afe70e210fd Mon Sep 17 00:00:00 2001 >> > From: Ingo Molnar >> > Date: Sat, 5 May 2018 10:23:23

Re: [PATCH] locking/atomics: Simplify the op definitions in atomic.h some more

On Sun, 06 May 2018 07:57:27 PDT (-0700), mi...@kernel.org wrote: > > * Andrea Parri wrote: > >> Hi Ingo, >> >> > From 5affbf7e91901143f84f1b2ca64f4afe70e210fd Mon Sep 17 00:00:00 2001 >> > From: Ingo Molnar >> > Date: Sat, 5 May 2018 10:23:23 +0200 >> > Subject: [PATCH] locking/atomics:

Tasks RCU vs Preempt RCU

Hi, I was thinking about tasks-RCU and why its needed. Since preempt-RCU allows tasks to be preempted in read-sections, can we not just reuse that mechanism for the trampolines since we track all preempted tasks so we would wait on all tasks preempted within a trampoline? I am trying to

Tasks RCU vs Preempt RCU

Hi, I was thinking about tasks-RCU and why its needed. Since preempt-RCU allows tasks to be preempted in read-sections, can we not just reuse that mechanism for the trampolines since we track all preempted tasks so we would wait on all tasks preempted within a trampoline? I am trying to

Re: seq_putc is preferable to seq_puts

On Fri, 2018-05-18 at 10:50 -0700, Joe Perches wrote: > and a trivial script to convert them all treewide > > $ git grep -P --name-only > '\b(?:seq_puts|seq_printf)\s*\(\s*[^,]+,\s*"(?:\\.|.)"\s*\)\s*;' | \ > xargs perl -i -e 'local $/; while (<>) { >

Re: seq_putc is preferable to seq_puts

On Fri, 2018-05-18 at 10:50 -0700, Joe Perches wrote: > and a trivial script to convert them all treewide > > $ git grep -P --name-only > '\b(?:seq_puts|seq_printf)\s*\(\s*[^,]+,\s*"(?:\\.|.)"\s*\)\s*;' | \ > xargs perl -i -e 'local $/; while (<>) { >

Re: [PATCH v11 1/2] arch/*: Add CONFIG_ARCH_HAVE_CMPXCHG64

On May 18, 2018 11:00:05 AM PDT, Bart Van Assche wrote: >The next patch in this series introduces a call to cmpxchg64() >in the block layer core for those architectures on which this >functionality is available. Make it possible to test whether >cmpxchg64() is available by

Re: [PATCH v11 1/2] arch/*: Add CONFIG_ARCH_HAVE_CMPXCHG64

On May 18, 2018 11:00:05 AM PDT, Bart Van Assche wrote: >The next patch in this series introduces a call to cmpxchg64() >in the block layer core for those architectures on which this >functionality is available. Make it possible to test whether >cmpxchg64() is available by introducing

<    1   2   3   4   5   6   7   8   9   10   >