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

On Tue, Apr 24, 2018 at 02:58:45PM -0500, Serge E. Hallyn wrote: > Quoting Tycho Andersen (ty...@tycho.ws): > > On Tue, Apr 24, 2018 at 11:46:38PM +0900, Tetsuo Handa wrote: > > > Tycho Andersen wrote: > > > > > > + if (unlikely(crypto_aead_ivsize(big_key_aead) != > > > > > > GCM_AES_IV_SIZE))

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

On Tue, Apr 24, 2018 at 02:58:45PM -0500, Serge E. Hallyn wrote: > Quoting Tycho Andersen (ty...@tycho.ws): > > On Tue, Apr 24, 2018 at 11:46:38PM +0900, Tetsuo Handa wrote: > > > Tycho Andersen wrote: > > > > > > + if (unlikely(crypto_aead_ivsize(big_key_aead) != > > > > > > GCM_AES_IV_SIZE))

Re: vmalloc with GFP_NOFS

On Tue 24-04-18 20:26:23, Steven Whitehouse wrote: [...] > It would be good to fix this, and it has been known as an issue for a long > time. We might well be able to make use of the new API though. It might be > as simple as adding the calls when we get & release glocks, but I'd have to > check

Re: vmalloc with GFP_NOFS

On Tue 24-04-18 20:26:23, Steven Whitehouse wrote: [...] > It would be good to fix this, and it has been known as an issue for a long > time. We might well be able to make use of the new API though. It might be > as simple as adding the calls when we get & release glocks, but I'd have to > check

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

On Tue, Apr 24, 2018 at 12:58 PM, Serge E. Hallyn wrote: > Quoting Tycho Andersen (ty...@tycho.ws): >> On Tue, Apr 24, 2018 at 11:46:38PM +0900, Tetsuo Handa wrote: >> > Tycho Andersen wrote: >> > > > > + if (unlikely(crypto_aead_ivsize(big_key_aead) != >> > > > >

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

On Tue, Apr 24, 2018 at 12:58 PM, Serge E. Hallyn wrote: > Quoting Tycho Andersen (ty...@tycho.ws): >> On Tue, Apr 24, 2018 at 11:46:38PM +0900, Tetsuo Handa wrote: >> > Tycho Andersen wrote: >> > > > > + if (unlikely(crypto_aead_ivsize(big_key_aead) != >> > > > > GCM_AES_IV_SIZE)) { >> > >

RE: [PATCH] tpm: tpm_crb: relinquish locality on error path.

> Subject: Re: [PATCH] tpm: tpm_crb: relinquish locality on error path. > > On Fri, Apr 20, 2018 at 01:19:12PM +, Winkler, Tomas wrote: > > > > On Tue, 2018-04-10 at 09:00 +, Winkler, Tomas wrote: > > > > > > > > > > > > On Sat, 2018-04-07 at 19:12 +0300, Tomas Winkler wrote: > > > > > >

RE: [PATCH] tpm: tpm_crb: relinquish locality on error path.

> Subject: Re: [PATCH] tpm: tpm_crb: relinquish locality on error path. > > On Fri, Apr 20, 2018 at 01:19:12PM +, Winkler, Tomas wrote: > > > > On Tue, 2018-04-10 at 09:00 +, Winkler, Tomas wrote: > > > > > > > > > > > > On Sat, 2018-04-07 at 19:12 +0300, Tomas Winkler wrote: > > > > > >

Re: Boot failures with net-next after rebase to v4.17.0-rc1

On Tue, Apr 24, 2018 at 12:54 PM, Jesper Dangaard Brouer wrote: > Hi all, > > I'm experiencing boot failures with net-next git-tree after it got > rebased/merged with Linus'es tree at v4.17.0-rc1. I suspect it's the global bit stuff that came in very late in the merge window,

Re: Boot failures with net-next after rebase to v4.17.0-rc1

On Tue, Apr 24, 2018 at 12:54 PM, Jesper Dangaard Brouer wrote: > Hi all, > > I'm experiencing boot failures with net-next git-tree after it got > rebased/merged with Linus'es tree at v4.17.0-rc1. I suspect it's the global bit stuff that came in very late in the merge window, and had been

Re: [PATCH] net/tls: remove redundant second null check on sgout

From: Colin King Date: Tue, 24 Apr 2018 13:36:58 +0100 > From: Colin Ian King > > A duplicated null check on sgout is redundant as it is known to be > already true because of the identical earlier check. Remove it. > Detected by cppcheck: >

Re: [PATCH] net/tls: remove redundant second null check on sgout

From: Colin King Date: Tue, 24 Apr 2018 13:36:58 +0100 > From: Colin Ian King > > A duplicated null check on sgout is redundant as it is known to be > already true because of the identical earlier check. Remove it. > Detected by cppcheck: > > net/tls/tls_sw.c:696: (warning) Identical inner

Re: [PATCH] fsl/fman_port: remove redundant check on port->rev_info.major

From: Colin King Date: Tue, 24 Apr 2018 12:39:45 +0100 > From: Colin Ian King > > The check port->rev_info.major >= 6 is being performed twice, thus > the inner second check is always true and is redundant, hence it > can be removed. Detected

Re: [PATCH] fsl/fman_port: remove redundant check on port->rev_info.major

From: Colin King Date: Tue, 24 Apr 2018 12:39:45 +0100 > From: Colin Ian King > > The check port->rev_info.major >= 6 is being performed twice, thus > the inner second check is always true and is redundant, hence it > can be removed. Detected by cppcheck. > >

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

On Tue, 24 Apr 2018, Michal Hocko wrote: > Is there any reason why we cannot simply call __oom_reap_task_mm as we > have it now? mmap_sem for read shouldn't fail here because this is the > last reference of the mm and we are past the ksm and khugepaged > synchronizations. So unless my jed laged

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

On Tue, 24 Apr 2018, Michal Hocko wrote: > Is there any reason why we cannot simply call __oom_reap_task_mm as we > have it now? mmap_sem for read shouldn't fail here because this is the > last reference of the mm and we are past the ksm and khugepaged > synchronizations. So unless my jed laged

Re: [v1] mm: access to uninitialized struct page

Hi Steven, Thank you for your review: >> https://lkml.org/lkml/2018/4/18/797 > > #2, Do not use "lkml.org" it is a very unreliable source. > OK > I'm fine with this change, but what happens if mm_init() traps? > > But that is probably not a case we really care about, as it is in the > very

Re: [v1] mm: access to uninitialized struct page

Hi Steven, Thank you for your review: >> https://lkml.org/lkml/2018/4/18/797 > > #2, Do not use "lkml.org" it is a very unreliable source. > OK > I'm fine with this change, but what happens if mm_init() traps? > > But that is probably not a case we really care about, as it is in the > very

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

Quoting Tycho Andersen (ty...@tycho.ws): > On Tue, Apr 24, 2018 at 11:46:38PM +0900, Tetsuo Handa wrote: > > Tycho Andersen wrote: > > > > > + if (unlikely(crypto_aead_ivsize(big_key_aead) != > > > > > GCM_AES_IV_SIZE)) { > > > > > + WARN(1, "big key algorithm changed?"); > > > >

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

Quoting Tycho Andersen (ty...@tycho.ws): > On Tue, Apr 24, 2018 at 11:46:38PM +0900, Tetsuo Handa wrote: > > Tycho Andersen wrote: > > > > > + if (unlikely(crypto_aead_ivsize(big_key_aead) != > > > > > GCM_AES_IV_SIZE)) { > > > > > + WARN(1, "big key algorithm changed?"); > > > >

[PATCH] perf/x86/intel: Don't enable freeze-on-smi for PerfMon V1

From: Kan Liang The SMM freeze feature was introduced since PerfMon V2. But the current code unconditionally enables the feature for all platforms. It can generate #GP exception, if the related FREEZE_WHILE_SMM bit is set for the machine with PerfMon V1. Checking the

[PATCH] perf/x86/intel: Don't enable freeze-on-smi for PerfMon V1

From: Kan Liang The SMM freeze feature was introduced since PerfMon V2. But the current code unconditionally enables the feature for all platforms. It can generate #GP exception, if the related FREEZE_WHILE_SMM bit is set for the machine with PerfMon V1. Checking the PerfMon version. Only

[PATCH v2] staging: bcm2835-audio: Disconnect and free vchi_instance on module_exit()

In the current implementation, vchi_instance is inited during the first call of bcm2835_audio_open_connection(), and is never freed. It causes a memory leak when the module `snd_bcm2835` is removed. Here is how this commit fixes it: * the VCHI context (including vchi_instance) is created once in

[PATCH v2] staging: bcm2835-audio: Disconnect and free vchi_instance on module_exit()

In the current implementation, vchi_instance is inited during the first call of bcm2835_audio_open_connection(), and is never freed. It causes a memory leak when the module `snd_bcm2835` is removed. Here is how this commit fixes it: * the VCHI context (including vchi_instance) is created once in

Re: [PATCH] drm/radeon: Change the default to PCI on PowerPC

For reference: https://lists.freedesktop.org/archives/mesa-dev/2016-May/115453.html 2018-04-24 21:55 GMT+02:00 Mathieu Malaterre : > AGP mode is unstable on PowerPC. Symptoms are generally of the form: > > [ 1228.795711] radeon :00:10.0: ring 0 stalled for more than

Re: [PATCH] drm/radeon: Change the default to PCI on PowerPC

For reference: https://lists.freedesktop.org/archives/mesa-dev/2016-May/115453.html 2018-04-24 21:55 GMT+02:00 Mathieu Malaterre : > AGP mode is unstable on PowerPC. Symptoms are generally of the form: > > [ 1228.795711] radeon :00:10.0: ring 0 stalled for more than 10240msec > >

[PATCH] drm/radeon: Change the default to PCI on PowerPC

AGP mode is unstable on PowerPC. Symptoms are generally of the form: [ 1228.795711] radeon :00:10.0: ring 0 stalled for more than 10240msec Reviewed-by: Christian König Signed-off-by: Mathieu Malaterre --- drivers/gpu/drm/radeon/radeon_drv.c | 5

[PATCH] drm/radeon: Change the default to PCI on PowerPC

AGP mode is unstable on PowerPC. Symptoms are generally of the form: [ 1228.795711] radeon :00:10.0: ring 0 stalled for more than 10240msec Reviewed-by: Christian König Signed-off-by: Mathieu Malaterre --- drivers/gpu/drm/radeon/radeon_drv.c | 5 + 1 file changed, 5 insertions(+)

Re: [PATCH net-next v5 0/3] kernel: add support to collect hardware logs in crash recovery kernel

From: Rahul Lakkireddy Date: Sat, 21 Apr 2018 22:35:52 +0530 > Patch 1 adds API to vmcore module to allow drivers to register callback > to collect the device specific hardware/firmware logs. The logs will > be added to /proc/vmcore as elf notes. > > Patch 2

Re: [PATCH net-next v5 0/3] kernel: add support to collect hardware logs in crash recovery kernel

From: Rahul Lakkireddy Date: Sat, 21 Apr 2018 22:35:52 +0530 > Patch 1 adds API to vmcore module to allow drivers to register callback > to collect the device specific hardware/firmware logs. The logs will > be added to /proc/vmcore as elf notes. > > Patch 2 updates read and mmap logic to

Boot failures with net-next after rebase to v4.17.0-rc1

Hi all, I'm experiencing boot failures with net-next git-tree after it got rebased/merged with Linus'es tree at v4.17.0-rc1. The boot problem only occurs for certain kernel configs. I've bisected the config problem down to enabling CONFIG_PREEMPT=y and resulting dependencies in below diff. Is

Boot failures with net-next after rebase to v4.17.0-rc1

Hi all, I'm experiencing boot failures with net-next git-tree after it got rebased/merged with Linus'es tree at v4.17.0-rc1. The boot problem only occurs for certain kernel configs. I've bisected the config problem down to enabling CONFIG_PREEMPT=y and resulting dependencies in below diff. Is

Re: [Intel-gfx] [PATCH v8 01/10] drm/atomic: Print debug message on atomic check failure

On Wed, 2018-04-11 at 19:42 -0400, Lyude Paul wrote: > Does what it says on the label, it's a little confusing debugging atomic > check failures otherwise. > > Cc: Manasi Navare > Cc: Ville Syrjälä > Signed-off-by: Lyude Paul

Re: [Intel-gfx] [PATCH v8 01/10] drm/atomic: Print debug message on atomic check failure

On Wed, 2018-04-11 at 19:42 -0400, Lyude Paul wrote: > Does what it says on the label, it's a little confusing debugging atomic > check failures otherwise. > > Cc: Manasi Navare > Cc: Ville Syrjälä > Signed-off-by: Lyude Paul > --- > drivers/gpu/drm/drm_atomic.c | 5 - > 1 file

[PATCH] f2fs: avoid bug_on on corrupted inode

syzbot has tested the proposed patch but the reproducer still triggered crash: kernel BUG at fs/f2fs/inode.c:LINE! F2FS-fs (loop1): invalid crc value F2FS-fs (loop5): Magic Mismatch, valid(0xf2f52010) - read(0x0) F2FS-fs (loop5): Can't find valid F2FS filesystem in 1th superblock F2FS-fs (loop5):

[PATCH] f2fs: avoid bug_on on corrupted inode

syzbot has tested the proposed patch but the reproducer still triggered crash: kernel BUG at fs/f2fs/inode.c:LINE! F2FS-fs (loop1): invalid crc value F2FS-fs (loop5): Magic Mismatch, valid(0xf2f52010) - read(0x0) F2FS-fs (loop5): Can't find valid F2FS filesystem in 1th superblock F2FS-fs (loop5):

[PATCH] PM / devfreq: Drop custom MIN/MAX macros

Drop the custom MIN/MAX macros in favour of the standard min/max from kernel.h Signed-off-by: Bjorn Andersson --- drivers/devfreq/devfreq.c | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/devfreq/devfreq.c

[PATCH] PM / devfreq: Drop custom MIN/MAX macros

Drop the custom MIN/MAX macros in favour of the standard min/max from kernel.h Signed-off-by: Bjorn Andersson --- drivers/devfreq/devfreq.c | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c index

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote: > > Adding the dri-devel list, since this is driver independent code. > > > On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote: > > Avoid calling wait_event_killable when you are possibly being called > > from get_signal routine since

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote: > > Adding the dri-devel list, since this is driver independent code. > > > On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote: > > Avoid calling wait_event_killable when you are possibly being called > > from get_signal routine since

Re: [PATCH v5 0/2] perf: riscv: Preliminary Perf Event Support on RISC-V

On Tue, 24 Apr 2018 12:27:26 PDT (-0700), atish.pa...@wdc.com wrote: On 4/24/18 11:07 AM, Atish Patra wrote: On 4/19/18 4:28 PM, Alan Kao wrote: This implements the baseline PMU for RISC-V platforms. To ease future PMU portings, a guide is also written, containing perf concepts, arch porting

Re: [PATCH v5 0/2] perf: riscv: Preliminary Perf Event Support on RISC-V

On Tue, 24 Apr 2018 12:27:26 PDT (-0700), atish.pa...@wdc.com wrote: On 4/24/18 11:07 AM, Atish Patra wrote: On 4/19/18 4:28 PM, Alan Kao wrote: This implements the baseline PMU for RISC-V platforms. To ease future PMU portings, a guide is also written, containing perf concepts, arch porting

Re: [PATCH 0/7] gnss: add new GNSS subsystem

> Am 24.04.2018 um 19:50 schrieb Johan Hovold : > > On Tue, Apr 24, 2018 at 07:40:00PM +0200, H. Nikolaus Schaller wrote: >> Hi Johan, >> >>> Am 24.04.2018 um 18:34 schrieb Johan Hovold : > >>> As proof-of-concept I have implemented drivers for receivers

Re: [PATCH 0/7] gnss: add new GNSS subsystem

> Am 24.04.2018 um 19:50 schrieb Johan Hovold : > > On Tue, Apr 24, 2018 at 07:40:00PM +0200, H. Nikolaus Schaller wrote: >> Hi Johan, >> >>> Am 24.04.2018 um 18:34 schrieb Johan Hovold : > >>> As proof-of-concept I have implemented drivers for receivers based on >>> two common GNSS chipsets

Re: [PATCH 00/11] platform: device tree support for early platform drivers

On Tue, Apr 24, 2018 at 12:30 PM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > Device tree based systems often use OF_DECLARE() macros for devices > that need to be initialized early in the boot process such as clocks, > timers etc. However

Re: [PATCH 00/11] platform: device tree support for early platform drivers

On Tue, Apr 24, 2018 at 12:30 PM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > Device tree based systems often use OF_DECLARE() macros for devices > that need to be initialized early in the boot process such as clocks, > timers etc. However platform devices are more desirable.

Re: [PATCH net-next 2/2 v1] netns: isolate seqnums to use per-netns locks

From: Christian Brauner Date: Mon, 23 Apr 2018 12:24:43 +0200 > + #ifdef CONFIG_NET > + seqnum = get_ns_uevent_seqnum_by_vpid(); > + #else > + seqnum = uevent_seqnum; > + #endif Please don't indend the code like this. By

Re: [PATCH net-next 2/2 v1] netns: isolate seqnums to use per-netns locks

From: Christian Brauner Date: Mon, 23 Apr 2018 12:24:43 +0200 > + #ifdef CONFIG_NET > + seqnum = get_ns_uevent_seqnum_by_vpid(); > + #else > + seqnum = uevent_seqnum; > + #endif Please don't indend the code like this. By indenting the CPP directives, which

Re: [RFC PATCH] perf tools: allow map files to specify DSO

> Pekka, Andi, Stephane, do you guys see any problems with this? Looks ok to me. -Andi > > If this flies, tools/perf/Documentation/jit-interface.txt needs > updating.

Re: [RFC PATCH] perf tools: allow map files to specify DSO

> Pekka, Andi, Stephane, do you guys see any problems with this? Looks ok to me. -Andi > > If this flies, tools/perf/Documentation/jit-interface.txt needs > updating.

Re: [PATCH 2/7] ARM: dts: sun8i: h3: Split out common board design for ALL-H3-CC

On Tue, Apr 24, 2018 at 08:17:11PM +0800, Chen-Yu Tsai wrote: > On Tue, Apr 24, 2018 at 8:13 PM, Maxime Ripard > wrote: > > On Tue, Apr 24, 2018 at 07:34:19PM +0800, Chen-Yu Tsai wrote: > >> The Libre Computer Project ALL-H3-CC has three models, all using the > >> same

Re: [PATCH 2/7] ARM: dts: sun8i: h3: Split out common board design for ALL-H3-CC

On Tue, Apr 24, 2018 at 08:17:11PM +0800, Chen-Yu Tsai wrote: > On Tue, Apr 24, 2018 at 8:13 PM, Maxime Ripard > wrote: > > On Tue, Apr 24, 2018 at 07:34:19PM +0800, Chen-Yu Tsai wrote: > >> The Libre Computer Project ALL-H3-CC has three models, all using the > >> same board design, but with

Re: [PATCH v2] doc: dev-tools: kselftest.rst: update contributing new tests

On 04/19/2018 04:28 AM, Anders Roxell wrote: > Add a description that the kernel headers should be used as far as it is > possible and then the system headers. > > Signed-off-by: Anders Roxell > --- > Documentation/dev-tools/kselftest.rst | 5 + > 1 file changed, 5

Re: [PATCH v2] doc: dev-tools: kselftest.rst: update contributing new tests

On 04/19/2018 04:28 AM, Anders Roxell wrote: > Add a description that the kernel headers should be used as far as it is > possible and then the system headers. > > Signed-off-by: Anders Roxell > --- > Documentation/dev-tools/kselftest.rst | 5 + > 1 file changed, 5 insertions(+) > > diff

[PATCH v2 1/3] ACPI: improve function documentation for acpi_parse_entries_array()

I found the description of the table_size argument to the function acpi_parse_entries_array() unclear and ambiguous. This is a minor documentation change to improve that description so I don't misuse the argument again in the future, and it is hopefully clearer to other future users.

[PATCH v2 1/3] ACPI: improve function documentation for acpi_parse_entries_array()

I found the description of the table_size argument to the function acpi_parse_entries_array() unclear and ambiguous. This is a minor documentation change to improve that description so I don't misuse the argument again in the future, and it is hopefully clearer to other future users.

[PATCH v2 2/3] ACPI: ensure acpi_parse_entries_array() does not access non-existent table data

For ACPI tables that have subtables, acpi_parse_entries_array() gets used to step through each of the subtables in memory. The primary loop for this was checking that the beginning location of the subtable being examined plus the length of struct acpi_subtable_header was not beyond the end of the

[PATCH v2 2/3] ACPI: ensure acpi_parse_entries_array() does not access non-existent table data

For ACPI tables that have subtables, acpi_parse_entries_array() gets used to step through each of the subtables in memory. The primary loop for this was checking that the beginning location of the subtable being examined plus the length of struct acpi_subtable_header was not beyond the end of the

[PATCH v2 0/3] mailbox: ACPI: Remove incorrect error message about parsing PCCT

This set of patches provide some cleanup in ACPI for minor issues found while correcting a bogus error message (the first two patches), and the correction for the error message itself (patch 3/3). Note that patches 1/3 and 2/3 are not required for 3/3 to work: 1/3 only changes a comment and 2/3

[PATCH v2 3/3] mailbox: ACPI: erroneous error message when parsing the ACPI PCCT

There have been multiple reports of the following error message: [0.068293] Error parsing PCC subspaces from PCCT This error message is not correct. In multiple cases examined, the PCCT (Platform Communications Channel Table) concerned is actually properly constructed; the problem is that

[PATCH v2 0/3] mailbox: ACPI: Remove incorrect error message about parsing PCCT

This set of patches provide some cleanup in ACPI for minor issues found while correcting a bogus error message (the first two patches), and the correction for the error message itself (patch 3/3). Note that patches 1/3 and 2/3 are not required for 3/3 to work: 1/3 only changes a comment and 2/3

[PATCH v2 3/3] mailbox: ACPI: erroneous error message when parsing the ACPI PCCT

There have been multiple reports of the following error message: [0.068293] Error parsing PCC subspaces from PCCT This error message is not correct. In multiple cases examined, the PCCT (Platform Communications Channel Table) concerned is actually properly constructed; the problem is that

Re: [PATCH] perf: Documentation: Support for asciidoctor

Em Tue, Apr 24, 2018 at 05:04:56PM +0200, Takashi Iwai escreveu: > asciidoc seems behind the recent big wave of python3 conversion, and > we were advised to switch to asciidoctor instead. It's almost > compatible but some extensions used for perf documentation don't work > with it. Here is the

Re: [PATCH] perf: Documentation: Support for asciidoctor

Em Tue, Apr 24, 2018 at 05:04:56PM +0200, Takashi Iwai escreveu: > asciidoc seems behind the recent big wave of python3 conversion, and > we were advised to switch to asciidoctor instead. It's almost > compatible but some extensions used for perf documentation don't work > with it. Here is the

Re: [PATCH 1/2] iio: adc128s052: allow driver to be matched using ACPI

On Tue, Apr 24, 2018 at 06:23:30PM +0100, Jonathan Cameron wrote: > Unless we know of ACPI firmwares out there that are doing this, drop the > patch for now. I don't want to see a flood of these based on a 'you can > do it that' way argument. Fair enough. I'll drop it for v3.

Re: [PATCH 1/2] iio: adc128s052: allow driver to be matched using ACPI

On Tue, Apr 24, 2018 at 06:23:30PM +0100, Jonathan Cameron wrote: > Unless we know of ACPI firmwares out there that are doing this, drop the > patch for now. I don't want to see a flood of these based on a 'you can > do it that' way argument. Fair enough. I'll drop it for v3.

Re: [PATCH 0/4] selftests: rework RTC tests

On 04/19/2018 06:50 AM, Alexandre Belloni wrote: > Hi, > > This series separates tests using the RTC devices between the one > testing driver agnostic kernel facilities (timers) and the others that > are testing device drivers and hardware. > > Then, rtctest is reworked to use the test harness

Re: [PATCH 0/4] selftests: rework RTC tests

On 04/19/2018 06:50 AM, Alexandre Belloni wrote: > Hi, > > This series separates tests using the RTC devices between the one > testing driver agnostic kernel facilities (timers) and the others that > are testing device drivers and hardware. > > Then, rtctest is reworked to use the test harness

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

On Tue, Apr 24, 2018 at 8:48 PM, Christoph Hellwig wrote: > On Fri, Apr 20, 2018 at 05:21:11PM +0200, Daniel Vetter wrote: >> > At the very lowest level they will need to be handled differently for >> > many architectures, the questions is at what point we'll do the >> >

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

On Tue, Apr 24, 2018 at 8:48 PM, Christoph Hellwig wrote: > On Fri, Apr 20, 2018 at 05:21:11PM +0200, Daniel Vetter wrote: >> > At the very lowest level they will need to be handled differently for >> > many architectures, the questions is at what point we'll do the >> > branching out. >> >>

Re: [PATCH 03/11] platform: make support for early platform devices conditional

On 04/24/2018 10:30 AM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > Signed-off-by: Bartosz Golaszewski > --- > arch/sh/Kconfig | 1 + > drivers/base/Kconfig| 4 > drivers/base/platform.c

Re: [PATCH 03/11] platform: make support for early platform devices conditional

On 04/24/2018 10:30 AM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > Signed-off-by: Bartosz Golaszewski > --- > arch/sh/Kconfig | 1 + > drivers/base/Kconfig| 4 > drivers/base/platform.c | 3 +++ > include/linux/platform_device.h | 32

Fwd: [Bug 199473] New: pcieport does not scan devices behind PEX switch, while resources are allocated

Thanks for the report! I don't understand exactly what the issue is yet. You attached lspci output from v4.14.27 and v4.17-rc1. The v4.17-rc1 output shows several devices (4b:00, 4c:00, 4f:00) below the PEX switch, while the v4.14.27 output shows only the 4f:00 devices. Is the problem that

Fwd: [Bug 199473] New: pcieport does not scan devices behind PEX switch, while resources are allocated

Thanks for the report! I don't understand exactly what the issue is yet. You attached lspci output from v4.14.27 and v4.17-rc1. The v4.17-rc1 output shows several devices (4b:00, 4c:00, 4f:00) below the PEX switch, while the v4.14.27 output shows only the 4f:00 devices. Is the problem that

Re: [PATCH 4/5] perf parse-events: Specially handle uncore event alias in small groups

Em Tue, Apr 24, 2018 at 03:23:06PM -0400, Liang, Kan escreveu: > On 4/24/2018 3:17 PM, Arnaldo Carvalho de Melo wrote: > > Em Tue, Apr 24, 2018 at 11:20:13AM -0700, kan.li...@linux.intel.com > > escreveu: > > > From: Kan Liang > > > > > > Perf stat doesn't count the

Re: [PATCH 4/5] perf parse-events: Specially handle uncore event alias in small groups

Em Tue, Apr 24, 2018 at 03:23:06PM -0400, Liang, Kan escreveu: > On 4/24/2018 3:17 PM, Arnaldo Carvalho de Melo wrote: > > Em Tue, Apr 24, 2018 at 11:20:13AM -0700, kan.li...@linux.intel.com > > escreveu: > > > From: Kan Liang > > > > > > Perf stat doesn't count the uncore event aliases from

Re: [PATCH 5/5] perf stat: Fix duplicate PMU name for interval print

Em Tue, Apr 24, 2018 at 03:18:34PM -0400, Liang, Kan escreveu: > On 4/24/2018 2:53 PM, Arnaldo Carvalho de Melo wrote: > > Em Tue, Apr 24, 2018 at 11:20:14AM -0700, kan.li...@linux.intel.com > > escreveu: > > > + if (strstr(counter->name, counter->pmu_name)) > > > +

Re: [PATCH 5/5] perf stat: Fix duplicate PMU name for interval print

Em Tue, Apr 24, 2018 at 03:18:34PM -0400, Liang, Kan escreveu: > On 4/24/2018 2:53 PM, Arnaldo Carvalho de Melo wrote: > > Em Tue, Apr 24, 2018 at 11:20:14AM -0700, kan.li...@linux.intel.com > > escreveu: > > > + if (strstr(counter->name, counter->pmu_name)) > > > +

Re: vmalloc with GFP_NOFS

On Tue 24-04-18 21:03:43, Richard Weinberger wrote: > Am Dienstag, 24. April 2018, 18:27:12 CEST schrieb Michal Hocko: > > fs/ubifs/debug.c > > This one is just for debugging. > So, preallocating + locking would not hurt much. > > > fs/ubifs/lprops.c > > Ditto. > > > fs/ubifs/lpt_commit.c > >

Re: vmalloc with GFP_NOFS

On Tue 24-04-18 21:03:43, Richard Weinberger wrote: > Am Dienstag, 24. April 2018, 18:27:12 CEST schrieb Michal Hocko: > > fs/ubifs/debug.c > > This one is just for debugging. > So, preallocating + locking would not hurt much. > > > fs/ubifs/lprops.c > > Ditto. > > > fs/ubifs/lpt_commit.c > >

Re: [PATCH v5 0/2] perf: riscv: Preliminary Perf Event Support on RISC-V

On 4/24/18 11:07 AM, Atish Patra wrote: On 4/19/18 4:28 PM, Alan Kao wrote: This implements the baseline PMU for RISC-V platforms. To ease future PMU portings, a guide is also written, containing perf concepts, arch porting practices and some hints. Changes in v5: - Fix patch errors from

Re: [RFC PATCH] perf tools: allow map files to specify DSO

Em Tue, Apr 24, 2018 at 02:49:09PM -0400, Josh Hunt escreveu: > Add the ability to specify a DSO in the /tmp/perf-.map file. > The DSO should be the first line in the file and readable by the > running user. If a valid DSO is found all other contents of the > file will be ignored. This allows

Re: [PATCH v5 0/2] perf: riscv: Preliminary Perf Event Support on RISC-V

On 4/24/18 11:07 AM, Atish Patra wrote: On 4/19/18 4:28 PM, Alan Kao wrote: This implements the baseline PMU for RISC-V platforms. To ease future PMU portings, a guide is also written, containing perf concepts, arch porting practices and some hints. Changes in v5: - Fix patch errors from

Re: [RFC PATCH] perf tools: allow map files to specify DSO

Em Tue, Apr 24, 2018 at 02:49:09PM -0400, Josh Hunt escreveu: > Add the ability to specify a DSO in the /tmp/perf-.map file. > The DSO should be the first line in the file and readable by the > running user. If a valid DSO is found all other contents of the > file will be ignored. This allows

Re: vmalloc with GFP_NOFS

Hi, On 24/04/18 17:27, Michal Hocko wrote: Hi, it seems that we still have few vmalloc users who perform GFP_NOFS allocation: drivers/mtd/ubi/io.c fs/ext4/xattr.c fs/gfs2/dir.c fs/gfs2/quota.c fs/nfs/blocklayout/extent_tree.c fs/ubifs/debug.c fs/ubifs/lprops.c fs/ubifs/lpt_commit.c

Re: vmalloc with GFP_NOFS

Hi, On 24/04/18 17:27, Michal Hocko wrote: Hi, it seems that we still have few vmalloc users who perform GFP_NOFS allocation: drivers/mtd/ubi/io.c fs/ext4/xattr.c fs/gfs2/dir.c fs/gfs2/quota.c fs/nfs/blocklayout/extent_tree.c fs/ubifs/debug.c fs/ubifs/lprops.c fs/ubifs/lpt_commit.c

Re: [PATCH] do not call trace_printk on non-debug build

On Tue, 24 Apr 2018 19:20:03 + Wei Wang wrote: > checkpatch.pl sounds good. One thing to add is we have many off tree > patches with abuse trace_printk. Also as you mentioned, given this is > really not for use in production and we have been cleaning this our on our > side

Re: [PATCH] do not call trace_printk on non-debug build

On Tue, 24 Apr 2018 19:20:03 + Wei Wang wrote: > checkpatch.pl sounds good. One thing to add is we have many off tree > patches with abuse trace_printk. Also as you mentioned, given this is > really not for use in production and we have been cleaning this our on our > side for years, could

Re: vmalloc with GFP_NOFS

On Tue 24-04-18 14:35:36, Theodore Ts'o wrote: > On Tue, Apr 24, 2018 at 10:27:12AM -0600, Michal Hocko wrote: > > fs/ext4/xattr.c > > > > What to do about this? Well, there are two things. Firstly, it would be > > really great to double check whether the GFP_NOFS is really needed. I > > cannot

Re: vmalloc with GFP_NOFS

On Tue 24-04-18 14:35:36, Theodore Ts'o wrote: > On Tue, Apr 24, 2018 at 10:27:12AM -0600, Michal Hocko wrote: > > fs/ext4/xattr.c > > > > What to do about this? Well, there are two things. Firstly, it would be > > really great to double check whether the GFP_NOFS is really needed. I > > cannot

Re: [PATCH 4/5] perf parse-events: Specially handle uncore event alias in small groups

On 4/24/2018 3:17 PM, Arnaldo Carvalho de Melo wrote: Em Tue, Apr 24, 2018 at 11:20:13AM -0700, kan.li...@linux.intel.com escreveu: From: Kan Liang Perf stat doesn't count the uncore event aliases from the same uncore block in a group, for example: This one is

Re: [PATCH 4/5] perf parse-events: Specially handle uncore event alias in small groups

On 4/24/2018 3:17 PM, Arnaldo Carvalho de Melo wrote: Em Tue, Apr 24, 2018 at 11:20:13AM -0700, kan.li...@linux.intel.com escreveu: From: Kan Liang Perf stat doesn't count the uncore event aliases from the same uncore block in a group, for example: This one is not applying to

Re: [PATCH 0/2] selftests: tracing: Update inter-event testcases

On Thu, 5 Apr 2018 18:28:11 +0900 Masami Hiramatsu wrote: > Hi, > > I've fixed a testcase for inter-event extended error > and added a testcase for multiple actions on trigger, > which is based on what Tom shown in his mail. > > This series can be applied on Steven's

Re: [PATCH 0/2] selftests: tracing: Update inter-event testcases

On Thu, 5 Apr 2018 18:28:11 +0900 Masami Hiramatsu wrote: > Hi, > > I've fixed a testcase for inter-event extended error > and added a testcase for multiple actions on trigger, > which is based on what Tom shown in his mail. > > This series can be applied on Steven's tracing repo. > >

[PATCH] tick/sched: Do not mess with an enqueued hrtimer

Kaike reported that in tests rdma hrtimers occasionaly stopped working. He did great debugging, which provided enough context to decode the problem. CPU 3CPU 2 idle start sched_timer expires = 71217100 queue->next = sched_timer

[PATCH] tick/sched: Do not mess with an enqueued hrtimer

Kaike reported that in tests rdma hrtimers occasionaly stopped working. He did great debugging, which provided enough context to decode the problem. CPU 3CPU 2 idle start sched_timer expires = 71217100 queue->next = sched_timer

Re: [PATCH v4 03/19] powerpc: Mark variable `l` as unused, remove `path`

Le 06/04/2018 à 20:32, Mathieu Malaterre a écrit : On Fri, Apr 6, 2018 at 5:33 PM, LEROY Christophe wrote: Mathieu Malaterre a écrit : Add gcc attribute unused for `l` variable, replace `path` variable directly with prom_scratch. Fix warnings

Re: [PATCH v4 03/19] powerpc: Mark variable `l` as unused, remove `path`

Le 06/04/2018 à 20:32, Mathieu Malaterre a écrit : On Fri, Apr 6, 2018 at 5:33 PM, LEROY Christophe wrote: Mathieu Malaterre a écrit : Add gcc attribute unused for `l` variable, replace `path` variable directly with prom_scratch. Fix warnings treated as errors with W=1:

Re: [PATCH] do not call trace_printk on non-debug build

checkpatch.pl sounds good. One thing to add is we have many off tree patches with abuse trace_printk. Also as you mentioned, given this is really not for use in production and we have been cleaning this our on our side for years, could we consider to enforce this in kernel? Thanks! Wei On Tue,

Re: [PATCH] do not call trace_printk on non-debug build

checkpatch.pl sounds good. One thing to add is we have many off tree patches with abuse trace_printk. Also as you mentioned, given this is really not for use in production and we have been cleaning this our on our side for years, could we consider to enforce this in kernel? Thanks! Wei On Tue,

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