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

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

linux.kernel@googlegroups.com

Today's topics:

* MAINTAINERS tree branches [xen tip as an example] - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/e080ae587afdec2e?hl=en
* i2c: qup: Add device tree bindings information - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/2c6bb71246961625?hl=en
* mmc: sdhci: fix possible scheduling while atomic - 4 messages, 3 authors
http://groups.google.com/group/linux.kernel/t/5220ab2fee9bc8b4?hl=en
* net: rfkill: gpio: add device tree support - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/502551497c79a009?hl=en
* pinctrl: capri: add dependency on OF - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/bcdbebbdc79aee31?hl=en
* x86, CPU, AMD: Add workaround for family 16h, erratum 793 - 3 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/0e4150592fc82fa1?hl=en
* mtd: block2mtd: char mtd major and erasesize parameter check + mutex_destroy
- 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/5b75aa23cf74312b?hl=en
* crypto: Simple crypto algorithm load balancer - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/5983996c9887b6ad?hl=en
* crypto: Simple load balancer test module - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/a990e4ce630270d8?hl=en
* Deadlock in do_page_fault() on ARM (old kernel) - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/d3fb0c69a17cc5a5?hl=en
* dt-bindings: qcom: Fix warning with duplicate dt define - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/07e77d0db06e0e58?hl=en
* cgroup: make CONFIG_NET_CLS_CGROUP and CONFIG_NETPRIO_CGROUP bool instead of
tristate - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/3a3c8584cdd64136?hl=en
* fs: don't write pages when receiving a pending SIGKILL in __get_user_pages()
- 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/38a356209f5ec559?hl=en
* target fixes for v3.13 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/a05b90fd74d0ef51?hl=en
* [v3.12][v3.13][Regression] EISA: Initialize device before its resources - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/bf9255ff181e65b5?hl=en
* ipv4_dst_destroy panic regression after 3.10.15 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f9a10b1dd49cf609?hl=en
* net: rds: fix per-cpu helper usage - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/49ce51b657a098f7?hl=en
* kvm: make KVM_MMU_AUDIT help text more readable - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/dd451709dc3dd0d5?hl=en

==============================================================================
TOPIC: MAINTAINERS tree branches [xen tip as an example]
http://groups.google.com/group/linux.kernel/t/e080ae587afdec2e?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 17 2014 3:10 pm
From: "Luis R. Rodriguez"


As per linux-next Next/Trees [0], and a recent January MAINTAINERS patch [1]
from David one of the xen development kernel git trees to track is
xen/git.git [2], this tree however gives has undefined references when doing a
fresh clone [shown below], but as expected does work well when only cloning
the linux-next branch [also below]. While I'm sure this is fine for
folks who can do the guess work do we really want to live with trees like
these on MAINTAINERS ? The MAINTAINERS file doesn't let us specify branches
required, so perhaps it should -- if we want to live with these ? Curious, how
many other git are there with a similar situation ?

The xen project web site actually lists [3] Konrad's xen git tree [4] for
development as the primary development tree, that probably should be
updated now, and likely with instructions to clone only the linux-next
branch ?

[0] https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Next/Trees#n176
[1] http://lists.xen.org/archives/html/xen-devel/2014-01/msg01504.html
[2] git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
[3] http://wiki.xenproject.org/wiki/Xen_Repositories#Primary_Xen_Repository
[4] git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git

mcgrof@bubbles ~ $ git clone
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git --reference linux/.git
Cloning into 'tip'...
remote: Counting objects: 2806, done.
remote: Compressing objects: 100% (334/334), done.
remote: Total 1797 (delta 1511), reused 1646 (delta 1462)
Receiving objects: 100% (1797/1797), 711.01 KiB | 640.00 KiB/s, done.
Resolving deltas: 100% (1511/1511), completed with 306 local objects.
Checking connectivity... done.
warning: remote HEAD refers to nonexistent ref, unable to checkout.

mcgrof@work ~ $ git clone
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git -b linux-next --reference linux/.git
Cloning into 'tip'...
remote: Counting objects: 2806, done.
remote: Compressing objects: 100% (377/377), done.
remote: Total 1797 (delta 1545), reused 1607 (delta 1419)
Receiving objects: 100% (1797/1797), 485.23 KiB | 0 bytes/s, done.
Resolving deltas: 100% (1545/1545), completed with 327 local objects.
Checking connectivity... done.
Checking out files: 100% (44979/44979), done.

Luis





==============================================================================
TOPIC: i2c: qup: Add device tree bindings information
http://groups.google.com/group/linux.kernel/t/2c6bb71246961625?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 17 2014 3:10 pm
From: Bjorn Andersson


From: "Ivan T. Ivanov" <iivanov@mm-sol.com>

The Qualcomm Universal Peripherial (QUP) wraps I2C mini-core and
provide input and output FIFO's for it. I2C controller can operate
as master with supported bus speeds of 100Kbps and 400Kbps.

Signed-off-by: Ivan T. Ivanov <iivanov@mm-sol.com>
[bjorn: reformulated part of binding description and cleaned up example]
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
---
.../devicetree/bindings/i2c/qcom,i2c-qup.txt | 41 ++++++++++++++++++++++
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt

diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt b/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt
new file mode 100644
index 0000000..a99711b
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt
@@ -0,0 +1,41 @@
+Qualcomm Universal Peripheral (QUP) I2C controller
+
+Required properties:
+ - compatible: Should be "qcom,i2c-qup".
+ - reg: Should contain QUP register address and length.
+ - interrupts: Should contain I2C interrupt.
+
+ - clocks: Should contain the core clock and the AHB clock.
+ - clock-names: Should be "core" for the core clock and "iface" for the
+ AHB clock.
+
+ - #address-cells: Should be <1> Address cells for i2c device address
+ - #size-cells: Should be <0> as i2c addresses have no size component
+
+Optional properties:
+ - clock-frequency: Should specify the desired i2c bus clock frequency in Hz,
+ default is 100kHz if omitted.
+
+Child nodes should conform to i2c bus binding.
+
+Example:
+
+ i2c2: i2c@f9924000 {
+ compatible = "qcom,i2c-qup";
+ reg = <0xf9924000 0x1000>;
+ interrupts = <0 96 0>;
+
+ clocks = <&gcc_blsp1_qup2_i2c_apps_clk>, <&gcc_blsp1_ahb_clk>;
+ clock-names = "core", "iface";
+
+ clock-frequency = <355000>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dummy@60 {
+ compatible = "dummy";
+ reg = <0x60>;
+ };
+ };
+
--
1.8.2.2

--
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: mmc: sdhci: fix possible scheduling while atomic
http://groups.google.com/group/linux.kernel/t/5220ab2fee9bc8b4?hl=en
==============================================================================

== 1 of 4 ==
Date: Fri, Jan 17 2014 3:20 pm
From: John Tobias


There's an existing patch for that...
http://www.spinics.net/lists/arm-kernel/msg296596.html

On Fri, Jan 17, 2014 at 2:58 PM, Philip Rakity <prakity@nvidia.com> wrote:
>
> On Jan 17, 2014, at 7:57 PM, Andrew Bresticker <abrestic@chromium.org> wrote:
>
>> sdhci_execute_tuning() takes host->lock without disabling interrupts.
>> Use spin_lock_irq{save,restore} instead so that we avoid taking an
>> interrupt and scheduling while holding host->lock.
>>
>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>> ---
>> drivers/mmc/host/sdhci.c | 13 +++++++------
>> 1 file changed, 7 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> index ec3eb30..84c80e7 100644
>> --- a/drivers/mmc/host/sdhci.c
>> +++ b/drivers/mmc/host/sdhci.c
>> @@ -1857,12 +1857,13 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
>> unsigned long timeout;
>> int err = 0;
>> bool requires_tuning_nonuhs = false;
>> + unsigned long flags;
>>
>> host = mmc_priv(mmc);
>>
>> sdhci_runtime_pm_get(host);
>> disable_irq(host->irq);
>> - spin_lock(&host->lock);
>> + spin_lock_irqsave(&host->lock, flags);
>
>
> The disable_irq() call stops the controller from doing interrupts.
> Please explain what problem you are seeing
>
>>
>> ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
>>
>> @@ -1882,14 +1883,14 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
>> requires_tuning_nonuhs)
>> ctrl |= SDHCI_CTRL_EXEC_TUNING;
>> else {
>> - spin_unlock(&host->lock);
>> + spin_unlock_irqrestore(&host->lock, flags);
>> enable_irq(host->irq);
>> sdhci_runtime_pm_put(host);
>> return 0;
>> }
>>
>> if (host->ops->platform_execute_tuning) {
>> - spin_unlock(&host->lock);
>> + spin_unlock_irqrestore(&host->lock, flags);
>> enable_irq(host->irq);
>> err = host->ops->platform_execute_tuning(host, opcode);
>> sdhci_runtime_pm_put(host);
>> @@ -1963,7 +1964,7 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
>> host->cmd = NULL;
>> host->mrq = NULL;
>>
>> - spin_unlock(&host->lock);
>> + spin_unlock_irqrestore(&host->lock, flags);
>> enable_irq(host->irq);
>>
>> /* Wait for Buffer Read Ready interrupt */
>> @@ -1971,7 +1972,7 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
>> (host->tuning_done == 1),
>> msecs_to_jiffies(50));
>> disable_irq(host->irq);
>> - spin_lock(&host->lock);
>> + spin_lock_irqsave(&host->lock, flags);
>>
>> if (!host->tuning_done) {
>> pr_info(DRIVER_NAME ": Timeout waiting for "
>> @@ -2046,7 +2047,7 @@ out:
>> err = 0;
>>
>> sdhci_clear_set_irqs(host, SDHCI_INT_DATA_AVAIL, ier);
>> - spin_unlock(&host->lock);
>> + spin_unlock_irqrestore(&host->lock, flags);
>> enable_irq(host->irq);
>> sdhci_runtime_pm_put(host);
>>
>> --
>> 1.8.5.2
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> 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/
--
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: Fri, Jan 17 2014 3:20 pm
From: Andrew Bresticker


On Fri, Jan 17, 2014 at 2:58 PM, Philip Rakity <prakity@nvidia.com> wrote:
>
> On Jan 17, 2014, at 7:57 PM, Andrew Bresticker <abrestic@chromium.org> wrote:
>
>> sdhci_execute_tuning() takes host->lock without disabling interrupts.
>> Use spin_lock_irq{save,restore} instead so that we avoid taking an
>> interrupt and scheduling while holding host->lock.
>>
>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>> ---
>> drivers/mmc/host/sdhci.c | 13 +++++++------
>> 1 file changed, 7 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> index ec3eb30..84c80e7 100644
>> --- a/drivers/mmc/host/sdhci.c
>> +++ b/drivers/mmc/host/sdhci.c
>> @@ -1857,12 +1857,13 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
>> unsigned long timeout;
>> int err = 0;
>> bool requires_tuning_nonuhs = false;
>> + unsigned long flags;
>>
>> host = mmc_priv(mmc);
>>
>> sdhci_runtime_pm_get(host);
>> disable_irq(host->irq);
>> - spin_lock(&host->lock);
>> + spin_lock_irqsave(&host->lock, flags);
>
>
> The disable_irq() call stops the controller from doing interrupts.

Right, but it does not disable other IRQ sources that could cause us
to schedule.

> Please explain what problem you are seeing

The issue we were seeing was that a card-detect interrupt was
triggered (*not* the controller interrupt), causing the card-detect
irq thread to recurse on host->lock:

[ 60.962218] BUG: spinlock cpu recursion on CPU#0, irq/362-700b040/89
[ 60.975253] lock: 0xee210c80, .magic: dead4ead, .owner:
kworker/u8:1/33, .owner_cpu: 0
[ 60.991638] CPU: 0 PID: 89 Comm: irq/362-700b040 Not tainted 3.10.18 #2
[ 61.005199] [<800153cc>] (unwind_backtrace+0x0/0x118) from
[<800124e4>] (show_stack+0x20/0x24)
[ 61.022824] [<800124e4>] (show_stack+0x20/0x24) from [<8053d584>]
(dump_stack+0x20/0x28)
[ 61.039389] [<8053d584>] (dump_stack+0x20/0x28) from [<8021d508>]
(spin_dump+0x80/0x94)
[ 61.055773] [<8021d508>] (spin_dump+0x80/0x94) from [<8021d548>]
(spin_bug+0x2c/0x30)
[ 61.071803] [<8021d548>] (spin_bug+0x2c/0x30) from [<8021d61c>]
(do_raw_spin_lock+0x70/0x15c)
[ 61.089250] [<8021d61c>] (do_raw_spin_lock+0x70/0x15c) from
[<8054098c>] (_raw_spin_lock_irqsave+0x20/0x28)
[ 61.109175] [<8054098c>] (_raw_spin_lock_irqsave+0x20/0x28) from
[<803e2af0>] (sdhci_card_event+0x28/0xfc)
[ 61.128922] [<803e2af0>] (sdhci_card_event+0x28/0xfc) from
[<803dc880>] (mmc_gpio_cd_irqt+0x30/0x4c)
[ 61.147609] [<803dc880>] (mmc_gpio_cd_irqt+0x30/0x4c) from
[<80091858>] (irq_thread+0xf0/0x224)
[ 61.165412] [<80091858>] (irq_thread+0xf0/0x224) from [<80050db4>]
(kthread+0xc8/0xd8)
[ 61.181623] [<80050db4>] (kthread+0xc8/0xd8) from [<8000e4d8>]
(ret_from_fork+0x14/0x20)

Thanks,
Andrew

>
>>
>> ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
>>
>> @@ -1882,14 +1883,14 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
>> requires_tuning_nonuhs)
>> ctrl |= SDHCI_CTRL_EXEC_TUNING;
>> else {
>> - spin_unlock(&host->lock);
>> + spin_unlock_irqrestore(&host->lock, flags);
>> enable_irq(host->irq);
>> sdhci_runtime_pm_put(host);
>> return 0;
>> }
>>
>> if (host->ops->platform_execute_tuning) {
>> - spin_unlock(&host->lock);
>> + spin_unlock_irqrestore(&host->lock, flags);
>> enable_irq(host->irq);
>> err = host->ops->platform_execute_tuning(host, opcode);
>> sdhci_runtime_pm_put(host);
>> @@ -1963,7 +1964,7 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
>> host->cmd = NULL;
>> host->mrq = NULL;
>>
>> - spin_unlock(&host->lock);
>> + spin_unlock_irqrestore(&host->lock, flags);
>> enable_irq(host->irq);
>>
>> /* Wait for Buffer Read Ready interrupt */
>> @@ -1971,7 +1972,7 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
>> (host->tuning_done == 1),
>> msecs_to_jiffies(50));
>> disable_irq(host->irq);
>> - spin_lock(&host->lock);
>> + spin_lock_irqsave(&host->lock, flags);
>>
>> if (!host->tuning_done) {
>> pr_info(DRIVER_NAME ": Timeout waiting for "
>> @@ -2046,7 +2047,7 @@ out:
>> err = 0;
>>
>> sdhci_clear_set_irqs(host, SDHCI_INT_DATA_AVAIL, ier);
>> - spin_unlock(&host->lock);
>> + spin_unlock_irqrestore(&host->lock, flags);
>> enable_irq(host->irq);
>> sdhci_runtime_pm_put(host);
>>
>> --
>> 1.8.5.2
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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: Fri, Jan 17 2014 3:20 pm
From: Andrew Bresticker


On Fri, Jan 17, 2014 at 3:11 PM, John Tobias <john.tobias.ph@gmail.com> wrote:
> There's an existing patch for that...
> http://www.spinics.net/lists/arm-kernel/msg296596.html

Ah, I see. Looks like it has yet to be picked up...

>
> On Fri, Jan 17, 2014 at 2:58 PM, Philip Rakity <prakity@nvidia.com> wrote:
>>
>> On Jan 17, 2014, at 7:57 PM, Andrew Bresticker <abrestic@chromium.org> wrote:
>>
>>> sdhci_execute_tuning() takes host->lock without disabling interrupts.
>>> Use spin_lock_irq{save,restore} instead so that we avoid taking an
>>> interrupt and scheduling while holding host->lock.
>>>
>>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>>> ---
>>> drivers/mmc/host/sdhci.c | 13 +++++++------
>>> 1 file changed, 7 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>>> index ec3eb30..84c80e7 100644
>>> --- a/drivers/mmc/host/sdhci.c
>>> +++ b/drivers/mmc/host/sdhci.c
>>> @@ -1857,12 +1857,13 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
>>> unsigned long timeout;
>>> int err = 0;
>>> bool requires_tuning_nonuhs = false;
>>> + unsigned long flags;
>>>
>>> host = mmc_priv(mmc);
>>>
>>> sdhci_runtime_pm_get(host);
>>> disable_irq(host->irq);
>>> - spin_lock(&host->lock);
>>> + spin_lock_irqsave(&host->lock, flags);
>>
>>
>> The disable_irq() call stops the controller from doing interrupts.
>> Please explain what problem you are seeing
>>
>>>
>>> ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
>>>
>>> @@ -1882,14 +1883,14 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
>>> requires_tuning_nonuhs)
>>> ctrl |= SDHCI_CTRL_EXEC_TUNING;
>>> else {
>>> - spin_unlock(&host->lock);
>>> + spin_unlock_irqrestore(&host->lock, flags);
>>> enable_irq(host->irq);
>>> sdhci_runtime_pm_put(host);
>>> return 0;
>>> }
>>>
>>> if (host->ops->platform_execute_tuning) {
>>> - spin_unlock(&host->lock);
>>> + spin_unlock_irqrestore(&host->lock, flags);
>>> enable_irq(host->irq);
>>> err = host->ops->platform_execute_tuning(host, opcode);
>>> sdhci_runtime_pm_put(host);
>>> @@ -1963,7 +1964,7 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
>>> host->cmd = NULL;
>>> host->mrq = NULL;
>>>
>>> - spin_unlock(&host->lock);
>>> + spin_unlock_irqrestore(&host->lock, flags);
>>> enable_irq(host->irq);
>>>
>>> /* Wait for Buffer Read Ready interrupt */
>>> @@ -1971,7 +1972,7 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
>>> (host->tuning_done == 1),
>>> msecs_to_jiffies(50));
>>> disable_irq(host->irq);
>>> - spin_lock(&host->lock);
>>> + spin_lock_irqsave(&host->lock, flags);
>>>
>>> if (!host->tuning_done) {
>>> pr_info(DRIVER_NAME ": Timeout waiting for "
>>> @@ -2046,7 +2047,7 @@ out:
>>> err = 0;
>>>
>>> sdhci_clear_set_irqs(host, SDHCI_INT_DATA_AVAIL, ier);
>>> - spin_unlock(&host->lock);
>>> + spin_unlock_irqrestore(&host->lock, flags);
>>> enable_irq(host->irq);
>>> sdhci_runtime_pm_put(host);
>>>
>>> --
>>> 1.8.5.2
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>> --
>> 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/
--
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: Fri, Jan 17 2014 3:50 pm
From: Chris Ball


Hi, adding Aisheng,

On Fri, Jan 17 2014, Andrew Bresticker wrote:
> On Fri, Jan 17, 2014 at 3:11 PM, John Tobias <john.tobias.ph@gmail.com> wrote:
>> There's an existing patch for that...
>> http://www.spinics.net/lists/arm-kernel/msg296596.html
>
> Ah, I see. Looks like it has yet to be picked up...

The patches aren't quite identical -- Andrew's leaves the
disable_irq() call in and Aisheng's removes it. Which should I take?

Thanks,

- Chris.
--
Chris Ball <chris@printf.net> <http://printf.net/>
--
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: net: rfkill: gpio: add device tree support
http://groups.google.com/group/linux.kernel/t/502551497c79a009?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 17 2014 3:20 pm
From: Linus Walleij


On Fri, Jan 17, 2014 at 6:43 PM, Chen-Yu Tsai <wens@csie.org> wrote:
> On Sat, Jan 18, 2014 at 12:47 AM, Arnd Bergmann <arnd@arndb.de> wrote:

>>> +- NAME_shutdown-gpios : GPIO phandle to shutdown control
>>> + (phandle must be the second)
>>> +- NAME_reset-gpios : GPIO phandle to reset control
>>> +
>>> +NAME must match the rfkill-name property. NAME_shutdown-gpios or
>>> +NAME_reset-gpios, or both, must be defined.
>>> +
>>
>> I don't understand this part. Why do you include the name in the
>> gpios property, rather than just hardcoding the property strings
>> to "shutdown-gpios" and "reset-gpios"?
>
> This quirk is a result of how gpiod_get_index implements device tree
> lookup.

Why can't it just have a single property "gpios", where the first
element is the reset GPIO and the second is the shutdown GPIO?

rfkill-gpio does this:

gpio = devm_gpiod_get_index(&pdev->dev, rfkill->reset_name, 0);
gpio = devm_gpiod_get_index(&pdev->dev, rfkill->shutdown_name, 1);

The passed con ID name parameter is only there for the device
tree case it seems. (ACPI ignores it.) So what about you just
don't pass it at all and patch it to do like this instead:

gpio = devm_gpiod_get_index(&pdev->dev, NULL, 0);
gpio = devm_gpiod_get_index(&pdev->dev, NULL, 1);

Heikki, are you OK with this change?

I think this is actually necessary if the ACPI and DT unification
pipe dream shall limp forward, we cannot have arguments passed
that have a semantic effect on DT but not on ACPI... Drivers
that are supposed to use both ACPI and DT will always
have to pass NULL as con ID.

> If con_id is given, it is prepended to "gpios" as the property string.
> con_id is also used as the label passed to gpiod_request, which is
> then shown in /sys/kernel/debug/gpio.

If your problem is really what turns up in debugfs, then we need
to figure out a way to label gpios outside of the *gpiod_get* calls.

The string passed in *gpiod_get* is a "connection ID" not a proper
name for the GPIO.

Yours,
Linus Walleij
--
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: pinctrl: capri: add dependency on OF
http://groups.google.com/group/linux.kernel/t/bcdbebbdc79aee31?hl=en
==============================================================================

== 1 of 3 ==
Date: Fri, Jan 17 2014 3:20 pm
From: Linus Walleij


On Sat, Jan 18, 2014 at 12:12 AM, Linus Walleij
<linus.walleij@linaro.org> wrote:
> On Fri, Jan 17, 2014 at 8:51 PM, Sherman Yin <syin@broadcom.com> wrote:
>
>> Thanks for the fix, Linus. While we're visiting this config, should we add
>> "depends on MACH_BCM_MOBILE" as well?
>
> No, it's nice to get the compile coverage.

But maybe you can experiment with that special option that only
turns on the driver on other platforms to do compile test.

Yours,
Linus Walleij
--
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 3 ==
Date: Fri, Jan 17 2014 3:20 pm
From: Linus Walleij


On Fri, Jan 17, 2014 at 8:51 PM, Sherman Yin <syin@broadcom.com> wrote:

> Thanks for the fix, Linus. While we're visiting this config, should we add
> "depends on MACH_BCM_MOBILE" as well?

No, it's nice to get the compile coverage.

Yours,
Linus Walleij
--
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 3 ==
Date: Fri, Jan 17 2014 3:30 pm
From: Stephen Warren


On 01/17/2014 04:13 PM, Linus Walleij wrote:
> On Sat, Jan 18, 2014 at 12:12 AM, Linus Walleij
> <linus.walleij@linaro.org> wrote:
>> On Fri, Jan 17, 2014 at 8:51 PM, Sherman Yin <syin@broadcom.com> wrote:
>>
>>> Thanks for the fix, Linus. While we're visiting this config, should we add
>>> "depends on MACH_BCM_MOBILE" as well?
>>
>> No, it's nice to get the compile coverage.
>
> But maybe you can experiment with that special option that only
> turns on the driver on other platforms to do compile test.

a/k/a
depends on XXX || COMPILE_TEST
--
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: x86, CPU, AMD: Add workaround for family 16h, erratum 793
http://groups.google.com/group/linux.kernel/t/0e4150592fc82fa1?hl=en
==============================================================================

== 1 of 3 ==
Date: Fri, Jan 17 2014 4:30 pm
From: Pavel Machek


On Fri 2014-01-17 14:51:52, H. Peter Anvin wrote:
> On 01/17/2014 02:50 PM, Borislav Petkov wrote:
> > On Fri, Jan 17, 2014 at 11:28:06PM +0100, Pavel Machek wrote:
> >> Would it make sense to printk() a warning?
> >
> > No because people come and start bitching about their dmesg containing
> > a warning and whether their hardware is b0rked without even reading the
> > actual words.

Have you checked your dmesg recently? Normal people don't read
it... it is just too much of it.

> Printing a warning is appropriate if we can't actually fix the problem
> in the OS. If we actually make the problem go away then we have just
> done our job and we can be done with it.

I disagree. Older kernel versions still may have problem, etc.

We normally do print warnings for problems we work around. We want
vendors to fix their hardware, too...

ACPI BIOS Warning (bug): 32/64X FACS address mismatch in FADT -
0xBDB5FF40/0x00000000BDB64F40, using 32 (20131115/tbfadt-522)
[Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored

Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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 3 ==
Date: Fri, Jan 17 2014 5:30 pm
From: "H. Peter Anvin"


On 01/17/2014 04:29 PM, Pavel Machek wrote:
>
> Have you checked your dmesg recently? Normal people don't read
> it... it is just too much of it.
>
>> Printing a warning is appropriate if we can't actually fix the problem
>> in the OS. If we actually make the problem go away then we have just
>> done our job and we can be done with it.
>
> I disagree. Older kernel versions still may have problem, etc.
>
> We normally do print warnings for problems we work around. We want
> vendors to fix their hardware, too...
>
> ACPI BIOS Warning (bug): 32/64X FACS address mismatch in FADT -
> 0xBDB5FF40/0x00000000BDB64F40, using 32 (20131115/tbfadt-522)
> [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
>

You say people don't read their dmesg...
... because there is too much ...
... so let's add more?

What am I missing here?

-hpa


--
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 3 ==
Date: Fri, Jan 17 2014 6:10 pm
From: Pavel Machek


On Fri 2014-01-17 17:21:00, H. Peter Anvin wrote:
> On 01/17/2014 04:29 PM, Pavel Machek wrote:
> >
> > Have you checked your dmesg recently? Normal people don't read
> > it... it is just too much of it.
> >
> >> Printing a warning is appropriate if we can't actually fix the problem
> >> in the OS. If we actually make the problem go away then we have just
> >> done our job and we can be done with it.
> >
> > I disagree. Older kernel versions still may have problem, etc.
> >
> > We normally do print warnings for problems we work around. We want
> > vendors to fix their hardware, too...
> >
> > ACPI BIOS Warning (bug): 32/64X FACS address mismatch in FADT -
> > 0xBDB5FF40/0x00000000BDB64F40, using 32 (20131115/tbfadt-522)
> > [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
> >
>
> You say people don't read their dmesg...
> ... because there is too much ...
> ... so let's add more?

I'd say that proposed "your bios has a bug" is way more useful than
stuff such as:

pci_bus 0000:00: root bus resource [bus 00-ff]
pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7]
pci_bus 0000:00: root bus resource [io 0x0d00-0xffff]
pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
pci_bus 0000:00: root bus resource [mem 0xc0000000-0xffffffff]
pci 0000:00:00.0: [8086:2e30] type 00 class 0x060000
pci 0000:00:01.0: [8086:2e31] type 01 class 0x060400
pci 0000:00:01.0: PME# supported from D0 D3hot D3cold
pci 0000:00:01.0: System wakeup disabled by ACPI
pci 0000:00:02.0: [8086:2e32] type 00 class 0x030000
pci 0000:00:02.0: reg 0x10: [mem 0xd0000000-0xd03fffff 64bit]
pci 0000:00:02.0: reg 0x18: [mem 0xc0000000-0xcfffffff 64bit pref]
pci 0000:00:02.0: reg 0x20: [io 0xf140-0xf147]
pci 0000:00:02.1: [8086:2e33] type 00 class 0x038000
pci 0000:00:02.1: reg 0x10: [mem 0xd0400000-0xd04fffff 64bit]
pci 0000:00:1b.0: [8086:27d8] type 00 class 0x040300
pci 0000:00:1b.0: reg 0x10: [mem 0xd0600000-0xd0603fff 64bit]
pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold
pci 0000:00:1c.0: [8086:27d0] type 01 class 0x060400
pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
pci 0000:00:1c.0: System wakeup disabled by ACPI
pci 0000:00:1c.1: [8086:27d2] type 01 class 0x060400
pci 0000:00:1c.1: PME# supported from D0 D3hot D3cold
pci 0000:00:1c.1: System wakeup disabled by ACPI
pci 0000:00:1d.0: [8086:27c8] type 00 class 0x0c0300
pci 0000:00:1d.0: reg 0x20: [io 0xf080-0xf09f]
pci 0000:00:1d.0: System wakeup disabled by ACPI

So yes. Lets add useful stuff.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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: mtd: block2mtd: char mtd major and erasesize parameter check + mutex_
destroy
http://groups.google.com/group/linux.kernel/t/5b75aa23cf74312b?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 17 2014 4:30 pm
From: Fabian Frederick


-Deny use of a char mtd device to map as block device.
-mutex_init when mtd structure is available.
-fixme applied : check device size is a multiple of erasesize.
-mutex_destroy on each device in block2mtd_exit and add_device failure.

Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
drivers/mtd/devices/block2mtd.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/devices/block2mtd.c b/drivers/mtd/devices/block2mtd.c
index d9fd87a..be67731 100644
--- a/drivers/mtd/devices/block2mtd.c
+++ b/drivers/mtd/devices/block2mtd.c
@@ -209,7 +209,6 @@ static void block2mtd_free_device(struct block2mtd_dev *dev)
}


-/* FIXME: ensure that mtd->size % erase_size == 0 */
static struct block2mtd_dev *add_device(char *devname, int erase_size)
{
const fmode_t mode = FMODE_READ | FMODE_WRITE | FMODE_EXCL;
@@ -244,21 +243,27 @@ static struct block2mtd_dev *add_device(char *devname, int erase_size)
}
dev->blkdev = bdev;

- if (MAJOR(bdev->bd_dev) == MTD_BLOCK_MAJOR) {
+ if ((MAJOR(bdev->bd_dev) == MTD_BLOCK_MAJOR) ||
+ (MAJOR(bdev->bd_dev) == MTD_CHAR_MAJOR)) {
pr_err("attempting to use an MTD device as a block device\n");
goto devinit_err;
}

- mutex_init(&dev->write_mutex);

/* Setup the MTD structure */
/* make the name contain the block device in */
name = kasprintf(GFP_KERNEL, "block2mtd: %s", devname);
+
if (!name)
goto devinit_err;
+
+ if ((long)dev->blkdev->bd_inode->i_size % erase_size) {
+ pr_err("erasesize must be a divisor of device size\n");
+ goto devinit_err;
+ }

+ mutex_init(&dev->write_mutex);
dev->mtd.name = name;
-
dev->mtd.size = dev->blkdev->bd_inode->i_size & PAGE_MASK;
dev->mtd.erasesize = erase_size;
dev->mtd.writesize = 1;
@@ -274,7 +279,7 @@ static struct block2mtd_dev *add_device(char *devname, int erase_size)

if (mtd_device_register(&dev->mtd, NULL, 0)) {
/* Device didn't get added, so free the entry */
- goto devinit_err;
+ goto register_err;
}
list_add(&dev->list, &blkmtd_device_list);
pr_info("mtd%d: [%s] erase_size = %dKiB [%d]\n",
@@ -283,6 +288,8 @@ static struct block2mtd_dev *add_device(char *devname, int erase_size)
dev->mtd.erasesize >> 10, dev->mtd.erasesize);
return dev;

+register_err:
+ mutex_destroy(&dev->write_mutex);
devinit_err:
block2mtd_free_device(dev);
return NULL;
@@ -448,6 +455,7 @@ static void block2mtd_exit(void)
struct block2mtd_dev *dev = list_entry(pos, typeof(*dev), list);
block2mtd_sync(&dev->mtd);
mtd_device_unregister(&dev->mtd);
+ mutex_destroy(&dev->write_mutex);
pr_info("mtd%d: [%s] removed\n",
dev->mtd.index,
dev->mtd.name + strlen("block2mtd: "));
--
1.8.1.4
--
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: crypto: Simple crypto algorithm load balancer
http://groups.google.com/group/linux.kernel/t/5983996c9887b6ad?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 17 2014 4:50 pm
From: Tadeusz Struk


Hi,
In case of multiple crypto devices implementing the same algorithms
the arbitration, which one to use is based on the cra_priority.
Currently the algorithm with the highest priority is always be used.
In case of two algorithms with the same priority the one added last is used.
There is no load balancing and on a busy system there can be a situation when
there more crypto accelerators, but only one is used for all crypto jobs
and the others sit idle.
This patch implements a simple load balancing based on the priority
of an algorithm and its usage refctr. The distribution for 10 algorithms
and 3000000 tfm_alloc allocations is as follows:

=== Algorithm load balancig test results for 3000000 allocatoins ===
All different alg priorities:
Algorithm 1 with cra_pri 1 allocated 3 times. That's ~0%
Algorithm 2 with cra_pri 2 allocated 10 times. That's ~0%
Algorithm 3 with cra_pri 3 allocated 38 times. That's ~0%
Algorithm 4 with cra_pri 4 allocated 168 times. That's ~0%
Algorithm 5 with cra_pri 5 allocated 781 times. That's ~0%
Algorithm 6 with cra_pri 6 allocated 3757 times. That's ~0%
Algorithm 7 with cra_pri 7 allocated 18483 times. That's ~0%
Algorithm 8 with cra_pri 8 allocated 92540 times. That's ~3%
Algorithm 9 with cra_pri 9 allocated 469918 times. That's ~15%
Algorithm 10 with cra_pri 10 allocated 2414312 times. That's ~80%

All the same alg priorities:
Algorithm 1 with cra_pri 10 allocated 297521 times. That's ~9%
Algorithm 2 with cra_pri 10 allocated 297521 times. That's ~9%
Algorithm 3 with cra_pri 10 allocated 297521 times. That's ~9%
Algorithm 4 with cra_pri 10 allocated 297522 times. That's ~9%
Algorithm 5 with cra_pri 10 allocated 297522 times. That's ~9%
Algorithm 6 with cra_pri 10 allocated 297522 times. That's ~9%
Algorithm 7 with cra_pri 10 allocated 297522 times. That's ~9%
Algorithm 8 with cra_pri 10 allocated 297522 times. That's ~9%
Algorithm 9 with cra_pri 10 allocated 297522 times. That's ~9%
Algorithm 10 with cra_pri 10 allocated 297522 times. That's ~9%

A mix of alg priorities:
Algorithm 1 with cra_pri 9 allocated 1938 times. That's ~0%
Algorithm 2 with cra_pri 4 allocated 8 times. That's ~0%
Algorithm 3 with cra_pri 1 allocated 2 times. That's ~0%
Algorithm 4 with cra_pri 4 allocated 9 times. That's ~0%
Algorithm 5 with cra_pri 5 allocated 62 times. That's ~0%
Algorithm 6 with cra_pri 20 allocated 157052 times. That's ~5%
Algorithm 7 with cra_pri 21 allocated 1410070 times. That's ~47%
Algorithm 8 with cra_pri 10 allocated 10215 times. That's ~0%
Algorithm 9 with cra_pri 21 allocated 1420284 times. That's ~47%
Algorithm 10 with cra_pri 7 allocated 370 times. That's ~0%

A mix of alg priorities with one very big:
Algorithm 1 with cra_pri 9 allocated 6 times. That's ~0%
Algorithm 2 with cra_pri 4 allocated 1 times. That's ~0%
Algorithm 3 with cra_pri 1 allocated 1 times. That's ~0%
Algorithm 4 with cra_pri 4 allocated 1 times. That's ~0%
Algorithm 5 with cra_pri 500 allocated 2993808 times. That's ~99%
Algorithm 6 with cra_pri 20 allocated 346 times. That's ~0%
Algorithm 7 with cra_pri 21 allocated 2899 times. That's ~0%
Algorithm 8 with cra_pri 10 allocated 23 times. That's ~0%
Algorithm 9 with cra_pri 21 allocated 2922 times. That's ~0%
Algorithm 10 with cra_pri 7 allocated 3 times. That's ~0%

Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
---
crypto/api.c | 25 ++++++++++++++++++++++---
include/linux/crypto.h | 3 ++-
2 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/crypto/api.c b/crypto/api.c
index a2b39c5..0c0f1c3 100644
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -63,7 +63,7 @@ static struct crypto_alg *__crypto_alg_lookup(const char *name, u32 type,
int best = -2;

list_for_each_entry(q, &crypto_alg_list, cra_list) {
- int exact, fuzzy;
+ int exact, fuzzy, relative_priority;

if (crypto_is_moribund(q))
continue;
@@ -78,13 +78,15 @@ static struct crypto_alg *__crypto_alg_lookup(const char *name, u32 type,

exact = !strcmp(q->cra_driver_name, name);
fuzzy = !strcmp(q->cra_name, name);
- if (!exact && !(fuzzy && q->cra_priority > best))
+ relative_priority = q->cra_priority -
+ atomic_read(&q->cra_lbalance);
+ if (!exact && !(fuzzy && relative_priority > best))
continue;

if (unlikely(!crypto_mod_get(q)))
continue;

- best = q->cra_priority;
+ best = relative_priority;
if (alg)
crypto_mod_put(alg);
alg = q;
@@ -92,6 +94,23 @@ static struct crypto_alg *__crypto_alg_lookup(const char *name, u32 type,
if (exact)
break;
}
+ if (!alg) {
+ list_for_each_entry(q, &crypto_alg_list, cra_list) {
+ int best = -2;
+ if (best < q->cra_priority) {
+ alg = q;
+ best = q->cra_priority;
+ }
+ atomic_set(&q->cra_lbalance, 0);
+ }
+ }
+ atomic_inc(&alg->cra_lbalance);
+ list_for_each_entry(q, &crypto_alg_list, cra_list) {
+ if (alg == q)
+ continue;
+ if (q->cra_priority > alg->cra_priority)
+ atomic_set(&q->cra_lbalance, 0);
+ }

return alg;
}
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index b92eadf..6c24b27 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -288,6 +288,7 @@ struct crypto_alg {

int cra_priority;
atomic_t cra_refcnt;
+ atomic_t cra_lbalance;

char cra_name[CRYPTO_MAX_ALG_NAME];
char cra_driver_name[CRYPTO_MAX_ALG_NAME];
@@ -306,7 +307,7 @@ struct crypto_alg {
int (*cra_init)(struct crypto_tfm *tfm);
void (*cra_exit)(struct crypto_tfm *tfm);
void (*cra_destroy)(struct crypto_alg *alg);
-
+
struct module *cra_module;
};

--
1.7.10.4

--
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: crypto: Simple load balancer test module
http://groups.google.com/group/linux.kernel/t/a990e4ce630270d8?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 17 2014 4:50 pm
From: Tadeusz Struk


Test module for the simple algorithm load balancer

Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
---
crypto/Kconfig | 6 ++
crypto/Makefile | 1 +
crypto/test_alg_loadbalance.c | 231 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 247 insertions(+)
create mode 100644 crypto/test_alg_loadbalance.c

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 7bcb70d..85e1bc2 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1404,6 +1404,12 @@ config CRYPTO_USER_API_SKCIPHER
config CRYPTO_HASH_INFO
bool

+config CRYPTO_ALG_LOAD_BALANCE_TEST
+ tristate "Crypto Algorithm load balancer test module"
+ default n
+ help
+ This option enables the crypto algorithm load balancer test module.
+
source "drivers/crypto/Kconfig"
source crypto/asymmetric_keys/Kconfig

diff --git a/crypto/Makefile b/crypto/Makefile
index b29402a..5a49e2a 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -97,6 +97,7 @@ obj-$(CONFIG_CRYPTO_GHASH) += ghash-generic.o
obj-$(CONFIG_CRYPTO_USER_API) += af_alg.o
obj-$(CONFIG_CRYPTO_USER_API_HASH) += algif_hash.o
obj-$(CONFIG_CRYPTO_USER_API_SKCIPHER) += algif_skcipher.o
+obj-$(CONFIG_CRYPTO_ALG_LOAD_BALANCE_TEST) += test_alg_loadbalance.o

#
# generic algorithms and the async_tx api
diff --git a/crypto/test_alg_loadbalance.c b/crypto/test_alg_loadbalance.c
new file mode 100644
index 0000000..2637247
--- /dev/null
+++ b/crypto/test_alg_loadbalance.c
@@ -0,0 +1,231 @@
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ */
+
+#include <linux/err.h>
+#include <linux/module.h>
+#include <linux/crypto.h>
+#include <linux/string.h>
+#include <crypto/algapi.h>
+
+static int encrypt(struct blkcipher_desc *desc, struct scatterlist *dst,
+ struct scatterlist *src, unsigned int nbytes)
+{
+ return 0;
+}
+static int setkey(struct crypto_tfm *tfm, const u8 *key, unsigned int keylen)
+{
+ return 0;
+}
+
+
+#define loops 3000000
+static struct crypto_ablkcipher *tfms[loops];
+
+static struct crypto_alg tmp = {
+ .cra_name = "test",
+ .cra_driver_name = "test_driver",
+ .cra_priority = 1,
+ .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER,
+ .cra_module = THIS_MODULE,
+ .cra_ctxsize = 0,
+ .cra_type = &crypto_blkcipher_type,
+ .cra_u = {
+ .blkcipher = {
+ .min_keysize = 64,
+ .max_keysize = 64,
+ .ivsize = 64,
+ .setkey = setkey,
+ .encrypt = encrypt,
+ .decrypt = encrypt,
+ },
+ },
+ };
+static struct crypto_alg algs[10] = {
+ { { 0 } },
+ { { 0 } },
+ { { 0 } },
+ { { 0 } },
+ { { 0 } },
+ { { 0 } },
+ { { 0 } },
+ { { 0 } },
+ { { 0 } },
+ { { 0 } },
+};
+
+static int __init cra_lbtest_init(void)
+{
+ int i;
+
+ for (i = 0; i < 10; i++) {
+ algs[i] = tmp;
+ algs[i].cra_priority += i;
+ }
+
+ if (crypto_register_algs(algs, 10))
+ return -1;
+
+ for (i = 0; i < loops; i++) {
+ tfms[i] = crypto_alloc_ablkcipher("test", 0, 0);
+ if (IS_ERR(tfms[i]))
+ return PTR_ERR(tfms[i]);
+ }
+ pr_info("Algorithm load balancig test results for %d allocatoins\n",
+ loops);
+ pr_info("All different alg priorities:\n");
+ for (i = 0; i < 10; i++) {
+ unsigned long times = atomic_read(&algs[i].cra_refcnt);
+ unsigned long percent = (times * 100) / loops;
+
+ pr_info("Alg with cra_pri %d allocated %lu times. That's ~%lu%%\n",
+ algs[i].cra_priority, times, percent);
+
+ }
+ for (i = 0; i < loops; i++)
+ crypto_free_ablkcipher(tfms[i]);
+
+ crypto_unregister_algs(algs, 10);
+
+ for (i = 0; i < 10; i++) {
+ algs[i] = tmp;
+ algs[i].cra_priority = 10;
+ }
+ if (crypto_register_algs(algs, 10))
+ return -1;
+
+ for (i = 0; i < loops; i++) {
+ tfms[i] = crypto_alloc_ablkcipher("test", 0, 0);
+ if (IS_ERR(tfms[i]))
+ return PTR_ERR(tfms[i]);
+ }
+ pr_info("All same alg priorities:\n");
+ for (i = 0; i < 10; i++) {
+ unsigned long times = atomic_read(&algs[i].cra_refcnt);
+ unsigned long percent = (times * 100) / loops;
+
+ pr_info("Alg with cra_pri %d allocated %lu times. That's ~%lu%%\n",
+ algs[i].cra_priority, times, percent);
+ }
+ for (i = 0; i < loops; i++)
+ crypto_free_ablkcipher(tfms[i]);
+
+ crypto_unregister_algs(algs, 10);
+
+ for (i = 0; i < 10; i++)
+ algs[i] = tmp;
+
+ algs[0].cra_priority = 9;
+ algs[1].cra_priority = 4;
+ algs[2].cra_priority = 1;
+ algs[3].cra_priority = 4;
+ algs[4].cra_priority = 5;
+ algs[5].cra_priority = 20;
+ algs[6].cra_priority = 21;
+ algs[7].cra_priority = 10;
+ algs[8].cra_priority = 21;
+ algs[9].cra_priority = 7;
+
+ if (crypto_register_algs(algs, 10))
+ return -1;
+
+ for (i = 0; i < loops; i++) {
+ tfms[i] = crypto_alloc_ablkcipher("test", 0, 0);
+ if (IS_ERR(tfms[i]))
+ return PTR_ERR(tfms[i]);
+ }
+ pr_info("A mix alg priorities:\n");
+ for (i = 0; i < 10; i++) {
+ unsigned long times = atomic_read(&algs[i].cra_refcnt);
+ unsigned long percent = (times * 100) / loops;
+
+ pr_info("Alg with cra_pri %d allocated %lu times. That's ~%lu%%\n",
+ algs[i].cra_priority, times, percent);
+ }
+ for (i = 0; i < loops; i++)
+ crypto_free_ablkcipher(tfms[i]);
+ crypto_unregister_algs(algs, 10);
+
+ for (i = 0; i < 10; i++)
+ algs[i] = tmp;
+
+ algs[0].cra_priority = 9;
+ algs[1].cra_priority = 4;
+ algs[2].cra_priority = 1;
+ algs[3].cra_priority = 4;
+ algs[4].cra_priority = 500;
+ algs[5].cra_priority = 20;
+ algs[6].cra_priority = 21;
+ algs[7].cra_priority = 10;
+ algs[8].cra_priority = 21;
+ algs[9].cra_priority = 7;
+
+ if (crypto_register_algs(algs, 10))
+ return -1;
+
+ for (i = 0; i < loops; i++) {
+ tfms[i] = crypto_alloc_ablkcipher("test", 0, 0);
+ if (IS_ERR(tfms[i]))
+ return PTR_ERR(tfms[i]);
+ }
+ pr_info("A mix alg priorities with one very big:\n");
+ for (i = 0; i < 10; i++) {
+ unsigned long times = atomic_read(&algs[i].cra_refcnt);
+ unsigned long percent = (times * 100) / loops;
+
+ pr_info("Alg with cra_pri %d allocated %lu times. That's ~%lu%%\n",
+ algs[i].cra_priority, times, percent);
+ }
+
+ for (i = 0; i < loops; i++)
+ crypto_free_ablkcipher(tfms[i]);
+
+ crypto_unregister_algs(algs, 10);
+
+ pr_info("And lastly only one of a given alg:\n");
+ strcpy(tmp.cra_name, "TEST");
+
+ for (i = 0; i < 10; i++)
+ algs[i] = tmp;
+
+ strcpy(algs[0].cra_name, "test");
+
+ if (crypto_register_algs(algs, 10))
+ return -1;
+
+ for (i = 0; i < loops; i++) {
+ tfms[i] = crypto_alloc_ablkcipher("test", 0, 0);
+ if (IS_ERR(tfms[i]))
+ return PTR_ERR(tfms[i]);
+ }
+
+ for (i = 0; i < 10; i++) {
+
+ unsigned long times = atomic_read(&algs[i].cra_refcnt);
+ unsigned long percent = (times * 100) / loops;
+
+ pr_info("Alg with cra_pri %d allocated %lu times. That's ~%lu%%\n",
+ algs[i].cra_priority, times, percent);
+ }
+
+ for (i = 0; i < loops; i++)
+ crypto_free_ablkcipher(tfms[i]);
+
+ crypto_unregister_algs(algs, 10);
+ return 0;
+
+}
+
+static void __exit cra_lbtest_exit(void)
+{
+ crypto_unregister_algs(algs, 10);
+}
+
+module_init(cra_lbtest_init);
+module_exit(cra_lbtest_exit);
+MODULE_DESCRIPTION("Crypto Algorithm load balancer test module");
+MODULE_LICENSE("GPL");
--
1.7.10.4

--
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: Deadlock in do_page_fault() on ARM (old kernel)
http://groups.google.com/group/linux.kernel/t/d3fb0c69a17cc5a5?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Jan 17 2014 5:00 pm
From: Alan Ott


On 01/17/2014 08:46 AM, Russell King - ARM Linux wrote:
> On Wed, Jan 15, 2014 at 08:13:04PM -0500, Alan Ott wrote:
>> So my questions are:
>> 1. Why don't I see a full backtrace beyond the exception stack? It's the
>> same when dump_stack() is called manually.
> No idea - it looks like you're not using frame pointers, but are using
> the unwinder. Full backtraces can always be created with frame pointers,
> it's just that unwinding seems unreliable.

Hi Russell,

I managed to get frame pointers turned on, which in this kernel version,
seems like it requires the unwinder to be turned off[1].

When I built with frame pointers, the backtraces show differently. It
only shows the frames which were _not_ shown with the unwinder.
Backtrace at [2]. As you can see, it shows the non-exception stack dumps
ending at places which can't page fault (and if it did page fault in
those locations, it wouldn't try to take the mmap_sem lock). Its as
though it shows what's in the modules but not what's in the image, where
with the unwinder, it showed what's in the image and not what's in the
modules[3].

> I think we do need to see the full backtrace here - from looking at the
> full state dump, I don't see any sign of the mmap_sem being held except
> by an attempt to process a fault, and two threads trying to do a
> sys_mmap_pgoff().

The lockdep printout at the end of [4] (which is the original log I sent
the other day) shows do_page_fault() holding mmap_sem in six tasks and
sys_mmap_pgoff() holding it in two. (I don't like the term "held" in the
lockdep printout and believe it to mean "held or waiting for," based on
my analysis of the rw_semaphore code.)

Each of those tasks seems to be blocking for it.

> My suspicion therefore is that some other thread must have died while
> holding the mmap_sem, so there's probably a kernel oops earlier...
> that's my best guess at the moment without seeing the full backtrace.

There's no oops that I'm able to see.

Each of the tasks which lockdep reports as "holding" mmap_sem are
blocking for it. If some other task had taken it and then crashed, I
assume lockdep would list the crashed task as also holding the resource
in the printout.

Thanks for having a look at this,

Alan.

[1] It seems a little strange to me even in the newest kernel:
1: lib/Kconfig.debug specifies FRAME_POINTER . The text of this instance
shows up when one searches for FRAME_POINTER in menuconfig. It can
become selected even though the dependencies listed here are not met.
2: arch/arm/Kconfig.debug also specifies FRAME_POINTER, with a
dependency only on !THUMB2_KERNEL, defaulting to yes on !ARM_UNWIND
3: ARM doens't set ARCH_WANT_FRAME_POINTERS

[2] http://www.signal11.us/~alan/stack_dump_with_frame_pointers.txt
Note: This is a sysrq dump of the locks held at lockup time and then the
automatic hung task detection.

[3] The modules are being built in the standard way for out-of-tree:
$(MAKE) -C $(PRJDIR)/linux M=$(CWD) modules

[4] http://www.signal11.us/~alan/show-all-tasks-deadlock.txt


--
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: Fri, Jan 17 2014 5:30 pm
From: Russell King - ARM Linux


On Fri, Jan 17, 2014 at 07:57:16PM -0500, Alan Ott wrote:
> On 01/17/2014 08:46 AM, Russell King - ARM Linux wrote:
>> My suspicion therefore is that some other thread must have died while
>> holding the mmap_sem, so there's probably a kernel oops earlier...
>> that's my best guess at the moment without seeing the full backtrace.
>
> There's no oops that I'm able to see.
>
> Each of the tasks which lockdep reports as "holding" mmap_sem are
> blocking for it. If some other task had taken it and then crashed, I
> assume lockdep would list the crashed task as also holding the resource
> in the printout.

My point is this:

- the five (or six) threads which are trying to take the mmap_sem in
read-mode in the fault handler are all blocked on it - they haven't
taken the lock, which will only happen because there's a pending writer.
- of these in your original post, there are two which faulted from
__copy_to_user_std(). __copy_to_user_std() doesn't take the mmap_sem -
this is the non-uaccess-with-memcpy path.
- the pending writers are the two threads in sys_mmap_pgoff(), both of
which are blocked waiting to gain the write lock.
- there are no *other* threads holding the mmap_sem lock.

So... there's a question here how we got into this state - and frankly
I don't know. What I do see from your latest dump is that there's two
unknown modules there - something called rcu2m and another called
buttoms, and there are two threads inside ioctls there. Both have
faulted from the function at 0xc0d2a394 (which won't appear in the
backtrace, but is most likely __copy_to_user_std.)

So, in the absence of you saying anything about there being any preceding
oopses, my conclusion now is that one of those modules is taking the
mmap_sem itself, and is the culpret inducing this deadlock.

Note that your dump ([2]) in your reply was just the hung task detector
printing out the stacktrace for a few tasks, not the full all-threads
stack dump which I was expecting.

So I'm pulling out these conclusions from the very little information
you're supplying.

--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
--
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: dt-bindings: qcom: Fix warning with duplicate dt define
http://groups.google.com/group/linux.kernel/t/07e77d0db06e0e58?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 17 2014 5:10 pm
From: Stephen Boyd


arch/arm/boot/dts/include/dt-bindings/clock/qcom,mmcc-msm8974.h:60:0:
warning: "RBCPR_CLK_SRC" redefined

Rename this to MMSS_RBCPR_CLK_SRC to avoid conflicts with the
RBCPR clock in the gcc header.

Reported-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
include/dt-bindings/clock/qcom,mmcc-msm8974.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/dt-bindings/clock/qcom,mmcc-msm8974.h b/include/dt-bindings/clock/qcom,mmcc-msm8974.h
index 04d318d1187a..032ed87ef0f3 100644
--- a/include/dt-bindings/clock/qcom,mmcc-msm8974.h
+++ b/include/dt-bindings/clock/qcom,mmcc-msm8974.h
@@ -57,7 +57,7 @@
#define EXTPCLK_CLK_SRC 40
#define HDMI_CLK_SRC 41
#define VSYNC_CLK_SRC 42
-#define RBCPR_CLK_SRC 43
+#define MMSS_RBCPR_CLK_SRC 43
#define CAMSS_CCI_CCI_AHB_CLK 44
#define CAMSS_CCI_CCI_CLK 45
#define CAMSS_CSI0_AHB_CLK 46
--
The Qualcomm Innovation Center, Inc. is a member of the 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: cgroup: make CONFIG_NET_CLS_CGROUP and CONFIG_NETPRIO_CGROUP bool
instead of tristate
http://groups.google.com/group/linux.kernel/t/3a3c8584cdd64136?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 17 2014 5:10 pm
From: Li Zefan


Cc: Daniel Borkmann <dborkman@redhat.com>

On 2014/1/18 2:11, Tejun Heo wrote:
> net_cls and net_prio are the only cgroups which are allowed to be
> built as modules. The savings from allowing the two controllers to be
> built as modules are tiny especially given that cgroup module support
> itself adds quite a bit of complexity.
>
> The following are the sizes of vmlinux with both built as module and
> both built as part of the kernel image with cgroup module support
> removed.
>
> text data bss dec
> 20292207 2411496 10784768 33488471
> 20293421 2412568 10784768 33490757
>
> The total difference is 2286 bytes. Given that none of other
> controllers has much chance of being made a module and that we're
> unlikely to add new modular controllers, the added complexity is
> simply not justifiable.
>
> As a first step to drop cgroup module support, this patch changes the
> two config options to bool from tristate and drops module related code
> from the two controllers.
>

I sugguested Daniel to do this for net_cls, and the change has been in
net-next.

https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=fe1217c4f3f7d7cbf8efdd8dd5fdc7204a1d65a8

I was planning to remove module support after that change goes into
upstream. :)

> Signed-off-by: Tejun Heo <tj@kernel.org>
> Cc: Neil Horman <nhorman@tuxdriver.com>
> Cc: Thomas Graf <tgraf@suug.ch>
> Cc: "David S. Miller" <davem@davemloft.net>
> ---
> net/Kconfig | 2 +-
> net/core/netprio_cgroup.c | 32 ++------------------------------
> net/sched/Kconfig | 2 +-
> net/sched/cls_cgroup.c | 23 ++---------------------
> 4 files changed, 6 insertions(+), 53 deletions(-)
>

The modular version of task_netprioidx() in include/net/netprio_cgroup.h
can be removed.

--
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: fs: don't write pages when receiving a pending SIGKILL in __get_user_
pages()
http://groups.google.com/group/linux.kernel/t/38a356209f5ec559?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 17 2014 5:30 pm
From: Xishi Qiu


In the process IO direction, dio_refill_pages will call get_user_pages_fast
to map the page from user space. If ret is less than 0 and IO is write, the
function will create a zero page to fill data. This may work for some file
system, but in some device operate we prefer whole write or fail, not half
data half zero, e.g. fs metadata, like inode, identy.
This happens often when kill a process which is doing direct IO. Consider
the following cases, the process A is doing IO process, may enter __get_user_pages
function, if other processes send process A SIG_KILL, A will enter the
following branches
/*
* If we have a pending SIGKILL, don't keep faulting
* pages and potentially allocating memory.
*/
if (unlikely(fatal_signal_pending(current)))
return i ? i : -ERESTARTSYS;
Return current pages. direct IO will write the pages, the subsequent pages
which can�t get will use zero page instead.

Signed-off-by: Xishi Qiu <qiuxishi@huawei.com>
Signed-off-by: Bin Yang <robin.yb@huawei.com>
---
fs/direct-io.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/fs/direct-io.c b/fs/direct-io.c
index 0e04142..b74d565 100644
--- a/fs/direct-io.c
+++ b/fs/direct-io.c
@@ -174,6 +174,9 @@ static inline int dio_refill_pages(struct dio *dio, struct dio_submit *sdio)
&dio->pages[0]); /* Put results here */

if (ret < 0 && sdio->blocks_available && (dio->rw & WRITE)) {
+ /* If task is killed, do not write anymore */
+ if (ret == -ERESTARTSYS)
+ goto out;
struct page *page = ZERO_PAGE(0);
/*
* A memory fault, but the filesystem has some outstanding
--
1.7.1



--
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: target fixes for v3.13
http://groups.google.com/group/linux.kernel/t/a05b90fd74d0ef51?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 17 2014 5:30 pm
From: Linus Torvalds


On Thu, Jan 16, 2014 at 4:09 PM, Nicholas A. Bellinger
<nab@linux-iscsi.org> wrote:
>
> This change allows the percpu_ida tag allocator to optionally use
> interruptible sleep that iscsi-target expects, while still leaving the
> functionality + interface for existing percpu_ida consumers unchanged.

I'm not pulling this. Passing in TASK_RUNNING to prepare_to_wait() is
insane (because if it ever were to actually wait, that would be a
bug), and afaik this would be the first time anybody ever does that.

Yes, yes, it may "work", but I'm not pulling that kind of hack just
before a release.

Quite frankly, it looks like you want to have a tristate argument ("no
wait", "wait interruptibly", "wait uninterruptibly") to that
percpu_ida_alloc() function. Fine. But dammit, using this kind of
hackery, and then having two *different* calling conventions (one
mis-using the gfp_t for legacy reasons, and one now using the task
state flags in odd ways) is just not acceptable.

Now, neither of those two is perfect, but I can see why you want to
use the task state ones to say which kind of interruptible you want..
But I really don't like suddenly having a
prepare_to_wait(TASK_RUNNING) caller without any discussion, and I
*really* don't like having two completely different models for this
hack.

So quite frankly, I'd much prefer:

- talk to the scheduler people, and make them aware of the fact that
you are going to pass in TASK_RUNNING to prepare_to_wait(). It works
with the code as-is, as long as you don't actually then wait.

- Don't do that wrapper function with a totally different calling
convention logic. Instead, just change all the callers explicitly.
From a quick look, you really only have a couple of cases:

(a) target/iscsi, which wants the new ternary argument

(b) vhost/scsi.c, which uses GFP_ATOMIC and can be changed to TASK_RUNNABLE

(c) block/blk-mq-tag.c, which already hates the current insane
thing, and uses __GFP_WAIT and (gfp & ~__GFP_WAIT) and other hacks,
and is obviously *very* aware of the internal hackery in the current
percpu_ida_alloc() argument. So I'm getting the feeling that that
whole thing might actually be *happier* with the TASK_xyz flags.

So I really think this needs cleanup, and that hacky "passing in
TASK_RUNNING to prepare_to_wait()" needs to be made official. And yes,
that implies that it's too late to try to push this through for 3.13,
this goes into the next merge window and can be backported.

Added the appropriate people to the Cc..

Linus
--
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: [v3.12][v3.13][Regression] EISA: Initialize device before its resources
http://groups.google.com/group/linux.kernel/t/bf9255ff181e65b5?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 17 2014 5:40 pm
From: Joseph Salisbury


On 01/17/2014 05:19 PM, Bjorn Helgaas wrote:
> On Fri, Jan 17, 2014 at 02:26:23PM -0500, Joseph Salisbury wrote:
>> On 01/17/2014 12:02 PM, Bjorn Helgaas wrote:
>>> On Thu, Jan 16, 2014 at 01:14:01PM -0500, Joseph Salisbury wrote:
>>>> On 01/16/2014 01:12 PM, Bjorn Helgaas wrote:
>>>>> On Thu, Jan 16, 2014 at 10:53 AM, Joseph Salisbury
>>>>> <joseph.salisbury@canonical.com> wrote:
>>>>>> Hi Bjorn,
>>>>>>
>>>>>> A kernel bug was opened against Ubuntu [0]. After a kernel bisect, it
>>>>>> was found the following commit introduced this bug:
>>>>> Sorry about that, and thanks for the report. Did you mean to include
>>>>> URL for the bug?
>>>> Yes, sorry about that:
>>>> http://pad.lv/1251816
>>> Hi Joseph,
>>>
>>> Can you attach the 3.8.0-32-generic config (the one matching the successful
>>> boot at https://launchpadlibrarian.net/156685076/BootDmesg.txt) to the bug?
>> I attached the config file to the bug:
>> https://launchpadlibrarian.net/162754666/config.common.ubuntu
>>
>> I also attached a tar file with the complete config directory for that
>> kernel version.
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1251816/+attachment/3951156/+files/raring-config.tar
> Thanks again. I attached the following reverts to launchpad. I screwed up
> when doing those EISA changes. I'd like to squeeze these into my v3.14
> merge request (probably early next week), so please test and let me know
> if this fixes the problem. I'm really sorry for the inconvenience.
>
> Bjorn
>
>
> Revert "EISA: Log device resources in dmesg"
>
> From: Bjorn Helgaas <bhelgaas@google.com>
>
> This reverts commit a2080d0c561c546d73cb8b296d4b7ca414e6860b.
>
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> ---
> drivers/eisa/eisa-bus.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/eisa/eisa-bus.c b/drivers/eisa/eisa-bus.c
> index 8842cde69177..1b86fe0c2e80 100644
> --- a/drivers/eisa/eisa-bus.c
> +++ b/drivers/eisa/eisa-bus.c
> @@ -288,7 +288,6 @@ static int __init eisa_request_resources(struct eisa_root_device *root,
> edev->res[i].flags = IORESOURCE_IO | IORESOURCE_BUSY;
> }
>
> - dev_printk(KERN_DEBUG, &edev->dev, "%pR\n", &edev->res[i]);
> if (request_resource(root->res, &edev->res[i]))
> goto failed;
> }
> Revert "EISA: Initialize device before its resources"
>
> From: Bjorn Helgaas <bhelgaas@google.com>
>
> This reverts commit 26abfeed4341872364386c6a52b9acef8c81a81a.
>
> In the eisa_probe() force_probe path, if we were unable to request slot
> resources (e.g., [io 0x800-0x8ff]), we skipped the slot with "Cannot
> allocate resource for EISA slot %d" before reading the EISA signature in
> eisa_init_device().
>
> Commit 26abfeed4341 moved eisa_init_device() earlier, so we tried to read
> the EISA signature before requesting the slot resources, and this caused
> hangs during boot.
>
> Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1251816
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> ---
> drivers/eisa/eisa-bus.c | 26 +++++++++++++++-----------
> 1 file changed, 15 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/eisa/eisa-bus.c b/drivers/eisa/eisa-bus.c
> index 1b86fe0c2e80..612afeaec3cb 100644
> --- a/drivers/eisa/eisa-bus.c
> +++ b/drivers/eisa/eisa-bus.c
> @@ -277,11 +277,13 @@ static int __init eisa_request_resources(struct eisa_root_device *root,
> }
>
> if (slot) {
> + edev->res[i].name = NULL;
> edev->res[i].start = SLOT_ADDRESS(root, slot)
> + (i * 0x400);
> edev->res[i].end = edev->res[i].start + 0xff;
> edev->res[i].flags = IORESOURCE_IO;
> } else {
> + edev->res[i].name = NULL;
> edev->res[i].start = SLOT_ADDRESS(root, slot)
> + EISA_VENDOR_ID_OFFSET;
> edev->res[i].end = edev->res[i].start + 3;
> @@ -327,19 +329,20 @@ static int __init eisa_probe(struct eisa_root_device *root)
> return -ENOMEM;
> }
>
> - if (eisa_init_device(root, edev, 0)) {
> + if (eisa_request_resources(root, edev, 0)) {
> + dev_warn(root->dev,
> + "EISA: Cannot allocate resource for mainboard\n");
> kfree(edev);
> if (!root->force_probe)
> - return -ENODEV;
> + return -EBUSY;
> goto force_probe;
> }
>
> - if (eisa_request_resources(root, edev, 0)) {
> - dev_warn(root->dev,
> - "EISA: Cannot allocate resource for mainboard\n");
> + if (eisa_init_device(root, edev, 0)) {
> + eisa_release_resources(edev);
> kfree(edev);
> if (!root->force_probe)
> - return -EBUSY;
> + return -ENODEV;
> goto force_probe;
> }
>
> @@ -362,11 +365,6 @@ static int __init eisa_probe(struct eisa_root_device *root)
> continue;
> }
>
> - if (eisa_init_device(root, edev, i)) {
> - kfree(edev);
> - continue;
> - }
> -
> if (eisa_request_resources(root, edev, i)) {
> dev_warn(root->dev,
> "Cannot allocate resource for EISA slot %d\n",
> @@ -375,6 +373,12 @@ static int __init eisa_probe(struct eisa_root_device *root)
> continue;
> }
>
> + if (eisa_init_device(root, edev, i)) {
> + eisa_release_resources(edev);
> + kfree(edev);
> + continue;
> + }
> +
> if (edev->state == (EISA_CONFIG_ENABLED | EISA_CONFIG_FORCED))
> enabled_str = " (forced enabled)";
> else if (edev->state == EISA_CONFIG_FORCED)
Thanks again for looking at this, Bjorn!

Yes, reverting commit 26abfeed4 does in fact resolve the bug. I already
built a test kernel, noted in comment #34:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1251816/comments/34

The original bug reporter tested the kernel to confirm it fixes the bug:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1251816/comments/36

Would it be also possible for you to request the revert in the stable
trees, in addition to 3.14?

Thanks,

Joe


--
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: ipv4_dst_destroy panic regression after 3.10.15
http://groups.google.com/group/linux.kernel/t/f9a10b1dd49cf609?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 17 2014 5:40 pm
From: dormando


Hi,

Upgraded a few kernels to the latest 3.10 stable tree while tracking down
a rare kernel panic, seems to have introduced a much more frequent kernel
panic. Takes anywhere from 4 hours to 2 days to trigger:

<4>[196727.311203] general protection fault: 0000 [#1] SMP
<4>[196727.311224] Modules linked in: xt_TEE xt_dscp xt_DSCP macvlan bridge coretemp crc32_pclmul ghash_clmulni_intel gpio_ich microcode ipmi_watchdog ipmi_devintf sb_edac edac_core lpc_ich mfd_core tpm_tis tpm tpm_bios ipmi_si ipmi_msghandler isci igb libsas i2c_algo_bit ixgbe ptp pps_core mdio
<4>[196727.311333] CPU: 17 PID: 0 Comm: swapper/17 Not tainted 3.10.26 #1
<4>[196727.311344] Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.0 07/05/2013
<4>[196727.311364] task: ffff885e6f069700 ti: ffff885e6f072000 task.ti: ffff885e6f072000
<4>[196727.311377] RIP: 0010:[<ffffffff815f8c7f>] [<ffffffff815f8c7f>] ipv4_dst_destroy+0x4f/0x80
<4>[196727.311399] RSP: 0018:ffff885effd23a70 EFLAGS: 00010282
<4>[196727.311409] RAX: dead000000200200 RBX: ffff8854c398ecc0 RCX: 0000000000000040
<4>[196727.311423] RDX: dead000000100100 RSI: dead000000100100 RDI: dead000000200200
<4>[196727.311437] RBP: ffff885effd23a80 R08: ffffffff815fd9e0 R09: ffff885d5a590800
<4>[196727.311451] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
<4>[196727.311464] R13: ffffffff81c8c280 R14: 0000000000000000 R15: ffff880e85ee16ce
<4>[196727.311510] FS: 0000000000000000(0000) GS:ffff885effd20000(0000) knlGS:0000000000000000
<4>[196727.311554] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[196727.311581] CR2: 00007a46751eb000 CR3: 0000005e65688000 CR4: 00000000000407e0
<4>[196727.311625] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
<4>[196727.311669] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
<4>[196727.311713] Stack:
<4>[196727.311733] ffff8854c398ecc0 ffff8854c398ecc0 ffff885effd23ab0 ffffffff815b7f42
<4>[196727.311784] ffff88be6595bc00 ffff8854c398ecc0 0000000000000000 ffff8854c398ecc0
<4>[196727.311834] ffff885effd23ad0 ffffffff815b86c6 ffff885d5a590800 ffff8816827821c0
<4>[196727.311885] Call Trace:
<4>[196727.311907] <IRQ>
<4>[196727.311912] [<ffffffff815b7f42>] dst_destroy+0x32/0xe0
<4>[196727.311959] [<ffffffff815b86c6>] dst_release+0x56/0x80
<4>[196727.311986] [<ffffffff81620bd5>] tcp_v4_do_rcv+0x2a5/0x4a0
<4>[196727.312013] [<ffffffff81622b5a>] tcp_v4_rcv+0x7da/0x820
<4>[196727.312041] [<ffffffff815fd9e0>] ? ip_rcv_finish+0x360/0x360
<4>[196727.312070] [<ffffffff815de02d>] ? nf_hook_slow+0x7d/0x150
<4>[196727.312097] [<ffffffff815fd9e0>] ? ip_rcv_finish+0x360/0x360
<4>[196727.312125] [<ffffffff815fda92>] ip_local_deliver_finish+0xb2/0x230
<4>[196727.312154] [<ffffffff815fdd9a>] ip_local_deliver+0x4a/0x90
<4>[196727.312183] [<ffffffff815fd799>] ip_rcv_finish+0x119/0x360
<4>[196727.312212] [<ffffffff815fe00b>] ip_rcv+0x22b/0x340
<4>[196727.312242] [<ffffffffa0339680>] ? macvlan_broadcast+0x160/0x160 [macvlan]
<4>[196727.312275] [<ffffffff815b0c62>] __netif_receive_skb_core+0x512/0x640
<4>[196727.312308] [<ffffffff811427fb>] ? kmem_cache_alloc+0x13b/0x150
<4>[196727.312338] [<ffffffff815b0db1>] __netif_receive_skb+0x21/0x70
<4>[196727.312368] [<ffffffff815b0fa1>] netif_receive_skb+0x31/0xa0
<4>[196727.312397] [<ffffffff815b1ae8>] napi_gro_receive+0xe8/0x140
<4>[196727.312433] [<ffffffffa00274f1>] ixgbe_poll+0x551/0x11f0 [ixgbe]
<4>[196727.312463] [<ffffffff815fe00b>] ? ip_rcv+0x22b/0x340
<4>[196727.312491] [<ffffffff815b1691>] net_rx_action+0x111/0x210
<4>[196727.312521] [<ffffffff815b0db1>] ? __netif_receive_skb+0x21/0x70
<4>[196727.312552] [<ffffffff810519d0>] __do_softirq+0xd0/0x270
<4>[196727.312583] [<ffffffff816cef3c>] call_softirq+0x1c/0x30
<4>[196727.312613] [<ffffffff81004205>] do_softirq+0x55/0x90
<4>[196727.312640] [<ffffffff81051c85>] irq_exit+0x55/0x60
<4>[196727.312668] [<ffffffff816cf5c3>] do_IRQ+0x63/0xe0
<4>[196727.312696] [<ffffffff816c5aaa>] common_interrupt+0x6a/0x6a
<4>[196727.312722] <EOI>
<4>[196727.312727] [<ffffffff8100a150>] ? default_idle+0x20/0xe0
<4>[196727.312775] [<ffffffff8100a8ff>] arch_cpu_idle+0xf/0x20
<4>[196727.312803] [<ffffffff8108d330>] cpu_startup_entry+0xc0/0x270
<4>[196727.312833] [<ffffffff816b276e>] start_secondary+0x1f9/0x200
<4>[196727.312860] Code: 4a 9f e9 81 e8 13 cb 0c 00 48 8b 93 b0 00 00 00 48 bf 00 02 20 00 00 00 ad de 48 8b 83 b8 00 00 00 48 be 00 01 10 00 00 00 ad de <48> 89 42 08 48 89 10 48 89 bb b8 00 00 00 48 c7 c7 4a 9f e9 81
<1>[196727.313071] RIP [<ffffffff815f8c7f>] ipv4_dst_destroy+0x4f/0x80
<4>[196727.313100] RSP <ffff885effd23a70>
<4>[196727.313377] ---[ end trace 64b3f14fae0f2e29 ]---
<0>[196727.380908] Kernel panic - not syncing: Fatal exception in interrupt


... bisecting it's going to be a pain... I tried eyeballing the diffs and
am trying a revert or two.

We've hit it in .25, .26 so far. I have .27 running but not sure if it
crashed, so the change exists between .15 and .25.

Thanks,
-Dormando
--
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: net: rds: fix per-cpu helper usage
http://groups.google.com/group/linux.kernel/t/49ce51b657a098f7?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 17 2014 6:00 pm
From: David Miller


From: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Date: Thu, 16 Jan 2014 16:54:48 +0100

> commit ae4b46e9d "net: rds: use this_cpu_* per-cpu helper" broke per-cpu
> handling for rds. chpfirst is the result of __this_cpu_read(), so it is
> an absolute pointer and not __percpu. Therefore, __this_cpu_write()
> should not operate on chpfirst, but rather on cache->percpu->first, just
> like __this_cpu_read() did before.
>
> Cc: <stable@vger.kernel.org> # 3.8+
> Signed-off-byd Gerald Schaefer <gerald.schaefer@de.ibm.com>

Applied and queued up for -stable, thanks.
--
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: make KVM_MMU_AUDIT help text more readable
http://groups.google.com/group/linux.kernel/t/dd451709dc3dd0d5?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 17 2014 6:10 pm
From: Randy Dunlap


From: Randy Dunlap <rdunlap@infradead.org>

Make KVM_MMU_AUDIT kconfig help text readable and collapse
two spaces between words down to one space.

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---
arch/x86/kvm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- lnx-313-rc8.orig/arch/x86/kvm/Kconfig
+++ lnx-313-rc8/arch/x86/kvm/Kconfig
@@ -65,7 +65,7 @@ config KVM_MMU_AUDIT
depends on KVM && TRACEPOINTS
---help---
This option adds a R/W kVM module parameter 'mmu_audit', which allows
- audit KVM MMU at runtime.
+ auditing of KVM MMU events at runtime.

config KVM_DEVICE_ASSIGNMENT
bool "KVM legacy PCI device assignment support"
--
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/




==============================================================================

You received this message because you are subscribed to the Google Groups "linux.kernel"
group.

To post to this group, visit http://groups.google.com/group/linux.kernel?hl=en

To unsubscribe from this group, send email to linux.kernel+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/linux.kernel/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en