Re: [PATCH v2 2/3] sched/deadline: Throttle the task when missing its deadline

Hi again, (sorry for the previous email; I replied from gmail and I did not realize I was sending it in html). On Fri, 12 May 2017 11:32:08 +0800 Xunlei Pang wrote: > dl_runtime_exceeded() only checks negative runtime, actually > when the current deadline past, we should

Re: [PATCH v2 2/3] sched/deadline: Throttle the task when missing its deadline

Hi again, (sorry for the previous email; I replied from gmail and I did not realize I was sending it in html). On Fri, 12 May 2017 11:32:08 +0800 Xunlei Pang wrote: > dl_runtime_exceeded() only checks negative runtime, actually > when the current deadline past, we should start a new period >

[RESEND PATCH] mm: Don't reinvent the wheel but use existing llist API

Although llist provides proper APIs, they are not used. Make them used. Signed-off-by: Byungchul Park --- mm/vmalloc.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 3ca82d4..8c0eb45 100644 ---

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Thu, 11 May 2017 22:34:31 -0700 Kees Cook wrote: > On Thu, May 11, 2017 at 10:28 PM, Martin Schwidefsky > wrote: > > On Thu, 11 May 2017 16:44:07 -0700 > > Linus Torvalds wrote: > > > >> On Thu, May 11, 2017 at

[RESEND PATCH] mm: Don't reinvent the wheel but use existing llist API

Although llist provides proper APIs, they are not used. Make them used. Signed-off-by: Byungchul Park --- mm/vmalloc.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 3ca82d4..8c0eb45 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Thu, 11 May 2017 22:34:31 -0700 Kees Cook wrote: > On Thu, May 11, 2017 at 10:28 PM, Martin Schwidefsky > wrote: > > On Thu, 11 May 2017 16:44:07 -0700 > > Linus Torvalds wrote: > > > >> On Thu, May 11, 2017 at 4:17 PM, Thomas Garnier > >> wrote: > >> > > >> > Ingo: Do you want the

[PATCH] parisc: fix spelling mistake: "page_tye" -> "page_type"

From: Colin Ian King Trivial fix to spelling mistake in a pr_warn message. Signed-off-by: Colin Ian King --- arch/parisc/kernel/pdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/parisc/kernel/pdt.c

[PATCH v4 4/5] sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()

It would be better to avoid pushing tasks to other cpu within a SD_PREFER_SIBLING domain, instead, get more chances to check other siblings. Signed-off-by: Byungchul Park --- kernel/sched/deadline.c | 17 + 1 file changed, 17 insertions(+) diff --git

[PATCH] parisc: fix spelling mistake: "page_tye" -> "page_type"

From: Colin Ian King Trivial fix to spelling mistake in a pr_warn message. Signed-off-by: Colin Ian King --- arch/parisc/kernel/pdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/parisc/kernel/pdt.c b/arch/parisc/kernel/pdt.c index 261e134ee7f8..6362614c5160 100644

[PATCH v4 4/5] sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()

It would be better to avoid pushing tasks to other cpu within a SD_PREFER_SIBLING domain, instead, get more chances to check other siblings. Signed-off-by: Byungchul Park --- kernel/sched/deadline.c | 17 + 1 file changed, 17 insertions(+) diff --git a/kernel/sched/deadline.c

[PATCH v4 5/5] sched/rt: Add support for SD_PREFER_SIBLING on find_lowest_rq()

It would be better to avoid pushing tasks to other cpu within a SD_PREFER_SIBLING domain, instead, get more chances to check other siblings. Signed-off-by: Byungchul Park --- kernel/sched/rt.c | 17 + 1 file changed, 17 insertions(+) diff --git

[PATCH v4 3/5] sched/deadline: Change return value of cpudl_find()

Currently cpudl_find() returns the best cpu that means it has the maximum dl, however, the value is already kept in later_mask and the return value is not referred directly any more. Now, it's enough to return whether CPUs were found or not, like rt. Signed-off-by: Byungchul Park

[PATCH v4 5/5] sched/rt: Add support for SD_PREFER_SIBLING on find_lowest_rq()

It would be better to avoid pushing tasks to other cpu within a SD_PREFER_SIBLING domain, instead, get more chances to check other siblings. Signed-off-by: Byungchul Park --- kernel/sched/rt.c | 17 + 1 file changed, 17 insertions(+) diff --git a/kernel/sched/rt.c

[PATCH v4 3/5] sched/deadline: Change return value of cpudl_find()

Currently cpudl_find() returns the best cpu that means it has the maximum dl, however, the value is already kept in later_mask and the return value is not referred directly any more. Now, it's enough to return whether CPUs were found or not, like rt. Signed-off-by: Byungchul Park ---

[PATCH v4 1/5] sched/deadline: Refer to cpudl.elements atomically

cpudl.elements is an instance that should be protected with a spin lock. Without it, the code would be insane. Current cpudl_find() has problems like, 1. cpudl.elements[0].cpu might not match with cpudl.elements[0].dl. 2. cpudl.elements[0].dl(u64) might not be referred atomically. 3.

[PATCH v4 1/5] sched/deadline: Refer to cpudl.elements atomically

cpudl.elements is an instance that should be protected with a spin lock. Without it, the code would be insane. Current cpudl_find() has problems like, 1. cpudl.elements[0].cpu might not match with cpudl.elements[0].dl. 2. cpudl.elements[0].dl(u64) might not be referred atomically. 3.

[PATCH v4 0/5] Make find_later_rq() choose a closer cpu in topology

Change from v3 -. rename closest_cpu to best_cpu so that it align with rt -. protect referring cpudl.elements with cpudl.lock -. change return value of cpudl_find() to bool Change from v2 -. add support for SD_PREFER_SIBLING Change from v1 -. clean up the patch When cpudl_find()

[PATCH v4 0/5] Make find_later_rq() choose a closer cpu in topology

Change from v3 -. rename closest_cpu to best_cpu so that it align with rt -. protect referring cpudl.elements with cpudl.lock -. change return value of cpudl_find() to bool Change from v2 -. add support for SD_PREFER_SIBLING Change from v1 -. clean up the patch When cpudl_find()

[PATCH v4 2/5] sched/deadline: Make find_later_rq() choose a closer cpu in topology

When cpudl_find() returns any among free_cpus, the cpu might not be closer than others, considering sched domain. For example: this_cpu: 15 free_cpus: 0, 1,..., 14 (== later_mask) best_cpu: 0 topology: 0 --+ +--+ 1 --+ | +-- ... --+ 2 --+ | |

[PATCH v4 2/5] sched/deadline: Make find_later_rq() choose a closer cpu in topology

When cpudl_find() returns any among free_cpus, the cpu might not be closer than others, considering sched domain. For example: this_cpu: 15 free_cpus: 0, 1,..., 14 (== later_mask) best_cpu: 0 topology: 0 --+ +--+ 1 --+ | +-- ... --+ 2 --+ | |

Re: [greybus-dev] [PATCH] staging: greybus: power_supply: replace kzalloc by kcalloc

On 11-05-17, 22:58, JB Van Puyvelde wrote: > According to checkpatch.pl, kcalloc should be preferred to kzalloc with > multiply. > > Signed-off-by: JB Van Puyvelde > --- > drivers/staging/greybus/power_supply.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [greybus-dev] [PATCH] staging: greybus: power_supply: replace kzalloc by kcalloc

On 11-05-17, 22:58, JB Van Puyvelde wrote: > According to checkpatch.pl, kcalloc should be preferred to kzalloc with > multiply. > > Signed-off-by: JB Van Puyvelde > --- > drivers/staging/greybus/power_supply.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) You should have kept my Ack

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Thu, May 11, 2017 at 10:28 PM, Martin Schwidefsky wrote: > On Thu, 11 May 2017 16:44:07 -0700 > Linus Torvalds wrote: > >> On Thu, May 11, 2017 at 4:17 PM, Thomas Garnier wrote: >> > >> > Ingo: Do you want the change

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Thu, May 11, 2017 at 10:28 PM, Martin Schwidefsky wrote: > On Thu, 11 May 2017 16:44:07 -0700 > Linus Torvalds wrote: > >> On Thu, May 11, 2017 at 4:17 PM, Thomas Garnier wrote: >> > >> > Ingo: Do you want the change as-is? Would you like it to be optional? >> > What do you think? >> >> I'm

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Thu, 11 May 2017 16:44:07 -0700 Linus Torvalds wrote: > On Thu, May 11, 2017 at 4:17 PM, Thomas Garnier wrote: > > > > Ingo: Do you want the change as-is? Would you like it to be optional? > > What do you think? > > I'm not ingo, but I

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Thu, 11 May 2017 16:44:07 -0700 Linus Torvalds wrote: > On Thu, May 11, 2017 at 4:17 PM, Thomas Garnier wrote: > > > > Ingo: Do you want the change as-is? Would you like it to be optional? > > What do you think? > > I'm not ingo, but I don't like that patch. It's in the wrong place - >

Re: [PATCH 1/2] KVM: nVMX: fix EPT permissions as reported in exit qualification

On 05/12/2017 11:59 AM, Xiao Guangrong wrote: error: @@ -452,7 +459,7 @@ static int FNAME(walk_addr_generic)(struct guest_walker *walker, */ if (!(errcode & PFERR_RSVD_MASK)) { vcpu->arch.exit_qualification &= 0x187; -vcpu->arch.exit_qualification |= ((pt_access

Re: [PATCH 1/2] KVM: nVMX: fix EPT permissions as reported in exit qualification

On 05/12/2017 11:59 AM, Xiao Guangrong wrote: error: @@ -452,7 +459,7 @@ static int FNAME(walk_addr_generic)(struct guest_walker *walker, */ if (!(errcode & PFERR_RSVD_MASK)) { vcpu->arch.exit_qualification &= 0x187; -vcpu->arch.exit_qualification |= ((pt_access

[PATCH] net: netfilter: netlink: delete extra spaces

This patch cleans up extra spaces. Signed-off-by: linzhang --- net/netfilter/nf_conntrack_netlink.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c index dcf561b..356e6f0

[PATCH] net: netfilter: netlink: delete extra spaces

This patch cleans up extra spaces. Signed-off-by: linzhang --- net/netfilter/nf_conntrack_netlink.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c index dcf561b..356e6f0 100644 ---

RE: [PATCH 1/2] Revert "ACPI / button: Remove lid_init_state=method mode"

Hi, > From: linux-acpi-ow...@vger.kernel.org > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Benjamin > Tissoires > Subject: Re: [PATCH 1/2] Revert "ACPI / button: Remove lid_init_state=method > mode" > > On May 11 2017 or thereabouts, Zheng, Lv wrote: > > Hi, Benjamin > > > > >

RE: [PATCH 1/2] Revert "ACPI / button: Remove lid_init_state=method mode"

Hi, > From: linux-acpi-ow...@vger.kernel.org > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Benjamin > Tissoires > Subject: Re: [PATCH 1/2] Revert "ACPI / button: Remove lid_init_state=method > mode" > > On May 11 2017 or thereabouts, Zheng, Lv wrote: > > Hi, Benjamin > > > > >

Re: [PATCH v4 2/3] KASLR: Handle memory limit specified by memmap and mem option

On 05/12/17 at 01:15pm, Masayoshi Mizuma wrote: > Hi Baoquan, > > Thank you for fixing! > I confirmed that the kernel is located within mem= address. > > Tested-by: Masayoshi Mizuma Thanks for your testing! I will post v5 according to comments from Thomas and Kees.

Re: [PATCH v4 2/3] KASLR: Handle memory limit specified by memmap and mem option

On 05/12/17 at 01:15pm, Masayoshi Mizuma wrote: > Hi Baoquan, > > Thank you for fixing! > I confirmed that the kernel is located within mem= address. > > Tested-by: Masayoshi Mizuma Thanks for your testing! I will post v5 according to comments from Thomas and Kees. Since no functionality code

Re: [PATCH 1/2] alpha-module: Improve a size determination in module_frob_arch_sections()

On Thu, May 11, 2017 at 01:54:42PM +0200, SF Markus Elfring wrote: > From: Markus Elfring > Date: Thu, 11 May 2017 12:54:29 +0200 > > Replace the specification of a data structure by a pointer dereference > as the parameter for the operator "sizeof" to make the

Re: [PATCH 1/2] alpha-module: Improve a size determination in module_frob_arch_sections()

On Thu, May 11, 2017 at 01:54:42PM +0200, SF Markus Elfring wrote: > From: Markus Elfring > Date: Thu, 11 May 2017 12:54:29 +0200 > > Replace the specification of a data structure by a pointer dereference > as the parameter for the operator "sizeof" to make the corresponding size > determination

Re: Lockdep splat involving all_q_mutex

On Thu, May 11, 2017 at 01:23:44PM -0700, Paul E. McKenney wrote: > On Thu, May 11, 2017 at 02:12:39PM -0600, Jens Axboe wrote: > > On 05/10/2017 09:13 PM, Paul E. McKenney wrote: > > > On Wed, May 10, 2017 at 08:55:54PM -0600, Jens Axboe wrote: > > >> On 05/10/2017 04:34 PM, Paul E. McKenney

Re: Lockdep splat involving all_q_mutex

On Thu, May 11, 2017 at 01:23:44PM -0700, Paul E. McKenney wrote: > On Thu, May 11, 2017 at 02:12:39PM -0600, Jens Axboe wrote: > > On 05/10/2017 09:13 PM, Paul E. McKenney wrote: > > > On Wed, May 10, 2017 at 08:55:54PM -0600, Jens Axboe wrote: > > >> On 05/10/2017 04:34 PM, Paul E. McKenney

Re: [Intel-gfx] GPU hang with kernel 4.10rc3

On 11/05/17 23:08, Pavel Machek wrote: > On Mon 2017-01-23 10:39:27, Juergen Gross wrote: >> On 13/01/17 15:41, Juergen Gross wrote: >>> On 12/01/17 10:21, Chris Wilson wrote: On Thu, Jan 12, 2017 at 07:03:25AM +0100, Juergen Gross wrote: > On 11/01/17 18:08, Chris Wilson wrote: >> On

Re: [Intel-gfx] GPU hang with kernel 4.10rc3

On 11/05/17 23:08, Pavel Machek wrote: > On Mon 2017-01-23 10:39:27, Juergen Gross wrote: >> On 13/01/17 15:41, Juergen Gross wrote: >>> On 12/01/17 10:21, Chris Wilson wrote: On Thu, Jan 12, 2017 at 07:03:25AM +0100, Juergen Gross wrote: > On 11/01/17 18:08, Chris Wilson wrote: >> On

RE: [PATCH] PCI: Make SR-IOV capable GPU working on the SR-IOV incapable platform

Hi Williamson, I verified the patch is working for both AMD SR-IOV GPU and Intel SR-IOV NIC. I don't think it is redundant to check the VF BAR valid before call sriov_init(), it is safe and saving boot time, also there is no a better method to know if system BIOS has correctly initialized the

RE: [PATCH] PCI: Make SR-IOV capable GPU working on the SR-IOV incapable platform

Hi Williamson, I verified the patch is working for both AMD SR-IOV GPU and Intel SR-IOV NIC. I don't think it is redundant to check the VF BAR valid before call sriov_init(), it is safe and saving boot time, also there is no a better method to know if system BIOS has correctly initialized the

Re: [PATCH] ARM: remove duplicate 'const' annotations'

Arnd Bergmann writes: > gcc-7 warns about some declarations that are more 'const' than necessary: > --- a/arch/arm/mach-cns3xxx/core.c > +++ b/arch/arm/mach-cns3xxx/core.c > @@ -346,7 +346,7 @@ static struct usb_ohci_pdata cns3xxx_usb_ohci_pdata = { > .power_off =

Re: [PATCH] ARM: remove duplicate 'const' annotations'

Arnd Bergmann writes: > gcc-7 warns about some declarations that are more 'const' than necessary: > --- a/arch/arm/mach-cns3xxx/core.c > +++ b/arch/arm/mach-cns3xxx/core.c > @@ -346,7 +346,7 @@ static struct usb_ohci_pdata cns3xxx_usb_ohci_pdata = { > .power_off =

Re: [PATCH v8 02/10] powerpc/powernv: Autoload IMC device driver module

On Thursday 11 May 2017 01:19 PM, Stewart Smith wrote: Anju T Sudhakar writes: This patch does three things : - Enables "opal.c" to create a platform device for the IMC interface according to the appropriate compatibility string. - Find the reserved-memory

Re: [PATCH v8 02/10] powerpc/powernv: Autoload IMC device driver module

On Thursday 11 May 2017 01:19 PM, Stewart Smith wrote: Anju T Sudhakar writes: This patch does three things : - Enables "opal.c" to create a platform device for the IMC interface according to the appropriate compatibility string. - Find the reserved-memory region details from the

Re: [PATCH v4 2/3] KASLR: Handle memory limit specified by memmap and mem option

Hi Baoquan, Thank you for fixing! I confirmed that the kernel is located within mem= address. Tested-by: Masayoshi Mizuma Regards, Masayoshi Mizuma On Tue, 9 May 2017 13:57:51 +0800 Baoquan He wrote: > Option mem= will limit the max address a system can use and any

Re: [PATCH v4 2/3] KASLR: Handle memory limit specified by memmap and mem option

Hi Baoquan, Thank you for fixing! I confirmed that the kernel is located within mem= address. Tested-by: Masayoshi Mizuma Regards, Masayoshi Mizuma On Tue, 9 May 2017 13:57:51 +0800 Baoquan He wrote: > Option mem= will limit the max address a system can use and any memory > region above the

Re: [PATCH] ARM: remove duplicate 'const' annotations'

On 11-05-17, 13:50, Arnd Bergmann wrote: > gcc-7 warns about some declarations that are more 'const' than necessary: > > arch/arm/mach-at91/pm.c:338:34: error: duplicate 'const' declaration > specifier [-Werror=duplicate-decl-specifier] > static const struct of_device_id const ramc_ids[]

Re: [PATCH] ARM: remove duplicate 'const' annotations'

On 11-05-17, 13:50, Arnd Bergmann wrote: > gcc-7 warns about some declarations that are more 'const' than necessary: > > arch/arm/mach-at91/pm.c:338:34: error: duplicate 'const' declaration > specifier [-Werror=duplicate-decl-specifier] > static const struct of_device_id const ramc_ids[]

[PATCH 2/3] EDAC: mv64x60: Fix pdata->name

Change this from mpc85xx_pci_err to mv64x60_pci_err. The former is likely a hangover from when this driver was created. Signed-off-by: Chris Packham --- drivers/edac/mv64x60_edac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 2/3] EDAC: mv64x60: Fix pdata->name

Change this from mpc85xx_pci_err to mv64x60_pci_err. The former is likely a hangover from when this driver was created. Signed-off-by: Chris Packham --- drivers/edac/mv64x60_edac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/edac/mv64x60_edac.c

[PATCH 3/3] EDAC: mv64x60: replace in_le32/out_le32 with ioread32/iowrite32

To allow this driver to be used on non-powerpc platforms it needs to use io accessors suitable for all platforms. Signed-off-by: Chris Packham --- drivers/edac/mv64x60_edac.c | 84 ++--- 1 file changed, 42 insertions(+),

[PATCH 1/3] EDAC: mv64x60: remove unused variable

Signed-off-by: Chris Packham --- drivers/edac/mv64x60_edac.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/edac/mv64x60_edac.c b/drivers/edac/mv64x60_edac.c index 14b7e7b71eaa..454e1e26ee7c 100644 --- a/drivers/edac/mv64x60_edac.c +++

[PATCH 3/3] EDAC: mv64x60: replace in_le32/out_le32 with ioread32/iowrite32

To allow this driver to be used on non-powerpc platforms it needs to use io accessors suitable for all platforms. Signed-off-by: Chris Packham --- drivers/edac/mv64x60_edac.c | 84 ++--- 1 file changed, 42 insertions(+), 42 deletions(-) diff --git

[PATCH 1/3] EDAC: mv64x60: remove unused variable

Signed-off-by: Chris Packham --- drivers/edac/mv64x60_edac.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/edac/mv64x60_edac.c b/drivers/edac/mv64x60_edac.c index 14b7e7b71eaa..454e1e26ee7c 100644 --- a/drivers/edac/mv64x60_edac.c +++ b/drivers/edac/mv64x60_edac.c @@ -853,8 +853,6

[ANNOUNCE] linux-4.11-ck1 / MuQSS CPU scheduler 0.155

These are patches designed to improve system responsiveness and interactivity with specific emphasis on the desktop, but configurable for any workload. The patchset is mainly centred around the Multiple Queue Skiplist Scheduler, MuQSS. linux-4.11-ck1 -ck1 patches:

[ANNOUNCE] linux-4.11-ck1 / MuQSS CPU scheduler 0.155

These are patches designed to improve system responsiveness and interactivity with specific emphasis on the desktop, but configurable for any workload. The patchset is mainly centred around the Multiple Queue Skiplist Scheduler, MuQSS. linux-4.11-ck1 -ck1 patches:

[PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

It seems like RSTe is much more conservative with transition timing that we are. According to Mario, RSTe programs APST to transition from active states to the first idle state after 60ms and, thereafter, to 1000 * the exit latency of the target state. This is IMO a terrible policy. On my

[PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

It seems like RSTe is much more conservative with transition timing that we are. According to Mario, RSTe programs APST to transition from active states to the first idle state after 60ms and, thereafter, to 1000 * the exit latency of the target state. This is IMO a terrible policy. On my

[PATCH v2 2/3] irqchip/mbigen: Fix potential NULL dereferencing

From: Hanjun Guo platform_get_resource() may return NULL, add proper check to avoid potential NULL dereferencing. Signed-off-by: Hanjun Guo --- drivers/irqchip/irq-mbigen.c | 3 +++ 1 file changed, 3 insertions(+) diff --git

[PATCH v2 3/3] irqchip/mbigen: Fix the clear register offset

From: MaJun Don't minus reserved interrupts (64) when get the clear register offset, because the clear register space includes the space of these 64 interrupts. This bug wasn't discovered until we running the driver on a new platform with an updated firmware. It turns out

[PATCH v2 1/3] irqchip/mbigen: Fix memory mapping code

From: Hanjun Guo Some mbigens share memory regions, and devm_ioremap_resource does not allow to share resources which will break the probe of mbigen, in opposition to devm_ioremap. This patch restores back usage of devm_ioremap function, but with proper error handling and

Re: [PATCH] PCI: Make SR-IOV capable GPU working on the SR-IOV incapable platform

On Fri, 12 May 2017 03:42:46 + "Cheng, Collins" wrote: > Hi Williamson, > > GPU card needs more BAR aperture resource than other PCI devices. For > example, Intel SR-IOV network card only require 512KB memory resource for all > VFs. AMD SR-IOV GPU card needs 256MB

[PATCH v2 2/3] irqchip/mbigen: Fix potential NULL dereferencing

From: Hanjun Guo platform_get_resource() may return NULL, add proper check to avoid potential NULL dereferencing. Signed-off-by: Hanjun Guo --- drivers/irqchip/irq-mbigen.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c index

[PATCH v2 3/3] irqchip/mbigen: Fix the clear register offset

From: MaJun Don't minus reserved interrupts (64) when get the clear register offset, because the clear register space includes the space of these 64 interrupts. This bug wasn't discovered until we running the driver on a new platform with an updated firmware. It turns out that there is a

[PATCH v2 1/3] irqchip/mbigen: Fix memory mapping code

From: Hanjun Guo Some mbigens share memory regions, and devm_ioremap_resource does not allow to share resources which will break the probe of mbigen, in opposition to devm_ioremap. This patch restores back usage of devm_ioremap function, but with proper error handling and logging. Fixes:

Re: [PATCH] PCI: Make SR-IOV capable GPU working on the SR-IOV incapable platform

On Fri, 12 May 2017 03:42:46 + "Cheng, Collins" wrote: > Hi Williamson, > > GPU card needs more BAR aperture resource than other PCI devices. For > example, Intel SR-IOV network card only require 512KB memory resource for all > VFs. AMD SR-IOV GPU card needs 256MB x16 VF = 4GB memory

[PATCH v2 0/3] irqchip/mbigen: bugfixs

From: Hanjun Guo Here are 3 bugfixes for mbigen: Patch 1 is a critical bugfix which to fix the mbigen probe failure, commit 216646e4d82e ("irqchip/mbigen: Fix return value check in mbigen_device_probe()") introduced this breakage; Patch 2 fixes a potential NULL

[PATCH v2 0/3] irqchip/mbigen: bugfixs

From: Hanjun Guo Here are 3 bugfixes for mbigen: Patch 1 is a critical bugfix which to fix the mbigen probe failure, commit 216646e4d82e ("irqchip/mbigen: Fix return value check in mbigen_device_probe()") introduced this breakage; Patch 2 fixes a potential NULL dereferencing; Patch 3 fixes a

Re: [PATCH 1/2] KVM: nVMX: fix EPT permissions as reported in exit qualification

On 05/11/2017 07:23 PM, Paolo Bonzini wrote: This fixes the new ept_access_test_read_only and ept_access_test_read_write testcases from vmx.flat. The problem is that gpte_access moves bits around to switch from EPT bit order (XWR) to ACC_*_MASK bit order (RWX). This results in an incorrect

Re: [PATCH 1/2] KVM: nVMX: fix EPT permissions as reported in exit qualification

On 05/11/2017 07:23 PM, Paolo Bonzini wrote: This fixes the new ept_access_test_read_only and ept_access_test_read_write testcases from vmx.flat. The problem is that gpte_access moves bits around to switch from EPT bit order (XWR) to ACC_*_MASK bit order (RWX). This results in an incorrect

[PATCH] powerpc: Tweak copy selection parameter in __copy_tofrom_user_power7()

Experiments with the netperf benchmark indicated that the size selecting VMX-based copies in __copy_tofrom_user_power7() was suboptimal on POWER8. Measurements showed that parity was in the neighbourhood of 3328 bytes, rather than greater than 4096. The change gives a 1.5-2.0% improvement in

[PATCH] powerpc: Tweak copy selection parameter in __copy_tofrom_user_power7()

Experiments with the netperf benchmark indicated that the size selecting VMX-based copies in __copy_tofrom_user_power7() was suboptimal on POWER8. Measurements showed that parity was in the neighbourhood of 3328 bytes, rather than greater than 4096. The change gives a 1.5-2.0% improvement in

Re: [PATCH 4/4] staging: rtl8723bs: checkpatch - resolve indentation and line width

Hi Matthew, [auto build test WARNING on staging/staging-testing] [also build test WARNING on next-20170511] [cannot apply to v4.11] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Matthew-Giassa

Re: [PATCH 4/4] staging: rtl8723bs: checkpatch - resolve indentation and line width

Hi Matthew, [auto build test WARNING on staging/staging-testing] [also build test WARNING on next-20170511] [cannot apply to v4.11] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Matthew-Giassa

RE: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

>-Original Message- >From: Alex Williamson [mailto:alex.william...@redhat.com] >Sent: Friday, May 12, 2017 10:58 AM >To: Chen, Xiaoguang >Cc: Gerd Hoffmann ; Tian, Kevin ; >intel-...@lists.freedesktop.org;

RE: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

>-Original Message- >From: Alex Williamson [mailto:alex.william...@redhat.com] >Sent: Friday, May 12, 2017 10:58 AM >To: Chen, Xiaoguang >Cc: Gerd Hoffmann ; Tian, Kevin ; >intel-...@lists.freedesktop.org; linux-kernel@vger.kernel.org; >zhen...@linux.intel.com; Lv, Zhiyuan ; intel-gvt-

Re: [PATCH v8 05/10] powerpc/perf: IMC pmu cpumask and cpuhotplug support

On Friday 12 May 2017 09:03 AM, Michael Ellerman wrote: Stewart Smith writes: Madhavan Srinivasan writes: * in patch 9 should opal_imc_counters_init return something other than OPAL_SUCCESS in the case on invalid

Re: [PATCH v8 05/10] powerpc/perf: IMC pmu cpumask and cpuhotplug support

On Friday 12 May 2017 09:03 AM, Michael Ellerman wrote: Stewart Smith writes: Madhavan Srinivasan writes: * in patch 9 should opal_imc_counters_init return something other than OPAL_SUCCESS in the case on invalid arguments? Maybe OPAL_PARAMETER? (I think you fix this

Re: [PATCH] soc: imx: add PM dependency for IMX7_PM_DOMAINS

On Thu, May 11, 2017 at 01:37:47PM +0200, Arnd Bergmann wrote: > The new pm domain driver causes a build failure when CONFIG_PM > is not set: > > warning: (IMX7_PM_DOMAINS) selects PM_GENERIC_DOMAINS which has unmet direct > dependencies (PM) > drivers/base/power/domain_governor.c: In function

Re: [PATCH] soc: imx: add PM dependency for IMX7_PM_DOMAINS

On Thu, May 11, 2017 at 01:37:47PM +0200, Arnd Bergmann wrote: > The new pm domain driver causes a build failure when CONFIG_PM > is not set: > > warning: (IMX7_PM_DOMAINS) selects PM_GENERIC_DOMAINS which has unmet direct > dependencies (PM) > drivers/base/power/domain_governor.c: In function

Re: Threads stuck in zap_pid_ns_processes()

Guenter Roeck writes: > On Thu, May 11, 2017 at 04:25:23PM -0500, Eric W. Biederman wrote: >> Guenter Roeck writes: >> > As an add-on to my previous mail: I added a function to count >> > the number of threads in the pid namespace, using next_pidmap().

Re: Threads stuck in zap_pid_ns_processes()

Guenter Roeck writes: > On Thu, May 11, 2017 at 04:25:23PM -0500, Eric W. Biederman wrote: >> Guenter Roeck writes: >> > As an add-on to my previous mail: I added a function to count >> > the number of threads in the pid namespace, using next_pidmap(). >> > Even though nr_hashed == 2, only the

RE: [PATCH] PCI: Make SR-IOV capable GPU working on the SR-IOV incapable platform

>-Original Message- >From: Alex Williamson [mailto:alex.william...@redhat.com] >Sent: Thursday, May 11, 2017 11:21 PM >To: Cheng, Collins >Cc: Bjorn Helgaas; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; >Deucher, Alexander; Zytaruk, Kelly >Subject: Re: [PATCH] PCI: Make

RE: [PATCH] PCI: Make SR-IOV capable GPU working on the SR-IOV incapable platform

>-Original Message- >From: Alex Williamson [mailto:alex.william...@redhat.com] >Sent: Thursday, May 11, 2017 11:21 PM >To: Cheng, Collins >Cc: Bjorn Helgaas; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; >Deucher, Alexander; Zytaruk, Kelly >Subject: Re: [PATCH] PCI: Make

RE: [PATCH] PCI: Make SR-IOV capable GPU working on the SR-IOV incapable platform

Hi Williamson, GPU card needs more BAR aperture resource than other PCI devices. For example, Intel SR-IOV network card only require 512KB memory resource for all VFs. AMD SR-IOV GPU card needs 256MB x16 VF = 4GB memory resource for frame buffer BAR aperture. If the system BIOS supports

Re: [PATCH v8 05/10] powerpc/perf: IMC pmu cpumask and cpuhotplug support

On Friday 12 May 2017 07:48 AM, Stewart Smith wrote: Madhavan Srinivasan writes: * in patch 9 should opal_imc_counters_init return something other than OPAL_SUCCESS in the case on invalid arguments? Maybe OPAL_PARAMETER? (I think you fix this

RE: [PATCH] PCI: Make SR-IOV capable GPU working on the SR-IOV incapable platform

Hi Williamson, GPU card needs more BAR aperture resource than other PCI devices. For example, Intel SR-IOV network card only require 512KB memory resource for all VFs. AMD SR-IOV GPU card needs 256MB x16 VF = 4GB memory resource for frame buffer BAR aperture. If the system BIOS supports

Re: [PATCH v8 05/10] powerpc/perf: IMC pmu cpumask and cpuhotplug support

On Friday 12 May 2017 07:48 AM, Stewart Smith wrote: Madhavan Srinivasan writes: * in patch 9 should opal_imc_counters_init return something other than OPAL_SUCCESS in the case on invalid arguments? Maybe OPAL_PARAMETER? (I think you fix this in a later patch anyway?)

Re: [RFC 04/10] x86/mm: Pass flush_tlb_info to flush_tlb_others() etc

On Thu, May 11, 2017 at 1:01 PM, Nadav Amit wrote: > >> On May 7, 2017, at 5:38 AM, Andy Lutomirski wrote: >> >> @@ -243,15 +237,15 @@ static void flush_tlb_func(void *info) >> return; >> } >> >> - if (f->flush_end == TLB_FLUSH_ALL)

Re: [RFC 04/10] x86/mm: Pass flush_tlb_info to flush_tlb_others() etc

On Thu, May 11, 2017 at 1:01 PM, Nadav Amit wrote: > >> On May 7, 2017, at 5:38 AM, Andy Lutomirski wrote: >> >> @@ -243,15 +237,15 @@ static void flush_tlb_func(void *info) >> return; >> } >> >> - if (f->flush_end == TLB_FLUSH_ALL) { >> + if (f->end == TLB_FLUSH_ALL)

Re: [RFC 09/10] x86/mm: Rework lazy TLB to track the actual loaded mm

On Thu, May 11, 2017 at 12:13 AM, Ingo Molnar wrote: > My personal favorite is double underscores prefix, i.e. 'void *__mm', which > would > clearly signal that this is something special. But this does not appear to > have > been picked up overly widely: Nice bikeshed! I'll

Re: [RFC 09/10] x86/mm: Rework lazy TLB to track the actual loaded mm

On Thu, May 11, 2017 at 12:13 AM, Ingo Molnar wrote: > My personal favorite is double underscores prefix, i.e. 'void *__mm', which > would > clearly signal that this is something special. But this does not appear to > have > been picked up overly widely: Nice bikeshed! I'll use it.

Re: [RFC 01/10] x86/mm: Reimplement flush_tlb_page() using flush_tlb_mm_range()

On Thu, May 11, 2017 at 10:41 AM, Borislav Petkov wrote: >> +{ >> + flush_tlb_mm_range(vma->vm_mm, a, a + PAGE_SIZE, 0); > > VM_NONE); > Fixed, although this won't have any effect. --Andy

Re: [RFC 01/10] x86/mm: Reimplement flush_tlb_page() using flush_tlb_mm_range()

On Thu, May 11, 2017 at 10:41 AM, Borislav Petkov wrote: >> +{ >> + flush_tlb_mm_range(vma->vm_mm, a, a + PAGE_SIZE, 0); > > VM_NONE); > Fixed, although this won't have any effect. --Andy

Re: [PATCH] sched/deadline: Zero out positive runtime after throttling constrained tasks

On 05/11/2017 at 09:38 AM, Xunlei Pang wrote: > On 05/10/2017 at 09:36 PM, Steven Rostedt wrote: >> On Wed, 10 May 2017 21:03:37 +0800 >> Xunlei Pang wrote: >> >>> When a contrained task is throttled by dl_check_constrained_dl(), >>> it may carry the remaining positive runtime,

Re: [PATCH] sched/deadline: Zero out positive runtime after throttling constrained tasks

On 05/11/2017 at 09:38 AM, Xunlei Pang wrote: > On 05/10/2017 at 09:36 PM, Steven Rostedt wrote: >> On Wed, 10 May 2017 21:03:37 +0800 >> Xunlei Pang wrote: >> >>> When a contrained task is throttled by dl_check_constrained_dl(), >>> it may carry the remaining positive runtime, as a result when

Re: [PATCH 3/3] f2fs: introduce io_list for serialize data/node IOs

Hi Jaegeuk, On 2017/5/12 2:36, Jaegeuk Kim wrote: > Hi Chao, > > On 05/09, Chao Yu wrote: >> From: Chao Yu >> >> Serialize data/node IOs by using fifo list instead of mutex lock, >> it will help to enhance concurrency of f2fs, meanwhile keeping LFS >> IO semantics. > > I'm

Re: [PATCH 3/3] f2fs: introduce io_list for serialize data/node IOs

Hi Jaegeuk, On 2017/5/12 2:36, Jaegeuk Kim wrote: > Hi Chao, > > On 05/09, Chao Yu wrote: >> From: Chao Yu >> >> Serialize data/node IOs by using fifo list instead of mutex lock, >> it will help to enhance concurrency of f2fs, meanwhile keeping LFS >> IO semantics. > > I'm not against to give

  1   2   3   4   5   6   7   8   9   10   >