Re: [PATCH] mfd: menelaus: use NULL instead of 0

2013-08-01 Thread Jingoo Han
On Friday, August 02, 2013 2:53 PM, Sachin Kamat wrote:
> On 2 August 2013 11:20, Jingoo Han  wrote:

[...]

> >
> > mutex_lock(_menelaus->lock);
> > -   if (vtg == 0)
> > +   if (vtg == NULL)
> 
> Instead you could just make this:
> if (!vtg)

Thank you for your comment. :)
It looks simpler. So, I will use it as you guide.

Best regards,
Jingoo Han



--
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] mfd: menelaus: use NULL instead of 0

2013-08-01 Thread Sachin Kamat
On 2 August 2013 11:20, Jingoo Han  wrote:
> 'mmc_callback_data' and 'vtg' are pointers.
> Fix the following sparse warning:
>
> drivers/mfd/menelaus.c:445:43: warning: Using plain integer as NULL pointer
> drivers/mfd/menelaus.c:469:20: warning: Using plain integer as NULL pointer
>
> Signed-off-by: Jingoo Han 
> ---
>  drivers/mfd/menelaus.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
> index 998ce8c..0f62ecd 100644
> --- a/drivers/mfd/menelaus.c
> +++ b/drivers/mfd/menelaus.c
> @@ -442,7 +442,7 @@ void menelaus_unregister_mmc_callback(void)
> menelaus_remove_irq_work(MENELAUS_MMC_S2D1_IRQ);
>
> the_menelaus->mmc_callback = NULL;
> -   the_menelaus->mmc_callback_data = 0;
> +   the_menelaus->mmc_callback_data = NULL;
>  }
>  EXPORT_SYMBOL(menelaus_unregister_mmc_callback);
>
> @@ -466,7 +466,7 @@ static int menelaus_set_voltage(const struct menelaus_vtg 
> *vtg, int mV,
> struct i2c_client *c = the_menelaus->client;
>
> mutex_lock(_menelaus->lock);
> -   if (vtg == 0)
> +   if (vtg == NULL)

Instead you could just make this:
if (!vtg)
> goto set_voltage;
>


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


Re: [PATCH v2 13/18] x86, numa, mem_hotplug: Skip all the regions the kernel resides in.

2013-08-01 Thread Tang Chen

On 08/01/2013 09:42 PM, Tejun Heo wrote:

On Thu, Aug 01, 2013 at 03:06:35PM +0800, Tang Chen wrote:

At early time, memblock will reserve some memory for the kernel,
such as the kernel code and data segments, initrd file, and so on=EF=BC=8C
which means the kernel resides in these memory regions.

Even if these memory regions are hotpluggable, we should not
mark them as hotpluggable. Otherwise the kernel won't have enough
memory to boot.

This patch finds out which memory regions the kernel resides in,
and skip them when finding all hotpluggable memory regions.

Signed-off-by: Tang Chen
Reviewed-by: Zhang Yanfei
---
  mm/memory=5Fhotplug.c |   45 +
   1 files changed, 45 insertions(+), 0 deletions(-)

diff --git a/mm/memory=5Fhotplug.c b/mm/memory=5Fhotplug.c
index 326e2f2..b800c9c 100644
--- a/mm/memory=5Fhotplug.c
+++ b/mm/memory=5Fhotplug.c
@@ -31,6 +31,7 @@
  #include
  #include
  #include
+#include
=20
  #include
=20


This patch is contaminated.  Can you please resend?It


It's wired. I'll rebase these patches to linux 3.11-rc3 and resend them all.

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


Re: [PATCH v2 10/18] x86, acpi: Try to find if SRAT is overrided earlier.

2013-08-01 Thread Tang Chen

On 08/02/2013 09:19 AM, Toshi Kani wrote:
..

+phys_addr_t __init early_acpi_override_srat(void)
+{
+   int i;
+   u32 length;
+   long offset;
+   void *ramdisk_vaddr;
+   struct acpi_table_header *table;
+   struct cpio_data file;
+   unsigned long map_step = NR_FIX_BTMAPS<<  PAGE_SHIFT;
+   phys_addr_t ramdisk_image = get_ramdisk_image();
+   char cpio_path[32] = "kernel/firmware/acpi/";


Don't you need to check if ramdisk is present before parsing the table?
You may need something like:

   if (!ramdisk_image || !get_ramdisk_size())
 return 0;


Yes, it is better to do such a check here. But is there a possibility that
no ramdisk is present and we come to setup_arch() ?

..

+
+   return ramdisk_image;


Doesn't this function return a physical address regardless of SRAT if a
ramdisk is present?


Yes, and it is not good. I'll add the check above so that this won't happen.

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/


[PATCH] staging/lustre: lloop depends on BLOCK

2013-08-01 Thread Xiong Zhou
From: Xiong Zhou 

Add a config option for llite/lloop in lustre driver, making it depends
on BLOCK to fix this better:
drivers/staging/lustre/lustre/fid/../include/linux/lustre_compat25.h:117:2:
error: implicit declaration of function ‘unregister_blkdev'

Also, remove the wrapper ll_unregister_blkdev which depends on BLOCK in
the header and just call unregister_blkdev in lloop.c based on Peng Tao's
comment. Drop the redundant dependency on STAGING for LUSTRE_FS, remove
some unnecessary jdb header files which depends on BLOCK btw.

Signed-off-by: Xiong Zhou 
Reviewed-by: Peng Tao 
---
 drivers/staging/lustre/lustre/Kconfig  |7 ++-
 drivers/staging/lustre/lustre/fld/fld_cache.c  |1 -
 drivers/staging/lustre/lustre/fld/fld_request.c|1 -
 .../lustre/lustre/include/linux/lustre_compat25.h  |7 ---
 drivers/staging/lustre/lustre/llite/Makefile   |2 +-
 drivers/staging/lustre/lustre/llite/lloop.c|6 ++
 drivers/staging/lustre/lustre/lvfs/fsfilt.c|1 -
 7 files changed, 9 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/lustre/lustre/Kconfig 
b/drivers/staging/lustre/lustre/Kconfig
index 0b45de0..4e898e4 100644
--- a/drivers/staging/lustre/lustre/Kconfig
+++ b/drivers/staging/lustre/lustre/Kconfig
@@ -1,6 +1,6 @@
 config LUSTRE_FS
tristate "Lustre file system client support"
-   depends on STAGING && INET && BLOCK && m
+   depends on INET && m
select LNET
select CRYPTO
select CRYPTO_CRC32
@@ -53,3 +53,8 @@ config LUSTRE_TRANSLATE_ERRNOS
bool
depends on LUSTRE_FS && !X86
default true
+
+config LUSTRE_LLITE_LLOOP
+   bool "Lustre virtual block device"
+   depends on LUSTRE_FS && BLOCK
+   default m
diff --git a/drivers/staging/lustre/lustre/fld/fld_cache.c 
b/drivers/staging/lustre/lustre/fld/fld_cache.c
index 347f2ae..8410107 100644
--- a/drivers/staging/lustre/lustre/fld/fld_cache.c
+++ b/drivers/staging/lustre/lustre/fld/fld_cache.c
@@ -45,7 +45,6 @@
 
 # include 
 # include 
-# include 
 # include 
 
 #include 
diff --git a/drivers/staging/lustre/lustre/fld/fld_request.c 
b/drivers/staging/lustre/lustre/fld/fld_request.c
index c99b945..049322a 100644
--- a/drivers/staging/lustre/lustre/fld/fld_request.c
+++ b/drivers/staging/lustre/lustre/fld/fld_request.c
@@ -44,7 +44,6 @@
 
 # include 
 # include 
-# include 
 # include 
 
 #include 
diff --git a/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h 
b/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h
index 426533b..018e604 100644
--- a/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h
+++ b/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h
@@ -111,13 +111,6 @@ static inline void ll_set_fs_pwd(struct fs_struct *fs, 
struct vfsmount *mnt,
 #define TREE_READ_LOCK_IRQ(mapping)spin_lock_irq(&(mapping)->tree_lock)
 #define TREE_READ_UNLOCK_IRQ(mapping)  spin_unlock_irq(&(mapping)->tree_lock)
 
-static inline
-int ll_unregister_blkdev(unsigned int dev, const char *name)
-{
-   unregister_blkdev(dev, name);
-   return 0;
-}
-
 #define ll_invalidate_bdev(a,b) invalidate_bdev((a))
 
 #ifndef FS_HAS_FIEMAP
diff --git a/drivers/staging/lustre/lustre/llite/Makefile 
b/drivers/staging/lustre/lustre/llite/Makefile
index dff0c04..f493e07 100644
--- a/drivers/staging/lustre/lustre/llite/Makefile
+++ b/drivers/staging/lustre/lustre/llite/Makefile
@@ -1,5 +1,5 @@
 obj-$(CONFIG_LUSTRE_FS) += lustre.o
-obj-$(CONFIG_LUSTRE_FS) += llite_lloop.o
+obj-$(CONFIG_LUSTRE_LLITE_LLOOP) += llite_lloop.o
 lustre-y := dcache.o dir.o file.o llite_close.o llite_lib.o llite_nfs.o \
rw.o lproc_llite.o namei.o symlink.o llite_mmap.o \
xattr.o remote_perm.o llite_rmtacl.o llite_capa.o \
diff --git a/drivers/staging/lustre/lustre/llite/lloop.c 
b/drivers/staging/lustre/lustre/llite/lloop.c
index e063efc..ae3dc9d 100644
--- a/drivers/staging/lustre/lustre/llite/lloop.c
+++ b/drivers/staging/lustre/lustre/llite/lloop.c
@@ -848,10 +848,8 @@ static void lloop_exit(void)
blk_cleanup_queue(loop_dev[i].lo_queue);
put_disk(disks[i]);
}
-   if (ll_unregister_blkdev(lloop_major, "lloop"))
-   CWARN("lloop: cannot unregister blkdev\n");
-   else
-   CDEBUG(D_CONFIG, "unregistered lloop major %d\n", lloop_major);
+
+   unregister_blkdev(lloop_major, "lloop");
 
OBD_FREE(disks, max_loop * sizeof(*disks));
OBD_FREE(loop_dev, max_loop * sizeof(*loop_dev));
diff --git a/drivers/staging/lustre/lustre/lvfs/fsfilt.c 
b/drivers/staging/lustre/lustre/lvfs/fsfilt.c
index 064445c..ce71f80 100644
--- a/drivers/staging/lustre/lustre/lvfs/fsfilt.c
+++ b/drivers/staging/lustre/lustre/lvfs/fsfilt.c
@@ -35,7 +35,6 @@
 #define DEBUG_SUBSYSTEM S_FILTER
 
 #include 
-#include 
 #include 
 #include 
 #include 

[PATCH] mfd: menelaus: use NULL instead of 0

2013-08-01 Thread Jingoo Han
'mmc_callback_data' and 'vtg' are pointers.
Fix the following sparse warning:

drivers/mfd/menelaus.c:445:43: warning: Using plain integer as NULL pointer
drivers/mfd/menelaus.c:469:20: warning: Using plain integer as NULL pointer

Signed-off-by: Jingoo Han 
---
 drivers/mfd/menelaus.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 998ce8c..0f62ecd 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -442,7 +442,7 @@ void menelaus_unregister_mmc_callback(void)
menelaus_remove_irq_work(MENELAUS_MMC_S2D1_IRQ);
 
the_menelaus->mmc_callback = NULL;
-   the_menelaus->mmc_callback_data = 0;
+   the_menelaus->mmc_callback_data = NULL;
 }
 EXPORT_SYMBOL(menelaus_unregister_mmc_callback);
 
@@ -466,7 +466,7 @@ static int menelaus_set_voltage(const struct menelaus_vtg 
*vtg, int mV,
struct i2c_client *c = the_menelaus->client;
 
mutex_lock(_menelaus->lock);
-   if (vtg == 0)
+   if (vtg == NULL)
goto set_voltage;
 
ret = menelaus_read_reg(vtg->vtg_reg);
-- 
1.7.10.4


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


[PATCH] MFD: ucb1x00-core: add CONFIG_PM_SLEEP to suspend/resume

2013-08-01 Thread Jingoo Han
Add CONFIG_PM_SLEEP to suspend/resume functions to fix the build
warnings when CONFIG_PM_SLEEP is not selected. This is because
sleep PM callbacks defined by SET_SYSTEM_SLEEP_PM_OPS are only used
when the CONFIG_PM_SLEEP is enabled.

drivers/mfd/ucb1x00-core.c:672:12: warning: 'ucb1x00_suspend' defined but not 
used [-Wunused-function]
drivers/mfd/ucb1x00-core.c:704:12: warning: 'ucb1x00_resume' defined but not 
used [-Wunused-function]

Signed-off-by: Jingoo Han 
---
 drivers/mfd/ucb1x00-core.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mfd/ucb1x00-core.c b/drivers/mfd/ucb1x00-core.c
index 70f02da..daec8c8 100644
--- a/drivers/mfd/ucb1x00-core.c
+++ b/drivers/mfd/ucb1x00-core.c
@@ -669,6 +669,7 @@ void ucb1x00_unregister_driver(struct ucb1x00_driver *drv)
mutex_unlock(_mutex);
 }
 
+#ifdef CONFIG_PM_SLEEP
 static int ucb1x00_suspend(struct device *dev)
 {
struct ucb1x00_plat_data *pdata = dev->platform_data;
@@ -736,6 +737,7 @@ static int ucb1x00_resume(struct device *dev)
mutex_unlock(_mutex);
return 0;
 }
+#endif
 
 static const struct dev_pm_ops ucb1x00_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(ucb1x00_suspend, ucb1x00_resume)
-- 
1.7.10.4


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


Re: [PATCH v2 1/1] mfd: palmas: Add power off control

2013-08-01 Thread Bill Huang
On Thu, 2013-08-01 at 21:08 +0800, Nishanth Menon wrote:
> On 04:08-20130801, Bill Huang wrote:
> > On Wed, 2013-07-31 at 19:57 +0800, Nishanth Menon wrote:
> > > 
> > > If you notice the reference code I send, atleast on TWL6035/37 variants 
> > > of Palmas, USB IRQ unmask is mandatory for power on with USB cable - 
> > > example usage scenario: extremely low battery, device powered off, plug 
> > > in usb cable to restart charging - you'd like to initiate charging logic 
> > > in bootloader, but that wont work if the device does not do OFF-ON 
> > > transition with usb cable plugged in for vbus.
> > > 
> > Why do we need to add Palmas USB_IRQ unmask logic in shutdown? Does that
> > mean for all platform using Palmas has to unmask USB IRQ (including
> > those do not power vbus through Palmas)? Can't we just have a simple
> > shutdown function but have the VBus programming been done in USB driver
> > or maybe platform driver since it is platform specific control?
> we dont have a irq cleanup, irq handling is done in palmas-mfd. Further,
> 
> Why would USB driver care about vbus supply needs in complete power off
> - it is the job of palmas driver? Further, palmas-mfd shutdown
> handler(currently missing) if probably cleansup things:
> 
>  mfd_remove_devices(palmas->dev);
>   palmas_irq_exit(palmas);
> 
> shutdown sequence becomes complicated further esp if things are
> cleanedup in shutdown (Dummy patch[1]).
> 
>  
> All I am saying is this: shutdown should allow powerup functionality to
> work as well, how we do that is upto us - I personally found it a little
> easier to keep the IRQ unmask in shutdown easier to deal with, but other
> options might be possible as well.

I'm not sure if I understand your comments completely (maybe due to I'm
not familiar with the mechanism of unmasking USB IRQ in Palmas driver)
but doing cleanup in each driver shutdown handler makes sense to me, if
those clean up can be done in shutdown then we can make power off
function as simple as possible and being part of Palmas mfd driver?
> 
> [1]
> diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
> index e4d1c70..6998863 100644
> --- a/drivers/mfd/palmas.c
> +++ b/drivers/mfd/palmas.c
> @@ -447,6 +447,11 @@ static int palmas_i2c_remove(struct i2c_client *i2c)
>   return 0;
>  }
>  
> +static void palmas_i2c_shutdown(struct i2c_client *i2c)
> +{
> + palmas_i2c_remove(i2c);
> +}
> +
>  static const struct i2c_device_id palmas_i2c_id[] = {
>   { "palmas", },
>   { "twl6035", },
> @@ -464,6 +469,7 @@ static struct i2c_driver palmas_i2c_driver = {
>   },
>   .probe = palmas_i2c_probe,
>   .remove = palmas_i2c_remove,
> + .shutdown = palmas_i2c_shutdown,
>   .id_table = palmas_i2c_id,
>  };
>  


--
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] mfd: ab8500-gpadc: add CONFIG_PM_SLEEP to suspend/resume

2013-08-01 Thread Jingoo Han
Add CONFIG_PM_SLEEP to suspend/resume functions to fix the build
warnings when CONFIG_PM_SLEEP is not selected. This is because
sleep PM callbacks defined by SET_SYSTEM_SLEEP_PM_OPS are only used
when the CONFIG_PM_SLEEP is enabled.

drivers/mfd/ab8500-gpadc.c:891:12: warning: 'ab8500_gpadc_suspend' defined but 
not used [-Wunused-function]
drivers/mfd/ab8500-gpadc.c:903:12: warning: 'ab8500_gpadc_resume' defined but 
not used [-Wunused-function]

Signed-off-by: Jingoo Han 
---
 drivers/mfd/ab8500-gpadc.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mfd/ab8500-gpadc.c b/drivers/mfd/ab8500-gpadc.c
index 77c616f..36000f9 100644
--- a/drivers/mfd/ab8500-gpadc.c
+++ b/drivers/mfd/ab8500-gpadc.c
@@ -888,6 +888,7 @@ static int ab8500_gpadc_runtime_resume(struct device *dev)
 }
 #endif
 
+#ifdef CONFIG_PM_SLEEP
 static int ab8500_gpadc_suspend(struct device *dev)
 {
struct ab8500_gpadc *gpadc = dev_get_drvdata(dev);
@@ -915,6 +916,7 @@ static int ab8500_gpadc_resume(struct device *dev)
mutex_unlock(>ab8500_gpadc_lock);
return ret;
 }
+#endif
 
 static int ab8500_gpadc_probe(struct platform_device *pdev)
 {
-- 
1.7.10.4


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


[PATCH 1/2] mfd: ab8500-gpadc: add CONFIG_PM_RUNTIME to runtime_suspend/runtime_resume

2013-08-01 Thread Jingoo Han
Add CONFIG_PM_RUNTIME to runtime_suspend/runtime_resume functions
to fix the build warnings when CONFIG_PM_RUNTIME is not selected.
This is because runtime PM callbacks defined by SET_RUNTIME_PM_OPS
are only used when the CONFIG_PM_RUNTIME is enabled.

drivers/mfd/ab8500-gpadc.c:870:12: warning: 'ab8500_gpadc_runtime_suspend' 
defined but not used [-Wunused-function]
drivers/mfd/ab8500-gpadc.c:878:12: warning: 'ab8500_gpadc_runtime_resume' 
defined but not used [-Wunused-function]

Signed-off-by: Jingoo Han 
---
 drivers/mfd/ab8500-gpadc.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mfd/ab8500-gpadc.c b/drivers/mfd/ab8500-gpadc.c
index 7623e91..77c616f 100644
--- a/drivers/mfd/ab8500-gpadc.c
+++ b/drivers/mfd/ab8500-gpadc.c
@@ -867,6 +867,7 @@ static void ab8500_gpadc_read_calibration_data(struct 
ab8500_gpadc *gpadc)
gpadc->cal_data[ADC_INPUT_VBAT].offset);
 }
 
+#ifdef CONFIG_PM_RUNTIME
 static int ab8500_gpadc_runtime_suspend(struct device *dev)
 {
struct ab8500_gpadc *gpadc = dev_get_drvdata(dev);
@@ -885,6 +886,7 @@ static int ab8500_gpadc_runtime_resume(struct device *dev)
dev_err(dev, "Failed to enable vtvout LDO: %d\n", ret);
return ret;
 }
+#endif
 
 static int ab8500_gpadc_suspend(struct device *dev)
 {
-- 
1.7.10.4


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


Re: [PATCH v8 10/12] iommu/exynos: add bus notifier for registering System MMU

2013-08-01 Thread Rahul Sharma
Hi Cho,

On Fri, Jul 26, 2013 at 5:00 PM, Cho KyongHo  wrote:
> When a device driver is registered, all constructs to handle System MMU
> is prepared by bus notifier call.
>
> Signed-off-by: Cho KyongHo 
> ---
>  drivers/iommu/exynos-iommu.c |  708 -
>  1 files changed, 552 insertions(+), 156 deletions(-)
>
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index f9853fe..c62c244 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -27,6 +27,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>
>  #include 
>  #include 
> @@ -80,7 +83,13 @@
>  #define CTRL_BLOCK 0x7
>  #define CTRL_DISABLE   0x0
>
> +#define CFG_LRU0x1
> +#define CFG_QOS(n) ((n & 0xF) << 7)
> +#define CFG_MASK   0x0150 /* Selecting bit 0-15, 20, 22 and 24 */
> +#define CFG_ACGEN  (1 << 24) /* System MMU 3.3 only */
> +#define CFG_SYSSEL (1 << 22) /* System MMU 3.2 only */
>  #define CFG_FLPDCACHE  (1 << 20) /* System MMU 3.2+ only */
> +#define CFG_SHAREABLE  (1 << 12) /* System MMU 3.x only */
>
>  #define REG_MMU_CTRL   0x000
>  #define REG_MMU_CFG0x004
> @@ -154,6 +163,14 @@ static char *sysmmu_fault_name[SYSMMU_FAULTS_NUM] = {
> "UNKNOWN FAULT"
>  };
>
> +struct exynos_iommu_client {
> +   struct list_head node;  /* entry of exynos_iommu_domain.clients */
> +   struct device *dev;
> +   spinlock_t lock;
> +   int num_sysmmu;
> +   struct device *sysmmu[0];

Shouldn't we keep limit on the max number of iommu's to a single client ? Even
this way, you will hit array overrun with multiple iommu's.

> +};
> +
>  struct exynos_iommu_domain {
> struct list_head clients; /* list of sysmmu_drvdata.node */
> unsigned long *pgtable; /* lv1 page table, 16KB */
> @@ -165,12 +182,14 @@ struct exynos_iommu_domain {
>  struct sysmmu_drvdata {
> struct list_head node; /* entry of exynos_iommu_domain.clients */
> struct device *sysmmu;  /* System MMU's device descriptor */
> -   struct device *dev; /* Owner of system MMU */
> +   struct device *master;  /* Owner of system MMU */
> int nsfrs;
> struct clk *clk;
> +   struct clk *clk_master;
> int activations;
> rwlock_t lock;
> struct iommu_domain *domain;
> +   bool runtime_active;
> unsigned long pgtable;
> void __iomem *sfrbases[0];
>  };
> @@ -245,7 +264,6 @@ static void __sysmmu_tlb_invalidate_entry(void __iomem 
> *sfrbase,
>  static void __sysmmu_set_ptbase(void __iomem *sfrbase,
>unsigned long pgd)
>  {
> -   __raw_writel(0x1, sfrbase + REG_MMU_CFG); /* 16KB LV1, LRU */
> __raw_writel(pgd, sfrbase + REG_PT_BASE_ADDR);
>
> __sysmmu_tlb_invalidate(sfrbase);
> @@ -273,6 +291,7 @@ void exynos_sysmmu_set_prefbuf(struct device *dev,
> if (!is_sysmmu_active(data))
> goto finish;
>
> +   clk_enable(data->clk_master);
> for (i = 0; i < data->nsfrs; i++) {
> if ((readl(data->sfrbases[i] + REG_MMU_VERSION) >> 28) == 3) {
> if (!sysmmu_block(data->sfrbases[i]))
> @@ -298,6 +317,7 @@ void exynos_sysmmu_set_prefbuf(struct device *dev,
> sysmmu_unblock(data->sfrbases[i]);
> }
> }
> +   clk_disable(data->clk_master);
>  finish:
> read_unlock_irqrestore(>lock, flags);
>  }
> @@ -331,12 +351,13 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void 
> *dev_id)
>  {
> /* SYSMMU is in blocked when interrupt occurred. */
> struct sysmmu_drvdata *data = dev_id;
> +   struct exynos_iommu_client *client = NULL;
> enum exynos_sysmmu_inttype itype;
> unsigned long addr = -1;
> -
> int i, ret = -ENOSYS;
>
> -   read_lock(>lock);
> +   if (data->master)
> +   client = data->master->archdata.iommu;
>
> WARN_ON(!is_sysmmu_active(data));
>
> @@ -348,6 +369,10 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void 
> *dev_id)
> break;
> }
>
> +   if (client)
> +   spin_lock(>lock);
> +   read_lock(>lock);
> +
> if (i == data->nsfrs) {
> itype = SYSMMU_FAULT_UNKNOWN;
> } else {
> @@ -361,7 +386,7 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void 
> *dev_id)
> }
>
> if (data->domain)
> -   ret = report_iommu_fault(data->domain, data->dev,
> +   ret = report_iommu_fault(data->domain, data->master,
> addr, itype);
>
> if (!ret && (itype != SYSMMU_FAULT_UNKNOWN))
> @@ -378,177 +403,251 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void 
> *dev_id)
> sysmmu_unblock(data->sfrbases[i]);
>
> read_unlock(>lock);
> +   if (client)
> +   

[PATCH v2] acpi: video: remove unused code

2013-08-01 Thread Felipe Contreras
_BCM_use_index and _BCL_use_index are never used and probably never will.

Signed-off-by: Felipe Contreras 
---
 drivers/acpi/video.c | 12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 0ec434d..1a04dfe 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -185,8 +185,6 @@ struct acpi_video_device_cap {
 struct acpi_video_brightness_flags {
u8 _BCL_no_ac_battery_levels:1; /* no AC/Battery levels in _BCL */
u8 _BCL_reversed:1; /* _BCL package is in a reversed order*/
-   u8 _BCL_use_index:1;/* levels in _BCL are index values */
-   u8 _BCM_use_index:1;/* input of _BCM is an index value */
u8 _BQC_use_index:1;/* _BQC returns an index value */
 };
 
@@ -806,16 +804,6 @@ acpi_video_init_brightness(struct acpi_video_device 
*device)
br->count = count;
device->brightness = br;
 
-   /* Check the input/output of _BQC/_BCL/_BCM */
-   if ((max_level < 100) && (max_level <= (count - 2)))
-   br->flags._BCL_use_index = 1;
-
-   /*
-* _BCM is always consistent with _BCL,
-* at least for all the laptops we have ever seen.
-*/
-   br->flags._BCM_use_index = br->flags._BCL_use_index;
-
/* _BQC uses INDEX while _BCL uses VALUE in some laptops */
br->curr = level = max_level;
 
-- 
1.8.3.4

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


Re: RFC: vfio-pci API for PCI bus/slot (hot) resets

2013-08-01 Thread Benjamin Herrenschmidt
On Thu, 2013-08-01 at 16:18 -0600, Alex Williamson wrote:
> vfio-pci needs to support an interface to do hot resets (PCI parent
> bridge secondary bus reset).   We need this to support reset of
> co-assigned devices where one or more of the devices does not support
> function level reset.  In particular, discrete graphics cards typically
> have no reset options other than doing a link reset.  

Link reset != hot reset but yeah I see your point. There is more too,
there is fundamental reset which may or may not be something we can
control for individual slots (ie, switch legs) depending on platform
specific stuff...

> What I have below
> is a bit awkward, so I welcome other ideas to accomplish this goal.
> I've been using a "blind" interface based on all affected devices
> belonging to the same VFIO container for current VGA testing.  This is
> ok when all you want to do is VGA, but I'd really like to make use of
> this any time a device doesn't support a function level reset.  I've
> posted a series to the PCI list to add bus and slot reset interfaces to
> PCI-core, this API is how we expose that through VFIO to a user.  Please
> comment.  Thanks,

Also in some cases, at least for us, we have a problem where the scope
of the reset can be larger than the group ... in this case I think we
need to forbid the reset.

For us, it's also tied into our "EEH" error handling. IE. The way the
guest will request some of these things is going to be via firmware APIs
that we have yet to implement, but that we were also thinking of
implementing entire in the kernel rather than qemu for various
reasons... IE. There is more to error handling & recovery in our case at
least than AER and reset :-)

I need to spend more time reading your proposal and see how it can work
for us (or not...)... but we might end up just doing our own thing that
carries the whole EEH API instead.

Cheers,
Ben.

> Alex
> 
> ---
> Mechanism to do PCI hot resets through VFIO:
> 
> VFIO is fundamentally an IOMMU group and device level interface.
> There's no concept of buses, slots, or hierarchies of devices.  There
> are only IOMMU group and devices.  A bus (or slot) may contain exactly
> one IOMMU group, multiple IOMMU groups, or a portion of an IOMMU group.
> An IOMMU group may contain one or more devices.
> 
> The first question is perhaps where should we create the interface to do
> a PCI hot reset.  Assuming an ioctl interface, our choices are the
> group, the container, or the device file descriptors.  Groups and
> containers are not PCI specific, so an extension on either of those
> doesn't make much sense.  They also don't have much granularity if your
> goal is to do a hot reset on the smallest subset of devices you can.
> Therefore the only choice seems to be a VFIO device level interface.
> 
> The fact that a hot reset affects multiple devices also raises concerns.
> How do we make sure a user has sufficient access/privilege to perform
> this operation?  If all of the affected devices are within the same
> group, then we know the user already "owns" all those devices.  Using
> groups as the boundary excludes a number of use cases though.  The user
> would need to prove that they also own the other groups or devices that
> are affected by the reset.  This might be multiple groups, so the ioctl
> quickly grows to requiring a list of file descriptors be passed for
> validation.
> 
> We already use the group file descriptor as a unit of ownership for
> enabling the container, so it seems like it would make sense to use it
> here too.  The alternative is a device file descriptor, but groups may
> encompass devices the user doesn't care to use and we don't want to
> require that they open a file descriptor simply to perform a hot reset.
> Groups can also contain devices that the user cannot open, for instance
> those owned by VFIO "compatible" drivers like pci-stub or pcieport.
> 
> The user also needs to know the set of devices affected by a hot reset,
> otherwise they have no idea which group file descriptors to pass to such
> an interface.  That implies we also need a separate "info" ioctl for the
> user to learn that information.  We could argue that the user could
> learn this information from sysfs, but that imposes non-trivial library
> or code overhead on the user to evaluate the topology.  The PCI hot
> reset info ioctl would need to indicate whether a hot reset is
> available, and the set of affected devices.  It may be useful to provide
> this as a {group, device} pair so the user doesn't need to
> cross-reference each device with sysfs to determine the group for the
> device.  This would then provide both the set of groups required to
> perform the hot reset and the set of devices affected by the hot reset.
> 
> As an alternative, we could consider simply requiring that all of the
> devices affected by a hot reset belong to the same VFIO container.
> However, allowing multiple groups per container is an optional IOMMU
> capability 

Re: [ANNOUNCE] 3.10.4-rt1

2013-08-01 Thread Benjamin Herrenschmidt
On Thu, 2013-08-01 at 20:03 -0400, Paul Gortmaker wrote:
> I've added Ben to the CC in case he has a suggestion on
> how best to fix this, even though it is not yet mainline.

Can you exchange with a TIF_ that isn't used in asm ? For example
TIF_PERFMON_* ? Keep all the asm ones below 16 and move up the ones
that are used in C only ?

Cheers,
Ben.


--
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: dts: exynos5420: add ADC device tree node

2013-08-01 Thread Naveen Krishna Ch
On 2 August 2013 10:20, sunil joshi  wrote:
> Hi Naveen,
> exynos5250.dtsi also needs this entry.
> Pls consider adding adc node in exynos5250.dtsi as well, and move the
> common content of adc node to exynos5.dtsi.
Sure, sunil will run a boot test and submit the code
>
> Regards
> Sunil
>
>
> On Thu, Aug 1, 2013 at 2:58 PM, Naveen Krishna Chatradhi
>  wrote:
>> From: Jaehoon Kim 
>>
>> Add device tree node for ADC in exynos5420.dtsi
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
>> Signed-off-by: Doug Anderson 
>> ---
>>  arch/arm/boot/dts/exynos5420.dtsi |   11 +++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
>> b/arch/arm/boot/dts/exynos5420.dtsi
>> index 8c54c4b..074e1bc 100644
>> --- a/arch/arm/boot/dts/exynos5420.dtsi
>> +++ b/arch/arm/boot/dts/exynos5420.dtsi
>> @@ -145,4 +145,15 @@
>> clocks = < 260>, < 131>;
>> clock-names = "uart", "clk_uart_baud0";
>> };
>> +
>> +   adc: adc@12D1 {
>> +   compatible = "samsung,exynos-adc-v2";
>> +   reg = <0x12D1 0x100>, <0x10040720 0x4>;
>> +   interrupts = <0 106 0>;
>> +   #io-channel-cells = <1>;
>> +   io-channel-ranges;
>> +   clocks = < 270>;
>> +   clock-names = "adc";
>> +   status = "disabled";
>> +   };
>>  };
>> --
>> 1.7.9.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to 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/



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


Re: Re: [RFC][PATCH 3/4] tracing/kprobes: Fail to unregister if probe event files are open

2013-08-01 Thread Masami Hiramatsu
(2013/08/01 22:34), Oleg Nesterov wrote:
> Just one off-topic note,
> 
>> > @@ -632,7 +635,9 @@ static int release_all_trace_probes(void)
>> >/* TODO: Use batch unregistration */
>> >while (!list_empty(_list)) {
>> >tp = list_entry(probe_list.next, struct trace_probe, list);
>> > -  unregister_trace_probe(tp);
>> > +  ret = unregister_trace_probe(tp);
>> > +  if (ret)
>> > +  goto end;
>> >free_trace_probe(tp);
>> >}
> This obviously breaks all-or-nothing semantics (I mean, this breaks
> the intent, the current code is buggy).

I see, since we can't lock all operations, we have to change the
semantics. I think it's OK.

> I think we can't avoid this, and I hope this is fine. But then perhaps
> we should simply remove the "list_for_each_entry" check above?

Yes, it should be done. And in that case, I'd like to remove
all removable probes, as much as possible.

BTW, I'd like to replace this "remove all" behavior with
writing "-:*", instead of writing without append flag.

Thank you,
-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


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


Re: [PATCH] acpi: video: fix reversed indexed BQC

2013-08-01 Thread Aaron Lu
On 08/02/2013 12:50 PM, Felipe Contreras wrote:
> On Thu, Aug 1, 2013 at 11:30 PM, Aaron Lu  wrote:
>> On 08/02/2013 12:11 PM, Felipe Contreras wrote:
>>> On Thu, Aug 1, 2013 at 9:03 PM, Aaron Lu  wrote:
 On 08/02/2013 07:34 AM, Felipe Contreras wrote:
> Commit 1a7c618 (ACPI video: support _BQC/_BCL/_BCM methods that use
> index values) assumed that bl->levels were not reverted, but at this
> point they already are, so there's no need to revert them yet again.

 When acpi_video_bqc_value_to_level is called, bl->levels is not
 reverted.
>>>
>>> This is the code that turns br->flags._BCL_reversed on:
>>>
>>>   if (max_level == br->levels[2]) {
>>>   br->flags._BCL_reversed = 1;
>>>   sort(>levels[2], count - 2, sizeof(br->levels[2]),
>>>   acpi_video_cmp_level, NULL);
>>>   }
>>>
>>> Now tell me how br->flags._BCL_reversed can be on, and the br->levels
>>> *not* reverted.
>>
>> Oh yes, it is reverted to be in increase order, so it is not in reverse
>> order. I'm a little confused by these words.
> 
> br->levels is always ascending, but that doesn't mean _BCL is.

Right.

> 
>> Please see acpi_video_bqc_quirk, we set _BQC_use_index by revert the
>> level on a reversed _BCL, so we will need to revert level here too.
> 
> I cannot parse that sentence, but nothing needs to change there; to
> find out if _BQC is using an index, we need to see if the returned
> value is the index of the level we are looking for, and to find that
> out we need the original list of levels, which can be found by
> reverting the already reverted list. If this wasn't the case there

Yes, but instead of reverting the already reverted list, we revert the
returned value to get the correct index in the reverted list. But your
patch removes the revert, is it correct?

> would not be any need for the _BCL_reversed flag.
> 
-Aaron
--
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] acpi: video: remove unused code

2013-08-01 Thread Felipe Contreras
_BCM_use_index is never used and probably never will.

Signed-off-by: Felipe Contreras 
---
 drivers/acpi/video.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 0ec434d..54e2d4d 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -186,7 +186,6 @@ struct acpi_video_brightness_flags {
u8 _BCL_no_ac_battery_levels:1; /* no AC/Battery levels in _BCL */
u8 _BCL_reversed:1; /* _BCL package is in a reversed order*/
u8 _BCL_use_index:1;/* levels in _BCL are index values */
-   u8 _BCM_use_index:1;/* input of _BCM is an index value */
u8 _BQC_use_index:1;/* _BQC returns an index value */
 };
 
@@ -810,12 +809,6 @@ acpi_video_init_brightness(struct acpi_video_device 
*device)
if ((max_level < 100) && (max_level <= (count - 2)))
br->flags._BCL_use_index = 1;
 
-   /*
-* _BCM is always consistent with _BCL,
-* at least for all the laptops we have ever seen.
-*/
-   br->flags._BCM_use_index = br->flags._BCL_use_index;
-
/* _BQC uses INDEX while _BCL uses VALUE in some laptops */
br->curr = level = max_level;
 
-- 
1.8.3.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: __ftrace_hash_rec_update FTRACE_WARN_ON.

2013-08-01 Thread Steve Hodgson
On Tue, Jul 30, 2013 at 5:51 PM, Steven Rostedt  wrote:
> On Sat, 2013-07-27 at 12:16 -0700, Steve Hodgson wrote:
>
>> This patch fixes ftrace across module removal/reinsertion on our 3.6.11 
>> kernel.
>
> I found a few corner cases that this patch doesn't work with, and the
> solution is just getting uglier and uglier.
>
> I found a new solution that seems to handle all the corner cases
> (including this one). Can you test this as well. I want to add your
> tested-by tag for this too.
>
> Thanks!
>
> -- Steve

This patch also fixes the issue for me: ftrace works fine across module removal.

Sorry for being a little slow in testing this.

- Steve

>
> From 4c647dde26cf8c47ccaaed6f2e2fffee5dab5871 Mon Sep 17 00:00:00 2001
> From: "Steven Rostedt (Red Hat)" 
> Date: Tue, 30 Jul 2013 00:04:32 -0400
> Subject: [PATCH] ftrace: Check module functions being traced on reload
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> There's been a nasty bug that would show up and not give much info.
> The bug displayed the following warning:
>
>  WARNING: at kernel/trace/ftrace.c:1529 __ftrace_hash_rec_update+0x1e3/0x230()
>  Pid: 20903, comm: bash Tainted: G   O 3.6.11+ #38405.trunk
>  Call Trace:
>   [] warn_slowpath_common+0x7f/0xc0
>   [] warn_slowpath_null+0x1a/0x20
>   [] __ftrace_hash_rec_update+0x1e3/0x230
>   [] ftrace_hash_move+0x28/0x1d0
>   [] ? kfree+0x2c/0x110
>   [] ftrace_regex_release+0x8e/0x150
>   [] __fput+0xae/0x220
>   [] fput+0xe/0x10
>   [] task_work_run+0x72/0x90
>   [] do_notify_resume+0x6c/0xc0
>   [] ? trace_hardirqs_on_thunk+0x3a/0x3c
>   [] int_signal+0x12/0x17
>  ---[ end trace 793179526ee09b2c ]---
>
> It was finally narrowed down to unloading a module that was being traced.
>
> It was actually more than that. When functions are being traced, there's
> a table of all functions that have a ref count of the number of active
> tracers attached to that function. When a function trace callback is
> registered to a function, the function's record ref count is incremented.
> When it is unregistered, the function's record ref count is decremented.
> If an inconsistency is detected (ref count goes below zero) the above
> warning is shown and the function tracing is permanently disabled until
> reboot.
>
> The ftrace callback ops holds a hash of functions that it filters on
> (and/or filters off). If the hash is empty, the default means to filter
> all functions (for the filter_hash) or to disable no functions (for the
> notrace_hash).
>
> When a module is unloaded, it frees the function records that represent
> the module functions. These records exist on their own pages, that is
> function records for one module will not exist on the same page as
> function records for other modules or even the core kernel.
>
> Now when a module unloads, the records that represents its functions are
> freed. When the module is loaded again, the records are recreated with
> a default ref count of zero (unless there's a callback that traces all
> functions, then they will also be traced, and the ref count will be
> incremented).
>
> The problem is that if an ftrace callback hash includes functions of the
> module being unloaded, those hash entries will not be removed. If the
> module is reloaded in the same location, the hash entries still point
> to the functions of the module but the module's ref counts do not reflect
> that.
>
> With the help of Steve and Joern, we found a reproducer:
>
>  Using uinput module and uinput_release function.
>
>  cd /sys/kernel/debug/tracing
>  modprobe uinput
>  echo uinput_release > set_ftrace_filter
>  echo function > current_tracer
>  rmmod uinput
>  modprobe uinput
>  # check /proc/modules to see if loaded in same addr, otherwise try again
>  echo nop > current_tracer
>
>  [BOOM]
>
> The above loads the uinput module, which creates a table of functions that
> can be traced within the module.
>
> We add uinput_release to the filter_hash to trace just that function.
>
> Enable function tracincg, which increments the ref count of the record
> associated to uinput_release.
>
> Remove uinput, which frees the records including the one that represents
> uinput_release.
>
> Load the uinput module again (and make sure it's at the same address).
> This recreates the function records all with a ref count of zero,
> including uinput_release.
>
> Disable function tracing, which will decrement the ref count for 
> uinput_release
> which is now zero because of the module removal and reload, and we have
> a mismatch (below zero ref count).
>
> The solution is to check all currently tracing ftrace callbacks to see if any
> are tracing any of the module's functions when a module is loaded (it already 
> does
> that with callbacks that trace all functions). If a callback happens to have
> a module function being traced, it increments that records ref count and 
> starts
> tracing that function.
>
> There may be a strange side effect 

Re: [PATCH] ARM: dts: exynos5420: add ADC device tree node

2013-08-01 Thread sunil joshi
Hi Naveen,
exynos5250.dtsi also needs this entry.
Pls consider adding adc node in exynos5250.dtsi as well, and move the
common content of adc node to exynos5.dtsi.

Regards
Sunil


On Thu, Aug 1, 2013 at 2:58 PM, Naveen Krishna Chatradhi
 wrote:
> From: Jaehoon Kim 
>
> Add device tree node for ADC in exynos5420.dtsi
>
> Signed-off-by: Naveen Krishna Chatradhi 
> Signed-off-by: Doug Anderson 
> ---
>  arch/arm/boot/dts/exynos5420.dtsi |   11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
> b/arch/arm/boot/dts/exynos5420.dtsi
> index 8c54c4b..074e1bc 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -145,4 +145,15 @@
> clocks = < 260>, < 131>;
> clock-names = "uart", "clk_uart_baud0";
> };
> +
> +   adc: adc@12D1 {
> +   compatible = "samsung,exynos-adc-v2";
> +   reg = <0x12D1 0x100>, <0x10040720 0x4>;
> +   interrupts = <0 106 0>;
> +   #io-channel-cells = <1>;
> +   io-channel-ranges;
> +   clocks = < 270>;
> +   clock-names = "adc";
> +   status = "disabled";
> +   };
>  };
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v2 02/18] earlycpio.c: Fix the confusing comment of find_cpio_data().

2013-08-01 Thread Tang Chen

On 08/02/2013 05:57 AM, Toshi Kani wrote:
..

  struct cpio_data __cpuinit find_cpio_data(const char *path, void *data,


This patch does not apply cleanly.  It seems that your branch does not
have 0db0628d90125193280eabb501c94feaf48fa9ab.



I have rebased the patch-set to linux 3.11-rc3. And will resend it later.

Thanks.

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


Re: [PATCH] acpi: video: fix reversed indexed BQC

2013-08-01 Thread Felipe Contreras
On Thu, Aug 1, 2013 at 11:30 PM, Aaron Lu  wrote:
> On 08/02/2013 12:11 PM, Felipe Contreras wrote:
>> On Thu, Aug 1, 2013 at 9:03 PM, Aaron Lu  wrote:
>>> On 08/02/2013 07:34 AM, Felipe Contreras wrote:
 Commit 1a7c618 (ACPI video: support _BQC/_BCL/_BCM methods that use
 index values) assumed that bl->levels were not reverted, but at this
 point they already are, so there's no need to revert them yet again.
>>>
>>> When acpi_video_bqc_value_to_level is called, bl->levels is not
>>> reverted.
>>
>> This is the code that turns br->flags._BCL_reversed on:
>>
>>   if (max_level == br->levels[2]) {
>>   br->flags._BCL_reversed = 1;
>>   sort(>levels[2], count - 2, sizeof(br->levels[2]),
>>   acpi_video_cmp_level, NULL);
>>   }
>>
>> Now tell me how br->flags._BCL_reversed can be on, and the br->levels
>> *not* reverted.
>
> Oh yes, it is reverted to be in increase order, so it is not in reverse
> order. I'm a little confused by these words.

br->levels is always ascending, but that doesn't mean _BCL is.

> Please see acpi_video_bqc_quirk, we set _BQC_use_index by revert the
> level on a reversed _BCL, so we will need to revert level here too.

I cannot parse that sentence, but nothing needs to change there; to
find out if _BQC is using an index, we need to see if the returned
value is the index of the level we are looking for, and to find that
out we need the original list of levels, which can be found by
reverting the already reverted list. If this wasn't the case there
would not be any need for the _BCL_reversed flag.

-- 
Felipe Contreras
--
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] fs: Allow unprivileged linkat(..., AT_EMPTY_PATH) aka flink

2013-08-01 Thread Andy Lutomirski
Every now and then someone proposes a new flink syscall, and this spawns
a long discussion of whether it would be a security problem.  I think
that this is missing the point: flink is *already* allowed without
privilege as long as /proc is mounted -- it's called AT_SYMLINK_FOLLOW.

Now that O_TMPFILE is here, the ability to create a file with O_TMPFILE,
write it, and link it in is very convenient.  The only problem is that
it requires that /proc be mounted so that you can do:

linkat(AT_FDCWD, "/proc/self/fd/", dfd, path, AT_SYMLINK_NOFOLLOW)

This sucks -- it's much nicer to do:

linkat(tmpfd, "", dfd, path, AT_EMPTY_PATH)

Let's allow it.

If this turns out to be excessively scary, it we could instead require
that the inode in question be I_LINKABLE, but this seems pointless given
the /proc situation

Signed-off-by: Andy Lutomirski 
---
 fs/namei.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/fs/namei.c b/fs/namei.c
index 8b61d10..89a612e 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -3671,15 +3671,11 @@ SYSCALL_DEFINE5(linkat, int, olddfd, const char __user 
*, oldname,
if ((flags & ~(AT_SYMLINK_FOLLOW | AT_EMPTY_PATH)) != 0)
return -EINVAL;
/*
-* To use null names we require CAP_DAC_READ_SEARCH
-* This ensures that not everyone will be able to create
-* handlink using the passed filedescriptor.
+* Using empty names is equivalent to using AT_SYMLINK_FOLLOW
+* on /proc/self/fd/.
 */
-   if (flags & AT_EMPTY_PATH) {
-   if (!capable(CAP_DAC_READ_SEARCH))
-   return -ENOENT;
+   if (flags & AT_EMPTY_PATH)
how = LOOKUP_EMPTY;
-   }
 
if (flags & AT_SYMLINK_FOLLOW)
how |= LOOKUP_FOLLOW;
-- 
1.8.3.1

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


Re: [PATCH v2 3/3] sched: clean-up struct sd_lb_stat

2013-08-01 Thread Preeti U Murthy
Hi Joonsoo,

On 08/02/2013 07:20 AM, Joonsoo Kim wrote:
> There is no reason to maintain separate variables for this_group
> and busiest_group in sd_lb_stat, except saving some space.
> But this structure is always allocated in stack, so this saving
> isn't really benificial.
> 
> This patch unify these variables, so IMO, readability may be improved.
> 
> Signed-off-by: Joonsoo Kim 
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 7f51b8c..f72ee7d 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4195,36 +4195,6 @@ static unsigned long task_h_load(struct task_struct *p)
> 
>  /** Helpers for find_busiest_group /
>  /*
> - * sd_lb_stats - Structure to store the statistics of a sched_domain
> - *   during load balancing.
> - */
> -struct sd_lb_stats {
> - struct sched_group *busiest; /* Busiest group in this sd */
> - struct sched_group *this;  /* Local group in this sd */
> - unsigned long total_load;  /* Total load of all groups in sd */
> - unsigned long total_pwr;   /*   Total power of all groups in sd */
> - unsigned long avg_load;/* Average load across all groups in sd */
> -
> - /** Statistics of this group */
> - unsigned long this_load;
> - unsigned long this_load_per_task;
> - unsigned long this_nr_running;
> - unsigned long this_has_capacity;
> - unsigned int  this_idle_cpus;
> -
> - /* Statistics of the busiest group */
> - unsigned int  busiest_idle_cpus;
> - unsigned long max_load;
> - unsigned long busiest_load_per_task;
> - unsigned long busiest_nr_running;
> - unsigned long busiest_group_capacity;
> - unsigned long busiest_has_capacity;
> - unsigned int  busiest_group_weight;
> -
> - int group_imb; /* Is there imbalance in this sd */
> -};

There are a few parameters that you should not be removing.
busiest_load_per_task and max_load. busiest_load_per_task is a metric
that is not present for sg_lb_stats. And max_load going by its usage in
load balancing is best placed under sd_lb_stats. Removing it could cause
some confusion. See below.
>  /**
> @@ -4732,11 +4715,20 @@ void fix_small_imbalance(struct lb_env *env, struct 
> sd_lb_stats *sds)
>  static inline void calculate_imbalance(struct lb_env *env, struct 
> sd_lb_stats *sds)
>  {
>   unsigned long max_pull, load_above_capacity = ~0UL;
> -
> - sds->busiest_load_per_task /= sds->busiest_nr_running;
> - if (sds->group_imb) {
> - sds->busiest_load_per_task =
> - min(sds->busiest_load_per_task, sds->avg_load);
> + struct sg_lb_stats *this, *busiest;
> +
> + /* After below code, we use sum_weighted_load of
> +  * this_stat and busiest_stat as load_per_task */
> + this = >this_stat;
> + if (this->sum_nr_running)
> + this->sum_weighted_load /= this->sum_nr_running;
> +
> + busiest = >busiest_stat;
> + /* busiest must have some tasks */
> + busiest->sum_weighted_load /= busiest->sum_nr_running;

You cannot change sum_weighted_load of this_grp and busiest_grp like
this. They are meant to carry the total load of the group and not the
load per task in that group. This is why there is a separate metric
busiest_load_per_task and this_load_per_task under sd_lb_stats to convey
exactly what is being done. Doing the above will confuse the readers of
this code.

> + if (busiest->group_imb) {
> + busiest->sum_weighted_load =
> + min(busiest->sum_weighted_load, sds->sd_avg_load);

Right here we get confused as to why the total load is being compared
against load per task (although you are changing it to load per task above).

>   }
> 
>   /*
> @@ -4744,17 +4736,17 @@ static inline void calculate_imbalance(struct lb_env 
> *env, struct sd_lb_stats *s
>* max load less than avg load(as we skip the groups at or below
>* its cpu_power, while calculating max_load..)
>*/
> - if (sds->max_load < sds->avg_load) {
> + if (busiest->avg_load < this->avg_load) {
>   env->imbalance = 0;
>   return fix_small_imbalance(env, sds);
>   }
> 
> - if (!sds->group_imb) {
> + if (!busiest->group_imb) {
>   /*
>* Don't want to pull so many tasks that a group would go idle.
>*/
> - load_above_capacity = (sds->busiest_nr_running -
> - sds->busiest_group_capacity);
> + load_above_capacity = (busiest->sum_nr_running -
> + busiest->group_capacity);
> 
>   load_above_capacity *= (SCHED_LOAD_SCALE * SCHED_POWER_SCALE);
> 
> @@ -4771,12 +4763,13 @@ static inline void calculate_imbalance(struct lb_env 
> *env, struct sd_lb_stats *s
>* Be careful of negative numbers as they'll appear as very large values
>* with unsigned longs.
>*/
> - 

Re: [Update][PATCH] cpufreq: Do not hold driver module references for additional policy CPUs

2013-08-01 Thread Viresh Kumar
Wow!! Lot of stuff happened while I was asleep..

@Srivatsa: Thanks for answering what I would have answered to Rafael :)
And you should really get some sleep, I would suggest :)

On 2 August 2013 02:23, Rafael J. Wysocki  wrote:
> From: Rafael J. Wysocki 
> Subject: cpufreq: Do not hold driver module references for additional policy 
> CPUs

I still have issues with this subject. Why don't we get rid of .owner
field completely? And stop using a mix of cpufreq_cpu_get() and
kobject_get()?

> The cpufreq core is a little inconsistent in the way it uses the
> driver module refcount.
>
> Namely, if __cpufreq_add_dev() is called for a CPU that doesn't
> share the policy object with any other CPUs, the driver module
> refcount it grabs to start with will be dropped by it before
> returning and will be equal to 0 afterward.

It wouldn't be zero but 1, this is what it is initialized with probably.
That's what I can see in my tests.

> However, if the given CPU does share the policy object with other
> CPUs, either cpufreq_add_policy_cpu() is called to link the new CPU
> to the existing policy, or cpufreq_add_dev_symlink() is used to link
> the other CPUs sharing the policy with it to the just created policy
> object.  In that case, because both cpufreq_add_policy_cpu() and
> cpufreq_add_dev_symlink() call cpufreq_cpu_get() for the given
> policy (the latter possibly many times) without the balancing
> cpufreq_cpu_put() (unless there is an error), the driver module
> refcount will be left by __cpufreq_add_dev() with a nonzero value.
>
> To remove that inconsistency make cpufreq_add_policy_cpu() execute
> cpufreq_cpu_put() for the given policy before returning, which
> decrements the driver module refcount so that it will be 0 after
> __cpufreq_add_dev() returns.  Moreover, remove the cpufreq_cpu_get()
> call from cpufreq_add_dev_symlink(), since both the policy refcount
> and the driver module refcount are nonzero when it is called and they
> don't need to be bumped up by it.
>
> Accordingly, drop the cpufreq_cpu_put() from __cpufreq_remove_dev(),
> since it is only necessary to balance the cpufreq_cpu_get() called
> by cpufreq_add_policy_cpu() or cpufreq_add_dev_symlink().
>
> Signed-off-by: Rafael J. Wysocki 
> Reviewed-by: Srivatsa S. Bhat 
> ---
>  drivers/cpufreq/cpufreq.c |   28 +++-
>  1 file changed, 7 insertions(+), 21 deletions(-)

So, we can't rmmod the module as soon as it is inserted and so the
problem stays as is. :(

> Index: linux-pm/drivers/cpufreq/cpufreq.c
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq.c
> +++ linux-pm/drivers/cpufreq/cpufreq.c
> @@ -818,14 +818,11 @@ static int cpufreq_add_dev_symlink(struc
> continue;
>
> pr_debug("Adding link for CPU: %u\n", j);
> -   cpufreq_cpu_get(policy->cpu);
> cpu_dev = get_cpu_device(j);
> ret = sysfs_create_link(_dev->kobj, >kobj,
> "cpufreq");
> -   if (ret) {
> -   cpufreq_cpu_put(policy);
> -   return ret;
> -   }
> +   if (ret)
> +   break;
> }
> return ret;
>  }
> @@ -908,7 +905,8 @@ static int cpufreq_add_policy_cpu(unsign
> unsigned long flags;
>
> policy = cpufreq_cpu_get(sibling);

This can be skipped completely at this place. Caller of
cpufreq_add_policy_cpu() has got the policy pointer with it and so
can be passed. I haven't done it earlier as the impression was we need
to call cpufreq_cpu_get()..

> -   WARN_ON(!policy);
> +   if (WARN_ON_ONCE(!policy))
> +   return -ENODATA;
>
> if (has_target)
> __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
> @@ -930,16 +928,10 @@ static int cpufreq_add_policy_cpu(unsign
> }
>
> /* Don't touch sysfs links during light-weight init */
> -   if (frozen) {
> -   /* Drop the extra refcount that we took above */
> -   cpufreq_cpu_put(policy);
> -   return 0;
> -   }
> -
> -   ret = sysfs_create_link(>kobj, >kobj, "cpufreq");
> -   if (ret)
> -   cpufreq_cpu_put(policy);
> +   if (!frozen)
> +   ret = sysfs_create_link(>kobj, >kobj, "cpufreq");
>
> +   cpufreq_cpu_put(policy);

And so this will go away.
--
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 04/23] hugetlb_cgroup: pass around @hugetlb_cgroup instead of @cgroup

2013-08-01 Thread Aneesh Kumar K.V
Tejun Heo  writes:

> cgroup controller API will be converted to primarily use struct
> cgroup_subsys_state instead of struct cgroup.  In preparation, make
> hugetlb_cgroup functions pass around struct hugetlb_cgroup instead of
> struct cgroup.
>
> This patch shouldn't cause any behavior differences.
>
> Signed-off-by: Tejun Heo 
> Cc: Aneesh Kumar K.V 
> Cc: KAMEZAWA Hiroyuki 
> Cc: Michal Hocko 
> Cc: Johannes Weiner 

Reviewed-by: Aneesh Kumar K.V 


> ---
>  mm/hugetlb_cgroup.c | 22 --
>  1 file changed, 12 insertions(+), 10 deletions(-)
>
> diff --git a/mm/hugetlb_cgroup.c b/mm/hugetlb_cgroup.c
> index 50f213f..d2f9fc0 100644
> --- a/mm/hugetlb_cgroup.c
> +++ b/mm/hugetlb_cgroup.c
> @@ -56,17 +56,19 @@ static inline bool hugetlb_cgroup_is_root(struct 
> hugetlb_cgroup *h_cg)
>   return (h_cg == root_h_cgroup);
>  }
>
> -static inline struct hugetlb_cgroup *parent_hugetlb_cgroup(struct cgroup *cg)
> +static inline struct hugetlb_cgroup *
> +parent_hugetlb_cgroup(struct hugetlb_cgroup *h_cg)
>  {
> - if (!cg->parent)
> + struct cgroup *parent = h_cg->css.cgroup->parent;
> +
> + if (!parent)
>   return NULL;
> - return hugetlb_cgroup_from_cgroup(cg->parent);
> + return hugetlb_cgroup_from_cgroup(parent);
>  }
>
> -static inline bool hugetlb_cgroup_have_usage(struct cgroup *cg)
> +static inline bool hugetlb_cgroup_have_usage(struct hugetlb_cgroup *h_cg)
>  {
>   int idx;
> - struct hugetlb_cgroup *h_cg = hugetlb_cgroup_from_cgroup(cg);
>
>   for (idx = 0; idx < hugetlb_max_hstate; idx++) {
>   if ((res_counter_read_u64(_cg->hugepage[idx], RES_USAGE)) > 0)
> @@ -115,15 +117,14 @@ static void hugetlb_cgroup_css_free(struct cgroup 
> *cgroup)
>   * page reference and test for page active here. This function
>   * cannot fail.
>   */
> -static void hugetlb_cgroup_move_parent(int idx, struct cgroup *cgroup,
> +static void hugetlb_cgroup_move_parent(int idx, struct hugetlb_cgroup *h_cg,
>  struct page *page)
>  {
>   int csize;
>   struct res_counter *counter;
>   struct res_counter *fail_res;
>   struct hugetlb_cgroup *page_hcg;
> - struct hugetlb_cgroup *h_cg   = hugetlb_cgroup_from_cgroup(cgroup);
> - struct hugetlb_cgroup *parent = parent_hugetlb_cgroup(cgroup);
> + struct hugetlb_cgroup *parent = parent_hugetlb_cgroup(h_cg);
>
>   page_hcg = hugetlb_cgroup_from_page(page);
>   /*
> @@ -155,6 +156,7 @@ out:
>   */
>  static void hugetlb_cgroup_css_offline(struct cgroup *cgroup)
>  {
> + struct hugetlb_cgroup *h_cg = hugetlb_cgroup_from_cgroup(cgroup);
>   struct hstate *h;
>   struct page *page;
>   int idx = 0;
> @@ -163,13 +165,13 @@ static void hugetlb_cgroup_css_offline(struct cgroup 
> *cgroup)
>   for_each_hstate(h) {
>   spin_lock(_lock);
>   list_for_each_entry(page, >hugepage_activelist, lru)
> - hugetlb_cgroup_move_parent(idx, cgroup, page);
> + hugetlb_cgroup_move_parent(idx, h_cg, page);
>
>   spin_unlock(_lock);
>   idx++;
>   }
>   cond_resched();
> - } while (hugetlb_cgroup_have_usage(cgroup));
> + } while (hugetlb_cgroup_have_usage(h_cg));
>  }
>
>  int hugetlb_cgroup_charge_cgroup(int idx, unsigned long nr_pages,
> -- 
> 1.8.3.1

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


Re: [PATCH] acpi: video: fix reversed indexed BQC

2013-08-01 Thread Aaron Lu
On 08/02/2013 12:11 PM, Felipe Contreras wrote:
> On Thu, Aug 1, 2013 at 9:03 PM, Aaron Lu  wrote:
>> On 08/02/2013 07:34 AM, Felipe Contreras wrote:
>>> Commit 1a7c618 (ACPI video: support _BQC/_BCL/_BCM methods that use
>>> index values) assumed that bl->levels were not reverted, but at this
>>> point they already are, so there's no need to revert them yet again.
>>
>> When acpi_video_bqc_value_to_level is called, bl->levels is not
>> reverted.
> 
> This is the code that turns br->flags._BCL_reversed on:
> 
>   if (max_level == br->levels[2]) {
>   br->flags._BCL_reversed = 1;
>   sort(>levels[2], count - 2, sizeof(br->levels[2]),
>   acpi_video_cmp_level, NULL);
>   }
> 
> Now tell me how br->flags._BCL_reversed can be on, and the br->levels
> *not* reverted.

Oh yes, it is reverted to be in increase order, so it is not in reverse
order. I'm a little confused by these words.

Please see acpi_video_bqc_quirk, we set _BQC_use_index by revert the
level on a reversed _BCL, so we will need to revert level here too.

-Aaron
--
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: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

2013-08-01 Thread David Gibson
On Wed, Jul 31, 2013 at 05:26:47PM -0400, jonsm...@gmail.com wrote:
> On Wed, Jul 31, 2013 at 4:48 PM, Russell King - ARM Linux
>  wrote:
> > On Wed, Jul 31, 2013 at 04:37:36PM -0400, jonsm...@gmail.com
> wrote:
[snip]
> Alternatively you may be of the belief that it is impossible to get
> rid of the board specific code. But x86 doesn't have any of it, why
> should ARM?

Sure x86 has board specific code.  It's just that x86 basically only
has one board - PC.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


pgpI6NfGqsPfk.pgp
Description: PGP signature


Re: [PATCH v2 2/3] sched: factor out code to should_we_balance()

2013-08-01 Thread Preeti U Murthy
Hi Joonsoo,

On 08/02/2013 07:20 AM, Joonsoo Kim wrote:
> Now checking whether this cpu is appropriate to balance or not
> is embedded into update_sg_lb_stats() and this checking has no direct
> relationship to this function. There is not enough reason to place
> this checking at update_sg_lb_stats(), except saving one iteration
> for sched_group_cpus.
> 
> In this patch, I factor out this checking to should_we_balance() function.
> And before doing actual work for load_balancing, check whether this cpu is
> appropriate to balance via should_we_balance(). If this cpu is not
> a candidate for balancing, it quit the work immediately.
> 
> With this change, we can save two memset cost and can expect better
> compiler optimization.
> 
> Below is result of this patch.
> 
> * Vanilla *
>text  data bss dec hex filename
>   34499  1136 116   357518ba7 kernel/sched/fair.o
> 
> * Patched *
>text  data bss dec hex filename
>   34243  1136 116   354958aa7 kernel/sched/fair.o
> 
> In addition, rename @balance to @should_balance in order to represent
> its purpose more clearly.
> 
> Signed-off-by: Joonsoo Kim 
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index eaae77e..7f51b8c 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4426,22 +4426,17 @@ fix_small_capacity(struct sched_domain *sd, struct 
> sched_group *group)
>   * @group: sched_group whose statistics are to be updated.
>   * @load_idx: Load index of sched_domain of this_cpu for load calc.
>   * @local_group: Does group contain this_cpu.
> - * @balance: Should we balance.
>   * @sgs: variable to hold the statistics for this group.
>   */
>  static inline void update_sg_lb_stats(struct lb_env *env,
>   struct sched_group *group, int load_idx,
> - int local_group, int *balance, struct sg_lb_stats *sgs)
> + int local_group, struct sg_lb_stats *sgs)
>  {
>   unsigned long nr_running, max_nr_running, min_nr_running;
>   unsigned long load, max_cpu_load, min_cpu_load;
> - unsigned int balance_cpu = -1, first_idle_cpu = 0;
>   unsigned long avg_load_per_task = 0;
>   int i;
> 
> - if (local_group)
> - balance_cpu = group_balance_cpu(group);
> -
>   /* Tally up the load of all CPUs in the group */
>   max_cpu_load = 0;
>   min_cpu_load = ~0UL;
> @@ -4454,15 +4449,9 @@ static inline void update_sg_lb_stats(struct lb_env 
> *env,
>   nr_running = rq->nr_running;
> 
>   /* Bias balancing toward cpus of our domain */
> - if (local_group) {
> - if (idle_cpu(i) && !first_idle_cpu &&
> - cpumask_test_cpu(i, 
> sched_group_mask(group))) {
> - first_idle_cpu = 1;
> - balance_cpu = i;
> - }
> -
> + if (local_group)
>   load = target_load(i, load_idx);
> - } else {
> + else {
>   load = source_load(i, load_idx);
>   if (load > max_cpu_load)
>   max_cpu_load = load;
> @@ -4482,22 +4471,9 @@ static inline void update_sg_lb_stats(struct lb_env 
> *env,
>   sgs->idle_cpus++;
>   }
> 
> - /*
> -  * First idle cpu or the first cpu(busiest) in this sched group
> -  * is eligible for doing load balancing at this and above
> -  * domains. In the newly idle case, we will allow all the cpu's
> -  * to do the newly idle load balance.
> -  */
> - if (local_group) {
> - if (env->idle != CPU_NEWLY_IDLE) {
> - if (balance_cpu != env->dst_cpu) {
> - *balance = 0;
> - return;
> - }
> - update_group_power(env->sd, env->dst_cpu);
> - } else if (time_after_eq(jiffies, group->sgp->next_update))
> - update_group_power(env->sd, env->dst_cpu);
> - }

Observe what is happening in the above code which checks if we should
balance on the env->dst_cpu.

Only if the env->dst_cpu "belongs" to the group considered in
update_sg_lb_stats(), which means local_group = 1,should the above
checks be carried out.

Meaning, if there is a better CPU in the same group to which
env->dst_cpu belongs, to carry out load balancing for the system (in the
above case, balance_cpu), cancel the current iteration of load balancing
on env->dst_cpu. Wait for the right cpu in this group to do the load
balancing.

Keeping this in mind see the below comments around should_we_balance().

> @@ -5001,13 +4964,47 @@ static int need_active_balance(struct lb_env *env)
> 
>  static int active_load_balance_cpu_stop(void *data);
> 
> +static int should_we_balance(struct lb_env *env)
> +{
> + struct sched_group *sg = 

Re: [RESEND PATCH 1/2] ARM: msm: Add support for MSM8974

2013-08-01 Thread David Brown

On Thu, Aug 01, 2013 at 08:36:38PM -0700, Rohit Vaswani wrote:

On 8/1/2013 7:29 PM, Stephen Warren wrote:

On 08/01/2013 07:23 PM, Rohit Vaswani wrote:

This patch adds basic board support for MSM8974 which
belongs to the Snapdragon 800 family.
For now, just support a basic machine with device tree.
  arch/arm/boot/dts/msm8974.dts | 26 ++

That's odd. If this is support for an SoC, why not a *.dtsi file rather
than *.dts?


I am not sure why I would need a dtsi if I am just adding the 1 file for
the SoC support ?


The .dts file should be for a specific board, not a general SoC.  Note
the names of the other board .dts files for MSM.  We'll probably want
a msm8974.dtsi at some point, though.

David

--
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 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/3] acpi: video: trivial style cleanups

2013-08-01 Thread Felipe Contreras
On Thu, Aug 1, 2013 at 8:55 PM, Aaron Lu  wrote:
> On 08/02/2013 07:44 AM, Felipe Contreras wrote:
>> Signed-off-by: Felipe Contreras 
>
> Change log please.

You mean a commit message? That's what it's called in Git lingo, and
it's right there:

acpi: video: trivial style cleanups

>> ---
>>  drivers/acpi/video.c | 90 
>> +++-
>>  1 file changed, 40 insertions(+), 50 deletions(-)
>>
>> diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
>> index f021bf4..b07573f 100644
>> --- a/drivers/acpi/video.c
>> +++ b/drivers/acpi/video.c
>> @@ -88,7 +88,7 @@ module_param(allow_duplicates, bool, 0644);
>>  static bool use_bios_initial_backlight = 1;
>>  module_param(use_bios_initial_backlight, bool, 0644);
>>
>> -static int register_count = 0;
>> +static int register_count;
>
> This isn't a style clean up.

It is.

There's no difference before and after, the only difference is the style.

ERROR: do not initialise statics to 0 or NULL
#91: FILE: acpi/video.c:91:
+static int register_count = 0;

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


Re: [PATCH 1/3] acpi: video: trivial costmetic cleanups

2013-08-01 Thread Felipe Contreras
On Thu, Aug 1, 2013 at 8:50 PM, Aaron Lu  wrote:
> On 08/02/2013 07:43 AM, Felipe Contreras wrote:
>> Signed-off-by: Felipe Contreras 
>
> Please add change log explaining what you have changed.
> It seems that the patch modify comment style only, some add a space and
> some change spaces to tab, is it the case?

The commit message already explains what the change is; trivial
cosmetic cleanups. Cosmetic means it's completely superficial.

-- 
Felipe Contreras
--
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] h8300: include: asm: add "vga.h" in Kbuild

2013-08-01 Thread Chen Gang
Need add "vga.h" in Kbuild, or can not pass compiling, the related
error is:

CC  drivers/tty/tty_io.o
  In file included from include/linux/selection.h:11:0,
   from drivers/tty/tty_io.c:103:
  include/linux/vt_buffer.h:18:21: fatal error: asm/vga.h: No such file or 
directory
   #include 
   ^

Signed-off-by: Chen Gang 
---
 arch/h8300/include/asm/Kbuild |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/h8300/include/asm/Kbuild b/arch/h8300/include/asm/Kbuild
index 8ada3cf..f10523e 100644
--- a/arch/h8300/include/asm/Kbuild
+++ b/arch/h8300/include/asm/Kbuild
@@ -5,4 +5,5 @@ generic-y += linkage.h
 generic-y += mmu.h
 generic-y += module.h
 generic-y += trace_clock.h
+generic-y += vga.h
 generic-y += xor.h
-- 
1.7.7.6
--
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 21/23] cgroup: make cftype->[un]register_event() deal with cgroup_subsys_state instead of cgroup

2013-08-01 Thread Li Zefan
> @@ -506,15 +506,17 @@ struct cftype {
>* you want to provide this functionality. Use eventfd_signal()
>* on eventfd to send notification to userspace.
>*/
> - int (*register_event)(struct cgroup *cgrp, struct cftype *cft,
> - struct eventfd_ctx *eventfd, const char *args);
> + int (*register_event)(struct cgroup_subsys_state *css,
> +   struct cftype *cft, struct eventfd_ctx *eventfd,
> +   const char *args);
>   /*
>* unregister_event() callback will be called when userspace
>* closes the eventfd or on cgroup removing.
>* This callback must be implemented, if you want provide
>* notification functionality.
>*/
> - void (*unregister_event)(struct cgroup *cgrp, struct cftype *cft,
> + void (*unregister_event)(struct cgroup_subsys_state *css,
> +  struct cftype *cft,
>   struct eventfd_ctx *eventfd);

align this line?

>  };

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


Re: [PATCH] acpi: video: fix reversed indexed BQC

2013-08-01 Thread Felipe Contreras
On Thu, Aug 1, 2013 at 9:03 PM, Aaron Lu  wrote:
> On 08/02/2013 07:34 AM, Felipe Contreras wrote:
>> Commit 1a7c618 (ACPI video: support _BQC/_BCL/_BCM methods that use
>> index values) assumed that bl->levels were not reverted, but at this
>> point they already are, so there's no need to revert them yet again.
>
> When acpi_video_bqc_value_to_level is called, bl->levels is not
> reverted.

This is the code that turns br->flags._BCL_reversed on:

if (max_level == br->levels[2]) {
br->flags._BCL_reversed = 1;
sort(>levels[2], count - 2, sizeof(br->levels[2]),
acpi_video_cmp_level, NULL);
}

Now tell me how br->flags._BCL_reversed can be on, and the br->levels
*not* reverted.

-- 
Felipe Contreras
--
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] h8300: Makefile: remove the hard code CROSS_COMPILE

2013-08-01 Thread Chen Gang
Current Linux can set CROSS_CMPILE from command line or config file, so
need remove the hard code CROSS_COMPILE from Makefile, or can not work
with cross-compiler with additional prefix (e.g. "h8300-gchen-elf-").


Signed-off-by: Chen Gang 
---
 arch/h8300/Makefile |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/arch/h8300/Makefile b/arch/h8300/Makefile
index a556447..f85 100644
--- a/arch/h8300/Makefile
+++ b/arch/h8300/Makefile
@@ -38,7 +38,6 @@ KBUILD_CFLAGS += -DUTS_SYSNAME=\"uClinux\"
 KBUILD_AFLAGS += -DPLATFORM=$(PLATFORM) -DMODEL=$(MODEL) $(cflags-y)
 LDFLAGS += $(ldflags-y)
 
-CROSS_COMPILE = h8300-elf-
 LIBGCC := $(shell $(CROSS-COMPILE)$(CC) $(KBUILD_CFLAGS) 
-print-libgcc-file-name)
 
 head-y := arch/$(ARCH)/platform/$(PLATFORM)/$(BOARD)/crt0_$(MODEL).o
-- 
1.7.7.6
--
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] fs: Fix file mode for O_TMPFILE

2013-08-01 Thread Andy Lutomirski
O_TMPFILE, like O_CREAT, should respect the requested mode and should
create regular files.

This fixes two bugs: O_TMPFILE required privilege (because the mode
ended up as 000) and it produced bogus inodes with no type.

Signed-off-by: Andy Lutomirski 
---
 fs/open.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/open.c b/fs/open.c
index d53e298..7931f76 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -823,7 +823,7 @@ static inline int build_open_flags(int flags, umode_t mode, 
struct open_flags *o
int lookup_flags = 0;
int acc_mode;
 
-   if (flags & O_CREAT)
+   if (flags & (O_CREAT | __O_TMPFILE))
op->mode = (mode & S_IALLUGO) | S_IFREG;
else
op->mode = 0;
-- 
1.8.3.1

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


[PATCH resend] MAINTAINERS: Add separate section for USB NETWORKING DRIVERS

2013-08-01 Thread Joe Perches
There are several drivers in drivers/net/usb/ that
do not have specific MAINTAINERS that should have
emails forwarded to the linux-usb mailing list.

Add a section for those drivers.

Signed-off-by: Joe Perches 
---
> In the future, you do not need to send drivers/net/usb/ patches to me,
> netdev and the linux-usb mailing lists should be sufficient.

I should have done this in the first patch.
Oh well...

 MAINTAINERS | 5 +
 1 file changed, 5 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index d83f70f..4af7539 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8656,6 +8656,11 @@ T:   git git://git.alsa-project.org/alsa-kernel.git
 S: Maintained
 F: sound/usb/midi.*
 
+USB NETWORKING DRIVERS
+L: linux-...@vger.kernel.org
+S: Odd Fixes
+F: drivers/net/usb/
+
 USB OHCI DRIVER
 M: Alan Stern 
 L: linux-...@vger.kernel.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 08/23] cgroup: pass around cgroup_subsys_state instead of cgroup in subsystem methods

2013-08-01 Thread Li Zefan
> @@ -4199,12 +4208,13 @@ static void init_cgroup_css(struct 
> cgroup_subsys_state *css,
>  /* invoke ->css_online() on a new CSS and mark it online if successful */
>  static int online_css(struct cgroup_subsys *ss, struct cgroup *cgrp)
>  {
> + struct cgroup_subsys_state *css = cgrp->subsys[ss->subsys_id];
>   int ret = 0;
>  
>   lockdep_assert_held(_mutex);
>  
>   if (ss->css_online)
> - ret = ss->css_online(cgrp);
> + ret = ss->css_online(css);
>   if (!ret)
>   cgrp->subsys[ss->subsys_id]->flags |= CSS_ONLINE;

Then this can be changed to css->flags |= CSS_ONLINE.

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


Re: [ipc,shm] BUG: lock held when returning to user space!

2013-08-01 Thread Davidlohr Bueso
On Sat, 2013-07-27 at 21:34 +0800, Fengguang Wu wrote:
> On Sat, Jul 20, 2013 at 09:46:45AM -0700, Davidlohr Bueso wrote:
> > On Sun, 2013-07-21 at 00:02 +0800, Xiaotian Feng wrote:
> > > On Sat, Jul 20, 2013 at 9:13 PM, Fengguang Wu  
> > > wrote:
> > > > Greetings,
> > > >
> > > > I got the below dmesg and the first bad commit is
> > > >
> > > > commit c5d0282a0405b0a81fa3390e4230e4cbb3ced7a2
> > > > Author: Davidlohr Bueso 
> > > > Date:   Fri Jul 19 09:56:58 2013 +1000
> > > >
> > > > ipc,shm: shorten critical region for shmat
> > > >
> > > > Similar to other system calls, acquire the kern_ipc_perm lock after 
> > > > doing
> > > > the initial permission and security checks.
> > > >
> > > > Signed-off-by: Davidlohr Bueso 
> > > > Tested-by: Sedat Dilek 
> > > > Cc: Rik van Riel 
> > > > Cc: Manfred Spraul 
> > > > Signed-off-by: Andrew Morton 
> > > >
> > > > [   20.702156]
> > > > [   20.702493] 
> > > > [   20.703511] [ BUG: lock held when returning to user space! ]
> > > > [   20.704532] 3.11.0-rc1-next-20130719 #50 Not tainted
> > > > [   20.705416] 
> > > > [   20.706425] trinity-child0/174 is leaving the kernel with locks 
> > > > still held!
> > > > [   20.707638] 1 lock held by trinity-child0/174:
> > > > [   20.708475]  #0:  (rcu_read_lock){.+.+..}, at: [] 
> > > > do_shmat+0xe1/0x500
> > > >
> > > 
> > > 
> > > ns = current->nsproxy->ipc_ns;
> > > - shp = shm_lock_check(ns, shmid);
> > > + rcu_read_lock();
> > > + shp = shm_obtain_object_check(ns, shmid);
> > > if (IS_ERR(shp)) {
> > > err = PTR_ERR(shp);
> > > goto out;
> > > 
> > > 
> > > If shm_obtain_object_check() failed, goto out will return with
> > > rcu_read_lock() held.  I think following patch should cure this.
> > 
> > Yep that should solve it, sorry about that. Sasha Levin sent out a fix
> > for it yesterday (offline).
> 
> What's the patch's status? The bug is still there in linux-next 20130726.

Andrew, unless you have an objection (or have already done so), could
you pickup Sasha's fix?

Thanks,
Davidlohr

--
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] scripts/mod/modpost.c: permit '.cranges' secton for sh64 architecture.

2013-08-01 Thread Chen Gang
On 08/02/2013 10:27 AM, Rusty Russell wrote:
> Chen Gang  writes:
>> Need permit '.cranges' section for sh64 architecture, or modpost will
>> report warning:
>>
>> LD  init/built-in.o
>>   WARNING: init/built-in.o (.cranges): unexpected non-allocatable section.
>>   Did you forget to use "ax"/"aw" in a .S file?
>>   Note that for example  contains
>>   section definitions for use in .S files.
>>
>>
>> Signed-off-by: Chen Gang 
> 
> Applied.
> 

Thank you too.

> Thanks,
> Rusty.
> 
>> ---
>>  scripts/mod/modpost.c |1 +
>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
>> index 6216434..8247979 100644
>> --- a/scripts/mod/modpost.c
>> +++ b/scripts/mod/modpost.c
>> @@ -821,6 +821,7 @@ static const char *section_white_list[] =
>>  {
>>  ".comment*",
>>  ".debug*",
>> +".cranges", /* sh64 */
>>  ".zdebug*", /* Compressed debug sections. */
>>  ".GCC-command-line",/* mn10300 */
>>  ".GCC.command.line",/* record-gcc-switches, non mn10300 */
>> -- 
>> 1.7.7.6
> 
> 


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


Re: [PATCH] MAINTAINERS: Add separate section for USB NETWORKING DRIVERS

2013-08-01 Thread Greg KH
On Thu, Aug 01, 2013 at 08:50:10PM -0700, Joe Perches wrote:
> On Fri, 2013-08-02 at 11:30 +0800, Greg KH wrote:
> > On Thu, Aug 01, 2013 at 01:09:55AM -0700, Joe Perches wrote:
> > > Lots of "maintainers" don't apply patches.
> > I have no idea what you are meaning here.
> 
> Just that maintainers aren't necessarily appliers.
> In fact, most aren't.
> 
> > Add netdev to the L: list as well.
> 
> I don't think it's necessary.
> get_maintainers already shows that via the
> NETWORKING DRIVERS section F: drivers/net/

Ah, I thought this entry would have overridden it, sorry about that.

Can you resend this so that I can apply it?

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: WARNING: CPU: 26 PID: 93793 at fs/ext4/inode.c:230 ext4_evict_inode+0x4c9/0x500 [ext4]() still in 3.11-rc3

2013-08-01 Thread Davidlohr Bueso
On Thu, 2013-08-01 at 22:33 +0200, Jan Kara wrote:
>   Hi,
> 
> On Thu 01-08-13 13:14:19, Davidlohr Bueso wrote:
> > FYI I'm seeing loads of the following messages with Linus' latest
> > 3.11-rc3 (which includes 822dbba33458cd6ad)
>   Thanks for notice. I see you are running reaim to trigger this. What
> workload?

After re-running the workloads one by one, I finally hit the issue again
with 'dbase'. FWIW I'm using ramdisks + ext4.

Thanks,
Davidlohr

> 
>   Honza
> 
> > [ cut here ]
> > WARNING: CPU: 26 PID: 93793 at fs/ext4/inode.c:230 
> > ext4_evict_inode+0x4c9/0x500 [ext4]()
> > Modules linked in: autofs4 cpufreq_ondemand freq_table sunrpc 8021q garp 
> > stp llc pcc_cpufreq ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 
> > iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 
> > xt_state nf_conntrack ip6table_filter ip6_tables ipv6 dm_mirror 
> > dm_region_hash dm_log dm_mod uinput iTCO_wdt iTCO_vendor_support coretemp 
> > kvm_intel kvm crc32c_intel ghash_clmulni_intel microcode pcspkr sg lpc_ich 
> > mfd_core hpilo hpwdt i7core_edac edac_core netxen_nic mperf ext4 jbd2 
> > mbcache sd_mod crc_t10dif aesni_intel ablk_helper cryptd lrw gf128mul 
> > glue_helper aes_x86_64 hpsa radeon ttm drm_kms_helper drm i2c_algo_bit 
> > i2c_core [last unloaded: freq_table]
> > CPU: 26 PID: 93793 Comm: reaim Tainted: GW3.11.0-rc3+ #1
> > Hardware name: HP ProLiant DL980 G7, BIOS P66 06/24/2011
> >  00e6 8985db603d78 8153ce4d 00e6
> >   8985db603db8 8104cf1c 8985db603dc8
> >  8b05c485b8b0 8b05c485b9b8 8b05c485b800 ff9c
> > Call Trace:
> >  [] dump_stack+0x49/0x5c
> >  [] warn_slowpath_common+0x8c/0xc0
> >  [] warn_slowpath_null+0x1a/0x20
> >  [] ext4_evict_inode+0x4c9/0x500 [ext4]
> >  [] evict+0xa7/0x1c0
> >  [] iput_final+0xe3/0x170
> >  [] iput+0x3e/0x50
> >  [] do_unlinkat+0x1c6/0x280
> >  [] ? task_work_run+0x94/0xf0
> >  [] ? do_notify_resume+0x84/0x90
> >  [] SyS_unlink+0x16/0x20
> >  [] system_call_fastpath+0x16/0x1b
> > ---[ end trace 15e812809616488b ]---
> > 
> > 


--
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] scripts/mod/modpost.c: permit '.cranges' secton for sh64 architecture.

2013-08-01 Thread Rusty Russell
Chen Gang  writes:
> Need permit '.cranges' section for sh64 architecture, or modpost will
> report warning:
>
> LD  init/built-in.o
>   WARNING: init/built-in.o (.cranges): unexpected non-allocatable section.
>   Did you forget to use "ax"/"aw" in a .S file?
>   Note that for example  contains
>   section definitions for use in .S files.
>
>
> Signed-off-by: Chen Gang 

Applied.

Thanks,
Rusty.

> ---
>  scripts/mod/modpost.c |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> index 6216434..8247979 100644
> --- a/scripts/mod/modpost.c
> +++ b/scripts/mod/modpost.c
> @@ -821,6 +821,7 @@ static const char *section_white_list[] =
>  {
>   ".comment*",
>   ".debug*",
> + ".cranges", /* sh64 */
>   ".zdebug*", /* Compressed debug sections. */
>   ".GCC-command-line",/* mn10300 */
>   ".GCC.command.line",/* record-gcc-switches, non mn10300 */
> -- 
> 1.7.7.6
--
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 08/23] cgroup: pass around cgroup_subsys_state instead of cgroup in subsystem methods

2013-08-01 Thread Li Zefan
> @@ -4298,7 +4308,7 @@ static long cgroup_create(struct cgroup *parent, struct 
> dentry *dentry,
>   for_each_root_subsys(root, ss) {
>   struct cgroup_subsys_state *css;
>  
> - css = ss->css_alloc(cgrp);
> + css = ss->css_alloc(parent->subsys[ss->subsys_id]);

As this patchset is based on for-3.12 branch, which lacks the fix in for-3.11,
so the css_alloc() in that bug fix is not converted.

>   if (IS_ERR(css)) {
>   err = PTR_ERR(css);
>   goto err_free_all;
> @@ -4377,7 +4387,7 @@ err_free_all:
>  
>   if (css) {
>   percpu_ref_cancel_init(>refcnt);
> - ss->css_free(cgrp);
> + ss->css_free(css);
>   }
>   }
>   mutex_unlock(_mutex);

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


[PATCH] perf: sample after exit loses thread correlation - v3

2013-08-01 Thread David Ahern
Occassionally events (e.g., context-switch, sched tracepoints) are losing
the conversion of sample data associated with a thread. For example:

$ perf record -e sched:sched_switch -c 1 -a -- sleep 5
$ perf script

ls 30482 [000] 1379727.583037: sched:sched_switch: prev_comm=ls 
prev_pid=30482 ...
ls 30482 [000] 1379727.586339: sched:sched_switch: prev_comm=ls 
prev_pid=30482 ...
:30482 30482 [000] 1379727.589462: sched:sched_switch: prev_comm=ls 
prev_pid=30482 ...

The last line lost the conversion from tid to comm. If you look at the events
(perf script -D) you see why - SAMPLE event is generated after the EXIT:

0 1379727589449774 0x1540b0 [0x38]: PERF_RECORD_EXIT(30482:30482):(30482:30482)
0 1379727589462497 0x1540e8 [0x80]: PERF_RECORD_SAMPLE(IP, 1): 30482/30482: 
0x816416f1 period: 1 addr: 0
... thread: :30482:30482

When perf processes the EXIT event the thread is moved to the dead_threads
list. When the SAMPLE event is processed no thread exists for the pid so a new
one is created by machine__findnew_thread.

This patch address the problem by delaying the move to the dead_threads list
until the tid is re-used (per Adrian's suggestion).

With this patch we get the previous example shows:

  ls 30482 [000] 1379727.583037: sched:sched_switch: prev_comm=ls 
prev_pid=30482 ...
  ls 30482 [000] 1379727.586339: sched:sched_switch: prev_comm=ls 
prev_pid=30482 ...
  ls 30482 [000] 1379727.589462: sched:sched_switch: prev_comm=ls 
prev_pid=30482 ...

and

  0 1379727589449774 0x1540b0 [0x38]: 
PERF_RECORD_EXIT(30482:30482):(30482:30482)
  0 1379727589462497 0x1540e8 [0x80]: PERF_RECORD_SAMPLE(IP, 1): 30482/30482: 
0x816416f1 period: 1 addr: 0
  ... thread: ls:30482

v3: re-do from a time based check to a delayed move to dead_threads list

v2: Rebased to latest perf/core branch. Changed time comparison to use
a macro which explicitly shows the time basis

Signed-off-by: David Ahern 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Mike Galbraith 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: Adrian Hunter 
---
 tools/perf/util/machine.c |   37 +++--
 1 file changed, 19 insertions(+), 18 deletions(-)

diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index f9f9d63..0d29b1b 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -994,11 +994,27 @@ out_problem:
return 0;
 }
 
+static void machine__remove_thread(struct machine *machine, struct thread *th)
+{
+   machine->last_match = NULL;
+   rb_erase(>rb_node, >threads);
+   /*
+* We may have references to this thread, for instance in some 
hist_entry
+* instances, so just move them to a separate list.
+*/
+   list_add_tail(>node, >dead_threads);
+}
+
 int machine__process_fork_event(struct machine *machine, union perf_event 
*event)
 {
-   struct thread *thread = machine__findnew_thread(machine, 
event->fork.tid);
+   struct thread *thread = machine__find_thread(machine, event->fork.tid);
struct thread *parent = machine__findnew_thread(machine, 
event->fork.ptid);
 
+   /* if a thread currently exists for the thread id remove it */
+   if (thread != NULL)
+   machine__remove_thread(machine, thread);
+
+   thread = machine__findnew_thread(machine, event->fork.tid);
if (dump_trace)
perf_event__fprintf_task(event, stdout);
 
@@ -1011,27 +1027,12 @@ int machine__process_fork_event(struct machine 
*machine, union perf_event *event
return 0;
 }
 
-static void machine__remove_thread(struct machine *machine, struct thread *th)
-{
-   machine->last_match = NULL;
-   rb_erase(>rb_node, >threads);
-   /*
-* We may have references to this thread, for instance in some 
hist_entry
-* instances, so just move them to a separate list.
-*/
-   list_add_tail(>node, >dead_threads);
-}
-
-int machine__process_exit_event(struct machine *machine, union perf_event 
*event)
+int machine__process_exit_event(struct machine *machine __maybe_unused,
+   union perf_event *event)
 {
-   struct thread *thread = machine__find_thread(machine, event->fork.tid);
-
if (dump_trace)
perf_event__fprintf_task(event, stdout);
 
-   if (thread != NULL)
-   machine__remove_thread(machine, thread);
-
return 0;
 }
 
-- 
1.7.10.1

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


Re: [PATCH] MAINTAINERS: Add separate section for USB NETWORKING DRIVERS

2013-08-01 Thread Joe Perches
On Fri, 2013-08-02 at 11:30 +0800, Greg KH wrote:
> On Thu, Aug 01, 2013 at 01:09:55AM -0700, Joe Perches wrote:
> > Lots of "maintainers" don't apply patches.
> I have no idea what you are meaning here.

Just that maintainers aren't necessarily appliers.
In fact, most aren't.

> Add netdev to the L: list as well.

I don't think it's necessary.
get_maintainers already shows that via the
NETWORKING DRIVERS section F: drivers/net/

Maybe adding
W:  http://www.linux-usb.org/usbnet
might be useful, but it seems pretty out of date.

btw: This is a similar section to what I suggested.
 No named "maintainer"

NETWORKING DRIVERS
L:  net...@vger.kernel.org
W:  http://www.linuxfoundation.org/en/Net
Q:  http://patchwork.ozlabs.org/project/netdev/list/
T:  git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
T:  git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
S:  Odd Fixes
F:  drivers/net/


--
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/3] xfs: Implement FALLOC_FL_COLLAPSE_RANGE

2013-08-01 Thread Dave Chinner
On Thu, Aug 01, 2013 at 02:33:09PM +0900, Namjae Jeon wrote:
> 2013/8/1, Dave Chinner :
> > On Wed, Jul 31, 2013 at 11:42:14PM +0900, Namjae Jeon wrote:
> >> From: Namjae Jeon 
> >>
> >> New fallocate flag FALLOC_FL_COLLAPSE_RANGE implementation for XFS.
> >
> Hi Dave.
> > A good start, but there's lots of work needed to make this safe for
> > general use.
> First, Thanks for your advice and help.
> 
> >
> >> Signed-off-by: Namjae Jeon 
> >> Signed-off-by: Ashish Sangwan 
> >> ---
> >>  fs/xfs/xfs_bmap.c |   92
> >> +
> >>  fs/xfs/xfs_bmap.h |3 ++
> >>  fs/xfs/xfs_file.c |   26 --
> >>  fs/xfs/xfs_iops.c |   35 +++
> >>  fs/xfs/xfs_vnodeops.c |   62 +
> >>  fs/xfs/xfs_vnodeops.h |2 ++
> >>  6 files changed, 217 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/fs/xfs/xfs_bmap.c b/fs/xfs/xfs_bmap.c
> >> index 05c698c..ae677b1 100644
> >> --- a/fs/xfs/xfs_bmap.c
> >> +++ b/fs/xfs/xfs_bmap.c
> >> @@ -6145,3 +6145,95 @@ next_block:
> >>
> >>return error;
> >>  }
> >> +
> >> +/*
> >> + * xfs_update_logical()
> >> + *Updates starting logical block of extents by subtracting
> >> + *shift from them. At max XFS_LINEAR_EXTS number extents
> >> + *will be updated and *current_ext is the extent number which
> >> + *is currently being updated.
> >
> > Single space after the "*" in the comments. Also, format them out to
> > 80 columns.
> >
> Single space after * followed by a tab gives checkpath warning:
> WARNING: please, no space before tabs
> #29: FILE: fs/xfs/xfs_bmap.c:6151:
> + * ^IUpdates starting logical block of extents by subtracting$

Get rid of the tabs altogether. The comment doesn't nee dthe
function name in it, and it doesn't need indenting. i.e.:

/*
 * Update the starting logical block of extents by subtracting shift from them.
 * At max XFS_LINEAR_EXTS number extents will be updated and *current_ext is
 * the extent number which is currently being updated.
 */


> > struct xfs_mount*mp = ip->i_mount;
> >
> >> +
> >> +  if (!(ifp->if_flags & XFS_IFEXTENTS) &&
> >> +  (error = xfs_iread_extents(tp, ip, XFS_DATA_FORK)))
> >> +  return error;
> >
> > H - that rings alarm bells.
> ok, we will remove the alarm.

The reason it rings alarm bells is that this indicates that we have
an extent manipulation function being done without any of the usual
checks that the inode is in a format that we can do this
operation, or that it is correctly locked, or that the filesyste is
not shut down, etc. Have a look at all the other functions that call
xfs_iread_extents() in xfs_bmap.c


> >> +
> >> +  if (!*current_ext) {
> >> +  gotp = xfs_iext_bno_to_ext(ifp, start_fsb, current_ext);
> >> +  /*
> >> +   * gotp can be null in 2 cases: 1) if there are no extents
> >> +   * or 2) start_fsb lies in a hole beyond which there are
> >> +   * no extents. Either way, we are done.
> >> +   */
> >> +  if (!gotp) {
> >> +  *done = 1;
> >> +  return 0;
> >> +  }
> >> +  }
> >
> > So, you do a lookup on an extent index, which returns a incore
> > extent record.
> >
> >> +
> >> +  if (ifp->if_flags & XFS_IFBROOT)
> >> +  cur = xfs_bmbt_init_cursor(mp, tp, ip, XFS_DATA_FORK);
> >> +  else
> >> +  cur = NULL;
> >> +
> >> +  while (nexts++ < XFS_LINEAR_EXTS &&
> >
> > What has XFS_LINEAR_EXTS got to do with how many extents can be moved
> > in a single transaction at a time?
> We are also not sure how many extents to move in 1 transaction.
> xfs_bunmapi deletes 3 extents in 1 iteration.

No, it removes as many as the caller asks it to. The caller defines
that number because the caller is the one that reserved the
transaction space for the removal.

> But deletion and updation are 2 different tasks.

Yes, they are.

> BTW, we tested this patch with 10,000 extents and it is working fine.
> Could you help us out here? What number would be appropriate?

How many btree modifications can a record update do? Can it cause a
btree split? If it can cause a btree split, then we nee dto do
allocation and reserve enough blocks in the transaction reservation
for the split.

So, if we can split the bmbt, then allocation can cause the free
space btrees to split as well, so we need to reserve blocks for
those tree splits, too.

And if each record update can potentially cause a bmbt split and
multiple free space btree splits, then how many records should we
update in a single transaction? IOWs, it's no different to hole
punching, truncation, *allocation*, etc.

You used the write transaction reservation, which is defined as:

/*
 * In a write transaction we can allocate a maximum of 2
 * extents.  This gives:
 *the inode getting the new extents: inode size
 *the inode's bmap btree: max depth * block size
 *the agfs of the ags from 

Re: [PATCH] i2c: Fix Kontron PLD prescaler calculation

2013-08-01 Thread Guenter Roeck
On Fri, Jul 26, 2013 at 02:04:55PM +0200, Michael Brunner wrote:
> Add some necessary braces that have been removed during driver cleanup.
> This fixes the I2C prescaler calculation.
> 
> Signed-off-by: Michael Brunner 

Tested-by: Guenter Roeck 
Reviewed-by: Guenter Roeck 

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


Re: [PATCH] tty: Only hangup once

2013-08-01 Thread Greg Kroah-Hartman
On Wed, Jul 31, 2013 at 02:05:45PM -0400, Peter Hurley wrote:
> Instrumented testing shows a tty can be hungup multiple times [1].
> Although concurrent hangups are properly serialized, multiple
> hangups for the same tty should be prevented.
> 
> If tty has already been HUPPED, abort hangup. Note it is not
> necessary to cleanup file *redirect on subsequent hangups,
> as only TIOCCONS can set that value and ioctls are disabled
> after hangup.
> 
> Signed-off-by: Peter Hurley 
> 
> [1]
> Test performed by simulating a concurrent async hangup via
> tty_hangup() with a sync hangup via tty_vhangup(), while
> __tty_hangup() was instrumented with:
> 
> diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
> index 26bb78c..fe8b061 100644
> --- a/drivers/tty/tty_io.c
> +++ b/drivers/tty/tty_io.c
> @@ -629,6 +629,8 @@ static void __tty_hangup(struct tty_struct *tty, int 
> exit_session)
> 
>   tty_lock(tty);
> 
> + WARN_ON(test_bit(TTY_HUPPED, >flags));
> +
>   /* some functions below drop BTM, so we need this bit */
>   set_bit(TTY_HUPPING, >flags);
> 
> Test result:
> 
> WARNING: at /home/peter/src/kernels/mainline/drivers/tty/tty_io.c:632 
> __tty_hangup+0x459/0x460()
> Modules linked in: ip6table_filter ip6_tables ebtable_nat <...snip...>
> CPU: 6 PID: 1197 Comm: kworker/6:2 Not tainted 3.10.0-0+rfcomm-xeon #0+rfcomm
> Hardware name: Dell Inc. Precision WorkStation T5400  /0RW203, BIOS A11 
> 04/30/2012
> Workqueue: events do_tty_hangup
>  0009 8802b16d7d18 816b553e 8802b16d7d58
>  810407e0 880254f95c00 880254f95c00 8802bfd92b00
>  8802bfd96b00 880254f95e40 0180 8802b16d7d68
> Call Trace:
>  [] dump_stack+0x19/0x1b
>  [] warn_slowpath_common+0x70/0xa0
>  [] warn_slowpath_null+0x1a/0x20
>  [] __tty_hangup+0x459/0x460
>  [] ? finish_task_switch+0xbc/0xe0
>  [] do_tty_hangup+0x17/0x20
>  [] process_one_work+0x16f/0x450
>  [] process_scheduled_works+0x2c/0x40
>  [] worker_thread+0x26a/0x380
>  [] ? rescuer_thread+0x310/0x310
>  [] kthread+0xc0/0xd0
>  [] ? destroy_compound_page+0x65/0x92
>  [] ? kthread_create_on_node+0x130/0x130
>  [] ret_from_fork+0x7c/0xb0
>  [] ? kthread_create_on_node+0x130/0x130
> ---[ end trace 98d9f01536cf411e ]---
> ---
>  drivers/tty/tty_io.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
> index 26bb78c..a9355ce 100644
> --- a/drivers/tty/tty_io.c
> +++ b/drivers/tty/tty_io.c
> @@ -629,6 +629,11 @@ static void __tty_hangup(struct tty_struct *tty, int 
> exit_session)
>  
>   tty_lock(tty);
>  
> + if (test_bit(TTY_HUPPED, >flags)) {
> + tty_unlock(tty);
> + return;
> + }
> +
>   /* some functions below drop BTM, so we need this bit */
>   set_bit(TTY_HUPPING, >flags);

A diff inside the changelog entry of a diff is going to cause havoc :)

I'll go edit this to make it not complain...

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: [RESEND PATCH 1/2] ARM: msm: Add support for MSM8974

2013-08-01 Thread Rohit Vaswani

On 8/1/2013 7:29 PM, Stephen Warren wrote:

On 08/01/2013 07:23 PM, Rohit Vaswani wrote:

This patch adds basic board support for MSM8974 which
belongs to the Snapdragon 800 family.
For now, just support a basic machine with device tree.
  arch/arm/boot/dts/msm8974.dts | 26 ++

That's odd. If this is support for an SoC, why not a *.dtsi file rather
than *.dts?


I am not sure why I would need a dtsi if I am just adding the 1 file for 
the SoC support ?


Thanks,
Rohit Vaswani

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

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


Re: [PATCH] MAINTAINERS: Add separate section for USB NETWORKING DRIVERS

2013-08-01 Thread Greg KH
On Thu, Aug 01, 2013 at 01:09:55AM -0700, Joe Perches wrote:
> On Thu, 2013-08-01 at 15:56 +0800, Greg KH wrote:
> > On Thu, Aug 01, 2013 at 12:48:48AM -0700, Joe Perches wrote:
> > > There are several drivers in drivers/net/usb/ that
> > > do not have specific MAINTAINERS that should have
> > > emails forwarded to the linux-usb mailing list.
> 
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> []
> > > +USB NETWORKING DRIVERS
> > > +L:   linux-...@vger.kernel.org
> > > +S:   Odd Fixes
> > > +F:   drivers/net/usb/
> > 
> > But netdev is the one that applies these patches, not linux-usb, so this
> > isn't correct either.
> > 
> > sorry,
> 
> Lots of "maintainers" don't apply patches.

I have no idea what you are meaning here.

> This is simply a means to forward patches to
> relevant lists that may have reviewers that care
> about changes to certain files.
> 
> You suggested that linux-usb should get copies
> of these patches.

Yes, they should, for review, but so should netdev.

> These files are not marked as "Maintained", just
> "Odd fixes".  I suppose these could be marked
> "Orphan" instead.
> 
> You have a suggestion otherwise?

Add netdev to the L: list as well.

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 16/23] cgroup: relocate cgroup_advance_iter()

2013-08-01 Thread Li Zefan
On 2013/8/2 5:49, Tejun Heo wrote:
> For some reason, cgroup_advance_iter() is standing lonely all away
> from its iter comrades.  Relocate it.
> 

There're some other functions that are in the same situation. Do you
think it's better to relocate them, or just leave it as it is?

--
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: [PATCHSET cgroup/for-3.12] cgroup: use cgroup_subsys_state as the primary subsystem interface handle

2013-08-01 Thread Li Zefan
On 2013/8/2 5:49, Tejun Heo wrote:
> Hello,
> 
> Currently, struct cgroup * is used as the main interface handle
> between cgroup core and its subsystems, which works but is a bit
> clunky because subsystems usually care much more about css's
> (cgroup_subsys_state) a lot more than cgroups, which is natural as a
> css is the intersection between a cgroup and a subsystem.
> 
> In addition to being a bit clunky, dealing with cgroups directly pose
> a bit of trouble for the planned unified hierarchy support on two
> fronts.  First, most iterations become subsystem dependent as task
> membership is affected by which subtree has the specific subsystem
> enabled and thus require specifying which subsystem the iteration is
> for, which is automatically achieved if the interfaces deal with css's
> instead of cgroups.
> 
> Second, as css's may be created, attached, detached and destroyed
> dynamically multiple times across the lifetime of a given cgroup as
> they're enabled and disabled, which makes cgroup -> css mapping much
> more difficult to synchronize.  Giving out cgroup to subsystems and
> then requiring them to take the extra steps to deal with their css's
> coming and going dynamically is a lot more fragile than cgroup core
> proper handling it internally and giving out the resulting css's to
> subsystems.
> 
> So, this patchset converts all cgroup subsystem APIs to deal with
> css's instead of cgroups.  The patchset is fairly large but most of
> the conversions, while being tedious, aren't complex.  At the end of
> series, subsystems no longer make cgroup -> css mapping themselves and
> cgroup_css() - formerly cgroup_subsys_state() - is made internal to
> cgroup core proper.
> 
> This is a rather large update to the interface and likely to play as a
> barrier when porting commits, which is inconvenient but also provides
> an opportunity to clean up the API where we can as doing so won't
> significantly raise the level of inconvenience.  As such, this
> patchset contains some API cleanups and I'll probably follow up with
> further API updates that I've been meaning to do and, if you have some
> good idea to clean up cgroup internal API, this probably is a good
> time to submit it.
> 
> This patchset contains the following 23 patches.
> 
>  0001-cgroup-s-cgroup_subsys_state-cgroup_css-s-task_subsy.patch
>  0002-cpuset-drop-const-qualifiers-from-struct-cpuset-inst.patch
>  0003-netprio_cgroup-pass-around-css-instead-of-cgroup-and.patch
>  0004-hugetlb_cgroup-pass-around-hugetlb_cgroup-instead-of.patch
>  0005-cgroup-add-subsystem-pointer-to-cgroup_subsys_state.patch
>  0006-cgroup-add-update-accessors-which-obtain-subsys-spec.patch
>  0007-cgroup-add-css_parent.patch
>  0008-cgroup-pass-around-cgroup_subsys_state-instead-of-cg.patch
>  0009-cgroup-add-subsys-backlink-pointer-to-cftype.patch
>  0010-cgroup-pin-cgroup_subsys_state-when-opening-a-cgroup.patch
>  0011-cgroup-add-cgroup-dummy_css.patch
>  0012-cgroup-pass-around-cgroup_subsys_state-instead-of-cg.patch
>  0013-cgroup-convert-cgroup_next_sibling-to-cgroup_next_ch.patch
>  0014-cgroup-always-use-cgroup_next_child-to-walk-the-chil.patch
>  0015-cgroup-make-hierarchy-iterators-deal-with-cgroup_sub.patch
>  0016-cgroup-relocate-cgroup_advance_iter.patch
>  0017-cgroup-rename-cgroup_iter-to-cgroup_task_iter.patch
>  0018-cgroup-make-cgroup_task_iter-remember-the-cgroup-bei.patch
>  0019-cgroup-remove-struct-cgroup_scanner.patch
>  0020-cgroup-make-task-iterators-deal-with-cgroup_subsys_s.patch
>  0021-cgroup-make-cftype-un-register_event-deal-with-cgrou.patch
>  0022-cgroup-make-cgroup_taskset-deal-with-cgroup_subsys_s.patch
>  0023-cgroup-unexport-cgroup_css.patch
> 

Looks good to me!

Acked-by: Li Zefan 

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


Re: [LINUX PATCH RFC v2] trafgen: xilinx: add axi traffic generator driver

2013-08-01 Thread Greg KH
On Sat, Jul 20, 2013 at 08:31:14PM +0530, Srikanth Thokala wrote:
> This is the driver for AXI Traffic Generator IP. The AXI
> Traffic Generator IP is a core that stresses the AXI4
> interconnect and other AXI4 peripherals in the system.
> It generates a wide variety of AXI4 transactions based on
> the core programming.
> 
> Architecture of the core is broadly separated into a master
> and slave block, each of which contains the write block and
> read block. Other support functions are provided by the
> control registers and three internal RAMs - Master RAM,
> Command RAM, Parameter RAM. The initialisation sequence
> includes programming Command RAM with commands, data into
> Master RAM (optional Parameter RAM programming) and then
> enable master logic using control register interface.
> This sequence generates traffic to cores connected in the
> h/w design.
> 
> The driver for this IP is designed to be a module with
> sysfs interface.  All the control registers and internal
> RAMs can be accessed through sysfs interface.

As you are adding sysfs files, you also need to add Documentation/ABI/
entries as well.

One other comment:

> + /*
> +  * Create sysfs file entries for the device
> +  *
> +  * NOTE: We can create sysfs entries by adding attribute groups
> +  * and then populate into device_driver structure. We see issue
> +  * here, as this process doesn't allow to add sysfs entries with
> +  * BIN attributes (SYSFS_KOBJ_BIN_ATTR). Also, this would create
> +  * sysfs entries under driver/ which will be a bit confusing for
> +  * users as bin files and normal files will be populated at diff
> +  * erent places. So to avoid this, we created this function to
> +  * add sysfs entries at a common place.
> +  *
> +  * This issue is being addressed in mainline by
> +  * 'sysfs: add support for binary attributes in groups'. It
> +  * removes this overhead of creating/removing sysfs file entries.
> +  */
> + err = xtg_create_sysfs_dev_files(tg);
> + if (err < 0) {
> + dev_err(tg->dev, "unable to create sysfs entries\n");
> + return err;
> + }

This patch is now in place, so you don't have to create the sysfs binary
files separately, just add them to the same attribute group as your
"normal" sysfs files.

Now the idea of doing all of the api to this device from sysfs is
another story, but as I don't know what these files are really doing
(i.e. no documentation), I'll hold off on that until you fix that up.

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 RFC V11 15/18] kvm : Paravirtual ticketlocks support for linux guests running on KVM hypervisor

2013-08-01 Thread Raghavendra K T

On 08/01/2013 02:34 PM, Raghavendra K T wrote:

On 08/01/2013 01:15 PM, Gleb Natapov wrote:

Shall I consider this as an ack for kvm part?


For everything except 18/18. For that I still want to see numbers. But
18/18 is pretty independent from the reset of the series so it should
not stop the reset from going in.


Yes. agreed.
I am going to evaluate patch 18 separately and come with results for
that. Now we can consider only 1-17 patches.



Gleb,

32 core machine with HT off 32 vcpu guests.
base = 3.11-rc + patch 1 -17 pvspinlock_v11
patched = base + patch 18

+---+---+---++---+
  dbench  (Throughput in MB/sec higher is better)
+---+---+---++---+
  base  stdev   patchedstdev   %improvement
+---+---+---++---+
1x 14584.3800   146.9074   14705.1000   163.1060 0.82773
2x  1713.730032.87501717.320045.5979 0.20948
3x   967.821242.0257 971.885518.8532 0.41994
4x   685.276425.7150 694.5881 8.3907 1.35882
+---+---+---++---+

I saw -0.78% - .84% changes in ebizzy and 1-2% improvement in
hackbench.

--
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] Tools: hv: in kvp_set_ip_info free mac_addr right after usage

2013-08-01 Thread gre...@linuxfoundation.org
On Thu, Aug 01, 2013 at 02:35:36PM +, KY Srinivasan wrote:
> 
> 
> > -Original Message-
> > From: Olaf Hering [mailto:o...@aepfle.de]
> > Sent: Thursday, August 01, 2013 8:58 AM
> > To: KY Srinivasan; gre...@linuxfoundation.org
> > Cc: linux-kernel@vger.kernel.org; Olaf Hering
> > Subject: [PATCH] Tools: hv: in kvp_set_ip_info free mac_addr right after 
> > usage
> > 
> > ... to simplify error path in upcoming changes.
> > 
> > Signed-off-by: Olaf Hering 
> Signed-off-by: K. Y. Srinivasan 

Can you resend this as well?

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] Tools: hv: check return value of system in hv_kvp_daemon

2013-08-01 Thread gre...@linuxfoundation.org
On Thu, Aug 01, 2013 at 02:36:10PM +, KY Srinivasan wrote:
> 
> 
> > -Original Message-
> > From: Olaf Hering [mailto:o...@aepfle.de]
> > Sent: Thursday, August 01, 2013 9:04 AM
> > To: KY Srinivasan; gre...@linuxfoundation.org
> > Cc: linux-kernel@vger.kernel.org; Olaf Hering
> > Subject: [PATCH] Tools: hv: check return value of system in hv_kvp_daemon
> > 
> > hv_kvp_daemon.c: In function 'main':
> > hv_kvp_daemon.c:1441:8: warning: ignoring return value of 'daemon', declared
> > with attribute warn_unused_result [-Wunused-result]
> > 
> > Signed-off-by: Olaf Hering 
> Signed-off-by: K. Y. Srinivasan 

Can you please resend this to me, I don't seem to have a copy of it
anywhere.

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 v2] staging/lustre: lloop depends on BLOCK

2013-08-01 Thread Greg Kroah-Hartman
On Fri, Aug 02, 2013 at 10:20:28AM +0800, Xiong Zhou wrote:
> 
> 
> On Wed, 31 Jul 2013, Greg Kroah-Hartman wrote:
> 
> > On Wed, Jul 31, 2013 at 10:30:41AM +0800, Xiong Zhou wrote:
> > > From: Xiong Zhou 
> > > 
> > > First version of this patch makes LUSTRE_FS depends on BLOCK.  Second
> > > version makes only lloop depends on BLOCK with a config option for this
> > > dependence, and remove unnecessary jdb header files which depends on
> > > BLOCK.
> > > 
> > > This version removes the wrapper ll_unregister_blkdev which depends on
> > > BLOCK in header and just call unregister_blkdev in lloop.c based on Peng
> > > Tao's comment.
> > 
> > This isn't all needed in the patch changelog info, just say what it
> > does.
> > 
> > Also, it doesn't apply for some reason, care to refresh this against my
> > latest tree and resend?
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> OK, this patch is based on the staging-next branch of your staging tree.
> 
> 
> From: Xiong Zhou 
> 
> Add a config option for llite/lloop in lustre driver, making it 
> depends on BLOCK to fix this better:
> drivers/staging/lustre/lustre/fid/../include/linux/lustre_compat25.h:117:2: 
> error: implicit declaration of function ‘unregister_blkdev’ 
> 
> Also, remove the wrapper ll_unregister_blkdev which depends on BLOCK in
> the header and just call unregister_blkdev in lloop.c based on Peng Tao's
> comment. Drop the redundant dependency on STAGING for LUSTRE_FS, remove 
> some unnecessary jdb header files which depends on BLOCK btw.
> 
> Signed-off-by: Xiong Zhou 
> Reviewed-by: Peng Tao 

Please resend this so I don't have to edit the body of the email, and
the Subject: line as well.

Also, you have a bunch of trailing whitespace in your changelog
comments, are you sure you want/need that?

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] scsi disk: Use its own buffer for the vpd request

2013-08-01 Thread Martin K. Petersen
> "Bernd" == Bernd Schubert  writes:

Bernd,

Bernd> Once I noticed that scsi_get_vpd_page() works fine from other
Bernd> function calls and that it is not 0x89, but already 0x0 that
Bernd> fails fixing it became easy.

Bernd> Nix, any chance you could verify it also works for you?

Do we get an appropriate error back when we try to issue WRITE SAME
10/16? If so, I'm OK with this fix.

And thanks for looking into this!

-- 
Martin K. Petersen  Oracle Linux Engineering
--
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/


[for-next-3.11][PATCH 4/5] tracing/kprobes: Fail to unregister if probe event files are in use

2013-08-01 Thread Steven Rostedt
From: "Steven Rostedt (Red Hat)" 

When a probe is being removed, it cleans up the event files that correspond
to the probe. But there is a race between writing to one of these files
and deleting the probe. This is especially true for the "enable" file.

CPU 0   CPU 1
-   -

  fd = open("enable",O_WRONLY);

  probes_open()
  release_all_trace_probes()
  unregister_trace_probe()
  if (trace_probe_is_enabled(tp))
return -EBUSY

   write(fd, "1", 1)
   __ftrace_set_clr_event()
   call->class->reg()
(kprobe_register)
 enable_trace_probe(tp)

  __unregister_trace_probe(tp);
  list_del(>list)
  unregister_probe_event(tp) <-- fails!
  free_trace_probe(tp)

   write(fd, "0", 1)
   __ftrace_set_clr_event()
   call->class->unreg
(kprobe_register)
disable_trace_probe(tp) <-- BOOM!

A test program was written that used two threads to simulate the
above scenario adding a nanosleep() interval to change the timings
and after several thousand runs, it was able to trigger this bug
and crash:

BUG: unable to handle kernel paging request at 000500f9
IP: [] probes_open+0x3b/0xa7
PGD 7808a067 PUD 0
Oops:  [#1] PREEMPT SMP
Dumping ftrace buffer:
-
Modules linked in: ipt_MASQUERADE sunrpc ip6t_REJECT nf_conntrack_ipv6
CPU: 1 PID: 2070 Comm: test-kprobe-rem Not tainted 3.11.0-rc3-test+ #47
Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by 
O.E.M., BIOS SDBLI944.86P 05/08/2007
task: 880077756440 ti: 880076e52000 task.ti: 880076e52000
RIP: 0010:[]  [] probes_open+0x3b/0xa7
RSP: 0018:880076e53c38  EFLAGS: 00010203
RAX: 00050001 RBX: 88007844f440 RCX: 0003
RDX: 0003 RSI: 0003 RDI: 880076e52000
RBP: 880076e53c58 R08: 880076e53bd8 R09: 
R10: 880077756440 R11: 0006 R12: 810dee35
R13: 880079250418 R14:  R15: 88007844f450
FS:  7f87a276f700() GS:88007d48() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2: 000500f9 CR3: 77262000 CR4: 07e0
Stack:
 880076e53c58 81219ea0 88007844f440 810dee35
 880076e53ca8 81130f78 8800772986c0 8800796f93a0
 81d1b5d8 880076e53e04  88007844f440
Call Trace:
 [] ? security_file_open+0x2c/0x30
 [] ? unregister_trace_probe+0x4b/0x4b
 [] do_dentry_open+0x162/0x226
 [] finish_open+0x46/0x54
 [] do_last+0x7f6/0x996
 [] ? inode_permission+0x42/0x44
 [] path_openat+0x232/0x496
 [] do_filp_open+0x3a/0x8a
 [] ? __alloc_fd+0x168/0x17a
 [] do_sys_open+0x70/0x102
 [] ? trace_hardirqs_on_caller+0x160/0x197
 [] SyS_open+0x1e/0x20
 [] system_call_fastpath+0x16/0x1b
Code: e5 41 54 53 48 89 f3 48 83 ec 10 48 23 56 78 48 39 c2 75 6c 31 f6 48 c7
RIP  [] probes_open+0x3b/0xa7
 RSP 
CR2: 000500f9
---[ end trace 35f17d68fc569897 ]---

The unregister_trace_probe() must be done first, and if it fails it must
fail the removal of the kprobe.

Several changes have already been made by Oleg Nesterov and Masami Hiramatsu
to allow moving the unregister_probe_event() before the removal of
the probe and exit the function if it fails. This prevents the tp
structure from being used after it is freed.

Link: http://lkml.kernel.org/r/20130704034038.819592...@goodmis.org

Acked-by: Masami Hiramatsu 
Signed-off-by: Steven Rostedt 
---
 kernel/trace/trace_kprobe.c |   21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 3811487..243f683 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -95,7 +95,7 @@ static __kprobes bool trace_probe_is_on_module(struct 
trace_probe *tp)
 }
 
 static int register_probe_event(struct trace_probe *tp);
-static void unregister_probe_event(struct trace_probe *tp);
+static int unregister_probe_event(struct trace_probe *tp);
 
 static DEFINE_MUTEX(probe_lock);
 static LIST_HEAD(probe_list);
@@ -351,9 +351,12 @@ static int unregister_trace_probe(struct trace_probe *tp)
if (trace_probe_is_enabled(tp))
return -EBUSY;
 
+   /* Will fail if probe is being used by ftrace or perf */
+   if (unregister_probe_event(tp))
+   return -EBUSY;
+
__unregister_trace_probe(tp);
list_del(>list);
-   unregister_probe_event(tp);
 
return 0;
 }
@@ -632,7 +635,9 @@ static int release_all_trace_probes(void)
/* TODO: Use batch 

[for-next-3.11][PATCH 2/5] tracing: trace_remove_event_call() should fail if call/file is in use

2013-08-01 Thread Steven Rostedt
From: Oleg Nesterov 

Change trace_remove_event_call(call) to return the error if this
call is active. This is what the callers assume but can't verify
outside of the tracing locks. Both trace_kprobe.c/trace_uprobe.c
need the additional changes, unregister_trace_probe() should abort
if trace_remove_event_call() fails.

The caller is going to free this call/file so we must ensure that
nobody can use them after trace_remove_event_call() succeeds.
debugfs should be fine after the previous changes and event_remove()
does TRACE_REG_UNREGISTER, but still there are 2 reasons why we need
the additional checks:

- There could be a perf_event(s) attached to this tp_event, so the
  patch checks ->perf_refcount.

- TRACE_REG_UNREGISTER can be suppressed by FTRACE_EVENT_FL_SOFT_MODE,
  so we simply check FTRACE_EVENT_FL_ENABLED protected by event_mutex.

Link: http://lkml.kernel.org/r/20130729175033.gb26...@redhat.com

Reviewed-by: Masami Hiramatsu 
Signed-off-by: Oleg Nesterov 
Signed-off-by: Steven Rostedt 
---
 include/linux/ftrace_event.h |2 +-
 kernel/trace/trace_events.c  |   35 +--
 2 files changed, 34 insertions(+), 3 deletions(-)

diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 4372658..f98ab06 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -332,7 +332,7 @@ extern int trace_define_field(struct ftrace_event_call 
*call, const char *type,
  const char *name, int offset, int size,
  int is_signed, int filter_type);
 extern int trace_add_event_call(struct ftrace_event_call *call);
-extern void trace_remove_event_call(struct ftrace_event_call *call);
+extern int trace_remove_event_call(struct ftrace_event_call *call);
 
 #define is_signed_type(type)   (((type)(-1)) < (type)1)
 
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index a67c913..ec04836 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -1713,16 +1713,47 @@ static void __trace_remove_event_call(struct 
ftrace_event_call *call)
destroy_preds(call);
 }
 
+static int probe_remove_event_call(struct ftrace_event_call *call)
+{
+   struct trace_array *tr;
+   struct ftrace_event_file *file;
+
+#ifdef CONFIG_PERF_EVENTS
+   if (call->perf_refcount)
+   return -EBUSY;
+#endif
+   do_for_each_event_file(tr, file) {
+   if (file->event_call != call)
+   continue;
+   /*
+* We can't rely on ftrace_event_enable_disable(enable => 0)
+* we are going to do, FTRACE_EVENT_FL_SOFT_MODE can suppress
+* TRACE_REG_UNREGISTER.
+*/
+   if (file->flags & FTRACE_EVENT_FL_ENABLED)
+   return -EBUSY;
+   break;
+   } while_for_each_event_file();
+
+   __trace_remove_event_call(call);
+
+   return 0;
+}
+
 /* Remove an event_call */
-void trace_remove_event_call(struct ftrace_event_call *call)
+int trace_remove_event_call(struct ftrace_event_call *call)
 {
+   int ret;
+
mutex_lock(_types_lock);
mutex_lock(_mutex);
down_write(_event_sem);
-   __trace_remove_event_call(call);
+   ret = probe_remove_event_call(call);
up_write(_event_sem);
mutex_unlock(_mutex);
mutex_unlock(_types_lock);
+
+   return ret;
 }
 
 #define for_each_event(event, start, end)  \
-- 
1.7.10.4


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


[for-next-3.11][PATCH 1/5] debugfs: debugfs_remove_recursive() must not rely on list_empty(d_subdirs)

2013-08-01 Thread Steven Rostedt
From: Oleg Nesterov 

debugfs_remove_recursive() is wrong,

1. it wrongly assumes that !list_empty(d_subdirs) means that this
   dir should be removed.

   This is not that bad by itself, but:

2. if d_subdirs does not becomes empty after __debugfs_remove()
   it gives up and silently fails, it doesn't even try to remove
   other entries.

   However ->d_subdirs can be non-empty because it still has the
   already deleted !debugfs_positive() entries.

3. simple_release_fs() is called even if __debugfs_remove() fails.

Suppose we have

dir1/
dir2/
file2
file1

and someone opens dir1/dir2/file2.

Now, debugfs_remove_recursive(dir1/dir2) succeeds, and dir1/dir2 goes
away.

But debugfs_remove_recursive(dir1) silently fails and doesn't remove
this directory. Because it tries to delete (the already deleted)
dir1/dir2/file2 again and then fails due to "Avoid infinite loop"
logic.

Test-case:

#!/bin/sh

cd /sys/kernel/debug/tracing
echo 'p:probe/sigprocmask sigprocmask' >> kprobe_events
sleep 1000 < events/probe/sigprocmask/id &
echo -n >| kprobe_events

[ -d events/probe ] && echo "ERR!! failed to rm probe"

And after that it is not possible to create another probe entry.

With this patch debugfs_remove_recursive() skips !debugfs_positive()
files although this is not strictly needed. The most important change
is that it does not try to make ->d_subdirs empty, it simply scans
the whole list(s) recursively and removes as much as possible.

Link: http://lkml.kernel.org/r/20130726151256.gc19...@redhat.com

Acked-by: Greg Kroah-Hartman 
Signed-off-by: Oleg Nesterov 
Signed-off-by: Steven Rostedt 
---
 fs/debugfs/inode.c |   69 +---
 1 file changed, 22 insertions(+), 47 deletions(-)

diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index 4888cb3..c7c83ff 100644
--- a/fs/debugfs/inode.c
+++ b/fs/debugfs/inode.c
@@ -533,8 +533,7 @@ EXPORT_SYMBOL_GPL(debugfs_remove);
  */
 void debugfs_remove_recursive(struct dentry *dentry)
 {
-   struct dentry *child;
-   struct dentry *parent;
+   struct dentry *child, *next, *parent;
 
if (IS_ERR_OR_NULL(dentry))
return;
@@ -544,61 +543,37 @@ void debugfs_remove_recursive(struct dentry *dentry)
return;
 
parent = dentry;
+ down:
mutex_lock(>d_inode->i_mutex);
+   list_for_each_entry_safe(child, next, >d_subdirs, d_u.d_child) {
+   if (!debugfs_positive(child))
+   continue;
 
-   while (1) {
-   /*
-* When all dentries under "parent" has been removed,
-* walk up the tree until we reach our starting point.
-*/
-   if (list_empty(>d_subdirs)) {
-   mutex_unlock(>d_inode->i_mutex);
-   if (parent == dentry)
-   break;
-   parent = parent->d_parent;
-   mutex_lock(>d_inode->i_mutex);
-   }
-   child = list_entry(parent->d_subdirs.next, struct dentry,
-   d_u.d_child);
- next_sibling:
-
-   /*
-* If "child" isn't empty, walk down the tree and
-* remove all its descendants first.
-*/
+   /* perhaps simple_empty(child) makes more sense */
if (!list_empty(>d_subdirs)) {
mutex_unlock(>d_inode->i_mutex);
parent = child;
-   mutex_lock(>d_inode->i_mutex);
-   continue;
+   goto down;
}
-   __debugfs_remove(child, parent);
-   if (parent->d_subdirs.next == >d_u.d_child) {
-   /*
-* Try the next sibling.
-*/
-   if (child->d_u.d_child.next != >d_subdirs) {
-   child = list_entry(child->d_u.d_child.next,
-  struct dentry,
-  d_u.d_child);
-   goto next_sibling;
-   }
-
-   /*
-* Avoid infinite loop if we fail to remove
-* one dentry.
-*/
-   mutex_unlock(>d_inode->i_mutex);
-   break;
-   }
-   simple_release_fs(_mount, _mount_count);
+ up:
+   if (!__debugfs_remove(child, parent))
+   simple_release_fs(_mount, _mount_count);
}
 
-   parent = dentry->d_parent;
+   mutex_unlock(>d_inode->i_mutex);
+   child = parent;
+   parent = parent->d_parent;
mutex_lock(>d_inode->i_mutex);
-   

[for-next-3.11][PATCH 3/5] tracing: Add comment to describe special break case in probe_remove_event_call()

2013-08-01 Thread Steven Rostedt
From: "Steven Rostedt (Red Hat)" 

The "break" used in the do_for_each_event_file() is used as an optimization
as the loop is really a double loop. The loop searches all event files
for each trace_array. There's only one matching event file per trace_array
and after we find the event file for the trace_array, the break is used
to jump to the next trace_array and start the search there.

As this is not a standard way of using "break" in C code, it requires
a comment right before the break to let people know what is going on.

Signed-off-by: Steven Rostedt 
---
 kernel/trace/trace_events.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index ec04836..29a7ebc 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -1732,6 +1732,12 @@ static int probe_remove_event_call(struct 
ftrace_event_call *call)
 */
if (file->flags & FTRACE_EVENT_FL_ENABLED)
return -EBUSY;
+   /*
+* The do_for_each_event_file_safe() is
+* a double loop. After finding the call for this
+* trace_array, we use break to jump to the next
+* trace_array.
+*/
break;
} while_for_each_event_file();
 
-- 
1.7.10.4


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


[for-next-3.11][PATCH 5/5] tracing/uprobes: Fail to unregister if probe event files are in use

2013-08-01 Thread Steven Rostedt
From: "Steven Rostedt (Red Hat)" 

Uprobes suffer the same problem that kprobes have. There's a race between
writing to the "enable" file and removing the probe. The probe checks for
it being in use and if it is not, goes about deleting the probe and the
event that represents it. But the problem with that is, after it checks
if it is in use it can be enabled, and the deletion of the event (access
to the probe) will fail, as it is in use. But the uprobe will still be
deleted. This is a problem as the event can reference the uprobe that
was deleted.

The fix is to remove the event first, and check to make sure the event
removal succeeds. Then it is safe to remove the probe.

When the event exists, either ftrace or perf can enable the probe and
prevent the event from being removed.

Link: http://lkml.kernel.org/r/20130704034038.991525...@goodmis.org

Acked-by: Oleg Nesterov 
Signed-off-by: Steven Rostedt 
---
 kernel/trace/trace_uprobe.c |   51 ---
 1 file changed, 38 insertions(+), 13 deletions(-)

diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index a23d2d7..272261b 100644
--- a/kernel/trace/trace_uprobe.c
+++ b/kernel/trace/trace_uprobe.c
@@ -70,7 +70,7 @@ struct trace_uprobe {
(sizeof(struct probe_arg) * (n)))
 
 static int register_uprobe_event(struct trace_uprobe *tu);
-static void unregister_uprobe_event(struct trace_uprobe *tu);
+static int unregister_uprobe_event(struct trace_uprobe *tu);
 
 static DEFINE_MUTEX(uprobe_lock);
 static LIST_HEAD(uprobe_list);
@@ -164,11 +164,17 @@ static struct trace_uprobe *find_probe_event(const char 
*event, const char *grou
 }
 
 /* Unregister a trace_uprobe and probe_event: call with locking uprobe_lock */
-static void unregister_trace_uprobe(struct trace_uprobe *tu)
+static int unregister_trace_uprobe(struct trace_uprobe *tu)
 {
+   int ret;
+
+   ret = unregister_uprobe_event(tu);
+   if (ret)
+   return ret;
+
list_del(>list);
-   unregister_uprobe_event(tu);
free_trace_uprobe(tu);
+   return 0;
 }
 
 /* Register a trace_uprobe and probe_event */
@@ -181,9 +187,12 @@ static int register_trace_uprobe(struct trace_uprobe *tu)
 
/* register as an event */
old_tp = find_probe_event(tu->call.name, tu->call.class->system);
-   if (old_tp)
+   if (old_tp) {
/* delete old event */
-   unregister_trace_uprobe(old_tp);
+   ret = unregister_trace_uprobe(old_tp);
+   if (ret)
+   goto end;
+   }
 
ret = register_uprobe_event(tu);
if (ret) {
@@ -256,6 +265,8 @@ static int create_trace_uprobe(int argc, char **argv)
group = UPROBE_EVENT_SYSTEM;
 
if (is_delete) {
+   int ret;
+
if (!event) {
pr_info("Delete command needs an event name.\n");
return -EINVAL;
@@ -269,9 +280,9 @@ static int create_trace_uprobe(int argc, char **argv)
return -ENOENT;
}
/* delete an event */
-   unregister_trace_uprobe(tu);
+   ret = unregister_trace_uprobe(tu);
mutex_unlock(_lock);
-   return 0;
+   return ret;
}
 
if (argc < 2) {
@@ -408,16 +419,20 @@ fail_address_parse:
return ret;
 }
 
-static void cleanup_all_probes(void)
+static int cleanup_all_probes(void)
 {
struct trace_uprobe *tu;
+   int ret = 0;
 
mutex_lock(_lock);
while (!list_empty(_list)) {
tu = list_entry(uprobe_list.next, struct trace_uprobe, list);
-   unregister_trace_uprobe(tu);
+   ret = unregister_trace_uprobe(tu);
+   if (ret)
+   break;
}
mutex_unlock(_lock);
+   return ret;
 }
 
 /* Probes listing interfaces */
@@ -462,8 +477,13 @@ static const struct seq_operations probes_seq_op = {
 
 static int probes_open(struct inode *inode, struct file *file)
 {
-   if ((file->f_mode & FMODE_WRITE) && (file->f_flags & O_TRUNC))
-   cleanup_all_probes();
+   int ret;
+
+   if ((file->f_mode & FMODE_WRITE) && (file->f_flags & O_TRUNC)) {
+   ret = cleanup_all_probes();
+   if (ret)
+   return ret;
+   }
 
return seq_open(file, _seq_op);
 }
@@ -968,12 +988,17 @@ static int register_uprobe_event(struct trace_uprobe *tu)
return ret;
 }
 
-static void unregister_uprobe_event(struct trace_uprobe *tu)
+static int unregister_uprobe_event(struct trace_uprobe *tu)
 {
+   int ret;
+
/* tu->event is unregistered in trace_remove_event_call() */
-   trace_remove_event_call(>call);
+   ret = trace_remove_event_call(>call);
+   if (ret)
+   return ret;
kfree(tu->call.print_fmt);
tu->call.print_fmt = NULL;
+   return 0;
 }

[for-next-3.11][PATCH 0/5] tracing: Final fixes for the race between open event file and deleting event

2013-08-01 Thread Steven Rostedt
Oleg,

Is all the races that we are aware of between accessing event files and
deleting events covered by these patches?  I think I have them all.
Was there any patches that I missed, as there were a lot of threads
and lots of patches sent out, but not all were considered final.

I think I got the main ones that we decided on, but I'm not 100% sure as
my INBOX is overrun by too many activities. It may be a few months before
I go through them all.

I haven't pushed this to my for-next branch as I'm waiting for some feedback
from others in my queue. But I did push it to my ftrace/urgent branch
if you want to look at what will be going there. That branch may rebase
but I wanted to get these patches tested by Fengguang before sending
them to next. And I try not to rebase my for-next branch.

Thanks,

-- Steve


Oleg Nesterov (2):
  debugfs: debugfs_remove_recursive() must not rely on list_empty(d_subdirs)
  tracing: trace_remove_event_call() should fail if call/file is in use

Steven Rostedt (Red Hat) (3):
  tracing: Add comment to describe special break case in 
probe_remove_event_call()
  tracing/kprobes: Fail to unregister if probe event files are in use
  tracing/uprobes: Fail to unregister if probe event files are in use


 fs/debugfs/inode.c   |   69 ++
 include/linux/ftrace_event.h |2 +-
 kernel/trace/trace_events.c  |   41 +++--
 kernel/trace/trace_kprobe.c  |   21 +
 kernel/trace/trace_uprobe.c  |   51 +++
 5 files changed, 115 insertions(+), 69 deletions(-)
--
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 RFC 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation

2013-08-01 Thread Raghavendra K T

On 08/02/2013 02:39 AM, Waiman Long wrote:

On 08/01/2013 04:23 PM, Raghavendra K T wrote:

On 08/01/2013 08:07 AM, Waiman Long wrote:

[..]


Though I could see some gains in overcommit, but it hurted undercommit
in some workloads :(.


The gcc 4.4.7 compiler that I used in my test machine has the tendency
of allocating stack space for variables instead of using registers when
a loop is present. So I try to avoid having loop in the fast path. Also
the count itself is rather arbitrary. For the first pass, I would like
to make thing simple. We can always enhance it once it is accepted and
merged.


Yes. agree.



I have not yet tested on bigger machine. I hope that bigger machine will
see significant undercommit improvements.



Thank for running the test. I am a bit confused about the terminology.
What exactly do undercommit and overcommit mean?



Undercommit means I meant total #vcpu < #pcpus in virtual env. so
overcommit should not be an issue in baremetal.

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


Re: [PATCH] ACPI: Do not fail acpi_bind_one() if device is already bound correctly

2013-08-01 Thread Lan Tianyu
2013/8/2 Rafael J. Wysocki :
> From: Rafael J. Wysocki 
>
> Modify acpi_bind_one() so that it doesn't fail if the device
> represented by its first argument has already been bound to the
> given ACPI handle (second argument), because that is not a good
> enough reason for returning an error code.
>
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/acpi/glue.c |   15 +++
>  1 file changed, 11 insertions(+), 4 deletions(-)
>
> Index: linux-pm/drivers/acpi/glue.c
> ===
> --- linux-pm.orig/drivers/acpi/glue.c
> +++ linux-pm/drivers/acpi/glue.c
> @@ -143,7 +143,10 @@ int acpi_bind_one(struct device *dev, ac
> list_for_each_entry(pn, _dev->physical_node_list, node)
> if (pn->dev == dev) {
> dev_warn(dev, "Already associated with ACPI node\n");
> -   goto err_free;
> +   if (ACPI_HANDLE(dev) == handle)
> +   retval = 0;
> +
> +   goto out_free;
> }
>
> /* allocate physical node id according to physical_node_id_bitmap */
> @@ -152,7 +155,7 @@ int acpi_bind_one(struct device *dev, ac
> ACPI_MAX_PHYSICAL_NODE);
> if (physical_node->node_id >= ACPI_MAX_PHYSICAL_NODE) {
> retval = -ENOSPC;
> -   goto err_free;
> +   goto out_free;
> }
>
> set_bit(physical_node->node_id, acpi_dev->physical_node_id_bitmap);
> @@ -185,10 +188,14 @@ int acpi_bind_one(struct device *dev, ac
> put_device(dev);
> return retval;
>
> - err_free:
> + out_free:
> mutex_unlock(_dev->physical_node_lock);
> kfree(physical_node);
> -   goto err;
> +   if (retval)
> +   goto err;
> +
> +   put_device(dev);
> +   return 0;
>  }
>  EXPORT_SYMBOL_GPL(acpi_bind_one);

Hi Rafael:
How about the following change?

diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
index f70cc45..35f375e 100644
--- a/drivers/acpi/glue.c
+++ b/drivers/acpi/glue.c
@@ -183,19 +183,15 @@ int acpi_bind_one(struct device *dev, acpi_handle handle)

return 0;

- err:
-   ACPI_HANDLE_SET(dev, NULL);
-   put_device(dev);
-   return retval;
-
  out_free:
mutex_unlock(_dev->physical_node_lock);
kfree(physical_node);
-   if (retval)
-   goto err;

+ err:
+   if (retval)
+   ACPI_HANDLE_SET(dev, NULL);
put_device(dev);
-   return 0;
+   return retval;
 }
 EXPORT_SYMBOL_GPL(acpi_bind_one);
---

When I reviewed this patch, found the dev's acpi handle always
is set  to NULL if there is error. This seems make no sense for
the case that the handle has been set to dev before binding.

For this case, the acpi handle has been found before binding.
Actually, the device driver could control any resources under ACPI
node even if the binding failed. So adding one flag to differentiate
it.

diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
index 35f375e..c868e51 100644
--- a/drivers/acpi/glue.c
+++ b/drivers/acpi/glue.c
@@ -113,6 +113,7 @@ int acpi_bind_one(struct device *dev, acpi_handle handle)
acpi_status status;
struct acpi_device_physical_node *physical_node, *pn;
char physical_node_name[sizeof(PHYSICAL_NODE_STRING) + 2];
+   bool has_handle = false;
int retval = -EINVAL;

if (ACPI_HANDLE(dev)) {
@@ -121,6 +122,7 @@ int acpi_bind_one(struct device *dev, acpi_handle handle)
return -EINVAL;
} else {
handle = ACPI_HANDLE(dev);
+   has_handle = true;
}
}
if (!handle)
@@ -188,7 +190,7 @@ int acpi_bind_one(struct device *dev, acpi_handle handle)
kfree(physical_node);

  err:
-   if (retval)
+   if (retval && !has_handle)
ACPI_HANDLE_SET(dev, NULL);
put_device(dev);
return retval;



>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



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


Re: PROBLEM: 3.11.0-rc2+ lost of connectivity

2013-08-01 Thread Cong Wang
On Thu, 01 Aug 2013 at 14:34 GMT, Sebastiano Spicuglia 
 wrote:
>
> The machine suddenly stops to be connected to the network.
> Running "ifdown eth0" "ifup eth0" the network starts to work
> again for few minutes and then the failure happens again.
> It is not even possible to ping the machine.
> /var/log/messages does not report anything wrong.
>
> I instrumented the kernel with SystemTap to see what happens when the
> machine is in the failure state.
>
> the function ip_rcv is invoked.
> the function ip_rcv_finish is invoked.
> the function ip_local_deliver is invoked
> the function ip_local_deliver_finish is invoked
> the function tcp_v4_rcv is NOT invoked
>
> When the network works the function tcp_v4_rcv is invoked.
>

Please turn off your firewall and run dropwatch to see where the
packets are dropped.

--
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 RFC 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation

2013-08-01 Thread Raghavendra K T

On 08/02/2013 02:17 AM, Peter Zijlstra wrote:

On Fri, Aug 02, 2013 at 01:53:22AM +0530, Raghavendra K T wrote:

You need to learn to trim your replies.. I already stopped reading that
paravirt thread because of it. Soon I'll introduce you to my /dev/null
mail reader.



will be more careful next time.

--
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/3] xfs: Implement FALLOC_FL_COLLAPSE_RANGE

2013-08-01 Thread Dave Chinner
On Thu, Aug 01, 2013 at 01:24:02AM -0700, Christoph Hellwig wrote:
> Instead of adding more mess to change_file_space it might be a good idea
> to pull my
> 
>   "refactor the preallocation and hole punching code"
> 
> series from December in first.

You mean this one:

http://oss.sgi.com/archives/xfs/2012-12/msg00124.html

Yeah, probably makes sense to do this. I'll have a look at porting
it forwards to my current tree as xfs_vnodeops.c has gone away in
that series...

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/


[PATCH 3/4 v2] rcu: Simplify RCU_STATE_INITIALIZER() macro

2013-08-01 Thread Steven Rostedt
From: "Steven Rostedt (Red Hat)" 

The RCU_STATE_INITIALIZER() macro is used only in the rcutree.c file
as well as the rcutree_plugin.h file. It is passed as a rvalue to
a variable of a similar name. A per_cpu variable is also created
with a similar name as well.

The uses of RCU_STATE_INITIALIZER() can be simplified to remove some
of the duplicate code that is done. Currently the three users of this
macro has this format:

struct rcu_state rcu_sched_state =
RCU_STATE_INITIALIZER(rcu_sched, call_rcu_sched);
DEFINE_PER_CPU(struct rcu_data, rcu_sched_data);

Notice that "rcu_sched" is called three times. This is the same with
the other two users. This can be condensed to just:

RCU_STATE_INITIALIZER(rcu_sched, call_rcu_sched);

by moving the rest into the macro itself.

This also opens the door to allow the RCU tracepoint strings and
their addresses to be exported so that userspace tracing tools can
translate the contents of the pointers of the RCU tracepoints.
The change will allow for helper code to be placed in the
RCU_STATE_INITIALIZER() macro to export the name that is used.

Signed-off-by: Steven Rostedt 
---
 kernel/rcutree.c|   14 ++
 kernel/rcutree_plugin.h |4 +---
 2 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/kernel/rcutree.c b/kernel/rcutree.c
index 3020149..97994a3 100644
--- a/kernel/rcutree.c
+++ b/kernel/rcutree.c
@@ -64,7 +64,8 @@
 static struct lock_class_key rcu_node_class[RCU_NUM_LVLS];
 static struct lock_class_key rcu_fqs_class[RCU_NUM_LVLS];
 
-#define RCU_STATE_INITIALIZER(sname, sabbr, cr) { \
+#define RCU_STATE_INITIALIZER(sname, sabbr, cr) \
+struct rcu_state sname##_state = { \
.level = { ##_state.node[0] }, \
.call = cr, \
.fqs_state = RCU_GP_IDLE, \
@@ -77,14 +78,11 @@ static struct lock_class_key rcu_fqs_class[RCU_NUM_LVLS];
.onoff_mutex = __MUTEX_INITIALIZER(sname##_state.onoff_mutex), \
.name = #sname, \
.abbr = sabbr, \
-}
-
-struct rcu_state rcu_sched_state =
-   RCU_STATE_INITIALIZER(rcu_sched, 's', call_rcu_sched);
-DEFINE_PER_CPU(struct rcu_data, rcu_sched_data);
+}; \
+DEFINE_PER_CPU(struct rcu_data, sname##_data)
 
-struct rcu_state rcu_bh_state = RCU_STATE_INITIALIZER(rcu_bh, 'b', 
call_rcu_bh);
-DEFINE_PER_CPU(struct rcu_data, rcu_bh_data);
+RCU_STATE_INITIALIZER(rcu_sched, 's', call_rcu_sched);
+RCU_STATE_INITIALIZER(rcu_bh, 'b', call_rcu_bh);
 
 static struct rcu_state *rcu_state;
 LIST_HEAD(rcu_struct_flavors);
diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
index 769e12e..6976a7d 100644
--- a/kernel/rcutree_plugin.h
+++ b/kernel/rcutree_plugin.h
@@ -110,9 +110,7 @@ static void __init rcu_bootup_announce_oddness(void)
 
 #ifdef CONFIG_TREE_PREEMPT_RCU
 
-struct rcu_state rcu_preempt_state =
-   RCU_STATE_INITIALIZER(rcu_preempt, 'p', call_rcu);
-DEFINE_PER_CPU(struct rcu_data, rcu_preempt_data);
+RCU_STATE_INITIALIZER(rcu_preempt, 'p', call_rcu);
 static struct rcu_state *rcu_state = _preempt_state;
 
 static int rcu_preempted_readers_exp(struct rcu_node *rnp);
-- 
1.7.10.4


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


Re: [PATCH 8/8] prepare to remove /proc/sys/vm/hugepages_treat_as_movable

2013-08-01 Thread Naoya Horiguchi
On Thu, Aug 01, 2013 at 11:29:39AM +0530, Aneesh Kumar K.V wrote:
> Naoya Horiguchi  writes:
> 
> > On Wed, Jul 31, 2013 at 12:02:30AM +0530, Aneesh Kumar K.V wrote:
> >> Naoya Horiguchi  writes:
> >> 
> >> > Now hugepages are definitely movable. So allocating hugepages from
> >> > ZONE_MOVABLE is natural and we have no reason to keep this parameter.
> >> > In order to allow userspace to prepare for the removal, let's leave
> >> > this sysctl handler as noop for a while.
> >> 
> >> I guess you still need to handle architectures for which pmd_huge is
> >> 
> >> int pmd_huge(pmd_t pmd)
> >> {
> >>return 0;
> >> }
> >> 
> >> embedded powerpc is one. They don't store pte information at the PMD
> >> level. Instead pmd contains a pointer to hugepage directory which
> >> contain huge pte.
> >
> > It seems that this comment is for the whole series, not just for this
> > patch, right?
> >
> > Some users of hugepage migration (mbind, move_pages, migrate_pages)
> > walk over page tables to collect hugepages to be migrated, where
> > hugepages are just ignored in such architectures due to pmd_huge.
> > So no problem for these users.
> >
> > But the other users (softoffline, memory hotremove) choose hugepages
> > to be migrated based on pfn, where they don't check pmd_huge.
> > As you wrote, this can be problematic for such architectures.
> > So I think of adding pmd_huge() check somewhere (in unmap_and_move_huge_page
> > for example) to make it fail for such architectures.
> 
> Considering that we have architectures that won't support migrating
> explicit hugepages with this patch series, is it ok to use
> GFP_HIGHUSER_MOVABLE for hugepage allocation ?

Originally this parameter was introduced to make hugepage pool on ZONE_MOVABLE.
The benefit is that we can extend the hugepage pool more easily,
because external fragmentation less likely happens than other zone type
by rearranging fragmented pages with page migration/reclaim.

So I think using ZONE_MOVABLE for hugepage allocation by default makes sense
even on the architectures which don't support hugepage migration.

Thanks,
Naoya Horiguchi
--
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/4 v2] rcu: Have the RCU tracepoints use the tracepoint_string infrastructure

2013-08-01 Thread Steven Rostedt
From: "Steven Rostedt (Red Hat)" 

Currently, RCU tracepoints save only a pointer to strings in the
ring buffer. When displayed via the /sys/kernel/debug/tracing/trace file
they are referenced like the printf "%s" that looks at the address
in the ring buffer and prints out the string it points too. This requires
that the strings are constant and persistent in the kernel.

The problem with this is for tools like trace-cmd and perf that read the
binary data from the buffers but have no access to the kernel memory to
find out what string is represented by the address in the buffer.

By using the tracepoint_string infrastructure, the RCU tracepoint strings
can be exported such that userspace tools can map the addresses to
the strings.

 # cat /sys/kernel/debug/tracing/printk_formats
0x81a4a0e8 : "rcu_preempt"
0x81a4a0f4 : "rcu_bh"
0x81a4a100 : "rcu_sched"
0x818437a0 : "cpuqs"
0x818437a6 : "rcu_sched"
0x818437a0 : "cpuqs"
0x818437b0 : "rcu_bh"
0x818437b7 : "Start context switch"
0x818437cc : "End context switch"
0x818437a0 : "cpuqs"
[...]

Now userspaces tools can display:

 rcu_utilization:  Start context switch
 rcu_dyntick:  Start 1 0
 rcu_utilization:  End context switch
 rcu_batch_start:  rcu_preempt CBs=0/5 bl=10
 rcu_dyntick:  End 0 140
 rcu_invoke_callback:  rcu_preempt rhp=0x880071c0d600 func=proc_i_callback
 rcu_invoke_callback:  rcu_preempt rhp=0x880077b5b230 func=__d_free
 rcu_dyntick:  Start 140 0
 rcu_invoke_callback:  rcu_preempt rhp=0x880077563980 func=file_free_rcu
 rcu_batch_end:rcu_preempt CBs-invoked=3 idle=>c<>c<>c<>c<
 rcu_utilization:  End RCU core
 rcu_grace_period: rcu_preempt 9741 start
 rcu_dyntick:  Start 1 0
 rcu_dyntick:  End 0 140
 rcu_dyntick:  Start 140 0

Instead of:

 rcu_utilization:  81843110
 rcu_future_grace_period: 81842f1d 9939 9939 9940 0 0 3 81842f32
 rcu_batch_start:  81842f1d CBs=0/4 bl=10
 rcu_future_grace_period: 81842f1d 9939 9939 9940 0 0 3 81842f3c
 rcu_grace_period: 81842f1d 9939 81842f80
 rcu_invoke_callback:  81842f1d rhp=0x88007888aac0 
func=file_free_rcu
 rcu_grace_period: 81842f1d 9939 81842f95
 rcu_invoke_callback:  81842f1d rhp=0x88006aeb4600 
func=proc_i_callback
 rcu_future_grace_period: 81842f1d 9939 9939 9940 0 0 3 81842f32
 rcu_future_grace_period: 81842f1d 9939 9939 9940 0 0 3 81842f3c
 rcu_invoke_callback:  81842f1d rhp=0x880071cb9fc0 func=__d_free
 rcu_grace_period: 81842f1d 9939 81842f80
 rcu_invoke_callback:  81842f1d rhp=0x88007888ae80 
func=file_free_rcu
 rcu_batch_end:81842f1d CBs-invoked=4 idle=>c<>c<>c<>c<
 rcu_utilization:  8184311f

Signed-off-by: Steven Rostedt 
---
 kernel/rcutree.c|   87 +--
 kernel/rcutree_plugin.h |   32 -
 2 files changed, 69 insertions(+), 50 deletions(-)

diff --git a/kernel/rcutree.c b/kernel/rcutree.c
index 97994a3..338f1d1 100644
--- a/kernel/rcutree.c
+++ b/kernel/rcutree.c
@@ -53,18 +53,36 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "rcutree.h"
 #include 
 
 #include "rcu.h"
 
+/*
+ * Strings used in tracepoints need to be exported via the
+ * tracing system such that tools like perf and trace-cmd can
+ * translate the string address pointers to actual text.
+ */
+#define TPS(x) tracepoint_string(x)
+
 /* Data structures. */
 
 static struct lock_class_key rcu_node_class[RCU_NUM_LVLS];
 static struct lock_class_key rcu_fqs_class[RCU_NUM_LVLS];
 
+/*
+ * In order to export the rcu_state name to the tracing tools, it
+ * needs to be added in the __tracepoint_string section.
+ * This requires defining a separate variable tp__varname
+ * that points to the string being used, and this will allow
+ * the tracing userspace tools to be able to decipher the string
+ * address to the matching string.
+ */
 #define RCU_STATE_INITIALIZER(sname, sabbr, cr) \
+static char sname##_varname[] = #sname; \
+static const char *tp_##sname##_varname __used __tracepoint_string = 
sname##_varname; \
 struct rcu_state sname##_state = { \
.level = { ##_state.node[0] }, \
.call = cr, \
@@ -76,7 +94,7 @@ struct rcu_state sname##_state = { \
.orphan_donetail = ##_state.orphan_donelist, \
.barrier_mutex = __MUTEX_INITIALIZER(sname##_state.barrier_mutex), \
.onoff_mutex = __MUTEX_INITIALIZER(sname##_state.onoff_mutex), \
-   .name = #sname, \
+   .name = sname##_varname, \
.abbr = sabbr, \
 }; \
 DEFINE_PER_CPU(struct rcu_data, sname##_data)
@@ -176,7 +194,7 @@ void rcu_sched_qs(int cpu)
struct rcu_data *rdp = _cpu(rcu_sched_data, cpu);
 
if 

[PATCH 2/4 v2] rcu: Add const annotation to char * for RCU tracepoints and functions

2013-08-01 Thread Steven Rostedt
From: "Steven Rostedt (Red Hat)" 

All the RCU tracepoints and functions that reference char pointers do
so with just 'char *' even though they do not modify the contents of
the string itself. This will cause warnings if a const char * is used
in one of these functions.

The RCU tracepoints store the pointer to the string to refer back to them
when the trace output is displayed. As this can be minutes, hours or
even days later, those strings had better be constant.

This change also opens the door to allow the RCU tracepoint strings and
their addresses to be exported so that userspace tracing tools can
translate the contents of the pointers of the RCU tracepoints.

Signed-off-by: Steven Rostedt 
---
 include/linux/rcupdate.h   |4 +--
 include/trace/events/rcu.h |   82 ++--
 kernel/rcu.h   |2 +-
 kernel/rcupdate.c  |2 +-
 kernel/rcutiny.c   |2 +-
 kernel/rcutiny_plugin.h|2 +-
 kernel/rcutorture.c|8 ++---
 kernel/rcutree.c   |4 +--
 kernel/rcutree.h   |2 +-
 9 files changed, 54 insertions(+), 54 deletions(-)

diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 4b14bdc..0c38abb 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -52,7 +52,7 @@ extern int rcutorture_runnable; /* for sysctl */
 #if defined(CONFIG_TREE_RCU) || defined(CONFIG_TREE_PREEMPT_RCU)
 extern void rcutorture_record_test_transition(void);
 extern void rcutorture_record_progress(unsigned long vernum);
-extern void do_trace_rcu_torture_read(char *rcutorturename,
+extern void do_trace_rcu_torture_read(const char *rcutorturename,
  struct rcu_head *rhp,
  unsigned long secs,
  unsigned long c_old,
@@ -65,7 +65,7 @@ static inline void rcutorture_record_progress(unsigned long 
vernum)
 {
 }
 #ifdef CONFIG_RCU_TRACE
-extern void do_trace_rcu_torture_read(char *rcutorturename,
+extern void do_trace_rcu_torture_read(const char *rcutorturename,
  struct rcu_head *rhp,
  unsigned long secs,
  unsigned long c_old,
diff --git a/include/trace/events/rcu.h b/include/trace/events/rcu.h
index 59ebcc8..ee2376c 100644
--- a/include/trace/events/rcu.h
+++ b/include/trace/events/rcu.h
@@ -19,12 +19,12 @@
  */
 TRACE_EVENT(rcu_utilization,
 
-   TP_PROTO(char *s),
+   TP_PROTO(const char *s),
 
TP_ARGS(s),
 
TP_STRUCT__entry(
-   __field(char *, s)
+   __field(const char *, s)
),
 
TP_fast_assign(
@@ -51,14 +51,14 @@ TRACE_EVENT(rcu_utilization,
  */
 TRACE_EVENT(rcu_grace_period,
 
-   TP_PROTO(char *rcuname, unsigned long gpnum, char *gpevent),
+   TP_PROTO(const char *rcuname, unsigned long gpnum, const char *gpevent),
 
TP_ARGS(rcuname, gpnum, gpevent),
 
TP_STRUCT__entry(
-   __field(char *, rcuname)
+   __field(const char *, rcuname)
__field(unsigned long, gpnum)
-   __field(char *, gpevent)
+   __field(const char *, gpevent)
),
 
TP_fast_assign(
@@ -89,21 +89,21 @@ TRACE_EVENT(rcu_grace_period,
  */
 TRACE_EVENT(rcu_future_grace_period,
 
-   TP_PROTO(char *rcuname, unsigned long gpnum, unsigned long completed,
+   TP_PROTO(const char *rcuname, unsigned long gpnum, unsigned long 
completed,
 unsigned long c, u8 level, int grplo, int grphi,
-char *gpevent),
+const char *gpevent),
 
TP_ARGS(rcuname, gpnum, completed, c, level, grplo, grphi, gpevent),
 
TP_STRUCT__entry(
-   __field(char *, rcuname)
+   __field(const char *, rcuname)
__field(unsigned long, gpnum)
__field(unsigned long, completed)
__field(unsigned long, c)
__field(u8, level)
__field(int, grplo)
__field(int, grphi)
-   __field(char *, gpevent)
+   __field(const char *, gpevent)
),
 
TP_fast_assign(
@@ -132,13 +132,13 @@ TRACE_EVENT(rcu_future_grace_period,
  */
 TRACE_EVENT(rcu_grace_period_init,
 
-   TP_PROTO(char *rcuname, unsigned long gpnum, u8 level,
+   TP_PROTO(const char *rcuname, unsigned long gpnum, u8 level,
 int grplo, int grphi, unsigned long qsmask),
 
TP_ARGS(rcuname, gpnum, level, grplo, grphi, qsmask),
 
TP_STRUCT__entry(
-   __field(char *, rcuname)
+   __field(const char *, rcuname)
__field(unsigned long, gpnum)
__field(u8, level)
__field(int, grplo)
@@ -168,12 +168,12 @@ TRACE_EVENT(rcu_grace_period_init,
  */
 TRACE_EVENT(rcu_preempt_task,
 
-   TP_PROTO(char *rcuname, int pid, unsigned 

[PATCH 1/4 v2] tracing: Add __tracepoint_string() to export string pointers

2013-08-01 Thread Steven Rostedt
From: "Steven Rostedt (Red Hat)" 

There are several tracepoints (mostly in RCU), that reference a string
pointer and uses the print format of "%s" to display the string that
exists in the kernel, instead of copying the actual string to the
ring buffer (saves time and ring buffer space).

But this has an issue with userspace tools that read the binary buffers
that has the address of the string but has no access to what the string
itself is. The end result is just output that looks like:

 rcu_dyntick:  818adeaa 1 0
 rcu_dyntick:  818adeb5 0 140
 rcu_dyntick:  818adeb5 0 140
 rcu_utilization:  8184333b
 rcu_utilization:  8184333b

The above is pretty useless when read by the userspace tools. Ideally
we would want something that looks like this:

 rcu_dyntick:  Start 1 0
 rcu_dyntick:  End 0 140
 rcu_dyntick:  Start 140 0
 rcu_callback: rcu_preempt rhp=0x880037aff710 func=put_cred_rcu 0/4
 rcu_callback: rcu_preempt rhp=0x880078961980 func=file_free_rcu 0/5
 rcu_dyntick:  End 0 1

The trace_printk() which also only stores the address of the string
format instead of recording the string into the buffer itself, exports
the mapping of kernel addresses to format strings via the printk_format
file in the debugfs tracing directory.

The tracepoint strings can use this same method and output the format
to the same file and the userspace tools will be able to decipher
the address without any modification.

The tracepoint strings need its own section to save the strings because
the trace_printk section will cause the trace_printk() buffers to be
allocated if anything exists within the section. trace_printk() is only
used for debugging and should never exist in the kernel, we can not use
the trace_printk sections.

Add a new tracepoint_str section that will also be examined by the output
of the printk_format file.

Cc: Paul E. McKenney 
Signed-off-by: Steven Rostedt 
---
 include/asm-generic/vmlinux.lds.h |7 ++-
 include/linux/ftrace_event.h  |   34 ++
 kernel/trace/trace.h  |3 +++
 kernel/trace/trace_printk.c   |   19 +++
 4 files changed, 62 insertions(+), 1 deletion(-)

diff --git a/include/asm-generic/vmlinux.lds.h 
b/include/asm-generic/vmlinux.lds.h
index 69732d2..83e2c31 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -122,8 +122,12 @@
 #define TRACE_PRINTKS() VMLINUX_SYMBOL(__start___trace_bprintk_fmt) = .;  \
 *(__trace_printk_fmt) /* Trace_printk fmt' pointer */ \
 VMLINUX_SYMBOL(__stop___trace_bprintk_fmt) = .;
+#define TRACEPOINT_STR() VMLINUX_SYMBOL(__start___tracepoint_str) = .; \
+*(__tracepoint_str) /* Trace_printk fmt' pointer */ \
+VMLINUX_SYMBOL(__stop___tracepoint_str) = .;
 #else
 #define TRACE_PRINTKS()
+#define TRACEPOINT_STR()
 #endif
 
 #ifdef CONFIG_FTRACE_SYSCALLS
@@ -190,7 +194,8 @@
VMLINUX_SYMBOL(__stop___verbose) = .;   \
LIKELY_PROFILE()\
BRANCH_PROFILE()\
-   TRACE_PRINTKS()
+   TRACE_PRINTKS() \
+   TRACEPOINT_STR()
 
 /*
  * Data section helpers
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 4372658..81af18a 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -357,6 +357,40 @@ do {   
\
__trace_printk(ip, fmt, ##args);\
 } while (0)
 
+/**
+ * tracepoint_string - register constant persistent string to trace system
+ * @str - a constant persistent string that will be referenced in tracepoints
+ *
+ * If constant strings are being used in tracepoints, it is faster and
+ * more efficient to just save the pointer to the string and reference
+ * that with a printf "%s" instead of saving the string in the ring buffer
+ * and wasting space and time.
+ *
+ * The problem with the above approach is that userspace tools that read
+ * the binary output of the trace buffers do not have access to the string.
+ * Instead they just show the address of the string which is not very
+ * useful to users.
+ *
+ * With tracepoint_string(), the string will be registered to the tracing
+ * system and exported to userspace via the debugfs/tracing/printk_formats
+ * file that maps the string address to the string text. This way userspace
+ * tools that read the binary buffers have a way to map the pointers to
+ * the ASCII strings they represent.
+ *
+ * The @str used must be a constant string and persistent as it would not
+ * make sense to show a string 

[PATCH 0/4 v2] [GIT PULL][RCU][3.12] tracing/rcu: Export strings to userspace

2013-08-01 Thread Steven Rostedt
Paul,

As we talked about earlier, I set up a branch based off of v3.11-rc2 which
the first patch has my tracing patch I need for other updates, and
the other three are RCU specific patches that you should take.

You can either just pull this branch from my tree, or you can pull
just the first patch (to keep the same SHA1) and apply the other three
patches any way you want.

I tested all these patches through my standard tests, but I did not run
the RCU ones through any specific RCU tests (like rcutorture). They
shouldn't affect the process of RCU in anyway and only should touch
the way trace points export their strings. You may want to run them through
other tests just to make sure there isn't some strange side effect I
caused. :-)

Note the "-2" on the branch name.

-- Steve

v2 changes:

  Remove const from char * in rcu_nocb_setup(), parse_rcu_nocb_poll(), and
  print_cpu_stall_fast_no_hz(). I got a little to carried away with my
  consts!

Please pull the latest ftrace/rcu-2 tree, which can be found at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
ftrace/rcu-2

Head SHA1: f7f7bac9cb1c50783f15937a11743655a5756a36


Steven Rostedt (Red Hat) (4):
  tracing: Add __tracepoint_string() to export string pointers
  rcu: Add const annotation to char * for RCU tracepoints and functions
  rcu: Simplify RCU_STATE_INITIALIZER() macro
  rcu: Have the RCU tracepoints use the tracepoint_string infrastructure


 include/asm-generic/vmlinux.lds.h |7 ++-
 include/linux/ftrace_event.h  |   34 
 include/linux/rcupdate.h  |4 +-
 include/trace/events/rcu.h|   82 ++---
 kernel/rcu.h  |2 +-
 kernel/rcupdate.c |2 +-
 kernel/rcutiny.c  |2 +-
 kernel/rcutiny_plugin.h   |2 +-
 kernel/rcutorture.c   |8 +--
 kernel/rcutree.c  |  105 +
 kernel/rcutree.h  |2 +-
 kernel/rcutree_plugin.h   |   36 ++---
 kernel/trace/trace.h  |3 ++
 kernel/trace/trace_printk.c   |   19 +++
 14 files changed, 192 insertions(+), 116 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/3] fs: Introduce new flag FALLOC_FL_COLLAPSE_RANGE

2013-08-01 Thread Dave Chinner
On Thu, Aug 01, 2013 at 02:07:39PM +0900, Namjae Jeon wrote:
> 2013/8/1, Dave Chinner :
> > On Wed, Jul 31, 2013 at 11:42:00PM +0900, Namjae Jeon wrote:
> >> From: Namjae Jeon 
> >>
> >> Fallocate now supports new FALLOC_FL_COLLAPSE_RANGE flag.
> >> The semantics of this flag are following:
> >> 1) It collapses the range lying between offset and length by removing any
> >> data
> >>blocks which are present in this range and than updates all the
> >> logical
> >>offsets of extents beyond "offset + len" to nullify the hole created
> >> by
> >>removing blocks. In short, it does not leave a hole.
> >> 1) It should be used exclusively. No other fallocate flag in combination.
> >> 2) Offset and length supplied to fallocate should be fs block size
> >> aligned.
> >
> Hi Dave.
> 
> > Given that the rest of fallocate() interfaces are byte based, this
> > is going to cause some confusion if it's not well documented. i.e.
> > this restriction needs to be documented in the header file that is
> > exposed to userspace, as well as in the fallocate(2) man page.
> Agree.
> 
> >
> >> 3) It wokrs beyond "EOF", so the extents which are pre-allocated beyond
> >> "EOF"
> >>are also updated.
> >
> > I don't think that's valid for this operation. If the range is
> > beyond EOF, you are not modifying anything visible to userspace, and
> > that makes it the same as a hole punch operation. So, I'd get rid of
> > thisnasty implementation complexity altogether.
> The basic idea behind collapse range is that it does'nt leaves a hole.

I know what collapse range is and what it's supposed to do. read
again what I said - collapsing a range beyond EOF simply removes
extents that the user can't otherwise see. That makes it the same as
a hole punch operation. i.e. you don't need to use collapse range
for this, because you can simply punch the same number of extents of
the end of the preallocated range and get exactly the same result.

i.e. we already have functionality to manipulate extents beyond EOF
and so we don't need another.

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 3/8] Add all memory via sysfs probe interface at once

2013-08-01 Thread Michael Ellerman
On Wed, Jul 24, 2013 at 01:37:47PM -0500, Nathan Fontenot wrote:
> When doing memory hot add via the 'probe' interface in sysfs we do not
> need to loop through and add memory one section at a time. I think this
> was originally done for powerpc, but is not needed. This patch removes
> the loop and just calls add_memory for all of the memory to be added.

Looks like memory hot add is supported on ia64, x86, sh, powerpc and
s390. Have you tested on any?
 
cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] mm/hotplug: fix a drain pcp bug when offline pages

2013-08-01 Thread Xishi Qiu
On 2013/8/2 2:59, Cody P Schafer wrote:

> On 08/01/2013 02:18 AM, Xishi Qiu wrote:
>> __offline_pages()
>> start_isolate_page_range()
>>set_migratetype_isolate()
>>   set_pageblock_migratetype() -> this pageblock will be marked as 
>> MIGRATE_ISOLATE
>>   move_freepages_block() -> pages in PageBuddy will be moved into 
>> MIGRATE_ISOLATE list
>>   drain_all_pages() -> drain PCP
>>  free_pcppages_bulk()
>> mt = get_freepage_migratetype(page); -> PCP's migratetype is 
>> not MIGRATE_ISOLATE
>> __free_one_page(page, zone, 0, mt); -> so PCP will not be 
>> freed into into MIGRATE_ISOLATE list
>>
>> In this case, the PCP may be allocated again, because they are not in
>> PageBuddy's MIGRATE_ISOLATE list. This will cause offline_pages failed.
>>
>> Signed-off-by: Xishi Qiu 
>> ---
>>   mm/page_alloc.c |   10 ++
>>   mm/page_isolation.c |   15 ++-
>>   2 files changed, 20 insertions(+), 5 deletions(-)
>>
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index b100255..d873471 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -965,11 +965,13 @@ int move_freepages(struct zone *zone,
>>   }
>>
>>   order = page_order(page);
>> -list_move(>lru,
>> -  >free_area[order].free_list[migratetype]);
>> -set_freepage_migratetype(page, migratetype);
>> +if (get_freepage_migratetype(page) != migratetype) {
>> +list_move(>lru,
>> +>free_area[order].free_list[migratetype]);
>> +set_freepage_migratetype(page, migratetype);
>> +pages_moved += 1 << order;
>> +}
>>   page += 1 << order;
>> -pages_moved += 1 << order;
> 
> So this looks like it changes the return from move_freepages() to be the 
> "pages moved" from "the pages now belonging to the passed migrate type".
> 
> The user of move_freepages_block()'s return value (and thus the return value 
> of move_freepages()) in mm/page_alloc.c expects that it is the original 
> meaning. The users in page_isolation.c expect it is the new meaning. Those 
> need to be reconciled.
> 

>>   }
>>
>>   return pages_moved;
>> diff --git a/mm/page_isolation.c b/mm/page_isolation.c
>> index 383bdbb..ba1afc9 100644
>> --- a/mm/page_isolation.c
>> +++ b/mm/page_isolation.c
>> @@ -65,8 +65,21 @@ out:
>>   }
>>
>>   spin_unlock_irqrestore(>lock, flags);
>> -if (!ret)
>> +
>> +if (!ret) {
>>   drain_all_pages();
>> +/*
>> + * When drain_all_pages() frees cached pages into the buddy
>> + * system, it uses the stale migratetype cached in the
>> + * page->index field, so try to move free pages to ISOLATE
>> + * list again.
>> + */
>> +spin_lock_irqsave(>lock, flags);
>> +nr_pages = move_freepages_block(zone, page, MIGRATE_ISOLATE);
>> +__mod_zone_freepage_state(zone, -nr_pages, migratetype);
>> +spin_unlock_irqrestore(>lock, flags);
>> +}
>> +
> 
> Could we teach drain_all_pages() to use the right migrate type instead (or 
> add something similar that does)? (pages could be reallocated between the 
> drain_all_pages() and move_freepages_block()).
> 

Sorry, I made a mistake. __test_page_isolated_in_pageblock() will catch the 
pages and move 
them into MIGRATE_ISOLATE list. So the code is right.

Thanks,
Xishi Qiu

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


Re: [RESEND PATCH 1/2] ARM: msm: Add support for MSM8974

2013-08-01 Thread Stephen Warren
On 08/01/2013 07:23 PM, Rohit Vaswani wrote:
> This patch adds basic board support for MSM8974 which
> belongs to the Snapdragon 800 family.
> For now, just support a basic machine with device tree.

>  arch/arm/boot/dts/msm8974.dts | 26 ++

That's odd. If this is support for an SoC, why not a *.dtsi file rather
than *.dts?
--
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/8] Mark powerpc memory resources as busy

2013-08-01 Thread Michael Ellerman
On Wed, Jul 24, 2013 at 01:36:34PM -0500, Nathan Fontenot wrote:
> Memory I/O resources need to be marked as busy or else we cannot remove
> them when doing memory hot remove.

I would have thought it was the opposite?

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


Re: [PATCH 1/8] register bootmem pages for powerpc when sparse vmemmap is not defined

2013-08-01 Thread Michael Ellerman
On Wed, Jul 24, 2013 at 01:35:11PM -0500, Nathan Fontenot wrote:
> Previous commit 46723bfa540... introduced a new config option
> HAVE_BOOTMEM_INFO_NODE that ended up breaking memory hot-remove for powerpc
> when sparse vmemmap is not defined.

So that's a bug fix that should go into 3.10 stable?

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


Re: [PATCH v2] staging/lustre: lloop depends on BLOCK

2013-08-01 Thread Xiong Zhou


On Wed, 31 Jul 2013, Greg Kroah-Hartman wrote:

> On Wed, Jul 31, 2013 at 10:30:41AM +0800, Xiong Zhou wrote:
> > From: Xiong Zhou 
> > 
> > First version of this patch makes LUSTRE_FS depends on BLOCK.  Second
> > version makes only lloop depends on BLOCK with a config option for this
> > dependence, and remove unnecessary jdb header files which depends on
> > BLOCK.
> > 
> > This version removes the wrapper ll_unregister_blkdev which depends on
> > BLOCK in header and just call unregister_blkdev in lloop.c based on Peng
> > Tao's comment.
> 
> This isn't all needed in the patch changelog info, just say what it
> does.
> 
> Also, it doesn't apply for some reason, care to refresh this against my
> latest tree and resend?
> 
> thanks,
> 
> greg k-h
> 

OK, this patch is based on the staging-next branch of your staging tree.


From: Xiong Zhou 

Add a config option for llite/lloop in lustre driver, making it 
depends on BLOCK to fix this better:
drivers/staging/lustre/lustre/fid/../include/linux/lustre_compat25.h:117:2: 
error: implicit declaration of function ‘unregister_blkdev’ 

Also, remove the wrapper ll_unregister_blkdev which depends on BLOCK in
the header and just call unregister_blkdev in lloop.c based on Peng Tao's
comment. Drop the redundant dependency on STAGING for LUSTRE_FS, remove 
some unnecessary jdb header files which depends on BLOCK btw.

Signed-off-by: Xiong Zhou 
Reviewed-by: Peng Tao 
---
 drivers/staging/lustre/lustre/Kconfig  |7 ++-
 drivers/staging/lustre/lustre/fld/fld_cache.c  |1 -
 drivers/staging/lustre/lustre/fld/fld_request.c|1 -
 .../lustre/lustre/include/linux/lustre_compat25.h  |7 ---
 drivers/staging/lustre/lustre/llite/Makefile   |2 +-
 drivers/staging/lustre/lustre/llite/lloop.c|6 ++
 drivers/staging/lustre/lustre/lvfs/fsfilt.c|1 -
 7 files changed, 9 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/lustre/lustre/Kconfig 
b/drivers/staging/lustre/lustre/Kconfig
index 0b45de0..4e898e4 100644
--- a/drivers/staging/lustre/lustre/Kconfig
+++ b/drivers/staging/lustre/lustre/Kconfig
@@ -1,6 +1,6 @@
 config LUSTRE_FS
tristate "Lustre file system client support"
-   depends on STAGING && INET && BLOCK && m
+   depends on INET && m
select LNET
select CRYPTO
select CRYPTO_CRC32
@@ -53,3 +53,8 @@ config LUSTRE_TRANSLATE_ERRNOS
bool
depends on LUSTRE_FS && !X86
default true
+
+config LUSTRE_LLITE_LLOOP
+   bool "Lustre virtual block device"
+   depends on LUSTRE_FS && BLOCK
+   default m
diff --git a/drivers/staging/lustre/lustre/fld/fld_cache.c 
b/drivers/staging/lustre/lustre/fld/fld_cache.c
index 347f2ae..8410107 100644
--- a/drivers/staging/lustre/lustre/fld/fld_cache.c
+++ b/drivers/staging/lustre/lustre/fld/fld_cache.c
@@ -45,7 +45,6 @@
 
 # include 
 # include 
-# include 
 # include 
 
 #include 
diff --git a/drivers/staging/lustre/lustre/fld/fld_request.c 
b/drivers/staging/lustre/lustre/fld/fld_request.c
index c99b945..049322a 100644
--- a/drivers/staging/lustre/lustre/fld/fld_request.c
+++ b/drivers/staging/lustre/lustre/fld/fld_request.c
@@ -44,7 +44,6 @@
 
 # include 
 # include 
-# include 
 # include 
 
 #include 
diff --git a/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h 
b/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h
index 426533b..018e604 100644
--- a/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h
+++ b/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h
@@ -111,13 +111,6 @@ static inline void ll_set_fs_pwd(struct fs_struct *fs, 
struct vfsmount *mnt,
 #define TREE_READ_LOCK_IRQ(mapping)spin_lock_irq(&(mapping)->tree_lock)
 #define TREE_READ_UNLOCK_IRQ(mapping)  spin_unlock_irq(&(mapping)->tree_lock)
 
-static inline
-int ll_unregister_blkdev(unsigned int dev, const char *name)
-{
-   unregister_blkdev(dev, name);
-   return 0;
-}
-
 #define ll_invalidate_bdev(a,b) invalidate_bdev((a))
 
 #ifndef FS_HAS_FIEMAP
diff --git a/drivers/staging/lustre/lustre/llite/Makefile 
b/drivers/staging/lustre/lustre/llite/Makefile
index dff0c04..f493e07 100644
--- a/drivers/staging/lustre/lustre/llite/Makefile
+++ b/drivers/staging/lustre/lustre/llite/Makefile
@@ -1,5 +1,5 @@
 obj-$(CONFIG_LUSTRE_FS) += lustre.o
-obj-$(CONFIG_LUSTRE_FS) += llite_lloop.o
+obj-$(CONFIG_LUSTRE_LLITE_LLOOP) += llite_lloop.o
 lustre-y := dcache.o dir.o file.o llite_close.o llite_lib.o llite_nfs.o \
rw.o lproc_llite.o namei.o symlink.o llite_mmap.o \
xattr.o remote_perm.o llite_rmtacl.o llite_capa.o \
diff --git a/drivers/staging/lustre/lustre/llite/lloop.c 
b/drivers/staging/lustre/lustre/llite/lloop.c
index e063efc..ae3dc9d 100644
--- a/drivers/staging/lustre/lustre/llite/lloop.c
+++ b/drivers/staging/lustre/lustre/llite/lloop.c
@@ -848,10 +848,8 @@ static void lloop_exit(void)
blk_cleanup_queue(loop_dev[i].lo_queue);
 

[RESEND PATCH 1/4] ARM: msm: Remove pen_release usage

2013-08-01 Thread Rohit Vaswani
pen_release is no longer required as the synchronization
is now managed by generic arm code.
This is done as suggested in https://lkml.org/lkml/2013/6/4/184

Signed-off-by: Rohit Vaswani 
---
 arch/arm/mach-msm/Makefile  |  2 +-
 arch/arm/mach-msm/headsmp.S | 39 ---
 arch/arm/mach-msm/hotplug.c | 31 ---
 arch/arm/mach-msm/platsmp.c | 35 +++
 4 files changed, 8 insertions(+), 99 deletions(-)
 delete mode 100644 arch/arm/mach-msm/headsmp.S

diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile
index 80e3b15..14e22f9 100644
--- a/arch/arm/mach-msm/Makefile
+++ b/arch/arm/mach-msm/Makefile
@@ -20,7 +20,7 @@ obj-$(CONFIG_MSM_SCM) += scm.o scm-boot.o
 CFLAGS_scm.o :=$(call as-instr,.arch_extension sec,-DREQUIRES_SEC=1)
 
 obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
-obj-$(CONFIG_SMP) += headsmp.o platsmp.o
+obj-$(CONFIG_SMP) += platsmp.o
 
 obj-$(CONFIG_MACH_TROUT) += board-trout.o board-trout-gpio.o board-trout-mmc.o 
devices-msm7x00.o
 obj-$(CONFIG_MACH_TROUT) += board-trout.o board-trout-gpio.o board-trout-mmc.o 
board-trout-panel.o devices-msm7x00.o
diff --git a/arch/arm/mach-msm/headsmp.S b/arch/arm/mach-msm/headsmp.S
deleted file mode 100644
index 6c62c3f..000
--- a/arch/arm/mach-msm/headsmp.S
+++ /dev/null
@@ -1,39 +0,0 @@
-/*
- *  linux/arch/arm/mach-realview/headsmp.S
- *
- *  Copyright (c) 2003 ARM Limited
- *  All Rights Reserved
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#include 
-#include 
-
-/*
- * MSM specific entry point for secondary CPUs.  This provides
- * a "holding pen" into which all secondary cores are held until we're
- * ready for them to initialise.
- */
-ENTRY(msm_secondary_startup)
-   mrc p15, 0, r0, c0, c0, 5
-   and r0, r0, #15
-   adr r4, 1f
-   ldmia   r4, {r5, r6}
-   sub r4, r4, r5
-   add r6, r6, r4
-pen:   ldr r7, [r6]
-   cmp r7, r0
-   bne pen
-
-   /*
-* we've been released from the holding pen: secondary_stack
-* should now contain the SVC stack for this core
-*/
-   b   secondary_startup
-ENDPROC(msm_secondary_startup)
-
-   .align
-1: .long   .
-   .long   pen_release
diff --git a/arch/arm/mach-msm/hotplug.c b/arch/arm/mach-msm/hotplug.c
index 326a872..cea80fc 100644
--- a/arch/arm/mach-msm/hotplug.c
+++ b/arch/arm/mach-msm/hotplug.c
@@ -24,33 +24,10 @@ static inline void cpu_leave_lowpower(void)
 
 static inline void platform_do_lowpower(unsigned int cpu)
 {
-   /* Just enter wfi for now. TODO: Properly shut off the cpu. */
-   for (;;) {
-   /*
-* here's the WFI
-*/
-   asm("wfi"
-   :
-   :
-   : "memory", "cc");
-
-   if (pen_release == cpu_logical_map(cpu)) {
-   /*
-* OK, proper wakeup, we're done
-*/
-   break;
-   }
-
-   /*
-* getting here, means that we have come out of WFI without
-* having been woken up - this shouldn't happen
-*
-* The trouble is, letting people know about this is not really
-* possible, since we are currently running incoherently, and
-* therefore cannot safely call printk() or anything else
-*/
-   pr_debug("CPU%u: spurious wakeup call\n", cpu);
-   }
+   asm("wfi"
+   :
+   :
+   : "memory", "cc");
 }
 
 /*
diff --git a/arch/arm/mach-msm/platsmp.c b/arch/arm/mach-msm/platsmp.c
index 3f06edc..5b481db 100644
--- a/arch/arm/mach-msm/platsmp.c
+++ b/arch/arm/mach-msm/platsmp.c
@@ -28,7 +28,7 @@
 #define SCSS_CPU1CORE_RESET 0xD80
 #define SCSS_DBG_STATUS_CORE_PWRDUP 0xE64
 
-extern void msm_secondary_startup(void);
+extern void secondary_startup(void);
 
 static DEFINE_SPINLOCK(boot_lock);
 
@@ -41,13 +41,6 @@ static inline int get_core_count(void)
 static void msm_secondary_init(unsigned int cpu)
 {
/*
-* let the primary processor know we're out of the
-* pen, then head off into the C entry point
-*/
-   pen_release = -1;
-   smp_wmb();
-
-   /*
 * Synchronise with the boot thread.
 */
spin_lock(_lock);
@@ -57,7 +50,7 @@ static void msm_secondary_init(unsigned int cpu)
 static void prepare_cold_cpu(unsigned int cpu)
 {
int ret;
-   ret = scm_set_boot_addr(virt_to_phys(msm_secondary_startup),
+   ret = scm_set_boot_addr(virt_to_phys(secondary_startup),
SCM_FLAG_COLDBOOT_CPU1);
if (ret == 0) {
void __iomem *sc1_base_ptr;
@@ -75,7 +68,6 @@ static 

[PATCH 3/4] ARM: msm: Add SMP support for 8960

2013-08-01 Thread Rohit Vaswani
Add the cpus bindings and the Krait release sequence
to make SMP work for MSM8960

Signed-off-by: Rohit Vaswani 
---
 Documentation/devicetree/bindings/arm/cpus.txt |  2 +
 Documentation/devicetree/bindings/arm/msm/kpss.txt | 16 ++
 arch/arm/boot/dts/msm8960-cdp.dts  | 22 +
 arch/arm/mach-msm/platsmp.c| 57 ++
 arch/arm/mach-msm/scm-boot.h   |  8 +--
 5 files changed, 102 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/msm/kpss.txt

diff --git a/Documentation/devicetree/bindings/arm/cpus.txt 
b/Documentation/devicetree/bindings/arm/cpus.txt
index 327aad2..1132eac 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -45,11 +45,13 @@ For the ARM architecture every CPU node must contain the 
following properties:
"marvell,xsc3"
"marvell,xscale"
"qcom,scorpion"
+   "qcom,krait"
 - enable-method: Specifies the method used to enable or take the secondary 
cores
 out of reset. This allows different reset sequence for
 different types of cpus.
 This should be one of:
 "qcom,scss"
+"qcom,kpssv1"
 
 Example:
 
diff --git a/Documentation/devicetree/bindings/arm/msm/kpss.txt 
b/Documentation/devicetree/bindings/arm/msm/kpss.txt
new file mode 100644
index 000..7272340
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/kpss.txt
@@ -0,0 +1,16 @@
+* KPSS - Krait Processor Sub-system
+
+Properties
+
+- compatible : Should contain "qcom,kpss".
+
+- reg: Specifies the base address for the KPSS registers used for
+   booting up secondary cores.
+
+Example:
+
+   kpss@2088000 {
+   compatible = "qcom,kpss";
+   reg = <0x02088000 0x1000
+   0x02098000 0x2000>;
+   };
diff --git a/arch/arm/boot/dts/msm8960-cdp.dts 
b/arch/arm/boot/dts/msm8960-cdp.dts
index db2060c..8c82d5e 100644
--- a/arch/arm/boot/dts/msm8960-cdp.dts
+++ b/arch/arm/boot/dts/msm8960-cdp.dts
@@ -7,6 +7,22 @@
compatible = "qcom,msm8960-cdp", "qcom,msm8960";
interrupt-parent = <>;
 
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "qcom,krait";
+   device_type = "cpu";
+   enable-method = "qcom,kpssv1";
+
+   cpu@0 {
+   reg = <0>;
+   };
+
+   cpu@1 {
+   reg = <1>;
+   };
+   };
+
intc: interrupt-controller@200 {
compatible = "qcom,msm-qgic2";
interrupt-controller;
@@ -37,6 +53,12 @@
reg = <0xfd51 0x4000>;
};
 
+   kpss@2088000 {
+   compatible = "qcom,kpss";
+   reg = <0x02088000 0x1000
+   0x02098000 0x2000>;
+   };
+
serial@1644 {
compatible = "qcom,msm-hsuart", "qcom,msm-uart";
reg = <0x1644 0x1000>,
diff --git a/arch/arm/mach-msm/platsmp.c b/arch/arm/mach-msm/platsmp.c
index 17022e0..82eb079 100644
--- a/arch/arm/mach-msm/platsmp.c
+++ b/arch/arm/mach-msm/platsmp.c
@@ -74,6 +74,56 @@ static int scorpion_release_secondary(void)
return 0;
 }
 
+static int msm8960_release_secondary(unsigned int cpu)
+{
+   void __iomem *reg;
+   struct device_node *dn = NULL;
+
+   if (cpu == 0 || cpu >= num_possible_cpus())
+   return -EINVAL;
+
+   dn = of_find_compatible_node(dn, NULL, "qcom,kpss");
+   if (!dn) {
+   pr_err("%s : Missing kpss node from device tree\n", __func__);
+   return -ENXIO;
+   }
+
+   reg = of_iomap(dn, cpu);
+   if (!reg)
+   return -ENOMEM;
+
+   pr_debug("Starting secondary CPU %d\n", cpu);
+
+   /* Turn on CPU Rail */
+   writel_relaxed(0xA4, reg+0x1014);
+   mb();
+   udelay(512);
+
+   /* Krait bring-up sequence */
+   writel_relaxed(0x109, reg+0x04);
+   writel_relaxed(0x101, reg+0x04);
+   mb();
+   ndelay(300);
+
+   writel_relaxed(0x121, reg+0x04);
+   mb();
+   udelay(2);
+
+   writel_relaxed(0x120, reg+0x04);
+   mb();
+   udelay(2);
+
+   writel_relaxed(0x100, reg+0x04);
+   mb();
+   udelay(100);
+
+   writel_relaxed(0x180, reg+0x04);
+   mb();
+
+   iounmap(reg);
+   return 0;
+}
+
 static DEFINE_PER_CPU(int, cold_boot_done);
 
 static void boot_cold_cpu(unsigned int cpu)
@@ -96,6 +146,11 @@ static void boot_cold_cpu(unsigned int cpu)
scorpion_release_secondary();
per_cpu(cold_boot_done, cpu) = true;
}
+   } else if (!strcmp(enable_method, "qcom,kpssv1")) {
+   if (per_cpu(cold_boot_done, cpu) == false) {
+  

[RESEND PATCH 2/4] ARM: msm: Re-organize platsmp to make it extensible

2013-08-01 Thread Rohit Vaswani
This makes it easy to add SMP support for new targets
by adding cpus property and the release sequence.
We add the enable-method property for the cpus property to
specify which release sequence to use.
While at it, add the 8660 cpus bindings to make SMP work.

Signed-off-by: Rohit Vaswani 
---
 Documentation/devicetree/bindings/arm/cpus.txt |  6 ++
 Documentation/devicetree/bindings/arm/msm/scss.txt | 15 
 arch/arm/boot/dts/msm8660-surf.dts | 23 +-
 arch/arm/mach-msm/platsmp.c| 94 +-
 4 files changed, 115 insertions(+), 23 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/msm/scss.txt

diff --git a/Documentation/devicetree/bindings/arm/cpus.txt 
b/Documentation/devicetree/bindings/arm/cpus.txt
index f32494d..327aad2 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -44,6 +44,12 @@ For the ARM architecture every CPU node must contain the 
following properties:
"marvell,mohawk"
"marvell,xsc3"
"marvell,xscale"
+   "qcom,scorpion"
+- enable-method: Specifies the method used to enable or take the secondary 
cores
+out of reset. This allows different reset sequence for
+different types of cpus.
+This should be one of:
+"qcom,scss"
 
 Example:
 
diff --git a/Documentation/devicetree/bindings/arm/msm/scss.txt 
b/Documentation/devicetree/bindings/arm/msm/scss.txt
new file mode 100644
index 000..21c3e26
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/scss.txt
@@ -0,0 +1,15 @@
+* SCSS - Scorpion Sub-system
+
+Properties
+
+- compatible : Should contain "qcom,scss".
+
+- reg: Specifies the base address for the SCSS registers used for
+   booting up secondary cores.
+
+Example:
+
+   scss@902000 {
+   compatible = "qcom,scss";
+   reg = <0x00902000 0x2000>;
+   };
diff --git a/arch/arm/boot/dts/msm8660-surf.dts 
b/arch/arm/boot/dts/msm8660-surf.dts
index cdc010e..203e51a 100644
--- a/arch/arm/boot/dts/msm8660-surf.dts
+++ b/arch/arm/boot/dts/msm8660-surf.dts
@@ -7,6 +7,22 @@
compatible = "qcom,msm8660-surf", "qcom,msm8660";
interrupt-parent = <>;
 
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "qcom,scorpion";
+   device_type = "cpu";
+   enable-method = "qcom,scss";
+
+   cpu@0 {
+   reg = <0>;
+   };
+
+   cpu@1 {
+   reg = <1>;
+   };
+   };
+
intc: interrupt-controller@208 {
compatible = "qcom,msm-8660-qgic";
interrupt-controller;
@@ -37,7 +53,12 @@
#interrupt-cells = <2>;
};
 
-   serial@19c4 {
+   scss@902000 {
+   compatible = "qcom,scss";
+   reg = <0x00902000 0x2000>;
+   };
+
+   serial@19c40 {
compatible = "qcom,msm-hsuart", "qcom,msm-uart";
reg = <0x19c4 0x1000>,
  <0x19c0 0x1000>;
diff --git a/arch/arm/mach-msm/platsmp.c b/arch/arm/mach-msm/platsmp.c
index 5b481db..17022e0 100644
--- a/arch/arm/mach-msm/platsmp.c
+++ b/arch/arm/mach-msm/platsmp.c
@@ -13,6 +13,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 
@@ -47,35 +49,63 @@ static void msm_secondary_init(unsigned int cpu)
spin_unlock(_lock);
 }
 
-static void prepare_cold_cpu(unsigned int cpu)
+static int scorpion_release_secondary(void)
 {
-   int ret;
-   ret = scm_set_boot_addr(virt_to_phys(secondary_startup),
-   SCM_FLAG_COLDBOOT_CPU1);
-   if (ret == 0) {
-   void __iomem *sc1_base_ptr;
-   sc1_base_ptr = ioremap_nocache(0x00902000, SZ_4K*2);
-   if (sc1_base_ptr) {
-   writel(0, sc1_base_ptr + VDD_SC1_ARRAY_CLAMP_GFS_CTL);
-   writel(0, sc1_base_ptr + SCSS_CPU1CORE_RESET);
-   writel(3, sc1_base_ptr + SCSS_DBG_STATUS_CORE_PWRDUP);
-   iounmap(sc1_base_ptr);
-   }
-   } else
-   printk(KERN_DEBUG "Failed to set secondary core boot "
- "address\n");
+   void __iomem *sc1_base_ptr;
+   struct device_node *dn = NULL;
+
+   dn = of_find_compatible_node(dn, NULL, "qcom,scss");
+   if (!dn) {
+   pr_err("%s: Missing scss node in device tree\n", __func__);
+   return -ENXIO;
+   }
+
+   sc1_base_ptr = of_iomap(dn, 0);
+   if (sc1_base_ptr) {
+   writel_relaxed(0, sc1_base_ptr + VDD_SC1_ARRAY_CLAMP_GFS_CTL);
+   writel_relaxed(0, sc1_base_ptr + SCSS_CPU1CORE_RESET);
+   writel_relaxed(3, sc1_base_ptr + 

[RESEND PATCH 4/4] ARM: msm: Add support for 8974 SMP

2013-08-01 Thread Rohit Vaswani
Add the cpus bindings and the Kraitv2 release sequence
to make SMP work for 2 cores on MSM8974.

Signed-off-by: Rohit Vaswani 
---
 Documentation/devicetree/bindings/arm/cpus.txt |  1 +
 arch/arm/boot/dts/msm8974.dts  | 23 
 arch/arm/mach-msm/board-dt-8974.c  |  3 +
 arch/arm/mach-msm/platsmp.c| 79 ++
 4 files changed, 106 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/cpus.txt 
b/Documentation/devicetree/bindings/arm/cpus.txt
index 1132eac..7c3c677 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -52,6 +52,7 @@ For the ARM architecture every CPU node must contain the 
following properties:
 This should be one of:
 "qcom,scss"
 "qcom,kpssv1"
+"qcom,kpssv2"
 
 Example:
 
diff --git a/arch/arm/boot/dts/msm8974.dts b/arch/arm/boot/dts/msm8974.dts
index c31c097..ef35a9b 100644
--- a/arch/arm/boot/dts/msm8974.dts
+++ b/arch/arm/boot/dts/msm8974.dts
@@ -7,6 +7,22 @@
compatible = "qcom,msm8974";
interrupt-parent = <>;
 
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "qcom,krait";
+   device_type = "cpu";
+   enable-method = "qcom,kpssv2";
+
+   cpu@0 {
+   reg = <0>;
+   };
+
+   cpu@1 {
+   reg = <1>;
+   };
+   };
+
intc: interrupt-controller@f900 {
compatible = "qcom,msm-qgic2";
interrupt-controller;
@@ -23,4 +39,11 @@
 <1 1 0xf08>;
clock-frequency = <1920>;
};
+
+   kpss@f9012000 {
+   compatible = "qcom,kpss";
+   reg = <0xf9012000 0x1000>,
+ <0xf9088000 0x1000>,
+ <0xf9098000 0x1000>;
+   };
 };
diff --git a/arch/arm/mach-msm/board-dt-8974.c 
b/arch/arm/mach-msm/board-dt-8974.c
index d7f84f2..06119f9 100644
--- a/arch/arm/mach-msm/board-dt-8974.c
+++ b/arch/arm/mach-msm/board-dt-8974.c
@@ -13,11 +13,14 @@
 #include 
 #include 
 
+#include "common.h"
+
 static const char * const msm8974_dt_match[] __initconst = {
"qcom,msm8974",
NULL
 };
 
 DT_MACHINE_START(MSM8974_DT, "Qualcomm MSM (Flattened Device Tree)")
+   .smp = smp_ops(msm_smp_ops),
.dt_compat = msm8974_dt_match,
 MACHINE_END
diff --git a/arch/arm/mach-msm/platsmp.c b/arch/arm/mach-msm/platsmp.c
index 82eb079..0fdae69 100644
--- a/arch/arm/mach-msm/platsmp.c
+++ b/arch/arm/mach-msm/platsmp.c
@@ -124,6 +124,80 @@ static int msm8960_release_secondary(unsigned int cpu)
return 0;
 }
 
+static int msm8974_release_secondary(unsigned int cpu)
+{
+   void __iomem *reg;
+   void __iomem *l2_saw_base;
+   struct device_node *dn = NULL;
+   unsigned apc_pwr_gate_ctl = 0x14;
+   unsigned reg_val;
+
+   if (cpu == 0 || cpu >= num_possible_cpus())
+   return -EINVAL;
+
+   dn = of_find_compatible_node(dn, NULL, "qcom,kpss");
+   if (!dn) {
+   pr_err("%s : Missing kpss node from device tree\n", __func__);
+   return -ENXIO;
+   }
+
+   reg = of_iomap(dn, cpu+1);
+   if (!reg)
+   return -ENOMEM;
+
+   pr_debug("Starting secondary CPU %d\n", cpu);
+
+   /* Turn on the BHS, turn off LDO Bypass and power down LDO */
+   reg_val =  0x403f0001;
+   writel_relaxed(reg_val, reg + apc_pwr_gate_ctl);
+
+   /* complete the above write before the delay */
+   mb();
+   /* wait for the bhs to settle */
+   udelay(1);
+
+   /* Turn on BHS segments */
+   reg_val |= 0x3f << 1;
+   writel_relaxed(reg_val, reg + apc_pwr_gate_ctl);
+
+   /* complete the above write before the delay */
+   mb();
+/* wait for the bhs to settle */
+   udelay(1);
+
+   /* Finally turn on the bypass so that BHS supplies power */
+   reg_val |= 0x3f << 8;
+   writel_relaxed(reg_val, reg + apc_pwr_gate_ctl);
+
+   /* enable max phases */
+   l2_saw_base = of_iomap(dn, 0);
+   if (!l2_saw_base) {
+   return -ENOMEM;
+   }
+   writel_relaxed(0x10003, l2_saw_base + 0x1c);
+   mb();
+   udelay(50);
+
+   iounmap(l2_saw_base);
+
+   writel_relaxed(0x021, reg+0x04);
+   mb();
+   udelay(2);
+
+   writel_relaxed(0x020, reg+0x04);
+   mb();
+   udelay(2);
+
+   writel_relaxed(0x000, reg+0x04);
+   mb();
+
+   writel_relaxed(0x080, reg+0x04);
+   mb();
+
+   iounmap(reg);
+   return 0;
+}
+
 static DEFINE_PER_CPU(int, cold_boot_done);
 
 static void boot_cold_cpu(unsigned int cpu)
@@ -151,6 +225,11 @@ static void boot_cold_cpu(unsigned int cpu)
msm8960_release_secondary(cpu);

[RESEND PATCH 0/4]Add SMP support for MSM8660, MSM8960 and MSM8974

2013-08-01 Thread Rohit Vaswani
This series re-organizes the platsmp.c and adds SMP support for
MSM8660, MSM8960 and MSM8974. This is based on 3.11-rc3.
We convert to using the cpus property in device tree and
add a "enable-method" property for arm32.
This helps select the appropriate release sequence for the
secondary cores based on the cpu.

Rohit Vaswani (4):
  ARM: msm: Remove pen_release usage
  ARM: msm: Re-organize platsmp to make it extensible
  ARM: msm: Add SMP support for 8960
  ARM: msm: Add support for 8974 SMP

 Documentation/devicetree/bindings/arm/cpus.txt |   9 +
 Documentation/devicetree/bindings/arm/msm/kpss.txt |  16 ++
 Documentation/devicetree/bindings/arm/msm/scss.txt |  15 ++
 arch/arm/boot/dts/msm8660-surf.dts |  23 +-
 arch/arm/boot/dts/msm8960-cdp.dts  |  22 ++
 arch/arm/boot/dts/msm8974.dts  |  23 ++
 arch/arm/mach-msm/Makefile |   2 +-
 arch/arm/mach-msm/board-dt-8974.c  |   3 +
 arch/arm/mach-msm/headsmp.S|  39 ---
 arch/arm/mach-msm/hotplug.c|  31 +--
 arch/arm/mach-msm/platsmp.c| 263 -
 arch/arm/mach-msm/scm-boot.h   |   8 +-
 12 files changed, 330 insertions(+), 124 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/msm/kpss.txt
 create mode 100644 Documentation/devicetree/bindings/arm/msm/scss.txt
 delete mode 100644 arch/arm/mach-msm/headsmp.S

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 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: /sys/module/pcie_aspm/parameters/policy not writable?

2013-08-01 Thread Pavel Machek
Hi!

> >> > But since the problem also occurs with Windows, it's pretty likely
> >> > that there's a BIOS update to fix it.  I notice on the X60 support
> >> > page that there are several versions newer than what you're running.
> >>
> >> Do you have any interest in trying a newer BIOS to see if it's fixed
> >> there?  If not, I understand; BIOS updates are a hassle at best.
> >> You're running BIOS 2.14, and it looks like the current BIOS for an
> >> X60 1709 7HU is 2.19 (from http://support.lenovo.com).
> >
> > I'm lost at the lenovo pages :-(. And frankly I'd prefer not to touch
> > the BIOS.
> 
> I tried to provide a complete link, but the web site isn't amenable to
> that.  I found it by selecting the "Drivers & Software" section,
> entering "X60" as the machine type, selecting "ThinkPad X60 (1709)"
> and going to the "BIOS" section.  I was surprised how easy it was :)

Hmm. So I've update bios using 7buj28uc.iso . Reverted the patches and
yes, ping latencies are still bad:

pavel@amd:~$ ping 10.0.0.250
PING 10.0.0.250 (10.0.0.250) 56(84) bytes of data.
64 bytes from 10.0.0.250: icmp_req=1 ttl=127 time=1.05 ms
64 bytes from 10.0.0.250: icmp_req=2 ttl=127 time=0.820 ms
64 bytes from 10.0.0.250: icmp_req=3 ttl=127 time=73.5 ms
64 bytes from 10.0.0.250: icmp_req=4 ttl=127 time=7.41 ms
64 bytes from 10.0.0.250: icmp_req=5 ttl=127 time=5.25 ms
64 bytes from 10.0.0.250: icmp_req=6 ttl=127 time=1.16 ms
64 bytes from 10.0.0.250: icmp_req=7 ttl=127 time=36.3 ms
64 bytes from 10.0.0.250: icmp_req=8 ttl=127 time=1.64 ms

> >> Carolyn's patch will likely work, at least most of the time, but I
> >> think there's a small possibility that it could cause a conflict
> >> between the BIOS and the OS over ASPM control, so I'm not 100% in
> >> support of that approach.  A conflict may not happen on your
> >> machine,
> >
> > Can we base it on DMI  whitelist?
> 
> I don't think we can know a priori whether a machine (even your
> machine) is susceptible to a conflict.  But if Carolyn forcibly

We don't apriori now how broken machines are, true. There are 1000
ways BIOS can break things. And yes, it will be us breaking the specs
here. But "useful machine with OS breaking specs" is better than
"machine useless for ssh".

_If_ there's a conflict, we can try something else.

(Has someone really seen a conflict, or is it just theoretical thing?)

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 2/4] mm, migrate: allocation new page lazyily in unmap_and_move()

2013-08-01 Thread Joonsoo Kim
We don't need a new page and then go out immediately if some condition
is met. Allocation has overhead in comparison with some condition check,
so allocating lazyily is preferable solution.

Signed-off-by: Joonsoo Kim 

diff --git a/mm/migrate.c b/mm/migrate.c
index 6f0c244..86db87e 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -864,10 +864,7 @@ static int unmap_and_move(new_page_t get_new_page, 
unsigned long private,
 {
int rc = 0;
int *result = NULL;
-   struct page *newpage = get_new_page(page, private, );
-
-   if (!newpage)
-   return -ENOMEM;
+   struct page *newpage = NULL;
 
if (page_count(page) == 1) {
/* page was freed from under us. So we are done. */
@@ -878,6 +875,10 @@ static int unmap_and_move(new_page_t get_new_page, 
unsigned long private,
if (unlikely(split_huge_page(page)))
goto out;
 
+   newpage = get_new_page(page, private, );
+   if (!newpage)
+   return -ENOMEM;
+
rc = __unmap_and_move(page, newpage, force, mode);
 
if (unlikely(rc == MIGRATEPAGE_BALLOON_SUCCESS)) {
@@ -908,7 +909,8 @@ out:
 * Move the new page to the LRU. If migration was not successful
 * then this will free the page.
 */
-   putback_lru_page(newpage);
+   if (newpage)
+   putback_lru_page(newpage);
if (result) {
if (rc)
*result = rc;
-- 
1.7.9.5

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


[PATCH 1/4] mm, page_alloc: add likely macro to help compiler optimization

2013-08-01 Thread Joonsoo Kim
We rarely allocate a page with ALLOC_NO_WATERMARKS and it is used
in slow path. For making fast path more faster, add likely macro to
help compiler optimization.

Signed-off-by: Joonsoo Kim 

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index b100255..86ad44b 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1901,7 +1901,7 @@ zonelist_scan:
goto this_zone_full;
 
BUILD_BUG_ON(ALLOC_NO_WATERMARKS < NR_WMARK);
-   if (!(alloc_flags & ALLOC_NO_WATERMARKS)) {
+   if (likely(!(alloc_flags & ALLOC_NO_WATERMARKS))) {
unsigned long mark;
int ret;
 
-- 
1.7.9.5

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


[PATCH 4/4] swap: clean-up #ifdef in page_mapping()

2013-08-01 Thread Joonsoo Kim
PageSwapCache() is always false when !CONFIG_SWAP, so compiler
properly discard related code. Therefore, we don't need #ifdef explicitly.

Signed-off-by: Joonsoo Kim 

diff --git a/include/linux/swap.h b/include/linux/swap.h
index d95cde5..c638a71 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -414,6 +414,7 @@ mem_cgroup_uncharge_swapcache(struct page *page, 
swp_entry_t ent, bool swapout)
 
 #else /* CONFIG_SWAP */
 
+#define swap_address_space(entry)  (NULL)
 #define get_nr_swap_pages()0L
 #define total_swap_pages   0L
 #define total_swapcache_pages()0UL
diff --git a/mm/util.c b/mm/util.c
index 7441c41..eaf63fc2 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -388,15 +388,12 @@ struct address_space *page_mapping(struct page *page)
struct address_space *mapping = page->mapping;
 
VM_BUG_ON(PageSlab(page));
-#ifdef CONFIG_SWAP
if (unlikely(PageSwapCache(page))) {
swp_entry_t entry;
 
entry.val = page_private(page);
mapping = swap_address_space(entry);
-   } else
-#endif
-   if ((unsigned long)mapping & PAGE_MAPPING_ANON)
+   } else if ((unsigned long)mapping & PAGE_MAPPING_ANON)
mapping = NULL;
return mapping;
 }
-- 
1.7.9.5

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


[PATCH 3/4] mm: move pgtable related functions to right place

2013-08-01 Thread Joonsoo Kim
pgtable related functions are mostly in pgtable-generic.c.
So move remaining functions from memory.c to pgtable-generic.c.

Signed-off-by: Joonsoo Kim 

diff --git a/mm/memory.c b/mm/memory.c
index 1ce2e2a..26bce51 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -374,30 +374,6 @@ void tlb_remove_table(struct mmu_gather *tlb, void *table)
 #endif /* CONFIG_HAVE_RCU_TABLE_FREE */
 
 /*
- * If a p?d_bad entry is found while walking page tables, report
- * the error, before resetting entry to p?d_none.  Usually (but
- * very seldom) called out from the p?d_none_or_clear_bad macros.
- */
-
-void pgd_clear_bad(pgd_t *pgd)
-{
-   pgd_ERROR(*pgd);
-   pgd_clear(pgd);
-}
-
-void pud_clear_bad(pud_t *pud)
-{
-   pud_ERROR(*pud);
-   pud_clear(pud);
-}
-
-void pmd_clear_bad(pmd_t *pmd)
-{
-   pmd_ERROR(*pmd);
-   pmd_clear(pmd);
-}
-
-/*
  * Note: this doesn't free the actual pages themselves. That
  * has been handled earlier when unmapping all the memory regions.
  */
diff --git a/mm/pgtable-generic.c b/mm/pgtable-generic.c
index e1a6e4f..3929a40 100644
--- a/mm/pgtable-generic.c
+++ b/mm/pgtable-generic.c
@@ -10,6 +10,30 @@
 #include 
 #include 
 
+/*
+ * If a p?d_bad entry is found while walking page tables, report
+ * the error, before resetting entry to p?d_none.  Usually (but
+ * very seldom) called out from the p?d_none_or_clear_bad macros.
+ */
+
+void pgd_clear_bad(pgd_t *pgd)
+{
+   pgd_ERROR(*pgd);
+   pgd_clear(pgd);
+}
+
+void pud_clear_bad(pud_t *pud)
+{
+   pud_ERROR(*pud);
+   pud_clear(pud);
+}
+
+void pmd_clear_bad(pmd_t *pmd)
+{
+   pmd_ERROR(*pmd);
+   pmd_clear(pmd);
+}
+
 #ifndef __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS
 /*
  * Only sets the access flags (dirty, accessed), as well as write 
-- 
1.7.9.5

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


Re: [QUERY] lguest64

2013-08-01 Thread Rusty Russell
Mike Rapoport  writes:
> On Wed, Jul 31, 2013 at 3:17 PM, H. Peter Anvin  wrote:
>> On 07/31/2013 02:39 AM, Mike Rapoport wrote:
>>>
>>> The use case I had in mind is to use lguest as a nested hypervisor in
>>> public clouds. As of today, major public clouds do not support nested
>>> virtualization and it's not clear at all if they will expose this
>>> ability in their deployments. Addition of 64-bit support for lguest
>>> won't require changes to pvops and, as far as I can tell, won't change
>>> the number of pvops users...
>>>
>>
>> "We can add a pvops user and that won't change the number of pvops
>> users" What?!
>
> We modify existing pvops user, IMHO. lguest is existing pvops user and
> my idea was to extend it, rather than add lguest64 alongside lguest32.

Well, lguest is particularly expendable.  It's the red shirt of the
virtualization away team.

Unlike HPA, I would advocate for applying the patches if you produced
them.  But I'd be aware that they're likely to be ripped out as soon as
pvops has no other users.

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


Re: [PATCH] acpi: video: fix reversed indexed BQC

2013-08-01 Thread Aaron Lu
On 08/02/2013 07:34 AM, Felipe Contreras wrote:
> Commit 1a7c618 (ACPI video: support _BQC/_BCL/_BCM methods that use
> index values) assumed that bl->levels were not reverted, but at this
> point they already are, so there's no need to revert them yet again.

When acpi_video_bqc_value_to_level is called, bl->levels is not
reverted. Can you please point me the code path when it is called and
bl->levels were still reverted? I think we will need to fix that then.

-Aaron

> 
> Signed-off-by: Felipe Contreras 
> ---
>  drivers/acpi/video.c | 13 ++---
>  1 file changed, 2 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
> index 0ec434d..b27c049 100644
> --- a/drivers/acpi/video.c
> +++ b/drivers/acpi/video.c
> @@ -499,19 +499,10 @@ acpi_video_bqc_value_to_level(struct acpi_video_device 
> *device,
>  {
>   unsigned long long level;
>  
> - if (device->brightness->flags._BQC_use_index) {
> - /*
> -  * _BQC returns an index that doesn't account for
> -  * the first 2 items with special meaning, so we need
> -  * to compensate for that by offsetting ourselves
> -  */
> - if (device->brightness->flags._BCL_reversed)
> - bqc_value = device->brightness->count - 3 - bqc_value;
> -
> + if (device->brightness->flags._BQC_use_index)
>   level = device->brightness->levels[bqc_value + 2];
> - } else {
> + else
>   level = bqc_value;
> - }
>  
>   level += bqc_offset_aml_bug_workaround;
>  
> 

--
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] mm, slab_common: add 'unlikely' to size check of kmalloc_slab()

2013-08-01 Thread Joonsoo Kim
Size is usually below than KMALLOC_MAX_SIZE.
If we add a 'unlikely' macro, compiler can make better code.

Signed-off-by: Joonsoo Kim 

diff --git a/mm/slab_common.c b/mm/slab_common.c
index 538bade..f0410eb 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -373,7 +373,7 @@ struct kmem_cache *kmalloc_slab(size_t size, gfp_t flags)
 {
int index;
 
-   if (size > KMALLOC_MAX_SIZE) {
+   if (unlikely(size > KMALLOC_MAX_SIZE)) {
WARN_ON_ONCE(!(flags & __GFP_NOWARN));
return NULL;
}
-- 
1.7.9.5

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


Re: [PATCH] regulator: pfuze100: Fix off-by-one for max_register setting

2013-08-01 Thread Robin Gong
On Thu, Aug 01, 2013 at 07:59:56PM +0800, Axel Lin wrote:
> max_register should be register count - 1.
> 
> Signed-off-by: Axel Lin 
> ---
> Hi Robin,
> I don't have the datasheet, can you check if this patch is correct or not?
> If PFUZE_NUMREGS really means register count, I think this fix is required.
> 
Yes, you are right.
Reviewed-by: Robin Gong 
Thanks.
> Thanks,
> Axel
>  drivers/regulator/pfuze100-regulator.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/regulator/pfuze100-regulator.c 
> b/drivers/regulator/pfuze100-regulator.c
> index bda5561..ba67b2c 100644
> --- a/drivers/regulator/pfuze100-regulator.c
> +++ b/drivers/regulator/pfuze100-regulator.c
> @@ -332,7 +332,7 @@ static int pfuze_identify(struct pfuze_chip *pfuze_chip)
>  static const struct regmap_config pfuze_regmap_config = {
>   .reg_bits = 8,
>   .val_bits = 8,
> - .max_register = PFUZE_NUMREGS,
> + .max_register = PFUZE_NUMREGS - 1,
>   .cache_type = REGCACHE_RBTREE,
>  };
>  
> -- 
> 1.8.1.2
> 
> 
> 
> 

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


[PATCH] DMA: let filter functions of of_dma_simple_xlate possible check of_node

2013-08-01 Thread Richard Zhao
pass of_phandle_args dma_spec to dma_request_channel in of_dma_simple_xlate,
so the filter function could access of_node in of_phandle_args.

It also remove restriction of #dma-cells has to be one.

Signed-off-by: Richard Zhao 
---
 drivers/dma/edma.c |  7 +--
 drivers/dma/of-dma.c   | 10 --
 drivers/dma/omap-dma.c |  6 --
 3 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 4f6d87b..54582fd 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -604,9 +605,11 @@ static struct platform_driver edma_driver = {
 
 bool edma_filter_fn(struct dma_chan *chan, void *param)
 {
-   if (chan->device->dev->driver == _driver.driver) {
+   struct of_phandle_args *dma_spec = param;
+   if (chan->device->dev->driver == _driver.driver &&
+   dma_spec->np == chan->device->dev->of_node) {
struct edma_chan *echan = to_edma_chan(chan);
-   unsigned ch_req = *(unsigned *)param;
+   unsigned ch_req = dma_spec->args[0];
return ch_req == echan->ch_num;
}
return false;
diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c
index 75334bd..e1c4d3b 100644
--- a/drivers/dma/of-dma.c
+++ b/drivers/dma/of-dma.c
@@ -192,11 +192,9 @@ struct dma_chan *of_dma_request_slave_channel(struct 
device_node *np,
  * @dma_spec:  pointer to DMA specifier as found in the device tree
  * @of_dma:pointer to DMA controller data
  *
- * A simple translation function for devices that use a 32-bit value for the
+ * A simple translation function for devices that use dma_spec for the
  * filter_param when calling the DMA engine dma_request_channel() function.
- * Note that this translation function requires that #dma-cells is equal to 1
- * and the argument of the dma specifier is the 32-bit filter_param. Returns
- * pointer to appropriate dma channel on success or NULL on error.
+ * Returns pointer to appropriate dma channel on success or NULL on error.
  */
 struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec,
struct of_dma *ofdma)
@@ -207,10 +205,10 @@ struct dma_chan *of_dma_simple_xlate(struct 
of_phandle_args *dma_spec,
if (!info || !info->filter_fn)
return NULL;
 
-   if (count != 1)
+   if (count < 1)
return NULL;
 
return dma_request_channel(info->dma_cap, info->filter_fn,
-   _spec->args[0]);
+   dma_spec);
 }
 EXPORT_SYMBOL_GPL(of_dma_simple_xlate);
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index ec3fc4f..32547ec 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -693,9 +693,11 @@ static struct platform_driver omap_dma_driver = {
 
 bool omap_dma_filter_fn(struct dma_chan *chan, void *param)
 {
-   if (chan->device->dev->driver == _dma_driver.driver) {
+   struct of_phandle_args *dma_spec = param;
+   if (chan->device->dev->driver == _dma_driver.driver &&
+   dma_spec->np == chan->device->dev->of_node) {
struct omap_chan *c = to_omap_dma_chan(chan);
-   unsigned req = *(unsigned *)param;
+   unsigned req = dma_spec->args[0];
 
return req == c->dma_sig;
}
-- 
1.8.1.5

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


Re: [PATCH 3/3] acpi: video: remove unnecessary casting

2013-08-01 Thread Aaron Lu
On 08/02/2013 07:44 AM, Felipe Contreras wrote:
> Signed-off-by: Felipe Contreras 

Looks good to me, except that no change log feels a little weird.

Reviewed-by: Aaron Lu 

Thanks,
Aaron

> ---
>  drivers/acpi/video.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
> index b07573f..11bafbe 100644
> --- a/drivers/acpi/video.c
> +++ b/drivers/acpi/video.c
> @@ -236,8 +236,7 @@ static int acpi_video_get_brightness(struct 
> backlight_device *bd)
>  {
>   unsigned long long cur_level;
>   int i;
> - struct acpi_video_device *vd =
> - (struct acpi_video_device *)bl_get_data(bd);
> + struct acpi_video_device *vd = bl_get_data(bd);
>  
>   if (acpi_video_device_lcd_get_level_current(vd, _level, false))
>   return -EINVAL;
> @@ -255,8 +254,7 @@ static int acpi_video_get_brightness(struct 
> backlight_device *bd)
>  static int acpi_video_set_brightness(struct backlight_device *bd)
>  {
>   int request_level = bd->props.brightness + 2;
> - struct acpi_video_device *vd =
> - (struct acpi_video_device *)bl_get_data(bd);
> + struct acpi_video_device *vd = bl_get_data(bd);
>  
>   return acpi_video_device_lcd_set_level(vd,
>   vd->brightness->levels[request_level]);
> 

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


  1   2   3   4   5   6   7   8   9   10   >