Re: [PATCH v1] kernel/trace:check the val against the available mem

On Fri, Mar 30, 2018 at 8:07 PM, Steven Rostedt wrote: > On Fri, 30 Mar 2018 19:18:57 -0700 > Matthew Wilcox wrote: > >> Again though, this is the same pattern as vmalloc. There are any number >> of places where userspace can cause an arbitrarily large

Re: [PATCH v1] kernel/trace:check the val against the available mem

On Fri, Mar 30, 2018 at 8:07 PM, Steven Rostedt wrote: > On Fri, 30 Mar 2018 19:18:57 -0700 > Matthew Wilcox wrote: > >> Again though, this is the same pattern as vmalloc. There are any number >> of places where userspace can cause an arbitrarily large vmalloc to be >> attempted (grep for

Re: [PATCH 00/11] Use global pages with PTI

* Dave Hansen wrote: > On 03/30/2018 01:32 PM, Thomas Gleixner wrote: > > On Fri, 30 Mar 2018, Dave Hansen wrote: > > > >> On 03/30/2018 05:17 AM, Ingo Molnar wrote: > >>> BTW., the expectation on !PCID Intel hardware would be for global pages > >>> to help > >>>

Re: [PATCH 00/11] Use global pages with PTI

* Dave Hansen wrote: > On 03/30/2018 01:32 PM, Thomas Gleixner wrote: > > On Fri, 30 Mar 2018, Dave Hansen wrote: > > > >> On 03/30/2018 05:17 AM, Ingo Molnar wrote: > >>> BTW., the expectation on !PCID Intel hardware would be for global pages > >>> to help > >>> even more than the 0.6% and

Re: [PATCH v6] kernel.h: Retain constant expression output for max()/min()

* Kees Cook wrote: > On Mon, Mar 26, 2018 at 10:47 PM, Ingo Molnar wrote: > > > > * Kees Cook wrote: > > > >> In the effort to remove all VLAs from the kernel[1], it is desirable to > >> build with -Wvla. However, this warning is

Re: [PATCH v6] kernel.h: Retain constant expression output for max()/min()

* Kees Cook wrote: > On Mon, Mar 26, 2018 at 10:47 PM, Ingo Molnar wrote: > > > > * Kees Cook wrote: > > > >> In the effort to remove all VLAs from the kernel[1], it is desirable to > >> build with -Wvla. However, this warning is overly pessimistic, in that > >> it is only happy with stack

Re: [03/10] genksyms: generate lexer and parser during build instead of shipping

On Sat, Mar 31, 2018 at 11:20:22AM +0900, Masahiro Yamada wrote: > 2018-03-31 7:21 GMT+09:00 Andrei Vagin : > > On Fri, Mar 30, 2018 at 10:40:22AM -0700, Andrei Vagin wrote: > >> On Fri, Mar 23, 2018 at 10:04:32PM +0900, Masahiro Yamada wrote: > >> > Now that the kernel build

Re: [03/10] genksyms: generate lexer and parser during build instead of shipping

On Sat, Mar 31, 2018 at 11:20:22AM +0900, Masahiro Yamada wrote: > 2018-03-31 7:21 GMT+09:00 Andrei Vagin : > > On Fri, Mar 30, 2018 at 10:40:22AM -0700, Andrei Vagin wrote: > >> On Fri, Mar 23, 2018 at 10:04:32PM +0900, Masahiro Yamada wrote: > >> > Now that the kernel build supports flex and

Re: [PATCH v6] kernel.h: Retain constant expression output for max()/min()

On Mon, Mar 26, 2018 at 10:47 PM, Ingo Molnar wrote: > > * Kees Cook wrote: > >> In the effort to remove all VLAs from the kernel[1], it is desirable to >> build with -Wvla. However, this warning is overly pessimistic, in that >> it is only happy with

Re: [PATCH v6] kernel.h: Retain constant expression output for max()/min()

On Mon, Mar 26, 2018 at 10:47 PM, Ingo Molnar wrote: > > * Kees Cook wrote: > >> In the effort to remove all VLAs from the kernel[1], it is desirable to >> build with -Wvla. However, this warning is overly pessimistic, in that >> it is only happy with stack array sizes that are declared as

Re: [PATCH v4 01/14] soc: qcom: Separate kryo l2 accessors from PMU driver

Hi Ilia, Thank you for the patch! Yet something to improve: [auto build test ERROR on clk/clk-next] [also build test ERROR on v4.16-rc7 next-20180329] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v4 01/14] soc: qcom: Separate kryo l2 accessors from PMU driver

Hi Ilia, Thank you for the patch! Yet something to improve: [auto build test ERROR on clk/clk-next] [also build test ERROR on v4.16-rc7 next-20180329] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [kbuild-all] [PATCH] OPTIONAL: cpufreq/intel_pstate: fix debugfs_simple_attr.cocci warnings

Julia Lawall writes: > On Fri, 30 Mar 2018, Nicolai Stange wrote: > >> Julia Lawall writes: >> >> > On Thu, 29 Mar 2018, Fabio Estevam wrote: >> > >> >> Hi Julia, >> >> >> >> On Thu, Mar 29, 2018 at 4:12 PM, Julia Lawall >> >>

Re: [kbuild-all] [PATCH] OPTIONAL: cpufreq/intel_pstate: fix debugfs_simple_attr.cocci warnings

Julia Lawall writes: > On Fri, 30 Mar 2018, Nicolai Stange wrote: > >> Julia Lawall writes: >> >> > On Thu, 29 Mar 2018, Fabio Estevam wrote: >> > >> >> Hi Julia, >> >> >> >> On Thu, Mar 29, 2018 at 4:12 PM, Julia Lawall >> >> wrote: >> >> > Use DEFINE_DEBUGFS_ATTRIBUTE rather than

[PATCH v8 03/18] block, dax: remove dead code in blkdev_writepages()

Block device inodes never have S_DAX set, so kill the check for DAX and diversion to dax_writeback_mapping_range(). Cc: Jeff Moyer Cc: Ross Zwisler Cc: Matthew Wilcox Cc: Dave Chinner Reviewed-by:

[PATCH v8 03/18] block, dax: remove dead code in blkdev_writepages()

Block device inodes never have S_DAX set, so kill the check for DAX and diversion to dax_writeback_mapping_range(). Cc: Jeff Moyer Cc: Ross Zwisler Cc: Matthew Wilcox Cc: Dave Chinner Reviewed-by: Christoph Hellwig Reviewed-by: Jan Kara Signed-off-by: Dan Williams --- fs/block_dev.c |

[PATCH v8 04/18] 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 v8 05/18] 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 v8 05/18] 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 v8 04/18] 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 v8 06/18] 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 Reported-by:

[PATCH v8 06/18] 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 Reported-by: kbuild test robot

[PATCH v8 08/18] dax: introduce CONFIG_DAX_DRIVER

In support of allowing device-mapper to compile out idle/dead code when there are no dax providers in the system, introduce the DAX_DRIVER symbol. This is selected by all leaf drivers that device-mapper might be layered on top. This allows device-mapper to conditionally 'select DAX' only when a

[PATCH v8 08/18] dax: introduce CONFIG_DAX_DRIVER

In support of allowing device-mapper to compile out idle/dead code when there are no dax providers in the system, introduce the DAX_DRIVER symbol. This is selected by all leaf drivers that device-mapper might be layered on top. This allows device-mapper to conditionally 'select DAX' only when a

[PATCH v8 11/18] 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 v8 11/18] 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 v8 15/18] 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 v8 15/18] 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 v8 16/18] xfs: prepare xfs_break_layouts() to be called with XFS_MMAPLOCK_EXCL

In preparation for adding coordination between extent unmap operations and busy dax-pages, update xfs_break_layouts() to permit it to be called with the mmap lock held. This lock scheme will be required for coordinating the break of 'dax layouts' (non-idle dax (ZONE_DEVICE) pages mapped into the

[PATCH v8 14/18] memremap: mark devm_memremap_pages() EXPORT_SYMBOL_GPL

The devm_memremap_pages() facility is tightly integrated with the kernel's memory hotplug functionality. It injects an altmap argument deep into the architecture specific vmemmap implementation to allow allocating from specific reserved pages, and it has Linux specific assumptions about page

[PATCH v8 16/18] xfs: prepare xfs_break_layouts() to be called with XFS_MMAPLOCK_EXCL

In preparation for adding coordination between extent unmap operations and busy dax-pages, update xfs_break_layouts() to permit it to be called with the mmap lock held. This lock scheme will be required for coordinating the break of 'dax layouts' (non-idle dax (ZONE_DEVICE) pages mapped into the

[PATCH v8 14/18] memremap: mark devm_memremap_pages() EXPORT_SYMBOL_GPL

The devm_memremap_pages() facility is tightly integrated with the kernel's memory hotplug functionality. It injects an altmap argument deep into the architecture specific vmemmap implementation to allow allocating from specific reserved pages, and it has Linux specific assumptions about page

[PATCH v8 17/18] 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 v8 17/18] 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 v8 12/18] memremap: split devm_memremap_pages() and memremap() infrastructure

Currently, kernel/memremap.c contains generic code for supporting memremap() (CONFIG_HAS_IOMEM) and devm_memremap_pages() (CONFIG_ZONE_DEVICE). This causes ongoing build maintenance problems as additions to memremap.c, especially for the ZONE_DEVICE case, need to be careful about being placed in

[PATCH v8 18/18] 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 v8 12/18] memremap: split devm_memremap_pages() and memremap() infrastructure

Currently, kernel/memremap.c contains generic code for supporting memremap() (CONFIG_HAS_IOMEM) and devm_memremap_pages() (CONFIG_ZONE_DEVICE). This causes ongoing build maintenance problems as additions to memremap.c, especially for the ZONE_DEVICE case, need to be careful about being placed in

[PATCH v8 18/18] 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 v8 07/18] 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 v8 10/18] dax, dm: introduce ->fs_{claim, release}() dax_device infrastructure

In preparation for allowing filesystems to augment the dev_pagemap associated with a dax_device, add an ->fs_claim() callback. The ->fs_claim() callback is leveraged by the device-mapper dax implementation to iterate all member devices in the map and repeat the claim operation across the array.

[PATCH v8 10/18] dax, dm: introduce ->fs_{claim, release}() dax_device infrastructure

In preparation for allowing filesystems to augment the dev_pagemap associated with a dax_device, add an ->fs_claim() callback. The ->fs_claim() callback is leveraged by the device-mapper dax implementation to iterate all member devices in the map and repeat the claim operation across the array.

[PATCH v8 07/18] 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

Re: [PATCH][next] apparmor: fix memory leak on buffer on error exit path

On 03/27/2018 06:35 AM, Colin King wrote: > From: Colin Ian King > > Currently on the error exit path the allocated buffer is not free'd > causing a memory leak. Fix this by kfree'ing it. > > Detected by CoverityScan, CID#1466876 ("Resource leaks") > > Fixes:

Re: [PATCH][next] apparmor: fix memory leak on buffer on error exit path

On 03/27/2018 06:35 AM, Colin King wrote: > From: Colin Ian King > > Currently on the error exit path the allocated buffer is not free'd > causing a memory leak. Fix this by kfree'ing it. > > Detected by CoverityScan, CID#1466876 ("Resource leaks") > > Fixes: 1180b4c757aa ("apparmor: fix

[PATCH v8 09/18] dax, dm: allow device-mapper to operate without dax support

Change device-mapper's DAX dependency to require the presence of at least one DAX_DRIVER. This allows device-mapper to be built without bringing the DAX core along which is especially wasteful when there are no DAX drivers, like BLK_DEV_PMEM, configured. Cc: Alasdair Kergon

[PATCH v8 13/18] 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 v8 09/18] dax, dm: allow device-mapper to operate without dax support

Change device-mapper's DAX dependency to require the presence of at least one DAX_DRIVER. This allows device-mapper to be built without bringing the DAX core along which is especially wasteful when there are no DAX drivers, like BLK_DEV_PMEM, configured. Cc: Alasdair Kergon Reported-by: Bart Van

[PATCH v8 13/18] 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 v8 01/18] 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 v8 01/18] 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 v8 02/18] fs, dax: prepare for dax-specific address_space_operations

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. Define some generic VFS aops helpers for dax. These noop implementations are there in the dax case to prevent the VFS from

[PATCH v8 00/18] dax: fix dma vs truncate/hole-punch

Changes since v7 [1]: * Introduce noop_direct_IO() and use it to clean up xfs_dax_aops, ext4_dax_aops, and ext2_dax_aops (Jan, Christoph) * Clarify dax_associcate_entry() vs zero-page and empty entries with for_each_mapped_pfn() and a comment (Jan) * Collect reviewed-by's from Jan and

[PATCH v8 00/18] dax: fix dma vs truncate/hole-punch

Changes since v7 [1]: * Introduce noop_direct_IO() and use it to clean up xfs_dax_aops, ext4_dax_aops, and ext2_dax_aops (Jan, Christoph) * Clarify dax_associcate_entry() vs zero-page and empty entries with for_each_mapped_pfn() and a comment (Jan) * Collect reviewed-by's from Jan and

[PATCH v8 02/18] fs, dax: prepare for dax-specific address_space_operations

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. Define some generic VFS aops helpers for dax. These noop implementations are there in the dax case to prevent the VFS from

Re: [PATCH] staging: lustre: libcfs: use dynamic minors for /dev/{lnet,obd}

On Fri, Mar 30 2018, James Simmons wrote: > From: "John L. Hammond" > > Request dynamic minor allocation when registering /dev/lnet and > /dev/obd. > > Signed-off-by: John L. Hammond > Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-100086 >

Re: [PATCH] staging: lustre: libcfs: use dynamic minors for /dev/{lnet,obd}

On Fri, Mar 30 2018, James Simmons wrote: > From: "John L. Hammond" > > Request dynamic minor allocation when registering /dev/lnet and > /dev/obd. > > Signed-off-by: John L. Hammond > Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-100086 > Reviewed-on: https://review.whamcloud.com/29741 >

[GIT PULL] Kbuild fixes for v4.16

Hi Linus, Please pull a little more Kbuild fixes for v4.16. The following changes since commit 0c8efd610b58cb23cefdfa12015799079aef94ae: Linux 4.16-rc5 (2018-03-11 17:25:09 -0700) are available in the git repository at:

[GIT PULL] Kbuild fixes for v4.16

Hi Linus, Please pull a little more Kbuild fixes for v4.16. The following changes since commit 0c8efd610b58cb23cefdfa12015799079aef94ae: Linux 4.16-rc5 (2018-03-11 17:25:09 -0700) are available in the git repository at:

[PATCH 02/10] sparc: Convert local_softirq_pending() to use per-cpu op

In order to consolidate and optimize generic softirq mask accesses, we first need to convert architectures to use per-cpu operations when possible. Signed-off-by: Frederic Weisbecker Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo

[PATCH 02/10] sparc: Convert local_softirq_pending() to use per-cpu op

In order to consolidate and optimize generic softirq mask accesses, we first need to convert architectures to use per-cpu operations when possible. Signed-off-by: Frederic Weisbecker Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Sebastian Andrzej Siewior Cc: David S. Miller Cc:

[PATCH 06/10] parisc: Switch to generic local_softirq_pending() implementation

Remove the ad-hoc implementation, the generic code now allows us not to reinvent the wheel. Signed-off-by: Frederic Weisbecker Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Sebastian Andrzej Siewior

[PATCH 04/10] softirq: Consolidate default local_softirq_pending() implementations

Consolidate and optimize default softirq mask API implementations. Per-CPU operations are expected to be faster and a few architectures already rely on them to implement local_softirq_pending() and related accessors/mutators. Those will be migrated to the new generic code. Signed-off-by: Frederic

[PATCH 03/10] softirq: Turn default irq_cpustat_t to standard per-cpu

In order to optimize and consolidate softirq mask accesses, let's convert the default irq_cpustat_t implementation to per-CPU standard API. Signed-off-by: Frederic Weisbecker Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo Molnar

[PATCH 04/10] softirq: Consolidate default local_softirq_pending() implementations

Consolidate and optimize default softirq mask API implementations. Per-CPU operations are expected to be faster and a few architectures already rely on them to implement local_softirq_pending() and related accessors/mutators. Those will be migrated to the new generic code. Signed-off-by: Frederic

[PATCH 03/10] softirq: Turn default irq_cpustat_t to standard per-cpu

In order to optimize and consolidate softirq mask accesses, let's convert the default irq_cpustat_t implementation to per-CPU standard API. Signed-off-by: Frederic Weisbecker Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Sebastian Andrzej Siewior Cc: David S. Miller Cc:

[PATCH 06/10] parisc: Switch to generic local_softirq_pending() implementation

Remove the ad-hoc implementation, the generic code now allows us not to reinvent the wheel. Signed-off-by: Frederic Weisbecker Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Sebastian Andrzej Siewior Cc: David S. Miller Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael

[PATCH 08/10] sparc: Switch to generic local_softirq_pending() implementation

Benefit from the generic softirq mask implementation that rely on per-CPU mutators instead of working with raw operators on top of this_cpu_ptr(). Signed-off-by: Frederic Weisbecker Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo

[PATCH 08/10] sparc: Switch to generic local_softirq_pending() implementation

Benefit from the generic softirq mask implementation that rely on per-CPU mutators instead of working with raw operators on top of this_cpu_ptr(). Signed-off-by: Frederic Weisbecker Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Sebastian Andrzej Siewior Cc: David S. Miller Cc:

[PATCH 09/10] x86: Switch to generic local_softirq_pending() implementation

Remove the ad-hoc implementation, the generic code now allows us not to reinvent the wheel. Signed-off-by: Frederic Weisbecker Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Sebastian Andrzej Siewior

[PATCH 09/10] x86: Switch to generic local_softirq_pending() implementation

Remove the ad-hoc implementation, the generic code now allows us not to reinvent the wheel. Signed-off-by: Frederic Weisbecker Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Sebastian Andrzej Siewior Cc: David S. Miller Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael

[PATCH 07/10] powerpc: Switch to generic local_softirq_pending() implementation

Remove the ad-hoc implementation, the generic code now allows us not to reinvent the wheel. Signed-off-by: Frederic Weisbecker Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Sebastian Andrzej Siewior

[PATCH 05/10] ia64: Switch to generic local_softirq_pending() implementation

Benefit from the generic softirq mask implementation that rely on per-CPU mutators instead of working with raw operators on top of this_cpu_ptr(). Signed-off-by: Frederic Weisbecker Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo

[PATCH 07/10] powerpc: Switch to generic local_softirq_pending() implementation

Remove the ad-hoc implementation, the generic code now allows us not to reinvent the wheel. Signed-off-by: Frederic Weisbecker Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Sebastian Andrzej Siewior Cc: David S. Miller Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael

[PATCH 05/10] ia64: Switch to generic local_softirq_pending() implementation

Benefit from the generic softirq mask implementation that rely on per-CPU mutators instead of working with raw operators on top of this_cpu_ptr(). Signed-off-by: Frederic Weisbecker Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Sebastian Andrzej Siewior Cc: David S. Miller Cc:

[PATCH 00/10] softirq: Consolidate and optimize softirq mask v2

Only the last patch has changed since v1 to integrate review from peterz. Quote from the v1 summary: The softirq mask and its accessors/mutators have many implementations scattered around many architectures. Most do the same things consisting in a field in a per-cpu struct (often irq_cpustat_t)

[PATCH 01/10] ia64: Convert local_softirq_pending() to per-cpu ops

In order to consolidate and optimize generic softirq mask accesses, we first need to convert architectures to use per-cpu operations when possible. Signed-off-by: Frederic Weisbecker Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo

[PATCH 10/10] softirq/s390: Move default mutators of overwritten softirq mask to s390

s390 is now the last architecture that entirely overwrites local_softirq_pending() and uses the according default definitions of set_softirq_pending() and or_softirq_pending(). Just move these to s390 to debloat the generic code complexity. Suggested-by: Peter Zijlstra

[PATCH 01/10] ia64: Convert local_softirq_pending() to per-cpu ops

In order to consolidate and optimize generic softirq mask accesses, we first need to convert architectures to use per-cpu operations when possible. Signed-off-by: Frederic Weisbecker Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Sebastian Andrzej Siewior Cc: David S. Miller Cc:

[PATCH 10/10] softirq/s390: Move default mutators of overwritten softirq mask to s390

s390 is now the last architecture that entirely overwrites local_softirq_pending() and uses the according default definitions of set_softirq_pending() and or_softirq_pending(). Just move these to s390 to debloat the generic code complexity. Suggested-by: Peter Zijlstra Signed-off-by: Frederic

[PATCH 00/10] softirq: Consolidate and optimize softirq mask v2

Only the last patch has changed since v1 to integrate review from peterz. Quote from the v1 summary: The softirq mask and its accessors/mutators have many implementations scattered around many architectures. Most do the same things consisting in a field in a per-cpu struct (often irq_cpustat_t)

Re: [PATCH v1] kernel/trace:check the val against the available mem

On Fri, 30 Mar 2018 19:18:57 -0700 Matthew Wilcox wrote: > Again though, this is the same pattern as vmalloc. There are any number > of places where userspace can cause an arbitrarily large vmalloc to be > attempted (grep for kvmalloc_array for a list of promising

Re: [PATCH v1] kernel/trace:check the val against the available mem

On Fri, 30 Mar 2018 19:18:57 -0700 Matthew Wilcox wrote: > Again though, this is the same pattern as vmalloc. There are any number > of places where userspace can cause an arbitrarily large vmalloc to be > attempted (grep for kvmalloc_array for a list of promising candidates). > I'm pretty sure

[PATCH] autofs4: use wake_up() instead of wake_up_interruptible

In "autofs4: use wait_event_killable", wait_event_interruptible() was replaced by wait_event_killable(), but in this case we have to use wake_up() instead of wake_up_interruptible(). Cc: Matthew Wilcox Cc: Ian Kent Cc: Andrew Morton

[PATCH] autofs4: use wake_up() instead of wake_up_interruptible

In "autofs4: use wait_event_killable", wait_event_interruptible() was replaced by wait_event_killable(), but in this case we have to use wake_up() instead of wake_up_interruptible(). Cc: Matthew Wilcox Cc: Ian Kent Cc: Andrew Morton Cc: Stephen Rothwell Signed-off-by: Andrei Vagin ---

Re: [03/10] genksyms: generate lexer and parser during build instead of shipping

2018-03-31 7:21 GMT+09:00 Andrei Vagin : > On Fri, Mar 30, 2018 at 10:40:22AM -0700, Andrei Vagin wrote: >> On Fri, Mar 23, 2018 at 10:04:32PM +0900, Masahiro Yamada wrote: >> > Now that the kernel build supports flex and bison, remove the _shipped >> > files and generate

Re: [03/10] genksyms: generate lexer and parser during build instead of shipping

2018-03-31 7:21 GMT+09:00 Andrei Vagin : > On Fri, Mar 30, 2018 at 10:40:22AM -0700, Andrei Vagin wrote: >> On Fri, Mar 23, 2018 at 10:04:32PM +0900, Masahiro Yamada wrote: >> > Now that the kernel build supports flex and bison, remove the _shipped >> > files and generate them during the build

Re: [PATCH v1] kernel/trace:check the val against the available mem

On Fri, Mar 30, 2018 at 09:41:51PM -0400, Steven Rostedt wrote: > On Fri, 30 Mar 2018 16:38:52 -0700 > Joel Fernandes wrote: > > > > --- a/kernel/trace/ring_buffer.c > > > +++ b/kernel/trace/ring_buffer.c > > > @@ -1164,6 +1164,11 @@ static int __rb_allocate_pages(long

Re: [PATCH v1] kernel/trace:check the val against the available mem

On Fri, Mar 30, 2018 at 09:41:51PM -0400, Steven Rostedt wrote: > On Fri, 30 Mar 2018 16:38:52 -0700 > Joel Fernandes wrote: > > > > --- a/kernel/trace/ring_buffer.c > > > +++ b/kernel/trace/ring_buffer.c > > > @@ -1164,6 +1164,11 @@ static int __rb_allocate_pages(long nr_pages, > > > struct

Re: [REVIEW][PATCH 12/11] ipc: Directly call the security hook in ipc_ops.associate

On Sat, 24 Mar 2018, Eric W. Biederman wrote: > > After the last round of cleanups the shm, sem, and msg associate > operations just became trivial wrappers around the appropriate security > method. Simplify things further by just calling the security method > directly. > > Signed-off-by:

Re: [REVIEW][PATCH 12/11] ipc: Directly call the security hook in ipc_ops.associate

On Sat, 24 Mar 2018, Eric W. Biederman wrote: > > After the last round of cleanups the shm, sem, and msg associate > operations just became trivial wrappers around the appropriate security > method. Simplify things further by just calling the security method > directly. > > Signed-off-by:

[PATCH] ACPI / PM: Fix wake up by PS2 keyboard fail on ASUS UX331UA

This issue happens on new ASUS laptop UX331UA which has modern standby mode (suspend-to-idle). Pressing keys on the PS2 keyboard can't wake up the system from suspend-to-idle which is not expected. However, pressing power button can wake up without problem. Per the engineers of ASUS, the keypress

[PATCH] ACPI / PM: Fix wake up by PS2 keyboard fail on ASUS UX331UA

This issue happens on new ASUS laptop UX331UA which has modern standby mode (suspend-to-idle). Pressing keys on the PS2 keyboard can't wake up the system from suspend-to-idle which is not expected. However, pressing power button can wake up without problem. Per the engineers of ASUS, the keypress

[PATCH] ACPI / PM: Fix wake up by PS2 keyboard fail on ASUS UX331UA

This issue happens on new ASUS laptop UX331UA which has modern standby mode (suspend-to-idle). Pressing keys on the PS2 keyboard can't wake up the system from suspend-to-idle which is not expected. However, pressing power button can wake up without problem. Per the engineers of ASUS, the keypress

[PATCH] ACPI / PM: Fix wake up by PS2 keyboard fail on ASUS UX331UA

This issue happens on new ASUS laptop UX331UA which has modern standby mode (suspend-to-idle). Pressing keys on the PS2 keyboard can't wake up the system from suspend-to-idle which is not expected. However, pressing power button can wake up without problem. Per the engineers of ASUS, the keypress

4.15.14 crash with iscsi target and dvd

I reported this before but noone responded. I have an iscsi target setup with /dev/sr[012] using pscsi. On the initiator, I mount only 1 disc. Then I issue find -type f | xargs cat > /dev/null Then after a few seconds, I get 2 oops and the system has to be hard reset. I noticed if I cat

4.15.14 crash with iscsi target and dvd

I reported this before but noone responded. I have an iscsi target setup with /dev/sr[012] using pscsi. On the initiator, I mount only 1 disc. Then I issue find -type f | xargs cat > /dev/null Then after a few seconds, I get 2 oops and the system has to be hard reset. I noticed if I cat

[PATCH] f2fs: truncate preallocated blocks in error case

If write is failed, we must deallocate the blocks that we couldn't write. Cc: sta...@vger.kernel.org Signed-off-by: Jaegeuk Kim --- fs/f2fs/file.c | 9 + 1 file changed, 9 insertions(+) diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index 8068b015ece5..f18f62dd60a3

[PATCH] f2fs: truncate preallocated blocks in error case

If write is failed, we must deallocate the blocks that we couldn't write. Cc: sta...@vger.kernel.org Signed-off-by: Jaegeuk Kim --- fs/f2fs/file.c | 9 + 1 file changed, 9 insertions(+) diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index 8068b015ece5..f18f62dd60a3 100644 ---

[PATCH v7] kernel.h: Retain constant expression output for max()/min()

In the effort to remove all VLAs from the kernel[1], it is desirable to build with -Wvla. However, this warning is overly pessimistic, in that it is only happy with stack array sizes that are declared as constant expressions, and not constant values. One case of this is the evaluation of the max()

[PATCH v7] kernel.h: Retain constant expression output for max()/min()

In the effort to remove all VLAs from the kernel[1], it is desirable to build with -Wvla. However, this warning is overly pessimistic, in that it is only happy with stack array sizes that are declared as constant expressions, and not constant values. One case of this is the evaluation of the max()

  1   2   3   4   5   6   7   8   9   10   >