[PATCH v2 1/1] dmaengine: slave means at least one of DMA_SLAVE, DMA_CYCLIC

When check for capabilities recognize slave support by either DMA_SLAVE or DMA_CYCLIC bit set. If we don't do that the user can't get a normally worked DMA support for engines that doesn't have one of the mentioned bits set. Signed-off-by: Andy Shevchenko ---

[PATCH v2 1/1] dmaengine: slave means at least one of DMA_SLAVE, DMA_CYCLIC

When check for capabilities recognize slave support by either DMA_SLAVE or DMA_CYCLIC bit set. If we don't do that the user can't get a normally worked DMA support for engines that doesn't have one of the mentioned bits set. Signed-off-by: Andy Shevchenko --- In v2: - fix typo in the commit

[PATCH v2 1/1] skd_main: use %*ph to dump small buffers

Replace custom approach by %*ph specifier to dump small buffers in hex format. Unfortunately we can't use print_hex_dump_bytes() here since tha gap is present, though one familiar with the code may change this. Signed-off-by: Andy Shevchenko --- In v2: - use

[PATCH v2 1/1] skd_main: use %*ph to dump small buffers

Replace custom approach by %*ph specifier to dump small buffers in hex format. Unfortunately we can't use print_hex_dump_bytes() here since tha gap is present, though one familiar with the code may change this. Signed-off-by: Andy Shevchenko --- In v2: - use pointers instead of direct values -

Re: [PATCH 0/3] clk: bcm2835: critical clocks and parent selection

Martin Sperl writes: > On 10.05.2016 03:01, Eric Anholt wrote: >> With the new patch 2 inserted between my previous pair, I think this >> should cover Martin's bugs with clock disabling. >> >> I tested patch 2 to be important on the downstream kernel: with the >> DPI

Re: [PATCH 0/3] clk: bcm2835: critical clocks and parent selection

Martin Sperl writes: > On 10.05.2016 03:01, Eric Anholt wrote: >> With the new patch 2 inserted between my previous pair, I think this >> should cover Martin's bugs with clock disabling. >> >> I tested patch 2 to be important on the downstream kernel: with the >> DPI panel support added there, I

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Mon, May 09, 2016 at 10:55:24PM +0100, Matt Fleming wrote: > On Mon, 02 May, at 04:39:31PM, Alex Thorlton wrote: > > > > If you think we're violating EFI rules by accessing these registers from > > both sides of the fence, please let me know. I'd like to make sure that > > we get everything

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Mon, May 09, 2016 at 10:55:24PM +0100, Matt Fleming wrote: > On Mon, 02 May, at 04:39:31PM, Alex Thorlton wrote: > > > > If you think we're violating EFI rules by accessing these registers from > > both sides of the fence, please let me know. I'd like to make sure that > > we get everything

Re: [PATCH v5 02/13] x86/xsaves: Rename xstate_size to kernel_xstate_size to explicitly distinguish xstate size in kernel from user space

On 05/10/2016 10:26 AM, Borislav Petkov wrote: >> > It's nice to dump out interesting data in dmesg, but I'm curious why you >> > think it's interesting. > I think it would be interesting to know what the kernel's idea > is of user_xstate_size. I know, I know, one can follow the code > and figure

Re: [PATCH v5 02/13] x86/xsaves: Rename xstate_size to kernel_xstate_size to explicitly distinguish xstate size in kernel from user space

On 05/10/2016 10:26 AM, Borislav Petkov wrote: >> > It's nice to dump out interesting data in dmesg, but I'm curious why you >> > think it's interesting. > I think it would be interesting to know what the kernel's idea > is of user_xstate_size. I know, I know, one can follow the code > and figure

[GIT PULL] PCI fixes for v4.6

Hi Linus, Since v4.5, we've WARNed during resume if a PCI device, including a Thunderbolt device, was added while we were suspended. A change we merged for v4.6-rc1 turned that warning into a system hang. These patches from Lukas fix this issue. Bjorn The following changes since commit

[GIT PULL] PCI fixes for v4.6

Hi Linus, Since v4.5, we've WARNed during resume if a PCI device, including a Thunderbolt device, was added while we were suspended. A change we merged for v4.6-rc1 turned that warning into a system hang. These patches from Lukas fix this issue. Bjorn The following changes since commit

Re: [PATCH v5 02/13] x86/xsaves: Rename xstate_size to kernel_xstate_size to explicitly distinguish xstate size in kernel from user space

On Tue, May 10, 2016 at 10:08:44AM -0700, Dave Hansen wrote: > But the kernel never actually stores "user_xstate_size" anywhere or > really ever even cares about it except when copying in/out of userspace. Sounds like a reason enough to me. > "user_xstate_size" is also entirely enumerable in

Re: [PATCH v5 02/13] x86/xsaves: Rename xstate_size to kernel_xstate_size to explicitly distinguish xstate size in kernel from user space

On Tue, May 10, 2016 at 10:08:44AM -0700, Dave Hansen wrote: > But the kernel never actually stores "user_xstate_size" anywhere or > really ever even cares about it except when copying in/out of userspace. Sounds like a reason enough to me. > "user_xstate_size" is also entirely enumerable in

Re: Getting rid of dynamic TASK_SIZE (on x86, at least)

On Tue, May 10, 2016 at 10:05 AM, Cyrill Gorcunov wrote: > On Tue, May 10, 2016 at 09:45:34AM -0700, Andy Lutomirski wrote: >> On Tue, May 10, 2016 at 9:30 AM, Cyrill Gorcunov wrote: >> > On Tue, May 10, 2016 at 09:07:49AM -0700, Andy Lutomirski wrote: >>

Re: Getting rid of dynamic TASK_SIZE (on x86, at least)

On Tue, May 10, 2016 at 10:05 AM, Cyrill Gorcunov wrote: > On Tue, May 10, 2016 at 09:45:34AM -0700, Andy Lutomirski wrote: >> On Tue, May 10, 2016 at 9:30 AM, Cyrill Gorcunov wrote: >> > On Tue, May 10, 2016 at 09:07:49AM -0700, Andy Lutomirski wrote: >> >> Hi all- >> >> >> >> I'm trying to get

Re: [PATCH] kvm-pr: manage illegal instructions

On 09/05/2016 10:14, Thomas Huth wrote: >> > Tested-by: Thomas Huth > Ping! > > Alex, Paul, could you please pick up this patch? This patch is required > to get the kvm-unit-tests working properly with kvm-pr, so I'd be glad > if we could get this included finally... I have

Re: [PATCH] kvm-pr: manage illegal instructions

On 09/05/2016 10:14, Thomas Huth wrote: >> > Tested-by: Thomas Huth > Ping! > > Alex, Paul, could you please pick up this patch? This patch is required > to get the kvm-unit-tests working properly with kvm-pr, so I'd be glad > if we could get this included finally... I have a pull request for

Re: [PATCH 02/11] irqdomain: Warn if we fail to set the IRQ type

On 10/05/16 16:14, Jon Hunter wrote: > When setting the IRQ type we don't check the return value to see if it > is set correctly. Due to this, failures to set the IRQ type have gone > unnoticed and because these failures were not catastrophic have not had > an impact on the system. > > Ideally,

Re: [PATCH 02/11] irqdomain: Warn if we fail to set the IRQ type

On 10/05/16 16:14, Jon Hunter wrote: > When setting the IRQ type we don't check the return value to see if it > is set correctly. Due to this, failures to set the IRQ type have gone > unnoticed and because these failures were not catastrophic have not had > an impact on the system. > > Ideally,

Re: [PATCH v9 5/7] vfio/type1: also check IRQ remapping capability at msi domain

Hi Eric, On 10/05/16 17:10, Eric Auger wrote: Hi Alex, On 05/10/2016 12:49 AM, Alex Williamson wrote: On Wed, 4 May 2016 11:54:16 + Eric Auger wrote: On x86 IRQ remapping is abstracted by the IOMMU. On ARM this is abstracted by the msi controller.

Re: [PATCH v9 5/7] vfio/type1: also check IRQ remapping capability at msi domain

Hi Eric, On 10/05/16 17:10, Eric Auger wrote: Hi Alex, On 05/10/2016 12:49 AM, Alex Williamson wrote: On Wed, 4 May 2016 11:54:16 + Eric Auger wrote: On x86 IRQ remapping is abstracted by the IOMMU. On ARM this is abstracted by the msi controller. vfio_safe_irq_domain allows to check

Re: [PATCH -v2] x86/hweight: Get rid of the special calling convention

On Tue, May 10, 2016 at 06:53:18PM +0200, Borislav Petkov wrote: > static __always_inline unsigned int __arch_hweight32(unsigned int w) > { > - unsigned int res = 0; > + unsigned int res; > > - asm (ALTERNATIVE("call __sw_hweight32", POPCNT32, X86_FEATURE_POPCNT) > -

Re: [PATCH -v2] x86/hweight: Get rid of the special calling convention

On Tue, May 10, 2016 at 06:53:18PM +0200, Borislav Petkov wrote: > static __always_inline unsigned int __arch_hweight32(unsigned int w) > { > - unsigned int res = 0; > + unsigned int res; > > - asm (ALTERNATIVE("call __sw_hweight32", POPCNT32, X86_FEATURE_POPCNT) > -

[PATCH v8 0/4] x86/KASLR: Randomize virtual address separately

This is v8 of the last 3 patches from v7, with an additional clean-up for the pagetable.c code. The rest of the series has landed in -tip. The patches are: - 1: Further clean up on pagetable.c. - 2: Last part of Baoquan's decoupling the physical address and virtual address randomization of

[PATCH v8 0/4] x86/KASLR: Randomize virtual address separately

This is v8 of the last 3 patches from v7, with an additional clean-up for the pagetable.c code. The rest of the series has landed in -tip. The patches are: - 1: Further clean up on pagetable.c. - 2: Last part of Baoquan's decoupling the physical address and virtual address randomization of

[PATCH v8 2/4] x86/KASLR: Randomize virtual address separately

From: Baoquan He The current KASLR implementation randomizes the physical and virtual addresses of the kernel together (both are offset by the same amount). It calculates the delta of the physical address where vmlinux was linked to load and where it is finally loaded. If the

Re: workqueue: race in mod_delayed_work_on?

On 10.05.2016 19:36, Tejun Heo wrote: Hello, On Tue, May 10, 2016 at 07:28:08PM +0300, Konstantin Khlebnikov wrote: On 10.05.2016 11:21, Konstantin Khlebnikov wrote: I've got plenty warnings, bugs and oops around trivial use of mod_delayed_work in drivers/infiniband/core/addr.c Looks like

[PATCH v8 2/4] x86/KASLR: Randomize virtual address separately

From: Baoquan He The current KASLR implementation randomizes the physical and virtual addresses of the kernel together (both are offset by the same amount). It calculates the delta of the physical address where vmlinux was linked to load and where it is finally loaded. If the delta is not equal

Re: workqueue: race in mod_delayed_work_on?

On 10.05.2016 19:36, Tejun Heo wrote: Hello, On Tue, May 10, 2016 at 07:28:08PM +0300, Konstantin Khlebnikov wrote: On 10.05.2016 11:21, Konstantin Khlebnikov wrote: I've got plenty warnings, bugs and oops around trivial use of mod_delayed_work in drivers/infiniband/core/addr.c Looks like

[PATCH v8 4/4] x86/KASLR: Allow randomization below load address

From: Yinghai Lu Currently the physical randomization's lower boundary is the original kernel load address. For bootloaders that load kernels into very high memory (e.g. kexec), this means randomization takes place in a very small window at the top of memory, ignoring the

[PATCH v8 4/4] x86/KASLR: Allow randomization below load address

From: Yinghai Lu Currently the physical randomization's lower boundary is the original kernel load address. For bootloaders that load kernels into very high memory (e.g. kexec), this means randomization takes place in a very small window at the top of memory, ignoring the large region of

[PATCH v8 1/4] x86/KASLR: Clarify identity map interface

This extracts the call to prepare_level4() into a top-level function that the user of the pagetable.c interface must call to initialize the new page tables. For clarity and to match the "finalize" function, it has been renamed to initialize_identity_maps(). This function also gains the

Re: [PATCH v2] drm/vc4: Return -EBUSY if there's already a pending flip event.

Thanks Eric! On 2016-05-10 01:06 PM, Eric Anholt wrote: Robert Foss writes: On 2016-05-03 03:22 PM, Eric Anholt wrote: robert.f...@collabora.com writes: From: Robert Foss As per the documentation in drm_crtc.h, atomic_commit should

[PATCH v8 3/4] x86/KASLR: Add physical address randomization >4G

This patch exchanges the prior slots[] array for the new slot_areas[] array, and lifts the limitation of KERNEL_IMAGE_SIZE on the physical address offset for 64-bit. As before, process_e820_entry() walks memory and populates slot_areas[], splitting on any detected mem_avoid collisions. Finally,

[PATCH v8 1/4] x86/KASLR: Clarify identity map interface

This extracts the call to prepare_level4() into a top-level function that the user of the pagetable.c interface must call to initialize the new page tables. For clarity and to match the "finalize" function, it has been renamed to initialize_identity_maps(). This function also gains the

Re: [PATCH v2] drm/vc4: Return -EBUSY if there's already a pending flip event.

Thanks Eric! On 2016-05-10 01:06 PM, Eric Anholt wrote: Robert Foss writes: On 2016-05-03 03:22 PM, Eric Anholt wrote: robert.f...@collabora.com writes: From: Robert Foss As per the documentation in drm_crtc.h, atomic_commit should return -EBUSY if an asycnhronous update is requested

[PATCH v8 3/4] x86/KASLR: Add physical address randomization >4G

This patch exchanges the prior slots[] array for the new slot_areas[] array, and lifts the limitation of KERNEL_IMAGE_SIZE on the physical address offset for 64-bit. As before, process_e820_entry() walks memory and populates slot_areas[], splitting on any detected mem_avoid collisions. Finally,

Re: [PATCH v8 7/7] mm: kasan: Initial memory quarantine implementation

On Tue, May 10, 2016 at 5:39 PM, Andrey Ryabinin wrote: > 2016-03-15 13:10 GMT+03:00 Alexander Potapenko : > >> >> static inline int kasan_module_alloc(void *addr, size_t size) { return 0; } >> static inline void kasan_free_shadow(const struct

Re: [PATCH v8 7/7] mm: kasan: Initial memory quarantine implementation

On Tue, May 10, 2016 at 5:39 PM, Andrey Ryabinin wrote: > 2016-03-15 13:10 GMT+03:00 Alexander Potapenko : > >> >> static inline int kasan_module_alloc(void *addr, size_t size) { return 0; } >> static inline void kasan_free_shadow(const struct vm_struct *vm) {} >> diff --git a/lib/test_kasan.c

Re: [PATCH v6 2/2] kvm: introduce KVM_MAX_VCPU_ID

On 09/05/2016 18:23, Cornelia Huck wrote: > On Mon, 09 May 2016 18:13:37 +0200 > Greg Kurz wrote: > >> The KVM_MAX_VCPUS define provides the maximum number of vCPUs per guest, and >> also the upper limit for vCPU ids. This is okay for all archs except PowerPC >> which

Re: [PATCH v6 2/2] kvm: introduce KVM_MAX_VCPU_ID

On 09/05/2016 18:23, Cornelia Huck wrote: > On Mon, 09 May 2016 18:13:37 +0200 > Greg Kurz wrote: > >> The KVM_MAX_VCPUS define provides the maximum number of vCPUs per guest, and >> also the upper limit for vCPU ids. This is okay for all archs except PowerPC >> which can have higher ids,

Re: [PATCH] mmc: tegra: Disable UHS-I modes for tegra30

On 10/05/16 17:34, Stephen Warren wrote: > On 05/10/2016 10:13 AM, Jon Hunter wrote: [snip] >> Stephen, for your u-boot testing, do you are set the bit in the vendor >> misc register to enable version 3.0 support for sdhci on tegra30? This >> is what the above quirk is doing (and has done so

Re: [PATCH] mmc: tegra: Disable UHS-I modes for tegra30

On 10/05/16 17:34, Stephen Warren wrote: > On 05/10/2016 10:13 AM, Jon Hunter wrote: [snip] >> Stephen, for your u-boot testing, do you are set the bit in the vendor >> misc register to enable version 3.0 support for sdhci on tegra30? This >> is what the above quirk is doing (and has done so

Re: [PATCH v5 02/13] x86/xsaves: Rename xstate_size to kernel_xstate_size to explicitly distinguish xstate size in kernel from user space

On 05/10/2016 10:01 AM, Borislav Petkov wrote: >> >pr_info("x86/fpu: Enabled xstate features 0x%llx, context size is %d >> > bytes, using '%s' format.\n", >> >xfeatures_mask, >> > - xstate_size, >> > + kernel_xstate_size, >> >cpu_has_xsaves ?

Re: [PATCH v5 02/13] x86/xsaves: Rename xstate_size to kernel_xstate_size to explicitly distinguish xstate size in kernel from user space

On 05/10/2016 10:01 AM, Borislav Petkov wrote: >> >pr_info("x86/fpu: Enabled xstate features 0x%llx, context size is %d >> > bytes, using '%s' format.\n", >> >xfeatures_mask, >> > - xstate_size, >> > + kernel_xstate_size, >> >cpu_has_xsaves ?

Re: [PATCH BUGFIX] block: add missing group association in bio_split

Il 10/05/2016 18:12, Jeff Moyer ha scritto: Paolo Valente writes: When a bio is split, the newly created bio must be associated with the same blkcg as the original bio (if BLK_CGROUP is enabled). If this operation is not performed, then the new bio is not associated

Re: [PATCH BUGFIX] block: add missing group association in bio_split

Il 10/05/2016 18:12, Jeff Moyer ha scritto: Paolo Valente writes: When a bio is split, the newly created bio must be associated with the same blkcg as the original bio (if BLK_CGROUP is enabled). If this operation is not performed, then the new bio is not associated with any group, and the

Re: [PART1 V5 07/13] KVM: x86: Detect and Initialize AVIC support

On Tue, May 10, 2016 at 07:00:43PM +0200, Paolo Bonzini wrote: > If you read it backwards, that's the > > Mask > for the host physical id > in entries of > the physical ID table > (an AVIC thing). Note to self: defines in arch/x86/kvm/ should be read backwards. > Quite a

Re: [PATCH v2] drm/vc4: Return -EBUSY if there's already a pending flip event.

Robert Foss writes: > On 2016-05-03 03:22 PM, Eric Anholt wrote: >> robert.f...@collabora.com writes: >> >>> From: Robert Foss >>> >>> As per the documentation in drm_crtc.h, atomic_commit should return >>> -EBUSY if an asycnhronous update

Re: [PART1 V5 07/13] KVM: x86: Detect and Initialize AVIC support

On Tue, May 10, 2016 at 07:00:43PM +0200, Paolo Bonzini wrote: > If you read it backwards, that's the > > Mask > for the host physical id > in entries of > the physical ID table > (an AVIC thing). Note to self: defines in arch/x86/kvm/ should be read backwards. > Quite a

Re: [PATCH v2] drm/vc4: Return -EBUSY if there's already a pending flip event.

Robert Foss writes: > On 2016-05-03 03:22 PM, Eric Anholt wrote: >> robert.f...@collabora.com writes: >> >>> From: Robert Foss >>> >>> As per the documentation in drm_crtc.h, atomic_commit should return >>> -EBUSY if an asycnhronous update is requested and there is an earlier >>> update

Re: Getting rid of dynamic TASK_SIZE (on x86, at least)

On Tue, May 10, 2016 at 09:45:34AM -0700, Andy Lutomirski wrote: > On Tue, May 10, 2016 at 9:30 AM, Cyrill Gorcunov wrote: > > On Tue, May 10, 2016 at 09:07:49AM -0700, Andy Lutomirski wrote: > >> Hi all- > >> > >> I'm trying to get rid of x86's dynamic TASK_SIZE and just

Re: Getting rid of dynamic TASK_SIZE (on x86, at least)

On Tue, May 10, 2016 at 09:45:34AM -0700, Andy Lutomirski wrote: > On Tue, May 10, 2016 at 9:30 AM, Cyrill Gorcunov wrote: > > On Tue, May 10, 2016 at 09:07:49AM -0700, Andy Lutomirski wrote: > >> Hi all- > >> > >> I'm trying to get rid of x86's dynamic TASK_SIZE and just redefine it > >> to

Re: [PATCH v5 02/13] x86/xsaves: Rename xstate_size to kernel_xstate_size to explicitly distinguish xstate size in kernel from user space

On Mon, May 09, 2016 at 01:45:59PM -0700, Yu-cheng Yu wrote: > User space uses standard format xsave area. fpstate in signal frame should > have standard format size. > > To explicitly distinguish between xstate size in kernel space and the one > in user space, we rename xstate_size to

Re: [PATCH v5 02/13] x86/xsaves: Rename xstate_size to kernel_xstate_size to explicitly distinguish xstate size in kernel from user space

On Mon, May 09, 2016 at 01:45:59PM -0700, Yu-cheng Yu wrote: > User space uses standard format xsave area. fpstate in signal frame should > have standard format size. > > To explicitly distinguish between xstate size in kernel space and the one > in user space, we rename xstate_size to

Re: [PART1 V5 07/13] KVM: x86: Detect and Initialize AVIC support

On 10/05/2016 18:24, Borislav Petkov wrote: > Sure but how can one even read that? > > AVIC_PHYSICAL_ID_ENTRY_HOST_PHYSICAL_ID_MASK > > AVIC's physical ID entry's host's physical ID's mask? > > That sucks in any language :-) If you read it backwards, that's the Mask for the

Re: [PART1 V5 07/13] KVM: x86: Detect and Initialize AVIC support

On 10/05/2016 18:24, Borislav Petkov wrote: > Sure but how can one even read that? > > AVIC_PHYSICAL_ID_ENTRY_HOST_PHYSICAL_ID_MASK > > AVIC's physical ID entry's host's physical ID's mask? > > That sucks in any language :-) If you read it backwards, that's the Mask for the

Re: [PATCH v2 1/2] Documentation: DT: bindings: Add Broadcom STB PCIe bindings

On 05/05/2016 02:15 PM, Arnd Bergmann wrote: >> +Required properties: >> +- compatible: must be one of: "brcm,bcm7425-pcie" >> + "brcm,bcm7435-pcie" >> + "brcm,bcm7445-pcie" >> + >> +- reg: specifies the physical base address of the controller

Re: [PATCH v2 1/2] Documentation: DT: bindings: Add Broadcom STB PCIe bindings

On 05/05/2016 02:15 PM, Arnd Bergmann wrote: >> +Required properties: >> +- compatible: must be one of: "brcm,bcm7425-pcie" >> + "brcm,bcm7435-pcie" >> + "brcm,bcm7445-pcie" >> + >> +- reg: specifies the physical base address of the controller

[PATCH -v2] x86/hweight: Get rid of the special calling convention

From: Borislav Petkov Date: Wed, 4 May 2016 18:52:09 +0200 Subject: [PATCH -v2] x86/hweight: Get rid of the special calling convention People complained about ARCH_HWEIGHT_CFLAGS and how it throws a wrench into kcov, lto, etc, experimentation. And its not like we absolutely need

[PATCH -v2] x86/hweight: Get rid of the special calling convention

From: Borislav Petkov Date: Wed, 4 May 2016 18:52:09 +0200 Subject: [PATCH -v2] x86/hweight: Get rid of the special calling convention People complained about ARCH_HWEIGHT_CFLAGS and how it throws a wrench into kcov, lto, etc, experimentation. And its not like we absolutely need it so let's get

Re: [PATCH v9 7/7] vfio/type1: return MSI geometry through VFIO_IOMMU_GET_INFO capability chains

On 05/10/2016 01:03 AM, Alex Williamson wrote: > On Wed, 4 May 2016 14:06:19 +0200 > Eric Auger wrote: > >> Hi Alex, >> On 05/04/2016 01:54 PM, Eric Auger wrote: >>> This patch allows the user-space to retrieve the MSI geometry. The >>> implementation is based on

Re: [PATCH v9 7/7] vfio/type1: return MSI geometry through VFIO_IOMMU_GET_INFO capability chains

On 05/10/2016 01:03 AM, Alex Williamson wrote: > On Wed, 4 May 2016 14:06:19 +0200 > Eric Auger wrote: > >> Hi Alex, >> On 05/04/2016 01:54 PM, Eric Auger wrote: >>> This patch allows the user-space to retrieve the MSI geometry. The >>> implementation is based on capability chains, now also

[PATCH] KVM: x86: make hwapic_isr_update and hwapic_irr_update look the same

Neither APICv nor AVIC actually need the first argument of hwapic_isr_update, but the vCPU makes more sense than passing the pointer to the whole virtual machine! In fact in the APICv case it's just because the vCPU is used implicitly, through the loaded VMCS. The second argument instead is

[PATCH] KVM: x86: make hwapic_isr_update and hwapic_irr_update look the same

Neither APICv nor AVIC actually need the first argument of hwapic_isr_update, but the vCPU makes more sense than passing the pointer to the whole virtual machine! In fact in the APICv case it's just because the vCPU is used implicitly, through the loaded VMCS. The second argument instead is

Re: [PATCH 1/3] memory-hotplug: add move_pfn_range()

On Mon, 9 May 2016 12:53:37 -0500 Reza Arbab wrote: > Add move_pfn_range(), a wrapper to call move_pfn_range_left() or > move_pfn_range_right(). > > No functional change. This will be utilized by a later patch. > > Signed-off-by: Reza Arbab

Re: [PATCH 1/3] memory-hotplug: add move_pfn_range()

On Mon, 9 May 2016 12:53:37 -0500 Reza Arbab wrote: > Add move_pfn_range(), a wrapper to call move_pfn_range_left() or > move_pfn_range_right(). > > No functional change. This will be utilized by a later patch. > > Signed-off-by: Reza Arbab Looks good to me. Reviewed-by: Yasuaki Ishimatsu

Re: Getting rid of dynamic TASK_SIZE (on x86, at least)

On Tue, May 10, 2016 at 9:30 AM, Cyrill Gorcunov wrote: > On Tue, May 10, 2016 at 09:07:49AM -0700, Andy Lutomirski wrote: >> Hi all- >> >> I'm trying to get rid of x86's dynamic TASK_SIZE and just redefine it >> to TASK_SIZE_MAX. So far, these are the TASK_SIZE users that

Re: Getting rid of dynamic TASK_SIZE (on x86, at least)

On Tue, May 10, 2016 at 9:30 AM, Cyrill Gorcunov wrote: > On Tue, May 10, 2016 at 09:07:49AM -0700, Andy Lutomirski wrote: >> Hi all- >> >> I'm trying to get rid of x86's dynamic TASK_SIZE and just redefine it >> to TASK_SIZE_MAX. So far, these are the TASK_SIZE users that actually >> seem to

Re: [PATCH 1/1] Staging: comedi: comedi_fops.c: Fixed coding style issue

On 10/05/16 16:51, Shyam Saini wrote: Fixed following checkpatch.pl warnings WARNING: Prefer WRITE_ONCE(, ) over ACCESS_ONCE() = WARNING: Prefer READ_ONCE() over ACCESS_ONCE() Signed-off-by: Shyam Saini --- drivers/staging/comedi/comedi_fops.c | 12 ++-- 1

Re: [PATCH 1/1] Staging: comedi: comedi_fops.c: Fixed coding style issue

On 10/05/16 16:51, Shyam Saini wrote: Fixed following checkpatch.pl warnings WARNING: Prefer WRITE_ONCE(, ) over ACCESS_ONCE() = WARNING: Prefer READ_ONCE() over ACCESS_ONCE() Signed-off-by: Shyam Saini --- drivers/staging/comedi/comedi_fops.c | 12 ++-- 1 file changed, 6

Re: [PATCH v5 2/5] ARM: davinci: da8xx: Add CFGCHIP syscon platform declaration.

On 05/10/2016 06:26 AM, Sergei Shtylyov wrote: On 5/10/2016 2:46 AM, David Lechner wrote: The CFGCHIP registers are used by a number of devices, so using a syscon device to share them. The first consumer of this will by the phy-da8xx-usb driver. Signed-off-by: David Lechner

Re: [PATCH v5 2/5] ARM: davinci: da8xx: Add CFGCHIP syscon platform declaration.

On 05/10/2016 06:26 AM, Sergei Shtylyov wrote: On 5/10/2016 2:46 AM, David Lechner wrote: The CFGCHIP registers are used by a number of devices, so using a syscon device to share them. The first consumer of this will by the phy-da8xx-usb driver. Signed-off-by: David Lechner [...] diff

Re: [PATCH v2 00/23] ata: sata_dwc_460ex: make it working again

On Tue, 2016-05-10 at 12:30 -0400, Tejun Heo wrote: > Hello, > > On Tue, May 10, 2016 at 11:34:40AM +0530, Vinod Koul wrote: > > > > > > > > slave-dma [1], branch topic/dw. But I think Vinod can tell us > > > which > > > tag/branch will be immutable. Vinod? > > Please use branch topic/dw. I

Re: [PATCH v2 00/23] ata: sata_dwc_460ex: make it working again

On Tue, 2016-05-10 at 12:30 -0400, Tejun Heo wrote: > Hello, > > On Tue, May 10, 2016 at 11:34:40AM +0530, Vinod Koul wrote: > > > > > > > > slave-dma [1], branch topic/dw. But I think Vinod can tell us > > > which > > > tag/branch will be immutable. Vinod? > > Please use branch topic/dw. I

[PATCH net] drivers: net: Don't print unpopulated net_device name

For ethernet devices, net_device.name will be eth%d before register_netdev() is called. Don't print the net_device name until the format string is replaced. Cc: Robert Jarzmik Cc: Barry Song Cc: Marcel Ziswiler Cc:

[PATCH net] drivers: net: Don't print unpopulated net_device name

For ethernet devices, net_device.name will be eth%d before register_netdev() is called. Don't print the net_device name until the format string is replaced. Cc: Robert Jarzmik Cc: Barry Song Cc: Marcel Ziswiler Cc: net...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Harvey

Re: workqueue: race in mod_delayed_work_on?

Hello, On Tue, May 10, 2016 at 07:28:08PM +0300, Konstantin Khlebnikov wrote: > On 10.05.2016 11:21, Konstantin Khlebnikov wrote: > >I've got plenty warnings, bugs and oops around trivial use of > >mod_delayed_work in drivers/infiniband/core/addr.c > > Looks like problem in mod_delayed_work_on

Re: workqueue: race in mod_delayed_work_on?

Hello, On Tue, May 10, 2016 at 07:28:08PM +0300, Konstantin Khlebnikov wrote: > On 10.05.2016 11:21, Konstantin Khlebnikov wrote: > >I've got plenty warnings, bugs and oops around trivial use of > >mod_delayed_work in drivers/infiniband/core/addr.c > > Looks like problem in mod_delayed_work_on

RE: [PATCH 2/3] perf/x86/mbm: Fix mbm counting for RMID reuse

>> (3) Also we may not want to count at every sched_in and sched_out >> because the MSR reads involve quite a bit of overhead. > > Every single other PMU driver just does this; why are you special? They just have to read a register. We have to write the IA32_EM_EVT_SEL MSR and then read

RE: [PATCH 2/3] perf/x86/mbm: Fix mbm counting for RMID reuse

>> (3) Also we may not want to count at every sched_in and sched_out >> because the MSR reads involve quite a bit of overhead. > > Every single other PMU driver just does this; why are you special? They just have to read a register. We have to write the IA32_EM_EVT_SEL MSR and then read

Re: [PATCH v9 7/7] vfio/type1: return MSI geometry through VFIO_IOMMU_GET_INFO capability chains

Hi Alex, On 05/10/2016 12:49 AM, Alex Williamson wrote: > On Wed, 4 May 2016 11:54:18 + > Eric Auger wrote: > >> This patch allows the user-space to retrieve the MSI geometry. The >> implementation is based on capability chains, now also added to >>

Re: [PATCH v9 7/7] vfio/type1: return MSI geometry through VFIO_IOMMU_GET_INFO capability chains

Hi Alex, On 05/10/2016 12:49 AM, Alex Williamson wrote: > On Wed, 4 May 2016 11:54:18 + > Eric Auger wrote: > >> This patch allows the user-space to retrieve the MSI geometry. The >> implementation is based on capability chains, now also added to >> VFIO_IOMMU_GET_INFO. >> >> The returned

[PATCH v4 3/6] ext4: Add alignment check for DAX mount

When a partition is not aligned by 4KB, mount -o dax succeeds, but any read/write access to the filesystem fails, except for metadata update. Call bdev_dax_supported() to perform proper precondition checks which includes this partition alignment check. Reported-by: Micah Parrish

[PATCH v4 3/6] ext4: Add alignment check for DAX mount

When a partition is not aligned by 4KB, mount -o dax succeeds, but any read/write access to the filesystem fails, except for metadata update. Call bdev_dax_supported() to perform proper precondition checks which includes this partition alignment check. Reported-by: Micah Parrish Signed-off-by:

[PATCH v4 0/6] Add alignment check for DAX mount

When a partition is not aligned by 4KB, mount -o dax succeeds, but any read/write access to the filesystem fails, except for metadata update. Add alignment check to ext4, ext2, and xfs. - Patch 1-2 add bdev_dax_supported() which performs all the checks necessary for dax mount. - Patch 3-5

Re: [PATCH v5 01/13] x86/xsaves: Define and use user_xstate_size for xstate size in signal context

On Tue, May 10, 2016 at 06:29:00PM +0200, Borislav Petkov wrote: > Also, please snip the mail text you're quoting if you're not going to > refer to it. Like I just did. Ok :-)

[PATCH v4 0/6] Add alignment check for DAX mount

When a partition is not aligned by 4KB, mount -o dax succeeds, but any read/write access to the filesystem fails, except for metadata update. Add alignment check to ext4, ext2, and xfs. - Patch 1-2 add bdev_dax_supported() which performs all the checks necessary for dax mount. - Patch 3-5

Re: [PATCH v5 01/13] x86/xsaves: Define and use user_xstate_size for xstate size in signal context

On Tue, May 10, 2016 at 06:29:00PM +0200, Borislav Petkov wrote: > Also, please snip the mail text you're quoting if you're not going to > refer to it. Like I just did. Ok :-)

Re: [PATCH] mmc: tegra: Disable UHS-I modes for tegra30

On 05/10/2016 10:13 AM, Jon Hunter wrote: On 09/05/16 16:15, Jon Hunter wrote: Support for SD cards is not working on the Tegra30 Beaver board and on boot the following error message is seen if an SD card is present: mmc0: error -110 whilst initialising SD card In addition to this, Tegra30

[PATCH v4 1/6] block: Add vfs_msg() interface

In preparation of moving DAX capability checks to the block layer from filesystem code, add a VFS message interface that aligns with filesystem's message format. For instance, a vfs_msg() message followed by XFS messages in case of a dax mount error may look like: VFS (pmem0p1): error:

Re: [PATCH] mmc: tegra: Disable UHS-I modes for tegra30

On 05/10/2016 10:13 AM, Jon Hunter wrote: On 09/05/16 16:15, Jon Hunter wrote: Support for SD cards is not working on the Tegra30 Beaver board and on boot the following error message is seen if an SD card is present: mmc0: error -110 whilst initialising SD card In addition to this, Tegra30

[PATCH v4 1/6] block: Add vfs_msg() interface

In preparation of moving DAX capability checks to the block layer from filesystem code, add a VFS message interface that aligns with filesystem's message format. For instance, a vfs_msg() message followed by XFS messages in case of a dax mount error may look like: VFS (pmem0p1): error:

[PATCH v4 4/6] ext2: Add alignment check for DAX mount

When a partition is not aligned by 4KB, mount -o dax succeeds, but any read/write access to the filesystem fails, except for metadata update. Call bdev_dax_supported() to perform proper precondition checks which includes this partition alignment check. Signed-off-by: Toshi Kani

[PATCH v4 4/6] ext2: Add alignment check for DAX mount

When a partition is not aligned by 4KB, mount -o dax succeeds, but any read/write access to the filesystem fails, except for metadata update. Call bdev_dax_supported() to perform proper precondition checks which includes this partition alignment check. Signed-off-by: Toshi Kani Reviewed-by: Jan

[PATCH v4 6/6] block: Update blkdev_dax_capable() for consistency

blkdev_dax_capable() is similar to bdev_dax_supported(), but needs to remain as a separate interface for checking dax capability of a raw block device. Rename and relocate blkdev_dax_capable() to keep them maintained consistently, and call bdev_direct_access() for the dax capability check. There

Re: workqueue: race in mod_delayed_work_on?

On 10.05.2016 11:21, Konstantin Khlebnikov wrote: I've got plenty warnings, bugs and oops around trivial use of mod_delayed_work in drivers/infiniband/core/addr.c Looks like problem in mod_delayed_work_on was hidden because add_timer is equal to mod_timer but Sasha accidentally backported

[PATCH v4 6/6] block: Update blkdev_dax_capable() for consistency

blkdev_dax_capable() is similar to bdev_dax_supported(), but needs to remain as a separate interface for checking dax capability of a raw block device. Rename and relocate blkdev_dax_capable() to keep them maintained consistently, and call bdev_direct_access() for the dax capability check. There

Re: workqueue: race in mod_delayed_work_on?

On 10.05.2016 11:21, Konstantin Khlebnikov wrote: I've got plenty warnings, bugs and oops around trivial use of mod_delayed_work in drivers/infiniband/core/addr.c Looks like problem in mod_delayed_work_on was hidden because add_timer is equal to mod_timer but Sasha accidentally backported

<    3   4   5   6   7   8   9   10   11   12   >