Re: [PATCH] ext4: super.c: Update logging style using PR_CONT

On Wed, Oct 12, 2016 at 07:32:10AM -0700, Joe Perches wrote: > On Wed, 2016-10-12 at 12:41 +0200, Jan Kara wrote: > > On Tue 11-10-16 18:57:58, Joe Perches wrote: > > > Recent commit require line continuing printks to use PR_CONT. > > > > > > Update super.c to use PR_CONT and use vsprintf

Re: [PATCH] ext4: super.c: Update logging style using PR_CONT

On Wed, Oct 12, 2016 at 07:32:10AM -0700, Joe Perches wrote: > On Wed, 2016-10-12 at 12:41 +0200, Jan Kara wrote: > > On Tue 11-10-16 18:57:58, Joe Perches wrote: > > > Recent commit require line continuing printks to use PR_CONT. > > > > > > Update super.c to use PR_CONT and use vsprintf

Re: [RFC PATCH] mm, compaction: allow compaction for GFP_NOFS requests

On Fri, Oct 07, 2016 at 03:18:14PM +0200, Michal Hocko wrote: > On Thu 06-10-16 13:11:42, Dave Chinner wrote: > > On Wed, Oct 05, 2016 at 01:38:45PM +0200, Michal Hocko wrote: > > > On Wed 05-10-16 07:32:02, Dave Chinner wrote: > > > > On Tue, Oct 04, 2016 at 10:12:15AM +0200, Michal Hocko wrote:

Re: [RFC PATCH] mm, compaction: allow compaction for GFP_NOFS requests

On Fri, Oct 07, 2016 at 03:18:14PM +0200, Michal Hocko wrote: > On Thu 06-10-16 13:11:42, Dave Chinner wrote: > > On Wed, Oct 05, 2016 at 01:38:45PM +0200, Michal Hocko wrote: > > > On Wed 05-10-16 07:32:02, Dave Chinner wrote: > > > > On Tue, Oct 04, 2016 at 10:12:15AM +0200, Michal Hocko wrote:

[PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags

This patch series adjusts functions in the get_user_pages* family such that desired FOLL_* flags are passed as an argument rather than implied by flags. The purpose of this change is to make the use of FOLL_FORCE explicit so it is easier to grep for and clearer to callers that this flag is being

[PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags

This patch series adjusts functions in the get_user_pages* family such that desired FOLL_* flags are passed as an argument rather than implied by flags. The purpose of this change is to make the use of FOLL_FORCE explicit so it is easier to grep for and clearer to callers that this flag is being

Re: [PATCH v2] z3fold: add shrinker

On Wed, Oct 12, 2016 at 10:26:34AM +0200, Vitaly Wool wrote: > On Wed, 12 Oct 2016 09:52:06 +1100 > Dave Chinner wrote: > > > > > > > +static unsigned long z3fold_shrink_scan(struct shrinker *shrink, > > > + struct shrink_control *sc) > > > +{ > > >

[PATCH 03/10] mm: replace get_user_pages_unlocked() write/force parameters with gup_flags

This patch removes the write and force parameters from get_user_pages_unlocked() and replaces them with a gup_flags parameter to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by: Lorenzo

Re: [PATCH v2] z3fold: add shrinker

On Wed, Oct 12, 2016 at 10:26:34AM +0200, Vitaly Wool wrote: > On Wed, 12 Oct 2016 09:52:06 +1100 > Dave Chinner wrote: > > > > > > > +static unsigned long z3fold_shrink_scan(struct shrinker *shrink, > > > + struct shrink_control *sc) > > > +{ > > > + struct z3fold_pool

[PATCH 03/10] mm: replace get_user_pages_unlocked() write/force parameters with gup_flags

This patch removes the write and force parameters from get_user_pages_unlocked() and replaces them with a gup_flags parameter to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by: Lorenzo

[PATCH 01/10] mm: remove write/force parameters from __get_user_pages_locked()

This patch removes the write and force parameters from __get_user_pages_locked() to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by: Lorenzo Stoakes --- mm/gup.c |

[PATCH 01/10] mm: remove write/force parameters from __get_user_pages_locked()

This patch removes the write and force parameters from __get_user_pages_locked() to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by: Lorenzo Stoakes --- mm/gup.c | 47

[PATCH 02/10] mm: remove write/force parameters from __get_user_pages_unlocked()

This patch removes the write and force parameters from __get_user_pages_unlocked() to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by: Lorenzo Stoakes ---

[PATCH 02/10] mm: remove write/force parameters from __get_user_pages_unlocked()

This patch removes the write and force parameters from __get_user_pages_unlocked() to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by: Lorenzo Stoakes --- include/linux/mm.h | 3

Re: [RFC v2 PATCH] mm/percpu.c: fix panic triggered by BUG_ON() falsely

On 10/13/2016 05:41 AM, Andrew Morton wrote: > On Tue, 11 Oct 2016 22:00:28 +0800 zijun_hu wrote: > >> as shown by pcpu_build_alloc_info(), the number of units within a percpu >> group is educed by rounding up the number of CPUs within the group to >> @upa boundary, therefore,

Re: [RFC v2 PATCH] mm/percpu.c: fix panic triggered by BUG_ON() falsely

On 10/13/2016 05:41 AM, Andrew Morton wrote: > On Tue, 11 Oct 2016 22:00:28 +0800 zijun_hu wrote: > >> as shown by pcpu_build_alloc_info(), the number of units within a percpu >> group is educed by rounding up the number of CPUs within the group to >> @upa boundary, therefore, the number of CPUs

Re: [PATCH v3 3/4] mm: try to exhaust highatomic reserve before the OOM

Hi Michal, On Wed, Oct 12, 2016 at 10:34:50AM +0200, Michal Hocko wrote: > Looks much better. Thanks! I am wondering whether we want to have this > marked for stable. The patch is quite non-intrusive and fires only when > we are really OOM. It is definitely better to try harder than go and >

Re: [PATCH v3 3/4] mm: try to exhaust highatomic reserve before the OOM

Hi Michal, On Wed, Oct 12, 2016 at 10:34:50AM +0200, Michal Hocko wrote: > Looks much better. Thanks! I am wondering whether we want to have this > marked for stable. The patch is quite non-intrusive and fires only when > we are really OOM. It is definitely better to try harder than go and >

Re: [PATCH v3 3/6] pwm: imx: support output polarity inversion

On 2016-10-12 15:15, Lukasz Majewski wrote: > Hi Stefan, > >> On 2016-10-07 08:11, Bhuvanchandra DV wrote: >> > From: Lothar Wassmann >> > >> > The i.MX pwm unit on i.MX27 and newer SoCs provides a configurable >> > output polarity. This patch adds support to utilize

Re: [PATCH v3 3/6] pwm: imx: support output polarity inversion

On 2016-10-12 15:15, Lukasz Majewski wrote: > Hi Stefan, > >> On 2016-10-07 08:11, Bhuvanchandra DV wrote: >> > From: Lothar Wassmann >> > >> > The i.MX pwm unit on i.MX27 and newer SoCs provides a configurable >> > output polarity. This patch adds support to utilize this feature >> > where

[PATCH] f2fs: fix wrong sum_page pointer in f2fs_gc

This patch fixes using a wrong pointer for sum_page in f2fs_gc. Signed-off-by: Jaegeuk Kim --- fs/f2fs/gc.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c index e48142f..9c18917 100644 --- a/fs/f2fs/gc.c +++

[PATCH] f2fs: fix wrong sum_page pointer in f2fs_gc

This patch fixes using a wrong pointer for sum_page in f2fs_gc. Signed-off-by: Jaegeuk Kim --- fs/f2fs/gc.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c index e48142f..9c18917 100644 --- a/fs/f2fs/gc.c +++ b/fs/f2fs/gc.c @@ -854,16

Re: [PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem

Hi Inki, On 08/15/2016 10:40 PM, Inki Dae wrote: >> >> okay the very first commit that added IOMMU support >> introduced the code that rejects non-contig gem memory >> type without IOMMU. >> >> commit 0519f9a12d0113caab78980c48a7902d2bd40c2c >> Author: Inki Dae >> Date:

Re: [PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem

Hi Inki, On 08/15/2016 10:40 PM, Inki Dae wrote: >> >> okay the very first commit that added IOMMU support >> introduced the code that rejects non-contig gem memory >> type without IOMMU. >> >> commit 0519f9a12d0113caab78980c48a7902d2bd40c2c >> Author: Inki Dae >> Date: Sat Oct 20 07:53:42

Re: [PATCHv2 1/4] arm64: dump: Make ptdump debugfs a separate option

On 10/12/2016 03:45 PM, Kees Cook wrote: On Wed, Oct 12, 2016 at 3:31 PM, Laura Abbott wrote: ptdump_register currently initializes a set of page table information and registers debugfs. There are uses for the ptdump option without wanting the debugfs options. Split this

Re: [PATCHv2 1/4] arm64: dump: Make ptdump debugfs a separate option

On 10/12/2016 03:45 PM, Kees Cook wrote: On Wed, Oct 12, 2016 at 3:31 PM, Laura Abbott wrote: ptdump_register currently initializes a set of page table information and registers debugfs. There are uses for the ptdump option without wanting the debugfs options. Split this out to make it a

Re: [PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem

On 10/12/2016 05:11 PM, Shuah Khan wrote: + Fixing Krzysztof Kozlowski address. > Hi Inki, > > On 08/15/2016 10:40 PM, Inki Dae wrote: > >>> >>> okay the very first commit that added IOMMU support >>> introduced the code that rejects non-contig gem memory >>> type without IOMMU. >>> >>> commit

Re: [PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem

On 10/12/2016 05:11 PM, Shuah Khan wrote: + Fixing Krzysztof Kozlowski address. > Hi Inki, > > On 08/15/2016 10:40 PM, Inki Dae wrote: > >>> >>> okay the very first commit that added IOMMU support >>> introduced the code that rejects non-contig gem memory >>> type without IOMMU. >>> >>> commit

Re: [PATCHv2 1/4] arm64: dump: Make ptdump debugfs a separate option

On Wed, Oct 12, 2016 at 3:57 PM, Laura Abbott wrote: > On 10/12/2016 03:45 PM, Kees Cook wrote: >> >> On Wed, Oct 12, 2016 at 3:31 PM, Laura Abbott wrote: >>> >>> >>> ptdump_register currently initializes a set of page table information and >>> registers

Re: [PATCHv2 1/4] arm64: dump: Make ptdump debugfs a separate option

On Wed, Oct 12, 2016 at 3:57 PM, Laura Abbott wrote: > On 10/12/2016 03:45 PM, Kees Cook wrote: >> >> On Wed, Oct 12, 2016 at 3:31 PM, Laura Abbott wrote: >>> >>> >>> ptdump_register currently initializes a set of page table information and >>> registers debugfs. There are uses for the ptdump

Re: [PATCH v3 3/6] pwm: imx: support output polarity inversion

Hi Stefan, > On 2016-10-07 08:11, Bhuvanchandra DV wrote: > > From: Lothar Wassmann > > > > The i.MX pwm unit on i.MX27 and newer SoCs provides a configurable > > output polarity. This patch adds support to utilize this feature > > where available. > > > >

Re: [PATCH v3 3/6] pwm: imx: support output polarity inversion

Hi Stefan, > On 2016-10-07 08:11, Bhuvanchandra DV wrote: > > From: Lothar Wassmann > > > > The i.MX pwm unit on i.MX27 and newer SoCs provides a configurable > > output polarity. This patch adds support to utilize this feature > > where available. > > > > Signed-off-by: Lothar Waßmann > >

[PATCH] perf: dynamically change verbosity level in perf top

Signed-off-by: Alexis Berlemont --- tools/perf/ui/browsers/hists.c | 5 - tools/perf/util/map.c | 17 - 2 files changed, 16 insertions(+), 6 deletions(-) diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c index

[PATCH] perf: dynamically change verbosity level in perf top

Signed-off-by: Alexis Berlemont --- tools/perf/ui/browsers/hists.c | 5 - tools/perf/util/map.c | 17 - 2 files changed, 16 insertions(+), 6 deletions(-) diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c index fb8e42c..6016909 100644 ---

[PATCH v2] sparc64: Multi-page size support

Add support for using multiple hugepage sizes simultaneously on mainline. Currently, support for 256M has been added which can be used along with 8M pages. Page tables are set like this (e.g. for 256M page): VA + (8M * x) -> PA + (8M * x) (sz bit = 256M) where x in [0, 31] and TSB is set

[PATCH v2] sparc64: Multi-page size support

Add support for using multiple hugepage sizes simultaneously on mainline. Currently, support for 256M has been added which can be used along with 8M pages. Page tables are set like this (e.g. for 256M page): VA + (8M * x) -> PA + (8M * x) (sz bit = 256M) where x in [0, 31] and TSB is set

Re: [PATCH 1/1] jbd2: fix incorrect unlock on j_list_lock

On Mar 17, 2015, at 8:08 PM, Taesoo Kim wrote: > > When 'jh->b_transaction == transaction' (asserted by below) > > J_ASSERT_JH(jh, (jh->b_transaction == transaction || ... > > 'journal->j_list_lock' will be incorrectly unlocked, since > spin_lock() is called only in

Re: [PATCH 1/1] jbd2: fix incorrect unlock on j_list_lock

On Mar 17, 2015, at 8:08 PM, Taesoo Kim wrote: > > When 'jh->b_transaction == transaction' (asserted by below) > > J_ASSERT_JH(jh, (jh->b_transaction == transaction || ... > > 'journal->j_list_lock' will be incorrectly unlocked, since > spin_lock() is called only in the 'if' and

Re: [PATCH v2 01/31] af9005: don't do DMA on stack

On Tue, 11 Oct 2016 07:09:16 -0300, Mauro wrote: > struct af9005_device_state { > > u8 sequence; > > int led_state; > > + unsigned char data[256]; > > + struct mutex data_mutex; > > }; This will not work on DMA incoherent architectures. When the data cache is

Re: [PATCH v2 01/31] af9005: don't do DMA on stack

On Tue, 11 Oct 2016 07:09:16 -0300, Mauro wrote: > struct af9005_device_state { > > u8 sequence; > > int led_state; > > + unsigned char data[256]; > > + struct mutex data_mutex; > > }; This will not work on DMA incoherent architectures. When the data cache is

[PATCH v6 04/17] ext2: remove support for DAX PMD faults

DAX PMD support was added via the following commit: commit e7b1ea2ad658 ("ext2: huge page fault support") I believe this path to be untested as ext2 doesn't reliably provide block allocations that are aligned to 2MiB. In my testing I've been unable to get ext2 to actually fault in a PMD. It

[PATCH v6 03/17] dax: remove buffer_size_valid()

Now that ext4 properly sets bh.b_size when we call get_block() for a hole, rely on that value and remove the buffer_size_valid() sanity check. Signed-off-by: Ross Zwisler Reviewed-by: Jan Kara Reviewed-by: Christoph Hellwig --- fs/dax.c

[PATCH v6 03/17] dax: remove buffer_size_valid()

Now that ext4 properly sets bh.b_size when we call get_block() for a hole, rely on that value and remove the buffer_size_valid() sanity check. Signed-off-by: Ross Zwisler Reviewed-by: Jan Kara Reviewed-by: Christoph Hellwig --- fs/dax.c | 22 +- 1 file changed, 1

[PATCH v6 04/17] ext2: remove support for DAX PMD faults

DAX PMD support was added via the following commit: commit e7b1ea2ad658 ("ext2: huge page fault support") I believe this path to be untested as ext2 doesn't reliably provide block allocations that are aligned to 2MiB. In my testing I've been unable to get ext2 to actually fault in a PMD. It

[PATCH v6 06/17] dax: remove the last BUG_ON() from fs/dax.c

Don't take down the kernel if we get an invalid 'from' and 'length' argument pair. Just warn once and return an error. Signed-off-by: Ross Zwisler Reviewed-by: Christoph Hellwig Reviewed-by: Jan Kara --- fs/dax.c | 3 ++- 1 file

[PATCH v6 06/17] dax: remove the last BUG_ON() from fs/dax.c

Don't take down the kernel if we get an invalid 'from' and 'length' argument pair. Just warn once and return an error. Signed-off-by: Ross Zwisler Reviewed-by: Christoph Hellwig Reviewed-by: Jan Kara --- fs/dax.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/dax.c

[PATCH v6 08/17] dax: coordinate locking for offsets in PMD range

DAX radix tree locking currently locks entries based on the unique combination of the 'mapping' pointer and the pgoff_t 'index' for the entry. This works for PTEs, but as we move to PMDs we will need to have all the offsets within the range covered by the PMD to map to the same bit lock. To

[PATCH v6 08/17] dax: coordinate locking for offsets in PMD range

DAX radix tree locking currently locks entries based on the unique combination of the 'mapping' pointer and the pgoff_t 'index' for the entry. This works for PTEs, but as we move to PMDs we will need to have all the offsets within the range covered by the PMD to map to the same bit lock. To

[PATCH v6 14/17] dax: move put_(un)locked_mapping_entry() in dax.c

No functional change. The static functions put_locked_mapping_entry() and put_unlocked_mapping_entry() will soon be used in error cases in grab_mapping_entry(), so move their definitions above this function. Signed-off-by: Ross Zwisler --- fs/dax.c | 50

[PATCH v6 07/17] dax: consistent variable naming for DAX entries

No functional change. Consistently use the variable name 'entry' instead of 'ret' for DAX radix tree entries. This was already happening in most of the code, so update get_unlocked_mapping_entry(), grab_mapping_entry() and dax_unlock_mapping_entry(). Signed-off-by: Ross Zwisler

[PATCH v6 13/17] dax: move RADIX_DAX_* defines to dax.h

The RADIX_DAX_* defines currently mostly live in fs/dax.c, with just RADIX_DAX_ENTRY_LOCK being in include/linux/dax.h so it can be used in mm/filemap.c. When we add PMD support, though, mm/filemap.c will also need access to the RADIX_DAX_PTE type so it can properly construct a 4k sized empty

[PATCH v6 10/17] dax: correct dax iomap code namespace

The recently added DAX functions that use the new struct iomap data structure were named iomap_dax_rw(), iomap_dax_fault() and iomap_dax_actor(). These are actually defined in fs/dax.c, though, so should be part of the "dax" namespace and not the "iomap" namespace. Rename them to dax_iomap_rw(),

[PATCH v6 14/17] dax: move put_(un)locked_mapping_entry() in dax.c

No functional change. The static functions put_locked_mapping_entry() and put_unlocked_mapping_entry() will soon be used in error cases in grab_mapping_entry(), so move their definitions above this function. Signed-off-by: Ross Zwisler --- fs/dax.c | 50

[PATCH v6 07/17] dax: consistent variable naming for DAX entries

No functional change. Consistently use the variable name 'entry' instead of 'ret' for DAX radix tree entries. This was already happening in most of the code, so update get_unlocked_mapping_entry(), grab_mapping_entry() and dax_unlock_mapping_entry(). Signed-off-by: Ross Zwisler Reviewed-by:

[PATCH v6 13/17] dax: move RADIX_DAX_* defines to dax.h

The RADIX_DAX_* defines currently mostly live in fs/dax.c, with just RADIX_DAX_ENTRY_LOCK being in include/linux/dax.h so it can be used in mm/filemap.c. When we add PMD support, though, mm/filemap.c will also need access to the RADIX_DAX_PTE type so it can properly construct a 4k sized empty

[PATCH v6 10/17] dax: correct dax iomap code namespace

The recently added DAX functions that use the new struct iomap data structure were named iomap_dax_rw(), iomap_dax_fault() and iomap_dax_actor(). These are actually defined in fs/dax.c, though, so should be part of the "dax" namespace and not the "iomap" namespace. Rename them to dax_iomap_rw(),

[PATCH v6 12/17] dax: dax_iomap_fault() needs to call iomap_end()

Currently iomap_end() doesn't do anything for DAX page faults for both ext2 and XFS. ext2_iomap_end() just checks for a write underrun, and xfs_file_iomap_end() checks to see if it needs to finish a delayed allocation. However, in the future iomap_end() calls might be needed to make sure we have

[PATCH v6 05/17] dax: make 'wait_table' global variable static

The global 'wait_table' variable is only used within fs/dax.c, and generates the following sparse warning: fs/dax.c:39:19: warning: symbol 'wait_table' was not declared. Should it be static? Make it static so it has scope local to fs/dax.c, and to make sparse happy. Signed-off-by: Ross Zwisler

[PATCH v6 00/17] re-enable DAX PMD support

DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based locking. This series allows DAX PMDs to participate in the DAX radix tree based locking scheme so that they can be re-enabled. For now I'm still using the same baseline for this series as I did with v5. I'll update the

[PATCH v6 01/17] ext4: allow DAX writeback for hole punch

Currently when doing a DAX hole punch with ext4 we fail to do a writeback. This is because the logic around filemap_write_and_wait_range() in ext4_punch_hole() only looks for dirty page cache pages in the radix tree, not for dirty DAX exceptional entries. Signed-off-by: Ross Zwisler

[PATCH v6 11/17] dax: add dax_iomap_sector() helper function

To be able to correctly calculate the sector from a file position and a struct iomap there is a complex little bit of logic that currently happens in both dax_iomap_actor() and dax_iomap_fault(). This will need to be repeated yet again in the DAX PMD fault handler when it is added, so break it

[PATCH v6 09/17] dax: remove dax_pmd_fault()

dax_pmd_fault() is the old struct buffer_head + get_block_t based 2 MiB DAX fault handler. This fault handler has been disabled for several kernel releases, and support for PMDs will be reintroduced using the struct iomap interface instead. Signed-off-by: Ross Zwisler

[PATCH v6 02/17] ext4: tell DAX the size of allocation holes

When DAX calls _ext4_get_block() and the file offset points to a hole we currently don't set bh->b_size. This is current worked around via buffer_size_valid() in fs/dax.c. _ext4_get_block() has the hole size information from ext4_map_blocks(), so populate bh->b_size so we can remove

[PATCH v6 17/17] dax: remove "depends on BROKEN" from FS_DAX_PMD

Now that DAX PMD faults are once again working and are now participating in DAX's radix tree locking scheme, allow their config option to be enabled. Signed-off-by: Ross Zwisler --- fs/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/Kconfig

[PATCH v6 05/17] dax: make 'wait_table' global variable static

The global 'wait_table' variable is only used within fs/dax.c, and generates the following sparse warning: fs/dax.c:39:19: warning: symbol 'wait_table' was not declared. Should it be static? Make it static so it has scope local to fs/dax.c, and to make sparse happy. Signed-off-by: Ross Zwisler

[PATCH v6 00/17] re-enable DAX PMD support

DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based locking. This series allows DAX PMDs to participate in the DAX radix tree based locking scheme so that they can be re-enabled. For now I'm still using the same baseline for this series as I did with v5. I'll update the

[PATCH v6 01/17] ext4: allow DAX writeback for hole punch

Currently when doing a DAX hole punch with ext4 we fail to do a writeback. This is because the logic around filemap_write_and_wait_range() in ext4_punch_hole() only looks for dirty page cache pages in the radix tree, not for dirty DAX exceptional entries. Signed-off-by: Ross Zwisler Reviewed-by:

[PATCH v6 11/17] dax: add dax_iomap_sector() helper function

To be able to correctly calculate the sector from a file position and a struct iomap there is a complex little bit of logic that currently happens in both dax_iomap_actor() and dax_iomap_fault(). This will need to be repeated yet again in the DAX PMD fault handler when it is added, so break it

[PATCH v6 09/17] dax: remove dax_pmd_fault()

dax_pmd_fault() is the old struct buffer_head + get_block_t based 2 MiB DAX fault handler. This fault handler has been disabled for several kernel releases, and support for PMDs will be reintroduced using the struct iomap interface instead. Signed-off-by: Ross Zwisler Reviewed-by: Christoph

[PATCH v6 02/17] ext4: tell DAX the size of allocation holes

When DAX calls _ext4_get_block() and the file offset points to a hole we currently don't set bh->b_size. This is current worked around via buffer_size_valid() in fs/dax.c. _ext4_get_block() has the hole size information from ext4_map_blocks(), so populate bh->b_size so we can remove

[PATCH v6 17/17] dax: remove "depends on BROKEN" from FS_DAX_PMD

Now that DAX PMD faults are once again working and are now participating in DAX's radix tree locking scheme, allow their config option to be enabled. Signed-off-by: Ross Zwisler --- fs/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/Kconfig b/fs/Kconfig index 2bc7ad7..b6f0fce

[PATCH v6 12/17] dax: dax_iomap_fault() needs to call iomap_end()

Currently iomap_end() doesn't do anything for DAX page faults for both ext2 and XFS. ext2_iomap_end() just checks for a write underrun, and xfs_file_iomap_end() checks to see if it needs to finish a delayed allocation. However, in the future iomap_end() calls might be needed to make sure we have

[PATCH v6 16/17] xfs: use struct iomap based DAX PMD fault path

Switch xfs_filemap_pmd_fault() from using dax_pmd_fault() to the new and improved dax_iomap_pmd_fault(). Also, now that it has no more users, remove xfs_get_blocks_dax_fault(). Signed-off-by: Ross Zwisler Reviewed-by: Jan Kara --- fs/xfs/xfs_aops.c

[PATCH v6 15/17] dax: add struct iomap based DAX PMD support

DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based locking. This patch allows DAX PMDs to participate in the DAX radix tree based locking scheme so that they can be re-enabled using the new struct iomap based fault handlers. There are currently three types of DAX 4k

[PATCH v6 16/17] xfs: use struct iomap based DAX PMD fault path

Switch xfs_filemap_pmd_fault() from using dax_pmd_fault() to the new and improved dax_iomap_pmd_fault(). Also, now that it has no more users, remove xfs_get_blocks_dax_fault(). Signed-off-by: Ross Zwisler Reviewed-by: Jan Kara --- fs/xfs/xfs_aops.c | 26 +-

[PATCH v6 15/17] dax: add struct iomap based DAX PMD support

DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based locking. This patch allows DAX PMDs to participate in the DAX radix tree based locking scheme so that they can be re-enabled using the new struct iomap based fault handlers. There are currently three types of DAX 4k

Re: [PATCH V2 1/3] Revert "ACPI,PCI,IRQ: reduce static IRQ array size to 16"

Hi Bjorn, On 10/12/2016 6:13 PM, Bjorn Helgaas wrote: > Hi Sinan, > > I have to apologize because I haven't followed all the discussion and > now I'm trying to figure it out from the patches and changelogs. But > I guess that's not all bad, because future interested folks *should* > be able to

Re: [PATCH V2 1/3] Revert "ACPI,PCI,IRQ: reduce static IRQ array size to 16"

Hi Bjorn, On 10/12/2016 6:13 PM, Bjorn Helgaas wrote: > Hi Sinan, > > I have to apologize because I haven't followed all the discussion and > now I'm trying to figure it out from the patches and changelogs. But > I guess that's not all bad, because future interested folks *should* > be able to

Re: [PATCHv2 1/4] arm64: dump: Make ptdump debugfs a separate option

On Wed, Oct 12, 2016 at 3:31 PM, Laura Abbott wrote: > > ptdump_register currently initializes a set of page table information and > registers debugfs. There are uses for the ptdump option without wanting the > debugfs options. Split this out to make it a separate option. > >

Re: [PATCHv2 1/4] arm64: dump: Make ptdump debugfs a separate option

On Wed, Oct 12, 2016 at 3:31 PM, Laura Abbott wrote: > > ptdump_register currently initializes a set of page table information and > registers debugfs. There are uses for the ptdump option without wanting the > debugfs options. Split this out to make it a separate option. > > Signed-off-by: Laura

Re: [PATCH] arch/x86: Remove second call to topology_update_package_map()

On 10/12/2016 06:06 PM, Tim Chen wrote: > On Wed, 2016-10-12 at 16:54 -0400, Prarit Bhargava wrote: >> >> On 10/12/2016 03:51 PM, Tim Chen wrote: >>> >>> On Wed, 2016-10-12 at 11:06 -0400, Prarit Bhargava wrote: On 10/12/2016 10:36 AM, Prarit Bhargava wrote: > > > This

Re: [PATCH] arch/x86: Remove second call to topology_update_package_map()

On 10/12/2016 06:06 PM, Tim Chen wrote: > On Wed, 2016-10-12 at 16:54 -0400, Prarit Bhargava wrote: >> >> On 10/12/2016 03:51 PM, Tim Chen wrote: >>> >>> On Wed, 2016-10-12 at 11:06 -0400, Prarit Bhargava wrote: On 10/12/2016 10:36 AM, Prarit Bhargava wrote: > > > This

[PATCHv2 4/4] arm64: dump: Add checking for writable and exectuable pages

Page mappings with full RWX permissions are a security risk. x86 has an option to walk the page tables and dump any bad pages. (See e1a58320a38d ("x86/mm: Warn on W^X mappings")). Add a similar implementation for arm64. Signed-off-by: Laura Abbott --- v2: Check only init_mm,

[PATCHv2 2/4] arm64: dump: Make the page table dumping seq_file optional

The page table dumping code always assumes it will be dumping to a seq_file to userspace. Future code will be taking advantage of the page table dumping code but will not need the seq_file. Make the seq_file optional for these cases. Acked-by: Mark Rutland Signed-off-by:

[PATCHv2 3/4] arm64: dump: Remove max_addr

max_addr was added as part of struct ptdump_info but has never actually been used. Remove it. Signed-off-by: Laura Abbott --- New for v2 of the series --- arch/arm64/include/asm/ptdump.h | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm64/include/asm/ptdump.h

[PATCHv2 4/4] arm64: dump: Add checking for writable and exectuable pages

Page mappings with full RWX permissions are a security risk. x86 has an option to walk the page tables and dump any bad pages. (See e1a58320a38d ("x86/mm: Warn on W^X mappings")). Add a similar implementation for arm64. Signed-off-by: Laura Abbott --- v2: Check only init_mm, style cleanups, UXN

[PATCHv2 2/4] arm64: dump: Make the page table dumping seq_file optional

The page table dumping code always assumes it will be dumping to a seq_file to userspace. Future code will be taking advantage of the page table dumping code but will not need the seq_file. Make the seq_file optional for these cases. Acked-by: Mark Rutland Signed-off-by: Laura Abbott --- v2:

[PATCHv2 3/4] arm64: dump: Remove max_addr

max_addr was added as part of struct ptdump_info but has never actually been used. Remove it. Signed-off-by: Laura Abbott --- New for v2 of the series --- arch/arm64/include/asm/ptdump.h | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm64/include/asm/ptdump.h

[PATCHv2 1/4] arm64: dump: Make ptdump debugfs a separate option

ptdump_register currently initializes a set of page table information and registers debugfs. There are uses for the ptdump option without wanting the debugfs options. Split this out to make it a separate option. Signed-off-by: Laura Abbott --- v2: Minor style fixups per Mark

[PATCHv2 0/4] WX checking for arm64

Hi, This is v2 of the implementation to check for writable and executable pages on arm64. Major changes since v1: - I realized my concerns about initialization and registration were unfounded so registration to register page tables with debugfs is simplified. - New patch to remove max_addr

[PATCHv2 1/4] arm64: dump: Make ptdump debugfs a separate option

ptdump_register currently initializes a set of page table information and registers debugfs. There are uses for the ptdump option without wanting the debugfs options. Split this out to make it a separate option. Signed-off-by: Laura Abbott --- v2: Minor style fixups per Mark Rutland,

[PATCHv2 0/4] WX checking for arm64

Hi, This is v2 of the implementation to check for writable and executable pages on arm64. Major changes since v1: - I realized my concerns about initialization and registration were unfounded so registration to register page tables with debugfs is simplified. - New patch to remove max_addr

Re: [PATCH] arch/x86: Remove second call to topology_update_package_map()

On Wed, 2016-10-12 at 16:54 -0400, Prarit Bhargava wrote: > > On 10/12/2016 03:51 PM, Tim Chen wrote: > > > > On Wed, 2016-10-12 at 11:06 -0400, Prarit Bhargava wrote: > > > > > > > > > On 10/12/2016 10:36 AM, Prarit Bhargava wrote: > > > > > > > > > > > > This was noticed during the

Re: [PATCH V3 02/10] ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1

Hello Suzuki, Thank you for the feedback! Responses below. On 10/11/2016 11:28 AM, Suzuki K Poulose wrote: On 07/10/16 22:31, Tyler Baicar wrote: Currently when a RAS error is reported it is not timestamped. The ACPI 6.1 spec adds the timestamp field to the generic error data entry v3

Re: [PATCH] arch/x86: Remove second call to topology_update_package_map()

On Wed, 2016-10-12 at 16:54 -0400, Prarit Bhargava wrote: > > On 10/12/2016 03:51 PM, Tim Chen wrote: > > > > On Wed, 2016-10-12 at 11:06 -0400, Prarit Bhargava wrote: > > > > > > > > > On 10/12/2016 10:36 AM, Prarit Bhargava wrote: > > > > > > > > > > > > This was noticed during the

Re: [PATCH V3 02/10] ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1

Hello Suzuki, Thank you for the feedback! Responses below. On 10/11/2016 11:28 AM, Suzuki K Poulose wrote: On 07/10/16 22:31, Tyler Baicar wrote: Currently when a RAS error is reported it is not timestamped. The ACPI 6.1 spec adds the timestamp field to the generic error data entry v3

Re: [PATCH] platform/x86: asus-wmi: add SERIO_I8042 dependency

On Wed, Oct 12, 2016 at 09:31:40PM +0200, Arnd Bergmann wrote: > A recent bugfix added a call to i8042_install_filter but did > not add the dependency, leading to possible link errors: > > drivers/platform/built-in.o: In function `asus_nb_wmi_quirks': > asus-nb-wmi.c:(.text+0x23af): undefined

Re: [PATCH] platform/x86: asus-wmi: add SERIO_I8042 dependency

On Wed, Oct 12, 2016 at 09:31:40PM +0200, Arnd Bergmann wrote: > A recent bugfix added a call to i8042_install_filter but did > not add the dependency, leading to possible link errors: > > drivers/platform/built-in.o: In function `asus_nb_wmi_quirks': > asus-nb-wmi.c:(.text+0x23af): undefined

Re: [PATCH] irqchip/jcore: fix lost per-cpu interrupts

On Wed, Oct 12, 2016 at 01:34:17PM -0700, Paul E. McKenney wrote: > On Wed, Oct 12, 2016 at 12:35:43PM -0400, Rich Felker wrote: > > On Wed, Oct 12, 2016 at 10:18:02AM +0200, Thomas Gleixner wrote: > > > On Tue, 11 Oct 2016, Rich Felker wrote: > > > > On Sun, Oct 09, 2016 at 09:23:58PM +0200,

Re: [PATCH] irqchip/jcore: fix lost per-cpu interrupts

On Wed, Oct 12, 2016 at 01:34:17PM -0700, Paul E. McKenney wrote: > On Wed, Oct 12, 2016 at 12:35:43PM -0400, Rich Felker wrote: > > On Wed, Oct 12, 2016 at 10:18:02AM +0200, Thomas Gleixner wrote: > > > On Tue, 11 Oct 2016, Rich Felker wrote: > > > > On Sun, Oct 09, 2016 at 09:23:58PM +0200,

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