[PATCH v3 20/21] fuse: Restrict allow_other to the superblock's namespace or a descendant

2016-04-22 Thread Seth Forshee
Unprivileged users are normally restricted from mounting with the
allow_other option by system policy, but this could be bypassed
for a mount done with user namespace root permissions. In such
cases allow_other should not allow users outside the userns
to access the mount as doing so would give the unprivileged user
the ability to manipulate processes it would otherwise be unable
to manipulate. Restrict allow_other to apply to users in the same
userns used at mount or a descendant of that namespace.

Signed-off-by: Seth Forshee 
Acked-by: Serge Hallyn 
Acked-by: Miklos Szeredi 
---
 fs/fuse/dir.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c
index ecba75bf6640..1a6c5af49608 100644
--- a/fs/fuse/dir.c
+++ b/fs/fuse/dir.c
@@ -1015,7 +1015,7 @@ int fuse_allow_current_process(struct fuse_conn *fc)
const struct cred *cred;
 
if (fc->flags & FUSE_ALLOW_OTHER)
-   return 1;
+   return current_in_userns(fc->user_ns);
 
cred = current_cred();
if (uid_eq(cred->euid, fc->user_id) &&
-- 
1.9.1



[PATCH v3 15/21] fs: Don't remove suid for CAP_FSETID in s_user_ns

2016-04-22 Thread Seth Forshee
Expand the check in should_remove_suid() to keep privileges for
CAP_FSETID in s_user_ns rather than init_user_ns.

Signed-off-by: Seth Forshee 
Acked-by: Serge Hallyn 
---
 fs/inode.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/inode.c b/fs/inode.c
index 69b8b526c194..cd52170f9117 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -1690,7 +1690,8 @@ int should_remove_suid(struct dentry *dentry)
if (unlikely((mode & S_ISGID) && (mode & S_IXGRP)))
kill |= ATTR_KILL_SGID;
 
-   if (unlikely(kill && !capable(CAP_FSETID) && S_ISREG(mode)))
+   if (unlikely(kill && !ns_capable(dentry->d_sb->s_user_ns, CAP_FSETID) &&
+S_ISREG(mode)))
return kill;
 
return 0;
-- 
1.9.1



[PATCH v3 21/21] fuse: Allow user namespace mounts

2016-04-22 Thread Seth Forshee
Signed-off-by: Seth Forshee 
Acked-by: Miklos Szeredi 
---
 fs/fuse/inode.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
index 0a771145d853..254f1944ee98 100644
--- a/fs/fuse/inode.c
+++ b/fs/fuse/inode.c
@@ -1199,7 +1199,7 @@ static void fuse_kill_sb_anon(struct super_block *sb)
 static struct file_system_type fuse_fs_type = {
.owner  = THIS_MODULE,
.name   = "fuse",
-   .fs_flags   = FS_HAS_SUBTYPE,
+   .fs_flags   = FS_HAS_SUBTYPE | FS_USERNS_MOUNT,
.mount  = fuse_mount,
.kill_sb= fuse_kill_sb_anon,
 };
@@ -1231,7 +1231,7 @@ static struct file_system_type fuseblk_fs_type = {
.name   = "fuseblk",
.mount  = fuse_mount_blk,
.kill_sb= fuse_kill_sb_blk,
-   .fs_flags   = FS_REQUIRES_DEV | FS_HAS_SUBTYPE,
+   .fs_flags   = FS_REQUIRES_DEV | FS_HAS_SUBTYPE | FS_USERNS_MOUNT,
 };
 MODULE_ALIAS_FS("fuseblk");
 
-- 
1.9.1



[PATCH v3 17/21] capabilities: Allow privileged user in s_user_ns to set security.* xattrs

2016-04-22 Thread Seth Forshee
A privileged user in s_user_ns will generally have the ability to
manipulate the backing store and insert security.* xattrs into
the filesystem directly. Therefore the kernel must be prepared to
handle these xattrs from unprivileged mounts, and it makes little
sense for commoncap to prevent writing these xattrs to the
filesystem. The capability and LSM code have already been updated
to appropriately handle xattrs from unprivileged mounts, so it
is safe to loosen this restriction on setting xattrs.

The exception to this logic is that writing xattrs to a mounted
filesystem may also cause the LSM inode_post_setxattr or
inode_setsecurity callbacks to be invoked. SELinux will deny the
xattr update by virtue of applying mountpoint labeling to
unprivileged userns mounts, and Smack will deny the writes for
any user without global CAP_MAC_ADMIN, so loosening the
capability check in commoncap is safe in this respect as well.

Signed-off-by: Seth Forshee 
Acked-by: Serge Hallyn 
---
 security/commoncap.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/security/commoncap.c b/security/commoncap.c
index e657227d221e..12477afaa8ed 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -664,15 +664,17 @@ int cap_bprm_secureexec(struct linux_binprm *bprm)
 int cap_inode_setxattr(struct dentry *dentry, const char *name,
   const void *value, size_t size, int flags)
 {
+   struct user_namespace *user_ns = dentry->d_sb->s_user_ns;
+
if (!strcmp(name, XATTR_NAME_CAPS)) {
-   if (!capable(CAP_SETFCAP))
+   if (!ns_capable(user_ns, CAP_SETFCAP))
return -EPERM;
return 0;
}
 
if (!strncmp(name, XATTR_SECURITY_PREFIX,
 sizeof(XATTR_SECURITY_PREFIX) - 1) &&
-   !capable(CAP_SYS_ADMIN))
+   !ns_capable(user_ns, CAP_SYS_ADMIN))
return -EPERM;
return 0;
 }
@@ -690,15 +692,17 @@ int cap_inode_setxattr(struct dentry *dentry, const char 
*name,
  */
 int cap_inode_removexattr(struct dentry *dentry, const char *name)
 {
+   struct user_namespace *user_ns = dentry->d_sb->s_user_ns;
+
if (!strcmp(name, XATTR_NAME_CAPS)) {
-   if (!capable(CAP_SETFCAP))
+   if (!ns_capable(user_ns, CAP_SETFCAP))
return -EPERM;
return 0;
}
 
if (!strncmp(name, XATTR_SECURITY_PREFIX,
 sizeof(XATTR_SECURITY_PREFIX) - 1) &&
-   !capable(CAP_SYS_ADMIN))
+   !ns_capable(user_ns, CAP_SYS_ADMIN))
return -EPERM;
return 0;
 }
-- 
1.9.1



[PATCH V3 12/18] coresight: tmc: dump system memory content only when needed

2016-04-22 Thread Mathieu Poirier
Calling tmc_etf/etr_dump_hw() is required only when operating from
sysFS.  When working from Perf, the system memory is harvested
from the AUX trace API.

Signed-off-by: Mathieu Poirier 
---
 drivers/hwtracing/coresight/coresight-tmc-etf.c | 7 ++-
 drivers/hwtracing/coresight/coresight-tmc-etr.c | 7 ++-
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c 
b/drivers/hwtracing/coresight/coresight-tmc-etf.c
index d090a9745c73..25fad93b68d4 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
@@ -74,7 +74,12 @@ static void tmc_etb_disable_hw(struct tmc_drvdata *drvdata)
CS_UNLOCK(drvdata->base);
 
tmc_flush_and_stop(drvdata);
-   tmc_etb_dump_hw(drvdata);
+   /*
+* When operating in sysFS mode the content of the buffer needs to be
+* read before the TMC is disabled.
+*/
+   if (local_read(>mode) == CS_MODE_SYSFS)
+   tmc_etb_dump_hw(drvdata);
tmc_disable_hw(drvdata);
 
CS_LOCK(drvdata->base);
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c 
b/drivers/hwtracing/coresight/coresight-tmc-etr.c
index 8bbbf3ab1387..4b000f4003a2 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
@@ -76,7 +76,12 @@ static void tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
CS_UNLOCK(drvdata->base);
 
tmc_flush_and_stop(drvdata);
-   tmc_etr_dump_hw(drvdata);
+   /*
+* When operating in sysFS mode the content of the buffer needs to be
+* read before the TMC is disabled.
+*/
+   if (local_read(>mode) == CS_MODE_SYSFS)
+   tmc_etr_dump_hw(drvdata);
tmc_disable_hw(drvdata);
 
CS_LOCK(drvdata->base);
-- 
2.5.0



Re: [git pull] drm fixes

2016-04-22 Thread Linus Torvalds
On Thu, Apr 21, 2016 at 5:57 PM, Dave Airlie  wrote:
>
>   git://people.freedesktop.org/~airlied/linux drm-fixes

Hmm. freedesktop.org seems to be feeling a bit under the weather. It's
not just the git part - it's not doing web either, and doesn't seem to
answer to pings either (I saw _one_ ping response, but that was over a
minute or two, so..)

Can you kick it? Do you have a mirror?

   Linus


Re: [PATCH] kvm: x86: do not leak guest xcr0 into host interrupt handlers

2016-04-22 Thread David Matlack
On Fri, Apr 22, 2016 at 12:30 AM, Wanpeng Li  wrote:
> Hi Paolo and David,
> 2016-03-31 3:24 GMT+08:00 David Matlack :
>>
>> kernel_fpu_begin() saves the current fpu context. If this uses
>> XSAVE[OPT], it may leave the xsave area in an undesirable state.
>> According to the SDM, during XSAVE bit i of XSTATE_BV is not modified
>> if bit i is 0 in xcr0. So it's possible that XSTATE_BV[i] == 1 and
>> xcr0[i] == 0 following an XSAVE.
>
> How XSAVE save bit i since SDM mentioned that "XSAVE saves state
> component i if and only if RFBM[i] = 1. "?  RFBM[i] will be 0 if
> XSTATE_BV[i] == 1 && guest xcr0[i] == 0.

You are correct, RFBM[i] will be 0 and XSAVE does not save state
component i in this case. However, XSTATE_BV[i] is left untouched by
XSAVE (left as 1). On XRSTOR, the CPU checks if XSTATE_BV[i] == 1 &&
xcr0[i] == 0, and if so delivers a #GP.

If you are wondering how XSTATE_BV[i] could be 1 in the first place, I
suspect it is left over from a previous XSAVE (which sets XSTATE_BV[i]
to the value in XINUSE[i]).

>
> Regards,
> Wanpeng Li
>
>>
>> kernel_fpu_end() restores the fpu context. Now if any bit i in
>> XSTATE_BV == 1 while xcr0[i] == 0, XRSTOR generates a #GP. The
>> fault is trapped and SIGSEGV is delivered to the current process.


Re: [PATCH 4/8] drm/fb-helper: Add fb_deferred_io support

2016-04-22 Thread Daniel Vetter
On Fri, Apr 22, 2016 at 7:28 PM, Noralf Trønnes  wrote:
> This patch extend the use of the fbdev deferred_io worker to also handle
> the fbdev drawing operations, which can happen in atomic context.
> The qxl driver adds an extra worker (struct qxl_device).fb_work which is
> used to flush the framebuffer. Both the mmap deferred_io (qxl_deferred_io())
> code which is run by the deferred io worker and the fbdev drawing operations
> (qxl_fb_fillrect() etc.) schedule this fb_work worker.
>
> So this patch uses 1 worker, qxl uses 2 workers.

Oh, I didn't realize that you're reusing the same worker for both
things. 2 workers indeed make sense, since the mmap one must have a
built-in delay (to coalesce a bunch of writes), whereas the other one
probably should be run right away, after each op.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


Re: [PATCH 4/8] drm/fb-helper: Add fb_deferred_io support

2016-04-22 Thread Noralf Trønnes


Den 22.04.2016 19:05, skrev Daniel Vetter:

On Fri, Apr 22, 2016 at 04:17:14PM +0200, Noralf Trønnes wrote:

Den 22.04.2016 10:27, skrev Daniel Vetter:

On Thu, Apr 21, 2016 at 08:54:45PM +0200, Noralf Trønnes wrote:

Den 20.04.2016 17:25, skrev Noralf Trønnes:

This adds deferred io support if CONFIG_FB_DEFERRED_IO is enabled.
Accumulated fbdev framebuffer changes are signaled using the callback
(struct drm_framebuffer_funcs *)->dirty()

The drm_fb_helper_sys_*() functions will accumulate changes and
schedule fb_info.deferred_work _if_ fb_info.fbdefio is set.
This worker is used by the deferred io mmap code to signal that it
has been collecting page faults. The page faults and/or other changes
are then merged into a drm_clip_rect and passed to the framebuffer
dirty() function.

The driver is responsible for setting up the fb_info.fbdefio structure
and calling fb_deferred_io_init() using the provided callback:
(struct fb_deferred_io).deferred_io = drm_fb_helper_deferred_io;

Signed-off-by: Noralf Trønnes 
---
  drivers/gpu/drm/drm_fb_helper.c | 119 +++-
  include/drm/drm_fb_helper.h |  15 +
  2 files changed, 133 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c

[...]


+#ifdef CONFIG_FB_DEFERRED_IO
+/**
+ * drm_fb_helper_deferred_io() - (struct fb_deferred_io *)->deferred_io 
callback
+ *   function
+ *
+ * This function always runs in process context (struct delayed_work) and calls
+ * the (struct drm_framebuffer_funcs)->dirty function with the collected
+ * damage. There's no need to worry about the possibility that the fb_sys_*()
+ * functions could be running in atomic context. They only schedule the
+ * delayed worker which then calls this deferred_io callback.
+ */
+void drm_fb_helper_deferred_io(struct fb_info *info,
+  struct list_head *pagelist)
+{
+   struct drm_fb_helper *helper = info->par;
+   unsigned long start, end, min, max;
+   struct drm_clip_rect clip;
+   unsigned long flags;
+   struct page *page;
+
+   if (!helper->fb->funcs->dirty)
+   return;
+
+   spin_lock_irqsave(>dirty_lock, flags);
+   clip = helper->dirty_clip;
+   drm_clip_rect_reset(>dirty_clip);
+   spin_unlock_irqrestore(>dirty_lock, flags);
+
+   min = ULONG_MAX;
+   max = 0;
+   list_for_each_entry(page, pagelist, lru) {
+   start = page->index << PAGE_SHIFT;
+   end = start + PAGE_SIZE - 1;
+   min = min(min, start);
+   max = max(max, end);
+   }
+
+   if (min < max) {
+   struct drm_clip_rect mmap_clip;
+
+   mmap_clip.x1 = 0;
+   mmap_clip.x2 = info->var.xres;
+   mmap_clip.y1 = min / info->fix.line_length;
+   mmap_clip.y2 = min_t(u32, max / info->fix.line_length,
+info->var.yres);
+   drm_clip_rect_merge(, _clip, 1, 0, 0, 0);
+   }
+
+   if (!drm_clip_rect_is_empty())
+   helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, , 1);
+}
+EXPORT_SYMBOL(drm_fb_helper_deferred_io);

There is one thing I have wondered about when it comes to deferred io and
long run times for the defio worker with my displays:

Userspace writes to some pages then the deferred io worker kicks off and
runs for 100ms holding the page list mutex. While this is happening,
userspace writes to a new page triggering a page_mkwrite. Now this
function has to wait for the mutex to be released.

Who is actually waiting here and is there a problem that this can last
for 100ms?

No idea at all - I haven't looked that closely at  fbdev defio. But one
reason we have an explicit ioctl in drm to flush out frontbuffer rendering
is exactly that flushing could take some time, and should only be done
once userspace has completed some rendering. Not right in the middle of an
op.

I guess fix up your userspace to use dumb drm fb + drm dirtyfb ioctl?
Otherwise you'll get to improve fbdev defio, and fbdev is deprecated
subsystem and a real horror show. I highly recommend against touching it
;-)

I have tried to track the call chain and it seems to be part of the
page fault handler. Which means it's userspace wanting to write to the
page that has to wait. And it has to wait at some random point in
whatever rendering it's doing.

Unless someone has any objections, I will make a change and add a worker
like qxl does. This decouples the deferred_io worker holding the mutex
from the framebuffer flushing job. However I intend to differ from qxl in
that I will use a delayed worker (run immediately from the mmap side which
has already been deferred). Since I don't see any point in flushing the
framebuffer immediately when fbcon has put out only one glyph, might as
well defer it a couple of jiffies to be able to capture some more glyphs.

Adding a worker 

Re: [PATCH 18/25] arm64: ilp32: introduce binfmt_ilp32.c

2016-04-22 Thread Arnd Bergmann
On Friday 22 April 2016 17:51:30 Catalin Marinas wrote:
> On Wed, Apr 06, 2016 at 01:08:40AM +0300, Yury Norov wrote:
> > --- /dev/null
> > +++ b/arch/arm64/kernel/binfmt_ilp32.c
> 
> [...]
> 
> > +#include "../../../fs/binfmt_elf.c"
> 
> How different is this new binfmt_ilp32.c file from the first part of
> compat_binfmt_elf.c? I wonder whether we could include the latter here
> instead and make this similar to binfmt_elf32.c introduced by the
> previous patch.

That is how the earlier versions did it, and I thought it ended up 
too ugly with lots of runtime checks instead of compile-time checks.

The current version is how I asked it to be done. A slight
variation would be to keep using fs/compat_binfmt_elf.c for one
of the two compat modes (today it is used for aarch32) and have
a separate file include "../../../fs/binfmt_elf.c" for the other
mode (as this patch does for ilp32). I think that is what I asked
for, but there was probably a good reason for having two files
in the same directory. The result is basically the same.

Arnd


Re: [PATCH] media: vb2: Fix regression on poll() for RW mode

2016-04-22 Thread Mauro Carvalho Chehab
Em Fri, 22 Apr 2016 18:45:41 +0200
Hans Verkuil  escreveu:

> On 04/22/2016 05:21 PM, Mauro Carvalho Chehab wrote:
> > Em Fri, 22 Apr 2016 16:56:00 +0200
> > Hans Verkuil  escreveu:
> >   
> >> On 04/22/2016 04:48 PM, Mauro Carvalho Chehab wrote:  
> >>> Em Fri, 22 Apr 2016 16:31:28 +0200
> >>> Hans Verkuil  escreveu:
> >>> 
>  On 04/22/2016 04:21 PM, Mauro Carvalho Chehab wrote:
> > Em Fri, 22 Apr 2016 14:37:07 +0200
> > Hans Verkuil  escreveu:
> >   
> >> On 04/22/2016 02:31 PM, Mauro Carvalho Chehab wrote:  
> >>> Em Fri, 22 Apr 2016 11:19:09 +0200
> >>> Hans Verkuil  escreveu:
> >>> 
>  Hi Ricardo,
> 
>  On 04/21/2016 11:15 AM, Ricardo Ribalda Delgado wrote:
> > When using a device is read/write mode, vb2 does not handle 
> > properly the
> > first select/poll operation. It allways return POLLERR.
> >
> > The reason for this is that when this code has been refactored, 
> > some of
> > the operations have changed their order, and now fileio emulator is 
> > not
> > started by poll, due to a previous check.
> >
> > Reported-by: Dimitrios Katsaros 
> > Cc: Junghak Sung 
> > Cc: sta...@vger.kernel.org
> > Fixes: 49d8ab9feaf2 ("media] media: videobuf2: Separate vb2_poll()")
> > Signed-off-by: Ricardo Ribalda Delgado 
> > ---
> >  drivers/media/v4l2-core/videobuf2-core.c | 8 
> >  drivers/media/v4l2-core/videobuf2-v4l2.c | 8 
> >  2 files changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> > b/drivers/media/v4l2-core/videobuf2-core.c
> > index 5d016f496e0e..199c65dbe330 100644
> > --- a/drivers/media/v4l2-core/videobuf2-core.c
> > +++ b/drivers/media/v4l2-core/videobuf2-core.c
> > @@ -2298,6 +2298,14 @@ unsigned int vb2_core_poll(struct vb2_queue 
> > *q, struct file *file,
> > return POLLERR;
> >  
> > /*
> > +* For compatibility with vb1: if QBUF hasn't been called yet, 
> > then
> > +* return POLLERR as well. This only affects capture queues, 
> > output
> > +* queues will always initialize waiting_for_buffers to false.
> > +*/
> > +   if (q->waiting_for_buffers && (req_events & (POLLIN | 
> > POLLRDNORM)))
> > +   return POLLERR;  
> 
>  The problem I have with this is that this should be specific to 
>  V4L2. The only
>  reason we do this is that we had to stay backwards compatible with 
>  vb1.
> 
>  This is the reason this code was placed in videobuf2-v4l2.c. But you 
>  are correct
>  that this causes a regression, and I see no other choice but to put 
>  it in core.c.
> 
>  That said, I would still only honor this when called from v4l2, so I 
>  suggest that
>  a new flag 'check_waiting_for_buffers' is added that is only set in 
>  vb2_queue_init
>  in videobuf2-v4l2.c.
> 
>  So the test above becomes:
> 
>   if (q->check_waiting_for_buffers && q->waiting_for_buffers &&
>   (req_events & (POLLIN | POLLRDNORM)))
> 
>  It's not ideal, but at least this keeps this v4l2 specific.
> >>>
> >>> I don't like the above approach, for two reasons:
> >>>
> >>> 1) it is not obvious that this is V4L2 specific from the code;
> >>
> >> s/check_waiting_for_buffers/v4l2_needs_to_wait_for_buffers/  
> >
> > Better, but still hell of a hack. Maybe we could add a quirks
> > flag and add a flag like:
> > VB2_FLAG_ENABLE_POLLERR_IF_WAITING_BUFFERS_AND_NO_QBUF
> > (or some better naming, I'm not inspired today...)
> >
> > Of course, such quirk should be properly documented.  
> 
>  How about 'quirk_poll_must_check_waiting_for_buffers'? Something with 
>  'quirk' in the
>  name is a good idea.
> >>>
> >>> works for me, provided that we add the field as a flag. So it would be 
> >>> like:
> >>>
> >>> #define QUIRK_POLL_MUST_CHECK_WAITING_FOR_BUFFERS 0
> >>>
> >>>   if (test_bit(q->quirk, QUIRK_POLL_MUST_CHECK_WAITING_FOR_BUFFERS) &&
> >>>   q->waiting_for_buffers && (req_events & (POLLIN | POLLRDNORM)))
> >>
> >> Why should it be a flag? What is wrong with a bitfield?
> >>
> >> Just curious what the reasoning is for that. I don't see any obvious
> >> advantage of a flag over a bitfield.  
> > 
> > Huh? Flags are implemented as bitfields. See 

[PATCH v7 2/6] GCC plugin infrastructure

2016-04-22 Thread Emese Revfy
This patch allows to build the whole kernel with GCC plugins. It was ported from
grsecurity/PaX. The infrastructure supports building out-of-tree modules and
building in a separate directory. Cross-compilation is supported too but
currently only the x86 architecture enables plugins.

The directory of the gcc plugins is tools/gcc. You can use a file or a directory
there. The plugins compile with these options:
 * -fno-rtti: gcc is compiled with this option so the plugins must use it too
 * -fno-exceptions: this is inherited from gcc too
 * -fasynchronous-unwind-tables: this is inherited from gcc too
 * -ggdb: it is useful for debugging a plugin (better backtrace on internal
errors)
 * -Wno-narrowing: to suppress warnings from gcc headers (ipa-utils.h)
 * -Wno-unused-variable: to suppress warnings from gcc headers (gcc_version
variable, plugin-version.h)

The infrastructure introduces a new Makefile target called gcc-plugins. It
supports all gcc versions from 4.5 to 6.0. The scripts/gcc-plugin.sh script
chooses the proper host compiler (gcc-4.7 can be built by either gcc or g++).
This script also checks the availability of the included headers in
tools/gcc/gcc-common.h.

The gcc-common.h header contains frequently included headers for GCC plugins
and it has a compatibility layer for the supported gcc versions.

The gcc-generate-*-pass.h headers automatically generate the registration
structures for GIMPLE, SIMPLE_IPA, IPA and RTL passes.

Note that 'make clean' keeps the *.so files (only the distclean or mrproper
targets clean all) because they are needed for out-of-tree modules.

Signed-off-by: Emese Revfy 
---
 Documentation/dontdiff |   1 +
 MAINTAINERS|   8 +
 Makefile   |  17 +-
 arch/Kconfig   |  13 +
 arch/x86/Kconfig   |   1 +
 arch/x86/entry/vdso/Makefile   |   3 +-
 scripts/Makefile   |   2 +-
 scripts/Makefile.gcc-plugins   |  20 +
 scripts/gcc-plugin.sh  |  51 ++
 scripts/gcc-plugins/Makefile   |  15 +
 scripts/gcc-plugins/gcc-common.h   | 830 +
 scripts/gcc-plugins/gcc-generate-gimple-pass.h | 175 +
 scripts/gcc-plugins/gcc-generate-ipa-pass.h| 289 +++
 scripts/gcc-plugins/gcc-generate-rtl-pass.h| 175 +
 scripts/gcc-plugins/gcc-generate-simple_ipa-pass.h | 175 +
 scripts/link-vmlinux.sh|   2 +-
 scripts/package/builddeb   |   1 +
 17 files changed, 1772 insertions(+), 6 deletions(-)
 create mode 100644 scripts/Makefile.gcc-plugins
 create mode 100755 scripts/gcc-plugin.sh
 create mode 100644 scripts/gcc-plugins/Makefile
 create mode 100644 scripts/gcc-plugins/gcc-common.h
 create mode 100644 scripts/gcc-plugins/gcc-generate-gimple-pass.h
 create mode 100644 scripts/gcc-plugins/gcc-generate-ipa-pass.h
 create mode 100644 scripts/gcc-plugins/gcc-generate-rtl-pass.h
 create mode 100644 scripts/gcc-plugins/gcc-generate-simple_ipa-pass.h

diff --git a/Documentation/dontdiff b/Documentation/dontdiff
index 8ea834f..5385cba 100644
--- a/Documentation/dontdiff
+++ b/Documentation/dontdiff
@@ -3,6 +3,7 @@
 *.bc
 *.bin
 *.bz2
+*.c.[012]*.*
 *.cis
 *.cpio
 *.csp
diff --git a/MAINTAINERS b/MAINTAINERS
index e12a27c..de91d6c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4777,6 +4777,14 @@ L:   linux-s...@vger.kernel.org
 S: Odd Fixes (e.g., new signatures)
 F: drivers/scsi/fdomain.*
 
+GCC PLUGINS
+M: Kees Cook 
+R: Emese Revfy 
+L: kernel-harden...@lists.openwall.com
+S: Maintained
+F: scripts/gcc-plugins/
+F: Documentation/gcc-plugins.txt
+
 GCOV BASED KERNEL PROFILING
 M: Peter Oberparleiter 
 S: Maintained
diff --git a/Makefile b/Makefile
index c3937c5..22f0e1b 100644
--- a/Makefile
+++ b/Makefile
@@ -418,6 +418,8 @@ export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE 
KBUILD_LDFLAGS_MODULE
 export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL
 export KBUILD_ARFLAGS
 
+export PLUGINCC GCC_PLUGINS_CFLAGS
+
 # When compiling out-of-tree modules, put MODVERDIR in the module
 # tree rather than in the kernel tree. The kernel tree might
 # even be read-only.
@@ -548,7 +550,7 @@ ifeq ($(KBUILD_EXTMOD),)
 # in parallel
 PHONY += scripts
 scripts: scripts_basic include/config/auto.conf include/config/tristate.conf \
-asm-generic
+asm-generic gcc-plugins
$(Q)$(MAKE) $(build)=$(@)
 
 # Objects we will link into vmlinux / subdirs we need to visit
@@ -623,6 +625,15 @@ endif
 # Tell gcc to never replace conditional load with a non-conditional one
 KBUILD_CFLAGS  += $(call cc-option,--param=allow-store-data-races=0)
 
+PHONY += gcc-plugins

[PATCH v7 3/6] The GCC plugin infrastructure supports the arm and arm64 architectures too

2016-04-22 Thread Emese Revfy
The GCC plugin infrastructure supports the arm and arm64 architectures too

Signed-off-by: David Brown 
---
 arch/arm/Kconfig   | 1 +
 arch/arm64/Kconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0846026..8f57eb6 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -55,6 +55,7 @@ config ARM
select HAVE_FUNCTION_GRAPH_TRACER if (!THUMB2_KERNEL)
select HAVE_FUNCTION_TRACER if (!XIP_KERNEL)
select HAVE_GENERIC_DMA_COHERENT
+   select HAVE_GCC_PLUGINS
select HAVE_HW_BREAKPOINT if (PERF_EVENTS && (CPU_V6 || CPU_V6K || 
CPU_V7))
select HAVE_IDE if PCI || ISA || PCMCIA
select HAVE_IRQ_TIME_ACCOUNTING
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index c8762f4..33f30f6 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -76,6 +76,7 @@ config ARM64
select HAVE_FTRACE_MCOUNT_RECORD
select HAVE_FUNCTION_TRACER
select HAVE_FUNCTION_GRAPH_TRACER
+   select HAVE_GCC_PLUGINS
select HAVE_GENERIC_DMA_COHERENT
select HAVE_HW_BREAKPOINT if PERF_EVENTS
select HAVE_IRQ_TIME_ACCOUNTING
-- 
2.4.1



Re: [PATCH v6 00/20] kthread: Use kthread worker API more widely

2016-04-22 Thread Tejun Heo
Hello, Petr.

On Thu, Apr 14, 2016 at 05:14:19PM +0200, Petr Mladek wrote:
> My intention is to make it easier to manipulate and maintain kthreads.
> Especially, I want to replace all the custom main cycles with a
> generic one. Also I want to make the kthreads sleep in a consistent
> state in a common place when there is no work.
> 
> My first attempt was with a brand new API (iterant kthread), see
> http://thread.gmane.org/gmane.linux.kernel.api/11892 . But I was
> directed to improve the existing kthread worker API. This is
> the 4th iteration of the new direction.
> 
> 1nd..10th patches: improve the existing kthread worker API

I glanced over them and they generally look good to me.  Let's see how
people respond to actual conversions.

Thanks.

-- 
tejun


[PATCH 0/4] MIPS: Guest timekeeping improvements

2016-04-22 Thread James Hogan
These patches improve timekeeping of MIPS/Malta kernels running in a KVM
guest.

Patch 2 fixes malta frequency calculation under virtualisation,
especially on very slow targets (FPGA / emulators). Patch 1 is a minor
fix for something I noticed while writing patch 2.

Patch 3 drops the use of the PIT timer for Malta, which is slow to
emulate with KVM + QEMU.

Finally patch 4 calculates min_delta_ns of cevt-r4k dynamically to
handle virtualised environments with software emulated Count/Compare,
and where Count frequency may not be directly related to actual CPU
speed (and so the static value of 0x300 may be no good).

James Hogan (4):
  MIPS: malta-time: Start GIC count before syncing to RTC
  MIPS: malta-time: Take seconds into account
  MIPS: malta-time: Don't use PIT timer for cevt/csrc
  MIPS: cevt-r4k: Dynamically calculate min_delta_ns

 arch/mips/Kconfig|  1 -
 arch/mips/kernel/cevt-r4k.c  | 82 +++-
 arch/mips/mti-malta/malta-time.c | 50 +++-
 3 files changed, 113 insertions(+), 20 deletions(-)

Cc: Ralf Baechle 
Cc: Daniel Lezcano 
Cc: Thomas Gleixner 
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
-- 
2.4.10



[PATCH V3 00/18] coresight: tmc: make driver usable by Perf

2016-04-22 Thread Mathieu Poirier
This patchset makes the TMC driver usable from Perf by way of the
recently added AUX area functionality.  Note that only the kernel
side of the operation is presented here.  The user space perf tool
enhancement are kept here[1].  Upstreaming of that portion will 
follow when the kernel side has been addressed.

The first 15 patches remodel the driver so that the functionality
is compartmented enough to be used as building blocks when interfacing
with the Perf subsystem.

Patch 16 and 17 implement the AUX area API, taking heavily on the existing
ETB10 implementation.

Finally patch 18 allows the TMC to be used as a link rather than a sink,
something that is required when dealing with an ETF component.

Best regards,
Mathieu

[1]. 
https://git.linaro.org/people/mathieu.poirier/coresight.git/shortlog/refs/heads/perf-opencsd-4.6-rc2

Changes for V3:
- Reworked drvdata::memwidth assignment.
- cleaned up coresight-tmc.h header file.
- Added WARN_ON[_ONCE]() on error paths.
- Added missing spinlock release.
- Using a type 'long' when dealing with local_[cmp]xchg()
- Added Suzuki K Poulose's Reviewed-by.

Changes for V2:
- Renamed functions tmc_read_prepare/unprepare_etf() to 
  tmc_read_prepare/unprepare_etb().
- Consolidated return points in functions tmc_enable_etf/etr_sink().
- Re-wrote allocation schemed in functions tmc_enable_etf/etr_sink().
- Fixed description typos in patch 7/15.
- Fixed problem with linksink devices when disabling a path in patch 15/15.

Mathieu Poirier (18):
  coresight: tmc: modifying naming convention
  coresight: tmc: waiting for TMCReady bit before programming
  coresight: tmc: re-implementing tmc_read_prepare/unprepare() functions
  coresight: tmc: clearly define number of transfers per burst
  coresight: tmc: introducing new header file
  coresight: tmc: cleaning up header file
  coresight: tmc: splitting driver in ETB/ETF and ETR components
  coresight: tmc: making prepare/unprepare functions generic
  coresight: tmc: allocating memory when needed
  coresight: tmc: getting the right read_count on tmc_open()
  coresight: tmc: adding mode of operation for link/sinks
  coresight: tmc: dump system memory content only when needed
  coresight: tmc: make sysFS and Perf mode mutually exclusive
  coresight: tmc: keep track of memory width
  coresight: moving struct cs_buffers to header file
  coresight: tmc: implementing TMC-ETF AUX space API
  coresight: tmc: implementing TMC-ETR AUX space API
  coresight: configuring ETF in FIFO mode when acting as link

 drivers/hwtracing/coresight/Makefile|   4 +-
 drivers/hwtracing/coresight/coresight-etb10.c   |  20 -
 drivers/hwtracing/coresight/coresight-priv.h|  20 +
 drivers/hwtracing/coresight/coresight-tmc-etf.c | 603 
 drivers/hwtracing/coresight/coresight-tmc-etr.c | 469 ++
 drivers/hwtracing/coresight/coresight-tmc.c | 485 +++
 drivers/hwtracing/coresight/coresight-tmc.h | 145 ++
 drivers/hwtracing/coresight/coresight.c |  32 +-
 8 files changed, 1339 insertions(+), 439 deletions(-)
 create mode 100644 drivers/hwtracing/coresight/coresight-tmc-etf.c
 create mode 100644 drivers/hwtracing/coresight/coresight-tmc-etr.c
 create mode 100644 drivers/hwtracing/coresight/coresight-tmc.h

-- 
2.5.0



[PATCH] powercap/intel_rapl: Add support for Kabylake

2016-04-22 Thread Jacob Pan
Kabylake is similar to Skylake in terms of RAPL.

Signed-off-by: Jacob Pan 
---
 drivers/powercap/intel_rapl.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c
index 8fad0a7..470bb62 100644
--- a/drivers/powercap/intel_rapl.c
+++ b/drivers/powercap/intel_rapl.c
@@ -1101,6 +1101,8 @@ static const struct x86_cpu_id rapl_ids[] __initconst = {
RAPL_CPU(0X5C, rapl_defaults_core),/* Broxton */
RAPL_CPU(0x5E, rapl_defaults_core),/* Skylake-H/S */
RAPL_CPU(0x57, rapl_defaults_hsw_server),/* Knights Landing */
+   RAPL_CPU(0x8E, rapl_defaults_core),/* Kabylake */
+   RAPL_CPU(0x9E, rapl_defaults_core),/* Kabylake */
{}
 };
 MODULE_DEVICE_TABLE(x86cpu, rapl_ids);
-- 
1.9.1



[PATCH V3 01/18] coresight: tmc: modifying naming convention

2016-04-22 Thread Mathieu Poirier
According to the TMC architectural state machine, the 'stopped'
state is reached when bit 2 (TMCReady) of the TMC Status register
turns to '1'.  The code is correct but the naming convention isn't.

The 'Triggered' bit occupies position '1' of the TMC Status register
and has nothing to do with the indication of the TMC entering the
stopped state. As such renaming function "tmc_wait_for_triggered()"
and changing the #define to reflect what the code is really doing.

This patch has no effect other than clarifying the semantic.

Signed-off-by: Mathieu Poirier 
Reviewed-by: Suzuki K Poulose 
---
 drivers/hwtracing/coresight/coresight-tmc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-tmc.c 
b/drivers/hwtracing/coresight/coresight-tmc.c
index 2b42ecbd8831..3f646e29a99b 100644
--- a/drivers/hwtracing/coresight/coresight-tmc.c
+++ b/drivers/hwtracing/coresight/coresight-tmc.c
@@ -77,7 +77,7 @@
 #define TMC_FFCR_TRIGON_TRIGIN BIT(8)
 #define TMC_FFCR_STOP_ON_FLUSH BIT(12)
 
-#define TMC_STS_TRIGGERED_BIT  2
+#define TMC_STS_TMCREADY_BIT   2
 #define TMC_FFCR_FLUSHMAN_BIT  6
 
 enum tmc_config_type {
@@ -132,11 +132,11 @@ struct tmc_drvdata {
u32 trigger_cntr;
 };
 
-static void tmc_wait_for_ready(struct tmc_drvdata *drvdata)
+static void tmc_wait_for_tmcready(struct tmc_drvdata *drvdata)
 {
/* Ensure formatter, unformatter and hardware fifo are empty */
if (coresight_timeout(drvdata->base,
- TMC_STS, TMC_STS_TRIGGERED_BIT, 1)) {
+ TMC_STS, TMC_STS_TMCREADY_BIT, 1)) {
dev_err(drvdata->dev,
"timeout observed when probing at offset %#x\n",
TMC_STS);
@@ -160,7 +160,7 @@ static void tmc_flush_and_stop(struct tmc_drvdata *drvdata)
TMC_FFCR);
}
 
-   tmc_wait_for_ready(drvdata);
+   tmc_wait_for_tmcready(drvdata);
 }
 
 static void tmc_enable_hw(struct tmc_drvdata *drvdata)
-- 
2.5.0



Re: [git pull] drm fixes

2016-04-22 Thread Linus Torvalds
On Fri, Apr 22, 2016 at 10:23 AM, Daniel Vetter  wrote:
>
> Works all fine here, http, ssh & git protocols all up well.
> Maybe temporary, or just your part of the interwebs fell off?

It's up for me now too, so something temporary. I don't think it was
at my end, everything else seemed to work fine and be reachable..

Maybe it was going through a reboot and I was just unlucky with timing.

  Linus


Re: linux-next: Tree for Apr 22 (adjust_autoksyms.sh)

2016-04-22 Thread Nicolas Pitre
On Fri, 22 Apr 2016, Randy Dunlap wrote:

> on x86_64:
> 
> I'm seeing:
> 
> /bin/sh: scripts/adjust_autoksyms.sh: No such file or directory
> /local/lnx/next/linux-next-20160422/Makefile:937: recipe for target 'vmlinux' 
> failed
> 
> when using O=subdir for the build output directory.
> 
> 
> Is there a missing $(objtree) somewhere?

Rather a $(srctree).  Please try the patch below.

- >8

Subject: [PATCH] kbuild: fix CONFIG_TRIM_UNUSED_KSYMS=y with a separate output  
directory

This fixes the following:

/bin/sh: scripts/adjust_autoksyms.sh: No such file or directory

Signed-off-by: Nicolas Pitre <n...@linaro.org>

diff --git a/Makefile b/Makefile
index e3af48068c..e9ad498238 100644
--- a/Makefile
+++ b/Makefile
@@ -934,7 +934,7 @@ quiet_cmd_link-vmlinux = LINK$@
 # execute if the rest of the kernel build went well.
 vmlinux: scripts/link-vmlinux.sh $(vmlinux-deps) FORCE
 ifdef CONFIG_TRIM_UNUSED_KSYMS
-   $(Q)$(CONFIG_SHELL) scripts/adjust_autoksyms.sh \
+   $(Q)$(CONFIG_SHELL) $(srctree)/scripts/adjust_autoksyms.sh \
  "$(MAKE) KBUILD_MODULES=1 -f $(srctree)/Makefile autoksyms_recursive"
 endif
 ifdef CONFIG_HEADERS_CHECK
@@ -949,13 +949,13 @@ endif
+$(call if_changed,link-vmlinux)
 
 autoksyms_recursive: $(vmlinux-deps)
-   $(Q)$(CONFIG_SHELL) scripts/adjust_autoksyms.sh \
+   $(Q)$(CONFIG_SHELL) $(srctree)/scripts/adjust_autoksyms.sh \
  "$(MAKE) KBUILD_MODULES=1 -f $(srctree)/Makefile autoksyms_recursive"
 PHONY += autoksyms_recursive
 
 # standalone target for easier testing
 include/generated/autoksyms.h: FORCE
-   $(Q)$(CONFIG_SHELL) scripts/adjust_autoksyms.sh true
+   $(Q)$(CONFIG_SHELL) $(srctree)/scripts/adjust_autoksyms.sh true
 
 # Build samples along the rest of the kernel
 ifdef CONFIG_SAMPLES


[PATCH 2/4] sh: make mm/asids-debugfs explicitly non-modular

2016-04-22 Thread Paul Gortmaker
The Makefile/Kconfig currently controlling compilation of this code is:

obj-$(CONFIG_DEBUG_FS)  += $(debugfs-y)
debugfs-y   := asids-debugfs.o

lib/Kconfig.debug:config DEBUG_FS
lib/Kconfig.debug:  bool "Debug Filesystem"

...meaning that it currently is not being built as a module by anyone.

Lets remove the couple traces of modular code, so that when reading the
driver there is no doubt it is builtin-only.

Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit.

Cc: Yoshinori Sato 
Cc: Rich Felker 
Cc: linux...@vger.kernel.org
Signed-off-by: Paul Gortmaker 
---
 arch/sh/mm/asids-debugfs.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/sh/mm/asids-debugfs.c b/arch/sh/mm/asids-debugfs.c
index ecfc6b0c1da1..bf95fdaedd0c 100644
--- a/arch/sh/mm/asids-debugfs.c
+++ b/arch/sh/mm/asids-debugfs.c
@@ -17,7 +17,6 @@
  * for more details.
  */
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -70,6 +69,4 @@ static int __init asids_debugfs_init(void)
 
return PTR_ERR_OR_ZERO(asids_dentry);
 }
-module_init(asids_debugfs_init);
-
-MODULE_LICENSE("GPL v2");
+device_initcall(asids_debugfs_init);
-- 
2.8.0



Re: [PATCH v3] prism54: isl_38xx: Replace 'struct timeval'

2016-04-22 Thread Kalle Valo
Johannes Berg  writes:

> On Mon, 2016-04-18 at 00:10 +0200, Arnd Bergmann wrote:
>> On Sunday 17 April 2016 14:42:33 Johannes Berg wrote:
>> > 
>> > I was thinking more restrictively of just the stuff that can't even
>> > be built without modifying the sources - like the "#if VERBOSE"
>> > thing.
>>
>> All the DEBUG() statements are inside of this kind of check, so if we
>> remove the #ifdefs, it would be logical to remove the rest of the
>> debugging infrastructure (DEBUG() macros, SHOW_*, pc_debug, maybe
>> more) as well.
>
> Seems reasonable.
>
> Maybe we should Cc the maintainer, but I suspect that since the driver
> is marked Obsolete anyway Luis won't care either :)

I'm planning to apply this patch anyway, the debugging infrastructure
removal can be a followup patch. But please let me know if I should drop
this instead.

-- 
Kalle Valo


[PATCH 1/4] sh: make time.c explicitly non-modular

2016-04-22 Thread Paul Gortmaker
The Makefile currently controlling compilation of this code is:

obj-y   := debugtraps.o dma-nommu.o dumpstack.o \
[...]
   syscalls_$(BITS).o time.o topology.o traps.o \
   traps_$(BITS).o unwinder.o

...meaning that it currently is not being built as a module by anyone.

Lets remove the couple traces of modular code, so that when reading
the driver there is no doubt it is builtin-only.

Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit.

Cc: Yoshinori Sato 
Cc: Rich Felker 
Cc: Paul Gortmaker 
Cc: linux...@vger.kernel.org
Signed-off-by: Paul Gortmaker 
---
 arch/sh/kernel/time.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/sh/kernel/time.c b/arch/sh/kernel/time.c
index d6d0a986c6e9..bfe1de98d003 100644
--- a/arch/sh/kernel/time.c
+++ b/arch/sh/kernel/time.c
@@ -11,7 +11,6 @@
  * for more details.
  */
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -83,7 +82,7 @@ static int __init rtc_generic_init(void)
 
return PTR_ERR_OR_ZERO(pdev);
 }
-module_init(rtc_generic_init);
+device_initcall(rtc_generic_init);
 
 void (*board_time_init)(void);
 
-- 
2.8.0



Re: [tip:x86/asm] x86/mm/xen: Suppress hugetlbfs in PV guests

2016-04-22 Thread Borislav Petkov
On Fri, Apr 22, 2016 at 11:03:53AM -0700, H. Peter Anvin wrote:
> Please don't use the cpu_has_* macros anymore, they are going away soon.
> 
> In this case it should be static_cpu_has(X86_FEATURE_PSE).

Ingo fixed this up while merging:

b2eafe890d4a ("Merge branch 'x86/urgent' into x86/asm, to fix semantic 
conflict")

The cpu_has_* things are gone now in tip! \o/

:-)

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.


[GIT PULL] pin control fixes for v4.6 take three

2016-04-22 Thread Linus Walleij
Hi Linus,

some pin control driver fixes came in. One headed for stable
and the other two are just ordinary merge window fixes.

Details in the tag and commits.

Please pull it in.

Yours,
Linus Walleij

The following changes since commit bf16200689118d19de1b8d2a3c314fc21f5dc7bb:

  Linux 4.6-rc3 (2016-04-10 17:58:30 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git
tags/pinctrl-v4.6-3

for you to fetch changes up to 56b367c0cd67d4c3006738e7dc9dda9273fd2bfe:

  pinctrl: single: Fix pcs_parse_bits_in_pinctrl_entry to use __ffs
than ffs (2016-04-15 11:26:55 +0200)


Pin control fixes for the v4.6 series:
- Make the i.MX driver select REGMAP as a dependency
- Fix up the Mediatek debounce time unit
- Fix a real hairy ffs vs __ffs issue in the Single pinctrl driver


Alexander Kurz (1):
  pinctrl: imx: Kconfig: PINCTRL_IMX select REGMAP

Keerthy (1):
  pinctrl: single: Fix pcs_parse_bits_in_pinctrl_entry to use __ffs than ffs

Yingjoe Chen (1):
  pinctrl: mediatek: correct debounce time unit in mtk_gpio_set_debounce

 drivers/pinctrl/freescale/Kconfig | 1 +
 drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 9 +
 drivers/pinctrl/pinctrl-single.c  | 6 +++---
 3 files changed, 9 insertions(+), 7 deletions(-)


Re: [PATCH] irqdomain: fix compare_const_fl.cocci warnings

2016-04-22 Thread Jon Hunter

On 20/04/16 17:49, Julia Lawall wrote:
>  Move constants to the right of binary operators.
> 
> Generated by: scripts/coccinelle/misc/compare_const_fl.cocci
> 
> Signed-off-by: Fengguang Wu 
> Signed-off-by: Julia Lawall 
> ---
> 
> Not a big deal, but the transformed code looks better to me.
> 
>  irqdomain.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -618,7 +618,7 @@ unsigned int irq_create_fwspec_mapping(s
>* If the trigger type has not been set yet, then set
>* it now and return the interrupt number.
>*/
> - if (IRQ_TYPE_NONE == irq_get_trigger_type(virq)) {
> + if (irq_get_trigger_type(virq) == IRQ_TYPE_NONE) {
>   irq_set_irq_type(virq, type);
>   return virq;
>   }

What branch is this from? Looks very familiar and related to some
changes I have been working on, but in my latest version I already have
this as shown above [0].

Cheers
Jon

[0] http://marc.info/?l=linux-tegra=146115064322071=2



Re: [PATCH V4] irq: Track the interrupt timings

2016-04-22 Thread Daniel Lezcano
On Wed, Apr 13, 2016 at 01:05:56PM +0200, Daniel Lezcano wrote:
> The interrupt framework gives a lot of information about each interrupt.
> 
> It does not keep track of when those interrupts occur though.
> 
> This patch provides a mean to record the elapsed time between successive
> interrupt occurrences in a per-IRQ per-CPU circular buffer to help with the
> prediction of the next occurrence using a statistical model.
> 
> A new function is added to browse the different interrupts and retrieve the
> timing information stored in it.
> 
> A static key is introduced so when the irq prediction is switched off at
> runtime, we can reduce the overhead near to zero. The irq timings is
> supposed to be potentially used by different sub-systems and for this reason
> the static key is a ref counter, so when the last use releases the irq
> timings that will result on the effective deactivation of the irq measurement.
> 
> Signed-off-by: Daniel Lezcano 
> Acked-by: Nicolas Pitre 
> ---
> V4:
>   - Added a static key
>   - Added more comments for irq_timings_get_next()
>   - Unified some function names to be prefixed by 'irq_timings_...'
>   - Fixed a rebase error
> V3:
>   - Replaced ktime_get() by local_clock()
>   - Shared irq are not handled
>   - Simplified code by adding the timing in the irqdesc struct
>   - Added a function to browse the irq timings
> V2:
>   - Fixed kerneldoc comment
>   - Removed data field from the struct irq timing
>   - Changed the lock section comment
>   - Removed semi-colon style with empty stub
>   - Replaced macro by static inline
>   - Fixed static functions declaration
> RFC:
>   - initial posting
> ---

Hi Thomas,

do you think this patch is acceptable ?


Re: linux-next: Tree for Apr 22 (adjust_autoksyms.sh)

2016-04-22 Thread Randy Dunlap
On 04/22/16 10:48, Nicolas Pitre wrote:
> On Fri, 22 Apr 2016, Randy Dunlap wrote:
> 
>> on x86_64:
>>
>> I'm seeing:
>>
>> /bin/sh: scripts/adjust_autoksyms.sh: No such file or directory
>> /local/lnx/next/linux-next-20160422/Makefile:937: recipe for target 
>> 'vmlinux' failed
>>
>> when using O=subdir for the build output directory.
>>
>>
>> Is there a missing $(objtree) somewhere?
> 
> Rather a $(srctree).  Please try the patch below.

Hi,

Yes, this patch helps, but I think there is still a problem.
I think that trim needs to be done after CONFIG_BUILD_DOCSRC and possibly
after CONFIG_SAMPLES are built.  At least CONFIG_BUILD_DOCSRC seems to
cause this error:

Setup is 16508 bytes (padded to 16896 bytes).
System is 6125 kB
CRC 8aa70f94
Kernel: arch/x86/boot/bzImage is ready  (#9)
ERROR: "cn_del_callback" [Documentation/connector/cn_test.ko] undefined!
ERROR: "cn_add_callback" [Documentation/connector/cn_test.ko] undefined!
ERROR: "cn_netlink_send" [Documentation/connector/cn_test.ko] undefined!
../scripts/Makefile.modpost:91: recipe for target '__modpost' failed
make[2]: *** [__modpost] Error 1



If I'm reading it incorrectly, just yell at me. :)


> - >8
> 
> Subject: [PATCH] kbuild: fix CONFIG_TRIM_UNUSED_KSYMS=y with a separate 
> output  directory
> 
> This fixes the following:
> 
> /bin/sh: scripts/adjust_autoksyms.sh: No such file or directory
> 
> Signed-off-by: Nicolas Pitre <n...@linaro.org>
> 
> diff --git a/Makefile b/Makefile
> index e3af48068c..e9ad498238 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -934,7 +934,7 @@ quiet_cmd_link-vmlinux = LINK$@
>  # execute if the rest of the kernel build went well.
>  vmlinux: scripts/link-vmlinux.sh $(vmlinux-deps) FORCE
>  ifdef CONFIG_TRIM_UNUSED_KSYMS
> - $(Q)$(CONFIG_SHELL) scripts/adjust_autoksyms.sh \
> + $(Q)$(CONFIG_SHELL) $(srctree)/scripts/adjust_autoksyms.sh \
> "$(MAKE) KBUILD_MODULES=1 -f $(srctree)/Makefile autoksyms_recursive"
>  endif
>  ifdef CONFIG_HEADERS_CHECK
> @@ -949,13 +949,13 @@ endif
>   +$(call if_changed,link-vmlinux)
>  
>  autoksyms_recursive: $(vmlinux-deps)
> - $(Q)$(CONFIG_SHELL) scripts/adjust_autoksyms.sh \
> + $(Q)$(CONFIG_SHELL) $(srctree)/scripts/adjust_autoksyms.sh \
> "$(MAKE) KBUILD_MODULES=1 -f $(srctree)/Makefile autoksyms_recursive"
>  PHONY += autoksyms_recursive
>  
>  # standalone target for easier testing
>  include/generated/autoksyms.h: FORCE
> - $(Q)$(CONFIG_SHELL) scripts/adjust_autoksyms.sh true
> + $(Q)$(CONFIG_SHELL) $(srctree)/scripts/adjust_autoksyms.sh true
>  
>  # Build samples along the rest of the kernel
>  ifdef CONFIG_SAMPLES
> --


-- 
~Randy


[PATCH v7 0/6] Introduce GCC plugin infrastructure

2016-04-22 Thread Emese Revfy
This patch set introduce the GCC plugin infrastructure with examples for testing
and documentation.

GCC plugins are loadable modules that provide extra features to the compiler.
They are useful for runtime instrumentation and static analysis.

The infrastructure supports all gcc versions from 4.5 to 6.0, building
out-of-tree modules and building in a separate directory. Cross-compilation
is supported too but currently only the x86, arm and arm64 architectures 
enables plugins.

This infrastructure was ported from grsecurity/PaX. It is a CII project
supported by the Linux Foundation.

Emese Revfy (6):
 Shared library support
 GCC plugin infrastructure
 The GCC plugin infrastructure supports the arm and arm64 architectures too
 Add Cyclomatic complexity plugin
 Documentations of the GCC plugin infrastructre
 Add sancov plugin


Changes from v6:
 * Disable the sancov plugin whenever KCOV_INSTRUMENT is disabled
(Reported-by: Huang Ying )
 * Disable KCOV/sancov plugin because this is not a regular kernel code
(Reported-by: Huang Ying )
 * Removed unnecessary gcc plugin cflags
(Signed-off-by: Masahiro Yamada )
 * Removed unnecessary gcc plugin aflags

Changes from v5:
 * Set important properties on the external fndecl (Add sancov plugin)
 * Revert documentation change too (Shared library support)
(Suggested-by: Kees Cook )
 * The GCC plugin infrastructure now supports the arm and arm64 architectures 
too
(Signed-off-by: David Brown )
 * Simplify the computation of PLUGINCC (GCC plugin infrastructure)
(Suggested-by: Masahiro Yamada )
 * Simplify the invocation of gcc-plugin.sh (GCC plugin infrastructure)
(Suggested-by: Masahiro Yamada )
 * Make use of multi-depend (Shared library support)
(Suggested-by: Masahiro Yamada )
 * Remove unnecessary exports (GCC plugin infrastructure)
(Suggested-by: Masahiro Yamada )
 * Simplify Makefile by using addprefix (GCC plugin infrastructure)
(Suggested-by: Masahiro Yamada )
 * Moved the gcc plugins from tools/ to scripts/ (GCC plugin infrastructure)
(Suggested-by: Masahiro Yamada )
 * Removed plugins from KBUILD_CFLAGS_32 (GCC plugin infrastructure)
 * Remove gcc-plugin target everywhere
(Suggested-by and partly Written-by: Masahiro Yamada 
)
 * There is no leaf gcc attribute in gcc-4.5 (Add sancov plugin)
 * Added support to the sancov plugin with kcov (Add sancov plugin)

Changes from v4:
 * Moved shared library support from the GCC plugin infrastructure patch into
   a different patch
 * Update gcc-*.h from PaX
   * Fixed gcc-common.h for gcc 6
   * Added pass cloning support to the gcc pass generators
 * Disable all plugins in vdso because it is userland code
 * Add sancov gcc plugin: another use case for gcc plugin support in the kernel
   is when there is a feature in the latest gcc version and we would like to use
   it with older gcc versions as well (e.g., distros).

Changes from v3:
 * Fix some indentation related warnings
   (Suggested by checkpatch.pl)
 * Add maintainer entries
 * Don't run gcc_plugin.sh when the GCC_PLUGINS option is disabled or 
unsupported
   (Reported-by: Fengguang Wu )

Changes from v2:
 * Fixed incorrectly encoded characters
 * Generate the GIMPLE, IPA, SIMPLE_IPA and RTL pass structures
   (Suggested-by: Rasmus Villemoes )
 * Write plugin related warning messages to stderr instead of stdout
   (Suggested-by: Kees Cook )
 * Mention the installation of the gcc plugin headers (Documentation)

Changes from v1:
 * Move the gcc-plugins make target into a separate Makefile because there may
   be a lot of plugins (Suggested-by: Rasmus Villemoes)
 * Simplify the dependencies of the plugin related config option
   (Suggested-by: Kees Cook )
 * Removed the unnecessary example plugin

---
 Documentation/dontdiff |   1 +
 Documentation/gcc-plugins.txt  |  83 +++
 Documentation/kbuild/makefiles.txt |  39 +-
 Documentation/kernel-parameters.txt|   5 +
 MAINTAINERS|   8 +
 Makefile   |  25 +-
 arch/Kconfig   |  36 +
 arch/arm/Kconfig   |   1 +
 arch/arm64/Kconfig |   1 +
 arch/x86/Kconfig   |   1 +
 arch/x86/entry/vdso/Makefile   |   3 +-
 arch/x86/purgatory/Makefile|   2 +
 lib/Kconfig.debug  |   2 +
 

[PATCH V3 14/18] coresight: tmc: keep track of memory width

2016-04-22 Thread Mathieu Poirier
Accessing the HW configuration register each time the memory
width is needed simply doesn't make sense.  It is much more
efficient to read the value once and keep a reference for
later use.

Signed-off-by: Mathieu Poirier 
---
 drivers/hwtracing/coresight/coresight-tmc-etf.c | 14 +-
 drivers/hwtracing/coresight/coresight-tmc.c | 34 +
 drivers/hwtracing/coresight/coresight-tmc.h | 10 +---
 3 files changed, 41 insertions(+), 17 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c 
b/drivers/hwtracing/coresight/coresight-tmc-etf.c
index cc88c15ba45c..981c5ca75e36 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
@@ -41,25 +41,13 @@ void tmc_etb_enable_hw(struct tmc_drvdata *drvdata)
 
 static void tmc_etb_dump_hw(struct tmc_drvdata *drvdata)
 {
-   enum tmc_mem_intf_width memwidth;
-   u8 memwords;
char *bufp;
u32 read_data;
int i;
 
-   memwidth = BMVAL(readl_relaxed(drvdata->base + CORESIGHT_DEVID), 8, 10);
-   if (memwidth == TMC_MEM_INTF_WIDTH_32BITS)
-   memwords = 1;
-   else if (memwidth == TMC_MEM_INTF_WIDTH_64BITS)
-   memwords = 2;
-   else if (memwidth == TMC_MEM_INTF_WIDTH_128BITS)
-   memwords = 4;
-   else
-   memwords = 8;
-
bufp = drvdata->buf;
while (1) {
-   for (i = 0; i < memwords; i++) {
+   for (i = 0; i < drvdata->memwidth; i++) {
read_data = readl_relaxed(drvdata->base + TMC_RRD);
if (read_data == 0x)
return;
diff --git a/drivers/hwtracing/coresight/coresight-tmc.c 
b/drivers/hwtracing/coresight/coresight-tmc.c
index 55806352b1f1..cb030a09659d 100644
--- a/drivers/hwtracing/coresight/coresight-tmc.c
+++ b/drivers/hwtracing/coresight/coresight-tmc.c
@@ -193,6 +193,39 @@ static const struct file_operations tmc_fops = {
.llseek = no_llseek,
 };
 
+static enum tmc_mem_intf_width tmc_get_memwidth(u32 devid)
+{
+   enum tmc_mem_intf_width memwidth;
+
+   /*
+* Excerpt from the TRM:
+*
+* DEVID::MEMWIDTH[10:8]
+* 0x2 Memory interface databus is 32 bits wide.
+* 0x3 Memory interface databus is 64 bits wide.
+* 0x4 Memory interface databus is 128 bits wide.
+* 0x5 Memory interface databus is 256 bits wide.
+*/
+   switch (BMVAL(devid, 8, 10)) {
+   case 0x2:
+   memwidth = TMC_MEM_INTF_WIDTH_32BITS;
+   break;
+   case 0x3:
+   memwidth = TMC_MEM_INTF_WIDTH_64BITS;
+   break;
+   case 0x4:
+   memwidth = TMC_MEM_INTF_WIDTH_128BITS;
+   break;
+   case 0x5:
+   memwidth = TMC_MEM_INTF_WIDTH_256BITS;
+   break;
+   default:
+   memwidth = 0;
+   }
+
+   return memwidth;
+}
+
 #define coresight_tmc_simple_func(name, offset)\
coresight_simple_func(struct tmc_drvdata, name, offset)
 
@@ -306,6 +339,7 @@ static int tmc_probe(struct amba_device *adev, const struct 
amba_id *id)
 
devid = readl_relaxed(drvdata->base + CORESIGHT_DEVID);
drvdata->config_type = BMVAL(devid, 6, 7);
+   drvdata->memwidth = tmc_get_memwidth(devid);
 
if (drvdata->config_type == TMC_CONFIG_TYPE_ETR) {
if (np)
diff --git a/drivers/hwtracing/coresight/coresight-tmc.h 
b/drivers/hwtracing/coresight/coresight-tmc.h
index 9b4c215d2b6b..12a097f3d06c 100644
--- a/drivers/hwtracing/coresight/coresight-tmc.h
+++ b/drivers/hwtracing/coresight/coresight-tmc.h
@@ -81,10 +81,10 @@ enum tmc_mode {
 };
 
 enum tmc_mem_intf_width {
-   TMC_MEM_INTF_WIDTH_32BITS   = 0x2,
-   TMC_MEM_INTF_WIDTH_64BITS   = 0x3,
-   TMC_MEM_INTF_WIDTH_128BITS  = 0x4,
-   TMC_MEM_INTF_WIDTH_256BITS  = 0x5,
+   TMC_MEM_INTF_WIDTH_32BITS   = 1,
+   TMC_MEM_INTF_WIDTH_64BITS   = 2,
+   TMC_MEM_INTF_WIDTH_128BITS  = 4,
+   TMC_MEM_INTF_WIDTH_256BITS  = 8,
 };
 
 /**
@@ -101,6 +101,7 @@ enum tmc_mem_intf_width {
  * @size:  @buf size.
  * @mode:  how this TMC is being used.
  * @config_type: TMC variant, must be of type @tmc_config_type.
+ * @memwidth:  width of the memory interface databus, in bytes.
  * @trigger_cntr: amount of words to store after a trigger.
  */
 struct tmc_drvdata {
@@ -117,6 +118,7 @@ struct tmc_drvdata {
u32 size;
local_t mode;
enum tmc_config_typeconfig_type;
+   enum tmc_mem_intf_width memwidth;
u32 trigger_cntr;
 };
 
-- 
2.5.0



[PATCH V3 08/18] coresight: tmc: making prepare/unprepare functions generic

2016-04-22 Thread Mathieu Poirier
Dealing with HW related matters in tmc_read_prepare/unprepare
becomes convoluted when many cases need to be handled distinctively.

As such moving processing related to HW setup to individual driver
files and keep the core driver generic.

Signed-off-by: Mathieu Poirier 
Reviewed-by: Suzuki K Poulose 
---
 drivers/hwtracing/coresight/coresight-tmc-etf.c | 62 -
 drivers/hwtracing/coresight/coresight-tmc-etr.c | 42 -
 drivers/hwtracing/coresight/coresight-tmc.c | 55 +-
 drivers/hwtracing/coresight/coresight-tmc.h |  8 ++--
 4 files changed, 117 insertions(+), 50 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c 
b/drivers/hwtracing/coresight/coresight-tmc-etf.c
index 467d19221f7b..91e43572ce9f 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
@@ -71,7 +71,7 @@ static void tmc_etb_dump_hw(struct tmc_drvdata *drvdata)
}
 }
 
-void tmc_etb_disable_hw(struct tmc_drvdata *drvdata)
+static void tmc_etb_disable_hw(struct tmc_drvdata *drvdata)
 {
CS_UNLOCK(drvdata->base);
 
@@ -202,3 +202,63 @@ const struct coresight_ops tmc_etf_cs_ops = {
.sink_ops   = _etf_sink_ops,
.link_ops   = _etf_link_ops,
 };
+
+int tmc_read_prepare_etb(struct tmc_drvdata *drvdata)
+{
+   enum tmc_mode mode;
+   int ret = 0;
+   unsigned long flags;
+
+   /* config types are set a boot time and never change */
+   if (WARN_ON_ONCE(drvdata->config_type != TMC_CONFIG_TYPE_ETB &&
+drvdata->config_type != TMC_CONFIG_TYPE_ETF))
+   return -EINVAL;
+
+   spin_lock_irqsave(>spinlock, flags);
+
+   /* There is no point in reading a TMC in HW FIFO mode */
+   mode = readl_relaxed(drvdata->base + TMC_MODE);
+   if (mode != TMC_MODE_CIRCULAR_BUFFER) {
+   ret = -EINVAL;
+   goto out;
+   }
+
+   /* Disable the TMC if need be */
+   if (drvdata->enable)
+   tmc_etb_disable_hw(drvdata);
+
+   drvdata->reading = true;
+out:
+   spin_unlock_irqrestore(>spinlock, flags);
+
+   return ret;
+}
+
+int tmc_read_unprepare_etb(struct tmc_drvdata *drvdata)
+{
+   enum tmc_mode mode;
+   unsigned long flags;
+
+   /* config types are set a boot time and never change */
+   if (WARN_ON_ONCE(drvdata->config_type != TMC_CONFIG_TYPE_ETB &&
+drvdata->config_type != TMC_CONFIG_TYPE_ETF))
+   return -EINVAL;
+
+   spin_lock_irqsave(>spinlock, flags);
+
+   /* There is no point in reading a TMC in HW FIFO mode */
+   mode = readl_relaxed(drvdata->base + TMC_MODE);
+   if (mode != TMC_MODE_CIRCULAR_BUFFER) {
+   spin_unlock_irqrestore(>spinlock, flags);
+   return -EINVAL;
+   }
+
+   /* Re-enable the TMC if need be */
+   if (drvdata->enable)
+   tmc_etb_enable_hw(drvdata);
+
+   drvdata->reading = false;
+   spin_unlock_irqrestore(>spinlock, flags);
+
+   return 0;
+}
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c 
b/drivers/hwtracing/coresight/coresight-tmc-etr.c
index 5d9333ec49ae..3483d139a4ac 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
@@ -70,7 +70,7 @@ static void tmc_etr_dump_hw(struct tmc_drvdata *drvdata)
drvdata->buf = drvdata->vaddr;
 }
 
-void tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
+static void tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
 {
CS_UNLOCK(drvdata->base);
 
@@ -126,3 +126,43 @@ static const struct coresight_ops_sink tmc_etr_sink_ops = {
 const struct coresight_ops tmc_etr_cs_ops = {
.sink_ops   = _etr_sink_ops,
 };
+
+int tmc_read_prepare_etr(struct tmc_drvdata *drvdata)
+{
+   unsigned long flags;
+
+   /* config types are set a boot time and never change */
+   if (WARN_ON_ONCE(drvdata->config_type != TMC_CONFIG_TYPE_ETR))
+   return -EINVAL;
+
+   spin_lock_irqsave(>spinlock, flags);
+
+   /* Disable the TMC if need be */
+   if (drvdata->enable)
+   tmc_etr_disable_hw(drvdata);
+
+   drvdata->reading = true;
+   spin_unlock_irqrestore(>spinlock, flags);
+
+   return 0;
+}
+
+int tmc_read_unprepare_etr(struct tmc_drvdata *drvdata)
+{
+   unsigned long flags;
+
+   /* config types are set a boot time and never change */
+   if (WARN_ON_ONCE(drvdata->config_type != TMC_CONFIG_TYPE_ETR))
+   return -EINVAL;
+
+   spin_lock_irqsave(>spinlock, flags);
+
+   /* RE-enable the TMC if need be */
+   if (drvdata->enable)
+   tmc_etr_enable_hw(drvdata);
+
+   drvdata->reading = false;
+   spin_unlock_irqrestore(>spinlock, flags);
+
+   return 0;
+}
diff --git a/drivers/hwtracing/coresight/coresight-tmc.c 

[PATCH V3 13/18] coresight: tmc: make sysFS and Perf mode mutually exclusive

2016-04-22 Thread Mathieu Poirier
The sysFS and Perf access methods can't be allowed to interfere
with one another.  As such introducing guards to access
functions that prevents moving forward if a TMC is already
being used.

Signed-off-by: Mathieu Poirier 
---
 drivers/hwtracing/coresight/coresight-tmc-etf.c | 60 +-
 drivers/hwtracing/coresight/coresight-tmc-etr.c | 68 +++--
 2 files changed, 121 insertions(+), 7 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c 
b/drivers/hwtracing/coresight/coresight-tmc-etf.c
index 25fad93b68d4..cc88c15ba45c 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
@@ -111,7 +111,7 @@ static void tmc_etf_disable_hw(struct tmc_drvdata *drvdata)
CS_LOCK(drvdata->base);
 }
 
-static int tmc_enable_etf_sink(struct coresight_device *csdev, u32 mode)
+static int tmc_enable_etf_sink_sysfs(struct coresight_device *csdev, u32 mode)
 {
bool used = false;
char *buf = NULL;
@@ -190,6 +190,54 @@ spin_unlock:
return 0;
 }
 
+static int tmc_enable_etf_sink_perf(struct coresight_device *csdev, u32 mode)
+{
+   int ret = 0;
+   long val;
+   unsigned long flags;
+   struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+/* This shouldn't be happening */
+   if (WARN_ON(mode != CS_MODE_PERF))
+   return -EINVAL;
+
+   spin_lock_irqsave(>spinlock, flags);
+   if (drvdata->reading) {
+   ret = -EINVAL;
+   goto out;
+   }
+
+   val = local_xchg(>mode, mode);
+   /*
+* In Perf mode there can be only one writer per sink.  There
+* is also no need to continue if the ETB/ETR is already operated
+* from sysFS.
+*/
+   if (val != CS_MODE_DISABLED) {
+   ret = -EINVAL;
+   goto out;
+   }
+
+   tmc_etb_enable_hw(drvdata);
+out:
+   spin_unlock_irqrestore(>spinlock, flags);
+
+   return ret;
+}
+
+static int tmc_enable_etf_sink(struct coresight_device *csdev, u32 mode)
+{
+   switch (mode) {
+   case CS_MODE_SYSFS:
+   return tmc_enable_etf_sink_sysfs(csdev, mode);
+   case CS_MODE_PERF:
+   return tmc_enable_etf_sink_perf(csdev, mode);
+   }
+
+   /* We shouldn't be here */
+   return -EINVAL;
+}
+
 static void tmc_disable_etf_sink(struct coresight_device *csdev)
 {
long val;
@@ -272,6 +320,7 @@ const struct coresight_ops tmc_etf_cs_ops = {
 
 int tmc_read_prepare_etb(struct tmc_drvdata *drvdata)
 {
+   long val;
enum tmc_mode mode;
int ret = 0;
unsigned long flags;
@@ -290,6 +339,13 @@ int tmc_read_prepare_etb(struct tmc_drvdata *drvdata)
goto out;
}
 
+   val = local_read(>mode);
+   /* Don't interfere if operated from Perf */
+   if (val == CS_MODE_PERF) {
+   ret = -EINVAL;
+   goto out;
+   }
+
/* If drvdata::buf is NULL the trace data has been read already */
if (drvdata->buf == NULL) {
ret = -EINVAL;
@@ -297,7 +353,7 @@ int tmc_read_prepare_etb(struct tmc_drvdata *drvdata)
}
 
/* Disable the TMC if need be */
-   if (local_read(>mode) == CS_MODE_SYSFS)
+   if (val == CS_MODE_SYSFS)
tmc_etb_disable_hw(drvdata);
 
drvdata->reading = true;
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c 
b/drivers/hwtracing/coresight/coresight-tmc-etr.c
index 4b000f4003a2..a9a94a09186a 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
@@ -87,7 +87,7 @@ static void tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
CS_LOCK(drvdata->base);
 }
 
-static int tmc_enable_etr_sink(struct coresight_device *csdev, u32 mode)
+static int tmc_enable_etr_sink_sysfs(struct coresight_device *csdev, u32 mode)
 {
bool used = false;
long val;
@@ -167,6 +167,54 @@ spin_unlock:
return 0;
 }
 
+static int tmc_enable_etr_sink_perf(struct coresight_device *csdev, u32 mode)
+{
+   int ret = 0;
+   long val;
+   unsigned long flags;
+   struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+/* This shouldn't be happening */
+   if (WARN_ON(mode != CS_MODE_PERF))
+   return -EINVAL;
+
+   spin_lock_irqsave(>spinlock, flags);
+   if (drvdata->reading) {
+   ret = -EINVAL;
+   goto out;
+   }
+
+   val = local_xchg(>mode, mode);
+   /*
+* In Perf mode there can be only one writer per sink.  There
+* is also no need to continue if the ETR is already operated
+* from sysFS.
+*/
+   if (val != CS_MODE_DISABLED) {
+   ret = -EINVAL;
+   goto out;
+   }
+
+   tmc_etr_enable_hw(drvdata);
+out:
+   

[PATCH V3 16/18] coresight: tmc: implementing TMC-ETF AUX space API

2016-04-22 Thread Mathieu Poirier
This patch implement the AUX area interfaces required to
use the TMC (configured as an ETF) from the Perf sub-system.

The heuristic is heavily borrowed from the ETB10 implementation.

Signed-off-by: Mathieu Poirier 
---
 drivers/hwtracing/coresight/coresight-tmc-etf.c | 198 
 drivers/hwtracing/coresight/coresight-tmc.h |   1 +
 2 files changed, 199 insertions(+)

diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c 
b/drivers/hwtracing/coresight/coresight-tmc-etf.c
index 981c5ca75e36..4f38e8d185bc 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
@@ -15,7 +15,9 @@
  * this program.  If not, see .
  */
 
+#include 
 #include 
+#include 
 #include 
 #include "coresight-priv.h"
 #include "coresight-tmc.h"
@@ -287,9 +289,205 @@ static void tmc_disable_etf_link(struct coresight_device 
*csdev,
dev_info(drvdata->dev, "TMC disabled\n");
 }
 
+static void *tmc_alloc_etf_buffer(struct coresight_device *csdev, int cpu,
+ void **pages, int nr_pages, bool overwrite)
+{
+   int node;
+   struct cs_buffers *buf;
+
+   if (cpu == -1)
+   cpu = smp_processor_id();
+   node = cpu_to_node(cpu);
+
+   /* Allocate memory structure for interaction with Perf */
+   buf = kzalloc_node(sizeof(struct cs_buffers), GFP_KERNEL, node);
+   if (!buf)
+   return NULL;
+
+   buf->snapshot = overwrite;
+   buf->nr_pages = nr_pages;
+   buf->data_pages = pages;
+
+   return buf;
+}
+
+static void tmc_free_etf_buffer(void *config)
+{
+   struct cs_buffers *buf = config;
+
+   kfree(buf);
+}
+
+static int tmc_set_etf_buffer(struct coresight_device *csdev,
+ struct perf_output_handle *handle,
+ void *sink_config)
+{
+   int ret = 0;
+   unsigned long head;
+   struct cs_buffers *buf = sink_config;
+
+   /* wrap head around to the amount of space we have */
+   head = handle->head & ((buf->nr_pages << PAGE_SHIFT) - 1);
+
+   /* find the page to write to */
+   buf->cur = head / PAGE_SIZE;
+
+   /* and offset within that page */
+   buf->offset = head % PAGE_SIZE;
+
+   local_set(>data_size, 0);
+
+   return ret;
+}
+
+static unsigned long tmc_reset_etf_buffer(struct coresight_device *csdev,
+ struct perf_output_handle *handle,
+ void *sink_config, bool *lost)
+{
+   long size = 0;
+   struct cs_buffers *buf = sink_config;
+
+   if (buf) {
+   /*
+* In snapshot mode ->data_size holds the new address of the
+* ring buffer's head.  The size itself is the whole address
+* range since we want the latest information.
+*/
+   if (buf->snapshot)
+   handle->head = local_xchg(>data_size,
+ buf->nr_pages << PAGE_SHIFT);
+   /*
+* Tell the tracer PMU how much we got in this run and if
+* something went wrong along the way.  Nobody else can use
+* this cs_buffers instance until we are done.  As such
+* resetting parameters here and squaring off with the ring
+* buffer API in the tracer PMU is fine.
+*/
+   *lost = !!local_xchg(>lost, 0);
+   size = local_xchg(>data_size, 0);
+   }
+
+   return size;
+}
+
+static void tmc_update_etf_buffer(struct coresight_device *csdev,
+ struct perf_output_handle *handle,
+ void *sink_config)
+{
+   int i, cur;
+   u32 *buf_ptr;
+   u32 read_ptr, write_ptr;
+   u32 status, to_read;
+   unsigned long offset;
+   struct cs_buffers *buf = sink_config;
+   struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+   if (!buf)
+   return;
+
+   /* This shouldn't happen */
+   if (WARN_ON_ONCE(local_read(>mode) != CS_MODE_PERF))
+   return;
+
+   CS_UNLOCK(drvdata->base);
+
+   tmc_flush_and_stop(drvdata);
+
+   read_ptr = readl_relaxed(drvdata->base + TMC_RRP);
+   write_ptr = readl_relaxed(drvdata->base + TMC_RWP);
+
+   /*
+* Get a hold of the status register and see if a wrap around
+* has occurred.  If so adjust things accordingly.
+*/
+   status = readl_relaxed(drvdata->base + TMC_STS);
+   if (status & TMC_STS_FULL) {
+   local_inc(>lost);
+   to_read = drvdata->size;
+   } else {
+   to_read = CIRC_CNT(write_ptr, read_ptr, drvdata->size);
+   }
+
+   /*
+* The TMC RAM buffer may be bigger than the space available in the
+  

Re: [PATCH V4] audit: add tty field to LOGIN event

2016-04-22 Thread Peter Hurley
On 04/21/2016 11:14 AM, Richard Guy Briggs wrote:
> The tty field was missing from AUDIT_LOGIN events.
> 
> Refactor code to create a new function audit_get_tty(), using it to
> replace the call in audit_log_task_info() and to add it to
> audit_log_set_loginuid().  Lock and bump the kref to protect it, adding
> audit_put_tty() alias to decrement it.
> 
> Signed-off-by: Richard Guy Briggs 
> ---
> 
> V4: Add missing prototype for audit_put_tty() when audit syscall is not
> enabled (MIPS).
> 
> V3: Introduce audit_put_tty() alias to decrement kref.
> 
> V2: Use kref to protect tty signal struct while in use.
> 
> ---
> 
>  include/linux/audit.h |   24 
>  kernel/audit.c|   18 +-
>  kernel/auditsc.c  |8 ++--
>  3 files changed, 35 insertions(+), 15 deletions(-)
> 
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index b40ed5d..32cdafb 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define AUDIT_INO_UNSET ((unsigned long)-1)
>  #define AUDIT_DEV_UNSET ((dev_t)-1)
> @@ -343,6 +344,23 @@ static inline unsigned int audit_get_sessionid(struct 
> task_struct *tsk)
>   return tsk->sessionid;
>  }
>  
> +static inline struct tty_struct *audit_get_tty(struct task_struct *tsk)
> +{
> + struct tty_struct *tty = NULL;
> + unsigned long flags;
> +
> + spin_lock_irqsave(>sighand->siglock, flags);
> + if (tsk->signal)
> + tty = tty_kref_get(tsk->signal->tty);
> + spin_unlock_irqrestore(>sighand->siglock, flags);


Not that I'm objecting because I get that you're just refactoring
existing code, but I thought I'd point out some stuff.

1. There's no need to check if signal_struct is NULL (ie. tsk->signal)
   because if it is, this will blow up trying to dereference the
   sighand_struct (ie tsk->sighand).

2. The existing usage is always tsk==current

3. If the idea is to make this invulnerable to tsk being gone, then
   the usage is unsafe anyway.


So ultimately (but not necessarily for this patch) I'd prefer that either
a. audit use existing tty api instead of open-coding, or
b. add any tty api functions required.


Regards,
Peter Hurley


> + return tty;
> +}
> +
> +static inline void audit_put_tty(struct tty_struct *tty)
> +{
> + tty_kref_put(tty);
> +}
> +
>  extern void __audit_ipc_obj(struct kern_ipc_perm *ipcp);
>  extern void __audit_ipc_set_perm(unsigned long qbytes, uid_t uid, gid_t gid, 
> umode_t mode);
>  extern void __audit_bprm(struct linux_binprm *bprm);
> @@ -500,6 +518,12 @@ static inline unsigned int audit_get_sessionid(struct 
> task_struct *tsk)
>  {
>   return -1;
>  }
> +static inline struct tty_struct *audit_get_tty(struct task_struct *tsk)
> +{
> + return NULL;
> +}
> +static inline void audit_put_tty(struct tty_struct *tty)
> +{ }
>  static inline void audit_ipc_obj(struct kern_ipc_perm *ipcp)
>  { }
>  static inline void audit_ipc_set_perm(unsigned long qbytes, uid_t uid,
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 3a3e5de..7edd776 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -64,7 +64,6 @@
>  #include 
>  #endif
>  #include 
> -#include 
>  #include 
>  #include 
>  
> @@ -1873,21 +1872,14 @@ void audit_log_task_info(struct audit_buffer *ab, 
> struct task_struct *tsk)
>  {
>   const struct cred *cred;
>   char comm[sizeof(tsk->comm)];
> - char *tty;
> + struct tty_struct *tty;
>  
>   if (!ab)
>   return;
>  
>   /* tsk == current */
>   cred = current_cred();
> -
> - spin_lock_irq(>sighand->siglock);
> - if (tsk->signal && tsk->signal->tty && tsk->signal->tty->name)
> - tty = tsk->signal->tty->name;
> - else
> - tty = "(none)";
> - spin_unlock_irq(>sighand->siglock);
> -
> + tty = audit_get_tty(tsk);
>   audit_log_format(ab,
>" ppid=%d pid=%d auid=%u uid=%u gid=%u"
>" euid=%u suid=%u fsuid=%u"
> @@ -1903,11 +1895,11 @@ void audit_log_task_info(struct audit_buffer *ab, 
> struct task_struct *tsk)
>from_kgid(_user_ns, cred->egid),
>from_kgid(_user_ns, cred->sgid),
>from_kgid(_user_ns, cred->fsgid),
> -  tty, audit_get_sessionid(tsk));
> -
> +  tty ? tty_name(tty) : "(none)",
> +  audit_get_sessionid(tsk));
> + audit_put_tty(tty);
>   audit_log_format(ab, " comm=");
>   audit_log_untrustedstring(ab, get_task_comm(comm, tsk));
> -
>   audit_log_d_path_exe(ab, tsk->mm);
>   audit_log_task_context(ab);
>  }
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index 195ffae..71e14d8 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -1980,6 +1980,7 @@ static void audit_log_set_loginuid(kuid_t koldloginuid, 
> kuid_t kloginuid,
>  {
>   

[PATCH V3 10/18] coresight: tmc: getting the right read_count on tmc_open()

2016-04-22 Thread Mathieu Poirier
In function tmc_open(), if tmc_read_prepare() fails variable
drvdata->read_count is not decremented, causing unwanted
access to drvdata->buf and very likely, a crash dump.

By moving the incrementation to a place where we know things
are stable this kind of situation is avoided.

Signed-off-by: Mathieu Poirier 
Reviewed-by: Suzuki K Poulose 
---
 drivers/hwtracing/coresight/coresight-tmc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight-tmc.c 
b/drivers/hwtracing/coresight/coresight-tmc.c
index e8e12a9b917a..55806352b1f1 100644
--- a/drivers/hwtracing/coresight/coresight-tmc.c
+++ b/drivers/hwtracing/coresight/coresight-tmc.c
@@ -121,13 +121,14 @@ static int tmc_open(struct inode *inode, struct file 
*file)
   struct tmc_drvdata, miscdev);
int ret = 0;
 
-   if (drvdata->read_count++)
+   if (drvdata->read_count)
goto out;
 
ret = tmc_read_prepare(drvdata);
if (ret)
return ret;
 out:
+   drvdata->read_count++;
nonseekable_open(inode, file);
 
dev_dbg(drvdata->dev, "%s: successfully opened\n", __func__);
-- 
2.5.0



[PATCH 4/4] MIPS: cevt-r4k: Dynamically calculate min_delta_ns

2016-04-22 Thread James Hogan
Calculate the MIPS clockevent device's min_delta_ns dynamically based on
the time it takes to perform the mips_next_event() sequence.

Virtualisation in particular makes the current fixed min_delta of 0x300
inappropriate under some circumstances, as the CP0_Count and CP0_Compare
registers may be being emulated by the hypervisor, and the frequency may
not correspond directly to the CPU frequency.

We actually use twice the median of multiple 75th percentiles of
multiple measurements of how long the mips_next_event() sequence takes,
in order to fairly efficiently eliminate outliers due to unexpected
hypervisor latency (which would need handling with retries when it
occurs during normal operation anyway).

Signed-off-by: James Hogan 
Cc: Ralf Baechle 
Cc: Daniel Lezcano 
Cc: Thomas Gleixner 
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
---
 arch/mips/kernel/cevt-r4k.c | 82 +++--
 1 file changed, 80 insertions(+), 2 deletions(-)

diff --git a/arch/mips/kernel/cevt-r4k.c b/arch/mips/kernel/cevt-r4k.c
index 8dfe6a6e1480..e4c21bbf9422 100644
--- a/arch/mips/kernel/cevt-r4k.c
+++ b/arch/mips/kernel/cevt-r4k.c
@@ -28,6 +28,83 @@ static int mips_next_event(unsigned long delta,
return res;
 }
 
+/**
+ * calculate_min_delta() - Calculate a good minimum delta for 
mips_next_event().
+ *
+ * Running under virtualisation can introduce overhead into mips_next_event() 
in
+ * the form of hypervisor emulation of CP0_Count/CP0_Compare registers,
+ * potentially with an unnatural frequency, which makes a fixed min_delta_ns
+ * value inappropriate as it may be too small.
+ *
+ * It can also introduce occasional latency from the guest being descheduled.
+ *
+ * This function calculates a good minimum delta based roughly on the 75th
+ * percentile of the time taken to do the mips_next_event() sequence, in order
+ * to handle potentially higher overhead while also eliminating outliers due to
+ * unpredictable hypervisor latency (which can be handled by retries).
+ *
+ * Return: An appropriate minimum delta for the clock event device.
+ */
+static unsigned int calculate_min_delta(void)
+{
+   unsigned int cnt, i, j, k, l;
+   unsigned int buf1[4], buf2[3];
+   unsigned int min_delta;
+
+   /*
+* Calculate the median of 5 75th percentiles of 5 samples of how long
+* it takes to set CP0_Compare = CP0_Count + delta.
+*/
+   for (i = 0; i < 5; ++i) {
+   for (j = 0; j < 5; ++j) {
+   /*
+* This is like the code in mips_next_event(), and
+* directly measures the borderline "safe" delta.
+*/
+   cnt = read_c0_count();
+   write_c0_compare(cnt);
+   cnt = read_c0_count() - cnt;
+
+   /* Sorted insert into buf1 */
+   for (k = 0; k < j; ++k) {
+   if (cnt < buf1[k]) {
+   l = min_t(unsigned int,
+ j, ARRAY_SIZE(buf1) - 1);
+   for (; l > k; --l)
+   buf1[l] = buf1[l - 1];
+   break;
+   }
+   }
+   if (k < ARRAY_SIZE(buf1))
+   buf1[k] = cnt;
+   }
+
+   /* Sorted insert of 75th percentile into buf2 */
+   for (k = 0; k < i; ++k) {
+   if (buf1[ARRAY_SIZE(buf1) - 1] < buf2[k]) {
+   l = min_t(unsigned int,
+ i, ARRAY_SIZE(buf2) - 1);
+   for (; l > k; --l)
+   buf2[l] = buf2[l - 1];
+   break;
+   }
+   }
+   if (k < ARRAY_SIZE(buf2))
+   buf2[k] = buf1[ARRAY_SIZE(buf1) - 1];
+   }
+
+   /* Use 2 * median of 75th percentiles */
+   min_delta = buf2[ARRAY_SIZE(buf2) - 1] * 2;
+
+   /* Don't go too low */
+   if (min_delta < 0x300)
+   min_delta = 0x300;
+
+   pr_debug("%s: median 75th percentile=%#x, min_delta=%#x\n",
+__func__, buf2[ARRAY_SIZE(buf2) - 1], min_delta);
+   return min_delta;
+}
+
 DEFINE_PER_CPU(struct clock_event_device, mips_clockevent_device);
 int cp0_timer_irq_installed;
 
@@ -177,7 +254,7 @@ int r4k_clockevent_init(void)
 {
unsigned int cpu = smp_processor_id();
struct clock_event_device *cd;
-   unsigned int irq;
+   unsigned int irq, min_delta;
 
if (!cpu_has_counter || !mips_hpt_frequency)
return -ENXIO;
@@ -203,7 

namespaced file capabilities

2016-04-22 Thread serge . hallyn
Hi,

I've sent a few patches and emails over the past months about supporting
file capabilities in user namespace confined containers.  A few of the
requirements as I see them are:

1. Root in a user namespace should be able to set file capabilities on a binary
for use by any user mapped into his namespace.

2. Any uid not mapped into the user namespace whose root user set file
capabilities should not gain privileges when running an executable which only
has file capabilities set by this root user.

3. Existing calls to cap_set_file(3) and cap_get_file(3) as well as
setcap(8) and getcap(8) should transparently work.  This would allow
package managers to simply set file capabilities in postinst.

Below is a kernel patch which implements a new security.nscapability
extended attribute.  Setting this xattr on a file requires cap_setfcap
against the current user namespace, and for the file to be owned by
a uid and gid mapped into that namespace.  When found on a file,
the capabilities will take effect only if the file is owned by the
root uid in the caller's namespace, or the root uid in any ancestor
namespace.

While this design supports nested namespaces, it does not support
use of file capabilities by users in unrelated namespaces.  So if
the same file is linked into two namespaces N1 and N2 which do not
share the same root kuid, then the only way for N1 and N2 to both
execute the file while respecting security.nscapability is to have
a common ancestor namespace write the capability.  The only reasonable
way we could handle this case would be to use a securityfs interface
to set file capabilities.  The capability.ko module could then
do the work of keeping a list of uid ranges for which file capabilities
should be honored.  I don't think that flexibility is really called
for.
 
The kernel patch follows, and can be found at
https://git.kernel.org/cgit/linux/kernel/git/sergeh/linux-security.git/log/?h=2016-04-22/nsfscaps

The libcap patch can be found at
https://git.kernel.org/cgit/linux/kernel/git/sergeh/libcap.git/log/?h=2016-04-22/nscaps

Comments/conversation/suggestions greatly appreciated.

thanks,
-serge



Re: [PATCH] MIPS: Allow R6 compact branch policy to be left unspecified

2016-04-22 Thread James Hogan
On Fri, Apr 22, 2016 at 04:56:02PM +0100, Maciej W. Rozycki wrote:
> On Fri, 22 Apr 2016, Paul Burton wrote:
> 
> > It turns out that some toolchains which support MIPS R6 don't support
> > the -mcompact-branches flag to specify compact branch behaviour. Default
> > to not providing the -mcompact-branch option to the compiler such that
> > we can build with such toolchains.
> 
>  Good idea overall, one further suggestion below.
> 
> > diff --git a/arch/mips/Kconfig.debug b/arch/mips/Kconfig.debug
> > index f0e314c..e91b3d1 100644
> > --- a/arch/mips/Kconfig.debug
> > +++ b/arch/mips/Kconfig.debug
> > @@ -117,7 +117,15 @@ if CPU_MIPSR6
> >  
> >  choice
> > prompt "Compact branch policy"
> > -   default MIPS_COMPACT_BRANCHES_OPTIMAL
> > +   default MIPS_COMPACT_BRANCHES_DEFAULT
> > +
> > +config MIPS_COMPACT_BRANCHES_DEFAULT
> > +   bool "Toolchain Default (don't specify)"
> > +   help
> > + Don't pass the -mcompact-branches flag to the compiler, allowing it
> > + to use its default (generally "optimal"). This is particularly
> > + useful for early R6-supporting toolchains which don't support the
> > + -mcompact-branches flag.
> >  
> >  config MIPS_COMPACT_BRANCHES_NEVER
> > bool "Never (force delay slot branches)"
> 
>  How about making the option depend on DEBUG_KERNEL and maybe making it an 
> umbrella setting to hide details from users who do not want to be 
> bothered, i.e. something like:
> 
> config MIPS_COMPACT_BRANCHES_OVERRIDE
>  bool "Override the toolchain default for compact branch policy"
>  depends on DEBUG_KERNEL
>  default n

Although note that "default n" is redundant.

Cheers
James

> [...]
> if MIPS_COMPACT_BRANCHES_OVERRIDE
> choice
> prompt "Compact branch policy"
> default MIPS_COMPACT_BRANCHES_OPTIMAL
> [...]
> endif # MIPS_COMPACT_BRANCHES_OVERRIDE
> 
> ?
> 
>   Maciej
> 


signature.asc
Description: Digital signature


[PATCH 1/1] simplified security.nscapability xattr

2016-04-22 Thread serge . hallyn
From: Serge Hallyn 

This can only be set by root in his own namespace, and will
only be respected by namespaces with that same root kuid
mapped as root, or namespaces descended from it.

This allows a simple setxattr to work, allows tar/untar to
work, and allows us to tar in one namespace and untar in
another while preserving the capability, without risking
leaking privilege into a parent namespace.

Signed-off-by: Serge Hallyn 
---
 include/linux/capability.h  |5 ++-
 include/uapi/linux/capability.h |   18 
 include/uapi/linux/xattr.h  |3 ++
 security/commoncap.c|   91 +--
 4 files changed, 112 insertions(+), 5 deletions(-)

diff --git a/include/linux/capability.h b/include/linux/capability.h
index 00690ff..cf533ff 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@ -13,7 +13,7 @@
 #define _LINUX_CAPABILITY_H
 
 #include 
-
+#include 
 
 #define _KERNEL_CAPABILITY_VERSION _LINUX_CAPABILITY_VERSION_3
 #define _KERNEL_CAPABILITY_U32S_LINUX_CAPABILITY_U32S_3
@@ -31,6 +31,9 @@ struct cpu_vfs_cap_data {
kernel_cap_t inheritable;
 };
 
+#define NS_CAPS_VERSION(x) (x & 0xFF)
+#define NS_CAPS_FLAGS(x) ((x >> 8) & 0xFF)
+
 #define _USER_CAP_HEADER_SIZE  (sizeof(struct __user_cap_header_struct))
 #define _KERNEL_CAP_T_SIZE (sizeof(kernel_cap_t))
 
diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
index 12c37a1..f0b4a66 100644
--- a/include/uapi/linux/capability.h
+++ b/include/uapi/linux/capability.h
@@ -62,6 +62,9 @@ typedef struct __user_cap_data_struct {
 #define VFS_CAP_U32_2   2
 #define XATTR_CAPS_SZ_2 (sizeof(__le32)*(1 + 2*VFS_CAP_U32_2))
 
+/* version number for security.nscapability xattrs hdr->hdr_info */
+#define VFS_NS_CAP_REVISION 1
+
 #define XATTR_CAPS_SZ   XATTR_CAPS_SZ_2
 #define VFS_CAP_U32 VFS_CAP_U32_2
 #define VFS_CAP_REVISION   VFS_CAP_REVISION_2
@@ -74,6 +77,21 @@ struct vfs_cap_data {
} data[VFS_CAP_U32];
 };
 
+#define VFS_NS_CAP_EFFECTIVE0x1
+/*
+ * 32-bit hdr_info contains
+ * 16 leftmost: reserved
+ * next 8: flags (only VFS_NS_CAP_EFFECTIVE so far)
+ * last 8: version
+ */
+struct vfs_ns_cap_data {
+   __le32 magic_etc;
+   struct {
+   __le32 permitted;/* Little endian */
+   __le32 inheritable;  /* Little endian */
+   } data[VFS_CAP_U32];
+};
+
 #ifndef __KERNEL__
 
 /*
diff --git a/include/uapi/linux/xattr.h b/include/uapi/linux/xattr.h
index 1590c49..67c80ab 100644
--- a/include/uapi/linux/xattr.h
+++ b/include/uapi/linux/xattr.h
@@ -68,6 +68,9 @@
 #define XATTR_CAPS_SUFFIX "capability"
 #define XATTR_NAME_CAPS XATTR_SECURITY_PREFIX XATTR_CAPS_SUFFIX
 
+#define XATTR_NS_CAPS_SUFFIX "nscapability"
+#define XATTR_NAME_NS_CAPS XATTR_SECURITY_PREFIX XATTR_NS_CAPS_SUFFIX
+
 #define XATTR_POSIX_ACL_ACCESS  "posix_acl_access"
 #define XATTR_NAME_POSIX_ACL_ACCESS XATTR_SYSTEM_PREFIX XATTR_POSIX_ACL_ACCESS
 #define XATTR_POSIX_ACL_DEFAULT  "posix_acl_default"
diff --git a/security/commoncap.c b/security/commoncap.c
index 48071ed..8f3f34a 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -313,6 +313,10 @@ int cap_inode_need_killpriv(struct dentry *dentry)
if (!inode->i_op->getxattr)
   return 0;
 
+   error = inode->i_op->getxattr(dentry, XATTR_NAME_NS_CAPS, NULL, 0);
+   if (error > 0)
+   return 1;
+
error = inode->i_op->getxattr(dentry, XATTR_NAME_CAPS, NULL, 0);
if (error <= 0)
return 0;
@@ -330,11 +334,17 @@ int cap_inode_need_killpriv(struct dentry *dentry)
 int cap_inode_killpriv(struct dentry *dentry)
 {
struct inode *inode = d_backing_inode(dentry);
+   int ret1, ret2;
 
if (!inode->i_op->removexattr)
   return 0;
 
-   return inode->i_op->removexattr(dentry, XATTR_NAME_CAPS);
+   ret1 = inode->i_op->removexattr(dentry, XATTR_NAME_CAPS);
+   ret2 = inode->i_op->removexattr(dentry, XATTR_NAME_NS_CAPS);
+
+   if (ret1 != 0)
+   return ret1;
+   return ret2;
 }
 
 /*
@@ -438,6 +448,65 @@ int get_vfs_caps_from_disk(const struct dentry *dentry, 
struct cpu_vfs_cap_data
return 0;
 }
 
+int get_vfs_ns_caps_from_disk(const struct dentry *dentry, struct 
cpu_vfs_cap_data *cpu_caps)
+{
+   struct inode *inode = d_backing_inode(dentry);
+   unsigned i;
+   u32 magic_etc;
+   ssize_t size;
+   struct vfs_ns_cap_data nscap;
+   bool foundroot = false;
+   struct user_namespace *ns;
+
+   memset(cpu_caps, 0, sizeof(struct cpu_vfs_cap_data));
+
+   if (!inode || !inode->i_op->getxattr)
+   return -ENODATA;
+
+   /* verify that current or ancestor userns root owns this file */
+   for (ns = current_user_ns(); ; ns = ns->parent) {
+   if (from_kuid(ns, dentry->d_inode->i_uid) == 0) {
+ 

Re: [PATCH] irqdomain: fix compare_const_fl.cocci warnings

2016-04-22 Thread Thomas Gleixner
On Wed, 20 Apr 2016, Julia Lawall wrote:

>  Move constants to the right of binary operators.
> 
> Generated by: scripts/coccinelle/misc/compare_const_fl.cocci
> 
> Signed-off-by: Fengguang Wu 
> Signed-off-by: Julia Lawall 

This SOB chain looks wrong. Who is the author?

Thanks,

tglx


HELLO DEAR

2016-04-22 Thread Melissa Robert


Hello Dear,
how are you doing hope fine, I am (Melissa Robert) by name. i will like
to
know more about you believing that friendship is a free gift of nature.
Please get back to me as soon as possible through this my private Email.
(mr4785...@gmail.com)
thank you.



[PATCH 0/4] sh: fix up modular use in non-modular code

2016-04-22 Thread Paul Gortmaker
For anyone new to the underlying goal of this cleanup, we are trying to
make kernel code consistent with the Makefiles/Kconfigs that control them.

This means not using modular functions/macros for code that can never
be built as a module.  Some of the other downfalls this leads to are:

 (1) it is easy to accidentally write unused module_exit and remove code
 (2) it can be misleading when reading the source, thinking it can be
 modular when the Makefile and/or Kconfig prohibit it
 (3) it requires the include of the module.h header file which in turn
 includes nearly everything else, thus adding to CPP overhead.
 (4) it gets copied/replicated into other drivers and spreads like weeds.

Three of the four commits here are completely trivial with zero runtime
impact whatsoever.  The fourth has a deletion of a ".remove" function
and as we've done elsewhere, we block the sysfs ability to reach in and
manually execute that function, since there isn't a sane use case for
which doing that makes sense.

Build tested on today's linux-next ; full build fails on duplicate syms
from OF generic board, but that is a known and reported issue elsewhere;
it has nothing to do with the changes here.

Paul
--

Cc: linux...@vger.kernel.org
Cc: Paul Gortmaker 
Cc: Rich Felker 
Cc: Yoshinori Sato 


Paul Gortmaker (4):
  sh: make time.c explicitly non-modular
  sh: make mm/asids-debugfs explicitly non-modular
  sh: make board-secureedge5410 explicitly non-modular
  sh: make heartbeat driver explicitly non-modular

 arch/sh/boards/board-secureedge5410.c |  3 +--
 arch/sh/drivers/heartbeat.c   | 32 +++-
 arch/sh/kernel/time.c |  3 +--
 arch/sh/mm/asids-debugfs.c|  5 +
 4 files changed, 6 insertions(+), 37 deletions(-)

-- 
2.8.0



[PATCH 3/4] sh: make board-secureedge5410 explicitly non-modular

2016-04-22 Thread Paul Gortmaker
The Kconfig currently controlling compilation of this code is:

config SH_SECUREEDGE5410
bool "SecureEdge5410"

...meaning that it currently is not being built as a module by anyone.

Lets remove the couple traces of modularity so that when reading the
driver there is no doubt it is builtin-only.

Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit.

We don't replace module.h with init.h since the file already has that.

Cc: Yoshinori Sato 
Cc: Rich Felker 
Cc: linux...@vger.kernel.org
Signed-off-by: Paul Gortmaker 
---
 arch/sh/boards/board-secureedge5410.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/sh/boards/board-secureedge5410.c 
b/arch/sh/boards/board-secureedge5410.c
index 98b36205aa7b..97ec67ffec2b 100644
--- a/arch/sh/boards/board-secureedge5410.c
+++ b/arch/sh/boards/board-secureedge5410.c
@@ -14,7 +14,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -49,7 +48,7 @@ static int __init eraseconfig_init(void)
irq);
return 0;
 }
-module_init(eraseconfig_init);
+device_initcall(eraseconfig_init);
 
 /*
  * Initialize IRQ setting
-- 
2.8.0



[PATCH 4/4] sh: make heartbeat driver explicitly non-modular

2016-04-22 Thread Paul Gortmaker
The Kconfig for this driver is currently:

config HEARTBEAT
bool "Heartbeat LED"

...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.

Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit.

We explicitly disallow a driver unbind, since that doesn't have a
sensible use case anyway, and it allows us to drop the ".remove"
code for non-modular drivers.

We also delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.

Cc: Yoshinori Sato 
Cc: Rich Felker 
Cc: linux...@vger.kernel.org
Signed-off-by: Paul Gortmaker 
---
 arch/sh/drivers/heartbeat.c | 32 +++-
 1 file changed, 3 insertions(+), 29 deletions(-)

diff --git a/arch/sh/drivers/heartbeat.c b/arch/sh/drivers/heartbeat.c
index 7efc9c354fc7..49bace446a1a 100644
--- a/arch/sh/drivers/heartbeat.c
+++ b/arch/sh/drivers/heartbeat.c
@@ -19,7 +19,6 @@
  * for more details.
  */
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -139,26 +138,11 @@ static int heartbeat_drv_probe(struct platform_device 
*pdev)
return mod_timer(>timer, jiffies + 1);
 }
 
-static int heartbeat_drv_remove(struct platform_device *pdev)
-{
-   struct heartbeat_data *hd = platform_get_drvdata(pdev);
-
-   del_timer_sync(>timer);
-   iounmap(hd->base);
-
-   platform_set_drvdata(pdev, NULL);
-
-   if (!pdev->dev.platform_data)
-   kfree(hd);
-
-   return 0;
-}
-
 static struct platform_driver heartbeat_driver = {
.probe  = heartbeat_drv_probe,
-   .remove = heartbeat_drv_remove,
.driver = {
-   .name   = DRV_NAME,
+   .name   = DRV_NAME,
+   .suppress_bind_attrs= true,
},
 };
 
@@ -167,14 +151,4 @@ static int __init heartbeat_init(void)
printk(KERN_NOTICE DRV_NAME ": version %s loaded\n", DRV_VERSION);
return platform_driver_register(_driver);
 }
-
-static void __exit heartbeat_exit(void)
-{
-   platform_driver_unregister(_driver);
-}
-module_init(heartbeat_init);
-module_exit(heartbeat_exit);
-
-MODULE_VERSION(DRV_VERSION);
-MODULE_AUTHOR("Paul Mundt");
-MODULE_LICENSE("GPL v2");
+device_initcall(heartbeat_init);
-- 
2.8.0



Re: [PATCH RFC 10/22] block, bfq: add full hierarchical scheduling and cgroups support

2016-04-22 Thread Tejun Heo
Hello, Paolo.

On Wed, Apr 20, 2016 at 11:32:23AM +0200, Paolo wrote:
> This malfunction seems related to a blkcg behavior that I did not
> expect: the sequential writer changes group continuously. It moves
> from the root group to its correct group, and back. Here is the
> output of
> 
> egrep 'insert_request|changed cgroup' trace
> 
> over a trace taken with the original version of cfq (seq_write is of
> course the group of the writer):
...
> For reasons that I don't yet know, group changes are much more
> frequent with bfq, which ultimately causes bfq to fail to isolate the
> writer from the reader.
> 
> While I go on trying to understand why, could you please tell me
> whether this fluctuation is normal, and/or point me to documentation from
> which I can better understand this behavior, without bothering you
> further?

So, a kworker would jump through different workqueues and issue IOs
for different writeback domains and the context can't be tied to the
issuing task.  The cgroup membership should be determined directly
from the bio.  cfq uses per-cgroup async queue.  I'm not sure how this
would map to bfq tho.

Thanks.

-- 
tejun


Re: [PATCH RFC 10/22] block, bfq: add full hierarchical scheduling and cgroups support

2016-04-22 Thread Paolo Valente

Il giorno 22/apr/2016, alle ore 20:13, Tejun Heo  ha scritto:

> Hello, Paolo.
> 
> On Wed, Apr 20, 2016 at 11:32:23AM +0200, Paolo wrote:
>> This malfunction seems related to a blkcg behavior that I did not
>> expect: the sequential writer changes group continuously. It moves
>> from the root group to its correct group, and back. Here is the
>> output of
>> 
>> egrep 'insert_request|changed cgroup' trace
>> 
>> over a trace taken with the original version of cfq (seq_write is of
>> course the group of the writer):
> ...
>> For reasons that I don't yet know, group changes are much more
>> frequent with bfq, which ultimately causes bfq to fail to isolate the
>> writer from the reader.
>> 
>> While I go on trying to understand why, could you please tell me
>> whether this fluctuation is normal, and/or point me to documentation from
>> which I can better understand this behavior, without bothering you
>> further?
> 
> So, a kworker would jump through different workqueues and issue IOs
> for different writeback domains and the context can't be tied to the
> issuing task.  The cgroup membership should be determined directly
> from the bio.

Yes. My doubt arises from the fact that the only source of intense I/O
is the dd (I have executed it alone). In contrast, group changes occur
at a high frequency during all the execution of the dd. Apparently I
cannot see any other I/O induced by the dd. Journaling issues sync
requests.

>  cfq uses per-cgroup async queue.  I'm not sure how this
> would map to bfq tho.
> 

It’s the same. But this is the part I’m checking.

Thanks,
Paolo

> Thanks.
> 
> -- 
> tejun



[PATCH v7 5/6] Documentation for the GCC plugin infrastructure

2016-04-22 Thread Emese Revfy
This is the GCC infrastructure documentation about its operation, how to add
and use a new plugin with an example.

Signed-off-by: Emese Revfy 
---
 Documentation/gcc-plugins.txt | 83 +++
 arch/Kconfig  |  2 ++
 2 files changed, 85 insertions(+)
 create mode 100644 Documentation/gcc-plugins.txt

diff --git a/Documentation/gcc-plugins.txt b/Documentation/gcc-plugins.txt
new file mode 100644
index 000..9fa9bd2
--- /dev/null
+++ b/Documentation/gcc-plugins.txt
@@ -0,0 +1,83 @@
+GCC plugin infrastructure
+=
+
+
+1. Introduction
+===
+
+GCC plugins are loadable modules that provide extra features to the
+compiler [1]. They are useful for runtime instrumentation and static analysis.
+We can analyse, change and add further code during compilation via
+callbacks [2], GIMPLE [3], IPA [4] and RTL passes [5].
+
+The GCC plugin infrastructure of the kernel supports all gcc versions from
+4.5 to 6.0, building out-of-tree modules, cross-compilation and building in a
+separate directory.
+
+Currently the GCC plugin infrastructure supports only the x86, arm and arm64
+architectures.
+
+This infrastructure was ported from grsecurity [6] and PaX [7].
+
+--
+[1] https://gcc.gnu.org/onlinedocs/gccint/Plugins.html
+[2] https://gcc.gnu.org/onlinedocs/gccint/Plugin-API.html#Plugin-API
+[3] https://gcc.gnu.org/onlinedocs/gccint/GIMPLE.html
+[4] https://gcc.gnu.org/onlinedocs/gccint/IPA.html
+[5] https://gcc.gnu.org/onlinedocs/gccint/RTL.html
+[6] https://grsecurity.net/
+[7] https://pax.grsecurity.net/
+
+
+2. Files
+
+
+$(src)/scripts/gcc-plugins
+   This is the directory of the GCC plugins.
+
+$(src)/scripts/gcc-plugins/gcc-common.h
+   This is a compatibility header for GCC plugins.
+   It should be always included instead of individual gcc headers.
+
+$(src)/scripts/gcc-plugin.sh
+   This script checks the availability of the included headers in
+   gcc-common.h and chooses the proper host compiler to build the plugins
+   (gcc-4.7 can be built by either gcc or g++).
+
+$(src)/scripts/gcc-plugins/gcc-generate-gimple-pass.h
+$(src)/scripts/gcc-plugins/gcc-generate-ipa-pass.h
+$(src)/scripts/gcc-plugins/gcc-generate-simple_ipa-pass.h
+$(src)/scripts/gcc-plugins/gcc-generate-rtl-pass.h
+   These headers automatically generate the registration structures for
+   GIMPLE, SIMPLE_IPA, IPA and RTL passes. They support all gcc versions
+   from 4.5 to 6.0.
+   They should be preferred to creating the structures by hand.
+
+
+3. Usage
+
+
+You must install the gcc plugin headers for your gcc version,
+e.g., on Ubuntu for gcc-4.9:
+
+   apt-get install gcc-4.9-plugin-dev
+
+Enable a GCC plugin based feature in the kernel config:
+
+   CONFIG_GCC_PLUGIN_CYC_COMPLEXITY = y
+
+To compile only the plugin(s):
+
+   make gcc-plugins
+
+or just run the kernel make and compile the whole kernel with
+the cyclomatic complexity GCC plugin.
+
+
+4. How to add a new GCC plugin
+==
+
+The GCC plugins are in $(src)/scripts/gcc-plugins/. You can use a file or a 
directory
+here. It must be added to $(src)/scripts/gcc-plugins/Makefile,
+$(src)/scripts/Makefile.gcc-plugins and $(src)/arch/Kconfig.
+See the cyc_complexity_plugin.c (CONFIG_GCC_PLUGIN_CYC_COMPLEXITY) GCC plugin.
diff --git a/arch/Kconfig b/arch/Kconfig
index ddf29b4..e783429 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -366,6 +366,8 @@ menuconfig GCC_PLUGINS
  GCC plugins are loadable modules that provide extra features to the
  compiler. They are useful for runtime instrumentation and static 
analysis.
 
+ See Documentation/gcc-plugins.txt for details.
+
 config GCC_PLUGIN_CYC_COMPLEXITY
bool "Compute the cyclomatic complexity of a function"
depends on GCC_PLUGINS
-- 
2.4.1



[PATCH v7 4/6] Add Cyclomatic complexity GCC plugin

2016-04-22 Thread Emese Revfy
Add a very simple plugin to demonstrate the GCC plugin infrastructure. This GCC
plugin computes the cyclomatic complexity of each function.

The complexity M of a function's control flow graph is defined as:
M = E - N + 2P
where
E = the number of edges
N = the number of nodes
P = the number of connected components (exit nodes).

Signed-off-by: Emese Revfy 
---
 arch/Kconfig| 12 +
 scripts/Makefile.gcc-plugins|  2 +
 scripts/gcc-plugins/Makefile|  4 ++
 scripts/gcc-plugins/cyc_complexity_plugin.c | 73 +
 4 files changed, 91 insertions(+)
 create mode 100644 scripts/gcc-plugins/cyc_complexity_plugin.c

diff --git a/arch/Kconfig b/arch/Kconfig
index 7c12571..ddf29b4 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -366,6 +366,18 @@ menuconfig GCC_PLUGINS
  GCC plugins are loadable modules that provide extra features to the
  compiler. They are useful for runtime instrumentation and static 
analysis.
 
+config GCC_PLUGIN_CYC_COMPLEXITY
+   bool "Compute the cyclomatic complexity of a function"
+   depends on GCC_PLUGINS
+   help
+ The complexity M of a function's control flow graph is defined as:
+  M = E - N + 2P
+ where
+
+ E = the number of edges
+ N = the number of nodes
+ P = the number of connected components (exit nodes).
+
 config HAVE_CC_STACKPROTECTOR
bool
help
diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins
index e6d66e2..282d63a 100644
--- a/scripts/Makefile.gcc-plugins
+++ b/scripts/Makefile.gcc-plugins
@@ -2,6 +2,8 @@ ifdef CONFIG_GCC_PLUGINS
   __PLUGINCC := $(call cc-ifversion, -ge, 0408, $(HOSTCXX), $(HOSTCC))
   PLUGINCC := $(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-plugin.sh 
"$(__PLUGINCC)" "$(HOSTCXX)" "$(CC)")
 
+  gcc-plugin-$(CONFIG_GCC_PLUGIN_CYC_COMPLEXITY)   += 
cyc_complexity_plugin.so
+
   GCC_PLUGINS_CFLAGS := $(addprefix -fplugin=$(objtree)/scripts/gcc-plugins/, 
$(gcc-plugin-y))
 
   ifeq ($(PLUGINCC),)
diff --git a/scripts/gcc-plugins/Makefile b/scripts/gcc-plugins/Makefile
index b2d64af..31c72bf 100644
--- a/scripts/gcc-plugins/Makefile
+++ b/scripts/gcc-plugins/Makefile
@@ -12,4 +12,8 @@ endif
 
 export GCCPLUGINS_DIR HOSTLIBS
 
+$(HOSTLIBS)-$(CONFIG_GCC_PLUGIN_CYC_COMPLEXITY) := cyc_complexity_plugin.so
+
 always := $($(HOSTLIBS)-y)
+
+cyc_complexity_plugin-objs := cyc_complexity_plugin.o
diff --git a/scripts/gcc-plugins/cyc_complexity_plugin.c 
b/scripts/gcc-plugins/cyc_complexity_plugin.c
new file mode 100644
index 000..34df974
--- /dev/null
+++ b/scripts/gcc-plugins/cyc_complexity_plugin.c
@@ -0,0 +1,73 @@
+/*
+ * Copyright 2011-2016 by Emese Revfy 
+ * Licensed under the GPL v2, or (at your option) v3
+ *
+ * Homepage:
+ * https://github.com/ephox-gcc-plugins/cyclomatic_complexity
+ *
+ * http://en.wikipedia.org/wiki/Cyclomatic_complexity
+ * The complexity M is then defined as:
+ * M = E - N + 2P
+ * where
+ *
+ *  E = the number of edges of the graph
+ *  N = the number of nodes of the graph
+ *  P = the number of connected components (exit nodes).
+ *
+ * Usage (4.5 - 5):
+ * $ make clean; make run
+ */
+
+#include "gcc-common.h"
+
+int plugin_is_GPL_compatible;
+
+static struct plugin_info cyc_complexity_plugin_info = {
+   .version= "20160225",
+   .help   = "Cyclomatic Complexity\n",
+};
+
+static unsigned int cyc_complexity_execute(void)
+{
+   int complexity;
+   expanded_location xloc;
+
+   /* M = E - N + 2P */
+   complexity = n_edges_for_fn(cfun) - n_basic_blocks_for_fn(cfun) + 2;
+
+   xloc = expand_location(DECL_SOURCE_LOCATION(current_function_decl));
+   fprintf(stderr, "Cyclomatic Complexity %d %s:%s\n", complexity,
+   xloc.file, DECL_NAME_POINTER(current_function_decl));
+
+   return 0;
+}
+
+#define PASS_NAME cyc_complexity
+
+#define NO_GATE
+#define TODO_FLAGS_FINISH TODO_dump_func
+
+#include "gcc-generate-gimple-pass.h"
+
+int plugin_init(struct plugin_name_args *plugin_info, struct 
plugin_gcc_version *version)
+{
+   const char * const plugin_name = plugin_info->base_name;
+   struct register_pass_info cyc_complexity_pass_info;
+
+   cyc_complexity_pass_info.pass   = 
make_cyc_complexity_pass();
+   cyc_complexity_pass_info.reference_pass_name= "ssa";
+   cyc_complexity_pass_info.ref_pass_instance_number   = 1;
+   cyc_complexity_pass_info.pos_op = 
PASS_POS_INSERT_AFTER;
+
+   if (!plugin_default_version_check(version, _version)) {
+   error(G_("incompatible gcc/plugin versions"));
+   return 1;
+   }
+
+   register_callback(plugin_name, PLUGIN_INFO, NULL,
+   _complexity_plugin_info);
+   register_callback(plugin_name, PLUGIN_PASS_MANAGER_SETUP, NULL,
+

[PATCH V3 09/18] coresight: tmc: allocating memory when needed

2016-04-22 Thread Mathieu Poirier
In it's current form the TMC probe() function allocates
trace buffer memory at boot time, event if coresight isn't
used.  This is highly inefficient since trace buffers can
occupy a lot of memory that could be used otherwised.

This patch allocates trace buffers on the fly, when the
coresight subsystem is solicited.  Allocated buffers are
released when traces are read using the device descriptors
under /dev.

Signed-off-by: Mathieu Poirier 
---
 drivers/hwtracing/coresight/coresight-tmc-etf.c | 86 +++--
 drivers/hwtracing/coresight/coresight-tmc-etr.c | 84 +++-
 drivers/hwtracing/coresight/coresight-tmc.c | 14 
 3 files changed, 165 insertions(+), 19 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c 
b/drivers/hwtracing/coresight/coresight-tmc-etf.c
index 91e43572ce9f..bcfa40e8cd1c 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
@@ -16,14 +16,12 @@
  */
 
 #include 
+#include 
 #include "coresight-priv.h"
 #include "coresight-tmc.h"
 
 void tmc_etb_enable_hw(struct tmc_drvdata *drvdata)
 {
-   /* Zero out the memory to help with debug */
-   memset(drvdata->buf, 0, drvdata->size);
-
CS_UNLOCK(drvdata->base);
 
/* Wait for TMCSReady bit to be set */
@@ -110,19 +108,69 @@ static void tmc_etf_disable_hw(struct tmc_drvdata 
*drvdata)
 
 static int tmc_enable_etf_sink(struct coresight_device *csdev, u32 mode)
 {
+   bool used = false;
+   char *buf = NULL;
unsigned long flags;
struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 
+/* This shouldn't be happening */
+   if (WARN_ON(mode != CS_MODE_SYSFS))
+   return -EINVAL;
+
+   /*
+* If a buffer is already allocated *keep holding* the lock and
+* jump to the fast path.  Otherwise release the lock and allocate
+* memory to work with.
+*/
spin_lock_irqsave(>spinlock, flags);
+   if (drvdata->buf)
+   goto fast_path;
+
+   spin_unlock_irqrestore(>spinlock, flags);
+
+   /* Allocating the memory here while outside of the spinlock */
+   buf = kzalloc(drvdata->size, GFP_KERNEL);
+   if (!buf)
+   return -ENOMEM;
+
+   /* Let's try again */
+   spin_lock_irqsave(>spinlock, flags);
+fast_path:
if (drvdata->reading) {
spin_unlock_irqrestore(>spinlock, flags);
+   /*
+* Free allocated memory outside of the spinlock.  There is
+* no need to assert the validity of 'buf' since calling
+* kfree(NULL) is safe.
+*/
+   kfree(buf);
return -EBUSY;
}
 
+   /*
+* If drvdata::buf isn't NULL, memory was allocated for a previous
+* trace run but wasn't read.  If so simply zero-out the memory.
+* Otherwise use the memory allocated above.
+*
+* The memory is freed when users read the buffer using the
+* /dev/xyz.{etf|etb} interface.  See tmc_read_unprepare_etf() for
+* details.
+*/
+   if (drvdata->buf) {
+   memset(drvdata->buf, 0, drvdata->size);
+   } else {
+   used = true;
+   drvdata->buf = buf;
+   }
+
tmc_etb_enable_hw(drvdata);
drvdata->enable = true;
spin_unlock_irqrestore(>spinlock, flags);
 
+   /* Free memory outside the spinlock if need be */
+   if (!used && buf)
+   kfree(buf);
+
dev_info(drvdata->dev, "TMC-ETB/ETF enabled\n");
return 0;
 }
@@ -223,6 +271,12 @@ int tmc_read_prepare_etb(struct tmc_drvdata *drvdata)
goto out;
}
 
+   /* If drvdata::buf is NULL the trace data has been read already */
+   if (drvdata->buf == NULL) {
+   ret = -EINVAL;
+   goto out;
+   }
+
/* Disable the TMC if need be */
if (drvdata->enable)
tmc_etb_disable_hw(drvdata);
@@ -236,6 +290,7 @@ out:
 
 int tmc_read_unprepare_etb(struct tmc_drvdata *drvdata)
 {
+   char *buf = NULL;
enum tmc_mode mode;
unsigned long flags;
 
@@ -254,11 +309,34 @@ int tmc_read_unprepare_etb(struct tmc_drvdata *drvdata)
}
 
/* Re-enable the TMC if need be */
-   if (drvdata->enable)
+   if (drvdata->enable) {
+   /*
+* The trace run will continue with the same allocated trace
+* buffer. As such zero-out the buffer so that we don't end
+* up with stale data.
+*
+* Since the tracer is still enabled drvdata::buf
+* can't be NULL.
+*/
+   memset(drvdata->buf, 0, drvdata->size);
tmc_etb_enable_hw(drvdata);
+   } else {
+   /*
+* The ETB/ETF is not 

[PATCH V3 03/18] coresight: tmc: re-implementing tmc_read_prepare/unprepare() functions

2016-04-22 Thread Mathieu Poirier
In their current implementation the tmc_read_prepare/unprepare()
are a lump of if/else that is difficult to read.  This patch is
alleviating that by using a switch statement.  The latter also
allows for a better control on the error path.

Signed-off-by: Mathieu Poirier 
Reviewed-by: Suzuki K Poulose 
---
 drivers/hwtracing/coresight/coresight-tmc.c | 56 ++---
 1 file changed, 36 insertions(+), 20 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-tmc.c 
b/drivers/hwtracing/coresight/coresight-tmc.c
index 66fa7736d12f..d211aeec49f8 100644
--- a/drivers/hwtracing/coresight/coresight-tmc.c
+++ b/drivers/hwtracing/coresight/coresight-tmc.c
@@ -431,7 +431,7 @@ static const struct coresight_ops tmc_etf_cs_ops = {
 
 static int tmc_read_prepare(struct tmc_drvdata *drvdata)
 {
-   int ret;
+   int ret = 0;
unsigned long flags;
enum tmc_mode mode;
 
@@ -439,25 +439,31 @@ static int tmc_read_prepare(struct tmc_drvdata *drvdata)
if (!drvdata->enable)
goto out;
 
-   if (drvdata->config_type == TMC_CONFIG_TYPE_ETB) {
+   switch (drvdata->config_type) {
+   case TMC_CONFIG_TYPE_ETB:
tmc_etb_disable_hw(drvdata);
-   } else if (drvdata->config_type == TMC_CONFIG_TYPE_ETR) {
-   tmc_etr_disable_hw(drvdata);
-   } else {
+   break;
+   case TMC_CONFIG_TYPE_ETF:
+   /* There is no point in reading a TMC in HW FIFO mode */
mode = readl_relaxed(drvdata->base + TMC_MODE);
-   if (mode == TMC_MODE_CIRCULAR_BUFFER) {
-   tmc_etb_disable_hw(drvdata);
-   } else {
-   ret = -ENODEV;
+   if (mode != TMC_MODE_CIRCULAR_BUFFER) {
+   ret = -EINVAL;
goto err;
}
+
+   tmc_etb_disable_hw(drvdata);
+   break;
+   case TMC_CONFIG_TYPE_ETR:
+   tmc_etr_disable_hw(drvdata);
+   break;
+   default:
+   ret = -EINVAL;
+   goto err;
}
+
 out:
drvdata->reading = true;
-   spin_unlock_irqrestore(>spinlock, flags);
-
dev_info(drvdata->dev, "TMC read start\n");
-   return 0;
 err:
spin_unlock_irqrestore(>spinlock, flags);
return ret;
@@ -472,20 +478,30 @@ static void tmc_read_unprepare(struct tmc_drvdata 
*drvdata)
if (!drvdata->enable)
goto out;
 
-   if (drvdata->config_type == TMC_CONFIG_TYPE_ETB) {
+   switch (drvdata->config_type) {
+   case TMC_CONFIG_TYPE_ETB:
tmc_etb_enable_hw(drvdata);
-   } else if (drvdata->config_type == TMC_CONFIG_TYPE_ETR) {
-   tmc_etr_enable_hw(drvdata);
-   } else {
+   break;
+   case TMC_CONFIG_TYPE_ETF:
+   /* Make sure we don't re-enable a TMC in HW FIFO mode */
mode = readl_relaxed(drvdata->base + TMC_MODE);
-   if (mode == TMC_MODE_CIRCULAR_BUFFER)
-   tmc_etb_enable_hw(drvdata);
+   if (mode != TMC_MODE_CIRCULAR_BUFFER)
+   goto err;
+
+   tmc_etb_enable_hw(drvdata);
+   break;
+   case TMC_CONFIG_TYPE_ETR:
+   tmc_etr_disable_hw(drvdata);
+   break;
+   default:
+   goto err;
}
+
 out:
drvdata->reading = false;
-   spin_unlock_irqrestore(>spinlock, flags);
-
dev_info(drvdata->dev, "TMC read end\n");
+err:
+   spin_unlock_irqrestore(>spinlock, flags);
 }
 
 static int tmc_open(struct inode *inode, struct file *file)
-- 
2.5.0



[PATCH V3 11/18] coresight: tmc: adding mode of operation for link/sinks

2016-04-22 Thread Mathieu Poirier
Moving tmc_drvdata::enable to a local_t mode.  That way the
sink interface is aware of it's orgin and the foundation for
mutual exclusion between the sysFS and Perf interface can be
laid out.

Signed-off-by: Mathieu Poirier 
---
 drivers/hwtracing/coresight/coresight-tmc-etf.c | 28 ++---
 drivers/hwtracing/coresight/coresight-tmc-etr.c | 24 -
 drivers/hwtracing/coresight/coresight-tmc.h |  4 ++--
 3 files changed, 42 insertions(+), 14 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c 
b/drivers/hwtracing/coresight/coresight-tmc-etf.c
index bcfa40e8cd1c..d090a9745c73 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
@@ -110,6 +110,7 @@ static int tmc_enable_etf_sink(struct coresight_device 
*csdev, u32 mode)
 {
bool used = false;
char *buf = NULL;
+   long val;
unsigned long flags;
struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 
@@ -147,6 +148,15 @@ fast_path:
return -EBUSY;
}
 
+   val = local_xchg(>mode, mode);
+   /*
+* In sysFS mode we can have multiple writers per sink.  Since this
+* sink is already enabled no memory is needed and the HW need not be
+* touched.
+*/
+   if (val == CS_MODE_SYSFS)
+   goto spin_unlock;
+
/*
 * If drvdata::buf isn't NULL, memory was allocated for a previous
 * trace run but wasn't read.  If so simply zero-out the memory.
@@ -164,7 +174,7 @@ fast_path:
}
 
tmc_etb_enable_hw(drvdata);
-   drvdata->enable = true;
+spin_unlock:
spin_unlock_irqrestore(>spinlock, flags);
 
/* Free memory outside the spinlock if need be */
@@ -177,6 +187,7 @@ fast_path:
 
 static void tmc_disable_etf_sink(struct coresight_device *csdev)
 {
+   long val;
unsigned long flags;
struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 
@@ -186,8 +197,11 @@ static void tmc_disable_etf_sink(struct coresight_device 
*csdev)
return;
}
 
-   tmc_etb_disable_hw(drvdata);
-   drvdata->enable = false;
+   val = local_xchg(>mode, CS_MODE_DISABLED);
+   /* Disable the TMC only if it needs to */
+   if (val != CS_MODE_DISABLED)
+   tmc_etb_disable_hw(drvdata);
+
spin_unlock_irqrestore(>spinlock, flags);
 
dev_info(drvdata->dev, "TMC-ETB/ETF disabled\n");
@@ -206,7 +220,7 @@ static int tmc_enable_etf_link(struct coresight_device 
*csdev,
}
 
tmc_etf_enable_hw(drvdata);
-   drvdata->enable = true;
+   local_set(>mode, CS_MODE_SYSFS);
spin_unlock_irqrestore(>spinlock, flags);
 
dev_info(drvdata->dev, "TMC-ETF enabled\n");
@@ -226,7 +240,7 @@ static void tmc_disable_etf_link(struct coresight_device 
*csdev,
}
 
tmc_etf_disable_hw(drvdata);
-   drvdata->enable = false;
+   local_set(>mode, CS_MODE_DISABLED);
spin_unlock_irqrestore(>spinlock, flags);
 
dev_info(drvdata->dev, "TMC disabled\n");
@@ -278,7 +292,7 @@ int tmc_read_prepare_etb(struct tmc_drvdata *drvdata)
}
 
/* Disable the TMC if need be */
-   if (drvdata->enable)
+   if (local_read(>mode) == CS_MODE_SYSFS)
tmc_etb_disable_hw(drvdata);
 
drvdata->reading = true;
@@ -309,7 +323,7 @@ int tmc_read_unprepare_etb(struct tmc_drvdata *drvdata)
}
 
/* Re-enable the TMC if need be */
-   if (drvdata->enable) {
+   if (local_read(>mode) == CS_MODE_SYSFS) {
/*
 * The trace run will continue with the same allocated trace
 * buffer. As such zero-out the buffer so that we don't end
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c 
b/drivers/hwtracing/coresight/coresight-tmc-etr.c
index 474c70c089f3..8bbbf3ab1387 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
@@ -85,6 +85,7 @@ static void tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
 static int tmc_enable_etr_sink(struct coresight_device *csdev, u32 mode)
 {
bool used = false;
+   long val;
unsigned long flags;
void __iomem *vaddr = NULL;
dma_addr_t paddr;
@@ -126,6 +127,15 @@ fast_path:
return -EBUSY;
}
 
+   val = local_xchg(>mode, mode);
+   /*
+* In sysFS mode we can have multiple writers per sink.  Since this
+* sink is already enabled no memory is needed and the HW need not be
+* touched.
+*/
+   if (val == CS_MODE_SYSFS)
+   goto spin_unlock;
+
/*
 * If drvdata::buf == NULL, use the memory allocated above.
 * Otherwise a buffer still exists from a previous session, so
@@ -141,7 +151,7 @@ fast_path:
memset(drvdata->vaddr, 0, 

[PATCH V3 02/18] coresight: tmc: waiting for TMCReady bit before programming

2016-04-22 Thread Mathieu Poirier
According to the TRM before programming the TMC in circular
buffer mode (and that for any configuration, ETB, ETR, ETF),
the TMCReady bit in the status register has to be set.

This patch adds a check to make sure the state machine is in
a state where it can be configured, and complains otherwise.

Signed-off-by: Mathieu Poirier 
Reviewed-by: Suzuki K Poulose 
---
 drivers/hwtracing/coresight/coresight-tmc.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/hwtracing/coresight/coresight-tmc.c 
b/drivers/hwtracing/coresight/coresight-tmc.c
index 3f646e29a99b..66fa7736d12f 100644
--- a/drivers/hwtracing/coresight/coresight-tmc.c
+++ b/drivers/hwtracing/coresight/coresight-tmc.c
@@ -180,6 +180,9 @@ static void tmc_etb_enable_hw(struct tmc_drvdata *drvdata)
 
CS_UNLOCK(drvdata->base);
 
+   /* Wait for TMCSReady bit to be set */
+   tmc_wait_for_tmcready(drvdata);
+
writel_relaxed(TMC_MODE_CIRCULAR_BUFFER, drvdata->base + TMC_MODE);
writel_relaxed(TMC_FFCR_EN_FMT | TMC_FFCR_EN_TI |
   TMC_FFCR_FON_FLIN | TMC_FFCR_FON_TRIG_EVT |
@@ -201,6 +204,9 @@ static void tmc_etr_enable_hw(struct tmc_drvdata *drvdata)
 
CS_UNLOCK(drvdata->base);
 
+   /* Wait for TMCSReady bit to be set */
+   tmc_wait_for_tmcready(drvdata);
+
writel_relaxed(drvdata->size / 4, drvdata->base + TMC_RSZ);
writel_relaxed(TMC_MODE_CIRCULAR_BUFFER, drvdata->base + TMC_MODE);
 
@@ -230,6 +236,9 @@ static void tmc_etf_enable_hw(struct tmc_drvdata *drvdata)
 {
CS_UNLOCK(drvdata->base);
 
+   /* Wait for TMCSReady bit to be set */
+   tmc_wait_for_tmcready(drvdata);
+
writel_relaxed(TMC_MODE_HARDWARE_FIFO, drvdata->base + TMC_MODE);
writel_relaxed(TMC_FFCR_EN_FMT | TMC_FFCR_EN_TI,
   drvdata->base + TMC_FFCR);
-- 
2.5.0



[PATCH V3 06/18] coresight: tmc: cleaning up header file

2016-04-22 Thread Mathieu Poirier
This patch first move the TMC_STS_TMCREADY_BIT and
TMC_FFCR_FLUSHMAN_BIT defines to their respective section.
It also removes TMC_FFCR_FLUSHMAN, since the same result
can easily be obtained using the BIT() macro.

Signed-off-by: Mathieu Poirier 
Reviewed-by: Suzuki K Poulose 
---
 drivers/hwtracing/coresight/coresight-tmc.c | 2 +-
 drivers/hwtracing/coresight/coresight-tmc.h | 5 ++---
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-tmc.c 
b/drivers/hwtracing/coresight/coresight-tmc.c
index f9a6624ab531..07e2809d832b 100644
--- a/drivers/hwtracing/coresight/coresight-tmc.c
+++ b/drivers/hwtracing/coresight/coresight-tmc.c
@@ -50,7 +50,7 @@ static void tmc_flush_and_stop(struct tmc_drvdata *drvdata)
ffcr = readl_relaxed(drvdata->base + TMC_FFCR);
ffcr |= TMC_FFCR_STOP_ON_FLUSH;
writel_relaxed(ffcr, drvdata->base + TMC_FFCR);
-   ffcr |= TMC_FFCR_FLUSHMAN;
+   ffcr |= BIT(TMC_FFCR_FLUSHMAN_BIT);
writel_relaxed(ffcr, drvdata->base + TMC_FFCR);
/* Ensure flush completes */
if (coresight_timeout(drvdata->base,
diff --git a/drivers/hwtracing/coresight/coresight-tmc.h 
b/drivers/hwtracing/coresight/coresight-tmc.h
index 49718b4a9788..5a60830c8db5 100644
--- a/drivers/hwtracing/coresight/coresight-tmc.h
+++ b/drivers/hwtracing/coresight/coresight-tmc.h
@@ -49,6 +49,7 @@
 /* TMC_CTL - 0x020 */
 #define TMC_CTL_CAPT_ENBIT(0)
 /* TMC_STS - 0x00C */
+#define TMC_STS_TMCREADY_BIT   2
 #define TMC_STS_TRIGGERED  BIT(1)
 /* TMC_AXICTL - 0x110 */
 #define TMC_AXICTL_PROT_CTL_B0 BIT(0)
@@ -56,16 +57,14 @@
 #define TMC_AXICTL_SCT_GAT_MODEBIT(7)
 #define TMC_AXICTL_WR_BURST_16 0xF00
 /* TMC_FFCR - 0x304 */
+#define TMC_FFCR_FLUSHMAN_BIT  6
 #define TMC_FFCR_EN_FMTBIT(0)
 #define TMC_FFCR_EN_TI BIT(1)
 #define TMC_FFCR_FON_FLIN  BIT(4)
 #define TMC_FFCR_FON_TRIG_EVT  BIT(5)
-#define TMC_FFCR_FLUSHMAN  BIT(6)
 #define TMC_FFCR_TRIGON_TRIGIN BIT(8)
 #define TMC_FFCR_STOP_ON_FLUSH BIT(12)
 
-#define TMC_STS_TMCREADY_BIT   2
-#define TMC_FFCR_FLUSHMAN_BIT  6
 
 enum tmc_config_type {
TMC_CONFIG_TYPE_ETB,
-- 
2.5.0



Re: [git pull] drm fixes

2016-04-22 Thread Daniel Vetter
On Fri, Apr 22, 2016 at 7:16 PM, Linus Torvalds
 wrote:
> On Thu, Apr 21, 2016 at 5:57 PM, Dave Airlie  wrote:
>>
>>   git://people.freedesktop.org/~airlied/linux drm-fixes
>
> Hmm. freedesktop.org seems to be feeling a bit under the weather. It's
> not just the git part - it's not doing web either, and doesn't seem to
> answer to pings either (I saw _one_ ping response, but that was over a
> minute or two, so..)
>
> Can you kick it? Do you have a mirror?

Works all fine here, http, ssh & git protocols all up well.
Maybe temporary, or just your part of the interwebs fell off?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


Re: [git pull] drm fixes

2016-04-22 Thread Daniel Vetter
On Fri, Apr 22, 2016 at 7:30 PM, Linus Torvalds
 wrote:
> On Fri, Apr 22, 2016 at 10:23 AM, Daniel Vetter  wrote:
>>
>> Works all fine here, http, ssh & git protocols all up well.
>> Maybe temporary, or just your part of the interwebs fell off?
>
> It's up for me now too, so something temporary. I don't think it was
> at my end, everything else seemed to work fine and be reachable..
>
> Maybe it was going through a reboot and I was just unlucky with timing.

Just chatted with the Portland folks and at least they said half the
internet fell off for a few minutes, not just fd.o (gmail among
others). And it's back again since a few minutes. Anyway seems all
back up again.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


[PATCH] ARM: omap2plus_defconfig: Fix warning due invalid RXKAD symbol value

2016-04-22 Thread Javier Martinez Canillas
Commit 648af7fca159 ("rxrpc: Absorb the rxkad security module") changed
the RXKAD Kconfig symbol from tristate to boolean but the commit didn't
update the omap2plus_defconfig that was enabling CONFIG_RXKAD as module.

This leads to the following warning when using the omap2plus_defconfig:

arch/arm/configs/omap2plus_defconfig:112:warning: symbol value 'm' invalid for 
RXKAD

Signed-off-by: Javier Martinez Canillas 

---

 arch/arm/configs/omap2plus_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/configs/omap2plus_defconfig 
b/arch/arm/configs/omap2plus_defconfig
index 9edf8a493f07..c48cbd78e08f 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -109,7 +109,7 @@ CONFIG_BT_HCIVHCI=m
 CONFIG_BT_MRVL=m
 CONFIG_BT_MRVL_SDIO=m
 CONFIG_AF_RXRPC=m
-CONFIG_RXKAD=m
+CONFIG_RXKAD=y
 CONFIG_CFG80211=m
 CONFIG_MAC80211=m
 CONFIG_DEVTMPFS=y
-- 
2.5.5



Re: [tip:x86/asm] x86/mm/xen: Suppress hugetlbfs in PV guests

2016-04-22 Thread H. Peter Anvin
On 04/22/2016 02:47 AM, tip-bot for Jan Beulich wrote:
> Commit-ID:  103f6112f253017d7062cd74d17f4a514ed4485c
> Gitweb: http://git.kernel.org/tip/103f6112f253017d7062cd74d17f4a514ed4485c
> Author: Jan Beulich 
> AuthorDate: Thu, 21 Apr 2016 00:27:04 -0600
> Committer:  Ingo Molnar 
> CommitDate: Fri, 22 Apr 2016 10:05:00 +0200
> 
> 
> diff --git a/arch/x86/include/asm/hugetlb.h b/arch/x86/include/asm/hugetlb.h
> index f8a29d2..e6a8613 100644
> --- a/arch/x86/include/asm/hugetlb.h
> +++ b/arch/x86/include/asm/hugetlb.h
> @@ -4,6 +4,7 @@
>  #include 
>  #include 
>  
> +#define hugepages_supported() cpu_has_pse
>  

Please don't use the cpu_has_* macros anymore, they are going away soon.

In this case it should be static_cpu_has(X86_FEATURE_PSE).

-hpa




[PATCH v7 1/6] Shared library support

2016-04-22 Thread Emese Revfy
Infrastructure for building independent shared library targets.
This effectively also reverts commit 62e2210798ed38928ab24841e8b4878a
(Masahiro Yamada, kbuild: drop shared library support from Makefile.host).

Signed-off-by: Emese Revfy 
---
 Documentation/kbuild/makefiles.txt | 39 -
 scripts/Makefile.build |  2 +-
 scripts/Makefile.clean |  3 +-
 scripts/Makefile.host  | 70 +-
 4 files changed, 103 insertions(+), 11 deletions(-)

diff --git a/Documentation/kbuild/makefiles.txt 
b/Documentation/kbuild/makefiles.txt
index 13f888a..250729b 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -23,10 +23,11 @@ This document describes the Linux kernel Makefiles.
=== 4 Host Program support
   --- 4.1 Simple Host Program
   --- 4.2 Composite Host Programs
-  --- 4.3 Using C++ for host programs
-  --- 4.4 Controlling compiler options for host programs
-  --- 4.5 When host programs are actually built
-  --- 4.6 Using hostprogs-$(CONFIG_FOO)
+  --- 4.3 Defining shared libraries
+  --- 4.4 Using C++ for host programs
+  --- 4.5 Controlling compiler options for host programs
+  --- 4.6 When host programs are actually built
+  --- 4.7 Using hostprogs-$(CONFIG_FOO)
 
=== 5 Kbuild clean infrastructure
 
@@ -643,7 +644,29 @@ Both possibilities are described in the following.
Finally, the two .o files are linked to the executable, lxdialog.
Note: The syntax -y is not permitted for host-programs.
 
 4.3 Using C++ for host programs
+--- 4.3 Defining shared libraries
+
+   Objects with extension .so are considered shared libraries, and
+   will be compiled as position independent objects.
+   Kbuild provides support for shared libraries, but the usage
+   shall be restricted.
+   In the following example the libkconfig.so shared library is used
+   to link the executable conf.
+
+   Example:
+   #scripts/kconfig/Makefile
+   hostprogs-y := conf
+   conf-objs   := conf.o libkconfig.so
+   libkconfig-objs := expr.o type.o
+
+   Shared libraries always require a corresponding -objs line, and
+   in the example above the shared library libkconfig is composed by
+   the two objects expr.o and type.o.
+   expr.o and type.o will be built as position independent code and
+   linked as a shared library libkconfig.so. C++ is not supported for
+   shared libraries.
+
+--- 4.4 Using C++ for host programs
 
kbuild offers support for host programs written in C++. This was
introduced solely to support kconfig, and is not recommended
@@ -666,7 +689,7 @@ Both possibilities are described in the following.
qconf-cxxobjs := qconf.o
qconf-objs:= check.o
 
 4.4 Controlling compiler options for host programs
+--- 4.5 Controlling compiler options for host programs
 
When compiling host programs, it is possible to set specific flags.
The programs will always be compiled utilising $(HOSTCC) passed
@@ -694,7 +717,7 @@ Both possibilities are described in the following.
When linking qconf, it will be passed the extra option
"-L$(QTDIR)/lib".
 
 4.5 When host programs are actually built
+--- 4.6 When host programs are actually built
 
Kbuild will only build host-programs when they are referenced
as a prerequisite.
@@ -725,7 +748,7 @@ Both possibilities are described in the following.
This will tell kbuild to build lxdialog even if not referenced in
any rule.
 
 4.6 Using hostprogs-$(CONFIG_FOO)
+--- 4.7 Using hostprogs-$(CONFIG_FOO)
 
A typical pattern in a Kbuild file looks like this:
 
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 0d1ca5b..11602e5 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -60,7 +60,7 @@ endif
 endif
 
 # Do not include host rules unless needed
-ifneq ($(hostprogs-y)$(hostprogs-m),)
+ifneq 
($(hostprogs-y)$(hostprogs-m)$(hostlibs-y)$(hostlibs-m)$(hostcxxlibs-y)$(hostcxxlibs-m),)
 include scripts/Makefile.host
 endif
 
diff --git a/scripts/Makefile.clean b/scripts/Makefile.clean
index 55c96cb..e4e88ab 100644
--- a/scripts/Makefile.clean
+++ b/scripts/Makefile.clean
@@ -38,7 +38,8 @@ subdir-ymn:= $(addprefix $(obj)/,$(subdir-ymn))
 __clean-files  := $(extra-y) $(extra-m) $(extra-)   \
   $(always) $(targets) $(clean-files)   \
   $(host-progs) \
-  $(hostprogs-y) $(hostprogs-m) $(hostprogs-)
+  $(hostprogs-y) $(hostprogs-m) $(hostprogs-) \
+  $(hostlibs-y) $(hostlibs-m) $(hostlibs-)
 
 __clean-files   := $(filter-out $(no-clean-files), $(__clean-files))
 
diff --git 

[PATCH v7 6/6] Add sancov plugin

2016-04-22 Thread Emese Revfy
The sancov gcc plugin inserts a __sanitizer_cov_trace_pc() call
at the start of basic blocks.

This plugin is a helper plugin for the kcov feature. It supports
all gcc versions with plugin support (from gcc-4.5 on).
It is based on the gcc commit "Add fuzzing coverage support" by Dmitry Vyukov
(https://gcc.gnu.org/viewcvs/gcc?limit_changes=0=revision=231296).

Signed-off-by: Emese Revfy 
---
 Makefile|  10 +--
 arch/Kconfig|   9 +++
 arch/x86/purgatory/Makefile |   2 +
 lib/Kconfig.debug   |   2 +
 scripts/Makefile.gcc-plugins|  18 +
 scripts/gcc-plugins/Makefile|   5 ++
 scripts/gcc-plugins/sancov_plugin.c | 144 
 7 files changed, 181 insertions(+), 9 deletions(-)
 create mode 100644 scripts/gcc-plugins/sancov_plugin.c

diff --git a/Makefile b/Makefile
index 22f0e1b..f09f2bf 100644
--- a/Makefile
+++ b/Makefile
@@ -365,7 +365,7 @@ LDFLAGS_MODULE  =
 CFLAGS_KERNEL  =
 AFLAGS_KERNEL  =
 CFLAGS_GCOV= -fprofile-arcs -ftest-coverage
-CFLAGS_KCOV= -fsanitize-coverage=trace-pc
+CFLAGS_KCOV:= $(call cc-option,-fsanitize-coverage=trace-pc,)
 
 
 # Use USERINCLUDE when you must reference the UAPI directories only.
@@ -685,14 +685,6 @@ endif
 endif
 KBUILD_CFLAGS += $(stackp-flag)
 
-ifdef CONFIG_KCOV
-  ifeq ($(call cc-option, $(CFLAGS_KCOV)),)
-$(warning Cannot use CONFIG_KCOV: \
- -fsanitize-coverage=trace-pc is not supported by compiler)
-CFLAGS_KCOV =
-  endif
-endif
-
 ifeq ($(cc-name),clang)
 KBUILD_CPPFLAGS += $(call cc-option,-Qunused-arguments,)
 KBUILD_CPPFLAGS += $(call cc-option,-Wno-unknown-warning-option,)
diff --git a/arch/Kconfig b/arch/Kconfig
index e783429..5d856c8 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -380,6 +380,15 @@ config GCC_PLUGIN_CYC_COMPLEXITY
  N = the number of nodes
  P = the number of connected components (exit nodes).
 
+config GCC_PLUGIN_SANCOV
+   bool
+   depends on GCC_PLUGINS
+   help
+ This plugin inserts a __sanitizer_cov_trace_pc() call at the start of
+ basic blocks. It supports all gcc versions with plugin support (from
+ gcc-4.5 on). It is based on the commit "Add fuzzing coverage support"
+ by Dmitry Vyukov .
+
 config HAVE_CC_STACKPROTECTOR
bool
help
diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile
index 12734a9..ac58c16 100644
--- a/arch/x86/purgatory/Makefile
+++ b/arch/x86/purgatory/Makefile
@@ -8,6 +8,8 @@ PURGATORY_OBJS = $(addprefix $(obj)/,$(purgatory-y))
 LDFLAGS_purgatory.ro := -e purgatory_start -r --no-undefined -nostdlib -z 
nodefaultlib
 targets += purgatory.ro
 
+KCOV_INSTRUMENT := n
+
 # Default KBUILD_CFLAGS can have -pg option set when FTRACE is enabled. That
 # in turn leaves some undefined symbols like __fentry__ in purgatory and not
 # sure how to relocate those. Like kexec-tools, use custom flags.
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 4fff4b0..616f7ed 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -708,6 +708,8 @@ config KCOV
bool "Code coverage for fuzzing"
depends on ARCH_HAS_KCOV
select DEBUG_FS
+   select GCC_PLUGINS
+   select GCC_PLUGIN_SANCOV
help
  KCOV exposes kernel code coverage information in a form suitable
  for coverage-guided fuzzing (randomized testing).
diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins
index 282d63a..33ab13e 100644
--- a/scripts/Makefile.gcc-plugins
+++ b/scripts/Makefile.gcc-plugins
@@ -2,8 +2,23 @@ ifdef CONFIG_GCC_PLUGINS
   __PLUGINCC := $(call cc-ifversion, -ge, 0408, $(HOSTCXX), $(HOSTCC))
   PLUGINCC := $(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-plugin.sh 
"$(__PLUGINCC)" "$(HOSTCXX)" "$(CC)")
 
+  SANCOV_PLUGIN := -fplugin=$(objtree)/scripts/gcc-plugins/sancov_plugin.so
+
   gcc-plugin-$(CONFIG_GCC_PLUGIN_CYC_COMPLEXITY)   += 
cyc_complexity_plugin.so
 
+  ifdef CONFIG_GCC_PLUGIN_SANCOV
+ifeq ($(CFLAGS_KCOV),)
+  # It is needed because of the gcc-plugin.sh and gcc version checks.
+  gcc-plugin-$(CONFIG_GCC_PLUGIN_SANCOV)   += sancov_plugin.so
+
+  ifneq ($(PLUGINCC),)
+CFLAGS_KCOV := $(SANCOV_PLUGIN)
+  else
+$(error Cannot use CONFIG_KCOV: -fsanitize-coverage=trace-pc is not 
supported by compiler)
+  endif
+endif
+  endif
+
   GCC_PLUGINS_CFLAGS := $(addprefix -fplugin=$(objtree)/scripts/gcc-plugins/, 
$(gcc-plugin-y))
 
   ifeq ($(PLUGINCC),)
@@ -15,6 +30,9 @@ ifdef CONFIG_GCC_PLUGINS
 $(error error, your gcc version does not support plugins, you should 
upgrade it to gcc 4.5 at least)
   endif
 endif
+  else
+# SANCOV_PLUGIN can be only in CFLAGS_KCOV because avoid duplication.
+GCC_PLUGINS_CFLAGS := $(filter-out $(SANCOV_PLUGIN), $(GCC_PLUGINS_CFLAGS))
   endif
 
   KBUILD_CFLAGS += $(GCC_PLUGINS_CFLAGS)

Re: [PATCH] serial: mctrl_gpio: Drop support for out1-gpios and out2-gpios

2016-04-22 Thread Peter Hurley
On 04/22/2016 08:10 AM, Geert Uytterhoeven wrote:
> The OUT1 and OUT2 pins present on some legacy UARTs are basically GPIOs.
> It doesn't make much sense to emulate GPIOs using other GPIOs, hence
> drop support for that.

Thanks Geert.

Reviewed-by: Peter Hurley 




Re: [PATCH] ext4: Fix check of dqget() return value in ext4_ioctl_setproject()

2016-04-22 Thread Seth Forshee
On Tue, Mar 29, 2016 at 08:01:03AM -0500, Seth Forshee wrote:
> A failed call to dqget() returns an ERR_PTR() and not null. Fix
> the check in ext4_ioctl_setproject() to handle this correctly.
> 
> Fixes: 9b7365fc1c82 ("ext4: add FS_IOC_FSSETXATTR/FS_IOC_FSGETXATTR interface 
> support")
> Cc: sta...@vger.kernel.org # v4.5
> Signed-off-by: Seth Forshee 

Thought I'd check and see if this patch was forgotten, I sent it nearly
a month ago but the bug is still present.

Thanks,
Seth


Re: [PATCH RFC 10/22] block, bfq: add full hierarchical scheduling and cgroups support

2016-04-22 Thread Tejun Heo
Hello, Paolo.

On Fri, Apr 22, 2016 at 08:19:47PM +0200, Paolo Valente wrote:
> > So, a kworker would jump through different workqueues and issue IOs
> > for different writeback domains and the context can't be tied to the
> > issuing task.  The cgroup membership should be determined directly
> > from the bio.
> 
> Yes. My doubt arises from the fact that the only source of intense I/O
> is the dd (I have executed it alone). In contrast, group changes occur
> at a high frequency during all the execution of the dd. Apparently I
> cannot see any other I/O induced by the dd. Journaling issues sync
> requests.
> 
> >  cfq uses per-cgroup async queue.  I'm not sure how this
> > would map to bfq tho.
> 
> It’s the same. But this is the part I’m checking.

Ah, right, I was confused.  cic is always associated with the task and
yes a writeback worker can trigger blkcg changed events frequently as
it walks through different cgroups.  Is this an issue?

Thanks.

-- 
tejun


HELLO DEAR

2016-04-22 Thread Melissa Robert


Hello Dear,
how are you doing hope fine, I am (Melissa Robert) by name. i will like
to
know more about you believing that friendship is a free gift of nature.
Please get back to me as soon as possible through this my private Email.
(mr4785...@gmail.com)
thank you.



Re: [RFC][PATCH 00/31] implement atomic_fetch_$op

2016-04-22 Thread Kalle Valo
Fengguang Wu  writes:

>> OK, weirdness. I received the "BUILD SUCCESS" email without any arm64
>> builds listed, but I just received a build bot email telling me the
>> arm64 build was borked (which I know it is).
>
> Sorry, that may happen because even though most errors will be
> detected in the first hour or before the BUILD SUCCESS/DONE
> notification, the build/boot/performance tests for a particular branch
> may continue for days, during the time test coverage keeps growing.
> Which means it's possible to receive a build failure after receiving
> BUILD SUCCESS notification.
>
> In particular, 0-day bot classify 500+ kconfigs into 2 priority lists:
>
> P1: 100+ realtime priority kconfigs which should be finished before sending
> out BUILD SUCCESS notification
>
> P2: 400+ background priority kconfigs which may take hours to days to finish
>
> That split is a tradeoff between timeliness and completeness. It turns
> out to work well as long as we choose the suitable P1 list.
>
> So the more accurate interpretation of "BUILD SUCCESS/DONE" would be:
> 0day bot is working on your tree (no worry about out-of-service) and
> reached a major milestone.

Thanks, this is very useful information. But would it be also possible
to get a report about the P2 completion (or failure)?

-- 
Kalle Valo


Re: [PATCH v7 4/9] clk: mediatek: Add MT2701 clock support

2016-04-22 Thread Matthias Brugger



On 14/04/16 10:11, James Liao wrote:

From: Shunli Wang 

Add MT2701 clock support, include topckgen, apmixedsys,
infracfg, pericfg and subsystem clocks.

Signed-off-by: Shunli Wang 
Signed-off-by: James Liao 
Tested-by: John Crispin 


Reviewed-by: Matthias Brugger 


---
  drivers/clk/mediatek/Kconfig  |8 +
  drivers/clk/mediatek/Makefile |1 +
  drivers/clk/mediatek/clk-gate.c   |   52 ++
  drivers/clk/mediatek/clk-gate.h   |2 +
  drivers/clk/mediatek/clk-mt2701.c | 1356 +
  drivers/clk/mediatek/clk-mtk.c|   25 +
  drivers/clk/mediatek/clk-mtk.h|   34 +-
  7 files changed, 1475 insertions(+), 3 deletions(-)
  create mode 100644 drivers/clk/mediatek/clk-mt2701.c

diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
index dc224e6..1e56000 100644
--- a/drivers/clk/mediatek/Kconfig
+++ b/drivers/clk/mediatek/Kconfig
@@ -6,6 +6,14 @@ config COMMON_CLK_MEDIATEK
---help---
  Mediatek SoCs' clock support.

+config COMMON_CLK_MT2701
+   bool "Clock driver for Mediatek MT2701"
+   depends on COMMON_CLK
+   select COMMON_CLK_MEDIATEK
+   default ARCH_MEDIATEK
+   ---help---
+ This driver supports Mediatek MT2701 clocks.
+
  config COMMON_CLK_MT8135
bool "Clock driver for Mediatek MT8135"
depends on COMMON_CLK
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index 32e7222..5b2b91b 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -1,4 +1,5 @@
  obj-$(CONFIG_COMMON_CLK_MEDIATEK) += clk-mtk.o clk-pll.o clk-gate.o 
clk-apmixed.o
  obj-$(CONFIG_RESET_CONTROLLER) += reset.o
+obj-$(CONFIG_COMMON_CLK_MT2701) += clk-mt2701.o
  obj-$(CONFIG_COMMON_CLK_MT8135) += clk-mt8135.o
  obj-$(CONFIG_COMMON_CLK_MT8173) += clk-mt8173.o
diff --git a/drivers/clk/mediatek/clk-gate.c b/drivers/clk/mediatek/clk-gate.c
index 2a76901..65ad4ca 100644
--- a/drivers/clk/mediatek/clk-gate.c
+++ b/drivers/clk/mediatek/clk-gate.c
@@ -61,6 +61,22 @@ static void mtk_cg_clr_bit(struct clk_hw *hw)
regmap_write(cg->regmap, cg->clr_ofs, BIT(cg->bit));
  }

+static void mtk_cg_set_bit_no_setclr(struct clk_hw *hw)
+{
+   struct mtk_clk_gate *cg = to_mtk_clk_gate(hw);
+   u32 cgbit = BIT(cg->bit);
+
+   regmap_update_bits(cg->regmap, cg->sta_ofs, cgbit, cgbit);
+}
+
+static void mtk_cg_clr_bit_no_setclr(struct clk_hw *hw)
+{
+   struct mtk_clk_gate *cg = to_mtk_clk_gate(hw);
+   u32 cgbit = BIT(cg->bit);
+
+   regmap_update_bits(cg->regmap, cg->sta_ofs, cgbit, 0);
+}
+
  static int mtk_cg_enable(struct clk_hw *hw)
  {
mtk_cg_clr_bit(hw);
@@ -85,6 +101,30 @@ static void mtk_cg_disable_inv(struct clk_hw *hw)
mtk_cg_clr_bit(hw);
  }

+static int mtk_cg_enable_no_setclr(struct clk_hw *hw)
+{
+   mtk_cg_clr_bit_no_setclr(hw);
+
+   return 0;
+}
+
+static void mtk_cg_disable_no_setclr(struct clk_hw *hw)
+{
+   mtk_cg_set_bit_no_setclr(hw);
+}
+
+static int mtk_cg_enable_inv_no_setclr(struct clk_hw *hw)
+{
+   mtk_cg_set_bit_no_setclr(hw);
+
+   return 0;
+}
+
+static void mtk_cg_disable_inv_no_setclr(struct clk_hw *hw)
+{
+   mtk_cg_clr_bit_no_setclr(hw);
+}
+
  const struct clk_ops mtk_clk_gate_ops_setclr = {
.is_enabled = mtk_cg_bit_is_cleared,
.enable = mtk_cg_enable,
@@ -97,6 +137,18 @@ const struct clk_ops mtk_clk_gate_ops_setclr_inv = {
.disable= mtk_cg_disable_inv,
  };

+const struct clk_ops mtk_clk_gate_ops_no_setclr = {
+   .is_enabled = mtk_cg_bit_is_cleared,
+   .enable = mtk_cg_enable_no_setclr,
+   .disable= mtk_cg_disable_no_setclr,
+};
+
+const struct clk_ops mtk_clk_gate_ops_no_setclr_inv = {
+   .is_enabled = mtk_cg_bit_is_set,
+   .enable = mtk_cg_enable_inv_no_setclr,
+   .disable= mtk_cg_disable_inv_no_setclr,
+};
+
  struct clk * __init mtk_clk_register_gate(
const char *name,
const char *parent_name,
diff --git a/drivers/clk/mediatek/clk-gate.h b/drivers/clk/mediatek/clk-gate.h
index b182160..72ef89b 100644
--- a/drivers/clk/mediatek/clk-gate.h
+++ b/drivers/clk/mediatek/clk-gate.h
@@ -36,6 +36,8 @@ static inline struct mtk_clk_gate *to_mtk_clk_gate(struct 
clk_hw *hw)

  extern const struct clk_ops mtk_clk_gate_ops_setclr;
  extern const struct clk_ops mtk_clk_gate_ops_setclr_inv;
+extern const struct clk_ops mtk_clk_gate_ops_no_setclr;
+extern const struct clk_ops mtk_clk_gate_ops_no_setclr_inv;

  struct clk *mtk_clk_register_gate(
const char *name,
diff --git a/drivers/clk/mediatek/clk-mt2701.c 
b/drivers/clk/mediatek/clk-mt2701.c
new file mode 100644
index 000..b4db141
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt2701.c
@@ -0,0 +1,1356 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ * 

Re: linux-next: Tree for Apr 22 (adjust_autoksyms.sh)

2016-04-22 Thread Nicolas Pitre
On Fri, 22 Apr 2016, Randy Dunlap wrote:

> On 04/22/16 10:48, Nicolas Pitre wrote:
> > On Fri, 22 Apr 2016, Randy Dunlap wrote:
> > 
> >> on x86_64:
> >>
> >> I'm seeing:
> >>
> >> /bin/sh: scripts/adjust_autoksyms.sh: No such file or directory
> >> /local/lnx/next/linux-next-20160422/Makefile:937: recipe for target 
> >> 'vmlinux' failed
> >>
> >> when using O=subdir for the build output directory.
> >>
> >>
> >> Is there a missing $(objtree) somewhere?
> > 
> > Rather a $(srctree).  Please try the patch below.
> 
> Hi,
> 
> Yes, this patch helps, but I think there is still a problem.
> I think that trim needs to be done after CONFIG_BUILD_DOCSRC and possibly
> after CONFIG_SAMPLES are built.

The later is already taken care of with commit dd92478a15.

> At least CONFIG_BUILD_DOCSRC seems to
> cause this error:
> 
> Setup is 16508 bytes (padded to 16896 bytes).
> System is 6125 kB
> CRC 8aa70f94
> Kernel: arch/x86/boot/bzImage is ready  (#9)
> ERROR: "cn_del_callback" [Documentation/connector/cn_test.ko] undefined!
> ERROR: "cn_add_callback" [Documentation/connector/cn_test.ko] undefined!
> ERROR: "cn_netlink_send" [Documentation/connector/cn_test.ko] undefined!
> ../scripts/Makefile.modpost:91: recipe for target '__modpost' failed
> make[2]: *** [__modpost] Error 1

This one is indeed a problem.


Nicolas


Re: [PATCH v7 6/6] Add sancov plugin

2016-04-22 Thread Dmitry Vyukov
On Fri, Apr 22, 2016 at 8:27 PM, Emese Revfy  wrote:
> The sancov gcc plugin inserts a __sanitizer_cov_trace_pc() call
> at the start of basic blocks.
>
> This plugin is a helper plugin for the kcov feature. It supports
> all gcc versions with plugin support (from gcc-4.5 on).
> It is based on the gcc commit "Add fuzzing coverage support" by Dmitry Vyukov
> (https://gcc.gnu.org/viewcvs/gcc?limit_changes=0=revision=231296).

+syzkaller mailing list

> Signed-off-by: Emese Revfy 
> ---
>  Makefile|  10 +--
>  arch/Kconfig|   9 +++
>  arch/x86/purgatory/Makefile |   2 +
>  lib/Kconfig.debug   |   2 +
>  scripts/Makefile.gcc-plugins|  18 +
>  scripts/gcc-plugins/Makefile|   5 ++
>  scripts/gcc-plugins/sancov_plugin.c | 144 
> 
>  7 files changed, 181 insertions(+), 9 deletions(-)
>  create mode 100644 scripts/gcc-plugins/sancov_plugin.c
>
> diff --git a/Makefile b/Makefile
> index 22f0e1b..f09f2bf 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -365,7 +365,7 @@ LDFLAGS_MODULE  =
>  CFLAGS_KERNEL  =
>  AFLAGS_KERNEL  =
>  CFLAGS_GCOV= -fprofile-arcs -ftest-coverage
> -CFLAGS_KCOV= -fsanitize-coverage=trace-pc
> +CFLAGS_KCOV:= $(call cc-option,-fsanitize-coverage=trace-pc,)
>
>
>  # Use USERINCLUDE when you must reference the UAPI directories only.
> @@ -685,14 +685,6 @@ endif
>  endif
>  KBUILD_CFLAGS += $(stackp-flag)
>
> -ifdef CONFIG_KCOV
> -  ifeq ($(call cc-option, $(CFLAGS_KCOV)),)
> -$(warning Cannot use CONFIG_KCOV: \
> - -fsanitize-coverage=trace-pc is not supported by compiler)
> -CFLAGS_KCOV =
> -  endif
> -endif
> -
>  ifeq ($(cc-name),clang)
>  KBUILD_CPPFLAGS += $(call cc-option,-Qunused-arguments,)
>  KBUILD_CPPFLAGS += $(call cc-option,-Wno-unknown-warning-option,)
> diff --git a/arch/Kconfig b/arch/Kconfig
> index e783429..5d856c8 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -380,6 +380,15 @@ config GCC_PLUGIN_CYC_COMPLEXITY
>   N = the number of nodes
>   P = the number of connected components (exit nodes).
>
> +config GCC_PLUGIN_SANCOV
> +   bool
> +   depends on GCC_PLUGINS
> +   help
> + This plugin inserts a __sanitizer_cov_trace_pc() call at the start 
> of
> + basic blocks. It supports all gcc versions with plugin support (from
> + gcc-4.5 on). It is based on the commit "Add fuzzing coverage 
> support"
> + by Dmitry Vyukov .
> +
>  config HAVE_CC_STACKPROTECTOR
> bool
> help
> diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile
> index 12734a9..ac58c16 100644
> --- a/arch/x86/purgatory/Makefile
> +++ b/arch/x86/purgatory/Makefile
> @@ -8,6 +8,8 @@ PURGATORY_OBJS = $(addprefix $(obj)/,$(purgatory-y))
>  LDFLAGS_purgatory.ro := -e purgatory_start -r --no-undefined -nostdlib -z 
> nodefaultlib
>  targets += purgatory.ro
>
> +KCOV_INSTRUMENT := n
> +
>  # Default KBUILD_CFLAGS can have -pg option set when FTRACE is enabled. That
>  # in turn leaves some undefined symbols like __fentry__ in purgatory and not
>  # sure how to relocate those. Like kexec-tools, use custom flags.
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 4fff4b0..616f7ed 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -708,6 +708,8 @@ config KCOV
> bool "Code coverage for fuzzing"
> depends on ARCH_HAS_KCOV
> select DEBUG_FS
> +   select GCC_PLUGINS
> +   select GCC_PLUGIN_SANCOV
> help
>   KCOV exposes kernel code coverage information in a form suitable
>   for coverage-guided fuzzing (randomized testing).
> diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins
> index 282d63a..33ab13e 100644
> --- a/scripts/Makefile.gcc-plugins
> +++ b/scripts/Makefile.gcc-plugins
> @@ -2,8 +2,23 @@ ifdef CONFIG_GCC_PLUGINS
>__PLUGINCC := $(call cc-ifversion, -ge, 0408, $(HOSTCXX), $(HOSTCC))
>PLUGINCC := $(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-plugin.sh 
> "$(__PLUGINCC)" "$(HOSTCXX)" "$(CC)")
>
> +  SANCOV_PLUGIN := -fplugin=$(objtree)/scripts/gcc-plugins/sancov_plugin.so
> +
>gcc-plugin-$(CONFIG_GCC_PLUGIN_CYC_COMPLEXITY)   += 
> cyc_complexity_plugin.so
>
> +  ifdef CONFIG_GCC_PLUGIN_SANCOV
> +ifeq ($(CFLAGS_KCOV),)
> +  # It is needed because of the gcc-plugin.sh and gcc version checks.
> +  gcc-plugin-$(CONFIG_GCC_PLUGIN_SANCOV)   += sancov_plugin.so
> +
> +  ifneq ($(PLUGINCC),)
> +CFLAGS_KCOV := $(SANCOV_PLUGIN)
> +  else
> +$(error Cannot use CONFIG_KCOV: -fsanitize-coverage=trace-pc is not 
> supported by compiler)
> +  endif
> +endif
> +  endif
> +
>GCC_PLUGINS_CFLAGS := $(addprefix 
> -fplugin=$(objtree)/scripts/gcc-plugins/, $(gcc-plugin-y))
>
>ifeq ($(PLUGINCC),)
> @@ -15,6 +30,9 @@ ifdef CONFIG_GCC_PLUGINS
>  

Re: [PATCH] lib: Always NUL terminate ucs2_as_utf8

2016-04-22 Thread Matt Fleming
On Thu, 21 Apr, at 06:21:11PM, Laszlo Ersek wrote:
> 
> ... How about this instead?

Your patch looks fine to me. I've gone ahead and stuck it in the
urgent EFI queue.

Thanks everyone!


Re: [PATCH 1/2] KVM: x86: fix ordering of cr0 initialization code in vmx_cpu_reset

2016-04-22 Thread Bruce Rogers
>>> On 2/3/2016 at 04:18 PM, Nadav Amit  wrote: 
> Oops.
> 
> Anyhow, I see my patch has done a similar change in init_vmcb() , so you may
> want to revert it as well.
> 
> Nadav
> 
> Bruce Rogers  wrote:
> 
>> Commit d28bc9dd25ce reversed the order of two lines which initialize cr0,
>> allowing the current (old) cr0 value to mess up vcpu initialization.
>> This was observed in the checks for cr0 X86_CR0_WP bit in the context of
>> kvm_mmu_reset_context().  Besides, setting vcpu->arch.cr0 after vmx_set_cr0()
>> is completely redundant. Change the order back to ensure proper vcpu
>> intiialization.
>> 
>> Signed-off-by: Bruce Rogers 
>> ---
>> arch/x86/kvm/vmx.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>> index e2951b6..21507b4 100644
>> --- a/arch/x86/kvm/vmx.c
>> +++ b/arch/x86/kvm/vmx.c
>> @@ -4993,8 +4993,8 @@ static void vmx_vcpu_reset(struct kvm_vcpu *vcpu, bool 
> init_event)
>>  vmcs_write16(VIRTUAL_PROCESSOR_ID, vmx->vpid);
>> 
>>  cr0 = X86_CR0_NW | X86_CR0_CD | X86_CR0_ET;
>> -vmx_set_cr0(vcpu, cr0); /* enter rmode */
>>  vmx->vcpu.arch.cr0 = cr0;
>> +vmx_set_cr0(vcpu, cr0); /* enter rmode */
>>  vmx_set_cr4(vcpu, 0);
>>  vmx_set_efer(vcpu, 0);
>>  vmx_fpu_activate(vcpu);
>> -- 
>> 1.9.0
> 

I had not pursued this as the initial problem I was chasing ended up including 
some
undefined behavior.

Since, I've run into another failure which this patch addresses (ovmf based 
booting with
vcpu count >1 on older hardware), so I'll resend this one patch with updated 
info.

Also, it seems to me  that the init_vmcb() svm issue Nadav mentioned is no 
longer an
issue in the current master branch so I won't be addressing that.

Bruce



Re: fs: GPF in locked_inode_to_wb_and_lock_list

2016-04-22 Thread Dmitry Vyukov
On Thu, Apr 21, 2016 at 7:06 PM, Tejun Heo  wrote:
> Hello,
>
> (cc'ing Ilya, Jan and Jens)
>
> On Thu, Apr 21, 2016 at 12:00:38PM +0200, Dmitry Vyukov wrote:
>> On Thu, Apr 21, 2016 at 11:45 AM, Andrey Ryabinin
>>  wrote:
>> > 2016-04-21 11:35 GMT+03:00 Dmitry Vyukov :
>> >>
>> >> 818884dd:   48 8b 03mov(%rbx),%rax
>> >>
>> >> So whatever load ">bdi->wb" produces is a NULL deref. (is it wb
>> >> that is NULL?)
>> >
>> > Yes it's NULL wb, because there is only one load:
>> > mov(%rbx),%rax=>   rax = wb->bdi
>> > add$0x50,%rax =>   rax = >wb
>>
>>
>> I bet that wb becomes NULL on the second iteration of the loop. The
>> loop loops in case of a race with another thread, so it would also
>> explain why it is difficult to reproduce.
>>
>> Tejun, does it make any sense to you?
>
> Yeah, that makes sense.  I think the culprit is 43d1c0eb7e11 ("block:
> detach bdev inode from its wb in __blkdev_put()") which allows inode
> to wb association to be broken while other operations including
> writeback are in progress.  I thought it should be okay as the inode
> must be clean at that point but that obviously doesn't mean that there
> can be no writeback operations in flight.
>
> I hope we could eventually move away from the current model where we
> try to swap out an underlying data structure while upper layers may
> still be referring to it in the future but for now we can make sure
> the writeback operation is finished before detaching wb.
>
> Dmitry, I understand that the bug is difficult to reproduce but can
> you please give the following patch a try?


I've merged it into my tree and will restart the fuzzer and leave it
running for the weekend.
Though, yeah, it is difficult to reproduce...


> Thanks.
>
> diff --git a/fs/block_dev.c b/fs/block_dev.c
> index 20a2c02..209ea33 100644
> --- a/fs/block_dev.c
> +++ b/fs/block_dev.c
> @@ -1530,12 +1530,7 @@ static void __blkdev_put(struct block_device *bdev, 
> fmode_t mode, int for_part)
> kill_bdev(bdev);
>
> bdev_write_inode(bdev);
> -   /*
> -* Detaching bdev inode from its wb in __destroy_inode()
> -* is too late: the queue which embeds its bdi (along with
> -* root wb) can be gone as soon as we put_disk() below.
> -*/
> -   inode_detach_wb(bdev->bd_inode);
> +   inode_detach_blkdev_wb(bdev);
> }
> if (bdev->bd_contains == bdev) {
> if (disk->fops->release)
> diff --git a/include/linux/writeback.h b/include/linux/writeback.h
> index d0b5ca5..ec1f530 100644
> --- a/include/linux/writeback.h
> +++ b/include/linux/writeback.h
> @@ -230,6 +230,25 @@ static inline void inode_detach_wb(struct inode *inode)
>  }
>
>  /**
> + * inode_detach_blkdev_wb - disassociate a bd_inode from its wb
> + * @bdev: block_device of interest
> + *
> + * @bdev is being put for the last time.  Detaching bdev inode in
> + * __destroy_inode() is too late: the queue which embeds its bdi (along
> + * with root wb) can be gone as soon as the containing disk is put.
> + *
> + * This function dissociates @bdev->bd_inode from its wb.  The inode must
> + * be clean and no further operations should be started on it.
> + */
> +static inline void inode_detach_blkdev_wb(struct block_device *bdev)
> +{
> +   if (bdev->bd_inode->i_wb) {
> +   flush_delayed_work(>bd_inode->i_wb->dwork);
> +   inode_detach_wb(bdev->bd_inode);
> +   }
> +}
> +
> +/**
>   * wbc_attach_fdatawrite_inode - associate wbc and inode for fdatawrite
>   * @wbc: writeback_control of interest
>   * @inode: target inode
> @@ -277,6 +296,10 @@ static inline void inode_detach_wb(struct inode *inode)
>  {
>  }
>
> +static inline void inode_detach_blkdev_wb(struct block_device *bdev)
> +{
> +}
> +
>  static inline void wbc_attach_and_unlock_inode(struct writeback_control *wbc,
>struct inode *inode)
> __releases(>i_lock)


[GIT PULL][PATCH 0/3] Few small timekeeping updates for 4.7

2016-04-22 Thread John Stultz
Hey Thomas,
  Just wanted to send you my current queue for 4.7. Its fairly small.

The one unusal bit is the security_settime64() patch, which was
ok'ed to go in via the -tip tree by both Kees and Serge.

Let me know if you have any objections.

thanks
-john

Cc: Serge Hallyn 
Cc: James Morris 
Cc: "Serge E. Hallyn" 
Cc: Paul Moore 
Cc: Stephen Smalley 
Cc: Kees Cook 
Cc: Prarit Bhargava 
Cc: Richard Cochran 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 

If you prefer to pull:

The following changes since commit 9735a22799b9214d17d3c231fe377fc852f042e9:

  Linux 4.6-rc2 (2016-04-03 09:09:40 -0500)

are available in the git repository at:

  https://git.linaro.org/people/john.stultz/linux.git fortglx/4.7/time

for you to fetch changes up to 86d3473224b004f920c107206d181d37db735145:

  time: Introduce do_sys_settimeofday64() (2016-04-22 11:49:04 -0700)


Baolin Wang (2):
  security: Introduce security_settime64()
  time: Introduce do_sys_settimeofday64()

David Lechner (1):
  clocksource: Add missing include of of.h.

 include/linux/clocksource.h |  1 +
 include/linux/lsm_hooks.h   |  5 +++--
 include/linux/security.h| 20 +---
 include/linux/timekeeping.h | 17 +++--
 kernel/time/time.c  |  8 
 security/commoncap.c|  2 +-
 security/security.c |  2 +-
 7 files changed, 42 insertions(+), 13 deletions(-)

-- 
1.9.1



[PATCH 2/3] security: Introduce security_settime64()

2016-04-22 Thread John Stultz
From: Baolin Wang 

security_settime() uses a timespec, which is not year 2038 safe
on 32bit systems. Thus this patch introduces the security_settime64()
function with timespec64 type. We also convert the cap_settime() helper
function to use the 64bit types.

This patch then moves security_settime() to the header file as an
inline helper function so that existing users can be iteratively
converted.

None of the existing hooks is using the timespec argument and therefor
the patch is not making any functional changes.

Cc: Serge Hallyn ,
Cc: James Morris ,
Cc: "Serge E. Hallyn" ,
Cc: Paul Moore 
Cc: Stephen Smalley 
Cc: Kees Cook 
Cc: Prarit Bhargava 
Cc: Richard Cochran 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Reviewed-by: James Morris 
Signed-off-by: Baolin Wang 
[jstultz: Reworded commit message]
Signed-off-by: John Stultz 
---
 include/linux/lsm_hooks.h |  5 +++--
 include/linux/security.h  | 20 +---
 security/commoncap.c  |  2 +-
 security/security.c   |  2 +-
 4 files changed, 22 insertions(+), 7 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index cdee11c..41ab466 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -1190,7 +1190,8 @@
  * Return 0 if permission is granted.
  * @settime:
  * Check permission to change the system time.
- * struct timespec and timezone are defined in include/linux/time.h
+ * struct timespec64 is defined in include/linux/time64.h and timezone
+ * is defined in include/linux/time.h
  * @ts contains new time
  * @tz contains new timezone
  * Return 0 if permission is granted.
@@ -1327,7 +1328,7 @@ union security_list_options {
int (*quotactl)(int cmds, int type, int id, struct super_block *sb);
int (*quota_on)(struct dentry *dentry);
int (*syslog)(int type);
-   int (*settime)(const struct timespec *ts, const struct timezone *tz);
+   int (*settime)(const struct timespec64 *ts, const struct timezone *tz);
int (*vm_enough_memory)(struct mm_struct *mm, long pages);
 
int (*bprm_set_creds)(struct linux_binprm *bprm);
diff --git a/include/linux/security.h b/include/linux/security.h
index 157f0cb..35ac8d9 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -71,7 +71,7 @@ struct timezone;
 /* These functions are in security/commoncap.c */
 extern int cap_capable(const struct cred *cred, struct user_namespace *ns,
   int cap, int audit);
-extern int cap_settime(const struct timespec *ts, const struct timezone *tz);
+extern int cap_settime(const struct timespec64 *ts, const struct timezone *tz);
 extern int cap_ptrace_access_check(struct task_struct *child, unsigned int 
mode);
 extern int cap_ptrace_traceme(struct task_struct *parent);
 extern int cap_capget(struct task_struct *target, kernel_cap_t *effective, 
kernel_cap_t *inheritable, kernel_cap_t *permitted);
@@ -208,7 +208,13 @@ int security_capable_noaudit(const struct cred *cred, 
struct user_namespace *ns,
 int security_quotactl(int cmds, int type, int id, struct super_block *sb);
 int security_quota_on(struct dentry *dentry);
 int security_syslog(int type);
-int security_settime(const struct timespec *ts, const struct timezone *tz);
+int security_settime64(const struct timespec64 *ts, const struct timezone *tz);
+static inline int security_settime(const struct timespec *ts, const struct 
timezone *tz)
+{
+   struct timespec64 ts64 = timespec_to_timespec64(*ts);
+
+   return security_settime64(, tz);
+}
 int security_vm_enough_memory_mm(struct mm_struct *mm, long pages);
 int security_bprm_set_creds(struct linux_binprm *bprm);
 int security_bprm_check(struct linux_binprm *bprm);
@@ -462,10 +468,18 @@ static inline int security_syslog(int type)
return 0;
 }
 
+static inline int security_settime64(const struct timespec64 *ts,
+const struct timezone *tz)
+{
+   return cap_settime(ts, tz);
+}
+
 static inline int security_settime(const struct timespec *ts,
   const struct timezone *tz)
 {
-   return cap_settime(ts, tz);
+   struct timespec64 ts64 = timespec_to_timespec64(*ts);
+
+   return cap_settime(, tz);
 }
 
 static inline int security_vm_enough_memory_mm(struct mm_struct *mm, long 
pages)
diff --git a/security/commoncap.c b/security/commoncap.c
index 48071ed..2074bf6 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -111,7 +111,7 @@ int cap_capable(const struct cred *cred, struct 
user_namespace *targ_ns,
  * Determine whether the current process may set the system clock and timezone
  * information, 

Re: [PATCH] ARM: BCM5301X: Add DT entry for SPI controller and NOR flash

2016-04-22 Thread Florian Fainelli
On 18/04/16 23:56, Rafał Miłecki wrote:
> Controller is present on every BCM4708* board but only few devices have
> serial flash attached so mark it as disabled by default.
> 
> Signed-off-by: Rafał Miłecki 

Applied to devicetree/next, thanks!
-- 
Florian


[PATCH 3/3] time: Introduce do_sys_settimeofday64()

2016-04-22 Thread John Stultz
From: Baolin Wang 

The do_sys_settimeofday() function uses a timespec, which is not year
2038 safe on 32bit systems.

Thus this patch introduces do_sys_settimeofday64(), which allows us to
transition users of do_sys_settimeofday() to using 64bit time types.

Cc: Prarit Bhargava 
Cc: Richard Cochran 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Signed-off-by: Baolin Wang 
[jstultz: Include errno-base.h to avoid build issue on some arches]
Signed-off-by: John Stultz 
---
 include/linux/timekeeping.h | 17 +++--
 kernel/time/time.c  |  8 
 2 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index 96f37be..37dbacf 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -1,6 +1,8 @@
 #ifndef _LINUX_TIMEKEEPING_H
 #define _LINUX_TIMEKEEPING_H
 
+#include 
+
 /* Included from linux/ktime.h */
 
 void timekeeping_init(void);
@@ -11,8 +13,19 @@ extern int timekeeping_suspended;
  */
 extern void do_gettimeofday(struct timeval *tv);
 extern int do_settimeofday64(const struct timespec64 *ts);
-extern int do_sys_settimeofday(const struct timespec *tv,
-  const struct timezone *tz);
+extern int do_sys_settimeofday64(const struct timespec64 *tv,
+const struct timezone *tz);
+static inline int do_sys_settimeofday(const struct timespec *tv,
+ const struct timezone *tz)
+{
+   struct timespec64 ts64;
+
+   if (!tv)
+   return -EINVAL;
+
+   ts64 = timespec_to_timespec64(*tv);
+   return do_sys_settimeofday64(, tz);
+}
 
 /*
  * Kernel time accessors
diff --git a/kernel/time/time.c b/kernel/time/time.c
index be115b0..a4064b6 100644
--- a/kernel/time/time.c
+++ b/kernel/time/time.c
@@ -160,15 +160,15 @@ static inline void warp_clock(void)
  * various programs will get confused when the clock gets warped.
  */
 
-int do_sys_settimeofday(const struct timespec *tv, const struct timezone *tz)
+int do_sys_settimeofday64(const struct timespec64 *tv, const struct timezone 
*tz)
 {
static int firsttime = 1;
int error = 0;
 
-   if (tv && !timespec_valid(tv))
+   if (tv && !timespec64_valid(tv))
return -EINVAL;
 
-   error = security_settime(tv, tz);
+   error = security_settime64(tv, tz);
if (error)
return error;
 
@@ -186,7 +186,7 @@ int do_sys_settimeofday(const struct timespec *tv, const 
struct timezone *tz)
}
}
if (tv)
-   return do_settimeofday(tv);
+   return do_settimeofday64(tv);
return 0;
 }
 
-- 
1.9.1



Re: [PATCH v7 00/10] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 1/3: iommu changes

2016-04-22 Thread Alex Williamson
On Fri, 22 Apr 2016 14:31:18 +0200
Eric Auger  wrote:

> Hi Alex,
> On 04/21/2016 09:32 PM, Alex Williamson wrote:
> > On Thu, 21 Apr 2016 14:18:09 +0200
> > Eric Auger  wrote:
> >   
> >> Hi Alex, Robin,
> >> On 04/19/2016 06:56 PM, Eric Auger wrote:  
> >>> This series introduces the dma-reserved-iommu api used to:
> >>>
> >>> - create/destroy an iova domain dedicated to reserved iova bindings
> >>> - map/unmap physical addresses onto reserved IOVAs.
> >>> - search for an existing reserved iova mapping matching a PA window
> >>> - determine whether an msi needs to be iommu mapped
> >>> - translate an msi_msg PA address into its IOVA counterpart
> >>
> >> Following Robin's review, I understand one important point we have to
> >> clarify is how much this API has to be generic.
> >>
> >> I agree with Robin on the fact there is quite a lot of duplication
> >> between this dma-reserved-iommu implementation and dma-iommu
> >> implementation. Maybe we could consider an msi-mapping API
> >> implementation upon dma-iommu.c. This implementation would add MSI
> >> doorbell binding list management, including, ref counting and locking.
> >>
> >> We would need to add a map/unmap function taking an iova/pa/size as
> >> parameters in current dma-iommu.c
> >>
> >> An important assumption is that the dma-mapping API and the msi-mapping
> >> API must not be used concurrently (be would be trying to use the same
> >> cookie to store a different iova_domain).
> >>
> >> Any thought/suggestion?  
> > 
> > Hi Eric,
> > 
> > I'm not attached to a generic interface, the important part for me is
> > that if we have an iommu domain with space reserved for MSI, the MSI
> > setup and allocation code should handle that so we don't need to play
> > the remapping tricks between vfio-pci and a vfio iommu driver that we
> > saw in early drafts of this.  My first inclination is always to try to
> > make a generic, re-usable interface, but I apologize if that's led us
> > astray here and we really do want the more simple, MSI specific
> > interface.
> > 
> > For the IOMMU API, rather than just a DOMAIN_ATTR_MSI_MAPPING flag,
> > what about DOMAIN_ATTR_MSI_GEOMETRY with both a get and set attribute?
> > Maybe something like:
> > 
> > struct iommu_domain_msi_geometry {
> > dma_addr_t  aperture_start;
> > dma_addr_t  aperture_end;
> > boolfixed; /* or 'programmable' depending on your polarity 
> > preference */
> > };
> > 
> > Calling \get\ on arm would return { 0, 0, false }, indicating it's
> > programmable, \set\ would allocate the iovad as specified.  That would
> > make it very easy to expand the API to x86 with reporting of the fixed
> > MSI range and it operates within the existing IOMMU API interfaces.
> > Thanks,  
> Yes I would be happy to handle this x86 query requirement. I would be
> more inclined to define it at "MSI mapping API" level since the IOMMU
> API implementation does not handle iova allocation, as Robin argued as
> the beginning. When "MSI MAPPING API" CONFIG is unset I would return
> default x86 aperture.
> 
> Does it make sense?

It's not entirely clear to me if x86 would be participating in this MSI
mapping API given the implicit handling within iommu/irq-remapping.
It might make sense if x86 iommus simply left a gap in their existing
geometry reporting through the iommu api.  I guess we'll see in your
next draft ;)  Thanks,

Alex


Re: [PATCH v2 1/1] arm64: dts: NS2 secondary core enablement via PSCI

2016-04-22 Thread Florian Fainelli
On 20/04/16 10:40, Luke Starrett wrote:
> Declare PSCI-1.0 node and enable CPU_ON method via PSCI.  Spin-table
> memreserve has been removed as well as syscon based reset, as PSCI-1.0
> expects reset implementation in firmware.
> 
> Signed-off-by: Luke Starrett 

Applied with Scott's Ack, thanks Luke!
-- 
Florian


Re: [PATCH] irqdomain: fix compare_const_fl.cocci warnings

2016-04-22 Thread Jon Hunter

On 22/04/16 20:00, Julia Lawall wrote:
> On Fri, 22 Apr 2016, Jon Hunter wrote:
> 
>>
>> On 20/04/16 17:49, Julia Lawall wrote:
>>>  Move constants to the right of binary operators.
>>>
>>> Generated by: scripts/coccinelle/misc/compare_const_fl.cocci
>>>
>>> Signed-off-by: Fengguang Wu 
>>> Signed-off-by: Julia Lawall 
>>> ---
>>>
>>> Not a big deal, but the transformed code looks better to me.
>>>
>>>  irqdomain.c |2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> --- a/kernel/irq/irqdomain.c
>>> +++ b/kernel/irq/irqdomain.c
>>> @@ -618,7 +618,7 @@ unsigned int irq_create_fwspec_mapping(s
>>>  * If the trigger type has not been set yet, then set
>>>  * it now and return the interrupt number.
>>>  */
>>> -   if (IRQ_TYPE_NONE == irq_get_trigger_type(virq)) {
>>> +   if (irq_get_trigger_type(virq) == IRQ_TYPE_NONE) {
>>> irq_set_irq_type(virq, type);
>>> return virq;
>>> }
>>
>> What branch is this from? Looks very familiar and related to some
>> changes I have been working on, but in my latest version I already have
>> this as shown above [0].
> 
> Sorry, I didn't save that information.  If it's done, it's done.  Sorry 
> for the noise.

No problem. I am wondering if this was based off an earlier branch on my
github tree (as I know that kbuild is trawling these) and I have never
posted a patch publicly with the above.

Cheers
Jon


Re: [PATCH] mm: Fix incorrect pfn passed to untrack_pfn in remap_pfn_range

2016-04-22 Thread Andrew Morton
On Fri, 22 Apr 2016 18:31:28 +0800 Yongji Xie  wrote:

> We used generic hooks in remap_pfn_range to help archs to
> track pfnmap regions. The code is something like:
> 
> int remap_pfn_range()
> {
>   ...
>   track_pfn_remap(vma, , pfn, addr, PAGE_ALIGN(size));
>   ...
>   pfn -= addr >> PAGE_SHIFT;
>   ...
>   untrack_pfn(vma, pfn, PAGE_ALIGN(size));
>   ...
> }
> 
> Here we can easily find the pfn is changed but not recovered
> before untrack_pfn() is called. That's incorrect.

What are the runtime effects of this bug?

> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -1755,6 +1755,7 @@ int remap_pfn_range(struct vm_area_struct *vma, 
> unsigned long addr,
>   break;
>   } while (pgd++, addr = next, addr != end);
>  
> + pfn += (end - PAGE_ALIGN(size)) >> PAGE_SHIFT;
>   if (err)
>   untrack_pfn(vma, pfn, PAGE_ALIGN(size));

I'm having trouble understanding this.  Wouldn't it be better to simply
save the track_pfn_remap() call's `pfn' arg in a new local variable?



Re: [PATCH 0/7] IB/hfi1: Remove write() and use ioctl() for user access

2016-04-22 Thread Dennis Dalessandro

On Wed, Apr 20, 2016 at 02:36:16PM -0600, Jason Gunthorpe wrote:

On Thu, Apr 14, 2016 at 01:52:44PM -0400, Dennis Dalessandro wrote:

The eprom device is for low level programming of the eprom on the
chip. We do not use i2c for this because the eprom is directly
attached to the chip and not accessible via i2c, requires register
access.


Okay, but the twsi.c is still not acceptable in a driver, use the i2c
subsystem to talk to the qsfps. Open coding i2c is not OK.


Yeah, I mentioned this at OFA. We are looking at reworking this.


The char dev(s) are also done wrong, there is no set to 'kobj.parent'
and there are empty release functions. There are certainly
use-after-free bugs between close and device removal, someone needs to
audit all of this carefully.

The patch forgets compat_ioctl.


We will take a look at this.


Stuff like this should be a build bug:
/* NOTE: assumes unsigned long is 8 bytes */


Our Kconfig depends on X86_64. Should we add a BUILD_BUG_ON or something?


The 'goto on success' in hfi1_cdev_init is an anti-pattern, don't do it.


Can fix.


Even if the char dev stays, creating two whole sysfs classes seems
really unnecessary. Surely there is a better place to attach the cdev.

And this is just outrageous:

   if (atomic_inc_return(_count) == 1) {
   ret = hfi1_cdev_init(0, class_name(), _file_ops,
_cdev, _device,
true);
   if (ret)

I can see an argument for a per-device char dev (as Christoph says,
that is not entirely uncommon) but this is a multi-device char dev


We are discussing what can be done about this internally. On that note we 
are also looking at what we can do about the twsi as mentioned above, also 
the eprom, ui, and snoop. We'll send the actual plan for each issue to 
linux-rdma for feedback soon. 

We are certainly not opposed to improving these areas of the code. So long 
as we can maintain the same functionality, which seems doable. It's just 
that no one has spoken up about these things in the 9+ months since the 
driver was added. We need a bit of time to get it all sorted out.


-Denny


Zádost!!

2016-04-22 Thread P.Brt



Jsem zastupujicí investicní zajem ze strany Dubaji, pro ktere hledáme vasi
ucast. Odpoved na e-mailu nize v pripade zajmu.

E-mail: pbrt...@gmail.com




Re: [PATCH] irqdomain: fix compare_const_fl.cocci warnings

2016-04-22 Thread Julia Lawall


On Fri, 22 Apr 2016, Thomas Gleixner wrote:

> On Wed, 20 Apr 2016, Julia Lawall wrote:
> 
> >  Move constants to the right of binary operators.
> > 
> > Generated by: scripts/coccinelle/misc/compare_const_fl.cocci
> > 
> > Signed-off-by: Fengguang Wu 
> > Signed-off-by: Julia Lawall 
> 
> This SOB chain looks wrong. Who is the author?

The script?

julia


Re: [PATCH] irqdomain: fix compare_const_fl.cocci warnings

2016-04-22 Thread Julia Lawall


On Fri, 22 Apr 2016, Jon Hunter wrote:

> 
> On 20/04/16 17:49, Julia Lawall wrote:
> >  Move constants to the right of binary operators.
> > 
> > Generated by: scripts/coccinelle/misc/compare_const_fl.cocci
> > 
> > Signed-off-by: Fengguang Wu 
> > Signed-off-by: Julia Lawall 
> > ---
> > 
> > Not a big deal, but the transformed code looks better to me.
> > 
> >  irqdomain.c |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > --- a/kernel/irq/irqdomain.c
> > +++ b/kernel/irq/irqdomain.c
> > @@ -618,7 +618,7 @@ unsigned int irq_create_fwspec_mapping(s
> >  * If the trigger type has not been set yet, then set
> >  * it now and return the interrupt number.
> >  */
> > -   if (IRQ_TYPE_NONE == irq_get_trigger_type(virq)) {
> > +   if (irq_get_trigger_type(virq) == IRQ_TYPE_NONE) {
> > irq_set_irq_type(virq, type);
> > return virq;
> > }
> 
> What branch is this from? Looks very familiar and related to some
> changes I have been working on, but in my latest version I already have
> this as shown above [0].

Sorry, I didn't save that information.  If it's done, it's done.  Sorry 
for the noise.

julia

> Cheers
> Jon
> 
> [0] http://marc.info/?l=linux-tegra=146115064322071=2
> 
> 


Re: [PATCH RFC 10/22] block, bfq: add full hierarchical scheduling and cgroups support

2016-04-22 Thread Paolo Valente

Il giorno 22/apr/2016, alle ore 20:41, Tejun Heo  ha scritto:

> Hello, Paolo.
> 
> On Fri, Apr 22, 2016 at 08:19:47PM +0200, Paolo Valente wrote:
>>> So, a kworker would jump through different workqueues and issue IOs
>>> for different writeback domains and the context can't be tied to the
>>> issuing task.  The cgroup membership should be determined directly
>>> from the bio.
>> 
>> Yes. My doubt arises from the fact that the only source of intense I/O
>> is the dd (I have executed it alone). In contrast, group changes occur
>> at a high frequency during all the execution of the dd. Apparently I
>> cannot see any other I/O induced by the dd. Journaling issues sync
>> requests.
>> 
>>> cfq uses per-cgroup async queue.  I'm not sure how this
>>> would map to bfq tho.
>> 
>> It’s the same. But this is the part I’m checking.
> 
> Ah, right, I was confused.  cic is always associated with the task and
> yes a writeback worker can trigger blkcg changed events frequently as
> it walks through different cgroups.  Is this an issue?
> 

That’s exactly the source of my confusion: why does the worker walk through 
different cgroups all the time if the I/O is originated by the same process, 
which never changes group?

Thanks,
Paolo

> Thanks.
> 
> -- 
> tejun



[PATCH 1/3] clocksource: Add missing include of of.h.

2016-04-22 Thread John Stultz
From: David Lechner 

This header uses OF_DELCARE_1 which is defined in linux/of.h.

This fixes getting unhelpful compiler error messages about missing ')'
before a string constant.

Cc: Prarit Bhargava 
Cc: Richard Cochran 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Signed-off-by: David Lechner 
Signed-off-by: John Stultz 
---
 include/linux/clocksource.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
index a307bf6..44a1aff 100644
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
-- 
1.9.1



[PATCH] KVM: x86: fix ordering of cr0 initialization code in vmx_cpu_reset

2016-04-22 Thread Bruce Rogers
Commit d28bc9dd25ce reversed the order of two lines which initialize cr0,
allowing the current (old) cr0 value to mess up vcpu initialization.
This was observed in the checks for cr0 X86_CR0_WP bit in the context of
kvm_mmu_reset_context(). Besides, setting vcpu->arch.cr0 after vmx_set_cr0()
is completely redundant. Change the order back to ensure proper vcpu
initialization.

The combination of booting with ovmf firmware when guest vcpus > 1 and kvm's
ept=N option being set results in a VM-entry failure. This patch fixes that.

Signed-off-by: Bruce Rogers 
---
 arch/x86/kvm/vmx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index ee1c8a9..ab4a387 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -5046,8 +5046,8 @@ static void vmx_vcpu_reset(struct kvm_vcpu *vcpu, bool 
init_event)
vmcs_write16(VIRTUAL_PROCESSOR_ID, vmx->vpid);
 
cr0 = X86_CR0_NW | X86_CR0_CD | X86_CR0_ET;
-   vmx_set_cr0(vcpu, cr0); /* enter rmode */
vmx->vcpu.arch.cr0 = cr0;
+   vmx_set_cr0(vcpu, cr0); /* enter rmode */
vmx_set_cr4(vcpu, 0);
vmx_set_efer(vcpu, 0);
vmx_fpu_activate(vcpu);
-- 
1.9.0



Re: [PATCH RFC 10/22] block, bfq: add full hierarchical scheduling and cgroups support

2016-04-22 Thread Tejun Heo
Hello, Paolo.

On Fri, Apr 22, 2016 at 09:05:14PM +0200, Paolo Valente wrote:
> > Ah, right, I was confused.  cic is always associated with the task and
> > yes a writeback worker can trigger blkcg changed events frequently as
> > it walks through different cgroups.  Is this an issue?
> 
> That’s exactly the source of my confusion: why does the worker walk
> through different cgroups all the time if the I/O is originated by
> the same process, which never changes group?

Because the workqueue workers aren't tied to individual workqueues,
they wander around serving different workqueues.  This might change if
we eventually update workqueues to be cgroup aware but for now it's
expected to happen.

Thanks.

-- 
tejun


Re: [PATCH 1/3] mfd: add Cypress FM33256B Processor Companion driver

2016-04-22 Thread Rob Herring
On Wed, Apr 20, 2016 at 01:07:49PM +0200, Jeppe Ledet-Pedersen wrote:
> This patch adds support for the Cypress Semiconductor FM33256B processor
> companion. The device contains a 256 kbit FRAM, an RTC, a supply voltage
> monitor, and a watchdog timer.
> 
> Signed-off-by: Jeppe Ledet-Pedersen 
> ---
>  Documentation/devicetree/bindings/mfd/fm33256b.txt |  30 ++
>  MAINTAINERS|   6 +
>  drivers/mfd/Kconfig|  16 +
>  drivers/mfd/Makefile   |   1 +
>  drivers/mfd/fm33256b.c | 488 
> +
>  include/linux/mfd/fm33256b.h   |  76 
>  6 files changed, 617 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/fm33256b.txt
>  create mode 100644 drivers/mfd/fm33256b.c
>  create mode 100644 include/linux/mfd/fm33256b.h
> 
> diff --git a/Documentation/devicetree/bindings/mfd/fm33256b.txt 
> b/Documentation/devicetree/bindings/mfd/fm33256b.txt
> new file mode 100644
> index 000..6591c94
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/fm33256b.txt
> @@ -0,0 +1,30 @@
> +Device-tree bindings for Cypress Semiconductor FM33256B Processor Companion
> +---
> +
> +Required properties:
> +- compatible: must be "cypress,fm33256b".
> +- reg: SPI chip select
> +- spi-max-frequency: Max SPI frequency to use (< 1600)
> +
> +Optional properties:
> +- cypress,charge-enabled: enable trickle charger

What does the driver do if charging is disabled? Would using 'status = 
"disabled"' be any different?
 
> +- cypress,charge-fast: enable fast (1 mA) charging

What does fast mean?

I think it is time for a common binding here. There's all sorts of 
variations on setting the charge current in bindings. Add something like 
"charge-current-microamp" in power_supply.txt and use it here. Then 
1000uA implies "fast charge".

> +
> +The MFD exposes two subdevices:
> +- The FRAM: "cypress,fm33256b-fram"
> +- The RTC: "cypress,fm33256b-rtc"
> +
> +Example:
> +
> +spi1: spi@f800800 {
> + status = "okay";
> + cs-gpios = < 25 0>;
> +
> + fm33256b@0 {
> + compatible = "cypress,fm33256b";
> + spi-max-frequency = <1000>;
> + cypress,charge-enabled;
> + cypress,charge-fast;
> + reg = <0>;
> + };

Where's the 2nd sub device?

> +};


Re: [PATCH v2 2/2] ARM: dts: dra7x: Support QSPI MODE-0 operation at 64MHz

2016-04-22 Thread Rob Herring
On Wed, Apr 20, 2016 at 05:03:00PM +0530, Vignesh R wrote:
> According to Data Manual(SPRS915P) of AM57x, TI QSPI controller on
> DRA74(rev 1.1+)/DRA72 EVM can support up to 64MHz in MODE-0, whereas
> MODE-3 is limited to 48MHz. Hence, switch to MODE-0 for better
> throughput.
> 
> Signed-off-by: Vignesh R 
> ---
> 
> v2: rebased on linux-next 20160419 to include moving to
> dra72-evm-common.dtsi
> 
> 
>  Documentation/devicetree/bindings/spi/ti_qspi.txt | 7 +++
>  arch/arm/boot/dts/dra7-evm.dts| 6 ++
>  arch/arm/boot/dts/dra72-evm-common.dtsi   | 6 ++
>  3 files changed, 11 insertions(+), 8 deletions(-)

Acked-by: Rob Herring 


Re: [PATCH v2 1/2] Documentation: DT: vdma: Add clock support for vdma

2016-04-22 Thread Rob Herring
On Wed, Apr 20, 2016 at 05:13:18PM +0530, Kedareswara rao Appana wrote:
> This patch updates the binding doc with clock description
> for vdma.
> 
> Signed-off-by: Kedareswara rao Appana 
> ---
> Changes for v2:
> --> Listed down all the clocks supported by the h/w
> as suggested by the Datta.
> --> Used IP clock names instead of shortcut clock names.
> 
>  Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt 
> b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
> index fcc2b65..afe9eb7 100644
> --- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
> +++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
> @@ -21,6 +21,11 @@ Required properties:
>  - dma-channel child node: Should have at least one channel and can have up to
>   two channels per device. This node specifies the properties of each
>   DMA channel (see child node properties below).
> +- clocks: Input clock specifier. Refer to common clock bindings.
> +- clock-names: List of input clocks "s_axi_lite_aclk", "m_axi_mm2s_aclk"
> +"m_axi_s2mm_aclk", "m_axis_mm2s_aclk", "s_axis_s2mm_aclk"
> +(list of input cloks may vary based on the ip configuration.

s/cloks/clocks/

> + see clock bindings for more info).

This does not make sense. The common clock binding is going to tell me 
more about how the clocks vary?

You need to define here how the clocks can vary.


Re: linux-next: Tree for Apr 22 (adjust_autoksyms.sh)

2016-04-22 Thread Nicolas Pitre
On Fri, 22 Apr 2016, Nicolas Pitre wrote:

> On Fri, 22 Apr 2016, Randy Dunlap wrote:
> 
> > Yes, this patch helps, but I think there is still a problem.
> > I think that trim needs to be done after CONFIG_BUILD_DOCSRC and possibly
> > after CONFIG_SAMPLES are built.
> 
> The later is already taken care of with commit dd92478a15.
> 
> > At least CONFIG_BUILD_DOCSRC seems to
> > cause this error:
> > 
> > Setup is 16508 bytes (padded to 16896 bytes).
> > System is 6125 kB
> > CRC 8aa70f94
> > Kernel: arch/x86/boot/bzImage is ready  (#9)
> > ERROR: "cn_del_callback" [Documentation/connector/cn_test.ko] undefined!
> > ERROR: "cn_add_callback" [Documentation/connector/cn_test.ko] undefined!
> > ERROR: "cn_netlink_send" [Documentation/connector/cn_test.ko] undefined!
> > ../scripts/Makefile.modpost:91: recipe for target '__modpost' failed
> > make[2]: *** [__modpost] Error 1
> 
> This one is indeed a problem.

Please try the following:

- >8
Subject: [PATCH] kbuild: better abstract vmlinux sequential prerequisites

When CONFIG_TRIM_UNUSED_KSYMS=y and CONFIG_BUILD_DOCSRC=y it is possible
to get the following error:

ERROR: "cn_del_callback" [Documentation/connector/cn_test.ko] undefined!
ERROR: "cn_add_callback" [Documentation/connector/cn_test.ko] undefined!
ERROR: "cn_netlink_send" [Documentation/connector/cn_test.ko] undefined!
../scripts/Makefile.modpost:91: recipe for target '__modpost' failed

It is not sufficient to do "vmlinux-dirs += Documentation" as this also
depends on the headers_check target, and all of this needs to be done
before adjust_autoksyms.sh is executed.

Let's sort this out by gathering those sequential prerequisites in a make
target of their own, separate from the vmlinux target. And by doing so,
the special autoksyms_recursive target is no longer needed.

Signed-off-by: Nicolas Pitre 

diff --git a/Makefile b/Makefile
index e9ad498238..3f1eb6a1bf 100644
--- a/Makefile
+++ b/Makefile
@@ -926,17 +926,11 @@ export KBUILD_ALLDIRS := $(sort $(filter-out 
arch/%,$(vmlinux-alldirs)) arch Doc
 
 vmlinux-deps := $(KBUILD_LDS) $(KBUILD_VMLINUX_INIT) $(KBUILD_VMLINUX_MAIN)
 
-# Final link of vmlinux
-  cmd_link-vmlinux = $(CONFIG_SHELL) $< $(LD) $(LDFLAGS) $(LDFLAGS_vmlinux)
-quiet_cmd_link-vmlinux = LINK$@
-
-# Include targets which we want to
-# execute if the rest of the kernel build went well.
-vmlinux: scripts/link-vmlinux.sh $(vmlinux-deps) FORCE
-ifdef CONFIG_TRIM_UNUSED_KSYMS
-   $(Q)$(CONFIG_SHELL) $(srctree)/scripts/adjust_autoksyms.sh \
- "$(MAKE) KBUILD_MODULES=1 -f $(srctree)/Makefile autoksyms_recursive"
-endif
+# Include targets which we want to execute sequentially if the rest of the
+# kernel build went well. If CONFIG_TRIM_UNUSED_KSYMS is set, this might be
+# evaluated more than once.
+PHONY += vmlinux_prereq
+vmlinux_prereq: $(vmlinux-deps) FORCE
 ifdef CONFIG_HEADERS_CHECK
$(Q)$(MAKE) -f $(srctree)/Makefile headers_check
 endif
@@ -946,17 +940,22 @@ endif
 ifdef CONFIG_GDB_SCRIPTS
$(Q)ln -fsn `cd $(srctree) && /bin/pwd`/scripts/gdb/vmlinux-gdb.py
 endif
-   +$(call if_changed,link-vmlinux)
-
-autoksyms_recursive: $(vmlinux-deps)
+ifdef CONFIG_TRIM_UNUSED_KSYMS
$(Q)$(CONFIG_SHELL) $(srctree)/scripts/adjust_autoksyms.sh \
- "$(MAKE) KBUILD_MODULES=1 -f $(srctree)/Makefile autoksyms_recursive"
-PHONY += autoksyms_recursive
+ "$(MAKE) KBUILD_MODULES=1 -f $(srctree)/Makefile vmlinux_prereq"
+endif
 
 # standalone target for easier testing
 include/generated/autoksyms.h: FORCE
$(Q)$(CONFIG_SHELL) $(srctree)/scripts/adjust_autoksyms.sh true
 
+# Final link of vmlinux
+  cmd_link-vmlinux = $(CONFIG_SHELL) $< $(LD) $(LDFLAGS) $(LDFLAGS_vmlinux)
+quiet_cmd_link-vmlinux = LINK$@
+
+vmlinux: scripts/link-vmlinux.sh vmlinux_prereq FORCE
+   +$(call if_changed,link-vmlinux)
+
 # Build samples along the rest of the kernel
 ifdef CONFIG_SAMPLES
 vmlinux-dirs += samples


Re: [PATCH 1/2] [v4] net: emac: emac gigabit ethernet controller driver

2016-04-22 Thread Timur Tabi

Timur Tabi wrote:




So I've done some more research, and I believe that the internal phy is
not a candidate for phylib, but the external phy (which is a real phy)
might be.  There's no MDIO bus to the internal phy.

Does this mean that I will need to enable a PHY driver, and that driver
will control the external phy?  If so, then does that mean that I would
delete all to code in my driver that calls emac_phy_read() and
emac_phy_write()?  For example, I wouldn't need emac_phy_link_check()
any more?


So I think I have it partially working, but I'm not sure if I'm doing 
things correctly, and I'd like some help.


The external phy is an Atheros 8031, so I load the at803x driver.  I 
added this code to my driver:


mii_bus = devm_mdiobus_alloc(>dev);
mii_bus->phy_mask = ~(1 << adpt->hw.phy_addr);
mii_bus->read = emac_mdio_read;
mii_bus->write = emac_mdio_write;
mii_bus->reset = emac_mdio_reset;
mii_bus->parent = >dev;
mii_bus->priv = hw;

mdiobus_register(mii_bus);

When I call mdiobus_register, I can see that the at803x_probe() probe 
function is called, so a connection is made.


The problem is that after that point, it appears that the at803x driver 
is never called again.  I tried bring the interface up and down, and 
connecting and disconnecting an Ethernet cable, but that didn't trigger 
anything.  I would expect the PHY driver to do more than just probe.


--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, a Linux Foundation collaborative project.


Re: [PATCH 2/2] printk, allow different timestamps for printk.time

2016-04-22 Thread Andrew Morton
On Fri, 22 Apr 2016 08:03:09 -0400 Prarit Bhargava  wrote:

> Over the past years I've seen many reports of bugs that include
> time-stamped kernel logs (enabled when CONFIG_PRINTK_TIME=y or
> print.time=1 is specified as a kernel parameter) that do not align
> with either external time stamped logs or /var/log/messages.  This
> also makes determining the time of a failure difficult in cases where
> /var/log/messages is unavailable.
> 
> For example,
> 
> [root@intel-wildcatpass-06 ~]# date; echo "Hello!" > /dev/kmsg ; date
> Thu Dec 17 13:58:31 EST 2015
> Thu Dec 17 13:58:31 EST 2015
> 
> which displays
> 
> [83973.768912] Hello!
> 
> on the serial console.
> 
> Running a script to convert this to the stamped time,
> 
> [root@intel-wildcatpass-06 ~]# ./human.sh  | tail -1
> [Thu Dec 17 13:59:57 2015] Hello!
> 
> which is already off by 1 minute and 26 seconds off after ~24 hours of
> uptime.
> 
> This occurs because the time stamp is obtained from a call to
> local_clock() which (on x86) is a direct call to the hardware.  These
> hardware clock reads are not modified by the standard ntp or ptp protocol,
> while the other timestamps are, and that results in situations external
> time sources are further and further offset from the kernel log
> timestamps.
> 
> This patch introduces printk.time=[0-3] allowing a user to specify an adjusted
> clock to use with printk timestamps.  The hardware clock, or the existing
> functionality, is preserved by default.
> 
> Real clock & 32-bit systems:  Selecting the real clock printk timestamp may
> lead to unlikely situations where a timestamp is wrong because the real time
> offset is read without the protection of a sequence lock in the call to
> ktime_get_log_ts() in printk_get_ts().

Looks OK to me.  Timekeeping stuff makes my head spin nowadays but I
trust you've sorted out the obvious deadlock/reentrancy/etc issues. 
I'll toss it in for some testing.

> @@ -1042,6 +1044,12 @@ static inline void boot_delay_msec(int level)
>  
>  static int printk_time = CONFIG_PRINTK_TIME;
>  
> +/*
> + * Real clock & 32-bit systems:  Selecting the real clock printk timestamp 
> may
> + * lead to unlikely situations where a timestamp is wrong because the real 
> time
> + * offset is read without the protection of a sequence lock in the call to
> + * ktime_get_log_ts() in printk_get_ts() below.
> + */
>  static int printk_time_param_set(const char *val,
>const struct kernel_param *kp)
>  {
> @@ -1063,6 +1071,14 @@ static int printk_time_param_set(const char *val,
>   case 'y':
>   printk_time = 1;
>   break;
> + /* 2 = monotonic clock */
> + case '2':
> + printk_time = 2;
> + break;
> + /* 3 = real clock */
> + case '3':
> + printk_time = 3;
> + break;

Maybe it's time to enumerate these values.

>   default:
>   pr_warn("printk: invalid timestamp value\n");
>   return -EINVAL;
> @@ -1080,6 +1096,21 @@ static struct kernel_param_ops printk_time_param_ops = 
> {
>  
>  module_param_cb(time, _time_param_ops, _time, S_IRUGO);
>  
> +static u64 printk_get_ts(void)
> +{
> + u64 mono, offset_real;
> +
> + if (printk_time <= 1)
> + return local_clock();
> +
> + mono = ktime_get_log_ts(_real);
> +
> + if (printk_time == 2)
> + return mono;
> +
> + return mono + offset_real;
> +}

Because the magic constants set a bad example for any children in the
audience.




[PATCH] Changed the path from to the incorrect drivers/char/sysrq.c to drivers/tty/sysrq.c

2016-04-22 Thread René Nyffenegger
This is my first patch submission. Please let me know if I have made a 
mistake anywhere.


Signed-off-by: René Nyffenegger 
---
 Documentation/sysrq.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/sysrq.txt b/Documentation/sysrq.txt
index 13f5619..3a3b30a 100644
--- a/Documentation/sysrq.txt
+++ b/Documentation/sysrq.txt
@@ -212,7 +212,7 @@ it is currently registered in that slot. This is in 
case the slot has been

 overwritten since you registered it.

 The Magic SysRQ system works by registering key operations against a 
key op
-lookup table, which is defined in 'drivers/char/sysrq.c'. This key 
table has

+lookup table, which is defined in 'drivers/tty/sysrq.c'. This key table has
 a number of operations registered into it at compile time, but is mutable,
 and 2 functions are exported for interface to it:
 register_sysrq_key and unregister_sysrq_key.
--
2.8.0


Re: [GIT PULL 1/2] bcm2835 DT changes for 4.7

2016-04-22 Thread Florian Fainelli
On 20/04/16 13:27, Eric Anholt wrote:
>   Linux 4.6-rc1 (2016-03-26 16:03:24 -0700)
> 
> are available in the git repository at:
> 
>   https://github.com/anholt/linux tags/bcm2835-dt-next-2016-04-20
> 
> for you to fetch changes up to 896ad420db8d5ec4cc4727b786d15e28eb59b366:
> 
>   dt/bindings: bcm2835: correct description for DMA-int (2016-04-19 17:31:58 
> -0700)
> 
> 
> This pull request brings in VC4 devicetree support and the other minor
> DT changes for 4.7.
> 
> Also included is a DRM patch necessary to prevent regressions when
> simplefb and vc4 drivers are both present.  The patch was suggested by
> the simplefb maintainer as the solution agreed upon at ELCE 2014, and
> was acked by the DRM maintainer for merging through this tree.
> 
> 

Merged into devicetree/next, thanks Eric!
-- 
Florian


Re: [GIT PULL 2/2] bcm2835 defconfig changes for 4.7

2016-04-22 Thread Florian Fainelli
On 20/04/16 13:27, Eric Anholt wrote:
>   Linux 4.6-rc1 (2016-03-26 16:03:24 -0700)
> 
> are available in the git repository at:
> 
>   https://github.com/anholt/linux tags/bcm2835-defconfig-next-2016-04-20
> 
> for you to fetch changes up to 3652bb35abf6ee11333cbec1d2855c1c0f9f6b27:
> 
>   ARM: bcm2835: Enable NFS root support. (2016-04-04 11:03:30 -0700)
> 
> 
> This pull request brings in changes for bcm2835_defconfig and
> multi_v7_defconfig in 4.7.

Also merged into defconfig/next, thanks Eric!
-- 
Florian


Re: [PATCH v11 04/60] sparc/PCI: Use correct offset for bus address to resource

2016-04-22 Thread Bjorn Helgaas
[+cc Ben, Michael]

On Thu, Apr 07, 2016 at 05:15:17PM -0700, Yinghai Lu wrote:
> After we added 64bit mmio parsing, we got some "no compatible bridge window"
> warning on anther new model that support 64bit resource.
> 
> It turns out that we can not use mem_space.start as 64bit mem space
> offset, aka there is mem_space.start != offset.
> 
> Use child_phys_addr to calculate exact offset and record offset in
> pbm.
> 
> After patch we get correct offset.
> 
> /pci@305: PCI IO [io  0x2007e-0x2007e0fff] offset 2007e
> /pci@305: PCI MEM [mem 0x20010-0x27eff] offset 2
> /pci@305: PCI MEM64 [mem 0x20001-0x2000d] offset 2
> ...
> pci_sun4v f02ae7f8: PCI host bridge to bus :00
> pci_bus :00: root bus resource [io  0x2007e-0x2007e0fff] (bus 
> address [0x-0xfff])
> pci_bus :00: root bus resource [mem 0x20010-0x27eff] (bus 
> address [0x0010-0x7eff])
> pci_bus :00: root bus resource [mem 0x20001-0x2000d] (bus 
> address [0x1-0xd])
> ...

> @@ -733,30 +733,32 @@ int pcibios_enable_device(struct pci_dev *dev, int mask)
>  static int __pci_mmap_make_offset_bus(struct pci_dev *pdev, struct 
> vm_area_struct *vma,
> enum pci_mmap_state mmap_state)
>  {
> - struct pci_pbm_info *pbm = pdev->dev.archdata.host_controller;
> - unsigned long space_size, user_offset, user_size;
> -
> - if (mmap_state == pci_mmap_io) {
> - space_size = resource_size(>io_space);
> - } else {
> - space_size = resource_size(>mem_space);
> - }
> + unsigned long user_offset, user_size;
> + struct resource res, *root_bus_res;
> + struct pci_bus_region region;
> + struct pci_bus *bus;
>  
>   /* Make sure the request is in range. */
>   user_offset = vma->vm_pgoff << PAGE_SHIFT;
>   user_size = vma->vm_end - vma->vm_start;
>  
> - if (user_offset >= space_size ||
> - (user_offset + user_size) > space_size)
> + region.start = user_offset;
> + region.end = user_offset + user_size - 1;
> + memset(, 0, sizeof(res));
> + if (mmap_state == pci_mmap_io)
> + res.flags = IORESOURCE_IO;
> + else
> + res.flags = IORESOURCE_MEM;
> +
> + pcibios_bus_to_resource(pdev->bus, , );
> + bus = pdev->bus;
> + while (bus->parent)
> + bus = bus->parent;
> + root_bus_res = pci_find_bus_resource(bus, );
> + if (!root_bus_res)
>   return -EINVAL;
>  
> - if (mmap_state == pci_mmap_io) {
> - vma->vm_pgoff = (pbm->io_space.start +
> -  user_offset) >> PAGE_SHIFT;
> - } else {
> - vma->vm_pgoff = (pbm->mem_space.start +
> -  user_offset) >> PAGE_SHIFT;
> - }
> + vma->vm_pgoff = res.start >> PAGE_SHIFT;
>  
>   return 0;
>  }

I'm kind of confused here.  There are two ways to mmap PCI BARs:

  /proc/bus/pci/00/02.0 (proc_bus_pci_mmap()):
all BARs in one file; MEM/IO determined by ioctl()
mmap offset is a CPU physical address in the PCI resource

  /sys/devices/pci:00/:00:02.0/resource0 (pci_mmap_resource()):
one file per BAR; MEM/IO determined by BAR type
mmap offset is between 0 and BAR size

Both proc_bus_pci_mmap() and pci_mmap_resource() validate the
requested area with pci_mmap_fits() before calling pci_mmap_page_range().

In the proc_bus_pci_mmap() path, the offset in vma->vm_pgoff must be
within the pdev->resource[], so the user must be supplying a CPU
physical address (not an address obtained from pci_resource_to_user()).
That vma->vm_pgoff is passed unchanged to pci_mmap_page_range().

In the pci_mmap_resource() path, vma->vm_pgoff must be between 0 and
the BAR size.  Then we add in the pci_resource_to_user() information
before passing it to pci_mmap_page_range().  The comment in
pci_mmap_resource() says pci_mmap_page_range() expects a "user
visible" address, but I don't really believe that based on how
proc_bus_pci_mmap() works.

Do both proc_bus_pci_mmap() and pci_mmap_resource() work on sparc?
It looks like they call pci_mmap_page_range() with different
assumptions, so I don't see how they can both work.

In any case, pci_mmap_page_range() on sparc converts that
vma->vm_pgoff back to a CPU physical address, so there's an awful lot
of work going on in the pci_mmap_resource() path to convert the mmap
offset to a "user" address and then convert it back again.

There's also quite a bit of validation done in the arch code (in
__pci_mmap_make_offset() and __pci_mmap_make_offset_bus()) that looks
partly redundant with pci_mmap_fits() and not necessarily
arch-specific.

As far as I can see, pci_mmap_resource() doesn't need to have any
connection at all with pci_resource_to_user().  All it needs is the
pdev->resource[] (which has the CPU physical address of the BAR) and
vma->vm_pgoff 

Re: [PATCH v2 1/2] mm, kasan: don't call kasan_krealloc() from ksize().

2016-04-22 Thread Andrew Morton
On Wed, 13 Apr 2016 13:20:09 +0200 Alexander Potapenko  
wrote:

> Instead of calling kasan_krealloc(), which replaces the memory allocation
> stack ID (if stack depot is used), just unpoison the whole memory chunk.

I don't understand why these two patches exist.  Bugfix?  Cleanup? 
Optimization?


I had to change kmalloc_tests_init() a bit due to
mm-kasan-initial-memory-quarantine-implementation.patch:

kasan_stack_oob();
kasan_global_oob();
 #ifdef CONFIG_SLAB
kasan_quarantine_cache();
 #endif
+   ksize_unpoisons_memory();
return -EAGAIN;
 }

Please check.


Re: [PATCH/RFC v2] perf core: Allow setting up max frame stack depth via sysctl

2016-04-22 Thread Alexei Starovoitov
On Fri, Apr 22, 2016 at 04:05:31PM -0600, David Ahern wrote:
> On 4/22/16 2:52 PM, Arnaldo Carvalho de Melo wrote:
> >Em Wed, Apr 20, 2016 at 04:04:12PM -0700, Alexei Starovoitov escreveu:
> >>On Wed, Apr 20, 2016 at 07:47:30PM -0300, Arnaldo Carvalho de Melo wrote:
> >
> >>Nice. I like it. That's a great approach to hard problem.
> >>Java guys will be happy too.
> >>Please also adjust two places in kernel/bpf/stackmap.c
> >
> >>>+  {
> >>>+  .procname   = "perf_event_max_stack",
> >>>+  .data   = NULL, /* filled in by handler */
> >>>+  .maxlen = sizeof(sysctl_perf_event_max_stack),
> >>>+  .mode   = 0644,
> >>>+  .proc_handler   = perf_event_max_stack_handler,
> >>>+  .extra1 = ,
> >
> >>zero seems to be the wrong minimum. I think it should be at least 2 to
> >>to fit user/kernel tags ?  Probably needs to define max as well.
> >
> >So, if someone asks for zero, it will not copy anything, but then, this
> >would be what the user had asked for :-)
> >
> >Ditto for the max, if someone asks for too big a callchain, then when
> >allocating it it will fail and no callchain will be produced, that or it
> >will be able to allocate but will take too long copying that many
> >addresses, and we would be prevented from doing so by some other
> >protection, iirc there is perf_cpu_time_max_percent, and then buffer
> >space will run out.
> >
> >So I think that leaving it as is is enough, no?
> >
> >Can I keep your Acked-by? David, can I keep yours?
> 
> Yes
> 
> 
> >diff --git a/kernel/events/callchain.c b/kernel/events/callchain.c
> >index 343c22f5e867..6fe77349fa9d 100644
> >--- a/kernel/events/callchain.c
> >+++ b/kernel/events/callchain.c
> >@@ -18,6 +18,14 @@ struct callchain_cpus_entries {
> > struct perf_callchain_entry *cpu_entries[0];
> >  };
> >
> >+int sysctl_perf_event_max_stack __read_mostly = PERF_MAX_STACK_DEPTH;
> >+
> >+static size_t perf_callchain_entry__sizeof(void)
> >+{
> >+return sizeof(struct perf_callchain_entry) +
> >+   sizeof(__u64) * sysctl_perf_event_max_stack;
> >+}
> >+
> 
> To Alexei's comment, a max_stack of 0 still has a non-zero alloc size so
> that should be ok.
> 
> 
> >  static DEFINE_PER_CPU(int, callchain_recursion[PERF_NR_CONTEXTS]);
> >  static atomic_t nr_callchain_events;
> >  static DEFINE_MUTEX(callchain_mutex);
> >@@ -73,7 +81,7 @@ static int alloc_callchain_buffers(void)
> > if (!entries)
> > return -ENOMEM;
> >
> >-size = sizeof(struct perf_callchain_entry) * PERF_NR_CONTEXTS;
> >+size = perf_callchain_entry__sizeof() * PERF_NR_CONTEXTS;
> >
> > for_each_possible_cpu(cpu) {
> > entries->cpu_entries[cpu] = kmalloc_node(size, GFP_KERNEL,

right... and looking into it further, realized that the patch is broken,
since get_callchain_entry() is doing:
  return >cpu_entries[cpu][*rctx];
whereas it should be dynamic offset based on sysctl_perf_event_max_stack*8
So definitely needs another respin.



[PATCH 5/8] firmware: qcom: scm: Use atomic SCM for cold boot

2016-04-22 Thread Andy Gross
This patch changes the cold_set_boot_addr function to use atomic SCM
calls.  This removes the need for memory allocation and instead places
all arguments in registers.

Signed-off-by: Andy Gross 
---
 drivers/firmware/qcom_scm-32.c | 40 ++--
 1 file changed, 26 insertions(+), 14 deletions(-)

diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
index 0d2a3f8..f596091 100644
--- a/drivers/firmware/qcom_scm-32.c
+++ b/drivers/firmware/qcom_scm-32.c
@@ -294,34 +294,39 @@ out:
(n & 0xf))
 
 /**
- * qcom_scm_call_atomic1() - Send an atomic SCM command with one argument
+ * qcom_scm_call_atomic() - Send an atomic SCM command with one argument
  * @svc_id: service identifier
  * @cmd_id: command identifier
+ * @arglen: number of arguments
  * @arg1: first argument
+ * @arg2: second argument (optional - fill with 0 if unused)
  *
  * This shall only be used with commands that are guaranteed to be
  * uninterruptable, atomic and SMP safe.
  */
-static s32 qcom_scm_call_atomic1(u32 svc, u32 cmd, u32 arg1)
+static s32 qcom_scm_call_atomic(u32 svc, u32 cmd, u32 arglen, u32 arg1,
+   u32 arg2)
 {
int context_id;
 
-   register u32 r0 asm("r0") = SCM_ATOMIC(svc, cmd, 1);
+   register u32 r0 asm("r0") = SCM_ATOMIC(svc, cmd, arglen);
register u32 r1 asm("r1") = (u32)_id;
register u32 r2 asm("r2") = arg1;
+   register u32 r3 asm("r3") = arg2;
 
asm volatile(
__asmeq("%0", "r0")
__asmeq("%1", "r0")
__asmeq("%2", "r1")
__asmeq("%3", "r2")
+   __asmeq("%4", "r3")
 #ifdef REQUIRES_SEC
".arch_extension sec\n"
 #endif
"smc#0  @ switch to secure world\n"
: "=r" (r0)
-   : "r" (r0), "r" (r1), "r" (r2)
-   : "r3");
+   : "r" (r0), "r" (r1), "r" (r2), "r" (r3)
+   );
return r0;
 }
 
@@ -364,17 +369,24 @@ EXPORT_SYMBOL(qcom_scm_get_version);
 /*
  * Set the cold/warm boot address for one of the CPU cores.
  */
-static int qcom_scm_set_boot_addr(u32 addr, int flags)
+static int qcom_scm_set_boot_addr(u32 addr, int flags, bool do_atomic)
 {
struct {
__le32 flags;
__le32 addr;
} cmd;
 
-   cmd.addr = cpu_to_le32(addr);
-   cmd.flags = cpu_to_le32(flags);
-   return qcom_scm_call(QCOM_SCM_SVC_BOOT, QCOM_SCM_BOOT_ADDR,
-   , sizeof(cmd), NULL, 0);
+   if (do_atomic) {
+   return qcom_scm_call_atomic(QCOM_SCM_SVC_BOOT,
+   QCOM_SCM_BOOT_ADDR, 2, flags, addr);
+   } else {
+
+   cmd.addr = cpu_to_le32(addr);
+   cmd.flags = cpu_to_le32(flags);
+
+   return qcom_scm_call(QCOM_SCM_SVC_BOOT, QCOM_SCM_BOOT_ADDR,
+, sizeof(cmd), NULL, 0);
+   }
 }
 
 /**
@@ -406,7 +418,7 @@ int __qcom_scm_set_cold_boot_addr(void *entry, const 
cpumask_t *cpus)
set_cpu_present(cpu, false);
}
 
-   return qcom_scm_set_boot_addr(virt_to_phys(entry), flags);
+   return qcom_scm_set_boot_addr(virt_to_phys(entry), flags, true);
 }
 
 /**
@@ -437,7 +449,7 @@ int __qcom_scm_set_warm_boot_addr(void *entry, const 
cpumask_t *cpus)
if (!flags)
return 0;
 
-   ret = qcom_scm_set_boot_addr(virt_to_phys(entry), flags);
+   ret = qcom_scm_set_boot_addr(virt_to_phys(entry), flags, false);
if (!ret) {
for_each_cpu(cpu, cpus)
qcom_scm_wb[cpu].entry = entry;
@@ -456,8 +468,8 @@ int __qcom_scm_set_warm_boot_addr(void *entry, const 
cpumask_t *cpus)
  */
 void __qcom_scm_cpu_power_down(u32 flags)
 {
-   qcom_scm_call_atomic1(QCOM_SCM_SVC_BOOT, QCOM_SCM_CMD_TERMINATE_PC,
-   flags & QCOM_SCM_FLUSH_FLAG_MASK);
+   qcom_scm_call_atomic(QCOM_SCM_SVC_BOOT, QCOM_SCM_CMD_TERMINATE_PC, 1,
+   flags & QCOM_SCM_FLUSH_FLAG_MASK, 0);
 }
 
 int __qcom_scm_is_call_available(u32 svc_id, u32 cmd_id)
-- 
1.9.1



Re: [PATCH 4/5] x86, boot: Make memcpy handle overlaps

2016-04-22 Thread Kees Cook
On Fri, Apr 22, 2016 at 12:49 AM, Ingo Molnar  wrote:
>
> * Kees Cook  wrote:
>
>> Two uses of memcpy (screen scrolling and ELF parsing) were handling
>> overlapping memory areas. While there were no explicitly noticed bugs
>> here (yet), it is best to fix this so that the copying will always be
>> safe.
>>
>> Instead of making a new memmove function that might collide with other
>> memmove definitions in the decompressors, this just makes the compressed
>> boot's copy of memcpy overlap safe.
>>
>> Reported-by: Yinghai Lu 
>> Suggested-by: Lasse Collin 
>> Signed-off-by: Kees Cook 
>> ---
>>  arch/x86/boot/compressed/misc.c   |  4 +---
>>  arch/x86/boot/compressed/string.c | 22 --
>>  2 files changed, 21 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/x86/boot/compressed/string.c 
>> b/arch/x86/boot/compressed/string.c
>> index 00e788be1db9..1e10e40f49dd 100644
>> --- a/arch/x86/boot/compressed/string.c
>> +++ b/arch/x86/boot/compressed/string.c
>> @@ -1,7 +1,7 @@
>>  #include "../string.c"
>>
>>  #ifdef CONFIG_X86_32
>
> I've applied this patch, but could you please also do another patch that adds 
> a
> comment block to the top of this special version of compressed/string.c, which
> explains why this file exists and what its purpose is?

So... this isn't exactly clearly to me. I assume that something about
the builtin memcpy doesn't work during compressed boot, so
compressed/string.c needed to explicitly overload them. If that
matches your understanding, I can add a comment to that effect.

> Also:
>
> +/*
> + * This memcpy is overlap safe (i.e. it is memmove without conflicting
> + * with other definitions of memmove from the various decompressors.
> + */
> +void *memcpy(void *dest, const void *src, size_t n)
>
> I'd not name it memcpy() if its semantics are not the same as the regular 
> kernel
> memcpy() - that will only cause confusion later on.
>
> I'd try to name it memmove() and would fix the memmove() hacks in 
> decompressors:
>
>  lib/decompress_unxz.c:#ifndef memmove
>  lib/decompress_unxz.c:void *memmove(void *dest, const void *src, size_t size)
>  lib/decompress_unxz.c: * Since we need memmove anyway, would use it as 
> memcpy too.
>  lib/decompress_unxz.c:# define memcpy memmove
>
> any strong reason this cannot be done?

Lasse asked for this too, but I'm going to avoid poking at the
decompressor code and just use the interface it already defines: the
"memmove" define.

> Some other decompressors seem to avoid memmove() intentionally:
>
>  lib/decompress_bunzip2.c:*by 256 in any case, using memmove 
> here would
>  lib/decompress_unlzo.c:  * of the buffer. This way memmove() isn't 
> needed which
>  lib/decompress_unlzo.c:  * Use a loop to avoid memmove() 
> dependency.

Yeah, seems like it's not hard to add memmove! :)

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security


<    4   5   6   7   8   9   10   11   12   13   >