Re: [PATCH v2 0/3] perf/buildid-cache: Add --list and --purge-all options

On Tue, 17 Apr 2018 09:43:43 +0530 Ravi Bangoria wrote: > First patch is a trivial error message fix. Second and third > adds new options --list and --purge-all to 'buildid-cache' > subcommand. > > v2 changes: > - [PATCH v2 2/3] Display optput of 'perf

Re: [PATCH v2 0/3] perf/buildid-cache: Add --list and --purge-all options

On Tue, 17 Apr 2018 09:43:43 +0530 Ravi Bangoria wrote: > First patch is a trivial error message fix. Second and third > adds new options --list and --purge-all to 'buildid-cache' > subcommand. > > v2 changes: > - [PATCH v2 2/3] Display optput of 'perf buildid-cache -l' same as >'perf

Re: [PATCH 3/3] perf/buildid-cache: Support --purge-all option

On Mon, 16 Apr 2018 12:30:17 +0200 Jiri Olsa wrote: > On Mon, Apr 16, 2018 at 03:10:40PM +0530, Ravi Bangoria wrote: > > Hi Masami, > > > > On 04/16/2018 02:57 PM, Masami Hiramatsu wrote: > > > On Mon, 9 Apr 2018 16:36:33 +0530 > > > Ravi Bangoria

Re: [PATCH 3/3] perf/buildid-cache: Support --purge-all option

On Mon, 16 Apr 2018 12:30:17 +0200 Jiri Olsa wrote: > On Mon, Apr 16, 2018 at 03:10:40PM +0530, Ravi Bangoria wrote: > > Hi Masami, > > > > On 04/16/2018 02:57 PM, Masami Hiramatsu wrote: > > > On Mon, 9 Apr 2018 16:36:33 +0530 > > > Ravi Bangoria wrote: > > > > > >> User can remove files

Re: [PATCH v6 07/11] ARM: sun9i: smp: Rename clusters's power-off

Hello, On Tue, 17 Apr 2018 11:21:02 +0300 Sergei Shtylyov wrote: > Hello! > > On 4/17/2018 12:50 AM, Mylène Josserand wrote: > > > To prepare the support for sun8i-a83t, rename the variable name > > s/variable/macro/ maybe? Also "rename the ... name"

Re: [PATCH v6 07/11] ARM: sun9i: smp: Rename clusters's power-off

Hello, On Tue, 17 Apr 2018 11:21:02 +0300 Sergei Shtylyov wrote: > Hello! > > On 4/17/2018 12:50 AM, Mylène Josserand wrote: > > > To prepare the support for sun8i-a83t, rename the variable name > > s/variable/macro/ maybe? Also "rename the ... name" sounds tautological... Thank you

Re: [PATCH v6 00/11] Sunxi: Add SMP support on A83T

Hello Ondrej, On Tue, 17 Apr 2018 04:15:00 +0200 Ondřej Jirman wrote: > Hello Mylène, > > Please also add this: > > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig > index ce53ceaf4cc5..d9c8ecf88ec6 100644 > --- a/arch/arm/mach-sunxi/Kconfig

Re: [PATCH v6 00/11] Sunxi: Add SMP support on A83T

Hello Ondrej, On Tue, 17 Apr 2018 04:15:00 +0200 Ondřej Jirman wrote: > Hello Mylène, > > Please also add this: > > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig > index ce53ceaf4cc5..d9c8ecf88ec6 100644 > --- a/arch/arm/mach-sunxi/Kconfig > +++

Re: cpu stopper threads and load balancing leads to deadlock

On Tue, 2018-04-17 at 15:21 +0100, Matt Fleming wrote: > Hi guys, > > We've seen a bug in one of our SLE kernels where the cpu stopper > thread ("migration/15") is entering idle balance. This then triggers > active load balance. > > At the same time, a task on another CPU triggers a page fault

Re: cpu stopper threads and load balancing leads to deadlock

On Tue, 2018-04-17 at 15:21 +0100, Matt Fleming wrote: > Hi guys, > > We've seen a bug in one of our SLE kernels where the cpu stopper > thread ("migration/15") is entering idle balance. This then triggers > active load balance. > > At the same time, a task on another CPU triggers a page fault

Re: [PATCH v2] usb: chipidea: Hook into mux framework to toggle usb switch

On 2018-04-17 17:11, Peter Rosin wrote: On 2018-04-17 15:52, Yossi Mansharoff wrote: On the db410c 96boards platform we have a TC7USB40MU on the board to mux the D+/D- lines coming from the controller between a micro usb "device" port and a USB hub for "host" roles[1]. During a role switch, we

Re: [PATCH v2] usb: chipidea: Hook into mux framework to toggle usb switch

On 2018-04-17 17:11, Peter Rosin wrote: On 2018-04-17 15:52, Yossi Mansharoff wrote: On the db410c 96boards platform we have a TC7USB40MU on the board to mux the D+/D- lines coming from the controller between a micro usb "device" port and a USB hub for "host" roles[1]. During a role switch, we

Re: [PATCH v6 09/11] ARM: sun8i: smp: Add support for A83T

Hello Maxime, On Tue, 17 Apr 2018 13:20:38 +0200 Maxime Ripard wrote: > On Mon, Apr 16, 2018 at 11:50:30PM +0200, Mylène Josserand wrote: > > @@ -535,8 +599,12 @@ static int sunxi_mc_smp_cpu_kill(unsigned int l_cpu) > > return !ret; > > } > > > > -static bool

Re: [PATCH v6 09/11] ARM: sun8i: smp: Add support for A83T

Hello Maxime, On Tue, 17 Apr 2018 13:20:38 +0200 Maxime Ripard wrote: > On Mon, Apr 16, 2018 at 11:50:30PM +0200, Mylène Josserand wrote: > > @@ -535,8 +599,12 @@ static int sunxi_mc_smp_cpu_kill(unsigned int l_cpu) > > return !ret; > > } > > > > -static bool

[PATCH RESENT v4] dell_rbu: make firmware payload memory uncachable

From: Stuart Hayes The dell_rbu driver takes firmware update payloads and puts them in memory so the system BIOS can find them after a reboot. This sometimes fails (though rarely), because the memory containing the payload is in the CPU cache but never gets written

[PATCH RESENT v4] dell_rbu: make firmware payload memory uncachable

From: Stuart Hayes The dell_rbu driver takes firmware update payloads and puts them in memory so the system BIOS can find them after a reboot. This sometimes fails (though rarely), because the memory containing the payload is in the CPU cache but never gets written back to main memory before

Re: [PATCH] gpu: drm: i915: Change return type to vm_fault_t

On Tue, 17 Apr 2018, Souptick Joarder wrote: > On 17-Apr-2018 9:45 PM, "Matthew Wilcox" wrote: >> >> On Tue, Apr 17, 2018 at 09:14:32PM +0530, Souptick Joarder wrote: >> > Not exactly. The plan for these patches is to introduce new vm_fault_t > type >>

Re: [PATCH] gpu: drm: i915: Change return type to vm_fault_t

On Tue, 17 Apr 2018, Souptick Joarder wrote: > On 17-Apr-2018 9:45 PM, "Matthew Wilcox" wrote: >> >> On Tue, Apr 17, 2018 at 09:14:32PM +0530, Souptick Joarder wrote: >> > Not exactly. The plan for these patches is to introduce new vm_fault_t > type >> > in vm_operations_struct fault handlers.

Re: [PATCH v6 6/7] remoteproc/davinci: use the reset framework

On Tuesday 17 April 2018 11:00 PM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > Switch to using the reset framework instead of handcoded reset routines > we used so far. > > Signed-off-by: Bartosz Golaszewski Looks good!

Re: [PATCH v6 6/7] remoteproc/davinci: use the reset framework

On Tuesday 17 April 2018 11:00 PM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > Switch to using the reset framework instead of handcoded reset routines > we used so far. > > Signed-off-by: Bartosz Golaszewski Looks good! Reviewed-by: Sekhar Nori This depends on DaVinci

[PATCH 2/2] qxl: keep separate release_bo pointer

qxl expects that list_first_entry(release->bos) returns the first element qxl added to the list. ttm_eu_reserve_buffers() may reorder the list though. Add a release_bo field to struct qxl_release and use that instead. Signed-off-by: Gerd Hoffmann ---

[PATCH 1/2] qxl: fix qxl_release_{map,unmap}

s/PAGE_SIZE/PAGE_MASK/ Luckily release_offset is never larger than PAGE_SIZE, so the bug has no bad side effects and managed to stay unnoticed for years that way ... Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_ioctl.c | 4 ++--

[PATCH 2/2] qxl: keep separate release_bo pointer

qxl expects that list_first_entry(release->bos) returns the first element qxl added to the list. ttm_eu_reserve_buffers() may reorder the list though. Add a release_bo field to struct qxl_release and use that instead. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_drv.h | 1 +

[PATCH 1/2] qxl: fix qxl_release_{map,unmap}

s/PAGE_SIZE/PAGE_MASK/ Luckily release_offset is never larger than PAGE_SIZE, so the bug has no bad side effects and managed to stay unnoticed for years that way ... Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_ioctl.c | 4 ++-- drivers/gpu/drm/qxl/qxl_release.c | 6 +++--- 2

Re: [PATCH 5/5] dmaengine: sprd: Add 'device_config' and 'device_prep_slave_sg' interfaces

On 17 April 2018 at 18:45, Lars-Peter Clausen wrote: > On 04/10/2018 09:46 AM, Baolin Wang wrote: > [...] >> +static int sprd_dma_slave_config(struct dma_chan *chan, >> + struct dma_slave_config *config) >> +{ >> + struct sprd_dma_chn *schan =

Re: [PATCH 5/5] dmaengine: sprd: Add 'device_config' and 'device_prep_slave_sg' interfaces

On 17 April 2018 at 18:45, Lars-Peter Clausen wrote: > On 04/10/2018 09:46 AM, Baolin Wang wrote: > [...] >> +static int sprd_dma_slave_config(struct dma_chan *chan, >> + struct dma_slave_config *config) >> +{ >> + struct sprd_dma_chn *schan =

Re: [PATCH v6 5/7] remoteproc/davinci: use octal permissions for module_param()

On Tuesday 17 April 2018 11:00 PM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > Checkpatch recommends to use octal perms instead of S_IRUGO. > > Signed-off-by: Bartosz Golaszewski Reviewed-by: Sekhar Nori

Re: [PATCH v6 5/7] remoteproc/davinci: use octal permissions for module_param()

On Tuesday 17 April 2018 11:00 PM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > Checkpatch recommends to use octal perms instead of S_IRUGO. > > Signed-off-by: Bartosz Golaszewski Reviewed-by: Sekhar Nori Thanks, Sekhar

Re: [PATCH v6 4/7] remoteproc/davinci: prepare and unprepare the clock where needed

On Tuesday 17 April 2018 11:00 PM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > We're currently switching the platform to using the common clock > framework. We need to explicitly prepare and unprepare the rproc > clock. > > Signed-off-by: Bartosz

Re: [PATCH v6 4/7] remoteproc/davinci: prepare and unprepare the clock where needed

On Tuesday 17 April 2018 11:00 PM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > We're currently switching the platform to using the common clock > framework. We need to explicitly prepare and unprepare the rproc > clock. > > Signed-off-by: Bartosz Golaszewski > Acked-by: Suman

Re: [PATCH 4.15 00/53] 4.15.18-stable review

On 17 April 2018 at 21:28, Greg Kroah-Hartman wrote: > > NOTE, this is the last expected 4.15.y release. After this one, the > tree is end-of-life. Please move to 4.16.y at this point in time. > > > This is the start

Re: [PATCH 4.15 00/53] 4.15.18-stable review

On 17 April 2018 at 21:28, Greg Kroah-Hartman wrote: > > NOTE, this is the last expected 4.15.y release. After this one, the > tree is end-of-life. Please move to 4.16.y at this point in time. > > > This is the start of the stable review cycle

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

On Wed, 18 Apr 2018, Tetsuo Handa wrote: > > Commit 97b1255cb27c is referencing MMF_OOM_SKIP already being set by > > exit_mmap(). The only thing this patch changes is where that is done: > > before or after free_pgtables(). We can certainly move it to before > > free_pgtables() at the risk

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

On Wed, 18 Apr 2018, Tetsuo Handa wrote: > > Commit 97b1255cb27c is referencing MMF_OOM_SKIP already being set by > > exit_mmap(). The only thing this patch changes is where that is done: > > before or after free_pgtables(). We can certainly move it to before > > free_pgtables() at the risk

Re: [PATCH 4.16 00/68] 4.16.3-stable review

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

Re: [PATCH 4.16 00/68] 4.16.3-stable review

On 17 April 2018 at 21:27, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.16.3 release. > There are 68 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. > >

RE: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too

> -Original Message- > From: Robin Murphy [mailto:robin.mur...@arm.com] > Sent: Tuesday, April 17, 2018 10:23 PM > To: Nipun Gupta ; robh...@kernel.org; > frowand.l...@gmail.com > Cc: will.dea...@arm.com; mark.rutl...@arm.com; catalin.mari...@arm.com; > h...@lst.de;

RE: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too

> -Original Message- > From: Robin Murphy [mailto:robin.mur...@arm.com] > Sent: Tuesday, April 17, 2018 10:23 PM > To: Nipun Gupta ; robh...@kernel.org; > frowand.l...@gmail.com > Cc: will.dea...@arm.com; mark.rutl...@arm.com; catalin.mari...@arm.com; > h...@lst.de;

Re: [PATCH v6 3/7] remoteproc/davinci: add the missing retval check for clk_enable()

On Tuesday 17 April 2018 11:00 PM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > The davinci platform is being switched to using the common clock > framework, where clk_enable() can fail. Add the return value check. > > Signed-off-by: Bartosz Golaszewski

Re: [PATCH v6 3/7] remoteproc/davinci: add the missing retval check for clk_enable()

On Tuesday 17 April 2018 11:00 PM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > The davinci platform is being switched to using the common clock > framework, where clk_enable() can fail. Add the return value check. > > Signed-off-by: Bartosz Golaszewski > Acked-by: Suman Anna >

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

David Rientjes wrote: > On Wed, 18 Apr 2018, Tetsuo Handa wrote: > > > Fix this by reusing MMF_UNSTABLE to specify that an mm should not be > > > reaped. This prevents the concurrent munlock_vma_pages_range() and > > > unmap_page_range(). The oom reaper will simply not operate on an mm that > >

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

David Rientjes wrote: > On Wed, 18 Apr 2018, Tetsuo Handa wrote: > > > Fix this by reusing MMF_UNSTABLE to specify that an mm should not be > > > reaped. This prevents the concurrent munlock_vma_pages_range() and > > > unmap_page_range(). The oom reaper will simply not operate on an mm that > >

Re: [PATCH 0/3] intel-iommu: fix mapping PSI missing for iommu_map()

On Wed, Apr 18, 2018 at 12:41:27PM +0800, Peter Xu wrote: > (PSI stands for: Page Selective Invalidations) > > Intel IOMMU has the caching mode to ease emulation of the device. > When that bit is set, we need to send PSIs even for newly mapped > pages. However current driver is not fully obey

Re: [PATCH 0/3] intel-iommu: fix mapping PSI missing for iommu_map()

On Wed, Apr 18, 2018 at 12:41:27PM +0800, Peter Xu wrote: > (PSI stands for: Page Selective Invalidations) > > Intel IOMMU has the caching mode to ease emulation of the device. > When that bit is set, we need to send PSIs even for newly mapped > pages. However current driver is not fully obey

Re: [PATCH net-next] net: introduce a new tracepoint for tcp_rcv_space_adjust

On Wed, Apr 18, 2018 at 7:44 AM, Alexei Starovoitov wrote: > On Mon, Apr 16, 2018 at 08:43:31AM -0700, Eric Dumazet wrote: >> >> >> On 04/16/2018 08:33 AM, Yafang Shao wrote: >> > tcp_rcv_space_adjust is called every time data is copied to user space, >> >

Re: [PATCH net-next] net: introduce a new tracepoint for tcp_rcv_space_adjust

On Wed, Apr 18, 2018 at 7:44 AM, Alexei Starovoitov wrote: > On Mon, Apr 16, 2018 at 08:43:31AM -0700, Eric Dumazet wrote: >> >> >> On 04/16/2018 08:33 AM, Yafang Shao wrote: >> > tcp_rcv_space_adjust is called every time data is copied to user space, >> > introducing a tcp tracepoint for which

[PATCH 1/3] intel-iommu: add some traces for PSIs

It is helpful to debug and triage PSI notification missings. Signed-off-by: Peter Xu --- drivers/iommu/dmar.c| 3 +++ drivers/iommu/intel-iommu.c | 3 +++ 2 files changed, 6 insertions(+) diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c index

[PATCH 1/3] intel-iommu: add some traces for PSIs

It is helpful to debug and triage PSI notification missings. Signed-off-by: Peter Xu --- drivers/iommu/dmar.c| 3 +++ drivers/iommu/intel-iommu.c | 3 +++ 2 files changed, 6 insertions(+) diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c index 9a7ffd13c7f0..62ae26c3f7b7 100644

[PATCH 3/3] intel-iommu: fix iotlb psi missing for mappings

When caching mode is enabled for IOMMU, we should send explicit IOTLB PSIs even for newly created mappings. However these events are missing for all intel_iommu_map() callers, e.g., iommu_map(). One direct user is the vfio-pci driver. To make sure we'll send the PSIs always when necessary, this

[PATCH 3/3] intel-iommu: fix iotlb psi missing for mappings

When caching mode is enabled for IOMMU, we should send explicit IOTLB PSIs even for newly created mappings. However these events are missing for all intel_iommu_map() callers, e.g., iommu_map(). One direct user is the vfio-pci driver. To make sure we'll send the PSIs always when necessary, this

[PATCH 2/3] intel-iommu: generalize __mapping_notify_one()

Generalize this new helper to notify one newly created mapping on one single IOMMU. We can further leverage this helper in the next patch. Signed-off-by: Peter Xu --- drivers/iommu/intel-iommu.c | 26 ++ 1 file changed, 14 insertions(+), 12

[PATCH 2/3] intel-iommu: generalize __mapping_notify_one()

Generalize this new helper to notify one newly created mapping on one single IOMMU. We can further leverage this helper in the next patch. Signed-off-by: Peter Xu --- drivers/iommu/intel-iommu.c | 26 ++ 1 file changed, 14 insertions(+), 12 deletions(-) diff --git

[PATCH 0/3] intel-iommu: fix mapping PSI missing for iommu_map()

(PSI stands for: Page Selective Invalidations) Intel IOMMU has the caching mode to ease emulation of the device. When that bit is set, we need to send PSIs even for newly mapped pages. However current driver is not fully obey the rule. E.g., iommu_map() API will only do the mapping but it never

[PATCH 0/3] intel-iommu: fix mapping PSI missing for iommu_map()

(PSI stands for: Page Selective Invalidations) Intel IOMMU has the caching mode to ease emulation of the device. When that bit is set, we need to send PSIs even for newly mapped pages. However current driver is not fully obey the rule. E.g., iommu_map() API will only do the mapping but it never

Re: [PATCH/RFC] crypto: Add platform dependencies for CRYPTO_DEV_CCREE

Hi Geert, On Tue, Apr 17, 2018 at 9:14 PM, Geert Uytterhoeven wrote: > The ARM TrustZone CryptoCell is found on ARM SoCs only. Hence make it > depend on ARM or ARM64, unless compile-testing. > Actually it is not. Despite what the name suggest, CryptoCell is designed by

Re: [PATCH/RFC] crypto: Add platform dependencies for CRYPTO_DEV_CCREE

Hi Geert, On Tue, Apr 17, 2018 at 9:14 PM, Geert Uytterhoeven wrote: > The ARM TrustZone CryptoCell is found on ARM SoCs only. Hence make it > depend on ARM or ARM64, unless compile-testing. > Actually it is not. Despite what the name suggest, CryptoCell is designed by Arm but is not in fact

Re: [PATCH] mm:memcg: add __GFP_NOWARN in __memcg_schedule_kmem_cache_create

On Tue, 17 Apr 2018, Matthew Wilcox wrote: > Not arguing against this patch. But how many places do we want to use > GFP_NOWAIT without __GFP_NOWARN? Not many, and the few which do do this > seem like they simply haven't added it yet. Maybe this would be a good idea? > > -#define GFP_NOWAIT

Re: [PATCH] mm:memcg: add __GFP_NOWARN in __memcg_schedule_kmem_cache_create

On Tue, 17 Apr 2018, Matthew Wilcox wrote: > Not arguing against this patch. But how many places do we want to use > GFP_NOWAIT without __GFP_NOWARN? Not many, and the few which do do this > seem like they simply haven't added it yet. Maybe this would be a good idea? > > -#define GFP_NOWAIT

Re: [PATCH] f2fs: set deadline to drop expired inmem pages

On 04/17, Chao Yu wrote: > On 2018/4/17 14:44, Chao Yu wrote: > > On 2018/4/17 4:16, Jaegeuk Kim wrote: > >> On 04/13, Chao Yu wrote: > >>> On 2018/4/13 12:05, Jaegeuk Kim wrote: > On 04/13, Chao Yu wrote: > > On 2018/4/13 9:04, Jaegeuk Kim wrote: > >> On 04/10, Chao Yu wrote: >

Re: [PATCH] f2fs: set deadline to drop expired inmem pages

On 04/17, Chao Yu wrote: > On 2018/4/17 14:44, Chao Yu wrote: > > On 2018/4/17 4:16, Jaegeuk Kim wrote: > >> On 04/13, Chao Yu wrote: > >>> On 2018/4/13 12:05, Jaegeuk Kim wrote: > On 04/13, Chao Yu wrote: > > On 2018/4/13 9:04, Jaegeuk Kim wrote: > >> On 04/10, Chao Yu wrote: >

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

On Wed, 18 Apr 2018, Tetsuo Handa wrote: > > Fix this by reusing MMF_UNSTABLE to specify that an mm should not be > > reaped. This prevents the concurrent munlock_vma_pages_range() and > > unmap_page_range(). The oom reaper will simply not operate on an mm that > > has the bit set and leave the

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

On Wed, 18 Apr 2018, Tetsuo Handa wrote: > > Fix this by reusing MMF_UNSTABLE to specify that an mm should not be > > reaped. This prevents the concurrent munlock_vma_pages_range() and > > unmap_page_range(). The oom reaper will simply not operate on an mm that > > has the bit set and leave the

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

David Rientjes wrote: > Fix this by reusing MMF_UNSTABLE to specify that an mm should not be > reaped. This prevents the concurrent munlock_vma_pages_range() and > unmap_page_range(). The oom reaper will simply not operate on an mm that > has the bit set and leave the unmapping to exit_mmap().

Re: [PATCH v5] ARM: dts: tpc: Device tree description of the iMX6Q TPC board

On Tue, Apr 10, 2018 at 10:32:09PM +0200, Lukasz Majewski wrote: > This commit adds device tree description of Kieback & Peter GmbH > iMX6Q TPC board. > > Signed-off-by: Lukasz Majewski > Reviewed-by: Fabio Estevam > > --- > Changes for v5: > - Use

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

David Rientjes wrote: > Fix this by reusing MMF_UNSTABLE to specify that an mm should not be > reaped. This prevents the concurrent munlock_vma_pages_range() and > unmap_page_range(). The oom reaper will simply not operate on an mm that > has the bit set and leave the unmapping to exit_mmap().

Re: [PATCH v5] ARM: dts: tpc: Device tree description of the iMX6Q TPC board

On Tue, Apr 10, 2018 at 10:32:09PM +0200, Lukasz Majewski wrote: > This commit adds device tree description of Kieback & Peter GmbH > iMX6Q TPC board. > > Signed-off-by: Lukasz Majewski > Reviewed-by: Fabio Estevam > > --- > Changes for v5: > - Use 'interpolation-steps' to fill the brightness

Re: [PATCH] regulator: Fix return type of of_map_mode()

Hi, On Tue, Apr 17, 2018 at 10:48 AM, Javier Martinez Canillas wrote: >>> Let's fix the return type of all of the current of_map_mode() >>> functions. While we're at it, we'll remove one pointless "inline". >> >> Ah, I see... the thing here is that the mode is always an

Re: [PATCH] regulator: Fix return type of of_map_mode()

Hi, On Tue, Apr 17, 2018 at 10:48 AM, Javier Martinez Canillas wrote: >>> Let's fix the return type of all of the current of_map_mode() >>> functions. While we're at it, we'll remove one pointless "inline". >> >> Ah, I see... the thing here is that the mode is always an unsigned int >> since

linux-next: build failure after merge of the arm-current tree

Hi Russell, After merging the arm-current tree, today's linux-next build (lots of configs) failed like this: /bin/sh: 1: arithmetic expression: expecting primary: " " (lots of these) Caused by commit fe680ca02c1e ("ARM: replace unnecessary perl with sed and the shell $(( )) operator")

linux-next: build failure after merge of the arm-current tree

Hi Russell, After merging the arm-current tree, today's linux-next build (lots of configs) failed like this: /bin/sh: 1: arithmetic expression: expecting primary: " " (lots of these) Caused by commit fe680ca02c1e ("ARM: replace unnecessary perl with sed and the shell $(( )) operator")

[PATCH v2] regulator: Don't return or expect -errno from of_map_mode()

In of_get_regulation_constraints() we were taking the result of of_map_mode() (an unsigned int) and assigning it to an int. We were then checking whether this value was -EINVAL. Some implementers of of_map_mode() were returning -EINVAL (even though the return type of their function needed to be

[PATCH v2] regulator: Don't return or expect -errno from of_map_mode()

In of_get_regulation_constraints() we were taking the result of of_map_mode() (an unsigned int) and assigning it to an int. We were then checking whether this value was -EINVAL. Some implementers of of_map_mode() were returning -EINVAL (even though the return type of their function needed to be

[PATCH] prctl: fix compat handling for prctl

The member auxv in prctl_mm_map structure which be shared with userspace is pointer type, but the kernel supporting COMPAT didn't handle it. This patch fix the compat handling for prctl syscall. Signed-off-by: Li Bin --- kernel/sys.c | 41

[PATCH] prctl: fix compat handling for prctl

The member auxv in prctl_mm_map structure which be shared with userspace is pointer type, but the kernel supporting COMPAT didn't handle it. This patch fix the compat handling for prctl syscall. Signed-off-by: Li Bin --- kernel/sys.c | 41 + 1 file

Re: [PATCH] KVM: X86: Allow userspace to define the microcode version

2018-04-18 4:24 GMT+08:00 Eduardo Habkost : > On Tue, Apr 17, 2018 at 06:40:58PM +0800, Wanpeng Li wrote: >> Cc Eduardo, >> 2018-02-26 20:41 GMT+08:00 Paolo Bonzini : >> > On 26/02/2018 13:22, Borislav Petkov wrote: >> >> On Mon, Feb 26, 2018 at 01:18:07PM

Re: [PATCH] KVM: X86: Allow userspace to define the microcode version

2018-04-18 4:24 GMT+08:00 Eduardo Habkost : > On Tue, Apr 17, 2018 at 06:40:58PM +0800, Wanpeng Li wrote: >> Cc Eduardo, >> 2018-02-26 20:41 GMT+08:00 Paolo Bonzini : >> > On 26/02/2018 13:22, Borislav Petkov wrote: >> >> On Mon, Feb 26, 2018 at 01:18:07PM +0100, Paolo Bonzini wrote: >> In

Re: [PATCH 0/4] ARM: imx: use device properties for at24 eeprom

On Wed, Apr 04, 2018 at 03:16:23PM +0200, Bartosz Golaszewski wrote: > We want to work towards phasing out the at24_platform_data structure. > There are few users and its contents can be represented using generic > device properties. Using device properties only will allow us to > significantly

Re: [PATCH 0/4] ARM: imx: use device properties for at24 eeprom

On Wed, Apr 04, 2018 at 03:16:23PM +0200, Bartosz Golaszewski wrote: > We want to work towards phasing out the at24_platform_data structure. > There are few users and its contents can be represented using generic > device properties. Using device properties only will allow us to > significantly

[PATCH 14/24] x86/speculation: Move firmware_restrict_branch_speculation_*() from C to CPP

From: Ingo Molnar (cherry picked from commit d72f4e29e6d84b7ec02ae93088aa459ac70e733b) firmware_restrict_branch_speculation_*() recently started using preempt_enable()/disable(), but those are relatively high level primitives and cause build failures on some 32-bit builds.

[PATCH 14/24] x86/speculation: Move firmware_restrict_branch_speculation_*() from C to CPP

From: Ingo Molnar (cherry picked from commit d72f4e29e6d84b7ec02ae93088aa459ac70e733b) firmware_restrict_branch_speculation_*() recently started using preempt_enable()/disable(), but those are relatively high level primitives and cause build failures on some 32-bit builds. Since we want to

Re: [PATCH 00/20] staging: lustre: convert to rhashtable

On Tue, Apr 17 2018, James Simmons wrote: >> libcfs in lustre has a resizeable hashtable. >> Linux already has a resizeable hashtable, rhashtable, which is better >> is most metrics. See https://lwn.net/Articles/751374/ in a few days >> for an introduction to rhashtable. > > Thansk for starting

Re: [RFC] virtio: Use DMA MAP API for devices without an IOMMU

On 04/15/2018 05:41 PM, Christoph Hellwig wrote: > On Fri, Apr 06, 2018 at 06:37:18PM +1000, Benjamin Herrenschmidt wrote: implemented as DMA API which the virtio core understands. There is no need for an IOMMU to be involved for the device representation in this case IMHO. >>> >>>

Re: [PATCH 00/20] staging: lustre: convert to rhashtable

On Tue, Apr 17 2018, James Simmons wrote: >> libcfs in lustre has a resizeable hashtable. >> Linux already has a resizeable hashtable, rhashtable, which is better >> is most metrics. See https://lwn.net/Articles/751374/ in a few days >> for an introduction to rhashtable. > > Thansk for starting

Re: [RFC] virtio: Use DMA MAP API for devices without an IOMMU

On 04/15/2018 05:41 PM, Christoph Hellwig wrote: > On Fri, Apr 06, 2018 at 06:37:18PM +1000, Benjamin Herrenschmidt wrote: implemented as DMA API which the virtio core understands. There is no need for an IOMMU to be involved for the device representation in this case IMHO. >>> >>>

Re: [PATCH] mm:memcg: add __GFP_NOWARN in __memcg_schedule_kmem_cache_create

On Wed, Apr 18, 2018 at 11:29:12AM +0900, Minchan Kim wrote: > If there are heavy memory pressure, page allocation with __GFP_NOWAIT > fails easily although it's order-0 request. > I got below warning 9 times for normal boot. > > [ 17.072747] c0 0 : page allocation failure: order:0, >

Re: [PATCH] mm:memcg: add __GFP_NOWARN in __memcg_schedule_kmem_cache_create

On Wed, Apr 18, 2018 at 11:29:12AM +0900, Minchan Kim wrote: > If there are heavy memory pressure, page allocation with __GFP_NOWAIT > fails easily although it's order-0 request. > I got below warning 9 times for normal boot. > > [ 17.072747] c0 0 : page allocation failure: order:0, >

Re: [PATCH] mm:memcg: add __GFP_NOWARN in __memcg_schedule_kmem_cache_create

On Wed, 18 Apr 2018, Minchan Kim wrote: > If there are heavy memory pressure, page allocation with __GFP_NOWAIT > fails easily although it's order-0 request. > I got below warning 9 times for normal boot. > > [ 17.072747] c0 0 : page allocation failure: order:0, >

Re: [PATCH] mm:memcg: add __GFP_NOWARN in __memcg_schedule_kmem_cache_create

On Wed, 18 Apr 2018, Minchan Kim wrote: > If there are heavy memory pressure, page allocation with __GFP_NOWAIT > fails easily although it's order-0 request. > I got below warning 9 times for normal boot. > > [ 17.072747] c0 0 : page allocation failure: order:0, >

Re: [PATCH v4] ARM: dts: imx6q-icore-ofcap12: Switch LVDS timings from panel-simple

On Mon, Mar 26, 2018 at 01:35:53PM +0530, Jagan Teki wrote: > Switch to use koe_tx31d200vm0baa LVDS timings from > panel-simple instead hard coding the same in dts. > > Signed-off-by: Jagan Teki Applied both, thanks.

Re: [PATCH v4] ARM: dts: imx6q-icore-ofcap12: Switch LVDS timings from panel-simple

On Mon, Mar 26, 2018 at 01:35:53PM +0530, Jagan Teki wrote: > Switch to use koe_tx31d200vm0baa LVDS timings from > panel-simple instead hard coding the same in dts. > > Signed-off-by: Jagan Teki Applied both, thanks.

[patch v2] mm, oom: fix concurrent munlock and oom reaper unmap

Since exit_mmap() is done without the protection of mm->mmap_sem, it is possible for the oom reaper to concurrently operate on an mm until MMF_OOM_SKIP is set. This allows munlock_vma_pages_all() to concurrently run while the oom reaper is operating on a vma. Since munlock_vma_pages_range()

[patch v2] mm, oom: fix concurrent munlock and oom reaper unmap

Since exit_mmap() is done without the protection of mm->mmap_sem, it is possible for the oom reaper to concurrently operate on an mm until MMF_OOM_SKIP is set. This allows munlock_vma_pages_all() to concurrently run while the oom reaper is operating on a vma. Since munlock_vma_pages_range()

Re: [patch] mm, oom: fix concurrent munlock and oom reaper unmap

On Wed, 18 Apr 2018, Tetsuo Handa wrote: > > Since exit_mmap() is done without the protection of mm->mmap_sem, it is > > possible for the oom reaper to concurrently operate on an mm until > > MMF_OOM_SKIP is set. > > > > This allows munlock_vma_pages_all() to concurrently run while the oom > >

Re: [patch] mm, oom: fix concurrent munlock and oom reaper unmap

On Wed, 18 Apr 2018, Tetsuo Handa wrote: > > Since exit_mmap() is done without the protection of mm->mmap_sem, it is > > possible for the oom reaper to concurrently operate on an mm until > > MMF_OOM_SKIP is set. > > > > This allows munlock_vma_pages_all() to concurrently run while the oom > >

Re: [PATCH 3/6] staging: lustre: remove include/linux/libcfs/linux/linux-cpu.h

On Mon, Apr 16 2018, James Simmons wrote: >> This include file contains definitions used when CONFIG_SMP >> is in effect. Other includes contain corresponding definitions >> for when it isn't. >> This can be hard to follow, so move the definitions to the one place. >> >> As HAVE_LIBCFS_CPT is

Re: [PATCH 3/6] staging: lustre: remove include/linux/libcfs/linux/linux-cpu.h

On Mon, Apr 16 2018, James Simmons wrote: >> This include file contains definitions used when CONFIG_SMP >> is in effect. Other includes contain corresponding definitions >> for when it isn't. >> This can be hard to follow, so move the definitions to the one place. >> >> As HAVE_LIBCFS_CPT is

Re: [PATCH] PCI: Add PCIe to pcie_print_link_status() messages

On Fri, 13 Apr 2018 11:16:38 -0700, Jakub Kicinski wrote: > Currently the pcie_print_link_status() will print PCIe bandwidth > and link width information but does not mention it is pertaining > to the PCIe. Since this and related functions are used exclusively > by networking drivers today users

Re: [PATCH] PCI: Add PCIe to pcie_print_link_status() messages

On Fri, 13 Apr 2018 11:16:38 -0700, Jakub Kicinski wrote: > Currently the pcie_print_link_status() will print PCIe bandwidth > and link width information but does not mention it is pertaining > to the PCIe. Since this and related functions are used exclusively > by networking drivers today users

Re: [PATCH v2] clk: imx: Set CLK_SET_RATE_GATE for gate and divider clocks

On Wed, Apr 11, 2018 at 05:03:29PM +0300, Abel Vesa wrote: > From: Shawn Guo > > Add flag CLK_SET_RATE_GATE for i.MX gate and divider clocks on which the > client drivers usually make clk_set_rate() call, so that the call will fail > when clock is still on instead of

Re: [PATCH v2] clk: imx: Set CLK_SET_RATE_GATE for gate and divider clocks

On Wed, Apr 11, 2018 at 05:03:29PM +0300, Abel Vesa wrote: > From: Shawn Guo > > Add flag CLK_SET_RATE_GATE for i.MX gate and divider clocks on which the > client drivers usually make clk_set_rate() call, so that the call will fail > when clock is still on instead of standing the risk of running

  1   2   3   4   5   6   7   8   9   10   >