Re: [PATCH ftrace/core v3 2/3] ftrace, kprobes: Support IPMODIFY flag to find IP modify conflict

[Masami Hiramatsu]

(2014/07/18 3:41), Steven Rostedt wrote:
> On Tue, 15 Jul 2014 06:00:28 +
> Masami Hiramatsu  wrote:
> 
>> Introduce FTRACE_OPS_FL_IPMODIFY to avoid conflict among
>> ftrace users who may modify regs->ip to change the execution
>> path. This also adds the flag to kprobe_ftrace_ops, since
>> ftrace-based kprobes already modifies regs->ip. Thus, if
>> another user modifies the regs->ip on the same function entry,
>> one of them will be broken. So both should add IPMODIFY flag
>> and make sure that ftrace_set_filter_ip() succeeds.
>>
>> Note that currently conflicts of IPMODIFY are detected on the
>> filter hash. It does NOT care about the notrace hash. This means
>> that if you set filter hash all functions and notrace(mask)
>> some of them, the IPMODIFY flag will be applied to all
>> functions.
> 
> I would go a bit further (not in this patch, but in a separate patch),
> that if ftrace_ops sets IPMODIFY, it must have a filter hash (non
> global) *and* have nothing in the notrace hash. Modifying the ip is
> dangerous, and it should only be done to a select few functions which
> means there's no reason for having a notrace hash in existence.

Ah, that's a good idea. :)
IPMODIFY user should use ftrace_set_filter_ip and that just allows
user to set the filter hash, not the notrace hash. I like that.

> 
> 
>>
>> Changes in v3:
>>  - Update for the latest ftrace/core.
>>  - Add a comment about FTRACE_OPS_FL_* attribute flags.
>>  - Don't check FTRACE_OPS_FL_SAVE_REGS in
>>__ftrace_hash_update_ipmodify().
>>  - Fix comments.
>>
>> Changes in v2:
>>  - Add a description how __ftrace_hash_update_ipmodify() will
>>handle the given hashes (NULL and EMPTY_HASH cases).
>>  - Clear FTRACE_OPS_FL_ENABLED after calling
>>__unregister_ftrace_function() in error path.
>>
>> Signed-off-by: Masami Hiramatsu 
>> Cc: Ananth N Mavinakayanahalli 
>> Cc: Steven Rostedt 
>> Cc: Josh Poimboeuf 
>> Cc: Namhyung Kim 
>> ---
>>  Documentation/trace/ftrace.txt |5 ++
>>  include/linux/ftrace.h |   15 -
>>  kernel/kprobes.c   |2 -
>>  kernel/trace/ftrace.c  |  132 
>> +++-
>>  4 files changed, 149 insertions(+), 5 deletions(-)
>>
>> diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt
>> index 2479b2a..0fcad7d 100644
>> --- a/Documentation/trace/ftrace.txt
>> +++ b/Documentation/trace/ftrace.txt
>> @@ -234,6 +234,11 @@ of ftrace. Here is a list of some of the key files:
>>  will be displayed on the same line as the function that
>>  is returning registers.
>>  
>> +If the callback registered to be traced by a function with
>> +the "ip modify" attribute (thus the regs->ip can be changed),
>> +a 'I' will be displayed on the same line as the function that
> 
> "an 'I' ..."

I see.

> 
>> +can be overridden.
>> +
>>function_profile_enabled:
>>  
>>  When set it will enable all functions with either the function
>> diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
>> index 11e18fd..daa0f7f 100644
>> --- a/include/linux/ftrace.h
>> +++ b/include/linux/ftrace.h
>> @@ -60,6 +60,11 @@ typedef void (*ftrace_func_t)(unsigned long ip, unsigned 
>> long parent_ip,
>>  /*
>>   * FTRACE_OPS_FL_* bits denote the state of ftrace_ops struct and are
>>   * set in the flags member.
>> + * CONTROL, SAVE_REGS, SAVE_REGS_IF_SUPPORTED, RECURSION_SAFE, STUB and
>> + * IPMODIFY are a kind of attribute flags which can set only before
> 
> "... which can be set ..."
> 
>> + * registering the ftrace_ops, and not able to update while registered.
> 
> "..., and can not be modified while registered."
> 
>> + * Changint those attribute flags after regsitering ftrace_ops will
> 
> s/Changint/Changing/

Oops, thanks,

> 
>> + * cause unexpected results.
>>   *
>>   * ENABLED - set/unset when ftrace_ops is registered/unregistered
>>   * DYNAMIC - set when ftrace_ops is registered to denote dynamically
>> @@ -90,6 +95,9 @@ typedef void (*ftrace_func_t)(unsigned long ip, unsigned 
>> long parent_ip,
>>   * INITIALIZED - The ftrace_ops has already been initialized (first use time
>>   *register_ftrace_function() is called, it will initialized the 
>> ops)
>>   * DELETED - The ops are being deleted, do not let them be registered again.
>> + * IPMODIFY - The ops can modify IP register. This must be set with 
>> SAVE_REGS
>> + *and if the other ops has been set this on same function, 
>> filter
>> + *update must be failed.
> 
> 
> "The ops can modify the IP register. This can only be set along with
> SAVE_REGS. If another ops is already registered for any of the
> functions that this ops will be registered for, then this ops will fail
> to register."

Not only register, but also set_filter_ip ;)
"...will fail to register or set_filter_ip."


>>   */
>>  enum {
>>  FTRACE_OPS_FL_ENABLED   = 1 << 0,
>> @@ -101,6 +109,7 @@ enum {
>>  FTRACE_OPS_FL_STUB

Re: Re: [PATCH ftrace/core v3 3/3] kprobes: Set IPMODIFY flag only if the probe can change regs->ip

[Masami Hiramatsu]

(2014/07/18 14:32), Namhyung Kim wrote:
> Hi Masami,
> 
> On Tue, 15 Jul 2014 06:00:35 +, Masami Hiramatsu wrote:
>> +static int __ftrace_add_filter_ip(struct ftrace_ops *ops, unsigned long ip,
>> +  int *ref)
>> +{
>> +int ret;
>> +
>> +/* Try to set given ip to filter */
>> +ret = ftrace_set_filter_ip(ops, ip, 0, 0);
>> +if (ret < 0)
>> +return ret;
>> +
>> +(*ref)++;
>> +if (*ref == 1) {
>> +ret = register_ftrace_function(ops);
>> +if (ret < 0) {
>> +/* Rollback refcounter and filter */
>> +(*ref)--;
>> +ftrace_set_filter_ip(ops, ip, 1, 0);
>> +}
>> +}
>> +
>> +return ret;
>> +}
> 
> This function also can be changed in a similar way:
> 
>   if (*ref == 0) {
>   ret = register_ftrace_function(ops);
>   if (ret < 0) {
>   /* Rollback filter if failed */
>   ftrace_set_filter_ip(ops, ip, 1, 0);
>   return ret;
>   }
>   }
> 
>   (*ref)++;
> 
>   return 0;

Indeed :)

Thanks!


-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


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

Re: [RFC PATCH] usb: dwc3: core: allow vendor drivers to check probe status

[Lee Jones]

On Thu, 17 Jul 2014, Felipe Balbi wrote:

> Hi,
> 
> On Thu, Jul 17, 2014 at 06:13:33PM +0100, Lee Jones wrote:
> > This patch provides mechanism for subordinate devices to check
> > whether the DWC3 core probed successfully or otherwise.  Useful
> > if PHYs are required to configure controllers, but aren't yet
> > available.  The DWC3 core driver will defer probe if PHYs are
> > unavailable, however subordinate DWC3 drivers currently do not
> > have any visibility or means to check status - until now.
> 
> what's a subordinate DWC3 driver ?
> 
> > Another way to do this would be to *_phy_get*(), but if every
> > driver did this it would create a high level of code
> > duplication.
> > 
> > Signed-off-by: Lee Jones 
> > ---
> >  drivers/usb/dwc3/core.c | 12 
> >  drivers/usb/dwc3/core.h |  1 +
> >  2 files changed, 13 insertions(+)
> > 
> > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> > index eb69eb9..171ca52 100644
> > --- a/drivers/usb/dwc3/core.c
> > +++ b/drivers/usb/dwc3/core.c
> > @@ -47,6 +47,14 @@
> >  
> >  /* 
> > -- 
> > */
> >  
> > +static bool is_enabled = false;
> > +
> > +int dwc3_is_enabled(void)
> > +{
> > +   return is_enabled;
> > +}
> > +EXPORT_SYMBOL(dwc3_is_enabled);
> 
> no, no, no, no. Let me try that again, hello no! You _do_ realise there
> are systems with more than one dwc3 instance, right ? And this is the
> most fragile possible way of doing this.
> 
> You never explained what's a dwc3 subordinate driver, you don't show any
> example of how this would be used and why/where does the PHY need to
> poke into DWC3. Why isn't probe defer enough for you ? Which platform
> are you working on ? what is the problem that you're trying to solve ?
> 
> From this patch, all I can is NAK this patch with no mercy, sorry.

That's okay, I knew this was going to happen hence the RFC status of
the patch.  In the DT case, I describe 'subordinate devices' as are
drivers which register the DWC3 core using of_platform_populate(), 
so, for now:

  drivers/usb/dwc3/dwc3-exynos.c
  drivers/usb/dwc3/dwc3-keystone.c
  drivers/usb/dwc3/dwc3-omap.c

We're attempting to use the same process; however, at the moment we are
suffering with a 'boot order' issue.  If the PHYs aren't up and we
attempt to configure through the glue-layer our board locks up.  
Presumably waiting for a read to return, forever.  Whist the core does
the correct thing i.e. -EPROBE_DEFER, we (dwc3-st.c) have no way of
checking the return status of dwc3_probe().  As mentioned in the
commit message, another way of ensuring the PHYs are available is to
request them, but this would mean an awful lot of code duplication.

In your opinion, what's the best way to handle this?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 1/8] of: Add NVIDIA Tegra SATA controller binding

[Mikko Perttunen]

This patch adds device tree binding documentation for the SATA
controller found on NVIDIA Tegra SoCs.

Signed-off-by: Mikko Perttunen 
---
v5: remove ordering requirement again

 .../devicetree/bindings/ata/tegra-sata.txt | 30 ++
 1 file changed, 30 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/ata/tegra-sata.txt

diff --git a/Documentation/devicetree/bindings/ata/tegra-sata.txt 
b/Documentation/devicetree/bindings/ata/tegra-sata.txt
new file mode 100644
index 000..946f207
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/tegra-sata.txt
@@ -0,0 +1,30 @@
+Tegra124 SoC SATA AHCI controller
+
+Required properties :
+- compatible : "nvidia,tegra124-ahci".
+- reg : Should contain 2 entries:
+  - AHCI register set (SATA BAR5)
+  - SATA register set
+- interrupts : Defines the interrupt used by SATA
+- clocks : Must contain an entry for each entry in clock-names.
+  See ../clocks/clock-bindings.txt for details.
+- clock-names : Must include the following entries:
+  - sata
+  - sata-oob
+  - cml1
+  - pll_e
+- resets : Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names : Must include the following entries:
+  - sata
+  - sata-oob
+  - sata-cold
+- phys : Must contain an entry for each entry in phy-names.
+  See ../phy/phy-bindings.txt for details.
+- phy-names : Must include the following entries:
+  - sata-phy : XUSB PADCTL SATA PHY
+- hvdd-supply : Defines the SATA HVDD regulator
+- vddio-supply : Defines the SATA VDDIO regulator
+- avdd-supply : Defines the SATA AVDD regulator
+- target-5v-supply : Defines the SATA 5V power regulator
+- target-12v-supply : Defines the SATA 12V power regulator
-- 
1.8.1.5

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

Re: [patch 13/13] mm: memcontrol: rewrite uncharge API

[Michal Hocko]

On Tue 15-07-14 14:19:35, Michal Hocko wrote:
> [...]
> > +/**
> > + * mem_cgroup_migrate - migrate a charge to another page
> > + * @oldpage: currently charged page
> > + * @newpage: page to transfer the charge to
> > + * @lrucare: page might be on LRU already
> 
> which one? I guess the newpage?
> 
> > + *
> > + * Migrate the charge from @oldpage to @newpage.
> > + *
> > + * Both pages must be locked, @newpage->mapping must be set up.
> > + */
> > +void mem_cgroup_migrate(struct page *oldpage, struct page *newpage,
> > +   bool lrucare)
> > +{
> > +   unsigned int nr_pages = 1;
> > +   struct page_cgroup *pc;
> > +
> > +   VM_BUG_ON_PAGE(!PageLocked(oldpage), oldpage);
> > +   VM_BUG_ON_PAGE(!PageLocked(newpage), newpage);
> > +   VM_BUG_ON_PAGE(PageLRU(oldpage), oldpage);
> > +   VM_BUG_ON_PAGE(PageLRU(newpage), newpage);
> 
>   VM_BUG_ON_PAGE(PageLRU(newpage) && !lruvec, newpage);

I guess everything except these two notes got addressed.

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

[PATCH v5 7/8] ata: Add support for the Tegra124 SATA controller

[Mikko Perttunen]

This adds support for the integrated AHCI-compliant Serial ATA
controller present on the NVIDIA Tegra124 system-on-chip.

Signed-off-by: Mikko Perttunen 
---
v5: let ahci_platform handle sata clock and also handle it ourselves.
  this allows use of ahci_platform while having a special sequence
  for the clock.

 drivers/ata/Kconfig  |   9 ++
 drivers/ata/Makefile |   1 +
 drivers/ata/ahci_tegra.c | 377 +++
 3 files changed, 387 insertions(+)
 create mode 100644 drivers/ata/ahci_tegra.c

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index b0d5b5a..e1b9278 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -142,6 +142,15 @@ config AHCI_SUNXI
 
  If unsure, say N.
 
+config AHCI_TEGRA
+   tristate "NVIDIA Tegra124 AHCI SATA support"
+   depends on ARCH_TEGRA
+   help
+ This option enables support for the NVIDIA Tegra124 SoC's
+ onboard AHCI SATA.
+
+ If unsure, say N.
+
 config AHCI_XGENE
tristate "APM X-Gene 6.0Gbps AHCI SATA host controller support"
depends on PHY_XGENE
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index 5a02aee..ae41107 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_AHCI_IMX)+= ahci_imx.o libahci.o 
libahci_platform.o
 obj-$(CONFIG_AHCI_MVEBU)   += ahci_mvebu.o libahci.o libahci_platform.o
 obj-$(CONFIG_AHCI_SUNXI)   += ahci_sunxi.o libahci.o libahci_platform.o
 obj-$(CONFIG_AHCI_ST)  += ahci_st.o libahci.o libahci_platform.o
+obj-$(CONFIG_AHCI_TEGRA)   += ahci_tegra.o libahci.o libahci_platform.o
 obj-$(CONFIG_AHCI_XGENE)   += ahci_xgene.o libahci.o libahci_platform.o
 
 # SFF w/ custom DMA
diff --git a/drivers/ata/ahci_tegra.c b/drivers/ata/ahci_tegra.c
new file mode 100644
index 000..d30bb21
--- /dev/null
+++ b/drivers/ata/ahci_tegra.c
@@ -0,0 +1,377 @@
+/*
+ * drivers/ata/ahci_tegra.c
+ *
+ * Copyright (c) 2014, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * Author:
+ * Mikko Perttunen 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "ahci.h"
+
+#define SATA_CONFIGURATION_0   0x180
+#define SATA_CONFIGURATION_EN_FPCI BIT(0)
+
+#define SCFG_OFFSET0x1000
+
+#define T_SATA0_CFG_1  0x04
+#define T_SATA0_CFG_1_IO_SPACE BIT(0)
+#define T_SATA0_CFG_1_MEMORY_SPACE BIT(1)
+#define T_SATA0_CFG_1_BUS_MASTER   BIT(2)
+#define T_SATA0_CFG_1_SERR BIT(8)
+
+#define T_SATA0_CFG_9  0x24
+#define T_SATA0_CFG_9_BASE_ADDRESS_SHIFT   13
+
+#define SATA_FPCI_BAR5 0x94
+#define SATA_FPCI_BAR5_START_SHIFT 4
+
+#define SATA_INTR_MASK 0x188
+#define SATA_INTR_MASK_IP_INT_MASK BIT(16)
+
+#define T_SATA0_AHCI_HBA_CAP_BKDR  0x300
+
+#define T_SATA0_BKDOOR_CC  0x4a4
+
+#define T_SATA0_CFG_SATA   0x54c
+#define T_SATA0_CFG_SATA_BACKDOOR_PROG_IF_EN   BIT(12)
+
+#define T_SATA0_CFG_MISC   0x550
+
+#define T_SATA0_INDEX  0x680
+
+#define T_SATA0_CHX_PHY_CTRL1_GEN1 0x690
+#define T_SATA0_CHX_PHY_CTRL1_GEN1_TX_AMP_MASK 0xff
+#define T_SATA0_CHX_PHY_CTRL1_GEN1_TX_AMP_SHIFT0
+#define T_SATA0_CHX_PHY_CTRL1_GEN1_TX_PEAK_MASK(0xff << 8)
+#define T_SATA0_CHX_PHY_CTRL1_GEN1_TX_PEAK_SHIFT   8
+
+#define T_SATA0_CHX_PHY_CTRL1_GEN2 0x694
+#define T_SATA0_CHX_PHY_CTRL1_GEN2_TX_AMP_MASK 0xff
+#define T_SATA0_CHX_PHY_CTRL1_GEN2_TX_AMP_SHIFT0
+#define T_SATA0_CHX_PHY_CTRL1_GEN2_TX_PEAK_MASK(0xff << 12)
+#define T_SATA0_CHX_PHY_CTRL1_GEN2_TX_PEAK_SHIFT   12
+
+#define T_SATA0_CHX_PHY_CTRL2  0x69c
+#define T_SATA0_CHX_PHY_CTRL2_CDR_CNTL_GEN10x23
+
+#define T_SATA0_CHX_PHY_CTRL11 0x6d0
+#define T_SATA0_CHX_PHY_CTRL11_GEN2_RX_EQ  (0x2800 << 16)
+
+#define FUSE_SATA_CALIB0x124
+#define FUSE_SATA_CALIB_MASK   0x3
+
+struct sata_pad_

[PATCHv4 0/2] parport: parport_pc: Fix false-positives at checking for Intel bug

[matwey]

From: "Matwey V. Kornilov" 

Hi,

The following patch series is to deal with the issue on false-positives
of Intel EPP bug check [1].

More than a decade ago, the check was introduced in order to prevent EPP
operation on the some Intel LPT chipsets. The main issue to defence from
was CPU hang at EPP operation on broken chipsets. It is mentioned that
affected chipsets are Intel 82091. However, it is not known whether
there are others.

The check was implemented in strange manner. Now, there is no explanations
why. The check itself now leads to the false-positives, disabling EPP on
many PC-s (Dell OptiPlex series for instance). The latter is an issue.

As it was suggested by One Thousand Gnomes we implement the additional check of 
CPU model.
If CPU is Intel 80486 or Pentium, then it is considered as potentially affected 
by the initial problem, so the initial check is applied.

The patches organized as following:

1. Introduce-intel_bug_present-function.

The transparent refactoring of the check is performed.
Make the check be immutable regarding to ECR register.

2. Implement CPU model check to cut off false-positives

Based on CPU model, disable the check. The check is enabled only for Intel 
80486 or Pentium.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630593

Suggested-by: One Thousand Gnomes  
Tested-by: Heiko Andreas Sommer 
Signed-off-by: Matwey V. Kornilov 

---
Changes from v3:
 - Do not introduce the additional option, rely on CPU model instead.

Changes from v2:
 - The module option has more clear description

Changes from v1:
 - Patch 1 fetched from right branch and now compiled

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

[PATCHv4 2/2] parport: parport_pc: Implement CPU model check to cut off false-positives

[matwey]

From: "Matwey V. Kornilov" 

The code in intel_bug_present is known to produce much false-positives.
It is believed that the affected by the bug hardware are used with either Intel 
80486 or Pentium.

Perform the check only when the kernel configured as CONFIG_X86_32,
then use cpuinfo_x86 of the first available CPU to check the model
and run initial check code.

Suggested-by: One Thousand Gnomes 
Tested-by: Heiko Andreas Sommer 
Signed-off-by: Matwey V. Kornilov 
---
 drivers/parport/parport_pc.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
index a6eaafb..6b28f9f 100644
--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
@@ -65,6 +65,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define PARPORT_PC_MAX_PORTS PARPORT_MAX
 
@@ -1702,7 +1703,11 @@ static int parport_ECP_supported(struct parport *pb)
 }
 #endif
 
-static int intel_bug_present(struct parport *pb)
+/*  It is believed that CPU model correlates with buggy LPT chipset model.
+Here we check that or CPU is elder than Pentium Pro: either 80486 or 
Pentium.
+If it is then we perform The Check. */
+#ifdef CONFIG_X86_32
+static int intel_bug_present_check_epp(struct parport *pb)
 {
const struct parport_pc_private *priv = pb->private_data;
int bug_present = 0;
@@ -1725,6 +1730,20 @@ static int intel_bug_present(struct parport *pb)
 
return bug_present;
 }
+static int intel_bug_present(struct parport *pb)
+{
+   struct cpuinfo_x86 *c = &cpu_data(0);
+
+   if (c->x86_vendor == X86_VENDOR_INTEL && (c->x86 == 4 || c->x86 == 5))
+   return intel_bug_present_check_epp(pb);
+   return 0;
+}
+#else
+static int intel_bug_present(struct parport *pb)
+{
+   return 0;
+}
+#endif
 
 static int parport_ECPPS2_supported(struct parport *pb)
 {
-- 
1.8.1.4

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

[PATCHv4 1/2] parport: parport_pc: Introduce intel_bug_present function.

[matwey]

From: "Matwey V. Kornilov" 

Put the code to check present of the Intel bug from parport_EPP_supported
into new intel_bug_present function. The later also return ECR register
to the state it has before function call.

Suggested-by: One Thousand Gnomes 
Tested-by: Heiko Andreas Sommer 
Signed-off-by: Matwey V. Kornilov 
---
 drivers/parport/parport_pc.c | 38 ++
 1 file changed, 26 insertions(+), 12 deletions(-)

diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
index 76ee775..a6eaafb 100644
--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
@@ -1702,6 +1702,30 @@ static int parport_ECP_supported(struct parport *pb)
 }
 #endif
 
+static int intel_bug_present(struct parport *pb)
+{
+   const struct parport_pc_private *priv = pb->private_data;
+   int bug_present = 0;
+
+   if (priv->ecr) {
+   /* store value of ECR */
+   unsigned char ecr = inb(ECONTROL(pb));
+   unsigned char i;
+   for (i = 0x00; i < 0x80; i += 0x20) {
+   ECR_WRITE(pb, i);
+   if (clear_epp_timeout(pb)) {
+   /* Phony EPP in ECP. */
+   bug_present = 1;
+   break;
+   }
+   }
+   /* return ECR into the inital state */
+   ECR_WRITE(pb, ecr);
+   }
+
+   return bug_present;
+}
+
 static int parport_ECPPS2_supported(struct parport *pb)
 {
const struct parport_pc_private *priv = pb->private_data;
@@ -1722,8 +1746,6 @@ static int parport_ECPPS2_supported(struct parport *pb)
 
 static int parport_EPP_supported(struct parport *pb)
 {
-   const struct parport_pc_private *priv = pb->private_data;
-
/*
 * Theory:
 *  Bit 0 of STR is the EPP timeout bit, this bit is 0
@@ -1742,16 +1764,8 @@ static int parport_EPP_supported(struct parport *pb)
return 0;  /* No way to clear timeout */
 
/* Check for Intel bug. */
-   if (priv->ecr) {
-   unsigned char i;
-   for (i = 0x00; i < 0x80; i += 0x20) {
-   ECR_WRITE(pb, i);
-   if (clear_epp_timeout(pb)) {
-   /* Phony EPP in ECP. */
-   return 0;
-   }
-   }
-   }
+   if (intel_bug_present(pb))
+   return 0;
 
pb->modes |= PARPORT_MODE_EPP;
 
-- 
1.8.1.4

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

Re: [PATCH] random: limit the contribution of the hw rng to at most half

[Theodore Ts'o]

On Thu, Jul 17, 2014 at 04:33:36PM -0700, H. Peter Anvin wrote:
> 
> I just want to make sure we don't negatively impact the real security of
> users because of "optics".  We already have a lot of problems with
> people extracting long-living keys from /dev/urandom because /dev/random
> is too slow.

With a system with RDRAND, we're mixing arch_get_rand_long() as part
of the extraction process (as the seed for the SHA's IV).  So if you
trust RDRAND, then using /dev/urandom even when the entropy count is
zero is going to be secure.  If you don't trust RDRAND, then the
RDSEED entropy accounting is going to be extremely disturbing.

So the only way that we could be impacting the "real security" of
users, would be if RDRAND was back-doored, but RDSEED wasn't.  And
that doesn't seem like a terribly likely scenario to me, but what do I
know?  :-)

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

Re: [PATCH v5 1/8] of: Add NVIDIA Tegra SATA controller binding

[Mikko Perttunen]

So here's v5: this time, as suggested, I handle the sata clock myself 
and let ahci_platform handle it too, leading it to be prepared+enabled 
twice. This works fine, and allows us to remove the DT ordering requirement.


I also have in the works a patchset that adds the name-based 
ahci_platform_get_resources function, but that is not quite ready yet, 
even if it is quite far along. Also, I am going on vacation and 
returning on 28.7., so if this v5 is acceptable maybe it could be merged 
for 3.17 and I could work on the new get_resources scheme after I get 
back from vacation?


Thanks, Mikko

On 18/07/14 10:11, Mikko Perttunen wrote:

This patch adds device tree binding documentation for the SATA
controller found on NVIDIA Tegra SoCs.

Signed-off-by: Mikko Perttunen 
---
v5: remove ordering requirement again

  .../devicetree/bindings/ata/tegra-sata.txt | 30 ++
  1 file changed, 30 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/ata/tegra-sata.txt

diff --git a/Documentation/devicetree/bindings/ata/tegra-sata.txt 
b/Documentation/devicetree/bindings/ata/tegra-sata.txt
new file mode 100644
index 000..946f207
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/tegra-sata.txt
@@ -0,0 +1,30 @@
+Tegra124 SoC SATA AHCI controller
+
+Required properties :
+- compatible : "nvidia,tegra124-ahci".
+- reg : Should contain 2 entries:
+  - AHCI register set (SATA BAR5)
+  - SATA register set
+- interrupts : Defines the interrupt used by SATA
+- clocks : Must contain an entry for each entry in clock-names.
+  See ../clocks/clock-bindings.txt for details.
+- clock-names : Must include the following entries:
+  - sata
+  - sata-oob
+  - cml1
+  - pll_e
+- resets : Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names : Must include the following entries:
+  - sata
+  - sata-oob
+  - sata-cold
+- phys : Must contain an entry for each entry in phy-names.
+  See ../phy/phy-bindings.txt for details.
+- phy-names : Must include the following entries:
+  - sata-phy : XUSB PADCTL SATA PHY
+- hvdd-supply : Defines the SATA HVDD regulator
+- vddio-supply : Defines the SATA VDDIO regulator
+- avdd-supply : Defines the SATA AVDD regulator
+- target-5v-supply : Defines the SATA 5V power regulator
+- target-12v-supply : Defines the SATA 12V power regulator


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

Re: [PATCH v3 1/3] drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver

[Lee Jones]

On Thu, 17 Jul 2014, Andreas Werner wrote:
> On Thu, Jul 17, 2014 at 01:41:56PM +0100, Lee Jones wrote:
> > On Thu, 17 Jul 2014, Andreas Werner wrote:
> > > The MEN 14F021P00 Board Management Controller provides an
> > > I2C interface to the host to access the feature implemented in the BMC.
> > > The BMC is a PIC Microntroller assembled on CPCI Card from MEN 
> > > Mikroelektronik
> > > and on a few Box/Display Computer.
> > > 
> > > Added MFD Core driver, supporting the I2C communication to the device.
> > > 
> > > The MFD driver currently supports the following features:
> > >   - Watchdog
> > >   - LEDs
> > > 
> > > Signed-off-by: Andreas Werner 
> > > ---
> > >  drivers/mfd/Kconfig |  12 +
> > >  drivers/mfd/Makefile|   1 +
> > >  drivers/mfd/menf21bmc.c | 136 
> > > 
> > >  3 files changed, 149 insertions(+)
> > >  create mode 100644 drivers/mfd/menf21bmc.c
> > > 
> > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > > index b8d9ca0..6e2cd14 100644
> > > --- a/drivers/mfd/Kconfig
> > > +++ b/drivers/mfd/Kconfig
> > > @@ -453,6 +453,18 @@ config MFD_MAX8998
> > > additional drivers must be enabled in order to use the functionality
> > > of the device.
> > >  
> > > +config MFD_MENF21BMC
> > > + tristate "MEN 14F021P00 Board Management Controller Support"
> > > + depends on I2C=y
> > > + select MFD_CORE
> > > + help
> > > +   Say yes here to add support for the MEN 14F021P00 BMC
> > > +   which is a Board Management Controller connected to the I2C bus.
> > > +   The device supports multiple sub-devices like LED and WDT.
> > > +   This driver provides common support for accessing the devices;
> > > +   additional drivers must be enabled in order to use the
> > > +   functionality of the BMC device.
> > 
> > Can you mention what those devices are here in the help text?
> >
> 
> I've mentioned the sub-devices "LED" and "WDT" but i can also write
> the name to the help text like "menf21bmc_wdt" and "leds-menf21bmc".

Scrap this comment, I was being silly and didn't see "LED and WDT".

[...]

> > > +MODULE_DEVICE_TABLE(i2c, menf21bmc_id_table);
> > > +
> > > +static struct i2c_driver menf21bmc_driver = {
> > > + .driver = {
> > > + .name   = "menf21bmc",
> > > + .owner  = THIS_MODULE,
> > 
> > Remove this line, it's handled elsewhere.
> 
> Which line? the ".owner" line?

Yeah.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch added to the 3.12 stable tree] recordmcount/MIPS: Fix possible incorrect mcount_loc table entries in modules

[Jiri Slaby]

From: Alex Smith 

This patch has been added to the 3.12 stable tree. If you have any
objections, please let us know.

===

commit 91ad11d7cc6f4472ebf177a6252fbf0fd100d798 upstream.

On MIPS calls to _mcount in modules generate 2 instructions to load
the _mcount address (and therefore 2 relocations). The mcount_loc
table should only reference the first of these, so the second is
filtered out by checking the relocation offset and ignoring ones that
immediately follow the previous one seen.

However if a module has an _mcount call at offset 0, the second
relocation would not be filtered out due to old_r_offset == 0
being taken to mean that the current relocation is the first one
seen, and both would end up in the mcount_loc table.

This results in ftrace_make_nop() patching both (adjacent)
instructions to branches over the _mcount call sequence like so:

  0xc08a8000:  04 00 00 10 b   0xc08a8014
  0xc08a8004:  04 00 00 10 b   0xc08a8018
  0xc08a8008:  2d 08 e0 03 moveat,ra
  ...

The second branch is in the delay slot of the first, which is
defined to be unpredictable - on the platform on which this bug was
encountered, it triggers a reserved instruction exception.

Fix by initializing old_r_offset to ~0 and using that instead of 0
to determine whether the current relocation is the first seen.

Signed-off-by: Alex Smith 
Cc: linux-kernel@vger.kernel.org
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/7098/
Signed-off-by: Ralf Baechle 
Signed-off-by: Jiri Slaby 
---
 scripts/recordmcount.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/recordmcount.h b/scripts/recordmcount.h
index 9d1421e63ff8..49b582a225b0 100644
--- a/scripts/recordmcount.h
+++ b/scripts/recordmcount.h
@@ -163,11 +163,11 @@ static int mcount_adjust = 0;
 
 static int MIPS_is_fake_mcount(Elf_Rel const *rp)
 {
-   static Elf_Addr old_r_offset;
+   static Elf_Addr old_r_offset = ~(Elf_Addr)0;
Elf_Addr current_r_offset = _w(rp->r_offset);
int is_fake;
 
-   is_fake = old_r_offset &&
+   is_fake = (old_r_offset != ~(Elf_Addr)0) &&
(current_r_offset - old_r_offset == MIPS_FAKEMCOUNT_OFFSET);
old_r_offset = current_r_offset;
 
-- 
2.0.0

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

[patch added to the 3.12 stable tree] NFS: populate ->net in mount data when remounting

[Jiri Slaby]

From: Mateusz Guzik 

This patch has been added to the 3.12 stable tree. If you have any
objections, please let us know.

===

commit a914722f333b3359d2f4f12919380a334176bb89 upstream.

Otherwise the kernel oopses when remounting with IPv6 server because
net is dereferenced in dev_get_by_name.

Use net ns of current thread so that dev_get_by_name does not operate on
foreign ns. Changing the address is prohibited anyway so this should not
affect anything.

Signed-off-by: Mateusz Guzik 
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Trond Myklebust 
Signed-off-by: Jiri Slaby 
---
 fs/nfs/super.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index a03b9c6f9489..64940b5286db 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -2197,6 +2197,7 @@ nfs_remount(struct super_block *sb, int *flags, char 
*raw_data)
data->timeo = 10U * nfss->client->cl_timeout->to_initval / HZ;
data->nfs_server.port = nfss->port;
data->nfs_server.addrlen = nfss->nfs_client->cl_addrlen;
+   data->net = current->nsproxy->net_ns;
memcpy(&data->nfs_server.address, &nfss->nfs_client->cl_addr,
data->nfs_server.addrlen);
 
-- 
2.0.0

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

[PATCH 1/2 v4] sched: Remove update_rq_runnable_avg

[Yuyang Du]

The current rq->avg is not made use of anywhere, and the code is in fair
scheduler's critical path, so remove it.

Signed-off-by: Yuyang Du 
---
 kernel/sched/debug.c |8 
 kernel/sched/fair.c  |   24 
 kernel/sched/sched.h |2 --
 3 files changed, 4 insertions(+), 30 deletions(-)

diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index 695f977..4b864c7 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -68,14 +68,6 @@ static void print_cfs_group_stats(struct seq_file *m, int 
cpu, struct task_group
 #define PN(F) \
SEQ_printf(m, "  .%-30s: %lld.%06ld\n", #F, SPLIT_NS((long long)F))
 
-   if (!se) {
-   struct sched_avg *avg = &cpu_rq(cpu)->avg;
-   P(avg->runnable_avg_sum);
-   P(avg->runnable_avg_period);
-   return;
-   }
-
-
PN(se->exec_start);
PN(se->vruntime);
PN(se->sum_exec_runtime);
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index fea7d33..1a2d04f 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2430,18 +2430,12 @@ static inline void __update_group_entity_contrib(struct 
sched_entity *se)
}
 }
 
-static inline void update_rq_runnable_avg(struct rq *rq, int runnable)
-{
-   __update_entity_runnable_avg(rq_clock_task(rq), &rq->avg, runnable);
-   __update_tg_runnable_avg(&rq->avg, &rq->cfs);
-}
 #else /* CONFIG_FAIR_GROUP_SCHED */
 static inline void __update_cfs_rq_tg_load_contrib(struct cfs_rq *cfs_rq,
 int force_update) {}
 static inline void __update_tg_runnable_avg(struct sched_avg *sa,
  struct cfs_rq *cfs_rq) {}
 static inline void __update_group_entity_contrib(struct sched_entity *se) {}
-static inline void update_rq_runnable_avg(struct rq *rq, int runnable) {}
 #endif /* CONFIG_FAIR_GROUP_SCHED */
 
 static inline void __update_task_entity_contrib(struct sched_entity *se)
@@ -2614,7 +2608,6 @@ static inline void dequeue_entity_load_avg(struct cfs_rq 
*cfs_rq,
  */
 void idle_enter_fair(struct rq *this_rq)
 {
-   update_rq_runnable_avg(this_rq, 1);
 }
 
 /*
@@ -2624,7 +2617,6 @@ void idle_enter_fair(struct rq *this_rq)
  */
 void idle_exit_fair(struct rq *this_rq)
 {
-   update_rq_runnable_avg(this_rq, 0);
 }
 
 static int idle_balance(struct rq *this_rq);
@@ -2633,7 +2625,6 @@ static int idle_balance(struct rq *this_rq);
 
 static inline void update_entity_load_avg(struct sched_entity *se,
  int update_cfs_rq) {}
-static inline void update_rq_runnable_avg(struct rq *rq, int runnable) {}
 static inline void enqueue_entity_load_avg(struct cfs_rq *cfs_rq,
   struct sched_entity *se,
   int wakeup) {}
@@ -3936,10 +3927,9 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p, 
int flags)
update_entity_load_avg(se, 1);
}
 
-   if (!se) {
-   update_rq_runnable_avg(rq, rq->nr_running);
+   if (!se)
add_nr_running(rq, 1);
-   }
+
hrtick_update(rq);
 }
 
@@ -3997,10 +3987,9 @@ static void dequeue_task_fair(struct rq *rq, struct 
task_struct *p, int flags)
update_entity_load_avg(se, 1);
}
 
-   if (!se) {
+   if (!se)
sub_nr_running(rq, 1);
-   update_rq_runnable_avg(rq, 1);
-   }
+
hrtick_update(rq);
 }
 
@@ -5437,9 +5426,6 @@ static void __update_blocked_averages_cpu(struct 
task_group *tg, int cpu)
 */
if (!se->avg.runnable_avg_sum && !cfs_rq->nr_running)
list_del_leaf_cfs_rq(cfs_rq);
-   } else {
-   struct rq *rq = rq_of(cfs_rq);
-   update_rq_runnable_avg(rq, rq->nr_running);
}
 }
 
@@ -7352,8 +7338,6 @@ static void task_tick_fair(struct rq *rq, struct 
task_struct *curr, int queued)
 
if (numabalancing_enabled)
task_tick_numa(rq, curr);
-
-   update_rq_runnable_avg(rq, 1);
 }
 
 /*
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 31cc02e..a147571 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -542,8 +542,6 @@ struct rq {
 #ifdef CONFIG_FAIR_GROUP_SCHED
/* list of leaf cfs_rq on this cpu: */
struct list_head leaf_cfs_rq_list;
-
-   struct sched_avg avg;
 #endif /* CONFIG_FAIR_GROUP_SCHED */
 
/*
-- 
1.7.9.5

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

Re: [PATCH 0/2] mmc: rtsx: add support for async request

[Lee Jones]

Chris, Ulf,

Sorry for the delay, things have been hectic.

The following changes since commit cd3de83f147601356395b57a8673e9c5ff1e59d1:

  Linux 3.16-rc4 (2014-07-06 12:37:51 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git tags/mfd-mmc-v3.17

for you to fetch changes up to 6291e7153a173f85bbdb13bf0c72fa11b5d74bc0:

  mmc: rtsx: add support for async request (2014-07-09 14:17:15 +0100)


Immutable branch between MFD and MMC due for the v3.17 merge window.


Micky Ching (2):
  mfd: rtsx: Add dma transfer function
  mmc: rtsx: add support for async request

 drivers/mfd/rtsx_pcr.c|  76 ++
 drivers/mmc/host/rtsx_pci_sdmmc.c | 133 --
 include/linux/mfd/rtsx_pci.h  |   6 ++
 3 files changed, 181 insertions(+), 34 deletions(-)

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/2 v4] sched: Rewrite per entity runnable load average tracking

[Yuyang Du]

Thanks to Morten, Ben, and Fengguang.

v4 changes:

- Insert memory barrier before writing cfs_rq->load_last_update_copy.
- Fix typos.

We carried out some performance tests (thanks to Fengguang and his LKP). The 
results are shown
as follows. The patchset (including two patches) is on top of mainline 
v3.16-rc3. To make a fair
and clear comparison, we have two parts:

(1) v3.16-rc3 vs. PATCH 1/2 + 2/2
(2) PATCH 1/2 vs. PATCH 1/2 + 2/2

Overall, this rewrite has better performance, and reduced net overhead in load 
average tracking.

--

host: lkp-snb01
model: Sandy Bridge-EP
memory: 32G

host: lkp-sb03
model: Sandy Bridge-EP
memory: 64G

host: lkp-nex04
model: Nehalem-EX
memory: 256G

host: xps2
model: Nehalem
memory: 4G

host: lkp-a0x
model: Atom
memory: 8G

Legend:
[+-]XX% - change percent
~XX%- stddev percent

(1) v3.16-rc3 PATCH 1/2 + 2/2
---  -  
  0.03 ~ 0%  +0.0%   0.03 ~ 0%  
snb-drag/fileio/600s-100%-1HDD-ext4-64G-1024f-seqwr-sync
 51.72 ~ 1%  +0.5%  51.99 ~ 1%  
snb-drag/fileio/600s-100%-1HDD-xfs-64G-1024f-rndrd-sync
 53.24 ~ 0%  +0.9%  53.72 ~ 0%  
snb-drag/fileio/600s-100%-1HDD-xfs-64G-1024f-rndrw-sync
  0.01 ~ 0%  +0.0%   0.01 ~ 0%  
snb-drag/fileio/600s-100%-1HDD-xfs-64G-1024f-rndwr-sync
  3.27 ~ 0%  -0.1%   3.27 ~ 0%  
snb-drag/fileio/600s-100%-1HDD-xfs-64G-1024f-seqrd-sync
  0.02 ~ 0%  +0.0%   0.02 ~ 0%  
snb-drag/fileio/600s-100%-1HDD-xfs-64G-1024f-seqrewr-sync
  0.02 ~ 0%  +0.0%   0.02 ~ 0%  
snb-drag/fileio/600s-100%-1HDD-xfs-64G-1024f-seqwr-sync
108.31 ~ 1%  +0.7% 109.06 ~ 0%  TOTAL fileio.request_latency_95%_ms

---  -  
155810 ~ 3% +62.6% 253355 ~ 0%  
lkp-snb01/hackbench/1600%-process-pipe
146931 ~ 1%  +5.5% 154948 ~ 0%  
lkp-snb01/hackbench/1600%-process-socket
172780 ~ 1% +23.0% 212579 ~ 2%  
lkp-snb01/hackbench/1600%-threads-pipe
152966 ~ 0%  +3.6% 158433 ~ 0%  
lkp-snb01/hackbench/1600%-threads-socket
 95943 ~ 0%  +2.7%  98501 ~ 0%  lkp-snb01/hackbench/50%-process-pipe
 86759 ~ 0% +79.4% 155606 ~ 0%  
lkp-snb01/hackbench/50%-process-socket
 90232 ~ 0%  +3.3%  93205 ~ 0%  lkp-snb01/hackbench/50%-threads-pipe
 79416 ~ 0% +85.6% 147379 ~ 0%  
lkp-snb01/hackbench/50%-threads-socket
980841 ~ 1% +29.9%1274010 ~ 0%  TOTAL hackbench.throughput

---  -  
  3.02e+08 ~ 5%  -2.5%  2.944e+08 ~ 3%  lkp-a06/qperf/600s
  3.02e+08 ~ 5%  -2.5%  2.944e+08 ~ 3%  TOTAL qperf.sctp.bw

---  -  
 6.578e+08 ~ 1%  +1.1%  6.651e+08 ~ 1%  lkp-a06/qperf/600s
 6.578e+08 ~ 1%  +1.1%  6.651e+08 ~ 1%  TOTAL qperf.tcp.bw

---  -  
 6.678e+08 ~ 0%  +0.7%  6.728e+08 ~ 0%  lkp-a06/qperf/600s
 6.678e+08 ~ 0%  +0.7%  6.728e+08 ~ 0%  TOTAL qperf.udp.recv_bw

---  -  
 6.721e+08 ~ 0%  +1.1%  6.797e+08 ~ 0%  lkp-a06/qperf/600s
 6.721e+08 ~ 0%  +1.1%  6.797e+08 ~ 0%  TOTAL qperf.udp.send_bw

---  -  
 55388 ~ 2%  -1.9%  54324 ~ 0%  lkp-a06/qperf/600s
 55388 ~ 2%  -1.9%  54324 ~ 0%  TOTAL qperf.sctp.latency

---  -  
 39988 ~ 1%  -1.0%  39581 ~ 0%  lkp-a06/qperf/600s
 39988 ~ 1%  -1.0%  39581 ~ 0%  TOTAL qperf.tcp.latency

---  -  
 33022 ~ 2%  -1.6%  32484 ~ 0%  lkp-a06/qperf/600s
 33022 ~ 2%  -1.6%  32484 ~ 0%  TOTAL qperf.udp.latency

---  -  
   1048360 ~ 0%  +0.0%1048360 ~ 0%  lkp-a05/iperf/300s-udp
   1048360 ~ 0%  +0.0%1048360 ~ 0%  TOTAL iperf.udp.bps

---  -  
 4.801e+09 ~ 2%  -2.4%  4.688e+09 ~ 0%  lkp-a05/iperf/300s-tcp
 4.801e+09 ~ 2%  -2.4%  4.688e+09 ~ 0%  TOTAL iperf.tcp.receiver.bps

---  -  
 4.801e+09 ~ 2%  -2.4%  4.688e+09 ~ 0%  lkp-a05/iperf/300s-tcp
 4.801e+09 ~ 2%  -2.4%  4.688e+09 ~ 0%  TOTAL iperf.tcp.sender.bps

---  -  
140261 ~ 1%  +2.6% 143971 ~ 0%  lkp-sb03/nepim/300s-100%-udp
126862 ~ 1%  +4.4% 132471 ~ 4%  lkp-sb03/nepim/300s-100%-udp6
577494 ~ 3%  -2.7% 561810 ~ 2%  lkp-sb03/nepim/300s-25%-udp
515120 ~ 2%  +3.3% 532350 ~ 2%  lkp-sb03/nepim/300s-25%-udp6
   1359739 ~ 3%  +0.8%1370604 ~ 2%  TOTAL nepim.udp.avg.kbps_in

---  -  
160888 ~ 2%  +3.2% 165964 ~ 2%  lkp-sb03/nepim/300s-100%-udp
127159 ~ 1%  +4.4% 132798 ~ 4%  lkp-sb03/nepim/300s-100%-udp6
653177 ~ 3%  -1.0%  

[PATCH 2/2 v4] sched: Rewrite per entity runnable load average tracking

[Yuyang Du]

The idea of per entity runnable load average (let runnable time contribute to 
load
weight) was proposed by Paul Turner, and it is still followed by this rewrite. 
This
rewrite is done due to the following ends:

1. cfs_rq's load average (namely runnable_load_avg and blocked_load_avg) is 
updated
   at the granularity of one entity at one time, which results in the cfs_rq 
load
   average is partially updated or asynchronous across its entities: at any 
time,
   only one entity is up to date and contributes to the cfs_rq, all other 
entities
   are effectively lagging behind.

2. cfs_rq load average is different between top rq->cfs_rq and other 
task_group's
   per CPU cfs_rqs in whether or not blocked_load_average contributes to the 
load.

3. How task_group's load is calculated is complex.

This rewrite tackles these by:

1. Combine runnable and blocked load averages for cfs_rq. And track cfs_rq's 
load
   average as a whole and is used as such.

2. Track task entity load average for carrying it between CPUs in migration, 
group
   cfs_rq and its own entity load averages are tracked for update_cfs_shares and
   task_h_load calc. task_group's load_avg is aggregated from its per CPU 
cfs_rq's
   load_avg, which is aggregated from its sched_entities (both task and group 
entity).
   Group entity's weight is proportional to its own cfs_rq's load_avg / 
task_group's
   load_avg.

3. All task, cfs_rq/group_entity, and task_group have simple, consistent, 
up-to-date,
   and synchronized load_avg.

This rewrite in principle is equivalent to the previous in functionality, but
significantly reduces code coplexity and hence increases efficiency and clarity.
In addition, the new load_avg is much more smooth/continuous (no abrupt jumping 
ups
and downs) and decayed/updated more quickly and synchronously to reflect the 
load
dynamic. As a result, we have less load tracking overhead and better 
performance.

Signed-off-by: Yuyang Du 
---
 include/linux/sched.h |   21 +-
 kernel/sched/debug.c  |   22 +-
 kernel/sched/fair.c   |  542 -
 kernel/sched/proc.c   |2 +-
 kernel/sched/sched.h  |   20 +-
 5 files changed, 203 insertions(+), 404 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 306f4f0..c981f26 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1067,16 +1067,21 @@ struct load_weight {
u32 inv_weight;
 };
 
+/*
+ * The load_avg represents an infinite geometric series. The 64 bit
+ * load_sum can:
+ * 1) for cfs_rq, afford 4353082796 (=2^64/47742/88761) entities with
+ * the highest weight (=88761) always runnable, we should not overflow
+ * 2) for entity, support any load.weight always runnable
+ */
 struct sched_avg {
/*
-* These sums represent an infinite geometric series and so are bound
-* above by 1024/(1-y).  Thus we only need a u32 to store them for all
-* choices of y < 1-2^(-32)*1024.
+* The load_avg represents an infinite geometric series.
 */
-   u32 runnable_avg_sum, runnable_avg_period;
-   u64 last_runnable_update;
-   s64 decay_count;
-   unsigned long load_avg_contrib;
+   u64 last_update_time;
+   u64 load_sum;
+   unsigned long load_avg;
+   u32 period_contrib;
 };
 
 #ifdef CONFIG_SCHEDSTATS
@@ -1142,7 +1147,7 @@ struct sched_entity {
 #endif
 
 #ifdef CONFIG_SMP
-   /* Per-entity load-tracking */
+   /* Per entity load average tracking */
struct sched_avgavg;
 #endif
 };
diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index 4b864c7..34a3f26 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -85,10 +85,7 @@ static void print_cfs_group_stats(struct seq_file *m, int 
cpu, struct task_group
 #endif
P(se->load.weight);
 #ifdef CONFIG_SMP
-   P(se->avg.runnable_avg_sum);
-   P(se->avg.runnable_avg_period);
-   P(se->avg.load_avg_contrib);
-   P(se->avg.decay_count);
+   P(se->my_q->avg.load_avg);
 #endif
 #undef PN
 #undef P
@@ -205,19 +202,11 @@ void print_cfs_rq(struct seq_file *m, int cpu, struct 
cfs_rq *cfs_rq)
SEQ_printf(m, "  .%-30s: %d\n", "nr_running", cfs_rq->nr_running);
SEQ_printf(m, "  .%-30s: %ld\n", "load", cfs_rq->load.weight);
 #ifdef CONFIG_SMP
-   SEQ_printf(m, "  .%-30s: %ld\n", "runnable_load_avg",
-   cfs_rq->runnable_load_avg);
-   SEQ_printf(m, "  .%-30s: %ld\n", "blocked_load_avg",
-   cfs_rq->blocked_load_avg);
+   SEQ_printf(m, "  .%-30s: %lu\n", "load_avg",
+   cfs_rq->avg.load_avg);
 #ifdef CONFIG_FAIR_GROUP_SCHED
-   SEQ_printf(m, "  .%-30s: %ld\n", "tg_load_contrib",
-   cfs_rq->tg_load_contrib);
-   SEQ_printf(m, "  .%-30s: %d\n", "tg_runnable_contrib",
-   cfs_rq->tg_runnable_contrib);
SEQ_printf(m, "  .%-30s: %ld\n", "tg_load_avg",
atomic_long_read

Re: [PATCHv4 2/2] parport: parport_pc: Implement CPU model check to cut off false-positives

[Ondrej Zary]

On Friday 18 July 2014, mat...@sai.msu.ru wrote:
> From: "Matwey V. Kornilov" 
>
> The code in intel_bug_present is known to produce much false-positives.
> It is believed that the affected by the bug hardware are used with either
> Intel 80486 or Pentium.
>
> Perform the check only when the kernel configured as CONFIG_X86_32,
> then use cpuinfo_x86 of the first available CPU to check the model
> and run initial check code.
>
> Suggested-by: One Thousand Gnomes 
> Tested-by: Heiko Andreas Sommer 
> Signed-off-by: Matwey V. Kornilov 
> ---
>  drivers/parport/parport_pc.c | 21 -
>  1 file changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
> index a6eaafb..6b28f9f 100644
> --- a/drivers/parport/parport_pc.c
> +++ b/drivers/parport/parport_pc.c
> @@ -65,6 +65,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #define PARPORT_PC_MAX_PORTS PARPORT_MAX
>
> @@ -1702,7 +1703,11 @@ static int parport_ECP_supported(struct parport *pb)
>  }
>  #endif
>
> -static int intel_bug_present(struct parport *pb)
> +/*  It is believed that CPU model correlates with buggy LPT chipset model.
> +Here we check that or CPU is elder than Pentium Pro: either 80486 or
> Pentium. +If it is then we perform The Check. */
> +#ifdef CONFIG_X86_32
> +static int intel_bug_present_check_epp(struct parport *pb)
>  {
>   const struct parport_pc_private *priv = pb->private_data;
>   int bug_present = 0;
> @@ -1725,6 +1730,20 @@ static int intel_bug_present(struct parport *pb)
>
>   return bug_present;
>  }
> +static int intel_bug_present(struct parport *pb)
> +{
> + struct cpuinfo_x86 *c = &cpu_data(0);
> +
> + if (c->x86_vendor == X86_VENDOR_INTEL && (c->x86 == 4 || c->x86 == 5))
> + return intel_bug_present_check_epp(pb);

You can have a non-Intel CPU in a 486 or Pentium board.

> + return 0;
> +}
> +#else
> +static int intel_bug_present(struct parport *pb)
> +{
> + return 0;
> +}
> +#endif
>
>  static int parport_ECPPS2_supported(struct parport *pb)
>  {



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

Re: [PATCH] CMA: generalize CMA reserved area management functionality (fixup)

[Marek Szyprowski]

Hello,

On 2014-07-18 00:06, Andrew Morton wrote:

On Thu, 17 Jul 2014 11:36:07 +0200 Marek Szyprowski  
wrote:


MAX_CMA_AREAS is used by other subsystems (i.e. arch/arm/mm/dma-mapping.c),
so we need to provide correct definition even if CMA is disabled.
This patch fixes this issue.

Reported-by: Sylwester Nawrocki 
Signed-off-by: Marek Szyprowski 
---
  include/linux/cma.h | 4 
  1 file changed, 4 insertions(+)

diff --git a/include/linux/cma.h b/include/linux/cma.h
index 9a18a2b1934c..c077635cad76 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -5,7 +5,11 @@
   * There is always at least global CMA area and a few optional
   * areas configured in kernel .config.
   */
+#ifdef CONFIG_CMA
  #define MAX_CMA_AREAS (1 + CONFIG_CMA_AREAS)
+#else
+#define MAX_CMA_AREAS  (0)
+#endif
  
  struct cma;

Joonsoo already fixed this up, a bit differently:
http://ozlabs.org/~akpm/mmots/broken-out/cma-generalize-cma-reserved-area-management-functionality-fix.patch

Which approach makes more sense?


CMA_AREAS depends on CMA being enabled, so both approaches works exactly
the same way. Please keep Joonsoo's patch and just ignore mine to avoid
confusing others by disappearing patches. I'm sorry that I've missed it
before sending mine.


From: Joonsoo Kim 
Subject: CMA: fix ARM build failure related to MAX_CMA_AREAS definition

If CMA is disabled, CONFIG_CMA_AREAS isn't defined so compile error
happens. To fix it, define MAX_CMA_AREAS if CONFIG_CMA_AREAS
isn't defined.

Signed-off-by: Joonsoo Kim 
Reported-by: Stephen Rothwell 
Signed-off-by: Andrew Morton 
---

  include/linux/cma.h |6 ++
  1 file changed, 6 insertions(+)

diff -puN 
include/linux/cma.h~cma-generalize-cma-reserved-area-management-functionality-fix
 include/linux/cma.h
--- 
a/include/linux/cma.h~cma-generalize-cma-reserved-area-management-functionality-fix
+++ a/include/linux/cma.h
@@ -5,8 +5,14 @@
   * There is always at least global CMA area and a few optional
   * areas configured in kernel .config.
   */
+#ifdef CONFIG_CMA_AREAS
  #define MAX_CMA_AREAS (1 + CONFIG_CMA_AREAS)
  
+#else

+#define MAX_CMA_AREAS  (0)
+
+#endif
+
  struct cma;
  
  extern phys_addr_t cma_get_base(struct cma *cma);

_


Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland

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

[PATCH v5 1/7] kernel: Add support for kernel restart handler call chain

[Guenter Roeck]

Various drivers implement architecture and/or device specific means
to restart (reset) the system. Various mechanisms have been implemented
to support those schemes. The best known mechanism is arm_pm_restart,
which is a function pointer to be set either from platform specific code
or from drivers. Another mechanism is to use hardware watchdogs to issue
a reset; this mechanism is used if there is no other method available
to reset a board or system. Two examples are alim7101_wdt, which currently
uses the reboot notifier to trigger a reset, and moxart_wdt, which registers
the arm_pm_restart function.

The existing mechanisms have a number of drawbacks. Typically only one scheme
to restart the system is supported (at least if arm_pm_restart is used).
At least in theory there can be multiple means to restart the system, some of
which may be less desirable (for example one mechanism may only reset the CPU,
while another may reset the entire system). Using arm_pm_restart can also be
racy if the function pointer is set from a driver, as the driver may be in
the process of being unloaded when arm_pm_restart is called.
Using the reboot notifier is always racy, as it is unknown if and when
other functions using the reboot notifier have completed execution
by the time the watchdog fires.

Introduce a system restart handler call chain to solve the described problems.
This call chain is expected to be executed from the architecture specific
machine_restart() function. Drivers providing system restart functionality
(such as the watchdog drivers mentioned above) are expected to register
with this call chain. By using the priority field in the notifier block,
callers can control restart handler execution sequence and thus ensure that
the restart handler with the optimal restart capabilities for a given system
is called first.

Signed-off-by: Guenter Roeck 
---
v5: Function renames:
register_restart_notifier -> register_restart_handler
unregister_restart_notifier -> unregister_restart_handler
kernel_restart_notify -> do_kernel_restart
v4: Document and suggest values for notifier priorities
v3: Add kernel_restart_notify wrapper function to execute notifier.
Improve documentation.
Move restart_notifier_list into kernel/reboot.c and make it static.
v2: No change.

 include/linux/reboot.h |  3 ++
 kernel/reboot.c| 81 ++
 2 files changed, 84 insertions(+)

diff --git a/include/linux/reboot.h b/include/linux/reboot.h
index 48bf152..67fc8fc 100644
--- a/include/linux/reboot.h
+++ b/include/linux/reboot.h
@@ -38,6 +38,9 @@ extern int reboot_force;
 extern int register_reboot_notifier(struct notifier_block *);
 extern int unregister_reboot_notifier(struct notifier_block *);
 
+extern int register_restart_handler(struct notifier_block *);
+extern int unregister_restart_handler(struct notifier_block *);
+extern void do_kernel_restart(char *cmd);
 
 /*
  * Architecture-specific implementations of sys_reboot commands.
diff --git a/kernel/reboot.c b/kernel/reboot.c
index a3a9e24..33e8170 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -104,6 +104,87 @@ int unregister_reboot_notifier(struct notifier_block *nb)
 }
 EXPORT_SYMBOL(unregister_reboot_notifier);
 
+/*
+ * Notifier list for kernel code which wants to be called
+ * to restart the system.
+ */
+static BLOCKING_NOTIFIER_HEAD(restart_handler_list);
+
+/**
+ * register_restart_handler - Register function to be called to reset
+ *the system
+ * @nb: Info about handler function to be called
+ * @nb->priority:  Handler priority. Handlers should follow the
+ * following guidelines for setting priorities.
+ * 0:  Restart handler of last resort,
+ * with limited restart capabilities
+ * 128:Default restart handler; use if no other
+ * restart handler is expected to be available,
+ * and/or if restart functionality is
+ * sufficient to restart the entire system
+ * 255:Highest priority restart handler, will
+ * preempt all other restart handlers
+ *
+ * Registers a function with the list of functions
+ * to be called to restart the system.
+ *
+ * Registered functions will be called from machine_restart as last
+ * step of the restart sequence (if the architecture specific
+ * machine_restart function calls do_kernel_restart - see below
+ * for details).
+ * Registered functions are expected to restart the system immediately.
+ * If more than one function is registered, the restart handler priority
+ * selects which function will be called first.
+ *
+ * Restart handlers are expected to be registered from non-architecture
+ * code, typically from drivers. A typical use case would be a s

[PATCH v5 6/7] watchdog: alim7101: Register restart handler with kernel restart handler

[Guenter Roeck]

The kernel core now provides an API to trigger a system restart.
Register with it to restart the system instead of misusing the
reboot notifier.

Signed-off-by: Guenter Roeck 
---
v5: Function and variable renames: *notifier -> *handler
v4: Set restart notifier priority to 128.
v3: No change
v2: No change

 drivers/watchdog/alim7101_wdt.c | 42 +++--
 1 file changed, 32 insertions(+), 10 deletions(-)

diff --git a/drivers/watchdog/alim7101_wdt.c b/drivers/watchdog/alim7101_wdt.c
index 996b2f7..665e0e7 100644
--- a/drivers/watchdog/alim7101_wdt.c
+++ b/drivers/watchdog/alim7101_wdt.c
@@ -301,6 +301,28 @@ static struct miscdevice wdt_miscdev = {
.fops   =   &wdt_fops,
 };
 
+static int wdt_restart_handle(struct notifier_block *this, unsigned long mode,
+ void *cmd)
+{
+   /*
+* Cobalt devices have no way of rebooting themselves other
+* than getting the watchdog to pull reset, so we restart the
+* watchdog on reboot with no heartbeat.
+*/
+   wdt_change(WDT_ENABLE);
+
+   /* loop until the watchdog fires */
+   while (true)
+   ;
+
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block wdt_restart_handler = {
+   .notifier_call = wdt_restart_handle,
+   .priority = 128,
+};
+
 /*
  * Notifier for system down
  */
@@ -311,15 +333,6 @@ static int wdt_notify_sys(struct notifier_block *this,
if (code == SYS_DOWN || code == SYS_HALT)
wdt_turnoff();
 
-   if (code == SYS_RESTART) {
-   /*
-* Cobalt devices have no way of rebooting themselves other
-* than getting the watchdog to pull reset, so we restart the
-* watchdog on reboot with no heartbeat
-*/
-   wdt_change(WDT_ENABLE);
-   pr_info("Watchdog timer is now enabled with no heartbeat - 
should reboot in ~1 second\n");
-   }
return NOTIFY_DONE;
 }
 
@@ -338,6 +351,7 @@ static void __exit alim7101_wdt_unload(void)
/* Deregister */
misc_deregister(&wdt_miscdev);
unregister_reboot_notifier(&wdt_notifier);
+   unregister_restart_handler(&wdt_restart_handler);
pci_dev_put(alim7101_pmu);
 }
 
@@ -390,11 +404,17 @@ static int __init alim7101_wdt_init(void)
goto err_out;
}
 
+   rc = register_restart_handler(&wdt_restart_handler);
+   if (rc) {
+   pr_err("cannot register restart handler (err=%d)\n", rc);
+   goto err_out_reboot;
+   }
+
rc = misc_register(&wdt_miscdev);
if (rc) {
pr_err("cannot register miscdev on minor=%d (err=%d)\n",
   wdt_miscdev.minor, rc);
-   goto err_out_reboot;
+   goto err_out_restart;
}
 
if (nowayout)
@@ -404,6 +424,8 @@ static int __init alim7101_wdt_init(void)
timeout, nowayout);
return 0;
 
+err_out_restart:
+   unregister_restart_handler(&wdt_restart_handler);
 err_out_reboot:
unregister_reboot_notifier(&wdt_notifier);
 err_out:
-- 
1.9.1

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

[PATCH v5 5/7] watchdog: moxart: Register restart handler with kernel restart handler

[Guenter Roeck]

The kernel now provides an API to trigger a system restart.
Register with it instead of setting arm_pm_restart.

Signed-off-by: Guenter Roeck 
---
v5: Functions and variables renamed: *notifier -> *handler
v4: Set notifier priority to 128.
v3: Move struct notifier_block into struct moxart_wdt_dev.
Drop static variable previously needed to access struct moxart_wdt_dev
from notifier function; use container_of instead.
v2: No change.

 drivers/watchdog/moxart_wdt.c | 32 
 1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/drivers/watchdog/moxart_wdt.c b/drivers/watchdog/moxart_wdt.c
index 4aa3a8a..a64405b 100644
--- a/drivers/watchdog/moxart_wdt.c
+++ b/drivers/watchdog/moxart_wdt.c
@@ -15,12 +15,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 
-#include 
-
 #define REG_COUNT  0x4
 #define REG_MODE   0x8
 #define REG_ENABLE 0xC
@@ -29,17 +29,22 @@ struct moxart_wdt_dev {
struct watchdog_device dev;
void __iomem *base;
unsigned int clock_frequency;
+   struct notifier_block restart_handler;
 };
 
-static struct moxart_wdt_dev *moxart_restart_ctx;
-
 static int heartbeat;
 
-static void moxart_wdt_restart(enum reboot_mode reboot_mode, const char *cmd)
+static int moxart_restart_handle(struct notifier_block *this,
+unsigned long mode, void *cmd)
 {
-   writel(1, moxart_restart_ctx->base + REG_COUNT);
-   writel(0x5ab9, moxart_restart_ctx->base + REG_MODE);
-   writel(0x03, moxart_restart_ctx->base + REG_ENABLE);
+   struct moxart_wdt_dev *moxart_wdt = container_of(this,
+struct moxart_wdt_dev,
+restart_handler);
+   writel(1, moxart_wdt->base + REG_COUNT);
+   writel(0x5ab9, moxart_wdt->base + REG_MODE);
+   writel(0x03, moxart_wdt->base + REG_ENABLE);
+
+   return NOTIFY_DONE;
 }
 
 static int moxart_wdt_stop(struct watchdog_device *wdt_dev)
@@ -136,8 +141,12 @@ static int moxart_wdt_probe(struct platform_device *pdev)
if (err)
return err;
 
-   moxart_restart_ctx = moxart_wdt;
-   arm_pm_restart = moxart_wdt_restart;
+   moxart_wdt->restart_handler.notifier_call = moxart_restart_handle;
+   moxart_wdt->restart_handler.priority = 128;
+   err = register_restart_handler(&moxart_wdt->restart_handler);
+   if (err)
+   dev_err(dev, "cannot register restart notifier (err=%d)\n",
+   err);
 
dev_dbg(dev, "Watchdog enabled (heartbeat=%d sec, nowayout=%d)\n",
moxart_wdt->dev.timeout, nowayout);
@@ -149,9 +158,8 @@ static int moxart_wdt_remove(struct platform_device *pdev)
 {
struct moxart_wdt_dev *moxart_wdt = platform_get_drvdata(pdev);
 
-   arm_pm_restart = NULL;
+   unregister_restart_handler(&moxart_wdt->restart_handler);
moxart_wdt_stop(&moxart_wdt->dev);
-   watchdog_unregister_device(&moxart_wdt->dev);
 
return 0;
 }
-- 
1.9.1

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

[PATCH v5 2/7] arm64: Support restart through restart handler call chain

[Guenter Roeck]

The kernel core now supports a restart handler call chain to restart
the system. Call it if arm_pm_restart is not set.

Signed-off-by: Guenter Roeck 
---
v5: Renamed restart function to do_kernel_restart
v4: No change.
v3: Use wrapper function to execute notifier call chain.
v2: Only call notifier call chain if arm_pm_restart is not set.
Do not include linux/watchdog.h.

 arch/arm64/kernel/process.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 43b7c34..9591e60 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -174,6 +174,8 @@ void machine_restart(char *cmd)
/* Now call the architecture specific reboot code. */
if (arm_pm_restart)
arm_pm_restart(reboot_mode, cmd);
+   else
+   do_kernel_restart(cmd);
 
/*
 * Whoops - the architecture was unable to reboot.
-- 
1.9.1

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

[PATCH v5 7/7] arm/arm64: Unexport restart handlers

[Guenter Roeck]

Implementing a restart handler in a module don't make sense
as there would be no guarantee that the module is loaded when
a restart is needed. Unexport arm_pm_restart to ensure that
no one gets the idea to do it anyway.

Signed-off-by: Guenter Roeck 
---
v5: No change
v4: No change
v3: No change
v2: No change

 arch/arm/kernel/process.c   | 1 -
 arch/arm64/kernel/process.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 84ca0d5..27bdf11 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -125,7 +125,6 @@ void (*pm_power_off)(void);
 EXPORT_SYMBOL(pm_power_off);
 
 void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd) = 
null_restart;
-EXPORT_SYMBOL_GPL(arm_pm_restart);
 
 /*
  * This is our default idle handler.
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 9591e60..f5fddff 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -92,7 +92,6 @@ void (*pm_power_off)(void);
 EXPORT_SYMBOL_GPL(pm_power_off);
 
 void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
-EXPORT_SYMBOL_GPL(arm_pm_restart);
 
 /*
  * This is our default idle handler.
-- 
1.9.1

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

[PATCH v5 4/7] power/restart: Call machine_restart instead of arm_pm_restart

[Guenter Roeck]

machine_restart is supported on non-ARM platforms, and and ultimately calls
arm_pm_restart, so dont call arm_pm_restart directly but use the more
generic function.

Cc: Russell King 
Signed-off-by: Guenter Roeck 
---
v5: No change.
v4: No change.
v3: No change.
v2: Added patch.

 drivers/power/reset/restart-poweroff.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/power/reset/restart-poweroff.c 
b/drivers/power/reset/restart-poweroff.c
index 5758033..47f10eb 100644
--- a/drivers/power/reset/restart-poweroff.c
+++ b/drivers/power/reset/restart-poweroff.c
@@ -20,7 +20,8 @@
 
 static void restart_poweroff_do_poweroff(void)
 {
-   arm_pm_restart(REBOOT_HARD, NULL);
+   reboot_mode = REBOOT_HARD;
+   machine_restart(NULL);
 }
 
 static int restart_poweroff_probe(struct platform_device *pdev)
-- 
1.9.1

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

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Richard Weinberger]

Am 18.07.2014 02:36, schrieb Chen Gang:
> 
> On 07/18/2014 02:09 AM, Richard Weinberger wrote:
>> Am 17.07.2014 12:48, schrieb Arnd Bergmann:
>>> AFAICT, NO_IOMEM only has a real purpose on UML these days. Could we take
>>> a shortcut here and make COMPILE_TEST depend on !UML? Getting random stuff
>>> to build on UML seems pointless to me and we special-case it in a number of
>>> places already.
>>
>> If UML is the only arch without io memory the dependency on !UML seems
>> reasonable to me. :-)
>>
> 
> For me, if only uml left, I suggest to implement dummy functions within
> uml instead of let CONFIG_UML appear in generic include directory. And
> then remove all HAS_IOMEM and NO_IOMEM from kernel.

Erm, this is something completely different.
I thought we're focusing on COMPILE_TEST?

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

Executable File Violation

[IT]

You attempted to send a message that contained an executable file. Our company 
policy prohibits the sending of executable files via email. The message was not 
delivered.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC Patch V1 09/30] mm, memcg: Use cpu_to_mem()/numa_mem_id() to support memoryless node

[Michal Hocko]

On Fri 11-07-14 15:37:26, Jiang Liu wrote:
> When CONFIG_HAVE_MEMORYLESS_NODES is enabled, cpu_to_node()/numa_node_id()
> may return a node without memory, and later cause system failure/panic
> when calling kmalloc_node() and friends with returned node id.
> So use cpu_to_mem()/numa_mem_id() instead to get the nearest node with
> memory for the/current cpu.
> 
> If CONFIG_HAVE_MEMORYLESS_NODES is disabled, cpu_to_mem()/numa_mem_id()
> is the same as cpu_to_node()/numa_node_id().

The change makes difference only for really tiny memcgs. If we really
have all pages on unevictable list or anon with no swap allowed and that
is the reason why no node is set in scan_nodes mask then reclaiming
memoryless node or any arbitrary close one doesn't make any difference.
The current memcg might not have any memory on that node at all.

So the change doesn't make any practical difference and the changelog is
misleading.

> Signed-off-by: Jiang Liu 
> ---
>  mm/memcontrol.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index a2c7bcb0e6eb..d6c4b7255ca9 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -1933,7 +1933,7 @@ int mem_cgroup_select_victim_node(struct mem_cgroup 
> *memcg)
>* we use curret node.
>*/
>   if (unlikely(node == MAX_NUMNODES))
> - node = numa_node_id();
> + node = numa_mem_id();
>  
>   memcg->last_scanned_node = node;
>   return node;
> -- 
> 1.7.10.4
> 

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

[PATCH v5 3/7] arm: Support restart through restart handler call chain

[Guenter Roeck]

The kernel core now supports a restart handler call chain for system
restart functions.

With this change, the arm_pm_restart callback is now optional, so check
if it is set before calling it. Only call the kernel restart handler
if arm_pm_restart is not set.

Signed-off-by: Guenter Roeck 
---
v5: Renamed restart function to do_kernel_restart
v4: No change.
v3: Use wrapper function to execute notifier call chain.
v2: Only call notifier call chain if arm_pm_restart is not set.
Do not include linux/watchdog.h.

 arch/arm/kernel/process.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 81ef686..84ca0d5 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -230,7 +230,10 @@ void machine_restart(char *cmd)
local_irq_disable();
smp_send_stop();
 
-   arm_pm_restart(reboot_mode, cmd);
+   if (arm_pm_restart)
+   arm_pm_restart(reboot_mode, cmd);
+   else
+   do_kernel_restart(cmd);
 
/* Give a grace period for failure to restart of 1s */
mdelay(1000);
-- 
1.9.1

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

[PATCH v5 0/7] kernel: Add support for restart handler call chain

[Guenter Roeck]

Various drivers implement architecture and/or device specific means
to restart (reset) the system. Various mechanisms have been implemented
to support those schemes. The best known mechanism is arm_pm_restart,
which is a function pointer to be set either from platform specific code
or from drivers. Another mechanism is to use hardware watchdogs to issue
a reset; this mechanism is used if there is no other method available
to reset a board or system. Two examples are alim7101_wdt, which currently
uses the reboot notifier to trigger a reset, and moxart_wdt, which registers
the arm_pm_restart function. Several other restart drivers for arm, all
directly calling arm_pm_restart, are in the process of being integrated
into the kernel. All those drivers would benefit from the new API.

The existing mechanisms have a number of drawbacks. Typically only one scheme
to restart the system is supported (at least if arm_pm_restart is used).
At least in theory there can be multiple means to restart the system, some of
which may be less desirable (for example one mechanism may only reset the CPU,
while another may reset the entire system). Using arm_pm_restart can also be
racy if the function pointer is set from a driver, as the driver may be in
the process of being unloaded when arm_pm_restart is called.
Using the reboot notifier is always racy, as it is unknown if and when
other functions using the reboot notifier have completed execution
by the time the watchdog fires.

Introduce a system restart handler call chain to solve the described problems.
This call chain is expected to be executed from the architecture specific
machine_restart() function. Drivers providing system restart functionality
(such as the watchdog drivers mentioned above) are expected to register
with this call chain. By using the priority field in the notifier block,
callers can control restart handler execution sequence and thus ensure that
the restart handler with the optimal restart capabilities for a given system
is called first.

Since the first revision of this patchset, a number of separate patch
submissions have been made which either depend on it or could make use of it.

http://www.spinics.net/linux/lists/arm-kernel/msg344796.html
registers three notifiers.
https://lkml.org/lkml/2014/7/8/962
would benefit from it.

Patch 1 of this series implements the restart handler function. Patches 2 and 3
implement calling the restart handler chain from arm and arm64 restart code.

Patch 4 modifies the restart-poweroff driver to no longer call arm_pm_restart
directly but machine_restart. This is done to avoid calling arm_pm_restart
from more than one place. The change makes the driver architecture independent,
so it would be possible to drop the arm dependency from its Kconfig entry.

Patch 5 and 6 convert existing restart handlers in the watchdog subsystem
to use the restart handler. Patch 7 unexports arm_pm_restart to ensure
that no one gets the idea to implement a restart handler as module.

---
v5: Rebased series to v3.16-rc5
Function renames:
register_restart_notifier -> register_restart_handler
unregister_restart_notifier -> unregister_restart_handler
kernel_restart_notify -> do_kernel_restart
v4: Document restart notifier priorities
Select 128 as default priority for newly introduced notifiers
Fix checkpatch warning (line too long) in moxart patch
v3: Drop RFC.
Add kernel_restart_notify wrapper function to execute notifier
Improve documentation.
Move restart_notifier_list into kernel/reboot.c and make it static.
v2: Add patch 4.
Only call blocking notifier call chain if arm_pm_restart was not set.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Sparc: Fix Mes in highmem.c

[Sam Ravnborg]

On Thu, Jul 17, 2014 at 11:05:12PM -0400, Nick Krause wrote:
> On Thu, Jul 17, 2014 at 1:38 PM, Nick Krause  wrote:
> > On Thu, Jul 17, 2014 at 3:52 AM, Sam Ravnborg  wrote:
> >> On Wed, Jul 16, 2014 at 10:25:30PM -0400, Nick Krause wrote:
> >>> I am hitting three Fix mes in this file and am wondering as the
> >>> maintainer how you would like
> >>> to clean them up.
> >>
> >> They may be addressed if we one day decide to give the sparc32 highmem
> >> support a big overhaul. Until then they are left as is.
> >>
> >> Sam
> >  Very well then I will just not touch it until we are going to
> > overhaul the highmem  for
> > sparc32.
> > Cheers Nick
> If you want I can fix the sparc32 highmem area with your help.

This is not just something that one can jump on fixing.

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

Re: Sparc Allmodconfig Fails

[Sam Ravnborg]

On Fri, Jul 18, 2014 at 12:21:04AM -0400, Nick Krause wrote:
> The build for sparc allmodconfig is still failing for the main branch
> of the linux kernel.
> I would recommend fixing these issues. I am attaching my build
> warnings and errors
> logs for the failing build test I did today.

Did you actually look into the log yourself?

This should give you a hint:

make[1]: *** No rule to make target `/media/nick/Nick's', needed by
+`kernel/x509_certificate_list'.  Stop.


All the rest are random warnings that may or may not be specific for sparc64.

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

Re: [x86, irq, ACPI] WARNING: CPU: 13 PID: 11079 at fs/proc/generic.c:521 remove_proc_entry+0x19f/0x1b0()

[Aaron Lu]

On 07/16/2014 02:31 PM, Jiang Liu wrote:
> Hi Aaron,
>   Thanks for reporting this issue. Yinghai has already posted
> a patch to fix the issue by disabling freeing of irq in case of system
> shutdown. Please refer to:
> https://lkml.org/lkml/2014/6/26/619
> 
> Or could you please help to try following patch, which USB free irq
> when shutting down USB controller.

Yes, the patch makes the warning gone.

Regards,
Aaron

> 
> diff --git a/drivers/usb/core/hcd-pci.c b/drivers/usb/core/hcd-pci.c
> index 82044b5d6113..efc953119ce2 100644
> --- a/drivers/usb/core/hcd-pci.c
> +++ b/drivers/usb/core/hcd-pci.c
> @@ -380,6 +380,8 @@ void usb_hcd_pci_shutdown(struct pci_dev *dev)
> if (test_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags) &&
> hcd->driver->shutdown) {
> hcd->driver->shutdown(hcd);
> +   if (usb_hcd_is_primary_hcd(hcd) && hcd->irq > 0)
> +   free_irq(hcd->irq, hcd);
> pci_disable_device(dev);
> }
>  }
> --
> Regards!
> Gerry
> 
> On 2014/7/16 12:19, Aaron Lu wrote:
>> FYI, we noticed the below changes on
>>
>> git://internal_merge_and_test_tree devel-athens-arm-201406220544
>> commit 6a38fa0e3c94dfd1394a71a2d47c9c4d47367374 ("x86, irq, ACPI: Release 
>> IOAPIC pin when PCI device is disabled")
>>
>> +--+++
>> |  | df334bead7 | 
>> 6a38fa0e3c |
>> +--+++
>> | boot_successes   | 25 | 10 
>> |
>> | early-boot-hang  | 1  |
>> |
>> | boot_failures| 0  | 8  
>> |
>> | WARNING:CPU:PID:at_fs/proc/generic.c:remove_proc_entry() | 0  | 8  
>> |
>> | backtrace:SYSC_reboot| 0  | 8  
>> |
>> | backtrace:SyS_reboot | 0  | 8  
>> |
>> +--+++
>>
>>
>> kexecing...
>> kexec -l 
>> /tmp//kernel/x86_64-rhel/aab037e6194df2251b558935d1ed497678a28a98/vmlinuz-3.16.0-rc5-01780-gaab037e
>>  --initrd=/tmp/initrd-10749 --append="user=lkp 
>> job=/lkp/scheduled/ivb43/cyclic_netperf-300s-25%-SCTP_STREAM-HEAD-aab037e6194df2251b558935d1ed497678a28a98.yaml
>>  ARCH=x86_64 
>> BOOT_IMAGE=/kernel/x86_64-rhel/aab037e6194df2251b558935d1ed497678a28a98/vmlinuz-3.16.0-rc5-01780-gaab037e
>>  kconfig=x86_64-rhel commit=aab037e6194df2251b558935d1ed497678a28a98 
>> initrd=/kernel-tests/initrd/lkp-rootfs.cgz root=/dev/ram0 
>> bm_initrd=/lkp/benchmarks/netperf.cgz 
>> modules_initrd=/kernel/x86_64-rhel/aab037e6194df2251b558935d1ed497678a28a98/modules.cgz
>>  max_uptime=1500 
>> RESULT_ROOT=/result/ivb43/netperf/300s-25%-SCTP_STREAM/x86_64-rhel/aab037e6194df2251b558935d1ed497678a28a98/0
>>  ip=ivb43::dhcp oops=panic earlyprintk=ttyS0,115200 debug apic=debug 
>> sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=10 
>> softlockup_panic=1 nmi_watchdog=panic load_ramdisk=2 prompt_ramdisk=0 
>> console=ttyS0,115200 cons

> ole=
>> tty0 vga=normal"
>> [  337.887999] remove_proc_entry: removing non-empty directory 'irq/20', 
>> leaking at least 'ehci_hcd:usb2'
>> [  337.898418] Modules linked in: sctp ipmi_watchdog dm_mod fuse mgag200 
>> syscopyarea sysfillrect snd_pcm sysimgblt ttm snd_timer ahci drm_kms_helper 
>> libahci snd sb_edac soundcore libata drm edac_core i2c_i801 pcspkr wmi 
>> ipmi_si ipmi_msghandler
>> [  337.922594] CPU: 37 PID: 11079 Comm: kexec Not tainted 
>> 3.16.0-rc5-01780-gaab037e #1
>> [  337.931164] Hardware name: Intel Corporation S2600WP/S2600WP, BIOS 
>> SE5C600.86B.02.02.0002.122320131210 12/23/2013
>> [  337.942650]  0009 880ffd1e3b30 8182cb42 
>> 880ffd1e3b78
>> [  337.950976]  880ffd1e3b68 8106d0cd 8808108e3a00 
>> 0002
>> [  337.959316]  880ffd1e3c3e 880801a60ab0 8808108e3a75 
>> 880ffd1e3bc8
>> [  337.967653] Call Trace:
>> [  337.970396]  [] dump_stack+0x4d/0x66
>> [  337.976153]  [] warn_slowpath_common+0x7d/0xa0
>> [  337.982867]  [] warn_slowpath_fmt+0x4c/0x50
>> [  337.989303]  [] remove_proc_entry+0x19f/0x1b0
>> [  337.995931]  [] unregister_irq_proc+0xbf/0xd0
>> [  338.002558]  [] free_desc+0x31/0x90
>> [  338.008212]  [] irq_free_descs+0x3c/0x80
>> [  338.014354]  [] irq_dispose_mapping+0x36/0x50
>> [  338.020983]  [] mp_unmap_irq+0x81/0xb0
>> [  338.026932]  [] acpi_unregister_gsi_ioapic+0x31/0x40
>> [  338.034239]  [] acpi_unregister_gsi+0x17/0x20
>> [  338.040869]  [] acpi_pci_irq_disable+0x8f/0x98
>> [  338.047594]  [] pcibios_disable_de

linux-next: manual merge of the akpm-current tree with the random tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
arch/x86/syscalls/syscall_64.tbl between commit 69d7b7939c24 ("random:
introduce getrandom(2) system call") from the random tree and commit
f5e74a5d7743 ("kexec: new syscall kexec_file_load() declaration") from
the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc arch/x86/syscalls/syscall_64.tbl
index 6705032c0520,6d3545914821..
--- a/arch/x86/syscalls/syscall_64.tbl
+++ b/arch/x86/syscalls/syscall_64.tbl
@@@ -323,7 -323,7 +323,8 @@@
  314   common  sched_setattr   sys_sched_setattr
  315   common  sched_getattr   sys_sched_getattr
  316   common  renameat2   sys_renameat2
 -317   common  kexec_file_load sys_kexec_file_load
 +317   common  getrandom   sys_getrandom
++318   common  kexec_file_load sys_kexec_file_load
  
  #
  # x32-specific system call numbers start at 512 to avoid cache impact


signature.asc
Description: PGP signature

Re: [PATCH v1] x86: fix kernel crash on boot due to NULL dereference

[Andy Shevchenko]

On Fri, Jul 18, 2014 at 12:34 AM, David Cohen
 wrote:
> Hi Andy,
>
> Thanks for the patch.
>
> On Thu, Jul 17, 2014 at 05:59:41PM +0300, Andy Shevchenko wrote:
>> The patch "x86, irq: Count legacy IRQs by legacy_pic->nr_legacy_irqs instead 
>> of
>> NR_IRQS_LEGACY" (linux-next commit 95d76acc7518d566df18d67c1343bb375b78d1f3)
>> removed reserved interrupts for the platforms that do not have a legacy 
>> IOAPIC.
>> Meanwhile it breks a boot on Intel MID platforms such as Medfield.
>
> Have you tested it against Merrifield?

No, I have only Medfield device around me. If you can do that on
Merrifield I will appreciate your Tested-by tag.

>
> Br, David
>
>>
>> [0.00] BUG: unable to handle kernel NULL pointer dereference at 
>> 003a
>> [0.00] IP: [] setup_irq+0xf/0x4d
>> [0.00] *pdpt =  *pde = 9bbf32453167e510
>> [0.00] Oops:  [#1] PREEMPT SMP
>> [0.00] Modules linked in:
>> [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
>> 3.16.0-rc5-next-20140717-00043-g6ab7e8d-dirty #497
>> [0.00] task: c184bc80 ti: c183e000 task.ti: c183e000
>> [0.00] EIP: 0060:[] EFLAGS: 00210046 CPU: 0
>> [0.00] EIP is at setup_irq+0xf/0x4d
>> [0.00] EAX:  EBX: 0002 ECX:  EDX: 0002
>> [0.00] ESI: 00d5 EDI: c184e280 EBP: c183ffc0 ESP: c183ffb4
>> [0.00]  DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
>> [0.00] CR0: 8005003b CR2: 003a CR3: 0195b000 CR4: 06b0
>> [0.00] Stack:
>> [0.00]  0100 00d5 c195c800 c183ffd0 c18eff07 c1935100 
>> 00010800 c183ffd8
>> [0.00]  c18efca0 c183ffe8 c18ec92e c1935100 00020800 c183fff8 
>> c18ec2b4 00020800
>> [0.00]  c195c800 025e5003 
>> [0.00] Call Trace:
>> [0.00]  [] native_init_IRQ+0x265/0x273
>> [0.00]  [] init_IRQ+0x2c/0x2e
>> [0.00]  [] start_kernel+0x1e4/0x32a
>> [0.00]  [] i386_start_kernel+0x82/0x86
>> [0.00] Code: eb 05 bf ea ff ff ff 8b 83 c4 00 00 00 e8 f6 a3 01 00 
>> 8d 65 f4 89 f8 5b 5e 5f 5d c3 55 89 e5 57 89 d7 56 53 89 c3 e8 4b e4 ff ff 
>>  40 3a 02 89 c6 74 16 b8 2b 3e 77 c1 ba 0a 05 00 00 e8 83 60
>> [0.00] EIP: [] setup_irq+0xf/0x4d SS:ESP 0068:c183ffb4
>> [0.00] CR2: 003a
>> [0.00] ---[ end trace cb88537fdc8fa200 ]---
>> [0.00] Kernel panic - not syncing: Attempted to kill the idle task!
>> [0.00] ---[ end Kernel panic - not syncing: Attempted to kill the 
>> idle task!
>>
>> The culprit is an uncoditional setting of the IRQ2 which is used as cascade 
>> IRQ
>> on legacy platforms. It seems we have to check if we have enough legacy IRQs
>> reserved before we can call setup_irq().
>>
>> The proposed patch adds such check.
>>
>> Signed-off-by: Andy Shevchenko 
>> ---
>>  arch/x86/kernel/irqinit.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kernel/irqinit.c b/arch/x86/kernel/irqinit.c
>> index 1e6cff5..44f1ed4 100644
>> --- a/arch/x86/kernel/irqinit.c
>> +++ b/arch/x86/kernel/irqinit.c
>> @@ -203,7 +203,7 @@ void __init native_init_IRQ(void)
>>   set_intr_gate(i, interrupt[i - FIRST_EXTERNAL_VECTOR]);
>>   }
>>
>> - if (!acpi_ioapic && !of_ioapic)
>> + if (!acpi_ioapic && !of_ioapic && nr_legacy_irqs())
>>   setup_irq(2, &irq2);
>>
>>  #ifdef CONFIG_X86_32
>> --
>> 2.0.1
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



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

Re: [PATCH 05/13] thermal: rcar: Document SoC-specific bindings

[Simon Horman]

On Tue, Jul 15, 2014 at 07:16:06PM -0700, Kuninori Morimoto wrote:
> 
> Hi
> 
> > > > The documentation only mentioned the generic fallback compatible 
> > > > property.
> > > > Add the missing SoC-specific compatible properties, some of which are
> > > > already in use.
> > > > 
> > > > Signed-off-by: Geert Uytterhoeven 
> > > > Cc: Zhang Rui 
> > > > Cc: Eduardo Valentin 
> > > > Cc: linux...@vger.kernel.org
> > > 
> > > Acked-by: Simon Horman 
> > 
> > Kuninori,
> > 
> > what' your opinion of this patch?
> > 
> > thanks,
> > rui
> > > 
> > > > ---
> > > >  .../devicetree/bindings/thermal/rcar-thermal.txt   | 18 
> > > > --
> > > >  1 file changed, 12 insertions(+), 6 deletions(-)
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt 
> > > > b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
> > > > index 28ef498a66e5..0ef00be44b01 100644
> > > > --- a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
> > > > +++ b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
> > > > @@ -1,7 +1,13 @@
> > > >  * Renesas R-Car Thermal
> > > >  
> > > >  Required properties:
> > > > -- compatible   : "renesas,rcar-thermal"
> > > > +- compatible   : "renesas,thermal-", 
> > > > "renesas,rcar-thermal"
> > > > + as fallback.
> > > > + Examples with soctypes are:
> > > > +   - "renesas,thermal-r8a73a4" (R-Mobile AP6)
> > > > +   - "renesas,thermal-r8a7779" (R-Car H1)
> > > > +   - "renesas,thermal-r8a7790" (R-Car H2)
> > > > +   - "renesas,thermal-r8a7791" (R-Car M2)
> > > >  - reg  : Address range of the thermal registers.
> > > >   The 1st reg will be recognized as common 
> > > > register
> > > >   if it has "interrupts".
> > > > @@ -12,18 +18,18 @@ Option properties:
> > > >  
> > > >  Example (non interrupt support):
> > > >  
> > > > -thermal@e61f0100 {
> > > > -   compatible = "renesas,rcar-thermal";
> > > > -   reg = <0xe61f0100 0x38>;
> > > > +thermal@ffc48000 {
> > > > +   compatible = "renesas,thermal-r8a7779", "renesas,rcar-thermal";
> > > > +   reg = <0xffc48000 0x38>;
> > > >  };
> > > >  
> > > >  Example (interrupt support):
> > > >  
> > > >  thermal@e61f {
> > > > -   compatible = "renesas,rcar-thermal";
> > > > +   compatible = "renesas,thermal-r8a73a4", "renesas,rcar-thermal";
> > > > reg = <0xe61f 0x14
> > > > 0xe61f0100 0x38
> > > > 0xe61f0200 0x38
> > > > 0xe61f0300 0x38>;
> > > > -   interrupts = <0 69 4>;
> > > > +   interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
> > > >  };
> 
> This patch and [12/13] are adding SoC-specific compatible name.
> Of course we don't know future request,
> and, adding SoC-specific compatible name for
> fallbacking is nice safety for us.
> So, I don't have strong objection about it.
> 
> But, thermal driver side do nothing for each
> SoC-specific compatible name at this point.
> This means
> 
>  -> There is no trouble in driver/SoC
>  -> Add new (and not used) compatible name
>  -> Nothing happen in driver/SoC
> 
> My questions are...
>  1) How to verify this patch ?
>  2) Do we need to update example SoC "specific name" list in rcar-thermal.txt.
> Few example codes are very enough ?

Hi Morimoto-san,

I believe that the approach taken with this patch is similar to the
approach that has been taken for several other drivers used by Renesas
SoCs. The implication of this approach is:

1. That the (in this case thermal) IP on the SoC's listed is known
   to work with the driver using the generic (in this case
   renesas,rcar-thermal) compatibility string.

2. That if some incompatibility is subsequently found such that the
   IP on SoC does function correctly using the generic compatibility
   string or some new feature is to be enabled which is not generic
   then it the driver should be updated with code that is triggered
   by the SoC-specific compat string.

3. That Soc dts(i) files should list the more specific SoC compat string
   followed bu the generic compat string. In this way so long as the
   driver only matches on the generic compat string it will be used. But
   if the driver is updated match on the SoC-specific compat string
   then it will be used instead. In this way dtbs should be forwards
   compatible with driver updates.

   I believe that this series includes patches to update the relevant
   dtsi files accordingly.

In relation to verification, I believe all the SoCs listed in this patch
are known to work with the generic compat string. And they should continue
to work with this change because its only an documentation change. In the
future, if a SoC specific compat string is added to the driver code then
verification would need to occur.

>From my point of

Re: [PATCH] CMA/HOTPLUG: clear buffer-head lru before page migration

[Marek Szyprowski]

Hello,

On 2014-07-18 08:45, Gioh Kim wrote:

For page migration of CMA, buffer-heads of lru should be dropped.
Please refer to https://lkml.org/lkml/2014/7/4/101 for the history.

I have two solution to drop bhs.
One is invalidating entire lru.
Another is searching the lru and dropping only one bh that Laura proposed
at https://lkml.org/lkml/2012/8/31/313.

I'm not sure which has better performance.
So I did performance test on my cortex-a7 platform with Lmbench
that has "File & VM system latencies" test.
I am attaching the results.
The first line is of invalidating entire lru and the second is dropping 
selected bh.

File & VM system latencies in microseconds - smaller is better
---
Host OS   0K File  10K File MmapProt   Page   100fd
 Create Delete Create Delete Latency Fault  Fault  selct
- - -- -- -- -- --- - --- -
10.178.33 Linux 3.10.19   25.1   19.6   32.6   19.7  5098.0 0.666 3.45880 6.506
10.178.33 Linux 3.10.19   24.9   19.5   32.3   19.4  5059.0 0.563 3.46380 6.521


I tried several times but the result tells that they are the same under 1% gap
except Protection Fault.
But the latency of Protection Fault is very small and I think it has little 
effect.

Therefore we can choose anything but I choose invalidating entire lru.
The try_to_free_buffers() which is calling drop_buffers() is called by many 
filesystem code.
So I think inserting codes in drop_buffers() can affect the system.
And also we cannot distinguish migration type in drop_buffers().

In alloc_contig_range() we can distinguish migration type and invalidate lru if 
it needs.
I think alloc_contig_range() is proper to deal with bh like following patch.

Laura, can I have you name on Acked-by line?
Please let me represent my thanks.

Thanks for any feedback.

--- 8< --

>From 33c894b1bab9bc26486716f0c62c452d3a04d35d Mon Sep 17 00:00:00 2001
From: Gioh Kim 
Date: Fri, 18 Jul 2014 13:40:01 +0900
Subject: [PATCH] CMA/HOTPLUG: clear buffer-head lru before page migration

The bh must be free to migrate a page at which bh is mapped.
The reference count of bh is increased when it is installed
into lru so that the bh of lru must be freed before migrating the page.

This frees every bh of lru. We could free only bh of migrating page.
But searching lru costs more than invalidating entire lru.

Signed-off-by: Gioh Kim 
Acked-by: Laura Abbott 
---
  mm/page_alloc.c |3 +++
  1 file changed, 3 insertions(+)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index b99643d4..3b474e0 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6369,6 +6369,9 @@ int alloc_contig_range(unsigned long start, unsigned long 
end,
 if (ret)
 return ret;

+   if (migratetype == MIGRATE_CMA || migratetype == MIGRATE_MOVABLE)


I'm not sure if it really makes sense to check the migratetype here. 
This check
doesn't add any new information to the code and make false impression 
that this
function can be called for other migratetypes than CMA or MOVABLE. Even 
if so,

then invalidating bh_lrus unconditionally will make more sense, IMHO.


+   invalidate_bh_lrus();
+
 ret = __alloc_contig_migrate_range(&cc, start, end);
 if (ret)
 goto done;
--
1.7.9.5



Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland

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

Re: [PATCH 2/4] power_supply: Introduce generic psy charging driver

[Pavel Machek]

Hi!

> > I suggest to add features supported by charger-manager to power supply 
> > charging
> > driver and convert users of charger-manager to the improved driver.
> > 
> > I CC'd MyungJoo Ham, who wrote the charger-manager, so that he can also give
> > feedback.
> 
> We are back to the initial discussions we had in the list. The initial 
> proposal
> was for the charger manager. The charger manager is more aligned to
> regulator framework, use private notification
> mechanisms(cm_notify_event,fullbatt_vchk etc) and relies more on
> platform data (struct charger_desc). This doesn't seems to be good to support 
> plug in
> charger drivers, charging algorithms, battery identification drivers
> at runtime.

>From what I seen, the new "plug in friendly" approach is unsuitable
for the kernel.

I really tried hard to review it, and it went through how many, 10?,
iterations, and it is not getting better.

So please just extend existing code.

If you insist that is not adequate, please talk to some experienced
hacker at Intel (does Rafael still work there? Ingo?) to design
acceptable solution.

Seeing same patches for 10 iterations with no real improvements is not
fun.

Thanks,
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 16/29] nios2: Signal handling support

[Richard Weinberger]

On Tue, Jul 15, 2014 at 10:45 AM, Ley Foon Tan  wrote:
> This patch adds support for signal handling.
>
> Signed-off-by: Ley Foon Tan 
> ---
>  arch/nios2/include/asm/signal.h  |  22 +++
>  arch/nios2/include/asm/ucontext.h|  34 
>  arch/nios2/include/uapi/asm/sigcontext.h |  30 +++
>  arch/nios2/include/uapi/asm/signal.h |  23 +++
>  arch/nios2/kernel/signal.c   | 316 
> +++
>  5 files changed, 425 insertions(+)
>  create mode 100644 arch/nios2/include/asm/signal.h
>  create mode 100644 arch/nios2/include/asm/ucontext.h
>  create mode 100644 arch/nios2/include/uapi/asm/sigcontext.h
>  create mode 100644 arch/nios2/include/uapi/asm/signal.h
>  create mode 100644 arch/nios2/kernel/signal.c
>
> diff --git a/arch/nios2/include/asm/signal.h b/arch/nios2/include/asm/signal.h
> new file mode 100644
> index 000..bbcf11e
> --- /dev/null
> +++ b/arch/nios2/include/asm/signal.h
> @@ -0,0 +1,22 @@
> +/*
> + * Copyright Altera Corporation (C) 2013. All rights reserved
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + *
> + */
> +#ifndef _NIOS2_SIGNAL_H
> +#define _NIOS2_SIGNAL_H
> +
> +#include 
> +
> +#endif /* _NIOS2_SIGNAL_H */
> diff --git a/arch/nios2/include/asm/ucontext.h 
> b/arch/nios2/include/asm/ucontext.h
> new file mode 100644
> index 000..5870ef4
> --- /dev/null
> +++ b/arch/nios2/include/asm/ucontext.h
> @@ -0,0 +1,34 @@
> +/*
> + * Copyright (C) 2010 Tobias Klauser 
> + * Copyright (C) 2004 Microtronix Datacom Ltd
> + *
> + * derived from m68knommu
> + *
> + * This file is subject to the terms and conditions of the GNU General Public
> + * License.  See the file "COPYING" in the main directory of this archive
> + * for more details.
> + */
> +
> +#ifndef _ASM_NIOS2_UCONTEXT_H
> +#define _ASM_NIOS2_UCONTEXT_H
> +
> +typedef int greg_t;
> +#define NGREG 32
> +typedef greg_t gregset_t[NGREG];
> +
> +struct mcontext {
> +   int version;
> +   gregset_t gregs;
> +};
> +
> +#define MCONTEXT_VERSION 2
> +
> +struct ucontext {
> +   unsigned long uc_flags;
> +   struct ucontext  *uc_link;
> +   stack_t   uc_stack;
> +   struct mcontext   uc_mcontext;
> +   sigset_t  uc_sigmask;   /* mask last for extensibility */
> +};
> +
> +#endif
> diff --git a/arch/nios2/include/uapi/asm/sigcontext.h 
> b/arch/nios2/include/uapi/asm/sigcontext.h
> new file mode 100644
> index 000..6bfd880
> --- /dev/null
> +++ b/arch/nios2/include/uapi/asm/sigcontext.h
> @@ -0,0 +1,30 @@
> +/*
> + * Taken from the m68knommu.
> + *
> + * Copyright (C) 2004, Microtronix Datacom Ltd.
> + *
> + * All rights reserved.
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
> + * NON INFRINGEMENT.  See the GNU General Public License for more
> + * details.
> + */
> +
> +#ifndef _ASM_NIOS2_SIGCONTEXT_H
> +#define _ASM_NIOS2_SIGCONTEXT_H
> +
> +#include 
> +
> +struct sigcontext {
> +   struct pt_regs regs;
> +   unsigned long  sc_mask; /* old sigmask */
> +};
> +
> +#endif
> diff --git a/arch/nios2/include/uapi/asm/signal.h 
> b/arch/nios2/include/uapi/asm/signal.h
> new file mode 100644
> index 000..f29ee63
> --- /dev/null
> +++ b/arch/nios2/include/uapi/asm/signal.h
> @@ -0,0 +1,23 @@
> +/*
> + * Copyright Altera Corporation (C) 2013. All rights reserved
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + *
> + */
> +#ifndef _ASM_NIOS

Re: [PATCH 0/2] shmem: fix faulting into a hole while it's punched, take 3

[Vlastimil Babka]

On 07/18/2014 01:34 AM, Hugh Dickins wrote:
> On Thu, 17 Jul 2014, Vlastimil Babka wrote:
>> On 07/15/2014 12:28 PM, Hugh Dickins wrote:
>> > In the end I decided that we had better look at it as two problems,
>> > the trinity faulting starvation, and the indefinite punching loop,
>> > so 1/2 and 2/2 present both solutions: belt and braces.
>> 
>> I tested that with my reproducer and it was OK, but as I already said, it's
>> not trinity so I didn't observe the new problems in the first place.
> 
> Yes, but thanks for doing so anyway.

Now also tested vanilla 3.2.61, also OK.

>> 
>> > Which may be the best for fixing, but the worst for ease of backporting.
>> > Vlastimil, I have prepared (and lightly tested) a 3.2.61-based version
>> > of the combination of f00cdc6df7d7 and 1/2 and 2/2 (basically, I moved
>> > vmtruncate_range from mm/truncate.c to mm/shmem.c, since nothing but
>> > shmem ever implemented the truncate_range method).  It should give a
>> 
>> I don't know how much stable kernel updates are supposed to care about
>> out-of-tree modules,
> 
> I suggest that stable kernel updates do not need to care about
> out-of-tree modules: for so long as they are out of tree, they have
> to look after their own compatibility from one version to another.
> I have no desire to break them gratuitously, but it's not for me
> to spend more time accommodating them.

Fair enough.

> Now, SLES and RHEL and other distros may have different priorities
> from that: if they distribute additional filesystems, which happen to
> support the ->truncate_range() method, or work with partners who supply
> such filesystems, then they may want to rework the shmem-specific
> vmtruncate_range() to allow for those - that's up to them.

Sure, it wasn't my intention to raise any enterprise kernel specific concerns 
here.

>> but doesn't the change mean that an out-of-tree FS
>> supporting truncate_range (if such thing exists) would effectively stop
>> supporting madvise(MADV_REMOVE) after this change?
> 
> Yes, it would need to be reworked a little for them: I've not thought
> through what more would need to be done.  But it seems odd to me that
> an out-of-tree driver would support it, when it got no take up at all
> from in-tree filesystems, even from those which went on to support
> hole-punching in fallocate() (until the tmpfs series brought them in).
> 
> Or perhaps MADV_REMOVE-support is their secret sauce :-?  In that case
> I would expect them to support FALLOC_FL_PUNCH_HOLE already, and prefer
> a backport of v3.5's merging of the madvise and fallocate routes.
> 
>> But hey it's still madvise so maybe we don't need to care.
> 
> That's an argument I would not use, not in Linus's kernel anyway:
> users may have come to rely upon the behaviour of madvise(MADV_REMOVE):
> never mind that it says "advise", I would not be happy to break them.

Right.

>> And I suppose kernels where
>> FALLOC_FL_PUNCH_HOLE is supported, can be backported normally.
> 
> Yes.
> 
> Hugh
> 

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

[PATCH 5/5] memory-hotplug: powerpc: suitable memory should go to ZONE_MOVABLE

[Wang Nan]

This patch add new memory to ZONE_MOVABLE if movable zone is setup
and lower than newly added memory for powerpc.

Signed-off-by: Wang Nan 
---
 arch/powerpc/mm/mem.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 2c8e90f..2d869ef 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -118,6 +118,7 @@ int arch_add_memory(int nid, u64 start, u64 size)
 {
struct pglist_data *pgdata;
struct zone *zone;
+   struct zone *movable_zone;
unsigned long start_pfn = start >> PAGE_SHIFT;
unsigned long nr_pages = size >> PAGE_SHIFT;
 
@@ -129,6 +130,11 @@ int arch_add_memory(int nid, u64 start, u64 size)
 
/* this should work for most non-highmem platforms */
zone = pgdata->node_zones;
+   movable_zone = pgdat->node_zones + ZONE_MOVABLE;
+   if (!zone_is_empty(movable_zone))
+   if (zone_spans_pfn(movable_zone, start_pfn) ||
+   (zone_end_pfn(movable_zone) <= start_pfn))
+   zone = movable_zone;
 
return __add_pages(nid, zone, start_pfn, nr_pages);
 }
-- 
1.8.4

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

[PATCH 4/5] memory-hotplug: sh: suitable memory should go to ZONE_MOVABLE

[Wang Nan]

This patch add new memory to ZONE_MOVABLE if movable zone is setup
and lower than newly added memory for sh.

Signed-off-by: Wang Nan 
---
 arch/sh/mm/init.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/arch/sh/mm/init.c b/arch/sh/mm/init.c
index 2d089fe..ff9decc 100644
--- a/arch/sh/mm/init.c
+++ b/arch/sh/mm/init.c
@@ -487,16 +487,19 @@ void free_initrd_mem(unsigned long start, unsigned long 
end)
 #ifdef CONFIG_MEMORY_HOTPLUG
 int arch_add_memory(int nid, u64 start, u64 size)
 {
-   pg_data_t *pgdat;
+   pg_data_t *pgdat = NODE_DATA(nid);
unsigned long start_pfn = start >> PAGE_SHIFT;
unsigned long nr_pages = size >> PAGE_SHIFT;
+   struct zone *zone = pgdat->node_zones + ZONE_NORMAL;
+   struct zone *movable_zone = pgdat->node_zones + ZONE_MOVABLE;
int ret;
 
-   pgdat = NODE_DATA(nid);
+   if (!zone_is_empty(movable_zone))
+   if (zone_spans_pfn(movable_zone, start_pfn) ||
+   (zone_end_pfn(movable_zone) <= start_pfn))
+   zone = movable_zone;
 
-   /* We only have ZONE_NORMAL, so this is easy.. */
-   ret = __add_pages(nid, pgdat->node_zones + ZONE_NORMAL,
-   start_pfn, nr_pages);
+   ret = __add_pages(nid, zone, start_pfn, nr_pages);
if (unlikely(ret))
printk("%s: Failed, __add_pages() == %d\n", __func__, ret);
 
-- 
1.8.4

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

[PATCH 1/5] memory-hotplug: x86_64: suitable memory should go to ZONE_MOVABLE

[Wang Nan]

This patch add new memory to ZONE_MOVABLE if movable zone is setup
and lower than newly added memory for x86_64.

Signed-off-by: Wang Nan 
---
 arch/x86/mm/init_64.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index df1a992..825915e 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -685,17 +685,23 @@ static void  update_end_of_memory_vars(u64 start, u64 
size)
 }
 
 /*
- * Memory is added always to NORMAL zone. This means you will never get
- * additional DMA/DMA32 memory.
+ * Memory is added always to NORMAL or MOVABLE zone. This means you
+ * will never get additional DMA/DMA32 memory.
  */
 int arch_add_memory(int nid, u64 start, u64 size)
 {
struct pglist_data *pgdat = NODE_DATA(nid);
struct zone *zone = pgdat->node_zones + ZONE_NORMAL;
+   struct zone *movable_zone = pgdat->node_zones + ZONE_MOVABLE;
unsigned long start_pfn = start >> PAGE_SHIFT;
unsigned long nr_pages = size >> PAGE_SHIFT;
int ret;
 
+   if (!zone_is_empty(movable_zone))
+   if (zone_spans_pfn(movable_zone, start_pfn) ||
+   (zone_end_pfn(movable_zone) <= start_pfn))
+   zone = movable_zone;
+
init_memory_mapping(start, start + size);
 
ret = __add_pages(nid, zone, start_pfn, nr_pages);
-- 
1.8.4

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

[PATCH 2/5] memory-hotplug: x86_32: suitable memory should go to ZONE_MOVABLE

[Wang Nan]

This patch add new memory to ZONE_MOVABLE if movable zone is setup
and lower than newly added memory for x86_32.

Signed-off-by: Wang Nan 
---
 arch/x86/mm/init_32.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index e395048..dd69833 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -826,9 +826,15 @@ int arch_add_memory(int nid, u64 start, u64 size)
 {
struct pglist_data *pgdata = NODE_DATA(nid);
struct zone *zone = pgdata->node_zones + ZONE_HIGHMEM;
+   struct zone *movable_zone = pgdat->node_zones + ZONE_MOVABLE;
unsigned long start_pfn = start >> PAGE_SHIFT;
unsigned long nr_pages = size >> PAGE_SHIFT;
 
+   if (!zone_is_empty(movable_zone))
+   if (zone_spans_pfn(movable_zone, start_pfn) ||
+   (zone_end_pfn(movable_zone) <= start_pfn))
+   zone = movable_zone;
+
return __add_pages(nid, zone, start_pfn, nr_pages);
 }
 
-- 
1.8.4

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

[PATCH 0/5] memory-hotplug: suitable memory should go to ZONE_MOVABLE

[Wang Nan]

This series of patches fix a problem when adding memory in bad manner.
For example: for a x86_64 machine booted with "mem=400M" and with 2GiB
memory installed, following commands cause problem:

 # echo 0x4000 > /sys/devices/system/memory/probe
[   28.613895] init_memory_mapping: [mem 0x4000-0x47ff]
 # echo 0x4800 > /sys/devices/system/memory/probe
[   28.693675] init_memory_mapping: [mem 0x4800-0x4fff]
 # echo online_movable > /sys/devices/system/memory/memory9/state
 # echo 0x5000 > /sys/devices/system/memory/probe 
[   29.084090] init_memory_mapping: [mem 0x5000-0x57ff]
 # echo 0x5800 > /sys/devices/system/memory/probe 
[   29.151880] init_memory_mapping: [mem 0x5800-0x5fff]
 # echo online_movable > /sys/devices/system/memory/memory11/state
 # echo online> /sys/devices/system/memory/memory8/state
 # echo online> /sys/devices/system/memory/memory10/state
 # echo offline> /sys/devices/system/memory/memory9/state
[   30.558819] Offlined Pages 32768
 # free
 total   used   free sharedbuffers cached
Mem:780588 18014398509432020 830552  0  0  51180
-/+ buffers/cache: 18014398509380840 881732
Swap:0  0  0

This is because the above commands probe higher memory after online a
section with online_movable, which causes ZONE_HIGHMEM (or ZONE_NORMAL
for systems without ZONE_HIGHMEM) overlaps ZONE_MOVABLE.

After the second online_movable, the problem can be observed from
zoneinfo:

 # cat /proc/zoneinfo
...
Node 0, zone  Movable
  pages free 65491
min  250
low  312
high 375
scanned  0
spanned  18446744073709518848
present  65536
managed  65536
...

This series of patches solve the problem by checking ZONE_MOVABLE when
choosing zone for new memory. If new memory is inside or higher than
ZONE_MOVABLE, makes it go there instead.


Wang Nan (5):
  memory-hotplug: x86_64: suitable memory should go to ZONE_MOVABLE
  memory-hotplug: x86_32: suitable memory should go to ZONE_MOVABLE
  memory-hotplug: ia64: suitable memory should go to ZONE_MOVABLE
  memory-hotplug: sh: suitable memory should go to ZONE_MOVABLE
  memory-hotplug: powerpc: suitable memory should go to ZONE_MOVABLE

 arch/ia64/mm/init.c   |  7 +++
 arch/powerpc/mm/mem.c |  6 ++
 arch/sh/mm/init.c | 13 -
 arch/x86/mm/init_32.c |  6 ++
 arch/x86/mm/init_64.c | 10 --
 5 files changed, 35 insertions(+), 7 deletions(-)

-- 
1.8.4

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

Re: [RFC 1/2] workqueue: use the nearest NUMA node, not the local one

[Lai Jiangshan]

Hi,

I'm curious about what will it happen when alloc_pages_node(memoryless_node).

If the memory is allocated from the most preferable node for the 
@memoryless_node,
why we need to bother and use cpu_to_mem() in the caller site?

If not, why the memory allocation subsystem refuses to find a preferable node
for @memoryless_node in this case? Does it intend on some purpose or
it can't find in some cases?

Thanks,
Lai

Added CC to Tejun (workqueue maintainer).

On 07/18/2014 07:09 AM, Nishanth Aravamudan wrote:
> In the presence of memoryless nodes, the workqueue code incorrectly uses
> cpu_to_node() to determine what node to prefer memory allocations come
> from. cpu_to_mem() should be used instead, which will use the nearest
> NUMA node with memory.
> 
> Signed-off-by: Nishanth Aravamudan 
> 
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index 35974ac..0bba022 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -3547,7 +3547,12 @@ static struct worker_pool *get_unbound_pool(const 
> struct workqueue_attrs *attrs)
>   for_each_node(node) {
>   if (cpumask_subset(pool->attrs->cpumask,
>  wq_numa_possible_cpumask[node])) {
> - pool->node = node;
> + /*
> +  * We could use local_memory_node(node) here,
> +  * but it is expensive and the following caches
> +  * the same value.
> +  */
> + pool->node = 
> cpu_to_mem(cpumask_first(pool->attrs->cpumask));
>   break;
>   }
>   }
> @@ -4921,7 +4926,7 @@ static int __init init_workqueues(void)
>   pool->cpu = cpu;
>   cpumask_copy(pool->attrs->cpumask, cpumask_of(cpu));
>   pool->attrs->nice = std_nice[i++];
> - pool->node = cpu_to_node(cpu);
> + pool->node = cpu_to_mem(cpu);
>  
>   /* alloc pool ID */
>   mutex_lock(&wq_pool_mutex);
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/5] memory-hotplug: ia64: suitable memory should go to ZONE_MOVABLE

[Wang Nan]

This patch add new memory to ZONE_MOVABLE if movable zone is setup
and lower than newly added memory for ia64.

Signed-off-by: Wang Nan 
---
 arch/ia64/mm/init.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
index 25c3502..d81c916 100644
--- a/arch/ia64/mm/init.c
+++ b/arch/ia64/mm/init.c
@@ -625,6 +625,7 @@ int arch_add_memory(int nid, u64 start, u64 size)
 {
pg_data_t *pgdat;
struct zone *zone;
+   struct zone *movable_zone;
unsigned long start_pfn = start >> PAGE_SHIFT;
unsigned long nr_pages = size >> PAGE_SHIFT;
int ret;
@@ -632,6 +633,12 @@ int arch_add_memory(int nid, u64 start, u64 size)
pgdat = NODE_DATA(nid);
 
zone = pgdat->node_zones + ZONE_NORMAL;
+   movable_zone = pgdat->node_zones + ZONE_MOVABLE;
+   if (!zone_is_empty(movable_zone))
+   if (zone_spans_pfn(movable_zone, start_pfn) ||
+   (zone_end_pfn(movable_zone) <= start_pfn))
+   zone = movable_zone;
+
ret = __add_pages(nid, zone, start_pfn, nr_pages);
 
if (ret)
-- 
1.8.4

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

Re: [PATCH V3 0/3] Add new PowerPC specific ELF core notes

[Anshuman Khandual]

On 07/18/2014 04:53 AM, Sam Bobroff wrote:
> On 17/07/14 21:14, Michael Neuling wrote:
>>
>> On Jul 17, 2014 9:11 PM, "Benjamin Herrenschmidt"
>> mailto:b...@kernel.crashing.org>> wrote:
>>>
>
>> Outstanding Issues
>> ==
>> (1) Running DSCR register value inside a transaction does not
>> seem to be saved
>> at thread.dscr when the process stops for ptrace examination.
>
> Hey Ben,
>
> Any updates on this patch series ?

 Ben,

 Any updates on this patch series ?
>>>
>>> I haven't had a chance to review yet, I was hoping somebody else would..
>>>
>>> Have you made any progress vs. the DSCR outstanding issue mentioned
>>> above ?
>>
>> The DSCR issue should be resolved with Sam Bobroff's recent  DSCR
>> fixes.  I've not tested them though.
>>
>> Actually... Sam did you review this series?
>>
>> Mikey
>>
> 
> I did, and applying "powerpc: Correct DSCR during TM context switch"
> corrected the DSCR value in the test program (the one in the patch notes
> for this series).
> 
> (In fact, IIRC, the reason for my patch set was the bug exposed by this
> one ;-)

Yeah the test program worked correctly with the fix from Sam. The first patch
is a generic code change which Pedro had reviewed before. The second and third
patches are powerpc specific.

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

checksyscall warning: #warning syscall getrandom not implemented

[Theodore Ts'o]

On Fri, Jul 18, 2014 at 07:48:49AM +0800, kbuild test robot wrote:
> All warnings:
> 
>:1229:2: warning: #warning syscall sched_setattr not implemented 
> [-Wcpp]
>:1232:2: warning: #warning syscall sched_getattr not implemented 
> [-Wcpp]
>:1235:2: warning: #warning syscall renameat2 not implemented [-Wcpp]
> >> :1238:2: warning: #warning syscall getrandom not implemented [-Wcpp]
> --
>kernel/time/Kconfig:162:warning: range is invalid
>:1229:2: warning: #warning syscall sched_setattr not implemented 
> [-Wcpp]
>:1232:2: warning: #warning syscall sched_getattr not implemented 
> [-Wcpp]
>:1235:2: warning: #warning syscall renameat2 not implemented [-Wcpp]
> >> :1238:2: warning: #warning syscall getrandom not implemented [-Wcpp]

I was trying to figure out why this warning was happening, because I
was pretty sure I had properly wired up the getrandom syscall.  It
looks like the problem was a stale unistd_32.h.

At some point, apprently the generated unistd.h file migrated from:

arch/x86/include/generated/asm/unistd_32.h

to

arch/x86/include/generated/uapi/asm/unistd_32.h

The stale unistd_32.h which was getting picked up by the checksyscalls
script, and this was causing all of these warnings --- both in my
tree, and apparently, the kbuild test robot's tree.  It looks like
after the migration, the Makefiles aren't deleting the old generated
unistd.h file automatically.  I tried to go through the Makefiles,
quickly got a headache, and decided it was easier to report the
problem than to send a patch :-P

There's a simple workaround anyway.  Once I deleted the old, stale,
generated unistd_32.h file, and reran the build, all of the
checksyscall warnings went away.

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

Re: [PATCH] checkpatch.pl: Remove --file option

[Guenter Roeck]

On 07/17/2014 08:34 AM, Richard Weinberger wrote:

checkpatch.pl is a nice tool to find issues in patches.
Sadly this tool gets more and more  abused by various people to create
style cleanups for source files within the kernel.
In order to deal with that bad habit let's remove the --file option
and bring checkpatch.pl back to its original purpose.



I have a number of problems with this patch.

First, 'abuse' is a relative term. It describes a use you
(and possibly many others) may find objectionable, but that
does not mean all uses are objectionable.

Second, just because something is abused doesn't mean it would be
a good idea to take it away. Many of the amendmends to the US
Constitution can be abused. Should freedom of speech be taken away
because it can be abused ? I hope not. Many drugs can be abused.
Should they be taken away ? I hope not. And so on.

Using your argument, you can take away anything that can be abused,
which is pretty much everything. Not a good idea.

Guenter

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

Re: [PATCH v7 01/24] mfd: max77686: Convert to use regmap_irq

[Lee Jones]

> By using the generic IRQ support in the Register map API, it
> is possible to get rid max77686-irq.c and simplify the code.
> 
> Suggested-by: Krzysztof Kozlowski 
> Signed-off-by: Javier Martinez Canillas 
> Acked-by: Lee Jones 
> Reviewed-by: Doug Anderson 
> Tested-by: Doug Anderson 

Applied now, thanks.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 03/24] mfd: max77686: Don't define dummy function if OF isn't enabled

[Lee Jones]

On Fri, 04 Jul 2014, Javier Martinez Canillas wrote:

> When the CONFIG_OF option was not enabled, a dummy function
> max77686_i2c_parse_dt_pdata() was defined since this is called
> unconditionally on probe(). Just always define the real function
> and conditionally call it if CONFIG_OF is enabled instead.
> 
> Signed-off-by: Javier Martinez Canillas 
> ---
>  drivers/mfd/max77686.c | 10 +-
>  1 file changed, 1 insertion(+), 9 deletions(-)

Applied now, thanks.

> diff --git a/drivers/mfd/max77686.c b/drivers/mfd/max77686.c
> index a38e9ee..d1f9d04 100644
> --- a/drivers/mfd/max77686.c
> +++ b/drivers/mfd/max77686.c
> @@ -96,7 +96,6 @@ static const struct regmap_irq_chip max77686_rtc_irq_chip = 
> {
>   .num_irqs   = ARRAY_SIZE(max77686_rtc_irqs),
>  };
>  
> -#ifdef CONFIG_OF
>  static const struct of_device_id max77686_pmic_dt_match[] = {
>   {.compatible = "maxim,max77686", .data = NULL},
>   {},
> @@ -116,13 +115,6 @@ static struct max77686_platform_data 
> *max77686_i2c_parse_dt_pdata(struct device
>   dev->platform_data = pd;
>   return pd;
>  }
> -#else
> -static struct max77686_platform_data *max77686_i2c_parse_dt_pdata(struct 
> device
> -   *dev)
> -{
> - return 0;
> -}
> -#endif
>  
>  static int max77686_i2c_probe(struct i2c_client *i2c,
> const struct i2c_device_id *id)
> @@ -132,7 +124,7 @@ static int max77686_i2c_probe(struct i2c_client *i2c,
>   unsigned int data;
>   int ret = 0;
>  
> - if (i2c->dev.of_node)
> + if (IS_ENABLED(CONFIG_OF) && i2c->dev.of_node)
>   pdata = max77686_i2c_parse_dt_pdata(&i2c->dev);
>  
>   if (!pdata) {

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 02/24] mfd: max77686: Add power management support

[Lee Jones]

On Fri, 04 Jul 2014, Javier Martinez Canillas wrote:

> The driver doesn't have PM operations defined so add a suspend
> and resume function handlers to allow the PMIC IRQ to wakeup
> the system when it is put into a sleep state.
> 
> Signed-off-by: Javier Martinez Canillas 
> Reviewed-by: Krzysztof Kozlowski 
> ---
>  drivers/mfd/max77686.c | 40 
>  1 file changed, 40 insertions(+)

Applied now, thanks.

> diff --git a/drivers/mfd/max77686.c b/drivers/mfd/max77686.c
> index 3cb41d0..a38e9ee 100644
> --- a/drivers/mfd/max77686.c
> +++ b/drivers/mfd/max77686.c
> @@ -240,10 +240,50 @@ static const struct i2c_device_id max77686_i2c_id[] = {
>  };
>  MODULE_DEVICE_TABLE(i2c, max77686_i2c_id);
>  
> +#ifdef CONFIG_PM_SLEEP
> +static int max77686_suspend(struct device *dev)
> +{
> + struct i2c_client *i2c = container_of(dev, struct i2c_client, dev);
> + struct max77686_dev *max77686 = i2c_get_clientdata(i2c);
> +
> + if (device_may_wakeup(dev))
> + enable_irq_wake(max77686->irq);
> +
> + /*
> +  * IRQ must be disabled during suspend because if it happens
> +  * while suspended it will be handled before resuming I2C.
> +  *
> +  * When device is woken up from suspend (e.g. by RTC wake alarm),
> +  * an interrupt occurs before resuming I2C bus controller.
> +  * Interrupt handler tries to read registers but this read
> +  * will fail because I2C is still suspended.
> +  */
> + disable_irq(max77686->irq);
> +
> + return 0;
> +}
> +
> +static int max77686_resume(struct device *dev)
> +{
> + struct i2c_client *i2c = container_of(dev, struct i2c_client, dev);
> + struct max77686_dev *max77686 = i2c_get_clientdata(i2c);
> +
> + if (device_may_wakeup(dev))
> + disable_irq_wake(max77686->irq);
> +
> + enable_irq(max77686->irq);
> +
> + return 0;
> +}
> +#endif /* CONFIG_PM_SLEEP */
> +
> +static SIMPLE_DEV_PM_OPS(max77686_pm, max77686_suspend, max77686_resume);
> +
>  static struct i2c_driver max77686_i2c_driver = {
>   .driver = {
>  .name = "max77686",
>  .owner = THIS_MODULE,
> +.pm = &max77686_pm,
>  .of_match_table = of_match_ptr(max77686_pmic_dt_match),
>   },
>   .probe = max77686_i2c_probe,

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFA][PATCH 22/27] microblaze: ftrace: Remove check of obsolete variable function_trace_stop

[Michal Simek]

Hi Steve,

On 07/15/2014 11:51 PM, Steven Rostedt wrote:
> Michal,
> 
> Can you please test and ack this and patch 6 of this series. Otherwise I
> may have to stip it out of the series which will break the build on
> microblaze.
> 
> You can test my branch at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
> rfc/remove-function-trace-stop

I have tested this full branch and there is no issue on Microblaze that's why
here is:
Tested-by: Michal Simek 

Thanks,
Michal












signature.asc
Description: OpenPGP digital signature

Re: [PATCH v7 06/24] mfd: max77686: Make error checking consistent

[Lee Jones]

On Fri, 04 Jul 2014, Javier Martinez Canillas wrote:

> Error checking across the driver is mostly consistent besides
> a few exceptions, so change these exceptions for consistency.
> 
> Signed-off-by: Javier Martinez Canillas 
> Reviewed-by: Krzysztof Kozlowski 
> ---
>  drivers/mfd/max77686.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)

Applied now, thanks.

> diff --git a/drivers/mfd/max77686.c b/drivers/mfd/max77686.c
> index ada4976..87fe52e 100644
> --- a/drivers/mfd/max77686.c
> +++ b/drivers/mfd/max77686.c
> @@ -134,7 +134,7 @@ static int max77686_i2c_probe(struct i2c_client *i2c,
>  
>   max77686 = devm_kzalloc(&i2c->dev,
>   sizeof(struct max77686_dev), GFP_KERNEL);
> - if (max77686 == NULL)
> + if (!max77686)
>   return -ENOMEM;
>  
>   i2c_set_clientdata(i2c, max77686);
> @@ -153,8 +153,8 @@ static int max77686_i2c_probe(struct i2c_client *i2c,
>   return ret;
>   }
>  
> - if (regmap_read(max77686->regmap,
> -  MAX77686_REG_DEVICE_ID, &data) < 0) {
> + ret = regmap_read(max77686->regmap, MAX77686_REG_DEVICE_ID, &data);
> + if (ret < 0) {
>   dev_err(max77686->dev,
>   "device not found on this channel (this is not an 
> error)\n");
>   return -ENODEV;
> @@ -180,7 +180,7 @@ static int max77686_i2c_probe(struct i2c_client *i2c,
> IRQF_TRIGGER_FALLING | IRQF_ONESHOT |
> IRQF_SHARED, 0, &max77686_irq_chip,
> &max77686->irq_data);
> - if (ret != 0) {
> + if (ret) {
>   dev_err(&i2c->dev, "failed to add PMIC irq chip: %d\n", ret);
>   goto err_unregister_i2c;
>   }
> @@ -188,7 +188,7 @@ static int max77686_i2c_probe(struct i2c_client *i2c,
> IRQF_TRIGGER_FALLING | IRQF_ONESHOT |
> IRQF_SHARED, 0, &max77686_rtc_irq_chip,
> &max77686->rtc_irq_data);
> - if (ret != 0) {
> + if (ret) {
>   dev_err(&i2c->dev, "failed to add RTC irq chip: %d\n", ret);
>   goto err_del_irqc;
>   }

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 07/24] mfd: max77686: Remove unneeded OOM error message

[Lee Jones]

On Fri, 04 Jul 2014, Javier Martinez Canillas wrote:

> There is no need to print out-of-memory errors since this is already
> done by the memory management subsystem which even calls dump_stack().
> 
> Signed-off-by: Javier Martinez Canillas 
> ---
>  drivers/mfd/max77686.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)

Applied now, thanks.

> diff --git a/drivers/mfd/max77686.c b/drivers/mfd/max77686.c
> index 87fe52e..8650832 100644
> --- a/drivers/mfd/max77686.c
> +++ b/drivers/mfd/max77686.c
> @@ -107,10 +107,8 @@ static struct max77686_platform_data 
> *max77686_i2c_parse_dt_pdata(struct device
>   struct max77686_platform_data *pd;
>  
>   pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
> - if (!pd) {
> - dev_err(dev, "could not allocate memory for pdata\n");
> + if (!pd)
>   return NULL;
> - }
>  
>   dev->platform_data = pd;
>   return pd;

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linux-zigbee-devel] [PATCH net-next v9 3/9] net: nl802154 - make add_iface take name assign type

[Alexander Aring]

On Thu, Jul 17, 2014 at 04:19:31PM -0700, David Miller wrote:
> From: Tom Gundersen 
> Date: Thu, 17 Jul 2014 10:06:04 +0200
> 
> > @@ -192,8 +193,10 @@ int ieee802154_add_iface(struct sk_buff *skb, struct 
> > genl_info *info)
> > if (devname[nla_len(info->attrs[IEEE802154_ATTR_DEV_NAME]) - 1]
> > != '\0')
> > return -EINVAL; /* phy name should be null-terminated */
> > +   name_assign_type = NET_NAME_USER;
> > } else  {
> > devname = "wpan%d";
> > +   name_assign_type = NET_NAME_ENUM;
> > }
> >  
> > if (strlen(devname) >= IFNAMSIZ)
> 
> Just wondering what should happen if "%d" appears in a user provided name.
> 

I tested it. If I use a name like "foobar%d" then I get a foobar0,
foobar1 ... foobarX.

> That would seem to be both USER and ENUM.
> 

yes.


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

Re: [RFA][PATCH 06/27] microblaze: ftrace: Add call to ftrace_graph_is_dead() in function graph code

[Michal Simek]

Hi Steve,

On 07/09/2014 04:03 PM, Steven Rostedt wrote:
> Michal,
> 
> Can you ack this please?
> 
> -- Steve
> 
> 
> On Thu, 26 Jun 2014 12:52:27 -0400
> Steven Rostedt  wrote:
> 
>> From: "Steven Rostedt (Red Hat)" 
>>
>> ftrace_stop() is going away as it disables parts of function tracing
>> that affects users that should not be affected. But ftrace_graph_stop()
>> is built on ftrace_stop(). Here's another example of killing all of
>> function tracing because something went wrong with function graph
>> tracing.
>>
>> Instead of disabling all users of function tracing on function graph
>> error, disable only function graph tracing. To do this, the arch code
>> must call ftrace_graph_is_dead() before it implements function graph.
>>
>> Cc: Michal Simek 
>> Signed-off-by: Steven Rostedt 
>> ---
>>  arch/microblaze/kernel/ftrace.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/microblaze/kernel/ftrace.c 
>> b/arch/microblaze/kernel/ftrace.c
>> index bbcd2533766c..fc7b48a52cd5 100644
>> --- a/arch/microblaze/kernel/ftrace.c
>> +++ b/arch/microblaze/kernel/ftrace.c
>> @@ -27,6 +27,9 @@ void prepare_ftrace_return(unsigned long *parent, unsigned 
>> long self_addr)
>>  unsigned long return_hooker = (unsigned long)
>>  &return_to_handler;
>>  
>> +if (unlikely(ftrace_graph_is_dead()))
>> +return;
>> +
>>  if (unlikely(atomic_read(¤t->tracing_graph_pause)))
>>  return;
>>  
> 

sorry for delay. Here is mine.

Tested-by: Michal Simek 

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




signature.asc
Description: OpenPGP digital signature

Re: [PATCH v7 05/24] mfd: max77686: Return correct error when pdata isn't found

[Lee Jones]

On Fri, 04 Jul 2014, Javier Martinez Canillas wrote:

> When platform data is not found an -EIO (I/O error) code is returned.
> This doesn't seem to be the correct error so better return -EINVAL
> (Invalid argument) which is what most drivers do in this case.
> 
> Signed-off-by: Javier Martinez Canillas 
> ---
>  drivers/mfd/max77686.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied now, thanks.

> diff --git a/drivers/mfd/max77686.c b/drivers/mfd/max77686.c
> index 12d4c17..ada4976 100644
> --- a/drivers/mfd/max77686.c
> +++ b/drivers/mfd/max77686.c
> @@ -129,7 +129,7 @@ static int max77686_i2c_probe(struct i2c_client *i2c,
>  
>   if (!pdata) {
>   dev_err(&i2c->dev, "No platform data found.\n");
> - return -EIO;
> + return -EINVAL;
>   }
>  
>   max77686 = devm_kzalloc(&i2c->dev,

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 04/24] mfd: max77686: Make platform data over-rule DT

[Lee Jones]

On Fri, 04 Jul 2014, Javier Martinez Canillas wrote:

> The function max77802_i2c_parse_dt_pdata() should only be called
> if there isn't already platform data for the device.
> 
> Signed-off-by: Javier Martinez Canillas 
> ---
>  drivers/mfd/max77686.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied now, thanks.

> diff --git a/drivers/mfd/max77686.c b/drivers/mfd/max77686.c
> index d1f9d04..12d4c17 100644
> --- a/drivers/mfd/max77686.c
> +++ b/drivers/mfd/max77686.c
> @@ -124,7 +124,7 @@ static int max77686_i2c_probe(struct i2c_client *i2c,
>   unsigned int data;
>   int ret = 0;
>  
> - if (IS_ENABLED(CONFIG_OF) && i2c->dev.of_node)
> + if (IS_ENABLED(CONFIG_OF) && i2c->dev.of_node && !pdata)
>   pdata = max77686_i2c_parse_dt_pdata(&i2c->dev);
>  
>   if (!pdata) {

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] checkpatch.pl: Remove --file option

[Borislav Petkov]

On Fri, Jul 18, 2014 at 12:29:37AM -0700, Guenter Roeck wrote:
> First, 'abuse' is a relative term. It describes a use you
> (and possibly many others) may find objectionable, but that
> does not mean all uses are objectionable.

Do you actually have a valid use case for keeping the cmdline switch ...

> Second, just because something is abused doesn't mean it would be
> a good idea to take it away. Many of the amendmends to the US
> Constitution can be abused. Should freedom of speech be taken away
> because it can be abused ?

... or do you feel political and want to do some waste-of-time debating
today just because its Friday?

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] CMA/HOTPLUG: clear buffer-head lru before page migration

[Gioh Kim]

2014-07-18 오후 4:50, Marek Szyprowski 쓴 글:

Hello,

On 2014-07-18 08:45, Gioh Kim wrote:

For page migration of CMA, buffer-heads of lru should be dropped.
Please refer to https://lkml.org/lkml/2014/7/4/101 for the history.

I have two solution to drop bhs.
One is invalidating entire lru.
Another is searching the lru and dropping only one bh that Laura proposed
at https://lkml.org/lkml/2012/8/31/313.

I'm not sure which has better performance.
So I did performance test on my cortex-a7 platform with Lmbench
that has "File & VM system latencies" test.
I am attaching the results.
The first line is of invalidating entire lru and the second is dropping 
selected bh.

File & VM system latencies in microseconds - smaller is better
---
Host OS   0K File  10K File MmapProt   Page   100fd
 Create Delete Create Delete Latency Fault  Fault  selct
- - -- -- -- -- --- - --- -
10.178.33 Linux 3.10.19   25.1   19.6   32.6   19.7  5098.0 0.666 3.45880 6.506
10.178.33 Linux 3.10.19   24.9   19.5   32.3   19.4  5059.0 0.563 3.46380 6.521


I tried several times but the result tells that they are the same under 1% gap
except Protection Fault.
But the latency of Protection Fault is very small and I think it has little 
effect.

Therefore we can choose anything but I choose invalidating entire lru.
The try_to_free_buffers() which is calling drop_buffers() is called by many 
filesystem code.
So I think inserting codes in drop_buffers() can affect the system.
And also we cannot distinguish migration type in drop_buffers().

In alloc_contig_range() we can distinguish migration type and invalidate lru if 
it needs.
I think alloc_contig_range() is proper to deal with bh like following patch.

Laura, can I have you name on Acked-by line?
Please let me represent my thanks.

Thanks for any feedback.

--- 8< --

>From 33c894b1bab9bc26486716f0c62c452d3a04d35d Mon Sep 17 00:00:00 2001
From: Gioh Kim 
Date: Fri, 18 Jul 2014 13:40:01 +0900
Subject: [PATCH] CMA/HOTPLUG: clear buffer-head lru before page migration

The bh must be free to migrate a page at which bh is mapped.
The reference count of bh is increased when it is installed
into lru so that the bh of lru must be freed before migrating the page.

This frees every bh of lru. We could free only bh of migrating page.
But searching lru costs more than invalidating entire lru.

Signed-off-by: Gioh Kim 
Acked-by: Laura Abbott 
---
  mm/page_alloc.c |3 +++
  1 file changed, 3 insertions(+)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index b99643d4..3b474e0 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6369,6 +6369,9 @@ int alloc_contig_range(unsigned long start, unsigned long 
end,
 if (ret)
 return ret;

+   if (migratetype == MIGRATE_CMA || migratetype == MIGRATE_MOVABLE)


I'm not sure if it really makes sense to check the migratetype here. This check
doesn't add any new information to the code and make false impression that this
function can be called for other migratetypes than CMA or MOVABLE. Even if so,
then invalidating bh_lrus unconditionally will make more sense, IMHO.


I agree. I cannot understand why alloc_contig_range has an argument of 
migratetype.
Can the alloc_contig_range is called for other migrate type than CMA/MOVABLE?

What do you think about removing the argument of migratetype and
checking migratetype (if (migratetype == MIGRATE_CMA || migratetype == 
MIGRATE_MOVABLE))?





+   invalidate_bh_lrus();
+
 ret = __alloc_contig_migrate_range(&cc, start, end);
 if (ret)
 goto done;
--
1.7.9.5



Best regards

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

Re: [PATCH] kbuild: allow to override Python command name

[Michal Marek]

Dne 18.7.2014 06:40, Masahiro Yamada napsal(a):
> The specification of Python 3 is largely different from that of
> Python 2.
> 
> For example, arch/ia64/scripts/unwcheck.py seems to be written
> in Python 2, not compatible with Python 3.
> 
> It is not a good idea to invoke python scripts with the hard-coded
> command name 'python'. The command 'python' could possibly be
> Python 3 on some systems.
> For that case, it is reasonable to allow to override the command name
> by giving 'PYTHON=python2' from the command line.
> 
> The 'python' in arch/ia64/Makefile should be replaced with '$(PYTHON)'.
> 
> Signed-off-by: Masahiro Yamada 
> Cc: linux-i...@vger.kernel.org

Thanks, applied to kbuild.git#kbuild.

Michal

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

RE: [PATCH net-next v9 3/9] net: nl802154 - make add_iface take name assign type

[David Laight]

From: David Miller
> From: Tom Gundersen 
> Date: Thu, 17 Jul 2014 10:06:04 +0200
> 
> > @@ -192,8 +193,10 @@ int ieee802154_add_iface(struct sk_buff *skb, struct 
> > genl_info *info)
> > if (devname[nla_len(info->attrs[IEEE802154_ATTR_DEV_NAME]) - 1]
> > != '\0')
> > return -EINVAL; /* phy name should be null-terminated */
> > +   name_assign_type = NET_NAME_USER;
> > } else  {
> > devname = "wpan%d";
> > +   name_assign_type = NET_NAME_ENUM;
> > }
> >
> > if (strlen(devname) >= IFNAMSIZ)
> 
> Just wondering what should happen if "%d" appears in a user provided name.
> 
> That would seem to be both USER and ENUM.

Is a training %d detected by special code?
Or is the string used as a printf format?
If the latter is true what happens if the user provides foo%s

David



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

linux-next: Tree for Jul 18

[Stephen Rothwell]

Hi all,

Changes since 20140717:

The net-next tree gained a build failure so I used the version from
next-20140717.

The irqchip tree gained conflicts against the arm64 and trivial trees.

The akpm-current tree gained a conflict against the random tree.

Non-merge commits (relative to Linus' tree): 6591
 6212 files changed, 241098 insertions(+), 337599 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm
defconfig.

Below is a summary of the state of the merge.

I am currently merging 222 trees (counting Linus' and 30 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (59ca9ee42838 Merge tag 'stable/for-linus-3.16-rc5-tag' 
of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip)
Merging fixes/master (1795cd9b3a91 Linux 3.16-rc5)
Merging kbuild-current/rc-fixes (dd5a6752ae7d firmware: Create directories for 
external firmware)
Merging arc-current/for-curr (89ca3b881987 Linux 3.15-rc4)
Merging arm-current/fixes (6b076991dca9 ARM: DMA: ensure that old section 
mappings are flushed from the TLB)
Merging m68k-current/for-linus (5bc8c7cdeb6e m68k: Export 
mach_random_get_entropy to modules)
Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX)
Merging powerpc-merge/merge (f56029410a13 powerpc/perf: Never program book3s 
PMCs with values >= 0x8000)
Merging sparc/master (894e552cfaa3 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security)
Merging net/master (c2a6c7813f1f net: huawei_cdc_ncm: add "subclass 3" devices)
Merging ipsec/master (a0e5ef53aac8 xfrm: Fix installation of AH IPsec SAs)
Merging sound-current/for-linus (4da63c6fc426 ALSA: hda - Fix broken PM due to 
incomplete i915 initialization)
Merging pci-current/for-linus (8e809611be2e GenWQE: Use pci_enable_msi_range() 
so we can fall back to fewer MSIs)
Merging wireless/master (2c4db12ec469 rt2800usb: Don't perform DMA from stack)
Merging driver-core.current/driver-core-linus (aff008ad813c platform_get_irq: 
Revert to platform_get_resource if of_irq_get fails)
Merging tty.current/tty-linus (1795cd9b3a91 Linux 3.16-rc5)
Merging usb.current/usb-linus (bb86cf569bbd usb: Check if port status is equal 
to RxDetect)
Merging usb-gadget-fixes/fixes (a8a85b01d185 usb: musb/cppi41: call 
musb_ep_select() before accessing an endpoint's CSR)
Merging usb-serial-fixes/usb-linus (1795cd9b3a91 Linux 3.16-rc5)
Merging staging.current/staging-linus (9359003385a2 Merge tag 
'iio-fixes-for-3.16d' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus)
Merging char-misc.current/char-misc-linus (1795cd9b3a91 Linux 3.16-rc5)
Merging input-current/for-linus (31972f6e517d Input: ti_am335x_tsc - warn about 
incorrect spelling)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (e052dbf55461 hwrng: virtio - ensure reads happen 
after successful probe)
Merging ide/master (5b40dd30bbfa ide: Fix SC1200 dependencies)
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (356facff5275 of/platform: Fix 
of_platform_device_destroy iteration of devices)
Merging rr-fixes/fixes (79465d2fd48e module: remove warning about waiting 
module removal.)
Merging mfd-fixes/master (73beb63d290f mfd: rtsx_pcr: Disable interrupts before 
cancelling delayed works)
Merging vfio-fixes/for-linus (239a87020b26 Merge branch 
'for-joerg/arm-smmu/fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into for-linus)
Merging drm-intel-fixes/f

Re: [PATCH] ACPI/NVS: Not save NVS region for new machines to accelerate S3

[Chen, Gong]

On Fri, Jul 18, 2014 at 01:55:22PM +0800, Lan Tianyu wrote:
> Date: Fri, 18 Jul 2014 13:55:22 +0800
> From: Lan Tianyu 
> To: r...@rjwysocki.net, l...@kernel.org
> Cc: Lan Tianyu , linux-a...@vger.kernel.org,
>  linux-kernel@vger.kernel.org
> Subject: [PATCH] ACPI/NVS: Not save NVS region for new machines to
>  accelerate S3
> X-Mailer: git-send-email 1.7.9.5
> 
> NVS region is saved and restored unconditionally for machines without
> nvs_nosave quirk during S3. Tested some new machines and the operation
> is not necessary. Saving NVS region also affects S2RAM speed. The time of
> NVS saving and restoring depends on the size of NVS region and it consumes
> 7~10ms normally.
> 
> This patch is to make machines produced from 2012 to now not saving NVS region
> to accelerate S3.
> 
The year 2012 is a mandatory value in the spec?


signature.asc
Description: Digital signature

Re: [PATCH v2] sparc: Add support for seek and shorter read to /dev/mdesc

[Sam Ravnborg]

Hi Khalid.

Looks better now - thanks.

A few nits remaining.
Please fix and submit a v3 - then we will see if David approves.

Sam

> +/* mdesc_open() - Grab a reference to mdesc_handle when /dev/mdesc is
> + *   opened. Hold this reference until /dev/mdesc is closed to ensure
> + *   mdesc data structure is not released underneath us. Store the
> + *   pointer to mdesc structure in private_data for read and seek to use
Please use one space between "*" and "text" - not a tab.
This is how it is done in the rest of the sparc code.



> + */
> +static int mdesc_open(struct inode *inode, struct file *file)
>  {
>   struct mdesc_handle *hp = mdesc_grab();
> - int err;
>  
>   if (!hp)
>   return -ENODEV;
>  
> - err = hp->handle_size;
> - if (len < hp->handle_size)
> - err = -EMSGSIZE;
> - else if (copy_to_user(buf, &hp->mdesc, hp->handle_size))
> - err = -EFAULT;
> - mdesc_release(hp);
> + file->private_data = hp;
> + return 0;
> +}

Personally I would add an empty line before the return.
But this is not something mandatory.

> +static loff_t mdesc_llseek(struct file *file, loff_t offset, int whence)
> +{
> + struct mdesc_handle *hp;
> +
> + switch (whence) {
> + case SEEK_CUR:
> + offset += file->f_pos;
> + break;
> + case SEEK_SET:
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + hp = file->private_data;
> + if (offset > hp->handle_size)
> + return -EINVAL;
> + else
> + file->f_pos = offset;
> + return offset;
> +}
Likewise regarning empty line.

> +
> +/* mdesc_close() - /dev/mdesc is being closed, release the reference to
> + *   mdesc structure.
> + */
Tab => space


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

Re: [PATCH 4/5] tty: serial: 8250 core: add runtime pm

[Sebastian Andrzej Siewior]

On 07/17/2014 06:18 PM, Felipe Balbi wrote:

>> No, this is okay. If you look, it checks for "up->ier & 
>> UART_IER_THRI". On the second invocation it will see that this
>> bit is already set and therefore won't call get_sync() for the
>> second time. That bit is removed in the _stop_tx() path.
> 
> oh, right. But that's actually unnecessary. Calling
> pm_runtime_get() multiple times will just increment the usage
> counter multiple times, which means you can call __stop_tx()
> multiple times too and everything gets balanced, right ?

No. start_tx() will be called multiple times but only the first
invocation invoke pm_runtime_get(). Now I noticed that I forgot to
remove pm_runtime_put_autosuspend() at the bottom of it. But you get
the idea right?
pm_get() on the while the UART_IER_THRI is not yet set. pm_put() once
the fifo is completely empty.

>> Do you have other ideas? It doesn't look like this is exported at
>> all. If we call _stop_tx() right away, then we have 64 bytes in
>> the TX fifo in the worst case. They should be gone "soon" but the
>> HW-flow control may delay it (in theory for a long time)).
> 
> this can be problematic, specially for OMAP which can go into OFF
> while idle. Whatever is in the FIFO would get lost. It seems like
> omap-serial solved this within transmit_chars().

No, it didn't.

> See how transmit_chars() is called from within IRQ handler with
> clocks enabled then it conditionally calls serial_omap_stop_tx()
> which will pm_runtime_get_sync() -> do_the_harlem_shake() -> 
> pm_runtime_put_autosuspend(). That leaves one unbalanced 
> pm_runtime_get() which is balanced when we're exitting the IRQ
> handler.

omap-serial and the 8250 do the following on tx path:
- start_tx()
  -> sets UART_IER_THRI. This will generate an interrupt once the FIFO
 is empty.
- interrupt, notices the empty fifo, invokes serial8250_start_tx()/
  transmit_chars().
  Both have a while loop that fills the FIFO. This loop is left once
  the tty-buffer is empty (uart_circ_empty() is true) or the FIFO full.

Lets say you filled 64 bytes into the FIFO and then left because your
FIFO is full and tty-buffer is empty. That means you will invoke
serial_omap_stop_tx() and remove UART_IER_THRI bit.
This is okay because you are not interested in further FIFO empty
interrupts because you don't have any TX-bytes to be sent. However,
once you leave the transmit_chars() you leave serial_omap_irq() which
does the last pm_put(). That means you have data in the TX FIFO that is
about to be sent and the device is in auto-suspend.
This is "fine" as long as the timeout is greater then the time required
for the data be sent (plus assuming HW-float control does not stall it
for too long) so nobody notices a thing.

For that reason I added the hack / #if0 block in the 8250 driver. To
ensure we do not disable the TX-FIFO-empty interrupt even if there is
nothing to send. Instead we enter serial8250_tx_chars() once again with
empty FIFO and empty tty-buffer and will invoke _stop_tx() which also
finally does the pm_put().
That is the plan. The problem I have is how to figure out that the
device is using auto-suspend. If I don't then I would have to remove
the #if0 block and that would mean for everybody an extra interrupt
(which I wanted to avoid).

> This seems work fine and dandy without DMA, but for DMA work, I
> think we need to make sure this IP stays powered until we get DMA
> completion callback. But that's future, I guess.

Yes, probably. That means one get at dma start, one put at dma complete
callback. And I assume we get that callbacks once the DMA transfer is
complete, not when the FIFO is empty :) So lets leave it to the future
for now…

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

Re: [PATCH net-next v9 3/9] net: nl802154 - make add_iface take name assign type

[Tom Gundersen]

On Fri, Jul 18, 2014 at 1:19 AM, David Miller  wrote:
> From: Tom Gundersen 
> Date: Thu, 17 Jul 2014 10:06:04 +0200
>
>> @@ -192,8 +193,10 @@ int ieee802154_add_iface(struct sk_buff *skb, struct 
>> genl_info *info)
>>   if (devname[nla_len(info->attrs[IEEE802154_ATTR_DEV_NAME]) - 1]
>>   != '\0')
>>   return -EINVAL; /* phy name should be null-terminated 
>> */
>> + name_assign_type = NET_NAME_USER;
>>   } else  {
>>   devname = "wpan%d";
>> + name_assign_type = NET_NAME_ENUM;
>>   }
>>
>>   if (strlen(devname) >= IFNAMSIZ)
>
> Just wondering what should happen if "%d" appears in a user provided name.
>
> That would seem to be both USER and ENUM.

Yes, this is a bit of a grey area.

I discussed this a bit with David Herrmann, and we landed on that
these names should be USER. As the user has explicitly asked for the
enumerated name, nobody should rename them to anything else (so ENUM
would have the wrong effect as it indicates that userspace should
rename the device), moreover, we should assume that the user knows
what they are doing, and that the enumerated names are fine in this
context.

Cheers,

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

Re: [PATCH RFCv3 08/14] arm64: introduce aarch64_insn_gen_movewide()

[Will Deacon]

On Fri, Jul 18, 2014 at 06:47:22AM +0100, Z Lim wrote:
> (resending this email in case the first one got caught in your spam
> filter. sorry.)
> 
> On Thu, Jul 17, 2014 at 10:41:02AM +0100, Will Deacon wrote:
> > On Wed, Jul 16, 2014 at 11:04:22PM +0100, Zi Shen Lim wrote:
> > > On Wed, Jul 16, 2014 at 05:17:15PM +0100, Will Deacon wrote:
> > > > On Tue, Jul 15, 2014 at 07:25:06AM +0100, Zi Shen Lim wrote:
> > > > > Introduce function to generate move wide (immediate) instructions.
> [...]
> > > > > +   switch (variant) {
> > > > > +   case AARCH64_INSN_VARIANT_32BIT:
> > > > > +   BUG_ON(shift != 0 && shift != 16);
> > > > > +   break;
> > > > > +   case AARCH64_INSN_VARIANT_64BIT:
> > > > > +   insn |= BIT(31);
> > > > > +   BUG_ON(shift != 0 && shift != 16 && shift != 32 &&
> > > > > +  shift != 48);
> > > >
> > > > Would be neater as a nested switch, perhaps? If you reorder the
> > > > outer-switch, you could probably fall-through too and combine the shift
> > > > checks.
> > >
> > > Not sure I picture what you had in mind... I couldn't come up with a
> > > neater version with the properties you described.
> > >
> > > The alternative I had was using masks instead of integer values, but
> > > one could argue that while neater, it could also be harder to read:
> > >
> > > switch (variant) {
> > > case AARCH64_INSN_VARIANT_32BIT:
> > > BUG_ON(shift & ~BIT(4));
> > > break;
> > > case AARCH64_INSN_VARIANT_64BIT:
> > > insn |= BIT(31);
> > > BUG_ON(shift & ~GENMASK(5, 4));
> > > ...
> >
> > I was thinking of using nested switches, but that doesn't fall out like I
> > hoped. How about:
> >
> >   switch (variant) {
> >   case AARCH64_INSN_VARIANT_64BIT:
> >   BUG_ON(shift != 32 && shift != 48);
> 
> Sorry this won't work. For example, on the valid case of shift==0,
> we'll barf right here - no fallthrough.
> 
> Shall we just leave the code as is? :)

Yeah, I'm an idiot ;)

Cheers,

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

Re: [PATCH] misc/GenWQE: fix pci_enable_msi usage

[Sebastian Ott]

On Thu, 17 Jul 2014, Frank Haverkamp wrote:
> Hi Bjorn and Sebastian,
> 
> Am Mittwoch, den 16.07.2014, 15:10 -0600 schrieb Bjorn Helgaas:
> > [+cc linux-pci]
> > 
> > On Wed, Jul 09, 2014 at 12:46:39PM +0200, Sebastian Ott wrote:
> > > GenWQE used to call pci_enable_msi_block to allocate a desired number
> > > of MSI's. If that was not possible pci_enable_msi_block returned with a
> > > smaller number which might be possible to allocate. GenWQE then called
> > > pci_enable_msi_block with that number.
> > > 
> > > Since commit a30d0108b
> > > "GenWQE: Use pci_enable_msi_exact() instead of pci_enable_msi_block()"
> > > pci_enable_msi_exact is used which fails if the desired number of MSI's
> > > was not possible to allocate. Change GenWQE to use pci_enable_msi_range
> > > to restore the old behavior.
> > > 
> > > Signed-off-by: Sebastian Ott 
> > 
> > Since this fixes a30d0108b09a, which we merged via my tree in v3.16-rc1, I
> > applied this with Alexander and Frank's acks to for-linus for v3.16,
> > thanks!
> > 
> > > ---
> > >  drivers/misc/genwqe/card_ddcb.c  |  4 +---
> > >  drivers/misc/genwqe/card_utils.c | 10 ++
> > >  2 files changed, 7 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/misc/genwqe/card_ddcb.c 
> > > b/drivers/misc/genwqe/card_ddcb.c
> > > index c8046db..f66d43d 100644
> > > --- a/drivers/misc/genwqe/card_ddcb.c
> > > +++ b/drivers/misc/genwqe/card_ddcb.c
> > > @@ -1237,9 +1237,7 @@ int genwqe_setup_service_layer(struct genwqe_dev 
> > > *cd)
> > >   }
> > >  
> > >   rc = genwqe_set_interrupt_capability(cd, GENWQE_MSI_IRQS);
> > > - if (rc > 0)
> > > - rc = genwqe_set_interrupt_capability(cd, rc);
> > > - if (rc != 0) {
> > > + if (rc) {
> > >   rc = -ENODEV;
> > >   goto stop_kthread;
> > >   }
> > > diff --git a/drivers/misc/genwqe/card_utils.c 
> > > b/drivers/misc/genwqe/card_utils.c
> > > index 62cc6bb..6abc437 100644
> > > --- a/drivers/misc/genwqe/card_utils.c
> > > +++ b/drivers/misc/genwqe/card_utils.c
> > > @@ -718,10 +718,12 @@ int genwqe_set_interrupt_capability(struct 
> > > genwqe_dev *cd, int count)
> > >   int rc;
> > >   struct pci_dev *pci_dev = cd->pci_dev;
> > >  
> > > - rc = pci_enable_msi_exact(pci_dev, count);
> > > - if (rc == 0)
> > > - cd->flags |= GENWQE_FLAG_MSI_ENABLED;
> > > - return rc;
> > > + rc = pci_enable_msi_range(pci_dev, 1, count);
> > > + if (rc < 0)
> > > + return rc;
> > > +
> > > + cd->flags |= GENWQE_FLAG_MSI_ENABLED;
> > > + return 0;
> > >  }
> 
> The original code tried to register for 4 interrupts. On my system the
> following scenario was executed:
> 
> We tried to register for 4 MSI interrupts, which was the original plan
> of interrupts for the card. Linux returned that it could not do that and
> that just 1 would work. We tried to register for 1 MSI interrupt and it
> worked. GENWQE_MSI_IRQS is still 4. That is how my original version
> looked like:

I changed the code that way, because I was under the impression
GENWQE_MSI_IRQS was set to 4 for a reason (I have no knowledge of the
internal workings of this driver). A lot of archs don't support more than
one MSI anyway - but are you saying that the genwqe card/driver itself
doesn't support more than one MSI?

Regards,
Sebastian
> 
> rc = genwqe_set_interrupt_capability(cd, GENWQE_MSI_IRQS);
> if (rc > 0)
> rc = genwqe_set_interrupt_capability(cd, rc);
> if (rc != 0) {
> rc = -ENODEV;
> goto stop_kthread;
> }
> 
> So genwqe_set_interrupt_capability() was indeed called two times.
> Calling it with 4 returned with rc=1 and no interrupts enabled. So
> calling it a 2nd time with rc=1 was leading to the proper enablement.
> 
> I think the simplest way is to set GENWQE_MSI_IRQS to 1. The rest of the
> code at least assumes just one interrupt, because 4 never worked.
> 
> Regards
> 
> Frank
> 
> 

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

Re: [PATCH 1/4] printk: LOG_CONT and LOG_NEWLINE are separate

[Petr Mládek]

On Thu 2014-07-17 11:19:15, Alex Elder wrote:
> On 07/17/2014 09:46 AM, Petr Mládek wrote:
> > On Thu 2014-07-17 07:11:39, Alex Elder wrote:
> >> On 07/17/2014 03:39 AM, Petr Mládek wrote:
> >>> On Wed 2014-07-16 12:26:57, Alex Elder wrote:
>  Two log record flags--LOG_CONT and LOG_NEWLINE--are never both set
>  at the same time in a log record flags field.  What follows is a
>  great deal of explanation that aims to prove this assertion.
> >>
> >> Thank you so much for reviewing these patches.
> >>
> >> Your confirmation of the fact that LOG_CONT and LOG_NEWLINE
> >> should not go together is very valuable to me.  I have a set
> >> of follow-on patches that rely on this, and I didn't want to
> >> go ahead with proposing them until I knew this was right.
> > 
> > To be honest. My statement was based on a common sense. I simply
> > cannot imagine situatiuon when a text ends with "\n" and is continuous
> > at the same time. IMHO, it is against any logic.
> 
> Well, I thought so too, but it was hard to see that by
> just looking at the code.
> 
> > IMHO, it would make sense to have only one flag, either LOG_NEWLINE or
> > LOG_CONT. Well, I am not sure if we could remove it easily. AFAIK, the
> > ring buffer is read also by external tools, e.g. crash.
> 
> I took a very quick look at crash-7.0.7 and see dump_log_entry(),
> which seems to dump the contents of a log record but does not
> interpret any of the flags.

Good to know.

> This is a really important point, so if anybody knows of other
> utilities outside the kernel that interpret the log record flags
> I'd like to know about it.

AFAIK, also makedumpfile tool somehow access the private data.
See the comments for log_buf_kexec_setup()

[...]
 
> >> Thanks again for the review.  If you're willing after reading my
> >> explanations, please offer an ACK or Reviewed-by (or further
> >> questions and suggestions).  I'll have responses to your others
> >> shortly.
> > 
> > I would like to see the bigger picture before :-)
> 
> OK, the big picture for this is that I have a set of about
> 5 more patches, which have the end result of eliminating
> LOG_CONT and LOG_PREFIX.  The only thing that matters is
> LOG_NEWLINE, which indicates the log entry completes a
> sequence of one or more.  Most records will have that set;
> any that do not will be "continuation" records, which should
> be taken along with one or more successor records to make
> up a single logical log entry.  There is no need for
> LOG_PREFIX, because that is implied by the presence of
> LOG_NEWLINE in the previous log entry.  We're already tracking
> the previous record state where that's needed.

I wanted to think about this over night. And Kay actually confirmed my
doubts. There are various situations when the messages could get mixed
either when writing or when reading.

We do not care much about whole lines. Users are usually able to put
the right lines together by context.

Most of the hackery seems to be done for the continuous lines. The
following problematic situations come to my mind:


1. More tasks are printing at the same time. It is solved by flushing
   the cont buffer with newline when message from another task comes.

2. Someone prints continuous lines and forgets to put '\n' at the end.
   This is solved by flushing the cont buffer with newline when
   the same tasks prints new message with prefix.

3. Task is interrupted and the handler prints something. It is not
   currently detected. It is fine because it usually looks like
   the second scenario. The handler prints the first message with
   prefix...

4. There is a flood of messages. The readers, e.g. console, syslog,
   are not able to handle everything. They copy a continuous line and
   miss the rest. This is currently solved by resetting the flags
   for the previous message. I think that it is handled as if
   the previous line was newline.


The question is how many flags we need to handle the situations
reasonable way. We are discussing the three flags:

   LOG_CONT
   LOG_NEWLINE
   LOG_PREFIX

Let's start with CONT and NEWLINE. The only situation when they
have the same value is when readers miss a message and reset the flag
for the previous message. It has the meaning: "we do not know".

IMHO, we do not need both CONT and NEWLINE flags. If we do not know
what was the last message, we need to decide somehow. It seems that we
currently do nothing special and expect that the last message ended
with newline. It means that the we could omit LOG_CONT flag and
simplify the code.


What about LOG_PREFIX? IMHO, we need it because the following
situations:

a) printk() could not modify flags of the previous messages. They
might be already proceed by readers, .e.g console, syslog. We could
not add LOG_NEWLINE flag to the previous message if suddenly new
message with prefix comes and the previous was already flushed
without newline.

b) Readers might miss messages. We might want to print '\n'

Re: [PATCH v13 6/8] arm: add pmd_[dirty|mkclean] for THP

[Will Deacon]

On Fri, Jul 18, 2014 at 07:53:04AM +0100, Minchan Kim wrote:
> MADV_FREE needs pmd_dirty and pmd_mkclean for detecting recent
> overwrite of the contents since MADV_FREE syscall is called for
> THP page.
> 
> This patch adds pmd_dirty and pmd_mkclean for THP page MADV_FREE
> support.
> 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: Steve Capper 
> Cc: Russell King 
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Minchan Kim 
> ---
>  arch/arm/include/asm/pgtable-3level.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/include/asm/pgtable-3level.h 
> b/arch/arm/include/asm/pgtable-3level.h
> index 85c60adc8b60..830f84f2d277 100644
> --- a/arch/arm/include/asm/pgtable-3level.h
> +++ b/arch/arm/include/asm/pgtable-3level.h
> @@ -220,6 +220,8 @@ static inline pmd_t *pmd_offset(pud_t *pud, unsigned long 
> addr)
>  #define pmd_trans_splitting(pmd) (pmd_val(pmd) & PMD_SECT_SPLITTING)
>  #endif
>  
> +#define pmd_dirty(pmd)   (pmd_val(pmd) & PMD_SECT_DIRTY)
> +
>  #define PMD_BIT_FUNC(fn,op) \
>  static inline pmd_t pmd_##fn(pmd_t pmd) { pmd_val(pmd) op; return pmd; }
>  
> @@ -228,6 +230,7 @@ PMD_BIT_FUNC(mkold,   &= ~PMD_SECT_AF);
>  PMD_BIT_FUNC(mksplitting, |= PMD_SECT_SPLITTING);
>  PMD_BIT_FUNC(mkwrite,   &= ~PMD_SECT_RDONLY);
>  PMD_BIT_FUNC(mkdirty,   |= PMD_SECT_DIRTY);
> +PMD_BIT_FUNC(mkclean,   &= ~PMD_SECT_DIRTY);
>  PMD_BIT_FUNC(mkyoung,   |= PMD_SECT_AF);
>  
>  #define pmd_mkhuge(pmd)  (__pmd(pmd_val(pmd) & ~PMD_TABLE_BIT))

Looks fine to me, but again, it would be great if Steve can take a look too.

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

RE: [PATCH 3/3] ext4: Add support IOC_MOV_DATA ioctl

[Namjae Jeon]

> On Tue, 8 Jul 2014 16:02:28 +0200 (CEST), Lukáš Czerner  
> wrote:
> Non-text part: MULTIPART/MIXED
> > On Tue, 8 Jul 2014, Namjae Jeon wrote:
> >
> > > Date: Tue, 08 Jul 2014 21:00:02 +0900
> > > From: Namjae Jeon 
> > > To: Dave Chinner , Theodore Ts'o 
> > > Cc: linux-ext4 , 
> > > linux-fsde...@vger.kernel.org,
> > > linux-kernel@vger.kernel.org, Lukáš Czerner ,
> > > Brian Foster , Christoph Hellwig 
> > > ,
> > > Ashish Sangwan , x...@oss.sgi.com
> > > Subject: [PATCH 3/3] ext4: Add support IOC_MOV_DATA ioctl
> > >
> > > This patch implements fs ioctl's IOC_MOV_DATA for Ext4.
> >
> > Hmm isn't this basically what ext4_move_extents() does ? eg.
> > EXT4_IOC_MOVE_EXT ?
> >
> > I guess that the intention here is to do the move, without actually
> > moving the data right ? But nevertheless maybe some code can be
> > shared with ext4_move_extents() ?
> It definitely can be shared, because it has specific case for unwritten
> data see move_extent_per_page().
If I understand correctly, mov_extent_per_page calls mext_replace_branches to
_replace_ extents from 1 inode to other inode. Please correct me if I am wrong.
ioc_mov_data will not replace extents, but it will actually _move_ extents into
hole from donor to receiver, leaving a hole at the place from where extents are
moved.
Could you elaborate more how it can be shared for unwritten data case ?

> But I think we can observe another way to unify this two things.
> An idea inspired by the fact that ioc_move_data works only for
> regular inodes, where orig_offset == donor_offset. 
Could you elaborate this point? 

> This is showstopper
> for  my utility e4defrag2 ( new version of e4defrag which is able defragment
> pack small files as described here :
> http://lists.openwall.net/linux-ext4/2014/04/28/3)
> 
> Proposed API is very similar to ext4_ext_migrate:
> Args:
>   orig_file: inode which we want to defragment
>   donor_file: a file which will be used as a donor of blocks
> 1) fallocate big donor_file
> 2) a) Create tmp inode wich nlink = 0
>b) move extents required extents from  donor to tmp_donor_inode
>c) return file descriptor (tmp_fd) to that tmp_donor_inode
> 4) Mark orig_file's inode with EXT4_STATE_EXT_MIGRATE state
> 5) Copy data from orig_file to tmp_fd
> 6) IOC_SWAP_EX: atomically swap  orig_file->i_data and tmp_fd->i_data
>if EXT4_STATE_EXT_MIGRATE was not cleared.
> 
> This approach can works not only for regular file w/o journaling
> enabled, but also for journaled ones, and directories.
> 
> 
> 
> 
> >
> > -Lukas
> >

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

Re: Alpha Checkpatch Errors

[Borislav Petkov]

On Thu, Jul 17, 2014 at 11:24:45PM -0400, Nick Krause wrote:
> > Nick, are you human?
> >
> Yes I am human.

It doesn't look like it. *Every-f*ckin-body* is telling you to stop
doing this FIXME bullshit but you continue like a bot which cannot parse
answer mails.

Just answer me one thing: why are you even doing this? Are you doing this
because

* you want to help with kernel development

* see your name in git logs

* ...

or simply because you're doing some sick experiment to see how long you
can bother people on lkml with senseless crap and are secretly giggling
nasty at all the pissed answers you get?

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: perf: Add support for full Intel event lists v7

[Michael Ellerman]

On Fri, 2014-07-11 at 16:59 -0700, Andi Kleen wrote:
> All feedback addressed. Hopefully ready for merge now.
...

> The JSON format and perf parser has some minor Intelisms, but they
> are simple and small and optional. It's easy to extend, so it would be
> possible to use it for other CPUs too, add different pmu attributes, and
> add new download sites to the downloader tool.

Yeah I agree.

We'll do some follow-up patches to get it working for the IBM powerpc chips.

cheers


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

Re: [RFC PATCH 1/3] hw_random: allow RNG devices to give early randomness after a delay

[Amit Shah]

On (Mon) 14 Jul 2014 [18:12:46], Amit Shah wrote:
> On (Mon) 14 Jul 2014 [08:37:00], Jason Cooper wrote:
> > On Mon, Jul 14, 2014 at 10:05:19AM +0530, Amit Shah wrote:
> > > Some RNG devices may not be ready to give early randomness at probe()
> > > time, and hence lose out on the opportunity to contribute to system
> > > randomness at boot- or device hotplug- time.
> > > 
> > > This commit schedules a delayed work item for such devices, and fetches
> > > early randomness after a delay.  Currently the delay is 500ms, which is
> > > enough for the lone device that needs such treatment: virtio-rng.
> > > 
> > > CC: Kees Cook 
> > > CC: Jason Cooper 
> > > CC: Herbert Xu 
> > > Signed-off-by: Amit Shah 
> > > ---
> > >  drivers/char/hw_random/core.c | 20 +++-
> > >  include/linux/hw_random.h |  8 
> > >  2 files changed, 27 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
> > > index c4419ea..2a765fd 100644
> > > --- a/drivers/char/hw_random/core.c
> > > +++ b/drivers/char/hw_random/core.c
> > > @@ -63,7 +63,7 @@ static size_t rng_buffer_size(void)
> > >   return SMP_CACHE_BYTES < 32 ? 32 : SMP_CACHE_BYTES;
> > >  }
> > >  
> > > -static void add_early_randomness(struct hwrng *rng)
> > > +static void get_early_randomness(struct hwrng *rng)
> > >  {
> > >   unsigned char bytes[16];
> > >   int bytes_read;
> > > @@ -79,6 +79,21 @@ static void add_early_randomness(struct hwrng *rng)
> > >   add_device_randomness(bytes, bytes_read);
> > >  }
> > >  
> > > +static void sched_init_random(struct work_struct *work)
> > > +{
> > > + struct hwrng *rng = container_of(work, struct hwrng, dwork.work);
> > > +
> > > + get_early_randomness(rng);
> > > +}
> > > +
> > > +static void add_early_randomness(struct hwrng *rng)
> > 
> > The add/get naming seems awkward in the above hunks.
> 
> Yea; I felt that too.  I thought of a do_add_early_randomness()
> instead, but that seemed awkward too.  I forgot to mention I was
> planning on revisiting this naming for v1.
> 
> > > +{
> > > + if (!(rng->flags & HWRNG_DELAY_READ_AT_INIT))
> > > + return get_early_randomness(rng);
> > > +
> > > + schedule_delayed_work(&rng->dwork, msecs_to_jiffies(500));
> > > +}
> > > +
> > 
> > Perhaps instead of rng->flags and a hardcoded delay, we could have
> > rng->seed_delay = msecs_to_jiffies(500) in virtio-rng?  Then you can
> > just call unconditionally:
> > 
> > schedule_delayed_work(&rng->dwork, rng->seed_delay);

BTW I didn't want to make this call unconditional -- i.e. the existing
behaviour of in-line fetching of randomness for all devices but one
should not be affected.

If indeed people are OK with this being done by a delayed work item
for all the drivers, the code can get a bit simpler here.

> > I think that would be a more extensible solution should other drivers
> > show up with the same issue.
> 
> Sounds like a good idea to me.  Though, changes in core.c that
> increase the time in hwrng_register() or hwrng_init() may not get
> noticed by rng drivers and they may suddenly start failing for no
> apparent reason.  Seems like a far stretch, though.  Does anyone else
> have an opinion on this?

Herbert, do you have any preference?

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

Re: [PATCH net-next v9 4/9] net: set name_assign_type when setting names via ioctls

[Tom Gundersen]

On Fri, Jul 18, 2014 at 1:20 AM, David Miller  wrote:
> From: Tom Gundersen 
> Date: Thu, 17 Jul 2014 10:06:05 +0200
>
>> @@ -2787,10 +2788,13 @@ static int gsm_create_network(struct gsm_dlci *dlci, 
>> struct gsm_netconfig *nc)
>>   pr_debug("create network interface");
>>
>>   netname = "gsm%d";
>> - if (nc->if_name[0] != '\0')
>> + if (nc->if_name[0] != '\0') {
>>   netname = nc->if_name;
>> - net = alloc_netdev(sizeof(struct gsm_mux_net), netname,
>> -NET_NAME_UNKNOWN, gsm_mux_net_init);
>> + name_assign_type = NET_NAME_USER;
>> + }
>> + net = alloc_netdev(sizeof(struct gsm_mux_net),
>> + netname, name_assign_type,
>> + gsm_mux_net_init);
>
> The indentation is now not correct.  For a function call, all arguments on the
> second and subsequent line, must start exactly at the first column after the
> openning parenthesis of the function call.

Indeed. Thanks, I'll fix this up.

Cheers,

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

Re: [PATCH 0/4 V3] irqchip: gic: Introduce ARM GICv2m MSI(-X) support

[Mark Rutland]

On Thu, Jul 17, 2014 at 03:12:35PM +0100, Jason Cooper wrote:
> On Thu, Jul 17, 2014 at 02:55:34PM +0100, Mark Rutland wrote:
> > Hi Jason,
> > 
> > On Thu, Jul 17, 2014 at 02:18:54PM +0100, Jason Cooper wrote:
> > > On Wed, Jul 09, 2014 at 06:05:00PM -0500, suravee.suthikulpa...@amd.com 
> > > wrote:
> > > > From: Suravee Suthikulpanit 
> > > > 
> > > > This patch set introduces support for MSI(-X) in GICv2m specification,
> > > > which is implemented in some variation of GIC400.
> > > > 
> > > > This depends on and has been tested with the V7 of"Add support for PCI 
> > > > in AArch64"
> > > > (https://lkml.org/lkml/2014/3/14/320).
> > > > 
> > > > Changes in V3:
> > > > * Rebase to git://git.infradead.org/users/jcooper/linux.git 
> > > > irqchip/gic
> > > >   (per Jason Cooper request)
> > > > * Misc fix/clean up per Mark Rutland comments
> > > > * Minor Clean up in the driver/irqchip/irq-gic-v2m.c: 
> > > > alloc_msi_irqs()
> > > > * Patch 4 is new to the series:
> > > > * Add ARM64-specific version arch_setup_msi_irqs() to allow 
> > > > support
> > > >   for Multiple MSI.
> > > > * Add support for Multiple MSI for GICv2m.
> > > > 
> > > > Suravee Suthikulpanit (4):
> > > >   irqchip: gic: Add binding probe for ARM GIC400
> > > >   irqchip: gic: Restructuring ARM GIC code
> > > >   irqchip: gic: Add supports for ARM GICv2m MSI(-X)
> > > >   irqchip: gicv2m: Add support for multiple MSI for ARM64 GICv2m
> > > 
> > > Ok, patch #1 applied to irqchip/urgent.  Patches 2 and 3 applied to
> > > irqchip/gic with irqchip/urgent merged in.  To facilitate
> > > testing/merging, I've prepared an unsigned tag for you on the
> > > irqchip/gic branch:
> > 
> > I'm a little concerned that this is all going through for v3.17 without
> > a {Reviewed,Acked}-by from Marc or anyone working with GIC{,v2m}.
> 
> Well, that's why it's not in irqchip/core yet. ;-)  It can be undone if
> needed.

Ah, perhaps I was a litte premature. :)
 
> > While his comments on v1 have been addressed, he has not had a chance to
> > acknowledge the solutions. I appreciate Marc's holiday is unfortunately
> > timed.
> > 
> > I also have an open concern with the binding with regard to the
> > orthogonality of GICV GICH and the MSI registers.
> > 
> > Suravee, do you need this urgently for v3.17? I was under the impression
> > that we wouldn't have full PCIe support by then.
> 
> If Suravee is ok with it, I can drop them for now and he can resend for
> v3.18.  Since we've worked out a way to merge it all in one window, I
> don't think it would hurt anything to wait.

Ok.

> I'll leave these in irqchip/for-next until I hear from Suravee, then
> I'll drop the lot till we hear from Marc and look at the timing.

Keeping it in for-next for testing sounds like a good idea, but until we
hear from Marc I wouldn't want to see this queued for mainline. So the
above sounds fine to me.

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

Re: [PATCH 2/5] printk: update previous message for LOG_PREFIX

[Petr Mládek]

On Thu 2014-07-17 12:59:10, Alex Elder wrote:
> If log_store() gets flags containing LOG_PREFIX, it indicates the
> record getting stored should implicitly complete the previous log
> record and start a new one.
> 
> We can also ensure the previous record is completed by keeping
> track of the previously-logged record, and adding the LOG_NEWLINE
> flag to it when log_store() sees a LOG_PREFIX flag.
> 
> Signed-off-by: Alex Elder 
> ---
>  kernel/printk/printk.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index e35d91a..6b72a77 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -242,6 +242,9 @@ static size_t syslog_partial;
>  static u64 log_first_seq;
>  static u32 log_first_idx;
>  
> +/* Pointer to the last record written into the log */
> +static struct printk_log *log_last_msg;
> +
>  /* index and sequence number of the next record to store in the buffer */
>  static u64 log_next_seq;
>  static u32 log_next_idx;
> @@ -425,7 +428,13 @@ static int log_store(int facility, int level,
>   log_next_idx = 0;
>   }
>  
> - /* fill message */
> + /*
> +  * If we're forcing a new log record, update the flags for
> +  * the previous one to mark it complete.
> +  */
> + if (flags & LOG_PREFIX && log_last_msg)
> + log_last_msg->flags |= LOG_NEWLINE;

You are not allowed to do this. The previous message might already be
proceed by readers (console, syslog, kmsg).

IMHO, you will not be able to make this safe without adding extra
complexity into the readers. So, I am afraid that there is no win
in vanishing the LOG_PREFIX flag.

Best Regards,
Petr

>   msg = (struct printk_log *)(log_buf + log_next_idx);
>   memcpy(log_text(msg), text, text_len);
>   msg->text_len = text_len;
> @@ -449,6 +458,9 @@ static int log_store(int facility, int level,
>   log_next_idx += msg->len;
>   log_next_seq++;
>  
> + /* Save our previous record address for next time. */
> + log_last_msg = msg;
> +
>   return msg->text_len;
>  }
>  
> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 5/5] kvm, mem-hotplug: Do not pin apic access page in memory.

[Tang Chen]

Hi Gleb,

On 07/17/2014 09:57 PM, Gleb Natapov wrote:

On Thu, Jul 17, 2014 at 09:34:20PM +0800, Tang Chen wrote:

Hi Gleb,

On 07/15/2014 08:40 PM, Gleb Natapov wrote:
..


And yes, we have the problem you said here. We can migrate the page while L2
vm is running.
So I think we should enforce L2 vm to exit to L1. Right ?


We can request APIC_ACCESS_ADDR reload during L2->L1 vmexit emulation, so
if APIC_ACCESS_ADDR changes while L2 is running it will be reloaded for L1 too.



Sorry, I think I don't quite understand the procedure you are talking about
here.

Referring to the code, I think we have three machines: L0(host), L1 and L2.
And we have two types of vmexit: L2->L1 and L2->L0.  Right ?

We are now talking about this case: L2 and L1 shares the apic page.

Using patch 5/5, when apic page is migrated on L0, mmu_notifier will notify
L1,
and update L1's VMCS. At this time, we are in L0, not L2. Why cannot we

Using patch 5/5, when apic page is migrated on L0, mmu_notifier will notify
L1 or L2 VMCS depending on which one happens to be running right now.
If it is L1 then L2's VMCS will be updated during vmentry emulation,


OK, this is easy to understand.


if it is
L2 we need to request reload during vmexit emulation to make sure L1's VMCS is
updated.



I'm a little confused here. In patch 5/5, I called 
make_all_cpus_request() to
force all vcpus exit to host. If we are in L2, where will the vcpus exit 
to ?

L1 or L0 ?

Thanks.

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

Re: [PATCH 0/4 V3] irqchip: gic: Introduce ARM GICv2m MSI(-X) support

[Mark Rutland]

On Thu, Jul 17, 2014 at 03:48:29PM +0100, Suravee Suthikulanit wrote:
> On 7/17/2014 8:55 AM, Mark Rutland wrote:
> > Hi Jason,
> >
> > On Thu, Jul 17, 2014 at 02:18:54PM +0100, Jason Cooper wrote:
> >> On Wed, Jul 09, 2014 at 06:05:00PM -0500, suravee.suthikulpa...@amd.com 
> >> wrote:
> >>> From: Suravee Suthikulpanit 
> >>>
> >>> This patch set introduces support for MSI(-X) in GICv2m specification,
> >>> which is implemented in some variation of GIC400.
> >>>
> >>> This depends on and has been tested with the V7 of"Add support for PCI in 
> >>> AArch64"
> >>> (https://lkml.org/lkml/2014/3/14/320).
> >>>
> >>> Changes in V3:
> >>>  * Rebase to git://git.infradead.org/users/jcooper/linux.git 
> >>> irqchip/gic
> >>>(per Jason Cooper request)
> >>>  * Misc fix/clean up per Mark Rutland comments
> >>>  * Minor Clean up in the driver/irqchip/irq-gic-v2m.c: 
> >>> alloc_msi_irqs()
> >>>  * Patch 4 is new to the series:
> >>>  * Add ARM64-specific version arch_setup_msi_irqs() to allow 
> >>> support
> >>>for Multiple MSI.
> >>>  * Add support for Multiple MSI for GICv2m.
> >>>
> >>> Suravee Suthikulpanit (4):
> >>>irqchip: gic: Add binding probe for ARM GIC400
> >>>irqchip: gic: Restructuring ARM GIC code
> >>>irqchip: gic: Add supports for ARM GICv2m MSI(-X)
> >>>irqchip: gicv2m: Add support for multiple MSI for ARM64 GICv2m
> >>
> >> Ok, patch #1 applied to irqchip/urgent.  Patches 2 and 3 applied to
> >> irqchip/gic with irqchip/urgent merged in.  To facilitate
> >> testing/merging, I've prepared an unsigned tag for you on the
> >> irqchip/gic branch:
> >
> > I'm a little concerned that this is all going through for v3.17 without
> > a {Reviewed,Acked}-by from Marc or anyone working with GIC{,v2m}.
> 
> > While his comments on v1 have been addressed, he has not had a chance to
> > acknowledge the solutions. I appreciate Marc's holiday is unfortunately
> > timed.
> >
> > I also have an open concern with the binding with regard to the
> > orthogonality of GICV GICH and the MSI registers.
> 
> The MSI part is normally enabled from the optional "msi-controller" 
> keyword. It should not really matter which compatible ID it uses.

I meant the fact that the MSI registers being described in reg[4],
rather than how the driver determines MSI support.

> Ooops. I noticed that was accidentally dropped the check for 
> "msi-controller" in the gicv2m_of_init() function.  I'll send a follow 
> up patch to fix this.

Sure. Whatever happens we should have both the msi-controller property
and the registers for the MSI block before we enable MSI support.

> > Suravee, do you need this urgently for v3.17? I was under the impression
> > that we wouldn't have full PCIe support by then.
> >
> 
> PCI is the dependency for this patch to function.  So, it should be 
> aligned with upstreaming of PCI patches.

Ok, so it sounds like this can wait for the moment (but we should
definitely ensure this gets some testing before then).

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

[PATCH] add error checks to initramfs

[David Engraf]

On a system with low memory extracting the initramfs may fail. If this 
happens the user gets "Failed to execute /init" instead of an initramfs 
error.


Check return value of sys_write and call error() when the write was 
incomplete or failed.


Signed-off-by: David Engraf 

diff --git a/init/initramfs.c b/init/initramfs.c
index a8497fa..64013cc 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -346,7 +346,8 @@ static int __init do_name(void)
 static int __init do_copy(void)
 {
 	if (count >= body_len) {
-		sys_write(wfd, victim, body_len);
+		if (sys_write(wfd, victim, body_len) != body_len)
+			error("write error");
 		sys_close(wfd);
 		do_utime(vcollected, mtime);
 		kfree(vcollected);
@@ -354,7 +355,8 @@ static int __init do_copy(void)
 		state = SkipIt;
 		return 0;
 	} else {
-		sys_write(wfd, victim, count);
+		if (sys_write(wfd, victim, count) != count)
+			error("write error");
 		body_len -= count;
 		eat(count);
 		return 1;

Re: [PATCH v2 21/29] nios2: Futex operations

[Arnd Bergmann]

On Friday 18 July 2014 14:07:42 Ley Foon Tan wrote:
> On Thu, Jul 17, 2014 at 7:07 PM, Arnd Bergmann  wrote:
> > The get_user/put_user functions really need to be annotated might_fault(),
> > because that's what they do.
> >
> > The whole point of get_user() is to access an unchecked user space
> > pointer, which  can do a number of things based on what the pointer
> > points to:
> >
> > - access a user space variable that resides in memory
> > - access a kernel pointer and fail because of the access_ok()
> >   check
> > - access a user space pointer that is not mapped and return
> >   through the __ex_table fixup.
> > - access a user space pointer that has a valid VMA but not PTE,
> >   causing a page fault to be resolved.
> >
> > It's the last case that breaks here.
> So, do you mean that we can't use get_user/put_user in futex support?
> BTW, some architectures like sh,parisc, m68k use get_user in futex
> function as well.
> Any recommendation way to support futex if we can't use get_user.
> Note, nios2 doesn't have atomic instruction.
> Thanks.

I looked at it again now and I'm no longer sure about my initial
interpretation. The way it seems to work is that pagefault_disable()
turns the case I mentioned into a simple error through the fixup,
so we return -EFAULT from get_user, and retry the futex from
futex_wake_op().

This would however also mean that there is no need for a spinlock
at all, atomicity is already implied by pagefault_disable() here
because you are running on a UP kernel and pagefault_disable() also
means there is no preemption.

If this understanding is right, we can probably just merge the
m68k implementation into the asm-generic version, as that does
exactly that, and just isn't SMP safe. I'm still unsure whether
I'm missing something here though, as everything else seems to
do this in assembly, even for non-SMP machines that could use
the trivial method that m68k has.

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

Re: testing result of loop-aio patchset on ext3

[Lukáš Czerner]

On Wed, 16 Jul 2014, Rui Xiang wrote:

> Date: Wed, 16 Jul 2014 17:28:10 +0800
> From: Rui Xiang 
> To: Lukáš Czerner 
> Cc: Dave Kleikamp , linux-e...@vger.kernel.org,
> linux-fsde...@vger.kernel.org, linux-kernel@vger.kernel.org,
> Li Zefan 
> Subject: Re: testing result of loop-aio patchset on ext3
> 
> On 2014/7/16 15:58, Lukáš Czerner wrote:
> > On Wed, 16 Jul 2014, Rui Xiang wrote:
> > 
> >> Date: Wed, 16 Jul 2014 11:54:24 +0800
> >> From: Rui Xiang 
> >> To: Lukáš Czerner 
> >> Cc: Dave Kleikamp , linux-e...@vger.kernel.org,
> >> linux-fsde...@vger.kernel.org, linux-kernel@vger.kernel.org,
> >> Li Zefan 
> >> Subject: Re: testing result of loop-aio patchset on ext3
> >>
> >> On 2014/7/14 17:51, Lukáš Czerner wrote:
> >>> On Mon, 14 Jul 2014, Rui Xiang wrote:
> >>>
>  Date: Mon, 14 Jul 2014 17:34:38 +0800
>  From: Rui Xiang 
>  To: Dave Kleikamp , linux-e...@vger.kernel.org
>  Cc: linux-fsde...@vger.kernel.org, linux-kernel@vger.kernel.org,
>  Li Zefan 
>  Subject: testing result of loop-aio patchset on ext3
> 
>  Hi Dave,
> 
>  We export a container image file as a block device via loop device, but 
>  we
>  found it's very easy that the container rootfs gets corrupted due to 
>  power
>  loss.
> 
>  Your early version of loop-aio patchset said the patchset can make loop
>  mounted filesystems recoverable(lkml.org/lkml/2012/3/30/317), but we 
>  found
>  it doesn't help.
> 
>  Both the guest fs and host fs are ext3.
> 
>  The loop-aio patchset is from:
>  git://github.com/kleikamp/linux-shaggy.git aio_loop
> 
>  Steps:
>  1. dd a 10G image, mkfs.ext3,
>    # dd if=/dev/zero of=./raw_image bs=1M count=1
>    # echo y | mkfs.ext3 raw_image
> 
>  2. losetup a loop device, mount at ./test_dir
>    # losetup /dev/loop1 raw_image
>    # mount /dev/loop1 ./test_dir
> 
>  3. copy fs_mark into test_dir and run
>    # ./fs_mark -d ./tmp/ -s 10240 -n 80
> 
>  4. during runing fs_mark, make systerm reboot indirectly.
>    # echo b > /proc/sysrq-trigger
> 
>  After systerm booted up, sometimes fsck reported raw_image fs has been 
>  damaged.
> 
>  # fsck.ext3 -n raw_image
>  e2fsck 1.41.9 (22-Aug-2009)
>  Warning: skipping journal recovery because doing a read-only filesystem 
>  check.
>  raw_image contains a file system with errors, check forced.
>  Pass 1: Checking inodes, blocks, and sizes
>  Pass 2: Checking directory structure
>  Pass 3: Checking directory connectivity
>  Pass 4: Checking reference counts
>  Pass 5: Checking group summary information
>  Free blocks count wrong (2481348, counted=2480577).
>  Fix? no
>  Free inodes count wrong (640837, counted=640835).
>  Fix? no
>  raw_image: ** WARNING: Filesystem still has errors **
>  raw_image: 11/640848 files (0.0% non-contiguous), 78652/256 blocks
> >>>
> >>> It's not damaged, this is expected result if you're using old
> >>> e2fsprogs which still treats this as an error.
> >>>
> >>> It's not an error because we only update superblock summary at
> >>> unmount time so with unclean shutdown it's likely that it does not
> >>> match the reality, but e2fsck can and will easily fix that for you.
> >>>
> >>> Please try e2fsprogs v1.42.3 or newer.
> >>>
> >>
> >> Hi Lukas,
> >>
> >> I updated e2fsprogs to v1.42.3, and user the newer fsck.ext3 to check 
> >> raw_image.
> >> Exactly, the result seemed normal.
> > 
> > Now I can see that there are much more problems than before, that's
> > weird. Sorry for not making this clear, but for this kind of
> > reproducers please use the most recent e2fsprogs. Also , what is the
> > kernel version you're using in this test ?
> > 
> 
> I use the most recent e2fsprogs 1.42.11 to check, and the error info is same 
> as
> result fscked by v1.42.3. It seems that shouldn't be the reason.
> 
> Otherwise, the kernel version in this test is stable 3.4.

In that case, this is a problem somewhere else. I'll try to
reproduce and see what I can see.

I assume you're not able to reproduce this on a real device ?

Thanks!
-Lukas

> 
> 
> Thanks!
> 
> > Thanks!
> > -Lukas
> > 
> >>
> >> Then, I continue my previous test. And after testing 35 times, "fsck -n" 
> >> reported image fs
> >> had been damaged, too.
> >>
> >>  # fsck.ext3 -n image1
> >> e2fsck 1.42.3.wc1 (28-May-2012)
> >> Warning: skipping journal recovery because doing a read-only filesystem 
> >> check.
> >> image1 has been mounted 36 times without being checked, check forced.
> >> Pass 1: Checking inodes, blocks, and sizes
> >> Inode 16407, i_size is 597447, should be 602112.  Fix? no
> >> Inode 16407, i_blocks is 1176, should be 1184.  Fix? no
> >> Inode 409941, i_blocks is 200208, should be 112.  Fix? no
> >> Pass 2: Checking directory structure
> >> Pass 3: Checking directory connectivity
>

Re: [PATCH 05/13] thermal: rcar: Document SoC-specific bindings

[Kuninori Morimoto]

Hi Simon

> 1. That the (in this case thermal) IP on the SoC's listed is known
>to work with the driver using the generic (in this case
>renesas,rcar-thermal) compatibility string.
> 
> 2. That if some incompatibility is subsequently found such that the
>IP on SoC does function correctly using the generic compatibility
>string or some new feature is to be enabled which is not generic
>then it the driver should be updated with code that is triggered
>by the SoC-specific compat string.
> 3. That Soc dts(i) files should list the more specific SoC compat string
>followed bu the generic compat string. In this way so long as the
>driver only matches on the generic compat string it will be used. But
>if the driver is updated match on the SoC-specific compat string
>then it will be used instead. In this way dtbs should be forwards
>compatible with driver updates.
> 
>I believe that this series includes patches to update the relevant
>dtsi files accordingly.
> 
> In relation to verification, I believe all the SoCs listed in this patch
> are known to work with the generic compat string. And they should continue
> to work with this change because its only an documentation change. In the
> future, if a SoC specific compat string is added to the driver code then
> verification would need to occur.
> 
> From my point of view the documentation in rcar-thermal.txt is consistent
> with the documentation for other drivers that use this binding scheme
> (at least the ones that are documented :). I would not have any problems
> examples but I don't think its entirely necessary.

>From my point of view,
I have no object to adding SoC-specific compatible
string on dts(i) file.
It can be insurance for future (above 1, 2, 3).

My concern is to add "known working SoC" to documentation.
I have no objection if this listed "known working SoC" 
was matched to "SoC-specific" compatible name.
Because driver cares it specially.
And, this case, documentation should list it.

But this case, listed SoC are matched to "generic name".

> +- compatible : "renesas,thermal-", "renesas,rcar-thermal"
> +   as fallback.
> +   Examples with soctypes are:
> + - "renesas,thermal-r8a73a4" (R-Mobile AP6)
> + - "renesas,thermal-r8a7779" (R-Car H1)
> + - "renesas,thermal-r8a7790" (R-Car H2)
> + - "renesas,thermal-r8a7791" (R-Car M2)

>From my (general?) point of view,
it seems that these listed SoC doesn't match to "generic name".
I mean that driver will do something special for these SoC.
And, we will confuse if driver supports "SoC-specific" compatible name.
(which one is special ? which one is generic ?)

And, I don't want to keep updating
"generic name matched SoC" on document.

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

[PATCH] usb: gadget: serial: replace {V,}DBG macro with dev_{v,}dbg

[Richard Leitner]

Replace the VDBG and DBG macro with the kernels "proper" debug macros
(dev_vdbg and dev_dbg) in f_acm.c, f_obex.c & f_serial.c

Signed-off-by: Richard Leitner 
---
 drivers/usb/gadget/f_acm.c|   41 -
 drivers/usb/gadget/f_obex.c   |   22 ++
 drivers/usb/gadget/f_serial.c |   11 +++
 3 files changed, 45 insertions(+), 29 deletions(-)

diff --git a/drivers/usb/gadget/f_acm.c b/drivers/usb/gadget/f_acm.c
index ab1065a..beac376 100644
--- a/drivers/usb/gadget/f_acm.c
+++ b/drivers/usb/gadget/f_acm.c
@@ -313,14 +313,14 @@ static void acm_complete_set_line_coding(struct usb_ep 
*ep,
struct usb_composite_dev *cdev = acm->port.func.config->cdev;
 
if (req->status != 0) {
-   DBG(cdev, "acm ttyGS%d completion, err %d\n",
+   dev_dbg(&cdev->gadget->dev, "acm ttyGS%d completion, err %d\n",
acm->port_num, req->status);
return;
}
 
/* normal completion */
if (req->actual != sizeof(acm->port_line_coding)) {
-   DBG(cdev, "acm ttyGS%d short resp, len %d\n",
+   dev_dbg(&cdev->gadget->dev, "acm ttyGS%d short resp, len %d\n",
acm->port_num, req->actual);
usb_ep_set_halt(ep);
} else {
@@ -397,14 +397,16 @@ static int acm_setup(struct usb_function *f, const struct 
usb_ctrlrequest *ctrl)
 
default:
 invalid:
-   VDBG(cdev, "invalid control req%02x.%02x v%04x i%04x l%d\n",
+   dev_vdbg(&cdev->gadget->dev,
+   "invalid control req%02x.%02x v%04x i%04x l%d\n",
ctrl->bRequestType, ctrl->bRequest,
w_value, w_index, w_length);
}
 
/* respond with data transfer or status phase? */
if (value >= 0) {
-   DBG(cdev, "acm ttyGS%d req%02x.%02x v%04x i%04x l%d\n",
+   dev_dbg(&cdev->gadget->dev,
+   "acm ttyGS%d req%02x.%02x v%04x i%04x l%d\n",
acm->port_num, ctrl->bRequestType, ctrl->bRequest,
w_value, w_index, w_length);
req->zero = 0;
@@ -428,10 +430,12 @@ static int acm_set_alt(struct usb_function *f, unsigned 
intf, unsigned alt)
 
if (intf == acm->ctrl_id) {
if (acm->notify->driver_data) {
-   VDBG(cdev, "reset acm control interface %d\n", intf);
+   dev_vdbg(&cdev->gadget->dev,
+"reset acm control interface %d\n", intf);
usb_ep_disable(acm->notify);
} else {
-   VDBG(cdev, "init acm ctrl interface %d\n", intf);
+   dev_vdbg(&cdev->gadget->dev,
+"init acm ctrl interface %d\n", intf);
if (config_ep_by_speed(cdev->gadget, f, acm->notify))
return -EINVAL;
}
@@ -440,11 +444,13 @@ static int acm_set_alt(struct usb_function *f, unsigned 
intf, unsigned alt)
 
} else if (intf == acm->data_id) {
if (acm->port.in->driver_data) {
-   DBG(cdev, "reset acm ttyGS%d\n", acm->port_num);
+   dev_dbg(&cdev->gadget->dev,
+   "reset acm ttyGS%d\n", acm->port_num);
gserial_disconnect(&acm->port);
}
if (!acm->port.in->desc || !acm->port.out->desc) {
-   DBG(cdev, "activate acm ttyGS%d\n", acm->port_num);
+   dev_dbg(&cdev->gadget->dev,
+   "activate acm ttyGS%d\n", acm->port_num);
if (config_ep_by_speed(cdev->gadget, f,
   acm->port.in) ||
config_ep_by_speed(cdev->gadget, f,
@@ -467,7 +473,7 @@ static void acm_disable(struct usb_function *f)
struct f_acm*acm = func_to_acm(f);
struct usb_composite_dev *cdev = f->config->cdev;
 
-   DBG(cdev, "acm ttyGS%d deactivated\n", acm->port_num);
+   dev_dbg(&cdev->gadget->dev, "acm ttyGS%d deactivated\n", acm->port_num);
gserial_disconnect(&acm->port);
usb_ep_disable(acm->notify);
acm->notify->driver_data = NULL;
@@ -537,8 +543,8 @@ static int acm_notify_serial_state(struct f_acm *acm)
 
spin_lock(&acm->lock);
if (acm->notify_req) {
-   DBG(cdev, "acm ttyGS%d serial state %04x\n",
-   acm->port_num, acm->serial_state);
+   dev_dbg(&cdev->gadget->dev, "acm ttyGS%d serial state %04x\n",
+   acm->port_num, acm->serial_state);
status = acm_cdc_notify(acm, USB_CDC_NOTIFY_SERIAL_STATE,
0, &acm->serial_state, 
sizeof(acm->serial_state));
} else {
@@ -691,12 +697

Re: [RFC PATCH 1/3] hw_random: allow RNG devices to give early randomness after a delay

[Herbert Xu]

On Fri, Jul 18, 2014 at 02:26:26PM +0530, Amit Shah wrote:
>
> > Sounds like a good idea to me.  Though, changes in core.c that
> > increase the time in hwrng_register() or hwrng_init() may not get
> > noticed by rng drivers and they may suddenly start failing for no
> > apparent reason.  Seems like a far stretch, though.  Does anyone else
> > have an opinion on this?
> 
> Herbert, do you have any preference?

So it's only virtio-rng that's a problem, right? How about if we
abuse the scan hook in virtio and move the hwrng_register there?

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/5] memory-hotplug: suitable memory should go to ZONE_MOVABLE

[Zhang Yanfei]

Hello,

On 07/18/2014 03:55 PM, Wang Nan wrote:
> This series of patches fix a problem when adding memory in bad manner.
> For example: for a x86_64 machine booted with "mem=400M" and with 2GiB
> memory installed, following commands cause problem:
> 
>  # echo 0x4000 > /sys/devices/system/memory/probe
> [   28.613895] init_memory_mapping: [mem 0x4000-0x47ff]
>  # echo 0x4800 > /sys/devices/system/memory/probe
> [   28.693675] init_memory_mapping: [mem 0x4800-0x4fff]
>  # echo online_movable > /sys/devices/system/memory/memory9/state
>  # echo 0x5000 > /sys/devices/system/memory/probe 
> [   29.084090] init_memory_mapping: [mem 0x5000-0x57ff]
>  # echo 0x5800 > /sys/devices/system/memory/probe 
> [   29.151880] init_memory_mapping: [mem 0x5800-0x5fff]
>  # echo online_movable > /sys/devices/system/memory/memory11/state
>  # echo online> /sys/devices/system/memory/memory8/state
>  # echo online> /sys/devices/system/memory/memory10/state
>  # echo offline> /sys/devices/system/memory/memory9/state
> [   30.558819] Offlined Pages 32768
>  # free
>  total   used   free sharedbuffers cached
> Mem:780588 18014398509432020 830552  0  0  
> 51180
> -/+ buffers/cache: 18014398509380840 881732
> Swap:0  0  0
> 
> This is because the above commands probe higher memory after online a
> section with online_movable, which causes ZONE_HIGHMEM (or ZONE_NORMAL
> for systems without ZONE_HIGHMEM) overlaps ZONE_MOVABLE.

Yeah, this is rare in reality but can happen. Could you please also
include the free result and zoneinfo after applying your patch?

Thanks.

> 
> After the second online_movable, the problem can be observed from
> zoneinfo:
> 
>  # cat /proc/zoneinfo
> ...
> Node 0, zone  Movable
>   pages free 65491
> min  250
> low  312
> high 375
> scanned  0
> spanned  18446744073709518848
> present  65536
> managed  65536
> ...
> 
> This series of patches solve the problem by checking ZONE_MOVABLE when
> choosing zone for new memory. If new memory is inside or higher than
> ZONE_MOVABLE, makes it go there instead.
> 
> 
> Wang Nan (5):
>   memory-hotplug: x86_64: suitable memory should go to ZONE_MOVABLE
>   memory-hotplug: x86_32: suitable memory should go to ZONE_MOVABLE
>   memory-hotplug: ia64: suitable memory should go to ZONE_MOVABLE
>   memory-hotplug: sh: suitable memory should go to ZONE_MOVABLE
>   memory-hotplug: powerpc: suitable memory should go to ZONE_MOVABLE
> 
>  arch/ia64/mm/init.c   |  7 +++
>  arch/powerpc/mm/mem.c |  6 ++
>  arch/sh/mm/init.c | 13 -
>  arch/x86/mm/init_32.c |  6 ++
>  arch/x86/mm/init_64.c | 10 --
>  5 files changed, 35 insertions(+), 7 deletions(-)
> 


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

Re: [PATCH v2 22/29] nios2: Miscellaneous header files

[Arnd Bergmann]

On Friday 18 July 2014 14:15:07 Chung-Lin Tang wrote:
> Hi Arnd,
> Considering two other kernel interface issues that appeared earlier in
> the context of nios2 glibc/kernel upstreaming:
> 
> (1) The 64-bit time_t/timespec issue.
> (2) Dropping renameat by default in favor of renameat2
> 
> What's the decision for these? Are they delayed to the next release?

For renameat2, I believe we had patches to change the generic syscall
list. It would be nice if you could include those in your patch
series as a prerequisite and base your patches on top.

Regarding time_t, I've spent much more time looking into what we
need to do for the other 32-bit architectures now. My feeling now
is that we're better off not introducing another special case for
nios2 here, as that will have the effect of making it harder to
move everyone else over later. We already have to deal with:

- 32-bit architectures using 32-bit time_t
- 64-bit architectures using 64-bit time_t
- 64-bit architectures running 32-bit tasks with 32-bit time_t
- 64-bit x86-64 and soon arm64 running x32 user space with 64-bit time_t

and we will get in the future

- 32-bit architectures providing both 32-bit time_t and 64-bit time64_t
- 64-bit architectures with compat tasks running 64-bit time64_t

Adding a 32-bit architecture that has a native 64-bit time_t will
just add another special case that we will have to live with for
a long time and that can introduce bugs for the other cases if we
get it wrong. I vote for keeping 32-bit time_t on nios2 and fixing
it along with arm32 and x86-32 and the others.

Presumably this is not a huge problem for you as I expect it's
easier for you to do another ABI change in user space when we get
there: once we have support for 64-bit time64_t in the kernel, you
can change your toolchains to default to that in user space and
rebuild everything. This is not something we can easily do in x86.

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

Re: [PATCH 1/5] arm: dts: omap3-gta04: Add missing nodes to fully describe gta04 board

[Javier Martinez Canillas]

Hello Marek and Dr. H. Nikolaus,

On Fri, Jul 18, 2014 at 8:55 AM, Joachim Eastwood  wrote:
> On 16 July 2014 09:17, Dr. H. Nikolaus Schaller  wrote:
>> Am 15.07.2014 um 14:45 schrieb Joachim Eastwood:
>>
>>> Hi Marek,
>>>
>>> You seem to add some DT nodes for hw that doesn't have drivers in
>>> mainline. I think you should leave those out until the driver itself
>>> is upstream and the bindings for it is documented.
>> is there some policy for only having nodes for existing drivers in DT files?
>

I strongly agree with Joachim on this regard.

>> If I understand the device tree concept correctly, it should not describe 
>> drivers
>> (and hence nothing about the state of them being mainlined), but it should 
>> statically
>> describe the given hardware in a way that kernel and drivers can read it (or 
>> ignore).
>> And even other kernels can use it (because they run on the same hardware).
>>

Yes, it should describe hardware but that description should be
previously agreed and properly documented as was mentioned before.

>> So unless there is an important reason not to have "currently unused" nodes
>> in the DT source/binary (loading time is IMHO neglectable), I would ask that 
>> we
>> can keep with the complete DT instead of splitting it up artificially and 
>> getting back
>> to the same status (because the hardware does not change over time).
>

I understand your motivation since it will allow you to not have to
maintain a patch-set for your downstream DTS changes but I would like
to ask you the opposite question. What's the benefit for the kernel
community to keep in a mainline DTS a bunch of device nodes with DT
bindings that have not been neither discussed nor documented?

Developers doing a board bring-up usually use the DTS in mainline as a
reference for their boards and having non-documented/agreed DT binding
on the upstream DTS will only bring confusion and frustration to them
IMHO.

We already have some issues with Device Trees (bindings that broke
backward compatibility, drivers implementing custom DT binding instead
of using standard ones, bindings that don't really reflect the actual
H/W, etc), please don't make this even more complicated to developers.

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

Re: [PATCH 0/5] printk: more log flag simplification

[Petr Mládek]

On Thu 2014-07-17 20:54:35, Alex Elder wrote:
> On 07/17/2014 08:37 PM, Kay Sievers wrote:
> > On Thu, Jul 17, 2014 at 7:59 PM, Alex Elder  wrote:
> >> This series rearranges the log code in such a way that the LOG_CONT
> >> and LOG_PREFIX log record flags can be eliminated entirely.  The
> >> result should be considerably easier to understand than before.  It
> >> builds on another recently-posted series of patches:
> >> https://lkml.org/lkml/2014/7/17/363
> >>
> >> The first patch exploits the fact that LOG_CONT and LOG_NEWLINE
> >> are inverses, and uses LOG_NEWLINE (or its negation) anywhere
> >> LOG_CONT is used.  As a result, LOG_CONT is no longer needed, so
> >> it's eliminated.

I think that only this part is usable. It would make sense to move it
to the other patch set.

> >> The next three patches together eliminate LOG_PREFIX.  The effect
> >> of LOG_PREFIX is to complete the previous log entry before recording
> >> a new one.  Patch 2 arranges to do this directly, marking the previous
> >> log record with LOG_NEWLINE whenever a new record is presented with
> >> LOG_PREFIX set.  Patch 3 stops saving LOG_PREFIX in any log records,
> >> and patch 4 finally gets rid of LOG_PREFIX.
>>>
> >> The last patch is just some cleanup of the code now that it's gone
> >> through this transformation.

The other patches would break readers. You could not modify older
records because the might already have been proceed.

You would need to add another hacks to the readers. I think that using
LOG_PREFIX is more clear and less hacky.

> > Continuation lines are racy and unreliable by definition, they create
> > a problem that cannot be solved properly, so we need to try to make
> > the best out of it. The idea of the record buffer flags was to record
> > what actually happened when things race against each other. A line
> > without a newline is recorded as a line without a newline.
> 
> Understood.
> 
> > Your simplifying patches changes the code to store how things will
> > *look* like when exported, not what actually *happened*; like it
> > pretends the earlier line had a newline, while that might not have
> > been the case.
> 
> What do you mean by "exported?"  Does the result in syslog
> or /proc/kmsg (or the console for that matter) actually
> differ?  I'll have to look again, but I think they do not.

Yes, they are asynchronous. Each of them has its own speed and
behavior.

Console is like a dog. It tries to process all new messages until
the very last one.

Syslog and kmsg are interfaces that are used by userspace tools,
e.g. syslogd, dmesg. They are asked to read selected part of
the ring buffer, usually the last messages. They might be asked to
seek, read everything again, ...

Syslog and kmsg have to release the logbuf_lock every time they copy
some line to the userspace. This is the time when the ring buffer
might get rotated and they might miss the end of continuous line.


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

Re: [PATCH v2 1/3] ACPI: ARM64 does not have a BIOS add config for BIOS table scan.

[Hanjun Guo]

On 2014-7-18 0:58, Luck, Tony wrote:
>> Tony, if it is ok with you, I will modify the patch and will not select
>> ACPI_LEGACY_TABLES_LOOKUP on IA64, I'm waiting for your final confirmation.
> 
> Confirmed.  Thanks Peter for catching this.

Great, I will update the patch and send out soon.

Thanks
Hanjun

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

Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

[Dietmar Eggemann]

On 18/07/14 07:34, Bruno Wolff III wrote:

On Thu, Jul 17, 2014 at 14:35:02 +0200,
   Peter Zijlstra  wrote:


In any case, can someone who can trigger this run with the below; its
'clean' for me, but supposedly you'll trigger a FAIL somewhere.


I got a couple of fail messages.

dmesg output is available in the bug as the following attachment:
https://bugzilla.kernel.org/attachment.cgi?id=143361

The part of interest is probably:

[0.253354] build_sched_groups: got group f255b020 with cpus:
[0.253436] build_sched_groups: got group f255b120 with cpus:
[0.253519] build_sched_groups: got group f255b1a0 with cpus:
[0.253600] build_sched_groups: got group f255b2a0 with cpus:
[0.253681] build_sched_groups: got group f255b2e0 with cpus:
[0.253762] build_sched_groups: got group f255b320 with cpus:
[0.253843] build_sched_groups: got group f255b360 with cpus:
[0.254004] build_sched_groups: got group f255b0e0 with cpus:
[0.254087] build_sched_groups: got group f255b160 with cpus:
[0.254170] build_sched_groups: got group f255b1e0 with cpus:
[0.254252] build_sched_groups: FAIL
[0.254331] build_sched_groups: got group f255b1a0 with cpus: 0
[0.255004] build_sched_groups: FAIL
[0.255084] build_sched_groups: got group f255b1e0 with cpus: 1


That (partly) explains it. f255b1a0 (5) and f255b1e0 (6) are reused 
here! This reuse doesn't happen on my machines.


But if they are used for a different cpu mask (not including cpu0 resp. 
cpu1 this would mess up their first usage?


I guess that the second time, cpu3 will be added to the cpumask of 
f255b1a0 and cpu4 to f255b1e0?


Maybe we can extend PeterZ patch to print out cpu and span as well us 
this printk also in free_sched_domain() to debug further if this is not 
enough evidence?


[0.252059] __sdt_alloc: allocated f255b020 with cpus: (1)
[0.252147] __sdt_alloc: allocated f255b0e0 with cpus: (2)
[0.252229] __sdt_alloc: allocated f255b120 with cpus: (3)
[0.252311] __sdt_alloc: allocated f255b160 with cpus: (4)
[0.252395] __sdt_alloc: allocated f255b1a0 with cpus: (5)
[0.252477] __sdt_alloc: allocated f255b1e0 with cpus: (6)
[0.252559] __sdt_alloc: allocated f255b220 with cpus: (7) (not used)
[0.252641] __sdt_alloc: allocated f255b260 with cpus: (8) (not used)
[0.253013] __sdt_alloc: allocated f255b2a0 with cpus: (9)
[0.253097] __sdt_alloc: allocated f255b2e0 with cpus: (10)
[0.253184] __sdt_alloc: allocated f255b320 with cpus: (11)
[0.253265] __sdt_alloc: allocated f255b360 with cpus: (12)

[0.253354] build_sched_groups: got group f255b020 with cpus: (1)
[0.253436] build_sched_groups: got group f255b120 with cpus: (3)
[0.253519] build_sched_groups: got group f255b1a0 with cpus: (5)
[0.253600] build_sched_groups: got group f255b2a0 with cpus: (9)
[0.253681] build_sched_groups: got group f255b2e0 with cpus: (10)
[0.253762] build_sched_groups: got group f255b320 with cpus: (11)
[0.253843] build_sched_groups: got group f255b360 with cpus: (12)
[0.254004] build_sched_groups: got group f255b0e0 with cpus: (2)
[0.254087] build_sched_groups: got group f255b160 with cpus: (4)
[0.254170] build_sched_groups: got group f255b1e0 with cpus: (6)
[0.254252] build_sched_groups: FAIL
[0.254331] build_sched_groups: got group f255b1a0 with cpus: 0 (5)
[0.255004] build_sched_groups: FAIL
[0.255084] build_sched_groups: got group f255b1e0 with cpus: 1 (6)
[0.255365] devtmpfs: initialized



I also booted with early printk=keepsched_debug as requested by
Dietmar.



Didn't see what I was looking for in your dmesg output. Did you use
'earlyprintk=keep sched_debug'







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

Re: [RFC PATCH 1/3] hw_random: allow RNG devices to give early randomness after a delay

[Amit Shah]

On (Fri) 18 Jul 2014 [17:14:08], Herbert Xu wrote:
> On Fri, Jul 18, 2014 at 02:26:26PM +0530, Amit Shah wrote:
> >
> > > Sounds like a good idea to me.  Though, changes in core.c that
> > > increase the time in hwrng_register() or hwrng_init() may not get
> > > noticed by rng drivers and they may suddenly start failing for no
> > > apparent reason.  Seems like a far stretch, though.  Does anyone else
> > > have an opinion on this?
> > 
> > Herbert, do you have any preference?
> 
> So it's only virtio-rng that's a problem, right? How about if we
> abuse the scan hook in virtio and move the hwrng_register there?

Oops, I had completely missed the scan hook, and looks like it was
added for exactly the purpose we want here (so we won't even be
abusing it!)

Thanks!

I'll post the patches when the one to revert gets an upstream commit
id.

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

Re: [PATCH v3 09/12] Revert "sched: Put rq's sched_avg under CONFIG_FAIR_GROUP_SCHED"

[Yuyang Du]

On Mon, Jul 14, 2014 at 06:54:11PM +0100, Dietmar Eggemann wrote:
> __update_entity_runnable_avg() has an additional parameter 'running' so
> that it can be called for
> 
> a) sched_entities in update_entity_load_avg():
> 
>   __update_entity_runnable_avg(..., se->on_rq, cfs_rq->curr == se))
> 
> 
> b) rq's in update_rq_runnable_avg():
> 
>   __update_entity_runnable_avg(..., runnable, runnable);
> 
> I can see how it gives us two different signals for a sched_entity but
> for a rq?
> 
For rq, 

__update_entity_runnable_avg(..., runnable, runnable > 0)

Then, first one would be effectively CPU ConCurrency (fair and !fair) and
second one would be CPU (has task) running (or about CPU utilization for
fair and !fair), :)

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

Re: Random panic in load_balance() with 3.16-rc

[Michel Dänzer]

On 17.07.2014 16:58, Peter Zijlstra wrote:
> On Thu, Jul 17, 2014 at 04:31:04PM +0900, Michel Dänzer wrote:
>>
>> I've been running into the panic captured in the attached picture (hope
>> it's legible) randomly while running 3.16-rc4 and -rc5. I haven't
>> noticed any pattern as to when it happens; at least once it happened
>> while the box was basically sitting idle.
>>
>> dmesg, .config and /proc/cpuinfo attached as well; let me know if you
>> need anything else.
> 
> Does lkml.kernel.org/r/20140716145546.ga6...@wolff.to cure things?

Yes, adding back

   cpumask_clear(sched_group_cpus(sg));

seems to do the trick, thanks.

There's a long weekend coming up for me, but after that I'll be happy to
test any better fix you guys come up with.


-- 
Earthling Michel Dänzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] CMA/HOTPLUG: clear buffer-head lru before page migration

[Zhang Yanfei]

Hello,

On 07/18/2014 04:23 PM, Gioh Kim wrote:
> 
> 
> 2014-07-18 오후 4:50, Marek Szyprowski 쓴 글:
>> Hello,
>>
>> On 2014-07-18 08:45, Gioh Kim wrote:
>>> For page migration of CMA, buffer-heads of lru should be dropped.
>>> Please refer to https://lkml.org/lkml/2014/7/4/101 for the history.
>>>
>>> I have two solution to drop bhs.
>>> One is invalidating entire lru.
>>> Another is searching the lru and dropping only one bh that Laura proposed
>>> at https://lkml.org/lkml/2012/8/31/313.
>>>
>>> I'm not sure which has better performance.
>>> So I did performance test on my cortex-a7 platform with Lmbench
>>> that has "File & VM system latencies" test.
>>> I am attaching the results.
>>> The first line is of invalidating entire lru and the second is dropping 
>>> selected bh.
>>>
>>> File & VM system latencies in microseconds - smaller is better
>>> ---
>>> Host OS   0K File  10K File MmapProt   Page   
>>> 100fd
>>>  Create Delete Create Delete Latency Fault  Fault  
>>> selct
>>> - - -- -- -- -- --- - --- 
>>> -
>>> 10.178.33 Linux 3.10.19   25.1   19.6   32.6   19.7  5098.0 0.666 3.45880 
>>> 6.506
>>> 10.178.33 Linux 3.10.19   24.9   19.5   32.3   19.4  5059.0 0.563 3.46380 
>>> 6.521
>>>
>>>
>>> I tried several times but the result tells that they are the same under 1% 
>>> gap
>>> except Protection Fault.
>>> But the latency of Protection Fault is very small and I think it has little 
>>> effect.
>>>
>>> Therefore we can choose anything but I choose invalidating entire lru.
>>> The try_to_free_buffers() which is calling drop_buffers() is called by many 
>>> filesystem code.
>>> So I think inserting codes in drop_buffers() can affect the system.
>>> And also we cannot distinguish migration type in drop_buffers().
>>>
>>> In alloc_contig_range() we can distinguish migration type and invalidate 
>>> lru if it needs.
>>> I think alloc_contig_range() is proper to deal with bh like following patch.
>>>
>>> Laura, can I have you name on Acked-by line?
>>> Please let me represent my thanks.
>>>
>>> Thanks for any feedback.
>>>
>>> --- 8< --
>>>
>>> >From 33c894b1bab9bc26486716f0c62c452d3a04d35d Mon Sep 17 00:00:00 2001
>>> From: Gioh Kim 
>>> Date: Fri, 18 Jul 2014 13:40:01 +0900
>>> Subject: [PATCH] CMA/HOTPLUG: clear buffer-head lru before page migration
>>>
>>> The bh must be free to migrate a page at which bh is mapped.
>>> The reference count of bh is increased when it is installed
>>> into lru so that the bh of lru must be freed before migrating the page.
>>>
>>> This frees every bh of lru. We could free only bh of migrating page.
>>> But searching lru costs more than invalidating entire lru.
>>>
>>> Signed-off-by: Gioh Kim 
>>> Acked-by: Laura Abbott 
>>> ---
>>>   mm/page_alloc.c |3 +++
>>>   1 file changed, 3 insertions(+)
>>>
>>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>>> index b99643d4..3b474e0 100644
>>> --- a/mm/page_alloc.c
>>> +++ b/mm/page_alloc.c
>>> @@ -6369,6 +6369,9 @@ int alloc_contig_range(unsigned long start, unsigned 
>>> long end,
>>>  if (ret)
>>>  return ret;
>>>
>>> +   if (migratetype == MIGRATE_CMA || migratetype == MIGRATE_MOVABLE)
>>
>> I'm not sure if it really makes sense to check the migratetype here. This 
>> check
>> doesn't add any new information to the code and make false impression that 
>> this
>> function can be called for other migratetypes than CMA or MOVABLE. Even if 
>> so,
>> then invalidating bh_lrus unconditionally will make more sense, IMHO.
> 
> I agree. I cannot understand why alloc_contig_range has an argument of 
> migratetype.
> Can the alloc_contig_range is called for other migrate type than CMA/MOVABLE?
> 
> What do you think about removing the argument of migratetype and
> checking migratetype (if (migratetype == MIGRATE_CMA || migratetype == 
> MIGRATE_MOVABLE))?
> 

Remove the checking only. Because gigantic page allocation used for hugetlb is
using alloc_contig_range(.. MIGRATE_MOVABLE).

Thanks.

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

[PATCH 3/9] usb: musb_am335x: source cleanup

[Lothar Waßmann]

- remove comma after end of list delimiter
  The empty entry must always be the last item in the list, thus there
  is no point in having a trailing comma to facilitate adding
  succeding entries.
  Remove the comma, so that inadvertedly adding an entry after the end
  of list sentinel will produce a compile time error rather than an
  unreachable entry in the list.
- consistently use tabs for indentation

Signed-off-by: Lothar Waßmann 
---
 drivers/usb/musb/musb_am335x.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/musb/musb_am335x.c b/drivers/usb/musb/musb_am335x.c
index 1e58ed2..164c868 100644
--- a/drivers/usb/musb/musb_am335x.c
+++ b/drivers/usb/musb/musb_am335x.c
@@ -21,14 +21,14 @@ err:
 
 static const struct of_device_id am335x_child_of_match[] = {
{ .compatible = "ti,am33xx-usb" },
-   {  },
+   {  }
 };
 MODULE_DEVICE_TABLE(of, am335x_child_of_match);
 
 static struct platform_driver am335x_child_driver = {
.probe  = am335x_child_probe,
-   .driver = {
-   .name   = "am335x-usb-childs",
+   .driver = {
+   .name   = "am335x-usb-childs",
.of_match_table = am335x_child_of_match,
},
 };
-- 
1.7.10.4

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