date:20130922

Hi Ted,

On Mon, 23 Sep 2013 14:39:24 +1000 Stephen Rothwell  
wrote:
>
> After merging the random tree, today's linux-next build (powerpc64
> allnoconfig) produced this warning:
> 
> In file included from include/linux/kernel.h:10:0,
>  from include/linux/sched.h:15,
>  from include/linux/utsname.h:5,
>  from drivers/char/random.c:238:
> drivers/char/random.c: In function 'add_interrupt_randomness':
> include/linux/bitops.h:96:2: warning: 'input[3]' may be used uninitialized in 
> this function [-Wmaybe-uninitialized]
>   return (word << shift) | (word >> (32 - shift));
>   ^
> drivers/char/random.c:827:10: note: 'input[3]' was declared here
>   __u32   input[4], cycles = random_get_entropy();
>   ^
> In file included from include/linux/kernel.h:10:0,
>  from include/linux/sched.h:15,
>  from include/linux/utsname.h:5,
>  from drivers/char/random.c:238:
> include/linux/bitops.h:96:2: warning: 'input[2]' may be used uninitialized in 
> this function [-Wmaybe-uninitialized]
>   return (word << shift) | (word >> (32 - shift));
>   ^
> drivers/char/random.c:827:10: note: 'input[2]' was declared here
>   __u32   input[4], cycles = random_get_entropy();
>   ^
> 
> Probably introduced by commit d5693ae494f2 ("random: speed up the
> fast_mix function by a factor of four").

i386 defconfig produces similar (to make testing easier).

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


pgp6OJ6VlpmiH.pgp
Description: PGP signature

Re: [RFC GIT PULL] softirq: Consolidation and stack overrun fix

2013-09-22 Thread Benjamin Herrenschmidt

On Sun, 2013-09-22 at 07:45 +1000, Benjamin Herrenschmidt wrote:
> What I *can* do that would help I suppose would be to switch to the irq
> stack before irq_enter/exit which would at least mean that softirq would
> run from the top of the irq stack which is better than the current
> situation.
> 
> I'm fact I'll whip up a quick fix see if that might be enough of a band
> aid for RHEL7.

OK I've done that, it seems to work so far. Heads up guys: i386 and sparc
at least seem to need the same treatment. I haven't looked at others except
ARM which doesn't seem to have irq stacks to begin with.

We can also instead apply Fred's series to put back in the switch to the
softirq stack since this is actually a regression , but then, arguably,
making sure irq_exit() is called off the irq stack is better and means
we do one instead of two stack switches.

Fred: Maybe revert partially under an arch #define/Kconfig so we can get
the best of both worlds ?

Cheers,
Ben.

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

linux-next: build warning after merge of the random tree

Hi Ted,

After merging the random tree, today's linux-next build (powerpc64
allnoconfig) produced this warning:

In file included from include/linux/kernel.h:10:0,
 from include/linux/sched.h:15,
 from include/linux/utsname.h:5,
 from drivers/char/random.c:238:
drivers/char/random.c: In function 'add_interrupt_randomness':
include/linux/bitops.h:96:2: warning: 'input[3]' may be used uninitialized in 
this function [-Wmaybe-uninitialized]
  return (word << shift) | (word >> (32 - shift));
  ^
drivers/char/random.c:827:10: note: 'input[3]' was declared here
  __u32   input[4], cycles = random_get_entropy();
  ^
In file included from include/linux/kernel.h:10:0,
 from include/linux/sched.h:15,
 from include/linux/utsname.h:5,
 from drivers/char/random.c:238:
include/linux/bitops.h:96:2: warning: 'input[2]' may be used uninitialized in 
this function [-Wmaybe-uninitialized]
  return (word << shift) | (word >> (32 - shift));
  ^
drivers/char/random.c:827:10: note: 'input[2]' was declared here
  __u32   input[4], cycles = random_get_entropy();
  ^

Probably introduced by commit d5693ae494f2 ("random: speed up the
fast_mix function by a factor of four").

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


pgpvoTL92RuUs.pgp
Description: PGP signature

[PATCH] powerpc/irq: Run softirqs off the top of the irq stack

2013-09-22 Thread Benjamin Herrenschmidt

Nowadays, irq_exit() calls __do_softirq() pretty much directly
instead of calling do_softirq() which switches to the decicated
softirq stack.

This has lead to observed stack overflows on powerpc since we call
irq_enter() and irq_exit() outside of the scope that switches to
the irq stack.

This fixes it by moving the stack switching up a level, making
irq_enter() and irq_exit() run off the irq stack.

Signed-off-by: Benjamin Herrenschmidt 
---

This is the "band aid" discussed so far for the stack overflow
problem for powerpc. I assume sparc and i386 at least need
something similar (I had a quick look at ARM and it doesn't
seem to have irq stacks at all).

Unless objection in the next day or so, I intend to send that to
Linus and to -stable ASAP.

 arch/powerpc/include/asm/irq.h |  4 +-
 arch/powerpc/kernel/irq.c  | 99 ++
 arch/powerpc/kernel/misc_32.S  |  9 ++--
 arch/powerpc/kernel/misc_64.S  | 10 ++---
 4 files changed, 62 insertions(+), 60 deletions(-)

diff --git a/arch/powerpc/include/asm/irq.h b/arch/powerpc/include/asm/irq.h
index 0e40843..41f13ce 100644
--- a/arch/powerpc/include/asm/irq.h
+++ b/arch/powerpc/include/asm/irq.h
@@ -69,9 +69,9 @@ extern struct thread_info *softirq_ctx[NR_CPUS];
 
 extern void irq_ctx_init(void);
 extern void call_do_softirq(struct thread_info *tp);
-extern int call_handle_irq(int irq, void *p1,
-  struct thread_info *tp, void *func);
+extern void call_do_irq(struct pt_regs *regs, struct thread_info *tp);
 extern void do_IRQ(struct pt_regs *regs);
+extern void __do_irq(struct pt_regs *regs);
 
 int irq_choose_cpu(const struct cpumask *mask);
 
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index c69440c..0c9646f 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -443,46 +443,7 @@ void migrate_irqs(void)
 
 static inline void handle_one_irq(unsigned int irq)
 {
-   struct thread_info *curtp, *irqtp;
-   unsigned long saved_sp_limit;
-   struct irq_desc *desc;
-
-   desc = irq_to_desc(irq);
-   if (!desc)
-   return;
-
-   /* Switch to the irq stack to handle this */
-   curtp = current_thread_info();
-   irqtp = hardirq_ctx[smp_processor_id()];
-
-   if (curtp == irqtp) {
-   /* We're already on the irq stack, just handle it */
-   desc->handle_irq(irq, desc);
-   return;
-   }
-
-   saved_sp_limit = current->thread.ksp_limit;
-
-   irqtp->task = curtp->task;
-   irqtp->flags = 0;
-
-   /* Copy the softirq bits in preempt_count so that the
-* softirq checks work in the hardirq context. */
-   irqtp->preempt_count = (irqtp->preempt_count & ~SOFTIRQ_MASK) |
-  (curtp->preempt_count & SOFTIRQ_MASK);
 
-   current->thread.ksp_limit = (unsigned long)irqtp +
-   _ALIGN_UP(sizeof(struct thread_info), 16);
-
-   call_handle_irq(irq, desc, irqtp, desc->handle_irq);
-   current->thread.ksp_limit = saved_sp_limit;
-   irqtp->task = NULL;
-
-   /* Set any flag that may have been set on the
-* alternate stack
-*/
-   if (irqtp->flags)
-   set_bits(irqtp->flags, >flags);
 }
 
 static inline void check_stack_overflow(void)
@@ -501,9 +462,9 @@ static inline void check_stack_overflow(void)
 #endif
 }
 
-void do_IRQ(struct pt_regs *regs)
+void __do_irq(struct pt_regs *regs)
 {
-   struct pt_regs *old_regs = set_irq_regs(regs);
+   struct irq_desc *desc;
unsigned int irq;
 
irq_enter();
@@ -519,18 +480,64 @@ void do_IRQ(struct pt_regs *regs)
 */
irq = ppc_md.get_irq();
 
-   /* We can hard enable interrupts now */
+   /* We can hard enable interrupts now to allow perf interrupts */
may_hard_irq_enable();
 
/* And finally process it */
-   if (irq != NO_IRQ)
-   handle_one_irq(irq);
-   else
+   if (unlikely(irq == NO_IRQ))
__get_cpu_var(irq_stat).spurious_irqs++;
+   else {
+   desc = irq_to_desc(irq);
+   if (likely(desc))
+   desc->handle_irq(irq, desc);
+   }
 
trace_irq_exit(regs);
 
irq_exit();
+}
+
+void do_IRQ(struct pt_regs *regs)
+{
+   struct pt_regs *old_regs = set_irq_regs(regs);
+   struct thread_info *curtp, *irqtp;
+   unsigned long saved_sp_limit;
+
+   /* Switch to the irq stack to handle this */
+   curtp = current_thread_info();
+   irqtp = hardirq_ctx[raw_smp_processor_id()];
+
+   /* Already there ? */
+   if (unlikely(curtp == irqtp)) {
+   __do_irq(regs);
+   set_irq_regs(old_regs);
+   return;
+   }
+
+   /* Adjust the stack limit */
+   saved_sp_limit = current->thread.ksp_limit;
+   current->thread.ksp_limit = (unsigned long)irqtp +
+   _ALIGN_UP(sizeof(struct thread_info), 16);
+
+
+

Re: [PATCH, RFC 08/12] random: mix in architectural randomness earlier in extract_buf()

On Sun, Sep 22, 2013 at 09:11:58PM -0700, H. Peter Anvin wrote:
> 
> This doesn't mix in across the entire width of the hash (my original
> motivation for putting this at the end was to do it after the hash is
> folded in half -- which is still believe is cryptographically dubious,
> but please don't take my word for it, as I'm not a professional
> cryptographer.)  As such, this change should *probably* have
> EXTRACT_SIZE changed to 2*EXTRACT_SIZE (or simply "20") both in the for
> loop and in the declaration of the union.

Agreed, I'll make the change to "20" instead of EXTRACT_SIZE.

As far as whether or not folding the hash is cryptographically
dubious, we're not using the hash as part of a digital signature,
which is normally where cryptographers get antsy about truncating a
cryptographic hash value (since it effectively halves the length of
the hash, which thanks to the birthday paradox, makes it much easier
to find collisions).

However, in this case, we are reducing the amount of information which
is available to an attacker to infer the state of the pool.  The
"Linux Random Pool Revisited" paper had the following to say about it
in section 4.3:

"In addition, the folding operation helps in avoiding recognizable
patterns: the output of the hash function is not directly
recognizable from the output data.  For an optimal hash function,
this step would not be necessary and could be replaced by a simple
truncation."

If they had thought it was cryptographically dubious, they could have
said so --- but they didn't.

It's true that if we know for sure that SHA-1 is a perfect one-way
hash function (which is believed to be true, although there is no
proof of this, and the recent work by Xiaoyun Wang, Yiquin Lisa Yin,
and Hungbo Yu does not lead to any evidence for or against SHA-1's
status as a one-way function), the folding operation wouldn't be
necessary.  But the folding operation shouldn't hurt (except for
reducing the speed of generating random numbers, and it's currently
not a bottleneck), and in the case where it might not be a perfect
one-way function, it could help.

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

linux-next: build warning after merge of the block tree

Hi Jens,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

In file included from include/linux/kernel.h:13:0,
 from drivers/block/skd_main.c:19:
drivers/block/skd_main.c: In function 'skd_cons_skmsg':
drivers/block/skd_main.c:4562:33: warning: format '%u' expects argument of type 
'unsigned int', but argument 5 has type 'long unsigned int' [-Wformat=]
   (unsigned long) sizeof(struct skd_fitmsg_context) *
 ^
include/linux/printk.h:216:33: note: in definition of macro 'pr_err'
  printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
 ^
drivers/block/skd_main.c:4559:2: note: in expansion of macro 'VPRINTK'
  VPRINTK(skdev, "skmsg_table kzalloc, struct %u, count %u total %lu\n",
  ^

and several more.

Introduced by commit 0e2c4a3a6c0c ("drivers/block/skd_main.c: fix a few
things, disable on 32-bit"). sizeof() needs %zu to print, right?

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


pgpknFusvyZlm.pgp
Description: PGP signature

Re: [PATCH 1/2] staging: zram: fix handle_pending_slot_free() and zram_reset_device() race

2013-09-22 Thread Minchan Kim

On Tue, Sep 17, 2013 at 08:24:45PM +0300, Sergey Senozhatsky wrote:
> 
> Hello,
> 
> On (09/16/13 09:02), Minchan Kim wrote:
> > Hello Sergey,
> > 
> > Sorry for really slow response. I was really busy by internal works
> > and Thanks for pointing the BUG, Dan, Jerome and Sergey.
> > I read your threads roughly so I may miss something. If so, sorry
> > for that. Anyway I will put my opinion.
> > 
> > On Wed, Sep 11, 2013 at 02:12:50AM +0300, Sergey Senozhatsky wrote:
> > > Dan Carpenter noted that handle_pending_slot_free() is racy with
> > > zram_reset_device(). Take write init_lock in zram_slot_free(), thus
> > 
> > Right but "init_lock" is what I really want to remove.
> > Yes. It's just read-side lock so most of time it doesn't hurt us but it
> > makes code very complicated and deadlock prone so I'd like to replace
> > it with RCU. Yeah, It's off topic but just let me put my opinion in
> > future direction.
> > 
> > Abought the bug, how about moving flush_work below down_write(init_lock)?
> > zram_make_request is already closed by init_lock and we have a rule about
> > lock ordering as following so I don't see any problem.
> > 
> >   init_lock
> > zram->lock
> > 
> > > preventing any concurrent zram_slot_free(), zram_bvec_rw() or
> > > zram_reset_device(). This also allows to safely check zram->init_done
> > > in handle_pending_slot_free().
> > > 
> > > Initial intention was to minimze number of handle_pending_slot_free()
> > > call from zram_bvec_rw(), which were slowing down READ requests due to
> > > slot_free_lock spin lock. Jerome Marchand suggested to remove
> > > handle_pending_slot_free() from zram_bvec_rw().
> > > 
> > > Link: https://lkml.org/lkml/2013/9/9/172
> > > Signed-off-by: Sergey Senozhatsky 
> > > 
> > > ---
> > > 
> > >  drivers/staging/zram/zram_drv.c | 13 +
> > >  1 file changed, 5 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/drivers/staging/zram/zram_drv.c 
> > > b/drivers/staging/zram/zram_drv.c
> > > index 91d94b5..7a2d4de 100644
> > > --- a/drivers/staging/zram/zram_drv.c
> > > +++ b/drivers/staging/zram/zram_drv.c
> > > @@ -521,7 +521,8 @@ static void handle_pending_slot_free(struct zram 
> > > *zram)
> > >   while (zram->slot_free_rq) {
> > >   free_rq = zram->slot_free_rq;
> > >   zram->slot_free_rq = free_rq->next;
> > > - zram_free_page(zram, free_rq->index);
> > > + if (zram->init_done)
> > > + zram_free_page(zram, free_rq->index);
> > >   kfree(free_rq);
> > >   }
> > >   spin_unlock(>slot_free_lock);
> > > @@ -534,16 +535,13 @@ static int zram_bvec_rw(struct zram *zram, struct 
> > > bio_vec *bvec, u32 index,
> > >  
> > >   if (rw == READ) {
> > >   down_read(>lock);
> > > - handle_pending_slot_free(zram);
> > 
> > Read side is okay but actually I have a nitpick.
> > If someone poll a block in zram-swap device, he would see a block
> > has zero value suddenly although there was no I/O.(I don't want to argue
> > it's sane user or not, anyway) it never happens on real block device and
> > it never happens on zram-block device. Only it can happen zram-swap device.
> > And such behavior was there since we introduced swap_slot_free_notify.
> > (off-topic: I'd like to remove it because it makes tight coupling between
> > zram and swap and obviously, it was layering violation function)
> > so now, I don't have strong objection. 
> > 
> > The idea is to remove swap_slot_free_notify is to use frontswap when
> > user want to use zram as swap so zram can be notified when the block
> > lose the owner but still we should solve the mutex problem in notify
> > handler.
> > 
> > 
> > >   ret = zram_bvec_read(zram, bvec, index, offset, bio);
> > >   up_read(>lock);
> > >   } else {
> > >   down_write(>lock);
> > > - handle_pending_slot_free(zram);
> > 
> > Why did you remove this in write-side?
> > We can't expect when the work will trigger. It means the work could remove
> > valid block under the us.
> > 
> 
> 
> not sure I understand how.
> zram_slot_free() takes down_write(>init_lock) and zram_make_request() 
> takes
> down_read(>init_lock), thus zram_slot_free() can not concurrently work 
> with
> any RW requests. RW requests are under read() lock and zram_slot_free() is 
> under
> write() lock.

Let's consider example.
Swap subsystem asked to zram "A" block free from now by swap_slot_free_notify
but zram had been pended it without real freeing.
Swap reused "A" block for new data because "A" block was free but request pended
for a long time just handled and zram blindly free new data on the "A" block. :(
That's why we should handle pending free request right before zram-write.

Another try to optimize the lock overhead is to check the block is pending for 
free
right before zram_free_page in write path. If so, we should remove pending 
reuqest
from slot_free_rq list to prevent valid block later. But for that case, we need
more complex data structure

Re: [PATCH V3] pci: exynos: split into two parts such as Synopsys part and Exynos part

2013-09-22 Thread Pratyush Anand

Hi Kishon,


On Sun, Sep 22, 2013 at 07:16:34PM +0800, Kishon Vijay Abraham I wrote:
> Hi Arnd,
> 
> Thanks for replying :-)
> 
> On Sunday 22 September 2013 03:33 AM, Arnd Bergmann wrote:
> > On Saturday 21 September 2013, Kishon Vijay Abraham I wrote:
> >> {
> >> u32 val;
> >> void __iomem *val1;
> >> void __iomem *dbi_base = pp->dbi_base;
> >>
> >> /* Program viewport 0 : INBOUND : MEMORY*/
> >> val = PCIE_ATU_REGION_INBOUND | (0 & 0xF);
> >> dw_pcie_writel_rc(pp, val, dbi_base + PCIE_ATU_VIEWPORT);
> >> val1 = ioremap(0x8000, 0x5fff);
> > 
> > The ioremap here makes no sense at all, and I suspect it will fail anyway,
> > because you exhaust the vmalloc area size, but since the value is not
> > used anywhere, it won't matter.
> > 
> >> dw_pcie_writel_rc(pp, 0x8000, dbi_base + PCIE_ATU_LOWER_BASE);
> >> dw_pcie_writel_rc(pp, 0, dbi_base + PCIE_ATU_UPPER_BASE);
> >> /* in_mem_size must be in power of 2 */
> >> dw_pcie_writel_rc(pp, 0x5FFF, dbi_base + PCIE_ATU_LIMIT);

This is wrong. You should program here 0xBFFF.

Translation rule is as follows:

Region between "Start Address" and "End Address" is translated to
"Target Address" with region size = "End Address" - "Start Address".
Where: Start Address = (PCIE_ATU_UPPER_BASE | PCIE_ATU_LOWER_BASE)
End Address = (PCIE_ATU_UPPER_BASE | PCIE_ATU_LIMIT)
Target Address = (PCIE_ATU_UPPER_TARGET | PCIE_ATU_LOWER_TARGET) 

> >> dw_pcie_writel_rc(pp, 0x8000, dbi_base + 
> >> PCIE_ATU_LOWER_TARGET);
> >> dw_pcie_writel_rc(pp, 0, dbi_base + PCIE_ATU_UPPER_TARGET);
> > 
> > These numbers need to come from somewhere, you shouldn't just hardcode 
> > them, 
> 
> right. I'm still in the process of getting it work ;-)
> > 
> > I guess you should either program an inbound window covering the entire 
> > 64-bit
> > address space, or you should look at the top-level "memory" nodes to find
> > the location of physical RAM.
> > 
> > I can't see anything wrong with the way it's set up though, unless you have
> > an IOMMU. Can you confirm that there is no IOMMU (aka SMMU) in your system
> > that handles the PCIe root complex?
> 
> There is a MMU for PCIe root complex but that's disabled.
> > 
> >> I somehow starting to doubt the DMA address programmed in the ethernet card
> >> which is in my RAM address range (0x8000 to 0xBFFF). Should this
> >> address be programmed in the BAR of the ethernet card? How should it be 
> >> done?
> > 
> > No, it should not be in the BAR. The ethernet device driver calls dma_map_*
> > or pci_map_* interfaces to get a valid token that can be passed into the
> > device registers that are starting the DMA. You have to ensure that the
> > dma_map_ops for the device return the value that is set up in the 
> > translation.
> > 
> > The normal case is an identity mapping between device DMA space and host
> > memory space, i.e. PCIE_ATU_LOWER_TARGET == PCIE_ATU_LOWER_BASE, so
> > in the dma_map_single implementation, phys_addr_t == dma_addr_t.
> > 
> > If you set up the dma_addr_t space to start at 0 instead, you have to add
> > the offset in the dma_map_ops.
> 
> My DMA address is in 0x8000 to 0xBFFF range and I program my inbound
> translation for this range. Not sure what is missing still :-(

Hope, above modification helps. Let me know.

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

Re: [PATCH, RFC 08/12] random: mix in architectural randomness earlier in extract_buf()

On 09/22/2013 01:38 PM, Theodore Ts'o wrote:
> Previously if CPU chip had a built-in random number generator (i.e.,
> RDRAND on newer x86 chips), we mixed it in at the very end of
> extract_buf() using an XOR operation.
> 
> We now mix it in right after the calculate a hash across the entire
> pool.  This has the advantage that any contribution of entropy from
> the CPU's HWRNG will get mixed back into the pool.  In addition, it
> means that if the HWRNG has any defects (either accidentally or
> maliciously introduced), this will be mitigated via the non-linear
> transform of the SHA-1 hash function before we hand out generated
> output.
> 
> Signed-off-by: "Theodore Ts'o" 


This doesn't mix in across the entire width of the hash (my original
motivation for putting this at the end was to do it after the hash is
folded in half -- which is still believe is cryptographically dubious,
but please don't take my word for it, as I'm not a professional
cryptographer.)  As such, this change should *probably* have
EXTRACT_SIZE changed to 2*EXTRACT_SIZE (or simply "20") both in the for
loop and in the declaration of the union.

-hpa

>  drivers/char/random.c | 22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index ba23d5c..6d5e8e6 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -993,6 +993,17 @@ static void extract_buf(struct entropy_store *r, __u8 
> *out)
>   sha_transform(hash.w, (__u8 *)(r->pool + i), workspace);
>  
>   /*
> +  * If we have a architectural hardware random number
> +  * generator, mix that in, too.
> +  */
> + for (i = 0; i < LONGS(EXTRACT_SIZE); i++) {
> + unsigned long v;
> + if (!arch_get_random_long())
> + break;
> + hash.l[i] ^= v;
> + }
> +
> + /*
>* We mix the hash back into the pool to prevent backtracking
>* attacks (where the attacker knows the state of the pool
>* plus the current outputs, and attempts to find previous
> @@ -1021,17 +1032,6 @@ static void extract_buf(struct entropy_store *r, __u8 
> *out)
>   hash.w[1] ^= hash.w[4];
>   hash.w[2] ^= rol32(hash.w[2], 16);
>  
> - /*
> -  * If we have a architectural hardware random number
> -  * generator, mix that in, too.
> -  */
> - for (i = 0; i < LONGS(EXTRACT_SIZE); i++) {
> - unsigned long v;
> - if (!arch_get_random_long())
> - break;
> - hash.l[i] ^= v;
> - }
> -
>   memcpy(out, , EXTRACT_SIZE);
>   memset(, 0, sizeof(hash));
>  }
> 

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

Re: [PATCH, RFC 03/12] random: Allow fractional bits to be tracked

On 09/22/2013 09:01 PM, Theodore Ts'o wrote:
> I've added the following changes to this patch since upon testing,
> there were some uses of r->entropy_count that were not properly
> converted from using fractional bits to bits.
> 

Thanks for catching that.

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

linux-next: manual merge of the random tree with Linus' tree

Hi Theodore,

Today's linux-next merge of the random tree got a conflict in init/main.c
between commit 65f382fd0c8f ("context_tracking: Ground setup for static
key use") from Linus' tree and commit 382521d2478b ("random: run
random_int_secret_init() run after all late_initcalls") from the random
tree.

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

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

diff --cc init/main.c
index af310af,586cd33..000
--- a/init/main.c
+++ b/init/main.c
@@@ -75,7 -75,7 +75,8 @@@
  #include 
  #include 
  #include 
 +#include 
+ #include 
  
  #include 
  #include 


pgp3zMtK09bE7.pgp
Description: PGP signature

Re: [PATCH, RFC 03/12] random: Allow fractional bits to be tracked

I've added the following changes to this patch since upon testing,
there were some uses of r->entropy_count that were not properly
converted from using fractional bits to bits.

- Ted

diff --git a/drivers/char/random.c b/drivers/char/random.c
index 1547338..8654b7e 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -286,6 +286,7 @@
  * entropy_count, trickle_thresh
  */
 #define ENTROPY_SHIFT 3
+#define ENTROPY_BITS(r) ((r)->entropy_count >> ENTROPY_SHIFT)
 
 /*
  * The minimum number of bits of entropy before we wake up a read on
@@ -618,7 +619,8 @@ retry:
r->initialized = 1;
}
 
-   trace_credit_entropy_bits(r->name, nbits, entropy_count,
+   trace_credit_entropy_bits(r->name, nbits,
+ entropy_count >> ENTROPY_SHIFT,
  r->entropy_total, _RET_IP_);
 
/* should we wake readers? */
@@ -695,7 +697,7 @@ static void add_timer_randomness(struct timer_rand_state 
*state, unsigned num)
 
preempt_disable();
/* if over the trickle threshold, use only 1 in 4096 samples */
-   if (input_pool.entropy_count > trickle_thresh &&
+   if (ENTROPY_BITS(_pool) > trickle_thresh &&
((__this_cpu_inc_return(trickle_count) - 1) & 0xfff))
goto out;
 
@@ -999,7 +1001,7 @@ static ssize_t extract_entropy(struct entropy_store *r, 
void *buf,
r->last_data_init = true;
spin_unlock_irqrestore(>lock, flags);
trace_extract_entropy(r->name, EXTRACT_SIZE,
- r->entropy_count, _RET_IP_);
+ ENTROPY_BITS(r), _RET_IP_);
xfer_secondary_pool(r, EXTRACT_SIZE);
extract_buf(r, tmp);
spin_lock_irqsave(>lock, flags);
@@ -1008,7 +1010,7 @@ static ssize_t extract_entropy(struct entropy_store *r, 
void *buf,
spin_unlock_irqrestore(>lock, flags);
}
 
-   trace_extract_entropy(r->name, nbytes, r->entropy_count, _RET_IP_);
+   trace_extract_entropy(r->name, nbytes, ENTROPY_BITS(r), _RET_IP_);
xfer_secondary_pool(r, nbytes);
nbytes = account(r, nbytes, min, reserved);
 
@@ -1041,7 +1043,7 @@ static ssize_t extract_entropy_user(struct entropy_store 
*r, void __user *buf,
ssize_t ret = 0, i;
__u8 tmp[EXTRACT_SIZE];
 
-   trace_extract_entropy_user(r->name, nbytes, r->entropy_count, _RET_IP_);
+   trace_extract_entropy_user(r->name, nbytes, ENTROPY_BITS(r), _RET_IP_);
xfer_secondary_pool(r, nbytes);
nbytes = account(r, nbytes, 0, 0);
 
@@ -1213,8 +1215,8 @@ random_read(struct file *file, char __user *buf, size_t 
nbytes, loff_t *ppos)
DEBUG_ENT("sleeping?\n");
 
wait_event_interruptible(random_read_wait,
-   input_pool.entropy_count >=
-random_read_wakeup_thresh);
+   ENTROPY_BITS(_pool) >=
+   random_read_wakeup_thresh);
 
DEBUG_ENT("awake\n");
 
@@ -1250,9 +1252,9 @@ random_poll(struct file *file, poll_table * wait)
poll_wait(file, _read_wait, wait);
poll_wait(file, _write_wait, wait);
mask = 0;
-   if (input_pool.entropy_count >= random_read_wakeup_thresh)
+   if (ENTROPY_BITS(_pool) >= random_read_wakeup_thresh)
mask |= POLLIN | POLLRDNORM;
-   if (input_pool.entropy_count < random_write_wakeup_thresh)
+   if (ENTROPY_BITS(_pool) < random_write_wakeup_thresh)
mask |= POLLOUT | POLLWRNORM;
return mask;
 }
@@ -1303,7 +1305,7 @@ static long random_ioctl(struct file *f, unsigned int 
cmd, unsigned long arg)
switch (cmd) {
case RNDGETENTCNT:
/* inherently racy, no point locking */
-   ent_count = input_pool.entropy_count >> ENTROPY_SHIFT;
+   ent_count = ENTROPY_BITS(_pool);
if (put_user(ent_count, p))
return -EFAULT;
return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] pinctrl: pinctrl-adi2-bf60x: remove useless and duplicated GPIO definition for PPI2.

2013-09-22 Thread Sonic Zhang

From: Sonic Zhang 

Signed-off-by: Sonic Zhang 
---
 drivers/pinctrl/pinctrl-adi2-bf60x.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-adi2-bf60x.c 
b/drivers/pinctrl/pinctrl-adi2-bf60x.c
index e90cb80..bf57aea 100644
--- a/drivers/pinctrl/pinctrl-adi2-bf60x.c
+++ b/drivers/pinctrl/pinctrl-adi2-bf60x.c
@@ -236,8 +236,7 @@ static const unsigned ppi2_8b_pins[] = {
 static const unsigned ppi2_16b_pins[] = {
GPIO_PA0, GPIO_PA1, GPIO_PA2, GPIO_PA3, GPIO_PA4, GPIO_PA5, GPIO_PA6,
GPIO_PA7, GPIO_PA8, GPIO_PA9, GPIO_PA10, GPIO_PA11, GPIO_PA12,
-   GPIO_PA13, GPIO_PA14, GPIO_PA15,
-   GPIO_PA7, GPIO_PB0, GPIO_PB1, GPIO_PB2, GPIO_PB3,
+   GPIO_PA13, GPIO_PA14, GPIO_PA15, GPIO_PB0, GPIO_PB1, GPIO_PB2,
 };
 
 static const unsigned lp0_pins[] = {
-- 
1.8.2.3


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

Re: [PATCH v5 0/4] media: s5p-tv: clean-up and fixes

2013-09-22 Thread Sachin Kamat

Hi Mateusz,

On 21 September 2013 20:30, Mateusz Krawczuk
 wrote:
> This patch series add restoring previous vpll rate after driver offs stream
> or recives error.
> It also replace mxr_info, mxr_dbg, mxr_warn and mxr_err macro
> by generic solution.

It is a good practice to include revision history of the changes in
the patch set. This will help reviewers
check if the changes previously suggested have been incorporated or
not and to identify any new changes introduced by the author.

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

Re: Input: 8042 - only one i8042_filter

2013-09-22 Thread Dmitry Torokhov

Hi Andrey,

On Sat, Sep 21, 2013 at 10:48:21AM +0400, Andrey Moiseev wrote:
> Is it ok that in /drivers/input/serio/i8042.c it's allowed to install
> only one i8042_filter? Theoretically, there may be several different
> devices that need their drivers to install i8042_filter, to eat out
> some device-specific subset of scancodes. Shouldn't that single
> pointer to the i8042_filter be replaced by a list, for example?

The expectation that there will be a single platform specific driver
living in drivers/platform/x86/... that will install platform specific
filter and will do all necessary processing. So far there was no need
for more than one filter.

Thanks.

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

[PATCH] pinctrl: pinctrl-adi2: Add dependency to arch BLACKFIN in Kconfig.

2013-09-22 Thread Sonic Zhang

From: Sonic Zhang 

Signed-off-by: Sonic Zhang 
---
 drivers/pinctrl/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 08b8337..9bb6efb 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -51,6 +51,7 @@ config PINCTRL_AB8505
 
 config PINCTRL_ADI2
bool "ADI pin controller driver"
+   depends on BLACKFIN
select PINMUX
select IRQ_DOMAIN
help
-- 
1.8.2.3


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

[PATCH] usb: dwc3: Remove additional delay of 100ms when resuming

2013-09-22 Thread Vivek Gautam

This delay got introduced in:
"7415f17 usb: dwc3: core: add power management support"
which reflected similar code in dwc3_core_soft_reset() function.
However, originally the delay of 100ms in dwc3_core_soft_reset() was
meant to assist USB2PHY and USB3PHY reset, not for usb_phy_init()
sequence.

We should get rid of this delay, since things will still work
fine without this.

Signed-off-by: Vivek Gautam 
---

Hi Felipe,

I remember this change for phy_init including msleep(100) was
suggested by me, after testing the patch-series for PM support
to dwc3.
Sorry for that !!

 drivers/usb/dwc3/core.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 474162e..e88ffae 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -691,7 +691,6 @@ static int dwc3_resume(struct device *dev)
 
usb_phy_init(dwc->usb3_phy);
usb_phy_init(dwc->usb2_phy);
-   msleep(100);
 
spin_lock_irqsave(>lock, flags);
 
-- 
1.7.6.5

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

Re: [PATCH 1/3] Add smp support for Allwinner A20(sunxi 7i).

2013-09-22 Thread Guenter Roeck


On 09/21/2013 07:00 AM, Maxime Ripard wrote:

[ ... ]


+   /* assert cpu core reset */
+   writel(0, sunxi7i_cc_base + CPUX_RESET_CTL(cpu));
+   /* L1RSTDISABLE hold low */
+   pwr_reg = readl(sunxi7i_cc_base + AW_CPUCFG_GENCTL);
+   pwr_reg &= ~(1<

Use BIT(cpu) here. And you should run scripts/checkpatch.pl on your
patches before sending them.



For the record:

$ scripts/checkpatch.pl --strict allwinner.patch
total: 0 errors, 0 warnings, 0 checks, 527 lines checked

allwinner.patch has no obvious style problems and is ready for submission.

This is on top of "v3.12-rc1-336-gd8524ae".

checkpatch.pl does not complain as long as the number of spaces before
and after an operator is the same. There is a patch pending to change
this with the --strict option, but it will still not complain in 'normal'
operation.

Guenter

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

Re: [PATCH 3/3 v4] blackfin: pinctrl-adi2: Enable PINCTRL framework for BF54x and BF60x.

2013-09-22 Thread Steven Miao

Acked-by: Steven Miao 

On Tue, Sep 3, 2013 at 4:29 PM, Sonic Zhang  wrote:
> From: Sonic Zhang 
>
> - Remove unused macro MAX_RESOURCES
> - Override blackfin legacy peripheral pinmux request and free APIs by
> devm_pinctrl_get_select_default() to init the peripheral portmux setting.
>
> v3-chagnes:
> - Move pinctrl soc data out of blackfin arch folder.
>
> Signed-off-by: Sonic Zhang 
> ---
>  arch/blackfin/Kconfig   |  4 
>  arch/blackfin/include/asm/portmux.h | 19 +--
>  arch/blackfin/mach-bf548/include/mach/portmux.h |  2 --
>  arch/blackfin/mach-bf609/include/mach/portmux.h |  2 --
>  4 files changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
> index 9eff25b..ed7157f 100644
> --- a/arch/blackfin/Kconfig
> +++ b/arch/blackfin/Kconfig
> @@ -324,6 +324,10 @@ config GPIO_ADI
> def_bool y
> depends on (BF51x || BF52x || BF53x || BF538 || BF539 || BF561)
>
> +config PINCTRL
> +   def_bool y
> +   depends on BF54x || BF60x
> +
>  config MEM_MT48LC64M4A2FB_7E
> bool
> depends on (BFIN533_STAMP)
> diff --git a/arch/blackfin/include/asm/portmux.h 
> b/arch/blackfin/include/asm/portmux.h
> index 9b1e2c3..7aa2043 100644
> --- a/arch/blackfin/include/asm/portmux.h
> +++ b/arch/blackfin/include/asm/portmux.h
> @@ -17,14 +17,29 @@
>  #define P_MAYSHARE 0x2000
>  #define P_DONTCARE 0x1000
>
> -
> +#ifdef CONFIG_PINCTRL
> +#include 
> +
> +#define gpio_pint_regs bfin_pint_regs
> +#define adi_internal_set_wake bfin_internal_set_wake
> +
> +#define peripheral_request(per, label) 0
> +#define peripheral_free(per)
> +#define peripheral_request_list(per, label) \
> +   (pdev ? (IS_ERR(devm_pinctrl_get_select_default(>dev)) \
> +   ? -EINVAL : 0) : 0)
> +#define peripheral_free_list(per)
> +#else
>  int peripheral_request(unsigned short per, const char *label);
>  void peripheral_free(unsigned short per);
>  int peripheral_request_list(const unsigned short per[], const char *label);
>  void peripheral_free_list(const unsigned short per[]);
> +#endif
>
> -#include 
> +#include 
> +#include 
>  #include 
> +#include 
>
>  #ifndef P_SPORT2_TFS
>  #define P_SPORT2_TFS P_UNDEF
> diff --git a/arch/blackfin/mach-bf548/include/mach/portmux.h 
> b/arch/blackfin/mach-bf548/include/mach/portmux.h
> index e222462..d9f8632 100644
> --- a/arch/blackfin/mach-bf548/include/mach/portmux.h
> +++ b/arch/blackfin/mach-bf548/include/mach/portmux.h
> @@ -7,8 +7,6 @@
>  #ifndef _MACH_PORTMUX_H_
>  #define _MACH_PORTMUX_H_
>
> -#define MAX_RESOURCES  MAX_BLACKFIN_GPIOS
> -
>  #define P_SPORT2_TFS   (P_DEFINED | P_IDENT(GPIO_PA0) | P_FUNCT(0))
>  #define P_SPORT2_DTSEC (P_DEFINED | P_IDENT(GPIO_PA1) | P_FUNCT(0))
>  #define P_SPORT2_DTPRI (P_DEFINED | P_IDENT(GPIO_PA2) | P_FUNCT(0))
> diff --git a/arch/blackfin/mach-bf609/include/mach/portmux.h 
> b/arch/blackfin/mach-bf609/include/mach/portmux.h
> index 2e1a51c..fe34191 100644
> --- a/arch/blackfin/mach-bf609/include/mach/portmux.h
> +++ b/arch/blackfin/mach-bf609/include/mach/portmux.h
> @@ -7,8 +7,6 @@
>  #ifndef _MACH_PORTMUX_H_
>  #define _MACH_PORTMUX_H_
>
> -#define MAX_RESOURCES  MAX_BLACKFIN_GPIOS
> -
>  /* EMAC RMII Port Mux */
>  #define P_MII0_MDC (P_DEFINED | P_IDENT(GPIO_PC6) | P_FUNCT(0))
>  #define P_MII0_MDIO(P_DEFINED | P_IDENT(GPIO_PC7) | P_FUNCT(0))
> --
> 1.8.2.3
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the staging tree with the staging.current tree

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/iio/industrialio-event.c between commit cadc2125e140 ("iio: fix:
Keep a reference to the IIO device for open file descriptors") from the
staging.current tree and commit a646fbf0fd11 ("iio: use anon_inode_getfd
() with O_CLOEXEC flag") from the staging tree.

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

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

diff --cc drivers/iio/industrialio-event.c
index 6be65ef,2390e3d..000
--- a/drivers/iio/industrialio-event.c
+++ b/drivers/iio/industrialio-event.c
@@@ -163,10 -158,8 +163,10 @@@ int iio_event_getfd(struct iio_dev *ind
return -EBUSY;
}
spin_unlock_irq(_int->wait.lock);
 -  fd = anon_inode_getfd("iio:event",
 -  _event_chrdev_fileops, ev_int, O_RDONLY | 
O_CLOEXEC);
 +  iio_device_get(indio_dev);
 +
 +  fd = anon_inode_getfd("iio:event", _event_chrdev_fileops,
-   indio_dev, O_RDONLY);
++  indio_dev, O_RDONLY | O_CLOEXEC);
if (fd < 0) {
spin_lock_irq(_int->wait.lock);
__clear_bit(IIO_BUSY_BIT_POS, _int->flags);


pgpiEKnHQ4MF2.pgp
Description: PGP signature

Re: [PATCH 2/3 v4] blackfin: gpio: Remove none gpio lib code.

2013-09-22 Thread Steven Miao

Acked-by: Steven Miao 

On Tue, Sep 3, 2013 at 4:29 PM, Sonic Zhang  wrote:
> From: Sonic Zhang 
>
> - Remove non gpio lib code from blackfin architecture.
> - Limit the lagecy blackfin gpio driver to bf5xx processors only.
> - Remove unused definition of the pint power functions.
>
> Signed-off-by: Sonic Zhang 
> Acked-by: Linus Walleij 
> ---
>  arch/blackfin/Kconfig|   7 ++
>  arch/blackfin/include/asm/gpio.h | 157 
> +--
>  arch/blackfin/kernel/Makefile|   3 +-
>  3 files changed, 29 insertions(+), 138 deletions(-)
>
> diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
> index a117652..9eff25b 100644
> --- a/arch/blackfin/Kconfig
> +++ b/arch/blackfin/Kconfig
> @@ -52,6 +52,9 @@ config GENERIC_BUG
>  config ZONE_DMA
> def_bool y
>
> +config GENERIC_GPIO
> +   def_bool y
> +
>  config FORCE_MAX_ZONEORDER
> int
> default "14"
> @@ -317,6 +320,10 @@ config BF53x
> depends on (BF531 || BF532 || BF533 || BF534 || BF536 || BF537)
> default y
>
> +config GPIO_ADI
> +   def_bool y
> +   depends on (BF51x || BF52x || BF53x || BF538 || BF539 || BF561)
> +
>  config MEM_MT48LC64M4A2FB_7E
> bool
> depends on (BFIN533_STAMP)
> diff --git a/arch/blackfin/include/asm/gpio.h 
> b/arch/blackfin/include/asm/gpio.h
> index 98d0133..99d338c 100644
> --- a/arch/blackfin/include/asm/gpio.h
> +++ b/arch/blackfin/include/asm/gpio.h
> @@ -25,8 +25,12 @@
>
>  #ifndef __ASSEMBLY__
>
> +#ifndef CONFIG_PINCTRL
> +
>  #include 
> -#include 
> +#include 
> +#include 
> +#include 
>
>  /***
>  *
> @@ -45,7 +49,6 @@
>  * MODIFICATION HISTORY :
>  **/
>
> -#if !BFIN_GPIO_PINT
>  void set_gpio_dir(unsigned, unsigned short);
>  void set_gpio_inen(unsigned, unsigned short);
>  void set_gpio_polar(unsigned, unsigned short);
> @@ -115,7 +118,6 @@ struct gpio_port_t {
> unsigned short dummy16;
> unsigned short inen;
>  };
> -#endif
>
>  #ifdef BFIN_SPECIAL_GPIO_BANKS
>  void bfin_special_gpio_free(unsigned gpio);
> @@ -127,25 +129,21 @@ void bfin_special_gpio_pm_hibernate_suspend(void);
>  #endif
>
>  #ifdef CONFIG_PM
> -int bfin_pm_standby_ctrl(unsigned ctrl);
> +void bfin_gpio_pm_hibernate_restore(void);
> +void bfin_gpio_pm_hibernate_suspend(void);
> +int bfin_gpio_pm_wakeup_ctrl(unsigned gpio, unsigned ctrl);
> +int bfin_gpio_pm_standby_ctrl(unsigned ctrl);
>
>  static inline int bfin_pm_standby_setup(void)
>  {
> -   return bfin_pm_standby_ctrl(1);
> +   return bfin_gpio_pm_standby_ctrl(1);
>  }
>
>  static inline void bfin_pm_standby_restore(void)
>  {
> -   bfin_pm_standby_ctrl(0);
> +   bfin_gpio_pm_standby_ctrl(0);
>  }
>
> -void bfin_gpio_pm_hibernate_restore(void);
> -void bfin_gpio_pm_hibernate_suspend(void);
> -void bfin_pint_suspend(void);
> -void bfin_pint_resume(void);
> -
> -# if !BFIN_GPIO_PINT
> -int gpio_pm_wakeup_ctrl(unsigned gpio, unsigned ctrl);
>
>  struct gpio_port_s {
> unsigned short data;
> @@ -161,7 +159,6 @@ struct gpio_port_s {
> unsigned short reserved;
> unsigned short mux;
>  };
> -# endif
>  #endif /*CONFIG_PM*/
>
>  /***
> @@ -178,36 +175,29 @@ struct gpio_port_s {
>  *
>  * MODIFICATION HISTORY :
>  **/
> -
> -int bfin_gpio_request(unsigned gpio, const char *label);
> -void bfin_gpio_free(unsigned gpio);
>  int bfin_gpio_irq_request(unsigned gpio, const char *label);
>  void bfin_gpio_irq_free(unsigned gpio);
> -int bfin_gpio_direction_input(unsigned gpio);
> -int bfin_gpio_direction_output(unsigned gpio, int value);
> -int bfin_gpio_get_value(unsigned gpio);
> -void bfin_gpio_set_value(unsigned gpio, int value);
> +void bfin_gpio_irq_prepare(unsigned gpio);
> +
> +static inline int irq_to_gpio(unsigned irq)
> +{
> +   return irq - GPIO_IRQ_BASE;
> +}
> +#endif /* CONFIG_PINCTRL */
>
>  #include 
>  #include 
>
> -#ifdef CONFIG_GPIOLIB
>  #include   /* cansleep wrappers */
>
>  static inline int gpio_get_value(unsigned int gpio)
>  {
> -   if (gpio < MAX_BLACKFIN_GPIOS)
> -   return bfin_gpio_get_value(gpio);
> -   else
> -   return __gpio_get_value(gpio);
> +   return __gpio_get_value(gpio);
>  }
>
>  static inline void gpio_set_value(unsigned int gpio, int value)
>  {
> -   if (gpio < MAX_BLACKFIN_GPIOS)
> -   bfin_gpio_set_value(gpio, value);
> -   else
> -   __gpio_set_value(gpio, value);
> +   __gpio_set_value(gpio, value);
>  }
>
>  static inline int gpio_cansleep(unsigned int gpio)
> @@ -219,113 +209,6 @@ static inline int gpio_to_irq(unsigned gpio)
>  {
> return __gpio_to_irq(gpio);
>  }
> -
> -#else /* !CONFIG_GPIOLIB */
> -
> -static

Re: [PATCH 1/3 v4] pinctrl: ADI PIN control driver for the GPIO controller on bf54x and bf60x.

2013-09-22 Thread Steven Miao

Hi Linus,

On Thu, Sep 19, 2013 at 8:45 PM, Linus Walleij  wrote:
> On Tue, Sep 3, 2013 at 10:28 AM, Sonic Zhang  wrote:
>
>> From: Sonic Zhang 
>>
>> The new ADI GPIO2 controller was introduced since the BF548 and BF60x
>> processors. It differs a lot from the old one on BF5xx processors. So,
>> create a pinctrl driver under the pinctrl framework.
> (...)
>> v4-changes:
> (...)
>
> I'm quite happy with v4, and applied it to my devel branch
> in the pinctrl tree so we get some rotation in linux-next.
>
> If I can get an ACK from the Blackfin maintainer on patches
> 2 and 3 I'll apply those as well so you don't have to pull
> the pinctrl tree into blackfins tree, Mike?
Pls apply those patches to your pinctrl tree, thanks.

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

linux-next: manual merge of the staging tree with the staging.current tree

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/iio/industrialio-buffer.c between commit d66e0452bf6b ("iio: Fix
crash when scan_bytes is computed with active_scan_mask == NUL") from the
staging.current tree and commit 705ee2c98a37 ("iio:buffer: Simplify
iio_buffer_is_active()") from the staging tree.

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

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

diff --cc drivers/iio/industrialio-buffer.c
index 2710f72,2361fbc..000
--- a/drivers/iio/industrialio-buffer.c
+++ b/drivers/iio/industrialio-buffer.c
@@@ -546,16 -521,9 +540,16 @@@ int iio_update_buffers(struct iio_dev *
 * Roll back.
 * Note can only occur when adding a buffer.
 */
-   list_del(_buffer->buffer_list);
+   list_del_init(_buffer->buffer_list);
 -  indio_dev->active_scan_mask = old_mask;
 -  success = -EINVAL;
 +  if (old_mask) {
 +  indio_dev->active_scan_mask = old_mask;
 +  success = -EINVAL;
 +  }
 +  else {
 +  kfree(compound_mask);
 +  ret = -EINVAL;
 +  goto error_ret;
 +  }
}
} else {
indio_dev->active_scan_mask = compound_mask;


pgp4dZd1JWVOt.pgp
Description: PGP signature

Re: [PATCH,RFC] random: make fast_mix() honor its name

On Sun, Sep 22, 2013 at 08:16:23PM -0400, Jörn Engel wrote:
> How about we switch between the two mixing functions depending on the
> interrupt load?  If this CPU has seen fewer than 1000 interrupts in
> the last second, use the better one, otherwise us the cheaper one?

I guess the question here is whether it's worth it.  On a 2.8 GHz
laptop Ivy Bridge chip the numbers are:

Original fast_mix: 84 ns
tytso's fast_mix:  14 ns
joern's fast_mix:   8 ns

In terms of absolute overhead if you are running at an insane 100k
interrupts per second, it's still only 0.84%, 0.14%, and 0.08%,
respectively.  Granted, an embedded CPU will be (much) slower, but so
will the overall overhead of the rest of the interrupt handling code
path plus whatever the overhead of the device driver will be.  The
real bug is the 100k interrupts per second workload.

How about this as a compromise?  We can add an #ifdef in the random.c
code which has the alternate fast_mix algorithm in the very rare case
that some embedded software engineer under time-pressure and suffering
under the need to use a pathetically broken hardware design, and who
starts looking in the random.c code, will find the an alternate
version.  That way, we avoid the complexity of an dynamic switching
system, plus the overhead of measuring the number of interrupts per
second.

I am very strongly of the opinion that the number of systems where you
have an embedded system with that kind of inane interrupt rate is the
0.001% case.  So IMHO it's not even worth having a dynamic
switching system, especially when it's only going to improve things
slightly.

- Ted

P.S.  The real reason for the original fast_mix() function is because
it has a separate pool for each CPU, so there's no spinlock contention
and no cache line bouncing.  And that's why the fast_mix pool is so
small --- so that the entire struct fast_pool can fit in a single CPU
cache line.  So on normal, common systems --- even mobile handsets
have multiple cores these days --- fast_mix() *is* actually much
faster than the standard entropy pool, even before any optimizations.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 01/12] ping.h: Remove extern from function prototypes

2013-09-22 Thread Joe Perches

On Mon, 2013-09-23 at 12:38 +1000, Ryan Mallon wrote:
> A checkpatch rule might help,

Extant.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Would an "information module" be useful?

2013-09-22 Thread Markus Elfring

> In the systemd case we have to ensure that we never ever merge a module named 
> "systemd".

Interesting ...


> We have all kinds of strange modules/drivers. Usually you don't have to think
> whether your module is a "ordinary" driver or not...

Would it become useful to move "drivers" which do not manage hardware to a
separate directory?
Should such source files belong to a different software category (or "class")?

Regards,
Markus

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

Re: [PATCH 01/12] ping.h: Remove extern from function prototypes

2013-09-22 Thread Ryan Mallon

On 23/09/13 12:16, Joe Perches wrote:
> On Mon, 2013-09-23 at 11:59 +1000, Ryan Mallon wrote:
>> This seems like a lot of code churn for very little benefit. At a quick
>> glance:
>>
>>   git grep extern include/ | wc -l
>>   11427
>>
>> Not all of those will need to be removed, but that is still a huge
>> number to change, and doesn't include extern usage in C files or local
>> headers. You are probably never going to remove all the instances, so
>> what is the point of just randomly doing a handful?
> 
> Rather more than a handful.
> 
> The ratio of function prototypes without extern to
> function prototypes with extern is currently ~2.5:1
> 
> So:
> 
> Standardization without extern
> Line count reduction (~10%)
> Miscellaneous neatening at the same time
> Removal of all unnecessary externs from include/net
> 
> There are ~8500 instances in include/
> There are ~1500 instances in include/net/
> 
> After this series, 0 in include/net/
> 
> Start somewhere, go from there...
> 
> $ git grep -E "^\s*\bextern(\s+\w+){1,4}\s*\(\s*[^\*]" include/ | wc -l
> 8395
> $ git grep -E "^\s*\bextern(\s+\w+){1,4}\s*\(\s*[^\*]" include/net/ | wc -l
> 1471

Right, and:

  $ git grep -E "^\s*\bextern(\s+\w+){1,4}\s*\(\s*[^\*]" | wc -l
  29104

Since there are lots of local/arch headers, and there are uses of extern
function prototypes in C files.

I don't see the real benefit though. Its like trying to "clean-up" the
difference between "unsigned x" and "unsigned int x", or any number of
other minor style differences. Either version, with or without the
extern, is correct, valid C code. Plus you will get people adding new
instances of extern because they don't know any better. A checkpatch
rule might help, but we all know how often people run that...

~Ryan


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

Linus GIT - kernel BUG at include/linux/scatterlist.h:115! CPU: 1 PID: 1203 Comm: apparmor_parser Not tainted 3.12.0-rc1+

2013-09-22 Thread Miles Lane

[   27.190017] kernel BUG at include/linux/scatterlist.h:115!
[   27.190017] invalid opcode:  [#1] PREEMPT SMP DEBUG_PAGEALLOC
[   27.190017] Modules linked in: mxm_wmi iwldvm mac80211 iwlwifi
cfg80211 snd_hda_intel(+) snd_hda_codec snd_hwdep snd_pcm_oss
snd_mixer_oss hwmon snd_pcm ttm snd_seq_dummy snd_page_alloc
snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_timer
i915(+) snd i2c_algo_bit drm_kms_helper wmi ac drm soundcore evdev
mac_hid i2c_core battery acpi_cpufreq ehci_pci(+) ehci_hcd asus_laptop
rfkill intel_agp intel_gtt agpgart processor sr_mod cdrom atl1c
uhci_hcd thermal
[   27.190017] CPU: 1 PID: 1203 Comm: apparmor_parser Not tainted 3.12.0-rc1+ #8
[   27.190017] Hardware name: ASUSTeK Computer Inc. UL50VT
 /UL50VT, BIOS 217 03/01/2010
[   27.190017] task: 8800bd99ea80 ti: 8800baf5a000 task.ti:
8800baf5a000
[   27.190017] RIP: 0010:[]  []
sg_set_buf+0x20/0x7e
[   27.190017] RSP: 0018:8800baf5bcf8  EFLAGS: 00010246
[   27.190017] RAX:  RBX: 8800baf5bd70 RCX: 0024
[   27.190017] RDX: 0410 RSI: c900108ca010 RDI: 4100108ca010
[   27.190017] RBP: 8800baf5bd18 R08: 880138eec290 R09: 
[   27.190017] R10: 880138ee2148 R11: 0e12 R12: c900108ca010
[   27.190017] R13: 8649 R14: c900108ca010 R15: 880138ee
[   27.190017] FS:  7f96aaf6c740() GS:88013f30()
knlGS:
[   27.190017] CS:  0010 DS:  ES:  CR0: 80050033
[   27.190017] CR2: 7f96aaf5d00f CR3: b9e7a000 CR4: 000407e0
[   27.190017] Stack:
[   27.190017]  8800b9d55520 8800baf5bd70 8649
c900108ca010
[   27.190017]  8800baf5bdb8 811f9f50 811f3eef
000538ee8000
[   27.190017]  880138c42000 8800 87654321
ea0002ebd6c0
[   27.190017] Call Trace:
[   27.190017]  [] aa_calc_profile_hash+0x75/0x11d
[   27.190017]  [] ? __aa_kvmalloc+0x39/0x51
[   27.190017]  [] aa_unpack+0x929/0x969
[   27.190017]  [] aa_replace_profiles+0x38/0x57c
[   27.190017]  [] profile_replace+0x35/0x4c
[   27.190017]  [] vfs_write+0xad/0x113
[   27.190017]  [] SyS_write+0x44/0x7a
[   27.190017]  [] system_call_fastpath+0x16/0x1b
[   27.190017] Code: 66 89 45 fc e8 6a fc ff ff c9 c3 55 48 89 e5 41
56 41 55 41 89 d5 41 54 49 89 f4 53 48 89 fb 48 89 f7 e8 1b 9e e3 ff
84 c0 75 02 <0f> 0b 4c 89 e7 45 89 e6 e8 96 9e e3 ff 48 8b 53 08 41 81
e6 ff
[   27.190017] RIP  [] sg_set_buf+0x20/0x7e
[   27.190017]  RSP 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the omap_dss2 tree with the fbdev tree

Hi Tomi,

Today's linux-next merge of the omap_dss2 tree got a conflict in
drivers/video/atmel_lcdfb.c between commits a17c2e7b704f ("video:
atmel_lcdfb: fix platform data struct") and 5e8be022fb5b ("video:
atmel_lcdfb: add device tree suport") from the fbdev tree and commit
a5d58be0796a ("video: atmel_lcdfb: use dev_get_platdata()") from the
omap_dss2 tree.

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

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

diff --cc drivers/video/atmel_lcdfb.c
index bf9c5d0,df05550..000
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@@ -1157,30 -934,19 +1157,30 @@@ static int __init atmel_lcdfb_probe(str
}
  
sinfo = info->par;
 +  sinfo->pdev = pdev;
 +  sinfo->info = info;
  
 -  if (dev_get_platdata(dev)) {
 -  pdata_sinfo = dev_get_platdata(dev);
 -  sinfo->default_bpp = pdata_sinfo->default_bpp;
 -  sinfo->default_dmacon = pdata_sinfo->default_dmacon;
 -  sinfo->default_lcdcon2 = pdata_sinfo->default_lcdcon2;
 -  sinfo->default_monspecs = pdata_sinfo->default_monspecs;
 -  sinfo->atmel_lcdfb_power_control = 
pdata_sinfo->atmel_lcdfb_power_control;
 -  sinfo->guard_time = pdata_sinfo->guard_time;
 -  sinfo->smem_len = pdata_sinfo->smem_len;
 -  sinfo->lcdcon_is_backlight = pdata_sinfo->lcdcon_is_backlight;
 -  sinfo->lcdcon_pol_negative = pdata_sinfo->lcdcon_pol_negative;
 -  sinfo->lcd_wiring_mode = pdata_sinfo->lcd_wiring_mode;
 +  INIT_LIST_HEAD(>modelist);
 +
 +  if (pdev->dev.of_node) {
 +  ret = atmel_lcdfb_of_init(sinfo);
 +  if (ret)
 +  goto free_info;
-   } else if (dev->platform_data) {
++  } else if (dev_get_platdata(dev)) {
 +  struct fb_monspecs *monspecs;
 +  int i;
 +
-   pdata = dev->platform_data;
++  pdata = dev_get_platdata(dev);
 +  monspecs = pdata->default_monspecs;
 +  sinfo->pdata = *pdata;
 +
 +  for (i = 0; i < monspecs->modedb_len; i++)
 +  fb_add_videomode(>modedb[i], >modelist);
 +
 +  sinfo->config = atmel_lcdfb_get_config(pdev);
 +
 +  info->var.bits_per_pixel = pdata->default_bpp ? 
pdata->default_bpp : 16;
 +  memcpy(>monspecs, pdata->default_monspecs, 
sizeof(info->monspecs));
} else {
dev_err(dev, "cannot get default configuration\n");
goto free_info;


pgpgx3T0AhfYq.pgp
Description: PGP signature

Re: [PATCH] usb/core/devio.c:tolerate wrong direction flag in control endpoints

2013-09-22 Thread Alan Stern

On Sun, 22 Sep 2013, Kurt Garloff wrote:

> Hi Alan,
> 
> thanks for your review and your constructive comments!

You're welcome.

> >> Hi,
> >> 
> >> USB devio rejects control messages when the index does not have the
> >> direction bit set correctly.
> >
> >I wouldn't describe it that way.  It would be more accurate to say that
> >the message is rejected when wIndex contains an invalid endpoint
> >address.
> 
> Well, this seems to be a question of terminology, no?
> I saw the endpoint byte as consisting of endpoint index plus the direction 
> bit.

See the entry for "Endpoint Address" in Chapter 2 (Terms and 
Abbreviations) of the USB 2.0 specification.  The definition says:

The combination of an endpoint number and an endpoint direction
on a USB device. Each endpoint address supports data transfer
in one direction.

> >> This breaks windows apps in KVM -- and might be overly strict
> >according
> >> to my reading of USB HID spec.
> >
> >It is not overly strict.
> 
> OK, you certainly know the USB specs better than I do.
> 
> If the message is not according to spec because the windex byte (which
> should reference the endpoint) has the endpoint direction flag wrong,
> then the question may become whether the kernel should reject it or
> leave that to the device.
> Rejecting by the kernel has the risk that somewhat non-compliant devices
> with somewhat non-compliant (userspace) drivers are prevented from working.
> While not rejecting has the risk that overly sensitive devices might freak out
> on receiving a non-compliant transfer. The fact that Win does not not seem to
> filter here however might make that risk rather small.
> (Long years have taught us that companies don't test against the spec but this
>  "OS" from Redmond.)

This is a good explanation of why the patch should be accepted.

> >> From: Kurt Garloff 
> >> Subject: Tolerate wrong direction bit endpoint index for control 
> >> messages
> >> Signed-off-by: Kurt Garloff 
> >> 
> >> Trying to read data from the Pegasus Technologies NoteTaker (0e20:0101)
> >> [1] with the Windows App (EasyNote) works natively but fails when
> >> WIndows is running under KVM (and the USB device handed to KVM).
> >> 
> >> The reason is a USB control message
> >>  usb 4-2.2: control urb: bRequestType=22 bRequest=09 wValue=0200 
> >> wIndex=0001 wLength=0008
> >> This goes to endpoint 1 (wIndex), however, the endpoint is an input
> >> endpoint and thus enumerated 0x81.
> >> 
> >> The kernel thus rejects the IO and thus we see the failure.
> >> 
> >> Apparently, Linux is more strict here than Windows ... we can't change
> >> the Win app easily, so that's a problem.
> >
> >Indeed, this indicates that the device itself is also buggy.  If it 
> >worked correctly, it would reject the incorrect control message.
> 
> It seems to interpret wIndex differently indeed. Not sure whether
> that qualifies as a bug or not. Maybe it should not claim to be a
> HID device then?

Maybe not.  This particular combination of bRequestType and bRequest 
values (0x22, 0x09) is not defined in the HID 1.11 spec.  Do you know 
if it is defined somewhere else?

> Looking at the code, it seems that printers do something strange
> here, and it might be that the device in question here is not 100%
> HID in that it also assumes a non-standard meaning to this byte.
> 
> Strange enough, the app does want to talk to the control interface it seems:
> Sep 19 09:47:21 nehalem kernel: [44539.730269] usb 4-2.2: usbdev_do_ioctl: 
> SUBMITURB
> Sep 19 09:47:21 nehalem kernel: [44539.730276] usb 4-2.2: proc_submiturb: URB 
> 02 00 0  01a83420 16 0
> Sep 19 09:47:21 nehalem kernel: [44539.730280] usb 4-2.2: control urb: 
> bRequestType=22 bRequest=09 wValue=0200 wIndex=0001 wLength=0008
> Sep 19 09:47:21 nehalem kernel: [44539.730285] usb 4-2.2: check_ctrlrecip: 
> process 13073 (qemu-kvm) requesting ep 01 but needs 81 (or 00)
> Sep 19 09:47:21 nehalem kernel: [44539.730290] usb 4-2.2: userurb 
> 01b56f00, ep0 ctrl-out, length 8
> Sep 19 09:47:21 nehalem kernel: [44539.730294] data: 02 01 b5 00 00 00 00 00  
> 
> 
> Sep 19 09:47:21 nehalem kernel: [44539.730301] usb 4-2.2: proc_submiturb: 
> return 0
> 
> The second line here comes from instrumentation I have inserted in 
> proc_submiturb():
> 
> snoop(>dev->dev, "%s: URB %02x %02x %i %08x %p %i %i\n",
> __func__, uurb.type, uurb.endpoint, uurb.status,
> uurb.flags, uurb.buffer, uurb.buffer_length,
> uurb.actual_length);
> 
> and it shows that uurb.endpoint actually is set to 0.

That's right.  The URB is sent to endpoint 0.  The value in
bRequestType indicates that the recipient of the request is an
endpoint, and the value of wIndex indicates which endpoint.  So even
though the request is sent to endpoint 0,

Re: [PATCH] ipc/sem.c: fix update sem_otime when calling sem_op in semaphore initialization

2013-09-22 Thread Jia He

 

On Mon, 23 Sep 2013 03:08:36 +0200 from bitbuc...@online.de wrote:
> On Sun, 2013-09-22 at 12:42 +0200, Manfred Spraul wrote:
>
>> Mike: no, your patch makes it worse:
>> - wait-for-zero semops still don't update sem_otime
>> - sem_otime is initialized to sem_ctime. That's not mentioned in the 
>> sysv standard.
> So sem_otime = 0 is a specified semaphore state?  I thought the proggy
> was busted for spinning on a (busted and) irrelevant stamp.
Please refer to the words from Unix Network Programming - Volume 2 2nd
Edition Chapter 11
"Fortunately, there is a way around this race condition. We are guaranteed
that thesem-otime member of the semid-ds structure is set to 0 when a
new semaphore set iscreated. (The System V manuals have stated this
fact for a long time, as do the XPG3and Unix 98 standards.) This member
is set to the current time only by a successful callto semop."
>
> Man lernt nie aus.
>
> -Mike
>
>

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

Re: [PATCH 01/12] ping.h: Remove extern from function prototypes

2013-09-22 Thread Joe Perches

On Mon, 2013-09-23 at 11:59 +1000, Ryan Mallon wrote:
> This seems like a lot of code churn for very little benefit. At a quick
> glance:
> 
>   git grep extern include/ | wc -l
>   11427
> 
> Not all of those will need to be removed, but that is still a huge
> number to change, and doesn't include extern usage in C files or local
> headers. You are probably never going to remove all the instances, so
> what is the point of just randomly doing a handful?

Rather more than a handful.

The ratio of function prototypes without extern to
function prototypes with extern is currently ~2.5:1

So:

Standardization without extern
Line count reduction (~10%)
Miscellaneous neatening at the same time
Removal of all unnecessary externs from include/net

There are ~8500 instances in include/
There are ~1500 instances in include/net/

After this series, 0 in include/net/

Start somewhere, go from there...

$ git grep -E "^\s*\bextern(\s+\w+){1,4}\s*\(\s*[^\*]" include/ | wc -l
8395
$ git grep -E "^\s*\bextern(\s+\w+){1,4}\s*\(\s*[^\*]" include/net/ | wc -l
1471


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

Re: [PATCH v2 3/4] mm/zswap: avoid unnecessary page scanning

2013-09-22 Thread Bob Liu


On 09/10/2013 12:29 AM, Seth Jennings wrote:
> On Fri, Sep 06, 2013 at 01:16:45PM +0800, Weijie Yang wrote:
>> add SetPageReclaim before __swap_writepage so that page can be moved to the
>> tail of the inactive list, which can avoid unnecessary page scanning as this
>> page was reclaimed by swap subsystem before.
>>
>> Signed-off-by: Weijie Yang 
> 
> Acked-by: Seth Jennings 
> 

Below is a reply from Mel in original thread "[PATCHv11 3/4] zswap: add
to mm/"
--
> + /* start writeback */
> + SetPageReclaim(page);
> + __swap_writepage(page, , end_swap_bio_write);
> + page_cache_release(page);
> + zswap_written_back_pages++;
> +

SetPageReclaim? Why?. If the page is under writeback then why do you not
mark it as that? Do not free pages that are currently under writeback
obviously. It's likely that it was PageWriteback you wanted in zbud.c too.


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

[PATCH] perf record: mmap output file - RFC

When recording raw_syscalls for the entire system, e.g.,
perf record -e raw_syscalls:*,sched:sched_switch -a -- sleep 1

you end up with a negative feedback loop as perf itself calls
write() fairly often. This patch mmap's the file in chunks of 64M
at a time and copies events from the event buffers to the file
avoiding write system calls.

Before (with write syscall):

perf record -o /tmp/perf.data -e raw_syscalls:*,sched:sched_switch -a -- sleep 1
[ perf record: Woken up 0 times to write data ]
[ perf record: Captured and wrote 81.843 MB /tmp/perf.data (~3575786 samples) ]

After (using mmap):

perf record -o /tmp/perf.data -e raw_syscalls:*,sched:sched_switch -a -- sleep 1
[ perf record: Woken up 31 times to write data ]
[ perf record: Captured and wrote 8.203 MB /tmp/perf.data (~358388 samples) ]

Before I get too far down this path I wanted to get comments on the approach.

Signed-off-by: David Ahern 
Cc: Ingo Molnar 
Cc: Frederic Weisbecker 
Cc: Peter Zijlstra 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Mike Galbraith 
Cc: Stephane Eranian 
---
 tools/perf/builtin-record.c |   87 +++
 1 file changed, 87 insertions(+)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index da13840..45bb565 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -29,6 +29,9 @@
 #include 
 #include 
 
+/* mmap file big chunks at a time */
+#define MMAP_OUTPUT_SIZE   (64*1024*1024)
+
 #ifndef HAVE_ON_EXIT
 #ifndef ATEXIT_MAX
 #define ATEXIT_MAX 32
@@ -64,6 +67,14 @@ static void __handle_on_exit_funcs(void)
 struct perf_record {
struct perf_tooltool;
struct perf_record_opts opts;
+
+   /* for MMAP based file writes */
+   void*mmap_addr;
+   u64 bytes_at_mmap_start; /* bytes in file when mmap 
use starts */
+   u64 mmap_offset;/* current location within mmap 
*/
+   size_t  mmap_size;  /* size of mmap segments */
+   booluse_mmap;
+
u64 bytes_written;
const char  *output_name;
struct perf_evlist  *evlist;
@@ -82,8 +93,66 @@ static void advance_output(struct perf_record *rec, size_t 
size)
rec->bytes_written += size;
 }
 
+static int do_mmap_output(struct perf_record *rec, void *buf, size_t size)
+{
+   u64 remaining;
+   off_t offset;
+
+   if (rec->mmap_addr == NULL) {
+do_mmap:
+   offset = rec->bytes_at_mmap_start + rec->bytes_written;
+   if (offset < (ssize_t) rec->mmap_size) {
+   rec->mmap_offset = offset;
+   offset = 0;
+   } else
+   rec->mmap_offset = 0;
+
+   rec->mmap_addr = mmap(NULL, rec->mmap_size,
+PROT_WRITE | PROT_READ,
+MAP_SHARED,
+rec->output,
+offset);
+
+   if (rec->mmap_addr == MAP_FAILED) {
+   pr_err("mmap failed: %d: %s\n", errno, strerror(errno));
+   return -1;
+   }
+
+   /* expand file to include this mmap segment */
+   if (ftruncate(rec->output, offset + rec->mmap_size) != 0) {
+   pr_err("ftruncate failed\n");
+   return -1;
+   }
+   }
+
+   remaining = rec->mmap_size - rec->mmap_offset;
+
+   if (size > remaining) {
+   memcpy(rec->mmap_addr + rec->mmap_offset, buf, remaining);
+   rec->bytes_written += remaining;
+
+   size -= remaining;
+   buf  += remaining;
+
+   msync(rec->mmap_addr, rec->mmap_size, MS_ASYNC);
+   munmap(rec->mmap_addr, rec->mmap_size);
+   goto do_mmap;
+   }
+
+   if (size) {
+   memcpy(rec->mmap_addr + rec->mmap_offset, buf, size);
+   rec->bytes_written += size;
+   rec->mmap_offset += size;
+   }
+
+   return 0;
+}
+
 static int write_output(struct perf_record *rec, void *buf, size_t size)
 {
+   if (rec->use_mmap)
+   return do_mmap_output(rec, buf, size);
+
while (size) {
int ret = write(rec->output, buf, size);
 
@@ -546,6 +615,11 @@ static int __cmd_record(struct perf_record *rec, int argc, 
const char **argv)
if (forks)
perf_evlist__start_workload(evsel_list);
 
+   if (!rec->opts.pipe_output && stat(output_name, ) == 0) {
+   rec->use_mmap = true;
+   rec->bytes_at_mmap_start = st.st_size - rec->bytes_written;
+   }
+
for (;;) {
int hits = rec->samples;
 
@@ -572,6 +646,18 @@ static int __cmd_record(struct perf_record *rec, int argc, 
const char **argv)
}
}
 
+   if

Re: [PATCH 01/12] ping.h: Remove extern from function prototypes

2013-09-22 Thread Ryan Mallon

On 23/09/13 03:32, Joe Perches wrote:
> There are a mix of function prototypes with and without extern
> in the kernel sources.  Standardize on not using extern for
> function prototypes.
> 
> Function prototypes don't need to be written with extern.
> extern is assumed by the compiler.  Its use is as unnecessary as
> using auto to declare automatic/local variables in a block.
> 
> Signed-off-by: Joe Perches 

This seems like a lot of code churn for very little benefit. At a quick
glance:

  git grep extern include/ | wc -l
  11427

Not all of those will need to be removed, but that is still a huge
number to change, and doesn't include extern usage in C files or local
headers. You are probably never going to remove all the instances, so
what is the point of just randomly doing a handful?

~Ryan

> ---
>  include/net/ping.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/net/ping.h b/include/net/ping.h
> index 5db0224..3f67704 100644
> --- a/include/net/ping.h
> +++ b/include/net/ping.h
> @@ -103,8 +103,8 @@ void ping_seq_stop(struct seq_file *seq, void *v);
>  int ping_proc_register(struct net *net, struct ping_seq_afinfo *afinfo);
>  void ping_proc_unregister(struct net *net, struct ping_seq_afinfo *afinfo);
>  
> -extern int __init ping_proc_init(void);
> -extern void ping_proc_exit(void);
> +int __init ping_proc_init(void);
> +void ping_proc_exit(void);
>  #endif
>  
>  void __init ping_init(void);
> 

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

[PATCHv3] x86: EFI stub support for large memory maps

2013-09-22 Thread Linn Crosetto

This patch fixes a problem with EFI memory maps larger than 128 entries
when booting using the EFI stub, which results in overflowing e820_map
in boot_params and an eventual halt when checking the map size in
sanitize_e820_map().

If the number of map entries is greater than what can fit in e820_map,
add the extra entries to the setup_data list using type SETUP_E820_EXT.
These extra entries are then picked up when the setup_data list is
parsed in parse_e820_ext().

Signed-off-by: Linn Crosetto 
---
Changes from v2:
 * Removed unnecessary optimization in alloc_e820ext() (Matt Fleming)
 * Fixed a bug where an incorrect buffer size may be passed to
   get_memory_map when jumping to get_map

 arch/x86/boot/compressed/eboot.c | 239 +++
 1 file changed, 167 insertions(+), 72 deletions(-)

diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index b7388a4..bfa177a 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -982,46 +982,198 @@ fail:
return NULL;
 }
 
+static void add_e820ext(struct boot_params *params,
+   struct setup_data *e820ext, u32 nr_entries)
+{
+   struct setup_data *data;
+   efi_status_t status;
+   unsigned long size;
+
+   e820ext->type = SETUP_E820_EXT;
+   e820ext->len = nr_entries * sizeof(struct e820entry);
+   e820ext->next = 0;
+
+   data = (struct setup_data *)(unsigned long)params->hdr.setup_data;
+
+   while (data && data->next)
+   data = (struct setup_data *)(unsigned long)data->next;
+
+   if (data)
+   data->next = (unsigned long)e820ext;
+   else
+   params->hdr.setup_data = (unsigned long)e820ext;
+}
+
+static efi_status_t setup_e820(struct boot_params *params,
+  struct setup_data *e820ext, u32 e820ext_size)
+{
+   struct e820entry *e820_map = >e820_map[0];
+   struct efi_info *efi = >efi_info;
+   struct e820entry *prev = NULL;
+   u32 nr_entries;
+   u32 nr_desc;
+   int i;
+
+   nr_entries = 0;
+   nr_desc = efi->efi_memmap_size / efi->efi_memdesc_size;
+
+   for (i = 0; i < nr_desc; i++) {
+   efi_memory_desc_t *d;
+   unsigned int e820_type = 0;
+   unsigned long m = efi->efi_memmap;
+
+   d = (efi_memory_desc_t *)(m + (i * efi->efi_memdesc_size));
+   switch (d->type) {
+   case EFI_RESERVED_TYPE:
+   case EFI_RUNTIME_SERVICES_CODE:
+   case EFI_RUNTIME_SERVICES_DATA:
+   case EFI_MEMORY_MAPPED_IO:
+   case EFI_MEMORY_MAPPED_IO_PORT_SPACE:
+   case EFI_PAL_CODE:
+   e820_type = E820_RESERVED;
+   break;
+
+   case EFI_UNUSABLE_MEMORY:
+   e820_type = E820_UNUSABLE;
+   break;
+
+   case EFI_ACPI_RECLAIM_MEMORY:
+   e820_type = E820_ACPI;
+   break;
+
+   case EFI_LOADER_CODE:
+   case EFI_LOADER_DATA:
+   case EFI_BOOT_SERVICES_CODE:
+   case EFI_BOOT_SERVICES_DATA:
+   case EFI_CONVENTIONAL_MEMORY:
+   e820_type = E820_RAM;
+   break;
+
+   case EFI_ACPI_MEMORY_NVS:
+   e820_type = E820_NVS;
+   break;
+
+   default:
+   continue;
+   }
+
+   /* Merge adjacent mappings */
+   if (prev && prev->type == e820_type &&
+   (prev->addr + prev->size) == d->phys_addr) {
+   prev->size += d->num_pages << 12;
+   continue;
+   }
+
+   if (nr_entries == ARRAY_SIZE(params->e820_map)) {
+   u32 need = (nr_desc - i) * sizeof(struct e820entry) +
+  sizeof(struct setup_data);
+
+   if (!e820ext || e820ext_size < need)
+   return EFI_BUFFER_TOO_SMALL;
+
+   /* boot_params map full, switch to e820 extended */
+   e820_map = (struct e820entry *)e820ext->data;
+   }
+
+   e820_map->addr = d->phys_addr;
+   e820_map->size = d->num_pages << PAGE_SHIFT;
+   e820_map->type = e820_type;
+   prev = e820_map++;
+   nr_entries++;
+   }
+
+   if (nr_entries > ARRAY_SIZE(params->e820_map)) {
+   u32 nr_e820ext = nr_entries - ARRAY_SIZE(params->e820_map);
+
+   add_e820ext(params, e820ext, nr_e820ext);
+   nr_entries -= nr_e820ext;
+   }
+
+   params->e820_entries = (u8)nr_entries;
+
+   return EFI_SUCCESS;
+}
+
+static efi_status_t alloc_e820ext(u32 nr_desc, struct setup_data **e820ext,
+

Re: [f2fs-dev] [PATCH] f2fs: remove unneeded write checkpoint in recover_fsync_data

2013-09-22 Thread Gu Zheng

On 09/22/2013 03:51 PM, Chao Yu wrote:

> Previously, recover_fsync_data still to write checkpoint when there is
> nothing to recover with normal umount image.
> It may reduce mount performance and flash memory lifetime, so let's remove
> it.
> 
> Signed-off-by: Tan Shu 
> Signed-off-by: Yu Chao 
> ---
>  fs/f2fs/recovery.c |5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
> index 51ef5ee..6988e1b 100644
> --- a/fs/f2fs/recovery.c
> +++ b/fs/f2fs/recovery.c
> @@ -419,6 +419,7 @@ int recover_fsync_data(struct f2fs_sb_info *sbi)
>  {
>   struct list_head inode_list;
>   int err;
> + int is_writecp = 0;

"need_writecp" may be more suitable.

Thanks,
Gu 

>  
>   fsync_entry_slab = f2fs_kmem_cache_create("f2fs_fsync_inode_entry",
>   sizeof(struct fsync_inode_entry), NULL);
> @@ -436,6 +437,8 @@ int recover_fsync_data(struct f2fs_sb_info *sbi)
>   if (list_empty(_list))
>   goto out;
>  
> + is_writecp = 1;
> +
>   /* step #2: recover data */
>   err = recover_data(sbi, _list, CURSEG_WARM_NODE);
>   BUG_ON(!list_empty(_list));
> @@ -443,7 +446,7 @@ out:
>   destroy_fsync_dnodes(_list);
>   kmem_cache_destroy(fsync_entry_slab);
>   sbi->por_doing = 0;
> - if (!err)
> + if (!err && is_writecp)
>   write_checkpoint(sbi, false);
>   return err;
>  }
> ---
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


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

Re: [f2fs-dev] [PATCH] f2fs: avoid allocating failure in bio_alloc

2013-09-22 Thread Gu Zheng

On 09/22/2013 03:50 PM, Chao Yu wrote:

> This patch add macro MAX_BIO_BLOCKS to limit value of npages in
> f2fs_bio_alloc, it can avoid allocating failure in bio_alloc caused by
> npages is larger than BIO_MAX_PAGES.
> 
> Signed-off-by: Yu Chao 


Reviewed-by: Gu Zheng 

> ---
>  fs/f2fs/segment.c |4 +++-
>  fs/f2fs/segment.h |2 ++
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> index 09af9c7..bd79bbe 100644
> --- a/fs/f2fs/segment.c
> +++ b/fs/f2fs/segment.c
> @@ -657,6 +657,7 @@ static void submit_write_page(struct f2fs_sb_info *sbi,
> struct page *page,
>   block_t blk_addr, enum page_type type)
>  {
>   struct block_device *bdev = sbi->sb->s_bdev;
> + int bio_blocks;
>  
>   verify_block_addr(sbi, blk_addr);
>  
> @@ -676,7 +677,8 @@ retry:
>   goto retry;
>   }
>  
> - sbi->bio[type] = f2fs_bio_alloc(bdev, max_hw_blocks(sbi));
> + bio_blocks = MAX_BIO_BLOCKS(max_hw_blocks(sbi));
> + sbi->bio[type] = f2fs_bio_alloc(bdev, bio_blocks);
>   sbi->bio[type]->bi_sector = SECTOR_FROM_BLOCK(sbi,
> blk_addr);
>   sbi->bio[type]->bi_private = priv;
>   /*
> diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
> index bdd10ea..7f94d78 100644
> --- a/fs/f2fs/segment.h
> +++ b/fs/f2fs/segment.h
> @@ -90,6 +90,8 @@
>   (blk_addr << ((sbi)->log_blocksize - F2FS_LOG_SECTOR_SIZE))
>  #define SECTOR_TO_BLOCK(sbi, sectors)
> \
>   (sectors >> ((sbi)->log_blocksize - F2FS_LOG_SECTOR_SIZE))
> +#define MAX_BIO_BLOCKS(max_hw_blocks)
> \
> + (min((int)max_hw_blocks, BIO_MAX_PAGES))
>  
>  /* during checkpoint, bio_private is used to synchronize the last bio */
>  struct bio_private {
> ---
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


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

[PATCH 3/5] perf trace: Add mmap2 handler

5c5e854b changed perf_event__synthesize_mmap_events to generate MMAP2
events. Since perf-trace does not have a handler for it it dies with a
segfault when trying to process files:

perf trace -i /tmp/perf.data
Segmentation fault

Signed-off-by: David Ahern 
---
 tools/perf/builtin-trace.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 9c7f017..f61c968 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -1383,6 +1383,7 @@ static int trace__replay(struct trace *trace)
 
trace->tool.sample= trace__process_sample;
trace->tool.mmap  = perf_event__process_mmap;
+   trace->tool.mmap2 = perf_event__process_mmap2;
trace->tool.comm  = perf_event__process_comm;
trace->tool.exit  = perf_event__process_exit;
trace->tool.fork  = perf_event__process_fork;
-- 
1.7.10.1

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

[PATCH 5/5] perf trace: Add beautifier for clock_gettime's clk_id argument - v2

Before:
0.030 ( 0.002 ms): 2571 clock_gettime(which_clock: 1, tp: 0x7f3b45729cd0 ) = 0

After:
0.030 ( 0.002 ms): 2571 clock_gettime(which_clock: MONOTONIC, tp: 
0x7f3b45729cd0 ) = 0

v2: Update to use the STRARRAY option

Signed-off-by: David Ahern 
Cc: Adrian Hunter 
Cc: Frederic Weisbecker 
Cc: Jiri Olsa 
Cc: Mike Galbraith 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
---
 tools/perf/builtin-trace.c |7 +++
 1 file changed, 7 insertions(+)

diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index f61c968..636a506 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -280,6 +280,12 @@ static DEFINE_STRARRAY(rlimit_resources);
 static const char *sighow[] = { "BLOCK", "UNBLOCK", "SETMASK", };
 static DEFINE_STRARRAY(sighow);
 
+static const char *clockid[] = {
+   "REALTIME", "MONOTONIC", "PROCESS_CPUTIME_ID", "THREAD_CPUTIME_ID",
+   "MONOTONIC_RAW", "REALTIME_COARSE", "MONOTONIC_COARSE",
+};
+static DEFINE_STRARRAY(clockid);
+
 static const char *socket_families[] = {
"UNSPEC", "LOCAL", "INET", "AX25", "IPX", "APPLETALK", "NETROM",
"BRIDGE", "ATMPVC", "X25", "INET6", "ROSE", "DECnet", "NETBEUI",
@@ -566,6 +572,7 @@ static struct syscall_fmt {
{ .name = "arch_prctl", .errmsg = true, .alias = "prctl", },
{ .name = "brk",.hexret = true,
  .arg_scnprintf = { [0] = SCA_HEX, /* brk */ }, },
+   { .name = "clock_gettime",  .errmsg = true, STRARRAY(0, clk_id, 
clockid), },
{ .name = "connect",.errmsg = true, },
{ .name = "epoll_ctl",  .errmsg = true, STRARRAY(1, op, 
epoll_ctl_ops), },
{ .name = "eventfd2",   .errmsg = true,
-- 
1.7.10.1

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

[PATCH 4/5] perf tool: Add default handler for mmap2 events

Commands that do not implement an mmap2 handler should at least
not die with a segfault when processing files with MMAP2 events.

Signed-off-by: David Ahern 
---
 tools/perf/util/session.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 78646da..6c1d444 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -256,6 +256,8 @@ void perf_tool__fill_defaults(struct perf_tool *tool)
tool->sample = process_event_sample_stub;
if (tool->mmap == NULL)
tool->mmap = process_event_stub;
+   if (tool->mmap2 == NULL)
+   tool->mmap2 = process_event_stub;
if (tool->comm == NULL)
tool->comm = process_event_stub;
if (tool->fork == NULL)
-- 
1.7.10.1

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

[PATCH 2/5] perf tool: Explicitly add libdl dependency

Fixes compile failure on Fedora 12.

Signed-off-by: David Ahern 
---
 tools/perf/config/Makefile |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index 6850529..85fc870 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -87,7 +87,7 @@ CFLAGS += -Wall
 CFLAGS += -Wextra
 CFLAGS += -std=gnu99
 
-EXTLIBS = -lelf -lpthread -lrt -lm
+EXTLIBS = -lelf -lpthread -lrt -lm -ldl
 
 ifeq ($(call try-cc,$(SOURCE_HELLO),$(CFLAGS) -Werror 
-fstack-protector-all,-fstack-protector-all),y)
   CFLAGS += -fstack-protector-all
-- 
1.7.10.1

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

[PATCH 0/5] perf tool: Various fixes and version 2 on clock_gettime

Arnaldo:

Various bug fixes hit working on the mmap write change and version 2 on the
clock_gettime beautifier. One other problem I was not able to resolve is 
with perf-trace not displaying comms when processing files. eg.,

 0.025 ( 0.000 ms): :7137/7137  ... [continued]: ioctl()) = 0
 0.045 ( 0.014 ms): :7137/7137 ioctl(fd: 14, cmd: 44672 
 ) = 0
 0.055 ( 0.008 ms): :7137/7137 ioctl(fd: 14, cmd: 44672

Other commands like perf-script display comms just fine, so it is something
about perf-trace.

David Ahern (5):
  perf trace: Handle MSG_WAITFORONE not defined
  perf tool: Explicitly add libdl dependency
  perf trace: Add mmap2 handler
  perf tool: Add default handler for mmap2 events
  perf trace: Add beautifier for clock_gettime's clk_id argument - v2

 tools/perf/builtin-trace.c |   11 +++
 tools/perf/config/Makefile |2 +-
 tools/perf/util/session.c  |2 ++
 3 files changed, 14 insertions(+), 1 deletion(-)

-- 
1.7.10.1

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

[PATCH 1/5] perf trace: Handle MSG_WAITFORONE not defined

Needed for compiles on Fedora 12 for example.

Signed-off-by: David Ahern 
---
 tools/perf/builtin-trace.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index f869c87..9c7f017 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -340,6 +340,9 @@ static size_t syscall_arg__scnprintf_socket_type(char *bf, 
size_t size,
 #ifndef MSG_PROBE
 #define MSG_PROBE   0x10
 #endif
+#ifndef MSG_WAITFORONE
+#define MSG_WAITFORONE 0x1
+#endif
 #ifndef MSG_SENDPAGE_NOTLAST
 #define MSG_SENDPAGE_NOTLAST 0x2
 #endif
-- 
1.7.10.1

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

[PATCH 4/4] misc: pti: remove unnecessary pci_set_drvdata()

The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/misc/pti.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/misc/pti.c b/drivers/misc/pti.c
index f84ff0c..eda38cb 100644
--- a/drivers/misc/pti.c
+++ b/drivers/misc/pti.c
@@ -892,7 +892,6 @@ static void pti_pci_remove(struct pci_dev *pdev)
}
 
iounmap(drv_data->pti_ioaddr);
-   pci_set_drvdata(pdev, NULL);
kfree(drv_data);
pci_release_region(pdev, 1);
pci_disable_device(pdev);
-- 
1.7.10.4


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

[PATCH 3/4] misc: mei: remove unnecessary pci_set_drvdata()

The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/misc/mei/pci-me.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/misc/mei/pci-me.c b/drivers/misc/mei/pci-me.c
index 1b3844e..1b8a4c6 100644
--- a/drivers/misc/mei/pci-me.c
+++ b/drivers/misc/mei/pci-me.c
@@ -239,7 +239,6 @@ static void mei_me_remove(struct pci_dev *pdev)
 
free_irq(pdev->irq, dev);
pci_disable_msi(pdev);
-   pci_set_drvdata(pdev, NULL);
 
if (hw->mem_addr)
pci_iounmap(pdev, hw->mem_addr);
-- 
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 2/4] misc: ibmasm: remove unnecessary pci_set_drvdata()

The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/misc/ibmasm/module.c |2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/misc/ibmasm/module.c b/drivers/misc/ibmasm/module.c
index 0346d87..c224039 100644
--- a/drivers/misc/ibmasm/module.c
+++ b/drivers/misc/ibmasm/module.c
@@ -153,7 +153,6 @@ error_ioremap:
 error_heartbeat:
ibmasm_event_buffer_exit(sp);
 error_eventbuffer:
-   pci_set_drvdata(pdev, NULL);
kfree(sp);
 error_kmalloc:
 pci_release_regions(pdev);
@@ -182,7 +181,6 @@ static void ibmasm_remove_one(struct pci_dev *pdev)
ibmasm_free_remote_input_dev(sp);
iounmap(sp->base_address);
ibmasm_event_buffer_exit(sp);
-   pci_set_drvdata(pdev, NULL);
kfree(sp);
pci_release_regions(pdev);
pci_disable_device(pdev);
-- 
1.7.10.4


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

[PATCH 1/4] misc: tifm: remove unnecessary pci_set_drvdata()

The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/misc/tifm_7xx1.c |3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/misc/tifm_7xx1.c b/drivers/misc/tifm_7xx1.c
index f8d66543..ae282a1 100644
--- a/drivers/misc/tifm_7xx1.c
+++ b/drivers/misc/tifm_7xx1.c
@@ -378,7 +378,6 @@ err_out_irq:
 err_out_unmap:
iounmap(fm->addr);
 err_out_free:
-   pci_set_drvdata(dev, NULL);
tifm_free_adapter(fm);
 err_out_int:
pci_intx(dev, 0);
@@ -405,8 +404,6 @@ static void tifm_7xx1_remove(struct pci_dev *dev)
for (cnt = 0; cnt < fm->num_sockets; cnt++)
tifm_7xx1_sock_power_off(tifm_7xx1_sock_addr(fm->addr, cnt));
 
-   pci_set_drvdata(dev, NULL);
-
iounmap(fm->addr);
pci_intx(dev, 0);
pci_release_regions(dev);
-- 
1.7.10.4


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

Re: [PATCH,RFC] random: make fast_mix() honor its name

2013-09-22 Thread Jörn Engel

On Sun, 22 September 2013 19:36:41 -0400, Theodore Ts'o wrote:
> On Sun, Sep 22, 2013 at 04:53:34PM -0400, Jörn Engel wrote:
> > 
> > And I want to keep that function.  Essentially the point of fast_mix()
> > is to ratelimit _mix_pool_bytes().  Naïve ratelimiting would simply
> > discard the input once the ratelimit has been reached.  My proposal is
> > to still use the input bits, but use a really cheap mixing function.
> 
> Sure, but how cheap is "cheap"?  There's a balance here.  I don't buy
> the argument that we must weaken the fast_mix() at all costs because
> we have to drive the cost of fast_mix() to zero.  If we're going to do
> that, to the limit fast_mix() should be a no-op, which is ridiculous.

Agreed.  We always have a tradeoff between quality and cost.  And I
repeat yet again that driving the cost down is important, because it
allows us to collect entropy more often.  The schedule is an entropy
source I would like to tap.

> So what I've suggested already makes fast_mix() much faster.  It's not
> fast as what you've proposed, but it's pretty clear that my fast_mix()
> is better at mixing the fast_mix pool.

Agreed.

> > Your version of fast_mix() failed in the "really cheap" department.
> > As a result, it showed up in profiles and at least one idiot (me)
> > reverted to naïve ratelimiting.  It could have been worse, I was
> > explicitly asked twice to just remove the call to
> > add_interrupt_randomness().
> 
> Sure, but that's not _my_ problem.  If someone stupid adulterates
> /dev/random, that's not my responsibility.  Most people aren't going
> to be dealing with systems with truly stupid interrupt rates, and most
> people aren't going to be tampering with the random driver.

This is where I don't agree.  I very much care even about the plastic
routers running some variant of Linux modified by some embedded
engineers under insane time pressure.  If you leave them an incentive
to cripple the random generator, some of them will.  If you find
source code with a maliciously crippled random generator, the author
has plausible deniability.

So this should be _our_ problem.  Maybe not yours specifically, but
certainly that of kernel developers in general.

> I'm certainly willing to make fast_mix() faster, to reduce the
> temptation for idiots to tamper with /dev/random, but we need to
> balance the time of fast_mix() with the quality of its mixing, and to
> remember what the common case is (and it's not 100k interrupts per
> second!)

How about we switch between the two mixing functions depending on the
interrupt load?  If this CPU has seen fewer than 1000 interrupts in
the last second, use the better one, otherwise us the cheaper one?

I don't really like the idea too much.  But it would cover both the
common case and my particular degenerated one.

> In practice, we are using randomness in so many places (every single
> time we start a process for ASLR, in lots of security-related programs
> that use SSL libraries, etc.), that we are actually practically
> *never* hitting trickle_thresh.
> 
> The trickle_thresh was added originally when add_timer_randomness()
> was used for interrupts that used SA_SAMPLE_RANDOM.  Given that we
> don't use add_timer_randomness() for that, but for things that happen
> much more rarely (i.e., such as keyboard/mouse input), I'm probably
> going to end up removing the trickle thresh_check altogether.

Makes sense to me.

Jörn

--
Doubt is not a pleasant condition, but certainty is an absurd one.
-- Voltaire
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Why does test_bit() take a volatile addr?

2013-09-22 Thread Rusty Russell

Rob Landley  writes:
> On 09/15/2013 11:08:35 PM, Rusty Russell wrote:
>> Predates git, does anyone remember the rationale?
>
> Depends which git: http://landley.net/kdocs/fullhist/ :)

Not useful.  See Geert's more helpful response.

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

[PATCHv2 1/1] arch/parisc: mm: fix uninitialized variable usage

2013-09-22 Thread Felipe Pena

The FAULT_FLAG_WRITE flag has been set based on uninitialized variable

Signed-off-by: Felipe Pena 
---
 arch/parisc/mm/fault.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/parisc/mm/fault.c b/arch/parisc/mm/fault.c
index d10d27a..00c0ed3 100644
--- a/arch/parisc/mm/fault.c
+++ b/arch/parisc/mm/fault.c
@@ -182,6 +182,9 @@ void do_page_fault(struct pt_regs *regs, unsigned long code,
 
if (user_mode(regs))
flags |= FAULT_FLAG_USER;
+
+   acc_type = parisc_acctyp(code, regs->iir);
+
if (acc_type & VM_WRITE)
flags |= FAULT_FLAG_WRITE;
 retry:
@@ -196,8 +199,6 @@ retry:
 
 good_area:
 
-   acc_type = parisc_acctyp(code,regs->iir);
-
if ((vma->vm_flags & acc_type) != acc_type)
goto bad_area;
 
-- 
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] ipc/sem.c: fix update sem_otime when calling sem_op in semaphore initialization

2013-09-22 Thread Mike Galbraith

On Sun, 2013-09-22 at 12:42 +0200, Manfred Spraul wrote:

> Mike: no, your patch makes it worse:
> - wait-for-zero semops still don't update sem_otime
> - sem_otime is initialized to sem_ctime. That's not mentioned in the 
> sysv standard.

So sem_otime = 0 is a specified semaphore state?  I thought the proggy
was busted for spinning on a (busted and) irrelevant stamp.

Man lernt nie aus.

-Mike

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

xpad input driver: Xbox 360 Wireless Adapter

2013-09-22 Thread Zachary Lund

I'm apologize ahead of time if this thread isn't appropriate, I'm not
very familiar with mailing lists, especially lkml. I'm also very new
to kernel/module development (as of literally yesterday).

I was looking into getting the LED working properly for the Xbox 360
controllers and learning about the basics of a kernel module at the
same time. There were a few things that confused me. I will reference
functions by name and all functions are from the current 3.12 branch.

First, xpad_send_led_command seems to be geared only towards the
"Microsoft X-Box 360 pad". Using xboxdrv as a reference, they use a
completely different packet structure to set the LED status on the
wireless controller which can be seen here:
https://github.com/Grumbel/xboxdrv/blob/master/src/controller/xbox360_wireless_controller.cpp#L66

Second, the driver acts strangely when setting the LED. It calls
xpad_send_led_command during xpad_led_probe during xpad_probe but
there's a chance that a controller might not even be connected if
using the wireless adapter during that time! The only way to seemingly
tell if a controller is connected is by receiving the correct
connection packets. If I use the correct packet structure (which I
ripped almost directly from xboxdrv) and set the led after parsing a
connection packet, the LED seemingly works fine!

Third, I'm incredibly new to really low level development. Whenever
loading the module, it finds my wireless adapter but then creates 4
devices (which seems to mean only 4 controllers are allowed per
wireless adapter), each of which cause a call to xpad_probe. I
couldn't figure out how to tell if other wireless controllers were
already connected to the wireless adapter so I could light up the
correct LED. How would I go about this properly?

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

Re: [PATCH 1/5] scsi: Fix assignment of 0/1 to bool variables

2013-09-22 Thread Joe Perches

On Sun, 2013-09-22 at 20:44 +0200, Peter Senna Tschudin wrote:
> Convert 0 to false and 1 to true when assigning values to bool
> variables. Inspired by commit 3db1cd5c05f35fb43eb134df6f321de4e63141f2.
[]
> @@
> bool b;
> @@
> -b = 1
> +b = true

You might also look for non-zero values other than 1
and convert those true too.


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

Re: [PATCH, RFC 10/12] random: cap the rate which the /dev/urandom pool gets reseeded

On 09/22/2013 04:23 PM, Theodore Ts'o wrote:
> On Sun, Sep 22, 2013 at 03:45:11PM -0700, H. Peter Anvin wrote:
>> I understand the motivation, but I question basing it in a fixed amount of 
>> time.
> 
> We already have a threshold based on the amount of the entropy in the
> input pool.  I could increase that threshold, but then instead of
> having the entropy hover between say, 192 and 128, it would hover
> between say, 576 and 512.  What that means in practice is that there
> will be a higher baseline, but we will still end up reseeding every 10
> seconds or so (that being approximately how much entropy I've seen
> flowing into the input pool on my laptop system --- 64 bits every 10
> seconds or so).
> 
> By basing it on a time-based threshold, it means that the input pool
> can build up faster such that over time, such that entropy pool ends
> up hovering around 3400 bits.
> 

So make it a threshold around 2048-3072 bits.  A.k.a. "if the input pool
is filling up fast enough, take advantage of it."

> What is your concern is about having it being time-based --- or more
> accurately, being partially time-based, since we also keep the entorpy
> count based threshold?  I'll note that the Fortuna Random Number
> Generator, devised by Bruce Schneier and Niels Ferguson also uses as
> part of its design a time-based reseed limit.

Just that it is unnecessary in a scenario when entropy is plentiful.

-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 10/18] Do proper conversion from UTF-16 to UTF-8

On 09/22/2013 04:07 PM, Roy Franz wrote:
> On Sun, Sep 22, 2013 at 3:54 PM, H. Peter Anvin  wrote:
>> Sorry this version is broken and doesn't even compile due to remaining 
>> options_size references.
> 
> I compiled and tested this series on both x86_64 (using OVMF) and on
> the ARM simulator.  I just doubled checked
> my kernel .config to verify this was not being omitted and I'm pretty
> sure this doesn't have any compilation problems.
> I did make a few changes to get the untested version you sent out to
> compile, but they all seemed to be straightforward typo type fixes.
> I'll gladly address any defects in this patch, but I don't see an
> compilation problems.
> 

Ah yes, I see now... you fixed up the compile problem but did so
incorrectly.

  int load_options_size = image->load_options_size / 2; /* ASCII */

This is a number of UTF-16 chars, the comment is completely wrong;

-  while (*s2 && *s2 != '\n' && options_size <
load_options_size) {
+  while (*s2 && *s2 != '\n' && options_bytes <
load_options_size) {
+  options_bytes += efi_utf8_bytes(*s2);
  s2++;
-  options_size++;
  }
+  options_chars = s2 - options;

You can't compare options_bytes against load_options_size; the latter
being a UTF-16 shortword count.

So the loop really needs to update options_chars in the loop to compare
it against load_options_size:

while (*s2 && *s2 != '\n' && options_chars < load_options_size) {
options_bytes += efi_utf8_bytes(*s2++);
option_chars++;
}

-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: [PATCHv2] x86: EFI stub support for large memory maps

2013-09-22 Thread Linn Crosetto

On Tue, Sep 17, 2013 at 09:14:52PM +0100, Matt Fleming wrote:
> > +static efi_status_t alloc_e820ext(u32 nr_desc, struct setup_data **e820ext,
> > + u32 *e820ext_size)
> > +{
> > +   efi_status_t status;
> > +   unsigned long size;
> > +
> > +   size = sizeof(struct setup_data) +
> > +   sizeof(struct e820entry) * nr_desc;
> > +
> > +   if (*e820ext && size <= *e820ext_size)
> > +   return EFI_SUCCESS; /* Already allocated */
> 
> Do we actually need this check? I thought the 'prev_nr_desc' below
> ensures we only allocate 'e820ext' if we need more memory.

I am okay with removing the check. There is another bug in exit_boot, when
jumping to get_map the call to get the memory map is passed the previous map
size instead of the size of the allocated buffer. I'll make the changes and
resend.

> 
> [...]
> 
> > @@ -1016,6 +1157,19 @@ get_map:
> > if (status != EFI_SUCCESS)
> > goto free_mem_map;
> >  
> > +   prev_nr_desc = nr_desc;
> > +   nr_desc = size / desc_size;
> > +   if (nr_desc > prev_nr_desc &&
> > +   nr_desc > ARRAY_SIZE(boot_params->e820_map)) {
> > +   u32 nr_e820ext = nr_desc - ARRAY_SIZE(boot_params->e820_map);
> > +
> > +   status = alloc_e820ext(nr_e820ext, , _size);
> > +   if (status != EFI_SUCCESS)
> > +   goto free_mem_map;
> > +
> > +   goto get_map; /* Allocated memory, get map again */
> > +   }
> > +
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] arch/parisc: mm: fix uninitialized variable usage

2013-09-22 Thread Felipe Pena

Hello Johannes,

On Sun, Sep 22, 2013 at 7:58 PM, Johannes Weiner  wrote:
> Hello Felipe,
>
> On Sun, Sep 22, 2013 at 03:17:46PM -0300, Felipe Pena wrote:
>> The FAULT_FLAG_WRITE flag has been set based on uninitialized variable
>
> Oops, you are right.
>
>> Signed-off-by: Felipe Pena 
>> ---
>>  arch/parisc/mm/fault.c |5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/parisc/mm/fault.c b/arch/parisc/mm/fault.c
>> index d10d27a..6b38026 100644
>> --- a/arch/parisc/mm/fault.c
>> +++ b/arch/parisc/mm/fault.c
>> @@ -182,8 +182,6 @@ void do_page_fault(struct pt_regs *regs, unsigned long 
>> code,
>>
>>   if (user_mode(regs))
>>   flags |= FAULT_FLAG_USER;
>> - if (acc_type & VM_WRITE)
>> - flags |= FAULT_FLAG_WRITE;
>>  retry:
>>   down_read(>mmap_sem);
>>   vma = find_vma_prev(mm, address, _vma);
>> @@ -201,6 +199,9 @@ good_area:
>>   if ((vma->vm_flags & acc_type) != acc_type)
>>   goto bad_area;
>>
>> + if (acc_type & VM_WRITE)
>> + flags |= FAULT_FLAG_WRITE;
>
> Can acc_type actually change between between the first round and a
> retry?  Otherwise, it might make sense to pull this up and place it
> next to the flag initialization instead of pulling one flag down.

>From what I've analyzed, this make sense. I'll make the suggested
changes and send another patch.

Thanks.

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

Re: linux-next: old trees

Hi Konrad,

On Fri, 20 Sep 2013 14:35:17 -0400 Konrad Rzeszutek Wilk 
 wrote:
>
> > ibft1 year, 9 months ago
> 
> Can go away.
> 
> > swiotlb 11 months ago
> 
> Need it. Don't remove it pls.
> 
> > tmem11 months ago
> 
> Can go away.

OK, 2 removed.  Thanks.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpMofHQU3CfO.pgp
Description: PGP signature

Re: [GIT PULL] Block IO fixes for 3.12

2013-09-22 Thread Jens Axboe

On Sun, Sep 22 2013, Linus Torvalds wrote:
> On Sun, Sep 22, 2013 at 4:12 PM, Jens Axboe  wrote:
> >
> > Not necessarily bad quality control, but yeah, the commit messages
> > could've been prettier. Those two should have been git ammended, most of
> > them are directly applied byt git am fwiw.
> 
> No, one of them was clearly *not* done with git am, because git am
> uses the subject like to create that summary message.

So make that a combo of git am and shitty mailer. I forget why it
happens, but it does happen often for me and I (usually remember) to fix
it up.

> And the other one you should have edited the mbox before feeding it to
> git am - or pushed back on the submitter to write email in a format
> where no such editing is necessary.
> 
> "I used git am" is not an excuse for bad formatting of commits. It's
> just a tool, you need to make sure the tool is fed valid data.

Sure, not disagreeing. It is my fault :-)

-- 
Jens Axboe

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

Re: [PATCH,RFC] random: make fast_mix() honor its name

On Sun, Sep 22, 2013 at 04:53:34PM -0400, Jörn Engel wrote:
> 
> And I want to keep that function.  Essentially the point of fast_mix()
> is to ratelimit _mix_pool_bytes().  Naïve ratelimiting would simply
> discard the input once the ratelimit has been reached.  My proposal is
> to still use the input bits, but use a really cheap mixing function.

Sure, but how cheap is "cheap"?  There's a balance here.  I don't buy
the argument that we must weaken the fast_mix() at all costs because
we have to drive the cost of fast_mix() to zero.  If we're going to do
that, to the limit fast_mix() should be a no-op, which is ridiculous.

So what I've suggested already makes fast_mix() much faster.  It's not
fast as what you've proposed, but it's pretty clear that my fast_mix()
is better at mixing the fast_mix pool.

> Your version of fast_mix() failed in the "really cheap" department.
> As a result, it showed up in profiles and at least one idiot (me)
> reverted to naïve ratelimiting.  It could have been worse, I was
> explicitly asked twice to just remove the call to
> add_interrupt_randomness().

Sure, but that's not _my_ problem.  If someone stupid adulterates
/dev/random, that's not my responsibility.  Most people aren't going
to be dealing with systems with truly stupid interrupt rates, and most
people aren't going to be tampering with the random driver.

I'm certainly willing to make fast_mix() faster, to reduce the
temptation for idiots to tamper with /dev/random, but we need to
balance the time of fast_mix() with the quality of its mixing, and to
remember what the common case is (and it's not 100k interrupts per
second!)

> And you should do the same for add_timer_randomness(), where again you
> have ratelimiting.  Once trickle_thresh is reached your code simply
> discards most randomness.  

In practice, we are using randomness in so many places (every single
time we start a process for ASLR, in lots of security-related programs
that use SSL libraries, etc.), that we are actually practically
*never* hitting trickle_thresh.

The trickle_thresh was added originally when add_timer_randomness()
was used for interrupts that used SA_SAMPLE_RANDOM.  Given that we
don't use add_timer_randomness() for that, but for things that happen
much more rarely (i.e., such as keyboard/mouse input), I'm probably
going to end up removing the trickle thresh_check altogether.

Regards,

- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Block IO fixes for 3.12

2013-09-22 Thread Linus Torvalds

On Sun, Sep 22, 2013 at 4:12 PM, Jens Axboe  wrote:
>
> Not necessarily bad quality control, but yeah, the commit messages
> could've been prettier. Those two should have been git ammended, most of
> them are directly applied byt git am fwiw.

No, one of them was clearly *not* done with git am, because git am
uses the subject like to create that summary message.

And the other one you should have edited the mbox before feeding it to
git am - or pushed back on the submitter to write email in a format
where no such editing is necessary.

"I used git am" is not an excuse for bad formatting of commits. It's
just a tool, you need to make sure the tool is fed valid data.

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

Re: [PATCH, RFC 10/12] random: cap the rate which the /dev/urandom pool gets reseeded

On Sun, Sep 22, 2013 at 03:45:11PM -0700, H. Peter Anvin wrote:
> I understand the motivation, but I question basing it in a fixed amount of 
> time.

We already have a threshold based on the amount of the entropy in the
input pool.  I could increase that threshold, but then instead of
having the entropy hover between say, 192 and 128, it would hover
between say, 576 and 512.  What that means in practice is that there
will be a higher baseline, but we will still end up reseeding every 10
seconds or so (that being approximately how much entropy I've seen
flowing into the input pool on my laptop system --- 64 bits every 10
seconds or so).

By basing it on a time-based threshold, it means that the input pool
can build up faster such that over time, such that entropy pool ends
up hovering around 3400 bits.

What is your concern is about having it being time-based --- or more
accurately, being partially time-based, since we also keep the entorpy
count based threshold?  I'll note that the Fortuna Random Number
Generator, devised by Bruce Schneier and Niels Ferguson also uses as
part of its design a time-based reseed limit.

- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] block: Device driver for sTec's PCIe Kronos Card.

2013-09-22 Thread Jens Axboe

On Sun, Sep 22 2013, Olof Johansson wrote:
> On Sat, Sep 21, 2013 at 1:01 PM, Jens Axboe  wrote:
> > On Fri, Sep 20 2013, Andrew Morton wrote:
> >> On Tue, 17 Sep 2013 14:20:55 -0600 Jens Axboe  wrote:
> >>
> >> > > So, it looks like this driver needs a bunch of work before it's ready
> >> > > to go in. Or, maybe it's better to submit it with a TODO list for the
> >> > > staging tree instead?
> >> >
> >> > Not disagreeing with you, it definitely needs a bit of cleaning. And so
> >> > far stec has not been very responsive in fixing those issues.
> >>
> >> Geeze.  Here's what I came up with, mainly to make i386 compile:
> >
> > Thanks Andrew. It's not the fixes themselves that are tricky, I would
> > just have liked a little more proof that the submission wasn't just a
> > dump'n run.
> 
> Well, that's what much of the staging process is about, since it needs
> to come with a todo list (and that list needs to be taken care of
> before the driver graduates). Honestly, this looks like a prime
> candidate for that. But it's your tree and your call.
> 
> Thanks for applying the patch from Andrew, that resolves most of it
> for me right now.

I'm sort-of on the fence. It's minor stuff, but it does need cleaning
up. So not necessarily something that will prevent it from going into
3.12, it's more the continued support and development I'm worried about.

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Block IO fixes for 3.12

2013-09-22 Thread Jens Axboe

On Sun, Sep 22 2013, Linus Torvalds wrote:
> On Sun, Sep 22, 2013 at 2:55 PM, Jens Axboe  wrote:
> >
> > Mike Christie (1):
> >   If the queue is dying then we only call the rq->end_io callout. 
> > This leaves bios setup on the request, because the caller assumes when 
> > the blk_execute_rq_nowait/blk_execute_rq call has completed that the 
> > rq->bios have been cleaned up.
> 
> Christ people.
> 
> We have rules for commit messages. Those rules have things like
> "one-line commit summary at the top", because without that things like
> summary logs (ie "git shortlog") and "gitk" don't do a good job.
> 
> How long have we been doing this? I'm used to seeing some odd commit
> messages outside the kernel repo, but am used to kernel people getting
> the trivial details right.
> 
> That's not the only one. Look at commit 577cee1e8db6 for some other
> cruddy commit messages. Just because somebody said "Hello" in email
> doesn't mean that it should remain that way in a commit message.
> 
> So out of seven commit messages, two were badly formatted. That's not
> a sign of good quality control.

Not necessarily bad quality control, but yeah, the commit messages
could've been prettier. Those two should have been git ammended, most of
them are directly applied byt git am fwiw.

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 10/18] Do proper conversion from UTF-16 to UTF-8

On Sun, Sep 22, 2013 at 3:54 PM, H. Peter Anvin  wrote:
> Sorry this version is broken and doesn't even compile due to remaining 
> options_size references.

I compiled and tested this series on both x86_64 (using OVMF) and on
the ARM simulator.  I just doubled checked
my kernel .config to verify this was not being omitted and I'm pretty
sure this doesn't have any compilation problems.
I did make a few changes to get the untested version you sent out to
compile, but they all seemed to be straightforward typo type fixes.
I'll gladly address any defects in this patch, but I don't see an
compilation problems.

Thanks,
Roy


>
> Roy Franz  wrote:
>>From: "H. Peter Anvin" 
>>
>>Improve the conversion of the UTF-16 EFI command line
>>to UTF-8 for passing to the kernel.
>>
>>Signed-off-by: Roy Franz 
>>---
>> arch/x86/boot/compressed/eboot.c   |3 +-
>>drivers/firmware/efi/efi-stub-helper.c |   92
>>
>> 2 files changed, 72 insertions(+), 23 deletions(-)
>>
>>diff --git a/arch/x86/boot/compressed/eboot.c
>>b/arch/x86/boot/compressed/eboot.c
>>index 5e708c0..4723dc89 100644
>>--- a/arch/x86/boot/compressed/eboot.c
>>+++ b/arch/x86/boot/compressed/eboot.c
>>@@ -486,8 +486,7 @@ struct boot_params *make_boot_params(void *handle,
>>efi_system_table_t *_table)
>>   hdr->type_of_loader = 0x21;
>>
>>   /* Convert unicode cmdline to ascii */
>>-  cmdline_ptr = efi_convert_cmdline_to_ascii(sys_table, image,
>>- _size);
>>+  cmdline_ptr = efi_convert_cmdline(sys_table, image, _size);
>>   if (!cmdline_ptr)
>>   goto fail;
>>   hdr->cmd_line_ptr = (unsigned long)cmdline_ptr;
>>diff --git a/drivers/firmware/efi/efi-stub-helper.c
>>b/drivers/firmware/efi/efi-stub-helper.c
>>index 335d17d..8331892 100644
>>--- a/drivers/firmware/efi/efi-stub-helper.c
>>+++ b/drivers/firmware/efi/efi-stub-helper.c
>>@@ -548,61 +548,111 @@ static efi_status_t
>>efi_relocate_kernel(efi_system_table_t *sys_table_arg,
>>
>>   return status;
>> }
>>-/* Convert the unicode UEFI command line to ASCII to pass to kernel.
>>+
>>+/*
>>+ * Get the number of UTF-8 bytes corresponding to an UTF-16 character.
>>+ * This overestimates for surrogates, but that is okay.
>>+ */
>>+static int efi_utf8_bytes(u16 c)
>>+{
>>+  return 1 + (c >= 0x80) + (c >= 0x800);
>>+}
>>+
>>+/*
>>+ * Convert an UTF-16 string, not necessarily null terminated, to
>>UTF-8.
>>+ */
>>+static u8 *efi_utf16_to_utf8(u8 *dst, const u16 *src, int n)
>>+{
>>+  unsigned int c;
>>+
>>+  while (n--) {
>>+  c = *src++;
>>+  if (n && c >= 0xd800 && c <= 0xdbff &&
>>+  *src >= 0xdc00 && *src <= 0xdfff) {
>>+  c = 0x1 + ((c & 0x3ff) << 10) + (*src & 0x3ff);
>>+  src++;
>>+  n--;
>>+  }
>>+  if (c >= 0xd800 && c <= 0xdfff)
>>+  c = 0xfffd; /* Unmatched surrogate */
>>+  if (c < 0x80) {
>>+  *dst++ = c;
>>+  continue;
>>+  }
>>+  if (c < 0x800) {
>>+  *dst++ = 0xc0 + (c >> 6);
>>+  goto t1;
>>+  }
>>+  if (c < 0x1) {
>>+  *dst++ = 0xe0 + (c >> 12);
>>+  goto t2;
>>+  }
>>+  *dst++ = 0xf0 + (c >> 18);
>>+  *dst++ = 0x80 + ((c >> 12) & 0x3f);
>>+t2:
>>+  *dst++ = 0x80 + ((c >> 6) & 0x3f);
>>+t1:
>>+  *dst++ = 0x80 + (c & 0x3f);
>>+  }
>>+
>>+  return dst;
>>+}
>>+
>>+/*
>>+ * Convert the unicode UEFI command line to ASCII to pass to kernel.
>>  * Size of memory allocated return in *cmd_line_len.
>>  * Returns NULL on error.
>>  */
>>-static char *efi_convert_cmdline_to_ascii(efi_system_table_t
>>*sys_table_arg,
>>-efi_loaded_image_t *image,
>>-int *cmd_line_len)
>>+static char *efi_convert_cmdline(efi_system_table_t *sys_table_arg,
>>+   efi_loaded_image_t *image,
>>+   int *cmd_line_len)
>> {
>>-  u16 *s2;
>>+  const u16 *s2;
>>   u8 *s1 = NULL;
>>   unsigned long cmdline_addr = 0;
>>   int load_options_size = image->load_options_size / 2; /* ASCII */
>>-  void *options = image->load_options;
>>-  int options_size = 0;
>>+  const u16 *options = image->load_options;
>>+  int options_bytes = 0;  /* UTF-8 bytes */
>>+  int options_chars = 0;  /* UTF-16 chars */
>>   efi_status_t status;
>>-  int i;
>>   u16 zero = 0;
>>
>>   if (options) {
>>   s2 = options;
>>-  while (*s2 && *s2 != '\n' && options_size < load_options_size) 
>>{
>>+  while (*s2 && *s2 != '\n' && options_bytes < 
>>load_options_size) {
>>+  options_bytes +=

Re: [PATCH] block: Device driver for sTec's PCIe Kronos Card.

2013-09-22 Thread Olof Johansson

On Sat, Sep 21, 2013 at 1:01 PM, Jens Axboe  wrote:
> On Fri, Sep 20 2013, Andrew Morton wrote:
>> On Tue, 17 Sep 2013 14:20:55 -0600 Jens Axboe  wrote:
>>
>> > > So, it looks like this driver needs a bunch of work before it's ready
>> > > to go in. Or, maybe it's better to submit it with a TODO list for the
>> > > staging tree instead?
>> >
>> > Not disagreeing with you, it definitely needs a bit of cleaning. And so
>> > far stec has not been very responsive in fixing those issues.
>>
>> Geeze.  Here's what I came up with, mainly to make i386 compile:
>
> Thanks Andrew. It's not the fixes themselves that are tricky, I would
> just have liked a little more proof that the submission wasn't just a
> dump'n run.

Well, that's what much of the staging process is about, since it needs
to come with a todo list (and that list needs to be taken care of
before the driver graduates). Honestly, this looks like a prime
candidate for that. But it's your tree and your call.

Thanks for applying the patch from Andrew, that resolves most of it
for me right now.


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

Re: [PATCH 1/1] arch/parisc: mm: fix uninitialized variable usage

2013-09-22 Thread Johannes Weiner

Hello Felipe,

On Sun, Sep 22, 2013 at 03:17:46PM -0300, Felipe Pena wrote:
> The FAULT_FLAG_WRITE flag has been set based on uninitialized variable

Oops, you are right.

> Signed-off-by: Felipe Pena 
> ---
>  arch/parisc/mm/fault.c |5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/parisc/mm/fault.c b/arch/parisc/mm/fault.c
> index d10d27a..6b38026 100644
> --- a/arch/parisc/mm/fault.c
> +++ b/arch/parisc/mm/fault.c
> @@ -182,8 +182,6 @@ void do_page_fault(struct pt_regs *regs, unsigned long 
> code,
>  
>   if (user_mode(regs))
>   flags |= FAULT_FLAG_USER;
> - if (acc_type & VM_WRITE)
> - flags |= FAULT_FLAG_WRITE;
>  retry:
>   down_read(>mmap_sem);
>   vma = find_vma_prev(mm, address, _vma);
> @@ -201,6 +199,9 @@ good_area:
>   if ((vma->vm_flags & acc_type) != acc_type)
>   goto bad_area;
>  
> + if (acc_type & VM_WRITE)
> + flags |= FAULT_FLAG_WRITE;

Can acc_type actually change between between the first round and a
retry?  Otherwise, it might make sense to pull this up and place it
next to the flag initialization instead of pulling one flag down.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 10/18] Do proper conversion from UTF-16 to UTF-8

Sorry this version is broken and doesn't even compile due to remaining 
options_size references.

Roy Franz  wrote:
>From: "H. Peter Anvin" 
>
>Improve the conversion of the UTF-16 EFI command line
>to UTF-8 for passing to the kernel.
>
>Signed-off-by: Roy Franz 
>---
> arch/x86/boot/compressed/eboot.c   |3 +-
>drivers/firmware/efi/efi-stub-helper.c |   92
>
> 2 files changed, 72 insertions(+), 23 deletions(-)
>
>diff --git a/arch/x86/boot/compressed/eboot.c
>b/arch/x86/boot/compressed/eboot.c
>index 5e708c0..4723dc89 100644
>--- a/arch/x86/boot/compressed/eboot.c
>+++ b/arch/x86/boot/compressed/eboot.c
>@@ -486,8 +486,7 @@ struct boot_params *make_boot_params(void *handle,
>efi_system_table_t *_table)
>   hdr->type_of_loader = 0x21;
> 
>   /* Convert unicode cmdline to ascii */
>-  cmdline_ptr = efi_convert_cmdline_to_ascii(sys_table, image,
>- _size);
>+  cmdline_ptr = efi_convert_cmdline(sys_table, image, _size);
>   if (!cmdline_ptr)
>   goto fail;
>   hdr->cmd_line_ptr = (unsigned long)cmdline_ptr;
>diff --git a/drivers/firmware/efi/efi-stub-helper.c
>b/drivers/firmware/efi/efi-stub-helper.c
>index 335d17d..8331892 100644
>--- a/drivers/firmware/efi/efi-stub-helper.c
>+++ b/drivers/firmware/efi/efi-stub-helper.c
>@@ -548,61 +548,111 @@ static efi_status_t
>efi_relocate_kernel(efi_system_table_t *sys_table_arg,
> 
>   return status;
> }
>-/* Convert the unicode UEFI command line to ASCII to pass to kernel.
>+
>+/*
>+ * Get the number of UTF-8 bytes corresponding to an UTF-16 character.
>+ * This overestimates for surrogates, but that is okay.
>+ */
>+static int efi_utf8_bytes(u16 c)
>+{
>+  return 1 + (c >= 0x80) + (c >= 0x800);
>+}
>+
>+/*
>+ * Convert an UTF-16 string, not necessarily null terminated, to
>UTF-8.
>+ */
>+static u8 *efi_utf16_to_utf8(u8 *dst, const u16 *src, int n)
>+{
>+  unsigned int c;
>+
>+  while (n--) {
>+  c = *src++;
>+  if (n && c >= 0xd800 && c <= 0xdbff &&
>+  *src >= 0xdc00 && *src <= 0xdfff) {
>+  c = 0x1 + ((c & 0x3ff) << 10) + (*src & 0x3ff);
>+  src++;
>+  n--;
>+  }
>+  if (c >= 0xd800 && c <= 0xdfff)
>+  c = 0xfffd; /* Unmatched surrogate */
>+  if (c < 0x80) {
>+  *dst++ = c;
>+  continue;
>+  }
>+  if (c < 0x800) {
>+  *dst++ = 0xc0 + (c >> 6);
>+  goto t1;
>+  }
>+  if (c < 0x1) {
>+  *dst++ = 0xe0 + (c >> 12);
>+  goto t2;
>+  }
>+  *dst++ = 0xf0 + (c >> 18);
>+  *dst++ = 0x80 + ((c >> 12) & 0x3f);
>+t2:
>+  *dst++ = 0x80 + ((c >> 6) & 0x3f);
>+t1:
>+  *dst++ = 0x80 + (c & 0x3f);
>+  }
>+
>+  return dst;
>+}
>+
>+/*
>+ * Convert the unicode UEFI command line to ASCII to pass to kernel.
>  * Size of memory allocated return in *cmd_line_len.
>  * Returns NULL on error.
>  */
>-static char *efi_convert_cmdline_to_ascii(efi_system_table_t
>*sys_table_arg,
>-efi_loaded_image_t *image,
>-int *cmd_line_len)
>+static char *efi_convert_cmdline(efi_system_table_t *sys_table_arg,
>+   efi_loaded_image_t *image,
>+   int *cmd_line_len)
> {
>-  u16 *s2;
>+  const u16 *s2;
>   u8 *s1 = NULL;
>   unsigned long cmdline_addr = 0;
>   int load_options_size = image->load_options_size / 2; /* ASCII */
>-  void *options = image->load_options;
>-  int options_size = 0;
>+  const u16 *options = image->load_options;
>+  int options_bytes = 0;  /* UTF-8 bytes */
>+  int options_chars = 0;  /* UTF-16 chars */
>   efi_status_t status;
>-  int i;
>   u16 zero = 0;
> 
>   if (options) {
>   s2 = options;
>-  while (*s2 && *s2 != '\n' && options_size < load_options_size) {
>+  while (*s2 && *s2 != '\n' && options_bytes < load_options_size) 
>{
>+  options_bytes += efi_utf8_bytes(*s2);
>   s2++;
>-  options_size++;
>   }
>+  options_chars = s2 - options;
>   }
> 
>-  if (options_size == 0) {
>-  /* No command line options, so return empty string*/
>-  options_size = 1;
>+  if (!options_chars) {
>+  /* No command line options, so return empty string */
>   options = 
>   }
> 
>-  options_size++;  /* NUL termination */
>+  options_bytes++;/* NUL termination */
>+
> #ifdef CONFIG_ARM
>   /* For ARM, allocate at a high address to avoid reserved
>* regions at low addresses that we

[PATCH 11/18] Rename __get_map() to efi_get_memory_map()

Rename function in preparation for making it more flexible
and sharing it.

Signed-off-by: Roy Franz 
---
 drivers/firmware/efi/efi-stub-helper.c |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/firmware/efi/efi-stub-helper.c 
b/drivers/firmware/efi/efi-stub-helper.c
index 8331892..4ac274b 100644
--- a/drivers/firmware/efi/efi-stub-helper.c
+++ b/drivers/firmware/efi/efi-stub-helper.c
@@ -46,10 +46,10 @@ static void efi_printk(efi_system_table_t *sys_table_arg, 
char *str)
 }
 
 
-static efi_status_t __get_map(efi_system_table_t *sys_table_arg,
- efi_memory_desc_t **map,
- unsigned long *map_size,
- unsigned long *desc_size)
+static efi_status_t efi_get_memory_map(efi_system_table_t *sys_table_arg,
+  efi_memory_desc_t **map,
+  unsigned long *map_size,
+  unsigned long *desc_size)
 {
efi_memory_desc_t *m = NULL;
efi_status_t status;
@@ -97,7 +97,7 @@ static efi_status_t efi_high_alloc(efi_system_table_t 
*sys_table_arg,
u64 max_addr = 0;
int i;
 
-   status = __get_map(sys_table_arg, , _size, _size);
+   status = efi_get_memory_map(sys_table_arg, , _size, _size);
if (status != EFI_SUCCESS)
goto fail;
 
@@ -182,7 +182,7 @@ static efi_status_t efi_low_alloc(efi_system_table_t 
*sys_table_arg,
unsigned long nr_pages;
int i;
 
-   status = __get_map(sys_table_arg, , _size, _size);
+   status = efi_get_memory_map(sys_table_arg, , _size, _size);
if (status != EFI_SUCCESS)
goto fail;
 
-- 
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 02/18] Add proper definitions for some EFI function pointers.

The x86/AMD64 EFI stubs must use a call wrapper to convert between
the Linux and EFI ABIs, so void pointers are sufficient.  For ARM,
the ABIs are compatible, so we can directly invoke the function
pointers.  The functions that are used by the ARM stub are updated
to match the EFI definitions.
Also add some EFI types used by EFI functions.

Signed-off-by: Roy Franz 
Acked-by: Mark Salter 
Reviewed-by: Grant Likely 
---
 arch/x86/boot/compressed/eboot.h |8 --
 include/linux/efi.h  |   50 ++
 2 files changed, 34 insertions(+), 24 deletions(-)

diff --git a/arch/x86/boot/compressed/eboot.h b/arch/x86/boot/compressed/eboot.h
index e5b0a8f..0226510 100644
--- a/arch/x86/boot/compressed/eboot.h
+++ b/arch/x86/boot/compressed/eboot.h
@@ -10,8 +10,6 @@
 #define SEG_GRANULARITY_4KB(1 << 0)
 
 #define DESC_TYPE_CODE_DATA(1 << 0)
-
-#define EFI_PAGE_SIZE  (1UL << EFI_PAGE_SHIFT)
 #define EFI_READ_CHUNK_SIZE(1024 * 1024)
 
 #define EFI_CONSOLE_OUT_DEVICE_GUID\
@@ -62,10 +60,4 @@ struct efi_uga_draw_protocol {
void *blt;
 };
 
-struct efi_simple_text_output_protocol {
-   void *reset;
-   void *output_string;
-   void *test_string;
-};
-
 #endif /* BOOT_COMPRESSED_EBOOT_H */
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 5f8f176..840ab28 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -39,6 +39,8 @@
 typedef unsigned long efi_status_t;
 typedef u8 efi_bool_t;
 typedef u16 efi_char16_t;  /* UNICODE character */
+typedef u64 efi_physical_addr_t;
+typedef void *efi_handle_t;
 
 
 typedef struct {
@@ -96,6 +98,7 @@ typedef   struct {
 #define EFI_MEMORY_DESCRIPTOR_VERSION  1
 
 #define EFI_PAGE_SHIFT 12
+#define EFI_PAGE_SIZE  (1UL << EFI_PAGE_SHIFT)
 
 typedef struct {
u32 type;
@@ -157,11 +160,13 @@ typedef struct {
efi_table_hdr_t hdr;
void *raise_tpl;
void *restore_tpl;
-   void *allocate_pages;
-   void *free_pages;
-   void *get_memory_map;
-   void *allocate_pool;
-   void *free_pool;
+   efi_status_t (*allocate_pages)(int, int, unsigned long,
+  efi_physical_addr_t *);
+   efi_status_t (*free_pages)(efi_physical_addr_t, unsigned long);
+   efi_status_t (*get_memory_map)(unsigned long *, void *, unsigned long *,
+  unsigned long *, u32 *);
+   efi_status_t (*allocate_pool)(int, unsigned long, void **);
+   efi_status_t (*free_pool)(void *);
void *create_event;
void *set_timer;
void *wait_for_event;
@@ -171,7 +176,7 @@ typedef struct {
void *install_protocol_interface;
void *reinstall_protocol_interface;
void *uninstall_protocol_interface;
-   void *handle_protocol;
+   efi_status_t (*handle_protocol)(efi_handle_t, efi_guid_t *, void **);
void *__reserved;
void *register_protocol_notify;
void *locate_handle;
@@ -181,7 +186,7 @@ typedef struct {
void *start_image;
void *exit;
void *unload_image;
-   void *exit_boot_services;
+   efi_status_t (*exit_boot_services)(efi_handle_t, unsigned long);
void *get_next_monotonic_count;
void *stall;
void *set_watchdog_timer;
@@ -488,10 +493,6 @@ typedef struct {
unsigned long unload;
 } efi_loaded_image_t;
 
-typedef struct {
-   u64 revision;
-   void *open_volume;
-} efi_file_io_interface_t;
 
 typedef struct {
u64 size;
@@ -504,20 +505,30 @@ typedef struct {
efi_char16_t filename[1];
 } efi_file_info_t;
 
-typedef struct {
+typedef struct _efi_file_handle {
u64 revision;
-   void *open;
-   void *close;
+   efi_status_t (*open)(struct _efi_file_handle *,
+struct _efi_file_handle **,
+efi_char16_t *, u64, u64);
+   efi_status_t (*close)(struct _efi_file_handle *);
void *delete;
-   void *read;
+   efi_status_t (*read)(struct _efi_file_handle *, unsigned long *,
+void *);
void *write;
void *get_position;
void *set_position;
-   void *get_info;
+   efi_status_t (*get_info)(struct _efi_file_handle *, efi_guid_t *,
+   unsigned long *, void *);
void *set_info;
void *flush;
 } efi_file_handle_t;
 
+typedef struct _efi_file_io_interface {
+   u64 revision;
+   int (*open_volume)(struct _efi_file_io_interface *,
+  efi_file_handle_t **);
+} efi_file_io_interface_t;
+
 #define EFI_FILE_MODE_READ 0x0001
 #define EFI_FILE_MODE_WRITE0x0002
 #define EFI_FILE_MODE_CREATE   0x8000
@@ -784,6 +795,13 @@ struct efivar_entry {
struct kobject kobj;
 };
 
+
+struct efi_simple_text_output_protocol {
+   void *reset;
+   efi_status_t (*output_string)(void *,

[PATCH 03/18] Move common EFI stub code from x86 arch code to common location

No code changes made, just moving functions and #define from x86 arch
directory to common location.  Code is shared using #include, similar
to how decompression code is shared among architectures.

Signed-off-by: Roy Franz 
Acked-by: Mark Salter 
Reviewed-by: Grant Likely 
---
 arch/x86/boot/compressed/eboot.c   |  442 +-
 arch/x86/boot/compressed/eboot.h   |1 -
 drivers/firmware/efi/efi-stub-helper.c |  463 
 3 files changed, 464 insertions(+), 442 deletions(-)
 create mode 100644 drivers/firmware/efi/efi-stub-helper.c

diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index b7388a4..ab0eefc 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -19,214 +19,10 @@
 
 static efi_system_table_t *sys_table;
 
-static void efi_char16_printk(efi_char16_t *str)
-{
-   struct efi_simple_text_output_protocol *out;
-
-   out = (struct efi_simple_text_output_protocol *)sys_table->con_out;
-   efi_call_phys2(out->output_string, out, str);
-}
-
-static void efi_printk(char *str)
-{
-   char *s8;
-
-   for (s8 = str; *s8; s8++) {
-   efi_char16_t ch[2] = { 0 };
-
-   ch[0] = *s8;
-   if (*s8 == '\n') {
-   efi_char16_t nl[2] = { '\r', 0 };
-   efi_char16_printk(nl);
-   }
-
-   efi_char16_printk(ch);
-   }
-}
-
-static efi_status_t __get_map(efi_memory_desc_t **map, unsigned long *map_size,
- unsigned long *desc_size)
-{
-   efi_memory_desc_t *m = NULL;
-   efi_status_t status;
-   unsigned long key;
-   u32 desc_version;
-
-   *map_size = sizeof(*m) * 32;
-again:
-   /*
-* Add an additional efi_memory_desc_t because we're doing an
-* allocation which may be in a new descriptor region.
-*/
-   *map_size += sizeof(*m);
-   status = efi_call_phys3(sys_table->boottime->allocate_pool,
-   EFI_LOADER_DATA, *map_size, (void **));
-   if (status != EFI_SUCCESS)
-   goto fail;
-
-   status = efi_call_phys5(sys_table->boottime->get_memory_map, map_size,
-   m, , desc_size, _version);
-   if (status == EFI_BUFFER_TOO_SMALL) {
-   efi_call_phys1(sys_table->boottime->free_pool, m);
-   goto again;
-   }
-
-   if (status != EFI_SUCCESS)
-   efi_call_phys1(sys_table->boottime->free_pool, m);
-
-fail:
-   *map = m;
-   return status;
-}
-
-/*
- * Allocate at the highest possible address that is not above 'max'.
- */
-static efi_status_t high_alloc(unsigned long size, unsigned long align,
- unsigned long *addr, unsigned long max)
-{
-   unsigned long map_size, desc_size;
-   efi_memory_desc_t *map;
-   efi_status_t status;
-   unsigned long nr_pages;
-   u64 max_addr = 0;
-   int i;
-
-   status = __get_map(, _size, _size);
-   if (status != EFI_SUCCESS)
-   goto fail;
-
-   nr_pages = round_up(size, EFI_PAGE_SIZE) / EFI_PAGE_SIZE;
-again:
-   for (i = 0; i < map_size / desc_size; i++) {
-   efi_memory_desc_t *desc;
-   unsigned long m = (unsigned long)map;
-   u64 start, end;
-
-   desc = (efi_memory_desc_t *)(m + (i * desc_size));
-   if (desc->type != EFI_CONVENTIONAL_MEMORY)
-   continue;
-
-   if (desc->num_pages < nr_pages)
-   continue;
 
-   start = desc->phys_addr;
-   end = start + desc->num_pages * (1UL << EFI_PAGE_SHIFT);
+#include "../../../../drivers/firmware/efi/efi-stub-helper.c"
 
-   if ((start + size) > end || (start + size) > max)
-   continue;
-
-   if (end - size > max)
-   end = max;
-
-   if (round_down(end - size, align) < start)
-   continue;
-
-   start = round_down(end - size, align);
-
-   /*
-* Don't allocate at 0x0. It will confuse code that
-* checks pointers against NULL.
-*/
-   if (start == 0x0)
-   continue;
-
-   if (start > max_addr)
-   max_addr = start;
-   }
-
-   if (!max_addr)
-   status = EFI_NOT_FOUND;
-   else {
-   status = efi_call_phys4(sys_table->boottime->allocate_pages,
-   EFI_ALLOCATE_ADDRESS, EFI_LOADER_DATA,
-   nr_pages, _addr);
-   if (status != EFI_SUCCESS) {
-   max = max_addr;
-   max_addr = 0;
-   goto again;
-   }
-
-   *addr = max_addr;
-   }
-
-free_pool:
-

[PATCH 04/18] Add system table pointer argument to shared functions.

Add system table pointer argument to shared EFI stub related functions
so they no longer use a global system table pointer as they did when part
of eboot.c.  For the ARM EFI stub this allows us to avoid global
variables completely and thereby not have to deal with GOT fixups.
Not having the EFI stub fixup its GOT, which is shared with the
decompressor, simplifies the relocating of the zImage to a
bootable address.


Signed-off-by: Roy Franz 
---
 arch/x86/boot/compressed/eboot.c   |   38 +++--
 drivers/firmware/efi/efi-stub-helper.c |   96 +---
 2 files changed, 72 insertions(+), 62 deletions(-)

diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index ab0eefc..65b6a34 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -453,13 +453,13 @@ struct boot_params *make_boot_params(void *handle, 
efi_system_table_t *_table)
status = efi_call_phys3(sys_table->boottime->handle_protocol,
handle, , (void *));
if (status != EFI_SUCCESS) {
-   efi_printk("Failed to get handle for LOADED_IMAGE_PROTOCOL\n");
+   efi_printk(sys_table, "Failed to get handle for 
LOADED_IMAGE_PROTOCOL\n");
return NULL;
}
 
-   status = low_alloc(0x4000, 1, (unsigned long *)_params);
+   status = low_alloc(sys_table, 0x4000, 1, (unsigned long *)_params);
if (status != EFI_SUCCESS) {
-   efi_printk("Failed to alloc lowmem for boot params\n");
+   efi_printk(sys_table, "Failed to alloc lowmem for boot 
params\n");
return NULL;
}
 
@@ -503,9 +503,10 @@ struct boot_params *make_boot_params(void *handle, 
efi_system_table_t *_table)
 
options_size++; /* NUL termination */
 
-   status = low_alloc(options_size, 1, );
+   status = low_alloc(sys_table, options_size, 1,
+  );
if (status != EFI_SUCCESS) {
-   efi_printk("Failed to alloc mem for cmdline\n");
+   efi_printk(sys_table, "Failed to alloc mem for 
cmdline\n");
goto fail;
}
 
@@ -529,16 +530,16 @@ struct boot_params *make_boot_params(void *handle, 
efi_system_table_t *_table)
 
memset(sdt, 0, sizeof(*sdt));
 
-   status = handle_ramdisks(image, hdr);
+   status = handle_ramdisks(sys_table, image, hdr);
if (status != EFI_SUCCESS)
goto fail2;
 
return boot_params;
 fail2:
if (options_size)
-   low_free(options_size, hdr->cmd_line_ptr);
+   low_free(sys_table, options_size, hdr->cmd_line_ptr);
 fail:
-   low_free(0x4000, (unsigned long)boot_params);
+   low_free(sys_table, 0x4000, (unsigned long)boot_params);
return NULL;
 }
 
@@ -561,7 +562,7 @@ static efi_status_t exit_boot(struct boot_params 
*boot_params,
 again:
size += sizeof(*mem_map) * 2;
_size = size;
-   status = low_alloc(size, 1, (unsigned long *)_map);
+   status = low_alloc(sys_table, size, 1, (unsigned long *)_map);
if (status != EFI_SUCCESS)
return status;
 
@@ -569,7 +570,7 @@ get_map:
status = efi_call_phys5(sys_table->boottime->get_memory_map, ,
mem_map, , _size, _version);
if (status == EFI_BUFFER_TOO_SMALL) {
-   low_free(_size, (unsigned long)mem_map);
+   low_free(sys_table, _size, (unsigned long)mem_map);
goto again;
}
 
@@ -671,7 +672,7 @@ get_map:
return EFI_SUCCESS;
 
 free_mem_map:
-   low_free(_size, (unsigned long)mem_map);
+   low_free(sys_table, _size, (unsigned long)mem_map);
return status;
 }
 
@@ -694,10 +695,10 @@ static efi_status_t relocate_kernel(struct setup_header 
*hdr)
EFI_ALLOCATE_ADDRESS, EFI_LOADER_DATA,
nr_pages, );
if (status != EFI_SUCCESS) {
-   status = low_alloc(hdr->init_size, hdr->kernel_alignment,
-  );
+   status = low_alloc(sys_table, hdr->init_size,
+  hdr->kernel_alignment, );
if (status != EFI_SUCCESS)
-   efi_printk("Failed to alloc mem for kernel\n");
+   efi_printk(sys_table, "Failed to alloc mem for 
kernel\n");
}
 
if (status == EFI_SUCCESS)
@@ -737,14 +738,15 @@ struct boot_params *efi_main(void *handle, 
efi_system_table_t *_table,
EFI_LOADER_DATA, sizeof(*gdt),
(void **));
if (status != EFI_SUCCESS) {
-   efi_printk("Failed to alloc mem for gdt structure\n");
+   efi_printk(sys_table, "Failed to

[PATCH 10/18] Do proper conversion from UTF-16 to UTF-8

From: "H. Peter Anvin" 

Improve the conversion of the UTF-16 EFI command line
to UTF-8 for passing to the kernel.

Signed-off-by: Roy Franz 
---
 arch/x86/boot/compressed/eboot.c   |3 +-
 drivers/firmware/efi/efi-stub-helper.c |   92 
 2 files changed, 72 insertions(+), 23 deletions(-)

diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 5e708c0..4723dc89 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -486,8 +486,7 @@ struct boot_params *make_boot_params(void *handle, 
efi_system_table_t *_table)
hdr->type_of_loader = 0x21;
 
/* Convert unicode cmdline to ascii */
-   cmdline_ptr = efi_convert_cmdline_to_ascii(sys_table, image,
-  _size);
+   cmdline_ptr = efi_convert_cmdline(sys_table, image, _size);
if (!cmdline_ptr)
goto fail;
hdr->cmd_line_ptr = (unsigned long)cmdline_ptr;
diff --git a/drivers/firmware/efi/efi-stub-helper.c 
b/drivers/firmware/efi/efi-stub-helper.c
index 335d17d..8331892 100644
--- a/drivers/firmware/efi/efi-stub-helper.c
+++ b/drivers/firmware/efi/efi-stub-helper.c
@@ -548,61 +548,111 @@ static efi_status_t 
efi_relocate_kernel(efi_system_table_t *sys_table_arg,
 
return status;
 }
-/* Convert the unicode UEFI command line to ASCII to pass to kernel.
+
+/*
+ * Get the number of UTF-8 bytes corresponding to an UTF-16 character.
+ * This overestimates for surrogates, but that is okay.
+ */
+static int efi_utf8_bytes(u16 c)
+{
+   return 1 + (c >= 0x80) + (c >= 0x800);
+}
+
+/*
+ * Convert an UTF-16 string, not necessarily null terminated, to UTF-8.
+ */
+static u8 *efi_utf16_to_utf8(u8 *dst, const u16 *src, int n)
+{
+   unsigned int c;
+
+   while (n--) {
+   c = *src++;
+   if (n && c >= 0xd800 && c <= 0xdbff &&
+   *src >= 0xdc00 && *src <= 0xdfff) {
+   c = 0x1 + ((c & 0x3ff) << 10) + (*src & 0x3ff);
+   src++;
+   n--;
+   }
+   if (c >= 0xd800 && c <= 0xdfff)
+   c = 0xfffd; /* Unmatched surrogate */
+   if (c < 0x80) {
+   *dst++ = c;
+   continue;
+   }
+   if (c < 0x800) {
+   *dst++ = 0xc0 + (c >> 6);
+   goto t1;
+   }
+   if (c < 0x1) {
+   *dst++ = 0xe0 + (c >> 12);
+   goto t2;
+   }
+   *dst++ = 0xf0 + (c >> 18);
+   *dst++ = 0x80 + ((c >> 12) & 0x3f);
+t2:
+   *dst++ = 0x80 + ((c >> 6) & 0x3f);
+t1:
+   *dst++ = 0x80 + (c & 0x3f);
+   }
+
+   return dst;
+}
+
+/*
+ * Convert the unicode UEFI command line to ASCII to pass to kernel.
  * Size of memory allocated return in *cmd_line_len.
  * Returns NULL on error.
  */
-static char *efi_convert_cmdline_to_ascii(efi_system_table_t *sys_table_arg,
- efi_loaded_image_t *image,
- int *cmd_line_len)
+static char *efi_convert_cmdline(efi_system_table_t *sys_table_arg,
+efi_loaded_image_t *image,
+int *cmd_line_len)
 {
-   u16 *s2;
+   const u16 *s2;
u8 *s1 = NULL;
unsigned long cmdline_addr = 0;
int load_options_size = image->load_options_size / 2; /* ASCII */
-   void *options = image->load_options;
-   int options_size = 0;
+   const u16 *options = image->load_options;
+   int options_bytes = 0;  /* UTF-8 bytes */
+   int options_chars = 0;  /* UTF-16 chars */
efi_status_t status;
-   int i;
u16 zero = 0;
 
if (options) {
s2 = options;
-   while (*s2 && *s2 != '\n' && options_size < load_options_size) {
+   while (*s2 && *s2 != '\n' && options_bytes < load_options_size) 
{
+   options_bytes += efi_utf8_bytes(*s2);
s2++;
-   options_size++;
}
+   options_chars = s2 - options;
}
 
-   if (options_size == 0) {
-   /* No command line options, so return empty string*/
-   options_size = 1;
+   if (!options_chars) {
+   /* No command line options, so return empty string */
options = 
}
 
-   options_size++;  /* NUL termination */
+   options_bytes++;/* NUL termination */
+
 #ifdef CONFIG_ARM
/* For ARM, allocate at a high address to avoid reserved
 * regions at low addresses that we don't know the specfics of
 * at the time we are processing the command line.
 */
-   status = efi_high_alloc(sys_table_arg, options_size, 0,
+   status

[PATCH 08/18] Generalize relocate_kernel() for use by other architectures.

Rename relocate_kernel() to efi_relocate_kernel(), and take
parameters rather than x86 specific structure.  Add max_addr
argument as for ARM we have some address constraints that we
need to enforce when relocating the kernel.  Add alloc_size
parameter for use by ARM64 which uses an uncompressed kernel,
and needs to allocate space for BSS.

Signed-off-by: Roy Franz 
---
 arch/x86/boot/compressed/eboot.c   |   10 -
 drivers/firmware/efi/efi-stub-helper.c |   72 ++--
 2 files changed, 59 insertions(+), 23 deletions(-)

diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 5bbba86..2e997b6 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -733,10 +733,16 @@ struct boot_params *efi_main(void *handle, 
efi_system_table_t *_table,
 * address, relocate it.
 */
if (hdr->pref_address != hdr->code32_start) {
-   status = relocate_kernel(hdr);
-
+   unsigned long bzimage_addr = hdr->code32_start;
+   status = efi_relocate_kernel(sys_table, _addr,
+hdr->init_size, hdr->init_size,
+hdr->pref_address,
+hdr->kernel_alignment);
if (status != EFI_SUCCESS)
goto fail;
+
+   hdr->pref_address = hdr->code32_start;
+   hdr->code32_start = bzimage_addr;
}
 
status = exit_boot(boot_params, handle);
diff --git a/drivers/firmware/efi/efi-stub-helper.c 
b/drivers/firmware/efi/efi-stub-helper.c
index 1d5f219..9a92129 100644
--- a/drivers/firmware/efi/efi-stub-helper.c
+++ b/drivers/firmware/efi/efi-stub-helper.c
@@ -483,38 +483,68 @@ fail:
 
return status;
 }
-
-static efi_status_t relocate_kernel(struct setup_header *hdr)
+/* Relocate a kernel image, either compressed or uncompressed.
+ * In the ARM64 case, all kernel images are currently
+ * uncompressed, and as such when we relocate it we need to
+ * allocate additional space for the BSS segment. Any low
+ * memory that this function should avoid needs to be
+ * unavailable in the EFI memory map, as if the preferred
+ * address is not available the lowest available address will
+ * be used.
+ */
+static efi_status_t efi_relocate_kernel(efi_system_table_t *sys_table_arg,
+   unsigned long *image_addr,
+   unsigned long image_size,
+   unsigned long alloc_size,
+   unsigned long preferred_addr,
+   unsigned long alignment)
 {
-   unsigned long start, nr_pages;
+   unsigned long cur_image_addr;
+   unsigned long new_addr = 0;
efi_status_t status;
+   unsigned long nr_pages;
+   efi_physical_addr_t efi_addr = preferred_addr;
+
+   if (!image_addr || !image_size || !alloc_size)
+   return EFI_INVALID_PARAMETER;
+   if (alloc_size < image_size)
+   return EFI_INVALID_PARAMETER;
+
+   cur_image_addr = *image_addr;
 
/*
 * The EFI firmware loader could have placed the kernel image
-* anywhere in memory, but the kernel has various restrictions
-* on the max physical address it can run at. Attempt to move
-* the kernel to boot_params.pref_address, or as low as
-* possible.
+* anywhere in memory, but the kernel has restrictions on the
+* max physical address it can run at.  Some architectures
+* also have a prefered address, so first try to relocate
+* to the preferred address.  If that fails, allocate as low
+* as possible while respecting the required alignment.
 */
-   start = hdr->pref_address;
-   nr_pages = round_up(hdr->init_size, EFI_PAGE_SIZE) / EFI_PAGE_SIZE;
-
-   status = efi_call_phys4(sys_table->boottime->allocate_pages,
+   nr_pages = round_up(alloc_size, EFI_PAGE_SIZE) / EFI_PAGE_SIZE;
+   status = efi_call_phys4(sys_table_arg->boottime->allocate_pages,
EFI_ALLOCATE_ADDRESS, EFI_LOADER_DATA,
-   nr_pages, );
+   nr_pages, _addr);
+   new_addr = efi_addr;
+   /* If preferred address allocation failed allocate as low as
+* possible. */
+   if (status != EFI_SUCCESS) {
+   status = efi_low_alloc(sys_table_arg, alloc_size, alignment,
+  _addr);
+   }
if (status != EFI_SUCCESS) {
-   status = efi_low_alloc(sys_table, hdr->init_size,
-  hdr->kernel_alignment, );
-   if (status != EFI_SUCCESS)
-   efi_printk(sys_table, "Failed to alloc mem for 
kernel\n");
+   efi_printk(sys_table_arg, "ERROR:

[PATCH 09/18] Move unicode to ASCII conversion to shared function.

Move the open-coded conversion to a shared function for
use by all architectures.  Change the allocation to prefer
a high address for ARM, as this is required to avoid conflicts
with reserved regions in low memory.  We don't know the specifics
of these regions until after we process the command line and
device tree.

Signed-off-by: Roy Franz 
---
 arch/x86/boot/compressed/eboot.c   |   43 ---
 drivers/firmware/efi/efi-stub-helper.c |   58 
 2 files changed, 64 insertions(+), 37 deletions(-)

diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 2e997b6..5e708c0 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -435,11 +435,10 @@ struct boot_params *make_boot_params(void *handle, 
efi_system_table_t *_table)
struct efi_info *efi;
efi_loaded_image_t *image;
void *options;
-   u32 load_options_size;
efi_guid_t proto = LOADED_IMAGE_PROTOCOL_GUID;
int options_size = 0;
efi_status_t status;
-   unsigned long cmdline;
+   char *cmdline_ptr;
u16 *s2;
u8 *s1;
int i;
@@ -487,41 +486,11 @@ struct boot_params *make_boot_params(void *handle, 
efi_system_table_t *_table)
hdr->type_of_loader = 0x21;
 
/* Convert unicode cmdline to ascii */
-   options = image->load_options;
-   load_options_size = image->load_options_size / 2; /* ASCII */
-   cmdline = 0;
-   s2 = (u16 *)options;
-
-   if (s2) {
-   while (*s2 && *s2 != '\n' && options_size < load_options_size) {
-   s2++;
-   options_size++;
-   }
-
-   if (options_size) {
-   if (options_size > hdr->cmdline_size)
-   options_size = hdr->cmdline_size;
-
-   options_size++; /* NUL termination */
-
-   status = efi_low_alloc(sys_table, options_size, 1,
-  );
-   if (status != EFI_SUCCESS) {
-   efi_printk(sys_table, "Failed to alloc mem for 
cmdline\n");
-   goto fail;
-   }
-
-   s1 = (u8 *)(unsigned long)cmdline;
-   s2 = (u16 *)options;
-
-   for (i = 0; i < options_size - 1; i++)
-   *s1++ = *s2++;
-
-   *s1 = '\0';
-   }
-   }
-
-   hdr->cmd_line_ptr = cmdline;
+   cmdline_ptr = efi_convert_cmdline_to_ascii(sys_table, image,
+  _size);
+   if (!cmdline_ptr)
+   goto fail;
+   hdr->cmd_line_ptr = (unsigned long)cmdline_ptr;
 
hdr->ramdisk_image = 0;
hdr->ramdisk_size = 0;
diff --git a/drivers/firmware/efi/efi-stub-helper.c 
b/drivers/firmware/efi/efi-stub-helper.c
index 9a92129..335d17d 100644
--- a/drivers/firmware/efi/efi-stub-helper.c
+++ b/drivers/firmware/efi/efi-stub-helper.c
@@ -548,3 +548,61 @@ static efi_status_t efi_relocate_kernel(efi_system_table_t 
*sys_table_arg,
 
return status;
 }
+/* Convert the unicode UEFI command line to ASCII to pass to kernel.
+ * Size of memory allocated return in *cmd_line_len.
+ * Returns NULL on error.
+ */
+static char *efi_convert_cmdline_to_ascii(efi_system_table_t *sys_table_arg,
+ efi_loaded_image_t *image,
+ int *cmd_line_len)
+{
+   u16 *s2;
+   u8 *s1 = NULL;
+   unsigned long cmdline_addr = 0;
+   int load_options_size = image->load_options_size / 2; /* ASCII */
+   void *options = image->load_options;
+   int options_size = 0;
+   efi_status_t status;
+   int i;
+   u16 zero = 0;
+
+   if (options) {
+   s2 = options;
+   while (*s2 && *s2 != '\n' && options_size < load_options_size) {
+   s2++;
+   options_size++;
+   }
+   }
+
+   if (options_size == 0) {
+   /* No command line options, so return empty string*/
+   options_size = 1;
+   options = 
+   }
+
+   options_size++;  /* NUL termination */
+#ifdef CONFIG_ARM
+   /* For ARM, allocate at a high address to avoid reserved
+* regions at low addresses that we don't know the specfics of
+* at the time we are processing the command line.
+*/
+   status = efi_high_alloc(sys_table_arg, options_size, 0,
+   _addr, 0xf000);
+#else
+   status = efi_low_alloc(sys_table_arg, options_size, 0,
+   _addr);
+#endif
+   if (status != EFI_SUCCESS)
+   return NULL;
+
+   s1 = (u8 *)cmdline_addr;
+   s2 = (u16 *)options;
+
+   for (i = 0; i < options_size - 1; i++)
+

[PATCH 01/18] EFI stub documentation updates

Move efi-stub.txt out of x86 directory and into common directory
in preparation for adding ARM EFI stub support.

Signed-off-by: Roy Franz 
---
 Documentation/efi-stub.txt |   65 
 Documentation/x86/efi-stub.txt |   65 
 arch/x86/Kconfig   |2 +-
 3 files changed, 66 insertions(+), 66 deletions(-)
 create mode 100644 Documentation/efi-stub.txt
 delete mode 100644 Documentation/x86/efi-stub.txt

diff --git a/Documentation/efi-stub.txt b/Documentation/efi-stub.txt
new file mode 100644
index 000..44e6bb6
--- /dev/null
+++ b/Documentation/efi-stub.txt
@@ -0,0 +1,65 @@
+ The EFI Boot Stub
+---
+
+On the x86 platform, a bzImage can masquerade as a PE/COFF image,
+thereby convincing EFI firmware loaders to load it as an EFI
+executable. The code that modifies the bzImage header, along with the
+EFI-specific entry point that the firmware loader jumps to are
+collectively known as the "EFI boot stub", and live in
+arch/x86/boot/header.S and arch/x86/boot/compressed/eboot.c,
+respectively.
+
+By using the EFI boot stub it's possible to boot a Linux kernel
+without the use of a conventional EFI boot loader, such as grub or
+elilo. Since the EFI boot stub performs the jobs of a boot loader, in
+a certain sense it *IS* the boot loader.
+
+The EFI boot stub is enabled with the CONFIG_EFI_STUB kernel option.
+
+
+ How to install bzImage.efi
+
+The bzImage located in arch/x86/boot/bzImage must be copied to the EFI
+System Partiion (ESP) and renamed with the extension ".efi". Without
+the extension the EFI firmware loader will refuse to execute it. It's
+not possible to execute bzImage.efi from the usual Linux file systems
+because EFI firmware doesn't have support for them.
+
+
+ Passing kernel parameters from the EFI shell
+
+Arguments to the kernel can be passed after bzImage.efi, e.g.
+
+   fs0:> bzImage.efi console=ttyS0 root=/dev/sda4
+
+
+ The "initrd=" option
+
+Like most boot loaders, the EFI stub allows the user to specify
+multiple initrd files using the "initrd=" option. This is the only EFI
+stub-specific command line parameter, everything else is passed to the
+kernel when it boots.
+
+The path to the initrd file must be an absolute path from the
+beginning of the ESP, relative path names do not work. Also, the path
+is an EFI-style path and directory elements must be separated with
+backslashes (\). For example, given the following directory layout,
+
+fs0:>
+   Kernels\
+   bzImage.efi
+   initrd-large.img
+
+   Ramdisks\
+   initrd-small.img
+   initrd-medium.img
+
+to boot with the initrd-large.img file if the current working
+directory is fs0:\Kernels, the following command must be used,
+
+   fs0:\Kernels> bzImage.efi initrd=\Kernels\initrd-large.img
+
+Notice how bzImage.efi can be specified with a relative path. That's
+because the image we're executing is interpreted by the EFI shell,
+which understands relative paths, whereas the rest of the command line
+is passed to bzImage.efi.
diff --git a/Documentation/x86/efi-stub.txt b/Documentation/x86/efi-stub.txt
deleted file mode 100644
index 44e6bb6..000
--- a/Documentation/x86/efi-stub.txt
+++ /dev/null
@@ -1,65 +0,0 @@
- The EFI Boot Stub
----
-
-On the x86 platform, a bzImage can masquerade as a PE/COFF image,
-thereby convincing EFI firmware loaders to load it as an EFI
-executable. The code that modifies the bzImage header, along with the
-EFI-specific entry point that the firmware loader jumps to are
-collectively known as the "EFI boot stub", and live in
-arch/x86/boot/header.S and arch/x86/boot/compressed/eboot.c,
-respectively.
-
-By using the EFI boot stub it's possible to boot a Linux kernel
-without the use of a conventional EFI boot loader, such as grub or
-elilo. Since the EFI boot stub performs the jobs of a boot loader, in
-a certain sense it *IS* the boot loader.
-
-The EFI boot stub is enabled with the CONFIG_EFI_STUB kernel option.
-
-
- How to install bzImage.efi
-
-The bzImage located in arch/x86/boot/bzImage must be copied to the EFI
-System Partiion (ESP) and renamed with the extension ".efi". Without
-the extension the EFI firmware loader will refuse to execute it. It's
-not possible to execute bzImage.efi from the usual Linux file systems
-because EFI firmware doesn't have support for them.
-
-
- Passing kernel parameters from the EFI shell
-
-Arguments to the kernel can be passed after bzImage.efi, e.g.
-
-   fs0:> bzImage.efi console=ttyS0 root=/dev/sda4
-
-
- The "initrd=" option
-
-Like most boot loaders, the EFI stub allows the user to specify
-multiple initrd files using the "initrd=" option. This is the only EFI
-stub-specific command line parameter, everything

[PATCH 07/18] Move relocate_kernel() to shared file.

The relocate_kernel() function will be generalized and used
by all architectures, as they all have similar requirements.

Signed-off-by: Roy Franz 
---
 arch/x86/boot/compressed/eboot.c   |   34 ---
 drivers/firmware/efi/efi-stub-helper.c |   35 
 2 files changed, 35 insertions(+), 34 deletions(-)

diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 2a4430a..5bbba86 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -677,40 +677,6 @@ free_mem_map:
return status;
 }
 
-static efi_status_t relocate_kernel(struct setup_header *hdr)
-{
-   unsigned long start, nr_pages;
-   efi_status_t status;
-
-   /*
-* The EFI firmware loader could have placed the kernel image
-* anywhere in memory, but the kernel has various restrictions
-* on the max physical address it can run at. Attempt to move
-* the kernel to boot_params.pref_address, or as low as
-* possible.
-*/
-   start = hdr->pref_address;
-   nr_pages = round_up(hdr->init_size, EFI_PAGE_SIZE) / EFI_PAGE_SIZE;
-
-   status = efi_call_phys4(sys_table->boottime->allocate_pages,
-   EFI_ALLOCATE_ADDRESS, EFI_LOADER_DATA,
-   nr_pages, );
-   if (status != EFI_SUCCESS) {
-   status = efi_low_alloc(sys_table, hdr->init_size,
-  hdr->kernel_alignment, );
-   if (status != EFI_SUCCESS)
-   efi_printk(sys_table, "Failed to alloc mem for 
kernel\n");
-   }
-
-   if (status == EFI_SUCCESS)
-   memcpy((void *)start, (void *)(unsigned long)hdr->code32_start,
-  hdr->init_size);
-
-   hdr->pref_address = hdr->code32_start;
-   hdr->code32_start = (__u32)start;
-
-   return status;
-}
 
 /*
  * On success we return a pointer to a boot_params structure, and NULL
diff --git a/drivers/firmware/efi/efi-stub-helper.c 
b/drivers/firmware/efi/efi-stub-helper.c
index 9e451c6..1d5f219 100644
--- a/drivers/firmware/efi/efi-stub-helper.c
+++ b/drivers/firmware/efi/efi-stub-helper.c
@@ -483,3 +483,38 @@ fail:
 
return status;
 }
+
+static efi_status_t relocate_kernel(struct setup_header *hdr)
+{
+   unsigned long start, nr_pages;
+   efi_status_t status;
+
+   /*
+* The EFI firmware loader could have placed the kernel image
+* anywhere in memory, but the kernel has various restrictions
+* on the max physical address it can run at. Attempt to move
+* the kernel to boot_params.pref_address, or as low as
+* possible.
+*/
+   start = hdr->pref_address;
+   nr_pages = round_up(hdr->init_size, EFI_PAGE_SIZE) / EFI_PAGE_SIZE;
+
+   status = efi_call_phys4(sys_table->boottime->allocate_pages,
+   EFI_ALLOCATE_ADDRESS, EFI_LOADER_DATA,
+   nr_pages, );
+   if (status != EFI_SUCCESS) {
+   status = efi_low_alloc(sys_table, hdr->init_size,
+  hdr->kernel_alignment, );
+   if (status != EFI_SUCCESS)
+   efi_printk(sys_table, "Failed to alloc mem for 
kernel\n");
+   }
+
+   if (status == EFI_SUCCESS)
+   memcpy((void *)start, (void *)(unsigned long)hdr->code32_start,
+  hdr->init_size);
+
+   hdr->pref_address = hdr->code32_start;
+   hdr->code32_start = (__u32)start;
+
+   return status;
+}
-- 
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 05/18] Rename memory allocation/free functions

Rename them to be more similar, as low_free() could be used to free
memory allocated by both high_alloc() and low_alloc().
high_alloc() -> efi_high_alloc()
low_alloc()  -> efi_low_alloc()
low_free()   -> efi_free()

Signed-off-by: Roy Franz 
Acked-by: Mark Salter 
Reviewed-by: Grant Likely 
---
 arch/x86/boot/compressed/eboot.c   |   19 ++-
 drivers/firmware/efi/efi-stub-helper.c |   14 +++---
 2 files changed, 17 insertions(+), 16 deletions(-)

diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 65b6a34..2a4430a 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -457,7 +457,8 @@ struct boot_params *make_boot_params(void *handle, 
efi_system_table_t *_table)
return NULL;
}
 
-   status = low_alloc(sys_table, 0x4000, 1, (unsigned long *)_params);
+   status = efi_low_alloc(sys_table, 0x4000, 1,
+  (unsigned long *)_params);
if (status != EFI_SUCCESS) {
efi_printk(sys_table, "Failed to alloc lowmem for boot 
params\n");
return NULL;
@@ -503,7 +504,7 @@ struct boot_params *make_boot_params(void *handle, 
efi_system_table_t *_table)
 
options_size++; /* NUL termination */
 
-   status = low_alloc(sys_table, options_size, 1,
+   status = efi_low_alloc(sys_table, options_size, 1,
   );
if (status != EFI_SUCCESS) {
efi_printk(sys_table, "Failed to alloc mem for 
cmdline\n");
@@ -537,9 +538,9 @@ struct boot_params *make_boot_params(void *handle, 
efi_system_table_t *_table)
return boot_params;
 fail2:
if (options_size)
-   low_free(sys_table, options_size, hdr->cmd_line_ptr);
+   efi_free(sys_table, options_size, hdr->cmd_line_ptr);
 fail:
-   low_free(sys_table, 0x4000, (unsigned long)boot_params);
+   efi_free(sys_table, 0x4000, (unsigned long)boot_params);
return NULL;
 }
 
@@ -562,7 +563,7 @@ static efi_status_t exit_boot(struct boot_params 
*boot_params,
 again:
size += sizeof(*mem_map) * 2;
_size = size;
-   status = low_alloc(sys_table, size, 1, (unsigned long *)_map);
+   status = efi_low_alloc(sys_table, size, 1, (unsigned long *)_map);
if (status != EFI_SUCCESS)
return status;
 
@@ -570,7 +571,7 @@ get_map:
status = efi_call_phys5(sys_table->boottime->get_memory_map, ,
mem_map, , _size, _version);
if (status == EFI_BUFFER_TOO_SMALL) {
-   low_free(sys_table, _size, (unsigned long)mem_map);
+   efi_free(sys_table, _size, (unsigned long)mem_map);
goto again;
}
 
@@ -672,7 +673,7 @@ get_map:
return EFI_SUCCESS;
 
 free_mem_map:
-   low_free(sys_table, _size, (unsigned long)mem_map);
+   efi_free(sys_table, _size, (unsigned long)mem_map);
return status;
 }
 
@@ -695,7 +696,7 @@ static efi_status_t relocate_kernel(struct setup_header 
*hdr)
EFI_ALLOCATE_ADDRESS, EFI_LOADER_DATA,
nr_pages, );
if (status != EFI_SUCCESS) {
-   status = low_alloc(sys_table, hdr->init_size,
+   status = efi_low_alloc(sys_table, hdr->init_size,
   hdr->kernel_alignment, );
if (status != EFI_SUCCESS)
efi_printk(sys_table, "Failed to alloc mem for 
kernel\n");
@@ -743,7 +744,7 @@ struct boot_params *efi_main(void *handle, 
efi_system_table_t *_table,
}
 
gdt->size = 0x800;
-   status = low_alloc(sys_table, gdt->size, 8,
+   status = efi_low_alloc(sys_table, gdt->size, 8,
   (unsigned long *)>address);
if (status != EFI_SUCCESS) {
efi_printk(sys_table, "Failed to alloc mem for gdt\n");
diff --git a/drivers/firmware/efi/efi-stub-helper.c 
b/drivers/firmware/efi/efi-stub-helper.c
index 05c539e..2f528fb 100644
--- a/drivers/firmware/efi/efi-stub-helper.c
+++ b/drivers/firmware/efi/efi-stub-helper.c
@@ -86,7 +86,7 @@ fail:
 /*
  * Allocate at the highest possible address that is not above 'max'.
  */
-static efi_status_t high_alloc(efi_system_table_t *sys_table_arg,
+static efi_status_t efi_high_alloc(efi_system_table_t *sys_table_arg,
   unsigned long size, unsigned long align,
   unsigned long *addr, unsigned long max)
 {
@@ -165,8 +165,8 @@ fail:
 /*
  * Allocate at the lowest possible address.
  */
-static efi_status_t low_alloc(efi_system_table_t *sys_table_arg,
-   unsigned long size, unsigned long align,
+static efi_status_t efi_low_alloc(efi_system_table_t *sys_table_arg,
+ unsigned long size, unsigned long align,

[PATCH 15/18] Generalize handle_ramdisks() and rename to handle_cmdline_files().

The handle_cmdline_files now takes the option to handle as a string,
and returns the loaded data through parameters, rather than taking
an x86 specific setup_header structure.  For ARM, this will be used
to load a device tree blob in addition to initrd images.

Signed-off-by: Roy Franz 
Acked-by: Mark Salter 
Reviewed-by: Grant Likely 
---
 arch/x86/boot/compressed/eboot.c   |9 +-
 drivers/firmware/efi/efi-stub-helper.c |   51 +++-
 2 files changed, 38 insertions(+), 22 deletions(-)

diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 8b86772..a5628cd 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -442,6 +442,8 @@ struct boot_params *make_boot_params(void *handle, 
efi_system_table_t *_table)
u16 *s2;
u8 *s1;
int i;
+   unsigned long ramdisk_addr;
+   unsigned long ramdisk_size;
 
sys_table = _table;
 
@@ -499,9 +501,14 @@ struct boot_params *make_boot_params(void *handle, 
efi_system_table_t *_table)
 
memset(sdt, 0, sizeof(*sdt));
 
-   status = handle_ramdisks(sys_table, image, hdr);
+   status = handle_cmdline_files(sys_table, image,
+ (char *)(unsigned long)hdr->cmd_line_ptr,
+ "initrd=", hdr->initrd_addr_max,
+ _addr, _size);
if (status != EFI_SUCCESS)
goto fail2;
+   hdr->ramdisk_image = ramdisk_addr;
+   hdr->ramdisk_size = ramdisk_size;
 
return boot_params;
 fail2:
diff --git a/drivers/firmware/efi/efi-stub-helper.c 
b/drivers/firmware/efi/efi-stub-helper.c
index 73cf86b..d2d845f 100644
--- a/drivers/firmware/efi/efi-stub-helper.c
+++ b/drivers/firmware/efi/efi-stub-helper.c
@@ -267,9 +267,12 @@ static void efi_free(efi_system_table_t *sys_table_arg, 
unsigned long size,
  * We only support loading an initrd from the same filesystem as the
  * kernel image.
  */
-static efi_status_t handle_ramdisks(efi_system_table_t *sys_table_arg,
-   efi_loaded_image_t *image,
-   struct setup_header *hdr)
+static efi_status_t handle_cmdline_files(efi_system_table_t *sys_table_arg,
+efi_loaded_image_t *image,
+char *cmd_line, char *option_string,
+unsigned long max_addr,
+unsigned long *load_addr,
+unsigned long *load_size)
 {
struct initrd *initrds;
unsigned long initrd_addr;
@@ -285,19 +288,25 @@ static efi_status_t handle_ramdisks(efi_system_table_t 
*sys_table_arg,
initrd_addr = 0;
initrd_total = 0;
 
-   str = (char *)(unsigned long)hdr->cmd_line_ptr;
+   str = cmd_line;
 
j = 0;  /* See close_handles */
 
+   if (!load_addr || !load_size)
+   return EFI_INVALID_PARAMETER;
+
+   *load_addr = 0;
+   *load_size = 0;
+
if (!str || !*str)
return EFI_SUCCESS;
 
for (nr_initrds = 0; *str; nr_initrds++) {
-   str = strstr(str, "initrd=");
+   str = strstr(str, option_string);
if (!str)
break;
 
-   str += 7;
+   str += strlen(option_string);
 
/* Skip any leading slashes */
while (*str == '/' || *str == '\\')
@@ -315,11 +324,11 @@ static efi_status_t handle_ramdisks(efi_system_table_t 
*sys_table_arg,
nr_initrds * sizeof(*initrds),
);
if (status != EFI_SUCCESS) {
-   efi_printk(sys_table_arg, "Failed to alloc mem for initrds\n");
+   efi_printk(sys_table_arg, "Failed to alloc mem for file 
load\n");
goto fail;
}
 
-   str = (char *)(unsigned long)hdr->cmd_line_ptr;
+   str = cmd_line;
for (i = 0; i < nr_initrds; i++) {
struct initrd *initrd;
efi_file_handle_t *h;
@@ -330,11 +339,11 @@ static efi_status_t handle_ramdisks(efi_system_table_t 
*sys_table_arg,
efi_char16_t *p;
u64 file_sz;
 
-   str = strstr(str, "initrd=");
+   str = strstr(str, option_string);
if (!str)
break;
 
-   str += 7;
+   str += strlen(option_string);
 
initrd = [i];
p = filename_16;
@@ -380,7 +389,7 @@ static efi_status_t handle_ramdisks(efi_system_table_t 
*sys_table_arg,
status = efi_call_phys5(fh->open, fh, , filename_16,
EFI_FILE_MODE_READ, (u64)0);
if (status != EFI_SUCCESS) {
-   efi_printk(sys_table_arg, "Failed to open

[PATCH 13/18] use efi_get_memory_map() to get final map for x86

Replace the open-coded memory map getting with the
efi_get_memory_map() that is now general enough to use.

Signed-off-by: Roy Franz 
---
 arch/x86/boot/compressed/eboot.c |   22 +-
 1 file changed, 5 insertions(+), 17 deletions(-)

diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 4723dc89..05f11c7 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -526,25 +526,12 @@ static efi_status_t exit_boot(struct boot_params 
*boot_params,
u8 nr_entries;
int i;
 
-   size = sizeof(*mem_map) * 32;
-
-again:
-   size += sizeof(*mem_map) * 2;
-   _size = size;
-   status = efi_low_alloc(sys_table, size, 1, (unsigned long *)_map);
-   if (status != EFI_SUCCESS)
-   return status;
-
 get_map:
-   status = efi_call_phys5(sys_table->boottime->get_memory_map, ,
-   mem_map, , _size, _version);
-   if (status == EFI_BUFFER_TOO_SMALL) {
-   efi_free(sys_table, _size, (unsigned long)mem_map);
-   goto again;
-   }
+   status = efi_get_memory_map(sys_table, _map, , _size,
+   _version, );
 
if (status != EFI_SUCCESS)
-   goto free_mem_map;
+   return status;
 
memcpy(>efi_loader_signature, EFI_LOADER_SIGNATURE, sizeof(__u32));
efi->efi_systab = (unsigned long)sys_table;
@@ -573,6 +560,7 @@ get_map:
goto free_mem_map;
 
called_exit = true;
+   efi_call_phys1(sys_table->boottime->free_pool, mem_map);
goto get_map;
}
 
@@ -641,7 +629,7 @@ get_map:
return EFI_SUCCESS;
 
 free_mem_map:
-   efi_free(sys_table, _size, (unsigned long)mem_map);
+   efi_call_phys1(sys_table->boottime->free_pool, mem_map);
return status;
 }
 
-- 
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 14/18] Allow efi_free() to be called with size of 0, and do nothing in that case.

Make efi_free() safely callable with size of 0, similar to free() being
callable with NULL pointers.
Remove size checks that this makes redundant.  This also avoids some
size checks in the ARM EFI stub code that will be added as well.

Signed-off-by: Roy Franz 
---
 arch/x86/boot/compressed/eboot.c   |3 +--
 drivers/firmware/efi/efi-stub-helper.c |3 +++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 05f11c7..8b86772 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -505,8 +505,7 @@ struct boot_params *make_boot_params(void *handle, 
efi_system_table_t *_table)
 
return boot_params;
 fail2:
-   if (options_size)
-   efi_free(sys_table, options_size, hdr->cmd_line_ptr);
+   efi_free(sys_table, options_size, hdr->cmd_line_ptr);
 fail:
efi_free(sys_table, 0x4000, (unsigned long)boot_params);
return NULL;
diff --git a/drivers/firmware/efi/efi-stub-helper.c 
b/drivers/firmware/efi/efi-stub-helper.c
index b0b2f15..73cf86b 100644
--- a/drivers/firmware/efi/efi-stub-helper.c
+++ b/drivers/firmware/efi/efi-stub-helper.c
@@ -253,6 +253,9 @@ static void efi_free(efi_system_table_t *sys_table_arg, 
unsigned long size,
 {
unsigned long nr_pages;
 
+   if (!size)
+   return;
+
nr_pages = round_up(size, EFI_PAGE_SIZE) / EFI_PAGE_SIZE;
efi_call_phys2(sys_table_arg->boottime->free_pages, addr, nr_pages);
 }
-- 
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 16/18] Renames in handle_cmdline_files() to complete generalization.

Rename variables to be not initrd specific, as now the function
loads arbitrary files.  This change is exclusively renames
and comment changes to reflect the generalization.

Signed-off-by: Roy Franz 
Acked-by: Mark Salter 
Reviewed-by: Grant Likely 
---
 drivers/firmware/efi/efi-stub-helper.c |   92 
 1 file changed, 46 insertions(+), 46 deletions(-)

diff --git a/drivers/firmware/efi/efi-stub-helper.c 
b/drivers/firmware/efi/efi-stub-helper.c
index d2d845f..e2ff076 100644
--- a/drivers/firmware/efi/efi-stub-helper.c
+++ b/drivers/firmware/efi/efi-stub-helper.c
@@ -11,7 +11,7 @@
  */
 #define EFI_READ_CHUNK_SIZE(1024 * 1024)
 
-struct initrd {
+struct file_info {
efi_file_handle_t *handle;
u64 size;
 };
@@ -262,10 +262,10 @@ static void efi_free(efi_system_table_t *sys_table_arg, 
unsigned long size,
 
 
 /*
- * Check the cmdline for a LILO-style initrd= arguments.
+ * Check the cmdline for a LILO-style file= arguments.
  *
- * We only support loading an initrd from the same filesystem as the
- * kernel image.
+ * We only support loading a file from the same filesystem as
+ * the kernel image.
  */
 static efi_status_t handle_cmdline_files(efi_system_table_t *sys_table_arg,
 efi_loaded_image_t *image,
@@ -274,19 +274,19 @@ static efi_status_t 
handle_cmdline_files(efi_system_table_t *sys_table_arg,
 unsigned long *load_addr,
 unsigned long *load_size)
 {
-   struct initrd *initrds;
-   unsigned long initrd_addr;
+   struct file_info *files;
+   unsigned long file_addr;
efi_guid_t fs_proto = EFI_FILE_SYSTEM_GUID;
-   u64 initrd_total;
+   u64 file_size_total;
efi_file_io_interface_t *io;
efi_file_handle_t *fh;
efi_status_t status;
-   int nr_initrds;
+   int nr_files;
char *str;
int i, j, k;
 
-   initrd_addr = 0;
-   initrd_total = 0;
+   file_addr = 0;
+   file_size_total = 0;
 
str = cmd_line;
 
@@ -301,7 +301,7 @@ static efi_status_t handle_cmdline_files(efi_system_table_t 
*sys_table_arg,
if (!str || !*str)
return EFI_SUCCESS;
 
-   for (nr_initrds = 0; *str; nr_initrds++) {
+   for (nr_files = 0; *str; nr_files++) {
str = strstr(str, option_string);
if (!str)
break;
@@ -316,21 +316,21 @@ static efi_status_t 
handle_cmdline_files(efi_system_table_t *sys_table_arg,
str++;
}
 
-   if (!nr_initrds)
+   if (!nr_files)
return EFI_SUCCESS;
 
status = efi_call_phys3(sys_table_arg->boottime->allocate_pool,
EFI_LOADER_DATA,
-   nr_initrds * sizeof(*initrds),
-   );
+   nr_files * sizeof(*files),
+   );
if (status != EFI_SUCCESS) {
-   efi_printk(sys_table_arg, "Failed to alloc mem for file 
load\n");
+   efi_printk(sys_table_arg, "Failed to alloc mem for file handle 
list\n");
goto fail;
}
 
str = cmd_line;
-   for (i = 0; i < nr_initrds; i++) {
-   struct initrd *initrd;
+   for (i = 0; i < nr_files; i++) {
+   struct file_info *file;
efi_file_handle_t *h;
efi_file_info_t *info;
efi_char16_t filename_16[256];
@@ -345,7 +345,7 @@ static efi_status_t handle_cmdline_files(efi_system_table_t 
*sys_table_arg,
 
str += strlen(option_string);
 
-   initrd = [i];
+   file = [i];
p = filename_16;
 
/* Skip any leading slashes */
@@ -376,13 +376,13 @@ static efi_status_t 
handle_cmdline_files(efi_system_table_t *sys_table_arg,
image->device_handle, _proto, );
if (status != EFI_SUCCESS) {
efi_printk(sys_table_arg, "Failed to handle 
fs_proto\n");
-   goto free_initrds;
+   goto free_files;
}
 
status = efi_call_phys2(io->open_volume, io, );
if (status != EFI_SUCCESS) {
efi_printk(sys_table_arg, "Failed to open 
volume\n");
-   goto free_initrds;
+   goto free_files;
}
}
 
@@ -395,7 +395,7 @@ static efi_status_t handle_cmdline_files(efi_system_table_t 
*sys_table_arg,
goto close_handles;
}
 
-   initrd->handle = h;
+   file->handle = h;
 
info_sz = 0;
status = efi_call_phys4(h->get_info, h, _guid,
@@ -429,37

[PATCH 18/18] resolve warnings found on ARM compile

warnings from gcc:
warning: label 'free_pool' defined but not used [-Wunused-label]
warning: value computed is not used [-Wunused-value]




Signed-off-by: Roy Franz 
---
 drivers/firmware/efi/efi-stub-helper.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/firmware/efi/efi-stub-helper.c 
b/drivers/firmware/efi/efi-stub-helper.c
index 4e4127b..2d22aa3 100644
--- a/drivers/firmware/efi/efi-stub-helper.c
+++ b/drivers/firmware/efi/efi-stub-helper.c
@@ -169,7 +169,6 @@ again:
*addr = max_addr;
}
 
-free_pool:
efi_call_phys1(sys_table_arg->boottime->free_pool, map);
 
 fail:
@@ -242,7 +241,6 @@ static efi_status_t efi_low_alloc(efi_system_table_t 
*sys_table_arg,
if (i == map_size / desc_size)
status = EFI_NOT_FOUND;
 
-free_pool:
efi_call_phys1(sys_table_arg->boottime->free_pool, map);
 fail:
return status;
@@ -358,7 +356,7 @@ static efi_status_t handle_cmdline_files(efi_system_table_t 
*sys_table_arg,
 
if (*str == '/') {
*p++ = '\\';
-   *str++;
+   str++;
} else {
*p++ = *str++;
}
-- 
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 12/18] generalize efi_get_memory_map()

Add arguments for returning the descriptor version and also
the memory map key.  The key is required for calling
exit_boot_services().

Signed-off-by: Roy Franz 
---
 drivers/firmware/efi/efi-stub-helper.c |   14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/firmware/efi/efi-stub-helper.c 
b/drivers/firmware/efi/efi-stub-helper.c
index 4ac274b..b0b2f15 100644
--- a/drivers/firmware/efi/efi-stub-helper.c
+++ b/drivers/firmware/efi/efi-stub-helper.c
@@ -49,7 +49,9 @@ static void efi_printk(efi_system_table_t *sys_table_arg, 
char *str)
 static efi_status_t efi_get_memory_map(efi_system_table_t *sys_table_arg,
   efi_memory_desc_t **map,
   unsigned long *map_size,
-  unsigned long *desc_size)
+  unsigned long *desc_size,
+  u32 *desc_ver,
+  unsigned long *key_ptr)
 {
efi_memory_desc_t *m = NULL;
efi_status_t status;
@@ -77,6 +79,10 @@ again:
 
if (status != EFI_SUCCESS)
efi_call_phys1(sys_table_arg->boottime->free_pool, m);
+   if (key_ptr && status == EFI_SUCCESS)
+   *key_ptr = key;
+   if (desc_ver && status == EFI_SUCCESS)
+   *desc_ver = desc_version;
 
 fail:
*map = m;
@@ -97,7 +103,8 @@ static efi_status_t efi_high_alloc(efi_system_table_t 
*sys_table_arg,
u64 max_addr = 0;
int i;
 
-   status = efi_get_memory_map(sys_table_arg, , _size, _size);
+   status = efi_get_memory_map(sys_table_arg, , _size, _size,
+   NULL, NULL);
if (status != EFI_SUCCESS)
goto fail;
 
@@ -182,7 +189,8 @@ static efi_status_t efi_low_alloc(efi_system_table_t 
*sys_table_arg,
unsigned long nr_pages;
int i;
 
-   status = efi_get_memory_map(sys_table_arg, , _size, _size);
+   status = efi_get_memory_map(sys_table_arg, , _size, _size,
+   NULL, NULL);
if (status != EFI_SUCCESS)
goto fail;
 
-- 
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 17/18] Fix types in EFI calls to match EFI function definitions.

EFI calls can made directly on ARM, so the function pointers
are directly invoked.  This allows types to be checked at
compile time, so here we ensure that the parameters match
the function signature. The wrappers used by x86 prevent
any type checking.
Correct the type of chunksize to be based on native
width as specified by the EFI_FILE_PROTOCOL read()
function.

Signed-off-by: Roy Franz 
---
 drivers/firmware/efi/efi-stub-helper.c |   15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/firmware/efi/efi-stub-helper.c 
b/drivers/firmware/efi/efi-stub-helper.c
index e2ff076..4e4127b 100644
--- a/drivers/firmware/efi/efi-stub-helper.c
+++ b/drivers/firmware/efi/efi-stub-helper.c
@@ -322,7 +322,7 @@ static efi_status_t handle_cmdline_files(efi_system_table_t 
*sys_table_arg,
status = efi_call_phys3(sys_table_arg->boottime->allocate_pool,
EFI_LOADER_DATA,
nr_files * sizeof(*files),
-   );
+   (void **));
if (status != EFI_SUCCESS) {
efi_printk(sys_table_arg, "Failed to alloc mem for file handle 
list\n");
goto fail;
@@ -373,7 +373,8 @@ static efi_status_t handle_cmdline_files(efi_system_table_t 
*sys_table_arg,
boottime = sys_table_arg->boottime;
 
status = efi_call_phys3(boottime->handle_protocol,
-   image->device_handle, _proto, );
+   image->device_handle, _proto,
+   (void **));
if (status != EFI_SUCCESS) {
efi_printk(sys_table_arg, "Failed to handle 
fs_proto\n");
goto free_files;
@@ -407,7 +408,8 @@ static efi_status_t handle_cmdline_files(efi_system_table_t 
*sys_table_arg,
 
 grow:
status = efi_call_phys3(sys_table_arg->boottime->allocate_pool,
-   EFI_LOADER_DATA, info_sz, );
+   EFI_LOADER_DATA, info_sz,
+   (void **));
if (status != EFI_SUCCESS) {
efi_printk(sys_table_arg, "Failed to alloc mem for file 
info\n");
goto close_handles;
@@ -457,18 +459,19 @@ grow:
 
addr = file_addr;
for (j = 0; j < nr_files; j++) {
-   u64 size;
+   unsigned long size;
 
size = files[j].size;
while (size) {
-   u64 chunksize;
+   unsigned long chunksize;
if (size > EFI_READ_CHUNK_SIZE)
chunksize = EFI_READ_CHUNK_SIZE;
else
chunksize = size;
status = efi_call_phys3(fh->read,
files[j].handle,
-   , addr);
+   ,
+   (void *)addr);
if (status != EFI_SUCCESS) {
efi_printk(sys_table_arg, "Failed to 
read file\n");
goto free_file_total;
-- 
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, RFC 10/12] random: cap the rate which the /dev/urandom pool gets reseeded

I understand the motivation, but I question basing it in a fixed amount of time.

Theodore Ts'o  wrote:
>On Sun, Sep 22, 2013 at 02:21:48PM -0700, H. Peter Anvin wrote:
>> Is this really an improvement on a system with plenty of entropy?
>Would it not make more sense to modulate this bad on entropy production
>rates?
>> 
>> Also, the urandom pool is only reseeded once per read, no matter how
>large...
>
>I added this after observing using the random driver's tracepoints to
>measure how the entropy pool behaves on a desktop system.  It turns
>outs the Chrome browser requests a truly amazing amount of entropy
>using /dev/urandom.  Enough so that while you are reading GMail or
>using G+, the available entropy in the input pool is always running at
>minimum levels.  (i.e., it never gets above 192 bits before we do a
>catatrophic reseed and it drops down to 128 bits.)
>
>I'm not sure what the heck it is doing --- maybe it is using
>/dev/urandom to generate random padding values?  I can't believe it is
>opening new SSL connetions that quickly.  So this might be a Chrome
>bug, and I can talk to some Chrome developers when I get into work
>tomorrow.  But in the case of badly behaved applications, this is
>useful.
>
>It results in more entropy building up in the input pool before we do
>a reseed, so it should result in better "catastrophic reseeding", and
>it means that there is more entropy available in the input pool for
>use by the /dev/random pool, even if /dev/urandom is being used in
>what might be arguably considered an abusive fashion.
>
>You can test this by applying the patch, and observing the value of
>/proc/sys/kernel/random/entropy_avail over time while running a Chrome
>browser (and there may be other userspace applications which are as
>aggressive in the use of /dev/urandom).  The compare it after running
>the command "echo 0 > /proc/sys/kernel/random/urandom_min_reseed_secs",
>which will restore the original pre-patch behaviour.
>
>   - Ted

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 V5 00/18] ARM EFI stub common code

This patch is the common/x86 portion of the ARM EFI stub
patchset broken out.  These changes support the addition
of EFI stub support for the ARM and ARM64 architectures.
The common code that is now shared in efi-stub-helper.c
is based on code in the x86 stub that has been generalized
to support other architectures.



(Previously these changes were submitted as part of
the "EFI stub for ARM" patch series that included the
common/x86 changes as well as the ARM changes.)


Changes since V4:
* Fix relocate_kernel() on x86/x86_64 by adding alignment parameter.
  The alignment was previously read from the setup_header structure
  passed to relocate_kernel was was missed when converting to passing
  all values as parameters.
* Undo comment reformatting in efi-stub-helper.c
* Fix incorrect comment in eboot.c (obsolete, based on older intermediate
  version.
* Include HPA's patch for command line conversion.

Changes since V3:
* Made relocate_kernel() a shared function.
* Made command line unicode to ASCII conversion ASCII
  a shared function
* Updated efi_get_memory_map() to return descriptor version,
  and updated x86 stub to use it to retrieve final memory map.
* removed min_address argument of efi_low_alloc(), as it is
  no longer used.
* Squashed very tiny patch moving EFI_READ_CHUNK_SIZE into
  related patch.


Changes since v2:
* EFI bugfix "correct call to free_pages" that patch series
  depends on now in mainline
* remove unnecessary zimage_size variable from relocate_kernel()
* correct return types on EFI functions - should be efi_status_t, not int.

Changes since V1:
* Broke up changes to x86 and common code into more patches.
  10 more patches in this series.

H. Peter Anvin (1):
  Do proper conversion from UTF-16 to UTF-8

Roy Franz (17):
  EFI stub documentation updates
  Add proper definitions for some EFI function pointers.
  Move common EFI stub code from x86 arch code to common location
  Add system table pointer argument to shared functions.
  Rename memory allocation/free functions
  Enforce minimum alignment of 1 page on allocations.
  Move relocate_kernel() to shared file.
  Generalize relocate_kernel() for use by other architectures.
  Move unicode to ASCII conversion to shared function.
  Rename __get_map() to efi_get_memory_map()
  generalize efi_get_memory_map()
  use efi_get_memory_map() to get final map for x86
  Allow efi_free() to be called with size of 0, and do nothing in that
case.
  Generalize handle_ramdisks() and rename to handle_cmdline_files().
  Renames in handle_cmdline_files() to complete generalization.
  Fix types in EFI calls to match EFI function definitions.
  resolve warnings found on ARM compile

 Documentation/efi-stub.txt |   65 +++
 Documentation/x86/efi-stub.txt |   65 ---
 arch/x86/Kconfig   |2 +-
 arch/x86/boot/compressed/eboot.c   |  579 ++-
 arch/x86/boot/compressed/eboot.h   |9 -
 drivers/firmware/efi/efi-stub-helper.c |  679 
 include/linux/efi.h|   50 ++-
 7 files changed, 817 insertions(+), 632 deletions(-)
 create mode 100644 Documentation/efi-stub.txt
 delete mode 100644 Documentation/x86/efi-stub.txt
 create mode 100644 drivers/firmware/efi/efi-stub-helper.c

-- 
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 06/18] Enforce minimum alignment of 1 page on allocations.