[PATCH v2 10/10] intel_mid: Moved SFI related code to intel_mid_sfi.c

[David Cohen]

From: Kuppuswamy Sathyanarayanan 

Moved SFI specific parsing/handling code to intel_mid_sfi.c. This will enable
us to reuse our intel-mid code for platforms that supports firmware interfaces
other than SFI (like ACPI).

Signed-off-by: Kuppuswamy Sathyanarayanan 

Signed-off-by: David Cohen 
---
 arch/x86/include/asm/intel-mid.h|1 +
 arch/x86/platform/intel-mid/Makefile|5 +-
 arch/x86/platform/intel-mid/intel-mid.c |  450 -
 arch/x86/platform/intel-mid/intel_mid_sfi.c |  485 +++
 4 files changed, 489 insertions(+), 452 deletions(-)
 create mode 100644 arch/x86/platform/intel-mid/intel_mid_sfi.c

diff --git a/arch/x86/include/asm/intel-mid.h b/arch/x86/include/asm/intel-mid.h
index afc282a..358e0d2 100644
--- a/arch/x86/include/asm/intel-mid.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -18,6 +18,7 @@ extern int intel_mid_pci_init(void);
 extern int get_gpio_by_name(const char *name);
 extern void intel_scu_device_register(struct platform_device *pdev);
 extern int __init sfi_parse_mrtc(struct sfi_table_header *table);
+extern int __init sfi_parse_mtmr(struct sfi_table_header *table);
 extern int sfi_mrtc_num;
 extern struct sfi_rtc_table_entry sfi_mrtc_array[];
 
diff --git a/arch/x86/platform/intel-mid/Makefile 
b/arch/x86/platform/intel-mid/Makefile
index 36323ee..9a6b6c3 100644
--- a/arch/x86/platform/intel-mid/Makefile
+++ b/arch/x86/platform/intel-mid/Makefile
@@ -1,8 +1,9 @@
 obj-$(CONFIG_X86_INTEL_MID) += intel-mid.o
 obj-$(CONFIG_X86_INTEL_MID)+= intel_mid_vrtc.o
 obj-$(CONFIG_EARLY_PRINTK_INTEL_MID)   += early_printk_intel_mid.o
-
+# SFI specific code
+obj-$(CONFIG_SFI) += intel_mid_sfi.o
 # BOARD files
 obj-$(CONFIG_X86_INTEL_MID) += board.o
 # platform configuration for board devices
-obj-y += device_libs/
\ No newline at end of file
+obj-y += device_libs/
diff --git a/arch/x86/platform/intel-mid/intel-mid.c 
b/arch/x86/platform/intel-mid/intel-mid.c
index 0ac2bd6..a08541a 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -18,19 +18,9 @@
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
 
 #include 
 #include 
@@ -69,17 +59,9 @@
 
 enum intel_mid_timer_options intel_mid_timer_options;
 
-static u32 sfi_mtimer_usage[SFI_MTMR_MAX_NUM];
-static struct sfi_timer_table_entry sfi_mtimer_array[SFI_MTMR_MAX_NUM];
 enum intel_mid_cpu_type __intel_mid_cpu_chip;
 EXPORT_SYMBOL_GPL(__intel_mid_cpu_chip);
 
-int sfi_mtimer_num;
-
-struct sfi_rtc_table_entry sfi_mrtc_array[SFI_MRTC_MAX];
-EXPORT_SYMBOL_GPL(sfi_mrtc_array);
-int sfi_mrtc_num;
-
 static void intel_mid_power_off(void)
 {
 }
@@ -89,114 +71,6 @@ static void intel_mid_reboot(void)
intel_scu_ipc_simple_command(IPCMSG_COLD_BOOT, 0);
 }
 
-/* parse all the mtimer info to a static mtimer array */
-static int __init sfi_parse_mtmr(struct sfi_table_header *table)
-{
-   struct sfi_table_simple *sb;
-   struct sfi_timer_table_entry *pentry;
-   struct mpc_intsrc mp_irq;
-   int totallen;
-
-   sb = (struct sfi_table_simple *)table;
-   if (!sfi_mtimer_num) {
-   sfi_mtimer_num = SFI_GET_NUM_ENTRIES(sb,
-   struct sfi_timer_table_entry);
-   pentry = (struct sfi_timer_table_entry *) sb->pentry;
-   totallen = sfi_mtimer_num * sizeof(*pentry);
-   memcpy(sfi_mtimer_array, pentry, totallen);
-   }
-
-   pr_debug("SFI MTIMER info (num = %d):\n", sfi_mtimer_num);
-   pentry = sfi_mtimer_array;
-   for (totallen = 0; totallen < sfi_mtimer_num; totallen++, pentry++) {
-   pr_debug("timer[%d]: paddr = 0x%08x, freq = %dHz,"
-   " irq = %d\n", totallen, (u32)pentry->phys_addr,
-   pentry->freq_hz, pentry->irq);
-   if (!pentry->irq)
-   continue;
-   mp_irq.type = MP_INTSRC;
-   mp_irq.irqtype = mp_INT;
-/* triggering mode edge bit 2-3, active high polarity bit 0-1 */
-   mp_irq.irqflag = 5;
-   mp_irq.srcbus = MP_BUS_ISA;
-   mp_irq.srcbusirq = pentry->irq; /* IRQ */
-   mp_irq.dstapic = MP_APIC_ALL;
-   mp_irq.dstirq = pentry->irq;
-   mp_save_irq(_irq);
-   }
-
-   return 0;
-}
-
-struct sfi_timer_table_entry *sfi_get_mtmr(int hint)
-{
-   int i;
-   if (hint < sfi_mtimer_num) {
-   if (!sfi_mtimer_usage[hint]) {
-   pr_debug("hint taken for timer %d irq %d\n",
-   hint, sfi_mtimer_array[hint].irq);
-   sfi_mtimer_usage[hint] = 1;
-   return _mtimer_array[hint];
-   }
-   }
-   /* take 

[PATCH v2 08/10] intel_mid: Added custom handler for ipc devices

[David Cohen]

From: Kuppuswamy Sathyanarayanan 

Added a custom handler for medfield based ipc devices and
moved devs_id structure defintion to header file.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Signed-off-by: David Cohen 
---
 arch/x86/include/asm/intel-mid.h|   15 ++
 arch/x86/platform/intel-mid/intel-mid.c |   87 ---
 2 files changed, 71 insertions(+), 31 deletions(-)

diff --git a/arch/x86/include/asm/intel-mid.h b/arch/x86/include/asm/intel-mid.h
index beb7a5f..ad236ae 100644
--- a/arch/x86/include/asm/intel-mid.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -19,6 +19,21 @@ extern int sfi_mrtc_num;
 extern struct sfi_rtc_table_entry sfi_mrtc_array[];
 
 /*
+ * Here defines the array of devices platform data that IAFW would export
+ * through SFI "DEVS" table, we use name and type to match the device and
+ * its platform data.
+ */
+struct devs_id {
+   char name[SFI_NAME_LEN + 1];
+   u8 type;
+   u8 delay;
+   void *(*get_platform_data)(void *info);
+   /* Custom handler for devices */
+   void (*device_handler)(struct sfi_device_table_entry *pentry,
+   struct devs_id *dev);
+};
+
+/*
  * Medfield is the follow-up of Moorestown, it combines two chip solution into
  * one. Other than that it also added always-on and constant tsc and lapic
  * timers. Medfield is the platform name, and the chip name is called Penwell
diff --git a/arch/x86/platform/intel-mid/intel-mid.c 
b/arch/x86/platform/intel-mid/intel-mid.c
index 65c7bca..3a210d9 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -78,6 +78,8 @@ int sfi_mtimer_num;
 struct sfi_rtc_table_entry sfi_mrtc_array[SFI_MRTC_MAX];
 EXPORT_SYMBOL_GPL(sfi_mrtc_array);
 int sfi_mrtc_num;
+static void __init ipc_device_handler(struct sfi_device_table_entry *pentry,
+   struct devs_id *dev);
 
 static void intel_mid_power_off(void)
 {
@@ -386,21 +388,6 @@ static int get_gpio_by_name(const char *name)
return -1;
 }
 
-/*
- * Here defines the array of devices platform data that IAFW would export
- * through SFI "DEVS" table, we use name and type to match the device and
- * its platform data.
- */
-struct devs_id {
-   char name[SFI_NAME_LEN + 1];
-   u8 type;
-   u8 delay;
-   void *(*get_platform_data)(void *info);
-   /* Custom handler for devices */
-   void (*device_handler)(struct sfi_device_table_entry *pentry,
-   struct devs_id *dev);
-};
-
 /* the offset for the mapping of global gpio pin to irq */
 #define INTEL_MID_IRQ_OFFSET 0x100
 
@@ -695,27 +682,32 @@ static void *tc35876x_platform_data(void *data)
 static const struct devs_id __initconst device_ids[] = {
{"bma023", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
{"pmic_gpio", SFI_DEV_TYPE_SPI, 1, _gpio_platform_data, NULL},
-   {"pmic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data, NULL},
+   {"pmic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data,
+   _device_handler},
{"spi_max3111", SFI_DEV_TYPE_SPI, 0, _platform_data, NULL},
{"i2c_max7315", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
{"i2c_max7315_2", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
{"tca6416", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
{"emc1403", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
{"i2c_accel", SFI_DEV_TYPE_I2C, 0, _platform_data, NULL},
-   {"pmic_audio", SFI_DEV_TYPE_IPC, 1, _platform_data, NULL},
+   {"pmic_audio", SFI_DEV_TYPE_IPC, 1, _platform_data,
+   _device_handler},
{"mpu3050", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
{"i2c_disp_brig", SFI_DEV_TYPE_I2C, 0, _platform_data, NULL},
 
/* MSIC subdevices */
{"msic_battery", SFI_DEV_TYPE_IPC, 1, _battery_platform_data,
-   NULL},
-   {"msic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data, NULL},
-   {"msic_audio", SFI_DEV_TYPE_IPC, 1, _audio_platform_data, NULL},
+   _device_handler},
+   {"msic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data,
+   _device_handler},
+   {"msic_audio", SFI_DEV_TYPE_IPC, 1, _audio_platform_data,
+   _device_handler},
{"msic_power_btn", SFI_DEV_TYPE_IPC, 1, _power_btn_platform_data,
-   NULL},
-   {"msic_ocd", SFI_DEV_TYPE_IPC, 1, _ocd_platform_data, NULL},
+   _device_handler},
+   {"msic_ocd", SFI_DEV_TYPE_IPC, 1, _ocd_platform_data,
+   _device_handler},
{"msic_thermal", SFI_DEV_TYPE_IPC, 1, _thermal_platform_data,
-   NULL},
+   _device_handler},
{},
 };
 
@@ -846,13 +838,6 @@ 

[PATCH v2 03/10] mrst: Fixed checkpatch warnings

[David Cohen]

From: Kuppuswamy Sathyanarayanan 

Fixed checkpatch warnings in mrst related files.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Signed-off-by: David Cohen 
---
 arch/x86/platform/mrst/mrst.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/platform/mrst/mrst.c b/arch/x86/platform/mrst/mrst.c
index 235a742..2a45eab 100644
--- a/arch/x86/platform/mrst/mrst.c
+++ b/arch/x86/platform/mrst/mrst.c
@@ -977,7 +977,7 @@ static int __init sfi_parse_devs(struct sfi_table_header 
*table)
case SFI_DEV_TYPE_UART:
case SFI_DEV_TYPE_HSI:
default:
-   ;
+   break;
}
}
return 0;
-- 
1.7.9.5

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

[PATCH v2 06/10] intel_mid: Refactored sfi_parse_devs() function

[David Cohen]

From: Kuppuswamy Sathyanarayanan 

SFI device_id[] table parsing code is duplicated in every SFI
device handler. This patch removes this code duplication, by
adding a seperate function get_device_id() to parse through the
device table. Also this patch moves the SPI, I2C, IPC info code from
sfi_parse_devs() to respective device handlers.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Signed-off-by: David Cohen 
---
 arch/x86/platform/intel-mid/intel-mid.c |  141 ---
 1 file changed, 71 insertions(+), 70 deletions(-)

diff --git a/arch/x86/platform/intel-mid/intel-mid.c 
b/arch/x86/platform/intel-mid/intel-mid.c
index 742b7bf..f9c4be8 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -831,20 +831,15 @@ static void __init install_irq_resource(struct 
platform_device *pdev, int irq)
platform_device_add_resources(pdev, , 1);
 }
 
-static void __init sfi_handle_ipc_dev(struct sfi_device_table_entry *entry)
+static void __init sfi_handle_ipc_dev(struct sfi_device_table_entry *pentry,
+   struct devs_id *dev)
 {
-   const struct devs_id *dev = device_ids;
struct platform_device *pdev;
void *pdata = NULL;
 
-   while (dev->name[0]) {
-   if (dev->type == SFI_DEV_TYPE_IPC &&
-   !strncmp(dev->name, entry->name, SFI_NAME_LEN)) {
-   pdata = dev->get_platform_data(entry);
-   break;
-   }
-   dev++;
-   }
+   pr_debug("IPC bus, name = %16.16s, irq = 0x%2x\n",
+   pentry->name, pentry->irq);
+   pdata = dev->get_platform_data(pentry);
 
/*
 * On Medfield the platform device creation is handled by the MSIC
@@ -853,68 +848,94 @@ static void __init sfi_handle_ipc_dev(struct 
sfi_device_table_entry *entry)
if (intel_mid_has_msic())
return;
 
-   pdev = platform_device_alloc(entry->name, 0);
+   pdev = platform_device_alloc(pentry->name, 0);
if (pdev == NULL) {
pr_err("out of memory for SFI platform device '%s'.\n",
-   entry->name);
+   pentry->name);
return;
}
-   install_irq_resource(pdev, entry->irq);
+   install_irq_resource(pdev, pentry->irq);
 
pdev->dev.platform_data = pdata;
intel_scu_device_register(pdev);
 }
 
-static void __init sfi_handle_spi_dev(struct spi_board_info *spi_info)
+static void __init sfi_handle_spi_dev(struct sfi_device_table_entry *pentry,
+   struct devs_id *dev)
 {
-   const struct devs_id *dev = device_ids;
+   struct spi_board_info spi_info;
void *pdata = NULL;
 
-   while (dev->name[0]) {
-   if (dev->type == SFI_DEV_TYPE_SPI &&
-   !strncmp(dev->name, spi_info->modalias,
-   SFI_NAME_LEN)) {
-   pdata = dev->get_platform_data(spi_info);
-   break;
-   }
-   dev++;
-   }
-   spi_info->platform_data = pdata;
+   memset(_info, 0, sizeof(spi_info));
+   strncpy(spi_info.modalias, pentry->name, SFI_NAME_LEN);
+   spi_info.irq = ((pentry->irq == (u8)0xff) ? 0 : pentry->irq);
+   spi_info.bus_num = pentry->host_num;
+   spi_info.chip_select = pentry->addr;
+   spi_info.max_speed_hz = pentry->max_freq;
+   pr_debug("SPI bus=%d, name=%16.16s, irq=0x%2x, max_freq=%d, cs=%d\n",
+   spi_info.bus_num,
+   spi_info.modalias,
+   spi_info.irq,
+   spi_info.max_speed_hz,
+   spi_info.chip_select);
+
+   pdata = dev->get_platform_data(_info);
+
+   spi_info.platform_data = pdata;
if (dev->delay)
-   intel_scu_spi_device_register(spi_info);
+   intel_scu_spi_device_register(_info);
else
-   spi_register_board_info(spi_info, 1);
+   spi_register_board_info(_info, 1);
 }
 
-static void __init sfi_handle_i2c_dev(int bus, struct i2c_board_info *i2c_info)
+static void __init sfi_handle_i2c_dev(struct sfi_device_table_entry *pentry,
+   struct devs_id *dev)
 {
-   const struct devs_id *dev = device_ids;
+   struct i2c_board_info i2c_info;
void *pdata = NULL;
 
+   memset(_info, 0, sizeof(i2c_info));
+   strncpy(i2c_info.type, pentry->name, SFI_NAME_LEN);
+   i2c_info.irq = ((pentry->irq == (u8)0xff) ? 0 : pentry->irq);
+   i2c_info.addr = pentry->addr;
+   pr_debug("I2C bus = %d, name = %16.16s, irq = 0x%2x, addr = 0x%x\n",
+   pentry->host_num,
+   i2c_info.type,
+   i2c_info.irq,
+   i2c_info.addr);
+   pdata = dev->get_platform_data(_info);
+   i2c_info.platform_data = pdata;
+
+   if (dev->delay)
+   

[PATCH v2 01/10] mrst: Fixed printk/pr_* related issues

[David Cohen]

From: Kuppuswamy Sathyanarayanan 

Fixed printk and pr_* related issues in mrst related files.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Signed-off-by: David Cohen 
---
 arch/x86/platform/mrst/early_printk_mrst.c |2 +-
 arch/x86/platform/mrst/mrst.c  |2 +-
 arch/x86/platform/mrst/vrtc.c  |5 ++---
 3 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/arch/x86/platform/mrst/early_printk_mrst.c 
b/arch/x86/platform/mrst/early_printk_mrst.c
index 028454f..95880f7 100644
--- a/arch/x86/platform/mrst/early_printk_mrst.c
+++ b/arch/x86/platform/mrst/early_printk_mrst.c
@@ -213,7 +213,7 @@ static void early_mrst_spi_putc(char c)
}
 
if (!timeout)
-   pr_warning("MRST earlycon: timed out\n");
+   pr_warn("MRST earlycon: timed out\n");
else
max3110_write_data(c);
 }
diff --git a/arch/x86/platform/mrst/mrst.c b/arch/x86/platform/mrst/mrst.c
index 3ca5957..b9aeb54 100644
--- a/arch/x86/platform/mrst/mrst.c
+++ b/arch/x86/platform/mrst/mrst.c
@@ -328,7 +328,7 @@ static inline int __init setup_x86_mrst_timer(char *arg)
else if (strcmp("lapic_and_apbt", arg) == 0)
mrst_timer_options = MRST_TIMER_LAPIC_APBT;
else {
-   pr_warning("X86 MRST timer option %s not recognised"
+   pr_warn("X86 MRST timer option %s not recognised"
   " use x86_mrst_timer=apbt_only or lapic_and_apbt\n",
   arg);
return -EINVAL;
diff --git a/arch/x86/platform/mrst/vrtc.c b/arch/x86/platform/mrst/vrtc.c
index 5e355b1..ca4f7d9 100644
--- a/arch/x86/platform/mrst/vrtc.c
+++ b/arch/x86/platform/mrst/vrtc.c
@@ -79,7 +79,7 @@ void vrtc_get_time(struct timespec *now)
/* vRTC YEAR reg contains the offset to 1972 */
year += 1972;
 
-   printk(KERN_INFO "vRTC: sec: %d min: %d hour: %d day: %d "
+   pr_info("vRTC: sec: %d min: %d hour: %d day: %d "
"mon: %d year: %d\n", sec, min, hour, mday, mon, year);
 
now->tv_sec = mktime(year, mon, mday, hour, min, sec);
@@ -109,8 +109,7 @@ int vrtc_set_mmss(const struct timespec *now)
vrtc_cmos_write(tm.tm_sec, RTC_SECONDS);
spin_unlock_irqrestore(_lock, flags);
} else {
-   printk(KERN_ERR
-  "%s: Invalid vRTC value: write of %lx to vRTC failed\n",
+   pr_err("%s: Invalid vRTC value: write of %lx to vRTC failed\n",
__FUNCTION__, now->tv_sec);
retval = -EINVAL;
}
-- 
1.7.9.5

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

[PATCH v2 05/10] intel_mid: Renamed *mrst* to *intel_mid*

[David Cohen]

From: Kuppuswamy Sathyanarayanan 

mrst is used as common name to represent all intel_mid type
soc's. But moorsetwon is just one of the intel_mid soc. So
renamed them to use intel_mid.

This patch mainly renames the variables and related
functions that uses *mrst* prefix with *intel_mid*.

To ensure that there are no functional changes, I have compared
the objdump of related files before and after rename and found
the only difference is symbol and name changes.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Signed-off-by: David Cohen 
---
 Documentation/kernel-parameters.txt|6 +-
 arch/x86/include/asm/intel-mid.h   |   26 ++---
 arch/x86/include/asm/setup.h   |4 +-
 arch/x86/include/uapi/asm/bootparam.h  |2 +-
 arch/x86/kernel/apb_timer.c|8 +-
 arch/x86/kernel/head32.c   |4 +-
 arch/x86/kernel/rtc.c  |2 +-
 arch/x86/pci/intel_mid_pci.c   |   12 +--
 .../platform/intel-mid/early_printk_intel_mid.c|2 +-
 arch/x86/platform/intel-mid/intel-mid.c|  109 ++--
 arch/x86/platform/intel-mid/intel_mid_vrtc.c   |8 +-
 drivers/platform/x86/intel_scu_ipc.c   |2 +-
 drivers/watchdog/intel_scu_watchdog.c  |2 +-
 13 files changed, 93 insertions(+), 94 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index fcbb736..dfaeb0c 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3471,11 +3471,11 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
default x2apic cluster mode on platforms
supporting x2apic.
 
-   x86_mrst_timer= [X86-32,APBT]
-   Choose timer option for x86 Moorestown MID platform.
+   x86_intel_mid_timer= [X86-32,APBT]
+   Choose timer option for x86 Intel MID platform.
Two valid options are apbt timer only and lapic timer
plus one apbt timer for broadcast timer.
-   x86_mrst_timer=apbt_only | lapic_and_apbt
+   x86_intel_mid_timer=apbt_only | lapic_and_apbt
 
xen_emul_unplug=[HW,X86,XEN]
Unplug Xen emulated devices
diff --git a/arch/x86/include/asm/intel-mid.h b/arch/x86/include/asm/intel-mid.h
index cc79a4f..beb7a5f 100644
--- a/arch/x86/include/asm/intel-mid.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -13,7 +13,7 @@
 
 #include 
 
-extern int pci_mrst_init(void);
+extern int intel_mid_pci_init(void);
 extern int __init sfi_parse_mrtc(struct sfi_table_header *table);
 extern int sfi_mrtc_num;
 extern struct sfi_rtc_table_entry sfi_mrtc_array[];
@@ -25,33 +25,33 @@ extern struct sfi_rtc_table_entry sfi_mrtc_array[];
  * we treat Medfield/Penwell as a variant of Moorestown. Penwell can be
  * identified via MSRs.
  */
-enum mrst_cpu_type {
+enum intel_mid_cpu_type {
/* 1 was Moorestown */
-   MRST_CPU_CHIP_PENWELL = 2,
+   INTEL_MID_CPU_CHIP_PENWELL = 2,
 };
 
-extern enum mrst_cpu_type __mrst_cpu_chip;
+extern enum intel_mid_cpu_type __intel_mid_cpu_chip;
 
 #ifdef CONFIG_X86_INTEL_MID
 
-static inline enum mrst_cpu_type mrst_identify_cpu(void)
+static inline enum intel_mid_cpu_type intel_mid_identify_cpu(void)
 {
-   return __mrst_cpu_chip;
+   return __intel_mid_cpu_chip;
 }
 
 #else /* !CONFIG_X86_INTEL_MID */
 
-#define mrst_identify_cpu()(0)
+#define intel_mid_identify_cpu()(0)
 
 #endif /* !CONFIG_X86_INTEL_MID */
 
-enum mrst_timer_options {
-   MRST_TIMER_DEFAULT,
-   MRST_TIMER_APBT_ONLY,
-   MRST_TIMER_LAPIC_APBT,
+enum intel_mid_timer_options {
+   INTEL_MID_TIMER_DEFAULT,
+   INTEL_MID_TIMER_APBT_ONLY,
+   INTEL_MID_TIMER_LAPIC_APBT,
 };
 
-extern enum mrst_timer_options mrst_timer_options;
+extern enum intel_mid_timer_options intel_mid_timer_options;
 
 /*
  * Penwell uses spread spectrum clock, so the freq number is not exactly
@@ -76,6 +76,6 @@ extern void intel_scu_devices_destroy(void);
 #define MRST_VRTC_MAP_SZ   (1024)
 /*#define MRST_VRTC_PGOFFSET   (0xc00) */
 
-extern void mrst_rtc_init(void);
+extern void intel_mid_rtc_init(void);
 
 #endif /* _ASM_X86_INTEL_MID_H */
diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index 3475554..59bcf4e 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -51,9 +51,9 @@ extern void i386_reserve_resources(void);
 extern void setup_default_timer_irq(void);
 
 #ifdef CONFIG_X86_INTEL_MID
-extern void x86_mrst_early_setup(void);
+extern void x86_intel_mid_early_setup(void);
 #else
-static inline void x86_mrst_early_setup(void) { }
+static inline void x86_intel_mid_early_setup(void) { }
 #endif
 
 #ifdef CONFIG_X86_INTEL_CE
diff --git 

[PATCH] f2fs: fix the starvation problem on cp_rwsem

[Jaegeuk Kim]

This patch removes the logic previously introduced to address the starvation
on cp_rwsem.

One potential there-in bug is that we should cover the wait.list with spin_lock,
but the previous code broke this rule.

And, actually current rwsem handles this starvation issue reasonably, so that we
didn't need to do this before neither.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/f2fs.h  | 13 -
 fs/f2fs/super.c |  1 -
 2 files changed, 14 deletions(-)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index a955a59..308967b 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -18,8 +18,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 
 /*
  * For mount options
@@ -360,7 +358,6 @@ struct f2fs_sb_info {
struct inode *meta_inode;   /* cache meta blocks */
struct mutex cp_mutex;  /* checkpoint procedure lock */
struct rw_semaphore cp_rwsem;   /* blocking FS operations */
-   wait_queue_head_t cp_wait;  /* checkpoint wait queue */
struct mutex node_write;/* locking node writes */
struct mutex writepages;/* mutex for writepages() */
int por_doing;  /* recovery is doing or not */
@@ -516,13 +513,6 @@ static inline void clear_ckpt_flags(struct f2fs_checkpoint 
*cp, unsigned int f)
 
 static inline void f2fs_lock_op(struct f2fs_sb_info *sbi)
 {
-   /*
-* If the checkpoint thread is waiting for cp_rwsem, add cuurent task
-* into wait list to avoid the checkpoint thread starvation
-*/
-   while (!list_empty(>cp_rwsem.wait_list))
-   wait_event_interruptible(sbi->cp_wait,
-   list_empty(>cp_rwsem.wait_list));
down_read(>cp_rwsem);
 }
 
@@ -539,9 +529,6 @@ static inline void f2fs_lock_all(struct f2fs_sb_info *sbi)
 static inline void f2fs_unlock_all(struct f2fs_sb_info *sbi)
 {
up_write(>cp_rwsem);
-
-   /* wake up all tasks blocked by checkpoint */
-   wake_up_all(>cp_wait);
 }
 
 /*
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 539c009..3b786c8 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -841,7 +841,6 @@ static int f2fs_fill_super(struct super_block *sb, void 
*data, int silent)
spin_lock_init(>stat_lock);
init_rwsem(>bio_sem);
init_rwsem(>cp_rwsem);
-   init_waitqueue_head(>cp_wait);
init_sb_info(sbi);
 
/* get an inode for meta space */
-- 
1.8.4.474.g128a96c

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 06/52] tools/perf/build: Split out feature check: 'stackprotector'

[Namhyung Kim]

On Tue,  8 Oct 2013 12:10:36 +0200, Ingo Molnar wrote:
> -ifeq ($(call try-cc,$(SOURCE_HELLO),$(CFLAGS) -Werror 
> -Wstack-protector,-Wstack-protector),y)
> +ifeq ($(feature-stackprotector), 1)
>CFLAGS += -Wstack-protector
>  endif

[SNIP]

> +test-stackprotector:
> + $(BUILD) -Werror -fstack-protector

The flag being checked should be -"W"stack-protector instead of
-"f"stack-protector.  And the gcc manpage says that -Wstack-protector is
only active when -fstack-protector is active.  So the end result should
look like

$(BUILD) -Werror -fstack-protector -Wstack-protector

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

Re: [PATCH 0/6] Optimize the cpu hotplug locking -v2

[Andrew Morton]

On Tue, 08 Oct 2013 12:25:05 +0200 Peter Zijlstra  wrote:

> The current cpu hotplug lock is a single global lock; therefore excluding
> hotplug is a very expensive proposition even though it is rare occurrence 
> under
> normal operation.
> 
> There is a desire for a more light weight implementation of
> {get,put}_online_cpus() from both the NUMA scheduling as well as the -RT side.
> 
> The current hotplug lock is a full reader preference lock -- and thus supports
> reader recursion. However since we're making the read side lock much cheaper 
> it
> is the expectation that it will also be used far more. Which in turn would 
> lead
> to writer starvation.
> 
> Therefore the new lock proposed is completely fair; albeit somewhat expensive
> on the write side. This in turn means that we need a per-task nesting count to
> support reader recursion.

This is a lot of code and a lot of new complexity.  It needs some pretty
convincing performance numbers to justify its inclusion, no?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] hotplug: Optimize {get,put}_online_cpus()

[Andrew Morton]

On Tue, 08 Oct 2013 12:25:06 +0200 Peter Zijlstra  wrote:

> The current implementation of get_online_cpus() is global of nature
> and thus not suited for any kind of common usage.
> 
> Re-implement the current recursive r/w cpu hotplug lock such that the
> read side locks are as light as possible.
> 
> The current cpu hotplug lock is entirely reader biased; but since
> readers are expensive there aren't a lot of them about and writer
> starvation isn't a particular problem.
> 
> However by making the reader side more usable there is a fair chance
> it will get used more and thus the starvation issue becomes a real
> possibility.
> 
> Therefore this new implementation is fair, alternating readers and
> writers; this however requires per-task state to allow the reader
> recursion.

Obvious question: can't we adapt lglocks for this?  It would need the
counter in task_struct to permit reader nesting, but what else is
needed?

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

[PATCHv2 3/3] ARM: dts: exynos4x12: Add maudio/gps_alive power domain for exynos4x12

[Chanwoo Choi]

This patch maudio/gps_alive power domain to exynos4x12.dtsi.

Signed-off-by: Chanwoo Choi 
Signed-off-by: Kyungmin Park 
---
Changes since v1:
- Fix GPS_ALIVE power domain's register address

 arch/arm/boot/dts/exynos4x12.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
b/arch/arm/boot/dts/exynos4x12.dtsi
index ad531fe..d265047 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -35,6 +35,16 @@
reg = <0x10023CA0 0x20>;
};
 
+   pd_maudio: maudio-power-domain@10023CC0 {
+   compatible = "samsung,exynos4210-pd";
+   reg = <0x10023CC0 0x20>;
+   };
+
+   pd_gps_alive: gps-alive-power-domain@10023D00 {
+   compatible = "samsung,exynos4210-pd";
+   reg = <0x10023D00 0x20>;
+   };
+
clock: clock-controller@1003 {
compatible = "samsung,exynos4412-clock";
reg = <0x1003 0x2>;
-- 
1.8.0

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

[PATCHv2 2/3] ARM: dts: exynos4212: Add missing clock for multi core timer

[Chanwoo Choi]

From: Marek Szyprowski 

Signed-off-by: Marek Szyprowski 
Signed-off-by: Kyungmin Park 
---
Changes since v1:
- No change

 arch/arm/boot/dts/exynos4212.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4212.dtsi 
b/arch/arm/boot/dts/exynos4212.dtsi
index 3081bae..d7a3fbc 100644
--- a/arch/arm/boot/dts/exynos4212.dtsi
+++ b/arch/arm/boot/dts/exynos4212.dtsi
@@ -43,6 +43,8 @@
interrupt-parent = <_map>;
interrupts = <0 0>, <1 0>, <2 0>, <3 0>,
 <4 0>, <5 0>;
+   clocks = < 3>, < 344>;
+   clock-names = "fin_pll", "mct";
 
mct_map: mct-map {
#interrupt-cells = <2>;
-- 
1.8.0

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

[PATCHv2 1/3] ARM: dts: exynos4212: Add PMU dt data for pmu-irq

[Chanwoo Choi]

Signed-off-by: Chanwoo Choi 
Signed-off-by: Kyungmin Park 
---
Changes since v1:
- No change

 arch/arm/boot/dts/exynos4212.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4212.dtsi 
b/arch/arm/boot/dts/exynos4212.dtsi
index 6f34d7f..3081bae 100644
--- a/arch/arm/boot/dts/exynos4212.dtsi
+++ b/arch/arm/boot/dts/exynos4212.dtsi
@@ -56,4 +56,10 @@
<0x5 0  1 12 0>;
};
};
+
+   pmu {
+   compatible = "arm,cortex-a9-pmu";
+   interrupt-parent = <>;
+   interrupts = <2 2>, <3 2>;
+   };
 };
-- 
1.8.0

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

[PATCHv2 0/3] ARM: dts: exynos: Add missing dt data to bring up kernel feature

[Chanwoo Choi]

This patchset add missing dt data to bring up kernel feature
- MAUDIO/GPS_ALIVE power domain
- PMU
- Clock data for Multi core timer

Changes since v1:
- Fix wrong address of GPS_ALIVE power domain

Chanwoo Choi (2):
  ARM: dts: exynos4212: Add PMU dt data for pmu-irq
  ARM: dts: exynos4x12: Add maudio/gps_alive power domain for exynos4x12

Marek Szyprowski (1):
  ARM: dts: exynos4212: Add missing clock for multi core timer

 arch/arm/boot/dts/exynos4212.dtsi |  8 
 arch/arm/boot/dts/exynos4x12.dtsi | 10 ++
 2 files changed, 18 insertions(+)

-- 
1.8.0

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

Re: [PATCH 03/52] tools/perf/build: Add 'autodep' functionality, generate feature test dependencies automatically

[Namhyung Kim]

On Tue,  8 Oct 2013 12:10:33 +0200, Ingo Molnar wrote:
> +-include *.d */*.d

Hmm.. this */*.d part is really needed?

> +
>  ###
>  
>  clean:
> - rm -f $(FILES)
> + rm -f $(FILES) *.d

If so, at least it'd be deleted from here IMHO.

Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tools/perf/build: Fix redirection printouts

[Ingo Molnar]

* Arnaldo Carvalho de Melo  wrote:

> So while merging what I have in my perf/core branch I got to Vitillo's, as
> peterz called it, "inlining" of addr2line, i.e. using libbfd to do that work,
> it will look if lbfd is in EXTLIBS and if so, use it, otherwise we continue
> exec'in the addr2line tool.
> 
> Since this appears when doing the feature check:
> 
> ...libbfd: [ on  ]
> 
> I wanted to build just one object file that is related to this:
> 
> [acme@sandy linux]$ ls -la /tmp/build/perf/util/util/srcline.o
> ls: cannot access /tmp/build/perf/util/util/srcline.o: No such file or 
> directory
> [acme@sandy linux]$ ls -la tools/perf/util/srcline.c 
> -rw-rw-r--. 1 acme acme 1777 Oct  9 16:06 tools/perf/util/srcline.c
> [acme@sandy linux]$ ls -la tools/perf/util/srcline.*
> -rw-rw-r--. 1 acme acme 1777 Oct  9 16:06 tools/perf/util/srcline.c
> [acme@sandy linux]$ make V=1 O=/tmp/build/perf -C tools/perf/ util/srcline.o
> make: Entering directory `/home/acme/git/linux/tools/perf'
> BUILD: Doing 'make -j8' parallel build
> # Redirected target util/srcline.o => /tmp/build/perf/util/util/srcline.o
> make: Leaving directory `/home/acme/git/linux/tools/perf'
> [acme@sandy linux]$ 
> [acme@sandy linux]$ ls -la /tmp/build/perf/util/util/srcline.o
> ls: cannot access /tmp/build/perf/util/util/srcline.o: No such file or 
> directory
> [acme@sandy linux]$ make V=1 O=/tmp/build/perf -C tools/perf/ 
> /tmp/build/perf/util/util/srcline.o
> make: Entering directory `/home/acme/git/linux/tools/perf'
> BUILD: Doing 'make -j8' parallel build
> make[1]: *** No rule to make target `/tmp/build/perf/util/util/srcline.o'.  
> Stop.
> make: *** [/tmp/build/perf/util/util/srcline.o] Error 2
> make: Leaving directory `/home/acme/git/linux/tools/perf'
> [acme@sandy linux]$ ls -la tools/perf/util/srcline.*
> -rw-rw-r--. 1 acme acme 1777 Oct  9 16:06 tools/perf/util/srcline.c
> [acme@sandy linux]$
> 
>   What am I doing wrong here while trying to build just one .o file?
> 
>   Back to checking why it is not using the 'inline' addr2line...
> 
> - Arnaldo

There's two things that I can see here.

1)

The printout is a bit off, duplicating util/util. The fix below should 
help with that.

2)

This issue is more difficult: if tools/perf/util/srcline.o exists, then 
the redirection will not happen and make just says:

 comet:~/tip/tools/perf> rm -f /tmp/build/perf/util/pager.o
 comet:~/tip/tools/perf> make O=/tmp/build/perf/ util/pager.o
 make: `util/pager.o' is up to date.

 comet:~/tip/tools/perf> ll /tmp/build/perf/util/pager.o
 ls: cannot access /tmp/build/perf/util/pager.o: No such file or directory
 comet:~/tip/tools/perf> ll util/pager.o
 -rw-rw-r-- 1 mingo mingo 297488 Oct 10 07:34 util/pager.o

So the redirection quirks will only work in a clean tree. I think that 
should be fine - people who build via O= generally do it to keep their 
source trees clean.

Thanks,

Ingo

==>
>From 881641d16f8445d8796c3b437cb33d6467af98b7 Mon Sep 17 00:00:00 2001
From: Ingo Molnar 
Date: Thu, 10 Oct 2013 07:36:52 +0200
Subject: [PATCH] tools/perf/bench: Fix redirection printouts

Fix the duplicate util/util printout Arnaldo reported:

   $ make V=1 O=/tmp/build/perf -C tools/perf/ util/srcline.o
   ...
   # Redirected target util/srcline.o => 
/tmp/build/perf/util/util/srcline.o

Reported-by: Arnaldo Carvalho de Melo 
Cc: Peter Zijlstra 
Cc: Namhyung Kim 
Cc: David Ahern 
Cc: Jiri Olsa 
Signed-off-by: Ingo Molnar 
---
 tools/perf/Makefile.perf | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index ee97778..2d55480 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -585,11 +585,11 @@ ifneq ($(OUTPUT),)
 %.o: $(OUTPUT)%.o
@echo "# Redirected target $@ => $(OUTPUT)$@"
 util/%.o: $(OUTPUT)util/%.o
-   @echo "# Redirected target $@ => $(OUTPUT)util/$@"
+   @echo "# Redirected target $@ => $(OUTPUT)$@"
 bench/%.o: $(OUTPUT)bench/%.o
-   @echo "# Redirected target $@ => $(OUTPUT)bench/$@"
+   @echo "# Redirected target $@ => $(OUTPUT)$@"
 tests/%.o: $(OUTPUT)tests/%.o
-   @echo "# Redirected target $@ => $(OUTPUT)tests/$@"
+   @echo "# Redirected target $@ => $(OUTPUT)$@"
 endif
 
 # These two need to be here so that when O= is not used they take precedence
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 02/52] tools/perf/build: Add feature check core code

[Namhyung Kim]

Hi Ingo,

On Tue,  8 Oct 2013 12:10:32 +0200, Ingo Molnar wrote:
> +feature_check = $(eval $(feature_check_code)); $(info CHK: 
> config/feature-checks/test-$(1))
> +define feature_check_code
> +  feature-$(2) := $(shell make -C config/feature-checks test-$1 >/dev/null 
> 2>/dev/null && echo 1 || echo 0)
> +endef
> +
> +#
> +# Build the feature check binaries in parallel, ignore errors, ignore return 
> value and suppress output:
> +#
> +$(info Testing features:)
> +$(shell make -i -j -C config/feature-checks >/dev/null 2>&1)
> +$(info done)
> +
> +FEATURE_TESTS = hello
> +
> +$(foreach test,$(FEATURE_TESTS),$(call feature_check,$(test),$(test)))

So as far as I can see, all the feature checking goes twice - once in
$(shell make ...) and another in $(foreach test,...).  They look like
doing exactly same thing.  And the final Makefile in this series still
has it twice.  Is it intentional or did I miss something?

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

LOAN OFFER

[info]

We are European Loan service,Do you need a Loan,contact Via  
(europanl...@foxmail.com)



This message was sent using IMP, the Internet Messaging Program.

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

Re: [PATCH V6 02/15] ARM: OMAP2+: AM33XX: add lateinit hook for calling pm late init

[Joel Fernandes]

On 10/09/2013 06:24 PM, Nishanth Menon wrote:
> Call OMAP2+ generic lateinit hook from AM specific late init hook.
> This allows the generic late initializations such as cpufreq hooks
> to be active.
> 
> Cc: Benoit Cousson 
> Cc: Kevin Hilman 
> Cc: Paul Walmsley 
> Cc: Tony Lindgren 
> Signed-off-by: Nishanth Menon 
> ---
>  arch/arm/mach-omap2/board-generic.c |1 +
>  arch/arm/mach-omap2/common.h|1 +
>  arch/arm/mach-omap2/io.c|6 ++
>  3 files changed, 8 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/board-generic.c 
> b/arch/arm/mach-omap2/board-generic.c
> index 87162e1..b474498 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -180,6 +180,7 @@ DT_MACHINE_START(AM33XX_DT, "Generic AM33XX (Flattened 
> Device Tree)")
>   .init_irq   = omap_intc_of_init,
>   .handle_irq = omap3_intc_handle_irq,
>   .init_machine   = omap_generic_init,
> + .init_late  = am33xx_init_late,

Instead of adding a new a *_init_late function for every platform, perhaps
better to just do:
.init_late  = omap2_common_pm_late_init;

since that's the only function you're calling.

Later if more functions are added, then it can be wrapped around.

regards,

-Joel





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

Avoid needless loop in sdhci_irq() for Card Interrupt

[Alexey Neyman]

Hi all,

I've discovered that the sdhci_irq() function needlessly iterates re-reading 
the interrupt status and doing nothing (until it runs out of max_loops) when 
it handles the "Card Interrupt" status in the interrupt status register.

The reason is that the "Card Interrupt" bit is not cleared until the 
sdhci_irq() calls mmc_signal_sdio_irq(), so if Card Interrupt was asserted, 
re-reading the interrupt status will find this bit set over and over, even if 
no other bits are reported.

The fix: ignore Card Interrupt bits in the interrupt status if we already know 
that mmc_signal_sdio_irq() is going to be called at the end of sdhci_irq().

Signed-off-by: Alexey Neyman 
commit 7f23315b344ca51ddf22a78f326f88404fa8c81d
Author: Alexey Neyman 
Date:   Wed Oct 9 22:23:54 2013 -0700

Avoid a loop in sdhci.c.

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 7a7fb4f..a83cd1b 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2491,6 +2491,14 @@ again:
 	result = IRQ_HANDLED;
 
 	intmask = sdhci_readl(host, SDHCI_INT_STATUS);
+
+	/*
+	 * If we know we'll call the driver to signal SDIO IRQ, disregard
+	 * further indications of Card Interrupt in the status to avoid a
+	 * needless loop.
+	 */
+	if (cardint)
+		intmask &= ~SDHCI_INT_CARD_INT;
 	if (intmask && --max_loops)
 		goto again;
 out:

Re: [PATCH v4 1/4] backlight: introduce backlight_device_registered

[Jani Nikula]

On Thu, 10 Oct 2013, Aaron Lu  wrote:
> On 10/10/2013 12:29 PM, Jani Nikula wrote:
>> On Thu, 10 Oct 2013, Aaron Lu  wrote:
>>> On 10/10/2013 08:25 AM, Rafael J. Wysocki wrote:
 On Tuesday, October 08, 2013 02:39:58 PM Aaron Lu wrote:
> +bool backlight_device_registered(enum backlight_type type)
> +{
> + bool found = false;
> + struct backlight_device *bd;
> +
> + mutex_lock(_list_mutex);
> + list_for_each_entry(bd, _list_head, entry) {
> + if (bd->props.type == type) {
> + found = true;
> + break;
> + }
> + }

 Isn't it useful to be able to register more than one backlight device of 
 the
 same type sometimes?
>>>
>>> I think so for some kind of computers. OTOH, the above function should
>>> be enough for the problem we are solving here, if someday we need to
>>> differentiate, we can enhance the code then.
>> 
>> Since both Baytrail and Haswell already have two backlight PWMs, this
>> may be needed sooner than you think. But we shouldn't let that block
>
> Do we need to differentiate which backlight PWM is registered to decide
> if ACPI video backlight interface should be skipped? My understanding is
> no.

That's correct. If things change, we can fix it then.

Jani.


>
> Thanks,
> Aaron
>
>> fixing the more urgent issue we have now. So I'm fine with this. It
>> doesn't prevent one from registering more than one device of the same
>> type anyway.
>> 
>> BR,
>> Jani.
>> 
>> 
>> 
>

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

Re: [PATCH 1/2] clk/zynq/clkc: Add 'fclk-enable' feature

[Michal Simek]

On 10/09/2013 05:25 PM, Sören Brinkmann wrote:
> On Tue, Oct 08, 2013 at 04:38:17PM +0100, Mark Rutland wrote:
>> On Tue, Oct 08, 2013 at 03:36:11PM +0100, Soren Brinkmann wrote:
>>> In some use cases Zynq's FPGA clocks are used as static clock
>>> generators for IP in the FPGA part of the SOC for which no Linux driver
>>> exists and would control those clocks. To avoid automatic
>>> gating of these clocks in such cases a new property - fclk-enable - is
>>> added to the clock controller's DT description to accomodate such use
>>> cases. It's value is a bitmask, where a set bit results in enabling
>>> the corresponding FCLK through the clkc.
>>>
>>> FPGA clocks are handled following the rules below:
>>>
>>> If an FCLK is not enabled by bootloaders, that FCLK will be disabled in
>>> Linux. Drivers can enable and control it through the CCF as usual.
>>>
>>> If an FCLK is enabled by bootloaders AND the corresponding bit in the
>>> 'fclk-enable' DT property is set, that FCLK will be enabled by the clkc,
>>> resulting in an off by one reference count for that clock. Ensuring it
>>> will always be running.
>>>
>>> The default value for 'fclk-enable' is '0xf' (all FCLK's enabled by the
>>> bootloader are enabled through the clkc.
>>
>> Why? Juding by the diff that's not what the code currently does, so why
>> not leave it as 0, and only set it where required as a work-around?
> The default is set as described here:
> [...]
>>> +   ret = of_property_read_u32(np, "fclk-enable", _enable);
>>> +   if (ret)
>>> +   fclk_enable = 0xf;
>>> +
> 
> The default has been chosen this way, because it avoids trouble with
> customers. Customers expect the FPGA clocks to be running, once they
> configured them in the FPGA tools. If Linux gates them off for some
> reason, it creates confusion and often ends up in customer support.
> But in general I agree. It is kind of a work around and having zero as
> default would be desirable. I'd leave this to Michal.

No problem to have default value setup to 0. And use this workaround
when it is set in DTS.

Thanks,
Michal

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




signature.asc
Description: OpenPGP digital signature

Re: [PATCH v7 1/5] ARM: add basic support for Trusted Foundations

[Michal Simek]

On 10/10/2013 01:45 AM, Olof Johansson wrote:
> On Tue, Oct 8, 2013 at 1:17 AM, Michal Simek  wrote:
>> Hi,
>>
>> On 10/04/2013 06:37 PM, Alexandre Courbot wrote:
>>> Trusted Foundations is a TrustZone-based secure monitor for ARM that
>>> can be invoked using the same SMC-based API on all supported
>>> platforms. This patch adds initial basic support for Trusted
>>> Foundations using the ARM firmware API. Current features are limited
>>> to the ability to boot secondary processors.
>>>
>>> Note: The API followed by Trusted Foundations does *not* follow the SMC
>>> calling conventions. It has nothing to do with PSCI neither and is only
>>> relevant to devices that use Trusted Foundations (like most Tegra-based
>>> retail devices).
>>>
>>> Signed-off-by: Alexandre Courbot 
>>> Reviewed-by: Tomasz Figa 
>>> Reviewed-by: Stephen Warren 
>>> ---
>>>  .../arm/firmware/tl,trusted-foundations.txt| 17 +
>>>  .../devicetree/bindings/vendor-prefixes.txt|  1 +
>>>  arch/arm/Kconfig   |  2 +
>>>  arch/arm/Makefile  |  1 +
>>>  arch/arm/firmware/Kconfig  | 28 
>>>  arch/arm/firmware/Makefile |  1 +
>>>  arch/arm/firmware/trusted_foundations.c| 77 
>>> ++
>>>  arch/arm/include/asm/trusted_foundations.h | 64 ++
>>>  8 files changed, 191 insertions(+)
>>>  create mode 100644 
>>> Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundations.txt
>>>  create mode 100644 arch/arm/firmware/Kconfig
>>>  create mode 100644 arch/arm/firmware/Makefile
>>>  create mode 100644 arch/arm/firmware/trusted_foundations.c
>>>  create mode 100644 arch/arm/include/asm/trusted_foundations.h
>>>
>>> diff --git 
>>> a/Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundations.txt 
>>> b/Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundations.txt
>>> new file mode 100644
>>> index 000..3954bbd
>>> --- /dev/null
>>> +++ 
>>> b/Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundations.txt
>>> @@ -0,0 +1,17 @@
>>> +Trusted Foundations
>>> +
>>> +Boards that use the Trusted Foundations secure monitor can signal its
>>> +presence by declaring a node compatible with "tl,trusted-foundations"
>>> +under the root node.
>>> +
>>> +Required properties:
>>> +- compatible : "tl,trusted-foundations"
>>> +- version-major : major version number of Trusted Foundations firmware
>>> +- version-minor: minor version number of Trusted Foundations firmware
>>> +
>>> +Example:
>>> + firmware {
>>> + compatible = "tl,trusted-foundations";
>>> + version-major = <2>;
>>> + version-minor = <8>;
>>> + };
>>
>> This is just another example how to add sw description to dts.
>> I have briefly looked at tegra20.dtsi and there are IPs like timer, intc, etc
>> which are in the DTS without any bus.
>>
>> Add this firmware node to the root is just +1 case to this mess
>> but IMHO will be good to have specific DT part which will be used for
>> this sw setting which are coming to DTS all the time.
>>
>> Grant, Rob: Where is the proper location for these type of description?
> 
> Usually we've been using the /firmware hierarchy for these kind of things.
> 
> Chrome OS uses /firmware/chromeos for some of the information passing
> from FW to the OS.
> 
> You might want a separate node under /firmware for this, since this is
> "just" the secure runtime portion of things, there might be need to
> add things for/from the bootloader too.

Is this documented somewhere? I mean that firmware node should be used for this.

Thanks,
Michal

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




signature.asc
Description: OpenPGP digital signature

Re: [PATCH V2 0/6] perf: New conditional branch filter

[Anshuman Khandual]

On 09/26/2013 04:44 PM, Stephane Eranian wrote:
> So you are saying that the HW filter is exclusive. That seems odd. But
> I think it is
> because of the choices is ANY. ANY covers all the types of branches. Therefore
> it does not make a difference whether you add COND or not. And
> vice-versa, if you
> set COND, you need to disable ANY. I bet if you add other filters such
> as CALL, RETURN,
> then you could OR them and say: I want RETURN or CALLS.
> 
> But that's okay. The API operates in OR mode but if the HW does not
> support it, you
> can check the mask and reject if more than one type is set. That is
> arch-specific code.
> The alternative, if to only capture ANY and emulate the filter in SW.
> This will work, of
> course. But the downside, is that you lose the way to appreciate how
> many, for instance,
> COND branches you sampled out of the total number of COND branches
> retired. Unless
> you can count COND branches separately.

Hey Stephane,

Thanks for your reply. I am working on a solution where PMU will process
all the requested branch filters in HW only if it can filter all of them in an
OR manner else it will just leave the entire thing upto the SW to process and
do no filtering itself. This implies that branch filtering will either happen
completely in HW or completely in SW and never in a mixed manner. This way
it will conform to the OR mode defined in the API. I will post the revised
patch set soon.

Regards
Anshuman

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 25/29] arc: use common of_flat_dt_match_machine

[Vineet Gupta]

On 10/09/2013 10:35 PM, Rob Herring wrote:
> Thanks. I've added this in and updated my branch. Please double check
> it when you have a chance. I also made __arch_info_begin[] and
> __arch_info_end[] const.

Works great !

Thx,
-Vineet
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/9] rwsem performance optimizations

[Davidlohr Bueso]

On Wed, 2013-10-09 at 20:14 -0700, Linus Torvalds wrote:
> On Wed, Oct 9, 2013 at 12:28 AM, Peter Zijlstra  wrote:
> >
> > The workload that I got the report from was a virus scanner, it would
> > spawn nr_cpus threads and {mmap file, scan content, munmap} through your
> > filesystem.
> 
> So I suspect we could make the mmap_sem write area *much* smaller for
> the normal cases.
> 
> Look at do_mmap_pgoff(), for example: it is run entirely under
> mmap_sem, but 99% of what it does doesn't actually need the lock.
> 
> The part that really needs the lock is
> 
> addr = get_unmapped_area(file, addr, len, pgoff, flags);
> addr = mmap_region(file, addr, len, vm_flags, pgoff);
> 
> but we hold it over all the other stuff too.
> 

True. By looking at the callers, we're always doing:

down_write(>mmap_sem);
do_mmap_pgoff()
...
up_write(>mmap_sem);

That goes for shm, aio, and of course mmap_pgoff().

While I know you hate two level locking, one way to go about this is to
take the lock inside do_mmap_pgoff() after the initial checks (flags,
page align, etc.) and return with the lock held, leaving the caller to
unlock it. 

> In fact, even if we moved the mmap_sem down into do_mmap(), and moved
> code around a bit to only hold it over those functions, it would still
> cover unnecessarily much. For example, while merging is common, not
> merging is pretty common too, and we do that
> 
> vma = kmem_cache_zalloc(vm_area_cachep, GFP_KERNEL);
> 
> allocation under the lock. We could easily do things like preallocate
> it outside the lock.
> 

AFAICT there are also checks that should be done at the beginning of the
function, such as checking for MAP_LOCKED and VM_LOCKED flags before
calling get_unmapped_area().

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: SDIV / UDIV Question

[Wang, Yalin]

Hi  Will ,


Oh ,  I see ,
Thanks for your clarification !
So R-class cores will not run linux ?
This means we don't  need  care about this .
Am I right ?

Thank you .

-Original Message-
From: Will Deacon [mailto:will.dea...@arm.com] 
Sent: Wednesday, October 09, 2013 6:54 PM
To: Wang, Yalin
Cc: 'linux-arm-msm-ow...@vger.kernel.org'; linux-kernel@vger.kernel.org
Subject: Re: SDIV / UDIV Question

On Wed, Oct 09, 2013 at 08:08:05AM +0100, Wang, Yalin wrote:
> I have a question about sdiv/ udiv  instructions :
> In  armv7 A/R  TRM, it said sdiv/udiv will cause Divide by zero as 
> undefined exception or just return zero (decided by implementation) .
> 
> So  in kernel ,  should we need register a undef hook to Get this 
> undef exception and send SIGFPE to user space Process ?

As far as I can see, this can only happen for R-class cores, based on SCTLR.DZ.

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

Re: [PATCH] perf: disable mmap2 support

[Ingo Molnar]

* Arnaldo Carvalho de Melo  wrote:

> Em Wed, Oct 09, 2013 at 06:17:43PM +0200, Stephane Eranian escreveu:

> > This patch disables the mmap2 record format support for now. The 
> > support needs a bit more work to cover VM_CLONE cases.
> > 
> > The patch leaves attr->mmap2 defined, but returns an error if it is 
> > set. That ensures no PERF_RECORD_MMAP2 record can be generated. Yet it 
> > minimizes the reverts in the perf tool.
> 
> Would be interesting to have a simple new tool that would detect all the 
> mmaps that are shared in a given perf.data file, using the 
> PERF_RECORD_MMAP2 information, and that tool should come together with 
> the reworked kernel ABI, showing how it is used.

Indeed. Let's make that a requirement for the next round of mmap2 patches. 

Issues like this is really why I hate not getting a fully functional 
usecase together with a new ABI - it's _so_ easy to come up with something 
subtly (or not so subtly) incomplete.

> A 'perf test' entry, based on the test programs you guys are using to 
> test this functionality would be even better, showing that all cases 
> you've been striving to cover are in fact covered by the new ABI.

That too, in addition to an actual tool that people can use.

Thanks,

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

Re: [RFC][PATCH] x86: Lazy disabling of interrupts

[Ingo Molnar]

* Andi Kleen  wrote:

> - That said, I think a software CLI/STI is somewhat useful for 
> profiling, as it can allow to measure how long interrupts are delayed by 
> CLI/STI. [...]

That could be measured directly in a simpler way, without disrupting 
CLI/STI: by turning all IRQs into NMIs and resending them from a special 
NMI handler. (and of course timestamping the NMI arrival time and the IRQ 
entry time so that instrumentation can recover it.)

If indirect, statistical measurement suffices then IRQ delivery latencies 
can also be estimated statistically without any kernel changes: by 
profiling IRQ disable/enable sections (there's a counter for that), 
calculating average IRQ-disable section length from that. The average IRQ 
delay will be 50% of that value, assuming normal distribution of IRQs. 
This should be good enough for most cases.

Thanks,

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

Re: [PATCH v4 1/4] backlight: introduce backlight_device_registered

[Aaron Lu]

On 10/10/2013 12:29 PM, Jani Nikula wrote:
> On Thu, 10 Oct 2013, Aaron Lu  wrote:
>> On 10/10/2013 08:25 AM, Rafael J. Wysocki wrote:
>>> On Tuesday, October 08, 2013 02:39:58 PM Aaron Lu wrote:
 +bool backlight_device_registered(enum backlight_type type)
 +{
 +  bool found = false;
 +  struct backlight_device *bd;
 +
 +  mutex_lock(_list_mutex);
 +  list_for_each_entry(bd, _list_head, entry) {
 +  if (bd->props.type == type) {
 +  found = true;
 +  break;
 +  }
 +  }
>>>
>>> Isn't it useful to be able to register more than one backlight device of the
>>> same type sometimes?
>>
>> I think so for some kind of computers. OTOH, the above function should
>> be enough for the problem we are solving here, if someday we need to
>> differentiate, we can enhance the code then.
> 
> Since both Baytrail and Haswell already have two backlight PWMs, this
> may be needed sooner than you think. But we shouldn't let that block

Do we need to differentiate which backlight PWM is registered to decide
if ACPI video backlight interface should be skipped? My understanding is
no.

Thanks,
Aaron

> fixing the more urgent issue we have now. So I'm fine with this. It
> doesn't prevent one from registering more than one device of the same
> type anyway.
> 
> BR,
> Jani.
> 
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RESEND] timer stats: reset entries when disable the timer usage statistics

[John Stultz]

On 10/09/2013 09:35 PM, Ingo Molnar wrote:
> * Dong Zhu  wrote:
>
>> From f41628c61d8a9172677ba33a55b61e37ce28f7a6 Mon Sep 17 00:00:00 2001
>> From: Dong Zhu  
>> Date: Thu, 10 Oct 2013 10:38:13 +0800
>>
>> When we stop timer statistics collection (via echo 0 > 
>> /proc/timers_stats), the statistics data is still exported as if it were 
>> correct, which can cause applicaitons to misuse the statistics.
> What misuse do you mean?
>
>> This patch resets the statistics when we stop collecting them, to avoid 
>> this problem.
> Well, this loses the handy 'snapshot' property of /proc/timer_stats. 
> Before this change one could do:
>
>   echo 1 > /proc/timers_stats
>   sleep 60 # run system workload
>   echo 0 > /proc/timers_stats
>
> and examine the 1-minute collection result without it changing. Your 
> change, if I understand it correctly, zeroes it all out.


Good point. I misunderstood the patch and thought it was an issue that
the statistics are never cleared even if the collection was disabled,
but looking closer I see we clear on enable (if we were disabled). So
yes, this change doesn't seem right.



> Instead of this change I'd suggest adding a 'status' line, with two 
> outputs:
>
>   Status: collection active
>
>   Status: collection disabled

Agreed.

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

Re: [GIT PULL] More timekeeping items for 3.13

[John Stultz]

On 10/09/2013 09:30 PM, Ingo Molnar wrote:
> Pulled into tip:timers/core, thanks John!
>
> One small detail I noticed, in commit 07783397c:
>
> Cc: Linus Walleij 
> Acked-by: Linus Walleij 
>
> Please remove the Cc: line in such cases in the future.

Ah, yes. I'll try to be more careful about that. Sorry!

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

Re: [PATCH] MAINTAINERS: Add arch/x86/pci to PCI file patterns

[Ingo Molnar]

* Bjorn Helgaas  wrote:

> On Wed, Oct 9, 2013 at 3:02 PM, Bjorn Helgaas  wrote:
> > I handle many arch/x86/pci changes, so help those patches get to the
> > PCI patchwork.
> >
> > Signed-off-by: Bjorn Helgaas 
> 
> I'll merge this via the PCI tree unless anybody objects.

Acked-by: Ingo Molnar 

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RESEND] timer stats: reset entries when disable the timer usage statistics

[Ingo Molnar]

* Dong Zhu  wrote:

> From f41628c61d8a9172677ba33a55b61e37ce28f7a6 Mon Sep 17 00:00:00 2001
> From: Dong Zhu  
> Date: Thu, 10 Oct 2013 10:38:13 +0800
> 
> When we stop timer statistics collection (via echo 0 > 
> /proc/timers_stats), the statistics data is still exported as if it were 
> correct, which can cause applicaitons to misuse the statistics.

What misuse do you mean?

> This patch resets the statistics when we stop collecting them, to avoid 
> this problem.

Well, this loses the handy 'snapshot' property of /proc/timer_stats. 
Before this change one could do:

echo 1 > /proc/timers_stats
sleep 60 # run system workload
echo 0 > /proc/timers_stats

and examine the 1-minute collection result without it changing. Your 
change, if I understand it correctly, zeroes it all out.

Instead of this change I'd suggest adding a 'status' line, with two 
outputs:

Status: collection active

Status: collection disabled

Thanks,

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

Re: [PATCH v4 1/4] backlight: introduce backlight_device_registered

[Jani Nikula]

On Thu, 10 Oct 2013, Aaron Lu  wrote:
> On 10/10/2013 08:25 AM, Rafael J. Wysocki wrote:
>> On Tuesday, October 08, 2013 02:39:58 PM Aaron Lu wrote:
>>> +bool backlight_device_registered(enum backlight_type type)
>>> +{
>>> +   bool found = false;
>>> +   struct backlight_device *bd;
>>> +
>>> +   mutex_lock(_list_mutex);
>>> +   list_for_each_entry(bd, _list_head, entry) {
>>> +   if (bd->props.type == type) {
>>> +   found = true;
>>> +   break;
>>> +   }
>>> +   }
>> 
>> Isn't it useful to be able to register more than one backlight device of the
>> same type sometimes?
>
> I think so for some kind of computers. OTOH, the above function should
> be enough for the problem we are solving here, if someday we need to
> differentiate, we can enhance the code then.

Since both Baytrail and Haswell already have two backlight PWMs, this
may be needed sooner than you think. But we shouldn't let that block
fixing the more urgent issue we have now. So I'm fine with this. It
doesn't prevent one from registering more than one device of the same
type anyway.

BR,
Jani.



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

Re: [GIT PULL] More timekeeping items for 3.13

[Ingo Molnar]

* John Stultz  wrote:

> Hey Thomas,
> Just wanted to send along the few minor time related items I've got
> left for 3.13.
> 
> * Small cleanup in the clocksource code.
> 
> * Fix for rtc-pl031 to let it work with alarmtimers
> 
> * Move arm64 to using the generic sched_clock framework & resulting
> cleanup in the generic sched_clock code.
> 
> 
> thanks
> -john
> 
> 
> The following changes since commit 389e067032fbb96e439abafae848dd447e4cafb4:
> 
>   Merge branch 'fortglx/3.12/time' into fortglx/3.13/time (2013-09-16
> 18:54:07 -0700)
> 
> are available in the git repository at:
> 
> 
>   git://git.linaro.org/people/jstultz/linux.git fortglx/3.13/time
> 
> for you to fetch changes up to b4042ceaabbd913bc5b397ddd1e396eeb312d72f:
> 
>   sched_clock: Remove sched_clock_func() hook (2013-10-09 16:54:39 -0700)
> 
> 
> Elad Wexler (1):
>   clocksource: Fix 'ret' data type of sysfs_override_clocksource()
> and sysfs_unbind_clocksource()
> 
> John Stultz (1):
>   rtc: rtc-pl031: Set wakeup flag prior to registering rtcdev
> 
> Stephen Boyd (2):
>   arch_timer: Move to generic sched_clock framework
>   sched_clock: Remove sched_clock_func() hook
> 
>  arch/arm/kernel/arch_timer.c | 14 --
>  arch/arm64/Kconfig   |  1 +
>  arch/arm64/kernel/time.c | 10 --
>  drivers/clocksource/arm_arch_timer.c | 10 ++
>  drivers/rtc/rtc-pl031.c  |  3 +--
>  include/linux/sched_clock.h  |  2 --
>  kernel/time/clocksource.c|  4 ++--
>  kernel/time/sched_clock.c|  9 +
>  8 files changed, 15 insertions(+), 38 deletions(-)

Pulled into tip:timers/core, thanks John!

One small detail I noticed, in commit 07783397c:

Cc: Linus Walleij 
Acked-by: Linus Walleij 

Please remove the Cc: line in such cases in the future.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] video: da8xx-fb: remove unwanted define

[Manish Badarkhe]

Remove unwanted define "WSI_TIMEOUT" present in code.

Signed-off-by: Manish Badarkhe 
---
:100644 100644 e030e17... fa61323... M  drivers/video/da8xx-fb.c
 drivers/video/da8xx-fb.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index e030e17..fa61323 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -129,7 +129,6 @@
 
 #define LCD_NUM_BUFFERS2
 
-#define WSI_TIMEOUT50
 #define PALETTE_SIZE   256
 
 #defineCLK_MIN_DIV 2
-- 
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: [XFS on bad superblock] BUG: unable to handle kernel NULL pointer dereference at 00000003

[Dave Chinner]

On Thu, Oct 10, 2013 at 11:38:34AM +0800, Fengguang Wu wrote:
> On Thu, Oct 10, 2013 at 11:33:00AM +0800, Fengguang Wu wrote:
> > On Thu, Oct 10, 2013 at 11:26:37AM +0800, Fengguang Wu wrote:
> > > Dave,
> > > 
> > > > I note that you have CONFIG_SLUB=y, which means that the cache slabs
> > > > are shared with objects of other types. That means that the memory
> > > > corruption problem is likely to be caused by one of the other
> > > > filesystems that is probing the block device(s), not XFS.
> > > 
> > > Good to know that, it would easy to test then: just turn off every
> > > other filesystems. I'll try it right away.
> > 
> > Seems that we don't even need to do that. A dig through the oops
> > database and I find stack dumps from other FS.
> > 
> > This happens in the kernel with same kconfig and commit 3.12-rc1.
> 
> Here is a summary of all FS with oops:
> 
> 411 ocfs2_fill_super
> 189 xfs_fs_fill_super
>  86 jfs_fill_super
>  50 isofs_fill_super
>  33 fat_fill_super
>  18 vfat_fill_super
>  15 msdos_fill_super
>  11 ext2_fill_super
>  10 ext3_fill_super
>   3 reiserfs_fill_super

The order of probing on the original dmesg output you reported is:

ext3
ext2
fatfs
reiserfs
gfs2
isofs
ocfs2

which means that no XFS filesystem was mounted in the original bug
report, and hence that further indicates that XFS is not responsible
for the problem and that perhaps the original bisect was not
reliable...

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/

sysfs for my chips

[Benjamin Herrenschmidt]

Hi Greg !

(random CC list of clueful people)

On some new powerpc platforms (non-hypervisor or rather linux is the
hypervisor), I want to expose a bunch of stuff per "chip", the chips
being currently the processor chips and the "centaurs" (think of them as
the bottom half of the memory controllers).

Among other, I want a sysfs file in there to access "xscom" on the chip
which is a sideband bus used for low level stuff (think jtag on steroid)
which we can use, among others, for chip health monitoring, general
debugging and diagnostics, etc...

I might add more such as VPD, model information, etc... later or at
least a link to corresponding device-tree node.

How do you suggest I expose that ? So far I've been thinking about
something like

/sys/chips/{processor,centaur}/chip#/files

or to avoid namespace clashes

/sys/firmware/chips/{processor,centaur}/chip#/files

Or maybe just

/sys/firmware/chips/chip#/files

(the chip type can be inferred from the chip#, they use the same space
at least as far my firmware exposes them to Linux)

(the actual access to xscom goes via firmware tho it makes *some* sense)

But I could instead create platform devices corresponding to the
device-tree representation of each of those chips ... and have the
platform devices contain the magic attributes. That's a bit more
convoluted though.

What's the current trend of the day for that sort of thing ? I'd rather
avoid yet-another-chardev-with-ioctl's here ...

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: [RFC][PATCH] x86: Lazy disabling of interrupts

[David Miller]

From: Steven Rostedt 
Date: Thu, 10 Oct 2013 00:11:53 -0400

> 
> I'm replying to my email to see if that helps make it to LKML. If it
> doesn't, I'm sorry for the noise to all I Cc'd.

The problem is the:

H.PeterAnvin

in the CC list, you can't have a name with the "." charater it appear in
email headers unless the string is surrounded by double quotes.  Otherwise
it's a syntax error.

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

Re: [PATCH net-next] fib_trie: only calc for the un-first node

[David Miller]

From: baker.ker...@gmail.com
Date: Tue,  8 Oct 2013 11:36:51 +0800

> From: "baker.zhang" 
> 
> This is a enhancement.
> 
> for the first node in fib_trie, newpos is 0, bit is 1.
> Only for the leaf or node with unmatched key need calc pos.
> 
> Signed-off-by: baker.zhang 

The compiler is probably doing this transformation all by itself,
but applied anyways, 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 3/5] drm/bridge: Add PTN3460 bridge driver

[Inki Dae]

> -Original Message-
> From: Mark Brown [mailto:broo...@kernel.org]
> Sent: Thursday, October 10, 2013 3:29 AM
> To: Inki Dae
> Cc: Olof Johansson; Sean Paul; devicet...@vger.kernel.org; linux-samsung-
> s...@vger.kernel.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; DRI mailing list; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH 3/5] drm/bridge: Add PTN3460 bridge driver
> 
> On Fri, Oct 04, 2013 at 11:05:48AM +0900, Inki Dae wrote:
> > 2013/10/4 Olof Johansson :
> 
> > > "If PD_N is LOW, then the device is in Deep power-down completely,
> > > even if supply rail is ON; for the device to be able to operate, the
> > > PD_N pin must be HIGH."
> 
> > I still think the pin could be replaced with a regulator. But
> > lvds-bridge node has "powerdown-gpio" property - it say this board
> > will use gpio pin - specific to board.  So it seems no problem.
> 
> No, don't model things that aren't regulators as regulators - it's just
> confusing from a usability standpoint and causes breakage when the pins
> don't behave like regulators.

It seems that there was your missing point. That _is not_ what I mentioned.
I mean that other boards can use a regulator instead of gpio pin.




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

[GIT PULL] More timekeeping items for 3.13

[John Stultz]

Hey Thomas,
Just wanted to send along the few minor time related items I've got
left for 3.13.

* Small cleanup in the clocksource code.

* Fix for rtc-pl031 to let it work with alarmtimers

* Move arm64 to using the generic sched_clock framework & resulting
cleanup in the generic sched_clock code.


thanks
-john


The following changes since commit 389e067032fbb96e439abafae848dd447e4cafb4:

  Merge branch 'fortglx/3.12/time' into fortglx/3.13/time (2013-09-16
18:54:07 -0700)

are available in the git repository at:


  git://git.linaro.org/people/jstultz/linux.git fortglx/3.13/time

for you to fetch changes up to b4042ceaabbd913bc5b397ddd1e396eeb312d72f:

  sched_clock: Remove sched_clock_func() hook (2013-10-09 16:54:39 -0700)


Elad Wexler (1):
  clocksource: Fix 'ret' data type of sysfs_override_clocksource()
and sysfs_unbind_clocksource()

John Stultz (1):
  rtc: rtc-pl031: Set wakeup flag prior to registering rtcdev

Stephen Boyd (2):
  arch_timer: Move to generic sched_clock framework
  sched_clock: Remove sched_clock_func() hook

 arch/arm/kernel/arch_timer.c | 14 --
 arch/arm64/Kconfig   |  1 +
 arch/arm64/kernel/time.c | 10 --
 drivers/clocksource/arm_arch_timer.c | 10 ++
 drivers/rtc/rtc-pl031.c  |  3 +--
 include/linux/sched_clock.h  |  2 --
 kernel/time/clocksource.c|  4 ++--
 kernel/time/sched_clock.c|  9 +
 8 files changed, 15 insertions(+), 38 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 3/3] ARM: dts: exynos4x12: Add maudio/gps_alive power domain for exynos4x12

[Chanwoo Choi]

On 10/10/2013 01:05 PM, Chanwoo Choi wrote:
> On 10/10/2013 12:29 PM, Sachin Kamat wrote:
>> On 10 October 2013 06:00, Chanwoo Choi  wrote:
>>> This patch maudio/gps_alive power domain to exynos4x12.dtsi.
>>>
>>> Signed-off-by: Chanwoo Choi 
>>> Signed-off-by: Kyungmin Park 
>>> ---
>>>  arch/arm/boot/dts/exynos4x12.dtsi | 10 ++
>>>  1 file changed, 10 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
>>> b/arch/arm/boot/dts/exynos4x12.dtsi
>>> index ad531fe..c04418e 100644
>>> --- a/arch/arm/boot/dts/exynos4x12.dtsi
>>> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
>>> @@ -35,6 +35,16 @@
>>> reg = <0x10023CA0 0x20>;
>>> };
>>>
>>> +   pd_maudio: maudio-power-domain@10023CC0 {
>>> +   compatible = "samsung,exynos4210-pd";
>>> +   reg = <0x10023CC0 0x20>;
>>> +   };
>>> +
>>> +   pd_gps_alive: gps-alive-power-domain@10023D04 {
>>> +   compatible = "samsung,exynos4210-pd";
>>> +   reg = <0x10023D00 0x20>;
>>
>> There is mismatch between node name and register value.
>>
>>
> What is exactly mismatch?
> 
> I checked the register address of 
> MAUDIO_CONFIGURATION/GPS_ALIVE_CONFIGURATION regsiter.
> - MAUDIO_CONFIGURATION 0x1002_3CC0
> - GPS_ALIVE_CONFIGURATION 0x1002_3D00

My mistake. I write wrong address about gps-alive-power-domain.

I will fix it.
- gps-alive-power-domain@10023D04 -> gps-alive-power-domain@10023D00

Thanks,
Chanwoo Choi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ARM: dts: exynos4x12: Add maudio/gps_alive power domain for exynos4x12

[Chanwoo Choi]

On 10/10/2013 12:29 PM, Sachin Kamat wrote:
> On 10 October 2013 06:00, Chanwoo Choi  wrote:
>> This patch maudio/gps_alive power domain to exynos4x12.dtsi.
>>
>> Signed-off-by: Chanwoo Choi 
>> Signed-off-by: Kyungmin Park 
>> ---
>>  arch/arm/boot/dts/exynos4x12.dtsi | 10 ++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
>> b/arch/arm/boot/dts/exynos4x12.dtsi
>> index ad531fe..c04418e 100644
>> --- a/arch/arm/boot/dts/exynos4x12.dtsi
>> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
>> @@ -35,6 +35,16 @@
>> reg = <0x10023CA0 0x20>;
>> };
>>
>> +   pd_maudio: maudio-power-domain@10023CC0 {
>> +   compatible = "samsung,exynos4210-pd";
>> +   reg = <0x10023CC0 0x20>;
>> +   };
>> +
>> +   pd_gps_alive: gps-alive-power-domain@10023D04 {
>> +   compatible = "samsung,exynos4210-pd";
>> +   reg = <0x10023D00 0x20>;
> 
> There is mismatch between node name and register value.
> 
> 
What is exactly mismatch?

I checked the register address of MAUDIO_CONFIGURATION/GPS_ALIVE_CONFIGURATION 
regsiter.
- MAUDIO_CONFIGURATION 0x1002_3CC0
- GPS_ALIVE_CONFIGURATION 0x1002_3D00


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RESEND] timer stats: reset entries when disable the timer usage statistics

[John Stultz]

On 10/09/2013 07:59 PM, Dong Zhu wrote:
> From f41628c61d8a9172677ba33a55b61e37ce28f7a6 Mon Sep 17 00:00:00 2001
> From: Dong Zhu  
> Date: Thu, 10 Oct 2013 10:38:13 +0800
>
> When we stop timer statistics collection (via echo 0 >
> /proc/timers_stats), the statistics data is still exported as if it were
> correct, which can cause applicaitons to misuse the statistics.
>
> This patch resets the statistics when we stop collecting them, to avoid
> this problem.
>
> Signed-off-by: Dong Zhu 
> ---
>  kernel/time/timer_stats.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/kernel/time/timer_stats.c b/kernel/time/timer_stats.c
> index 0b537f2..43f05e7 100644
> --- a/kernel/time/timer_stats.c
> +++ b/kernel/time/timer_stats.c
> @@ -371,6 +371,7 @@ static ssize_t tstats_write(struct file *file, const char 
> __user *buf,
>   switch (ctl[0]) {
>   case '0':
>   if (timer_stats_active) {
> + reset_entries();
>   timer_stats_active = 0;
>   time_stop = ktime_get();
>   sync_access();

This looks ok to me. Thomas, do you have any objections here?

thanks
-john

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

Re: [RFC][PATCH] x86: Lazy disabling of interrupts

[Steven Rostedt]

On Wed, 09 Oct 2013 23:39:28 -0400 (EDT)
David Miller  wrote:

> From: Steven Rostedt 
> Date: Wed, 9 Oct 2013 20:36:27 -0400
> 
> > I don't know why my email never reached LKML, was there something about
> > it that prevented it from going? The total character length was 46,972,
> > well below the 100,000 limit. Also the Cc list wasn't that big. Did my
> > ISP get flagged as a spam bot or something?
> > 
> > I can bounce it to you to see what was wrong with it.
> 
> That's odd, can you try sending it to the list again?  I'll watch
> very carefully for a bounce.
> 

I just sent it as a redirect to LKML. Hopefully that worked.

Thanks,

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 02/15] rtc: rtc-88pm860x: use dev_get_platdata()

[Haojian Zhuang]

On 23 September 2013 17:40, Jingoo Han  wrote:
> Use the wrapper function for retrieving the platform data instead of
> accessing dev->platform_data directly. This is a cosmetic change
> to make the code simpler and enhance the readability.
>
> Signed-off-by: Jingoo Han 
> ---
>  drivers/rtc/rtc-88pm860x.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/rtc/rtc-88pm860x.c b/drivers/rtc/rtc-88pm860x.c
> index 4e30c85..81650484 100644
> --- a/drivers/rtc/rtc-88pm860x.c
> +++ b/drivers/rtc/rtc-88pm860x.c
> @@ -316,7 +316,7 @@ static int pm860x_rtc_probe(struct platform_device *pdev)
> unsigned long ticks = 0;
> int ret;
>
> -   pdata = pdev->dev.platform_data;
> +   pdata = dev_get_platdata(>dev);
>
> info = devm_kzalloc(>dev, sizeof(struct pm860x_rtc_info),
> GFP_KERNEL);
> --
> 1.7.10.4
>
>

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

Re: [RFC][PATCH] x86: Lazy disabling of interrupts

[David Miller]

From: Steven Rostedt 
Date: Wed, 9 Oct 2013 20:36:27 -0400

> I don't know why my email never reached LKML, was there something about
> it that prevented it from going? The total character length was 46,972,
> well below the 100,000 limit. Also the Cc list wasn't that big. Did my
> ISP get flagged as a spam bot or something?
> 
> I can bounce it to you to see what was wrong with it.

That's odd, can you try sending it to the list again?  I'll watch
very carefully for a bounce.

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: [XFS on bad superblock] BUG: unable to handle kernel NULL pointer dereference at 00000003

[Fengguang Wu]

On Thu, Oct 10, 2013 at 11:33:00AM +0800, Fengguang Wu wrote:
> On Thu, Oct 10, 2013 at 11:26:37AM +0800, Fengguang Wu wrote:
> > Dave,
> > 
> > > I note that you have CONFIG_SLUB=y, which means that the cache slabs
> > > are shared with objects of other types. That means that the memory
> > > corruption problem is likely to be caused by one of the other
> > > filesystems that is probing the block device(s), not XFS.
> > 
> > Good to know that, it would easy to test then: just turn off every
> > other filesystems. I'll try it right away.
> 
> Seems that we don't even need to do that. A dig through the oops
> database and I find stack dumps from other FS.
> 
> This happens in the kernel with same kconfig and commit 3.12-rc1.

Here is a summary of all FS with oops:

411 ocfs2_fill_super
189 xfs_fs_fill_super
 86 jfs_fill_super
 50 isofs_fill_super
 33 fat_fill_super
 18 vfat_fill_super
 15 msdos_fill_super
 11 ext2_fill_super
 10 ext3_fill_super
  3 reiserfs_fill_super

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

Re: [XFS on bad superblock] BUG: unable to handle kernel NULL pointer dereference at 00000003

[Fengguang Wu]

On Thu, Oct 10, 2013 at 11:26:37AM +0800, Fengguang Wu wrote:
> Dave,
> 
> > I note that you have CONFIG_SLUB=y, which means that the cache slabs
> > are shared with objects of other types. That means that the memory
> > corruption problem is likely to be caused by one of the other
> > filesystems that is probing the block device(s), not XFS.
> 
> Good to know that, it would easy to test then: just turn off every
> other filesystems. I'll try it right away.

Seems that we don't even need to do that. A dig through the oops
database and I find stack dumps from other FS.

This happens in the kernel with same kconfig and commit 3.12-rc1.

[   51.205369] block nbd1: Attempted send on closed socket
[   51.214126] BUG: unable to handle kernel NULL pointer dereference at 0004
[   51.215640] IP: [] pool_mayday_timeout+0x5f/0x9c
[   51.216262] *pdpt = 0ca90001 *pde =  
[   51.216262] Oops:  [#1] 
[   51.216262] CPU: 0 PID: 644 Comm: mount Not tainted 3.12.0-rc1 #2
[   51.216262] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[   51.216262] task: ccffd7a0 ti: cca54000 task.ti: cca54000
[   51.216262] EIP: 0060:[] EFLAGS: 0046 CPU: 0
[   51.216262] EIP is at pool_mayday_timeout+0x5f/0x9c
[   51.216262] EAX:  EBX: c1a81d50 ECX:  EDX: 
[   51.216262] ESI: cd0d303c EDI: cfff7054 EBP: cca55d2c ESP: cca55d18
[   51.216262]  DS: 007b ES: 007b FS:  GS: 0033 SS: 0068
[   51.216262] CR0: 8005003b CR2: 0004 CR3: 0ca0b000 CR4: 06b0
[   51.216262] DR0:  DR1:  DR2:  DR3: 
[   51.216262] DR6:  DR7: 
[   51.216262] Stack:
[   51.216262]  c1a81d60 cd0d303c 0100 c103439c cca55d58 cca55d3c c102cd96 
c1ba4700
[   51.216262]  cca55d58 cca55d6c c102cf7e c1a81d50 c1ba5110 c1ba4f10 cca55d58 
c103439c
[   51.216262]  cca55d58 cca55d58 0001 c1ba4588 0100 cca55d90 c1028f61 
0001
[   51.216262] Call Trace:
[   51.216262]  [] ? need_to_create_worker+0x32/0x32
[   51.216262]  [] call_timer_fn.isra.39+0x16/0x60
[   51.216262]  [] run_timer_softirq+0x144/0x15e
[   51.216262]  [] ? need_to_create_worker+0x32/0x32
[   51.216262]  [] __do_softirq+0x87/0x12b
[   51.216262]  [] irq_exit+0x3a/0x48
[   51.216262]  [] do_IRQ+0x64/0x77
[   51.216262]  [] common_interrupt+0x2c/0x31
[   51.216262]  [] ? ocfs2_get_sector+0x14/0x1cd
[   51.216262]  [] ocfs2_sb_probe+0xcb/0x7ca
[   51.216262]  [] ? bdi_lock_two+0x8/0x14
[   51.216262]  [] ? string.isra.4+0x26/0x89
[   51.216262]  [] ocfs2_fill_super+0x39/0xe84
[   51.216262]  [] ? pointer.isra.15+0x23f/0x25b
[   51.216262]  [] ? disk_name+0x20/0x65
[   51.216262]  [] mount_bdev+0x105/0x14d
[   51.216262]  [] ? slab_pre_alloc_hook.isra.66+0x1e/0x25
[   51.216262]  [] ? __kmalloc_track_caller+0xb8/0xe4
[   51.216262]  [] ? alloc_vfsmnt+0xdc/0xff
[   51.216262]  [] ocfs2_mount+0x10/0x12
[   51.216262]  [] ? ocfs2_handle_error+0xa2/0xa2
[   51.216262]  [] mount_fs+0x55/0x123
[   51.216262]  [] vfs_kern_mount+0x44/0xac
[   51.216262]  [] do_mount+0x647/0x768
[   51.216262]  [] ? strndup_user+0x2c/0x3d
[   51.216262]  [] SyS_mount+0x71/0xa0
[   51.216262]  [] syscall_call+0x7/0xb
[   51.216262] Code: 43 44 e8 7a 8c ff ff 58 5a 5b 5e 5f 5d c3 8b 43 10 8d 78 
fc 8d 43 10 89 45 ec 8d 47 04 3b 45 ec 74 ca 89 f8 e8 44 f0 ff ff 89 c1 <8b> 50 
04 83 7a 44 00 74 2c 8b 40 68 8d 71 68 39 f0 75 22 8b 72
[   51.216262] EIP: [] pool_mayday_timeout+0x5f/0x9c SS:ESP 
0068:cca55d18
[   51.216262] CR2: 0004
[   51.216262] ---[ end trace 267272283b2d7610 ]---
[   51.216262] Kernel panic - not syncing: Fatal exception in interrupt

[3.244964] block nbd1: Attempted send on closed socket
[3.246243] block nbd1: Attempted send on closed socket
[3.247508] (mount,661,0):ocfs2_get_sector:1861 ERROR: status = -5
[3.248906] (mount,661,0):ocfs2_sb_probe:770 ERROR: status = -5
[3.250269] (mount,661,0):ocfs2_fill_super:1038 ERROR: superblock probe 
failed!
[3.252100] (mount,661,0):ocfs2_fill_super:1229 ERROR: status = -5
[3.253569] BUG: unable to handle kernel NULL pointer dereference at 0004
[3.255322] IP: [] process_one_work+0x1a/0x1cc
[3.256681] *pdpt = 0c950001 *pde =  
[3.256833] Oops:  [#1] 
[3.256833] CPU: 0 PID: 5 Comm: kworker/0:0H Not tainted 3.12.0-rc1 #2
[3.256833] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[3.256833] task: cec44d80 ti: cec54000 task.ti: cec54000
[3.256833] EIP: 0060:[] EFLAGS: 00010046 CPU: 0
[3.256833] EIP is at process_one_work+0x1a/0x1cc
[3.256833] EAX:  EBX: cec1b900 ECX: ccdf0700 EDX: ccdf0700
[3.256833] ESI: ccdf0754 EDI: c1a81d50 EBP: cec55f44 ESP: cec55f2c
[3.256833]  DS: 007b ES: 007b FS:  GS:  SS: 0068
[3.256833] CR0: 8005003b CR2: 005c CR3: 0cfc5000 CR4: 06b0
[3.256833] Stack:
[3.256833]  c1a81d50  c10345b0 cec1b900 cec1b918 cec1b918 cec55f54 
c1034a1d
[3.256833]  cec1b900 c1a81d50 cec55f70 c1034d3b 

Re: [PATCH 3/3] ARM: dts: exynos4x12: Add maudio/gps_alive power domain for exynos4x12

[Sachin Kamat]

On 10 October 2013 06:00, Chanwoo Choi  wrote:
> This patch maudio/gps_alive power domain to exynos4x12.dtsi.
>
> Signed-off-by: Chanwoo Choi 
> Signed-off-by: Kyungmin Park 
> ---
>  arch/arm/boot/dts/exynos4x12.dtsi | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
> b/arch/arm/boot/dts/exynos4x12.dtsi
> index ad531fe..c04418e 100644
> --- a/arch/arm/boot/dts/exynos4x12.dtsi
> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
> @@ -35,6 +35,16 @@
> reg = <0x10023CA0 0x20>;
> };
>
> +   pd_maudio: maudio-power-domain@10023CC0 {
> +   compatible = "samsung,exynos4210-pd";
> +   reg = <0x10023CC0 0x20>;
> +   };
> +
> +   pd_gps_alive: gps-alive-power-domain@10023D04 {
> +   compatible = "samsung,exynos4210-pd";
> +   reg = <0x10023D00 0x20>;

There is mismatch between node name and register value.


-- 
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: [XFS on bad superblock] BUG: unable to handle kernel NULL pointer dereference at 00000003

[Fengguang Wu]

Dave,

> I note that you have CONFIG_SLUB=y, which means that the cache slabs
> are shared with objects of other types. That means that the memory
> corruption problem is likely to be caused by one of the other
> filesystems that is probing the block device(s), not XFS.

Good to know that, it would easy to test then: just turn off every
other filesystems. I'll try it right away.

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

Re: [PATCH v8 0/9] rwsem performance optimizations

[Linus Torvalds]

On Wed, Oct 9, 2013 at 12:28 AM, Peter Zijlstra  wrote:
>
> The workload that I got the report from was a virus scanner, it would
> spawn nr_cpus threads and {mmap file, scan content, munmap} through your
> filesystem.

So I suspect we could make the mmap_sem write area *much* smaller for
the normal cases.

Look at do_mmap_pgoff(), for example: it is run entirely under
mmap_sem, but 99% of what it does doesn't actually need the lock.

The part that really needs the lock is

addr = get_unmapped_area(file, addr, len, pgoff, flags);
addr = mmap_region(file, addr, len, vm_flags, pgoff);

but we hold it over all the other stuff too.

In fact, even if we moved the mmap_sem down into do_mmap(), and moved
code around a bit to only hold it over those functions, it would still
cover unnecessarily much. For example, while merging is common, not
merging is pretty common too, and we do that

vma = kmem_cache_zalloc(vm_area_cachep, GFP_KERNEL);

allocation under the lock. We could easily do things like preallocate
it outside the lock.

Right now mmap_sem covers pretty much the whole system call (we do do
some security checks outside of it).

I think the main issue is that nobody has ever cared deeply enough to
see how far this could be pushed. I suspect there is some low-hanging
fruit for anybody who is willing to handle the pain..

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

Re: [XFS on bad superblock] BUG: unable to handle kernel NULL pointer dereference at 00000003

[Dave Chinner]

On Thu, Oct 10, 2013 at 09:41:17AM +0800, Fengguang Wu wrote:
> On Thu, Oct 10, 2013 at 09:16:40AM +0800, Fengguang Wu wrote:
> > On Thu, Oct 10, 2013 at 11:59:00AM +1100, Dave Chinner wrote:
> > > [add x...@oss.sgi.com to cc]
> > 
> > Thanks.
> > 
> > To help debug the problem, I searched XFS in my tests' oops database
> > and find one kernel that failed 4 times (out of 12 total boots) with
> > basically the same error:
> > 
> >   4 BUG: sleeping function called from invalid context at 
> > kernel/workqueue.c:2810
> >   1 WARNING: CPU: 1 PID: 372 at lib/debugobjects.c:260 
> > debug_print_object+0x94/0xa2()
> >   1 WARNING: CPU: 1 PID: 360 at lib/debugobjects.c:260 
> > debug_print_object+0x94/0xa2()
> >   1 WARNING: CPU: 0 PID: 381 at lib/debugobjects.c:260 
> > debug_print_object+0x94/0xa2()
> >   1 WARNING: CPU: 0 PID: 361 at lib/debugobjects.c:260 
> > debug_print_object+0x94/0xa2()
> 

Fenguang, I'll having real trouble associating these with the XFS
code path that is seeing the problems. These look like a use after
free or a double free, but that isn't possible in the XFS code paths
that are showing up in the traces.

> And some other messages in an older kernel:
> 
> [   39.004416] F2FS-fs (nbd2): unable to read second superblock
> [   39.005088] XFS: Assertion failed: read && bp->b_ops, file: 
> fs/xfs/xfs_buf.c, line: 1036

This can not possibily occur on the superblock read path, as
bp->b_ops in that case is *always* initialised, as is XBF_READ.

So this implies something else has modified the struct xfs_buf.

> [   41.550471] [ cut here ]
> [   41.550476] WARNING: CPU: 1 PID: 878 at lib/list_debug.c:33 
> __list_add+0xac/0xc0()
> [   41.550478] list_add corruption. prev->next should be next 
> (88000f3d7360), but was   (null). (prev=880008786a30).

And this is a smoking gun - list corruption...

> [   41.550481] CPU: 1 PID: 878 Comm: mount Not tainted 
> 3.11.0-rc1-00667-gf70eb07 #64
> [   41.550482] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [   41.550485]  0009 880007d6fb08 824044a1 
> 880007d6fb50
> [   41.550488]  880007d6fb40 8109a0a8 880007c6b530 
> 88000f3d7360
> [   41.550491]  880008786a30 0007  
> 880007d6fba0
> [   41.550491] Call Trace:
> [   41.550499]  [] dump_stack+0x4e/0x82
> [   41.550503]  [] warn_slowpath_common+0x78/0xa0
> [   41.550505]  [] warn_slowpath_fmt+0x4c/0x50
> [   41.550509]  [] ? get_lock_stats+0x19/0x60
> [   41.550511]  [] __list_add+0xac/0xc0
> [   41.550515]  [] insert_work+0x43/0xa0
> [   41.550518]  [] __queue_work+0x11b/0x510
> [   41.550520]  [] queue_work_on+0x96/0xa0
> [   41.550526]  [] ? _xfs_buf_ioend.constprop.15+0x26/0x30
> [   41.550529]  [] xfs_buf_ioend+0x15c/0x260

... in the workqueue code on a work item in the the struct xfs_buf .

> [   41.550531]  [] ? xfsbdstrat+0x22/0x170
> [   41.550534]  [] _xfs_buf_ioend.constprop.15+0x26/0x30
> [   41.550537]  [] xfs_buf_iorequest+0x73/0x1a0
> [   41.550539]  [] xfsbdstrat+0x22/0x170
> [   41.550542]  [] xfs_buf_read_uncached+0x72/0xa0
> [   41.550546]  [] xfs_readsb+0x176/0x250

... in the very context that we allocated the struct xfs_buf. It's
not a use after free or memory corruption caused by XFS you are
seeing here.

I note that you have CONFIG_SLUB=y, which means that the cache slabs
are shared with objects of other types. That means that the memory
corruption problem is likely to be caused by one of the other
filesystems that is probing the block device(s), not XFS.

Cheers,

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

Re: RFC: (re-)binding the VFIO platform driver to a platform device

[Kim Phillips]

On Wed, 9 Oct 2013 15:03:19 -0500
Scott Wood  wrote:

> On Wed, 2013-10-09 at 14:44 -0500, Yoder Stuart-B08248 wrote:
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, October 09, 2013 2:22 PM
> > > 
> > > On Wed, 2013-10-09 at 14:02 -0500, Yoder Stuart-B08248 wrote:
> > > > Have been thinking about this issue some more.  As Scott mentioned,

thanks for bringing this up again.

> > > There's already a "bool suppress_bind_attrs" to prevent sysfs
> > > bind/unbind.  I suggested a similar flag to mean the oppsosite -- bind
> > > *only* through sysfs.  Greg KH was skeptical and wanted to see a patch
> > > before any further discussion.
> > 
> > Ah, think I understand now...yes that works as well, and would be
> > less intrustive.   So are you writing a patch? :)
> 
> I've been meaning to since the previous round of discussion, but I've
> been busy.  Would someone else be able to test it in the context of
> using it for VFIO?

yes - see below.

> Otherwise, that looks about right, for the driver side (though
> driver_attach could error out earlier rather than testing it inside the
> loop).

I've made the changes you suggested and tested the resulting diff below
on an arndale board.  I successfully performed the following sequence of
commands after first changing the i2c@12C8 node in the device tree
to be exclusively compatible with "vfio":

===
# ls -l /sys/bus/platform/drivers/vfio-platform/
total 0
--w--- 1 root root 4096 Sep 24 19:17 bind
--w--- 1 root root 4096 Sep 24 19:13 uevent
--w--- 1 root root 4096 Sep 24 19:18 unbind
# ls -l /sys/bus/platform/drivers/s3c-i2c
total 0
lrwxrwxrwx 1 root root0 Sep 24 19:11 12c6.i2c -> 
../../../../devices/12c6.i2c
lrwxrwxrwx 1 root root0 Sep 24 19:11 12c9.i2c -> 
../../../../devices/12c9.i2c
lrwxrwxrwx 1 root root0 Sep 24 19:20 12ce.i2c -> 
../../../../devices/12ce.i2c
--w--- 1 root root 4096 Sep 24 19:18 bind
--w--- 1 root root 4096 Sep 24 19:11 uevent
--w--- 1 root root 4096 Sep 24 19:17 unbind
# ls -l /sys/devices/12c8.i2c/driver  # this is the one with the 'vfio' 
compatible
ls: cannot access /sys/devices/12c8.i2c/driver: No such file or directory
# ls -l /sys/devices/12ce.i2c/driver
lrwxrwxrwx 1 root root 0 Sep 24 19:18 /sys/devices/12ce.i2c/driver -> 
../../bus/platform/drivers/s3c-i2c
# echo 12ce.i2c > /sys/bus/platform/drivers/s3c-i2c/unbind
# ls -l /sys/devices/12ce.i2c/driver
ls: cannot access /sys/devices/12ce.i2c/driver: No such file or directory
# echo 12ce.i2c > /sys/bus/platform/drivers/vfio-platform/bind
# ls -l /sys/devices/12ce.i2c/driver
lrwxrwxrwx 1 root root 0 Sep 24 19:21 /sys/devices/12ce.i2c/driver -> 
../../bus/platform/drivers/vfio-platform
# echo 12ce.i2c > /sys/bus/platform/drivers/vfio-platform/unbind
# ls -l /sys/devices/12ce.i2c/driver
# echo 12ce.i2c > /sys/bus/platform/drivers/s3c-i2c/bind
[  722.137524] s3c-i2c 12ce.i2c: slave address 0x38
[  722.141037] s3c-i2c 12ce.i2c: bus frequency set to 65 KHz
[  722.150605] s3c-i2c 12ce.i2c: i2c-8: S3C I2C adapter
# ls -l /sys/devices/12ce.i2c/driver
lrwxrwxrwx 1 root root 0 Sep 24 19:21 /sys/devices/12ce.i2c/driver -> 
../../bus/platform/drivers/s3c-i2c
# 


so it's correctly not allowing 'vfio' driver to bind to a device tree
compatible it's declared, and it then can bind the i2c @ 12ce device
to the vfio-platform driver, and unbind and bind it back to the i2c
driver.

For clarity's sake, before this diff, the command:

echo 12ce.i2c > /sys/bus/platform/drivers/vfio-platform/bind

would error with:

echo: write error: No such device

> The other half of fixing the raciness is to ensure that the device
> doesn't get bound back to a non-VFIO driver (e.g. due to a module load
> or new_id).  The solution I proposed for that was a similar
> explicit-bind-only flag for a device, that the user sets through sysfs
> prior to unbinding.  This would also be useful in non-VFIO contexts to
> simply say "I don't want to use this device at all".

I can take a look at doing this if you're still busy.

Thanks,

Kim

diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index 73f6c29..da81442 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -201,7 +201,8 @@ static ssize_t bind_store(struct device_driver *drv, const 
char *buf,
int err = -ENODEV;
 
dev = bus_find_device_by_name(bus, NULL, buf);
-   if (dev && dev->driver == NULL && driver_match_device(drv, dev)) {
+   if (dev && dev->driver == NULL && (drv->sysfs_bind_only ||
+  driver_match_device(drv, dev))) {
if (dev->parent)/* Needed for USB */
device_lock(dev->parent);
device_lock(dev);
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 35fa368..6f85279 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -389,7 +389,7 @@ static int __device_attach(struct 

[BUG] kdump won't work if invalid TSS fault happens in irq context

[Xishi Qiu]

I write a module, and find kdump can't boot in the following case.
Kernel version is 3.4.24, Intel(R) Xeon(R) CPU  E5620, and kernel v3.12 
has the same problem too.

Here is the code:
struct timer_list g_timer;

void tmrhnd_invtssfault(unsigned long data)
{
long __res;
printk(KERN_EMERG "invalid TSS fault in interrupt context.\n");
__asm__ volatile("int $0x0A" : "=a"(__res):);
}

{
...
init_timer(_timer);
g_timer.expires = jiffies + 10;
g_timer.data = 0;
g_timer.function = tmrhnd_invtssfault;
add_timer(_timer);
...
}

Here is the log:
[   87.801066] kpgenm: invalid TSS fault in interrupt context.
[   87.976956] BUG: unable to handle kernel paging request at 81467489
[   87.983979] IP: [] down_read_trylock+0x10/0x20
[   87.990017] PGD 1a0d067 PUD 1a11063 PMD 14001e1 
[   87.994708] Oops: 0003 [#1] SMP 
[   87.997985] CPU 2 
[   87.999833] Modules linked in: kpgen(O) igb(O) netmap_lin(O) megaraid_sas 
sr_mod mpt2sas raid_class uhci_hcd usb_storage ide_cd_mod ide_core mptctl 
mptsas ata_piix acpi_cpufreq mperf tg3 usbhid hid nfs lockd fscache auth_rpcgss 
nfs_acl sunrpc cdrom scsi_transport_sas e1000 mptscsih mptbase ipmi_devintf 
ipmi_msghandler ext2 ac dm_mod af_packet af_key zlib_deflate loop coretemp 
crc32c_intel ghash_clmulni_intel aesni_intel cryptd ipv6 aes_x86_64 aes_generic 
pcspkr i2c_i801 mei(C) sg iTCO_wdt microcode iTCO_vendor_support dca rtc_cmos 
container ext3 jbd mbcache i915 drm_kms_helper drm i2c_algo_bit i2c_core sd_mod 
crc_t10dif ahci libahci ehci_hcd libata button usbcore usb_common thermal video 
fan intel_agp intel_gtt processor thermal_sys hwmon scsi_dh_rdac scsi_dh_alua 
scsi_dh_emc scsi_dh_hp_sw scsi_dh scsi_mod [last unloaded: igb]
[   88.075236] 
[   88.076738] Pid: 1417644280, comm: ԨF.??? Tainted: G C O 
3.4.24.13-0.1-default #1 INSYDE eChiefRiver/Type2 - Board Product Name1
[   88.089319] RIP: 0010:[]  [] 
down_read_trylock+0x10/0x20
[   88.097783] RSP: 0018:8802547fbc88  EFLAGS: 00010002
[   88.103101] RAX: 4c10246c894c1824 RBX: 0001 RCX: 81467429
[   88.110238] RDX: 4c10246c894c1825 RSI: 0010 RDI: 81467489
[   88.117373] RBP: 8802547fbc88 R08: 8802547fbfd8 R09: 
[   88.124511] R10: 88025f28dc50 R11:  R12: 0001
[   88.131648] R13: 0010 R14: 8802547fbda8 R15: 0028
[   88.138786] FS:  () GS:88025f28() 
knlGS:
[   88.146876] CS:  0010 DS:  ES:  CR0: 8005003b
[   88.152626] CR2: 81467489 CR3: 01a0b000 CR4: 001407e0
[   88.159764] DR0:  DR1:  DR2: 
[   88.166901] DR3:  DR6: 0ff0 DR7: 0400
[   88.174039] Process ԨF.??? (pid: 1417644280, threadinfo 8802547fa000, 
task 8802547f8440)
[   88.183082] Stack:
[   88.185101]  8802547fbd98 8146aa24 a02ca194 
81467489
[   88.192601]  8802547f8440 81467429 8802547fbe78 
814675f5
[   88.200084]  0028 8802547fbe88  
a02ca194
[   88.207571] Call Trace:
[   88.210031]  [] do_page_fault+0x184/0x4b0
[   88.215617]  [] ? tmrhnd_invtssfault+0x14/0x20 [kpgen]
[   88.222327]  [] ? retint_signal+0x25/0x8c
[   88.227901]  [] ? restore_args+0x30/0x30
[   88.233390]  [] ? page_fault+0x25/0x30
[   88.238706]  [] ? tmrhnd_invtssfault+0x14/0x20 [kpgen]
[   88.245411]  [] ? tmrhnd_invtssfault+0x14/0x20 [kpgen]
[   88.252112]  [] ? restore_args+0x30/0x30
[   88.257604]  [] ? do_page_fault+0x34/0x4b0
[   88.263265]  [] page_fault+0x25/0x30
[   88.268408]  [] ? tmrhnd_invtssfault+0x14/0x20 [kpgen]
[   88.275110]  [] ? page_fault+0x25/0x30
[   88.280427]  [] ? tmrhnd_invtssfault+0x14/0x20 [kpgen]
[   88.287130]  [] ? tmrhnd_invtssfault+0x14/0x20 [kpgen]
[   88.293835]  [] ? restore_args+0x30/0x30
[   88.299322]  [] ? do_page_fault+0x34/0x4b0
[   88.304987]  [] ? start_secondary+0x7a/0x7c
[   88.310733] Code: c0 83 fa 01 5b 0f 94 c0 41 5c c9 c3 90 90 90 90 90 90 90 
90 90 90 90 90 90 90 90 55 48 89 e5 48 8b 07 48 89 c2 48 83 c2 01 7e 07  48 
0f b1 17 75 f0 48 f7 d0 c9 48 c1 e8 3f c3 55 31 c0 48 ba 
[   88.330974] RIP  [] down_read_trylock+0x10/0x20
[   88.337097]  RSP 
[   88.340590] CR2: 81467489
[   88.343921] BUG: unable to handle kernel paging request at 81467489
[   88.350926] IP: [] down_read_trylock+0x10/0x20
[   88.356962] PGD 1a0d067 PUD 1a11063 PMD 14001e1 
[   88.361664] Oops: 0003 [#2] SMP 
[   88.364940] CPU 2 
[   88.366788] Modules linked in: kpgen(O) igb(O) netmap_lin(O) megaraid_sas 
sr_mod mpt2sas raid_class uhci_hcd usb_storage ide_cd_mod ide_core mptctl 
mptsas ata_piix acpi_cpufreq mperf tg3 usbhid hid nfs lockd fscache auth_rpcgss 
nfs_acl sunrpc cdrom scsi_transport_sas e1000 mptscsih mptbase ipmi_devintf 
ipmi_msghandler ext2 ac 

Re: [PATCH 00/16] sched/wait: Collapse __wait_event macros -v5

[Paul E. McKenney]

On Wed, Oct 09, 2013 at 07:21:23AM -0700, Paul E. McKenney wrote:
> On Wed, Oct 09, 2013 at 08:08:06AM +0200, Ingo Molnar wrote:

[ . . . ]

> > > Now if it actually still builds, boots, and runs...  ;-)
> > 
> > Booting is overrated! ;-)
> 
> Well, some work is needed on this front, but will get there.
> 
> > Seriously, this is good stuff.
> > 
> >Reviewed-by: Ingo Molnar 
> 
> Very good, I have added this.
> 
> > I'd definitely argue in favor of doing a mechanical move first, then any 
> > further reorganization separately.
> > 
> > (One minor detail I noticed: you'll probably need to update the RCU file 
> > patterns in MAINTAINERS as well.)
> 
> Ah, good point, fixed!

And it now builds, boots, and passes short rcutorture tests, updated
patch below.

One side-effect is the boot parameters, namely that what used to be
rcutree.blimit=10 is now simply tree.blimit=10.  Not a problem for
me, I just made my test scripts probe the source tree and generate
the corresponding format.  But is there some straightforward way to
get the name of the "rcu" directory involved?  The obvious approach
of "rcu.tree.blimit=10" does not work -- the kernel happily ignores
any such parameter.

It looks like I should be able to do something like the following
in kernel/rcu/tree.c to get back the old parameter names:

MODULE_ALIAS("rcutree");
#ifdef MODULE_PARAM_PREFIX
#undef MODULE_PARAM_PREFIX
#endif
#define MODULE_PARAM_PREFIX "rcutree."

And similarly for rcu/update.c and rcu/torture.c.

In fact, it looks like I could make rcu/update.c also use either the
"rcutree." or "rcutiny." prefix, depending on which was being built.

Any thoughts, cautions, or suggestions?

Thanx, Paul

 b/Documentation/DocBook/device-drivers.tmpl |5 
 b/Documentation/RCU/stallwarn.txt   |4 
 b/Documentation/kernel-parameters.txt   |  257 ++--
 b/MAINTAINERS   |   11 -
 b/kernel/Makefile   |   11 -
 b/kernel/rcu/Makefile   |6 
 b/kernel/rcu/tiny.c |8 
 b/kernel/rcu/tree.c |6 
 b/kernel/rcu/tree_plugin.h  |4 
 b/kernel/rcu/tree_trace.c   |2 
 10 files changed, 168 insertions(+), 146 deletions(-)

rcu: Move RCU-related source code to kernel/rcu directory

Signed-off-by: Paul E. McKenney 
Reviewed-by: Ingo Molnar 

diff --git a/Documentation/DocBook/device-drivers.tmpl 
b/Documentation/DocBook/device-drivers.tmpl
index fe397f90a34f..6c9d9d37c83a 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -87,7 +87,10 @@ X!Iinclude/linux/kobject.h
 !Ekernel/printk/printk.c
 !Ekernel/panic.c
 !Ekernel/sys.c
-!Ekernel/rcupdate.c
+!Ekernel/rcu/srcu.c
+!Ekernel/rcu/tree.c
+!Ekernel/rcu/tree_plugin.h
+!Ekernel/rcu/update.c
  
 
  Device Resource Management
diff --git a/Documentation/RCU/stallwarn.txt b/Documentation/RCU/stallwarn.txt
index 6f3a0057548e..934448acdfbe 100644
--- a/Documentation/RCU/stallwarn.txt
+++ b/Documentation/RCU/stallwarn.txt
@@ -15,7 +15,7 @@ CONFIG_RCU_CPU_STALL_TIMEOUT
21 seconds.
 
This configuration parameter may be changed at runtime via the
-   /sys/module/rcutree/parameters/rcu_cpu_stall_timeout, however
+   /sys/module/tree/parameters/rcu_cpu_stall_timeout, however
this parameter is checked only at the beginning of a cycle.
So if you are 10 seconds into a 40-second stall, setting this
sysfs parameter to (say) five will shorten the timeout for the
@@ -24,7 +24,7 @@ CONFIG_RCU_CPU_STALL_TIMEOUT
timing of the next warning for the current stall.
 
Stall-warning messages may be enabled and disabled completely via
-   /sys/module/rcutree/parameters/rcu_cpu_stall_suppress.
+   /sys/module/tree/parameters/rcu_cpu_stall_suppress.
 
 CONFIG_RCU_CPU_STALL_VERBOSE
 
diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 1a036cd972fb..e442114cda5a 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2619,126 +2619,6 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
energy efficiency by requiring that the kthreads
periodically wake up to do the polling.
 
-   rcutree.blimit= [KNL,BOOT]
-   Set maximum number of finished RCU callbacks to process
-   in one batch.
-
-   rcutree.fanout_leaf=[KNL,BOOT]
-   Increase the number of CPUs assigned to each
-   leaf rcu_node structure.  Useful for very large
-   systems.
-
-   rcutree.jiffies_till_first_fqs= [KNL,BOOT]
-   Set delay from grace-period initialization to
-   first attempt to force quiescent 

[PATCH RESEND] timer stats: reset entries when disable the timer usage statistics

[Dong Zhu]

>From f41628c61d8a9172677ba33a55b61e37ce28f7a6 Mon Sep 17 00:00:00 2001
From: Dong Zhu  
Date: Thu, 10 Oct 2013 10:38:13 +0800

When we stop timer statistics collection (via echo 0 >
/proc/timers_stats), the statistics data is still exported as if it were
correct, which can cause applicaitons to misuse the statistics.

This patch resets the statistics when we stop collecting them, to avoid
this problem.

Signed-off-by: Dong Zhu 
---
 kernel/time/timer_stats.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/time/timer_stats.c b/kernel/time/timer_stats.c
index 0b537f2..43f05e7 100644
--- a/kernel/time/timer_stats.c
+++ b/kernel/time/timer_stats.c
@@ -371,6 +371,7 @@ static ssize_t tstats_write(struct file *file, const char 
__user *buf,
switch (ctl[0]) {
case '0':
if (timer_stats_active) {
+   reset_entries();
timer_stats_active = 0;
time_stop = ktime_get();
sync_access();
-- 
1.7.11.7

-- 
Best Regards,
Dong Zhu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [uml-devel] BUG: soft lockup for a user mode linux image

[Fengguang Wu]

On Wed, Oct 09, 2013 at 11:47:33PM +0200, Jan Kara wrote:
> On Wed 09-10-13 20:43:50, Richard Weinberger wrote:
> > CC'ing mm folks.
> > Please see below.
>   Added Fenguang to CC since he is the author of this code.

Thanks!

> > Am 09.10.2013 19:26, schrieb Toralf Förster:
> > > On 10/08/2013 10:07 PM, Geert Uytterhoeven wrote:
> > >> On Sun, Oct 6, 2013 at 11:01 PM, Toralf Förster  
> > >> wrote:
> >  Hmm, now pages_dirtied is zero, according to the backtrace, but the 
> >  BUG_ON()
> >  asserts its strict positive?!?
> > 
> >  Can you please try the following instead of the BUG_ON():
> > 
> >  if (pause < 0) {
> >  printk("pages_dirtied = %lu\n", pages_dirtied);
> >  printk("task_ratelimit = %lu\n", task_ratelimit);
> >  printk("pause = %ld\n", pause);
> >  }
> > 
> >  Gr{oetje,eeting}s,
> > 
> >  Geert
> > >>> I tried it in different ways already - I'm completely unsuccessful in 
> > >>> getting any printk output.
> > >>> As soon as the issue happens I do have a
> > >>>
> > >>> BUG: soft lockup - CPU#0 stuck for 22s! [trinity-child0:1521]
> > >>>
> > >>> at stderr of the UML and then no further input is accepted. With 
> > >>> uml_mconsole I'm however able
> > >>> to run very basic commands like a crash dump, sysrq ond so on.
> > >>
> > >> You may get an idea of the magnitude of pages_dirtied by using a chain of
> > >> BUG_ON()s, like:
> > >>
> > >> BUG_ON(pages_dirtied > 20);
> > >> BUG_ON(pages_dirtied > 10);
> > >> BUG_ON(pages_dirtied > 1);
> > >> BUG_ON(pages_dirtied > 1000);
> > >> BUG_ON(pages_dirtied > 100);
> > >>
> > >> Probably 1 million is already too much for normal operation?
> > >>
> > > period = HZ * pages_dirtied / task_ratelimit;
> > >   BUG_ON(pages_dirtied > 20);
> > >   BUG_ON(pages_dirtied > 10);  <-- this 
> > > is line 1467
> > 
> > Summary for mm people:
> > 
> > Toralf runs trinty on UML/i386.
> > After some time pages_dirtied becomes very large.
> > More than 10 pages in this case.
>   Huh, this is really strange. pages_dirtied is passed into
> balance_dirty_pages() from current->nr_dirtied. So I wonder how a value
> over 10^9 can get there.

I noticed aio_setup_ring() in the call trace and find it recently
added a SetPageDirty() call in a loop by commit 36bc08cc01 ("fs/aio:
Add support to aio ring pages migration"). So added CC to its authors.

> After all that is over 4TB so I somewhat doubt the
> task was ever able to dirty that much during its lifetime (but correct me
> if I'm wrong here, with UML and memory backed disks it is not totally
> impossible)... I went through the logic of handling ->nr_dirtied but
> I didn't find any obvious problem there. Hum, maybe one thing - what
> 'task_ratelimit' values do you see in balance_dirty_pages? If that one was
> huge, we could possibly accumulate huge current->nr_dirtied.
> 
> > Thus, period = HZ * pages_dirtied / task_ratelimit overflows
> > and period/pause becomes extremely large.

Yes, that's possible.

> > It looks like io_schedule_timeout() get's called with a very large timeout.
> > I don't know why "if (unlikely(pause > max_pause)) {" does not help.

The test will sure work and limit pause to <= max_pause. However it's
very possible balance_dirty_pages() cannot break out of the loop (or
being called repeatedly) and block the task.

I'm afraid there are no one to clear the dirty pages, which makes
balance_dirty_pages() waiting for ever.

Thanks,
Fengguang

> > 
> > > the back trace is :
> > > 
> > > tfoerste@n22 ~/devel/linux $ gdb --core=/mnt/ramdisk/core 
> > > /home/tfoerste/devel/linux/linux -batch -ex bt
> > > [New LWP 6911]
> > > Core was generated by `/home/tfoerste/devel/linux/linux earlyprintk 
> > > ubda=/home/tfoerste/virtual/uml/tr'.
> > > Program terminated with signal 6, Aborted.
> > > #0  0xb77a7424 in __kernel_vsyscall ()
> > > #0  0xb77a7424 in __kernel_vsyscall ()
> > > #1  0x083bdf35 in kill ()
> > > #2  0x0807296d in uml_abort () at arch/um/os-Linux/util.c:93
> > > #3  0x08072ca5 in os_dump_core () at arch/um/os-Linux/util.c:148
> > > #4  0x080623c4 in panic_exit (self=0x85c1558 , 
> > > unused1=0, unused2=0x85f76e0 ) at arch/um/kernel/um_arch.c:240
> > > #5  0x0809ba86 in notifier_call_chain (nl=0x0, val=0, v=0x85f76e0 
> > > , nr_to_call=-2, nr_calls=0x0) at kernel/notifier.c:93
> > > #6  0x0809bba1 in __atomic_notifier_call_chain (nh=0x85f76c4 
> > > , val=0, v=0x85f76e0 , nr_to_call=0, 
> > > nr_calls=0x0) at kernel/notifier.c:182
> > > #7  0x0809bbdf in atomic_notifier_call_chain (nh=0x0, val=0, v=0x0) at 
> > > kernel/notifier.c:191
> > > #8  0x0841b5bc in panic (fmt=0x0) at kernel/panic.c:130
> > > #9  0x0841c470 in balance_dirty_pages (pages_dirtied=23, 
> > > mapping=) at mm/page-writeback.c:1467
> > > #10 0x080d3595 in balance_dirty_pages_ratelimited (mapping=0x6) at 
> > > mm/page-writeback.c:1661

Re: [RFC] do we want pipefs et.al. in /proc/filesystems?

[Linus Torvalds]

On Wed, Oct 9, 2013 at 5:47 PM, Al Viro  wrote:
>
> These days there's no reason to register the filesystem types
> that can only be used for internal mounts - ia64 pfmfs, anon_inodes,
> bdev, pipefs and sockfs, in the current tree.  The only user-visible
> effect of dropping those register_filesystem() would be shorter
> /proc/filesystems - that bunch wouldn't be mentioned there anymore.
> Does anything care about that?  FWIW, the diff eliminating those
> would be as below (net/socket.c init leaks on early failures;
> I'd left that as-is - it's a separate story).

I like the patch, but I do worry that some user space thing uses this
to check whether the particular filesystem module is loaded.

Those kinds of things can't use /proc/modules (because it might be
built-in), but /proc/filesystems has traditionally contained
everything.

That said, these particular filesystems I really don't think people
would ever possibly check for, so I think it's fine.

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

Re: [xen] double fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC

[Linus Torvalds]

On Wed, Oct 9, 2013 at 7:23 PM, Dave Airlie  wrote:
>
> Well the commit that added it had a reason that seems to cover some other
> device model abuses, so maybe someone who actually understands the device
> model (all 2 people) can review usage

Actually, I think it's the same bug.

You *cannot* just reuse the storage. Doing a "memset()" doesn't
improve anything. The basic issue is that if you reuse it, you're
buggy. End of story.

Why? It's refcounted, and it's out of your hands. Reusing it is wrong
- because it might still be used. The fact that you "released" it is
immaterial. Others can have refcounts (and through /sys etc,
historically really do have them).

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

[PATCH 3/3] arm64: include: asm: atomic.h: use 'unsigned int' and 'atomic_t' instead of 'unsigned long' for atomic_clear_mask()

[Chen Gang]

In current kernel wide source, for arm64, only s390 scsi drivers use
atomic_clear_mask(), now, s390 itself need use 'unsigned int' and
'atomic_t', so need match s390's atomic_clear_mask().


Signed-off-by: Chen Gang 
---
 arch/arm64/include/asm/atomic.h |   13 +++--
 1 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/include/asm/atomic.h b/arch/arm64/include/asm/atomic.h
index 8363644..58808fc 100644
--- a/arch/arm64/include/asm/atomic.h
+++ b/arch/arm64/include/asm/atomic.h
@@ -126,16 +126,17 @@ static inline int atomic_cmpxchg(atomic_t *ptr, int old, 
int new)
return oldval;
 }
 
-static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
+static inline void atomic_clear_mask(unsigned int mask, atomic_t *ptr)
 {
-   unsigned long tmp, tmp2;
+   unsigned int tmp;
+   unsigned long tmp2;
 
asm volatile("// atomic_clear_mask\n"
-"1:ldxr%0, %2\n"
-"  bic %0, %0, %3\n"
-"  stxr%w1, %0, %2\n"
+"1:ldxr%w0, %2\n"
+"  bic %w0, %w0, %w3\n"
+"  stxr%w1, %w0, %2\n"
 "  cbnz%w1, 1b"
-   : "=" (tmp), "=" (tmp2), "+Q" (*addr)
+   : "=" (tmp), "=" (tmp2), "+Q" (ptr->counter)
: "Ir" (mask)
: "cc");
 }
-- 
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 2/3] arm: include: asm: atomic.h: use 'unsigned int' and 'atomic' instead of 'unsigned long' for atomic_clear_mask()

[Chen Gang]

In current kernel wide source, for arm, only s390 scsi drivers use
atomic_clear_mask(), now, s390 itself need use 'unsigned int' and
'atomic_t', so need match s390's atomic_clear_mask().


Signed-off-by: Chen Gang 
---
 arch/arm/include/asm/atomic.h |   13 +++--
 1 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/arch/arm/include/asm/atomic.h b/arch/arm/include/asm/atomic.h
index da1c77d..0832a7f 100644
--- a/arch/arm/include/asm/atomic.h
+++ b/arch/arm/include/asm/atomic.h
@@ -134,9 +134,10 @@ static inline int atomic_cmpxchg(atomic_t *ptr, int old, 
int new)
return oldval;
 }
 
-static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
+static inline void atomic_clear_mask(unsigned int mask, atomic_t *ptr)
 {
-   unsigned long tmp, tmp2;
+   unsigned int tmp;
+   unsigned long tmp2;
 
__asm__ __volatile__("@ atomic_clear_mask\n"
 "1:ldrex   %0, [%3]\n"
@@ -144,8 +145,8 @@ static inline void atomic_clear_mask(unsigned long mask, 
unsigned long *addr)
 "  strex   %1, %0, [%3]\n"
 "  teq %1, #0\n"
 "  bne 1b"
-   : "=" (tmp), "=" (tmp2), "+Qo" (*addr)
-   : "r" (addr), "Ir" (mask)
+   : "=" (tmp), "=" (tmp2), "+Qo" (ptr->counter)
+   : "r" (>counter), "Ir" (mask)
: "cc");
 }
 
@@ -197,12 +198,12 @@ static inline int atomic_cmpxchg(atomic_t *v, int old, 
int new)
return ret;
 }
 
-static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
+static inline void atomic_clear_mask(unsigned int mask, atomic_t *v)
 {
unsigned long flags;
 
raw_local_irq_save(flags);
-   *addr &= ~mask;
+   v->counter &= ~mask;
raw_local_irq_restore(flags);
 }
 
-- 
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/

kdump: kdump can't boot in this case

[Xishi Qiu]

I write a module, and find kdump can't boot in this case.
kernel version is 3.12, Intel(R) Xeon(R) CPUE5620

struct timer_list g_timer;

void tmrhnd_invtssfault(unsigned long data)
{
long __res;
printk(KERN_EMERG "invalid TSS fault in interrupt context.\n");
__asm__ volatile("int $0x0A" : "=a"(__res):);
}

{
...
init_timer(_timer);
g_timer.expires = jiffies + 10;
g_timer.data = 0;
g_timer.function = tmrhnd_invtssfault;
add_timer(_timer);
...
}

If access NULL pointer instead of "__asm__ volatile("int $0x0A" : 
"=a"(__res):);" 
in tmrhnd_invtssfault(), kdump can boot.
And if not use timer, just do "__asm__ volatile("int $0x0A" : "=a"(__res):);" 
only
once in module, kdump can boot too.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] s390: include: asm: atomic.h: use 'unsigned int' instead of 'unsigned long' for atomic_*_mask()

[Chen Gang]

The type of 'v->counter' is always 'int', and related inline assembly
code also process 'int', so use 'unsigned int' instead of 'unsigned
long' for the 'mask'.


Signed-off-by: Chen Gang 
---
 arch/s390/include/asm/atomic.h |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/s390/include/asm/atomic.h b/arch/s390/include/asm/atomic.h
index a62ed2d..12c5ec1 100644
--- a/arch/s390/include/asm/atomic.h
+++ b/arch/s390/include/asm/atomic.h
@@ -113,12 +113,12 @@ static inline void atomic_add(int i, atomic_t *v)
 #define atomic_dec_return(_v)  atomic_sub_return(1, _v)
 #define atomic_dec_and_test(_v)(atomic_sub_return(1, _v) == 0)
 
-static inline void atomic_clear_mask(unsigned long mask, atomic_t *v)
+static inline void atomic_clear_mask(unsigned int mask, atomic_t *v)
 {
__ATOMIC_LOOP(v, ~mask, __ATOMIC_AND);
 }
 
-static inline void atomic_set_mask(unsigned long mask, atomic_t *v)
+static inline void atomic_set_mask(unsigned int mask, atomic_t *v)
 {
__ATOMIC_LOOP(v, mask, __ATOMIC_OR);
 }
-- 
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 0/3] s390/arm/arm64: include: asm: atomic.h: use 'unsigned int' and 'atomic_t' instead of 'unsigned long' for atomic_*_mask()

[Chen Gang]

For atomic_*_mask(), the 'atomic_t' is 32-bit, so for the 'mask', also
need mach it.


Patch 1/3: s390: include: asm: atomic.h: use 'unsigned int' instead of
'unsigned long' for atomic_*_mask().

Patch 2/3: arm: include: asm: atomic.h: use 'unsigned int' and 'atomic'
instead of 'unsigned long' for atomic_clear_mask().

Patch 3/3: arm64: include: asm: atomic.h: use 'unsigned int' and
'atomic_t' instead of 'unsigned long' for atomic_clear_mask().


Signed-off-by: Chen Gang 
---
 arch/arm/include/asm/atomic.h   |   13 +++--
 arch/arm64/include/asm/atomic.h |   13 +++--
 arch/s390/include/asm/atomic.h  |4 ++--
 3 files changed, 16 insertions(+), 14 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/

[PATCH] tools/perf/util: Fix memory leak in trace-event-info.c

[Felipe Pena]

Fix for a memory leak on tracing_data_get() function when returning NULL 
explicitly

Signed-off-by: Felipe Pena 
---
 tools/perf/util/trace-event-info.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/trace-event-info.c 
b/tools/perf/util/trace-event-info.c
index f3c9e55..06f8624 100644
--- a/tools/perf/util/trace-event-info.c
+++ b/tools/perf/util/trace-event-info.c
@@ -518,13 +518,13 @@ struct tracing_data *tracing_data_get(struct list_head 
*pattrs,
 "/tmp/perf-XX");
if (!mkstemp(tdata->temp_file)) {
pr_debug("Can't make temp file");
-   return NULL;
+   goto err_tdata;
}

temp_fd = open(tdata->temp_file, O_RDWR);
if (temp_fd < 0) {
pr_debug("Can't read '%s'", tdata->temp_file);
-   return NULL;
+   goto err_tdata;
}

/*
@@ -569,6 +569,10 @@ out:

put_tracepoints_path(tps);
return tdata;
+
+err_tdata:
+   free(tdata);
+   return NULL;
 }

 int tracing_data_put(struct tracing_data *tdata)
--
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] frontswap: enable call to invalidate area on swapoff

[Seth Jennings]

On Thu, Oct 10, 2013 at 09:29:07AM +0800, Bob Liu wrote:
> On 10/09/2013 10:40 PM, Seth Jennings wrote:
> > 
> > The reason we never noticed this for zswap is that zswap has no
> > dynamically allocated per-type resources.  In the expected case,
> > where all of the pages have been drained from zswap,
> > zswap_frontswap_invalidate_area() is a no-op.
> > 
> 
> Not exactly, see the bug fix "mm/zswap: bugfix: memory leak when
> re-swapon" from Weijie.
> Zswap needs invalidate_area() also.

I remembered this patch as soon as I sent out this note.  What I said
about zswap_frontswap_invalidate_area() being a no-op in the expected
case is true as of v3.12-rc4, but it shouldn't be :)

I sent a note to Andrew reminding him to pull in that patch.

Thanks,
Seth
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] xhci-hub.c: handle command_trb that may be link TRB

[Xiao Jin]

Sarah,

Thanks for the reminding. The kernel base of the patch is k3.10, I
didn't notice k3.12 commit ec7e43e2d98173483866fe2e4e690143626b659c at
that time. I will backport the patch from k3.12 for use.

As you mentioned in another email, we meet with dpm timeout when xhci
suspend, the root cause are what the patch aimed to solve. FYI.

On Wed, 2013-10-09 at 13:18 -0700, Sarah Sharp wrote:
> Hi Xiao,
> 
> Thanks for taking the time to submit this patch.  Comments below.
> 
> On Wed, Oct 09, 2013 at 09:42:36AM +0800, Xiao Jin wrote:
> > From: xiao jin 
> > Date: Wed, 9 Oct 2013 09:38:45 +0800
> > Subject: [PATCH] xhci-hub.c: handle command_trb that may be link TRB
> 
> I won't be able to apply your patch  because it has these extra lines in
> the body ^^^.  I suspect you used `git format-patch` to produce this,
> and then tried to copy-paste it into your mail client?  You can't do
> that, because your mail client will probably word-wrap your patch, and
> possibly turn tabs into spaces.  You need to use `git send-email`
> instead to send your patches.
> 
> > When xhci stop device, it's possible cmd_ring enqueue point to
> > link TRB after queue the last but one stop endpoint. We must
> > handle the command_trb point to the next segment trb. Otherwise
> > xhci stop devie will timeout because command_trb can't match
> > with cmd_ring dequeue.
> > 
> > The patch is to let command_trb point to the next segment trb if
> > cmd_ring enqueue point to link TRB.
> > 
> > Signed-off-by: xiao jin 
> > ---
> >  drivers/usb/host/xhci-hub.c |7 +++
> >  1 files changed, 7 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
> > index 1d35459..4872640 100644
> > --- a/drivers/usb/host/xhci-hub.c
> > +++ b/drivers/usb/host/xhci-hub.c
> > @@ -287,6 +287,13 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int 
> > slot_id, int suspend)
> > xhci_queue_stop_endpoint(xhci, slot_id, i, suspend);
> > }
> > cmd->command_trb = xhci->cmd_ring->enqueue;
> > +   /* Enqueue pointer can be left pointing to the link TRB,
> > +* we must handle that
> > +*/
> > +   if (TRB_TYPE_LINK_LE32(cmd->command_trb->link.control))
> > +   cmd->command_trb =
> > +   xhci->cmd_ring->enq_seg->next->trbs;
> > +
> > list_add_tail(>cmd_list, _dev->cmd_list);
> > xhci_queue_stop_endpoint(xhci, slot_id, 0, suspend);
> > xhci_ring_cmd_db(xhci);
> 
> What kernel version or tree is it against?  I ask because there's
> already a fix in the 3.12-rc4 kernel for this:
> 
> static int xhci_stop_device(struct xhci_hcd *xhci, int slot_id, int suspend)
> {
> ...
> spin_lock_irqsave(>lock, flags);
> for (i = LAST_EP_INDEX; i > 0; i--) {
> if (virt_dev->eps[i].ring && virt_dev->eps[i].ring->dequeue)
> xhci_queue_stop_endpoint(xhci, slot_id, i, suspend);
> }
> cmd->command_trb = xhci_find_next_enqueue(xhci->cmd_ring);
> ...
> 
> Where xhci_find_next_enqueue is defined as:
> 
> union xhci_trb *xhci_find_next_enqueue(struct xhci_ring *ring)
> {
> /* Enqueue pointer can be left pointing to the link TRB,
>  * we must handle that
>  */
> if (TRB_TYPE_LINK_LE32(ring->enqueue->link.control))
> return ring->enq_seg->next->trbs;
> return ring->enqueue;
> }
> 
> That was added in commit ec7e43e2d98173483866fe2e4e690143626b659c "xhci:
> Ensure a command structure points to the correct trb on the command
> ring"  It's in (or should be in soon) the stable kernels as well.
> 
> Sarah Sharp


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [xen] double fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC

[Dave Airlie]

> I think David Arlie also needs a quiet talking to about how to use the
> device model:
> 
> int drm_sysfs_device_add(struct drm_minor *minor)
> {
> minor->kdev.release = drm_sysfs_device_release;
> ...
> err = device_register(>kdev);
> }
> 
> static void drm_sysfs_device_release(struct device *dev)
> {
> memset(dev, 0, sizeof(struct device));
> return;
> }
> 
> Since when has that been acceptable in a release function?

Well the commit that added it had a reason that seems to cover some other 
device model abuses, so maybe someone who actually understands the device 
model (all 2 people) can review usage.

Dave.

commit 77d26dc9b9805f322f5a1f6e559b18ad66205bd9
Author: Ma Ling 
Date:   Thu Apr 16 17:51:25 2009 +0800

drm: clean dirty memory after device release

In current code we register/unregister connector object by
drm_sysfs_connector_add/remove function.

However under some cases, we need to dynamically register or 
unregister device
multiple times, so we have to go through register -> unregister 
->register
routine.

Because after device_unregister function our memory is dirty, we need 
to do
clean operation in order to re-register the device, otherwise the 
system
will crash.  The patch intends to clean device after device release.

Signed-off-by: Ma Ling 
Signed-off-by: Dave Airlie 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Potential out-of-bounds in ftrace_regex_release

[Steven Rostedt]

On Wed, 9 Oct 2013 14:05:26 +0400
Andrey Konovalov  wrote:

> So I still think that the bug is in 'trage_get_user()':
> Checking that 'parser->idx < parser->size - 1' is not performed in 'if
> (isspace(ch))' section, so 'parser->idx' becomes equal to
> 'parser->size' after 'parser->buffer[parser->idx++] = ch;'.
> (However in 'while (cnt && !isspace(ch))' loop checking is performed.)

Yep, you are correct. I put in some printk's and did same writing to
the set_events file and was able to prove that I could get that "0"
written into the +1 overflow boundary.

Can you try this patch to see if it fixes it for you.

Thanks,

-- Steve

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index d5f7c4d..063a92b 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -843,9 +843,12 @@ int trace_get_user(struct trace_parser *parser, const char 
__user *ubuf,
if (isspace(ch)) {
parser->buffer[parser->idx] = 0;
parser->cont = false;
-   } else {
+   } else if (parser->idx < parser->size - 1) {
parser->cont = true;
parser->buffer[parser->idx++] = ch;
+   } else {
+   ret = -EINVAL;
+   goto out;
}
 
*ppos += read;

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

Re: [x86] BUG: unable to handle kernel paging request at 00740060

[Mike Galbraith]

On Wed, 2013-10-09 at 19:18 +0200, Ingo Molnar wrote: 
> * Ingo Molnar  wrote:
> 
> > 
> > * Peter Zijlstra  wrote:
> > 
> > > On Wed, Oct 09, 2013 at 08:19:11PM +0800, Fengguang Wu wrote:
> > > > > > Fengguang, I do not think this will help, but just in case. Could 
> > > > > > you
> > > > > > show the result of
> > > > > > 
> > > > > > $ kernel/task_work.s
> > > > 
> > > > Update: I recompiled the kernel with gcc 4.4.7 and find it booting fine!
> > > 
> > > > # 208 "/c/wfg/tip/arch/x86/include/asm/bitops.h" 1
> > > > bts $1, 8(%eax); setc %dl   #,, c
> > > 
> > > That compiler doesn't appear to have asm goto support, so we fall back 
> > > to the code we already knew worked :-)
> > 
> > I'm using 4.7.2 with randconfig testing, which has asm goto support, and 
> > I haven't seen this crash yet.
> > 
> > Unless my testing is off it might be a bug in GCC 4.8, or a pre-existing 
> > bug gets exposed by GCC 4.8.
> 
> And as it happens, just a few hours later I hit a very similar crash, this 
> time compiled with both 4.7.3 and 4.7.2! (config attached)
> 
> This has a weird-x86-arch tuning knob as well:
> 
>   CONFIG_MGEODE_LX=y
> 
> So I think we might need to turn off asm goto for all things 32-bit x86.

Hm, 32 bit x86...

I built 4.8.1 yesterday, so can now build x86_64 tip, but I suspect I'll
not be the only one with a compiler that goes belly up.

net/sunrpc/xprtsock.c: In function ‘xs_setup_tcp’:
net/sunrpc/xprtsock.c:2844:1: internal compiler error: in move_insn, at 
haifa-sched.c:2353

gcc-4.6.2 (opensuse 12.1) has happily chewed up humongous piles of
source, but finds this asm goto stuff to be toxic.

-Mike

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

Re: [RFC/PATCH] ftrace: add set_graph_notrace filter

[Steven Rostedt]

On Thu, 10 Oct 2013 10:51:54 +0900
Namhyung Kim  wrote:

> Hi Steve,
> 
> On Mon, 30 Sep 2013 23:58:46 -0400, Steven Rostedt wrote:
> > On Mon, 2013-09-30 at 16:04 +0900, Namhyung Kim wrote:
> >> Ping!
> >
> > Ah I missed this patch. And I'm currently traveling.
> >
> > I'll start testing it when I get back on Friday, but feel free to ping
> > me again next Monday.
> 
> Would you take a look at it this time? :)

Yep! I just finished a bunch of stuff, and now have time to look into
patches. I'm working backward (although I should be working forward).
I'll definitely get to this tomorrow.

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

[PATCH v4] btrfs: Fix memory leakage in the tree-log.c

[Geyslan G. Bem]

When 'dir' is NULL, after calling extref_get_fields(), add_inode_ref()
can be returning without freeing the 'name' pointer.

Added kfree when necessary.

Signed-off-by: Geyslan G. Bem 
---
 fs/btrfs/tree-log.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 79f057c..63c0b72 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -1169,8 +1169,11 @@ static noinline int add_inode_ref(struct 
btrfs_trans_handle *trans,
 */
if (!dir)
dir = read_one_inode(root, parent_objectid);
-   if (!dir)
+   if (!dir) {
+   if (!ret)
+   kfree(name);
return -ENOENT;
+   }
} else {
ret = ref_get_fields(eb, ref_ptr, , ,
 _index);
-- 
1.8.4

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

Re: [PATCH v2 tip/core/rcu 07/13] ipv6/ip6_tunnel: Apply rcu_access_pointer() to avoid sparse false positive

[Hannes Frederic Sowa]

On Wed, Oct 09, 2013 at 05:28:33PM -0700, Paul E. McKenney wrote:
> On Wed, Oct 09, 2013 at 05:12:40PM -0700, Eric Dumazet wrote:
> > On Wed, 2013-10-09 at 16:40 -0700, Josh Triplett wrote:
> > 
> > > that.  Constructs like list_del_rcu are much clearer, and not
> > > open-coded.  Open-coding synchronization code is almost always a Bad
> > > Idea.
> > 
> > OK, so you think there is synchronization code.
> > 
> > I will shut up then, no need to waste time.
> 
> As you said earlier, we should at least get rid of the memory barrier
> as long as we are changing the code.

Interesting thread!

Sorry to chime in and asking a question:

Why do we need an ACCESS_ONCE here if rcu_assign_pointer can do without one?
In other words I wonder why rcu_assign_pointer is not a static inline function
to use the sequence point in argument evaluation (if I remember correctly this
also holds for inline functions) to not allow something like this:

E.g. we want to publish which lock to take first to prevent an ABBA problem
(extreme example):

rcu_assign_pointer(lockptr, min(lptr1, lptr2));

Couldn't a compiler spill the lockptr memory location as a temporary buffer
if the compiler is under register pressure? (yes, this seems unlikely if we
flushed out most registers to memory because of the barrier, but still... ;) )

This seems to be also the case if we publish a multi-dereferencing pointers
e.g. ptr->ptr->ptr.

Thanks,

  Hannes

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

[PATCH] tools/perf/tests: Fix memory leak in dso-data.c

[Felipe Pena]

Fix for a memory leak on test_file() function in dso-data.c

Signed-off-by: Felipe Pena 
---
 tools/perf/tests/dso-data.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/perf/tests/dso-data.c b/tools/perf/tests/dso-data.c
index dffe055..9cc81a3 100644
--- a/tools/perf/tests/dso-data.c
+++ b/tools/perf/tests/dso-data.c
@@ -35,6 +35,7 @@ static char *test_file(int size)
if (size != write(fd, buf, size))
templ = NULL;

+   free(buf);
close(fd);
return templ;
 }
--
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: block layer runtime pm and udisks

[Aaron Lu]

On 10/10/2013 09:40 AM, Phillip Susi wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> I have been trying out the new block layer runtime pm, and run into a
> problem: udisks keeps waking up the disk.  Every 10 minutes it tries
> to poll the SMART status of the drive, but it does first issue an ata
> CHECK POWER command to see if it is in standby, and skips the check to
> avoid waking the disk.  The problem with runtime pm is that *any*
> request brings the drive out of suspend, and the suspend wake path
> forces the drive to spin up by issuing a verify command on sector 0.
> 
> Is there a reason that the wakeup path forces the drive to spin up, or
> could this be removed and rely on the drive waking up automatically if
> the request requires it?
> 
> Or would it be possible to notice that the command being sent is a
> check power command, and fake the reply instead of resuming the device?
> 
> Or does udisks just need to check the runtime pm status before trying
> the check power command?

I think the udisks can be modified to check if the drive is runtime
suspended and if so, avoid poll the SMART status.

Thanks,
Aaron

> 
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.14 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQEcBAEBCgAGBQJSVgWPAAoJEJrBOlT6nu75k/cH+gMAb9YtMS21rEt94umJpBYj
> BcNoyGoK39tAKZHW7pXfP2hRIm1+kPTPi44Wp7kQHu7m6BSp4YetmDkqjNv+6yAy
> 8SUvPcqRsJVbF1oBXN09phBEnk/JfxqID7n6hB1lT6NqYV72VVVUEUOlnSnpHtDJ
> gszV+TLH37uhd5/KiDFja3J2bJC0R/klzDF1x1clc53tGJd1NZ+h9tZZBLszIdnS
> EnjukLA02Q7ooq+445WyWth2cypTXKfRbigZW+FfCI3hfAKOShVevodlGmmrQb7Z
> 0xzhSoO5JTpNqJPLaNL3+JZFdXwANd+7PuO9v2XVKKUkydQ9+Vl4CfydSFhqo5U=
> =iuSZ
> -END PGP SIGNATURE-
> 

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

Re: [RFC/PATCH] ftrace: add set_graph_notrace filter

[Namhyung Kim]

Hi Steve,

On Mon, 30 Sep 2013 23:58:46 -0400, Steven Rostedt wrote:
> On Mon, 2013-09-30 at 16:04 +0900, Namhyung Kim wrote:
>> Ping!
>
> Ah I missed this patch. And I'm currently traveling.
>
> I'll start testing it when I get back on Friday, but feel free to ping
> me again next Monday.

Would you take a look at it this time? :)

Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 12/15] KVM: MMU: allow locklessly access shadow page table out of vcpu thread

[Marcelo Tosatti]

On Wed, Oct 09, 2013 at 06:45:47PM +0800, Xiao Guangrong wrote:
> On 10/09/2013 09:56 AM, Marcelo Tosatti wrote:
> > On Tue, Oct 08, 2013 at 12:02:32PM +0800, Xiao Guangrong wrote:
> >>
> >> Hi Marcelo,
> >>
> >> On Oct 8, 2013, at 9:23 AM, Marcelo Tosatti  wrote:
> >>
> 
>  +if (kvm->arch.rcu_free_shadow_page) {
>  +kvm_mmu_isolate_pages(invalid_list);
>  +sp = list_first_entry(invalid_list, struct 
>  kvm_mmu_page, link);
>  +list_del_init(invalid_list);
>  +call_rcu(>rcu, free_pages_rcu);
>  +return;
>  +}
> >>>
> >>> This is unbounded (there was a similar problem with early fast page fault
> >>> implementations):
> >>>
> >>> From RCU/checklist.txt:
> >>>
> >>> "An especially important property of the synchronize_rcu()
> >>>primitive is that it automatically self-limits: if grace periods
> >>>are delayed for whatever reason, then the synchronize_rcu()
> >>>primitive will correspondingly delay updates.  In contrast,
> >>>code using call_rcu() should explicitly limit update rate in
> >>>cases where grace periods are delayed, as failing to do so can
> >>>result in excessive realtime latencies or even OOM conditions.
> >>> "
> >>
> >> I understand what you are worrying about… Hmm, can it be avoided by
> >> just using kvm->arch.rcu_free_shadow_page in a small window? - Then
> >> there are slight chance that the page need to be freed by call_rcu.
> > 
> > The point that must be addressed is that you cannot allow an unlimited
> > number of sp's to be freed via call_rcu between two grace periods.
> > 
> > So something like:
> > 
> > - For every 17MB worth of shadow pages.
> > - Guarantee a grace period has passed.
> 
> Hmm, the 'qhimark' in rcu is 1, that means rcu allows call_rcu
> to pend 1 times in a grace-period without slowdown. Can we really
> reach this number while rcu_free_shadow_page is set? Anyway, if it can,
> we can use rcu tech-break to avoid it, can't we?

Yes.

> > If you control kvm->arch.rcu_free_shadow_page, you could periodically
> > verify how many MBs worth of shadow pages are in the queue for RCU
> > freeing and force grace period after a certain number.
> 
> I have no idea how to froce grace-period for the cpu which is running
> in rcu-read side. IIUC, only dyntick-idle and offline CPU can be froced,
> see rcu_gp_fqs().

synchronize_rcu.

> >>> Moreover, freeing pages differently depending on some state should 
> >>> be avoided.
> >>>
> >>> Alternatives:
> >>>
> >>> - Disable interrupts at write protect sites.
> >>
> >> The write-protection can be triggered by KVM ioctl that is not in the VCPU
> >> context, if we do this, we also need to send IPI to the KVM thread when do
> >> TLB flush.
> > 
> > Yes. However for the case being measured, simultaneous page freeing by 
> > vcpus 
> > should be minimal (therefore not affecting the latency of GET_DIRTY_LOG).
> 
> I agree, but write-protection will cost lots of time, we need to:
> 1) do write-protection under irq disabled, that is not good for device
> Or
> 2) do pieces of works, then enable irq and disable it agian to continue
>the work. Enabling and disabing irq many times are not cheap for x86.
> 
> no?

Its getting cheaper (see performance optimization guide).

> >> And we can not do much work while interrupt is disabled due to
> >> interrupt latency.
> >>
> >>> - Rate limit the number of pages freed via call_rcu
> >>> per grace period.
> >>
> >> Seems complex. :(
> >>
> >>> - Some better alternative.
> >>
> >> Gleb has a idea that uses RCU_DESTORY to protect the shadow page table
> >> and encodes the page-level into the spte (since we need to check if the 
> >> spte
> >> is the last-spte. ).  How about this?
> > 
> > Pointer please? Why is DESTROY_SLAB_RCU any safer than call_rcu with
> > regards to limitation? (maybe it is).
> 
> For my experience, freeing shadow page and allocing shadow page are balanced,
> we can check it by (make -j12 on a guest with 4 vcpus and):
> 
> # echo > trace
> [root@eric-desktop tracing]# cat trace > ~/log | sleep 3
> [root@eric-desktop tracing]# cat ~/log | grep new | wc -l
> 10816
> [root@eric-desktop tracing]# cat ~/log | grep prepare | wc -l
> 10656
> [root@eric-desktop tracing]# cat set_event
> kvmmmu:kvm_mmu_get_page
> kvmmmu:kvm_mmu_prepare_zap_page
> 
> alloc VS. free = 10816 : 10656
> 
> So that, mostly all allocing and freeing are done in the slab's
> cache and the slab frees shdadow pages very slowly, there is no rcu issue.

A more detailed test case would be:

- cpu0-vcpu0 releasing pages as fast as possible
- cpu1 executing get_dirty_log

Think of a very large guest.

> >> I planned to do it after this patchset merged, if you like it and if you 
> >> think
> >> that "using kvm->arch.rcu_free_shadow_page in a small window" can not avoid
> >> the issue, i am happy to do it in the next version. :)
> > 

[PATCH 1/2] regulator: s5m8767: Modify parse_dt function to parse data related to ramp

[Chanwoo Choi]

This patch parse 'buck[2-4]_ramp_enable and buck_ramp_delay' platform data
from dts file.

Signed-off-by: Chanwoo Choi 
Signed-off-by: Kyungmin Park 
---
 drivers/regulator/s5m8767.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/regulator/s5m8767.c b/drivers/regulator/s5m8767.c
index c24448b..cb6cdb3 100644
--- a/drivers/regulator/s5m8767.c
+++ b/drivers/regulator/s5m8767.c
@@ -640,6 +640,22 @@ static int s5m8767_pmic_dt_parse_pdata(struct 
platform_device *pdev,
return -EINVAL;
}
 
+   if (of_get_property(pmic_np, "s5m8767,pmic-buck2-ramp-enable", NULL))
+   pdata->buck2_ramp_enable = true;
+
+   if (of_get_property(pmic_np, "s5m8767,pmic-buck3-ramp-enable", NULL))
+   pdata->buck3_ramp_enable = true;
+
+   if (of_get_property(pmic_np, "s5m8767,pmic-buck4-ramp-enable", NULL))
+   pdata->buck4_ramp_enable = true;
+
+   if (pdata->buck2_ramp_enable || pdata->buck3_ramp_enable
+   || pdata->buck4_ramp_enable) {
+   if (of_property_read_u32(pmic_np, 
"s5m8767,pmic-buck-ramp-delay",
+   >buck_ramp_delay))
+   pdata->buck_ramp_delay = 0;
+   }
+
return 0;
 }
 #else
-- 
1.8.0

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

[PATCH 2/2] regulator: s5m8767: Modify parsing method of the voltage table of buck2/3/4

[Chanwoo Choi]

The s5m8767 regulator driver parse always the voltage table of buck2/3/4.
If gpio_dvs feature isn't used and dts haven't included the voltage table
of buck2/3/4, s5m8767 regulator driver return error and file probe state.

This patch check only voltage table of buck on s5m8767_pmic_dt_parse_pdata()
if buck[2-4]_gpiodvs is true.

Signed-off-by: Chanwoo Choi 
Signed-off-by: YoungJun Cho 
Signed-off-by: Kyungmin Park 
---
 drivers/regulator/s5m8767.c | 54 +++--
 1 file changed, 28 insertions(+), 26 deletions(-)

diff --git a/drivers/regulator/s5m8767.c b/drivers/regulator/s5m8767.c
index cb6cdb3..2c0 100644
--- a/drivers/regulator/s5m8767.c
+++ b/drivers/regulator/s5m8767.c
@@ -522,7 +522,7 @@ static int s5m8767_pmic_dt_parse_pdata(struct 
platform_device *pdev,
struct device_node *pmic_np, *regulators_np, *reg_np;
struct sec_regulator_data *rdata;
struct sec_opmode_data *rmode;
-   unsigned int i, dvs_voltage_nr = 1, ret;
+   unsigned int i, dvs_voltage_nr = 8, ret;
 
pmic_np = iodev->dev->of_node;
if (!pmic_np) {
@@ -586,15 +586,39 @@ static int s5m8767_pmic_dt_parse_pdata(struct 
platform_device *pdev,
rmode++;
}
 
-   if (of_get_property(pmic_np, "s5m8767,pmic-buck2-uses-gpio-dvs", NULL))
+   if (of_get_property(pmic_np, "s5m8767,pmic-buck2-uses-gpio-dvs", NULL)) 
{
pdata->buck2_gpiodvs = true;
 
-   if (of_get_property(pmic_np, "s5m8767,pmic-buck3-uses-gpio-dvs", NULL))
+   if (of_property_read_u32_array(pmic_np,
+   "s5m8767,pmic-buck2-dvs-voltage",
+   pdata->buck2_voltage, dvs_voltage_nr)) {
+   dev_err(iodev->dev, "buck2 voltages not specified\n");
+   return -EINVAL;
+   }
+   }
+
+   if (of_get_property(pmic_np, "s5m8767,pmic-buck3-uses-gpio-dvs", NULL)) 
{
pdata->buck3_gpiodvs = true;
 
-   if (of_get_property(pmic_np, "s5m8767,pmic-buck4-uses-gpio-dvs", NULL))
+   if (of_property_read_u32_array(pmic_np,
+   "s5m8767,pmic-buck3-dvs-voltage",
+   pdata->buck3_voltage, dvs_voltage_nr)) {
+   dev_err(iodev->dev, "buck3 voltages not specified\n");
+   return -EINVAL;
+   }
+   }
+
+   if (of_get_property(pmic_np, "s5m8767,pmic-buck4-uses-gpio-dvs", NULL)) 
{
pdata->buck4_gpiodvs = true;
 
+   if (of_property_read_u32_array(pmic_np,
+   "s5m8767,pmic-buck4-dvs-voltage",
+   pdata->buck4_voltage, dvs_voltage_nr)) {
+   dev_err(iodev->dev, "buck4 voltages not specified\n");
+   return -EINVAL;
+   }
+   }
+
if (pdata->buck2_gpiodvs || pdata->buck3_gpiodvs ||
pdata->buck4_gpiodvs) {
ret = s5m8767_pmic_dt_parse_dvs_gpio(iodev, pdata, pmic_np);
@@ -612,34 +636,12 @@ static int s5m8767_pmic_dt_parse_pdata(struct 
platform_device *pdev,
"invalid value for default dvs index, use 0\n");
}
}
-   dvs_voltage_nr = 8;
}
 
ret = s5m8767_pmic_dt_parse_ds_gpio(iodev, pdata, pmic_np);
if (ret)
return -EINVAL;
 
-   if (of_property_read_u32_array(pmic_np,
-   "s5m8767,pmic-buck2-dvs-voltage",
-   pdata->buck2_voltage, dvs_voltage_nr)) {
-   dev_err(iodev->dev, "buck2 voltages not specified\n");
-   return -EINVAL;
-   }
-
-   if (of_property_read_u32_array(pmic_np,
-   "s5m8767,pmic-buck3-dvs-voltage",
-   pdata->buck3_voltage, dvs_voltage_nr)) {
-   dev_err(iodev->dev, "buck3 voltages not specified\n");
-   return -EINVAL;
-   }
-
-   if (of_property_read_u32_array(pmic_np,
-   "s5m8767,pmic-buck4-dvs-voltage",
-   pdata->buck4_voltage, dvs_voltage_nr)) {
-   dev_err(iodev->dev, "buck4 voltages not specified\n");
-   return -EINVAL;
-   }
-
if (of_get_property(pmic_np, "s5m8767,pmic-buck2-ramp-enable", NULL))
pdata->buck2_ramp_enable = true;
 
-- 
1.8.0

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

Re: [XFS on bad superblock] BUG: unable to handle kernel NULL pointer dereference at 00000003

[Fengguang Wu]

On Thu, Oct 10, 2013 at 09:16:40AM +0800, Fengguang Wu wrote:
> On Thu, Oct 10, 2013 at 11:59:00AM +1100, Dave Chinner wrote:
> > [add x...@oss.sgi.com to cc]
> 
> Thanks.
> 
> To help debug the problem, I searched XFS in my tests' oops database
> and find one kernel that failed 4 times (out of 12 total boots) with
> basically the same error:
> 
>   4 BUG: sleeping function called from invalid context at 
> kernel/workqueue.c:2810
>   1 WARNING: CPU: 1 PID: 372 at lib/debugobjects.c:260 
> debug_print_object+0x94/0xa2()
>   1 WARNING: CPU: 1 PID: 360 at lib/debugobjects.c:260 
> debug_print_object+0x94/0xa2()
>   1 WARNING: CPU: 0 PID: 381 at lib/debugobjects.c:260 
> debug_print_object+0x94/0xa2()
>   1 WARNING: CPU: 0 PID: 361 at lib/debugobjects.c:260 
> debug_print_object+0x94/0xa2()

And some other messages in an older kernel:

[   39.004416] F2FS-fs (nbd2): unable to read second superblock
[   39.005088] XFS: Assertion failed: read && bp->b_ops, file: 
fs/xfs/xfs_buf.c, line: 1036
[   39.005089] [ cut here ]
[   39.005096] WARNING: CPU: 1 PID: 20 at fs/xfs/xfs_message.c:100 
asswarn+0x33/0x40()
[   39.005099] CPU: 1 PID: 20 Comm: kworker/1:0H Not tainted 
3.11.0-rc1-00667-gf70eb07 #64
[   39.005100] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[   39.005106] Workqueue: xfslogd xfs_buf_iodone_work
[   39.005110]  0009 88000ed91ce0 824044a1 

[   39.005113]  88000ed91d18 8109a0a8 880007d6cea8 
880007d6cd80
[   39.005116]    0060 
88000ed91d28
[   39.005116] Call Trace:
[   39.005122]  [] dump_stack+0x4e/0x82
[   39.005126]  [] warn_slowpath_common+0x78/0xa0
[   39.005129]  [] warn_slowpath_null+0x1a/0x20
[   39.005131]  [] asswarn+0x33/0x40
[   39.005134]  [] xfs_buf_iodone_work+0x92/0x200
[   39.005138]  [] process_one_work+0x1fa/0x6f0
[   39.005141]  [] ? process_one_work+0x198/0x6f0
[   39.005144]  [] worker_thread+0x11d/0x3a0
[   39.005146]  [] ? process_one_work+0x6f0/0x6f0
[   39.005149]  [] kthread+0xed/0x100
[   39.005153]  [] ? trace_hardirqs_on_caller+0xfd/0x1c0
[   39.005156]  [] ? insert_kthread_work+0x80/0x80
[   39.005159]  [] ret_from_fork+0x7c/0xb0
[   39.005162]  [] ? insert_kthread_work+0x80/0x80
[   39.005164] ---[ end trace be5b205ae29d07cd ]---
[   39.028229] block nbd6: Attempted send on closed socket
[   39.028988] block nbd6: Attempted send on closed socket
[   39.029109] block nbd6: Attempted send on closed socket

[   41.550438] block nbd7: Attempted send on closed socket
[   41.550471] [ cut here ]
[   41.550476] WARNING: CPU: 1 PID: 878 at lib/list_debug.c:33 
__list_add+0xac/0xc0()
[   41.550478] list_add corruption. prev->next should be next 
(88000f3d7360), but was   (null). (prev=880008786a30).
[   41.550481] CPU: 1 PID: 878 Comm: mount Not tainted 
3.11.0-rc1-00667-gf70eb07 #64
[   41.550482] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[   41.550485]  0009 880007d6fb08 824044a1 
880007d6fb50
[   41.550488]  880007d6fb40 8109a0a8 880007c6b530 
88000f3d7360
[   41.550491]  880008786a30 0007  
880007d6fba0
[   41.550491] Call Trace:
[   41.550499]  [] dump_stack+0x4e/0x82
[   41.550503]  [] warn_slowpath_common+0x78/0xa0
[   41.550505]  [] warn_slowpath_fmt+0x4c/0x50
[   41.550509]  [] ? get_lock_stats+0x19/0x60
[   41.550511]  [] __list_add+0xac/0xc0
[   41.550515]  [] insert_work+0x43/0xa0
[   41.550518]  [] __queue_work+0x11b/0x510
[   41.550520]  [] queue_work_on+0x96/0xa0
[   41.550526]  [] ? _xfs_buf_ioend.constprop.15+0x26/0x30
[   41.550529]  [] xfs_buf_ioend+0x15c/0x260
[   41.550531]  [] ? xfsbdstrat+0x22/0x170
[   41.550534]  [] _xfs_buf_ioend.constprop.15+0x26/0x30
[   41.550537]  [] xfs_buf_iorequest+0x73/0x1a0
[   41.550539]  [] xfsbdstrat+0x22/0x170
[   41.550542]  [] xfs_buf_read_uncached+0x72/0xa0
[   41.550546]  [] xfs_readsb+0x176/0x250
[   41.550550]  [] xfs_fs_fill_super+0x24a/0x3a0
[   41.550553]  [] mount_bdev+0x1c0/0x200
[   41.550556]  [] ? xfs_parseargs+0xc10/0xc10
[   41.550559]  [] ? lock_release_holdtime.part.29+0xe6/0x160
[   41.550561]  [] xfs_fs_mount+0x15/0x20
[   41.550563]  [] mount_fs+0x39/0x1b0
[   41.550567]  [] ? __alloc_percpu+0x10/0x20
[   41.550571]  [] vfs_kern_mount+0x63/0xf0
[   41.550574]  [] do_mount+0x23e/0xa20
[   41.550577]  [] ? strndup_user+0x4b/0x60
[   41.550579]  [] SyS_mount+0x83/0xc0
[   41.550583]  [] tracesys+0xdd/0xe2
[   41.550584] ---[ end trace 5193f938804cbcca ]---
[   41.550820] block nbd15: Attempted send on closed socket

[   38.738751] block nbd9: Attempted send on closed socket
[   38.738775] F2FS-fs (nbd9): unable to read first superblock
[   38.738852] block nbd9: Attempted send on closed socket
[   38.738875] F2FS-fs (nbd9): unable to read second superblock
 881cbde0 810b9ddf 8800081dfe18
[   

Re: block layer runtime pm and udisks

[Phillip Susi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I have been trying out the new block layer runtime pm, and run into a
problem: udisks keeps waking up the disk.  Every 10 minutes it tries
to poll the SMART status of the drive, but it does first issue an ata
CHECK POWER command to see if it is in standby, and skips the check to
avoid waking the disk.  The problem with runtime pm is that *any*
request brings the drive out of suspend, and the suspend wake path
forces the drive to spin up by issuing a verify command on sector 0.

Is there a reason that the wakeup path forces the drive to spin up, or
could this be removed and rely on the drive waking up automatically if
the request requires it?

Or would it be possible to notice that the command being sent is a
check power command, and fake the reply instead of resuming the device?

Or does udisks just need to check the runtime pm status before trying
the check power command?


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJSVgWPAAoJEJrBOlT6nu75k/cH+gMAb9YtMS21rEt94umJpBYj
BcNoyGoK39tAKZHW7pXfP2hRIm1+kPTPi44Wp7kQHu7m6BSp4YetmDkqjNv+6yAy
8SUvPcqRsJVbF1oBXN09phBEnk/JfxqID7n6hB1lT6NqYV72VVVUEUOlnSnpHtDJ
gszV+TLH37uhd5/KiDFja3J2bJC0R/klzDF1x1clc53tGJd1NZ+h9tZZBLszIdnS
EnjukLA02Q7ooq+445WyWth2cypTXKfRbigZW+FfCI3hfAKOShVevodlGmmrQb7Z
0xzhSoO5JTpNqJPLaNL3+JZFdXwANd+7PuO9v2XVKKUkydQ9+Vl4CfydSFhqo5U=
=iuSZ
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] frontswap: enable call to invalidate area on swapoff

[Bob Liu]

On 10/09/2013 10:40 PM, Seth Jennings wrote:
> On Tue, Oct 08, 2013 at 01:08:53PM -0700, Andrew Morton wrote:
>> On Tue, 08 Oct 2013 10:13:20 +0200 Krzysztof Kozlowski 
>>  wrote:
>>
>>> On pon, 2013-10-07 at 15:03 -0700, Andrew Morton wrote:
 On Mon, 07 Oct 2013 17:25:41 +0200 Krzysztof Kozlowski 
  wrote:

> During swapoff the frontswap_map was NULL-ified before calling
> frontswap_invalidate_area(). However the frontswap_invalidate_area()
> exits early if frontswap_map is NULL. Invalidate was never called during
> swapoff.
>
> This patch moves frontswap_map_set() in swapoff just after calling
> frontswap_invalidate_area() so outside of locks
> (swap_lock and swap_info_struct->lock). This shouldn't be a problem as
> during swapon the frontswap_map_set() is called also outside of any
> locks.
>

 Ahem.  So there's a bunch of code in __frontswap_invalidate_area()
 which hasn't ever been executed and nobody noticed it.  So perhaps that
 code isn't actually needed?

 More seriously, this patch looks like it enables code which hasn't been
 used or tested before.  How well tested was this?

 Are there any runtime-visible effects from this change?
>>>
>>> I tested zswap on x86 and x86-64 and there was no difference. This is
>>> good as there shouldn't be visible anything because swapoff is unusing
>>> all pages anyway:
>>> try_to_unuse(type, false, 0); /* force all pages to be unused */
>>>
>>> I haven't tested other frontswap users.
>>
>> So is that code in __frontswap_invalidate_area() unneeded?
> 
> Yes, to expand on what Bob said, __frontswap_invalidate_area() is still
> needed to let any frontswap backend free per-swaptype resources.
> 
> __frontswap_invalidate_area() is _not_ for freeing structures associated
> with individual swapped out pages since all of the pages should be
> brought back into memory by try_to_unuse() before
> __frontswap_invalidate_area() is called.
> 
> The reason we never noticed this for zswap is that zswap has no
> dynamically allocated per-type resources.  In the expected case,
> where all of the pages have been drained from zswap,
> zswap_frontswap_invalidate_area() is a no-op.
> 

Not exactly, see the bug fix "mm/zswap: bugfix: memory leak when
re-swapon" from Weijie.
Zswap needs invalidate_area() also.

Thanks,
-Bob

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 part1 v6 4/6] x86/mem-hotplug: Support initialize page tables in bottom-up

[Zhang Yanfei]

Hello guys,

On 10/10/2013 07:26 AM, Zhang Yanfei wrote:
> Hello Peter,
> 
> On 10/10/2013 07:10 AM, H. Peter Anvin wrote:
>> On 10/09/2013 02:45 PM, Zhang Yanfei wrote:

 I would also argue that in the VM scenario -- and arguable even in the
 hardware scenario -- the right thing is to not expose the flexible
 memory in the e820/EFI tables, and instead have it hotadded (possibly
 *immediately* so) on boot.  This avoids both the boot time funnies as
 well as the scaling issues with metadata.

>>>
>>> So in this kind of scenario, hotpluggable memory will not be detected
>>> at boot time, and admin should not use this movable_node boot option
>>> and the kernel will act as before, using top-down allocation always.
>>>
>>
>> Yes.  The idea is that the kernel will boot up without the hotplug
>> memory, but if desired, will immediately see a hotplug-add event for the
>> movable memory.
> 
> Yeah, this is good.
> 
> But in the scenario that boot with hotplug memory, we need the movable_node
> option. So as tejun has explained a lot about this patchset, do you still
> have objection to it or could I ask andrew to merge it into -mm tree for
> more tests?
> 

Since tejun has explained a lot about this approach, could we come to
an agreement on this one?

Peter? If you have no objection, I'll post a new v7 version which will fix
the __pa_symbol problem pointed by you.

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

Re: [PATCH v3] btrfs: Fix memory leakage in the tree-log.c

[Geyslan Gregório Bem]

Josef,

Thank you. Sending v4.

Geyslan Gregório Bem
hackingbits.com


2013/10/9 Josef Bacik :
> On Wed, Oct 09, 2013 at 08:40:30PM -0300, Geyslan G. Bem wrote:
>> In some cases, add_inode_ref() is returning without freeing
>> the 'name' pointer.
>>
>> Added bail out to explicitly call kfree when necessary.
>>
>> Signed-off-by: Geyslan G. Bem 
>> ---
>>  fs/btrfs/tree-log.c | 10 --
>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
>> index 79f057c..ad7cc5f 100644
>> --- a/fs/btrfs/tree-log.c
>> +++ b/fs/btrfs/tree-log.c
>> @@ -1170,13 +1170,16 @@ static noinline int add_inode_ref(struct 
>> btrfs_trans_handle *trans,
>>   if (!dir)
>>   dir = read_one_inode(root, parent_objectid);
>>   if (!dir)
>> - return -ENOENT;
>> + {
>> + ret = -ENOENT;
>> + goto bail;
>> + }
>
> Code formatting is
>
> if () {
> }
>
> not
>
> if ()
> {
> }
>
>
>>   } else {
>>   ret = ref_get_fields(eb, ref_ptr, , ,
>>_index);
>>   }
>>   if (ret)
>> - return ret;
>> + goto bail;
>>
>>   /* if we already have a perfect match, we're done */
>>   if (!inode_in_dir(root, path, btrfs_ino(dir), btrfs_ino(inode),
>> @@ -1227,6 +1230,9 @@ out:
>>   btrfs_release_path(path);
>>   iput(dir);
>>   iput(inode);
>> +bail:
>> + if (name)
>> + kfree(name);
>
> kfree already does the if (name) part of this so this is redundant.  Also if 
> you
> are going to do this you need to set name = NULL; after the kfree above it
> otherwise we have a double free.  Thanks,
>
> Josef
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [XFS on bad superblock] BUG: unable to handle kernel NULL pointer dereference at 00000003

[Fengguang Wu]

On Thu, Oct 10, 2013 at 11:59:00AM +1100, Dave Chinner wrote:
> [add x...@oss.sgi.com to cc]

Thanks.

To help debug the problem, I searched XFS in my tests' oops database
and find one kernel that failed 4 times (out of 12 total boots) with
basically the same error:

  4 BUG: sleeping function called from invalid context at 
kernel/workqueue.c:2810
  1 WARNING: CPU: 1 PID: 372 at lib/debugobjects.c:260 
debug_print_object+0x94/0xa2()
  1 WARNING: CPU: 1 PID: 360 at lib/debugobjects.c:260 
debug_print_object+0x94/0xa2()
  1 WARNING: CPU: 0 PID: 381 at lib/debugobjects.c:260 
debug_print_object+0x94/0xa2()
  1 WARNING: CPU: 0 PID: 361 at lib/debugobjects.c:260 
debug_print_object+0x94/0xa2()

dmesg-yocto-cairo-28:20131004225501:i386-randconfig-j0-10042023:3.12.0-rc2-next-20130927-03100-ga0cf1ab:3

[   29.709162] qnx6: unable to set blocksize
[   29.716037] ADFS-fs error (device zram0): adfs_fill_super: unable to read 
superblock
[   29.719395] [ cut here ]
[   29.719838] WARNING: CPU: 1 PID: 372 at lib/debugobjects.c:260 
debug_print_object+0x94/0xa2()
[   29.720016] ODEBUG: free active (active state 0) object type: work_struct 
hint: xfs_buf_iodone_work+0x0/0xfe
[   29.720016] CPU: 1 PID: 372 Comm: mount Not tainted 
3.12.0-rc2-next-20130927-03100-ga0cf1ab #3
[   29.720016]    8a3efd30 8275c9a2 8a3efd70  0104 
8a3efd60
[   29.720016]  8103f5e3 8334fafe 8a3efd8c 0174 8334fb3b 0104 817001fb 
817001fb
[   29.720016]  8a121e90 8355b58c 83323588 8a3efd78 8103f641 0009 8a3efd70 
8334fafe
[   29.720016] Call Trace:
[   29.720016]  [<8275c9a2>] dump_stack+0x7a/0xaa
[   29.720016]  [<8103f5e3>] warn_slowpath_common+0x8c/0xa3
[   29.720016]  [<817001fb>] ? debug_print_object+0x94/0xa2
[   29.720016]  [<817001fb>] ? debug_print_object+0x94/0xa2
[   29.720016]  [<8103f641>] warn_slowpath_fmt+0x2e/0x30
[   29.720016]  [<817001fb>] debug_print_object+0x94/0xa2
[   29.720016]  [<81344703>] ? xfs_buf_unlock+0x17f/0x17f
[   29.720016]  [<81700f1a>] debug_check_no_obj_freed+0xe2/0x1f8
[   29.720016]  [<8115aaa1>] kmem_cache_free+0xfe/0x32b
[   29.720016]  [<81342be0>] xfs_buf_free+0x263/0x26f
[   29.720016]  [<81343a71>] xfs_buf_rele+0x3e0/0x3f0
[   29.720016]  [<813635f6>] ? xfs_readsb+0x25e/0x268
[   29.720016]  [<813635f6>] xfs_readsb+0x25e/0x268
[   29.720016]  [<827243a5>] ? register_cpu_notifier+0x20/0x27
[   29.720016]  [<81367344>] xfs_fs_fill_super+0x27d/0x495
[   29.720016]  [<813670c7>] ? xfs_finish_flags+0x24e/0x24e
[   29.720016]  [<811666bf>] mount_bdev+0x1d6/0x256
[   29.720016]  [<813670c7>] ? xfs_finish_flags+0x24e/0x24e
[   29.720016]  [<8115a80b>] ? __kmalloc_track_caller+0x21a/0x3b2
[   29.720016]  [<816d87d6>] ? ida_get_new_above+0x24a/0x25b
[   29.720016]  [<81364b69>] xfs_fs_mount+0x1a/0x1f
[   29.720016]  [<813670c7>] ? xfs_finish_flags+0x24e/0x24e
[   29.720016]  [<81166a09>] mount_fs+0x38/0x1b3
[   29.720016]  [<811395a4>] ? __alloc_percpu+0xa/0xc
[   29.720016]  [<8118b7ff>] ? alloc_vfsmnt+0x108/0x1d6
[   29.720016]  [<8118ca68>] vfs_kern_mount+0x97/0x123
[   29.720016]  [<8118ef8f>] do_mount+0xc8e/0xe0d
[   29.720016]  [<8118e2e3>] ? copy_mount_string+0x51/0x6f
[   29.720016]  [<8118f1ee>] SyS_mount+0xe0/0x10d
[   29.720016]  [<827889ff>] syscall_call+0x7/0xb
[   29.720016] ---[ end trace dbf8d35123ab64b3 ]---
[   29.720016] BUG: sleeping function called from invalid context at 
kernel/workqueue.c:2810

dmesg-yocto-cairo-33:20131004225518:i386-randconfig-j0-10042023:3.12.0-rc2-next-20130927-03100-ga0cf1ab:3

[   30.423344] qnx6: unable to set blocksize
[   30.424465] ADFS-fs error (device zram0): adfs_fill_super: unable to read 
superblock
[   30.428281] [ cut here ]
[   30.428765] WARNING: CPU: 0 PID: 381 at lib/debugobjects.c:260 
debug_print_object+0x94/0xa2()
[   30.429826] ODEBUG: free active (active state 0) object type: work_struct 
hint: xfs_buf_iodone_work+0x0/0xfe
[   30.430014] CPU: 0 PID: 381 Comm: mount Not tainted 
3.12.0-rc2-next-20130927-03100-ga0cf1ab #3
[   30.430014]    8982dd30 8275c9a2 8982dd70  0104 
8982dd60
[   30.430014]  8103f5e3 8334fafe 8982dd8c 017d 8334fb3b 0104 817001fb 
817001fb
[   30.430014]  8a7ba8c0 8355b58c 83323588 8982dd78 8103f641 0009 8982dd70 
8334fafe
[   30.434063] Call Trace:
[   30.434063]  [<8275c9a2>] dump_stack+0x7a/0xaa
[   30.434063]  [<8103f5e3>] warn_slowpath_common+0x8c/0xa3
[   30.434063]  [<817001fb>] ? debug_print_object+0x94/0xa2
[   30.434063]  [<817001fb>] ? debug_print_object+0x94/0xa2
[   30.434063]  [<8103f641>] warn_slowpath_fmt+0x2e/0x30
[   30.434063]  [<817001fb>] debug_print_object+0x94/0xa2
[   30.434063]  [<81344703>] ? xfs_buf_unlock+0x17f/0x17f
[   30.434063]  [<81700f1a>] debug_check_no_obj_freed+0xe2/0x1f8
[   30.434063]  [<8115aaa1>] kmem_cache_free+0xfe/0x32b
[   30.434063]  [<81342be0>] xfs_buf_free+0x263/0x26f
[   30.434063]  [<81343a71>] xfs_buf_rele+0x3e0/0x3f0
[   

[PATCH] mfd: max77693: Fix up bug of wrong interrupt number

[Chanwoo Choi]

The max77693 MFD device use irq domain method which has hardware interrupt 
number
and virtual interrupt number getting through irq domain mapping. This patch
use hardware interrupt number instead of virtual interrupt number to get
struct irq_data.

Signed-off-by: Chanwoo Choi 
Signed-off-by: Kyungmin Park 
---
 drivers/mfd/max77693-irq.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/max77693-irq.c b/drivers/mfd/max77693-irq.c
index 1029d01..66b58fe 100644
--- a/drivers/mfd/max77693-irq.c
+++ b/drivers/mfd/max77693-irq.c
@@ -128,7 +128,8 @@ static void max77693_irq_sync_unlock(struct irq_data *data)
 static const inline struct max77693_irq_data *
 irq_to_max77693_irq(struct max77693_dev *max77693, int irq)
 {
-   return _irqs[irq];
+   struct irq_data *data = irq_get_irq_data(irq);
+   return _irqs[data->hwirq];
 }
 
 static void max77693_irq_mask(struct irq_data *data)
-- 
1.8.0

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

Re: [PATCH 1/8] perf callchain: Convert children list to rbtree

[Namhyung Kim]

Hi Frederic,

On Tue, 8 Oct 2013 21:22:45 +0200, Frederic Weisbecker wrote:
> On Tue, Oct 08, 2013 at 11:03:16AM +0900, Namhyung Kim wrote:
>> On Wed, 2 Oct 2013 12:18:28 +0200, Frederic Weisbecker wrote:
>> > Have you tested this patchset when collapsing is not used?
>> > There are fair chances that this patchset does not only improve collapsing
>> > but also callchain insertion in general. So it's probably a win in any 
>> > case. But
>> > still it would be nice to make sure that it's the case because we are 
>> > getting
>> > rid of collapsing anyway.
>> >
>> > The test that could tell us about that is to run "perf report -s sym" and 
>> > compare the
>> > time it takes to complete before and after this patch, because "-s sym" 
>> > shouldn't
>> > involve collapses.
>> >
>> > Sorting by anything that is not comm should do the trick in fact.
>> 
>> Yes, I have similar result when collapsing is not used.  Actually when I
>> ran "perf report -s sym", the performance improves higher since it'd
>> insert more callchains in a hist entry.
>
> Great! I'll have a closer look and review on the callchain patches then. 
> Please
> resend these along the comm batch.

I'll do it later today or tomorrow.

Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: 6e543d5780e fixed a boot hang

[Lisa Du]

>-Original Message-
>From: Fengguang Wu [mailto:fengguang...@intel.com]
>Sent: 2013年10月9日 22:12
>To: Lisa Du
>Cc: KOSAKI Motohiro; linux...@kvack.org; linux-kernel@vger.kernel.org
>Subject: 6e543d5780e fixed a boot hang
>
>Greetings,
>
>FYI, this commit seem to fix a boot hang problem here.
>
>commit 6e543d5780e36ff5ee56c44d7e2e30db3457a7ed
>Author: Lisa Du 
>Date:   Wed Sep 11 14:22:36 2013 -0700
>
>mm: vmscan: fix do_try_to_free_pages() livelock
>
>
>[1.394871] pci :00:02.0: Boot video device
>[1.395883] PCI: CLS 0 bytes, default 64
>
>In parent commit, it will hang right here.
>
>With this commit, it will continue to emit the below OOM messages (which is 
>not a surprise to me because the boot test runs in a small
>memory KVM and the kconfig builds in lots of drivers).
I think you may meet the same issue as mine.
Direct reclaim loop forever with zone->all_unreclaimable = 0(as kswapd sleeps 
forever).
And at the boot stage, no one detect and terminate it, so you see the boot 
hang. 
After apply this patch, you see there's oom-killer invoked as direct reclaim 
would break when zone was unreclaimable.
>
>[1.631892] swapper/0 invoked oom-killer: gfp_mask=0x2000d0, 
> order=1, oom_score_adj=0
>[1.633549] swapper/0 cpuset=/ mems_allowed=0
>[1.634443] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 
> 3.12.0-rc4-00019-g8b5ede6 #126
>[1.635982] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
>[1.637088]  0002 88001dd41b28 82c8d78f 
> 88001ef7c040
>[1.638955]  88001dd41ba8 82c8395f 83c54680 
> 88001dd41b60
>[1.640830]  810f3f06 1eb4 0246 
> 88001dd41b98
>[1.642687] Call Trace:
>[1.643313]  [] dump_stack+0x54/0x74
>[1.644331]  [] dump_header.isra.10+0x7a/0x1ba
>[1.645443]  [] ? 
> lock_release_holdtime.part.27+0x4c/0x50
>[1.646685]  [] ? lock_release+0x189/0x1d1
>[1.647744]  [] out_of_memory+0x39e/0x3ee
>[1.648882]  [] __alloc_pages_nodemask+0x668/0x7de
>[1.650385]  [] kmem_getpages+0x75/0x16c
>[1.651429]  [] fallback_alloc+0x12c/0x1ea
>[1.652528]  [] ? trace_hardirqs_off+0xd/0xf
>[1.653627]  [] cache_alloc_node+0x14a/0x159
>[1.654783]  [] ? dma_debug_init+0x1ef/0x29a
>[1.655928]  [] kmem_cache_alloc_trace+0x83/0x11a
>[1.657108]  [] dma_debug_init+0x1ef/0x29a
>[1.658182]  [] pci_iommu_init+0x16/0x52
>[1.659263]  [] ? iommu_setup+0x27d/0x27d
>[1.660342]  [] do_one_initcall+0x93/0x137
>[1.661415]  [] ? param_set_charp+0x92/0xd8
>[1.662503]  [] ? parse_args+0x189/0x247
>[1.663555]  [] kernel_init_freeable+0x15e/0x1df
>[1.664724]  [] ? do_early_param+0x88/0x88
>[1.665814]  [] ? rest_init+0xdb/0xdb
>[1.666824]  [] kernel_init+0xe/0xdb
>[1.667824]  [] ret_from_fork+0x7c/0xb0
>[1.668911]  [] ? rest_init+0xdb/0xdb
>[1.669925] Mem-Info:
>[1.670508] Node 0 DMA per-cpu:
>
>Thanks,
>Fengguang
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�:+v�����赙zZ+��+zf＂�h���~i���z��wア�?�ㄨ��&�)撷f��^j谦y�m��@A�a囤�
0鹅h���i

[PATCH 2/3] HID:hid-lg: Fixed Report Descriptor for Logitech MOMO Force (Black) to split Accel/Brake into seperate axis

[Simon Wood]

Signed-off-by: Simon Wood 
---
 drivers/hid/hid-lg.c | 58 
 1 file changed, 58 insertions(+)

diff --git a/drivers/hid/hid-lg.c b/drivers/hid/hid-lg.c
index c6efdae..545da44 100644
--- a/drivers/hid/hid-lg.c
+++ b/drivers/hid/hid-lg.c
@@ -47,6 +47,7 @@
 #define DFP_RDESC_ORIG_SIZE97
 #define FV_RDESC_ORIG_SIZE 130
 #define MOMO_RDESC_ORIG_SIZE   87
+#define MOMO2_RDESC_ORIG_SIZE  87
 
 /* Fixed report descriptors for Logitech Driving Force (and Pro)
  * wheel controllers
@@ -284,6 +285,54 @@ static __u8 momo_rdesc_fixed[] = {
 0xC0/*  End Collection  */
 };
 
+static __u8 momo2_rdesc_fixed[] = {
+0x05, 0x01, /*  Usage Page (Desktop),   */
+0x09, 0x04, /*  Usage (Joystik),*/
+0xA1, 0x01, /*  Collection (Application),   */
+0xA1, 0x02, /*  Collection (Logical),   */
+0x95, 0x01, /*  Report Count (1),   */
+0x75, 0x0A, /*  Report Size (10),   */
+0x15, 0x00, /*  Logical Minimum (0),*/
+0x26, 0xFF, 0x03,   /*  Logical Maximum (1023), */
+0x35, 0x00, /*  Physical Minimum (0),   */
+0x46, 0xFF, 0x03,   /*  Physical Maximum (1023),*/
+0x09, 0x30, /*  Usage (X),  */
+0x81, 0x02, /*  Input (Variable),   */
+0x95, 0x0A, /*  Report Count (10),  */
+0x75, 0x01, /*  Report Size (1),*/
+0x25, 0x01, /*  Logical Maximum (1),*/
+0x45, 0x01, /*  Physical Maximum (1),   */
+0x05, 0x09, /*  Usage Page (Button),*/
+0x19, 0x01, /*  Usage Minimum (01h),*/
+0x29, 0x0A, /*  Usage Maximum (0Ah),*/
+0x81, 0x02, /*  Input (Variable),   */
+0x06, 0x00, 0xFF,   /*  Usage Page (FF00h), */
+0x09, 0x00, /*  Usage (00h),*/
+0x95, 0x04, /*  Report Count (4),   */
+0x81, 0x02, /*  Input (Variable),   */
+0x95, 0x01, /*  Report Count (1),   */
+0x75, 0x08, /*  Report Size (8),*/
+0x26, 0xFF, 0x00,   /*  Logical Maximum (255),  */
+0x46, 0xFF, 0x00,   /*  Physical Maximum (255), */
+0x09, 0x01, /*  Usage (01h),*/
+0x81, 0x02, /*  Input (Variable),   */
+0x05, 0x01, /*  Usage Page (Desktop),   */
+0x09, 0x31, /*  Usage (Y),  */
+0x81, 0x02, /*  Input (Variable),   */
+0x09, 0x32, /*  Usage (Z),  */
+0x81, 0x02, /*  Input (Variable),   */
+0x06, 0x00, 0xFF,   /*  Usage Page (FF00h), */
+0x09, 0x00, /*  Usage (00h),*/
+0x81, 0x02, /*  Input (Variable),   */
+0xC0,   /*  End Collection, */
+0xA1, 0x02, /*  Collection (Logical),   */
+0x09, 0x02, /*  Usage (02h),*/
+0x95, 0x07, /*  Report Count (7),   */
+0x91, 0x02, /*  Output (Variable),  */
+0xC0,   /*  End Collection, */
+0xC0/*  End Collection  */
+};
+
 /*
  * Certain Logitech keyboards send in report #3 keys which are far
  * above the logical maximum described in descriptor. This extends
@@ -343,6 +392,15 @@ static __u8 *lg_report_fixup(struct hid_device *hdev, __u8 
*rdesc,
}
break;
 
+   case USB_DEVICE_ID_LOGITECH_MOMO_WHEEL2:
+   if (*rsize == MOMO2_RDESC_ORIG_SIZE) {
+   hid_info(hdev,
+   "fixing up Logitech Momo Racing Force (Black) 
report descriptor\n");
+   rdesc = momo2_rdesc_fixed;
+   *rsize = sizeof(momo2_rdesc_fixed);
+   }
+   break;
+
case USB_DEVICE_ID_LOGITECH_VIBRATION_WHEEL:
if (*rsize == FV_RDESC_ORIG_SIZE) {
hid_info(hdev,
-- 
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 3/3] HID:Kconfig: Correct MOMO description in wrong place (handled by LG4FF).

[Simon Wood]

Signed-off-by: Simon Wood 
---
 drivers/hid/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 46fd27f..aee7182 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -362,7 +362,6 @@ config LOGITECH_FF
  - Logitech WingMan Force 3D
  - Logitech Formula Force EX
  - Logitech WingMan Formula Force GP
- - Logitech MOMO Force wheel
 
  and if you want to enable force feedback for them.
  Note: if you say N here, this device will still be supported, but 
without
-- 
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 1/3] HID:hid-lg: Fixed ReportDescriptor for Logitech Formular Vibration to split Accel/Brake into seperate axis

[Simon Wood]

Requires https://patchwork.kernel.org/patch/2998241/

Signed-off-by: Simon Wood 
---
 drivers/hid/hid-lg.c | 77 
 1 file changed, 77 insertions(+)

diff --git a/drivers/hid/hid-lg.c b/drivers/hid/hid-lg.c
index c2c7dab..c6efdae 100644
--- a/drivers/hid/hid-lg.c
+++ b/drivers/hid/hid-lg.c
@@ -45,6 +45,7 @@
 /* Size of the original descriptors of the Driving Force (and Pro) wheels */
 #define DF_RDESC_ORIG_SIZE 130
 #define DFP_RDESC_ORIG_SIZE97
+#define FV_RDESC_ORIG_SIZE 130
 #define MOMO_RDESC_ORIG_SIZE   87
 
 /* Fixed report descriptors for Logitech Driving Force (and Pro)
@@ -170,6 +171,73 @@ static __u8 dfp_rdesc_fixed[] = {
 0xC0/*  End Collection  */
 };
 
+static __u8 fv_rdesc_fixed[] = {
+0x05, 0x01, /*  Usage Page (Desktop),   */
+0x09, 0x04, /*  Usage (Joystik),*/
+0xA1, 0x01, /*  Collection (Application),   */
+0xA1, 0x02, /*  Collection (Logical),   */
+0x95, 0x01, /*  Report Count (1),   */
+0x75, 0x0A, /*  Report Size (10),   */
+0x15, 0x00, /*  Logical Minimum (0),*/
+0x26, 0xFF, 0x03,   /*  Logical Maximum (1023), */
+0x35, 0x00, /*  Physical Minimum (0),   */
+0x46, 0xFF, 0x03,   /*  Physical Maximum (1023),*/
+0x09, 0x30, /*  Usage (X),  */
+0x81, 0x02, /*  Input (Variable),   */
+0x95, 0x0C, /*  Report Count (12),  */
+0x75, 0x01, /*  Report Size (1),*/
+0x25, 0x01, /*  Logical Maximum (1),*/
+0x45, 0x01, /*  Physical Maximum (1),   */
+0x05, 0x09, /*  Usage Page (Button),*/
+0x19, 0x01, /*  Usage Minimum (01h),*/
+0x29, 0x0C, /*  Usage Maximum (0Ch),*/
+0x81, 0x02, /*  Input (Variable),   */
+0x95, 0x02, /*  Report Count (2),   */
+0x06, 0x00, 0xFF,   /*  Usage Page (FF00h), */
+0x09, 0x01, /*  Usage (01h),*/
+0x81, 0x02, /*  Input (Variable),   */
+0x09, 0x02, /*  Usage (02h),*/
+0x26, 0xFF, 0x00,   /*  Logical Maximum (255),  */
+0x46, 0xFF, 0x00,   /*  Physical Maximum (255), */
+0x95, 0x01, /*  Report Count (1),   */
+0x75, 0x08, /*  Report Size (8),*/
+0x81, 0x02, /*  Input (Variable),   */
+0x05, 0x01, /*  Usage Page (Desktop),   */
+0x25, 0x07, /*  Logical Maximum (7),*/
+0x46, 0x3B, 0x01,   /*  Physical Maximum (315), */
+0x75, 0x04, /*  Report Size (4),*/
+0x65, 0x14, /*  Unit (Degrees), */
+0x09, 0x39, /*  Usage (Hat Switch), */
+0x81, 0x42, /*  Input (Variable, Null State),   */
+0x75, 0x01, /*  Report Size (1),*/
+0x95, 0x04, /*  Report Count (4),   */
+0x65, 0x00, /*  Unit,   */
+0x06, 0x00, 0xFF,   /*  Usage Page (FF00h), */
+0x09, 0x01, /*  Usage (01h),*/
+0x25, 0x01, /*  Logical Maximum (1),*/
+0x45, 0x01, /*  Physical Maximum (1),   */
+0x81, 0x02, /*  Input (Variable),   */
+0x05, 0x01, /*  Usage Page (Desktop),   */
+0x95, 0x01, /*  Report Count (1),   */
+0x75, 0x08, /*  Report Size (8),*/
+0x26, 0xFF, 0x00,   /*  Logical Maximum (255),  */
+0x46, 0xFF, 0x00,   /*  Physical Maximum (255), */
+0x09, 0x31, /*  Usage (Y),  */
+0x81, 0x02, /*  Input (Variable),   */
+0x09, 0x32, /*  Usage (Z),  */
+0x81, 0x02, /*  Input (Variable),   */
+0xC0,   /*  End Collection, */
+0xA1, 0x02, /*  Collection (Logical),   */
+0x26, 0xFF, 0x00,   /*  Logical Maximum (255),  */
+0x46, 0xFF, 0x00,   /*  Physical Maximum (255), */
+0x95, 0x07, /*  Report Count (7),   */
+0x75, 0x08, /*  Report Size (8),*/
+0x09, 0x03, /*  Usage (03h),*/
+0x91, 0x02, /*  Output 

Re: [PATCH v4 3/4] ACPI / video: Do not register backlight if win8 and native interface exists

[Aaron Lu]

On 10/10/2013 08:29 AM, Rafael J. Wysocki wrote:
> On Tuesday, October 08, 2013 02:40:00 PM Aaron Lu wrote:
>> According to Matthew Garrett, "Windows 8 leaves backlight control up
>> to individual graphics drivers rather than making ACPI calls itself.
>> There's plenty of evidence to suggest that the Intel driver for
>> Windows [8] doesn't use the ACPI interface, including the fact that
>> it's broken on a bunch of machines when the OS claims to support
>> Windows 8.  The simplest thing to do appears to be to disable the
>> ACPI backlight interface on these systems".
>>
>> So for Win8 systems, if there is native backlight control interface
>> registered by GPU driver, ACPI video will not register its own. For
>> users who prefer to keep ACPI video's backlight interface, the existing
>> kernel cmdline option acpi_backlight=video can be used.
>>
>> Signed-off-by: Aaron Lu 
>> Tested-by: Igor Gnatenko 
>> Tested-by: Yves-Alexis Perez 
>> Tested-by: Mika Westerberg 
>> ---
>>  drivers/acpi/internal.h |  5 ++---
>>  drivers/acpi/video.c| 10 +-
>>  drivers/acpi/video_detect.c | 14 --
>>  3 files changed, 19 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
>> index 20f4233..453ae8d 100644
>> --- a/drivers/acpi/internal.h
>> +++ b/drivers/acpi/internal.h
>> @@ -169,9 +169,8 @@ int acpi_create_platform_device(struct acpi_device *adev,
>>  Video
>>
>> -- */
>>  #if defined(CONFIG_ACPI_VIDEO) || defined(CONFIG_ACPI_VIDEO_MODULE)
>> -bool acpi_video_backlight_quirks(void);
>> -#else
>> -static inline bool acpi_video_backlight_quirks(void) { return false; }
>> +bool acpi_osi_is_win8(void);
>> +bool acpi_video_verify_backlight_support(void);
>>  #endif
>>  
>>  #endif /* _ACPI_INTERNAL_H_ */
>> diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
>> index 3bd1eaa..343db59 100644
>> --- a/drivers/acpi/video.c
>> +++ b/drivers/acpi/video.c
>> @@ -1256,8 +1256,8 @@ acpi_video_switch_brightness(struct acpi_video_device 
>> *device, int event)
>>  unsigned long long level_current, level_next;
>>  int result = -EINVAL;
>>  
>> -/* no warning message if acpi_backlight=vendor is used */
>> -if (!acpi_video_backlight_support())
>> +/* no warning message if acpi_backlight=vendor or a quirk is used */
>> +if (!acpi_video_verify_backlight_support())
>>  return 0;
>>  
>>  if (!device->brightness)
>> @@ -1386,13 +1386,13 @@ acpi_video_bus_get_devices(struct acpi_video_bus 
>> *video,
>>  static int acpi_video_bus_start_devices(struct acpi_video_bus *video)
>>  {
>>  return acpi_video_bus_DOS(video, 0,
>> -  acpi_video_backlight_quirks() ? 1 : 0);
>> +  acpi_osi_is_win8() ? 1 : 0);
>>  }
>>  
>>  static int acpi_video_bus_stop_devices(struct acpi_video_bus *video)
>>  {
>>  return acpi_video_bus_DOS(video, 0,
>> -  acpi_video_backlight_quirks() ? 0 : 1);
>> +  acpi_osi_is_win8() ? 0 : 1);
>>  }
>>  
>>  static void acpi_video_bus_notify(struct acpi_device *device, u32 event)
>> @@ -1558,7 +1558,7 @@ acpi_video_bus_match(acpi_handle handle, u32 level, 
>> void *context,
>>  
>>  static void acpi_video_dev_register_backlight(struct acpi_video_device 
>> *device)
>>  {
>> -if (acpi_video_backlight_support()) {
>> +if (acpi_video_verify_backlight_support()) {
>>  struct backlight_properties props;
>>  struct pci_dev *pdev;
>>  acpi_handle acpi_parent;
>> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
>> index 940edbf..23d7d26 100644
>> --- a/drivers/acpi/video_detect.c
>> +++ b/drivers/acpi/video_detect.c
>> @@ -37,6 +37,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  #include "internal.h"
>>  
>> @@ -233,11 +234,11 @@ static void acpi_video_caps_check(void)
>>  acpi_video_get_capabilities(NULL);
>>  }
>>  
>> -bool acpi_video_backlight_quirks(void)
>> +bool acpi_osi_is_win8(void)
>>  {
>>  return acpi_gbl_osi_data >= ACPI_OSI_WIN_8;
>>  }
>> -EXPORT_SYMBOL(acpi_video_backlight_quirks);
>> +EXPORT_SYMBOL(acpi_osi_is_win8);
>>  
>>  /* Promote the vendor interface instead of the generic video module.
>>   * This function allow DMI blacklists to be implemented by externals
>> @@ -283,6 +284,15 @@ int acpi_video_backlight_support(void)
>>  }
>>  EXPORT_SYMBOL(acpi_video_backlight_support);
>>  
>> +bool acpi_video_verify_backlight_support(void)
>> +{
>> +if (!(acpi_video_support & ACPI_VIDEO_BACKLIGHT_FORCE_VIDEO) &&
>> +acpi_osi_is_win8() && backlight_device_registered(BACKLIGHT_RAW))
>> +return false;
> 
> If I'm not mistaken, this will introduce a regression for the people who have
> problems with the native i915 backlight on Win8-compatible systems.  I'd 

Re: [PATCH v4 1/4] backlight: introduce backlight_device_registered

[Rafael J. Wysocki]

On Thursday, October 10, 2013 08:54:29 AM Aaron Lu wrote:
> On 10/10/2013 08:25 AM, Rafael J. Wysocki wrote:
> > On Tuesday, October 08, 2013 02:39:58 PM Aaron Lu wrote:
> >> Introduce a new API for modules to query if a specific type of backlight
> >> device has been registered. This is useful for some backlight device
> >> provider module(e.g. ACPI video) to know if a native control
> >> interface(e.g. the interface created by i915) is available and then do
> >> things accordingly(e.g. avoid register its own on Win8 systems).
> >>
> >> Signed-off-by: Aaron Lu 
> >> Tested-by: Igor Gnatenko 
> >> Tested-by: Yves-Alexis Perez 
> >> Tested-by: Mika Westerberg 
> >> ---
> >>  drivers/video/backlight/backlight.c | 31 +++
> >>  include/linux/backlight.h   |  4 
> >>  2 files changed, 35 insertions(+)
> >>
> >> diff --git a/drivers/video/backlight/backlight.c 
> >> b/drivers/video/backlight/backlight.c
> >> index 94a403a..bf2d71d 100644
> >> --- a/drivers/video/backlight/backlight.c
> >> +++ b/drivers/video/backlight/backlight.c
> >> @@ -21,6 +21,9 @@
> >>  #include 
> >>  #endif
> >>  
> >> +static struct list_head bd_list_head;
> >> +static struct mutex bd_list_mutex;
> > 
> > I'd prefer these two things to be called backlight_dev_list and
> > backlight_dev_list_mutex, respectively.
> 
> OK.
> 
> > 
> >> +
> >>  static const char *const backlight_types[] = {
> >>[BACKLIGHT_RAW] = "raw",
> >>[BACKLIGHT_PLATFORM] = "platform",
> >> @@ -349,10 +352,32 @@ struct backlight_device 
> >> *backlight_device_register(const char *name,
> >>mutex_unlock(_backlight_mutex);
> >>  #endif
> >>  
> >> +  mutex_lock(_list_mutex);
> >> +  list_add(_bd->entry, _list_head);
> >> +  mutex_unlock(_list_mutex);
> >> +
> >>return new_bd;
> >>  }
> >>  EXPORT_SYMBOL(backlight_device_register);
> >>  
> >> +bool backlight_device_registered(enum backlight_type type)
> >> +{
> >> +  bool found = false;
> >> +  struct backlight_device *bd;
> >> +
> >> +  mutex_lock(_list_mutex);
> >> +  list_for_each_entry(bd, _list_head, entry) {
> >> +  if (bd->props.type == type) {
> >> +  found = true;
> >> +  break;
> >> +  }
> >> +  }
> > 
> > Isn't it useful to be able to register more than one backlight device of the
> > same type sometimes?
> 
> I think so for some kind of computers. OTOH, the above function should
> be enough for the problem we are solving here, if someday we need to
> differentiate, we can enhance the code then.

OK

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] i2c designware make SCL and SDA falling time configurable

[Ryan Mallon]

On 09/10/13 18:55, Mika Westerberg wrote:
> On Tue, Oct 08, 2013 at 05:00:54PM +0200, Romain Baeriswyl wrote:
>>  static void __i2c_dw_enable(struct dw_i2c_dev *dev, bool enable)
>> @@ -286,6 +287,7 @@ int i2c_dw_init(struct dw_i2c_dev *dev)
>>  u32 input_clock_khz;
>>  u32 hcnt, lcnt;
>>  u32 reg;
>> +u32 sda_falling_time, scl_falling_time;
>>  
>>  input_clock_khz = dev->get_clk_rate_khz(dev);
>>  
>> @@ -307,15 +309,25 @@ int i2c_dw_init(struct dw_i2c_dev *dev)
>>  
>>  /* set standard and fast speed deviders for high/low periods */
>>  
>> +if (dev->sda_falling_time)
>> +sda_falling_time = dev->sda_falling_time;
>> +else
>> +sda_falling_time = 300; /* ns */
> 
> I think this looks better:
> 
>   sda_falling_time = dev->sda_falling_time ? dev->sda_falling_time : 300;

You can also use the gcc-ism, which is a bit more concise:

sda_falling_time = dev->sda_falling_time ?: 300;

~Ryan

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

Re: [PATCH v4 1/4] backlight: introduce backlight_device_registered

[Aaron Lu]

On 10/10/2013 08:25 AM, Rafael J. Wysocki wrote:
> On Tuesday, October 08, 2013 02:39:58 PM Aaron Lu wrote:
>> Introduce a new API for modules to query if a specific type of backlight
>> device has been registered. This is useful for some backlight device
>> provider module(e.g. ACPI video) to know if a native control
>> interface(e.g. the interface created by i915) is available and then do
>> things accordingly(e.g. avoid register its own on Win8 systems).
>>
>> Signed-off-by: Aaron Lu 
>> Tested-by: Igor Gnatenko 
>> Tested-by: Yves-Alexis Perez 
>> Tested-by: Mika Westerberg 
>> ---
>>  drivers/video/backlight/backlight.c | 31 +++
>>  include/linux/backlight.h   |  4 
>>  2 files changed, 35 insertions(+)
>>
>> diff --git a/drivers/video/backlight/backlight.c 
>> b/drivers/video/backlight/backlight.c
>> index 94a403a..bf2d71d 100644
>> --- a/drivers/video/backlight/backlight.c
>> +++ b/drivers/video/backlight/backlight.c
>> @@ -21,6 +21,9 @@
>>  #include 
>>  #endif
>>  
>> +static struct list_head bd_list_head;
>> +static struct mutex bd_list_mutex;
> 
> I'd prefer these two things to be called backlight_dev_list and
> backlight_dev_list_mutex, respectively.

OK.

> 
>> +
>>  static const char *const backlight_types[] = {
>>  [BACKLIGHT_RAW] = "raw",
>>  [BACKLIGHT_PLATFORM] = "platform",
>> @@ -349,10 +352,32 @@ struct backlight_device 
>> *backlight_device_register(const char *name,
>>  mutex_unlock(_backlight_mutex);
>>  #endif
>>  
>> +mutex_lock(_list_mutex);
>> +list_add(_bd->entry, _list_head);
>> +mutex_unlock(_list_mutex);
>> +
>>  return new_bd;
>>  }
>>  EXPORT_SYMBOL(backlight_device_register);
>>  
>> +bool backlight_device_registered(enum backlight_type type)
>> +{
>> +bool found = false;
>> +struct backlight_device *bd;
>> +
>> +mutex_lock(_list_mutex);
>> +list_for_each_entry(bd, _list_head, entry) {
>> +if (bd->props.type == type) {
>> +found = true;
>> +break;
>> +}
>> +}
> 
> Isn't it useful to be able to register more than one backlight device of the
> same type sometimes?

I think so for some kind of computers. OTOH, the above function should
be enough for the problem we are solving here, if someday we need to
differentiate, we can enhance the code then.

> 
>> +mutex_unlock(_list_mutex);
>> +
>> +return found;
>> +}
>> +EXPORT_SYMBOL(backlight_device_registered);
>> +
>>  /**
>>   * backlight_device_unregister - unregisters a backlight device object.
>>   * @bd: the backlight device object to be unregistered and freed.
>> @@ -364,6 +389,10 @@ void backlight_device_unregister(struct 
>> backlight_device *bd)
>>  if (!bd)
>>  return;
>>  
>> +mutex_lock(_list_mutex);
>> +list_del(>entry);
>> +mutex_unlock(_list_mutex);
>> +
>>  #ifdef CONFIG_PMAC_BACKLIGHT
>>  mutex_lock(_backlight_mutex);
>>  if (pmac_backlight == bd)
>> @@ -499,6 +528,8 @@ static int __init backlight_class_init(void)
>>  
>>  backlight_class->dev_groups = bl_device_groups;
>>  backlight_class->pm = _class_dev_pm_ops;
>> +INIT_LIST_HEAD(_list_head);
>> +mutex_init(_list_mutex);
>>  return 0;
>>  }
>>  
>> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
>> index 53b7794..5f9cd96 100644
>> --- a/include/linux/backlight.h
>> +++ b/include/linux/backlight.h
>> @@ -100,6 +100,9 @@ struct backlight_device {
>>  /* The framebuffer notifier block */
>>  struct notifier_block fb_notif;
>>  
>> +/* list entry of all registered backlight devices */
>> +struct list_head entry;
>> +
>>  struct device dev;
>>  };
>>  
>> @@ -123,6 +126,7 @@ extern void devm_backlight_device_unregister(struct 
>> device *dev,
>>  struct backlight_device *bd);
>>  extern void backlight_force_update(struct backlight_device *bd,
>> enum backlight_update_reason reason);
>> +extern bool backlight_device_registered(enum backlight_type type);
>>  
>>  #define to_backlight_device(obj) container_of(obj, struct backlight_device, 
>> dev)
> 
> Thanks!

Thanks for the review,
-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: [PATCH v3] btrfs: Fix memory leakage in the tree-log.c

[Josef Bacik]

On Wed, Oct 09, 2013 at 08:40:30PM -0300, Geyslan G. Bem wrote:
> In some cases, add_inode_ref() is returning without freeing
> the 'name' pointer.
> 
> Added bail out to explicitly call kfree when necessary.
> 
> Signed-off-by: Geyslan G. Bem 
> ---
>  fs/btrfs/tree-log.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
> index 79f057c..ad7cc5f 100644
> --- a/fs/btrfs/tree-log.c
> +++ b/fs/btrfs/tree-log.c
> @@ -1170,13 +1170,16 @@ static noinline int add_inode_ref(struct 
> btrfs_trans_handle *trans,
>   if (!dir)
>   dir = read_one_inode(root, parent_objectid);
>   if (!dir)
> - return -ENOENT;
> + {
> + ret = -ENOENT;
> + goto bail;
> + }

Code formatting is

if () {
}

not

if ()
{
}


>   } else {
>   ret = ref_get_fields(eb, ref_ptr, , ,
>_index);
>   }
>   if (ret)
> - return ret;
> + goto bail;
>  
>   /* if we already have a perfect match, we're done */
>   if (!inode_in_dir(root, path, btrfs_ino(dir), btrfs_ino(inode),
> @@ -1227,6 +1230,9 @@ out:
>   btrfs_release_path(path);
>   iput(dir);
>   iput(inode);
> +bail:
> + if (name)
> + kfree(name);

kfree already does the if (name) part of this so this is redundant.  Also if you
are going to do this you need to set name = NULL; after the kfree above it
otherwise we have a double free.  Thanks,

Josef
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [REPOST/PATCH] mfd: tps65910: remove warning during dt node parsing

[Olof Johansson]

Hi,

On Wed, Sep 26, 2012 at 5:48 AM, Laxman Dewangan  wrote:
> Driver throw the warning message if dt node does not
> have the info for VMBCH-Threshold and VMBCH2-Threshold.
> These properties are optional property and hence it
> is not mandatory to have these on DT node and in this case
> it should not throw the warning message.
> It creates noise from driver as follows:
> [0.384605] tps65910 4-002d: VMBCH-Threshold not specified
> [0.384616] tps65910 4-002d: VMBCH2-Threshold not specified
>
> Removing the warning message from driver.
>
> Signed-off-by: Laxman Dewangan 
> ---
> It seems orginal patch has been lost. Reposting it.

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