Re: a question of split_huge_page

On 10.7.2020 10.00, Alex Shi wrote: > > 在 2020/7/10 下午1:28, Mika Penttilä 写道: >>> Thanks a lot for quick reply! >>> What I am confusing is the call chain: __iommu_dma_alloc_pages() >>> to split_huge_page(), in the func, splited page, >>> page

Re: a question of split_huge_page

On 10.7.2020 7.51, Alex Shi wrote: > > 在 2020/7/10 上午12:07, Kirill A. Shutemov 写道: >> On Thu, Jul 09, 2020 at 04:50:02PM +0100, Matthew Wilcox wrote: >>> On Thu, Jul 09, 2020 at 11:11:11PM +0800, Alex Shi wrote: Hi Kirill & Matthew, In the func call chain, from split_huge_page()

Re: [PATCH 4/6] vhost_vdpa: support doorbell mapping via mmap

Hi, On 29.5.2020 11.03, Jason Wang wrote: Currently the doorbell is relayed via eventfd which may have significant overhead because of the cost of vmexits or syscall. This patch introduces mmap() based doorbell mapping which can eliminate the overhead caused by vmexit or syscall. Just

BUG/Oops - unix domain sockets / wakeups

Hello, I have got  a couple of these in a week with 5.3-rc. Happens very randomly and infrequently, the system has been nearly idle. Otoh, seems new to 5.3, dont remeber this happening before. Thanks, Mika # [386517.339218] Internal error: Oops: 17 [#1] PREEMPT SMP ARM [386517.344726] Modules

Re: [PATCH 2/4] pid: add pidctl()

Hi! > +SYSCALL_DEFINE5(pidctl, unsigned int, cmd, pid_t, pid, int, source, int, > target, > + unsigned int, flags) > +{ > + struct pid_namespace *source_ns = NULL, *target_ns = NULL; > + struct pid *struct_pid; > + pid_t result; > + > + switch (cmd) { > + case

Re: Regression: i.MX6: pinctrl: fsl: add scu based pinctrl support

Hi! On 14.1.2019 18.58, Fabio Estevam wrote: > Hi Mika, > > On Mon, Jan 14, 2019 at 8:21 AM Mika Penttilä > wrote: >> Hello, >> >> >> The patch titled "pinctrl: fsl: add scu based pinctrl support" causes >> regression on i.MX6. Tested on

Regression: i.MX6: pinctrl: fsl: add scu based pinctrl support

Hello, The patch titled "pinctrl: fsl: add scu based pinctrl support" causes regression on i.MX6. Tested on a custom board based on i.MX6Q and sgtl5000 codec, there is no sound,  tested with simple wav playing. Reverting the patch makes audio work again. --Mika pEpkey.asc Description:

Re: [PATCH] PM / suspend: Count suspend-to-idle loop as sleep time

On 09/14/2018 11:46 AM, Rafael J. Wysocki wrote: > On Friday, September 14, 2018 10:28:44 AM CEST Mika Penttilä wrote: >> Hi! >> >> >> On 09/14/2018 09:59 AM, Rafael J. Wysocki wrote: >>> From: Rafael J. Wysocki >>> >>> There is a differen

Re: [PATCH] PM / suspend: Count suspend-to-idle loop as sleep time

On 09/14/2018 11:46 AM, Rafael J. Wysocki wrote: > On Friday, September 14, 2018 10:28:44 AM CEST Mika Penttilä wrote: >> Hi! >> >> >> On 09/14/2018 09:59 AM, Rafael J. Wysocki wrote: >>> From: Rafael J. Wysocki >>> >>> There is a differen

Re: [PATCH] PM / suspend: Count suspend-to-idle loop as sleep time

Hi! On 09/14/2018 09:59 AM, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > There is a difference in behavior between suspend-to-idle and > suspend-to-RAM in the timekeeping handling that leads to functional > issues. Namely, every iteration of the loop in s2idle_loop() > increases the

Re: [PATCH] PM / suspend: Count suspend-to-idle loop as sleep time

Hi! On 09/14/2018 09:59 AM, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > There is a difference in behavior between suspend-to-idle and > suspend-to-RAM in the timekeeping handling that leads to functional > issues. Namely, every iteration of the loop in s2idle_loop() > increases the

Re: [RFC v6 PATCH 2/2] mm: mmap: zap pages with read mmap_sem in munmap

On 26.07.2018 21:10, Yang Shi wrote: > When running some mmap/munmap scalability tests with large memory (i.e. >> 300GB), the below hung task issue may happen occasionally. > INFO: task ps:14018 blocked for more than 120 seconds. >Tainted: GE 4.9.79-009.ali3000.alios7.x86_64

Re: [RFC v6 PATCH 2/2] mm: mmap: zap pages with read mmap_sem in munmap

On 26.07.2018 21:10, Yang Shi wrote: > When running some mmap/munmap scalability tests with large memory (i.e. >> 300GB), the below hung task issue may happen occasionally. > INFO: task ps:14018 blocked for more than 120 seconds. >Tainted: GE 4.9.79-009.ali3000.alios7.x86_64

Re: [PATCHv3 14/17] x86/mm: Introduce direct_mapping_size

On 12.06.2018 17:39, Kirill A. Shutemov wrote: > Kernel need to have a way to access encrypted memory. We are going to > use per-KeyID direct mapping to facilitate the access with minimal > overhead. > > Direct mapping for each KeyID will be put next to each other in the > virtual address

Re: [PATCHv3 14/17] x86/mm: Introduce direct_mapping_size

On 12.06.2018 17:39, Kirill A. Shutemov wrote: > Kernel need to have a way to access encrypted memory. We are going to > use per-KeyID direct mapping to facilitate the access with minimal > overhead. > > Direct mapping for each KeyID will be put next to each other in the > virtual address

Re: [PATCH 6/6] x86/vdso: Move out the CPU number store

On 06/05/2018 08:36 AM, H. Peter Anvin wrote: > On 06/04/18 20:57, Mika Penttilä wrote: >> >> This won't work on X86-32 because it actually uses the segment limit with >> fs: access. So there >> is a reason why the lsl based method is X86-64 only. >> > >

Re: [PATCH 6/6] x86/vdso: Move out the CPU number store

On 06/05/2018 08:36 AM, H. Peter Anvin wrote: > On 06/04/18 20:57, Mika Penttilä wrote: >> >> This won't work on X86-32 because it actually uses the segment limit with >> fs: access. So there >> is a reason why the lsl based method is X86-64 only. >> > >

Re: [PATCH 6/6] x86/vdso: Move out the CPU number store

On 06/05/2018 07:44 AM, Bae, Chang Seok wrote: >>> diff --git a/arch/x86/kernel/setup_percpu.c b/arch/x86/kernel/setup_percpu.c >>> index ea554f8..e716e94 100644 >>> --- a/arch/x86/kernel/setup_percpu.c >>> +++ b/arch/x86/kernel/setup_percpu.c >>> @@ -155,12 +155,21 @@ static void __init

Re: [PATCH 6/6] x86/vdso: Move out the CPU number store

On 06/05/2018 07:44 AM, Bae, Chang Seok wrote: >>> diff --git a/arch/x86/kernel/setup_percpu.c b/arch/x86/kernel/setup_percpu.c >>> index ea554f8..e716e94 100644 >>> --- a/arch/x86/kernel/setup_percpu.c >>> +++ b/arch/x86/kernel/setup_percpu.c >>> @@ -155,12 +155,21 @@ static void __init

Re: [PATCH 6/6] x86/vdso: Move out the CPU number store

On 06/04/2018 10:24 PM, Chang S. Bae wrote: > The CPU (and node) number will be written, as early enough, > to the segment limit of per CPU data and TSC_AUX MSR entry. > The information has been retrieved by vgetcpu in user space > and will be also loaded from the paranoid entry, when > FSGSBASE

Re: [PATCH 6/6] x86/vdso: Move out the CPU number store

On 06/04/2018 10:24 PM, Chang S. Bae wrote: > The CPU (and node) number will be written, as early enough, > to the segment limit of per CPU data and TSC_AUX MSR entry. > The information has been retrieved by vgetcpu in user space > and will be also loaded from the paranoid entry, when > FSGSBASE

Re: [PATCH v2 4/9] x86, memcpy_mcsafe: add write-protection-fault handling

On 05/03/2018 07:59 AM, Dan Williams wrote: > In preparation for using memcpy_mcsafe() to handle user copies it needs > to be to handle write-protection faults while writing user pages. Add > MMU-fault handlers alongside the machine-check exception handlers. > > Note that the machine check fault

Re: [PATCH v2 4/9] x86, memcpy_mcsafe: add write-protection-fault handling

On 05/03/2018 07:59 AM, Dan Williams wrote: > In preparation for using memcpy_mcsafe() to handle user copies it needs > to be to handle write-protection faults while writing user pages. Add > MMU-fault handlers alongside the machine-check exception handlers. > > Note that the machine check fault

Re: [REGRESSION][BISECTED] i.MX6 pinctrl hogs stopped working

On 10.04.2018 13:21, Richard Fitzgerald wrote: > On 04/04/18 06:33, Mika Penttilä wrote: >> Hi! >> >> Reverting this made the hogs on a i.MX6 board work again. : >> >> >> commit b89405b6102fcc3746f43697b826028caa94c823 >> Author: Richard Fitzgerald &l

Re: [REGRESSION][BISECTED] i.MX6 pinctrl hogs stopped working

On 10.04.2018 13:21, Richard Fitzgerald wrote: > On 04/04/18 06:33, Mika Penttilä wrote: >> Hi! >> >> Reverting this made the hogs on a i.MX6 board work again. : >> >> >> commit b89405b6102fcc3746f43697b826028caa94c823 >> Author: Richard Fitzgera

Re: [PATCH] ASoC: fsl_ssi: Fix mode setting when changing channel number

comments to declare ssi->i2s_net does > not reflect the register value but merely the initial setting from > the set_dai_fmt(). > > Reported-by: Mika Penttilä <mika.pentt...@nextfour.com> > Signed-off-by: Nicolin Chen <nicoleots...@gmail.com> > Cc: Mika Penttilä <m

Re: [PATCH] ASoC: fsl_ssi: Fix mode setting when changing channel number

comments to declare ssi->i2s_net does > not reflect the register value but merely the initial setting from > the set_dai_fmt(). > > Reported-by: Mika Penttilä > Signed-off-by: Nicolin Chen > Cc: Mika Penttilä > --- > sound/soc/fsl/fsl_ssi.c | 14 +++--- > 1 fi

Fwd: regression, imx6 and sgtl5000 sound problems

> On Fri, Apr 06, 2018 at 07:46:37AM +0300, Mika Penttilä wrote: >> >> With recent merge to pre 4.17-rc, audio stopped workin (or it's hearable but >> way too slow). >> imx6q + sgtl5000 codec. > > Could you please be more specific at your test cases? > &g

Fwd: regression, imx6 and sgtl5000 sound problems

> On Fri, Apr 06, 2018 at 07:46:37AM +0300, Mika Penttilä wrote: >> >> With recent merge to pre 4.17-rc, audio stopped workin (or it's hearable but >> way too slow). >> imx6q + sgtl5000 codec. > > Could you please be more specific at your test cases? > &g

Re: regression, imx6 and sgtl5000 sound problems

On 04/06/2018 10:23 AM, Nicolin Chen wrote: > On Fri, Apr 06, 2018 at 07:46:37AM +0300, Mika Penttilä wrote: >> >> With recent merge to pre 4.17-rc, audio stopped workin (or it's hearable but >> way too slow). >> imx6q + sgtl5000 codec. > > Could you please be

Re: regression, imx6 and sgtl5000 sound problems

On 04/06/2018 10:23 AM, Nicolin Chen wrote: > On Fri, Apr 06, 2018 at 07:46:37AM +0300, Mika Penttilä wrote: >> >> With recent merge to pre 4.17-rc, audio stopped workin (or it's hearable but >> way too slow). >> imx6q + sgtl5000 codec. > > Could you please be

regression, imx6 and sgtl5000 sound problems

Hi, With recent merge to pre 4.17-rc, audio stopped workin (or it's hearable but way too slow). imx6q + sgtl5000 codec. Maybe some of the soc/fsl changes is causing this. --Mika

regression, imx6 and sgtl5000 sound problems

Hi, With recent merge to pre 4.17-rc, audio stopped workin (or it's hearable but way too slow). imx6q + sgtl5000 codec. Maybe some of the soc/fsl changes is causing this. --Mika

[REGRESSION][BISECTED] i.MX6 pinctrl hogs stopped working

Hi! Reverting this made the hogs on a i.MX6 board work again. : commit b89405b6102fcc3746f43697b826028caa94c823 Author: Richard Fitzgerald Date: Wed Feb 28 15:53:06 2018 + pinctrl: devicetree: Fix dt_to_map_one_config handling of hogs --Mika

[REGRESSION][BISECTED] i.MX6 pinctrl hogs stopped working

Hi! Reverting this made the hogs on a i.MX6 board work again. : commit b89405b6102fcc3746f43697b826028caa94c823 Author: Richard Fitzgerald Date: Wed Feb 28 15:53:06 2018 + pinctrl: devicetree: Fix dt_to_map_one_config handling of hogs --Mika

Re: [regression, bisected] 4.11+ imx uarts broken

On 05/09/2017 10:14 AM, Uwe Kleine-König wrote: > Hello Mika, > > On Tue, May 09, 2017 at 07:18:09AM +0300, Mika Penttilä wrote: >> The following commit e61c38d85b7 makes the uarts on i.MX6 nonfunctional (no >> data transmitted or received). >> With e61c38d85b7

Re: [regression, bisected] 4.11+ imx uarts broken

On 05/09/2017 10:14 AM, Uwe Kleine-König wrote: > Hello Mika, > > On Tue, May 09, 2017 at 07:18:09AM +0300, Mika Penttilä wrote: >> The following commit e61c38d85b7 makes the uarts on i.MX6 nonfunctional (no >> data transmitted or received). >> With e61c38d85b7

[regression, bisected] 4.11+ imx uarts broken

Hi, The following commit e61c38d85b7 makes the uarts on i.MX6 nonfunctional (no data transmitted or received). With e61c38d85b7 reverted the uarts work ok. --- commit e61c38d85b7392e033ee03bca46f1d6006156175 Author: Uwe Kleine-König Date: Tue

[regression, bisected] 4.11+ imx uarts broken

Hi, The following commit e61c38d85b7 makes the uarts on i.MX6 nonfunctional (no data transmitted or received). With e61c38d85b7 reverted the uarts work ok. --- commit e61c38d85b7392e033ee03bca46f1d6006156175 Author: Uwe Kleine-König Date: Tue Apr 4 11:18:51 2017 +0200

nvdimm/pmem device lifetime

Hi, Just wondering the pmem struct device vs gendisk lifetimes.. from pmem_attach_disk(): device_add_disk(dev, disk); devm_add_action_or_reset(dev, pmem_release_disk, disk); where: static void pmem_release_disk(void *disk) { del_gendisk(disk); put_disk(disk); }

nvdimm/pmem device lifetime

Hi, Just wondering the pmem struct device vs gendisk lifetimes.. from pmem_attach_disk(): device_add_disk(dev, disk); devm_add_action_or_reset(dev, pmem_release_disk, disk); where: static void pmem_release_disk(void *disk) { del_gendisk(disk); put_disk(disk); }

Re: [PATCH 2/5] zram: partial IO refactoring

On 04/03/2017 09:12 AM, Minchan Kim wrote: > Hi Mika, > > On Mon, Apr 03, 2017 at 08:52:33AM +0300, Mika Penttilä wrote: >> >> Hi! >> >> On 04/03/2017 08:17 AM, Minchan Kim wrote: >>> For architecture(PAGE_SIZE > 4K), zram have supported partial IO. &g

Re: [PATCH 2/5] zram: partial IO refactoring

On 04/03/2017 09:12 AM, Minchan Kim wrote: > Hi Mika, > > On Mon, Apr 03, 2017 at 08:52:33AM +0300, Mika Penttilä wrote: >> >> Hi! >> >> On 04/03/2017 08:17 AM, Minchan Kim wrote: >>> For architecture(PAGE_SIZE > 4K), zram have supported partial IO. &g

Re: [PATCH 2/5] zram: partial IO refactoring

Hi! On 04/03/2017 08:17 AM, Minchan Kim wrote: > For architecture(PAGE_SIZE > 4K), zram have supported partial IO. > However, the mixed code for handling normal/partial IO is too mess, > error-prone to modify IO handler functions with upcoming feature > so this patch aims for cleaning up zram's

Re: [PATCH 2/5] zram: partial IO refactoring

Hi! On 04/03/2017 08:17 AM, Minchan Kim wrote: > For architecture(PAGE_SIZE > 4K), zram have supported partial IO. > However, the mixed code for handling normal/partial IO is too mess, > error-prone to modify IO handler functions with upcoming feature > so this patch aims for cleaning up zram's

[PATCH] fix pinctrl setup for i.IMX6

-off-by: Mika Penttilä <mika.pentt...@nextfour.com> --- diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c index d690465..33659c5a 100644 --- a/drivers/pinctrl/core.c +++ b/drivers/pinctrl/core.c @@ -2237,6 +2237,47 @@ int devm_pinctrl_register_and_init(struct devic

[PATCH] fix pinctrl setup for i.IMX6

-off-by: Mika Penttilä --- diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c index d690465..33659c5a 100644 --- a/drivers/pinctrl/core.c +++ b/drivers/pinctrl/core.c @@ -2237,6 +2237,47 @@ int devm_pinctrl_register_and_init(struct device *dev, } EXPORT_SYMBOL_GPL

[REGRESSION] pinctrl, of, unable to find hogs

With current linus git (pre 4.11), unable to find the pinctrl hogs : imx6q-pinctrl 20e.iomuxc: unable to find group for node hoggrp Device is i.MX6 based. --Mika

[REGRESSION] pinctrl, of, unable to find hogs

With current linus git (pre 4.11), unable to find the pinctrl hogs : imx6q-pinctrl 20e.iomuxc: unable to find group for node hoggrp Device is i.MX6 based. --Mika

Re: [PATCH 1/2] exec: don't wait for zombie threads with cred_guard_mutex held

On 13.02.2017 16:15, Oleg Nesterov wrote: > + retval = de_thread(current); > + if (retval) > + return retval; > > if (N_MAGIC(ex) == OMAGIC) { > unsigned long text_addr, map_size; > diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c > index 4223702..79508f7

Re: [PATCH 1/2] exec: don't wait for zombie threads with cred_guard_mutex held

On 13.02.2017 16:15, Oleg Nesterov wrote: > + retval = de_thread(current); > + if (retval) > + return retval; > > if (N_MAGIC(ex) == OMAGIC) { > unsigned long text_addr, map_size; > diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c > index 4223702..79508f7

Re: [PATCH 2/2] efi: efi_mem_reserve(): don't reserve through memblock after mm_init()

On 21.12.2016 20:28, Nicolai Stange wrote: > Before invoking the arch specific handler, efi_mem_reserve() reserves > the given memory region through memblock. > > efi_mem_reserve() can get called after mm_init() though -- through > efi_bgrt_init(), for example. After mm_init(), memblock is dead

Re: [PATCH 2/2] efi: efi_mem_reserve(): don't reserve through memblock after mm_init()

On 21.12.2016 20:28, Nicolai Stange wrote: > Before invoking the arch specific handler, efi_mem_reserve() reserves > the given memory region through memblock. > > efi_mem_reserve() can get called after mm_init() though -- through > efi_bgrt_init(), for example. After mm_init(), memblock is dead

Re: [PATCH] bdi flusher should not be throttled here when it fall into buddy slow path

On 20.10.2016 15:38, zhouxianr...@huawei.com wrote: > From: z00281421 > > The bdi flusher should be throttled only depends on > own bdi and is decoupled with others. > > separate PGDAT_WRITEBACK into PGDAT_ANON_WRITEBACK and > PGDAT_FILE_WRITEBACK avoid scanning

Re: [PATCH] bdi flusher should not be throttled here when it fall into buddy slow path

On 20.10.2016 15:38, zhouxianr...@huawei.com wrote: > From: z00281421 > > The bdi flusher should be throttled only depends on > own bdi and is decoupled with others. > > separate PGDAT_WRITEBACK into PGDAT_ANON_WRITEBACK and > PGDAT_FILE_WRITEBACK avoid scanning anon lru and it is ok > then

Re: EXT: pre 4.9-rc dma regression, imx6 sound etc

On 10/13/2016 08:25 AM, Han, Nandor (GE Healthcare) wrote: > > > On 12/10/2016 16:25, Mika Penttilä wrote: >> Hi! >> >> Bisected that commit 5881826 - "dmaengine: imx-sdma - update the residue >> calculation for cyclic channels" is first bad co

Re: EXT: pre 4.9-rc dma regression, imx6 sound etc

On 10/13/2016 08:25 AM, Han, Nandor (GE Healthcare) wrote: > > > On 12/10/2016 16:25, Mika Penttilä wrote: >> Hi! >> >> Bisected that commit 5881826 - "dmaengine: imx-sdma - update the residue >> calculation for cyclic channels" is first bad co

pre 4.9-rc dma regression, imx6 sound etc

Hi! Bisected that commit 5881826 - "dmaengine: imx-sdma - update the residue calculation for cyclic channels" is first bad commit to cause audio regression on imx6q, sgtl5000 codec. It causes audible disturbing background noise when playing wavs. Unfortunately, reverting only 5881826

pre 4.9-rc dma regression, imx6 sound etc

Hi! Bisected that commit 5881826 - "dmaengine: imx-sdma - update the residue calculation for cyclic channels" is first bad commit to cause audio regression on imx6q, sgtl5000 codec. It causes audible disturbing background noise when playing wavs. Unfortunately, reverting only 5881826

Re: [PATCH] KVM: VMX: Enable MSR-BASED TPR shadow even if w/o APICv

On 09/15/2016 07:25 AM, Wanpeng Li wrote: > 2016-09-15 12:08 GMT+08:00 Mika Penttilä <mika.pentt...@nextfour.com>: >> On 09/14/2016 10:58 AM, Wanpeng Li wrote: >>> From: Wanpeng Li <wanpeng...@hotmail.com> >>> >>> I observed that kvmvapic(to optimize

Re: [PATCH] KVM: VMX: Enable MSR-BASED TPR shadow even if w/o APICv

On 09/15/2016 07:25 AM, Wanpeng Li wrote: > 2016-09-15 12:08 GMT+08:00 Mika Penttilä : >> On 09/14/2016 10:58 AM, Wanpeng Li wrote: >>> From: Wanpeng Li >>> >>> I observed that kvmvapic(to optimize flexpriority=N or AMD) is used >>> to boost TPR access

Re: [PATCH] KVM: VMX: Enable MSR-BASED TPR shadow even if w/o APICv

On 09/14/2016 10:58 AM, Wanpeng Li wrote: > From: Wanpeng Li > > I observed that kvmvapic(to optimize flexpriority=N or AMD) is used > to boost TPR access when testing kvm-unit-test/eventinj.flat tpr case > on my haswell desktop (w/ flexpriority, w/o APICv). Commit

Re: [PATCH] KVM: VMX: Enable MSR-BASED TPR shadow even if w/o APICv

On 09/14/2016 10:58 AM, Wanpeng Li wrote: > From: Wanpeng Li > > I observed that kvmvapic(to optimize flexpriority=N or AMD) is used > to boost TPR access when testing kvm-unit-test/eventinj.flat tpr case > on my haswell desktop (w/ flexpriority, w/o APICv). Commit (8d14695f9542 > x86, apicv:

[PATCH] bluetooth, regression: MSG_TRUNC fixes

Recent 4.8-rc changes to bluetooth MSG_TRUNC handling introduced regression; pairing finishes but connecting profiles not. With the below fixes to MSG_TRUNC handling the connection is established normally. --Mika Signed-off-by: Mika Penttilä <mika.pentt...@nextfour.com> --- diff

[PATCH] bluetooth, regression: MSG_TRUNC fixes

Recent 4.8-rc changes to bluetooth MSG_TRUNC handling introduced regression; pairing finishes but connecting profiles not. With the below fixes to MSG_TRUNC handling the connection is established normally. --Mika Signed-off-by: Mika Penttilä --- diff --git a/net/bluetooth/af_bluetooth.c b

Re: kvm vmx shadow paging question

On 13.08.2016 18:47, Mika Penttilä wrote: > On 13.08.2016 17:38, Mika Penttilä wrote: > >> Hi, >> >> While studying the vmx code, and the shadow page tables usage (no ept >> involved), >> I wondered the GUEST_CR3 usage. If no ept, GUEST_CR3 points to the

Re: kvm vmx shadow paging question

On 13.08.2016 18:47, Mika Penttilä wrote: > On 13.08.2016 17:38, Mika Penttilä wrote: > >> Hi, >> >> While studying the vmx code, and the shadow page tables usage (no ept >> involved), >> I wondered the GUEST_CR3 usage. If no ept, GUEST_CR3 points to the

Re: kvm vmx shadow paging question

On 13.08.2016 17:38, Mika Penttilä wrote: > Hi, > > While studying the vmx code, and the shadow page tables usage (no ept > involved), > I wondered the GUEST_CR3 usage. If no ept, GUEST_CR3 points to the shadow > tables. > But the format of sptes is always 64 bit. How is t

Re: kvm vmx shadow paging question

On 13.08.2016 17:38, Mika Penttilä wrote: > Hi, > > While studying the vmx code, and the shadow page tables usage (no ept > involved), > I wondered the GUEST_CR3 usage. If no ept, GUEST_CR3 points to the shadow > tables. > But the format of sptes is always 64 bit. How is t

Re: [PATCH v1 2/2] x86/KASLR: Increase BRK pages for KASLR memory randomization

On 08/08/2016 09:40 PM, Thomas Garnier wrote: > Default implementation expects 6 pages maximum are needed for low page > allocations. If KASLR memory randomization is enabled, the worse case > of e820 layout would require 12 pages (no large pages). It is due to the > PUD level randomization and

Re: [PATCH v1 2/2] x86/KASLR: Increase BRK pages for KASLR memory randomization

On 08/08/2016 09:40 PM, Thomas Garnier wrote: > Default implementation expects 6 pages maximum are needed for low page > allocations. If KASLR memory randomization is enabled, the worse case > of e820 layout would require 12 pages (no large pages). It is due to the > PUD level randomization and

Re: [PATCH v4 00/29] virtually mapped stacks and thread_info cleanup

On 29.06.2016 10:06, Mika Penttilä wrote: > On 06/27/2016 12:55 AM, Andy Lutomirski wrote: >> Hi all- >> >> Known issues: >> - tcp md5, virtio_net, and virtio_console will have issues. Eric Dumazet >>has a patch for tcp md5, and Michael

Re: [PATCH v4 00/29] virtually mapped stacks and thread_info cleanup

On 29.06.2016 10:06, Mika Penttilä wrote: > On 06/27/2016 12:55 AM, Andy Lutomirski wrote: >> Hi all- >> >> Known issues: >> - tcp md5, virtio_net, and virtio_console will have issues. Eric Dumazet >>has a patch for tcp md5, and Michael

Re: [PATCH v4 00/29] virtually mapped stacks and thread_info cleanup

On 06/27/2016 12:55 AM, Andy Lutomirski wrote: > Hi all- > > > Known issues: > - tcp md5, virtio_net, and virtio_console will have issues. Eric Dumazet >has a patch for tcp md5, and Michael Tsirkin says he'll fix virtio_net >and virtio_console. > How about PTRACE_SETREGS, it's using

Re: [PATCH v4 00/29] virtually mapped stacks and thread_info cleanup

On 06/27/2016 12:55 AM, Andy Lutomirski wrote: > Hi all- > > > Known issues: > - tcp md5, virtio_net, and virtio_console will have issues. Eric Dumazet >has a patch for tcp md5, and Michael Tsirkin says he'll fix virtio_net >and virtio_console. > How about PTRACE_SETREGS, it's using

Re: [PATCH 12/13] x86/mm/64: Enable vmapped stacks

Hi, On 06/16/2016 03:28 AM, Andy Lutomirski wrote: > This allows x86_64 kernels to enable vmapped stacks. There are a > couple of interesting bits. > > First, x86 lazily faults in top-level paging entries for the vmalloc > area. This won't work if we get a page fault while trying to access >

Re: [PATCH 12/13] x86/mm/64: Enable vmapped stacks

Hi, On 06/16/2016 03:28 AM, Andy Lutomirski wrote: > This allows x86_64 kernels to enable vmapped stacks. There are a > couple of interesting bits. > > First, x86 lazily faults in top-level paging entries for the vmalloc > area. This won't work if we get a page fault while trying to access >

Re: [PATCH v2] sched/cputime: add steal time support to full dynticks CPU time accounting

On 05/18/2016 11:28 AM, Wanpeng Li wrote: > From: Wanpeng Li > > This patch adds steal guest time support to full dynticks CPU > time accounting. After 'commit ff9a9b4c4334 ("sched, time: Switch > VIRT_CPU_ACCOUNTING_GEN to jiffy granularity")', time is jiffy > based

Re: [PATCH v2] sched/cputime: add steal time support to full dynticks CPU time accounting

On 05/18/2016 11:28 AM, Wanpeng Li wrote: > From: Wanpeng Li > > This patch adds steal guest time support to full dynticks CPU > time accounting. After 'commit ff9a9b4c4334 ("sched, time: Switch > VIRT_CPU_ACCOUNTING_GEN to jiffy granularity")', time is jiffy > based sampling even if it's

[BUG] 4.4.7 af_unix, wakeup

Have hit this same looking oops every now and then since at least 4.2 or so.. Not easy to reproduce systematically. --Mika [10973.891726] Unable to handle kernel NULL pointer dereference at virtual address [10973.899839] pgd = a8ce4000 [10973.902549] [] *pgd=38c38831,

[BUG] 4.4.7 af_unix, wakeup

Have hit this same looking oops every now and then since at least 4.2 or so.. Not easy to reproduce systematically. --Mika [10973.891726] Unable to handle kernel NULL pointer dereference at virtual address [10973.899839] pgd = a8ce4000 [10973.902549] [] *pgd=38c38831,

Re: [PATCH 23/31] huge tmpfs recovery: framework for reconstituting huge pages

On 04/06/2016 12:53 AM, Hugh Dickins wrote: > +static void shmem_recovery_work(struct work_struct *work) > +{ > + struct recovery *recovery; > + struct shmem_inode_info *info; > + struct address_space *mapping; > + struct page *page; > + struct page *head = NULL; > + int

Re: [PATCH 23/31] huge tmpfs recovery: framework for reconstituting huge pages

On 04/06/2016 12:53 AM, Hugh Dickins wrote: > +static void shmem_recovery_work(struct work_struct *work) > +{ > + struct recovery *recovery; > + struct shmem_inode_info *info; > + struct address_space *mapping; > + struct page *page; > + struct page *head = NULL; > + int

Re: [PATCH v14] x86, mce: Add memcpy_mcsafe()

On 18.02.2016 21:47, Tony Luck wrote: > Make use of the EXTABLE_FAULT exception table entries to write > a kernel copy routine that doesn't crash the system if it > encounters a machine check. Prime use case for this is to copy > from large arrays of non-volatile memory used as storage. > > We

Re: [PATCH v14] x86, mce: Add memcpy_mcsafe()

On 18.02.2016 21:47, Tony Luck wrote: > Make use of the EXTABLE_FAULT exception table entries to write > a kernel copy routine that doesn't crash the system if it > encounters a machine check. Prime use case for this is to copy > from large arrays of non-volatile memory used as storage. > > We

[BUG] 4.5-rc7 af unix related

Have got some of these same looking crashes after 4.4 (maybe before also, not sure). Very random, not easy to reproduce. --Mika [ 1999.948171] Unable to handle kernel NULL pointer dereference at virtual address [ 1999.955740] pgd = a8ba4000 [ 1999.958264] [] *pgd=38ca7831,

[BUG] 4.5-rc7 af unix related

Have got some of these same looking crashes after 4.4 (maybe before also, not sure). Very random, not easy to reproduce. --Mika [ 1999.948171] Unable to handle kernel NULL pointer dereference at virtual address [ 1999.955740] pgd = a8ba4000 [ 1999.958264] [] *pgd=38ca7831,

Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack

On 02.03.2016 18:55, Borislav Petkov wrote: > On Wed, Mar 02, 2016 at 06:38:15PM +0200, Mika Penttilä wrote: >> I actually looked at it a while too... >> >> The >> movq stack_start - __START_KERNEL_map, %rsp >> >> turns into (objdump disassembly) >&g

Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack

On 02.03.2016 18:55, Borislav Petkov wrote: > On Wed, Mar 02, 2016 at 06:38:15PM +0200, Mika Penttilä wrote: >> I actually looked at it a while too... >> >> The >> movq stack_start - __START_KERNEL_map, %rsp >> >> turns into (objdump disassembly) >&g

Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack

On 02.03.2016 18:15, Borislav Petkov wrote: > On Wed, Mar 02, 2016 at 05:55:14PM +0200, Mika Penttilä wrote: >>> + /* Setup a stack for verify_cpu */ >>> + movqstack_start - __START_KERNEL_map, %rsp >>> + subq$__START_KERNEL_map, %rsp >>> + &

Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack

On 02.03.2016 18:15, Borislav Petkov wrote: > On Wed, Mar 02, 2016 at 05:55:14PM +0200, Mika Penttilä wrote: >>> + /* Setup a stack for verify_cpu */ >>> + movqstack_start - __START_KERNEL_map, %rsp >>> + subq$__START_KERNEL_map, %rsp >>> + &

Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack

On 02.03.2016 13:20, Borislav Petkov wrote: > From: Borislav Petkov > > 04633df0c43d ("x86/cpu: Call verify_cpu() after having entered long mode too") > added the call to verify_cpu() for sanitizing CPU configuration. > > The latter uses the stack minimally and it can happen that we

Re: [RFC PATCH] x86: Make sure verify_cpu has a good stack

On 02.03.2016 13:20, Borislav Petkov wrote: > From: Borislav Petkov > > 04633df0c43d ("x86/cpu: Call verify_cpu() after having entered long mode too") > added the call to verify_cpu() for sanitizing CPU configuration. > > The latter uses the stack minimally and it can happen that we land in >

Re: [REGRESSION, bisected] 4.5rc4 sound fsl-soc

. Thanks, Mika On 20.02.2016 22:45, Fabio Estevam wrote: > Hi Mika, > > Did it work for you? > > If so, please ask in the mailing list for Mark Brown to apply that patch. > > Thanks > > ____ > From: Mika Penttilä <mika.pent

Re: [REGRESSION, bisected] 4.5rc4 sound fsl-soc

. Thanks, Mika On 20.02.2016 22:45, Fabio Estevam wrote: > Hi Mika, > > Did it work for you? > > If so, please ask in the mailing list for Mark Brown to apply that patch. > > Thanks > > ____ > From: Mika Penttilä > Sent: M

[REGRESSION, bisected] 4.5rc4 sound fsl-soc

Hi, The following commit : 5c408fee254633a5be69505bc86c6b034f871ab4 is the first bad commit commit 5c408fee254633a5be69505bc86c6b034f871ab4 Author: Maciej S. Szmigiero Date: Mon Jan 18 20:07:44 2016 +0100 ASoC: fsl_ssi: remove explicit register defaults

[REGRESSION, bisected] 4.5rc4 sound fsl-soc

Hi, The following commit : 5c408fee254633a5be69505bc86c6b034f871ab4 is the first bad commit commit 5c408fee254633a5be69505bc86c6b034f871ab4 Author: Maciej S. Szmigiero Date: Mon Jan 18 20:07:44 2016 +0100 ASoC: fsl_ssi: remove explicit register defaults There is no guarantee

Re: [PATCHv2 2/2] x86: SROP mitigation: implement signal cookies

Hi, On 07.02.2016 01:39, Scott Bauer wrote: > This patch adds SROP mitigation logic to the x86 signal delivery > and sigreturn code. The cookie is placed in the unused alignment > space above the saved FP state, if it exists. If there is no FP > state to save then the cookie is placed in the

Re: [PATCHv2 2/2] x86: SROP mitigation: implement signal cookies

Hi, On 07.02.2016 01:39, Scott Bauer wrote: > This patch adds SROP mitigation logic to the x86 signal delivery > and sigreturn code. The cookie is placed in the unused alignment > space above the saved FP state, if it exists. If there is no FP > state to save then the cookie is placed in the

Re: [PATCH v2 RESEND 1/2] arm, arm64: change_memory_common with numpages == 0 should be no-op.

Hi Will, On 26.01.2016 17:59, Will Deacon wrote: > Hi Mika, > > On Tue, Jan 26, 2016 at 04:59:52PM +0200, mika.pentt...@nextfour.com wrote: >> From: Mika Penttilä >> >> This makes the caller set_memory_xx() consistent with x86. >> >> arm64 part i

  1   2   >