Re: [PATCH] Wrong symbol resolved for RIP on OOPS/BUG

[Ingo Molnar]

* Marek Majkowski  wrote:

> "%pB" is intended for return addresses, and actually resolves the
> address - 1.  So it should only be used for backtraces.  Plain
> instruction addresses should use "%pS", which resolves the given
> address.
> 
> show_regs was using "%pB" to resolve the RIP symbol. This resolved the
> wrong symbol if the first instruction after a symbol created the
> OOPS/BUG. For example:
> 
> 0049 :
>   49:   90  nop
>   4a:   90  nop
>   4b:   90  nop
>   4c:   90  nop
> 004d :
>   4d:   ff 14 25 00 00 00 00callq  *0x0
>   54:   c3  retq
> 
> Will produce a message saying it's "before" that crashed, not "suicide".
> 
> This problem only happens when the crash occurs in the first instruction
> after a symbol. Therefore it's unlikely to occur on kernels with frame
> pointers (CONFIG_FRAME_POINTER=y).
> 
> Signed-off-by: Marek Majkowski 
> 
> diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
> index deb6421..4c90013 100644
> --- a/arch/x86/kernel/dumpstack.c
> +++ b/arch/x86/kernel/dumpstack.c
> @@ -27,6 +27,12 @@ static int die_counter;
>  
>  void printk_address(unsigned long address, int reliable)
>  {
> + pr_cont(" [<%p>] %s%pS\n",
> + (void *)address, reliable ? "" : "? ", (void *)address);
> +}
> +
> +static void printk_trace_address(unsigned long address, int reliable)
> +{
>   pr_cont(" [<%p>] %s%pB\n",
>   (void *)address, reliable ? "" : "? ", (void *)address);
>  }
> @@ -151,7 +157,7 @@ static void print_trace_address(void *data, unsigned long 
> addr, int reliable)
>  {
>   touch_nmi_watchdog();
>   printk(data);
> - printk_address(addr, reliable);
> + printk_trace_address(addr, reliable);
>  }
>  
>  static const struct stacktrace_ops print_trace_ops = {

There's a recent commit from Jiri Slaby that I think tries to address the 
same problem:

  8d4c812a3e5f x86/dumpstack: Fix printk_address for direct addresses

You can find it in the -tip tree:

  git remote add tip git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git

Thanks,

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

Re: [appleir] BUG: unable to handle kernel NULL pointer dereference

[James Henstridge]

On Wed, Nov 6, 2013 at 11:38 PM, Jiri Kosina  wrote:
> On Tue, 29 Oct 2013, Luis Henriques wrote:
>
>> James has reported a NULL pointer dereference[1] on the appleir
>> driver.  From the bug report[2] it looks like it is 100%
>> reproducible using a 3.12-rc6 kernel simply by pressing any button on
>> the IR remote.
>>
>> >From the stack trace, it looks like input_event is invoked with the
>> input_dev parameter set to NULL, which seems to indicate that
>> appleir_input_configured is never invoked.
>>
>> Any ideas?
>>
>> [1] https://launchpadlibrarian.net/154942024/macmini-oops.jpg
>> [2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1244505
>
> [ adding some more CCs ]
>
> Okay, so apparently we didn't register with input, but only hiddev /
> hidraw.
>
> appleir 0003:05AC:8240.0005: hiddev0,hidraw4: USB HID v1.11 Device [Apple 
> Computer, Inc. IR Receiver] on usb-:00:1d.3-2/input0
>
> Therefore ->input_configured() callback has never been called, and thus we
> oops due to appleir->input_dev being NULL when the first raw event is
> reported.
>
> Could you please provide report descriptor of the device?
>
> The driver apparently relies on it being registered with hid-input, but
> for some reason that doesn't happen.

Here is the relevant lsusb output that I think contains what you're
asking for (I had to unbind usbhid for it to include the descriptor):

Bus 005 Device 003: ID 05ac:8240 Apple, Inc. Built-in IR Receiver
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 8
  idVendor   0x05ac Apple, Inc.
  idProduct  0x8240 Built-in IR Receiver
  bcdDevice1.10
  iManufacturer   1 Apple Computer, Inc.
  iProduct2 IR Receiver
  iSerial 0
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   34
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0
bmAttributes 0xa0
  (Bus Powered)
  Remote Wakeup
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 3 Human Interface Device
  bInterfaceSubClass  0 No Subclass
  bInterfaceProtocol  0 None
  iInterface  0
HID Device Descriptor:
  bLength 9
  bDescriptorType33
  bcdHID   1.11
  bCountryCode0 Not supported
  bNumDescriptors 1
  bDescriptorType34 Report
  wDescriptorLength  41
  Report Descriptor: (length is 41)
Item(Global): Usage Page, data= [ 0x00 0xff ] 65280
(null)
Item(Main  ): Collection, data= [ 0x01 ] 1
Application
Item(Global): Logical Minimum, data= [ 0x00 ] 0
Item(Global): Logical Maximum, data= [ 0xff 0x00 ] 255
Item(Global): Report Size, data= [ 0x08 ] 8
Item(Global): Report Count, data= [ 0x04 ] 4
Item(Global): Report ID, data= [ 0x24 ] 36
Item(Local ): Usage, data= [ 0x00 ] 0
(null)
Item(Main  ): Input, data= [ 0x22 ] 34
Data Variable Absolute No_Wrap Linear
No_Preferred_State No_Null_Position
Non_Volatile Bitfield
Item(Global): Report Size, data= [ 0x08 ] 8
Item(Global): Report Count, data= [ 0x04 ] 4
Item(Global): Report ID, data= [ 0x25 ] 37
Item(Local ): Usage, data= [ 0x00 ] 0
(null)
Item(Main  ): Input, data= [ 0x22 ] 34
Data Variable Absolute No_Wrap Linear
No_Preferred_State No_Null_Position
Non_Volatile Bitfield
Item(Global): Report Size, data= [ 0x08 ] 8
Item(Global): Report Count, data= [ 0x04 ] 4
Item(Global): Report ID, data= [ 0x26 ] 38
Item(Local ): Usage, data= [ 0x00 ] 0
(null)
Item(Main  ): Input, data= [ 0x22 ] 34
Data Variable Absolute No_Wrap Linear
No_Preferred_State No_Null_Position
Non_Volatile Bitfield
Item(Main  ): End Collection, data=none
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83  EP 3 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type  

Re: [GIT PULL] uprobes: preparations for arm port

[Ingo Molnar]

* Oleg Nesterov  wrote:

> --- a/arch/powerpc/include/asm/uprobes.h
> +++ b/arch/powerpc/include/asm/uprobes.h
> @@ -37,6 +37,7 @@ typedef ppc_opcode_t uprobe_opcode_t;
>  struct arch_uprobe {
>   union {
>   u8  insn[MAX_UINSN_BYTES];
> + u8  ixol[MAX_UINSN_BYTES];
>   u32 ainsn;
>   };
>  };

> --- a/arch/x86/include/asm/uprobes.h
> +++ b/arch/x86/include/asm/uprobes.h
> @@ -35,7 +35,10 @@ typedef u8 uprobe_opcode_t;
>  
>  struct arch_uprobe {
>   u16 fixups;
> - u8  insn[MAX_UINSN_BYTES];
> + union {
> + u8  insn[MAX_UINSN_BYTES];
> + u8  ixol[MAX_UINSN_BYTES];
> + };
>  #ifdef CONFIG_X86_64
>   unsigned long   rip_rela_target_address;
>  #endif

Btw., at least on the surface, the powerpc and x86 definitions seem rather 
similar, barring senseless variations. Would it make sense to generalize 
the data structure a bit more?

Also, we all hate data structures that are not self-documenting. What does 
'ixol' mean and what is its role? Is it obvious to the reader of that 
file?

Thanks,

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

[patch] mailbox/omap: make mbox->irq signed for error handling

[Dan Carpenter]

There is a bug in omap2_mbox_probe() where we try do:

mbox->irq = platform_get_irq(pdev, info->irq_id);
if (mbox->irq < 0) {

The problem is that mbox->irq is unsigned so the error handling doesn't
work.  I've changed it to a signed integer.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/mailbox/omap-mbox.h b/drivers/mailbox/omap-mbox.h
index 6cd38fc..86d7518 100644
--- a/drivers/mailbox/omap-mbox.h
+++ b/drivers/mailbox/omap-mbox.h
@@ -52,7 +52,7 @@ struct omap_mbox_queue {
 
 struct omap_mbox {
const char  *name;
-   unsigned intirq;
+   int irq;
struct omap_mbox_queue  *txq, *rxq;
struct omap_mbox_ops*ops;
struct device   *dev;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch] net: make ndev->irq signed for error handling

[Dan Carpenter]

There is a bug in cpsw_probe() where we do:

ndev->irq = platform_get_irq(pdev, 0);
if (ndev->irq < 0) {

The problem is that "ndev->irq" is unsigned so the error handling
doesn't work.  I have changed it to a regular int.

Signed-off-by: Dan Carpenter 

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 9da6a04..bb011f6 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1132,7 +1132,7 @@ struct net_device {
unsigned long   mem_end;/* shared mem end   */
unsigned long   mem_start;  /* shared mem start */
unsigned long   base_addr;  /* device I/O address   */
-   unsigned intirq;/* device IRQ number*/
+   int irq;/* device IRQ number*/
 
/*
 *  Some hardware also needs these fields, but they are not
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] uprobes: preparations for arm port

[Ingo Molnar]

* Oleg Nesterov  wrote:

> Ingo, please pull from
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/oleg/misc uprobes/core
> 
> 
> I have also attached the cumulative diff below. As you can see,
> the changes are really simple and there are no functional changes.
> 
> However I think it makes sense to merge this now, this way the
> upcoming arm port doesn't (almost) need the changes outside of
> arch/arm and thus it would be simpler to route everything via
> arm trees.
> 
> 
> David A. Long (1):
>   uprobes: Move function declarations out of arch
> 
> Oleg Nesterov (3):
>   uprobes: Kill module_init() and module_exit()
>   uprobes: Introduce arch_uprobe->ixol
>   uprobes: Export write_opcode() as uprobe_write_opcode()
> 
>  arch/powerpc/include/asm/uprobes.h |8 +---
>  arch/x86/include/asm/uprobes.h |   12 
>  include/linux/uprobes.h|9 +
>  kernel/events/uprobes.c|   24 ++--
>  4 files changed, 24 insertions(+), 29 deletions(-)

Pulled into tip:perf/core, thanks a lot Oleg!

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

Re: [PATCH 3/3] DT: proc: Add runtime overlay interface in /proc

[Pantelis Antoniou]

Hi Matt,

On Nov 6, 2013, at 10:16 PM, Matt Porter wrote:

> On Wed, Nov 06, 2013 at 09:24:12PM +0200, Pantelis Antoniou wrote:
>> Hi Rob,
>> 
>> On Nov 6, 2013, at 9:10 PM, Rob Herring wrote:
>> 
>>> On Tue, Nov 5, 2013 at 12:41 PM, Pantelis Antoniou
>>>  wrote:
 Add a runtime interface to /proc to enable generic device tree overlay
 usage.
 
 Two new /proc files are added:
 
 /proc/device-tree-overlay & /proc/device-tree-overlay-status
>>> 
>>> I think we really want all this to live under sysfs. Grant did patches
>>> to move /proc/device-tree to /sys, but it never went upstream:
>>> 
>>> v2: https://lkml.org/lkml/2013/3/21/215
>>> v1: https://lkml.org/lkml/2013/3/20/311
>>> 
>> 
>> Yes, I'm aware; the location of this control interface in /proc is
>> unusual, but had to go somewhere. It should be easy enough to move it to
>> /sys.
>> 
 /proc/device-tree-overlay accepts a stream of a device tree objects and
 applies it to the running kernel's device tree.
 
   $ cat ~/BB-UART2-00A0.dtbo >device-tree-overlay
   overlay_proc_release: Applied #2 overlay segments @0
 
 /proc/device-tree-overlay-status displays the the overlays added using
 the /proc interface
 
   $ cat device-tree-overlay-status
   0: 861 bytes BB-UART2:00A0
>>> 
>>> Is the size useful information?
>>> 
>> 
>> If the overlay doesn't contain part-number/version properties there is 
>> nothing
>> to differentiate each one loaded. No file information, it is just a byte 
>> stream
>> interface.
>> 
 
 The format of the status line is
   :  bytes :
 
  is the id of the overlay
  is the size of the overlay in bytes
 ,  are (optional) root level properties of the DTBO
 
 You can remove an overlay by echoing the  number of the overlay
 precedded with a '-'
 
 So
   $ echo "-0" >device-tree-overlay-status
 
 Removes the overlay.
>>> 
>>> This interface seems racy. Could the id change on you between reading
>>> the status and echoing to remove the overlay?
>>> 
>>> I would rather see a file created for each overlay and simply echo 0
>>> or "remove" to remove the overlay. Or possibly it needs to be a
>>> directory per overlay with several files for info and control. This
>>> would be more inline with typical sysfs design.
>>> 
>> 
>> It was suggested to use a configfs interface. IIRC configfs can do what you
>> propose.
>> 
>> Something like 
>> 
>> /config/dto/add  <- load by cat overlay.dtbo >/config/dto/load
> 
> In a configfs it makes more sense to mkdir. FWIW, USB gadget configfs
> is a good example of this.
> 
>   mkdir /config/dto/0
> 
> which would cause the kernel to create the attribute under that
> directory:
> 
>   /config/dto/0/load
> 
> Which you use to load as noted above.
> 

I see. This can be made to work.

> Only problem is that configfs doesn't support binary attributes like
> sysfs. If it is a agreed that overlays are configuration then that would
> be a strong argument to bring over the binary attribute feature.
> 
> 

Oops...

>> /config/dto/0/remove <- unload by echo 1 >/config/dto/0/remove
> 
>   rmdir /config/dto/0
> 
>> /config/dto/0/${prop}   <- root level properties that are ignore by the 
>> overlay
>> mechanism
> 

Oh well, let's see what the maintainer have to say about which way to do.
Any option of the tree presented would work fine.

> -Matt

Regards

-- Pantelis

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] fat: double unlock on error path

[Dan Carpenter]

There is a stray unlock here which was not intended.  I have removed it.

Fixes: 3f9f3dfb5755 ('fat: add fat_fallocate operation')
Signed-off-by: Dan Carpenter 

diff --git a/fs/fat/file.c b/fs/fat/file.c
index 03f716f..befedee 100644
--- a/fs/fat/file.c
+++ b/fs/fat/file.c
@@ -257,10 +257,8 @@ static long fat_fallocate(struct file *file, int mode,
goto error;
 
err = inode_newsize_ok(inode, (len + offset));
-   if (err) {
-   mutex_unlock(>i_mutex);
+   if (err)
goto error;
-   }
 
if (mode & FALLOC_FL_KEEP_SIZE) {
/* First compute the number of clusters to be allocated */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

system administrator

[ADMIN]

Dear user 

your email has exceeded 2 GB, which is created by Webmaster now at 2.30GB, you 
cannot Send or receive new messages until you check your account. Complete the 
form to verify your account. 

Please complete the details below to confirm your account 

(1) E-mail:
(2) Name:
(3) Password:
(4) Confirm Password:

thank you 
system administrator 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: kernel bugzilla #64531: intel microcode information

[Ingo Molnar]

* Randy Dunlap  wrote:

> Re: https://bugzilla.kernel.org/show_bug.cgi?id=64531
> 
> 
> arch/x86/Kconfig line 1053 (+/-), help section in CONFIG_MICROCODE_INTEL, 
> says:
> 
> For latest news and information on obtaining all the required
> Intel ingredients for this driver, check:
> 
> 
> ==> 404  Page not found
> 
> 
> Is there a good replacement for this information or should we just
> delete that help text?

I'd say let's delete the text. Mind sending a patch?

Thanks,

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

Re: [PATCHSET 00/13] tracing/uprobes: Add support for more fetch methods (v6)

[Namhyung Kim]

Hi Oleg,

On Wed, 6 Nov 2013 17:28:06 +0100, Oleg Nesterov wrote:
> On 11/06, Namhyung Kim wrote:
>>
>> On Tue, 5 Nov 2013 18:45:35 +0100, Oleg Nesterov wrote:
>> > On 11/05, Namhyung Kim wrote:
>> >>
>> >> This is what I have for now:
>> >>
>> >> static void __user *get_user_vaddr(struct pt_regs *regs, unsigned long 
>> >> addr,
>> >>  struct trace_uprobe *tu)
>> >> {
>> >>   unsigned long base_addr;
>> >>   unsigned long vaddr;
>> >>
>> >>   base_addr = instruction_pointer(regs) - tu->offset;
>> >>   vaddr = base_addr + addr;
>> >>
>> >>   return (void __force __user *) vaddr;
>> >> }
>> >>
>> >> When I tested it, it was able to fetch global and bss data from both of
>> >> executable and library properly.
>> >
>> > Heh ;) I didn't expect you will agree with this suggestion. But if you
>> > think it can work - great!
>>
>> It seems to work for me well except the cross-fetch.
>
> Yes, but cross-fetching needs something different anyway, so I think we
> should discuss this separately.

Okay.

>
>> But I'm not sure it'll work for every cases.
>
> I think "ip - tu->offset + vaddr" trick should always work, just we need
> to calculate this "vaddr" passed as an argument correctly.

Right.

>
> Except: user-space can create another executable mapping and call the
> probed function via another address, but I think we can ignore this.
> And I think we can do nothing in this case, because in this case we
> can't even rely on tu->inode.

Agreed.


>> > As for "-= tu->offset"... Can't we avoid it? User-space needs to calculate
>> > the "@" argument anyway, why it can't also substruct this offset?
>>
>> Hmm.. it makes sense too. :)
>
> I am no longer sure ;)
>
> This way the "@" argument will look more confusing, it will depend on the
> address/offset of the probed insn. But again, I do not know, this is up
> to you.

That said, I'd prefer the original "-= -tu->offset" approach.  It'll
make debugging easier IMHO.

>
>> >> But it still doesn't work for uretprobes
>> >> as you said before.
>> >
>> > This looks simple,
>> >
>> >+   if (is_ret_probe(tu)) {
>> >+   saved_ip = instruction_pointer(regs);
>> >+   instruction_pointer_set(func);
>> >+   }
>> >store_trace_args(...);
>> >+   if (is_ret_probe(tu))
>> >+   instruction_pointer_set(saved_ip);
>> >
>> > although not pretty.
>>
>> So for normal non-uretprobes, func == instruction_pointer(), right?
>
> No, for normal non-uretprobes func == 0 (actually, undefined).

Ah, okay.

>
>> If so, just passing func as you suggested looks better than this.
>
> Not sure I understand... OK, we can change uprobe_trace_func() and
> uprobe_perf_func()
>
>   if (!is_ret_probe(tu))
>   -   uprobe_trace_print(tu, 0, regs);
>   +   uprobe_trace_print(tu, instruction_pointer(regs), regs);
>   return 0;
>
> but why?
>
> We need the "saved_ip" ugly hack above only if is_ret_probe() == T and
> thus instruction_pointer() doesn't match the address of the probed function.
> And there is no way to pass some additional info to call_fetch/etc from
> uprobe_*_print().

Ah, I was confused that the 'func' is somewhat available in trace_uprobe
and it can make to avoid passing regs to get_user_vaddr().

Sorry for the noise.


> See also another email...

Will do.

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

Re: [PATCH] wcn36xx: Fix logging macro with unnecessary semicolon

[Eugene Krasnikov]

Hi Joe,

I personally like the idea of making some kind of framework on top of
printing because all ath drivers are using the same printing approach
and combining all that code in one place will reduce amount of code in
each particular driver. As a true engineer i like when it's less code
= less work to do = less bugs:)

Suggestion is to send a patch with semicolon fix only and have a
second round of convincing ath guys to change printing code. How does
that sound?

On Wed, Nov 6, 2013 at 5:55 PM, Joe Perches  wrote:
> On Wed, 2013-11-06 at 07:49 +, Eugene Krasnikov wrote:
>> Hm... when it comes to semicolon the patch seems to be good. When it
>> comes to dynamic debugging i think we should have a separate
>> discussion about that.
>> I personally like the whole idea about dynamic debug but if you want
>> to change it i would suggest to have some kind of framework for all
>> ath drivers(or maybe all wireless drivers). Because obviously you can
>> find common code in every driver that defines it's own debug
>> functions/debug levels and so on. Why not to make a framework with
>> standard API/levels?
>
> You need to bring that up with the Atheros folk.
> I've tried.  The view seemed to be it was more
> trouble than it was worth.
>
>
>



-- 
Best regards,
Eugene
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Tree for Nov 7

[Stephen Rothwell]

Hi all,

Changes since 20131106:

The vfs tree gained a build failure so I used the version from
next-20131106.

The drm tree gained conflicts against Linus' tree.

The drm-intel tree gained a conflict against the drm tree.

The audit tree lost its build failure.

The akpm-current tree gained a conflict against the kbuild tree.



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

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

Below is a summary of the state of the merge.

We are up to 210 trees (counting Linus' and 29 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.

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

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

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

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

$ git checkout master
$ git reset --hard stable
Merging origin/master (be408cd3e1fe Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging fixes/master (fa8218def1b1 Merge tag 'regmap-v3.11-rc7' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap)
Merging kbuild-current/rc-fixes (19514fc665ff arm, kbuild: make "make install" 
not depend on vmlinux)
Merging arc-current/for-curr (68195fadb2a0 ARC: [plat-arcfpga] defconfig update)
Merging arm-current/fixes (384b38b66947 ARM: 7873/1: vfp: clear 
vfp_current_hw_state for dying cpu)
Merging m68k-current/for-linus (55490050df0f m68k/atari: ARAnyM - Always use 
physical addresses in NatFeat calls)
Merging metag-fixes/fixes (3b2f64d00c46 Linux 3.11-rc2)
Merging powerpc-merge/merge (8b5ede69d24d powerpc/irq: Don't switch to irq 
stack from softirq stack)
Merging sparc/master (6d15ee492809 Merge 
git://git.kernel.org/pub/scm/virt/kvm/kvm)
Merging net/master (be408cd3e1fe Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging ipsec/master (84502b5ef984 xfrm: Fix null pointer dereference when 
decoding sessions)
Merging sound-current/for-linus (8e35cd4ac996 ALSA: HDA - Limit mic boost and 
add mute LED for an HP machine)
Merging pci-current/for-linus (67d470e0e171 Revert "x86/PCI: MMCONFIG: Check 
earlier for MMCONFIG region at address zero")
Merging wireless/master (8ce9beac4661 drivers: net: wireless: b43: Fix possible 
NULL ptr dereference)
Merging driver-core.current/driver-core-linus (31d141e3a666 Linux 3.12-rc6)
Merging tty.current/tty-linus (6e757ad2c92c tty/serial: at91: fix uart/usart 
selection for older products)
Merging usb.current/usb-linus (e1466ad5b1ae USB: serial: ftdi_sio: add id for 
Z3X Box device)
Merging staging.current/staging-linus (31d141e3a666 Linux 3.12-rc6)
Merging char-misc.current/char-misc-linus (31d141e3a666 Linux 3.12-rc6)
Merging input-current/for-linus (5beea882e641 Input: ALPS - add support for 
model found on Dell XT2)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (f262f0f5cad0 crypto: s390 - Fix aes-cbc IV 
corruption)
Merging ide/master (64110c16e012 ide: sgiioc4: Staticize ioc4_ide_attach_one())
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging sh-current/sh-fixes-for-linus (44033109e99c SH: Convert out[bwl] macros 
to inline functions)
Merging devicetree-current/devicetree/merge (1931ee143b0a Revert "drivers: of: 
add initialization code for dma reserved memory")
Merging rr-fixes/fixes (f6537f2f0eba scripts/kallsyms: filter symbols not in 
kernel address space)
Merging mfd-fixes/master (d0e639c9e06d Lin

Re: [PATCH 0/3 - V2] Introducing Device Tree Overlays

[Pantelis Antoniou]

Hi Guenter,

On Nov 6, 2013, at 11:17 PM, Guenter Roeck wrote:

> On Wed, Nov 06, 2013 at 09:38:21PM +0100, Sebastian Andrzej Siewior wrote:
>> On 06.11.13, Guenter Roeck wrote:
>>> At least that is our use case. u-boot doesn't know which cards are going to 
>>> be
>>> inserted at runtime. Even PCIe hotplug itself is insufficient, as the PCIe
>>> configuration differs per card, and the cards support a variety of i2c 
>>> devices
>>> as well as other card specific devices such LEDs and multi-function FPGAs.
>> 
>> So you have your FPGA behind PCIe and you use the DT to describe the
>> chips behind i2c? And then you update your FPGA and want update the
>> devices in DT without reboot?
>> 
> No.
> 
> We have a variety of boards ...
[snip]

TL;DR the real world...

> 
> We use DT overlays to describe the hardware on those boards and, if necessary,
> its configuration. For example, if there is a PCIe switch, the overlay would
> describe its memory and bus number configuration.
> 
> Guenter

Glad it's been useful...

Regards

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

Re: [PATCH 0/3 - V2] Introducing Device Tree Overlays

[Pantelis Antoniou]

Hi Sebastian,

On Nov 6, 2013, at 10:41 PM, Sebastian Andrzej Siewior wrote:

> On 06.11.13, Sebastian Andrzej Siewior wrote:
>>> It has been discussed.
>>> 
>>> We are doing it because
> 
> Please don't get me wrong. I am not against this, I am just curious why
> this needs to be done at runtime and bootloader time is not an option.
> 

No harm done.

I guess it all comes down to being done at runtime being the better option.

> Sebastian

Regards

-- Pantelis

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

Re: [PATCH 0/3 - V2] Introducing Device Tree Overlays

[Pantelis Antoniou]

Hi Sebestian,

On Nov 6, 2013, at 10:31 PM, Sebastian Andrzej Siewior wrote:

> On 06.11.13, Pantelis Antoniou wrote:
>> Hi Sebastian,
> Hi Pantelis,
> 
>> It has been discussed.
>> 
>> We are doing it because
>> 
>> a) We tried to do it in u-boot and it has been a complete disaster.
>> Regular users just can't handle bootloader updates.
> 
> How so? The "additional" dtb piece was deleted by accident as part of
> the u-boot upgrade? Do you maybe a link which describes the disaster?
> 

You're assuming that bootloaders are anything like u-boot or barebox.
In the field, especially on consumer products, bootloaders are custom one-off
jobs that don't do much besides handing control to the kernel as soon as 
possible.

Even when using u-boot, end users botch updates related to bootloader in
such a way that systems end up RMAed.

Ask Koen Kooi in the CClist about the messy details.

>> b) It is similar to that. It was originally created for the beaglebone,
>> which has a concept of capes (similar to Arduino shields).
>> http://circuitco.com/support/index.php?title=BeagleBone_Capes
>> Turns out it's really useful to anyone doing reconfigurable hardware too,
>> so that's why FPGA people are thinking of using it.
> 
> I am aware of this. My understanding is that those capes have hardware
> information encoded in an eeprom behind i2c _and_ you can't or should
> not replace capes at runtime.
> Naive as I am I *assume* it should be easy to read this eeprom in u-boot
> as part of the boot setup and extend the dtb before passing it to the
> kernel. In case this works well, the problem here is a) ?
> 

It is just better system design to have it all done in the kernel.
Other people in the list can chime in, but it's hard to get a feel of the
problem if you haven't dealt with it before.

>> c) There are people that want to tinker with Linux based hardware boards
>> but are not kernel developers. This gives them a way to do so without
>> having to recompile the kernel and/or reboot while tinkering.
> 
> I understand that they want to avoid reboot. But they still need to
> recompile the device tree, don't they? Or does this allow to change the
> HW description without knowing the syntax of .dts?
> 

They understand the syntax of the DTS (barely).
They can't hack compiling the kernel and updating it, not by a long shot.
Not everyone is a kernel hacker (neither it needs be).

Imagine people coming over from Arduino trying to hack a 4K board file to
add support for the thing they're working on.

>> Regards
>> 
>> -- Pantelis
> 
> Sebastian

Regards

-- Pantelis

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

Re: [PATCH -next] mtd: nand: omap: fix error return code in omap_nand_probe()

[Brian Norris]

On Wed, Nov 06, 2013 at 06:06:25PM +, Pekon Gupta wrote:
> > From: Brian Norris [mailto:computersforpe...@gmail.com]
> > > On Thu, Oct 31, 2013 at 7:18 PM, Jingoo Han 
> > >> From: Wei Yongjun 
> > >>
> > >> Fix to return a negative error code from the error handling
> > >> case instead of 0, as done elsewhere in this function.
> > >
> > > Commit message is right? :-(
> > 
> > It sounds OK by my reading. Unless you're having trouble parsing what
> > "as done elsewhere in this function" is being applied to. (IOW, is the
> > rest of the function returning a negative error code on the error
> > paths, or is it returning 0? Of course the answer is the former, but
> > it's possible to misread it.) If it helps, I can try to tweak the
> > wording a bit when applying this patch.
> > 
> > Pekon, can I get an Acked-by?
> > 
> Yes sure .. Sorry I was away from both mailbox and boards.

No problem.

> Acked-by: Pekon Gupta 
> 
> And thanks much Wei Yongjun for fixing this .

Thanks. Pushed to l2-mtd.git with a slight tweak in the description.

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

Re: [PATCH -next] mtd: nand: omap: fix error return code in omap_nand_probe()

[Brian Norris]

On Tue, Nov 05, 2013 at 07:45:27PM -0300, Ezequiel Garcia wrote:
> On Tue, Nov 05, 2013 at 01:59:25PM -0800, Brian Norris wrote:
> > On Thu, Oct 31, 2013 at 7:18 PM, Jingoo Han  wrote:
> > > On Friday, November 01, 2013 9:16 AM, Wei Yongjun wrote:
> > >>
> > >> From: Wei Yongjun 
> > >>
> > >> Fix to return a negative error code from the error handling
> > >> case instead of 0, as done elsewhere in this function.
> > >
> > > Commit message is right? :-(
> > 
> > It sounds OK by my reading. Unless you're having trouble parsing what
> > "as done elsewhere in this function" is being applied to. (IOW, is the
> > rest of the function returning a negative error code on the error
> > paths, or is it returning 0? Of course the answer is the former, but
> > it's possible to misread it.) If it helps, I can try to tweak the
> > wording a bit when applying this patch.
> > 
> > Pekon, can I get an Acked-by?
> > 
> 
> I guess you'd prefer Pekon's ack than mine, but anyway:

Eh, this patch was pretty small anyway. But extra eyes are good.

> Acked-by: Ezequiel Garcia 

Thanks.

> I'd like to point out this driver has other "mis-behaviors" in returning codes
> in some other places.
> 
> In particular, this pattern can be found repeatedly:
> 
>   if (do_something()) {
>   err = -ENXIO;
>   goto some_other_place;
>   }
> 
> Which should probably be:
> 
>   err = do_something();
>   if (err)
>   goto some_other_place;

Yeah, these could be made more consistent. If the callee is choosing
good error codes, then we can just return them. But this is mostly
cosmetic.

> Wei: maybe you'd like to prepare some more patches?

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ext4: Fix reading of extended tv_sec (bug 23732)

[David Turner]

In ext4, the bottom two bits of {a,c,m}time_extra are used to extend
the {a,c,m}time fields, deferring the year 2038 problem to the year
2446.  The representation (which this patch does not alter) is a bit
hackish, in that the most-significant bit is no longer (alone)
sufficient to indicate the sign.  That's because we're representing an
asymmetric range, with seven times as many positive values as
negative.

When decoding these extended fields, for times whose bottom 32 bits
would represent a negative number, sign extension causes the 64-bit
extended timestamp to be negative as well, which is not what's
intended.  This patch corrects that issue, so that the only negative
{a,c,m}times are those between 1901 and 1970 (as per 32-bit signed
timestamps).

Signed-off-by: David Turner 
Reported-by: Mark Harris 
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=23732
---
 fs/ext4/ext4.h | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index af815ea..7b73c26 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -722,10 +722,15 @@ static inline __le32 ext4_encode_extra_time(struct 
timespec *time)
 
 static inline void ext4_decode_extra_time(struct timespec *time, __le32 extra)
 {
-   if (sizeof(time->tv_sec) > 4)
-  time->tv_sec |= (__u64)(le32_to_cpu(extra) & EXT4_EPOCH_MASK)
-  << 32;
-   time->tv_nsec = (le32_to_cpu(extra) & EXT4_NSEC_MASK) >> 
EXT4_EPOCH_BITS;
+   if (sizeof(time->tv_sec) > 4) {
+   u64 extra_bits = (__u64)(le32_to_cpu(extra) & EXT4_EPOCH_MASK);
+   if (time->tv_sec > 0 || extra_bits != EXT4_EPOCH_MASK) {
+   time->tv_sec &= 0x;
+   time->tv_sec |= extra_bits << 32;
+   }
+   time->tv_nsec = (le32_to_cpu(extra) & EXT4_NSEC_MASK) >>
+   EXT4_EPOCH_BITS;
+   }
 }
 
 #define EXT4_INODE_SET_XTIME(xtime, inode, raw_inode) \
-- 
1.8.1.2



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

Re: [PATCH] smsc9420: Use netif_

[David Miller]

From: Joe Perches 
Date: Tue, 05 Nov 2013 10:34:21 -0800

> Use a more standard logging style.
> 
> Convert smsc_ macros to use netif_.
> Remove unused #define PFX
> Add pr_fmt and neaten pr_ uses.
> 
> Signed-off-by: Joe Perches 

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

Re: [PATCH net-next trivial] udp: Remove unnecessary semicolon from do{}while (0) macro

[David Miller]

From: Joe Perches 
Date: Tue, 05 Nov 2013 14:13:47 -0800

> Just an unnecessary semicolon that should be removed...
> 
> Whitespace neatening of macro too.
> 
> Signed-off-by: Joe Perches 

Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] jme: Remove unused #define PFX

[David Miller]

From: Joe Perches 
Date: Tue, 05 Nov 2013 09:29:55 -0800

> It's unused, remove it.
> 
> Signed-off-by: Joe Perches 

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

Re: [PATCH 2/3] OF: Introduce DT overlay support.

[Pantelis Antoniou]

Hi Dinh,

On Nov 6, 2013, at 10:41 PM, Dinh Nguyen wrote:

> Hi Pantelis,
> 
> On 11/5/13 12:41 PM, Pantelis Antoniou wrote:
>> Introduce DT overlay support.
>> Using this functionality it is possible to dynamically overlay a part of
>> the kernel's tree with another tree that's been dynamically loaded.
>> It is also possible to remove node and properties.
>> 
>> Note that the I2C client devices are 'special', as in they're not platform
>> devices. They need to be registered with an I2C specific method.
>> 
>> In general I2C is just no good platform device citizen and needs
>> special casing.
>> 
>> Signed-off-by: Pantelis Antoniou 
>> ---
>> Documentation/devicetree/overlay-notes.txt | 179 ++
>> drivers/of/Kconfig |  10 +
>> drivers/of/Makefile|   1 +
>> drivers/of/overlay.c   | 869 
>> +
>> include/linux/of.h | 113 
>> 5 files changed, 1172 insertions(+)
>> create mode 100644 Documentation/devicetree/overlay-notes.txt
>> create mode 100644 drivers/of/overlay.c
>> 
>> diff --git a/Documentation/devicetree/overlay-notes.txt 
>> b/Documentation/devicetree/overlay-notes.txt
>> new file mode 100644
>> index 000..5289cbb
>> --- /dev/null
>> +++ b/Documentation/devicetree/overlay-notes.txt
>> @@ -0,0 +1,179 @@
>> +Device Tree Overlay Notes
>> +-
>> +
>> +This document describes the implementation of the in-kernel
>> +device tree overlay functionality residing in drivers/of/overlay.c and is a
>> +companion document to Documentation/devicetree/dt-object-internal.txt[1] &
>> +Documentation/devicetree/dynamic-resolution-notes.txt[2]
>> +
>> +How overlays work
>> +-
>> +
>> +A Device Tree's overlay purpose is to modify the kernel's live tree, and
>> +have the modification affecting the state of the the kernel in a way that
>> +is reflecting the changes.
>> +Since the kernel mainly deals with devices, any new device node that result
>> +in an active device should have it created while if the device node is 
>> either
>> +disabled or removed all together, the affected device should be 
>> deregistered.
>> +
>> +Lets take an example where we have a foo board with the following base tree
>> +which is taken from [1].
>> +
>> + foo.dts 
>> -
>> +/* FOO platform */
>> +/ {
>> +compatible = "corp,foo";
>> +
>> +/* shared resources */
>> +res: res {
>> +};
>> +
>> +/* On chip peripherals */
>> +ocp: ocp {
>> +/* peripherals that are always instantiated */
>> +peripheral1 { ... };
>> +}
>> +};
>> + foo.dts 
>> -
>> +
>> +The overlay bar.dts, when loaded (and resolved as described in [2]) should
>> +
>> + bar.dts 
>> -
>> +/plugin/;   /* allow undefined label references and record them */
>> +/ {
>> +/* various properties for loader use; i.e. part id etc. */
>> +fragment@0 {
>> +target = <>;
>> +__overlay__ {
>> +/* bar peripheral */
>> +bar {
>> +compatible = "corp,bar";
>> +... /* various properties and child nodes */
>> +}
>> +};
>> +};
>> +};
>> + bar.dts 
>> -
>> +
>> +result in foo+bar.dts
>> +
>> + foo+bar.dts 
>> -
>> +/* FOO platform + bar peripheral */
>> +/ {
>> +compatible = "corp,foo";
>> +
>> +/* shared resources */
>> +res: res {
>> +};
>> +
>> +/* On chip peripherals */
>> +ocp: ocp {
>> +/* peripherals that are always instantiated */
>> +peripheral1 { ... };
>> +
>> +/* bar peripheral */
>> +bar {
>> +compatible = "corp,bar";
>> +... /* various properties and child nodes */
>> +}
>> +}
>> +};
>> + foo+bar.dts 
>> -
>> +
>> +As a result of the the overlay, a new device node (bar) has been created
>> +so a bar platform device will be registered and if a matching device driver
>> +is loaded the device will be created as expected.
>> +
>> +Overlay in-kernel API
>> +-
>> +
>> +The steps typically required to get an overlay to work are as follows:
>> +
>> +1. Use of_build_overlay_info() to create an array of initialized and
>> +ready to use of_overlay_info structures.
>> +2. Call 

Re: [PATCH] perf: Remove unneeded include

[Namhyung Kim]

Hi Rodrigo,

On Wed,  6 Nov 2013 22:20:54 +, Rodrigo Campos wrote:
> There is no point in sort.h including itself.
>
> The include was added when the file was created, in commit "perf tools: Create
> util/sort.and use it" (dd68ada2d) and added a include to "sort.h" in lot of
> files (all the files that started using the file). It was probably added by
> mistake on sort.h too.

Acked-by: Namhyung Kim 

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

Re: [PATCH v3 9/9] ARM: add initial support for Marvell Berlin SoCs

[Jisheng Zhang]

On Wed, 6 Nov 2013 21:40:33 -0800
Jisheng Zhang  wrote:

...
> > +   select ARM_GIC  
> ARM_GIC is common on berlin SoCs. we can put it below ARCH_BERLIN?
> > +   select CACHE_L2X0  
> ditto

Sorry. After some consideration, CACHE_L2X0 is not common (BG3). So please 
ignore
this line

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

Re: [PATCH] staging: zsmalloc: Ensure handle is never 0 on success

[Minchan Kim]

On Wed, Nov 06, 2013 at 07:05:11PM -0800, Greg KH wrote:
> On Wed, Nov 06, 2013 at 03:46:19PM -0800, Nitin Gupta wrote:
>  > I'm getting really tired of them hanging around in here for many years
> > > now...
> > >
> > 
> > Minchan has tried many times to promote zram out of staging. This was
> > his most recent attempt:
> > 
> > https://lkml.org/lkml/2013/8/21/54
> > 
> > There he provided arguments for zram inclusion, how it can help in
> > situations where zswap can't and why generalizing /dev/ramX would
> > not be a great idea. So, cannot say why it wasn't picked up
> > for inclusion at that time.
> > 
> > > Should I just remove them if no one is working on getting them merged
> > > "properly"?
> > >
> > 
> > Please refer the mail thread (link above) and see Minchan's
> > justifications for zram.
> > If they don't sound convincing enough then please remove zram+zsmalloc
> > from staging.
> 
> You don't need to be convincing me, you need to be convincing the
> maintainers of the area of the kernel you are working with.
> 
> And since the last time you all tried to get this merged was back in
> August, I'm feeling that you all have given up, so it needs to be
> deleted.  I'll go do that for 3.14, and if someone wants to pick it up
> and merge it properly, they can easily revert it.

I'm guilty and I have been busy by other stuff. Sorry for that.
Fortunately, I discussed this issue with Hugh in this Linuxcon for a
long time(Thanks Hugh!) he felt zram's block device abstraction is
better design rather than frontswap backend stuff although it's a question
where we put zsmalloc. I will CC Hugh because many of things is related
to swap subsystem and his opinion is really important.
And I discussed it with Rik and he feel positive about zram.

Last impression Andrw gave me by private mail is he want to merge
zram's functionality into zswap or vise versa.
If I misunderstood, please correct me.
I understand his concern but I guess he didn't have a time to read
my long description due to a ton of works at that time.
So, I will try one more time.
I hope I'd like to listen feedback than *silence* so that we can
move forward than stall.

Recently, Bob tried to move zsmalloc under mm directory to unify
zram and zswap with adding pseudo block device in zswap(It's
very weired to me. I think it's horrible monster which is lying
between mm and block in layering POV) but he was ignoring zram's
block device (a.k.a zram-blk) feature and considered only swap
usecase of zram, in turn, it lose zram's good concept. 
I already convered other topics Bob raised in this thread[1]
and why I think zram is better in the thread.

Will repeat one more time and hope gray beards penguins grab a
time in this time and they give a conclusion/direction to me so
that we don't lose lots of user and functionality.

== &< ===

Mel raised an another issue in v6, "maintainance headache".
He claimed zswap and zram has a similar goal that is to compresss
swap pages so if we promote zram, maintainance headache happens
sometime by diverging implementaion between zswap and zram
so that he want to unify zram and zswap. For it, he want zswap
to implement pseudo block device like Bob did to emulate zram so
zswap can have an advantage of writeback as well as zram's benefit.
But I wonder frontswap-based zswap's writeback is really good
approach for writeback POV. I think that problem isn't only
specific for zswap. If we want to configure multiple swap hierarchy
with various speed device such as RAM, NVRAM, SSD, eMMC, NAS etc,
it would be a general problem. So we should think of more general
approach. At a glance, I can see two approach.

First, VM could be aware of heterogeneous swap configuration
so it could aim for being able to configure cache hierarchy
among swap devices. It may need indirction layer on swap, which
was already talked about that way so VM can migrate a block from
A to B easily. It will support various configuration with VM's
hints, maybe, in future.
http://lkml.indiana.edu/hypermail/linux/kernel/1203.3/03812.html

Second, as more practical solution, we could use device mapper like
dm-cache(https://lwn.net/Articles/540996/), which makes it very
flexible. Now, it supports various configruation and cache policy
(block size, writeback/writethrough, LRU, MFU although MQ is merged
now) so it would be good fit for our purpose. Even, it can make zram
support writeback. I tested it following as following scenario
in KVM 4 CPU, 1G DRAM with background 800M memory hogger, which is
allocates random data up to 800M.

1) zram swap disk 1G, untar kernel.tgz to tmpfs, build -j 4
   Fail to untar due to shortage of memory space by tmpfs default size limit

2) zram swap disk 1G, untar kernel.tgz to ext2 on zram-blk, build -j 4
   OOM happens while building the kernel but it untar successfully
   on ext2 based on zram-blk. The reason OOM happend is zram can not find
   free pages from main memory to store swap out pages although empty
   

RE: [RFCv2][PATCHv5 0/4] Add Freescale FTM PWM driver.

[Li Xiubo]

Hi Thierry,

The document binding patch of this patch series has been acked.
And other patches have been acked before.

Should I send a V6 patch series ?

Thanks very much.


--


> Subject: [RFCv2][PATCHv5 0/4] Add Freescale FTM PWM driver.
> 
> Hello,
> 
> This patch series is the Freescale FTM PWM implementation. And there are
> 8 channels most supported by the FTM PWM. This implementation is only
> compatible with device tree definition.
> 
> This patch series is based on linux-next and has been tested on Vybrid
> VF610 Tower board using device tree.
> 
> 
> 
> Changes in RFCv2 of PATVHv5:
> - Remove "fsl,pwm-counter-clk"(all the four patches are modified).
> 
> Changes in v5:
> - Remove active/idle pinctrl stuff.
> 
> Changes in v4:
> - Check for the result and return an error for devm_kzalloc().
> - Move pinmux setting from the SoC file to the board specific file.
> - Revise the written mistake of 'ret |= FTMSC_CLKEXT;' --> 'reg |=
> FTMSC_CLKEXT;'.
> 
> 
> Changes in v3:
> - Remove "availabe" field.
> - Remove "fsl,pwm-avaliable-chs" property.
> - ...
> 
> Changes in v2:
> - Remove PWM CPWM/EPWM feature and sysfs.
> - Remove some redundant code.
> - Revise some code for more readable.
> - Remove "fsl,pwm-clk-ps", "fsl,pwm-number", "fsl,pwm-channels",etc.
> - Add "fsl,pwm-avaliable-chs", "fsl,pwm-counter-clk", etc.
> - Support 8 channels default in dtsi file.
> - Add counter clock source selection.
> - Rename some function name, macro name, etc.
> - Use PWM's and OF's existing function interfaces.
> - Split clk_unprepare_enable to clk_unprepare and clk_enable,etc.
> - ...
> 
> Added in v1:
> - Add Freescale FTM PWM driver support.
> - Add Freescale FTM PWM node for VF610.
> - Enable Enables FTM PWM device for Vybrid VF610 TOWER.
> - Add device tree bindings for Freescale.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] usb: phy: phy-mxs-usb: set the correct platform drvdata

[Peter Chen]

 
> 
> Signed-off-by: Jisheng Zhang 
> ---
>  drivers/usb/phy/phy-mxs-usb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-
> usb.c
> index fdd33b4..545844b 100644
> --- a/drivers/usb/phy/phy-mxs-usb.c
> +++ b/drivers/usb/phy/phy-mxs-usb.c
> @@ -164,7 +164,7 @@ static int mxs_phy_probe(struct platform_device *pdev)
> 
>   mxs_phy->clk = clk;
> 
> - platform_set_drvdata(pdev, _phy->phy);
> + platform_set_drvdata(pdev, mxs_phy);
> 
>   ret = usb_add_phy_dev(_phy->phy);
>   if (ret)
> --

It is so unlucky the struct usb_phy phy is the first element
of struct mxs_phy, so we haven't run any problems.

Jisheng, thanks for fixing it.

Acked-by: Peter Chen  


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/10] perf hists: Consolidate __hists__add_*entry()

[Namhyung Kim]

Hi Arnaldo,

On Wed, 6 Nov 2013 10:42:10 -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Nov 05, 2013 at 09:52:43PM +, Rodrigo Campos escreveu:
>> On Tue, Nov 05, 2013 at 05:09:52PM -0300, Arnaldo Carvalho de Melo wrote:
>> > @@ -486,15 +425,15 @@ struct hist_entry *__hists__add_entry(struct hists 
>> > *hists,
>> >.stat = {
>> > -  .period = period,
>> >.nr_events = 1,
>> > +  .period = period,
>> >.weight = weight,
>> >},
>
>> Isn't this seems unrelated and unneeded ?
>
>> The "period" field is before the "nr_events" field in the struct, so maybe is
>> more clear to leave it as it was ?  The actual relative order (it has some 
>> more
>> fields) in the struct is: period, weigth, nr_events. Might be better if they
>> match that order here ? Although not sure since we are using the fields with
>> name and is clear enough.
>
> Yeah, this shouldn't be there, I thought about fixing this up to reduce
> the patch size, but ended up being lenient.
>
> Namhyung, please avoid such unneeded patch churn :-)

Okay, I'll keep it in mind.

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

RE: mei: cancel stall timers in mei_reset

[Eugene Shatokhin]

Hi,

> You can safely comment out all of the timer_work.
 
Well, I rebuilt the kernel with the schedule_... commented out (in 
mei_me_pci_resume(), for the present). The errors are no longer visible in the 
log. The full log is attached.

Regards,

Eugene


system-log-20131107.tar.bz2
Description: application/bzip-compressed-tar

linux-next: manual merge of the akpm-current tree with the kbuild tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
scripts/bloat-o-meter between commit 21cf6e584ce3 ("kbuild,
bloat-o-meter: fix static detection") from the kbuild tree and commit
372dd3b27736 ("scripts/bloat-o-meter: ignore changes in the size of
linux_banner") from the akpm-current 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 scripts/bloat-o-meter
index 855198c9dedb,31c953195b52..
--- a/scripts/bloat-o-meter
+++ b/scripts/bloat-o-meter
@@@ -19,9 -19,10 +19,10 @@@ def getsizes(file)
  size, type, name = l[:-1].split()
  if type in "tTdDbBrR":
  # strip generated symbols
- if name[:6] == "__mod_": continue
+ if name.startswith("__mod_"): continue
+ if name == "linux_banner": continue
 -# function names begin with '.' on 64-bit powerpc
 -if "." in name[1:]: name = "static." + name.split(".")[0]
 +# statics and some other optimizations adds random .NUMBER
 +name = re.sub(r'\.[0-9]+', '', name)
  sym[name] = sym.get(name, 0) + int(size, 16)
  return sym
  


pgpv4aHGbFBHv.pgp
Description: PGP signature

Re: [PATCH v2] dynamic_debug: add wildcard support to filter files/functions/modules

[Joe Perches]

On Thu, 2013-11-07 at 11:11 +0800, Changbin Du wrote:
> 2013/11/1 Joe Perches :
> > On Thu, 2013-10-31 at 15:52 -0700, Andrew Morton wrote:
> >> On Mon, 28 Oct 2013 23:29:10 +0800 "Du, Changbin"  
> >> wrote:
> > []
> >> > +/* check if the string matches given pattern which includes wildcards */
> >> > +static int match_pattern(const char *pattern, const char *string)
> > []
> >> No, something like this should be in lib/ so that other callers can use
> >> it.  We already have at least one copy handy in
> >> drivers/ata/libata-core.c:glob_match().  A better approach would be to
> >> move that glob_match() into lib/glob_match.c then teach dynamic_debug
> >> to use it.
> >>
> >> There are probably other private globbing functions lying around the
> >> kernel, but it's rather a hard thing to grep for...
> >
> > Maybe use lib/parser.c where the other match_ functions
> > are already.
> 
> match_ functions in lib/parser.c just do simple match, they
> doesn't support wildcards.
> So it's not useful for us.

It's not meant to be useful so much as be a possible
generic location for your match_regex function.


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

Re: [PATCH v3 4/9] ARM: add Marvell Berlin SoC familiy to Marvell doc

[Jisheng Zhang]

Dear Sebastian,

I have some permission to comment this patch now ;)

On Tue, 5 Nov 2013 06:28:38 -0800
Sebastian Hesselbarth  wrote:

> This adds known facts and rumors about the Marvell Berlin (88DE3xxx) SoC
> family to the Marvell SoC documentation.
> 
> Signed-off-by: Sebastian Hesselbarth 
> Reviewed-by: Jason Cooper 
> Reviewed-by: Thomas Petazzoni 
> Reviewed-by: Arnd Bergmann 
> ---
> Changelog:
> v2->v3:
> - add stepping Z1 to Armada 1000 (88DE3010)
> RFCv2->v1:
> - move Berlin below PXA/MMP[23] where it belongs to
> - add note about IP (re-)used in Berlin SoCs
> RFCv1->RFCv2:
> - initial patch
> 
> Cc: Rob Landley 
> Cc: linux-...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  Documentation/arm/Marvell/README |   29 +
>  1 file changed, 29 insertions(+)
> 
> diff --git a/Documentation/arm/Marvell/README
> b/Documentation/arm/Marvell/README index 8f08a86..53ecf08 100644
> --- a/Documentation/arm/Marvell/README
> +++ b/Documentation/arm/Marvell/README
> @@ -210,6 +210,35 @@ MMP/MMP2 family (communication processor)
> Linux kernel mach directory: arch/arm/mach-mmp
> Linux kernel plat directory: arch/arm/plat-pxa
>  
> +Berlin family (Digital Entertainment)
> +-
> +
> +  Flavors:
> + 88DE3005, Armada 1500-mini
> + Design name:BG2CD(A0)
> + Core:   ARM Cortex-A9, PL310 L2CC
> + Homepage:
> http://www.marvell.com/digital-entertainment/armada-1500-mini/
> + 88DE3010, Armada 1000
> + Design name:BG2(Z1)
> + Core:   Marvell PJ4B (ARMv7), Tauros3 L2CC
> + Product Brief:
> http://www.marvell.com/digital-entertainment/assets/armada_1000_pb.pdf
88DE3010 is based on ARMv5 and is too old, I bet there are no real users now. 
Can we
remove it?
> + 88DE3100, Armada 1500
> + Design name:BG2(A0)
BG2(B0), BG2(A0) and BG2(Z1) are both called 88DE3100, Armada 1500. They are
just different Step versions. And BG2(Zx) BG2(Ax) are rarely used outside 
marvell
Mostly used version is BG2(B0)
> + Core:   Marvell PJ4B (ARMv7), Tauros3 L2CC
> + Homepage:
> http://www.marvell.com/digital-entertainment/armada-1500/
> + Product Brief:
> http://www.marvell.com/digital-entertainment/armada-1500/assets/Marvell-ARMADA-1500-Product-Brief.pdf
> + 88DE
> + Design name:BG3
> + Core:   ARM Cortex-A15, CA15 integrated L2CC
> +
> +  Homepage: http://www.marvell.com/digital-entertainment/
> +  Directory: arch/arm/mach-berlin
> +
> +  Comments:
> +   * This line of SoCs is based on Marvell Sheeva or ARM Cortex CPUs
> + with Synopsys DesignWare (IRQ, GPIO, Timers, ...) and PXA IP (SDHCI,
> USB, ETH, ...).
> +   * Currently known design names are: C2, BG2(Z1), BG2(A0), BG2CD(A0),
> BG2CT(A0) +
>  Long-term plans
>  ---
>  

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

[PATCH 3/3 v8] thermal: samsung: Add TMU support for Exynos5420 SoCs

[Naveen Krishna Chatradhi]

This patch adds the neccessary register changes and arch information
to support Exynos5420 SoCs
Exynos5420 has 5 TMU channels one for each CPU 0, 1, 2 and 3 and GPU

Also updated the Documentation at
Documentation/devicetree/bindings/thermal/exynos-thermal.txt

Note: The platform data structure will be handled properly once the driver
 moves to complete device driver solution.

Signed-off-by: Naveen Krishna Chatradhi 
---
Changes since v1:
1. modified the platform data structure in order to pass SHARED flag
   for channels that need sharing of address space.
2. https://lkml.org/lkml/2013/8/1/38 is merged into this patch.
   As the changes are minimum and can be added here.
Changes since v3:
   a. Rearraged the code alphabetically, make exynso5420 come before exynso5440
   b. Reduce code duplication in passing platform data by introducing a common 
macro
  Bartlomiej Zolnierkiewicz Thanks for review and suggestions
Changes since v4:
 None
Changes since v5:
 None
Changes since v6:
 - removed the unsued field "inten_fall_shift"
 - defined EXYNOS5420_TMU_CLEAR_FALL_INT_SHIFT instead of using 
EXYNOS_TMU_FALL_INT_SHIFT
Changes since v7:
 - changes ins v6 were moved to the patch 1/3 of this patchset.
 - defined EXYNOS5420_TMU_CLEAR_FALL_INT_SHIFT instead of using 
EXYNOS_TMU_FALL_INT_SHIFT
 
 .../devicetree/bindings/thermal/exynos-thermal.txt |   39 
 drivers/thermal/samsung/exynos_tmu.c   |   12 ++-
 drivers/thermal/samsung/exynos_tmu.h   |1 +
 drivers/thermal/samsung/exynos_tmu_data.c  |   98 
 drivers/thermal/samsung/exynos_tmu_data.h  |8 ++
 5 files changed, 157 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index 116cca0..c5f9a74 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -6,6 +6,7 @@
   "samsung,exynos4412-tmu"
   "samsung,exynos4210-tmu"
   "samsung,exynos5250-tmu"
+  "samsung,exynos5420-tmu"
   "samsung,exynos5440-tmu"
 - interrupt-parent : The phandle for the interrupt controller
 - reg : Address range of the thermal registers. For soc's which has multiple
@@ -13,6 +14,16 @@
interrupt related then 2 set of register has to supplied. First set
belongs to each instance of TMU and second set belongs to second set
of common TMU registers.
+  NOTE: On Exynos5420, the TRIMINFO register is misplaced for TMU
+   channels 2, 3 and 4
+
+   TRIMINFO at 0x1006c000 contains data for TMU channel 3
+   TRIMINFO at 0x100a contains data for TMU channel 4
+   TRIMINFO at 0x10068000 contains data for TMU channel 2
+
+   The misplaced register address is passed through devicetree as the
+   second base
+
 - interrupts : Should contain interrupt for thermal system
 - clocks : The main clock for TMU device
 - clock-names : Thermal system clock name
@@ -43,6 +54,34 @@ Example 2):
clock-names = "tmu_apbif";
};
 
+Example 3): (In case of Exynos5420)
+   /* tmu for CPU2 */
+   tmu@10068000 {
+   compatible = "samsung,exynos5420-tmu";
+   reg = <0x10068000 0x100>, <0x1006c000 0x4>;
+   interrupts = <0 184 0>;
+   clocks = < 318>;
+   clock-names = "tmu_apbif";
+   };
+
+   /* tmu for CPU3 */
+   tmu@1006c000 {
+   compatible = "samsung,exynos5420-tmu";
+   reg = <0x1006c000 0x100>, <0x100a 0x4>;
+   interrupts = <0 185 0>;
+   clocks = < 318>;
+   clock-names = "tmu_apbif";
+   };
+
+   /* tmu for GPU */
+   tmu@100a {
+   compatible = "samsung,exynos5420-tmu";
+   reg = <0x100a 0x100>, <0x10068000 0x4>;
+   interrupts = <0 215 0>;
+   clocks = < 318>;
+   clock-names = "tmu_apbif";
+   };
+
 Note: For multi-instance tmu each instance should have an alias correctly
 numbered in "aliases" node.
 
diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index ae80a87..b54825a 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -186,7 +186,12 @@ static int exynos_tmu_initialize(struct platform_device 
*pdev)
EXYNOS5440_EFUSE_SWAP_OFFSET + reg->triminfo_data);
}
} else {
-   trim_info = readl(data->base + reg->triminfo_data);
+   /* On exynos5420 the triminfo register is in the shared space */
+   if (data->base_second && (data->soc == SOC_ARCH_EXYNOS5420))
+   trim_info = readl(data->base_second +
+   reg->triminfo_data);
+   else
+

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

[Gao feng]

On 11/06/2013 03:14 AM, Richard Guy Briggs wrote:
> On Tue, Nov 05, 2013 at 04:56:55PM +0800, Gao feng wrote:
>> On 11/05/2013 04:11 PM, Li Zefan wrote:
>>> On 2013/11/5 15:52, Gao feng wrote:
 On 11/05/2013 03:51 PM, Gao feng wrote:
> Ping...

 I want to catch up the merge window..
>>>
>>> Even if your patches are accepted by a certain maintainer immediately,
>>> he will in no doubt queue them for 3.14.
>>
>> Yes, you are right...
>> But I still want to get some comments..
> 
> Definitely won't make it in in this merge window.  I agree it needs
> discussion, but I won't start that for at least another week (I'm
> currently at IETF in Vancouver.).
> 

Get it,hope we can start discussion ASAP.

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

[PATCH 1/3 v8] thermal: samsung: add intclr_fall_shift bit in exynos_tmu_register struct

[Naveen Krishna Chatradhi]

On Exynos5250, the FALL interrupt related en, status and clear bits are
available at an offset of
16 in INTEN, INTSTAT registers and at an offset of
12 in INTCLEAR register.

On Exynos5420, the FALL interrupt related en, status and clear bits are
available at an offset of
16 in INTEN, INTSTAT and INTCLEAR registers.

On Exynos5440,
the FALL_IRQEN bits are at an offset of 4
and the RISE_IRQEN bits are at an offset of 0

This patch introduces a new bit field intclr_fall_shift to handle the
offset for exyns5250 and exynos5440
Also removes the unused macros EXYNOS_TMU_FALL_INT_SHIFT and
EXYNOS5440_TMU_FALL_INT_SHIFT, inten_fall_shift field

Signed-off-by: Naveen Krishna Chatradhi 
---
Changes since v1:
Changes since v2:
Changes since v3:
  None
Changes since v4:
 Correct the CLEAR_FALL_INT_SHIFT for Exynos5250/Exynos5440
Changes since v5:
 Modify the commit message
Changes since v6:
 - Use EXYNOS_TMU_CLEAR_FALL_INT_SHIFT instead of 
EXYNOS5250_TMU_CLEAR_FALL_INT_SHIFT
 as the same is being used for Exynos4412
Changes since v7:
 - also removes the unused macros EXYNOS_TMU_FALL_INT_SHIFT and
 EXYNOS5440_TMU_FALL_INT_SHIFT, inten_fall_shift field

 
 drivers/thermal/samsung/exynos_tmu.c  |2 +-
 drivers/thermal/samsung/exynos_tmu.h  |4 ++--
 drivers/thermal/samsung/exynos_tmu_data.c |4 ++--
 drivers/thermal/samsung/exynos_tmu_data.h |4 ++--
 4 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index 32f38b9..b2202fa 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -265,7 +265,7 @@ skip_calib_data:
data->base + reg->threshold_th1);
 
writel((reg->inten_rise_mask << reg->inten_rise_shift) |
-   (reg->inten_fall_mask << reg->inten_fall_shift),
+   (reg->inten_fall_mask << reg->intclr_fall_shift),
data->base + reg->tmu_intclear);
 
/* if last threshold limit is also present */
diff --git a/drivers/thermal/samsung/exynos_tmu.h 
b/drivers/thermal/samsung/exynos_tmu.h
index 3fb6554..39fca47 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -124,7 +124,6 @@ enum soc_type {
enable bits.
  * @inten_rise_shift: shift bits of all rising interrupt bits.
  * @inten_rise_mask: mask bits of all rising interrupt bits.
- * @inten_fall_shift: shift bits of all rising interrupt bits.
  * @inten_fall_mask: mask bits of all rising interrupt bits.
  * @inten_rise0_shift: shift bits of rising 0 interrupt bits.
  * @inten_rise1_shift: shift bits of rising 1 interrupt bits.
@@ -136,6 +135,7 @@ enum soc_type {
  * @inten_fall3_shift: shift bits of falling 3 interrupt bits.
  * @tmu_intstat: Register containing the interrupt status values.
  * @tmu_intclear: Register for clearing the raised interrupt status.
+ * @intclr_fall_shift: shift bits for interrupt clear fall 0
  * @emul_con: TMU emulation controller register.
  * @emul_temp_shift: shift bits of emulation temperature.
  * @emul_time_shift: shift bits of emulation time.
@@ -193,7 +193,6 @@ struct exynos_tmu_registers {
u32 tmu_inten;
u32 inten_rise_shift;
u32 inten_rise_mask;
-   u32 inten_fall_shift;
u32 inten_fall_mask;
u32 inten_rise0_shift;
u32 inten_rise1_shift;
@@ -207,6 +206,7 @@ struct exynos_tmu_registers {
u32 tmu_intstat;
 
u32 tmu_intclear;
+   u32 intclr_fall_shift;
 
u32 emul_con;
u32 emul_temp_shift;
diff --git a/drivers/thermal/samsung/exynos_tmu_data.c 
b/drivers/thermal/samsung/exynos_tmu_data.c
index 073c292..70ad559 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.c
+++ b/drivers/thermal/samsung/exynos_tmu_data.c
@@ -115,7 +115,6 @@ static const struct exynos_tmu_registers 
exynos4412_tmu_registers = {
.inten_rise_mask = EXYNOS_TMU_RISE_INT_MASK,
.inten_rise_shift = EXYNOS_TMU_RISE_INT_SHIFT,
.inten_fall_mask = EXYNOS_TMU_FALL_INT_MASK,
-   .inten_fall_shift = EXYNOS_TMU_FALL_INT_SHIFT,
.inten_rise0_shift = EXYNOS_TMU_INTEN_RISE0_SHIFT,
.inten_rise1_shift = EXYNOS_TMU_INTEN_RISE1_SHIFT,
.inten_rise2_shift = EXYNOS_TMU_INTEN_RISE2_SHIFT,
@@ -123,6 +122,7 @@ static const struct exynos_tmu_registers 
exynos4412_tmu_registers = {
.inten_fall0_shift = EXYNOS_TMU_INTEN_FALL0_SHIFT,
.tmu_intstat = EXYNOS_TMU_REG_INTSTAT,
.tmu_intclear = EXYNOS_TMU_REG_INTCLEAR,
+   .intclr_fall_shift = EXYNOS_TMU_CLEAR_FALL_INT_SHIFT,
.emul_con = EXYNOS_EMUL_CON,
.emul_temp_shift = EXYNOS_EMUL_DATA_SHIFT,
.emul_time_shift = EXYNOS_EMUL_TIME_SHIFT,
@@ -220,7 +220,6 @@ static const struct exynos_tmu_registers 
exynos5440_tmu_registers = {
.inten_rise_mask = EXYNOS5440_TMU_RISE_INT_MASK,

[PATCH] kcore: add Kconfig help text

[Randy Dunlap]

From: Randy Dunlap 

Under Pseudo filesystems, /proc/kcore support has no help,
so add some.

Fixes a portion of kernel bugzilla #52671:
  https://bugzilla.kernel.org/show_bug.cgi?id=52671

Signed-off-by: Randy Dunlap 
Reported-by: lailavrazda1...@gmail.com
---
Would anyone like to expand on this help text?
Thanks.

 fs/proc/Kconfig |2 ++
 1 file changed, 2 insertions(+)

--- lnx-312.orig/fs/proc/Kconfig
+++ lnx-312/fs/proc/Kconfig
@@ -31,6 +31,8 @@ config PROC_FS
 config PROC_KCORE
bool "/proc/kcore support" if !ARM
depends on PROC_FS && MMU
+   help
+ Exports kernel core in ELF format.
 
 config PROC_VMCORE
bool "/proc/vmcore support"
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3 v8] thermal: samsung: change base_common to more meaningful base_second

[Naveen Krishna Chatradhi]

On Exynos5440 and Exynos5420 there are registers common
across the TMU channels.

To support that, we introduced a ADDRESS_MULTIPLE flag in the
driver and the 2nd set of register base and size are provided
in the "reg" property of the node.

As per Amit's suggestion, this patch changes the base_common
to base_second and SHARED_MEMORY to ADDRESS_MULTIPLE.

Signed-off-by: Naveen Krishna Chatradhi 
---
Changes since v1:
 None
Changes since v2:
 Changed the flag name from SHARED_MEMORY to ADDRESS_MULTIPLE.
 https://lkml.org/lkml/2013/8/1/38
Changes since v3:
 None
Changes since v4:
 Corrected a compilation error, undeclared variable
Changes since v5:
 None
Changes since v6:
 None
Changes since v7:
 None

 .../devicetree/bindings/thermal/exynos-thermal.txt   |4 ++--
 drivers/thermal/samsung/exynos_tmu.c |   14 +++---
 drivers/thermal/samsung/exynos_tmu.h |4 ++--
 drivers/thermal/samsung/exynos_tmu_data.c|2 +-
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index 284f530..116cca0 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -11,8 +11,8 @@
 - reg : Address range of the thermal registers. For soc's which has multiple
instances of TMU and some registers are shared across all TMU's like
interrupt related then 2 set of register has to supplied. First set
-   belongs to each instance of TMU and second set belongs to common TMU
-   registers.
+   belongs to each instance of TMU and second set belongs to second set
+   of common TMU registers.
 - interrupts : Should contain interrupt for thermal system
 - clocks : The main clock for TMU device
 - clock-names : Thermal system clock name
diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index b2202fa..ae80a87 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -41,7 +41,7 @@
  * @id: identifier of the one instance of the TMU controller.
  * @pdata: pointer to the tmu platform/configuration data
  * @base: base address of the single instance of the TMU controller.
- * @base_common: base address of the common registers of the TMU controller.
+ * @base_second: base address of the common registers of the TMU controller.
  * @irq: irq number of the TMU controller.
  * @soc: id of the SOC type.
  * @irq_work: pointer to the irq work structure.
@@ -56,7 +56,7 @@ struct exynos_tmu_data {
int id;
struct exynos_tmu_platform_data *pdata;
void __iomem *base;
-   void __iomem *base_common;
+   void __iomem *base_second;
int irq;
enum soc_type soc;
struct work_struct irq_work;
@@ -297,7 +297,7 @@ skip_calib_data:
}
/*Clear the PMIN in the common TMU register*/
if (reg->tmu_pmin && !data->id)
-   writel(0, data->base_common + reg->tmu_pmin);
+   writel(0, data->base_second + reg->tmu_pmin);
 out:
clk_disable(data->clk);
mutex_unlock(>lock);
@@ -454,7 +454,7 @@ static void exynos_tmu_work(struct work_struct *work)
 
/* Find which sensor generated this interrupt */
if (reg->tmu_irqstatus) {
-   val_type = readl(data->base_common + reg->tmu_irqstatus);
+   val_type = readl(data->base_second + reg->tmu_irqstatus);
if (!((val_type >> data->id) & 0x1))
goto out;
}
@@ -579,7 +579,7 @@ static int exynos_map_dt_data(struct platform_device *pdev)
 * Check if the TMU shares some registers and then try to map the
 * memory of common registers.
 */
-   if (!TMU_SUPPORTS(pdata, SHARED_MEMORY))
+   if (!TMU_SUPPORTS(pdata, ADDRESS_MULTIPLE))
return 0;
 
if (of_address_to_resource(pdev->dev.of_node, 1, )) {
@@ -587,9 +587,9 @@ static int exynos_map_dt_data(struct platform_device *pdev)
return -ENODEV;
}
 
-   data->base_common = devm_ioremap(>dev, res.start,
+   data->base_second = devm_ioremap(>dev, res.start,
resource_size());
-   if (!data->base_common) {
+   if (!data->base_second) {
dev_err(>dev, "Failed to ioremap memory\n");
return -ENOMEM;
}
diff --git a/drivers/thermal/samsung/exynos_tmu.h 
b/drivers/thermal/samsung/exynos_tmu.h
index 39fca47..0591089 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -60,7 +60,7 @@ enum soc_type {
  * state(active/idle) can be checked.
  * TMU_SUPPORT_EMUL_TIME - This features allows to set next temp emulation
  * sample time.
- * TMU_SUPPORT_SHARED_MEMORY - This 

Re: [PATCH v3 8/9] ARM: add Armada 1500-mini and Chromecast device tree files

[Jisheng Zhang]

On Tue, 5 Nov 2013 06:28:42 -0800
Sebastian Hesselbarth  wrote:

> This adds very basic device tree files for the Marvell Armada
> 1500-mini SoC (Berlin BG2CD) and the Google Chromecast. Currently,
> SoC only has nodes for cpu, some clocks, l2 cache controller, local
> timer, apb timers, uart, and interrupt controllers.
> The Google Chromecast is a consumer device comprising the Armada
> 1500-mini SoC above.
> 
> Signed-off-by: Sebastian Hesselbarth 
> ---
> Changelog:
> v3:
> - initial patch
> 
> Cc: Rob Herring 
> Cc: Pawel Moll 
> Cc: Mark Rutland 
> Cc: Stephen Warren 
> Cc: Ian Campbell 
> Cc: Rob Landley 
> Cc: Russell King 
> Cc: devicet...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  arch/arm/boot/dts/Makefile|3 +-
>  arch/arm/boot/dts/berlin2cd-google-chromecast.dts |   29 +++
>  arch/arm/boot/dts/berlin2cd.dtsi  |  212
> + 3 files changed, 243 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/boot/dts/berlin2cd-google-chromecast.dts
>  create mode 100644 arch/arm/boot/dts/berlin2cd.dtsi
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index c9c1a6c..dac733f 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -47,7 +47,8 @@ dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb
>  dtb-$(CONFIG_ARCH_BCM) += bcm11351-brt.dtb \
> bcm28155-ap.dtb
>  dtb-$(CONFIG_ARCH_BERLIN) += \
> -   berlin2-sony-nsz-gs7.dtb
> +   berlin2-sony-nsz-gs7.dtb \
> +   berlin2cd-google-chromecast.dtb
>  dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
> da850-evm.dtb
>  dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \
> diff --git a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
> b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts new file mode 100644
> index 000..bcd81ff
> --- /dev/null
> +++ b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
> @@ -0,0 +1,29 @@
> +/*
> + * Device Tree file for Google Chromecast
> + *
> + * Sebastian Hesselbarth 
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +/dts-v1/;
> +
> +#include "berlin2cd.dtsi"
> +
> +/ {
> +   model = "Google Chromecast";
> +   compatible = "google,chromecast", "marvell,berlin2cd",
> "marvell,berlin"; +
> +   chosen {
> +   bootargs = "console=ttyS0,115200 earlyprintk";
> +   };
> +
> +   memory {
> +   device_type = "memory";
> +   reg = <0x 0x2000>; /* 512 MB */
> +   };
> +};
> +
> + { status = "okay"; };
> diff --git a/arch/arm/boot/dts/berlin2cd.dtsi
> b/arch/arm/boot/dts/berlin2cd.dtsi new file mode 100644
> index 000..40d1bed
> --- /dev/null
> +++ b/arch/arm/boot/dts/berlin2cd.dtsi
> @@ -0,0 +1,212 @@
> +/*
> + * Device Tree Include file for Marvell Armada 1500-mini (Berlin BG2CD) SoC
> + *
> + * Sebastian Hesselbarth 
> + *
> + * based on GPL'ed 2.6 kernel sources
> + *  (c) Marvell International Ltd.
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include "skeleton.dtsi"
> +#include 
> +
> +/ {
> +   model = "Marvell Armada 1500-mini (BG2CD) SoC";
> +   compatible = "marvell,berlin2cd", "marvell,berlin";
> +
> +   cpus {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   cpu@0 {
> +   compatible = "arm,cortex-a9";
> +   device_type = "cpu";
> +   next-level-cache = <>;
> +   reg = <0>;
> +   };
> +   };
> +
> +   clocks {
> +   smclk: sysmgr-clock {
> +   compatible = "fixed-clock";
> +   #clock-cells = <0>;
> +   clock-frequency = <2500>;
> +   };
> +
> +   cfgclk: cfg-clock {
> +   compatible = "fixed-clock";
> +   #clock-cells = <0>;
> +   clock-frequency = <7500>;
> +   };
> +
> +   sysclk: system-clock {
> +   compatible = "fixed-clock";
> +   #clock-cells = <0>;
> +   clock-frequency = <3>;
> +   };
> +   };
> +
> +   soc {
> +   compatible = "simple-bus";
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +   interrupt-parent = <>;
> +
> +   ranges = <0 0xf700 0x100>;
> +
> +   l2: l2-cache-controller@ac {
> +   compatible = "arm,pl310-cache";
> +   

Re: [PATCH v3 9/9] ARM: add initial support for Marvell Berlin SoCs

[Jisheng Zhang]

Dear Sebastian,

On Tue, 5 Nov 2013 06:28:43 -0800
Sebastian Hesselbarth  wrote:

> This adds initial support for the Marvell Berlin SoC family with
> Armada 1500 (88DE3100) and Armada 1500-mini (88DE3005) SoCs.
> 
> Signed-off-by: Sebastian Hesselbarth 
> Reviewed-by: Jason Cooper 
> Reviewed-by: Thomas Petazzoni 
> Reviewed-by: Arnd Bergmann 
> ---
> Changelog:
> v2->v3:
> - add Armada 1500-mini (BG2CD) Kconfig
> v1->v2:
> - replace 88DE3xxx numbering with SoC variant name
>   (Requested by Jisheng Zhang)
> - remove LOCAL_TIMERS dependency (Suggested by Dinh Nguyen)
> RFCv2->v1:
> - remove custom .init_time, adds dependency for arch-wide of_clk_init call
> RFCv1->RFCv2:
> - nuke .map_io (Reported by Arnd Bergmann)
> - add copyright reference
> - switch to mach-berlin instead of mach-mvebu
> 
> Cc: Russell King 
> Cc: Arnd Bergmann 
> Cc: Olof Johansson 
> Cc: Kevin Hilman 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  arch/arm/Kconfig  |2 ++
>  arch/arm/Makefile |1 +
>  arch/arm/mach-berlin/Kconfig  |   30 ++
>  arch/arm/mach-berlin/Makefile |1 +
>  arch/arm/mach-berlin/berlin.c |   39
> +++ 5 files changed, 73 insertions(+)
>  create mode 100644 arch/arm/mach-berlin/Kconfig
>  create mode 100644 arch/arm/mach-berlin/Makefile
>  create mode 100644 arch/arm/mach-berlin/berlin.c
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 1ad6fb6..5692426 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -932,6 +932,8 @@ source "arch/arm/mach-bcm/Kconfig"
>  
>  source "arch/arm/mach-bcm2835/Kconfig"
>  
> +source "arch/arm/mach-berlin/Kconfig"
> +
>  source "arch/arm/mach-clps711x/Kconfig"
>  
>  source "arch/arm/mach-cns3xxx/Kconfig"
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index db50b62..07258c7 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -147,6 +147,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
>  machine-$(CONFIG_ARCH_AT91)  += at91
>  machine-$(CONFIG_ARCH_BCM)   += bcm
>  machine-$(CONFIG_ARCH_BCM2835)   += bcm2835
> +machine-$(CONFIG_ARCH_BERLIN)+= berlin
>  machine-$(CONFIG_ARCH_CLPS711X)  += clps711x
>  machine-$(CONFIG_ARCH_CNS3XXX)   += cns3xxx
>  machine-$(CONFIG_ARCH_DAVINCI)   += davinci
> diff --git a/arch/arm/mach-berlin/Kconfig b/arch/arm/mach-berlin/Kconfig
> new file mode 100644
> index 000..c5b39b1
> --- /dev/null
> +++ b/arch/arm/mach-berlin/Kconfig
> @@ -0,0 +1,30 @@
> +config ARCH_BERLIN
> + bool "Marvell Berlin SoCs" if ARCH_MULTI_V7
> + select GENERIC_CLOCKEVENTS
> + select GENERIC_IRQ_CHIP
> + select COMMON_CLK
> + select DW_APB_ICTL
> + select DW_APB_TIMER_OF
> +
> +if ARCH_BERLIN
> +
> +menu "Marvell Berlin SoC variants"
> +
> +config MACH_BERLIN_BG2
> + bool "Marvell Armada 1500 (BG2)"
> + select ARM_GIC
ARM_GIC is common on berlin SoCs. we can put it below ARCH_BERLIN?
> + select CACHE_L2X0
ditto
> + select CPU_PJ4B
> + select HAVE_ARM_TWD
> + select HAVE_SMP
> +
> +config MACH_BERLIN_BG2CD
> + bool "Marvell Armada 1500-mini (BG2CD)"
> + select ARM_GIC
> + select CACHE_L2X0
> + select CPU_V7
> + select HAVE_ARM_TWD
BG2CD is single core, I'm not sure it have twd. I will check with SoC people.
But can twd be really used in single CA9 system?
> +
> +endmenu
> +
> +endif
> diff --git a/arch/arm/mach-berlin/Makefile b/arch/arm/mach-berlin/Makefile
> new file mode 100644
> index 000..ab69fe9
> --- /dev/null
> +++ b/arch/arm/mach-berlin/Makefile
> @@ -0,0 +1 @@
> +obj-y += berlin.o
> diff --git a/arch/arm/mach-berlin/berlin.c b/arch/arm/mach-berlin/berlin.c
> new file mode 100644
> index 000..16c2942
> --- /dev/null
> +++ b/arch/arm/mach-berlin/berlin.c
> @@ -0,0 +1,39 @@
> +/*
> + * Device Tree support for Marvell Berlin SoCs.
> + *
> + * Sebastian Hesselbarth 
> + *
> + * based on GPL'ed 2.6 kernel sources
> + *  (c) Marvell International Ltd.
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static void __init berlin_init_machine(void)
> +{
> + /*
> +  * with DT probing for L2CCs, berlin_init_machine can be removed.
> +  * Note: 88DE3005 (Armada 1500-mini) uses pl310 l2cc
> +  */
> + l2x0_of_init(0x70c0, 0xfeff);
Per my experience, put l2x0 initialization in init_machine is too late. It
did cause some boot stability problems during our product massive bootup test.
In our internal 3.10.y tree, we put it in init_early, I also suggest we do
this too in mainline.
> + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
If l2 initialization is put 

kernel bugzilla #64531: intel microcode information

[Randy Dunlap]

Re: https://bugzilla.kernel.org/show_bug.cgi?id=64531


arch/x86/Kconfig line 1053 (+/-), help section in CONFIG_MICROCODE_INTEL, says:

For latest news and information on obtaining all the required
Intel ingredients for this driver, check:


==> 404  Page not found


Is there a good replacement for this information or should we just
delete that help text?


thanks,

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

Re: [GIT PULL] uprobes: preparations for arm port

[Srikar Dronamraju]

* Oleg Nesterov  [2013-11-06 20:19:13]:

> Ingo, please pull from
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/oleg/misc uprobes/core
> 
> 
> I have also attached the cumulative diff below. As you can see,
> the changes are really simple and there are no functional changes.
> 
> However I think it makes sense to merge this now, this way the
> upcoming arm port doesn't (almost) need the changes outside of
> arch/arm and thus it would be simpler to route everything via
> arm trees.
> 
> 
> David A. Long (1):
>   uprobes: Move function declarations out of arch
> 
> Oleg Nesterov (3):
>   uprobes: Kill module_init() and module_exit()
>   uprobes: Introduce arch_uprobe->ixol
>   uprobes: Export write_opcode() as uprobe_write_opcode()
> 

Acked-by: Srikar Dronamraju 
for this series.

-- 
Thanks and Regards
Srikar Dronamraju

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 V7 5/7] POWER/cpuidle: Generic POWER CPUIDLE driver supporting PSERIES.

[Deepthi Dharwar]

On 11/07/2013 10:31 AM, Benjamin Herrenschmidt wrote:
> On Thu, 2013-11-07 at 09:45 +0530, Deepthi Dharwar wrote:
>> 'powerpc' would be very generic arch and would comprise of all platforms
>> including embedded 32/64 bit to server 64 bit (similar to that of ARM).
>> This driver does not intend to support complete powerpc arch, but just
>> PSERIES and POWERNV platforms termed as 'POWER' processors. So to avoid
>> confusion btw 'power mgmt' and 'POWER' archs, I have prefixed both the
>> driver and file names with 'IBM'namely ibm-power-driver, cpuidle-ibm-power.
> 

Hi Ben,

> Why not book3s ? powerpc-book3s ?

I went with 'ibm-power' thinking it would resolve the confusion,
but if ppl feel that is is good to get away from 'POWER' and have
powerpc-book3s instead to make things clearer, I am open for it.


Regards,
Deepthi

> That's what we use in other places to differenciate between the families
> 
> Ben.
> 
> 

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

Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random

[Stephan Mueller]

Am Donnerstag, 7. November 2013, 02:03:57 schrieb Nicholas Mc Guire:

Hi Nicholas,

>On Wed, 06 Nov 2013, Stephan Mueller wrote:
>> Am Mittwoch, 6. November 2013, 07:43:54 schrieb Theodore Ts'o:
>> 
>> Hi Theodore,
>> 
>> >On Wed, Nov 06, 2013 at 12:49:45PM +0100, Stephan Mueller wrote:
>> >> Here is a quote from his answer to my question whether he was able
>> >> to
>> >> identify the root cause:
>> >> 
>> >> "its inherent in the microtiming of Hardware and there is nothing
>> >> you
>> >> can do about it if you want the root cause is quantum physics"
>> >
>> >That's unfortunate, since it leaves open the question of whether
>> >this
>> >jitter is something that could be at least somewhat predictable if
>> >you
>> >had a lot more information about the internal works of the CPU or
>> >not
>> 
>> I do not understand that answer: I thought we are talking about the
>> search of non-predictable noise sources. If you cannot predict the
>> sequence even if you have the state of the CPU, that is what we are
>> looking for, is it not?
>
>unpredictabilitty of the individual event does not imply that you do
>not have the ability to "guess" with more than 50% - that is just
>because it is not predictable
>does not mean itt is bias-free (and more importantly here that the bias
>is not influenced by controllable factors like load). Attached is a
>simple demonstration of this problem (gauss.c) that runs in user-space
>and harvestts entropy by race occurrence, while the distribution is a
>nice normal distribution (on multticore it is an overlay of multtiple
>normal distributions - one per core-pairing possible) it is not load
>independent. Never the less the individual event (race/no-race) is not
>predictable.

Thank you for sharing your ideas and code.

There is one deviation of my RNG from your considerations. My RNG is not 
around race contention (i.e. your software-based uncertainty) but a 
simple measurement of how long some instruction take to execute.

So, how can I induce skews? By trying to disable CPU logic or fudge with 
the CPU support (like cache attacks, etc). My tests have shown that 
disabling some CPU logic may diminish timing variations, but they are 
still sufficiently large to support the RNG.

So, when we already have variations that are sufficient (i.e. the 
entropy is sufficient), using the CPU features that initially have been 
disabled but are now added on top of an already sufficient set of 
variations cannot diminish the entropy that is already present. Even 
when we assume we have full control over the CPU features, I do not see 
a way how we can use these features to cancel already existing 
variations out.

Or do you have an idea how that can be established? Note, we all must 
assume that an attacker is only in user state. Anything else is 
meaningless.

>> Besides, how on earth shall an attacker even gain knowledge about the
>> state of the CPU or disable CPU mechanisms? Oh, I forgot, your NSA
>> guy. But if he is able to do that, all discussions are moot because
>> he simply disables any noise sources by flipping a bit, reads the
>> memory that is used to hold the state of the RNG or just overwrites
>> the memory locations where data is collected, because the general
>> protection mechanisms offered by the kernel and the underlying
>> hardware are broken.
>No need to gain knowledge of the internal CPU state itt would be
>sufficient to be able to put the CPU in a sub-state-space in which
>the distribution is shifted. it may be enough to reduce the truely
>random bits of some key only by a few bits to make it suceptible to
>brute force attacks.

Note, the proposed RNG contains an unbias operation (the Von-Neumann 
unbiaser) which is proven to remove any bias when it is established that 
the individual observations are independent. And the way the 
observations are generated ensures that they are independent. Thus, a 
skew should not be a concern here.

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

Re: [PATCH v4] binfmt_elf.c: use get_random_int() to fix entropy depleting

[Stephan Mueller]

Am Donnerstag, 7. November 2013, 12:14:17 schrieb Jeff Liu:

Hi Jeff,

>Hi Stephan,
>
>As per your previous comments for this fix, you have promised another
>approach which is promising to avoid entropy starvation, I got this
>info from the following thread: [PATCH] avoid entropy starvation due
>to stack protection
>https://lkml.org/lkml/2012/12/14/267

There are several solutions:

- Ted is trying to prevent a constant reseeding of the nonblocking_pool 
from the input_pool with a set of patches. I am unsure whether these 
patches find their way into the kernel. With those patches, we can 
happily keep get_random_bytes without too much strain on the input_pool 
entropy -- i.e. drop the conversion to get_random_int.

- The begin of the email thread contains a patch that adds a new pool 
which I called the kernel_pool that is just just for kernel internal 
purposes. With Teds proposed changes to nonblocking_pool, 
nonblocking_pool would behave almost like my kernel_pool and thus my 
kernel_pool patch would not be needed.

- Lastly I am trying to add a new seed source to random.c and kernel 
crypto API which could also be used as a stand-alone noise source. That 
proposed noise source would effectively alleviate a lot of entropy 
problems. The discussion for inclusion is raging at 
http://lkml.org/lkml/2013/10/11/582. Ted is having concerns and we are 
in a discussion to address those.
>
>My current fix has been merged into Andrew's tree(marked in "stuck"
>state) for a long time, and it also works well in our internal
>specific kernel, I'd like to know if there is any update from you, so
>that we can move it along for mainline. :)
>
>Thanks,
>-Jeff


Ciao
Stephan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random

[Stephan Mueller]

Am Mittwoch, 6. November 2013, 08:04:32 schrieb Theodore Ts'o:

Hi Theodore,

>On Wed, Nov 06, 2013 at 01:51:17PM +0100, Stephan Mueller wrote:
>> >That's unfortunate, since it leaves open the question of whether
>> >this
>> >jitter is something that could be at least somewhat predictable if
>> >you
>> >had a lot more information about the internal works of the CPU or
>> >not
>> 
>> I do not understand that answer: I thought we are talking about the
>> search of non-predictable noise sources. If you cannot predict the
>> sequence even if you have the state of the CPU, that is what we are
>> looking for, is it not?
>
>I was asking the question about whether someone who knew more about
>the internal _workings_ of the CPU, note of the state of the CPU.
>This is not necessarily "the NSA guy", but someone who knows more
>about the internal workings of the Intel CPU (such as an Intel
>engineer --- and I've had Intel express misgivings about approaches
>which depend on "CPU jitter" approaches), or just someone who has
>spent a lot more time trying to examine the black box of the Intel CPU
>from the outside.

I try to get more information from my contacts to other vendors. But I 
am wondering what shall we do if the answer is (maybe even proven with 
some test results) that they see the same issue themselves and have no 
handle on it?

I mean, what is it that I would need to test and demonstrate to prove or 
disprove my RNG? We can certainly test very much, but one thing we 
cannot prove, and that is the fundamental jitter, provided it is a 
result of quantum fluctuations. Just as with any other noise source, 
basic fundamental principles are hard if not impossible to test.

I would again like to stress the fact that we see the root cause to a 
similar degree on all major CPUs that we have around us. All of these 
CPUs work differently and yet they show a common behavior, the execution 
time variations. I wonder whether this is already a good indication 
>
>I remember making my own home-grown encryption algorithm before I
>entered college, secure in my arrogance that I had created something
>so complicated that no one could crack it.  Of course, as I got older
>and wiser, I realized that it just meant it was just something *I*
>couldn't yet anaylze and crack.  The argument "the internal state of
>the CPU is so large, and the state transitions ar so complex
>that it *must* be unpredictable, because *I* can't predict them" seems
>to be a very similar mistake that I made many years ago when I was in
>high school.

Agreed, I do not want to state that nobody is able to obtain the state 
(especially considering that the CPUs *must* have some hardware 
debugging hooks somewhere that should allow dumping out the current 
state of the entire CPU to aid CPU development). However, we also have 
to consider our threat model: to me, an attacker can only reside in user 
state of the CPU. All that he can observe there can be used against us. 
Anything that he can only do when in supervisor state is not of 
interest, because gathering and maintaining entropy is the least of our 
worries in this case.
>
>Of course, some of the state in the CPU may not be unknown to the
>attacker, if it is derived by external events that are not visible to
>the attacker, such as a network interrupt.  But if that's the case,
>why not measure network interrupts directly?  We're much less likely
>to overestimate the amount of entropy we can extract the system in
>that case.

To aid that discussion, let us assume that the variations are solely 
based on the CPU state (which indications show that this is not the 
case). When you focus on only the interrupts (or only one interrupt for 
that matter) we limit the base from which we try to obtain entropy.

If you are concerned about the entropy level we add with the proposed 
jitter RNG, what about the following:

- when mixing in bits from the jitter RNG into the entropy pools of 
random.c, we increase the entropy estimator not by the equivalent amount 
of bits, but some fraction. For example:

...
ret = jent_read_entropy(>entropy_collector, rand, JENTBLOCKSIZE);
...
_mix_pool_bytes(r, rand, ret, NULL);
credit_entropy_bits(r, (ret * 8) / 2);

This code would only increase the entropy estimator by half of the 
obtained bits

- The jitter RNG allows specifying an oversampling rate where it 
oversamples the jitter by multiples of the given value. The default is 1 
(i.e. no oversampling). But we could set it to 2 (double oversampling). 
The code is here:

r->entropy_collector.osr = 1;

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

Re: [PATCH] kbuild: replace unbounded sprintf call in modpost

[Michal Marek]

On Fri, Oct 25, 2013 at 06:14:43AM -0700, Kees Cook wrote:
> The modpost tool could overflow its stack buffer if someone was running
> with an insane shell environment. Regardless, it's technically a bug,
> so this fixes it to truncate the string instead of seg-faulting.
> 
> Found by Coverity.
> 
> Signed-off-by: Kees Cook 

Applied to kbuild.git#kbuild.

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] kbuild: Increase kallsyms max symbol length v2

[Michal Marek]

On Wed, Oct 23, 2013 at 03:06:53PM +0200, Andi Kleen wrote:
> From: Joe Mario 
> 
> [AK: This seems like a ticking time bomb even without LTO,
> so should be merged now. It causes very weird problems.
> Thanks to Joe for tracking them down.]
> 
> With the added postfixes that LTO adds for local
> symbols, the longest name in the kernel overflows
> the namebuf[KSYM_NAME_LEN] array by two bytes.  That name is:
> __pci_fixup_resumePCI_VENDOR_ID_SERVERWORKSPCI_DEVICE_ID_SERVERWORKS_HT1000SBquirk_disable_broadcom_boot_interrupt.1488004.672802
> 
> Double the max symbol name length.
> 
> v2: Use 255  (Joe Perches)
> Signed-off-by: Andi Kleen 

Applied to kbuild.git#kbuild.

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ARM: l2x0: add prefetch and power ctrl registers configuration support

[Jisheng Zhang]

PL310 supports Prefetch offset/control register from r2p0 and Power
control register from r3p0. This patch adds the support to configure
these two registers if there are. The dt binding document is also updated.

Signed-off-by: Jisheng Zhang 
---
 Documentation/devicetree/bindings/arm/l2cc.txt |  4 
 arch/arm/mm/cache-l2x0.c   | 19 +++
 2 files changed, 23 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt 
b/Documentation/devicetree/bindings/arm/l2cc.txt
index c0c7626..32cd08c 100644
--- a/Documentation/devicetree/bindings/arm/l2cc.txt
+++ b/Documentation/devicetree/bindings/arm/l2cc.txt
@@ -39,6 +39,10 @@ Optional properties:
 - arm,filter-ranges :  Starting address and length of window to
   filter. Addresses in the filter window are directed to the M1 port. Other
   addresses will go to the M0 port.
+- arm,prefetch-ctrl : The value for Prefetch Offset/Control Register if there
+  is. This is a single cell.
+- arm,pwr-ctrl : The value for Power Control Register if there is. This is a
+  single cell.
 - interrupts : 1 combined interrupt.
 - cache-id-part: cache id part number to be used if it is not present
   on hardware
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 447da6f..8f536ea 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -704,6 +704,8 @@ static void __init pl310_of_setup(const struct device_node 
*np,
u32 data[3] = { 0, 0, 0 };
u32 tag[3] = { 0, 0, 0 };
u32 filter[2] = { 0, 0 };
+   u32 l2x0_revision = readl_relaxed(l2x0_base + L2X0_CACHE_ID) &
+   L2X0_CACHE_ID_RTL_MASK;
 
of_property_read_u32_array(np, "arm,tag-latency", tag, ARRAY_SIZE(tag));
if (tag[0] && tag[1] && tag[2])
@@ -730,6 +732,23 @@ static void __init pl310_of_setup(const struct device_node 
*np,
writel_relaxed((filter[0] & ~(SZ_1M - 1)) | L2X0_ADDR_FILTER_EN,
   l2x0_base + L2X0_ADDR_FILTER_START);
}
+
+   if (l2x0_revision >= L2X0_CACHE_ID_RTL_R2P0) {
+   u32 prefetch_ctrl = 0;
+
+   of_property_read_u32(np, "arm,prefetch-ctrl",
+_ctrl);
+   if (prefetch_ctrl)
+   writel_relaxed(prefetch_ctrl, l2x0_base +
+   L2X0_PREFETCH_CTRL);
+   if (l2x0_revision >= L2X0_CACHE_ID_RTL_R3P0) {
+   u32 pwr_ctrl = 0;
+   of_property_read_u32(np, "arm,pwr-ctrl", _ctrl);
+   if (pwr_ctrl)
+   writel_relaxed(pwr_ctrl, l2x0_base +
+   L2X0_POWER_CTRL);
+   }
+   }
 }
 
 static void __init pl310_save(void)
-- 
1.8.4.2

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

Re: [trivial PATCH] module.h: Remove unnecessary semicolon

[Joe Perches]

On Thu, 2013-11-07 at 12:32 +1030, Rusty Russell wrote:
> Joe Perches  writes:
> > This semicolon isn't necessary, remove it.
> >
> > Signed-off-by: Joe Perches 
> 
> This is a terrible description.  Really bad.

I'd've preferred no description.

> First, it just repeats the subject, with more words.

Which others have demanded.

> Second, it gives me no indication that you've done a grep to make sure
> noone is abusing the macro, so I can't apply it without doing that check
> myself.

That's a trust issue.
I've done it.  It isn't necessary.
The other #define module_put_and_exit in a
different #if #else already doesn't have one.

Trust it or not, apply it or not.

> Please try again.

No thanks.

cheers, Joe

> > diff --git a/include/linux/module.h b/include/linux/module.h
[]
> > @@ -454,7 +454,7 @@ int module_kallsyms_on_each_symbol(int (*fn)(void *, 
> > const char *,
> >  
> >  extern void __module_put_and_exit(struct module *mod, long code)
> > __attribute__((noreturn));
> > -#define module_put_and_exit(code) __module_put_and_exit(THIS_MODULE, code);
> > +#define module_put_and_exit(code) __module_put_and_exit(THIS_MODULE, code)
> >  
> >  #ifdef CONFIG_MODULE_UNLOAD
> >  unsigned long module_refcount(struct module *mod);

$ git grep -w module_put_and_exit
crypto/algboss.c:   module_put_and_exit(0);
crypto/algboss.c:   module_put_and_exit(0);
fs/cifs/connect.c:  module_put_and_exit(0);
fs/nfs/nfs4state.c: module_put_and_exit(0);
fs/nfsd/nfssvc.c:   module_put_and_exit(0);
include/linux/module.h:#define module_put_and_exit(code) 
__module_put_and_exit(THIS_MODULE, code);
include/linux/module.h:#define module_put_and_exit(code) do_exit(code)
net/bluetooth/bnep/core.c:  module_put_and_exit(0);
net/bluetooth/cmtp/core.c:  module_put_and_exit(0);
net/bluetooth/hidp/core.c:  module_put_and_exit(0);


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

Re: [PATCH] cpufreq: conservative: fix requested_freq reduction issue

[Viresh Kumar]

On 7 November 2013 07:58, Xiaoguang Chen  wrote:
> When decreasing frequency, requested_freq may be less than
> freq_target, So requested_freq minus freq_target may be negative,
> But reqested_freq's unit is unsigned int, then the negative result
> will be one larger interger which may be even higher than
> requested_freq.
>
> This patch is to fix such issue. when result becomes negative,
> set requested_freq as the min value of policy.
>
> Signed-off-by: Xiaoguang Chen 
> ---
>  drivers/cpufreq/cpufreq_conservative.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)

Good Catch.

Acked-by: Viresh Kumar 

We need another patch for fixing the other part of code where we
increase freq..
We need to replace:

if (dbs_info->requested_freq == policy->max)
return;

with

if (dbs_info->requested_freq >= policy->max)
return;

So, that we don't run unnecessary code :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG][ext2] XIP does not work on ext2

[Jan Kara]

On Tue 05-11-13 17:28:35, Andiry Xu wrote:
> Hi,
> 
> On Tue, Nov 5, 2013 at 6:32 AM, Jan Kara  wrote:
> >   Hello,
> >
> > On Mon 04-11-13 18:37:40, Andiry Xu wrote:
> >> On Mon, Nov 4, 2013 at 4:37 PM, Jan Kara  wrote:
> >> >   Hello,
> >> >
> >> > On Mon 04-11-13 14:31:34, Andiry Xu wrote:
> >> >> When I'm trying XIP on ext2, I find that xip does not work on ext2
> >> >> with latest kernel.
> >> >>
> >> >> Reproduce steps:
> >> >> Compile kernel with following configs:
> >> >> CONFIG_BLK_DEV_XIP=y
> >> >> CONFIG_EXT2_FS_XIP=y
> >> >>
> >> >> And run following commands:
> >> >> # mke2fs -b 4096 /dev/ram0
> >> >> # mount -t ext2 -o xip /dev/ram0 /mnt/ramdisk/
> >> >> # dd if=/dev/zero of=/mnt/ramdisk/test1 bs=1M count=16
> >> >>
> >> >> And it shows:
> >> >> dd: writing `/mnt/ramdisk/test1': No space left on device
> >> >>
> >> >> df also shows /mnt/ramdisk is 100% full. Its default size is 64MB so a
> >> >> 16MB write should only occupy 1/4 capacity.
> >> >>
> >> >> Criminal commit:
> >> >> After git bisect, it points to the following commit:
> >> >> 8e3dffc651cb668e1ff4d8b89cc1c3dde7540d3b
> >> >> Ext2: mark inode dirty after the function dquot_free_block_nodirty is 
> >> >> called
> >> >   Thanks for report and the bisection!
> >> >
> >> >> Particularly, the following code:
> >> >> @@ -1412,9 +1415,11 @@ allocated:
> >> >> *errp = 0;
> >> >> brelse(bitmap_bh);
> >> >> -dquot_free_block_nodirty(inode, *count-num);
> >> >> -mark_inode_dirty(inode);
> >> >> -*count = num;
> >> >> +if (num < *count) {
> >> >> +dquot_free_block_nodirty(inode, *count-num);
> >> >> +mark_inode_dirty(inode);
> >> >> +*count = num;
> >> >> +}
> >> >>   return ret_block;
> >> >>
> >> >> Not mark_inode_dirty() is called only when num is less than *count.
> >> >> However, I've seen
> >> >> with the dd command, there is case where num >= *count.
> >> >>
> >> >> Fix:
> >> >> I've verified that the following patch fixes the issue:
> >> >> diff --git a/fs/ext2/balloc.c b/fs/ext2/balloc.c
> >> >> index 9f9992b..5446a52 100644
> >> >> --- a/fs/ext2/balloc.c
> >> >> +++ b/fs/ext2/balloc.c
> >> >> @@ -1406,11 +1406,10 @@ allocated:
> >> >>
> >> >> *errp = 0;
> >> >> brelse(bitmap_bh);
> >> >> -   if (num < *count) {
> >> >> +   if (num <= *count)
> >> >> dquot_free_block_nodirty(inode, *count-num);
> >> >> -   mark_inode_dirty(inode);
> >> >> -   *count = num;
> >> >> -   }
> >> >> +   mark_inode_dirty(inode);
> >> >> +   *count = num;
> >> >> return ret_block;
> >> >>
> >> >>  io_error:
> >> >>
> >> >> However, I'm not familiar with ext2 source code and cannot tell if
> >> >> this is the correct fix. At least it fixes my issue.
> >> >   With this, you have essentially reverted a hunk from commit
> >> > 8e3dffc651cb668e1ff4d8b89cc1c3dde7540d3b. But I don't see a reason why it
> >> > should be reverted. num should never ever be greater than *count and when
> >> > num == count, we the code inside if doesn't do anything useful.
> >> >
> >> > I've looked into the code and I think I see the problem. It is a long
> >> > standing bug in __ext2_get_block() in fs/ext2/xip.c. It calls
> >> > ext2_get_block() asking for 0 blocks to map (while we really want 1 
> >> > block).
> >> > ext2_get_block() just passes that request and ext2_get_blocks() actually
> >> > allocates 1 block. And that's were the commit you have identified makes a
> >> > difference because previously we returned that 1 block was allocated 
> >> > while
> >> > now we return that 0 blocks were allocated and thus allocation is 
> >> > repeated
> >> > until all free blocks are exhaused.
> >> >
> >> > Attached patch should fix the problem.
> >> >
> >>
> >> Thanks for the reply. I've verified that your patch fixes my issue.
> >> And it's absolutely better than my solution.
> >>
> >> Tested-by: Andiry Xu 
> >   Thanks for testing!
> >
> >> I have another question about ext2 XIP performance, although it's not
> >> quite related to this thread.
> >>
> >> I'm testing xip with ext2 on a ram disk drive, the driver is brd.c.
> >> The RAM disk size is 2GB and I pre-fill it to guarantee that all pages
> >> reside in main memory.
> >> Then I use two different applications to write to the ram disk. One is
> >> open() with O_DIRECT flag, and writing with Posix write(). Another is
> >> open() with O_DIRECT, mmap() it to user space, then use memcpy() to
> >> write data. I use different request size to write data, from 512 bytes
> >> to 64MB.
> >>
> >> In my understanding, the mmap version bypasses the file system and
> >> does not go to kernel space, hence it should have better performance
> >> than the Posix-write version. However, my test result shows it's not
> >> always true: when the request size is between 8KB and 1MB, the
> >> Posix-write() version has bandwidth about 7GB/s and mmap version only
> >> has 5GB/s. The test is performed on a i7-3770K machine with 8GB

Re: [PATCH] scripts/kernel-doc: make unknown function prototype a Warning instead of an Error

[Michal Marek]

On Thu, Oct 17, 2013 at 04:32:01PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap 
> 
> When scripts/kernel-doc cannot understand a function prototype,
> it had been generating a fatal error and stopping immediately.
> Make this a Warning instead of an Error and keep going.
> 
> Note that this can happen if the kernel-doc notation that is being
> parsed is not actually a function prototype; maybe it's a struct or
> something else, so I added "function" to the warning message to try
> to make it clearer that scripts/kernel-doc is looking for a function
> prototype here.
> 
> Signed-off-by: Randy Dunlap 
> Cc:   Mark Brown 

Applied to kbuild.git#misc, thanks.

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

Re: [PATCH] raid0: Set discard_granularity to correct value after reshape.

[NeilBrown]

On Tue, 5 Nov 2013 14:25:19 + "Baldysiak, Pawel"
 wrote:

> On Thursday, October 31, 2013 1:16 AM NeilBrown  wrote:
> > On Wed, 30 Oct 2013 13:20:22 +0100 Pawel Baldysiak
> >  wrote:
> > 
> > > In case of reshape of raid0 through raid4 a value of
> > > discard_granularity will be set to stripe size. MD driver should
> > > re-set this value to correct one when migration will be finished.
> > > Otherwise array will be left with wrong value and discard operations will 
> > > not
> > work properly.
> > >
> > > Signed-off-by: Pawel Baldysiak 
> > > Cc: Shaohua Li 
> > > ---
> > >  drivers/md/raid0.c |2 ++
> > >  1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/md/raid0.c b/drivers/md/raid0.c index
> > > c4d420b..807ca3a 100644
> > > --- a/drivers/md/raid0.c
> > > +++ b/drivers/md/raid0.c
> > > @@ -266,6 +266,8 @@ static int create_strip_zones(struct mddev *mddev,
> > struct r0conf **private_conf)
> > >   }
> > >   mddev->queue->backing_dev_info.congested_fn = raid0_congested;
> > >   mddev->queue->backing_dev_info.congested_data = mddev;
> > > + mddev->queue->limits.discard_granularity =
> > > + queue_logical_block_size(mddev->queue);
> > >
> > >   /*
> > >* now since we have the hard sector sizes, we can make sure
> > 
> > Thanks, but this doesn't seem like the right sort of fix.  It is to 
> > specific to the
> > symptom rather than trying to address the underlying problem.
> > 
> > Maybe something like this?  Can you review and test?
> > 
> > Thanks,
> > NeilBrown
> > 
> > 
> > diff --git a/drivers/md/md.c b/drivers/md/md.c index
> > 628cd529343f..740b6340f980 100644
> > --- a/drivers/md/md.c
> > +++ b/drivers/md/md.c
> > @@ -3620,6 +3620,7 @@ level_store(struct mddev *mddev, const char
> > *buf, size_t len)
> > mddev->in_sync = 1;
> > del_timer_sync(>safemode_timer);
> > }
> > +   blk_set_stacking_limit(>queue->limits);
> > pers->run(mddev);
> > set_bit(MD_CHANGE_DEVS, >flags);
> > mddev_resume(mddev);
> Hi Neil,
> I have tested Yours patch, and everything works well.
> TRIM operation are made correctly.
> Could You apply it to upstream? 
> 
> BTW. Correct name of this function is blk_set_stacking_limits();
> 
> Thanks,
> Paweł Baldysiak

Thanks for testing.  I've queue the following up for submission soonish.

NeilBrown

From 3d2b31bb23ccb8170fafdf358098bb3cb0836080 Mon Sep 17 00:00:00 2001
From: NeilBrown 
Date: Thu, 7 Nov 2013 13:36:36 +1100
Subject: [PATCH] md: fix calculation of stacking limits on level change.

The various ->run routines of md personalities assume that the 'queue'
has been initialised by the blk_set_stacking_limits() call in
md_alloc().

However when the level is changed (by level_store()) the ->run routine
for the new level is called for an array which has already had the
stacking limits modified.  This can result in incorrect final
settings.

So call blk_set_stacking_limits() before ->run in level_store().

A specific consequence of this bug is that it causes
discard_granularity to be set incorrectly when reshaping a RAID4 to a
RAID0.

This is suitable for any -stable kernel since 3.3 in which
blk_set_stacking_limits() was introduced.

Cc: sta...@vger.kernel.org (3.3+)
Reported-by: "Baldysiak, Pawel" 
Signed-off-by: NeilBrown 

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


signature.asc
Description: PGP signature

[GIT PULL] hwmon updates for 3.13-rc1

[Guenter Roeck]

Hi Linus,

Please pull hwmon updates for Linux 3.13-rc1 from signed tag:

git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
hwmon-for-linus

Thanks,
Guenter
--

The following changes since commit 61e6cfa80de5760bbe406f4e815b7739205754d2:

  Linux 3.12-rc5 (2013-10-13 15:41:28 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
tags/hwmon-for-linus

for you to fetch changes up to 26336c8a36c0a6a28b9ecf6f1bb8c8f5605d6a21:

  hwmon: (w83793) Clean up a signedness issue (2013-10-19 09:04:25 -0700)


hwmon updates for 3.13-rc1

Introduce new hwmon API functions hwmon_device_register_with_groups and
devm_hwmon_device_register_with_groups, and convert several drivers to use the
new API.
Add support for EMC1404, EMC1424, LTC2977, LTC2978A, LM25063 to exiting drivers
Various cleanups in several drivers


Dan Carpenter (2):
  hwmon: (nct6775) Remove an unused variable
  hwmon: (w83793) Clean up a signedness issue

Fengguang Wu (7):
  hwmon: (nct6775) fix coccinelle warnings
  hwmon: (ds1621) fix coccinelle warnings
  hwmon: (max6642 fix coccinelle warnings
  hwmon: (max6697) fix coccinelle warnings
  hwmon: (lm95234) fix coccinelle warnings
  hwmon: (ltc4261) fix coccinelle warnings
  hwmon: (jc42) fix coccinelle warnings

Guenter Roeck (36):
  hwmon: Remove unnecessary semicolons
  hwmon: (nct6775) Use return value from find_temp_source
  hwmon: (nct6775) Check array index when accessing temp_offset
  hwmon: (mc13783-adc) Increase size of name string
  hwmon: (pmbus) Don't unnecessarily crash the kernel
  hwmon: (adt7462) Use error value returned from find_trange_value()
  hwmon: (gpio_fan) Use error value returned from get_fan_speed_index()
  hwmon: (acpi_power_meter) Don't crash the kernel unnecessarily
  hwmon: (acpi_power_meter) Use return value from acpi_bus_register_driver
  hwmon: (atxp1) Set and use error code from vid_to_reg()
  hwmon: (f75375s) Don't crash the kernel unnecessarily
  hwmon: (f71882fg) Remove extra return statement
  hwmon: Introduce hwmon_device_register_with_groups
  hwmon: (ds1621) Convert to use hwmon_device_register_with_groups
  hwmon: (gpio-fan) Convert to use hwmon_device_register_with_groups
  hwmon: (ltc4245) Convert to use hwmon_device_register_with_groups
  hwmon: (pmbus) Convert to use hwmon_device_register_with_groups
  hwmon: (nct6775) Convert to use hwmon_device_register_with_groups
  hwmon: Provide managed hwmon registration
  hwmon: (nct6775) Convert to use devm_hwmon_device_register_with_groups
  hwmon: (ds1621) Convert to use devm_hwmon_device_register_with_groups
  hwmon: (max6642) Convert to use devm_hwmon_device_register_with_groups
  hwmon: (lm73) Convert to use devm_hwmon_device_register_with_groups
  hwmon: (max6697) Convert to use devm_hwmon_device_register_with_groups
  hwmon: (max16065) Convert to use devm_hwmon_device_register_with_groups
  hwmon: (ina2xx) Convert to use devm_hwmon_device_register_with_groups
  hwmon: (tmp401) Convert to use devm_hwmon_device_register_with_groups
  hwmon: (lm95234) Convert to use devm_hwmon_device_register_with_groups
  hwmon: (ina209) Convert to use devm_hwmon_device_register_with_groups
  hwmon: (ltc4261) Convert to use devm_hwmon_device_register_with_groups
  hwmon: (jc42) Convert to use devm_hwmon_device_register_with_groups
  hwmon: (pmbus/lm25066) Add support for LM25063
  hwmon: (pmbus/ltc2978): Add support for LTC2977
  hwmon: (pmbus/ltc2978): Add support for LTC2978A
  hwmon: (emc1403) Convert to use devm_hwmon_device_register_with_groups
  hwmon: (emc1403) Add support for EMC1404 and EMC1424

LABBE Corentin (1):
  hwmon: Correct some typos

Sachin Kamat (3):
  hwmon: (adcxx) Remove redundant spi_set_drvdata
  hwmon: (lm70) Remove redundant spi_set_drvdata
  hwmon: (gpio-fan) Include linux/of.h header

 Documentation/hwmon/lm25066  |   20 -
 Documentation/hwmon/ltc2978  |   44 +
 drivers/hwmon/abituguru.c|6 +-
 drivers/hwmon/abituguru3.c   |2 +-
 drivers/hwmon/acpi_power_meter.c |   13 ++-
 drivers/hwmon/adcxx.c|2 -
 drivers/hwmon/adm1026.c  |6 +-
 drivers/hwmon/adt7462.c  |5 +-
 drivers/hwmon/asc7621.c  |   12 +--
 drivers/hwmon/asus_atk0110.c |2 +-
 drivers/hwmon/atxp1.c|3 +-
 drivers/hwmon/ds1621.c   |   63 -
 drivers/hwmon/emc1403.c  |  120 +++--
 drivers/hwmon/f71882fg.c |1 -
 drivers/hwmon/f75375s.c  |4 +-
 drivers/hwmon/gpio-fan.c |   46 --
 drivers/hwmon/hwmon.c|  185 

Re: [PATCH V7 5/7] POWER/cpuidle: Generic POWER CPUIDLE driver supporting PSERIES.

[Benjamin Herrenschmidt]

On Thu, 2013-11-07 at 09:45 +0530, Deepthi Dharwar wrote:
> 'powerpc' would be very generic arch and would comprise of all platforms
> including embedded 32/64 bit to server 64 bit (similar to that of ARM).
> This driver does not intend to support complete powerpc arch, but just
> PSERIES and POWERNV platforms termed as 'POWER' processors. So to avoid
> confusion btw 'power mgmt' and 'POWER' archs, I have prefixed both the
> driver and file names with 'IBM'namely ibm-power-driver, cpuidle-ibm-power.

Why not book3s ? powerpc-book3s ?

That's what we use in other places to differenciate between the families

Ben.


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

Re: [PATCH] block: Revert bio_clone() default behaviour

[NeilBrown]

On Wed, 6 Nov 2013 15:22:36 -0500 Chris Mason 
wrote:


> > Yup - that should actually be safe for all the existing bio_clone() users
> > actually, I audited all of them - because normally you're not going to 
> > complete
> > the original bio until the clone finishes.
> 
> I'd say we need an ack from Neil before we can switch to _fast.  The
> completions look non-trivial and _fast adds new ordering requirements on
> free.

I think it should be fairly straight forward to use _fast in md.
As Kent says, the original bio that is cloned is (almost) never going to have
endio called until all the clones have done their thing and finished up.

The only exception is the "behind_pages" stuff in raid1.c.  We clearly need
to be more careful there.
If the  "ordering requirements" you mention are simply that the owner of the
original may free the biovec, so the clone must have finished using it before
that can happen, then that would most easily be fix with
   mbio->bi_io_vec = r1_bio->behind_bvecs;
rather than the current loop which copies all the bv_page pointers.

NeilBrown



signature.asc
Description: PGP signature

Re: [PATCH 1/1] cpufreq: cpufreq-cpu0: use the max voltage instead of voltage-tolerance

[Shawn Guo]

On Thu, Nov 07, 2013 at 03:32:09AM +, Rongjun Ying wrote:
> I think my patch is better.

Well, unfortunately your patch is plainly wrong, because there are
in-tree users of voltage-tolerance right now.  How can you simply remove
it from driver with ignoring these users?

$ git grep voltage-tolerance arch/arm/boot/dts
arch/arm/boot/dts/am33xx.dtsi:  voltage-tolerance = <2>; /* 2 
percentage */
arch/arm/boot/dts/imx27.dtsi:   voltage-tolerance = <5>;
arch/arm/boot/dts/r8a73a4-ape6evm-reference.dts:voltage-tolerance = 
<1>; /* 1% */
arch/arm/boot/dts/r8a73a4-ape6evm.dts:  voltage-tolerance = <1>; /* 1% */
arch/arm/boot/dts/sh73a0-kzm9g-reference.dts:   
voltage-tolerance = <1>; /* 1% */

Shawn

> All soc have a max work voltage. If regulator IC can't supply min voltage, 
> It can supply max voltage to soc.
> As my patch, not need overwrite OPP in .dts.
> As your comment above, almost all board need overwrite OPP, unless the 
> regulator 
> IC can supply all voltage ranges of SoC need.

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

Re: [PATCH v4] binfmt_elf.c: use get_random_int() to fix entropy depleting

[Andrew Morton]

On Thu, 07 Nov 2013 12:14:17 +0800 Jeff Liu  wrote:

> Hi Stephan,
> 
> As per your previous comments for this fix, you have promised another 
> approach which
> is promising to avoid entropy starvation, I got this info from the following 
> thread:
> [PATCH] avoid entropy starvation due to stack protection
> https://lkml.org/lkml/2012/12/14/267
> 
> My current fix has been merged into Andrew's tree(marked in "stuck" state) 
> for a long
> time, and it also works well in our internal specific kernel, I'd like to 
> know if there
> is any update from you, so that we can move it along for mainline. :)


This:


From: Jeff Liu 
Subject: binfmt_elf.c: use get_random_int() to fix entropy depleting

Entropy is quickly depleted under normal operations like ls(1), cat(1),
etc...  between 2.6.30 to current mainline, for instance:

$ cat /proc/sys/kernel/random/entropy_avail
3428
$ cat /proc/sys/kernel/random/entropy_avail
2911
$cat /proc/sys/kernel/random/entropy_avail
2620

We observed this problem has been occurring since 2.6.30 with
fs/binfmt_elf.c: create_elf_tables()->get_random_bytes(), introduced by
f06295b44c296c8f ("ELF: implement AT_RANDOM for glibc PRNG seeding").

/*
 * Generate 16 random bytes for userspace PRNG seeding.
 */
get_random_bytes(k_rand_bytes, sizeof(k_rand_bytes));

The patch introduces a wrapper around get_random_int() which has lower
overhead than calling get_random_bytes() directly.

With this patch applied:
$ cat /proc/sys/kernel/random/entropy_avail
2731
$ cat /proc/sys/kernel/random/entropy_avail
2802
$ cat /proc/sys/kernel/random/entropy_avail
2878

Analyzed by John Sobecki.

This has been applied on a specific Oracle kernel and has been running on
the customer's production environment (the original bug reporter) for
several months; it has worked fine until now.

Signed-off-by: Jie Liu 
Cc: Al Viro 
Cc: Andreas Dilger 
Cc: Alan Cox 
Cc: Arnd Bergmann 
Cc: John Sobecki 
Cc: James Morris 
Cc: Jakub Jelinek 
Cc: Ted Ts'o 
Cc: Greg Kroah-Hartman 
Acked-by: Kees Cook 
Cc: Ulrich Drepper 
Signed-off-by: Andrew Morton 
---

 fs/binfmt_elf.c |   21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff -puN 
fs/binfmt_elf.c~binfmt_elfc-use-get_random_int-to-fix-entropy-depleting 
fs/binfmt_elf.c
--- a/fs/binfmt_elf.c~binfmt_elfc-use-get_random_int-to-fix-entropy-depleting
+++ a/fs/binfmt_elf.c
@@ -140,6 +140,25 @@ static int padzero(unsigned long elf_bss
 #define ELF_BASE_PLATFORM NULL
 #endif
 
+/*
+ * Use get_random_int() to implement AT_RANDOM while avoiding depletion
+ * of the entropy pool.
+ */
+static void get_atrandom_bytes(unsigned char *buf, size_t nbytes)
+{
+   unsigned char *p = buf;
+
+   while (nbytes) {
+   unsigned int random_variable;
+   size_t chunk = min(nbytes, sizeof(random_variable));
+
+   random_variable = get_random_int();
+   memcpy(p, _variable, chunk);
+   p += chunk;
+   nbytes -= chunk;
+   }
+}
+
 static int
 create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
unsigned long load_addr, unsigned long interp_load_addr)
@@ -201,7 +220,7 @@ create_elf_tables(struct linux_binprm *b
/*
 * Generate 16 random bytes for userspace PRNG seeding.
 */
-   get_random_bytes(k_rand_bytes, sizeof(k_rand_bytes));
+   get_atrandom_bytes(k_rand_bytes, sizeof(k_rand_bytes));
u_rand_bytes = (elf_addr_t __user *)
   STACK_ALLOC(p, sizeof(k_rand_bytes));
if (__copy_to_user(u_rand_bytes, k_rand_bytes, sizeof(k_rand_bytes)))
_

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Kbuild: Ignore GREP_OPTIONS env variable

[Michal Marek]

Dne 30.10.2013 17:06, Borislav Petkov napsal(a):
> So I had defined GREP_OPTIONS=--color=always on one of my boxes and had
> forgotten about it and the kernel build started failing because we use
> grep quite a while in the tree and it started issuing shell color markup
> which generated garbage files, like the syscall headers on x86, for
> example.
> 
> I have a fix below which seems to take care of it but what is the
> general opinion: Do we want to be more robust against the environment we
> find on a machine before building the kernel or let the user figure it
> out himself that he should be using
> 
> GREP_OPTIONS=--color=auto
> 
> in the first place and it is his own moronic fault if he does 'always'?

I think that on a scale from one to ten, building with
GREP_OPTIONS=--color=always and building with LC_COLLATE= score about the same. And are already
sanitizing the LC_* variables.


> +GREP_OPTIONS=
> +export GREP_OPTIONS

Just remove it from the enviromnet completely, like the next statement does:

> +
>  # Avoid funny character set dependencies
>  unexport LC_ALL
>  LC_COLLATE=C

Michal

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] net: x86: bpf: don't forget to free sk_filter (v2)

[Andrey Vagin]

sk_filter isn't freed if bpf_func is equal to sk_run_filter.

This memory leak was introduced by v3.12-rc3-224-gd45ed4a4
"net: fix unsafe set_memory_rw from softirq".

Before this patch sk_filter was freed in sk_filter_release_rcu,
now it should be freed in bpf_jit_free.

Here is output of kmemleak:
unreferenced object 0x8800b774eab0 (size 128):
  comm "systemd", pid 1, jiffies 4294669014 (age 124.062s)
  hex dump (first 32 bytes):
00 00 00 00 0b 00 00 00 20 63 7f b7 00 88 ff ff   c..
60 d4 55 81 ff ff ff ff 30 d9 55 81 ff ff ff ff  `.U.0.U.
  backtrace:
[] kmemleak_alloc+0x4e/0xb0
[] __kmalloc+0xef/0x260
[] sock_kmalloc+0x38/0x60
[] sk_attach_filter+0x5d/0x190
[] sock_setsockopt+0x991/0x9e0
[] SyS_setsockopt+0xb6/0xd0
[] system_call_fastpath+0x16/0x1b
[] 0x

v2: add extra { } after else

Fixes: d45ed4a4e33a ("net: fix unsafe set_memory_rw from softirq")
Acked-by: Daniel Borkmann 
Cc: Alexei Starovoitov 
Cc: Eric Dumazet 
Cc: "David S. Miller" 
Signed-off-by: Andrey Vagin 
---
 arch/x86/net/bpf_jit_comp.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index 516593e..26328e8 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -788,5 +788,7 @@ void bpf_jit_free(struct sk_filter *fp)
if (fp->bpf_func != sk_run_filter) {
INIT_WORK(>work, bpf_jit_free_deferred);
schedule_work(>work);
+   } else {
+   kfree(fp);
}
 }
-- 
1.8.3.1

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

Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?

[Greg KH]

On Mon, Nov 04, 2013 at 07:25:40AM +0100, Ingo Molnar wrote:
> 
> * Linus Torvalds  wrote:
> 
> > So I may be pessimistic, but I'd expect many developers would go "Let's 
> > hunt bugs.. Wait. Oooh, shiny" and go off doing some new feature after 
> > all instead. Or just take that release off.
> > 
> > But I do wonder.. Maybe it would be possible, and I'm just unfairly 
> > projecting my own inner squirrel onto other kernel developers. If we 
> > have enough heads-up that people *know* that for one release (and 
> > companies/managers know that too) the only patches that get accepted are 
> > the kind that fix bugs, maybe people really would have sufficient 
> > attention span that it could work.
> > 
> > And the reason I mention "4.0" is that it would be a lovely time to do 
> > that. Roughly a years heads-up that "ok, after 3.19 (or whatever), we're 
> > doing a release with *just* fixes, and then that becomes 4.0".
> > 
> > Comments?
> 
> I think the biggest problem wouldn't even be the enforcement of 
> bugfixes-only during that 2.5 months period, or kernel developers 
> surviving such a long streak of boredom, but v3.19 would also probably be 
> a super-stressful release to maintainers, as everyone would try to cram 
> their feature in there. And if anything important misses that window then 
> it's a +5 months wait...

I second this statement.  The presure that people will be trying to cram
stuff into the "bugfix-only-release" - 1 will be huge, I see it today
when people are trying to guess as to what the next longterm-stable
kernel is going to be and they throw thing in that are half-baked just
because they know then can "fix it up" later with "bugfixes".

Maintainers have a hard enough time handling patches from developers,
trying to sift them into a "bugfix for this release" and "new
feature/option for next release" bucket, all the time having to educate
the developers that the merge window is for the maintainers, it does not
mean it is time for developers to send new subsystems / drivers /
features in after a 3.x-final release is done by you and expect it to
get reviewed and merged before 3.x-rc1 comes out.

> Bugs that go on longer are usually the bugs developers cannot reproduce, 
> the ones where the timing and progress depends on other, external people. 
> For example the NUMA fixes in v3.12 took a couple of full cycles to pin 
> down fully. I think waiting another 2-3 months will mostly bring idle time 
> and diminishing returns of the long, exponentially decaying tail of 
> bugfixes, IMHO.
> 
> Thirdly, _users_ interested in stability can already go to the -stable 
> kernel, will will suck up 1 cycle worth of bugfixes out of the main flow 
> of changes. So users already have a stability choice of v-latest and 
> 'v-latest - 1' - plus the 'long term' stable kernels as well.

I think (but I'm probably biased here), that the -stable releases are
doing this pretty well.  The fact that we had 4,000 bugfixes added to
the 3.0-stable kernel is a testament to the fact that developers and
users are paying more attention to the stable kernel releases, and are
asking for things to be included there that they hadn't been before.
It's taken 8 years to educate people about this process, and still,
maintainers don't do this today, as was evident in my kernel summit talk
about the stable tree.  I think pushing those maintainers to start
tagging things for stable releases will benefit everyone much more than
having a "bugfix only" release.

> So ... unless you think our current stabilization flow is unhealthy and/or 
> you'd like to perform a natural experiment to measure it, why not just do 
> what worked so well for v3.0 and afterwards? Keep the existing process in 
> place, don't upset it just due to a (comparably) silly number tweak.

I agree.

> Maybe ask first-hop maintainers to be extra super diligent about new 
> features in v4.0 by imposing an internal merge window deadline 2 weeks 
> before the real merge window [a fair chunk of patches hit maintainer trees 
> in the last 2 weeks of the development window, and those cause much of the 
> regressions], maybe even reject a few pulls during the merge window that 
> blatantly violate these pre-freeze rules, but don't hold up the 
> low-latency flow of steady improvements - much of which is driver work, 
> platform enablement work, small improvements, etc., which isn't really a 
> big source of real regressions for the existing installed base.

A 2 week merge window deadline would help out a lot with a number of
some of the bugs we get during the -rc cycle, but there's always going
to be issues found with wider testing, so I'm not quite sure that will
help out all that much in the end.

Anyway, I think this might be tougher than expected, and put more work
on the maintainers who are going to have to queue up stuff for 3 extra
months in their trees, because it's not like things are just going to
not come in to us because Linus isn't taking them at the 

Re: kernel BUG at kernel/kallsyms.c:222!

[Ming Lei]

Hi,

On Thu, Nov 7, 2013 at 10:47 AM, Axel Lin  wrote:
>
> hi Ming,
> Seems CONFIG_PAGE_OFFSET is not configurabe in "make menuconfig".
> And I found CONFIG_PAGE_OFFSET=0xC000 for all below configs...
> $ make at91_dt_defconfig; grep  CONFIG_PAGE_OFFSET .config
> $ make ep93xx_defconfig; grep  CONFIG_PAGE_OFFSET .config
> $ make imx_v4_v5_defconfig; grep CONFIG_PAGE_OFFSET .config
> $ make mxs_defconfig; grep CONFIG_PAGE_OFFSET .config
> $ make omap2plus_defconfig; grep CONFIG_PAGE_OFFSET .config
> $ make s3c6400_defconfig; grep CONFIG_PAGE_OFFSET .config
> $ make at91x40_defconfig; grep CONFIG_PAGE_OFFSET .config
> ( at91x40_defconfig is also arm7tdmi )

Firstly it can be configured via VMSPLIT_3GVMSPLIT_2G/VMSPLIT_1G.

Secondly, configurable or not isn't the point, and maybe some uclinux
platforms do not use CONFIG_PAGE_OFFSET at all, but they should
set it as a reasonable value or at least be below than the start link
address of vmlinux.


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

Re: CONFIG_NO_HZ_FULL + CONFIG_PREEMPT_RT_FULL = nogo

[Mike Galbraith]

On Thu, 2013-11-07 at 04:26 +0100, Mike Galbraith wrote: 
> On Wed, 2013-11-06 at 18:49 +0100, Thomas Gleixner wrote: 

> > I bet you are trying to work around some of the side effects of the
> > occasional tick which is still necessary despite of full nohz, right?
> 
> Nope, I wanted to check out cost of nohz_full for rt, and found that it
> doesn't work at all instead, looked, and found that the sole running
> task has just awakened ksoftirqd when it wants to shut the tick down, so
> that shutdown never happens. 

Like so in virgin 3.10-rt.  Box is x3550 M3 booted nowatchdog
rcu_nocbs=1-3 nohz_full=1-3, and CPUs1-3 are completely isolated via
cpusets as well.

... 
pert-5229  [003] d..h2..   684.481615: hrtimer_cancel: 
hrtimer=88017fccbac0
pert-5229  [003] d..h1..   684.481616: hrtimer_expire_entry: 
hrtimer=88017fccbac0 function=tick_sched_timer now=683820187877
pert-5229  [003] d..h2..   684.481616: sched_stat_runtime: 
comm=pert pid=5229 runtime=993917 [ns] vruntime=179048871558 [ns]
pert-5229  [003] d..h1..   684.481616: softirq_raise: vec=1 
[action=TIMER]
pert-5229  [003] d..h1..   684.481616: hrtimer_expire_exit: 
hrtimer=88017fccbac0
pert-5229  [003] d..h2..   684.481617: hrtimer_start: 
hrtimer=88017fccbac0 function=tick_sched_timer expires=683821187500 
softexpires=683821187500
pert-5229  [003] d...3..   684.481618: sched_stat_runtime: 
comm=pert pid=5229 runtime=1634 [ns] vruntime=179048873192 [ns]
pert-5229  [003] d.L.3..   684.481618: sched_wakeup: 
comm=ksoftirqd/3 pid=49 prio=120 success=1 target_cpu=003
pert-5229  [003] d.L.1..   684.481618: tick_stop: success=no 
msg=more than 1 task in runqueue

pert-5229  [003] d.L.1..   684.481619: tick_stop: success=no 
msg=more than 1 task in runqueue

pert-5229  [003] d.L.3..   684.481620: sched_stat_runtime: 
comm=pert pid=5229 runtime=2096 [ns] vruntime=179048875288 [ns]
pert-5229  [003] d...3..   684.481620: sched_switch: prev_comm=pert 
prev_pid=5229 prev_prio=120 prev_state=R+ ==> next_comm=ksoftirqd/3 next_pid=49 
next_prio=120
 ksoftirqd/3-49[003] 111   684.481621: softirq_entry: vec=1 
[action=TIMER]
 ksoftirqd/3-49[003] 111   684.481621: softirq_exit: vec=1 
[action=TIMER]
 ksoftirqd/3-49[003] d...3..   684.481622: sched_stat_runtime: 
comm=ksoftirqd/3 pid=49 runtime=1934 [ns] vruntime=179039875126 [ns]
 ksoftirqd/3-49[003] d...3..   684.481622: sched_switch: 
prev_comm=ksoftirqd/3 prev_pid=49 prev_prio=120 prev_state=S ==> next_comm=pert 
next_pid=5229 next_prio=120
pert-5229  [003] d...3..   684.481623: sched_stat_runtime: 
comm=pert pid=5229 runtime=1289 [ns] vruntime=179048876577 [ns]
pert-5229  [003] d..h2..   684.482616: hrtimer_cancel: 
hrtimer=88017fccbac0
pert-5229  [003] d..h1..   684.482617: hrtimer_expire_entry: 
hrtimer=88017fccbac0 function=tick_sched_timer now=683821188024
pert-5229  [003] d..h2..   684.482617: sched_stat_runtime: 
comm=pert pid=5229 runtime=994281 [ns] vruntime=179049870858 [ns]
pert-5229  [003] d..h1..   684.482617: softirq_raise: vec=1 
[action=TIMER]
pert-5229  [003] d..h1..   684.482618: softirq_raise: vec=9 
[action=RCU]
pert-5229  [003] d..h1..   684.482618: hrtimer_expire_exit: 
hrtimer=88017fccbac0
pert-5229  [003] d..h2..   684.482618: hrtimer_start: 
hrtimer=88017fccbac0 function=tick_sched_timer expires=683822187500 
softexpires=683822187500
pert-5229  [003] d...3..   684.482619: sched_stat_runtime: 
comm=pert pid=5229 runtime=1719 [ns] vruntime=179049872577 [ns]
pert-5229  [003] d.L.3..   684.482619: sched_wakeup: 
comm=ksoftirqd/3 pid=49 prio=120 success=1 target_cpu=003
pert-5229  [003] d.L.1..   684.482619: tick_stop: success=no 
msg=more than 1 task in runqueue

pert-5229  [003] d.L.1..   684.482620: tick_stop: success=no 
msg=more than 1 task in runqueue

pert-5229  [003] d.L.3..   684.482621: sched_stat_runtime: 
comm=pert pid=5229 runtime=2204 [ns] vruntime=179049874781 [ns]
pert-5229  [003] d...3..   684.482621: sched_switch: prev_comm=pert 
prev_pid=5229 prev_prio=120 prev_state=R+ ==> next_comm=ksoftirqd/3 next_pid=49 
next_prio=120
 ksoftirqd/3-49[003] 111   684.482622: softirq_entry: vec=1 
[action=TIMER]
 ksoftirqd/3-49[003] 111   684.482623: softirq_exit: vec=1 
[action=TIMER]
 ksoftirqd/3-49[003] 111   684.482623: softirq_entry: vec=9 
[action=RCU]
 ksoftirqd/3-49[003] 111   684.482624: softirq_exit: vec=9 
[action=RCU]
 ksoftirqd/3-49[003] d...3..   684.482624: sched_stat_runtime: 
comm=ksoftirqd/3 pid=49 runtime=3049 [ns] vruntime=179040875626 [ns]
 ksoftirqd/3-49[003] d...3..   684.482624: sched_switch: 
prev_comm=ksoftirqd/3 

Re: [PATCH 3/3] kbuild, bloat-o-meter: fix static detection

[Michal Marek]

On Tue, Oct 22, 2013 at 08:46:23AM -0700, Andi Kleen wrote:
> From: Andi Kleen 
> 
> Disable static detection: the static currently drops a lot of useful 
> information
> including clones generated by gcc. Drop this. The statics will appear now
> without static. prefix.
> 
> But remove the LTO .NUMBER postfixes that look ugly
> 
> Signed-off-by: Andi Kleen 

Applied to kbuild.git#kbuild.

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

Re: [PATCH 2/3] Kbuild: Handle longer symbols in kallsyms.c v2

[Michal Marek]

On Wed, Oct 23, 2013 at 03:07:53PM +0200, Andi Kleen wrote:
> 
> Also warn for too long symbols
> 
> v2: Add missing newline. Use 255 max (Joe Perches)
> Signed-off-by: Andi Kleen 

Applied to kbuild.git#kbuild.

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 V7 5/7] POWER/cpuidle: Generic POWER CPUIDLE driver supporting PSERIES.

[Deepthi Dharwar]

On 11/07/2013 02:35 AM, Daniel Lezcano wrote:
> On 10/29/2013 12:01 PM, Deepthi Dharwar wrote:
>> This patch includes cleanup and refactoring of the
>> existing code to make the driver POWER generic.
>> * Re-naming the functions from pseries to generic power.
>> * Re-naming the backend driver from pseries_idle to
>>ibm-power-idle.
>>
>> Signed-off-by: Deepthi Dharwar 
> 
> Acked-by: Daniel Lezcano 

Hi Daniel,

Thanks for the Acks.

> ... but I am wondering if 'power' name is not confusing with power
> management and if 'powerpc' would suit better.

'powerpc' would be very generic arch and would comprise of all platforms
including embedded 32/64 bit to server 64 bit (similar to that of ARM).
This driver does not intend to support complete powerpc arch, but just
PSERIES and POWERNV platforms termed as 'POWER' processors. So to avoid
confusion btw 'power mgmt' and 'POWER' archs, I have prefixed both the
driver and file names with 'IBM'namely ibm-power-driver, cpuidle-ibm-power.

Regards,
Deepthi

>> ---
>>   drivers/cpuidle/cpuidle-ibm-power.c |   32
>> 
>>   1 file changed, 16 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/cpuidle/cpuidle-ibm-power.c
>> b/drivers/cpuidle/cpuidle-ibm-power.c
>> index e81c207..5b92242 100644
>> --- a/drivers/cpuidle/cpuidle-ibm-power.c
>> +++ b/drivers/cpuidle/cpuidle-ibm-power.c
>> @@ -20,8 +20,8 @@
>>   #include 
>>   #include 
>>
>> -struct cpuidle_driver pseries_idle_driver = {
>> -.name = "pseries_idle",
>> +struct cpuidle_driver power_idle_driver = {
>> +.name = "ibm_power_idle",
>>   .owner= THIS_MODULE,
>>   };
>>
>> @@ -182,7 +182,7 @@ void update_smt_snooze_delay(int cpu, int residency)
>>   drv->states[1].target_residency = residency;
>>   }
>>
>> -static int pseries_cpuidle_add_cpu_notifier(struct notifier_block *n,
>> +static int power_cpuidle_add_cpu_notifier(struct notifier_block *n,
>>   unsigned long action, void *hcpu)
>>   {
>>   int hotcpu = (unsigned long)hcpu;
>> @@ -213,16 +213,16 @@ static int
>> pseries_cpuidle_add_cpu_notifier(struct notifier_block *n,
>>   }
>>
>>   static struct notifier_block setup_hotplug_notifier = {
>> -.notifier_call = pseries_cpuidle_add_cpu_notifier,
>> +.notifier_call = power_cpuidle_add_cpu_notifier,
>>   };
>>
>>   /*
>> - * pseries_cpuidle_driver_init()
>> + * power_cpuidle_driver_init()
>>*/
>> -static int pseries_cpuidle_driver_init(void)
>> +static int power_cpuidle_driver_init(void)
>>   {
>>   int idle_state;
>> -struct cpuidle_driver *drv = _idle_driver;
>> +struct cpuidle_driver *drv = _idle_driver;
>>
>>   drv->state_count = 0;
>>   for (idle_state = 0; idle_state < max_idle_state; ++idle_state) {
>> @@ -241,10 +241,10 @@ static int pseries_cpuidle_driver_init(void)
>>   }
>>
>>   /*
>> - * pseries_idle_probe()
>> + * power_idle_probe()
>>* Choose state table for shared versus dedicated partition
>>*/
>> -static int pseries_idle_probe(void)
>> +static int power_idle_probe(void)
>>   {
>>
>>   if (cpuidle_disable != IDLE_NO_OVERRIDE)
>> @@ -264,24 +264,24 @@ static int pseries_idle_probe(void)
>>   return 0;
>>   }
>>
>> -static int __init pseries_processor_idle_init(void)
>> +static int __init power_processor_idle_init(void)
>>   {
>>   int retval;
>>
>> -retval = pseries_idle_probe();
>> +retval = power_idle_probe();
>>   if (retval)
>>   return retval;
>>
>> -pseries_cpuidle_driver_init();
>> -retval = cpuidle_register(_idle_driver, NULL);
>> +power_cpuidle_driver_init();
>> +retval = cpuidle_register(_idle_driver, NULL);
>>   if (retval) {
>> -printk(KERN_DEBUG "Registration of pseries driver failed.\n");
>> +printk(KERN_DEBUG "Registration of ibm_power_idle driver
>> failed.\n");
>>   return retval;
>>   }
>>
>>   register_cpu_notifier(_hotplug_notifier);
>> -printk(KERN_DEBUG "pseries_idle_driver registered\n");
>> +printk(KERN_DEBUG "ibm_power_idle registered\n");
>>   return 0;
>>   }
>>
>> -device_initcall(pseries_processor_idle_init);
>> +device_initcall(power_processor_idle_init);
>>
> 
> 

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

Xen PV ABI on FPU doesn't match with pvops kernel FPU code, reducing to a serious memory data damage

[Zhu Yanhai]

Hi guys,
The PV ABI of xen will clear CR0.TS before trapping into the PV guest
kernel's exception handler, so the exception handler in guest kernel
runs with CR0.TS clear at the very beginning (which is different with
on baremetal). In Xenolinux and mainline Linux kernel before 2.6.26
everything is fine since they don't sleep nor enable interrupts during
the handler, however the current mainline pvops kernel has a schedule
window opened within it.

[Pls see the code below,

void math_state_restore(void)
{
struct task_struct *tsk = current;

if (!tsk_used_math(tsk)) {
local_irq_enable();    Here it might
open a schedule window
/*
 * does a slab alloc which can sleep
 */
if (init_fpu(tsk)) {
/*
 * ran out of memory!
 */
do_group_exit(SIGKILL);
return;
}
local_irq_disable();   Here it closes
}

__thread_fpu_begin(tsk);

/*
 * Paranoid restore. send a SIGSEGV if we fail to restore the state.
 */
if (unlikely(restore_fpu_checking(tsk))) {
drop_init_fpu(tsk);
force_sig(SIGSEGV, tsk);
return;
}

tsk->fpu_counter++;
}
]

This can cause serious data damage against xen pv guests (including
dom0 kernel), we have encountered this issue both in stress test and
production systems. Please take a look at
http://comments.gmane.org/gmane.comp.emulators.xen.devel/176970 for
more discussions and test cases.

Ian and George, we have confirmed this is the very root cause of
http://comments.gmane.org/gmane.comp.emulators.xen.devel/175491

The xen ABI is part of history which can't be changed, as well as
simply adding a couple of stts()-clts() around the enabling/disabling
interrupts is a really ugly hack.
Maintainers, any thoughts?

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

Re: [PATCH v4] binfmt_elf.c: use get_random_int() to fix entropy depleting

[Jeff Liu]

Hi Stephan,

As per your previous comments for this fix, you have promised another approach 
which
is promising to avoid entropy starvation, I got this info from the following 
thread:
[PATCH] avoid entropy starvation due to stack protection
https://lkml.org/lkml/2012/12/14/267

My current fix has been merged into Andrew's tree(marked in "stuck" state) for 
a long
time, and it also works well in our internal specific kernel, I'd like to know 
if there
is any update from you, so that we can move it along for mainline. :)

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

[for-next][PATCH 2/5] tracing: Add helper function tracing_is_disabled()

[Steven Rostedt]

From: "Geyslan G. Bem" 

This patch creates the function 'tracing_is_disabled', which
can be used outside of trace.c.

Link: 
http://lkml.kernel.org/r/1382141754-12155-1-git-send-email-geys...@gmail.com

Signed-off-by: Geyslan G. Bem 
Signed-off-by: Steven Rostedt 
---
 kernel/trace/trace.c | 5 +
 kernel/trace/trace.h | 1 +
 2 files changed, 6 insertions(+)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index eaacd3a..2a595cf 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -2987,6 +2987,11 @@ int tracing_open_generic(struct inode *inode, struct 
file *filp)
return 0;
 }
 
+bool tracing_is_disabled(void)
+{
+   return (tracing_disabled) ? true: false;
+}
+
 /*
  * Open and update trace_array ref count.
  * Must have the current trace_array passed to it.
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 9c27cda..4388e16 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -514,6 +514,7 @@ void tracing_reset_online_cpus(struct trace_buffer *buf);
 void tracing_reset_current(int cpu);
 void tracing_reset_all_online_cpus(void);
 int tracing_open_generic(struct inode *inode, struct file *filp);
+bool tracing_is_disabled(void);
 struct dentry *trace_create_file(const char *name,
 umode_t mode,
 struct dentry *parent,
-- 
1.8.4.rc3


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arch: alpha: uapi: be sure of "_UAPI" prefix for all guard macros

[Chen Gang]

For all uapi headers, need use "_UAPI" prefix for its guard macro
(which will be stripped by "scripts/headers_installler.sh").

Also delete the redundant files (ipcbuf.h, kvm_para.h, and poll.h)
which are already in Kbuild.


Signed-off-by: Chen Gang 
---
 arch/alpha/include/uapi/asm/auxvec.h  |6 +++---
 arch/alpha/include/uapi/asm/bitsperlong.h |6 +++---
 arch/alpha/include/uapi/asm/byteorder.h   |6 +++---
 arch/alpha/include/uapi/asm/errno.h   |6 +++---
 arch/alpha/include/uapi/asm/fcntl.h   |6 +++---
 arch/alpha/include/uapi/asm/gentrap.h |6 +++---
 arch/alpha/include/uapi/asm/ioctl.h   |6 +++---
 arch/alpha/include/uapi/asm/ioctls.h  |6 +++---
 arch/alpha/include/uapi/asm/ipcbuf.h  |1 -
 arch/alpha/include/uapi/asm/kvm_para.h|1 -
 arch/alpha/include/uapi/asm/mman.h|6 +++---
 arch/alpha/include/uapi/asm/msgbuf.h  |6 +++---
 arch/alpha/include/uapi/asm/poll.h|1 -
 arch/alpha/include/uapi/asm/posix_types.h |6 +++---
 arch/alpha/include/uapi/asm/reg.h |6 +++---
 arch/alpha/include/uapi/asm/regdef.h  |6 +++---
 arch/alpha/include/uapi/asm/resource.h|6 +++---
 arch/alpha/include/uapi/asm/sembuf.h  |6 +++---
 arch/alpha/include/uapi/asm/setup.h   |6 +++---
 arch/alpha/include/uapi/asm/shmbuf.h  |6 +++---
 arch/alpha/include/uapi/asm/sigcontext.h  |6 +++---
 arch/alpha/include/uapi/asm/siginfo.h |6 +++---
 arch/alpha/include/uapi/asm/sockios.h |6 +++---
 arch/alpha/include/uapi/asm/stat.h|6 +++---
 arch/alpha/include/uapi/asm/statfs.h  |6 +++---
 arch/alpha/include/uapi/asm/swab.h|6 +++---
 arch/alpha/include/uapi/asm/sysinfo.h |6 +++---
 arch/alpha/include/uapi/asm/termbits.h|6 +++---
 28 files changed, 75 insertions(+), 78 deletions(-)
 delete mode 100644 arch/alpha/include/uapi/asm/ipcbuf.h
 delete mode 100644 arch/alpha/include/uapi/asm/kvm_para.h
 delete mode 100644 arch/alpha/include/uapi/asm/poll.h

diff --git a/arch/alpha/include/uapi/asm/auxvec.h 
b/arch/alpha/include/uapi/asm/auxvec.h
index a3a579d..d297271 100644
--- a/arch/alpha/include/uapi/asm/auxvec.h
+++ b/arch/alpha/include/uapi/asm/auxvec.h
@@ -1,5 +1,5 @@
-#ifndef __ASM_ALPHA_AUXVEC_H
-#define __ASM_ALPHA_AUXVEC_H
+#ifndef _UAPI__ASM_ALPHA_AUXVEC_H
+#define _UAPI__ASM_ALPHA_AUXVEC_H
 
 /* Reserve these numbers for any future use of a VDSO.  */
 #if 0
@@ -23,4 +23,4 @@
 
 #define AT_VECTOR_SIZE_ARCH 4 /* entries in ARCH_DLINFO */
 
-#endif /* __ASM_ALPHA_AUXVEC_H */
+#endif /* _UAPI__ASM_ALPHA_AUXVEC_H */
diff --git a/arch/alpha/include/uapi/asm/bitsperlong.h 
b/arch/alpha/include/uapi/asm/bitsperlong.h
index ad57f78..c3d1159 100644
--- a/arch/alpha/include/uapi/asm/bitsperlong.h
+++ b/arch/alpha/include/uapi/asm/bitsperlong.h
@@ -1,8 +1,8 @@
-#ifndef __ASM_ALPHA_BITSPERLONG_H
-#define __ASM_ALPHA_BITSPERLONG_H
+#ifndef _UAPI__ASM_ALPHA_BITSPERLONG_H
+#define _UAPI__ASM_ALPHA_BITSPERLONG_H
 
 #define __BITS_PER_LONG 64
 
 #include 
 
-#endif /* __ASM_ALPHA_BITSPERLONG_H */
+#endif /* _UAPI__ASM_ALPHA_BITSPERLONG_H */
diff --git a/arch/alpha/include/uapi/asm/byteorder.h 
b/arch/alpha/include/uapi/asm/byteorder.h
index 7368309..331ca69 100644
--- a/arch/alpha/include/uapi/asm/byteorder.h
+++ b/arch/alpha/include/uapi/asm/byteorder.h
@@ -1,6 +1,6 @@
-#ifndef _ALPHA_BYTEORDER_H
-#define _ALPHA_BYTEORDER_H
+#ifndef _UAPI_ALPHA_BYTEORDER_H
+#define _UAPI_ALPHA_BYTEORDER_H
 
 #include 
 
-#endif /* _ALPHA_BYTEORDER_H */
+#endif /* _UAPI_ALPHA_BYTEORDER_H */
diff --git a/arch/alpha/include/uapi/asm/errno.h 
b/arch/alpha/include/uapi/asm/errno.h
index 17f92aa..656023c 100644
--- a/arch/alpha/include/uapi/asm/errno.h
+++ b/arch/alpha/include/uapi/asm/errno.h
@@ -1,5 +1,5 @@
-#ifndef _ALPHA_ERRNO_H
-#define _ALPHA_ERRNO_H
+#ifndef _UAPI_ALPHA_ERRNO_H
+#define _UAPI_ALPHA_ERRNO_H
 
 #include 
 
@@ -124,4 +124,4 @@
 
 #define EHWPOISON  139 /* Memory page has hardware error */
 
-#endif
+#endif /* _UAPI_ALPHA_ERRNO_H */
diff --git a/arch/alpha/include/uapi/asm/fcntl.h 
b/arch/alpha/include/uapi/asm/fcntl.h
index 09f49a6..46bd65a 100644
--- a/arch/alpha/include/uapi/asm/fcntl.h
+++ b/arch/alpha/include/uapi/asm/fcntl.h
@@ -1,5 +1,5 @@
-#ifndef _ALPHA_FCNTL_H
-#define _ALPHA_FCNTL_H
+#ifndef _UAPI_ALPHA_FCNTL_H
+#define _UAPI_ALPHA_FCNTL_H
 
 #define O_CREAT 01000  /* not fcntl */
 #define O_TRUNC 02000  /* not fcntl */
@@ -54,4 +54,4 @@
 
 #include 
 
-#endif
+#endif /* _UAPI_ALPHA_FCNTL_H */
diff --git a/arch/alpha/include/uapi/asm/gentrap.h 
b/arch/alpha/include/uapi/asm/gentrap.h
index ae50cc3..8c40e37 100644
--- a/arch/alpha/include/uapi/asm/gentrap.h
+++ b/arch/alpha/include/uapi/asm/gentrap.h
@@ -1,5 +1,5 @@
-#ifndef _ASMAXP_GENTRAP_H
-#define _ASMAXP_GENTRAP_H
+#ifndef _UAPI_ASMAXP_GENTRAP_H
+#define _UAPI_ASMAXP_GENTRAP_H
 
 /*
  * Definitions for gentrap causes.  They are generated 

[for-next][PATCH 5/5] tracing: Do not use signed enums with unsigned long long in fgragh output

[Steven Rostedt]

From: "Steven Rostedt (Red Hat)" 

The duration field of print_graph_duration() can also be used
to do the space filling by passing an enum in it:

  DURATION_FILL_FULL
  DURATION_FILL_START
  DURATION_FILL_END

The problem is that these are enums and defined as negative,
but the duration field is unsigned long long. Most archs are
fine with this but blackfin fails to compile because of it:

kernel/built-in.o: In function `print_graph_duration':
kernel/trace/trace_functions_graph.c:782: undefined reference to `__ucmpdi2'

Overloading a unsigned long long with an signed enum is just
bad in principle. We can accomplish the same thing by using
part of the flags field instead.

Cc: Mike Frysinger 
Cc: Frederic Weisbecker 
Signed-off-by: Steven Rostedt 
---
 kernel/trace/trace.h |  2 ++
 kernel/trace/trace_functions_graph.c | 22 +++---
 2 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 4388e16..11a04d6 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -712,6 +712,8 @@ extern unsigned long trace_flags;
 #define TRACE_GRAPH_PRINT_PROC  0x8
 #define TRACE_GRAPH_PRINT_DURATION  0x10
 #define TRACE_GRAPH_PRINT_ABS_TIME  0x20
+#define TRACE_GRAPH_PRINT_FILL_SHIFT   28
+#define TRACE_GRAPH_PRINT_FILL_MASK(0x3 << TRACE_GRAPH_PRINT_FILL_SHIFT)
 
 extern enum print_line_t
 print_graph_function_flags(struct trace_iterator *iter, u32 flags);
diff --git a/kernel/trace/trace_functions_graph.c 
b/kernel/trace/trace_functions_graph.c
index 80387d1..0b99120 100644
--- a/kernel/trace/trace_functions_graph.c
+++ b/kernel/trace/trace_functions_graph.c
@@ -82,9 +82,9 @@ static struct trace_array *graph_array;
  * to fill in space into DURATION column.
  */
 enum {
-   DURATION_FILL_FULL  = -1,
-   DURATION_FILL_START = -2,
-   DURATION_FILL_END   = -3,
+   FLAGS_FILL_FULL  = 1 << TRACE_GRAPH_PRINT_FILL_SHIFT,
+   FLAGS_FILL_START = 2 << TRACE_GRAPH_PRINT_FILL_SHIFT,
+   FLAGS_FILL_END   = 3 << TRACE_GRAPH_PRINT_FILL_SHIFT,
 };
 
 static enum print_line_t
@@ -702,7 +702,7 @@ print_graph_irq(struct trace_iterator *iter, unsigned long 
addr,
}
 
/* No overhead */
-   ret = print_graph_duration(DURATION_FILL_START, s, flags);
+   ret = print_graph_duration(0, s, flags | FLAGS_FILL_START);
if (ret != TRACE_TYPE_HANDLED)
return ret;
 
@@ -714,7 +714,7 @@ print_graph_irq(struct trace_iterator *iter, unsigned long 
addr,
if (!ret)
return TRACE_TYPE_PARTIAL_LINE;
 
-   ret = print_graph_duration(DURATION_FILL_END, s, flags);
+   ret = print_graph_duration(0, s, flags | FLAGS_FILL_END);
if (ret != TRACE_TYPE_HANDLED)
return ret;
 
@@ -779,14 +779,14 @@ print_graph_duration(unsigned long long duration, struct 
trace_seq *s,
return TRACE_TYPE_HANDLED;
 
/* No real adata, just filling the column with spaces */
-   switch (duration) {
-   case DURATION_FILL_FULL:
+   switch (flags & TRACE_GRAPH_PRINT_FILL_MASK) {
+   case FLAGS_FILL_FULL:
ret = trace_seq_puts(s, "  |  ");
return ret ? TRACE_TYPE_HANDLED : TRACE_TYPE_PARTIAL_LINE;
-   case DURATION_FILL_START:
+   case FLAGS_FILL_START:
ret = trace_seq_puts(s, "  ");
return ret ? TRACE_TYPE_HANDLED : TRACE_TYPE_PARTIAL_LINE;
-   case DURATION_FILL_END:
+   case FLAGS_FILL_END:
ret = trace_seq_puts(s, " |");
return ret ? TRACE_TYPE_HANDLED : TRACE_TYPE_PARTIAL_LINE;
}
@@ -902,7 +902,7 @@ print_graph_entry_nested(struct trace_iterator *iter,
}
 
/* No time */
-   ret = print_graph_duration(DURATION_FILL_FULL, s, flags);
+   ret = print_graph_duration(0, s, flags | FLAGS_FILL_FULL);
if (ret != TRACE_TYPE_HANDLED)
return ret;
 
@@ -1222,7 +1222,7 @@ print_graph_comment(struct trace_seq *s, struct 
trace_entry *ent,
return TRACE_TYPE_PARTIAL_LINE;
 
/* No time */
-   ret = print_graph_duration(DURATION_FILL_FULL, s, flags);
+   ret = print_graph_duration(0, s, flags | FLAGS_FILL_FULL);
if (ret != TRACE_TYPE_HANDLED)
return ret;
 
-- 
1.8.4.rc3


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

[for-next][PATCH 4/5] tracing: Remove unused function ftrace_off_permanent()

[Steven Rostedt]

From: "Steven Rostedt (Red Hat)" 

In the past, ftrace_off_permanent() was called if something
strange was detected. But the ftrace_bug() now handles all the
anomolies that can happen with ftrace (function tracing), and there
are no uses of ftrace_off_permanent(). Get rid of it.

Signed-off-by: Steven Rostedt 
---
 include/linux/kernel.h |  2 --
 kernel/trace/trace.c   | 15 ---
 2 files changed, 17 deletions(-)

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 672ddc4..d4e98d1 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -501,7 +501,6 @@ void tracing_snapshot_alloc(void);
 
 extern void tracing_start(void);
 extern void tracing_stop(void);
-extern void ftrace_off_permanent(void);
 
 static inline __printf(1, 2)
 void trace_printk_check_format(const char *fmt, ...)
@@ -639,7 +638,6 @@ extern void ftrace_dump(enum ftrace_dump_mode 
oops_dump_mode);
 #else
 static inline void tracing_start(void) { }
 static inline void tracing_stop(void) { }
-static inline void ftrace_off_permanent(void) { }
 static inline void trace_dump_stack(int skip) { }
 
 static inline void tracing_on(void) { }
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 2a595cf..d72a15c 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -1284,21 +1284,6 @@ int is_tracing_stopped(void)
 }
 
 /**
- * ftrace_off_permanent - disable all ftrace code permanently
- *
- * This should only be called when a serious anomally has
- * been detected.  This will turn off the function tracing,
- * ring buffers, and other tracing utilites. It takes no
- * locks and can be called from any context.
- */
-void ftrace_off_permanent(void)
-{
-   tracing_disabled = 1;
-   ftrace_stop();
-   tracing_off_permanent();
-}
-
-/**
  * tracing_start - quick start of the tracer
  *
  * If tracing is enabled but was stopped by tracing_stop,
-- 
1.8.4.rc3


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

[for-next][PATCH 3/5] tracing: Do not assign filp->private_data to freed memory

[Steven Rostedt]

From: "Geyslan G. Bem" 

In system_tr_open(), the filp->private_data can be assigned the 'dir'
variable even if it was freed. This is on the error path, and is
harmless because the error return code will prevent filp->private_data
from being used. But for correctness, we should not assign it to
a recently freed variable, as that can cause static tools to give
false warnings.

Also have both subsystem_open() and system_tr_open() return -ENODEV
if tracing has been disabled.

Link: 
http://lkml.kernel.org/r/1383764571-7318-1-git-send-email-geys...@gmail.com

Signed-off-by: Geyslan G. Bem 
Signed-off-by: Steven Rostedt 
---
 kernel/trace/trace_events.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 043f833..f919a2e 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -1062,6 +1062,9 @@ static int subsystem_open(struct inode *inode, struct 
file *filp)
struct trace_array *tr;
int ret;
 
+   if (tracing_is_disabled())
+   return -ENODEV;
+
/* Make sure the system still exists */
mutex_lock(_types_lock);
mutex_lock(_mutex);
@@ -1108,6 +,9 @@ static int system_tr_open(struct inode *inode, struct 
file *filp)
struct trace_array *tr = inode->i_private;
int ret;
 
+   if (tracing_is_disabled())
+   return -ENODEV;
+
if (trace_array_get(tr) < 0)
return -ENODEV;
 
@@ -1124,11 +1130,12 @@ static int system_tr_open(struct inode *inode, struct 
file *filp)
if (ret < 0) {
trace_array_put(tr);
kfree(dir);
+   return ret;
}
 
filp->private_data = dir;
 
-   return ret;
+   return 0;
 }
 
 static int subsystem_release(struct inode *inode, struct file *file)
-- 
1.8.4.rc3


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

[for-next][PATCH 1/5] tracing: Open tracer when ftrace_dump_on_oops is used

[Steven Rostedt]

From: Cody P Schafer 

With ftrace_dump_on_oops, we previously did not open the tracer in
question, sometimes causing the trace output to be useless.

For example, the function_graph tracer with tracing_thresh set dumped via
ftrace_dump_on_oops would show a series of '}' indented at different levels,
but no function names.

call trace->open() (and do a few other fixups copied from the normal dump
path) to make the output more intelligible.

Link: 
http://lkml.kernel.org/r/1382554197-16961-1-git-send-email-c...@linux.vnet.ibm.com

Signed-off-by: Cody P Schafer 
Signed-off-by: Steven Rostedt 
---
 kernel/trace/trace.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index f9fa42b..eaacd3a 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -6276,6 +6276,17 @@ void trace_init_global_iter(struct trace_iterator *iter)
iter->trace = iter->tr->current_trace;
iter->cpu_file = RING_BUFFER_ALL_CPUS;
iter->trace_buffer = _trace.trace_buffer;
+
+   if (iter->trace && iter->trace->open)
+   iter->trace->open(iter);
+
+   /* Annotate start of buffers if we had overruns */
+   if (ring_buffer_overruns(iter->trace_buffer->buffer))
+   iter->iter_flags |= TRACE_FILE_ANNOTATE;
+
+   /* Output in nanoseconds only if we are using a clock in nanoseconds. */
+   if (trace_clocks[iter->tr->clock_id].in_ns)
+   iter->iter_flags |= TRACE_FILE_TIME_IN_NS;
 }
 
 void ftrace_dump(enum ftrace_dump_mode oops_dump_mode)
-- 
1.8.4.rc3


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

[for-next][PATCH 0/5] tracing: More updates for 3.13

[Steven Rostedt]

  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
for-next

Head SHA1: 20b72e76c42bc4f0dd091f9faee542ea45ad6b5e


Cody P Schafer (1):
  tracing: Open tracer when ftrace_dump_on_oops is used

Geyslan G. Bem (2):
  tracing: Add helper function tracing_is_disabled()
  tracing: Do not assign filp->private_data to freed memory

Steven Rostedt (1):
  Merge branch 'trace/ftrace/core' into trace/for-next

Steven Rostedt (Red Hat) (2):
  tracing: Remove unused function ftrace_off_permanent()
  tracing: Do not use signed enums with unsigned long long in fgragh output


 include/linux/kernel.h   |  2 --
 kernel/trace/trace.c | 31 ---
 kernel/trace/trace.h |  3 +++
 kernel/trace/trace_events.c  |  9 -
 kernel/trace/trace_functions_graph.c | 22 +++---
 5 files changed, 38 insertions(+), 29 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 1/1] cpufreq: cpufreq-cpu0: use the max voltage instead of voltage-tolerance

[Rongjun Ying]

> -Original Message-
> From: Shawn Guo [mailto:shawn@linaro.org]
> Sent: Thursday, November 07, 2013 10:27 AM
> To: Rongjun Ying
> Cc: Viresh Kumar; rjying; Rafael J. Wysocki; cpuf...@vger.kernel.org;
> linux...@vger.kernel.org; Linux Kernel Mailing List; Barry Song
> Subject: Re: [PATCH 1/1] cpufreq: cpufreq-cpu0: use the max voltage
> instead of voltage-tolerance
> 
> On Thu, Nov 07, 2013 at 01:55:21AM +, Rongjun Ying wrote:
> > > For given board, what voltages could be provided is known.  So you
> > > can just define OPP table in .dts and specify the voltage as
> > > the value that the regulator IC can supply, e.g. 1.200V in above
> example.
> > >
> > > This is not nice, as OPP table is CPU/SoC specific and should be
> > > ideally defined in .dtsi.  But still it's a way out for you to
> > > use
> > > cpufreq-cpu0 driver as it is.
> > >
> > > In any case, you can not just change voltage-tolerance to
> > > voltage-max with no care about the existing users.
> > >
> > > Shawn
> > >
> > I don't think so. The voltage/freq pairs are attribute of the CPU.
> > Any boards can choose regulator IC base the cost and other reasons.
> > If the opp table defined in .dts, we can set exact
> voltage/freq
> > pairs, and not need use the voltage-tolerance to set tolerance.
> 
> If you read my comment above, you should see that I agree OPP is
> CPU/SoC specific and should be defined in .dtsi.  But property
> operating-points can reasonably be overwritten by particular
> .dts for some reason like some voltages cannot be supplied on
> that board.
> 
> Again, this is just a way for you to use generic cpufreq-cpu0 driver as
> it is, but not necessarily the best one.
> 
> Shawn
> 

I think my patch is better.
All soc have a max work voltage. If regulator IC can't supply min voltage, 
It can supply max voltage to soc.
As my patch, not need overwrite OPP in .dts.
As your comment above, almost all board need overwrite OPP, unless the 
regulator 
IC can supply all voltage ranges of SoC need.

Thanks
-RongJun Ying
> 
> 
>  To report this email as spam click
> https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ==
> aM23S6+s5uWr7qEkawiSK+0AUqjCk0gm6KMeRLY+cWrx9g== .


Member of the CSR plc group of companies. CSR plc registered in England and 
Wales, registered number 4187346, registered office Churchill House, Cambridge 
Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at 
http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: CONFIG_NO_HZ_FULL + CONFIG_PREEMPT_RT_FULL = nogo

[Mike Galbraith]

On Wed, 2013-11-06 at 18:49 +0100, Thomas Gleixner wrote: 
> On Thu, 31 Oct 2013, Mike Galbraith wrote:
> 
> > Hi Frederic,
> > 
> > The tick wakes ksoftirqd, ensuring nr_running test ain't gonna happen
> > when an otherwise lonely task takes the timer interrupt.  Deferring to
> > softirq processing time. works.
> 
> -ENOPARSE
> 
> What the heck is this patch doing aside of slapping #ifdeffery all
> over the place?

It ain't a patch, it's a diagnostic.

> I bet you are trying to work around some of the side effects of the
> occasional tick which is still necessary despite of full nohz, right?

Nope, I wanted to check out cost of nohz_full for rt, and found that it
doesn't work at all instead, looked, and found that the sole running
task has just awakened ksoftirqd when it wants to shut the tick down, so
that shutdown never happens. 

> Bah, we want to solve the underlying problems and get rid of the tick
> completely instead of hiding the issues by magic hackery.

That's why I mentioned it.  That " works" has a whole different
meaning than "this is the fix" :)

-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] seccomp: not compatible with ARM OABI

[Will Drewry]

Thanks!

Reviewed-By: Will Drewry 

On Wed, Nov 6, 2013 at 5:31 PM, Kees Cook  wrote:
> Make sure that seccomp filter won't be built when ARM OABI is in use,
> since there is work needed to distinguish calling conventions. Until
> that is done (which is likely never since OABI is deprecated), make
> sure seccomp filter is unavailable in the OABI compat world.
>
> Signed-off-by: Kees Cook 
> ---
>  arch/Kconfig |5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index af2cc6eabcc7..6eaca7d92399 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -331,12 +331,15 @@ config HAVE_ARCH_SECCOMP_FILTER
>
>  config SECCOMP_FILTER
> def_bool y
> -   depends on HAVE_ARCH_SECCOMP_FILTER && SECCOMP && NET
> +   depends on HAVE_ARCH_SECCOMP_FILTER && SECCOMP && NET && !OABI_COMPAT
> help
>   Enable tasks to build secure computing environments defined
>   in terms of Berkeley Packet Filter programs which implement
>   task-defined system call filtering polices.
>
> + Not available on ARM when built with OABI compatibility due to
> + lack of a sensible way to distinguish the calling conventions.
> +
>   See Documentation/prctl/seccomp_filter.txt for details.
>
>  config HAVE_CONTEXT_TRACKING
> --
> 1.7.9.5
>
>
> --
> Kees Cook
> Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 3/4] arm: prima2: make use of common scu_a9_get_base() interface

[Jisheng Zhang]

Make use of common scu_a9_get_base() and delete the comment since the
interface is self commented.

Signed-off-by: Jisheng Zhang 
---
 arch/arm/mach-prima2/platsmp.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mach-prima2/platsmp.c b/arch/arm/mach-prima2/platsmp.c
index 3dbcb1a..2d5bcc9 100644
--- a/arch/arm/mach-prima2/platsmp.c
+++ b/arch/arm/mach-prima2/platsmp.c
@@ -34,8 +34,7 @@ void __init sirfsoc_map_scu(void)
 {
unsigned long base;
 
-   /* Get SCU base */
-   asm("mrc p15, 4, %0, c15, c0, 0" : "=r" (base));
+   base = scu_a9_get_base();
 
scu_io_desc.virtual = SIRFSOC_VA(base);
scu_io_desc.pfn = __phys_to_pfn(base);
-- 
1.8.4.2

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

[PATCH V2 0/4] arm: make use of common scu_a9_get_base() interface

[Jisheng Zhang]

Commit e9d6b3358ac35901ccc6a4a5a317670fa469db25 adds common APIs to
get scu base address from CP15. This patch series connverts some platforms
to use that interface.

Jisheng Zhang (4):
  arm: highbank: make use of common scu_a9_get_base() interface
  arm: imx: make use of common scu_a9_get_base() interface
  arm: prima2: make use of common scu_a9_get_base() interface
  arm: socfgpa: make use of common scu_a9_get_base() interface

 arch/arm/mach-highbank/highbank.c | 4 ++--
 arch/arm/mach-imx/platsmp.c   | 3 +--
 arch/arm/mach-prima2/platsmp.c| 3 +--
 arch/arm/mach-socfpga/socfpga.c   | 4 ++--
 4 files changed, 6 insertions(+), 8 deletions(-)

-- 
1.8.4.2

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

[PATCH V2 4/4] arm: socfgpa: make use of common scu_a9_get_base() interface

[Jisheng Zhang]

Make use of common scu_a9_get_base() and delete the comment since the
interface is self commented.

Signed-off-by: Jisheng Zhang 
---
 arch/arm/mach-socfpga/socfpga.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c
index bfce964..b695887 100644
--- a/arch/arm/mach-socfpga/socfpga.c
+++ b/arch/arm/mach-socfpga/socfpga.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "core.h"
 
@@ -51,8 +52,7 @@ static void __init socfpga_scu_map_io(void)
 {
unsigned long base;
 
-   /* Get SCU base */
-   asm("mrc p15, 4, %0, c15, c0, 0" : "=r" (base));
+   base = scu_a9_get_base();
 
scu_io_desc.pfn = __phys_to_pfn(base);
iotable_init(_io_desc, 1);
-- 
1.8.4.2

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

[PATCH V2 1/4] arm: highbank: make use of common scu_a9_get_base() interface

[Jisheng Zhang]

Make use of common scu_a9_get_base() and delete the comment since the
interface is self commented.

Signed-off-by: Jisheng Zhang 
---
 arch/arm/mach-highbank/highbank.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-highbank/highbank.c 
b/arch/arm/mach-highbank/highbank.c
index 8e63ccd..7df007b 100644
--- a/arch/arm/mach-highbank/highbank.c
+++ b/arch/arm/mach-highbank/highbank.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -43,8 +44,7 @@ static void __init highbank_scu_map_io(void)
 {
unsigned long base;
 
-   /* Get SCU base */
-   asm("mrc p15, 4, %0, c15, c0, 0" : "=r" (base));
+   base = scu_a9_get_base();
 
scu_base_addr = ioremap(base, SZ_4K);
 }
-- 
1.8.4.2

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

[PATCH V2 2/4] arm: imx: make use of common scu_a9_get_base() interface

[Jisheng Zhang]

Make use of common scu_a9_get_base() and delete the comment since the
interface is self commented.

Signed-off-by: Jisheng Zhang 
---
 arch/arm/mach-imx/platsmp.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mach-imx/platsmp.c b/arch/arm/mach-imx/platsmp.c
index 1f24c1f..369a566 100644
--- a/arch/arm/mach-imx/platsmp.c
+++ b/arch/arm/mach-imx/platsmp.c
@@ -35,8 +35,7 @@ void __init imx_scu_map_io(void)
 {
unsigned long base;
 
-   /* Get SCU base */
-   asm("mrc p15, 4, %0, c15, c0, 0" : "=r" (base));
+   base = scu_a9_get_base();
 
scu_io_desc.virtual = IMX_IO_P2V(base);
scu_io_desc.pfn = __phys_to_pfn(base);
-- 
1.8.4.2

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

Re: [PATCH 0/4] arm: make use of common scu_a9_get_base() interface

[Jisheng Zhang]

On Wed, 6 Nov 2013 19:08:33 -0800
Jisheng Zhang  wrote:

> Commit e9d6b3358ac35901ccc6a4a5a317670fa469db25 adds common APIs to
> get scu base address from CP15. This patch series connverts some platforms
> to use that interface.

OOPS, sorry, I made an mistake when generating patches. Please ignore this
serials. I'll submit V2 soon

Sorry again.
Jisheng
> 
> Jisheng Zhang (4):
>   arm: highbank: make use of common scu_a9_get_base() interface
>   arm: imx: make use of common scu_a9_get_base() interface
>   arm: prima2: make use of common scu_a9_get_base() interface
>   arm: socfgpa: make use of common scu_a9_get_base() interface
> 
>  arch/arm/mach-highbank/highbank.c | 4 ++--
>  arch/arm/mach-imx/platsmp.c   | 3 +--
>  arch/arm/mach-prima2/platsmp.c| 3 +--
>  arch/arm/mach-socfpga/socfpga.c   | 4 ++--
>  4 files changed, 6 insertions(+), 8 deletions(-)
> 

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

[PATCH] memstick: rtsx: fix ms card data transfer bug

[micky_ching]

From: Micky Ching 

This patch is used to add support for ms card. The main difference
between ms card and mspro card is long data transfer mode. mspro card
can use auto mode DMA for long data transfer, but ms can not use this
mode, it should use normal mode DMA.

The memstick core add support for ms card, but the original driver will
make ms card fail at initialize, because it use auto mode DMA. This
patch can make ms card work properly.

Signed-off-by: Micky Ching 
---
 drivers/memstick/host/rtsx_pci_ms.c |   30 --
 1 file changed, 20 insertions(+), 10 deletions(-)

diff --git a/drivers/memstick/host/rtsx_pci_ms.c 
b/drivers/memstick/host/rtsx_pci_ms.c
index 25f8f93..2a635b6 100644
--- a/drivers/memstick/host/rtsx_pci_ms.c
+++ b/drivers/memstick/host/rtsx_pci_ms.c
@@ -145,6 +145,8 @@ static int ms_transfer_data(struct realtek_pci_ms *host, 
unsigned char data_dir,
unsigned int length = sg->length;
u16 sec_cnt = (u16)(length / 512);
u8 val, trans_mode, dma_dir;
+   struct memstick_dev *card = host->msh->card;
+   bool pro_card = card->id.type == MEMSTICK_TYPE_PRO;
 
dev_dbg(ms_dev(host), "%s: tpc = 0x%02x, data_dir = %s, length = %d\n",
__func__, tpc, (data_dir == READ) ? "READ" : "WRITE",
@@ -152,19 +154,21 @@ static int ms_transfer_data(struct realtek_pci_ms *host, 
unsigned char data_dir,
 
if (data_dir == READ) {
dma_dir = DMA_DIR_FROM_CARD;
-   trans_mode = MS_TM_AUTO_READ;
+   trans_mode = pro_card ? MS_TM_AUTO_READ : MS_TM_NORMAL_READ;
} else {
dma_dir = DMA_DIR_TO_CARD;
-   trans_mode = MS_TM_AUTO_WRITE;
+   trans_mode = pro_card ? MS_TM_AUTO_WRITE : MS_TM_NORMAL_WRITE;
}
 
rtsx_pci_init_cmd(pcr);
 
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, MS_TPC, 0xFF, tpc);
-   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, MS_SECTOR_CNT_H,
-   0xFF, (u8)(sec_cnt >> 8));
-   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, MS_SECTOR_CNT_L,
-   0xFF, (u8)sec_cnt);
+   if (pro_card) {
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, MS_SECTOR_CNT_H,
+   0xFF, (u8)(sec_cnt >> 8));
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, MS_SECTOR_CNT_L,
+   0xFF, (u8)sec_cnt);
+   }
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, MS_TRANS_CFG, 0xFF, cfg);
 
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, IRQSTAT0,
@@ -192,8 +196,14 @@ static int ms_transfer_data(struct realtek_pci_ms *host, 
unsigned char data_dir,
}
 
rtsx_pci_read_register(pcr, MS_TRANS_CFG, );
-   if (val & (MS_INT_CMDNK | MS_INT_ERR | MS_CRC16_ERR | MS_RDY_TIMEOUT))
-   return -EIO;
+   if (pro_card) {
+   if (val & (MS_INT_CMDNK | MS_INT_ERR |
+   MS_CRC16_ERR | MS_RDY_TIMEOUT))
+   return -EIO;
+   } else {
+   if (val & (MS_CRC16_ERR | MS_RDY_TIMEOUT))
+   return -EIO;
+   }
 
return 0;
 }
@@ -462,8 +472,8 @@ static int rtsx_pci_ms_set_param(struct memstick_host *msh,
clock = 1900;
ssc_depth = RTSX_SSC_DEPTH_500K;
 
-   err = rtsx_pci_write_register(pcr, MS_CFG,
-   0x18, MS_BUS_WIDTH_1);
+   err = rtsx_pci_write_register(pcr, MS_CFG, 0x58,
+   MS_BUS_WIDTH_1 | PUSH_TIME_DEFAULT);
if (err < 0)
return err;
} else if (value == MEMSTICK_PAR4) {
-- 
1.7.9.5

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

[PATCH 3/4] arm: prima2: make use of common scu_a9_get_base() interface

[Jisheng Zhang]

Make use of common scu_a9_get_base() and delete the comment since the
interface is self commented.

Signed-off-by: Jisheng Zhang 
---
 arch/arm/mach-prima2/platsmp.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mach-prima2/platsmp.c b/arch/arm/mach-prima2/platsmp.c
index 3dbcb1a..2d5bcc9 100644
--- a/arch/arm/mach-prima2/platsmp.c
+++ b/arch/arm/mach-prima2/platsmp.c
@@ -34,8 +34,7 @@ void __init sirfsoc_map_scu(void)
 {
unsigned long base;
 
-   /* Get SCU base */
-   asm("mrc p15, 4, %0, c15, c0, 0" : "=r" (base));
+   base = scu_a9_get_base();
 
scu_io_desc.virtual = SIRFSOC_VA(base);
scu_io_desc.pfn = __phys_to_pfn(base);
-- 
1.8.4.2

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

[PATCH v5 3/3] pinctrl: mvebu: Convert to use devm_ioremap_resource

[Jisheng Zhang]

The resource mapped by of_iomap() isn't unmapped in error path. This
patch fix the resource leakage by using devm_ioremap_resource() instead
of of_iomap().

Signed-off-by: Jisheng Zhang 
Reviewed-by: Ezequiel Garcia 
Acked-by: Jason Cooper 
---
 drivers/pinctrl/mvebu/pinctrl-mvebu.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/pinctrl/mvebu/pinctrl-mvebu.c 
b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
index bb7ddb1..1caa45f 100644
--- a/drivers/pinctrl/mvebu/pinctrl-mvebu.c
+++ b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
@@ -579,7 +579,7 @@ static int mvebu_pinctrl_build_functions(struct 
platform_device *pdev,
 int mvebu_pinctrl_probe(struct platform_device *pdev)
 {
struct mvebu_pinctrl_soc_info *soc = dev_get_platdata(>dev);
-   struct device_node *np = pdev->dev.of_node;
+   struct resource *res;
struct mvebu_pinctrl *pctl;
void __iomem *base;
struct pinctrl_pin_desc *pdesc;
@@ -591,11 +591,10 @@ int mvebu_pinctrl_probe(struct platform_device *pdev)
return -EINVAL;
}
 
-   base = of_iomap(np, 0);
-   if (!base) {
-   dev_err(>dev, "unable to get base address\n");
-   return -ENODEV;
-   }
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   base = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(base))
+   return PTR_ERR(base);
 
pctl = devm_kzalloc(>dev, sizeof(struct mvebu_pinctrl),
GFP_KERNEL);
-- 
1.8.4.rc3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/3] bus: mvebu: add missing of_node_put() to fix reference leak

[Jisheng Zhang]

Add of_node_put to properly decrement the refcount when we are
done using a given node.

Signed-off-by: Jisheng Zhang 
Reviewed-by: Ezequiel Garcia 
---
 drivers/bus/mvebu-mbus.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 33c6947..20da90f 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -837,6 +837,7 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t 
mbuswins_phys_base,
 {
struct mvebu_mbus_state *mbus = _state;
const struct of_device_id *of_id;
+   struct device_node *np;
int win;
 
for (of_id = of_mvebu_mbus_ids; of_id->compatible; of_id++)
@@ -860,8 +861,11 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t 
mbuswins_phys_base,
return -ENOMEM;
}
 
-   if (of_find_compatible_node(NULL, NULL, "marvell,coherency-fabric"))
+   np = of_find_compatible_node(NULL, NULL, "marvell,coherency-fabric");
+   if (np) {
mbus->hw_io_coherency = 1;
+   of_node_put(np);
+   }
 
for (win = 0; win < mbus->soc->num_wins; win++)
mvebu_mbus_disable_window(mbus, win);
-- 
1.8.4.rc3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] arm: make use of common scu_a9_get_base() interface

[Jisheng Zhang]

Commit e9d6b3358ac35901ccc6a4a5a317670fa469db25 adds common APIs to
get scu base address from CP15. This patch series connverts some platforms
to use that interface.

Jisheng Zhang (4):
  arm: highbank: make use of common scu_a9_get_base() interface
  arm: imx: make use of common scu_a9_get_base() interface
  arm: prima2: make use of common scu_a9_get_base() interface
  arm: socfgpa: make use of common scu_a9_get_base() interface

 arch/arm/mach-highbank/highbank.c | 4 ++--
 arch/arm/mach-imx/platsmp.c   | 3 +--
 arch/arm/mach-prima2/platsmp.c| 3 +--
 arch/arm/mach-socfpga/socfpga.c   | 4 ++--
 4 files changed, 6 insertions(+), 8 deletions(-)

-- 
1.8.4.2

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

[PATCH 1/4] arm: highbank: make use of common scu_a9_get_base() interface

[Jisheng Zhang]

Make use of common scu_a9_get_base() and delete the comment since the
interface is self commented.

Signed-off-by: Jisheng Zhang 
---
 arch/arm/mach-highbank/highbank.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-highbank/highbank.c 
b/arch/arm/mach-highbank/highbank.c
index 8e63ccd..7df007b 100644
--- a/arch/arm/mach-highbank/highbank.c
+++ b/arch/arm/mach-highbank/highbank.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -43,8 +44,7 @@ static void __init highbank_scu_map_io(void)
 {
unsigned long base;
 
-   /* Get SCU base */
-   asm("mrc p15, 4, %0, c15, c0, 0" : "=r" (base));
+   base = scu_a9_get_base();
 
scu_base_addr = ioremap(base, SZ_4K);
 }
-- 
1.8.4.2

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

[PATCH 4/4] arm: socfgpa: make use of common scu_a9_get_base() interface

[Jisheng Zhang]

Make use of common scu_a9_get_base() and delete the comment since the
interface is self commented.

Signed-off-by: Jisheng Zhang 
---
 arch/arm/mach-socfpga/socfpga.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c
index bfce964..b695887 100644
--- a/arch/arm/mach-socfpga/socfpga.c
+++ b/arch/arm/mach-socfpga/socfpga.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "core.h"
 
@@ -51,8 +52,7 @@ static void __init socfpga_scu_map_io(void)
 {
unsigned long base;
 
-   /* Get SCU base */
-   asm("mrc p15, 4, %0, c15, c0, 0" : "=r" (base));
+   base = scu_a9_get_base();
 
scu_io_desc.pfn = __phys_to_pfn(base);
iotable_init(_io_desc, 1);
-- 
1.8.4.2

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

[PATCH 2/4] arm: imx: make use of common scu_a9_get_base() interface

[Jisheng Zhang]

Make use of common scu_a9_get_base() and delete the comment since the
interface is self commented.

Signed-off-by: Jisheng Zhang 
---
 arch/arm/mach-imx/platsmp.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mach-imx/platsmp.c b/arch/arm/mach-imx/platsmp.c
index 1f24c1f..369a566 100644
--- a/arch/arm/mach-imx/platsmp.c
+++ b/arch/arm/mach-imx/platsmp.c
@@ -35,8 +35,7 @@ void __init imx_scu_map_io(void)
 {
unsigned long base;
 
-   /* Get SCU base */
-   asm("mrc p15, 4, %0, c15, c0, 0" : "=r" (base));
+   base = scu_a9_get_base();
 
scu_io_desc.virtual = IMX_IO_P2V(base);
scu_io_desc.pfn = __phys_to_pfn(base);
-- 
1.8.4.2

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

[PATCH v5 1/3] arm: mvebu: add missing of_node_put() to fix reference leak

[Jisheng Zhang]

Add of_node_put to properly decrement the refcount when we are
done using a given node.

Signed-off-by: Jisheng Zhang 
Reviewed-by: Ezequiel Garcia 
---
 arch/arm/mach-mvebu/armada-370-xp.c | 1 +
 arch/arm/mach-mvebu/coherency.c | 8 +++-
 arch/arm/mach-mvebu/platsmp.c   | 1 +
 arch/arm/mach-mvebu/pmsu.c  | 1 +
 arch/arm/mach-mvebu/system-controller.c | 1 +
 5 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-mvebu/armada-370-xp.c 
b/arch/arm/mach-mvebu/armada-370-xp.c
index 97cbb80..8a1ae83 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -64,6 +64,7 @@ static void __init armada_370_xp_mbus_init(void)
ARMADA_370_XP_MBUS_WINS_SIZE,
of_translate_address(dn, _wins_offs),
ARMADA_370_XP_SDRAM_WINS_SIZE);
+   of_node_put(dn);
 }
 
 static void __init armada_370_xp_timer_and_clk_init(void)
diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
index 4c24303..58adf2f 100644
--- a/arch/arm/mach-mvebu/coherency.c
+++ b/arch/arm/mach-mvebu/coherency.c
@@ -140,6 +140,7 @@ int __init coherency_init(void)
coherency_base = of_iomap(np, 0);
coherency_cpu_base = of_iomap(np, 1);
set_cpu_coherent(cpu_logical_map(smp_processor_id()), 0);
+   of_node_put(np);
}
 
return 0;
@@ -147,9 +148,14 @@ int __init coherency_init(void)
 
 static int __init coherency_late_init(void)
 {
-   if (of_find_matching_node(NULL, of_coherency_table))
+   struct device_node *np;
+
+   np = of_find_matching_node(NULL, of_coherency_table);
+   if (np) {
bus_register_notifier(_bus_type,
  _hwcc_platform_nb);
+   of_node_put(np);
+   }
return 0;
 }
 
diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
index ce81d30..e7edb82 100644
--- a/arch/arm/mach-mvebu/platsmp.c
+++ b/arch/arm/mach-mvebu/platsmp.c
@@ -95,6 +95,7 @@ static void __init armada_xp_smp_init_cpus(void)
panic("No 'cpus' node found\n");
 
ncores = of_get_child_count(np);
+   of_node_put(np);
if (ncores == 0 || ncores > ARMADA_XP_MAX_CPUS)
panic("Invalid number of CPUs in DT\n");
 
diff --git a/arch/arm/mach-mvebu/pmsu.c b/arch/arm/mach-mvebu/pmsu.c
index 3cc4bef..27fc4f0 100644
--- a/arch/arm/mach-mvebu/pmsu.c
+++ b/arch/arm/mach-mvebu/pmsu.c
@@ -67,6 +67,7 @@ int __init armada_370_xp_pmsu_init(void)
pr_info("Initializing Power Management Service Unit\n");
pmsu_mp_base = of_iomap(np, 0);
pmsu_reset_base = of_iomap(np, 1);
+   of_node_put(np);
}
 
return 0;
diff --git a/arch/arm/mach-mvebu/system-controller.c 
b/arch/arm/mach-mvebu/system-controller.c
index f875124..5175083c 100644
--- a/arch/arm/mach-mvebu/system-controller.c
+++ b/arch/arm/mach-mvebu/system-controller.c
@@ -98,6 +98,7 @@ static int __init mvebu_system_controller_init(void)
BUG_ON(!match);
system_controller_base = of_iomap(np, 0);
mvebu_sc = (struct mvebu_system_controller *)match->data;
+   of_node_put(np);
}
 
return 0;
-- 
1.8.4.rc3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random

[Stephan Mueller]

Am Mittwoch, 6. November 2013, 14:26:35 schrieb Pavel Machek:

Hi Pavel,

>Hi!
>
>> >I plugged that idea into my current Jitter RNG processing and
>> >disabled
>> >the other jitter measurements to get a clear, isolated picture.
>> >
>> >The result is also a white noise! And it is even quite fast.
>> 
>> After doing some more research on this approach, I have to admit that
>> the output not good (i.e. white noise) in all situations. Therefore,
>> I
>> dropped that (for now).
>
>Is there chance to extract at least some entropy from it? (Can you
>post the code you used for testing?) Because in this case we know
>where the entropy comes from, which is important for Ted.

The code is as follows -- it hooks into the framework of the RNG I 
already have, so the code folds the obtained data into one bit (use the 
following function as a drop-in replacement to my RNG code.

static __u64 jent_measure_jitter(struct rand_data *entropy_collector)
{
__u64 starttime = 0;
__u64 currtime = 0;
__u64 counter = 0;
__u64 data = 0;

jent_get_ustime();
jent_get_ustime();
while(starttime == currtime)
{
jent_get_ustime();
counter++;
}
jent_fold_time(counter, , 1);
return data;
}

Consider the following in addition:

static inline void jent_get_ustime(__u64 *out)
{
__u64 tmp = 0;
struct timeval time;
if(gettimeofday(, NULL) == 0)
tmp = time.tv_usec;
*out = tmp;
}

For the kernel land, I implemented jent_get_ustime to be identical to 
do_gettimeofday().

The result is the following on my i7 2nd gen without using the Von-
Neumann unbias operation:

- user space: looks like good white noise based on the results of ent 
(Chi square, etc). When I print out the counter variable above and 
calculate the Shannon Entropy, I get about 1.5 bits, so we have 
variations. But when you look at the data manually, you see quite some 
streaks that alternate between two values. Here is an example:

4
6
10
2
3
2
3
4
4
4
4
4
5
3
4
5
4
4
4
5
4
4
5
4
4
5
4
4
5
4
4
5
4
4
4
5
4
4


- kernel space: the resulting binary string is not very good: the chi 
square is very bad. Moreover, the resulting data string is slightly 
skewed. The reason is simple by looking at the counter value which I 
obtained with another debugfs file: there are very very long streaks of 
the same or alternating values.

So, I guess you may get some entropy, but I am not sure how much.

Also, when I enlarge the timer value to look something like that:

if(gettimeofday(, NULL) == 0)
tmp = time.tv_usec>>3;

the counter value is not getting really better, it is still alternating 
between two or three values.


>
>Thanks,
>   Pavel


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

Re: [PATCH v3] Add Documentation/module-signing.txt file

[Rusty Russell]

Randy Dunlap  writes:
> On 11/06/13 10:53, James Solner wrote:
>> This patch adds the Documentation/module-signing.txt file that is
>> currently missing from the Documentation directory. The init/Kconfig
>> file references the Documentation/module-signing.txt file to explain
>> how kernel module signing works. This patch supplies this documentation. 
>> 
>> The initial version of this patch provided old documentation
>> that was a mixture of the old RHEL style GPG signing. 
>> Version 1 updated the documentation to described the current
>> implementation using x509 certificate signing. 
>> Version 2, fixes grammar/spelling mistakes and removes
>> trailing whitespaces. Version 3, fixes grammar/spelling mistakes. 
>> 
>> Signed-off-by: James Solner 
>> 
>
> Looks good to me.  I'll let David, Josh, Rusty, et al, comment
> on the real content.

Once David Acks, I'll take it.

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

Re: [trivial PATCH] module.h: Remove unnecessary semicolon

[Rusty Russell]

Joe Perches  writes:
> This semicolon isn't necessary, remove it.
>
> Signed-off-by: Joe Perches 

This is a terrible description.  Really bad.

First, it just repeats the subject, with more words.

Second, it gives me no indication that you've done a grep to make sure
noone is abusing the macro, so I can't apply it without doing that check
myself.

Please try again.

Rusty.

> ---
>  include/linux/module.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/module.h b/include/linux/module.h
> index 05f2447..d1ad477 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -454,7 +454,7 @@ int module_kallsyms_on_each_symbol(int (*fn)(void *, 
> const char *,
>  
>  extern void __module_put_and_exit(struct module *mod, long code)
>   __attribute__((noreturn));
> -#define module_put_and_exit(code) __module_put_and_exit(THIS_MODULE, code);
> +#define module_put_and_exit(code) __module_put_and_exit(THIS_MODULE, code)
>  
>  #ifdef CONFIG_MODULE_UNLOAD
>  unsigned long module_refcount(struct module *mod);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] include/uapi/sound/firewire.h: use "_UAPI" instead of "UAPI"

[Chen Gang]

When installing, "scripts/headers_install.sh" will strip guard macro'
"_UAPI" to prevent from appearing it to users. And also, all another
files which need uapi prefix always use "_UAPI", not "UAPI".

So use "_UAPI" instead of "UAPI" on the guard macro, and also give a
comment for "#endif".


Signed-off-by: Chen Gang 
---
 include/uapi/sound/firewire.h |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/uapi/sound/firewire.h b/include/uapi/sound/firewire.h
index e86131c..59f5961 100644
--- a/include/uapi/sound/firewire.h
+++ b/include/uapi/sound/firewire.h
@@ -1,5 +1,5 @@
-#ifndef UAPI_SOUND_FIREWIRE_H_INCLUDED
-#define UAPI_SOUND_FIREWIRE_H_INCLUDED
+#ifndef _UAPI_SOUND_FIREWIRE_H_INCLUDED
+#define _UAPI_SOUND_FIREWIRE_H_INCLUDED
 
 #include 
 
@@ -48,4 +48,4 @@ struct snd_firewire_get_info {
  * Returns -EBUSY if the driver is already streaming.
  */
 
-#endif
+#endif /* _UAPI_SOUND_FIREWIRE_H_INCLUDED */
-- 
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] dynamic_debug: add wildcard support to filter files/functions/modules

[Changbin Du]

2013/11/1 Joe Perches :
> On Thu, 2013-10-31 at 15:52 -0700, Andrew Morton wrote:
>> On Mon, 28 Oct 2013 23:29:10 +0800 "Du, Changbin"  
>> wrote:
> []
>> > +/* check if the string matches given pattern which includes wildcards */
>> > +static int match_pattern(const char *pattern, const char *string)
> []
>> No, something like this should be in lib/ so that other callers can use
>> it.  We already have at least one copy handy in
>> drivers/ata/libata-core.c:glob_match().  A better approach would be to
>> move that glob_match() into lib/glob_match.c then teach dynamic_debug
>> to use it.
>>
>> There are probably other private globbing functions lying around the
>> kernel, but it's rather a hard thing to grep for...
>
> Maybe use lib/parser.c where the other match_ functions
> are already.

match_ functions in lib/parser.c just do simple match, they
doesn't support wildcards.
So it's not useful for us.

>
> match_glob has the disadvantage that it's recursive too.
>

As you mentioned before, we cannot use it since strings are given from
userspace. :)

> trace has:
>
> kernel/trace/trace_events_filter.c:static int regex_match_full(char *str, 
> struct regex *r, int len)
> kernel/trace/trace_events_filter.c:static int regex_match_front(char *str, 
> struct regex *r, int len)
> kernel/trace/trace_events_filter.c:static int regex_match_middle(char *str, 
> struct regex *r, int len)
> kernel/trace/trace_events_filter.c:static int regex_match_end(char *str, 
> struct regex *r, int len)
>
> but there probably aren't many more that could be converted.

Trace filter support wildcards, but it seems the match algorithm
couples with trace code. I'll try to see
if it can be split.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] dynamic_debug: add wildcard support to filter files/functions/modules

[Changbin Du]

2013/11/1 Joe Perches :
> On Thu, 2013-10-31 at 15:52 -0700, Andrew Morton wrote:
>> On Mon, 28 Oct 2013 23:29:10 +0800 "Du, Changbin"  
>> wrote:
> []
>> > +/* check if the string matches given pattern which includes wildcards */
>> > +static int match_pattern(const char *pattern, const char *string)
> []
>> No, something like this should be in lib/ so that other callers can use
>> it.  We already have at least one copy handy in
>> drivers/ata/libata-core.c:glob_match().  A better approach would be to
>> move that glob_match() into lib/glob_match.c then teach dynamic_debug
>> to use it.
>>
>> There are probably other private globbing functions lying around the
>> kernel, but it's rather a hard thing to grep for...
>
> Maybe use lib/parser.c where the other match_ functions
> are already.

match_ functions in lib/parser.c just do simple match, they
doesn't support wildcards.
So it's not useful for us.

>
> match_glob has the disadvantage that it's recursive too.
>

As you mentioned before, we cannot use it since strings are given from
userspace. :)

> trace has:
>
> kernel/trace/trace_events_filter.c:static int regex_match_full(char *str, 
> struct regex *r, int len)
> kernel/trace/trace_events_filter.c:static int regex_match_front(char *str, 
> struct regex *r, int len)
> kernel/trace/trace_events_filter.c:static int regex_match_middle(char *str, 
> struct regex *r, int len)
> kernel/trace/trace_events_filter.c:static int regex_match_end(char *str, 
> struct regex *r, int len)
>
> but there probably aren't many more that could be converted.

Trace filter support wildcards, but it seems the match algorithm
couples with trace code. I'll try to see
if it can be split.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/