Re: KASAN: use-after-free Read in sctp_association_free (2)

On Sat, Mar 10, 2018 at 6:08 AM, Neil Horman wrote: > On Fri, Mar 09, 2018 at 12:59:06PM -0800, syzbot wrote: >> Hello, >> >> syzbot hit the following crash on net-next commit >> fd372a7a9e5e9d8011a0222d10edd3523abcd3b1 (Thu Mar 8 19:43:48 2018 +) >> Merge tag

Re: KASAN: use-after-free Read in sctp_association_free (2)

On Sat, Mar 10, 2018 at 6:08 AM, Neil Horman wrote: > On Fri, Mar 09, 2018 at 12:59:06PM -0800, syzbot wrote: >> Hello, >> >> syzbot hit the following crash on net-next commit >> fd372a7a9e5e9d8011a0222d10edd3523abcd3b1 (Thu Mar 8 19:43:48 2018 +) >> Merge tag 'mlx5-updates-2018-02-28-2' of

[PATCH 2/2] drivers: android: binder: fixed a brace coding style issue

Fixed a coding style issue. Signed-off-by: Vaibhav Murkute --- drivers/android/binder.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/android/binder.c b/drivers/android/binder.c index 764b63a5aade..2729bb75ca19 100644 ---

[PATCH 2/2] drivers: android: binder: fixed a brace coding style issue

Fixed a coding style issue. Signed-off-by: Vaibhav Murkute --- drivers/android/binder.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/android/binder.c b/drivers/android/binder.c index 764b63a5aade..2729bb75ca19 100644 --- a/drivers/android/binder.c +++

[PATCH v2] net: ipv6: xfrm6_state: remove VLA usage

The kernel would like to have all stack VLA usage removed[1]. Instead of dynamic allocation, just use XFRM_MAX_DEPTH as already done for the "class" array, but as per feedback, I will not drop maxclass because that changes the behavior. In one case, it'll do this loop up to 5, the other caller up

[PATCH v2] net: ipv6: xfrm6_state: remove VLA usage

The kernel would like to have all stack VLA usage removed[1]. Instead of dynamic allocation, just use XFRM_MAX_DEPTH as already done for the "class" array, but as per feedback, I will not drop maxclass because that changes the behavior. In one case, it'll do this loop up to 5, the other caller up

RE: [RFC/RFT][PATCH v3 0/6] sched/cpuidle: Idle loop rework

On 2018.03.09 07:19 Rik van Riel wrote: > On Fri, 2018-03-09 at 10:34 +0100, Rafael J. Wysocki wrote: >> Hi All, >> >> Thanks a lot for the discussion and testing so far! >> >> This is a total respin of the whole series, so please look at it >> afresh. >> Patches 2 and 3 are the most similar to

RE: [RFC/RFT][PATCH v3 0/6] sched/cpuidle: Idle loop rework

On 2018.03.09 07:19 Rik van Riel wrote: > On Fri, 2018-03-09 at 10:34 +0100, Rafael J. Wysocki wrote: >> Hi All, >> >> Thanks a lot for the discussion and testing so far! >> >> This is a total respin of the whole series, so please look at it >> afresh. >> Patches 2 and 3 are the most similar to

Re: [PATCH 4.14 1/4] powerpc/mm/slice: Remove intermediate bitmap copy

, it is there https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/powerpc/mm/slice.c?h=next-20180309=326691ad4f179e6edc7eb1271e618dd673e4736d The id seems to be exactly the same. Christophe thanks, greg k-h --- L'absence de virus dans ce courrier électronique a été vérifiée par

Re: [PATCH 4.14 1/4] powerpc/mm/slice: Remove intermediate bitmap copy

, it is there https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/powerpc/mm/slice.c?h=next-20180309=326691ad4f179e6edc7eb1271e618dd673e4736d The id seems to be exactly the same. Christophe thanks, greg k-h --- L'absence de virus dans ce courrier électronique a été vérifiée par

[tip:x86/pti] x86/kprobes: Fix kernel crash when probing .entry_trampoline code

Commit-ID: c07a8f8b08ba683ea24f3ac9159f37ae94daf47f Gitweb: https://git.kernel.org/tip/c07a8f8b08ba683ea24f3ac9159f37ae94daf47f Author: Francis Deslauriers AuthorDate: Thu, 8 Mar 2018 22:18:12 -0500 Committer: Ingo Molnar CommitDate:

[tip:x86/pti] x86/kprobes: Fix kernel crash when probing .entry_trampoline code

Commit-ID: c07a8f8b08ba683ea24f3ac9159f37ae94daf47f Gitweb: https://git.kernel.org/tip/c07a8f8b08ba683ea24f3ac9159f37ae94daf47f Author: Francis Deslauriers AuthorDate: Thu, 8 Mar 2018 22:18:12 -0500 Committer: Ingo Molnar CommitDate: Fri, 9 Mar 2018 09:58:36 +0100 x86/kprobes: Fix

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Sat, Mar 10, 2018 at 7:10 AM, Miguel Ojeda wrote: > On Sat, Mar 10, 2018 at 4:11 AM, Randy Dunlap wrote: >> On 03/09/2018 04:07 PM, Andrew Morton wrote: >>> On Fri, 9 Mar 2018 12:05:36 -0800 Kees Cook wrote: >>>

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Sat, Mar 10, 2018 at 7:10 AM, Miguel Ojeda wrote: > On Sat, Mar 10, 2018 at 4:11 AM, Randy Dunlap wrote: >> On 03/09/2018 04:07 PM, Andrew Morton wrote: >>> On Fri, 9 Mar 2018 12:05:36 -0800 Kees Cook wrote: >>> When max() is used in stack array size calculations from literal values

[PATCH v5 04/11] ext2, dax: introduce ext2_dax_aops

In preparation for the dax implementation to start associating dax pages to inodes via page->mapping, we need to provide a 'struct address_space_operations' instance for dax. Otherwise, direct-I/O triggers incorrect page cache assumptions and warnings. Cc: Jan Kara Signed-off-by:

[PATCH v5 04/11] ext2, dax: introduce ext2_dax_aops

In preparation for the dax implementation to start associating dax pages to inodes via page->mapping, we need to provide a 'struct address_space_operations' instance for dax. Otherwise, direct-I/O triggers incorrect page cache assumptions and warnings. Cc: Jan Kara Signed-off-by: Dan Williams

[PATCH v5 08/11] wait_bit: introduce {wait_on,wake_up}_atomic_one

Add a generic facility for awaiting an atomic_t to reach a value of 1. Page reference counts typically need to reach 0 to be considered a free / inactive page. However, ZONE_DEVICE pages allocated via devm_memremap_pages() are never 'onlined', i.e. the put_page() typically done at init time to

[PATCH v5 08/11] wait_bit: introduce {wait_on,wake_up}_atomic_one

Add a generic facility for awaiting an atomic_t to reach a value of 1. Page reference counts typically need to reach 0 to be considered a free / inactive page. However, ZONE_DEVICE pages allocated via devm_memremap_pages() are never 'onlined', i.e. the put_page() typically done at init time to

[PATCH v5 02/11] xfs, dax: introduce xfs_dax_aops

In preparation for the dax implementation to start associating dax pages to inodes via page->mapping, we need to provide a 'struct address_space_operations' instance for dax. Otherwise, direct-I/O triggers incorrect page cache assumptions and warnings like the following: WARNING: CPU: 27 PID:

[PATCH v5 05/11] fs, dax: use page->mapping to warn if truncate collides with a busy page

Catch cases where extent unmap operations encounter pages that are pinned / busy. Typically this is pinned pages that are under active dma. This warning is a canary for potential data corruption as truncated blocks could be allocated to a new file while the device is still performing i/o. Here is

[PATCH v5 10/11] xfs: prepare xfs_break_layouts() for another layout type

When xfs is operating as the back-end of a pNFS block server, it prevents collisions between local and remote operations by requiring a lease to be held for remotely accessed blocks. Local filesystem operations break those leases before writing or mutating the extent map of the file. A similar

[PATCH v5 10/11] xfs: prepare xfs_break_layouts() for another layout type

When xfs is operating as the back-end of a pNFS block server, it prevents collisions between local and remote operations by requiring a lease to be held for remotely accessed blocks. Local filesystem operations break those leases before writing or mutating the extent map of the file. A similar

[PATCH v5 05/11] fs, dax: use page->mapping to warn if truncate collides with a busy page

Catch cases where extent unmap operations encounter pages that are pinned / busy. Typically this is pinned pages that are under active dma. This warning is a canary for potential data corruption as truncated blocks could be allocated to a new file while the device is still performing i/o. Here is

[PATCH v5 02/11] xfs, dax: introduce xfs_dax_aops

In preparation for the dax implementation to start associating dax pages to inodes via page->mapping, we need to provide a 'struct address_space_operations' instance for dax. Otherwise, direct-I/O triggers incorrect page cache assumptions and warnings like the following: WARNING: CPU: 27 PID:

[PATCH v5 06/11] mm, dax: enable filesystems to trigger dev_pagemap ->page_free callbacks

In order to resolve collisions between filesystem operations and DMA to DAX mapped pages we need a callback when DMA completes. With a callback we can hold off filesystem operations while DMA is in-flight and then resume those operations when the last put_page() occurs on a DMA page. Recall that

[PATCH v5 03/11] ext4, dax: introduce ext4_dax_aops

In preparation for the dax implementation to start associating dax pages to inodes via page->mapping, we need to provide a 'struct address_space_operations' instance for dax. Otherwise, direct-I/O triggers incorrect page cache assumptions and warnings. Cc: "Theodore Ts'o" Cc:

[PATCH v5 11/11] xfs, dax: introduce xfs_break_dax_layouts()

xfs_break_dax_layouts(), similar to xfs_break_leased_layouts(), scans for busy / pinned dax pages and waits for those pages to go idle before any potential extent unmap operation. dax_layout_busy_page() handles synchronizing against new page-busy events (get_user_pages). It invalidates all

[PATCH v5 06/11] mm, dax: enable filesystems to trigger dev_pagemap ->page_free callbacks

In order to resolve collisions between filesystem operations and DMA to DAX mapped pages we need a callback when DMA completes. With a callback we can hold off filesystem operations while DMA is in-flight and then resume those operations when the last put_page() occurs on a DMA page. Recall that

[PATCH v5 03/11] ext4, dax: introduce ext4_dax_aops

In preparation for the dax implementation to start associating dax pages to inodes via page->mapping, we need to provide a 'struct address_space_operations' instance for dax. Otherwise, direct-I/O triggers incorrect page cache assumptions and warnings. Cc: "Theodore Ts'o" Cc: Andreas Dilger Cc:

[PATCH v5 11/11] xfs, dax: introduce xfs_break_dax_layouts()

xfs_break_dax_layouts(), similar to xfs_break_leased_layouts(), scans for busy / pinned dax pages and waits for those pages to go idle before any potential extent unmap operation. dax_layout_busy_page() handles synchronizing against new page-busy events (get_user_pages). It invalidates all

[PATCH v5 07/11] mm, dev_pagemap: introduce CONFIG_DEV_PAGEMAP_OPS

The HMM sub-system extended dev_pagemap to arrange a callback when a dev_pagemap managed page is freed. Since a dev_pagemap page is free / idle when its reference count is 1 it requires an additional branch to check the page-type at put_page() time. Given put_page() is a hot-path we do not want to

[PATCH v5 07/11] mm, dev_pagemap: introduce CONFIG_DEV_PAGEMAP_OPS

The HMM sub-system extended dev_pagemap to arrange a callback when a dev_pagemap managed page is freed. Since a dev_pagemap page is free / idle when its reference count is 1 it requires an additional branch to check the page-type at put_page() time. Given put_page() is a hot-path we do not want to

[PATCH v5 09/11] mm, fs, dax: handle layout changes to pinned dax mappings

Background: get_user_pages() in the filesystem pins file backed memory pages for access by devices performing dma. However, it only pins the memory pages not the page-to-file offset association. If a file is truncated the pages are mapped out of the file and dma may continue indefinitely into a

[PATCH v5 09/11] mm, fs, dax: handle layout changes to pinned dax mappings

Background: get_user_pages() in the filesystem pins file backed memory pages for access by devices performing dma. However, it only pins the memory pages not the page-to-file offset association. If a file is truncated the pages are mapped out of the file and dma may continue indefinitely into a

[PATCH v5 00/11] dax: fix dma vs truncate/hole-punch

Changes since v4 [1]: * Kill the DEFINE_FSDAX_AOPS macro and just open code new address_space_operations instances for each fs (Matthew, Jan, Dave, Christoph) * Rename routines that had a 'dma_' prefix with 'dax_layout_' and merge the dax-layout-break into xfs_break_layouts() (Dave,

[PATCH v5 00/11] dax: fix dma vs truncate/hole-punch

Changes since v4 [1]: * Kill the DEFINE_FSDAX_AOPS macro and just open code new address_space_operations instances for each fs (Matthew, Jan, Dave, Christoph) * Rename routines that had a 'dma_' prefix with 'dax_layout_' and merge the dax-layout-break into xfs_break_layouts() (Dave,

[PATCH v5 01/11] dax: store pfns in the radix

In preparation for examining the busy state of dax pages in the truncate path, switch from sectors to pfns in the radix. Cc: Jeff Moyer Cc: Christoph Hellwig Cc: Matthew Wilcox Cc: Ross Zwisler Reviewed-by:

[PATCH v5 01/11] dax: store pfns in the radix

In preparation for examining the busy state of dax pages in the truncate path, switch from sectors to pfns in the radix. Cc: Jeff Moyer Cc: Christoph Hellwig Cc: Matthew Wilcox Cc: Ross Zwisler Reviewed-by: Jan Kara Signed-off-by: Dan Williams --- drivers/dax/super.c | 15 +++--

[PATCH 2/2] rtc: s5m: Remove VLA usage

In preparation to enabling -Wvla, remove VLAs and replace them with fixed-length arrays instead. >From a security viewpoint, the use of Variable Length Arrays can be a vector for stack overflow attacks. Also, in general, as the code evolves it is easy to lose track of how big a VLA can get. Thus,

[PATCH 2/2] rtc: s5m: Remove VLA usage

In preparation to enabling -Wvla, remove VLAs and replace them with fixed-length arrays instead. >From a security viewpoint, the use of Variable Length Arrays can be a vector for stack overflow attacks. Also, in general, as the code evolves it is easy to lose track of how big a VLA can get. Thus,

Re: [PATCH v2 3/3] ALSA: hda: Disabled unused audio controller for Dell platforms with Switchable Graphics

On Fri, Mar 09, 2018 at 05:30:15PM +0800, Kai Heng Feng wrote: > >On Thursday 08 March 2018 17:10:23 Kai-Heng Feng wrote: > >>Some Dell platforms (Preicsion 7510/7710/7520/7720) have a BIOS option > >>"Switchable Graphics" (SG). > >> > >>When SG is enabled, we have: > >>00:02.0 VGA compatible

Re: [PATCH v2 3/3] ALSA: hda: Disabled unused audio controller for Dell platforms with Switchable Graphics

On Fri, Mar 09, 2018 at 05:30:15PM +0800, Kai Heng Feng wrote: > >On Thursday 08 March 2018 17:10:23 Kai-Heng Feng wrote: > >>Some Dell platforms (Preicsion 7510/7710/7520/7720) have a BIOS option > >>"Switchable Graphics" (SG). > >> > >>When SG is enabled, we have: > >>00:02.0 VGA compatible

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

On 03/09/2018 09:55 PM, Ram Pai wrote: > On Fri, Mar 09, 2018 at 02:40:32PM -0800, Dave Hansen wrote: >> On 03/09/2018 12:12 AM, Ram Pai wrote: >>> Once an address range is associated with an allocated pkey, it cannot be >>> reverted back to key-0. There is no valid reason for the above behavior.

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

On 03/09/2018 09:55 PM, Ram Pai wrote: > On Fri, Mar 09, 2018 at 02:40:32PM -0800, Dave Hansen wrote: >> On 03/09/2018 12:12 AM, Ram Pai wrote: >>> Once an address range is associated with an allocated pkey, it cannot be >>> reverted back to key-0. There is no valid reason for the above behavior.

[PATCH] vgacon: fix function prototypes

It is possible to indirectly invoke functions with prototypes that do not match those of the respectively used function pointers by using void types. Despite widely used as a feature for relaxing function invocation, this should be avoided when possible as it may prevent the use of heuristics such

[PATCH] vgacon: fix function prototypes

It is possible to indirectly invoke functions with prototypes that do not match those of the respectively used function pointers by using void types. Despite widely used as a feature for relaxing function invocation, this should be avoided when possible as it may prevent the use of heuristics such

[PATCH 0/2] Remove VLA usage in rtc-s5m

This patchset aims to remove VLA usage from rtc-s5m. The first patch moves an enum from rtc.h to rtc-s5m.c, as this is the only driver in which such enum is actually being used [1]. The second patch adds the enum name RTC_MAX_NUM_TIME_REGS, which will be used as a maximum length to the current

[PATCH 0/2] Remove VLA usage in rtc-s5m

This patchset aims to remove VLA usage from rtc-s5m. The first patch moves an enum from rtc.h to rtc-s5m.c, as this is the only driver in which such enum is actually being used [1]. The second patch adds the enum name RTC_MAX_NUM_TIME_REGS, which will be used as a maximum length to the current

[PATCH 1/2] rtc: s5m: Move enum from rtc.h to rtc-s5m.c

Move this enum to rtc-s5m.c once it is meaningless to others drivers [1]. [1] https://marc.info/?l=linux-rtc=152060068925948=2 Signed-off-by: Gustavo A. R. Silva --- drivers/rtc/rtc-s5m.c | 11 +++ include/linux/mfd/samsung/rtc.h | 11 --- 2

[PATCH 1/2] rtc: s5m: Move enum from rtc.h to rtc-s5m.c

Move this enum to rtc-s5m.c once it is meaningless to others drivers [1]. [1] https://marc.info/?l=linux-rtc=152060068925948=2 Signed-off-by: Gustavo A. R. Silva --- drivers/rtc/rtc-s5m.c | 11 +++ include/linux/mfd/samsung/rtc.h | 11 --- 2 files changed, 11

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Sat, Mar 10, 2018 at 4:11 AM, Randy Dunlap wrote: > On 03/09/2018 04:07 PM, Andrew Morton wrote: >> On Fri, 9 Mar 2018 12:05:36 -0800 Kees Cook wrote: >> >>> When max() is used in stack array size calculations from literal values >>> (e.g. "char

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Sat, Mar 10, 2018 at 4:11 AM, Randy Dunlap wrote: > On 03/09/2018 04:07 PM, Andrew Morton wrote: >> On Fri, 9 Mar 2018 12:05:36 -0800 Kees Cook wrote: >> >>> When max() is used in stack array size calculations from literal values >>> (e.g. "char foo[max(sizeof(struct1), sizeof(struct2))]",

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

On Fri, Mar 09, 2018 at 02:40:32PM -0800, Dave Hansen wrote: > On 03/09/2018 12:12 AM, Ram Pai wrote: > > Once an address range is associated with an allocated pkey, it cannot be > > reverted back to key-0. There is no valid reason for the above behavior. On > > the contrary applications need the

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

On Fri, Mar 09, 2018 at 02:40:32PM -0800, Dave Hansen wrote: > On 03/09/2018 12:12 AM, Ram Pai wrote: > > Once an address range is associated with an allocated pkey, it cannot be > > reverted back to key-0. There is no valid reason for the above behavior. On > > the contrary applications need the

Re: [PATCH v2 0/3] drm: Add LVDS decoder bridge

Hi, On Friday 09 March 2018 07:21 PM, Jacopo Mondi wrote: Hello, after some discussion on the proposed bindings for generic lvds decoder and Thine THC63LVD1024, I decided to drop the THC63 specific part and just live with a transparent decoder that does not support any configuration from

Re: [PATCH v2 0/3] drm: Add LVDS decoder bridge

Hi, On Friday 09 March 2018 07:21 PM, Jacopo Mondi wrote: Hello, after some discussion on the proposed bindings for generic lvds decoder and Thine THC63LVD1024, I decided to drop the THC63 specific part and just live with a transparent decoder that does not support any configuration from

[5/5 V3] tpm: factor out tpm_get_timeouts

Factor out tpm_get_timeouts into tpm2_get_timeouts and tpm1_get_timeouts. Signed-off-by: Tomas Winkler --- V2: Rebase V3: 1. Fix typo tmp->tpm 2. Fix sparse WARNING: line over 80 characters drivers/char/tpm/tpm-interface.c | 127

[5/5 V3] tpm: factor out tpm_get_timeouts

Factor out tpm_get_timeouts into tpm2_get_timeouts and tpm1_get_timeouts. Signed-off-by: Tomas Winkler --- V2: Rebase V3: 1. Fix typo tmp->tpm 2. Fix sparse WARNING: line over 80 characters drivers/char/tpm/tpm-interface.c | 127 ++-

[GIT PULL] ARM: at91: DT for 4.17

Arnd, Olof, Not much this cycle, mainly changes on the Axentia boards from Peter and a cleanup from Bartosz. The following changes since commit 7928b2cbe55b2a410a0f5c1f154610059c57b1b2: Linux 4.16-rc1 (2018-02-11 15:04:29 -0800) are available in the Git repository at:

[GIT PULL] ARM: at91: DT for 4.17

Arnd, Olof, Not much this cycle, mainly changes on the Axentia boards from Peter and a cleanup from Bartosz. The following changes since commit 7928b2cbe55b2a410a0f5c1f154610059c57b1b2: Linux 4.16-rc1 (2018-02-11 15:04:29 -0800) are available in the Git repository at:

[PATCH] rbd: Remove VLA usage

>From 4198ebe2e8058ff676d8e2f993d8806d6ca29c11 Mon Sep 17 00:00:00 2001 From: Kyle Spiers Date: Fri, 9 Mar 2018 12:34:15 -0800 Subject: [PATCH] rbd: Remove VLA usage As part of the effort to remove VLAs from the kernel[1], this moves the literal values into the stack array

[PATCH] rbd: Remove VLA usage

>From 4198ebe2e8058ff676d8e2f993d8806d6ca29c11 Mon Sep 17 00:00:00 2001 From: Kyle Spiers Date: Fri, 9 Mar 2018 12:34:15 -0800 Subject: [PATCH] rbd: Remove VLA usage As part of the effort to remove VLAs from the kernel[1], this moves the literal values into the stack array calculation instead of

[GIT PULL] ARM: at91: SoC for 4.17

Arnd, Olof, It has been two years that Atmel merge with Microchip, rename where relevant. This is based on my fixes PR which is already in next/soc. Tell me if this is not right. The following changes since commit c8d5dcf122b194e897d2a6311903eae0c1023325: MAINTAINERS: ARM: at91: update my

[GIT PULL] ARM: at91: SoC for 4.17

Arnd, Olof, It has been two years that Atmel merge with Microchip, rename where relevant. This is based on my fixes PR which is already in next/soc. Tell me if this is not right. The following changes since commit c8d5dcf122b194e897d2a6311903eae0c1023325: MAINTAINERS: ARM: at91: update my

Re: [PATCH 3.18 00/21] 3.18.99-stable review

On 03/09/2018 05:18 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.99 release. > There are 21 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 3.18 00/21] 3.18.99-stable review

On 03/09/2018 05:18 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.99 release. > There are 21 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 4.4 00/36] 4.4.121-stable review

On 03/09/2018 05:18 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.121 release. > There are 36 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 4.4 00/36] 4.4.121-stable review

On 03/09/2018 05:18 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.121 release. > There are 36 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 4.9 00/65] 4.9.87-stable review

On 03/09/2018 05:18 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.87 release. > There are 65 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 4.9 00/65] 4.9.87-stable review

On 03/09/2018 05:18 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.87 release. > There are 65 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 4.14 0/9] 4.14.26-stable review

On 03/09/2018 05:19 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.26 release. > There are 9 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 4.14 0/9] 4.14.26-stable review

On 03/09/2018 05:19 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.26 release. > There are 9 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 4.15 00/11] 4.15.9-stable review

On 03/09/2018 05:19 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.15.9 release. > There are 11 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 4.15 00/11] 4.15.9-stable review

On 03/09/2018 05:19 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.15.9 release. > There are 11 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: [RFC 3/3] arch/x86/kvm: SVM: Introduce pause loop exit logic in SVM

Radim, Thanks for the comments. Taken care of most of the comments. I have few questions/comments. Please see inline. > -Original Message- > From: Radim Krčmář > Sent: Friday, March 9, 2018 12:13 PM > To: Moger, Babu > Cc: j...@8bytes.org;

RE: [RFC 3/3] arch/x86/kvm: SVM: Introduce pause loop exit logic in SVM

Radim, Thanks for the comments. Taken care of most of the comments. I have few questions/comments. Please see inline. > -Original Message- > From: Radim Krčmář > Sent: Friday, March 9, 2018 12:13 PM > To: Moger, Babu > Cc: j...@8bytes.org; t...@linutronix.de; mi...@redhat.com; >

Re: [PATCH 1/2] watchdog: dw: RMW the control register

On Fri, Mar 9, 2018 at 8:02 PM, Guenter Roeck wrote: > On 03/09/2018 07:28 PM, Brian Norris wrote: >> I guess I could mention it. I was assuming that was an intended behavior >> of the existing driver: that we set resp_mode=0 (via clobber), so we >> always get a system reset

Re: [PATCH 1/2] watchdog: dw: RMW the control register

On Fri, Mar 9, 2018 at 8:02 PM, Guenter Roeck wrote: > On 03/09/2018 07:28 PM, Brian Norris wrote: >> I guess I could mention it. I was assuming that was an intended behavior >> of the existing driver: that we set resp_mode=0 (via clobber), so we >> always get a system reset (we don't try to

Re: [RFC/RFT][PATCH v3 0/6] sched/cpuidle: Idle loop rework

On Fri, 2018-03-09 at 10:34 +0100, Rafael J. Wysocki wrote: > Hi All, > > Thanks a lot for the discussion and testing so far! > > This is a total respin of the whole series, so please look at it afresh. > Patches 2 and 3 are the most similar to their previous versions, but > still they are

Re: [RFC/RFT][PATCH v3 0/6] sched/cpuidle: Idle loop rework

On Fri, 2018-03-09 at 10:34 +0100, Rafael J. Wysocki wrote: > Hi All, > > Thanks a lot for the discussion and testing so far! > > This is a total respin of the whole series, so please look at it afresh. > Patches 2 and 3 are the most similar to their previous versions, but > still they are

RE: [PATCH 2/2] e1000e: Fix link check race condition

> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Benjamin Poirier > Sent: Monday, March 5, 2018 5:56 PM > To: Kirsher, Jeffrey T > Cc: Alexander Duyck ; Lennart Sorensen >

RE: [PATCH 2/2] e1000e: Fix link check race condition

> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Benjamin Poirier > Sent: Monday, March 5, 2018 5:56 PM > To: Kirsher, Jeffrey T > Cc: Alexander Duyck ; Lennart Sorensen > ; intel-wired-...@lists.osuosl.org; > net...@vger.kernel.org;

RE: [Intel-wired-lan] [PATCH 1/2] Revert "e1000e: Separate signaling for link check/link up"

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Benjamin Poirier > Sent: Monday, March 5, 2018 5:56 PM > To: Kirsher, Jeffrey T > Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux- > ker...@vger.kernel.org; Lennart

RE: [Intel-wired-lan] [PATCH 1/2] Revert "e1000e: Separate signaling for link check/link up"

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Benjamin Poirier > Sent: Monday, March 5, 2018 5:56 PM > To: Kirsher, Jeffrey T > Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux- > ker...@vger.kernel.org; Lennart Sorensen > Subject:

Re: [PATCH v4 03/10] drivers: qcom: rpmh-rsc: log RPMH requests in FTRACE

On Fri, Mar 09 2018 at 16:52 -0700, Steven Rostedt wrote: On Fri, 9 Mar 2018 16:25:36 -0700 Lina Iyer wrote: Log sent RPMH requests and interrupt responses in FTRACE. Cc: Steven Rostedt Signed-off-by: Lina Iyer --- Changes

Re: [PATCH v4 03/10] drivers: qcom: rpmh-rsc: log RPMH requests in FTRACE

On Fri, Mar 09 2018 at 16:52 -0700, Steven Rostedt wrote: On Fri, 9 Mar 2018 16:25:36 -0700 Lina Iyer wrote: Log sent RPMH requests and interrupt responses in FTRACE. Cc: Steven Rostedt Signed-off-by: Lina Iyer --- Changes in v4: - fix compilation issues, use __assign_str

Re: [PATCH] rtc: s5m: Remove VLA usage

Hi Krzysztof, On 03/09/2018 07:04 AM, Krzysztof Kozlowski wrote: On Thu, Mar 8, 2018 at 7:03 PM, Gustavo A. R. Silva wrote: On 03/08/2018 11:58 AM, Kees Cook wrote: On Thu, Mar 8, 2018 at 9:20 AM, Gustavo A. R. Silva wrote: In

Re: [PATCH] rtc: s5m: Remove VLA usage

Hi Krzysztof, On 03/09/2018 07:04 AM, Krzysztof Kozlowski wrote: On Thu, Mar 8, 2018 at 7:03 PM, Gustavo A. R. Silva wrote: On 03/08/2018 11:58 AM, Kees Cook wrote: On Thu, Mar 8, 2018 at 9:20 AM, Gustavo A. R. Silva wrote: In preparation to enabling -Wvla, remove VLAs and replace

Re: possible deadlock in get_user_pages_unlocked

On Fri, Feb 09, 2018 at 07:19:25PM -0800, Eric Biggers wrote: > Hi Al, > > On Sat, Feb 10, 2018 at 01:36:40AM +, Al Viro wrote: > > On Fri, Feb 02, 2018 at 09:57:27AM +0100, Dmitry Vyukov wrote: > > > > > syzbot tests for up to 5 minutes. However, if there is a race involved > > > then you

Re: possible deadlock in get_user_pages_unlocked

On Fri, Feb 09, 2018 at 07:19:25PM -0800, Eric Biggers wrote: > Hi Al, > > On Sat, Feb 10, 2018 at 01:36:40AM +, Al Viro wrote: > > On Fri, Feb 02, 2018 at 09:57:27AM +0100, Dmitry Vyukov wrote: > > > > > syzbot tests for up to 5 minutes. However, if there is a race involved > > > then you

Re: [PATCH v2 1/2] watchdog: dw: RMW the control register

On 03/09/2018 07:46 PM, Brian Norris wrote: RK3399 has rst_pulse_length in CONTROL_REG[4:2], determining the length of pulse to issue for system reset. We shouldn't clobber this value, because that might make the system reset ineffective. On RK3399, we're seeing that a value of 000b (meaning 2

Re: [PATCH v2 1/2] watchdog: dw: RMW the control register

On 03/09/2018 07:46 PM, Brian Norris wrote: RK3399 has rst_pulse_length in CONTROL_REG[4:2], determining the length of pulse to issue for system reset. We shouldn't clobber this value, because that might make the system reset ineffective. On RK3399, we're seeing that a value of 000b (meaning 2

Re: [PATCH 1/2] watchdog: dw: RMW the control register

Hi Brian, On 03/09/2018 07:28 PM, Brian Norris wrote: Hi, On Fri, Mar 09, 2018 at 07:20:38PM -0800, Guenter Roeck wrote: On 03/09/2018 06:44 PM, Brian Norris wrote: RK3399 has rst_pulse_length in CONTROL_REG[4:2], determining the length of pulse to issue for system reset. We shouldn't

Re: [PATCH 1/2] watchdog: dw: RMW the control register

Hi Brian, On 03/09/2018 07:28 PM, Brian Norris wrote: Hi, On Fri, Mar 09, 2018 at 07:20:38PM -0800, Guenter Roeck wrote: On 03/09/2018 06:44 PM, Brian Norris wrote: RK3399 has rst_pulse_length in CONTROL_REG[4:2], determining the length of pulse to issue for system reset. We shouldn't

[PATCH v2] Input: stmpe-keypad - remove VLA usage

In preparation to enabling -Wvla, remove VLA and replace it with a fixed-length array instead. Fixed as part of the directive to remove all VLAs from the kernel: https://lkml.org/lkml/2018/3/7/621 Signed-off-by: Gustavo A. R. Silva --- Changes in v2: - Update the code

[PATCH v2] Input: stmpe-keypad - remove VLA usage

In preparation to enabling -Wvla, remove VLA and replace it with a fixed-length array instead. Fixed as part of the directive to remove all VLAs from the kernel: https://lkml.org/lkml/2018/3/7/621 Signed-off-by: Gustavo A. R. Silva --- Changes in v2: - Update the code based on Dmitry Torokhov

Re: [PATCH] Input: stmpe-keypad - remove VLA usage

Hi Dmitry, On 03/09/2018 05:32 PM, Dmitry Torokhov wrote: On Fri, Mar 09, 2018 at 04:42:08PM -0600, Gustavo A. R. Silva wrote: In preparation to enabling -Wvla, remove VLA and replace it with a fixed-length array instead. Fixed as part of the directive to remove all VLAs from the kernel:

Re: [PATCH] Input: stmpe-keypad - remove VLA usage

Hi Dmitry, On 03/09/2018 05:32 PM, Dmitry Torokhov wrote: On Fri, Mar 09, 2018 at 04:42:08PM -0600, Gustavo A. R. Silva wrote: In preparation to enabling -Wvla, remove VLA and replace it with a fixed-length array instead. Fixed as part of the directive to remove all VLAs from the kernel:

[PATCH] EDAC, sb_edac: Remove VLA usage

In preparation to enabling -Wvla, remove VLA and replace it with a fixed-length array instead. Fixed as part of the directive to remove all VLAs from the kernel: https://lkml.org/lkml/2018/3/7/621 Signed-off-by: Gustavo A. R. Silva --- Notice that due to this change,

[PATCH] EDAC, sb_edac: Remove VLA usage

In preparation to enabling -Wvla, remove VLA and replace it with a fixed-length array instead. Fixed as part of the directive to remove all VLAs from the kernel: https://lkml.org/lkml/2018/3/7/621 Signed-off-by: Gustavo A. R. Silva --- Notice that due to this change, the field max_interleave

  1   2   3   4   5   6   7   8   9   10   >