[PATCH 5/5] W1: w1-gpio - switch to using managed resources (devm)

[Dmitry Torokhov]

This simplifies error unwinding and device teardown.

Signed-off-by: Dmitry Torokhov 
---
 drivers/w1/masters/w1-gpio.c | 31 ++-
 1 file changed, 10 insertions(+), 21 deletions(-)

diff --git a/drivers/w1/masters/w1-gpio.c b/drivers/w1/masters/w1-gpio.c
index ee6b6e3..19439f8 100644
--- a/drivers/w1/masters/w1-gpio.c
+++ b/drivers/w1/masters/w1-gpio.c
@@ -116,25 +116,26 @@ static int w1_gpio_probe(struct platform_device *pdev)
return err;
}
 
-   w1_gpio = kzalloc(sizeof(struct w1_gpio), GFP_KERNEL);
+   w1_gpio = devm_kzalloc(&pdev->dev, sizeof(struct w1_gpio), GFP_KERNEL);
if (!w1_gpio) {
dev_err(&pdev->dev, "Out of memory\n");
return -ENOMEM;
}
 
-   err = gpio_request(pdata->pin, "w1");
+   err = devm_gpio_request(&pdev->dev, pdata->pin, "w1");
if (err) {
dev_err(&pdev->dev, "gpio_request (pin) failed\n");
-   goto free_master;
+   return err;
}
 
if (gpio_is_valid(pdata->ext_pullup_enable_pin)) {
-   err = gpio_request_one(pdata->ext_pullup_enable_pin,
-  GPIOF_INIT_LOW, "w1 pullup");
+   err = devm_gpio_request_one(&pdev->dev,
+   pdata->ext_pullup_enable_pin,
+   GPIOF_INIT_LOW, "w1 pullup");
if (err < 0) {
-   dev_err(&pdev->dev, "gpio_request_one "
-   "(ext_pullup_enable_pin) failed\n");
-   goto free_gpio;
+   dev_err(&pdev->dev,
+   "gpio_request_one (ext_pullup_enable_pin) 
failed\n");
+   return err;
}
}
 
@@ -154,7 +155,7 @@ static int w1_gpio_probe(struct platform_device *pdev)
err = w1_add_master_device(&w1_gpio->master);
if (err) {
dev_err(&pdev->dev, "w1_add_master device failed\n");
-   goto free_gpio_ext_pu;
+   return err;
}
 
if (pdata->enable_external_pullup)
@@ -166,16 +167,6 @@ static int w1_gpio_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, w1_gpio);
 
return 0;
-
- free_gpio_ext_pu:
-   if (gpio_is_valid(pdata->ext_pullup_enable_pin))
-   gpio_free(pdata->ext_pullup_enable_pin);
- free_gpio:
-   gpio_free(pdata->pin);
- free_master:
-   kfree(w1_gpio);
-
-   return err;
 }
 
 static int w1_gpio_remove(struct platform_device *pdev)
@@ -190,8 +181,6 @@ static int w1_gpio_remove(struct platform_device *pdev)
gpio_set_value(pdata->ext_pullup_enable_pin, 0);
 
w1_remove_master_device(&w1_gpio->master);
-   gpio_free(pdata->pin);
-   kfree(w1_gpio);
 
return 0;
 }
-- 
1.7.11.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/

[PATCH 4/5] W1: w1-gpio - rework handling of platform data

[Dmitry Torokhov]

The platform data in the dveice structure does not belong to the driver
and so it should not be trying to alter it, but instead use a local pointer
and populate it with a local copy in case we are dealing with device tree
setup.

Also allow mixed setups where platform data coexists with device tree and
prefer kernel-supplied data (it may be easier to fiddle in kernel structure
before committing final result to device tree).

Signed-off-by: Dmitry Torokhov 
---
 drivers/w1/masters/w1-gpio.c | 93 +---
 1 file changed, 53 insertions(+), 40 deletions(-)

diff --git a/drivers/w1/masters/w1-gpio.c b/drivers/w1/masters/w1-gpio.c
index aa97a96..ee6b6e3 100644
--- a/drivers/w1/masters/w1-gpio.c
+++ b/drivers/w1/masters/w1-gpio.c
@@ -23,28 +23,33 @@
 #include "../w1.h"
 #include "../w1_int.h"
 
+struct w1_gpio {
+   struct w1_bus_master master;
+   const struct w1_gpio_platform_data *pdata;
+};
+
 static void w1_gpio_write_bit_dir(void *data, u8 bit)
 {
-   struct w1_gpio_platform_data *pdata = data;
+   struct w1_gpio *w1_gpio = data;
 
if (bit)
-   gpio_direction_input(pdata->pin);
+   gpio_direction_input(w1_gpio->pdata->pin);
else
-   gpio_direction_output(pdata->pin, 0);
+   gpio_direction_output(w1_gpio->pdata->pin, 0);
 }
 
 static void w1_gpio_write_bit_val(void *data, u8 bit)
 {
-   struct w1_gpio_platform_data *pdata = data;
+   struct w1_gpio *w1_gpio = data;
 
-   gpio_set_value(pdata->pin, bit);
+   gpio_set_value(w1_gpio->pdata->pin, bit);
 }
 
 static u8 w1_gpio_read_bit(void *data)
 {
-   struct w1_gpio_platform_data *pdata = data;
+   struct w1_gpio *w1_gpio = data;
 
-   return gpio_get_value(pdata->pin) ? 1 : 0;
+   return gpio_get_value(w1_gpio->pdata->pin) ? 1 : 0;
 }
 
 #ifdef CONFIG_OF
@@ -55,38 +60,43 @@ static struct of_device_id w1_gpio_dt_ids[] = {
 };
 MODULE_DEVICE_TABLE(of, w1_gpio_dt_ids);
 
-static int w1_gpio_probe_dt(struct platform_device *pdev)
+static struct w1_gpio_platform_data *
+w1_gpio_probe_dt(struct platform_device *pdev)
 {
-   struct w1_gpio_platform_data *pdata = pdev->dev.platform_data;
+   struct w1_gpio_platform_data *pdata;
struct device_node *np = pdev->dev.of_node;
 
+   if (!np)
+   return ERR_PTR(-ENOENT);
+
pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
-   return -ENOMEM;
+   return ERR_PTR(-ENOMEM);
 
if (of_get_property(np, "linux,open-drain", NULL))
pdata->is_open_drain = 1;
 
pdata->pin = of_get_gpio(np, 0);
pdata->ext_pullup_enable_pin = of_get_gpio(np, 1);
-   pdev->dev.platform_data = pdata;
 
-   return 0;
+   return pdata;
 }
 
 #else
 
-static inline int w1_gpio_probe_dt(struct platform_device *pdev)
+static inline struct w1_gpio_platform_data *
+w1_gpio_probe_dt(struct platform_device *pdev)
 {
-   return -ENOSYS;
+   return NULL;
 }
 
 #endif
 
 static int w1_gpio_probe(struct platform_device *pdev)
 {
-   struct w1_bus_master *master;
-   struct w1_gpio_platform_data *pdata;
+   const struct w1_gpio_platform_data *pdata =
+   dev_get_platdata(&pdev->dev);
+   struct w1_gpio *w1_gpio;
struct pinctrl *pinctrl;
int err;
 
@@ -94,23 +104,20 @@ static int w1_gpio_probe(struct platform_device *pdev)
if (IS_ERR(pinctrl))
dev_warn(&pdev->dev, "unable to select pin group\n");
 
-   if (of_have_populated_dt()) {
-   err = w1_gpio_probe_dt(pdev);
-   if (err < 0) {
-   dev_err(&pdev->dev, "Failed to parse DT\n");
-   return err;
-   }
-   }
-
-   pdata = pdev->dev.platform_data;
+   if (!pdata)
+   pdata = w1_gpio_probe_dt(pdev);
 
if (!pdata) {
dev_err(&pdev->dev, "No configuration data\n");
return -ENXIO;
+   } else if (IS_ERR(pdata)) {
+   err = PTR_ERR(pdata);
+   dev_err(&pdev->dev, "Failed to parse DT\n");
+   return err;
}
 
-   master = kzalloc(sizeof(struct w1_bus_master), GFP_KERNEL);
-   if (!master) {
+   w1_gpio = kzalloc(sizeof(struct w1_gpio), GFP_KERNEL);
+   if (!w1_gpio) {
dev_err(&pdev->dev, "Out of memory\n");
return -ENOMEM;
}
@@ -131,18 +138,20 @@ static int w1_gpio_probe(struct platform_device *pdev)
}
}
 
-   master->data = pdata;
-   master->read_bit = w1_gpio_read_bit;
+   w1_gpio->pdata = pdata;
+
+   w1_gpio->master.data = w1_gpio;
+   w1_gpio->master.read_bit = w1_gpio_read_bit;
 
if (pdata->is_open_drain) {
gpio_direction_output(pdata->pin, 1);
-   master->write_bit = w1_gpio_write_bit_val;
+   w1_gp

[PATCH 3/5] W1: w1-gpio - guard DT IDs with CONFIG_OF

[Dmitry Torokhov]

This fixes the following warning:

  CC  drivers/w1/masters/w1-gpio.o
drivers/w1/masters/w1-gpio.c:50:28: warning: ‘w1_gpio_dt_ids’ defined but not 
used [-Wunused-variable]

Also provide stub for w1_gpio_probe_dt() if device tree support is
disabled.

Signed-off-by: Dmitry Torokhov 
---
 drivers/w1/masters/w1-gpio.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/w1/masters/w1-gpio.c b/drivers/w1/masters/w1-gpio.c
index c45b9ae..aa97a96 100644
--- a/drivers/w1/masters/w1-gpio.c
+++ b/drivers/w1/masters/w1-gpio.c
@@ -47,6 +47,8 @@ static u8 w1_gpio_read_bit(void *data)
return gpio_get_value(pdata->pin) ? 1 : 0;
 }
 
+#ifdef CONFIG_OF
+
 static struct of_device_id w1_gpio_dt_ids[] = {
{ .compatible = "w1-gpio" },
{}
@@ -72,6 +74,15 @@ static int w1_gpio_probe_dt(struct platform_device *pdev)
return 0;
 }
 
+#else
+
+static inline int w1_gpio_probe_dt(struct platform_device *pdev)
+{
+   return -ENOSYS;
+}
+
+#endif
+
 static int w1_gpio_probe(struct platform_device *pdev)
 {
struct w1_bus_master *master;
-- 
1.7.11.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/

[PATCH 2/5] W1: w1-gpio - switch to using dev_pm_ops

[Dmitry Torokhov]

Signed-off-by: Dmitry Torokhov 
---
 drivers/w1/masters/w1-gpio.c | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/w1/masters/w1-gpio.c b/drivers/w1/masters/w1-gpio.c
index 799dafd..c45b9ae 100644
--- a/drivers/w1/masters/w1-gpio.c
+++ b/drivers/w1/masters/w1-gpio.c
@@ -176,11 +176,10 @@ static int w1_gpio_remove(struct platform_device *pdev)
return 0;
 }
 
-#ifdef CONFIG_PM
-
-static int w1_gpio_suspend(struct platform_device *pdev, pm_message_t state)
+#ifdef CONFIG_PM_SLEEP
+static int w1_gpio_suspend(struct device *dev)
 {
-   struct w1_gpio_platform_data *pdata = pdev->dev.platform_data;
+   const struct w1_gpio_platform_data *pdata = dev_get_platdata(dev);
 
if (pdata->enable_external_pullup)
pdata->enable_external_pullup(0);
@@ -188,31 +187,28 @@ static int w1_gpio_suspend(struct platform_device *pdev, 
pm_message_t state)
return 0;
 }
 
-static int w1_gpio_resume(struct platform_device *pdev)
+static int w1_gpio_resume(struct device *dev)
 {
-   struct w1_gpio_platform_data *pdata = pdev->dev.platform_data;
+   const struct w1_gpio_platform_data *pdata = dev_get_platdata(dev);
 
if (pdata->enable_external_pullup)
pdata->enable_external_pullup(1);
 
return 0;
 }
-
-#else
-#define w1_gpio_suspendNULL
-#define w1_gpio_resume NULL
 #endif
 
+static SIMPLE_DEV_PM_OPS(w1_gpio_pm_ops, w1_gpio_suspend, w1_gpio_resume);
+
 static struct platform_driver w1_gpio_driver = {
.driver = {
.name   = "w1-gpio",
.owner  = THIS_MODULE,
+   .pm = &w1_gpio_pm_ops,
.of_match_table = of_match_ptr(w1_gpio_dt_ids),
},
.probe = w1_gpio_probe,
.remove = w1_gpio_remove,
-   .suspend = w1_gpio_suspend,
-   .resume = w1_gpio_resume,
 };
 
 module_platform_driver(w1_gpio_driver);
-- 
1.7.11.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/

[PATCH] md/raid456: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

Signed-off-by: Kees Cook 
Cc: Arjan van de Ven 
Cc: Dan Williams 
Cc: Alasdair G Kergon 
---
 drivers/md/Kconfig |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
index 7cdf359..0cc3a3d 100644
--- a/drivers/md/Kconfig
+++ b/drivers/md/Kconfig
@@ -158,7 +158,6 @@ config MULTICORE_RAID456
bool "RAID-4/RAID-5/RAID-6 Multicore processing (EXPERIMENTAL)"
depends on MD_RAID456
depends on SMP
-   depends on EXPERIMENTAL
---help---
  Enable the raid456 module to dispatch per-stripe raid operations to a
  thread pool.
-- 
1.7.9.5


-- 
Kees Cook
Chrome OS Security
--
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] drivers/vfio: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

Signed-off-by: Kees Cook 
Cc: Alex Williamson 
---
 drivers/vfio/pci/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vfio/pci/Kconfig b/drivers/vfio/pci/Kconfig
index e84300b..c41b01e 100644
--- a/drivers/vfio/pci/Kconfig
+++ b/drivers/vfio/pci/Kconfig
@@ -9,7 +9,7 @@ config VFIO_PCI
 
 config VFIO_PCI_VGA
bool "VFIO PCI support for VGA devices"
-   depends on VFIO_PCI && X86 && VGA_ARB && EXPERIMENTAL
+   depends on VFIO_PCI && X86 && VGA_ARB
help
  Support for VGA extension to VFIO PCI.  This exposes an additional
  region on VGA devices for accessing legacy VGA addresses used by
-- 
1.7.9.5


-- 
Kees Cook
Chrome OS Security
--
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/

Are there numa balancing topics scheduled for the incoming LSF?

[Hillf Danton]

Hello all

On Mon, Dec 17, 2012 at 7:19 AM, Linus Torvalds
 wrote:
> On Wed, Dec 12, 2012 at 2:03 AM, Mel Gorman  wrote:
>> This is a pull request for "Automatic NUMA Balancing V11". The list
>
> Ok, guys, I've pulled this and pushed out. There were some conflicts
> with both the VM changes and with the scheduler tree, but they were
> pretty small and looked simple, so I fixed them up and hope they all
> work.
>
> Anyway, hopefully we'll have a more real numa balancing for 3.9, and
> this is still considered a reasonable base for that work.
>
And what is scheduled for 3.9?

Thanks
Hillf
--
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] drivers/vhost: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

Signed-off-by: Kees Cook 
Cc: David S. Miller 
Cc: Asias He 
Cc: Michael S. Tsirkin 
---
 drivers/vhost/Kconfig.blk |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/vhost/Kconfig.blk b/drivers/vhost/Kconfig.blk
index 831a121..eeffc8b 100644
--- a/drivers/vhost/Kconfig.blk
+++ b/drivers/vhost/Kconfig.blk
@@ -1,6 +1,6 @@
 config VHOST_BLK
-   tristate "Host kernel accelerator for virtio blk (EXPERIMENTAL)"
-   depends on BLOCK &&  EXPERIMENTAL && EVENTFD && m
+   tristate "Host kernel accelerator for virtio blk"
+   depends on BLOCK && EVENTFD && m
---help---
  This kernel module can be loaded in host kernel to accelerate
  guest block with virtio_blk. Not to be confused with virtio_blk
-- 
1.7.9.5


-- 
Kees Cook
Chrome OS Security
--
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] arch/x86/xen: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

Signed-off-by: Kees Cook 
Cc: Stefano Stabellini 
Cc: Mukesh Rathor 
Cc: Konrad Rzeszutek Wilk 
---
 arch/x86/xen/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 93ff4e1..8cada4c 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -53,7 +53,7 @@ config XEN_DEBUG_FS
 
 config XEN_X86_PVH
bool "Support for running as a PVH guest (EXPERIMENTAL)"
-   depends on X86_64 && XEN && EXPERIMENTAL
+   depends on X86_64 && XEN
default n
help
   This option enables support for running as a PVH guest (PV guest
-- 
1.7.9.5


-- 
Kees Cook
Chrome OS Security
--
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] vxlan: remove depends on CONFIG_EXPERIMENTAL

[Kees Cook]

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

Signed-off-by: Kees Cook 
Cc: Stephen Hemminger 
Cc: David S. Miller 
---
 drivers/net/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 56c2d75..87f1d39 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -150,7 +150,7 @@ config MACVTAP
 
 config VXLAN
tristate "Virtual eXtensible Local Area Network (VXLAN)"
-   depends on EXPERIMENTAL && INET
+   depends on INET
---help---
  This allows one to create vxlan virtual interfaces that provide
  Layer 2 Networks over Layer 3 Networks. VXLAN is often used
-- 
1.7.9.5


-- 
Kees Cook
Chrome OS Security
--
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] xfs: Fix possible truncation of log data in xlog_bread_noalign()

[Tony Lu]

>From: Dave Chinner [mailto:da...@fromorbit.com]
>On Fri, Feb 22, 2013 at 08:12:52AM +, Tony Lu wrote:
>> I encountered the following panic when using xfs partitions as rootfs, which
>> is due to the truncated log data read by xlog_bread_noalign(). We should
>> extend the buffer by one extra log sector to ensure there's enough space to
>> accommodate requested log data, which we indeed did in xlog_get_bp(), but we
>> forgot to do in xlog_bread_noalign().
>
>We've never done that round up in xlog_bread_noalign(). It shouldn't
>be necessary as xlog_get_bp() and xlog_bread_noalign() are doing
>fundamentally different things. That is, xlog_get_bp() is ensuring
>the buffer is large enough for the upcoming IO that will be
>requested, while xlog_bread_noalign() is simply ensuring what it is
>passed is correctly aligned to device sector boundaries.

I set the sector size as 4096 when making the xfs filesystem.
-sh-4.1# mkfs.xfs -s size=4096 -f /dev/sda3

In this case, xlog_bread_noalign() needs to do such round up and round down 
frequently. And it is used to ensure what it is passed is aligned to the log 
sector size, but not the device sector boundaries.

Here is the debug info I added when mounting this xfs partition.
-sh-4.1# mount /dev/sda3 /home/
XFS (sda3): Mounting Filesystem
xlog_bread_noalign:blk_no=0,nbblks=1,l_sectBBsize=8
xlog_bread_noalign:blk_no=61447,nbblks=1,l_sectBBsize=8
xlog_bread_noalign:blk_no=0,nbblks=1,l_sectBBsize=8
...
xlog_bread_noalign:blk_no=8695,nbblks=1,l_sectBBsize=8
xlog_bread_noalign:blk_no=4600,nbblks=4096,l_sectBBsize=8
xlog_bread_noalign:blk_no=8184,nbblks=512,l_sectBBsize=8

>So, if you have to fudge an extra block for xlog_bread_noalign(),
>that implies that what xlog_bread_noalign() was passed was probably
>not correct. It also implies that you are using sector sizes larger
>than 512 bytes, because that's the only time this might matter. Put
>simply, this:

While debugging, I found when it crashed, the blk_no was not align to the log 
sector size and nnblks was aligned to the log sector size, which makes sense.

For example, if xlog_bread_noalign() wants to read blocks from #1 to # 9, in 
which case the passed parameter blk_no is 1, and nbblks is 8, sectBBsize is 8, 
after the round down and round up operations, we get blk_no as 0, and nbblks as 
still 8. We definitely lose the last block of the log data.

>> XFS mounting filesystem sda2
>> Starting XFS recovery on filesystem: sda2 (logdev: internal)
>> XFS: xlog_recover_process_data: bad clientid
>> XFS: log mount/recovery failed: error 5
>> XFS: log mount failed
>
>Is not sufficient information for me to determine if you've correctly
>analysed the problem you were seeing and that this is the correct
>fix for it. I don't even know what kernel you are seeing this on, or
>how you are reproducing it.

I was using the 2.6.38.6 kernel, and using xfs as a rootfs partition. After 
untaring the rootfs files on the xfs partition, and tried to reboot from the 
xfs, then the panic occasionally occurred.

>
>Note that I'm not saying the fix isn't necessary or correct, just
>that I cannot review it based this commit message.  Given that this
>code is essentially unchanged in behaviour since the large sector
>size support was adding in 2003(*), understanding how it is
>deficient is critical part of the reviewi process
>
>Information you need to provide so I have a chance of reviewing
>whether it is correct or not:
>
>   - what kernel you saw this on,
>   - what the filesystem configuration was
>   - what workload reproduced this problem (a test case would
> be nice, and xfstest even better)
>   - the actual contents of the log that lead to the short read
> during recovery
>   - whether xfs_logprint was capable of parsing the log
> correctly
>   - where in the actual log recovery process the failure
> occurred (e.g. was it trying to recover transactions from
> a section of a wrapped log?)

I hope I can provide the corrupted log for you, but probably I could not find 
it, since I fixed this bug a year ago. Recently when I do some clean-up on my 
code, I find this one, so I think I should return it back to the community.

>IOWs, please show your working so we can determine if this is the
>root cause of the problem you are seeing. :)
>
>(*)
>http://oss.sgi.com/cgi-bin/gitweb.cgi?p=archive/xfs-import.git;a=commitdiff
>;h=f14e527f411712f89178c31370b5d733ea1d0280
>
>FWIW, I think your change might need work - there's the possibility
>that is can round up the length beyond the end of the log if we ask
>to read up to the last sector of the log (i.e. blkno + blklen ==
>end of log) and then round up blklen by one sector
>
Good catch, you are right on this. To avoid this possibility, I changed the 
patch a little bit as following.
--- a/fs/xfs/xfs_log_recover.c
+++ b/fs/xfs/xfs_log_recover.c
@@ -171,6 +171,7 @@ xlog_bread_noalign(
struct xfs_buf  *bp)
 {

Re: [PATCH 8/9] memory-hotplug: enable memory hotplug to handle hugepage

[Hillf Danton]

Hello Naoya

[add Michal in cc list]

On Fri, Feb 22, 2013 at 3:41 AM, Naoya Horiguchi
 wrote:
>
> +/* Returns true for head pages of in-use hugepages, otherwise returns false. 
> */
> +int is_hugepage_movable(struct page *hpage)
s/int/bool/  can we?
> +{
> +   struct page *page;
> +   struct page *tmp;
> +   struct hstate *h = page_hstate(hpage);
Make sense to compute hstate for a tail page?
> +   int ret = 0;
> +
> +   VM_BUG_ON(!PageHuge(hpage));
> +   if (PageTail(hpage))
> +   return 0;
VM_BUG_ON(!PageHuge(hpage) || PageTail(hpage)), can we?
> +   spin_lock(&hugetlb_lock);
> +   list_for_each_entry_safe(page, tmp, &h->hugepage_activelist, lru)
s/_safe//  can we?
> +   if (page == hpage)
> +   ret = 1;
Can we bail out with ret set to be true?
> +   spin_unlock(&hugetlb_lock);
> +   return ret;
> +}
--
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/

ARM: ixp4xx regression (bisected) since v3.5-rc1

[Brad Parker]

I am using an ADI Pronghorn Metro board and noticed an issue with any
kernel >= 3.5-rc1 where the board would not boot (or at least no
console messages appear over the serial port), just giving
"Uncompressing Linux... done, booting the kernel." and stopping there.

I ran a git bisect between v3.4 and v3.5 and narrowed the problem down
to this commit:

---
c23bfc3835173f5229b2503e3b616001a28affad is the first bad commit
commit c23bfc3835173f5229b2503e3b616001a28affad
Author: Russell King 
Date:   Sat Mar 10 12:49:16 2012 +

ARM: PCI: provide a default bus scan implementation
---

I then reversed this commit on 3.7.9 and the board booted
successfully. I'm not sure if this affects other boards of the same
arch or not, I only have access to a Pronghorn which also requires a
patch for the board files as they are not part of mainline.
--
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] clocksource : nomadik-mtu : fix missing irq initialization

[Daniel Lezcano]

On 02/22/2013 06:21 PM, Linus Walleij wrote:
> On Fri, Feb 22, 2013 at 4:44 PM, Daniel Lezcano
>  wrote:
> 
>> This patch fix the clock device irq field which is not initialized.
>>
>> Signed-off-by: Daniel Lezcano 
> 
> Makes perfect sense:
> Acked-by: Linus Walleij 
> 
> Sorry that I might have missed some background here or just be
> out-of-track with things, how did this driver work for years without
> the irq assigned? Or was this field recently introduced?

The irq is assigned through:

setup_irq(irq, &nmdk_timer_irq);

two lines above but the clockevent's irq field was not set.

I did not investigate a lot, but at the first glance it worked because
the code path used by the default kernel configuration (CONFIG_NO_HZ)
does not use this field.

But when using the dynamic irq affinity [1], I noticed it was set to 0.

[1] http://www.spinics.net/lists/arm-kernel/msg226371.html

Thanks
  -- Daniel


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

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

Re: [v3.8 Regression] watchdog: sp5100_tco: Add SB8x0 chipset support

[Tanaka Takahisa]

Hi Joseph,

Thank you for testing!
I will submit this patch to the linux-watchdog community after adding
commit log to patch.

2013/2/22 Joseph Salisbury :
> The I/O data can be seen at:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1116835/+attachment/3540738/+files/iomem.txt

In the case of SP5100 and SB7x0 chipset, the sp5100_tco driver
overwrites a free resource I/O memory address obtained by
allocate_resource() to the MMIO address registers for watchdog timer.
In the case of M3A78-CM, the sp5100_tco driver was using 0xfed45000 as
a MMIO address. Since 0xfed45000 is the free I/O memory resource
address, this is the expected behavior.

  [   18.852540] sp5100_tco: Using 0xfed45000 for watchdog MMIO address

However, Rewriting the MMIO address registers for the watchdog timer
must have generated the problem. I think that the problem has occurred
with the chipset or the BIOS layer. So, It's difficult for me to
investigate the problem, and the problem is critical. Thus, I decided
to delete the concerned codes.


Regards,
Takahisa
--
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] perf: need to expose sched_clock to correlate user samples with kernel samples

[John Stultz]

On 02/20/2013 02:29 AM, Peter Zijlstra wrote:

On Tue, 2013-02-19 at 10:25 -0800, John Stultz wrote:

So describe how the perf time domain is different then
CLOCK_MONOTONIC_RAW.

The primary difference is that the trace/sched/perf time domain is not
strictly monotonic, it is only locally monotonic -- that is two time
stamps taken on the same cpu are guaranteed to be monotonic.


So how would a clock_gettime(CLOCK_PERF,...) interface help you figure 
out which cpu you got your timestamp from?




Furthermore, to make it useful, there's an actual bound on the inter-cpu
drift (implemented by limiting the drift to CLOCK_MONOTONIC).


So this sounds like you're already sort of interpolating to 
CLOCK_MONOTONIC, or am I just misunderstanding you?



Additionally -- to increase use -- we also added a monotonic sync point
when cpu A queries time of cpu B.


Not sure I'm following this bit. But I'll have to go look at the code on 
Monday.





My concern here is that we're basically creating a kernel interface
that
exports implementation-defined semantics (again: whatever perf does
right now). And I think folks want to do this, because adding
CLOCK_PERF
is easier then trying to:

1) Get a lock-free method for accessing CLOCK_MONOTONIC_RAW

2) Having perf interpolate its timestamps to CLOCK_MONOTONIC, or
CLOCKMONOTONIC_RAW when it exports the data

Mostly cheaper, not easier. Given unstable TSC, MONOTONIC will have to
fall back to another clock source (hpet, acpi_pm and other assorted
crap).

In order to avoid this, we'd had to relax the requirements. Using
anything other than TSC is simply not an option.


Right, and this I understand. We can can play a little fast and lose 
with the rules for in-kernel uses, given the variety of hardware and the 
fact that performance is more critical then perfect accuracy. Since 
we're in-kernel we also have more information then userland does about 
what cpu we're running on, so we can get away with only 
locally-monotonic timestamps.


But I want to be careful if we're exporting this out to userland that 
its both useful and that there's an actual specification for how 
CLOCK_PERF behaves, applications can rely upon not changing in the future.


thanks
-john


--
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[2]: [PATCH v5 1/3] mfd: syscon: Removed support for unloading

[Alexander Shiyan]

> On 02/22/2013 10:15 PM, Alexander Shiyan wrote:
> > The driver can be used in various subsystems and therefore should not
> > be unloaded when it is defined in the kernel configuration, so remove
> > support for unloading it.
> 
> Why not fix the clients to module_get() at the appropriate times; then
> you could still allow unloading, couldn't you?

I has explain this before. Driver defined as "bool" and loaded via 
postcore_initcall.
Once loaded it should not be unloaded, in other case it have not way to be 
loaded back.
I am correctly understand your question?
Thanks.

---
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

[PATCH v5 3/3] mfd: syscon: Add non-DT support

[Alexander Shiyan]

This patch allow using syscon driver from the platform data, i.e.
possibility using driver on systems without oftree support.
For search syscon device from the client drivers,
"syscon_regmap_lookup_by_pdevname" function was added.

Signed-off-by: Alexander Shiyan 
---
 drivers/mfd/Kconfig|  1 -
 drivers/mfd/syscon.c   | 67 --
 include/linux/mfd/syscon.h |  1 +
 3 files changed, 48 insertions(+), 21 deletions(-)

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 671f5b1..8fdd87e 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1070,7 +1070,6 @@ config MFD_STA2X11
 
 config MFD_SYSCON
bool "System Controller Register R/W Based on Regmap"
-   depends on OF
select REGMAP_MMIO
help
  Select this option to enable accessing system control registers
diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
index 2c59ce6..ead27d6 100644
--- a/drivers/mfd/syscon.c
+++ b/drivers/mfd/syscon.c
@@ -29,7 +29,7 @@ struct syscon {
struct regmap *regmap;
 };
 
-static int syscon_match(struct device *dev, void *data)
+static int syscon_match_node(struct device *dev, void *data)
 {
struct device_node *dn = data;
 
@@ -42,7 +42,7 @@ struct regmap *syscon_node_to_regmap(struct device_node *np)
struct device *dev;
 
dev = driver_find_device(&syscon_driver.driver, NULL, np,
-syscon_match);
+syscon_match_node);
if (!dev)
return ERR_PTR(-EPROBE_DEFER);
 
@@ -68,6 +68,34 @@ struct regmap *syscon_regmap_lookup_by_compatible(const char 
*s)
 }
 EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_compatible);
 
+static int syscon_match_pdevname(struct device *dev, void *data)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+   const struct platform_device_id *id = platform_get_device_id(pdev);
+
+   if (id)
+   if (!strcmp(id->name, (const char *)data))
+   return 1;
+
+   return !strcmp(dev_name(dev), (const char *)data);
+}
+
+struct regmap *syscon_regmap_lookup_by_pdevname(const char *s)
+{
+   struct device *dev;
+   struct syscon *syscon;
+
+   dev = driver_find_device(&syscon_driver.driver, NULL, (void *)s,
+syscon_match_pdevname);
+   if (!dev)
+   return ERR_PTR(-ENODEV);
+
+   syscon = dev_get_drvdata(dev);
+
+   return syscon->regmap;
+}
+EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_pdevname);
+
 struct regmap *syscon_regmap_lookup_by_phandle(struct device_node *np,
const char *property)
 {
@@ -99,30 +127,24 @@ static struct regmap_config syscon_regmap_config = {
 static int syscon_probe(struct platform_device *pdev)
 {
struct device *dev = &pdev->dev;
-   struct device_node *np = dev->of_node;
struct syscon *syscon;
-   struct resource res;
-   int ret;
-
-   if (!np)
-   return -ENOENT;
+   struct resource *res;
 
-   syscon = devm_kzalloc(dev, sizeof(struct syscon),
-   GFP_KERNEL);
+   syscon = devm_kzalloc(dev, sizeof(struct syscon), GFP_KERNEL);
if (!syscon)
return -ENOMEM;
 
-   syscon->base = of_iomap(np, 0);
-   if (!syscon->base)
-   return -EADDRNOTAVAIL;
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (!res)
+   return -ENOENT;
 
-   ret = of_address_to_resource(np, 0, &res);
-   if (ret)
-   return ret;
+   syscon->base = devm_ioremap(dev, res->start, resource_size(res));
+   if (!syscon->base)
+   return -ENOMEM;
 
-   syscon_regmap_config.max_register = res.end - res.start - 3;
+   syscon_regmap_config.max_register = res->end - res->start - 3;
syscon->regmap = devm_regmap_init_mmio(dev, syscon->base,
-   &syscon_regmap_config);
+  &syscon_regmap_config);
if (IS_ERR(syscon->regmap)) {
dev_err(dev, "regmap init failed\n");
return PTR_ERR(syscon->regmap);
@@ -130,12 +152,16 @@ static int syscon_probe(struct platform_device *pdev)
 
platform_set_drvdata(pdev, syscon);
 
-   dev_info(dev, "syscon regmap start 0x%x end 0x%x registered\n",
-   res.start, res.end);
+   dev_info(dev, "regmap 0x%x-0x%x registered\n", res->start, res->end);
 
return 0;
 }
 
+static const struct platform_device_id syscon_ids[] = {
+   { "syscon", },
+   { }
+};
+
 static struct platform_driver syscon_driver = {
.driver = {
.name = "syscon",
@@ -143,6 +169,7 @@ static struct platform_driver syscon_driver = {
.of_match_table = of_syscon_match,
},
.probe  = syscon_probe,
+   .id_table   = syscon_ids,
 };
 
 stat

Re: [PATCH v5 1/3] mfd: syscon: Removed support for unloading

[Stephen Warren]

On 02/22/2013 10:15 PM, Alexander Shiyan wrote:
> The driver can be used in various subsystems and therefore should not
> be unloaded when it is defined in the kernel configuration, so remove
> support for unloading it.

Why not fix the clients to module_get() at the appropriate times; then
you could still allow unloading, couldn't you?
--
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[2]: [PATCH v4] mfd: syscon: Add non-DT support

[Alexander Shiyan]

> On Fri, Feb 22, 2013 at 04:29:55PM +0800, Dong Aisheng wrote:
> > On Fri, Feb 22, 2013 at 08:27:19AM +0100, Thierry Reding wrote:
> > ...
> > > > > > Otherwise, i'm also ok with this patch.
> > > > > > Acked-by: Dong Aisheng 
> > > > > > 
> > > > > > BTW, i did not see Samuel's tree having this new API.
> > > > > > So, who will pick this patch?
> > > > > 
> > > > > I have same question.
> > > > 
> > > > I CCed Thierry and Greg who may know it.
> > > 
> > > Yes, devm_ioremap_resource() never returns NULL. You always need to
> > > check the returned pointer with IS_ERR(). The value that you return
> > > should be extracted from the pointer with PTR_ERR().
> > 
> > Thanks Thierry.
> > Since Samuel's mdf tree does not have your patch introducing
> > the new API of devm_ioremap_resource,
> > do you know which tree this patch can go through, Greg's driver core tree?
> 
> I don't think it matters much at this point because Linus merged the
> driver core tree yesterday, so anything that gets applied now should
> automatically have the new API available.

So, i will send all the three parts of the patch as v5 and keep all current CCs.
Thanks.

---

Re: [GIT PULL] parisc updates for 3.9

[Linus Torvalds]

On Fri, Feb 22, 2013 at 1:16 PM, Helge Deller  wrote:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git 
> parisc-3.9

In general, I'd love to also get a short human-readable explanation of
what the pull does for the merge message. As it is, I just made
something up.

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

[PATCH v5 2/3] mfd: syscon: Removed unneeded field "dev" from private driver structure

[Alexander Shiyan]

Signed-off-by: Alexander Shiyan 
---
 drivers/mfd/syscon.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
index 55d7915..2c59ce6 100644
--- a/drivers/mfd/syscon.c
+++ b/drivers/mfd/syscon.c
@@ -25,17 +25,15 @@
 static struct platform_driver syscon_driver;
 
 struct syscon {
-   struct device *dev;
void __iomem *base;
struct regmap *regmap;
 };
 
 static int syscon_match(struct device *dev, void *data)
 {
-   struct syscon *syscon = dev_get_drvdata(dev);
struct device_node *dn = data;
 
-   return (syscon->dev->of_node == dn) ? 1 : 0;
+   return (dev->of_node == dn) ? 1 : 0;
 }
 
 struct regmap *syscon_node_to_regmap(struct device_node *np)
@@ -130,7 +128,6 @@ static int syscon_probe(struct platform_device *pdev)
return PTR_ERR(syscon->regmap);
}
 
-   syscon->dev = dev;
platform_set_drvdata(pdev, syscon);
 
dev_info(dev, "syscon regmap start 0x%x end 0x%x registered\n",
-- 
1.7.12.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 v5 1/3] mfd: syscon: Removed support for unloading

[Alexander Shiyan]

The driver can be used in various subsystems and therefore should not
be unloaded when it is defined in the kernel configuration, so remove
support for unloading it.

Signed-off-by: Alexander Shiyan 
---
 drivers/mfd/syscon.c | 18 --
 1 file changed, 18 deletions(-)

diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
index 61aea63..55d7915 100644
--- a/drivers/mfd/syscon.c
+++ b/drivers/mfd/syscon.c
@@ -139,17 +139,6 @@ static int syscon_probe(struct platform_device *pdev)
return 0;
 }
 
-static int syscon_remove(struct platform_device *pdev)
-{
-   struct syscon *syscon;
-
-   syscon = platform_get_drvdata(pdev);
-   iounmap(syscon->base);
-   platform_set_drvdata(pdev, NULL);
-
-   return 0;
-}
-
 static struct platform_driver syscon_driver = {
.driver = {
.name = "syscon",
@@ -157,7 +146,6 @@ static struct platform_driver syscon_driver = {
.of_match_table = of_syscon_match,
},
.probe  = syscon_probe,
-   .remove = syscon_remove,
 };
 
 static int __init syscon_init(void)
@@ -166,12 +154,6 @@ static int __init syscon_init(void)
 }
 postcore_initcall(syscon_init);
 
-static void __exit syscon_exit(void)
-{
-   platform_driver_unregister(&syscon_driver);
-}
-module_exit(syscon_exit);
-
 MODULE_AUTHOR("Dong Aisheng ");
 MODULE_DESCRIPTION("System Control driver");
 MODULE_LICENSE("GPL v2");
-- 
1.7.12.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] regulators: max8998.c: use dev_err() instead of printk()

[Thiago Farina]

Fixes the following checkpatch warning:

WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: Thiago Farina 
---
 drivers/regulator/max8998.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/regulator/max8998.c b/drivers/regulator/max8998.c
index b588f07..a57a1b1 100644
--- a/drivers/regulator/max8998.c
+++ b/drivers/regulator/max8998.c
@@ -665,14 +665,16 @@ static int max8998_pmic_probe(struct platform_device 
*pdev)
gpio_is_valid(pdata->buck1_set2)) {
/* Check if SET1 is not equal to 0 */
if (!pdata->buck1_set1) {
-   printk(KERN_ERR "MAX8998 SET1 GPIO defined as 0 !\n");
+   dev_err(&pdev->dev,
+   "MAX8998 SET1 GPIO defined as 0 !\n");
WARN_ON(!pdata->buck1_set1);
ret = -EIO;
goto err_out;
}
/* Check if SET2 is not equal to 0 */
if (!pdata->buck1_set2) {
-   printk(KERN_ERR "MAX8998 SET2 GPIO defined as 0 !\n");
+   dev_err(&pdev->dev,
+   "MAX8998 SET2 GPIO defined as 0 !\n");
WARN_ON(!pdata->buck1_set2);
ret = -EIO;
goto err_out;
@@ -738,7 +740,8 @@ static int max8998_pmic_probe(struct platform_device *pdev)
if (gpio_is_valid(pdata->buck2_set3)) {
/* Check if SET3 is not equal to 0 */
if (!pdata->buck2_set3) {
-   printk(KERN_ERR "MAX8998 SET3 GPIO defined as 0 !\n");
+   dev_err(&pdev->dev,
+   "MAX8998 SET3 GPIO defined as 0 !\n");
WARN_ON(!pdata->buck2_set3);
ret = -EIO;
goto err_out;
-- 
1.8.1.151.g32238ae

--
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 2/2] lib/scatterlist: use page iterator in the mapping iterator

[Stephen Warren]

On 02/13/2013 08:10 AM, Imre Deak wrote:
> For better code reuse use the newly added page iterator to iterate
> through the pages. The offset, length within the page is still
> calculated by the mapping iterator as well as the actual mapping.
> Idea from Tejun Heo .

This patch appears in linux-next since next-20130220. It breaks mounting
a root filesystem on an SD card on the Raspberry Pi ARM platform, with
errors such as those shown below.

next-20130222 with just this patch reverted works fine.

> [0.708426] VFS: Mounted root (ext4 filesystem) on device 179:2.
> [0.723742] devtmpfs: mounted
> [0.733064] Freeing init memory: 204K
> [0.777992] EXT4-fs error (device mmcblk0p2): ext4_iget:3814: inode #4259: 
> comm swapper: bad extra_isize (57200 != 256)
> [0.815172] EXT4-fs error (device mmcblk0p2): ext4_lookup:1428: inode 
> #8198: comm swapper: deleted inode referenced: 487
> [0.826179] Kernel panic - not syncing: No init found.  Try passing init= 
> option to kernel. See Linux Documentation/init.txt for guidance.

> [0.719365] VFS: Mounted root (ext4 filesystem) on device 179:2.
> [0.740918] devtmpfs: mounted
> [0.745219] Freeing init memory: 204K
> ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libcofi_rpi.so' from 
> /etc/ld.so.preload cannot be preloaded: ignored.
> [0.906840] Kernel panic - not syncing: Attempted to kill init! 
> exitcode=0x000b

> [0.724018] VFS: Mounted root (ext4 filesystem) on device 179:2.
> [0.739404] devtmpfs: mounted
> [0.748741] Freeing init memory: 204K
> [0.793603] EXT4-fs error (device mmcblk0p2): ext4_iget:3814: inode #4259: 
> comm swapper: bad extra_isize (57200 != 256)
> [0.822138] Kernel panic - not syncing: No init found.  Try passing init= 
> option to kernel. See Linux Documentation/init.txt for guidance.


--
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: [GIT PATCH] USB patches for 3.9-rc1

[Rafael J. Wysocki]

On Saturday, February 23, 2013 02:44:27 AM Fabio Baltieri wrote:
> On Sat, Feb 23, 2013 at 01:35:26AM +0100, Rafael J. Wysocki wrote:
> > On Saturday, February 23, 2013 01:10:55 AM Fabio Baltieri wrote:
> > > Well, this did the trick in my case:
> > > 
> > > --- >8 ---
> > > diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c
> > > index b820528..54175a0 100644
> > > --- a/drivers/acpi/power.c
> > > +++ b/drivers/acpi/power.c
> > > @@ -795,7 +795,7 @@ int acpi_add_power_resource(acpi_handle handle)
> > > int state, result = -ENODEV;
> > >  
> > > acpi_bus_get_device(handle, &device);
> > > -   if (device)
> > > +   if (!device)
> > > return 0;
> > >  
> > > resource = kzalloc(sizeof(*resource), GFP_KERNEL);
> > > --- >8 ---
> > > 
> > > But I guess it's working as a coincidence and something else is wrong -
> > > I'll not even try to make a patch out of it and will leave the dirty
> > > work to the ACPI guys instead.
> > 
> > Well, this patch effectively disables the handling of power resources on 
> > your
> > machine entirely.  The effect of which is probably that the power resources
> > can't be turned off for the USB controllers, so they don't go into D3cold.
> 
> Ok, as I wrote, I suspected this was just shutting off something and not
> solving the real problem.
> 
> So, I'll try to recap all the threads here:
> 
> > And the bisection found a commit that restores the handling of power 
> > resources
> > for you, which is not entirely surprising, but the root cause is somewhere 
> > else
> > most likely.
> 
> Indeed.
> 
> > The new sysfs interface for power resources control may be helpful here.  
> > You
> > need to use the Linus' current for it to work, though.
> > 
> > Can you please do
> > 
> > $ find /sys/devices/LNXSYSTM:00/ -name power_state -print -exec cat {} \;
> > $ find /sys/devices/LNXSYSTM:00/ -name real_power_state -print -exec cat {} 
> > \;
> > $ find /sys/devices/LNXSYSTM:00/ -name power_resources_D\* -print -exec ls 
> > {} \;
> > $ find /sys/devices/LNXSYSTM:00/ -name resource_in_use -print -exec cat {} 
> > \;
> > and send the output?
> 
> With the acpi_add_power_resource disabled all power_state read "D0",
> other attributes are not generated.

Yup.  That's how it should be.

> With a plain kernel that's the output:
> 
> $ find /sys/devices/LNXSYSTM:00/ -name power_state -print -exec cat {} \;
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:09/LNXVIDEO:01/power_state
> D0
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_state
> D0
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_state
> D0
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_state
> D0
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/power_state
> D0
> 
> $ find /sys/devices/LNXSYSTM:00/ -name real_power_state -print -exec cat {} \;
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/real_power_state
> D3cold
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/real_power_state
> D3cold
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/real_power_state
> D3cold

This is obviously wrong.  We expect the devices to be in D0, while they really
are in D3cold.  Let's look deeper.

> $ find /sys/devices/LNXSYSTM:00/ -name power_resources_D\* -print -exec ls {} 
> \;
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D0
> LNXPOWER:00
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D1
> LNXPOWER:00
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D2
> LNXPOWER:00
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D0
> LNXPOWER:00
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D1
> LNXPOWER:00
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D2
> LNXPOWER:00
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D0
> LNXPOWER:00
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D1
> LNXPOWER:00
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D2
> LNXPOWER:00

PNP0A08 is the PCI root bridge and device:29, device:34, device:1f are the USB
controllers.  All of them have ACPI power states D0, D1, D2 and D3cold, where
D0-D2 depend on the same power resource, so in fact they all are the same state
(what sense does this make?).

I suspect that the power resource being shared (and it being shared in such a
broken way) has to do something with the breakage.

> $ find /sys/devices/LNXSYSTM:00/ -name resource_in_use -print -exec cat {} \;
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:08/PNP0C09:00/LNXPOWER:00/resource_in_use
> 0

There's one power resource in the system and it's usage count is 0, so it is
"off" (which is consistent with the real power states of the USB controllers).

Now, the boot log shows that the power resource was "on" when it 

Re: [PATCH v4 1/2] cpufreq: Convert the cpufreq_driver_lock to a rwlock

[Viresh Kumar]

On 22 February 2013 21:54, Nathan Zimmer  wrote:
> This eliminates the contention I am seeing in __cpufreq_cpu_get.
> It also nicely stages the lock to be replaced by the rcu.
>
> Cc: Viresh Kumar 
> Cc: "Rafael J. Wysocki" 
> Signed-off-by: Nathan Zimmer 

Acked-by: Viresh Kumar 

@Rafael: I am too bored of seeing this patch again and again :)
Can we get this applied alone for now?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] regulators: max8998.c: use dev_err() instead of printk()

[Thiago Farina]

Fixes the following checkpatch warning:

WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: Thiago Farina 
---
 drivers/regulator/max8998.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/regulator/max8998.c b/drivers/regulator/max8998.c
index faeb7e8..a57a1b1 100644
--- a/drivers/regulator/max8998.c
+++ b/drivers/regulator/max8998.c
@@ -666,7 +666,7 @@ static int max8998_pmic_probe(struct platform_device *pdev)
/* Check if SET1 is not equal to 0 */
if (!pdata->buck1_set1) {
dev_err(&pdev->dev,
-"MAX8998 SET1 GPIO defined as 0 !\n");
+   "MAX8998 SET1 GPIO defined as 0 !\n");
WARN_ON(!pdata->buck1_set1);
ret = -EIO;
goto err_out;
@@ -674,7 +674,7 @@ static int max8998_pmic_probe(struct platform_device *pdev)
/* Check if SET2 is not equal to 0 */
if (!pdata->buck1_set2) {
dev_err(&pdev->dev,
-"MAX8998 SET2 GPIO defined as 0 !\n");
+   "MAX8998 SET2 GPIO defined as 0 !\n");
WARN_ON(!pdata->buck1_set2);
ret = -EIO;
goto err_out;
@@ -740,7 +740,8 @@ static int max8998_pmic_probe(struct platform_device *pdev)
if (gpio_is_valid(pdata->buck2_set3)) {
/* Check if SET3 is not equal to 0 */
if (!pdata->buck2_set3) {
-   printk(KERN_ERR "MAX8998 SET3 GPIO defined as 0 !\n");
+   dev_err(&pdev->dev,
+   "MAX8998 SET3 GPIO defined as 0 !\n");
WARN_ON(!pdata->buck2_set3);
ret = -EIO;
goto err_out;
-- 
1.8.1.151.g32238ae

--
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 v4 2/2] cpufreq: Convert the cpufreq_driver_lock to use the rcu

[Viresh Kumar]

Hi Nathan,

Sorry for pointing out this so late but i still feel we are missing something
really important.

On 22 February 2013 21:54, Nathan Zimmer  wrote:

> -   read_lock_irqsave(&cpufreq_driver_lock, flags);
> +   rcu_read_lock();
> +   freqs->flags = rcu_dereference(cpufreq_driver)->flags;
> policy = per_cpu(cpufreq_cpu_data, freqs->cpu);
> -   read_unlock_irqrestore(&cpufreq_driver_lock, flags);
> +   rcu_read_unlock();

> -   write_lock_irqsave(&cpufreq_driver_lock, flags);
> +   spin_lock_irqsave(&cpufreq_driver_lock, flags);
> for_each_cpu(j, policy->cpus) {
> per_cpu(cpufreq_cpu_data, j) = policy;
> per_cpu(cpufreq_policy_cpu, j) = policy->cpu;
> }
> -   write_unlock_irqrestore(&cpufreq_driver_lock, flags);
> +   spin_unlock_irqrestore(&cpufreq_driver_lock, flags);

Look at how we are protecting cpufreq_cpu_data here. rcu_read_[un]lock()
only marks the start/end of critical section. How are we sure here that
cpufreq_cpu_data is not read simultaneously when we are updating it?

rcu lock/unlock only works for cpufreq_driver pointer only and not for
this data. We still need the same locking for for cpufreq_cpu_data.

What do you say?
--
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] tty: fix ldisc flush and termios setting race

[Min Zhang]

From: Min Zhang 

A race condition can clear tty ldisc icanon bit unintentionally which 
could stop n_tty from processing received characters. It can occur when
tty receiver buffer was full, e.g. 4096 chars received, 8250 serial driver
interrupt tried to flush_to_ldisc them, but other shell thread tried
to change_termios the tty setting too. Then n_tty_receive_char and
n_tty_set_termios both tried to modify n_tty_data fields.

Specifically the icanon and its neighbor fields are defines as bits:

unsigned char lnext:1, erasing:1, raw:1, real_raw:1, icanon:1;

However they are not atomically accessed in the follow race condition:

serial8250_handle_irq
  serail8250_rx_chars
tty_flip_buffer_push
  schdule_work ---> flush_to_ldisc
  n_tty_receive_buf
n_tty_receive_char
  (holds no lock)
ioctl
  set_termios
tty_set_termios
  n_tty_set_termios
(holds termios_mutex)

The patch let change_termios to use TTY_LDISC_FLUSHING to prevent
flush_to_ldisc from running, and flush_to_ldisc use TTY_FLUSHING
to make change_termios wait until the flag is cleared.

The patch also replaces flush_to_ldisc's wake_up with wake_up_all,
because it can now wake up both TTY_FLUSHING and TTY_FLUSHPENDING
on the same tty->read_wait queue. Event waiters need check which event.

Signed-off-by: Min Zhang 
---
 drivers/tty/tty_buffer.c |   12 +++-
 drivers/tty/tty_ioctl.c  |   27 ++-
 2 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index 45d9161..37f4818 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -482,6 +482,13 @@ static void flush_to_ldisc(struct work_struct *work)
 
spin_lock_irqsave(&buf->lock, flags);
 
+   /* Ldisc change by change_termios can race with ldisc receive_buf, esp
+  to access N_TTY line discipline field in tty_struct, so we defer */
+   if (test_bit(TTY_LDISC_CHANGING, &tty->flags)) {
+   schedule_delayed_work(&buf->work, 1);
+   goto out;
+   }
+
if (!test_and_set_bit(TTYP_FLUSHING, &port->iflags)) {
struct tty_buffer *head;
while ((head = buf->head) != NULL) {
@@ -522,8 +529,11 @@ static void flush_to_ldisc(struct work_struct *work)
if (test_bit(TTYP_FLUSHPENDING, &port->iflags)) {
__tty_buffer_flush(port);
clear_bit(TTYP_FLUSHPENDING, &port->iflags);
-   wake_up(&tty->read_wait);
}
+
+   /* wake up tasks waiting for TTYP_FLUSHING or TTYP_FLUSHPENDING */
+   wake_up_all(&tty->read_wait);
+out:
spin_unlock_irqrestore(&buf->lock, flags);
 
tty_ldisc_deref(disc);
diff --git a/drivers/tty/tty_ioctl.c b/drivers/tty/tty_ioctl.c
index 8481b29..36a1bfa 100644
--- a/drivers/tty/tty_ioctl.c
+++ b/drivers/tty/tty_ioctl.c
@@ -546,8 +546,33 @@ int tty_set_termios(struct tty_struct *tty, struct 
ktermios *new_termios)
 
ld = tty_ldisc_ref(tty);
if (ld != NULL) {
-   if (ld->ops->set_termios)
+   unsigned long   flags;
+   struct tty_port *port = tty->port;
+   struct tty_bufhead *buf = &port->buf;
+   if (!ld->ops->set_termios)
+   goto no_set_termios;
+
+   /* Wait if the data is being pushed to the tty layer */
+   spin_lock_irqsave(&buf->lock, flags);
+   while (test_bit(TTYP_FLUSHING, &port->iflags)) {
+   spin_unlock_irqrestore(&buf->lock, flags);
+   printk(KERN_CRIT "%s flushing\n", __FUNCTION__);
+   wait_event(tty->read_wait,
+  test_bit(TTYP_FLUSHING, &port->iflags) == 0);
+   spin_lock_irqsave(&buf->lock, flags);
+   }
+   printk(KERN_CRIT "%s survived flushing\n", __FUNCTION__);
+
+   /* Prevent future flush_to_ldisc while we are setting */
+   if (!test_and_set_bit(TTY_LDISC_CHANGING, &tty->flags)) {
+   spin_unlock_irqrestore(&buf->lock, flags);
(ld->ops->set_termios)(tty, &old_termios);
+   spin_lock_irqsave(&buf->lock, flags);
+   clear_bit(TTY_LDISC_CHANGING, &tty->flags);
+   }
+   spin_unlock_irqrestore(&buf->lock, flags);
+
+no_set_termios:
tty_ldisc_deref(ld);
}
mutex_unlock(&tty->termios_mutex);
-- 
1.7.7.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 v6] arm: use built-in byte swap function

[Nicolas Pitre]

On Fri, 22 Feb 2013, Kim Phillips wrote:

> On Thu, 21 Feb 2013 22:40:08 -0500
> Nicolas Pitre  wrote:
> 
> > On Thu, 21 Feb 2013, Kim Phillips wrote:
> > 
> > > Here's the asm version I'm working on now, based on compiler
> > > output of the C version.  Haven't tested beyond defconfig builds,
> > > which pass ok.
> > > 
> > > Is there anything I have to do for thumb mode?  If so, how to test?
> > 
> > You just need to pick a config that uses some ARMv7 processor, and 
> > enable CONFIG_THUMB2_KERNEL.  I don't see any problem with your patch 
> > wrt Thumb2.
> 
> ok, I've addressed your comments and tested both pre-armv6 and armv6
> + bswapsi2s on i.mx hardware with CONFIG_CC_OPTIMIZE_FOR_SIZE and
> CONFIG_THUMB2_KERNEL set:
> 
> >From c22f4050174d8da71fdddba2cf67ae40c00ca5cc Mon Sep 17 00:00:00 2001
> From: Kim Phillips 
> Date: Tue, 19 Feb 2013 17:16:11 -0600
> Subject: [PATCH] arm: use built-in byte swap function
> 
> Enable the compiler intrinsic for byte swapping on arch ARM.  This
> allows the compiler to detect and be able to optimize out byte
> swappings, and has a tiny benefit on vmlinux size (Linaro gcc 4.7.3):
> 
>text  data bss dec hex filename
> 2754100121144   56520 2931764  2cbc34 vmlinux-lart #orig
> 2754050121144   56520 2931714  2cbc02 vmlinux-lart #builtin-bswap
> 6282699307852 5578076 12168627 b9adb3 vmlinux-mxs #orig
> 6282241307832 5578076 12168149 b9abd5 vmlinux-mxs #builtin-bswap
> 7200193364180  361748 7926121  78f169 vmlinux-imx_v6_v7 #orig
> 7199515364188  361748 7925451  78eecb vmlinux-imx_v6_v7 #builtin-bswap
> 
> Signed-off-by: Kim Phillips 

Reviewed-by: Nicolas Pitre 


> ---
> akin to: http://comments.gmane.org/gmane.linux.kernel.cross-arch/16016
> 
> based on linux-next-20130221.
> 
> changes from last diff:
> - addressed Nicolas' comments
> - updated commit text figures and reformatted as a patch
> 
> changes from diff before that:
> - 1st asm version
> 
> changes from diff before that:
> - enforce -O2 for bswapsdi2.o
> - fix building out-of-source tree
> 
> changes from diff before that:
> - implement custom __bswap[sd]i2 in arch/arm/lib/bswapsdi2.c
> 
> v5: re-work based on new gcc version test data:
>   - moved outside armv6 protection
>   - check for gcc 4.6+ demoted to gcc 4.5+ with:
> !defined(CONFIG_CC_OPTIMIZE_FOR_SIZE)
> 
> v4:
> - undo v2-2's addition of ARCH_DEFINES_BUILTIN_BSWAP per Boris
>   and David - object is to find arches that define _HAVE_BSWAP
>   and clean it up in the future: patch is much less intrusive. :)
> 
> v3:
> - moved out of uapi swab.h into arch/arm/include/asm/swab.h
> - moved ARCH_DEFINES_BUILTIN_BSWAP help text into commit message
> - moved GCC_VERSION >= 40800 ifdef into GCC_VERSION >= 40600 block
> 
> v2:
> - at91 and lpd270 builds fixed by limiting to ARMv6 and above
>   (i.e., ARM cores that have support for the 'rev' instruction).
>   Otherwise, the compiler emits calls to libgcc's __bswapsi2 on
>   these ARMv4/v5 builds (and arch ARM doesn't link with libgcc).
>   All ARM defconfigs now have the same build status as they did
>   without this patch (some are broken on linux-next).
> 
> - move ARM check from generic compiler.h to arch ARM's swab.h.
>   - pretty sure it should be limited to __KERNEL__ builds
> 
> - add new ARCH_DEFINES_BUILTIN_BSWAP (see Kconfig help).
>   - if set, generic compiler header does not set HAVE_BUILTIN_BSWAPxx
>   - not too sure about this having to be a new CONFIG_, but it's hard
> to find a place for it given linux/compiler.h doesn't include any
> arch-specific files.
> 
> - move new selects to end of CONFIG_ARM's Kconfig select list,
>   as is done in David Woodhouse's original patchseries for ppc/x86.
> 
>  arch/arm/Kconfig  |  1 +
>  arch/arm/boot/compressed/Makefile | 15 +++
>  arch/arm/kernel/armksyms.c|  4 
>  arch/arm/lib/Makefile |  2 +-
>  arch/arm/lib/bswapsdi2.S  | 36 
>  5 files changed, 53 insertions(+), 5 deletions(-)
>  create mode 100644 arch/arm/lib/bswapsdi2.S
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index dedf02b..e8a41d0 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -59,6 +59,7 @@ config ARM
>   select CLONE_BACKWARDS
>   select OLD_SIGSUSPEND3
>   select OLD_SIGACTION
> + select ARCH_USE_BUILTIN_BSWAP
>   help
> The ARM series is a line of low-power-consumption RISC chip designs
> licensed by ARM Ltd and targeted at embedded applications and
> diff --git a/arch/arm/boot/compressed/Makefile 
> b/arch/arm/boot/compressed/Makefile
> index 5cad8a6..d9b5ee5 100644
> --- a/arch/arm/boot/compressed/Makefile
> +++ b/arch/arm/boot/compressed/Makefile
> @@ -108,12 +108,12 @@ endif
>  
>  targets   := vmlinux vmlinux.lds \
>piggy.$(suffix_y) piggy.$(suffix_y).o \
> -  lib1funcs.o lib1funcs.S ashldi3.o ashldi3.S \
> -  

Crypto Update for 3.9

[Herbert Xu]

Hi Linus:

Here is the crypto update for 3.9:

* Added accelerated implementation of crc32 using pclmulqdq.
* Added test vector for fcrypt.
* Added support for OMAP4/AM33XX cipher and hash.
* Fixed loose crypto_user input checks.
* Misc fixes.


Please pull from

git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git


Alexander Boyko (1):
  crypto: crc32 - add crc32 pclmulqdq implementation and wrappers for table 
implementation

Herbert Xu (1):
  crypto: crc32-pclmul - Kill warning on x86-32

Jingoo Han (1):
  crypto: s5p-sss - Use devm_clk_get()

Julia Lawall (3):
  crypto: bfin_crc - reposition free_irq to avoid access to invalid data
  crypto: atmel-aes - adjust duplicate test
  crypto: use ERR_CAST

Jussi Kivilinna (13):
  crypto: testmgr - add test vector for fcrypt
  crypto: x86/aes - assembler clean-ups: use ENTRY/ENDPROC, localize jump 
targets
  crypto: aesni-intel - add ENDPROC statements for assembler functions
  crypto: blowfish-x86_64: use ENTRY()/ENDPROC() for assembler functions 
and localize jump targets
  crypto: camellia-x86_64/aes-ni: use ENTRY()/ENDPROC() for assembler 
functions and localize jump targets
  crypto: cast5-avx: use ENTRY()/ENDPROC() for assembler functions and 
localize jump targets
  crypto: cast6-avx: use ENTRY()/ENDPROC() for assembler functions
  crypto: x86/crc32c - assembler clean-up: use ENTRY/ENDPROC
  crypto: x86/ghash - assembler clean-up: use ENDPROC at end of assember 
functions
  crypto: x86/salsa20 - assembler cleanup, use ENTRY/ENDPROC for assember 
functions and rename ECRYPT_* to salsa20_*
  crypto: x86/serpent - use ENTRY/ENDPROC for assember functions and 
localize jump targets
  crypto: x86/sha1 - assembler clean-ups: use ENTRY/ENDPROC
  crypto: x86/twofish - assembler clean-ups: use ENTRY/ENDPROC, localize 
jump labels

Mark A. Greer (20):
  crypto: omap-sham - Remove unnecessary pr_info noise
  crypto: omap-sham - Convert to use pm_runtime API
  crypto: omap-sham - Add suspend/resume support
  crypto: omap-sham - Add code to use dmaengine API
  crypto: omap-sham - Remove usage of private DMA API
  crypto: omap-sham - Add Device Tree Support
  crypto: omap-sham - Convert to dma_request_slave_channel_compat()
  crypto: omap-sham - Add OMAP4/AM33XX SHAM Support
  crypto: omap-sham - Add SHA224 and SHA256 Support
  crypto: omap-aes - Remmove unnecessary pr_info noise
  crypto: omap-aes - Don't reset controller for every operation
  crypto: omap-aes - Convert to use pm_runtime API
  crypto: omap-aes - Add suspend/resume support
  crypto: omap-aes - Add code to use dmaengine API
  crypto: omap-aes - Remove usage of private DMA API
  crypto: omap-aes - Add Device Tree Support
  crypto: omap-aes - Convert to dma_request_slave_channel_compat()
  crypto: omap-aes - Add OMAP4/AM33XX AES Support
  crypto: omap-aes - Add CTR algorithm Support
  crypto: omap-sham - Fix compile errors when CONFIG_OF not defined

Mathias Krause (3):
  crypto: user - fix info leaks in report API
  crypto: user - fix empty string test in report API
  crypto: user - ensure user supplied strings are nul-terminated

Vakul Garg (1):
  crypto: caam - Added property fsl,sec-era in SEC4.0 device tree binding.

 .../devicetree/bindings/crypto/fsl-sec4.txt|   12 +-
 arch/x86/crypto/Makefile   |2 +
 arch/x86/crypto/aes-i586-asm_32.S  |   15 +-
 arch/x86/crypto/aes-x86_64-asm_64.S|   30 +-
 arch/x86/crypto/aesni-intel_asm.S  |   23 +-
 arch/x86/crypto/blowfish-x86_64-asm_64.S   |   39 +-
 arch/x86/crypto/camellia-aesni-avx-asm_64.S|   38 +-
 arch/x86/crypto/camellia-x86_64-asm_64.S   |   50 +-
 arch/x86/crypto/cast5-avx-x86_64-asm_64.S  |   48 +-
 arch/x86/crypto/cast6-avx-x86_64-asm_64.S  |   35 +-
 arch/x86/crypto/crc32-pclmul_asm.S |  246 ++
 arch/x86/crypto/crc32-pclmul_glue.c|  201 +
 arch/x86/crypto/crc32c-pcl-intel-asm_64.S  |8 +-
 arch/x86/crypto/ghash-clmulni-intel_asm.S  |4 +
 arch/x86/crypto/salsa20-i586-asm_32.S  |   28 +-
 arch/x86/crypto/salsa20-x86_64-asm_64.S|   28 +-
 arch/x86/crypto/salsa20_glue.c |5 -
 arch/x86/crypto/serpent-avx-x86_64-asm_64.S|   35 +-
 arch/x86/crypto/serpent-sse2-i586-asm_32.S |   20 +-
 arch/x86/crypto/serpent-sse2-x86_64-asm_64.S   |   20 +-
 arch/x86/crypto/sha1_ssse3_asm.S   |   10 +-
 arch/x86/crypto/twofish-avx-x86_64-asm_64.S|   35 +-
 arch/x86/crypto/twofish-i586-asm_32.S  |   11 +-
 arch/x86/crypto/twofish-x86_64-asm_64-3way.S   |   20 +-
 arch/x86/crypto/twofish-x86_64-asm_64.S|   11 +-
 crypto/Kconfig |   21 +
 crypto/Makef

[GIT PULL] LED subsystem update for v3.9

[Bryan Wu]

The following changes since commit 88b62b915b0b7e25870eb0604ed9a92ba4bfc9f7:

  Linux 3.8-rc6 (2013-02-01 12:08:14 +1100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds.git for-next

for you to fetch changes up to 4b07c5d5123f76487c61cf9dc3f987d0b8c88a94:

  leds: leds-sunfire: use dev_err()/pr_err() instead of printk()
(2013-02-06 16:00:43 -0800)


Axel Lin (5):
  leds: pca9532: Convert to devm_input_allocate_device()
  leds: lm3530: Ensure drvdata->enable has correct status if
regulator_disable fails
  leds: renesas-tpu: Improve the readability to pick the lowest
acceptable rate
  leds: tca6507: Use of_get_child_count()
  leds: 88pm860x: Add missing of_node_put()

Jingoo Han (6):
  leds: lm355x: rename devAttr to avoid CamelCase
  leds: lm3642: rename devAttr to avoid CamelCase
  leds: pca9532: fix suspect code indent for conditional statements
  leds: leds-ss4200: use DEFINE_PCI_DEVICE_TABLE
  leds: wm831x: add missing const
  leds: leds-sunfire: use dev_err()/pr_err() instead of printk()

Kim, Milo (1):
  leds-lp8788: fix a parent device in _probe()

Marek Belisko (2):
  leds/tca6507: Add support for devicetree.
  leds/tca6507: DT: Add documentation for tca6507 devicetree bindings.

Milo(Woogyom) Kim (39):
  leds-lp55xx: clean up init_device() in lp5521/5523
  leds-lp55xx: clean up deinit_device() in lp5521/5523
  leds-lp55xx: clean up init leds in lp5521/5523
  leds-lp55xx: clean up deinit leds in lp5521/5523
  leds-lp55xx: add device reset function in lp5521/5523
  leds-lp55xx: do chip specific configuration on device init
  leds-lp55xx: add new common driver for lp5521/5523
  leds-lp55xx: replace name of data structure
  leds-lp55xx: use common lp55xx data structure in _probe()
  leds-lp5521: clean up lp5521_configure()
  leds-lp5523: clean up lp5523_configure()
  leds-lp55xx: use lp55xx common init function - platform data
  leds-lp55xx: use lp55xx common init function - reset
  leds-lp55xx: use lp55xx common init function - detect
  leds-lp55xx: use lp55xx common init function - post int
  leds-lp55xx: clean up init function
  leds-lp55xx: use lp55xx common deinit function
  leds-lp55xx: use lp55xx common led registration function
  leds-lp55xx: use lp55xx_init_led() common function
  leds-lp55xx: use lp55xx_set_brightness()
  leds-lp55xx: provide common LED current setting
  leds-lp55xx: use lp55xx_unregister_leds()
  leds-lp55xx: fix error condition in lp55xx_register_leds()
  leds-lp55xx: add new lp55xx_register_sysfs() for the firmware interface
  leds-lp55xx: support firmware interface
  leds-lp5521: use generic firmware interface
  leds-lp5523: use generic firmware interface
  leds-lp55xx: support device specific attributes
  leds-lp55xx: use common device attribute driver function
  leds-lp55xx: code refactoring on selftest function
  leds-lp55xx: add new function for removing device attribtues
  leds-lp55xx: clean up _remove()
  leds-lp55xx: clean up unused data and functions
  leds-lp55xx: clean up definitions
  leds-lp55xx: clean up headers
  leds-lp5521/5523: use new lp55xx common header
  leds-lp5521/5523: add author and copyright description
  leds-lp55xx: fix problem on removing LED attributes
  Documentation: leds: update LP55xx family devices

Peter Ujfalusi (8):
  leds: leds-pwm: Convert to use devm_get_pwm
  leds: leds-pwm: Preparing the driver for device tree support
  pwm: Correct parameter name in header for *pwm_get() functions
  pwm: core: Rename of_pwm_request() to of_pwm_get() and export it
  pwm: Add devm_of_pwm_get() as exported API for users
  leds: leds-pwm: Simplify cleanup code
  leds: leds-pwm: Add device tree bindings
  leds: leds-pwm: make it depend on PWM and not HAVE_PWM

 .../devicetree/bindings/leds/leds-pwm.txt  |   48 +
 Documentation/devicetree/bindings/leds/tca6507.txt |   33 +
 Documentation/leds/00-INDEX|2 +
 Documentation/leds/leds-lp5521.txt |   63 +-
 Documentation/leds/leds-lp5523.txt |   27 +-
 Documentation/leds/leds-lp55xx.txt |  118 +++
 arch/arm/mach-omap2/board-rx51-peripherals.c   |8 +-
 arch/arm/mach-ux500/board-mop500.c |   14 +-
 drivers/leds/Kconfig   |   12 +-
 drivers/leds/Makefile  |1 +
 drivers/leds/leds-88pm860x.c   |5 +-
 drivers/leds/leds-lm3530.c |   58 +-
 drivers/leds/leds-lm355x.c |2 +-
 drivers/leds/leds-lm3642.c |4 +-
 drivers/leds/leds-lp5521.c |  944 +-
 

Re: [GIT PATCH] USB patches for 3.9-rc1

[Rafael J. Wysocki]

On Friday, February 22, 2013 05:10:43 PM Linus Torvalds wrote:
> On Fri, Feb 22, 2013 at 4:48 PM, Rafael J. Wysocki  wrote:
> >
> > The problem is, though, that even if bisection turns up something, it 
> > doesn't
> > automatically mean that this particular commit is the one that caused the
> > problem to happen in the first place.
> 
> No, I agree. I just react *very* strongly when somebody starts arguing
> against reverting.
> 
> The fact that the commit that was bisected fixes another bug in a
> previous commit does in fact just imply that that *previous* commit
> should perhaps be reverted. Of course, I see that that is the first in
> the whole series, so I understand the pain, but even so..
> 
> And looking at that commit that makes power resources be treated
> specially, that looks completely bogus. It's not what the old code did
> either, and it seems to be a total hack for the breakage that just
> happens to fix that one machine for purely random reasons, as far as I
> can tell. The ACPI_BUS_TYPE_POWER case always had match=1 before, no?

It had, when it was called from acpi_bus_add_power_resource(), but that
was not the only way power resources could be added.  That function was only
called when we found a device using power resources and we needed to add them
before adding that device (if they were not present already).

The second way we could add power resources was during the normal namespace
walk and that case was broken.

> The thing that looks to have been dropped somewhere is that
> 
>   .acpi_op_start = !!context,
> 
> which first became
> 
>   device->add_type = context ? ACPI_BUS_ADD_START : ACPI_BUS_ADD_MATCH;
> 
> and then somehow that wasn't needed any more, so it became just an 
> unconditional
> 
>   device->add_type = ACPI_BUS_ADD_START;
> 
> for unexplained reasons (the commit message says that the argument
> "context" wasn't used, and renames it not_used to reinforce the point,
> but doesn't explain why it can remove the use that was there).
> 
> That unconditional "add_type = ACPI_BUS_ADD_START" then later becomes
> "flags.match_driver = true", which is where the whole match_driver
> thing comes in.
> 
> Anyway, I don't see how magically it became about ACPI_BUS_TYPE_POWER.

If we added a power resource with acpi_add_single_object(..., false) from
acpi_bus_check_add(), later acpi_bus_add_power_resource() saw that it
was already present and didn't add it either.  The power resource was there at
that point, but it didn't have a driver (which only would be probed in the
second pass, after all ACPI devices had been registered).  The driver was
needed, though, for the initialization of the power management of devices
depending on that power resource.

The fact that it was missing caused power management of devices depending on
that power resource not to be initialized correctly and changing their power
states didn't really work going forward.

That's why the Fabio's bisection turned up that commit, BTW (the changing
of USB controllers' power states didn't really work before it on his machine).

I put ACPI_BUS_TYPE_POWER in there, because power resources always needed
'true' in the last arg of acpi_add_single_object() and they were the only type
needing it.

> The code is not exactly obvious, though, so whatever. But that
> "context is suddenly not used" commit (e3863094c6f9: "ACPI: Drop the
> second argument of acpi_bus_scan()") looks odd.
> 
> Maybe "context" was effectively always non-NULL, but it *looks* like
> that series of commits is intended to have no semantic changes, and
> that's the one that looked very dubious to me.

While I might make a mistake in it, I seriously doubt that it is the root
cause of the problem at hand.

It surely is related to PCI power management and to the fact that PCI devices
can go into D3cold at run time now.  This isn't an old change and there were
problems with it.  The known problems were fixed, but there might be more to
uncover and it looks like we've just run into a new one. :-(

So I really need to know what's going on before deciding how to fix that.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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/40] Input: atmel_mxt_ts - Add CHG line handling in bootloader code

[Benson Leung]

On Fri, Feb 22, 2013 at 9:58 AM, Nick Dyer  wrote:
> The bootloader state machine toggles the CHG/Interrupt line to indicate when
> it has transitioned between states. Waiting for this event improves bootloader
> reliability.
>
> Signed-off-by: Nick Dyer 
> ---
>  drivers/input/touchscreen/atmel_mxt_ts.c |   29 +++--
>  1 file changed, 27 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
> b/drivers/input/touchscreen/atmel_mxt_ts.c
> index a1f196b..f182228 100644
> --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> @@ -430,6 +430,27 @@ static int mxt_probe_bootloader(struct mxt_data *data)
> return 0;
>  }
>
> +static int mxt_wait_for_chg(struct mxt_data *data)
> +{
> +   int timeout_counter = 0;
> +   int count = 1E6;
> +
> +   if (data->pdata->read_chg == NULL) {

This also assumes the existence of data->pdata. If data->pdata ==
NULL, you're going to have a bad time.

> +   msleep(20);
> +   return 0;
> +   }
> +
> +   while ((timeout_counter++ <= count) && data->pdata->read_chg())
> +   udelay(20);
> +
> +   if (timeout_counter > count) {
> +   dev_err(&data->client->dev, "mxt_wait_for_chg() timeout!\n");
> +   return -EIO;
> +   }
> +
> +   return 0;
> +}
> +

> --
> 1.7.10.4
>



-- 
Benson Leung
Software Engineer, Chrom* OS
ble...@chromium.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: [GIT PATCH] USB patches for 3.9-rc1

[Fabio Baltieri]

On Sat, Feb 23, 2013 at 01:35:26AM +0100, Rafael J. Wysocki wrote:
> On Saturday, February 23, 2013 01:10:55 AM Fabio Baltieri wrote:
> > Well, this did the trick in my case:
> > 
> > --- >8 ---
> > diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c
> > index b820528..54175a0 100644
> > --- a/drivers/acpi/power.c
> > +++ b/drivers/acpi/power.c
> > @@ -795,7 +795,7 @@ int acpi_add_power_resource(acpi_handle handle)
> > int state, result = -ENODEV;
> >  
> > acpi_bus_get_device(handle, &device);
> > -   if (device)
> > +   if (!device)
> > return 0;
> >  
> > resource = kzalloc(sizeof(*resource), GFP_KERNEL);
> > --- >8 ---
> > 
> > But I guess it's working as a coincidence and something else is wrong -
> > I'll not even try to make a patch out of it and will leave the dirty
> > work to the ACPI guys instead.
> 
> Well, this patch effectively disables the handling of power resources on your
> machine entirely.  The effect of which is probably that the power resources
> can't be turned off for the USB controllers, so they don't go into D3cold.

Ok, as I wrote, I suspected this was just shutting off something and not
solving the real problem.

So, I'll try to recap all the threads here:

> And the bisection found a commit that restores the handling of power resources
> for you, which is not entirely surprising, but the root cause is somewhere 
> else
> most likely.

Indeed.

> The new sysfs interface for power resources control may be helpful here.  You
> need to use the Linus' current for it to work, though.
> 
> Can you please do
> 
> $ find /sys/devices/LNXSYSTM:00/ -name power_state -print -exec cat {} \;
> $ find /sys/devices/LNXSYSTM:00/ -name real_power_state -print -exec cat {} \;
> $ find /sys/devices/LNXSYSTM:00/ -name power_resources_D\* -print -exec ls {} 
> \;
> $ find /sys/devices/LNXSYSTM:00/ -name resource_in_use -print -exec cat {} \;
> and send the output?

With the acpi_add_power_resource disabled all power_state read "D0",
other attributes are not generated.

With a plain kernel that's the output:

$ find /sys/devices/LNXSYSTM:00/ -name power_state -print -exec cat {} \;
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:09/LNXVIDEO:01/power_state
D0
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_state
D0
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_state
D0
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_state
D0
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/power_state
D0

$ find /sys/devices/LNXSYSTM:00/ -name real_power_state -print -exec cat {} \;
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/real_power_state
D3cold
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/real_power_state
D3cold
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/real_power_state
D3cold

$ find /sys/devices/LNXSYSTM:00/ -name power_resources_D\* -print -exec ls {} \;
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D0
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D1
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D2
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D0
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D1
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D2
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D0
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D1
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D2
LNXPOWER:00

$ find /sys/devices/LNXSYSTM:00/ -name resource_in_use -print -exec cat {} \;
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:08/PNP0C09:00/LNXPOWER:00/resource_in_use
0

> Can you please check if the problem is still there in the master
> branch of the linux-pm.git tree alone?

Not sure if this was for me or Dave, anyway linux-pm.git master
currently points as:

10baf04 Merge branch 'release' of 
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux

and the problem is still there.

> May I see the bisection log, BTW?

Sure, here it is:

git bisect start
# bad: [8793422fd9ac5037f5047f80473007301df3689f] Merge tag 'pm+acpi-3.9-rc1' 
of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
git bisect bad 8793422fd9ac5037f5047f80473007301df3689f
# good: [19f949f52599ba7c3f67a5897ac6be14bfcb1200] Linux 3.8
git bisect good 19f949f52599ba7c3f67a5897ac6be14bfcb1200
# good: [8909ff652ddfc83ecdf450f96629c25489d88f77] Merge tag 'regulator-3.9' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
git bisect good 8909ff652ddfc83ecdf450f96629c25489d88f77
# good: [3aad3f03b2b6d2d977b985c49274cdb78a1593e5] Merge tag 'spi-for-linus' of 
git://git.secretlab.ca/git/linux
git bisect good 3aad3f03b2

[PATCH v6] arm: use built-in byte swap function

[Kim Phillips]

On Thu, 21 Feb 2013 22:40:08 -0500
Nicolas Pitre  wrote:

> On Thu, 21 Feb 2013, Kim Phillips wrote:
> 
> > Here's the asm version I'm working on now, based on compiler
> > output of the C version.  Haven't tested beyond defconfig builds,
> > which pass ok.
> > 
> > Is there anything I have to do for thumb mode?  If so, how to test?
> 
> You just need to pick a config that uses some ARMv7 processor, and 
> enable CONFIG_THUMB2_KERNEL.  I don't see any problem with your patch 
> wrt Thumb2.

ok, I've addressed your comments and tested both pre-armv6 and armv6
+ bswapsi2s on i.mx hardware with CONFIG_CC_OPTIMIZE_FOR_SIZE and
CONFIG_THUMB2_KERNEL set:

>From c22f4050174d8da71fdddba2cf67ae40c00ca5cc Mon Sep 17 00:00:00 2001
From: Kim Phillips 
Date: Tue, 19 Feb 2013 17:16:11 -0600
Subject: [PATCH] arm: use built-in byte swap function

Enable the compiler intrinsic for byte swapping on arch ARM.  This
allows the compiler to detect and be able to optimize out byte
swappings, and has a tiny benefit on vmlinux size (Linaro gcc 4.7.3):

   textdata bss dec hex filename
2754100  121144   56520 2931764  2cbc34 vmlinux-lart #orig
2754050  121144   56520 2931714  2cbc02 vmlinux-lart #builtin-bswap
6282699  307852 5578076 12168627 b9adb3 vmlinux-mxs #orig
6282241  307832 5578076 12168149 b9abd5 vmlinux-mxs #builtin-bswap
7200193  364180  361748 7926121  78f169 vmlinux-imx_v6_v7 #orig
7199515  364188  361748 7925451  78eecb vmlinux-imx_v6_v7 #builtin-bswap

Signed-off-by: Kim Phillips 
---
akin to: http://comments.gmane.org/gmane.linux.kernel.cross-arch/16016

based on linux-next-20130221.

changes from last diff:
- addressed Nicolas' comments
- updated commit text figures and reformatted as a patch

changes from diff before that:
- 1st asm version

changes from diff before that:
- enforce -O2 for bswapsdi2.o
- fix building out-of-source tree

changes from diff before that:
- implement custom __bswap[sd]i2 in arch/arm/lib/bswapsdi2.c

v5: re-work based on new gcc version test data:
  - moved outside armv6 protection
  - check for gcc 4.6+ demoted to gcc 4.5+ with:
!defined(CONFIG_CC_OPTIMIZE_FOR_SIZE)

v4:
- undo v2-2's addition of ARCH_DEFINES_BUILTIN_BSWAP per Boris
  and David - object is to find arches that define _HAVE_BSWAP
  and clean it up in the future: patch is much less intrusive. :)

v3:
- moved out of uapi swab.h into arch/arm/include/asm/swab.h
- moved ARCH_DEFINES_BUILTIN_BSWAP help text into commit message
- moved GCC_VERSION >= 40800 ifdef into GCC_VERSION >= 40600 block

v2:
- at91 and lpd270 builds fixed by limiting to ARMv6 and above
  (i.e., ARM cores that have support for the 'rev' instruction).
  Otherwise, the compiler emits calls to libgcc's __bswapsi2 on
  these ARMv4/v5 builds (and arch ARM doesn't link with libgcc).
  All ARM defconfigs now have the same build status as they did
  without this patch (some are broken on linux-next).

- move ARM check from generic compiler.h to arch ARM's swab.h.
  - pretty sure it should be limited to __KERNEL__ builds

- add new ARCH_DEFINES_BUILTIN_BSWAP (see Kconfig help).
  - if set, generic compiler header does not set HAVE_BUILTIN_BSWAPxx
  - not too sure about this having to be a new CONFIG_, but it's hard
to find a place for it given linux/compiler.h doesn't include any
arch-specific files.

- move new selects to end of CONFIG_ARM's Kconfig select list,
  as is done in David Woodhouse's original patchseries for ppc/x86.

 arch/arm/Kconfig  |  1 +
 arch/arm/boot/compressed/Makefile | 15 +++
 arch/arm/kernel/armksyms.c|  4 
 arch/arm/lib/Makefile |  2 +-
 arch/arm/lib/bswapsdi2.S  | 36 
 5 files changed, 53 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/lib/bswapsdi2.S

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index dedf02b..e8a41d0 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -59,6 +59,7 @@ config ARM
select CLONE_BACKWARDS
select OLD_SIGSUSPEND3
select OLD_SIGACTION
+   select ARCH_USE_BUILTIN_BSWAP
help
  The ARM series is a line of low-power-consumption RISC chip designs
  licensed by ARM Ltd and targeted at embedded applications and
diff --git a/arch/arm/boot/compressed/Makefile 
b/arch/arm/boot/compressed/Makefile
index 5cad8a6..d9b5ee5 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -108,12 +108,12 @@ endif
 
 targets   := vmlinux vmlinux.lds \
 piggy.$(suffix_y) piggy.$(suffix_y).o \
-lib1funcs.o lib1funcs.S ashldi3.o ashldi3.S \
-font.o font.c head.o misc.o $(OBJS)
+lib1funcs.o lib1funcs.S ashldi3.o ashldi3.S bswapsdi2.o \
+bswapsdi2.S font.o font.c head.o misc.o $(OBJS)
 
 # Make sure files are removed during clean
 extra-y   += piggy.gzip piggy.lzo piggy.lzma piggy.xzkern \
-lib1funcs.S ashldi3.S $

Re: [idr/perf_init_event] BUG: unable to handle kernel NULL pointer dereference at (null)

[Fengguang Wu]

On Fri, Feb 22, 2013 at 05:35:54PM -0800, Tejun Heo wrote:
> On Fri, Feb 22, 2013 at 05:34:48PM -0800, Tejun Heo wrote:
> > Hello,
> > 
> > On Sat, Feb 23, 2013 at 09:30:11AM +0800, Fengguang Wu wrote:
> > > Greetings,
> > > 
> > > I got the below dmesg and the first bad commit is
> > > 
> > > commit f5947173c082a04a9804bb42a91a0f5df5ee0527
> > > Author: Tejun Heo 
> > > Date:   Wed Feb 20 02:05:52 2013 +
> > > 
> > > idr: implement lookup hint
> > 
> > Andy Shevchenko already posted fix two days ago.  Let me check whether
> > that went in yet.
> 
> Yeah, already in -mm.  It's titled "idr: always do slow path when hint
> is uninitialized".

Great, thanks for the info!

Fengguang
--
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: [GIT PULL] x86/mm changes for v3.9-rc1

[Yinghai Lu]

[ trim cc list]

On Fri, Feb 22, 2013 at 5:27 PM, Konrad Rzeszutek Wilk
 wrote:
>> >  static int xen_pgd_alloc(struct mm_struct *mm)
>> >  {
>> > pgd_t *pgd = mm->pgd;
>> > @@ -2105,7 +2143,7 @@ static const struct pv_mmu_ops xen_mmu_ops 
>> > __initconst = {
>> >  #ifdef CONFIG_X86_32
>> > .write_cr3 = xen_write_cr3_init,
>> >  #else
>> > -   .write_cr3 = xen_write_cr3,
>> > +   .write_cr3 = xen_write_cr3_init,
>> >  #endif
>>
>> ah, why do you still keep the #ifdef here?
>>
>> how about if we call load_cr3 early several times?
>> assume you should make xen_write_cr3 more robust,
>> like bailing out early when cr3 writing same value.
>
> I would welcome such patch - but at this point I just want a
> patch for Linus so that I am not blocking him - and this
> one works.

come on, you produce

  #ifdef CONFIG_X86_32
 .write_cr3 = xen_write_cr3_init,
  #else
 .write_cr3 = xen_write_cr3_init,
  #endif

for the fix, Linus should just apply attached patch instead.

>>
>> Also you should check condition about calling xen_get_user_pgd().
>
> Could you elaborate please?

only call xen_get_user_pgd() when it should be called.

Yinghai


fix_xen_cr3.patch
Description: Binary data

[PATCH] x86-64, xen, mmu: Provide an early version of write_cr3.

[H. Peter Anvin]

From: Konrad Rzeszutek Wilk 

With git commit 8170e6bed465b4b0c7687f93e9948aca4358a33b
"x86, 64bit: Use a #PF handler to materialize early mappings on demand"

we started hitting an early bootup crash where the Xen hypervisor
would inform us that:

(XEN) d7:v0: unhandled page fault (ec=)
(XEN) Pagetable walk from ea05b2d0:
(XEN)  L4[0x1d4] =  
(XEN) domain_crash_sync called from entry.S
(XEN) Domain 7 (vcpu#0) crashed on cpu#3:
(XEN) [ Xen-4.2.0  x86_64  debug=n  Not tainted ]

.. that Xen was unable to context switch back to dom0.

Looking at the calling stack we find that:

  [] xen_get_user_pgd+0x5a  <--
  [] xen_get_user_pgd+0x5a
  [] xen_write_cr3+0x77
  [] init_mem_mapping+0x1f9
  [] setup_arch+0x742
  [] printk+0x48

We are trying to figure out whether we need to up-date the user PGD
as well. Please keep in mind that under 64-bit PV guests we have
a limited amount of rings: 0 for the Hypervisor, and 1 for both
the Linux kernel and user-space. As such the Linux pvops'fied
version of write_cr3 checks if it has to update the user-space cr3
as well.

That clearly is not needed during early bootup. The
recent changes (see above git commit) streamline the x86 page table
allocation to be much simpler (And also incidentally the #PF handler
ends up in spirit being similar to how the Xen toolstack sets up
the initial page-tables).

The fix is to have an early-bootup version of cr3 that just loads
the kernel %cr3.  The later version - which also handles user-page
modifications will be used after the initial page tables have been setup.

[ hpa: removed a redundant #ifdef and made the new function __init.
  Also note that x86-32 already has such an early xen_write_cr3. ]

Tested-by: "H. Peter Anvin" 
Reported-by: Konrad Rzeszutek Wilk 
Signed-off-by: Konrad Rzeszutek Wilk 
Link: 
http://lkml.kernel.org/r/1361579812-23709-1-git-send-email-konrad.w...@oracle.com
Signed-off-by: H. Peter Anvin 
---

[ hpa: This version has some minor cleanups over Konrad's ]

 arch/x86/xen/mmu.c | 44 +++-
 1 file changed, 39 insertions(+), 5 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index f5e86ee..e8e3493 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1408,7 +1408,6 @@ static void __xen_write_cr3(bool kernel, unsigned long 
cr3)
xen_mc_callback(set_current_cr3, (void *)cr3);
}
 }
-
 static void xen_write_cr3(unsigned long cr3)
 {
BUG_ON(preemptible());
@@ -1434,6 +1433,45 @@ static void xen_write_cr3(unsigned long cr3)
xen_mc_issue(PARAVIRT_LAZY_CPU);  /* interrupts restored */
 }
 
+#ifdef CONFIG_X86_64
+/*
+ * At the start of the day - when Xen launches a guest, it has already
+ * built pagetables for the guest. We diligently look over them
+ * in xen_setup_kernel_pagetable and graft as appropiate them in the
+ * init_level4_pgt and its friends. Then when we are happy we load
+ * the new init_level4_pgt - and continue on.
+ *
+ * The generic code starts (start_kernel) and 'init_mem_mapping' sets
+ * up the rest of the pagetables. When it has completed it loads the cr3.
+ * N.B. that baremetal would start at 'start_kernel' (and the early
+ * #PF handler would create bootstrap pagetables) - so we are running
+ * with the same assumptions as what to do when write_cr3 is executed
+ * at this point.
+ *
+ * Since there are no user-page tables at all, we have two variants
+ * of xen_write_cr3 - the early bootup (this one), and the late one
+ * (xen_write_cr3). The reason we have to do that is that in 64-bit
+ * the Linux kernel and user-space are both in ring 3 while the
+ * hypervisor is in ring 0.
+ */
+static void __init xen_write_cr3_init(unsigned long cr3)
+{
+   BUG_ON(preemptible());
+
+   xen_mc_batch();  /* disables interrupts */
+
+   /* Update while interrupts are disabled, so its atomic with
+  respect to ipis */
+   this_cpu_write(xen_cr3, cr3);
+
+   __xen_write_cr3(true, cr3);
+
+   xen_mc_issue(PARAVIRT_LAZY_CPU);  /* interrupts restored */
+
+   pv_mmu_ops.write_cr3 = &xen_write_cr3;
+}
+#endif
+
 static int xen_pgd_alloc(struct mm_struct *mm)
 {
pgd_t *pgd = mm->pgd;
@@ -2102,11 +2140,7 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = 
{
.write_cr2 = xen_write_cr2,
 
.read_cr3 = xen_read_cr3,
-#ifdef CONFIG_X86_32
.write_cr3 = xen_write_cr3_init,
-#else
-   .write_cr3 = xen_write_cr3,
-#endif
 
.flush_tlb_user = xen_flush_tlb,
.flush_tlb_kernel = xen_flush_tlb,
-- 
1.7.11.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: [idr/perf_init_event] BUG: unable to handle kernel NULL pointer dereference at (null)

[Tejun Heo]

On Fri, Feb 22, 2013 at 05:34:48PM -0800, Tejun Heo wrote:
> Hello,
> 
> On Sat, Feb 23, 2013 at 09:30:11AM +0800, Fengguang Wu wrote:
> > Greetings,
> > 
> > I got the below dmesg and the first bad commit is
> > 
> > commit f5947173c082a04a9804bb42a91a0f5df5ee0527
> > Author: Tejun Heo 
> > Date:   Wed Feb 20 02:05:52 2013 +
> > 
> > idr: implement lookup hint
> 
> Andy Shevchenko already posted fix two days ago.  Let me check whether
> that went in yet.

Yeah, already in -mm.  It's titled "idr: always do slow path when hint
is uninitialized".

Thanks

-- 
tejun
--
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: [idr/perf_init_event] BUG: unable to handle kernel NULL pointer dereference at (null)

[Tejun Heo]

Hello,

On Sat, Feb 23, 2013 at 09:30:11AM +0800, Fengguang Wu wrote:
> Greetings,
> 
> I got the below dmesg and the first bad commit is
> 
> commit f5947173c082a04a9804bb42a91a0f5df5ee0527
> Author: Tejun Heo 
> Date:   Wed Feb 20 02:05:52 2013 +
> 
> idr: implement lookup hint

Andy Shevchenko already posted fix two days ago.  Let me check whether
that went in yet.

Thanks.

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

Regression introduced with 14e568e78f6f80ca1e27256641ddf524c7dbdc51 (stop_machine: Use smpboot threads)

[Konrad Rzeszutek Wilk]

Hey Thomas,

I don't know if this is b/c the Xen code is missing something or
expects something that never happend. I hadn't looked at your
patch in any detail (was going to do that on Monday).

Either way, if I boot a HVM guest with PV extensions (aka PVHVM)
this is I what get:


Loading 
initramf.gzready.
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.8.0upstream-06472-g6661875-dirty 
(kon...@phenom.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) 
(GCC) ) #1 SMP Fri Feb 22 20:00:54 EST 2013
[0.00] Command line: initrd=initramf.gz  console=ttyS0,115200 
test=netstatic nofb   sleep BOOT_IMAGE=vmlinuz 
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009dfff] usable
[0.00] BIOS-e820: [mem 0x0009e000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x3f7f] usable
[0.00] BIOS-e820: [mem 0xfc00-0x] reserved
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.4 present.
[0.00] Hypervisor detected: Xen HVM
[0.00] Xen version 4.2.
[0.00] Netfront and the Xen platform PCI driver have been compiled for 
this kernel: unplug emulated NICs.
[0.00] Blkfront and the Xen platform PCI driver have been compiled for 
this kernel: unplug emulated disks.
[0.00] You might have to change the root device
[0.00] from /dev/hd[a-d] to /dev/xvd[a-d]
[0.00] in your root= kernel command line option
[0.00] No AGP bridge found
[0.00] e820: last_pfn = 0x3f800 max_arch_pfn = 0x4
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] found SMP MP-table at [mem 0x000fbba0-0x000fbbaf] mapped at 
[880fbba0]
[0.00] Scanning 1 areas for low memory corruption
[0.00] init_memory_mapping: [mem 0x-0x000f]
[0.00] init_memory_mapping: [mem 0x3a00-0x3a1c8fff]
[0.00] init_memory_mapping: [mem 0x3800-0x39ff]
[0.00] init_memory_mapping: [mem 0x0010-0x37ff]
[0.00] init_memory_mapping: [mem 0x3a1c9000-0x3f7f]
[0.00] RAMDISK: [mem 0x3a1c9000-0x3f7defff]
[0.00] ACPI: RSDP 000ea020 00024 (v02Xen)
[0.00] ACPI: XSDT fc010140 00054 (v01Xen  HVM  
HVML )
[0.00] ACPI: FACP fc00fe00 000F4 (v04Xen  HVM  
HVML )
[0.00] ACPI: DSDT fc004180 0BBF6 (v02Xen  HVM  
INTL 20100528)
[0.00] ACPI: FACS fc004140 00040
[0.00] ACPI: APIC fc00ff00 000D8 (v02Xen  HVM  
HVML )
[0.00] ACPI: HPET fc010050 00038 (v01Xen  HVM  
HVML )
[0.00] ACPI: WAET fc010090 00028 (v01Xen  HVM  
HVML )
[0.00] ACPI: SSDT fc0100c0 00031 (v02Xen  HVM  
INTL 20100528)
[0.00] ACPI: SSDT fc010100 00031 (v02Xen  HVM  
INTL 20100528)
[0.00] No NUMA configuration found
[0.00] Faking a node at [mem 0x-0x3f7f]
[0.00] Initmem setup node 0 [mem 0x-0x3f7f]
[0.00]   NODE_DATA [mem 0x3f7fc000-0x3f7f]
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x1000-0x00ff]
[0.000

Re: [GIT PATCH] USB patches for 3.9-rc1

[Linus Torvalds]

On Fri, Feb 22, 2013 at 4:48 PM, Rafael J. Wysocki  wrote:
>
> The problem is, though, that even if bisection turns up something, it doesn't
> automatically mean that this particular commit is the one that caused the
> problem to happen in the first place.

No, I agree. I just react *very* strongly when somebody starts arguing
against reverting.

The fact that the commit that was bisected fixes another bug in a
previous commit does in fact just imply that that *previous* commit
should perhaps be reverted. Of course, I see that that is the first in
the whole series, so I understand the pain, but even so..

And looking at that commit that makes power resources be treated
specially, that looks completely bogus. It's not what the old code did
either, and it seems to be a total hack for the breakage that just
happens to fix that one machine for purely random reasons, as far as I
can tell. The ACPI_BUS_TYPE_POWER case always had match=1 before, no?

The thing that looks to have been dropped somewhere is that

  .acpi_op_start = !!context,

which first became

  device->add_type = context ? ACPI_BUS_ADD_START : ACPI_BUS_ADD_MATCH;

and then somehow that wasn't needed any more, so it became just an unconditional

  device->add_type = ACPI_BUS_ADD_START;

for unexplained reasons (the commit message says that the argument
"context" wasn't used, and renames it not_used to reinforce the point,
but doesn't explain why it can remove the use that was there).

That unconditional "add_type = ACPI_BUS_ADD_START" then later becomes
"flags.match_driver = true", which is where the whole match_driver
thing comes in.

Anyway, I don't see how magically it became about ACPI_BUS_TYPE_POWER.
The code is not exactly obvious, though, so whatever. But that
"context is suddenly not used" commit (e3863094c6f9: "ACPI: Drop the
second argument of acpi_bus_scan()") looks odd.

Maybe "context" was effectively always non-NULL, but it *looks* like
that series of commits is intended to have no semantic changes, and
that's the one that looked very dubious to me.

   Linus
--
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: Regression introduced by 805d410fb0dbd65e1a57a810858fa2491e75822d (ACPI: Separate adding ACPI device objects from probing ACPI drivers) in v3.9-rc0

[Konrad Rzeszutek Wilk]

> > [1.830762] IP: [] apei_hest_parse+0x2a/0x140
> > [1.830780] PGD 0
> > [1.830791] Oops:  [#1] SMP
> > [1.830806] Modules linked in:
> > [1.830819] CPU 0
> > [1.830827] Pid: 1, comm: swapper/0 Not tainted 
> > 3.8.0-rc2upstream-2-g92ef2a2 #1
> > [1.830838] RIP: e030:[]  [] 
> > apei_hest_parse+0x2a/0x140
> > [1.830853] RSP: e02b:88005bb69e98  EFLAGS: 00010246
> > [1.830862] RAX: ffea RBX: 0030 RCX: 
> > 0017
> > [1.830871] RDX:  RSI:  RDI: 
> > 81328b30
> > [1.830880] RBP: 88005bb69eb8 R08: 833df7a7 R09: 
> > 0720072007200720
> > [1.830890] R10: 0720072007200720 R11: 0720072007200720 R12: 
> > 
> > [1.830899] R13: 81328b30 R14:  R15: 
> > 
> > [1.830913] FS:  () GS:88005d60() 
> > knlGS:
> > [1.830926] CS:  e033 DS:  ES:  CR0: 8005003b
> > [1.830935] CR2: 0024 CR3: 01a0c000 CR4: 
> > 00040660
> > [1.830945] DR0:  DR1:  DR2: 
> > 
> > [1.830955] DR3:  DR6: 0ff0 DR7: 
> > 0400
> > [1.830965] Process swapper/0 (pid: 1, threadinfo 88005bb68000, task 
> > 88005bb627f0)
> > [1.830975] Stack:
> > [1.830981]  0030  81ae8f60 
> > 6d1ed4e7
> > [1.831007]  88005bb69ec8 81328b8b 88005bb69ed8 
> > 81ae8f72
> > [1.831033]  88005bb69f08 81002124 0030 
> > 0007
> > [1.831057] Call Trace:
> > [1.831057]  [] ? pcie_portdrv_init+0x7a/0x7a
> > [1.831057]  [] aer_acpi_firmware_first+0x1b/0x30
> > [1.831057]  [] aer_service_init+0x12/0x2b
> > [1.831057]  [] do_one_initcall+0x124/0x170
> > [1.831057]  [] kernel_init+0x174/0x2f0
> > [1.831057]  [] ? parse_early_options+0x2b/0x2b
> > [1.831057]  [] ? rest_init+0xa0/0xa0
> > [1.831057]  [] ret_from_fork+0x7c/0xb0
> > [1.831057]  [] ? rest_init+0xa0/0xa0
> > [1.831057] Code: 90 55 80 3d 50 5f 8d 00 00 b8 ea ff ff ff 48 89 e5 41 
> > 56 49 89 f6 41 55 49 89 fd 41 54 53 0f 85 bd 00 00 00 48 8b 15 fe 7c 71 00 
> > <44> 8b 4a 24 45 85 c9 0f 84 e1 00 00 00 0f b7 42 28 31 db 48 8d
> > [1.831057] RIP  [] apei_hest_parse+0x2a/0x140
> > [1.831057]  RSP 
> > [1.831057] CR2: 0024
> > [2.028436] ---[ end trace dad4411f23c0dcf5 ]---
> > [2.028459] swapper/0 (1) used greatest stack depth: 5176 bytes left
> > [2.028476] Kernel panic - not syncing: Attempted to kill init! 
> > exitcode=0x0009
> > [2.028476]
> > Parsing config from test.xm
> > Daemon running with PID 5069
> >
> 
> 
> https://patchwork.kernel.org/patch/2175871/

And Tested-by: Konrad Rzeszutek Wilk 

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: x86: mm: Fix vmalloc_fault oops during lazy MMU updates.

[Konrad Rzeszutek Wilk]

On Thu, Feb 21, 2013 at 05:56:35PM +0200, Samu Kallio wrote:
> On Thu, Feb 21, 2013 at 2:33 PM, Konrad Rzeszutek Wilk
>  wrote:
> > On Sun, Feb 17, 2013 at 02:35:52AM -, Samu Kallio wrote:
> >> In paravirtualized x86_64 kernels, vmalloc_fault may cause an oops
> >> when lazy MMU updates are enabled, because set_pgd effects are being
> >> deferred.
> >>
> >> One instance of this problem is during process mm cleanup with memory
> >> cgroups enabled. The chain of events is as follows:
> >>
> >> - zap_pte_range enables lazy MMU updates
> >> - zap_pte_range eventually calls mem_cgroup_charge_statistics,
> >>   which accesses the vmalloc'd mem_cgroup per-cpu stat area
> >> - vmalloc_fault is triggered which tries to sync the corresponding
> >>   PGD entry with set_pgd, but the update is deferred
> >> - vmalloc_fault oopses due to a mismatch in the PUD entries
> >>
> >> Calling arch_flush_lazy_mmu_mode immediately after set_pgd makes the
> >> changes visible to the consistency checks.
> >
> > How do you reproduce this? Is there a BUG() or WARN() trace that
> > is triggered when this happens?
> 
> In my case I've seen this triggered on an Amazon EC2 (Xen PV) instance
> under heavy load spawning many LXC containers. The best I can say at
> this point is that the frequency of this bug seems to be linked to how
> busy the machine is.
> 
> The earliest report of this problem was from 3.3:
> http://comments.gmane.org/gmane.linux.kernel.cgroups/5540
> I can personally confirm the issue since 3.5.
> 
> Here's a sample bug report from a 3.7 kernel (vanilla with Xen XSAVE patch
> for EC2 compatibility). The latest kernel version I have tested and seen this
> problem occur is 3.7.9.

Ingo,

I am OK with this patch. Are you OK taking this in or should I take
it (and add the nice RIP below)?

It should also have CC: sta...@vger.kernel.org on it.

FYI, There is also a Red Hat bug for this: 
https://bugzilla.redhat.com/show_bug.cgi?id=914737

> 
> [11852214.733630] [ cut here ]
> [11852214.733642] kernel BUG at arch/x86/mm/fault.c:397!
> [11852214.733648] invalid opcode:  [#1] SMP
> [11852214.733654] Modules linked in: veth xt_nat xt_comment fuse btrfs
> libcrc32c zlib_deflate ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat
> xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack
> bridge stp llc iptable_filter ip_tables x_tables ghash_clmulni_intel
> aesni_intel aes_x86_64 ablk_helper cryptd xts lrw gf128mul microcode
> ext4 crc16 jbd2 mbcache
> [11852214.733695] CPU 1
> [11852214.733700] Pid: 1617, comm: qmgr Not tainted 3.7.0-1-ec2 #1
> [11852214.733705] RIP: e030:[]  []
> vmalloc_fault+0x14b/0x249
> [11852214.733725] RSP: e02b:88083e57d7f8  EFLAGS: 00010046
> [11852214.733730] RAX: 000854046000 RBX: e8c80d70 RCX:
> 8800
> [11852214.733736] RDX: 3000 RSI: 880854046ff8 RDI:
> 
> [11852214.733744] RBP: 88083e57d818 R08:  R09:
> 88000ff8
> [11852214.733750] R10: 7ff0 R11: 0001 R12:
> 880854686e88
> [11852214.733758] R13: 8180ce88 R14: 88083e57d948 R15:
> 
> [11852214.733768] FS:  7ff3bf0f8740()
> GS:88088b48() knlGS:
> [11852214.733777] CS:  e033 DS:  ES:  CR0: 8005003b
> [11852214.733782] CR2: e8c80d70 CR3: 000854686000 CR4:
> 2660
> [11852214.733790] DR0:  DR1:  DR2:
> 
> [11852214.733796] DR3:  DR6: 0ff0 DR7:
> 0400
> [11852214.733803] Process qmgr (pid: 1617, threadinfo
> 88083e57c000, task 88084474b3e0)
> [11852214.733810] Stack:
> [11852214.733814]  0029 0002 e8c80d70
> 88083e57d948
> [11852214.733828]  88083e57d928 8103e0c7 
> 88083e57d8d0
> [11852214.733840]  88084474b3e0 0060 
> 6cf6
> [11852214.733852] Call Trace:
> [11852214.733861]  [] __do_page_fault+0x2c7/0x4a0
> [11852214.733871]  [] ? xen_mc_flush+0xb2/0x1b0
> [11852214.733880]  [] ? xen_end_context_switch+0x1e/0x30
> [11852214.733888]  [] ? xen_write_msr_safe+0x9b/0xc0
> [11852214.733900]  [] ? __switch_to+0x163/0x4a0
> [11852214.733907]  [] do_page_fault+0xe/0x10
> [11852214.733919]  [] page_fault+0x28/0x30
> [11852214.733930]  [] ?
> mem_cgroup_charge_statistics.isra.12+0x13/0x50
> [11852214.733940]  [] 
> __mem_cgroup_uncharge_common+0xce/0x2d0
> [11852214.733948]  [] ? xen_pte_val+0xe/0x10
> [11852214.733958]  [] mem_cgroup_uncharge_page+0x2a/0x30
> [11852214.733966]  [] page_remove_rmap+0xf8/0x150
> [11852214.733976]  [] ? vm_normal_page+0x1a/0x80
> [11852214.733984]  [] unmap_single_vma+0x573/0x860
> [11852214.733994]  [] ? release_pages+0x1f0/0x230
> [11852214.734004]  [] ? __xen_pgd_walk+0x16a/0x260
> [11852214.734018]  [] unmap_vmas+0x52/0xa0
> [11852214.734026]  [] exit_mmap+0x98/0x17

Re: [GIT PATCH] USB patches for 3.9-rc1

[Rafael J. Wysocki]

On Friday, February 22, 2013 10:51:58 PM Fabio Baltieri wrote:
> On Fri, Feb 22, 2013 at 03:59:54AM -0500, Dave Jones wrote:
> > On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote:
> > 
> >  > USB patches for 3.9-rc1
> >  > 
> >  > Here's the big USB merge for 3.9-rc1
> >  > 
> >  > Nothing major, lots of gadget fixes, and of course, xhci stuff.
> > 
> > I get no USB devices recognised when I insert them any more, which
> > I think is pretty major.  I suspect it has something to do with this ?
> > 
> >  > Lan Tianyu (12):
> >  >   usb: add runtime pm support for usb port device
> >  >   usb: add usb port auto power off mechanism
> > 
> > It looks like every port on my laptop is powered down, as I can't
> > even charge devices with it.
> 
> Hi Dave,
> 
> I have the same problem (and almost the same laptop, Thinkpad T430
> here), all external USB ports without power - even the always-on one
> :-).
> 
> The bug seems to be ACPI related, I bisected it down to this patch:
> 
> f95988d ACPI / scan: Treat power resources in a special way
> 
> In the dmesg I have some error like these:
> 
> ACPI: Power Resource [PUBS] (on)
> ...
> pci :00:14.0: System wakeup disabled by ACPI
> 
> for the USB controllers in the broken kernel, there are some in your
> dmesg too.  I'll try to come up with a fix for current mainline, but all
> the acpi stuff is quite obscure to me and the patch does not revert
> cleanly, maybe Rafael (in CC) has some idea!

May I see the bisection log, BTW?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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: [GIT PATCH] USB patches for 3.9-rc1

[Rafael J. Wysocki]

On Friday, February 22, 2013 04:30:25 PM Linus Torvalds wrote:
> On Fri, Feb 22, 2013 at 4:19 PM, Rafael J. Wysocki  wrote:
> >
> > It won't revert, there's more stuff on top of it.  And it is a fix, so
> > reverting it is not really a good idea anyway.
> 
> Rafael, please don't *ever* write that crap again.
> 
> We revert stuff whether it "fixed" something else or not. The rule is
> "NO REGRESSIONS". It doesn't matter one whit if something "fixes"
> something else or not - if it breaks an old case, it gets reverted.
> 
> Seriously. Why do I even have to mention this? Why do I have to
> explain this to somebody pretty much *every* f*cking merge window?

Well, sorry.  I shouldn't have said that.

The problem is, though, that even if bisection turns up something, it doesn't
automatically mean that this particular commit is the one that caused the
problem to happen in the first place.

And in this particular case bisection turns up a commit that enables something
that didn't work on that particular machine for some time.  It used to work,
then it stopped working and that commit made it work again.  And the fact that
it made it work again caused something different to trigger the result of which
is the observed breakage.

I'm obviously going to fix it, because it is a serious problem, but the commit
in question is not the root cause of it in my opinion (as I wrote to Fabio in
another message).

> This is not a new rule.
> 
> And btw, the *reason* for that rule becoming such a hard rule was
> pretty much exactly suspend/resume and ACPI. Exactly because we used
> to have those infinite "let's fix one thing and break another" dances.
> So you should be well acquainted with the rule, and I'm surprised to
> hear that kind of utter garbage from you in particular.
> 
> There is no excuse for regressions, and "it is a fix" is actually the
> _least_ valid of all reasons.
> 
> A commit that causes a regression is - by definition - not a "fix". So
> please don't *ever* say something that stupid again.
> 
> Things that used to work are simply a million times more important
> than things that historically didn't work.
> 
> So this had better get fixed asap, and I need to feel like people are
> working on it. Otherwise we start reverting.
> 
> And no amount "but it's a fix" matters one whit. In fact, it just
> makes me feel like I need to start reverting early, because the
> maintainer doesn't seem to understand how serious a regression is.

OK, OK.

Please let me understand what the problem is first.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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] PM: align buffers for LZO compression

[Bojan Smojver]

"Markus F.X.J. Oberhumer"  wrote:

>for performance reasons I'd strongly suggest that you explicitly align
>all
>buffers passed to the LZO compress and decompress functions.
>
>Below is a small (and completely untested!) patch, but I think you
>get the idea.

Do you know what kind of performance gains should be expected from this?

--
Bojan
--
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] xen/mmu: Provide an early version of write_cr3.

[Konrad Rzeszutek Wilk]

With git commit 8170e6bed465b4b0c7687f93e9948aca4358a33b
"x86, 64bit: Use a #PF handler to materialize early mappings on demand"

we started hitting an early bootup crash where the Xen hypervisor
would inform us that:

(XEN) d7:v0: unhandled page fault (ec=)
(XEN) Pagetable walk from ea05b2d0:
(XEN)  L4[0x1d4] =  
(XEN) domain_crash_sync called from entry.S
(XEN) Domain 7 (vcpu#0) crashed on cpu#3:
(XEN) [ Xen-4.2.0  x86_64  debug=n  Not tainted ]

.. that Xen was unable to context switch back to dom0.

Looking at the calling stack we find that:

  [] xen_get_user_pgd+0x5a  <--
  [] xen_get_user_pgd+0x5a
  [] xen_write_cr3+0x77
  [] init_mem_mapping+0x1f9
  [] setup_arch+0x742
  [] printk+0x48

We are trying to figure out whether we need to up-date the user PGD
as well. Please keep in mind that under 64-bit PV guests we have
a limited amount of rings: 0 for the Hypervisor, and 1 for both
the Linux kernel and user-space. As such the Linux pvops'fied
version of write_cr3 checks if it has to update the user-space cr3
as well.

That clearly is not needed during early bootup. The
recent changes (see above git commit) streamline the X86 page table
allocation to be much simpler (And also incidentally the #PF handler
ends up in spirit being similar to how the Xen toolstack sets up
the initial page-tables).

The fix is to have an early-bootup version of cr3 that just loads
the kernel %cr3.  The later version - which also handles user-page
modifications will be used after the initial page tables have been setup.

Tested-by: "H. Peter Anvin" 
Reported-by: Konrad Rzeszutek Wilk 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/xen/mmu.c | 42 --
 1 file changed, 40 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index f5e86ee..2c82917 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1408,7 +1408,6 @@ static void __xen_write_cr3(bool kernel, unsigned long 
cr3)
xen_mc_callback(set_current_cr3, (void *)cr3);
}
 }
-
 static void xen_write_cr3(unsigned long cr3)
 {
BUG_ON(preemptible());
@@ -1434,6 +1433,45 @@ static void xen_write_cr3(unsigned long cr3)
xen_mc_issue(PARAVIRT_LAZY_CPU);  /* interrupts restored */
 }
 
+#ifdef CONFIG_X86_64
+/*
+ * At the start of the day - when Xen launches a guest, it has already
+ * built pagetables for the guest. We diligently look over them
+ * in xen_setup_kernel_pagetable and graft as appropiate them in the
+ * init_level4_pgt and its friends. Then when we are happy we load
+ * the new init_level4_pgt - and continue on.
+ *
+ * The generic code starts (start_kernel) and 'init_mem_mapping' sets
+ * up the rest of the pagetables. When it has completed it loads the cr3.
+ * N.B. that baremetal would start at 'start_kernel' (and the early
+ * #PF handler would create bootstrap pagetables) - so we are running
+ * with the same assumptions as what to do when write_cr3 is executed
+ * at this point.
+ *
+ * Since there are no user-page tables at all, we have two variants
+ * of xen_write_cr3 - the early bootup (this one), and the late one
+ * (xen_write_cr3). The reason we have to do that is that in 64-bit
+ * the Linux kernel and user-space are both in ring 3 while the
+ * hypervisor is in ring 0.
+ */
+static void xen_write_cr3_init(unsigned long cr3)
+{
+   BUG_ON(preemptible());
+
+   xen_mc_batch();  /* disables interrupts */
+
+   /* Update while interrupts are disabled, so its atomic with
+  respect to ipis */
+   this_cpu_write(xen_cr3, cr3);
+
+   __xen_write_cr3(true, cr3);
+
+   xen_mc_issue(PARAVIRT_LAZY_CPU);  /* interrupts restored */
+
+   pv_mmu_ops.write_cr3 = &xen_write_cr3;
+}
+#endif
+
 static int xen_pgd_alloc(struct mm_struct *mm)
 {
pgd_t *pgd = mm->pgd;
@@ -2105,7 +2143,7 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
 #ifdef CONFIG_X86_32
.write_cr3 = xen_write_cr3_init,
 #else
-   .write_cr3 = xen_write_cr3,
+   .write_cr3 = xen_write_cr3_init,
 #endif
 
.flush_tlb_user = xen_flush_tlb,
-- 
1.8.0.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: New copyfile system call - discuss before LSF?

[Eric Wong]

"Myklebust, Trond"  wrote:
> > -Original Message-
> > From: Zach Brown [mailto:z...@redhat.com]
> > Sent: Thursday, February 21, 2013 5:25 PM
> > To: Myklebust, Trond
> > Cc: Paolo Bonzini; Ric Wheeler; Linux FS Devel; 
> > linux-kernel@vger.kernel.org;
> > Chris L. Mason; Christoph Hellwig; Alexander Viro; Martin K. Petersen;
> > Hannes Reinecke; Joel Becker
> > Subject: Re: New copyfile system call - discuss before LSF?
> > 
> > On Thu, Feb 21, 2013 at 08:50:27PM +, Myklebust, Trond wrote:
> > > On Thu, 2013-02-21 at 21:00 +0100, Paolo Bonzini wrote:
> > > > Il 21/02/2013 15:57, Ric Wheeler ha scritto:
> > > > >>>
> > > > >> sendfile64() pretty much already has the right arguments for a
> > > > >> "copyfile", however it would be nice to add a 'flags' parameter:
> > > > >> the
> > > > >> NFSv4.2 version would use that to specify whether or not to copy
> > > > >> file metadata.
> > > > >
> > > > > That would seem to be enough to me and has the advantage that it
> > > > > is an relatively obvious extension to something that is at least
> > > > > not totally unknown to developers.
> > > > >
> > > > > Do we need more than that for non-NFS paths I wonder? What does
> > > > > reflink need or the SCSI mechanism?
> > > >
> > > > For virt we would like to be able to specify arbitrary block ranges.
> > > > Copying an entire file helps some copy operations like storage
> > > > migration.  However, it is not enough to convert the guest's
> > > > offloaded copies to host-side offloaded copies.
> > >
> > > So how would a system call based on sendfile64() plus my flag
> > > parameter prevent an underlying implementation from meeting your
> > criterion?
> > 
> > If I'm guessing correctly, sendfile64()+flags would be annoying because it's
> > missing an out_fd_offset.  The host will want to offload the guest's copies 
> > by
> > calling sendfile on block ranges of a guest disk image file that correspond 
> > to
> > the mappings of the in and out files in the guest.
> > 
> > You could make it work with some locking and out_fd seeking to set the
> > write offset before calling sendfile64()+flags, but ugh.
> > 
> >  ssize_t sendfile(int out_fd, int in_fd, off_t in_offset, off_t
> >   out_offset, size_t count, int flags);
> > 
> > That seems closer.
> 
> psendfile() ?
> 
> I fully agree that sounds reasonable... Just being an ass. :-)

splice() already has offset for both fds and a flags arg:

   ssize_t splice(int fd_in, loff_t *off_in, int fd_out,
  loff_t *off_out, size_t len, unsigned int flags);

The current downside is it requires one fd to be a pipe, so it's
just not very easy to use from my perspective[1].

> > We might also want to pre-emptively offer iovs instead of offsets, because
> > that's the very first thing that's going to be requested after people 
> > prototype
> > having to iterate calling sendfile() for each contiguous copy region.
> 
> vpsendfile() then? I agree that might be a little more future-proof. 
> Particularly given that the underlying protocols tend to be fully 
> asynchronous, and so it makes sense to queue up more than one copy at a 
> time...

splicev() might be nice to have in that case, too.



[1] my splice() annoyances:
* need to create/manage a pipe
* copy size limited by pipe size
* doesn't reduce userspace syscalls (just data copy overhead)
* easy to misuse and starve with blocking sockets + big buffers
* not many users, so bugs creep in (v3.7.8 was the first usable
  version of the 3.7 series for TCP sockets)
--
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: [GIT PATCH] USB patches for 3.9-rc1

[Linus Torvalds]

On Fri, Feb 22, 2013 at 4:19 PM, Rafael J. Wysocki  wrote:
>
> It won't revert, there's more stuff on top of it.  And it is a fix, so
> reverting it is not really a good idea anyway.

Rafael, please don't *ever* write that crap again.

We revert stuff whether it "fixed" something else or not. The rule is
"NO REGRESSIONS". It doesn't matter one whit if something "fixes"
something else or not - if it breaks an old case, it gets reverted.

Seriously. Why do I even have to mention this? Why do I have to
explain this to somebody pretty much *every* f*cking merge window?

This is not a new rule.

And btw, the *reason* for that rule becoming such a hard rule was
pretty much exactly suspend/resume and ACPI. Exactly because we used
to have those infinite "let's fix one thing and break another" dances.
So you should be well acquainted with the rule, and I'm surprised to
hear that kind of utter garbage from you in particular.

There is no excuse for regressions, and "it is a fix" is actually the
_least_ valid of all reasons.

A commit that causes a regression is - by definition - not a "fix". So
please don't *ever* say something that stupid again.

Things that used to work are simply a million times more important
than things that historically didn't work.

So this had better get fixed asap, and I need to feel like people are
working on it. Otherwise we start reverting.

And no amount "but it's a fix" matters one whit. In fact, it just
makes me feel like I need to start reverting early, because the
maintainer doesn't seem to understand how serious a regression is.

  Linus
--
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: [GIT PATCH] USB patches for 3.9-rc1

[Rafael J. Wysocki]

On Saturday, February 23, 2013 01:10:55 AM Fabio Baltieri wrote:
> On Fri, Feb 22, 2013 at 05:23:04PM -0500, Dave Jones wrote:
> > On Fri, Feb 22, 2013 at 10:51:58PM +0100, Fabio Baltieri wrote:
> >  > On Fri, Feb 22, 2013 at 03:59:54AM -0500, Dave Jones wrote:
> >  > > On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote:
> >  > > 
> >  > > It looks like every port on my laptop is powered down, as I can't
> >  > > even charge devices with it.
> >  > 
> >  > I have the same problem (and almost the same laptop, Thinkpad T430
> >  > here), all external USB ports without power - even the always-on one
> >  > :-).
> >  > 
> >  > The bug seems to be ACPI related, I bisected it down to this patch:
> >  > 
> >  > f95988d ACPI / scan: Treat power resources in a special way
> >  > 
> >  > In the dmesg I have some error like these:
> >  > 
> >  > ACPI: Power Resource [PUBS] (on)
> >  > ...
> >  > pci :00:14.0: System wakeup disabled by ACPI
> >  > 
> >  > for the USB controllers in the broken kernel, there are some in your
> >  > dmesg too.  I'll try to come up with a fix for current mainline, but all
> >  > the acpi stuff is quite obscure to me and the patch does not revert
> >  > cleanly, maybe Rafael (in CC) has some idea!
> > 
> > Good find. I see the same thing.
> > 
> > [0.930283] ACPI _OSC control for PCIe not granted, disabling ASPM
> > [0.933527] pci :00:14.0: System wakeup disabled by ACPI
> > [0.935982] pci :00:19.0: System wakeup disabled by ACPI
> > [0.937898] pci :00:1a.0: System wakeup disabled by ACPI
> > [0.939835] pci :00:1b.0: System wakeup disabled by ACPI
> > [0.940700] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP1._PRT]
> > [0.942195] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP2._PRT]
> > [0.943737] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP3._PRT]
> > [0.944564] pci :00:1c.2: System wakeup disabled by ACPI
> > [0.966491] pci :00:1d.0: System wakeup disabled by ACPI
> > 
> > I must have pulled in the acpi bits the same time as the usb pull,
> > because I don't recall seeing this problem before last night.
> 
> Definitely.
> 
> Well, this did the trick in my case:
> 
> --- >8 ---
> diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c
> index b820528..54175a0 100644
> --- a/drivers/acpi/power.c
> +++ b/drivers/acpi/power.c
> @@ -795,7 +795,7 @@ int acpi_add_power_resource(acpi_handle handle)
> int state, result = -ENODEV;
>  
> acpi_bus_get_device(handle, &device);
> -   if (device)
> +   if (!device)
> return 0;
>  
> resource = kzalloc(sizeof(*resource), GFP_KERNEL);
> --- >8 ---
> 
> But I guess it's working as a coincidence and something else is wrong -
> I'll not even try to make a patch out of it and will leave the dirty
> work to the ACPI guys instead.

Well, this patch effectively disables the handling of power resources on your
machine entirely.  The effect of which is probably that the power resources
can't be turned off for the USB controllers, so they don't go into D3cold.

And the bisection found a commit that restores the handling of power resources
for you, which is not entirely surprising, but the root cause is somewhere else
most likely.

The new sysfs interface for power resources control may be helpful here.  You
need to use the Linus' current for it to work, though.

Can you please do

$ find /sys/devices/LNXSYSTM:00/ -name power_state -print -exec cat {} \;

$ find /sys/devices/LNXSYSTM:00/ -name real_power_state -print -exec cat {} \;

$ find /sys/devices/LNXSYSTM:00/ -name power_resources_D\* -print -exec ls {} \;

$ find /sys/devices/LNXSYSTM:00/ -name resource_in_use -print -exec cat {} \;

and send the output?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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: [GIT PATCH] USB patches for 3.9-rc1

[Rafael J. Wysocki]

On Friday, February 22, 2013 05:23:04 PM Dave Jones wrote:
> On Fri, Feb 22, 2013 at 10:51:58PM +0100, Fabio Baltieri wrote:
>  > On Fri, Feb 22, 2013 at 03:59:54AM -0500, Dave Jones wrote:
>  > > On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote:
>  > > 
>  > > It looks like every port on my laptop is powered down, as I can't
>  > > even charge devices with it.
>  > 
>  > I have the same problem (and almost the same laptop, Thinkpad T430
>  > here), all external USB ports without power - even the always-on one
>  > :-).
>  > 
>  > The bug seems to be ACPI related, I bisected it down to this patch:
>  > 
>  > f95988d ACPI / scan: Treat power resources in a special way
>  > 
>  > In the dmesg I have some error like these:
>  > 
>  > ACPI: Power Resource [PUBS] (on)
>  > ...
>  > pci :00:14.0: System wakeup disabled by ACPI
>  > 
>  > for the USB controllers in the broken kernel, there are some in your
>  > dmesg too.  I'll try to come up with a fix for current mainline, but all
>  > the acpi stuff is quite obscure to me and the patch does not revert
>  > cleanly, maybe Rafael (in CC) has some idea!
> 
> Good find. I see the same thing.
> 
> [0.930283] ACPI _OSC control for PCIe not granted, disabling ASPM
> [0.933527] pci :00:14.0: System wakeup disabled by ACPI
> [0.935982] pci :00:19.0: System wakeup disabled by ACPI
> [0.937898] pci :00:1a.0: System wakeup disabled by ACPI
> [0.939835] pci :00:1b.0: System wakeup disabled by ACPI
> [0.940700] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP1._PRT]
> [0.942195] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP2._PRT]
> [0.943737] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP3._PRT]
> [0.944564] pci :00:1c.2: System wakeup disabled by ACPI
> [0.966491] pci :00:1d.0: System wakeup disabled by ACPI
> 
> I must have pulled in the acpi bits the same time as the usb pull,
> because I don't recall seeing this problem before last night.

Can you please check if the problem is still there in the master branch of
the linux-pm.git tree alone?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/4] dcache: make Oracle more scalable on large systems

[Andi Kleen]

> That seems to me like an application problem - poking at what the
> kernel is doing via diagnostic interfaces so often that it gets in
> the way of the kernel actually doing stuff is not a problem the
> kernel can solve.

I agree with you that the application shouldn't be doing that, but 
if there is a cheap way to lower the d_path overhead that is also
attractive.  There will be always applications doing broken things.
Any scaling problem less in the kernel is good.

But the real fix in this case is to fix the application.

-Andi
--
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: [GIT PATCH] USB patches for 3.9-rc1

[Rafael J. Wysocki]

On Friday, February 22, 2013 10:51:58 PM Fabio Baltieri wrote:
> On Fri, Feb 22, 2013 at 03:59:54AM -0500, Dave Jones wrote:
> > On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote:
> > 
> >  > USB patches for 3.9-rc1
> >  > 
> >  > Here's the big USB merge for 3.9-rc1
> >  > 
> >  > Nothing major, lots of gadget fixes, and of course, xhci stuff.
> > 
> > I get no USB devices recognised when I insert them any more, which
> > I think is pretty major.  I suspect it has something to do with this ?
> > 
> >  > Lan Tianyu (12):
> >  >   usb: add runtime pm support for usb port device
> >  >   usb: add usb port auto power off mechanism
> > 
> > It looks like every port on my laptop is powered down, as I can't
> > even charge devices with it.
> 
> Hi Dave,
> 
> I have the same problem (and almost the same laptop, Thinkpad T430
> here), all external USB ports without power - even the always-on one
> :-).
> 
> The bug seems to be ACPI related, I bisected it down to this patch:
> 
> f95988d ACPI / scan: Treat power resources in a special way
> 
> In the dmesg I have some error like these:
> 
> ACPI: Power Resource [PUBS] (on)
> ...
> pci :00:14.0: System wakeup disabled by ACPI

They aren't errors in fact, just info messages.

> for the USB controllers in the broken kernel, there are some in your
> dmesg too.  I'll try to come up with a fix for current mainline, but all
> the acpi stuff is quite obscure to me and the patch does not revert
> cleanly, maybe Rafael (in CC) has some idea!

It won't revert, there's more stuff on top of it.  And it is a fix, so
reverting it is not really a good idea anyway.

I suspect that the USB controllers are put into low-power states at one
point and they don't generate wakeup events.  I'm not sure, though, why this
is related to power resources.

Can you please send a dmesg boot log and the output of acpidump from the
affected machine?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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: [GIT PATCH] USB patches for 3.9-rc1

[Fabio Baltieri]

On Fri, Feb 22, 2013 at 05:23:04PM -0500, Dave Jones wrote:
> On Fri, Feb 22, 2013 at 10:51:58PM +0100, Fabio Baltieri wrote:
>  > On Fri, Feb 22, 2013 at 03:59:54AM -0500, Dave Jones wrote:
>  > > On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote:
>  > > 
>  > > It looks like every port on my laptop is powered down, as I can't
>  > > even charge devices with it.
>  > 
>  > I have the same problem (and almost the same laptop, Thinkpad T430
>  > here), all external USB ports without power - even the always-on one
>  > :-).
>  > 
>  > The bug seems to be ACPI related, I bisected it down to this patch:
>  > 
>  > f95988d ACPI / scan: Treat power resources in a special way
>  > 
>  > In the dmesg I have some error like these:
>  > 
>  > ACPI: Power Resource [PUBS] (on)
>  > ...
>  > pci :00:14.0: System wakeup disabled by ACPI
>  > 
>  > for the USB controllers in the broken kernel, there are some in your
>  > dmesg too.  I'll try to come up with a fix for current mainline, but all
>  > the acpi stuff is quite obscure to me and the patch does not revert
>  > cleanly, maybe Rafael (in CC) has some idea!
> 
> Good find. I see the same thing.
> 
> [0.930283] ACPI _OSC control for PCIe not granted, disabling ASPM
> [0.933527] pci :00:14.0: System wakeup disabled by ACPI
> [0.935982] pci :00:19.0: System wakeup disabled by ACPI
> [0.937898] pci :00:1a.0: System wakeup disabled by ACPI
> [0.939835] pci :00:1b.0: System wakeup disabled by ACPI
> [0.940700] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP1._PRT]
> [0.942195] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP2._PRT]
> [0.943737] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP3._PRT]
> [0.944564] pci :00:1c.2: System wakeup disabled by ACPI
> [0.966491] pci :00:1d.0: System wakeup disabled by ACPI
> 
> I must have pulled in the acpi bits the same time as the usb pull,
> because I don't recall seeing this problem before last night.

Definitely.

Well, this did the trick in my case:

--- >8 ---
diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c
index b820528..54175a0 100644
--- a/drivers/acpi/power.c
+++ b/drivers/acpi/power.c
@@ -795,7 +795,7 @@ int acpi_add_power_resource(acpi_handle handle)
int state, result = -ENODEV;
 
acpi_bus_get_device(handle, &device);
-   if (device)
+   if (!device)
return 0;
 
resource = kzalloc(sizeof(*resource), GFP_KERNEL);
--- >8 ---

But I guess it's working as a coincidence and something else is wrong -
I'll not even try to make a patch out of it and will leave the dirty
work to the ACPI guys instead.

Fabio

-- 
Fabio Baltieri
--
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] xfs: Fix possible truncation of log data in xlog_bread_noalign()

[Dave Chinner]

On Fri, Feb 22, 2013 at 08:12:52AM +, Tony Lu wrote:
> I encountered the following panic when using xfs partitions as rootfs, which
> is due to the truncated log data read by xlog_bread_noalign(). We should
> extend the buffer by one extra log sector to ensure there's enough space to
> accommodate requested log data, which we indeed did in xlog_get_bp(), but we
> forgot to do in xlog_bread_noalign().

We've never done that round up in xlog_bread_noalign(). It shouldn't
be necessary as xlog_get_bp() and xlog_bread_noalign() are doing
fundamentally different things. That is, xlog_get_bp() is ensuring
the buffer is large enough for the upcoming IO that will be
requested, while xlog_bread_noalign() is simply ensuring what it is
passed is correctly aligned to device sector boundaries.

So, if you have to fudge an extra block for xlog_bread_noalign(),
that implies that what xlog_bread_noalign() was passed was probably
not correct. It also implies that you are using sector sizes larger
than 512 bytes, because that's the only time this might matter. Put
simply, this:

> XFS mounting filesystem sda2
> Starting XFS recovery on filesystem: sda2 (logdev: internal)
> XFS: xlog_recover_process_data: bad clientid
> XFS: log mount/recovery failed: error 5
> XFS: log mount failed

Is not sufficient information for me to determine if you've correctly
analysed the problem you were seeing and that this is the correct
fix for it. I don't even know what kernel you are seeing this on, or
how you are reproducing it.

Note that I'm not saying the fix isn't necessary or correct, just
that I cannot review it based this commit message.  Given that this
code is essentially unchanged in behaviour since the large sector
size support was adding in 2003(*), understanding how it is
deficient is critical part of the reviewi process

Information you need to provide so I have a chance of reviewing
whether it is correct or not:

- what kernel you saw this on,
- what the filesystem configuration was
- what workload reproduced this problem (a test case would
  be nice, and xfstest even better)
- the actual contents of the log that lead to the short read
  during recovery
- whether xfs_logprint was capable of parsing the log
  correctly
- where in the actual log recovery process the failure
  occurred (e.g. was it trying to recover transactions from
  a section of a wrapped log?)

IOWs, please show your working so we can determine if this is the
root cause of the problem you are seeing. :)

(*) 
http://oss.sgi.com/cgi-bin/gitweb.cgi?p=archive/xfs-import.git;a=commitdiff;h=f14e527f411712f89178c31370b5d733ea1d0280

FWIW, I think your change might need work - there's the possibility
that is can round up the length beyond the end of the log if we ask
to read up to the last sector of the log (i.e. blkno + blklen ==
end of log) and then round up blklen by one sector

Cheers,

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

Re: [RFC patch 7/8] timekeeping: Implement a shadow timekeeper

[John Stultz]

On 02/21/2013 02:51 PM, Thomas Gleixner wrote:

Use the shadow timekeeper to do the update_wall_time() adjustments and
then copy it over to the real timekeeper.

Keep the shadow timekeeper in sync when updating stuff outside of
update_wall_time().

This allows us to limit the timekeeper_seq hold time to the update of
the real timekeeper and the vsyscall data in the next patch.

Signed-off-by: Thomas Gleixner
---


So up to here it all looks ok to me (and not so different from my 
earlier attempts at the same).


The only gotcha here that I realized with my earlier patches, is that in 
order to do the shadow copy update properly, we are also going to need 
to merge the NTP state data into the timekeeper. Otherwise, we could run 
into odd cases where as we update the shadow copy, we change the NTP 
state which then would affect the non-shadow timekeeping state that is 
about to be updated. One example: A the leap second lands, and the tai 
offset gets bumped in the ntp state, while we do a similar counter 
adjustment to the shadow-copy. Then before the real/active timekeeper is 
updated, someone gets the tai offset and applies it to that pre-update 
timekeeper state, and gets an invalid tai time.


The down side is that the NTP state data is fairly large, and so adding 
it to the timekeeper will cause the memcopys to be a bit more painful.


I'm looking at the NTP code now to try to see if we can bound where the 
NTP state is accessed, so we can maybe thin out what ntp state is linked 
to timekeeper updates, and only move that data over to the timekeeper.


thanks
-john





--
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] ARM: vfp: fix fpsid register subarchitecture field mask width

[Stephen Boyd]

On 2/22/2013 10:27 AM, Will Deacon wrote:
> Hi guys,
>
> On Fri, Feb 22, 2013 at 08:08:05AM +, Stephen Boyd wrote:
>> From: Steve Muckle 
>>
>> The subarchitecture field in the fpsid register is 7 bits wide.
>> The topmost bit is used to designate that the subarchitecture
>> designer is not ARM. We use this field to determine which VFP
>> version is supported by the CPU. Since the topmost bit is masked
>> off we detect non-ARM subarchitectures as supporting only
>> HWCAP_VFP and not HWCAP_VFPv3 as it should be for Qualcomm's
>> processors.
> I'm struggling to see why this has anything to do with the hwcaps being set
> incorrectly. What value do you have in fpsid? As far as I can tell, the
> subarchitecture bits 6:0 should start at 0x40 for you, right?

Yes it does.

>
> I can see cases for changing this code, I just don't see why it would go
> wrong in the case you're describing.

VFP_arch = (vfpsid & FPSID_ARCH_MASK) >> FPSID_ARCH_BIT;

causes VFP_arch to be equal to 0 because 0x40 & 0xf == 0.

and then a little bit later we have

   if (VFP_arch >= 2) {
elf_hwcap |= HWCAP_VFPv3;


The branch is not taken so we never set VFPv3.

-- 
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: [BUG bisected]: apei_hest_parse explosion

[Yinghai Lu]

On Fri, Feb 22, 2013 at 4:30 AM, Rafael J. Wysocki  wrote:
> On Friday, February 22, 2013 09:22:15 AM Thomas Gleixner wrote:
>> On Fri, 22 Feb 2013, Rafael J. Wysocki wrote:
>> > On Friday, February 22, 2013 02:40:58 AM Rafael J. Wysocki wrote:
>> > > It looks like the hest_tab memory mapping is unmapped between 
>> > > acpi_hest_init()
>> > > and aer_acpi_firmware_first(), but I have no idea what may be 
>> > > responsible for
>> > > that.
>> > >
>> > > And the only relevant difference between now and before the commit above 
>> > > seems
>> > > to be the change of the acpi_hest_init() ordering (which now is called 
>> > > earlier).
>> >
>> > We actually don't really need to do that thing so early, I think.  It 
>> > looks like
>> > we only need to make it available early enough for the AER driver to be 
>> > able to
>> > use it, so I wonder if moving the acpi_hest_init() to a separate
>> > subsys_initcall() will work around the problem.  That is, something like 
>> > the
>> > patch below.
>>
>> Yes, that makes the machine boot.
>
> Although for a reason I didn't think about.
>
>> > But even if this helps, I will be wanting to understand what's up here.
>>
>> It's very simple. I have "acpi=off" on the command line. With that
>> acpi_hest_init is never called, so hest_disable is not set .
>
> Well, that explains things (and means that acpi=off doesn't really get much
> test coverage these days).
>
>> Brilliant stuff that.
>
> The appended patch should fix the breakage too, can you please verify?
>
> Rafael
>
>
> ---
> From: Rafael J. Wysocki 
> Subject: ACPI / APEI: Fix crash in apei_hest_parse() for acpi=off
>
> After commit 92ef2a2 (ACPI: Change the ordering of PCI root bridge
> driver registrarion), acpi_hest_init() is never called for acpi=off
> (acpi_disabled), so hest_disable is not set, but hest_tab is NULL,
> which causes apei_hest_parse() to crash when it is called from
> aer_acpi_firmware_first().
>
> Fix that by making apei_hest_parse() check if hest_tab is not NULL
> in addition to checking hest_disable.  Also remove the now useless
> acpi_disabled check from apei_hest_parse().
>
> Reported-by: Thomas Gleixner 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/acpi/apei/hest.c |5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> Index: test/drivers/acpi/apei/hest.c
> ===
> --- test.orig/drivers/acpi/apei/hest.c
> +++ test/drivers/acpi/apei/hest.c
> @@ -89,7 +89,7 @@ int apei_hest_parse(apei_hest_func_t fun
> struct acpi_hest_header *hest_hdr;
> int i, rc, len;
>
> -   if (hest_disable)
> +   if (hest_disable || !hest_tab)
> return -EINVAL;
>
> hest_hdr = (struct acpi_hest_header *)(hest_tab + 1);
> @@ -216,9 +216,6 @@ void __init acpi_hest_init(void)
> return;
> }
>
> -   if (acpi_disabled)
> -   goto err;
> -
> status = acpi_get_table(ACPI_SIG_HEST, 0,
> (struct acpi_table_header **)&hest_tab);
> if (status == AE_NOT_FOUND)
>

Acked-by: Yinghai Lu 
--
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: Regression introduced by 805d410fb0dbd65e1a57a810858fa2491e75822d (ACPI: Separate adding ACPI device objects from probing ACPI drivers) in v3.9-rc0

[Yinghai Lu]

On Fri, Feb 22, 2013 at 1:48 PM, Konrad Rzeszutek Wilk
 wrote:
> Hey Rafael,
>
> Per git bisect it looks like that patch:
> ACPI: Separate adding ACPI device objects from probing ACPI drivers
> blows up when running under Xen PV guests:
>
> (please notice that ACPI is turned off with normal Xen PV guests):
> 547 #ifdef CONFIG_ACPI
> 548 if (!(xen_start_info->flags & SIF_INITDOMAIN)) {
> 549 printk(KERN_INFO "ACPI in unprivileged domain 
> disabled\n");
> 550 disable_acpi();
> 551 }
> 552 #endif
>
> (in arch/x86/xen/setup.c). Here is what the console tells me
> (I can't get the early console somehow to work):
>
> [0.00] console [hvc0] enabled, bootconsole disabled
> [0.00] Xen: using vcpuop timer interface
> [0.00] installing Xen timer for CPU 0
> [0.00] tsc: Detected 3901.188 MHz processor
> [0.00] tsc: Marking TSC unstable due to TSCs unsynchronized
> [0.001000] Calibrating delay loop (skipped), value calculated using timer 
> frequency.. 7802.37 BogoMIPS (lpj=3901188)
> [0.001000] pid_max: default: 32768 minimum: 301
> [0.001000] Security Framework initialized
> [0.001000] SELinux:  Initializing.
> [0.001000] SELinux:  Starting in permissive mode
> [0.001000] Dentry cache hash table entries: 262144 (order: 9, 2097152 
> bytes)
> [0.001224] Inode-cache hash table entries: 131072 (order: 8, 1048576 
> bytes)
> [0.001488] Mount-cache hash table entries: 256
> [0.001774] Initializing cgroup subsys cpuacct
> [0.001782] Initializing cgroup subsys freezer
> [0.001860] tseg: 00adf0
> [0.001868] CPU: Physical Processor ID: 0
> [0.001874] CPU: Processor Core ID: 1
> [0.001883] Last level iTLB entries: 4KB 512, 2MB 1024, 4MB 512
> [0.001883] Last level dTLB entries: 4KB 1024, 2MB 1024, 4MB 512
> [0.001883] tlb_flushall_shift: 5
> [0.028911] cpu 0 spinlock event irq 17
> [0.028956] calling  trace_init_flags_sys_exit+0x0/0x12 @ 1
> [0.028966] initcall trace_init_flags_sys_exit+0x0/0x12 returned 0 after 0 
> usecs
> [0.028976] calling  trace_init_flags_sys_enter+0x0/0x12 @ 1
> [0.028986] initcall trace_init_flags_sys_enter+0x0/0x12 returned 0 after 
> 0 usecs
> [0.028997] calling  init_hw_perf_events+0x0/0x414 @ 1
> [0.029000] Performance Events:
> [0.029000] perf: AMD core performance counters detected
> [0.029000] no APIC, boot with the "lapic" boot parameter to force-enable 
> it.
> [0.029000] no hardware sampling interrupt available.
> [0.029000] Broken PMU hardware detected, using software events only.
> [0.029005] Failed to access perfctr msr (MSR c0010201 is 0)
> [0.029014] initcall init_hw_perf_events+0x0/0x414 returned 0 after 976 
> usecs
> [0.029024] calling  register_trigger_all_cpu_backtrace+0x0/0x16 @ 1
> [0.029034] initcall register_trigger_all_cpu_backtrace+0x0/0x16 returned 
> 0 after 0 usecs
> [0.029044] calling  spawn_ksoftirqd+0x0/0x28 @ 1
> [0.029093] initcall spawn_ksoftirqd+0x0/0x28 returned 0 after 0 usecs
> [0.029103] calling  init_workqueues+0x0/0x33a @ 1
> [0.029316] initcall init_workqueues+0x0/0x33a returned 0 after 0 usecs
> [0.029327] calling  migration_init+0x0/0x71 @ 1
> [0.029337] initcall migration_init+0x0/0x71 returned 0 after 0 usecs
> [0.029346] calling  cpu_stop_init+0x0/0xb4 @ 1
> [0.029392] initcall cpu_stop_init+0x0/0xb4 returned 0 after 0 usecs
> [0.029402] calling  rcu_scheduler_really_started+0x0/0x12 @ 1
> [0.029413] initcall rcu_scheduler_really_started+0x0/0x12 returned 0 
> after 0 usecs
> [0.029423] calling  rcu_spawn_gp_kthread+0x0/0x89 @ 1
> [0.029493] initcall rcu_spawn_gp_kthread+0x0/0x89 returned 0 after 0 usecs
> [0.029502] calling  relay_init+0x0/0x14 @ 1
> [0.029510] initcall relay_init+0x0/0x14 returned 0 after 0 usecs
> [0.029519] calling  tracer_alloc_buffers+0x0/0x1fc @ 1
> [0.029565] initcall tracer_alloc_buffers+0x0/0x1fc returned 0 after 0 
> usecs
> [0.029575] calling  init_events+0x0/0x61 @ 1
> [0.029584] initcall init_events+0x0/0x61 returned 0 after 0 usecs
> [0.029592] calling  init_trace_printk+0x0/0x12 @ 1
> [0.029601] initcall init_trace_printk+0x0/0x12 returned 0 after 0 usecs
> [0.029610] calling  jump_label_init_module+0x0/0x12 @ 1
> [0.029618] initcall jump_label_init_module+0x0/0x12 returned 0 after 0 
> usecs
> [0.029630] calling  mce_amd_init+0x0/0x110 @ 1
> [0.029638] MCE: In-kernel MCE decoding enabled.
> [0.029647] initcall mce_amd_init+0x0/0x110 returned 0 after 0 usecs
> [0.029760] NMI watchdog: disabled (cpu0): hardware events not enabled
> [0.030028] installing Xen timer for CPU 1
> [0.030051] cpu 1 spinlock event irq 24
> [0.030092] SMP alternatives: switching to SMP code
> [0.056501] installing Xen timer for CPU 2
> [0.056544] cpu 2 spinlock event irq 31
> [0.057032] Brought up 3 CPUs
> [

Re: Debugging system freezes on filesystem writes

[Marcus Sundman]

On 22.02.2013 22:51, Jan Kara wrote:

On Wed 20-02-13 13:40:03, Marcus Sundman wrote:

On 20.02.2013 10:42, Marcus Sundman wrote:

On 05.12.2012 17:32, Jan Kara wrote:

   I see. Maybe you could have something like
while true; do echo w >/proc/sysrq-trigger; sleep 10; done
   running in the background?

Sure, but I suspect it'll take until the worst is over before it
manages to load and execute that "echo w".

Here is a big run of sysrq-triggering, all while I was uncompressing
a big rar file causing the whole system to be utterly unusable.
NB: Even with realtime I/O-priority the sysrq couldn't be triggered
between 12:41:54 and 12:42:49, as you can see from the dmesg-3.txt
file.

$ sudo ionice -c 1 su
# ionice
realtime: prio 4
# while true; do sleep 10; echo w >/proc/sysrq-trigger; done
^C
# tail -n +1700 /var/log/syslog >dmesg-3.txt

http://sundman.iki.fi/dmesg-3.txt

   Thanks for the traces. I was looking at them and we seem to be always
waiting for IO. There don't seem to be that much CPU load either.

I'm actually starting to suspect the SSD in your laptop.


I've suspected the driver, because I don't remember it being slow in 
windows before I wiped it and installed ubuntu on it. (I didn't do very 
much with it in windows, though. I just downloaded the ubuntu image, but 
AFAICR it had no problem saving the image at the speed of my internet 
connection (which is normally around 6 MiB/s), but nowadays I have to 
strype my downloads to less than 1 MiB/s for it to not lock up so much.)



The svctm field
from iostat output shows it takes 1 second on average to complete an IO
request. That is awfully slow given one request has ~180 KB of data on
average. Ah, one more idea - can you post your /proc/mounts please?


Sure:

$ cat /proc/mounts
rootfs / rootfs rw 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,relatime,size=1964816k,nr_inodes=491204,mode=755 0 0
devpts /dev/pts devpts 
rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0

tmpfs /run tmpfs rw,nosuid,relatime,size=789652k,mode=755 0 0
/dev/disk/by-uuid/5bfa7a58-2d35-4758-954e-4deafb09b892 / ext4 
rw,noatime,discard,errors=remount-ro 0 0

none /sys/fs/fuse/connections fusectl rw,relatime 0 0
none /sys/kernel/debug debugfs rw,relatime 0 0
none /sys/kernel/security securityfs rw,relatime 0 0
none /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
none /run/shm tmpfs rw,nosuid,nodev,relatime 0 0
none /run/user tmpfs 
rw,nosuid,nodev,noexec,relatime,size=102400k,mode=755 0 0

/dev/sda6 /home ext4 rw,noatime,discard 0 0
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc 
rw,nosuid,nodev,noexec,relatime 0 0
gvfsd-fuse /run/user/marcus/gvfs fuse.gvfsd-fuse 
rw,nosuid,nodev,relatime,user_id=1000,group_id=100 0 0


Both / and /home are on the same SSD and suffer from the same problem. 
(I think the swap does as well, but I have my swappiness set very low to 
minimize swapping.)


Regards,
Marcus

--
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/40] Input: atmel_mxt_ts - Make wait-after-reset period compatible with all chips

[Benson Leung]

Hi Nick,

Thanks for this patch. Comments inline.

On Fri, Feb 22, 2013 at 9:57 AM, Nick Dyer  wrote:
> From: Iiro Valkonen 
>
> The delay before the chip can be accessed after reset varies between different
> chips in maXTouch family. Waiting for 200ms and then monitoring the CHG (chip
> is ready when the line is low) is guaranteed to work with all chips.
>
> Signed-off-by: Nick Dyer 
> ---
>  drivers/input/touchscreen/atmel_mxt_ts.c |   91 
> --
>  include/linux/i2c/atmel_mxt_ts.h |1 +
>  2 files changed, 76 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
> b/drivers/input/touchscreen/atmel_mxt_ts.c
> index d04f810..b4bf946 100644
> --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> @@ -2,6 +2,7 @@
>   * Atmel maXTouch Touchscreen driver
>   *
>   * Copyright (C) 2010 Samsung Electronics Co.Ltd
> + * Copyright (C) 2011 Atmel Corporation
>   * Author: Joonyoung Shim 
>   *
>   * This program is free software; you can redistribute  it and/or modify it
> @@ -175,11 +176,14 @@
>
>  /* Define for MXT_GEN_COMMAND_T6 */
>  #define MXT_BOOT_VALUE 0xa5
> +#define MXT_RESET_VALUE0x01
>  #define MXT_BACKUP_VALUE   0x55
> -#define MXT_BACKUP_TIME25  /* msec */
> -#define MXT_RESET_TIME 65  /* msec */
>
> -#define MXT_FWRESET_TIME   175 /* msec */
> +/* Delay times */
> +#define MXT_BACKUP_TIME25  /* msec */
> +#define MXT_RESET_TIME 200 /* msec */
> +#define MXT_RESET_NOCHGREAD400 /* msec */
> +#define MXT_FWRESET_TIME   1000/* msec */
>
>  /* Command to unlock bootloader */
>  #define MXT_UNLOCK_CMD_MSB 0xaa
> @@ -249,6 +253,7 @@ struct mxt_data {
>
> /* Cached parameters from object table */
> u8 T6_reportid;
> +   u16 T6_address;
> u8 T9_reportid_min;
> u8 T9_reportid_max;
>  };
> @@ -599,6 +604,66 @@ end:
> return IRQ_HANDLED;
>  }
>
> +static int mxt_t6_command(struct mxt_data *data, u16 cmd_offset, u8 value, 
> bool wait)
> +{
> +   u16 reg;
> +   u8 command_register;
> +   int ret;
> +   int timeout_counter = 0;
> +
> +   reg = data->T6_address + cmd_offset;
> +
> +   ret = mxt_write_reg(data->client, reg, value);
> +   if (ret)
> +   return ret;
> +
> +   if (!wait)
> +   return 0;
> +
> +   do {
> +   msleep(20);
> +   ret = __mxt_read_reg(data->client, reg, 1, &command_register);
> +   if (ret)
> +   return ret;
> +   } while ((command_register != 0) && (timeout_counter++ <= 100));
> +
> +   if (timeout_counter > 100) {
> +   dev_err(&data->client->dev, "Command failed!\n");
> +   return -EIO;
> +   }
> +
> +   return 0;
> +}
> +
> +static int mxt_soft_reset(struct mxt_data *data, u8 value)
> +{
> +   int ret;
> +   int timeout_counter = 0;
> +   struct device *dev = &data->client->dev;
> +
> +   dev_info(dev, "Resetting chip\n");
> +
> +   ret = mxt_t6_command(data, MXT_COMMAND_RESET, value, false);
> +   if (ret)
> +   return ret;
> +
> +   if (data->pdata->read_chg == NULL) {

Is it possible for data->pdata to be NULL here?
For our chromiumos projects, we operate with a NULL pdata. There may
be a bunch of other places where this is a problem, actually.

> +   msleep(MXT_RESET_NOCHGREAD);
> +   } else {
> +   msleep(MXT_RESET_TIME);
> +
> +   timeout_counter = 0;
> +   while ((timeout_counter++ <= 100) && data->pdata->read_chg())
> +   msleep(20);
> +   if (timeout_counter > 100) {
> +   dev_err(dev, "No response after reset!\n");
> +   return -EIO;
> +   }
> +   }
> +
> +   return 0;
> +}
> +
>  static int mxt_check_reg_init(struct mxt_data *data)
>  {
> const struct mxt_platform_data *pdata = data->pdata;
> @@ -759,6 +824,7 @@ static int mxt_get_object_table(struct mxt_data *data)
> switch (object->type) {
> case MXT_GEN_COMMAND_T6:
> data->T6_reportid = min_id;
> +   data->T6_address = object->start_address;
> break;
> case MXT_TOUCH_MULTI_T9:
> data->T9_reportid_min = min_id;
> @@ -811,16 +877,9 @@ static int mxt_initialize(struct mxt_data *data)
>
> mxt_handle_pdata(data);
>
> -   /* Backup to memory */
> -   mxt_write_object(data, MXT_GEN_COMMAND_T6,
> -   MXT_COMMAND_BACKUPNV,
> -   MXT_BACKUP_VALUE);
> -   msleep(MXT_BACKUP_TIME);
> -
> -   /* Soft reset */
> -   mxt_write_object(data, MXT_GEN_COMMAND_T6,
> -   MXT_COMMAND_RESET, 1);
> -   

Re: [PATCH v2] slub: correctly bootstrap boot caches

[JoonSoo Kim]

2013/2/23 Christoph Lameter :
> On Fri, 22 Feb 2013, Glauber Costa wrote:
>
>> On 02/22/2013 09:01 PM, Christoph Lameter wrote:
>> > Argh. This one was the final version:
>> >
>> > https://patchwork.kernel.org/patch/2009521/
>> >
>>
>> It seems it would work. It is all the same to me.
>> Which one do you prefer?
>
> Flushing seems to be simpler and less code.
>

Hello, Christoph, Glauber.

With flushing, deactivate_slab() occur and it has some overhead to
deactivate objects.
If my patch properly fix this situation, it is better to use mine
which has no overhead.

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/

[BUG] Lenovo x230: SATA errors with 180GB Intel 520 SSD under heavy write load

[Mathieu Desnoyers]

Hi,

We spent a couple of days cornering what appears to be an issue with the
Intel 520 SSD drives in Lenovo x230 laptops. It was first showing up
on a clean Debian installation, while installing a guest operating
system into a VM. Looking around on forums, there appears to be some
people having issues with database workloads too. So I decided to create
a small user-space program to repoduce the problem. IMPORTANT: Before
you try it, be ready for a system crash. It's available at:

git://git.efficios.com/test-ssd.git

direct link to .c file:
https://git.efficios.com/?p=test-ssd.git;a=blob;f=test-ssd-write.c;hb=refs/heads/master

This program simply performs random-access-writes of 4Kb into a single
file.

Executive summary of our findings (the details are in the
test-ssd-write.c header in the git repo):

- We reproduced this issue on 4 x230 machines (all our x230 have 180GB
  Intel drives, and they are all affected),
- We took a SSD from one of the machines, moved it into an x200, and the
  problem still occurs,
- The problem seems to occur independently of the filesystem (reproduced
  on ext3 and ext4),
- Problem reproduced by test-ssd-write.c (git tree above): After less
  than 5 minutes of the heavy write workload, we get SATA errors and we
  need to cold reboot the machine to access the drive again. Example
  usage (don't forget to prepare for a computer freeze):

  ./test-ssd-write somefileondisk 209715200 1234 -z

  (see options by just running ./test-ssd-write)

The problem occurs with drive model SSDSC2BW180A3L, with both firmwares
LE1i and LF1i (those are Lenovo firmwares). We could reproduce the issue
on 3.2 (Debian), 3.5 (Debian), 3.7.9 (Arch) distribution kernels. We
could reproduce it with x230 BIOS G2ET90WW (2.50) 2012-20-12 and
G2ET86WW (2.06) 2012-11-13, but since it can be reproduced on a x200
too, it does not appear to be a BIOS issue.

We tried the program on a range of other SSD drives, one of those
including the same SandForce 2281 controller (details within
test-ssd-write.c header). So our current guess is that the Lenovo
firmware on the SSD might be part of the problem, but it might be good
if we could to confirm that Intel's firmwares work fine.

Thoughts, ideas, hints about who to contact on this issue would be very
much welcome,

Thanks,

Mathieu

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

Re: [PATCH 11/40] Input: atmel_mxt_ts - Bootloader addresses for mXT1664/mXT1188S

[Benson Leung]

We've moved away from using platform data in our project because it's
clunky, and because we implemented the config loading that's similar
to what you submitted elsewhere in this series.

Furthermore, for our ARM projects specifically, we are using flattened
device trees to describe our board and instantiate devices. The upside
is that it means that we no longer have to modify the kernel to bring
up a new board with some varied hardware.

The downside is that it's impossible to setup platform data for i2c
devices from the device tree. drivers/of/of_i2c.c instantiates i2c
devices including the atmel touch device, and it doesn't and shouldn't
know about how atmel_mxt_ts's platform data is structured. All it does
is i2c_new_device on the right adapter, at the right address, and
optionally pass in an irq #.



On Fri, Feb 22, 2013 at 11:51 AM, Nick Dyer  wrote:
> Benson Leung wrote:
>> This is disappointing that Atmel decided to change the bootloader
>> address scheme for the 1664S family. Unfortunately, this ifdef won't
>> work for situations where there are more than one Atmel device of a
>> different kind on a system using this same driver.
>>
>> For the Chromebook Pixel, we use the same atmel_mxt_ts driver for a
>> 1664S device and a 224SL.
>>
>> The 1664S has the pair 0x26 and 0x4a, while the 224SL has 0x25 and
>> 0x4b.
>
> If I put a bootloader address override in the platform data will that meet
> your requirements?



--
Benson Leung
Software Engineer, Chrom* OS
ble...@chromium.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] checkpatch: Improve CamelCase test for Page

[Andrew Morton]

On Fri, 22 Feb 2013 15:57:16 -0700
Shuah Khan  wrote:

> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > index 747bcd7..e08e9f6 100755
> > --- a/scripts/checkpatch.pl
> > +++ b/scripts/checkpatch.pl
> > @@ -2929,8 +2929,8 @@ sub process {
> > while ($line =~ m{($Constant|$Lval)}g) {
> > my $var = $1;
> > if ($var !~ /$Constant/ &&
> > -   $var =~ /[A-Z]\w*[a-z]|[a-z]\w*[A-Z]/ &&
> > -   $var !~ /^Page[A-Z]/ &&
> > +   $var =~ /[A-Z][a-z]|[a-z][A-Z]/ &&
> > +   $var !~ 
> > /"^(?:Clear|Set|TestClear|TestSet|)Page[A-Z]/ && &&
> > !defined $camelcase{$var}) {
> > $camelcase{$var} = 1;
> > WARN("CAMELCASE",
> >
> >
> 
> What are the guidelines on camelcase warnings on patches. A recent one
> I ran into is on a variable in a structure and fixing it would require
> changing the original variable.
> 
> WARNING: Avoid CamelCase: Header.SGList>
> #67: FILE: drivers/scsi/hpsa.c:1409:
> + cp->Header.SGList = 0;
> 
> WARNING: Avoid CamelCase: Header.SGTotal>
> #68: FILE: drivers/scsi/hpsa.c:1410:
> + cp->Header.SGTotal = 0;
> 
> total: 0 errors, 2 warnings, 11 lines checked
> 
> One would have to change a large portion of the code to fix it. In
> such cases, do we ignore this warning?

Yes, ignore the warning.  In my experience this is always the case,
and it happens often.

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

Re: [PATCH] checkpatch: Improve CamelCase test for Page

[Joe Perches]

dOn Fri, 2013-02-22 at 15:57 -0700, Shuah Khan wrote:
> What are the guidelines on camelcase warnings on patches. A recent one
> I ran into is on a variable in a structure and fixing it would require
> changing the original variable.

The same as all other checkpatch warnings.
Ignore the ones you don't agree with.

Errors maybe should be fixed.  You should be able
to ignore those too though.

> One would have to change a large portion of the code to fix it. In
> such cases, do we ignore this warning?

Yes.

Taste is always author's choice.

Of course, lots of things depends on the upstream
path and files you chose to work on.

If you're working in drivers/net, most of these
warnings seem more likely to get patches that have
them rejected.

If you're working on drivers/scsi, it seems you
don't have to bother running checkpatch at all.

--
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 v2 2/3] power: power_supply: Add core support for supplied_nodes

[Stephen Warren]

On 02/22/2013 02:55 PM, Rhyland Klein wrote:
> On 2/22/2013 2:49 PM, Stephen Warren wrote:
>> On 02/21/2013 04:11 PM, Rhyland Klein wrote:
>>> With the growing support for dt, it make sense to try to make use of
>>> dt features to make the general code cleaner. This patch is an
>>> attempt to commonize how chargers and their supplies are linked.
>>>
>>> Following common dt convention, the "supplied-to" char** list is
>>> replaced with phandle lists defined in the supplies which contain
>>> phandles of their suppliers.
>>>
>>> This has the effect however of introducing an inversion in the internal
>>> mechanics of how this information is stored. In the case of non-dt,
>>> the char** list of supplies is stored in the charger. In the dt case,
>>> a device_node * list is stored in the supplies of their chargers,
>>> however this seems to be the only way to support this.
>> When parsing the DT, you can convert from phandle (or struct device_node
>> *) to the name of the referenced supply by simple lookup. So, you could
>> store supply names rather than device_node *. Can't you then also fill
>> in the referenced supply's existing char** list of supplies?
>>
>> Of course, making this interact-with/use -EPROBE_DEFERRED might be
>> challenging, since this would be operating in the inverse order to other
>> producer/consumer relationships, which might cause loops.
> The main problem I ran into when I was essentially trying to do this,
> was that the list of names that
> are used to match the power_supplies are the strings set as "name" in
> the power_supply structs. This
> doesn't get set automatically based on their nodes, and it is currently
> up to each driver to define their
> own name.
> 
> For example, the sbs-battery driver uses the name "sbs-XXX" where XX is
> its dev_name. Other drivers
> use "%s-$%d" as i2c_device_id->name, + instance number. Then the only
> solution I see is to require a new
> property that defines the power-supply's name in the devicetree.
> 
> This solution with device_nodes, while not ideal, seems the be the best
> bet from what I see. Maybe
> someone else has a better idea.

For other resource types, this is handled by the (phandle -> whatever)
conversion process actually being a function call on the referenced
object, so that the driver code for it can look up the data in the
actual device/... object etc. See the various .of_xlate functions that
exist in the kernel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/4] dcache: make Oracle more scalable on large systems

[Dave Chinner]

On Thu, Feb 21, 2013 at 11:13:27PM -0500, Waiman Long wrote:
> On 02/21/2013 07:13 PM, Andi Kleen wrote:
> >Dave Chinner  writes:
> >
> >>On Tue, Feb 19, 2013 at 01:50:55PM -0500, Waiman Long wrote:
> >>>It was found that the Oracle database software issues a lot of call
> >>>to the seq_path() kernel function which translates a (dentry, mnt)
> >>>pair to an absolute path. The seq_path() function will eventually
> >>>take the following two locks:
> >>Nobody should be doing reverse dentry-to-name lookups in a quantity
> >>sufficient for it to become a performance limiting factor. What is
> >>the Oracle DB actually using this path for?
> >Yes calling d_path frequently is usually a bug elsewhere.
> >Is that through /proc ?
> >
> >-Andi
> >
> >
> A sample strace of Oracle indicates that it opens a lot of /proc
> filesystem files such as the stat, maps, etc many times while
> running. Oracle has a very detailed system performance reporting
> infrastructure in place to report almost all aspect of system
> performance through its AWR reporting tool or the browser-base
> enterprise manager. Maybe that is the reason why it is hitting this
> performance bottleneck.

That seems to me like an application problem - poking at what the
kernel is doing via diagnostic interfaces so often that it gets in
the way of the kernel actually doing stuff is not a problem the
kernel can solve.

Cheers,

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

Re: [PATCH] checkpatch: Improve CamelCase test for Page

[Shuah Khan]

On Fri, Feb 22, 2013 at 3:21 PM, Joe Perches  wrote:
> On Fri, 2013-02-22 at 17:01 -0500, Peter Hurley wrote:
>> I didn't bother to mention it before, but since your addressing mm
>> CamelCase exceptions, perhaps
>>
>>   _
>>   xx_XXX_xxx
>>   XXX_xxx
>>
>> could be exceptions as well?
>
> Maybe the check should only be for "[A-Z][a-z]|[a-z][A-Z]"
> to make '_' and any non-alpha char a name barrier.
>
> So vars like A_foo or b_9A would be acceptable.
>
> Maybe:
>
> ---
>  scripts/checkpatch.pl | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 747bcd7..e08e9f6 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -2929,8 +2929,8 @@ sub process {
> while ($line =~ m{($Constant|$Lval)}g) {
> my $var = $1;
> if ($var !~ /$Constant/ &&
> -   $var =~ /[A-Z]\w*[a-z]|[a-z]\w*[A-Z]/ &&
> -   $var !~ /^Page[A-Z]/ &&
> +   $var =~ /[A-Z][a-z]|[a-z][A-Z]/ &&
> +   $var !~ 
> /"^(?:Clear|Set|TestClear|TestSet|)Page[A-Z]/ && &&
> !defined $camelcase{$var}) {
> $camelcase{$var} = 1;
> WARN("CAMELCASE",
>
>

What are the guidelines on camelcase warnings on patches. A recent one
I ran into is on a variable in a structure and fixing it would require
changing the original variable.

WARNING: Avoid CamelCase: Header.SGList>
#67: FILE: drivers/scsi/hpsa.c:1409:
+   cp->Header.SGList = 0;

WARNING: Avoid CamelCase: Header.SGTotal>
#68: FILE: drivers/scsi/hpsa.c:1410:
+   cp->Header.SGTotal = 0;

total: 0 errors, 2 warnings, 11 lines checked

One would have to change a large portion of the code to fix it. In
such cases, do we ignore this warning?

-- Shuah
--
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: New copyfile system call - discuss before LSF?

[Myklebust, Trond]

> -Original Message-
> From: Zach Brown [mailto:z...@redhat.com]
> Sent: Friday, February 22, 2013 1:22 PM
> To: Ric Wheeler
> Cc: Paolo Bonzini; Myklebust, Trond; Linux FS Devel; linux-
> ker...@vger.kernel.org; Chris L. Mason; Christoph Hellwig; Alexander Viro;
> Martin K. Petersen; Hannes Reinecke; Joel Becker
> Subject: Re: New copyfile system call - discuss before LSF?
> 
> > This seems to be suspiciously close to a clear consensus on how to
> > move forward after many years of spinning our wheels. Anyone want to
> > promote an actual patch before we change our collective minds?
> 
> It seems like we'd want to start with the exisiting (presumably
> bitrotten) prototypes that Trond has for nfs and that Martin has for
> block->scsi.  Mash the new syscall on top of and get them working in
> current mainline.
> 
> I'd be happy to take responsibility for making forward progress if no one else
> has the bandwidth.
> 
> Trond, Martin, would that make sense?  Are the most recent versions of the
> prototypes available somewhere?

Hi Zach,

The wildly bitrotten NFS copyfile prototype can be found on


ftp://ftp.netapp.com/frm-ntap/opensource/linux_copyfileat/v2/linux_copyfileat_v2.tgz

Please open with extreme caution and apply the resulting patches to a Linux 
2.6.34.2 kernel...

Cheers
   Trond
--
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: i915 black screen introduced by ACPI changes

[Chris Li]

Ping. Any update for this black screen problem?

Chris

On Wed, Feb 20, 2013 at 1:04 PM, Chris Li  wrote:
> Here is the dmesg with "drm.debug=0xe" at
> 80187431762989ebade986468d3c548287a12689
>
> That is the 3.6 kernel, exactly one commit before the ACPI commit
> which  triggering the black screen.
>
> Thanks
>
> Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] checkpatch: Improve CamelCase test for Page

[Peter Hurley]

On Fri, 2013-02-22 at 14:21 -0800, Joe Perches wrote:
> On Fri, 2013-02-22 at 17:01 -0500, Peter Hurley wrote:
> > I didn't bother to mention it before, but since your addressing mm
> > CamelCase exceptions, perhaps
> > 
> >   _
> >   xx_XXX_xxx
> >   XXX_xxx
> > 
> > could be exceptions as well?
> 
> Maybe the check should only be for "[A-Z][a-z]|[a-z][A-Z]"
> to make '_' and any non-alpha char a name barrier.
> 
> So vars like A_foo or b_9A would be acceptable.
> 
> Maybe:
> 
> ---
>  scripts/checkpatch.pl | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 747bcd7..e08e9f6 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -2929,8 +2929,8 @@ sub process {
>   while ($line =~ m{($Constant|$Lval)}g) {
>   my $var = $1;
>   if ($var !~ /$Constant/ &&
> - $var =~ /[A-Z]\w*[a-z]|[a-z]\w*[A-Z]/ &&
> - $var !~ /^Page[A-Z]/ &&
> + $var =~ /[A-Z][a-z]|[a-z][A-Z]/ &&
> + $var !~ 
> /"^(?:Clear|Set|TestClear|TestSet|)Page[A-Z]/ && &&

^

&&  

>   !defined $camelcase{$var}) {
>   $camelcase{$var} = 1;
>   WARN("CAMELCASE",

Other than that, works for me :)


--
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/40] Input: atmel_mxt_ts - Add CHG line handling in bootloader code

[Benson Leung]

This is very similar to a patch that Daniel and I sent earlier this month.

http://www.spinics.net/lists/linux-input/msg24666.html

The major difference is that your wait_for_chg does a polling read of
chg, while the one we worked on leaves the irq enabled and waits on
completion.

On Fri, Feb 22, 2013 at 9:58 AM, Nick Dyer  wrote:
> The bootloader state machine toggles the CHG/Interrupt line to indicate when
> it has transitioned between states. Waiting for this event improves bootloader
> reliability.
>
> Signed-off-by: Nick Dyer 
> ---
>  drivers/input/touchscreen/atmel_mxt_ts.c |   29 +++--
>  1 file changed, 27 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
> b/drivers/input/touchscreen/atmel_mxt_ts.c
> index a1f196b..f182228 100644
> --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> @@ -430,6 +430,27 @@ static int mxt_probe_bootloader(struct mxt_data *data)
> return 0;
>  }
>
> +static int mxt_wait_for_chg(struct mxt_data *data)
> +{
> +   int timeout_counter = 0;
> +   int count = 1E6;
> +
> +   if (data->pdata->read_chg == NULL) {
> +   msleep(20);
> +   return 0;
> +   }
> +
> +   while ((timeout_counter++ <= count) && data->pdata->read_chg())
> +   udelay(20);
> +
> +   if (timeout_counter > count) {
> +   dev_err(&data->client->dev, "mxt_wait_for_chg() timeout!\n");
> +   return -EIO;
> +   }
> +
> +   return 0;
> +}
> +
>  static u8 mxt_get_bootloader_version(struct mxt_data *data, u8 val)
>  {
> struct device *dev = &data->client->dev;
> @@ -478,9 +499,10 @@ recheck:
> val &= ~MXT_BOOT_STATUS_MASK;
> break;
> case MXT_FRAME_CRC_PASS:
> -   if (val == MXT_FRAME_CRC_CHECK)
> +   if (val == MXT_FRAME_CRC_CHECK) {
> +   mxt_wait_for_chg(data);
> goto recheck;
> -   if (val == MXT_FRAME_CRC_FAIL) {
> +   } else if (val == MXT_FRAME_CRC_FAIL) {
> dev_err(dev, "Bootloader CRC fail\n");
> return -EINVAL;
> }
> @@ -1781,6 +1803,7 @@ static int mxt_load_fw(struct device *dev, const char 
> *fn)
>
> ret = mxt_check_bootloader(data, MXT_WAITING_BOOTLOAD_CMD);
> if (ret) {
> +   mxt_wait_for_chg(data);
> /* Bootloader may still be unlocked from previous update
>  * attempt */
> ret = mxt_check_bootloader(data, MXT_WAITING_FRAME_DATA);
> @@ -1800,6 +1823,7 @@ static int mxt_load_fw(struct device *dev, const char 
> *fn)
> }
>
> while (pos < fw->size) {
> +   mxt_wait_for_chg(data);
> ret = mxt_check_bootloader(data, MXT_WAITING_FRAME_DATA);
> if (ret) {
> data->state = FAILED;
> @@ -1818,6 +1842,7 @@ static int mxt_load_fw(struct device *dev, const char 
> *fn)
> goto release_firmware;
> }
>
> +   mxt_wait_for_chg(data);
> ret = mxt_check_bootloader(data, MXT_FRAME_CRC_PASS);
> if (ret) {
> retry++;
> --
> 1.7.10.4
>



--
Benson Leung
Software Engineer, Chrom* OS
ble...@chromium.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: [GIT PATCH] USB patches for 3.9-rc1

[Dave Jones]

On Fri, Feb 22, 2013 at 10:51:58PM +0100, Fabio Baltieri wrote:
 > On Fri, Feb 22, 2013 at 03:59:54AM -0500, Dave Jones wrote:
 > > On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote:
 > > 
 > > It looks like every port on my laptop is powered down, as I can't
 > > even charge devices with it.
 > 
 > I have the same problem (and almost the same laptop, Thinkpad T430
 > here), all external USB ports without power - even the always-on one
 > :-).
 > 
 > The bug seems to be ACPI related, I bisected it down to this patch:
 > 
 > f95988d ACPI / scan: Treat power resources in a special way
 > 
 > In the dmesg I have some error like these:
 > 
 > ACPI: Power Resource [PUBS] (on)
 > ...
 > pci :00:14.0: System wakeup disabled by ACPI
 > 
 > for the USB controllers in the broken kernel, there are some in your
 > dmesg too.  I'll try to come up with a fix for current mainline, but all
 > the acpi stuff is quite obscure to me and the patch does not revert
 > cleanly, maybe Rafael (in CC) has some idea!

Good find. I see the same thing.

[0.930283] ACPI _OSC control for PCIe not granted, disabling ASPM
[0.933527] pci :00:14.0: System wakeup disabled by ACPI
[0.935982] pci :00:19.0: System wakeup disabled by ACPI
[0.937898] pci :00:1a.0: System wakeup disabled by ACPI
[0.939835] pci :00:1b.0: System wakeup disabled by ACPI
[0.940700] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP1._PRT]
[0.942195] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP2._PRT]
[0.943737] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP3._PRT]
[0.944564] pci :00:1c.2: System wakeup disabled by ACPI
[0.966491] pci :00:1d.0: System wakeup disabled by ACPI

I must have pulled in the acpi bits the same time as the usb pull,
because I don't recall seeing this problem before last night.

Dave

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

Re: [PATCH] checkpatch: Improve CamelCase test for Page

[Peter Hurley]

On Fri, 2013-02-22 at 14:05 -0800, Andrew Morton wrote:
> On Fri, 22 Feb 2013 17:01:48 -0500
> Peter Hurley  wrote:
> 
> > On Fri, 2013-02-22 at 12:59 -0800, Joe Perches wrote:
> > > Add the ClearPage/SetPage/TestClearPage/TestSetPage
> > > variants to the not reported Page CamelCase variables.
> > > 
> > > Signed-off-by: Joe Perches 
> > > ---
> > >  scripts/checkpatch.pl | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > > index 747bcd7..8a32306 100755
> > > --- a/scripts/checkpatch.pl
> > > +++ b/scripts/checkpatch.pl
> > > @@ -2930,7 +2930,7 @@ sub process {
> > >   my $var = $1;
> > >   if ($var !~ /$Constant/ &&
> > >   $var =~ /[A-Z]\w*[a-z]|[a-z]\w*[A-Z]/ &&
> > > - $var !~ /^Page[A-Z]/ &&
> > > + $var !~ 
> > > /"^(?:Clear|Set|TestClear|TestSet|)Page[A-Z]/ &&
> > >   !defined $camelcase{$var}) {
> > >   $camelcase{$var} = 1;
> > >   WARN("CAMELCASE",
> > > 
> > 
> > In a recent patch, checkpatch gave this warning.
> > 
> > WARNING: Avoid CamelCase: SAK_work>
> > #35: FILE: drivers/tty/tty_io.c:1475:
> > +   flush_work(&tty->SAK_work);
> 
> If we start whitelisting these things, it will never end.
> 
> My (cruelly spurned) suggestion for this check is to grep the affected
> files to see if the symbol is already present and if so, don't warn.
> 
> Or just revert the whole thing.  I get tons of camelcase warnings, and
> they're always unuseful/incorrect/ignored.

Oh. I didn't know the impetus (although I had seen the mm variance and
wondered :)

I don't have an opinion on this. It doesn't bother me, but I'm not my
own maintainer.

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

Re: [PATCH] checkpatch: Improve CamelCase test for Page

[Joe Perches]

On Fri, 2013-02-22 at 17:01 -0500, Peter Hurley wrote:
> I didn't bother to mention it before, but since your addressing mm
> CamelCase exceptions, perhaps
> 
>   _
>   xx_XXX_xxx
>   XXX_xxx
> 
> could be exceptions as well?

Maybe the check should only be for "[A-Z][a-z]|[a-z][A-Z]"
to make '_' and any non-alpha char a name barrier.

So vars like A_foo or b_9A would be acceptable.

Maybe:

---
 scripts/checkpatch.pl | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 747bcd7..e08e9f6 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2929,8 +2929,8 @@ sub process {
while ($line =~ m{($Constant|$Lval)}g) {
my $var = $1;
if ($var !~ /$Constant/ &&
-   $var =~ /[A-Z]\w*[a-z]|[a-z]\w*[A-Z]/ &&
-   $var !~ /^Page[A-Z]/ &&
+   $var =~ /[A-Z][a-z]|[a-z][A-Z]/ &&
+   $var !~ 
/"^(?:Clear|Set|TestClear|TestSet|)Page[A-Z]/ && &&
!defined $camelcase{$var}) {
$camelcase{$var} = 1;
WARN("CAMELCASE",


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

Re: [PATCH] checkpatch: Improve CamelCase test for Page

[Andrew Morton]

On Fri, 22 Feb 2013 17:01:48 -0500
Peter Hurley  wrote:

> On Fri, 2013-02-22 at 12:59 -0800, Joe Perches wrote:
> > Add the ClearPage/SetPage/TestClearPage/TestSetPage
> > variants to the not reported Page CamelCase variables.
> > 
> > Signed-off-by: Joe Perches 
> > ---
> >  scripts/checkpatch.pl | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > index 747bcd7..8a32306 100755
> > --- a/scripts/checkpatch.pl
> > +++ b/scripts/checkpatch.pl
> > @@ -2930,7 +2930,7 @@ sub process {
> > my $var = $1;
> > if ($var !~ /$Constant/ &&
> > $var =~ /[A-Z]\w*[a-z]|[a-z]\w*[A-Z]/ &&
> > -   $var !~ /^Page[A-Z]/ &&
> > +   $var !~ 
> > /"^(?:Clear|Set|TestClear|TestSet|)Page[A-Z]/ &&
> > !defined $camelcase{$var}) {
> > $camelcase{$var} = 1;
> > WARN("CAMELCASE",
> > 
> 
> In a recent patch, checkpatch gave this warning.
> 
> WARNING: Avoid CamelCase: SAK_work>
> #35: FILE: drivers/tty/tty_io.c:1475:
> + flush_work(&tty->SAK_work);

If we start whitelisting these things, it will never end.

My (cruelly spurned) suggestion for this check is to grep the affected
files to see if the symbol is already present and if so, don't warn.

Or just revert the whole thing.  I get tons of camelcase warnings, and
they're always unuseful/incorrect/ignored.

--
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 v2 1/3] power_supply: Define Binding for supplied-nodes

[Rhyland Klein]

On 2/22/2013 2:46 PM, Stephen Warren wrote:

On 02/21/2013 04:11 PM, Rhyland Klein wrote:

This property is meant to be used in device nodes which represent
power_supply devices that wish to provide a list of supplies to
which they provide power. A common case is a AC Charger with
the batteries it powers.
diff --git a/Documentation/devicetree/bindings/power_supply/power_supply.txt 
b/Documentation/devicetree/bindings/power_supply/power_supply.txt
+Optional Properties:
+ - power-supply : This property is added to a supply in order to list the
+   devices which supply it power, referenced by their phandles.

DT properties that reference resources are usually named in the plural,
so "power-supplies" would be more appropriate here.

It seems plausible that a single DT node could represent/instantiate
multiple separate supply objects. I think we want to employ the standard
pattern of  rather than just .

That way, each supply that can supply others would have something like a
#supply-cells = , where n is the number of cells that the supply uses
to name the multiple supplies provided by that node. 0 would be a common
value here. 1 might be used for a node that represents many supplies.

When a client supply uses a providing supply as the supply(!), do you
need any flags to parameterize the connection? If so, that might be
cause for a supplier to have a larger #supply-cells, so the flags could
be represented.

That all said, regulators assume 1 node == 1 regulator, so an
alternative would be for a multi-supply node to include a child node per
supply, e.g.:

power@xxx {
 ...
 supply1 {
 ...
 };
 supply2 {
 ...
 };
};

client {
 supplies = <&supply1> <&supply2>;
};

I don't recall why regulators went for the style above rather than the
#supply-cells style. Cc Mark Brown for any comment here.

Also, do supplies and regulators need to inter-operate in any way (e.g.
reference each-other in DT)?


+Example:
+
+   usb-charger: power@e {
+   compatible = "some,usb-charger";
+   ...
+   };
+
+   ac-charger: power@e {
+   compatible = "some,ac-charger";
+   ...
+   };
+
+   battery@b {
+   compatible = "some,battery";
+   ...
+   power-supply = <&usb-charger>, <&ac-charger>;
+   };


The "connection" between supplier and supplies isn't really a hard 
connection.
Essentially, the core code uses the names/nodes in the list and iterates 
over

all the power_supplies that are registered and does matching.

I don't have any experience working with a single node that would spawn 
multiple
supplies, though the situation I am sure is possible. I am interested to 
see what

the consensus is around this design for multiple supplies, as I don't have a
preference either way.

-rhyland

--
nvpublic

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

Re: [PATCH] checkpatch: Improve CamelCase test for Page

[Peter Hurley]

On Fri, 2013-02-22 at 12:59 -0800, Joe Perches wrote:
> Add the ClearPage/SetPage/TestClearPage/TestSetPage
> variants to the not reported Page CamelCase variables.
> 
> Signed-off-by: Joe Perches 
> ---
>  scripts/checkpatch.pl | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 747bcd7..8a32306 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -2930,7 +2930,7 @@ sub process {
>   my $var = $1;
>   if ($var !~ /$Constant/ &&
>   $var =~ /[A-Z]\w*[a-z]|[a-z]\w*[A-Z]/ &&
> - $var !~ /^Page[A-Z]/ &&
> + $var !~ 
> /"^(?:Clear|Set|TestClear|TestSet|)Page[A-Z]/ &&
>   !defined $camelcase{$var}) {
>   $camelcase{$var} = 1;
>   WARN("CAMELCASE",
> 

In a recent patch, checkpatch gave this warning.

WARNING: Avoid CamelCase: SAK_work>
#35: FILE: drivers/tty/tty_io.c:1475:
+   flush_work(&tty->SAK_work);


'SAK' is the acronym for 'Secure Attention Key'. Identifiers which
relate to SAK handling have the above form; eg.,
  do_SAK()
  SAK_work
  do_SAK_work
  fn_SAK
  vc_SAK
  sysrq_handle_SAK

I didn't bother to mention it before, but since your addressing mm
CamelCase exceptions, perhaps

  _
  xx_XXX_xxx
  XXX_xxx

could be exceptions as well?

Regards,
Peter Hurley

--
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] kexec: fix memory leak in function kimage_normal_alloc

[Andrew Morton]

On Fri, 22 Feb 2013 12:36:13 +0800
Zhang Yanfei  wrote:

> If kimage_normal_alloc() fails to alloc pages for image->swap_page, it
> should call kimage_free_page_list() to free allocated pages in
> image->control_pages list before it frees image.
>
> ...
>
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -223,6 +223,8 @@ out:
>  
>  }
>  
> +static void kimage_free_page_list(struct list_head *list);
> +
>  static int kimage_normal_alloc(struct kimage **rimage, unsigned long entry,
>   unsigned long nr_segments,
>   struct kexec_segment __user *segments)
> @@ -248,22 +250,22 @@ static int kimage_normal_alloc(struct kimage **rimage, 
> unsigned long entry,
>  get_order(KEXEC_CONTROL_PAGE_SIZE));
>   if (!image->control_code_page) {
>   printk(KERN_ERR "Could not allocate control_code_buffer\n");
> - goto out;
> + goto out_free;
>   }
>  
>   image->swap_page = kimage_alloc_control_pages(image, 0);
>   if (!image->swap_page) {
>   printk(KERN_ERR "Could not allocate swap buffer\n");
> - goto out;
> + goto out_free;
>   }
>  
> - result = 0;
> - out:
> - if (result == 0)
> - *rimage = image;
> - else
> - kfree(image);
> + *rimage = image;
> + return 0;
>  
> +out_free:
> + kimage_free_page_list(&image->control_pages);
> + kfree(image);
> +out:
>   return result;
>  }

kimage_alloc_normal_control_pages() won't add any pages to the image if
one of its allocation attemtps failed.  So afaict the first `goto
out_free' could be just `goto out'.

The second `goto out_free' does appear to be needed: it frees the pages
allocated by the first call to kimage_alloc_control_pages().  I think. 
The kimage_alloc_control_pages() handling of image->type is a bit
twisty.

Please double-check the logic?
--
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 v2 2/3] power: power_supply: Add core support for supplied_nodes

[Rhyland Klein]

On 2/22/2013 3:09 PM, Stephen Warren wrote:

On 02/21/2013 04:11 PM, Rhyland Klein wrote:

With the growing support for dt, it make sense to try to make use of
dt features to make the general code cleaner. This patch is an
attempt to commonize how chargers and their supplies are linked.

Following common dt convention, the "supplied-to" char** list is
replaced with phandle lists defined in the supplies which contain
phandles of their suppliers.

This has the effect however of introducing an inversion in the internal
mechanics of how this information is stored. In the case of non-dt,
the char** list of supplies is stored in the charger. In the dt case,
a device_node * list is stored in the supplies of their chargers,
however this seems to be the only way to support this.

grep over the whole kernel tree for supplied_to doesn't yield /too/ many
hits, although I didn't look at the complexity of most of them. Would it
be possible to invert all the current in-kernel uses to represent a
supplied_from/by model instead? That would mean the proposed DT binding
would then represent the same relationship ordering as the kernel code,
which would be easier to handle.
I think it is surely possible to change all the existing drivers to the 
inverse logic as

you suggested. That might make a good follow patchset.

-rhyland

--
nvpublic

--
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 v2 2/3] power: power_supply: Add core support for supplied_nodes

[Rhyland Klein]

On 2/22/2013 2:49 PM, Stephen Warren wrote:

On 02/21/2013 04:11 PM, Rhyland Klein wrote:

With the growing support for dt, it make sense to try to make use of
dt features to make the general code cleaner. This patch is an
attempt to commonize how chargers and their supplies are linked.

Following common dt convention, the "supplied-to" char** list is
replaced with phandle lists defined in the supplies which contain
phandles of their suppliers.

This has the effect however of introducing an inversion in the internal
mechanics of how this information is stored. In the case of non-dt,
the char** list of supplies is stored in the charger. In the dt case,
a device_node * list is stored in the supplies of their chargers,
however this seems to be the only way to support this.

When parsing the DT, you can convert from phandle (or struct device_node
*) to the name of the referenced supply by simple lookup. So, you could
store supply names rather than device_node *. Can't you then also fill
in the referenced supply's existing char** list of supplies?

Of course, making this interact-with/use -EPROBE_DEFERRED might be
challenging, since this would be operating in the inverse order to other
producer/consumer relationships, which might cause loops.
The main problem I ran into when I was essentially trying to do this, 
was that the list of names that
are used to match the power_supplies are the strings set as "name" in 
the power_supply structs. This
doesn't get set automatically based on their nodes, and it is currently 
up to each driver to define their

own name.

For example, the sbs-battery driver uses the name "sbs-XXX" where XX is 
its dev_name. Other drivers
use "%s-$%d" as i2c_device_id->name, + instance number. Then the only 
solution I see is to require a new

property that defines the power-supply's name in the devicetree.

This solution with device_nodes, while not ideal, seems the be the best 
bet from what I see. Maybe

someone else has a better idea.

-rhyland

--
nvpublic

--
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: [GIT PATCH] USB patches for 3.9-rc1

[Fabio Baltieri]

On Fri, Feb 22, 2013 at 03:59:54AM -0500, Dave Jones wrote:
> On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote:
> 
>  > USB patches for 3.9-rc1
>  > 
>  > Here's the big USB merge for 3.9-rc1
>  > 
>  > Nothing major, lots of gadget fixes, and of course, xhci stuff.
> 
> I get no USB devices recognised when I insert them any more, which
> I think is pretty major.  I suspect it has something to do with this ?
> 
>  > Lan Tianyu (12):
>  >   usb: add runtime pm support for usb port device
>  >   usb: add usb port auto power off mechanism
> 
> It looks like every port on my laptop is powered down, as I can't
> even charge devices with it.

Hi Dave,

I have the same problem (and almost the same laptop, Thinkpad T430
here), all external USB ports without power - even the always-on one
:-).

The bug seems to be ACPI related, I bisected it down to this patch:

f95988d ACPI / scan: Treat power resources in a special way

In the dmesg I have some error like these:

ACPI: Power Resource [PUBS] (on)
...
pci :00:14.0: System wakeup disabled by ACPI

for the USB controllers in the broken kernel, there are some in your
dmesg too.  I'll try to come up with a fix for current mainline, but all
the acpi stuff is quite obscure to me and the patch does not revert
cleanly, maybe Rafael (in CC) has some idea!

Fabio

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

Re: [patch] drivers, vmci: vmware vmci driver depends on CONFIG_NET

[Greg Kroah-Hartman]

On Fri, Feb 22, 2013 at 12:37:29PM -0800, David Rientjes wrote:
> On Thu, 21 Feb 2013, David Rientjes wrote:
> 
> > CONFIG_VMWARE_VMCI requires CONFIG_NET, otherwise there is a link error:
> > 
> > drivers/built-in.o: In function `__qp_memcpy_from_queue.isra.11':
> > vmci_queue_pair.c:(.text+0x2d4509): undefined reference to `memcpy_toiovec'
> > drivers/built-in.o: In function `__qp_memcpy_to_queue.isra.12':
> > vmci_queue_pair.c:(.text+0x2d4709): undefined reference to 
> > `memcpy_fromiovec'
> > 
> 
> This link error has made it to Linus' tree, so hopefully this can be 
> merged and pushed before rc1.

Yes, give me a chance, it's still early in the merge window.  Actually,
for something so trivial as this, it will probably wait until after
3.9-rc1 is out, the number of people who build a running system without
CONFIG_NET is probably pretty small :)

Don't worry, the patch is not lost, it's in my "to-apply" queue.

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: [PATCH] lib: devres: Fix misplaced #endif

[Andrew Morton]

On Fri, 22 Feb 2013 14:39:40 +0900
Jingoo Han  wrote:

> A misplaced #endif causes link errors related to pcim_*() functions.
> 
> --- a/lib/devres.c
> +++ b/lib/devres.c
> @@ -227,6 +227,7 @@ void devm_ioport_unmap(struct device *dev, void __iomem 
> *addr)
>  devm_ioport_map_match, (void *)addr));
>  }
>  EXPORT_SYMBOL(devm_ioport_unmap);
> +#endif /* CONFIG_HAS_IOPORT */
>  
>  #ifdef CONFIG_PCI
>  /*
> @@ -432,4 +433,3 @@ void pcim_iounmap_regions(struct pci_dev *pdev, int mask)
>  }
>  EXPORT_SYMBOL(pcim_iounmap_regions);
>  #endif /* CONFIG_PCI */
> -#endif /* CONFIG_HAS_IOPORT */

More details needed, please.  This code is pretty old and it's
surprising that errors are popping up now.

--
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: [GIT PULL] arch/arc for v3.9-rc1

[Helge Deller]

On 02/22/2013 07:58 AM, Vineet Gupta wrote:
> Hi Linus,
> 
> I would like to introduce the Linux port to ARC Processors (from Synopsys) for
> 3.9-rc1. The patch-set has been discussed on the public lists since Nov and 
> has
> received a fair bit of review, specially from Arnd, tglx, Al and other 
> subsystem
> maintainers for DeviceTree, kgdb .
> 
> The arch bits are in arch/arc, some asm-generic changes (acked by Arnd), a 
> minor
> change to PARISC (acked by Helge).
> 
> The series is a touch bigger for a new port for 2 main reasons:
> 1. It enables a basic kernel in first sub-series and adds ptrace/kgdb/.. later
> 2. Some of the fallout of review (DeviceTree support, multi-platform-image
> support) were added on top of orig series, primarily to record the revision 
> history.
> 
> Please consider pulling.
> 
> Thanks,
> Vineet
> 
> 
> The following changes since commit 949db153b6466c6f7cad5a427ecea94985927311:
> 
>   Linux 3.8-rc5 (2013-01-25 11:57:28 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git 
> tags/arc-v3.9-rc1
> 
> for you to fetch changes up to fc32781bfdb56dad883469b65e468e749ef35fe5:
> 
>   ARC: [plat-arcfpga] DT arc-uart bindings change: "baud" => "current-speed"
> (2013-02-15 23:16:22 +0530)
> 
> 
> Introducing Linux port to Synopsys ARC Processors (for 3.9-rc1)
> 
> This patchset contains architecture specific bits (arch/arc) to enable Linux 
> on
> ARC700 Processor and some minor adjustments to generic code (reviewed/acked).
> 
> 
> Gilad Ben-Yossef (1):
>   ARC: Add support for ioremap_prot API
> 
> Mischa Jonker (1):
>   ARC: kgdb support
> 
> Vineet Gupta (75):
>   ARC: Generic Headers
>   ARC: Build system: Makefiles, Kconfig, Linker script
>   ARC: irqflags - Interrupt enabling/disabling at in-core intc
>   ARC: Atomic/bitops/cmpxchg/barriers
>   asm-generic headers: uaccess.h to conditionally define segment_eq()
>   ARC: uaccess friends
>   asm-generic: uaccess: Allow arches to over-ride __{get,put}_user_fn()
>   ARC: [optim] uaccess __{get,put}_user() optimised
>   asm-generic headers: Allow yet more arch overrides in checksum.h
>   ARC: Checksum/byteorder/swab routines
>   ARC: Fundamental ARCH data-types/defines
>   ARC: Spinlock/rwlock/mutex primitives
>   ARC: String library
>   ARC: Low level IRQ/Trap/Exception Handling
>   ARC: Interrupt Handling
>   ARC: Non-MMU Exception Handling
>   ARC: Syscall support (no-legacy-syscall ABI)
>   ARC: Process-creation/scheduling/idle-loop
>   ARC: Timers/counters/delay management
>   ARC: Signal handling
>   ARC: [Review] Preparing to fix incorrect syscall restarts due to signals
>   ARC: [Review] Prevent incorrect syscall restarts
>   ARC: Cache Flush Management
>   ARC: Page Table Management
>   ARC: MMU Context Management
>   ARC: MMU Exception Handling
>   ARC: TLB flush Handling
>   ARC: Page Fault handling
>   ARC: I/O and DMA Mappings
>   ARC: Boot #1: low-level, setup_arch(), /proc/cpuinfo, mem init
>   ARC: [plat-arcfpga] Static platform device for CONFIG_SERIAL_ARC
>   ARC: [DeviceTree] Basic support
>   ARC: [DeviceTree] Convert some Kconfig items to runtime values
>   ARC: [plat-arcfpga]: Enabling DeviceTree for Angel4 board
>   ARC: Last bits (stubs) to get to a running kernel with UART
>   ARC: [plat-arcfpga] defconfig
>   ARC: [optim] Cache "current" in Register r25
>   ARC: ptrace support
>   ARC: Futex support
>   ARC: OProfile support
>   ARC: Support for high priority interrupts in the in-core intc
>   ARC: Module support
>   ARC: Diagnostics: show_regs() etc
>   ARC: SMP support
>   ARC: DWARF2 .debug_frame based stack unwinder
>   ARC: stacktracing APIs based on dw2 unwinder
>   ARC: disassembly (needed by kprobes/kgdb/unaligned-access-emul)
>   ARC: kprobes support
>   sysctl: Enable PARISC "unaligned-trap" to be used cross-arch
>   ARC: Unaligned access emulation
>   ARC: Boot #2: Verbose Boot reporting / feature verification
>   ARC: [plat-arfpga] BVCI Latency Unit setup
>   perf, ARC: Enable building perf tools for ARC
>   ARC: perf support (software counters only)
>   ARC: Support for single cycle Close Coupled Mem (CCM)
>   ARC: Hostlink Pseudo-Driver for Metaware Debugger
>   ARC: UAPI Disintegrate arch/arc/include/asm
>   ARC: [Review] Multi-platform image #1: Kconfig enablement
>   ARC: Fold boards sub-menu into platform/SoC menu
>   ARC: [Review] Multi-platform image #2: Board callback Infrastructure
>   ARC: [Review] Multi-platform image #3: switch to board callback
>   ARC: [Review] Multi-platform image #4: Isolate platform headers
>   ARC: [Review]

Re: [PATCH] backlight: ams369fg06: convert ams369fg06 to dev_pm_ops

[Andrew Morton]

On Fri, 22 Feb 2013 19:42:59 +0900
Jingoo Han  wrote:

> Instead of using legacy suspend/resume methods, using newer dev_pm_ops
> structure allows better control over power management.
> 
> ...
>
> @@ -571,12 +571,13 @@ static struct spi_driver ams369fg06_driver = {
>   .driver = {
>   .name   = "ams369fg06",
>   .owner  = THIS_MODULE,
> +#ifdef CONFIG_PM
> + .pm = &ams369fg06_pm_ops,
> +#endif
>   },
>   .probe  = ams369fg06_probe,
>   .remove = ams369fg06_remove,
>   .shutdown   = ams369fg06_shutdown,

Are the ifdefs needed?  There's various macro trickery in pm.h to clean
this up - the rtc drivers use it.

--
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] ima: fix part_pack_uuid() build error

[Randy Dunlap]

On 02/22/13 11:46, Mimi Zohar wrote:
> Fix a build error when CONFIG_BLOCK is not enabled by defining
> a wrapper called ima_part_pack_uuid().  The wrapper returns
> -EINVAL, when CONFIG_BLOCK is not defined.

Some function wrapper for the case of BLOCK not enabled should be handled
where the function is defined, not where it is called.
That's how it is usually done in Linux.


> security/integrity/ima/ima_policy.c:538:4: error: implicit declaration
> of function 'part_pack_uuid' [-Werror=implicit-function-declaration]
> 
> Changelog v0:
> - fix UUID scripts/Lindent msgs
> 
> Reported-by: Randy Dunlap 
> Reported-by: David Rientjes 
> Signed-off-by: Mimi Zohar 
> ---
>  security/integrity/ima/ima.h| 13 +
>  security/integrity/ima/ima_policy.c | 11 ++-
>  2 files changed, 19 insertions(+), 5 deletions(-)
> 
> diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
> index a41c9c1..902c356 100644
> --- a/security/integrity/ima/ima.h
> +++ b/security/integrity/ima/ima.h
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -199,4 +200,16 @@ static inline int security_filter_rule_match(u32 secid, 
> u32 field, u32 op,
>   return -EINVAL;
>  }
>  #endif /* CONFIG_IMA_LSM_RULES */
> +
> +/* UUID policy option requires CONFIG_BLOCK */
> +#ifdef CONFIG_BLOCK
> +static inline int ima_part_pack_uuid(const u8 *uuid_str, u8 *to) {
> + part_pack_uuid(uuid_str, to);
> + return 0;
> +}
> +#else
> +static inline int ima_part_pack_uuid(const u8 *uuid_str, u8 *to) {
> + return -EINVAL;
> +}
> +#endif
>  #endif
> diff --git a/security/integrity/ima/ima_policy.c 
> b/security/integrity/ima/ima_policy.c
> index b27535a..41b7f48 100644
> --- a/security/integrity/ima/ima_policy.c
> +++ b/security/integrity/ima/ima_policy.c
> @@ -176,7 +176,7 @@ static bool ima_match_rules(struct ima_rule_entry *rule,
>   && rule->fsmagic != inode->i_sb->s_magic)
>   return false;
>   if ((rule->flags & IMA_FSUUID) &&
> - memcmp(rule->fsuuid, inode->i_sb->s_uuid, sizeof(rule->fsuuid)))
> + memcmp(rule->fsuuid, inode->i_sb->s_uuid, sizeof(rule->fsuuid)))
>   return false;
>   if ((rule->flags & IMA_UID) && !uid_eq(rule->uid, cred->uid))
>   return false;
> @@ -530,14 +530,15 @@ static int ima_parse_rule(char *rule, struct 
> ima_rule_entry *entry)
>   ima_log_string(ab, "fsuuid", args[0].from);
>  
>   if (memchr_inv(entry->fsuuid, 0x00,
> - sizeof(entry->fsuuid))) {
> +sizeof(entry->fsuuid))) {
>   result = -EINVAL;
>   break;
>   }
>  
> - part_pack_uuid(args[0].from, entry->fsuuid);
> - entry->flags |= IMA_FSUUID;
> - result = 0;
> + result = ima_part_pack_uuid(args[0].from,
> + entry->fsuuid);
> + if (!result)
> + entry->flags |= IMA_FSUUID;
>   break;
>   case Opt_uid:
>   ima_log_string(ab, "uid", args[0].from);
> 


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

[GIT PULL] parisc updates for 3.9

[Helge Deller]

Hi Linus,

The following changes since commit 19f949f52599ba7c3f67a5897ac6be14bfcb1200:

  Linux 3.8 (2013-02-18 15:58:34 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git 
parisc-3.9

for you to fetch changes up to 1dda59b4f3d03fa28d86f3ea235655f0f96aab3e:

  arch/parisc/include/asm: use ARRAY_SIZE macro in mmzone.h (2013-02-20 
22:57:49 +0100)


Al Viro (1):
  parisc: fix ptrace breakage

Geert Uytterhoeven (1):
  [PARISC] hpux: Remove obsolete regs parameter from do_execve() in 
hpux_execve()

Helge Deller (13):
  Merge tag 'parisc-fixes' of git://git.kernel.org/.../jejb/parisc-2.6 into 
stable-3.8
  parisc: enhance automatic CONFIG_CROSS_COMPILE detection
  parisc: add CONFIG_MLONGCALLS option to enable linkage of huge vmlinux 
executables
  parisc: led driver requires CONFIG_VM_EVENT_COUNTERS
  parisc: wire up process_vm_readv, process_vm_writev, kcmp and 
finit_module syscalls
  parisc: fix personality on 32bit kernel
  parisc: correctly wire up mq_* functions for CONFIG_COMPAT case
  parisc: convert msgrcv and msgsnd syscalls to use compat layer
  parisc: fix error return codes for rt_sigaction and rt_sigprocmask
  parisc: fix fallocate syscall
  parisc: switch to available compat_sched_rr_get_interval implementation
  parisc: sendfile and sendfile64 syscall cleanups
  parisc: remove empty lines and unnecessary #ifdef coding in 
include/asm/signal.h

Joe Perches (1):
  drivers/parisc: Use printf extension %pR for struct resource

John David Anglin (10):
  [PARISC] Purge existing TLB entries in set_pte_at and ptep_set_wrprotect
  parisc: Fix comment describing setup of access rights in entry.S
  parisc: fixes and cleanups in page cache flushing (1/4)
  parisc: fixes and cleanups in page cache flushing (2/4)
  parisc: fixes and cleanups in page cache flushing (3/4)
  parisc: fixes and cleanups in page cache flushing (4/4)
  parisc: disable preemption while flushing D- or I-caches through TMPALIAS 
region
  parisc: ensure that mmapped shared pages are aligned at SHMLBA addresses
  parisc: always detect multiple physical ranges
  parisc: space register variables need to be in native length (unsigned 
long)

Julia Lawall (1):
  drivers/parisc/pdc_stable.c: use WARN

Kautuk Consul (1):
  parisc/mm/fault.c: Port OOM changes to do_page_fault

Nikitas Angelinas (1):
  arch/parisc/include/asm: use ARRAY_SIZE macro in mmzone.h

Paul Bolle (1):
  parisc: remove unused compat_rt_sigframe.h header

Peter Zijlstra (1):
  parisc: remove IRQF_DISABLED

Wei Yongjun (1):
  parisc: fix possible memory leak in pat_query_module()

 arch/parisc/Kconfig  |  21 ++
 arch/parisc/Makefile |  13 +-
 arch/parisc/hpux/fs.c|   3 +-
 arch/parisc/include/asm/cacheflush.h |   2 +
 arch/parisc/include/asm/compat.h |  61 +
 arch/parisc/include/asm/compat_rt_sigframe.h |  50 
 arch/parisc/include/asm/elf.h|   2 +-
 arch/parisc/include/asm/floppy.h |   4 +-
 arch/parisc/include/asm/mmzone.h |   7 +-
 arch/parisc/include/asm/page.h   |  20 +-
 arch/parisc/include/asm/pgtable.h|  13 +-
 arch/parisc/include/asm/signal.h |   4 -
 arch/parisc/include/asm/unistd.h |   2 +
 arch/parisc/include/uapi/asm/unistd.h|   6 +-
 arch/parisc/kernel/cache.c   | 221 +++---
 arch/parisc/kernel/entry.S   |   4 +-
 arch/parisc/kernel/inventory.c   |   2 +
 arch/parisc/kernel/irq.c |   4 +-
 arch/parisc/kernel/pacache.S | 335 +++
 arch/parisc/kernel/parisc_ksyms.c|   5 +-
 arch/parisc/kernel/signal.c  |   2 +-
 arch/parisc/kernel/signal32.c|  15 +-
 arch/parisc/kernel/sys_parisc.c  |  16 +-
 arch/parisc/kernel/sys_parisc32.c| 122 ++
 arch/parisc/kernel/syscall.S |   5 +-
 arch/parisc/kernel/syscall_table.S   |  27 +--
 arch/parisc/mm/fault.c   |  30 ++-
 drivers/parisc/Kconfig   |   1 +
 drivers/parisc/dino.c|  13 +-
 drivers/parisc/hppb.c|   6 +-
 drivers/parisc/pdc_stable.c  |   6 +-
 drivers/parisc/superio.c |   2 +-
 32 files changed, 708 insertions(+), 316 deletions(-)
 delete mode 100644 arch/parisc/include/asm/compat_rt_sigframe.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: [PATCH] fadvise: perform WILLNEED readahead in a workqueue

[Eric Wong]

Phillip Susi  wrote:
> > On Sat, Dec 15, 2012 at 12:54:48AM +, Eric Wong wrote:
> >> "strace -T" timing on an uncached, one gigabyte file:
> >> 
> >> Before: fadvise64(3, 0, 0, POSIX_FADV_WILLNEED) = 0 <2.484832> 
> >> After: fadvise64(3, 0, 0, POSIX_FADV_WILLNEED) = 0 <0.61>
> 
> It shouldn't take 2 seconds to queue up some async reads.  Are you
> using ext3?  The blocks have to be mapped in order to queue the reads,
> and without ext4 extents, this means the indirect blocks have to be
> read and can cause fadvise to block.

You're right, I originally tested on ext3.

I just tested an unpatched 3.7.9 kernel with ext4 and is much faster
(~250ms).  I consider ~250ms acceptable for my needs.  Will migrate
the rest of my setup to ext4 soon, thanks for the tip!
--
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] irq: Cleanup context state transitions in irq_exit()

[Linus Torvalds]

On Fri, Feb 22, 2013 at 7:06 AM, Thomas Gleixner  wrote:
>>
>> I prefer to let you guys have the final word on this patch. Whether you
>> apply it or not, I fear I'll never be entirely happy either way :)
>> That's the sad fate of dealing with circular dependencies...
>
> plus the butt ugly softirq semantics or the lack thereof ...

The softirq semantics are perfectly fine. Don't blame softirq for the
fact that irq_exit() has had shit-for-brains for a long time.

Just move the whole "invoke_softirq()" thing down to *after* the
tick_nohz_irq_exit() stuff. And that "wakeup_softirqd()" is garbage
too, since the whole thing should only be used for the
"force_irqthreads" case (which invoke_softirq()" got right.

And get rid of that final

 #ifndef __ARCH_IRQ_EXIT_IRQS_DISABLED
local_irq_restore(flags);
 #endif

because even if the architecture enters irq_exit() with interrupts
enabled, we should damn well exit with them disabled so that there are
no races with new recursive interrupts (other than the ones that
wakeup_softirqd already handled).

In other words, I think all those special cases are indeed indicative
of something being wrong, but that "something" is not the softirq
code. Don't blame that. Blame the fact that irq_exit() is simply
written wrong. The softirq code should be done last (it used to be
done from the asm code), and the whole comment about
tick_nohz_irq_exit() perhaps changing something looks like pure and
utter garbage.

Don't blame the wrong code here.

   Linus
--
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: [RFE PATCH 2/2] rtc, add write functionality to sysfs

[John Stultz]

On 02/22/2013 12:55 PM, Prarit Bhargava wrote:


On 02/22/2013 03:43 PM, John Stultz wrote:

On 02/14/2013 09:02 AM, Prarit Bhargava wrote:

/sys/class/rtc/rtcX/date and /sys/class/rtc/rtcX/time currently have
read-only access.  This patch introduces write functionality which will
set the rtc time.

Usage: echo -MM-DD > /sys/class/rtc/rtcX/date
 echo HH:MM:SS > /sys/class/rtc/rtcX/time

Why do we want to add a new interface here?

John,

I'm not adding a new interface.  The current date/time interface only handles
read and I'm introducing write.



Right, but what benefit does that provide?
(I'm not saying there isn't any, its just not clear from your patch why 
this is a good thing.)


Also CC'ing Alessandro for his input.

thanks
-john


--
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/7] ksm: treat unstable nid like in stable tree

[Hugh Dickins]

On Fri, 22 Feb 2013, Ric Mason wrote:
> On 02/21/2013 04:20 PM, Hugh Dickins wrote:
> > An inconsistency emerged in reviewing the NUMA node changes to KSM:
> > when meeting a page from the wrong NUMA node in a stable tree, we say
> > that it's okay for comparisons, but not as a leaf for merging; whereas
> > when meeting a page from the wrong NUMA node in an unstable tree, we
> > bail out immediately.
> 
> IIUC
> - ksm page from the wrong NUMA node will be add to current node's stable tree

That should never happen (and when I was checking with a WARN_ON it did
not happen).  What can happen is that a node already in a stable tree
has its page migrated away to another NUMA node.

> - normal page from the wrong NUMA node will be merged to current node's
> stable tree  <- where I miss here? I didn't see any special handling in
> function stable_tree_search for this case.

nid = get_kpfn_nid(page_to_pfn(page));
root = root_stable_tree + nid;

to choose the right tree for the page, and

if (get_kpfn_nid(stable_node->kpfn) !=
NUMA(stable_node->nid)) {
put_page(tree_page);
goto replace;
}

to make sure that we don't latch on to a node whose page got migrated away.

> - normal page from the wrong NUMA node will compare but not as a leaf for
> merging after the patch

I don't understand you there, but hope my remarks above resolve it.

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

Re: [PATCHv5 2/8] zsmalloc: add documentation

[Seth Jennings]

On 02/21/2013 08:56 PM, Ric Mason wrote:
> On 02/21/2013 11:50 PM, Seth Jennings wrote:
>> On 02/21/2013 02:49 AM, Ric Mason wrote:
>>> On 02/19/2013 03:16 AM, Seth Jennings wrote:
 On 02/16/2013 12:21 AM, Ric Mason wrote:
> On 02/14/2013 02:38 AM, Seth Jennings wrote:
>> This patch adds a documentation file for zsmalloc at
>> Documentation/vm/zsmalloc.txt
>>
>> Signed-off-by: Seth Jennings 
>> ---
>> Documentation/vm/zsmalloc.txt |   68
>> +
>> 1 file changed, 68 insertions(+)
>> create mode 100644 Documentation/vm/zsmalloc.txt
>>
>> diff --git a/Documentation/vm/zsmalloc.txt
>> b/Documentation/vm/zsmalloc.txt
>> new file mode 100644
>> index 000..85aa617
>> --- /dev/null
>> +++ b/Documentation/vm/zsmalloc.txt
>> @@ -0,0 +1,68 @@
>> +zsmalloc Memory Allocator
>> +
>> +Overview
>> +
>> +zmalloc a new slab-based memory allocator,
>> +zsmalloc, for storing compressed pages.  It is designed for
>> +low fragmentation and high allocation success rate on
>> +large object, but <= PAGE_SIZE allocations.
>> +
>> +zsmalloc differs from the kernel slab allocator in two primary
>> +ways to achieve these design goals.
>> +
>> +zsmalloc never requires high order page allocations to back
>> +slabs, or "size classes" in zsmalloc terms. Instead it allows
>> +multiple single-order pages to be stitched together into a
>> +"zspage" which backs the slab.  This allows for higher allocation
>> +success rate under memory pressure.
>> +
>> +Also, zsmalloc allows objects to span page boundaries within the
>> +zspage.  This allows for lower fragmentation than could be had
>> +with the kernel slab allocator for objects between PAGE_SIZE/2
>> +and PAGE_SIZE.  With the kernel slab allocator, if a page
>> compresses
>> +to 60% of it original size, the memory savings gained through
>> +compression is lost in fragmentation because another object of
>> +the same size can't be stored in the leftover space.
>> +
>> +This ability to span pages results in zsmalloc allocations not
>> being
>> +directly addressable by the user.  The user is given an
>> +non-dereferencable handle in response to an allocation request.
>> +That handle must be mapped, using zs_map_object(), which returns
>> +a pointer to the mapped region that can be used.  The mapping is
>> +necessary since the object data may reside in two different
>> +noncontigious pages.
> Do you mean the reason of  to use a zsmalloc object must map after
> malloc is object data maybe reside in two different nocontiguous
> pages?
 Yes, that is one reason for the mapping.  The other reason (more
 of an
 added bonus) is below.

>> +
>> +For 32-bit systems, zsmalloc has the added benefit of being
>> +able to back slabs with HIGHMEM pages, something not possible
> What's the meaning of "back slabs with HIGHMEM pages"?
 By HIGHMEM, I'm referring to the HIGHMEM memory zone on 32-bit
 systems
 with larger that 1GB (actually a little less) of RAM.  The upper 3GB
 of the 4GB address space, depending on kernel build options, is not
 directly addressable by the kernel, but can be mapped into the kernel
 address space with functions like kmap() or kmap_atomic().

 These pages can't be used by slab/slub because they are not
 continuously mapped into the kernel address space.  However, since
 zsmalloc requires a mapping anyway to handle objects that span
 non-contiguous page boundaries, we do the kernel mapping as part of
 the process.

 So zspages, the conceptual slab in zsmalloc backed by single-order
 pages can include pages from the HIGHMEM zone as well.
>>> Thanks for your clarify,
>>>   http://lwn.net/Articles/537422/, your article about zswap in lwn.
>>>   "Additionally, the kernel slab allocator does not allow objects that
>>> are less
>>> than a page in size to span a page boundary. This means that if an
>>> object is
>>> PAGE_SIZE/2 + 1 bytes in size, it effectively use an entire page,
>>> resulting in
>>> ~50% waste. Hense there are *no kmalloc() cache size* between
>>> PAGE_SIZE/2 and
>>> PAGE_SIZE."
>>> Are your sure? It seems that kmalloc cache support big size, your can
>>> check in
>>> include/linux/kmalloc_sizes.h
>> Yes, kmalloc can allocate large objects > PAGE_SIZE, but there are no
>> cache sizes _between_ PAGE_SIZE/2 and PAGE_SIZE.  For example, on a
>> system with 4k pages, there are no caches between kmalloc-2048 and
>> kmalloc-4096.
> 
> kmalloc object > PAGE_SIZE/2 or > PAGE_SIZE should also allocate from
> slab cache, correct? Then how can alloc object w/o slab cache which
> contains this object size objects?

I have to admit, I didn't understand the question.

Thanks,
Seth

--
To unsubscribe from this list: send

[PATCH] checkpatch: Improve CamelCase test for Page

[Joe Perches]

Add the ClearPage/SetPage/TestClearPage/TestSetPage
variants to the not reported Page CamelCase variables.

Signed-off-by: Joe Perches 
---
 scripts/checkpatch.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 747bcd7..8a32306 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2930,7 +2930,7 @@ sub process {
my $var = $1;
if ($var !~ /$Constant/ &&
$var =~ /[A-Z]\w*[a-z]|[a-z]\w*[A-Z]/ &&
-   $var !~ /^Page[A-Z]/ &&
+   $var !~ 
/"^(?:Clear|Set|TestClear|TestSet|)Page[A-Z]/ &&
!defined $camelcase{$var}) {
$camelcase{$var} = 1;
WARN("CAMELCASE",


--
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: Read I/O starvation with writeback RAID controller

[Chris Friesen]

On 02/22/2013 02:35 PM, Jan Engelhardt wrote:


On Friday 2013-02-22 20:28, Martin Svec wrote:


Yes, I've already tried the ROW scheduler. It helped for some low iodepths
depending on quantum settings but generally didn't solve the problem. I think
the key issue is that none of the schedulers can throttle I/O according to e.g.
average request roundtrip time. Shaohua Li is right here:
https://lkml.org/lkml/2012/12/11/598 -- as long as there's free room in
device's queue they blindly dispatch requests to it.

Which is exactly what I see in deadline scheduler fifo queues: There're no read
requests to be scheduled between writes because all readers are starving. So
the scheduler keeps dispatching writes using all the remaining capacity of
device queue. Which in turn worses the read starvation. Bigger queue depth and
bigger writeback cache means higher chance for read starvation even from a
single writer.


Sounds just like the bufferbloat problem in networking.
Waiting for codel for the block layer  :)


Is there any way to somehow have the reads jump to the head of the queue 
in the disk controller?


Otherwise it seems like we might need to minimize the disk cache usage 
and do the scheduling in software.


This effectively mirrors what the codel people are doing with using tiny 
tx ring buffers to fight bufferbloat.  The difference is that with a NIC 
all you have to do is make sure the buffer doesn't empty and you get 
full speed whereas with a disk the more you stuff in the cache the 
better it can schedule things.


Chris
--
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: [rebased][PATCH 1/4] acpi: move x86/mm/srat.c to x86/kernel/acpi/srat.c

[David Rientjes]

On Fri, 22 Feb 2013, liguang wrote:

> srat table should present only on acpi domain,
> seems mm/ is not the right place for it.
> 
> Reviewed-by: Yasuaki Ishimatsu 
> Signed-off-by: liguang 

This is not rebased, it does not have 4819e14ff31e ("acpi, movablemem_map: 
Set numa_nodes_hotplug nodemask when using SRAT info.") but does have 
f7c24b7e1c41 ("acpi, memory-hotplug: support getting hotplug info from 
SRAT"), so I don't know how you're generating these patches.

You're also not sending this to any maintainer who would merge it, so 
please run scripts/get_maintainer.pl on it.
--
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/