[patch 1/4] x86, apic: Only use default_wait_for_init_deassert

[David Rientjes]

es7000_wait_for_init_deassert() is functionally equivalent to 
default_wait_for_init_deassert(), so remove the duplicate code and use
only a single function.

Signed-off-by: David Rientjes 
---
 arch/x86/include/asm/apic.h  | 1 -
 arch/x86/kernel/apic/es7000_32.c | 8 +---
 2 files changed, 1 insertion(+), 8 deletions(-)

diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -521,7 +521,6 @@ static inline void default_wait_for_init_deassert(atomic_t 
*deassert)
 {
while (!atomic_read(deassert))
cpu_relax();
-   return;
 }
 
 extern void generic_bigsmp_probe(void);
diff --git a/arch/x86/kernel/apic/es7000_32.c b/arch/x86/kernel/apic/es7000_32.c
--- a/arch/x86/kernel/apic/es7000_32.c
+++ b/arch/x86/kernel/apic/es7000_32.c
@@ -394,12 +394,6 @@ static void es7000_enable_apic_mode(void)
WARN(1, "Command failed, status = %x\n", mip_status);
 }
 
-static void es7000_wait_for_init_deassert(atomic_t *deassert)
-{
-   while (!atomic_read(deassert))
-   cpu_relax();
-}
-
 static unsigned int es7000_get_apic_id(unsigned long x)
 {
return (x >> 24) & 0xFF;
@@ -722,7 +716,7 @@ static struct apic __refdata apic_es7000 = {
.trampoline_phys_low= 0x467,
.trampoline_phys_high   = 0x469,
 
-   .wait_for_init_deassert = es7000_wait_for_init_deassert,
+   .wait_for_init_deassert = default_wait_for_init_deassert,
 
/* Nothing to do for most platforms, since cleared by the INIT cycle: */
.smp_callin_clear_local_apic= NULL,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] x86, apic: Remove unused function prototypes

[David Rientjes]

Some function prototypes declared in asm/apic.h are never defined, so
remove them.

Signed-off-by: David Rientjes 
---
 arch/x86/include/asm/apic.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -93,9 +93,6 @@ static inline int is_vsmp_box(void)
return 0;
 }
 #endif
-extern void xapic_wait_icr_idle(void);
-extern u32 safe_xapic_wait_icr_idle(void);
-extern void xapic_icr_write(u32, u32);
 extern int setup_profiling_timer(unsigned int);
 
 static inline void native_apic_mem_write(u32 reg, u32 v)
@@ -184,7 +181,6 @@ extern int x2apic_phys;
 extern int x2apic_preenabled;
 extern void check_x2apic(void);
 extern void enable_x2apic(void);
-extern void x2apic_icr_write(u32 low, u32 id);
 static inline int x2apic_enabled(void)
 {
u64 msr;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] x86, apic: Always define nox2apic and define it as initdata

[David Rientjes]

The "nox2apic" variable can be defined as __initdata since it is only
used for bootstrap.  It can now unconditionally be defined since it will
later be freed.

At the same time, it is also better off as a bool.

Signed-off-by: David Rientjes 
---
 arch/x86/include/asm/apic.h | 1 -
 arch/x86/kernel/apic/apic.c | 9 ++---
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -217,7 +217,6 @@ static inline void x2apic_force_phys(void)
 {
 }
 
-#definenox2apic0
 #definex2apic_preenabled 0
 #definex2apic_supported()  0
 #endif
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -133,6 +133,10 @@ static inline void imcr_apic_to_pic(void)
  * +1=force-enable
  */
 static int force_enable_local_apic __initdata;
+
+/* Control whether x2APIC mode is enabled or not */
+static bool nox2apic __initdata;
+
 /*
  * APIC command line parameters
  */
@@ -162,8 +166,7 @@ int x2apic_mode;
 /* x2apic enabled before OS handover */
 int x2apic_preenabled;
 static int x2apic_disabled;
-static int nox2apic;
-static __init int setup_nox2apic(char *str)
+static int __init setup_nox2apic(char *str)
 {
if (x2apic_enabled()) {
int apicid = native_apic_msr_read(APIC_ID);
@@ -178,7 +181,7 @@ static __init int setup_nox2apic(char *str)
} else
setup_clear_cpu_cap(X86_FEATURE_X2APIC);
 
-   nox2apic = 1;
+   nox2apic = true;
 
return 0;
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 2/4] x86, apic: Switch wait_for_init_deassert to bool

[David Rientjes]

Now that there is only a single wait_for_init_deassert() function, just
convert the member of struct apic to a bool to determine whether we need
to wait for init_deassert to become non-zero.

There are no more callers of default_wait_for_init_deassert(), so fold
it into the caller.

Signed-off-by: David Rientjes 
---
 arch/x86/include/asm/apic.h   | 8 +---
 arch/x86/kernel/apic/apic_flat_64.c   | 4 ++--
 arch/x86/kernel/apic/apic_noop.c  | 3 +--
 arch/x86/kernel/apic/apic_numachip.c  | 2 +-
 arch/x86/kernel/apic/bigsmp_32.c  | 3 +--
 arch/x86/kernel/apic/es7000_32.c  | 6 ++
 arch/x86/kernel/apic/numaq_32.c   | 3 +--
 arch/x86/kernel/apic/probe_32.c   | 3 +--
 arch/x86/kernel/apic/summit_32.c  | 3 +--
 arch/x86/kernel/apic/x2apic_cluster.c | 2 +-
 arch/x86/kernel/apic/x2apic_phys.c| 2 +-
 arch/x86/kernel/apic/x2apic_uv_x.c| 2 +-
 arch/x86/kernel/smpboot.c | 5 +++--
 13 files changed, 17 insertions(+), 29 deletions(-)

diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -351,7 +351,7 @@ struct apic {
int trampoline_phys_low;
int trampoline_phys_high;
 
-   void (*wait_for_init_deassert)(atomic_t *deassert);
+   bool wait_for_init_deassert;
void (*smp_callin_clear_local_apic)(void);
void (*inquire_remote_apic)(int apicid);
 
@@ -517,12 +517,6 @@ extern int default_cpu_present_to_apicid(int mps_cpu);
 extern int default_check_phys_apicid_present(int phys_apicid);
 #endif
 
-static inline void default_wait_for_init_deassert(atomic_t *deassert)
-{
-   while (!atomic_read(deassert))
-   cpu_relax();
-}
-
 extern void generic_bigsmp_probe(void);
 
 
diff --git a/arch/x86/kernel/apic/apic_flat_64.c 
b/arch/x86/kernel/apic/apic_flat_64.c
--- a/arch/x86/kernel/apic/apic_flat_64.c
+++ b/arch/x86/kernel/apic/apic_flat_64.c
@@ -198,7 +198,7 @@ static struct apic apic_flat =  {
 
.trampoline_phys_low= DEFAULT_TRAMPOLINE_PHYS_LOW,
.trampoline_phys_high   = DEFAULT_TRAMPOLINE_PHYS_HIGH,
-   .wait_for_init_deassert = NULL,
+   .wait_for_init_deassert = false,
.smp_callin_clear_local_apic= NULL,
.inquire_remote_apic= default_inquire_remote_apic,
 
@@ -314,7 +314,7 @@ static struct apic apic_physflat =  {
 
.trampoline_phys_low= DEFAULT_TRAMPOLINE_PHYS_LOW,
.trampoline_phys_high   = DEFAULT_TRAMPOLINE_PHYS_HIGH,
-   .wait_for_init_deassert = NULL,
+   .wait_for_init_deassert = false,
.smp_callin_clear_local_apic= NULL,
.inquire_remote_apic= default_inquire_remote_apic,
 
diff --git a/arch/x86/kernel/apic/apic_noop.c b/arch/x86/kernel/apic/apic_noop.c
--- a/arch/x86/kernel/apic/apic_noop.c
+++ b/arch/x86/kernel/apic/apic_noop.c
@@ -172,8 +172,7 @@ struct apic apic_noop = {
.trampoline_phys_low= DEFAULT_TRAMPOLINE_PHYS_LOW,
.trampoline_phys_high   = DEFAULT_TRAMPOLINE_PHYS_HIGH,
 
-   .wait_for_init_deassert = NULL,
-
+   .wait_for_init_deassert = false,
.smp_callin_clear_local_apic= NULL,
.inquire_remote_apic= NULL,
 
diff --git a/arch/x86/kernel/apic/apic_numachip.c 
b/arch/x86/kernel/apic/apic_numachip.c
--- a/arch/x86/kernel/apic/apic_numachip.c
+++ b/arch/x86/kernel/apic/apic_numachip.c
@@ -248,7 +248,7 @@ static const struct apic apic_numachip __refconst = {
.wakeup_secondary_cpu   = numachip_wakeup_secondary,
.trampoline_phys_low= DEFAULT_TRAMPOLINE_PHYS_LOW,
.trampoline_phys_high   = DEFAULT_TRAMPOLINE_PHYS_HIGH,
-   .wait_for_init_deassert = NULL,
+   .wait_for_init_deassert = false,
.smp_callin_clear_local_apic= NULL,
.inquire_remote_apic= NULL, /* REMRD not supported */
 
diff --git a/arch/x86/kernel/apic/bigsmp_32.c b/arch/x86/kernel/apic/bigsmp_32.c
--- a/arch/x86/kernel/apic/bigsmp_32.c
+++ b/arch/x86/kernel/apic/bigsmp_32.c
@@ -199,8 +199,7 @@ static struct apic apic_bigsmp = {
.trampoline_phys_low= DEFAULT_TRAMPOLINE_PHYS_LOW,
.trampoline_phys_high   = DEFAULT_TRAMPOLINE_PHYS_HIGH,
 
-   .wait_for_init_deassert = default_wait_for_init_deassert,
-
+   .wait_for_init_deassert = true,
.smp_callin_clear_local_apic= NULL,
.inquire_remote_apic= default_inquire_remote_apic,
 
diff --git a/arch/x86/kernel/apic/es7000_32.c b/arch/x86/kernel/apic/es7000_32.c
--- a/arch/x86/kernel/apic/es7000_32.c
+++ b/arch/x86/kernel/apic/es7000_32.c
@@ -652,8 +652,7 @@ static struct apic __refdata apic_es7000_cluster = {
.trampoline_phys_low= 0x467,
.trampoline_phys_high   = 0x469,
 
-   .wait_for_init_deassert = NULL,

Re: [PATCH] MAINTAINERS: Update drm/i915 git repo

[Daniel Vetter]

On Tue, Feb 4, 2014 at 8:37 PM, Daniel Vetter  wrote:
> On Tue, Feb 4, 2014 at 8:00 PM, Daniel Vetter  wrote:
>> Moved to a common location so that Jani also can push to it, to avoid
>> moving it every time I go on vacation. Please update autobuilders and
>> everything else pointing at the drm-intel.git repo, the old one won't
>> be updated any more.
>>
>> Cc: Dave Airlie 
>> Cc: Jani Nikula 
>> Signed-off-by: Daniel Vetter 
>
> Also forgotten to cc our QA people ...

And Wu Fengguang with his 0-day builder also needs to know about the
new git repo!
-Daniel

>> ---
>>  MAINTAINERS | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 31a046213274..e3aaf277cf58 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -2832,7 +2832,7 @@ M:Jani Nikula 
>>  L: intel-...@lists.freedesktop.org
>>  L: dri-de...@lists.freedesktop.org
>>  Q: http://patchwork.freedesktop.org/project/intel-gfx/
>> -T: git git://people.freedesktop.org/~danvet/drm-intel
>> +T: git git://anongit.freedesktop.org/drm-intel
>>  S: Supported
>>  F: drivers/gpu/drm/i915/
>>  F: include/drm/i915*
>> --
>> 1.8.5.2
>>
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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/kprobes.h: move all functions to their matched area

[Masami Hiramatsu]

(2014/02/05 14:27), Chen Gang wrote:
> For dummy functions, it is not a good idea to still use the input
> parameters (not a good idea to assume they are still effect).
> 
>  - let kprobe* static inline functions in CONFIG_KPROBES, dummy outside.
> 
>  - let (en/dis)able_jprobe() in CONFIG_KPROBES, dummy outside.
> 
>  - for kretprobe:
> 
>- let kretprobe_assert() only in CONFIG_KRETPROBES (internal use).
> 
>- remove kretprobe_inst_table_head() (cannot grep it in kernel wide).
> 
>- for (en/dis)able_kretprobe():
> 
>if CONFIG_KRETPROBES enabled, they use (en/dis)able_kprobe().
>else if CONFIG_KPROBES enabled, return -EINVAL (not registered).
>else, return -ENOSYS, just like (en/dis)able_kprobe() have done.

NAK. I don't increase complexity in this header file anymore,
unless we have any actual issue with sane usage.

Thank you,

> 
> 
> Signed-off-by: Chen Gang 
> ---
>  include/linux/kprobes.h | 136 
> 
>  1 file changed, 92 insertions(+), 44 deletions(-)
> 
> diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h
> index 925eaf2..860313d 100644
> --- a/include/linux/kprobes.h
> +++ b/include/linux/kprobes.h
> @@ -129,30 +129,6 @@ struct kprobe {
>  */
>  #define KPROBE_FLAG_FTRACE   8 /* probe is using ftrace */
>  
> -/* Has this kprobe gone ? */
> -static inline int kprobe_gone(struct kprobe *p)
> -{
> - return p->flags & KPROBE_FLAG_GONE;
> -}
> -
> -/* Is this kprobe disabled ? */
> -static inline int kprobe_disabled(struct kprobe *p)
> -{
> - return p->flags & (KPROBE_FLAG_DISABLED | KPROBE_FLAG_GONE);
> -}
> -
> -/* Is this kprobe really running optimized path ? */
> -static inline int kprobe_optimized(struct kprobe *p)
> -{
> - return p->flags & KPROBE_FLAG_OPTIMIZED;
> -}
> -
> -/* Is this kprobe uses ftrace ? */
> -static inline int kprobe_ftrace(struct kprobe *p)
> -{
> - return p->flags & KPROBE_FLAG_FTRACE;
> -}
> -
>  /*
>   * Special probe type that uses setjmp-longjmp type tricks to resume
>   * execution at a specified entry with a matching prototype corresponding
> @@ -223,7 +199,42 @@ static inline int kprobes_built_in(void)
>   return 1;
>  }
>  
> +/* Has this kprobe gone ? */
> +static inline int kprobe_gone(struct kprobe *p)
> +{
> + return p->flags & KPROBE_FLAG_GONE;
> +}
> +
> +/* Is this kprobe disabled ? */
> +static inline int kprobe_disabled(struct kprobe *p)
> +{
> + return p->flags & (KPROBE_FLAG_DISABLED | KPROBE_FLAG_GONE);
> +}
> +
> +/* Is this kprobe really running optimized path ? */
> +static inline int kprobe_optimized(struct kprobe *p)
> +{
> + return p->flags & KPROBE_FLAG_OPTIMIZED;
> +}
> +
> +/* Is this kprobe uses ftrace ? */
> +static inline int kprobe_ftrace(struct kprobe *p)
> +{
> + return p->flags & KPROBE_FLAG_FTRACE;
> +}
> +
>  #ifdef CONFIG_KRETPROBES
> +static inline void kretprobe_assert(struct kretprobe_instance *ri,
> + unsigned long orig_ret_address, unsigned long trampoline_address)
> +{
> + if (!orig_ret_address || (orig_ret_address == trampoline_address)) {
> + printk(KERN_ERR
> + "kretprobe BUG!: Processing kretprobe %p @ %p\n",
> + ri->rp, ri->rp->kp.addr);
> + BUG();
> + }
> +}
> +
>  extern void arch_prepare_kretprobe(struct kretprobe_instance *ri,
>  struct pt_regs *regs);
>  extern int arch_trampoline_kprobe(struct kprobe *p);
> @@ -240,16 +251,6 @@ static inline int arch_trampoline_kprobe(struct kprobe 
> *p)
>  
>  extern struct kretprobe_blackpoint kretprobe_blacklist[];
>  
> -static inline void kretprobe_assert(struct kretprobe_instance *ri,
> - unsigned long orig_ret_address, unsigned long trampoline_address)
> -{
> - if (!orig_ret_address || (orig_ret_address == trampoline_address)) {
> - printk("kretprobe BUG!: Processing kretprobe %p @ %p\n",
> - ri->rp, ri->rp->kp.addr);
> - BUG();
> - }
> -}
> -
>  #ifdef CONFIG_KPROBES_SANITY_TEST
>  extern int init_test_probes(void);
>  #else
> @@ -340,7 +341,6 @@ struct kprobe *get_kprobe(void *addr);
>  void kretprobe_hash_lock(struct task_struct *tsk,
>struct hlist_head **head, unsigned long *flags);
>  void kretprobe_hash_unlock(struct task_struct *tsk, unsigned long *flags);
> -struct hlist_head * kretprobe_inst_table_head(struct task_struct *tsk);
>  
>  /* kprobe_running() will just return the current_kprobe on this CPU */
>  static inline struct kprobe *kprobe_running(void)
> @@ -384,12 +384,60 @@ int enable_kprobe(struct kprobe *kp);
>  
>  void dump_kprobe(struct kprobe *kp);
>  
> +static inline int disable_jprobe(struct jprobe *jp)
> +{
> + return disable_kprobe(>kp);
> +}
> +
> +static inline int enable_jprobe(struct jprobe *jp)
> +{
> + return enable_kprobe(>kp);
> +}
> +
> +#ifdef CONFIG_KRETPROBES
> +static inline 

Re: vmwgfx: Fix unitialized stack read in vmw_setup_otable_base

[Thomas Hellstrom]

On 01/31/2014 03:27 AM, Dave Jones wrote:
> One of the error paths in vmw_setup_otable_base causes us to return with
> 'ret' having never been set to anything causing us to return whatever was
> on the stack.
>
> Found with Coverity
>
> Signed-off-by: Dave Jones 
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
> index 4910e7b81811..d4a5a19cb8c3 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
> @@ -134,6 +134,7 @@ static int vmw_setup_otable_base(struct vmw_private 
> *dev_priv,
>   cmd = vmw_fifo_reserve(dev_priv, sizeof(*cmd));
>   if (unlikely(cmd == NULL)) {
>   DRM_ERROR("Failed reserving FIFO space for OTable setup.\n");
> + ret = -ENOMEM;
>   goto out_no_fifo;
>   }
>  

Thanks,
Will queue on vmwgfx-fixes for -rc2.

/Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ipv4: Fix runtime WARNING in rtmsg_ifa()

[Geert Uytterhoeven]

On m68k/ARAnyM:

WARNING: CPU: 0 PID: 407 at net/ipv4/devinet.c:1599 0x316a99()
Modules linked in:
CPU: 0 PID: 407 Comm: ifconfig Not tainted
3.13.0-atari-09263-g0c71d68014d1 #1378
Stack from 10c4fdf0:
10c4fdf0 002ffabb 000243e8  008ced6c 00024416 00316a99 063f
00316a99 0009  002501b4 00316a99 063f c0a86117 0080
c0a86117 00ad0c90 00250a5a 0014 00ad0c90   0001
00b02dd0 00356594  00356594 c0a86117 eff6c9e4 008ced6c 0002
008ced60 0024f9b4 00250b52 00ad0c90   00252390 00ad0c90
eff6c9e4 004f   eff6c9e4 8000e25c eff6c9e4 80001020
Call Trace: [<000243e8>] warn_slowpath_common+0x52/0x6c
 [<00024416>] warn_slowpath_null+0x14/0x1a
 [<002501b4>] rtmsg_ifa+0xdc/0xf0
 [<00250a5a>] __inet_insert_ifa+0xd6/0x1c2
 [<0024f9b4>] inet_abc_len+0x0/0x42
 [<00250b52>] inet_insert_ifa+0xc/0x12
 [<00252390>] devinet_ioctl+0x2ae/0x5d6

Adding some debugging code reveals that net_fill_ifaddr() fails in

put_cacheinfo(skb, ifa->ifa_cstamp, ifa->ifa_tstamp,
  preferred, valid))

nla_put complains:

lib/nlattr.c:454: skb_tailroom(skb) = 12, nla_total_size(attrlen) = 20

Apparently commit 5c766d642bcaffd0c2a5b354db2068515b3846cf ("ipv4:
introduce address lifetime") forgot to take into account the addition of
struct ifa_cacheinfo in inet_nlmsg_size(). Hence add it, like is already
done for ipv6.

Suggested-by: Cong Wang 
Signed-off-by: Geert Uytterhoeven 
---
 net/ipv4/devinet.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index ac2dff3c2c1c..bdbf68bb2e2d 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1443,7 +1443,8 @@ static size_t inet_nlmsg_size(void)
   + nla_total_size(4) /* IFA_LOCAL */
   + nla_total_size(4) /* IFA_BROADCAST */
   + nla_total_size(IFNAMSIZ) /* IFA_LABEL */
-  + nla_total_size(4);  /* IFA_FLAGS */
+  + nla_total_size(4)  /* IFA_FLAGS */
+  + nla_total_size(sizeof(struct ifa_cacheinfo)); /* IFA_CACHEINFO 
*/
 }
 
 static inline u32 cstamp_delta(unsigned long cstamp)
-- 
1.7.9.5

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

Re: [PATCH v4 1/2] iio:as3935: Add DT binding docs for AS3935 driver

[Jonathan Cameron]

On February 5, 2014 4:43:35 AM GMT+00:00, Matt Porter  
wrote:
>On Tue, Feb 04, 2014 at 07:14:55PM -0800, Matt Ranostay Matt Ranostay
>wrote:
>> Document compatible string, required and optional DT properties for
>> AS3935 chipset driver.
>> 
>> Signed-off-by: Matt Ranostay 
>> ---
>>  .../devicetree/bindings/iio/proximity/as3935.txt   | 25
>++
>>  1 file changed, 25 insertions(+)
>>  create mode 100644
>Documentation/devicetree/bindings/iio/proximity/as3935.txt
>> 
>> diff --git
>a/Documentation/devicetree/bindings/iio/proximity/as3935.txt
>b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
>> new file mode 100644
>> index 000..7e117cd
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
>> @@ -0,0 +1,25 @@
>> +Austrian Microsystems AS3935 Franklin lightning sensor device driver
>> +
>> +Required properties:
>> +- compatible: must be "ams,as3935"
>
>Change this to "amstaos,as3935"
>
>amstaos (AMS bought Taos) is already a registered vendor prefix in
>vendor-prefixes.txt

It is but has a rather separate presence and is not where people expect to find 
non light
 sensor stuff from ams. I personally would go for a new vendor prefix and stick 
with ams.

>
>> +- reg: SPI chip select number for the device
>> +- spi-cpha: SPI Mode 1
>
>When using generic binding properties, please reference the binding
>being used. Like:
>
>   - spi-cpha: SPI Mode 1. Refer to spi/spi-bus.txt for generic SPI
> slave node bindings.
>
>> +- interrupt-parent : should be the phandle for the interrupt
>controller
>> +- interrupts : interrupt mapping for GPIO IRQ
>
>   Refer to interrupt-controller/interrupts.txt for generic
>   interrupt client node bindings.
>
>> +
>> +Optional properties:
>> +- ams,tune-cap: Calibration tuning capacitor stepping value 0 - 15.
>> +  Range of 0 to 120 pF, 8pF steps. This will require using the
>> +  calibration data from the manufacturer.
>> +
>> +
>> +Example:
>> +
>> +as3935@0 {
>> +compatible = "ams,as3935";
>> +reg = <0>;
>> +spi-cpha;
>> +interrupt-parent = <>;
>> +interrupts = <16 1>;
>> +ams,tune-cap = /bits/ 8 <10>;
>
>What is this? Why not just ams,tune-cap = <10>; ?
>
>It's a value between 0-15, right?
>
>-Matt
>--
>To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>the body of a message to majord...@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] mm: vmscan: get rid of DEFAULT_SEEKS and document shrink_slab logic

[Vladimir Davydov]

On 02/05/2014 01:58 AM, Andrew Morton wrote:
> On Fri, 17 Jan 2014 23:25:30 +0400 Vladimir Davydov  
> wrote:
>
>> Each shrinker must define the number of seeks it takes to recreate a
>> shrinkable cache object. It is used to balance slab reclaim vs page
>> reclaim: assuming it costs one seek to replace an LRU page, we age equal
>> percentages of the LRU and ageable caches. So far, everything sounds
>> clear, but the code implementing this behavior is rather confusing.
>>
>> First, there is the DEFAULT_SEEKS constant, which equals 2 for some
>> reason:
>>
>>   #define DEFAULT_SEEKS 2 /* A good number if you don't know better. */
>>
>> Most shrinkers define `seeks' to be equal to DEFAULT_SEEKS, some use
>> DEFAULT_SEEKS*N, and there are a few that totally ignore it. What is
>> peculiar, dcache and icache shrinkers have seeks=DEFAULT_SEEKS although
>> recreating an inode typically requires one seek. Does this mean that we
>> scan twice more inodes than we should?
>>
>> Actually, no. The point is that vmscan handles DEFAULT_SEEKS as if it
>> were 1 (`delta' is the number of objects we are going to scan):
>>
>>   shrink_slab_node():
>> delta = (4 * nr_pages_scanned) / shrinker->seeks;
>> delta *= freeable;
>> do_div(delta, lru_pages + 1);
>>
>> i.e.
>>
>> 2 * nr_pages_scannedDEFAULT_SEEKS
>> delta =  * --- * freeable;
>>  lru_pages shrinker->seeks
>>
>> Here we double the number of pages scanned in order to take into account
>> moves of on-LRU pages from the inactive list to the active list, which
>> we do not count in nr_pages_scanned.
>>
>> That said, shrinker->seeks=DEFAULT_SEEKS*N is equivalent to N seeks, so
>> why on the hell do we need it?
>>
>> IMO, the existence of the DEFAULT_SEEKS constant only causes confusion
>> for both users of the shrinker interface and those trying to understand
>> how slab shrinking works. The meaning of the `seeks' is perfectly
>> explained by the comment to it and there is no need in any obscure
>> constants for using it.
>>
>> That's why I'm sending this patch which completely removes DEFAULT_SEEKS
>> and makes all shrinkers use N instead of N*DEFAULT_SEEKS, documenting
>> the idea lying behind shrink_slab() in the meanwhile.
>>
>> Unfortunately, there are a few shrinkers that define seeks=1, which is
>> impossible to transfer to the new interface intact, namely:
>>
>>   nfsd_reply_cache_shrinker
>>   ttm_pool_manager::mm_shrink
>>   ttm_pool_manager::mm_shrink
>>   dm_bufio_client::shrinker
>>
>> It seems to me their authors were simply deceived by this mysterious
>> DEFAULT_SEEKS constant, because I've found no documentation why these
>> particular caches should be scanned more aggressively than the page and
>> other slab caches. For them, this patch leaves seeks=1. Thus, it DOES
>> introduce a functional change: the shrinkers enumerated above will be
>> scanned twice less intensively than they are now. I do not think that
>> this will cause any problems though.
>>
> um, yes.  DEFAULT_SEEKS is supposed to be "the number of seeks if you
> don't know any better".  Using DEFAULT_SEEKS*n is just daft.
>
> So why did I originally make DEFAULT_SEEKS=2?  Because I figured that to
> recreate (say) an inode would require a seek to the inode data then a
> seek back.  Is it legitimate to include the
> seek-back-to-what-you-were-doing-before seek in the cost of an inode
> reclaim?  I guess so...

Hmm, that explains this 2. Since we typically don't need to "seek back"
when recreating a cache page, as they are usually read in bunches by
readahead, the number of seeks to bring back a user page is 1, while the
number of seeks to recreate an average inode is 2, right?

Then to scan inodes and user pages so that they would generate
approximately the same number of seeks, we should calculate the number
of objects to scan as follows:

nr_objects_to_scan = nr_pages_scanned / lru_pages *
nr_freeable_objects /
shrinker->seeks

where shrinker->seeks = DEFAULT_SEEKS = 2 for inodes. But currently we
have four times that. I can explain why we should multiply this by 2 -
we do not count pages moving from active to inactive lrus in
nr_pages_scanned, and 2*nr_pages_scanned can be a good approximation for
that - but I have no idea why we multiply it by 4...

Thanks.

>
> If a filesystem were to require a seek to the superblock for every
> inode read (ok, bad example) then the cost of reestablishing that inode
> would be 3.
>
> All that being said, why did you go through and halve everything?  The
> cost of reestablishing an ext2 inode should be "2 seeks", but the patch
> makes it "1".
>

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

Re: [RFCv2 08/10] xhci: Add a global command queue

[Dan Williams]

On Thu, Jan 30, 2014 at 6:10 AM, Mathias Nyman
 wrote:
> Create a list to store command structures, add a strucure to it every time
> a command is submitted, and remove it from the list once we get a
> command completion event matching the command.
>
> Signed-off-by: Mathias Nyman 
> ---
>  drivers/usb/host/xhci-mem.c  |  8 
>  drivers/usb/host/xhci-ring.c | 13 -
>  drivers/usb/host/xhci.h  |  1 +
>  3 files changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
> index 49b8bd0..7f8e4c3 100644
> --- a/drivers/usb/host/xhci-mem.c
> +++ b/drivers/usb/host/xhci-mem.c
> @@ -1694,6 +1694,7 @@ void xhci_mem_cleanup(struct xhci_hcd *xhci)
>  {
> struct pci_dev  *pdev = 
> to_pci_dev(xhci_to_hcd(xhci)->self.controller);
> struct xhci_cd  *cur_cd, *next_cd;
> +   struct xhci_command *cur_cmd, *next_cmd;
> int size;
> int i, j, num_ports;
>
> @@ -1722,6 +1723,12 @@ void xhci_mem_cleanup(struct xhci_hcd *xhci)
> kfree(cur_cd);
> }
>
> +   list_for_each_entry_safe(cur_cmd, next_cmd,
> +   >cmd_list, cmd_list) {
> +   list_del(_cmd->cmd_list);
> +   kfree(cur_cmd);
> +   }
> +

Aren't commands on the cmd_list currently being executed, or are there
other guarantees that make sure all commands have terminated?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 01/04] PCI: rcar: Register each instance independently

[Magnus Damm]

From: Magnus Damm 

Convert the code to allow per-device probe() like other device
drivers. This also delays driver registration due to change from
subsys_initcall() to regular module_platform_driver().

Signed-off-by: Magnus Damm 
---

 drivers/pci/host/pci-rcar-gen2.c |   74 --
 1 file changed, 16 insertions(+), 58 deletions(-)

--- 0001/drivers/pci/host/pci-rcar-gen2.c
+++ work/drivers/pci/host/pci-rcar-gen2.c   2014-02-04 16:38:46.0 
+0900
@@ -74,9 +74,6 @@
 
 #define RCAR_PCI_UNIT_REV_REG  (RCAR_AHBPCI_PCICOM_OFFSET + 0x48)
 
-/* Number of internal PCI controllers */
-#define RCAR_PCI_NR_CONTROLLERS3
-
 struct rcar_pci_priv {
struct device *dev;
void __iomem *reg;
@@ -228,6 +225,8 @@ static int __init rcar_pci_setup(int nr,
pci_add_resource(>resources, >io_res);
pci_add_resource(>resources, >mem_res);
 
+   /* Setup bus number based on platform device id */
+   sys->busnr = to_platform_device(priv->dev)->id;
return 1;
 }
 
@@ -236,48 +235,12 @@ static struct pci_ops rcar_pci_ops = {
.write  = rcar_pci_write_config,
 };
 
-static struct hw_pci rcar_hw_pci __initdata = {
-   .map_irq= rcar_pci_map_irq,
-   .ops= _pci_ops,
-   .setup  = rcar_pci_setup,
-};
-
-static int rcar_pci_count __initdata;
-
-static int __init rcar_pci_add_controller(struct rcar_pci_priv *priv)
-{
-   void **private_data;
-   int count;
-
-   if (rcar_hw_pci.nr_controllers < rcar_pci_count)
-   goto add_priv;
-
-   /* (Re)allocate private data pointer array if needed */
-   count = rcar_pci_count + RCAR_PCI_NR_CONTROLLERS;
-   private_data = kzalloc(count * sizeof(void *), GFP_KERNEL);
-   if (!private_data)
-   return -ENOMEM;
-
-   rcar_pci_count = count;
-   if (rcar_hw_pci.private_data) {
-   memcpy(private_data, rcar_hw_pci.private_data,
-  rcar_hw_pci.nr_controllers * sizeof(void *));
-   kfree(rcar_hw_pci.private_data);
-   }
-
-   rcar_hw_pci.private_data = private_data;
-
-add_priv:
-   /* Add private data pointer to the array */
-   rcar_hw_pci.private_data[rcar_hw_pci.nr_controllers++] = priv;
-   return 0;
-}
-
-static int __init rcar_pci_probe(struct platform_device *pdev)
+static int rcar_pci_probe(struct platform_device *pdev)
 {
struct resource *cfg_res, *mem_res;
struct rcar_pci_priv *priv;
void __iomem *reg;
+   struct hw_pci hw;
 
cfg_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
reg = devm_ioremap_resource(>dev, cfg_res);
@@ -308,31 +271,26 @@ static int __init rcar_pci_probe(struct
priv->reg = reg;
priv->dev = >dev;
 
-   return rcar_pci_add_controller(priv);
+   memset(, 0, sizeof(hw));
+   hw.nr_controllers = 1;
+   hw.private_data = (void **)
+   hw.map_irq = rcar_pci_map_irq;
+   hw.ops = _pci_ops;
+   hw.setup = rcar_pci_setup;
+   pci_common_init_dev(>dev, );
+   return 0;
 }
 
 static struct platform_driver rcar_pci_driver = {
.driver = {
.name = "pci-rcar-gen2",
+   .owner = THIS_MODULE,
+   .suppress_bind_attrs = true,
},
+   .probe = rcar_pci_probe,
 };
 
-static int __init rcar_pci_init(void)
-{
-   int retval;
-
-   retval = platform_driver_probe(_pci_driver, rcar_pci_probe);
-   if (!retval)
-   pci_common_init(_hw_pci);
-
-   /* Private data pointer array is not needed any more */
-   kfree(rcar_hw_pci.private_data);
-   rcar_hw_pci.private_data = NULL;
-
-   return retval;
-}
-
-subsys_initcall(rcar_pci_init);
+module_platform_driver(rcar_pci_driver);
 
 MODULE_LICENSE("GPL v2");
 MODULE_DESCRIPTION("Renesas R-Car Gen2 internal PCI");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 04/04] PCI: rcar: Enable BOUNCE in case of HIGHMEM

[Magnus Damm]

From: Magnus Damm 

Select BOUNCE in case of HIGHMEM to enable bounce buffers in
the block layer. Without this patch the DMABOUNCE code will
error out due to lack of HIGHMEM support, and without DMABOUNCE
there will be silent errors.

Signed-off-by: Magnus Damm 
---

 drivers/pci/host/Kconfig |1 +
 1 file changed, 1 insertion(+)

--- 0009/drivers/pci/host/Kconfig
+++ work/drivers/pci/host/Kconfig   2014-02-04 16:11:27.0 +0900
@@ -30,6 +30,7 @@ config PCI_RCAR_GEN2
depends on ARM && (ARCH_R8A7790 || ARCH_R8A7791 || COMPILE_TEST)
select GENERIC_ALLOCATOR
select DMABOUNCE
+   select BOUNCE if HIGHMEM
help
  Say Y here if you want internal PCI support on R-Car Gen2 SoC.
  There are 3 internal PCI controllers available with a single
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 00/04] PCI: rcar: Driver model and physical address space update

[Magnus Damm]

PCI: rcar: Driver model and physical address space update

[PATCH 01/04] PCI: rcar: Register each instance independently
[PATCH 02/04] PCI: rcar: Break out window size handling
[PATCH 03/04] PCI: rcar: Add DMABOUNCE support
[PATCH 04/04] PCI: rcar: Enable BOUNCE in case of HIGHMEM

These patches update the pci-rcar-gen2.c driver in various ways
including cleanups for driver model interface (1/4), readability
update (2/4) and also bounce buffer support (3/4, 4/4). Basically
the first two are just cleanups and the rest are fixes.

As it is today without these patches the system memory start address
is hard coded at 0x400 and the window is fixed at 1GiB. So we
have board specific code hidden in the driver which is good to avoid.

With these hard coded board specific constants there are some error cases
that are not handled, in particular the issue that only maximum 1GiB of
physical address space can be used for bus mastering with a single window.
The common case of using ARM CONFIG_VMSPLIT_3G results in no visible issues
as long as CONFIG_BOUNCE is used, but other CONFIG_VMSPLIT settings will
break due to the hard coded 1GiB window not being enough. It has been
verified that reducing the window size to 256MB makes the driver behave
the same with VMSPLIT_3G as 1GiB window size and other VMSPLIT settings.

To handle the maximum 1GiB physical address space limitation two types
of bounce buffers are added. The ARM specific DMABOUNCE code is in 3/4
hooked up to a chunk of local memory that is also handed of as coherent
memory to the pci devices hanging off the PCI bridge. The driver makes
sure to set the window so the local memory is always included. When the
PCI devices are operating and in case memory is used outside the window
then the DMABOUNCE buffers kicks in. This makes the driver support all
kinds of VMSPLIT settings and window sizes. The BOUNCE code in 4/4 is
selected to make sure bounce buffers are used for HIGHMEM.

With these patches this driver can be used with or without CMA and
with or without DMA zone. Basically the system wide memory setup is
left to the user. If a DMA zone is used then the PCI window will
be setup to cover that. Same thing with CMA.

Tested with USB storage using LPAE and various VMSPLIT settings together
with renesas git tag renesas-devel-v3.14-rc1-20140204 from kernel.org

Signed-off-by: Magnus Damm 
---

 Written against renesas.git tag renesas-devel-v3.14-rc1-20140204

 drivers/pci/host/Kconfig |3 
 drivers/pci/host/pci-rcar-gen2.c |  367 +++---
 2 files changed, 306 insertions(+), 64 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 03/04] PCI: rcar: Add DMABOUNCE support

[Magnus Damm]

From: Magnus Damm 

Add DMABOUNCE support together with a local memory area for
all PCI devices hanging off this bridge. 4MiB of memory is
set aside for coherent allocations which is shared between
the on-chip OHCI and EHCI devices that are hanging off the
PCI bridge. With this patch the driver will work for all
CONFIG_VMSPLIT settings.

Signed-off-by: Magnus Damm 
---

 drivers/pci/host/Kconfig |2 
 drivers/pci/host/pci-rcar-gen2.c |  262 +-
 2 files changed, 261 insertions(+), 3 deletions(-)

--- 0001/drivers/pci/host/Kconfig
+++ work/drivers/pci/host/Kconfig   2014-02-04 17:23:57.0 +0900
@@ -28,6 +28,8 @@ config PCI_TEGRA
 config PCI_RCAR_GEN2
bool "Renesas R-Car Gen2 Internal PCI controller"
depends on ARM && (ARCH_R8A7790 || ARCH_R8A7791 || COMPILE_TEST)
+   select GENERIC_ALLOCATOR
+   select DMABOUNCE
help
  Say Y here if you want internal PCI support on R-Car Gen2 SoC.
  There are 3 internal PCI controllers available with a single
--- 0006/drivers/pci/host/pci-rcar-gen2.c
+++ work/drivers/pci/host/pci-rcar-gen2.c   2014-02-04 17:26:10.0 
+0900
@@ -15,11 +15,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
 
 /* AHB-PCI Bridge PCI communication registers */
 #define RCAR_AHBPCI_PCICOM_OFFSET  0x800
@@ -83,6 +86,11 @@ struct rcar_pci_priv {
struct resource *cfg_res;
int irq;
unsigned long window_size;
+   u32 window_base;
+   struct notifier_block bus_notifier;
+   struct gen_pool *dma_pool;
+   unsigned long dma_size;
+   dma_addr_t dma_phys;
 };
 
 /* PCI configuration space operations */
@@ -217,8 +225,8 @@ static int __init rcar_pci_setup(int nr,
   RCAR_PCI_ARBITER_PCIBP_MODE;
iowrite32(val, reg + RCAR_PCI_ARBITER_CTR_REG);
 
-   /* PCI-AHB mapping: 0x4000 base */
-   iowrite32(0x4000 | RCAR_PCIAHB_PREFETCH16,
+   /* PCI-AHB mapping: dynamic base */
+   iowrite32(priv->window_base | RCAR_PCIAHB_PREFETCH16,
  reg + RCAR_PCIAHB_WIN1_CTR_REG);
 
/* AHB-PCI mapping: OHCI/EHCI registers */
@@ -229,7 +237,7 @@ static int __init rcar_pci_setup(int nr,
iowrite32(RCAR_AHBPCI_WIN1_HOST | RCAR_AHBPCI_WIN_CTR_CFG,
  reg + RCAR_AHBPCI_WIN1_CTR_REG);
/* Set PCI-AHB Window1 address */
-   iowrite32(0x4000 | PCI_BASE_ADDRESS_MEM_PREFETCH,
+   iowrite32(priv->window_base | PCI_BASE_ADDRESS_MEM_PREFETCH,
  reg + PCI_BASE_ADDRESS_1);
/* Set AHB-PCI bridge PCI communication area address */
val = priv->cfg_res->start + RCAR_AHBPCI_PCICOM_OFFSET;
@@ -258,12 +266,231 @@ static struct pci_ops rcar_pci_ops = {
.write  = rcar_pci_write_config,
 };
 
+static struct rcar_pci_priv *rcar_pci_dev_to_priv(struct device *dev)
+{
+   struct pci_sys_data *sys = to_pci_dev(dev)->sysdata;
+
+   return sys->private_data;
+}
+
+static void *rcar_pci_dma_alloc(struct device *dev, size_t size,
+   dma_addr_t *handle, gfp_t gfp,
+   struct dma_attrs *attrs)
+{
+   struct rcar_pci_priv *p = rcar_pci_dev_to_priv(dev);
+
+   return (void *)gen_pool_dma_alloc(p->dma_pool, size, handle);
+}
+
+static void rcar_pci_dma_free(struct device *dev, size_t size, void *cpu_addr,
+ dma_addr_t handle, struct dma_attrs *attrs)
+{
+   struct rcar_pci_priv *p = rcar_pci_dev_to_priv(dev);
+
+   gen_pool_free(p->dma_pool, (unsigned long)cpu_addr, size);
+}
+
+static struct dma_map_ops rcar_pci_dma_ops_init = {
+   .alloc = rcar_pci_dma_alloc,
+   .free = rcar_pci_dma_free,
+};
+
+static int rcar_pci_dma_mmap(struct device *dev, struct vm_area_struct *vma,
+void *cpu_addr, dma_addr_t dma_addr, size_t size,
+struct dma_attrs *attrs)
+{
+   struct rcar_pci_priv *p = rcar_pci_dev_to_priv(dev);
+
+   return get_dma_ops(p->dev)->mmap(p->dev, vma, cpu_addr,
+dma_addr, size, attrs);
+}
+
+static int rcar_pci_dma_get_sgtable(struct device *dev, struct sg_table *sgt,
+   void *cpu_addr, dma_addr_t handle,
+   size_t size, struct dma_attrs *attrs)
+{
+   struct rcar_pci_priv *p = rcar_pci_dev_to_priv(dev);
+
+   return get_dma_ops(p->dev)->get_sgtable(p->dev, sgt, cpu_addr,
+   handle, size, attrs);
+}
+
+static dma_addr_t rcar_pci_dma_map_page(struct device *dev, struct page *page,
+   unsigned long offset, size_t size,
+   enum dma_data_direction dir,
+   struct dma_attrs *attrs)
+{
+   struct rcar_pci_priv *p = 

[PATCH] pinctrl: do not init debugfs entries for unimplemented functionalities

[Florian Vaussard]

Commit c420619 "pinctrl: pinconf: remove checks on ops->pin_config_get"
removed the check on (ops != NULL) when performing pinconf_pins_show() or
pinconf_groups_show(). As these entries are always enabled, even if
pinconf is not supported, reading will result in an oops due to NULL
ops.

Instead of checking for ops, remove the corresponding debugfs entries if
pinconf and/or pinmux are not implemented.

Tested on OMAP3 (pinctrl-single).

Signed-off-by: Florian Vaussard 
---
 drivers/pinctrl/core.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 5ee61a4..3f64c01 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -1642,8 +1642,10 @@ static void pinctrl_init_device_debugfs(struct 
pinctrl_dev *pctldev)
device_root, pctldev, _groups_ops);
debugfs_create_file("gpio-ranges", S_IFREG | S_IRUGO,
device_root, pctldev, _gpioranges_ops);
-   pinmux_init_device_debugfs(device_root, pctldev);
-   pinconf_init_device_debugfs(device_root, pctldev);
+   if (pctldev->desc->pmxops)
+   pinmux_init_device_debugfs(device_root, pctldev);
+   if (pctldev->desc->confops)
+   pinconf_init_device_debugfs(device_root, pctldev);
 }
 
 static void pinctrl_remove_device_debugfs(struct pinctrl_dev *pctldev)
-- 
1.8.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 02/04] PCI: rcar: Break out window size handling

[Magnus Damm]

From: Magnus Damm 

Break out the hard coded window size code to allow
dynamic setup. The window size is still left at 1GiB
but with this patch changing window size is easy for
testing.

Signed-off-by: Magnus Damm 
---

 drivers/pci/host/pci-rcar-gen2.c |   31 ---
 1 file changed, 28 insertions(+), 3 deletions(-)

--- 0005/drivers/pci/host/pci-rcar-gen2.c
+++ work/drivers/pci/host/pci-rcar-gen2.c   2014-02-04 17:22:41.0 
+0900
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /* AHB-PCI Bridge PCI communication registers */
@@ -81,6 +82,7 @@ struct rcar_pci_priv {
struct resource mem_res;
struct resource *cfg_res;
int irq;
+   unsigned long window_size;
 };
 
 /* PCI configuration space operations */
@@ -180,10 +182,31 @@ static int __init rcar_pci_setup(int nr,
iowrite32(val, reg + RCAR_USBCTR_REG);
udelay(4);
 
-   /* De-assert reset and set PCIAHB window1 size to 1GB */
+   /* De-assert reset and reset PCIAHB window1 size */
val &= ~(RCAR_USBCTR_PCIAHB_WIN1_MASK | RCAR_USBCTR_PCICLK_MASK |
 RCAR_USBCTR_USBH_RST | RCAR_USBCTR_PLL_RST);
-   iowrite32(val | RCAR_USBCTR_PCIAHB_WIN1_1G, reg + RCAR_USBCTR_REG);
+
+   /* Setup PCIAHB window1 size */
+   switch (priv->window_size) {
+   case SZ_2G:
+   val |= RCAR_USBCTR_PCIAHB_WIN1_2G;
+   break;
+   case SZ_1G:
+   val |= RCAR_USBCTR_PCIAHB_WIN1_1G;
+   break;
+   case SZ_512M:
+   val |= RCAR_USBCTR_PCIAHB_WIN1_512M;
+   break;
+   default:
+   pr_warn("unknown window size %ld - defaulting to 256M\n",
+   priv->window_size);
+   priv->window_size = SZ_256M;
+   /* fall-through */
+   case SZ_256M:
+   val |= RCAR_USBCTR_PCIAHB_WIN1_256M;
+   break;
+   }
+   iowrite32(val, reg + RCAR_USBCTR_REG);
 
/* Configure AHB master and slave modes */
iowrite32(RCAR_AHB_BUS_MODE, reg + RCAR_AHB_BUS_CTR_REG);
@@ -194,7 +217,7 @@ static int __init rcar_pci_setup(int nr,
   RCAR_PCI_ARBITER_PCIBP_MODE;
iowrite32(val, reg + RCAR_PCI_ARBITER_CTR_REG);
 
-   /* PCI-AHB mapping: 0x4000-0x8000 */
+   /* PCI-AHB mapping: 0x4000 base */
iowrite32(0x4000 | RCAR_PCIAHB_PREFETCH16,
  reg + RCAR_PCIAHB_WIN1_CTR_REG);
 
@@ -271,6 +294,8 @@ static int rcar_pci_probe(struct platfor
priv->reg = reg;
priv->dev = >dev;
 
+   priv->window_size = SZ_1G;
+
memset(, 0, sizeof(hw));
hw.nr_controllers = 1;
hw.private_data = (void **)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] slub: fix false-positive lockdep warning in free_partial()

[Vladimir Davydov]

Commit c65c1877bd68 ("slub: use lockdep_assert_held") requires
remove_partial() to be called with n->list_lock held, but free_partial()
called from kmem_cache_close() on cache destruction does not follow this
rule, leading to a warning:

  WARNING: CPU: 0 PID: 2787 at mm/slub.c:1536 
__kmem_cache_shutdown+0x1b2/0x1f0()
  Modules linked in:
  CPU: 0 PID: 2787 Comm: modprobe Tainted: GW3.14.0-rc1-mm1+ #1
  Hardware name:
   0600 88003ae1dde8 816d9583 0600
    88003ae1de28 8107c107 
   880037ab2b00 88007c240d30 ea0001ee5280 ea0001ee52a0
  Call Trace:
   [] dump_stack+0x51/0x6e
   [] warn_slowpath_common+0x87/0xb0
   [] warn_slowpath_null+0x15/0x20
   [] __kmem_cache_shutdown+0x1b2/0x1f0
   [] kmem_cache_destroy+0x43/0xf0
   [] xfs_destroy_zones+0x103/0x110 [xfs]
   [] exit_xfs_fs+0x38/0x4e4 [xfs]
   [] SyS_delete_module+0x19a/0x1f0
   [] ? retint_swapgs+0x13/0x1b
   [] ? trace_hardirqs_on_caller+0x105/0x1d0
   [] ? trace_hardirqs_on_thunk+0x3a/0x3f
   [] system_call_fastpath+0x16/0x1b

Although this cannot actually result in a race, because on cache
destruction there should not be any concurrent frees or allocations from
the cache, let's add spin_lock/unlock to free_partial() just to keep
lockdep happy.

Signed-off-by: Vladimir Davydov 
---
 v2: add a comment explaining why we need to take the lock

 mm/slub.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/mm/slub.c b/mm/slub.c
index 0eeea85034c8..24bf05e962ff 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -3191,6 +3191,11 @@ static void free_partial(struct kmem_cache *s, struct 
kmem_cache_node *n)
 {
struct page *page, *h;
 
+   /*
+* the lock is for lockdep's sake, not for any actual
+* race protection
+*/
+   spin_lock_irq(>list_lock);
list_for_each_entry_safe(page, h, >partial, lru) {
if (!page->inuse) {
remove_partial(n, page);
@@ -3200,6 +3205,7 @@ static void free_partial(struct kmem_cache *s, struct 
kmem_cache_node *n)
"Objects remaining in %s on kmem_cache_close()");
}
}
+   spin_unlock_irq(>list_lock);
 }
 
 /*
-- 
1.7.10.4

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

Re: [PATCH v2 0/3] Deferrable timers support for timerfd API

[Alexey Perevalov]

On 02/04/2014 08:10 PM, Thomas Gleixner wrote:

On Mon, 27 Jan 2014, Alexey Perevalov wrote:

On 01/21/2014 11:12 PM, John Stultz wrote:

Thomas: Any thought here? Should we be trying to unify the timerfd flags
and the posix timer flags (specifically things like TIMER_CANCEL_ON_SET,
which is currently timerfd-only)?  Should a deferrable flag be added to
the hrtimer core or left to the timer wheel?

The timer cancel on set was added only to timerfd because timerfd is a
non posix interface and we are halfways free to add stuff to
it. Adding extra flags to the real posix timer interfaces is a
different story.
And what about "deferrable" possibility for hrtimers, do you consider it 
reasonable?




What's the rationale for a deferrable flag for user space interfaces?
The main reason of this was do not call user space timers on system 
idle, to safe power on embedded systems, especially in case of NOHZ.




Thanks,

tglx




--
Best regards,
Alexey Perevalov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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.13 000/140] 3.13.2-stable review

[Guenter Roeck]

On 02/04/2014 01:09 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 3.13.2 release.
There are 140 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Thu Feb  6 21:10:18 UTC 2014.
Anything received after that time might be too late.



Version tested: v3.13.1-139

Build results:
total: 126 pass: 122 skipped: 4 fail: 0

qemu tests all passed.

Results are as expected.

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

Guenter

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

Re: [PATCH 3.12 000/133] 3.12.10-stable review

[Guenter Roeck]

On 02/04/2014 01:06 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 3.12.10 release.
There are 133 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Thu Feb  6 21:07:17 UTC 2014.
Anything received after that time might be too late.




Version tested: v3.12.9-132

Build results:
total: 126 pass: 121 skipped: 5 fail: 0

qemu tests all passed.

Results are as expected.

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

Guenter


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

Re: [PATCH 3.10 000/104] 3.10.29-stable review

[Guenter Roeck]

On 02/04/2014 01:01 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 3.10.29 release.
There are 104 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Thu Feb  6 21:02:03 UTC 2014.
Anything received after that time might be too late.



Version tested: v3.10.28-103

Build results:
total: total: 126 pass: 121 skipped: 4 fail: 1

qemu tests all passed.

Results are as expected.

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

Guenter



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

Re: [PATCH 3.4 00/37] 3.4.79-stable review

[Guenter Roeck]

On 02/04/2014 01:00 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 3.4.79 release.
There are 37 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Thu Feb  6 21:00:31 UTC 2014.
Anything received after that time might be too late.


Version tested: v3.4.78-36

Build results:
total: 119 pass: 97 skipped: 18 fail: 4

qemu tests all passed.

Results are as expected.

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

Guenter


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

Re: [PATCH] slub: fix false-positive lockdep warning in free_partial()

[Vladimir Davydov]

On 02/05/2014 04:57 AM, David Rientjes wrote:
> On Tue, 4 Feb 2014, Christoph Lameter wrote:
>
>>> Although this cannot actually result in a race, because on cache
>>> destruction there should not be any concurrent frees or allocations from
>>> the cache, let's add spin_lock/unlock to free_partial() just to keep
>>> lockdep happy.
>> Please add a comment that says this in the source so we know why this was
>> added.
>>
> Makes sense since there is a comment there already saying we don't need 
> the lock, then with this patch we end up taking it away.  The nice thing 
> is that there should be no lock contention here :)
>
> I'm not sure we need to disable irqs as in the patch, though.

I'm afraid we need:

=
[ INFO: inconsistent lock state ]
3.14.0-rc1-mm1+ #4 Tainted: GW  
-
inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
modprobe/2760 [HC0[0]:SC0[0]:HE1:SE1] takes:
 (&(>list_lock)->rlock){?.-...}, at: []
__kmem_cache_shutdown+0x68/0x210
{IN-HARDIRQ-W} state was registered at:
  [] __lock_acquire+0x8f1/0x17f0
  [] lock_acquire+0x92/0x120
  [] _raw_spin_lock+0x39/0x70
  [] deactivate_slab+0x26b/0x500
  [] flush_cpu_slab+0x3c/0x70
  [] generic_smp_call_function_single_interrupt+0x52/0xb0
  [] smp_call_function_single_interrupt+0x22/0x40
  [] call_function_single_interrupt+0x72/0x80
  [] default_idle+0x1f/0xe0
  [] arch_cpu_idle+0x26/0x30
  [] cpu_startup_entry+0xa6/0x290
  [] start_secondary+0x1d9/0x290
irq event stamp: 3883
hardirqs last  enabled at (3883): []
mutex_lock_nested+0x2af/0x3d0
hardirqs last disabled at (3882): []
mutex_lock_nested+0x9f/0x3d0
softirqs last  enabled at (3866): []
__do_softirq+0x1f2/0x330
softirqs last disabled at (3851): [] irq_exit+0xd5/0xe0

other info that might help us debug this:
 Possible unsafe locking scenario:

   CPU0
   
  lock(&(>list_lock)->rlock);
  
lock(&(>list_lock)->rlock);

 *** DEADLOCK ***

1 lock held by modprobe/2760:
 #0:  (slab_mutex){+.+.+.}, at: []
kmem_cache_destroy+0x22/0xf0

stack backtrace:
CPU: 0 PID: 2760 Comm: modprobe Tainted: GW3.14.0-rc1-mm1+ #4
Hardware name:
 82295780 88003af89c18 816d9633 0002
 88007b2b 88003af89c68 810d1001 
 0001 0001 822957e8 88007b2b0840
Call Trace:
 [] dump_stack+0x51/0x6e
 [] print_usage_bug+0x231/0x290
 [] mark_lock+0x37f/0x420
 [] __lock_acquire+0x789/0x17f0
 [] ? wait_for_completion+0x5b/0x120
 [] ? cpumask_next_and+0x23/0x40
 [] ? slab_cpuup_callback+0x120/0x120
 [] ? smp_call_function_many+0x5c/0x250
 [] ? __kmem_cache_shutdown+0x68/0x210
 [] lock_acquire+0x92/0x120
 [] ? __kmem_cache_shutdown+0x68/0x210
 [] ? set_page_slub_counters+0x40/0x40
 [] _raw_spin_lock+0x39/0x70
 [] ? __kmem_cache_shutdown+0x68/0x210
 [] __kmem_cache_shutdown+0x68/0x210
 [] kmem_cache_destroy+0x43/0xf0
 [] xfs_qm_exit+0x15/0x30 [xfs]
 [] exit_xfs_fs+0x9/0x4e4 [xfs]
 [] SyS_delete_module+0x19a/0x1f0
 [] ? retint_swapgs+0x13/0x1b
 [] ? trace_hardirqs_on_caller+0x105/0x1d0
 [] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [] system_call_fastpath+0x16/0x1b
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] perf tools: Handle PERF_RECORD_HEADER_EVENT_TYPE properly

[Ingo Molnar]

* Jiri Olsa  wrote:

> We removed event types from data file in following commits:
>   6065210 perf tools: Remove event types framework completely
>   44b3c57 perf tools: Remove event types from perf data file
> 
> We no longer need this information, because we can get it
> directly from tracepoints.
> 
> But we still need to handle PERF_RECORD_HEADER_EVENT_TYPE
> event for the sake of old perf data files created in pipe
> mode like:
> 
>   $ perf.3.4 record -o - foo >perf.data
>   $ perf.312 report -i - < perf.data
> 
> Reported-by: Stephane Eranian 
> Signed-off-by: Jiri Olsa 
> Cc: Corey Ashford 
> Cc: Frederic Weisbecker 
> Cc: Ingo Molnar 
> Cc: Namhyung Kim 
> Cc: Paul Mackerras 
> Cc: Peter Zijlstra 
> Cc: Arnaldo Carvalho de Melo 
> Cc: David Ahern 
> ---
>  tools/perf/util/session.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
> index 0b39a48..5da6ce7 100644
> --- a/tools/perf/util/session.c
> +++ b/tools/perf/util/session.c
> @@ -1008,6 +1008,12 @@ static int perf_session__process_user_event(struct 
> perf_session *session, union
>   if (err == 0)
>   perf_session__set_id_hdr_size(session);
>   return err;
> + case PERF_RECORD_HEADER_EVENT_TYPE:
> + /*
> +  * Depreceated, but we need to handle it for sake
> +  * of old data files create in pipe mode.
> +  */

Two small speling nits:

 s/Depreceated
  /Deprecated

 s/create
  /created

Ack otherwise.

Thanks,

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

[PATCH] x86: Disable CONFIG_X86_DECODER_SELFTEST in allmod/allyesconfigs

[Ingo Molnar]

* Linus Torvalds  wrote:

> > BTW you probably also want to do the same for the x86 instruction 
> > decoder test. It seems to be the biggest compile time waster in 
> > allyesconfig and I usually disable it too.
> 
> Agreed, that should be disabled too by default. Although in that 
> case I think the COMPILE_TEST combination makes more sense, since 
> it's a coverage issue.

I'd say randconfig will cover it often enough, and the failure is also 
borderline build coverage related: you cannot really make the decoder 
test fail via source level changes, only with changes in the build 
environment, so I agree with Andi that we can disable this one too - 
via the patch below.

Thanks,

Ingo

Signed-off-by: Ingo Molnar 

diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index 0f3621e..f0fca39 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -184,6 +184,11 @@ config HAVE_MMIOTRACE_SUPPORT
 config X86_DECODER_SELFTEST
bool "x86 instruction decoder selftest"
depends on DEBUG_KERNEL && KPROBES
+   #
+   # It can take some time to validate the image,
+   # make sure {allyes|allmod}config doesn't enable it:
+   #
+   depends on !COMPILE_TEST
---help---
 Perform x86 instruction decoder selftests at build time.
 This option is useful for checking the sanity of x86 instruction
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[REVIEW PATCH] scsi: Add 'retry_timeout' to avoid infinite command retry

[Eiichi Tsukata]

Currently, scsi error handling in scsi_decide_disposition() tries to
unconditionally requeue scsi command when device keeps some error state.
This is because retryable errors are thought to be temporary and the scsi
device will soon recover from those errors. Normally, such retry policy is
appropriate because the device will soon recover from temporary error state.

But there is no guarantee that device is able to recover from error state
immediately. Some hardware error may prevent device from recovering.
Therefore hardware error can results in infinite command retry loop.

This patchs adds 'retry_timeout' sysfs attribute which limits the retry time
of each scsi command. Once scsi command retry time is longer than this timeout,
the command is treated as failure. 'retry_timeout' is set to '0' by default
which means no timeout set.

Signed-off-by: Eiichi Tsukata 
Cc: "James E.J. Bottomley" 
Cc: linux-s...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/scsi/scsi_lib.c| 22 +-
 drivers/scsi/scsi_scan.c   |  1 +
 drivers/scsi/scsi_sysfs.c  | 32 
 include/scsi/scsi.h|  1 +
 include/scsi/scsi_device.h |  1 +
 5 files changed, 56 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 7bd7f0d..a9db69e 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1492,6 +1492,23 @@ static void scsi_kill_request(struct request *req, 
struct request_queue *q)
blk_complete_request(req);
 }
 
+/*
+ * Check if scsi command excessed retry timeout
+ */
+static int scsi_retry_timed_out(struct scsi_cmnd *cmd)
+{
+   unsigned int retry_timeout;
+
+   retry_timeout = cmd->device->retry_timeout;
+   if (retry_timeout &&
+   time_before(cmd->jiffies_at_alloc + retry_timeout, jiffies)) {
+   scmd_printk(KERN_INFO, cmd, "retry timeout\n");
+   return 1;
+   }
+
+   return 0;
+}
+
 static void scsi_softirq_done(struct request *rq)
 {
struct scsi_cmnd *cmd = rq->special;
@@ -1512,7 +1529,10 @@ static void scsi_softirq_done(struct request *rq)
wait_for/HZ);
disposition = SUCCESS;
}
-   
+
+   if (scsi_retry_timed_out(cmd))
+   disposition = FAILED;
+
scsi_log_completion(cmd, disposition);
 
switch (disposition) {
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index 307a811..4ab044a 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -925,6 +925,7 @@ static int scsi_add_lun(struct scsi_device *sdev, unsigned 
char *inq_result,
sdev->no_dif = 1;
 
sdev->eh_timeout = SCSI_DEFAULT_EH_TIMEOUT;
+   sdev->retry_timeout = SCSI_DEFAULT_RETRY_TIMEOUT;
 
if (*bflags & BLIST_SKIP_VPD_PAGES)
sdev->skip_vpd_pages = 1;
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 8ff62c2..eaa2118 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -627,6 +627,37 @@ sdev_store_eh_timeout(struct device *dev, struct 
device_attribute *attr,
 static DEVICE_ATTR(eh_timeout, S_IRUGO | S_IWUSR, sdev_show_eh_timeout, 
sdev_store_eh_timeout);
 
 static ssize_t
+sdev_show_retry_timeout(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct scsi_device *sdev;
+   sdev = to_scsi_device(dev);
+   return snprintf(buf, 20, "%u\n", sdev->retry_timeout / HZ);
+}
+
+static ssize_t
+sdev_store_retry_timeout(struct device *dev, struct device_attribute *attr,
+const char *buf, size_t count)
+{
+   struct scsi_device *sdev;
+   unsigned int retry_timeout;
+   int err;
+
+   if (!capable(CAP_SYS_ADMIN))
+   return -EACCES;
+
+   sdev = to_scsi_device(dev);
+   err = kstrtouint(buf, 10, _timeout);
+   if (err)
+   return err;
+   sdev->retry_timeout = retry_timeout * HZ;
+
+   return count;
+}
+static DEVICE_ATTR(retry_timeout, S_IRUGO | S_IWUSR,
+  sdev_show_retry_timeout, sdev_store_retry_timeout);
+
+static ssize_t
 store_rescan_field (struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
 {
@@ -797,6 +828,7 @@ static struct attribute *scsi_sdev_attrs[] = {
_attr_state.attr,
_attr_timeout.attr,
_attr_eh_timeout.attr,
+   _attr_retry_timeout.attr,
_attr_iocounterbits.attr,
_attr_iorequest_cnt.attr,
_attr_iodone_cnt.attr,
diff --git a/include/scsi/scsi.h b/include/scsi/scsi.h
index 66d42ed..545408d 100644
--- a/include/scsi/scsi.h
+++ b/include/scsi/scsi.h
@@ -16,6 +16,7 @@ struct scsi_cmnd;
 
 enum scsi_timeouts {
SCSI_DEFAULT_EH_TIMEOUT = 10 * HZ,
+   SCSI_DEFAULT_RETRY_TIMEOUT  = 0,/* disabled by default */
 };
 
 /*
diff --git a/include/scsi/scsi_device.h 

Re: [PATCH] Clarify CONFIG_DEBUG_INFO's bloaty nature

[Ingo Molnar]

* Linus Torvalds  wrote:

> On Tue, Feb 4, 2014 at 1:08 AM, Ingo Molnar  wrote:
> >
> >  config SAVE_TIME_AND_DISK_SPACE
> > bool "Faster and leaner build object files: compile without debug 
> > info"
> > default y
> 
> Thinking about it, we already have this. It's called "CONFIG_COMPILE_TEST".
> 
> It very much gets set by all{yes,mod}config, and it also says "we're
> interested in testing the compile, not so much running the result".
> 
> So let's just make the DEBUG_INFO depend on !COMPILE_TEST.
> 
> Trivial oneliner patch (independent of the discussion about improving
> the documentation), so I'll just apply it.
> 
> I can't imagine that this would be controversial:
> 
>config DEBUG_INFO
>   bool "Compile the kernel with debug info"
>   -   depends on DEBUG_KERNEL
>   +   depends on DEBUG_KERNEL && !COMPILE_TEST
>   help
> 
> Hm?

Fully agreed.

Thanks,

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

Re: [Intel-gfx] [PATCH v3 2/6] x86: Add Intel graphics stolen memory quirk for gen2 platforms

[Ingo Molnar]

* Daniel Vetter  wrote:

> On Tue, Feb 04, 2014 at 02:47:07PM +0200, Ville Syrjälä wrote:
> > Hi x86 folks,
> > 
> > Ping on getting the gen2 stolen memory early quirk patches into 
> > the x86 tree.
> > 
> > From our side Daniel and Chris both seemed happy with them, so I'd 
> > like to get them in at some point.
> 
> Yup, I think this is ready for 3.15. And since there's no direct 
> depency really between the i915 parts and the x86 early reserve 
> stuff they can go both in through relevant trees - i915 will simply 
> fail the stolen setup if the range isn't properly reserved.
> 
> A stable branch somewhere would be good though so that I can pull it 
> into our integration tree for testing.

Please post the x86 bits separately in a standalone series, if they 
can and should be applied standalone.

Thanks,

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

[PATCH 2/2] f2fs: fix f2fs_write_meta_page at no checkpoint status

[Jaegeuk Kim]

If f2fs entered errorneous checkpoint status, it should skip writing meta
pages instead of redirtying the pages out.
Otherwise, it cannot unmount the partition even though f2fs is under read-only
status.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/checkpoint.c | 29 +
 fs/f2fs/gc.c |  2 ++
 2 files changed, 23 insertions(+), 8 deletions(-)

diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 293d048..8f5dff1 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -81,17 +81,18 @@ static int f2fs_write_meta_page(struct page *page,
struct inode *inode = page->mapping->host;
struct f2fs_sb_info *sbi = F2FS_SB(inode->i_sb);
 
-   /* Should not write any meta pages, if any IO error was occurred */
-   if (unlikely(sbi->por_doing ||
-   is_set_ckpt_flags(F2FS_CKPT(sbi), CP_ERROR_FLAG)))
+   if (unlikely(sbi->por_doing))
goto redirty_out;
-
if (wbc->for_reclaim)
goto redirty_out;
 
-   wait_on_page_writeback(page);
+   /* Should not write any meta pages, if any IO error was occurred */
+   if (unlikely(is_set_ckpt_flags(F2FS_CKPT(sbi), CP_ERROR_FLAG)))
+   goto no_write;
 
+   wait_on_page_writeback(page);
write_meta_page(sbi, page);
+no_write:
dec_page_count(sbi, F2FS_DIRTY_META);
unlock_page(page);
return 0;
@@ -148,10 +149,22 @@ long sync_meta_pages(struct f2fs_sb_info *sbi, enum 
page_type type,
 
for (i = 0; i < nr_pages; i++) {
struct page *page = pvec.pages[i];
+
lock_page(page);
-   f2fs_bug_on(page->mapping != mapping);
-   f2fs_bug_on(!PageDirty(page));
-   clear_page_dirty_for_io(page);
+
+   if (unlikely(page->mapping != mapping)) {
+continue_unlock:
+   unlock_page(page);
+   continue;
+   }
+   if (!PageDirty(page)) {
+   /* someone wrote it for us */
+   goto continue_unlock;
+   }
+
+   if (!clear_page_dirty_for_io(page))
+   goto continue_unlock;
+
if (f2fs_write_meta_page(page, )) {
unlock_page(page);
break;
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index ea0371e..b0f5762 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -701,6 +701,8 @@ int f2fs_gc(struct f2fs_sb_info *sbi)
 gc_more:
if (unlikely(!(sbi->sb->s_flags & MS_ACTIVE)))
goto stop;
+   if (unlikely(is_set_ckpt_flags(F2FS_CKPT(sbi), CP_ERROR_FLAG)))
+   goto stop;
 
if (gc_type == BG_GC && has_not_enough_free_secs(sbi, nfree)) {
gc_type = FG_GC;
-- 
1.8.4.474.g128a96c

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

[PATCH 1/2] f2fs: fix to truncate dentry pages in the error case

[Jaegeuk Kim]

When a new directory is allocated, if an error is occurred, we should truncate
preallocated dentry pages too.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/dir.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index bfcb4ae..daea906c 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -372,6 +372,8 @@ static struct page *init_inode_metadata(struct inode *inode,
 
 put_error:
f2fs_put_page(page, 1);
+   if (S_ISDIR(inode->i_mode))
+   truncate_blocks(inode, 0);
 error:
remove_inode_page(inode);
return ERR_PTR(err);
-- 
1.8.4.474.g128a96c

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

Re: [PATCH v4 1/2] iio:as3935: Add DT binding docs for AS3935 driver

[Matt Ranostay]

On Tue, Feb 4, 2014 at 9:17 PM, Matt Porter  wrote:
> On Tue, Feb 04, 2014 at 08:52:26PM -0800, Matt Ranostay Matt Ranostay wrote:
>> On Tue, Feb 4, 2014 at 8:43 PM, Matt Porter  wrote:
>> > On Tue, Feb 04, 2014 at 07:14:55PM -0800, Matt Ranostay Matt Ranostay 
>> > wrote:
>> >> Document compatible string, required and optional DT properties for
>> >> AS3935 chipset driver.
>> >>
>> >> Signed-off-by: Matt Ranostay 
>> >> ---
>> >>  .../devicetree/bindings/iio/proximity/as3935.txt   | 25 
>> >> ++
>> >>  1 file changed, 25 insertions(+)
>> >>  create mode 100644 
>> >> Documentation/devicetree/bindings/iio/proximity/as3935.txt
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/iio/proximity/as3935.txt 
>> >> b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
>> >> new file mode 100644
>> >> index 000..7e117cd
>> >> --- /dev/null
>> >> +++ b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
>> >> @@ -0,0 +1,25 @@
>> >> +Austrian Microsystems AS3935 Franklin lightning sensor device driver
>> >> +
>> >> +Required properties:
>> >> + - compatible: must be "ams,as3935"
>> >
>> > Change this to "amstaos,as3935"
>> >
>> > amstaos (AMS bought Taos) is already a registered vendor prefix in
>> > vendor-prefixes.txt
>> >
>> >> + - reg: SPI chip select number for the device
>> >> + - spi-cpha: SPI Mode 1
>> >
>> > When using generic binding properties, please reference the binding
>> > being used. Like:
>> >
>> > - spi-cpha: SPI Mode 1. Refer to spi/spi-bus.txt for generic SPI
>> >   slave node bindings.
>> >
>> Noted.
>>
>> >> + - interrupt-parent : should be the phandle for the interrupt 
>> >> controller
>> >> + - interrupts : interrupt mapping for GPIO IRQ
>> >
>> > Refer to interrupt-controller/interrupts.txt for generic
>> > interrupt client node bindings.
>> >
>> Noted.
>>
>> >> +
>> >> +Optional properties:
>> >> + - ams,tune-cap: Calibration tuning capacitor stepping value 0 - 15.
>> >> +   Range of 0 to 120 pF, 8pF steps. This will require using the
>> >> +   calibration data from the manufacturer.
>> >> +
>> >> +
>> >> +Example:
>> >> +
>> >> +as3935@0 {
>> >> + compatible = "ams,as3935";
>> >> + reg = <0>;
>> >> + spi-cpha;
>> >> + interrupt-parent = <>;
>> >> + interrupts = <16 1>;
>> >> + ams,tune-cap = /bits/ 8 <10>;
>> >
>> > What is this? Why not just ams,tune-cap = <10>; ?
>> >
>> > It's a value between 0-15, right?
>>
>> Correct but it is using of_property_read_u8() so that requires the
>> /bits/ statement.
>> Should this just be a u32 value?
>
> Do you really need a u8? If not just read_u32() into an int and keep
> this syntax simple.

Just me different it seems :P.  Will fix in next version waiting for
Peter's and Jonathan's input on the rest of the code first.

>
> -Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] include/linux/kprobes.h: move all functions to their matched area

[Chen Gang]

For dummy functions, it is not a good idea to still use the input
parameters (not a good idea to assume they are still effect).

 - let kprobe* static inline functions in CONFIG_KPROBES, dummy outside.

 - let (en/dis)able_jprobe() in CONFIG_KPROBES, dummy outside.

 - for kretprobe:

   - let kretprobe_assert() only in CONFIG_KRETPROBES (internal use).

   - remove kretprobe_inst_table_head() (cannot grep it in kernel wide).

   - for (en/dis)able_kretprobe():

   if CONFIG_KRETPROBES enabled, they use (en/dis)able_kprobe().
   else if CONFIG_KPROBES enabled, return -EINVAL (not registered).
   else, return -ENOSYS, just like (en/dis)able_kprobe() have done.


Signed-off-by: Chen Gang 
---
 include/linux/kprobes.h | 136 
 1 file changed, 92 insertions(+), 44 deletions(-)

diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h
index 925eaf2..860313d 100644
--- a/include/linux/kprobes.h
+++ b/include/linux/kprobes.h
@@ -129,30 +129,6 @@ struct kprobe {
   */
 #define KPROBE_FLAG_FTRACE 8 /* probe is using ftrace */
 
-/* Has this kprobe gone ? */
-static inline int kprobe_gone(struct kprobe *p)
-{
-   return p->flags & KPROBE_FLAG_GONE;
-}
-
-/* Is this kprobe disabled ? */
-static inline int kprobe_disabled(struct kprobe *p)
-{
-   return p->flags & (KPROBE_FLAG_DISABLED | KPROBE_FLAG_GONE);
-}
-
-/* Is this kprobe really running optimized path ? */
-static inline int kprobe_optimized(struct kprobe *p)
-{
-   return p->flags & KPROBE_FLAG_OPTIMIZED;
-}
-
-/* Is this kprobe uses ftrace ? */
-static inline int kprobe_ftrace(struct kprobe *p)
-{
-   return p->flags & KPROBE_FLAG_FTRACE;
-}
-
 /*
  * Special probe type that uses setjmp-longjmp type tricks to resume
  * execution at a specified entry with a matching prototype corresponding
@@ -223,7 +199,42 @@ static inline int kprobes_built_in(void)
return 1;
 }
 
+/* Has this kprobe gone ? */
+static inline int kprobe_gone(struct kprobe *p)
+{
+   return p->flags & KPROBE_FLAG_GONE;
+}
+
+/* Is this kprobe disabled ? */
+static inline int kprobe_disabled(struct kprobe *p)
+{
+   return p->flags & (KPROBE_FLAG_DISABLED | KPROBE_FLAG_GONE);
+}
+
+/* Is this kprobe really running optimized path ? */
+static inline int kprobe_optimized(struct kprobe *p)
+{
+   return p->flags & KPROBE_FLAG_OPTIMIZED;
+}
+
+/* Is this kprobe uses ftrace ? */
+static inline int kprobe_ftrace(struct kprobe *p)
+{
+   return p->flags & KPROBE_FLAG_FTRACE;
+}
+
 #ifdef CONFIG_KRETPROBES
+static inline void kretprobe_assert(struct kretprobe_instance *ri,
+   unsigned long orig_ret_address, unsigned long trampoline_address)
+{
+   if (!orig_ret_address || (orig_ret_address == trampoline_address)) {
+   printk(KERN_ERR
+   "kretprobe BUG!: Processing kretprobe %p @ %p\n",
+   ri->rp, ri->rp->kp.addr);
+   BUG();
+   }
+}
+
 extern void arch_prepare_kretprobe(struct kretprobe_instance *ri,
   struct pt_regs *regs);
 extern int arch_trampoline_kprobe(struct kprobe *p);
@@ -240,16 +251,6 @@ static inline int arch_trampoline_kprobe(struct kprobe *p)
 
 extern struct kretprobe_blackpoint kretprobe_blacklist[];
 
-static inline void kretprobe_assert(struct kretprobe_instance *ri,
-   unsigned long orig_ret_address, unsigned long trampoline_address)
-{
-   if (!orig_ret_address || (orig_ret_address == trampoline_address)) {
-   printk("kretprobe BUG!: Processing kretprobe %p @ %p\n",
-   ri->rp, ri->rp->kp.addr);
-   BUG();
-   }
-}
-
 #ifdef CONFIG_KPROBES_SANITY_TEST
 extern int init_test_probes(void);
 #else
@@ -340,7 +341,6 @@ struct kprobe *get_kprobe(void *addr);
 void kretprobe_hash_lock(struct task_struct *tsk,
 struct hlist_head **head, unsigned long *flags);
 void kretprobe_hash_unlock(struct task_struct *tsk, unsigned long *flags);
-struct hlist_head * kretprobe_inst_table_head(struct task_struct *tsk);
 
 /* kprobe_running() will just return the current_kprobe on this CPU */
 static inline struct kprobe *kprobe_running(void)
@@ -384,12 +384,60 @@ int enable_kprobe(struct kprobe *kp);
 
 void dump_kprobe(struct kprobe *kp);
 
+static inline int disable_jprobe(struct jprobe *jp)
+{
+   return disable_kprobe(>kp);
+}
+
+static inline int enable_jprobe(struct jprobe *jp)
+{
+   return enable_kprobe(>kp);
+}
+
+#ifdef CONFIG_KRETPROBES
+static inline int disable_kretprobe(struct kretprobe *rp)
+{
+   return disable_kprobe(>kp);
+}
+
+static inline int enable_kretprobe(struct kretprobe *rp)
+{
+   return enable_kprobe(>kp);
+}
+
+#else /* CONFIG_KRETPROBES */
+static inline int disable_kretprobe(struct kretprobe *rp)
+{
+   return -EINVAL;
+}
+static inline int enable_kretprobe(struct kretprobe *rp)
+{
+   return -EINVAL;
+}

[PATCH -tip ] [BUGFIX/URGENT] perf-probe: Do not add offset to uprobe address

[Masami Hiramatsu]

Fix perf-probe not to add offset value to uprobe probe
address when post processing.
tevs[i].point.address is the address of symbol+offset,
but current perf-probe adjusts the point.address by
adding the offset. As a result, the probe address becomes
symbol+offset+offset. This may cause unexpected
code corruption. Urgent fix is needed.

Without this fix
  ---
  # ./perf probe -x ./perf dso__load_vmlinux+4
  # ./perf probe -l
probe_perf:dso__load_vmlinux (on 0x0006d2b8)
  # nm ./perf.orig | grep dso__load_vmlinux\$
  0046d0a0 T dso__load_vmlinux
  ---
You can see the given offset is 3 but the actual probed
address is dso__load_vmlinux+8.

With this fix
  ---
  # ./perf probe -x ./perf dso__load_vmlinux+4
  # ./perf probe -l
probe_perf:dso__load_vmlinux (on 0x0006d2b4)
  ---
Now the problem is fixed.

Note: This bug is introduced by
commit fb7345bbf7fad9bf72ef63a19c707970b9685812

Signed-off-by: Masami Hiramatsu 
---
 tools/perf/util/probe-event.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index a8a9b6c..d8b048c 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -336,8 +336,8 @@ static int add_exec_to_probe_trace_events(struct 
probe_trace_event *tevs,
return ret;
 
for (i = 0; i < ntevs && ret >= 0; i++) {
+   /* point.address is the addres of point.symbol + point.offset */
offset = tevs[i].point.address - stext;
-   offset += tevs[i].point.offset;
tevs[i].point.offset = 0;
zfree([i].point.symbol);
ret = e_snprintf(buf, 32, "0x%lx", offset);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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/2] iio:as3935: Add DT binding docs for AS3935 driver

[Matt Porter]

On Tue, Feb 04, 2014 at 08:52:26PM -0800, Matt Ranostay Matt Ranostay wrote:
> On Tue, Feb 4, 2014 at 8:43 PM, Matt Porter  wrote:
> > On Tue, Feb 04, 2014 at 07:14:55PM -0800, Matt Ranostay Matt Ranostay wrote:
> >> Document compatible string, required and optional DT properties for
> >> AS3935 chipset driver.
> >>
> >> Signed-off-by: Matt Ranostay 
> >> ---
> >>  .../devicetree/bindings/iio/proximity/as3935.txt   | 25 
> >> ++
> >>  1 file changed, 25 insertions(+)
> >>  create mode 100644 
> >> Documentation/devicetree/bindings/iio/proximity/as3935.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/iio/proximity/as3935.txt 
> >> b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
> >> new file mode 100644
> >> index 000..7e117cd
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
> >> @@ -0,0 +1,25 @@
> >> +Austrian Microsystems AS3935 Franklin lightning sensor device driver
> >> +
> >> +Required properties:
> >> + - compatible: must be "ams,as3935"
> >
> > Change this to "amstaos,as3935"
> >
> > amstaos (AMS bought Taos) is already a registered vendor prefix in
> > vendor-prefixes.txt
> >
> >> + - reg: SPI chip select number for the device
> >> + - spi-cpha: SPI Mode 1
> >
> > When using generic binding properties, please reference the binding
> > being used. Like:
> >
> > - spi-cpha: SPI Mode 1. Refer to spi/spi-bus.txt for generic SPI
> >   slave node bindings.
> >
> Noted.
> 
> >> + - interrupt-parent : should be the phandle for the interrupt 
> >> controller
> >> + - interrupts : interrupt mapping for GPIO IRQ
> >
> > Refer to interrupt-controller/interrupts.txt for generic
> > interrupt client node bindings.
> >
> Noted.
> 
> >> +
> >> +Optional properties:
> >> + - ams,tune-cap: Calibration tuning capacitor stepping value 0 - 15.
> >> +   Range of 0 to 120 pF, 8pF steps. This will require using the
> >> +   calibration data from the manufacturer.
> >> +
> >> +
> >> +Example:
> >> +
> >> +as3935@0 {
> >> + compatible = "ams,as3935";
> >> + reg = <0>;
> >> + spi-cpha;
> >> + interrupt-parent = <>;
> >> + interrupts = <16 1>;
> >> + ams,tune-cap = /bits/ 8 <10>;
> >
> > What is this? Why not just ams,tune-cap = <10>; ?
> >
> > It's a value between 0-15, right?
> 
> Correct but it is using of_property_read_u8() so that requires the
> /bits/ statement.
> Should this just be a u32 value?

Do you really need a u8? If not just read_u32() into an int and keep
this syntax simple.

-Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] kernel: kprobe: move all *kretprobe* generic implementation to CONFIG_KRETPROBES enabled area

[Chen Gang]

On 02/05/2014 12:57 PM, Masami Hiramatsu wrote:
> (2014/02/05 12:08), Chen Gang wrote:
> Anyway, I don't think those inlined functions to be changed, because
> most of them are internal functions. If CONFIG_KRETPROBES=n, it just
> be ignored.
>

 In original implementation, if CONFIG_KRETPROBES=n, kretprobe_assert(),
 disable_kretprobe(), and enable_kretprobe() are not ignored.
>>>
>>> Really? where are they called? I mean, those functions do not have
>>> any instance unless your module uses it (but that is not what the kernel
>>> itself should help).
>>>
>>
>> If what you said correct (I guess so), for me, we still need let them in
>> CONFIG_KRETPROBES area, and without any dummy outside, just like another
>> *kprobe* static inline functions have done in "include/linux/kprobes.h".
>
> kretprobe_assert() is only for the internal check. So we don't need to 
> care
> about, and disable/enable_kretprobe() are anyway returns -EINVAL because
> kretprobe can not be registered. And all of them are inlined functions.
> In that case, we don't need to care about it.

 Hmm... it is related with code 'consistency':

  - these static inline functions are kretprobe generic implementation,
and we are trying to let all kretprobe generic implementation within
CONFIG_KRETPROBES area.
>>>
>>> No, actually, kretprobe is just built on the kprobe. 
>>> enable/disable_kretprobe
>>> just wrapped the kprobe methods. And kretprobe_assert() is just for 
>>> kretprobe
>>> internal use. that is not an API. Moving only the kretprobe_assert() into 
>>> the
>>> CONFIG_KRETPROBE area is not bad, but since it is just a static inline 
>>> function,
>>> if there is no caller, it just be ignored, no side effect.
>>>
>>
>> OK, I can understand.
>>
>> And do you mean enable/disable_kretprobe() are API? if so, we have to
>> implement them whether CONFIG_KRETPROBES enabled or disabled.
>>
>> And when CONFIG_KRETPROBES=n, just like what you originally said: we
>> need returns -EINVAL directly (either, I am not quite sure whether the
>> input parameter will be NULL, in this case).
> 
> Both are API, and when implementing it I had also considered that, but
> I decided to stay it in inline-function wrapper. The reason why is,
> that enable/disable_k*probe require the registered k*probes. If the
> kernel hacker uses those functions, they must ensure registering his
> k*probes, otherwise it does not work correctly. If the CONFIG_KRETPROBES=n,
> register_kretprobe() always fails, this means that the code has
> no chance to call those functions (it must be).
>

OK, thank you for your explanations.


  - And original kprobe static inline functions have done like that,
in same header file, if no obvious reasons, we can try to follow.
>>>
>>> It is no reasons to follow that too. Please keep your patch simple as much
>>> as possible.
>>>
>>
>> "keep our patch simple as much as posssible" sounds reasonable to me.
>> After skip "include/linux/kprobe.h", our patch's subject (include
>> comments) also need be changed (I will/should change it).
>>
>> For me, "include/linux/kprobe.h" can also be improved, but it can be
>> another patch for it (not only for kretprobe, but also for jpobe).
> 
> if that "improvement" means "simplify", it is acceptable. Now I don't like
> ifdefs of CONFIG_KPROBES and dummy functions, since if CONFIG_KPROBES=n,
> other kernel modules can also check the kconfig and decide what they do
> (or don't).
> Perhaps, what we've really needed is "just enough able to compile",
> not the fully covered dummy APIs.
> 

Hmm... for me, I still try to send a patch for "include/linux/kprobe.h".

For API (although it is kernel internal API), I have a hobby to try to
let it 'beautiful' as much as possible.


> I just concerned that it is a waste of memory if there are useless 
> kretprobe
> related instances are built when CONFIG_KRETPROBES=n.
>

 Yeah, that is also one of reason (3rd reason).


 And if necessary, please help check what we have done whether already
 "let all kretprobe generic implementation within CONFIG_KRETPROBES area"
 (exclude declaration, struct/union definition, and architecture
 implementation).
>>>
>>> As I commented, your changes in kernel/kprobes.c are good to me except
>>> two functions. That's all what we need to fix :)
>>>
>>
>> I will send a patch for it (since subject changed, we need not mark
>> "patch v2"), thanks.  :-)
> 
> OK, I'll review that.
> 

Thanks.

> Thank you!
> 
> 

Thanks.
-- 
Chen Gang

Open, share and attitude like air, water and life which God blessed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] clk: respect the clock dependencies in of_clk_init

[Jason Cooper]

Mike,

On Tue, Feb 04, 2014 at 11:59:26PM +0100, Gregory CLEMENT wrote:
> Until now the clock providers were initialized in the order found in
> the device tree. This led to have the dependencies between the clocks
> not respected: children clocks could be initialized before their
> parent clocks.
> 
> Instead of forcing each platform to manage its own initialization order,
> this patch adds this work inside the framework itself.
> 
> Using the data of the device tree the of_clk_init function now delayed
> the initialization of a clock provider if its parent provider was not
> ready yet.
> 
> Signed-off-by: Gregory CLEMENT 
> ---
> Mike,
> 
> this patch could solve the issues we get on severals mvebu platform
> since 3.14-rc1. This is an alternate solution of the patch set sent by
> Sebastian. However as it modifies the clock framework itself, it is
> more sensible.
> 
> I find this solution more elegant than changing the order of the
> initialization of the clock at the platform level. However as it
> should be tested on more platforms that only the mvebu ones, it would
> take some time, and I don't want to still have "broken" platform
> during more release candidate. So at the end this patch should be part
> of the 3.15 kernel.

If we can get a response from Mike, I'd prefer to go with this approach
and let it bake in -next for a while.  Hopefully, we could get it in
before -rc4...

thx,

Jason.

>  drivers/clk/clk.c | 94 
> +--
>  1 file changed, 91 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 5517944495d8..beb0f8b0c2a0 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -2526,24 +2526,112 @@ const char *of_clk_get_parent_name(struct 
> device_node *np, int index)
>  }
>  EXPORT_SYMBOL_GPL(of_clk_get_parent_name);
>  
> +struct clock_provider {
> + of_clk_init_cb_t clk_init_cb;
> + struct device_node *np;
> + struct list_head node;
> +};
> +
> +static LIST_HEAD(clk_provider_list);
> +
> +/*
> + * This function looks for a parent clock. If there is one, then it
> + * checks that the provider for this parent clock was initialized, in
> + * this case the parent clock will be ready.
> + */
> +static int parent_ready(struct device_node *np)
> +{
> + struct of_phandle_args clkspec;
> + struct of_clk_provider *provider;
> +
> + /*
> +  * If there is no clock parent, no need to wait for them, then
> +  * we can consider their absence as being ready
> +  */
> + if (of_parse_phandle_with_args(np, "clocks", "#clock-cells", 0,
> + ))
> + return 1;
> +
> + /* Check if we have such a provider in our array */
> + list_for_each_entry(provider, _clk_providers, link) {
> + if (provider->node == clkspec.np)
> + return 1;
> + }
> +
> + return 0;
> +}
> +
>  /**
>   * of_clk_init() - Scan and init clock providers from the DT
>   * @matches: array of compatible values and init functions for providers.
>   *
> - * This function scans the device tree for matching clock providers and
> - * calls their initialization functions
> + * This function scans the device tree for matching clock providers
> + * and calls their initialization functions. It also do it by trying
> + * to follow the dependencies.
>   */
>  void __init of_clk_init(const struct of_device_id *matches)
>  {
>   const struct of_device_id *match;
>   struct device_node *np;
> + struct clock_provider *clk_provider, *next;
> + bool is_init_done;
>  
>   if (!matches)
>   matches = &__clk_of_table;
>  
>   for_each_matching_node_and_match(np, matches, ) {
>   of_clk_init_cb_t clk_init_cb = match->data;
> - clk_init_cb(np);
> +
> +
> + if (parent_ready(np)) {
> + /*
> +  * The parent clock is ready or there is no
> +  * clock parent at all, in this case the
> +  * provider can be initialize immediately.
> +  */
> + clk_init_cb(np);
> + } else {
> + /*
> +  * The parent clock is not ready, this
> +  * provider is moved to a list to be
> +  * initialized later
> +  */
> + struct clock_provider *parent = kzalloc(sizeof(struct 
> clock_provider),
> + GFP_KERNEL);
> +
> + parent->clk_init_cb = match->data;
> + parent->np = np;
> + list_add(>node, _provider_list);
> + }
> + }
> +
> + while (!list_empty(_provider_list)) {
> + is_init_done = false;
> + list_for_each_entry_safe(clk_provider, next,
> + _provider_list, node) {

Re: [PATCH] kernel/kprobes.c: move kretprobe implementation to CONFIG_KRETPROBES area

[Chen Gang]

On 02/05/2014 01:00 PM, Masami Hiramatsu wrote:
> (2014/02/05 12:36), Chen Gang wrote:
>> > When CONFIG_KRETPROBES disabled, kretprobe implementation are useless,
>> > so need move them to CONFIG_KPROBES area.
>> > 
>> >  - move all kretprobe* to CONFIG_KPROBES area and dummy outside.
>> >  - define kretprobe_flush_task() to let kprobe_flush_task() call.
>> >  - define init_kretprobes() to let init_kprobes() call.
>> > 
>> > 
> Looks good to me ;)
> 
> Acked-by: Masami Hiramatsu 
> 

Thank you very much !!

:-)


>> > Signed-off-by: Chen Gang 
>> > ---
>> >  kernel/kprobes.c | 323 
>> > +++
>> >  1 file changed, 181 insertions(+), 142 deletions(-)
>> > 
>> > diff --git a/kernel/kprobes.c b/kernel/kprobes.c
>> > index ceeadfc..0619536 100644
>> > --- a/kernel/kprobes.c
>> > +++ b/kernel/kprobes.c
>> > @@ -69,7 +69,6 @@
>> >  
>> >  static int kprobes_initialized;
>> >  static struct hlist_head kprobe_table[KPROBE_TABLE_SIZE];
>> > -static struct hlist_head kretprobe_inst_table[KPROBE_TABLE_SIZE];
>> >  
>> >  /* NOTE: change this value only with kprobe_mutex held */
>> >  static bool kprobes_all_disarmed;
>> > @@ -77,14 +76,6 @@ static bool kprobes_all_disarmed;
>> >  /* This protects kprobe_table and optimizing_list */
>> >  static DEFINE_MUTEX(kprobe_mutex);
>> >  static DEFINE_PER_CPU(struct kprobe *, kprobe_instance) = NULL;
>> > -static struct {
>> > -  raw_spinlock_t lock cacheline_aligned_in_smp;
>> > -} kretprobe_table_locks[KPROBE_TABLE_SIZE];
>> > -
>> > -static raw_spinlock_t *kretprobe_table_lock_ptr(unsigned long hash)
>> > -{
>> > -  return &(kretprobe_table_locks[hash].lock);
>> > -}
>> >  
>> >  /*
>> >   * Normally, functions that we'd want to prohibit kprobes in, are marked
>> > @@ -1079,125 +1070,6 @@ void __kprobes kprobes_inc_nmissed_count(struct 
>> > kprobe *p)
>> >return;
>> >  }
>> >  
>> > -void __kprobes recycle_rp_inst(struct kretprobe_instance *ri,
>> > -  struct hlist_head *head)
>> > -{
>> > -  struct kretprobe *rp = ri->rp;
>> > -
>> > -  /* remove rp inst off the rprobe_inst_table */
>> > -  hlist_del(>hlist);
>> > -  INIT_HLIST_NODE(>hlist);
>> > -  if (likely(rp)) {
>> > -  raw_spin_lock(>lock);
>> > -  hlist_add_head(>hlist, >free_instances);
>> > -  raw_spin_unlock(>lock);
>> > -  } else
>> > -  /* Unregistering */
>> > -  hlist_add_head(>hlist, head);
>> > -}
>> > -
>> > -void __kprobes kretprobe_hash_lock(struct task_struct *tsk,
>> > -   struct hlist_head **head, unsigned long *flags)
>> > -__acquires(hlist_lock)
>> > -{
>> > -  unsigned long hash = hash_ptr(tsk, KPROBE_HASH_BITS);
>> > -  raw_spinlock_t *hlist_lock;
>> > -
>> > -  *head = _inst_table[hash];
>> > -  hlist_lock = kretprobe_table_lock_ptr(hash);
>> > -  raw_spin_lock_irqsave(hlist_lock, *flags);
>> > -}
>> > -
>> > -static void __kprobes kretprobe_table_lock(unsigned long hash,
>> > -  unsigned long *flags)
>> > -__acquires(hlist_lock)
>> > -{
>> > -  raw_spinlock_t *hlist_lock = kretprobe_table_lock_ptr(hash);
>> > -  raw_spin_lock_irqsave(hlist_lock, *flags);
>> > -}
>> > -
>> > -void __kprobes kretprobe_hash_unlock(struct task_struct *tsk,
>> > -  unsigned long *flags)
>> > -__releases(hlist_lock)
>> > -{
>> > -  unsigned long hash = hash_ptr(tsk, KPROBE_HASH_BITS);
>> > -  raw_spinlock_t *hlist_lock;
>> > -
>> > -  hlist_lock = kretprobe_table_lock_ptr(hash);
>> > -  raw_spin_unlock_irqrestore(hlist_lock, *flags);
>> > -}
>> > -
>> > -static void __kprobes kretprobe_table_unlock(unsigned long hash,
>> > -   unsigned long *flags)
>> > -__releases(hlist_lock)
>> > -{
>> > -  raw_spinlock_t *hlist_lock = kretprobe_table_lock_ptr(hash);
>> > -  raw_spin_unlock_irqrestore(hlist_lock, *flags);
>> > -}
>> > -
>> > -/*
>> > - * This function is called from finish_task_switch when task tk becomes 
>> > dead,
>> > - * so that we can recycle any function-return probe instances associated
>> > - * with this task. These left over instances represent probed functions
>> > - * that have been called but will never return.
>> > - */
>> > -void __kprobes kprobe_flush_task(struct task_struct *tk)
>> > -{
>> > -  struct kretprobe_instance *ri;
>> > -  struct hlist_head *head, empty_rp;
>> > -  struct hlist_node *tmp;
>> > -  unsigned long hash, flags = 0;
>> > -
>> > -  if (unlikely(!kprobes_initialized))
>> > -  /* Early boot.  kretprobe_table_locks not yet initialized. */
>> > -  return;
>> > -
>> > -  INIT_HLIST_HEAD(_rp);
>> > -  hash = hash_ptr(tk, KPROBE_HASH_BITS);
>> > -  head = _inst_table[hash];
>> > -  kretprobe_table_lock(hash, );
>> > -  hlist_for_each_entry_safe(ri, tmp, head, hlist) {
>> > -  if (ri->task == tk)
>> > -  recycle_rp_inst(ri, _rp);
>> > -  }
>> > -  kretprobe_table_unlock(hash, );
>> > -  hlist_for_each_entry_safe(ri, tmp, _rp, hlist) {
>> > -  hlist_del(>hlist);
>> > -  kfree(ri);
>> > -  }

Re: [PATCH] backlight: add PWM dependencies

[Jingoo Han]

On Tuesday, February 04, 2014 9:57 PM, Linus Walleij wrote:
> 
> In some compilations the LM3630A and LP855X backlight drivers
> fail like this:
> 
> drivers/built-in.o: In function `lm3630a_pwm_ctrl':
> drivers/video/backlight/lm3630a_bl.c:168: undefined reference to `pwm_config'
> drivers/video/backlight/lm3630a_bl.c:172: undefined reference to `pwm_disable'
> drivers/video/backlight/lm3630a_bl.c:170: undefined reference to `pwm_enable'
> drivers/built-in.o: In function `lp855x_pwm_ctrl':
> drivers/video/backlight/lp855x_bl.c:249: undefined reference to `pwm_config'
> drivers/video/backlight/lp855x_bl.c:253: undefined reference to `pwm_disable'
> drivers/video/backlight/lp855x_bl.c:251: undefined reference to `pwm_enable'
> 
> This is because both drivers depend on the PWM framework, so
> add this dependency to their Kconfig entries.

However, even though, when CONFIG_PWM is not enabled, the problem
should not happen. pwm_config(),pwm_disable(), and pwm_enable()
are already defined for CONFIG_PWM=n case as below.

./include/linux/pwm.h
#if IS_ENABLED(CONFIG_PWM) || IS_ENABLED(CONFIG_HAVE_PWM)
.
#else
static inline struct pwm_device *pwm_request(int pwm_id, const char *label)
{
return ERR_PTR(-ENODEV);
}

static inline void pwm_free(struct pwm_device *pwm)
{
}

static inline int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns)
{
return -EINVAL;
}

static inline int pwm_enable(struct pwm_device *pwm)
{
return -EINVAL;
}

static inline void pwm_disable(struct pwm_device *pwm)
{
}
#endif

Is there 'drivers/pwm/core.o'?
I reproduced this problem by commenting core.o with CONFIG_PWM=y.

.config
CONFIG_PWM=y

./drivers/pwm/Makefile
@@ -1,4 +1,4 @@
-obj-$(CONFIG_PWM)  += core.o
+#obj-$(CONFIG_PWM) += core.o

In this case, the following build errors happen.
Even though, CONFIG_PWM is enabled, the same errors happen.
Would you give me the more detailed information?
Ex. how to reproduce the problem.

drivers/built-in.o: In function `lm3630a_pwm_ctrl':
drivers/video/backlight/lm3630a_bl.c:168: undefined reference to `pwm_config'
drivers/video/backlight/lm3630a_bl.c:172: undefined reference to `pwm_disable'
drivers/video/backlight/lm3630a_bl.c:170: undefined reference to `pwm_enable'
drivers/built-in.o: In function `lm3630a_probe':
drivers/video/backlight/lm3630a_bl.c:422: undefined reference to `devm_pwm_get'
drivers/built-in.o: In function `lp855x_pwm_ctrl':
drivers/video/backlight/lp855x_bl.c:249: undefined reference to `pwm_config'
drivers/video/backlight/lp855x_bl.c:253: undefined reference to `pwm_disable'
drivers/video/backlight/lp855x_bl.c:251: undefined reference to `pwm_enable'
drivers/video/backlight/lp855x_bl.c:242: undefined reference to `devm_pwm_get'

Thank you.

Best regards,
Jingoo Han

> 
> Signed-off-by: Linus Walleij 
> ---
>  drivers/video/backlight/Kconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
> index 5a3eb2ecb525..0604c3348761 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -371,6 +371,7 @@ config BACKLIGHT_AAT2870
>  config BACKLIGHT_LM3630A
>   tristate "Backlight Driver for LM3630A"
>   depends on BACKLIGHT_CLASS_DEVICE && I2C
> + depends on PWM
>   select REGMAP_I2C
>   help
> This supports TI LM3630A Backlight Driver
> @@ -387,6 +388,7 @@ config BACKLIGHT_LM3639
>  config BACKLIGHT_LP855X
>   tristate "Backlight driver for TI LP855X"
>   depends on BACKLIGHT_CLASS_DEVICE && I2C
> + depends on PWM
>   help
> This supports TI LP8550, LP8551, LP8552, LP8553, LP8555, LP8556 and
> LP8557 backlight driver.
> --
> 1.8.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] kernel/kprobes.c: move kretprobe implementation to CONFIG_KRETPROBES area

[Masami Hiramatsu]

(2014/02/05 12:36), Chen Gang wrote:
> When CONFIG_KRETPROBES disabled, kretprobe implementation are useless,
> so need move them to CONFIG_KPROBES area.
> 
>  - move all kretprobe* to CONFIG_KPROBES area and dummy outside.
>  - define kretprobe_flush_task() to let kprobe_flush_task() call.
>  - define init_kretprobes() to let init_kprobes() call.
> 
> 

Looks good to me ;)

Acked-by: Masami Hiramatsu 

> Signed-off-by: Chen Gang 
> ---
>  kernel/kprobes.c | 323 
> +++
>  1 file changed, 181 insertions(+), 142 deletions(-)
> 
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index ceeadfc..0619536 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -69,7 +69,6 @@
>  
>  static int kprobes_initialized;
>  static struct hlist_head kprobe_table[KPROBE_TABLE_SIZE];
> -static struct hlist_head kretprobe_inst_table[KPROBE_TABLE_SIZE];
>  
>  /* NOTE: change this value only with kprobe_mutex held */
>  static bool kprobes_all_disarmed;
> @@ -77,14 +76,6 @@ static bool kprobes_all_disarmed;
>  /* This protects kprobe_table and optimizing_list */
>  static DEFINE_MUTEX(kprobe_mutex);
>  static DEFINE_PER_CPU(struct kprobe *, kprobe_instance) = NULL;
> -static struct {
> - raw_spinlock_t lock cacheline_aligned_in_smp;
> -} kretprobe_table_locks[KPROBE_TABLE_SIZE];
> -
> -static raw_spinlock_t *kretprobe_table_lock_ptr(unsigned long hash)
> -{
> - return &(kretprobe_table_locks[hash].lock);
> -}
>  
>  /*
>   * Normally, functions that we'd want to prohibit kprobes in, are marked
> @@ -1079,125 +1070,6 @@ void __kprobes kprobes_inc_nmissed_count(struct 
> kprobe *p)
>   return;
>  }
>  
> -void __kprobes recycle_rp_inst(struct kretprobe_instance *ri,
> - struct hlist_head *head)
> -{
> - struct kretprobe *rp = ri->rp;
> -
> - /* remove rp inst off the rprobe_inst_table */
> - hlist_del(>hlist);
> - INIT_HLIST_NODE(>hlist);
> - if (likely(rp)) {
> - raw_spin_lock(>lock);
> - hlist_add_head(>hlist, >free_instances);
> - raw_spin_unlock(>lock);
> - } else
> - /* Unregistering */
> - hlist_add_head(>hlist, head);
> -}
> -
> -void __kprobes kretprobe_hash_lock(struct task_struct *tsk,
> -  struct hlist_head **head, unsigned long *flags)
> -__acquires(hlist_lock)
> -{
> - unsigned long hash = hash_ptr(tsk, KPROBE_HASH_BITS);
> - raw_spinlock_t *hlist_lock;
> -
> - *head = _inst_table[hash];
> - hlist_lock = kretprobe_table_lock_ptr(hash);
> - raw_spin_lock_irqsave(hlist_lock, *flags);
> -}
> -
> -static void __kprobes kretprobe_table_lock(unsigned long hash,
> - unsigned long *flags)
> -__acquires(hlist_lock)
> -{
> - raw_spinlock_t *hlist_lock = kretprobe_table_lock_ptr(hash);
> - raw_spin_lock_irqsave(hlist_lock, *flags);
> -}
> -
> -void __kprobes kretprobe_hash_unlock(struct task_struct *tsk,
> - unsigned long *flags)
> -__releases(hlist_lock)
> -{
> - unsigned long hash = hash_ptr(tsk, KPROBE_HASH_BITS);
> - raw_spinlock_t *hlist_lock;
> -
> - hlist_lock = kretprobe_table_lock_ptr(hash);
> - raw_spin_unlock_irqrestore(hlist_lock, *flags);
> -}
> -
> -static void __kprobes kretprobe_table_unlock(unsigned long hash,
> -   unsigned long *flags)
> -__releases(hlist_lock)
> -{
> - raw_spinlock_t *hlist_lock = kretprobe_table_lock_ptr(hash);
> - raw_spin_unlock_irqrestore(hlist_lock, *flags);
> -}
> -
> -/*
> - * This function is called from finish_task_switch when task tk becomes dead,
> - * so that we can recycle any function-return probe instances associated
> - * with this task. These left over instances represent probed functions
> - * that have been called but will never return.
> - */
> -void __kprobes kprobe_flush_task(struct task_struct *tk)
> -{
> - struct kretprobe_instance *ri;
> - struct hlist_head *head, empty_rp;
> - struct hlist_node *tmp;
> - unsigned long hash, flags = 0;
> -
> - if (unlikely(!kprobes_initialized))
> - /* Early boot.  kretprobe_table_locks not yet initialized. */
> - return;
> -
> - INIT_HLIST_HEAD(_rp);
> - hash = hash_ptr(tk, KPROBE_HASH_BITS);
> - head = _inst_table[hash];
> - kretprobe_table_lock(hash, );
> - hlist_for_each_entry_safe(ri, tmp, head, hlist) {
> - if (ri->task == tk)
> - recycle_rp_inst(ri, _rp);
> - }
> - kretprobe_table_unlock(hash, );
> - hlist_for_each_entry_safe(ri, tmp, _rp, hlist) {
> - hlist_del(>hlist);
> - kfree(ri);
> - }
> -}
> -
> -static inline void free_rp_inst(struct kretprobe *rp)
> -{
> - struct kretprobe_instance *ri;
> - struct hlist_node *next;
> -
> - hlist_for_each_entry_safe(ri, next, >free_instances, hlist) {
> - hlist_del(>hlist);
> - kfree(ri);
> - }
> -}
> -
> -static void __kprobes 

RE: [PATCH 01/22] be2iscsi: Use pci_enable_msix_range()

[Jayamohan Kallickal]

-Original Message-
From: Alexander Gordeev [mailto:agord...@redhat.com] 
Sent: Tuesday, February 04, 2014 3:17 AM
To: linux-kernel@vger.kernel.org
Cc: Alexander Gordeev; Jayamohan Kallickal; linux-s...@vger.kernel.org; 
linux-...@vger.kernel.org
Subject: [PATCH 01/22] be2iscsi: Use pci_enable_msix_range()

As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers using these two 
interfaces need to be updated to use the new pci_enable_msi_range() and 
pci_enable_msix_range() interfaces.

Signed-off-by: Alexander Gordeev 
Cc: Jayamohan Kallickal 
Cc: linux-s...@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/scsi/be2iscsi/be_main.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c 
index 1f37505..5878f3e 100644
--- a/drivers/scsi/be2iscsi/be_main.c
+++ b/drivers/scsi/be2iscsi/be_main.c
@@ -5284,9 +5284,9 @@ static void beiscsi_msix_enable(struct beiscsi_hba *phba)
for (i = 0; i <= phba->num_cpus; i++)
phba->msix_entries[i].entry = i;
 
-   status = pci_enable_msix(phba->pcidev, phba->msix_entries,
-(phba->num_cpus + 1));
-   if (!status)
+   status = pci_enable_msix_range(phba->pcidev, phba->msix_entries,
+  phba->num_cpus + 1, phba->num_cpus + 1);
+   if (status > 0)
phba->msix_enabled = true;
 
return;



Looks OK to me

Acked-by: Jayamohan Kallickal 

--

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] kernel: kprobe: move all *kretprobe* generic implementation to CONFIG_KRETPROBES enabled area

[Masami Hiramatsu]

(2014/02/05 12:08), Chen Gang wrote:
 Anyway, I don't think those inlined functions to be changed, because
 most of them are internal functions. If CONFIG_KRETPROBES=n, it just
 be ignored.

>>>
>>> In original implementation, if CONFIG_KRETPROBES=n, kretprobe_assert(),
>>> disable_kretprobe(), and enable_kretprobe() are not ignored.
>>
>> Really? where are they called? I mean, those functions do not have
>> any instance unless your module uses it (but that is not what the kernel
>> itself should help).
>>
>
> If what you said correct (I guess so), for me, we still need let them in
> CONFIG_KRETPROBES area, and without any dummy outside, just like another
> *kprobe* static inline functions have done in "include/linux/kprobes.h".

 kretprobe_assert() is only for the internal check. So we don't need to care
 about, and disable/enable_kretprobe() are anyway returns -EINVAL because
 kretprobe can not be registered. And all of them are inlined functions.
 In that case, we don't need to care about it.
>>>
>>> Hmm... it is related with code 'consistency':
>>>
>>>  - these static inline functions are kretprobe generic implementation,
>>>and we are trying to let all kretprobe generic implementation within
>>>CONFIG_KRETPROBES area.
>>
>> No, actually, kretprobe is just built on the kprobe. enable/disable_kretprobe
>> just wrapped the kprobe methods. And kretprobe_assert() is just for kretprobe
>> internal use. that is not an API. Moving only the kretprobe_assert() into the
>> CONFIG_KRETPROBE area is not bad, but since it is just a static inline 
>> function,
>> if there is no caller, it just be ignored, no side effect.
>>
> 
> OK, I can understand.
> 
> And do you mean enable/disable_kretprobe() are API? if so, we have to
> implement them whether CONFIG_KRETPROBES enabled or disabled.
> 
> And when CONFIG_KRETPROBES=n, just like what you originally said: we
> need returns -EINVAL directly (either, I am not quite sure whether the
> input parameter will be NULL, in this case).

Both are API, and when implementing it I had also considered that, but
I decided to stay it in inline-function wrapper. The reason why is,
that enable/disable_k*probe require the registered k*probes. If the
kernel hacker uses those functions, they must ensure registering his
k*probes, otherwise it does not work correctly. If the CONFIG_KRETPROBES=n,
register_kretprobe() always fails, this means that the code has
no chance to call those functions (it must be).

>>>  - And original kprobe static inline functions have done like that,
>>>in same header file, if no obvious reasons, we can try to follow.
>>
>> It is no reasons to follow that too. Please keep your patch simple as much
>> as possible.
>>
> 
> "keep our patch simple as much as posssible" sounds reasonable to me.
> After skip "include/linux/kprobe.h", our patch's subject (include
> comments) also need be changed (I will/should change it).
> 
> For me, "include/linux/kprobe.h" can also be improved, but it can be
> another patch for it (not only for kretprobe, but also for jpobe).

if that "improvement" means "simplify", it is acceptable. Now I don't like
ifdefs of CONFIG_KPROBES and dummy functions, since if CONFIG_KPROBES=n,
other kernel modules can also check the kconfig and decide what they do
(or don't).
Perhaps, what we've really needed is "just enough able to compile",
not the fully covered dummy APIs.

 I just concerned that it is a waste of memory if there are useless 
 kretprobe
 related instances are built when CONFIG_KRETPROBES=n.

>>>
>>> Yeah, that is also one of reason (3rd reason).
>>>
>>>
>>> And if necessary, please help check what we have done whether already
>>> "let all kretprobe generic implementation within CONFIG_KRETPROBES area"
>>> (exclude declaration, struct/union definition, and architecture
>>> implementation).
>>
>> As I commented, your changes in kernel/kprobes.c are good to me except
>> two functions. That's all what we need to fix :)
>>
> 
> I will send a patch for it (since subject changed, we need not mark
> "patch v2"), thanks.  :-)

OK, I'll review that.

Thank you!


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


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

Re: [PATCH 0/3] irqchip: orion: bridge irq fixes for v3.14-rc1

[Jason Cooper]

On Thu, Jan 23, 2014 at 11:38:03PM +0100, Sebastian Hesselbarth wrote:
> This is a small patch set to fix some shortcomings how Orion bridge
> irqs are handled. The patches are based on v3.13-rc8 and should go
> into v3.14. They can possibly also marked for -stable down to v3.10.
> 
> This patches are the result of a discussion about a stale watchdog irq,
> that can accidentially trigger the watchdog's irq handler and cause a
> reset [1].
> 
> The first patch will add a write to clear already pending interrupts
> on init. The second patch replaces handle_level_irq with handle_edge_irq
> which is more appropriate for bridge irqs which are edge-triggered.
> The last patch finally, fixes stale interrupts by installing an
> .irq_enable callback, that will clear a possible pending interrupt
> before unmasking it.
> 
> [1] http://www.spinics.net/lists/arm-kernel/msg302106.html
> 
> Sebastian Hesselbarth (3):
>   irqchip: orion: clear bridge cause register on init
>   irqchip: orion: use handle_edge_irq on bridge irqs
>   irqchip: orion: clear stale interrupts in irq_enable
> 
>  drivers/irqchip/irq-orion.c | 18 --
>  1 file changed, 16 insertions(+), 2 deletions(-)

Whole series applied to mvebu-next/irqchip-fixes (v2 for 3/3).  Once I
see that the outstanding pull requests for mvebu/irqchip have been
merged into mainline, I'll be changing the name of this branch to
mvebu/irqchip-fixes.  I just don't want to upset the applecart atm.

Oh yeah, Cc'd for stable back to v3.10.

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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/2] iio:as3935: Add DT binding docs for AS3935 driver

[Matt Ranostay]

On Tue, Feb 4, 2014 at 8:43 PM, Matt Porter  wrote:
> On Tue, Feb 04, 2014 at 07:14:55PM -0800, Matt Ranostay Matt Ranostay wrote:
>> Document compatible string, required and optional DT properties for
>> AS3935 chipset driver.
>>
>> Signed-off-by: Matt Ranostay 
>> ---
>>  .../devicetree/bindings/iio/proximity/as3935.txt   | 25 
>> ++
>>  1 file changed, 25 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/iio/proximity/as3935.txt
>>
>> diff --git a/Documentation/devicetree/bindings/iio/proximity/as3935.txt 
>> b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
>> new file mode 100644
>> index 000..7e117cd
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
>> @@ -0,0 +1,25 @@
>> +Austrian Microsystems AS3935 Franklin lightning sensor device driver
>> +
>> +Required properties:
>> + - compatible: must be "ams,as3935"
>
> Change this to "amstaos,as3935"
>
> amstaos (AMS bought Taos) is already a registered vendor prefix in
> vendor-prefixes.txt
>
>> + - reg: SPI chip select number for the device
>> + - spi-cpha: SPI Mode 1
>
> When using generic binding properties, please reference the binding
> being used. Like:
>
> - spi-cpha: SPI Mode 1. Refer to spi/spi-bus.txt for generic SPI
>   slave node bindings.
>
Noted.

>> + - interrupt-parent : should be the phandle for the interrupt controller
>> + - interrupts : interrupt mapping for GPIO IRQ
>
> Refer to interrupt-controller/interrupts.txt for generic
> interrupt client node bindings.
>
Noted.

>> +
>> +Optional properties:
>> + - ams,tune-cap: Calibration tuning capacitor stepping value 0 - 15.
>> +   Range of 0 to 120 pF, 8pF steps. This will require using the
>> +   calibration data from the manufacturer.
>> +
>> +
>> +Example:
>> +
>> +as3935@0 {
>> + compatible = "ams,as3935";
>> + reg = <0>;
>> + spi-cpha;
>> + interrupt-parent = <>;
>> + interrupts = <16 1>;
>> + ams,tune-cap = /bits/ 8 <10>;
>
> What is this? Why not just ams,tune-cap = <10>; ?
>
> It's a value between 0-15, right?

Correct but it is using of_property_read_u8() so that requires the
/bits/ statement.
Should this just be a u32 value?

>
> -Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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.14-rc1] cirrus driver problem (qemu)

[Dave Airlie]

On Wed, Feb 5, 2014 at 8:53 AM, Sabrina Dubroca  wrote:
> 2014-02-04, 13:20:54 +1000, Dave Airlie wrote:
>> On Tue, Feb 4, 2014 at 1:34 AM, Sabrina Dubroca  wrote:
>> > When I boot 3.14-rc1 in qemu, I get the trace below. The console stops
>> > updating and I don't get a login prompt. I can login, but I can't see
>> > what I'm doing. I can login normally via SSH.
>> >
>> > If I revert the last commit in drivers/gpu/drm/cirrus:
>> >
>> > f4b4718b61d1d5a7442a4fd6863ea80c3a10e508 drm: ast,cirrus,mgag200: use 
>> > drm_can_sleep
>> >
>> > the problem is solved.
>> >
>>
>> Hi does the attach patch fix it?
>>
>> Dave.
>
>
> Same problem. Didn't you reverse the logic on in_interrupt, compared
> to the old "if (!in_interrupt())" ? It looks like drm_can_sleep() is
> false when in_interrupt() is true.
>
> I modified your patch as below. Display doesn't freeze, but I still
> get the warning.

Oh wow I totally screwed up there, you are right, logic inversion.

Can you try the attached?

without the in_interrupt addition.

Dave.
From c39a8bdd2586c616e9b3746db128180d4e0ca8ec Mon Sep 17 00:00:00 2001
From: Dave Airlie 
Date: Wed, 5 Feb 2014 14:47:45 +1000
Subject: [PATCH] drm/mgag200,ast,cirrus: fix regression with drm_can_sleep
 conversion

I totally sign inverted my way out of this one.

Reported-by: "Sabrina Dubroca" 
Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/ast/ast_fb.c  | 2 +-
 drivers/gpu/drm/cirrus/cirrus_fbdev.c | 2 +-
 drivers/gpu/drm/mgag200/mgag200_fb.c  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index 3f65dd6..a28640f 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -65,7 +65,7 @@ static void ast_dirty_update(struct ast_fbdev *afbdev,
 	 * then the BO is being moved and we should
 	 * store up the damage until later.
 	 */
-	if (!drm_can_sleep())
+	if (drm_can_sleep())
 		ret = ast_bo_reserve(bo, true);
 	if (ret) {
 		if (ret != -EBUSY)
diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
index 2fd4a92..32bbba0 100644
--- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
+++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
@@ -39,7 +39,7 @@ static void cirrus_dirty_update(struct cirrus_fbdev *afbdev,
 	 * then the BO is being moved and we should
 	 * store up the damage until later.
 	 */
-	if (!drm_can_sleep())
+	if (drm_can_sleep())
 		ret = cirrus_bo_reserve(bo, true);
 	if (ret) {
 		if (ret != -EBUSY)
diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c b/drivers/gpu/drm/mgag200/mgag200_fb.c
index f9adc27..13b7dd8 100644
--- a/drivers/gpu/drm/mgag200/mgag200_fb.c
+++ b/drivers/gpu/drm/mgag200/mgag200_fb.c
@@ -41,7 +41,7 @@ static void mga_dirty_update(struct mga_fbdev *mfbdev,
 	 * then the BO is being moved and we should
 	 * store up the damage until later.
 	 */
-	if (!drm_can_sleep())
+	if (drm_can_sleep())
 		ret = mgag200_bo_reserve(bo, true);
 	if (ret) {
 		if (ret != -EBUSY)
-- 
1.8.4.2

Re: [PATCH v3 8/8] ARM: dts: sun7i: Add ethernet alias for GMAC

[Chen-Yu Tsai]

On Tue, Feb 4, 2014 at 3:38 AM, Maxime Ripard
 wrote:
> On Mon, Feb 03, 2014 at 11:32:26AM +0800, Chen-Yu Tsai wrote:
>> U-Boot will insert MAC address into the device tree image.
>> It looks up ethernet[0-5] aliases to find the ethernet nodes.
>> Alias GMAC as ethernet0, as it is the only ethernet controller used.
>>
>> Signed-off-by: Chen-Yu Tsai 
>> ---
>>  arch/arm/boot/dts/sun7i-a20.dtsi | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi 
>> b/arch/arm/boot/dts/sun7i-a20.dtsi
>> index 65fb8d0..c48fb11 100644
>> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
>> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
>> @@ -17,7 +17,7 @@
>>   interrupt-parent = <>;
>>
>>   aliases {
>> - ethernet0 = 
>> + ethernet0 = 
>>   };
>
> I'm not very fond of this patch.
>
> People might rely on the fact that ethernet0 is actually the emac, and
> are expecting u-boot to fill the ethaddr variable to the emac, and not
> the gmac.
>
> Since u-boot is totally able to deal with several ethernet addresses,
> please add it as ethernet1.

Actually I think we should override this in the board dts.
The boards we currently support can only use emac or gmac,
and in our u-boot tree, they have been converted to using
gmac. If any future boards support both emac and gmac, we
can address the ordering then. And the ordering should
match u-boot.

What do you think?


Cheers
ChenYu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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/2] iio:as3935: Add DT binding docs for AS3935 driver

[Matt Porter]

On Tue, Feb 04, 2014 at 07:14:55PM -0800, Matt Ranostay Matt Ranostay wrote:
> Document compatible string, required and optional DT properties for
> AS3935 chipset driver.
> 
> Signed-off-by: Matt Ranostay 
> ---
>  .../devicetree/bindings/iio/proximity/as3935.txt   | 25 
> ++
>  1 file changed, 25 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/proximity/as3935.txt
> 
> diff --git a/Documentation/devicetree/bindings/iio/proximity/as3935.txt 
> b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
> new file mode 100644
> index 000..7e117cd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
> @@ -0,0 +1,25 @@
> +Austrian Microsystems AS3935 Franklin lightning sensor device driver
> +
> +Required properties:
> + - compatible: must be "ams,as3935"

Change this to "amstaos,as3935"

amstaos (AMS bought Taos) is already a registered vendor prefix in
vendor-prefixes.txt

> + - reg: SPI chip select number for the device
> + - spi-cpha: SPI Mode 1

When using generic binding properties, please reference the binding
being used. Like:

- spi-cpha: SPI Mode 1. Refer to spi/spi-bus.txt for generic SPI
  slave node bindings.

> + - interrupt-parent : should be the phandle for the interrupt controller
> + - interrupts : interrupt mapping for GPIO IRQ

Refer to interrupt-controller/interrupts.txt for generic
interrupt client node bindings.

> +
> +Optional properties:
> + - ams,tune-cap: Calibration tuning capacitor stepping value 0 - 15.
> +   Range of 0 to 120 pF, 8pF steps. This will require using the
> +   calibration data from the manufacturer.
> +
> +
> +Example:
> +
> +as3935@0 {
> + compatible = "ams,as3935";
> + reg = <0>;
> + spi-cpha;
> + interrupt-parent = <>;
> + interrupts = <16 1>;
> + ams,tune-cap = /bits/ 8 <10>;

What is this? Why not just ams,tune-cap = <10>; ?

It's a value between 0-15, right?

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

Re: [bisected] Re: WARNING: at net/ipv4/devinet.c:1599

[David Miller]

From: Geert Uytterhoeven 
Date: Tue, 4 Feb 2014 21:03:24 +0100

> On Tue, Feb 4, 2014 at 8:20 PM, Geert Uytterhoeven  
> wrote:
>> On Tue, Feb 4, 2014 at 7:08 PM, Cong Wang  wrote:
>>> On Tue, Feb 4, 2014 at 6:19 AM, Geert Uytterhoeven  
>>> wrote:

 Anyone with a clue?

>>>
>>> Looks like we need:
>>>
>>> diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
>>> index ac2dff3..bdbf68b 100644
>>> --- a/net/ipv4/devinet.c
>>> +++ b/net/ipv4/devinet.c
>>> @@ -1443,7 +1443,8 @@ static size_t inet_nlmsg_size(void)
>>>+ nla_total_size(4) /* IFA_LOCAL */
>>>+ nla_total_size(4) /* IFA_BROADCAST */
>>>+ nla_total_size(IFNAMSIZ) /* IFA_LABEL */
>>> -  + nla_total_size(4);  /* IFA_FLAGS */
>>> +  + nla_total_size(4)  /* IFA_FLAGS */
>>> +  + nla_total_size(sizeof(struct ifa_cacheinfo)); /*
>>> IFA_CACHEINFO */
>>>  }
>>
>> Thanks for your suggestion, but it doesn't help :-(
> 
> Bummer, I applied it to the wrong tree.
> 
> Yes, it works, thanks a lot!
> 
> David, Jiri, is this the right fix, or just a band-aid?

It looks correct, and if you look ipv6 does this correctly already,
someone please submit this formally.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/build] x86: Disable generation of traditional x87 instructions

[tip-bot for Borislav Petkov]

Commit-ID:  b399fe355b30d0102e7690c99e6f764ddfd32ec3
Gitweb: http://git.kernel.org/tip/b399fe355b30d0102e7690c99e6f764ddfd32ec3
Author: Borislav Petkov 
AuthorDate: Wed, 5 Feb 2014 01:55:11 +0100
Committer:  H. Peter Anvin 
CommitDate: Tue, 4 Feb 2014 20:00:35 -0800

x86: Disable generation of traditional x87 instructions

We recently had the case where wrongly used floating-constant 'E' caused
the generation of traditional x87 instructions in kernel code and
wreaking all kinds of havoc.

Disable the generation of those too. This will save people a lot of time
when trying to debug such issues by erroring out of the build instead of
let them manifest themselves in very spectacular and happy-crappy ways
at runtime.

We're using -mno-fp-ret-in-387 in addition to -mno-80387 (which is ==
-msoft-float) because, as the gcc manpage says:

  On machines where a function returns floating-point results in the
  80387 register stack, some floating-point opcodes may be emitted even
  if -msoft-float is used.

so we want to turn off *all* non-integer instructions involving any
architectural FPU state, unless it is absolutely necessary (and those
cases need special handling anyway).

Cc: Jiri Kosina 
Cc: Michael Matz 
Cc: Michal Hocko 
Signed-off-by: Borislav Petkov 
Link: http://lkml.kernel.org/r/1391561711-3023-1-git-send-email...@alien8.de
Signed-off-by: H. Peter Anvin 
---
 arch/x86/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index eeda43a..a414b14 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -82,8 +82,8 @@ else
 KBUILD_AFLAGS += -m64
 KBUILD_CFLAGS += -m64
 
-# Don't autogenerate MMX or SSE instructions
-KBUILD_CFLAGS += -mno-mmx -mno-sse
+# Don't autogenerate traditional x87, MMX or SSE instructions
+KBUILD_CFLAGS += -mno-mmx -mno-sse -mno-80387 -mno-fp-ret-in-387
 
# Use -mpreferred-stack-boundary=3 if supported.
KBUILD_CFLAGS += $(call cc-option,-mpreferred-stack-boundary=3)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] mvebu : pcie: dt: potential issue in range parsing

[Jason Cooper]

Jean-Jacques,

On Fri, Jan 10, 2014 at 11:23:51AM +0100, Jean-Jacques Hiblot wrote:
> The second parameter of of_read_number is not the index, but a size.
> As it happens, in this case it may work just fine because of the the 
> conversion
> to u32 and the favorable endianness on this architecture.
> 
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>  drivers/pci/host/pci-mvebu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Sorry for the unusually long delay.  I was waiting for Thomas to get
back from vacation since he is intimately familiar with this driver.

Thomas?

thx,

Jason.

> diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
> index c269e43..877e8ce 100644
> --- a/drivers/pci/host/pci-mvebu.c
> +++ b/drivers/pci/host/pci-mvebu.c
> @@ -768,7 +768,7 @@ static int mvebu_get_tgt_attr(struct device_node *np, int 
> devfn,
>  
>   for (i = 0; i < nranges; i++) {
>   u32 flags = of_read_number(range, 1);
> - u32 slot = of_read_number(range, 2);
> + u32 slot = of_read_number(range + 1, 1);
>   u64 cpuaddr = of_read_number(range + na, pna);
>   unsigned long rtype;
>  
> -- 
> 1.8.5.2
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V3] cpuidle/governors: Fix logic in selection of idle states

[Preeti U Murthy]

Hi Arjan,

On 02/04/2014 08:22 PM, Arjan van de Ven wrote:
> On 2/4/2014 12:35 AM, Preeti U Murthy wrote:
>> The cpuidle governors today are not handling scenarios where no idle
>> state
>> can be chosen. Such scenarios coud arise if the user has disabled all the
>> idle states at runtime or the latency requirement from the cpus is
>> very strict.
>>
>> The menu governor returns 0th index of the idle state table when no other
>> idle state is suitable. This is even when the idle state corresponding
>> to this
>> index is disabled or the latency requirement is strict and the
>> exit_latency
>> of the lowest idle state is also not acceptable. Hence this patch
>> fixes this logic in the menu governor by defaulting to an idle state
>> index
>>  of -1 unless any other state is suitable.
> 
> state 0 is defined as polling, and polling ALWAYS should be ok

Hmm.. you are right. This is convincing. There is no need for this patch.

Thanks

Regards
Preeti U Murthy
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pinctrl-msm: Support output-{high,low} configuration

[Bjorn Andersson]

Add support for configuring pins as output with value as from the
pinconf-generic interface.

Signed-off-by: Bjorn Andersson 
---
 drivers/pinctrl/pinctrl-msm.c |   27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/pinctrl/pinctrl-msm.c b/drivers/pinctrl/pinctrl-msm.c
index ef2bf31..2cfb1d4 100644
--- a/drivers/pinctrl/pinctrl-msm.c
+++ b/drivers/pinctrl/pinctrl-msm.c
@@ -228,6 +228,11 @@ static int msm_config_reg(struct msm_pinctrl *pctrl,
*bit = g->drv_bit;
*mask = 7;
break;
+   case PIN_CONFIG_OUTPUT:
+   *reg = g->ctl_reg;
+   *bit = g->oe_bit;
+   *mask = 1;
+   break;
default:
dev_err(pctrl->dev, "Invalid config param %04x\n", param);
return -ENOTSUPP;
@@ -301,6 +306,14 @@ static int msm_config_group_get(struct pinctrl_dev 
*pctldev,
case PIN_CONFIG_DRIVE_STRENGTH:
arg = msm_regval_to_drive[arg];
break;
+   case PIN_CONFIG_OUTPUT:
+   /* Pin is not output */
+   if (!arg)
+   return -EINVAL;
+
+   val = readl(pctrl->regs + g->io_reg);
+   arg = !!(val & BIT(g->in_bit));
+   break;
default:
dev_err(pctrl->dev, "Unsupported config parameter: %x\n",
param);
@@ -357,6 +370,20 @@ static int msm_config_group_set(struct pinctrl_dev 
*pctldev,
else
arg = msm_drive_to_regval[arg];
break;
+   case PIN_CONFIG_OUTPUT:
+   /* set output value */
+   spin_lock_irqsave(>lock, flags);
+   val = readl(pctrl->regs + g->io_reg);
+   if (arg)
+   val |= BIT(g->out_bit);
+   else
+   val &= ~BIT(g->out_bit);
+   writel(val, pctrl->regs + g->io_reg);
+   spin_unlock_irqrestore(>lock, flags);
+
+   /* enable output */
+   arg = 1;
+   break;
default:
dev_err(pctrl->dev, "Unsupported config parameter: 
%x\n",
param);
-- 
1.7.9.5

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

Legacy pm ops to dev_pm_ops patches

[Shuah Khan]

Hi Rafael,

I checked on the status of the legacy pm ops to dev_pm_ops conversion 
patches. Several went in. I have about 13 patches I would like to send. 
These patches are similar in nature. One of the issues I am having is 
being able to test these patches. Except for drivers/pcmcia/ds.c patch, 
others I am limited to compile testing only. Would it be okay to I send 
these as RFT patches cc'ing you and linux-pm and in addition to the 
maintainers for each of these patches?


Patch details below:

5 mmc host driver patches:

drivers/mmc/host/au1xmmc.c
drivers/mmc/host/bfin_sdh.c
drivers/mmc/host/cb710-mmc.c
drivers/mmc/host/msm_sdcc.c
drivers/mmc/host/tmio_mmc.c

3 arm platform driver patches:

arch/arm/common/locomo.c
arch/arm/common/sa.c
arch/arm/common/scoop.c

1 macintosh driver patch:
drivers/macintosh/adb.c

3 bus drivers patches:
drivers/base/isa.c
drivers/pcmcia/ds.c
drivers/s390/crypto/ap_bus.c

The nature if changes is very similar:
1. Define dev_pm_ops as in the example below:

+static const struct dev_pm_ops pcmcia_bus_dev_pm_ops = {
+   .suspend = pcmcia_dev_suspend,
+   .resume = pcmcia_dev_resume,
+   /* Hibernate callbacks */
+   .freeze = pcmcia_dev_freeze,
+   .thaw = pcmcia_dev_resume,
+   .poweroff = pcmcia_dev_poweroff,
+   .restore = pcmcia_dev_resume,
+};

 struct bus_type pcmcia_bus_type = {
.name = "pcmcia",
@@ -1405,8 +1432,7 @@ struct bus_type pcmcia_bus_type = {
.dev_groups = pcmcia_dev_groups,
.probe = pcmcia_device_probe,
.remove = pcmcia_device_remove,
-   .suspend = pcmcia_dev_suspend,
-   .resume = pcmcia_dev_resume,
+   .pm = _bus_dev_pm_ops,
 };

2. Define new interfaces for poweroff, freeze which in turn call 
existing suspend interface, as in the example below. thaw, resume, and 
restore are straight forward and just point to existing resume() hook


+static int pcmcia_dev_suspend(struct device *dev)
+{
+   __pcmcia_dev_suspend(dev, PMSG_SUSPEND);
+}
+
+static int pcmcia_dev_poweroff(struct device *dev)
+{
+   __pcmcia_dev_suspend(dev, PMSG_HIBERNATE);
+}
+
+static int pcmcia_dev_freeze(struct device *dev)
+{
+   __pcmcia_dev_suspend(dev, PMSG_FREEZE);
+}
+
+static int __pcmcia_dev_suspend(struct device *dev, pm_message_t state)
 {
struct pcmcia_device *p_dev = to_pcmcia_dev(dev);
struct pcmcia_driver *p_drv = NULL;
@@ -1397,6 +1415,15 @@ static struct class_interface 
pcmcia_bus_interface __refdata = {

.remove_dev = _bus_remove_socket,
 };

thanks,
-- Shuah

--
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah...@samsung.com | (970) 672-0658
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] exec: Fix use after free of tracepoint trace_sched_process_exec

[Linus Torvalds]

On Tue, Feb 4, 2014 at 5:10 PM, Al Viro  wrote:
>
> Umm...  Interactions with aushit might be interesting.

Freudian slip or intentional? :-)

> It hooks into getname() and putname(); I'm not up to doing analysis
> right now [...]

Right you are. I was actually aware of that, but grepping for things
it all looked fine. But I got confused by all the insane audit
wrappers, and you're right, it needs some massaging for audit
handling.

And that audit code really is aushit. I think I found a bug in it
while just scanning it: if audit_alloc_name() fails, the filename will
never be added to the audit lists, and name_count will never be
incremented. But then when we call audit_putname it won't actually put
the name, so it all just leaks - and if you have AUDIT_DEBUG enabled
you'd eventually see an error.

I wonder if we could get rid of some of that crap, and make the audit
code use dentry_path() instead of trying to save off pathnames like
that. But I don't know what the audit code actually *uses* the
pathnames for, so what do I know.

Eric? Can you please explain?

Also, here's a slightly updated patch. The change is that:
 - getname_kernel() will now clear 'filename->aname'
 - cleared 'aname' for regular getname too before calling
audit_getname(), so that if that one fails, it will be NULL.
 - audit_putname() will consider a NULL aname to be the same as not
being in audit context, and just do a final_putname() on it.

That should fix the audit filename leak too, afaik.

Eric, please take a look. As well as explain the audit name thing if possible.

Linus
 arch/parisc/hpux/fs.c |  3 +-
 arch/tile/mm/elf.c|  2 +-
 fs/binfmt_em86.c  |  2 +-
 fs/binfmt_flat.c  | 15 ++
 fs/exec.c | 58 ---
 fs/namei.c| 30 
 include/linux/binfmts.h   |  3 +-
 include/linux/fs.h|  1 +
 include/linux/sched.h |  3 +-
 include/trace/events/sched.h  |  4 +--
 init/main.c   |  2 +-
 kernel/auditsc.c  |  2 +-
 kernel/kmod.c |  2 +-
 security/apparmor/domain.c|  2 +-
 security/commoncap.c  |  6 ++--
 security/integrity/ima/ima_main.c |  4 +--
 security/tomoyo/domain.c  |  2 +-
 security/tomoyo/tomoyo.c  |  2 +-
 18 files changed, 90 insertions(+), 53 deletions(-)

diff --git a/arch/parisc/hpux/fs.c b/arch/parisc/hpux/fs.c
index 88d0962de65a..23ebcd678da3 100644
--- a/arch/parisc/hpux/fs.c
+++ b/arch/parisc/hpux/fs.c
@@ -41,11 +41,10 @@ int hpux_execve(struct pt_regs *regs)
if (IS_ERR(filename))
goto out;
 
-   error = do_execve(filename->name,
+   error = do_execve(filename,
  (const char __user *const __user *) regs->gr[25],
  (const char __user *const __user *) regs->gr[24]);
 
-   putname(filename);
 
 out:
return error;
diff --git a/arch/tile/mm/elf.c b/arch/tile/mm/elf.c
index 23f044e8a7ab..3ad54a7a927c 100644
--- a/arch/tile/mm/elf.c
+++ b/arch/tile/mm/elf.c
@@ -117,7 +117,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm,
 * whatever was passed as the linux_binprm filename.
 */
if (!notify_exec(mm))
-   sim_notify_exec(bprm->filename);
+   sim_notify_exec(bprm->filename->name);
 
retval = setup_vdso_pages();
 
diff --git a/fs/binfmt_em86.c b/fs/binfmt_em86.c
index f37b08cea1f7..077a76fb6347 100644
--- a/fs/binfmt_em86.c
+++ b/fs/binfmt_em86.c
@@ -62,7 +62,7 @@ static int load_em86(struct linux_binprm *bprm)
 * user environment and arguments are stored.
 */
remove_arg_zero(bprm);
-   retval = copy_strings_kernel(1, >filename, bprm);
+   retval = copy_strings_kernel(1, >filename->name, bprm);
if (retval < 0) return retval; 
bprm->argc++;
if (i_arg) {
diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
index d50bbe59da1e..f1377a5d260b 100644
--- a/fs/binfmt_flat.c
+++ b/fs/binfmt_flat.c
@@ -469,7 +469,7 @@ static int load_flat_file(struct linux_binprm * bprm,
}
 
if (flags & FLAT_FLAG_KTRACE)
-   printk("BINFMT_FLAT: Loading file: %s\n", bprm->filename);
+   printk("BINFMT_FLAT: Loading file: %s\n", bprm->filename->name);
 
if (rev != FLAT_VERSION && rev != OLD_FLAT_VERSION) {
printk("BINFMT_FLAT: bad flat file version 0x%x (supported "
@@ -686,7 +686,7 @@ static int load_flat_file(struct linux_binprm * bprm,
 
if (flags & FLAT_FLAG_KTRACE)
printk("%s %s: TEXT=%x-%x DATA=%x-%x BSS=%x-%x\n",
-   id ? "Lib" : "Load", bprm->filename,
+   id ? "Lib" : "Load", bprm->filename->name,
(int) start_code, (int) end_code,
(int) datapos,

[PATCH] kernel/kprobes.c: move kretprobe implementation to CONFIG_KRETPROBES area

[Chen Gang]

When CONFIG_KRETPROBES disabled, kretprobe implementation are useless,
so need move them to CONFIG_KPROBES area.

 - move all kretprobe* to CONFIG_KPROBES area and dummy outside.
 - define kretprobe_flush_task() to let kprobe_flush_task() call.
 - define init_kretprobes() to let init_kprobes() call.


Signed-off-by: Chen Gang 
---
 kernel/kprobes.c | 323 +++
 1 file changed, 181 insertions(+), 142 deletions(-)

diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index ceeadfc..0619536 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -69,7 +69,6 @@
 
 static int kprobes_initialized;
 static struct hlist_head kprobe_table[KPROBE_TABLE_SIZE];
-static struct hlist_head kretprobe_inst_table[KPROBE_TABLE_SIZE];
 
 /* NOTE: change this value only with kprobe_mutex held */
 static bool kprobes_all_disarmed;
@@ -77,14 +76,6 @@ static bool kprobes_all_disarmed;
 /* This protects kprobe_table and optimizing_list */
 static DEFINE_MUTEX(kprobe_mutex);
 static DEFINE_PER_CPU(struct kprobe *, kprobe_instance) = NULL;
-static struct {
-   raw_spinlock_t lock cacheline_aligned_in_smp;
-} kretprobe_table_locks[KPROBE_TABLE_SIZE];
-
-static raw_spinlock_t *kretprobe_table_lock_ptr(unsigned long hash)
-{
-   return &(kretprobe_table_locks[hash].lock);
-}
 
 /*
  * Normally, functions that we'd want to prohibit kprobes in, are marked
@@ -1079,125 +1070,6 @@ void __kprobes kprobes_inc_nmissed_count(struct kprobe 
*p)
return;
 }
 
-void __kprobes recycle_rp_inst(struct kretprobe_instance *ri,
-   struct hlist_head *head)
-{
-   struct kretprobe *rp = ri->rp;
-
-   /* remove rp inst off the rprobe_inst_table */
-   hlist_del(>hlist);
-   INIT_HLIST_NODE(>hlist);
-   if (likely(rp)) {
-   raw_spin_lock(>lock);
-   hlist_add_head(>hlist, >free_instances);
-   raw_spin_unlock(>lock);
-   } else
-   /* Unregistering */
-   hlist_add_head(>hlist, head);
-}
-
-void __kprobes kretprobe_hash_lock(struct task_struct *tsk,
-struct hlist_head **head, unsigned long *flags)
-__acquires(hlist_lock)
-{
-   unsigned long hash = hash_ptr(tsk, KPROBE_HASH_BITS);
-   raw_spinlock_t *hlist_lock;
-
-   *head = _inst_table[hash];
-   hlist_lock = kretprobe_table_lock_ptr(hash);
-   raw_spin_lock_irqsave(hlist_lock, *flags);
-}
-
-static void __kprobes kretprobe_table_lock(unsigned long hash,
-   unsigned long *flags)
-__acquires(hlist_lock)
-{
-   raw_spinlock_t *hlist_lock = kretprobe_table_lock_ptr(hash);
-   raw_spin_lock_irqsave(hlist_lock, *flags);
-}
-
-void __kprobes kretprobe_hash_unlock(struct task_struct *tsk,
-   unsigned long *flags)
-__releases(hlist_lock)
-{
-   unsigned long hash = hash_ptr(tsk, KPROBE_HASH_BITS);
-   raw_spinlock_t *hlist_lock;
-
-   hlist_lock = kretprobe_table_lock_ptr(hash);
-   raw_spin_unlock_irqrestore(hlist_lock, *flags);
-}
-
-static void __kprobes kretprobe_table_unlock(unsigned long hash,
-   unsigned long *flags)
-__releases(hlist_lock)
-{
-   raw_spinlock_t *hlist_lock = kretprobe_table_lock_ptr(hash);
-   raw_spin_unlock_irqrestore(hlist_lock, *flags);
-}
-
-/*
- * This function is called from finish_task_switch when task tk becomes dead,
- * so that we can recycle any function-return probe instances associated
- * with this task. These left over instances represent probed functions
- * that have been called but will never return.
- */
-void __kprobes kprobe_flush_task(struct task_struct *tk)
-{
-   struct kretprobe_instance *ri;
-   struct hlist_head *head, empty_rp;
-   struct hlist_node *tmp;
-   unsigned long hash, flags = 0;
-
-   if (unlikely(!kprobes_initialized))
-   /* Early boot.  kretprobe_table_locks not yet initialized. */
-   return;
-
-   INIT_HLIST_HEAD(_rp);
-   hash = hash_ptr(tk, KPROBE_HASH_BITS);
-   head = _inst_table[hash];
-   kretprobe_table_lock(hash, );
-   hlist_for_each_entry_safe(ri, tmp, head, hlist) {
-   if (ri->task == tk)
-   recycle_rp_inst(ri, _rp);
-   }
-   kretprobe_table_unlock(hash, );
-   hlist_for_each_entry_safe(ri, tmp, _rp, hlist) {
-   hlist_del(>hlist);
-   kfree(ri);
-   }
-}
-
-static inline void free_rp_inst(struct kretprobe *rp)
-{
-   struct kretprobe_instance *ri;
-   struct hlist_node *next;
-
-   hlist_for_each_entry_safe(ri, next, >free_instances, hlist) {
-   hlist_del(>hlist);
-   kfree(ri);
-   }
-}
-
-static void __kprobes cleanup_rp_inst(struct kretprobe *rp)
-{
-   unsigned long flags, hash;
-   struct kretprobe_instance *ri;
-   struct hlist_node *next;
-   struct hlist_head *head;
-
-   /* No race here */
-   for (hash = 0; hash < KPROBE_TABLE_SIZE; hash++) {
- 

Re: Fwd: failure notice

[Gene Heskett]

On Tuesday 04 February 2014, Gene Heskett wrote:
>Tried to send PM, bounced
>
>Cheers, Gene

This was supposed to have an inline copy of the bounce, kmail failed.  so 
here is a copy/paste
Greetings Linus;


Clamdscan, in its daily surveys of my system, is indentifying:
Documentation/usb/gadget_multi.txt: MBL_400944.UNOFFICIAL FOUND

In several of my fairly recent trees, pulled by tarball from kernel.org.

You might want to take a look at it.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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/8] Allow Link state changes for Hot-Plug

[Rajat Jain]

Hello list,

My apologies for I forgot to attach the version history information of each 
individual patch.

Essentially the v4 is exactly same as v3, except that it is rebased on top of 
3.14-rc1.

Thanks,

Rajat

> -Original Message-
> From: Rajat Jain [mailto:rajatxj...@gmail.com]
> Sent: Tuesday, February 04, 2014 6:28 PM
> To: Bjorn Helgaas; Rafael J. Wysocki; Kenji Kaneshige; Alex Williamson;
> Yijing Wang; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Yinghai Lu
> Cc: Guenter Roeck; Rajat Jain; Rajat Jain
> Subject: [PATCH v4 0/8] Allow Link state changes for Hot-Plug
> 
> Hello,
> 
> This patch set enables the use of PCI Express link up and link down
> events for Hotplug or Unplug. This is the pretty much the same patchset
> as v3, only resending after rebasing on top of 3.14-rc1.
> 
> (As a side effect, this patch also fixes the bug
> https://bugzilla.kernel.org/show_bug.cgi?id=65521 )
> 
> I'd appreciate if you could please review and provide me with any
> comments.
> 
> Thanks,
> 
> Rajat
> 
> Rajat Jain (8):
>   pciehp: Make check_link_active() non-static
>   pciehp: Use link change notifications for hot-plug and removal
>   pciehp: Enable link state change notifications
>   pciehp: Don't disable the link permanently, during removal
>   pciehp: Don't check for adapter or latch status while disabling
>   pciehp: Disabling the link notification across slot reset
>   pciehp: Ensure very fast hotplug events are also processed.
>   pciehp: Introduce hotplug_lock to serialize HP events
> 
>  drivers/pci/hotplug/pciehp.h  |5 ++
>  drivers/pci/hotplug/pciehp_core.c |7 +-
>  drivers/pci/hotplug/pciehp_ctrl.c |  149
> ++---
>  drivers/pci/hotplug/pciehp_hpc.c  |   74 +-
>  4 files changed, 169 insertions(+), 66 deletions(-)
> 
> --
> 1.7.9.5
> 
> 

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

[PATCH v4 2/2] iio: Add AS3935 lightning sensor support

[Matt Ranostay]

AS3935 chipset can detect lightning strikes and reports those back as
events and the estimated distance to the storm.

Signed-off-by: Matt Ranostay 
---
 .../ABI/testing/sysfs-bus-iio-proximity-as3935 |  18 +
 drivers/iio/Kconfig|   1 +
 drivers/iio/Makefile   |   1 +
 drivers/iio/proximity/Kconfig  |  19 +
 drivers/iio/proximity/Makefile |   6 +
 drivers/iio/proximity/as3935.c | 437 +
 6 files changed, 482 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935
 create mode 100644 drivers/iio/proximity/Kconfig
 create mode 100644 drivers/iio/proximity/Makefile
 create mode 100644 drivers/iio/proximity/as3935.c

diff --git a/Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935 
b/Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935
new file mode 100644
index 000..f6d9e6f
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935
@@ -0,0 +1,18 @@
+What   /sys/bus/iio/devices/iio:deviceX/in_proximity_raw
+Date:  January 2014
+KernelVersion: 3.15
+Contact:   Matt Ranostay 
+Description:
+   Get the current distance in kilometers of storm
+   1= storm overhead
+   1-40 = distance in kilometers
+   63   = out of range
+
+What   /sys/bus/iio/devices/iio:deviceX/gain_boost
+Date:  January 2014
+KernelVersion: 3.15
+Contact:   Matt Ranostay 
+Description:
+   Show or set the gain boost of the amp, from 0-31 range.
+   18 = indoors (default)
+   14 = outdoors
diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 5dd0e12..743485e 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -74,6 +74,7 @@ if IIO_TRIGGER
source "drivers/iio/trigger/Kconfig"
 endif #IIO_TRIGGER
 source "drivers/iio/pressure/Kconfig"
+source "drivers/iio/proximity/Kconfig"
 source "drivers/iio/temperature/Kconfig"
 
 endif # IIO
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 887d390..698afc2 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -24,5 +24,6 @@ obj-y += light/
 obj-y += magnetometer/
 obj-y += orientation/
 obj-y += pressure/
+obj-y += proximity/
 obj-y += temperature/
 obj-y += trigger/
diff --git a/drivers/iio/proximity/Kconfig b/drivers/iio/proximity/Kconfig
new file mode 100644
index 000..0c8cdf5
--- /dev/null
+++ b/drivers/iio/proximity/Kconfig
@@ -0,0 +1,19 @@
+#
+# Proximity sensors
+#
+
+menu "Lightning sensors"
+
+config AS3935
+   tristate "AS3935 Franklin lightning sensor"
+   select IIO_BUFFER
+   select IIO_TRIGGERED_BUFFER
+   depends on SPI
+   help
+ Say Y here to build SPI interface support for the Austrian
+ Microsystems AS3935 lightning detection sensor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called as3935
+
+endmenu
diff --git a/drivers/iio/proximity/Makefile b/drivers/iio/proximity/Makefile
new file mode 100644
index 000..743adee
--- /dev/null
+++ b/drivers/iio/proximity/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for IIO proximity sensors
+#
+
+# When adding new entries keep the list in alphabetical order
+obj-$(CONFIG_AS3935)   += as3935.o
diff --git a/drivers/iio/proximity/as3935.c b/drivers/iio/proximity/as3935.c
new file mode 100644
index 000..da4f5f6
--- /dev/null
+++ b/drivers/iio/proximity/as3935.c
@@ -0,0 +1,437 @@
+/*
+ * as3935.c - Support for AS3935 Franklin lightning sensor
+ *
+ * Copyright (C) 2014 Matt Ranostay 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+#define AS3935_AFE_GAIN0x00
+#define AS3935_AFE_MASK0x3F
+#define AS3935_AFE_GAIN_MAX0x1F
+#define AS3935_AFE_PWR_BIT BIT(0)
+
+#define AS3935_INT 0x03
+#define AS3935_INT_MASK0x07
+#define AS3935_EVENT_INT   BIT(3)
+#define AS3935_NOISE_INT   BIT(1)
+
+#define AS3935_DATA0x07
+#define AS3935_DATA_MASK   0x3F
+
+#define AS3935_TUNE_CAP0x08
+#define AS3935_CALIBRATE   0x3D
+
+#define AS3935_WRITE_DATA  BIT(15)
+#define AS3935_READ_DATA   BIT(14)
+#define AS3935_ADDRESS(x)  

[PATCH v4 1/2] iio:as3935: Add DT binding docs for AS3935 driver

[Matt Ranostay]

Document compatible string, required and optional DT properties for
AS3935 chipset driver.

Signed-off-by: Matt Ranostay 
---
 .../devicetree/bindings/iio/proximity/as3935.txt   | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/proximity/as3935.txt

diff --git a/Documentation/devicetree/bindings/iio/proximity/as3935.txt 
b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
new file mode 100644
index 000..7e117cd
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
@@ -0,0 +1,25 @@
+Austrian Microsystems AS3935 Franklin lightning sensor device driver
+
+Required properties:
+   - compatible: must be "ams,as3935"
+   - reg: SPI chip select number for the device
+   - spi-cpha: SPI Mode 1
+   - interrupt-parent : should be the phandle for the interrupt controller
+   - interrupts : interrupt mapping for GPIO IRQ
+
+Optional properties:
+   - ams,tune-cap: Calibration tuning capacitor stepping value 0 - 15.
+ Range of 0 to 120 pF, 8pF steps. This will require using the
+ calibration data from the manufacturer.
+
+
+Example:
+
+as3935@0 {
+   compatible = "ams,as3935";
+   reg = <0>;
+   spi-cpha;
+   interrupt-parent = <>;
+   interrupts = <16 1>;
+   ams,tune-cap = /bits/ 8 <10>;
+};
-- 
1.8.3.2

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

Fwd: failure notice

[Gene Heskett]

Tried to send PM, bounced

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] kernel: kprobe: move all *kretprobe* generic implementation to CONFIG_KRETPROBES enabled area

[Chen Gang]

On 02/05/2014 09:21 AM, Masami Hiramatsu wrote:
> (2014/02/05 9:18), Chen Gang wrote:
>> On 02/04/2014 11:39 PM, Masami Hiramatsu wrote:
>>> (2014/02/04 22:53), Chen Gang wrote:
 On 02/04/2014 09:29 PM, Masami Hiramatsu wrote:
> (2014/02/04 21:07), Chen Gang wrote:
>> On 02/04/2014 03:17 PM, Masami Hiramatsu wrote:
>>> (2014/02/04 14:16), Chen Gang wrote:
 When CONFIG_KRETPROBES disabled, all *kretprobe* generic implementation
 are useless, so need move them to CONFIG_KPROBES enabled area.

 Now, *kretprobe* generic implementation are all implemented in 2 files:

  - in "include/linux/kprobes.h":

  move inline kretprobe*() to CONFIG_KPROBES area and dummy outside.
  move some *kprobe() declarations which kretprobe*() call, to 
 front.
  not touch kretprobe_blacklist[] which is architecture's variable.

  - in "kernel/kprobes.c":

  move all kretprobe* to CONFIG_KPROBES area and dummy outside.
  define kretprobe_flush_task() to let kprobe_flush_task() call.
  define init_kretprobes() to let init_kprobes() call.

 The patch passes compiling (get "kernel/kprobes.o" and "kernel/built-
 in.o") under avr32 and x86_64 allmodconfig, and passes building (get
 bzImage and Modpost modules) under x86_64 defconfig.
>>>
>>> Thanks for the fix! and I have some comments below.
>>>
 Signed-off-by: Chen Gang 
 ---
  include/linux/kprobes.h |  58 +
  kernel/kprobes.c| 328 
 +++-
  2 files changed, 222 insertions(+), 164 deletions(-)

 diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h
 index 925eaf2..c0d1212 100644
 --- a/include/linux/kprobes.h
 +++ b/include/linux/kprobes.h
 @@ -223,10 +223,36 @@ static inline int kprobes_built_in(void)
   return 1;
  }
  
 +int disable_kprobe(struct kprobe *kp);
 +int enable_kprobe(struct kprobe *kp);
 +
 +void dump_kprobe(struct kprobe *kp);
 +
 +extern struct kretprobe_blackpoint kretprobe_blacklist[];
 +
  #ifdef CONFIG_KRETPROBES
  extern void arch_prepare_kretprobe(struct kretprobe_instance *ri,
 struct pt_regs *regs);
  extern int arch_trampoline_kprobe(struct kprobe *p);
 +static inline void kretprobe_assert(struct kretprobe_instance *ri,
 + unsigned long orig_ret_address, unsigned long trampoline_address)
 +{
 + if (!orig_ret_address || (orig_ret_address == trampoline_address)) {
 + printk(KERN_ERR
 + "kretprobe BUG!: Processing kretprobe %p @ %p\n",
 + ri->rp, ri->rp->kp.addr);
 + BUG();
 + }
 +}
 +static inline int disable_kretprobe(struct kretprobe *rp)
 +{
 + return disable_kprobe(>kp);
 +}
 +static inline int enable_kretprobe(struct kretprobe *rp)
 +{
 + return enable_kprobe(>kp);
 +}
 +
  #else /* CONFIG_KRETPROBES */
  static inline void arch_prepare_kretprobe(struct kretprobe *rp,
   struct pt_regs *regs)
 @@ -236,19 +262,20 @@ static inline int arch_trampoline_kprobe(struct 
 kprobe *p)
  {
   return 0;
  }
 -#endif /* CONFIG_KRETPROBES */
 -
 -extern struct kretprobe_blackpoint kretprobe_blacklist[];
 -
  static inline void kretprobe_assert(struct kretprobe_instance *ri,
   unsigned long orig_ret_address, unsigned long trampoline_address)
  {
 - if (!orig_ret_address || (orig_ret_address == trampoline_address)) {
 - printk("kretprobe BUG!: Processing kretprobe %p @ %p\n",
 - ri->rp, ri->rp->kp.addr);
 - BUG();
 - }
  }
 +static inline int disable_kretprobe(struct kretprobe *rp)
 +{
 + return 0;
 +}
 +static inline int enable_kretprobe(struct kretprobe *rp)
 +{
 + return 0;
 +}
>>>
>>> No, these should returns -EINVAL or -ENOSYS, since these are user API.
>>
>> OK, thanks, it sounds reasonable to me.
>>
>>> Anyway, I don't think those inlined functions to be changed, because
>>> most of them are internal functions. If CONFIG_KRETPROBES=n, it just
>>> be ignored.
>>>
>>
>> In original implementation, if CONFIG_KRETPROBES=n, kretprobe_assert(),
>> disable_kretprobe(), and enable_kretprobe() are not ignored.
>
> Really? where are they called? I mean, those functions do not have
> any instance unless your module uses it (but that is not what the kernel
> itself should help).
>

 If what you said correct (I guess so), for me, we 

linux-next: Tree for Feb 5

[Stephen Rothwell]

Hi all,

This tree fails (more than usual) the powerpc allyesconfig build.

Changes since 20140204:

Removed tree: init (submitted and done with)

Undropped tree: parisc-hd

The parisc-hd tree lost its conflicts and so is back.

The powerpc tree still had its build failure.

Non-merge commits (relative to Linus' tree): 1420
 755 files changed, 31699 insertions(+), 12009 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final
link) and i386, sparc, sparc64 and arm defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

I am currently merging 208 trees (counting Linus' and 28 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

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

$ git checkout master
$ git reset --hard stable
Merging origin/master (878a876b2e10 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs)
Merging fixes/master (b0031f227e47 Merge tag 's2mps11-build' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator)
Merging kbuild-current/rc-fixes (19514fc665ff arm, kbuild: make "make install" 
not depend on vmlinux)
Merging arc-current/for-curr (7e22e91102c6 Linux 3.13-rc8)
Merging arm-current/fixes (d326b65c57d6 ARM: fix building with gcc 4.6.4)
Merging m68k-current/for-linus (56931d73697c m68k/mac: Make SCC reset work more 
reliably)
Merging metag-fixes/fixes (3b2f64d00c46 Linux 3.11-rc2)
Merging powerpc-merge/merge (b3084f4db3ae powerpc/thp: Fix crash on mremap)
Merging sparc/master (9b0cd304f26b Merge branch 'drm-next' of 
git://people.freedesktop.org/~airlied/linux)
Merging net/master (b045d37bd68c ip_tunnel: fix panic in ip_tunnel_xmit())
Merging ipsec/master (965cdea82569 dccp: catch failed request_module call in 
dccp_probe init)
Merging sound-current/for-linus (4528eb19b00d ALSA: hda - Fix silent output on 
Toshiba Satellite L40)
Merging pci-current/for-linus (38dbfb59d117 Linus 3.14-rc1)
Merging wireless/master (4cfe9a8d5829 ath9k: Fix TX power calculation)
Merging driver-core.current/driver-core-linus (38dbfb59d117 Linus 3.14-rc1)
Merging tty.current/tty-linus (38dbfb59d117 Linus 3.14-rc1)
Merging usb.current/usb-linus (823d12c95c66 usb-storage: enable multi-LUN 
scanning when needed)
Merging staging.current/staging-linus (38dbfb59d117 Linus 3.14-rc1)
Merging char-misc.current/char-misc-linus (38dbfb59d117 Linus 3.14-rc1)
Merging input-current/for-linus (55df811f2066 Merge branch 'next' into 
for-linus)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (ee97dc7db4cb crypto: s390 - fix des and des3_ede 
ctr concurrency issue)
Merging ide/master (9b0cd304f26b Merge branch 'drm-next' of 
git://people.freedesktop.org/~airlied/linux)
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (6f041e99fc7b of: Fix NULL 
dereference in unflatten_and_copy())
Merging rr-fixes/fixes (7122c3e9154b scripts/link-vmlinux.sh: only filter 
kernel symbols for arm)
Merging mfd-fixes/master (73beb63d290f mfd: rtsx_pcr: Disable interrupts before 
cancelling delayed works)
Merging vfio-fixes/for-linus (239a87020b26 Merge branch 
'for-joerg/arm-smmu/fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into for-linus)
Merging drm-intel-fixes/for-linux-next-fixes (bdde5c6a258a drm/i915: demo

Re: [RFC][PATCH] exec: Fix use after free of tracepoint trace_sched_process_exec

[Steven Rostedt]

On Tue, 4 Feb 2014 21:31:09 -0500
Steven Rostedt  wrote:
 
> (probably should keep)
> 
> Reported-by: Igor Zhbanov 

I should probably state that "IZh" confirmed on IRC that this is indeed
the person that reported the issue in the first place.

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

[patch v2] mm, compaction: avoid isolating pinned pages

[David Rientjes]

Page migration will fail for memory that is pinned in memory with, for
example, get_user_pages().  In this case, it is unnecessary to take
zone->lru_lock or isolating the page and passing it to page migration
which will ultimately fail.

This is a racy check, the page can still change from under us, but in
that case we'll just fail later when attempting to move the page.

This avoids very expensive memory compaction when faulting transparent
hugepages after pinning a lot of memory with a Mellanox driver.

On a 128GB machine and pinning ~120GB of memory, before this patch we
see the enormous disparity in the number of page migration failures
because of the pinning (from /proc/vmstat):

compact_pages_moved 8450
compact_pagemigrate_failed 15614415

0.05% of pages isolated are successfully migrated and explicitly 
triggering memory compaction takes 102 seconds.  After the patch:

compact_pages_moved 9197
compact_pagemigrate_failed 7

99.9% of pages isolated are now successfully migrated in this 
configuration and memory compaction takes less than one second.

Signed-off-by: David Rientjes 
---
 v2: address page count issue per Joonsoo

 mm/compaction.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/mm/compaction.c b/mm/compaction.c
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -578,6 +578,15 @@ isolate_migratepages_range(struct zone *zone, struct 
compact_control *cc,
continue;
}
 
+   /*
+* Migration will fail if an anonymous page is pinned in memory,
+* so avoid taking lru_lock and isolating it unnecessarily in an
+* admittedly racy check.
+*/
+   if (!page_mapping(page) &&
+   page_count(page) > page_mapcount(page))
+   continue;
+
/* Check if it is ok to still hold the lock */
locked = compact_checklock_irqsave(>lru_lock, ,
locked, cc);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFCv2 00/10] xhci: re-work command queue management

[Dan Williams]

On Thu, Jan 30, 2014 at 6:25 AM, David Laight  wrote:
> From: Mathias Nyman
>> Only changes since v1 are fixing smatch warnings and errors.
>>   patch 01/10
>> Check for null return from alloc_command, release lock in error path and
>> don't dereference possible null pointer in error path.
>>
>>   patch 04/10
>> release lock in xhci_stop_dev() error path.
>>
>> This is the second attempt to re-work and solve the issues in xhci command
>> queue management that Sarah has descibed earlier:
>>
>> Right now, the command management in the xHCI driver is rather ad-hock.
>> Different parts of the driver all submit commands, including interrupt
>> handling routines, functions called from the USB core (with or without the
>> bus bandwidth mutex held).
>> Some times they need to wait for the command to complete, and sometimes
>> they just issue the command and don't care about the result of the command.
>>
>> The places that wait on a command all time the command for five seconds,
>> and then attempt to cancel the command.
>> Unfortunately, that means if several commands are issued at once, and one of
>> them times out, all the commands timeout, even though the host hasn't gotten
>> a chance to service them yet.
>>
>> This is apparent with some devices that take a long time to respond to the
>> Set Address command during device enumeration (when the device is plugged 
>> in).
>> If a driver for a different device attempts to change alternate interface
>> settings at the same time (causing a Configure Endpoint command to be 
>> issued),
>> both commands timeout.
>>
>> Instead of having each command timeout after five seconds, the driver should
>> wait indefinitely in an uninterruptible sleep on the command completion.
>> A global command queue manager should time whatever command is currently
>> running, and cancel that command after five seconds.
>>
>> If the commands were in a list, like TDs currently are, it may be easier to 
>> keep
>> track of where the command ring dequeue pointer is, and avoid racing with 
>> events.
>> We may need to have parts of the driver that issue commands without waiting 
>> on
>> them still put the commands in the command list.
>>
>> The Implementation:
>> ---
>>
>> First step is to create a list of the commands submitted to the command 
>> queue.
>> To accomplish this each command is required to be submitted with a properly
>> filled command structure containing completion, status variable and a 
>> pointer to
>> the command TRB that will be used.
>
> I think it would be much simpler to allocate a parallel array to the actual
> hardware command ring that contains the additional information for the request
> (instead of allocating it pre-request).
> This would immediately solve any problems allocating the memory from interrupt
> context and failing to free in correctly in all the code paths.
>
> A similar solution could be used for the transfer rings thus removing the
> need to the 'td' list - which there are reports of it failing to find 
> transfers
> and the code paths for aborting isoch transfers are badly broken.
>
> Adding another list that will have its own set of bugs seems retrograde top 
> me.

What bugs?  Please be specific.  The problem to be addressed is not
the allocation of commands, but that timeouts of one command eat the
timeout periods of subsequent commands.  I'm thinking a
single-threaded workqueue better models what the hardware is doing.
See my comments in patch 1, but that is orthogonal to how the command
contexts are allocated.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] exec: Fix use after free of tracepoint trace_sched_process_exec

[Steven Rostedt]

On Tue, 4 Feb 2014 16:57:31 -0800
Linus Torvalds  wrote:


> How does this look?

Well, it is lacking a bit of the "ugly factor" but other than that,
I ran it through some minor tests (basically just logged in and enabled
the sched_process_exec tracepoint and ran a few programs and looked at
what would cause the previous bug). It passed.

I can run it through some more vigorous tests, but I think Al still
needs to really take a look at it.

Tested-by: Steven Rostedt 

(probably should keep)

Reported-by: Igor Zhbanov 

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

[PATCH v4 8/8] pciehp: Introduce hotplug_lock to serialize HP events

[Rajat Jain]

Today it is there is no protection around pciehp_enable_slot() and
pciehp_disable_slot() to ensure that they complete before another
hot-plug operation can be done on that particular slot.

This patch introduces the slot->hotplug_lock to ensure that any
hotplug operations (add / remove) complete before another HP event
can begin processing on that particular slot.

Signed-off-by: Rajat Jain 
Signed-off-by: Rajat Jain 
Signed-off-by: Guenter Roeck 
---
 drivers/pci/hotplug/pciehp.h  |1 +
 drivers/pci/hotplug/pciehp_core.c |7 ++-
 drivers/pci/hotplug/pciehp_ctrl.c |   14 +-
 drivers/pci/hotplug/pciehp_hpc.c  |1 +
 4 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/hotplug/pciehp.h b/drivers/pci/hotplug/pciehp.h
index d8d0336..8a66866 100644
--- a/drivers/pci/hotplug/pciehp.h
+++ b/drivers/pci/hotplug/pciehp.h
@@ -76,6 +76,7 @@ struct slot {
struct hotplug_slot *hotplug_slot;
struct delayed_work work;   /* work for button event */
struct mutex lock;
+   struct mutex hotplug_lock;
struct workqueue_struct *wq;
 };
 
diff --git a/drivers/pci/hotplug/pciehp_core.c 
b/drivers/pci/hotplug/pciehp_core.c
index 53b58de..23b4bde 100644
--- a/drivers/pci/hotplug/pciehp_core.c
+++ b/drivers/pci/hotplug/pciehp_core.c
@@ -283,8 +283,11 @@ static int pciehp_probe(struct pcie_device *dev)
slot = ctrl->slot;
pciehp_get_adapter_status(slot, );
pciehp_get_power_status(slot, );
-   if (occupied && pciehp_force)
+   if (occupied && pciehp_force) {
+   mutex_lock(>hotplug_lock);
pciehp_enable_slot(slot);
+   mutex_unlock(>hotplug_lock);
+   }
/* If empty slot's power status is on, turn power off */
if (!occupied && poweron && POWER_CTRL(ctrl))
pciehp_power_off_slot(slot);
@@ -328,10 +331,12 @@ static int pciehp_resume (struct pcie_device *dev)
 
/* Check if slot is occupied */
pciehp_get_adapter_status(slot, );
+   mutex_lock(>hotplug_lock);
if (status)
pciehp_enable_slot(slot);
else
pciehp_disable_slot(slot);
+   mutex_unlock(>hotplug_lock);
return 0;
 }
 #endif /* PM */
diff --git a/drivers/pci/hotplug/pciehp_ctrl.c 
b/drivers/pci/hotplug/pciehp_ctrl.c
index 3e40ec0..1f2716c 100644
--- a/drivers/pci/hotplug/pciehp_ctrl.c
+++ b/drivers/pci/hotplug/pciehp_ctrl.c
@@ -293,6 +293,7 @@ static void pciehp_power_thread(struct work_struct *work)
struct power_work_info *info =
container_of(work, struct power_work_info, work);
struct slot *p_slot = info->p_slot;
+   int ret;
 
switch (info->req) {
case DISABLE_REQ:
@@ -300,7 +301,9 @@ static void pciehp_power_thread(struct work_struct *work)
 "Disabling domain:bus:device=%04x:%02x:00\n",
 pci_domain_nr(p_slot->ctrl->pcie->port->subordinate),
 p_slot->ctrl->pcie->port->subordinate->number);
+   mutex_lock(_slot->hotplug_lock);
pciehp_disable_slot(p_slot);
+   mutex_unlock(_slot->hotplug_lock);
mutex_lock(_slot->lock);
p_slot->state = STATIC_STATE;
mutex_unlock(_slot->lock);
@@ -310,8 +313,10 @@ static void pciehp_power_thread(struct work_struct *work)
 "Enabling domain:bus:device=%04x:%02x:00\n",
 pci_domain_nr(p_slot->ctrl->pcie->port->subordinate),
 p_slot->ctrl->pcie->port->subordinate->number);
+   mutex_lock(_slot->hotplug_lock);
if (pciehp_enable_slot(p_slot))
pciehp_green_led_off(p_slot);
+   mutex_unlock(_slot->hotplug_lock);
mutex_lock(_slot->lock);
p_slot->state = STATIC_STATE;
mutex_unlock(_slot->lock);
@@ -546,6 +551,9 @@ static void interrupt_event_handler(struct work_struct 
*work)
kfree(info);
 }
 
+/*
+ * Note: This function must be called with slot->hotplug_lock held
+ */
 int pciehp_enable_slot(struct slot *p_slot)
 {
u8 getstatus = 0;
@@ -584,7 +592,9 @@ int pciehp_enable_slot(struct slot *p_slot)
return rc;
 }
 
-
+/*
+ * Note: This function must be called with slot->hotplug_lock held
+ */
 int pciehp_disable_slot(struct slot *p_slot)
 {
u8 getstatus = 0;
@@ -617,7 +627,9 @@ int pciehp_sysfs_enable_slot(struct slot *p_slot)
case STATIC_STATE:
p_slot->state = POWERON_STATE;
mutex_unlock(_slot->lock);
+   mutex_lock(_slot->hotplug_lock);
retval = pciehp_enable_slot(p_slot);
+   mutex_unlock(_slot->hotplug_lock);
mutex_lock(_slot->lock);
p_slot->state = STATIC_STATE;
break;
diff --git a/drivers/pci/hotplug/pciehp_hpc.c 

[PATCH v4 6/8] pciehp: Disabling the link notification across slot reset

[Rajat Jain]

Disable the link notification (in addition to presence detect
notifications) across the slot reset since it could potentialy flap
the link and we don't want to treat it as hot unplug followed by a
hotplug.

Signed-off-by: Rajat Jain 
Signed-off-by: Rajat Jain 
Signed-off-by: Guenter Roeck 
---
 drivers/pci/hotplug/pciehp_hpc.c |   30 +-
 1 file changed, 17 insertions(+), 13 deletions(-)

diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
index 15ca3a1..6433e73 100644
--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/drivers/pci/hotplug/pciehp_hpc.c
@@ -619,33 +619,37 @@ static void pcie_disable_notification(struct controller 
*ctrl)
 
 /*
  * pciehp has a 1:1 bus:slot relationship so we ultimately want a secondary
- * bus reset of the bridge, but if the slot supports surprise removal we need
- * to disable presence detection around the bus reset and clear any spurious
+ * bus reset of the bridge, but if the slot supports surprise removal (or
+ * link state change based hotplug), we need to disable presence detection
+ * (or link state notifications) around the bus reset and clear any spurious
  * events after.
  */
 int pciehp_reset_slot(struct slot *slot, int probe)
 {
struct controller *ctrl = slot->ctrl;
struct pci_dev *pdev = ctrl_dev(ctrl);
+   u16 stat_mask = 0, ctrl_mask = 0;
 
if (probe)
return 0;
 
-   if (HP_SUPR_RM(ctrl)) {
-   pcie_write_cmd(ctrl, 0, PCI_EXP_SLTCTL_PDCE);
-   if (pciehp_poll_mode)
-   del_timer_sync(>poll_timer);
+   if (HP_SUPR_RM(ctrl) && !ATTN_BUTTN(ctrl)) {
+   ctrl_mask |= PCI_EXP_SLTCTL_PDCE;
+   stat_mask |= PCI_EXP_SLTSTA_PDC;
}
+   ctrl_mask |= PCI_EXP_SLTCTL_DLLSCE;
+   stat_mask |= PCI_EXP_SLTSTA_DLLSC;
+
+   pcie_write_cmd(ctrl, 0, ctrl_mask);
+   if (pciehp_poll_mode)
+   del_timer_sync(>poll_timer);
 
pci_reset_bridge_secondary_bus(ctrl->pcie->port);
 
-   if (HP_SUPR_RM(ctrl)) {
-   pcie_capability_write_word(pdev, PCI_EXP_SLTSTA,
-  PCI_EXP_SLTSTA_PDC);
-   pcie_write_cmd(ctrl, PCI_EXP_SLTCTL_PDCE, PCI_EXP_SLTCTL_PDCE);
-   if (pciehp_poll_mode)
-   int_poll_timeout(ctrl->poll_timer.data);
-   }
+   pcie_capability_write_word(pdev, PCI_EXP_SLTSTA, stat_mask);
+   pcie_write_cmd(ctrl, ctrl_mask, ctrl_mask);
+   if (pciehp_poll_mode)
+   int_poll_timeout(ctrl->poll_timer.data);
 
return 0;
 }
-- 
1.7.9.5

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

[PATCH v4 7/8] pciehp: Ensure very fast hotplug events are also processed.

[Rajat Jain]

Today, this is how all the hotplug and unplug events work:

Hotplug / Removal needs to be done
  => Set slot->state (protected by slot->lock) to either
POWERON_STATE (for enabling) or POWEROFF_STATE (for disabling).
  => Submit the work item for pciehp_power_thread() to slot->wq.

Problem:
  There is a problem if the hotplug events can happen fast enough that
  they do not give SW enough time to add or remove the new devices.

  => Assume: Event for unplug comes (e.g. surprise removal). But
 before the pciehp_power_thread() work item was executed, the
 card was replaced by another card, causing surprise hotplug event.

  => What goes wrong:
=> The hot-removal event sets slot->state to POWEROFF_STATE, and
   schedules the pciehp_power_thread().
=> The hot-add event sets slot->state to POWERON_STATE, and
   schedules the pciehp_power_thread().
=> Now the pciehp_power_thread() is scheduled twice, and on both
   occasions it will find POWERON_STATE and will try to add the
   devices on the slot, and will fail complaining that the devices
   already exist.

  => Why this is a problem: If the device was replaced between the hot
 removal and hot-add, then we should unload the old driver and
 reload the new one. This does not happen today. The kernel or the
 driver is not even aware that the device was replaced.

 The problem is that the pciehp_power_thread() only looks at the
 slot->state which would only contain the *latest* state - not
 the actual event (add / remove) that was the intent of the IRQ
 handler who submitted the work.

What this patch does:

  => Hotplug events pass on an actual request (for addition or removal)
 to pciehp_power_thread() which is local to that work item
 submission.

  => pciehp_power_thread() does not need to look at slote->state and
 hence no locks needed in that.

  => Essentially this results in all the hotplug and unplug events
 "replayed" by pciehp_power_thread().

Signed-off-by: Rajat Jain 
Signed-off-by: Rajat Jain 
Signed-off-by: Guenter Roeck 
---
 drivers/pci/hotplug/pciehp_ctrl.c |   29 -
 1 file changed, 20 insertions(+), 9 deletions(-)

diff --git a/drivers/pci/hotplug/pciehp_ctrl.c 
b/drivers/pci/hotplug/pciehp_ctrl.c
index b418e3b..3e40ec0 100644
--- a/drivers/pci/hotplug/pciehp_ctrl.c
+++ b/drivers/pci/hotplug/pciehp_ctrl.c
@@ -276,6 +276,9 @@ static int remove_board(struct slot *p_slot)
 struct power_work_info {
struct slot *p_slot;
struct work_struct work;
+   unsigned int req;
+#define DISABLE_REQ 0
+#define ENABLE_REQ  1
 };
 
 /**
@@ -291,10 +294,8 @@ static void pciehp_power_thread(struct work_struct *work)
container_of(work, struct power_work_info, work);
struct slot *p_slot = info->p_slot;
 
-   mutex_lock(_slot->lock);
-   switch (p_slot->state) {
-   case POWEROFF_STATE:
-   mutex_unlock(_slot->lock);
+   switch (info->req) {
+   case DISABLE_REQ:
ctrl_dbg(p_slot->ctrl,
 "Disabling domain:bus:device=%04x:%02x:00\n",
 pci_domain_nr(p_slot->ctrl->pcie->port->subordinate),
@@ -302,18 +303,22 @@ static void pciehp_power_thread(struct work_struct *work)
pciehp_disable_slot(p_slot);
mutex_lock(_slot->lock);
p_slot->state = STATIC_STATE;
-   break;
-   case POWERON_STATE:
mutex_unlock(_slot->lock);
+   break;
+   case ENABLE_REQ:
+   ctrl_dbg(p_slot->ctrl,
+"Enabling domain:bus:device=%04x:%02x:00\n",
+pci_domain_nr(p_slot->ctrl->pcie->port->subordinate),
+p_slot->ctrl->pcie->port->subordinate->number);
if (pciehp_enable_slot(p_slot))
pciehp_green_led_off(p_slot);
mutex_lock(_slot->lock);
p_slot->state = STATIC_STATE;
+   mutex_unlock(_slot->lock);
break;
default:
break;
}
-   mutex_unlock(_slot->lock);
 
kfree(info);
 }
@@ -336,9 +341,11 @@ void pciehp_queue_pushbutton_work(struct work_struct *work)
switch (p_slot->state) {
case BLINKINGOFF_STATE:
p_slot->state = POWEROFF_STATE;
+   info->req = DISABLE_REQ;
break;
case BLINKINGON_STATE:
p_slot->state = POWERON_STATE;
+   info->req = ENABLE_REQ;
break;
default:
kfree(info);
@@ -428,10 +435,13 @@ static void handle_surprise_event(struct slot *p_slot)
INIT_WORK(>work, pciehp_power_thread);
 
pciehp_get_adapter_status(p_slot, );
-   if (!getstatus)
+   if (!getstatus) {
p_slot->state = POWEROFF_STATE;
-   else
+   info->req = DISABLE_REQ;
+   } else {
  

[PATCH v4 4/8] pciehp: Don't disable the link permanently, during removal

[Rajat Jain]

We need future link up events for hot-add, thus don't disable
the link permanently during device removal. Also, remove the static
functions that are now left unused.

This reverts part of 2debd9289997 ("PCI: pciehp: Disable/enable link
during slot power off/on"). This was dicussed at
http://marc.info/?l=linux-pci=138963477507425=2
where it was revealed that it was done for a bug in a pcie repeater
chip on that particular platform.

Signed-off-by: Rajat Jain 
Signed-off-by: Rajat Jain 
Signed-off-by: Guenter Roeck 
---
 drivers/pci/hotplug/pciehp_hpc.c |   18 --
 1 file changed, 18 deletions(-)

diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
index 245a3cb..15ca3a1 100644
--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/drivers/pci/hotplug/pciehp_hpc.c
@@ -242,11 +242,6 @@ static void pcie_wait_link_active(struct controller *ctrl)
__pcie_wait_link_active(ctrl, true);
 }
 
-static void pcie_wait_link_not_active(struct controller *ctrl)
-{
-   __pcie_wait_link_active(ctrl, false);
-}
-
 static bool pci_bus_check_dev(struct pci_bus *bus, int devfn)
 {
u32 l;
@@ -332,11 +327,6 @@ static int pciehp_link_enable(struct controller *ctrl)
return __pciehp_link_set(ctrl, true);
 }
 
-static int pciehp_link_disable(struct controller *ctrl)
-{
-   return __pciehp_link_set(ctrl, false);
-}
-
 void pciehp_get_attention_status(struct slot *slot, u8 *status)
 {
struct controller *ctrl = slot->ctrl;
@@ -508,14 +498,6 @@ void pciehp_power_off_slot(struct slot * slot)
 {
struct controller *ctrl = slot->ctrl;
 
-   /* Disable the link at first */
-   pciehp_link_disable(ctrl);
-   /* wait the link is down */
-   if (ctrl->link_active_reporting)
-   pcie_wait_link_not_active(ctrl);
-   else
-   msleep(1000);
-
pcie_write_cmd(ctrl, PCI_EXP_SLTCTL_PWR_OFF, PCI_EXP_SLTCTL_PCC);
ctrl_dbg(ctrl, "%s: SLOTCTRL %x write cmd %x\n", __func__,
 pci_pcie_cap(ctrl->pcie->port) + PCI_EXP_SLTCTL,
-- 
1.7.9.5

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

[PATCH v4 5/8] pciehp: Don't check for adapter or latch status while disabling

[Rajat Jain]

It does not make much sense to refuse to disable a slot if an
adapter is not present or the latch is open. If an adapter is not
present, it provides an even better reason to disable the device
slot.

This is specially a problem for link state hot-plug, because some
ports use in band mechanism for presence detection. Thus
when link goes down, presence detect also goes down. We _want_ that
the removal should take place in such case.

Thus remove the checks for adapter and latch in pciehp_disable_slot()

Signed-off-by: Rajat Jain 
Signed-off-by: Rajat Jain 
Signed-off-by: Guenter Roeck 
---
 drivers/pci/hotplug/pciehp_ctrl.c |   18 --
 1 file changed, 18 deletions(-)

diff --git a/drivers/pci/hotplug/pciehp_ctrl.c 
b/drivers/pci/hotplug/pciehp_ctrl.c
index 5608284..b418e3b 100644
--- a/drivers/pci/hotplug/pciehp_ctrl.c
+++ b/drivers/pci/hotplug/pciehp_ctrl.c
@@ -582,24 +582,6 @@ int pciehp_disable_slot(struct slot *p_slot)
if (!p_slot->ctrl)
return 1;
 
-   if (!HP_SUPR_RM(p_slot->ctrl)) {
-   pciehp_get_adapter_status(p_slot, );
-   if (!getstatus) {
-   ctrl_info(ctrl, "No adapter on slot(%s)\n",
- slot_name(p_slot));
-   return -ENODEV;
-   }
-   }
-
-   if (MRL_SENS(p_slot->ctrl)) {
-   pciehp_get_latch_status(p_slot, );
-   if (getstatus) {
-   ctrl_info(ctrl, "Latch open on slot(%s)\n",
- slot_name(p_slot));
-   return -ENODEV;
-   }
-   }
-
if (POWER_CTRL(p_slot->ctrl)) {
pciehp_get_power_status(p_slot, );
if (!getstatus) {
-- 
1.7.9.5

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

[PATCH v4 2/8] pciehp: Use link change notifications for hot-plug and removal

[Rajat Jain]

A lot of systems do not have the fancy buttons and LEDs, and instead
want to rely only on the Link state change events to drive the hotplug
and removal state machinery.
(http://www.spinics.net/lists/hotplug/msg05802.html)

This patch adds support for that functionality. Here are the details
about the patch itself:

* Define and use interrupt events for linkup / linkdown.

* Make the pcie_isr() also look at link events, and direct control to
  corresponding (new) link state change handler function.

* Introduce the functions to handle link-up and link-down events and
  queue the add / removal work in the slot->wq to be processed by
  pciehp_power_thread()

As a side note, this patch also fixes the bug
https://bugzilla.kernel.org/show_bug.cgi?id=65521

Signed-off-by: Rajat Jain 
Signed-off-by: Rajat Jain 
Signed-off-by: Guenter Roeck 
---
 drivers/pci/hotplug/pciehp.h  |3 ++
 drivers/pci/hotplug/pciehp_ctrl.c |   88 +
 drivers/pci/hotplug/pciehp_hpc.c  |6 ++-
 3 files changed, 96 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/hotplug/pciehp.h b/drivers/pci/hotplug/pciehp.h
index f952459..d8d0336 100644
--- a/drivers/pci/hotplug/pciehp.h
+++ b/drivers/pci/hotplug/pciehp.h
@@ -109,6 +109,8 @@ struct controller {
 #define INT_BUTTON_PRESS   7
 #define INT_BUTTON_RELEASE 8
 #define INT_BUTTON_CANCEL  9
+#define INT_LINK_UP10
+#define INT_LINK_DOWN  11
 
 #define STATIC_STATE   0
 #define BLINKINGON_STATE   1
@@ -132,6 +134,7 @@ u8 pciehp_handle_attention_button(struct slot *p_slot);
 u8 pciehp_handle_switch_change(struct slot *p_slot);
 u8 pciehp_handle_presence_change(struct slot *p_slot);
 u8 pciehp_handle_power_fault(struct slot *p_slot);
+void pciehp_handle_linkstate_change(struct slot *p_slot);
 int pciehp_configure_device(struct slot *p_slot);
 int pciehp_unconfigure_device(struct slot *p_slot);
 void pciehp_queue_pushbutton_work(struct work_struct *work);
diff --git a/drivers/pci/hotplug/pciehp_ctrl.c 
b/drivers/pci/hotplug/pciehp_ctrl.c
index 5062848..5608284 100644
--- a/drivers/pci/hotplug/pciehp_ctrl.c
+++ b/drivers/pci/hotplug/pciehp_ctrl.c
@@ -150,6 +150,27 @@ u8 pciehp_handle_power_fault(struct slot *p_slot)
return 1;
 }
 
+void pciehp_handle_linkstate_change(struct slot *p_slot)
+{
+   u32 event_type;
+   struct controller *ctrl = p_slot->ctrl;
+
+   /* Link Status Change */
+   ctrl_dbg(ctrl, "Data Link Layer State change\n");
+
+   if (pciehp_check_link_active(ctrl)) {
+   ctrl_info(ctrl, "slot(%s): Link Up event\n",
+ slot_name(p_slot));
+   event_type = INT_LINK_UP;
+   } else {
+   ctrl_info(ctrl, "slot(%s): Link Down event\n",
+ slot_name(p_slot));
+   event_type = INT_LINK_DOWN;
+   }
+
+   queue_interrupt_event(p_slot, event_type);
+}
+
 /* The following routines constitute the bulk of the
hotplug controller logic
  */
@@ -415,6 +436,69 @@ static void handle_surprise_event(struct slot *p_slot)
queue_work(p_slot->wq, >work);
 }
 
+/*
+ * Note: This function must be called with slot->lock held
+ */
+static void handle_link_event(struct slot *p_slot, u32 event)
+{
+   struct controller *ctrl = p_slot->ctrl;
+   struct power_work_info *info;
+
+   info = kmalloc(sizeof(*info), GFP_KERNEL);
+   if (!info) {
+   ctrl_err(p_slot->ctrl, "%s: Cannot allocate memory\n",
+__func__);
+   return;
+   }
+   info->p_slot = p_slot;
+   INIT_WORK(>work, pciehp_power_thread);
+
+   switch (p_slot->state) {
+   case BLINKINGON_STATE:
+   case BLINKINGOFF_STATE:
+   cancel_delayed_work(_slot->work);
+   /* Fall through */
+   case STATIC_STATE:
+   p_slot->state = event == INT_LINK_UP ?
+   POWERON_STATE : POWEROFF_STATE;
+   queue_work(p_slot->wq, >work);
+   break;
+   case POWERON_STATE:
+   if (event == INT_LINK_UP) {
+   ctrl_info(ctrl,
+ "Link Up event ignored on slot(%s): already 
powering on\n",
+ slot_name(p_slot));
+   kfree(info);
+   } else {
+   ctrl_info(ctrl,
+ "Link Down event queued on slot(%s): 
currently getting powered on\n",
+ slot_name(p_slot));
+   p_slot->state = POWEROFF_STATE;
+   queue_work(p_slot->wq, >work);
+   }
+   break;
+   case POWEROFF_STATE:
+   if (event == INT_LINK_UP) {
+   ctrl_info(ctrl,
+ "Link Up event queued on slot(%s): currently 
getting powered off\n",
+

[PATCH v4 3/8] pciehp: Enable link state change notifications

[Rajat Jain]

Enabled the Link state notifications unconditionaly. Enable the
presence detection notification only if attention button is absent.
This was discussed at this thread:
http://marc.info/?t=13861101431=1=2

Signed-off-by: Rajat Jain 
Signed-off-by: Rajat Jain 
Signed-off-by: Guenter Roeck 
---
 drivers/pci/hotplug/pciehp_hpc.c |   13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
index b413dce..245a3cb 100644
--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/drivers/pci/hotplug/pciehp_hpc.c
@@ -600,9 +600,17 @@ void pcie_enable_notification(struct controller *ctrl)
 * when it is cleared in the interrupt service routine, and
 * next power fault detected interrupt was notified again.
 */
-   cmd = PCI_EXP_SLTCTL_PDCE;
+
+   /*
+* Always enable link events: thus link-up and link-down shall
+* always be treated as hotplug and unplug respectively. Enable
+* presence detect only if Attention Button is not present.
+*/
+   cmd = PCI_EXP_SLTCTL_DLLSCE;
if (ATTN_BUTTN(ctrl))
cmd |= PCI_EXP_SLTCTL_ABPE;
+   else
+   cmd |= PCI_EXP_SLTCTL_PDCE;
if (MRL_SENS(ctrl))
cmd |= PCI_EXP_SLTCTL_MRLSCE;
if (!pciehp_poll_mode)
@@ -610,7 +618,8 @@ void pcie_enable_notification(struct controller *ctrl)
 
mask = (PCI_EXP_SLTCTL_PDCE | PCI_EXP_SLTCTL_ABPE |
PCI_EXP_SLTCTL_MRLSCE | PCI_EXP_SLTCTL_PFDE |
-   PCI_EXP_SLTCTL_HPIE | PCI_EXP_SLTCTL_CCIE);
+   PCI_EXP_SLTCTL_HPIE | PCI_EXP_SLTCTL_CCIE |
+   PCI_EXP_SLTCTL_DLLSCE);
 
pcie_write_cmd(ctrl, cmd, mask);
 }
-- 
1.7.9.5

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

[PATCH v4 1/8] pciehp: Make check_link_active() non-static

[Rajat Jain]

check_link_active() functionality needs to be used by subsequent patches
(that introduce link state change based hotplug). Thus make the function
non-static, and rename it to pciehp_check_link_active() so as to be
consistent with other non-static functions.

Signed-off-by: Rajat Jain 
Signed-off-by: Rajat Jain 
Signed-off-by: Guenter Roeck 
---
 drivers/pci/hotplug/pciehp.h |1 +
 drivers/pci/hotplug/pciehp_hpc.c |6 +++---
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/hotplug/pciehp.h b/drivers/pci/hotplug/pciehp.h
index 88b37ca..f952459 100644
--- a/drivers/pci/hotplug/pciehp.h
+++ b/drivers/pci/hotplug/pciehp.h
@@ -153,6 +153,7 @@ void pciehp_green_led_on(struct slot *slot);
 void pciehp_green_led_off(struct slot *slot);
 void pciehp_green_led_blink(struct slot *slot);
 int pciehp_check_link_status(struct controller *ctrl);
+bool pciehp_check_link_active(struct controller *ctrl);
 void pciehp_release_ctrl(struct controller *ctrl);
 int pciehp_reset_slot(struct slot *slot, int probe);
 
diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
index 14acfcc..aed6ab4 100644
--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/drivers/pci/hotplug/pciehp_hpc.c
@@ -206,7 +206,7 @@ static void pcie_write_cmd(struct controller *ctrl, u16 
cmd, u16 mask)
mutex_unlock(>ctrl_lock);
 }
 
-static bool check_link_active(struct controller *ctrl)
+bool pciehp_check_link_active(struct controller *ctrl)
 {
struct pci_dev *pdev = ctrl_dev(ctrl);
u16 lnk_status;
@@ -225,12 +225,12 @@ static void __pcie_wait_link_active(struct controller 
*ctrl, bool active)
 {
int timeout = 1000;
 
-   if (check_link_active(ctrl) == active)
+   if (pciehp_check_link_active(ctrl) == active)
return;
while (timeout > 0) {
msleep(10);
timeout -= 10;
-   if (check_link_active(ctrl) == active)
+   if (pciehp_check_link_active(ctrl) == active)
return;
}
ctrl_dbg(ctrl, "Data Link Layer Link Active not %s in 1000 msec\n",
-- 
1.7.9.5

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

[PATCH v4 0/8] Allow Link state changes for Hot-Plug

[Rajat Jain]

Hello,

This patch set enables the use of PCI Express link up and link down events
for Hotplug or Unplug. This is the pretty much the same patchset as v3, only
resending after rebasing on top of 3.14-rc1.

(As a side effect, this patch also fixes the bug 
https://bugzilla.kernel.org/show_bug.cgi?id=65521 )

I'd appreciate if you could please review and provide me with any comments.

Thanks,

Rajat

Rajat Jain (8):
  pciehp: Make check_link_active() non-static
  pciehp: Use link change notifications for hot-plug and removal
  pciehp: Enable link state change notifications
  pciehp: Don't disable the link permanently, during removal
  pciehp: Don't check for adapter or latch status while disabling
  pciehp: Disabling the link notification across slot reset
  pciehp: Ensure very fast hotplug events are also processed.
  pciehp: Introduce hotplug_lock to serialize HP events

 drivers/pci/hotplug/pciehp.h  |5 ++
 drivers/pci/hotplug/pciehp_core.c |7 +-
 drivers/pci/hotplug/pciehp_ctrl.c |  149 ++---
 drivers/pci/hotplug/pciehp_hpc.c  |   74 +-
 4 files changed, 169 insertions(+), 66 deletions(-)

-- 
1.7.9.5

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

Re: [RFCv2 01/10] xhci: Use command structures when calling xhci_configure_endpoint

[Dan Williams]

Hi Mathias, comments below:

On Thu, Jan 30, 2014 at 6:10 AM, Mathias Nyman
 wrote:
> To create a global command queue we need to fill a command structure
> for each entry on the command ring.
>
> We start by requiring xhci_configure_endpoint() to be called with
> a proper command structure. Functions xhci_check_maxpacket and 
> xhci_check_bandwith

s/xhci_check_bandwith/xhci_check_bandwidth/

> that called xhci_configure_endpoint without a command strucure are fixed.

s/strucure/structure/

>
> A special case where an endpoint needs to be configured after reset, done in 
> interrupt
> context is also changed to create a command strucure. (this command

s/strucure/structure/

> structure is not used yet, but will be later when we requre all queued 
> commands

s/requre/require/

> to have a command strucure)

s/strucure/structure/

>
> Signed-off-by: Mathias Nyman 
> ---
>  drivers/usb/host/xhci-ring.c | 10 ++---
>  drivers/usb/host/xhci.c  | 97 
> 
>  2 files changed, 56 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index 1e2f3f4..da83a844 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -1180,12 +1180,15 @@ static void xhci_handle_cmd_reset_ep(struct xhci_hcd 
> *xhci, int slot_id,
>  * because the HW can't handle two commands being queued in a row.
>  */
> if (xhci->quirks & XHCI_RESET_EP_QUIRK) {
> +   struct xhci_command *command;
> +   command = xhci_alloc_command(xhci, false, false, GFP_ATOMIC);

One cleanup we may want to consider in this series is making
xhci_alloc_command() more readable.  My brain hurts when I see "false,
false" as I wonder what that means.  I took a look and of the 4
possible ways to call xhci_alloc_command, we only use 2:

$ git grep xhci_alloc_command\(.*\) | grep -o
xhci_alloc_command\(xhci,.*,.*, | sort -u
xhci_alloc_command(xhci, false, true,
xhci_alloc_command(xhci, true, true,

So a first take is to just have a xhci_alloc_command() for "true,
true" and a xhci_alloc_command_no_ctx() for "false, true".

...uh oh, this series adds a usage of:
xhci_alloc_command(xhci, false, false,

...any reason we can't just use something like
xhci_alloc_command_no_ctx() instead?

Actually just make xhci_alloc_command() take an option in_ctx
parameter, when it is NULL xhci_alloc_command will allocate one,
otherwise it will use the passed in one.

> xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
> "Queueing configure endpoint command");
> xhci_queue_configure_endpoint(xhci,
> xhci->devs[slot_id]->in_ctx->dma, slot_id,
> false);
> xhci_ring_cmd_db(xhci);
> +   kfree(command);

It's not really acceptable to add dead code in a patch.  Consider the
case where some of the patches are reverted due to a regression.  If,
for example we revert patch 2, the unused infrastructure in patch1
does not get deleted.  Patch size minimization is good, but not when
it separates new infrastructure from its first user.

> } else {
> /* Clear our internal halted state and restart the ring(s) */
> xhci->devs[slot_id]->eps[ep_index].ep_state &= ~EP_HALTED;
> @@ -1439,7 +1442,7 @@ static void xhci_handle_cmd_config_ep(struct xhci_hcd 
> *xhci, int slot_id,
> add_flags - SLOT_FLAG == drop_flags) {
> ep_state = virt_dev->eps[ep_index].ep_state;
> if (!(ep_state & EP_HALTED))
> -   goto bandwidth_change;
> +   return;
> xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
> "Completed config ep cmd - "
> "last ep index = %d, state = %d",
> @@ -1449,11 +1452,6 @@ static void xhci_handle_cmd_config_ep(struct xhci_hcd 
> *xhci, int slot_id,
> ring_doorbell_for_active_rings(xhci, slot_id, ep_index);
> return;
> }
> -bandwidth_change:
> -   xhci_dbg_trace(xhci,  trace_xhci_dbg_context_change,
> -   "Completed config ep cmd");
> -   virt_dev->cmd_status = cmd_comp_code;
> -   complete(_dev->cmd_completion);
> return;

This change has no description in the change log.  What's the reason
for deleting the goto?

>  }
>
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index 4265b48..a40485e 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -1179,10 +1179,10 @@ static int xhci_configure_endpoint(struct xhci_hcd 
> *xhci,
>  static int xhci_check_maxpacket(struct xhci_hcd *xhci, unsigned int slot_id,
> unsigned int ep_index, struct urb *urb)
>  {
> -   struct xhci_container_ctx *in_ctx;
> struct xhci_container_ctx *out_ctx;
> 

Re: [patch 00/10] mm: thrash detection-based file cache sizing v9

[Johannes Weiner]

On Tue, Feb 04, 2014 at 03:14:24PM -0800, Andrew Morton wrote:
> On Mon,  3 Feb 2014 19:53:32 -0500 Johannes Weiner  wrote:
> 
> > o Fix vmstat build problems on UP (Fengguang Wu's build bot)
> > 
> > o Clarify why optimistic radix_tree_node->private_list link checking
> >   is safe without holding the list_lru lock (Dave Chinner)
> > 
> > o Assert locking balance when the list_lru isolator says it dropped
> >   the list lock (Dave Chinner)
> > 
> > o Remove remnant of a manual reclaim counter in the shadow isolator,
> >   the list_lru-provided accounting is accurate now that we added
> >   LRU_REMOVED_RETRY (Dave Chinner)
> > 
> > o Set an object limit for the shadow shrinker instead of messing with
> >   its seeks setting.  The configured seeks define how pressure applied
> >   to pages translates to pressure on the object pool, in itself it is
> >   not enough to replace proper object valuation to classify expired
> >   and in-use objects.  Shadow nodes contain up to 64 shadow entries
> >   from different/alternating zones that have their own atomic age
> >   counter, so determining if a node is overall expired is crazy
> >   expensive.  Instead, use an object limit above which nodes are very
> >   likely to be expired.
> > 
> > o __pagevec_lookup and __find_get_pages kerneldoc fixes (Minchan Kim)
> > 
> > o radix_tree_node->count accessors for pages and shadows (Minchan Kim)
> > 
> > o Rebase to v3.14-rc1 and add review tags
> 
> An earlier version caused a 24-byte inode bloatage.  That appears to
> have been reduced to 8 bytes, yes?  What was done there?

Instead of inodes, the shrinker now directly tracks radix tree nodes
that contain only shadow entries.  So the 16 bytes for the list_head
are now in struct radix_tree_node, but due to different slab packing
it didn't increase memory consumption.

> > 69 files changed, 1438 insertions(+), 462 deletions(-)
> 
> omigod

Most of it is comments and Minchan's accessor functions.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv2 2/2] arm: Get rid of meminfo

[Jason Cooper]

On Tue, Feb 04, 2014 at 04:02:31PM -0800, Laura Abbott wrote:
> memblock is now fully integrated into the kernel and is the prefered
> method for tracking memory. Rather than reinvent the wheel with
> meminfo, migrate to using memblock directly instead of meminfo as
> an intermediate.
> 
> Signed-off-by: Laura Abbott 
> ---
...
>  arch/arm/mach-orion5x/common.c   |3 +-
>  arch/arm/mach-orion5x/common.h   |3 +-
...

Acked-by: Jason Cooper 

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 00/22] perf tools: Display tracepoint enahncements

[Namhyung Kim]

On Sun,  2 Feb 2014 22:38:48 +0100, Jiri Olsa wrote:
> hi,
> sending out tracepoint (mostly) events display enahncements.
>
> * adding the '--tp' option for report command to show
>   tracepoint related info. Use can specify following switches:
> fields: shows separated tracepoint fields
> format: shows tracepoints 'print fmt' in single column
>  (This is default if no switch is given.)

Looks like an useful feature.. but unfortunately it seems not to work
well with --children and (especially) --group options.  Do you have an
idea?

Also as Ingo requested I plan to extend controlling output column with
-F/--field option.  I think I need to more consideration..

Thanks,
Namhyung


>
>   $ perf report --tp --no-children
>   Samples: 4K of event 'sched:sched_switch', Event count (approx.): 4788
>Overhead  Command  Shared Object  Symbol  Print fmt
>   +  26.27%  swapper  [kernel.kallsyms]  [k] __schedule  swapper/2:0 
> [120] R ==> offlineimap:22134 [120]
>   +  26.27%  offlineimap  [kernel.kallsyms]  [k] __schedule  
> offlineimap:22134 [120] S ==> swapper/2:0 [120]
>   -   8.15%  swapper  [kernel.kallsyms]  [k] __schedule  swapper/3:0 
> [120] R ==> offlineimap:22134 [120]
>__schedule
>schedule_preempt_disabled
>cpu_startup_entry
>start_secondary
>   +   8.15%  offlineimap  [kernel.kallsyms]  [k] __schedule  
> offlineimap:22134 [120] S ==> swapper/3:0 [120]
>
>   $ perf report --tp=fields --no-children
>   Samples: 4K of event 'sched:sched_switch', Event count (approx.): 4788
> Overhead  Command  Shared Object  Symbol  
>  prev_commprev_pid   prev_prio  prev_state
>next_commnext_pid   next_prio
>   +   26.27%  swapper  [kernel.kallsyms]  [k] __schedule  
>  swapper/2   0 120   0
>  offlineimap   22134 120
>   +   26.27%  offlineimap  [kernel.kallsyms]  [k] __schedule  
>offlineimap   22134 120   1
>swapper/2   0 120
>   -8.15%  swapper  [kernel.kallsyms]  [k] __schedule  
>  swapper/3   0 120   0
>  offlineimap   22134 120
>__schedule
>schedule_preempt_disabled
>cpu_startup_entry
>start_secondary
>   +8.15%  offlineimap  [kernel.kallsyms]  [k] __schedule  
>offlineimap   22134 120   1
>swapper/3   0 120
>
>
> * adding '--list' report option to display entries sequentialy:
>
>   Samples: 2K of event 'sched:sched_switch', Event count (approx.): 2450
> Self  Children  Time  Command 
>Shared Object  
>  Symbol  Print fmt
>   +0.04% 0.04%9582.431783 +00.00  swapper  
> [kernel.kallsyms][k] __schedule   
> swapper/1:0 [120] R ==> perf:11168 [120]
>   -0.00% 0.04%9582.431783 +00.00  swapper  
> [kernel.kallsyms][k] __schedule   
> swapper/1:0 [120] R ==> perf:11168 [120]
>__schedule
>schedule
>cpu_idle
>start_secondary
>   +0.00% 0.04%9582.431783 +00.00  swapper  
> [kernel.kallsyms][k] schedule 
> swapper/1:0 [120] R ==> perf:11168 [120]
>   +0.00% 0.04%9582.431783 +00.00  swapper  
> [kernel.kallsyms][k] cpu_idle 
> swapper/1:0 [120] R ==> perf:11168 [120]
>
> * adding 'H' key handler to togle header columns
>
>
> thanks for comments,
> jirka
>
>
> Signed-off-by: Jiri Olsa 
> Cc: Corey Ashford 
> Cc: Frederic Weisbecker 
> Cc: Ingo Molnar 
> Cc: Namhyung Kim 
> Cc: Paul Mackerras 
> Cc: Peter Zijlstra 
> Cc: Arnaldo Carvalho de Melo 
> Cc: Steven Rostedt 
> Cc: David Ahern 
> ---
> Jiri Olsa (22):
>   perf tools: Fix memory leak in event_format__print function
>   perf tools: Add time sort entry
>   perf tools: Add idx sort entry
>   perf tools: Add --list report option
>   perf tools: Add sort_entry struct into sort entries callbacks
>   perf tools: Add selected bool into se_snprintf sort entries callback
>   perf tools: Implement selected bool se_snprintf callback logic
>   perf tools: Implement selected logic for time sort entry
>   perf tools: Factor ui_browser ops out of ui_browser struct
>   perf tools: Add header callback into ui_browser_ops struct
>   perf tools: Remove ev_name 

Re: [patch 10/10] mm: keep page cache radix tree nodes in check

[Johannes Weiner]

On Tue, Feb 04, 2014 at 03:07:56PM -0800, Andrew Morton wrote:
> On Mon,  3 Feb 2014 19:53:42 -0500 Johannes Weiner  wrote:
> 
> > Previously, page cache radix tree nodes were freed after reclaim
> > emptied out their page pointers.  But now reclaim stores shadow
> > entries in their place, which are only reclaimed when the inodes
> > themselves are reclaimed.  This is problematic for bigger files that
> > are still in use after they have a significant amount of their cache
> > reclaimed, without any of those pages actually refaulting.  The shadow
> > entries will just sit there and waste memory.  In the worst case, the
> > shadow entries will accumulate until the machine runs out of memory.
> > 
> > To get this under control, the VM will track radix tree nodes
> > exclusively containing shadow entries on a per-NUMA node list.
> > Per-NUMA rather than global because we expect the radix tree nodes
> > themselves to be allocated node-locally and we want to reduce
> > cross-node references of otherwise independent cache workloads.  A
> > simple shrinker will then reclaim these nodes on memory pressure.

^^^
> > A few things need to be stored in the radix tree node to implement the
> > shadow node LRU and allow tree deletions coming from the list:
> > 
> > 1. There is no index available that would describe the reverse path
> >from the node up to the tree root, which is needed to perform a
> >deletion.  To solve this, encode in each node its offset inside the
> >parent.  This can be stored in the unused upper bits of the same
> >member that stores the node's height at no extra space cost.
> > 
> > 2. The number of shadow entries needs to be counted in addition to the
> >regular entries, to quickly detect when the node is ready to go to
> >the shadow node LRU list.  The current entry count is an unsigned
> >int but the maximum number of entries is 64, so a shadow counter
> >can easily be stored in the unused upper bits.
> > 
> > 3. Tree modification needs tree lock and tree root, which are located
> >in the address space, so store an address_space backpointer in the
> >node.  The parent pointer of the node is in a union with the 2-word
> >rcu_head, so the backpointer comes at no extra cost as well.
> > 
> > 4. The node needs to be linked to an LRU list, which requires a list
> >head inside the node.  This does increase the size of the node, but
> >it does not change the number of objects that fit into a slab page.
> 
> changelog forgot to mention that this reclaim is performed via a
> shrinker...

Uhm...  see above? :)

> How expensive is that list walk in scan_shadow_nodes()?  I assume in
> the best case it will bale out after nr_to_scan iterations?

Yes, it scans sc->nr_to_scan radix tree nodes, cleans their pointers,
and frees them.

I ran a worst-case scenario on an 8G machine that creates one 8T
sparse file and faults one page per 64-page radix tree node, i.e. one
node per sparse file fault at CPU speed.  The profile:

 1   9.21% radixblow  [kernel.kallsyms]   [k] memset
 2   7.23% radixblow  [kernel.kallsyms]   [k] do_mpage_readpage
 3   4.76% radixblow  [kernel.kallsyms]   [k] 
copy_user_generic_string
 4   3.85% radixblow  [kernel.kallsyms]   [k] __radix_tree_lookup
 5   3.32%   kswapd0  [kernel.kallsyms]   [k] shadow_lru_isolate
 6   2.92% radixblow  [kernel.kallsyms]   [k] get_page_from_freelist
 7   2.81%   kswapd0  [kernel.kallsyms]   [k] 
__delete_from_page_cache
 8   2.50% radixblow  [kernel.kallsyms]   [k] radix_tree_node_ctor
 9   1.79% radixblow  [kernel.kallsyms]   [k] _raw_spin_lock_irq
10   1.70%   kswapd0  [kernel.kallsyms]   [k] 
__mem_cgroup_uncharge_common

Same scenario with 4 pages per 64-page radix tree node:

13   1.39%   kswapd0  [kernel.kallsyms]   [k] shadow_lru_isolate

16 pages per 64-page node:

75   0.20%   kswapd0  [kernel.kallsyms]   [k] shadow_lru_isolate

So I doubt this will bother anyone, especially since most use-once
streamers should have a better population density and populate cache
at disk speed, not CPU speed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 3/3] arm64: audit: Add audit hook in ptrace/syscall_trace

[AKASHI Takahiro]

On 02/05/2014 02:31 AM, Will Deacon wrote:

On Mon, Feb 03, 2014 at 06:56:30AM +, AKASHI Takahiro wrote:

This patch adds auditing functions on entry to or exit from
every system call invocation.

Signed-off-by: AKASHI Takahiro 
---
  arch/arm64/include/asm/thread_info.h |1 +
  arch/arm64/kernel/entry.S|3 +++
  arch/arm64/kernel/ptrace.c   |   10 ++
  3 files changed, 14 insertions(+)

diff --git a/arch/arm64/include/asm/thread_info.h 
b/arch/arm64/include/asm/thread_info.h
index 720e70b..7468388 100644
--- a/arch/arm64/include/asm/thread_info.h
+++ b/arch/arm64/include/asm/thread_info.h
@@ -101,6 +101,7 @@ static inline struct thread_info *current_thread_info(void)
  #define TIF_NEED_RESCHED  1
  #define TIF_NOTIFY_RESUME 2   /* callback before returning to user */
  #define TIF_SYSCALL_TRACE 8
+#define TIF_SYSCALL_AUDIT  9
  #define TIF_POLLING_NRFLAG16
  #define TIF_MEMDIE18  /* is terminating due to OOM killer */
  #define TIF_FREEZE19
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 827cbad..83c4b29 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -630,6 +630,9 @@ el0_svc_naked:  // 
compat entry point
get_thread_info tsk
ldr x16, [tsk, #TI_FLAGS]   // check for syscall tracing
tbnzx16, #TIF_SYSCALL_TRACE, __sys_trace // are we tracing syscalls?
+#ifdef CONFIG_AUDITSYSCALL
+   tbnzx16, #TIF_SYSCALL_AUDIT, __sys_trace // auditing syscalls?
+#endif


Could we avoid the back-to-back tbnz instructions with a single mask? It's
not obvious that it will end up any better, but it would be good to know.


When first implementing ftrace support, TIF_SYSCALL_TRACEPOINT is defined as 10
and 'tst' instruction doesn't allow the following code:
tst x16, #(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_TRACEPOINT)

That is why I've used "back-to-back" tbnz since then, but now that I'm going to
submit ftrace, audit and later seccomp, I will replace it with:
#define TIF_SYSCALL_WORK (_TIF_SYSCALL_TRACE|TRACEPOINT|AUDIT|SECCOMP)

tst x16, #TIF_SYSCALL_WORK
b.ne __syscall_trace



adr lr, ret_fast_syscall// return address
cmp scno, sc_nr // check upper syscall limit
b.hsni_sys
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 6777a21..75a3f23 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -19,6 +19,7 @@
   * along with this program.  If not, see .
   */

+#include 
  #include 
  #include 
  #include 
@@ -38,6 +39,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 

@@ -1064,6 +1066,14 @@ asmlinkage int syscall_trace(int dir, struct pt_regs 
*regs)
  {
unsigned long saved_reg;

+   if (dir)
+   audit_syscall_exit(regs);
+   else
+   audit_syscall_entry(syscall_get_arch(current, regs),
+   (int)regs->syscallno,
+   regs->orig_x0, regs->regs[1],
+   regs->regs[2], regs->regs[3]);
+


Do we really want to perform the audit checks before the tracehook calls?
Remember that the latter can rewrite all of the registers.


OK. I will change the code to make calls in the following order:
On entry,
   *secure_computing
   *tracehook_report_syscall(ENTER)
   *trace_sys_enter
   *audit_syscall_entry
On exit,
   *audit_syscall_exit
   *trace_sys_exit
   *tracehook_report_syscall(EXIT)

The order here is the exact same as on x86, but such change might
decrease the readability in syscall_trace().

Thanks,
-Takahiro AKASHI


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 04/22] perf tools: Add --list report option

[Namhyung Kim]

On Sun,  2 Feb 2014 22:38:52 +0100, Jiri Olsa wrote:
> Adding --list report option to display entries sequentialy:
>
>   $ perf report --list --stdio
>   ...
>0.00%   13151.543527 +00.00   ls  [kernel.kallsyms]  
> [k] native_write_msr_safe
>0.00%   13151.543530 +00.03   ls  [kernel.kallsyms]  
> [k] native_write_msr_safe
>0.00%   13151.543532 +00.05   ls  [kernel.kallsyms]  
> [k] native_write_msr_safe
>0.00%   13151.543534 +00.07   ls  [kernel.kallsyms]  
> [k] native_write_msr_safe
>0.05%   13151.543536 +00.09   ls  [kernel.kallsyms]  
> [k] native_write_msr_safe
>0.92%   13151.543538 +00.11   ls  [kernel.kallsyms]  
> [k] perf_event_comm
>   14.52%   13151.543560 +00.33   ls  [kernel.kallsyms]  
> [k] uprobe_mmap
>   30.10%   13151.543878 +00.000351   ls  ld-2.17.so 
> [.] _dl_setup_hash
>   29.30%   13151.544531 +00.001004   ls  ls 
> [.] gobble_file.constprop.49
>   25.09%   13151.545613 +00.002086   ls  [kernel.kallsyms]  
> [k] _cond_resched

Hmm.. it seems what this --list option does is very similar to
what "perf script -f time,comm,dso,sym,ip" tries to do, no?

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

Re: [RFC 00/22] perf tools: Display tracepoint enahncements

[Namhyung Kim]

On Sun, 2 Feb 2014 22:45:50 +0100, Jiri Olsa wrote:
> On Sun, Feb 02, 2014 at 10:38:48PM +0100, Jiri Olsa wrote:
>> hi,
>> sending out tracepoint (mostly) events display enahncements.
>
> forgot to mention.. the branch is in here:
>   git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
>   perf/core_tp

It's segfaulted with --group --tui option since the hpp->ptr is not
setup to point an evsel.  Not sure whose problem.. ;-)

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

Re: [PATCHSET 0/5] tracing/uprobes: Support multi buffer and event trigger

[Masami Hiramatsu]

(2014/01/17 17:08), Namhyung Kim wrote:
> Hello,
> (Resending with LKML CC'ed)
> 
> This patchset tries to add support for recent multi buffer and event
> trigger changes to uprobes.  The multi buffer support patch is an
> updated version of Zovi's previous patch v6 [1].
> 
> Zovi, please tell me if you have any update and/or issues with this.
> 
> Masami and Oleg, I kept your Reviewed-by's in the patch since I think
> it's just an rebase.  Please take a look again to see whether I added
> some mistakes.

OK, this series looks good to me. Thank you for enhancing it!
Feel free to add my reviewed-by.

Reviewed-by: Masami Hiramatsu 

Thanks,

> 
> 
> You can also get it from 'uprobe/trigger-v1' branch in my tree
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git
> 
> Any comments are welcome, thanks
> Namhyung
> 
> 
> [1] https://lkml.org/lkml/2013/7/4/165
> 
> Cc: Masami Hiramatsu 
> Cc: Oleg Nesterov 
> Cc: Srikar Dronamraju 
> Cc: zhangwei(Jovi) 
> Cc: Tom Zanussi   
> 
> 
> Namhyung Kim (4):
>   tracing/uprobes: Rename uprobe_{trace,perf}_print() functions
>   tracing/uprobes: Move argument fetching to uprobe_dispatcher()
>   tracing/uprobes: Support event triggering
>   tracing/uprobes: Support mix of ftrace and perf
> 
> zhangwei(Jovi) (1):
>   tracing/uprobes: Support ftrace_event_file base multibuffer
> 
>  kernel/trace/trace_kprobe.c |  17 
>  kernel/trace/trace_probe.h  |  17 
>  kernel/trace/trace_uprobe.c | 191 
> +++-
>  3 files changed, 151 insertions(+), 74 deletions(-)
> 


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


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

Re: [PATCH 01/22] perf tools: Fix memory leak in event_format__print function

[Namhyung Kim]

On Sun,  2 Feb 2014 22:38:49 +0100, Jiri Olsa wrote:
> Properly destroying trace_seq object.
>
> Signed-off-by: Jiri Olsa 
> Cc: Corey Ashford 
> Cc: Frederic Weisbecker 
> Cc: Ingo Molnar 

Acked-by: Namhyung Kim 

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

Re: 3.13.0: crash on boot

[Borislav Petkov]

On Tue, Feb 04, 2014 at 05:30:50PM +0400, Alexandra N. Kossovsky wrote:
> On Feb 03 14:41, Matt Fleming wrote:
> > Alexandra, any chance you could try out a v3.14-rc1 kernel? Basically
> > all of the EFI memory mapping code was rewritten for v3.14.
> 
> v3.14-rc1: kmemleak complains about acpi code plus the same crash in
> efi.  Log and config attached.
> 
> I'll ask my system administrator for BIOS update.

Btw, did this box boot any kernels successfully in EFI mode at all?

...

And this looks like a nasty corruption of RIP state because we're
not getting any Code: section even. And we're choked somewhere in
SetVirtualAddressMap...

> [0.035953] BUG: unable to handle kernel paging request at 000129101020
> [0.044426] IP: [] 0xcf038cc6
> [0.050276] PGD 2967067 PUD 296a067 PMD 12fe99067 PTE 800129101962

and we've switched to the EFI page table (see CR3 below) but we're still
walking some pagetable which cannot be right because show_fault_oops()
doesn't know about the EFI page table (Matt's patch is not in yet). Hmm.

> [0.058361] Oops:  [#1] SMP 
> [0.062863] Modules linked in:
> [0.067143] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
> 3.14.0-rc1-debug-amd64 #1
> [0.076889] Hardware name: Supermicro X9SCL/X9SCM/X9SCL/X9SCM, BIOS 2.0b 
> 09/17/2012
> [0.087007] task: 81a134c0 ti: 81a0 task.ti: 
> 81a0
> [0.096936] RIP: 0010:[]  [] 0xcf038cc6

Now this could be the 1:1 mapping of say, region

[0.00] efi: mem53: type=5, attr=0x800f, 
range=[0xcefdc000-0xcf04d000) (0MB)

who knows...

Now, we #PF at 0x000129101020. Is that because we're trying to
access memory somewhere in here:

[0.00] efi: mem63: type=7, attr=0xf, 
range=[0x0001-0x00013000) (768MB)

which looks very strange because this is of type EFI_CONVENTIONAL_MEMORY
so is the efi thing trying to access normal memory and it is not mapped
in the efi pagetable???! And WTF is EFI trying to access conventional
memory?? No wonder we stuck it in its own pagetable.

Oh, and look, this region doesn't have the EFI_MEMORY_RUNTIME bit set so
we don't map it.

And this should explain the explosion with 3.13 too because we didn't
map EFI_CONVENTIONAL_MEMORY then either.

Or, wait a minute, isn't this the same __pa(new_memmap) crap we've been
debugging recently?? But if it were, this wouldn't explain the failure
with 3.13.

Fun.

> [0.105369] RSP: :81a01de0  EFLAGS: 00010287
> [0.112005] RAX: 8000 RBX: 000129101000 RCX: 
> 0660
> [0.120574] RDX: 000129101000 RSI: cefbff18 RDI: 
> cf037af4
> [0.129147] RBP: 0660 R08: 0001 R09: 
> 000129101000
> [0.137726] R10: 0001 R11:  R12: 
> cefbfe18
> [0.146295] R13: 0660 R14: 0001 R15: 
> 0009a000
> [0.154869] FS:  () GS:88012a80() 
> knlGS:
> [0.165444] CS:  0010 DS:  ES:  CR0: 80050033
> [0.172536] CR2: 88012a4d9c60 CR3: 0009a000 CR4: 
> 000406b0
> [0.18] DR0:  DR1:  DR2: 
> 
> [0.189682] DR3:  DR6: 4ff0 DR7: 
> 0400
> [0.198255] Stack:
> [0.201389]  81a01f48 813172aa  
> 0001
> [0.211392]  cf046a50 cf038f36 cefbfca0 
> 81a01f48
> [0.221401]  813172aa  0001 
> 
> [0.231392] Call Trace:
> [0.234994]  [] ? trace_hardirqs_off_thunk+0x3a/0x3c
> [0.242927]  [] ? trace_hardirqs_off_thunk+0x3a/0x3c
> [0.250859]  [] ? efi_call4+0x6c/0xf0
> [0.257408]  [] ? efi_enter_virtual_mode+0x2b2/0x45b
> [0.265344]  [] ? start_kernel+0x3d3/0x45e
> [0.272354]  [] ? repair_env_string+0x5c/0x5c
> [0.279640]  [] ? early_idt_handlers+0x120/0x120
> [0.287201]  [] ? x86_64_start_reservations+0x2a/0x2c
> [0.295228]  [] ? x86_64_start_kernel+0x143/0x152
> [0.302882] Code:  Bad RIP value.


> [0.307472] RIP  [] 0xcf038cc6
> [0.313415]  RSP 
> [0.318118] CR2: 000129101020
> [0.322638] ---[ end trace a93146f09f726796 ]---

Alexandra, can you please do

make arch/x86/platform/efi/efi.o
make arch/x86/platform/efi/efi.s

on that exact same kernel .config and zip and send me those two files?
Privately is fine too.

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body 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 1/3] perf tools: Put proper period for for samples without PERIOD sample_type

[Namhyung Kim]

Hi Jiri,

On Mon,  3 Feb 2014 12:44:41 +0100, Jiri Olsa wrote:
> We use PERF_SAMPLE_PERIOD sample type only for frequency
> setup -F (default) option. The -c does not need store period,
> because it's always the same.
>
> In -c case the report code uses '1' as  period. Fixing
> it to perf_event_attr::sample_period.

All 3 patches look good.  But I found something strange.  When we
setup/config evsel attrs following code is used:

 util/evsel.c::perf_evsel__config()

/*
 * We default some events to a 1 default interval. But keep
 * it a weak assumption overridable by the user.
 */
if (!attr->sample_period || (opts->user_freq != UINT_MAX &&
 opts->user_interval != ULLONG_MAX)) {
if (opts->freq) {
perf_evsel__set_sample_bit(evsel, PERIOD);
attr->freq  = 1;
attr->sample_freq   = opts->freq;
} else {
attr->sample_period = opts->default_interval;
}
}


But shouldn't it be "||" instead of "&&" for checking
user_freq/interval?  The opts->freq was setup by code below

  util/record.c::record_opts__config_freq()

bool user_freq = opts->user_freq != UINT_MAX;
unsigned int max_rate;

if (opts->user_interval != ULLONG_MAX)
opts->default_interval = opts->user_interval;
if (user_freq)
opts->freq = opts->user_freq;

/*
 * User specified count overrides default frequency.
 */
if (opts->default_interval)
opts->freq = 0;
else if (opts->freq) {
opts->default_interval = opts->freq;
} else {
pr_err("frequency and count are zero, aborting\n");
return -1;
}


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

TEST MAIL 1

[Rajat Jain]

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

Re: [RFC 12/16] drm/nouveau/fifo: add GK20A support

[Alexandre Courbot]

Hi Daniel,

On 02/04/2014 06:15 PM, Daniel Vetter wrote:

On Sat, Feb 01, 2014 at 12:16:54PM +0900, Alexandre Courbot wrote:

GK20A's FIFO is compatible with NVE0, but only features 128 channels and
1 runlist.

Signed-off-by: Alexandre Courbot 
---
  drivers/gpu/drm/nouveau/Makefile   |  1 +
  drivers/gpu/drm/nouveau/core/engine/fifo/nve0.h|  1 +
  drivers/gpu/drm/nouveau/core/engine/fifo/nvea.c| 27 ++
  drivers/gpu/drm/nouveau/core/include/engine/fifo.h |  1 +
  4 files changed, 30 insertions(+)
  create mode 100644 drivers/gpu/drm/nouveau/core/engine/fifo/nvea.c

diff --git a/drivers/gpu/drm/nouveau/Makefile b/drivers/gpu/drm/nouveau/Makefile
index e88145b..6c4b76d 100644
--- a/drivers/gpu/drm/nouveau/Makefile
+++ b/drivers/gpu/drm/nouveau/Makefile
@@ -236,6 +236,7 @@ nouveau-y += core/engine/fifo/nv50.o
  nouveau-y += core/engine/fifo/nv84.o
  nouveau-y += core/engine/fifo/nvc0.o
  nouveau-y += core/engine/fifo/nve0.o
+nouveau-y += core/engine/fifo/nvea.o
  nouveau-y += core/engine/fifo/nv108.o
  nouveau-y += core/engine/graph/ctxnv40.o
  nouveau-y += core/engine/graph/ctxnv50.o
diff --git a/drivers/gpu/drm/nouveau/core/engine/fifo/nve0.h 
b/drivers/gpu/drm/nouveau/core/engine/fifo/nve0.h
index 014344e..e96b32b 100644
--- a/drivers/gpu/drm/nouveau/core/engine/fifo/nve0.h
+++ b/drivers/gpu/drm/nouveau/core/engine/fifo/nve0.h
@@ -8,6 +8,7 @@ int  nve0_fifo_ctor(struct nouveau_object *, struct 
nouveau_object *,
struct nouveau_object **);
  void nve0_fifo_dtor(struct nouveau_object *);
  int  nve0_fifo_init(struct nouveau_object *);
+int  nve0_fifo_fini(struct nouveau_object *, bool);

  struct nve0_fifo_impl {
struct nouveau_oclass base;
diff --git a/drivers/gpu/drm/nouveau/core/engine/fifo/nvea.c 
b/drivers/gpu/drm/nouveau/core/engine/fifo/nvea.c
new file mode 100644
index 000..16f8905
--- /dev/null
+++ b/drivers/gpu/drm/nouveau/core/engine/fifo/nvea.c
@@ -0,0 +1,27 @@
+/*
+ * Copyright (c) 2014, NVIDIA Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.


Just stumbled over this lincense header: Generally drm is mit/gpl dual
lincensed. The important part for me is the drm core, but due to all the
refactoring we tend to do and code extraction from drivers those are
rather relevant imo, too. Was this just an oversight or are you still
working with your legap people on this?


Thanks for pointing this out. This was an oversight on my part indeed. 
The following revisions will use the correct MIT copyright header.


In case someone wants to contribute significant fixes to this patchset, 
please be aware that MIT is the license that will apply from now on.


Thanks,
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] kernel: kprobe: move all *kretprobe* generic implementation to CONFIG_KRETPROBES enabled area

[Masami Hiramatsu]

(2014/02/05 9:18), Chen Gang wrote:
> On 02/04/2014 11:39 PM, Masami Hiramatsu wrote:
>> (2014/02/04 22:53), Chen Gang wrote:
>>> On 02/04/2014 09:29 PM, Masami Hiramatsu wrote:
 (2014/02/04 21:07), Chen Gang wrote:
> On 02/04/2014 03:17 PM, Masami Hiramatsu wrote:
>> (2014/02/04 14:16), Chen Gang wrote:
>>> When CONFIG_KRETPROBES disabled, all *kretprobe* generic implementation
>>> are useless, so need move them to CONFIG_KPROBES enabled area.
>>>
>>> Now, *kretprobe* generic implementation are all implemented in 2 files:
>>>
>>>  - in "include/linux/kprobes.h":
>>>
>>>  move inline kretprobe*() to CONFIG_KPROBES area and dummy outside.
>>>  move some *kprobe() declarations which kretprobe*() call, to front.
>>>  not touch kretprobe_blacklist[] which is architecture's variable.
>>>
>>>  - in "kernel/kprobes.c":
>>>
>>>  move all kretprobe* to CONFIG_KPROBES area and dummy outside.
>>>  define kretprobe_flush_task() to let kprobe_flush_task() call.
>>>  define init_kretprobes() to let init_kprobes() call.
>>>
>>> The patch passes compiling (get "kernel/kprobes.o" and "kernel/built-
>>> in.o") under avr32 and x86_64 allmodconfig, and passes building (get
>>> bzImage and Modpost modules) under x86_64 defconfig.
>>
>> Thanks for the fix! and I have some comments below.
>>
>>> Signed-off-by: Chen Gang 
>>> ---
>>>  include/linux/kprobes.h |  58 +
>>>  kernel/kprobes.c| 328 
>>> +++-
>>>  2 files changed, 222 insertions(+), 164 deletions(-)
>>>
>>> diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h
>>> index 925eaf2..c0d1212 100644
>>> --- a/include/linux/kprobes.h
>>> +++ b/include/linux/kprobes.h
>>> @@ -223,10 +223,36 @@ static inline int kprobes_built_in(void)
>>>   return 1;
>>>  }
>>>  
>>> +int disable_kprobe(struct kprobe *kp);
>>> +int enable_kprobe(struct kprobe *kp);
>>> +
>>> +void dump_kprobe(struct kprobe *kp);
>>> +
>>> +extern struct kretprobe_blackpoint kretprobe_blacklist[];
>>> +
>>>  #ifdef CONFIG_KRETPROBES
>>>  extern void arch_prepare_kretprobe(struct kretprobe_instance *ri,
>>> struct pt_regs *regs);
>>>  extern int arch_trampoline_kprobe(struct kprobe *p);
>>> +static inline void kretprobe_assert(struct kretprobe_instance *ri,
>>> + unsigned long orig_ret_address, unsigned long trampoline_address)
>>> +{
>>> + if (!orig_ret_address || (orig_ret_address == trampoline_address)) {
>>> + printk(KERN_ERR
>>> + "kretprobe BUG!: Processing kretprobe %p @ %p\n",
>>> + ri->rp, ri->rp->kp.addr);
>>> + BUG();
>>> + }
>>> +}
>>> +static inline int disable_kretprobe(struct kretprobe *rp)
>>> +{
>>> + return disable_kprobe(>kp);
>>> +}
>>> +static inline int enable_kretprobe(struct kretprobe *rp)
>>> +{
>>> + return enable_kprobe(>kp);
>>> +}
>>> +
>>>  #else /* CONFIG_KRETPROBES */
>>>  static inline void arch_prepare_kretprobe(struct kretprobe *rp,
>>>   struct pt_regs *regs)
>>> @@ -236,19 +262,20 @@ static inline int arch_trampoline_kprobe(struct 
>>> kprobe *p)
>>>  {
>>>   return 0;
>>>  }
>>> -#endif /* CONFIG_KRETPROBES */
>>> -
>>> -extern struct kretprobe_blackpoint kretprobe_blacklist[];
>>> -
>>>  static inline void kretprobe_assert(struct kretprobe_instance *ri,
>>>   unsigned long orig_ret_address, unsigned long trampoline_address)
>>>  {
>>> - if (!orig_ret_address || (orig_ret_address == trampoline_address)) {
>>> - printk("kretprobe BUG!: Processing kretprobe %p @ %p\n",
>>> - ri->rp, ri->rp->kp.addr);
>>> - BUG();
>>> - }
>>>  }
>>> +static inline int disable_kretprobe(struct kretprobe *rp)
>>> +{
>>> + return 0;
>>> +}
>>> +static inline int enable_kretprobe(struct kretprobe *rp)
>>> +{
>>> + return 0;
>>> +}
>>
>> No, these should returns -EINVAL or -ENOSYS, since these are user API.
>
> OK, thanks, it sounds reasonable to me.
>
>> Anyway, I don't think those inlined functions to be changed, because
>> most of them are internal functions. If CONFIG_KRETPROBES=n, it just
>> be ignored.
>>
>
> In original implementation, if CONFIG_KRETPROBES=n, kretprobe_assert(),
> disable_kretprobe(), and enable_kretprobe() are not ignored.

 Really? where are they called? I mean, those functions do not have
 any instance unless your module uses it (but that is not what the kernel
 itself should help).

>>>
>>> If what you said correct (I guess so), for me, we still need let them in
>>> CONFIG_KRETPROBES area, and without any dummy outside, just like another
>>> *kprobe* static inline functions have done in "include/linux/kprobes.h".
>>
>> 

Re: [RFC][PATCH] exec: Fix use after free of tracepoint trace_sched_process_exec

[Al Viro]

On Tue, Feb 04, 2014 at 04:57:31PM -0800, Linus Torvalds wrote:
> On Tue, Feb 4, 2014 at 3:42 PM, Steven Rostedt  wrote:
> >
> > New version that moves all the ugliness into a static inline helper
> > function.
> 
> Ok, that's better, but I really think we should just use "getname()"
> and "putname()".

Umm...  Interactions with aushit might be interesting.  It hooks into
getname() and putname(); I'm not up to doing analysis right now (13 hours
of nearly non-stop {R,Grep}TFS today already and I'm ears-deep in
looking through locking implications of Miklos' stuff at the moment ;-/),
but it's worth looking into; there may be dragons.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] m68k: Switch to asm-generic/barrier.h

[Greg Ungerer]

On 05/02/14 06:15, Geert Uytterhoeven wrote:
> The generic nop() implementation is fine for m68k.
> 
> Signed-off-by: Geert Uytterhoeven 

Acked-by: Greg Ungerer 


> ---
>  arch/m68k/include/asm/Kbuild|1 +
>  arch/m68k/include/asm/barrier.h |8 
>  2 files changed, 1 insertion(+), 8 deletions(-)
>  delete mode 100644 arch/m68k/include/asm/barrier.h
> 
> diff --git a/arch/m68k/include/asm/Kbuild b/arch/m68k/include/asm/Kbuild
> index df4d46fc321b..6fb9e813a910 100644
> --- a/arch/m68k/include/asm/Kbuild
> +++ b/arch/m68k/include/asm/Kbuild
> @@ -1,3 +1,4 @@
> +generic-y += barrier.h
>  generic-y += bitsperlong.h
>  generic-y += clkdev.h
>  generic-y += cputime.h
> diff --git a/arch/m68k/include/asm/barrier.h b/arch/m68k/include/asm/barrier.h
> deleted file mode 100644
> index 15c5f77c1614..
> --- a/arch/m68k/include/asm/barrier.h
> +++ /dev/null
> @@ -1,8 +0,0 @@
> -#ifndef _M68K_BARRIER_H
> -#define _M68K_BARRIER_H
> -
> -#define nop()do { asm volatile ("nop"); barrier(); } while 
> (0)
> -
> -#include 
> -
> -#endif /* _M68K_BARRIER_H */
> 

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

Re: [PATCH 3/3] m68k: Wire up sched_setattr and sched_getattr

[Greg Ungerer]

On 05/02/14 06:15, Geert Uytterhoeven wrote:
> Signed-off-by: Geert Uytterhoeven 

Acked-by: Greg Ungerer 


> ---
>  arch/m68k/include/asm/unistd.h  |2 +-
>  arch/m68k/include/uapi/asm/unistd.h |2 ++
>  arch/m68k/kernel/syscalltable.S |2 ++
>  3 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/m68k/include/asm/unistd.h b/arch/m68k/include/asm/unistd.h
> index 014f288fc813..9d38b73989eb 100644
> --- a/arch/m68k/include/asm/unistd.h
> +++ b/arch/m68k/include/asm/unistd.h
> @@ -4,7 +4,7 @@
>  #include 
>  
>  
> -#define NR_syscalls  349
> +#define NR_syscalls  351
>  
>  #define __ARCH_WANT_OLD_READDIR
>  #define __ARCH_WANT_OLD_STAT
> diff --git a/arch/m68k/include/uapi/asm/unistd.h 
> b/arch/m68k/include/uapi/asm/unistd.h
> index 625f321001dc..b932dd470041 100644
> --- a/arch/m68k/include/uapi/asm/unistd.h
> +++ b/arch/m68k/include/uapi/asm/unistd.h
> @@ -354,5 +354,7 @@
>  #define __NR_process_vm_writev   346
>  #define __NR_kcmp347
>  #define __NR_finit_module348
> +#define __NR_sched_setattr   349
> +#define __NR_sched_getattr   350
>  
>  #endif /* _UAPI_ASM_M68K_UNISTD_H_ */
> diff --git a/arch/m68k/kernel/syscalltable.S b/arch/m68k/kernel/syscalltable.S
> index 3f04ea0ab802..b6223dc41d82 100644
> --- a/arch/m68k/kernel/syscalltable.S
> +++ b/arch/m68k/kernel/syscalltable.S
> @@ -369,4 +369,6 @@ ENTRY(sys_call_table)
>   .long sys_process_vm_writev
>   .long sys_kcmp
>   .long sys_finit_module
> + .long sys_sched_setattr
> + .long sys_sched_getattr /* 350 */
>  
> 

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

Re: [PATCH 1/3] m68k: Sort arch/m68k/include/asm/Kbuild

[Greg Ungerer]

On 05/02/14 06:15, Geert Uytterhoeven wrote:
> Signed-off-by: Geert Uytterhoeven 

Acked-by: Greg Ungerer 

> ---
>  arch/m68k/include/asm/Kbuild |5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/m68k/include/asm/Kbuild b/arch/m68k/include/asm/Kbuild
> index 7cc8c364924d..df4d46fc321b 100644
> --- a/arch/m68k/include/asm/Kbuild
> +++ b/arch/m68k/include/asm/Kbuild
> @@ -1,4 +1,3 @@
> -
>  generic-y += bitsperlong.h
>  generic-y += clkdev.h
>  generic-y += cputime.h
> @@ -6,6 +5,7 @@ generic-y += device.h
>  generic-y += emergency-restart.h
>  generic-y += errno.h
>  generic-y += exec.h
> +generic-y += hash.h
>  generic-y += hw_irq.h
>  generic-y += ioctl.h
>  generic-y += ipcbuf.h
> @@ -18,6 +18,7 @@ generic-y += local.h
>  generic-y += mman.h
>  generic-y += mutex.h
>  generic-y += percpu.h
> +generic-y += preempt.h
>  generic-y += resource.h
>  generic-y += scatterlist.h
>  generic-y += sections.h
> @@ -31,5 +32,3 @@ generic-y += trace_clock.h
>  generic-y += types.h
>  generic-y += word-at-a-time.h
>  generic-y += xor.h
> -generic-y += preempt.h
> -generic-y += hash.h
> 

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

Re: [PATCH] clocksource: exynos4: Fix wrong bit operation in exynos4_mct_write()

[jonghwa3 . lee]

On 2014년 02월 04일 22:01, Kyungmin Park wrote:

> 
> 
> On Tuesday, February 4, 2014, Jonghwa Lee  > wrote:
> 
> There was a faulty bit operation during checking offset in 
> exynos4_mct_write().
> This patch fixes it correctly.
> 
> What's the issue? What's happened with current code? 


Whether it would be applied or not, current code looks working fine. Because
those things are just needed to confirm writing to certain register. The
technical reference manual recommends users to check write status register for
some specified registers, e.g. control register. However current code always
skip checking write status even we access the registers required. It will just
executed writing operation only and leave write status uncleared.

Thanks,
Jonghwa

> 
> Thank you,
> Kyungmin Park
> 
> 
> Signed-off-by: Jonghwa Lee >
> Signed-off-by: MyungJoo Ham >
> ---
>  drivers/clocksource/exynos_mct.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clocksource/exynos_mct.c 
> b/drivers/clocksource/exynos_mct.c
> index 62b0de6..e60b019 100644
> --- a/drivers/clocksource/exynos_mct.c
> +++ b/drivers/clocksource/exynos_mct.c
> @@ -94,8 +94,8 @@ static void exynos4_mct_write(unsigned int value, 
> unsigned
> long offset)
> __raw_writel(value, reg_base + offset);
> 
> if (likely(offset >= EXYNOS4_MCT_L_BASE(0))) {
> -   stat_addr = (offset & ~EXYNOS4_MCT_L_MASK) + 
> MCT_L_WSTAT_OFFSET;
> -   switch (offset & EXYNOS4_MCT_L_MASK) {
> +   stat_addr = (offset & EXYNOS4_MCT_L_MASK) + 
> MCT_L_WSTAT_OFFSET;
> +   switch (offset & ~EXYNOS4_MCT_L_MASK) {
> case MCT_L_TCON_OFFSET:
> mask = 1 << 3;  /* L_TCON write status */
> break;
> --
> 1.7.9.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org 
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] slub: fix false-positive lockdep warning in free_partial()

[David Rientjes]

On Tue, 4 Feb 2014, Christoph Lameter wrote:

> > Although this cannot actually result in a race, because on cache
> > destruction there should not be any concurrent frees or allocations from
> > the cache, let's add spin_lock/unlock to free_partial() just to keep
> > lockdep happy.
> 
> Please add a comment that says this in the source so we know why this was
> added.
> 

Makes sense since there is a comment there already saying we don't need 
the lock, then with this patch we end up taking it away.  The nice thing 
is that there should be no lock contention here :)

I'm not sure we need to disable irqs as in the patch, though.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] exec: Fix use after free of tracepoint trace_sched_process_exec

[Linus Torvalds]

On Tue, Feb 4, 2014 at 3:42 PM, Steven Rostedt  wrote:
>
> New version that moves all the ugliness into a static inline helper
> function.

Ok, that's better, but I really think we should just use "getname()"
and "putname()".

That's what the path that *matters* already does (ie the normal
execve() system call), so let's just make all the random cases do the
same thing.

That requires a "getname_kernel()" to create a "struct filename *"
from a kernel string, but hey, that's simple enough.

NOTE! This means that "bprm->filename" is no longer a string: it's a
"struct filename *", so if you want the string, you do
"filename->name".

This actually cleans the normal paths up - look how "open_exec()" used
to create a dummy

struct filename tmp = { .name = name };

on the stack because do_filp_open() wants a 'struct filename' pointer.
I leave that for the external callers (that use it for the
interpreter), but for the main path that actually just goes away,
because now we have that "struct filename *" natively.

It does add code to the special kernel-execve paths, but moving the
"handle errors from getname()" code into do_execve(), even that is
really trivial, eg:

  -   return do_execve(init_filename,
  +   return do_execve(getname_kernel(init_filename),

NOTE NOTE NOTE. This is untested, but it looks fine. If I missed
something, the compiler should warn about bad types. I didn't my the
bprm_flat changes, for example, because that's a no-MMU-only file. And
I might have missed something that didn't match my grep patterns, for
example.

How does this look?

   Linus
 arch/parisc/hpux/fs.c |  3 +-
 arch/tile/mm/elf.c|  2 +-
 fs/binfmt_em86.c  |  2 +-
 fs/binfmt_flat.c  | 15 ++
 fs/exec.c | 58 ---
 fs/namei.c| 27 ++
 include/linux/binfmts.h   |  3 +-
 include/linux/fs.h|  1 +
 include/linux/sched.h |  3 +-
 include/trace/events/sched.h  |  4 +--
 init/main.c   |  2 +-
 kernel/kmod.c |  2 +-
 security/apparmor/domain.c|  2 +-
 security/commoncap.c  |  6 ++--
 security/integrity/ima/ima_main.c |  4 +--
 security/tomoyo/domain.c  |  2 +-
 security/tomoyo/tomoyo.c  |  2 +-
 17 files changed, 86 insertions(+), 52 deletions(-)

diff --git a/arch/parisc/hpux/fs.c b/arch/parisc/hpux/fs.c
index 88d0962de65a..23ebcd678da3 100644
--- a/arch/parisc/hpux/fs.c
+++ b/arch/parisc/hpux/fs.c
@@ -41,11 +41,10 @@ int hpux_execve(struct pt_regs *regs)
if (IS_ERR(filename))
goto out;
 
-   error = do_execve(filename->name,
+   error = do_execve(filename,
  (const char __user *const __user *) regs->gr[25],
  (const char __user *const __user *) regs->gr[24]);
 
-   putname(filename);
 
 out:
return error;
diff --git a/arch/tile/mm/elf.c b/arch/tile/mm/elf.c
index 23f044e8a7ab..3ad54a7a927c 100644
--- a/arch/tile/mm/elf.c
+++ b/arch/tile/mm/elf.c
@@ -117,7 +117,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm,
 * whatever was passed as the linux_binprm filename.
 */
if (!notify_exec(mm))
-   sim_notify_exec(bprm->filename);
+   sim_notify_exec(bprm->filename->name);
 
retval = setup_vdso_pages();
 
diff --git a/fs/binfmt_em86.c b/fs/binfmt_em86.c
index f37b08cea1f7..077a76fb6347 100644
--- a/fs/binfmt_em86.c
+++ b/fs/binfmt_em86.c
@@ -62,7 +62,7 @@ static int load_em86(struct linux_binprm *bprm)
 * user environment and arguments are stored.
 */
remove_arg_zero(bprm);
-   retval = copy_strings_kernel(1, >filename, bprm);
+   retval = copy_strings_kernel(1, >filename->name, bprm);
if (retval < 0) return retval; 
bprm->argc++;
if (i_arg) {
diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
index d50bbe59da1e..f1377a5d260b 100644
--- a/fs/binfmt_flat.c
+++ b/fs/binfmt_flat.c
@@ -469,7 +469,7 @@ static int load_flat_file(struct linux_binprm * bprm,
}
 
if (flags & FLAT_FLAG_KTRACE)
-   printk("BINFMT_FLAT: Loading file: %s\n", bprm->filename);
+   printk("BINFMT_FLAT: Loading file: %s\n", bprm->filename->name);
 
if (rev != FLAT_VERSION && rev != OLD_FLAT_VERSION) {
printk("BINFMT_FLAT: bad flat file version 0x%x (supported "
@@ -686,7 +686,7 @@ static int load_flat_file(struct linux_binprm * bprm,
 
if (flags & FLAT_FLAG_KTRACE)
printk("%s %s: TEXT=%x-%x DATA=%x-%x BSS=%x-%x\n",
-   id ? "Lib" : "Load", bprm->filename,
+   id ? "Lib" : "Load", bprm->filename->name,
(int) start_code, (int) end_code,
(int) datapos,
(int) (datapos + 

Re: [PATCH 00/11] ARM: shmobile: RSPI RZ and QSPI SoC and board integration

[Simon Horman]

Magnus, could you Ack these or otherwise?

On Tue, Feb 04, 2014 at 04:23:54PM +0100, Geert Uytterhoeven wrote:
>   Hi Simon, Magnus,
> 
> This patch series contains SoC and board integration for
>   1. RSPI in the r7s72100 aka RZ/A1H SoC on the Genmai reference board,
>   2. QSPI in the r8a7791 aka R-Car M2 SoC on the Koelsch reference board.
> It was rebased on top of renesas-devel-v3.14-rc1-20140204.
> 
> It was tested on the r7s72100-based Genmai reference board using loopback
> mode, and on the r8a7791-based Koelsch reference board using the Spansion
> s25fl512s SPI FLASH.
> 
>   - [v5 01/11] ARM: shmobile: r7s72100 clock: Add RSPI clocks
>   - [v5 02/11] ARM: shmobile: genmai legacy: Add RSPI support
>   - [v3 03/11] ARM: shmobile: genmai defconfig: Enable RSPI
>   - [v3 04/11] ARM: shmobile: r7s72100 clock: Add RSPI clocks for DT
>   - [v5 05/11] ARM: shmobile: r7s72100 dtsi: Add RSPI nodes
>   - [v4 06/11] ARM: shmobile: r8a7791 clock: add QSPI clocks
>   - [v4 07/11] ARM: shmobile: koelsch legacy: Add QSPI support
>   - [v4 08/11] ARM: shmobile: koelsch defconfig: Enable RSPI and
>   - [v3 09/11] ARM: shmobile: r8a7791 dtsi: Add QSPI node
>   - [v3 10/11] ARM: shmobile: koelsch dts: Add QSPI nodes
>   - [v2 11/11] ARM: shmobile: lager legacy: Switch QSPI to named IRQs

Above I see v2, v3, v4 and v5 patches.

While I can make sense of this it makes it cumbersome to refer to the
series as a whole.

Bob, can you take a look at '"[PATCH 00/11] ARM: shmobile: RSPI RZ and
QSPI SoC and board", posted on Tuesday the 2nd, which includes v2, v3,
v4 and v5 patches'?

What would make my life easier would be if the entire series was v5 and
all the patches contained in it were v5. Then I could just ask Bob to look
at "[PATCH v5 00/11] ARM: shmobile: RSPI RZ and QSPI SoC and board"

There is no Bob but I do ask people these kind of questions :)

> All of these should be safe to apply, without compile-time or run-time
> dependencies on other parts.
> Actual functioning for some parts may depend on RSPI work queued up for
> 3.15 in the spi tree.
> 
> Compared to previous submission, the following have been postponed:
>   - [v4 03/15] [WIP] ARM: shmobile: genmai legacy: Add preliminary RSPI
>pinmux setup
> This depends on the to-be-written non-DT pinmux configuration for
> r7s72100.
>   - [v4 07/15] ARM: shmobile: genmai reference dts: Add RSPI nodes
> This depends on Magnus' "ARM: shmobile: r7s72100 GPIO and PINCTRL device
> nodes"
>   - [v1 14/15] ARM: shmobile: koelsch legacy: Enable Quad SPI transfers for
>the SPI FLASH
>   - [v1 15/15] ARM: shmobile: koelsch dts: Enable Quad SPI transfers
> These two depend on the RSPI Dual/Quad work queued up in the spi tree.
> After applying the r8a7791/Koelsch patches above, the mainline RSPI/QSPI
> driver will work fine. But enabling Quad SPI transfers in board support
> code or DT without the corresponding support in the RSPI driver would
> cause a regression.
> 
> Please apply this series, Thanks!
> 
> Gr{oetje,eeting}s,
> 
>   Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
>   -- Linus Torvalds
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] x86: Disable generation of traditional x87 instructions

[Borislav Petkov]

From: Borislav Petkov 

We recently had the case where wrongly used floating-constant 'E' caused
the generation of traditional x87 instructions in kernel code and
wreaking all kinds of havoc.

Disable the generation of those too. This will save people a lot of time
when trying to debug such issues by erroring out of the build instead of
let them manifest themselves in very spectacular and happy-crappy ways
at runtime.

We're using -mno-fp-ret-in-387 in addition to -mno-80387 (which is ==
-msoft-float) because, as the gcc manpage says:

  On machines where a function returns floating-point results in the
  80387 register stack, some floating-point opcodes may be emitted even
  if -msoft-float is used.

so we want to turn off *all* non-integer instructions involving any
architectural FPU state, unless it is absolutely necessary (and those
cases need special handling anyway).

Cc: Jiri Kosina 
Cc: Michael Matz 
Cc: Michal Hocko 
Signed-off-by: Borislav Petkov 
---
 arch/x86/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index eeda43abed6e..a414b1471ffc 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -82,8 +82,8 @@ else
 KBUILD_AFLAGS += -m64
 KBUILD_CFLAGS += -m64
 
-# Don't autogenerate MMX or SSE instructions
-KBUILD_CFLAGS += -mno-mmx -mno-sse
+# Don't autogenerate traditional x87, MMX or SSE instructions
+KBUILD_CFLAGS += -mno-mmx -mno-sse -mno-80387 -mno-fp-ret-in-387
 
# Use -mpreferred-stack-boundary=3 if supported.
KBUILD_CFLAGS += $(call cc-option,-mpreferred-stack-boundary=3)
-- 
1.8.5.2.192.g7794a68

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

[PATCH] ACPI hotplug: Fix panic on eject to ejected device

[Toshi Kani]

When an eject request is sent to an ejected ACPI device, the following
panic occurs:

 ACPI: \_SB_.SCK3.CPU3: ACPI_NOTIFY_EJECT_REQUEST event
 BUG: unable to handle kernel NULL pointer dereference at 0070
 IP: [] acpi_device_hotplug+0x10b/0x33b
:
 Call Trace:
 [] acpi_hotplug_work_fn+0x1c/0x27
 [] process_one_work+0x175/0x430
 [] worker_thread+0x11b/0x3a0

This is becase device->handler is NULL in acpi_device_hotplug().
This case was used to fail in acpi_hotplug_notify_cb() as the target
had no acpi_deivce.  However, acpi_device now exists after ejection.

Added a check to verify if acpi_device->handler is valid for an
eject request in acpi_hotplug_notify_cb().  Note that handler passed
from an argument is still valid while acpi_device->handler is NULL.

Signed-off-by: Toshi Kani 
---
 drivers/acpi/scan.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 7384158..5cf6adf 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -484,7 +484,6 @@ static void acpi_device_hotplug(void *data, u32 src)
 static void acpi_hotplug_notify_cb(acpi_handle handle, u32 type, void *data)
 {
u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE;
-   struct acpi_scan_handler *handler = data;
struct acpi_device *adev;
acpi_status status;
 
@@ -500,7 +499,9 @@ static void acpi_hotplug_notify_cb(acpi_handle handle, u32 
type, void *data)
break;
case ACPI_NOTIFY_EJECT_REQUEST:
acpi_handle_debug(handle, "ACPI_NOTIFY_EJECT_REQUEST event\n");
-   if (!handler->hotplug.enabled) {
+   if (!adev->handler)
+   goto err_out;
+   if (!adev->handler->hotplug.enabled) {
acpi_handle_err(handle, "Eject disabled\n");
ost_code = ACPI_OST_SC_EJECT_NOT_SUPPORTED;
goto err_out;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/