RE: [PATCH net v2 2/3] r8152: modify the tx flow

2013-10-30 Thread hayeswang 
From: David Miller [mailto:da...@davemloft.net] 
Sent: Thursday, October 31, 2013 5:05 AM
> 
> From: Hayes Wang 
> Date: Wed, 30 Oct 2013 15:13:39 +0800
[...]
> Basically, your driver will now queue up to 1,000 packets onto
> this tx_queue list, because that is what tx_queue_len will be
> for alloc_etherdev() allocated network devices.
> 
> In my previous reply to you about this patch, I asked you to
> quantify and study the effects of using a limit of 60.  I said
> that 60 might be too large.
> 
> You've responded by removing the limit completely, which is exactly
> the opposite of what I've asked you to do.  Why did you do this?

Excuse me. My question is that the original code doesn't stop the tx queue
either, so I don't understand why it is necessary for this patch.

I don't say I wouldn't find the suitable value for the tx queue length.
I feel I need some time to think how to find the reasonable value. And
I don't hope it influences the submission of the other patches, so I
remove it first. Or, may I submit the other two patches first?

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

Re: [patch] mm, memcg: add memory.oom_control notification for system oom

2013-10-30 Thread Johannes Weiner 
On Wed, Oct 30, 2013 at 06:39:16PM -0700, David Rientjes wrote:
> A subset of applications that wait on memory.oom_control don't disable
> the oom killer for that memcg and simply log or cleanup after the kernel
> oom killer kills a process to free memory.
> 
> We need the ability to do this for system oom conditions as well, i.e.
> when the system is depleted of all memory and must kill a process.  For
> convenience, this can use memcg since oom notifiers are already present.
> 
> When a userspace process waits on the root memcg's memory.oom_control, it
> will wake up anytime there is a system oom condition so that it can log
> the event, including what process was killed and the stack, or cleanup
> after the kernel oom killer has killed something.
> 
> This is a special case of oom notifiers since it doesn't subsequently
> notify all memcgs under the root memcg (all memcgs on the system).  We
> don't want to trigger those oom handlers which are set aside specifically
> for true memcg oom notifications that disable their own oom killers to
> enforce their own oom policy, for example.

There is nothing they can do anyway since the handler is hardcoded for
the root cgroup, so this seems fine.

> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -155,6 +155,7 @@ static inline bool task_in_memcg_oom(struct task_struct 
> *p)
>  }
>  
>  bool mem_cgroup_oom_synchronize(bool wait);
> +void mem_cgroup_root_oom_notify(void);
>  
>  #ifdef CONFIG_MEMCG_SWAP
>  extern int do_swap_account;
> @@ -397,6 +398,10 @@ static inline bool mem_cgroup_oom_synchronize(bool wait)
>   return false;
>  }
>  
> +static inline void mem_cgroup_root_oom_notify(void)
> +{
> +}
> +
>  static inline void mem_cgroup_inc_page_stat(struct page *page,
>   enum mem_cgroup_stat_index idx)
>  {
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -5641,6 +5641,15 @@ static void mem_cgroup_oom_notify(struct mem_cgroup 
> *memcg)
>   mem_cgroup_oom_notify_cb(iter);
>  }
>  
> +/*
> + * Notify any process waiting on the root memcg's memory.oom_control, but do 
> not
> + * notify any child memcgs to avoid triggering their per-memcg oom handlers.
> + */
> +void mem_cgroup_root_oom_notify(void)
> +{
> + mem_cgroup_oom_notify_cb(root_mem_cgroup);
> +}
> +
>  static int mem_cgroup_usage_register_event(struct cgroup_subsys_state *css,
>   struct cftype *cft, struct eventfd_ctx *eventfd, const char *args)
>  {
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -632,6 +632,10 @@ void out_of_memory(struct zonelist *zonelist, gfp_t 
> gfp_mask,
>   return;
>   }
>  
> + /* Avoid waking up processes for oom kills triggered by sysrq */
> + if (!force_kill)
> + mem_cgroup_root_oom_notify();

We have an API for global OOM notifications, please just use
register_oom_notifier() instead.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] perf/x86/intel: Add Ivy Bridge-EP uncore IRP box support

2013-10-30 Thread Joe Perches 
On Thu, 2013-10-31 at 13:36 +0800, Yan, Zheng wrote:
> Unlike other uncore boxes, IRP boxes live in PCI buses with no UBOX
> device. For PCI bus without UBOX device, we find the next bus that
> has UBOX device and use its 'bus to socket' mapping.
[]
> diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c 
> b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
[]
> @@ -997,6 +997,20 @@ static int snbep_pci2phy_map_init(int devid)
[]
> +/* registers in IRP boxes are not properly aligned */
> +static unsigned ivt_uncore_irp_ctls[] = {0xd8, 0xdc, 0xe0, 0xe4};
> +static unsigned ivt_uncore_irp_ctrs[] = {0xa0, 0xb0, 0xb8, 0xc0};

Using this sort of naming is like asking for a typo
or a copy/paste defect.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] arch: *: remove '__init' for setup_profiling_timer()

2013-10-30 Thread Vineet Gupta 
On 10/23/2013 07:36 AM, Chen Gang wrote:
> Most of architectures not use '__init' for setup_profiling_timer(), so
> need remove it, or can generate warning (e.g. arc with allmodconfig):
>
> MODPOST vmlinux.o
>   WARNING: vmlinux.o(.text+0x3c682): Section mismatch in reference from the 
> function write_profile() to the function .init.text:setup_profiling_timer()
>   The function write_profile() references
>   the function __init setup_profiling_timer().
>   This is often because write_profile lacks a __init
>   annotation or the annotation of setup_profiling_timer is wrong.
>
>
> Signed-off-by: Chen Gang 
> ---
>  arch/arc/kernel/smp.c  |2 +-
>  arch/blackfin/mach-bf561/smp.c |2 +-
>  arch/parisc/kernel/smp.c   |2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arc/kernel/smp.c b/arch/arc/kernel/smp.c
> index bca3052..3bdac11 100644
> --- a/arch/arc/kernel/smp.c
> +++ b/arch/arc/kernel/smp.c
> @@ -187,7 +187,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
>  /*
>   * not supported here
>   */
> -int __init setup_profiling_timer(unsigned int multiplier)
> +int setup_profiling_timer(unsigned int multiplier)
>  {
>   return -EINVAL;
>  }
> diff --git a/arch/blackfin/mach-bf561/smp.c b/arch/blackfin/mach-bf561/smp.c
> index 11789be..3bef058 100644
> --- a/arch/blackfin/mach-bf561/smp.c
> +++ b/arch/blackfin/mach-bf561/smp.c
> @@ -43,7 +43,7 @@ void __init platform_prepare_cpus(unsigned int max_cpus)
>   init_cpu_present();
>  }
>  
> -int __init setup_profiling_timer(unsigned int multiplier) /* not supported */
> +int setup_profiling_timer(unsigned int multiplier) /* not supported */
>  {
>   return -EINVAL;
>  }
> diff --git a/arch/parisc/kernel/smp.c b/arch/parisc/kernel/smp.c
> index 8a252f2..2e8cd36 100644
> --- a/arch/parisc/kernel/smp.c
> +++ b/arch/parisc/kernel/smp.c
> @@ -433,7 +433,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *tidle)
>  }
>  
>  #ifdef CONFIG_PROC_FS
> -int __init
> +int
>  setup_profiling_timer(unsigned int multiplier)
>  {
>   return -EINVAL;

In theory this change is OK. However this is legacy code at best and it would be
better to define a weak definition in kernel/profile.c and remove this cruft 
from
relevant arches. I'll send out a patch.

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

[PATCH 1/2] perf/x86/intel/uncore: Add filter support for IvyBridge-EP QPI boxes

2013-10-30 Thread Yan, Zheng 
From: "Yan, Zheng" 

The encoding for filter registers of IvyBridge-EP uncore QPI boxes is
completely the same as SandyBridge-EP.

Signed-off-by: Yan, Zheng 
---
 arch/x86/kernel/cpu/perf_event_intel_uncore.c | 61 ++-
 1 file changed, 51 insertions(+), 10 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c 
b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
index 4118f9f..6da3999 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
@@ -1099,6 +1099,24 @@ static struct attribute *ivt_uncore_qpi_formats_attr[] = 
{
_attr_umask.attr,
_attr_edge.attr,
_attr_thresh8.attr,
+   _attr_match_rds.attr,
+   _attr_match_rnid30.attr,
+   _attr_match_rnid4.attr,
+   _attr_match_dnid.attr,
+   _attr_match_mc.attr,
+   _attr_match_opc.attr,
+   _attr_match_vnw.attr,
+   _attr_match0.attr,
+   _attr_match1.attr,
+   _attr_mask_rds.attr,
+   _attr_mask_rnid30.attr,
+   _attr_mask_rnid4.attr,
+   _attr_mask_dnid.attr,
+   _attr_mask_mc.attr,
+   _attr_mask_opc.attr,
+   _attr_mask_vnw.attr,
+   _attr_mask0.attr,
+   _attr_mask1.attr,
NULL,
 };
 
@@ -1312,17 +1330,30 @@ static struct intel_uncore_type ivt_uncore_imc = {
IVT_UNCORE_PCI_COMMON_INIT(),
 };
 
+static struct intel_uncore_ops ivt_uncore_qpi_ops = {
+   .init_box   = ivt_uncore_pci_init_box,
+   .disable_box= snbep_uncore_pci_disable_box,
+   .enable_box = snbep_uncore_pci_enable_box,
+   .disable_event  = snbep_uncore_pci_disable_event,
+   .enable_event   = snbep_qpi_enable_event,
+   .read_counter   = snbep_uncore_pci_read_counter,
+   .hw_config  = snbep_qpi_hw_config,
+   .get_constraint = uncore_get_constraint,
+   .put_constraint = uncore_put_constraint,
+};
+
 static struct intel_uncore_type ivt_uncore_qpi = {
-   .name   = "qpi",
-   .num_counters   = 4,
-   .num_boxes  = 3,
-   .perf_ctr_bits  = 48,
-   .perf_ctr   = SNBEP_PCI_PMON_CTR0,
-   .event_ctl  = SNBEP_PCI_PMON_CTL0,
-   .event_mask = IVT_QPI_PCI_PMON_RAW_EVENT_MASK,
-   .box_ctl= SNBEP_PCI_PMON_BOX_CTL,
-   .ops= _uncore_pci_ops,
-   .format_group   = _uncore_qpi_format_group,
+   .name   = "qpi",
+   .num_counters   = 4,
+   .num_boxes  = 3,
+   .perf_ctr_bits  = 48,
+   .perf_ctr   = SNBEP_PCI_PMON_CTR0,
+   .event_ctl  = SNBEP_PCI_PMON_CTL0,
+   .event_mask = IVT_QPI_PCI_PMON_RAW_EVENT_MASK,
+   .box_ctl= SNBEP_PCI_PMON_BOX_CTL,
+   .num_shared_regs= 1,
+   .ops= _uncore_qpi_ops,
+   .format_group   = _uncore_qpi_format_group,
 };
 
 static struct intel_uncore_type ivt_uncore_r2pcie = {
@@ -1429,6 +1460,16 @@ static DEFINE_PCI_DEVICE_TABLE(ivt_uncore_pci_ids) = {
PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xe3e),
.driver_data = UNCORE_PCI_DEV_DATA(IVT_PCI_UNCORE_R3QPI, 2),
},
+   { /* QPI Port 0 filter  */
+   PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xe86),
+   .driver_data = UNCORE_PCI_DEV_DATA(UNCORE_EXTRA_PCI_DEV,
+  SNBEP_PCI_QPI_PORT0_FILTER),
+   },
+   { /* QPI Port 0 filter  */
+   PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xe96),
+   .driver_data = UNCORE_PCI_DEV_DATA(UNCORE_EXTRA_PCI_DEV,
+  SNBEP_PCI_QPI_PORT1_FILTER),
+   },
{ /* end: all zeroes */ }
 };
 
-- 
1.8.1.4

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

[PATCH 2/2] perf/x86/intel: Add Ivy Bridge-EP uncore IRP box support

2013-10-30 Thread Yan, Zheng 
From: "Yan, Zheng" 

Unlike other uncore boxes, IRP boxes live in PCI buses with no UBOX
device. For PCI bus without UBOX device, we find the next bus that
has UBOX device and use its 'bus to socket' mapping.

Besides the counter/control registers in IRP boxes are not properly
aligned

Signed-off-by: Yan, Zheng 
---
 arch/x86/kernel/cpu/perf_event_intel_uncore.c | 73 +++
 1 file changed, 73 insertions(+)

diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c 
b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
index 6da3999..29c2487 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
@@ -997,6 +997,20 @@ static int snbep_pci2phy_map_init(int devid)
}
}
 
+   if (!err) {
+   /*
+* For PCI bus with no UBOX device, find the next bus
+* that has UBOX device and use its mapping.
+*/
+   i = -1;
+   for (bus = 255; bus >= 0; bus--) {
+   if (pcibus_to_physid[bus] >= 0)
+   i = pcibus_to_physid[bus];
+   else
+   pcibus_to_physid[bus] = i;
+   }
+   }
+
if (ubox_dev)
pci_dev_put(ubox_dev);
 
@@ -1330,6 +1344,59 @@ static struct intel_uncore_type ivt_uncore_imc = {
IVT_UNCORE_PCI_COMMON_INIT(),
 };
 
+/* registers in IRP boxes are not properly aligned */
+static unsigned ivt_uncore_irp_ctls[] = {0xd8, 0xdc, 0xe0, 0xe4};
+static unsigned ivt_uncore_irp_ctrs[] = {0xa0, 0xb0, 0xb8, 0xc0};
+
+static void ivt_uncore_irp_enable_event(struct intel_uncore_box *box, struct 
perf_event *event)
+{
+   struct pci_dev *pdev = box->pci_dev;
+   struct hw_perf_event *hwc = >hw;
+
+   pci_write_config_dword(pdev, ivt_uncore_irp_ctls[hwc->idx],
+  hwc->config | SNBEP_PMON_CTL_EN);
+}
+
+static void ivt_uncore_irp_disable_event(struct intel_uncore_box *box, struct 
perf_event *event)
+{
+   struct pci_dev *pdev = box->pci_dev;
+   struct hw_perf_event *hwc = >hw;
+
+   pci_write_config_dword(pdev, ivt_uncore_irp_ctls[hwc->idx], 
hwc->config);
+}
+
+static u64 ivt_uncore_irp_read_counter(struct intel_uncore_box *box, struct 
perf_event *event)
+{
+   struct pci_dev *pdev = box->pci_dev;
+   struct hw_perf_event *hwc = >hw;
+   u64 count = 0;
+
+   pci_read_config_dword(pdev, ivt_uncore_irp_ctrs[hwc->idx], (u32 
*));
+   pci_read_config_dword(pdev, ivt_uncore_irp_ctrs[hwc->idx] + 4, (u32 
*) + 1);
+
+   return count;
+}
+
+static struct intel_uncore_ops ivt_uncore_irp_ops = {
+   .init_box   = ivt_uncore_pci_init_box,
+   .disable_box= snbep_uncore_pci_disable_box,
+   .enable_box = snbep_uncore_pci_enable_box,
+   .disable_event  = ivt_uncore_irp_disable_event,
+   .enable_event   = ivt_uncore_irp_enable_event,
+   .read_counter   = ivt_uncore_irp_read_counter,
+};
+
+static struct intel_uncore_type ivt_uncore_irp = {
+   .name   = "irp",
+   .num_counters   = 4,
+   .num_boxes  = 1,
+   .perf_ctr_bits  = 48,
+   .event_mask = IVT_PMON_RAW_EVENT_MASK,
+   .box_ctl= SNBEP_PCI_PMON_BOX_CTL,
+   .ops= _uncore_irp_ops,
+   .format_group   = _uncore_format_group,
+};
+
 static struct intel_uncore_ops ivt_uncore_qpi_ops = {
.init_box   = ivt_uncore_pci_init_box,
.disable_box= snbep_uncore_pci_disable_box,
@@ -1377,6 +1444,7 @@ static struct intel_uncore_type ivt_uncore_r3qpi = {
 enum {
IVT_PCI_UNCORE_HA,
IVT_PCI_UNCORE_IMC,
+   IVT_PCI_UNCORE_IRP,
IVT_PCI_UNCORE_QPI,
IVT_PCI_UNCORE_R2PCIE,
IVT_PCI_UNCORE_R3QPI,
@@ -1385,6 +1453,7 @@ enum {
 static struct intel_uncore_type *ivt_pci_uncores[] = {
[IVT_PCI_UNCORE_HA] = _uncore_ha,
[IVT_PCI_UNCORE_IMC]= _uncore_imc,
+   [IVT_PCI_UNCORE_IRP]= _uncore_irp,
[IVT_PCI_UNCORE_QPI]= _uncore_qpi,
[IVT_PCI_UNCORE_R2PCIE] = _uncore_r2pcie,
[IVT_PCI_UNCORE_R3QPI]  = _uncore_r3qpi,
@@ -1432,6 +1501,10 @@ static DEFINE_PCI_DEVICE_TABLE(ivt_uncore_pci_ids) = {
PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xef1),
.driver_data = UNCORE_PCI_DEV_DATA(IVT_PCI_UNCORE_IMC, 7),
},
+   { /* IRP */
+   PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xe39),
+   .driver_data = UNCORE_PCI_DEV_DATA(IVT_PCI_UNCORE_IRP, 0),
+   },
{ /* QPI0 Port 0 */
PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xe32),
.driver_data = UNCORE_PCI_DEV_DATA(IVT_PCI_UNCORE_QPI, 0),
-- 
1.8.1.4

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

Re: [PATCH v5] PWM: atmel-pwm: add PWM controller driver

2013-10-30 Thread Bo Shen 

Hi Nicolas,

On 10/28/2013 10:49 PM, Nicolas Ferre wrote:

On 22/10/2013 12:13, Bo Shen :

Hi All,

On 10/8/2013 21:17, Thierry Reding wrote:

On Mon, Sep 30, 2013 at 05:10:40PM +0800, Bo Shen wrote:

Add Atmel PWM controller driver based on PWM framework.

This is the basic function implementation of Atmel PWM controller.
It can work with PWM based led and backlight.

Signed-off-by: Bo Shen 

---
Changes in v5:
- call clk_disable directly, if so, it won't cause more than one
channel
  enabled, the clock can not be disabled.

Changes in v4:
- check the return value of clk_prepare()
- change channel register size as constant

Changes in v3:
- change compatible string from "atmel,sama5-pwm" to
"atmel,sama5d3-pwm"
- Add PWM led example in binding documentation
- Using micro replace hard code

Changes in v2:
- Address the comments from Thierry Reding

   .../devicetree/bindings/pwm/atmel-pwm.txt  |   41 +++
   drivers/pwm/Kconfig|9 +
   drivers/pwm/Makefile   |1 +
   drivers/pwm/pwm-atmel.c|  344

   4 files changed, 395 insertions(+)
   create mode 100644
Documentation/devicetree/bindings/pwm/atmel-pwm.txt
   create mode 100644 drivers/pwm/pwm-atmel.c


I haven't seen an Acked-by from the device tree bindings maintainers on
this. I've Cc'ed them, so hopefully one of them has time to review.


Any comments?


As a recommendation from the recent Kernel Summit stated, you will have
to separate the binding itself from the driver and associated code.
Simply send the binding documentation to the DT maintainers but still
keep the two patches linked together in a series (but without putting DT
maintainers nor the DT mailing-list in CC of the non-documentation
patches).

This way you may have more chances to get feedback.


Thanks, I will split the binding document as a separate patch.


Thanks, bye,


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

Question: Takes about 2s in sched_clock_init() when kernel boots

2013-10-30 Thread Younger Liu 
Hi,
  When I analyse boot time on ArmV7, I found that it takes
about 2s in sched_clock_init(), the log is as follow:
[0.00] before:sched_clock_init.
[0.00] start:sched_clock_init.
[2.100505] end  :sched_clock_init.
[2.103983] before:calibrate_delay.

  In my config, CONFIG_HAVE_UNSTABLE_SCHED_CLOCK does not config.

  Are there any suggestions?

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

RE: [PATCHv4 5/9] Thermal: Add trip point sysfs nodes for sensor

2013-10-30 Thread R, Durgadoss 
> -Original Message-
> From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
> ow...@vger.kernel.org] On Behalf Of Srinivas Pandruvada
> Sent: Thursday, October 31, 2013 7:03 AM
> To: R, Durgadoss; Zhang, Rui
> Cc: eduardo.valen...@ti.com; linux...@vger.kernel.org; linux-
> ker...@vger.kernel.org; hongbo.zh...@freescale.com; w...@nvidia.com
> Subject: Re: [PATCHv4 5/9] Thermal: Add trip point sysfs nodes for sensor
> 
> You might want to use new DEVICE_ATTR_RO and DEVICE_ATTR_RW in this
> series. GKH wanted this changes in my powercap patchset.

I am working on my next version. Will take care of this in appropriate places.
Thank you for pointing this out.

Thanks,
Durga

> 
> Thanks,
> Srinivas
> 
> On 10/15/2013 06:12 AM, R, Durgadoss wrote:
> >> -Original Message-
> >> From: Zhang, Rui
> >> Sent: Tuesday, October 15, 2013 4:33 PM
> >> To: R, Durgadoss
> >> Cc: eduardo.valen...@ti.com; linux...@vger.kernel.org; linux-
> >> ker...@vger.kernel.org; hongbo.zh...@freescale.com; w...@nvidia.com
> >> Subject: Re: [PATCHv4 5/9] Thermal: Add trip point sysfs nodes for sensor
> >>
> >> On Wed, 2013-10-02 at 00:08 +0530, Durgadoss R wrote:
> >>> This patch adds a trip point related sysfs nodes
> >>> for each sensor under a zone in /sys/class/thermal/zoneX/.
> >>> The nodes will be named, sensorX_trip_activeY,
> >>> sensorX_trip_passiveY, sensorX_trip_hot, sensorX_trip_critical
> >>> for active, passive, hot and critical trip points
> >>> respectively for sensorX.
> >>>
> >>> Signed-off-by: Durgadoss R 
> >>> ---
> >>>   drivers/thermal/thermal_core.c |  344
> >> +++-
> >>>   include/linux/thermal.h|   40 -
> >>>   2 files changed, 379 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/drivers/thermal/thermal_core.c
> b/drivers/thermal/thermal_core.c
> >>> index 3c4ef62..d6e29f6 100644
> >>> --- a/drivers/thermal/thermal_core.c
> >>> +++ b/drivers/thermal/thermal_core.c
> >>> @@ -494,6 +494,60 @@ static void thermal_zone_device_check(struct
> >> work_struct *work)
> >>>   thermal_zone_device_update(tz);
> >>>   }
> >>>
> >>> +static int get_sensor_indx_by_kobj(struct thermal_zone *tz, const char
> >> *name)
> >>> +{
> >>> + int i, indx = -EINVAL;
> >>> +
> >>> + /* Protect against tz->sensors[i] being unregistered */
> >>> + mutex_lock(_list_lock);
> >>> +
> >>> + for (i = 0; i < tz->sensor_indx; i++) {
> >>> + if (!strnicmp(name, kobject_name(>sensors[i]-
> >>> device.kobj),
> >>> + THERMAL_NAME_LENGTH)) {
> >>> + indx = i;
> >>> + break;
> >>> + }
> >>> + }
> >>> +
> >>> + mutex_unlock(_list_lock);
> >>> + return indx;
> >>> +}
> >>> +
> >>> +static void __remove_trip_attr(struct thermal_zone *tz, int indx)
> >>> +{
> >>> + int i;
> >>> + struct thermal_trip_attr *attr = tz->trip_attr[indx];
> >>> + struct thermal_trip_point *trip = tz->sensor_trip[indx];
> >>> +
> >>> + if (!attr || !trip)
> >>> + return;
> >>> +
> >>> + if (trip->crit != THERMAL_TRIPS_NONE)
> >>> + device_remove_file(>device, >crit_attr.attr);
> >>> +
> >>> + if (trip->hot != THERMAL_TRIPS_NONE)
> >>> + device_remove_file(>device, >hot_attr.attr);
> >>> +
> >>> + if (trip->num_passive_trips > 0) {
> >>> + for (i = 0; i < trip->num_passive_trips; i++) {
> >>> + device_remove_file(>device,
> >>> + >passive_attrs[i].attr);
> >>> + }
> >>> + kfree(attr->passive_attrs);
> >>> + }
> >>> +
> >>> + if (trip->num_active_trips > 0) {
> >>> + for (i = 0; i < trip->num_active_trips; i++) {
> >>> + device_remove_file(>device,
> >>> + >active_attrs[i].attr);
> >>> + }
> >>> + kfree(attr->active_attrs);
> >>> + }
> >>> +
> >>> + kfree(tz->trip_attr[indx]);
> >>> + tz->trip_attr[indx] = NULL;
> >>> +}
> >>> +
> >>>   static void remove_sensor_from_zone(struct thermal_zone *tz,
> >>>   struct thermal_sensor *ts)
> >>>   {
> >>> @@ -503,13 +557,19 @@ static void remove_sensor_from_zone(struct
> >> thermal_zone *tz,
> >>>   if (indx < 0)
> >>>   return;
> >>>
> >>> - sysfs_remove_link(>device.kobj, kobject_name(>device.kobj));
> >>> -
> >>>   mutex_lock(>lock);
> >>>
> >>> + /* Remove trip point attributes associated with this sensor */
> >>> + __remove_trip_attr(tz, indx);
> >>> +
> >>> + sysfs_remove_link(>device.kobj, kobject_name(>device.kobj));
> >>> +
> >>>   /* Shift the entries in the tz->sensors array */
> >>> - for (j = indx; j < MAX_SENSORS_PER_ZONE - 1; j++)
> >>> + for (j = indx; j < MAX_SENSORS_PER_ZONE - 1; j++) {
> >>>   tz->sensors[j] = tz->sensors[j + 1];
> >>> + tz->sensor_trip[j] = tz->sensor_trip[j + 1];
> >>> + tz->trip_attr[j] = tz->trip_attr[j + 1];
> >>> + }
> >>>
> >>>   tz->sensor_indx--;
>

Re: Re: [PATCH 3/3] md/raid5: For stripe with R5_ReadNoMerge, we replace REQ_FLUSH with REQ_NOMERGE.

2013-10-30 Thread kedacomkernel 
>On Wed, 30 Oct 2013 10:41:46 +0800 majianpeng  wrote:
>
>> For R5_ReadNoMerge,it mean this bio can't merge with other bios or
>> request.It used REQ_FLUSH to achieve this. But REQ_NOMERGE can do the
>> same work.
>> 
>> Signed-off-by: Jianpeng Ma 
>> ---
>>  drivers/md/raid5.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
>> index f8b9068..8e0aeaa 100644
>> --- a/drivers/md/raid5.c
>> +++ b/drivers/md/raid5.c
>> @@ -772,7 +772,7 @@ static void ops_run_io(struct stripe_head *sh, struct 
>> stripe_head_state *s)
>>  bi->bi_sector = (sh->sector
>>   + rdev->data_offset);
>>  if (test_bit(R5_ReadNoMerge, >dev[i].flags))
>> -bi->bi_rw |= REQ_FLUSH;
>> +bi->bi_rw |= REQ_NOMERGE;
>>  
>>  bi->bi_vcnt = 1;
>>  bi->bi_io_vec[0].bv_len = STRIPE_SIZE;
>
>Thanks.
>
>I've queued this up pending Jens' acceptance of the other patches.
>
>By the way, your patch file has a carriage return as well as a newline at the
>end of each line.
>"patch" can still handle them but "git am" doesn't like it.
>
>If you are able to send the patches as plain text with just a NEWLINE at the
>end of each line, rather than base64 encodes with carriage returns, it would
>help a little.
>
Sorroy for that, i'll pay attention to this.
Thanks!
Jianpeng Ma

>Thanks,
>NeilBrown
>

Re: [PATCH v2 1/2] clocksource: sh_tmu: Release clock when sh_tmu_register() fails

2013-10-30 Thread Simon Horman 
On Tue, Oct 29, 2013 at 03:31:36PM +0100, Laurent Pinchart wrote:
> Fix the probe error path to release the clock resource when the
> sh_tmu_register() call fails.
> 
> Cc: Daniel Lezcano 
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Laurent Pinchart 

Thanks, I have queued this up.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 2/2] clocksource: sh_tmu: Add clk_prepare/unprepare support

2013-10-30 Thread Simon Horman 
On Tue, Oct 29, 2013 at 03:31:37PM +0100, Laurent Pinchart wrote:
> Prepare the clock at probe time, as there is no other appropriate place
> in the driver where we're allowed to sleep.
> 
> Cc: Daniel Lezcano 
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Laurent Pinchart 

Thanks, I have queued this up.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 2/2] clocksource: sh_mtu2: Add clk_prepare/unprepare support

2013-10-30 Thread Simon Horman 
On Tue, Oct 29, 2013 at 03:30:45PM +0100, Laurent Pinchart wrote:
> Prepare the clock at probe time, as there is no other appropriate place
> in the driver where we're allowed to sleep.
> 
> Cc: Daniel Lezcano 
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Laurent Pinchart 

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

Re: Any news on Runtime Interpreted Power Sequences

2013-10-30 Thread Alex Courbot 

On 10/31/2013 01:59 PM, NeilBrown wrote:

* PGP Signed by an unknown key

On Tue, 29 Oct 2013 09:18:16 -0700 Mark Brown  wrote:


On Tue, Oct 29, 2013 at 11:10:37AM +1100, NeilBrown wrote:


Yes, the device is soldered down and has a reset line that needs to be pulsed
low at about the same time that the MMC port enables the regulator.



How do you propose that I describe this?  Which driver should know about the
reset GPIO, how to I tell it about the GPIO, and which function should do the
pulsing?


I'd expect the driver for the device to know about this, obviously
depending on what this actually does it might want to use this at
runtime (for example, putting the device into reset to minimise power
while it's idle).  We really need a generic way for devices such as this
on enumerable buses to run before the current probe() in order to allow
them to manage their power up sequences in embedded systems, this is
*far* from a unique situation.


I agree.
To me, this sounds a lot like saying "We need a way for enumerable buses to
be given a power-on-sequence to power on the attached device".  That is what
I hopped RIPS would provide.


There are a few ad-hoc solutions that provide such a mechanism using 
platform data. Take for instance 
include/linux/platform_data/brcmfmac-sdio.h. It allows you to register a 
platform device which sole purpose is to control the power sequence of a 
SDIO network device. When the platform device is registered, it powers 
the network device which can then be probed by the bus. The network 
driver also calls the platform power on/off functions when appropriate.


This works quite well in the case of board files where you can write 
power sequencing code freely, but the question is how to translate it to 
device tree. You need to translate several, board-specific (and not 
device-specific) functions. Here I have to admit this seems like a good 
fit for in-DT power sequences.



Maybe various devices could allow other devices to register for call-backs
when the first device activates or deactivates a port  (whether an MMC port or
USB or Serial or whatever).
Then a driver that needs to control the power-on sequence would register as a
platform-device which registers a call-back with the appropriate parent and
performs the required power-on/off.

Does that sound like the right sort of thing?


I think it does, but you are still left with the problem of how and 
where to define that board-specific power sequence. If things were 
always as simple as turning a regulator on, this would be easy, but 
apparently we also face more complex cases.


Alex.

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

Re: [PATCH v2 1/2] clocksource: sh_mtu2: Release clock when sh_mtu2_register() fails

2013-10-30 Thread Simon Horman 
On Tue, Oct 29, 2013 at 03:30:44PM +0100, Laurent Pinchart wrote:
> Fix the probe error path to release the clock resource when the
> sh_mtu2_register() call fails.
> 
> Cc: Daniel Lezcano 
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Laurent Pinchart 

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

Re: [PATCH 2/4] ARM: msm: Remove 7x00 support

2013-10-30 Thread Olof Johansson 
On Wed, Oct 30, 2013 at 7:45 PM, Daniel Walker  wrote:
> On Wed, Oct 30, 2013 at 05:36:58PM -0700, Olof Johansson wrote:
>> On Wed, Oct 30, 2013 at 4:25 PM, Daniel Walker  wrote:
>>
>> > So the current users of those platforms are, what SOL ?
>>
>> What users? Show me one.
>
> What am I chop liver ?

Ah, right. So, what platforms do you currently rely on mainline
support for? Please be precise so we can figure out what needs to be
kept and not.


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

Re: [PATCH] mm: __rmqueue_fallback() should respect pageblock type

2013-10-30 Thread KOSAKI Motohiro 
(10/31/13 12:24 AM), kosaki.motoh...@gmail.com wrote:
> From: KOSAKI Motohiro 
> 
> When __rmqueue_fallback() don't find out a free block with the same size
> of required, it splits a larger page and puts back rest peiece of the page
> to free list.
> 
> But it has one serious mistake. When putting back, __rmqueue_fallback()
> always use start_migratetype if type is not CMA. However, __rmqueue_fallback()
> is only called when all of start_migratetype queue are empty. That said,
> __rmqueue_fallback always put back memory to wrong queue except
> try_to_steal_freepages() changed pageblock type (i.e. requested size is
> smaller than half of page block). Finally, antifragmentation framework
> increase fragmenation instead of decrease.
> 
> Mel's original anti fragmentation do the right thing. But commit 47118af076
> (mm: mmzone: MIGRATE_CMA migration type added) broke it.
> 
> This patch restores sane and old behavior.
> 
> Cc: Mel Gorman 
> Signed-off-by: KOSAKI Motohiro 
> ---
>   mm/page_alloc.c |2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index dd886fa..ea7bb9a 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1101,7 +1101,7 @@ __rmqueue_fallback(struct zone *zone, int order, int 
> start_migratetype)
>*/
>   expand(zone, page, order, current_order, area,
>  is_migrate_cma(migratetype)
> -  ? migratetype : start_migratetype);
> +  ? migratetype : new_type);

Oops, this can be simplified to following because try_to_steal_freepages() has 
cma check.


-   expand(zone, page, order, current_order, area,
-  is_migrate_cma(migratetype)
-? migratetype : start_migratetype);
+   expand(zone, page, order, current_order, area, 
new_type);



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

Re: [PATCH] mm: __rmqueue_fallback() should respect pageblock type

2013-10-30 Thread KOSAKI Motohiro 

(10/31/13 12:35 AM), Andrew Morton wrote:

On Thu, 31 Oct 2013 00:24:49 -0400 kosaki.motoh...@gmail.com wrote:


When __rmqueue_fallback() don't find out a free block with the same size
of required, it splits a larger page and puts back rest peiece of the page
to free list.

But it has one serious mistake. When putting back, __rmqueue_fallback()
always use start_migratetype if type is not CMA. However, __rmqueue_fallback()
is only called when all of start_migratetype queue are empty. That said,
__rmqueue_fallback always put back memory to wrong queue except
try_to_steal_freepages() changed pageblock type (i.e. requested size is
smaller than half of page block). Finally, antifragmentation framework
increase fragmenation instead of decrease.

Mel's original anti fragmentation do the right thing. But commit 47118af076
(mm: mmzone: MIGRATE_CMA migration type added) broke it.

This patch restores sane and old behavior.


What are the user-visible runtime effects of this change?


Memory fragmentation may increase compaction rate. (And then system get 
unnecessary
slow down)


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

Re: Any news on Runtime Interpreted Power Sequences

2013-10-30 Thread NeilBrown 
On Tue, 29 Oct 2013 09:18:16 -0700 Mark Brown  wrote:

> On Tue, Oct 29, 2013 at 11:10:37AM +1100, NeilBrown wrote:
> 
> > Yes, the device is soldered down and has a reset line that needs to be 
> > pulsed
> > low at about the same time that the MMC port enables the regulator.
> 
> > How do you propose that I describe this?  Which driver should know about the
> > reset GPIO, how to I tell it about the GPIO, and which function should do 
> > the
> > pulsing?
> 
> I'd expect the driver for the device to know about this, obviously
> depending on what this actually does it might want to use this at
> runtime (for example, putting the device into reset to minimise power
> while it's idle).  We really need a generic way for devices such as this
> on enumerable buses to run before the current probe() in order to allow
> them to manage their power up sequences in embedded systems, this is
> *far* from a unique situation.

I agree.
To me, this sounds a lot like saying "We need a way for enumerable buses to
be given a power-on-sequence to power on the attached device".  That is what
I hopped RIPS would provide.

Maybe various devices could allow other devices to register for call-backs
when the first device activates or deactivates a port  (whether an MMC port or
USB or Serial or whatever).
Then a driver that needs to control the power-on sequence would register as a
platform-device which registers a call-back with the appropriate parent and
performs the required power-on/off.

Does that sound like the right sort of thing?

NeilBrown


signature.asc
Description: PGP signature

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

2013-10-30 Thread KOSAKI Motohiro 

(10/16/13 6:42 AM), Mel Gorman wrote:

It has been reported on very large machines that show_mem is taking almost
5 minutes to display information. This is a serious problem if there is
an OOM storm. The bulk of the cost is in show_mem doing a very expensive
PFN walk to give us the following information

Total RAM:  Also available as totalram_pages
Highmem pages:  Also available as totalhigh_pages
Reserved pages: Can be inferred from the zone structure
Shared pages:   PFN walk required
Unshared pages: PFN walk required
Quick pages:Per-cpu walk required

Only the shared/unshared pages requires a full PFN walk but that information
is useless. It is also inaccurate as page pins of unshared pages would
be accounted for as shared.  Even if the information was accurate, I'm
struggling to think how the shared/unshared information could be useful
for debugging OOM conditions. Maybe it was useful before rmap existed when
reclaiming shared pages was costly but it is less relevant today.

The PFN walk could be optimised a bit but why bother as the information is
useless. This patch deletes the PFN walker and infers the total RAM, highmem
and reserved pages count from struct zone. It omits the shared/unshared page
usage on the grounds that it is useless.  It also corrects the reporting
of HighMem as HighMem/MovableOnly as ZONE_MOVABLE has similar problems to
HighMem with respect to lowmem/highmem exhaustion.

Signed-off-by: Mel Gorman 


That's ok. I haven't used such information on my long oom debugging history.

Acked-by: KOSAKI Motohiro 


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

Re: [PATCH RFC] kvm: optimize out smp_mb using srcu_read_unlock

2013-10-30 Thread Paul E. McKenney 
On Thu, Oct 31, 2013 at 01:26:05AM +0200, Michael S. Tsirkin wrote:
> > > Paul, could you review this patch please?
> > > Documentation/memory-barriers.txt says that unlock has a weaker
> > > uni-directional barrier, but in practice srcu_read_unlock calls
> > > smp_mb().
> > > 
> > > Is it OK to rely on this? If not, can I add
> > > smp_mb__after_srcu_read_unlock (making it an empty macro for now)
> > > so we can avoid an actual extra smp_mb()?
> > 
> > Please use smp_mb__after_srcu_read_unlock().  After all, it was not
> > that long ago that srcu_read_unlock() contained no memory barriers,
> > and perhaps some day it won't need to once again.
> > 
> > Thanx, Paul
> >
> 
> Thanks!
> Something like this will be enough?
> 
> diff --git a/include/linux/srcu.h b/include/linux/srcu.h
> index c114614..9b058ee 100644
> --- a/include/linux/srcu.h
> +++ b/include/linux/srcu.h
> @@ -237,4 +237,18 @@ static inline void srcu_read_unlock(struct srcu_struct 
> *sp, int idx)
>   __srcu_read_unlock(sp, idx);
>  }
> 
> +/**
> + * smp_mb__after_srcu_read_unlock - ensure full ordering after 
> srcu_read_unlock
> + *
> + * Converts the preceding srcu_read_unlock into a two-way memory barrier.
> + *
> + * Call this after srcu_read_unlock, to guarantee that all memory operations
> + * that occur after smp_mb__after_srcu_read_unlock will appear to happen 
> after
> + * the preceding srcu_read_unlock.
> + */
> +static inline void smp_mb__after_srcu_read_unlock(void)
> +{
> + /* __srcu_read_unlock has smp_mb() internally so nothing to do here. */
> +}
> +
>  #endif

Yep, that should do it!

Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] kernel/kallsyms.c: only show legal kernel symbol

2013-10-30 Thread Ming Lei 
On Thu, Oct 31, 2013 at 11:14 AM, Rusty Russell  wrote:
> Russell King - ARM Linux  writes:
>
> Kallsyms tends to fall between modules and scripts.  I assume it's not
> urgent, so no cc:stable on this one.

Rusty, thanks a lot.

BTW, there is already other report on the problem:

   http://lkml.indiana.edu/hypermail/linux/kernel/1310.3/02772.html


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

I GOT YOUR CONTACT... I WAIT OK!

2013-10-30 Thread Mr Keba Ba 

Dear Friend,
  Greeting to you!!!

I know that this mail will come to you as a surprise as we never met before. I 
am  Mr. Keba Ba The Chief representative of the African Development Bank for 
Central and West African Division, I Hoped that you will not expose or betray 
this trust and confident that I am about to repose on you for the mutual 
benefit of our both families and for the less privilege, I need your urgent 
assistance in transferring the sum of Two Million state dollars ($10,000.000) 
Immediately to your account. For comprehensive Detail, Go through the following 
website. 
(http://www.afdb.org/en/news-and-events/article/burkina-faso-receives-us-50-66-million-grant-for-drainage-of-ouagadougou-districts-12353/)
As I am talking to you right the contractor died last week in Mali, The 
$10m was credited in his contract CBI Bank account before the event, I am the 
head of the project that is going on right now, Please I would like you to keep 
this proposal as a top secret and delete it if you are not interested. Upon 
receipt of your reply, I will send you the application form you will fill and 
send to the bank for transfer of the fund into your bank account and also note 
that you will have 40% of the above mentioned amount if you agree to help me 
execute this business. And also 10% had been mapped out for you for the expense 
you will make in this transaction and 50% is for me.  I want us to complete the 
transaction within a week, very urgent nobody is aware if he has cash the money 
before his death, except me that knew and have all the information, I need your 
information’s so that I will send you the application form.

Now my questions are:-
1. Can you handle this project? …
2. Can I give you this trust? ……

Waiting for your urgent response so that we will proceed immediately, for 
confidentiality my contact info is on the bank website (www.afdb.org) What I 
need is confident and honest, I am very serious, I wait for your respond and 
call me as soon as possible.

Best Regards, 
Mr. Keba Ba
+226 64558872

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 0/3] x86, apic, kexec: Add disable_cpu_apic kernel parameter

2013-10-30 Thread HATAYAMA Daisuke 

(2013/10/31 9:58), jerry.hoem...@hp.com wrote:

On Wed, Oct 23, 2013 at 09:05:06AM +0900, HATAYAMA Daisuke wrote:


- Rebased on top of v3.12-rc6

- Basic design has been changed. Now users need to figure out initial
   APIC ID of BSP in the 1st kernel and configures kernel parameter for
   the 2nd kernel manually using disable_cpu_apic kernel parameter to
   be newly introduced in this patch set. This design is more flexible
   than the previous version in that we no longer have to rely on
   ACPI/MP table to get initial APIC ID of BSP.



Do you literally mean a human at each boot will have to configure
the kdump configuration files for passing disable_cpu_apic?
Or do you envision the setting of disable_cpu_apic being put into
the kdump initialization scripts?

thanks

Jerry


Nearer to the former case, but this is not what a human should do. It's
a cumbersome task. I think, on fedora/RHEL system for example, kdump
service should check at each boot automatically.

HATAYAMA, Daisuke



Daisuke,

Are you planning on making changes to the kexec tools to automate
the setting of disable_cpu_apic to the capture kernel? Or do you
know someone who is planning this?

I back ported the kernel side changes to a 4.2.32 based kernel.
I tested the patch on a prototype system which exhibits a stable
initial_apic_id for CPU 0.  While not something that would be suitable
for customers, it does allow me to test the kernel portion of the patch.

I will report the results of the testing later this week.



I'll do that after this patch is merged in kernel. But it is still under
reviewing.

--
Thanks.
HATAYAMA, Daisuke

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

Re: perf events ring buffer memory barrier on powerpc

2013-10-30 Thread Paul E. McKenney 
On Wed, Oct 30, 2013 at 03:28:54PM +0200, Victor Kaplansky wrote:
> "Paul E. McKenney"  wrote on 10/30/2013
> 11:27:25 AM:
> 
> > If you were to back up that insistence with a description of the
> orderings
> > you are relying on, why other orderings are not important, and how the
> > important orderings are enforced, I might be tempted to pay attention
> > to your opinion.
> >
> >  Thanx, Paul
> 
> NP, though, I feel too embarrassed to explain things about memory barriers
> when
> one of the authors of Documentation/memory-barriers.txt is on cc: list ;-)
> 
> Disclaimer: it is anyway impossible to prove lack of *any* problem.

If you want to play the "omit memory barriers" game, then proving a
negative is in fact the task before you.

> Having said that, lets look into an example in
> Documentation/circular-buffers.txt:

And the correctness of this code has been called into question.  :-(
An embarrassingly long time ago -- I need to get this either proven
or fixed.

> > THE PRODUCER
> > 
> >
> > The producer will look something like this:
> >
> >   spin_lock(_lock);
> >
> >   unsigned long head = buffer->head;
> >   unsigned long tail = ACCESS_ONCE(buffer->tail);
> >
> >   if (CIRC_SPACE(head, tail, buffer->size) >= 1) {
> >   /* insert one item into the buffer */
> >   struct item *item = buffer[head];
> >
> >   produce_item(item);
> >
> >   smp_wmb(); /* commit the item before incrementing the head
> */
> >
> >   buffer->head = (head + 1) & (buffer->size - 1);
> >
> >   /* wake_up() will make sure that the head is committed
> before
> >* waking anyone up */
> >   wake_up(consumer);
> >   }
> >
> >   spin_unlock(_lock);
> 
> We can see that authors of the document didn't put any memory barrier
> after "buffer->tail" read and before "produce_item(item)" and I think they
> have
> a good reason.
> 
> Lets consider an imaginary smp_mb() right before "produce_item(item);".
> Such a barrier will ensure that -
> 
> - the memory read on "buffer->tail" is completed
>   before store to memory pointed by "item" is committed.
> 
> However, the store to "buffer->tail" anyway cannot be completed before
> conditional
> branch implied by "if ()" is proven to execute body statement of the if().
> And the
> latter cannot be proven before read of "buffer->tail" is completed.
> 
> Lets see this other way. Lets imagine that somehow a store to the data
> pointed by "item"
> is completed before we read "buffer->tail". That would mean, that the store
> was completed
> speculatively. But speculative execution of conditional stores is
> prohibited by C/C++ standard,
> otherwise any conditional store at any random place of code could pollute
> shared memory.

Before C/C++11, the closest thing to such a prohibition is use of
volatile, for example, ACCESS_ONCE().  Even in C/C++11, you have to
use atomics to get anything resembing this prohibition.

If you just use normal variables, the compiler is within its rights
to transform something like the following:

if (a)
b = 1;
else
b = 42;

Into:

b = 42;
if (a)
b = 1;

Many other similar transformations are permitted.  Some are used to all
vector instructions to be used -- the compiler can do a write with an
overly wide vector instruction, then clean up the clobbered variables
later, if it wishes.  Again, if the variables are not marked volatile,
or, in C/C++11, atomic.

> On the other hand, if compiler or processor can prove that condition in
> above if() is going
> to be true (or if speculative store writes the same value as it was before
> write), the
> speculative store *is* allowed. In this case we should not be bothered by
> the fact that
> memory pointed by "item" is written before a read from "buffer->tail" is
> completed.

The compilers don't always know as much as they might about the underlying
hardware's memory model.  Of course, if this code is architecture specific,
it can avoid DEC Alpha's fun and games, which could also violate your
assumptions in the above paragraph:

http://www.openvms.compaq.com/wizard/wiz_2637.html

Anyway, proving or fixing the code in Documentation/circular-buffers.txt
has been on my list for too long, so I will take a closer look at it.

Thanx, Paul

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

Re: perf events ring buffer memory barrier on powerpc

2013-10-30 Thread Paul E. McKenney 
On Wed, Oct 30, 2013 at 04:51:16PM +0100, Peter Zijlstra wrote:
> On Wed, Oct 30, 2013 at 03:28:54PM +0200, Victor Kaplansky wrote:
> > one of the authors of Documentation/memory-barriers.txt is on cc: list ;-)
> > 
> > Disclaimer: it is anyway impossible to prove lack of *any* problem.
> > 
> > Having said that, lets look into an example in
> > Documentation/circular-buffers.txt:
> 
> > 
> > We can see that authors of the document didn't put any memory barrier
> 
> Note that both documents have the same author list ;-)
> 
> Anyway, I didn't know about the circular thing, I suppose I should use
> CIRC_SPACE() thing :-)

Interesting that we didn't seem to supply a definition...  ;-)

Thanx, Paul

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

Re: 3.12-rc7 regression - network panic from ipv6

2013-10-30 Thread David Miller 
From: mr...@linux.ee
Date: Wed, 30 Oct 2013 23:41:09 +0200 (EET)

>> Signed-off-by: Steffen Klassert 
> 
> Works fine, thanks!
> 
> Tested-by: Meelis Roos 

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

Re: [PATCH] mm: __rmqueue_fallback() should respect pageblock type

2013-10-30 Thread Andrew Morton 
On Thu, 31 Oct 2013 00:24:49 -0400 kosaki.motoh...@gmail.com wrote:

> When __rmqueue_fallback() don't find out a free block with the same size
> of required, it splits a larger page and puts back rest peiece of the page
> to free list.
> 
> But it has one serious mistake. When putting back, __rmqueue_fallback()
> always use start_migratetype if type is not CMA. However, __rmqueue_fallback()
> is only called when all of start_migratetype queue are empty. That said,
> __rmqueue_fallback always put back memory to wrong queue except
> try_to_steal_freepages() changed pageblock type (i.e. requested size is
> smaller than half of page block). Finally, antifragmentation framework
> increase fragmenation instead of decrease.
> 
> Mel's original anti fragmentation do the right thing. But commit 47118af076
> (mm: mmzone: MIGRATE_CMA migration type added) broke it.
> 
> This patch restores sane and old behavior.

What are the user-visible runtime effects of this change?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] bnx2: Use dev_kfree_skb_any() in bnx2_tx_int()

2013-10-30 Thread David Miller 
From: Cong Wang 
Date: Wed, 30 Oct 2013 15:01:12 -0700

> On Wed, Oct 30, 2013 at 2:32 PM, David Miller  wrote:
>>
>> Explain to me then why other ethernet drivers implemented identically,
>> such as tg3, can use plain dev_kfree_skb() just fine?
> 
> I don't think they are fine, I just don't see bug reports
> for them. At very least, I saw a same bug report for be2net too.
> 
> To reproduce this bug, we need to find some one calling printk()
> within IRQ handler, which seems rare? It seems there are few
> people using hpsa driver together with netconsole.

We've had this conversation before I believe, and I absolutely do not
want to have to add IRQ safety to every ->poll() implementation.

We have to provide a softint compatible environment for this callback
to run in else everything is completely broken.

All these drivers can safely assume softirq safe locking is
sufficient, you're suggesting we need to take this hardirq safety and
I'm really not willing to allow things to go that far.  A lot of
effort has been expended precisely to avoid that kind of overhead and
cost.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mm: __rmqueue_fallback() should respect pageblock type

2013-10-30 Thread kosaki . motohiro 
From: KOSAKI Motohiro 

When __rmqueue_fallback() don't find out a free block with the same size
of required, it splits a larger page and puts back rest peiece of the page
to free list.

But it has one serious mistake. When putting back, __rmqueue_fallback()
always use start_migratetype if type is not CMA. However, __rmqueue_fallback()
is only called when all of start_migratetype queue are empty. That said,
__rmqueue_fallback always put back memory to wrong queue except
try_to_steal_freepages() changed pageblock type (i.e. requested size is
smaller than half of page block). Finally, antifragmentation framework
increase fragmenation instead of decrease.

Mel's original anti fragmentation do the right thing. But commit 47118af076
(mm: mmzone: MIGRATE_CMA migration type added) broke it.

This patch restores sane and old behavior.

Cc: Mel Gorman 
Signed-off-by: KOSAKI Motohiro 
---
 mm/page_alloc.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index dd886fa..ea7bb9a 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1101,7 +1101,7 @@ __rmqueue_fallback(struct zone *zone, int order, int 
start_migratetype)
 */
expand(zone, page, order, current_order, area,
   is_migrate_cma(migratetype)
-? migratetype : start_migratetype);
+? migratetype : new_type);
 
trace_mm_page_alloc_extfrag(page, order,
current_order, start_migratetype, migratetype,
-- 
1.7.1

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

linux-next: manual merge of the net-next tree with the net tree

2013-10-30 Thread Stephen Rothwell 
Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/bridge/br_private.h between commit 06499098a02b ("bridge: pass
correct vlan id to multicast code") from the net tree and commit
348662a1429f ("net: 8021q/bluetooth/bridge/can/ceph: Remove extern from
function prototypes") from the net-next tree.

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

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

diff --cc net/bridge/br_private.h
index 2e8244efb262,d1ca6d956633..
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@@ -449,44 -434,40 +434,40 @@@ int br_ioctl_deviceless_stub(struct ne
  /* br_multicast.c */
  #ifdef CONFIG_BRIDGE_IGMP_SNOOPING
  extern unsigned int br_mdb_rehash_seq;
- extern int br_multicast_rcv(struct net_bridge *br,
-   struct net_bridge_port *port,
-   struct sk_buff *skb,
-   u16 vid);
- extern struct net_bridge_mdb_entry *br_mdb_get(struct net_bridge *br,
-  struct sk_buff *skb, u16 vid);
- extern void br_multicast_add_port(struct net_bridge_port *port);
- extern void br_multicast_del_port(struct net_bridge_port *port);
- extern void br_multicast_enable_port(struct net_bridge_port *port);
- extern void br_multicast_disable_port(struct net_bridge_port *port);
- extern void br_multicast_init(struct net_bridge *br);
- extern void br_multicast_open(struct net_bridge *br);
- extern void br_multicast_stop(struct net_bridge *br);
- extern void br_multicast_deliver(struct net_bridge_mdb_entry *mdst,
-struct sk_buff *skb);
- extern void br_multicast_forward(struct net_bridge_mdb_entry *mdst,
-struct sk_buff *skb, struct sk_buff *skb2);
- extern int br_multicast_set_router(struct net_bridge *br, unsigned long val);
- extern int br_multicast_set_port_router(struct net_bridge_port *p,
-   unsigned long val);
- extern int br_multicast_toggle(struct net_bridge *br, unsigned long val);
- extern int br_multicast_set_querier(struct net_bridge *br, unsigned long val);
- extern int br_multicast_set_hash_max(struct net_bridge *br, unsigned long 
val);
- extern struct net_bridge_mdb_entry *br_mdb_ip_get(
-   struct net_bridge_mdb_htable *mdb,
-   struct br_ip *dst);
- extern struct net_bridge_mdb_entry *br_multicast_new_group(struct net_bridge 
*br,
-   struct net_bridge_port *port, struct br_ip 
*group);
- extern void br_multicast_free_pg(struct rcu_head *head);
- extern struct net_bridge_port_group *br_multicast_new_port_group(
-   struct net_bridge_port *port,
-   struct br_ip *group,
-   struct net_bridge_port_group __rcu *next,
-   unsigned char state);
- extern void br_mdb_init(void);
- extern void br_mdb_uninit(void);
- extern void br_mdb_notify(struct net_device *dev, struct net_bridge_port 
*port,
- struct br_ip *group, int type);
+ int br_multicast_rcv(struct net_bridge *br, struct net_bridge_port *port,
 -   struct sk_buff *skb);
++   struct sk_buff *skb, u16 vid);
+ struct net_bridge_mdb_entry *br_mdb_get(struct net_bridge *br,
+   struct sk_buff *skb, u16 vid);
+ void br_multicast_add_port(struct net_bridge_port *port);
+ void br_multicast_del_port(struct net_bridge_port *port);
+ void br_multicast_enable_port(struct net_bridge_port *port);
+ void br_multicast_disable_port(struct net_bridge_port *port);
+ void br_multicast_init(struct net_bridge *br);
+ void br_multicast_open(struct net_bridge *br);
+ void br_multicast_stop(struct net_bridge *br);
+ void br_multicast_deliver(struct net_bridge_mdb_entry *mdst,
+ struct sk_buff *skb);
+ void br_multicast_forward(struct net_bridge_mdb_entry *mdst,
+ struct sk_buff *skb, struct sk_buff *skb2);
+ int br_multicast_set_router(struct net_bridge *br, unsigned long val);
+ int br_multicast_set_port_router(struct net_bridge_port *p, unsigned long 
val);
+ int br_multicast_toggle(struct net_bridge *br, unsigned long val);
+ int br_multicast_set_querier(struct net_bridge *br, unsigned long val);
+ int br_multicast_set_hash_max(struct net_bridge *br, unsigned long val);
+ struct net_bridge_mdb_entry *
+ br_mdb_ip_get(struct net_bridge_mdb_htable *mdb, struct br_ip *dst);
+ struct net_bridge_mdb_entry *
+ br_multicast_new_group(struct net_bridge *br, struct net_bridge_port *port,
+  struct br_ip *group);
+ void br_multicast_free_pg(struct rcu_head *head);
+ struct net_bridge_port_group *
+ br_multicast_new_port_group(struct net_bridge_port *port, struct br_ip *group,
+

RE: [PATCH 1/1] MTD: UBI: try to avoid program data to NOR flash after erasure interrupted

2013-10-30 Thread qiwang 
On Tue, 2013-10-29 at 11:19 +, Artem Bityutskiy wrote:
> On Mon, 2013-10-28 at 04:54 +, Qi Wang 王起 (qiwang) wrote:
> > On Sa, 2013-10-26 at 05:19 +, Artem Bityutskiy wrote:
> > > On Thu, 2013-10-10 at 08:28 +, Qi Wang 王起 (qiwang) wrote:
> > > > But I want to say the potential risk is if low level driver program 
> > > > data to 
> > > > this block, it will get “timeout error”. And the timeout period could 
> > > > be very 
> > > > long(almost several minutes), during this period, any operation on NOR 
> > > > flash 
> > > > cannot be accept. so program data to a erasure interrupted block isn’t 
> > > > a 
> > > > sensible action. in order to avoid program a erasure interrupted block, 
> > > > I suggest UBIFS can read this block before program data. the code 
> > > > changing as below:
> > > 
> > > Yes, reading first sounds like a good idea. Would you please send a
> > > patch implementing it?
> > 
> > From: Qi Wang 
> > 
> > nor_erase_prepare() will be called before erase a NOR flash, it will 
> > program '0'
> > into a block to mark this block. But program data into a erasure 
> > interrupted block
> > can cause program timtout(several minutes at most) error, could impact 
> > other 
> > operation on NOR flash. So UBIFS can read this block first to avoid 
> > unneeded 
> > program operation. 
> > 
> > This patch try to put read operation at at head of write operation in 
> > nor_erase_prepare(), read out the data. 
> > If the data is already corrupt, then no need to program any data into this 
> > block, 
> > just go to erase this block.
> > 
> > Signed-off-by: Qi Wang 
> > ---
> > diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c
> > index bf79def..be6ab56 100644
> > --- a/drivers/mtd/ubi/io.c
> > +++ b/drivers/mtd/ubi/io.c
> > @@ -509,26 +509,10 @@ static int nor_erase_prepare(struct ubi_device *ubi, 
> > int pnum)
> > struct ubi_vid_hdr vid_hdr;
> >  
> > /*
> > -* It is important to first invalidate the EC header, and then the VID
> > -* header. Otherwise a power cut may lead to valid EC header and
> > -* invalid VID header, in which case UBI will treat this PEB as
> > -* corrupted and will try to preserve it, and print scary warnings.
> > -*/
> > -   addr = (loff_t)pnum * ubi->peb_size;
> > -   err = mtd_write(ubi->mtd, addr, 4, , (void *));
> > -   if (!err) {
> > -   addr += ubi->vid_hdr_aloffset;
> > -   err = mtd_write(ubi->mtd, addr, 4, , (void *));
> > -   if (!err)
> > -   return 0;
> > -   }
> 
> How about structuring the code this way:
> 
> if (EC header is good)
>  invalidate EC header()
> if (VID header is good)
>  invalidate VID header()
> 
> Then you'll handle the case when only one of the headers is already
> corrupted.
>
> -- 
> Best Regards,
> Artem Bityutskiy


Hi Artem:
Please check below patch. 

From: Qi Wang 

nor_erase_prepare() will be called before erase a NOR flash, it will program '0'
into a block to mark this block. But program data into a erasure interrupted 
block
can cause program timtout(several minutes at most) error, could impact other 
operation on NOR flash. So UBIFS can read this block first to avoid unneeded 
program operation. 
 
This patch try to put read operation at at head of write operation in 
nor_erase_prepare(), read out the data. 
If the data is already corrupt, then no need to program any data into this 
block, 
just go to erase this block.

Signed-off-by: Qi Wang 
---
diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c
index bf79def..0fdaca9 100644
--- a/drivers/mtd/ubi/io.c
+++ b/drivers/mtd/ubi/io.c
@@ -499,59 +499,44 @@ static int nor_erase_prepare(struct ubi_device *ubi, int 
pnum)
size_t written;
loff_t addr;
uint32_t data = 0;
-   /*
-* Note, we cannot generally define VID header buffers on stack,
-* because of the way we deal with these buffers (see the header
-* comment in this file). But we know this is a NOR-specific piece of
-* code, so we can do this. But yes, this is error-prone and we should
-* (pre-)allocate VID header buffer instead.
-*/
struct ubi_vid_hdr vid_hdr;
+   struct ubi_ec_hdr ec_hdr;
+
+   addr = (loff_t)pnum * ubi->peb_size;
 
/*
+* If VID or EC is valid, need to corrupt it before erase operation.  
 * It is important to first invalidate the EC header, and then the VID
 * header. Otherwise a power cut may lead to valid EC header and
 * invalid VID header, in which case UBI will treat this PEB as
 * corrupted and will try to preserve it, and print scary warnings.
 */
-   addr = (loff_t)pnum * ubi->peb_size;
-   err = mtd_write(ubi->mtd, addr, 4, , (void *));
-   if (!err) {
-   addr += ubi->vid_hdr_aloffset;
-   err = mtd_write(ubi->mtd, addr, 4, , (void *));
-   if (!err)
-   return 0;
+   err =

Re: [RFC PATCH] kernel/kallsyms.c: only show legal kernel symbol

2013-10-30 Thread Rusty Russell 
Russell King - ARM Linux  writes:
> On Mon, Oct 28, 2013 at 04:20:19PM +1030, Rusty Russell wrote:
>> Ming Lei  writes:
>> > On Mon, 28 Oct 2013 13:44:30 +1030
>> > Rusty Russell  wrote:
>> >
>> >> Ming Lei  writes:
>> >> 
>> >> I don't know...  It would be your job, as the person making the change,
>> >> to find all the users of kallsyms and prove that.
>> >> 
>> >> This is why it is easier not to include incorrect values in the kernel's
>> >> kallsyms in the first place.
>> >
>> > OK, thanks for your comment, and I figured out one way to do it in
>> > scripts/kallsyms.c, could you comment on below patch?
>> 
>> Looks great! Seems like we spent more time arguing than it took you to
>> code that up.
>> 
>> Acked-by: Rusty Russell 
>> 
>> Russell, this seems logical for you to take along with the changes which
>> caused the problem?
>
> The changes are already in mainline since a long time (back in July/August
> time).  Am I the right person to take stuff for scripts/ ?  Isn't that
> more kbuild territory?

Kallsyms tends to fall between modules and scripts.  I assume it's not
urgent, so no cc:stable on this one.

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

Re: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit

2013-10-30 Thread Gao feng 
Hi Eric Paris,

Can you give me some comments?

You think the tying audit namespace to user namespace is a bad idea,
so this patchset doesn't assign auditns to userns and introduce an
new audit netlink type to help to create audit namespace.

and this patchset also introduces an new proc interface to make
sure container can't influence the whole system.

and the audit rules are not namespace aware, all of audit namespaces
should comply with the rules. in next step, if we find it's need to
make audit rules per audit namespace, then it's the time to do that
job.

This patchset also makes all of net namespaces have ability to send/
receive audit netlink message.

I may miss some points, if you find there are some shortage or loophole,
please let me know.

Thanks!

On 10/24/2013 03:31 PM, Gao feng wrote:
> Here is the v1 patchset: http://lwn.net/Articles/549546/
> 
> The main target of this patchset is allowing user in audit
> namespace to generate the USER_MSG type of audit message,
> some userspace tools need to generate audit message, or
> these tools will broken.
> 
> And the login process in container may want to setup
> /proc//loginuid, right now this value is unalterable
> once it being set. this will also broke the login problem
> in container. After this patchset, we can reset this loginuid
> to zero if task is running in a new audit namespace.
> 
> Same with v1 patchset, in this patchset, only the privileged
> user in init_audit_ns and init_user_ns has rights to
> add/del audit rules. and these rules are gloabl. all
> audit namespace will comply with the rules.
> 
> Compared with v1, v2 patch has some big changes.
> 1, the audit namespace is not assigned to user namespace.
>since there is no available bit of flags for clone, we
>create audit namespace through netlink, patch[18/20]
>introduces a new audit netlink type AUDIT_CREATE_NS.
>the privileged user in userns has rights to create a
>audit namespace, it means the unprivileged user can
>create auditns through create userns first. In order
>to prevent them from doing harm to host, the default
>audit_backlog_limit of un-init-audit-ns is zero(means
>audit is unavailable in audit namespace). and it can't
>be changed in auditns through netlink.
> 
> 2, introduce /proc//audit_log_limit
>this interface is used to setup log_limit of audit
>namespace.  we need this interface to make audit
>available in un-init-audit-ns. Only the privileged user
>has right to set this value, it means only the root user
>of host can change it.
> 
> 3, make audit namespace don't depend on net namespace.
>patch[1/20] add a compare function audit_compare for
>audit netlink, it always return true, it means the
>netlink subsystem will find out the netlink socket
>only through portid and netlink type. So we needn't
>to create kernel side audit netlink socket for per
>net namespace, all userspace audit netlink socket
>can find out the audit_sock, and audit_sock can
>communicate with them through the proper portid.
>it's just like the behavior we don't have net
>namespace before.
> 
> 
> This patchset still need some work, such as allow changing
> audit_enabled in audit namespace, auditd wants this feature.
> 
> I send this patchset now in order to get more comments, so
> I can keep on improving namespace support for audit.
> 
> Gao feng (20):
>   Audit: make audit netlink socket net namespace unaware
>   audit: introduce configure option CONFIG_AUDIT_NS
>   audit: make audit_skb_queue per audit namespace
>   audit: make audit_skb_hold_queue per audit namespace
>   audit: make audit_pid per audit namespace
>   audit: make kauditd_task per audit namespace
>   aduit: make audit_nlk_portid per audit namespace
>   audit: make kaudit_wait queue per audit namespace
>   audit: make audit_backlog_wait per audit namespace
>   audit: allow un-init audit ns to change pid and portid only
>   audit: use proper audit namespace in audit_receive_msg
>   audit: use proper audit_namespace in kauditd_thread
>   audit: introduce new audit logging interface for audit namespace
>   audit: pass proper audit namespace to audit_log_common_recv_msg
>   audit: Log audit pid config change in audit namespace
>   audit: allow GET,SET,USER MSG operations in audit namespace
>   nsproxy: don't make create_new_namespaces static
>   audit: add new message type AUDIT_CREATE_NS
>   audit: make audit_backlog_limit per audit namespace
>   audit: introduce /proc//audit_backlog_limit
> 
>  fs/proc/base.c  |  53 ++
>  include/linux/audit.h   |  26 ++-
>  include/linux/audit_namespace.h |  92 ++
>  include/linux/nsproxy.h |  15 +-
>  include/uapi/linux/audit.h  |   1 +
>  init/Kconfig|  10 ++
>  kernel/Makefile |   2 +-
>  kernel/audit.c  | 364 
> +---
>  kernel/audit.h  |   5

Re: [PATCH] Generic WorkQueue Engine (GenWQE) device driver (v4)

2013-10-30 Thread Ryan Mallon 
On 30/10/13 20:32, Frank Haverkamp wrote:
> From: Frank Haverkamp 

> Signed-off-by: Frank Haverkamp 
> Co-authors: Joerg-Stephan Vogt ,
> Michael Jung ,
> Michael Ruettger 
> ---
>  Documentation/ABI/testing/debugfs-driver-genwqe |   57 +
>  Documentation/ABI/testing/sysfs-driver-genwqe   |   46 +
>  drivers/misc/Kconfig|1 +
>  drivers/misc/Makefile   |1 +
>  drivers/misc/genwqe/Kconfig |   23 +
>  drivers/misc/genwqe/Makefile|8 +
>  drivers/misc/genwqe/card_base.c | 1238 +++
>  drivers/misc/genwqe/card_base.h |  569 +
>  drivers/misc/genwqe/card_ddcb.c | 1380 +
>  drivers/misc/genwqe/card_ddcb.h |  188 +++
>  drivers/misc/genwqe/card_debugfs.c  |  566 +
>  drivers/misc/genwqe/card_dev.c  | 1499 
> +++
>  drivers/misc/genwqe/card_sysfs.c|  306 +
>  drivers/misc/genwqe/card_utils.c|  983 +++
>  drivers/misc/genwqe/genwqe_driver.h |   75 ++
>  include/linux/genwqe/genwqe_card.h  |  559 +
>  16 files changed, 7499 insertions(+), 0 deletions(-)


Please consider breaking this into multiple patches. One behemoth patch
is harder to review and less likely for people to read all of it. Since
this adds a new driver, you can add it in parts, e.g: core, sysfs,
documentation, etc, and add the Makefile/Kconfig bits in the final
patch. That way it won't break the build at any point.

Couple of comments on the sysfs bits below.

~Ryan

> +++ b/drivers/misc/genwqe/card_sysfs.c
> @@ -0,0 +1,306 @@
> +/**
> + * IBM Accelerator Family 'GenWQE'
> + *
> + * (C) Copyright IBM Corp. 2013
> + *
> + * Author: Frank Haverkamp 
> + * Author: Joerg-Stephan Vogt 
> + * Author: Michael Jung 
> + * Author: Michael Ruettger 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License (version 2 only)
> + * as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +/*
> + * Sysfs interfaces for the GenWQE card. There are attributes to query
> + * the version of the bitstream as well as some for the
> + * driver. Additionally there are some attributes which help to debug
> + * potential problems.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "card_base.h"
> +#include "card_ddcb.h"
> +
> +static const char * const genwqe_types[] = {
> + [GENWQE_TYPE_ALTERA_230] = "GenWQE4-230",
> + [GENWQE_TYPE_ALTERA_530] = "GenWQE4-530",
> + [GENWQE_TYPE_ALTERA_A4]  = "GenWQE5-A4",
> + [GENWQE_TYPE_ALTERA_A7]  = "GenWQE5-A7",
> +};
> +
> +static ssize_t show_card_status(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + ssize_t len = 0;
> + struct genwqe_dev *cd = dev_get_drvdata(dev);
> + const char *cs[GENWQE_CARD_STATE_MAX] = { "unused", "used", "error" };
> +
> + len += scnprintf([len], PAGE_SIZE - len,
> +  "%s\n", cs[cd->card_state]);
> + return len;

This is a bit confusingly written. Why do:

scnprintf([len], ...

When len is always zero at that point? Since you are printing from an
array of statically sized strings that are guaranteed to be smaller than
PAGE_SIZE, you can safely do:

sprintf(buf, "%s\n", cs[cd->card_state]);

You might want to add some checking for cd->card_state being out of
bounds, and printing "unknown" or something in that case.

Same issue exists in other sysfs handlers.

> +}
> +
> +static ssize_t show_card_appid(struct device *dev,
> +struct device_attribute *attr,
> +char *buf)
> +{
> + ssize_t len = 0;
> + char app_name[5];
> + struct genwqe_dev *cd = dev_get_drvdata(dev);
> +
> + genwqe_read_app_id(cd, app_name, sizeof(app_name));
> + len += scnprintf([len], PAGE_SIZE - len,
> +  "%s\n", app_name);
> + return len;
> +}
> +
> +static ssize_t show_card_version(struct device *dev,
> +  struct device_attribute *attr,
> +  char *buf)
> +{
> + ssize_t len = 0;
> + u64 slu_id, app_id;
> + struct genwqe_dev *cd = dev_get_drvdata(dev);
> +
> + slu_id = __genwqe_readq(cd, IO_SLU_UNITCFG);
> + app_id = __genwqe_readq(cd, IO_APP_UNITCFG);
> +
> + len += scnprintf([len], PAGE_SIZE - len,
> +

Re: [PATCH] [trivial] doc: usb: Fix typo in Documentation/usb/gadget_configs.txt

2013-10-30 Thread Randy Dunlap 
On 10/30/13 18:57, Masanari Iida wrote:
> Correct spelling typo in Documentation/usb/gadget_configs.txt
> 
> Signed-off-by: Masanari Iida 

Acked-by: Randy Dunlap 

Thanks.

> ---
>  Documentation/usb/gadget_configfs.txt | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)


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

Re: perf confused by modules being loaded in between addresses in /proc/kallsyms

2013-10-30 Thread Ming Lei 
Hi Michael,

On Wed, Oct 30, 2013 at 8:53 AM, Michael Hudson-Doyle
 wrote:
> Hi,
>
> On arm, probably since "ARM: use linker magic for vectors and vector
> stubs" (although I haven't checked this), perf report tends to allocate
> all kernel time to the module loaded at the highest address.
>
> This turns out to be because the "perf_event__synthesize_modules"
> generates a PERF_RECORD_MMAP for the last module thats runs from its
> start to the end of the address space.
>
> This in turn turns out be because the first symbol in /proc/kallsyms is
> now at 0:
>
> # head -n 2 /proc/kallsyms
>  t __vectors_start

I think it is the root cause, so I posted the below patch to
remove these symbols from /proc/kallsyms days ago:

 http://marc.info/?l=linux-kernel=138297540711321=2

On ARM, this symbol of zero address is only for generating code, and
won't be run really by CPU, so it shouldn't be in /proc/kallsyms.

> c00081c0 T asm_do_IRQ
>
> /This/ means that the kallsyms entry in machine->kmaps[MAP__FUNCTION] is
> now the first entry rather than the last in the map, so the last module
> is the last in the map and so its "end" stays as ~0ULL.
>
> I'm told that there is no particularly good reason for __vectors_start
> to be in kallsyms at 0, but in any case this seems like a bug in the
> user space tool.  I notice that there is code to split the kallsyms

I am wondering if it is bug in perf utility, since perf may use /proc/kallsyms
to figure out the start address of symbols in kernel address space, but with
the zero address, looks not easy to figure out the real start address of
symbols inside kernel if vmlinux file is missed, then can't parse kernel
IP any more.


Thanks,
-- 
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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/6] Cleanup efi_enter_virtual_mode function

2013-10-30 Thread H. Peter Anvin 
On 10/30/2013 07:07 PM, Dave Young wrote:
> On 10/31/13 at 10:04am, Dave Young wrote:
>> On 10/30/13 at 11:47am, Borislav Petkov wrote:
>>> On Wed, Oct 30, 2013 at 10:03:49AM +0800, Dave Young wrote:
 Will try, but please keep the posted patches in mailing list up-to-date,
>>>
>>> Would you like me to send them to you privately?
>>
>> Thanks, do not bother to send me privately I can get it from your git tree.
>>
>> But Frankly I'd like to see them in list instead even with only small fixes
>> beacuse in this way there might be more people to review it carefully.
> 
> There's another shorcoming for keeping new patches in git is that nobody know
> when you push it and when is the proper date to pull from your git. I think
> it's better to use git only for the patches which have already been accepted
> and is waiting for maintainer to pull.
> 

You can use git for your own purposes, still.

-hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] md/raid5: For stripe with R5_ReadNoMerge, we replace REQ_FLUSH with REQ_NOMERGE.

2013-10-30 Thread NeilBrown 
On Wed, 30 Oct 2013 10:41:46 +0800 majianpeng  wrote:

> For R5_ReadNoMerge,it mean this bio can't merge with other bios or
> request.It used REQ_FLUSH to achieve this. But REQ_NOMERGE can do the
> same work.
> 
> Signed-off-by: Jianpeng Ma 
> ---
>  drivers/md/raid5.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index f8b9068..8e0aeaa 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -772,7 +772,7 @@ static void ops_run_io(struct stripe_head *sh, struct 
> stripe_head_state *s)
>   bi->bi_sector = (sh->sector
>+ rdev->data_offset);
>   if (test_bit(R5_ReadNoMerge, >dev[i].flags))
> - bi->bi_rw |= REQ_FLUSH;
> + bi->bi_rw |= REQ_NOMERGE;
>  
>   bi->bi_vcnt = 1;
>   bi->bi_io_vec[0].bv_len = STRIPE_SIZE;

Thanks.

I've queued this up pending Jens' acceptance of the other patches.

By the way, your patch file has a carriage return as well as a newline at the
end of each line.
"patch" can still handle them but "git am" doesn't like it.

If you are able to send the patches as plain text with just a NEWLINE at the
end of each line, rather than base64 encodes with carriage returns, it would
help a little.

Thanks,
NeilBrown


signature.asc
Description: PGP signature

Re: [PATCH v4 1/3] hwmon: (lm90) Define status bits

2013-10-30 Thread Wei Ni 
On 10/31/2013 10:47 AM, Wei Ni wrote:
> On 10/30/2013 11:41 PM, Jean Delvare wrote:
>> Hi Wei,
>>
>> On Wed, 7 Aug 2013 14:18:24 +0800, Wei Ni wrote:
>>> Add bit defines for the status register. And add a function
>>> lm90_is_tripped() which will read status register and return
>>> tripped or not, then lm90_alert can call it directly, and in the
>>> future the IRQ thread also can use it.
>>>
>>> Signed-off-by: Wei Ni 
>>> ---
>>>  drivers/hwmon/lm90.c |   75 
>>> +-
>>>  1 file changed, 50 insertions(+), 25 deletions(-)
>>>
>>> diff --git a/drivers/hwmon/lm90.c b/drivers/hwmon/lm90.c
>>> index cdff742..1da2eff 100644
>>> --- a/drivers/hwmon/lm90.c
>>> +++ b/drivers/hwmon/lm90.c
>>> @@ -179,6 +179,18 @@ enum chips { lm90, adm1032, lm99, lm86, max6657, 
>>> max6659, adt7461, max6680,
>>>  #define LM90_HAVE_TEMP3(1 << 6) /* 3rd temperature sensor  
>>> */
>>>  #define LM90_HAVE_BROKEN_ALERT (1 << 7) /* Broken alert
>>> */
>>>  
>>> +/* LM90 status */
>>> +#define LM90_STATUS_LTHRM  (1 << 0) /* local THERM limit tripped */
>>> +#define LM90_STATUS_RTHRM  (1 << 1) /* remote THERM limit tripped */
>>> +#define LM90_STATUS_OPEN   (1 << 2) /* remote is an open circuit */
>>> +#define LM90_STATUS_RLOW   (1 << 3) /* remote low temp limit tripped */
>>> +#define LM90_STATUS_RHIGH  (1 << 4) /* remote high temp limit tripped */
>>> +#define LM90_STATUS_LLOW   (1 << 5) /* local low temp limit tripped */
>>> +#define LM90_STATUS_LHIGH  (1 << 6) /* local high temp limit tripped */
>>> +
>>> +#define MAX6696_STATUS2_RLOW   (1 << 3) /* remote2 low temp limit 
>>> tripped */
>>> +#define MAX6696_STATUS2_RHIGH  (1 << 4) /* remote2 high temp limit 
>>> tripped */
>>> +
>>>  /*
>>>   * Driver data (common to all clients)
>>>   */
>>> @@ -1391,6 +1403,36 @@ static void lm90_init_client(struct i2c_client 
>>> *client)
>>> i2c_smbus_write_byte_data(client, LM90_REG_W_CONFIG1, config);
>>>  }
>>>  
>>> +static bool lm90_is_tripped(struct i2c_client *client)
>>> +{
>>> +   struct lm90_data *data = i2c_get_clientdata(client);
>>> +   u8 status, status2 = 0;
>>> +
>>> +   lm90_read_reg(client, LM90_REG_R_STATUS, );
>>> +
>>> +   if (data->kind == max6696)
>>> +   lm90_read_reg(client, MAX6696_REG_R_STATUS2, );
>>> +
>>> +   if ((status & 0x7f) == 0 && (status2 & 0xfe) == 0)
>>> +   return false;
>>> +
>>> +   if (status & (LM90_STATUS_LLOW | LM90_STATUS_LHIGH | LM90_STATUS_LTHRM))
>>> +   dev_warn(>dev,
>>> +"temp%d out of range, please check!\n", 1);
>>> +   if (status & (LM90_STATUS_RLOW | LM90_STATUS_RHIGH | LM90_STATUS_RTHRM))
>>> +   dev_warn(>dev,
>>> +"temp%d out of range, please check!\n", 2);
>>> +   if (status & LM90_STATUS_OPEN)
>>> +   dev_warn(>dev,
>>> +"temp%d diode open, please check!\n", 2);
>>> +
>>> +   if (status2 & (MAX6696_STATUS2_RLOW | MAX6696_STATUS2_RHIGH))
>>> +   dev_warn(>dev,
>>> +"temp%d out of range, please check!\n", 3);
>>> +
>>> +   return true;
>>> +}
>>> +
>>>  static int lm90_probe(struct i2c_client *client,
>>>   const struct i2c_device_id *id)
>>>  {
>>> @@ -1489,36 +1531,17 @@ static int lm90_remove(struct i2c_client *client)
>>>  
>>>  static void lm90_alert(struct i2c_client *client, unsigned int flag)
>>>  {
>>> -   struct lm90_data *data = i2c_get_clientdata(client);
>>> -   u8 config, alarms, alarms2 = 0;
>>> -
>>> -   lm90_read_reg(client, LM90_REG_R_STATUS, );
>>> -
>>> -   if (data->kind == max6696)
>>> -   lm90_read_reg(client, MAX6696_REG_R_STATUS2, );
>>> -
>>> -   if ((alarms & 0x7f) == 0 && (alarms2 & 0xfe) == 0) {
>>> -   dev_info(>dev, "Everything OK\n");
>>> -   } else {
>>> -   if (alarms & 0x61)
>>> -   dev_warn(>dev,
>>> -"temp%d out of range, please check!\n", 1);
>>> -   if (alarms & 0x1a)
>>> -   dev_warn(>dev,
>>> -"temp%d out of range, please check!\n", 2);
>>> -   if (alarms & 0x04)
>>> -   dev_warn(>dev,
>>> -"temp%d diode open, please check!\n", 2);
>>> -
>>> -   if (alarms2 & 0x18)
>>> -   dev_warn(>dev,
>>> -"temp%d out of range, please check!\n", 3);
>>> -
>>> +   if (lm90_is_tripped(client)) {
>>
>> You are reading LM90_REG_R_STATUS here...
>>
>>> /*
>>>  * Disable ALERT# output, because these chips don't implement
>>>  * SMBus alert correctly; they should only hold the alert line
>>>  * low briefly.
>>>  */
>>> +   struct lm90_data *data = i2c_get_clientdata(client);
>>> +   u8 config, alarms;
>>> +
>>> +   lm90_read_reg(client, LM90_REG_R_STATUS, );
>>
>> ... and here again. I already complained about this in my

RE: [PATCH] net/cdc_ncm: fix null pointer panic at usbnet_link_change

2013-10-30 Thread Du, ChangbinX 
> From: Bjørn Mork [mailto:bj...@mork.no]
> Sent: Tuesday, October 29, 2013 4:41 PM
> To: Du, ChangbinX
> Cc: oli...@neukum.org; linux-...@vger.kernel.org; net...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] net/cdc_ncm: fix null pointer panic at usbnet_link_change
> 
> "Du, ChangbinX"  writes:
> 
> > From: "Du, Changbin" 
> >
> > In cdc_ncm_bind() function, it call cdc_ncm_bind_common() to setup usb.
> > But cdc_ncm_bind_common() may meet error and cause usbnet_disconnect()
> > be called which calls free_netdev(net).
> 
> I am sure you are right, but I really don't see how that can happen.
> 
> AFAICS, we ensure that the intfdata is set to NULL before calling
> usb_driver_release_interface() in the error cleanup in
> cdc_ncm_bind_common():
> 
> 
> error2:
>   usb_set_intfdata(ctx->control, NULL);
>   usb_set_intfdata(ctx->data, NULL);
>   if (ctx->data != ctx->control)
>   usb_driver_release_interface(driver, ctx->data);
> error:
>   cdc_ncm_free((struct cdc_ncm_ctx *)dev->data[0]);
>   dev->data[0] = 0;
>   dev_info(>udev->dev, "bind() failure\n");
>   return -ENODEV;
> 
> 
> Thus we hit the test in disconnect, and usbnet_disconnect() is never
> called:
> 
> static void cdc_ncm_disconnect(struct usb_interface *intf)
> {
>   struct usbnet *dev = usb_get_intfdata(intf);
> 
>   if (dev == NULL)
>   return; /* already disconnected */
> 
>   usbnet_disconnect(intf);
> }
> 
> So we should really be OK, but we are not  I would appreciate it if
> anyone took the time to feed me why, with a very small spoon...
> 

Yes, you are right. It should not happen if cdc_ncm_disconnect is not called. 
But this really happened.
It produced on kernel 3.10. Here is the full panic message for you to refer. I 
will get a method try to 
reproduce it.

[   15.635727] BUG: Bad page state in process khubd  pfn:31994
[   15.641989] page:f3ad9280 count:0 mapcount:0 mapping:0020 index:0x0
[   15.649384] page flags: 0x4000()
[   15.670096] BUG: unable to handle kernel NULL pointer dereference at 0078
[   15.678078] IP: [] usbnet_link_change+0x1e/0x80
[   15.684120] *pde =  
[   15.687339] Oops:  [#1] SMP 
[   15.690953] Modules linked in: atmel_mxt_ts vxd392 videobuf_vmalloc 
videobuf_core bcm_bt_lpm bcm432)
[   15.702658] CPU: 0 PID: 573 Comm: khubd Tainted: GB   W  O 3.10.1+ #1
[   15.710241] task: f27e8f30 ti: f2084000 task.ti: f2084000
[   15.716270] EIP: 0060:[] EFLAGS: 00010246 CPU: 0
[   15.722396] EIP is at usbnet_link_change+0x1e/0x80
[   15.727747] EAX: f18524c0 EBX:  ECX: f18524c0 EDX: 
[   15.734746] ESI: f18524c0 EDI:  EBP: f2085b7c ESP: f2085b70
[   15.741746] DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
[   15.747775] CR0: 8005003b CR2: 0078 CR3: 02c3b000 CR4: 001007d0
[   15.754774] DR0:  DR1:  DR2:  DR3: 
[   15.761774] DR6: 0ff0 DR7: 0400
[   15.766054] Stack:
[   15.768295]   f18524c0 c2a03818 f2085b8c c24bc69a f1852000 f1f52e00 
f2085be0
[   15.776991]  c24b8d32  0001  c2167f2c f2085bb4 c2821253 
f2085bec
[   15.785687]  0246 0246 f18d8088 f1f52e1c f1fce464 f1fce400 f18524c0 
c28a06e0
[   15.794376] Call Trace:
[   15.797109]  [] cdc_ncm_bind+0x3a/0x50
[   15.802267]  [] usbnet_probe+0x282/0x7d0
[   15.807621]  [] ? sysfs_new_dirent+0x6c/0x100
[   15.813460]  [] ? mutex_lock+0x13/0x40
[   15.818618]  [] cdc_ncm_probe+0x8/0x10
[   15.823777]  [] usb_probe_interface+0x187/0x2c0
[   15.829811]  [] ? driver_sysfs_add+0x6a/0x90
[   15.835550]  [] ? __driver_attach+0x90/0x90
[   15.841192]  [] driver_probe_device+0x74/0x360
[   15.847127]  [] ? usb_match_id+0x41/0x60
[   15.852479]  [] ? usb_device_match+0x4e/0x90
[   15.858219]  [] ? __driver_attach+0x90/0x90
[   15.863861]  [] __device_attach+0x39/0x50
[   15.869311]  [] bus_for_each_drv+0x34/0x70
[   15.874856]  [] device_attach+0x7b/0x90
[   15.880109]  [] ? __driver_attach+0x90/0x90
[   15.885752]  [] bus_probe_device+0x6f/0x90
[   15.891298]  [] device_add+0x558/0x630
[   15.896457]  [] ? usb_create_ep_devs+0x71/0xd0
[   15.902391]  [] ? create_intf_ep_devs+0x4b/0x70
[   15.908422]  [] usb_set_configuration+0x4bf/0x800
[   15.914648]  [] ? __driver_attach+0x90/0x90
[   15.920292]  [] generic_probe+0x2b/0x90
[   15.925546]  [] usb_probe_device+0x2c/0x70
[   15.931091]  [] driver_probe_device+0x74/0x360
[   15.943345]  [] ? kobject_uevent_env+0x182/0x620
[   15.949473]  [] ? kobject_uevent_env+0x182/0x620
[   15.955601]  [] ? __driver_attach+0x90/0x90
[   15.961242]  [] __device_attach+0x39/0x50
[   15.966692]  [] bus_for_each_drv+0x34/0x70
[   15.972238]  [] device_attach+0x7b/0x90
[   15.977492]  [] ? __driver_attach+0x90/0x90
[   15.983135]  [] bus_probe_device+0x6f/0x90
[   15.988682]  [] device_add+0x558/0x630
[   15.993841]  [] ? add_device_randomness+0x60/0x70
[   16.69]  [] usb_new_device+0x1df/0x360
[   16.005616]  [] ?

Re: [PATCH 0/2] make all stored entries accessible.

2013-10-30 Thread Madper Xie 

tony.l...@intel.com writes:

>> So, do you mean efivars should fix to use the "id" in a proper way?
>
> It would avoid the need for all these tests, and additions to the filename to 
> guarantee
> uniqueness.
>
> Not sure what options efivars has to create a unique, persistent "id" for each
> record.  It's a fundamental part of how ERST works (though the unique ID is 
> just
> based around a timestamp).
>
Okay, maybe there are three options here:
1. combine timestamp, count and part into "id".
   for now, in efi-pstore.c, *id = part. and we could simply change it
   to unique one. F.E. *id = (timestamp * 100 + part) * 100 + count.
2. change the id's type. let id become a string.
   so every backend could write anything to id. then it will become a
   part of filename in pstore filesystem. (but we need fix all backends
   since we modified api.)
3. apply the patches I have sent... even if the filename will be ugly
   and gory...
Which one do you prefer?
>> I acked Madper's patch 2/2 earlier today, but when I look at your test 
>> result, I'm not sure if
>> it is reasonable for users to make multiple numbers visible to the file name.
>>
>>> -r--r--r-- 1 root root 17499 Oct 30 13:41 
>>> dmesg-erst-5940651313304961029--2129078373-1383165669
>
> after I added the "count = 0" initialization the filename gets a tiny bit less
> scary:
>
> -r--r--r-- 1 root root 17499 Oct 30 13:41 
> dmesg-erst-5940651313304961029-0-1383165669
>
> -Tony


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

[PATCH] fs/befs/linuxvfs.c: need signed cast for variable 'block'

2013-10-30 Thread Chen Gang 
Need signed cast for it, the original author assume the type of 'block'
is long, so just cast to long. The related warnings (with allmodconfig):

  fs/befs/linuxvfs.c:136:2: warning: comparison of unsigned expression < 0 is 
always false [-Wtype-limits]

Signed-off-by: Chen Gang 
---
 fs/befs/linuxvfs.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/befs/linuxvfs.c b/fs/befs/linuxvfs.c
index daa15d6..27e5179 100644
--- a/fs/befs/linuxvfs.c
+++ b/fs/befs/linuxvfs.c
@@ -133,7 +133,7 @@ befs_get_block(struct inode *inode, sector_t block,
befs_debug(sb, "---> befs_get_block() for inode %lu, block %ld",
   inode->i_ino, block);
 
-   if (block < 0) {
+   if ((long)block < 0) {
befs_error(sb, "befs_get_block() was asked for a block "
   "number less than zero: block %ld in inode %lu",
   block, inode->i_ino);
-- 
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 1/3] hwmon: (lm90) Define status bits

2013-10-30 Thread Wei Ni 
On 10/30/2013 11:41 PM, Jean Delvare wrote:
> Hi Wei,
> 
> On Wed, 7 Aug 2013 14:18:24 +0800, Wei Ni wrote:
>> Add bit defines for the status register. And add a function
>> lm90_is_tripped() which will read status register and return
>> tripped or not, then lm90_alert can call it directly, and in the
>> future the IRQ thread also can use it.
>>
>> Signed-off-by: Wei Ni 
>> ---
>>  drivers/hwmon/lm90.c |   75 
>> +-
>>  1 file changed, 50 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/hwmon/lm90.c b/drivers/hwmon/lm90.c
>> index cdff742..1da2eff 100644
>> --- a/drivers/hwmon/lm90.c
>> +++ b/drivers/hwmon/lm90.c
>> @@ -179,6 +179,18 @@ enum chips { lm90, adm1032, lm99, lm86, max6657, 
>> max6659, adt7461, max6680,
>>  #define LM90_HAVE_TEMP3 (1 << 6) /* 3rd temperature sensor  
>> */
>>  #define LM90_HAVE_BROKEN_ALERT  (1 << 7) /* Broken alert
>> */
>>  
>> +/* LM90 status */
>> +#define LM90_STATUS_LTHRM   (1 << 0) /* local THERM limit tripped */
>> +#define LM90_STATUS_RTHRM   (1 << 1) /* remote THERM limit tripped */
>> +#define LM90_STATUS_OPEN(1 << 2) /* remote is an open circuit */
>> +#define LM90_STATUS_RLOW(1 << 3) /* remote low temp limit tripped */
>> +#define LM90_STATUS_RHIGH   (1 << 4) /* remote high temp limit tripped */
>> +#define LM90_STATUS_LLOW(1 << 5) /* local low temp limit tripped */
>> +#define LM90_STATUS_LHIGH   (1 << 6) /* local high temp limit tripped */
>> +
>> +#define MAX6696_STATUS2_RLOW(1 << 3) /* remote2 low temp limit 
>> tripped */
>> +#define MAX6696_STATUS2_RHIGH   (1 << 4) /* remote2 high temp limit 
>> tripped */
>> +
>>  /*
>>   * Driver data (common to all clients)
>>   */
>> @@ -1391,6 +1403,36 @@ static void lm90_init_client(struct i2c_client 
>> *client)
>>  i2c_smbus_write_byte_data(client, LM90_REG_W_CONFIG1, config);
>>  }
>>  
>> +static bool lm90_is_tripped(struct i2c_client *client)
>> +{
>> +struct lm90_data *data = i2c_get_clientdata(client);
>> +u8 status, status2 = 0;
>> +
>> +lm90_read_reg(client, LM90_REG_R_STATUS, );
>> +
>> +if (data->kind == max6696)
>> +lm90_read_reg(client, MAX6696_REG_R_STATUS2, );
>> +
>> +if ((status & 0x7f) == 0 && (status2 & 0xfe) == 0)
>> +return false;
>> +
>> +if (status & (LM90_STATUS_LLOW | LM90_STATUS_LHIGH | LM90_STATUS_LTHRM))
>> +dev_warn(>dev,
>> + "temp%d out of range, please check!\n", 1);
>> +if (status & (LM90_STATUS_RLOW | LM90_STATUS_RHIGH | LM90_STATUS_RTHRM))
>> +dev_warn(>dev,
>> + "temp%d out of range, please check!\n", 2);
>> +if (status & LM90_STATUS_OPEN)
>> +dev_warn(>dev,
>> + "temp%d diode open, please check!\n", 2);
>> +
>> +if (status2 & (MAX6696_STATUS2_RLOW | MAX6696_STATUS2_RHIGH))
>> +dev_warn(>dev,
>> + "temp%d out of range, please check!\n", 3);
>> +
>> +return true;
>> +}
>> +
>>  static int lm90_probe(struct i2c_client *client,
>>const struct i2c_device_id *id)
>>  {
>> @@ -1489,36 +1531,17 @@ static int lm90_remove(struct i2c_client *client)
>>  
>>  static void lm90_alert(struct i2c_client *client, unsigned int flag)
>>  {
>> -struct lm90_data *data = i2c_get_clientdata(client);
>> -u8 config, alarms, alarms2 = 0;
>> -
>> -lm90_read_reg(client, LM90_REG_R_STATUS, );
>> -
>> -if (data->kind == max6696)
>> -lm90_read_reg(client, MAX6696_REG_R_STATUS2, );
>> -
>> -if ((alarms & 0x7f) == 0 && (alarms2 & 0xfe) == 0) {
>> -dev_info(>dev, "Everything OK\n");
>> -} else {
>> -if (alarms & 0x61)
>> -dev_warn(>dev,
>> - "temp%d out of range, please check!\n", 1);
>> -if (alarms & 0x1a)
>> -dev_warn(>dev,
>> - "temp%d out of range, please check!\n", 2);
>> -if (alarms & 0x04)
>> -dev_warn(>dev,
>> - "temp%d diode open, please check!\n", 2);
>> -
>> -if (alarms2 & 0x18)
>> -dev_warn(>dev,
>> - "temp%d out of range, please check!\n", 3);
>> -
>> +if (lm90_is_tripped(client)) {
> 
> You are reading LM90_REG_R_STATUS here...
> 
>>  /*
>>   * Disable ALERT# output, because these chips don't implement
>>   * SMBus alert correctly; they should only hold the alert line
>>   * low briefly.
>>   */
>> +struct lm90_data *data = i2c_get_clientdata(client);
>> +u8 config, alarms;
>> +
>> +lm90_read_reg(client, LM90_REG_R_STATUS, );
> 
> ... and here again. I already complained about this in my previous
> review of this patch, and you were supposed to address it, but you did
> not. As a result

Re: [PATCH 2/4] ARM: msm: Remove 7x00 support

2013-10-30 Thread Daniel Walker 
On Wed, Oct 30, 2013 at 05:36:58PM -0700, Olof Johansson wrote:
> On Wed, Oct 30, 2013 at 4:25 PM, Daniel Walker  wrote:
> 
> > So the current users of those platforms are, what SOL ?
> 
> What users? Show me one.
> 


What am I chop liver ?

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

Got iperf regression while intel_iommu is on, how to cut the cost of cache flushing

2013-10-30 Thread Ethan Zhao 
Hi guys,

 We got network I/O performance degradation with latest stable
kernel and the be2net driver as compared to old kernel 3.0.6.   later
we found even compared to
the same latest stable kernel but the INTEL_IOMMU set to 'n',  still
got very noticeable performance regression:

Kernel   : 3.11.x with  CONFIG_INTEL_IOMMU_DEFAULT_ON not set
Network driver: be2net

Average Bandwidth for :
   1.tcp-unidirectional test: 7908 Mbits/sec
   2.tcp-unidirectional-parallel: 9400 Mbits/sec
   3.tcp-bidirectonal test  : 5464 Mbits/sec

Kernel   : 3.11.x with CONFIG_INTEL_IOMMU_DEFAULT_ON set
Network driver: be2net

 Average Bandwidth for :
1.tcp-unidirectional test: 4380 Mbits/sec
2.tcp-unidirectional-parallel: 9400 Mbits/sec
3.tcp-bidirectonal test  : 2915 Mbits/sec

After did some profiling,  the main part of the cause points to the
cache flushing operation when Intel-IOMMU does mapping and un-mapping:

Notice the  clflush_cache_range while INTEL_IOMMU is on

 27.22%iperf  [kernel.kallsyms] [k] copy_user_generic_string
---> 5.86%iperf  [kernel.kallsyms] [k] clflush_cache_range
  3.99%iperf  [kernel.kallsyms] [k] put_page
  2.66%iperf  [kernel.kallsyms] [k] __ticket_spin_lock
  1.86%iperf  [kernel.kallsyms] [k] free_hot_cold_page
  1.68%iperf  [kernel.kallsyms] [k] skb_copy_datagram_iovec
  1.63%iperf  [kernel.kallsyms] [k] __domain_mapping
  1.57%iperf  [kernel.kallsyms] [k] rb_p

The ECAP_REG (extended capability register) of Intel IOMMU (vt-d) bit
0 shows it is not in "Coherency", OS must do cache flushing while
mapping and remapping etc.

The ECAP_REG bit 0 is configured by BIOS, I have some questions here :
1. Does the SandyBridge/Ivy Bridge platform  support coherent mode ?
So we could get rid of the  clflush_cache_range() cost by set the bit
0 to 1.

Searching Intel SDM didn't show up the answer, BWG neither.

2. Are there any other way to cut the cache flushing cost ?
Read some paper about it, so far , no good solution, right ?

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

Re: [Resend PATCH 5/5] IA64/PCI/ACPI: Rework PCI root bridge ACPI resource conversion

2013-10-30 Thread Lan Tianyu 
On 2013年10月31日 00:23, Bjorn Helgaas wrote:
> On Wed, Oct 30, 2013 at 2:34 AM, Lan Tianyu  wrote:
>> On 2013年10月29日 01:32, Bjorn Helgaas wrote:
>>>
>>> On Sat, Oct 26, 2013 at 10:53 AM, Lan Tianyu  wrote:

 On 10/24/2013 06:39 AM, Bjorn Helgaas wrote:
>
> On Fri, Oct 18, 2013 at 08:44:12PM +0800, Lan Tianyu wrote:
>>
>>
>> On 10/18/2013 04:33 AM, Bjorn Helgaas wrote:
>>>
>>>
>>> I wonder if it would make sense to make
>>> acpi_dev_resource_address_space() ignore addr.translation_offset for
>>> IO resources.  Or maybe ignore it if the _TTP (type translation) bit
>>> is set?
>>
>>
>>
>> I wonder why current code doesn't check _TTP? The code in the
>> add_io_space() seems to think _TTP is always set, right?
>
>
> I think it's an oversight, and you should fix it.  I suggest that you
> ignore the _TRA value when _TTP is set.  Obviously this only applies
> to I/O port resources, since _TTP is only defined in the I/O Resource
> Flag (Table 6-185 in ACPI 5.0 spec).


 _TTP is also defined in the Memory Resource flag, Please have a look at
 Table 6-184 in the ACPI 5.0 Spec.
>>>
>>>
>>> Yes, you're right.  That would be for a host bridge that converts I/O
>>> on the primary (upstream) side of the bridge to memory on the PCI
>>> side.  I've never seen such a bridge, and I can't really imagine why
>>> anybody would do that.  But I guess you should be able to safely
>>> ignore _TRA when _TTP is set in either a MEM or IO descriptor, because
>>> the same reasoning should apply to both.
>>>
 I am not sure how to deal with _TTP unsetting io resource? _TTP unsetting
 mean the resource is IO on the primary side and also IO on the secondary
 side.
>>>
>>>
>>> If _TTP is not set, I guess you would apply _TRA.  That's what you
>>> already do for MEM descriptors, and think you should just do the same
>>> for IO descriptors.  I would guess that having _TTP = 0 and _TRA != 0
>>> is rare for IO descriptors, but I suppose it could happen.
>>
>>
>> Yes, my concern is for the IO resource case of _TTP=0 and _TRA !=0. The
>> only reason for this case I think of is that the IO resource offsets on
>> the prime bus and second bus are different. In this case, we still need
>> to pass _TRA to new_space() and the finial resource->start still should be
>> acpi_resource->min + offset returned by add_io_space(), right?
> 
> No, I don't think so.  If the "phys_base" argument to new_space() is
> non-zero, it is the base of an MMIO region that needs to be
> ioremapped.  This is handling the _TTP=1 case, where the MMIO region
> is translated by the bridge into an IO region on PCI.
> 
> If _TTP=0, the region is IO on both the upstream and downstream sides
> of the host bridge, and we don't want to ioremap a new MMIO region for
> it.  It might be part of the "legacy I/O port space," but that's
> already covered elsewhere.
> 
> I don't think we need to add special handling for the _TTP=0 and _TRA
> != 0 case because I don't think it exists in the field.  If and when
> it *does* exist, we'll know what to do.  In the meantime, it should
> look just like the MEM path.


OK. I get it. acpi_dev_resource_address_space() will only apply _TRA to
resource ->start and ->end for both mem and io resource when _TTP=0. In
the add_window(), the offset returned by add_io_space() will be added
directly to ->start and ->end.

add_window() {
...
if (resource->flags & IORESOURCE_MEM) {
root = _resource;
offset = addr.translation_offset;
} else if (resource->flags & IORESOURCE_IO) {
root = _resource;

offset = add_io_space(info, );
if (offset == ~0)
return AE_OK;

resource->start += offset;
resource->end += offset;
} else
return AE_OK;

...
}

> 
>> If yes, I think _TRA can't be applied to IO resource in the
>> acpi_dev_resource_address_space() regardless of the value of _TTP.
>>
>> BTW, Translation Sparse(_TRS) is only meaningful if _TTP is set.(Table
>> 6-185). The add_io_space() doesn't check _TTP when set sparse. So this
>> should be corrected?
> 
> Sure, I'm OK with this.  It's possible we could trip over a BIOS bug
> where _TRS=1 but _TTP=0, but I think the risk is low because only
> large ia64 boxes would use this, and there aren't very many of those.
> 

Ok. I will add a check for _TTP before setting sparse. Something likes this.

add_io_space()
{
...
if (addr->info.io.translation == ACPI_TYPE_TRANSLATION &&
addr->info.io.translation_type == ACPI_SPARSE_TRANSLATION)
sparse = 1;
...
}



> Bjorn
> 


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

Re: [PATCH] mm: cma: free cma page to buddy instead of being cpu hot page

2013-10-30 Thread Laura Abbott 

On 10/29/2013 10:40 PM, Minchan Kim wrote:


We've had a similar patch in our tree for a year and a half because
of CMA migration failures, not just for a speedup in allocation
time. I understand that CMA is not the fast case or the general use
case but the problem is that the cost of CMA failure is very high
(complete failure of the feature using CMA). Putting CMA on the PCP
lists means they may be picked up by users who temporarily make the
movable pages unmovable (page cache etc.) which prevents the
allocation from succeeding. The problem still exists even if the CMA
pages are not on the PCP list but the window gets slightly smaller.


I understand that I have seen many people want to use CMA have tweaked
their system to work well and although they do best effort, it doesn't
work well because CMA doesn't gaurantee to succeed in getting free
space since there are lots of hurdle. (get_user_pages, AIO ring buffer,
buffer cache, short of free memory for migration, no swap and so on).
Even, someone want to allocate CMA space with speedy. SIGH.

Yeah, at the moment, CMA is really SUCK.



Yes, without hacks there are enough issues where it makes more sense to 
turn off CMA in some cases.




This really highlights one of the biggest issues with CMA today.
Movable pages make return -EBUSY for any number of reasons. For
non-CMA pages this is mostly fine, another movable page may be
substituted for the movable page that is busy. CMA is a restricted
range though so any failure in that range is very costly because CMA
regions are generally sized exactly for the use cases at hand which
means there is very little extra space for retries.

To make CMA actually usable, we've had to go through and add in
hacks/quirks that prevent CMA from being allocated in any path which
may prevent migration. I've been mixed on if this is the right path
or if the definition of MIGRATE_CMA needs to be changed to be more
restrictive (can't prevent migration).


Fundamental problem is that every subsystem could grab a page anytime
and they doesn't gaurantee to release it soonish or within time CMA
user want so it turns out non-determisitic mess which just hook into
core MM system here and there.

Sometime, I see some people try to solve it case by case with ad-hoc
approach. I guess it would be never ending story as kernel evolves.

I suggest that we could make new wheel with frontswap/cleancache stuff.
The idea is that pages in frontswap/cleancache are evicted from kernel
POV so that we can gaurantee that there is no chance to grab a page
in CMA area and we could remove lots of hook from core MM which just
complicated MM without benefit.

As benefit, cleancache pages could drop easily so it would be fast
to get free space but frontswap cache pages should be move into somewhere.
If there are enough free pages, it could be migrated out there. Optionally
we could compress them. Otherwise, we could pageout them into backed device.
Yeah, it could be slow than migration but at least, we could estimate the time
by storage speed ideally so we could have tunable knob. If someone want
fast CMA, he could control it with ratio of cleancache:frontswap.
IOW, higher frontswap page ratio is, slower the speed would be.
Important thing is admin could have tuned control knob and it gaurantees to
get CMA free space with deterministic time.



Before CMA was available, we attempted to do something similar with 
carved out memory where we hooked up the carveout to tmem and 
cleancache. The feature never really went anywhere because we saw 
impacts on file system benchmarks (too much time copying data to 
carveout memory). The feature has long been deprecated and we never 
debugged too far. Admittedly, this was many kernel versions ago and with 
a backport of various patches to an older kernel so I'd take our results 
with a grain of salt.



As drawback, if we fail to tune the ratio, memeory efficieny would be
bad so that it ends up thrashing but you guys is saying we have been
used CMA without movable fallback which means that it's already static
reserved memory and it's never CMA so you already have lost memory
efficiency and even fail to get a space so I think it's good trade-off
for embedded people.



Agreed. It really should be a policy decision how much effort to put 
into getting CMA pages. There isn't a nice way to do this now.



If anyone has interest the idea, I will move into that.
If it sounds crazy idea, feel free to ignore, please.



I'm interested in the idea with the warning noted above.

Thanks,
Laura

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 3/6] Cleanup efi_enter_virtual_mode function

2013-10-30 Thread Dave Young 
On 10/31/13 at 10:04am, Dave Young wrote:
> On 10/30/13 at 11:47am, Borislav Petkov wrote:
> > On Wed, Oct 30, 2013 at 10:03:49AM +0800, Dave Young wrote:
> > > Will try, but please keep the posted patches in mailing list up-to-date,
> > 
> > Would you like me to send them to you privately?
> 
> Thanks, do not bother to send me privately I can get it from your git tree.
> 
> But Frankly I'd like to see them in list instead even with only small fixes
> beacuse in this way there might be more people to review it carefully.

There's another shorcoming for keeping new patches in git is that nobody know
when you push it and when is the proper date to pull from your git. I think
it's better to use git only for the patches which have already been accepted
and is waiting for maintainer to pull.

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

Re: [patch 3/6] Cleanup efi_enter_virtual_mode function

2013-10-30 Thread Dave Young 
On 10/30/13 at 11:47am, Borislav Petkov wrote:
> On Wed, Oct 30, 2013 at 10:03:49AM +0800, Dave Young wrote:
> > Will try, but please keep the posted patches in mailing list up-to-date,
> 
> Would you like me to send them to you privately?

Thanks, do not bother to send me privately I can get it from your git tree.

But Frankly I'd like to see them in list instead even with only small fixes
beacuse in this way there might be more people to review it carefully.

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

[PATCH] [trivial] doc: usb: Fix typo in Documentation/usb/gadget_configs.txt

2013-10-30 Thread Masanari Iida 
Correct spelling typo in Documentation/usb/gadget_configs.txt

Signed-off-by: Masanari Iida 
---
 Documentation/usb/gadget_configfs.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/usb/gadget_configfs.txt 
b/Documentation/usb/gadget_configfs.txt
index 8ec2a67..4cf53e4 100644
--- a/Documentation/usb/gadget_configfs.txt
+++ b/Documentation/usb/gadget_configfs.txt
@@ -26,7 +26,7 @@ Linux provides a number of functions for gadgets to use.
 Creating a gadget means deciding what configurations there will be
 and which functions each configuration will provide.
 
-Configfs (please see Documentation/filesystems/configfs/*) lends itslef nicely
+Configfs (please see Documentation/filesystems/configfs/*) lends itself nicely
 for the purpose of telling the kernel about the above mentioned decision.
 This document is about how to do it.
 
@@ -99,7 +99,7 @@ directories must be created:
 $ mkdir configs/.
 
 where  can be any string which is legal in a filesystem and the
- is the configuration's number, e.g.:
+ is the configuration's number, e.g.:
 
 $ mkdir configs/c.1
 
@@ -327,7 +327,7 @@ from the buffer to the cs), but it is up to the implementer 
of the
 two functions to decide what they actually do.
 
 typedef struct configured_structure cs;
-typedef struc specific_attribute sa;
+typedef struct specific_attribute sa;
 
sa
+--+
-- 
1.8.4.1.600.g3d092bf

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] openrisc: include: asm: define empty SERIAL_PORT_DFNS in serial.h

2013-10-30 Thread Chen Gang 
For some architectures (e.g. openrisc, arc), BASE_BAUD isn't constant
And SERIAL_PORT_DFNS always use BASE_BAUND, and also all drivers use
SERIAL_PORT_DFNS to initialize static variables, statically.

So need define SERIAL_PORT_DFNS as empty to tell drivers they don't
support SERIAL_PORT_DFNS (mostly like frv and parisc did).


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

diff --git a/arch/openrisc/include/asm/serial.h 
b/arch/openrisc/include/asm/serial.h
index 270a452..254d1ad 100644
--- a/arch/openrisc/include/asm/serial.h
+++ b/arch/openrisc/include/asm/serial.h
@@ -31,6 +31,8 @@
 
 #define BASE_BAUD (cpuinfo.clock_frequency/16)
 
+#define SERIAL_PORT_DFNS
+
 #endif /* __KERNEL__ */
 
 #endif /* __ASM_OPENRISC_SERIAL_H */
-- 
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] arc: include: asm: define empty SERIAL_PORT_DFNS in serial.h

2013-10-30 Thread Chen Gang 
For some architectures (e.g. arc, openrisc), BASE_BAUD isn't constant
And SERIAL_PORT_DFNS always use BASE_BAUND, and also all drivers use
SERIAL_PORT_DFNS to initialize static variables, statically.

So need define SERIAL_PORT_DFNS as empty to tell drivers they don't
support SERIAL_PORT_DFNS (mostly like frv and parisc did), or can not
pass compiling

The related error (allmodconfig for arc with gcc-4.8.0):

CC [M]  drivers/staging/speakup/serialio.o
  drivers/staging/speakup/serialio.c:12:2: error: initializer element is not 
constant
SERIAL_PORT_DFNS
^
  drivers/staging/speakup/serialio.c:12:2: error: (near initialization for 
'rs_table[0].baud_base')
  drivers/staging/speakup/serialio.c:12:2: error: initializer element is not 
constant
  drivers/staging/speakup/serialio.c:12:2: error: (near initialization for 
'rs_table[1].baud_base')
  drivers/staging/speakup/serialio.c:12:2: error: initializer element is not 
constant
  drivers/staging/speakup/serialio.c:12:2: error: (near initialization for 
'rs_table[2].baud_base')
  drivers/staging/speakup/serialio.c:12:2: error: initializer element is not 
constant
  drivers/staging/speakup/serialio.c:12:2: error: (near initialization for 
'rs_table[3].baud_base')


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

diff --git a/arch/arc/include/asm/serial.h b/arch/arc/include/asm/serial.h
index 602b097..f18b772 100644
--- a/arch/arc/include/asm/serial.h
+++ b/arch/arc/include/asm/serial.h
@@ -32,4 +32,6 @@
 #define BASE_BAUD  (arc_get_core_freq() / 16 / 3)
 #endif
 
+#defineSERIAL_PORT_DFNS
+
 #endif /* _ASM_ARC_SERIAL_H */
-- 
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch] mm, memcg: add memory.oom_control notification for system oom

2013-10-30 Thread David Rientjes 
A subset of applications that wait on memory.oom_control don't disable
the oom killer for that memcg and simply log or cleanup after the kernel
oom killer kills a process to free memory.

We need the ability to do this for system oom conditions as well, i.e.
when the system is depleted of all memory and must kill a process.  For
convenience, this can use memcg since oom notifiers are already present.

When a userspace process waits on the root memcg's memory.oom_control, it
will wake up anytime there is a system oom condition so that it can log
the event, including what process was killed and the stack, or cleanup
after the kernel oom killer has killed something.

This is a special case of oom notifiers since it doesn't subsequently
notify all memcgs under the root memcg (all memcgs on the system).  We
don't want to trigger those oom handlers which are set aside specifically
for true memcg oom notifications that disable their own oom killers to
enforce their own oom policy, for example.

Signed-off-by: David Rientjes 
---
 Documentation/cgroups/memory.txt | 11 ++-
 include/linux/memcontrol.h   |  5 +
 mm/memcontrol.c  |  9 +
 mm/oom_kill.c|  4 
 4 files changed, 24 insertions(+), 5 deletions(-)

diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
--- a/Documentation/cgroups/memory.txt
+++ b/Documentation/cgroups/memory.txt
@@ -739,18 +739,19 @@ delivery and gets notification when OOM happens.
 
 To register a notifier, an application must:
  - create an eventfd using eventfd(2)
- - open memory.oom_control file
+ - open memory.oom_control file for reading
  - write string like " " to
cgroup.event_control
 
-The application will be notified through eventfd when OOM happens.
-OOM notification doesn't work for the root cgroup.
+The application will be notified through eventfd when OOM happens, including
+on system oom when used with the root memcg.
 
 You can disable the OOM-killer by writing "1" to memory.oom_control file, as:
 
-   #echo 1 > memory.oom_control
+   # echo 1 > memory.oom_control
 
-This operation is only allowed to the top cgroup of a sub-hierarchy.
+This operation is only allowed to the top cgroup of a sub-hierarchy and does
+not include the root memcg.
 If OOM-killer is disabled, tasks under cgroup will hang/sleep
 in memory cgroup's OOM-waitqueue when they request accountable memory.
 
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -155,6 +155,7 @@ static inline bool task_in_memcg_oom(struct task_struct *p)
 }
 
 bool mem_cgroup_oom_synchronize(bool wait);
+void mem_cgroup_root_oom_notify(void);
 
 #ifdef CONFIG_MEMCG_SWAP
 extern int do_swap_account;
@@ -397,6 +398,10 @@ static inline bool mem_cgroup_oom_synchronize(bool wait)
return false;
 }
 
+static inline void mem_cgroup_root_oom_notify(void)
+{
+}
+
 static inline void mem_cgroup_inc_page_stat(struct page *page,
enum mem_cgroup_stat_index idx)
 {
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -5641,6 +5641,15 @@ static void mem_cgroup_oom_notify(struct mem_cgroup 
*memcg)
mem_cgroup_oom_notify_cb(iter);
 }
 
+/*
+ * Notify any process waiting on the root memcg's memory.oom_control, but do 
not
+ * notify any child memcgs to avoid triggering their per-memcg oom handlers.
+ */
+void mem_cgroup_root_oom_notify(void)
+{
+   mem_cgroup_oom_notify_cb(root_mem_cgroup);
+}
+
 static int mem_cgroup_usage_register_event(struct cgroup_subsys_state *css,
struct cftype *cft, struct eventfd_ctx *eventfd, const char *args)
 {
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -632,6 +632,10 @@ void out_of_memory(struct zonelist *zonelist, gfp_t 
gfp_mask,
return;
}
 
+   /* Avoid waking up processes for oom kills triggered by sysrq */
+   if (!force_kill)
+   mem_cgroup_root_oom_notify();
+
/*
 * Check if there were limitations on the allocation (only relevant for
 * NUMA) that may require different handling.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv4 5/9] Thermal: Add trip point sysfs nodes for sensor

2013-10-30 Thread Srinivas Pandruvada 
You might want to use new DEVICE_ATTR_RO and DEVICE_ATTR_RW in this 
series. GKH wanted this changes in my powercap patchset.


Thanks,
Srinivas

On 10/15/2013 06:12 AM, R, Durgadoss wrote:

-Original Message-
From: Zhang, Rui
Sent: Tuesday, October 15, 2013 4:33 PM
To: R, Durgadoss
Cc: eduardo.valen...@ti.com; linux...@vger.kernel.org; linux-
ker...@vger.kernel.org; hongbo.zh...@freescale.com; w...@nvidia.com
Subject: Re: [PATCHv4 5/9] Thermal: Add trip point sysfs nodes for sensor

On Wed, 2013-10-02 at 00:08 +0530, Durgadoss R wrote:

This patch adds a trip point related sysfs nodes
for each sensor under a zone in /sys/class/thermal/zoneX/.
The nodes will be named, sensorX_trip_activeY,
sensorX_trip_passiveY, sensorX_trip_hot, sensorX_trip_critical
for active, passive, hot and critical trip points
respectively for sensorX.

Signed-off-by: Durgadoss R 
---
  drivers/thermal/thermal_core.c |  344

+++-

  include/linux/thermal.h|   40 -
  2 files changed, 379 insertions(+), 5 deletions(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 3c4ef62..d6e29f6 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -494,6 +494,60 @@ static void thermal_zone_device_check(struct

work_struct *work)

thermal_zone_device_update(tz);
  }

+static int get_sensor_indx_by_kobj(struct thermal_zone *tz, const char

*name)

+{
+   int i, indx = -EINVAL;
+
+   /* Protect against tz->sensors[i] being unregistered */
+   mutex_lock(_list_lock);
+
+   for (i = 0; i < tz->sensor_indx; i++) {
+   if (!strnicmp(name, kobject_name(>sensors[i]-
device.kobj),
+   THERMAL_NAME_LENGTH)) {
+   indx = i;
+   break;
+   }
+   }
+
+   mutex_unlock(_list_lock);
+   return indx;
+}
+
+static void __remove_trip_attr(struct thermal_zone *tz, int indx)
+{
+   int i;
+   struct thermal_trip_attr *attr = tz->trip_attr[indx];
+   struct thermal_trip_point *trip = tz->sensor_trip[indx];
+
+   if (!attr || !trip)
+   return;
+
+   if (trip->crit != THERMAL_TRIPS_NONE)
+   device_remove_file(>device, >crit_attr.attr);
+
+   if (trip->hot != THERMAL_TRIPS_NONE)
+   device_remove_file(>device, >hot_attr.attr);
+
+   if (trip->num_passive_trips > 0) {
+   for (i = 0; i < trip->num_passive_trips; i++) {
+   device_remove_file(>device,
+   >passive_attrs[i].attr);
+   }
+   kfree(attr->passive_attrs);
+   }
+
+   if (trip->num_active_trips > 0) {
+   for (i = 0; i < trip->num_active_trips; i++) {
+   device_remove_file(>device,
+   >active_attrs[i].attr);
+   }
+   kfree(attr->active_attrs);
+   }
+
+   kfree(tz->trip_attr[indx]);
+   tz->trip_attr[indx] = NULL;
+}
+
  static void remove_sensor_from_zone(struct thermal_zone *tz,
struct thermal_sensor *ts)
  {
@@ -503,13 +557,19 @@ static void remove_sensor_from_zone(struct

thermal_zone *tz,

if (indx < 0)
return;

-   sysfs_remove_link(>device.kobj, kobject_name(>device.kobj));
-
mutex_lock(>lock);

+   /* Remove trip point attributes associated with this sensor */
+   __remove_trip_attr(tz, indx);
+
+   sysfs_remove_link(>device.kobj, kobject_name(>device.kobj));
+
/* Shift the entries in the tz->sensors array */
-   for (j = indx; j < MAX_SENSORS_PER_ZONE - 1; j++)
+   for (j = indx; j < MAX_SENSORS_PER_ZONE - 1; j++) {
tz->sensors[j] = tz->sensors[j + 1];
+   tz->sensor_trip[j] = tz->sensor_trip[j + 1];
+   tz->trip_attr[j] = tz->trip_attr[j + 1];
+   }

tz->sensor_indx--;
mutex_unlock(>lock);
@@ -952,6 +1012,111 @@ emul_temp_store(struct device *dev, struct

device_attribute *attr,

  static DEVICE_ATTR(emul_temp, S_IWUSR, NULL, emul_temp_store);
  #endif/*CONFIG_THERMAL_EMULATION*/

+static ssize_t
+active_trip_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+   int i, j, val;
+   char kobj_name[THERMAL_NAME_LENGTH];
+   struct thermal_zone *tz = to_zone(dev);
+
+   if (!sscanf(attr->attr.name, "sensor%d_trip_active%d", , ))
+   return -EINVAL;
+
+   snprintf(kobj_name, THERMAL_NAME_LENGTH, "sensor%d", i);
+
+   mutex_lock(>lock);
+
+   i = get_sensor_indx_by_kobj(tz, kobj_name);
+   if (i < 0) {
+   mutex_unlock(>lock);
+   return i;
+   }
+
+   val = tz->sensor_trip[i]->active_trips[j];
+   mutex_unlock(>lock);
+
+   return sprintf(buf, "%d\n", val);
+}
+
+static ssize_t
+passive_trip_show(struct device *dev,

Re: [PATCH] pci-sysfs: fix a potential deadlock when concurrent remove pci device via sysfs

2013-10-30 Thread Gu Zheng 
Hi Bjorn,

On 10/31/2013 01:19 AM, Bjorn Helgaas wrote:

> On Wed, Oct 30, 2013 at 06:12:27PM +0800, Gu Zheng wrote:
>> There is a potential deadlock situation when we manipulate pci device 
>> (remove) via the pci-sysfs user interfaces simultaneously. 
>>
>> Privious patch:
>> https://lkml.org/lkml/2012/12/27/10
>>
>> Related bug reports on bugzilla:
>> https://bugzilla.kernel.org/show_bug.cgi?id=60672
>> https://bugzilla.kernel.org/show_bug.cgi?id=60695
>>
>> deadlock info described as following:
<...>
>>
>> path1: sysfs remove device: | path2: sysfs rescan device:
>> sysfs_schedule_callback_work()  | sysfs_write_file()
>>   remove_callback() |   flush_write_buffer()
>> *1* mutex_lock(_remove_rescan_mutex)|*2*  sysfs_get_active(attr_sd)
>>   ...   | dev_attr_store()
>> device_remove_file()|   dev_rescan_store()
>>   ...   |*4*  
>> mutex_lock(_remove_rescan_mutex)
>> *3*   sysfs_deactivate(sd)  | ...
>> wait_for_completion()   |*5*  sysfs_put_active(attr_sd)
>> *6* mutex_unlock(_remove_rescan_mutex)
>>
>> If path1 first holds the pci_remove_rescan_mutex at *1*, then another path
>> called path2 actived and runs to *2* before path1 runs to *3*, we now runs
>> to a deadlock situation:
>> Path1 holds the mutex waiting path2 to decrease sysfs_dirent's s_active
>> counter at *5*, but path2 is blocked at *4* when trying to get the
>> pci_remove_rescan_mutex. The mutex won't be put by path1 until it reach
>> *6*, but it's now blocked at *3*.
>>
>> So we use mutex_try_lock to avoid this deadlock, and additional 
>> wait/restart_syscall
>> steps are used to make the fail path of try_lock more friendly to user space 
>> task.
>>
>> Signed-off-by: Gu Zheng 
>> ---
>>  drivers/pci/pci-sysfs.c |   48 
>> +++---
>>  1 files changed, 40 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
>> index 7128cfd..0dac6f4 100644
>> --- a/drivers/pci/pci-sysfs.c
>> +++ b/drivers/pci/pci-sysfs.c
>> @@ -29,6 +29,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include "pci.h"
>>  
>>  static int sysfs_initialized;   /* = 0 */
>> @@ -285,6 +286,25 @@ msi_bus_store(struct device *dev, struct 
>> device_attribute *attr,
>>  }
>>  
>>  static DEFINE_MUTEX(pci_remove_rescan_mutex);
>> +
>> +static void pci_remove_rescan_lock(void)
>> +{
>> +mutex_lock(_remove_rescan_mutex);
>> +}
>> +
>> +static int pci_remove_rescan_lock_sysfs(void)
>> +{
>> +if (mutex_trylock(_remove_rescan_mutex))
>> +return 0;
>> +/* Avoid busy looping (20 ms of sleep should do). */
>> +msleep(20);
>> +return restart_syscall();
> 
> There are very few uses of restart_syscall().  I don't believe this
> situation is so unusual and special that we need to use it here.

What about queuing rescan routines into sysfs wrokqueue just like the
remove ones? I remember that your also mentioned this way in the previous
patch threads.

Regards,
Gu

> 
>> +}
>> +
>> +static void pci_remove_rescan_unlock(void)
>> +{
>> +mutex_unlock(_remove_rescan_mutex);
>> +}
>>  static ssize_t bus_rescan_store(struct bus_type *bus, const char *buf,
>>  size_t count)
>>  {
>> @@ -295,10 +315,14 @@ static ssize_t bus_rescan_store(struct bus_type *bus, 
>> const char *buf,
>>  return -EINVAL;
>>  
>>  if (val) {
>> -mutex_lock(_remove_rescan_mutex);
>> +int ret;
>> +
>> +ret = pci_remove_rescan_lock_sysfs();
>> +if (ret)
>> +return ret;
>>  while ((b = pci_find_next_bus(b)) != NULL)
>>  pci_rescan_bus(b);
>> -mutex_unlock(_remove_rescan_mutex);
>> +pci_remove_rescan_unlock();
>>  }
>>  return count;
>>  }
>> @@ -319,9 +343,13 @@ dev_rescan_store(struct device *dev, struct 
>> device_attribute *attr,
>>  return -EINVAL;
>>  
>>  if (val) {
>> -mutex_lock(_remove_rescan_mutex);
>> +int ret;
>> +
>> +ret = pci_remove_rescan_lock_sysfs();
>> +if (ret)
>> +return ret;
>>  pci_rescan_bus(pdev->bus);
>> -mutex_unlock(_remove_rescan_mutex);
>> +pci_remove_rescan_unlock();
>>  }
>>  return count;
>>  }
>> @@ -332,9 +360,9 @@ static void remove_callback(struct device *dev)
>>  {
>>  struct pci_dev *pdev = to_pci_dev(dev);
>>  
>> -mutex_lock(_remove_rescan_mutex);
>> +pci_remove_rescan_lock();
>>  pci_stop_and_remove_bus_device(pdev);
>> -mutex_unlock(_remove_rescan_mutex);
>> +pci_remove_rescan_unlock();
>>  }
>>  
>>  static ssize_t
>> @@ -370,12 +398,16 @@ dev_bus_rescan_store(struct device *dev, struct 
>> device_attribute *attr,
>>  return -EINVAL;
>>  
>>  if

Re: [RFC PATCH RESEND] fb: reorder the lock sequence to fix a potential lockdep

2013-10-30 Thread Gu Zheng 
Hi Tomi,

On 10/30/2013 07:20 PM, Tomi Valkeinen wrote:

> Hi,
> 
> On 2013-10-28 08:01, Gu Zheng wrote:
>> Following commits:
>> 50e244cc79 fb: rework locking to fix lock ordering on takeover
>> e93a9a8687 fb: Yet another band-aid for fixing lockdep mess
>> 054430e773 fbcon: fix locking harder
>>
>> reworked locking to fix related lock ordering on takeover, and introduced 
>> console_lock
>> into fbmem, but it seems that the new lock sequence(fb_info->lock ---> 
>> console_lock)
>> is against with the one in console_callback(console_lock ---> 
>> fb_info->lock), and leads to
>> a potential deadlock as following:
> 
> A quick grep shows that there are other places than fbmem.c which use
> lock_fb_info and console_lock, for example drivers/video/sh_mobile_lcdcfb.c.

Yes, thanks for your reminder, I'll fix them all in the next version.

Regards,
Gu

> 
>  Tomi
> 
> 


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

Re: [PATCH 2/2] misc: atmel_pwm: set initcall level to subsys

2013-10-30 Thread Bo Shen 

Hi Arnd,

On 10/31/2013 04:46, Arnd Bergmann wrote:

On Wednesday 30 October 2013, Johan Hovold wrote:

I really hate this type of patch, as it's papering over the real
problem.  What happens when someone else moves their driver to this
level?  Then you are back to the original problem.


Yes, it's crude, but it's currently the only way to express a preferred
probe order.


Does the same problem occur with the generic PWM subsystem?

The atmel_pwm driver apparently is the last PWM driver that has
not been converted to the generic subsystem yet. Doing that would
also let us drop the atmel-pwm-bl driver in favor of the generic
backlight.


The atmel pwm driver is on the way to generic subsystem. more 
information at:

--->8---
PWM: atmel-pwm: add PWM controller driver:
   https://patchwork.kernel.org/patch/2963081/
---<8---

Best Regards,
Bo Shen

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

Re: WTF: driver-core-next contains recursive directory removal!

2013-10-30 Thread Eric W. Biederman 
Greg Kroah-Hartman  writes:

> On Wed, Oct 30, 2013 at 03:38:58PM -0700, Eric W. Biederman wrote:
>> 
>> Greg what is  going on?  I just looked and Tejuns ill-conceived recursive
>> directory deletion code has been merged into your driver-core-next tree.
>> 
>> That code is semantically broken.  I reviewed it and I gave the reasons
>> why it was wrong.  You came up to me and mentioned at LPC that you
>> agreed with my reasons.  And yet I just looked in driver-core-next and
>> there the code is in all of it's broken glory.
>
> Because I tested it out, and there were no such problems.

The biggest and worst issue is the semantics are total unmaintable
garbage and there has never been a single counter argument to that.

Recursive delete is WRONG.

Further there was no follow up converstion on the list about this trash
to say you had tested it.  Or anything else.

Even the partial recursive delete we currently have has been responsible
for broken users of sysfs so I don't see how adding additional checks is
going to do anything but paper over real bugs in real uses of sysfs.

Will you please remove that garbage from your tree. 

Eric


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

Re: [RFC 4/9] of/irq: Refactor interrupt-map parsing

2013-10-30 Thread Ming Lei 
On Wed, Oct 30, 2013 at 12:23 AM, Olof Johansson  wrote:
> Hi,
>
> On Tue, Oct 15, 2013 at 1:39 PM, Grant Likely  wrote:
>> All the users of of_irq_parse_raw pass in a raw interrupt specifier from
>> the device tree and expect it to be returned (possibly modified) in an
>> of_phandle_args structure. However, the primary function of
>> of_irq_parse_raw() is to check for translations due to the presence of
>> one or more interrupt-map properties. The actual placing of the data
>> into an of_phandle_args structure is trivial. If it is refactored to
>> accept an of_phandle_args structure directly, then it becomes possible
>> to consume of_phandle_args from other sources. This is important for an
>> upcoming patch that allows a device to be connected to more than one
>> interrupt parent. It also simplifies the code a bit.
>>
>> The biggest complication with this patch is that the old version works
>> on the interrupt specifiers in __be32 form, but the of_phandle_args
>> structure is intended to carry it in the cpu-native version. A bit of
>> churn was required to make this work. In the end it results in tighter
>> code, so the churn is worth it.
>>
>> Signed-off-by: Grant Likely 
>> Cc: Benjamin Herrenschmidt 
>
> This patch stopped exynos/arndale from booting when it hit next (i.e.
> last night). I bisected down to this commit.

+1, :-)

>
> It seems that the platform is getting stuck calibrating delay loop,
> i.e. it is not getting interrupts. Let me know if you want me to
> collect more data of some sort.



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

[PATCH 3/4] ACPICA: Return error if DerefOf resolves to a null package element.

2013-10-30 Thread Lv Zheng 
From: Bob Moore 

commit a50abf4842dd7d603a2ad6dcc7f1467fd2a66f03 upstream.

Disallow the dereference of a reference (via index) to an uninitialized
package element. Provides compatibility with other ACPI
implementations. ACPICA BZ 1003.

 Cc:  # 3.8.x: 3f654ba: ACPICA: Interpreter: Fix
 Cc:  # 3.8.x: 63660e0: ACPICA: DeRefOf operator:
 Cc:  # 3.8.x
References: https://bugs.acpica.org/show_bug.cgi?id=431
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
Signed-off-by: Rafael J. Wysocki 
---
 drivers/acpi/acpica/exoparg1.c |   13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/acpica/exoparg1.c b/drivers/acpi/acpica/exoparg1.c
index 1fa1ad6..c9f1a21 100644
--- a/drivers/acpi/acpica/exoparg1.c
+++ b/drivers/acpi/acpica/exoparg1.c
@@ -969,10 +969,17 @@ acpi_status acpi_ex_opcode_1A_0T_1R(struct 
acpi_walk_state *walk_state)
 */
return_desc =
*(operand[0]->reference.where);
-   if (return_desc) {
-   acpi_ut_add_reference
-   (return_desc);
+   if (!return_desc) {
+   /*
+* Element is NULL, do not 
allow the dereference.
+* This provides compatibility 
with other ACPI
+* implementations.
+*/
+   return_ACPI_STATUS
+   
(AE_AML_UNINITIALIZED_ELEMENT);
}
+
+   acpi_ut_add_reference(return_desc);
break;
 
default:
-- 
1.7.10

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

[PATCH 2/4] ACPICA: DeRefOf operator: Update to fully resolve FieldUnit and BufferField refs.

2013-10-30 Thread Lv Zheng 
From: Bob Moore 

commit 63660e05ec719613b518547b40a1c501c10f0bc4 upstream.

Previously, references to these objects were resolved only to the actual
FieldUnit or BufferField object. The correct behavior is to resolve these
references to an actual value.
The problem is that DerefOf did not resolve these objects to actual
values.  An "Integer" object is simple, return the value.  But a field in
an operation region will require a read operation.  For a BufferField, the
appropriate data must be extracted from the parent buffer.

NOTE: It appears that this issues is present in Windows7 but not
Windows8.

 Cc:  # 3.8.x: 3f654ba: ACPICA: Interpreter: Fix
 Cc:  # 3.8.x
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
Signed-off-by: Rafael J. Wysocki 
---
 drivers/acpi/acpica/exoparg1.c |   35 ---
 1 file changed, 32 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/acpica/exoparg1.c b/drivers/acpi/acpica/exoparg1.c
index bbf01e9..1fa1ad6 100644
--- a/drivers/acpi/acpica/exoparg1.c
+++ b/drivers/acpi/acpica/exoparg1.c
@@ -997,11 +997,40 @@ acpi_status acpi_ex_opcode_1A_0T_1R(struct 
acpi_walk_state *walk_state)
 
acpi_namespace_node
 *)

return_desc);
-   }
+   if (!return_desc) {
+   break;
+   }
+
+   /*
+* June 2013:
+* buffer_fields/field_units require 
additional resolution
+*/
+   switch (return_desc->common.type) {
+   case ACPI_TYPE_BUFFER_FIELD:
+   case ACPI_TYPE_LOCAL_REGION_FIELD:
+   case ACPI_TYPE_LOCAL_BANK_FIELD:
+   case ACPI_TYPE_LOCAL_INDEX_FIELD:
+
+   status =
+   acpi_ex_read_data_from_field
+   (walk_state, return_desc,
+_desc);
+   if (ACPI_FAILURE(status)) {
+   goto cleanup;
+   }
 
-   /* Add another reference to the object! */
+   return_desc = temp_desc;
+   break;
 
-   acpi_ut_add_reference(return_desc);
+   default:
+
+   /* Add another reference to the 
object */
+
+   acpi_ut_add_reference
+   (return_desc);
+   break;
+   }
+   }
break;
 
default:
-- 
1.7.10

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

[PATCH 4/4] ACPICA: Fix for a Store->ArgX when ArgX contains a reference to a field.

2013-10-30 Thread Lv Zheng 
From: Bob Moore 

commit 4be4be8fee2ee99a52f94f90d03d2f287ee1db86 upstream.

This change fixes a problem where a Store operation to an ArgX object
that contained a reference to a field object did not complete the
automatic dereference and then write to the actual field object.
Instead, the object type of the field object was inadvertently changed
to match the type of the source operand. The new behavior will actually
write to the field object (buffer field or field unit), thus matching
the correct ACPI-defined behavior.

 Cc:  # 3.8.x: 3f654ba: ACPICA: Interpreter: Fix
 Cc:  # 3.8.x: 63660e0: ACPICA: DeRefOf operator:
 Cc:  # 3.8.x: a50abf4: ACPICA: Return error if
 Cc:  # 3.8.x
Signed-off-by: Bob Moore 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/exstore.c |  166 +
 1 file changed, 102 insertions(+), 64 deletions(-)

diff --git a/drivers/acpi/acpica/exstore.c b/drivers/acpi/acpica/exstore.c
index 4ff37e8..cd7079d 100644
--- a/drivers/acpi/acpica/exstore.c
+++ b/drivers/acpi/acpica/exstore.c
@@ -57,6 +57,11 @@ acpi_ex_store_object_to_index(union acpi_operand_object 
*val_desc,
  union acpi_operand_object *dest_desc,
  struct acpi_walk_state *walk_state);
 
+static acpi_status
+acpi_ex_store_direct_to_node(union acpi_operand_object *source_desc,
+struct acpi_namespace_node *node,
+struct acpi_walk_state *walk_state);
+
 
/***
  *
  * FUNCTION:acpi_ex_store
@@ -376,7 +381,11 @@ acpi_ex_store_object_to_index(union acpi_operand_object 
*source_desc,
  *  When storing into an object the data is converted to the
  *  target object type then stored in the object. This means
  *  that the target object type (for an initialized target) will
- *  not be changed by a store operation.
+ *  not be changed by a store operation. A copy_object can change
+ *  the target type, however.
+ *
+ *  The implicit_conversion flag is set to NO/FALSE only when
+ *  storing to an arg_x -- as per the rules of the ACPI spec.
  *
  *  Assumes parameters are already validated.
  *
@@ -400,7 +409,7 @@ acpi_ex_store_object_to_node(union acpi_operand_object 
*source_desc,
target_type = acpi_ns_get_type(node);
target_desc = acpi_ns_get_attached_object(node);
 
-   ACPI_DEBUG_PRINT((ACPI_DB_EXEC, "Storing %p(%s) into node %p(%s)\n",
+   ACPI_DEBUG_PRINT((ACPI_DB_EXEC, "Storing %p (%s) to node %p (%s)\n",
  source_desc,
  acpi_ut_get_object_type_name(source_desc), node,
  acpi_ut_get_type_name(target_type)));
@@ -414,46 +423,31 @@ acpi_ex_store_object_to_node(union acpi_operand_object 
*source_desc,
return_ACPI_STATUS(status);
}
 
-   /* If no implicit conversion, drop into the default case below */
-
-   if ((!implicit_conversion) ||
-   ((walk_state->opcode == AML_COPY_OP) &&
-(target_type != ACPI_TYPE_LOCAL_REGION_FIELD) &&
-(target_type != ACPI_TYPE_LOCAL_BANK_FIELD) &&
-(target_type != ACPI_TYPE_LOCAL_INDEX_FIELD))) {
-   /*
-* Force execution of default (no implicit conversion). Note:
-* copy_object does not perform an implicit conversion, as per 
the ACPI
-* spec -- except in case of region/bank/index fields -- 
because these
-* objects must retain their original type permanently.
-*/
-   target_type = ACPI_TYPE_ANY;
-   }
-
/* Do the actual store operation */
 
switch (target_type) {
-   case ACPI_TYPE_BUFFER_FIELD:
-   case ACPI_TYPE_LOCAL_REGION_FIELD:
-   case ACPI_TYPE_LOCAL_BANK_FIELD:
-   case ACPI_TYPE_LOCAL_INDEX_FIELD:
-
-   /* For fields, copy the source data to the target field. */
-
-   status = acpi_ex_write_data_to_field(source_desc, target_desc,
-_state->result_obj);
-   break;
-
case ACPI_TYPE_INTEGER:
case ACPI_TYPE_STRING:
case ACPI_TYPE_BUFFER:
 
/*
-* These target types are all of type Integer/String/Buffer, and
-* therefore support implicit conversion before the store.
-*
-* Copy and/or convert the source object to a new target object
+* The simple data types all support implicit source operand
+* conversion before the store.
 */
+
+   if ((walk_state->opcode == AML_COPY_OP) || 
!implicit_conversion) {
+   /*
+* However, copy_object and Stores

[PATCH 0/4] ACPICA: Stable material of ACPI executer fixes for linux-3.8.

2013-10-30 Thread Lv Zheng 
There are bug-fixes for AML interpreter upstreamed, fixing some serious
issues found in recent platforms.  These fixes make Linux AML interpreter
more ACPI 2.0 ASL concept compliant.  Further AML interpreter fixes should
be based on such improvements, thus they are good materials for stable.

This patch set can be safely applied to linux-3.8:
commit 19f949f52599ba7c3f67a5897ac6be14bfcb1200 upstream.

The patch set has passed build/boot tests on the following machines:
  Dell Inspiron Mini 1010 (i386)
  HP Compaq 8200 Elite SFF PC (x86-64)

Bob Moore (4):
  ACPICA: Interpreter: Fix Store() when implicit conversion is not
possible.
  ACPICA: DeRefOf operator: Update to fully resolve FieldUnit and
BufferField refs.
  ACPICA: Return error if DerefOf resolves to a null package element.
  ACPICA: Fix for a Store->ArgX when ArgX contains a reference to a
field.

 drivers/acpi/acpica/exoparg1.c |   48 +++--
 drivers/acpi/acpica/exstore.c  |  151 +++-
 2 files changed, 146 insertions(+), 53 deletions(-)

Cc: Bob Moore 
-- 
1.7.10

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

[PATCH 1/4] ACPICA: Interpreter: Fix Store() when implicit conversion is not possible.

2013-10-30 Thread Lv Zheng 
From: Bob Moore 

commit 3f654bad3257427bea7ba1c4d43a23d99a03622b upstream.

For the cases such as a store of a string to an existing package
object, implement the store as a CopyObject().
This is a small departure from the ACPI specification which states
that the control method should be aborted in this case. However,
ASLTS suite depends on this behavior.

 Cc:  # 3.8.x
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
Signed-off-by: Rafael J. Wysocki 
---
 drivers/acpi/acpica/exstore.c |   29 -
 1 file changed, 24 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/acpica/exstore.c b/drivers/acpi/acpica/exstore.c
index 90431f1..4ff37e8 100644
--- a/drivers/acpi/acpica/exstore.c
+++ b/drivers/acpi/acpica/exstore.c
@@ -487,14 +487,33 @@ acpi_ex_store_object_to_node(union acpi_operand_object 
*source_desc,
default:
 
ACPI_DEBUG_PRINT((ACPI_DB_EXEC,
- "Storing %s (%p) directly into node (%p) with 
no implicit conversion\n",
+ "Storing [%s] (%p) directly into node [%s] 
(%p)"
+ " with no implicit conversion\n",
  acpi_ut_get_object_type_name(source_desc),
- source_desc, node));
+ source_desc,
+ acpi_ut_get_object_type_name(target_desc),
+ node));
 
-   /* No conversions for all other types. Just attach the source 
object */
+   /*
+* No conversions for all other types. Directly store a copy of
+* the source object. NOTE: This is a departure from the ACPI
+* spec, which states "If conversion is impossible, abort the
+* running control method".
+*
+* This code implements "If conversion is impossible, treat the
+* Store operation as a CopyObject".
+*/
+   status =
+   acpi_ut_copy_iobject_to_iobject(source_desc, _desc,
+   walk_state);
+   if (ACPI_FAILURE(status)) {
+   return_ACPI_STATUS(status);
+   }
 
-   status = acpi_ns_attach_object(node, source_desc,
-  source_desc->common.type);
+   status =
+   acpi_ns_attach_object(node, new_desc,
+ new_desc->common.type);
+   acpi_ut_remove_reference(new_desc);
break;
}
 
-- 
1.7.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 0/3] x86, apic, kexec: Add disable_cpu_apic kernel parameter

2013-10-30 Thread jerry . hoemann 
On Wed, Oct 23, 2013 at 09:05:06AM +0900, HATAYAMA Daisuke wrote:
> >>
> >>- Rebased on top of v3.12-rc6
> >>
> >>- Basic design has been changed. Now users need to figure out initial
> >>   APIC ID of BSP in the 1st kernel and configures kernel parameter for
> >>   the 2nd kernel manually using disable_cpu_apic kernel parameter to
> >>   be newly introduced in this patch set. This design is more flexible
> >>   than the previous version in that we no longer have to rely on
> >>   ACPI/MP table to get initial APIC ID of BSP.
> >
> >
> >Do you literally mean a human at each boot will have to configure
> >the kdump configuration files for passing disable_cpu_apic?
> >Or do you envision the setting of disable_cpu_apic being put into
> >the kdump initialization scripts?
> >
> >thanks
> >
> >Jerry
> 
> Nearer to the former case, but this is not what a human should do. It's
> a cumbersome task. I think, on fedora/RHEL system for example, kdump
> service should check at each boot automatically.
> 
> HATAYAMA, Daisuke


Daisuke,

Are you planning on making changes to the kexec tools to automate
the setting of disable_cpu_apic to the capture kernel? Or do you
know someone who is planning this?

I back ported the kernel side changes to a 4.2.32 based kernel.
I tested the patch on a prototype system which exhibits a stable
initial_apic_id for CPU 0.  While not something that would be suitable
for customers, it does allow me to test the kernel portion of the patch.

I will report the results of the testing later this week.

Thanks

Jerry


-- 


Jerry HoemannSoftware Engineer  Hewlett-Packard/MODL

3404 E Harmony Rd. MS 57phone:  (970) 898-1022
Ft. Collins, CO 80528   FAX:(970) 898-
email:  jerry.hoem...@hp.com


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

Re: [PATCH] include/linux/wait.h: add ';' for the statement which missed it.

2013-10-30 Thread Chen Gang 
On 10/30/2013 11:40 PM, Peter Zijlstra wrote:
> On Wed, Oct 30, 2013 at 08:15:31AM -0700, Randy Dunlap wrote:
>> On 10/29/13 21:08, Chen Gang wrote:
>>> Add ';' for the statement, or can not pass compiling. The related error
>>> (for powerpc allmodconfig):
>>>
>>> CC  block/blk-mq.o
>>>   block/blk-mq.c: In function ‘blk_mq_queue_enter’:
>>>   block/blk-mq.c:108:8: error: expected ‘;’ before ‘__ret’
>>>   block/blk-mq.c:108:6: error: void value not ignored as it ought to be
>>>
>>>
>>> Signed-off-by: Chen Gang 
>>
>> Acked-by: Randy Dunlap 
>>
>> I have that same patch on my machine but never posted it.
> 
> tip already includes commit 92ec11809565cf6429c75204e99e0f583b5c9d7c
> from the 23th which should fix this.
> 
> 

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

Re: [PATCH-next v3] kernel/system_certificate.S: use real contents instead of macro GLOBAL()

2013-10-30 Thread Chen Gang 
On 10/30/2013 08:57 PM, David Howells wrote:
> Chen Gang  wrote:
> 
>> If a macro is only used within 2 times, and also its contents are
>> within 2 lines, recommend to expand it to shrink code line.
>>
>> For our case, the macro is not portable either: some architectures'
>> assembler may use another character to mark newline in a macro (e.g.
>> '`' for arc), which will cause issue.
>>
>> If still want to use macro and let it portable enough, it will also
>> need include additional header file (e.g "#include ",
>> although it also need be fixed).
> 
> Fine by me.
> 
> Applied.
> 
> 

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

Re: [PATCH 2/4] ARM: msm: Remove 7x00 support

2013-10-30 Thread Olof Johansson 
On Wed, Oct 30, 2013 at 4:25 PM, Daniel Walker  wrote:

> So the current users of those platforms are, what SOL ?

What users? Show me one.


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

RE: [PATCH 0/2] make all stored entries accessible.

2013-10-30 Thread Luck, Tony 
> So, do you mean efivars should fix to use the "id" in a proper way?

It would avoid the need for all these tests, and additions to the filename to 
guarantee
uniqueness.

Not sure what options efivars has to create a unique, persistent "id" for each
record.  It's a fundamental part of how ERST works (though the unique ID is just
based around a timestamp).

> I acked Madper's patch 2/2 earlier today, but when I look at your test 
> result, I'm not sure if
> it is reasonable for users to make multiple numbers visible to the file name.
>
>> -r--r--r-- 1 root root 17499 Oct 30 13:41 
>> dmesg-erst-5940651313304961029--2129078373-1383165669

after I added the "count = 0" initialization the filename gets a tiny bit less
scary:

-r--r--r-- 1 root root 17499 Oct 30 13:41 
dmesg-erst-5940651313304961029-0-1383165669

-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] raid0: Set discard_granularity to correct value after reshape.

2013-10-30 Thread NeilBrown 
On Wed, 30 Oct 2013 13:20:22 +0100 Pawel Baldysiak
 wrote:

> In case of reshape of raid0 through raid4 a value of discard_granularity
> will be set to stripe size. MD driver should re-set this value to correct
> one when migration will be finished. Otherwise array will be left with
> wrong value and discard operations will not work properly.
> 
> Signed-off-by: Pawel Baldysiak 
> Cc: Shaohua Li 
> ---
>  drivers/md/raid0.c |2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/md/raid0.c b/drivers/md/raid0.c
> index c4d420b..807ca3a 100644
> --- a/drivers/md/raid0.c
> +++ b/drivers/md/raid0.c
> @@ -266,6 +266,8 @@ static int create_strip_zones(struct mddev *mddev, struct 
> r0conf **private_conf)
>   }
>   mddev->queue->backing_dev_info.congested_fn = raid0_congested;
>   mddev->queue->backing_dev_info.congested_data = mddev;
> + mddev->queue->limits.discard_granularity =
> + queue_logical_block_size(mddev->queue);
>  
>   /*
>* now since we have the hard sector sizes, we can make sure

Thanks, but this doesn't seem like the right sort of fix.  It is to specific
to the symptom rather than trying to address the underlying problem.

Maybe something like this?  Can you review and test?

Thanks,
NeilBrown


diff --git a/drivers/md/md.c b/drivers/md/md.c
index 628cd529343f..740b6340f980 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -3620,6 +3620,7 @@ level_store(struct mddev *mddev, const char *buf, size_t 
len)
mddev->in_sync = 1;
del_timer_sync(>safemode_timer);
}
+   blk_set_stacking_limit(>queue->limits);
pers->run(mddev);
set_bit(MD_CHANGE_DEVS, >flags);
mddev_resume(mddev);


signature.asc
Description: PGP signature

Re: FW: Re: [dm-devel] [BUG 3.12.rc4] Oops: unable to handle kernel paging request during shutdown

2013-10-30 Thread Mikulas Patocka 


On Wed, 30 Oct 2013, Greg KH wrote:

> > I suggest that you implement a function kobject_put_free, that decrements 
> > the kobject reference count and waits until others stop using the kobject 
> > and the reference count drops to zero. Then, you change drivers to use 
> > kobject_put_free instead of kobject_put in their unload routine - that 
> > will fix this sort of module unload races.
> 
> The "module unload" issue is rare, thankfully, but yes, this type of
> function will be showing up in 3.13-rc1 through the btrfs tree as it
> needs that functionality, so feel free to use it to resolve this issue
> if you need it.
> 
> thanks,
> 
> greg k-h

With CONFIG_DEBUG_KOBJECT_RELEASE this issue is not rare - 
CONFIG_DEBUG_KOBJECT_RELEASE deliberately provokes it.

Nice to hear that it will be fixed. You should patch other drivers to use 
this new function in the unload routine as well.

What is the name of the function? I didn't find it in linux-btrfs.git or 
btrfs-next.git.

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

Re: Subject: [v3.8][v3.11][Regression] [SCSI] sd: Update WRITE SAME heuristics

2013-10-30 Thread H. Peter Anvin 
On 10/30/2013 12:28 PM, Joseph Salisbury wrote:
> Hi Bernd,
> 
> The bug reporter confirms that your patch fixes the bug.  Any chance
> this patch can make it into 3.12?

FWIW, I don't think reverting the WRITE SAME patch is an option -- it
causes serious filesystem failures.

-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 0/4] Exynos 5410 Dual cluster support

2013-10-30 Thread Kevin Hilman 
Hi Mauro,

Mauro Ribeiro  writes:

> Kevin,
>
> https://github.com/hardkernel/u-boot/tree/odroid-v2012.07

Yes, this is the one I'm using, but USB networking doesn't seem to work
with that.  Do you have USB networking working with that u-boot?  If so,
what changes to the config did you make?

Kevin

>
> On Thu, Oct 17, 2013 at 5:00 PM, Kevin Hilman  wrote:
>
>> Aliaksei Katovich  writes:
>>
>> > hi Kevin;
>> >
>> >> Vyacheslav Tyrtov  writes:
>> >>
>> >> > The series of patches represent support of Exynos 5410 SoC
>> >> >
>> >> > The Exynos 5410 is the first Samsung SoC based on bigLITTLE
>> architecture.
>> >> > Patches allow all 8 CPU cores (4 x A7 and 4 x A15) to run at the same
>> time
>> >> >
>> >> > Patches add new platform description, support of clock controller,
>> >> > dual cluster support and device tree for Exynos 5410
>> >> >
>> >> > Has been build on v3.12-rc5.
>> >> > Has been tested on Exynos 5410 reference board (exynos_defconfig).
>> >>
>> >> Has anyone tried this on the exynos5410 based odroid-xu yet?
>> >>
>> >> I tried booting this on my recently arrived odroid-xu, but am not
>> >> getting it to boot.
>> >
>> >   I am able to boot my odroid-xu+e to busybox with these patches
>> applied
>> >   against 3.12-rc5: exynos_defconfig and exynos5410-smdk5410.dtb were
>> >   used.
>> >
>> >   However there seem to be some issues with virq allocations, like
>> this:
>>
>> Ah, I've seen the same thing, but for me it doesn't boot reliably.
>> Sometimes there's an immediate fault like this[1], and once in a rare
>> while, it starts to boot and I see the same virq errors.
>>
>> Curious what you guys are using for boot loaders.  I found some
>> pre-build u-boot binaries along with the necessary BL1/2 binary blobs in
>> the hardkernel kernel repo: https://github.com/hardkernel/linux.git
>> branch: origin/odroidxu-3.4.y
>> path: tools/hardkernel/u-boot-pre-built
>>
>> Unfortunatly, that u-boot doesn't have usb networking support built in
>> so I couln't use u-boot to tftp the kernel, so I was able to use fasboot
>> to load the kernel/ramdisk, but it's very flaky.
>>
>> Do you have an pointers of where to get a known working bootloader.
>> Ideally, a u-boot with networking/tftp support would be ideal.
>>
>> Thanks,
>>
>> Kevin
>>
>> [1]
>> USB cable Connected![0x4]
>> Starting download of 10008576 bytes
>> .
>> downloading of 10008576 bytes finished
>> Kernel size: 00296bc5
>> Ramdisk size: 006f3c00
>> Booting kernel..
>> ## Booting kernel from Legacy Image at 40008000 ...
>>Image Name:   Linux
>>Image Type:   ARM Linux Kernel Image (uncompressed)
>>Data Size:2714501 Bytes = 2.6 MiB
>>Load Address: 40008000
>>Entry Point:  40008000
>>Verifying Checksum ... OK
>>XIP Kernel Image ... OK
>> OK
>>
>> Starting kernel ...
>>
>> undefined instruction
>> pc : [<4000800c>]  lr : []
>> sp : bfb5bbc8  ip :  fp : 1251
>> r10:   r9 :  r8 : bfb5bf30
>> r7 :   r6 :  r5 : 40008000  r4 : bfcabac0
>> r3 : bfb5bfa8  r2 : 4100 r1 : 1251  r0 : 
>> Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
>> Resetting CPU ...
>>
>> emmc resetting ...
>> resetting ...
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-samsung-soc" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[no subject]

2013-10-30 Thread Anthony, Jenise R. 

Your Mailbox have exceeded the storage limit and due for Maintenance. Please 
CLICK HERE to validate your Mailbox. Ifou 
it doesn't work, please COPY and PASTE it on your Address Url and the top of 
your webpage


This E-mail and any of its attachments may contain Prince George’s
County Government or Prince George's County 7th Judicial Circuit
Court proprietary information or Protected Health Information,
which is privileged and confidential.  This E-mail is intended
solely for the use of the individual or entity to which it is
addressed.  If you are not the intended recipient of this E-mail,
you are hereby notified that any dissemination, distribution,
copying, or action taken in relation to the contents of and
attachments to this E-mail is strictly prohibited by federal law
and may expose you to civil and/or criminal penalties. If you have
received this E-mail in error, please notify the sender immediately
and permanently delete the original and any copy of this E-mail and
any printout.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/2] mmc: arasan: Add driver for Arasan SDHCI

2013-10-30 Thread Rob Herring 
On Wed, Oct 30, 2013 at 11:38 AM, Soren Brinkmann
 wrote:
> Add a driver for Arasan's SDHCI controller core.
>
> Signed-off-by: Soren Brinkmann 

For the binding:

Acked-by: Rob Herring 

> ---
> v2:
>  - document 'interrupts' and 'interrupt-parent' properties in the driver
>bindings
>  - append '-8.9a' IP version specifier to comaptibility string
> ---
>  .../devicetree/bindings/mmc/arasan,sdhci.txt   |  27 +++
>  MAINTAINERS|   1 +
>  drivers/mmc/host/Kconfig   |  12 ++
>  drivers/mmc/host/Makefile  |   1 +
>  drivers/mmc/host/sdhci-of-arasan.c | 224 
> +
>  5 files changed, 265 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
>  create mode 100644 drivers/mmc/host/sdhci-of-arasan.c
>
> diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt 
> b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> new file mode 100644
> index ..ef4c5ac753e8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> @@ -0,0 +1,27 @@
> +Device Tree Bindings for the Arasan SDCHI Controller
> +
> +  The bindings follow the mmc[1], clock[2] and interrupt[3] bindings. Only
> +  deviations are documented here.
> +
> +  [1] Documentation/devicetree/bindings/mmc/mmc.txt
> +  [2] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +  [3] Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
> +
> +Required Properties:
> +  - compatible: Compatibility string. Must be 'arasan,sdhci-8.9a'
> +  - reg: From mmc bindings: Register location and length.
> +  - clocks: From clock bindings: Handles to clock inputs.
> +  - clock-names: From clock bindings: Tuple including "clk_xin" and "clk_ahb"
> +  - interrupts: Interrupt specifier
> +  - interrupt-parent: Phandle for the interrupt controller that services
> + interrupts for this device.
> +
> +Example:
> +   sdhci@e010 {
> +   compatible = "arasan,sdhci-8.9a";
> +   reg = <0xe010 0x1000>;
> +   clock-names = "clk_xin", "clk_ahb";
> +   clocks = < 21>, < 32>;
> +   interrupt-parent = <>;
> +   interrupts = <0 24 4>;
> +   } ;
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3438384d270c..5ede7f722025 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1357,6 +1357,7 @@ T:git git://git.xilinx.com/linux-xlnx.git
>  S: Supported
>  F: arch/arm/mach-zynq/
>  F: drivers/cpuidle/cpuidle-zynq.c
> +F: drivers/mmc/host/sdhci-of-arasan.c
>
>  ARM SMMU DRIVER
>  M: Will Deacon 
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 7fc5099e44b2..1eb090c187bb 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -104,6 +104,18 @@ config MMC_SDHCI_PLTFM
>
>   If unsure, say N.
>
> +config MMC_SDHCI_OF_ARASAN
> +   tristate "SDHCI OF support for the Arasan SDHCI controllers"
> +   depends on MMC_SDHCI_PLTFM
> +   depends on OF
> +   help
> + This selects the Arasan Secure Digital Host Controller Interface
> + (SDHCI). This hardware is found e.g. in Xilinx' Zynq SoC.
> +
> + If you have a controller with this interface, say Y or M here.
> +
> + If unsure, say N.
> +
>  config MMC_SDHCI_OF_ESDHC
> tristate "SDHCI OF support for the Freescale eSDHC controller"
> depends on MMC_SDHCI_PLTFM
> diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
> index c41d0c364509..f93617ec6548 100644
> --- a/drivers/mmc/host/Makefile
> +++ b/drivers/mmc/host/Makefile
> @@ -57,6 +57,7 @@ obj-$(CONFIG_MMC_SDHCI_CNS3XXX)   += 
> sdhci-cns3xxx.o
>  obj-$(CONFIG_MMC_SDHCI_ESDHC_IMX)  += sdhci-esdhc-imx.o
>  obj-$(CONFIG_MMC_SDHCI_DOVE)   += sdhci-dove.o
>  obj-$(CONFIG_MMC_SDHCI_TEGRA)  += sdhci-tegra.o
> +obj-$(CONFIG_MMC_SDHCI_OF_ARASAN)  += sdhci-of-arasan.o
>  obj-$(CONFIG_MMC_SDHCI_OF_ESDHC)   += sdhci-of-esdhc.o
>  obj-$(CONFIG_MMC_SDHCI_OF_HLWD)+= sdhci-of-hlwd.o
>  obj-$(CONFIG_MMC_SDHCI_BCM_KONA)   += sdhci-bcm-kona.o
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c 
> b/drivers/mmc/host/sdhci-of-arasan.c
> new file mode 100644
> index ..98464bc732f6
> --- /dev/null
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -0,0 +1,224 @@
> +/*
> + * Arasan Secure Digital Host Controller Interface.
> + * Copyright (C) 2011 - 2012 Michal Simek 
> + * Copyright (c) 2012 Wind River Systems, Inc.
> + * Copyright (C) 2013 Pengutronix e.K.
> + * Copyright (C) 2013 Xilinx Inc.
> + *
> + * Based on sdhci-of-esdhc.c
> + *
> + * Copyright (c) 2007 Freescale Semiconductor, Inc.
> + * Copyright (c) 2009 MontaVista Software, Inc.
> + *
> + * Authors: Xiaobo Xie 
> + * Anton Vorontsov 
> + *
> + * This program is free software; you can redistribute it

Re: [PATCH v3 1/2] mbcache: decoupling the locking of local from global data

2013-10-30 Thread Thavatchai Makphaibulchoke 
On 10/30/2013 08:42 AM, Theodore Ts'o wrote:
> I tried running xfstests with this patch, and it blew up on
> generic/020 test:
> 
> generic/020   [10:21:50][  105.170352] [ cut here ]
> [  105.171683] kernel BUG at 
> /usr/projects/linux/ext4/include/linux/bit_spinlock.h:76!
> [  105.173346] invalid opcode:  [#1] SMP DEBUG_PAGEALLOC
> [  105.173346] Modules linked in:
> [  105.173346] CPU: 1 PID: 8519 Comm: attr Not tainted 
> 3.12.0-rc5-8-gffbe1d7-dirty #1492
> [  105.173346] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [  105.173346] task: f5abe560 ti: f2274000 task.ti: f2274000
> [  105.173346] EIP: 0060:[] EFLAGS: 00010246 CPU: 1
> [  105.173346] EIP is at hlist_bl_unlock+0x7/0x1c
> [  105.173346] EAX: f488d360 EBX: f488d360 ECX:  EDX: f2998800
> [  105.173346] ESI: f29987f0 EDI: 6954c848 EBP: f2275cc8 ESP: f2275cb8
> [  105.173346]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> [  105.173346] CR0: 80050033 CR2: b76bcf54 CR3: 34844000 CR4: 06f0
> [  105.173346] Stack:
> [  105.173346]  c026bc78 f2275d48 6954c848 f29987f0 f2275d24 c02cd7a9 
> f2275ce4 c02e2881
> [  105.173346]  f255d8c8  f1109020 f4a67f00 f2275d54 f2275d08 
> c02cd020 6954c848
> [  105.173346]  f4a67f00 f1109000 f2b0eba8 f2ee3800 f2275d28 f4f811e8 
> f2275d38 
> [  105.173346] Call Trace:
> [  105.173346]  [] ? mb_cache_entry_find_first+0x4b/0x55
> [  105.173346]  [] ext4_xattr_block_set+0x248/0x6e7
> [  105.173346]  [] ? jbd2_journal_put_journal_head+0xe2/0xed
> [  105.173346]  [] ? ext4_xattr_find_entry+0x52/0xac
> [  105.173346]  [] ext4_xattr_set_handle+0x1c7/0x30f
> [  105.173346]  [] ext4_xattr_set+0xa5/0xe1
> [  105.173346]  [] ext4_xattr_user_set+0x46/0x5f
> [  105.173346]  [] generic_setxattr+0x4c/0x5e
> [  105.173346]  [] ? generic_listxattr+0x95/0x95
> [  105.173346]  [] __vfs_setxattr_noperm+0x56/0xb6
> [  105.173346]  [] vfs_setxattr+0x63/0x7e
> [  105.173346]  [] setxattr+0xfb/0x139
> [  105.173346]  [] ? __lock_acquire+0x540/0xca6
> [  105.173346]  [] ? lg_local_unlock+0x1b/0x34
> [  105.173346]  [] ? trace_hardirqs_off_caller+0x2e/0x98
> [  105.173346]  [] ? kmem_cache_free+0xd4/0x149
> [  105.173346]  [] ? lock_acquire+0xdd/0x107
> [  105.173346]  [] ? __sb_start_write+0xee/0x11d
> [  105.173346]  [] ? mnt_want_write+0x1e/0x3e
> [  105.173346]  [] ? trace_hardirqs_on_caller+0x12a/0x17e
> [  105.173346]  [] ? __mnt_want_write+0x4e/0x60
> [  105.173346]  [] SyS_lsetxattr+0x6a/0x9f
> [  105.173346]  [] syscall_call+0x7/0xb
> [  105.173346] Code: 00 00 00 00 5b 5d c3 55 89 e5 53 3e 8d 74 26 00 8b 58 08 
> 89 c2 8b 43 18 e8 3f c9 fb ff f0 ff 4b 0c 5b 5d c3 8b 10 80 e2 01 75 02 <0f> 
> 0b 55 89 e5 0f ba 30 00 89 e0 25 00 e0 ff ff ff 48 14 5d c3
> [  105.173346] EIP: [] hlist_bl_unlock+0x7/0x1c SS:ESP 0068:f2275cb8
> [  105.273781] ---[ end trace 1ee45ddfc1df0935 ]---
> 
> When I tried to find a potential problem, I immediately ran into this.
> I'm not entirely sure it's the problem, but it's raised a number of
> red flags for me in terms of (a) how much testing you've employed with
> this patch set, and (b) how maintaining and easy-to-audit the code
> will be with this extra locking.  The comments are good start, but
> some additional comments about exactly what assumptions a function
> assumes about locks that are held on function entry, or especially if
> the locking is different on function entry and function exit, might
> make it easier for people to audit this patch.
> 
> Or maybe this commit needs to be split up with first a conversion from
> using list_head to hlist_hl_node, and the changing the locking?  The
> bottom line is that we need to somehow make this patch easier to
> validate/review.
> 

Thanks for the comemnts.  Yes, I did run through xfstests.  My guess is that 
you probably ran into a race condition that I did not.

I will try to port the patch to a more recent kernel, including the 
mb_cache_shrink_scan() sent earlier (BTW, it looks good) and debug the problem.

Yes, those are good suggestions.  Once I find the problem, I will resubmit with 
more comments and also split it into two patches, as suggested. 

>> @@ -520,18 +647,23 @@ __mb_cache_entry_find(struct list_head *l, struct 
>> list_head *head,
>>  ce->e_queued++;
>>  prepare_to_wait(_cache_queue, ,
>>  TASK_UNINTERRUPTIBLE);
>> -spin_unlock(_cache_spinlock);
>> +hlist_bl_unlock(head);
>>  schedule();
>> -spin_lock(_cache_spinlock);
>> +hlist_bl_lock(head);
>> +mb_assert(ce->e_index_hash_p == head);
>>  ce->e_queued--;
>>  }
>> +hlist_bl_unlock(head);
>>  finish_wait(_cache_queue, );
>>  
>> -if

Re: [PATCH] Fix build without CONFIG_INPUT_LEDS [Was: mmotm 2013-10-29-16-22 uploaded (input)]

2013-10-30 Thread Stephen Rothwell 
Hi Andrew,

On Wed, 30 Oct 2013 16:23:34 -0700 Andrew Morton  
wrote:
> 
> It needs this as well.
> 
> From: Andrew Morton 
> Subject: input-route-kbd-leds-through-the-generic-leds-layer-fix-fix
> 
> use IS_ENABLED to pick up CONFIG_INPUT_LEDS=m
> 
> Cc: Dmitry Torokhov 
> Cc: John Crispin 
> Cc: Ralf Baechle 
> Cc: Samuel Thibault 
> Signed-off-by: Andrew Morton 
> ---
> 
>  include/linux/input.h |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff -puN 
> include/linux/input.h~input-route-kbd-leds-through-the-generic-leds-layer-fix-fix
>  include/linux/input.h
> --- 
> a/include/linux/input.h~input-route-kbd-leds-through-the-generic-leds-layer-fix-fix
> +++ a/include/linux/input.h
> @@ -533,7 +533,7 @@ int input_ff_erase(struct input_dev *dev
>  int input_ff_create_memless(struct input_dev *dev, void *data,
>   int (*play_effect)(struct input_dev *, void *, struct ff_effect 
> *));
>  
> -#ifdef CONFIG_INPUT_LEDS
> +#if IS_ENABLED(CONFIG_INPUT_LEDS)
>  
>  int input_led_connect(struct input_dev *dev);
>  void input_led_disconnect(struct input_dev *dev);

Added.

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


pgpG2F4Kslawz.pgp
Description: PGP signature

RE: [PATCH 0/2] make all stored entries accessible.

2013-10-30 Thread Seiji Aguchi 
> Ah - I was expecting that the backend driver would have a unique "id" for
> each record stored ... but is seems that this isn't true for efivars.
> 

So, do you mean efivars should fix to use the "id" in a proper way?

I acked Madper's patch 2/2 earlier today, but when I look at your test result, 
I'm not sure if
it is reasonable for users to make multiple numbers visible to the file name.

> -r--r--r-- 1 root root 17499 Oct 30 13:41 
> dmesg-erst-5940651313304961029--2129078373-1383165669

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

Re: [PATCH 2/4] ARM: msm: Remove 7x00 support

2013-10-30 Thread Daniel Walker 
On Wed, Oct 30, 2013 at 04:08:27PM -0700, Kevin Hilman wrote:
> Olof Johansson  writes:
> 
> > I would be very happy to take more code for the older Qualcomm chipset
> > to enable full functionality for them, but it's been my impression
> > that far from all that is needed to make it a useful platform is in
> > the upstream kernel, and there's been no signs of more of it showing
> > up at least in the last two years.
> >
> > So we have a bit of a stalemate here -- the current Qualcomm team
> > wants to avoid having to deal too much with the legacy platforms --
> > they are technically quite different from the current platforms and
> > the divergence makes it hard to deal with supporting it all in a
> > modern way without risking regressions. I tend to agree with them.
> 
> As do I.
> 
> > Just like omap split between omap1 and omap2plus, I think it's a time
> > to create a mach-qcom instead, and move the modern (v7, most likely)
> > platforms there -- enable them with device tree, modern framework
> > infrastructure, etc. That way you can keep older platforms in mach-msm
> > without risk of regressions, and they have a clean base to start on
> > with their later platforms.
> 
> I think this split approach is a good compromise.
> 
> If the maintainers of the current older platforms wish to bring them up
> to modern frameworks, we can consider combining again.  If not, they the
> older platforms will take the same path as the rest of the older
> platforms that slowly fade away.
> 

So the current users of those platforms are, what SOL ?

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

Re: [PATCH RFC] kvm: optimize out smp_mb using srcu_read_unlock

2013-10-30 Thread Michael S. Tsirkin 
> > Paul, could you review this patch please?
> > Documentation/memory-barriers.txt says that unlock has a weaker
> > uni-directional barrier, but in practice srcu_read_unlock calls
> > smp_mb().
> > 
> > Is it OK to rely on this? If not, can I add
> > smp_mb__after_srcu_read_unlock (making it an empty macro for now)
> > so we can avoid an actual extra smp_mb()?
> 
> Please use smp_mb__after_srcu_read_unlock().  After all, it was not
> that long ago that srcu_read_unlock() contained no memory barriers,
> and perhaps some day it won't need to once again.
> 
>   Thanx, Paul
>

Thanks!
Something like this will be enough?
 
diff --git a/include/linux/srcu.h b/include/linux/srcu.h
index c114614..9b058ee 100644
--- a/include/linux/srcu.h
+++ b/include/linux/srcu.h
@@ -237,4 +237,18 @@ static inline void srcu_read_unlock(struct srcu_struct 
*sp, int idx)
__srcu_read_unlock(sp, idx);
 }
 
+/**
+ * smp_mb__after_srcu_read_unlock - ensure full ordering after srcu_read_unlock
+ *
+ * Converts the preceding srcu_read_unlock into a two-way memory barrier.
+ *
+ * Call this after srcu_read_unlock, to guarantee that all memory operations
+ * that occur after smp_mb__after_srcu_read_unlock will appear to happen after
+ * the preceding srcu_read_unlock.
+ */
+static inline void smp_mb__after_srcu_read_unlock(void)
+{
+   /* __srcu_read_unlock has smp_mb() internally so nothing to do here. */
+}
+
 #endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] Fix build without CONFIG_INPUT_LEDS [Was: mmotm 2013-10-29-16-22 uploaded (input)]

2013-10-30 Thread Andrew Morton 
On Thu, 31 Oct 2013 10:20:12 +1100 Stephen Rothwell  
wrote:

> Hi all,
> 
> On Wed, 30 Oct 2013 12:46:24 +0100 Samuel Thibault 
>  wrote:
> >
> > Randy Dunlap, le Tue 29 Oct 2013 18:57:36 -0700, a __crit :
> > > arc_ps2.c:(.text+0x500): multiple definition of `input_led_connect'
> > 
> > D'oh.  I indeed hadn't tested the inlines, sorry about this.
> > 
> > Andrew, could you add the following patch on top of
> > input-route-kbd-leds-through-the-generic-leds-layer.patch
> > or perhaps rather fold into it?
> > 
> > Samuel
> > 
> > 
> > 
> > Really mark inlines as static inlines, so they are not defined multiple
> > times.
> > 
> > Signed-off-by: Samuel Thibault 
> 
> I have added that as a fix patch for the akpm-current tree for today.

It needs this as well.

From: Andrew Morton 
Subject: input-route-kbd-leds-through-the-generic-leds-layer-fix-fix

use IS_ENABLED to pick up CONFIG_INPUT_LEDS=m

Cc: Dmitry Torokhov 
Cc: John Crispin 
Cc: Ralf Baechle 
Cc: Samuel Thibault 
Signed-off-by: Andrew Morton 
---

 include/linux/input.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -puN 
include/linux/input.h~input-route-kbd-leds-through-the-generic-leds-layer-fix-fix
 include/linux/input.h
--- 
a/include/linux/input.h~input-route-kbd-leds-through-the-generic-leds-layer-fix-fix
+++ a/include/linux/input.h
@@ -533,7 +533,7 @@ int input_ff_erase(struct input_dev *dev
 int input_ff_create_memless(struct input_dev *dev, void *data,
int (*play_effect)(struct input_dev *, void *, struct ff_effect 
*));
 
-#ifdef CONFIG_INPUT_LEDS
+#if IS_ENABLED(CONFIG_INPUT_LEDS)
 
 int input_led_connect(struct input_dev *dev);
 void input_led_disconnect(struct input_dev *dev);
_

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

Re: perf: PERF_EVENT_IOC_PERIOD on ARM vs everywhere else

2013-10-30 Thread Will Deacon 
On Wed, Oct 30, 2013 at 02:13:11PM +, Vince Weaver wrote:
> On Wed, 30 Oct 2013, Peter Zijlstra wrote:
> > The below code should deal with both cases I think -- completely
> > untested.
> 
> Uncompiled too I guess?
> 
> kernel/events/core.c: In function ‘perf_event_period’:
> kernel/events/core.c:3531: error: invalid type argument of ‘->’ (have 
> ‘local64_t’)
> make[3]: *** [kernel/events/core.o] Error 1

That's trivial to fix.

> I also won't be able to test the ARM change, as my pandaboard won't boot 
> with recent kernels (can't find the MMC root filesystem) and I haven't had 
> time to track down why.  Also even on a simple period changing test it 
> often fails due to lost interrupts (the Cortex-A9 lost interrupt errata?).

The omap guys like trying to blame the A9 erratum for that (which doesn't
even affect the cycle counter), but the reality is that the CTI never
worked reliably with mainline, and now there are no developers working
on that after the TI layoffs. I don't see the state of Pandaboard support
improving over time.

If you have a canned testcase for this stuff, I'm happy to run it on my
Chromebook.

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] Fix build without CONFIG_INPUT_LEDS [Was: mmotm 2013-10-29-16-22 uploaded (input)]

2013-10-30 Thread Stephen Rothwell 
Hi all,

On Wed, 30 Oct 2013 12:46:24 +0100 Samuel Thibault 
 wrote:
>
> Randy Dunlap, le Tue 29 Oct 2013 18:57:36 -0700, a écrit :
> > arc_ps2.c:(.text+0x500): multiple definition of `input_led_connect'
> 
> D'oh.  I indeed hadn't tested the inlines, sorry about this.
> 
> Andrew, could you add the following patch on top of
> input-route-kbd-leds-through-the-generic-leds-layer.patch
> or perhaps rather fold into it?
> 
> Samuel
> 
> 
> 
> Really mark inlines as static inlines, so they are not defined multiple
> times.
> 
> Signed-off-by: Samuel Thibault 

I have added that as a fix patch for the akpm-current tree for today.

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


pgpBOR_gUoIGA.pgp
Description: PGP signature

Re: [RFC PATCH -next] Fix printk_once build errors due to __read_mostly

2013-10-30 Thread Stephen Rothwell 
Hi Andrew,

On Wed, 30 Oct 2013 13:48:39 -0700 Andrew Morton  
wrote:
>
> I can't immediately think of a nice solution so I guess for now I'll
> drop printk-mark-printk_once-test-variable-__read_mostly.patch.

I have removed that from my copy of the mmotm tree.

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


pgpA7vU510d99.pgp
Description: PGP signature

Re: linux-next build failure

2013-10-30 Thread Stephen Rothwell 
Hi Andrew,

On Wed, 30 Oct 2013 13:50:42 -0700 Andrew Morton  
wrote:
>
> On Thu, 31 Oct 2013 07:37:00 +1100 Stephen Rothwell  
> wrote:
> 
> > [Jut add Andrew to the cc list]
> > 
> > On Wed, 30 Oct 2013 11:27:45 -0400 Mark Salter  wrote:
> > >
> > > This patch causes a build failure for no-MMU builds:
> > > 
> > >   commit 41df2957cb010edfa2f9d394d3617da6beeeb660
> > >   Author: Colin Cross 
> > >   Date:   Wed Oct 30 11:45:39 2013 +1100
> > > 
> > >   mm: add a field to store names for private anonymous memory
> > > 
> > > The problem is:
> > > 
> > >   kernel/built-in.o: In function `sys_prctl':
> > >   (.text+0x19854): undefined reference to `madvise_set_anon_name'
> > > 
> > > madvise doesn't make sense without an MMU.
> > > 
> > > --Mark
> 
> OK, thanks.  I'll drop
> 
> mm-rearrange-madvise-code-to-allow-for-reuse.patch
> mm-add-a-field-to-store-names-for-private-anonymous-memory.patch
> mm-add-a-field-to-store-names-for-private-anonymous-memory-fix.patch
> mm-add-a-field-to-store-names-for-private-anonymous-memory-fix-fix-2.patch
> 
> for now.  They have other question marks - let's revisit everything
> after 3.13-rc1.

I have removed them from my copy of the mmotm tree ...

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


pgp7MNzfkMGO_.pgp
Description: PGP signature

[PATCH 5/5] drm:drm_stub: rewrite error handle code for drm_fill_in_dev

2013-10-30 Thread Wang YanQing 
Rewrite error handle code in a more rational and
normal way, it bring us benefit that we could drop
call to drm_lastclose which do "too much" cleanup work
for drm_fill_in_dev.

Signed-off-by: Wang YanQing 
---
 drivers/gpu/drm/drm_stub.c | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 3f3b167..6c5f65f 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -316,7 +316,7 @@ int drm_fill_in_dev(struct drm_device *dev,
if (dev->driver->bus->agp_init) {
retcode = dev->driver->bus->agp_init(dev);
if (retcode)
-   goto error_out_unreg;
+   goto err_g1;
}
 
 
@@ -324,7 +324,7 @@ int drm_fill_in_dev(struct drm_device *dev,
retcode = drm_ctxbitmap_init(dev);
if (retcode) {
DRM_ERROR("Cannot allocate memory for context bitmap.\n");
-   goto error_out_unreg;
+   goto err_g2;
}
 
if (driver->driver_features & DRIVER_GEM) {
@@ -332,14 +332,30 @@ int drm_fill_in_dev(struct drm_device *dev,
if (retcode) {
DRM_ERROR("Cannot initialize graphics execution "
  "manager (GEM)\n");
-   goto error_out_unreg;
+   goto err_g3;
}
}
 
return 0;
 
-  error_out_unreg:
-   drm_lastclose(dev);
+err_g3:
+   drm_ctxbitmap_cleanup(dev);
+err_g2:
+   if (drm_core_has_MTRR(dev) && drm_core_has_AGP(dev) &&
+   dev->agp && dev->agp->agp_mtrr >= 0) {
+   int retval;
+   retval = mtrr_del(dev->agp->agp_mtrr,
+   dev->agp->agp_info.aper_base,
+   dev->agp->agp_info.aper_size * 1024 * 1024);
+   DRM_DEBUG("mtrr_del=%d\n", retval);
+   }
+
+   if (drm_core_has_AGP(dev) && dev->agp) {
+   kfree(dev->agp);
+   dev->agp = NULL;
+   }
+err_g1:
+   drm_ht_remove(>map_hash);
return retcode;
 }
 EXPORT_SYMBOL(drm_fill_in_dev);
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/5] drm:drm_usb: fix resource leak in drm_get_usb_dev

2013-10-30 Thread Wang YanQing 
We should call drm_cleanup_in_dev in error handle
code path after drm_fill_in_dev had been called,
or it will cause resource leak heavily, vmalloc
leak etc.

This patch also add call to dev->unload in error
handle code path.

Signed-off-by: Wang YanQing 
---
 drivers/gpu/drm/drm_usb.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_usb.c b/drivers/gpu/drm/drm_usb.c
index 34a156f..7e4de60 100644
--- a/drivers/gpu/drm/drm_usb.c
+++ b/drivers/gpu/drm/drm_usb.c
@@ -31,23 +31,23 @@ int drm_get_usb_dev(struct usb_interface *interface,
usb_set_intfdata(interface, dev);
ret = drm_get_minor(dev, >control, DRM_MINOR_CONTROL);
if (ret)
-   goto err_g1;
+   goto err_g2;
 
ret = drm_get_minor(dev, >primary, DRM_MINOR_LEGACY);
if (ret)
-   goto err_g2;
+   goto err_g3;
 
if (dev->driver->load) {
ret = dev->driver->load(dev, 0);
if (ret)
-   goto err_g3;
+   goto err_g4;
}
 
/* setup the grouping for the legacy output */
ret = drm_mode_group_init_legacy_group(dev,
   >primary->mode_group);
if (ret)
-   goto err_g3;
+   goto err_g5;
 
list_add_tail(>driver_item, >device_list);
 
@@ -58,11 +58,15 @@ int drm_get_usb_dev(struct usb_interface *interface,
 driver->date, dev->primary->index);
 
return 0;
-
-err_g3:
+err_g5:
+   if (dev->driver->unload)
+   dev->driver->unload(dev);
+err_g4:
drm_put_minor(>primary);
-err_g2:
+err_g3:
drm_put_minor(>control);
+err_g2:
+   drm_cleanup_in_dev(dev);
 err_g1:
kfree(dev);
mutex_unlock(_global_mutex);
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/5] drm:drm_platform: fix resource leak in drm_get_platform_dev

2013-10-30 Thread Wang YanQing 
We should call drm_cleanup_in_dev in error handle
code path after drm_fill_in_dev had been called,
or it will cause resource leak heavily, vmalloc
leak etc.

This patch also add call to dev->unload in error
handle code path.

Signed-off-by: Wang YanQing 
---
 drivers/gpu/drm/drm_platform.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
index b8a282e..1198fa4 100644
--- a/drivers/gpu/drm/drm_platform.c
+++ b/drivers/gpu/drm/drm_platform.c
@@ -66,17 +66,17 @@ int drm_get_platform_dev(struct platform_device *platdev,
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
ret = drm_get_minor(dev, >control, DRM_MINOR_CONTROL);
if (ret)
-   goto err_g1;
+   goto err_g2;
}
 
ret = drm_get_minor(dev, >primary, DRM_MINOR_LEGACY);
if (ret)
-   goto err_g2;
+   goto err_g3;
 
if (dev->driver->load) {
ret = dev->driver->load(dev, 0);
if (ret)
-   goto err_g3;
+   goto err_g4;
}
 
/* setup the grouping for the legacy output */
@@ -84,7 +84,7 @@ int drm_get_platform_dev(struct platform_device *platdev,
ret = drm_mode_group_init_legacy_group(dev,
>primary->mode_group);
if (ret)
-   goto err_g3;
+   goto err_g5;
}
 
list_add_tail(>driver_item, >device_list);
@@ -96,12 +96,16 @@ int drm_get_platform_dev(struct platform_device *platdev,
 driver->date, dev->primary->index);
 
return 0;
-
-err_g3:
+err_g5:
+   if (dev->driver->unload)
+   dev->driver->unload(dev);
+err_g4:
drm_put_minor(>primary);
-err_g2:
+err_g3:
if (drm_core_check_feature(dev, DRIVER_MODESET))
drm_put_minor(>control);
+err_g2:
+   drm_cleanup_in_dev(dev);
 err_g1:
kfree(dev);
mutex_unlock(_global_mutex);
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] kernel/kallsyms.c: only show legal kernel symbol

2013-10-30 Thread Russell King - ARM Linux 
On Mon, Oct 28, 2013 at 04:20:19PM +1030, Rusty Russell wrote:
> Ming Lei  writes:
> > On Mon, 28 Oct 2013 13:44:30 +1030
> > Rusty Russell  wrote:
> >
> >> Ming Lei  writes:
> >> 
> >> I don't know...  It would be your job, as the person making the change,
> >> to find all the users of kallsyms and prove that.
> >> 
> >> This is why it is easier not to include incorrect values in the kernel's
> >> kallsyms in the first place.
> >
> > OK, thanks for your comment, and I figured out one way to do it in
> > scripts/kallsyms.c, could you comment on below patch?
> 
> Looks great! Seems like we spent more time arguing than it took you to
> code that up.
> 
> Acked-by: Rusty Russell 
> 
> Russell, this seems logical for you to take along with the changes which
> caused the problem?

The changes are already in mainline since a long time (back in July/August
time).  Am I the right person to take stuff for scripts/ ?  Isn't that
more kbuild territory?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/5] drm:drm_pci: fix resource leak in drm_get_pci_dev

2013-10-30 Thread Wang YanQing 
We should call drm_cleanup_in_dev in error handle
code path after drm_fill_in_dev had been called,
or it will cause resource leak heavily, vmalloc
leak etc.

This patch also add call to dev->unload in error
handle code path.

Signed-off-by: Wang YanQing 
---
 drivers/gpu/drm/drm_pci.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 14194b6..5f15805 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -345,16 +345,16 @@ int drm_get_pci_dev(struct pci_dev *pdev, const struct 
pci_device_id *ent,
pci_set_drvdata(pdev, dev);
ret = drm_get_minor(dev, >control, DRM_MINOR_CONTROL);
if (ret)
-   goto err_g2;
+   goto err_g3;
}
 
if ((ret = drm_get_minor(dev, >primary, DRM_MINOR_LEGACY)))
-   goto err_g3;
+   goto err_g4;
 
if (dev->driver->load) {
ret = dev->driver->load(dev, ent->driver_data);
if (ret)
-   goto err_g4;
+   goto err_g5;
}
 
/* setup the grouping for the legacy output */
@@ -362,7 +362,7 @@ int drm_get_pci_dev(struct pci_dev *pdev, const struct 
pci_device_id *ent,
ret = drm_mode_group_init_legacy_group(dev,
>primary->mode_group);
if (ret)
-   goto err_g4;
+   goto err_g6;
}
 
list_add_tail(>driver_item, >device_list);
@@ -373,12 +373,16 @@ int drm_get_pci_dev(struct pci_dev *pdev, const struct 
pci_device_id *ent,
 
mutex_unlock(_global_mutex);
return 0;
-
-err_g4:
+err_g6:
+   if (dev->driver->unload)
+   dev->driver->unload(dev);
+err_g5:
drm_put_minor(>primary);
-err_g3:
+err_g4:
if (drm_core_check_feature(dev, DRIVER_MODESET))
drm_put_minor(>control);
+err_g3:
+   drm_cleanup_in_dev(dev);
 err_g2:
pci_disable_device(pdev);
 err_g1:
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/4] ARM: msm: Remove 7x00 support

2013-10-30 Thread Kevin Hilman 
Olof Johansson  writes:

> I would be very happy to take more code for the older Qualcomm chipset
> to enable full functionality for them, but it's been my impression
> that far from all that is needed to make it a useful platform is in
> the upstream kernel, and there's been no signs of more of it showing
> up at least in the last two years.
>
> So we have a bit of a stalemate here -- the current Qualcomm team
> wants to avoid having to deal too much with the legacy platforms --
> they are technically quite different from the current platforms and
> the divergence makes it hard to deal with supporting it all in a
> modern way without risking regressions. I tend to agree with them.

As do I.

> Just like omap split between omap1 and omap2plus, I think it's a time
> to create a mach-qcom instead, and move the modern (v7, most likely)
> platforms there -- enable them with device tree, modern framework
> infrastructure, etc. That way you can keep older platforms in mach-msm
> without risk of regressions, and they have a clean base to start on
> with their later platforms.

I think this split approach is a good compromise.

If the maintainers of the current older platforms wish to bring them up
to modern frameworks, we can consider combining again.  If not, they the
older platforms will take the same path as the rest of the older
platforms that slowly fade away.

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

[PATCH 1/5] drm:drm_stub: add new function drm_cleanup_in_dev

2013-10-30 Thread Wang YanQing 
Introduce a new function, drm_cleanup_in_dev,
we could use it to release resources allocated
by drm_fill_in_dev in the error handle code path
after drm_fill_in_dev have been called.

Signed-off-by: Wang YanQing 
---
 drivers/gpu/drm/drm_stub.c | 62 --
 include/drm/drmP.h |  1 +
 2 files changed, 33 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 16f3ec5..3f3b167 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -250,6 +250,37 @@ int drm_dropmaster_ioctl(struct drm_device *dev, void 
*data,
return 0;
 }
 
+void drm_cleanup_in_dev(struct drm_device *dev)
+{
+   struct drm_driver *driver;
+   struct drm_map_list *r_list, *list_temp;
+
+   driver = dev->driver;
+   if (drm_core_has_MTRR(dev) && drm_core_has_AGP(dev) &&
+   dev->agp && dev->agp->agp_mtrr >= 0) {
+   int retval;
+   retval = mtrr_del(dev->agp->agp_mtrr,
+   dev->agp->agp_info.aper_base,
+   dev->agp->agp_info.aper_size * 1024 * 1024);
+   DRM_DEBUG("mtrr_del=%d\n", retval);
+   }
+
+   if (drm_core_has_AGP(dev) && dev->agp) {
+   kfree(dev->agp);
+   dev->agp = NULL;
+   }
+
+   list_for_each_entry_safe(r_list, list_temp, >maplist, head)
+   drm_rmmap(dev, r_list->map);
+   drm_ht_remove(>map_hash);
+
+   drm_ctxbitmap_cleanup(dev);
+
+   if (dev->driver->driver_features & DRIVER_GEM)
+   drm_gem_destroy(dev);
+}
+EXPORT_SYMBOL(drm_cleanup_in_dev);
+
 int drm_fill_in_dev(struct drm_device *dev,
   const struct pci_device_id *ent,
   struct drm_driver *driver)
@@ -438,52 +469,23 @@ static void drm_unplug_minor(struct drm_minor *minor)
  */
 void drm_put_dev(struct drm_device *dev)
 {
-   struct drm_driver *driver;
-   struct drm_map_list *r_list, *list_temp;
-
DRM_DEBUG("\n");
-
if (!dev) {
DRM_ERROR("cleanup called no dev\n");
return;
}
-   driver = dev->driver;
 
drm_lastclose(dev);
 
-   if (drm_core_has_MTRR(dev) && drm_core_has_AGP(dev) &&
-   dev->agp && dev->agp->agp_mtrr >= 0) {
-   int retval;
-   retval = mtrr_del(dev->agp->agp_mtrr,
- dev->agp->agp_info.aper_base,
- dev->agp->agp_info.aper_size * 1024 * 1024);
-   DRM_DEBUG("mtrr_del=%d\n", retval);
-   }
-
if (dev->driver->unload)
dev->driver->unload(dev);
 
-   if (drm_core_has_AGP(dev) && dev->agp) {
-   kfree(dev->agp);
-   dev->agp = NULL;
-   }
-
drm_vblank_cleanup(dev);
-
-   list_for_each_entry_safe(r_list, list_temp, >maplist, head)
-   drm_rmmap(dev, r_list->map);
-   drm_ht_remove(>map_hash);
-
-   drm_ctxbitmap_cleanup(dev);
+   drm_cleanup_in_dev(dev);
 
if (drm_core_check_feature(dev, DRIVER_MODESET))
drm_put_minor(>control);
-
-   if (driver->driver_features & DRIVER_GEM)
-   drm_gem_destroy(dev);
-
drm_put_minor(>primary);
-
list_del(>driver_item);
kfree(dev->devname);
kfree(dev);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 63d17ee..2dcf83a 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1761,6 +1761,7 @@ static __inline__ void drm_core_dropmap(struct 
drm_local_map *map)
 
 #include 
 
+extern void drm_cleanup_in_dev(struct drm_device *dev);
 extern int drm_fill_in_dev(struct drm_device *dev,
   const struct pci_device_id *ent,
   struct drm_driver *driver);
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/5] drm: fix resources leak in error handle code path

2013-10-30 Thread Wang YanQing 
This series patches fix resource leak
issue in error handle code path I meet
with drm, vmalloc leak, etc.

I meet below issue caused by drm haven't release 
resource(include 40K vmalloc per module insert failed) 
in error code path and buggy nvidia driver try to insert 
nvidia module cycled when it failed to probe device which
had been controlled by nouveau built-in kernel, then
drm leak all the vmalloc space finally:

[ 2075.508077] vmap allocation for size 9637888 failed: use vmalloc= to 
increase size.
[ 2075.508083] vmalloc: allocation failure: 9633737 bytes
[ 2075.508085] modprobe: page allocation failure: order:0, mode:0xd2
[ 2075.508089] CPU: 0 PID: 3 Comm: modprobe Tainted: P   O 3.10.16+ 
#13
[ 2075.508091] Hardware name: AcerAspire 4741
/Aspire 4741, BIOS V1.04   03/02/2010
[ 2075.508093]  c17295c4 f5283eac c15df443 f5283edc c10b3311 c1727ec4 f2c15ac0 

[ 2075.508097]  00d2 c17295c4 f5283ecc f5283ef0 00d2 0092ffc9  
f5283f0c
[ 2075.508101]  c10d86e7 00d2  c17295c4 0092ffc9 c1077408 f56979c0 
f5283f28
[ 2075.508106] Call Trace:
[ 2075.508113]  [] dump_stack+0x16/0x1b
[ 2075.508118]  [] warn_alloc_failed+0xa1/0x100
[ 2075.508123]  [] __vmalloc_node_range+0x177/0x1e0
[ 2075.508128]  [] ? SyS_init_module+0x78/0xc0
[ 2075.508131]  [] __vmalloc_node+0x60/0x70
[ 2075.508134]  [] ? SyS_init_module+0x78/0xc0
[ 2075.508137]  [] vmalloc+0x38/0x40
[ 2075.508140]  [] ? SyS_init_module+0x78/0xc0
[ 2075.508142]  [] SyS_init_module+0x78/0xc0
[ 2075.508147]  [] sysenter_do_call+0x12/0x26
[ 2075.508149] Mem-Info:
[ 2075.508151] DMA per-cpu:
[ 2075.508153] CPU0: hi:0, btch:   1 usd:   0
[ 2075.508154] CPU1: hi:0, btch:   1 usd:   0
[ 2075.508156] CPU2: hi:0, btch:   1 usd:   0
[ 2075.508157] CPU3: hi:0, btch:   1 usd:   0
[ 2075.508158] Normal per-cpu:
[ 2075.508160] CPU0: hi:  186, btch:  31 usd: 125
[ 2075.508162] CPU1: hi:  186, btch:  31 usd: 138
[ 2075.508163] CPU2: hi:  186, btch:  31 usd: 155
[ 2075.508165] CPU3: hi:  186, btch:  31 usd: 144
[ 2075.508166] HighMem per-cpu:
[ 2075.508167] CPU0: hi:  186, btch:  31 usd: 132
[ 2075.508169] CPU1: hi:  186, btch:  31 usd: 170
[ 2075.508171] CPU2: hi:  186, btch:  31 usd: 155
[ 2075.508172] CPU3: hi:  186, btch:  31 usd: 153
[ 2075.508177] active_anon:2889 inactive_anon:27 isolated_anon:0
[ 2075.508177]  active_file:66897 inactive_file:117009 isolated_file:0
[ 2075.508177]  unevictable:0 dirty:47 writeback:0 unstable:0
[ 2075.508177]  free:292466 slab_reclaimable:4051 slab_unreclaimable:2244
[ 2075.508177]  mapped:2241 shmem:206 pagetables:189 bounce:0
[ 2075.508177]  free_cma:0
[ 2075.508185] DMA free:15896kB min:64kB low:80kB high:96kB active_anon:0kB 
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB 
isolated(anon):0kB isolated(file):0kB present:15980kB managed:15904kB 
mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB 
slab_unreclaimable:8kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB 
free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[ 2075.508186] lowmem_reserve[]: 0 842 1923 1923
[ 2075.508193] Normal free:803896kB min:3680kB low:4600kB high:5520kB 
active_anon:0kB inactive_anon:0kB active_file:14052kB inactive_file:18684kB 
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:897016kB 
managed:863160kB mlocked:0kB dirty:72kB writeback:0kB mapped:4kB shmem:0kB 
slab_reclaimable:16204kB slab_unreclaimable:8968kB kernel_stack:1272kB 
pagetables:756kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB 
pages_scanned:0 all_unreclaimable? no
[ 2075.508195] lowmem_reserve[]: 0 0 8647 8647
[ 2075.508202] HighMem free:350072kB min:512kB low:1688kB high:2868kB 
active_anon:11556kB inactive_anon:108kB active_file:253536kB 
inactive_file:449352kB unevictable:0kB isolated(anon):0kB isolated(file):0kB 
present:1106844kB managed:1106844kB mlocked:0kB dirty:116kB writeback:0kB 
mapped:8960kB shmem:824kB slab_reclaimable:0kB slab_unreclaimable:0kB 
kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB 
writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[ 2075.508203] lowmem_reserve[]: 0 0 0 0
[ 2075.508206] DMA: 0*4kB 1*8kB (U) 1*16kB (U) 0*32kB 2*64kB (U) 1*128kB (U) 
1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (R) 3*4096kB (M) = 15896kB
[ 2075.508216] Normal: 50*4kB (UM) 180*8kB (UM) 159*16kB (UEM) 65*32kB (UEM) 
29*64kB (UEM) 1*128kB (M) 0*256kB 0*512kB 1*1024kB (M) 2*2048kB (UR) 193*4096kB 
(MR) = 803896kB
[ 2075.508228] HighMem: 1270*4kB (U) 942*8kB (UM) 467*16kB (UM) 1012*32kB (UM) 
632*64kB (UM) 199*128kB (UM) 61*256kB (UM) 24*512kB (M) 5*1024kB (M) 3*2048kB 
(UM) 47*4096kB (MR) = 350072kB
[ 2075.508240] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 
hugepages_size=2048kB
[ 2075.508242] 184112 total pagecache pages
[ 2075.508243] 0 pages in swap cache
[ 2075.508245] Swap cache

[PATCH V2] printk/cache: Mark printk_once test variable __read_mostly

2013-10-30 Thread Joe Perches 
Add #include  to define __read_mostly.

Convert cache.h to use uapi/linux/kernel.h instead
of linux/kernel.h to avoid recursive #includes.

Convert the ALIGN macro to __KERNEL_ALIGN.

printk_once only sets the bool variable tested
once so mark it __read_mostly.

Neaten the alignment so it matches the rest of the
pr__once #defines too.

Signed-off-by: Joe Perches 
---
V2: Add cache.h which was nearly always used
indirectly via #include ,
generally module.h
Update cache.h to avoid recursive #include

 include/linux/cache.h  |  4 ++--
 include/linux/printk.h | 19 ++-
 2 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/include/linux/cache.h b/include/linux/cache.h
index 4c57065..63a1d97 100644
--- a/include/linux/cache.h
+++ b/include/linux/cache.h
@@ -1,11 +1,11 @@
 #ifndef __LINUX_CACHE_H
 #define __LINUX_CACHE_H
 
-#include 
+#include 
 #include 
 
 #ifndef L1_CACHE_ALIGN
-#define L1_CACHE_ALIGN(x) ALIGN(x, L1_CACHE_BYTES)
+#define L1_CACHE_ALIGN(x) __KERNEL_ALIGN(x, L1_CACHE_BYTES)
 #endif
 
 #ifndef SMP_CACHE_BYTES
diff --git a/include/linux/printk.h b/include/linux/printk.h
index e6131a78..2449da9 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 
 extern const char linux_banner[];
 extern const char linux_proc_banner[];
@@ -251,17 +252,17 @@ extern asmlinkage void dump_stack(void) __cold;
  */
 
 #ifdef CONFIG_PRINTK
-#define printk_once(fmt, ...)  \
-({ \
-   static bool __print_once;   \
-   \
-   if (!__print_once) {\
-   __print_once = true;\
-   printk(fmt, ##__VA_ARGS__); \
-   }   \
+#define printk_once(fmt, ...)  \
+({ \
+   static bool __print_once __read_mostly; \
+   \
+   if (!__print_once) {\
+   __print_once = true;\
+   printk(fmt, ##__VA_ARGS__); \
+   }   \
 })
 #else
-#define printk_once(fmt, ...)  \
+#define printk_once(fmt, ...)  \
no_printk(fmt, ##__VA_ARGS__)
 #endif
 


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

Re: [PATCH] drivers: w1: make w1_slave::flags long to avoid casts

2013-10-30 Thread Andrew Morton 
On Sat, 26 Oct 2013 12:56:11 +0100 Michal Nazarewicz  wrote:

> From: Michal Nazarewicz 
> 
> Changing flags field of the w1_slave to unsigned long may on
> some architectures increase the size of the structure, but
> otherwise makes the code more kosher as casting is avoided
> and *_bit family of calls do not attempt to operate on an
> entity of bigger size than realy is available.
> 
> The current behaviour does not introduce any bugs (since any
> bytes past flags field are preserved)

hm, what does this mean

> --- a/drivers/w1/w1.c
> +++ b/drivers/w1/w1.c
> @@ -709,7 +709,7 @@ static int w1_attach_slave_device(struct w1_master *dev, 
> struct w1_reg_num *rn)
>  
>   sl->owner = THIS_MODULE;
>   sl->master = dev;
> - set_bit(W1_SLAVE_ACTIVE, (long *)>flags);
> + set_bit(W1_SLAVE_ACTIVE, >flags);

...  I'd have though that running this code on little-endian 64-bit
would result in a scribble over ...

> --- a/drivers/w1/w1.h
> +++ b/drivers/w1/w1.h
> @@ -67,8 +67,8 @@ struct w1_slave
>   struct w1_reg_num   reg_num;
>   atomic_trefcnt;
>   u8  rom[9];
> - u32 flags;
>   int ttl;

... w1_slave.ttl?

> + unsigned long   flags;
>  
>   struct w1_master*master;
>   struct w1_family*family;
>
> ...
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 -next] Fix printk_once build errors due to __read_mostly

2013-10-30 Thread Joe Perches 
On Wed, 2013-10-30 at 13:48 -0700, Andrew Morton wrote:
> On Wed, 30 Oct 2013 10:18:21 + James Hogan  wrote:
[]
> > Note that this actually adds a recursive include, since 
> > includes , which includes . The actual
> > dependencies are all in macros so it doesn't actually seem to result in
> > any build failures, but it's clearly less than ideal.
> 
> Yitch.

Yeah.

There are about ~700 files in the tree that use __read_mostly.
Only about ~25 of those actually #include 

I did a script that adds the #include, but 700 files is a _lot_.

For today's next:

$ git grep -w --name-only __read_mostly | \
  xargs grep -P -l "^\s*#\s*include\s+" | wc -l
28

$ git grep -w --name-only __read_mostly | \
  xargs grep -P -L "^\s*#\s*include\s+" | wc -l
716

Untangling that crud is nasty.

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

Re: WTF: driver-core-next contains recursive directory removal!

2013-10-30 Thread Eric W. Biederman 
Greg Kroah-Hartman  writes:

> I don't think there's an issue here, otherwise both Tejun and I would
> have found some issues during testing, same for all of the other
> linux-next users for the past few weeks.

There issues were subtle and hard to detect especially without
instrumenting the code during pci hotplug to look for them.  Memory
leaks, use after free, and needing pci hotplug to reproduce them made
the kinds of bugs I saw when I was working with it easy to go unnoticed
in light testing.

Beyond that the code has the deep issue that the code breaks normal
filesystem expectations in a way that is certain to confuse filesystem
people like Al Viro.

And yes that code being at all recursive is one of the things that Viro
objected to when you had him review sysfs before merging my cleanups
long ago.

Recursive removal is absolutely unnecessary, and it hides bugs, and
makes the code unnecessarily complex for no good reason.

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

Re: [PATCH V2 Resend 0/2] CPUFreq Cleanup Part IV

2013-10-30 Thread Rafael J. Wysocki 
On Thursday, October 31, 2013 03:57:27 AM Viresh Kumar wrote:
> On 31 October 2013 03:23, Rafael J. Wysocki  wrote:
> > [2/2] doesn't apply for me cleanly on top of the big/little changes.
> >
> > Care to rebase on top of the new bleeding-edge I've just pushed?
> 
> Done.. Please find attached..

Well, this is the last your patch from an attachment I'm ever going to
apply.  Please don't bother to send any of these to me in the future.

Thanks!

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

[PATCH V2 Resend 02/16] cpufreq: at32ap: use cpufreq_generic_get() routine

2013-10-30 Thread Viresh Kumar 
We have common infrastructure available with us for getting a CPUs clk rate.
Lets use it for this driver.

Acked-by: Hans-Christian Egtvedt 
Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/at32ap-cpufreq.c | 17 +
 1 file changed, 5 insertions(+), 12 deletions(-)

diff --git a/drivers/cpufreq/at32ap-cpufreq.c b/drivers/cpufreq/at32ap-cpufreq.c
index 856ad80..869c0b5 100644
--- a/drivers/cpufreq/at32ap-cpufreq.c
+++ b/drivers/cpufreq/at32ap-cpufreq.c
@@ -21,17 +21,8 @@
 #include 
 #include 
 
-static struct clk *cpuclk;
 static struct cpufreq_frequency_table *freq_table;
 
-static unsigned int at32_get_speed(unsigned int cpu)
-{
-   /* No SMP support */
-   if (cpu)
-   return 0;
-   return (unsigned int)((clk_get_rate(cpuclk) + 500) / 1000);
-}
-
 static unsigned intref_freq;
 static unsigned long   loops_per_jiffy_ref;
 
@@ -39,7 +30,7 @@ static int at32_set_target(struct cpufreq_policy *policy, 
unsigned int index)
 {
unsigned int old_freq, new_freq;
 
-   old_freq = at32_get_speed(0);
+   old_freq = policy->cur;
new_freq = freq_table[index].frequency;
 
if (!ref_freq) {
@@ -50,7 +41,7 @@ static int at32_set_target(struct cpufreq_policy *policy, 
unsigned int index)
if (old_freq < new_freq)
boot_cpu_data.loops_per_jiffy = cpufreq_scale(
loops_per_jiffy_ref, ref_freq, new_freq);
-   clk_set_rate(cpuclk, new_freq * 1000);
+   clk_set_rate(policy->clk, new_freq * 1000);
if (new_freq < old_freq)
boot_cpu_data.loops_per_jiffy = cpufreq_scale(
loops_per_jiffy_ref, ref_freq, new_freq);
@@ -61,6 +52,7 @@ static int at32_set_target(struct cpufreq_policy *policy, 
unsigned int index)
 static int __init at32_cpufreq_driver_init(struct cpufreq_policy *policy)
 {
unsigned int frequency, rate, min_freq;
+   static struct clk *cpuclk;
int retval, steps, i;
 
if (policy->cpu != 0)
@@ -103,6 +95,7 @@ static int __init at32_cpufreq_driver_init(struct 
cpufreq_policy *policy)
frequency /= 2;
}
 
+   policy->clk = cpuclk;
freq_table[steps - 1].frequency = CPUFREQ_TABLE_END;
 
retval = cpufreq_table_validate_and_show(policy, freq_table);
@@ -123,7 +116,7 @@ static struct cpufreq_driver at32_driver = {
.init   = at32_cpufreq_driver_init,
.verify = cpufreq_generic_frequency_table_verify,
.target_index   = at32_set_target,
-   .get= at32_get_speed,
+   .get= cpufreq_generic_get,
.flags  = CPUFREQ_STICKY,
 };
 
-- 
1.7.12.rc2.18.g61b472e

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

  1   2   3   4   5   6   7   8   9   10   >