Re: [PATCH 2/2] nohz: use delayed iowait accounting to avoid race on idle time stats

2014-04-17 Thread Hidetoshi Seto
(2014/04/17 19:05), Peter Zijlstra wrote:
> Anyway, if you want to preserve the same broken ass crap we had pre
> NOHZ, something like the below should do that.
> 
> I'm not really thrilled with iowait_{start,stop}() but I think they
> should have the same general cost as the atomic ops we already had. In
> particular on x86 an uncontended lock+unlock is a single atomic.
> 
> This is on top the first patch from Frederic that both you and Denys
> carried.
> 
> That said; I really hate duckt taping this together, for the generated
> numbers are still useless.
> 
> --- a/include/linux/ktime.h
> +++ b/include/linux/ktime.h
> @@ -58,6 +58,8 @@ union ktime {
>  
>  typedef union ktime ktime_t; /* Kill this */
>  
> +#define ktime_zero ((ktime_t){ .tv64 = 0 })
> +
>  /*
>   * ktime_t definitions when using the 64-bit scalar representation:
>   */
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -2297,15 +2297,29 @@ unsigned long nr_iowait(void)
>   unsigned long i, sum = 0;
>  
>   for_each_possible_cpu(i)
> - sum += atomic_read(_rq(i)->nr_iowait);
> + sum += cpu_rq(i)->nr_iowait;
>  
>   return sum;
>  }
>  
>  unsigned long nr_iowait_cpu(int cpu)
>  {
> - struct rq *this = cpu_rq(cpu);
> - return atomic_read(>nr_iowait);
> + return cpu_rq(cpu)->nr_iowait;
> +}
> +
> +void nr_iowait_deltas(ktime_t start, ktime_t now,
> +   ktime_t *iowait_delta, ktime_t *idle_delta)
> +{
> + struct rq *rq = this_rq();
> +
> + raw_spin_lock(>iowait_lock);
> + if (rq->nr_iowait) {
> + *iowait_delta = ktime_sub(now, start);
> + } else {
> + *iowait_delta = ktime_sub(rq->last_iowait, start);
> + *idle_delta = ktime_sub(now, rq->last_iowait);
> + }
> + raw_spin_unlock(>iowait_lock);
>  }
>  
>  #ifdef CONFIG_SMP
> @@ -4201,6 +4215,24 @@ bool __sched yield_to(struct task_struct
>  }
>  EXPORT_SYMBOL_GPL(yield_to);
>  
> +static inline void iowait_start(struct rq *rq)
> +{
> + raw_spin_lock(>iowait_lock);
> + rq->nr_iowait++;
> + raw_spin_unlock(>iowait_lock);
> + current->in_iowait = 1;
> +}
> +
> +static inline void iowait_stop(struct rq *rq)
> +{
> + current->in_iowait = 0;
> + raw_spin_lock(>iowait_lock);
> + rq->nr_iowait--;
> + if (!rq->nr_iowait && rq != this_rq())
> + rq->last_iowait = ktime_get();
> + raw_spin_unlock(>iowait_lock);
> +}
> +
>  /*
>   * This task is about to go to sleep on IO. Increment rq->nr_iowait so
>   * that process accounting knows that this is a task in IO wait state.
> @@ -4210,12 +4242,10 @@ void __sched io_schedule(void)
>   struct rq *rq = raw_rq();
>  
>   delayacct_blkio_start();
> - atomic_inc(>nr_iowait);
> + iowait_start();
>   blk_flush_plug(current);
> - current->in_iowait = 1;
>   schedule();
> - current->in_iowait = 0;
> - atomic_dec(>nr_iowait);
> + iowait_stop();
>   delayacct_blkio_end();
>  }
>  EXPORT_SYMBOL(io_schedule);
> @@ -4226,12 +4256,10 @@ long __sched io_schedule_timeout(long ti
>   long ret;
>  
>   delayacct_blkio_start();
> - atomic_inc(>nr_iowait);
> + iowait_start();
>   blk_flush_plug(current);
> - current->in_iowait = 1;
>   ret = schedule_timeout(timeout);
> - current->in_iowait = 0;
> - atomic_dec(>nr_iowait);
> + iowait_stop();
>   delayacct_blkio_end();
>   return ret;
>  }
> @@ -6880,7 +6908,10 @@ void __init sched_init(void)
>  #endif
>  #endif
>   init_rq_hrtick(rq);
> - atomic_set(>nr_iowait, 0);
> +
> + raw_spinlock_init(>iowait_lock);
> + rq->nr_iowait = 0;
> + rq->last_iowait = ktime_get();
>   }
>  
>   set_load_weight(_task);

I think it also works... but I have some concerns here:

 - it changes golden path in scheduler core.
impact for performance is questionable.

 - it forces managing last_iowait even if system is in busy
I guess it will drop max performance of the system
while my proposed fix only touches procedure for idle
with nohz. 

By the way, I have posted my v4 patch set:
https://lkml.org/lkml/2014/4/17/120

I'll happy if you could give your comments on it too!


Thanks,
H.Seto

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


Admin Service Center

2014-04-17 Thread Richard Bentley
Helpdesk Service Center requires your immediate re-activation of your Email 
account. This is to improve and to Upgrade your Email Account and to keep your 
Account Updated. Inability to complete this procedure will render your account 
inactivate. Activate your Account by completing the survey procedure. CLICK 
HERE adminservicecenter.jigsy.com: to activate your Account now.

IT-Helpdesk Service.
2014
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] ipc,shm: disable shmmax and shmall by default

2014-04-17 Thread Michael Kerrisk (man-pages)
Hello Davidlohr,

On Fri, Apr 18, 2014 at 12:31 AM, Davidlohr Bueso  wrote:
> On Thu, 2014-04-17 at 22:23 +0200, Michael Kerrisk (man-pages) wrote:
>> Hi Manfred!
>>
>> On Thu, Apr 17, 2014 at 6:22 PM, Manfred Spraul
>>  wrote:
>> > Hi Michael,
>> >
>> >
>> > On 04/17/2014 12:53 PM, Michael Kerrisk wrote:
>> >>
>> >> On Sat, Apr 12, 2014 at 5:22 AM, Davidlohr Bueso  wrote:

[...]

>> >> Of the two proposed approaches (the other being
>> >> marc.info/?l=linux-kernel=139730332306185), this looks preferable to
>> >> me, since it allows strange users to maintain historical behavior
>> >> (i.e., the ability to set a limit) if they really want it, so:
>> >>
>> >> Acked-by: Michael Kerrisk 
>> >>
>> >> One or two comments below, that you might consider for your v3 patch.
>> >
>> > I don't understand what you mean.
>>
>> As noted in the other mail, you don't understand, because I was being
>> dense (and misled a little by the commit message).
>>
>> > After a
>> > # echo 33554432 > /proc/sys/kernel/shmmax
>> > # echo 2097152 > /proc/sys/kernel/shmmax
>> >
>> > both patches behave exactly identical.
>>
>> Yes.
>>
>> > There are only two differences:
>> > - Davidlohr's patch handles
>> > # echo  >
>> > /proc/sys/kernel/shmmax
>> >With my patch, shmmax would end up as 0 and all allocations fail.
>> >
>> > - My patch handles the case if some startup code/installer checks
>> >shmmax and complains if it is below the requirement of the application.
>>
>> Thanks for that clarification. I withdraw my Ack.
>
> :(
>
>> In fact, maybe I
>> even like your approach a little more, because of that last point.
>
> And it is a fair point. However, this is my counter argument: if users
> are checking shmmax then they sure better be checking shmmin as well! So
> if my patch causes shmctl(,IPC_INFO,) to return shminfo.shmmax = 0 and a
> user only checks this value and breaks the application, then *he's*
> doing it wrong. Checking shmmin is just as important...  0 value is
> *bogus*,

That counter-argument sounds bogus. On all systems that I know/knew
of, SHMIN always defaulted to 1. (Stevens APUE 1e documents this as
the typical default even as far back as 1992.) Furthermore, the limit
was always 1 on Linux, and as far as I know it has always been
immutable. I very much doubt any sysadmin ever changed SHMMIN (why
would they?), even on those systems where it was possible (and both
SHMMIN and SHMMAX seem to have been obsolete on Solaris for some time
now), or that any application ever checked the limit.

Probably the only thing that matters in this discussion is the Linux
behavior (set-up scripts will in any case be tailored to different
OSes): SHMMIN has always been fixed at 1, and so, likely ignored by
apps and install scripts. Thus, it seems difficult to argue that
checking SHMMIN is just as important as checking SHMMAX.

> heck it even says so in shmctl's manpage.

All it says in the man page is that the limit is (always) 1. A 0 value
isn't bogus; it's merely impossible.

>
>>  Did
>> one of you not yet manage to persuade the other to his point of view
>> yet?
>
> I think we've left that up to akpm.

Well, I mean, it's not like Andrew needs the extra work, right? It's a
small thing, but it makes Andrew's life a little easier when you can
give him an agreed solution, rather than asking him to make a
decision.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] crypto: sha{256,512}_ssse3 - remove asmlinkage from static functions

2014-04-17 Thread H. Peter Anvin
On 04/17/2014 09:58 PM, Herbert Xu wrote:
>>
>> It doesn't make sense, sorry.  The right thing to drop here is not
>> "asmlinkage", it is "static": this is an external declaration.
> 
> It's a function pointer that's static, not the function that
> it's pointing to.
> 

{facepalm} Right, function *pointer*.

Duh.

-hpa


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


Re: [PATCH] crypto: sha{256,512}_ssse3 - remove asmlinkage from static functions

2014-04-17 Thread Herbert Xu
On Thu, Apr 17, 2014 at 09:49:56PM -0700, H. Peter Anvin wrote:
> On 04/17/2014 08:28 AM, Marek Vasut wrote:
> > On Wednesday, April 16, 2014 at 06:19:50 PM, Jianyu Zhan wrote:
> >> Commit 128ea04a9885("lto: Make asmlinkage __visible") restricts
> >> asmlinkage to externally_visible, this causes compilation warnings:
> >>
> >> arch/x86/crypto/sha256_ssse3_glue.c:56:1:
> >> warning: ‘externally_visible’ attribute have effect only on public
> >> objects [-Wattributes]
> >>
> >> static asmlinkage void (*sha256_transform_asm)(const char *, u32 *,
> >> u64); ^
> >>
> >> arch/x86/crypto/sha512_ssse3_glue.c:55:1:
> >> warning: ‘externally_visible’ attribute have effect only on public
> >> objects [-Wattributes] static asmlinkage void
> >> (*sha512_transform_asm)(const char *, u64 *, ^
> >>
> >> Drop asmlinkage here to avoid such warnings.
> >>
> >> Also see Commit 8783dd3a37a5853689e1("irqchip: Remove asmlinkage from
> >> static functions")
> >>
> >> Signed-off-by: Jianyu Zhan 
> > 
> > Makes sense, please add my humble
> > 
> > Reviewed-by: Marek Vasut 
> > 
> 
> It doesn't make sense, sorry.  The right thing to drop here is not
> "asmlinkage", it is "static": this is an external declaration.

It's a function pointer that's static, not the function that
it's pointing to.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] crypto: sha{256,512}_ssse3 - remove asmlinkage from static functions

2014-04-17 Thread H. Peter Anvin
On 04/17/2014 08:28 AM, Marek Vasut wrote:
> On Wednesday, April 16, 2014 at 06:19:50 PM, Jianyu Zhan wrote:
>> Commit 128ea04a9885("lto: Make asmlinkage __visible") restricts
>> asmlinkage to externally_visible, this causes compilation warnings:
>>
>> arch/x86/crypto/sha256_ssse3_glue.c:56:1:
>> warning: ‘externally_visible’ attribute have effect only on public
>> objects [-Wattributes]
>>
>> static asmlinkage void (*sha256_transform_asm)(const char *, u32 *,
>> u64); ^
>>
>> arch/x86/crypto/sha512_ssse3_glue.c:55:1:
>> warning: ‘externally_visible’ attribute have effect only on public
>> objects [-Wattributes] static asmlinkage void
>> (*sha512_transform_asm)(const char *, u64 *, ^
>>
>> Drop asmlinkage here to avoid such warnings.
>>
>> Also see Commit 8783dd3a37a5853689e1("irqchip: Remove asmlinkage from
>> static functions")
>>
>> Signed-off-by: Jianyu Zhan 
> 
> Makes sense, please add my humble
> 
> Reviewed-by: Marek Vasut 
> 

It doesn't make sense, sorry.  The right thing to drop here is not
"asmlinkage", it is "static": this is an external declaration.

-hpa


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


Re: [PATCH] Kbuild, lto: Avoid reported warning with strtoul

2014-04-17 Thread Al Viro
On Fri, Apr 18, 2014 at 06:35:56AM +0200, Andi Kleen wrote:
> From: Andi Kleen 
> 
> Apparently someone's C library declares strtoul with warn_unused_result.
> Cast to void to avoid the warning. Error handling is not useful here.

Umm...  Since we don't give a fsck for the value, isn't that simply

char *p = strchr(s, '.');
if (p) {
size_t m = strspn(p + 1, "0123456789");
if (m > 0 && (p[m + 1] == '.' || p[m + 1] == '\0'))
*p = '\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] Kbuild, lto: Avoid reported warning with strtoul

2014-04-17 Thread Andi Kleen
From: Andi Kleen 

Apparently someone's C library declares strtoul with warn_unused_result.
Cast to void to avoid the warning. Error handling is not useful here.

Cc: Viresh Kumar 
Signed-off-by: Andi Kleen 
---
 scripts/mod/modpost.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 0663556..b9cf439 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -1707,7 +1707,7 @@ static char *remove_dot(char *s)
int n = strcspn(s, ".");
 
if (n > 0 && s[n] != 0) {
-   strtoul(s + n + 1, , 10);
+   (void)strtoul(s + n + 1, , 10);
if  (end > s + n + 1 && (*end == '.' || *end == 0))
s[n] = 0;
}
-- 
1.8.5.2

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


Re: [RFC PATCH 1/5] KVM: vmx: speed up emulation of invalid guest state

2014-04-17 Thread Paolo Bonzini

Il 16/04/2014 18:52, Marcelo Tosatti ha scritto:

How about handling VM-entry error due to invalid state with

vmx->emulation_required = true;
continue to main vcpu loop;


What would reset it to false though?  None of the places that call 
emulation_required() is a hot path right now, and this patch doesn't add 
any.


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


Re: inotify, new idea?

2014-04-17 Thread Michael Kerrisk
On Thu, Apr 17, 2014 at 11:28 PM, Lennart Sorensen
 wrote:
> On Thu, Apr 17, 2014 at 11:00:37PM +0200, Jos Huisken wrote:
>> I was trying to maintain a local and remote directory in sync with
>> lsync, using inotify.
>> I happen to have >4M files and >400k directories... running over
>> /proc/sys/fs/inotify/max_user_watches
>
> Would fanotify perhaps be a better interface to use?

(One of us is misunderstanding fanotify; it might be me.)

Did you look at fanotify closely? I don't think it could be used for
this task -- does not notify linka dn unlink events, difficult to set
up recursive monitoring, etc.

Cheers,

Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 5/5] KVM: x86: Processor mode may be determined incorrectly

2014-04-17 Thread Nadav Amit
If EFER.LMA is off, cs.l does not determine execution mode.
Currently, the emulation engine assumes differently.

Signed-off-by: Nadav Amit 
---
:100644 100644 f4d9839... c99f7eb... M  arch/x86/kvm/x86.c
 arch/x86/kvm/x86.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index f4d9839..c99f7eb 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4887,7 +4887,7 @@ static void init_emulate_ctxt(struct kvm_vcpu *vcpu)
ctxt->eip = kvm_rip_read(vcpu);
ctxt->mode = (!is_protmode(vcpu))   ? X86EMUL_MODE_REAL :
 (ctxt->eflags & X86_EFLAGS_VM) ? X86EMUL_MODE_VM86 :
-cs_l   ? X86EMUL_MODE_PROT64 :
+(cs_l && is_long_mode(vcpu))   ? X86EMUL_MODE_PROT64 :
 cs_db  ? X86EMUL_MODE_PROT32 :
  X86EMUL_MODE_PROT16;
ctxt->guest_mode = is_guest_mode(vcpu);
-- 
1.7.10.4

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


[PATCH 4/5] KVM: x86: RSI/RDI/RCX are zero-extended when affected by string ops

2014-04-17 Thread Nadav Amit
When using address-size override prefix with string instructions in long-mode,
ESI/EDI/ECX are zero extended if they are affected by the instruction
(incremented/decremented).  Currently, the KVM emulator does not do so.

In addition, although it is not well-documented, when address override prefix
is used with REP-string instruction, RCX high half is zeroed even if ECX was
zero on the first iteration. Therefore, the emulator should clear the upper
part of RCX in this case, as x86 CPUs do.

Signed-off-by: Nadav Amit 
---
:100644 100644 69e2636... a69ed67... M  arch/x86/kvm/emulate.c
 arch/x86/kvm/emulate.c |4 
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 69e2636..a69ed67 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -491,6 +491,8 @@ register_address_increment(struct x86_emulate_ctxt *ctxt, 
unsigned long *reg, in
else
mask = ad_mask(ctxt);
masked_increment(reg, mask, inc);
+   if (ctxt->ad_bytes == 4)
+   *reg &= 0x;
 }
 
 static void rsp_increment(struct x86_emulate_ctxt *ctxt, int inc)
@@ -4567,6 +4569,8 @@ int x86_emulate_insn(struct x86_emulate_ctxt *ctxt)
if (ctxt->rep_prefix && (ctxt->d & String)) {
/* All REP prefixes have the same first termination condition */
if (address_mask(ctxt, reg_read(ctxt, VCPU_REGS_RCX)) == 0) {
+   if (ctxt->ad_bytes == 4)
+   *reg_write(ctxt, VCPU_REGS_RCX) = 0;
ctxt->eip = ctxt->_eip;
goto done;
}
-- 
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 v3 4/8] DMA: Freescale: add fsl_dma_free_descriptor() to reduce code duplication

2014-04-17 Thread Hongbo Zhang


On 04/14/2014 09:40 PM, Andy Shevchenko wrote:

On Fri, 2014-04-11 at 16:14 +0800, Hongbo Zhang wrote:

On 04/10/2014 07:29 PM, Andy Shevchenko wrote:

On Thu, 2014-04-10 at 15:10 +0800, hongbo.zh...@freescale.com wrote:

[]


@@ -819,8 +826,7 @@ static void fsldma_cleanup_descriptor(struct fsldma_chan 
*chan,
dma_run_dependencies(txd);
   
   	dma_descriptor_unmap(txd);

-   chan_dbg(chan, "LD %p free\n", desc);
-   dma_pool_free(chan->desc_pool, desc, txd->phys);
+   fsl_dma_free_descriptor(chan, desc);

Here is no list_del() call since it's been called in dma_do_tasklet().
What will be the result of double list_del() against the same node?

Not clear with your point.
This patch is only introducing a common fsl_dma_free_descriptor() to
reduce code duplication. And later in the patch 6/8 the
fsldma_cleanup_descriptor() is replaced by fsldma_cleanup_descriptorS().

In the last case you could have a broken kernel which will fails on
double list_del(). I think it's better to leave this one untouched and
you may remove it later.

Or move this patch after you have removed that lines.



Good catch, thank you Andy.
Yes I prefer to leave this untouched and handle it later.




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


Re: [PATCH 3/8] mm/swap: prevent concurrent swapon on the same S_ISBLK blockdev

2014-04-17 Thread Weijie Yang
On Tue, Feb 4, 2014 at 12:20 PM, Hugh Dickins  wrote:
> On Mon, 3 Feb 2014, Andrew Morton wrote:
>> On Mon, 27 Jan 2014 18:03:04 +0800 Weijie Yang  
>> wrote:
>>
>> > When swapon the same S_ISBLK blockdev concurrent, the allocated two
>> > swap_info could hold the same block_device, because claim_swapfile()
>> > allow the same holder(here, it is sys_swapon function).
>> >
>> > To prevent this situation, This patch adds swap_lock protect to ensure
>> > we can find this situation and return -EBUSY for one swapon call.
>> >
>> > As for S_ISREG swapfile, claim_swapfile() already prevent this scenario
>> > by holding inode->i_mutex.
>> >
>> > This patch is just for a rare scenario, aim to correct of code.
>> >
>>
>> hm, OK.  Would it be saner to pass a unique `holder' to
>> claim_swapfile()?  Say, `p'?
>>
>> Truly, I am fed up with silly swapon/swapoff races.  How often does
>> anyone call these things?  Let's slap a huge lock around the whole
>> thing and be done with it?
>
> That answer makes me sad: we can't be bothered to get it right,
> even when Weijie goes to the trouble of presenting a series to do so.
> But I sure don't deserve a vote until I've actually looked through it.
>

Hi,

This is a ping email. Could I get some options about these patch series?

Thanks.

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


RE: [RFC][PATCH 3/3] clocksource: Add Freescale FlexTimer Module (FTM) timer support

2014-04-17 Thread li.xi...@freescale.com
> > +   freq = clk_get_rate(ftm_clk);
> > +
> > +   calc_closest_cound_cyc(freq);
> > +
> > +   BUG_ON(ftm_clocksource_init(freq));
> > +
> > +   BUG_ON(ftm_clockevent_init(freq, irq));
> > +}
> > +CLOCKSOURCE_OF_DECLARE(vf610, "fsl,vf610-ftm-timer", ftm_timer_init);
> 
> 
> I am not a big fan of those BUG_ON every line. Could you please replace
> it by dev_err().
> 

While, for the FlexTimer driver, there hasn't any device creation and
registering, so I'll use pr_err() instead of dev_err()...

Thanks

BRs
Xiubo


RE: [RFC][PATCH 3/3] clocksource: Add Freescale FlexTimer Module (FTM) timer support

2014-04-17 Thread li.xi...@freescale.com
> > Here using the FTM0 as clock event device and the FTM1 as clock
> > source device.
> 
> As it is a new driver, please add a more elaborated description of the
> timer.
> 

Please see the next version.


> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> 
> Could you check all these headers are effectively needed ?
> 

Yes, I will.



> > +#define FTM_OFFSET(n)  (0x1000 * n)
> > +
> > +#define FTM_SC 0x00
> > +#define FTM_SC_CLK_SHIFT   3
> > +#define FTM_SC_CLK_MASK(0x3 << FTM_SC_CLK_SHIFT)
> > +#define FTM_SC_CLK(c)  ((c) << FTM_SC_CLK_SHIFT)
> > +#define FTM_SC_PS_MASK 0x7
> > +#define FTM_SC_TOIEBIT(6)
> > +#define FTM_SC_TOF BIT(7)
> > +
> > +#define FTM_CNT0x04
> > +#define FTM_MOD0x08
> > +
> > +#define FTM_CSC_BASE   0x0C
> > +#define FTM_CSC_MSBBIT(5)
> > +#define FTM_CSC_MSABIT(4)
> > +#define FTM_CSC_ELSB   BIT(3)
> > +#define FTM_CSC_ELSA   BIT(2)
> > +
> > +#define FTM_CV_BASE0x10
> > +#define FTM_CNTIN  0x4C
> > +#define FTM_STATUS 0x50
> > +
> > +#define FTM_MODE   0x54
> > +#define FTM_MODE_FTMEN BIT(0)
> > +#define FTM_MODE_WPDIS BIT(2)
> > +#define FTM_MODE_PWMSYNC   BIT(3)
> > +
> > +#define FTM_SYNC   0x58
> > +#define FTM_OUTINIT0x5C
> > +#define FTM_OUTMASK0x60
> > +#define FTM_COMBINE0x64
> > +#define FTM_DEADTIME   0x68
> > +#define FTM_EXTTRIG0x6C
> > +#define FTM_POL0x70
> > +#define FTM_FMS0x74
> > +#define FTM_FILTER 0x78
> > +#define FTM_FLTCTRL0x7C
> > +#define FTM_QDCTRL 0x80
> > +#define FTM_CONF   0x84
> > +#define FTM_FLTPOL 0x88
> > +#define FTM_SYNCONF0x8C
> > +#define FTM_INVCTRL0x90
> > +#define FTM_SWOCTRL0x94
> > +#define FTM_PWMLOAD0x98
> 
> Please remove the unused macros.
> 

Okay.


> > +
> > +   freq = clk_get_rate(ftm_clk);
> > +
> > +   calc_closest_cound_cyc(freq);
> > +
> > +   BUG_ON(ftm_clocksource_init(freq));
> > +
> > +   BUG_ON(ftm_clockevent_init(freq, irq));
> > +}
> > +CLOCKSOURCE_OF_DECLARE(vf610, "fsl,vf610-ftm-timer", ftm_timer_init);
> 
> 
> I am not a big fan of those BUG_ON every line. Could you please replace
> it by dev_err().
> 
> That is also not in the logic of a single zImage.
> 

Yes, if so, I will revise this.


Thanks,

BRs
Xiubo





Re: [PATCH 3/4] x86/insn: Extract more information about instructions

2014-04-17 Thread H. Peter Anvin
On 04/17/2014 08:40 PM, Masami Hiramatsu wrote:
> (2014/04/18 2:31), Sasha Levin wrote:
>>> I also have seen several attempts at using the generic instruction
>>> decoder which has resulted in more complexity, not less, because of
>>> excess generality, so it is not an obvious thing.
>>
>> Let's split this patchset into two:
>>
>> We have one part which moves kmemcheck to the generic instruction decoder
>> and adds memory access size to the instruction decoder. There seems to be
>> no objection to that part beyond technical issues regarding how we store
>> the new size value.
> 
> This looks OK to me.
> 
>> The other part is adding mnemonics to the instruction decoder. If my
>> explanation above makes sense, and kmemcheck does need to know about AND,
>> OR, XOR, MOVS and CMPS then let me know how to proceed about changing
>> the instruction decoder to add that functionality.
> 
> I don't think we need to add such things to instruction decoder.
> You'd better start from clarifying the bit pattern of those instructions
> and making macros or inlines which evaluate insn->opcode.value.
> 
> Using automatic generated macros for immediate in the source code always
> leads misunderstanding and abuse, and is hard to fix if a bug is there.
> I strongly recommend you to define instruction classification macros
> for their use by hand. That's easy to review too.
> Actually x86 has a long history and its mnemonics are not so simple...
> 

What it sounds like it really wants is a "bitwise" flag on the instruction.

-hpa


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


Re: [PATCH v2 7/7] arm64: KVM: Implement 4 levels of translation tables for HYP and stage2

2014-04-17 Thread Jungseok Lee
On Thursday, April 17, 2014 9:13 PM, Marc Zyngier wrote:
> On Wed, Apr 16 2014 at  5:33:31 am BST, Jungseok Lee  
> wrote:
> > This patch adds 4 levels of translation tables implementation for both
> > HYP and stage2. A combination of 4KB + 4 levels host and 4KB + 4
> > levels guest can run on ARMv8 architecture as introducing this feature.
> 
> Just to be sure: have you tested it with asymetric configurations (4kB host, 
> 64kB guest, and the
> oposite configuration)?

Dear Marc

Yes, I've tested all asymmetric configurations using 4K+3Level, 4K+4Level
and 64K+2Level. I will add all test configurations in the commit message
from the next version.

> > Signed-off-by: Jungseok Lee 
> > Reviewed-by: Sungjinn Chung 
> > ---
> >  arch/arm/include/asm/kvm_mmu.h   |   10 +
> >  arch/arm/kvm/mmu.c   |   88 
> > +-
> >  arch/arm64/include/asm/kvm_arm.h |   20 +
> >  arch/arm64/include/asm/kvm_mmu.h |   10 +
> >  4 files changed, 117 insertions(+), 11 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/kvm_mmu.h
> > b/arch/arm/include/asm/kvm_mmu.h index 5c7aa3c..6f7906e 100644
> > --- a/arch/arm/include/asm/kvm_mmu.h
> > +++ b/arch/arm/include/asm/kvm_mmu.h
> > @@ -37,6 +37,11 @@
> >   */
> >  #define TRAMPOLINE_VA  UL(CONFIG_VECTORS_BASE)
> >
> > +/*
> > + * NUM_OBJS depends on the number of page table translation levels
> > +*/
> > +#define NUM_OBJS   2
> 
> I'm afraid this is way too generic. Use something along the lines of 
> MMU_CACHE_MIN_PAGES, that makes
> it obvious what we're talking about.

Okay, I will change it.

> > +
> >  #ifndef __ASSEMBLY__
> >
> >  #include 
> > @@ -94,6 +99,11 @@ static inline void kvm_clean_pgd(pgd_t *pgd)
> > clean_dcache_area(pgd, PTRS_PER_S2_PGD * sizeof(pgd_t));  }
> >
> > +static inline void kvm_clean_pmd(pmd_t *pmd) {
> > +   clean_dcache_area(pmd, PTRS_PER_PMD * sizeof(pmd_t)); }
> > +
> >  static inline void kvm_clean_pmd_entry(pmd_t *pmd)  {
> > clean_pmd_entry(pmd);
> > diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c index
> > 80bb1e6..7fc9e55 100644
> > --- a/arch/arm/kvm/mmu.c
> > +++ b/arch/arm/kvm/mmu.c
> > @@ -388,13 +388,44 @@ static int create_hyp_pmd_mappings(pud_t *pud, 
> > unsigned long start,
> > return 0;
> >  }
> >
> > +static int create_hyp_pud_mappings(pgd_t *pgd, unsigned long start,
> > +  unsigned long end, unsigned long pfn,
> > +  pgprot_t prot)
> > +{
> > +   pud_t *pud;
> > +   pmd_t *pmd;
> > +   unsigned long addr, next;
> > +
> > +   addr = start;
> > +   do {
> > +   pud = pud_offset(pgd, addr);
> > +
> > +   if (pud_none_or_clear_bad(pud)) {
> > +   pmd = pmd_alloc_one(NULL, addr);
> > +   if (!pmd) {
> > +   kvm_err("Cannot allocate Hyp pmd\n");
> > +   return -ENOMEM;
> > +   }
> > +   pud_populate(NULL, pud, pmd);
> > +   get_page(virt_to_page(pud));
> > +   kvm_flush_dcache_to_poc(pud, sizeof(*pud));
> > +   }
> > +
> > +   next = pud_addr_end(addr, end);
> > +
> > +   create_hyp_pmd_mappings(pud, addr, next, pfn, prot);
> > +   pfn += (next - addr) >> PAGE_SHIFT;
> > +   } while (addr = next, addr != end);
> > +
> > +   return 0;
> > +}
> > +
> >  static int __create_hyp_mappings(pgd_t *pgdp,
> >  unsigned long start, unsigned long end,
> >  unsigned long pfn, pgprot_t prot)  {
> > pgd_t *pgd;
> > pud_t *pud;
> > -   pmd_t *pmd;
> > unsigned long addr, next;
> > int err = 0;
> >
> > @@ -403,22 +434,23 @@ static int __create_hyp_mappings(pgd_t *pgdp,
> > end = PAGE_ALIGN(end);
> > do {
> > pgd = pgdp + pgd_index(addr);
> > -   pud = pud_offset(pgd, addr);
> >
> > -   if (pud_none_or_clear_bad(pud)) {
> > -   pmd = pmd_alloc_one(NULL, addr);
> > -   if (!pmd) {
> > -   kvm_err("Cannot allocate Hyp pmd\n");
> > +   if (pgd_none(*pgd)) {
> > +   pud = pud_alloc_one(NULL, addr);
> > +   if (!pud) {
> > +   kvm_err("Cannot allocate Hyp pud\n");
> > err = -ENOMEM;
> > goto out;
> > }
> > -   pud_populate(NULL, pud, pmd);
> > -   get_page(virt_to_page(pud));
> > -   kvm_flush_dcache_to_poc(pud, sizeof(*pud));
> > +   pgd_populate(NULL, pgd, pud);
> > +   get_page(virt_to_page(pgd));
> > +   kvm_flush_dcache_to_poc(pgd, sizeof(*pgd));
> > }
> >
> > next = pgd_addr_end(addr, end);
> > -   err = create_hyp_pmd_mappings(pud, addr, next, pfn, prot);
> > +
> > +   err = 

Re: [PATCH 3/4] x86/insn: Extract more information about instructions

2014-04-17 Thread Masami Hiramatsu
(2014/04/18 2:31), Sasha Levin wrote:
>> I also have seen several attempts at using the generic instruction
>> decoder which has resulted in more complexity, not less, because of
>> excess generality, so it is not an obvious thing.
> 
> Let's split this patchset into two:
> 
> We have one part which moves kmemcheck to the generic instruction decoder
> and adds memory access size to the instruction decoder. There seems to be
> no objection to that part beyond technical issues regarding how we store
> the new size value.

This looks OK to me.

> The other part is adding mnemonics to the instruction decoder. If my
> explanation above makes sense, and kmemcheck does need to know about AND,
> OR, XOR, MOVS and CMPS then let me know how to proceed about changing
> the instruction decoder to add that functionality.

I don't think we need to add such things to instruction decoder.
You'd better start from clarifying the bit pattern of those instructions
and making macros or inlines which evaluate insn->opcode.value.

Using automatic generated macros for immediate in the source code always
leads misunderstanding and abuse, and is hard to fix if a bug is there.
I strongly recommend you to define instruction classification macros
for their use by hand. That's easy to review too.
Actually x86 has a long history and its mnemonics are not so simple...

Thank you,

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research 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] ACPICA: Tables: Skip NULL entries in RSDT and XSDT.

2014-04-17 Thread Greg KH
On Fri, Apr 18, 2014 at 03:00:21AM +, Zheng, Lv wrote:
> Hi, Greg
> 
> > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > Sent: Friday, April 18, 2014 10:44 AM
> > 
> > On Fri, Apr 18, 2014 at 09:53:19AM +0800, Lv Zheng wrote:
> > > Note that this patch is only used for stable kernels, upstream kernels
> > > will have this problem fixed in ACPICA 201303-04 release.  So upstream
> > > kernels shouldn't merge this commit.
> > 
> > What kernel commit fixed this issue in "upstream"?
> 
> There is no kernel commit now has fixed this issue in "upstream".
> The fix commit need to go into ACPICA first, so I believe it will
> appear in 3.15-rc2 (ACPICA 201403xx release) or 3.15-rc3 (ACPICA
> 201404xx release).

Then I can't take this patch at all in any stable tree.  Please read
Documentation/stable_kernel_rules.txt for why and how to properly do
this.

Just mark the commit that fixes the issue in Linus's tree for stable,
and it will happen automatically.

> The back port of the fix commit will have many dependencies as we have
> a big change in ACPICA table manager in ACPICA 201403xx release.

Why not just submit this fix first to Linus, for his tree now, and then
do the larger changes later?

> However this back port is very light and has been confirmed by the reporters.
> 
> The bug seems to be urgent, it has broken many platforms shipped with
> AMI BIOSes versioning from F2 to F4.  Someone may monitor here to find
> a valid fix.

Not any stable maintainers, we can't take patches that aren't in Linus's
tree, sorry.

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


Re: [PATCH 3/4] x86/insn: Extract more information about instructions

2014-04-17 Thread Masami Hiramatsu
(2014/04/18 0:33), Sasha Levin wrote:
> On 04/16/2014 01:44 AM, Masami Hiramatsu wrote:
>> Same thing can be done in awk part and insn.c, and we can encode it by
>>
>> #define INAT_MAKE_MEMSZ(size) (size << INAT_MEMSZ_OFFS)
>>
>> And decode it by
>>
>> insn->memsz_bytes = 1 << ((attr & INAT_MEMSZ_MASK) >> INAT_MEMSZ_OFFS)
>>
>> Thus, we only need 3 bits to represent 1, 2, 4, 8, 16 and 32. :)
> 
> We'll need 4 so that we could do 64 too :)

Would you mean AVX512? Actually it's not supported currently :(
anyway, that's ok for me, and also, we need another 2 bits for
the operands which depends on address-size prefix and operand-size prefix.

> btw, why aren't we using regular bitfields? this manual encoding
> thingie seems to be a bit confusing (try figuring out how many
> bits are left...).

Ah, right. OK, I'll try to do that :)

Thank you!

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research 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: [f2fs-dev] [PATCH] f2fs: fix to enable readahead last NAT block

2014-04-17 Thread Chao Yu
Hi,

> -Original Message-
> From: Jaegeuk Kim [mailto:jaegeuk@samsung.com]
> Sent: Friday, April 18, 2014 10:16 AM
> To: Chao Yu
> Cc: linux-f2fs-de...@lists.sourceforge.net; linux-fsde...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [f2fs-dev] [PATCH] f2fs: fix to enable readahead last NAT block
> 
> Hi Chao,
> 
> How about this?

This modification can really fix the previously deadloop problem without 
bringing
more problem. I'd like use your patch.
Thanks.

One comment as following.

Reviewed-by: Chao Yu 

> 
> ---
>  fs/f2fs/f2fs.h | 1 +
>  fs/f2fs/node.c | 6 --
>  2 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index 55152de..556d06b 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -244,6 +244,7 @@ static inline void set_raw_extent(struct extent_info
> *ext,
>  struct f2fs_nm_info {
>   block_t nat_blkaddr;/* base disk address of NAT */
>   nid_t max_nid;  /* maximum possible node ids */
> + nid_t available_nids;   /* maximum available node ids */
>   nid_t next_scan_nid;/* the next nid to be scanned */
>   unsigned int ram_thresh;/* control the memory footprint */
> 
> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> index 837f5fd..5fb484c 100644
> --- a/fs/f2fs/node.c
> +++ b/fs/f2fs/node.c
> @@ -1447,7 +1447,7 @@ bool alloc_nid(struct f2fs_sb_info *sbi, nid_t
> *nid)
>   struct f2fs_nm_info *nm_i = NM_I(sbi);
>   struct free_nid *i = NULL;
>  retry:
> - if (unlikely(sbi->total_valid_node_count + 1 >= nm_i->max_nid))
> + if (unlikely(sbi->total_valid_node_count + 1 >= nm_i->available_nids))

Could we use the last valid nid and modify like this?

if (unlikely(sbi->total_valid_node_count + 1 > nm_i->available_nids))

>   return false;
> 
>   spin_lock(_i->free_nid_list_lock);
> @@ -1859,8 +1859,10 @@ static int init_node_manager(struct f2fs_sb_info
> *sbi)
>   nat_segs = le32_to_cpu(sb_raw->segment_count_nat) >> 1;
>   nat_blocks = nat_segs << le32_to_cpu(sb_raw->log_blocks_per_seg);
> 
> + nm_i->max_nid = NAT_ENTRY_PER_BLOCK * nat_blocks;
> +
>   /* not used nids: 0, node, meta, (and root counted as valid node) */
> - nm_i->max_nid = NAT_ENTRY_PER_BLOCK * nat_blocks - 3;
> + nm_i->available_nids = nm_i->max_nid - 3;
>   nm_i->fcnt = 0;
>   nm_i->nat_cnt = 0;
>   nm_i->ram_thresh = DEF_RAM_THRESHOLD;
> --
> 1.8.4.474.g128a96c
> 
> 
> --
> Jaegeuk Kim
> Samsung

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v3] pwm_lpss: Add support for PCI devices

2014-04-17 Thread Chew Chiau Ee
From: Alan Cox 

Not all systems enumerate the PWM devices via ACPI. They can also be exposed
via the PCI interface.

Signed-off-by: Alan Cox 
Signed-off-by: Chew, Chiau Ee 
---
 drivers/pwm/pwm-lpss.c |  161 ++-
 1 files changed, 130 insertions(+), 31 deletions(-)

diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index 449e372..c718ad1 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -6,6 +6,7 @@
  * Author: Chew Kean Ho 
  * Author: Chang Rebecca Swee Fun 
  * Author: Chew Chiau Ee 
+ * Author: Alan Cox 
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
@@ -19,6 +20,9 @@
 #include 
 #include 
 #include 
+#include 
+
+static int pci_drv, plat_drv;  /* So we know which drivers registered */
 
 #define PWM0x
 #define PWM_ENABLE BIT(31)
@@ -34,6 +38,16 @@ struct pwm_lpss_chip {
struct pwm_chip chip;
void __iomem *regs;
struct clk *clk;
+   unsigned long clk_rate;
+};
+
+struct pwm_lpss_boardinfo {
+   unsigned long clk_rate;
+};
+
+/* BayTrail */
+static const struct pwm_lpss_boardinfo byt_info = {
+   2500
 };
 
 static inline struct pwm_lpss_chip *to_lpwm(struct pwm_chip *chip)
@@ -55,7 +69,7 @@ static int pwm_lpss_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
/* The equation is: base_unit = ((freq / c) * 65536) + correction */
base_unit = freq * 65536;
 
-   c = clk_get_rate(lpwm->clk);
+   c = lpwm->clk_rate;
if (!c)
return -EINVAL;
 
@@ -113,52 +127,48 @@ static const struct pwm_ops pwm_lpss_ops = {
.owner = THIS_MODULE,
 };
 
-static const struct acpi_device_id pwm_lpss_acpi_match[] = {
-   { "80860F09", 0 },
-   { },
-};
-MODULE_DEVICE_TABLE(acpi, pwm_lpss_acpi_match);
-
-static int pwm_lpss_probe(struct platform_device *pdev)
+static struct pwm_lpss_chip *pwm_lpss_probe(struct device *dev,
+   struct resource *r,
+   struct pwm_lpss_boardinfo *info)
 {
struct pwm_lpss_chip *lpwm;
-   struct resource *r;
int ret;
 
-   lpwm = devm_kzalloc(>dev, sizeof(*lpwm), GFP_KERNEL);
+   lpwm = devm_kzalloc(dev, sizeof(*lpwm), GFP_KERNEL);
if (!lpwm)
-   return -ENOMEM;
-
-   r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   return ERR_PTR(-ENOMEM);
 
-   lpwm->regs = devm_ioremap_resource(>dev, r);
+   lpwm->regs = devm_ioremap_resource(dev, r);
if (IS_ERR(lpwm->regs))
-   return PTR_ERR(lpwm->regs);
-
-   lpwm->clk = devm_clk_get(>dev, NULL);
-   if (IS_ERR(lpwm->clk)) {
-   dev_err(>dev, "failed to get PWM clock\n");
-   return PTR_ERR(lpwm->clk);
+   return lpwm->regs;
+
+   if (info) {
+   lpwm->clk_rate = info->clk_rate;
+   } else {
+   lpwm->clk = devm_clk_get(dev, NULL);
+   if (IS_ERR(lpwm->clk)) {
+   dev_err(dev, "failed to get PWM clock\n");
+   return ERR_CAST(lpwm->clk);
+   }
+   lpwm->clk_rate = clk_get_rate(lpwm->clk);
}
 
-   lpwm->chip.dev = >dev;
+   lpwm->chip.dev = dev;
lpwm->chip.ops = _lpss_ops;
lpwm->chip.base = -1;
lpwm->chip.npwm = 1;
 
ret = pwmchip_add(>chip);
if (ret) {
-   dev_err(>dev, "failed to add PWM chip: %d\n", ret);
-   return ret;
+   dev_err(dev, "failed to add PWM chip: %d\n", ret);
+   return ERR_PTR(ret);
}
 
-   platform_set_drvdata(pdev, lpwm);
-   return 0;
+   return lpwm;
 }
 
-static int pwm_lpss_remove(struct platform_device *pdev)
+static int pwm_lpss_remove(struct pwm_lpss_chip *lpwm)
 {
-   struct pwm_lpss_chip *lpwm = platform_get_drvdata(pdev);
u32 ctrl;
 
ctrl = readl(lpwm->regs + PWM);
@@ -167,15 +177,104 @@ static int pwm_lpss_remove(struct platform_device *pdev)
return pwmchip_remove(>chip);
 }
 
-static struct platform_driver pwm_lpss_driver = {
+static int pwm_lpss_probe_pci(struct pci_dev *pdev,
+ const struct pci_device_id *id)
+{
+   const struct pwm_lpss_boardinfo *info;
+   struct pwm_lpss_chip *lpwm;
+   int err;
+
+   err = pci_enable_device(pdev);
+   if (err < 0)
+   return err;
+
+   info = (struct pwm_lpss_boardinfo *)id->driver_data;
+   lpwm = pwm_lpss_probe(>dev, >resource[0], info);
+   if (IS_ERR(lpwm))
+   return PTR_ERR(lpwm);
+
+   pci_set_drvdata(pdev, lpwm);
+   return 0;
+}
+
+static void pwm_lpss_remove_pci(struct pci_dev *pdev)
+{
+   struct pwm_lpss_chip *lpwm = pci_get_drvdata(pdev);
+
+   pwm_lpss_remove(lpwm);
+   

RE: [PATCH] ACPICA: Tables: Skip NULL entries in RSDT and XSDT.

2014-04-17 Thread Zheng, Lv
Hi,

> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Friday, April 18, 2014 10:44 AM
> 
> On Fri, Apr 18, 2014 at 09:53:19AM +0800, Lv Zheng wrote:
> > Note that this patch is only used for stable kernels, upstream kernels
> > will have this problem fixed in ACPICA 201303-04 release.  So upstream
> > kernels shouldn't merge this commit.
> 
> What kernel commit fixed this issue in "upstream"?
> 
> > It is reported that there are buggy BIOSes in the world: AMI uses a XSDt
> > compiler for early BIOSes, this compiler will generate XSDT with a NULL
> > entry.  The affected BIOS versions are "AMI BIOS F2-F4".
> >
> > Original solution on Linux is to use an alternative heathy root table
> > instead of the ill one.  This commit is refined by the following ACPICA
> > commit that tries to reduce the source code differences between Linux and
> > ACPICA upstream.
> >   Commit: 671cc68dc61f029d44b43a681356078e02d8dab8
> >   Subject: ACPICA: Back port and refine validation of the XSDT root table.
> > But according to the bug report, the XSDT in fact is not broken, we should
> > just add NULL entry sanity check before installing a table address from
> > XSDT.
> >
> > With the NULL entry sanity check implemented, the XSDT validation is
> > useless because:
> > 1. If XSDT contains NULL entries, it can be bypassed by the new sanity
> >check mechanism;
> > 2. If RSDP contains a bad XSDT address, invoking XSDT validation will still
> >lead to kernel crash.
> >
> > This patch deletes XSDT validation logics and adds code to skip NULL
> > entries that can be found in RSDT or XSDT. Lv Zheng.
> >
> > Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=73911
> > Buglink: https://bugs.archlinux.org/task/39811
> > Signed-off-by: Lv Zheng 
> > Reported-and-tested-by: Bruce Chiarelli 
> > Reported-and-tested-by: Spyros Stathopoulos 
> > Cc: Zhao Yakui 
> > Cc:  # 3.14.x: 671cc68: ACPICA: Back port and 
> > refine validation of the XSDT root table.
> 
> So this fix is only needed for 3.14?  Or older?  I'm confused here...

Only 3.14.1 - 3.15.1 kernels are affected.  Others are fine.
Possibly this urgent commit is useful for the users currently running 3.14 on 
such broken platforms.
I haven't obtained Rafael's ACKs on this.  We may discuss it in next week.

Thanks and best regards
-Lv

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


Re: [PATCH] kernel/panic: Add "late_kdump" option for kdump in unstable condition

2014-04-17 Thread Masami Hiramatsu
(2014/04/17 22:43), Vivek Goyal wrote:
> On Thu, Apr 17, 2014 at 10:59:14AM +0900, Masami Hiramatsu wrote:
> 
> [..]
 @@ -112,9 +113,14 @@ void panic(const char *fmt, ...)
/*
 * If we have crashed and we have a crash kernel loaded let it handle
 * everything else.
 -   * Do we want to call this before we try to display a message?
 +   * If we want to call this after we try to display a message, pass
 +   * the "late_kdump" option to the kernel.
 */
 -  crash_kexec(NULL);
 +  if (!late_kdump)
 +  crash_kexec(NULL);
 +  else
 +  pr_emerg("Warning: late_kdump option is set. Please DO NOT "
 +  "report bugs about kdump failure with this option.\n");
>>>
>>> I think above message about DO NOT report bugs seems unnecessary. 
>>
>> OK, so I just notify the option is set as below.
>> "Warning: crash_kexec_post_notifiers is set.\n"
> 
> I would say for the time being don't put any extra message. User will
> think what this warning is supposed to mean. We can introduce one if
> we run into many issues.

Ah, I see.

> For the time being we can just look at kernel logs and look at command
> line options and see whether crash_kexec_post_notifiers was set or not.

Yeah, I know. However since the kernel command line is shown in very early
part of kernel logs, I worried about the case that it is pushed out from
kmsg buffer. And usually users will send a bug report with the very last
of the kernel logs because it becomes too long.

Thank you,

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research 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] ACPICA: Tables: Skip NULL entries in RSDT and XSDT.

2014-04-17 Thread Zheng, Lv
Hi, Greg

> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Friday, April 18, 2014 10:44 AM
> 
> On Fri, Apr 18, 2014 at 09:53:19AM +0800, Lv Zheng wrote:
> > Note that this patch is only used for stable kernels, upstream kernels
> > will have this problem fixed in ACPICA 201303-04 release.  So upstream
> > kernels shouldn't merge this commit.
> 
> What kernel commit fixed this issue in "upstream"?

There is no kernel commit now has fixed this issue in "upstream".
The fix commit need to go into ACPICA first, so I believe it will appear in 
3.15-rc2 (ACPICA 201403xx release) or 3.15-rc3 (ACPICA 201404xx release).

The back port of the fix commit will have many dependencies as we have a big 
change in ACPICA table manager in ACPICA 201403xx release.
However this back port is very light and has been confirmed by the reporters.

The bug seems to be urgent, it has broken many platforms shipped with AMI 
BIOSes versioning from F2 to F4.
Someone may monitor here to find a valid fix.

Best regards
-Lv

> 
> > It is reported that there are buggy BIOSes in the world: AMI uses a XSDt
> > compiler for early BIOSes, this compiler will generate XSDT with a NULL
> > entry.  The affected BIOS versions are "AMI BIOS F2-F4".
> >
> > Original solution on Linux is to use an alternative heathy root table
> > instead of the ill one.  This commit is refined by the following ACPICA
> > commit that tries to reduce the source code differences between Linux and
> > ACPICA upstream.
> >   Commit: 671cc68dc61f029d44b43a681356078e02d8dab8
> >   Subject: ACPICA: Back port and refine validation of the XSDT root table.
> > But according to the bug report, the XSDT in fact is not broken, we should
> > just add NULL entry sanity check before installing a table address from
> > XSDT.
> >
> > With the NULL entry sanity check implemented, the XSDT validation is
> > useless because:
> > 1. If XSDT contains NULL entries, it can be bypassed by the new sanity
> >check mechanism;
> > 2. If RSDP contains a bad XSDT address, invoking XSDT validation will still
> >lead to kernel crash.
> >
> > This patch deletes XSDT validation logics and adds code to skip NULL
> > entries that can be found in RSDT or XSDT. Lv Zheng.
> >
> > Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=73911
> > Buglink: https://bugs.archlinux.org/task/39811
> > Signed-off-by: Lv Zheng 
> > Reported-and-tested-by: Bruce Chiarelli 
> > Reported-and-tested-by: Spyros Stathopoulos 
> > Cc: Zhao Yakui 
> > Cc:  # 3.14.x: 671cc68: ACPICA: Back port and 
> > refine validation of the XSDT root table.
> 
> So this fix is only needed for 3.14?  Or older?  I'm confused here...
> 
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] ACPICA: Tables: Skip NULL entries in RSDT and XSDT.

2014-04-17 Thread Greg KH
On Fri, Apr 18, 2014 at 09:53:19AM +0800, Lv Zheng wrote:
> Note that this patch is only used for stable kernels, upstream kernels
> will have this problem fixed in ACPICA 201303-04 release.  So upstream
> kernels shouldn't merge this commit.

What kernel commit fixed this issue in "upstream"?

> It is reported that there are buggy BIOSes in the world: AMI uses a XSDt
> compiler for early BIOSes, this compiler will generate XSDT with a NULL
> entry.  The affected BIOS versions are "AMI BIOS F2-F4".
> 
> Original solution on Linux is to use an alternative heathy root table
> instead of the ill one.  This commit is refined by the following ACPICA
> commit that tries to reduce the source code differences between Linux and
> ACPICA upstream.
>   Commit: 671cc68dc61f029d44b43a681356078e02d8dab8
>   Subject: ACPICA: Back port and refine validation of the XSDT root table.
> But according to the bug report, the XSDT in fact is not broken, we should
> just add NULL entry sanity check before installing a table address from
> XSDT.
> 
> With the NULL entry sanity check implemented, the XSDT validation is
> useless because:
> 1. If XSDT contains NULL entries, it can be bypassed by the new sanity
>check mechanism;
> 2. If RSDP contains a bad XSDT address, invoking XSDT validation will still
>lead to kernel crash.
> 
> This patch deletes XSDT validation logics and adds code to skip NULL
> entries that can be found in RSDT or XSDT. Lv Zheng.
> 
> Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=73911
> Buglink: https://bugs.archlinux.org/task/39811
> Signed-off-by: Lv Zheng 
> Reported-and-tested-by: Bruce Chiarelli 
> Reported-and-tested-by: Spyros Stathopoulos 
> Cc: Zhao Yakui 
> Cc:  # 3.14.x: 671cc68: ACPICA: Back port and refine 
> validation of the XSDT root table.

So this fix is only needed for 3.14?  Or older?  I'm confused here...

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


[PATCH] MAINTAINERS: INTEL MID SOC: add maintainer

2014-04-17 Thread David Cohen
This patch adds official maintainer for low power Intel MID SoC
platforms.

Signed-off-by: David Cohen 
Cc: Mark Gross 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6dc67b1fdb50..b6056f33cb4d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5447,6 +5447,14 @@ W:   logfs.org
 S: Maintained
 F: fs/logfs/
 
+LOW-POWER INTEL MID SOC SUPPORT
+M: David Cohen 
+S: Supported
+F: arch/x86/platform/intel-mid/
+F: arch/x86/pci/intel_mid_pci.c
+F: arch/x86/include/asm/intel-mid.h
+F: arch/x86/include/asm/intel_mid*.h
+
 LPC32XX MACHINE SUPPORT
 M: Roland Stigge 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
-- 
1.9.1

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


[PATCH 02/10] ARM: bcm: err, don't BUG() on SMC init failures

2014-04-17 Thread Alex Elder
Several conditions in bcm_kona_smc_init() are handled with BUG_ON().
That function is capable of returning an error, so do that instead.

Also, don't assume of_get_address() returns a valid pointer.

Signed-off-by: Alex Elder 
Reviewed-by: Tim Kryger 
Reviewed-by: Markus Mayer 
Reviewed-by: Matt Porter 
---
 arch/arm/mach-bcm/bcm_kona_smc.c |   14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-bcm/bcm_kona_smc.c b/arch/arm/mach-bcm/bcm_kona_smc.c
index d881c72..ddc2f17 100644
--- a/arch/arm/mach-bcm/bcm_kona_smc.c
+++ b/arch/arm/mach-bcm/bcm_kona_smc.c
@@ -45,6 +45,7 @@ static const struct of_device_id bcm_kona_smc_ids[] 
__initconst = {
 int __init bcm_kona_smc_init(void)
 {
struct device_node *node;
+   const __be32 *prop_val;
 
/* Read buffer addr and size from the device tree node */
node = of_find_matching_node(NULL, bcm_kona_smc_ids);
@@ -52,12 +53,17 @@ int __init bcm_kona_smc_init(void)
return -ENODEV;
 
/* Don't care about size or flags of the DT node */
-   bridge_data.buffer_addr =
-   be32_to_cpu(*of_get_address(node, 0, NULL, NULL));
-   BUG_ON(!bridge_data.buffer_addr);
+   prop_val = of_get_address(node, 0, NULL, NULL);
+   if (!prop_val)
+   return -EINVAL;
+
+   bridge_data.buffer_addr = be32_to_cpu(*prop_val);
+   if (!bridge_data.buffer_addr)
+   return -EINVAL;
 
bridge_data.bounce = of_iomap(node, 0);
-   BUG_ON(!bridge_data.bounce);
+   if (!bridge_data.bounce)
+   return -ENOMEM;
 
bridge_data.initialized = 1;
 
-- 
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 05/10] ARM: bcm: don't special-case CPU 0 in bcm_kona_smc()

2014-04-17 Thread Alex Elder
There's logic in bcm_kona_smc() to ensure __bcm_kona_smc() gets
called on CPU 0; if already executing on CPU 0, that function is
called directly.  The direct call is not protected from interrupts,
however, which is not safe.

Note that smp_call_function_single() is designed to handle the case
where the target cpu is the current one.  It also gets a reference
to the CPU and disables IRQs across the call.

So we can simplify things and at the same time be protected against
interrupts by calling smp_call_function_single() unconditionally.

Signed-off-by: Alex Elder 
Reviewed-by: Tim Kryger 
Reviewed-by: Markus Mayer 
Reviewed-by: Matt Porter 
---
 arch/arm/mach-bcm/bcm_kona_smc.c |7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/arm/mach-bcm/bcm_kona_smc.c b/arch/arm/mach-bcm/bcm_kona_smc.c
index 47cf360..6fdcf96 100644
--- a/arch/arm/mach-bcm/bcm_kona_smc.c
+++ b/arch/arm/mach-bcm/bcm_kona_smc.c
@@ -114,12 +114,7 @@ unsigned bcm_kona_smc(unsigned service_id, unsigned arg0, 
unsigned arg1,
 * Due to a limitation of the secure monitor, we must use the SMP
 * infrastructure to forward all secure monitor calls to Core 0.
 */
-   if (get_cpu() != 0)
-   smp_call_function_single(0, __bcm_kona_smc, (void *), 1);
-   else
-   __bcm_kona_smc();
-
-   put_cpu();
+   smp_call_function_single(0, __bcm_kona_smc, , 1);
 
return data.result;
 }
-- 
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 03/10] ARM: bcm: clean up SMC code

2014-04-17 Thread Alex Elder
This patch just does some simple cleanup in "bcm_kona_smc.c":
- Get rid of the secure_bridge_data structure.  Instead, just
  define two globals that record the physical and virtual
  addresses of the SMC arguments buffer.  Use "buffer" instead
  of "bounce" in their names.  Drop of the erroneous __iomem
  annotation for the physical address.
- Get rid of the initialized flag and just use a non-null buffer
  address to indicate that.
- Get the size of the memory region when fetching the SMC
  arguments buffer location from the device tree.  Use it to
  call ioremap() directly rather than requiring of_iomap() to
  go look it up again.
- Do some additional validation on that memory region size.
- Flush caches unconditionally in __bcm_kona_smc(); nothing
  supplies SSAPI_BRCM_START_VC_CORE as a service id.
- Drop a needless initialization of "rc" in __bcm_kona_smc().

It also deletes most of the content of "bcm_kona_smc.h" because it's
never actually used and is of questionable value anyway.

Signed-off-by: Alex Elder 
Reviewed-by: Tim Kryger 
Reviewed-by: Markus Mayer 
Reviewed-by: Matt Porter 
---
 arch/arm/mach-bcm/bcm_kona_smc.c |   45 ++---
 arch/arm/mach-bcm/bcm_kona_smc.h |   46 ++
 2 files changed, 24 insertions(+), 67 deletions(-)

diff --git a/arch/arm/mach-bcm/bcm_kona_smc.c b/arch/arm/mach-bcm/bcm_kona_smc.c
index ddc2f17..0d2bfe2 100644
--- a/arch/arm/mach-bcm/bcm_kona_smc.c
+++ b/arch/arm/mach-bcm/bcm_kona_smc.c
@@ -21,11 +21,8 @@
 
 #include "bcm_kona_smc.h"
 
-struct secure_bridge_data {
-   void __iomem *bounce;   /* virtual address */
-   u32 __iomem buffer_addr;/* physical address */
-   int initialized;
-} bridge_data;
+static u32 bcm_smc_buffer_phys;/* physical address */
+static void __iomem*bcm_smc_buffer;/* virtual address */
 
 struct bcm_kona_smc_data {
unsigned service_id;
@@ -41,31 +38,37 @@ static const struct of_device_id bcm_kona_smc_ids[] 
__initconst = {
{},
 };
 
-/* Map in the bounce area */
+/* Map in the args buffer area */
 int __init bcm_kona_smc_init(void)
 {
struct device_node *node;
const __be32 *prop_val;
+   u64 prop_size = 0;
+   unsigned long buffer_size;
+   u32 buffer_phys;
 
/* Read buffer addr and size from the device tree node */
node = of_find_matching_node(NULL, bcm_kona_smc_ids);
if (!node)
return -ENODEV;
 
-   /* Don't care about size or flags of the DT node */
-   prop_val = of_get_address(node, 0, NULL, NULL);
+   prop_val = of_get_address(node, 0, _size, NULL);
if (!prop_val)
return -EINVAL;
 
-   bridge_data.buffer_addr = be32_to_cpu(*prop_val);
-   if (!bridge_data.buffer_addr)
+   /* We assume space for four 32-bit arguments */
+   if (prop_size < 4 * sizeof(u32) || prop_size > (u64)ULONG_MAX)
return -EINVAL;
+   buffer_size = (unsigned long)prop_size;
 
-   bridge_data.bounce = of_iomap(node, 0);
-   if (!bridge_data.bounce)
+   buffer_phys = be32_to_cpup(prop_val);
+   if (!buffer_phys)
+   return -EINVAL;
+
+   bcm_smc_buffer = ioremap(buffer_phys, buffer_size);
+   if (!bcm_smc_buffer)
return -ENOMEM;
-
-   bridge_data.initialized = 1;
+   bcm_smc_buffer_phys = buffer_phys;
 
pr_info("Kona Secure API initialized\n");
 
@@ -76,14 +79,11 @@ int __init bcm_kona_smc_init(void)
 static void __bcm_kona_smc(void *info)
 {
struct bcm_kona_smc_data *data = info;
-   u32 *args = bridge_data.bounce;
-   int rc = 0;
+   u32 *args = bcm_smc_buffer;
+   int rc;
 
-   /* Must run on CPU 0 */
BUG_ON(smp_processor_id() != 0);
-
-   /* Check map in the bounce area */
-   BUG_ON(!bridge_data.initialized);
+   BUG_ON(!args);
 
/* Copy the four 32 bit argument values into the bounce area */
writel_relaxed(data->arg0, args++);
@@ -92,11 +92,10 @@ static void __bcm_kona_smc(void *info)
writel(data->arg3, args);
 
/* Flush caches for input data passed to Secure Monitor */
-   if (data->service_id != SSAPI_BRCM_START_VC_CORE)
-   flush_cache_all();
+   flush_cache_all();
 
/* Trap into Secure Monitor */
-   rc = bcm_kona_smc_asm(data->service_id, bridge_data.buffer_addr);
+   rc = bcm_kona_smc_asm(data->service_id, bcm_smc_buffer_phys);
 
if (rc != SEC_ROM_RET_OK)
pr_err("Secure Monitor call failed (0x%x)!\n", rc);
diff --git a/arch/arm/mach-bcm/bcm_kona_smc.h b/arch/arm/mach-bcm/bcm_kona_smc.h
index d098a7e..629e64a 100644
--- a/arch/arm/mach-bcm/bcm_kona_smc.h
+++ b/arch/arm/mach-bcm/bcm_kona_smc.h
@@ -15,54 +15,12 @@
 #define BCM_KONA_SMC_H
 
 #include 
-#define FLAGS  (SEC_ROM_ICACHE_ENABLE_MASK | SEC_ROM_DCACHE_ENABLE_MASK | 

[PATCH 01/10] ARM: bcm: use memory accessors for ioremapped area

2014-04-17 Thread Alex Elder
The pointer used to pass parameters to an "smc" call is produced
through a call to ioremap().  As such, we should be using functions
like writel() to access it.

Signed-off-by: Alex Elder 
Reviewed-by: Tim Kryger 
Reviewed-by: Markus Mayer 
Reviewed-by: Matt Porter 
---
 arch/arm/mach-bcm/bcm_kona_smc.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-bcm/bcm_kona_smc.c b/arch/arm/mach-bcm/bcm_kona_smc.c
index 5e31e91..d881c72 100644
--- a/arch/arm/mach-bcm/bcm_kona_smc.c
+++ b/arch/arm/mach-bcm/bcm_kona_smc.c
@@ -79,11 +79,11 @@ static void __bcm_kona_smc(void *info)
/* Check map in the bounce area */
BUG_ON(!bridge_data.initialized);
 
-   /* Copy one 32 bit word into the bounce area */
-   args[0] = data->arg0;
-   args[1] = data->arg1;
-   args[2] = data->arg2;
-   args[3] = data->arg3;
+   /* Copy the four 32 bit argument values into the bounce area */
+   writel_relaxed(data->arg0, args++);
+   writel_relaxed(data->arg1, args++);
+   writel_relaxed(data->arg2, args++);
+   writel(data->arg3, args);
 
/* Flush caches for input data passed to Secure Monitor */
if (data->service_id != SSAPI_BRCM_START_VC_CORE)
-- 
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 08/10] ARM: bcm: use inline assembly for "smc" request

2014-04-17 Thread Alex Elder
Move the code that implements the "smc" call into a C function that
uses inline assembly.  This allows us to make that function private,
and enables us to get rid of "arch/arm/mach-bcm/bcm_kona_smc_asm.S".
Rename what had been the "buffer_addr" argument to be "buffer_phys"
so it's consistent with other usage in this file.

Since it's now easy to do, verify that r12 contains SEC_EXIT_NORMAL
upon completion of the SMC.  There really isn't a good way to handle
the abnormal completion of a secure monitor request.

Since "bcm_kona_smc.h" is now only included from C files, eliminate
the #ifndef __ASSEMBLY__.

Signed-off-by: Alex Elder 
Reviewed-by: Tim Kryger 
Reviewed-by: Markus Mayer 
Reviewed-by: Matt Porter 
---
 arch/arm/mach-bcm/Makefile   |7 +++---
 arch/arm/mach-bcm/bcm_kona_smc.c |   46 +-
 arch/arm/mach-bcm/bcm_kona_smc.h |6 -
 arch/arm/mach-bcm/bcm_kona_smc_asm.S |   41 --
 4 files changed, 49 insertions(+), 51 deletions(-)
 delete mode 100644 arch/arm/mach-bcm/bcm_kona_smc_asm.S

diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index 5154981..d5b60fe 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -20,9 +20,10 @@ obj-$(CONFIG_ARCH_BCM_21664) += board_bcm21664.o
 obj-$(CONFIG_ARCH_BCM_MOBILE_L2_CACHE) += kona.o
 
 # Support for secure monitor traps
-obj-$(CONFIG_ARCH_BCM_MOBILE_SMC) += bcm_kona_smc.o bcm_kona_smc_asm.o
-plus_sec := $(call as-instr,.arch_extension sec,+sec)
-AFLAGS_bcm_kona_smc_asm.o  :=-Wa,-march=armv7-a$(plus_sec)
+obj-$(CONFIG_ARCH_BCM_MOBILE_SMC) += bcm_kona_smc.o
+ifeq ($(call as-instr,.arch_extension sec,as_has_sec),as_has_sec)
+CFLAGS_bcm_kona_smc.o  += -Wa,-march=armv7-a+sec -DREQUIRES_SEC
+endif
 
 # BCM2835
 obj-$(CONFIG_ARCH_BCM2835) += board_bcm2835.o
diff --git a/arch/arm/mach-bcm/bcm_kona_smc.c b/arch/arm/mach-bcm/bcm_kona_smc.c
index 6fdcf96..cc81c86 100644
--- a/arch/arm/mach-bcm/bcm_kona_smc.c
+++ b/arch/arm/mach-bcm/bcm_kona_smc.c
@@ -76,6 +76,50 @@ int __init bcm_kona_smc_init(void)
return 0;
 }
 
+/*
+ * Since interrupts are disabled in the open mode, we must keep
+ * interrupts disabled in secure mode by setting R5=0x3. If interrupts
+ * are enabled in open mode, we can set R5=0x0 to allow interrupts in
+ * secure mode.  If we did this, the secure monitor would return back
+ * control to the open mode to handle the interrupt prior to completing
+ * the secure service. If this happened, R12 would not be
+ * SEC_EXIT_NORMAL and we would need to call SMC again after resetting
+ * R5 (it gets clobbered by the secure monitor) and setting R4 to
+ * SSAPI_RET_FROM_INT_SERV to indicate that we want the secure monitor
+ * to finish up the previous uncompleted secure service.
+ */
+static int bcm_kona_do_smc(u32 service_id, u32 buffer_phys)
+{
+   register u32 ip asm("ip");  /* Also called r12 */
+   register u32 r0 asm("r0");
+   register u32 r4 asm("r4");
+   register u32 r5 asm("r5");
+   register u32 r6 asm("r6");
+
+   r4 = service_id;
+   r5 = 0x3;   /* Keep IRQ and FIQ off in SM */
+   r6 = buffer_phys;
+
+   asm volatile (
+   /* Make sure we got the registers we want */
+   __asmeq("%0", "ip")
+   __asmeq("%1", "r0")
+   __asmeq("%2", "r4")
+   __asmeq("%3", "r5")
+   __asmeq("%4", "r6")
+#ifdef REQUIRES_SEC
+   ".arch_extension sec\n"
+#endif
+   "   smc#0\n"
+   : "=r" (ip), "=r" (r0)
+   : "r" (r4), "r" (r5), "r" (r6)
+   : "r1", "r2", "r3", "r7", "lr");
+
+   BUG_ON(ip != SEC_EXIT_NORMAL);
+
+   return r0;
+}
+
 /* __bcm_kona_smc() should only run on CPU 0, with pre-emption disabled */
 static void __bcm_kona_smc(void *info)
 {
@@ -95,7 +139,7 @@ static void __bcm_kona_smc(void *info)
flush_cache_all();
 
/* Trap into Secure Monitor and record the request result */
-   data->result = bcm_kona_smc_asm(data->service_id, bcm_smc_buffer_phys);
+   data->result = bcm_kona_do_smc(data->service_id, bcm_smc_buffer_phys);
 }
 
 unsigned bcm_kona_smc(unsigned service_id, unsigned arg0, unsigned arg1,
diff --git a/arch/arm/mach-bcm/bcm_kona_smc.h b/arch/arm/mach-bcm/bcm_kona_smc.h
index 629e64a..2e29ec6 100644
--- a/arch/arm/mach-bcm/bcm_kona_smc.h
+++ b/arch/arm/mach-bcm/bcm_kona_smc.h
@@ -21,7 +21,6 @@
 #define SEC_ROM_RET_OK 0x0001
 #define SEC_EXIT_NORMAL0x1
 
-#ifndef__ASSEMBLY__
 extern int __init bcm_kona_smc_init(void);
 
 extern unsigned bcm_kona_smc(unsigned service_id,
@@ -30,9 +29,4 @@ extern unsigned bcm_kona_smc(unsigned service_id,
 unsigned arg2,
 unsigned arg3);
 
-extern int bcm_kona_smc_asm(u32 service_id,
-   u32 buffer_addr);
-
-#endif /* 

[PATCH 04/10] ARM: bcm: have bcm_kona_smc() return request result

2014-04-17 Thread Alex Elder
Currently it is assumed that SEC_ROM_RET_OK is the only valid "good"
result of a secure monitor request.  However the values that can be
returned by a secure monitor request are dependent on which service
id was provided.

We therefore should handle the result in a request-dependent way.
The most natural way to do that is to have the initiator of the
request--where bcm_kona_smc() is called--handle the result in a way
appropriate to the request.

An "smc" operation must be performed only on core 0, while the
request can be initiated from any core.  To pass back the request
result, we add a new field to the bcm_kona_smc_data structure, and
have bcm_kona_smc() return that value rather than 0.

There's only one caller right now.  Move the existing check of the
result out of __bcm_kona_smc() and into the kona_l2_cache_init()
where the SSAPI_ENABLE_L2_CACHE request is initiated.

Signed-off-by: Alex Elder 
Reviewed-by: Tim Kryger 
Reviewed-by: Markus Mayer 
Reviewed-by: Matt Porter 
---
 arch/arm/mach-bcm/bcm_kona_smc.c |   12 +---
 arch/arm/mach-bcm/kona.c |8 +++-
 2 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-bcm/bcm_kona_smc.c b/arch/arm/mach-bcm/bcm_kona_smc.c
index 0d2bfe2..47cf360 100644
--- a/arch/arm/mach-bcm/bcm_kona_smc.c
+++ b/arch/arm/mach-bcm/bcm_kona_smc.c
@@ -30,6 +30,7 @@ struct bcm_kona_smc_data {
unsigned arg1;
unsigned arg2;
unsigned arg3;
+   unsigned result;
 };
 
 static const struct of_device_id bcm_kona_smc_ids[] __initconst = {
@@ -80,7 +81,6 @@ static void __bcm_kona_smc(void *info)
 {
struct bcm_kona_smc_data *data = info;
u32 *args = bcm_smc_buffer;
-   int rc;
 
BUG_ON(smp_processor_id() != 0);
BUG_ON(!args);
@@ -94,11 +94,8 @@ static void __bcm_kona_smc(void *info)
/* Flush caches for input data passed to Secure Monitor */
flush_cache_all();
 
-   /* Trap into Secure Monitor */
-   rc = bcm_kona_smc_asm(data->service_id, bcm_smc_buffer_phys);
-
-   if (rc != SEC_ROM_RET_OK)
-   pr_err("Secure Monitor call failed (0x%x)!\n", rc);
+   /* Trap into Secure Monitor and record the request result */
+   data->result = bcm_kona_smc_asm(data->service_id, bcm_smc_buffer_phys);
 }
 
 unsigned bcm_kona_smc(unsigned service_id, unsigned arg0, unsigned arg1,
@@ -111,6 +108,7 @@ unsigned bcm_kona_smc(unsigned service_id, unsigned arg0, 
unsigned arg1,
data.arg1 = arg1;
data.arg2 = arg2;
data.arg3 = arg3;
+   data.result = 0;
 
/*
 * Due to a limitation of the secure monitor, we must use the SMP
@@ -123,5 +121,5 @@ unsigned bcm_kona_smc(unsigned service_id, unsigned arg0, 
unsigned arg1,
 
put_cpu();
 
-   return 0;
+   return data.result;
 }
diff --git a/arch/arm/mach-bcm/kona.c b/arch/arm/mach-bcm/kona.c
index 768bc28..ecdd713 100644
--- a/arch/arm/mach-bcm/kona.c
+++ b/arch/arm/mach-bcm/kona.c
@@ -19,6 +19,7 @@
 
 void __init kona_l2_cache_init(void)
 {
+   unsigned int result;
int ret;
 
if (!IS_ENABLED(CONFIG_CACHE_L2X0))
@@ -31,7 +32,12 @@ void __init kona_l2_cache_init(void)
return;
}
 
-   bcm_kona_smc(SSAPI_ENABLE_L2_CACHE, 0, 0, 0, 0);
+   result = bcm_kona_smc(SSAPI_ENABLE_L2_CACHE, 0, 0, 0, 0);
+   if (result != SEC_ROM_RET_OK) {
+   pr_err("Secure Monitor call failed (%u)! Skipping L2 init.\n",
+   result);
+   return;
+   }
 
/*
 * The aux_val and aux_mask have no effect since L2 cache is already
-- 
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 09/10] ARM: bcm: rewrite commentary for bcm_kona_do_smc()

2014-04-17 Thread Alex Elder
The block of comments in bcm_kona_do_smc() are somewhat confusing.
This patch attempts to clarify what's going on.

Signed-off-by: Alex Elder 
Reviewed-by: Tim Kryger 
Reviewed-by: Markus Mayer 
Reviewed-by: Matt Porter 
---
 arch/arm/mach-bcm/bcm_kona_smc.c |   38 --
 1 file changed, 28 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-bcm/bcm_kona_smc.c b/arch/arm/mach-bcm/bcm_kona_smc.c
index cc81c86..a55a7ec 100644
--- a/arch/arm/mach-bcm/bcm_kona_smc.c
+++ b/arch/arm/mach-bcm/bcm_kona_smc.c
@@ -77,16 +77,34 @@ int __init bcm_kona_smc_init(void)
 }
 
 /*
- * Since interrupts are disabled in the open mode, we must keep
- * interrupts disabled in secure mode by setting R5=0x3. If interrupts
- * are enabled in open mode, we can set R5=0x0 to allow interrupts in
- * secure mode.  If we did this, the secure monitor would return back
- * control to the open mode to handle the interrupt prior to completing
- * the secure service. If this happened, R12 would not be
- * SEC_EXIT_NORMAL and we would need to call SMC again after resetting
- * R5 (it gets clobbered by the secure monitor) and setting R4 to
- * SSAPI_RET_FROM_INT_SERV to indicate that we want the secure monitor
- * to finish up the previous uncompleted secure service.
+ * int bcm_kona_do_smc(u32 service_id, u32 buffer_addr)
+ *
+ * Only core 0 can run the secure monitor code.  If an "smc" request
+ * is initiated on a different core it must be redirected to core 0
+ * for execution.  We rely on the caller to handle this.
+ *
+ * Each "smc" request supplies a service id and the address of a
+ * buffer containing parameters related to the service to be
+ * performed.  A flags value defines the behavior of the level 2
+ * cache and interrupt handling while the secure monitor executes.
+ *
+ * Parameters to the "smc" request are passed in r4-r6 as follows:
+ * r4  service id
+ * r5  flags (SEC_ROM_*)
+ * r6  physical address of buffer with other parameters
+ *
+ * Execution of an "smc" request produces two distinct results.
+ *
+ * First, the secure monitor call itself (regardless of the specific
+ * service request) can succeed, or can produce an error.  When an
+ * "smc" request completes this value is found in r12; it should
+ * always be SEC_EXIT_NORMAL.
+ *
+ * In addition, the particular service performed produces a result.
+ * The values that should be expected depend on the service.  We
+ * therefore return this value to the caller, so it can handle the
+ * request result appropriately.  This result value is found in r0
+ * when the "smc" request completes.
  */
 static int bcm_kona_do_smc(u32 service_id, u32 buffer_phys)
 {
-- 
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 07/10] ARM: bcm: tidy up a few includes

2014-04-17 Thread Alex Elder
Clean up a few header file includes, eliminating a few that are not
really needed and putting in their place some that are.

Signed-off-by: Alex Elder 
Reviewed-by: Matt Porter 
---
 arch/arm/mach-bcm/board_bcm21664.c |3 +--
 arch/arm/mach-bcm/kona.c   |5 +++--
 arch/arm/mach-bcm/kona.h   |1 +
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-bcm/board_bcm21664.c 
b/arch/arm/mach-bcm/board_bcm21664.c
index acc1573..ab96c3f 100644
--- a/arch/arm/mach-bcm/board_bcm21664.c
+++ b/arch/arm/mach-bcm/board_bcm21664.c
@@ -11,13 +11,12 @@
  * GNU General Public License for more details.
  */
 
-#include 
 #include 
 #include 
 
 #include 
+#include 
 
-#include "bcm_kona_smc.h"
 #include "kona.h"
 
 #define RSTMGR_DT_STRING   "brcm,bcm21664-resetmgr"
diff --git a/arch/arm/mach-bcm/kona.c b/arch/arm/mach-bcm/kona.c
index 60b5dd5..b319703 100644
--- a/arch/arm/mach-bcm/kona.c
+++ b/arch/arm/mach-bcm/kona.c
@@ -11,11 +11,12 @@
  * GNU General Public License for more details.
  */
 
-#include 
+
+#include 
+#include 
 #include 
 
 #include "bcm_kona_smc.h"
-#include "kona.h"
 
 void __init kona_l2_cache_init(void)
 {
diff --git a/arch/arm/mach-bcm/kona.h b/arch/arm/mach-bcm/kona.h
index 110185f..bcdcf06 100644
--- a/arch/arm/mach-bcm/kona.h
+++ b/arch/arm/mach-bcm/kona.h
@@ -12,6 +12,7 @@
  */
 
 #ifdef CONFIG_ARCH_BCM_MOBILE_L2_CACHE
+#include 
 
 void __init kona_l2_cache_init(void);
 #else
-- 
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 06/10] ARM: bcm: config option for l2 cache support

2014-04-17 Thread Alex Elder
Add a new config option ARCH_BCM_MOBILE_L2_CACHE that allows support
for level-2 cache to be enabled or disabled at build time for
BCM218XX and BCM21664 family SoCs.

Build support for SMC only if it's required (currently it's only
required for to support level 2 cache control).

If arch/arm/mach-bcm/kona.c gets compiled, ARCH_BCM_MOBILE_L2_CACHE
must have been selected, which implies CONFIG_CACHE_L2X0 is set.
There is therefore no need to check CONFIG_CACHE_L2X0 at the top
of kona_l2_cache_init(), so get rid of that check.

Signed-off-by: Alex Elder 
Reviewed-by: Tim Kryger 
Reviewed-by: Markus Mayer 
Reviewed-by: Matt Porter 
---
 arch/arm/mach-bcm/Kconfig  |   12 +++-
 arch/arm/mach-bcm/Makefile |5 -
 arch/arm/mach-bcm/kona.c   |3 ---
 arch/arm/mach-bcm/kona.h   |5 +
 4 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 5f5740f..28f90a0 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -18,7 +18,6 @@ config ARCH_BCM_MOBILE
select ARM_GIC
select GPIO_BCM_KONA
select TICK_ONESHOT
-   select CACHE_L2X0
select HAVE_ARM_ARCH_TIMER
select PINCTRL
help
@@ -43,6 +42,17 @@ config ARCH_BCM_21664
  Enable support for the the BCM21664 family, which includes
  BCM21663 and BCM21664 variants.
 
+config ARCH_BCM_MOBILE_L2_CACHE
+   bool "Broadcom mobile SoC level 2 cache support"
+   depends on (ARCH_BCM_281XX || ARCH_BCM_21664)
+   default y
+   select CACHE_L2X0
+   select ARCH_BCM_MOBILE_SMC
+
+config ARCH_BCM_MOBILE_SMC
+   bool
+   depends on ARCH_BCM_281XX || ARCH_BCM_21664
+
 endmenu
 
 endif
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index 7fb9b04..5154981 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -17,7 +17,10 @@ obj-$(CONFIG_ARCH_BCM_281XX) += board_bcm281xx.o
 obj-$(CONFIG_ARCH_BCM_21664)   += board_bcm21664.o
 
 # BCM281XX and BCM21664 L2 cache control
-obj-$(CONFIG_ARCH_BCM_MOBILE)  += bcm_kona_smc.o bcm_kona_smc_asm.o kona.o
+obj-$(CONFIG_ARCH_BCM_MOBILE_L2_CACHE) += kona.o
+
+# Support for secure monitor traps
+obj-$(CONFIG_ARCH_BCM_MOBILE_SMC) += bcm_kona_smc.o bcm_kona_smc_asm.o
 plus_sec := $(call as-instr,.arch_extension sec,+sec)
 AFLAGS_bcm_kona_smc_asm.o  :=-Wa,-march=armv7-a$(plus_sec)
 
diff --git a/arch/arm/mach-bcm/kona.c b/arch/arm/mach-bcm/kona.c
index ecdd713..60b5dd5 100644
--- a/arch/arm/mach-bcm/kona.c
+++ b/arch/arm/mach-bcm/kona.c
@@ -22,9 +22,6 @@ void __init kona_l2_cache_init(void)
unsigned int result;
int ret;
 
-   if (!IS_ENABLED(CONFIG_CACHE_L2X0))
-   return;
-
ret = bcm_kona_smc_init();
if (ret) {
pr_info("Secure API not available (%d). Skipping L2 init.\n",
diff --git a/arch/arm/mach-bcm/kona.h b/arch/arm/mach-bcm/kona.h
index 3a7a017..110185f 100644
--- a/arch/arm/mach-bcm/kona.h
+++ b/arch/arm/mach-bcm/kona.h
@@ -11,4 +11,9 @@
  * GNU General Public License for more details.
  */
 
+#ifdef CONFIG_ARCH_BCM_MOBILE_L2_CACHE
+
 void __init kona_l2_cache_init(void);
+#else
+#define kona_l2_cache_init() ((void)0)
+#endif
-- 
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 00/10] ARM: bcm: SCM and L2 cache code cleanup

2014-04-17 Thread Alex Elder
This series cleans up a number of things in the code that issues
secure monitor ("smc") requests for the bcm281xx and bcm21664 SoC
families.  This code is currently used only for enabling the level-2
cache.

There are some bug fixes and other improvements.  An assembly
language file containing a single function has been eliminated by
re-implementing the code using inline assembly.  Some comments have
been expanded and clarified.  Kernel configuration options allow
finer-grained control over how this code gets built.  Finally, the
"kona.c" and "kona.h" files are renamed to reflect the fact that
only contain code related to level-2 cache support.

This series is based on v3.15-rc1, and depends on one patch posted
previously:
[PATCH v4] mach-bcm: clean up config and build targets
https://lkml.org/lkml/2014/4/15/303

It is available here:
http://git.linaro.org/landing-teams/working/broadcom/kernel.git
Branch review/bcm-smc-cleanup

-Alex

Alex Elder (10):
  ARM: bcm: use memory accessors for ioremapped area
  ARM: bcm: err, don't BUG() on SMC init failures
  ARM: bcm: clean up SMC code
  ARM: bcm: have bcm_kona_smc() return request result
  ARM: bcm: don't special-case CPU 0 in bcm_kona_smc()
  ARM: bcm: config option for l2 cache support
  ARM: bcm: tidy up a few includes
  ARM: bcm: use inline assembly for "smc" request
  ARM: bcm: rewrite commentary for bcm_kona_do_smc()
  ARM: bcm: rename "kona.h" and "kona.c"

 arch/arm/mach-bcm/Kconfig |   12 ++-
 arch/arm/mach-bcm/Makefile|   10 +-
 arch/arm/mach-bcm/bcm_kona_smc.c  |  136 ++---
 arch/arm/mach-bcm/bcm_kona_smc.h  |   52 +-
 arch/arm/mach-bcm/bcm_kona_smc_asm.S  |   41 
 arch/arm/mach-bcm/board_bcm21664.c|5 +-
 arch/arm/mach-bcm/board_bcm281xx.c|2 +-
 arch/arm/mach-bcm/{kona.c => kona_l2_cache.c} |   16 +--
 arch/arm/mach-bcm/{kona.h => kona_l2_cache.h} |6 ++
 9 files changed, 137 insertions(+), 143 deletions(-)
 delete mode 100644 arch/arm/mach-bcm/bcm_kona_smc_asm.S
 rename arch/arm/mach-bcm/{kona.c => kona_l2_cache.c} (80%)
 rename arch/arm/mach-bcm/{kona.h => kona_l2_cache.h} (82%)

-- 
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 10/10] ARM: bcm: rename "kona.h" and "kona.c"

2014-04-17 Thread Alex Elder
These source files contain only level-2 cache initialization code,
so rename them to make that fact more obvious.

Signed-off-by: Alex Elder 
Reviewed-by: Tim Kryger 
Reviewed-by: Markus Mayer 
Reviewed-by: Matt Porter 
---
 arch/arm/mach-bcm/Makefile|2 +-
 arch/arm/mach-bcm/board_bcm21664.c|2 +-
 arch/arm/mach-bcm/board_bcm281xx.c|2 +-
 arch/arm/mach-bcm/{kona.c => kona_l2_cache.c} |0
 arch/arm/mach-bcm/{kona.h => kona_l2_cache.h} |0
 5 files changed, 3 insertions(+), 3 deletions(-)
 rename arch/arm/mach-bcm/{kona.c => kona_l2_cache.c} (100%)
 rename arch/arm/mach-bcm/{kona.h => kona_l2_cache.h} (100%)

diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index d5b60fe..7312921 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -17,7 +17,7 @@ obj-$(CONFIG_ARCH_BCM_281XX)  += board_bcm281xx.o
 obj-$(CONFIG_ARCH_BCM_21664)   += board_bcm21664.o
 
 # BCM281XX and BCM21664 L2 cache control
-obj-$(CONFIG_ARCH_BCM_MOBILE_L2_CACHE) += kona.o
+obj-$(CONFIG_ARCH_BCM_MOBILE_L2_CACHE) += kona_l2_cache.o
 
 # Support for secure monitor traps
 obj-$(CONFIG_ARCH_BCM_MOBILE_SMC) += bcm_kona_smc.o
diff --git a/arch/arm/mach-bcm/board_bcm21664.c 
b/arch/arm/mach-bcm/board_bcm21664.c
index ab96c3f..62c036b 100644
--- a/arch/arm/mach-bcm/board_bcm21664.c
+++ b/arch/arm/mach-bcm/board_bcm21664.c
@@ -17,7 +17,7 @@
 #include 
 #include 
 
-#include "kona.h"
+#include "kona_l2_cache.h"
 
 #define RSTMGR_DT_STRING   "brcm,bcm21664-resetmgr"
 
diff --git a/arch/arm/mach-bcm/board_bcm281xx.c 
b/arch/arm/mach-bcm/board_bcm281xx.c
index 6be54c1..1ac59fc 100644
--- a/arch/arm/mach-bcm/board_bcm281xx.c
+++ b/arch/arm/mach-bcm/board_bcm281xx.c
@@ -17,7 +17,7 @@
 
 #include 
 
-#include "kona.h"
+#include "kona_l2_cache.h"
 
 #define SECWDOG_OFFSET 0x
 #define SECWDOG_RESERVED_MASK  0xe200
diff --git a/arch/arm/mach-bcm/kona.c b/arch/arm/mach-bcm/kona_l2_cache.c
similarity index 100%
rename from arch/arm/mach-bcm/kona.c
rename to arch/arm/mach-bcm/kona_l2_cache.c
diff --git a/arch/arm/mach-bcm/kona.h b/arch/arm/mach-bcm/kona_l2_cache.h
similarity index 100%
rename from arch/arm/mach-bcm/kona.h
rename to arch/arm/mach-bcm/kona_l2_cache.h
-- 
1.7.9.5

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


[PATCH 1/2] cpufreq: exynos: Use dev_err/info function instead of pr_err/info

2014-04-17 Thread Chanwoo Choi
This patch uses dev_err/info function to show accurate log message with device 
name
instead of pr_err/info function.

Signed-off-by: Chanwoo Choi 
Acked-by: Kyungmin Park 
---
 drivers/cpufreq/exynos-cpufreq.c | 21 -
 drivers/cpufreq/exynos-cpufreq.h |  1 +
 2 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index f99cfe2..8b4bb4a 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -49,6 +49,7 @@ static int exynos_cpufreq_scale(unsigned int target_freq)
struct cpufreq_policy *policy = cpufreq_cpu_get(0);
unsigned int arm_volt, safe_arm_volt = 0;
unsigned int mpll_freq_khz = exynos_info->mpll_freq_khz;
+   struct device *dev = exynos_info->dev;
unsigned int old_freq;
int index, old_index;
int ret = 0;
@@ -90,8 +91,8 @@ static int exynos_cpufreq_scale(unsigned int target_freq)
/* Firstly, voltage up to increase frequency */
ret = regulator_set_voltage(arm_regulator, arm_volt, arm_volt);
if (ret) {
-   pr_err("%s: failed to set cpu voltage to %d\n",
-   __func__, arm_volt);
+   dev_err(dev, "failed to set cpu voltage to %d\n",
+   arm_volt);
return ret;
}
}
@@ -100,8 +101,8 @@ static int exynos_cpufreq_scale(unsigned int target_freq)
ret = regulator_set_voltage(arm_regulator, safe_arm_volt,
  safe_arm_volt);
if (ret) {
-   pr_err("%s: failed to set cpu voltage to %d\n",
-   __func__, safe_arm_volt);
+   dev_err(dev, "failed to set cpu voltage to %d\n",
+   safe_arm_volt);
return ret;
}
}
@@ -115,8 +116,8 @@ static int exynos_cpufreq_scale(unsigned int target_freq)
ret = regulator_set_voltage(arm_regulator, arm_volt,
arm_volt);
if (ret) {
-   pr_err("%s: failed to set cpu voltage to %d\n",
-   __func__, arm_volt);
+   dev_err(dev, "failed to set cpu voltage to %d\n",
+   arm_volt);
goto out;
}
}
@@ -163,6 +164,8 @@ static int exynos_cpufreq_probe(struct platform_device 
*pdev)
if (!exynos_info)
return -ENOMEM;
 
+   exynos_info->dev = >dev;
+
if (soc_is_exynos4210())
ret = exynos4210_cpufreq_init(exynos_info);
else if (soc_is_exynos4212() || soc_is_exynos4412())
@@ -176,13 +179,13 @@ static int exynos_cpufreq_probe(struct platform_device 
*pdev)
goto err_vdd_arm;
 
if (exynos_info->set_freq == NULL) {
-   pr_err("%s: No set_freq function (ERR)\n", __func__);
+   dev_err(>dev, "No set_freq function (ERR)\n");
goto err_vdd_arm;
}
 
arm_regulator = regulator_get(NULL, "vdd_arm");
if (IS_ERR(arm_regulator)) {
-   pr_err("%s: failed to get resource vdd_arm\n", __func__);
+   dev_err(>dev, "failed to get resource vdd_arm\n");
goto err_vdd_arm;
}
 
@@ -192,7 +195,7 @@ static int exynos_cpufreq_probe(struct platform_device 
*pdev)
if (!cpufreq_register_driver(_driver))
return 0;
 
-   pr_err("%s: failed to register cpufreq driver\n", __func__);
+   dev_err(>dev, "failed to register cpufreq driver\n");
regulator_put(arm_regulator);
 err_vdd_arm:
kfree(exynos_info);
diff --git a/drivers/cpufreq/exynos-cpufreq.h b/drivers/cpufreq/exynos-cpufreq.h
index 3ddade8..b72ff10 100644
--- a/drivers/cpufreq/exynos-cpufreq.h
+++ b/drivers/cpufreq/exynos-cpufreq.h
@@ -34,6 +34,7 @@ struct apll_freq {
 };
 
 struct exynos_dvfs_info {
+   struct device   *dev;
unsigned long   mpll_freq_khz;
unsigned intpll_safe_idx;
struct clk  *cpu_clk;
-- 
1.8.0

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


[PATCH 2/2] cpufreq: exynos: Add new Exynos3250 cpufreq driver

2014-04-17 Thread Chanwoo Choi
This patch add new Exynos3250 cpufreq driver to support DVFS (Dynamic Voltage
Frequency Scaling). Exynos3250 uses the Cortex-A7 dual cores and has a target
speed of 1.0 GHz. Exynos3250 cpufreq driver has range from 100MHz to 1000MHz.

Signed-off-by: Chanwoo Choi 
Acked-by: Kyungmin Park 
---
 drivers/cpufreq/Kconfig.arm  |  11 +++
 drivers/cpufreq/Makefile |   1 +
 drivers/cpufreq/exynos-cpufreq.c |   4 +-
 drivers/cpufreq/exynos-cpufreq.h |  17 
 drivers/cpufreq/exynos3250-cpufreq.c | 158 +++
 5 files changed, 190 insertions(+), 1 deletion(-)
 create mode 100644 drivers/cpufreq/exynos3250-cpufreq.c

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 0e9cce8..8af1bd1 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -28,6 +28,17 @@ config ARM_VEXPRESS_SPC_CPUFREQ
 config ARM_EXYNOS_CPUFREQ
bool
 
+config ARM_EXYNOS3250_CPUFREQ
+   bool "SAMSUNG EXYNOS3250"
+   depends on SOC_EXYNOS3250 && !ARCH_MULTIPLATFORM
+   default y
+   select ARM_EXYNOS_CPUFREQ
+   help
+ This adds the CPUFreq driver for Samsung EXYNOS3250 SoC based on
+ Cortex-A7 dual-core.
+
+ If in doubt, say N.
+
 config ARM_EXYNOS4210_CPUFREQ
bool "SAMSUNG EXYNOS4210"
depends on CPU_EXYNOS4210 && !ARCH_MULTIPLATFORM
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 0dbb963..18260bb 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_ARM_DT_BL_CPUFREQ)   += 
arm_big_little_dt.o
 obj-$(CONFIG_ARCH_DAVINCI_DA850)   += davinci-cpufreq.o
 obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS_CPUFREQ)   += exynos-cpufreq.o
+obj-$(CONFIG_ARM_EXYNOS3250_CPUFREQ)   += exynos3250-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)   += exynos4210-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ)   += exynos4x12-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ)   += exynos5250-cpufreq.o
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index 8b4bb4a..e72cc60 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -166,7 +166,9 @@ static int exynos_cpufreq_probe(struct platform_device 
*pdev)
 
exynos_info->dev = >dev;
 
-   if (soc_is_exynos4210())
+   if (soc_is_exynos3250())
+   ret = exynos3250_cpufreq_init(exynos_info);
+   else if (soc_is_exynos4210())
ret = exynos4210_cpufreq_init(exynos_info);
else if (soc_is_exynos4212() || soc_is_exynos4412())
ret = exynos4x12_cpufreq_init(exynos_info);
diff --git a/drivers/cpufreq/exynos-cpufreq.h b/drivers/cpufreq/exynos-cpufreq.h
index b72ff10..9c5e491 100644
--- a/drivers/cpufreq/exynos-cpufreq.h
+++ b/drivers/cpufreq/exynos-cpufreq.h
@@ -26,6 +26,15 @@ enum cpufreq_level_index {
.mps = ((m) << 16 | (p) << 8 | (s)), \
}
 
+#define APLL_FREQ_EXYNOS3(f, a0, a1, a2, a3, a4, a5, b0, b1, b2, m, p, s) \
+   { \
+   .freq = (f) * 1000, \
+   .clk_div_cpu0 = ((a0) | (a1) << 4 |  (a2) << 16 | (a3) << 20 | \
+   (a4) << 24 | (a5) << 28), \
+   .clk_div_cpu1 = (b0 << 0 | b1 << 4 | b2 << 8), \
+   .mps = ((m) << 16 | (p) << 8 | (s)), \
+   }
+
 struct apll_freq {
unsigned int freq;
u32 clk_div_cpu0;
@@ -44,6 +53,14 @@ struct exynos_dvfs_info {
bool (*need_apll_change)(unsigned int, unsigned int);
 };
 
+#ifdef CONFIG_ARM_EXYNOS3250_CPUFREQ
+extern int exynos3250_cpufreq_init(struct exynos_dvfs_info *);
+#else
+static inline int exynos3250_cpufreq_init(struct exynos_dvfs_info *info)
+{
+   return -EOPNOTSUPP;
+}
+#endif
 #ifdef CONFIG_ARM_EXYNOS4210_CPUFREQ
 extern int exynos4210_cpufreq_init(struct exynos_dvfs_info *);
 #else
diff --git a/drivers/cpufreq/exynos3250-cpufreq.c 
b/drivers/cpufreq/exynos3250-cpufreq.c
new file mode 100644
index 000..71f72b8
--- /dev/null
+++ b/drivers/cpufreq/exynos3250-cpufreq.c
@@ -0,0 +1,158 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * EXYNOS3250 - CPU frequency scaling support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "exynos-cpufreq.h"
+
+static struct clk *cpu_clk;
+static struct clk *mout_core;
+static struct clk *mout_mpll;
+static struct clk *mout_apll;
+
+static unsigned int exynos3250_volt_table[] = {
+   105, 105, 100, 95, 90,
+   90,   90,  90, 90, 90,
+};
+
+static struct cpufreq_frequency_table exynos3250_freq_table[] = {
+   {0, L0, 1000 * 1000},
+   

[PATCH 0/2] Support cpufreq driver for Exynos3250

2014-04-17 Thread Chanwoo Choi
This patchset support cpufreq driver for Exynos3250 which uses the Cortex-A7
dual cores and has a target speed of 1.0 GHz and code clean using dev_err/info
instead of pr_err/info function.

This patchset has a dependency on following patchset[1] to support Exynos3250:
[1] https://lkml.org/lkml/2014/4/17/669

Chanwoo Choi (2):
  cpufreq: exynos: Use dev_err/info function instead of pr_err/info
  cpufreq: exynos: Add new Exynos3250 cpufreq driver

 drivers/cpufreq/Kconfig.arm  |  11 +++
 drivers/cpufreq/Makefile |   1 +
 drivers/cpufreq/exynos-cpufreq.c |  25 +++---
 drivers/cpufreq/exynos-cpufreq.h |  18 
 drivers/cpufreq/exynos3250-cpufreq.c | 158 +++
 5 files changed, 203 insertions(+), 10 deletions(-)
 create mode 100644 drivers/cpufreq/exynos3250-cpufreq.c

-- 
1.8.0

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


Re: [f2fs-dev] [PATCH] f2fs: fix to enable readahead last NAT block

2014-04-17 Thread Jaegeuk Kim
Hi Chao,

How about this?

---
 fs/f2fs/f2fs.h | 1 +
 fs/f2fs/node.c | 6 --
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 55152de..556d06b 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -244,6 +244,7 @@ static inline void set_raw_extent(struct extent_info
*ext,
 struct f2fs_nm_info {
block_t nat_blkaddr;/* base disk address of NAT */
nid_t max_nid;  /* maximum possible node ids */
+   nid_t available_nids;   /* maximum available node ids */
nid_t next_scan_nid;/* the next nid to be scanned */
unsigned int ram_thresh;/* control the memory footprint */
 
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 837f5fd..5fb484c 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1447,7 +1447,7 @@ bool alloc_nid(struct f2fs_sb_info *sbi, nid_t
*nid)
struct f2fs_nm_info *nm_i = NM_I(sbi);
struct free_nid *i = NULL;
 retry:
-   if (unlikely(sbi->total_valid_node_count + 1 >= nm_i->max_nid))
+   if (unlikely(sbi->total_valid_node_count + 1 >= nm_i->available_nids))
return false;
 
spin_lock(_i->free_nid_list_lock);
@@ -1859,8 +1859,10 @@ static int init_node_manager(struct f2fs_sb_info
*sbi)
nat_segs = le32_to_cpu(sb_raw->segment_count_nat) >> 1;
nat_blocks = nat_segs << le32_to_cpu(sb_raw->log_blocks_per_seg);
 
+   nm_i->max_nid = NAT_ENTRY_PER_BLOCK * nat_blocks;
+
/* not used nids: 0, node, meta, (and root counted as valid node) */
-   nm_i->max_nid = NAT_ENTRY_PER_BLOCK * nat_blocks - 3;
+   nm_i->available_nids = nm_i->max_nid - 3;
nm_i->fcnt = 0;
nm_i->nat_cnt = 0;
nm_i->ram_thresh = DEF_RAM_THRESHOLD;
-- 
1.8.4.474.g128a96c


-- 
Jaegeuk Kim
Samsung

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


[ANNOUNCE] backports-3.15-rc1 is released

2014-04-17 Thread Luis R. Rodriguez
Linux backports [0] backports-v3.15-rc1 is out [1]. Please
go test and see if you can and break things or if see if
we've broken anything so far before a final release in
sync with Linus' releases. As usual development only happens
on the master branch, we'll then carry fixes onto the stable
branch. It just so happens that today's master branch is
exactly as we have it on the linux-3.15.y branch.

[0] https://backports.wiki.kernel.org/
[1] 
https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.15-rc1/backports-3.15-rc1-1.tar.xz

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


[ANNOUNCE] backports-3.14-1 released

2014-04-17 Thread Luis R. Rodriguez
Linux backports [0] backports-v3.14-1 is out [1]. Thanks for Hauke
for taking the torch while I was in limbo. The release obviously
has all the things that upstream has so there's no point in mentioning
any of that, but new drivers are igb, added by Stefan. This release
also has a new backports-update-manager under devel/ which will do
what you expect -- download any new kernels / keep trees in sycn and
remove any stale once we stop supporting them. One of the biggest changes
here is also the more extensive use of Coccinelle SmPL grammar [2] to
help further with automatic backports. I've written a piece of great
lengh to get people excited about the potential here. Hopefully, more
than anything, you'll just see by example how we do things better with
SmPL.

[0] https://backports.wiki.kernel.org/
[1] 
http://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.14/backports-3.14-1.tar.xz
[2] http://coccinelle.lip6.fr/
[3] 
http://www.do-not-panic.com/2014/04/automatic-linux-kernel-backporting-with-coccinelle.html

Eliad Peller (1):
  backports: ifdef some pci functions

Emmanuel Grumbach (2):
  backports: add support for prandom_bytes
  backports: fix iwlwifi threaded IRQ patches

Hauke Mehrtens (98):
  backports: remove mdio driver code
  backports: remove eeprom_93cx6.h header
  backports: remove acpi_video_register_with_quirks()
  backports: remove atomic_inc_not_zero_hint()
  backports: remove irq_set_affinity_hint()
  backports: remove efi
  backports: remove ethtool_rxfh_indir_default()
  backports: remove fb_enable_skip_vt_switch()
  backports: remove vlan_hw_offload_capable()
  backports: remove hex_byte_pack()
  backports: remove kref_get_unless_zero()
  backports: remove usb_unlink_anchored_urbs()
  backports: remove backport/backport-include/linux/vgaarb.h
  backports: remove own version of include/linux/wireless.h
  backports: remove own version of include/linux/unaligned/*.h
  backports: check for define in module_driver and not kernel version
  backports: add backport_ prefix in front of BQL functions
  backports: remove duplicate allyesconfig from help
  backports: add backport_ in front of sign_extend32()
  backports: refresh patches on next-20131129
  backports: remove DMI_EXACT_MATCH
  backports: add missing include for linux/of.h
  backports: add LINUX_BACKPORT infront of functions
  backports: remove unused workqueue backports
  backports: so not add netdev_features_t on RHEL 6.5
  backports: add missing LINUX_BACKPORT() on various places
  backports: fix skb_add_rx_fragi() for SLES 11 SP3
  backports: do not call dev_hw_addr_random()
  backports: add devm_kmalloc()
  backports: add netdev_notify_peers()
  backports: add ARPHRD_6LOWPAN
  backports: add include/trace/events/v4l2.h file
  backports: fix number of arguments of phy_connect()
  backports: make b44 depend on kernel > 2.6.28
  backports: remove usage of members of struct property for kernel < 2.6.39
  backports: add include/net/af_ieee802154.h file
  backports: remove usage of addr_assign_type in 6lowpan.c
  backports: remove CRC8 backport
  backports: add printk_ratelimited()
  backports: build some regulator drivers only with recent kernels
  backports: copy include/uapi/linux/vsp1.h
  backports: fix i2c_add_mux_adapter() parameters
  backports: update kernel versions
  backports: refresh on next-20131224
  backports: add prefix infront of led_blink_set()
  backports: add missing include
  gentree: create *.tar.gz instead of *.tar.bz for kernel.org
  backports: add ether_addr_equal_64bits()
  backports: add ether_addr_equal_unaligned()
  backports: do not build ACT8865 with kernel < 3.12
  backports: add missing header file
  backports: refresh on next-20140106
  backports: adapt to changes in netdev select_queue call
  backports: add USB_DEVICE_INTERFACE_CLASS
  backports: do not activate BCMA_HOST_SOC on kernel < 3.7
  backports: add sdio device id list
  backports: add ATTRIBUTE_GROUPS unconditionally
  backports: add linux/irqdomain.h
  backports: fix header of phy_mii_ioctl()
  backports: backport get_stats in alx driver
  backports: add IS_BUILTIN()
  backports: add prefix infront of ether_addr_equal_{unaligned, 64bits}()
  backports: fix led_trigger warning with old kernel versions
  backports: fix unused mwifiex_sdio_resume() warning
  backports: fix unused var ret warning
  backports: fix unused atl1e_rx_mode() warning
  backports: fix unused hidp_get_raw_report() warning
  backports: refresh on next-20140117
  backports: add DECLARE_SOCKADDR
  backports: add __sockaddr_check_size()
  backports: always access net/ieee802154/ with make
  backports: refresh on next-20140124
  backports: fix uninstall filename

Re: [PATCH V2] fs/f2fs/node.c: add static to recover_inline_xattr

2014-04-17 Thread Jaegeuk Kim
Hi,

This was already resolved by Jingoo Han.
Thanks,

2014-04-17 (목), 18:01 +0200, Fabian Frederick:
> recover_inline_xattr is only used in node.c
> 
> Cc: Jaegeuk Kim 
> Cc: Andrew Morton 
> Signed-off-by: Fabian Frederick 
> ---
>  fs/f2fs/node.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> index a161e95..3ce4beb 100644
> --- a/fs/f2fs/node.c
> +++ b/fs/f2fs/node.c
> @@ -1534,7 +1534,7 @@ void recover_node_page(struct f2fs_sb_info *sbi, struct 
> page *page,
>   clear_node_page_dirty(page);
>  }
>  
> -void recover_inline_xattr(struct inode *inode, struct page *page)
> +static void recover_inline_xattr(struct inode *inode, struct page *page)
>  {
>   struct f2fs_sb_info *sbi = F2FS_SB(inode->i_sb);
>   void *src_addr, *dst_addr;

-- 
Jaegeuk Kim
Samsung

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] ACPICA: Tables: Skip NULL entries in RSDT and XSDT.

2014-04-17 Thread Zheng, Lv
Hi, Stable reviewers

This patch is not included in any upstream kernel, so it might not follow the 
stable rule.
If you think you need more information, please ignore this message.
This urgent fix is sent here for people who are monitoring stable and seeking 
for this fix.

Thanks and best regards
-Lv

> From: Zheng, Lv
> Sent: Friday, April 18, 2014 9:53 AM
> 
> Note that this patch is only used for stable kernels, upstream kernels
> will have this problem fixed in ACPICA 201303-04 release.  So upstream
> kernels shouldn't merge this commit.
> 
> It is reported that there are buggy BIOSes in the world: AMI uses a XSDt
> compiler for early BIOSes, this compiler will generate XSDT with a NULL
> entry.  The affected BIOS versions are "AMI BIOS F2-F4".
> 
> Original solution on Linux is to use an alternative heathy root table
> instead of the ill one.  This commit is refined by the following ACPICA
> commit that tries to reduce the source code differences between Linux and
> ACPICA upstream.
>   Commit: 671cc68dc61f029d44b43a681356078e02d8dab8
>   Subject: ACPICA: Back port and refine validation of the XSDT root table.
> But according to the bug report, the XSDT in fact is not broken, we should
> just add NULL entry sanity check before installing a table address from
> XSDT.
> 
> With the NULL entry sanity check implemented, the XSDT validation is
> useless because:
> 1. If XSDT contains NULL entries, it can be bypassed by the new sanity
>check mechanism;
> 2. If RSDP contains a bad XSDT address, invoking XSDT validation will still
>lead to kernel crash.
> 
> This patch deletes XSDT validation logics and adds code to skip NULL
> entries that can be found in RSDT or XSDT. Lv Zheng.
> 
> Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=73911
> Buglink: https://bugs.archlinux.org/task/39811
> Signed-off-by: Lv Zheng 
> Reported-and-tested-by: Bruce Chiarelli 
> Reported-and-tested-by: Spyros Stathopoulos 
> Cc: Zhao Yakui 
> Cc:  # 3.14.x: 671cc68: ACPICA: Back port and refine 
> validation of the XSDT root table.
> ---
>  drivers/acpi/acpica/tbutils.c |  116 
> -
>  1 file changed, 11 insertions(+), 105 deletions(-)
> 
> diff --git a/drivers/acpi/acpica/tbutils.c b/drivers/acpi/acpica/tbutils.c
> index 6412d3c..aaea4e2 100644
> --- a/drivers/acpi/acpica/tbutils.c
> +++ b/drivers/acpi/acpica/tbutils.c
> @@ -49,8 +49,6 @@
>  ACPI_MODULE_NAME("tbutils")
> 
>  /* Local prototypes */
> -static acpi_status acpi_tb_validate_xsdt(acpi_physical_address address);
> -
>  static acpi_physical_address
>  acpi_tb_get_root_table_entry(u8 *table_entry, u32 table_entry_size);
> 
> @@ -357,87 +355,6 @@ acpi_tb_get_root_table_entry(u8 *table_entry, u32 
> table_entry_size)
> 
>  
> /***
>   *
> - * FUNCTION:acpi_tb_validate_xsdt
> - *
> - * PARAMETERS:  address - Physical address of the XSDT (from 
> RSDP)
> - *
> - * RETURN:  Status. AE_OK if the table appears to be valid.
> - *
> - * DESCRIPTION: Validate an XSDT to ensure that it is of minimum size and 
> does
> - *  not contain any NULL entries. A problem that is seen in the
> - *  field is that the XSDT exists, but is actually useless 
> because
> - *  of one or more (or all) NULL entries.
> - *
> - 
> **/
> -
> -static acpi_status acpi_tb_validate_xsdt(acpi_physical_address xsdt_address)
> -{
> - struct acpi_table_header *table;
> - u8 *next_entry;
> - acpi_physical_address address;
> - u32 length;
> - u32 entry_count;
> - acpi_status status;
> - u32 i;
> -
> - /* Get the XSDT length */
> -
> - table =
> - acpi_os_map_memory(xsdt_address, sizeof(struct acpi_table_header));
> - if (!table) {
> - return (AE_NO_MEMORY);
> - }
> -
> - length = table->length;
> - acpi_os_unmap_memory(table, sizeof(struct acpi_table_header));
> -
> - /*
> -  * Minimum XSDT length is the size of the standard ACPI header
> -  * plus one physical address entry
> -  */
> - if (length < (sizeof(struct acpi_table_header) + ACPI_XSDT_ENTRY_SIZE)) 
> {
> - return (AE_INVALID_TABLE_LENGTH);
> - }
> -
> - /* Map the entire XSDT */
> -
> - table = acpi_os_map_memory(xsdt_address, length);
> - if (!table) {
> - return (AE_NO_MEMORY);
> - }
> -
> - /* Get the number of entries and pointer to first entry */
> -
> - status = AE_OK;
> - next_entry = ACPI_ADD_PTR(u8, table, sizeof(struct acpi_table_header));
> - entry_count = (u32)((table->length - sizeof(struct acpi_table_header)) /
> - ACPI_XSDT_ENTRY_SIZE);
> -
> - /* Validate each entry (physical address) within the XSDT */
> -
> - for (i = 0; i < entry_count; i++) {
> - address =
> - 

[PATCH] ACPICA: Tables: Skip NULL entries in RSDT and XSDT.

2014-04-17 Thread Lv Zheng
Note that this patch is only used for stable kernels, upstream kernels
will have this problem fixed in ACPICA 201303-04 release.  So upstream
kernels shouldn't merge this commit.

It is reported that there are buggy BIOSes in the world: AMI uses a XSDt
compiler for early BIOSes, this compiler will generate XSDT with a NULL
entry.  The affected BIOS versions are "AMI BIOS F2-F4".

Original solution on Linux is to use an alternative heathy root table
instead of the ill one.  This commit is refined by the following ACPICA
commit that tries to reduce the source code differences between Linux and
ACPICA upstream.
  Commit: 671cc68dc61f029d44b43a681356078e02d8dab8
  Subject: ACPICA: Back port and refine validation of the XSDT root table.
But according to the bug report, the XSDT in fact is not broken, we should
just add NULL entry sanity check before installing a table address from
XSDT.

With the NULL entry sanity check implemented, the XSDT validation is
useless because:
1. If XSDT contains NULL entries, it can be bypassed by the new sanity
   check mechanism;
2. If RSDP contains a bad XSDT address, invoking XSDT validation will still
   lead to kernel crash.

This patch deletes XSDT validation logics and adds code to skip NULL
entries that can be found in RSDT or XSDT. Lv Zheng.

Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=73911
Buglink: https://bugs.archlinux.org/task/39811
Signed-off-by: Lv Zheng 
Reported-and-tested-by: Bruce Chiarelli 
Reported-and-tested-by: Spyros Stathopoulos 
Cc: Zhao Yakui 
Cc:  # 3.14.x: 671cc68: ACPICA: Back port and refine 
validation of the XSDT root table.
---
 drivers/acpi/acpica/tbutils.c |  116 -
 1 file changed, 11 insertions(+), 105 deletions(-)

diff --git a/drivers/acpi/acpica/tbutils.c b/drivers/acpi/acpica/tbutils.c
index 6412d3c..aaea4e2 100644
--- a/drivers/acpi/acpica/tbutils.c
+++ b/drivers/acpi/acpica/tbutils.c
@@ -49,8 +49,6 @@
 ACPI_MODULE_NAME("tbutils")
 
 /* Local prototypes */
-static acpi_status acpi_tb_validate_xsdt(acpi_physical_address address);
-
 static acpi_physical_address
 acpi_tb_get_root_table_entry(u8 *table_entry, u32 table_entry_size);
 
@@ -357,87 +355,6 @@ acpi_tb_get_root_table_entry(u8 *table_entry, u32 
table_entry_size)
 
 
/***
  *
- * FUNCTION:acpi_tb_validate_xsdt
- *
- * PARAMETERS:  address - Physical address of the XSDT (from RSDP)
- *
- * RETURN:  Status. AE_OK if the table appears to be valid.
- *
- * DESCRIPTION: Validate an XSDT to ensure that it is of minimum size and does
- *  not contain any NULL entries. A problem that is seen in the
- *  field is that the XSDT exists, but is actually useless because
- *  of one or more (or all) NULL entries.
- *
- 
**/
-
-static acpi_status acpi_tb_validate_xsdt(acpi_physical_address xsdt_address)
-{
-   struct acpi_table_header *table;
-   u8 *next_entry;
-   acpi_physical_address address;
-   u32 length;
-   u32 entry_count;
-   acpi_status status;
-   u32 i;
-
-   /* Get the XSDT length */
-
-   table =
-   acpi_os_map_memory(xsdt_address, sizeof(struct acpi_table_header));
-   if (!table) {
-   return (AE_NO_MEMORY);
-   }
-
-   length = table->length;
-   acpi_os_unmap_memory(table, sizeof(struct acpi_table_header));
-
-   /*
-* Minimum XSDT length is the size of the standard ACPI header
-* plus one physical address entry
-*/
-   if (length < (sizeof(struct acpi_table_header) + ACPI_XSDT_ENTRY_SIZE)) 
{
-   return (AE_INVALID_TABLE_LENGTH);
-   }
-
-   /* Map the entire XSDT */
-
-   table = acpi_os_map_memory(xsdt_address, length);
-   if (!table) {
-   return (AE_NO_MEMORY);
-   }
-
-   /* Get the number of entries and pointer to first entry */
-
-   status = AE_OK;
-   next_entry = ACPI_ADD_PTR(u8, table, sizeof(struct acpi_table_header));
-   entry_count = (u32)((table->length - sizeof(struct acpi_table_header)) /
-   ACPI_XSDT_ENTRY_SIZE);
-
-   /* Validate each entry (physical address) within the XSDT */
-
-   for (i = 0; i < entry_count; i++) {
-   address =
-   acpi_tb_get_root_table_entry(next_entry,
-ACPI_XSDT_ENTRY_SIZE);
-   if (!address) {
-
-   /* Detected a NULL entry, XSDT is invalid */
-
-   status = AE_NULL_ENTRY;
-   break;
-   }
-
-   next_entry += ACPI_XSDT_ENTRY_SIZE;
-   }
-
-   /* Unmap table */
-
-   acpi_os_unmap_memory(table, length);
-   return (status);
-}
-

3 linux-next based backports releases

2014-04-17 Thread Luis R. Rodriguez
3 new linux backports release are now available based on linux-next
tags next-20140320 [0] next-20140411 [1] and next-20140417 [2]. This
should mean that we can keep things in synch now almost daily, and
drivers can be tested with the latest code as-is on linux-next. We've
shaved off kernel support for kernels older than 3.0 in order to help
scale the project. We've also have added 2 new SmPL patches to help
backports backport two pain in the ass collateral evolutions
automatically. Please note that the patches/ directory is now all
tidied up -- folks interested in playing with SmPL can try to help by
seeing if they can use SmPL grammer to formalize a collateral
evolution backport. We have a bit of examples now. For more details
please refer to the wiki [3] or git tree.

[0] 
http://www.kernel.org/pub/linux/kernel/projects/backports/2014/03/20/backports-20140320.tar.xz
[1] 
https://www.kernel.org/pub/linux/kernel/projects/backports/2014/04/11/backports-20140411.tar.xz
[2] 
https://www.kernel.org/pub/linux/kernel/projects/backports/2014/04/17/backports-20140417.tar.xz
[3] http://backports.wiki.kernel.org

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 v9 00/19] qspinlock: a 4-byte queue spinlock with PV support

2014-04-17 Thread Waiman Long

On 04/17/2014 01:40 PM, Raghavendra K T wrote:

On 04/17/2014 10:53 PM, Konrad Rzeszutek Wilk wrote:

On Thu, Apr 17, 2014 at 11:03:52AM -0400, Waiman Long wrote:

v8->v9:
   - Integrate PeterZ's version of the queue spinlock patch with some
 modification:
 http://lkml.kernel.org/r/20140310154236.038181...@infradead.org
   - Break the more complex patches into smaller ones to ease review 
effort.

   - Fix a racing condition in the PV qspinlock code.


I am not seeing anything mentioning that the overcommit scenario
for KVM and Xen had been fixed. Or was the 'racing condition' said
issue?


Saw changes in patch 18 that fixes for kvm (19 for xen). 'll
test the series and confirm.



The main fix is by replacing some barrier() with smp_mb(). The 
additional changes in kvm and xen are not the main one.


-Longman

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 v9 00/19] qspinlock: a 4-byte queue spinlock with PV support

2014-04-17 Thread Waiman Long

On 04/17/2014 01:23 PM, Konrad Rzeszutek Wilk wrote:

On Thu, Apr 17, 2014 at 11:03:52AM -0400, Waiman Long wrote:

v8->v9:
   - Integrate PeterZ's version of the queue spinlock patch with some
 modification:
 http://lkml.kernel.org/r/20140310154236.038181...@infradead.org
   - Break the more complex patches into smaller ones to ease review effort.
   - Fix a racing condition in the PV qspinlock code.

I am not seeing anything mentioning that the overcommit scenario
for KVM and Xen had been fixed. Or was the 'racing condition' said
issue?

Thanks.


The hanging is caused by a racing condition which should be fixed in the 
v9 patch. Please let me know if you are still seeing it.


-Longman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 v9 06/19] qspinlock: prolong the stay in the pending bit path

2014-04-17 Thread Waiman Long

On 04/17/2014 12:36 PM, Peter Zijlstra wrote:

On Thu, Apr 17, 2014 at 11:03:58AM -0400, Waiman Long wrote:

There is a problem in the current trylock_pending() function.  When the
lock is free, but the pending bit holder hasn't grabbed the lock&
cleared the pending bit yet, the trylock_pending() function will fail.

I remember seeing some of this..


It can be seen that the queue spinlock is slower than the ticket
spinlock when there are 2 or 3 contending tasks. In all the other case,
the queue spinlock is either equal or faster than the ticket spinlock.

So with my code I get:

 qspinlock ticket

local:  2: 8741.853010 2: 8812.042460
remote: 2: 8549.731795 2: 8709.005695

And that is without this optimization.

Also note that I don't have this cmpxchg loop anymore.


It is a matter of timing. If the contending task enters the pending bit 
code path at the right time, it will be able to get pending bit and 
wait. If it enters at the wrong time, it will bail out and use the 
queuing code path. The patch is just to enlarge the timing windows so 
that it won't bail out so easily.


From my own testing, using xchg(), for example, will be a bit faster 
than cmpxchg(). The downside of that is that I can guarantee strict 
ordering between a pending bit waiter and a queue waiter. So I need to 
use cmpxchg to set the lock. This didn't slow thing down that much when 
I tested it on a Westmere-EX box, but I saw significant slowdown in 
IvyBridge-EX. That is why I trade the use of xchg() with cmpxchg() at 
the expense of a bit of slowdown in the pending bit code path.



  kernel/locking/qspinlock.c |   32 ++--
  1 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c
index 55601b4..497da24 100644
--- a/kernel/locking/qspinlock.c
+++ b/kernel/locking/qspinlock.c
@@ -216,6 +216,7 @@ xchg_tail(struct qspinlock *lock, u32 tail, u32 *pval)
  static inline int trylock_pending(struct qspinlock *lock, u32 *pval)
  {
u32 old, new, val = *pval;
+   int retry = 1;

/*
 * trylock || pending
@@ -225,11 +226,38 @@ static inline int trylock_pending(struct qspinlock *lock, 
u32 *pval)
 */
for (;;) {
/*
-* If we observe any contention; queue.
+* If we observe that the queue is not empty,
+* return and be queued.
 */
-   if (val&  ~_Q_LOCKED_MASK)
+   if (val&  _Q_TAIL_MASK)
return 0;

+   if ((val&  _Q_LOCKED_PENDING_MASK) ==
+   (_Q_LOCKED_VAL|_Q_PENDING_VAL)) {
+   /*
+* If both the lock and pending bits are set, we wait
+* a while to see if that either bit will be cleared.
+* If that is no change, we return and be queued.
+*/
+   if (!retry)
+   return 0;
+   retry--;
+   cpu_relax();
+   cpu_relax();
+   *pval = val = atomic_read(>val);
+   continue;

Since you gave up optimizing the _Q_PENDING_BITS != 8 case why bother
with this? The switch from _Q_PENDING_VAL to _Q_LOCKED_VAL is atomic by
virtue of your (endian challenged) clear_pending_set_locked().


The code is just to extend the timing window a bit more to include cases 
where the lock holder is about to release the lock. It applies to both 
cases. However, it is not strictly necessary and I can take it out.


BTW, I didn't test out your atomic_test_and_set() change. Did it provide 
a noticeable performance benefit when compared with cmpxchg()?



+   } else if ((val&  _Q_LOCKED_PENDING_MASK) == _Q_PENDING_VAL) {
+   /*
+* Pending bit is set, but not the lock bit.
+* Assuming that the pending bit holder is going to
+* set the lock bit and clear the pending bit soon,
+* it is better to wait than to exit at this point.
+*/
+   cpu_relax();
+   *pval = val = atomic_read(>val);
+   continue;
+   }
+
new = _Q_LOCKED_VAL;
if (val == new)
new |= _Q_PENDING_VAL;

Wouldn't something like:

while (atomic_read(>val) == _Q_PENDING_VAL)
cpu_relax();

before the cmpxchg loop have gotten you all this?


Yes, you are right. I don't need to do a bitwise AND with 
_Q_LOCKED_PENDING_MASK. I will try make the loop a bit simpler.




I just tried this on my code and I cannot see a difference.


Again, it is a matter of timing and it depends on the tests that we 
used. My test showed a difference, but not yours. Both can be 

[PATCH v2] coccinelle: add pycocci wrapper for multithreaded support

2014-04-17 Thread Luis R. Rodriguez
From: "Luis R. Rodriguez" 

This is a wrapper for folks which by work on git trees, specifically
the linux kernel with lots of files and with random task Cocci files.
The assumption is all you need is multithreaded support and currently only
a shell script is lying around, but that isn't easily extensible, nor
is it dynamic. This uses Python to add Coccinelle's mechanisms for
multithreaded support but also enables all sorts of defaults which
you'd expect to be enabled when using Coccinelle for Linux kernel
development.

The Linux kernel backports project makes use of this tool on a daily
basis and as such you can expect more tuning to it. All this is being
done as Coccinelle's multithreaded support is being revamped but
that will take a while so we want something easy to use that is
extensible in the meantime.

The purpose of putting this into Coccinelle is to make the tool generic
and usable outside of backports. If this tool gets merged into
Coccinelle we'll just drop this copy and help evolve it within
Coccinelle.

You just pass it a cocci file, a target dir, and that's it.

Cc: Johannes Berg 
Cc: backpo...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: co...@systeme.lip6.fr
Signed-off-by: Luis R. Rodriguez 
---

This v2 has taken quite a bit of consideration into some additional flags
to make default, in particular --coccigrep is now used which proved in
the general case to not require increasing the number of threads depending
on the type of Cocci patch you produce. This patch also now puts pycocci
under tool tools/ directory. If I get an ACK I can commit and push.

If you'd like to downlaod this tool I'll try to keep an updated version
here:

http://drvbp1.linux-foundation.org/~mcgrof/coccinelle/

Its also currently available under the backports project -- until and only
if Coccinelle does wish to carry this internally in its own repo / releases.

 tools/pycocci | 180 ++
 1 file changed, 180 insertions(+)
 create mode 100755 tools/pycocci

diff --git a/tools/pycocci b/tools/pycocci
new file mode 100755
index 000..fde8190
--- /dev/null
+++ b/tools/pycocci
@@ -0,0 +1,180 @@
+#!/usr/bin/env python
+#
+# Copyright (c) 2014 Luis R. Rodriguez  
+# Copyright (c) 2013 Johannes Berg 
+#
+# This file is released under the GPLv2.
+#
+# Python wrapper for Coccinelle for multithreaded support,
+# designed to be used for working on a git tree, and with sensible
+# defaults, specifically for kernel developers.
+
+from multiprocessing import Process, cpu_count, Queue
+import argparse, subprocess, os, sys
+import tempfile, shutil
+
+# simple tempdir wrapper object for 'with' statement
+#
+# Usage:
+# with tempdir.tempdir() as tmpdir:
+# os.chdir(tmpdir)
+# do something
+#
+class tempdir(object):
+def __init__(self, suffix='', prefix='', dir=None, nodelete=False):
+self.suffix = ''
+self.prefix = ''
+self.dir = dir
+self.nodelete = nodelete
+
+def __enter__(self):
+self._name = tempfile.mkdtemp(suffix=self.suffix,
+  prefix=self.prefix,
+  dir=self.dir)
+return self._name
+
+def __exit__(self, type, value, traceback):
+if self.nodelete:
+print('not deleting directory %s!' % self._name)
+else:
+shutil.rmtree(self._name)
+
+class CoccinelleError(Exception):
+pass
+class ExecutionError(CoccinelleError):
+def __init__(self, cmd, errcode):
+self.error_code = errcode
+print('Failed command:')
+print(' '.join(cmd))
+
+class ExecutionErrorThread(CoccinelleError):
+def __init__(self, errcode, fn, cocci_file, threads, t, logwrite, 
print_name):
+self.error_code = errcode
+logwrite("Failed to apply changes from %s" % print_name)
+
+logwrite("Specific log output from change that failed using %s" % 
print_name)
+tf = open(fn, 'r')
+for line in tf.read():
+logwrite('> %s' % line)
+tf.close()
+
+logwrite("Full log using %s" % print_name)
+for num in range(threads):
+fn = os.path.join(t, '.tmp_spatch_worker.' + str(num))
+if (not os.path.isfile(fn)):
+continue
+tf = open(fn, 'r')
+for line in tf.read():
+logwrite('> %s' % line)
+tf.close()
+os.unlink(fn)
+
+def spatch(cocci_file, outdir,
+   max_threads, thread_id, temp_dir, ret_q, extra_args=[]):
+cmd = ['spatch',
+'--sp-file', cocci_file,
+'--in-place',
+'--recursive-includes',
+'--relax-include-path',
+'--use-coccigrep',
+'--timeout', '120',
+'--dir', outdir ]
+
+if (max_threads > 1):
+cmd.extend(['-max', str(max_threads), '-index', str(thread_id)])
+
+cmd.extend(extra_args)
+
+fn = os.path.join(temp_dir, 

[PATCH v3] ipc,shm: disable shmmax and shmall by default

2014-04-17 Thread Davidlohr Bueso
The default size for shmmax is, and always has been, 32Mb.
Today, this value is rather small, making users have to
increase it via sysctl, which can cause unnecessary work and
userspace application workarounds. Ie:

http://rhaas.blogspot.com/2012/06/absurd-shared-memory-limits.html

Unix has historically required setting these limits for shared
memory, and Linux inherited such behavior. The consequence of this
is added complexity for users and administrators. One very common
example are Database setup/installation documents and scripts,
where users must manually calculate the values for these limits.
This also requires (some) knowledge of how the underlying memory
management works, thus causing, in many occasions, the limits to
just be flat out wrong. Disabling these limits sooner could have
saved companies a lot of time, headaches and money for support.
But it's never too late, simplify users life now.

Instead of choosing yet another arbitrary value, larger than 32Mb,
this patch disables the use of both shmmax and shmall by default,
allowing users to create segments of unlimited sizes. Users and
applications that already explicitly set these values through sysctl
are left untouched, and thus does not change any of the behavior.

So a value of 0 bytes or pages, for shmmax and shmall, respectively,
implies unlimited memory, as opposed to disabling sysv shared memory.
This is safe as 0 cannot possibly be used previously as SHMMIN is
hardcoded to 1 and cannot be modified. This change will of course
be reflected in shmctl(SHM_STAT) calls. Any application that does
preliminary checking of the size of shmmax, must also check for
shmmin, and therefore the kernel can safely make this change. It is
well stated that any sizes must be within both ranges.

Another advantage of setting these values to 0 is that we automatically
take care of any variable overflowing problems, where the limit can
accidentally become 0. Without this change, such situations are just
*broken*, where shmmax = 0 < shmmin = 1.

This change allows Linux to treat shm just as regular anonymous memory.
One important difference between them, though, is handling out-of-memory
conditions: as opposed to regular anon memory, the OOM killer will not
free the memory as it is shm, allowing users to potentially abuse this.
To overcome this situation, the shm_rmid_forced option must be enabled.

Signed-off-by: Davidlohr Bueso 
Acked-by: KAMEZAWA Hiroyuki 
Acked-by: KOSAKI Motohiro 
---
Changes from v2:
 - Improve changelog (per Andrew/Manfred).
 - Minor documentation updates (per Michael).

Changes from v1:
 - Respect SHMMIN even when shmmax is 0 (unlimited).
   This fixes the shmget02 test that broke in v1. (per Manfred).

 - Update changelog regarding OOM description (per Kosaki)

 include/linux/shm.h  | 3 ++-
 include/uapi/linux/shm.h | 8 
 ipc/shm.c| 6 --
 3 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/include/linux/shm.h b/include/linux/shm.h
index 1e2cd2e..34e6ba74 100644
--- a/include/linux/shm.h
+++ b/include/linux/shm.h
@@ -4,7 +4,8 @@
 #include 
 #include 
 
-#define SHMALL (SHMMAX/PAGE_SIZE*(SHMMNI/16)) /* max shm system wide (pages) */
+/* max shm system wide (pages), 0 being unlimited */
+#define SHMALL 0
 #include 
 struct shmid_kernel /* private to the kernel */
 {  
diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h
index 78b6941..d645c0c 100644
--- a/include/uapi/linux/shm.h
+++ b/include/uapi/linux/shm.h
@@ -9,14 +9,14 @@
 
 /*
  * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can
- * be increased by sysctl
+ * be modified by sysctl. By default, disable SHMMAX and SHMALL with
+ * 0 bytes, thus allowing processes to have unlimited shared memory.
  */
-
-#define SHMMAX 0x200/* max shared seg size (bytes) */
+#define SHMMAX 0/* max shared seg size (bytes) */
 #define SHMMIN 1/* min shared seg size (bytes) */
 #define SHMMNI 4096 /* max num of segs system wide */
 #ifndef __KERNEL__
-#define SHMALL (SHMMAX/getpagesize()*(SHMMNI/16))
+#define SHMALL 0
 #endif
 #define SHMSEG SHMMNI   /* max shared segs per process */
 
diff --git a/ipc/shm.c b/ipc/shm.c
index 7645961..8630561 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -490,10 +490,12 @@ static int newseg(struct ipc_namespace *ns, struct 
ipc_params *params)
int id;
vm_flags_t acctflag = 0;
 
-   if (size < SHMMIN || size > ns->shm_ctlmax)
+   if (size < SHMMIN ||
+   (ns->shm_ctlmax && size > ns->shm_ctlmax))
return -EINVAL;
 
-   if (ns->shm_tot + numpages > ns->shm_ctlall)
+   if (ns->shm_ctlall &&
+   ns->shm_tot + numpages > ns->shm_ctlall)
return -ENOSPC;
 
shp = ipc_rcu_alloc(sizeof(*shp));
-- 
1.8.1.4



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 

[PATCH 3/3] 6lowpan: include net/net_namespace.h on 6lowpan namepsace header

2014-04-17 Thread Luis R. Rodriguez
From: "Luis R. Rodriguez" 

Don't rely on driver files or other headers having this file included.

CC: Alexander Smirnov 
Cc: Dmitry Eremin-Solenikov 
Cc: linux-zigbee-de...@lists.sourceforge.net
Signed-off-by: Luis R. Rodriguez 
---
 include/net/6lowpan.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/net/6lowpan.h b/include/net/6lowpan.h
index f7d372b..79b530f 100644
--- a/include/net/6lowpan.h
+++ b/include/net/6lowpan.h
@@ -54,6 +54,7 @@
 #define __6LOWPAN_H__
 
 #include 
+#include 
 
 #define UIP_802154_SHORTADDR_LEN   2  /* compressed ipv6 address length */
 #define UIP_IPH_LEN40 /* ipv6 fixed header size */
-- 
1.9.1

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


[PATCH 2/3] 6lowpan: make lowpan_cb static

2014-04-17 Thread Luis R. Rodriguez
From: "Luis R. Rodriguez" 

CC: Alexander Smirnov 
Cc: Dmitry Eremin-Solenikov 
Cc: linux-zigbee-de...@lists.sourceforge.net
Signed-off-by: Luis R. Rodriguez 
---
 net/ieee802154/reassembly.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ieee802154/reassembly.c b/net/ieee802154/reassembly.c
index 132b65b..6f1428c 100644
--- a/net/ieee802154/reassembly.c
+++ b/net/ieee802154/reassembly.c
@@ -36,7 +36,7 @@ struct lowpan_frag_info {
u8 d_offset;
 };
 
-struct lowpan_frag_info *lowpan_cb(struct sk_buff *skb)
+static struct lowpan_frag_info *lowpan_cb(struct sk_buff *skb)
 {
return (struct lowpan_frag_info *)skb->cb;
 }
-- 
1.9.1

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


[PATCH 1/3] 6lowpan: add helper to get 6lowpan namespace

2014-04-17 Thread Luis R. Rodriguez
From: "Luis R. Rodriguez" 

This will simplify the new reassembly backport
with no code changes being required.

CC: Alexander Smirnov 
Cc: Dmitry Eremin-Solenikov 
Cc: linux-zigbee-de...@lists.sourceforge.net
Cc: David S. Miller" 
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez 
---
 include/net/net_namespace.h | 15 +++
 net/ieee802154/reassembly.c | 46 +
 2 files changed, 45 insertions(+), 16 deletions(-)

diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
index 5f9eb26..bc4118e 100644
--- a/include/net/net_namespace.h
+++ b/include/net/net_namespace.h
@@ -373,6 +373,21 @@ static inline void rt_genid_bump_ipv6(struct net *net)
 }
 #endif
 
+#if IS_ENABLED(CONFIG_IEEE802154_6LOWPAN)
+static inline struct netns_ieee802154_lowpan *
+net_ieee802154_lowpan(struct net *net)
+{
+   return >ieee802154_lowpan;
+}
+#else
+static inline struct netns_ieee802154_lowpan *
+net_ieee802154_lowpan(struct net *net)
+{
+   return NULL;
+}
+#endif
+
+
 /* For callers who don't really care about whether it's IPv4 or IPv6 */
 static inline void rt_genid_bump_all(struct net *net)
 {
diff --git a/net/ieee802154/reassembly.c b/net/ieee802154/reassembly.c
index ef2d543..132b65b 100644
--- a/net/ieee802154/reassembly.c
+++ b/net/ieee802154/reassembly.c
@@ -120,6 +120,8 @@ fq_find(struct net *net, const struct lowpan_frag_info 
*frag_info,
struct inet_frag_queue *q;
struct lowpan_create_arg arg;
unsigned int hash;
+   struct netns_ieee802154_lowpan *ieee802154_lowpan =
+   net_ieee802154_lowpan(net);
 
arg.tag = frag_info->d_tag;
arg.d_size = frag_info->d_size;
@@ -129,7 +131,7 @@ fq_find(struct net *net, const struct lowpan_frag_info 
*frag_info,
read_lock(_frags.lock);
hash = lowpan_hash_frag(frag_info->d_tag, frag_info->d_size, src, dst);
 
-   q = inet_frag_find(>ieee802154_lowpan.frags,
+   q = inet_frag_find(_lowpan->frags,
   _frags, , hash);
if (IS_ERR_OR_NULL(q)) {
inet_frag_maybe_warn_overflow(q, pr_fmt());
@@ -357,6 +359,8 @@ int lowpan_frag_rcv(struct sk_buff *skb, const u8 frag_type)
struct net *net = dev_net(skb->dev);
struct lowpan_frag_info *frag_info = lowpan_cb(skb);
struct ieee802154_addr source, dest;
+   struct netns_ieee802154_lowpan *ieee802154_lowpan =
+   net_ieee802154_lowpan(net);
int err;
 
source = mac_cb(skb)->source;
@@ -366,10 +370,10 @@ int lowpan_frag_rcv(struct sk_buff *skb, const u8 
frag_type)
if (err < 0)
goto err;
 
-   if (frag_info->d_size > net->ieee802154_lowpan.max_dsize)
+   if (frag_info->d_size > ieee802154_lowpan->max_dsize)
goto err;
 
-   inet_frag_evictor(>ieee802154_lowpan.frags, _frags, false);
+   inet_frag_evictor(_lowpan->frags, _frags, false);
 
fq = fq_find(net, frag_info, , );
if (fq != NULL) {
@@ -436,6 +440,8 @@ static int __net_init 
lowpan_frags_ns_sysctl_register(struct net *net)
 {
struct ctl_table *table;
struct ctl_table_header *hdr;
+   struct netns_ieee802154_lowpan *ieee802154_lowpan =
+   net_ieee802154_lowpan(net);
 
table = lowpan_frags_ns_ctl_table;
if (!net_eq(net, _net)) {
@@ -444,10 +450,10 @@ static int __net_init 
lowpan_frags_ns_sysctl_register(struct net *net)
if (table == NULL)
goto err_alloc;
 
-   table[0].data = >ieee802154_lowpan.frags.high_thresh;
-   table[1].data = >ieee802154_lowpan.frags.low_thresh;
-   table[2].data = >ieee802154_lowpan.frags.timeout;
-   table[3].data = >ieee802154_lowpan.max_dsize;
+   table[0].data = _lowpan->frags.high_thresh;
+   table[1].data = _lowpan->frags.low_thresh;
+   table[2].data = _lowpan->frags.timeout;
+   table[3].data = _lowpan->max_dsize;
 
/* Don't export sysctls to unprivileged users */
if (net->user_ns != _user_ns)
@@ -458,7 +464,7 @@ static int __net_init 
lowpan_frags_ns_sysctl_register(struct net *net)
if (hdr == NULL)
goto err_reg;
 
-   net->ieee802154_lowpan.sysctl.frags_hdr = hdr;
+   ieee802154_lowpan->sysctl.frags_hdr = hdr;
return 0;
 
 err_reg:
@@ -471,9 +477,11 @@ err_alloc:
 static void __net_exit lowpan_frags_ns_sysctl_unregister(struct net *net)
 {
struct ctl_table *table;
+   struct netns_ieee802154_lowpan *ieee802154_lowpan =
+   net_ieee802154_lowpan(net);
 
-   table = net->ieee802154_lowpan.sysctl.frags_hdr->ctl_table_arg;
-   unregister_net_sysctl_table(net->ieee802154_lowpan.sysctl.frags_hdr);
+   table = ieee802154_lowpan->sysctl.frags_hdr->ctl_table_arg;
+   

[PATCH 0/3] 6lowpan: few changes to help with backports

2014-04-17 Thread Luis R. Rodriguez
Here's a few changes that can help automate the backport of 6lowpan.
I've been carrying them around for a while, I think its best to just
merge these upstream as its nothing controversial.

Luis R. Rodriguez (3):
  6lowpan: add helper to get 6lowpan namespace
  6lowpan: make lowpan_cb static
  6lowpan: include net/net_namespace.h on 6lowpan namepsace header

 include/net/6lowpan.h   |  1 +
 include/net/net_namespace.h | 15 ++
 net/ieee802154/reassembly.c | 48 +
 3 files changed, 47 insertions(+), 17 deletions(-)

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


[PATCHv3 3/7] ARM: EXYNOS: Support secondary CPU boot of Exynos3250

2014-04-17 Thread Chanwoo Choi
This patch fix the offset of CPU boot address and don't need to send smc call
of SMC_CMD_CPU1BOOT command for secondary CPU boot because Exynos3250 removes
WFE in secure mode.

Signed-off-by: Chanwoo Choi 
Acked-by: Kyungmin Park 
---
 arch/arm/mach-exynos/firmware.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index aa01c42..386d01d 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -31,11 +31,17 @@ static int exynos_do_idle(void)
 static int exynos_cpu_boot(int cpu)
 {
/*
+* Exynos3250 doesn't need to send smc command for secondary CPU boot
+* because Exynos3250 removes WFE in secure mode.
+*/
+   if (soc_is_exynos3250())
+   return 0;
+   /*
 * The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
 * But, Exynos4212 has only one secondary CPU so second parameter
 * isn't used for informing secure firmware about CPU id.
 */
-   if (soc_is_exynos4212())
+   else if (soc_is_exynos4212())
cpu = 0;
 
exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
@@ -46,7 +52,7 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned long 
boot_addr)
 {
void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c;
 
-   if (!soc_is_exynos4212())
+   if (!soc_is_exynos4212() && !soc_is_exynos3250())
boot_reg += 4*cpu;
 
__raw_writel(boot_addr, boot_reg);
-- 
1.8.0

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


[PATCHv3 4/7] ARM: EXYNOS: Enter a15 lowpower mode for Exynos3250 based on Cortex-a7

2014-04-17 Thread Chanwoo Choi
This patch decide proper lowpower mode of either a15 or a9 according to own ID
from Main ID register.

Cc: Arnd Bergmann 
Cc: Marc Zynigier 
Signed-off-by: Chanwoo Choi 
Acked-by: Kyungmin Park 
---
 arch/arm/mach-exynos/hotplug.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 5eead53..acf3119 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -135,16 +135,21 @@ void __ref exynos_cpu_die(unsigned int cpu)
int primary_part = 0;
 
/*
-* we're ready for shutdown now, so do it.
-* Exynos4 is A9 based while Exynos5 is A15; check the CPU part
-* number by reading the Main ID register and then perform the
-* appropriate sequence for entering low power.
+* Prepare the CPU for shutting down. The required sequence of
+* operations depends on core type. CPUID part number can be used to
+* determine the right way.
 */
-   asm("mrc p15, 0, %0, c0, c0, 0" : "=r"(primary_part) : : "cc");
-   if ((primary_part & 0xfff0) == 0xc0f0)
+   primary_part = read_cpuid_part_number();
+
+   switch (primary_part) {
+   case ARM_CPU_PART_CORTEX_A7:
+   case ARM_CPU_PART_CORTEX_A15:
cpu_enter_lowpower_a15();
-   else
+   break;
+   default:
cpu_enter_lowpower_a9();
+   break;
+   }
 
platform_do_lowpower(cpu, );
 
-- 
1.8.0

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


[PATCHv3 6/7] dt-bindings: add documentation for Exynos3250 clock controller

2014-04-17 Thread Chanwoo Choi
The Exynos3250 clocks are statically listed and registered using the
Samsung specific common clock helper functions. Both device tree based
clock lookup and clkdev based clock lookups are supported.

Cc: Mike Turquette 
Cc: Kukjin Kim 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: Randy Dunlap 
Cc: Tomasz Figa 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Tomasz Figa 
Acked-by: Kyungmin Park 
---
 .../devicetree/bindings/clock/exynos3250-clock.txt | 41 ++
 1 file changed, 41 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/exynos3250-clock.txt

diff --git a/Documentation/devicetree/bindings/clock/exynos3250-clock.txt 
b/Documentation/devicetree/bindings/clock/exynos3250-clock.txt
new file mode 100644
index 000..aadc9c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/exynos3250-clock.txt
@@ -0,0 +1,41 @@
+* Samsung Exynos3250 Clock Controller
+
+The Exynos3250 clock controller generates and supplies clock to various
+controllers within the Exynos3250 SoC.
+
+Required Properties:
+
+- compatible: should be one of the following.
+  - "samsung,exynos3250-cmu" - controller compatible with Exynos3250 SoC.
+
+- reg: physical base address of the controller and length of memory mapped
+  region.
+
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/exynos3250.h header and can be used in device
+tree sources.
+
+Example 1: An example of a clock controller node is listed below.
+
+   cmu: clock-controller@1003 {
+   compatible = "samsung,exynos3250-cmu";
+   reg = <0x1003 0x2>;
+   #clock-cells = <1>;
+   };
+
+Example 2: UART controller node that consumes the clock generated by the clock
+  controller. Refer to the standard clock bindings for information
+  about 'clocks' and 'clock-names' property.
+
+   serial@1380 {
+   compatible = "samsung,exynos4210-uart";
+   reg = <0x1380 0x100>;
+   interrupts = <0 109 0>;
+   clocks = < CLK_UART0>, < CLK_SCLK_UART0>;
+   clock-names = "uart", "clk_uart_baud0";
+   };
-- 
1.8.0

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


[PATCHv3 2/7] ARM: EXYNOS: Support secondary CPU boot of Exynos4212

2014-04-17 Thread Chanwoo Choi
From: Kyungmin Park 

This patch fix the offset of CPU boot address and change parameter of smc call
of SMC_CMD_CPU1BOOT command for Exynos4212.

Signed-off-by: Kyungmin Park 
Signed-off-by: Chanwoo Choi 
---
 arch/arm/mach-exynos/firmware.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index 932129e..aa01c42 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -18,6 +18,8 @@
 
 #include 
 
+#include 
+
 #include "smc.h"
 
 static int exynos_do_idle(void)
@@ -28,13 +30,24 @@ static int exynos_do_idle(void)
 
 static int exynos_cpu_boot(int cpu)
 {
+   /*
+* The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
+* But, Exynos4212 has only one secondary CPU so second parameter
+* isn't used for informing secure firmware about CPU id.
+*/
+   if (soc_is_exynos4212())
+   cpu = 0;
+
exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
return 0;
 }
 
 static int exynos_set_cpu_boot_addr(int cpu, unsigned long boot_addr)
 {
-   void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c + 4*cpu;
+   void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c;
+
+   if (!soc_is_exynos4212())
+   boot_reg += 4*cpu;
 
__raw_writel(boot_addr, boot_reg);
return 0;
-- 
1.8.0

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


Re: BUG: spinlock trylock failure on UP - reverting timer patches helps

2014-04-17 Thread jordan
Hey again,

> [ninez@localhost ~]$  (cat /proc/meminfo ; cat /proc/meminfo) |  grep
> KernelStack
> KernelStack:3728 kB
> KernelStack:3728 kB
> [ninez@localhost ~]$  (cat /proc/meminfo ; cat /proc/meminfo) |  grep
> KernelStack
> KernelStack:3696 kB
> KernelStack:3696 kB
>
> I'll post from my old kernel in a bit.

my other machines all report kstack as being stable/consistent - I
also had an Archlinux user of my kernel check his box - his was
consistent too. [all of those boxes reverted those timer patches].

cheerz

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


[PATCHv3 5/7] clk: samsung: exynos3250: Add clocks using common clock framework

2014-04-17 Thread Chanwoo Choi
From: Tomasz Figa 

This patch add new the clock drvier of Exynos3250 SoC based on Cortex-A7
using common clock framework. The CMU (Clock Management Unit) of Exynos3250
control PLLs(Phase Locked Loops) and generate system clocks for CPU, buses,
and function clocks for individual IPs.

The CMU of Exynos3250 includes following clock doamins:
- CPU block for Cortex-A7 MPCore processor
- LEFTBUS/RIGHTBUS block
- TOP block for G3D/MFC/LCD0/ISP/CAM/FSYS/MFC/PERIL/PERIR

Cc: Mike Turquette 
Cc: Kukjin Kim 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Signed-off-by: Tomasz Figa 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Hyunhee Kim 
Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Inki Dae 
Signed-off-by: Seung-Woo Kim 
Signed-off-by: Jaehoon Chung 
Signed-off-by: Karol Wrona 
Signed-off-by: YoungJun Cho 
Signed-off-by: Kyungmin Park 
---
 drivers/clk/samsung/Makefile   |   1 +
 drivers/clk/samsung/clk-exynos3250.c   | 785 +
 include/dt-bindings/clock/exynos3250.h | 256 +++
 3 files changed, 1042 insertions(+)
 create mode 100644 drivers/clk/samsung/clk-exynos3250.c
 create mode 100644 include/dt-bindings/clock/exynos3250.h

diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 8eb4799..d120797 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -3,6 +3,7 @@
 #
 
 obj-$(CONFIG_COMMON_CLK)   += clk.o clk-pll.o
+obj-$(CONFIG_SOC_EXYNOS3250)   += clk-exynos3250.o
 obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
 obj-$(CONFIG_SOC_EXYNOS5250)   += clk-exynos5250.o
 obj-$(CONFIG_SOC_EXYNOS5420)   += clk-exynos5420.o
diff --git a/drivers/clk/samsung/clk-exynos3250.c 
b/drivers/clk/samsung/clk-exynos3250.c
new file mode 100644
index 000..0574a76
--- /dev/null
+++ b/drivers/clk/samsung/clk-exynos3250.c
@@ -0,0 +1,785 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Common Clock Framework support for Exynos3250 SoC.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "clk.h"
+#include "clk-pll.h"
+
+#define SRC_LEFTBUS0x4200
+#define DIV_LEFTBUS0x4500
+#define GATE_IP_LEFTBUS0x4800
+#define SRC_RIGHTBUS   0x8200
+#define DIV_RIGHTBUS   0x8500
+#define GATE_IP_RIGHTBUS   0x8800
+#define GATE_IP_PERIR  0x8960
+#define MPLL_LOCK  0xc010
+#define MPLL_CON0  0xc110
+#define VPLL_LOCK  0xc020
+#define VPLL_CON0  0xc120
+#define UPLL_LOCK  0xc030
+#define UPLL_CON0  0xc130
+#define SRC_TOP0   0xc210
+#define SRC_TOP1   0xc214
+#define SRC_CAM0xc220
+#define SRC_MFC0xc228
+#define SRC_G3D0xc22c
+#define SRC_LCD0xc234
+#define SRC_ISP0xc238
+#define SRC_FSYS   0xc240
+#define SRC_PERIL0 0xc250
+#define SRC_PERIL1 0xc254
+#define SRC_MASK_TOP   0xc310
+#define SRC_MASK_CAM   0xc320
+#define SRC_MASK_LCD   0xc334
+#define SRC_MASK_ISP   0xc338
+#define SRC_MASK_FSYS  0xc340
+#define SRC_MASK_PERIL00xc350
+#define SRC_MASK_PERIL10xc354
+#define DIV_TOP0xc510
+#define DIV_CAM0xc520
+#define DIV_MFC0xc528
+#define DIV_G3D0xc52c
+#define DIV_LCD0xc534
+#define DIV_ISP0xc538
+#define DIV_FSYS0  0xc540
+#define DIV_FSYS1  0xc544
+#define DIV_FSYS2  0xc548
+#define DIV_PERIL0 0xc550
+#define DIV_PERIL1 0xc554
+#define DIV_PERIL3 0xc55c
+#define DIV_PERIL4 0xc560
+#define DIV_PERIL5 0xc564
+#define DIV_CAM1   0xc568
+#define CLKDIV2_RATIO  0xc580
+#define GATE_SCLK_CAM  0xc820
+#define GATE_SCLK_MFC  0xc828
+#define GATE_SCLK_G3D  0xc82c
+#define GATE_SCLK_LCD  0xc834
+#define GATE_SCLK_ISP_TOP  0xc838
+#define GATE_SCLK_FSYS 0xc840
+#define GATE_SCLK_PERIL0xc850
+#define GATE_IP_CAM0xc920
+#define GATE_IP_MFC0xc928
+#define GATE_IP_G3D0xc92c
+#define GATE_IP_LCD0xc934
+#define GATE_IP_ISP0xc938
+#define GATE_IP_FSYS   0xc940
+#define GATE_IP_PERIL  0xc950
+#define GATE_BLOCK 0xc970
+#define APLL_LOCK  0x14000
+#define APLL_CON0  0x14100
+#define SRC_CPU0x14200
+#define DIV_CPU0   

[PATCHv3 7/7] ARM: dts: Add device tree sources for Exynos3250

2014-04-17 Thread Chanwoo Choi
From: Tomasz Figa 

This patch add new exynos3250.dtsi to support Exynos3250 SoC based on Cortex-A7
dual core and includes following dt nodes:

- GIC interrupt controller
- Pinctrl to control GPIOs
- Clock controller
- CPU information (Cortex-A7 dual core)
- UART to support serial port
- MCT (Multi Core Timer)
- ADC (Analog Digital Converter)
- I2C/SPI bus
- Power domain
- PMU (Performance Monitoring Unit)
- MSHC (Mobile Storage Host Controller)
- PWM (Pluse Width Modulation)
- AMBA bus
- sysram node for SYSRAM memory mapping
- pmu node for PMU memory mapping

Signed-off-by: Tomasz Figa 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Kyungmin Park 
Signed-off-by: Inki Dae 
Signed-off-by: Hyunhee Kim 
Signed-off-by: Jaehoon Chung 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Cc: Ben Dooks 
Cc: Kukjin Kim 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: Russell King 
Cc: devicet...@vger.kernel.org
---
 arch/arm/boot/dts/exynos3250-pinctrl.dtsi | 477 ++
 arch/arm/boot/dts/exynos3250.dtsi | 427 ++
 2 files changed, 904 insertions(+)
 create mode 100644 arch/arm/boot/dts/exynos3250-pinctrl.dtsi
 create mode 100644 arch/arm/boot/dts/exynos3250.dtsi

diff --git a/arch/arm/boot/dts/exynos3250-pinctrl.dtsi 
b/arch/arm/boot/dts/exynos3250-pinctrl.dtsi
new file mode 100644
index 000..976490b
--- /dev/null
+++ b/arch/arm/boot/dts/exynos3250-pinctrl.dtsi
@@ -0,0 +1,477 @@
+/*
+ * Samsung's Exynos3250 SoCs pin-mux and pin-config device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung's Exynos3250 SoCs pin-mux and pin-config optiosn are listed as 
device
+ * tree nodes are listed in this file.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/ {
+   pinctrl@1140 {
+   gpa0: gpa0 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpa1: gpa1 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpb: gpb {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpc0: gpc0 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpc1: gpc1 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpd0: gpd0 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpd1: gpd1 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   uart0_data: uart0-data {
+   samsung,pins = "gpa0-0", "gpa0-1";
+   samsung,pin-function = <0x2>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+
+   uart0_fctl: uart0-fctl {
+   samsung,pins = "gpa0-2", "gpa0-3";
+   samsung,pin-function = <2>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+
+   uart1_data: uart1-data {
+   samsung,pins = "gpa0-4", "gpa0-5";
+   samsung,pin-function = <2>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+
+   uart1_fctl: uart1-fctl {
+   samsung,pins = "gpa0-6", "gpa0-7";
+   samsung,pin-function = <2>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+
+   i2c2_bus: i2c2-bus {
+   samsung,pins = "gpa0-6", "gpa0-7";
+   samsung,pin-function = <3>;
+   samsung,pin-pud = <3>;
+   samsung,pin-drv = <0>;
+   };
+
+   i2c3_bus: i2c3-bus {
+

[PATCHv3 1/7] ARM: EXYNOS: Add Exynos3250 SoC ID

2014-04-17 Thread Chanwoo Choi
This patch add Exynos3250's SoC ID. Exynos 3250 is System-On-Chip(SoC) that
is based on the 32-bit RISC processor for Smartphone. Exynos3250 uses Cortex-A7
dual cores and has a target speed of 1.0GHz.

Signed-off-by: Chanwoo Choi 
Acked-by: Kyungmin Park 
---
 arch/arm/mach-exynos/Kconfig | 22 ++
 arch/arm/mach-exynos/exynos.c|  2 ++
 arch/arm/plat-samsung/include/plat/cpu.h | 10 ++
 3 files changed, 34 insertions(+)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index fc8bf18..6da8a68 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -11,6 +11,17 @@ if ARCH_EXYNOS
 
 menu "SAMSUNG EXYNOS SoCs Support"
 
+config ARCH_EXYNOS3
+   bool "SAMSUNG EXYNOS3"
+   select ARM_AMBA
+   select CLKSRC_OF
+   select HAVE_ARM_SCU if SMP
+   select HAVE_SMP
+   select PINCTRL
+   select PM_GENERIC_DOMAINS if PM_RUNTIME
+   help
+ Samsung EXYNOS3 SoCs based systems
+
 config ARCH_EXYNOS4
bool "SAMSUNG EXYNOS4"
default y
@@ -41,6 +52,17 @@ config ARCH_EXYNOS5
 
 comment "EXYNOS SoCs"
 
+config SOC_EXYNOS3250
+   bool "SAMSUNG EXYNOS3250"
+   default y
+   depends on ARCH_EXYNOS3
+   select ARCH_HAS_BANDGAP
+   select ARM_CPU_SUSPEND if PM
+   select PINCTRL_EXYNOS
+   select SAMSUNG_DMADEV
+   help
+ Enable EXYNOS3250 CPU support
+
 config CPU_EXYNOS4210
bool "SAMSUNG EXYNOS4210"
default y
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 6a5fe18..e7dc6fd 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -346,6 +346,8 @@ static void __init exynos_dt_machine_init(void)
 }
 
 static char const *exynos_dt_compat[] __initconst = {
+   "samsung,exynos3",
+   "samsung,exynos3250",
"samsung,exynos4",
"samsung,exynos4210",
"samsung,exynos4212",
diff --git a/arch/arm/plat-samsung/include/plat/cpu.h 
b/arch/arm/plat-samsung/include/plat/cpu.h
index 5992b8d..3d808f6b 100644
--- a/arch/arm/plat-samsung/include/plat/cpu.h
+++ b/arch/arm/plat-samsung/include/plat/cpu.h
@@ -43,6 +43,9 @@ extern unsigned long samsung_cpu_id;
 #define S5PV210_CPU_ID 0x4311
 #define S5PV210_CPU_MASK   0xF000
 
+#define EXYNOS3250_SOC_ID   0xE3472000
+#define EXYNOS3_SOC_MASK0xF000
+
 #define EXYNOS4210_CPU_ID  0x4321
 #define EXYNOS4212_CPU_ID  0x4322
 #define EXYNOS4412_CPU_ID  0xE4412200
@@ -68,6 +71,7 @@ IS_SAMSUNG_CPU(s5p6440, S5P6440_CPU_ID, S5P64XX_CPU_MASK)
 IS_SAMSUNG_CPU(s5p6450, S5P6450_CPU_ID, S5P64XX_CPU_MASK)
 IS_SAMSUNG_CPU(s5pc100, S5PC100_CPU_ID, S5PC100_CPU_MASK)
 IS_SAMSUNG_CPU(s5pv210, S5PV210_CPU_ID, S5PV210_CPU_MASK)
+IS_SAMSUNG_CPU(exynos3250, EXYNOS3250_SOC_ID, EXYNOS3_SOC_MASK)
 IS_SAMSUNG_CPU(exynos4210, EXYNOS4210_CPU_ID, EXYNOS4_CPU_MASK)
 IS_SAMSUNG_CPU(exynos4212, EXYNOS4212_CPU_ID, EXYNOS4_CPU_MASK)
 IS_SAMSUNG_CPU(exynos4412, EXYNOS4412_CPU_ID, EXYNOS4_CPU_MASK)
@@ -126,6 +130,12 @@ IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID, 
EXYNOS5_SOC_MASK)
 # define soc_is_s5pv210()  0
 #endif
 
+#if defined(CONFIG_SOC_EXYNOS3250)
+# define soc_is_exynos3250()is_samsung_exynos3250()
+#else
+# define soc_is_exynos3250()0
+#endif
+
 #if defined(CONFIG_CPU_EXYNOS4210)
 # define soc_is_exynos4210()   is_samsung_exynos4210()
 #else
-- 
1.8.0

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


[PATCHv3 0/7] Support new Exynos3250 SoC based on Cortex-A7 dual core

2014-04-17 Thread Chanwoo Choi
This patchset support new Exynos3250 Samsung SoC based on Cortex-A7 dual core.
Exynos3250 is a System-On-Chip (SoC) that is based on 32-bit RISC processor
for Smartphone. It is desigend with the 28nm low-power high-K metal gate process
and provides the best performance features.

This patchset include some patches such as:
- Support secondary CPU of Exynos3250 (cpu up/down)
- Supoort uart/mct/adc/gic/i2c/spi/power-domain/pmu/mshc/pwm/amba
- Support the clock control for Exynos3250 using common clk framework

This patchset is based on following git repo/branch.
- git repo : git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
- branch   : for-next (Linux 3.15-rc1)

Additional patch description about static memory mapping:
This patchset must need to map memory mapping about SYSRAM/PMU for CPU UP/DOWN.
So, this patchset need to merge following patchset to remove static memory
mapping for SYSRAM[1] / PMU ([2] or [3]).

[1] http://www.spinics.net/lists/arm-kernel/msg323011.html
[2] https://lkml.org/lkml/2014/4/2/48
[3] http://www.spinics.net/lists/arm-kernel/msg316013.html

And,
The pinctrl patch for Exynos3250 was posted as separated patch[4].
[4] https://lkml.org/lkml/2014/4/13/156

Changes from v2:
- Remove static memory mapping about SYSRAM/PMU such as following patches:
  ARM: EXYNOS: Add IO mapping for non-secure SYSRAM of Exynos3250
  ARM: EXYNOS: Add IO mapping for PMU of Exynos3250
- Add description for secondary CPU boot of Exynos4212/Exynos3250
- Fix description in exynos_cpu_die() to remove particular SoC series
- Fix minor coding style
- Add documentation for Exynos3250 clock controller

Changes from v1:
- Add new "samsung,exynos3" compatible name
- Add comment about exynos_cpu_boot in Exynos4212
- Remove unnecessary 'goto' statement in firmware.c
- Use read_cpuid_part_number() function instead of assembler directly
- Post separated pinctrl patch from this patchset
  : https://lkml.org/lkml/2014/4/13/156
- Remove unused pmu interrupts due to Exynos3250 dual-core
- Cosolidate all the patches related to exynos3250.dtsi into one patch
- Fix gic compatible name to "cortex-a15-gic" because Cortex-A7 GIC is same
- Add sign-off of sender to all this patches
- Fix minor typo

Chanwoo Choi (4):
  ARM: EXYNOS: Add Exynos3250 SoC ID
  ARM: EXYNOS: Support secondary CPU boot of Exynos3250
  ARM: EXYNOS: Enter a15 lowpower mode for Exynos3250 based on Cortex-a7
  dt-bindings: add documentation for Exynos3250 clock controller

Kyungmin Park (1):
  ARM: EXYNOS: Support secondary CPU boot of Exynos4212

Tomasz Figa (2):
  clk: samsung: exynos3250: Add clocks using common clock framework
  ARM: dts: Add device tree sources for Exynos3250

 .../devicetree/bindings/clock/exynos3250-clock.txt |  41 ++
 arch/arm/boot/dts/exynos3250-pinctrl.dtsi  | 477 +
 arch/arm/boot/dts/exynos3250.dtsi  | 427 +++
 arch/arm/mach-exynos/Kconfig   |  22 +
 arch/arm/mach-exynos/exynos.c  |   2 +
 arch/arm/mach-exynos/firmware.c|  21 +-
 arch/arm/mach-exynos/hotplug.c |  19 +-
 arch/arm/plat-samsung/include/plat/cpu.h   |  10 +
 drivers/clk/samsung/Makefile   |   1 +
 drivers/clk/samsung/clk-exynos3250.c   | 785 +
 include/dt-bindings/clock/exynos3250.h | 256 +++
 11 files changed, 2053 insertions(+), 8 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/exynos3250-clock.txt
 create mode 100644 arch/arm/boot/dts/exynos3250-pinctrl.dtsi
 create mode 100644 arch/arm/boot/dts/exynos3250.dtsi
 create mode 100644 drivers/clk/samsung/clk-exynos3250.c
 create mode 100644 include/dt-bindings/clock/exynos3250.h

-- 
1.8.0

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


Re: [PATCH V2 2/2] ahci: add support for Hisilicon sata

2014-04-17 Thread Kefeng Wang
On 04/17 21:31, Tejun Heo wrote:
> On Thu, Apr 17, 2014 at 09:48:03AM +0200, Hans de Goede wrote:
>>> Hmmm this should work but looks a bit tedious and it could be
>>> better to have a better mechanism to match devices to their
>>> port_infos.  Hans, can you please comment?  If getting something more
>>> structured is too much work, I can go with this but wanna find out
>>> whether that's the case.
>>
>> The more structured solution would be v1 of this patch, which I asked
>> Kefan to change since it seemed overkill. But if you prefer that version
>> that is fine with me.
> 
> I don't care either way at this point but if this grows to a large
> list, having a matching mechanism will probably be more manageable.
> 
>> Note that as I've already mentioned earlier in the thread this could be
>> made somewhat cleaner by having an host_flags parameter to
>> ahci_platform_init_host().
> 
> Kefeng, can you please update accordingly to Hans' comment and repost?

Sure, Thanks for the advice from you and Hans, will update.

> 
> Thanks.
> 


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


Re: [GIT PULL] Detaching mounts on unlink for 3.15

2014-04-17 Thread Al Viro
On Fri, Apr 18, 2014 at 01:37:26AM +0100, Al Viro wrote:
> IOW, workqueue is not the right tool here.  OTOH, it looks like we do have
> a problem with kernel/acct.c vs. umount; it just requires a race between
> auto-closing and acct_process_in_ns().  It's narrow, so it doesn't bite
> us all the time, but it's there...  Damn, it had been a long time since
> I really looked at that code ;-/
> 
> Actually, there's another reason why workqueue is bogus - we call
> do_acct_process(), same as we do on acct(NULL) (which might or might
> not be a good idea), but at least with do that from the context of
> real process doing umount(2).  Doing that from workqueue is going to
> produce a really bogus record...

Egads...  Why the hell are we forming (almost) the same record again
and again for every pidns the process belongs to?  Sure, we want
pid/ppid/uid/gid munged, but the rest of it?

And there's something else wrong here - what happens if the last process
in a namespace where we have accounting going on just plain exits?
All mounts in that namespace get dissolved.  Which leads to acct being
autoclosed.  From the context of a process that already has done
acct_process().

Do we ever want to write an acct record on autoclose-on-umount?  Do we
want that record of umount(8) we would've missed otherwise (along with
those of all other still living processes - those we *will* miss anyway)?

Linus, do you have objections against dropping that behaviour?  In theory,
some tools might look at the last record in acct file to figure out what
has stopped the sucker (accton vs. umount), so it's a user-visible change,
but...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [FIX] dmaengine: virt-dma: Free descriptor after callback

2014-04-17 Thread Joel Fernandes
Free the vd (virt descriptor) after the callback is called.  In EDMA driver
atleast which uses virt-dma, we make use of the desc during the callback and if
its dangerously freed before the callback is called. I also noticed this in
omap-dma dmaengine driver.

Cc: Vinod Koul 
Cc: Dan Williams 
Cc: Russell King 
Signed-off-by: Joel Fernandes 
---
 drivers/dma/virt-dma.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/virt-dma.c b/drivers/dma/virt-dma.c
index 6f80432..98aeb7f 100644
--- a/drivers/dma/virt-dma.c
+++ b/drivers/dma/virt-dma.c
@@ -84,10 +84,10 @@ static void vchan_complete(unsigned long arg)
 
list_del(>node);
 
-   vc->desc_free(vd);
-
if (cb)
cb(cb_data);
+
+   vc->desc_free(vd);
}
 }
 
-- 
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/


Attn;

2014-04-17 Thread Rose Ben
Attn;

We have concluded to effect your payment- through-Money Gram $5,000 daily
until the$1.5million US is completely transferred to you accordingly. Though,
Director Dr. Richard chris has sent $5,000 in your name today so contact Money
Gram Agent:below with your full Name,phone contact and address Name: Dr.
Richard chris TEL:+22998766894 Email:moneygramfinancia...@yahoo.fr Ask him for 
the MTCN
sender name and test Question/Answer to pick up your first payment of $5,000.

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


[PATCH 1/2] mmc: sdhci: Use supplies in common mmc_host struct

2014-04-17 Thread Tim Kryger
Switch the common SDHCI code over to use mmc_host's regulator pointers
and remove the ones in the sdhci_host structure.

Signed-off-by: Tim Kryger 
---
 drivers/mmc/host/sdhci.c  |   71 -
 include/linux/mmc/sdhci.h |3 --
 2 files changed, 38 insertions(+), 36 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 9a79fc4..16fba66 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1429,6 +1429,7 @@ static void sdhci_request(struct mmc_host *mmc, struct 
mmc_request *mrq)
 
 static void sdhci_do_set_ios(struct sdhci_host *host, struct mmc_ios *ios)
 {
+   struct mmc_host *mmc = host->mmc;
unsigned long flags;
int vdd_bit = -1;
u8 ctrl;
@@ -1437,8 +1438,8 @@ static void sdhci_do_set_ios(struct sdhci_host *host, 
struct mmc_ios *ios)
 
if (host->flags & SDHCI_DEVICE_DEAD) {
spin_unlock_irqrestore(>lock, flags);
-   if (host->vmmc && ios->power_mode == MMC_POWER_OFF)
-   mmc_regulator_set_ocr(host->mmc, host->vmmc, 0);
+   if (mmc->supply.vmmc && ios->power_mode == MMC_POWER_OFF)
+   mmc_regulator_set_ocr(host->mmc, mmc->supply.vmmc, 0);
return;
}
 
@@ -1463,9 +1464,9 @@ static void sdhci_do_set_ios(struct sdhci_host *host, 
struct mmc_ios *ios)
else
vdd_bit = sdhci_set_power(host, ios->vdd);
 
-   if (host->vmmc && vdd_bit != -1) {
+   if (mmc->supply.vmmc && vdd_bit != -1) {
spin_unlock_irqrestore(>lock, flags);
-   mmc_regulator_set_ocr(host->mmc, host->vmmc, vdd_bit);
+   mmc_regulator_set_ocr(host->mmc, mmc->supply.vmmc, vdd_bit);
spin_lock_irqsave(>lock, flags);
}
 
@@ -1742,6 +1743,7 @@ static void sdhci_enable_sdio_irq(struct mmc_host *mmc, 
int enable)
 static int sdhci_do_start_signal_voltage_switch(struct sdhci_host *host,
struct mmc_ios *ios)
 {
+   struct mmc_host *mmc = host->mmc;
u16 ctrl;
int ret;
 
@@ -1760,8 +1762,9 @@ static int sdhci_do_start_signal_voltage_switch(struct 
sdhci_host *host,
ctrl &= ~SDHCI_CTRL_VDD_180;
sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
 
-   if (host->vqmmc) {
-   ret = regulator_set_voltage(host->vqmmc, 270, 
360);
+   if (mmc->supply.vqmmc) {
+   ret = regulator_set_voltage(mmc->supply.vqmmc, 270,
+   360);
if (ret) {
pr_warning("%s: Switching to 3.3V signalling 
voltage "
" failed\n", 
mmc_hostname(host->mmc));
@@ -1781,8 +1784,8 @@ static int sdhci_do_start_signal_voltage_switch(struct 
sdhci_host *host,
 
return -EAGAIN;
case MMC_SIGNAL_VOLTAGE_180:
-   if (host->vqmmc) {
-   ret = regulator_set_voltage(host->vqmmc,
+   if (mmc->supply.vqmmc) {
+   ret = regulator_set_voltage(mmc->supply.vqmmc,
170, 195);
if (ret) {
pr_warning("%s: Switching to 1.8V signalling 
voltage "
@@ -1811,8 +1814,9 @@ static int sdhci_do_start_signal_voltage_switch(struct 
sdhci_host *host,
 
return -EAGAIN;
case MMC_SIGNAL_VOLTAGE_120:
-   if (host->vqmmc) {
-   ret = regulator_set_voltage(host->vqmmc, 110, 
130);
+   if (mmc->supply.vqmmc) {
+   ret = regulator_set_voltage(mmc->supply.vqmmc, 110,
+   130);
if (ret) {
pr_warning("%s: Switching to 1.2V signalling 
voltage "
" failed\n", 
mmc_hostname(host->mmc));
@@ -2976,24 +2980,24 @@ int sdhci_add_host(struct sdhci_host *host)
mmc->caps |= MMC_CAP_NEEDS_POLL;
 
/* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
-   host->vqmmc = regulator_get_optional(mmc_dev(mmc), "vqmmc");
-   if (IS_ERR_OR_NULL(host->vqmmc)) {
-   if (PTR_ERR(host->vqmmc) < 0) {
+   mmc->supply.vqmmc = regulator_get_optional(mmc_dev(mmc), "vqmmc");
+   if (IS_ERR_OR_NULL(mmc->supply.vqmmc)) {
+   if (PTR_ERR(mmc->supply.vqmmc) < 0) {
pr_info("%s: no vqmmc regulator found\n",
mmc_hostname(mmc));
-   host->vqmmc = NULL;
+   mmc->supply.vqmmc = NULL;
}
} else {
-   ret = regulator_enable(host->vqmmc);
-   if 

[PATCH 0/2] SDHCI should use more common MMC structs and functions

2014-04-17 Thread Tim Kryger
This series updates SDHCI to use the common regulator infrastructure that mmc
core provides.

Tim Kryger (2):
  mmc: sdhci: Use supplies in common mmc_host struct
  mmc: sdhci: Use common mmc_regulator_get_supply

 drivers/mmc/host/sdhci.c  |   96 +
 include/linux/mmc/sdhci.h |3 --
 2 files changed, 35 insertions(+), 64 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/


[PATCH 2/2] mmc: sdhci: Use common mmc_regulator_get_supply

2014-04-17 Thread Tim Kryger
Replace some buggy code with a call to mmc_regulator_get_supply.

When external regulator provides VDD, ocr_avail is set directly based on
the supported voltage range.  This allows for the use of regulators that
can't provide exactly 1.8v, 3.0v, or 3.3v.  Commit cec2e21 had attempted
to address this by relaxing the range checks in the SDHCI driver but it
set the capabilities as an intermediate step which meant ocr_avail could
get bits set for unsupported voltages.

Signed-off-by: Tim Kryger 
---
 drivers/mmc/host/sdhci.c |   67 +-
 1 file changed, 18 insertions(+), 49 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 16fba66..2d081d8 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1438,7 +1438,8 @@ static void sdhci_do_set_ios(struct sdhci_host *host, 
struct mmc_ios *ios)
 
if (host->flags & SDHCI_DEVICE_DEAD) {
spin_unlock_irqrestore(>lock, flags);
-   if (mmc->supply.vmmc && ios->power_mode == MMC_POWER_OFF)
+   if (!IS_ERR(mmc->supply.vmmc) &&
+   ios->power_mode == MMC_POWER_OFF)
mmc_regulator_set_ocr(host->mmc, mmc->supply.vmmc, 0);
return;
}
@@ -1464,7 +1465,7 @@ static void sdhci_do_set_ios(struct sdhci_host *host, 
struct mmc_ios *ios)
else
vdd_bit = sdhci_set_power(host, ios->vdd);
 
-   if (mmc->supply.vmmc && vdd_bit != -1) {
+   if (!IS_ERR(mmc->supply.vmmc) && vdd_bit != -1) {
spin_unlock_irqrestore(>lock, flags);
mmc_regulator_set_ocr(host->mmc, mmc->supply.vmmc, vdd_bit);
spin_lock_irqsave(>lock, flags);
@@ -1762,7 +1763,7 @@ static int sdhci_do_start_signal_voltage_switch(struct 
sdhci_host *host,
ctrl &= ~SDHCI_CTRL_VDD_180;
sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
 
-   if (mmc->supply.vqmmc) {
+   if (!IS_ERR(mmc->supply.vqmmc)) {
ret = regulator_set_voltage(mmc->supply.vqmmc, 270,
360);
if (ret) {
@@ -1784,7 +1785,7 @@ static int sdhci_do_start_signal_voltage_switch(struct 
sdhci_host *host,
 
return -EAGAIN;
case MMC_SIGNAL_VOLTAGE_180:
-   if (mmc->supply.vqmmc) {
+   if (!IS_ERR(mmc->supply.vqmmc)) {
ret = regulator_set_voltage(mmc->supply.vqmmc,
170, 195);
if (ret) {
@@ -1814,7 +1815,7 @@ static int sdhci_do_start_signal_voltage_switch(struct 
sdhci_host *host,
 
return -EAGAIN;
case MMC_SIGNAL_VOLTAGE_120:
-   if (mmc->supply.vqmmc) {
+   if (!IS_ERR(mmc->supply.vqmmc)) {
ret = regulator_set_voltage(mmc->supply.vqmmc, 110,
130);
if (ret) {
@@ -2979,15 +2980,12 @@ int sdhci_add_host(struct sdhci_host *host)
!(host->mmc->caps & MMC_CAP_NONREMOVABLE))
mmc->caps |= MMC_CAP_NEEDS_POLL;
 
+   /* If there are external regulators, get them */
+   if (mmc_regulator_get_supply(mmc) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+
/* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
-   mmc->supply.vqmmc = regulator_get_optional(mmc_dev(mmc), "vqmmc");
-   if (IS_ERR_OR_NULL(mmc->supply.vqmmc)) {
-   if (PTR_ERR(mmc->supply.vqmmc) < 0) {
-   pr_info("%s: no vqmmc regulator found\n",
-   mmc_hostname(mmc));
-   mmc->supply.vqmmc = NULL;
-   }
-   } else {
+   if (!IS_ERR(mmc->supply.vqmmc)) {
ret = regulator_enable(mmc->supply.vqmmc);
if (!regulator_is_supported_voltage(mmc->supply.vqmmc, 170,
195))
@@ -3058,34 +3056,6 @@ int sdhci_add_host(struct sdhci_host *host)
 
ocr_avail = 0;
 
-   mmc->supply.vmmc = regulator_get_optional(mmc_dev(mmc), "vmmc");
-   if (IS_ERR_OR_NULL(mmc->supply.vmmc)) {
-   if (PTR_ERR(mmc->supply.vmmc) < 0) {
-   pr_info("%s: no vmmc regulator found\n",
-   mmc_hostname(mmc));
-   mmc->supply.vmmc = NULL;
-   }
-   }
-
-#ifdef CONFIG_REGULATOR
-   /*
-* Voltage range check makes sense only if regulator reports
-* any voltage value.
-*/
-   if (mmc->supply.vmmc && regulator_get_voltage(mmc->supply.vmmc) > 0) {
-   ret = regulator_is_supported_voltage(mmc->supply.vmmc, 270,
-   360);
-   if ((ret <= 0) || (!(caps[0] & SDHCI_CAN_VDD_330)))
-  

Re: [PATCH 0/3] of: dts: enable memory@0 quirk for PPC32 only

2014-04-17 Thread Rob Herring
On Thu, Apr 17, 2014 at 12:41 PM, Leif Lindholm
 wrote:
> drivers/of/fdt.c contains a workaround for a missing memory type
> entry on longtrail firmware. Make that quirk PPC32 only, and while
> at it - fix up the .dts files in the tree currently working only
> because of that quirk.

But why do you need this?

>
> Cc: devicet...@vger.kernel.org
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: linux-kernel@vger.kernel.org
> Cc: Mark Rutland 
>
> Leif Lindholm (3):
>   arm: dts: add device_type="memory" for ste-ccu8540
>   mips: dts: add device_type="memory" where missing
>   of: Handle memory@0 node on PPC32 only
>
>  arch/arm/boot/dts/ste-ccu8540.dts |1 +
>  arch/mips/lantiq/dts/easy50712.dts|1 +
>  arch/mips/ralink/dts/mt7620a_eval.dts |1 +
>  arch/mips/ralink/dts/rt2880_eval.dts  |1 +
>  arch/mips/ralink/dts/rt3052_eval.dts  |1 +
>  arch/mips/ralink/dts/rt3883_eval.dts  |1 +

I'm not worried about these MIPS dts files because they are all
built-in, but you are breaking compatibility with old dtbs for this
ARM board.

Rob

>  drivers/of/fdt.c  |7 ++-
>  7 files changed, 12 insertions(+), 1 deletion(-)
>
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v4] net: netfilter: LLVMLinux: vlais-netfilter

2014-04-17 Thread Behan Webster

On 03/22/14 23:55, beh...@converseincode.com wrote:

From: Mark Charlebois 

Replaced non-standard C use of Variable Length Arrays In Structs (VLAIS) in
xt_repldata.h with a C99 compliant flexible array member and then calculated
offsets to the other struct members. These other members aren't referenced by
name in this code, however this patch maintains the same memory layout and
padding as was previously accomplished using VLAIS.

Had the original structure been ordered differently, with the entries VLA at
the end, then it could have been a flexible member, and this patch would have
been a lot simpler. However since the data stored in this structure is
ultimately exported to userspace, the order of this structure can't be changed.

This patch makes no attempt to change the existing behavior, merely the way in
which the current layout is accomplished using standard C99 constructs. As such
the code can now be compiled with either gcc or clang.

This version of the patch removes the trailing alignment that the VLAIS
structure would allocate in order to simplify the patch.

Author: Mark Charlebois 
Signed-off-by: Mark Charlebois 
Signed-off-by: Behan Webster 
Signed-off-by: Vinícius Tinti 
---
  net/netfilter/xt_repldata.h | 22 +-
  1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/net/netfilter/xt_repldata.h b/net/netfilter/xt_repldata.h
index 6efe4e5..8fd3241 100644
--- a/net/netfilter/xt_repldata.h
+++ b/net/netfilter/xt_repldata.h
@@ -5,23 +5,35 @@
   * they serve as the hanging-off data accessed through repl.data[].
   */
  
+/* tbl has the following structure equivalent, but is C99 compliant:

+ * struct {
+ * struct type##_replace repl;
+ * struct type##_standard entries[nhooks];
+ * struct type##_error term;
+ * } *tbl;
+ */
+
  #define xt_alloc_initial_table(type, typ2) ({ \
unsigned int hook_mask = info->valid_hooks; \
unsigned int nhooks = hweight32(hook_mask); \
unsigned int bytes = 0, hooknum = 0, i = 0; \
struct { \
struct type##_replace repl; \
-   struct type##_standard entries[nhooks]; \
-   struct type##_error term; \
-   } *tbl = kzalloc(sizeof(*tbl), GFP_KERNEL); \
+   struct type##_standard entries[]; \
+   } *tbl; \
+   struct type##_error *term; \
+   size_t term_offset = (offsetof(typeof(*tbl), entries[nhooks]) + \
+   __alignof__(*term) - 1) & ~(__alignof__(*term) - 1); \
+   tbl = kzalloc(term_offset + sizeof(*term), GFP_KERNEL); \
if (tbl == NULL) \
return NULL; \
+   term = (struct type##_error *)&(((char *)tbl)[term_offset]); \
strncpy(tbl->repl.name, info->name, sizeof(tbl->repl.name)); \
-   tbl->term = (struct type##_error)typ2##_ERROR_INIT;  \
+   *term = (struct type##_error)typ2##_ERROR_INIT;  \
tbl->repl.valid_hooks = hook_mask; \
tbl->repl.num_entries = nhooks + 1; \
tbl->repl.size = nhooks * sizeof(struct type##_standard) + \
-sizeof(struct type##_error); \
+sizeof(struct type##_error); \
for (; hook_mask != 0; hook_mask >>= 1, ++hooknum) { \
if (!(hook_mask & 1)) \
continue; \


Any further feedback about this patch?

Behan

--
Behan Webster
beh...@converseincode.com

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


[PATCH 2/5] KVM: x86: Fix CR3 reserved bits

2014-04-17 Thread Nadav Amit
According to Intel specifications, PAE and non-PAE does not have any reserved
bits.  In long-mode, regardless to PCIDE, only the high bits (above the
physical address) are reserved.

Signed-off-by: Nadav Amit 
---
:100644 100644 7de069af.. e21aee9... M  arch/x86/include/asm/kvm_host.h
:100644 100644 205b17e... 1d60374... M  arch/x86/kvm/emulate.c
:100644 100644 8b8fc0b... f4d9839... M  arch/x86/kvm/x86.c
 arch/x86/include/asm/kvm_host.h |6 +-
 arch/x86/kvm/emulate.c  |4 
 arch/x86/kvm/x86.c  |   25 +
 3 files changed, 6 insertions(+), 29 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 7de069af..e21aee9 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -50,11 +50,7 @@
  | X86_CR0_ET | X86_CR0_NE | X86_CR0_WP | X86_CR0_AM \
  | X86_CR0_NW | X86_CR0_CD | X86_CR0_PG))
 
-#define CR3_PAE_RESERVED_BITS ((X86_CR3_PWT | X86_CR3_PCD) - 1)
-#define CR3_NONPAE_RESERVED_BITS ((PAGE_SIZE-1) & ~(X86_CR3_PWT | X86_CR3_PCD))
-#define CR3_PCID_ENABLED_RESERVED_BITS 0xFF00ULL
-#define CR3_L_MODE_RESERVED_BITS (CR3_NONPAE_RESERVED_BITS |   \
- 0xFF00ULL)
+#define CR3_L_MODE_RESERVED_BITS 0xFF00ULL
 #define CR4_RESERVED_BITS   \
(~(unsigned long)(X86_CR4_VME | X86_CR4_PVI | X86_CR4_TSD | X86_CR4_DE\
  | X86_CR4_PSE | X86_CR4_PAE | X86_CR4_MCE \
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 205b17e..1d60374 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -3386,10 +3386,6 @@ static int check_cr_write(struct x86_emulate_ctxt *ctxt)
ctxt->ops->get_msr(ctxt, MSR_EFER, );
if (efer & EFER_LMA)
rsvd = CR3_L_MODE_RESERVED_BITS;
-   else if (ctxt->ops->get_cr(ctxt, 4) & X86_CR4_PAE)
-   rsvd = CR3_PAE_RESERVED_BITS;
-   else if (ctxt->ops->get_cr(ctxt, 0) & X86_CR0_PG)
-   rsvd = CR3_NONPAE_RESERVED_BITS;
 
if (new_val & rsvd)
return emulate_gp(ctxt, 0);
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 8b8fc0b..f4d9839 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -701,26 +701,11 @@ int kvm_set_cr3(struct kvm_vcpu *vcpu, unsigned long cr3)
return 0;
}
 
-   if (is_long_mode(vcpu)) {
-   if (kvm_read_cr4_bits(vcpu, X86_CR4_PCIDE)) {
-   if (cr3 & CR3_PCID_ENABLED_RESERVED_BITS)
-   return 1;
-   } else
-   if (cr3 & CR3_L_MODE_RESERVED_BITS)
-   return 1;
-   } else {
-   if (is_pae(vcpu)) {
-   if (cr3 & CR3_PAE_RESERVED_BITS)
-   return 1;
-   if (is_paging(vcpu) &&
-   !load_pdptrs(vcpu, vcpu->arch.walk_mmu, cr3))
-   return 1;
-   }
-   /*
-* We don't check reserved bits in nonpae mode, because
-* this isn't enforced, and VMware depends on this.
-*/
-   }
+   if (is_long_mode(vcpu) && (cr3 & CR3_L_MODE_RESERVED_BITS))
+   return 1;
+   if (is_pae(vcpu) && is_paging(vcpu) &&
+   !load_pdptrs(vcpu, vcpu->arch.walk_mmu, cr3))
+   return 1;
 
vcpu->arch.cr3 = cr3;
__set_bit(VCPU_EXREG_CR3, (ulong *)>arch.regs_avail);
-- 
1.7.10.4

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


[PATCH 3/5] KVM: x86: IN instruction emulation should ignore REP-prefix

2014-04-17 Thread Nadav Amit
The IN instruction is not be affected by REP-prefix as INS is.  Therefore, the
emulation should ignore the REP prefix as well.  The current emulator
implementation tries to perform writeback when IN instruction with REP-prefix
is emulated. This causes it to perform wrong memory write or spurious #GP
exception to be injected to the guest.

Signed-off-by: Nadav Amit 
---
:100644 100644 1d60374... 69e2636... M  arch/x86/kvm/emulate.c
 arch/x86/kvm/emulate.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 1d60374..69e2636 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -1324,7 +1324,8 @@ static int pio_in_emulated(struct x86_emulate_ctxt *ctxt,
rc->end = n * size;
}
 
-   if (ctxt->rep_prefix && !(ctxt->eflags & EFLG_DF)) {
+   if (ctxt->rep_prefix && (ctxt->d & String) &&
+   !(ctxt->eflags & EFLG_DF)) {
ctxt->dst.data = rc->data + rc->pos;
ctxt->dst.type = OP_MEM_STR;
ctxt->dst.count = (rc->end - rc->pos) / size;
-- 
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: [GIT PULL] Detaching mounts on unlink for 3.15

2014-04-17 Thread Al Viro
On Thu, Apr 17, 2014 at 11:12:03PM +0100, Al Viro wrote:

> That's all.  And yes, I believe that such series would make sense on its
> own and once it survives beating (see above about docker - that bastard has
> surprised me quite a bit re stressing namespace-related codepaths), I would
> be quite willing to help with getting it merged.

FWIW, the tricky part around auto-close of acct is that we really want to
preserve the following property:

In usual setups, umount(2) will not return until fs has been
shut down.

fput() being async is not a problem - it will be processed before we
return to userland.  I agree that we don't need the loop anymore (it's
basically a stack depth reduction measure that was needed with sync
fput() - without "add one more and deal with it when we return" we
would be getting mntput_no_expire -> fput -> mntput -> fs shutdown
back then).  But offloading that fput() to workqueue makes it really
possible to have actual fs shutdown happen after umount(2) returns,
without any extra mounts of the same fs, etc.  And since that shutdown
*can* take a long time (lots of dirty pages around, slow device or
slow network, etc.), we really might be talking about e.g. umount(8)
being finished before fs shutdown finishes.  It's an expected situation
when we have the same thing still mounted elsewhere or lazy-umounted
and busy, but this changes behaviour on setups where we had been
guaranteed that umount -a *will* wait until all filesystems except
root are shut down and root is remounted r/o.  So this change really
can cause data loss on reboot(8)/halt(8) on existing boxen...

IOW, workqueue is not the right tool here.  OTOH, it looks like we do have
a problem with kernel/acct.c vs. umount; it just requires a race between
auto-closing and acct_process_in_ns().  It's narrow, so it doesn't bite
us all the time, but it's there...  Damn, it had been a long time since
I really looked at that code ;-/

Actually, there's another reason why workqueue is bogus - we call
do_acct_process(), same as we do on acct(NULL) (which might or might
not be a good idea), but at least with do that from the context of
real process doing umount(2).  Doing that from workqueue is going to
produce a really bogus record...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 1/5] KVM: x86: Fix wrong/stuck PMU when guest does not use PMI

2014-04-17 Thread Nadav Amit
If a guest enables a performance counter but does not enable PMI, the
hypervisor currently does not reprogram the performance counter once it
overflows.  As a result the host performance counter is kept with the original
sampling period which was configured according to the value of the guest's
counter when the counter was enabled.

Such behaviour can cause very bad consequences. The most distrubing one can
cause the guest not to make any progress at all, and keep exiting due to host
PMI before any guest instructions is exeucted. This situation occurs when the
performance counter holds a very high value when the guest enables the
performance counter. As a result the host's sampling period is configured to be
very short. The host then never reconfigures the sampling period and get stuck
at entry->PMI->exit loop. We encountered such a scenario in our experiments.

The solution is to reprogram the counter even if the guest does not use PMI.

Signed-off-by: Nadav Amit 
---
:100644 100644 5c4f631... cbecaa9... M  arch/x86/kvm/pmu.c
 arch/x86/kvm/pmu.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
index 5c4f631..cbecaa9 100644
--- a/arch/x86/kvm/pmu.c
+++ b/arch/x86/kvm/pmu.c
@@ -108,7 +108,10 @@ static void kvm_perf_overflow(struct perf_event 
*perf_event,
 {
struct kvm_pmc *pmc = perf_event->overflow_handler_context;
struct kvm_pmu *pmu = >vcpu->arch.pmu;
-   __set_bit(pmc->idx, (unsigned long *)>global_status);
+   if (!test_and_set_bit(pmc->idx, (unsigned long *)>reprogram_pmi)) {
+   __set_bit(pmc->idx, (unsigned long *)>global_status);
+   kvm_make_request(KVM_REQ_PMU, pmc->vcpu);
+   }
 }
 
 static void kvm_perf_overflow_intr(struct perf_event *perf_event,
@@ -117,7 +120,7 @@ static void kvm_perf_overflow_intr(struct perf_event 
*perf_event,
struct kvm_pmc *pmc = perf_event->overflow_handler_context;
struct kvm_pmu *pmu = >vcpu->arch.pmu;
if (!test_and_set_bit(pmc->idx, (unsigned long *)>reprogram_pmi)) {
-   kvm_perf_overflow(perf_event, data, regs);
+   __set_bit(pmc->idx, (unsigned long *)>global_status);
kvm_make_request(KVM_REQ_PMU, pmc->vcpu);
/*
 * Inject PMI. If vcpu was in a guest mode during NMI PMI
-- 
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/


[PATCHv3 3/8] extcon: gpio: Use devm_extcon_dev_register()

2014-04-17 Thread Sangjung Woo
Use the resource-managed extcon device register function (i.e.
devm_extcon_dev_register()) instead of extcon_dev_register(). If extcon device
is attached with this function, that extcon device is automatically unregistered
on driver detach. That reduces tiresome managing code.

Signed-off-by: Sangjung Woo 
---
 drivers/extcon/extcon-gpio.c |   16 
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index 13d5222..43af34c 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -121,34 +121,27 @@ static int gpio_extcon_probe(struct platform_device *pdev)
msecs_to_jiffies(pdata->debounce);
}
 
-   ret = extcon_dev_register(_data->edev);
+   ret = devm_extcon_dev_register(>dev, _data->edev);
if (ret < 0)
return ret;
 
INIT_DELAYED_WORK(_data->work, gpio_extcon_work);
 
extcon_data->irq = gpio_to_irq(extcon_data->gpio);
-   if (extcon_data->irq < 0) {
-   ret = extcon_data->irq;
-   goto err;
-   }
+   if (extcon_data->irq < 0)
+   return extcon_data->irq;
 
ret = request_any_context_irq(extcon_data->irq, gpio_irq_handler,
  pdata->irq_flags, pdev->name,
  extcon_data);
if (ret < 0)
-   goto err;
+   return ret;
 
platform_set_drvdata(pdev, extcon_data);
/* Perform initial detection */
gpio_extcon_work(_data->work.work);
 
return 0;
-
-err:
-   extcon_dev_unregister(_data->edev);
-
-   return ret;
 }
 
 static int gpio_extcon_remove(struct platform_device *pdev)
@@ -157,7 +150,6 @@ static int gpio_extcon_remove(struct platform_device *pdev)
 
cancel_delayed_work_sync(_data->work);
free_irq(extcon_data->irq, extcon_data);
-   extcon_dev_unregister(_data->edev);
 
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/


[PATCHv3 4/8] extcon: max14577: Use devm_extcon_dev_register()

2014-04-17 Thread Sangjung Woo
Use the resource-managed extcon device register function (i.e.
devm_extcon_dev_register()) instead of extcon_dev_register(). If extcon device
is attached with this function, that extcon device is automatically unregistered
on driver detach. That reduces tiresome managing code.

Signed-off-by: Sangjung Woo 
Reviewed-by: Krzysztof Kozlowski 
---
 drivers/extcon/extcon-max14577.c |9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/extcon/extcon-max14577.c b/drivers/extcon/extcon-max14577.c
index 1fef08d..c6166e7 100644
--- a/drivers/extcon/extcon-max14577.c
+++ b/drivers/extcon/extcon-max14577.c
@@ -675,7 +675,7 @@ static int max14577_muic_probe(struct platform_device *pdev)
}
info->edev->name = DEV_NAME;
info->edev->supported_cable = max14577_extcon_cable;
-   ret = extcon_dev_register(info->edev);
+   ret = devm_extcon_dev_register(>dev, info->edev);
if (ret) {
dev_err(>dev, "failed to register extcon device\n");
return ret;
@@ -694,7 +694,7 @@ static int max14577_muic_probe(struct platform_device *pdev)
MAX14577_REG_DEVICEID, );
if (ret < 0) {
dev_err(>dev, "failed to read revision number\n");
-   goto err_extcon;
+   return ret;
}
dev_info(info->dev, "device ID : 0x%x\n", id);
 
@@ -714,10 +714,6 @@ static int max14577_muic_probe(struct platform_device 
*pdev)
delay_jiffies);
 
return ret;
-
-err_extcon:
-   extcon_dev_unregister(info->edev);
-   return ret;
 }
 
 static int max14577_muic_remove(struct platform_device *pdev)
@@ -725,7 +721,6 @@ static int max14577_muic_remove(struct platform_device 
*pdev)
struct max14577_muic_info *info = platform_get_drvdata(pdev);
 
cancel_work_sync(>irq_work);
-   extcon_dev_unregister(info->edev);
 
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/


[PATCHv3 6/8] extcon: max8997: Use devm_extcon_dev_register()

2014-04-17 Thread Sangjung Woo
Use the resource-managed extcon device register function (i.e.
devm_extcon_dev_register()) instead of extcon_dev_register(). If extcon device
is attached with this function, that extcon device is automatically unregistered
on driver detach. That reduces tiresome managing code.

Signed-off-by: Sangjung Woo 
Reviewed-by: Krzysztof Kozlowski 
---
 drivers/extcon/extcon-max8997.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/extcon/extcon-max8997.c b/drivers/extcon/extcon-max8997.c
index 223e6b0..804a446 100644
--- a/drivers/extcon/extcon-max8997.c
+++ b/drivers/extcon/extcon-max8997.c
@@ -709,7 +709,7 @@ static int max8997_muic_probe(struct platform_device *pdev)
info->edev->name = DEV_NAME;
info->edev->dev.parent = >dev;
info->edev->supported_cable = max8997_extcon_cable;
-   ret = extcon_dev_register(info->edev);
+   ret = devm_extcon_dev_register(>dev, info->edev);
if (ret) {
dev_err(>dev, "failed to register extcon device\n");
goto err_irq;
@@ -790,8 +790,6 @@ static int max8997_muic_remove(struct platform_device *pdev)
free_irq(muic_irqs[i].virq, info);
cancel_work_sync(>irq_work);
 
-   extcon_dev_unregister(info->edev);
-
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/


[PATCHv3 5/8] extcon: max77693: Use devm_extcon_dev_register()

2014-04-17 Thread Sangjung Woo
Use the resource-managed extcon device register function (i.e.
devm_extcon_dev_register()) instead of extcon_dev_register(). If extcon device
is attached with this function, that extcon device is automatically unregistered
on driver detach. That reduces tiresome managing code.

Signed-off-by: Sangjung Woo 
Reviewed-by: Krzysztof Kozlowski 
---
 drivers/extcon/extcon-max77693.c |7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/extcon/extcon-max77693.c b/drivers/extcon/extcon-max77693.c
index 39cd095..f0f18e2 100644
--- a/drivers/extcon/extcon-max77693.c
+++ b/drivers/extcon/extcon-max77693.c
@@ -1185,7 +1185,7 @@ static int max77693_muic_probe(struct platform_device 
*pdev)
info->edev->name = DEV_NAME;
info->edev->dev.parent = >dev;
info->edev->supported_cable = max77693_extcon_cable;
-   ret = extcon_dev_register(info->edev);
+   ret = devm_extcon_dev_register(>dev, info->edev);
if (ret) {
dev_err(>dev, "failed to register extcon device\n");
goto err_irq;
@@ -1267,7 +1267,7 @@ static int max77693_muic_probe(struct platform_device 
*pdev)
MAX77693_MUIC_REG_ID, );
if (ret < 0) {
dev_err(>dev, "failed to read revision number\n");
-   goto err_extcon;
+   goto err_irq;
}
dev_info(info->dev, "device ID : 0x%x\n", id);
 
@@ -1288,8 +1288,6 @@ static int max77693_muic_probe(struct platform_device 
*pdev)
 
return ret;
 
-err_extcon:
-   extcon_dev_unregister(info->edev);
 err_irq:
while (--i >= 0)
free_irq(muic_irqs[i].virq, info);
@@ -1305,7 +1303,6 @@ static int max77693_muic_remove(struct platform_device 
*pdev)
free_irq(muic_irqs[i].virq, info);
cancel_work_sync(>irq_work);
input_unregister_device(info->dock);
-   extcon_dev_unregister(info->edev);
 
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/


[PATCHv3 0/8] Resource-managed extcon device register function

2014-04-17 Thread Sangjung Woo
These patches add resource-managed extcon device register functions for
developers' convenience and apply them to related device driver files.
This work can make the code more tidy since extcon device is automatically
unregistered on driver detach so tiresome managing codes could be removed.


Changelog:

v3:
* send the right version instead of previous v1
* add the credit for reviewers according to the review rules

v2:
* modify and clean up all unnecessary code reported by Chanwoo
* fix the bug reported by Seung-Woo
* add the credit for reviewers

v1:
* initial version

Sangjung Woo (8):
  extcon: Add resource-managed extcon register function
  extcon: adc-jack: Use devm_extcon_dev_register()
  extcon: gpio: Use devm_extcon_dev_register()
  extcon: max14577: Use devm_extcon_dev_register()
  extcon: max77693: Use devm_extcon_dev_register()
  extcon: max8997: Use devm_extcon_dev_register()
  extcon: palmas: Use devm_extcon_dev_register()
  extcon: arizona: Use devm_extcon_dev_register()

 drivers/extcon/extcon-adc-jack.c |   30 +---
 drivers/extcon/extcon-arizona.c  |   12 +++
 drivers/extcon/extcon-class.c|   72 ++
 drivers/extcon/extcon-gpio.c |   16 +++--
 drivers/extcon/extcon-max14577.c |9 ++---
 drivers/extcon/extcon-max77693.c |7 ++--
 drivers/extcon/extcon-max8997.c  |4 +--
 drivers/extcon/extcon-palmas.c   |   15 +++-
 include/linux/extcon.h   |   17 +
 9 files changed, 116 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/


[PATCHv3 1/8] extcon: Add resource-managed extcon register function

2014-04-17 Thread Sangjung Woo
Add resource-managed extcon device register function for convenience.
For example, if a extcon device is attached with new
devm_extcon_dev_register(), that extcon device is automatically
unregistered on driver detach.

Signed-off-by: Sangjung Woo 
---
 drivers/extcon/extcon-class.c |   72 +
 include/linux/extcon.h|   17 ++
 2 files changed, 89 insertions(+)

diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 7ab21aa..e177edb6 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -819,6 +819,78 @@ void extcon_dev_unregister(struct extcon_dev *edev)
 }
 EXPORT_SYMBOL_GPL(extcon_dev_unregister);
 
+
+/*
+ * Device resource management
+ */
+static void devm_extcon_dev_release(struct device *dev, void *res)
+{
+   struct extcon_dev *devres = res;
+
+   extcon_dev_unregister(devres);
+}
+
+static int devm_extcon_dev_match(struct device *dev, void *res, void *data)
+{
+   struct extcon_dev *devres = res;
+   struct extcon_dev *match = data;
+   return devres == match;
+}
+
+/**
+ * devm_extcon_dev_register() - Resource-managed extcon_dev_register()
+ * @dev:   device to allocate extcon device
+ * @edev:  the new extcon device to register
+ *
+ * Managed extcon_dev_register() function. If extcon device is attached with
+ * this function, that extcon device is automatically unregistered on driver
+ * detach. Internally this function calls extcon_dev_register() function.
+ * To get more information, refer that function.
+ *
+ * If extcon device is registered with this function and the device needs to be
+ * unregistered separately, devm_extcon_dev_unregister() should be used.
+ *
+ * RETURNS:
+ * 0 on success, negative error number on failure.
+ */
+int devm_extcon_dev_register(struct device *dev, struct extcon_dev *edev)
+{
+   struct extcon_dev *devres;
+   int ret;
+
+   devres = devres_alloc(devm_extcon_dev_release, sizeof(*devres),
+   GFP_KERNEL);
+   if (!devres)
+   return -ENOMEM;
+
+   ret = extcon_dev_register(edev);
+   if (ret) {
+   devres_free(devres);
+   return ret;
+   }
+
+   devres = edev;
+   devres_add(dev, devres);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(devm_extcon_dev_register);
+
+/**
+ * devm_extcon_dev_unregister() - Resource-managed extcon_dev_unregister()
+ * @dev:   device the extcon belongs to
+ * @edev:  the extcon device to unregister
+ *
+ * Unregister extcon device that is registered with devm_extcon_dev_register()
+ * function.
+ */
+void devm_extcon_dev_unregister(struct device *dev, struct extcon_dev *edev)
+{
+   WARN_ON(devres_release(dev, devm_extcon_dev_release,
+   devm_extcon_dev_match, edev));
+}
+EXPORT_SYMBOL_GPL(devm_extcon_dev_unregister);
+
 #ifdef CONFIG_OF
 /*
  * extcon_get_edev_by_phandle - Get the extcon device from devicetree
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index f488145..35f3343 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -188,6 +188,14 @@ extern void extcon_dev_unregister(struct extcon_dev *edev);
 extern struct extcon_dev *extcon_get_extcon_dev(const char *extcon_name);
 
 /*
+ * Resource-managed extcon device register function.
+ */
+extern int devm_extcon_dev_register(struct device *dev,
+   struct extcon_dev *edev);
+extern void devm_extcon_dev_unregister(struct device *dev,
+   struct extcon_dev *edev);
+
+/*
  * get/set/update_state access the 32b encoded state value, which represents
  * states of all possible cables of the multistate port. For example, if one
  * calls extcon_set_state(edev, 0x7), it may mean that all the three cables
@@ -254,6 +262,15 @@ static inline int extcon_dev_register(struct extcon_dev 
*edev)
 
 static inline void extcon_dev_unregister(struct extcon_dev *edev) { }
 
+static inline devm_extcon_dev_register(struct device *dev,
+   struct extcon_dev *edev)
+{
+   return 0;
+}
+
+static inline devm_extcon_dev_unregister(struct device *dev,
+   struct extcon_dev *edev) { }
+
 static inline u32 extcon_get_state(struct extcon_dev *edev)
 {
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/


[PATCHv3 7/8] extcon: palmas: Use devm_extcon_dev_register()

2014-04-17 Thread Sangjung Woo
Use the resource-managed extcon device register function (i.e.
devm_extcon_dev_register()) instead of extcon_dev_register(). If extcon device
is attached with this function, that extcon device is automatically unregistered
on driver detach. That reduces tiresome managing code.

Signed-off-by: Sangjung Woo 
---
 drivers/extcon/extcon-palmas.c |   15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
index 51db5bc..1a770e0 100644
--- a/drivers/extcon/extcon-palmas.c
+++ b/drivers/extcon/extcon-palmas.c
@@ -192,7 +192,7 @@ static int palmas_usb_probe(struct platform_device *pdev)
palmas_usb->edev.name = kstrdup(node->name, GFP_KERNEL);
palmas_usb->edev.mutually_exclusive = mutually_exclusive;
 
-   status = extcon_dev_register(_usb->edev);
+   status = devm_extcon_dev_register(>dev, _usb->edev);
if (status) {
dev_err(>dev, "failed to register extcon device\n");
kfree(palmas_usb->edev.name);
@@ -209,7 +209,8 @@ static int palmas_usb_probe(struct platform_device *pdev)
if (status < 0) {
dev_err(>dev, "can't get IRQ %d, err %d\n",
palmas_usb->id_irq, status);
-   goto fail_extcon;
+   kfree(palmas_usb->edev.name);
+   return status;
}
}
 
@@ -223,26 +224,20 @@ static int palmas_usb_probe(struct platform_device *pdev)
if (status < 0) {
dev_err(>dev, "can't get IRQ %d, err %d\n",
palmas_usb->vbus_irq, status);
-   goto fail_extcon;
+   kfree(palmas_usb->edev.name);
+   return status;
}
}
 
palmas_enable_irq(palmas_usb);
device_set_wakeup_capable(>dev, true);
return 0;
-
-fail_extcon:
-   extcon_dev_unregister(_usb->edev);
-   kfree(palmas_usb->edev.name);
-
-   return status;
 }
 
 static int palmas_usb_remove(struct platform_device *pdev)
 {
struct palmas_usb *palmas_usb = platform_get_drvdata(pdev);
 
-   extcon_dev_unregister(_usb->edev);
kfree(palmas_usb->edev.name);
 
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/


[PATCHv3 8/8] extcon: arizona: Use devm_extcon_dev_register()

2014-04-17 Thread Sangjung Woo
Use the resource-managed extcon device register function (i.e.
devm_extcon_dev_register()) instead of extcon_dev_register(). If extcon device
is attached with this function, that extcon device is automatically unregistered
on driver detach. That reduces tiresome managing code.

Signed-off-by: Sangjung Woo 
---
 drivers/extcon/extcon-arizona.c |   12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index 98a14f6..f63fa6f 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -1105,15 +1105,14 @@ static int arizona_extcon_probe(struct platform_device 
*pdev)
info = devm_kzalloc(>dev, sizeof(*info), GFP_KERNEL);
if (!info) {
dev_err(>dev, "Failed to allocate memory\n");
-   ret = -ENOMEM;
-   goto err;
+   return -ENOMEM;
}
 
info->micvdd = devm_regulator_get(arizona->dev, "MICVDD");
if (IS_ERR(info->micvdd)) {
ret = PTR_ERR(info->micvdd);
dev_err(arizona->dev, "Failed to get MICVDD: %d\n", ret);
-   goto err;
+   return ret;
}
 
mutex_init(>lock);
@@ -1155,11 +1154,11 @@ static int arizona_extcon_probe(struct platform_device 
*pdev)
info->edev.dev.parent = arizona->dev;
info->edev.supported_cable = arizona_cable;
 
-   ret = extcon_dev_register(>edev);
+   ret = devm_extcon_dev_register(>dev, >edev);
if (ret < 0) {
dev_err(arizona->dev, "extcon_dev_register() failed: %d\n",
ret);
-   goto err;
+   return ret;
}
 
info->input = devm_input_allocate_device(>dev);
@@ -1410,8 +1409,6 @@ err_rise:
 err_input:
 err_register:
pm_runtime_disable(>dev);
-   extcon_dev_unregister(>edev);
-err:
return ret;
 }
 
@@ -1445,7 +1442,6 @@ static int arizona_extcon_remove(struct platform_device 
*pdev)
regmap_update_bits(arizona->regmap, ARIZONA_JACK_DETECT_ANALOGUE,
   ARIZONA_JD1_ENA, 0);
arizona_clk32k_disable(arizona);
-   extcon_dev_unregister(>edev);
 
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/


[PATCHv3 2/8] extcon: adc-jack: Use devm_extcon_dev_register()

2014-04-17 Thread Sangjung Woo
Use the resource-managed extcon device register function (i.e.
devm_extcon_dev_register()) instead of extcon_dev_register(). If extcon device
is attached with this function, that extcon device is automatically unregistered
on driver detach. That reduces tiresome managing code.

Signed-off-by: Sangjung Woo 
---
 drivers/extcon/extcon-adc-jack.c |   30 +-
 1 file changed, 9 insertions(+), 21 deletions(-)

diff --git a/drivers/extcon/extcon-adc-jack.c b/drivers/extcon/extcon-adc-jack.c
index e23f1c2..549d820 100644
--- a/drivers/extcon/extcon-adc-jack.c
+++ b/drivers/extcon/extcon-adc-jack.c
@@ -105,9 +105,8 @@ static int adc_jack_probe(struct platform_device *pdev)
data->edev.name = pdata->name;
 
if (!pdata->cable_names) {
-   err = -EINVAL;
dev_err(>dev, "error: cable_names not defined.\n");
-   goto out;
+   return -EINVAL;
}
 
data->edev.dev.parent = >dev;
@@ -117,18 +116,16 @@ static int adc_jack_probe(struct platform_device *pdev)
for (i = 0; data->edev.supported_cable[i]; i++)
;
if (i == 0 || i > SUPPORTED_CABLE_MAX) {
-   err = -EINVAL;
dev_err(>dev, "error: pdata->cable_names size = %d\n",
i - 1);
-   goto out;
+   return -EINVAL;
}
data->num_cables = i;
 
if (!pdata->adc_conditions ||
!pdata->adc_conditions[0].state) {
-   err = -EINVAL;
dev_err(>dev, "error: adc_conditions not defined.\n");
-   goto out;
+   return -EINVAL;
}
data->adc_conditions = pdata->adc_conditions;
 
@@ -138,10 +135,8 @@ static int adc_jack_probe(struct platform_device *pdev)
data->num_conditions = i;
 
data->chan = iio_channel_get(>dev, pdata->consumer_channel);
-   if (IS_ERR(data->chan)) {
-   err = PTR_ERR(data->chan);
-   goto out;
-   }
+   if (IS_ERR(data->chan))
+   return PTR_ERR(data->chan);
 
data->handling_delay = msecs_to_jiffies(pdata->handling_delay_ms);
 
@@ -149,15 +144,14 @@ static int adc_jack_probe(struct platform_device *pdev)
 
platform_set_drvdata(pdev, data);
 
-   err = extcon_dev_register(>edev);
+   err = devm_extcon_dev_register(>dev, >edev);
if (err)
-   goto out;
+   return err;
 
data->irq = platform_get_irq(pdev, 0);
if (!data->irq) {
dev_err(>dev, "platform_get_irq failed\n");
-   err = -ENODEV;
-   goto err_irq;
+   return -ENODEV;
}
 
err = request_any_context_irq(data->irq, adc_jack_irq_thread,
@@ -165,15 +159,10 @@ static int adc_jack_probe(struct platform_device *pdev)
 
if (err < 0) {
dev_err(>dev, "error: irq %d\n", data->irq);
-   goto err_irq;
+   return err;
}
 
return 0;
-
-err_irq:
-   extcon_dev_unregister(>edev);
-out:
-   return err;
 }
 
 static int adc_jack_remove(struct platform_device *pdev)
@@ -182,7 +171,6 @@ static int adc_jack_remove(struct platform_device *pdev)
 
free_irq(data->irq, data);
cancel_work_sync(>handler.work);
-   extcon_dev_unregister(>edev);
 
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] staging: cxt1e1: replace OS_kmalloc/OS_kfree with kzalloc/kfree

2014-04-17 Thread Daeseok Youn
Replace OS_kmalloc/OS_kfree with kzalloc/kfree.
And also some allocation doesn't need to use GFP_DMA
so just use GFP_KERNEL.

c4_new() function is never called, remove it.

Signed-off-by: Daeseok Youn 
---
V4: update patch description, OS_kmalloc should be replaced with
kzalloc for zeroed out the allocated data.
V3: replace kmalloc with kzalloc.
V2: fix subject and comment correctly.

It has some coding style issue. If this patch is merged,
I fix this issue with another patch.

 drivers/staging/cxt1e1/hwprobe.c |2 +-
 drivers/staging/cxt1e1/linux.c   |   21 +--
 drivers/staging/cxt1e1/musycc.c  |   12 ---
 drivers/staging/cxt1e1/pmcc4_drv.c   |   47 +-
 drivers/staging/cxt1e1/sbecom_inline_linux.h |   23 +
 drivers/staging/cxt1e1/sbecrc.c  |5 ++-
 drivers/staging/cxt1e1/sbeproc.c |2 +-
 7 files changed, 32 insertions(+), 80 deletions(-)

diff --git a/drivers/staging/cxt1e1/hwprobe.c b/drivers/staging/cxt1e1/hwprobe.c
index 9b4198b..6e207f5 100644
--- a/drivers/staging/cxt1e1/hwprobe.c
+++ b/drivers/staging/cxt1e1/hwprobe.c
@@ -205,7 +205,7 @@ cleanup_devs(void)
 #ifdef CONFIG_SBE_PMCC4_NCOMM
free_irq(hi->pdev[1]->irq, hi->ndev);
 #endif
-   OS_kfree(hi->ndev);
+   kfree(hi->ndev);
}
 }
 
diff --git a/drivers/staging/cxt1e1/linux.c b/drivers/staging/cxt1e1/linux.c
index b02f5ade..4b4609d 100644
--- a/drivers/staging/cxt1e1/linux.c
+++ b/drivers/staging/cxt1e1/linux.c
@@ -60,7 +60,6 @@ status_tc4_chan_work_init(mpi_t *, mch_t *);
 voidmusycc_wq_chan_restart(void *);
 status_t __init c4_init(ci_t *, u_char *, u_char *);
 status_t __init c4_init2(ci_t *);
-ci_t   *__init c4_new(void *);
 int __init  c4hw_attach_all(void);
 void __init hdw_sn_get(hdw_info_t *, int);
 
@@ -418,7 +417,7 @@ create_chan(struct net_device *ndev, ci_t *ci,
struct c4_priv *priv;
 
/* allocate then fill in private data structure */
-   priv = OS_kmalloc(sizeof(struct c4_priv));
+   priv = kzalloc(sizeof(struct c4_priv), GFP_KERNEL);
if (!priv) {
pr_warning("%s: no memory for net_device !\n",
   ci->devname);
@@ -428,7 +427,7 @@ create_chan(struct net_device *ndev, ci_t *ci,
if (!dev) {
pr_warning("%s: no memory for hdlc_device !\n",
   ci->devname);
-   OS_kfree(priv);
+   kfree(priv);
return NULL;
}
priv->ci = ci;
@@ -972,8 +971,8 @@ c4_add_dev(hdw_info_t *hi, int brdno, unsigned long f0, 
unsigned long f1,
 
if (register_netdev(ndev) ||
(c4_init(ci, (u_char *) f0, (u_char *) f1) != 
SBE_DRVR_SUCCESS)) {
-   OS_kfree(netdev_priv(ndev));
-   OS_kfree(ndev);
+   kfree(netdev_priv(ndev));
+   kfree(ndev);
error_flag = -ENODEV;
return NULL;
}
@@ -998,8 +997,8 @@ c4_add_dev(hdw_info_t *hi, int brdno, unsigned long f0, 
unsigned long f1,
pr_warning("%s: MUSYCC could not get irq: %d\n",
   ndev->name, irq0);
unregister_netdev(ndev);
-   OS_kfree(netdev_priv(ndev));
-   OS_kfree(ndev);
+   kfree(netdev_priv(ndev));
+   kfree(ndev);
error_flag = -EIO;
return NULL;
}
@@ -1008,8 +1007,8 @@ c4_add_dev(hdw_info_t *hi, int brdno, unsigned long f0, 
unsigned long f1,
pr_warning("%s: EBUS could not get irq: %d\n", hi->devname, 
irq1);
unregister_netdev(ndev);
free_irq(irq0, ndev);
-   OS_kfree(netdev_priv(ndev));
-   OS_kfree(ndev);
+   kfree(netdev_priv(ndev));
+   kfree(ndev);
error_flag = -EIO;
return NULL;
}
@@ -1068,8 +1067,8 @@ c4_add_dev(hdw_info_t *hi, int brdno, unsigned long f0, 
unsigned long f1,
unregister_netdev(ndev);
free_irq(irq1, ndev);
free_irq(irq0, ndev);
-   OS_kfree(netdev_priv(ndev));
-   OS_kfree(ndev);
+   kfree(netdev_priv(ndev));
+   kfree(ndev);
/* failure, error_flag is set */
return NULL;
}
diff --git a/drivers/staging/cxt1e1/musycc.c b/drivers/staging/cxt1e1/musycc.c
index 7b4f6f2..872cdae 100644
--- a/drivers/staging/cxt1e1/musycc.c
+++ b/drivers/staging/cxt1e1/musycc.c
@@ -744,7 +744,8 @@ musycc_init(ci_t *ci)
 
 #define INT_QUEUE_BOUNDARY  4
 
-regaddr = OS_kmalloc((INT_QUEUE_SIZE + 1) * sizeof(u_int32_t));
+   regaddr = kzalloc((INT_QUEUE_SIZE + 1) * sizeof(u_int32_t),
+ GFP_KERNEL | 

Re: [PATCH v2 1/4] sysctl: clean up char buffer arguments

2014-04-17 Thread Andi Kleen

BTW if you're worried about sysctl races you may also want to resurrect
https://lkml.org/lkml/2009/12/20/214

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v3 4/5] seccomp: add PR_SECCOMP_EXT and SECCOMP_EXT_ACT_FILTER

2014-04-17 Thread Kees Cook
This change adds a new seccomp "extension" framework for more complex
filter actions and option setting. The need for the added prctl() is
due to the lack of reserved arguments in PR_SET_SECCOMP (much existing
code already calls prctl without initializing trailing arguments).

When prctl(PR_SECCOMP_EXT, SECCOMP_EXT_ACT_FILTER, flags, filter) is
called, it will be the same as prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER,
filter), when flags is 0. This will allow for additional flags being
set on the filter in the future.

Signed-off-by: Kees Cook 
---
 Documentation/prctl/seccomp_filter.txt |   14 
 include/linux/seccomp.h|7 
 include/uapi/linux/prctl.h |6 
 include/uapi/linux/seccomp.h   |6 
 kernel/seccomp.c   |   60 
 kernel/sys.c   |3 ++
 6 files changed, 96 insertions(+)

diff --git a/Documentation/prctl/seccomp_filter.txt 
b/Documentation/prctl/seccomp_filter.txt
index 1e469ef75778..ea6bb5576fdc 100644
--- a/Documentation/prctl/seccomp_filter.txt
+++ b/Documentation/prctl/seccomp_filter.txt
@@ -223,3 +223,17 @@ Note that modern systems are unlikely to use vsyscalls at 
all -- they
 are a legacy feature and they are considerably slower than standard
 syscalls.  New code will use the vDSO, and vDSO-issued system calls
 are indistinguishable from normal system calls.
+
+
+
+Extensions
+--
+Additional seccomp extensions are available through prctl using
+PR_SECCOMP_EXT, with the extension as the following argument.
+
+prctl(PR_SECCOMP_EXT, SECCOMP_EXT_ACT_FILTER, flags, prog):
+   Attach filter, with flags.
+
+   This is the same as prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, prog)
+   except with the addition of optional "flags" argument. No flags
+   are currently recognized.
diff --git a/include/linux/seccomp.h b/include/linux/seccomp.h
index d05f1f1b8b10..a34a6bc76d3d 100644
--- a/include/linux/seccomp.h
+++ b/include/linux/seccomp.h
@@ -82,6 +82,8 @@ static inline int seccomp_mode(struct seccomp *s)
 #ifdef CONFIG_SECCOMP_FILTER
 extern void put_seccomp_filter(struct task_struct *tsk);
 extern void get_seccomp_filter(struct task_struct *tsk);
+extern long prctl_seccomp_ext(unsigned long, unsigned long,
+ unsigned long, unsigned long);
 #else  /* CONFIG_SECCOMP_FILTER */
 static inline void put_seccomp_filter(struct task_struct *tsk)
 {
@@ -91,5 +93,10 @@ static inline void get_seccomp_filter(struct task_struct 
*tsk)
 {
return;
 }
+static inline long prctl_seccomp_ext(unsigned long arg2, unsigned long arg3,
+unsigned long arg4, unsigned long arg5)
+{
+   return -EINVAL;
+}
 #endif /* CONFIG_SECCOMP_FILTER */
 #endif /* _LINUX_SECCOMP_H */
diff --git a/include/uapi/linux/prctl.h b/include/uapi/linux/prctl.h
index 58afc04c107e..ac758ed72495 100644
--- a/include/uapi/linux/prctl.h
+++ b/include/uapi/linux/prctl.h
@@ -152,4 +152,10 @@
 #define PR_SET_THP_DISABLE 41
 #define PR_GET_THP_DISABLE 42
 
+/*
+ * Access seccomp extensions
+ * See Documentation/prctl/seccomp_filter.txt for more details.
+ */
+#define PR_SECCOMP_EXT 43
+
 #endif /* _LINUX_PRCTL_H */
diff --git a/include/uapi/linux/seccomp.h b/include/uapi/linux/seccomp.h
index ac2dc9f72973..d7ad626c684d 100644
--- a/include/uapi/linux/seccomp.h
+++ b/include/uapi/linux/seccomp.h
@@ -10,6 +10,12 @@
 #define SECCOMP_MODE_STRICT1 /* uses hard-coded filter. */
 #define SECCOMP_MODE_FILTER2 /* uses user-supplied filter. */
 
+/* Valid extension types as arg2 for prctl(PR_SECCOMP_EXT) */
+#define SECCOMP_EXT_ACT1
+
+/* Valid extension actions as arg3 to prctl(PR_SECCOMP_EXT, SECCOMP_EXT_ACT) */
+#define SECCOMP_EXT_ACT_FILTER 1 /* apply seccomp-bpf filter with flags */
+
 /*
  * All BPF programs must return a 32-bit value.
  * The bottom 16-bits are for optional return data.
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 23e7a05c3868..6b582f73c5de 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -30,6 +30,8 @@
 #include 
 #include 
 
+static long _seccomp_set_mode(unsigned long mode, char * __user filter);
+
 /**
  * struct seccomp_filter - container for seccomp BPF programs
  *
@@ -310,6 +312,47 @@ out:
return ret;
 }
 
+/**
+ * seccomp_act_filter: attach filter with additional flags
+ * @flags:  flags from SECCOMP_FILTER_* to change behavior
+ * @filter: struct sock_fprog for use with SECCOMP_MODE_FILTER
+ *
+ * Return 0 on success, -ve on error.
+ */
+static long seccomp_act_filter(unsigned long flags, char * __user filter)
+{
+   long ret;
+
+   /* No flags currently recognized. */
+   if (flags != 0)
+   return -EINVAL;
+
+   seccomp_lock(current);
+   ret = _seccomp_set_mode(SECCOMP_MODE_FILTER, filter);
+   seccomp_unlock(current);
+
+   return ret;
+}
+
+/**
+ * seccomp_extended_action: performs the 

[PATCH v3 3/5] seccomp: move no_new_privs into seccomp

2014-04-17 Thread Kees Cook
Since seccomp transitions between threads requires updates to the
no_new_privs flag to be atomic, this creates accessors for it. In the
case of seccomp being built into the kernel, the flag is moved it into
seccomp struct where it can be updated safely.

Signed-off-by: Kees Cook 
---
 fs/exec.c  |4 ++--
 include/linux/sched.h  |   22 ++
 include/linux/seccomp.h|4 
 kernel/seccomp.c   |2 +-
 kernel/sys.c   |4 ++--
 security/apparmor/domain.c |4 ++--
 6 files changed, 33 insertions(+), 7 deletions(-)

diff --git a/fs/exec.c b/fs/exec.c
index 476f3ebf437e..c72f9f6f66f3 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1233,7 +1233,7 @@ static void check_unsafe_exec(struct linux_binprm *bprm)
 * This isn't strictly necessary, but it makes it harder for LSMs to
 * mess up.
 */
-   if (current->no_new_privs)
+   if (task_no_new_privs(current))
bprm->unsafe |= LSM_UNSAFE_NO_NEW_PRIVS;
 
t = p;
@@ -1271,7 +1271,7 @@ int prepare_binprm(struct linux_binprm *bprm)
bprm->cred->egid = current_egid();
 
if (!(bprm->file->f_path.mnt->mnt_flags & MNT_NOSUID) &&
-   !current->no_new_privs &&
+   !task_no_new_privs(current) &&
kuid_has_mapping(bprm->cred->user_ns, inode->i_uid) &&
kgid_has_mapping(bprm->cred->user_ns, inode->i_gid)) {
/* Set-uid? */
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 50a21e527eb2..cd8e59bb62a5 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1259,8 +1259,10 @@ struct task_struct {
 * execve */
unsigned in_iowait:1;
 
+#ifndef CONFIG_SECCOMP
/* task may not gain privileges */
unsigned no_new_privs:1;
+#endif
 
/* Revert to default priority/policy when forking */
unsigned sched_reset_on_fork:1;
@@ -2493,9 +2495,29 @@ static inline void seccomp_unlock(struct task_struct *p)
 {
spin_unlock(>seccomp.lock);
 }
+
+static inline bool task_no_new_privs(struct task_struct *p)
+{
+   return test_bit(SECCOMP_FLAG_NO_NEW_PRIVS, >seccomp.flags);
+}
+
+static inline int task_set_no_new_privs(struct task_struct *p)
+{
+   set_bit(SECCOMP_FLAG_NO_NEW_PRIVS, >seccomp.flags);
+   return 0;
+}
 #else
 static inline void seccomp_lock(struct task_struct *p) { }
 static inline void seccomp_unlock(struct task_struct *p) { }
+static inline bool task_no_new_privs(struct task_struct *p)
+{
+   return p->no_new_privs;
+}
+static inline int task_set_no_new_privs(struct task_struct *p)
+{
+   p->no_new_privs = 1;
+   return 0;
+}
 #endif
 
 extern struct sighand_struct *__lock_task_sighand(struct task_struct *tsk,
diff --git a/include/linux/seccomp.h b/include/linux/seccomp.h
index c47be00e8ffb..d05f1f1b8b10 100644
--- a/include/linux/seccomp.h
+++ b/include/linux/seccomp.h
@@ -17,6 +17,7 @@ struct seccomp_filter;
  * @lock:  held when making changes to avoid thread races.
  * @filter: must always point to a valid seccomp-filter or NULL as it is
  *  accessed without locking during system call entry.
+ * @flags: flags under write lock
  *
  *  @filter must only be accessed from the context of current as there
  *  is no locking.
@@ -25,8 +26,11 @@ struct seccomp {
int mode;
spinlock_t lock;
struct seccomp_filter *filter;
+   unsigned long flags;
 };
 
+#define SECCOMP_FLAG_NO_NEW_PRIVS  0
+
 extern int __secure_computing(int);
 static inline int secure_computing(int this_syscall)
 {
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 440dc2c213ac..23e7a05c3868 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -225,7 +225,7 @@ static long seccomp_attach_filter(struct sock_fprog *fprog)
 * This avoids scenarios where unprivileged tasks can affect the
 * behavior of privileged children.
 */
-   if (!current->no_new_privs &&
+   if (!task_no_new_privs(current) &&
security_capable_noaudit(current_cred(), current_user_ns(),
 CAP_SYS_ADMIN) != 0)
return -EACCES;
diff --git a/kernel/sys.c b/kernel/sys.c
index fba0f29401ea..262919a8a7ac 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1990,12 +1990,12 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, 
arg2, unsigned long, arg3,
if (arg2 != 1 || arg3 || arg4 || arg5)
return -EINVAL;
 
-   current->no_new_privs = 1;
+   error = task_set_no_new_privs(current);
break;
case PR_GET_NO_NEW_PRIVS:
if (arg2 || arg3 || arg4 || arg5)
return -EINVAL;
-   return current->no_new_privs ? 1 : 0;
+   return task_no_new_privs(current) ? 1 : 0;
case PR_GET_THP_DISABLE:
if (arg2 || arg3 || arg4 || arg5)
   

[PATCH v3 2/5] seccomp: create locked helper for setting mode

2014-04-17 Thread Kees Cook
For multiple mode-setting callers, we will need a helper to perform the
sanity-checking and finalization logic while the seccomp lock is held.

Signed-off-by: Kees Cook 
---
 kernel/seccomp.c |   42 +-
 1 file changed, 25 insertions(+), 17 deletions(-)

diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 6d61a0b5080c..440dc2c213ac 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -462,26 +462,11 @@ long prctl_get_seccomp(void)
return current->seccomp.mode;
 }
 
-/**
- * prctl_set_seccomp: configures current->seccomp.mode
- * @seccomp_mode: requested mode to use
- * @filter: optional struct sock_fprog for use with SECCOMP_MODE_FILTER
- *
- * This function may be called repeatedly with a @seccomp_mode of
- * SECCOMP_MODE_FILTER to install additional filters.  Every filter
- * successfully installed will be evaluated (in reverse order) for each system
- * call the task makes.
- *
- * Once current->seccomp.mode is non-zero, it may not be changed.
- *
- * Returns 0 on success or -EINVAL on failure.
- */
-long prctl_set_seccomp(unsigned long seccomp_mode, char __user *filter)
+/* Expects to be called under seccomp lock. */
+static long _seccomp_set_mode(unsigned long seccomp_mode, char * __user filter)
 {
long ret = -EINVAL;
 
-   seccomp_lock(current);
-
if (current->seccomp.mode &&
current->seccomp.mode != seccomp_mode)
goto out;
@@ -507,6 +492,29 @@ long prctl_set_seccomp(unsigned long seccomp_mode, char 
__user *filter)
current->seccomp.mode = seccomp_mode;
set_thread_flag(TIF_SECCOMP);
 out:
+   return ret;
+}
+
+/**
+ * prctl_set_seccomp: configures current->seccomp.mode
+ * @seccomp_mode: requested mode to use
+ * @filter: optional struct sock_fprog for use with SECCOMP_MODE_FILTER
+ *
+ * This function may be called repeatedly with a @seccomp_mode of
+ * SECCOMP_MODE_FILTER to install additional filters.  Every filter
+ * successfully installed will be evaluated (in reverse order) for each system
+ * call the task makes.
+ *
+ * Once current->seccomp.mode is non-zero, it may not be changed.
+ *
+ * Returns 0 on success or -EINVAL on failure.
+ */
+long prctl_set_seccomp(unsigned long seccomp_mode, char __user *filter)
+{
+   long ret;
+
+   seccomp_lock(current);
+   ret = _seccomp_set_mode(seccomp_mode, filter);
seccomp_unlock(current);
return ret;
 }
-- 
1.7.9.5

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


[PATCH v3 0/5] seccomp: add PR_SECCOMP_EXT and SECCOMP_EXT_ACT_TSYNC

2014-04-17 Thread Kees Cook
This adds the ability for threads to request seccomp filter
synchronization across their thread group (either at filter attach time
or later). To support this, seccomp locking on writes is introduced,
along with refactoring of no_new_privs. Races with thread creation are
handled via the tasklist_list.

I think all the concerns raised during the discussion[1] of the first
version of this patch have been addressed. However, the races involved
have tricked me before. :)

Thanks!

-Kees

[1] https://lkml.org/lkml/2014/1/13/795

v3:
 - added SECCOMP_EXT_ACT_FILTER for new filter install options
v2:
 - reworked to avoid clone races

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v3 1/5] seccomp: introduce writer locking

2014-04-17 Thread Kees Cook
Normally, task_struck.seccomp.filter is only ever read or modified by
the task that owns it (current). This property aids in fast access
during system call filtering as read access is lockless.

Updating the pointer from another task, however, opens up race
conditions. To allow cross-task filter pointer updates, writes to the
seccomp fields are now protected via a spinlock.  Read access remains
lockless because pointer updates themselves are atomic.  However, writes
(or cloning) often entail additional checking (like maximum instruction
counts) which require locking to perform safely.

In the case of cloning threads, the child is invisible to the system
until it enters the task list. To make sure a child can't be cloned
from a thread and left in a prior state, seccomp duplication is moved
under the tasklist_lock. Then parent and child are certain have the same
seccomp state when they exit the lock.

Based on patches by Will Drewry.

Signed-off-by: Kees Cook 
---
 include/linux/init_task.h |8 
 include/linux/sched.h |   18 ++
 include/linux/seccomp.h   |6 --
 kernel/fork.c |   33 -
 kernel/seccomp.c  |   13 -
 5 files changed, 70 insertions(+), 8 deletions(-)

diff --git a/include/linux/init_task.h b/include/linux/init_task.h
index 6df7f9fe0d01..e2370ec3102b 100644
--- a/include/linux/init_task.h
+++ b/include/linux/init_task.h
@@ -154,6 +154,13 @@ extern struct task_group root_task_group;
 # define INIT_VTIME(tsk)
 #endif
 
+#ifdef CONFIG_SECCOMP
+# define INIT_SECCOMP(tsk) \
+   .seccomp.lock   = __SPIN_LOCK_UNLOCKED(tsk.seccomp.lock),
+#else
+# define INIT_SECCOMP(tsk)
+#endif
+
 #define INIT_TASK_COMM "swapper"
 
 #ifdef CONFIG_RT_MUTEXES
@@ -234,6 +241,7 @@ extern struct task_group root_task_group;
INIT_CPUSET_SEQ(tsk)\
INIT_RT_MUTEXES(tsk)\
INIT_VTIME(tsk) \
+   INIT_SECCOMP(tsk)   \
 }
 
 
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 25f54c79f757..50a21e527eb2 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2480,6 +2480,24 @@ static inline void task_unlock(struct task_struct *p)
spin_unlock(>alloc_lock);
 }
 
+#ifdef CONFIG_SECCOMP
+/*
+ * Protects changes to ->seccomp
+ */
+static inline void seccomp_lock(struct task_struct *p)
+{
+   spin_lock(>seccomp.lock);
+}
+
+static inline void seccomp_unlock(struct task_struct *p)
+{
+   spin_unlock(>seccomp.lock);
+}
+#else
+static inline void seccomp_lock(struct task_struct *p) { }
+static inline void seccomp_unlock(struct task_struct *p) { }
+#endif
+
 extern struct sighand_struct *__lock_task_sighand(struct task_struct *tsk,
unsigned long *flags);
 
diff --git a/include/linux/seccomp.h b/include/linux/seccomp.h
index 4054b0994071..c47be00e8ffb 100644
--- a/include/linux/seccomp.h
+++ b/include/linux/seccomp.h
@@ -14,14 +14,16 @@ struct seccomp_filter;
  *
  * @mode:  indicates one of the valid values above for controlled
  * system calls available to a process.
- * @filter: The metadata and ruleset for determining what system calls
- *  are allowed for a task.
+ * @lock:  held when making changes to avoid thread races.
+ * @filter: must always point to a valid seccomp-filter or NULL as it is
+ *  accessed without locking during system call entry.
  *
  *  @filter must only be accessed from the context of current as there
  *  is no locking.
  */
 struct seccomp {
int mode;
+   spinlock_t lock;
struct seccomp_filter *filter;
 };
 
diff --git a/kernel/fork.c b/kernel/fork.c
index 54a8d26f612f..b33f886fe3a1 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -315,6 +315,15 @@ static struct task_struct *dup_task_struct(struct 
task_struct *orig)
goto free_ti;
 
tsk->stack = ti;
+#ifdef CONFIG_SECCOMP
+   /*
+* We must handle setting up seccomp filters once we're under
+* the tasklist_lock in case orig has changed between now and
+* then. Until then, filter must be NULL to avoid messing up
+* the usage counts on the error path calling free_task.
+*/
+   tsk->seccomp.filter = NULL;
+#endif
 
setup_thread_stack(tsk, orig);
clear_user_return_notifier(tsk);
@@ -1081,6 +1090,23 @@ static int copy_signal(unsigned long clone_flags, struct 
task_struct *tsk)
return 0;
 }
 
+static void copy_seccomp(struct task_struct *p)
+{
+#ifdef CONFIG_SECCOMP
+   /* Child lock not needed since it is not yet in tasklist. */
+   seccomp_lock(current);
+
+   get_seccomp_filter(current);
+   p->seccomp = current->seccomp;
+   

[PATCH v3 5/5] seccomp: add SECCOMP_EXT_ACT_TSYNC and SECCOMP_FILTER_TSYNC

2014-04-17 Thread Kees Cook
Applying restrictive seccomp filter programs to large or diverse
codebases often requires handling threads which may be started early in
the process lifetime (e.g., by code that is linked in). While it is
possible to apply permissive programs prior to process start up, it is
difficult to further restrict the kernel ABI to those threads after that
point.

This change adds a new seccomp extension action for synchronizing thread
group seccomp filters and a prctl() for accessing that functionality,
as well as a flag for SECCOMP_EXT_ACT_FILTER to perform sync at filter
installation time.

When calling prctl(PR_SECCOMP_EXT, SECCOMP_EXT_ACT_FILTER, flags, filter)
with flags containing SECCOMP_FILTER_TSYNC, or when calling
prctl(PR_SECCOMP_EXT, SECCOMP_EXT_ACT_TSYNC, 0, 0), it will attempt to
synchronize all threads in current's threadgroup to its seccomp
filter program. This is possible iff all threads are using a filter that
is an ancestor to the filter current is attempting to synchronize to. NULL
filters (where the task is running as SECCOMP_MODE_NONE) are also treated
as ancestors allowing threads to be transitioned into SECCOMP_MODE_FILTER.
On success, 0 is returned. On failure, the pid of one of the failing
threads will be returned, with as many filters installed as possible.

The race conditions are against another thread calling TSYNC, another
thread performing a clone, and another thread changing its filter. The
seccomp write lock is sufficient for these cases, though the clone
case is assisted by the tasklist_lock so that new threads must have a
duplicate of its parent seccomp state when it appears on the tasklist.

Based on patches by Will Drewry.

Suggested-by: Julien Tinnes 
Signed-off-by: Kees Cook 
---
 Documentation/prctl/seccomp_filter.txt |   20 +-
 include/uapi/linux/seccomp.h   |4 ++
 kernel/seccomp.c   |  104 ++--
 3 files changed, 122 insertions(+), 6 deletions(-)

diff --git a/Documentation/prctl/seccomp_filter.txt 
b/Documentation/prctl/seccomp_filter.txt
index ea6bb5576fdc..7bae09f20338 100644
--- a/Documentation/prctl/seccomp_filter.txt
+++ b/Documentation/prctl/seccomp_filter.txt
@@ -235,5 +235,21 @@ prctl(PR_SECCOMP_EXT, SECCOMP_EXT_ACT_FILTER, flags, prog):
Attach filter, with flags.
 
This is the same as prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, prog)
-   except with the addition of optional "flags" argument. No flags
-   are currently recognized.
+   except with the addition of optional "flags" argument:
+
+   SECCOMP_FILTER_TSYNC:
+   After installing filter, perform threadgroup sync, as
+   described below for SECCOMP_EXT_ACT_TSYNC.
+
+prctl(PR_SECCOMP_EXT, SECCOMP_EXT_ACT_TSYNC, 0, 0):
+   Thread synchronization.
+
+   The current thread requests to synchronize all threads in current's
+   threadgroup to its seccomp filter program. This is possible iff all
+   threads are using a filter that is an ancestor to the filter current
+   is attempting to synchronize to, or the thread has not yet entered
+   seccomp.
+
+   On success, 0 is returned. On failure, all synchronizable threads
+   will have been synchronized, and the pid of any of the failing
+   threads will be returned.
diff --git a/include/uapi/linux/seccomp.h b/include/uapi/linux/seccomp.h
index d7ad626c684d..7f4431b90fd4 100644
--- a/include/uapi/linux/seccomp.h
+++ b/include/uapi/linux/seccomp.h
@@ -15,6 +15,10 @@
 
 /* Valid extension actions as arg3 to prctl(PR_SECCOMP_EXT, SECCOMP_EXT_ACT) */
 #define SECCOMP_EXT_ACT_FILTER 1 /* apply seccomp-bpf filter with flags */
+#define SECCOMP_EXT_ACT_TSYNC  2 /* synchronize threadgroup filters */
+
+/* Flags for prctl arg4 when calling SECCOMP_EXT_ACT_FILTER */
+#define SECCOMP_FILTER_TSYNC   1 /* synchronize threadgroup to filter */
 
 /*
  * All BPF programs must return a 32-bit value.
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 6b582f73c5de..8b12ae826122 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -24,6 +24,7 @@
 #ifdef CONFIG_SECCOMP_FILTER
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -198,6 +199,91 @@ static u32 seccomp_run_filters(int syscall)
return ret;
 }
 
+/* Returns 1 if the candidate is an ancestor. */
+static int is_ancestor(struct seccomp_filter *candidate,
+  struct seccomp_filter *child)
+{
+   /* NULL is the root ancestor. */
+   if (candidate == NULL)
+   return 1;
+   for (; child; child = child->prev)
+   if (child == candidate)
+   return 1;
+   return 0;
+}
+
+/* Expects locking and sync suitability to have been done already. */
+static void seccomp_sync_thread(struct task_struct *caller,
+   struct task_struct *thread)
+{
+   /* Get a task reference for the new leaf node. */
+   get_seccomp_filter(caller);
+   /*
+* 

[PATCH v2 0/4] sysctl: fix incorrect write position handling

2014-04-17 Thread Kees Cook
When writing to a sysctl string, each write, regardless of VFS position,
began writing the string from the start. This meant the contents of
the last write to the sysctl controlled the string contents instead of
the first.

This misbehavior was featured in an exploit against Chrome OS. While it's
not in itself a vulnerability, it's a weirdness that isn't on the mind
of most auditors: "This filter looks correct, the first line written
would not be meaningful to sysctl" doesn't apply here, since the size
of the write and the contents of the final write are what matter when
writing to procfs.

For the paranoid, introduce CONFIG_PROC_SYSCTL_STRICT_WRITES to
change the behavior to track file position most strictly.

Thanks,

-Kees

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/4] sysctl: refactor sysctl string writing logic

2014-04-17 Thread Kees Cook
Consolidate buffer length checking with new-line/end-of-line checking.
Additionally, instead of reading user memory twice, just do the assignment
during the loop.

Signed-off-by: Kees Cook 
---
 kernel/sysctl.c |   11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index e7ff80a73c44..0e08103a69c8 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1712,21 +1712,18 @@ static int _proc_do_string(char *data, int maxlen, int 
write,
}
 
if (write) {
+   /* Start writing from beginning of buffer. */
len = 0;
+   *ppos += *lenp;
p = buffer;
-   while (len < *lenp) {
+   while ((p - buffer) < *lenp && len < maxlen - 1) {
if (get_user(c, p++))
return -EFAULT;
if (c == 0 || c == '\n')
break;
-   len++;
+   data[len++] = c;
}
-   if (len >= maxlen)
-   len = maxlen-1;
-   if(copy_from_user(data, buffer, len))
-   return -EFAULT;
data[len] = 0;
-   *ppos += *lenp;
} else {
len = strlen(data);
if (len > maxlen)
-- 
1.7.9.5

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


[PATCH v2 4/4] test: validate CONFIG_PROC_SYSCTL_STRICT_WRITES

2014-04-17 Thread Kees Cook
This adds several behavioral tests to sysctl string and number writing
to detect unexpected cases that behaved differently when the option
CONFIG_PROC_SYSCTL_STRICT_WRITES was unset.

[ original ]
root@localhost:~# make test_num
== Testing sysctl behavior against /proc/sys/kernel/domainname ==
Writing test file ... ok
Checking sysctl is not set to test value ... ok
Writing sysctl from shell ... ok
Resetting sysctl to original value ... ok
Writing entire sysctl in single write ... ok
Writing middle of sysctl after synchronized seek ... FAIL
Writing beyond end of sysctl ... FAIL
Writing sysctl with multiple long writes ... FAIL
Writing entire sysctl in short writes ... FAIL
Writing middle of sysctl after unsynchronized seek ... ok
Checking sysctl maxlen is at least 65 ... ok
Checking sysctl keeps original string on overflow append ... FAIL
Checking sysctl stays NULL terminated on write ... ok
Checking sysctl stays NULL terminated on overwrite ... ok
make: *** [test_num] Error 1
root@localhost:~# make test_string
== Testing sysctl behavior against /proc/sys/vm/swappiness ==
Writing test file ... ok
Checking sysctl is not set to test value ... ok
Writing sysctl from shell ... ok
Resetting sysctl to original value ... ok
Writing entire sysctl in single write ... ok
Writing middle of sysctl after synchronized seek ... FAIL
Writing beyond end of sysctl ... FAIL
Writing sysctl with multiple long writes ... ok
make: *** [test_string] Error 1

[ with CONFIG_PROC_SYSCTL_STRICT_WRITES ]
root@localhost:~# make run_tests
== Testing sysctl behavior against /proc/sys/kernel/domainname ==
Writing test file ... ok
Checking sysctl is not set to test value ... ok
Writing sysctl from shell ... ok
Resetting sysctl to original value ... ok
Writing entire sysctl in single write ... ok
Writing middle of sysctl after synchronized seek ... ok
Writing beyond end of sysctl ... ok
Writing sysctl with multiple long writes ... ok
Writing entire sysctl in short writes ... ok
Writing middle of sysctl after unsynchronized seek ... ok
Checking sysctl maxlen is at least 65 ... ok
Checking sysctl keeps original string on overflow append ... ok
Checking sysctl stays NULL terminated on write ... ok
Checking sysctl stays NULL terminated on overwrite ... ok
== Testing sysctl behavior against /proc/sys/vm/swappiness ==
Writing test file ... ok
Checking sysctl is not set to test value ... ok
Writing sysctl from shell ... ok
Resetting sysctl to original value ... ok
Writing entire sysctl in single write ... ok
Writing middle of sysctl after synchronized seek ... ok
Writing beyond end of sysctl ... ok
Writing sysctl with multiple long writes ... ok

Signed-off-by: Kees Cook 
---
 tools/testing/selftests/Makefile|1 +
 tools/testing/selftests/sysctl/Makefile |   19 
 tools/testing/selftests/sysctl/common_tests |  109 +++
 tools/testing/selftests/sysctl/run_numerictests |   10 +++
 tools/testing/selftests/sysctl/run_stringtests  |   77 
 5 files changed, 216 insertions(+)
 create mode 100644 tools/testing/selftests/sysctl/Makefile
 create mode 100644 tools/testing/selftests/sysctl/common_tests
 create mode 100644 tools/testing/selftests/sysctl/run_numerictests
 create mode 100644 tools/testing/selftests/sysctl/run_stringtests

diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 32487ed18354..e66e710cc595 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -10,6 +10,7 @@ TARGETS += timers
 TARGETS += vm
 TARGETS += powerpc
 TARGETS += user
+TARGETS += sysctl
 
 all:
for TARGET in $(TARGETS); do \
diff --git a/tools/testing/selftests/sysctl/Makefile 
b/tools/testing/selftests/sysctl/Makefile
new file mode 100644
index ..3fc94dc83b44
--- /dev/null
+++ b/tools/testing/selftests/sysctl/Makefile
@@ -0,0 +1,19 @@
+# Makefile for sysctl selftests.
+# Expects CONFIG_PROC_SYSCTL_STRICT_WRITES=y.
+
+# No binaries, but make sure arg-less "make" doesn't trigger "run_tests".
+all:
+
+# Allow specific tests to be selected.
+test_num:
+   @/bin/sh ./run_numerictests
+
+test_string:
+   @/bin/sh ./run_stringtests
+
+run_tests: all test_num test_string
+
+# Nothing to clean up.
+clean:
+
+.PHONY: all run_tests clean test_num test_string
diff --git a/tools/testing/selftests/sysctl/common_tests 
b/tools/testing/selftests/sysctl/common_tests
new file mode 100644
index ..17d534b1b7b4
--- /dev/null
+++ b/tools/testing/selftests/sysctl/common_tests
@@ -0,0 +1,109 @@
+#!/bin/sh
+
+TEST_FILE=$(mktemp)
+
+echo "== Testing sysctl behavior against ${TARGET} =="
+
+set_orig()
+{
+   echo "${ORIG}" > "${TARGET}"
+}
+
+set_test()
+{
+   echo "${TEST_STR}" > "${TARGET}"
+}
+
+verify()
+{
+   local seen
+   seen=$(cat "$1")
+   if [ "${seen}" != "${TEST_STR}" ]; then
+   return 1
+   fi
+   return 0
+}
+
+trap 'set_orig; rm -f "${TEST_FILE}"' EXIT
+
+rc=0
+
+echo -n 

  1   2   3   4   5   6   7   8   9   10   >