Re: [PATCH] ACPI / power: Drop automaitc resume of power resource dependent devices

[Aaron Lu]

On 10/16/2013 09:25 PM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> The mechanism causing devices depending on a given power resource
> (that is, devices that can be in D0 only if that power resource is
> on) to be resumed automatically when the power resource is turned
> on (and their "inferred" power state becomes D0 as a result) is
> inherently racy and in fact unnecessary.
> 
> It is racy, because if the power resources is turned on and then
> immediately off, the device resume triggered by the first transition
> to "on" may still happen, causing the power resource to be turned
> on again.  That again will trigger the "resume of dependent devices"
> mechanism, but if the devices in question are not in use, they will
> be suspended in the meantime causing the power resource to be turned
> off.  However, the "resume of dependent devices" will next resume
> them again and so on.  In some cases (USB port PM in particular) that
> leads to an endless busy loop of flipping the resource on and off
> continuously.
> 
> It is needless, because whoever turns a power resource on will most
> likely turn it off at some point and the devices that go into "D0"
> as a result of turning it on will then go back into D3cold.
> Moreover, turning all power resources a device needs to go into
> D0 is not sufficient for a full transition into D0 in general.
> Namely, _PS0 may need to be executed in addition to that in some
> cases.  This means that the whole rationale of the "resume of
> dependent devices" mechanism was incorrect to begin with and it's
> best to remove it entirely.

With this patch, your previous patch could also be applied now:
https://lkml.org/lkml/2013/6/14/173
[PATCH 4/4] ACPI / PM: Drop two functions that are not used any more

And the following ATA patch at the same time:

From: Aaron Lu 
Subject: [PATCH] ata: acpi: remove power dependent device handling

Previously, we want the SCSI device corrsponding to ATA device gets
runtime resumed when the power resource for that ATA device is turned
on by some other device, so we added the SCSI device to the dependent
device list of the ATA device's ACPI node. Since now we decided this
behavior is troublesome and hard to avoid race, this behavior has been
dropped. This patch cleans up the corresponding code in ATA ACPI layer.

Signed-off-by: Aaron Lu 
---
 drivers/ata/libata-acpi.c | 14 --
 drivers/ata/libata-scsi.c |  3 ---
 drivers/ata/libata.h  |  4 
 3 files changed, 21 deletions(-)

diff --git a/drivers/ata/libata-acpi.c b/drivers/ata/libata-acpi.c
index 4ba8b04..ab714d2 100644
--- a/drivers/ata/libata-acpi.c
+++ b/drivers/ata/libata-acpi.c
@@ -1035,17 +1035,3 @@ void ata_acpi_on_disable(struct ata_device *dev)
 {
ata_acpi_clear_gtf(dev);
 }
-
-void ata_scsi_acpi_bind(struct ata_device *dev)
-{
-   acpi_handle handle = ata_dev_acpi_handle(dev);
-   if (handle)
-   acpi_dev_pm_add_dependent(handle, &dev->sdev->sdev_gendev);
-}
-
-void ata_scsi_acpi_unbind(struct ata_device *dev)
-{
-   acpi_handle handle = ata_dev_acpi_handle(dev);
-   if (handle)
-   acpi_dev_pm_remove_dependent(handle, &dev->sdev->sdev_gendev);
-}
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 97a0cef..db6dfcf 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -3679,7 +3679,6 @@ void ata_scsi_scan_host(struct ata_port *ap, int sync)
if (!IS_ERR(sdev)) {
dev->sdev = sdev;
scsi_device_put(sdev);
-   ata_scsi_acpi_bind(dev);
} else {
dev->sdev = NULL;
}
@@ -3767,8 +3766,6 @@ static void ata_scsi_remove_dev(struct ata_device *dev)
struct scsi_device *sdev;
unsigned long flags;
 
-   ata_scsi_acpi_unbind(dev);
-
/* Alas, we need to grab scan_mutex to ensure SCSI device
 * state doesn't change underneath us and thus
 * scsi_device_get() always succeeds.  The mutex locking can
diff --git a/drivers/ata/libata.h b/drivers/ata/libata.h
index eeeb778..45b5ab3 100644
--- a/drivers/ata/libata.h
+++ b/drivers/ata/libata.h
@@ -121,8 +121,6 @@ extern void ata_acpi_set_state(struct ata_port *ap, 
pm_message_t state);
 extern void ata_acpi_bind_port(struct ata_port *ap);
 extern void ata_acpi_bind_dev(struct ata_device *dev);
 extern acpi_handle ata_dev_acpi_handle(struct ata_device *dev);
-extern void ata_scsi_acpi_bind(struct ata_device *dev);
-extern void ata_scsi_acpi_unbind(struct ata_device *dev);
 #else
 static inline void ata_acpi_dissociate(struct ata_host *host) { }
 static inline int ata_acpi_on_suspend(struct ata_port *ap) { return 0; }
@@ -133,8 +131,6 @@ static inline void ata_acpi_set_state(struct ata_port *ap,
  pm_message_t state) { }
 static inline void ata_acpi_bind_port(struct ata_port *ap

How to set fops in "struct platform_pwm_backlight_data"?

[Mark Zhang]

Hi,

This is the first time I send mail to linux-pwm, I didn't read through
the mails in this list, so if somebody already asked this question, I'm
sorry about that.

I wanna set some fops in "struct platform_pwm_backlight_data". But the
currrent probe function in pwm_bl.c says:

---
if (!data) {
ret = pwm_backlight_parse_dt(&pdev->dev, &defdata);
if (ret < 0) {
dev_err(&pdev->dev, "failed to find platform data\n");
return ret;
}

data = &defdata;
}
---

This looks like if we set the platform data for pwm backlight device,
"pwm_backlight_parse_dt" will never have a chance to be called, which
means the stuffs I defined in backlight DT node will be ignored.

If I don't set the platform data for pwm backlight device, according to
the pwm_backlight_probe, I will never have a chance to set some fops
which I need(like "notify", "check_fb"...).

So, what I suppose to do now? Maybe there is a way to set function
pointers in DT?

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 v2 3/9] bitops: Introduce a more generic BITMASK macro

[Chen Gong]

On Wed, Oct 16, 2013 at 07:59:09PM -0700, Joe Perches wrote:
> Date: Wed, 16 Oct 2013 19:59:09 -0700
> From: Joe Perches 
> To: "Chen, Gong" 
> Cc: tony.l...@intel.com, b...@alien8.de, naveen.n@linux.vnet.ibm.com,
>  m.che...@samsung.com, aroza...@redhat.com, linux-a...@vger.kernel.org,
>  linux-kernel@vger.kernel.org, Thomas Winischhofer
>  , Jean-Christophe Plagniol-Villard
>  , Tomi Valkeinen 
> Subject: Re: [PATCH v2 3/9] bitops: Introduce a more generic BITMASK macro
> X-Mailer: Evolution 3.6.4-0ubuntu1 
> 
> On Wed, 2013-10-16 at 10:56 -0400, Chen, Gong wrote:
> > GENMASK is used to create a contiguous bitmask([hi:lo]). It is
> > implemented twice in current kernel. One is in EDAC driver, the other
> > is in SiS/XGI FB driver. Move it to a more generic place for other
> > usage.
> []
> > diff --git a/include/linux/bitops.h b/include/linux/bitops.h
> []
> > @@ -10,6 +10,14 @@
> >  #define BITS_TO_LONGS(nr)  DIV_ROUND_UP(nr, BITS_PER_BYTE * sizeof(long))
> >  #endif
> >  
> > +/*
> > + * Create a contiguous bitmask starting at bit position @l and ending at
> > + * position @h. For example
> > + * GENMASK_ULL(39, 21) gives us the 64bit vector 0x00e0.
> 
> ull
> 
> > + */
> > +#define GENMASK(h, l)  (((U32_C(1) << ((h) - (l) + 1)) - 1) << 
> > (l))
> > +#define GENMASK_ULL(h, l)  (((U64_C(1) << ((h) - (l) + 1)) - 1) << (l))
> 
> 
> Maybe add a
> 
> BUILD_BUG_ON(__builtin_constant_p(l) && __builtin_constant_p(h) && \
>(h) < (l))
> 
No, if so, users can't use variables for this macro.


signature.asc
Description: Digital signature

[PATCH v2] n_gsm: race between ld close and gsmtty open

[channing]

ttyA has ld associated to n_gsm, when ttyA is closing, it triggers
to release gsmttyB's ld data dlci[B], then race would happen if gsmttyB
is opening in parallel.

Here are race cases we found recently in test:

CASE #1

releasing dlci[B] race with gsmtty_install(gsmttyB), then panic
in gsmtty_open(gsmttyB), as below:

 tty_release(ttyA)  tty_open(gsmttyB)
 |   |
   -   gsmtty_install(gsmttyB)
 |   |
   -gsm_dlci_alloc(gsmttyB) => alloc dlci[B]
 tty_ldisc_release(ttyA)   -
 |   |
 gsm_dlci_release(dlci[B]) -
 |   |
 gsm_dlci_free(dlci[B])-
 |   |
   -   gsmtty_open(gsmttyB)

 gsmtty_open()
 {
 struct gsm_dlci *dlci = tty->driver_data; => here it uses dlci[B]
 ...
 }

 In gsmtty_open(gsmttyA), it uses dlci[B] which was release, so hit a panic.
=

CASE #2
=
releasing dlci[0] race with gsmtty_install(gsmttyB), then panic
in gsmtty_open(), as below:

 tty_release(ttyA)  tty_open(gsmttyB)
 |   |
   -   gsmtty_install(gsmttyB)
 |   |
   -gsm_dlci_alloc(gsmttyB) => alloc dlci[B]
 |   |
   - gsmtty_open(gsmttyB) fail
 |   |
   -   tty_release(gsmttyB)
 |   |
   -   gsmtty_close(gsmttyB)
 |   |
   -gsmtty_detach_dlci(dlci[B])
 |   |
   - dlci_put(dlci[B])
 |   |
 tty_ldisc_release(ttyA)   -
 |   |
 gsm_dlci_release(dlci[0]) -
 |   |
 gsm_dlci_free(dlci[0])-
 |   |
   - dlci_put(dlci[0])

 In gsmtty_detach_dlci(dlci[B]), it tries to use dlci[0] which was released,
 then hit panic.
=

IMHO, n_gsm tty operations would refer released ldisc,  as long as
gsm_dlci_release() has chance to release ldisc data when some gsmtty operations
are not completed..

This patch is try to avoid it by:

1) in n_gsm driver, use a global gsm spin lock to avoid gsm_dlci_release() run 
in
parallel with gsmtty_install();

2) Increase dlci's ref count in gsmtty_install() instead of in gsmtty_open(), 
the
purpose is to prevent gsm_dlci_release() releasing dlci after gsmtty_install()
allocats dlci but before gsmtty_open increases dlci's ref count;

3) Decrease dlci's ref count in gsmtty_remove(), which is a tty framework api, 
and
this is the opposite process of step 2).

Signed-off-by: Chao Bi 
---
 drivers/tty/n_gsm.c |   37 +++--
 1 files changed, 27 insertions(+), 10 deletions(-)

diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index c0f76da..069bfd6 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -2054,9 +2054,11 @@ void gsm_cleanup_mux(struct gsm_mux *gsm)
dlci->state == DLCI_CLOSED);
}
/* Free up any link layer users */
+   spin_lock(&gsm->lock);
for (i = 0; i < NUM_DLCI; i++)
if (gsm->dlci[i])
gsm_dlci_release(gsm->dlci[i]);
+   spin_unlock(&gsm->lock);
/* Now wipe the queues */
list_for_each_entry_safe(txq, ntxq, &gsm->tx_list, list)
kfree(txq);
@@ -2909,23 +2911,33 @@ static int gsmtty_install(struct tty_driver *driver, 
struct tty_struct *tty)
This is ok from a locking
perspective as we don't have to worry about this
if DLCI0 is lost */
-   if (gsm->dlci[0] && gsm->dlci[0]->state != DLCI_OPEN)
+   spin_lock(&gsm->lock);
+   if (gsm->dlci[0] && gsm->dlci[0]->state != DLCI_OPEN) {
+   spin_unlock(&gsm->lock);
return -EL2NSYNC;
+   }
dlci = gsm->dlci[line];
if (dlci == NULL) {
alloc = true;
dlci = gsm_dlci_alloc(gsm, line);
}
-   if (dlci == NULL)
+   if (dlci == NULL) {
+   spin_unlock(&gsm->lock);
return -ENOMEM;
+   }
ret = tty_port_install(&dlci->port, driver, tty);
if (ret) {
  

[PATCH v2 8/8] ARM: add initial support for Marvell Berlin SoCs

[Sebastian Hesselbarth]

This adds initial support for the Marvell Berlin (88DE3xxx) SoC family
and basic machine setup for Armada 1500 (88DE3100) SoCs.

Signed-off-by: Sebastian Hesselbarth 
Reviewed-by: Jason Cooper 
Reviewed-by: Thomas Petazzoni 
Reviewed-by: Arnd Bergmann 
---
Changelog:
v1->v2:
- replace 88DE3xxx numbering with SoC variant name
  (Requested by Jisheng Zhang)
- remove LOCAL_TIMERS dependency (Suggested by Dinh Nguyen)
RFCv2->v1:
- remove custom .init_time, adds dependency for arch-wide of_clk_init call
RFCv1->RFCv2:
- nuke .map_io (Reported by Arnd Bergmann)
- add copyright reference
- switch to mach-berlin instead of mach-mvebu

Cc: Jason Cooper 
Cc: Thomas Petazzoni 
Cc: Arnd Bergmann 
Cc: Russell King 
Cc: Jisheng Zhang 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 arch/arm/Kconfig  |2 ++
 arch/arm/Makefile |1 +
 arch/arm/mach-berlin/Kconfig  |   23 +++
 arch/arm/mach-berlin/Makefile |1 +
 arch/arm/mach-berlin/berlin.c |   39 +++
 5 files changed, 66 insertions(+)
 create mode 100644 arch/arm/mach-berlin/Kconfig
 create mode 100644 arch/arm/mach-berlin/Makefile
 create mode 100644 arch/arm/mach-berlin/berlin.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1ad6fb6..5692426 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -932,6 +932,8 @@ source "arch/arm/mach-bcm/Kconfig"
 
 source "arch/arm/mach-bcm2835/Kconfig"
 
+source "arch/arm/mach-berlin/Kconfig"
+
 source "arch/arm/mach-clps711x/Kconfig"
 
 source "arch/arm/mach-cns3xxx/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index a37a50f..3ba332b 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -147,6 +147,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
 machine-$(CONFIG_ARCH_AT91)+= at91
 machine-$(CONFIG_ARCH_BCM) += bcm
 machine-$(CONFIG_ARCH_BCM2835) += bcm2835
+machine-$(CONFIG_ARCH_BERLIN)  += berlin
 machine-$(CONFIG_ARCH_CLPS711X)+= clps711x
 machine-$(CONFIG_ARCH_CNS3XXX) += cns3xxx
 machine-$(CONFIG_ARCH_DAVINCI) += davinci
diff --git a/arch/arm/mach-berlin/Kconfig b/arch/arm/mach-berlin/Kconfig
new file mode 100644
index 000..bdd5383
--- /dev/null
+++ b/arch/arm/mach-berlin/Kconfig
@@ -0,0 +1,23 @@
+config ARCH_BERLIN
+   bool "Marvell Berlin SoCs" if ARCH_MULTI_V7
+   select GENERIC_CLOCKEVENTS
+   select GENERIC_IRQ_CHIP
+   select COMMON_CLK
+   select DW_APB_ICTL
+   select DW_APB_TIMER_OF
+
+if ARCH_BERLIN
+
+menu "Marvell Berlin SoC variants"
+
+config MACH_BERLIN_BG2
+   bool "Marvell Armada 1500 (BG2)"
+   select ARM_GIC
+   select CACHE_L2X0
+   select CPU_PJ4B
+   select HAVE_ARM_TWD if SMP
+   select HAVE_SMP
+
+endmenu
+
+endif
diff --git a/arch/arm/mach-berlin/Makefile b/arch/arm/mach-berlin/Makefile
new file mode 100644
index 000..ab69fe9
--- /dev/null
+++ b/arch/arm/mach-berlin/Makefile
@@ -0,0 +1 @@
+obj-y += berlin.o
diff --git a/arch/arm/mach-berlin/berlin.c b/arch/arm/mach-berlin/berlin.c
new file mode 100644
index 000..16c2942
--- /dev/null
+++ b/arch/arm/mach-berlin/berlin.c
@@ -0,0 +1,39 @@
+/*
+ * Device Tree support for Marvell Berlin SoCs.
+ *
+ * Sebastian Hesselbarth 
+ *
+ * based on GPL'ed 2.6 kernel sources
+ *  (c) Marvell International Ltd.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static void __init berlin_init_machine(void)
+{
+   /*
+* with DT probing for L2CCs, berlin_init_machine can be removed.
+* Note: 88DE3005 (Armada 1500-mini) uses pl310 l2cc
+*/
+   l2x0_of_init(0x70c0, 0xfeff);
+   of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static const char * const berlin_dt_compat[] = {
+   "marvell,berlin",
+   NULL,
+};
+
+DT_MACHINE_START(BERLIN_DT, "Marvell Berlin")
+   .dt_compat  = berlin_dt_compat,
+   .init_machine   = berlin_init_machine,
+MACHINE_END
-- 
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/

[PATCH v2 7/8] ARM: add Armada 1500 and Sony NSZ-GS7 device tree files

[Sebastian Hesselbarth]

This adds very basic device tree files for the Marvell Armada 1500 SoC
(Berlin BG2) and the Sony NSZ-GS7 GoogleTV board. Currently, SoC only has
nodes for cpus, some clocks, l2 cache controller, local timer, apb timers,
uart, and interrupt controllers. The Sony NSZ-GS7 is a GoogleTV consumer
device comprising the Armada 1500 SoC above.

Signed-off-by: Sebastian Hesselbarth 
Reviewed-by: Jason Cooper 
Reviewed-by: Thomas Petazzoni 
Reviewed-by: Arnd Bergmann 
Reviewed-by: Jisheng Zhang 
---
Changelog:
v1->v2:
- add "arm,pl310-cache" compatible to l2cc (Suggested by Mark Rutland)
- replace 88DE3xxx numbering with SoC variant name
  (Requested by Jisheng Zhang)
RCFv2->v1:
- switch to (soon to be) correct "marvell,pj4b" cpu compatible
- reference fixed-clock for uarts instead of hard-coded clock-frequency
- disable timers except two for clksrc and clkevt
RFCv1->RFCv2:
- add binding documentation (Reported by Jason Cooper)
- change l2cc from aurora to tauros3 (Reported by Thomas Petazzoni)
- add copyright reference
- adapt compatibles to mach-berlin instead of mach-mvebu

Cc: Jason Cooper 
Cc: Thomas Petazzoni 
Cc: Arnd Bergmann 
Cc: Mark Rutland 
Cc: Jisheng Zhang 
Cc: devicet...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 .../devicetree/bindings/arm/marvell,berlin.txt |   24 +++
 arch/arm/boot/dts/Makefile |2 +
 arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts |   29 +++
 arch/arm/boot/dts/berlin2.dtsi |  227 
 4 files changed, 282 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell,berlin.txt
 create mode 100644 arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts
 create mode 100644 arch/arm/boot/dts/berlin2.dtsi

diff --git a/Documentation/devicetree/bindings/arm/marvell,berlin.txt 
b/Documentation/devicetree/bindings/arm/marvell,berlin.txt
new file mode 100644
index 000..737afa5
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell,berlin.txt
@@ -0,0 +1,24 @@
+Marvell Berlin SoC Family Device Tree Bindings
+---
+
+Boards with a SoC of the Marvell Berlin family, e.g. Armada 1500
+shall have the following properties:
+
+* Required root node properties:
+compatible: must contain "marvell,berlin"
+
+In addition, the above compatible shall be extended with the specific
+SoC and board used. Currently known SoC compatibles are:
+"marvell,berlin2"  for Marvell Armada 1500 (BG2, 88DE3100),
+"marvell,berlin2cd"for Marvell Armada 1500-mini (BG2CD, 88DE3005)
+"marvell,berlin2ct"for Marvell Armada ? (BG2CT, 88DE)
+"marvell,berlin3"  for Marvell Armada ? (BG3, 88DE)
+
+* Example:
+
+/ {
+   model = "Sony NSZ-GS7";
+   compatible = "sony,nsz-gs7", "marvell,berlin2", "marvell,berlin";
+
+   ...
+}
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 802720e..c9c1a6c 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -46,6 +46,8 @@ dtb-$(CONFIG_ARCH_ATLAS6) += atlas6-evb.dtb
 dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb
 dtb-$(CONFIG_ARCH_BCM) += bcm11351-brt.dtb \
bcm28155-ap.dtb
+dtb-$(CONFIG_ARCH_BERLIN) += \
+   berlin2-sony-nsz-gs7.dtb
 dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
da850-evm.dtb
 dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \
diff --git a/arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts 
b/arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts
new file mode 100644
index 000..c72bfd4
--- /dev/null
+++ b/arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts
@@ -0,0 +1,29 @@
+/*
+ * Device Tree file for Sony NSZ-GS7
+ *
+ * Sebastian Hesselbarth 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+
+#include "berlin2.dtsi"
+
+/ {
+   model = "Sony NSZ-GS7";
+   compatible = "sony,nsz-gs7", "marvell,berlin2", "marvell,berlin";
+
+   chosen {
+   bootargs = "console=ttyS0,115200 earlyprintk";
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x 0x4000>; /* 1 GB */
+   };
+};
+
+&uart0 { status = "okay"; };
diff --git a/arch/arm/boot/dts/berlin2.dtsi b/arch/arm/boot/dts/berlin2.dtsi
new file mode 100644
index 000..56a1af2
--- /dev/null
+++ b/arch/arm/boot/dts/berlin2.dtsi
@@ -0,0 +1,227 @@
+/*
+ * Device Tree Include file for Marvell Armada 1500 (Berlin BG2) SoC
+ *
+ * Sebastian Hesselbarth 
+ *
+ * based on GPL'ed 2.6 kernel sources
+ *  (c) Marvell International Ltd.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include "skeleton.dtsi"
+#include 
+
+/ {
+  

[PATCH v2 1/8] irqchip: add DesignWare APB ICTL interrupt controller

[Sebastian Hesselbarth]

This adds an irqchip driver and corresponding devicetree binding for the
secondary interrupt controllers based on Synopsys DesignWare IP dw_apb_ictl.

Signed-off-by: Sebastian Hesselbarth 
Reviewed-by: Mark Rutland 
Reviewed-by: Jisheng Zhang 
---
Changelog:
v1->v2:
- reword binding docu for reg property and add FIQ decoding note
  (Suggested by Mark Rutland)
- add cleanup on error path (Reported by Jisheng Zhang)
RFCv1->RFCv2:
- added copyright reference

Cc: Jason Cooper 
Cc: Thomas Petazzoni 
Cc: Arnd Bergmann 
Cc: Thomas Gleixner 
Cc: Mark Rutland 
Cc: Jisheng Zhang 
Cc: devicet...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 .../interrupt-controller/snps,dw-apb-ictl.txt  |   32 +
 drivers/irqchip/Kconfig|4 +
 drivers/irqchip/Makefile   |1 +
 drivers/irqchip/irq-dw-apb-ictl.c  |  150 
 4 files changed, 187 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
 create mode 100644 drivers/irqchip/irq-dw-apb-ictl.c

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt 
b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
new file mode 100644
index 000..4929117
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
@@ -0,0 +1,32 @@
+Synopsys DesignWare APB interrupt controller (dw_apb_ictl)
+
+Synopsys DesignWare provides interrupt controller IP for APB known as
+dw_apb_ictl. The IP is used as secondary interrupt controller in some SoCs with
+APB bus, e.g. Marvell Armada 1500.
+
+Required properties:
+- compatible: shall be "snps,dw-apb-ictl"
+- reg: physical base address of the controller and length of memory mapped
+  region starting with ENABLE_LOW register
+- interrupt-controller: identifies the node as an interrupt controller
+- #interrupt-cells: number of cells to encode an interrupt-specifier, shall be 
1
+- interrupts: interrupt reference to primary interrupt controller
+- interrupt-parent: (optional) reference specific primary interrupt controller
+
+The interrupt sources map to the corresponding bits in the interrupt
+registers, i.e.
+- 0 maps to bit 0 of low interrupts,
+- 1 maps to bit 1 of low interrupts,
+- 32 maps to bit 0 of high interrupts,
+- 33 maps to bit 1 of high interrupts,
+- (optional) fast interrupts start at 64.
+
+Example:
+   aic: interrupt-controller@3000 {
+   compatible = "snps,dw-apb-ictl";
+   reg = <0x3000 0xc00>;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   interrupt-parent = <&gic>;
+   interrupts = ;
+   };
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 3792a1a..940638d 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -30,6 +30,10 @@ config ARM_VIC_NR
  The maximum number of VICs available in the system, for
  power management.
 
+config DW_APB_ICTL
+   bool
+   select IRQ_DOMAIN
+
 config IMGPDC_IRQ
bool
select GENERIC_IRQ_CHIP
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index c60b901..6427323 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_ARCH_MMP)  += irq-mmp.o
 obj-$(CONFIG_ARCH_MVEBU)   += irq-armada-370-xp.o
 obj-$(CONFIG_ARCH_MXS) += irq-mxs.o
 obj-$(CONFIG_ARCH_S3C24XX) += irq-s3c24xx.o
+obj-$(CONFIG_DW_APB_ICTL)  += irq-dw-apb-ictl.o
 obj-$(CONFIG_METAG)+= irq-metag-ext.o
 obj-$(CONFIG_METAG_PERFCOUNTER_IRQS)   += irq-metag.o
 obj-$(CONFIG_ARCH_MOXART)  += irq-moxart.o
diff --git a/drivers/irqchip/irq-dw-apb-ictl.c 
b/drivers/irqchip/irq-dw-apb-ictl.c
new file mode 100644
index 000..31e231e
--- /dev/null
+++ b/drivers/irqchip/irq-dw-apb-ictl.c
@@ -0,0 +1,150 @@
+/*
+ * Synopsys DW APB ICTL irqchip driver.
+ *
+ * Sebastian Hesselbarth 
+ *
+ * based on GPL'ed 2.6 kernel sources
+ *  (c) Marvell International Ltd.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "irqchip.h"
+
+#define APB_INT_ENABLE_L   0x00
+#define APB_INT_ENABLE_H   0x04
+#define APB_INT_MASK_L 0x08
+#define APB_INT_MASK_H 0x0c
+#define APB_INT_FINALSTATUS_L  0x30
+#define APB_INT_FINALSTATUS_H  0x34
+
+static void dw_apb_ictl_handler(unsigned int irq, struct irq_desc *desc)
+{
+   struct irq_chip *chip = irq_get_chip(irq);
+   struct irq_chip_generic *gc = irq_get_handler_data(irq);
+   struct irq_domain *d = gc->private;
+   u32 stat;
+   int 

[PATCH v2 3/8] ARM: l2x0: add Marvell Tauros3 support

[Sebastian Hesselbarth]

This adds support for the Marvell Tauros3 cache controller which
is compatible with pl310 cache controller but broadcasts L1 cache
operations to L2 cache. While updating the binding documentation,
clean up the list of possible compatibles. Also reorder driver
compatibles to allow non-ARM derivated to be compatible to ARM
cache controller compatibles.

Signed-off-by: Sebastian Hesselbarth 
Reviewed-by: Mark Rutland 
---
Changelog:
v1->v2:
- add tauros3 data without outer cache ops (Suggested by Jisheng Zhang)
- reorder compatibles to allow derivates to be compatible with ARM
  controllers (Suggested by Mark Rutland)

Cc: Jason Cooper 
Cc: Thomas Petazzoni 
Cc: Arnd Bergmann 
Cc: Mark Rutland 
Cc: Jisheng Zhang 
Cc: devicet...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 Documentation/devicetree/bindings/arm/l2cc.txt |   23 +--
 arch/arm/include/asm/hardware/cache-l2x0.h |1 +
 arch/arm/mm/cache-l2x0.c   |   49 
 arch/arm/mm/cache-tauros3.h|   41 
 4 files changed, 95 insertions(+), 19 deletions(-)
 create mode 100644 arch/arm/mm/cache-tauros3.h

diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt 
b/Documentation/devicetree/bindings/arm/l2cc.txt
index c0c7626..b513cb8 100644
--- a/Documentation/devicetree/bindings/arm/l2cc.txt
+++ b/Documentation/devicetree/bindings/arm/l2cc.txt
@@ -7,20 +7,21 @@ The ARM L2 cache representation in the device tree should be 
done as follows:
 Required properties:
 
 - compatible : should be one of:
-   "arm,pl310-cache"
-   "arm,l220-cache"
-   "arm,l210-cache"
-   "marvell,aurora-system-cache": Marvell Controller designed to be
+  "arm,pl310-cache"
+  "arm,l220-cache"
+  "arm,l210-cache"
+  "bcm,bcm11351-a2-pl310-cache": DEPRECATED by "brcm,bcm11351-a2-pl310-cache"
+  "brcm,bcm11351-a2-pl310-cache": For Broadcom bcm11351 chipset where an
+ offset needs to be added to the address before passing down to the L2
+ cache controller
+  "marvell,aurora-system-cache": Marvell Controller designed to be
  compatible with the ARM one, with system cache mode (meaning
  maintenance operations on L1 are broadcasted to the L2 and L2
  performs the same operation).
-   "marvell,"aurora-outer-cache: Marvell Controller designed to be
-compatible with the ARM one with outer cache mode.
-   "brcm,bcm11351-a2-pl310-cache": For Broadcom bcm11351 chipset where an
-   offset needs to be added to the address before passing down to the L2
-   cache controller
-   "bcm,bcm11351-a2-pl310-cache": DEPRECATED by
-  "brcm,bcm11351-a2-pl310-cache"
+  "marvell,aurora-outer-cache": Marvell Controller designed to be
+ compatible with the ARM one with outer cache mode.
+  "marvell,tauros3-cache": Marvell Tauros3 cache controller, compatible
+ with arm,pl310-cache controller.
 - cache-unified : Specifies the cache is a unified cache.
 - cache-level : Should be set to 2 for a level 2 cache.
 - reg : Physical base address and size of cache controller's memory mapped
diff --git a/arch/arm/include/asm/hardware/cache-l2x0.h 
b/arch/arm/include/asm/hardware/cache-l2x0.h
index 3b2c40b..6795ff7 100644
--- a/arch/arm/include/asm/hardware/cache-l2x0.h
+++ b/arch/arm/include/asm/hardware/cache-l2x0.h
@@ -131,6 +131,7 @@ struct l2x0_regs {
unsigned long prefetch_ctrl;
unsigned long pwr_ctrl;
unsigned long ctrl;
+   unsigned long aux2_ctrl;
 };
 
 extern struct l2x0_regs l2x0_saved_regs;
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 447da6f..a70a4f5 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -25,6 +25,7 @@
 
 #include 
 #include 
+#include "cache-tauros3.h"
 #include "cache-aurora-l2.h"
 
 #define CACHE_LINE_SIZE32
@@ -767,6 +768,14 @@ static void aurora_save(void)
l2x0_saved_regs.aux_ctrl = readl_relaxed(l2x0_base + L2X0_AUX_CTRL);
 }
 
+static void __init tauros3_save(void)
+{
+   l2x0_saved_regs.aux2_ctrl =
+   readl_relaxed(l2x0_base + TAUROS3_AUX2_CTRL);
+   l2x0_saved_regs.prefetch_ctrl =
+   readl_relaxed(l2x0_base + L2X0_PREFETCH_CTRL);
+}
+
 static void l2x0_resume(void)
 {
if (!(readl_relaxed(l2x0_base + L2X0_CTRL) & L2X0_CTRL_EN)) {
@@ -821,6 +830,18 @@ static void aurora_resume(void)
}
 }
 
+static void tauros3_resume(void)
+{
+   if (!(readl_relaxed(l2x0_base + L2X0_CTRL) & L2X0_CTRL_EN)) {
+   writel_relaxed(l2x0_saved_regs.aux2_ctrl,
+  l2x0_base + TAUROS3_AUX2_CTRL);
+   writel_relaxed(l2x0_saved_regs.prefetch_ctrl,
+  l2x0_base + L2X0_PREFETCH_CTRL);
+   }
+
+   l2x0_resume();
+}
+
 static void __init aurora_broadcast_l2_commands(void)
 {
__u32 u;
@@ -906,6 +927,15 @@ 

Re: Re: [PATCH V2 2/5] trace-cmd: Apply the trace-msg protocol for communication between a server and clients

[Yoshihiro YUNOMAE]

(2013/10/15 11:21), Steven Rostedt wrote:

On Fri, 13 Sep 2013 11:06:32 +0900
Yoshihiro YUNOMAE  wrote:


Apply trace-msg protocol for communication between a server and clients.

Currently, trace-listen(server) and trace-record -N(client) operate as follows:

   
   listen to socket fd
   connect to socket fd
   accept the client
   send "tracecmd"
+> receive "tracecmd"
   check "tracecmd"
   send cpus
   receive cpus <+
   print "cpus=XXX"
   send pagesize
 |
   receive pagesize <+
   print "pagesize=XXX"
   send option
 |
   receive option <--+
   understand option
   send port_array
+> receive port_array
   understand port_array
   send meta data
   receive meta data <---+
   record meta data
 (snip)
   read block
  --- start sending trace data on child processes ---

  --- When client finishes sending trace data ---
   close(socket fd)
   read size = 0
   close(socket fd)


Note, this patch is filled with whitespace errors. Run checkpatch.pl on
it if you can.


Oh sorry. I'll check it.


I applied and fixed up the first patch.

Also, when I tested this patch I got:

Running in one terminal:

# trace-cmd listen -p 12345

And then in another terminal:

# trace-cmd record -N localhost:12345 -p function -e all
/debug/tracing/events/*/filter
   plugin 'function'
Hit Ctrl^C to stop recording
trace-cmd: Connection refused
   trace-cmd: Connection refused
trace-cmd: Connection refused
recorder error in splice output  recorder error in splice output

recorder error in splice output
trace-cmd: Connection refused
   recorder error in splice output


It seems to be not due to applying my patch.
We cannot use "localhost" for trace-cmd(v1.2).
When we use "127.0.0.1", this problem does not occur.

Thanks,
Yoshihiro YUNOMAE


-- Steve





All messages are unstructured character strings, so server(client) using the
protocol must parse the unstructured messages. Since it is hard to
add complex contents in the protocol, structured binary message trace-msg
is introduced as the communication protocol.

By applying this patch, server and client operate as follows:

   
   listen to socket fd
   connect to socket fd
   accept the client
   send "tracecmd"
+> receive "tracecmd"
   check "tracecmd"
   send "V2\0\00" as the v2 protocol
   receive "V2" <+
   check "V2"
   read "\00"
   send "V2"
 +---> receive "V2"
   check "V2"
   send cpus,pagesize,option(MSG_TINIT)
   receive MSG_TINIT <---+
   print "cpus=XXX"
   print "pagesize=XXX"
   understand option
   send port_array
+--MSG_RINIT-> receive MSG_RINIT
   understand port_array
   send meta data(MSG_SENDMETA)
   receive MSG_SENDMETA <+
   record meta data
  (snip)
   send a message to finish sending meta data
 |   (MSG_FINMETA)
   receive MSG_FINMETA <-+
   read block
  --- start sending trace data on child processes ---

  --- When client finishes sending trace data ---
   send MSG_CLOSE
   receive MSG_CLOSE <---+
   close(socket fd)close(socket fd)

By introducing the v2 protocol, after the client checks "tracecmd", the client
will send "V2\0\00\0". This complex message is used when the
new client tries to connect to the old server. The new client wants to check
whether the reply message from the server is "V2" or not. However, the old
server does not respond to the client before receiving cpu numbers, page size,
and options. Each message is separated with "\0" in the old server, so the
client send "V2" as cpu numbers, "" as page size, and "0" as
no options. On the other hands, the old server will understand the messages
as cpus=0, pagesize=, and options=0, and then the server will
send the message "\0" as port numbers. Then, the message which the client
receives is not "V2" but "\0", so the client will reconnect to the old server
as the v1 protocol.

Changes in V2: Regacy porotocol support in order to keep backward compatibility

Signed-off-by: Yoshihiro YUNOMAE 
---
  Makefile   |2
  trace-cmd.h|   11 +
  trace-listen.c |  133 +++
  trace-msg

[PATCH v4 7/7] jump_label: use defined macros instead of hard-coding for better readability

[Jiang Liu]

From: Jiang Liu 

Use macro JUMP_LABEL_TRUE_BRANCH instead of hard-coding for better
readability.

Signed-off-by: Jiang Liu 
Cc: Jiang Liu 
---
 include/linux/jump_label.h | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index a507907..6e54029 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -74,18 +74,21 @@ struct module;
 #include 
 #ifdef HAVE_JUMP_LABEL
 
-#define JUMP_LABEL_TRUE_BRANCH 1UL
+#define JUMP_LABEL_TYPE_FALSE_BRANCH   0UL
+#define JUMP_LABEL_TYPE_TRUE_BRANCH1UL
+#define JUMP_LABEL_TYPE_MASK   1UL
 
 static
 inline struct jump_entry *jump_label_get_entries(struct static_key *key)
 {
return (struct jump_entry *)((unsigned long)key->entries
-   & ~JUMP_LABEL_TRUE_BRANCH);
+   & ~JUMP_LABEL_TYPE_MASK);
 }
 
 static inline bool jump_label_get_branch_default(struct static_key *key)
 {
-   if ((unsigned long)key->entries & JUMP_LABEL_TRUE_BRANCH)
+   if (((unsigned long)key->entries & JUMP_LABEL_TYPE_MASK) ==
+   JUMP_LABEL_TYPE_TRUE_BRANCH)
return true;
return false;
 }
@@ -116,9 +119,11 @@ extern void static_key_slow_dec(struct static_key *key);
 extern void jump_label_apply_nops(struct module *mod);
 
 #define STATIC_KEY_INIT_TRUE ((struct static_key) \
-   { .enabled = ATOMIC_INIT(1), .entries = (void *)1 })
+   { .enabled = ATOMIC_INIT(1), \
+ .entries = (void *)JUMP_LABEL_TYPE_TRUE_BRANCH })
 #define STATIC_KEY_INIT_FALSE ((struct static_key) \
-   { .enabled = ATOMIC_INIT(0), .entries = (void *)0 })
+   { .enabled = ATOMIC_INIT(0), \
+ .entries = (void *)JUMP_LABEL_TYPE_FALSE_BRANCH })
 
 #else  /* !HAVE_JUMP_LABEL */
 
-- 
1.8.1.2

--
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: Re: [PATCH V2 0/5] trace-cmd: Support the feature recording trace data of guests on the host

[Yoshihiro YUNOMAE]

Hi Steven,

(2013/10/15 6:26), Steven Rostedt wrote:

On Fri, 13 Sep 2013 11:06:27 +0900
Yoshihiro YUNOMAE  wrote:




1. Run virt-server on a host
# trace-cmd virt-server

2. Make guest domain directory
# mkdir -p /tmp/trace-cmd/virt/
# chmod 710 /tmp/trace-cmd/virt/
# chgrp qemu /tmp/trace-cmd/virt/


Quick comment. I think the above should be done by trace-cmd. At least
have options for it like:

trace-cmd virt-server -d /tmp/trace-cmd/virt/domain -m 710 -g qemu

Perhaps default some of those, and have trace-cmd print out:

   Process Directory: /tmp/trace-cmd/virt/domain
   Directory permission:  0710
   Group: qemu


OK. As you say, when we know domains which we will boot, trace-cmd
should make those automatically. So, I'll add this feature.
Note that if we don't know domains when we boot virt-sevrer, we must
make those manually now.

In this patch set, virt-server always uses /tmp/trace-cmd/virt, so
we had better indicate only the domain name with d option, I think.

trace-cmd virt-server -d domain -m 710 -g qemu

What do you think about this?

Thanks,

Yoshihiro YUNOMAE


OK, now to look at the actual code ;-)

-- Steve




3. Make FIFO on the host
# mkfifo /tmp/trace-cmd/virt//trace-path-cpu{0,1,...,X}.{in,out}

4. Set up of virtio-serial pipe of a guest on the host
Add the following tags to domain XML files.
# virsh edit 

   
   


   
   

... (cpu1, cpu2, ...)

5. Boot the guest
# virsh start 

6. Execute "record --virt" on the guest
# trace-cmd record --virt -e sched*


--
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/



--
Yoshihiro YUNOMAE
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: yoshihiro.yunomae...@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/

[PATCH v4 6/7] arm64, jump label: optimize jump label implementation

[Jiang Liu]

From: Jiang Liu 

Optimize jump label implementation for ARM64 by dynamically patching
kernel text.

Signed-off-by: Jiang Liu 
Cc: Jiang Liu 
---
 arch/arm64/Kconfig  |  1 +
 arch/arm64/include/asm/jump_label.h | 52 +
 arch/arm64/kernel/Makefile  |  1 +
 arch/arm64/kernel/jump_label.c  | 58 +
 4 files changed, 112 insertions(+)
 create mode 100644 arch/arm64/include/asm/jump_label.h
 create mode 100644 arch/arm64/kernel/jump_label.c

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index c044548..da388e4 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -17,6 +17,7 @@ config ARM64
select GENERIC_SMP_IDLE_THREAD
select GENERIC_TIME_VSYSCALL
select HARDIRQS_SW_RESEND
+   select HAVE_ARCH_JUMP_LABEL
select HAVE_ARCH_TRACEHOOK
select HAVE_DEBUG_BUGVERBOSE
select HAVE_DEBUG_KMEMLEAK
diff --git a/arch/arm64/include/asm/jump_label.h 
b/arch/arm64/include/asm/jump_label.h
new file mode 100644
index 000..d268fab
--- /dev/null
+++ b/arch/arm64/include/asm/jump_label.h
@@ -0,0 +1,52 @@
+/*
+ * Copyright (C) 2013 Huawei Ltd.
+ * Author: Jiang Liu 
+ *
+ * Based on arch/arm/include/asm/jump_label.h
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+#ifndef _ASM_ARM64_JUMP_LABEL_H
+#define _ASM_ARM64_JUMP_LABEL_H
+#include 
+
+#ifdef __KERNEL__
+
+#define JUMP_LABEL_NOP_SIZE 4
+
+static __always_inline bool arch_static_branch(struct static_key *key)
+{
+   asm goto("1:\n\t"
+"nop\n\t"
+".pushsection __jump_table,  \"aw\"\n\t"
+".align 3\n\t"
+".quad 1b, %l[l_yes], %c0\n\t"
+".popsection\n\t"
+:  :  "i"(key) :  : l_yes);
+
+   return false;
+l_yes:
+   return true;
+}
+
+#endif /* __KERNEL__ */
+
+typedef u64 jump_label_t;
+
+struct jump_entry {
+   jump_label_t code;
+   jump_label_t target;
+   jump_label_t key;
+};
+
+#endif /* _ASM_ARM64_JUMP_LABEL_H */
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 9af6cb3..b7db65e 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -18,6 +18,7 @@ arm64-obj-$(CONFIG_SMP)   += smp.o 
smp_spin_table.o smp_psci.o
 arm64-obj-$(CONFIG_HW_PERF_EVENTS) += perf_event.o
 arm64-obj-$(CONFIG_HAVE_HW_BREAKPOINT)+= hw_breakpoint.o
 arm64-obj-$(CONFIG_EARLY_PRINTK)   += early_printk.o
+arm64-obj-$(CONFIG_JUMP_LABEL) += jump_label.o
 
 obj-y  += $(arm64-obj-y) vdso/
 obj-m  += $(arm64-obj-m)
diff --git a/arch/arm64/kernel/jump_label.c b/arch/arm64/kernel/jump_label.c
new file mode 100644
index 000..871786a
--- /dev/null
+++ b/arch/arm64/kernel/jump_label.c
@@ -0,0 +1,58 @@
+/*
+ * Copyright (C) 2013 Huawei Ltd.
+ * Author: Jiang Liu 
+ *
+ * Based on arch/arm/kernel/jump_label.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+
+#ifdef HAVE_JUMP_LABEL
+
+static void __arch_jump_label_transform(struct jump_entry *entry,
+   enum jump_label_type type,
+   bool is_static)
+{
+   void *addr = (void *)entry->code;
+   u32 insn;
+
+   if (type == JUMP_LABEL_ENABLE) {
+   insn = aarch64_insn_gen_branch_imm(entry->code,
+  entry->target, 0);
+   } else {
+   insn = aarch64_insn_gen_nop();
+   }
+
+   if (is_static)
+   aarch64_insn_patch_text_nosync(&addr, &insn, 1);
+   else
+   aarch64_insn_patch_text(&addr, &insn, 1);
+}
+
+void arch_jump_label_transform(struct jump_entry *entry,
+  enum jump_label_type type)
+{
+   __a

[PATCH v4 4/7] arm64: introduce aarch64_insn_gen_{nop|branch_imm}() helper functions

[Jiang Liu]

From: Jiang Liu 

Introduce aarch64_insn_gen_{nop|branch_imm}() helper functions, which
will be used to implement jump label on ARM64.

Signed-off-by: Jiang Liu 
Cc: Jiang Liu 
---
 arch/arm64/include/asm/insn.h |  7 +++
 arch/arm64/kernel/insn.c  | 28 
 2 files changed, 35 insertions(+)

diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
index d62b601..ac129a8 100644
--- a/arch/arm64/include/asm/insn.h
+++ b/arch/arm64/include/asm/insn.h
@@ -94,6 +94,13 @@ static __always_inline void aarch64_insn_write(void *addr, 
u32 insn)
 enum aarch64_insn_encoding_class aarch64_get_insn_class(u32 insn);
 u32 aarch64_insn_encode_immediate(enum aarch64_insn_imm_type type,
  u32 insn, u64 imm);
+u32 aarch64_insn_gen_branch_imm(unsigned long pc, unsigned long addr,
+   bool link);
+static __always_inline u32 aarch64_insn_gen_nop(void)
+{
+   return aarch64_insn_get_nop_value();
+}
+
 bool aarch64_insn_hotpatch_safe(u32 old_insn, u32 new_insn);
 
 int aarch64_insn_patch_text_nosync(void *addrs[], u32 insns[], int cnt);
diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
index 344d23ed..a59f71d 100644
--- a/arch/arm64/kernel/insn.c
+++ b/arch/arm64/kernel/insn.c
@@ -14,6 +14,7 @@
  * You should have received a copy of the GNU General Public License
  * along with this program.  If not, see .
  */
+#include 
 #include 
 #include 
 #include 
@@ -205,3 +206,30 @@ u32 aarch64_insn_encode_immediate(enum 
aarch64_insn_imm_type type,
 
return insn;
 }
+
+u32 aarch64_insn_gen_branch_imm(unsigned long pc, unsigned long addr, bool 
link)
+{
+   u32 insn;
+   long offset;
+
+   /*
+* PC: A 64-bit Program Counter holding the address of the current
+* instruction. A64 instructions may be word-aligned.
+*/
+   BUG_ON((pc & 0x3) || (addr & 0x3));
+
+   /*
+* B/BL support [-128M, 128M) offset
+* ARM64 virtual address arrangement garantees all kernel and module
+* texts are within +/-128M.
+*/
+   offset = ((long)addr - (long)pc) >> 2;
+   BUG_ON(abs(offset) > BIT(25) || offset == BIT(25));
+
+   if (link)
+   insn = aarch64_insn_get_bl_value();
+   else
+   insn = aarch64_insn_get_b_value();
+
+   return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_26, insn, offset);
+}
-- 
1.8.1.2

--
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 v4 5/7] arm64, jump label: detect %c support for ARM64

[Jiang Liu]

From: Jiang Liu 

As commit a9468f30b5eac6 "ARM: 7333/2: jump label: detect %c
support for ARM", this patch detects the same thing for ARM64
because some ARM64 GCC versions have the same issue.

Some versions of ARM64 GCC which do support asm goto, do not
support the %c specifier. Since we need the %c to support jump
labels on ARM64, detect that too in the asm goto detection script
to avoid build errors with these versions.

Signed-off-by: Jiang Liu 
Cc: Jiang Liu 
---
 scripts/gcc-goto.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/gcc-goto.sh b/scripts/gcc-goto.sh
index a2af2e8..c9469d3 100644
--- a/scripts/gcc-goto.sh
+++ b/scripts/gcc-goto.sh
@@ -5,7 +5,7 @@
 cat << "END" | $@ -x c - -c -o /dev/null >/dev/null 2>&1 && echo "y"
 int main(void)
 {
-#ifdef __arm__
+#if defined(__arm__) || defined(__aarch64__)
/*
 * Not related to asm goto, but used by jump label
 * and broken on some ARM GCC versions (see GCC Bug 48637).
-- 
1.8.1.2

--
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 v4 3/7] arm64: move encode_insn_immediate() from module.c to insn.c

[Jiang Liu]

From: Jiang Liu 

Function encode_insn_immediate() will be used by other instruction
manipulate related functions, so move it into insn.c and rename it
as aarch64_insn_encode_immediate().

Signed-off-by: Jiang Liu 
Cc: Jiang Liu 
---
 arch/arm64/include/asm/insn.h |  14 
 arch/arm64/kernel/insn.c  |  58 
 arch/arm64/kernel/module.c| 152 +-
 3 files changed, 117 insertions(+), 107 deletions(-)

diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
index fc439b9..d62b601 100644
--- a/arch/arm64/include/asm/insn.h
+++ b/arch/arm64/include/asm/insn.h
@@ -42,6 +42,18 @@ enum aarch64_insn_encoding_class {
 * system instructions */
 };
 
+enum aarch64_insn_imm_type {
+   AARCH64_INSN_IMM_MOVK,
+   AARCH64_INSN_IMM_ADR,
+   AARCH64_INSN_IMM_26,
+   AARCH64_INSN_IMM_19,
+   AARCH64_INSN_IMM_16,
+   AARCH64_INSN_IMM_14,
+   AARCH64_INSN_IMM_12,
+   AARCH64_INSN_IMM_9,
+   AARCH64_INSN_IMM_MAX
+};
+
 #define__AARCH64_INSN_FUNCS(abbr, mask, val)   \
 static __always_inline bool aarch64_insn_is_##abbr(u32 code) \
 { return (code & (mask)) == (val); }   \
@@ -80,6 +92,8 @@ static __always_inline void aarch64_insn_write(void *addr, 
u32 insn)
 }
 
 enum aarch64_insn_encoding_class aarch64_get_insn_class(u32 insn);
+u32 aarch64_insn_encode_immediate(enum aarch64_insn_imm_type type,
+ u32 insn, u64 imm);
 bool aarch64_insn_hotpatch_safe(u32 old_insn, u32 new_insn);
 
 int aarch64_insn_patch_text_nosync(void *addrs[], u32 insns[], int cnt);
diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
index 8dd5fbe..344d23ed 100644
--- a/arch/arm64/kernel/insn.c
+++ b/arch/arm64/kernel/insn.c
@@ -147,3 +147,61 @@ int __kprobes aarch64_insn_patch_text(void *addrs[], u32 
insns[], int cnt)
 
return ret;
 }
+
+u32 aarch64_insn_encode_immediate(enum aarch64_insn_imm_type type,
+ u32 insn, u64 imm)
+{
+   u32 immlo, immhi, lomask, himask, mask;
+   int shift;
+
+   switch (type) {
+   case AARCH64_INSN_IMM_MOVK:
+   mask = BIT(16) - 1;
+   shift = 5;
+   break;
+   case AARCH64_INSN_IMM_ADR:
+   lomask = 0x3;
+   himask = 0x7;
+   immlo = imm & lomask;
+   imm >>= 2;
+   immhi = imm & himask;
+   imm = (immlo << 24) | (immhi);
+   mask = (lomask << 24) | (himask);
+   shift = 5;
+   break;
+   case AARCH64_INSN_IMM_26:
+   mask = BIT(26) - 1;
+   shift = 0;
+   break;
+   case AARCH64_INSN_IMM_19:
+   mask = BIT(19) - 1;
+   shift = 5;
+   break;
+   case AARCH64_INSN_IMM_16:
+   mask = BIT(16) - 1;
+   shift = 5;
+   break;
+   case AARCH64_INSN_IMM_14:
+   mask = BIT(14) - 1;
+   shift = 5;
+   break;
+   case AARCH64_INSN_IMM_12:
+   mask = BIT(12) - 1;
+   shift = 10;
+   break;
+   case AARCH64_INSN_IMM_9:
+   mask = BIT(9) - 1;
+   shift = 12;
+   break;
+   default:
+   pr_err("aarch64_insn_encode_immediate: unknown immediate 
encoding %d\n",
+   type);
+   return 0;
+   }
+
+   /* Update the immediate field. */
+   insn &= ~(mask << shift);
+   insn |= (imm & mask) << shift;
+
+   return insn;
+}
diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
index ca0e3d5..695a2dd 100644
--- a/arch/arm64/kernel/module.c
+++ b/arch/arm64/kernel/module.c
@@ -25,6 +25,9 @@
 #include 
 #include 
 #include 
+#include 
+
+#defineAARCH64_INSN_IMM_MOVNZ  AARCH64_INSN_IMM_MAX
 
 void *module_alloc(unsigned long size)
 {
@@ -94,25 +97,19 @@ static int reloc_data(enum aarch64_reloc_op op, void 
*place, u64 val, int len)
return 0;
 }
 
-enum aarch64_imm_type {
-   INSN_IMM_MOVNZ,
-   INSN_IMM_MOVK,
-   INSN_IMM_ADR,
-   INSN_IMM_26,
-   INSN_IMM_19,
-   INSN_IMM_16,
-   INSN_IMM_14,
-   INSN_IMM_12,
-   INSN_IMM_9,
-};
-
-static u32 encode_insn_immediate(enum aarch64_imm_type type, u32 insn, u64 imm)
+static int reloc_insn_movw(enum aarch64_reloc_op op, void *place, u64 val,
+  int lsb, enum aarch64_insn_imm_type imm_type)
 {
-   u32 immlo, immhi, lomask, himask, mask;
-   int shift;
+   u64 imm, limit = 0;
+   s64 sval;
+   u32 insn = *(u32 *)place;
+
+   sval = do_reloc(op, place, val);
+   sval >>= lsb;
+   imm = sval & 0x;
+
 
-   switch (type) {
-   case INSN_IMM_MOVNZ:
+   if (imm_type == AARCH64_INSN_IMM_MOVNZ) {
/*
 * For signed MOVW relocations, w

[PATCH v4 2/7] arm64: introduce interfaces to hotpatch kernel and module code

[Jiang Liu]

From: Jiang Liu 

Introduce three interfaces to patch kernel and module code:
aarch64_insn_patch_text_nosync():
patch code without synchronization, it's caller's responsibility
to synchronize all CPUs if needed.
aarch64_insn_patch_text_sync():
patch code and always synchronize with stop_machine()
aarch64_insn_patch_text():
patch code and synchronize with stop_machine() if needed

Signed-off-by: Jiang Liu 
Cc: Jiang Liu 
---
 arch/arm64/include/asm/insn.h | 24 +-
 arch/arm64/kernel/insn.c  | 77 +++
 2 files changed, 100 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
index 6190016..fc439b9 100644
--- a/arch/arm64/include/asm/insn.h
+++ b/arch/arm64/include/asm/insn.h
@@ -60,8 +60,30 @@ __AARCH64_INSN_FUNCS(nop,0x, 0xD503201F)
 
 #undef __AARCH64_INSN_FUNCS
 
-enum aarch64_insn_encoding_class aarch64_get_insn_class(u32 insn);
+/*
+ * In ARMv8-A, A64 instructions have a fixed length of 32 bits and are always
+ * little-endian. On the other hand, SCTLR_EL1.EE (bit 25, Exception 
Endianness)
+ * flag controls endianness for EL1 explicit data accesses and stage 1
+ * translation table walks as below:
+ * 0: little-endian
+ * 1: big-endian
+ * So need to handle endianness when patching kernel code.
+ */
+static __always_inline u32 aarch64_insn_read(void *addr)
+{
+   return le32_to_cpu(*(u32 *)addr);
+}
 
+static __always_inline void aarch64_insn_write(void *addr, u32 insn)
+{
+   *(u32 *)addr = cpu_to_le32(insn);
+}
+
+enum aarch64_insn_encoding_class aarch64_get_insn_class(u32 insn);
 bool aarch64_insn_hotpatch_safe(u32 old_insn, u32 new_insn);
 
+int aarch64_insn_patch_text_nosync(void *addrs[], u32 insns[], int cnt);
+int aarch64_insn_patch_text_sync(void *addrs[], u32 insns[], int cnt);
+int aarch64_insn_patch_text(void *addrs[], u32 insns[], int cnt);
+
 #endif /* _ASM_ARM64_INSN_H */
diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
index 1c501f3..8dd5fbe 100644
--- a/arch/arm64/kernel/insn.c
+++ b/arch/arm64/kernel/insn.c
@@ -16,6 +16,9 @@
  */
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 
 static int aarch64_insn_encoding_cls[] = {
@@ -70,3 +73,77 @@ bool __kprobes aarch64_insn_hotpatch_safe(u32 old_insn, u32 
new_insn)
return __aarch64_insn_hotpatch_safe(old_insn) &&
   __aarch64_insn_hotpatch_safe(new_insn);
 }
+
+int __kprobes aarch64_insn_patch_text_nosync(void *addrs[], u32 insns[],
+int cnt)
+{
+   int i;
+   u32 *tp;
+
+   if (cnt <= 0)
+   return -EINVAL;
+
+   for (i = 0; i < cnt; i++) {
+   tp = addrs[i];
+   /* A64 instructions must be word aligned */
+   if ((uintptr_t)tp & 0x3)
+   return -EINVAL;
+   aarch64_insn_write(tp, insns[i]);
+   flush_icache_range((uintptr_t)tp, (uintptr_t)tp + sizeof(u32));
+   }
+
+   return 0;
+}
+
+struct aarch64_insn_patch {
+   void**text_addrs;
+   u32 *new_insns;
+   int insn_cnt;
+};
+
+static int __kprobes aarch64_insn_patch_text_cb(void *arg)
+{
+   struct aarch64_insn_patch *pp = arg;
+
+   return aarch64_insn_patch_text_nosync(pp->text_addrs, pp->new_insns,
+ pp->insn_cnt);
+}
+
+int __kprobes aarch64_insn_patch_text_sync(void *addrs[], u32 insns[], int cnt)
+{
+   struct aarch64_insn_patch patch = {
+   .text_addrs = addrs,
+   .new_insns = insns,
+   .insn_cnt = cnt,
+   };
+
+   if (cnt <= 0)
+   return -EINVAL;
+
+   /*
+* Execute __aarch64_insn_patch_text() on every online CPU,
+* which ensure serialization among all online CPUs.
+*/
+   return stop_machine(aarch64_insn_patch_text_cb, &patch, NULL);
+}
+
+int __kprobes aarch64_insn_patch_text(void *addrs[], u32 insns[], int cnt)
+{
+   int ret;
+
+   if (cnt == 1 && aarch64_insn_hotpatch_safe(aarch64_insn_read(addrs[0]),
+  insns[0])) {
+   /*
+* It doesn't guarantee all CPUs see the new instruction
+* after returning from aarch64_insn_patch_text_nosync().
+* So send a IPI to all other CPUs to achieve instruction
+* synchronization.
+*/
+   ret = aarch64_insn_patch_text_nosync(addrs, insns, cnt);
+   kick_all_cpus_sync();
+   } else {
+   ret = aarch64_insn_patch_text_sync(addrs, insns, cnt);
+   }
+
+   return ret;
+}
-- 
1.8.1.2

--
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

[PATCH v4 1/7] arm64: introduce basic aarch64 instruction decoding helpers

[Jiang Liu]

From: Jiang Liu 

Introduce basic aarch64 instruction decoding helper
aarch64_get_insn_class() and aarch64_insn_hotpatch_safe().

Signed-off-by: Jiang Liu 
Cc: Jiang Liu 
---
 arch/arm64/include/asm/insn.h | 67 
 arch/arm64/kernel/Makefile|  2 +-
 arch/arm64/kernel/insn.c  | 72 +++
 3 files changed, 140 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/include/asm/insn.h
 create mode 100644 arch/arm64/kernel/insn.c

diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
new file mode 100644
index 000..6190016
--- /dev/null
+++ b/arch/arm64/include/asm/insn.h
@@ -0,0 +1,67 @@
+/*
+ * Copyright (C) 2013 Huawei Ltd.
+ * Author: Jiang Liu 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+#ifndef_ASM_ARM64_INSN_H
+#define_ASM_ARM64_INSN_H
+#include 
+
+/*
+ * ARM Architecture Reference Manual ARMv8, Section C3.1
+ * AArch64 main encoding table
+ *  Bit position
+ *   28 27 26 25   Encoding Group
+ *   0  0  -  -Unallocated
+ *   1  0  0  -Data processing, immediate
+ *   1  0  1  -Branch, exception generation and system 
instructions
+ *   -  1  -  0Loads and stores
+ *   -  1  0  1Data processing - register
+ *   0  1  1  1Data processing - SIMD and floating point
+ *   1  1  1  1Data processing - SIMD and floating point
+ * "-" means "don't care"
+ */
+enum aarch64_insn_encoding_class {
+   AARCH64_INSN_CLS_UNKNOWN,   /* UNALLOCATED */
+   AARCH64_INSN_CLS_DP_IMM,/* Data processing - immediate */
+   AARCH64_INSN_CLS_DP_REG,/* Data processing - register */
+   AARCH64_INSN_CLS_DP_FPSIMD, /* Data processing - SIMD and FP */
+   AARCH64_INSN_CLS_LDST,  /* Loads and stores */
+   AARCH64_INSN_CLS_BR_SYS,/* Branch, exception generation and
+* system instructions */
+};
+
+#define__AARCH64_INSN_FUNCS(abbr, mask, val)   \
+static __always_inline bool aarch64_insn_is_##abbr(u32 code) \
+{ return (code & (mask)) == (val); }   \
+static __always_inline u32 aarch64_insn_get_##abbr##_mask(void) \
+{ return (mask); } \
+static __always_inline u32 aarch64_insn_get_##abbr##_value(void) \
+{ return (val); }
+
+__AARCH64_INSN_FUNCS(b,0xFC00, 0x1400)
+__AARCH64_INSN_FUNCS(bl,   0xFC00, 0x9400)
+__AARCH64_INSN_FUNCS(svc,  0xFFE0001F, 0xD401)
+__AARCH64_INSN_FUNCS(hvc,  0xFFE0001F, 0xD402)
+__AARCH64_INSN_FUNCS(smc,  0xFFE0001F, 0xD403)
+__AARCH64_INSN_FUNCS(brk,  0xFFE0001F, 0xD420)
+__AARCH64_INSN_FUNCS(nop,  0x, 0xD503201F)
+
+#undef __AARCH64_INSN_FUNCS
+
+enum aarch64_insn_encoding_class aarch64_get_insn_class(u32 insn);
+
+bool aarch64_insn_hotpatch_safe(u32 old_insn, u32 new_insn);
+
+#endif /* _ASM_ARM64_INSN_H */
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 7b4b564..9af6cb3 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -9,7 +9,7 @@ AFLAGS_head.o   := -DTEXT_OFFSET=$(TEXT_OFFSET)
 arm64-obj-y:= cputable.o debug-monitors.o entry.o irq.o fpsimd.o   
\
   entry-fpsimd.o process.o ptrace.o setup.o signal.o   
\
   sys.o stacktrace.o time.o traps.o io.o vdso.o
\
-  hyp-stub.o psci.o
+  hyp-stub.o psci.o insn.o
 
 arm64-obj-$(CONFIG_COMPAT) += sys32.o kuser32.o signal32.o 
\
   sys_compat.o
diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
new file mode 100644
index 000..1c501f3
--- /dev/null
+++ b/arch/arm64/kernel/insn.c
@@ -0,0 +1,72 @@
+/*
+ * Copyright (C) 2013 Huawei Ltd.
+ * Author: Jiang Liu 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GN

[PATCH v4 0/7] Optimize jump label implementation for ARM64

[Jiang Liu]

From: Jiang Liu 

This patchset tries to optimize arch specfic jump label implementation
for ARM64 by dynamic kernel text patching.

To enable this feature, your toolchain must support "asm goto" extension
and "%c" constraint extesion. Current GCC for AARCH64 doesn't support
"%c", so you need a GCC patch similiar to this:
http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/arm/arm.c?view=patch&r1=175293&r2=175565&pathrev=175565
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48637

It has been tested on ARM Fast mode and a real hardware platform.

Any comments are welcomed!

V3->V4:
1) resolve a race condition in kernel text patching
2) address other review comments

V2->V3:
1) fix a bug in comparing signed and unsigned values
2) detect big endian by checking __AARCH64EB__

V1->V2: address review comments of V1
1) refine comments
2) add a new interface to always synchronize with stop_machine()
   when patching code
3) handle endian issue when patching code


Jiang Liu (7):
  arm64: introduce basic aarch64 instruction decoding helpers
  arm64: introduce interfaces to hotpatch kernel and module code
  arm64: move encode_insn_immediate() from module.c to insn.c
  arm64: introduce aarch64_insn_gen_{nop|branch_imm}() helper functions
  arm64, jump label: detect %c support for ARM64
  arm64, jump label: optimize jump label implementation
  jump_label: use defined macros instead of hard-coding for better
readability

 arch/arm64/Kconfig  |   1 +
 arch/arm64/include/asm/insn.h   | 110 +
 arch/arm64/include/asm/jump_label.h |  52 
 arch/arm64/kernel/Makefile  |   3 +-
 arch/arm64/kernel/insn.c| 235 
 arch/arm64/kernel/jump_label.c  |  58 +
 arch/arm64/kernel/module.c  | 152 +++
 include/linux/jump_label.h  |  15 ++-
 scripts/gcc-goto.sh |   2 +-
 9 files changed, 514 insertions(+), 114 deletions(-)
 create mode 100644 arch/arm64/include/asm/insn.h
 create mode 100644 arch/arm64/include/asm/jump_label.h
 create mode 100644 arch/arm64/kernel/insn.c
 create mode 100644 arch/arm64/kernel/jump_label.c

-- 
1.8.1.2

--
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] virtio tools: use ansi versions of asm and volatile

[Ramkumar Ramachandra]

Rusty Russell wrote:
> Ramkumar Ramachandra  writes:
>> asm and volatile are provided for backward compatibility; use the ansi
>> versions __asm__ and __volatile__.
>
> Really?  I don't see that in the gcc documentation.  In fact, I didn't
> know __volatile__ at all:

Try compiling the program with `gcc -ansi`, and you'll see that "asm"
and "volatile" are undeclared. The motivation for my patch comes from
barrier() being declared differently in compiler-gcc.h.

However, the tree is polluted with the non-ansi versions anyway;
compilers will continue to support them for decades. So, I'd request
you to drop the patch.

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: [Resend PATCH 5/5] IA64/PCI/ACPI: Rework PCI root bridge ACPI resource conversion

[Lan Tianyu]

On 2013年10月17日 07:55, Bjorn Helgaas wrote:
> On Fri, Oct 11, 2013 at 08:19:01PM +0800, tianyu@intel.com wrote:
>> From: Lan Tianyu 
>>
>> Using ACPI resource functions to convert ACPI resource to generic resource
>>
>> Signed-off-by: Lan Tianyu 
>> ---
>> This patch just passes through compilation test due to no ia64 machine on 
>> hand.
>>
>>  arch/ia64/pci/pci.c | 38 +-
>>  1 file changed, 21 insertions(+), 17 deletions(-)
>>
>> diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
>> index 2326790..14fa175 100644
>> --- a/arch/ia64/pci/pci.c
>> +++ b/arch/ia64/pci/pci.c
>> @@ -232,8 +232,9 @@ out:
>>  return ~0;
>>  }
>>  
>> -static acpi_status resource_to_window(struct acpi_resource *resource,
>> -  struct acpi_resource_address64 *addr)
>> +static acpi_status resource_to_window(struct acpi_resource *ares,
>> +  struct acpi_resource_address64 *addr,
>> +  struct resource *res)
>>  {
>>  acpi_status status;
>>  
>> @@ -244,7 +245,7 @@ static acpi_status resource_to_window(struct 
>> acpi_resource *resource,
>>   *  - producers, i.e., the address space is routed downstream,
>>   *not consumed by the bridge itself
>>   */
>> -status = acpi_resource_to_address64(resource, addr);
>> +status = acpi_dev_resource_address_space_full(ares, addr, res);
>>  if (ACPI_SUCCESS(status) &&
>>  (addr->resource_type == ACPI_MEMORY_RANGE ||
>>   addr->resource_type == ACPI_IO_RANGE) &&
>> @@ -255,51 +256,54 @@ static acpi_status resource_to_window(struct 
>> acpi_resource *resource,
>>  return AE_ERROR;
>>  }
>>  
>> -static acpi_status count_window(struct acpi_resource *resource, void *data)
>> +static acpi_status count_window(struct acpi_resource *ares, void *data)
>>  {
>>  unsigned int *windows = (unsigned int *) data;
>>  struct acpi_resource_address64 addr;
>> +struct resource res;
>>  acpi_status status;
>>  
>> -status = resource_to_window(resource, &addr);
>> +status = resource_to_window(ares, &addr, &res);
>>  if (ACPI_SUCCESS(status))
>>  (*windows)++;
>>  
>>  return AE_OK;
>>  }
>>  
>> -static acpi_status add_window(struct acpi_resource *res, void *data)
>> +static acpi_status add_window(struct acpi_resource *ares, void *data)
>>  {
>>  struct pci_root_info *info = data;
>> -struct resource *resource;
>> +struct resource *resource = &info->res[info->res_num];
>>  struct acpi_resource_address64 addr;
>>  acpi_status status;
>> -unsigned long flags, offset = 0;
>> +unsigned long offset = 0;
>>  struct resource *root;
>>  
>>  /* Return AE_OK for non-window resources to keep scanning for more */
>> -status = resource_to_window(res, &addr);
>> +status = resource_to_window(ares, &addr, resource);
>>  if (!ACPI_SUCCESS(status))
>>  return AE_OK;
>>  
>> -if (addr.resource_type == ACPI_MEMORY_RANGE) {
>> -flags = IORESOURCE_MEM;
>> +if (resource->flags & IORESOURCE_MEM) {
>>  root = &iomem_resource;
>>  offset = addr.translation_offset;
>> -} else if (addr.resource_type == ACPI_IO_RANGE) {
>> -flags = IORESOURCE_IO;
>> +} else if (resource->flags & IORESOURCE_IO) {
>>  root = &ioport_resource;
>>  offset = add_io_space(info, &addr);
>>  if (offset == ~0)
>>  return AE_OK;
>> +
>> +/*
>> + * io space address translation offset depends
>> + * on the return value of add_io_space(). So
>> + * Repopulate resource->start and end here.
> 
> "Repopulate" makes it sound like "resource->start" got clobbered
> somewhere.  But it didn't.  I think it's just that each bridge can
> support its own I/O port range, and the PCI port numbers reported
> in the acpi_resource may not be distinct, and add_io_space() adds
> an offset so all the I/O port ranges fit into one global I/O port
> space.
> 
> For example, I think these two bridges have the same port numbers
> (0x0-0xfff) in their acpi_resource, but the second has an offset
> of 0x100 in the system I/O port space, and I think this offset
> is what add_io_space() returns:
> 
>   HWP0002:00: host bridge window [io  0x-0x0fff] (PCI [0x0-0xfff])
>   HWP0002:09: host bridge window [io  0x100-0x1000fff] (PCI [0x0-0xfff])
> 
>> + */
>> +resource->start = addr.minimum + offset;
>> +resource->end = resource->start + addr.address_length - 1;
> 
> Can't we use this:
> 
>   resource->start += offset;
>   resource->end += offset;
> 
> to avoid breaking the encapsulation of struct acpi_resource_address64?

resource->start has been populated with "addr.minimum +
addr.translation_offset" in the acpi_dev_resource_address_space().
continuing to add the offset

Re: [RESEND PATCH v2 2/6] ARM: dts: Specify clocks for UARTs on bcm11351

[Sebastian Hesselbarth]

On 10/17/2013 07:41 AM, Christian Daudt wrote:

On Wed, Oct 16, 2013 at 2:47 PM, Tim Kryger  wrote:

Rather than declaring the frequency of the external clock, specify the
label of the clock such that the driver may determine the frequency on
its own.

Signed-off-by: Tim Kryger 
Reviewed-by: Markus Mayer 
Reviewed-by: Matt Porter 
---
  arch/arm/boot/dts/bcm11351.dtsi | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
index c6464fb..ce65367 100644
--- a/arch/arm/boot/dts/bcm11351.dtsi
+++ b/arch/arm/boot/dts/bcm11351.dtsi
@@ -43,7 +43,7 @@
 compatible = "brcm,bcm11351-dw-apb-uart", "snps,dw-apb-uart";
 status = "disabled";
 reg = <0x3e00 0x1000>;
-   clock-frequency = <1300>;
+   clocks = <&uartb_clk>;
 interrupts = ;
 reg-shift = <2>;
 reg-io-width = <4>;


Hi Sebastian,
  this patch series (and a subsequent one from Tim) both rely on your
"ARM: provide common arch init for DT clocks" patchset in order to
work. Will that patchset be in 3.13 ? I don't want to pull the dt mods
unless they are as they break the boot without them.


Christian,

here is the pull request [1], pull [2], and stable commitment for the
branch [3]. You can merge that branch too and name the dependency when
you send your PR, arm-soc maintainers will sort it out.

Besides a small section mismatch fixup for nomadik that Olof requested,
I guess it is in.

Sebastian

[1] http://www.spinics.net/lists/arm-kernel/msg276175.html
[2] http://www.spinics.net/lists/arm-kernel/msg277816.html
[3] http://www.spinics.net/lists/arm-kernel/msg279736.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 v3] ARM: bcm: Add DEBUG_LL console support

[Christian Daudt]

On Sat, Oct 5, 2013 at 8:43 AM, Christian Daudt  wrote:
> This patch adds low level debug uart support to Broadcom
>  mobile based SOCs.
>
> Signed-off-by: Christian Daudt 
>
> Changes from V2:
>  - Changed to follow hex ordering on entries
>  - Dropped defconfig changes
>
> Changes from V1:
>  - Switched to use the common 8250 debug introduced in 3.12-rc1
>

Hi Russell,
 Does V3 look ok ?

 Thanks,
   csd
--
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] sound: pci: emu10k1: code refactoring and casting removal

[Takashi Iwai]

At Wed, 16 Oct 2013 19:11:21 -0300,
Geyslan G. Bem wrote:
> 
> Partially restructures _snd_emu10k1_audigy_init_efx() and
> _snd_emu10k1_init_efx() functions.
> 
> Removes useless casting (void *) from value returned by kcalloc;
> see Documentation/CodingStyle, Chap 14.
> 
> Signed-off-by: Geyslan G. Bem 
> ---
>  sound/pci/emu10k1/emufx.c | 84 
> ++-
>  1 file changed, 46 insertions(+), 38 deletions(-)
> 
> diff --git a/sound/pci/emu10k1/emufx.c b/sound/pci/emu10k1/emufx.c
> index 0275209..afd4691 100644
> --- a/sound/pci/emu10k1/emufx.c
> +++ b/sound/pci/emu10k1/emufx.c
> @@ -1182,15 +1182,20 @@ static int _snd_emu10k1_audigy_init_efx(struct 
> snd_emu10k1 *emu)
>   u32 *gpr_map;
>   mm_segment_t seg;
>  
> - if ((icode = kzalloc(sizeof(*icode), GFP_KERNEL)) == NULL ||
> - (icode->gpr_map = (u_int32_t __user *)
> -  kcalloc(512 + 256 + 256 + 2 * 1024, sizeof(u_int32_t),
> -  GFP_KERNEL)) == NULL ||
> - (controls = kcalloc(SND_EMU10K1_GPR_CONTROLS,
> - sizeof(*controls), GFP_KERNEL)) == NULL) {
> - err = -ENOMEM;
> - goto __err;
> - }
> + err = -ENOMEM;
> + icode = kzalloc(sizeof(*icode), GFP_KERNEL);
> + if (!icode)
> + return err;
> +
> + icode->gpr_map = (__user) kcalloc(512 + 256 + 256 + 2 * 1024,
> +   sizeof(u_int32_t), GFP_KERNEL);
> + if (!icode->gpr_map)
> + goto __err_gpr;
> + controls = kcalloc(SND_EMU10K1_GPR_CONTROLS,
> +sizeof(*controls), GFP_KERNEL);
> + if (!controls)
> + goto __err_ctrls;
> +
>   gpr_map = (u32 __force *)icode->gpr_map;
>  
>   icode->tram_data_map = icode->gpr_map + 512;
> @@ -1741,12 +1746,12 @@ A_OP(icode, &ptr, iMAC0, A_GPR(var), A_GPR(var), 
> A_GPR(vol), A_EXTIN(input))
>   emu->support_tlv = 0; /* clear again */
>   snd_leave_user(seg);
>  
> - __err:
> +__err:
>   kfree(controls);
> - if (icode != NULL) {
> - kfree((void __force *)icode->gpr_map);
> - kfree(icode);
> - }
> +__err_ctrls:
> + kfree((void __force *)icode->gpr_map);
> +__err_gpr:
> + kfree(icode);
>   return err;
>  }
>  
> @@ -1813,18 +1818,26 @@ static int _snd_emu10k1_init_efx(struct snd_emu10k1 
> *emu)
>   u32 *gpr_map;
>   mm_segment_t seg;
>  
> - if ((icode = kzalloc(sizeof(*icode), GFP_KERNEL)) == NULL)
> - return -ENOMEM;
> - if ((icode->gpr_map = (u_int32_t __user *)
> -  kcalloc(256 + 160 + 160 + 2 * 512, sizeof(u_int32_t),
> -  GFP_KERNEL)) == NULL ||
> -(controls = kcalloc(SND_EMU10K1_GPR_CONTROLS,
> - sizeof(struct snd_emu10k1_fx8010_control_gpr),
> - GFP_KERNEL)) == NULL ||
> - (ipcm = kzalloc(sizeof(*ipcm), GFP_KERNEL)) == NULL) {
> - err = -ENOMEM;
> - goto __err;
> - }
> + err = -ENOMEM;
> + icode = kzalloc(sizeof(*icode), GFP_KERNEL);
> + if (!icode)
> + return err;
> +
> + icode->gpr_map = (__user) kcalloc(256 + 160 + 160 + 2 * 512,
> +   sizeof(u_int32_t), GFP_KERNEL);
> + if (!icode->gpr_map)
> + goto __err_gpr;
> +
> + controls = kcalloc(SND_EMU10K1_GPR_CONTROLS,
> +sizeof(struct snd_emu10k1_fx8010_control_gpr),
> +GFP_KERNEL);
> + if (!controls)
> + goto __err_ctrls;
> +
> + ipcm = kzalloc(sizeof(*ipcm), GFP_KERNEL);
> + if (!ipcm)
> + goto __err_ipcm;
> +
>   gpr_map = (u32 __force *)icode->gpr_map;
>  
>   icode->tram_data_map = icode->gpr_map + 256;
> @@ -2335,14 +2348,8 @@ static int _snd_emu10k1_init_efx(struct snd_emu10k1 
> *emu)
>   for (z = 0; z < 16; z++)
>   OP(icode, &ptr, iACC3, FXBUS2(z), C_, 
> C_, EXTIN(z));
>   }
> - 
>  
> - if (gpr > tmp) {
> - snd_BUG();
> - err = -EIO;
> - goto __err;
> - }
> - if (i > SND_EMU10K1_GPR_CONTROLS) {
> + if (gpr > tmp || i > SND_EMU10K1_GPR_CONTROLS) {
>   snd_BUG();

In that way, you can't distinguish which condition triggered the bug
(it could be shown in WARN() called in snd_BUG() in the original
version), so this is a functional change.  Avoid it in a clean up
patch.


thanks,

Takashi
--
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 v2 2/5] slab: introduce helper functions to get/set free object

[Joonsoo Kim]

In the following patches, to get/set free objects from the freelist
is changed so that simple casting doesn't work for it. Therefore,
introduce helper functions.

Acked-by: Christoph Lameter 
Signed-off-by: Joonsoo Kim 

diff --git a/mm/slab.c b/mm/slab.c
index cb0a734..ec197b9 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -2556,9 +2556,15 @@ static struct freelist *alloc_slabmgmt(struct kmem_cache 
*cachep,
return freelist;
 }
 
-static inline unsigned int *slab_freelist(struct page *page)
+static inline unsigned int get_free_obj(struct page *page, unsigned int idx)
 {
-   return (unsigned int *)(page->freelist);
+   return ((unsigned int *)page->freelist)[idx];
+}
+
+static inline void set_free_obj(struct page *page,
+   unsigned int idx, unsigned int val)
+{
+   ((unsigned int *)(page->freelist))[idx] = val;
 }
 
 static void cache_init_objs(struct kmem_cache *cachep,
@@ -2603,7 +2609,7 @@ static void cache_init_objs(struct kmem_cache *cachep,
if (cachep->ctor)
cachep->ctor(objp);
 #endif
-   slab_freelist(page)[i] = i;
+   set_free_obj(page, i, i);
}
 }
 
@@ -2622,7 +2628,7 @@ static void *slab_get_obj(struct kmem_cache *cachep, 
struct page *page,
 {
void *objp;
 
-   objp = index_to_obj(cachep, page, slab_freelist(page)[page->active]);
+   objp = index_to_obj(cachep, page, get_free_obj(page, page->active));
page->active++;
 #if DEBUG
WARN_ON(page_to_nid(virt_to_page(objp)) != nodeid);
@@ -2643,7 +2649,7 @@ static void slab_put_obj(struct kmem_cache *cachep, 
struct page *page,
 
/* Verify double free bug */
for (i = page->active; i < cachep->num; i++) {
-   if (slab_freelist(page)[i] == objnr) {
+   if (get_free_obj(page, i) == objnr) {
printk(KERN_ERR "slab: double free detected in cache "
"'%s', objp %p\n", cachep->name, objp);
BUG();
@@ -2651,7 +2657,7 @@ static void slab_put_obj(struct kmem_cache *cachep, 
struct page *page,
}
 #endif
page->active--;
-   slab_freelist(page)[page->active] = objnr;
+   set_free_obj(page, page->active, objnr);
 }
 
 /*
@@ -4224,7 +4230,7 @@ static void handle_slab(unsigned long *n, struct 
kmem_cache *c,
 
for (j = page->active; j < c->num; j++) {
/* Skip freed item */
-   if (slab_freelist(page)[j] == i) {
+   if (get_free_obj(page, j) == i) {
active = false;
break;
}
-- 
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 3/4] ARM: pinctrl: Add Broadcom Capri pinctrl driver

[Christian Daudt]

On Thu, Oct 3, 2013 at 5:23 PM, Sherman Yin  wrote:
> Adds pinctrl driver for Broadcom Capri (BCM281xx) SoCs.
>
> Signed-off-by: Sherman Yin 
> Reviewed-by: Christian Daudt 
> Reviewed-by: Matt Porter 
> ---
>  arch/arm/mach-bcm/Kconfig   |2 +
>  drivers/pinctrl/Kconfig |   10 +
>  drivers/pinctrl/Makefile|1 +
>  drivers/pinctrl/pinctrl-capri.c | 1727 
> +++
>  4 files changed, 1740 insertions(+)
>  create mode 100644 drivers/pinctrl/pinctrl-capri.c
>
> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> index 69d67f7..2546365 100644
> --- a/arch/arm/mach-bcm/Kconfig
> +++ b/arch/arm/mach-bcm/Kconfig
> @@ -10,6 +10,8 @@ config ARCH_BCM
> select GENERIC_CLOCKEVENTS
> select GENERIC_TIME
> select GPIO_BCM
> +   select PINCTRL
> +   select PINCTRL_CAPRI
> select SPARSE_IRQ
> select TICK_ONESHOT
> select CACHE_L2X0

On your subsequent patchset pls move this from Kconfig to
arm/configs/bcm_defconfig, and break that modification into a separate
patch from the drivers/* modification.

 thanks,
   csd
--
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 v2 3/5] slab: restrict the number of objects in a slab

[Joonsoo Kim]

To prepare to implement byte sized index for managing the freelist
of a slab, we should restrict the number of objects in a slab to be less
or equal to 256, since byte only represent 256 different values.
Setting the size of object to value equal or more than newly introduced
SLAB_MIN_SIZE ensures that the number of objects in a slab is less or
equal to 256 for a slab with 1 page.

Signed-off-by: Joonsoo Kim 

diff --git a/mm/slab.c b/mm/slab.c
index ec197b9..3cee122 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -157,6 +157,10 @@
 #define ARCH_KMALLOC_FLAGS SLAB_HWCACHE_ALIGN
 #endif
 
+/* We use byte sized index to manage the freelist of a slab */
+#define NR_PER_BYTE (1 << BITS_PER_BYTE)
+#define SLAB_MIN_SIZE (PAGE_SIZE >> BITS_PER_BYTE)
+
 /*
  * true if a page was allocated from pfmemalloc reserves for network-based
  * swap
@@ -2016,6 +2020,10 @@ static size_t calculate_slab_order(struct kmem_cache 
*cachep,
if (!num)
continue;
 
+   /* We can't handler number of objects more than NR_PER_BYTE */
+   if (num > NR_PER_BYTE)
+   break;
+
if (flags & CFLGS_OFF_SLAB) {
/*
 * Max number of objs-per-slab for caches which
@@ -2258,6 +2266,12 @@ __kmem_cache_create (struct kmem_cache *cachep, unsigned 
long flags)
flags |= CFLGS_OFF_SLAB;
 
size = ALIGN(size, cachep->align);
+   /*
+* We want to restrict the number of objects in a slab to be equal or
+* less than 256 in order to manage freelist via byte sized indexes.
+*/
+   if (size < SLAB_MIN_SIZE)
+   size = ALIGN(SLAB_MIN_SIZE, cachep->align);
 
left_over = calculate_slab_order(cachep, size, cachep->align, flags);
 
-- 
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/

[PATCH v2 0/5] slab: implement byte sized indexes for the freelist of a slab

[Joonsoo Kim]

This patchset implements byte sized indexes for the freelist of a slab.

Currently, the freelist of a slab consist of unsigned int sized indexes.
Most of slabs have less number of objects than 256, so much space is wasted.
To reduce this overhead, this patchset implements byte sized indexes for
the freelist of a slab. With it, we can save 3 bytes for each objects.

Below is some numbers of 'cat /proc/slabinfo'.

* Before *
kmalloc-512  52564051281 : tunables   54   270 : 
slabdata 80 80  0
kmalloc-256  210210256   151 : tunables  120   600 : 
slabdata 14 14  0
kmalloc-192 1016   1040192   201 : tunables  120   600 : 
slabdata 52 52  0
kmalloc-96   560620128   311 : tunables  120   600 : 
slabdata 20 20  0
kmalloc-64  2148   2280 64   601 : tunables  120   600 : 
slabdata 38 38  0
kmalloc-128  647682128   311 : tunables  120   600 : 
slabdata 22 22  0
kmalloc-32 11360  11413 32  1131 : tunables  120   600 : 
slabdata101101  0
kmem_cache   197200192   201 : tunables  120   600 : 
slabdata 10 10  0

* After *
kmalloc-512  52164851281 : tunables   54   270 : 
slabdata 81 81  0
kmalloc-256  208208256   161 : tunables  120   600 : 
slabdata 13 13  0
kmalloc-192 1029   1029192   211 : tunables  120   600 : 
slabdata 49 49  0
kmalloc-96   529589128   311 : tunables  120   600 : 
slabdata 19 19  0
kmalloc-64  2142   2142 64   631 : tunables  120   600 : 
slabdata 34 34  0
kmalloc-128  660682128   311 : tunables  120   600 : 
slabdata 22 22  0
kmalloc-32 11716  11780 32  1241 : tunables  120   600 : 
slabdata 95 95  0
kmem_cache   197210192   211 : tunables  120   600 : 
slabdata 10 10  0

kmem_caches consisting of objects less than or equal to 256 byte have
one or more objects than before. In the case of kmalloc-32, we have 11 more
objects, so 352 bytes (11 * 32) are saved and this is roughly 9% saving of
memory. Of couse, this percentage decreases as the number of objects
in a slab decreases.

Here are the performance results on my 4 cpus machine.

* Before *

 Performance counter stats for 'perf bench sched messaging -g 50 -l 1000' (10 
runs):

   229,945,138 cache-misses 
 ( +-  0.23% )

  11.627897174 seconds time elapsed 
 ( +-  0.14% )

* After *

 Performance counter stats for 'perf bench sched messaging -g 50 -l 1000' (10 
runs):

   218,640,472 cache-misses 
 ( +-  0.42% )

  11.504999837 seconds time elapsed 
 ( +-  0.21% )

cache-misses are reduced by this patchset, roughly 5%.
And elapsed times are improved by 1%.

This patchset comes from a Christoph's idea.
https://lkml.org/lkml/2013/8/23/315

Patches are on top of my previous posting named as
"slab: overload struct slab over struct page to reduce memory usage"
https://lkml.org/lkml/2013/10/16/155

Thanks.

Joonsoo Kim (5):
  slab: factor out calculate nr objects in cache_estimate
  slab: introduce helper functions to get/set free object
  slab: restrict the number of objects in a slab
  slab: introduce byte sized index for the freelist of a slab
  slab: make more slab management structure off the slab

 mm/slab.c |   90 +++--
 1 file changed, 58 insertions(+), 32 deletions(-)

-- 
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/

[PATCH v2 5/5] slab: make more slab management structure off the slab

[Joonsoo Kim]

Now, the size of the freelist for the slab management diminish,
so that the on-slab management structure can waste large space
if the object of the slab is large.

Consider a 128 byte sized slab. If on-slab is used, 31 objects can be
in the slab. The size of the freelist for this case would be 31 bytes
so that 97 bytes, that is, more than 75% of object size, are wasted.

In a 64 byte sized slab case, no space is wasted if we use on-slab.
So set off-slab determining constraint to 128 bytes.

Acked-by: Christoph Lameter 
Signed-off-by: Joonsoo Kim 

diff --git a/mm/slab.c b/mm/slab.c
index 2f379ba..19ae154 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -2257,7 +2257,7 @@ __kmem_cache_create (struct kmem_cache *cachep, unsigned 
long flags)
 * it too early on. Always use on-slab management when
 * SLAB_NOLEAKTRACE to avoid recursive calls into kmemleak)
 */
-   if ((size >= (PAGE_SIZE >> 3)) && !slab_early_init &&
+   if ((size >= (PAGE_SIZE >> 5)) && !slab_early_init &&
!(flags & SLAB_NOLEAKTRACE))
/*
 * Size is large, assume best to place the slab management obj
-- 
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/

[PATCH v2 4/5] slab: introduce byte sized index for the freelist of a slab

[Joonsoo Kim]

Currently, the freelist of a slab consist of unsigned int sized indexes.
Since most of slabs have less number of objects than 256, large sized
indexes is waste. For example, consider the minimum kmalloc slab. It's
object size is 32 byte and it would consist of one page, so 256 indexes
through byte sized index are enough to contain all possible indexes.

There can be some slabs whose object size is 8 byte. We cannot handle
this case with byte sized index, so we need to restrict minimum
object size. Since these slabs are not major, wasted memory from these
slabs would be negligible.

Below is some number for this patch.

* Before *
kmalloc-512  52564051281 : tunables   54   270 : 
slabdata 80 80  0
kmalloc-256  210210256   151 : tunables  120   600 : 
slabdata 14 14  0
kmalloc-192 1016   1040192   201 : tunables  120   600 : 
slabdata 52 52  0
kmalloc-96   560620128   311 : tunables  120   600 : 
slabdata 20 20  0
kmalloc-64  2148   2280 64   601 : tunables  120   600 : 
slabdata 38 38  0
kmalloc-128  647682128   311 : tunables  120   600 : 
slabdata 22 22  0
kmalloc-32 11360  11413 32  1131 : tunables  120   600 : 
slabdata101101  0
kmem_cache   197200192   201 : tunables  120   600 : 
slabdata 10 10  0

* After *
kmalloc-512  52164851281 : tunables   54   270 : 
slabdata 81 81  0
kmalloc-256  208208256   161 : tunables  120   600 : 
slabdata 13 13  0
kmalloc-192 1029   1029192   211 : tunables  120   600 : 
slabdata 49 49  0
kmalloc-96   529589128   311 : tunables  120   600 : 
slabdata 19 19  0
kmalloc-64  2142   2142 64   631 : tunables  120   600 : 
slabdata 34 34  0
kmalloc-128  660682128   311 : tunables  120   600 : 
slabdata 22 22  0
kmalloc-32 11716  11780 32  1241 : tunables  120   600 : 
slabdata 95 95  0
kmem_cache   197210192   211 : tunables  120   600 : 
slabdata 10 10  0

kmem_caches consisting of objects less than or equal to 256 byte have
one or more objects than before. In the case of kmalloc-32, we have 11 more
objects, so 352 bytes (11 * 32) are saved and this is roughly 9% saving of
memory. Of couse, this percentage decreases as the number of objects
in a slab decreases.

Here are the performance results on my 4 cpus machine.

* Before *

 Performance counter stats for 'perf bench sched messaging -g 50 -l 1000' (10 
runs):

   229,945,138 cache-misses 
 ( +-  0.23% )

  11.627897174 seconds time elapsed 
 ( +-  0.14% )

* After *

 Performance counter stats for 'perf bench sched messaging -g 50 -l 1000' (10 
runs):

   218,640,472 cache-misses 
 ( +-  0.42% )

  11.504999837 seconds time elapsed 
 ( +-  0.21% )

cache-misses are reduced by this patchset, roughly 5%.
And elapsed times are improved by 1%.

Signed-off-by: Joonsoo Kim 

diff --git a/mm/slab.c b/mm/slab.c
index 3cee122..2f379ba 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -627,8 +627,8 @@ static void cache_estimate(unsigned long gfporder, size_t 
buffer_size,
 
} else {
nr_objs = calculate_nr_objs(slab_size, buffer_size,
-   sizeof(unsigned int), align);
-   mgmt_size = ALIGN(nr_objs * sizeof(unsigned int), align);
+   sizeof(unsigned char), align);
+   mgmt_size = ALIGN(nr_objs * sizeof(unsigned char), align);
}
*num = nr_objs;
*left_over = slab_size - nr_objs*buffer_size - mgmt_size;
@@ -2031,7 +2031,7 @@ static size_t calculate_slab_order(struct kmem_cache 
*cachep,
 * looping condition in cache_grow().
 */
offslab_limit = size;
-   offslab_limit /= sizeof(unsigned int);
+   offslab_limit /= sizeof(unsigned char);
 
if (num > offslab_limit)
break;
@@ -2279,7 +2279,7 @@ __kmem_cache_create (struct kmem_cache *cachep, unsigned 
long flags)
return -E2BIG;
 
freelist_size =
-   ALIGN(cachep->num * sizeof(unsigned int), cachep->align);
+   ALIGN(cachep->num * sizeof(unsigned char), cachep->align);
 
/*
 * If the slab has been placed off-slab, and we have enough space then
@@ -2292,7 +2292,7 @@ __kmem_cache_create (struct k

[PATCH v2 1/5] slab: factor out calculate nr objects in cache_estimate

[Joonsoo Kim]

This logic is not simple to understand so that making separate function
helping readability. Additionally, we can use this change in the
following patch which implement for freelist to have another sized index
in according to nr objects.

Signed-off-by: Joonsoo Kim 

diff --git a/mm/slab.c b/mm/slab.c
index af2db76..cb0a734 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -565,9 +565,31 @@ static inline struct array_cache *cpu_cache_get(struct 
kmem_cache *cachep)
return cachep->array[smp_processor_id()];
 }
 
-static size_t slab_mgmt_size(size_t nr_objs, size_t align)
+static int calculate_nr_objs(size_t slab_size, size_t buffer_size,
+   size_t idx_size, size_t align)
 {
-   return ALIGN(nr_objs * sizeof(unsigned int), align);
+   int nr_objs;
+   size_t freelist_size;
+
+   /*
+* Ignore padding for the initial guess. The padding
+* is at most @align-1 bytes, and @buffer_size is at
+* least @align. In the worst case, this result will
+* be one greater than the number of objects that fit
+* into the memory allocation when taking the padding
+* into account.
+*/
+   nr_objs = slab_size / (buffer_size + idx_size);
+
+   /*
+* This calculated number will be either the right
+* amount, or one greater than what we want.
+*/
+   freelist_size = slab_size - nr_objs * buffer_size;
+   if (freelist_size < ALIGN(nr_objs * idx_size, align))
+   nr_objs--;
+
+   return nr_objs;
 }
 
 /*
@@ -600,25 +622,9 @@ static void cache_estimate(unsigned long gfporder, size_t 
buffer_size,
nr_objs = slab_size / buffer_size;
 
} else {
-   /*
-* Ignore padding for the initial guess. The padding
-* is at most @align-1 bytes, and @buffer_size is at
-* least @align. In the worst case, this result will
-* be one greater than the number of objects that fit
-* into the memory allocation when taking the padding
-* into account.
-*/
-   nr_objs = (slab_size) / (buffer_size + sizeof(unsigned int));
-
-   /*
-* This calculated number will be either the right
-* amount, or one greater than what we want.
-*/
-   if (slab_mgmt_size(nr_objs, align) + nr_objs*buffer_size
-  > slab_size)
-   nr_objs--;
-
-   mgmt_size = slab_mgmt_size(nr_objs, align);
+   nr_objs = calculate_nr_objs(slab_size, buffer_size,
+   sizeof(unsigned int), align);
+   mgmt_size = ALIGN(nr_objs * sizeof(unsigned int), align);
}
*num = nr_objs;
*left_over = slab_size - nr_objs*buffer_size - mgmt_size;
-- 
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 v2 00/15] slab: overload struct slab over struct page to reduce memory usage

[Joonsoo Kim]

On Wed, Oct 16, 2013 at 01:34:57PM -0700, Andrew Morton wrote:
> On Wed, 16 Oct 2013 17:43:57 +0900 Joonsoo Kim  wrote:
> 
> > There is two main topics in this patchset. One is to reduce memory usage
> > and the other is to change a management method of free objects of a slab.
> > 
> > The SLAB allocate a struct slab for each slab. The size of this structure
> > except bufctl array is 40 bytes on 64 bits machine. We can reduce memory
> > waste and cache footprint if we overload struct slab over struct page.
> 
> Seems a good idea from a quick look.

Thanks :)

> 
> A thought: when we do things like this - adding additional
> interpretations to `struct page', we need to bear in mind that other
> unrelated code can inspect that pageframe.  It is not correct to assume
> that because slab "owns" this page, no other code will be looking at it
> and interpreting its contents.
> 
> One example is mm/memory-failure.c:memory_failure().  It starts with a
> raw pfn, uses that to get at the `struct page', then starts playing
> around with it.  Will that code still work correctly when some of the
> page's fields have been overlayed with slab-specific contents?

Yes, it would work correctly since the SLUB already overload many fields
of struct page with slab-specific contents. One exception is mapping field
which isn't overloaded by the SLUB. But I guess there is no problem,
because the code inspecting random struct page may be already check
PageSlab() or PageLRU() and then skip it if so.

> 
> And memory_failure() is just one example - another is compact_zone()
> and there may well be others.
> 
> This issue hasn't been well thought through.  Given a random struct
> page, there isn't any protocol to determine what it actually *is*. 
> It's a plain old variant record, but it lacks the agreed-upon tag field
> which tells users which variant is currently in use.

With PageSlab(), we can determine that this page is the slab page.
Do we need more? Is there another user who overload struct page?

Thanks.

> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org 
--
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 v11 3/3] DMA: Freescale: update driver to support 8-channel DMA engine

[Hongbo Zhang]

Hi Vinod,
I have gotten ACK from Mark for both the 1/3 and 2/3 patches.
Thanks.


On 09/26/2013 05:33 PM, hongbo.zh...@freescale.com wrote:

From: Hongbo Zhang 

This patch adds support to 8-channel DMA engine, thus the driver works for both
the new 8-channel and the legacy 4-channel DMA engines.

Signed-off-by: Hongbo Zhang 
---
  drivers/dma/Kconfig  |9 +
  drivers/dma/fsldma.c |9 ++---
  drivers/dma/fsldma.h |2 +-
  3 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 6825957..3979c65 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -89,14 +89,15 @@ config AT_HDMAC
  Support the Atmel AHB DMA controller.
  
  config FSL_DMA

-   tristate "Freescale Elo and Elo Plus DMA support"
+   tristate "Freescale Elo series DMA support"
depends on FSL_SOC
select DMA_ENGINE
select ASYNC_TX_ENABLE_CHANNEL_SWITCH
---help---
- Enable support for the Freescale Elo and Elo Plus DMA controllers.
- The Elo is the DMA controller on some 82xx and 83xx parts, and the
- Elo Plus is the DMA controller on 85xx and 86xx parts.
+ Enable support for the Freescale Elo series DMA controllers.
+ The Elo is the DMA controller on some mpc82xx and mpc83xx parts, the
+ EloPlus is on mpc85xx and mpc86xx and Pxxx parts, and the Elo3 is on
+ some Txxx and Bxxx parts.
  
  config MPC512X_DMA

tristate "Freescale MPC512x built-in DMA engine support"
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 49e8fbd..16a9a48 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1261,7 +1261,9 @@ static int fsl_dma_chan_probe(struct fsldma_device *fdev,
WARN_ON(fdev->feature != chan->feature);
  
  	chan->dev = fdev->dev;

-   chan->id = ((res.start - 0x100) & 0xfff) >> 7;
+   chan->id = (res.start & 0xfff) < 0x300 ?
+  ((res.start - 0x100) & 0xfff) >> 7 :
+  ((res.start - 0x200) & 0xfff) >> 7;
if (chan->id >= FSL_DMA_MAX_CHANS_PER_DEVICE) {
dev_err(fdev->dev, "too many channels for device\n");
err = -EINVAL;
@@ -1434,6 +1436,7 @@ static int fsldma_of_remove(struct platform_device *op)
  }
  
  static const struct of_device_id fsldma_of_ids[] = {

+   { .compatible = "fsl,elo3-dma", },
{ .compatible = "fsl,eloplus-dma", },
{ .compatible = "fsl,elo-dma", },
{}
@@ -1455,7 +1458,7 @@ static struct platform_driver fsldma_of_driver = {
  
  static __init int fsldma_init(void)

  {
-   pr_info("Freescale Elo / Elo Plus DMA driver\n");
+   pr_info("Freescale Elo series DMA driver\n");
return platform_driver_register(&fsldma_of_driver);
  }
  
@@ -1467,5 +1470,5 @@ static void __exit fsldma_exit(void)

  subsys_initcall(fsldma_init);
  module_exit(fsldma_exit);
  
-MODULE_DESCRIPTION("Freescale Elo / Elo Plus DMA driver");

+MODULE_DESCRIPTION("Freescale Elo series DMA driver");
  MODULE_LICENSE("GPL");
diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
index f5c3879..1ffc244 100644
--- a/drivers/dma/fsldma.h
+++ b/drivers/dma/fsldma.h
@@ -112,7 +112,7 @@ struct fsldma_chan_regs {
  };
  
  struct fsldma_chan;

-#define FSL_DMA_MAX_CHANS_PER_DEVICE 4
+#define FSL_DMA_MAX_CHANS_PER_DEVICE 8
  
  struct fsldma_device {

void __iomem *regs; /* DGSR register base */




--
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] efivars,efi-pstore: Hold off deletion of sysfs entry until, the scan is completed

[Madper Xie]

Howdy Seiji,
  I failed appily this patch to both 3.12-rc2 and 3.12-rc4. Could you
  please let me know which is the right tree for this patch?

  Thanks,
  Madper.
seiji.agu...@hds.com writes:

> Change from v2:
> - Move dynamic memory allocation to efi_pstore_read() before holding
>   efivars->lock to protect entry->var.Data.
> - Access to entry->scanning while holding efivars->lock.
> - Move a comment about a returned value from efi_pstore_read_func() to
>   efi_pstore_read() because "size < 0" case may happen in efi_pstore_read().
>
> Currently, when mounting pstore file system, a read callback of efi_pstore
> driver runs mutiple times as below.
>
> - In the first read callback, scan efivar_sysfs_list from head and pass
>   a kmsg buffer of a entry to an upper pstore layer.
> - In the second read callback, rescan efivar_sysfs_list from the entry and 
> pass
>   another kmsg buffer to it.
> - Repeat the scan and pass until the end of efivar_sysfs_list.
>
> In this process, an entry is read across the multiple read function calls.
> To avoid race between the read and erasion, the whole process above is
> protected by a spinlock, holding in open() and releasing in close().
>
> At the same time, kmemdup() is called to pass the buffer to pstore filesystem
> during it.
> And then, it causes a following lockdep warning.
>
> To make the dynamic memory allocation runnable without taking spinlock,
> holding off a deletion of sysfs entry if it happens while scanning it
> via efi_pstore, and deleting it after the scan is completed.
>
> To implement it, this patch introduces two flags, scanning and deleting,
> to efivar_entry.
>
> [1.143710] [ cut here ]
> [1.144058] WARNING: CPU: 1 PID: 1 at kernel/lockdep.c:2740
> lockdep_trace_alloc+0x104/0x110()
> [1.144058] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
> [1.144058] Modules linked in:
>
> [1.144058] CPU: 1 PID: 1 Comm: systemd Not tainted 3.11.0-rc5 #2
> [1.144058]  0009 8800797e9ae0 816614a5
> 8800797e9b28
> [1.144058]  8800797e9b18 8105510d 0080
> 0046
> [1.144058]  00d0 03af 81ccd0c0
> 8800797e9b78
> [1.144058] Call Trace:
> [1.144058]  [] dump_stack+0x54/0x74
> [1.144058]  [] warn_slowpath_common+0x7d/0xa0
> [1.144058]  [] warn_slowpath_fmt+0x4c/0x50
> [1.144058]  [] ? vsscanf+0x57f/0x7b0
> [1.144058]  [] lockdep_trace_alloc+0x104/0x110
> [1.144058]  [] __kmalloc_track_caller+0x50/0x280
> [1.144058]  [] ?
> efi_pstore_read_func.part.1+0x12b/0x170
> [1.144058]  [] kmemdup+0x20/0x50
> [1.144058]  [] efi_pstore_read_func.part.1+0x12b/0x170
> [1.144058]  [] ?
> efi_pstore_read_func.part.1+0x170/0x170
> [1.144058]  [] efi_pstore_read_func+0xb4/0xe0
> [1.144058]  [] __efivar_entry_iter+0xfb/0x120
> [1.144058]  [] efi_pstore_read+0x3f/0x50
> [1.144058]  [] pstore_get_records+0x9a/0x150
> [1.158207]  [] ? selinux_d_instantiate+0x1c/0x20
> [1.158207]  [] ? parse_options+0x80/0x80
> [1.158207]  [] pstore_fill_super+0xa5/0xc0
> [1.158207]  [] mount_single+0xa2/0xd0
> [1.158207]  [] pstore_mount+0x18/0x20
> [1.158207]  [] mount_fs+0x39/0x1b0
> [1.158207]  [] ? __alloc_percpu+0x10/0x20
> [1.158207]  [] vfs_kern_mount+0x63/0xf0
> [1.158207]  [] do_mount+0x23e/0xa20
> [1.158207]  [] ? strndup_user+0x4b/0xf0
> [1.158207]  [] SyS_mount+0x83/0xc0
> [1.158207]  [] system_call_fastpath+0x16/0x1b
> [1.158207] ---[ end trace 61981bc62de9f6f4 ]---
>
> Signed-off-by: Seiji Aguchi 
> ---
>  drivers/firmware/efi/efi-pstore.c | 143 
> +++---
>  drivers/firmware/efi/efivars.c|  12 ++--
>  drivers/firmware/efi/vars.c   |  12 +++-
>  include/linux/efi.h   |   2 +
>  4 files changed, 153 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/firmware/efi/efi-pstore.c 
> b/drivers/firmware/efi/efi-pstore.c
> index 5002d50..ebd5dbc 100644
> --- a/drivers/firmware/efi/efi-pstore.c
> +++ b/drivers/firmware/efi/efi-pstore.c
> @@ -18,14 +18,12 @@ module_param_named(pstore_disable, 
> efivars_pstore_disable, bool, 0644);
>  
>  static int efi_pstore_open(struct pstore_info *psi)
>  {
> - efivar_entry_iter_begin();
>   psi->data = NULL;
>   return 0;
>  }
>  
>  static int efi_pstore_close(struct pstore_info *psi)
>  {
> - efivar_entry_iter_end();
>   psi->data = NULL;
>   return 0;
>  }
> @@ -91,19 +89,125 @@ static int efi_pstore_read_func(struct efivar_entry 
> *entry, void *data)
>   __efivar_entry_get(entry, &entry->var.Attributes,
>  &entry->var.DataSize, entry->var.Data);
>   size = entry->var.DataSize;
> + memcpy(*cb_data->buf, entry->var.Data, (size_t)min_t(unsigned long,
> +  1024, size));
>  
> - *cb_data->buf = kmemdup(entry->var.Data, size, GFP_KER

Re: [PATCH] ARM: bcm_defconfig: Run "make savedefconfig"

[Christian Daudt]

On Mon, Oct 14, 2013 at 2:41 PM, Tim Kryger  wrote:
> Several of the options in bcm_defconfig have gotten out of date so
> regenerate it with "make savedefconfig" to keep things fresh.
>
> Signed-off-by: Tim Kryger 
> Reviewed-by: Matt Porter 
> ---
>  arch/arm/configs/bcm_defconfig | 10 ++
>  1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/configs/bcm_defconfig b/arch/arm/configs/bcm_defconfig
> index efb0132..3a138af 100644
> --- a/arch/arm/configs/bcm_defconfig
> +++ b/arch/arm/configs/bcm_defconfig
> @@ -1,4 +1,3 @@
> -CONFIG_EXPERIMENTAL=y
>  # CONFIG_LOCALVERSION_AUTO is not set
>  # CONFIG_SWAP is not set
>  CONFIG_SYSVIPC=y
> @@ -25,11 +24,8 @@ CONFIG_MODULES=y
>  CONFIG_MODULE_UNLOAD=y
>  # CONFIG_BLK_DEV_BSG is not set
>  CONFIG_PARTITION_ADVANCED=y
> -CONFIG_EFI_PARTITION=y
>  CONFIG_ARCH_BCM=y
> -CONFIG_ARCH_BCM_MOBILE=y
>  CONFIG_ARM_THUMBEE=y
> -CONFIG_ARM_ERRATA_743622=y
>  CONFIG_PREEMPT=y
>  CONFIG_AEABI=y
>  # CONFIG_OABI_COMPAT is not set
> @@ -51,7 +47,6 @@ CONFIG_UNIX_DIAG=y
>  CONFIG_NET_KEY=y
>  CONFIG_INET=y
>  CONFIG_IP_MULTICAST=y
> -CONFIG_ARPD=y
>  CONFIG_SYN_COOKIES=y
>  CONFIG_TCP_MD5SIG=y
>  CONFIG_IPV6=y
> @@ -96,7 +91,6 @@ CONFIG_MMC_UNSAFE_RESUME=y
>  CONFIG_MMC_BLOCK_MINORS=32
>  CONFIG_MMC_TEST=y
>  CONFIG_MMC_SDHCI=y
> -CONFIG_MMC_SDHCI_PLTFM=y
>  CONFIG_MMC_SDHCI_BCM_KONA=y
>  CONFIG_NEW_LEDS=y
>  CONFIG_LEDS_CLASS=y
> @@ -118,12 +112,12 @@ CONFIG_CONFIGFS_FS=y
>  CONFIG_NLS_CODEPAGE_437=y
>  CONFIG_NLS_ISO8859_1=y
>  CONFIG_PRINTK_TIME=y
> -CONFIG_MAGIC_SYSRQ=y
> +CONFIG_DEBUG_INFO=y
>  CONFIG_DEBUG_FS=y
> +CONFIG_MAGIC_SYSRQ=y
>  CONFIG_DETECT_HUNG_TASK=y
>  CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=110
>  CONFIG_BOOTPARAM_HUNG_TASK_PANIC=y
> -CONFIG_DEBUG_INFO=y
>  # CONFIG_FTRACE is not set
>  CONFIG_CRC_CCITT=y
>  CONFIG_CRC_T10DIF=y
> --

Reviewed-by: Christian Daudt 
Applied to armsoc/for-3.13/soc
 thanks,
   csd
--
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: [RESEND PATCH v2 2/6] ARM: dts: Specify clocks for UARTs on bcm11351

[Christian Daudt]

On Wed, Oct 16, 2013 at 2:47 PM, Tim Kryger  wrote:
> Rather than declaring the frequency of the external clock, specify the
> label of the clock such that the driver may determine the frequency on
> its own.
>
> Signed-off-by: Tim Kryger 
> Reviewed-by: Markus Mayer 
> Reviewed-by: Matt Porter 
> ---
>  arch/arm/boot/dts/bcm11351.dtsi | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
> index c6464fb..ce65367 100644
> --- a/arch/arm/boot/dts/bcm11351.dtsi
> +++ b/arch/arm/boot/dts/bcm11351.dtsi
> @@ -43,7 +43,7 @@
> compatible = "brcm,bcm11351-dw-apb-uart", "snps,dw-apb-uart";
> status = "disabled";
> reg = <0x3e00 0x1000>;
> -   clock-frequency = <1300>;
> +   clocks = <&uartb_clk>;
> interrupts = ;
> reg-shift = <2>;
> reg-io-width = <4>;

Hi Sebastian,
 this patch series (and a subsequent one from Tim) both rely on your
"ARM: provide common arch init for DT clocks" patchset in order to
work. Will that patchset be in 3.13 ? I don't want to pull the dt mods
unless they are as they break the boot without them.

 Thanks,
   csd
--
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 net-next v3 2/9] ipv6: split inet6_ehashfn to hash functions per compilation unit

[Hannes Frederic Sowa]

This patch splits the inet6_ehashfn into separate ones in
ipv6/inet6_hashtables.o and ipv6/udp.o to ease the introduction of
seperate secrets keys later.

Cc: Eric Dumazet 
Cc: "David S. Miller" 
Signed-off-by: Hannes Frederic Sowa 
---
 include/net/inet6_hashtables.h | 28 +++-
 include/net/ipv6.h |  4 ++--
 net/ipv6/inet6_hashtables.c| 24 
 net/ipv6/udp.c | 20 
 4 files changed, 49 insertions(+), 27 deletions(-)

diff --git a/include/net/inet6_hashtables.h b/include/net/inet6_hashtables.h
index a105d1a..ae06135 100644
--- a/include/net/inet6_hashtables.h
+++ b/include/net/inet6_hashtables.h
@@ -28,28 +28,14 @@
 
 struct inet_hashinfo;
 
-static inline unsigned int inet6_ehashfn(struct net *net,
-   const struct in6_addr *laddr, const u16 lport,
-   const struct in6_addr *faddr, const __be16 
fport)
+static inline unsigned int __inet6_ehashfn(const u32 lhash,
+   const u16 lport,
+   const u32 fhash,
+   const __be16 fport,
+   const u32 initval)
 {
-   u32 ports = (((u32)lport) << 16) | (__force u32)fport;
-
-   return jhash_3words((__force u32)laddr->s6_addr32[3],
-   ipv6_addr_jhash(faddr),
-   ports,
-   inet_ehash_secret + net_hash_mix(net));
-}
-
-static inline int inet6_sk_ehashfn(const struct sock *sk)
-{
-   const struct inet_sock *inet = inet_sk(sk);
-   const struct in6_addr *laddr = &sk->sk_v6_rcv_saddr;
-   const struct in6_addr *faddr = &sk->sk_v6_daddr;
-   const __u16 lport = inet->inet_num;
-   const __be16 fport = inet->inet_dport;
-   struct net *net = sock_net(sk);
-
-   return inet6_ehashfn(net, laddr, lport, faddr, fport);
+   const u32 ports = (((u32)lport) << 16) | (__force u32)fport;
+   return jhash_3words(lhash, fhash, ports, initval);
 }
 
 int __inet6_hash(struct sock *sk, struct inet_timewait_sock *twp);
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index fe1c7f6..a35055f 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -539,14 +539,14 @@ static inline u32 ipv6_addr_hash(const struct in6_addr *a)
 }
 
 /* more secured version of ipv6_addr_hash() */
-static inline u32 ipv6_addr_jhash(const struct in6_addr *a)
+static inline u32 __ipv6_addr_jhash(const struct in6_addr *a, const u32 
initval)
 {
u32 v = (__force u32)a->s6_addr32[0] ^ (__force u32)a->s6_addr32[1];
 
return jhash_3words(v,
(__force u32)a->s6_addr32[2],
(__force u32)a->s6_addr32[3],
-   ipv6_hash_secret);
+   initval);
 }
 
 static inline bool ipv6_addr_loopback(const struct in6_addr *a)
diff --git a/net/ipv6/inet6_hashtables.c b/net/ipv6/inet6_hashtables.c
index 842d833..fa7dd38 100644
--- a/net/ipv6/inet6_hashtables.c
+++ b/net/ipv6/inet6_hashtables.c
@@ -23,6 +23,30 @@
 #include 
 #include 
 
+static unsigned int inet6_ehashfn(struct net *net,
+ const struct in6_addr *laddr,
+ const u16 lport,
+ const struct in6_addr *faddr,
+ const __be16 fport)
+{
+   const u32 lhash = (__force u32)laddr->s6_addr32[3];
+   const u32 fhash = __ipv6_addr_jhash(faddr, ipv6_hash_secret);
+   return __inet6_ehashfn(lhash, lport, fhash, fport,
+  inet_ehash_secret + net_hash_mix(net));
+}
+
+static int inet6_sk_ehashfn(const struct sock *sk)
+{
+   const struct inet_sock *inet = inet_sk(sk);
+   const struct in6_addr *laddr = &sk->sk_v6_rcv_saddr;
+   const struct in6_addr *faddr = &sk->sk_v6_daddr;
+   const __u16 lport = inet->inet_num;
+   const __be16 fport = inet->inet_dport;
+   struct net *net = sock_net(sk);
+
+   return inet6_ehashfn(net, laddr, lport, faddr, fport);
+}
+
 int __inet6_hash(struct sock *sk, struct inet_timewait_sock *tw)
 {
struct inet_hashinfo *hashinfo = sk->sk_prot->h.hashinfo;
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index b496de1..324bd36 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -53,6 +53,18 @@
 #include 
 #include "udp_impl.h"
 
+static unsigned int udp6_ehashfn(struct net *net,
+ const struct in6_addr *laddr,
+ const u16 lport,
+ const struct in6_addr *faddr,
+ const __be16 fport)
+{
+   const u32 lhash = (__force u32)laddr->s6_addr32[3];
+   const u32 fhash = __ipv6_addr_jhash(faddr, ipv6_hash_secret);
+   return __inet6_ehashfn(lhash, lport, fhash, fport,
+  inet_ehash_secret + net_hash_mix(ne

[PATCH net-next v3 3/9] static_key: WARN on usage before jump_label_init was called

[Hannes Frederic Sowa]

Based on a patch from Andi Kleen.

Cc: Steven Rostedt 
Cc: Peter Zijlstra 
Cc: Andi Kleen 
Signed-off-by: Hannes Frederic Sowa 
---
 include/linux/jump_label.h   | 10 ++
 include/linux/jump_label_ratelimit.h |  2 ++
 init/main.c  |  7 +++
 kernel/jump_label.c  |  5 +
 4 files changed, 24 insertions(+)

diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index a507907..e96be72 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -48,6 +48,13 @@
 
 #include 
 #include 
+#include 
+
+extern bool static_key_initialized;
+
+#define STATIC_KEY_CHECK_USE() WARN(!static_key_initialized, \
+   "%s used before call to jump_label_init", \
+   __func__)
 
 #if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
 
@@ -128,6 +135,7 @@ struct static_key {
 
 static __always_inline void jump_label_init(void)
 {
+   static_key_initialized = true;
 }
 
 static __always_inline bool static_key_false(struct static_key *key)
@@ -146,11 +154,13 @@ static __always_inline bool static_key_true(struct 
static_key *key)
 
 static inline void static_key_slow_inc(struct static_key *key)
 {
+   STATIC_KEY_CHECK_USE();
atomic_inc(&key->enabled);
 }
 
 static inline void static_key_slow_dec(struct static_key *key)
 {
+   STATIC_KEY_CHECK_USE();
atomic_dec(&key->enabled);
 }
 
diff --git a/include/linux/jump_label_ratelimit.h 
b/include/linux/jump_label_ratelimit.h
index 1137883..089f70f 100644
--- a/include/linux/jump_label_ratelimit.h
+++ b/include/linux/jump_label_ratelimit.h
@@ -23,12 +23,14 @@ struct static_key_deferred {
 };
 static inline void static_key_slow_dec_deferred(struct static_key_deferred 
*key)
 {
+   STATIC_KEY_CHECK_USE();
static_key_slow_dec(&key->key);
 }
 static inline void
 jump_label_rate_limit(struct static_key_deferred *key,
unsigned long rl)
 {
+   STATIC_KEY_CHECK_USE();
 }
 #endif /* HAVE_JUMP_LABEL */
 #endif /* _LINUX_JUMP_LABEL_RATELIMIT_H */
diff --git a/init/main.c b/init/main.c
index af310af..27bbec1a 100644
--- a/init/main.c
+++ b/init/main.c
@@ -136,6 +136,13 @@ static char *execute_command;
 static char *ramdisk_execute_command;
 
 /*
+ * Used to generate warnings if static_key manipulation functions are used
+ * before jump_label_init is called.
+ */
+bool static_key_initialized __read_mostly = false;
+EXPORT_SYMBOL_GPL(static_key_initialized);
+
+/*
  * If set, this is an indication to the drivers that reset the underlying
  * device before going ahead with the initialization otherwise driver might
  * rely on the BIOS and skip the reset operation.
diff --git a/kernel/jump_label.c b/kernel/jump_label.c
index 297a924..9019f15 100644
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -58,6 +58,7 @@ static void jump_label_update(struct static_key *key, int 
enable);
 
 void static_key_slow_inc(struct static_key *key)
 {
+   STATIC_KEY_CHECK_USE();
if (atomic_inc_not_zero(&key->enabled))
return;
 
@@ -103,12 +104,14 @@ static void jump_label_update_timeout(struct work_struct 
*work)
 
 void static_key_slow_dec(struct static_key *key)
 {
+   STATIC_KEY_CHECK_USE();
__static_key_slow_dec(key, 0, NULL);
 }
 EXPORT_SYMBOL_GPL(static_key_slow_dec);
 
 void static_key_slow_dec_deferred(struct static_key_deferred *key)
 {
+   STATIC_KEY_CHECK_USE();
__static_key_slow_dec(&key->key, key->timeout, &key->work);
 }
 EXPORT_SYMBOL_GPL(static_key_slow_dec_deferred);
@@ -116,6 +119,7 @@ EXPORT_SYMBOL_GPL(static_key_slow_dec_deferred);
 void jump_label_rate_limit(struct static_key_deferred *key,
unsigned long rl)
 {
+   STATIC_KEY_CHECK_USE();
key->timeout = rl;
INIT_DELAYED_WORK(&key->work, jump_label_update_timeout);
 }
@@ -212,6 +216,7 @@ void __init jump_label_init(void)
key->next = NULL;
 #endif
}
+   static_key_initialized = true;
jump_label_unlock();
 }
 
-- 
1.8.3.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 net-next v3 4/9] x86/jump_label: expect default_nop if static_key gets enabled on boot-up

[Hannes Frederic Sowa]

net_get_random_once(intrduced in the next patch) uses static_keys in
a way that they get enabled on boot-up instead of replaced with an
ideal_nop. So check for default_nop on initial enabling.

Other architectures don't check for this.

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Steven Rostedt 
Cc: Jason Baron 
Cc: Peter Zijlstra 
Cc: Eric Dumazet 
Cc: "David S. Miller" 
Cc: x...@kernel.org
Signed-off-by: Hannes Frederic Sowa 
---
 arch/x86/kernel/jump_label.c | 25 ++---
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/jump_label.c b/arch/x86/kernel/jump_label.c
index ee11b7d..26d5a55 100644
--- a/arch/x86/kernel/jump_label.c
+++ b/arch/x86/kernel/jump_label.c
@@ -42,15 +42,27 @@ static void __jump_label_transform(struct jump_entry *entry,
   int init)
 {
union jump_code_union code;
+   const unsigned char default_nop[] = { STATIC_KEY_INIT_NOP };
const unsigned char *ideal_nop = ideal_nops[NOP_ATOMIC5];
 
if (type == JUMP_LABEL_ENABLE) {
-   /*
-* We are enabling this jump label. If it is not a nop
-* then something must have gone wrong.
-*/
-   if (unlikely(memcmp((void *)entry->code, ideal_nop, 5) != 0))
-   bug_at((void *)entry->code, __LINE__);
+   if (init) {
+   /*
+* Jump label is enabled for the first time.
+* So we expect a default_nop...
+*/
+   if (unlikely(memcmp((void *)entry->code, default_nop, 5)
+!= 0))
+   bug_at((void *)entry->code, __LINE__);
+   } else {
+   /*
+* ...otherwise expect an ideal_nop. Otherwise
+* something went horribly wrong.
+*/
+   if (unlikely(memcmp((void *)entry->code, ideal_nop, 5)
+!= 0))
+   bug_at((void *)entry->code, __LINE__);
+   }
 
code.jump = 0xe9;
code.offset = entry->target -
@@ -63,7 +75,6 @@ static void __jump_label_transform(struct jump_entry *entry,
 * are converting the default nop to the ideal nop.
 */
if (init) {
-   const unsigned char default_nop[] = { 
STATIC_KEY_INIT_NOP };
if (unlikely(memcmp((void *)entry->code, default_nop, 
5) != 0))
bug_at((void *)entry->code, __LINE__);
} else {
-- 
1.8.3.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 net-next v3 9/9] net: switch net_secret key generation to net_get_random_once

[Hannes Frederic Sowa]

Cc: Eric Dumazet 
Cc: "David S. Miller" 
Signed-off-by: Hannes Frederic Sowa 
---
 net/core/secure_seq.c | 14 ++
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/net/core/secure_seq.c b/net/core/secure_seq.c
index 3f1ec15..b02fd16 100644
--- a/net/core/secure_seq.c
+++ b/net/core/secure_seq.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -16,18 +17,7 @@ static u32 net_secret[NET_SECRET_SIZE] cacheline_aligned;
 
 static void net_secret_init(void)
 {
-   u32 tmp;
-   int i;
-
-   if (likely(net_secret[0]))
-   return;
-
-   for (i = NET_SECRET_SIZE; i > 0;) {
-   do {
-   get_random_bytes(&tmp, sizeof(tmp));
-   } while (!tmp);
-   cmpxchg(&net_secret[--i], 0, tmp);
-   }
+   net_get_random_once(net_secret, sizeof(net_secret));
 }
 
 #ifdef CONFIG_INET
-- 
1.8.3.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 net-next v3 6/9] inet: split syncookie keys for ipv4 and ipv6 and initialize with net_get_random_once

[Hannes Frederic Sowa]

This patch splits the secret key for syncookies for ipv4 and ipv6 and
initializes them with net_get_random_once. This change was the reason I
did this series. I think the initialization of the syncookie_secret is
way to early.

Cc: Florian Westphal 
Cc: Eric Dumazet 
Cc: "David S. Miller" 
Signed-off-by: Hannes Frederic Sowa 
---
 include/net/tcp.h |  1 -
 net/ipv4/syncookies.c | 15 +--
 net/ipv6/syncookies.c | 12 +---
 3 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/include/net/tcp.h b/include/net/tcp.h
index 1db3a01..0fa8fdc 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -475,7 +475,6 @@ int tcp_send_rcvq(struct sock *sk, struct msghdr *msg, 
size_t size);
 void inet_sk_rx_dst_set(struct sock *sk, const struct sk_buff *skb);
 
 /* From syncookies.c */
-extern __u32 syncookie_secret[2][16-4+SHA_DIGEST_WORDS];
 int __cookie_v4_check(const struct iphdr *iph, const struct tcphdr *th,
  u32 cookie);
 struct sock *cookie_v4_check(struct sock *sk, struct sk_buff *skb,
diff --git a/net/ipv4/syncookies.c b/net/ipv4/syncookies.c
index 3b64c59..b95331e 100644
--- a/net/ipv4/syncookies.c
+++ b/net/ipv4/syncookies.c
@@ -25,15 +25,7 @@
 
 extern int sysctl_tcp_syncookies;
 
-__u32 syncookie_secret[2][16-4+SHA_DIGEST_WORDS];
-EXPORT_SYMBOL(syncookie_secret);
-
-static __init int init_syncookies(void)
-{
-   get_random_bytes(syncookie_secret, sizeof(syncookie_secret));
-   return 0;
-}
-__initcall(init_syncookies);
+static u32 syncookie_secret[2][16-4+SHA_DIGEST_WORDS];
 
 #define COOKIEBITS 24  /* Upper bits store count */
 #define COOKIEMASK (((__u32)1 << COOKIEBITS) - 1)
@@ -44,8 +36,11 @@ static DEFINE_PER_CPU(__u32 [16 + 5 + SHA_WORKSPACE_WORDS],
 static u32 cookie_hash(__be32 saddr, __be32 daddr, __be16 sport, __be16 dport,
   u32 count, int c)
 {
-   __u32 *tmp = __get_cpu_var(ipv4_cookie_scratch);
+   __u32 *tmp;
+
+   net_get_random_once(syncookie_secret, sizeof(syncookie_secret));
 
+   tmp  = __get_cpu_var(ipv4_cookie_scratch);
memcpy(tmp + 4, syncookie_secret[c], sizeof(syncookie_secret[c]));
tmp[0] = (__force u32)saddr;
tmp[1] = (__force u32)daddr;
diff --git a/net/ipv6/syncookies.c b/net/ipv6/syncookies.c
index d04d3f1..535a3ad 100644
--- a/net/ipv6/syncookies.c
+++ b/net/ipv6/syncookies.c
@@ -24,6 +24,8 @@
 #define COOKIEBITS 24  /* Upper bits store count */
 #define COOKIEMASK (((__u32)1 << COOKIEBITS) - 1)
 
+static u32 syncookie6_secret[2][16-4+SHA_DIGEST_WORDS];
+
 /* RFC 2460, Section 8.3:
  * [ipv6 tcp] MSS must be computed as the maximum packet size minus 60 [..]
  *
@@ -61,14 +63,18 @@ static DEFINE_PER_CPU(__u32 [16 + 5 + SHA_WORKSPACE_WORDS],
 static u32 cookie_hash(const struct in6_addr *saddr, const struct in6_addr 
*daddr,
   __be16 sport, __be16 dport, u32 count, int c)
 {
-   __u32 *tmp = __get_cpu_var(ipv6_cookie_scratch);
+   __u32 *tmp;
+
+   net_get_random_once(syncookie6_secret, sizeof(syncookie6_secret));
+
+   tmp  = __get_cpu_var(ipv6_cookie_scratch);
 
/*
 * we have 320 bits of information to hash, copy in the remaining
-* 192 bits required for sha_transform, from the syncookie_secret
+* 192 bits required for sha_transform, from the syncookie6_secret
 * and overwrite the digest with the secret
 */
-   memcpy(tmp + 10, syncookie_secret[c], 44);
+   memcpy(tmp + 10, syncookie6_secret[c], 44);
memcpy(tmp, saddr, 16);
memcpy(tmp + 4, daddr, 16);
tmp[8] = ((__force u32)sport << 16) + (__force u32)dport;
-- 
1.8.3.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 net-next v3 0/9] Introduce support to lazy initialize mostly static keys

[Hannes Frederic Sowa]

Hi!

This series implements support for delaying the initialization of secret
keys, e.g. used for hashing, for as long as possible. This functionality
is implemented by a new macro, net_get_random_bytes.

I already used it to protect the socket hashes, the syncookie secret
(most important) and the tcp_fastopen secrets.

Changelog:
v2) Use static_keys in net_get_random_once to have as minimal impact to
the fast-path as possible.
v3) added patch "static_key: WARN on usage before jump_label_init was called":
Patch "x86/jump_label: expect default_nop if static_key gets enabled
on boot-up" relaxes the checks for using static_key primitives before
jump_label_init. So tighten them first.

Included patches:
 ipv4: split inet_ehashfn to hash functions per compilation unit
 ipv6: split inet6_ehashfn to hash functions per compilation unit
 static_key: WARN on usage before jump_label_init was called
 x86/jump_label: expect default_nop if static_key gets enabled on boot-up
 net: introduce new macro net_get_random_once
 inet: split syncookie keys for ipv4 and ipv6 and initialize with 
net_get_random_once
 inet: convert inet_ehash_secret and ipv6_hash_secret to net_get_random_once
 tcp: switch tcp_fastopen key generation to net_get_random_once
 net: switch net_secret key generation to net_get_random_once

Diffstat:
 arch/x86/kernel/jump_label.c | 25 ++---
 include/linux/jump_label.h   | 10 ++
 include/linux/jump_label_ratelimit.h |  2 ++
 include/linux/net.h  | 25 +
 include/net/inet6_hashtables.h   | 28 +++-
 include/net/inet_sock.h  | 26 ++
 include/net/ipv6.h   |  4 ++--
 include/net/tcp.h|  3 +--
 init/main.c  |  7 +++
 kernel/jump_label.c  |  5 +
 net/core/secure_seq.c| 14 ++
 net/core/utils.c | 48 

 net/ipv4/af_inet.c   | 27 ---
 net/ipv4/inet_hashtables.c   | 25 +
 net/ipv4/syncookies.c| 15 +--
 net/ipv4/sysctl_net_ipv4.c   |  5 +
 net/ipv4/tcp_fastopen.c  | 27 ---
 net/ipv4/udp.c   | 20 
 net/ipv6/af_inet6.c  |  5 -
 net/ipv6/inet6_hashtables.c  | 33 +
 net/ipv6/syncookies.c| 12 +---
 net/ipv6/udp.c   | 31 +++
 net/rds/connection.c | 12 +---
 23 files changed, 278 insertions(+), 131 deletions(-)

Greetings,

  Hannes

--
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 net-next v3 1/9] ipv4: split inet_ehashfn to hash functions per compilation unit

[Hannes Frederic Sowa]

This duplicates a bit of code but let's us easily introduce
separate secret keys later. The separate compilation units are
ipv4/inet_hashtabbles.o, ipv4/udp.o and rds/connection.o.

Cc: Eric Dumazet 
Cc: "David S. Miller" 
Signed-off-by: Hannes Frederic Sowa 
---
 include/net/inet_sock.h| 22 ++
 net/ipv4/inet_hashtables.c | 21 +
 net/ipv4/udp.c | 16 
 net/rds/connection.c   |  6 +++---
 4 files changed, 42 insertions(+), 23 deletions(-)

diff --git a/include/net/inet_sock.h b/include/net/inet_sock.h
index 06da91e..7a6c7f8 100644
--- a/include/net/inet_sock.h
+++ b/include/net/inet_sock.h
@@ -208,26 +208,16 @@ extern u32 inet_ehash_secret;
 extern u32 ipv6_hash_secret;
 void build_ehash_secret(void);
 
-static inline unsigned int inet_ehashfn(struct net *net,
-   const __be32 laddr, const __u16 lport,
-   const __be32 faddr, const __be16 fport)
+static inline unsigned int __inet_ehashfn(const __be32 laddr,
+ const __u16 lport,
+ const __be32 faddr,
+ const __be16 fport,
+ u32 initval)
 {
return jhash_3words((__force __u32) laddr,
(__force __u32) faddr,
((__u32) lport) << 16 | (__force __u32)fport,
-   inet_ehash_secret + net_hash_mix(net));
-}
-
-static inline int inet_sk_ehashfn(const struct sock *sk)
-{
-   const struct inet_sock *inet = inet_sk(sk);
-   const __be32 laddr = inet->inet_rcv_saddr;
-   const __u16 lport = inet->inet_num;
-   const __be32 faddr = inet->inet_daddr;
-   const __be16 fport = inet->inet_dport;
-   struct net *net = sock_net(sk);
-
-   return inet_ehashfn(net, laddr, lport, faddr, fport);
+   initval);
 }
 
 static inline struct request_sock *inet_reqsk_alloc(struct request_sock_ops 
*ops)
diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c
index a4b66bb..18aa668 100644
--- a/net/ipv4/inet_hashtables.c
+++ b/net/ipv4/inet_hashtables.c
@@ -24,6 +24,27 @@
 #include 
 #include 
 
+static unsigned int inet_ehashfn(struct net *net, const __be32 laddr,
+const __u16 lport, const __be32 faddr,
+const __be16 fport)
+{
+   return __inet_ehashfn(laddr, lport, faddr, fport,
+ inet_ehash_secret + net_hash_mix(net));
+}
+
+
+static unsigned int inet_sk_ehashfn(const struct sock *sk)
+{
+   const struct inet_sock *inet = inet_sk(sk);
+   const __be32 laddr = inet->inet_rcv_saddr;
+   const __u16 lport = inet->inet_num;
+   const __be32 faddr = inet->inet_daddr;
+   const __be16 fport = inet->inet_dport;
+   struct net *net = sock_net(sk);
+
+   return inet_ehashfn(net, laddr, lport, faddr, fport);
+}
+
 /*
  * Allocate and initialize a new local port bind bucket.
  * The bindhash mutex for snum's hash chain must be held here.
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 9f27bb8..b4437c7 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -407,6 +407,14 @@ static inline int compute_score2(struct sock *sk, struct 
net *net,
return score;
 }
 
+static unsigned int udp_ehashfn(struct net *net, const __be32 laddr,
+const __u16 lport, const __be32 faddr,
+const __be16 fport)
+{
+   return __inet_ehashfn(laddr, lport, faddr, fport,
+ inet_ehash_secret + net_hash_mix(net));
+}
+
 
 /* called with read_rcu_lock() */
 static struct sock *udp4_lib_lookup2(struct net *net,
@@ -430,8 +438,8 @@ begin:
badness = score;
reuseport = sk->sk_reuseport;
if (reuseport) {
-   hash = inet_ehashfn(net, daddr, hnum,
-   saddr, sport);
+   hash = udp_ehashfn(net, daddr, hnum,
+  saddr, sport);
matches = 1;
}
} else if (score == badness && reuseport) {
@@ -511,8 +519,8 @@ begin:
badness = score;
reuseport = sk->sk_reuseport;
if (reuseport) {
-   hash = inet_ehashfn(net, daddr, hnum,
-   saddr, sport);
+   hash = udp_ehashfn(net, daddr, hnum,
+  saddr, sport);
matches = 1;
}
} else if (score == badness && reuseport) {
diff --git a/net/rds/connection.c b/ne

[PATCH net-next v3 8/9] tcp: switch tcp_fastopen key generation to net_get_random_once

[Hannes Frederic Sowa]

Changed key initialization of tcp_fastopen cookies to net_get_random_once.

If the user sets a custom key net_get_random_once must be called at
least once to ensure we don't overwrite the user provided key when the
first cookie is generated later on.

Cc: Yuchung Cheng 
Cc: Eric Dumazet 
Cc: "David S. Miller" 
Signed-off-by: Hannes Frederic Sowa 
---
 include/net/tcp.h  |  2 +-
 net/ipv4/sysctl_net_ipv4.c |  5 +
 net/ipv4/tcp_fastopen.c| 27 ---
 3 files changed, 22 insertions(+), 12 deletions(-)

diff --git a/include/net/tcp.h b/include/net/tcp.h
index 0fa8fdc..027b663 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1322,7 +1322,7 @@ extern struct tcp_fastopen_context __rcu 
*tcp_fastopen_ctx;
 int tcp_fastopen_reset_cipher(void *key, unsigned int len);
 void tcp_fastopen_cookie_gen(__be32 src, __be32 dst,
 struct tcp_fastopen_cookie *foc);
-
+void tcp_fastopen_init_key_once(bool publish);
 #define TCP_FASTOPEN_KEY_LENGTH 16
 
 /* Fastopen key context */
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index c08f096..4b161d5 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -274,6 +274,11 @@ static int proc_tcp_fastopen_key(struct ctl_table *ctl, 
int write,
ret = -EINVAL;
goto bad_key;
}
+   /* Generate a dummy secret but don't publish it. This
+* is needed so we don't regenerate a new key on the
+* first invocation of tcp_fastopen_cookie_gen
+*/
+   tcp_fastopen_init_key_once(false);
tcp_fastopen_reset_cipher(user_key, TCP_FASTOPEN_KEY_LENGTH);
}
 
diff --git a/net/ipv4/tcp_fastopen.c b/net/ipv4/tcp_fastopen.c
index ab7bd35..766032b 100644
--- a/net/ipv4/tcp_fastopen.c
+++ b/net/ipv4/tcp_fastopen.c
@@ -14,6 +14,20 @@ struct tcp_fastopen_context __rcu *tcp_fastopen_ctx;
 
 static DEFINE_SPINLOCK(tcp_fastopen_ctx_lock);
 
+void tcp_fastopen_init_key_once(bool publish)
+{
+   static u8 key[TCP_FASTOPEN_KEY_LENGTH];
+
+   /* tcp_fastopen_reset_cipher publishes the new context
+* atomically, so we allow this race happening here.
+*
+* All call sites of tcp_fastopen_cookie_gen also check
+* for a valid cookie, so this is an acceptable risk.
+*/
+   if (net_get_random_once(key, sizeof(key)) && publish)
+   tcp_fastopen_reset_cipher(key, sizeof(key));
+}
+
 static void tcp_fastopen_ctx_free(struct rcu_head *head)
 {
struct tcp_fastopen_context *ctx =
@@ -70,6 +84,8 @@ void tcp_fastopen_cookie_gen(__be32 src, __be32 dst,
__be32 path[4] = { src, dst, 0, 0 };
struct tcp_fastopen_context *ctx;
 
+   tcp_fastopen_init_key_once(true);
+
rcu_read_lock();
ctx = rcu_dereference(tcp_fastopen_ctx);
if (ctx) {
@@ -78,14 +94,3 @@ void tcp_fastopen_cookie_gen(__be32 src, __be32 dst,
}
rcu_read_unlock();
 }
-
-static int __init tcp_fastopen_init(void)
-{
-   __u8 key[TCP_FASTOPEN_KEY_LENGTH];
-
-   get_random_bytes(key, sizeof(key));
-   tcp_fastopen_reset_cipher(key, sizeof(key));
-   return 0;
-}
-
-late_initcall(tcp_fastopen_init);
-- 
1.8.3.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 net-next v3 7/9] inet: convert inet_ehash_secret and ipv6_hash_secret to net_get_random_once

[Hannes Frederic Sowa]

Initialize the ehash and ipv6_hash_secrets with net_get_random_once.

Each compilation unit gets its own secret now:
  ipv4/inet_hashtables.o
  ipv4/udp.o
  ipv6/inet6_hashtables.o
  ipv6/udp.o
  rds/connection.o

The functions still get inlined into the hashing functions. In the fast
path we have at most two (needed in ipv6) if (unlikely(...)).

Cc: Eric Dumazet 
Cc: "David S. Miller" 
Signed-off-by: Hannes Frederic Sowa 
---
 include/net/inet_sock.h |  4 
 net/ipv4/af_inet.c  | 27 ---
 net/ipv4/inet_hashtables.c  |  4 
 net/ipv4/udp.c  |  6 +-
 net/ipv6/af_inet6.c |  5 -
 net/ipv6/inet6_hashtables.c | 15 ---
 net/ipv6/udp.c  | 17 ++---
 net/rds/connection.c| 12 +---
 8 files changed, 44 insertions(+), 46 deletions(-)

diff --git a/include/net/inet_sock.h b/include/net/inet_sock.h
index 7a6c7f8..1833c3f 100644
--- a/include/net/inet_sock.h
+++ b/include/net/inet_sock.h
@@ -204,10 +204,6 @@ static inline void inet_sk_copy_descendant(struct sock 
*sk_to,
 
 int inet_sk_rebuild_header(struct sock *sk);
 
-extern u32 inet_ehash_secret;
-extern u32 ipv6_hash_secret;
-void build_ehash_secret(void);
-
 static inline unsigned int __inet_ehashfn(const __be32 laddr,
  const __u16 lport,
  const __be32 faddr,
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 35913fb..b6bdd82 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -245,29 +245,6 @@ out:
 }
 EXPORT_SYMBOL(inet_listen);
 
-u32 inet_ehash_secret __read_mostly;
-EXPORT_SYMBOL(inet_ehash_secret);
-
-u32 ipv6_hash_secret __read_mostly;
-EXPORT_SYMBOL(ipv6_hash_secret);
-
-/*
- * inet_ehash_secret must be set exactly once, and to a non nul value
- * ipv6_hash_secret must be set exactly once.
- */
-void build_ehash_secret(void)
-{
-   u32 rnd;
-
-   do {
-   get_random_bytes(&rnd, sizeof(rnd));
-   } while (rnd == 0);
-
-   if (cmpxchg(&inet_ehash_secret, 0, rnd) == 0)
-   get_random_bytes(&ipv6_hash_secret, sizeof(ipv6_hash_secret));
-}
-EXPORT_SYMBOL(build_ehash_secret);
-
 /*
  * Create an inet socket.
  */
@@ -284,10 +261,6 @@ static int inet_create(struct net *net, struct socket 
*sock, int protocol,
int try_loading_module = 0;
int err;
 
-   if (unlikely(!inet_ehash_secret))
-   if (sock->type != SOCK_RAW && sock->type != SOCK_DGRAM)
-   build_ehash_secret();
-
sock->state = SS_UNCONNECTED;
 
/* Look for the requested type/protocol pair. */
diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c
index 18aa668..8b9cf27 100644
--- a/net/ipv4/inet_hashtables.c
+++ b/net/ipv4/inet_hashtables.c
@@ -28,6 +28,10 @@ static unsigned int inet_ehashfn(struct net *net, const 
__be32 laddr,
 const __u16 lport, const __be32 faddr,
 const __be16 fport)
 {
+   static u32 inet_ehash_secret __read_mostly;
+
+   net_get_random_once(&inet_ehash_secret, sizeof(inet_ehash_secret));
+
return __inet_ehashfn(laddr, lport, faddr, fport,
  inet_ehash_secret + net_hash_mix(net));
 }
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index b4437c7..89909dd 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -411,8 +411,12 @@ static unsigned int udp_ehashfn(struct net *net, const 
__be32 laddr,
 const __u16 lport, const __be32 faddr,
 const __be16 fport)
 {
+   static u32 udp_ehash_secret __read_mostly;
+
+   net_get_random_once(&udp_ehash_secret, sizeof(udp_ehash_secret));
+
return __inet_ehashfn(laddr, lport, faddr, fport,
- inet_ehash_secret + net_hash_mix(net));
+ udp_ehash_secret + net_hash_mix(net));
 }
 
 
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index a2cb07c..20af1fb 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -110,11 +110,6 @@ static int inet6_create(struct net *net, struct socket 
*sock, int protocol,
int try_loading_module = 0;
int err;
 
-   if (sock->type != SOCK_RAW &&
-   sock->type != SOCK_DGRAM &&
-   !inet_ehash_secret)
-   build_ehash_secret();
-
/* Look for the requested type/protocol pair. */
 lookup_protocol:
err = -ESOCKTNOSUPPORT;
diff --git a/net/ipv6/inet6_hashtables.c b/net/ipv6/inet6_hashtables.c
index fa7dd38..262e13c 100644
--- a/net/ipv6/inet6_hashtables.c
+++ b/net/ipv6/inet6_hashtables.c
@@ -29,10 +29,19 @@ static unsigned int inet6_ehashfn(struct net *net,
  const struct in6_addr *faddr,
  const __be16 fport)
 {
-   const u32 lhash = (__force u32)laddr->s6_addr32[3];
-   const u32 fhash = __ipv6_addr_jhash(faddr, 

[PATCH net-next v3 5/9] net: introduce new macro net_get_random_once

[Hannes Frederic Sowa]

net_get_random_once is a new macro which handles the initialization
of secret keys. It is possible to call it in the fast path. Only the
initialization depends on the spinlock and is rather slow. Otherwise
it should get used just before the key is used to delay the entropy
extration as late as possible to get better randomness. It returns true
if the key got initialized.

The usage of static_keys for net_get_random_once is a bit uncommon so
it needs some further explanation why this actually works:

=== In the simple non-HAVE_JUMP_LABEL case we actually have ===
no constrains to use static_key_(true|false) on keys initialized with
STATIC_KEY_INIT_(FALSE|TRUE). So this path just expands in favor of
the likely case that the initialization is already done. The key is
initialized like this:

___done_key = { .enabled = ATOMIC_INIT(0) }

The check

if (!static_key_true(&___done_key)) \

expands into (pseudo code)

if (!likely(___done_key > 0))

, so we take the fast path as soon as ___done_key is increased from the
helper function.

=== If HAVE_JUMP_LABELs are available this depends ===
on patching of jumps into the prepared NOPs, which is done in
jump_label_init at boot-up time (from start_kernel). It is forbidden
and dangerous to use net_get_random_once in functions which are called
before that!

At compilation time NOPs are generated at the call sites of
net_get_random_once. E.g. net/ipv6/inet6_hashtable.c:inet6_ehashfn (we
need to call net_get_random_once two times in inet6_ehashfn, so two NOPs):

  71:   0f 1f 44 00 00  nopl   0x0(%rax,%rax,1)
  76:   0f 1f 44 00 00  nopl   0x0(%rax,%rax,1)

Both will be patched to the actual jumps to the end of the function to
call __net_get_random_once at boot time as explained above.

arch_static_branch is optimized and inlined for false as return value and
actually also returns false in case the NOP is placed in the instruction
stream. So in the fast case we get a "return false". But because we
initialize ___done_key with (enabled != (entries & 1)) this call-site
will get patched up at boot thus returning true. The final check looks
like this:

if (!static_key_true(&___done_key)) \
___ret = __net_get_random_once(buf, \

expands to

if (!!static_key_false(&___done_key)) \
___ret = __net_get_random_once(buf, \

So we get true at boot time and as soon as static_key_slow_inc is called
on the key it will invert the logic and return false for the fast path.
static_key_slow_inc will change the branch because it got initialized
with .enabled == 0. After static_key_slow_inc is called on the key the
branch is replaced with a nop again.

=== Misc: ===
The helper defers the increment into a workqueue so we don't
have problems calling this code from atomic sections. A seperate boolean
(___done) guards the case where we enter net_get_random_once again before
the increment happend.

Cc: Ingo Molnar 
Cc: Steven Rostedt 
Cc: Jason Baron 
Cc: Peter Zijlstra 
Cc: Eric Dumazet 
Cc: "David S. Miller" 
Signed-off-by: Hannes Frederic Sowa 
---
I tested this patchset with !CC_HAVE_ASM_GOTO and with CC_HAVE_ASM_GOTO
on x86_64.

I quickly reviewed that all architectures which implement HAVE_JUMP_LABEL
also patch all branch sites on boot-up. But this needs further review
as this is a security sensitive patch series.

Thank you!

 include/linux/net.h | 25 +
 net/core/utils.c| 48 
 2 files changed, 73 insertions(+)

diff --git a/include/linux/net.h b/include/linux/net.h
index ca9ec85..a489705 100644
--- a/include/linux/net.h
+++ b/include/linux/net.h
@@ -239,6 +239,31 @@ do {   
\
 #define net_random()   prandom_u32()
 #define net_srandom(seed)  prandom_seed((__force u32)(seed))
 
+bool __net_get_random_once(void *buf, int nbytes, bool *done,
+  struct static_key *done_key);
+
+#ifdef HAVE_JUMP_LABEL
+#define ___NET_RANDOM_STATIC_KEY_INIT ((struct static_key) \
+   { .enabled = ATOMIC_INIT(0), .entries = (void *)1 })
+#else /* !HAVE_JUMP_LABEL */
+#define ___NET_RANDOM_STATIC_KEY_INIT STATIC_KEY_INIT_FALSE
+#endif /* HAVE_JUMP_LABEL */
+
+/* BE CAREFUL: this function is not interrupt safe */
+#define net_get_random_once(buf, nbytes)   \
+   ({  \
+   bool ___ret = false;\
+   static bool ___done = false;\
+   static struct static_key ___done_key =  \
+   ___NET_RANDOM_STATIC_KEY_INIT;  \
+   if (!static_key_true(&___done_key)) 

Re: [PATCH v2 01/15] slab: correct pfmemalloc check

[Joonsoo Kim]

On Wed, Oct 16, 2013 at 03:27:54PM +, Christoph Lameter wrote:
> On Wed, 16 Oct 2013, Joonsoo Kim wrote:
> 
> > --- a/mm/slab.c
> > +++ b/mm/slab.c
> > @@ -930,7 +930,8 @@ static void *__ac_put_obj(struct kmem_cache *cachep, 
> > struct array_cache *ac,
> >  {
> > if (unlikely(pfmemalloc_active)) {
> > /* Some pfmemalloc slabs exist, check if this is one */
> > -   struct page *page = virt_to_head_page(objp);
> > +   struct slab *slabp = virt_to_slab(objp);
> > +   struct page *page = virt_to_head_page(slabp->s_mem);
> > if (PageSlabPfmemalloc(page))
> 
> I hope the compiler optimizes this code correctly because virt_to_slab
> already does one virt_to_head_page()?

It should not.
objp could be in a different page with slabp->s_mem's,
so virt_to_head_page() should be called twice.

Anyway, after implementing struct slab overloading, one call site is
removed by [14/15] in this patchset, so there is no issue.

Thanks.

> 
> Otherwise this looks fine.
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org 
--
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-next: Tree for Oct 16

[Guenter Roeck]

On 10/16/2013 11:51 AM, Thierry Reding wrote:

Hi all,

I've uploaded today's linux-next tree to the master branch of the
repository below:

 git://gitorious.org/thierryreding/linux-next.git

A next-20131016 tag is also provided for convenience.

Gained two new conflicts, but nothing too exciting. x86 and ARM default
configurations as well as the x86 allmodconfig mostly build fine on the
final tree. There was a failure for the ARM at91x40_defconfig, but the
proper fix wasn't immediately obvious to me, so I've left it broken for
now.



Upside: mips qemu run now passes (mips64 qemu build still fails).

Downside: Up to 13 build failures, from 12.

Besides the mips64 qemu build, current failures are:

arm:allmodconfig
blackfin:defconfig
mips:nlm_xlp_defconfig
mips:cavium_octeon_defconfig
powerpc: (7 out of 14)
sparc64:allmodconfig
xtensa:allmodconfig (new failure)

Details are at http://server.roeck-us.net:8010/builders.

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 net V2 1/2] virtio-net: don't respond to cpu hotplug notifier if we're not ready

[Michael S. Tsirkin]

On Thu, Oct 17, 2013 at 09:57:41AM +1030, Rusty Russell wrote:
> Jason Wang  writes:
> > We're trying to re-configure the affinity unconditionally in cpu hotplug
> > callback. This may lead the issue during resuming from s3/s4 since
> >
> > - virt queues haven't been allocated at that time.
> > - it's unnecessary since thaw method will re-configure the affinity.
> >
> > Fix this issue by checking the config_enable and do nothing is we're not 
> > ready.
> >
> > The bug were introduced by commit 8de4b2f3ae90c8fc0f17eeaab87d5a951b66ee17
> > (virtio-net: reset virtqueue affinity when doing cpu hotplug).
> >
> > Cc: Rusty Russell 
> > Cc: Michael S. Tsirkin 
> > Cc: Wanlong Gao 
> > Acked-by: Michael S. Tsirkin 
> > Reviewed-by: Wanlong Gao 
> > Signed-off-by: Jason Wang 
> > ---
> > The patch is need for 3.8 and above.
> 
> Please put 'CC: sta...@kernel.org # 3.8+' in the commit.

Not if this is going in through the net tree.

> 
> (The specification of the stable line is poor, but that seems to be one
> common method).
> 
> Cheers,
> Rusty.
--
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 28/28] net: use DMA_COMPLETE for dma completion status

[David Miller]

From: Vinod Koul 
Date: Wed, 16 Oct 2013 21:58:46 +0530

> Signed-off-by: Vinod Koul 
> CC: "David S. Miller" 

Acked-by: David S. Miller 
--
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] of/lib: Export fdt routines to modules

[Guenter Roeck]

On 10/16/2013 05:27 PM, Michael Bohan wrote:

On Wed, Oct 16, 2013 at 04:39:03PM -0700, David Daney wrote:

On 10/16/2013 04:27 PM, Michael Bohan wrote:

Ever since the following commit, libfdt has been available for
usage in the kernel:

  commit ab25383983fb8d7786696f5371e75e79c3e9a405
  Author: David Daney 
  Date:   Thu Jul 5 18:12:38 2012 +0200

  of/lib: Allow scripts/dtc/libfdt to be used from kernel code

Export these functions to modules so that they may be used

>from device drivers.

---
+EXPORT_SYMBOL_GPL(fdt_next_tag);


The code was all written by David Gibson, and is dual GPL/BSD
licensed.  So I am not sure you should be using the GPL flavor of
the export directive.


Yeah, I wasn't quite sure about this myself. I can remove the GPL
if it's incorrect.


But more than this.  I don't understand why a driver would be
parsing the FDT in the first place.  If there is a device tree, why
hasn't it been unflattened, and thus used via the normal device tree
functions.


My motivation is actually to use the fdt format as a firmware.
I have a requirement to express driver metadata that's loadable
from the filesystem. This data is not reasonable to place in the
system Device Tree, since it's application specific and does not
actually describe hardware. The fact that the format chosen is
'flattened device tree' is merely just a coincidence.


Still, what prevents you from unflattening it and just using the
normal device tree functions as David suggested ?

Guenter


When considering formats, dts / fdt is convenient since:

-The dts syntax meets requirements by being human-readable.
-There exists a device-tree compiler already
-Linux knows how to deal with fdt, so the driver implementation
  becomes more simple.

Thanks,
Mike



--
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: About [PATCH 1/2] regulator: core: Provide a dummy regulator with full constraints

[Wei Ni]

On 10/16/2013 06:39 PM, Mark Brown wrote:
> * PGP Signed by an unknown key
> 
> On Wed, Oct 16, 2013 at 12:36:46PM +0800, Wei Ni wrote:
>> On 10/12/2013 08:14 PM, Mark Brown wrote:
> 
>>> OK, I think the device tree board code just needs to set full
>>> constraints during machine initialisation.  We can't have multiple
> 
>> Hi, Mark, do you mean we can call regulator_has_full_constraints(), but
>> some platforms doesn't have board file now, they only have dts file, how
>> to call this functions?
> 
> There is still a board file for DT machines, it's just shared between
> all machines - it should be doing the call instead of the regulator
> framework trying to retrofit it.

So do you mean it should call the regulator_has_full_constraints() in
the .init_machine for all machines? If so, this will affect all boards,
for example, in arch/arm/mach-tegra, if we set full constraints in the
shared board file tegra.c, all tegra boards will be set, is it right?

Thanks.
Wei.

> 
> * Unknown Key
> * 0x7EA229BD
> 

--
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: [bug] get_maintainer.pl incomplete output

[Joe Perches]

On Wed, 2013-10-16 at 21:19 -0700, David Rientjes wrote:
> On Wed, 16 Oct 2013, Joe Perches wrote:
> 
> > > I haven't looked closely at scripts/get_maintainer.pl, but I recently 
> > > wrote a patch touching mm/vmpressure.c and it doesn't list the file's 
> > > author, Anton Vorontsov .
> > > 
> > > Even when I do scripts/get_maintainer.pl -f mm/vmpressure.c, his entry is 
> > > missing and git blame attributs >90% of the lines to his authorship.
> > > 
> > > $ ./scripts/get_maintainer.pl -f mm/vmpressure.c 
> > > Tejun Heo  (commit_signer:6/7=86%)
> > > Michal Hocko  (commit_signer:5/7=71%)
> > > Andrew Morton  (commit_signer:4/7=57%)
> > > Li Zefan  (commit_signer:3/7=43%)
> > > "Kirill A. Shutemov"  (commit_signer:1/7=14%)
> > > linux...@kvack.org (open list:MEMORY MANAGEMENT)
> > > linux-kernel@vger.kernel.org (open list)
> > > 
> > > Any ideas?
> > 
> > get_maintainer has a lot of options.
> > 
> > get_maintainer tries to find people that are either
> > listed in the MAINTAINERS file or that have recently
> > (in the last year by default) worked on the file.
> > 
> > If you want to find all authors, use the --git-blame option
> > 
> > It's not the default because it can take quite awhile to run.
> > 
> 
> Hmm, it's a little strange to only consider recent activity when >90% of 
> the lines were written by someone not listed.  Isn't there any faster way 
> to determine that besides using the expensive git blame?

Not so far as I know.

> Something like 
> weighing the output of "git show --shortstat" for all commits in "git log 
> mm/vmpressure.c" to determine the most important recent changes?  That 
> should be fairly cheap.

Important can be hard to determine.

git blame effectively does a --follow

get_maintainers already does a git log 
and accumulates all the signatures for the
time selected by --git-since

It doesn't weight each commit by +/- count.

I think the most significant negative to
the current get_maintainer is that only the
"signature" lines are considered.

The "Author:" line isn't.

The default ris for get_maintainer to only list
a maximum of 5 "maintainers" ordered by signature
count.

Anton has only signed/acked 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: [RESEND PATCH 3/4] ARM: dts: bcm281xx: Add i2c busses

[Christian Daudt]

Hi Tim,
 This patch does not work as it relies on the yet-unmerged clock code
for bcm11351. This patch does not apply to -rc, and when tweaked it
does not compile as it references  non-existent bsc_clks.
 Has the clk patches been submitted yet ? Applying this will have to
wait until those have been accepted.

 thanks,
   csd


On Wed, Oct 16, 2013 at 3:01 PM, Tim Kryger  wrote:
> Add the DTS nodes for all the i2c busses in the SoC.
>
> Signed-off-by: Tim Kryger 
> Reviewed-by: Christian Daudt 
> Reviewed-by: Matt Porter 
> Reviewed-by: Markus Mayer 
> ---
>  arch/arm/boot/dts/bcm11351.dtsi | 40 
>  1 file changed, 40 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
> index 1246885..4bfd7e3 100644
> --- a/arch/arm/boot/dts/bcm11351.dtsi
> +++ b/arch/arm/boot/dts/bcm11351.dtsi
> @@ -146,6 +146,46 @@
> status = "disabled";
> };
>
> +   i2c@3e016000 {
> +   compatible = "brcm,bcm11351-i2c", "brcm,kona-i2c";
> +   reg = <0x3e016000 0x80>;
> +   interrupts = ;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   clocks = <&bsc1_clk>;
> +   status = "disabled";
> +   };
> +
> +   i2c@3e017000 {
> +   compatible = "brcm,bcm11351-i2c", "brcm,kona-i2c";
> +   reg = <0x3e017000 0x80>;
> +   interrupts = ;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   clocks = <&bsc2_clk>;
> +   status = "disabled";
> +   };
> +
> +   i2c@3e018000 {
> +   compatible = "brcm,bcm11351-i2c", "brcm,kona-i2c";
> +   reg = <0x3e018000 0x80>;
> +   interrupts = ;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   clocks = <&bsc3_clk>;
> +   status = "disabled";
> +   };
> +
> +   i2c@3500d000 {
> +   compatible = "brcm,bcm11351-i2c", "brcm,kona-i2c";
> +   reg = <0x3500d000 0x80>;
> +   interrupts = ;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   clocks = <&pmu_bsc_clk>;
> +   status = "disabled";
> +   };
> +
> clocks {
> bsc1_clk: bsc1 {
> compatible = "fixed-clock";
> --
> 1.8.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/

Re: [bug] get_maintainer.pl incomplete output

[David Rientjes]

On Wed, 16 Oct 2013, Joe Perches wrote:

> > I haven't looked closely at scripts/get_maintainer.pl, but I recently 
> > wrote a patch touching mm/vmpressure.c and it doesn't list the file's 
> > author, Anton Vorontsov .
> > 
> > Even when I do scripts/get_maintainer.pl -f mm/vmpressure.c, his entry is 
> > missing and git blame attributs >90% of the lines to his authorship.
> > 
> > $ ./scripts/get_maintainer.pl -f mm/vmpressure.c 
> > Tejun Heo  (commit_signer:6/7=86%)
> > Michal Hocko  (commit_signer:5/7=71%)
> > Andrew Morton  (commit_signer:4/7=57%)
> > Li Zefan  (commit_signer:3/7=43%)
> > "Kirill A. Shutemov"  (commit_signer:1/7=14%)
> > linux...@kvack.org (open list:MEMORY MANAGEMENT)
> > linux-kernel@vger.kernel.org (open list)
> > 
> > Any ideas?
> 
> get_maintainer has a lot of options.
> 
> get_maintainer tries to find people that are either
> listed in the MAINTAINERS file or that have recently
> (in the last year by default) worked on the file.
> 
> If you want to find all authors, use the --git-blame option
> 
> It's not the default because it can take quite awhile to run.
> 

Hmm, it's a little strange to only consider recent activity when >90% of 
the lines were written by someone not listed.  Isn't there any faster way 
to determine that besides using the expensive git blame?  Something like 
weighing the output of "git show --shortstat" for all commits in "git log 
mm/vmpressure.c" to determine the most important recent changes?  That 
should be fairly cheap.
--
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: [bug] get_maintainer.pl incomplete output

[Joe Perches]

On Wed, 2013-10-16 at 20:51 -0700, David Rientjes wrote:
> Hi Joe,

Hi David.

> I haven't looked closely at scripts/get_maintainer.pl, but I recently 
> wrote a patch touching mm/vmpressure.c and it doesn't list the file's 
> author, Anton Vorontsov .
> 
> Even when I do scripts/get_maintainer.pl -f mm/vmpressure.c, his entry is 
> missing and git blame attributs >90% of the lines to his authorship.
> 
> $ ./scripts/get_maintainer.pl -f mm/vmpressure.c 
> Tejun Heo  (commit_signer:6/7=86%)
> Michal Hocko  (commit_signer:5/7=71%)
> Andrew Morton  (commit_signer:4/7=57%)
> Li Zefan  (commit_signer:3/7=43%)
> "Kirill A. Shutemov"  (commit_signer:1/7=14%)
> linux...@kvack.org (open list:MEMORY MANAGEMENT)
> linux-kernel@vger.kernel.org (open list)
> 
> Any ideas?

get_maintainer has a lot of options.

get_maintainer tries to find people that are either
listed in the MAINTAINERS file or that have recently
(in the last year by default) worked on the file.

If you want to find all authors, use the --git-blame option

It's not the default because it can take quite awhile to run.

If you always want --git-blame added, use a .get_maintainer.conf
file to override the default options.

$ time ./scripts/get_maintainer.pl -f --git-blame mm/vmpressure.c
Tejun Heo  (commit_signer:6/7=86%,commits:5/6=83%)
Michal Hocko  (commit_signer:5/7=71%,authored 
lines:22/387=6%,commits:5/6=83%)
Andrew Morton  
(commit_signer:4/7=57%,commits:4/6=67%)
Li Zefan  (commit_signer:3/7=43%,commits:2/6=33%)
"Kirill A. Shutemov"  
(commit_signer:1/7=14%,commits:1/6=17%)
Anton Vorontsov  (authored lines:354/387=91%)
linux...@kvack.org (open list:MEMORY MANAGEMENT)
linux-kernel@vger.kernel.org (open list)

real0m28.529s
user0m25.400s
sys 0m0.764s

The --help option is moderately descriptive.
If you think it needs to be better, please say how.

cheers, Joe

$ ./scripts/get_maintainer.pl --help
usage: ./scripts/get_maintainer.pl [options] patchfile
   ./scripts/get_maintainer.pl [options] -f file|directory
version: 0.26

MAINTAINER field selection options:
  --email => print email address(es) if any
--git => include recent git *-by: signers
--git-all-signature-types => include signers regardless of signature type
or use only (Signed-off-by:|Reviewed-by:|Acked-by:) signers (default: 0)
--git-fallback => use git when no exact MAINTAINERS pattern (default: 1)
--git-chief-penguins => include (Linus Torvalds)
--git-min-signatures => number of signatures required (default: 1)
--git-max-maintainers => maximum maintainers to add (default: 5)
--git-min-percent => minimum percentage of commits required (default: 5)
--git-blame => use git blame to find modified commits for patch or file
--git-since => git history to use (default: 1-year-ago)
--hg-since => hg history to use (default: -365)
--interactive => display a menu (mostly useful if used with the --git 
option)
--m => include maintainer(s) if any
--n => include name 'Full Name '
--l => include list(s) if any
--s => include subscriber only list(s) if any
--remove-duplicates => minimize duplicate email names/addresses
--roles => show roles (status:subsystem, git-signer, list, etc...)
--rolestats => show roles and statistics (commits/total_commits, %)
--file-emails => add email addresses found in -f file (default: 0 (off))
  --scm => print SCM tree(s) if any
  --status => print status if any
  --subsystem => print subsystem name if any
  --web => print website(s) if any

Output type options:
  --separator [, ] => separator for multiple entries on 1 line
using --separator also sets --nomultiline if --separator is not [, ]
  --multiline => print 1 entry per line

Other options:
  --pattern-depth => Number of pattern directory traversals (default: 0 (all))
  --keywords => scan patch for keywords (default: 1)
  --sections => print all of the subsystem sections with pattern matches
  --mailmap => use .mailmap file (default: 1)
  --version => show version
  --help => show this help information

Default options:
  [--email --nogit --git-fallback --m --n --l --multiline -pattern-depth=0
   --remove-duplicates --rolestats]

Notes:
  Using "-f directory" may give unexpected results:
  Used with "--git", git signators for _all_ files in and below
  directory are examined as git recurses directories.
  Any specified X: (exclude) pattern matches are _not_ ignored.
  Used with "--nogit", directory is used as a pattern match,
  no individual file within the directory or subdirectory
  is matched.
  Used with "--git-blame", does not iterate all files in directory
  Using "--git-blame" is slow and may add old committers and authors
  that are no longer active maintainers to the output.
  Using "--roles" or "--rolestats" with git send-email --cc-cmd or any
  other automated tools that expect only ["name"] 
  may not work because of additional output after .
  Using 

Re: [PATCH net V2 1/2] virtio-net: don't respond to cpu hotplug notifier if we're not ready

[Rusty Russell]

Jason Wang  writes:
> We're trying to re-configure the affinity unconditionally in cpu hotplug
> callback. This may lead the issue during resuming from s3/s4 since
>
> - virt queues haven't been allocated at that time.
> - it's unnecessary since thaw method will re-configure the affinity.
>
> Fix this issue by checking the config_enable and do nothing is we're not 
> ready.
>
> The bug were introduced by commit 8de4b2f3ae90c8fc0f17eeaab87d5a951b66ee17
> (virtio-net: reset virtqueue affinity when doing cpu hotplug).
>
> Cc: Rusty Russell 
> Cc: Michael S. Tsirkin 
> Cc: Wanlong Gao 
> Acked-by: Michael S. Tsirkin 
> Reviewed-by: Wanlong Gao 
> Signed-off-by: Jason Wang 
> ---
> The patch is need for 3.8 and above.

Please put 'CC: sta...@kernel.org # 3.8+' in the commit.

(The specification of the stable line is poor, but that seems to be one
common method).

Cheers,
Rusty.
--
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/3] switch_creds: Syscall to switch creds for file server ops

[Eric W. Biederman]

Al Viro  writes:

> On Wed, Oct 16, 2013 at 06:18:16PM -0700, Eric W. Biederman wrote:
>
>> That doesn't look bad but it does need capable(CAP_SETUID) &&
>> capable(CAP_SETGID) or possibly something a little more refined.
>
> D'oh
>
>> I don't think we want file descriptor passing to all of a sudden become
>> a grant of privilege, beyond what the passed fd can do.
>
> Definitely.  And an extra ) to make it compile wouldn't hurt either...

There also appears to need to be a check that we don't gain any
capabilities.

We also need a check so that you don't gain any capabilities, and
possibly a few other things.

So I suspect we want a check something like:

if ((new_cred->securebits != current_cred->securebits)  ||
(new_cred->cap_inheritable != current_cred->cap_inheritable) ||
(new_cred->cap_permitted != current_cred->cap_permitted) ||
(new_cred->cap_effective != current_cred->cap_effective) ||
(new_cred->cap_bset != current_cred->cap_bset) ||
(new_cred->jit_keyring != current_cred->jit_keyring) ||
(new_cred->session_keyring != current_cred->session_keyring) ||
(new_cred->process_keyring != current_cred->process_keyring) ||
(new_cred->thread_keyring != current_cred->thread_keyring) ||
(new_cred->request_keyring != current_cred->request_keyring) ||
(new_cred->security != current_cred->security) ||
(new_cred->user_ns != current_cred->user_ns)) {
return -EPERM;
}

Eric

--
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/

[bug] get_maintainer.pl incomplete output

[David Rientjes]

Hi Joe,

I haven't looked closely at scripts/get_maintainer.pl, but I recently 
wrote a patch touching mm/vmpressure.c and it doesn't list the file's 
author, Anton Vorontsov .

Even when I do scripts/get_maintainer.pl -f mm/vmpressure.c, his entry is 
missing and git blame attributs >90% of the lines to his authorship.

$ ./scripts/get_maintainer.pl -f mm/vmpressure.c 
Tejun Heo  (commit_signer:6/7=86%)
Michal Hocko  (commit_signer:5/7=71%)
Andrew Morton  (commit_signer:4/7=57%)
Li Zefan  (commit_signer:3/7=43%)
"Kirill A. Shutemov"  (commit_signer:1/7=14%)
linux...@kvack.org (open list:MEMORY MANAGEMENT)
linux-kernel@vger.kernel.org (open list)

Any ideas?
--
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] mm, vmpressure: add high level

[David Rientjes]

On Wed, 16 Oct 2013, Anton Vorontsov wrote:

> > Vmpressure has two important levels: medium and critical.  Medium is 
> > defined at 60% and critical is defined at 95%.
> > 
> > We have a customer who needs a notification at a higher level than medium, 
> > which is slight to moderate reclaim activity, and before critical to start 
> > throttling incoming requests to save memory and avoid oom.
> > 
> > This patch adds the missing link: a high level defined at 80%.
> > 
> > In the future, it would probably be better to allow the user to specify an 
> > integer ratio for the notification rather than relying on arbitrarily 
> > specified levels.
> 
> Does the customer need to differentiate the two levels (medium and high),
> or the customer only interested in this (80%) specific level?
> 

Only high.

> In the latter case, instead of adding a new level I would vote for adding
> a [sysfs] knob for modifying medium level's threshold.
> 

Hmm, doesn't seem like such a good idea.  If one process depends on this 
being 60% and another depends on it being 80%, we're stuck.  I think it's 
legitimate to have things like low, medium, high, and critical as rough 
approximations (and to keep backwards compatibility), but as mentioned in 
the changelog I want to extend the interface to allow integer writes to 
specify their own ratio.
--
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] ext4: fix performance regression in ext4_writepages

[Theodore Ts'o]

On Wed, Oct 16, 2013 at 09:18:37AM +0800, Ming Lei wrote:
> Commit 4e7ea81db5(ext4: restructure writeback path) introduces
> another performance regression on random write:
> 
> - one more page may be added to ext4 extent in mpage_prepare_extent_to_map,
>   and will be submitted for I/O so nr_to_write will become -1 before 'done'
>   is set
> 
> - the worse thing is that dirty pages may still be retrieved from page
>   cache after nr_to_write becomes negative, so lots of small chunks can be
>   submitted to block device when page writeback is catching up with write
>   path, and performance is hurted.
> 
> On one arm A15 board with sata 3.0 SSD(CPU: 1.5GHz dura core, RAM: 2GB,
> SATA controller: 3.0Gbps), this patch can improve below test's result
> from 157MB/sec to 174MB/sec(>10%):
> 
>   dd if=/dev/zero of=./z.img bs=8K count=512K
> 
> The above test is actually prototype of block write in bonnie++ utility.
> 
> This patch makes sure no more pages than nr_to_write can be added to extent
> for mapping, so that nr_to_write won't become negative.
> 
> Cc: Ted Tso 
> Cc: linux-e...@vger.kernel.org
> Cc: "linux-fsde...@vger.kernel.org" 
> Acked-by: Jan Kara 
> Signed-off-by: Ming Lei 

Thanks, applied.

- 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: [Resend PATCH 3/5] ACPI: Add new acpi_dev_resource_address_space_full() function

[Lan Tianyu]

On 2013年10月17日 07:18, Bjorn Helgaas wrote:
> On Fri, Oct 11, 2013 at 08:18:59PM +0800, tianyu@intel.com wrote:
>> From: Lan Tianyu 
>>
>> Make acpi_dev_resource_address_space() to accept struct
>> acpi_resource_address64 as param and rename it to *_full.
>>
>> This is for some cases that acpi address info is also needed
>> after convert from acpi resouce to generic resource.
> 
> s/resouce/resource/
> 
>> Add acpi_dev_resource_addres_space() again as a wrapper of new
> 
> acpi_dev_resource_address_space() (spelled wrong above).
> 
>> function for original users.
>>
>> Signed-off-by: Lan Tianyu 
>> ---
>>  drivers/acpi/resource.c | 53 
>> ++---
>>  include/linux/acpi.h|  3 +++
>>  2 files changed, 40 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
>> index 84bc3db..2e395ba 100644
>> --- a/drivers/acpi/resource.c
>> +++ b/drivers/acpi/resource.c
>> @@ -162,19 +162,21 @@ bool acpi_dev_resource_io(struct acpi_resource *ares, 
>> struct resource *res)
>>  EXPORT_SYMBOL_GPL(acpi_dev_resource_io);
>>  
>>  /**
>> - * acpi_dev_resource_address_space - Extract ACPI address space information.
>> + * acpi_dev_resource_address_space_full - Extract ACPI address space 
>> information.
>>   * @ares: Input ACPI resource object.
>> + * @addr: Output ACPI resource address64 space object.
>>   * @res: Output generic resource object.
>>   *
>>   * Check if the given ACPI resource object represents an address space 
>> resource
>> - * and if that's the case, use the information in it to populate the generic
>> - * resource object pointed to by @res.
>> + * and if that's the case, convert it to ACPI resource address64 space 
>> object
>> + * pointed to by @addr and use the information to populate the generic 
>> resource
>> + * object pointed to by @re.
> 
> s/@re/@res/ or maybe even just use this:
> 
> "If @ares is an address space resource, convert it to an
> acpi_resource_address64 and use that to populate the generic @res."
> 
>>   */
>> -bool acpi_dev_resource_address_space(struct acpi_resource *ares,
>> +bool acpi_dev_resource_address_space_full(struct acpi_resource *ares,
>> + struct acpi_resource_address64 *addr,
>>   struct resource *res)
>>  {
>>  acpi_status status;
>> -struct acpi_resource_address64 addr;
>>  bool window;
>>  u64 len;
>>  u8 io_decode;
>> @@ -188,29 +190,29 @@ bool acpi_dev_resource_address_space(struct 
>> acpi_resource *ares,
>>  return false;
>>  }
>>  
>> -status = acpi_resource_to_address64(ares, &addr);
>> +status = acpi_resource_to_address64(ares, addr);
>>  if (ACPI_FAILURE(status))
>>  return true;
> 
> You didn't actually change this, but it looks wrong to return "true"
> here, because we haven't filled in "res".  Returning "true" will cause
> acpi_dev_process_resource() to call acpi_dev_new_resource_entry() with
> a struct resource that's full of zeroes.
> 
> I think the best fix would be to remove this code just above:
> 
> switch (ares->type) {
> case ACPI_RESOURCE_TYPE_ADDRESS16:
> case ACPI_RESOURCE_TYPE_ADDRESS32:
> case ACPI_RESOURCE_TYPE_ADDRESS64:
> break;
> default:
> return false;
> }
> 
> and return "false" if acpi_resource_to_address64() fails.

Yes, Just check acpi_resource_to_address64() and it only processes
ACPI_RESOURCE_TYPE_ADDRESS16, ACPI_RESOURCE_TYPE_ADDRESS32 and
ACPI_RESOURCE_TYPE_ADDRESS64. If other type,  it will return false.
I will change it.

> 
>>  
>> -res->start = addr.minimum + addr.translation_offset;
>> -res->end = addr.maximum + addr.translation_offset;
>> -window = addr.producer_consumer == ACPI_PRODUCER;
>> +res->start = addr->minimum + addr->translation_offset;
>> +res->end = addr->maximum + addr->translation_offset;
>> +window = addr->producer_consumer == ACPI_PRODUCER;
>>  
>> -switch(addr.resource_type) {
>> +switch (addr->resource_type) {
>>  case ACPI_MEMORY_RANGE:
>> -len = addr.maximum - addr.minimum + 1;
>> +len = addr->maximum - addr->minimum + 1;
>>  res->flags = acpi_dev_memresource_flags(len,
>> -addr.info.mem.write_protect,
>> +addr->info.mem.write_protect,
>>  window);
>>  
>> -if (addr.info.mem.caching == ACPI_PREFETCHABLE_MEMORY)
>> +if (addr->info.mem.caching == ACPI_PREFETCHABLE_MEMORY)
>>  res->flags |= IORESOURCE_PREFETCH;
>>  break;
>>  case ACPI_IO_RANGE:
>> -io_decode = addr.granularity == 0xfff ?
>> +io_decode = addr->granularity == 0xfff ?
>>  ACPI_DECODE_10 : ACPI_DECODE_16;
>> -res->flags = acpi_dev_i

Re: Re: [PATCH 1/3] switch_creds: Syscall to switch creds for file server ops

[Jim Lieb]

On Thursday, October 17, 2013 02:20:50 Al Viro wrote:
> On Wed, Oct 16, 2013 at 06:18:16PM -0700, Eric W. Biederman wrote:
> > That doesn't look bad but it does need capable(CAP_SETUID) &&
> > capable(CAP_SETGID) or possibly something a little more refined.
> 
> D'oh
> 
> > I don't think we want file descriptor passing to all of a sudden become
> > a grant of privilege, beyond what the passed fd can do.
> 
> Definitely.  And an extra ) to make it compile wouldn't hurt either...

Ok, I'll rework this, dropping the void arg etc.  How about this:

1. have one arg, the fd, i.e. SYSCALL_DEFINE1(switch_cred, int, fd)

2. if the fd >=0 do the override in my "use the fd" variation.  This would do 
the capability check after the valid fd check.  This means that you must have
privs to mess with privs.  Returns 0 or either EBADF or EPERM

3. if the fd == -1 do the revert case.  The reason for this is there are 4 
syscalls needed to change the creds and each has an error return.  We need
a way to escape the damage and a revert to the real creds set is the best way 
to return to a known state.  This does not require a capability check because
all that can happen is to return to the immutable real set.  Also, I don't 
need the initial open of /dev/null.

Does this fit?

Jim
-- 
Jim Lieb
Linux Systems Engineer
Panasas Inc.

"If ease of use was the only requirement, we would all be riding tricycles"
- Douglas Engelbart 1925–2013
--
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/

sparse: possible false report of context imbalance

[Larry Finger]

Hi,

Sparse reports the following:

  CHECK   drivers/staging/rtl8188eu/core/rtw_mlme.c
drivers/staging/rtl8188eu/core/rtw_mlme.c:1003:9: warning: context imbalance in 
'rtw_free_assoc_resources' - different lock contexts for basic block


The code in question is as follows:

if (lock_scanned_queue)
spin_lock_bh(&(pmlmepriv->scanned_queue.lock));

pwlan = rtw_find_network(&pmlmepriv->scanned_queue, 
tgt_network->network.MacAddress);


if (lock_scanned_queue)
spin_unlock_bh(&(pmlmepriv->scanned_queue.lock));

As this fragment uses the identical test to unlock that is used to lock, and the 
test variable is not touched, I think this is a false indication. I am using 
version 0.4.4 of sparse.


Thanks,

Larry
--
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: [Resend PATCH 2/5] ACPI/Resource: Add address translation support

[Lan Tianyu]

On 2013年10月17日 07:05, Bjorn Helgaas wrote:
> On Fri, Oct 11, 2013 at 08:18:58PM +0800, tianyu@intel.com wrote:
>> From: Lan Tianyu 
>>
>> According ACPI 5.0 spec Section 19.1.8
> 
> This section reference is wrong.  Table 5-133 (on page 243) does
> point to Section 19.1.8, but that section is only the ASL grammar
> description and doesn't have any useful information about what
> _TRA means.
> 
> A more useful reference (and the source of the quote below) is
> Section 6.4.3.5.1.
> 
>> "For bridges, translate addresses across the bridge, this is the
>> offset that must be added to the address on the secondary side
>> to obtain the address on the primary side. Non-bridge devices
>> must list 0."
> 
> You didn't quote this correctly.  Here's a copy/paste from the spec:
> 
> For bridges that translate addresses across the bridge, this is
> the offset that must be added to the address on the secondary side
> to obtain the address on the primary side. Non-bridge devices must
> list 0 for all Address Translation offset bits.
> 
>> This patch is to add address translation offset to the start/end
>> of struct resource in the acpi_dev_resource_address_space().
>> Further more, non-bridge device's translation_offset should 0.
>> So this change will affect other devices.
>>
>> Signed-off-by: Lan Tianyu 
> 
> I like the patch, though :)  With the above corrections,

Hi Bjorn:
Thanks for review. I will correct them.

> 
> Acked-by: Bjorn Helgaas 
> 
>> ---
>>  drivers/acpi/resource.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
>> index 929f416..84bc3db 100644
>> --- a/drivers/acpi/resource.c
>> +++ b/drivers/acpi/resource.c
>> @@ -192,8 +192,8 @@ bool acpi_dev_resource_address_space(struct 
>> acpi_resource *ares,
>>  if (ACPI_FAILURE(status))
>>  return true;
>>  
>> -res->start = addr.minimum;
>> -res->end = addr.maximum;
>> +res->start = addr.minimum + addr.translation_offset;
>> +res->end = addr.maximum + addr.translation_offset;
>>  window = addr.producer_consumer == ACPI_PRODUCER;
>>  
>>  switch(addr.resource_type) {
>> -- 
>> 1.8.2.1
>>


-- 
Best regards
Tianyu Lan
--
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/

[no subject]

[remittance2013@hotmail.comContact]

-- 
Dear beneficiary,This is to re-notify you of the $300,000.00 USD that was 
depositedhere in the western union office in your name is available for 
pickup.Contact us via email for your M.T.C.N Numbers.Contact Person:Mr. ben c 
johnEmail: remittance2013@hotmail.comContact Phone : +44 7024043572
--
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/3 v6] thermal: samsung: Add TMU support for Exynos5420 SoCs

[Naveen Krishna Chatradhi]

This patch adds the neccessary register changes and arch information
to support Exynos5420 SoCs
Exynos5420 has 5 TMU channels one for each CPU 0, 1, 2 and 3 and GPU

Also updated the Documentation at
Documentation/devicetree/bindings/thermal/exynos-thermal.txt

Note: The platform data structure will be handled properly once the driver
 moves to complete device driver solution.

Signed-off-by: Naveen Krishna Chatradhi 
---
Changes since v1:
1. modified the platform data structure in order to pass SHARED flag
   for channels that need sharing of address space.
2. https://lkml.org/lkml/2013/8/1/38 is merged into this patch.
   As the changes are minimum and can be added here.
Changes since v3:
   a. Rearraged the code alphabetically, make exynso5420 come before exynso5440
   b. Reduce code duplication in passing platform data by introducing a common 
macro
  Bartlomiej Zolnierkiewicz Thanks for review and suggestions
Changes since v4:
 None
Changes since v5:
 None

 .../devicetree/bindings/thermal/exynos-thermal.txt |   39 
 drivers/thermal/samsung/exynos_tmu.c   |   12 ++-
 drivers/thermal/samsung/exynos_tmu.h   |1 +
 drivers/thermal/samsung/exynos_tmu_data.c  |   99 
 drivers/thermal/samsung/exynos_tmu_data.h  |7 ++
 5 files changed, 157 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index 116cca0..c5f9a74 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -6,6 +6,7 @@
   "samsung,exynos4412-tmu"
   "samsung,exynos4210-tmu"
   "samsung,exynos5250-tmu"
+  "samsung,exynos5420-tmu"
   "samsung,exynos5440-tmu"
 - interrupt-parent : The phandle for the interrupt controller
 - reg : Address range of the thermal registers. For soc's which has multiple
@@ -13,6 +14,16 @@
interrupt related then 2 set of register has to supplied. First set
belongs to each instance of TMU and second set belongs to second set
of common TMU registers.
+  NOTE: On Exynos5420, the TRIMINFO register is misplaced for TMU
+   channels 2, 3 and 4
+
+   TRIMINFO at 0x1006c000 contains data for TMU channel 3
+   TRIMINFO at 0x100a contains data for TMU channel 4
+   TRIMINFO at 0x10068000 contains data for TMU channel 2
+
+   The misplaced register address is passed through devicetree as the
+   second base
+
 - interrupts : Should contain interrupt for thermal system
 - clocks : The main clock for TMU device
 - clock-names : Thermal system clock name
@@ -43,6 +54,34 @@ Example 2):
clock-names = "tmu_apbif";
};
 
+Example 3): (In case of Exynos5420)
+   /* tmu for CPU2 */
+   tmu@10068000 {
+   compatible = "samsung,exynos5420-tmu";
+   reg = <0x10068000 0x100>, <0x1006c000 0x4>;
+   interrupts = <0 184 0>;
+   clocks = <&clock 318>;
+   clock-names = "tmu_apbif";
+   };
+
+   /* tmu for CPU3 */
+   tmu@1006c000 {
+   compatible = "samsung,exynos5420-tmu";
+   reg = <0x1006c000 0x100>, <0x100a 0x4>;
+   interrupts = <0 185 0>;
+   clocks = <&clock 318>;
+   clock-names = "tmu_apbif";
+   };
+
+   /* tmu for GPU */
+   tmu@100a {
+   compatible = "samsung,exynos5420-tmu";
+   reg = <0x100a 0x100>, <0x10068000 0x4>;
+   interrupts = <0 215 0>;
+   clocks = <&clock 318>;
+   clock-names = "tmu_apbif";
+   };
+
 Note: For multi-instance tmu each instance should have an alias correctly
 numbered in "aliases" node.
 
diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index ae80a87..b54825a 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -186,7 +186,12 @@ static int exynos_tmu_initialize(struct platform_device 
*pdev)
EXYNOS5440_EFUSE_SWAP_OFFSET + reg->triminfo_data);
}
} else {
-   trim_info = readl(data->base + reg->triminfo_data);
+   /* On exynos5420 the triminfo register is in the shared space */
+   if (data->base_second && (data->soc == SOC_ARCH_EXYNOS5420))
+   trim_info = readl(data->base_second +
+   reg->triminfo_data);
+   else
+   trim_info = readl(data->base + reg->triminfo_data);
}
data->temp_error1 = trim_info & EXYNOS_TMU_TEMP_MASK;
data->temp_error2 = ((trim_info >> reg->triminfo_85_shift) &
@@ -498,6 +503,10 @@ static const struct of_device_id exynos_tmu_match[] = {
.data = (vo

[PATCH 2/3 v6] thermal: samsung: change base_common to more meaningful base_second

[Naveen Krishna Chatradhi]

On Exynos5440 and Exynos5420 there are registers common
across the TMU channels.

To support that, we introduced a ADDRESS_MULTIPLE flag in the
driver and the 2nd set of register base and size are provided
in the "reg" property of the node.

As per Amit's suggestion, this patch changes the base_common
to base_second and SHARED_MEMORY to ADDRESS_MULTIPLE.

Signed-off-by: Naveen Krishna Chatradhi 
---
Changes since v1:
 None
Changes since v2:
 Changed the flag name from SHARED_MEMORY to ADDRESS_MULTIPLE.
 https://lkml.org/lkml/2013/8/1/38
Changes since v3:
 None
Changes since v4:
 Corrected a compilation error, undeclared variable
Changes since v5:
 None

 .../devicetree/bindings/thermal/exynos-thermal.txt   |4 ++--
 drivers/thermal/samsung/exynos_tmu.c |   14 +++---
 drivers/thermal/samsung/exynos_tmu.h |4 ++--
 drivers/thermal/samsung/exynos_tmu_data.c|2 +-
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index 284f530..116cca0 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -11,8 +11,8 @@
 - reg : Address range of the thermal registers. For soc's which has multiple
instances of TMU and some registers are shared across all TMU's like
interrupt related then 2 set of register has to supplied. First set
-   belongs to each instance of TMU and second set belongs to common TMU
-   registers.
+   belongs to each instance of TMU and second set belongs to second set
+   of common TMU registers.
 - interrupts : Should contain interrupt for thermal system
 - clocks : The main clock for TMU device
 - clock-names : Thermal system clock name
diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index b2202fa..ae80a87 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -41,7 +41,7 @@
  * @id: identifier of the one instance of the TMU controller.
  * @pdata: pointer to the tmu platform/configuration data
  * @base: base address of the single instance of the TMU controller.
- * @base_common: base address of the common registers of the TMU controller.
+ * @base_second: base address of the common registers of the TMU controller.
  * @irq: irq number of the TMU controller.
  * @soc: id of the SOC type.
  * @irq_work: pointer to the irq work structure.
@@ -56,7 +56,7 @@ struct exynos_tmu_data {
int id;
struct exynos_tmu_platform_data *pdata;
void __iomem *base;
-   void __iomem *base_common;
+   void __iomem *base_second;
int irq;
enum soc_type soc;
struct work_struct irq_work;
@@ -297,7 +297,7 @@ skip_calib_data:
}
/*Clear the PMIN in the common TMU register*/
if (reg->tmu_pmin && !data->id)
-   writel(0, data->base_common + reg->tmu_pmin);
+   writel(0, data->base_second + reg->tmu_pmin);
 out:
clk_disable(data->clk);
mutex_unlock(&data->lock);
@@ -454,7 +454,7 @@ static void exynos_tmu_work(struct work_struct *work)
 
/* Find which sensor generated this interrupt */
if (reg->tmu_irqstatus) {
-   val_type = readl(data->base_common + reg->tmu_irqstatus);
+   val_type = readl(data->base_second + reg->tmu_irqstatus);
if (!((val_type >> data->id) & 0x1))
goto out;
}
@@ -579,7 +579,7 @@ static int exynos_map_dt_data(struct platform_device *pdev)
 * Check if the TMU shares some registers and then try to map the
 * memory of common registers.
 */
-   if (!TMU_SUPPORTS(pdata, SHARED_MEMORY))
+   if (!TMU_SUPPORTS(pdata, ADDRESS_MULTIPLE))
return 0;
 
if (of_address_to_resource(pdev->dev.of_node, 1, &res)) {
@@ -587,9 +587,9 @@ static int exynos_map_dt_data(struct platform_device *pdev)
return -ENODEV;
}
 
-   data->base_common = devm_ioremap(&pdev->dev, res.start,
+   data->base_second = devm_ioremap(&pdev->dev, res.start,
resource_size(&res));
-   if (!data->base_common) {
+   if (!data->base_second) {
dev_err(&pdev->dev, "Failed to ioremap memory\n");
return -ENOMEM;
}
diff --git a/drivers/thermal/samsung/exynos_tmu.h 
b/drivers/thermal/samsung/exynos_tmu.h
index 5f4fe6c..d79264f 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -60,7 +60,7 @@ enum soc_type {
  * state(active/idle) can be checked.
  * TMU_SUPPORT_EMUL_TIME - This features allows to set next temp emulation
  * sample time.
- * TMU_SUPPORT_SHARED_MEMORY - This feature tells that the

[PATCH 1/3 v6] thermal: samsung: add intclr_fall_shift bit in exynos_tmu_register

[Naveen Krishna Chatradhi]

On Exynos5250, the FALL interrupt related en, status and clear bits are
available at an offset of
16 in INTEN, INTSTAT registers and at an offset of
12 in INTCLEAR register.

On Exynos5420, the FALL interrupt related en, status and clear bits are
available at an offset of
16 in INTEN, INTSTAT and INTCLEAR registers.

On Exynos5440,
the FALL_IRQEN bits are at an offset of 4
and the RISE_IRQEN bits are at an offset of 0

This patch introduces a new bit field intclr_fall_shift to handle the
offset for exyns5250 and exynos5440

Signed-off-by: Naveen Krishna Chatradhi 
---
Changes since v1:
Changes since v2:
Changes since v3:
  None
Changes since v4:
 Correct the CLEAR_FALL_INT_SHIFT for Exynos5250/Exynos5440
Changes since v5:
 Modify the commit message

 drivers/thermal/samsung/exynos_tmu.c  |2 +-
 drivers/thermal/samsung/exynos_tmu.h  |2 ++
 drivers/thermal/samsung/exynos_tmu_data.c |2 ++
 drivers/thermal/samsung/exynos_tmu_data.h |4 +++-
 4 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index 32f38b9..b2202fa 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -265,7 +265,7 @@ skip_calib_data:
data->base + reg->threshold_th1);
 
writel((reg->inten_rise_mask << reg->inten_rise_shift) |
-   (reg->inten_fall_mask << reg->inten_fall_shift),
+   (reg->inten_fall_mask << reg->intclr_fall_shift),
data->base + reg->tmu_intclear);
 
/* if last threshold limit is also present */
diff --git a/drivers/thermal/samsung/exynos_tmu.h 
b/drivers/thermal/samsung/exynos_tmu.h
index 3fb6554..5f4fe6c 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -136,6 +136,7 @@ enum soc_type {
  * @inten_fall3_shift: shift bits of falling 3 interrupt bits.
  * @tmu_intstat: Register containing the interrupt status values.
  * @tmu_intclear: Register for clearing the raised interrupt status.
+ * @intclr_fall_shift: shift bits for interrupt clear fall 0
  * @emul_con: TMU emulation controller register.
  * @emul_temp_shift: shift bits of emulation temperature.
  * @emul_time_shift: shift bits of emulation time.
@@ -207,6 +208,7 @@ struct exynos_tmu_registers {
u32 tmu_intstat;
 
u32 tmu_intclear;
+   u32 intclr_fall_shift;
 
u32 emul_con;
u32 emul_temp_shift;
diff --git a/drivers/thermal/samsung/exynos_tmu_data.c 
b/drivers/thermal/samsung/exynos_tmu_data.c
index 073c292..09a8a27 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.c
+++ b/drivers/thermal/samsung/exynos_tmu_data.c
@@ -123,6 +123,7 @@ static const struct exynos_tmu_registers 
exynos4412_tmu_registers = {
.inten_fall0_shift = EXYNOS_TMU_INTEN_FALL0_SHIFT,
.tmu_intstat = EXYNOS_TMU_REG_INTSTAT,
.tmu_intclear = EXYNOS_TMU_REG_INTCLEAR,
+   .intclr_fall_shift = EXYNOS5250_TMU_CLEAR_FALL_INT_SHIFT,
.emul_con = EXYNOS_EMUL_CON,
.emul_temp_shift = EXYNOS_EMUL_DATA_SHIFT,
.emul_time_shift = EXYNOS_EMUL_TIME_SHIFT,
@@ -228,6 +229,7 @@ static const struct exynos_tmu_registers 
exynos5440_tmu_registers = {
.inten_fall0_shift = EXYNOS5440_TMU_INTEN_FALL0_SHIFT,
.tmu_intstat = EXYNOS5440_TMU_S0_7_IRQ,
.tmu_intclear = EXYNOS5440_TMU_S0_7_IRQ,
+   .intclr_fall_shift = EXYNOS5440_TMU_CLEAR_FALL_INT_SHIFT,
.tmu_irqstatus = EXYNOS5440_TMU_IRQ_STATUS,
.emul_con = EXYNOS5440_TMU_S0_7_DEBUG,
.emul_temp_shift = EXYNOS_EMUL_DATA_SHIFT,
diff --git a/drivers/thermal/samsung/exynos_tmu_data.h 
b/drivers/thermal/samsung/exynos_tmu_data.h
index a1ea19d..9c1e2c8 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.h
+++ b/drivers/thermal/samsung/exynos_tmu_data.h
@@ -69,9 +69,11 @@
 #define EXYNOS_TMU_RISE_INT_MASK   0x111
 #define EXYNOS_TMU_RISE_INT_SHIFT  0
 #define EXYNOS_TMU_FALL_INT_MASK   0x111
-#define EXYNOS_TMU_FALL_INT_SHIFT  12
+#define EXYNOS_TMU_FALL_INT_SHIFT  16
 #define EXYNOS_TMU_CLEAR_RISE_INT  0x111
 #define EXYNOS_TMU_CLEAR_FALL_INT  (0x111 << 12)
+#define EXYNOS5250_TMU_CLEAR_FALL_INT_SHIFT12
+#define EXYNOS5440_TMU_CLEAR_FALL_INT_SHIFT4
 #define EXYNOS_TMU_TRIP_MODE_SHIFT 13
 #define EXYNOS_TMU_TRIP_MODE_MASK  0x7
 #define EXYNOS_TMU_THERM_TRIP_EN_SHIFT 12
-- 
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/

[PATCH 29/29] dmaengine: remove unused DMA_SUCCESS

[Vinod Koul]

after all the users are converted

Signed-off-by: Vinod Koul 
---
 include/linux/dmaengine.h |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 683c380..4b460a6 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -55,7 +55,6 @@ enum dma_status {
DMA_IN_PROGRESS,
DMA_PAUSED,
DMA_ERROR,
-   DMA_SUCCESS,
 };
 
 /**
-- 
1.7.0.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] mm, vmpressure: add high level

[Anton Vorontsov]

Hello David,

On Wed, Oct 16, 2013 at 05:43:55PM -0700, David Rientjes wrote:
> Vmpressure has two important levels: medium and critical.  Medium is 
> defined at 60% and critical is defined at 95%.
> 
> We have a customer who needs a notification at a higher level than medium, 
> which is slight to moderate reclaim activity, and before critical to start 
> throttling incoming requests to save memory and avoid oom.
> 
> This patch adds the missing link: a high level defined at 80%.
> 
> In the future, it would probably be better to allow the user to specify an 
> integer ratio for the notification rather than relying on arbitrarily 
> specified levels.

Does the customer need to differentiate the two levels (medium and high),
or the customer only interested in this (80%) specific level?

In the latter case, instead of adding a new level I would vote for adding
a [sysfs] knob for modifying medium level's threshold.

Thanks,

Anton
--
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/2] perf-report: add --max-stack option to limit callchain stack scan

[David Ahern]

On 10/16/13 1:59 PM, Waiman Long wrote:

This patch adds a new --max-stack option to perf-report to limit the
depth of callchain stack data to look at to reduce the time it takes
for perf-report to finish its processing. It trades the presence of
trailing stack information with faster speed.


I like the patch. I have a similar option in my perf-sched-timehist 
command, and I have a patch somewhere for perf-script.


It would be even better to pass this arg kernel side and limit the stack 
depth at data collection time.


---8<---


diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 72eae74..d90d04a 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -37,6 +37,12 @@

  #include 

+/*
+ * 2-level stringification macro to enable stringification of macro value
+ * */
+#define__to_string(x)  #x
+#defineSTRINGIFY(x)__to_string(x)


These 2 lines should be somewhere else -- like util/util.h

---8<---


diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 2122141..2725aca 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -771,7 +771,8 @@ static void perf_event__process_sample(struct perf_tool 
*tool,
sample->callchain) {
err = machine__resolve_callchain(machine, evsel,
 al.thread, sample,
-&parent, &al);
+&parent, &al,
+PERF_MAX_STACK_DEPTH);
if (err)
return;
}


Why not add the option to perf-top as well? copy-paste.

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/

Re: [PATCH 01/28] dmaengine: use DMA_COMPLETE for dma completion status

[Vinod Koul]

On Wed, Oct 16, 2013 at 11:45:48AM -0700, Dan Williams wrote:
> On Wed, Oct 16, 2013 at 11:29 AM, Guennadi Liakhovetski
> >
> > Doesn't this break kernel compilation for a total of 27 commits? Or am I
> > missing anything?
> 
> Yes, I think at the start DMA_COMPLETE should just be a alias for
> DMA_SUCCESS, then after all the driver renames are in delete
> DMA_SUCCESS.
Oops, taht was bad of me. ffixes in v2 and sending patch 29 for removal case

--

>From 7768309422a1345d32857974fe8b57805adfd561 Mon Sep 17 00:00:00 2001
From: Vinod Koul 
Date: Wed, 16 Oct 2013 13:29:02 +0530
Subject: [PATCH] dmaengine: use DMA_COMPLETE for dma completion status

the DMA_SUCCESS is a misnomer as dmaengine indicates the transfer is complete 
and
gives no guarantee of the transfer success. Hence we should use DMA_COMPLTE
instead of DMA_SUCCESS

Signed-off-by: Vinod Koul 
---
 drivers/dma/dmaengine.c   |2 +-
 include/linux/dmaengine.h |   13 +++--
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 9162ac8..81d8765 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -1062,7 +1062,7 @@ dma_wait_for_async_tx(struct dma_async_tx_descriptor *tx)
unsigned long dma_sync_wait_timeout = jiffies + msecs_to_jiffies(5000);
 
if (!tx)
-   return DMA_SUCCESS;
+   return DMA_COMPLETE;
 
while (tx->cookie == -EBUSY) {
if (time_after_eq(jiffies, dma_sync_wait_timeout)) {
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 0bc7275..683c380 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -45,16 +45,17 @@ static inline int dma_submit_error(dma_cookie_t cookie)
 
 /**
  * enum dma_status - DMA transaction status
- * @DMA_SUCCESS: transaction completed successfully
+ * @DMA_COMPLETE: transaction completed
  * @DMA_IN_PROGRESS: transaction not yet processed
  * @DMA_PAUSED: transaction is paused
  * @DMA_ERROR: transaction failed
  */
 enum dma_status {
-   DMA_SUCCESS,
+   DMA_COMPLETE,
DMA_IN_PROGRESS,
DMA_PAUSED,
DMA_ERROR,
+   DMA_SUCCESS,
 };
 
 /**
@@ -979,10 +980,10 @@ static inline enum dma_status 
dma_async_is_complete(dma_cookie_t cookie,
 {
if (last_complete <= last_used) {
if ((cookie <= last_complete) || (cookie > last_used))
-   return DMA_SUCCESS;
+   return DMA_COMPLETE;
} else {
if ((cookie <= last_complete) && (cookie > last_used))
-   return DMA_SUCCESS;
+   return DMA_COMPLETE;
}
return DMA_IN_PROGRESS;
 }
@@ -1013,11 +1014,11 @@ static inline struct dma_chan *dma_find_channel(enum 
dma_transaction_type tx_typ
 }
 static inline enum dma_status dma_sync_wait(struct dma_chan *chan, 
dma_cookie_t cookie)
 {
-   return DMA_SUCCESS;
+   return DMA_COMPLETE;
 }
 static inline enum dma_status dma_wait_for_async_tx(struct 
dma_async_tx_descriptor *tx)
 {
-   return DMA_SUCCESS;
+   return DMA_COMPLETE;
 }
 static inline void dma_issue_pending_all(void)
 {
-- 
1.7.0.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] n_gsm: race between ld close and gsmtty open

[channing]

ttyA has ld associated to n_gsm, when ttyA is closing, it triggers
to release gsmttyB's ld data dlci[B], then race would happen if gsmttyB
is opening in parallel.

Here are some of race cases we found recently in test:

CASE #1

releasing dlci[B] race with gsmtty_install(gsmttyB), then panic
in gsmtty_open(gsmttyB), as below:

 tty_release(ttyA)  tty_open(gsmttyB)
 |   |
   -   gsmtty_install(gsmttyB)
 |   |
   -gsm_dlci_alloc(gsmttyB) => alloc dlci[B]
 tty_ldisc_release(ttyA)   -
 |   |
 gsm_dlci_release(dlci[B]) -
 |   |
 gsm_dlci_free(dlci[B])-
 |   |
   -   gsmtty_open(gsmttyB)

 gsmtty_open()
 {
 struct gsm_dlci *dlci = tty->driver_data; => here it uses dlci[B]
 ...
 }

 In gsmtty_open(gsmttyA), it uses dlci[B] which was release, so hit a panic.
=

CASE #2
=
releasing dlci[0] race with gsmtty_install(gsmttyB), then panic
in gsmtty_open(), as below:

 tty_release(ttyA)  tty_open(gsmttyB)
 |   |
   -   gsmtty_install(gsmttyB)
 |   |
   -gsm_dlci_alloc(gsmttyB) => alloc dlci[B]
 |   |
   - gsmtty_open(gsmttyB) fail
 |   |
   -   tty_release(gsmttyB)
 |   |
   -   gsmtty_close(gsmttyB)
 |   |
   -gsmtty_detach_dlci(dlci[B])
 |   |
   - dlci_put(dlci[B])
 |   |
 tty_ldisc_release(ttyA)   -
 |   |
 gsm_dlci_release(dlci[0]) -
 |   |
 gsm_dlci_free(dlci[0])-
 |   |
   - dlci_put(dlci[0])

 In gsmtty_detach_dlci(dlci[B]), it tries to use dlci[0] which was released,
 then hit panic.
=

IMHO, n_gsm tty operations would refer released ldisc,  as long as
gsm_dlci_release() has chance to release ldisc data when some gsmtty operations
are not completed..

This patch is try to avoid it by:

1) in n_gsm driver, use a global gsm spin lock to avoid gsm_dlci_release() run 
in
parallel with gsmtty_install();

2) Increase dlci's ref count in gsmtty_install() instead of in gsmtty_open(), 
the
purpose is to prevent gsm_dlci_release() releasing dlci after gsmtty_install()
allocats dlci but before gsmtty_open increases dlci's ref count;

3) Decrease dlci's ref count in gsmtty_remove(), which is a tty framework api, 
and
this is the opposite process of step 2).

Signed-off-by: Chao Bi 
---
 drivers/tty/n_gsm.c |   37 +++--
 1 files changed, 27 insertions(+), 10 deletions(-)

diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index c0f76da..41ef7d7 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -2054,9 +2054,11 @@ void gsm_cleanup_mux(struct gsm_mux *gsm)
dlci->state == DLCI_CLOSED);
}
/* Free up any link layer users */
+   spin_lock(&gsm->lock);
for (i = 0; i < NUM_DLCI; i++)
if (gsm->dlci[i])
gsm_dlci_release(gsm->dlci[i]);
+   spin_unlock(&gsm->lock);
/* Now wipe the queues */
list_for_each_entry_safe(txq, ntxq, &gsm->tx_list, list)
kfree(txq);
@@ -2909,23 +2911,33 @@ static int gsmtty_install(struct tty_driver *driver, 
struct tty_struct *tty)
This is ok from a locking
perspective as we don't have to worry about this
if DLCI0 is lost */
-   if (gsm->dlci[0] && gsm->dlci[0]->state != DLCI_OPEN)
+   spin_lock(&gsm->lock);
+   if (gsm->dlci[0] && gsm->dlci[0]->state != DLCI_OPEN) {
+   spin_unlock(&gsm->lock);
return -EL2NSYNC;
+   }
dlci = gsm->dlci[line];
if (dlci == NULL) {
alloc = true;
dlci = gsm_dlci_alloc(gsm, line);
}
-   if (dlci == NULL)
+   if (dlci == NULL) {
+   spin_unlock(&gsm->lock);
return -ENOMEM;
+   }
ret = tty_port_install(&dlci->port, driver, tty);
if (ret) {
  

[PATCH] gpiolib: append SFI helpers for GPIO API

[David Cohen]

From: Andy Shevchenko 

To support some (legacy) firmwares and platforms let's make life easier for
their customers.

Signed-off-by: Andy Shevchenko 
Cc: Kuppuswamy Sathyanarayanan 
Cc: David Cohen 
Cc: Linus Walleij 
Cc: Len Brown 
---
 drivers/gpio/Kconfig   |  4 +++
 drivers/gpio/Makefile  |  1 +
 drivers/gpio/gpiolib-sfi.c | 76 ++
 drivers/sfi/sfi_core.c |  7 +
 include/linux/sfi_gpio.h   | 27 
 5 files changed, 115 insertions(+)
 create mode 100644 drivers/gpio/gpiolib-sfi.c
 create mode 100644 include/linux/sfi_gpio.h

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 3471962..3fa2a0d 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -51,6 +51,10 @@ config OF_GPIO
def_bool y
depends on OF
 
+config GPIO_SFI
+   def_bool y
+   depends on SFI
+
 config GPIO_ACPI
def_bool y
depends on ACPI
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index f951866..d548ff3 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -5,6 +5,7 @@ ccflags-$(CONFIG_DEBUG_GPIO)+= -DDEBUG
 obj-$(CONFIG_GPIO_DEVRES)  += devres.o
 obj-$(CONFIG_GPIOLIB)  += gpiolib.o
 obj-$(CONFIG_OF_GPIO)  += gpiolib-of.o
+obj-$(CONFIG_GPIO_SFI) += gpiolib-sfi.o
 obj-$(CONFIG_GPIO_ACPI)+= gpiolib-acpi.o
 
 # Device drivers. Generally keep list sorted alphabetically
diff --git a/drivers/gpio/gpiolib-sfi.c b/drivers/gpio/gpiolib-sfi.c
new file mode 100644
index 000..2f15a81
--- /dev/null
+++ b/drivers/gpio/gpiolib-sfi.c
@@ -0,0 +1,76 @@
+/*
+ * SFI helpers for GPIO API
+ *
+ * Copyright (C) 2013, Intel Corporation
+ * Author: Andy Shevchenko 
+ *
+ * Based on work done for Intel MID platforms (mrst.c)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#define pr_fmt(fmt) "SFI: GPIO: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct sfi_gpio_table_entry *sfi_gpio_table;
+static int sfi_gpio_num_entry;
+
+int sfi_get_gpio_by_name(const char *name)
+{
+   struct sfi_gpio_table_entry *pentry = sfi_gpio_table;
+   int i;
+
+   if (!pentry)
+   return -1;
+
+   for (i = 0; i < sfi_gpio_num_entry; i++, pentry++) {
+   if (!strncmp(name, pentry->pin_name, SFI_NAME_LEN))
+   return pentry->pin_no;
+   }
+
+   return -1;
+}
+EXPORT_SYMBOL_GPL(sfi_get_gpio_by_name);
+
+static int __init sfi_gpio_parse(struct sfi_table_header *table)
+{
+   struct sfi_table_simple *sb = (struct sfi_table_simple *)table;
+   struct sfi_gpio_table_entry *pentry;
+   int num, i;
+
+   if (sfi_gpio_table)
+   return 0;
+
+   num = SFI_GET_NUM_ENTRIES(sb, struct sfi_gpio_table_entry);
+   pentry = (struct sfi_gpio_table_entry *)sb->pentry;
+
+   sfi_gpio_table = kmalloc(num * sizeof(*pentry), GFP_KERNEL);
+   if (!sfi_gpio_table)
+   return -ENOMEM;
+
+   memcpy(sfi_gpio_table, pentry, num * sizeof(*pentry));
+   sfi_gpio_num_entry = num;
+
+   pr_debug("Pin info:\n");
+   for (i = 0; i < num; i++, pentry++)
+   pr_debug("[%2d] chip = %16.16s, name = %16.16s, pin=%d\n", i,
+pentry->controller_name, pentry->pin_name,
+pentry->pin_no);
+
+   return 0;
+}
+
+int __init sfi_gpio_init(void)
+{
+   return sfi_table_parse(SFI_SIG_GPIO, NULL, NULL, sfi_gpio_parse);
+}
diff --git a/drivers/sfi/sfi_core.c b/drivers/sfi/sfi_core.c
index 296db7a..2828da0 100644
--- a/drivers/sfi/sfi_core.c
+++ b/drivers/sfi/sfi_core.c
@@ -67,6 +67,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "sfi_core.h"
@@ -512,6 +513,12 @@ void __init sfi_init_late(void)
syst_va = sfi_map_memory(syst_pa, length);
 
sfi_acpi_init();
+
+   /*
+* Parsing GPIO table first, since the DEVS table will need this table
+* to map the pin name to the actual pin.
+*/
+   sfi_gpio_init();
 }
 
 /*
diff --git a/include/linux/sfi_gpio.h b/include/linux/sfi_gpio.h
new file mode 100644
index 000..ef7e497
--- /dev/null
+++ b/include/linux/sfi_gpio.h
@@ -0,0 +1,27 @@
+#ifndef _LINUX_SFI_GPIO_H_
+#define _LINUX_SFI_GPIO_H_
+
+#include 
+#include 
+#include 
+
+#ifdef CONFIG_GPIO_SFI
+
+int sfi_get_gpio_by_name(const char *name);
+int __init sfi_gpio_init(void);
+
+#else /* CONFIG_GPIO_SFI */
+
+static inline int sfi_get_gpio_by_name(const char *name);
+{
+   return -1;
+}
+
+static inline int __init sfi_gpio_init(void)
+{
+   return -ENODEV;
+}
+
+#endif /* CONFIG_GPIO_SFI */
+
+#endif /* _LINUX_SFI_GPIO_H_ */
-- 
1.8.4.rc3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord

Re: [PATCH v2 3/9] bitops: Introduce a more generic BITMASK macro

[Joe Perches]

On Wed, 2013-10-16 at 10:56 -0400, Chen, Gong wrote:
> GENMASK is used to create a contiguous bitmask([hi:lo]). It is
> implemented twice in current kernel. One is in EDAC driver, the other
> is in SiS/XGI FB driver. Move it to a more generic place for other
> usage.
[]
> diff --git a/include/linux/bitops.h b/include/linux/bitops.h
[]
> @@ -10,6 +10,14 @@
>  #define BITS_TO_LONGS(nr)DIV_ROUND_UP(nr, BITS_PER_BYTE * sizeof(long))
>  #endif
>  
> +/*
> + * Create a contiguous bitmask starting at bit position @l and ending at
> + * position @h. For example
> + * GENMASK_ULL(39, 21) gives us the 64bit vector 0x00e0.

ull

> + */
> +#define GENMASK(h, l)(((U32_C(1) << ((h) - (l) + 1)) - 1) << 
> (l))
> +#define GENMASK_ULL(h, l)(((U64_C(1) << ((h) - (l) + 1)) - 1) << (l))


Maybe add a

BUILD_BUG_ON(__builtin_constant_p(l) && __builtin_constant_p(h) && \
 (h) < (l))

--
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] sfi: fix compiler warnings

[David Cohen]

From: Andy Shevchenko 

drivers/sfi/sfi_core.c:164:26: warning: no previous prototype for 
‘sfi_map_table’ [-Wmissing-prototypes]
drivers/sfi/sfi_core.c:192:6: warning: no previous prototype for 
‘sfi_unmap_table’ [-Wmissing-prototypes]

Signed-off-by: Andy Shevchenko 
Cc: Kuppuswamy Sathyanarayanan 
Cc: David Cohen 
Cc: Len Brown 
---
 drivers/sfi/sfi_core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/sfi/sfi_core.c b/drivers/sfi/sfi_core.c
index 1e824fb..296db7a 100644
--- a/drivers/sfi/sfi_core.c
+++ b/drivers/sfi/sfi_core.c
@@ -161,7 +161,7 @@ static int sfi_verify_table(struct sfi_table_header *table)
  * Check for common case that we can re-use mapping to SYST,
  * which requires syst_pa, syst_va to be initialized.
  */
-struct sfi_table_header *sfi_map_table(u64 pa)
+static struct sfi_table_header *sfi_map_table(u64 pa)
 {
struct sfi_table_header *th;
u32 length;
@@ -189,7 +189,7 @@ struct sfi_table_header *sfi_map_table(u64 pa)
  * Undoes effect of sfi_map_table() by unmapping table
  * if it did not completely fit on same page as SYST.
  */
-void sfi_unmap_table(struct sfi_table_header *th)
+static void sfi_unmap_table(struct sfi_table_header *th)
 {
if (!TABLE_ON_PAGE(syst_va, th, th->len))
sfi_unmap_memory(th, TABLE_ON_PAGE(th, th, th->len) ?
-- 
1.8.4.rc3

--
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/6] rcu: Create rcu_sync infrastructure

[Lai Jiangshan]

On 10/08/2013 06:25 PM, Peter Zijlstra wrote:
> From: Oleg Nesterov 
> 
> It is functionally equivalent to
> 
> struct rcu_sync_struct {
> atomic_t counter;
> };
> 
> static inline bool rcu_sync_is_idle(struct rcu_sync_struct *xxx)
> {
> return atomic_read(&xxx->counter) == 0;
> }
> 
> static inline void rcu_sync_enter(struct rcu_sync_struct *xxx)
> {
> atomic_inc(&xxx->counter);
> synchronize_sched();
> }
> 
> static inline void rcu_sync_enter(struct rcu_sync_struct *xxx)
> {
> synchronize_sched();
> atomic_dec(&xxx->counter);
> }
> 
> except: it records the state and synchronize_sched() is only called by
> rcu_sync_enter() and only if necessary.
> 
> Signed-off-by: Oleg Nesterov 
> Reviewed-by: Paul McKenney 
> Signed-off-by: Peter Zijlstra 
> Link: http://lkml.kernel.org/r/20130929183634.ga15...@redhat.com
> ---
>  include/linux/rcusync.h |   64 
>  kernel/Makefile |3 -
>  kernel/rcusync.c|  108 
> 
>  3 files changed, 174 insertions(+), 1 deletion(-)
> 
> --- /dev/null
> +++ b/include/linux/rcusync.h
> @@ -0,0 +1,64 @@
> +#ifndef _LINUX_RCUSYNC_H_
> +#define _LINUX_RCUSYNC_H_
> +
> +#include 
> +#include 
> +
> +struct rcu_sync_struct {
> + int gp_state;
> + int gp_count;
> + wait_queue_head_t   gp_wait;
> +
> + int cb_state;
> + struct rcu_head cb_head;
> +
> + void (*sync)(void);
> + void (*call)(struct rcu_head *, void (*)(struct rcu_head *));
> +};
> +
> +#define ___RCU_SYNC_INIT(name)   
> \
> + .gp_state = 0,  \
> + .gp_count = 0,  \
> + .gp_wait = __WAIT_QUEUE_HEAD_INITIALIZER(name.gp_wait), \
> + .cb_state = 0
> +
> +#define __RCU_SCHED_SYNC_INIT(name) {
> \
> + ___RCU_SYNC_INIT(name), \
> + .sync = synchronize_sched,  \
> + .call = call_rcu_sched, \
> +}
> +
> +#define __RCU_BH_SYNC_INIT(name) {   \
> + ___RCU_SYNC_INIT(name), \
> + .sync = synchronize_rcu_bh, \
> + .call = call_rcu_bh,\
> +}
> +
> +#define __RCU_SYNC_INIT(name) {  
> \
> + ___RCU_SYNC_INIT(name), \
> + .sync = synchronize_rcu,\
> + .call = call_rcu,   \
> +}
> +
> +#define DEFINE_RCU_SCHED_SYNC(name)  \
> + struct rcu_sync_struct name = __RCU_SCHED_SYNC_INIT(name)
> +
> +#define DEFINE_RCU_BH_SYNC(name) \
> + struct rcu_sync_struct name = __RCU_BH_SYNC_INIT(name)
> +
> +#define DEFINE_RCU_SYNC(name)
> \
> + struct rcu_sync_struct name = __RCU_SYNC_INIT(name)
> +
> +static inline bool rcu_sync_is_idle(struct rcu_sync_struct *rss)
> +{
> + return !rss->gp_state; /* GP_IDLE */
> +}

Hi, All

We may need to use ACCESS_ONCE() here to avoid the compiler access it 
multi-times.

it would be better: return ACCESS_ONCE(rss->gp_state) == GP_IDLE;


-my comment continues until it reaches a "Thanks".-

> +
> +enum rcu_sync_type { RCU_SYNC, RCU_SCHED_SYNC, RCU_BH_SYNC };
> +
> +extern void rcu_sync_init(struct rcu_sync_struct *, enum rcu_sync_type);
> +extern void rcu_sync_enter(struct rcu_sync_struct *);
> +extern void rcu_sync_exit(struct rcu_sync_struct *);
> +
> +#endif /* _LINUX_RCUSYNC_H_ */
> +
> --- a/kernel/Makefile
> +++ b/kernel/Makefile
> @@ -10,7 +10,8 @@ obj-y = fork.o exec_domain.o panic.o
>   kthread.o wait.o sys_ni.o posix-cpu-timers.o mutex.o \
>   hrtimer.o rwsem.o nsproxy.o srcu.o semaphore.o \
>   notifier.o ksysfs.o cred.o reboot.o \
> - async.o range.o groups.o lglock.o smpboot.o
> + async.o range.o groups.o lglock.o smpboot.o \
> + rcusync.o
>  
>  ifdef CONFIG_FUNCTION_TRACER
>  # Do not trace debug files and internal ftrace files
> --- /dev/null
> +++ b/kernel/rcusync.c
> @@ -0,0 +1,108 @@
> +
> +#include 
> +#include 
> +
> +enum { GP_IDLE = 0, GP_PENDING, GP_PASSED };
> +enum { CB_IDLE = 0, CB_PENDING, CB_REPLAY };
> +
> +#define  rss_lockgp_wait.lock
> +
> +void rcu_sync_init(struct rcu_sync_struct *rss, enum rcu_sync_type type)
> +{
> + memset(rss, 0, sizeof(*rss));
> + ini

Re: [PATCH] ACPI/Power: Check physical device's runtime pm status before requesting to resume it

[Lan Tianyu]

On 2013年10月17日 09:02, Lan Tianyu wrote:
> On 2013年10月16日 20:42, Rafael J. Wysocki wrote:
>> On Wednesday, October 16, 2013 05:26:21 PM Lan Tianyu wrote:
>>> This is a multi-part message in MIME format.
>>> --090400010209000300030201
>>> Content-Type: text/plain; charset=UTF-8
>>> Content-Transfer-Encoding: 8bit
>>>
>>> On 10/16/2013 05:22 AM, Rafael J. Wysocki wrote:
 On Tuesday, October 15, 2013 04:58:28 PM Lan Tianyu wrote:
> On 2013年10月11日 19:19, Rafael J. Wysocki wrote:
>> On Friday, October 11, 2013 04:16:25 PM tianyu@intel.com
>> wrote:
>>> From: Lan Tianyu 
>>>
>>> Currently, when one power resource is turned on, devices owning
>>> it will be requested to resume regardless of their runtime pm
>>> status. ACPI power resource maybe turn on in some devices'
>>> runtime pm resume callback(E.G, usb port) while turning on the
>>> power resource will trigger one new resume request of the
>>> device. It causes infinite loop between resume and suspend.
>>> This has happened on clearing usb port's PM Qos NO_POWER_OFF
>>> flag twice. This patch is to add check of physical device's
>>> runtime pm status and request resume if the device is
>>> suspended.
>>>
>>> Signed-off-by: Lan Tianyu  ---
>>> drivers/acpi/power.c | 6 -- 1 file changed, 4
>>> insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c index
>>>  0dbe5cd..228c138 100644 --- a/drivers/acpi/power.c +++
>>> b/drivers/acpi/power.c @@ -250,8 +250,10 @@ static void
>>> acpi_power_resume_dependent(struct work_struct *work)
>>>
>>> mutex_lock(&adev->physical_node_lock);
>>>
>>> -   list_for_each_entry(pn, &adev->physical_node_list, node) -
>>> pm_request_resume(pn->dev); +   list_for_each_entry(pn,
>>> &adev->physical_node_list, node) { +if
>>> (pm_runtime_suspended(pn->dev)) + pm_request_resume(pn->dev);
>>> + }
>>
>> This is racy, because the status may change right after you check
>> it and before you call pm_request_resume().
>
> Yes, the runtime status may be changed just after the check.
>
>>
>> Besides, pm_request_resume() checks the status of the device and
>>  won't try to resume it if it is not suspended.
>>
>
> For this issue, usb port is in the RPM_SUSPENDING state when
> pm_request_resume() is called.

 Why exactly does that happen?

> The deferred_resume will be set to true during this procedure and
> trigger resume after finishing suspend. USB port runtime resume
> callback will turn on its power resource again and the work of
> acpi_power_resume_dependent() is scheduled. Because the usb port's
>  usage count remains zero, it's to be suspended soon. When
> pm_request_resume() of acpi_power_resume_dependent() is called, the
> usb port is always in the PRM_SUSPENDING. Fall in the loop of
> suspend and resume.
>
> How about running acpi_power_dependent when turning on power
> resource rather than scheduling a work to run it?

 Is this actually going to help?  Even if
 acpi_power_resume_dependent() is run synchronously from within the
 resume callback, it will still see RPM_SUSPENDING as the device's
 status, won't it?

> After this, pm_request_resume() can check device's right status
> just after turning on power resource.

 The status doesn't change until the .runtime_suspend() callback
 returns and running pm_request_resume() syncrhonously from that
 callback for the device being suspended just plain doesn't make
 sense.


 Can you please explain to me how this is possible that the USB port's
 power resource is turned "on" while the port is RPM_SUSPENDING?

>>> [This mail seems not to be sent to maillist. So resend. Try again
>>> Sorry for noise]
>>>
>>>
>>> Hi Rafael:
>>>
>>> No, I mean the acpi_power_resume_dependent() is running while the port's
>>> status is RPM_SUSPENDING. It runs from a work item and turning on power
>>> resource adds the work to workqueue. There is a timeslot between running
>>> acpi_power_resume_dependent() and turning on power resource. In the
>>> timeslot, the device runtime pm status maybe change.
>>>
>>> In this case, changing PM Qos flag will do pm_runtime_get_sync and
>>> pm_runtime_put usb port. The usb port is without device attached and so
>>> it will be resumed and suspended soon during changing PM Qos flag.
>>>
>>> Resume callback turns on power resource if NO_POWER_OFF flag has been
>>> cleared and add the work of acpi_power_resume_dependent() to
>>> workqueue. After resume, the usb port will be suspended while the
>>> acpi_power_resume_dependent() is running. pm_request_resume() gets
>>> RPM_SUSPENDING as the usb port's runtime status and set the
>>> deferred_resume of usb port.
>>>
>>> After suspend, usb port will be 

Re: [Bug] 12.864681 BUG: lock held when returning to user space!

[vaughan]

On 10/17/2013 06:41 AM, Douglas Gilbert wrote:
> That seems to be the case. Vaughan acknowledged the
> problem and forwarded it to me 8 days ago. Yes, it
> seems to be a "no-no" to hold a any kernel semaphore
> when returning to the user space; in this case from
> sg_open(). I was hoping a revised patch might
> appear from Vaughan but to date that has not been
> the case. So with only a few weeks to go before
> lk 3.12 is released, reverting the whole 4 patches
> in that series seems to be the safest course.
>
> Also without a new patch from Vaughan in the next few
> weeks he may also miss the opportunity of getting
> his improved O_EXCL logic into the lk 3.13 series.
>
>
> Thinking about how to solve this problem: a field could
> be added to 'struct sg_device' with one of three states:
> no_opens, non_excl_opens and excl_open. It could be
> manipulated by sg_open() and sg_release() like a
> read-write semaphore. And the faulty 'struct
> rw_semaphore o_sem' in sg_device could be replaced by a
> normal semaphore to protect the manipulation of the new
> three-state field.
> And the new three-state field would replace (or expand)
the 'char exclude' field in struct sg_device .
>
> Doug Gilbert
Hi Doug,

Thanks for providing advice on how to fix this.
However, it seems be still awkward somehow. We have to
1. hold a lock (maybe sg_index_lock or a new one)
2. check
   a) the new three-state field;
   b) if sfp list is empty;
   c) sdp->detached field;
if either condition fails, we may link the open process into o_excl_wait
queue and need wakeup.
if satisfied, we go on.
3. then we release at least sg_index_lock to malloc a new sfp and
initialize.
4. try to acquire sg_index_lock again and add this sfp into sfd_siblings
list if possible.  <== We still have to check at least sdp->detached field
5. update three-state field to reflect the result of Step 4, and wake up
processes waiting in o_excl_wait.

This uncomfortable is introduced by releasing the sg_index_lock in the
middle of check->malloc->add the new sfp struct.

I wanna ask if it is possible to split the sg_add_sfp() into two
functions, sg_init_sfp() and sg_add_sfp2(). We can do all initialize
work in sg_init_sfp()
without any lock and let sg_add_sfp2() only serve lock-check-add in one
way. It seems more convenient for me to understand.
But there is still some questions on this approach:
1. memory consume can be very large if lots of sg_init_sfp in the same time;
2. some field are initialized according to the fields of scsi device sdp
points to, such as low_dma, sg_tablesize, max_sector, phys_segs.
I know scsi_device_get() would keep the underlying scsi_device
alive, however would these fields change in the gap of our initialize
and add?
The relationship of sg_device and scsi_device like above said
confuse me somehow...

Thanks,
Vaughan
--
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 3/9] bitops: Introduce a more generic BITMASK macro

[Chen Gong]

On Wed, Oct 16, 2013 at 02:02:21PM -0300, Mauro Carvalho Chehab wrote:
> Date: Wed, 16 Oct 2013 14:02:21 -0300
> From: Mauro Carvalho Chehab 
> To: "Chen, Gong" 
> Cc: tony.l...@intel.com, b...@alien8.de, j...@perches.com,
>  naveen.n@linux.vnet.ibm.com, aroza...@redhat.com,
>  linux-a...@vger.kernel.org, linux-kernel@vger.kernel.org, Thomas
>  Winischhofer , Jean-Christophe Plagniol-Villard
>  , Tomi Valkeinen 
> Subject: Re: [PATCH v2 3/9] bitops: Introduce a more generic BITMASK macro
> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; x86_64-redhat-linux-gnu)
> 
> Em Wed, 16 Oct 2013 10:56:00 -0400
> "Chen, Gong"  escreveu:
> 
> > GENMASK is used to create a contiguous bitmask([hi:lo]). It is
> > implemented twice in current kernel. One is in EDAC driver, the other
> > is in SiS/XGI FB driver. Move it to a more generic place for other
> > usage.
> > 
> > Signed-off-by: Chen, Gong 
> > Cc: Borislav Petkov 
> > Cc: Thomas Winischhofer 
> > Cc: Jean-Christophe Plagniol-Villard 
> > Cc: Tomi Valkeinen 
> 
> Acked-by: Mauro Carvalho Chehab 
> 
> Btw, there's another incarnation of it at sb_edac.c (GET_BITFIELD).
> It could make sense to also replace it by the newly bitops.h macro.
> 
> Regards,
> Mauro

Aha, I will update it in the next version.


signature.asc
Description: Digital signature

[PATCH] fuelguage: max17042: Support regmap to access device's registers.

[Jonghwa Lee]

This patch makes max17042 fuelguage driver uses regmap API to access
its device's registers.

It's based on linux-next.

Signed-off-by: Jonghwa Lee 
Signed-off-by: Myungjoo Ham 
---
 drivers/power/max17042_battery.c |  357 +++---
 1 file changed, 174 insertions(+), 183 deletions(-)

diff --git a/drivers/power/max17042_battery.c b/drivers/power/max17042_battery.c
index d664ef5..0382cb5 100644
--- a/drivers/power/max17042_battery.c
+++ b/drivers/power/max17042_battery.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Status register bits */
 #define STATUS_POR_BIT (1 << 1)
@@ -67,6 +68,7 @@
 
 struct max17042_chip {
struct i2c_client *client;
+   struct regmap *regmap;
struct power_supply battery;
enum max170xx_chip_type chip_type;
struct max17042_platform_data *pdata;
@@ -74,35 +76,6 @@ struct max17042_chip {
intinit_complete;
 };
 
-static int max17042_write_reg(struct i2c_client *client, u8 reg, u16 value)
-{
-   int ret = i2c_smbus_write_word_data(client, reg, value);
-
-   if (ret < 0)
-   dev_err(&client->dev, "%s: err %d\n", __func__, ret);
-
-   return ret;
-}
-
-static int max17042_read_reg(struct i2c_client *client, u8 reg)
-{
-   int ret = i2c_smbus_read_word_data(client, reg);
-
-   if (ret < 0)
-   dev_err(&client->dev, "%s: err %d\n", __func__, ret);
-
-   return ret;
-}
-
-static void max17042_set_reg(struct i2c_client *client,
-struct max17042_reg_data *data, int size)
-{
-   int i;
-
-   for (i = 0; i < size; i++)
-   max17042_write_reg(client, data[i].addr, data[i].data);
-}
-
 static enum power_supply_property max17042_battery_props[] = {
POWER_SUPPLY_PROP_PRESENT,
POWER_SUPPLY_PROP_CYCLE_COUNT,
@@ -125,96 +98,98 @@ static int max17042_get_property(struct power_supply *psy,
 {
struct max17042_chip *chip = container_of(psy,
struct max17042_chip, battery);
+   struct regmap *map = chip->regmap;
int ret;
+   u32 data;
 
if (!chip->init_complete)
return -EAGAIN;
 
switch (psp) {
case POWER_SUPPLY_PROP_PRESENT:
-   ret = max17042_read_reg(chip->client, MAX17042_STATUS);
+   ret = regmap_read(map, MAX17042_STATUS, &data);
if (ret < 0)
return ret;
 
-   if (ret & MAX17042_STATUS_BattAbsent)
+   if (data & MAX17042_STATUS_BattAbsent)
val->intval = 0;
else
val->intval = 1;
break;
case POWER_SUPPLY_PROP_CYCLE_COUNT:
-   ret = max17042_read_reg(chip->client, MAX17042_Cycles);
+   ret = regmap_read(map, MAX17042_Cycles, &data);
if (ret < 0)
return ret;
 
-   val->intval = ret;
+   val->intval = data;
break;
case POWER_SUPPLY_PROP_VOLTAGE_MAX:
-   ret = max17042_read_reg(chip->client, MAX17042_MinMaxVolt);
+   ret = regmap_read(map, MAX17042_MinMaxVolt, &data);
if (ret < 0)
return ret;
 
-   val->intval = ret >> 8;
+   val->intval = data >> 8;
val->intval *= 2; /* Units of LSB = 20mV */
break;
case POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN:
if (chip->chip_type == MAX17042)
-   ret = max17042_read_reg(chip->client, MAX17042_V_empty);
+   ret = regmap_read(map, MAX17042_V_empty, &data);
else
-   ret = max17042_read_reg(chip->client, MAX17047_V_empty);
+   ret = regmap_read(map, MAX17047_V_empty, &data);
if (ret < 0)
return ret;
 
-   val->intval = ret >> 7;
+   val->intval = data >> 7;
val->intval *= 1; /* Units of LSB = 10mV */
break;
case POWER_SUPPLY_PROP_VOLTAGE_NOW:
-   ret = max17042_read_reg(chip->client, MAX17042_VCELL);
+   ret = regmap_read(map, MAX17042_VCELL, &data);
if (ret < 0)
return ret;
 
-   val->intval = ret * 625 / 8;
+   val->intval = data * 625 / 8;
break;
case POWER_SUPPLY_PROP_VOLTAGE_AVG:
-   ret = max17042_read_reg(chip->client, MAX17042_AvgVCELL);
+   ret = regmap_read(map, MAX17042_AvgVCELL, &data);
if (ret < 0)
return ret;
 
-   val->intval = ret * 625 / 8;
+   val->intval = data * 625 / 8;
break;
case POWER_SUPPLY_PROP_VOLTAGE_OCV:
-   ret = max17042_read_reg(chip->client, MAX17042_OCVInternal);
+  

[PATCH v8 12/12] intel_mid: move board related codes to their own platform_.* files

[David Cohen]

As Intel rolling out more SoC's after Moorestown, we need to
re-structure the code in a way that is backward compatible and easy to
expand. This patch implements a flexible way to support multiple boards
and devices.

This patch does not add any new functional support. It just refactors
the existing code to increase the modularity and decrease the code
duplication for supporting multiple soc's and boards.

Currently intel-mid.c has both board and soc related code in one file.
This patch moves the board related code to new files and let linker
script to create SFI devite table following this:

1. Move the SFI device specific code to
   arch/x86/platform/intel-mid/device-libs/platform_.*
   A new device file is added for every supported device. This code will
   get conditionally compiled by using corresponding device driver
   CONFIG option.

2. Move the device_ids location to .x86_intel_mid_dev.init section by
   using new sfi_device() macro.

This patch was based on previous code from Sathyanarayanan Kuppuswamy.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Signed-off-by: David Cohen 
---

Changes from v7 to v8:
 - added missing platform_bma023.c files

 arch/x86/include/asm/intel-mid.h   |  16 +
 arch/x86/platform/intel-mid/Makefile   |   6 +-
 arch/x86/platform/intel-mid/device_libs/Makefile   |  22 ++
 .../intel-mid/device_libs/platform_bma023.c|  20 +
 .../intel-mid/device_libs/platform_emc1403.c   |  41 ++
 .../intel-mid/device_libs/platform_gpio_keys.c |  83 
 .../platform/intel-mid/device_libs/platform_ipc.c  |  68 
 .../platform/intel-mid/device_libs/platform_ipc.h  |  17 +
 .../intel-mid/device_libs/platform_lis331.c|  39 ++
 .../intel-mid/device_libs/platform_max3111.c   |  35 ++
 .../intel-mid/device_libs/platform_max7315.c   |  79 
 .../intel-mid/device_libs/platform_mpu3050.c   |  36 ++
 .../platform/intel-mid/device_libs/platform_msic.c |  87 +
 .../platform/intel-mid/device_libs/platform_msic.h |  19 +
 .../intel-mid/device_libs/platform_msic_audio.c|  47 +++
 .../intel-mid/device_libs/platform_msic_battery.c  |  37 ++
 .../intel-mid/device_libs/platform_msic_gpio.c |  48 +++
 .../intel-mid/device_libs/platform_msic_ocd.c  |  49 +++
 .../device_libs/platform_msic_power_btn.c  |  36 ++
 .../intel-mid/device_libs/platform_msic_thermal.c  |  37 ++
 .../intel-mid/device_libs/platform_pmic_gpio.c |  54 +++
 .../intel-mid/device_libs/platform_tc35876x.c  |  36 ++
 .../intel-mid/device_libs/platform_tca6416.c   |  57 +++
 arch/x86/platform/intel-mid/intel-mid.c| 419 -
 arch/x86/platform/intel-mid/sfi.c  |  14 +-
 include/linux/sfi.h|   3 +
 26 files changed, 976 insertions(+), 429 deletions(-)
 create mode 100644 arch/x86/platform/intel-mid/device_libs/Makefile
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_bma023.c
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_emc1403.c
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_gpio_keys.c
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_ipc.c
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_ipc.h
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_lis331.c
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_max3111.c
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_max7315.c
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_mpu3050.c
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_msic.c
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_msic.h
 create mode 100644 
arch/x86/platform/intel-mid/device_libs/platform_msic_audio.c
 create mode 100644 
arch/x86/platform/intel-mid/device_libs/platform_msic_battery.c
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_msic_gpio.c
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_msic_ocd.c
 create mode 100644 
arch/x86/platform/intel-mid/device_libs/platform_msic_power_btn.c
 create mode 100644 
arch/x86/platform/intel-mid/device_libs/platform_msic_thermal.c
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_pmic_gpio.c
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_tc35876x.c
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_tca6416.c

diff --git a/arch/x86/include/asm/intel-mid.h b/arch/x86/include/asm/intel-mid.h
index 3b0e7a7..2838942 100644
--- a/arch/x86/include/asm/intel-mid.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -12,8 +12,11 @@
 #define _ASM_X86_INTEL_MID_H
 
 #include 
+#include 
 
 extern int intel_mid_pci_init(void);
+extern int get_gpio_by_name(const char *name);
+extern void intel_scu_device_register(struct platform_device *pdev);
 extern int __init sfi_parse_mrtc(struct sfi_table_header *table);
 exte

Re: [PATCH] Release device_hotplug_lock when store_mem_state returns EINVAL

[Yasuaki Ishimatsu]

(2013/10/12 1:31), Toshi Kani wrote:

On Fri, 2013-10-11 at 15:36 +0900, Yasuaki Ishimatsu wrote:

When inserting a wrong value to /sys/devices/system/memory/memoryX/state file,
following messages are shown. And device_hotplug_lock is never released.


[ BUG: lock held when returning to user space! ]
3.12.0-rc4-debug+ #3 Tainted: GW

bash/6442 is leaving the kernel with locks still held!
1 lock held by bash/6442:
  #0:  (device_hotplug_lock){+.+.+.}, at: [] 
lock_device_hotplug_sysfs+0x15/0x50

This issue was introdued by commit fa2be40 (drivers: base: use standard
device online/offline for state change).

This patch releases device_hotplug_lcok when store_mem_state returns EINVAL.

Signed-off-by: Yasuaki Ishimatsu 
CC: Toshi Kani 
CC: Seth Jennings 
CC: Greg Kroah-Hartman 


Good catch!

Reviewed-by: Toshi Kani 


Thank you for your review.

Thanks,
Yasuaki Ishimatsu





Thanks,
-Toshi




--
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: usb_phy_gen: refine conditional declaration of usb_nop_xceiv_register

[Guenter Roeck]

Commit 3fa4d734 (usb: phy: rename nop_usb_xceiv => usb_phy_gen_xceiv)
changed the conditional around the declaration of usb_nop_xceiv_register
from
#if defined(CONFIG_NOP_USB_XCEIV) ||
(defined(CONFIG_NOP_USB_XCEIV_MODULE) && defined(MODULE))
to
#if IS_ENABLED(CONFIG_NOP_USB_XCEIV)

While that looks the same, it is semantically different. The first expression
is true if CONFIG_NOP_USB_XCEIV is built as module and if the including
code is built as module. The second expression is true if code depending on
CONFIG_NOP_USB_XCEIV if built as module or into the kernel.

As a result, the arm:allmodconfig build fails with

arch/arm/mach-omap2/built-in.o: In function `omap3_evm_init':
arch/arm/mach-omap2/board-omap3evm.c:703: undefined reference to
`usb_nop_xceiv_register'

Fix the problem by reverting to the old conditional.

Cc: Josh Boyer 
Signed-off-by: Guenter Roeck 
---
 include/linux/usb/usb_phy_gen_xceiv.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/usb/usb_phy_gen_xceiv.h 
b/include/linux/usb/usb_phy_gen_xceiv.h
index f9a7e7b..11d85b9 100644
--- a/include/linux/usb/usb_phy_gen_xceiv.h
+++ b/include/linux/usb/usb_phy_gen_xceiv.h
@@ -12,7 +12,7 @@ struct usb_phy_gen_xceiv_platform_data {
unsigned int needs_reset:1;
 };
 
-#if IS_ENABLED(CONFIG_NOP_USB_XCEIV)
+#if defined(CONFIG_NOP_USB_XCEIV) || (defined(CONFIG_NOP_USB_XCEIV_MODULE) && 
defined(MODULE))
 /* sometimes transceivers are accessed only through e.g. ULPI */
 extern void usb_nop_xceiv_register(void);
 extern void usb_nop_xceiv_unregister(void);
-- 
1.7.9.7

--
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/6] rcusync: Introduce struct rcu_sync_ops

[Lai Jiangshan]

On 10/08/2013 06:25 PM, Peter Zijlstra wrote:
> From: Oleg Nesterov 
> 
> Add the new struct rcu_sync_ops which holds sync/call methods, and
> turn the function pointers in rcu_sync_struct into an array of struct
> rcu_sync_ops.


Hi, Paul

I think this work should be done in rcupdate.[ch] side by introducing struct 
rcu_flavor.

Thanks,
Lai

> 
> This simplifies the "init" helpers, and this way it is simpler to add
> the new methods we need, especially ifdef'ed.
> 
> Signed-off-by: Peter Zijlstra 
> Link: http://lkml.kernel.org/r/20131005171746.ga17...@redhat.com
> ---
> 
> diff --git a/include/linux/rcusync.h b/include/linux/rcusync.h
> index 7858491..988ec33 100644
> --- a/include/linux/rcusync.h
> +++ b/include/linux/rcusync.h
> @@ -4,6 +4,8 @@
>  #include 
>  #include 
>  
> +enum rcu_sync_type { RCU_SYNC, RCU_SCHED_SYNC, RCU_BH_SYNC };
> +
>  struct rcu_sync_struct {
>   int gp_state;
>   int gp_count;
> @@ -12,53 +14,37 @@ struct rcu_sync_struct {
>   int cb_state;
>   struct rcu_head cb_head;
>  
> - void (*sync)(void);
> - void (*call)(struct rcu_head *, void (*)(struct rcu_head *));
> + enum rcu_sync_type  gp_type;
>  };
>  
> -#define ___RCU_SYNC_INIT(name)   
> \
> - .gp_state = 0,  \
> - .gp_count = 0,  \
> - .gp_wait = __WAIT_QUEUE_HEAD_INITIALIZER(name.gp_wait), \
> - .cb_state = 0
> -
> -#define __RCU_SCHED_SYNC_INIT(name) {
> \
> - ___RCU_SYNC_INIT(name), \
> - .sync = synchronize_sched,  \
> - .call = call_rcu_sched, \
> -}
> -
> -#define __RCU_BH_SYNC_INIT(name) {   \
> - ___RCU_SYNC_INIT(name), \
> - .sync = synchronize_rcu_bh, \
> - .call = call_rcu_bh,\
> -}
> -
> -#define __RCU_SYNC_INIT(name) {  
> \
> - ___RCU_SYNC_INIT(name), \
> - .sync = synchronize_rcu,\
> - .call = call_rcu,   \
> -}
> -
> -#define DEFINE_RCU_SCHED_SYNC(name)  \
> - struct rcu_sync_struct name = __RCU_SCHED_SYNC_INIT(name)
> -
> -#define DEFINE_RCU_BH_SYNC(name) \
> - struct rcu_sync_struct name = __RCU_BH_SYNC_INIT(name)
> -
> -#define DEFINE_RCU_SYNC(name)
> \
> - struct rcu_sync_struct name = __RCU_SYNC_INIT(name)
> -
>  static inline bool rcu_sync_is_idle(struct rcu_sync_struct *rss)
>  {
>   return !rss->gp_state; /* GP_IDLE */
>  }
>  
> -enum rcu_sync_type { RCU_SYNC, RCU_SCHED_SYNC, RCU_BH_SYNC };
> -
>  extern void rcu_sync_init(struct rcu_sync_struct *, enum rcu_sync_type);
>  extern void rcu_sync_enter(struct rcu_sync_struct *);
>  extern void rcu_sync_exit(struct rcu_sync_struct *);
>  
> +#define __RCU_SYNC_INITIALIZER(name, type) { \
> + .gp_state = 0,  \
> + .gp_count = 0,  \
> + .gp_wait = __WAIT_QUEUE_HEAD_INITIALIZER(name.gp_wait), \
> + .cb_state = 0,  \
> + .gp_type = type,\
> + }
> +
> +#define  __DEFINE_RCU_SYNC(name, type)   \
> + struct rcu_sync_struct name = __RCU_SYNC_INITIALIZER(name, type)
> +
> +#define DEFINE_RCU_SYNC(name)\
> + __DEFINE_RCU_SYNC(name, RCU_SYNC)
> +
> +#define DEFINE_RCU_SCHED_SYNC(name)  \
> + __DEFINE_RCU_SYNC(name, RCU_SCHED_SYNC)
> +
> +#define DEFINE_RCU_BH_SYNC(name) \
> + __DEFINE_RCU_SYNC(name, RCU_BH_SYNC)
> +
>  #endif /* _LINUX_RCUSYNC_H_ */
>  
> diff --git a/kernel/rcusync.c b/kernel/rcusync.c
> index f84176a..99051b7 100644
> --- a/kernel/rcusync.c
> +++ b/kernel/rcusync.c
> @@ -1,7 +1,24 @@
> -
>  #include 
>  #include 
>  
> +static const struct {
> + void (*sync)(void);
> + void (*call)(struct rcu_head *, void (*)(struct rcu_head *));
> +} gp_ops[] = {
> + [RCU_SYNC] = {
> + .sync = synchronize_rcu,
> + .call = call_rcu,
> + },
> + [RCU_SCHED_SYNC] = {
> + .sync = synchronize_sched,
> + .call = call_rcu_sched,
> + },
> + [RCU_BH_SYNC] = {
> + .sync = synchronize_rcu_bh,
> + .call = call_rcu_bh,
> + },
> +};
> +
>  enum { GP_IDLE = 0, GP_PENDING, GP_PASSED };
>  enum { CB_I

Re: [PATCH] ASoC: fsl_ssi: Fix irq_of_parse_and_map() return value check

[Guenter Roeck]

On 10/03/2013 08:58 AM, Mark Brown wrote:

On Wed, Oct 02, 2013 at 09:15:22PM -0700, Guenter Roeck wrote:

irq_of_parse_and_map() returns 0 on error, not NO_IRQ.


Applied, thanks.


Hi Mark,

do you plan to send this patch upstream anytime soon ?

It fixes an xtensa build problem, so it would be great if it could find its way 
into 3.13.

Thanks,
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: BUG report about ipt_do_table( )

[Wang, Yalin]

Hi  Will, 

I am happy to notify that our stability test has passed,
And this Crash don't happen again,
So seems this patch work now .

We has merged it into our release SW .
Could I know if this patch will be delivered into kernel
Mainline by you ? 


Thanks again !

-Original Message-
From: Wang, Yalin 
Sent: Friday, October 11, 2013 7:15 PM
To: 'Will Deacon'
Cc: 'linux-arm-msm-ow...@vger.kernel.org'; linux-kernel@vger.kernel.org; Peng, 
Arthur; Zhang, Bojie; Gu, Youcai 1 (EXT); Alevoor, Raghavendra 2
Subject: RE: BUG report about ipt_do_table( )

Hi Will,

Thanks for your clarification .

I have merged the patch,
And need wait some time to get
The test result ,
You know that this BUG is not easy to reproduce, It's very infrequent.
Maybe we need run several times stability test to Make sure the patch works .

I will update to you the result as soon as possible !

Thanks 

-Original Message-
From: Will Deacon [mailto:will.dea...@arm.com]
Sent: Friday, October 11, 2013 7:03 PM
To: Wang, Yalin
Cc: 'linux-arm-msm-ow...@vger.kernel.org'; linux-kernel@vger.kernel.org; Peng, 
Arthur; Zhang, Bojie; Gu, Youcai 1 (EXT); Alevoor, Raghavendra 2
Subject: Re: BUG report about ipt_do_table( )

On Fri, Oct 11, 2013 at 02:50:24AM +0100, Wang, Yalin wrote:
> Hi  Will,

Hello again,

> Maybe I know your meaning ,
> If it use spinlock to protected the shared data, The bug will not 
> happen, because spinlock will Use DSB( )  to sync .

Actually, the dsb is for something else (the sev). It is the smp_mb() call 
which guarantees the ordering of critical sections with respect to spinlock 
operations.

> Unluckily, here, it use a special seqcount_t( ) (see get_counters( )
> function)

Well, there is a comment about a write_lock being held, so you should be ok if 
that's true. The issue I saw was with the newinfo population, as I described in 
my earlier mail.

> To make sure there is no others using the old data, Before release the 
> old data, this is much like RCU Work, but RCU use rcu_assign_pointer(
> ) --> Which use smp_wmb( ) , so it's safe,  am I right ?

RCU is safe. There are *many* weakly ordered architectures on which Linux runs, 
so I don't think you have to worry too much about the core data structures and 
locking/synchronisation/atomic primitives. The major scope for errors is in 
lockless code, where the barrier usage is explicit.

> In my patch, I use mb( ), because this macro Is DSB( ) , while 
> smp_wmb( ) is DMS( ), I just think DSB is much strict than DMS, mmm..
> so , DSM( )  or DMS ( )  are both ok ?

I think you're getting confused with your barriers. We have two memory barriers 
on ARM: dmb and dsb. dmb is sufficient to enforce ordering of observability. 
dsb is used to enforce completion.

> The whitepaper I use is here:
> https://www.google.com/#q=cortex+a15+microarchitecture
> 
> the first: [PDF] Exploring the Design of the Cortex-A15 Processor - 
> ARM
> 
> I just search in Google, and you know that qcom don't release Much 
> document about its krait cpu's micro architecture details, I just use
> cortex-a15 for a reference, I am not sure if their pipeline ( 
> load/store unit) are the same,

I think the lawyers would have a field day if the pipelines were the same!
You really can't use an A15 slide-deck to infer micro-architectural details 
about Krait.

Please can you test the patch I sent you yesterday?

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] MAINTAINERS: Add Kumar to Device Tree Binding maintainers group

[Kumar Gala]

On Oct 16, 2013, at 5:56 PM, Rob Herring wrote:

> On 08/08/2013 10:51 AM, Kumar Gala wrote:
>> I'm tossing my hat into the ring of maintainers/reviewers for device tree
>> bindings based on history of dealing with DT on embedded PPC and starting
>> work on ARM SoCs.
>> 
>> Signed-off-by: Kumar Gala 
>> Cc: Pawel Moll 
>> Cc: Mark Rutland 
>> Cc: Stephen Warren 
>> Cc: Ian Campbell 
>> Cc: Rob Herring 
>> Cc: Grant Likely 
>> Cc: Olof Johansson 
>> ---
> 
> Seems this one got lost. I assume you still want to drink from the fire
> hose, so I've applied it.
> 
> Rob

Yeah, thanks.  Figured I'd bring it up at the DT summit if it hadn't been 
applied.

I'd like to hopefully spend a little time on DT review process:
* split list for binding reviews vs .dts{i}
* look at using patchworks to have some 'assignment' of lead reviewer.

- k

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 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] x86: Run checksumming in parallel accross multiple alu's

[Eric Dumazet]

On Wed, 2013-10-16 at 20:34 -0400, Neil Horman wrote:

> > 
> 
> So I went to reproduce these results, but was unable to (due to the fact that 
> I
> only have a pretty jittery network to do testing accross at the moment with
> these devices).  So instead I figured that I would go back to just doing
> measurements with the module that I cobbled together (operating under the
> assumption that it would give me accurate, relatively jitter free results 
> (I've
> attached the module code for reference below).  My results show slightly
> different behavior:
> 
> Base results runs:
> 89417240
> 85170397
> 85208407
> 89422794
> 91645494
> 103655144
> 86063791
> 75647774
> 83502921
> 85847372
> AVG = 875 ns
> 
> Prefetch only runs:
> 70962849
> 77555099
> 81898170
> 68249290
> 72636538
> 83039294
> 78561494
> 83393369
> 85317556
> 79570951
> AVG = 781 ns
> 
> Parallel addition only runs:
> 42024233
> 44313064
> 48304416
> 64762297
> 42994259
> 41811628
> 55654282
> 64892958
> 55125582
> 42456403
> AVG = 510 ns
> 
> 
> Both prefetch and parallel addition:
> 41329930
> 40689195
> 61106622
> 46332422
> 49398117
> 52525171
> 49517101
> 61311153
> 43691814
> 49043084
> AVG = 494 ns
> 
> 
> For reference, each of the above large numbers is the number of nanoseconds
> taken to compute the checksum of a 4kb buffer 10 times.  To get my average
> results, I ran the test in a loop 10 times, averaged them, and divided by
> 10.
> 
> 
> Based on these, prefetching is obviously a a good improvement, but not as good
> as parallel execution, and the winner by far is doing both.
> 
> Thoughts?
> 
> Neil
> 


Your benchmark uses a single 4K page, so data is _super_ hot in cpu
caches.
( prefetch should give no speedups, I am surprised it makes any
difference)

Try now with 32 huges pages, to get 64 MBytes of working set.

Because in reality we never csum_partial() data in cpu cache.
(Unless the NIC preloaded the data into cpu cache before sending the
interrupt)

Really, if Sebastien got a speed up, it means that something fishy was
going on, like :

- A copy of data into some area of memory, prefilling cpu caches
- csum_partial() done while data is hot in cache.

This is exactly a "should not happen" scenario, because the csum in this
case should happen _while_ doing the copy, for 0 ns.



--
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/8] mm: pcp: rename percpu pageset functions

[David Rientjes]

On Tue, 15 Oct 2013, Dave Hansen wrote:

> diff -puN mm/page_alloc.c~rename-pageset-functions mm/page_alloc.c
> --- linux.git/mm/page_alloc.c~rename-pageset-functions2013-10-15 
> 09:57:05.870612107 -0700
> +++ linux.git-davehans/mm/page_alloc.c2013-10-15 09:57:05.875612329 
> -0700
> @@ -4136,10 +4136,18 @@ static void pageset_update(struct per_cp
>   pcp->batch = batch;
>  }
>  
> -/* a companion to pageset_set_high() */
> -static void pageset_set_batch(struct per_cpu_pageset *p, unsigned long batch)
> +/*
> + * Set the batch size for hot per_cpu_pagelist, and derive
> + * the high water mark from the batch size.
> + */
> +static void pageset_setup_from_batch_size(struct per_cpu_pageset *p,
> + unsigned long batch)
>  {
> - pageset_update(&p->pcp, 6 * batch, max(1UL, 1 * batch));
> + unsigned long high;
> + high = 6 * batch;
> + if (!batch)
> + batch = 1;

high = 6 * batch should be here?

> + pageset_update(&p->pcp, high, batch);
>  }
>  
>  static void pageset_init(struct per_cpu_pageset *p)
> @@ -4158,15 +4166,15 @@ static void pageset_init(struct per_cpu_
>  static void setup_pageset(struct per_cpu_pageset *p, unsigned long batch)
>  {
>   pageset_init(p);
> - pageset_set_batch(p, batch);
> + pageset_setup_from_batch_size(p, batch);
>  }
>  
>  /*
> - * pageset_set_high() sets the high water mark for hot per_cpu_pagelist
> - * to the value high for the pageset p.
> + * Set the high water mark for the per_cpu_pagelist, and derive
> + * the batch size from this high mark.
>   */
> -static void pageset_set_high(struct per_cpu_pageset *p,
> - unsigned long high)
> +static void pageset_setup_from_high_mark(struct per_cpu_pageset *p,
> + unsigned long high)
>  {
>   unsigned long batch = max(1UL, high / 4);
>   if ((high / 4) > (PAGE_SHIFT * 8))
> @@ -4179,11 +4187,11 @@ static void __meminit pageset_set_high_a
>   struct per_cpu_pageset *pcp)
>  {
>   if (percpu_pagelist_fraction)
> - pageset_set_high(pcp,
> + pageset_setup_from_high_mark(pcp,
>   (zone->managed_pages /
>   percpu_pagelist_fraction));
>   else
> - pageset_set_batch(pcp, zone_batchsize(zone));
> + pageset_setup_from_batch_size(pcp, zone_batchsize(zone));
>  }
>  
>  static void __meminit zone_pageset_init(struct zone *zone, int cpu)
> @@ -5781,8 +5789,9 @@ int percpu_pagelist_fraction_sysctl_hand
>   unsigned long  high;
>   high = zone->managed_pages / percpu_pagelist_fraction;
>   for_each_possible_cpu(cpu)
> - pageset_set_high(per_cpu_ptr(zone->pageset, cpu),
> -  high);
> + pageset_setup_from_high_mark(
> + per_cpu_ptr(zone->pageset, cpu),
> + high);
>   }
>   mutex_unlock(&pcp_batch_high_lock);
>   return 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/

Re: linux-next: manual merge of the tip tree

[NeilBrown]

On Wed, 16 Oct 2013 23:30:05 +0200 Peter Zijlstra 
wrote:

> On Wed, Oct 16, 2013 at 08:51:39PM +0200, Thierry Reding wrote:
> > Today's linux-next merge of the tip tree got a conflict in
> > 
> > include/linux/wait.h
> > 
> > caused by commits 1ab2460 (wait: add wait_event_cmd()) and fb869b6
> > (sched/wait: Clean up wait.h details a bit).
> > 
> > I've cleaned it up (see below). Please verify that the resolution looks
> > good.
> 
> >  +#define __wait_event_cmd(wq, condition, cmd1, cmd2)   
> > \
> >  +do {  
> > \
> >  +  DEFINE_WAIT(__wait);\
> >  +  \
> >  +  for (;;) {  \
> >  +  prepare_to_wait(&wq, &__wait, TASK_UNINTERRUPTIBLE);\
> >  +  if (condition)  \
> >  +  break;  \
> >  +  cmd1;   \
> >  +  schedule(); \
> >  +  cmd2;   \
> >  +  }   \
> >  +  finish_wait(&wq, &__wait);  \
> >  +} while (0)
> 
> Ideally we'd write the new thing like:
> 
> #define __wait_event_cmd(wq, condition, cmd1, cmd2)   \
>   (void)___wait_event(wq, condition, TASK_UNINTERRUPTIBLE, 0, 0,  \
>   cmd1; schedule(); cmd2)
> 

Oooo.. that looks much nicer.  I'll make it look like that before it goes
upstream.

Thanks,
NeilBrown


signature.asc
Description: PGP signature

Re: linux-next: manual merge of the tip tree

[NeilBrown]

On Wed, 16 Oct 2013 22:52:07 +0200 Peter Zijlstra 
wrote:

> Hey Neil;
> 
> it looks like its one of your patches isn't it?
> 
> http://www.spinics.net/lists/raid/msg44100.html
> http://www.spinics.net/lists/raid/msg44101.html
> 
> Given that I can't find them in a lkml archive means nobody's ever seen
> those patches.
> 
> Anyway; has that 3/3 patch ever been ran with lockdep enabled? 

I always run with lockdep enabled, and I have done at least basic testing
(I've been on leave for a few weeks and don't remember exactly where I got
to).
And I haven't seen any lockdep reports.

> 
> Stuff like:
> 
> + for (i = 0; i < NR_STRIPE_HASH_LOCKS; i++)
> + spin_lock_init(conf->hash_locks + i);
> 
> And:
> 
> +static void __lock_all_hash_locks(struct r5conf *conf)
> +{
> + int i;
> + for (i = 0; i < NR_STRIPE_HASH_LOCKS; i++)
> + spin_lock(conf->hash_locks + i);
> +}
> 
> Tends to complain real loud.

Why is that?
Because "conf->hash_locks + i" gets used as the "name" of the lockdep map for
each one, and when they are all locked it looks like nested locking??

the lock_all_hash_locks doesn't get called very often and my testing mustn't
have got that far.  I just tried something that would trigger the 
"lock_all_device_hash_locks_irq" (as it is in the current version) and it
went "splat" just as you said it would.
Thanks.

Do you have a suggestion for how to make this work?
Would
spin_lock_nested(conf->hash_locks + i, i)
do the trick?

Thanks,
NeilBrown

> 
> This leaves one to wonder... 
>   'fancy' locking scheme:1, validation effort:0
> 



signature.asc
Description: PGP signature

Re: [PATCH] drivers: bus: omap_l3: remove deprecated IRQF_DISABLED

[Greg KH]

On Sat, Oct 12, 2013 at 06:37:32AM +0200, Michael Opdenacker wrote:
> This patch proposes to remove the use of the IRQF_DISABLED flag
> 
> It's a NOOP since 2.6.35 and it will be removed one day.
> 
> Signed-off-by: Michael Opdenacker 
> ---
>  drivers/bus/omap_l3_noc.c | 4 ++--
>  drivers/bus/omap_l3_smx.c | 6 ++
>  2 files changed, 4 insertions(+), 6 deletions(-)

These files aren't "mine", I suggest sending this to the OF maintainers
that scripts/get_maintainer.pl points out for this patch.

thanks,

greg k-h
--
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: [Question] Ask for arm arch timer

[Neil Zhang]

> -Original Message-
> From: Catalin Marinas [mailto:catalin.mari...@arm.com]
> Sent: 2013年10月16日 21:21
> To: Rob Herring
> Cc: Neil Zhang; linux-kernel@vger.kernel.org; Yu Tang; Zhou Zhu; Will Deacon
> Subject: Re: [Question] Ask for arm arch timer
> 
> On Wed, Oct 16, 2013 at 01:59:25PM +0100, Rob Herring wrote:
> > On 10/16/2013 07:39 AM, Neil Zhang wrote:
> > > I saw your following patch called clocksource_of_init() directly in
> > > time_init() for arm64.
> > > My question is that what should we do if there are some Soc special
> > > work need to be done before arch timer can be used?
> > > Thanks in advance.
> >
> > If the timer itself is different, then you should have a different DT
> > compatible string which you can use to trigger additional initialization.
> >
> > Integration level initialization like enabling clocks would need
> > something different as no machine descriptors exist for arm64.
> >
> > Another option would be do the setup in secure world or the bootloader.
> 
> The generic timer should indeed be initialised in the firmware (bootloader may
> not be suitable if initialisation needs to happen on each CPU). Linux doesn't 
> need
> to do other things than reading the frequency, programming the interrupts,
> counters (but definitely not SoC-specific initialisation).
> 
> > Can you be more specific what initialization is needed.
> 
> I'm interested in this as well.

Thanks Catalin and Rob!
Yes, we need to select the clk source and enable it.
Seems we need to put more and more works into firmware on arm64.

> 
> --
> Catalin

Best Regards,
Neil Zhang

Re: [PATCH] ecryptfs: Fix memory leakage in keystore.c

[Geyslan Gregório Bem]

2013/10/16 Tyler Hicks :
> On 2013-10-11 16:49:16, Geyslan G. Bem wrote:
>> In 'decrypt_pki_encrypted_session_key' function:
>>
>> Initializes 'payload' pointer and releases it on exit.
>>
>> Signed-off-by: Geyslan G. Bem 
>> ---
>
> Thanks! This one was easy to verify by auditing the code, but I was also
> able to verify the leak with kmemleak.
It's a pleasure.

>
> I've targeted it for stable and pushed it to the eCryptfs next branch.
>
Thank you.

> Tyler
>
>>  fs/ecryptfs/keystore.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/fs/ecryptfs/keystore.c b/fs/ecryptfs/keystore.c
>> index 7d52806..4725a07 100644
>> --- a/fs/ecryptfs/keystore.c
>> +++ b/fs/ecryptfs/keystore.c
>> @@ -1149,7 +1149,7 @@ decrypt_pki_encrypted_session_key(struct 
>> ecryptfs_auth_tok *auth_tok,
>>   struct ecryptfs_msg_ctx *msg_ctx;
>>   struct ecryptfs_message *msg = NULL;
>>   char *auth_tok_sig;
>> - char *payload;
>> + char *payload = NULL;
>>   size_t payload_len = 0;
>>   int rc;
>>
>> @@ -1203,6 +1203,7 @@ decrypt_pki_encrypted_session_key(struct 
>> ecryptfs_auth_tok *auth_tok,
>>   }
>>  out:
>>   kfree(msg);
>> + kfree(payload);
>>   return rc;
>>  }
>>
>> --
>> 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 1/3] switch_creds: Syscall to switch creds for file server ops

[Al Viro]

On Wed, Oct 16, 2013 at 06:18:16PM -0700, Eric W. Biederman wrote:

> That doesn't look bad but it does need capable(CAP_SETUID) &&
> capable(CAP_SETGID) or possibly something a little more refined.

D'oh

> I don't think we want file descriptor passing to all of a sudden become
> a grant of privilege, beyond what the passed fd can do.

Definitely.  And an extra ) to make it compile wouldn't hurt either...
--
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/3] switch_creds: Syscall to switch creds for file server ops

[Eric W. Biederman]

Al Viro  writes:

> On Wed, Oct 16, 2013 at 03:01:57PM -0700, Jim Lieb wrote:
>> File servers must do some operations with the credentials of
>> their client.  This syscall switches the key credentials similar
>> to nfsd_setuser() in fs/nfsd/auth.c  with the capability of retaining a
>> handle to the credentials by way of an fd for an open anonymous file.
>> This makes switching for subsequent operations for that client more 
>> efficient.
>
>   Yet Another Untyped Multiplexor.  Inna bun.  Onna stick.
> CMOT Dibbler special...
>
>   Switching creds to those of opener of given file descriptor
> is fine, but in any realistic situation you'll get all the real win
> from that - you should cache those fds (which you seem to do), and
> then setuid/etc. is done once per cache miss.  Making the magical
> "set them all at once" mess (complete with non-trivial structure,
> 32/64bit compat, etc.) pointless.  Moreover, you don't need any magic
> files at all - just set the creds and open /dev/null and there's your fd.
> With proper creds associated with it.  While we are at it, just _start_
> with opening /dev/null.  With your initial creds.  Voila - revert is
> simply switch to that fd's creds.
>
>   IOW, you really need only one syscall:

That doesn't look bad but it does need capable(CAP_SETUID) &&
capable(CAP_SETGID) or possibly something a little more refined.

I don't think we want file descriptor passing to all of a sudden become
a grant of privilege, beyond what the passed fd can do.

> SYSCALL_DEFINE1(switch_cred, int, fd)
> {
>   struct fd f = fdget(fd);
>   if (!f.file)
>   return -EBADF;
>   put_cred(override_creds(f.file->f_cred);
>   fdput(f);
>   return 0;
> }
>
> and that's all there is to it.

Eric
--
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] ACPI/Power: Check physical device's runtime pm status before requesting to resume it

[Lan Tianyu]

On 2013年10月16日 20:42, Rafael J. Wysocki wrote:
> On Wednesday, October 16, 2013 05:26:21 PM Lan Tianyu wrote:
>> This is a multi-part message in MIME format.
>> --090400010209000300030201
>> Content-Type: text/plain; charset=UTF-8
>> Content-Transfer-Encoding: 8bit
>>
>> On 10/16/2013 05:22 AM, Rafael J. Wysocki wrote:
>>> On Tuesday, October 15, 2013 04:58:28 PM Lan Tianyu wrote:
 On 2013年10月11日 19:19, Rafael J. Wysocki wrote:
> On Friday, October 11, 2013 04:16:25 PM tianyu@intel.com
> wrote:
>> From: Lan Tianyu 
>>
>> Currently, when one power resource is turned on, devices owning
>> it will be requested to resume regardless of their runtime pm
>> status. ACPI power resource maybe turn on in some devices'
>> runtime pm resume callback(E.G, usb port) while turning on the
>> power resource will trigger one new resume request of the
>> device. It causes infinite loop between resume and suspend.
>> This has happened on clearing usb port's PM Qos NO_POWER_OFF
>> flag twice. This patch is to add check of physical device's
>> runtime pm status and request resume if the device is
>> suspended.
>>
>> Signed-off-by: Lan Tianyu  ---
>> drivers/acpi/power.c | 6 -- 1 file changed, 4
>> insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c index
>>  0dbe5cd..228c138 100644 --- a/drivers/acpi/power.c +++
>> b/drivers/acpi/power.c @@ -250,8 +250,10 @@ static void
>> acpi_power_resume_dependent(struct work_struct *work)
>>
>> mutex_lock(&adev->physical_node_lock);
>>
>> -list_for_each_entry(pn, &adev->physical_node_list, node) -
>> pm_request_resume(pn->dev); +list_for_each_entry(pn,
>> &adev->physical_node_list, node) { + if
>> (pm_runtime_suspended(pn->dev)) + pm_request_resume(pn->dev);
>> + }
>
> This is racy, because the status may change right after you check
> it and before you call pm_request_resume().

 Yes, the runtime status may be changed just after the check.

>
> Besides, pm_request_resume() checks the status of the device and
>  won't try to resume it if it is not suspended.
>

 For this issue, usb port is in the RPM_SUSPENDING state when
 pm_request_resume() is called.
>>>
>>> Why exactly does that happen?
>>>
 The deferred_resume will be set to true during this procedure and
 trigger resume after finishing suspend. USB port runtime resume
 callback will turn on its power resource again and the work of
 acpi_power_resume_dependent() is scheduled. Because the usb port's
  usage count remains zero, it's to be suspended soon. When
 pm_request_resume() of acpi_power_resume_dependent() is called, the
 usb port is always in the PRM_SUSPENDING. Fall in the loop of
 suspend and resume.

 How about running acpi_power_dependent when turning on power
 resource rather than scheduling a work to run it?
>>>
>>> Is this actually going to help?  Even if
>>> acpi_power_resume_dependent() is run synchronously from within the
>>> resume callback, it will still see RPM_SUSPENDING as the device's
>>> status, won't it?
>>>
 After this, pm_request_resume() can check device's right status
 just after turning on power resource.
>>>
>>> The status doesn't change until the .runtime_suspend() callback
>>> returns and running pm_request_resume() syncrhonously from that
>>> callback for the device being suspended just plain doesn't make
>>> sense.
>>>
>>>
>>> Can you please explain to me how this is possible that the USB port's
>>> power resource is turned "on" while the port is RPM_SUSPENDING?
>>>
>> [This mail seems not to be sent to maillist. So resend. Try again
>> Sorry for noise]
>>
>>
>> Hi Rafael:
>>
>> No, I mean the acpi_power_resume_dependent() is running while the port's
>> status is RPM_SUSPENDING. It runs from a work item and turning on power
>> resource adds the work to workqueue. There is a timeslot between running
>> acpi_power_resume_dependent() and turning on power resource. In the
>> timeslot, the device runtime pm status maybe change.
>>
>> In this case, changing PM Qos flag will do pm_runtime_get_sync and
>> pm_runtime_put usb port. The usb port is without device attached and so
>> it will be resumed and suspended soon during changing PM Qos flag.
>>
>> Resume callback turns on power resource if NO_POWER_OFF flag has been
>> cleared and add the work of acpi_power_resume_dependent() to
>> workqueue. After resume, the usb port will be suspended while the
>> acpi_power_resume_dependent() is running. pm_request_resume() gets
>> RPM_SUSPENDING as the usb port's runtime status and set the
>> deferred_resume of usb port.
>>
>> After suspend, usb port will be resumed again and turn on power
>> resource. The work of acpi_power_resume_dependent() is also added to
>> workqueue. Because the usb port's usage c

Re: [PATCH] mm: Do not walk all of system memory during show_mem

[David Rientjes]

On Wed, 16 Oct 2013, Mel Gorman wrote:

> It has been reported on very large machines that show_mem is taking almost
> 5 minutes to display information. This is a serious problem if there is
> an OOM storm. The bulk of the cost is in show_mem doing a very expensive
> PFN walk to give us the following information
> 
> Total RAM:Also available as totalram_pages
> Highmem pages:Also available as totalhigh_pages
> Reserved pages:   Can be inferred from the zone structure
> Shared pages: PFN walk required
> Unshared pages:   PFN walk required
> Quick pages:  Per-cpu walk required
> 
> Only the shared/unshared pages requires a full PFN walk but that information
> is useless. It is also inaccurate as page pins of unshared pages would
> be accounted for as shared.  Even if the information was accurate, I'm
> struggling to think how the shared/unshared information could be useful
> for debugging OOM conditions. Maybe it was useful before rmap existed when
> reclaiming shared pages was costly but it is less relevant today.
> 
> The PFN walk could be optimised a bit but why bother as the information is
> useless. This patch deletes the PFN walker and infers the total RAM, highmem
> and reserved pages count from struct zone. It omits the shared/unshared page
> usage on the grounds that it is useless.  It also corrects the reporting
> of HighMem as HighMem/MovableOnly as ZONE_MOVABLE has similar problems to
> HighMem with respect to lowmem/highmem exhaustion.
> 

We haven't been hit by this for the oom killer, but we did get hit with 
this for page allocation failure warnings as a result of having irqs 
disabled and passing GFP_ATOMIC to the page allocator without GFP_NOWARN.  
That was the intention of passing SHOW_MEM_FILTER_PAGE_COUNT into 
show_mem() in 4b59e6c47309 ("mm, show_mem: suppress page counts in 
non-blockable contexts").

With this, I assume we can just remove SHOW_MEM_FILTER_PAGE_COUNT 
entirely?
--
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] ecryptfs: Fix memory leakage in keystore.c

[Tyler Hicks]

On 2013-10-11 16:49:16, Geyslan G. Bem wrote:
> In 'decrypt_pki_encrypted_session_key' function:
> 
> Initializes 'payload' pointer and releases it on exit.
> 
> Signed-off-by: Geyslan G. Bem 
> ---

Thanks! This one was easy to verify by auditing the code, but I was also
able to verify the leak with kmemleak.

I've targeted it for stable and pushed it to the eCryptfs next branch.

Tyler

>  fs/ecryptfs/keystore.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/ecryptfs/keystore.c b/fs/ecryptfs/keystore.c
> index 7d52806..4725a07 100644
> --- a/fs/ecryptfs/keystore.c
> +++ b/fs/ecryptfs/keystore.c
> @@ -1149,7 +1149,7 @@ decrypt_pki_encrypted_session_key(struct 
> ecryptfs_auth_tok *auth_tok,
>   struct ecryptfs_msg_ctx *msg_ctx;
>   struct ecryptfs_message *msg = NULL;
>   char *auth_tok_sig;
> - char *payload;
> + char *payload = NULL;
>   size_t payload_len = 0;
>   int rc;
>  
> @@ -1203,6 +1203,7 @@ decrypt_pki_encrypted_session_key(struct 
> ecryptfs_auth_tok *auth_tok,
>   }
>  out:
>   kfree(msg);
> + kfree(payload);
>   return rc;
>  }
>  
> -- 
> 1.8.4
> 


signature.asc
Description: Digital signature