linux.kernel - 26 new messages in 19 topics - digest

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

linux.kernel@googlegroups.com

Today's topics:

* devicetree: bindings: Document Krait/Scorpion cpus and enable-method - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/1598aa14a12139cd?hl=en
* lockdep: increase static allocations - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/da9aa9b0e2cea34e?hl=en
* mei: revamp mei reset state machine - 4 messages, 1 author
http://groups.google.com/group/linux.kernel/t/b3d429eb7b51891a?hl=en
* kvm: x86: Fix debug typo error in lapic - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/d2f26e1c9fa67436?hl=en
* mm: free memblock.memory in free_all_bootmem - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/53662ae043b7db01?hl=en
* PCI: Try best to allocate pref mmio 64bit above 4g - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/98098f241a7d18f9?hl=en
* kexec: add sysctl to disable kexec_load - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/87457a700eb3cc2b?hl=en
* ARM: dts: bcm28155-ap: Fix Card Detection GPIO - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/719bfd38cb2ad47a?hl=en
* binder: implement namepsace support for Android binder driver - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/69fb17227de5beef?hl=en
* pagewalk: update page table walker core - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/1f97c430da908e52?hl=en
* [tentative] PCI / ACPI: Rework PCI host bridge removal to avoid sysfs
warnings - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/0acfb30ad94acc57?hl=en
* drivers: dwc2: Mark function as static in core.c - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/2413ca44f9e0f8a2?hl=en
* Staging: lustre: Fix return does not need parantheses - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/69be2c64f44b5b83?hl=en
* beeceem: Fix newline issues at opening braces of conditional statements in
InterfaceRx.c - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/175d42594da2ec9f?hl=en
* Staging: lustre: Fix line length exceeding 80 characters - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/58f825fd29b8e6f3?hl=en
* drivers: gpu: Mark functions as static in radeon_device.c - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/71bc2475553ede70?hl=en
* kdump failed because of hotplug memory adding in kdump kernel - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/1d614525bf91dfa1?hl=en
* fix crash when using XFS on loopback - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/abeeabd164e3b873?hl=en
* libata fixes for 3.13-rc7 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/999edcdd8e172731?hl=en

==============================================================================
TOPIC: devicetree: bindings: Document Krait/Scorpion cpus and enable-method
http://groups.google.com/group/linux.kernel/t/1598aa14a12139cd?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Jan 8 2014 3:30 pm
From: Stephen Boyd


On 01/08/14 06:21, Mark Rutland wrote:
> On Tue, Dec 24, 2013 at 12:39:45AM +0000, Stephen Boyd wrote:
>> From: Rohit Vaswani <rvaswani@codeaurora.org>
>>
>> Scorpion and Krait don't use the spin-table enable-method.
>> Instead they rely on mmio register accesses to enable power and
>> clocks to bring CPUs out of reset. Document their enable-methods.
>>
>> Cc: <devicetree@vger.kernel.org>
>> Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
>> [sboyd: Split off into separate patch, renamed methods to
>> match compatible nodes]
>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>> ---
>> Documentation/devicetree/bindings/arm/cpus.txt | 25 ++++++++++++++++++++++++-
>> 1 file changed, 24 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
>> index 9130435..333f4ae 100644
>> --- a/Documentation/devicetree/bindings/arm/cpus.txt
>> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
>> @@ -180,7 +180,11 @@ nodes to be present and contain the properties described below.
>> be one of:
>> "spin-table"
>> "psci"
>> - # On ARM 32-bit systems this property is optional.
>> + # On ARM 32-bit systems this property is optional and
>> + can be one of:
>> + "qcom,gcc-msm8660"
>> + "qcom,kpss-acc-v1"
>> + "qcom,kpss-acc-v2"
> It would be nice to document "psci" here as valid for 32-bit.
>
> Currently the PSCI code doesn't inspect the enable-method and assumes it
> if there's a psci node, but KVM tool and others set enable-method to
> "psci", and if we change the way the PSCI code probes it will require
> enable-method to be set for PSCI to work.

Sure. I'll squash it in if I resend, or send a follow-up patch later on.

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: lockdep: increase static allocations
http://groups.google.com/group/linux.kernel/t/da9aa9b0e2cea34e?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Jan 8 2014 3:30 pm
From: Andi Kleen


On Wed, Jan 08, 2014 at 03:10:55PM -0500, Sasha Levin wrote:
> On 01/08/2014 02:51 PM, Andi Kleen wrote:
> >Sasha Levin <sasha.levin@oracle.com> writes:
> >
> >>Fuzzing a recent kernel with a large configuration hits the static
> >>allocation limits and disables lockdep.
> >
> >Doesn't that use a lot more memory? I thought lockdep preallocates.
> >
> >Doubling may be too aggressive.
>
> The patch adds about 4MB of memory usage, I didn't think it's too much for something
> that is only enabled during debugging.

Wasting 4MB is an issue.

Linus' first Linux system had less total memory than that.

>
> If this is an issue, can I suggest making these values configurable in the .config
> and just let users pick whatever they want?

Better allocate it at boot time, using a boot parameter or somesuch.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: mei: revamp mei reset state machine
http://groups.google.com/group/linux.kernel/t/b3d429eb7b51891a?hl=en
==============================================================================

== 1 of 4 ==
Date: Wed, Jan 8 2014 3:30 pm
From: Greg KH


On Wed, Jan 08, 2014 at 08:19:23PM +0200, Tomas Winkler wrote:
> 1. MEI_DEV_RESETTING device state spans only hardware reset flow
> while starting dev state is saved into a local variable for further
> reference, this let us to reduce big if statements in case we
> are trying to avoid nested resets
>
> 2. During initializations if the reset ended in MEI_DEV_DISABLED device
> state we bail out with -ENODEV
>
> 3. Remove redundant interrupts_enabled parameter as this
> can be deduced from the starting dev_state
>
> 4. mei_reset propagates error code to the caller
>
> 5. Add mei_restart function to wrap the pci resume
>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
> ---
> drivers/misc/mei/hbm.c | 2 +-
> drivers/misc/mei/hw-me.c | 10 +--
> drivers/misc/mei/init.c | 210 ++++++++++++++++++++++++++-----------------
> drivers/misc/mei/interrupt.c | 13 +--
> drivers/misc/mei/mei_dev.h | 3 +-
> drivers/misc/mei/pci-me.c | 10 +--
> 6 files changed, 143 insertions(+), 105 deletions(-)

Again, way too big for stable kernels, sorry.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 2 of 4 ==
Date: Wed, Jan 8 2014 3:30 pm
From: Greg KH


On Wed, Jan 08, 2014 at 08:19:21PM +0200, Tomas Winkler wrote:
> This fixes a potential deadlock in case of a firmware
> initiated reset
>
> mei_reset has a dialog with the interrupt thread hence
> it has to be run from an another work item
>
> Most of the mei_resets were called from mei_hbm_dispatch
> which is called in interrupt thread context so this
> function underwent major revamp. The error code is
> propagated to the interrupt thread and if needed
> the reset is scheduled from there.
>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
> ---
> drivers/misc/mei/hbm.c | 200 +++++++++++++++++++++++++++----------------
> drivers/misc/mei/hbm.h | 6 +-
> drivers/misc/mei/hw-me.c | 32 ++++---
> drivers/misc/mei/init.c | 100 +++++++++++++---------
> drivers/misc/mei/interrupt.c | 9 +-
> drivers/misc/mei/mei_dev.h | 1 +
> 6 files changed, 210 insertions(+), 138 deletions(-)

This is a _really_ big patch for a stable kernel tree. Are you sure
it's needed there? Please go read Documentation/stable_kernel_rules.txt
again.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 3 of 4 ==
Date: Wed, Jan 8 2014 3:30 pm
From: Greg KH


On Wed, Jan 08, 2014 at 08:19:23PM +0200, Tomas Winkler wrote:
> 1. MEI_DEV_RESETTING device state spans only hardware reset flow
> while starting dev state is saved into a local variable for further
> reference, this let us to reduce big if statements in case we
> are trying to avoid nested resets
>
> 2. During initializations if the reset ended in MEI_DEV_DISABLED device
> state we bail out with -ENODEV
>
> 3. Remove redundant interrupts_enabled parameter as this
> can be deduced from the starting dev_state
>
> 4. mei_reset propagates error code to the caller
>
> 5. Add mei_restart function to wrap the pci resume
>
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
> ---
> drivers/misc/mei/hbm.c | 2 +-
> drivers/misc/mei/hw-me.c | 10 +--
> drivers/misc/mei/init.c | 210 ++++++++++++++++++++++++++-----------------
> drivers/misc/mei/interrupt.c | 13 +--
> drivers/misc/mei/mei_dev.h | 3 +-
> drivers/misc/mei/pci-me.c | 10 +--
> 6 files changed, 143 insertions(+), 105 deletions(-)

This patch fails to apply to my tree:

checking file drivers/misc/mei/hbm.c
checking file drivers/misc/mei/hw-me.c
checking file drivers/misc/mei/init.c
Hunk #3 FAILED at 85.
Hunk #4 succeeded at 119 (offset -1 lines).
Hunk #5 succeeded at 246 (offset -1 lines).
Hunk #6 succeeded at 267 (offset -1 lines).
1 out of 6 hunks FAILED
checking file drivers/misc/mei/interrupt.c
checking file drivers/misc/mei/mei_dev.h
checking file drivers/misc/mei/pci-me.c

Care to fix it up and resend?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 4 of 4 ==
Date: Wed, Jan 8 2014 3:30 pm
From: Greg KH


On Wed, Jan 08, 2014 at 08:19:24PM +0200, Tomas Winkler wrote:
> give up reseting after 3 unsuccessful tries
>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
> ---
> drivers/misc/mei/client.c | 1 +
> drivers/misc/mei/init.c | 10 ++++++++++
> drivers/misc/mei/mei_dev.h | 7 +++++++
> 3 files changed, 18 insertions(+)

Doesn't apply as patch 3/4 didn't apply.

Which means it shouldn't be for a stable kernel either...

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: kvm: x86: Fix debug typo error in lapic
http://groups.google.com/group/linux.kernel/t/d2f26e1c9fa67436?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Jan 8 2014 3:30 pm
From: Marcelo Tosatti


On Wed, Jan 08, 2014 at 06:14:15PM -0500, Hu Yaohui wrote:
> Hi guys,
> I think you should be pretty familiar with lapic. I would really
> appreciate it if someone could shed some lights on my problem
> regarding Guest TLB flush IPI.
> Supposed we get two vcpus 0 and 1.
> When vcpu#0 wants to invalidate the tlb entry on vcpu#1. An IPI will
> be generated by lapic on vcpu#0 by writing to ICR which will cause a
> vmexit.
> apic_send_ipi->kvm_irq_delivery_to_apic->kvm_apic_set_irq->__apic_accept_irq
> In __apic_accept_irq, it will call kvm_make_request, kvm_vcpu_kick.
> If vcpu#1 in guest mode, how can it receives this IPI immediately, or
> the stale tlb entry could be accessed. Thanks for your time!

Two possibilities:

2) Hardware does not support APIC virtualization: kvm_vcpu_kick sends an
host-IPI to the remote vcpu, and if that vcpu is in guest mode, a VM-exit
(exit reason: external interrupt) will be triggered due to the host-IPI.
Then on VM-entry (inject_pending_event) the guest-IPI is injected.

2) Host CPU supports APIC virtualization (see commit 83d4c286931c and
Intel's documentation):
A bit is set in the posted interrupt section, and a special host-IPI is
delivered to the target cpu where the guest vcpu is scheduled
(vmx_deliver_posted_interrupt) which causes the hardware to
inject the vector (without VM-exit).


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 2 of 2 ==
Date: Wed, Jan 8 2014 3:40 pm
From: Hu Yaohui


Thanks a lot Marcelo!

On Wed, Jan 8, 2014 at 6:25 PM, Marcelo Tosatti <mtosatti@redhat.com> wrote:
> On Wed, Jan 08, 2014 at 06:14:15PM -0500, Hu Yaohui wrote:
>> Hi guys,
>> I think you should be pretty familiar with lapic. I would really
>> appreciate it if someone could shed some lights on my problem
>> regarding Guest TLB flush IPI.
>> Supposed we get two vcpus 0 and 1.
>> When vcpu#0 wants to invalidate the tlb entry on vcpu#1. An IPI will
>> be generated by lapic on vcpu#0 by writing to ICR which will cause a
>> vmexit.
>> apic_send_ipi->kvm_irq_delivery_to_apic->kvm_apic_set_irq->__apic_accept_irq
>> In __apic_accept_irq, it will call kvm_make_request, kvm_vcpu_kick.
>> If vcpu#1 in guest mode, how can it receives this IPI immediately, or
>> the stale tlb entry could be accessed. Thanks for your time!
>
I am using kvm-kmod-3.2
> Two possibilities:
>
> 2) Hardware does not support APIC virtualization: kvm_vcpu_kick sends an
> host-IPI to the remote vcpu, and if that vcpu is in guest mode, a VM-exit
> (exit reason: external interrupt) will be triggered due to the host-IPI.
> Then on VM-entry (inject_pending_event) the guest-IPI is injected.
>
if vcpu#1 is not on the same pcpu as the vcpu#0, a host-IPI will be sent.
But if they are on the same pcpu, if vcpu#1 is in guest mode. Then the
guest tlb flush IPI
will wait until the next vcpu#1 vmexit. If that's the case. they are
some time that the tlb entry has been
invalidated in vcpu#0, but the corresponding entry in vcpu#1 could
still been accessed, which seems cause some problem.

> 2) Host CPU supports APIC virtualization (see commit 83d4c286931c and
> Intel's documentation):
> A bit is set in the posted interrupt section, and a special host-IPI is
> delivered to the target cpu where the guest vcpu is scheduled
> (vmx_deliver_posted_interrupt) which causes the hardware to
> inject the vector (without VM-exit).
>
>
I did not find this function (vmx_deliver_posted_interrupt) in my kvm
kernel module.
Does that mean my hardware doesn't support APIC virtualization?

Thanks for your time!

Best Wishes,
Yaohui Hu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: mm: free memblock.memory in free_all_bootmem
http://groups.google.com/group/linux.kernel/t/53662ae043b7db01?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Jan 8 2014 3:40 pm
From: Yinghai Lu


On Wed, Jan 8, 2014 at 5:42 AM, Philipp Hachtmann
<phacht@linux.vnet.ibm.com> wrote:
> Am Wed, 8 Jan 2014 12:08:04 +0800
> schrieb Jianguo Wu <wujianguo@huawei.com>:
>
>> For some archs, like arm64, would use memblock.memory after system
>> booting, so we can not simply released to the buddy allocator, maybe
>> need !defined(CONFIG_ARCH_DISCARD_MEMBLOCK).
>
> Oh, I see. I have added some ifdefs to prevent memblock.memory from
> being freed when CONFIG_ARCH_DISCARD_MEMBLOCK is not set.
>
> Here is a replacement for the patch.
>
> Kind regards
>
> Philipp
>
> From aca95bcb9d79388b68bf18e7bae4353259b6758f Mon Sep 17 00:00:00 2001
> From: Philipp Hachtmann <phacht@linux.vnet.ibm.com>
> Date: Thu, 19 Dec 2013 15:53:46 +0100
> Subject: [PATCH 2/2] mm: free memblock.memory in free_all_bootmem
>
> When calling free_all_bootmem() the free areas under memblock's
> control are released to the buddy allocator. Additionally the
> reserved list is freed if it was reallocated by memblock.
> The same should apply for the memory list.
>
> Signed-off-by: Philipp Hachtmann <phacht@linux.vnet.ibm.com>
> ---
> include/linux/memblock.h | 1 +
> mm/memblock.c | 16 ++++++++++++++++
> mm/nobootmem.c | 10 +++++++++-
> 3 files changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> index 77c60e5..d174922 100644
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -52,6 +52,7 @@ phys_addr_t memblock_find_in_range_node(phys_addr_t start, phys_addr_t end,
> phys_addr_t memblock_find_in_range(phys_addr_t start, phys_addr_t end,
> phys_addr_t size, phys_addr_t align);
> phys_addr_t get_allocated_memblock_reserved_regions_info(phys_addr_t *addr);
> +phys_addr_t get_allocated_memblock_memory_regions_info(phys_addr_t *addr);
> void memblock_allow_resize(void);
> int memblock_add_node(phys_addr_t base, phys_addr_t size, int nid);
> int memblock_add(phys_addr_t base, phys_addr_t size);
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 53e477b..a78b2e9 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -271,6 +271,22 @@ phys_addr_t __init_memblock get_allocated_memblock_reserved_regions_info(
> memblock.reserved.max);
> }
>
> +#ifdef CONFIG_ARCH_DISCARD_MEMBLOCK
> +
> +phys_addr_t __init_memblock get_allocated_memblock_memory_regions_info(
> + phys_addr_t *addr)
> +{
> + if (memblock.memory.regions == memblock_memory_init_regions)
> + return 0;
> +
> + *addr = __pa(memblock.memory.regions);
> +
> + return PAGE_ALIGN(sizeof(struct memblock_region) *
> + memblock.memory.max);
> +}
> +
> +