Re: vmalloced stacks on x86_64?
On Oct 25, 2014 9:11 PM, "Frederic Weisbecker" wrote: > > 2014-10-25 2:22 GMT+02:00 Andy Lutomirski : > > Is there any good reason not to use vmalloc for x86_64 stacks? > > > > The tricky bits I've thought of are: > > > > - On any context switch, we probably need to probe the new stack > > before switching to it. That way, if it's going to fault due to an > > out-of-sync pgd, we still have a stack available to handle the fault. > > Would that prevent from any further fault on a vmalloc'ed kernel > stack? We would need to ensure that pre-faulting, say the first byte, > is enough to sync the whole new stack entirely otherwise we risk > another future fault and some places really aren't safely faulted. > I think so. The vmalloc faults only happen when the entire top-level page table entry is missing, and those cover giant swaths of address space. I don't know whether the vmalloc code guarantees not to span a pmd (pud? why couldn't these be called pte0, pte1, pte2, etc.?) boundary. --Andy > > > > - Any time we change cr3, we may need to check that the pgd > > corresponding to rsp is there. If now, we need to sync it over. > > > > - For simplicity, we probably want all stack ptes to be present all > > the time. This is fine; vmalloc already works that way. > > > > - If we overrun the stack, we double-fault. This should be easy to > > detect: any double-fault where rsp is less than 20 bytes from the > > bottom of the stack is a failure to deliver a non-IST exception due to > > a stack overflow. The question is: what do we do if this happens? > > We could just panic (guaranteed to work). We could also try to > > recover by killing the offending task, but that might be a bit > > challenging, since we're in IST context. We could do something truly > > awful: increment RSP by a few hundred bytes, point RIP at do_exit, and > > return from the double fault. > > > > Thoughts? This shouldn't be all that much code. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] zram: avoid NULL pointer access when reading mem_used_total
On (10/25/14 17:26), Weijie Yang wrote:
> Date: Sat, 25 Oct 2014 17:26:31 +0800
> From: Weijie Yang
> To: 'Minchan Kim'
> Cc: 'Andrew Morton' , 'Dan Streetman'
> , 'Sergey Senozhatsky' ,
> 'Nitin Gupta' , 'Linux-MM' ,
> 'linux-kernel' , 'Weijie Yang'
>
> Subject: [PATCH 2/2] zram: avoid NULL pointer access when reading
> mem_used_total
> X-Mailer: Microsoft Office Outlook 12.0
>
> There is a rare NULL pointer bug in mem_used_total_show() in concurrent
> situation, like this:
> zram is not initialized, process A is a mem_used_total reader which runs
> periodicity, while process B try to init zram.
>
> process A process B
> access meta, get a NULL value
> init zram, done
> init_done() is true
> access meta->mem_pool, get a NULL pointer BUG
>
> This patch fixes this issue.
>
> Signed-off-by: Weijie Yang
Acked-by: Sergey Senozhatsky
-ss
> ---
> drivers/block/zram/zram_drv.c |5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 64dd79a..2ffd7d8 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -99,11 +99,12 @@ static ssize_t mem_used_total_show(struct device *dev,
> {
> u64 val = 0;
> struct zram *zram = dev_to_zram(dev);
> - struct zram_meta *meta = zram->meta;
>
> down_read(>init_lock);
> - if (init_done(zram))
> + if (init_done(zram)) {
> + struct zram_meta *meta = zram->meta;
> val = zs_get_total_pages(meta->mem_pool);
> + }
> up_read(>init_lock);
>
> return scnprintf(buf, PAGE_SIZE, "%llu\n", val << PAGE_SHIFT);
> --
> 1.7.0.4
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: UKSM: What's maintainers think about it?
On Sat, 25 Oct 2014 22:25:56 +0300 Timofey Titovets wrote: > Good time of day, people. > I try to find 'mm' subsystem specific people and lists, but list > linux-mm looks dead and mail archive look like deprecated. > If i must to sent this message to another list or add CC people, let me know. linux...@kvack.org is alive and well. > If questions are already asked (i can't find activity before), feel > free to kick me. > > The main questions: > 1. Somebody test it? I see many reviews about it. > I already port it to latest linux-next-git kernel and its work without issues. > http://pastebin.com/6FMuKagS > (if it matter, i can describe use cases and results, if somebody ask it) > > 2. Developers of UKSM already tried to merge it? Somebody talked with uksm > devs? > offtop: now i try to communicate with dev's on kerneldedup.org forum, > but i have problems with email verification and wait admin > registration approval. > (i already sent questions to > http://kerneldedup.org/forum/home.php?mod=space=xianai , > because him looks like team leader) > > 3. I just want collect feedbacks from linux maintainers team, if you > decide what UKSM not needed in kernel, all other comments (as i > understand) not matter. > > Like KSM, but better. > UKSM - Ultra Kernel Samepage Merging > http://kerneldedup.org/en/projects/uksm/introduction/ It's the first I've heard of it. No, as far as I know there has been no attempt to upstream UKSM. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vmalloced stacks on x86_64?
2014-10-25 2:22 GMT+02:00 Andy Lutomirski : > Is there any good reason not to use vmalloc for x86_64 stacks? > > The tricky bits I've thought of are: > > - On any context switch, we probably need to probe the new stack > before switching to it. That way, if it's going to fault due to an > out-of-sync pgd, we still have a stack available to handle the fault. Would that prevent from any further fault on a vmalloc'ed kernel stack? We would need to ensure that pre-faulting, say the first byte, is enough to sync the whole new stack entirely otherwise we risk another future fault and some places really aren't safely faulted. > > - Any time we change cr3, we may need to check that the pgd > corresponding to rsp is there. If now, we need to sync it over. > > - For simplicity, we probably want all stack ptes to be present all > the time. This is fine; vmalloc already works that way. > > - If we overrun the stack, we double-fault. This should be easy to > detect: any double-fault where rsp is less than 20 bytes from the > bottom of the stack is a failure to deliver a non-IST exception due to > a stack overflow. The question is: what do we do if this happens? > We could just panic (guaranteed to work). We could also try to > recover by killing the offending task, but that might be a bit > challenging, since we're in IST context. We could do something truly > awful: increment RSP by a few hundred bytes, point RIP at do_exit, and > return from the double fault. > > Thoughts? This shouldn't be all that much code. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fs: lockup on rename_mutex in fs/dcache.c:1035
[context for Linus] Fuzzer has triggered deadlock in d_walk() with rename_lock taken twice. AFAICS, the plausible scenario is (child->d_flags & DCACHE_DENTRY_KILLED) || triggering while ascending to parent, on the pass with rename_lock already held exclusive. In that case we go to rename_retry and either return without unlocking rename_lock, or try to take in exclusive one more time, again without unlocking it first. > Hmm... Actually, the comment in there is simply wrong - if the child > got killed between unlocking the child and locking the parent, it's > not ascending to the wrong parent, it's having no way to find the next > sibling. > > OK, so basically it came from Nick's "fs: dcache avoid starvation in dcache > multi-step operations" and mistake was in the assumption that once we > hold rename_lock, nothing is going to need rename_retry. Which isn't > true - dentry_kill() on child while we are trying to get ->d_lock on > parent requires a restart and that isn't excluded by rename_lock at > all. > > Well, brute-force fix would be this, but I wonder if it's going to > create livelocks... > > diff --git a/fs/dcache.c b/fs/dcache.c > index 3ffef7f..e3d8499 100644 > --- a/fs/dcache.c > +++ b/fs/dcache.c > @@ -1118,6 +1118,7 @@ out_unlock: > return; > > rename_retry: > + done_seqretry(_lock, seq); > if (!retry) > return; > seq = 1; > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fs: lockup on rename_mutex in fs/dcache.c:1035
On Sun, Oct 26, 2014 at 03:06:08AM +, Al Viro wrote: > > >From a quick reading of the code it simply isn't possible for d_walk to > > take the lock twice short of memory corruption. And the fact that the > > code has not changed in years seems to suggest it isn't the obvious > > cause of d_walk talking the rename_lock twice. > > It is a fairly obvious case of d_walk() forgetting to drop rename_lock. > See upthread for analysis and (hopefully) a fix. ... except that it's not a full fix. If we get there that way with retry being true, we will immediately deadlock at again:... Which might very well has happened in this case - i.e. it might be a single call of d_walk() taking the sucker twice that way. Hmm... Actually, the comment in there is simply wrong - if the child got killed between unlocking the child and locking the parent, it's not ascending to the wrong parent, it's having no way to find the next sibling. OK, so basically it came from Nick's "fs: dcache avoid starvation in dcache multi-step operations" and mistake was in the assumption that once we hold rename_lock, nothing is going to need rename_retry. Which isn't true - dentry_kill() on child while we are trying to get ->d_lock on parent requires a restart and that isn't excluded by rename_lock at all. Well, brute-force fix would be this, but I wonder if it's going to create livelocks... diff --git a/fs/dcache.c b/fs/dcache.c index 3ffef7f..e3d8499 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -1118,6 +1118,7 @@ out_unlock: return; rename_retry: + done_seqretry(_lock, seq); if (!retry) return; seq = 1; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fs: lockup on rename_mutex in fs/dcache.c:1035
On Sat, Oct 25, 2014 at 08:01:41PM -0700, Eric W. Biederman wrote: > Sasha Levin writes: > > > Hi all, > > > > While fuzzing with trinity inside a KVM tools guest running the latest -next > > kernel, I've stumbled on the following spew: > > Weird. I took a quick look and I don't see any changes in d_walk that > in Al's tree or in Linus's kernel for years. > > Has read_seqbegin_or_lock changed somewhere? > > >From a quick reading of the code it simply isn't possible for d_walk to > take the lock twice short of memory corruption. And the fact that the > code has not changed in years seems to suggest it isn't the obvious > cause of d_walk talking the rename_lock twice. It is a fairly obvious case of d_walk() forgetting to drop rename_lock. See upthread for analysis and (hopefully) a fix. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] vfs.git
overlayfs merge + leak fix for d_splice_alias() failure exits. Please, pull from the usual place: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus Shortlog: Al Viro (5): fix inode leaks on d_splice_alias() failure exits overlayfs: don't hold ->i_mutex over opening the real directory overlayfs: make ovl_cache_entry->name an array instead of pointer overlayfs: embed root into overlay_readdir_data overlayfs: embed middle into overlay_readdir_data Andy Whitcroft (1): overlayfs: add statfs support Erez Zadok (1): overlayfs: implement show_options Miklos Szeredi (11): vfs: add i_op->dentry_open() vfs: export do_splice_direct() to modules vfs: export __inode_permission() to modules vfs: introduce clone_private_mount() vfs: export check_sticky() vfs: add whiteout support vfs: add RENAME_WHITEOUT ext4: support RENAME_WHITEOUT shmem: support RENAME_WHITEOUT overlay filesystem fs: limit filesystem stacking depth Neil Brown (1): overlay: overlay filesystem documentation Diffstat: Documentation/filesystems/Locking |2 + Documentation/filesystems/overlayfs.txt | 198 +++ Documentation/filesystems/vfs.txt |7 + MAINTAINERS |7 + fs/Kconfig |1 + fs/Makefile |1 + fs/btrfs/ioctl.c| 20 +- fs/dcache.c |2 + fs/ecryptfs/main.c |7 + fs/ext4/namei.c | 95 +++- fs/internal.h |7 - fs/namei.c | 41 +- fs/namespace.c | 27 + fs/open.c | 23 +- fs/overlayfs/Kconfig| 10 + fs/overlayfs/Makefile |7 + fs/overlayfs/copy_up.c | 414 ++ fs/overlayfs/dir.c | 921 +++ fs/overlayfs/inode.c| 425 ++ fs/overlayfs/overlayfs.h| 191 +++ fs/overlayfs/readdir.c | 590 fs/overlayfs/super.c| 796 ++ fs/splice.c |1 + include/linux/fs.h | 39 ++ include/linux/mount.h |3 + include/uapi/linux/fs.h |1 + mm/shmem.c | 36 +- 27 files changed, 3814 insertions(+), 58 deletions(-) create mode 100644 Documentation/filesystems/overlayfs.txt create mode 100644 fs/overlayfs/Kconfig create mode 100644 fs/overlayfs/Makefile create mode 100644 fs/overlayfs/copy_up.c create mode 100644 fs/overlayfs/dir.c create mode 100644 fs/overlayfs/inode.c create mode 100644 fs/overlayfs/overlayfs.h create mode 100644 fs/overlayfs/readdir.c create mode 100644 fs/overlayfs/super.c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fs: lockup on rename_mutex in fs/dcache.c:1035
Sasha Levin writes:
> Hi all,
>
> While fuzzing with trinity inside a KVM tools guest running the latest -next
> kernel, I've stumbled on the following spew:
Weird. I took a quick look and I don't see any changes in d_walk that
in Al's tree or in Linus's kernel for years.
Has read_seqbegin_or_lock changed somewhere?
>From a quick reading of the code it simply isn't possible for d_walk to
take the lock twice short of memory corruption. And the fact that the
code has not changed in years seems to suggest it isn't the obvious
cause of d_walk talking the rename_lock twice.
Eric
> [ 6172.870045] =
> [ 6172.870045] [ INFO: possible recursive locking detected ]
> [ 6172.870045] 3.18.0-rc1-next-20141023-sasha-00036-g4dcabd5 #1415 Not tainted
> [ 6172.870045] -
> [ 6172.870045] trinity-c55/12752 is trying to acquire lock:
> [ 6172.870045] (rename_lock){+.+...}, at: d_walk
> (include/linux/spinlock.h:309 fs/dcache.c:1035)
> [ 6172.870045]
> [ 6172.870045] but task is already holding lock:
> [ 6172.870045] (rename_lock){+.+...}, at: d_walk
> (include/linux/spinlock.h:309 fs/dcache.c:1035)
> [ 6172.870045]
> [ 6172.870045] other info that might help us debug this:
> [ 6172.900904] FAULT_INJECTION: forcing a failure
> [ 6172.870045] Possible unsafe locking scenario:
> [ 6172.870045]
> [ 6172.870045]CPU0
> [ 6172.870045]
> [ 6172.870045] lock(rename_lock);
> [ 6172.870045] lock(rename_lock);
> [ 6172.870045]
> [ 6172.870045] *** DEADLOCK ***
> [ 6172.870045]
> [ 6172.870045] May be due to missing lock nesting notation
> [ 6172.870045]
> [ 6172.870045] 1 lock held by trinity-c55/12752:
> [ 6172.870045] #0: (rename_lock){+.+...}, at: d_walk
> (include/linux/spinlock.h:309 fs/dcache.c:1035)
> [ 6172.870045]
> [ 6172.870045] stack backtrace:
> [ 6172.870045] CPU: 1 PID: 12752 Comm: trinity-c55 Not tainted
> 3.18.0-rc1-next-20141023-sasha-00036-g4dcabd5 #1415
> [ 6172.870045] 88070945b000 b6312fd0
> 8806d69ff728
> [ 6172.870045] a8ff75ca 0011 b6312fd0
> 8806d69ff828
> [ 6172.870045] 9f3a012b 880107fd76c0 880107fd76c0
> 0001
> [ 6172.870045] Call Trace:
> [ 6172.870045] dump_stack (lib/dump_stack.c:52)
> [ 6172.870045] validate_chain.isra.10 (kernel/locking/lockdep.c:2134)
> [ 6172.870045] ? kvm_clock_read (./arch/x86/include/asm/preempt.h:90
> arch/x86/kernel/kvmclock.c:86)
> [ 6172.870045] ? sched_clock_cpu (kernel/sched/clock.c:311)
> [ 6172.870045] __lock_acquire (kernel/locking/lockdep.c:3184)
> [ 6172.870045] lock_acquire (./arch/x86/include/asm/current.h:14
> kernel/locking/lockdep.c:3604)
> [ 6172.870045] ? d_walk (include/linux/spinlock.h:309 fs/dcache.c:1035)
> [ 6172.870045] ? put_lock_stats.isra.7 (./arch/x86/include/asm/preempt.h:98
> kernel/locking/lockdep.c:254)
> [ 6172.870045] _raw_spin_lock (include/linux/spinlock_api_smp.h:143
> kernel/locking/spinlock.c:151)
> [ 6172.870045] ? d_walk (include/linux/spinlock.h:309 fs/dcache.c:1035)
> [ 6172.870045] d_walk (include/linux/spinlock.h:309 fs/dcache.c:1035)
> [ 6172.870045] ? d_walk (fs/dcache.c:1087)
> [ 6172.870045] ? d_drop (fs/dcache.c:1336)
> [ 6172.870045] ? select_collect (fs/dcache.c:1323)
> [ 6172.870045] d_invalidate (fs/dcache.c:1381)
> [ 6172.870045] lookup_fast (fs/namei.c:1440)
> [ 6172.870045] ? _raw_spin_unlock (./arch/x86/include/asm/preempt.h:98
> include/linux/spinlock_api_smp.h:152 kernel/locking/spinlock.c:183)
> [ 6172.870045] ? lockref_put_or_lock (lib/lockref.c:135)
> [ 6172.870045] ? dput (fs/dcache.c:626)
> [ 6172.870045] walk_component (fs/namei.c:1545)
> [ 6172.870045] ? security_inode_permission (security/security.c:573)
> [ 6172.870045] ? __inode_permission (fs/namei.c:418)
> [ 6172.870045] link_path_walk (fs/namei.c:1805)
> [ 6172.870045] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
> [ 6172.870045] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2559
> kernel/locking/lockdep.c:2601)
> [ 6172.870045] ? getname_flags (fs/namei.c:145)
> [ 6172.870045] path_lookupat (fs/namei.c:1956)
> [ 6172.870045] ? kmem_cache_alloc (include/linux/rcupdate.h:479
> include/trace/events/kmem.h:53 mm/slub.c:2463)
> [ 6172.870045] ? getname_flags (fs/namei.c:145)
> [ 6172.870045] filename_lookup (fs/namei.c:2000)
> [ 6172.870045] user_path_at_empty (fs/namei.c:2151)
> [ 6172.870045] ? preempt_count_sub (kernel/sched/core.c:2662)
> [ 6172.870045] user_path_at (fs/namei.c:2162)
> [ 6172.870045] vfs_fstatat (fs/stat.c:106)
> [ 6172.870045] SYSC_newlstat (fs/stat.c:284)
> [ 6172.870045] ? syscall_trace_enter_phase2 (arch/x86/kernel/ptrace.c:1598)
> [ 6172.870045] ? tracesys_phase2 (arch/x86/kernel/entry_64.S:518)
> [ 6172.870045] SyS_newlstat (fs/stat.c:277)
> [ 6172.870045] tracesys_phase2 (arch/x86/kernel/entry_64.S:529)
>
> The machine proceeded to actually lock up, so this isn't a false positive.
>
>
>
Re: fs: lockup on rename_mutex in fs/dcache.c:1035
On Sat, Oct 25, 2014 at 09:39:23PM -0400, Sasha Levin wrote:
> [ 6172.870045] trinity-c55/12752 is trying to acquire lock:
> [ 6172.870045] (rename_lock){+.+...}, at: d_walk
> (include/linux/spinlock.h:309 fs/dcache.c:1035)
> [ 6172.870045]
> [ 6172.870045] but task is already holding lock:
> [ 6172.870045] (rename_lock){+.+...}, at: d_walk
> (include/linux/spinlock.h:309 fs/dcache.c:1035)
Umm... So we either have left d_walk() without dropping rename_lock, or
we have called d_walk() from something called from d_walk()? And the
trace would seem to point towards the former...
Ouch. For that to happen, we would need to
* get to rename_retry with retry being true
* after that get D_WALK_NORETRY from enter()
* somehow get to rename_retry *again*
Moreover, we couldn't get there via
if (need_seqretry(_lock, seq)) {
spin_unlock(_parent->d_lock);
goto rename_retry;
- seq is 1 by that point, and need_seqretry() returns 0 in that case. IOW,
it must have been this:
/*
* might go back up the wrong parent if we have had a rename
* or deletion
*/
if (this_parent != child->d_parent ||
(child->d_flags & DCACHE_DENTRY_KILLED) ||
need_seqretry(_lock, seq)) {
spin_unlock(_parent->d_lock);
rcu_read_unlock();
goto rename_retry;
}
And we had been holding rename_lock in that walk, so d_move() should've
been excluded... Which leaves us with
(child->d_flags & DCACHE_DENTRY_KILLED)
being true... Hrm. AFAICS, it *is* possible to hit that one - just have
the last reference to child dropped between
spin_unlock(>d_lock);
and
spin_lock(_parent->d_lock);
a few lines above. And yes, if that happens we are in shit - rename_retry
will see retry being false and return, without noticing that on this pass
we had been holding rename_lock. Easily fixed, fortunately - delta below
ought to take care of that...
Comments? AFAICS, it's -stable fodder, the bug going all way back to
at least 3.7...
diff --git a/fs/dcache.c b/fs/dcache.c
index 3ffef7f..65f4aff 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1114,12 +1114,13 @@ resume:
out_unlock:
spin_unlock(_parent->d_lock);
+out:
done_seqretry(_lock, seq);
return;
rename_retry:
if (!retry)
- return;
+ goto out;
seq = 1;
goto again;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] zram: avoid NULL pointer access when reading mem_used_total
On Sat, Oct 25, 2014 at 05:26:31PM +0800, Weijie Yang wrote: > There is a rare NULL pointer bug in mem_used_total_show() in concurrent > situation, like this: > zram is not initialized, process A is a mem_used_total reader which runs > periodicity, while process B try to init zram. > > process A process B > access meta, get a NULL value > init zram, done > init_done() is true > access meta->mem_pool, get a NULL pointer BUG > > This patch fixes this issue. > > Signed-off-by: Weijie Yang Acked-by: Minchan Kim Thanks! -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] zram: make max_used_pages reset work correctly
Hello,
On Sat, Oct 25, 2014 at 05:25:11PM +0800, Weijie Yang wrote:
> The commit 461a8eee6a ("zram: report maximum used memory") introduces a new
> knob "mem_used_max" in zram.stats sysfs, and wants to reset it via write 0
> to the sysfs interface.
>
> However, the current code cann't reset it correctly, so let's fix it.
We wanted to reset it to current used total memory, not 0.
--
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
fs: lockup on rename_mutex in fs/dcache.c:1035
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel, I've stumbled on the following spew:
[ 6172.870045] =
[ 6172.870045] [ INFO: possible recursive locking detected ]
[ 6172.870045] 3.18.0-rc1-next-20141023-sasha-00036-g4dcabd5 #1415 Not tainted
[ 6172.870045] -
[ 6172.870045] trinity-c55/12752 is trying to acquire lock:
[ 6172.870045] (rename_lock){+.+...}, at: d_walk (include/linux/spinlock.h:309
fs/dcache.c:1035)
[ 6172.870045]
[ 6172.870045] but task is already holding lock:
[ 6172.870045] (rename_lock){+.+...}, at: d_walk (include/linux/spinlock.h:309
fs/dcache.c:1035)
[ 6172.870045]
[ 6172.870045] other info that might help us debug this:
[ 6172.900904] FAULT_INJECTION: forcing a failure
[ 6172.870045] Possible unsafe locking scenario:
[ 6172.870045]
[ 6172.870045]CPU0
[ 6172.870045]
[ 6172.870045] lock(rename_lock);
[ 6172.870045] lock(rename_lock);
[ 6172.870045]
[ 6172.870045] *** DEADLOCK ***
[ 6172.870045]
[ 6172.870045] May be due to missing lock nesting notation
[ 6172.870045]
[ 6172.870045] 1 lock held by trinity-c55/12752:
[ 6172.870045] #0: (rename_lock){+.+...}, at: d_walk
(include/linux/spinlock.h:309 fs/dcache.c:1035)
[ 6172.870045]
[ 6172.870045] stack backtrace:
[ 6172.870045] CPU: 1 PID: 12752 Comm: trinity-c55 Not tainted
3.18.0-rc1-next-20141023-sasha-00036-g4dcabd5 #1415
[ 6172.870045] 88070945b000 b6312fd0
8806d69ff728
[ 6172.870045] a8ff75ca 0011 b6312fd0
8806d69ff828
[ 6172.870045] 9f3a012b 880107fd76c0 880107fd76c0
0001
[ 6172.870045] Call Trace:
[ 6172.870045] dump_stack (lib/dump_stack.c:52)
[ 6172.870045] validate_chain.isra.10 (kernel/locking/lockdep.c:2134)
[ 6172.870045] ? kvm_clock_read (./arch/x86/include/asm/preempt.h:90
arch/x86/kernel/kvmclock.c:86)
[ 6172.870045] ? sched_clock_cpu (kernel/sched/clock.c:311)
[ 6172.870045] __lock_acquire (kernel/locking/lockdep.c:3184)
[ 6172.870045] lock_acquire (./arch/x86/include/asm/current.h:14
kernel/locking/lockdep.c:3604)
[ 6172.870045] ? d_walk (include/linux/spinlock.h:309 fs/dcache.c:1035)
[ 6172.870045] ? put_lock_stats.isra.7 (./arch/x86/include/asm/preempt.h:98
kernel/locking/lockdep.c:254)
[ 6172.870045] _raw_spin_lock (include/linux/spinlock_api_smp.h:143
kernel/locking/spinlock.c:151)
[ 6172.870045] ? d_walk (include/linux/spinlock.h:309 fs/dcache.c:1035)
[ 6172.870045] d_walk (include/linux/spinlock.h:309 fs/dcache.c:1035)
[ 6172.870045] ? d_walk (fs/dcache.c:1087)
[ 6172.870045] ? d_drop (fs/dcache.c:1336)
[ 6172.870045] ? select_collect (fs/dcache.c:1323)
[ 6172.870045] d_invalidate (fs/dcache.c:1381)
[ 6172.870045] lookup_fast (fs/namei.c:1440)
[ 6172.870045] ? _raw_spin_unlock (./arch/x86/include/asm/preempt.h:98
include/linux/spinlock_api_smp.h:152 kernel/locking/spinlock.c:183)
[ 6172.870045] ? lockref_put_or_lock (lib/lockref.c:135)
[ 6172.870045] ? dput (fs/dcache.c:626)
[ 6172.870045] walk_component (fs/namei.c:1545)
[ 6172.870045] ? security_inode_permission (security/security.c:573)
[ 6172.870045] ? __inode_permission (fs/namei.c:418)
[ 6172.870045] link_path_walk (fs/namei.c:1805)
[ 6172.870045] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
[ 6172.870045] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2559
kernel/locking/lockdep.c:2601)
[ 6172.870045] ? getname_flags (fs/namei.c:145)
[ 6172.870045] path_lookupat (fs/namei.c:1956)
[ 6172.870045] ? kmem_cache_alloc (include/linux/rcupdate.h:479
include/trace/events/kmem.h:53 mm/slub.c:2463)
[ 6172.870045] ? getname_flags (fs/namei.c:145)
[ 6172.870045] filename_lookup (fs/namei.c:2000)
[ 6172.870045] user_path_at_empty (fs/namei.c:2151)
[ 6172.870045] ? preempt_count_sub (kernel/sched/core.c:2662)
[ 6172.870045] user_path_at (fs/namei.c:2162)
[ 6172.870045] vfs_fstatat (fs/stat.c:106)
[ 6172.870045] SYSC_newlstat (fs/stat.c:284)
[ 6172.870045] ? syscall_trace_enter_phase2 (arch/x86/kernel/ptrace.c:1598)
[ 6172.870045] ? tracesys_phase2 (arch/x86/kernel/entry_64.S:518)
[ 6172.870045] SyS_newlstat (fs/stat.c:277)
[ 6172.870045] tracesys_phase2 (arch/x86/kernel/entry_64.S:529)
The machine proceeded to actually lock up, so this isn't a false positive.
Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[no subject]
You have been awarded $280,000 by Siemens company. reply for details. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] futex: fix a race condition between REQUEUE_PI and task death
free_pi_state and exit_pi_state_list both clean up futex_pi_state's.
exit_pi_state_list takes the hb lock first, and most callers of
free_pi_state do too. requeue_pi didn't, which means free_pi_state can
free the pi_state out from under exit_pi_state_list. For example:
task A| task B
exit_pi_state_list|
pi_state = |
curr->pi_state_list->next |
| futex_requeue(requeue_pi=1)
|// pi_state is the same as
|// the one in task A
|free_pi_state(pi_state)
| list_del_init(_state->list)
| kfree(pi_state)
list_del_init(_state->list) |
Move the free_pi_state calls in requeue_pi to before it drops the hb
locks which it's already holding.
I have test code that forks a bunch of processes, which all fork more
processes that do futex(FUTEX_WAIT_REQUEUE_PI), then do
futex(FUTEX_CMP_REQUEUE_PI) before killing the waiting processes. That
test consistently breaks QEMU VMs without this patch.
Although they both make it faster to crash, CONFIG_PREEMPT_RT and lots
of CPUs are not necessary to reproduce this problem. The symptoms range
from random reboots to corrupting the test program to corrupting whole
filesystems to strange BIOS errors. Crashdumps (when they get created at
all) are usually a mess, to the point of crashing tools used to examine
them.
Signed-off-by: Brian Silverman
---
kernel/futex.c | 44 +++-
1 file changed, 27 insertions(+), 17 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index 815d7af..c2c35a5 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -64,6 +64,7 @@
#include
#include
#include
+#include
#include
@@ -639,8 +640,16 @@ static struct futex_pi_state * alloc_pi_state(void)
return pi_state;
}
-static void free_pi_state(struct futex_pi_state *pi_state)
+/**
+ * Must be called with the hb lock held.
+ */
+static void free_pi_state(struct futex_pi_state *pi_state,
+ struct futex_hash_bucket *hb)
{
+ if (!pi_state) return;
+
+ lockdep_assert_held(>lock);
+
if (!atomic_dec_and_test(_state->refcount))
return;
@@ -1519,15 +1528,6 @@ static int futex_requeue(u32 __user *uaddr1, unsigned
int flags,
}
retry:
- if (pi_state != NULL) {
- /*
-* We will have to lookup the pi_state again, so free this one
-* to keep the accounting correct.
-*/
- free_pi_state(pi_state);
- pi_state = NULL;
- }
-
ret = get_futex_key(uaddr1, flags & FLAGS_SHARED, , VERIFY_READ);
if (unlikely(ret != 0))
goto out;
@@ -1558,6 +1558,12 @@ retry_private:
ret = get_futex_value_locked(, uaddr1);
if (unlikely(ret)) {
+ /*
+* We will have to lookup the pi_state again, so
+* free this one to keep the accounting correct.
+*/
+ free_pi_state(pi_state, hb2);
+ pi_state = NULL;
double_unlock_hb(hb1, hb2);
hb_waiters_dec(hb2);
@@ -1617,6 +1623,8 @@ retry_private:
case 0:
break;
case -EFAULT:
+ free_pi_state(pi_state, hb2);
+ pi_state = NULL;
double_unlock_hb(hb1, hb2);
hb_waiters_dec(hb2);
put_futex_key();
@@ -1632,6 +1640,8 @@ retry_private:
* exit to complete.
* - The user space value changed.
*/
+ free_pi_state(pi_state, hb2);
+ pi_state = NULL;
double_unlock_hb(hb1, hb2);
hb_waiters_dec(hb2);
put_futex_key();
@@ -1699,7 +1709,7 @@ retry_private:
} else if (ret) {
/* -EDEADLK */
this->pi_state = NULL;
- free_pi_state(pi_state);
+ free_pi_state(pi_state, hb2);
goto out_unlock;
}
}
@@ -1708,6 +1718,7 @@ retry_private:
}
out_unlock:
+ free_pi_state(pi_state, hb2);
double_unlock_hb(hb1, hb2);
hb_waiters_dec(hb2);
@@ -1725,8 +1736,6 @@ out_put_keys:
out_put_key1:
put_futex_key();
out:
- if (pi_state != NULL)
- free_pi_state(pi_state);
return ret ? ret : task_count;
}
@@ -1850,14 +1859,15
Re: [PATCH] futex: fix a race condition between REQUEUE_PI and task death
On Sat, 25 Oct 2014, Thomas Gleixner wrote:
> > pi_state_free and exit_pi_state_list both clean up futex_pi_state's.
> > exit_pi_state_list takes the hb lock first, and most callers of
> > pi_state_free do too. requeue_pi didn't, which causes lots of problems.
>
> "causes lots of problems" is not really a good explanation of the root
> cause. That wants a proper description of the race, i.e.
>
> CPU 0 CPU 1
> ...
>
> I'm surely someone who is familiar with that code, but it took me
> quite some time to understand whats going on. The casual reader will
> just go into brain spiral mode and give up.
Thinking about it again, I'm no longer so sure that exit_pi_state_list is the
only place that it can race against. However, I did catch that one with a
particularly lucky crashdump, so I know it _can_ happen there. Is just
giving an example for that good?
> > static void free_pi_state(struct futex_pi_state *pi_state)
>
> > @@ -1558,6 +1552,14 @@ retry_private:
> > ret = get_futex_value_locked(, uaddr1);
> >
> > if (unlikely(ret)) {
> > + if (flags & FLAGS_SHARED && pi_state != NULL) {
>
> Why is this dependend on "flags & FLAGS_SHARED"? The shared/private
> property has nothing to do with that at all, but I might be missing
> something.
Nothing... Good catch. It was a bad rebase.
Thanks,
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dma: imx-sdma: Add a new DMATYPE for SAI
On Fri, Oct 24, 2014 at 12:37:41PM -0700, Nicolin Chen wrote: > This patch simply adds a new DMATYPE for SAI which's included > in i.MX6 Solo X. > > Signed-off-by: Nicolin Chen Acked-by: Shawn Guo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/14] KVM: x86: Emulator fixes for eip canonical checks on near branches
On Oct 25, 2014 12:57 PM, "Nadav Amit" wrote: > > > > On Oct 24, 2014, at 20:53, Andy Lutomirski wrote: > > > > On 10/24/2014 08:07 AM, Paolo Bonzini wrote: > >> From: Nadav Amit > >> > >> Before changing rip (during jmp, call, ret, etc.) the target should be > >> asserted > >> to be canonical one, as real CPUs do. During sysret, both target rsp and > >> rip > >> should be canonical. If any of these values is noncanonical, a #GP > >> exception > >> should occur. The exception to this rule are syscall and sysenter > >> instructions > >> in which the assigned rip is checked during the assignment to the relevant > >> MSRs. > > > > Careful here. AMD CPUs (IIUC) send #PF (or maybe #GP) from CPL3 instead > > of #GP from CPL0 on sysret to a non-canonical address. That behavior is > > *far* better than the Intel behavior, and it may be important. > I wasn’t aware of this discrepancy, and it is really not written clearly in > AMD manual (I have to take your word). It is possible AMD decided to inject > #GP from CPL3 (#PF makes no sense). > > Anyhow, I think it is much harder to emulate AMD’s behaviour on Intel. > Theoretically, the easy way would be for the host to set a non-canonical > guest RIP/RSP and inject #GP, but Intel CPUs don’t allow the host to do so. > Instead, the host needs to emulate the entire exception injection. This is > very hard and error-prone process due to the variety of scenarios > (interrupt/task-gate on the IDT, #DF, nested-exceptions, etc.) > Hmm. Fair enough. I guess emulating AMD's behavior just on AMD is complicated. > > > > > If an OS relies on that behavior on AMD CPUs, and guest ring 3 can force > > guest ring 0 to do an emulated sysret to a non-canonical address, than > > the guest ring3 code can own the guest ring0 code. > > > > —Andy > > Sysexit (I mistakenly wrote sysret on the description), out of all the > control transfer instructions, seems the hardest to exploit, since it must be > executed in CPL0. > Remember that this bug does not result in host crashing, but in guest > crashing: If guest userspace is able to cause KVM to emulate a jump > instruction to a non-canonical address, it can crash the entire guest (by > preventing VM-entry from succeeding). To use sysexit for such exploit, the > guest userspace needs also to somehow fool the guest kernel into returning > into non-canonical RIP. True. I don't know about sysexit, but there's a long and storied history of sysret vulnerabilities based on this Intel erratum^Wclever design decision. As a practical matter, is sysexit ever emulated on Intel CPUs? If not, this may be irrelevant. --Andy > > Nadav -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vmalloced stacks on x86_64?
Am 26.10.2014 um 01:16 schrieb Andy Lutomirski: > On Sat, Oct 25, 2014 at 3:26 PM, Richard Weinberger > wrote: >> On Sat, Oct 25, 2014 at 2:22 AM, Andy Lutomirski wrote: >>> Is there any good reason not to use vmalloc for x86_64 stacks? >>> >>> The tricky bits I've thought of are: >>> >>> - On any context switch, we probably need to probe the new stack >>> before switching to it. That way, if it's going to fault due to an >>> out-of-sync pgd, we still have a stack available to handle the fault. >>> >>> - Any time we change cr3, we may need to check that the pgd >>> corresponding to rsp is there. If now, we need to sync it over. >>> >>> - For simplicity, we probably want all stack ptes to be present all >>> the time. This is fine; vmalloc already works that way. >>> >>> - If we overrun the stack, we double-fault. This should be easy to >>> detect: any double-fault where rsp is less than 20 bytes from the >>> bottom of the stack is a failure to deliver a non-IST exception due to >>> a stack overflow. The question is: what do we do if this happens? >>> We could just panic (guaranteed to work). We could also try to >>> recover by killing the offending task, but that might be a bit >>> challenging, since we're in IST context. We could do something truly >>> awful: increment RSP by a few hundred bytes, point RIP at do_exit, and >>> return from the double fault. >>> >>> Thoughts? This shouldn't be all that much code. >> >> FWIW, grsecurity has this already. >> Maybe we can reuse their GRKERNSEC_KSTACKOVERFLOW feature. >> It allocates the kernel stack using vmalloc() and installs guard pages. >> > > On brief inspection, grsecurity isn't actually vmallocing the stack. > It seems to be allocating it the normal way and then vmapping it. > That allows it to modify sg_set_buf to work on stack addresses (sigh). Oh, you're right. They have changed it. (But not the Kconfig help of course) Last time I looked they did a vmalloc(). I'm not sure which version of the patch was but I think it was code like that one: http://www.grsecurity.net/~spender/kstackovf32.diff Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vmalloced stacks on x86_64?
On Sat, Oct 25, 2014 at 3:26 PM, Richard Weinberger wrote: > On Sat, Oct 25, 2014 at 2:22 AM, Andy Lutomirski wrote: >> Is there any good reason not to use vmalloc for x86_64 stacks? >> >> The tricky bits I've thought of are: >> >> - On any context switch, we probably need to probe the new stack >> before switching to it. That way, if it's going to fault due to an >> out-of-sync pgd, we still have a stack available to handle the fault. >> >> - Any time we change cr3, we may need to check that the pgd >> corresponding to rsp is there. If now, we need to sync it over. >> >> - For simplicity, we probably want all stack ptes to be present all >> the time. This is fine; vmalloc already works that way. >> >> - If we overrun the stack, we double-fault. This should be easy to >> detect: any double-fault where rsp is less than 20 bytes from the >> bottom of the stack is a failure to deliver a non-IST exception due to >> a stack overflow. The question is: what do we do if this happens? >> We could just panic (guaranteed to work). We could also try to >> recover by killing the offending task, but that might be a bit >> challenging, since we're in IST context. We could do something truly >> awful: increment RSP by a few hundred bytes, point RIP at do_exit, and >> return from the double fault. >> >> Thoughts? This shouldn't be all that much code. > > FWIW, grsecurity has this already. > Maybe we can reuse their GRKERNSEC_KSTACKOVERFLOW feature. > It allocates the kernel stack using vmalloc() and installs guard pages. > On brief inspection, grsecurity isn't actually vmallocing the stack. It seems to be allocating it the normal way and then vmapping it. That allows it to modify sg_set_buf to work on stack addresses (sigh). After each switch_mm, it probes the whole kernel stack. (This seems dangerous to me -- if the live stack isn't mapped in the new mm, won't that double-fault?) I also see no evidence that it probes the new stack when switching stacks. I suspect that it only works because it gets lucky. If we're worried about on-stack DMA, we could (by config option or otherwise) allow DMA on a vmalloced stack, at least through the sg interfaces. And we could WARN and fix it :) --Andy P.S. I see what appears to be some of my code in grsec. I feel entirely justified in taking good bits of grsec and sticking them in the upstream kernel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm64: amd-seattle: Adding device tree for AMD Seattle platform
On 24.10.14 14:20, suravee.suthikulpa...@amd.com wrote: > From: Suravee Suthikulpanit > > Initial revision of device tree for AMD Seattle platform > > Cc: Mark Rutland > Cc: Will Deacon > Cc: Catalin Marinas > Cc: Rob Herring > Signed-off-by: Suravee Suthikulpanit > Signed-off-by: Thomas Lendacky > Signed-off-by: Joel Schopp > --- > arch/arm64/Kconfig | 5 + > arch/arm64/boot/dts/Makefile| 1 + > arch/arm64/boot/dts/amd-seattle-periph.dtsi | 164 > > arch/arm64/boot/dts/amd-seattle.dts | 126 + > 4 files changed, 296 insertions(+) > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 48b7437..e4c052f 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -137,6 +137,11 @@ source "kernel/Kconfig.freezer" > > menu "Platform selection" > > +config ARCH_SEATTLE > + bool "AMD Seattle SoC Family" > + help > + This enables support for AMD Seattle SOC Family > + > config ARCH_THUNDER > bool "Cavium Inc. Thunder SoC Family" > help > diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile > index f8001a6..6c27047 100644 > --- a/arch/arm64/boot/dts/Makefile > +++ b/arch/arm64/boot/dts/Makefile > @@ -1,6 +1,7 @@ > dtb-$(CONFIG_ARCH_THUNDER) += thunder-88xx.dtb > dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb > dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb > +dtb-$(CONFIG_ARCH_SEATTLE) += amd-seattle.dtb This option doesn't exist in upstream kernels, does it? Why not just make it dtb-y? Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 03/14] perf tools: Kbuild source related fixies
From: Jiri Olsa
Fixing several sources config dependencies to allow
separate config builds.
This commit was originally created by Jiri Olsa in 2013. Minor changes
were needed to get it working one year later:
* Remove #ifdef directives related with GUI / TUI (because of code
changes in ui/setup.c)
* Fix a link issue if the option BUILTIN_TRACE is disabled.
* Fix typo (CONFIG_BULTIN_ instead CONFIG_BUILTIN_)
Signed-off-by: Jiri Olsa
Cc: Arnaldo Carvalho de Melo
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Paul Mackerras
Cc: Corey Ashford
Cc: Frederic Weisbecker
Cc: Namhyung Kim
Cc: Borislav Petkov
Cc: Michal Marek
Cc: linux-kbu...@vger.kernel.org
Cc: Stephane Eranian
Signed-off-by: Alexis Berlemont
---
tools/perf/builtin-annotate.c| 6 +++---
tools/perf/builtin-lock.c| 5 -
tools/perf/builtin-report.c | 2 +-
tools/perf/builtin-sched.c | 3 +++
tools/perf/builtin-top.c | 4 ++--
tools/perf/perf.c| 10 --
tools/perf/ui/browsers/scripts.c | 4
tools/perf/ui/setup.c| 6 +++---
8 files changed, 28 insertions(+), 12 deletions(-)
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index 19cb967..a46af8f 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -155,7 +155,7 @@ find_next:
/* skip missing symbols */
nd = rb_next(nd);
-#ifdef CONFIG_TUI
+#if defined(CONFIG_TUI) || !defined(CONFIG_KBUILD)
} else if (use_browser == 1) {
struct rb_node *next = NULL;
key = hist_entry__tui_annotate(he, evsel, NULL);
@@ -303,9 +303,9 @@ int cmd_annotate(int argc, const char **argv, const char
*prefix __maybe_unused)
OPT_BOOLEAN('D', "dump-raw-trace", _trace,
"dump raw trace in ASCII"),
OPT_BOOLEAN(0, "gtk", _gtk, "Use the GTK interface"),
-#ifdef CONFIG_TUI
+#if defined(CONFIG_TUI) || !defined(CONFIG_KBUILD)
OPT_BOOLEAN(0, "tui", _tui, "Use the TUI interface"),
-#endif /* CONFIG_TUI */
+#endif
OPT_BOOLEAN(0, "stdio", _stdio, "Use the stdio interface"),
OPT_STRING('k', "vmlinux", _conf.vmlinux_name,
"file", "vmlinux pathname"),
diff --git a/tools/perf/builtin-lock.c b/tools/perf/builtin-lock.c
index e7ec715..05c0e1c 100644
--- a/tools/perf/builtin-lock.c
+++ b/tools/perf/builtin-lock.c
@@ -1,4 +1,5 @@
#include "builtin.h"
+#include "builtin-cmds.h"
#include "perf.h"
#include "util/evlist.h"
@@ -995,9 +996,11 @@ int cmd_lock(int argc, const char **argv, const char
*prefix __maybe_unused)
usage_with_options(report_usage,
report_options);
}
rc = __cmd_report(false);
+#ifdef CONFIG_BUILTIN_SCRIPT
} else if (!strcmp(argv[0], "script")) {
/* Aliased to 'perf script' */
- return cmd_script(argc, argv, prefix);
+ rc = cmd_script(argc, argv, prefix);
+#endif
} else if (!strcmp(argv[0], "info")) {
if (argc) {
argc = parse_options(argc, argv,
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 00d93ff..b639e58 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -407,7 +407,7 @@ static int report__browse_hists(struct report *rep)
const char *help = "For a higher level overview, try: perf report
--sort comm,dso";
switch (use_browser) {
-#ifdef CONFIG_TUI
+#if defined(CONFIG_TUI) || !defined(CONFIG_KBUILD)
case 1:
ret = perf_evlist__tui_browse_hists(evlist, help, NULL,
rep->min_percent,
diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index 891c393..e38b021 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -1,4 +1,5 @@
#include "builtin.h"
+#include "builtin-cmds.h"
#include "perf.h"
#include "util/util.h"
@@ -1742,11 +1743,13 @@ int cmd_sched(int argc, const char **argv, const char
*prefix __maybe_unused)
if (!argc)
usage_with_options(sched_usage, sched_options);
+#ifdef CONFIG_BUILTIN_SCRIPT
/*
* Aliased to 'perf script' for now:
*/
if (!strcmp(argv[0], "script"))
return cmd_script(argc, argv, prefix);
+#endif
if (!strncmp(argv[0], "rec", 3)) {
return __cmd_record(argc, argv);
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index a2ff8b7..6f04452 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -535,7 +535,7 @@ static bool perf_top__handle_keypress(struct perf_top *top,
int c)
return ret;
}
-#ifdef CONFIG_TUI
+#if defined(CONFIG_TUI) || !defined(CONFIG_KBUILD)
static void perf_top__sort_new_samples(void *arg)
{
struct perf_top *t = arg;
@@ -981,7 +981,7 @@ static int
[PATCH v4 05/14] perf kbuild: remove Makefile.perf
The file Makefile.perf contained legacy build rules. It is replaced by
Makefile.kbuild which relies on Kbuild. Consequently, some minor
points need updates:
* The constant CONFIG_KBUILD can be removed
* The main Makefile wrapper now call Makefile.kbuild instead of
Makefile.perf
Signed-off-by: Alexis Berlemont
---
tools/perf/Makefile | 2 +-
tools/perf/Makefile.kbuild| 2 +-
tools/perf/Makefile.perf | 981 --
tools/perf/builtin-annotate.c | 4 +-
tools/perf/builtin-cmds.h | 25 --
tools/perf/builtin-report.c | 2 +-
tools/perf/builtin-top.c | 4 +-
tools/perf/ui/setup.c | 4 +-
8 files changed, 9 insertions(+), 1015 deletions(-)
delete mode 100644 tools/perf/Makefile.perf
diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index cb2e586..4512f16 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -55,7 +55,7 @@ define print_msg
endef
define make
- @$(MAKE) -f Makefile.perf --no-print-directory -j$(JOBS) O=$(FULL_O)
$(SET_DEBUG) $@
+ @$(MAKE) -f Makefile.kbuild --no-print-directory -j$(JOBS) O=$(FULL_O)
$(SET_DEBUG) $@
endef
#
diff --git a/tools/perf/Makefile.kbuild b/tools/perf/Makefile.kbuild
index 51eba07..8d9e8b0 100644
--- a/tools/perf/Makefile.kbuild
+++ b/tools/perf/Makefile.kbuild
@@ -43,7 +43,7 @@ export QUIET_BISON QUIET_FLEX
ifeq ($(KBUILD_SRC),)
-ifeq ("$(origin O)", "command line")
+ifneq ($(O),)
KBUILD_OUTPUT := $(O)
else
KBUILD_OUTPUT := $(objtree)
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
deleted file mode 100644
index 0e84559..000
--- a/tools/perf/Makefile.perf
+++ /dev/null
@@ -1,981 +0,0 @@
-include ../scripts/Makefile.include
-
-# The default target of this Makefile is...
-all:
-
-include config/utilities.mak
-
-# Define V to have a more verbose compile.
-#
-# Define VF to have a more verbose feature check output.
-#
-# Define O to save output files in a separate directory.
-#
-# Define ARCH as name of target architecture if you want cross-builds.
-#
-# Define CROSS_COMPILE as prefix name of compiler if you want cross-builds.
-#
-# Define NO_LIBPERL to disable perl script extension.
-#
-# Define NO_LIBPYTHON to disable python script extension.
-#
-# Define PYTHON to point to the python binary if the default
-# `python' is not correct; for example: PYTHON=python2
-#
-# Define PYTHON_CONFIG to point to the python-config binary if
-# the default `$(PYTHON)-config' is not correct.
-#
-# Define ASCIIDOC8 if you want to format documentation with AsciiDoc 8
-#
-# Define DOCBOOK_XSL_172 if you want to format man pages with DocBook XSL
v1.72.
-#
-# Define LDFLAGS=-static to build a static binary.
-#
-# Define EXTRA_CFLAGS=-m64 or EXTRA_CFLAGS=-m32 as appropriate for
cross-builds.
-#
-# Define NO_DWARF if you do not want debug-info analysis feature at all.
-#
-# Define WERROR=0 to disable treating any warnings as errors.
-#
-# Define NO_NEWT if you do not want TUI support. (deprecated)
-#
-# Define NO_SLANG if you do not want TUI support.
-#
-# Define NO_GTK2 if you do not want GTK+ GUI support.
-#
-# Define NO_DEMANGLE if you do not want C++ symbol demangling.
-#
-# Define NO_LIBELF if you do not want libelf dependency (e.g. cross-builds)
-#
-# Define NO_LIBUNWIND if you do not want libunwind dependency for dwarf
-# backtrace post unwind.
-#
-# Define NO_BACKTRACE if you do not want stack backtrace debug feature
-#
-# Define NO_LIBNUMA if you do not want numa perf benchmark
-#
-# Define NO_LIBAUDIT if you do not want libaudit support
-#
-# Define NO_LIBBIONIC if you do not want bionic support
-#
-# Define NO_LIBDW_DWARF_UNWIND if you do not want libdw support
-# for dwarf backtrace post unwind.
-#
-# Define NO_PERF_READ_VDSO32 if you do not want to build perf-read-vdso32
-# for reading the 32-bit compatibility VDSO in 64-bit mode
-#
-# Define NO_PERF_READ_VDSOX32 if you do not want to build perf-read-vdsox32
-# for reading the x32 mode 32-bit compatibility VDSO in 64-bit mode
-
-ifeq ($(srctree),)
-srctree := $(patsubst %/,%,$(dir $(shell pwd)))
-srctree := $(patsubst %/,%,$(dir $(srctree)))
-#$(info Determined 'srctree' to be $(srctree))
-endif
-
-ifneq ($(objtree),)
-#$(info Determined 'objtree' to be $(objtree))
-endif
-
-ifneq ($(OUTPUT),)
-#$(info Determined 'OUTPUT' to be $(OUTPUT))
-endif
-
-$(OUTPUT)PERF-VERSION-FILE: ../../.git/HEAD
- @$(SHELL_PATH) util/PERF-VERSION-GEN $(OUTPUT)
- @touch $(OUTPUT)PERF-VERSION-FILE
-
-CC = $(CROSS_COMPILE)gcc
-AR = $(CROSS_COMPILE)ar
-PKG_CONFIG = $(CROSS_COMPILE)pkg-config
-
-RM = rm -f
-LN = ln -f
-MKDIR = mkdir
-FIND= find
-INSTALL = install
-FLEX= flex
-BISON = bison
-STRIP = strip
-
-LIB_DIR = $(srctree)/tools/lib/api/
-TRACE_EVENT_DIR = $(srctree)/tools/lib/traceevent/
-
-# include config/Makefile by default and rule out
-# non-config cases
-config := 1
-
-NON_CONFIG_TARGETS := clean TAGS tags cscope help
-
-ifdef MAKECMDGOALS
-ifeq ($(filter-out
Re: vmalloced stacks on x86_64?
On Sat, Oct 25, 2014 at 2:22 AM, Andy Lutomirski wrote: > Is there any good reason not to use vmalloc for x86_64 stacks? > > The tricky bits I've thought of are: > > - On any context switch, we probably need to probe the new stack > before switching to it. That way, if it's going to fault due to an > out-of-sync pgd, we still have a stack available to handle the fault. > > - Any time we change cr3, we may need to check that the pgd > corresponding to rsp is there. If now, we need to sync it over. > > - For simplicity, we probably want all stack ptes to be present all > the time. This is fine; vmalloc already works that way. > > - If we overrun the stack, we double-fault. This should be easy to > detect: any double-fault where rsp is less than 20 bytes from the > bottom of the stack is a failure to deliver a non-IST exception due to > a stack overflow. The question is: what do we do if this happens? > We could just panic (guaranteed to work). We could also try to > recover by killing the offending task, but that might be a bit > challenging, since we're in IST context. We could do something truly > awful: increment RSP by a few hundred bytes, point RIP at do_exit, and > return from the double fault. > > Thoughts? This shouldn't be all that much code. FWIW, grsecurity has this already. Maybe we can reuse their GRKERNSEC_KSTACKOVERFLOW feature. It allocates the kernel stack using vmalloc() and installs guard pages. -- Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 13/14] perf kbuild: final cosmetic changes
* Correctly rename internal makefile variables * Remove makefiles in tools/perf/config which became empty and useless * Remove builtin-cmds.h * Remove arch/x86/Makefile * Improve outputs of clean and install targets * Remove creation of PERF-FEATURES file which is redundant with the .config file generated by Kconfig. * replace HAVE_KVM_STAT_SUPPORT by a Kconfig option * replace HAVE_SKIP_CALLCHAIN_IDX by a Kconfig option * add Kconfig options for 32-bit compatibility VDSOs Signed-off-by: Alexis Berlemont --- Changes since v3: * Add Kconfig options for 32-bit compatibility VDSOs tools/perf/Kconfig| 29 - tools/perf/Makefile.kbuild| 76 ++-- tools/perf/arch/s390/util/Kbuild | 2 +- tools/perf/arch/x86/Makefile | 17 -- tools/perf/arch/x86/util/Kbuild | 2 +- tools/perf/builtin-cmds.h | 6 -- tools/perf/builtin-help.c | 2 +- tools/perf/builtin-kvm.c | 6 +- tools/perf/builtin-lock.c | 2 +- tools/perf/builtin-sched.c| 2 +- tools/perf/config/Makefile| 108 +++--- tools/perf/config/Makefile.fix-config | 6 -- tools/perf/config/Makefile.fix-legacy | 2 - tools/perf/perf.c | 2 +- tools/perf/util/vdso.c| 5 +- 15 files changed, 115 insertions(+), 152 deletions(-) delete mode 100644 tools/perf/arch/x86/Makefile delete mode 100644 tools/perf/builtin-cmds.h delete mode 100644 tools/perf/config/Makefile.fix-config delete mode 100644 tools/perf/config/Makefile.fix-legacy diff --git a/tools/perf/Kconfig b/tools/perf/Kconfig index 54a194d..83f3d6d 100644 --- a/tools/perf/Kconfig +++ b/tools/perf/Kconfig @@ -5,9 +5,9 @@ config TARGET_ARCH string option env="ARCH" -config TARGET_IS_X86_64 +config TARGET_IS_64_BIT string - option env="IS_X86_64" + option env="IS_64_BIT" config TARGET_CROSS_COMPILE string @@ -19,7 +19,7 @@ config ARCH config X86_64 bool - default y if TARGET_ARCH = "x86" && TARGET_IS_X86_64 = "1" + default y if TARGET_ARCH = "x86" && TARGET_IS_64_BIT = "1" config CROSS_COMPILE string @@ -128,6 +128,13 @@ config BUILTIN_KVM ---help--- Tool to trace/measure kvm guest os +config BUILTIN_KVM_STAT + bool "kvm-stat" + default y + depends on BUILTIN_KVM && (ARCH = "x86" || ARCH = "s390") +---help--- + Get performance counter statistics on a kvm guest os. + config BUILTIN_LIST bool "list" default y @@ -405,6 +412,22 @@ config PERF_REGS Cache register accesses for unwind processing to speed-up performances. +config READ_VDSO32 + bool "Support 32-bit compatibility" + depends on TARGET_IS_64_BIT = "1" + default y +---help--- + On 64-bits architecture, support 32-bit compatibility VDSOs + +config READ_VDSOX32 + bool "Support x32 compatibility" + depends on X86_64 + default y +---help--- + On x86_64 architecture, support x32 compatibility VDSOs + (code for x86_64 architecture but "long" and pointer types + set to 32 bits) + endmenu menu "Build" diff --git a/tools/perf/Makefile.kbuild b/tools/perf/Makefile.kbuild index b48fe7f..84b7c01 100644 --- a/tools/perf/Makefile.kbuild +++ b/tools/perf/Makefile.kbuild @@ -1,6 +1,5 @@ srctree := $(abspath $(if $(KBUILD_SRC),$(KBUILD_SRC),$(CURDIR)/../../)) objtree := $(abspath $(if $(KBUILD_SRC),$(CURDIR),$(CURDIR)/../..)) - VPATH := $(srctree) export srctree VPATH @@ -36,7 +35,8 @@ export quiet Q KBUILD_VERBOSE ifndef V QUIET_LINK = @echo ' LD $@'; QUIET_GEN = @echo ' GEN $@'; -QUIET_CLEAN = @echo ' CLEAN tools/perf'; +QUIET_CLEAN = @printf ' CLEAN%s\n' $1; +QUIET_INSTALL = @printf ' INSTALL %s\n' $1; endif export QUIET_BISON QUIET_FLEX @@ -127,7 +127,7 @@ export CONFIG_DETECTED # arch-related main variables include $(src-perf)/config/Makefile.arch -export ARCH IS_X86_64 CROSS_COMPILE +export ARCH IS_X86_64 IS_64_BIT CROSS_COMPILE # external .a libs LIBTRACEEVENT := $(obj-kernel)/tools/lib/traceevent/libtraceevent.a @@ -158,7 +158,6 @@ $(CONFIG_DETECTED): $(KCONFIG_CONFIG) # no need to include auto.conf.cmd, because .config # is the only dependency here $(KCONFIG_AUTOCONFIG): $(KCONFIG_CONFIG) $(CONFIG_DETECTED) - $(Q)$(MAKE) -f $(src-perf)/config/Makefile.fix-config $(Q)mkdir -p $(obj-perf)/include/config $(Q)mkdir -p $(obj-perf)/include/generated $(Q)$(MAKE) -s $(build)=scripts/kconfig silentoldconfig @@ -167,22 +166,26 @@ $(KCONFIG_AUTOCONFIG): $(KCONFIG_CONFIG) $(CONFIG_DETECTED) clean-dirs := $(addprefix _clean_, tools/perf/) $(clean-dirs): + $(call QUIET_CLEAN, core-objs) $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.clean obj=$(patsubst _clean_%,%,$@) -clean:
[PATCH v4 06/14] perf kbuild: remove legacy tui/gui-related build variables
Remove NO_SLANG (replaced by CONFIG_LIBSLANG) Remove HAVE_SLANG_SUPPORT from CFLAGS (replaced by CONFIG_LIBSLANG) Remove NO_GTK2 (replaced by CONFIG_LIBGTK2 or CONFIG_GTK2) Remove HAVE_GTK2_SUPPORT from CFLAGS (replaced by CONFIG_LIBGTK2) Remove HAVE_GTK_INFO_BAR_SUPPORT from CFLAGS (replaced by CONFIG_LIBGTK2_INFOBAR) Signed-off-by: Alexis Berlemont --- tools/perf/Kconfig| 21 + tools/perf/config/Makefile| 20 ++-- tools/perf/config/Makefile.fix-config | 24 tools/perf/config/Makefile.fix-legacy | 8 tools/perf/ui/gtk/browser.c | 4 +++- tools/perf/ui/gtk/gtk.h | 5 +++-- tools/perf/ui/gtk/util.c | 6 -- tools/perf/ui/setup.c | 4 +++- tools/perf/ui/ui.h| 4 +++- tools/perf/util/annotate.h| 4 +++- tools/perf/util/hist.h| 3 ++- 11 files changed, 48 insertions(+), 55 deletions(-) diff --git a/tools/perf/Kconfig b/tools/perf/Kconfig index f9fcf9e..eb59567 100644 --- a/tools/perf/Kconfig +++ b/tools/perf/Kconfig @@ -171,6 +171,7 @@ config STDIO config TUI bool "Tui (slang based)" + depends on LIBSLANG default y ---help--- Text-based user interface which provides windowing @@ -179,6 +180,7 @@ config TUI config GTK2 bool "Gtk2" default y + depends on LIBGTK2 ---help--- Elaborate display mode based on libgtk2. @@ -186,12 +188,31 @@ endmenu menu "Libraries / Dependencies" +config LIBSLANG + bool "Slang (libslang)" + default y +---help--- + libslang + config LIBAUDIT bool "Audit (libaudit)" default y ---help--- Linux audit framework dependency. +config LIBGTK2 + bool "Gtk2 (libgtk2)" + default y +---help--- + libgtk2 + +config LIBGTK2_INFOBAR + bool "Gtk2 infobar (libgtk2)" + depends on LIBGTK2 + default y +---help--- + libgtk2-infobar + config LIBPERL bool "Perl" default y diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile index d5fec7c..e41c9de 100644 --- a/tools/perf/config/Makefile +++ b/tools/perf/config/Makefile @@ -447,32 +447,26 @@ ifndef NO_LIBAUDIT endif endif -ifdef NO_NEWT - NO_SLANG=1 -endif - -ifndef NO_SLANG +ifdef CONFIG_LIBSLANG ifneq ($(feature-libslang), 1) -msg := $(warning slang not found, disables TUI support. Please install slang-devel or libslang-dev); -NO_SLANG := 1 +msg := $(warning slang not found, disables SLANG and TUI supports. Please install slang-devel or libslang-dev); +$(shell $(KCONFIG_SCRIPT) -d CONFIG_LIBSLANG) else # Fedora has /usr/include/slang/slang.h, but ubuntu /usr/include/slang.h CFLAGS += -I/usr/include/slang -CFLAGS += -DHAVE_SLANG_SUPPORT EXTLIBS += -lslang endif endif -ifndef NO_GTK2 +ifdef CONFIG_LIBGTK2 FLAGS_GTK2=$(CFLAGS) $(LDFLAGS) $(EXTLIBS) $(shell $(PKG_CONFIG) --libs --cflags gtk+-2.0 2>/dev/null) ifneq ($(feature-gtk2), 1) msg := $(warning GTK2 not found, disables GTK2 support. Please install gtk2-devel or libgtk2.0-dev); -NO_GTK2 := 1 +$(shell $(KCONFIG_SCRIPT) -d CONFIG_LIBGTK2) else ifeq ($(feature-gtk2-infobar), 1) - GTK_CFLAGS := -DHAVE_GTK_INFO_BAR_SUPPORT + $(shell $(KCONFIG_SCRIPT) -d CONFIG_LIBGTK2_INFOBAR) endif -CFLAGS += -DHAVE_GTK2_SUPPORT GTK_CFLAGS += $(shell $(PKG_CONFIG) --cflags gtk+-2.0 2>/dev/null) GTK_LIBS := $(shell $(PKG_CONFIG) --libs gtk+-2.0 2>/dev/null) EXTLIBS += -ldl @@ -828,8 +822,6 @@ all: $(call store,NO_LIBUNWIND) $(call store,NO_LIBPERL) $(call store,NO_LIBPYTHON) - $(call store,NO_NEWT) - $(call store,NO_GTK2) $(call store,NO_DEMANGLE) $(call store,NO_LIBELF) $(call store,NO_LIBUNWIND) diff --git a/tools/perf/config/Makefile.fix-config b/tools/perf/config/Makefile.fix-config index 7f65fdb..3d84008 100644 --- a/tools/perf/config/Makefile.fix-config +++ b/tools/perf/config/Makefile.fix-config @@ -19,30 +19,6 @@ dummy := $(shell $(CONFIG) -d CONFIG_LIBPYTHON) endif endif -# NO_NEWT -ifdef CONFIG_TUI -ifdef NO_NEWT -dummy := $(info Disabling CONFIG_TUI) -dummy := $(shell $(CONFIG) -d CONFIG_TUI) -endif -endif - -# NO_NEWT -ifdef CONFIG_TUI -ifdef NO_SLANG -dummy := $(info Disabling CONFIG_TUI) -dummy := $(shell $(CONFIG) -d CONFIG_TUI) -endif -endif - -# NO_GTK2 -ifdef CONFIG_GTK2 -ifdef NO_GTK2 -dummy := $(info Disabling CONFIG_GTK2) -dummy := $(shell $(CONFIG) -d CONFIG_GTK2) -endif -endif - # NO_DEMANGLE ifdef CONFIG_DEMANGLE ifdef NO_DEMANGLE diff --git a/tools/perf/config/Makefile.fix-legacy b/tools/perf/config/Makefile.fix-legacy index 2ec91f3..ca219e7 100644 --- a/tools/perf/config/Makefile.fix-legacy +++ b/tools/perf/config/Makefile.fix-legacy @@ -9,14 +9,6 @@
[PATCH v4 08/14] perf kbuild: cross-compilation variables are now handled in Kconfig
The variable CONFIG_ARCH and CONFIG_CROSS_COMPILE were added.
Signed-off-by: Alexis Berlemont
---
tools/perf/Kconfig | 24
tools/perf/Makefile.kbuild | 8
tools/perf/arch/x86/include/perf_regs.h | 8 +---
tools/perf/arch/x86/tests/regs_load.S | 3 ++-
tools/perf/arch/x86/util/unwind-libunwind.c | 5 +++--
tools/perf/bench/mem-memcpy-arch.h | 4 +++-
tools/perf/bench/mem-memcpy.c | 4 +++-
tools/perf/bench/mem-memset-arch.h | 4 +++-
tools/perf/bench/mem-memset.c | 4 +++-
tools/perf/config/Makefile | 7 ++-
10 files changed, 52 insertions(+), 19 deletions(-)
diff --git a/tools/perf/Kconfig b/tools/perf/Kconfig
index 026ef67..5f85923 100644
--- a/tools/perf/Kconfig
+++ b/tools/perf/Kconfig
@@ -1,6 +1,30 @@
mainmenu "The perf configuration"
+config TARGET_ARCH
+ string
+ option env="ARCH"
+
+config TARGET_IS_X86_64
+ string
+ option env="IS_X86_64"
+
+config TARGET_CROSS_COMPILE
+ string
+ option env="CROSS_COMPILE"
+
+config ARCH
+ string
+ default TARGET_ARCH
+
+config X86_64
+ bool
+ default y if TARGET_ARCH = "x86" && TARGET_IS_X86_64 = "1"
+
+config CROSS_COMPILE
+ string
+ default TARGET_CROSS_COMPILE
+
menu "Built-in commands"
config BUILTIN_RECORD
diff --git a/tools/perf/Makefile.kbuild b/tools/perf/Makefile.kbuild
index 8d9e8b0..b48fe7f 100644
--- a/tools/perf/Makefile.kbuild
+++ b/tools/perf/Makefile.kbuild
@@ -123,9 +123,12 @@ export KCONFIG_AUTOHEADER KCONFIG_AUTOCONFIG KCONFIG_SCRIPT
# perf detected config
CONFIG_DETECTED := $(obj-perf)/.config-detected
-
export CONFIG_DETECTED
+# arch-related main variables
+include $(src-perf)/config/Makefile.arch
+export ARCH IS_X86_64 CROSS_COMPILE
+
# external .a libs
LIBTRACEEVENT := $(obj-kernel)/tools/lib/traceevent/libtraceevent.a
LIBAPIKFS := $(obj-kernel)/tools/lib/api/libapikfs.a
@@ -202,9 +205,6 @@ ifndef dont-detect
ifdef CONFIG_DETECTED_STORED
# Following variables are needed within Kbuild files, we need
# to export them as they are not part of the .config set.
-export CONFIG_ARCH := $(ARCH)
-export CROSS_COMPILE
-export CONFIG_X86_64
export htmldir_SQ
export infodir_SQ
export mandir_SQ
diff --git a/tools/perf/arch/x86/include/perf_regs.h
b/tools/perf/arch/x86/include/perf_regs.h
index 7df517a..d969cca 100644
--- a/tools/perf/arch/x86/include/perf_regs.h
+++ b/tools/perf/arch/x86/include/perf_regs.h
@@ -5,9 +5,11 @@
#include
#include
+#include "generated/autoconf.h"
+
void perf_regs_load(u64 *regs);
-#ifndef HAVE_ARCH_X86_64_SUPPORT
+#ifndef CONFIG_X86_64
#define PERF_REGS_MASK ((1ULL << PERF_REG_X86_32_MAX) - 1)
#define PERF_REGS_MAX PERF_REG_X86_32_MAX
#define PERF_SAMPLE_REGS_ABI PERF_SAMPLE_REGS_ABI_32
@@ -58,7 +60,7 @@ static inline const char *perf_reg_name(int id)
return "FS";
case PERF_REG_X86_GS:
return "GS";
-#ifdef HAVE_ARCH_X86_64_SUPPORT
+#ifdef CONFIG_X86_64
case PERF_REG_X86_R8:
return "R8";
case PERF_REG_X86_R9:
@@ -75,7 +77,7 @@ static inline const char *perf_reg_name(int id)
return "R14";
case PERF_REG_X86_R15:
return "R15";
-#endif /* HAVE_ARCH_X86_64_SUPPORT */
+#endif /* CONFIG_X86_64 */
default:
return NULL;
}
diff --git a/tools/perf/arch/x86/tests/regs_load.S
b/tools/perf/arch/x86/tests/regs_load.S
index 60875d5..822a797 100644
--- a/tools/perf/arch/x86/tests/regs_load.S
+++ b/tools/perf/arch/x86/tests/regs_load.S
@@ -1,4 +1,5 @@
#include
+#include "generated/autoconf.h"
#define AX 0
#define BX 1 * 8
@@ -26,7 +27,7 @@
#define R1523 * 8
.text
-#ifdef HAVE_ARCH_X86_64_SUPPORT
+#ifdef CONFIG_X86_64
ENTRY(perf_regs_load)
movq %rax, AX(%rdi)
movq %rbx, BX(%rdi)
diff --git a/tools/perf/arch/x86/util/unwind-libunwind.c
b/tools/perf/arch/x86/util/unwind-libunwind.c
index db25e93..e4960c1 100644
--- a/tools/perf/arch/x86/util/unwind-libunwind.c
+++ b/tools/perf/arch/x86/util/unwind-libunwind.c
@@ -1,11 +1,12 @@
#include
#include
+#include "generated/autoconf.h"
#include "perf_regs.h"
#include "../../util/unwind.h"
#include "../../util/debug.h"
-#ifdef HAVE_ARCH_X86_64_SUPPORT
+#ifdef CONFIG_X86_64
int libunwind__arch_reg_id(int regnum)
{
int id;
@@ -109,4 +110,4 @@ int libunwind__arch_reg_id(int regnum)
return id;
}
-#endif /* HAVE_ARCH_X86_64_SUPPORT */
+#endif /* CONFIG_X86_64 */
diff --git a/tools/perf/bench/mem-memcpy-arch.h
b/tools/perf/bench/mem-memcpy-arch.h
index 57b4ed8..8e3f0a9 100644
--- a/tools/perf/bench/mem-memcpy-arch.h
+++ b/tools/perf/bench/mem-memcpy-arch.h
@@ -1,5 +1,7 @@
-#ifdef HAVE_ARCH_X86_64_SUPPORT
+#include "generated/autoconf.h"
+
+#ifdef CONFIG_X86_64
#define MEMCPY_FN(fn, name, desc) \
[PATCH v4 10/14] perf kbuild: remove legacy libelf-related build variables
Remove NO_LIBELF (replaced by CONFIG_LIBELF)
Remove HAVE_LIBELF_SUPPORT (replaced by CONFIG_LIBELF)
Remove HAVE_LIBELF_MMAP_SUPPORT (replaced by CONFIG_LIBELF_MMAP)
Remove HAVE_LIBELF_GETPHDRNUM__SUPPORT (replaced by
CONFIG_LIBELF_GETPHDRNUM_)
Signed-off-by: Alexis Berlemont
---
tools/perf/Kconfig| 23 ++
tools/perf/builtin-inject.c | 2 +-
tools/perf/config/Makefile| 37 +++
tools/perf/config/Makefile.fix-config | 18 -
tools/perf/config/Makefile.fix-legacy | 4
tools/perf/perf.c | 2 +-
tools/perf/util/generate-cmdlist.sh | 4 ++--
tools/perf/util/map.c | 3 ++-
tools/perf/util/symbol-elf.c | 3 ++-
tools/perf/util/symbol.h | 8
10 files changed, 51 insertions(+), 53 deletions(-)
diff --git a/tools/perf/Kconfig b/tools/perf/Kconfig
index 29853a6..2eaf3ca 100644
--- a/tools/perf/Kconfig
+++ b/tools/perf/Kconfig
@@ -256,6 +256,7 @@ config TIMERFD
Timer via file descriptor
config DEMANGLE
+ depends on LIBELF
bool "Demangle symbols"
default y
---help---
@@ -298,7 +299,29 @@ choice
Builtin elf support.
endchoice
+config LIBELF_MMAP
+depends on LIBELF
+ bool "Libelf mmap support"
+ default y
+---help---
+ libdelf mmap
+
+config LIBELF_GETPHDRNUM
+depends on LIBELF
+ default y
+ bool "Libelf getphdrnum support"
+---help---
+ libdelf mmap
+
+config LIBDWARF
+ depends on LIBELF
+ bool "Dwarf (libdwarf)"
+ default y
+---help---
+ libdwarf
+
config LIBUNWIND
+depends on LIBELF
bool "User space libunwind callchains"
default y
---help---
diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
index 06f1758..cb19ccc 100644
--- a/tools/perf/builtin-inject.c
+++ b/tools/perf/builtin-inject.c
@@ -229,7 +229,7 @@ static int perf_event__inject_buildid(struct perf_tool
*tool,
* account this as unresolved.
*/
} else {
-#ifdef HAVE_LIBELF_SUPPORT
+#ifdef CONFIG_LIBELF
pr_warning("no symbols found in %s, maybe "
"install a debug package?\n",
al.map->dso->long_name);
diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index 15bd90b..19dab72 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -305,12 +305,7 @@ ifdef CONFIG_BIONIC
endif
endif
-ifdef NO_LIBELF
- NO_DWARF := 1
- NO_DEMANGLE := 1
- NO_LIBUNWIND := 1
- NO_LIBDW_DWARF_UNWIND := 1
-else
+ifdef CONFIG_LIBELF
ifeq ($(feature-libelf), 0)
ifeq ($(feature-glibc), 1)
LIBC_SUPPORT := 1
@@ -320,12 +315,9 @@ else
endif
ifeq ($(LIBC_SUPPORT),1)
msg := $(warning No libelf found, disables 'probe' tool, please install
elfutils-libelf-devel/libelf-dev);
-
- NO_LIBELF := 1
- NO_DWARF := 1
- NO_DEMANGLE := 1
- NO_LIBUNWIND := 1
- NO_LIBDW_DWARF_UNWIND := 1
+ $(shell $(KCONFIG_SCRIPT) -d CONFIG_LIBELF)
+ $(shell $(KCONFIG_SCRIPT) -e CONFIG_LIBELF_MINIMAL)
+ EXTLIBS := $(filter-out -lelf,$(EXTLIBS))
else
ifneq ($(filter s% -static%,$(LDFLAGS),),)
msg := $(error No static glibc found, please install glibc-static);
@@ -334,6 +326,7 @@ else
endif
endif
else
+LIBELF = 1
ifndef NO_LIBDW_DWARF_UNWIND
ifneq ($(feature-libdw-dwarf-unwind),1)
NO_LIBDW_DWARF_UNWIND := 1
@@ -345,17 +338,20 @@ else
NO_DWARF := 1
endif # Dwarf support
endif # libelf support
-endif # NO_LIBELF
+endif # CONFIG_LIBELF
-ifndef NO_LIBELF
- CFLAGS += -DHAVE_LIBELF_SUPPORT
+ifeq ($(LIBELF), 1)
- ifeq ($(feature-libelf-mmap), 1)
-CFLAGS += -DHAVE_LIBELF_MMAP_SUPPORT
+ ifdef CONFIG_LIBELF_MMAP
+ifneq ($(feature-libelf-mmap), 1)
+ $(shell $(KCONFIG_SCRIPT) -d CONFIG_LIBELF_MMAP)
+endif
endif
- ifeq ($(feature-libelf-getphdrnum), 1)
-CFLAGS += -DHAVE_ELF_GETPHDRNUM_SUPPORT
+ ifdef CONFIG_LIBELF_MMAP
+ifneq ($(feature-libelf-getphdrnum), 1)
+ $(shell $(KCONFIG_SCRIPT) -d CONFIG_LIBELF_MMAP)
+endif
endif
# include ARCH specific config
@@ -371,7 +367,7 @@ ifndef NO_LIBELF
EXTLIBS += -lelf -ldw
endif # PERF_HAVE_DWARF_REGS
endif # NO_DWARF
-endif # NO_LIBELF
+endif # LIBELF
ifeq ($(ARCH),powerpc)
ifndef NO_DWARF
@@ -814,7 +810,6 @@ all:
$(call store,NO_LIBUNWIND)
$(call store,NO_LIBPERL)
$(call store,NO_LIBPYTHON)
- $(call store,NO_LIBELF)
$(call store,NO_LIBUNWIND)
$(call store,NO_LIBBIONIC)
$(call store,ETC_PERFCONFIG_SQ)
diff --git a/tools/perf/config/Makefile.fix-config
[PATCH v4 12/14] perf kbuild: remove legacy script-related build variables
Remove NO_LIBPERL (replaced by CONFIG_LIBPERL)
Remove NO_LIBPYTHON (replaced by CONFIG_LIBPYTHON)
Signed-off-by: Alexis Berlemont
---
tools/perf/builtin-script.c | 6 +++--
tools/perf/config/Makefile | 41 +
tools/perf/config/Makefile.fix-config | 16 -
tools/perf/config/Makefile.fix-legacy | 8 ---
tools/perf/util/trace-event-scripting.c | 13 ++-
5 files changed, 22 insertions(+), 62 deletions(-)
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index ce304df..2d077c1 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -1,3 +1,5 @@
+#include "generated/autoconf.h"
+
#include "builtin.h"
#include "perf.h"
@@ -1370,11 +1372,11 @@ int find_scripts(char **scripts_array, char
**scripts_path_array)
for_each_lang(scripts_path, scripts_dir, lang_dirent, lang_next) {
snprintf(lang_path, MAXPATHLEN, "%s/%s", scripts_path,
lang_dirent.d_name);
-#ifdef NO_LIBPERL
+#ifndef CONFIG_LIBPERL
if (strstr(lang_path, "perl"))
continue;
#endif
-#ifdef NO_LIBPYTHON
+#ifndef CONFIG_LIBPYTHON
if (strstr(lang_path, "python"))
continue;
#endif
diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index fe375da..b628fa9 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -101,7 +101,7 @@ ifdef PARSER_DEBUG
CFLAGS += -DPARSER_DEBUG
endif
-ifndef NO_LIBPYTHON
+ifdef CONFIG_LIBPYTHON
# Try different combinations to accommodate systems that only have
# python[2][-config] in weird combinations but always preferring
# python2 and python2-config as per pep-0394. If we catch a
@@ -462,9 +462,7 @@ endif
grep-libs = $(filter -l%,$(1))
strip-libs = $(filter-out -l%,$(1))
-ifdef NO_LIBPERL
- CFLAGS += -DNO_LIBPERL
-else
+ifdef CONFIG_LIBPERL
PERL_EMBED_LDOPTS = $(shell perl -MExtUtils::Embed -e ldopts 2>/dev/null)
PERL_EMBED_LDFLAGS = $(call strip-libs,$(PERL_EMBED_LDOPTS))
PERL_EMBED_LIBADD = $(call grep-libs,$(PERL_EMBED_LDOPTS))
@@ -472,9 +470,8 @@ else
FLAGS_PERL_EMBED=$(PERL_EMBED_CCOPTS) $(PERL_EMBED_LDOPTS)
ifneq ($(feature-libperl), 1)
-CFLAGS += -DNO_LIBPERL
-NO_LIBPERL := 1
msg := $(warning Missing perl devel files. Disabling perl scripting
support, consider installing perl-ExtUtils-Embed);
+$(shell $(KCONFIG_SCRIPT) -d CONFIG_LIBPERL)
else
LDFLAGS += $(PERL_EMBED_LDFLAGS)
EXTLIBS += $(PERL_EMBED_LIBADD)
@@ -488,17 +485,14 @@ ifdef CONFIG_TIMERFD
endif
endif
-disable-python = $(eval $(disable-python_code))
-define disable-python_code
- CFLAGS += -DNO_LIBPYTHON
- $(if $(1),$(warning No $(1) was found))
- $(warning Python support will not be built)
- NO_LIBPYTHON := 1
-endef
+ifdef CONFIG_LIBPYTHON
-ifdef NO_LIBPYTHON
- $(call disable-python)
-else
+ disable-python = $(eval $(disable-python_code))
+ define disable-python_code
+$(if $(1),$(warning No $(1) was found))
+$(warning Python support will not be built)
+$(shell $(KCONFIG_SCRIPT) -d CONFIG_LIBPYTHON)
+ endef
ifndef PYTHON
$(call disable-python,python interpreter)
@@ -522,18 +516,7 @@ else
else
ifneq ($(feature-libpython-version), 1)
- $(warning Python 3 is not yet supported; please set)
- $(warning PYTHON and/or PYTHON_CONFIG appropriately.)
- $(warning If you also have Python 2 installed, then)
- $(warning try something like:)
- $(warning $(and ,))
- $(warning $(and ,) make PYTHON=python2)
- $(warning $(and ,))
- $(warning Otherwise, disable Python support entirely:)
- $(warning $(and ,))
- $(warning $(and ,) make NO_LIBPYTHON=1)
- $(warning $(and ,))
- $(error $(and ,))
+ $(call disable-python,python2 interpreter)
else
LDFLAGS += $(PYTHON_EMBED_LDFLAGS)
EXTLIBS += $(PYTHON_EMBED_LIBADD)
@@ -808,8 +791,6 @@ all:
$(call store,PYTHON_EMBED_CCOPTS)
$(call store,PERL_EMBED_CCOPTS)
$(call store,NO_LIBUNWIND)
- $(call store,NO_LIBPERL)
- $(call store,NO_LIBPYTHON)
$(call store,ETC_PERFCONFIG_SQ)
$(call store,DESTDIR_SQ)
$(call store,bindir_SQ)
diff --git a/tools/perf/config/Makefile.fix-config
b/tools/perf/config/Makefile.fix-config
index e63539f..3f0e33e 100644
--- a/tools/perf/config/Makefile.fix-config
+++ b/tools/perf/config/Makefile.fix-config
@@ -3,20 +3,4 @@ include $(KCONFIG_CONFIG)
CONFIG := $(srctree)/scripts/config --file $(KCONFIG_CONFIG)
-# NO_LIBPERL
-ifdef CONFIG_LIBPERL
-ifdef NO_LIBPERL
-dummy := $(info Disabling CONFIG_LIBPERL)
-dummy := $(shell $(CONFIG) -d CONFIG_LIBPERL)
-endif
-endif
-
-# NO_LIBPYTHON
-ifdef CONFIG_LIBPYTHON
-ifdef NO_LIBPYTHON
-dummy := $(info Disabling CONFIG_LIBPYTHON)
-dummy := $(shell
[PATCH v4 07/14] perf kbuild: remove legacy demangle-related build variables
Remove NO_DEMANGLE (replaced by CONFIG_DEMANGLE) Remove HAVE_LIBBFD_SUPPORT (replaced by CONFIG_LIBBFD) Remove HAVE_CPLUS_DEMANGLE_SUPPORT (replaced by CONFIG_LIBIBERTY_ONLY) Signed-off-by: Alexis Berlemont --- tools/perf/Kconfig| 36 +-- tools/perf/config/Makefile| 46 ++- tools/perf/config/Makefile.fix-legacy | 4 --- tools/perf/util/srcline.c | 8 +++--- tools/perf/util/symbol.h | 25 +-- 5 files changed, 75 insertions(+), 44 deletions(-) diff --git a/tools/perf/Kconfig b/tools/perf/Kconfig index eb59567..026ef67 100644 --- a/tools/perf/Kconfig +++ b/tools/perf/Kconfig @@ -225,6 +225,35 @@ config LIBPYTHON ---help--- Libpython dependency needed by the perf script feature. +config TIMERFD + bool "Timer via file descriptor" + default y +---help--- + Timer via file descriptor + +config DEMANGLE + bool "Demangle symbols" + default y +---help--- + Enable demangling so as to display human-readable + symbols. This option is convenient with C++ programs. + +choice DEMANGLE_DEPS + prompt "Demangle dependency(ies)" + depends on DEMANGLE + default LIBBFD + +config LIBBFD + bool "BFD + libiberty libraries" +---help--- + Binary File Descriptor and libiberty libraries + +config LIBIBERTY_ONLY + bool "Libiberty only" +---help--- + Libiberty +endchoice + choice prompt "Elf library" default LIBELF @@ -266,13 +295,6 @@ config NUMA The library libnuma offers facilities to configure NUMA policies supported by the linux kernel. -config DEMANGLE - bool "Demangle symbols" - default y ----help--- - Enable demangling so as to display human-readable - symbols. This option is convenient with C++ programs. - config BIONIC bool "Bionic support" default n diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile index e41c9de..0e36bbe 100644 --- a/tools/perf/config/Makefile +++ b/tools/perf/config/Makefile @@ -575,33 +575,36 @@ ifeq ($(feature-libbfd), 1) endif endif -ifdef NO_DEMANGLE - CFLAGS += -DNO_DEMANGLE -else - ifdef HAVE_CPLUS_DEMANGLE_SUPPORT -EXTLIBS += -liberty -CFLAGS += -DHAVE_CPLUS_DEMANGLE_SUPPORT - else -ifneq ($(feature-libbfd), 1) - ifneq ($(feature-liberty), 1) -ifneq ($(feature-liberty-z), 1) - # we dont have neither HAVE_CPLUS_DEMANGLE_SUPPORT - # or any of 'bfd iberty z' trinity - ifeq ($(feature-cplus-demangle), 1) -EXTLIBS += -liberty -CFLAGS += -DHAVE_CPLUS_DEMANGLE_SUPPORT - else -msg := $(warning No bfd.h/libbfd found, install binutils-dev[el]/zlib-static to gain symbol demangling) -CFLAGS += -DNO_DEMANGLE - endif +ifdef CONFIG_LIBBFD + ifneq ($(feature-libbfd), 1) +# TODO: there might be an issue here: feature-liberty and +# feature-liberty-z cannot be set; they can be set only if +# feature-libbfd is set +ifneq ($(feature-liberty), 1) + ifneq ($(feature-liberty-z), 1) +# we dont have neither HAVE_CPLUS_DEMANGLE_SUPPORT +# or any of 'bfd iberty z' trinity +ifeq ($(feature-cplus-demangle), 1) + EXTLIBS += -liberty + $(shell $(KCONFIG_SCRIPT) -d CONFIG_LIBBFD) + $(shell $(KCONFIG_SCRIPT) -e CONFIG_LIBIBERTY_ONLY) +else + msg := $(warning No bfd.h/libbfd found, install binutils-dev[el]/zlib-static to gain symbol demangling) + $(shell $(KCONFIG_SCRIPT) -d CONFIG_DEMANGLE) endif endif endif endif endif -ifneq ($(filter -lbfd,$(EXTLIBS)),) - CFLAGS += -DHAVE_LIBBFD_SUPPORT +ifdef CONFIG_LIBIBERTY_ONLY + $(call feature_check,cplus-demangle) + ifeq ($(feature-cplus-demangle), 1) +EXTLIBS += -liberty + else +msg := $(warning No libiberty found, install binutils-dev[el]/zlib-static to gain symbol demangling) +$(shell $(KCONFIG_SCRIPT) -d CONFIG_DEMANGLE) + endif endif ifndef NO_BACKTRACE @@ -822,7 +825,6 @@ all: $(call store,NO_LIBUNWIND) $(call store,NO_LIBPERL) $(call store,NO_LIBPYTHON) - $(call store,NO_DEMANGLE) $(call store,NO_LIBELF) $(call store,NO_LIBUNWIND) $(call store,NO_BACKTRACE) diff --git a/tools/perf/config/Makefile.fix-legacy b/tools/perf/config/Makefile.fix-legacy index ca219e7..64dbb1a 100644 --- a/tools/perf/config/Makefile.fix-legacy +++ b/tools/perf/config/Makefile.fix-legacy @@ -9,10 +9,6 @@ ifndef CONFIG_LIBPYTHON NO_LIBPYTHON := 1 endif -ifndef CONFIG_DEMANGLE -NO_DEMANGLE := 1 -endif - ifndef CONFIG_LIBELF NO_LIBELF := 1 endif diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c index f3e4bc5..38df8f4 100644 --- a/tools/perf/util/srcline.c +++
[PATCH v4 09/14] perf kbuild: remove legacy misc build variables
Remove NO_LIBAUDIT (replaced by CONFIG_LIBAUDIT)
Remove HAVE_LIBAUDIT_SUPPORT from CFLAGS (replaced by CONFIG_LIBAUDIT)
Remove HAVE_TIMERFD_SUPPORT (replaced by CONFIG_TIMERFD)
Remove HAVE_ON_EXIT_SUPPORT (replaced by CONFIG_ON_EXIT)
Remove HAVE_BACKTRACE_SUPPORT (replaced by CONFIG_BACKTRACE)
Remove HAVE_LIBNUMA_SUPPORT (replaced by CONFIG_LIBNUMA)
Remove NO_BIONIC (replaced by CONFIG_BIONIC)
Remove NO_PERF_REGS (replaced by CONFIG_PERF_REGS)
Signed-off-by: Alexis Berlemont
---
tools/perf/Kconfig| 12 --
tools/perf/arch/arm/tests/Kbuild | 2 +-
tools/perf/arch/x86/tests/Kbuild | 2 +-
tools/perf/bench/Kbuild | 2 +-
tools/perf/builtin-bench.c| 5 ++--
tools/perf/builtin-kvm.c | 13 ++-
tools/perf/builtin-record.c | 2 ++
tools/perf/config/Makefile| 43 +--
tools/perf/config/Makefile.fix-config | 32 --
tools/perf/config/Makefile.fix-legacy | 16 -
tools/perf/util/perf_regs.c | 3 +++
tools/perf/util/perf_regs.h | 6 +++--
tools/perf/util/util.c| 5 ++--
13 files changed, 51 insertions(+), 92 deletions(-)
diff --git a/tools/perf/Kconfig b/tools/perf/Kconfig
index 5f85923..29853a6 100644
--- a/tools/perf/Kconfig
+++ b/tools/perf/Kconfig
@@ -312,8 +312,8 @@ config LIBUNWIND_DIR
Directory holding the libuwind dependency (headers +
libraries).
-config NUMA
- bool "Numa support (bench)"
+config LIBNUMA
+ bool "Libnuma support"
default y
---help---
The library libnuma offers facilities to configure NUMA
@@ -327,6 +327,14 @@ config BIONIC
library code developed by Google for their Android operating
system.
+config PERF_REGS
+ bool "Cache register accesses"
+ depends on (ARCH = "x86" || ARCH = "arm" || ARCH = "arm64")
+ default y
+---help---
+ Cache register accesses for unwind processing to speed-up
+ performances.
+
endmenu
menu "Build"
diff --git a/tools/perf/arch/arm/tests/Kbuild b/tools/perf/arch/arm/tests/Kbuild
index 5d63e9d..1318ed0 100644
--- a/tools/perf/arch/arm/tests/Kbuild
+++ b/tools/perf/arch/arm/tests/Kbuild
@@ -1,2 +1,2 @@
-obj-y += regs_load.o
+obj-$(CONFIG_PERF_REGS) += regs_load.o
obj-y += dwarf-unwind.o
diff --git a/tools/perf/arch/x86/tests/Kbuild b/tools/perf/arch/x86/tests/Kbuild
index 3b5aa14..8287dae 100644
--- a/tools/perf/arch/x86/tests/Kbuild
+++ b/tools/perf/arch/x86/tests/Kbuild
@@ -1,3 +1,3 @@
obj-y += perf-time-to-tsc.o
-obj-y += regs_load.o
+obj-$(CONFIG_PERF_REGS) += regs_load.o
obj-y += dwarf-unwind.o
diff --git a/tools/perf/bench/Kbuild b/tools/perf/bench/Kbuild
index e604fe2..863646a 100644
--- a/tools/perf/bench/Kbuild
+++ b/tools/perf/bench/Kbuild
@@ -6,7 +6,7 @@ obj-y += futex-hash.o
obj-y += futex-requeue.o
obj-y += futex-wake.o
-obj-$(CONFIG_NUMA) += numa.o
+obj-$(CONFIG_LIBNUMA) += numa.o
obj-$(CONFIG_X86_64) += mem-memcpy-x86-64-asm.o
obj-$(CONFIG_X86_64) += mem-memset-x86-64-asm.o
diff --git a/tools/perf/builtin-bench.c b/tools/perf/builtin-bench.c
index b9a56fa..5116d25 100644
--- a/tools/perf/builtin-bench.c
+++ b/tools/perf/builtin-bench.c
@@ -14,6 +14,7 @@
* numa ... NUMA scheduling and MM performance
* futex ... Futex performance
*/
+#include "generated/autoconf.h"
#include "perf.h"
#include "util/util.h"
#include "util/parse-options.h"
@@ -33,7 +34,7 @@ struct bench {
bench_fn_t fn;
};
-#ifdef HAVE_LIBNUMA_SUPPORT
+#ifdef CONFIG_LIBNUMA
static struct bench numa_benchmarks[] = {
{ "mem","Benchmark for NUMA workloads",
bench_numa },
{ "all","Test all NUMA benchmarks", NULL
},
@@ -72,7 +73,7 @@ struct collection {
static struct collection collections[] = {
{ "sched", "Scheduler and IPC benchmarks",
sched_benchmarks},
{ "mem","Memory access benchmarks",
mem_benchmarks },
-#ifdef HAVE_LIBNUMA_SUPPORT
+#ifdef CONFIG_LIBNUMA
{ "numa", "NUMA scheduling and MM benchmarks",
numa_benchmarks },
#endif
{"futex", "Futex stressing benchmarks",
futex_benchmarks},
diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
index e042728..19a1d17 100644
--- a/tools/perf/builtin-kvm.c
+++ b/tools/perf/builtin-kvm.c
@@ -1,3 +1,4 @@
+#include "generated/autoconf.h"
#include "builtin.h"
#include "perf.h"
@@ -20,7 +21,7 @@
#include "util/data.h"
#include
-#ifdef HAVE_TIMERFD_SUPPORT
+#ifdef CONFIG_TIMERFD
#include
#endif
@@ -123,7 +124,7 @@ static void init_kvm_event_record(struct perf_kvm_stat *kvm)
INIT_LIST_HEAD(>kvm_events_cache[i]);
}
-#ifdef HAVE_TIMERFD_SUPPORT
+#ifdef CONFIG_TIMERFD
static void
[PATCH v4 11/14] perf kbuild: remove legacy libdwarf-related build variables
* Remove NO_DWARF (replaced by CONFIG_LIBDWARF) * Remove HAVE_DWARF_SUPPORT (replaced by CONFIG_LIBDWARF) * Remove the useless variable PERF_HAVE_DWARF_REGS * fix compilation issues if PERF_REGS is disabled Signed-off-by: Alexis Berlemont --- tools/perf/Kconfig | 59 +- tools/perf/arch/arm/tests/Kbuild | 2 +- tools/perf/arch/arm/util/Kbuild | 4 +- tools/perf/arch/arm64/util/Kbuild| 2 +- tools/perf/arch/powerpc/util/Kbuild | 4 +- tools/perf/arch/s390/util/Kbuild | 2 +- tools/perf/arch/sh/util/Kbuild | 2 +- tools/perf/arch/sparc/util/Kbuild| 2 +- tools/perf/arch/x86/Kbuild | 1 + tools/perf/arch/x86/Makefile | 8 +- tools/perf/arch/x86/tests/Kbuild | 2 +- tools/perf/arch/x86/tests/perf-time-to-tsc.c | 2 +- tools/perf/arch/x86/util/Kbuild | 3 +- tools/perf/builtin-probe.c | 15 +-- tools/perf/builtin-record.c | 2 +- tools/perf/config/Makefile | 170 +-- tools/perf/config/Makefile.fix-config| 8 -- tools/perf/config/Makefile.fix-legacy| 4 - tools/perf/tests/Kbuild | 2 + tools/perf/tests/builtin-test.c | 3 +- tools/perf/tests/tests.h | 6 +- tools/perf/util/Kbuild | 11 +- tools/perf/util/callchain.c | 11 +- tools/perf/util/callchain.h | 3 +- tools/perf/util/include/dwarf-regs.h | 4 +- tools/perf/util/machine.c| 3 +- tools/perf/util/perf_regs.c | 2 - tools/perf/util/probe-event.c| 6 +- tools/perf/util/probe-finder.h | 5 +- tools/perf/util/unwind-libunwind.c | 5 +- tools/perf/util/unwind.h | 7 +- 31 files changed, 203 insertions(+), 157 deletions(-) diff --git a/tools/perf/Kconfig b/tools/perf/Kconfig index 2eaf3ca..54a194d 100644 --- a/tools/perf/Kconfig +++ b/tools/perf/Kconfig @@ -287,7 +287,6 @@ choice these tasks, perf can rely on either the libelf library or a minimal builtin support. - config LIBELF bool "elf" ---help--- @@ -318,15 +317,51 @@ config LIBDWARF bool "Dwarf (libdwarf)" default y ---help--- - libdwarf + A library for parsing DWARF debug information. + +config LIBDWARF_DIR + string "libdwarf directory" + depends on LIBDWARF +---help--- + Directory holding the libdwarf dependency (headers + + libraries) + +config UNWIND +depends on (LIBELF && PERF_REGS) + bool "User space unwind callchains" + default y +---help--- + Enable call-chain unwinding of user-space application. + +choice UNWIND_DEPS + prompt "Unwind dependency" + depends on UNWIND + default LIBUNWIND config LIBUNWIND -depends on LIBELF - bool "User space libunwind callchains" +depends on (LIBELF && PERF_REGS) + bool "Libunwind" +---help--- + Rely on libunwind post unwind support to determine the + call-chain of a user-space program. The library libunwind + supports all the architectures. + +config LIBDWARF_UNWIND +depends on (LIBDWARF && PERF_REGS && (ARCH = "x86" || ARCH = "arm")) + bool "Libdwarf unwind" +---help--- + Rely on lidw DWARF post unwind support to determine the + call-chain of a user-space program. So far there's only x86 + and arm libdw unwind support merged in perf. + +endchoice + +config LIBUNWIND_DEBUG_FRAME +depends on LIBUNWIND + bool "libunwind debug frame" default y ---help--- - The library libunwind provides a portable C API to determine - the call-chain of a program. + libunwind debug frame config LIBUNWIND_DIR string "libunwind directory" @@ -335,6 +370,18 @@ config LIBUNWIND_DIR Directory holding the libuwind dependency (headers + libraries). +config SKIP_CALLCHAIN_IDX + depends on (LIBDWARF && ARCH = "powerpc") + bool "Skip unnecessary callchain entries thanks to Dwarf" + default y +---help--- + When saving the callchain on Power, the kernel + conservatively saves excess entries in the callchain. A few + of these entries are needed in some cases but not others. If + the unnecessary entries are not ignored, we end up with + duplicate arcs in the call-graphs. Use DWARF debug + information to skip over any unnecessary callchain entries. + config LIBNUMA bool "Libnuma support" default y diff --git a/tools/perf/arch/arm/tests/Kbuild b/tools/perf/arch/arm/tests/Kbuild index 1318ed0..f1d8426 100644 ---
[PATCH v4 14/14] perf kbuild: add generated Kconfig build-test cases
Thanks to the python module kconfiglib, we were able to generate build configurations. The set is, of course, not exhaustive but for each option, all the possible states are tested. If, during development step, a new symbol is added into the Kconfig file, the target build-test will not fail (olddefconfig is called so that new parameters are filled with their default value). Signed-off-by: Alexis Berlemont --- Changes since v3: * Target build-test: for each .config-based test case, call "make olddefconfig" so as to prevent failure because of new Kconfig symbol(s) tools/perf/MANIFEST| 1 + tools/perf/tests/configs/MINIMAL_config| 60 ++ tools/perf/tests/configs/NO_BACKTRACE_config | 73 ++ .../perf/tests/configs/NO_BUILTIN_ANNOTATE_config | 73 ++ tools/perf/tests/configs/NO_BUILTIN_BENCH_config | 73 ++ .../tests/configs/NO_BUILTIN_BUILDID_CACHE_config | 73 ++ .../tests/configs/NO_BUILTIN_BUILDID_LIST_config | 71 + tools/perf/tests/configs/NO_BUILTIN_DIFF_config| 71 + tools/perf/tests/configs/NO_BUILTIN_EVLIST_config | 73 ++ tools/perf/tests/configs/NO_BUILTIN_HELP_config| 73 ++ tools/perf/tests/configs/NO_BUILTIN_INJECT_config | 73 ++ tools/perf/tests/configs/NO_BUILTIN_KMEM_config| 73 ++ .../perf/tests/configs/NO_BUILTIN_KVM_STAT_config | 73 ++ tools/perf/tests/configs/NO_BUILTIN_KVM_config | 72 + tools/perf/tests/configs/NO_BUILTIN_LIST_config| 73 ++ tools/perf/tests/configs/NO_BUILTIN_LOCK_config| 73 ++ tools/perf/tests/configs/NO_BUILTIN_MEM_config | 73 ++ tools/perf/tests/configs/NO_BUILTIN_PROBE_config | 73 ++ tools/perf/tests/configs/NO_BUILTIN_RECORD_config | 63 +++ tools/perf/tests/configs/NO_BUILTIN_REPORT_config | 68 tools/perf/tests/configs/NO_BUILTIN_SCHED_config | 73 ++ tools/perf/tests/configs/NO_BUILTIN_SCRIPT_config | 73 ++ tools/perf/tests/configs/NO_BUILTIN_STAT_config| 71 + tools/perf/tests/configs/NO_BUILTIN_TEST_config| 73 ++ .../perf/tests/configs/NO_BUILTIN_TIMECHART_config | 73 ++ tools/perf/tests/configs/NO_BUILTIN_TOP_config | 71 + tools/perf/tests/configs/NO_BUILTIN_TRACE_config | 73 ++ tools/perf/tests/configs/NO_DEMANGLE_config| 71 + tools/perf/tests/configs/NO_GTK2_config| 73 ++ tools/perf/tests/configs/NO_LIBAUDIT_config| 72 + tools/perf/tests/configs/NO_LIBDWARF_config| 71 + tools/perf/tests/configs/NO_LIBELF_MMAP_config | 73 ++ tools/perf/tests/configs/NO_LIBGTK2_INFOBAR_config | 73 ++ tools/perf/tests/configs/NO_LIBGTK2_config | 71 + tools/perf/tests/configs/NO_LIBNUMA_config | 73 ++ tools/perf/tests/configs/NO_LIBPERL_config | 73 ++ tools/perf/tests/configs/NO_LIBPYTHON_config | 73 ++ tools/perf/tests/configs/NO_LIBSLANG_config| 72 + .../tests/configs/NO_LIBUNWIND_DEBUG_FRAME_config | 73 ++ tools/perf/tests/configs/NO_PERF_REGS_config | 73 ++ tools/perf/tests/configs/NO_STDIO_config | 73 ++ tools/perf/tests/configs/NO_TIMERFD_config | 73 ++ tools/perf/tests/configs/NO_TUI_config | 73 ++ tools/perf/tests/configs/NO_UNWIND_config | 69 tools/perf/tests/configs/REF_config| 73 ++ tools/perf/tests/generate_configs.py | 43 + tools/perf/tests/make | 70 ++--- 47 files changed, 3227 insertions(+), 50 deletions(-) create mode 100644 tools/perf/tests/configs/MINIMAL_config create mode 100644 tools/perf/tests/configs/NO_BACKTRACE_config create mode 100644 tools/perf/tests/configs/NO_BUILTIN_ANNOTATE_config create mode 100644 tools/perf/tests/configs/NO_BUILTIN_BENCH_config create mode 100644 tools/perf/tests/configs/NO_BUILTIN_BUILDID_CACHE_config create mode 100644 tools/perf/tests/configs/NO_BUILTIN_BUILDID_LIST_config create mode 100644 tools/perf/tests/configs/NO_BUILTIN_DIFF_config create mode 100644 tools/perf/tests/configs/NO_BUILTIN_EVLIST_config create mode 100644 tools/perf/tests/configs/NO_BUILTIN_HELP_config create mode 100644
[PATCH v4 04/14] perf tools: Add kbuild support into Makefile.kbuild
From: Jiri Olsa
Adding kbuild support into Makefile.kbuild. The 'legacy'
Makefile still stays untouched as it was.
It's possible to use kbuild by running 'make -f Makefile.kbuild'
with any option supported by 'legacy' Makefile.
We now have 2 config files:
'.config' - user configured setup
'.config-detected' - system detected setup
The '.config-detected' affects '.config' and if there's
configured feature in '.config' which was not detected
it is automatically disabled.
The '.config-detected' is re/created if:
- there's no '.config-detected'
- '.config' was changed
In a cleaned tree the perf is built with 'allyesconfig'
having disabled all non-detected features, just as it is
done now.
You can change '.config' via:
make -f Makefile.kbuild menuconfig
There's difference for O=DIR build. The DIR is populated
based on kernel source tree, so the final binary is created
under DIR/tools/perf.
This commit was originally created by Jiri Olsa in February 2013; a
few changes were necessary to fit the perf version of June 2014:
* Add missing CFLAGS for specific .o targets
* Update Kbuild files (new source files, ...)
* Fix recursive invocation of config/features-checks
* Store .config-detected missing variables (libdir, ...)
* Fix missing dependencies between Kconfig options
* Fix installation of traceevent plugins
* Fix missing cleanings of feature-check binaries
* CROSS_COMPILE was not used to define AS, CC, ...
* CROSS_COMPILE was not stored in .config-detected
* Take into account DESTDIR and prefix set in the command line
* Add missing Kbuild files for non-x86 architectures
(powerpc, arm, arm64, sh, s390, sparc)
* Move perf-time-to-tsc.c into x86-specific tests directory
Signed-off-by: Jiri Olsa
Cc: Arnaldo Carvalho de Melo
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Paul Mackerras
Cc: Corey Ashford
Cc: Frederic Weisbecker
Cc: Namhyung Kim
Cc: Borislav Petkov
Cc: Michal Marek
Cc: linux-kbu...@vger.kernel.org
Cc: Stephane Eranian
Signed-off-by: Alexis Berlemont
---
tools/perf/Kbuild | 47 +++
tools/perf/Kconfig | 284 ++
tools/perf/Makefile.kbuild | 431 +
tools/perf/Makefile.perf | 2 +-
tools/perf/arch/Kbuild | 3 +
tools/perf/arch/arm/Kbuild | 2 +
tools/perf/arch/arm/Makefile | 14 -
tools/perf/arch/arm/tests/Kbuild | 2 +
tools/perf/arch/arm/util/Kbuild| 3 +
tools/perf/arch/arm64/Kbuild | 1 +
tools/perf/arch/arm64/Makefile | 7 -
tools/perf/arch/arm64/util/Kbuild | 2 +
tools/perf/arch/powerpc/Kbuild | 1 +
tools/perf/arch/powerpc/Makefile | 6 -
tools/perf/arch/powerpc/util/Kbuild| 3 +
tools/perf/arch/s390/Kbuild| 1 +
tools/perf/arch/s390/Makefile | 7 -
tools/perf/arch/s390/util/Kbuild | 2 +
tools/perf/arch/sh/Kbuild | 1 +
tools/perf/arch/sh/Makefile| 4 -
tools/perf/arch/sh/util/Kbuild | 1 +
tools/perf/arch/sparc/Kbuild | 1 +
tools/perf/arch/sparc/Makefile | 4 -
tools/perf/arch/sparc/util/Kbuild | 1 +
tools/perf/arch/x86/Kbuild | 1 +
tools/perf/arch/x86/tests/Kbuild | 3 +
tools/perf/{ => arch/x86}/tests/perf-time-to-tsc.c | 0
tools/perf/arch/x86/util/Kbuild| 5 +
tools/perf/bench/Kbuild| 12 +
tools/perf/builtin-cmds.h | 4 +
tools/perf/config/Makefile | 55 ++-
tools/perf/config/Makefile.fix-config | 104 +
tools/perf/config/Makefile.fix-legacy | 46 +++
tools/perf/config/defconfig| 54 +++
tools/perf/perf-sys.h | 4 +-
tools/perf/scripts/perl/Perf-Trace-Util/Kbuild | 6 +
tools/perf/scripts/python/Perf-Trace-Util/Kbuild | 5 +
tools/perf/tests/Kbuild| 38 ++
tools/perf/ui/Kbuild | 15 +
tools/perf/ui/browsers/Kbuild | 9 +
tools/perf/ui/gtk/Kbuild | 9 +
tools/perf/ui/stdio/Kbuild | 1 +
tools/perf/ui/tui/Kbuild | 4 +
tools/perf/util/Kbuild | 126 ++
tools/perf/util/PERF-VERSION-GEN | 4 +
tools/perf/util/generate-cmdlist.sh| 8 +-
tools/perf/util/scripting-engines/Kbuild | 11 +
tools/perf/util/setup.py | 8 +-
48 files changed, 1310 insertions(+), 52
[PATCH v4 02/14] perf tools: Kbuild builtin source related fixies
From: Jiri Olsa
Adding CONFIG_BUILTIN_* defines to govern builtin commands.
This will be useful for kbuild process switch.
Signed-off-by: Jiri Olsa
Cc: Arnaldo Carvalho de Melo
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Paul Mackerras
Cc: Corey Ashford
Cc: Frederic Weisbecker
Cc: Namhyung Kim
Cc: Borislav Petkov
Cc: Michal Marek
Cc: linux-kbu...@vger.kernel.org
Cc: Stephane Eranian
Signed-off-by: Alexis Berlemont
---
tools/perf/builtin-annotate.c | 8 ++-
tools/perf/builtin-cmds.h | 27 ++
tools/perf/builtin-help.c | 1 +
tools/perf/builtin-kvm.c| 19 ++--
tools/perf/builtin-report.c | 3 +++
tools/perf/builtin-top.c| 19
tools/perf/perf.c | 45 +++--
tools/perf/ui/setup.c | 6 +++--
tools/perf/util/generate-cmdlist.sh | 10 +
9 files changed, 122 insertions(+), 16 deletions(-)
create mode 100644 tools/perf/builtin-cmds.h
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index e7417fe..19cb967 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -5,6 +5,7 @@
* look up and read DSOs and symbol information and display
* a histogram of results, along various sorting keys.
*/
+#include "generated/autoconf.h"
#include "builtin.h"
#include "util/util.h"
@@ -115,7 +116,7 @@ static void hists__find_annotations(struct hists *hists,
struct perf_evsel *evsel,
struct perf_annotate *ann)
{
- struct rb_node *nd = rb_first(>entries), *next;
+ struct rb_node *nd = rb_first(>entries);
int key = K_RIGHT;
while (nd) {
@@ -154,7 +155,9 @@ find_next:
/* skip missing symbols */
nd = rb_next(nd);
+#ifdef CONFIG_TUI
} else if (use_browser == 1) {
+ struct rb_node *next = NULL;
key = hist_entry__tui_annotate(he, evsel, NULL);
switch (key) {
case -1:
@@ -173,6 +176,7 @@ find_next:
if (next != NULL)
nd = next;
+#endif /* CONFIG_TUI */
} else {
hist_entry__tty_annotate(he, evsel, ann);
nd = rb_next(nd);
@@ -299,7 +303,9 @@ int cmd_annotate(int argc, const char **argv, const char
*prefix __maybe_unused)
OPT_BOOLEAN('D', "dump-raw-trace", _trace,
"dump raw trace in ASCII"),
OPT_BOOLEAN(0, "gtk", _gtk, "Use the GTK interface"),
+#ifdef CONFIG_TUI
OPT_BOOLEAN(0, "tui", _tui, "Use the TUI interface"),
+#endif /* CONFIG_TUI */
OPT_BOOLEAN(0, "stdio", _stdio, "Use the stdio interface"),
OPT_STRING('k', "vmlinux", _conf.vmlinux_name,
"file", "vmlinux pathname"),
diff --git a/tools/perf/builtin-cmds.h b/tools/perf/builtin-cmds.h
new file mode 100644
index 000..fec342a
--- /dev/null
+++ b/tools/perf/builtin-cmds.h
@@ -0,0 +1,27 @@
+#ifndef BUILTIN_CMDS_H
+#define BUILTIN_CMDS_H
+
+#define CONFIG_BUILTIN_REPORT 1
+#define CONFIG_BUILTIN_SCRIPT 1
+#define CONFIG_BUILTIN_BENCH 1
+#define CONFIG_BUILTIN_SCHED 1
+#define CONFIG_BUILTIN_TRACE 1
+#define CONFIG_BUILTIN_TOP 1
+#define CONFIG_BUILTIN_RECORD 1
+#define CONFIG_BUILTIN_BUILDID_LIST 1
+#define CONFIG_BUILTIN_INJECT 1
+#define CONFIG_BUILTIN_LOCK 1
+#define CONFIG_BUILTIN_KVM 1
+#define CONFIG_BUILTIN_BUILDID_CACHE 1
+#define CONFIG_BUILTIN_EVLIST 1
+#define CONFIG_BUILTIN_KMEM 1
+#define CONFIG_BUILTIN_STAT 1
+#define CONFIG_BUILTIN_DIFF 1
+#define CONFIG_BUILTIN_ANNOTATE 1
+#define CONFIG_BUILTIN_TIMECHART 1
+#define CONFIG_BUILTIN_LIST 1
+#define CONFIG_BUILTIN_HELP 1
+#define CONFIG_BUILTIN_PROBE 1
+#define CONFIG_BUILTIN_MEM 1
+
+#endif /* BUILTIN_CMDS_H */
diff --git a/tools/perf/builtin-help.c b/tools/perf/builtin-help.c
index 25d2062..fbbbaa4 100644
--- a/tools/perf/builtin-help.c
+++ b/tools/perf/builtin-help.c
@@ -7,6 +7,7 @@
#include "util/cache.h"
#include "builtin.h"
#include "util/exec_cmd.h"
+#include "builtin-cmds.h"
#include "common-cmds.h"
#include "util/parse-options.h"
#include "util/run-command.h"
diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
index 3c0f3d4..e042728 100644
--- a/tools/perf/builtin-kvm.c
+++ b/tools/perf/builtin-kvm.c
@@ -1556,20 +1556,25 @@ int cmd_kvm(int argc, const char **argv, const char
*prefix __maybe_unused)
if (!strncmp(argv[0], "rec", 3))
return __cmd_record(file_name, argc, argv);
- else if (!strncmp(argv[0], "rep", 3))
+
+ if (!strncmp(argv[0], "rep", 3))
return __cmd_report(file_name, argc, argv);
- else if (!strncmp(argv[0], "diff", 4))
+
+ if (!strncmp(argv[0], "diff", 4))
return cmd_diff(argc, argv, NULL);
-
[PATCH v4 01/14] kbuild: add support of custom paths for "auto.conf*" files
In the scripts/Makefile.build, use KCONFIG_AUTOCONFIG to include a
custom path for the "auto.conf" file.
The "*conf" programs were modified so as to work with the environment
variable KCONFIG_AUTOCONFIG.
Signed-off-by: Alexis Berlemont
---
scripts/Makefile.build | 3 ++-
scripts/kconfig/confdata.c | 23 ++-
scripts/kconfig/lkc.h | 1 +
3 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 649ce68..2abb82f 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -31,7 +31,8 @@ subdir-asflags-y :=
subdir-ccflags-y :=
# Read auto.conf if it exists, otherwise ignore
--include include/config/auto.conf
+kconfig-autoconfig := $(if
$(KCONFIG_AUTOCONFIG),$(KCONFIG_AUTOCONFIG),include/config/auto.conf)
+-include $(kconfig-autoconfig)
include scripts/Kbuild.include
diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
index f88d90f..75cf6bf 100644
--- a/scripts/kconfig/confdata.c
+++ b/scripts/kconfig/confdata.c
@@ -75,6 +75,23 @@ const char *conf_get_autoconfig_name(void)
return name ? name : "include/config/auto.conf";
}
+const char *conf_get_autoconfigdep_name(void)
+{
+ static char res_value[PATH_MAX+1];
+
+ const char *name = conf_get_autoconfig_name();
+
+ if (strlen(name) > PATH_MAX - 4)
+ name = NULL;
+ else {
+ strcpy(res_value, name);
+ strcat(res_value, ".cmd");
+ name = res_value;
+ }
+
+ return name;
+}
+
static char *conf_expand_value(const char *in)
{
struct symbol *sym;
@@ -953,7 +970,11 @@ int conf_write_autoconf(void)
sym_clear_all_valid();
- file_write_dep("include/config/auto.conf.cmd");
+ name = conf_get_autoconfigdep_name();
+ if (name == NULL)
+ return 1;
+
+ file_write_dep(name);
if (conf_split_config())
return 1;
diff --git a/scripts/kconfig/lkc.h b/scripts/kconfig/lkc.h
index d5daa7a..ac99004 100644
--- a/scripts/kconfig/lkc.h
+++ b/scripts/kconfig/lkc.h
@@ -84,6 +84,7 @@ const char *zconf_curname(void);
/* confdata.c */
const char *conf_get_configname(void);
const char *conf_get_autoconfig_name(void);
+const char *conf_get_autoconfigdep_name(void);
char *conf_get_default_confname(void);
void sym_set_change_count(int count);
void sym_add_change_count(int count);
--
2.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 00/14] Kbuild for perf
Hello,
Here is a proposal of perf's build process managed by Kbuild:
* The file Makefile.perf is replaced by Makefile.kbuild
* Makefile.kbuild generates a default .config file if none exists
(allyesconfig)
* Makefile.kbuild adapts the .config file according to the
features-check tests results
* Makefile.kbuild builds external dependencies (linux/tools/lib/*)
* Makefile.kbuild leaves the rest to Kbuild
Changes since v3:
* Patchs were generated starting from the following branch:
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git perf/core
* Add Kconfig options for 32-bit compatibility VDSOs
* Target build-test: for each .config-based test case, call "make
olddefconfig" so as to prevent failure because of new Kconfig
symbol(s)
Regards,
Alexis.
Alexis Berlemont (11):
kbuild: add support of custom paths for "auto.conf*" files
perf kbuild: remove Makefile.perf
perf kbuild: remove legacy tui/gui-related build variables
perf kbuild: remove legacy demangle-related build variables
perf kbuild: cross-compilation variables are now handled in Kconfig
perf kbuild: remove legacy misc build variables
perf kbuild: remove legacy libelf-related build variables
perf kbuild: remove legacy libdwarf-related build variables
perf kbuild: remove legacy script-related build variables
perf kbuild: final cosmetic changes
perf kbuild: add generated Kconfig build-test cases
Jiri Olsa (3):
perf tools: Kbuild builtin source related fixies
perf tools: Kbuild source related fixies
perf tools: Add kbuild support into Makefile.kbuild
scripts/Makefile.build | 3 +-
scripts/kconfig/confdata.c | 23 +-
scripts/kconfig/lkc.h | 1 +
tools/perf/Kbuild | 47 +
tools/perf/Kconfig | 452 ++
tools/perf/MANIFEST| 1 +
tools/perf/Makefile| 2 +-
tools/perf/Makefile.kbuild | 443 ++
tools/perf/Makefile.perf | 981 -
tools/perf/arch/Kbuild | 3 +
tools/perf/arch/arm/Kbuild | 2 +
tools/perf/arch/arm/Makefile | 14 -
tools/perf/arch/arm/tests/Kbuild | 2 +
tools/perf/arch/arm/util/Kbuild| 3 +
tools/perf/arch/arm64/Kbuild | 1 +
tools/perf/arch/arm64/Makefile | 7 -
tools/perf/arch/arm64/util/Kbuild | 2 +
tools/perf/arch/powerpc/Kbuild | 1 +
tools/perf/arch/powerpc/Makefile | 6 -
tools/perf/arch/powerpc/util/Kbuild| 3 +
tools/perf/arch/s390/Kbuild| 1 +
tools/perf/arch/s390/Makefile | 7 -
tools/perf/arch/s390/util/Kbuild | 2 +
tools/perf/arch/sh/Kbuild | 1 +
tools/perf/arch/sh/Makefile| 4 -
tools/perf/arch/sh/util/Kbuild | 1 +
tools/perf/arch/sparc/Kbuild | 1 +
tools/perf/arch/sparc/Makefile | 4 -
tools/perf/arch/sparc/util/Kbuild | 1 +
tools/perf/arch/x86/Kbuild | 2 +
tools/perf/arch/x86/Makefile | 19 -
tools/perf/arch/x86/include/perf_regs.h| 8 +-
tools/perf/arch/x86/tests/Kbuild | 3 +
tools/perf/{ => arch/x86}/tests/perf-time-to-tsc.c | 2 +-
tools/perf/arch/x86/tests/regs_load.S | 3 +-
tools/perf/arch/x86/util/Kbuild| 6 +
tools/perf/arch/x86/util/unwind-libunwind.c| 5 +-
tools/perf/bench/Kbuild| 12 +
tools/perf/bench/mem-memcpy-arch.h | 4 +-
tools/perf/bench/mem-memcpy.c | 4 +-
tools/perf/bench/mem-memset-arch.h | 4 +-
tools/perf/bench/mem-memset.c | 4 +-
tools/perf/builtin-annotate.c | 8 +-
tools/perf/builtin-bench.c | 5 +-
tools/perf/builtin-help.c | 1 +
tools/perf/builtin-inject.c| 2 +-
tools/perf/builtin-kvm.c | 38 +-
tools/perf/builtin-lock.c | 5 +-
tools/perf/builtin-probe.c | 15 +-
tools/perf/builtin-record.c| 4 +-
tools/perf/builtin-report.c| 3 +
tools/perf/builtin-sched.c | 3 +
tools/perf/builtin-script.c| 6 +-
tools/perf/builtin-top.c | 19 +-
tools/perf/config/Makefile | 459 +-
tools/perf/config/defconfig
Re: semantics of reader/writer semaphores in rt patch
On Sun, 26 Oct 2014, Thomas Gleixner wrote: > On Thu, 23 Oct 2014, Chris Friesen wrote: > > Does the RT kernel just disallow this sort of algorithm? > > Yes. For a good reason. Let's add thread C > > A B C > down_read(X) > down_write(X) > lock(Y) > modify data > unlock(Y) > wake(B) > down_read(X) > > Due to the mainline rwsem fairness semantics: > > A holds X, C is blocked on A and B is blocked on A. > > Deadlock, without RT and the single reader restriction being involved. > > So RT does not violate ANY of the existing mainline semantics, it just > imposes a performance impact of not allowing multiple readers. @peterz: It might be worthwhile to have a CONFIG_LOCKDEP=y dependent mode which restricts concurrent readers to 1 in mainline to catch this kind of stuff. Hmm? Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: semantics of reader/writer semaphores in rt patch
On Thu, 23 Oct 2014, Chris Friesen wrote: > I recently noticed that when CONFIG_PREEMPT_RT_FULL is enabled we the > semantics change. From "include/linux/rwsem_rt.h": > > * Note that the semantics are different from the usual > * Linux rw-sems, in PREEMPT_RT mode we do not allow > * multiple readers to hold the lock at once, we only allow > * a read-lock owner to read-lock recursively. This is > * better for latency, makes the implementation inherently > * fair and makes it simpler as well. > > How is this valid? It seems to me that there are any number of code paths > that could depend on having multiple threads of execution be able to hold the > reader lock simultaneously. Something as simple as: > > thread A: > take rw_semaphore X for reading > take lock Y, modify data, release lock Y > wake up thread B > wait on conditional protected by lock Y > free rw_semaphore X > > thread B: > take rw_semaphore X for reading > wait on conditional protected by lock Y > send message to wake up thread A > free rw_semaphore X I don't see why B should wake A without changing the conditional. A won't make progress by being woken by B as the conditional does not magically change just because B wakes A. So what you wanted to say is: thread B: take rw_semaphore X for reading wait on conditional protected by lock Y + take lock Y, modify data, release lock Y send message to wake up thread A free rw_semaphore X Otherwise your example does not make any sense at all. And that has some serious non RT related implications. > In the regular kernel this would work, in the RT kernel it would deadlock. Works by some definition of 'works' > Does the RT kernel just disallow this sort of algorithm? Yes. For a good reason. Let's add thread C A B C down_read(X) down_write(X) lock(Y) modify data unlock(Y) wake(B) down_read(X) Due to the mainline rwsem fairness semantics: A holds X, C is blocked on A and B is blocked on A. Deadlock, without RT and the single reader restriction being involved. So RT does not violate ANY of the existing mainline semantics, it just imposes a performance impact of not allowing multiple readers. Aside of that it provides as usual the free of charge service to expose mainline bugs faster. Yes, it's valid and not that simple as you might think. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
I2C OF IRQ parsing issue due to probe ordering
Hello,
I recently ran into an issue with the OF IRQ parsing code in the I2C core
(of_i2c_register_devices in drivers/i2c/i2c-core.c).
My DT contains the following nodes.
gpio1: gpio@e6051000 {
...
#interrupt-cells = <2>;
interrupt-controller;
clocks = <_clks R8A7790_CLK_GPIO1>;
};
iic2: i2c@e652 {
#address-cells = <1>;
#size-cells = <0>;
...
hdmi@39 {
compatible = "adi,adv7511w";
reg = <0x39>;
interrupt-parent = <>;
interrupts = <15 IRQ_TYPE_EDGE_FALLING>;
...
};
};
mstp9_clks: mstp9_clks@e6150994 {
...
};
The i2c@e652 node is probed before the gpio@e6051000 node. The
of_i2c_register_devices() function tries to register all children, including
hdmi@39. It tries to parse and map the I2C client IRQ by calling
irq_of_parse_and_map(), which returns 0 as the interrupt controller isn't
probed yet. The adv7511 driver later probes the hdmi@39 device and gets
client->irq set to 0.
We can't control the probe order. One option to solve the problem would be to
defer probing of the I2C client until the interrupt control is available. The
following patch is a naive implementation. Before turning it into a real
upstream candidate (changing the return type of irq_create_of_mapping without
checking the callers is a no-go) I'd like to get feedback on the approach.
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 2f90ac6a7f79..73ff1e7d2382 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -631,6 +631,14 @@ static int i2c_device_probe(struct device *dev)
if (!client)
return 0;
+ if (!client->irq && dev->of_node) {
+ int irq = irq_of_parse_and_map(dev->of_node, 0);
+ if (irq < 0)
+ return irq;
+
+ client->irq = irq;
+ }
+
driver = to_i2c_driver(dev->driver);
if (!driver->probe || !driver->id_table)
return -ENODEV;
@@ -1409,7 +1417,6 @@ static void of_i2c_register_devices(struct i2c_adapter
*adap)
continue;
}
- info.irq = irq_of_parse_and_map(node, 0);
info.of_node = of_node_get(node);
info.archdata = _ad;
@@ -1423,7 +1430,6 @@ static void of_i2c_register_devices(struct i2c_adapter
*adap)
dev_err(>dev, "of_i2c: Failure registering %s\n",
node->full_name);
of_node_put(node);
- irq_dispose_mapping(info.irq);
continue;
}
}
diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
index bfec136a6d1e..81a14d89a5bd 100644
--- a/include/linux/of_irq.h
+++ b/include/linux/of_irq.h
@@ -34,7 +34,7 @@ static inline int of_irq_parse_oldworld(struct device_node
*device, int index,
extern int of_irq_parse_raw(const __be32 *addr, struct of_phandle_args
*out_irq);
extern int of_irq_parse_one(struct device_node *device, int index,
struct of_phandle_args *out_irq);
-extern unsigned int irq_create_of_mapping(struct of_phandle_args *irq_data);
+extern int irq_create_of_mapping(struct of_phandle_args *irq_data);
extern int of_irq_to_resource(struct device_node *dev, int index,
struct resource *r);
extern int of_irq_to_resource_table(struct device_node *dev,
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 6534ff6ce02e..386fd09f4c85 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -466,7 +466,7 @@ int irq_create_strict_mappings(struct irq_domain *domain,
unsigned int irq_base,
}
EXPORT_SYMBOL_GPL(irq_create_strict_mappings);
-unsigned int irq_create_of_mapping(struct of_phandle_args *irq_data)
+int irq_create_of_mapping(struct of_phandle_args *irq_data)
{
struct irq_domain *domain;
irq_hw_number_t hwirq;
@@ -477,7 +477,7 @@ unsigned int irq_create_of_mapping(struct of_phandle_args
*irq_data)
if (!domain) {
pr_warn("no irq domain found for %s !\n",
of_node_full_name(irq_data->np));
- return 0;
+ return -EPROBE_DEFER;
}
/* If domain has no translation, then we assume interrupt line */
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] compiler-gcc*.h: remove inaccurate comment about 'asm goto' miscompiles
The bug referenced by the comment in this commit was not completely fixed in GCC 4.8.2, as I mentioned in a thread back in February[1]. The conclusion at that time was to make the quirk unconditional until the bug could be found and fixed in GCC. Unfortunately, when I submitted the patch (commit a9f18034) I left a comment in that claimed the bug was fixed in GCC 4.8.2+. This comment is inaccurate, and should be removed. [1] https://lkml.org/lkml/2014/2/12/797 Signed-off-by: Steven Noonan Cc: Ingo Molnar --- include/linux/compiler-gcc4.h | 1 - include/linux/compiler-gcc5.h | 1 - 2 files changed, 2 deletions(-) diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h index 2507fd2..d1a5582 100644 --- a/include/linux/compiler-gcc4.h +++ b/include/linux/compiler-gcc4.h @@ -71,7 +71,6 @@ * http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670 * * Work it around via a compiler barrier quirk suggested by Jakub Jelinek. - * Fixed in GCC 4.8.2 and later versions. * * (asm goto is automatically volatile - the naming reflects this.) */ diff --git a/include/linux/compiler-gcc5.h b/include/linux/compiler-gcc5.h index cdd1cc2..c8c5659 100644 --- a/include/linux/compiler-gcc5.h +++ b/include/linux/compiler-gcc5.h @@ -53,7 +53,6 @@ * http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670 * * Work it around via a compiler barrier quirk suggested by Jakub Jelinek. - * Fixed in GCC 4.8.2 and later versions. * * (asm goto is automatically volatile - the naming reflects this.) */ -- 2.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.17.0+ files disappearing after playing old dos game on nfsroot laptop
On 10/25/2014 04:55 PM, Eric W. Biederman wrote: Hans de Bruin writes: On 10/24/2014 08:18 PM, Eric W. Biederman wrote: [...] At this point I don't know enough to reproduce this. What does /proc/mounts look like before you start dosemu? bash-4.2$ cat /proc/mounts rootfs / rootfs rw 0 0 10.10.0.1:/nfs/root/psion_14.1 / nfs rw,relatime,vers=3,rsize=4096,wsize=4096,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.10.0.1,mountvers=3,mountproto=tcp,local_lock=all,addr=10.10.0.1 0 0 devtmpfs /dev devtmpfs rw,relatime,size=1031016k,nr_inodes=220978,mode=755 0 0 proc /proc proc rw,relatime 0 0 sysfs /sys sysfs rw,relatime 0 0 tmpfs /run tmpfs rw,relatime,mode=755 0 0 devpts /dev/pts devpts rw,relatime,gid=5,mode=620 0 0 cgroup /sys/fs/cgroup cgroup rw,relatime,cpu 0 0 /dev/shm /tmp tmpfs rw,relatime,size=524288k 0 0 /dev/shm /dev/shm tmpfs rw,relatime,size=524288k 0 0 nfs:/nfs/usr/slackware-14.1/usr /usr nfs ro,relatime,vers=3,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.10.0.1,mountvers=3,mountport=38337,mountproto=udp,local_lock=none,addr=10.10.0.1 0 0 nfs:/nfs/home /home nfs rw,relatime,vers=3,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.10.0.1,mountvers=3,mountport=38337,mountproto=udp,local_lock=none,addr=10.10.0.1 0 0 nfs:/nfs/mp3 /mp3 nfs rw,relatime,vers=3,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.10.0.1,mountvers=3,mountport=38337,mountproto=udp,local_lock=none,addr=10.10.0.1 0 0 nfs:/nfs/src /usr/src nfs rw,relatime,vers=3,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.10.0.1,mountvers=3,mountport=38337,mountproto=udp,local_lock=none,addr=10.10.0.1 0 0 nfs:/nfs/video /video nfs rw,relatime,vers=3,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.10.0.1,mountvers=3,mountport=38337,mountproto=udp,local_lock=none,addr=10.10.0.1 0 0 I now know why I do not see any file in /usr after running dosemu. The whole /usr mount disappears in /proc/mounts. When I remount it I have a usable laptop again. Running dosemu a second time does not remove the mount again. In the mean time I have seen /usr disappear after running other programs like xterm and firefox. But until now never after remouting it. That is interesting. boot run dosemu -> /usr unmounted mount /usr run dosemu -> /usr still mounted sync; echo 3 > /proc/sys/vm/drop_caches run dosemu -> /usr unmounted It sounds like occassionally your /home mount disappears as well. I have not seen that happening ... I expect what needs to happen is to confirm that nfs directory entry revalidation is buggy, and at least for the short term re-add the nfs logic that will avoid dropping a dentry if it is a mount point, or path to a mount point, to avoid the nfs bugs. ok, I will go in waiting mode. -- Hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] genirq: Add support for "split-EOI" irqchips
Moderately recent ARM interrupt controllers can use a "split mode" EOI, where instead of just using a single write to notify the controller of the end of interrupt, uses the following: - priority-drop: the interrupt is still active, but other interrupts can now be taken - deactivate: the interrupt is not active anymore, and can be taken again. This makes it very useful for threaded interrupts, as it avoids the usual mask/unmask dance (and has the potential of being more efficient on ARM, as it is using the CPU interface instead of the global distributor, specially with the use of virtualization). To implement this, a new optional irqchip method is added (irq_priority_drop). The usual irq_eoi is expected to implement the deactivate method. Non threaded interrupts are using these two callbacks back to back, but threaded ones only perform the irq_priority_drop call in the interrupt context, leaving the irq_eoi call to the thread context (which are expected to use the IRQCHIP_EOI_THREADED flag). I've tried to keep the changes as simple as possible, but I'm afraid it might be too simple (I'm basically considering that a a irq_desc with the IRQS_ONESHOT flag is a threaded interrupt, which might not alwayd be true). This has been tested on a dual Cortex-A7 board, with the ahci driver using a threaded interrupt handler. Patches based on my irq/irqchip_state branch previously posted, and also available at: git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git irq/priority_drop Marc Zyngier (3): genirq: Add support for priority-drop/deactivate interrupt controllers irqchip: GIC: Convert to EOImode == 1 irqchip: GICv3: Convert to EOImode == 1 drivers/irqchip/irq-gic-v3.c | 30 -- drivers/irqchip/irq-gic.c | 64 ++ include/linux/irq.h| 1 + include/linux/irqchip/arm-gic-v3.h | 10 ++ include/linux/irqchip/arm-gic.h| 4 +++ kernel/irq/chip.c | 53 +-- 6 files changed, 138 insertions(+), 24 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] genirq: Allow the irqchip state of an IRQ to be save/restored
There is a number of cases where a kernel subsystem may want to
introspect the state of an interrupt at the irqchip level:
- When a peripheral is shared between virtual machines, its interrupt
state becomes part of the guest's state, and must be switched accordingly.
KVM on arm/arm64 requires this for its guest-visible timer
- Some GPIO controllers seem to require peeking into the interrupt controller
they are connected to to report their internal state
This seem to be a pattern that is common enough for the core code to try and
support this without too many horrible hacks. Introduce a pair of accessors
(irq_get_irqchip_state/irq_set_irqchip_state) to retrieve the bits that can
be of interest to another subsystem: pending, active, and masked.
- irq_get_irqchip_state returns the state of the interrupt according to a
state parameter set to IRQCHIP_STATE_PENDING, IRQCHIP_STATE_ACTIVE
or IRQCHIP_STATE_MASKED.
- irq_set_irqchip_state sets the state of the interrupt according to
a similar state.
Signed-off-by: Marc Zyngier
---
include/linux/interrupt.h | 2 ++
include/linux/irq.h | 18
kernel/irq/manage.c | 71 +++
3 files changed, 91 insertions(+)
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 69517a2..80818b4 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -356,6 +356,8 @@ static inline int disable_irq_wake(unsigned int irq)
return irq_set_irq_wake(irq, 0);
}
+extern int irq_get_irqchip_state(unsigned int irq, int state);
+extern int irq_set_irqchip_state(unsigned int irq, int state, int val);
#ifdef CONFIG_IRQ_FORCED_THREADING
extern bool force_irqthreads;
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 03f48d9..257d59a 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -315,6 +315,8 @@ static inline irq_hw_number_t irqd_to_hwirq(struct irq_data
*d)
* any other callback related to this irq
* @irq_release_resources: optional to release resources acquired with
* irq_request_resources
+ * @irq_get_irqchip_state: return the internal state of an interrupt
+ * @irq_set_irqchip_state: set the internal state of a interrupt
* @flags: chip specific flags
*/
struct irq_chip {
@@ -351,6 +353,9 @@ struct irq_chip {
int (*irq_request_resources)(struct irq_data *data);
void(*irq_release_resources)(struct irq_data *data);
+ int (*irq_get_irqchip_state)(struct irq_data *data, int
state);
+ void(*irq_set_irqchip_state)(struct irq_data *data, int
state, int val);
+
unsigned long flags;
};
@@ -376,6 +381,19 @@ enum {
IRQCHIP_EOI_THREADED= (1 << 6),
};
+/*
+ * irq_get_irqchip_state/irq_set_irqchip_state specific flags:
+ *
+ * IRQCHIP_STATE_PENDING: Interrupt asserted at the pin level
+ * IRQCHIP_STATE_ACTIVE: Interrupt in progress (ACKed, but not EOIed)
+ * IRQCHIP_STATE_MASKED: Interrupt is masked
+ */
+enum {
+ IRQCHIP_STATE_PENDING,
+ IRQCHIP_STATE_ACTIVE,
+ IRQCHIP_STATE_MASKED,
+};
+
/* This include will go away once we isolated irq_desc usage to core code */
#include
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 0a9104b..6a4c03f 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1756,3 +1756,74 @@ int request_percpu_irq(unsigned int irq, irq_handler_t
handler,
return retval;
}
+
+/**
+ * irq_get_irqchip_state - returns the irqchip state of a interrupt.
+ * @irq: Interrupt line that is forwarded to a VM
+ * @state: One of IRQCHIP_STATE_* the caller wants to know about
+ *
+ * This call snapshots the internal irqchip state of an
+ * interrupt, returning the bit corresponding to the requested
+ * @state.
+ *
+ * This function should be called with preemption disabled if the
+ * interrupt controller has per-cpu registers.
+ */
+int irq_get_irqchip_state(unsigned int irq, int state)
+{
+ struct irq_desc *desc;
+ struct irq_data *data;
+ struct irq_chip *chip;
+ int val;
+
+ desc = irq_to_desc(irq);
+ if (!desc)
+ return -EINVAL;
+
+ data = irq_desc_get_irq_data(desc);
+
+ chip = irq_desc_get_chip(desc);
+ if (!chip->irq_get_irqchip_state)
+ return -EINVAL;
+
+ chip_bus_lock(desc);
+ val = chip->irq_get_irqchip_state(data, state);
+ chip_bus_sync_unlock(desc);
+
+ return val;
+}
+
+/**
+ * irq_set_irqchip_state - set the state of a forwarded interrupt.
+ * @irq: Interrupt line that is forwarded to a VM
+ * @state: State to be restored (one of IRQCHIP_STATE_*)
+ * @val: value corresponding to @state
+ *
+ * This call sets the internal irqchip state of an interrupt,
+ * depending on the value of @state.
+ *
+ *
[PATCH 2/3] irqchip: GIC: Convert to EOImode == 1
So far, GICv2 has been used in with EOImode == 0. The effect of this
mode is to perform the priority drop and the deactivation of the
interrupt at the same time.
While this works perfectly for Linux (we only have a single priority),
it causes issues when an interrupt is forwarded to a guest, and when
we want the guest to perform the EOI itself. This is also rather
inefficient for threaded interrupts, as it forces us to hit the
distributor (which is slower, specially when using virtualization).
For this case, the GIC architecture provides EOImode == 1, where:
- A write to the EOI register drops the priority of the interrupt and leaves
it active. Other interrupts at the same priority level can now be taken,
but the active interrupt cannot be taken again
- A write to the DIR marks the interrupt as inactive, meaning it can
now be taken again.
We only enable this feature when booted in HYP mode. Also, as most device
trees are broken (they report the CPU interface size to be 4kB, while
the GICv2 CPU interface size is 8kB), output a warning if we're booted
in HYP mode, and disable the feature.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic.c | 64 +
include/linux/irqchip/arm-gic.h | 4 +++
2 files changed, 62 insertions(+), 6 deletions(-)
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index d78169e..53aedc8 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -44,6 +44,7 @@
#include
#include
#include
+#include
#include "irq-gic-common.h"
#include "irqchip.h"
@@ -93,6 +94,10 @@ struct irq_chip gic_arch_extn = {
.irq_set_wake = NULL,
};
+static struct irq_chip *gic_chip;
+
+static bool supports_deactivate = false;
+
#ifndef MAX_GIC_NR
#define MAX_GIC_NR 1
#endif
@@ -192,6 +197,16 @@ static void gic_eoi_irq(struct irq_data *d)
writel_relaxed(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI);
}
+static void gic_priority_drop_irq(struct irq_data *d)
+{
+ gic_eoi_irq(d);
+}
+
+static void gic_deactivate_irq(struct irq_data *d)
+{
+ writel_relaxed(gic_irq(d), gic_cpu_base(d) + GIC_CPU_DEACTIVATE);
+}
+
static void gic_irq_set_irqchip_state(struct irq_data *d, int state, int val)
{
u32 reg;
@@ -333,6 +348,8 @@ static void __exception_irq_entry gic_handle_irq(struct
pt_regs *regs)
}
if (irqnr < 16) {
writel_relaxed(irqstat, cpu_base + GIC_CPU_EOI);
+ if (supports_deactivate)
+ writel_relaxed(irqstat, cpu_base +
GIC_CPU_DEACTIVATE);
#ifdef CONFIG_SMP
handle_IPI(irqnr, regs);
#endif
@@ -369,7 +386,7 @@ static void gic_handle_cascade_irq(unsigned int irq, struct
irq_desc *desc)
chained_irq_exit(chip, desc);
}
-static struct irq_chip gic_chip = {
+static struct irq_chip gicv1_chip = {
.name = "GIC",
.irq_mask = gic_mask_irq,
.irq_unmask = gic_unmask_irq,
@@ -384,6 +401,23 @@ static struct irq_chip gic_chip = {
.irq_set_irqchip_state = gic_irq_set_irqchip_state,
};
+static struct irq_chip gicv2_chip = {
+ .name = "GIC",
+ .flags = IRQCHIP_EOI_THREADED,
+ .irq_mask = gic_mask_irq,
+ .irq_unmask = gic_unmask_irq,
+ .irq_priority_drop = gic_priority_drop_irq,
+ .irq_eoi= gic_deactivate_irq,
+ .irq_set_type = gic_set_type,
+ .irq_retrigger = gic_retrigger,
+#ifdef CONFIG_SMP
+ .irq_set_affinity = gic_set_affinity,
+#endif
+ .irq_set_wake = gic_set_wake,
+ .irq_get_irqchip_state = gic_irq_get_irqchip_state,
+ .irq_set_irqchip_state = gic_irq_set_irqchip_state,
+};
+
void __init gic_cascade_irq(unsigned int gic_nr, unsigned int irq)
{
if (gic_nr >= MAX_GIC_NR)
@@ -415,7 +449,11 @@ static u8 gic_get_cpumask(struct gic_chip_data *gic)
static void gic_cpu_if_up(void)
{
void __iomem *cpu_base = gic_data_cpu_base(_data[0]);
- u32 bypass = 0;
+ u32 bypass;
+ u32 mode = 0;
+
+ if (supports_deactivate)
+ mode = GIC_CPU_CTRL_EOImodeNS;
/*
* Preserve bypass disable bits to be written back later
@@ -423,7 +461,7 @@ static void gic_cpu_if_up(void)
bypass = readl(cpu_base + GIC_CPU_CTRL);
bypass &= GICC_DIS_BYPASS_MASK;
- writel_relaxed(bypass | GICC_ENABLE, cpu_base + GIC_CPU_CTRL);
+ writel_relaxed(bypass | mode | GICC_ENABLE, cpu_base + GIC_CPU_CTRL);
}
@@ -848,11 +886,11 @@ static int gic_irq_domain_map(struct irq_domain *d,
unsigned int irq,
{
if (hw < 32) {
irq_set_percpu_devid(irq);
- irq_set_chip_and_handler(irq, _chip,
+ irq_set_chip_and_handler(irq, gic_chip,
[PATCH 3/3] irqchip: GICv3: Add support for irq_{get,set}_irqchip_state
Add the required hooks for the internal state of an interrupt
to be exposed to other subsystems.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3.c | 78
1 file changed, 65 insertions(+), 13 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index aa17ae8..666c14e 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -193,6 +193,19 @@ static void gic_enable_redist(bool enable)
/*
* Routines to disable, enable, EOI and route interrupts
*/
+static int gic_peek_irq(struct irq_data *d, u32 offset)
+{
+ u32 mask = 1 << (gic_irq(d) % 32);
+ void __iomem *base;
+
+ if (gic_irq_in_rdist(d))
+ base = gic_data_rdist_sgi_base();
+ else
+ base = gic_data.dist_base;
+
+ return !!(readl_relaxed(base + offset + (gic_irq(d) / 32) * 4) & mask);
+}
+
static void gic_poke_irq(struct irq_data *d, u32 offset)
{
u32 mask = 1 << (gic_irq(d) % 32);
@@ -221,6 +234,56 @@ static void gic_unmask_irq(struct irq_data *d)
gic_poke_irq(d, GICD_ISENABLER);
}
+static void gic_irq_set_irqchip_state(struct irq_data *d, int state, int val)
+{
+ u32 reg;
+
+ switch (state) {
+ case IRQCHIP_STATE_PENDING:
+ reg = val ? GICD_ISPENDR : GICD_ICPENDR;
+ break;
+
+ case IRQCHIP_STATE_ACTIVE:
+ reg = val ? GICD_ISACTIVER : GICD_ICACTIVER;
+ break;
+
+ case IRQCHIP_STATE_MASKED:
+ reg = val ? GICD_ICENABLER : GICD_ISENABLER;
+ break;
+
+ default:
+ WARN_ON(1);
+ return;
+ }
+
+ gic_poke_irq(d, reg);
+}
+
+static int gic_irq_get_irqchip_state(struct irq_data *d, int state)
+{
+ int val;
+
+ switch (state) {
+ case IRQCHIP_STATE_PENDING:
+ val = gic_peek_irq(d, GICD_ISPENDR);
+ break;
+
+ case IRQCHIP_STATE_ACTIVE:
+ val = gic_peek_irq(d, GICD_ISACTIVER);
+ break;
+
+ case IRQCHIP_STATE_MASKED:
+ val = !gic_peek_irq(d, GICD_ISENABLER);
+ break;
+
+ default:
+ WARN_ON(1);
+ val = 0;
+ }
+
+ return val;
+}
+
static void gic_eoi_irq(struct irq_data *d)
{
gic_write_eoir(gic_irq(d));
@@ -404,19 +467,6 @@ static void gic_cpu_init(void)
}
#ifdef CONFIG_SMP
-static int gic_peek_irq(struct irq_data *d, u32 offset)
-{
- u32 mask = 1 << (gic_irq(d) % 32);
- void __iomem *base;
-
- if (gic_irq_in_rdist(d))
- base = gic_data_rdist_sgi_base();
- else
- base = gic_data.dist_base;
-
- return !!(readl_relaxed(base + offset + (gic_irq(d) / 32) * 4) & mask);
-}
-
static int gic_secondary_init(struct notifier_block *nfb,
unsigned long action, void *hcpu)
{
@@ -583,6 +633,8 @@ static struct irq_chip gic_chip = {
.irq_eoi= gic_eoi_irq,
.irq_set_type = gic_set_type,
.irq_set_affinity = gic_set_affinity,
+ .irq_get_irqchip_state = gic_irq_get_irqchip_state,
+ .irq_set_irqchip_state = gic_irq_set_irqchip_state,
};
static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq,
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] irqchip: GIC: Add support for irq_{get,set}_irqchip_state
Add the required hooks for the internal state of an interrupt
to be exposed to other subsystems.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic.c | 70 +++
1 file changed, 65 insertions(+), 5 deletions(-)
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 38493ff..d78169e 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -151,12 +151,22 @@ static inline unsigned int gic_irq(struct irq_data *d)
/*
* Routines to acknowledge, disable and enable interrupts
*/
-static void gic_mask_irq(struct irq_data *d)
+static void gic_poke_irq(struct irq_data *d, u32 offset)
{
u32 mask = 1 << (gic_irq(d) % 32);
+ writel_relaxed(mask, gic_dist_base(d) + offset + (gic_irq(d) / 32) * 4);
+}
+static int gic_peek_irq(struct irq_data *d, u32 offset)
+{
+ u32 mask = 1 << (gic_irq(d) % 32);
+ return !!(readl_relaxed(gic_dist_base(d) + offset + (gic_irq(d) / 32) *
4) & mask);
+}
+
+static void gic_mask_irq(struct irq_data *d)
+{
raw_spin_lock(_controller_lock);
- writel_relaxed(mask, gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR +
(gic_irq(d) / 32) * 4);
+ gic_poke_irq(d, GIC_DIST_ENABLE_CLEAR);
if (gic_arch_extn.irq_mask)
gic_arch_extn.irq_mask(d);
raw_spin_unlock(_controller_lock);
@@ -164,12 +174,10 @@ static void gic_mask_irq(struct irq_data *d)
static void gic_unmask_irq(struct irq_data *d)
{
- u32 mask = 1 << (gic_irq(d) % 32);
-
raw_spin_lock(_controller_lock);
if (gic_arch_extn.irq_unmask)
gic_arch_extn.irq_unmask(d);
- writel_relaxed(mask, gic_dist_base(d) + GIC_DIST_ENABLE_SET +
(gic_irq(d) / 32) * 4);
+ gic_poke_irq(d, GIC_DIST_ENABLE_SET);
raw_spin_unlock(_controller_lock);
}
@@ -184,6 +192,56 @@ static void gic_eoi_irq(struct irq_data *d)
writel_relaxed(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI);
}
+static void gic_irq_set_irqchip_state(struct irq_data *d, int state, int val)
+{
+ u32 reg;
+
+ switch (state) {
+ case IRQCHIP_STATE_PENDING:
+ reg = val ? GIC_DIST_PENDING_SET : GIC_DIST_PENDING_CLEAR;
+ break;
+
+ case IRQCHIP_STATE_ACTIVE:
+ reg = val ? GIC_DIST_ACTIVE_SET : GIC_DIST_ACTIVE_CLEAR;
+ break;
+
+ case IRQCHIP_STATE_MASKED:
+ reg = val ? GIC_DIST_ENABLE_CLEAR : GIC_DIST_ENABLE_SET;
+ break;
+
+ default:
+ WARN_ON(1);
+ return;
+ }
+
+ gic_poke_irq(d, reg);
+}
+
+static int gic_irq_get_irqchip_state(struct irq_data *d, int state)
+{
+ int val;
+
+ switch (state) {
+ case IRQCHIP_STATE_PENDING:
+ val = gic_peek_irq(d, GIC_DIST_PENDING_SET);
+ break;
+
+ case IRQCHIP_STATE_ACTIVE:
+ val = gic_peek_irq(d, GIC_DIST_ACTIVE_SET);
+ break;
+
+ case IRQCHIP_STATE_MASKED:
+ val = !gic_peek_irq(d, GIC_DIST_ENABLE_SET);
+ break;
+
+ default:
+ WARN_ON(1);
+ val = 0;
+ }
+
+ return val;
+}
+
static int gic_set_type(struct irq_data *d, unsigned int type)
{
void __iomem *base = gic_dist_base(d);
@@ -322,6 +380,8 @@ static struct irq_chip gic_chip = {
.irq_set_affinity = gic_set_affinity,
#endif
.irq_set_wake = gic_set_wake,
+ .irq_get_irqchip_state = gic_irq_get_irqchip_state,
+ .irq_set_irqchip_state = gic_irq_set_irqchip_state,
};
void __init gic_cascade_irq(unsigned int gic_nr, unsigned int irq)
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] genirq: Add support for priority-drop/deactivate interrupt controllers
Moderately recent ARM interrupt controllers can use a "split mode" EOI,
where instead of just using a single write to notify the controller of
the end of interrupt, uses the following:
- priority-drop: the interrupt is still active, but other interrupts can
now be taken
- deactivate: the interrupt is not active anymore, and can be taken again.
This makes it very useful for threaded interrupts, as it avoids the usual
mask/unmask dance (and has the potential of being more efficient on ARM,
as it is using the CPU interface instead of the global distributor).
To implement this, a new optional irqchip method is added (irq_priority_drop).
The usual irq_eoi is expected to implement the deactivate method.
Non threaded interrupts are using these two callbacks back to back, but threaded
ones only perform the irq_priority_drop call in the interrupt context, leaving
the irq_eoi call to the thread context (which are expected to use the
IRQCHIP_EOI_THREADED flag).
Signed-off-by: Marc Zyngier
---
include/linux/irq.h | 1 +
kernel/irq/chip.c | 53 +
2 files changed, 38 insertions(+), 16 deletions(-)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 257d59a..64d3756 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -330,6 +330,7 @@ struct irq_chip {
void(*irq_mask)(struct irq_data *data);
void(*irq_mask_ack)(struct irq_data *data);
void(*irq_unmask)(struct irq_data *data);
+ void(*irq_priority_drop)(struct irq_data *data);
void(*irq_eoi)(struct irq_data *data);
int (*irq_set_affinity)(struct irq_data *data, const struct
cpumask *dest, bool force);
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index e5202f0..cf9d001 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -272,12 +272,25 @@ void mask_irq(struct irq_desc *desc)
}
}
+static void mask_threaded_irq(struct irq_desc *desc)
+{
+ struct irq_chip *chip = desc->irq_data.chip;
+
+ /* If we can do priority drop, then masking comes for free */
+ if (chip->irq_priority_drop)
+ irq_state_set_masked(desc);
+ else
+ mask_irq(desc);
+}
+
void unmask_irq(struct irq_desc *desc)
{
- if (desc->irq_data.chip->irq_unmask) {
- desc->irq_data.chip->irq_unmask(>irq_data);
+ struct irq_chip *chip = desc->irq_data.chip;
+
+ if (chip->irq_unmask && !chip->irq_priority_drop)
+ chip->irq_unmask(>irq_data);
+ if (chip->irq_unmask || chip->irq_priority_drop)
irq_state_clr_masked(desc);
- }
}
void unmask_threaded_irq(struct irq_desc *desc)
@@ -287,10 +300,7 @@ void unmask_threaded_irq(struct irq_desc *desc)
if (chip->flags & IRQCHIP_EOI_THREADED)
chip->irq_eoi(>irq_data);
- if (chip->irq_unmask) {
- chip->irq_unmask(>irq_data);
- irq_state_clr_masked(desc);
- }
+ unmask_irq(desc);
}
/*
@@ -470,12 +480,24 @@ static inline void preflow_handler(struct irq_desc *desc)
static inline void preflow_handler(struct irq_desc *desc) { }
#endif
+static void eoi_irq(struct irq_desc *desc, struct irq_chip *chip)
+{
+ if (chip->irq_priority_drop)
+ chip->irq_priority_drop(>irq_data);
+ if (chip->irq_eoi)
+ chip->irq_eoi(>irq_data);
+}
+
static void cond_unmask_eoi_irq(struct irq_desc *desc, struct irq_chip *chip)
{
if (!(desc->istate & IRQS_ONESHOT)) {
- chip->irq_eoi(>irq_data);
+ eoi_irq(desc, chip);
return;
}
+
+ if (chip->irq_priority_drop)
+ chip->irq_priority_drop(>irq_data);
+
/*
* We need to unmask in the following cases:
* - Oneshot irq which did not wake the thread (caused by a
@@ -485,7 +507,8 @@ static void cond_unmask_eoi_irq(struct irq_desc *desc,
struct irq_chip *chip)
if (!irqd_irq_disabled(>irq_data) &&
irqd_irq_masked(>irq_data) && !desc->threads_oneshot) {
chip->irq_eoi(>irq_data);
- unmask_irq(desc);
+ if (!chip->irq_priority_drop)
+ unmask_irq(desc);
} else if (!(chip->flags & IRQCHIP_EOI_THREADED)) {
chip->irq_eoi(>irq_data);
}
@@ -525,7 +548,7 @@ handle_fasteoi_irq(unsigned int irq, struct irq_desc *desc)
}
if (desc->istate & IRQS_ONESHOT)
- mask_irq(desc);
+ mask_threaded_irq(desc);
preflow_handler(desc);
handle_irq_event(desc);
@@ -536,7 +559,7 @@ handle_fasteoi_irq(unsigned int irq, struct irq_desc *desc)
return;
out:
if (!(chip->flags & IRQCHIP_EOI_IF_HANDLED))
- chip->irq_eoi(>irq_data);
+ eoi_irq(desc, chip);
raw_spin_unlock(>lock);
}
[PATCH 3/3] irqchip: GICv3: Convert to EOImode == 1
So far, GICv3 has been used in with EOImode == 0. The effect of this
mode is to perform the priority drop and the deactivation of the
interrupt at the same time.
While this works perfectly for Linux (we only have a single priority),
it causes issues when an interrupt is forwarded to a guest, and when
we want the guest to perform the EOI itself. This is also rather
inefficient for threaded interrupts, as it forces us to hit the
distributor (which is slower, specially when using virtualization).
For this case, the GIC architecture provides EOImode == 1, where:
- A write to ICC_EOIR1_EL1 drops the priority of the interrupt and leaves
it active. Other interrupts at the same priority level can now be taken,
but the active interrupt cannot be taken again
- A write to ICC_DIR_EL1 marks the interrupt as inactive, meaning it can
now be taken again.
This patch converts the driver to this new mode when virtualization is
enabled.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3.c | 30 --
include/linux/irqchip/arm-gic-v3.h | 10 ++
2 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 666c14e..c7f8a25 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include "irq-gic-common.h"
#include "irqchip.h"
@@ -45,6 +46,7 @@ struct gic_chip_data {
};
static struct gic_chip_data gic_data __read_mostly;
+static bool supports_deactivate = false;
#define gic_data_rdist() (this_cpu_ptr(gic_data.rdist))
#define gic_data_rdist_rd_base() (*gic_data_rdist())
@@ -289,6 +291,16 @@ static void gic_eoi_irq(struct irq_data *d)
gic_write_eoir(gic_irq(d));
}
+static void gic_priority_drop_irq(struct irq_data *d)
+{
+ gic_write_eoir(gic_irq(d));
+}
+
+static void gic_deactivate_irq(struct irq_data *d)
+{
+ gic_write_dir(gic_irq(d));
+}
+
static int gic_set_type(struct irq_data *d, unsigned int type)
{
unsigned int irq = gic_irq(d);
@@ -345,6 +357,8 @@ static asmlinkage void __exception_irq_entry
gic_handle_irq(struct pt_regs *regs
}
if (irqnr < 16) {
gic_write_eoir(irqnr);
+ if (supports_deactivate)
+ gic_write_dir(irqnr);
#ifdef CONFIG_SMP
handle_IPI(irqnr, regs);
#else
@@ -441,8 +455,13 @@ static void gic_cpu_sys_reg_init(void)
/* Set priority mask register */
gic_write_pmr(DEFAULT_PMR_VALUE);
- /* EOI deactivates interrupt too (mode 0) */
- gic_write_ctlr(ICC_CTLR_EL1_EOImode_drop_dir);
+ if (supports_deactivate) {
+ /* EOI drops priority only (mode 1) */
+ gic_write_ctlr(ICC_CTLR_EL1_EOImode_drop);
+ } else {
+ /* EOI deactivates interrupt too (mode 0) */
+ gic_write_ctlr(ICC_CTLR_EL1_EOImode_drop_dir);
+ }
/* ... and let's hit the road... */
gic_write_grpen1(1);
@@ -738,6 +757,13 @@ static int __init gic_of_init(struct device_node *node,
struct device_node *pare
if (of_property_read_u64(node, "redistributor-stride", _stride))
redist_stride = 0;
+ if (is_hyp_mode_available()) {
+ supports_deactivate = true;
+ gic_chip.flags = IRQCHIP_EOI_THREADED,
+ gic_chip.irq_priority_drop = gic_priority_drop_irq;
+ gic_chip.irq_eoi= gic_deactivate_irq;
+ }
+
gic_data.dist_base = dist_base;
gic_data.redist_base = redist_base;
gic_data.redist_regions = redist_regions;
diff --git a/include/linux/irqchip/arm-gic-v3.h
b/include/linux/irqchip/arm-gic-v3.h
index 03a4ea3..9875502 100644
--- a/include/linux/irqchip/arm-gic-v3.h
+++ b/include/linux/irqchip/arm-gic-v3.h
@@ -74,6 +74,9 @@
#define GICR_SYNCR 0x00C0
#define GICR_MOVLPIR 0x0100
#define GICR_MOVALLR 0x0110
+#define GICR_ISACTIVER GICD_ISACTIVER
+#define GICR_ICACTIVER GICD_ICACTIVER
+#define GICR_IDREGSGICD_IDREGS
#define GICR_PIDR2 GICD_PIDR2
#define GICR_WAKER_ProcessorSleep (1U << 1)
@@ -128,6 +131,7 @@
#define ICH_VMCR_PMR_MASK (0xffUL << ICH_VMCR_PMR_SHIFT)
#define ICC_EOIR1_EL1 sys_reg(3, 0, 12, 12, 1)
+#define ICC_DIR_EL1sys_reg(3, 0, 12, 11, 1)
#define ICC_IAR1_EL1 sys_reg(3, 0, 12, 12, 0)
#define ICC_SGI1R_EL1 sys_reg(3, 0, 12, 11, 5)
#define ICC_PMR_EL1sys_reg(3, 0, 4, 6, 0)
@@ -195,6 +199,12 @@ static inline void gic_write_eoir(u64 irq)
isb();
}
+static inline void gic_write_dir(u64 irq)
+{
+ asm volatile("msr_s "
[PATCH 0/3] genirq: Saving/restoring the irqchip state of an irq line
Despite Linux offering a rather fine grained control over the life
cycle of an interrupt, there is a few cases where it would be very
useful to snapshot (or even set) the internal state of the interrupt
controller for a given interrupt line:
- With KVM, a device shared between VMs must have its whole context
switched, and that includes the interrupt line state. KVM/arm is
moving to using this.
- Some GPIO controllers seem to require peeking into the interrupt controller
they are connected to to report their internal state.
Instead of letting people facing this situation doing horrible
(controller specific) hacks in their code, let's offer a couple of new
entry points that allow a few attributes to be read and set.
Of course, this is a very dangerous thing to do if you don't know what
you doing, and I wouldn't expect most drivers to use this. But this
can also be a life saver at times.
This patch series implement said API, and adds support for this to the
two main ARM interrupt controllers (GIC and GICv3).
Based on 3.18-rc1, tested on arm/arm64, and also available at:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
irq/irqchip_state
Marc Zyngier (3):
genirq: Allow the irqchip state of an IRQ to be save/restored
irqchip: GIC: Add support for irq_{get,set}_irqchip_state
irqchip: GICv3: Add support for irq_{get,set}_irqchip_state
drivers/irqchip/irq-gic-v3.c | 78
drivers/irqchip/irq-gic.c| 70 ---
include/linux/interrupt.h| 2 ++
include/linux/irq.h | 18 ++
kernel/irq/manage.c | 71
5 files changed, 221 insertions(+), 18 deletions(-)
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regulator: stub out devm_regulator_get_exclusive
On Fri, Oct 24, 2014 at 05:57:24PM -0400, Rob Clark wrote: > Oh, you are only looking at the one in mdp4_kms_init(), which could > possibly be a simple regulator_get(). Look instead at the ones in > hdmi_init(), where I need to know whether to defer or not. At one No, I saw that - looking at the code in hdmi_init() it's using normal devm_regulator_get() correctly (it appears to be open coding devm_regulator_bulk_get() and likewise for the enables and disables but that's a lot less serious). I can't see anything actively broken with that code other than the error handling on failed enable. > point I was having a problem getting dummy regulators with > regulator_get() but that could have been a symptom of another problem. > I will re-try regulator_get() next time I am working on the kernel > part of the driver.. It's a bug elsewhere, if you are getting a dummy regulator on a DT system it means that you don't have a regulator set up for that supply so the core is just assuming that it's always on. signature.asc Description: Digital signature
Re: [PATCH] x86: Don't allow stackprotector without TSC
On Fri, 24 Oct 2014, Borislav Petkov wrote: > On Thu, Oct 23, 2014 at 04:43:03PM -0700, Andy Lutomirski wrote: > > Presumably the actual failure is a #GP when trying to do the rdtsc. If > > so, wouldn't a better fix be to make that rdtsc check cpuid first? Can > > we easily check cpuid that early? > > I don't see why not. > > The real question, though is, can we have a fallback for RDTSC on those > machines so that they don't have to disable stack protector in order to > boot. The simple solution is to make the rdtsc conditional on the availability of the feature flag, which is going to be not set on these kind of machines. So for the non TSC case we can either leave the extra randomness alone or readout PIT, which is available and better than nothing. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4 RESEND 0/3] syscalls,x86: Add execveat() system call
Hi! > >> Oh, you mean that #!/usr/bin/make -f would turn into /usr/bin/make > >> /dev/fd/3? That could be interesting, although I can imagine it > >> breaking things, especially if /dev/fd/3 isn't set up like that, e.g. > >> early in boot. > > > > Sigh... What I mean is that fexecve(fd, ...) would have to put _something_ > > into argv when it execs the interpreter of #! file. Simply because the > > interpreter (which can be anything whatsoever) has no fscking idea what > > to do with some descriptor it has before execve(). Hell, it doesn't have > > any idea *which* descriptor had it been. > > > > You need to put some pathname that would yield your script upon open(2). > > If you bothered to read those patches, you'd see that they do supply > > one, generating it with d_path(). Which isn't particulary reliable. > > > > I'm not sure there's any point putting any of that in the kernel - if > > you *do* have that pathname, you can just pass it. > > Hmm. > > This issue certainly makes fexecve or execveat less attractive, at > least in cases where d_path won't work. > > On the other hand, if you want to run a static binary on a cloexec fd > (or, for that matter, a dynamic binary if you trust the interpreter to > close the extra copy of the fd it gets) in a namespace or chroot where > the binary is invisible, then you need kernel help. > > It's too bad that script interpreters don't have a mechanism to open > their scripts by fd. Every interpretter depends on /dev/zero... so what about having /dev/script_im_running? Standard character device, contains whatever script it should contain... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 2/2] arch/powerpc: Switch to generic RCU get_user_pages_fast
This patch switch the ppc arch to use the generic RCU based
gup implementation.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/hugetlb.h | 8 +-
arch/powerpc/include/asm/page.h | 3 +-
arch/powerpc/include/asm/pgtable-ppc64.h | 1 -
arch/powerpc/include/asm/pgtable.h | 5 -
arch/powerpc/mm/Makefile | 2 +-
arch/powerpc/mm/gup.c| 235 ---
arch/powerpc/mm/hugetlbpage.c| 27 ++--
8 files changed, 21 insertions(+), 261 deletions(-)
delete mode 100644 arch/powerpc/mm/gup.c
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 88eace4..7af887d 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -148,6 +148,7 @@ config PPC
select HAVE_ARCH_AUDITSYSCALL
select ARCH_SUPPORTS_ATOMIC_RMW
select DCACHE_WORD_ACCESS if PPC64 && CPU_LITTLE_ENDIAN
+ select HAVE_GENERIC_RCU_GUP
config GENERIC_CSUM
def_bool CPU_LITTLE_ENDIAN
diff --git a/arch/powerpc/include/asm/hugetlb.h
b/arch/powerpc/include/asm/hugetlb.h
index 766b77d..1d53a65 100644
--- a/arch/powerpc/include/asm/hugetlb.h
+++ b/arch/powerpc/include/asm/hugetlb.h
@@ -48,7 +48,7 @@ static inline unsigned int hugepd_shift(hugepd_t hpd)
#endif /* CONFIG_PPC_BOOK3S_64 */
-static inline pte_t *hugepte_offset(hugepd_t *hpdp, unsigned long addr,
+static inline pte_t *hugepte_offset(hugepd_t hpd, unsigned long addr,
unsigned pdshift)
{
/*
@@ -58,9 +58,9 @@ static inline pte_t *hugepte_offset(hugepd_t *hpdp, unsigned
long addr,
*/
unsigned long idx = 0;
- pte_t *dir = hugepd_page(*hpdp);
+ pte_t *dir = hugepd_page(hpd);
#ifndef CONFIG_PPC_FSL_BOOK3E
- idx = (addr & ((1UL << pdshift) - 1)) >> hugepd_shift(*hpdp);
+ idx = (addr & ((1UL << pdshift) - 1)) >> hugepd_shift(hpd);
#endif
return dir + idx;
@@ -193,7 +193,7 @@ static inline void flush_hugetlb_page(struct vm_area_struct
*vma,
}
#define hugepd_shift(x) 0
-static inline pte_t *hugepte_offset(hugepd_t *hpdp, unsigned long addr,
+static inline pte_t *hugepte_offset(hugepd_t hpd, unsigned long addr,
unsigned pdshift)
{
return 0;
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index f973fce..69c0598 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -379,13 +379,14 @@ static inline int hugepd_ok(hugepd_t hpd)
}
#endif
-#define is_hugepd(pdep) (hugepd_ok(*((hugepd_t *)(pdep
+#define is_hugepd(hpd) (hugepd_ok(hpd))
#define pgd_huge pgd_huge
int pgd_huge(pgd_t pgd);
#else /* CONFIG_HUGETLB_PAGE */
#define is_hugepd(pdep)0
#define pgd_huge(pgd) 0
#endif /* CONFIG_HUGETLB_PAGE */
+#define __hugepd(x) ((hugepd_t) { (x) })
struct page;
extern void clear_user_page(void *page, unsigned long vaddr, struct page *pg);
diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h
b/arch/powerpc/include/asm/pgtable-ppc64.h
index ae153c4..29c3624 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
@@ -575,6 +575,5 @@ static inline int pmd_move_must_withdraw(struct spinlock
*new_pmd_ptl,
*/
return true;
}
-
#endif /* __ASSEMBLY__ */
#endif /* _ASM_POWERPC_PGTABLE_PPC64_H_ */
diff --git a/arch/powerpc/include/asm/pgtable.h
b/arch/powerpc/include/asm/pgtable.h
index 316f9a5..4a67c1d 100644
--- a/arch/powerpc/include/asm/pgtable.h
+++ b/arch/powerpc/include/asm/pgtable.h
@@ -274,11 +274,6 @@ extern void paging_init(void);
*/
extern void update_mmu_cache(struct vm_area_struct *, unsigned long, pte_t *);
-extern int gup_hugepd(hugepd_t *hugepd, unsigned pdshift, unsigned long addr,
- unsigned long end, int write, struct page **pages, int
*nr);
-
-extern int gup_hugepte(pte_t *ptep, unsigned long sz, unsigned long addr,
- unsigned long end, int write, struct page **pages, int
*nr);
#ifndef CONFIG_TRANSPARENT_HUGEPAGE
#define pmd_large(pmd) 0
#define has_transparent_hugepage() 0
diff --git a/arch/powerpc/mm/Makefile b/arch/powerpc/mm/Makefile
index 325e861..438dcd3 100644
--- a/arch/powerpc/mm/Makefile
+++ b/arch/powerpc/mm/Makefile
@@ -6,7 +6,7 @@ subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror
ccflags-$(CONFIG_PPC64):= $(NO_MINIMAL_TOC)
-obj-y := fault.o mem.o pgtable.o gup.o mmap.o \
+obj-y := fault.o mem.o pgtable.o mmap.o \
init_$(CONFIG_WORD_SIZE).o \
pgtable_$(CONFIG_WORD_SIZE).o
obj-$(CONFIG_PPC_MMU_NOHASH) += mmu_context_nohash.o tlb_nohash.o \
diff --git a/arch/powerpc/mm/gup.c b/arch/powerpc/mm/gup.c
deleted file mode 100644
index d874668..000
[PATCH V3 1/2] mm: Update generic gup implementation to handle hugepage directory
Update generic gup implementation with powerpc specific details.
On powerpc at pmd level we can have hugepte, normal pmd pointer
or a pointer to the hugepage directory.
Signed-off-by: Aneesh Kumar K.V
---
Changes from V3:
* Explain pgd_huge, also move the definition to linux/hugetlb.h.
Both pgd_huge and is_hugepd are related to hugepages and hugetlb.h
is the right header
arch/arm/include/asm/pgtable.h | 2 +
arch/arm64/include/asm/pgtable.h | 2 +
arch/powerpc/include/asm/page.h | 1 +
include/linux/hugetlb.h | 30 +++
include/linux/mm.h | 7 +++
mm/gup.c | 113 +++
6 files changed, 96 insertions(+), 59 deletions(-)
diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
index 3b30062..c52d261 100644
--- a/arch/arm/include/asm/pgtable.h
+++ b/arch/arm/include/asm/pgtable.h
@@ -181,6 +181,8 @@ extern pgd_t swapper_pg_dir[PTRS_PER_PGD];
/* to find an entry in a kernel page-table-directory */
#define pgd_offset_k(addr) pgd_offset(_mm, addr)
+#define pgd_huge(pgd) (0)
+
#define pmd_none(pmd) (!pmd_val(pmd))
#define pmd_present(pmd) (pmd_val(pmd))
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 41a43bf..f532a14 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -464,6 +464,8 @@ static inline pmd_t pmd_modify(pmd_t pmd, pgprot_t newprot)
extern pgd_t swapper_pg_dir[PTRS_PER_PGD];
extern pgd_t idmap_pg_dir[PTRS_PER_PGD];
+#define pgd_huge(pgd) (0)
+
/*
* Encode and decode a swap entry:
* bits 0-1: present (must be zero)
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index 26fe1ae..f973fce 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -380,6 +380,7 @@ static inline int hugepd_ok(hugepd_t hpd)
#endif
#define is_hugepd(pdep) (hugepd_ok(*((hugepd_t *)(pdep
+#define pgd_huge pgd_huge
int pgd_huge(pgd_t pgd);
#else /* CONFIG_HUGETLB_PAGE */
#define is_hugepd(pdep)0
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 6e6d338..de63dbc 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -175,6 +175,36 @@ static inline void __unmap_hugepage_range(struct
mmu_gather *tlb,
}
#endif /* !CONFIG_HUGETLB_PAGE */
+/*
+ * hugepages at page global directory. If arch support
+ * hugepages at pgd level, they need to define this.
+ */
+#ifndef pgd_huge
+#define pgd_huge(x)0
+#endif
+
+#ifndef is_hugepd
+/*
+ * Some architectures requires a hugepage directory format that is
+ * required to support multiple hugepage sizes. For example
+ * a4fe3ce7699bfe1bd88f816b55d42d8fe1dac655 introduced the same
+ * on powerpc. This allows for a more flexible hugepage pagetable
+ * layout.
+ */
+typedef struct { unsigned long pd; } hugepd_t;
+#define is_hugepd(hugepd) (0)
+#define __hugepd(x) ((hugepd_t) { (x) })
+static inline int gup_huge_pd(hugepd_t hugepd, unsigned long addr,
+ unsigned pdshift, unsigned long end,
+ int write, struct page **pages, int *nr)
+{
+ return 0;
+}
+#else
+extern int gup_huge_pd(hugepd_t hugepd, unsigned long addr,
+ unsigned pdshift, unsigned long end,
+ int write, struct page **pages, int *nr);
+#endif
#define HUGETLB_ANON_FILE "anon_hugepage"
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 02d11ee..31d7fac 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1219,6 +1219,13 @@ long get_user_pages(struct task_struct *tsk, struct
mm_struct *mm,
struct vm_area_struct **vmas);
int get_user_pages_fast(unsigned long start, int nr_pages, int write,
struct page **pages);
+
+#ifdef CONFIG_HAVE_GENERIC_RCU_GUP
+extern int gup_huge_pte(pte_t orig, pte_t *ptep, unsigned long addr,
+ unsigned long sz, unsigned long end, int write,
+ struct page **pages, int *nr);
+#endif
+
struct kvec;
int get_kernel_pages(const struct kvec *iov, int nr_pages, int write,
struct page **pages);
diff --git a/mm/gup.c b/mm/gup.c
index cd62c8c..30773f3 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -786,65 +786,31 @@ static int gup_pte_range(pmd_t pmd, unsigned long addr,
unsigned long end,
}
#endif /* __HAVE_ARCH_PTE_SPECIAL */
-static int gup_huge_pmd(pmd_t orig, pmd_t *pmdp, unsigned long addr,
- unsigned long end, int write, struct page **pages, int *nr)
+int gup_huge_pte(pte_t orig, pte_t *ptep, unsigned long addr,
+unsigned long sz, unsigned long end, int write,
+struct page **pages, int *nr)
{
- struct page *head, *page, *tail;
int refs;
+ unsigned long pte_end;
+ struct page *head, *page, *tail;
-
Re: localed stuck in recent 3.18 git in copy_net_ns?
On Fri, Oct 24, 2014 at 09:33:33PM -0700, Jay Vosburgh wrote: > Paul E. McKenney wrote: > > >On Fri, Oct 24, 2014 at 05:20:48PM -0700, Jay Vosburgh wrote: > >> Paul E. McKenney wrote: > >> > >> >On Fri, Oct 24, 2014 at 03:59:31PM -0700, Paul E. McKenney wrote: > >> [...] > >> >> Hmmm... It sure looks like we have some callbacks stuck here. I > >> >> clearly > >> >> need to take a hard look at the sleep/wakeup code. > >> >> > >> >> Thank you for running this!!! > >> > > >> >Could you please try the following patch? If no joy, could you please > >> >add rcu:rcu_nocb_wake to the list of ftrace events? > >> > >>I tried the patch, it did not change the behavior. > >> > >>I enabled the rcu:rcu_barrier and rcu:rcu_nocb_wake tracepoints > >> and ran it again (with this patch and the first patch from earlier > >> today); the trace output is a bit on the large side so I put it and the > >> dmesg log at: > >> > >> http://people.canonical.com/~jvosburgh/nocb-wake-dmesg.txt > >> > >> http://people.canonical.com/~jvosburgh/nocb-wake-trace.txt > > > >Thank you again! > > > >Very strange part of the trace. The only sign of CPU 2 and 3 are: > > > >ovs-vswitchd-902 [000] 109.896840: rcu_barrier: rcu_sched Begin > > cpu -1 remaining 0 # 0 > >ovs-vswitchd-902 [000] 109.896840: rcu_barrier: rcu_sched Check > > cpu -1 remaining 0 # 0 > >ovs-vswitchd-902 [000] 109.896841: rcu_barrier: rcu_sched Inc1 > > cpu -1 remaining 0 # 1 > >ovs-vswitchd-902 [000] 109.896841: rcu_barrier: rcu_sched > > OnlineNoCB cpu 0 remaining 1 # 1 > >ovs-vswitchd-902 [000] d... 109.896841: rcu_nocb_wake: rcu_sched 0 > > WakeNot > >ovs-vswitchd-902 [000] 109.896841: rcu_barrier: rcu_sched > > OnlineNoCB cpu 1 remaining 2 # 1 > >ovs-vswitchd-902 [000] d... 109.896841: rcu_nocb_wake: rcu_sched 1 > > WakeNot > >ovs-vswitchd-902 [000] 109.896842: rcu_barrier: rcu_sched > > OnlineNoCB cpu 2 remaining 3 # 1 > >ovs-vswitchd-902 [000] d... 109.896842: rcu_nocb_wake: rcu_sched 2 > > WakeNotPoll > >ovs-vswitchd-902 [000] 109.896842: rcu_barrier: rcu_sched > > OnlineNoCB cpu 3 remaining 4 # 1 > >ovs-vswitchd-902 [000] d... 109.896842: rcu_nocb_wake: rcu_sched 3 > > WakeNotPoll > >ovs-vswitchd-902 [000] 109.896843: rcu_barrier: rcu_sched Inc2 > > cpu -1 remaining 4 # 2 > > > >The pair of WakeNotPoll trace entries says that at that point, RCU believed > >that the CPU 2's and CPU 3's rcuo kthreads did not exist. :-/ > > On the test system I'm using, CPUs 2 and 3 really do not exist; > it is a 2 CPU system (Intel Core 2 Duo E8400). I mentioned this in an > earlier message, but perhaps you missed it in the flurry. Or forgot it. Either way, thank you for reminding me. > Looking at the dmesg, the early boot messages seem to be > confused as to how many CPUs there are, e.g., > > [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 > [0.00] Hierarchical RCU implementation. > [0.00] RCU debugfs-based tracing is enabled. > [0.00] RCU dyntick-idle grace-period acceleration is enabled. > [0.00] RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=4. > [0.00] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 > [0.00] NR_IRQS:16640 nr_irqs:456 0 > [0.00] Offload RCU callbacks from all CPUs > [0.00] Offload RCU callbacks from CPUs: 0-3. > > but later shows 2: > > [0.233703] x86: Booting SMP configuration: > [0.236003] node #0, CPUs: #1 > [0.255528] x86: Booted up 1 node, 2 CPUs > > In any event, the E8400 is a 2 core CPU with no hyperthreading. Well, this might explain some of the difficulties. If RCU decides to wait on CPUs that don't exist, we will of course get a hang. And rcu_barrier() was definitely expecting four CPUs. So what happens if you boot with maxcpus=2? (Or build with CONFIG_NR_CPUS=2.) I suspect that this might avoid the hang. If so, I might have some ideas for a real fix. Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vmalloced stacks on x86_64?
On Oct 24, 2014 7:38 PM, "H. Peter Anvin" wrote: > > On 10/24/2014 05:22 PM, Andy Lutomirski wrote: > > Is there any good reason not to use vmalloc for x86_64 stacks? > > Additional TLB pressure if anything else. I wonder how much this matters. It certainly helps on context switches if the new stack is in the same TLB entry. But, for entries that use less than one page of stack, I can imagine this making almost no difference. > > Now, on the flipside: what is the *benefit*? Immediate exception on overflow, and no high order allocation issues. The former is a nice mitigation against exploits based on overflowing the stack. --Andy > > -hpa > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 21/29] nios2: Time keeping
On Fri, 24 Oct 2014, Ley Foon Tan wrote:
> +#ifndef _ASM_NIOS2_TIMEX_H
> +#define _ASM_NIOS2_TIMEX_H
> +
> +typedef unsigned long cycles_t;
> +
> +extern cycles_t get_cycles(void);
> +
> +#define ARCH_HAS_READ_CURRENT_TIMER
Why does NIOS need that? Does it have a hardware implementation
dependent clock frequency which needs to be calibrated at boot time?
> +struct nios2_clockevent_dev {
> + struct nios2_timer timer;
> + struct clock_event_device ced;
> + struct irqaction irqaction;
> +};
Why does this need its private irqaction? Timers are setup after the
interrupt subsystem, so request_irq() is good enough.
> +static void nios2_timer_config(struct nios2_timer *timer, unsigned long
> period,
> + enum clock_event_mode mode)
> +{
> + u16 ctrl;
> +
> + /* The timer's actual period is one cycle greater than the value
> + * stored in the period register. */
> + if (period)
> + period--;
Pointless conditional. Set ce->min_delta_ticks to 1, so the core code
will never call this with period == 0 and you can unconditionally
decrement period.
> +static __init void nios2_clockevent_init(struct device_node *timer)
> +{
> + struct nios2_clockevent_dev *ce;
> + void __iomem *iobase;
> + u32 freq;
> + int irq;
> +
> + ce = kzalloc(sizeof(*ce), GFP_KERNEL);
> + if (!ce)
> + panic("Failed to allocate memory for %s\n", timer->name);
What's the point of this allocation? You only install one of those, so
you can really make that whole thing statically allocated and
initialized. Or do you expect systems which use a different timer IP
for this?
> +static __init void nios2_clocksource_init(struct device_node *timer)
> +{
> + unsigned int ctrl;
> + void __iomem *iobase;
> + u32 freq;
> +
> + nios2_cs = kzalloc(sizeof(*nios2_cs), GFP_KERNEL);
> + if (!nios2_cs)
> + panic("Failed to allocate memory for %s\n", timer->name);
Ditto.
> +/*
> + * The first timer instance will use as a clockevent. If there are two or
> + * more instances, the second one gets used as clocksource and all
> + * others are unused.
> +*/
> +static int num_called;
This thing, horrible as it is, wants to be at least inside the
nios2_time_init() function. It has no other scope and should go away
after init along with the function itself.
> +static void __init nios2_time_init(struct device_node *timer)
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] drivers: net: xgene: Rewrite buggy loop in xgene_enet_ecc_init()
From: Geert Uytterhoeven
Date: Thu, 23 Oct 2014 10:25:53 +0200
> drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c: In function
> ‘xgene_enet_ecc_init’:
> drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:126: warning: ‘data’ may be
> used uninitialized in this function
>
> Depending on the arbitrary value on the stack, the loop may terminate
> too early, and cause a bogus -ENODEV failure.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> v3:
> - Use "do { ... } while (...);" instead of "for (...) { ... }",
> v2:
> - Rewrite the loop instead of pre-initializing data.
Applied, thank you.
N§²ζμrΈyϊθΨb²X¬ΆΗ§vΨ^)ήΊ{.nΗ+·₯{±κηzX§Ά‘ά¨}©²Ζ
zΪ:+v¨Ύ«κηzZ+Κ+zf£’·h§~Ϋi�ϋΰzΉ �w₯’Έ?¨θΪ&’)ί’fω^jΗ«y§m
α@A«aΆΪ�
0Άμh�εi
Re: [PATCH 1/1] W1: ds2490: Increase timeout when waiting for status
Hi everyone This looks good to me Greg, please pull it into your tree Thank you 25.10.2014, 16:27, "Alexander Stein" : > Adjust the bulk message timeout to the other ones (1000ms). Otherwise the > following dmesg errors can be seen on a Raspberry Pi: > [ 31.492386] Failed to read 1-wire data from 0x81: err=-110. > [ 31.504168] 0x81: count=-110, status: > [ 31.613404] Failed to read 1-wire data from 0x81: err=-110. > [ 31.621915] 0x81: count=-110, status: > [ 43.260968] Failed to read 1-wire data from 0x81: err=-110. > [ 43.270998] 0x81: count=-110, status: > [ 43.379959] Failed to read 1-wire data from 0x81: err=-110. > [ 43.388854] 0x81: count=-110, status: > > Signed-off-by: Alexander Stein Acked-by: Evgeniy Polyakov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/2] mm: Update generic gup implementation to handle hugepage directory
David Miller writes: > Hey guys, was looking over the generic GUP while working on a sparc64 > issue and I noticed that you guys do speculative page gets, and after > talking with Johannes Weiner (CC:'d) about this we don't see how it > could be necessary. > > If interrupts are disabled during the page table scan (which they > are), no IPI tlb flushes can arrive. Therefore any removal from the > page tables is guarded by interrupts being re-enabled. And as a > result, page counts of pages we see in the page tables must always > have a count > 0. > > x86 does direct atomic_add() on >_count because of this > invariant and I would rather see the generic version do this too. But that won't work with RCU GUP. For example on powerpc the tlb flush doesn't involve an IPI and we can essentially find page count 0. -aneesh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging:rtl8723au:core brace issue
On Sat, Oct 25, 2014 at 12:22:32AM +0100, Paul McQuade wrote:
> ERROR: that open brace { should be on the previous line
patch is corrupt.
thanks
sudip
>
> Signed-off-by: Paul McQuade
> ---
> drivers/staging/rtl8723au/core/rtw_ap.c | 137
> ++--
> 1 file changed, 43 insertions(+), 94 deletions(-)
>
> diff --git a/drivers/staging/rtl8723au/core/rtw_ap.c
> b/drivers/staging/rtl8723au/core/rtw_ap.c
> index 6b4092f..fd36be4 100644
> --- a/drivers/staging/rtl8723au/core/rtw_ap.c
> +++ b/drivers/staging/rtl8723au/core/rtw_ap.c
> @@ -231,12 +231,10 @@ voidexpire_timeout_chk23a(struct rtw_adapter
> *padapter)
> psta->expire_to--;
> }
>
> - if (psta->expire_to <= 0)
> - {
> + if (psta->expire_to <= 0) {
> struct mlme_ext_priv *pmlmeext = >mlmeextpriv;
>
> - if (padapter->registrypriv.wifi_spec == 1)
> - {
> + if (padapter->registrypriv.wifi_spec == 1) {
> psta->expire_to = pstapriv->expire_to;
> continue;
> }
> @@ -308,15 +306,13 @@ voidexpire_timeout_chk23a(struct rtw_adapter
> *padapter)
> ret = issue_nulldata23a(padapter, psta->hwaddr, 0, 3,
> 50);
>
> psta->keep_alive_trycnt++;
> - if (ret == _SUCCESS)
> - {
> + if (ret == _SUCCESS) {
> DBG_8723A("asoc check, sta(" MAC_FMT ") is alive\n",
> MAC_ARG(psta->hwaddr));
> psta->expire_to = pstapriv->expire_to;
> psta->keep_alive_trycnt = 0;
> continue;
> - }
> - else if (psta->keep_alive_trycnt <= 3)
> - {
> + } else if (psta->keep_alive_trycnt <= 3) {
> DBG_8723A("ack check for asoc expire, keep_alive_trycnt
> =%d\n", psta->keep_alive_trycnt);
> psta->expire_to = 1;
> continue;
> @@ -363,8 +359,7 @@ void add_RATid23a(struct rtw_adapter *padapter, struct
> sta_info *psta, u8 rssi_l
> return;
>
> /* b/g mode ra_bitmap */
> - for (i = 0; i < sizeof(psta->bssrateset); i++)
> - {
> + for (i = 0; i < sizeof(psta->bssrateset); i++) {
> if (psta->bssrateset[i])
> tx_ra_bitmap |=
> rtw_get_bit_value_from_ieee_value23a(psta->bssrateset[i]&0x7f);
> }
> @@ -406,8 +401,7 @@ void add_RATid23a(struct rtw_adapter *padapter, struct
> sta_info *psta, u8 rssi_l
> raid = networktype_to_raid23a(sta_band);
> init_rate = get_highest_rate_idx23a(tx_ra_bitmap&0x0fff)&0x3f;
>
> - if (psta->aid < NUM_STA)
> - {
> + if (psta->aid < NUM_STA) {
> u8 arg = 0;
>
> arg = psta->mac_id&0x1f;
> @@ -436,9 +430,7 @@ void add_RATid23a(struct rtw_adapter *padapter, struct
> sta_info *psta, u8 rssi_l
> psta->raid = raid;
> psta->init_rate = init_rate;
>
> - }
> - else
> - {
> + } else {
> DBG_8723A("station aid %d exceed the max number\n", psta->aid);
> }
> }
> @@ -453,8 +445,7 @@ static void update_bmc_sta(struct rtw_adapter *padapter)
> struct wlan_bssid_ex *pcur_network = >cur_network.network;
> struct sta_info *psta = rtw_get_bcmc_stainfo23a(padapter);
>
> - if (psta)
> - {
> + if (psta) {
> psta->aid = 0;/* default set to 0 */
> psta->mac_id = psta->aid + 1;
>
> @@ -474,8 +465,7 @@ static void update_bmc_sta(struct rtw_adapter *padapter)
> psta->bssratelen = supportRateNum;
>
> /* b/g mode ra_bitmap */
> - for (i = 0; i < supportRateNum; i++)
> - {
> + for (i = 0; i < supportRateNum; i++) {
> if (psta->bssrateset[i])
> tx_ra_bitmap |=
> rtw_get_bit_value_from_ieee_value23a(psta->bssrateset[i]&0x7f);
> }
> @@ -522,9 +512,7 @@ static void update_bmc_sta(struct rtw_adapter *padapter)
> psta->state = _FW_LINKED;
> spin_unlock_bh(>lock);
>
> - }
> - else
> - {
> + } else {
> DBG_8723A("add_RATid23a_bmc_sta error!\n");
> }
> }
> @@ -561,8 +549,7 @@ void update_sta_info23a_apmode23a(struct rtw_adapter
> *padapter, struct sta_info
> /* ERP */
> VCS_update23a(padapter, psta);
> /* HT related cap */
> - if (phtpriv_sta->ht_option)
> - {
> + if (phtpriv_sta->ht_option) {
> /* check if sta supports rx ampdu */
> phtpriv_sta->ampdu_enable = phtpriv_ap->ampdu_enable;
>
> @@ -580,9 +567,7 @@ void update_sta_info23a_apmode23a(struct rtw_adapter
> *padapter, struct sta_info
>
> psta->qos_option = true;
>
> - }
> - else
> -
Re: [PATCH v5 01/29] asm-generic: add generic futex for !CONFIG_SMP
B1;2802;0cOn Fri, 24 Oct 2014, Ley Foon Tan wrote:
> +#ifndef CONFIG_SMP
> +static inline int
> +futex_atomic_op_inuser(int encoded_op, u32 __user *uaddr)
If we add this to the generic code we want to have a proper docbook
comment describing the function.
> +{
> + int op = (encoded_op >> 28) & 7;
> + int cmp = (encoded_op >> 24) & 15;
> + int oparg = (encoded_op << 8) >> 20;
> + int cmparg = (encoded_op << 20) >> 20;
> + int oldval, ret;
> + u32 tmp;
> +
> + if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28))
> + oparg = 1 << oparg;
> +
> + pagefault_disable();/* implies preempt_disable() */
Now this mindlessly copied comment does not have any real value.
1) That pagefault_disable() implies preempt_disable() is an
implementation detail which is not guaranteed to be true forever.
2) It's not telling at all, that this code really relies on both
pagefault AND preemption being disabled.
> +
> +static inline int
> +futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
> + u32 oldval, u32 newval)
> +{
Docbook comment missing as well. But what's worse is, that it does not
explain what the calling convention for this function is.
As above it requires both pagefault AND preemption being disabled. The
fact that both are the same are again just an implementation detail of
todays code
> + u32 val;
> +
> + if (unlikely(get_user(val, uaddr) != 0))
> + return -EFAULT;
> +
> + if (val == oldval && unlikely(put_user(newval, uaddr) != 0))
> + return -EFAULT;
> +
> + *uval = val;
> +
> + return 0;
> +}
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: drivers: random: Shift out-of-bounds in _mix_pool_bytes
2014-10-25 23:30 GMT+03:00 One Thousand Gnomes :
> On Fri, 24 Oct 2014 20:50:46 -0400
> Sasha Levin wrote:
>
>> On 10/24/2014 06:22 PM, H. Peter Anvin wrote:
>> >> By the principle of least surprise, I would expect "__u32 >> N", where
>> >> > N >= 32 to return zero instead of random garbage. For N < 32 it will
>> >> > return progressively smaller numbers, until it has shifted away all of
>> >> > the set bits, at which turn it will return 0. For it suddenly to jump
>> >> > up once N = 32 is used, is counter-intuitive.
>> >> >
>> > That's why it is undefined.
>>
>> Now I'm curious about things like "memcpy(ptr, NULL, 0)". According to the
>> standard they're undefined, and since we're using gcc's implementation for
>> memcpy() we are doing "undefined memcpy" in quite a few places in the kernel.
>>
>> Is it an issue, or would you expect memcpy() to not deref the "from" ptr
>> since length is 0?
>
> No. Furthermore gcc 4.9 actually has optimiser magic around this. See the
> "Porting to gcc 4.9" notes.
>
>
>
> GCC might now optimize away the null pointer check in code like:
>
>
> int copy (int* dest, int* src, size_t nbytes) {
> memmove (dest, src, nbytes);
> if (src != NULL)
> return *src;
> return 0;
> }
>
> The pointers passed to memmove (and similar functions in ) must
> be non-null even when nbytes==0, so GCC can use that information to
> remove the check after the memmove call. Calling copy(p, NULL, 0) can
> therefore deference a null pointer and crash.
>
> -
>
> Which is unfortunate because an operating system has a lot of legitimate
> reasons to copy data to address 0 (on many processors its the exception
> vectors for example)
That is why kernel builds with -fno-delete-null-pointer-checks.
>
> Alan
--
Best regards,
Andrey Ryabinin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.17.0+ files disappearing after playing old dos game on nfsroot laptop
On 10/24/2014 08:18 PM, Eric W. Biederman wrote: Hans de Bruin writes: On 10/19/2014 07:32 PM, Hans de Bruin wrote: On 10/15/2014 10:00 PM, Hans de Bruin wrote: After playing an old dos game i am missing files on my nfsroot installed laptop. Which one, wel /bin/ls is at least one of them. After a reboot there all back again. But not al is well. Some icons on my kde panel where gone. I have seen this twice in the last day's The problem appears immediately after starting dosemu so this bisectable My bisect ended here: commit 8ed936b5671bfb33d89bc60bdcc7cf0470ba52fe Author: Eric W. Biederman Date: Tue Oct 1 18:33:48 2013 -0700 vfs: Lazily remove mounts on unlinked files and directories. I haven reverted it yet. Eric, Immediately after starting dosemu all files under mount point /usr are gone. When I play a old dos game for a while (binaries are under /home) even /bin/ls disappears. Al mounts are nfs, even /. Could you look in to this and cc this to the relevant kernel mailinglist? At this point I don't know enough to reproduce this. What does /proc/mounts look like before you start dosemu? bash-4.2$ cat /proc/mounts rootfs / rootfs rw 0 0 10.10.0.1:/nfs/root/psion_14.1 / nfs rw,relatime,vers=3,rsize=4096,wsize=4096,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.10.0.1,mountvers=3,mountproto=tcp,local_lock=all,addr=10.10.0.1 0 0 devtmpfs /dev devtmpfs rw,relatime,size=1031016k,nr_inodes=220978,mode=755 0 0 proc /proc proc rw,relatime 0 0 sysfs /sys sysfs rw,relatime 0 0 tmpfs /run tmpfs rw,relatime,mode=755 0 0 devpts /dev/pts devpts rw,relatime,gid=5,mode=620 0 0 cgroup /sys/fs/cgroup cgroup rw,relatime,cpu 0 0 /dev/shm /tmp tmpfs rw,relatime,size=524288k 0 0 /dev/shm /dev/shm tmpfs rw,relatime,size=524288k 0 0 nfs:/nfs/usr/slackware-14.1/usr /usr nfs ro,relatime,vers=3,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.10.0.1,mountvers=3,mountport=38337,mountproto=udp,local_lock=none,addr=10.10.0.1 0 0 nfs:/nfs/home /home nfs rw,relatime,vers=3,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.10.0.1,mountvers=3,mountport=38337,mountproto=udp,local_lock=none,addr=10.10.0.1 0 0 nfs:/nfs/mp3 /mp3 nfs rw,relatime,vers=3,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.10.0.1,mountvers=3,mountport=38337,mountproto=udp,local_lock=none,addr=10.10.0.1 0 0 nfs:/nfs/src /usr/src nfs rw,relatime,vers=3,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.10.0.1,mountvers=3,mountport=38337,mountproto=udp,local_lock=none,addr=10.10.0.1 0 0 nfs:/nfs/video /video nfs rw,relatime,vers=3,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.10.0.1,mountvers=3,mountport=38337,mountproto=udp,local_lock=none,addr=10.10.0.1 0 0 I now know why I do not see any file in /usr after running dosemu. The whole /usr mount disappears in /proc/mounts. When I remount it I have a usable laptop again. Running dosemu a second time does not remove the mount again. In the mean time I have seen /usr disappear after running other programs like xterm and firefox. But until now never after remouting it. My expectation is that you should only see this if the mount points are removed on the nfs server (which does not sound like it is the case). This is a at home environment with a nfs server in the meter cupboard. I have not changed the exports. Although a transient malfunction of the nfs server or misplaced call to check_submounts_and_drop could cause mounts to disappear as well. During testing autofs was observed to have an inappropriate call I am not using autofs to d_invalidate and it is unlikely but possible something like that is going on with nfs as well. Are your nfs mounts read-only or read-write? /usr is mounted ro and exported ro What is your nfs-server and what is it exporting? Which distro are you running? The nfs-server is slackware64 14.0 with a 3.4 kernel part from exports: /nfs/usr -ro,async,no_subtree_check 10.10.0.0/16 The laptop is slackware(32 bit) 14.1 with yesterday's linus kernel Which version of dosemu are you running? 1.4.0.8 How is dosemu configured to access files on your filesystem? I do not understand what you mean by this. It uses ~/.dosemu/drive_c -- Hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] genirq: Add support for priority-drop/deactivate interrupt controllers
On Sat, 25 Oct 2014, Thomas Gleixner wrote: > Can you please explain detailed how this "priority drop" mode > works? And I mean how it works from all aspects, not only from handling the interrupt itself. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RCU fanout leaf balancing
Hi Paul, Finding earlier reference to increasing RCU fanout leaf for the purpose of "decrease[ing] cache-miss overhead for large systems", would your suggestion be to increase the value to the next hierarchy core-count above 16? If we have say 32 interconnected 48-core servers; 3 sockets of dual-node 8-core Opteron 6300s, so 1536 cores in all. Latency across the coherent interconnect is O(100x) higher than the internal Hypertransport interconnect, so if we set RCU_FANOUT_LEAF to 48 to keep leaf-checking local to one Hypertransport fabric, what wisdom would one use for RCU_FANOUT? 4x leaf? Or, would it be more cache-friendly to set RCU_FANOUT_LEAF to 8 and RCU_FANOUT to 48? Many thanks, Daniel -- Daniel J Blueman Principal Software Engineer, Numascale -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] bcma: fix build when CONFIG_OF_ADDRESS is not set
On Thu, Oct 09, 2014 at 11:39:41PM +0200, Hauke Mehrtens wrote:
> Commit 2101e533f41a ("bcma: register bcma as device tree driver")
> introduces a hard dependency on OF_ADDRESS into the bcma driver.
> OF_ADDRESS is specifically disabled for the sparc architecture.
> This results in the following error when building sparc64:allmodconfig.
>
> drivers/bcma/main.c: In function 'bcma_of_find_child_device':
> drivers/bcma/main.c:150:3: error: implicit declaration of function
> 'of_translate_address'
>
> Fixes: 2101e533f41a ("bcma: register bcma as device tree driver")
> Reported-by: Guenter Roeck
> Signed-off-by: Hauke Mehrtens
The upstream kernel still does not include this patch, and the sparc64 build
is still broken.
Is this patch on its way upstream ?
Guenter
> ---
> drivers/bcma/main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
> index d1656c2..1000955 100644
> --- a/drivers/bcma/main.c
> +++ b/drivers/bcma/main.c
> @@ -132,7 +132,7 @@ static bool bcma_is_core_needed_early(u16 core_id)
> return false;
> }
>
> -#ifdef CONFIG_OF
> +#if defined(CONFIG_OF) && defined(CONFIG_OF_ADDRESS)
> static struct device_node *bcma_of_find_child_device(struct platform_device
> *parent,
>struct bcma_device *core)
> {
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: drivers: random: Shift out-of-bounds in _mix_pool_bytes
On Fri, 24 Oct 2014 20:50:46 -0400
Sasha Levin wrote:
> On 10/24/2014 06:22 PM, H. Peter Anvin wrote:
> >> By the principle of least surprise, I would expect "__u32 >> N", where
> >> > N >= 32 to return zero instead of random garbage. For N < 32 it will
> >> > return progressively smaller numbers, until it has shifted away all of
> >> > the set bits, at which turn it will return 0. For it suddenly to jump
> >> > up once N = 32 is used, is counter-intuitive.
> >> >
> > That's why it is undefined.
>
> Now I'm curious about things like "memcpy(ptr, NULL, 0)". According to the
> standard they're undefined, and since we're using gcc's implementation for
> memcpy() we are doing "undefined memcpy" in quite a few places in the kernel.
>
> Is it an issue, or would you expect memcpy() to not deref the "from" ptr
> since length is 0?
No. Furthermore gcc 4.9 actually has optimiser magic around this. See the
"Porting to gcc 4.9" notes.
GCC might now optimize away the null pointer check in code like:
int copy (int* dest, int* src, size_t nbytes) {
memmove (dest, src, nbytes);
if (src != NULL)
return *src;
return 0;
}
The pointers passed to memmove (and similar functions in ) must
be non-null even when nbytes==0, so GCC can use that information to
remove the check after the memmove call. Calling copy(p, NULL, 0) can
therefore deference a null pointer and crash.
-
Which is unfortunate because an operating system has a lot of legitimate
reasons to copy data to address 0 (on many processors its the exception
vectors for example)
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.17.0+ files disappearing after playing old dos game on nfsroot laptop
Hans de Bruin writes: > On 10/24/2014 08:18 PM, Eric W. Biederman wrote: [...] >> At this point I don't know enough to reproduce this. >> What does /proc/mounts look like before you start dosemu? > > bash-4.2$ cat /proc/mounts > rootfs / rootfs rw 0 0 > 10.10.0.1:/nfs/root/psion_14.1 / nfs > rw,relatime,vers=3,rsize=4096,wsize=4096,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.10.0.1,mountvers=3,mountproto=tcp,local_lock=all,addr=10.10.0.1 > 0 0 > devtmpfs /dev devtmpfs rw,relatime,size=1031016k,nr_inodes=220978,mode=755 0 0 > proc /proc proc rw,relatime 0 0 > sysfs /sys sysfs rw,relatime 0 0 > tmpfs /run tmpfs rw,relatime,mode=755 0 0 > devpts /dev/pts devpts rw,relatime,gid=5,mode=620 0 0 > cgroup /sys/fs/cgroup cgroup rw,relatime,cpu 0 0 > /dev/shm /tmp tmpfs rw,relatime,size=524288k 0 0 > /dev/shm /dev/shm tmpfs rw,relatime,size=524288k 0 0 > nfs:/nfs/usr/slackware-14.1/usr /usr nfs > ro,relatime,vers=3,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.10.0.1,mountvers=3,mountport=38337,mountproto=udp,local_lock=none,addr=10.10.0.1 > 0 0 > nfs:/nfs/home /home nfs > rw,relatime,vers=3,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.10.0.1,mountvers=3,mountport=38337,mountproto=udp,local_lock=none,addr=10.10.0.1 > 0 0 > nfs:/nfs/mp3 /mp3 nfs > rw,relatime,vers=3,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.10.0.1,mountvers=3,mountport=38337,mountproto=udp,local_lock=none,addr=10.10.0.1 > 0 0 > nfs:/nfs/src /usr/src nfs > rw,relatime,vers=3,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.10.0.1,mountvers=3,mountport=38337,mountproto=udp,local_lock=none,addr=10.10.0.1 > 0 0 > nfs:/nfs/video /video nfs > rw,relatime,vers=3,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.10.0.1,mountvers=3,mountport=38337,mountproto=udp,local_lock=none,addr=10.10.0.1 > 0 0 > > I now know why I do not see any file in /usr after running dosemu. The whole > /usr mount disappears in /proc/mounts. When I remount it I have a usable > laptop > again. Running dosemu a second time does not remove the mount again. In the > mean > time I have seen /usr disappear after running other programs like xterm and > firefox. But until now never after remouting it. That is interesting. It sounds like occassionally your /home mount disappears as well. Both of those would be consistent with my patch working doing what it was designed to do. My guess is that your nfs mount on / is being weird, and causing valid directory dentries (AKA /usr and /home) to disappear temporariliy, and it looks like my change is magnifying that weirdness by causing the mounts on those directory entries to disappear. What I don't understand is exactly why nfs is being weird that way yet. I expect what needs to happen is to confirm that nfs directory entry revalidation is buggy, and at least for the short term re-add the nfs logic that will avoid dropping a dentry if it is a mount point, or path to a mount point, to avoid the nfs bugs. >> My expectation is that you should only see this if the mount points are >> removed on the nfs server (which does not sound like it is the case). > > This is a at home environment with a nfs server in the meter cupboard. I have > not changed the exports. On the nfs server doing "rmdir .../nfs/posion_14.1/home" or "rmdir .../nfs/posion_14.1/usr" should cause the behavior you are seeing. As that you aren't doing that something is weird is going on. >> Although a transient malfunction of the nfs server or misplaced call to >> check_submounts_and_drop could cause mounts to disappear as well. >> During testing autofs was observed to have an inappropriate call > > I am not using autofs I mentioned autofs because I think something similar is probably going on with nfs, as was observed with autofs. >> to d_invalidate and it is unlikely but possible something like >> that is going on with nfs as well. >> >> Are your nfs mounts read-only or read-write? > /usr is mounted ro and exported ro / is mounted read-write but that seems seems immaterial at the moment. >> What is your nfs-server and what is it exporting? >> Which distro are you running? > > The nfs-server is slackware64 14.0 with a 3.4 kernel > part from exports: > /nfs/usr -ro,async,no_subtree_check 10.10.0.0/16 > > The laptop is slackware(32 bit) 14.1 with yesterday's linus kernel > >> Which version of dosemu are you running? > > 1.4.0.8 Thanks that information helps. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] genirq: Add support for priority-drop/deactivate interrupt controllers
On Sat, 25 Oct 2014, Marc Zyngier wrote:
@@ -330,6 +330,7 @@ struct irq_chip {
void(*irq_mask)(struct irq_data *data);
void(*irq_mask_ack)(struct irq_data *data);
void(*irq_unmask)(struct irq_data *data);
+ void(*irq_priority_drop)(struct irq_data *data);
Lacks the docbook comment.
> +static void mask_threaded_irq(struct irq_desc *desc)
There is only one caller for this, i.e handle_fasteoi_irq, right? So
this should go to the other eoi handler specific helpers and have eoi
in its name.
> +{
> + struct irq_chip *chip = desc->irq_data.chip;
> +
> + /* If we can do priority drop, then masking comes for free */
> + if (chip->irq_priority_drop)
> + irq_state_set_masked(desc);
> + else
> + mask_irq(desc);
> +}
> void unmask_irq(struct irq_desc *desc)
> {
> - if (desc->irq_data.chip->irq_unmask) {
> - desc->irq_data.chip->irq_unmask(>irq_data);
> + struct irq_chip *chip = desc->irq_data.chip;
> +
> + if (chip->irq_unmask && !chip->irq_priority_drop)
> + chip->irq_unmask(>irq_data);
I have a hard time to understand that logic. Assume the interrupt
being masked at the hardware level after boot. Now at request_irq()
time what is going to unmask that very interrupt? Ditto for masking
after disable_irq(). Probably not what you really want.
> +static void eoi_irq(struct irq_desc *desc, struct irq_chip *chip)
> +{
> + if (chip->irq_priority_drop)
> + chip->irq_priority_drop(>irq_data);
> + if (chip->irq_eoi)
> + chip->irq_eoi(>irq_data);
> +}
So if you are using that priority drop stuff, you need both calls even
for the non threaded case?
> static void cond_unmask_eoi_irq(struct irq_desc *desc, struct irq_chip *chip)
> {
> if (!(desc->istate & IRQS_ONESHOT)) {
> - chip->irq_eoi(>irq_data);
> + eoi_irq(desc, chip);
> return;
> }
> +
> + if (chip->irq_priority_drop)
> + chip->irq_priority_drop(>irq_data);
> +
> /*
>* We need to unmask in the following cases:
>* - Oneshot irq which did not wake the thread (caused by a
> @@ -485,7 +507,8 @@ static void cond_unmask_eoi_irq(struct irq_desc *desc,
> struct irq_chip *chip)
> if (!irqd_irq_disabled(>irq_data) &&
> irqd_irq_masked(>irq_data) && !desc->threads_oneshot) {
> chip->irq_eoi(>irq_data);
> - unmask_irq(desc);
> + if (!chip->irq_priority_drop)
> + unmask_irq(desc);
This is really completely obfuscated: Brain starts melting and
spiraling towards some unidentified universe.
Seriously, I don't think it's a good idea to bandaid this
functionality into the existing handle_fasteoi_irq() mechanism. It's
complex enough already.
So what you really want is a separate handler for this. But aside of
adding the drop prio callback you probably want to handle the other
existing callbacks completely differently than for the regular mode of
that irq controller.
Can you please explain detailed how this "priority drop" mode
works?
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: vmalloced stacks on x86_64?
* Andy Lutomirski wrote: > Is there any good reason not to use vmalloc for x86_64 stacks? In addition to what hpa mentioned, __pa()/__va() on-kstack DMA gets tricky, for legacy drivers. (Not sure how many of these are left though.) Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Does spi-gpio and bitband support 3-wire Bidirectional most/miso share pin usage?
I have a device use 3-wire spi which are CS,SCK,and a DATA for read/write.( maybe a.s.k.a SISO) The command format like as p.18 in www .newhavendisplay .com/app_notes/NV3035C.pdf The spi-gpio can't register miso and mosi for same GPIO pin. Also I traced SPI-3WIRE flag it seems only support half 3-wire which only write or only read but share ping Does current driver can support this kind of 3wire spi format? Or I need to do some modify to support this 3-wire spi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/3] iio: exynos-adc: use syscon instead of ioremap
On 09/10/14 21:05, Jonathan Cameron wrote: > On 21/09/14 13:17, Jonathan Cameron wrote: >> On 16/09/14 09:58, Naveen Krishna Chatradhi wrote: >>> Changes since v1: >>> 1. Rebased on top of togreg branch of IIO git. >>> >>> This patch set does the following >>> 1. Use the syscon and Regmap API instead of ioremappaing the >>>ADC_PHY register from PMU. >>> 2. Updates the Documentation in exynos-adc.txt with syscon phandle >>>for the ADC nodes. >>> 3. Updates the Dts files for Exynos3250, Exynos4x12, Exynos5250, >>>Exynos5420 with the syscon phandle. >>> >>> Tested on Exynos5420 based Peach PIT and Exynos5800 based Peach PI >>> by verifying sysfs entries provided by HWMON based NTC thermistors. >>> >>> Tested-By for Exynos3250, Exynos4x12 would be appreciated. >> Would definitely be good! >> >> The main issue I have with this series is that it breaks backward >> compatibility with old device trees and newer kernels. >> >> Now I appreciate that sometimes there are reasons to do it but want this >> to have deeper consideration (and acks to show it) from the Exynos side >> of things and preferably from the device tree side of things as well. >> >> cc'd Kukjin Kim for the Exynos side of things as the listed Maintainer. >> >> Otherwise, the series looks fine to me. > Kukjin? Sorry to pester, but this has been sat in my waiting queue for a > while now. This is still sitting here waiting for those acks from Exynos side of things. I'm happy to let this sit indefinitely, but does seem a little silly. >>> >>> Naveen Krishna Chatradhi (3): >>> iio: exyno-adc: use syscon for PMU register access >>> Documentation: dt-bindings: update exynos-adc.txt with syscon handle >>> ARM: dts: exynos: Add sysreg phandle to ADC node >>> >>> .../devicetree/bindings/arm/samsung/exynos-adc.txt |9 -- >>> arch/arm/boot/dts/exynos3250.dtsi |3 +- >>> arch/arm/boot/dts/exynos4x12.dtsi |3 +- >>> arch/arm/boot/dts/exynos5250.dtsi |3 +- >>> arch/arm/boot/dts/exynos5420.dtsi |3 +- >>> drivers/iio/adc/exynos_adc.c | 30 >>> ++-- >>> 6 files changed, 36 insertions(+), 15 deletions(-) >>> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-iio" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] iio: iadc: Qualcomm SPMI PMIC current ADC driver
On 22/10/14 15:13, Ivan T. Ivanov wrote:
> The current ADC is peripheral of Qualcomm SPMI PMIC chips. It has
> 16 bits resolution and register space inside PMIC accessible across
> SPMI bus.
>
> The driver registers itself through IIO interface.
>
> Signed-off-by: Ivan T. Ivanov
Applied to the togreg branch of iio.git - initially pushed out
as testing for the autobuilders to play. It's been more than 3 weeks
without the device tree stuff changing.
If Mark or Hartmut want to offer a reviewed by in the next day or so
before I push this out as togreg then I'd be most happy to add them!
Thanks,
Jonathan
> ---
>
> Changes:
> - Address review comments from Hartmut Knaack
>
> .../devicetree/bindings/iio/adc/qcom,spmi-iadc.txt | 46 ++
> drivers/iio/adc/Kconfig| 14 +
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/qcom-spmi-iadc.c | 595
> +
> 4 files changed, 656 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.txt
> create mode 100644 drivers/iio/adc/qcom-spmi-iadc.c
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.txt
> b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.txt
> new file mode 100644
> index 000..4e36d6e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.txt
> @@ -0,0 +1,46 @@
> +Qualcomm's SPMI PMIC current ADC
> +
> +QPNP PMIC current ADC (IADC) provides interface to clients to read current.
> +A 16 bit ADC is used for current measurements. IADC can measure the current
> +through an external resistor (channel 1) or internal (built-in) resistor
> +(channel 0). When using an external resistor it is to be described by
> +qcom,external-resistor-micro-ohms property.
> +
> +IADC node:
> +
> +- compatible:
> +Usage: required
> +Value type:
> +Definition: Should contain "qcom,spmi-iadc".
> +
> +- reg:
> +Usage: required
> +Value type:
> +Definition: IADC base address and length in the SPMI PMIC register map
> +
> +- interrupts:
> +Usage: optional
> +Value type:
> +Definition: End of ADC conversion.
> +
> +- qcom,external-resistor-micro-ohms:
> +Usage: optional
> +Value type:
> +Definition: Sense resister value in micro Ohm.
> +If not defined value of 1 micro Ohms will be used.
> +
> +Example:
> + /* IADC node */
> + pmic_iadc: iadc@3600 {
> + compatible = "qcom,spmi-iadc";
> + reg = <0x3600 0x100>;
> + interrupts = <0x0 0x36 0x0 IRQ_TYPE_EDGE_RISING>;
> + qcom,external-resistor-micro-ohms = <1>;
> + #io-channel-cells = <1>;
> + };
> +
> + /* IIO client node */
> + bat {
> + io-channels = <_iadc 0>;
> + io-channel-names = "iadc";
> + };
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 88bdc8f..d0924f3 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -206,6 +206,20 @@ config NAU7802
> To compile this driver as a module, choose M here: the
> module will be called nau7802.
>
> +config QCOM_SPMI_IADC
> + tristate "Qualcomm SPMI PMIC current ADC"
> + depends on SPMI
> + select REGMAP_SPMI
> + help
> + This is the IIO Current ADC driver for Qualcomm QPNP IADC Chip.
> +
> + The driver supports single mode operation to read from one of two
> + channels (external or internal). Hardware have additional
> + channels internally used for gain and offset calibration.
> +
> + To compile this driver as a module, choose M here: the module will
> + be called qcom-spmi-iadc.
> +
> config ROCKCHIP_SARADC
> tristate "Rockchip SARADC driver"
> depends on ARCH_ROCKCHIP || (ARM && COMPILE_TEST)
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index cb88a6a..c06718b 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -22,6 +22,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o
> obj-$(CONFIG_MCP3422) += mcp3422.o
> obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
> obj-$(CONFIG_NAU7802) += nau7802.o
> +obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
> obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
> obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
> obj-$(CONFIG_TI_ADC128S052) += ti-adc128s052.o
> diff --git a/drivers/iio/adc/qcom-spmi-iadc.c
> b/drivers/iio/adc/qcom-spmi-iadc.c
> new file mode 100644
> index 000..b9666f2
> --- /dev/null
> +++ b/drivers/iio/adc/qcom-spmi-iadc.c
> @@ -0,0 +1,595 @@
> +/*
> + * Copyright (c) 2012-2014, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will
Re: [PATCH v2 2/3] ARM: keystone: pm: switch to use generic pm domains
On 24 October 2014 18:39, Dmitry Torokhov wrote:
> On Fri, Oct 24, 2014 at 11:53:05AM +0200, Ulf Hansson wrote:
>> On 23 October 2014 16:37, Grygorii Strashko wrote:
>> > Hi Ulf,
>> >
>> > On 10/23/2014 11:11 AM, Ulf Hansson wrote:
>> >> On 22 October 2014 17:44, Geert Uytterhoeven wrote:
>> >>> On Wed, Oct 22, 2014 at 5:28 PM, Ulf Hansson
>> >>> wrote:
>> On 22 October 2014 17:09, Geert Uytterhoeven
>> wrote:
>> > On Wed, Oct 22, 2014 at 5:01 PM, Ulf Hansson
>> > wrote:
>> > +void keystone_pm_domain_attach_dev(struct device *dev)
>> >{
>> > +struct clk *clk;
>> >int ret;
>> > +int i = 0;
>> >
>> >dev_dbg(dev, "%s\n", __func__);
>> >
>> > -ret = pm_generic_runtime_suspend(dev);
>> > -if (ret)
>> > -return ret;
>> > -
>> > -ret = pm_clk_suspend(dev);
>> > +ret = pm_clk_create(dev);
>> >if (ret) {
>> > -pm_generic_runtime_resume(dev);
>> > -return ret;
>> > +dev_err(dev, "pm_clk_create failed %d\n", ret);
>> > +return;
>> > +};
>> > +
>> > +while ((clk = of_clk_get(dev->of_node, i++)) && !IS_ERR(clk))
>> > {
>> > +ret = pm_clk_add_clk(dev, clk);
>> > +if (ret) {
>> > +dev_err(dev, "pm_clk_add_clk failed %d\n", ret);
>> > +goto clk_err;
>> > +};
>> >}
>> >
>> > -return 0;
>> > +if (!IS_ENABLED(CONFIG_PM_RUNTIME)) {
>> Can we not okkup two seperate callbacks instead of above check ?
>> I don't like this CONFIG check here. Its slightly better version of
>> ifdef in middle of the code.
>> >>>
>> >>> I've found more-less similar comment on patch
>> >>> "Re: [PATCH v3 1/3] power-domain: add power domain drivers for
>> >>> Rockchip platform"
>> >>> https://lkml.org/lkml/2014/10/17/257
>> >>>
>> >>> So, Would you like me to create patch which will enable clocks in
>> >>> pm_clk_add/_clk()
>> >>> in case !IS_ENABLED(CONFIG_PM_RUNTIME)
>> >>
>> >> I am wondering whether we actually should/could do this, no matter of
>> >> CONFIG_PM_RUNTIME.
>> >>
>> >> Typically, for configurations that uses CONFIG_PM_RUNTIME, the PM
>> >> clocks through pm_clk_suspend(), will be gated once the device becomes
>> >> runtime PM suspended. Right?
>> >
>> > Doing it unconditionally means we'll have lots of unneeded clocks
>> > running
>> > for a short while.
>> >>>
>> As long as the pm_clk_add() is being invoked from the ->attach_dev()
>> callback, we are in the probe path. Certainly we would like to have
>> clocks enabled while probing, don't you think?
>>
>> If we wouldn't enable the clocks for CONFIG_PM_RUNTIME, when will
>> those be enabled?
>> >>>
>> >>> They will be enabled when the driver does
>> >>>
>> >>> pm_runtime_enable(dev);
>> >>> pm_runtime_get_sync(dev);
>> >>>
>> >>> in its .probe() method.
>> >>
>> >> No! This doesn't work for drivers which have used
>> >> pm_runtime_set_active() prior pm_runtime_enable().
>> >
>> > Sorry, but some misunderstanding is here:
>> > 1) If some code call pm_runtime_set_active() it has to ensure
>> > that all PM resources switched to ON state. All! So, it will
>> > be ok to call enable & get after that - these functions will only
>> > adjust counters.
>>
>> Correct.
>>
>> This is also the key problem with your approach. You requires a
>> pm_runtime_get_sync() to trigger the runtime PM resume callbacks to be
>> invoked. That's a fragile design.
>
> Why is this fragile design? Having pm_runtime_get_sync() result in
> resuming the device (and in turn the PM domain it is in) if device is
> suspended is the proper behavior, no?
It's fragile, because the device may very well be "runtime PM active"
at the point when we invoke pm_runtime_get_sync(). Thus the runtime PM
resume callback isn't invoked, which is a requirement for these cases
to work.
Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5] timekeeping: Added a function to return tv_sec portion of ktime_get_ts64()
The following patch adds a function to return tv_sec portion of
ktime_get_ts64() function in order to have a function that returns
seconds as 64-bit integers instead of 32-bit integers to address the
y2038 problem.
Since we are interested only in the seconds portion of ktime_get_ts64()
and require this to be as fast as possible, we take the implementation
of ktime_get_ts64() as it is and remove everything pertaining to the
nanoseconds portion. We only add to the seconds calculation if the
calculation of nanoseconds is more than one billion nanoseconds. We
replace timekeeping_get_ns() which returns the exact nanoseconds value
with tk_xtime() that returns nanosecond value of the last timer tick
since we do not require such fine resolution for nanoseconds portion but
want the seconds to be returned as fast as possible.
Signed-off-by: Heena Sirwani
---
Changes in v5:
- Made the commit message more clear.
- Changed the type of variable ts from timespec64 to time64_t as
we do not use the tv_nsec portion.
- Changed the type of nsec from s64 to s32.
- replaced the value 10 with NSEC_PER_SEC.
include/linux/timekeeping.h |1 +
kernel/time/timekeeping.c | 25 +
2 files changed, 26 insertions(+)
diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index 1caa6b0..115d55e 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -28,6 +28,7 @@ struct timespec __current_kernel_time(void);
struct timespec get_monotonic_coarse(void);
extern void getrawmonotonic(struct timespec *ts);
extern void ktime_get_ts64(struct timespec64 *ts);
+extern time64_t ktime_get_seconds(void);
extern int __getnstimeofday64(struct timespec64 *tv);
extern void getnstimeofday64(struct timespec64 *tv);
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index ec1791f..93fc596 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -648,6 +648,31 @@ void ktime_get_ts64(struct timespec64 *ts)
}
EXPORT_SYMBOL_GPL(ktime_get_ts64);
+time64_t ktime_get_seconds(void)
+{
+ time64_t ts;
+ struct timekeeper *tk = _core.timekeeper;
+ struct timespec64 tomono;
+ s32 nsec;
+ unsigned int seq;
+
+ WARN_ON(timekeeping_suspended);
+
+ do {
+ seq = read_seqcount_begin(_core.seq);
+ ts = tk->xtime_sec;
+ nsec = (long)(tk->tkr.xtime_nsec >> tk->tkr.shift);
+ tomono = tk->wall_to_monotonic;
+
+ } while (read_seqcount_retry(_core.seq, seq));
+
+ ts += tomono.tv_sec;
+ if (nsec + tomono.tv_nsec >= NSEC_PER_SEC)
+ ts += 1;
+ return ts;
+}
+EXPORT_SYMBOL_GPL(ktime_get_seconds);
+
#ifdef CONFIG_NTP_PPS
/**
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 1/7] iio: dummy: Add virtual registers for dummy device
On Sat, Oct 25, 2014 at 10:49 PM, Hartmut Knaack wrote: > Jonathan Cameron schrieb am 25.10.2014 20:55: >> On 09/10/14 13:39, Daniel Baluta wrote: >>> We need a way to store events generated by iio_dummy_evgen module, >>> in order to correctly process IRQs in iio_simple_dummy_events. >>> >>> For the moment, we add two registers: >>> >>> * id_reg - ID register, stores the source of the event >>> * id_data - DATA register, stores the type of the event >>> >>> e.g echo 4 > /sys/bus/iio/devices/iio_evgen/poke2 >>> >>> id_reg 0x02, id_data 0x04 >>> >>> This means, event of type 4 was generated by fake device 2. >>> >>> We currently use a hardcoded mapping of virtual events to IIO events. >>> >>> Signed-off-by: Irina Tirdea >>> Signed-off-by: Daniel Baluta >> Applied to the togreg branch of iio.git. >> Initially pushed out as testing for the autobuilders to play with it. > I think Daniel wanted to work on a V3 for (at least) this one, fixing > variable type of ret from long to int in iio_evgen_poke(). Had spotted it in > V1, when V2 was already sent out - sorry for that. See [1]. Correct, I was just waiting on feedback for other patches. I will send v3 as soon as possible. thanks, Daniel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/14] KVM: x86: Emulator fixes for eip canonical checks on near branches
> On Oct 24, 2014, at 20:53, Andy Lutomirski wrote: > > On 10/24/2014 08:07 AM, Paolo Bonzini wrote: >> From: Nadav Amit >> >> Before changing rip (during jmp, call, ret, etc.) the target should be >> asserted >> to be canonical one, as real CPUs do. During sysret, both target rsp and rip >> should be canonical. If any of these values is noncanonical, a #GP exception >> should occur. The exception to this rule are syscall and sysenter >> instructions >> in which the assigned rip is checked during the assignment to the relevant >> MSRs. > > Careful here. AMD CPUs (IIUC) send #PF (or maybe #GP) from CPL3 instead > of #GP from CPL0 on sysret to a non-canonical address. That behavior is > *far* better than the Intel behavior, and it may be important. I wasn’t aware of this discrepancy, and it is really not written clearly in AMD manual (I have to take your word). It is possible AMD decided to inject #GP from CPL3 (#PF makes no sense). Anyhow, I think it is much harder to emulate AMD’s behaviour on Intel. Theoretically, the easy way would be for the host to set a non-canonical guest RIP/RSP and inject #GP, but Intel CPUs don’t allow the host to do so. Instead, the host needs to emulate the entire exception injection. This is very hard and error-prone process due to the variety of scenarios (interrupt/task-gate on the IDT, #DF, nested-exceptions, etc.) > > If an OS relies on that behavior on AMD CPUs, and guest ring 3 can force > guest ring 0 to do an emulated sysret to a non-canonical address, than > the guest ring3 code can own the guest ring0 code. > > —Andy Sysexit (I mistakenly wrote sysret on the description), out of all the control transfer instructions, seems the hardest to exploit, since it must be executed in CPL0. Remember that this bug does not result in host crashing, but in guest crashing: If guest userspace is able to cause KVM to emulate a jump instruction to a non-canonical address, it can crash the entire guest (by preventing VM-entry from succeeding). To use sysexit for such exploit, the guest userspace needs also to somehow fool the guest kernel into returning into non-canonical RIP. Nadav-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 1/7] iio: dummy: Add virtual registers for dummy device
HOn 25/10/14 20:49, Hartmut Knaack wrote:
> Jonathan Cameron schrieb am 25.10.2014 20:55:
>> On 09/10/14 13:39, Daniel Baluta wrote:
>>> We need a way to store events generated by iio_dummy_evgen module,
>>> in order to correctly process IRQs in iio_simple_dummy_events.
>>>
>>> For the moment, we add two registers:
>>>
>>> * id_reg - ID register, stores the source of the event
>>> * id_data - DATA register, stores the type of the event
>>>
>>> e.g echo 4 > /sys/bus/iio/devices/iio_evgen/poke2
>>>
>>> id_reg 0x02, id_data 0x04
>>>
>>> This means, event of type 4 was generated by fake device 2.
>>>
>>> We currently use a hardcoded mapping of virtual events to IIO events.
>>>
>>> Signed-off-by: Irina Tirdea
>>> Signed-off-by: Daniel Baluta
>> Applied to the togreg branch of iio.git.
>> Initially pushed out as testing for the autobuilders to play with it.
> I think Daniel wanted to work on a V3 for (at least) this one, fixing
> variable type of ret from long to int in iio_evgen_poke(). Had spotted it in
> V1, when V2 was already sent out - sorry for that. See [1].
>
> [1] http://marc.info/?l=linux-iio=141375116229102=2
Backed out. Thanks for letting me know.
>
>>> ---
>>> drivers/staging/iio/iio_dummy_evgen.c | 16
>>> drivers/staging/iio/iio_dummy_evgen.h | 6 ++
>>> drivers/staging/iio/iio_simple_dummy.h| 2 ++
>>> drivers/staging/iio/iio_simple_dummy_events.c | 23 ++-
>>> 4 files changed, 42 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/staging/iio/iio_dummy_evgen.c
>>> b/drivers/staging/iio/iio_dummy_evgen.c
>>> index 5a804f1..d44f138 100644
>>> --- a/drivers/staging/iio/iio_dummy_evgen.c
>>> +++ b/drivers/staging/iio/iio_dummy_evgen.c
>>> @@ -33,6 +33,7 @@
>>> * @base: base of irq range
>>> * @enabled: mask of which irqs are enabled
>>> * @inuse: mask of which irqs are connected
>>> + * @regs: irq regs we are faking
>>> * @lock: protect the evgen state
>>> */
>>> struct iio_dummy_eventgen {
>>> @@ -40,6 +41,7 @@ struct iio_dummy_eventgen {
>>> int base;
>>> bool enabled[IIO_EVENTGEN_NO];
>>> bool inuse[IIO_EVENTGEN_NO];
>>> + struct iio_dummy_regs regs[IIO_EVENTGEN_NO];
>>> struct mutex lock;
>>> };
>>>
>>> @@ -136,6 +138,12 @@ int iio_dummy_evgen_release_irq(int irq)
>>> }
>>> EXPORT_SYMBOL_GPL(iio_dummy_evgen_release_irq);
>>>
>>> +struct iio_dummy_regs *iio_dummy_evgen_get_regs(int irq)
>>> +{
>>> + return _evgen->regs[irq - iio_evgen->base];
>>> +}
>>> +EXPORT_SYMBOL_GPL(iio_dummy_evgen_get_regs);
>>> +
>>> static void iio_dummy_evgen_free(void)
>>> {
>>> irq_free_descs(iio_evgen->base, IIO_EVENTGEN_NO);
>>> @@ -153,6 +161,14 @@ static ssize_t iio_evgen_poke(struct device *dev,
>>> size_t len)
>>> {
>>> struct iio_dev_attr *this_attr = to_iio_dev_attr(attr);
>>> + unsigned long event, ret;
>>> +
>>> + ret = kstrtoul(buf, 10, );
>>> + if (ret)
>>> + return ret;
>>> +
>>> + iio_evgen->regs[this_attr->address].reg_id = this_attr->address;
>>> + iio_evgen->regs[this_attr->address].reg_data = event;
>>>
>>> if (iio_evgen->enabled[this_attr->address])
>>> handle_nested_irq(iio_evgen->base + this_attr->address);
>>> diff --git a/drivers/staging/iio/iio_dummy_evgen.h
>>> b/drivers/staging/iio/iio_dummy_evgen.h
>>> index d8845e2..3ef3a1c 100644
>>> --- a/drivers/staging/iio/iio_dummy_evgen.h
>>> +++ b/drivers/staging/iio/iio_dummy_evgen.h
>>> @@ -1,2 +1,8 @@
>>> +struct iio_dummy_regs {
>>> + u32 reg_id;
>>> + u32 reg_data;
>>> +};
>>> +
>>> +struct iio_dummy_regs *iio_dummy_evgen_get_regs(int irq);
>>> int iio_dummy_evgen_get_irq(void);
>>> int iio_dummy_evgen_release_irq(int irq);
>>> diff --git a/drivers/staging/iio/iio_simple_dummy.h
>>> b/drivers/staging/iio/iio_simple_dummy.h
>>> index b126196..1a74e26 100644
>>> --- a/drivers/staging/iio/iio_simple_dummy.h
>>> +++ b/drivers/staging/iio/iio_simple_dummy.h
>>> @@ -11,6 +11,7 @@
>>> #include
>>>
>>> struct iio_dummy_accel_calibscale;
>>> +struct iio_dummy_regs;
>>>
>>> /**
>>> * struct iio_dummy_state - device instance specific state.
>>> @@ -33,6 +34,7 @@ struct iio_dummy_state {
>>> int accel_calibbias;
>>> const struct iio_dummy_accel_calibscale *accel_calibscale;
>>> struct mutex lock;
>>> + struct iio_dummy_regs *regs;
>>> #ifdef CONFIG_IIO_SIMPLE_DUMMY_EVENTS
>>> int event_irq;
>>> int event_val;
>>> diff --git a/drivers/staging/iio/iio_simple_dummy_events.c
>>> b/drivers/staging/iio/iio_simple_dummy_events.c
>>> index 64b45b0..719dfa5 100644
>>> --- a/drivers/staging/iio/iio_simple_dummy_events.c
>>> +++ b/drivers/staging/iio/iio_simple_dummy_events.c
>>> @@ -148,12 +148,23 @@ int iio_simple_dummy_write_event_value(struct iio_dev
>>> *indio_dev,
>>> static irqreturn_t iio_simple_dummy_event_handler(int irq, void *private)
>>> {
>>> struct iio_dev *indio_dev = private;
>>> + struct
Re: [GIT PULL] overlay filesystem v25
On Sat, Oct 25, 2014 at 11:53:52AM +0200, Miklos Szeredi wrote:
> Yes, but it's not about race with copy-up (which the ovl_path_upper()
> protects against), but race of two fsync calls with each other. If
> there's no synchronization between them, then that od->upperfile does
> indeed count as lockless access, no matter that the assignment was
> done under lock.
p = global;
if (!p) { // outside of lock
p = alloc();
grab lock
if (!global) {
global = p;
} else {
destroy(p);
p = global;
}
drop lock
}
is a very common pattern, especially if you look for cases when lock is
a spinlock and allocation is blocking (in those cases you'll often see
destroy() part done after dropping the lock; that's where what I fucked up in
what I'd originally pushed. And it wasn't even needed - fput() under
->i_mutex is OK...)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] overlay filesystem v25
On Fri, Oct 24, 2014 at 09:24:45AM +0200, Miklos Szeredi wrote: > The reason I didn't do your "fix" is that it > > - adds more lines than it takes, > > - I wasn't sure at all if the lockless access is actually correct > without the ACCESS_ONCE and all the memory barrier magic that might be > necessary on weird architectures. _What_ lockless accesses? There is an extremely embarrassing bug in that commit, all right, but it has nothing to do with barriers... All barrier-related issues are taken care of by ovl_path_upper() (and without that you'd have tons of worse problems). Fetching ->upperfile outside of ->i_mutex is fine - in the worst case we'll fetch NULL, open the sucker grab ->i_mutex and find out that it has already been taken care of. In which case we fput() what we'd opened and move on (fput() under ->i_mutex is fine - it's going to be delayed until return from syscall anyway). There was a very dumb braino in there; fixed, force-pushed, passes unionmount tests, no regressions on LTP syscall ones and xfstests. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 1/7] iio: dummy: Add virtual registers for dummy device
Jonathan Cameron schrieb am 25.10.2014 20:55:
> On 09/10/14 13:39, Daniel Baluta wrote:
>> We need a way to store events generated by iio_dummy_evgen module,
>> in order to correctly process IRQs in iio_simple_dummy_events.
>>
>> For the moment, we add two registers:
>>
>> * id_reg - ID register, stores the source of the event
>> * id_data - DATA register, stores the type of the event
>>
>> e.g echo 4 > /sys/bus/iio/devices/iio_evgen/poke2
>>
>> id_reg 0x02, id_data 0x04
>>
>> This means, event of type 4 was generated by fake device 2.
>>
>> We currently use a hardcoded mapping of virtual events to IIO events.
>>
>> Signed-off-by: Irina Tirdea
>> Signed-off-by: Daniel Baluta
> Applied to the togreg branch of iio.git.
> Initially pushed out as testing for the autobuilders to play with it.
I think Daniel wanted to work on a V3 for (at least) this one, fixing variable
type of ret from long to int in iio_evgen_poke(). Had spotted it in V1, when V2
was already sent out - sorry for that. See [1].
[1] http://marc.info/?l=linux-iio=141375116229102=2
>> ---
>> drivers/staging/iio/iio_dummy_evgen.c | 16
>> drivers/staging/iio/iio_dummy_evgen.h | 6 ++
>> drivers/staging/iio/iio_simple_dummy.h| 2 ++
>> drivers/staging/iio/iio_simple_dummy_events.c | 23 ++-
>> 4 files changed, 42 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/staging/iio/iio_dummy_evgen.c
>> b/drivers/staging/iio/iio_dummy_evgen.c
>> index 5a804f1..d44f138 100644
>> --- a/drivers/staging/iio/iio_dummy_evgen.c
>> +++ b/drivers/staging/iio/iio_dummy_evgen.c
>> @@ -33,6 +33,7 @@
>> * @base: base of irq range
>> * @enabled: mask of which irqs are enabled
>> * @inuse: mask of which irqs are connected
>> + * @regs: irq regs we are faking
>> * @lock: protect the evgen state
>> */
>> struct iio_dummy_eventgen {
>> @@ -40,6 +41,7 @@ struct iio_dummy_eventgen {
>> int base;
>> bool enabled[IIO_EVENTGEN_NO];
>> bool inuse[IIO_EVENTGEN_NO];
>> +struct iio_dummy_regs regs[IIO_EVENTGEN_NO];
>> struct mutex lock;
>> };
>>
>> @@ -136,6 +138,12 @@ int iio_dummy_evgen_release_irq(int irq)
>> }
>> EXPORT_SYMBOL_GPL(iio_dummy_evgen_release_irq);
>>
>> +struct iio_dummy_regs *iio_dummy_evgen_get_regs(int irq)
>> +{
>> +return _evgen->regs[irq - iio_evgen->base];
>> +}
>> +EXPORT_SYMBOL_GPL(iio_dummy_evgen_get_regs);
>> +
>> static void iio_dummy_evgen_free(void)
>> {
>> irq_free_descs(iio_evgen->base, IIO_EVENTGEN_NO);
>> @@ -153,6 +161,14 @@ static ssize_t iio_evgen_poke(struct device *dev,
>>size_t len)
>> {
>> struct iio_dev_attr *this_attr = to_iio_dev_attr(attr);
>> +unsigned long event, ret;
>> +
>> +ret = kstrtoul(buf, 10, );
>> +if (ret)
>> +return ret;
>> +
>> +iio_evgen->regs[this_attr->address].reg_id = this_attr->address;
>> +iio_evgen->regs[this_attr->address].reg_data = event;
>>
>> if (iio_evgen->enabled[this_attr->address])
>> handle_nested_irq(iio_evgen->base + this_attr->address);
>> diff --git a/drivers/staging/iio/iio_dummy_evgen.h
>> b/drivers/staging/iio/iio_dummy_evgen.h
>> index d8845e2..3ef3a1c 100644
>> --- a/drivers/staging/iio/iio_dummy_evgen.h
>> +++ b/drivers/staging/iio/iio_dummy_evgen.h
>> @@ -1,2 +1,8 @@
>> +struct iio_dummy_regs {
>> +u32 reg_id;
>> +u32 reg_data;
>> +};
>> +
>> +struct iio_dummy_regs *iio_dummy_evgen_get_regs(int irq);
>> int iio_dummy_evgen_get_irq(void);
>> int iio_dummy_evgen_release_irq(int irq);
>> diff --git a/drivers/staging/iio/iio_simple_dummy.h
>> b/drivers/staging/iio/iio_simple_dummy.h
>> index b126196..1a74e26 100644
>> --- a/drivers/staging/iio/iio_simple_dummy.h
>> +++ b/drivers/staging/iio/iio_simple_dummy.h
>> @@ -11,6 +11,7 @@
>> #include
>>
>> struct iio_dummy_accel_calibscale;
>> +struct iio_dummy_regs;
>>
>> /**
>> * struct iio_dummy_state - device instance specific state.
>> @@ -33,6 +34,7 @@ struct iio_dummy_state {
>> int accel_calibbias;
>> const struct iio_dummy_accel_calibscale *accel_calibscale;
>> struct mutex lock;
>> +struct iio_dummy_regs *regs;
>> #ifdef CONFIG_IIO_SIMPLE_DUMMY_EVENTS
>> int event_irq;
>> int event_val;
>> diff --git a/drivers/staging/iio/iio_simple_dummy_events.c
>> b/drivers/staging/iio/iio_simple_dummy_events.c
>> index 64b45b0..719dfa5 100644
>> --- a/drivers/staging/iio/iio_simple_dummy_events.c
>> +++ b/drivers/staging/iio/iio_simple_dummy_events.c
>> @@ -148,12 +148,23 @@ int iio_simple_dummy_write_event_value(struct iio_dev
>> *indio_dev,
>> static irqreturn_t iio_simple_dummy_event_handler(int irq, void *private)
>> {
>> struct iio_dev *indio_dev = private;
>> +struct iio_dummy_state *st = iio_priv(indio_dev);
>> +
>> +dev_dbg(_dev->dev, "id %x event %x\n",
>> +st->regs->reg_id, st->regs->reg_data);
>> +
>> +switch (st->regs->reg_data) {
>> +case 0:
Re: [PATCH] Input: vsxxxaa - fix code dropping bytes from queue
On Fri, 2014-10-24 15:38:46 -0700, Dmitry Torokhov
wrote:
> I believe the intent of the code was to drop oldest bytes from the queue,
> not the latest if we drop one byte and both latest and some oldest of we
> are dropping more than one.
>
> Signed-off-by: Dmitry Torokhov
> ---
> drivers/input/mouse/vsxxxaa.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/mouse/vsxxxaa.c b/drivers/input/mouse/vsxxxaa.c
> index 3829823..abd4944 100644
> --- a/drivers/input/mouse/vsxxxaa.c
> +++ b/drivers/input/mouse/vsxxxaa.c
> @@ -128,7 +128,7 @@ static void vsxxxaa_drop_bytes(struct vsxxxaa *mouse, int
> num)
> if (num >= mouse->count) {
> mouse->count = 0;
> } else {
> - memmove(mouse->buf, mouse->buf + num - 1, BUFLEN - num);
> + memmove(mouse->buf, mouse->buf + num, BUFLEN - num);
> mouse->count -= num;
> }
> }
Good catch! I fucked up the error recovery path.
Acked-by: Jan-Benedict Glaw
MfG, JBG
--
Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481
Signature of: Eine Freie Meinung in einem Freien Kopf
the second : für einen Freien Staat voll Freier Bürger.
signature.asc
Description: Digital signature
Re: Slow dc3dd in 3.18 on x86
On 10/24/14 21:51, Martin K. Petersen wrote:
"Michael" == Michael L Semon writes:
Michael> There was nothing regarding integrity in /sys/block/sda. I was
Michael> under the impression that both bio integrity and T10 checksums
Michael> require hardware support from good hardware, so the config
Michael> items have always been shut off.
That's correct. But I see what's going on.
Please try this:
commit 8d331952d2cd341d5c0e64eee961f78f6eb4b968
Author: Martin K. Petersen
Date: Fri Oct 24 21:39:12 2014 -0400
block: Fix merge logic when CONFIG_BLK_DEV_INTEGRITY is not defined
Commit 4eaf99beadce switched to returning bool and as a result
reversed the logic of the integrity merge checks. However, the
empty stubs used when the block integrity code is compiled out were
still returning 0. Make these stubs return "true".
Reported-by: Michael L. Semon
Signed-off-by: Martin K. Petersen
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 9fbf4d3196ed..7442c6b9187e 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1590,13 +1590,13 @@ static inline bool blk_integrity_merge_rq(struct
request_queue *rq,
struct request *r1,
struct request *r2)
{
- return 0;
+ return true;
}
static inline bool blk_integrity_merge_bio(struct request_queue *rq,
struct request *r,
struct bio *b)
{
- return 0;
+ return true;
}
static inline bool blk_integrity_is_initialized(struct gendisk *g)
{
Excellent! All is well with the problem kernel. All is well with the
night's git master + xfs-oss/for-next as well. The saved E-mail patched
cleanly against both kernels using `git am`. About 40 GB of data was
written, some using fio, most using dc3dd. No problems.
I'll keep this patch and stand behind its good results so far.
Thanks again!
Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/14] net: dsa: Add support for hardware monitoring
On 10/25/2014 07:01 AM, Andrew Lunn wrote: Here is another naming option: em1dsa0-virtual-0 I prefer this over isa. However, i think there should be some sort of separator between the network device name and dsa. Fine with me. Any preference ? Note that '-' is not permitted. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v3 PATCH 1/5] of: Add standard property for poweroff capability
[+CC: Felipe ] On Sat, Oct 25, 2014 at 09:28:36AM +0200, Romain Perier wrote: > Hi Johan, > > If that's still possible to do these changes, I am opened to suggestions. Before v3.18 comes out, we can always change it with a follow-up patch. > 2014-10-23 11:53 GMT+02:00 Johan Hovold : > > [ +CC: Guenter, Lee, linux-pm ] > > > > On Tue, Oct 14, 2014 at 06:31:09AM +, Romain Perier wrote: > >> Several drivers create their own devicetree property when they register > >> poweroff capabilities. This is for example the case for mfd, regulator > >> or power drivers which define "vendor,system-power-controller" property. > >> This patch adds support for a standard property "poweroff-source" > > > > Shouldn't this property really be called "power-off-source" or even > > "power-off-controller"? > > > > The power-off handler call-chain infrastructure is about to be merged > > and will be using power[-_ ]off (i.e. not "poweroff") consistently (at > > least in its interface). > > "poweroff" or "power-off", I don't care. If people prefer "power-off", > choose this name :) Let's try to stick to power off (and power_off) then. > > Furthermore, isn't "controller" as in "power-off-controller" more > > appropriate than "source" in this case? We have wake-up sources, which > > might appear analogous, but that really isn't the same thing. > > As I said, the idea with "power-off-source" (or "poweroff-source", > that's not the point here) is to mark the device as able to poweroff > the system, like "wakeup-source" which marks the device as able to > wakeup the system. > This is why I chose this name, because it is quite similar to wakeup > property except that it is for handling power, so it did make sense to > me. > > The question is: what is the advantage of the suffix "controller" > compared to "source" ? Yeah, I figured you had been inspired by the "wakeup-source" property. The problem is that "source" tends to be used for inputs, for example, wake-up source, interrupt source, entropy source, etc. Something that is outside of the control of the OS. Contrary to for instance an output which turns the system-power off. > > I now this has already been merged to the regulator tree, but there's > > still still time to fix this. > > > >> which marks the device as able to shutdown the system. > >> > >> Signed-off-by: Romain Perier > >> --- > >> include/linux/of.h | 11 +++ > >> 1 file changed, 11 insertions(+) > >> > >> diff --git a/include/linux/of.h b/include/linux/of.h > >> index 6545e7a..27b3ba1 100644 > >> --- a/include/linux/of.h > >> +++ b/include/linux/of.h > >> @@ -866,4 +866,15 @@ static inline int of_changeset_update_property(struct > >> of_changeset *ocs, > >> /* CONFIG_OF_RESOLVE api */ > >> extern int of_resolve_phandles(struct device_node *tree); > >> > >> +/** > >> + * of_system_has_poweroff_source - Tells if poweroff-source is found for > >> device_node > >> + * @np: Pointer to the given device_node > >> + * > >> + * return true if present false otherwise > >> + */ > >> +static inline bool of_system_has_poweroff_source(const struct device_node > >> *np) > > > > Why "system_has"? Shouldn't this be of_is_power_off_source (controller)? > > Note that the current custom vendor properties contain "system-" as prefix ;) Yes, but you dropped it. ;) And it's not the system that has the property (e.g. "poweroff-source"), it's the node (or the device it describes). > we have several possibilities: > - of_system_has_power_off_source() > - of_has_power_off_source() > > We should either to use "has" or "is" as prefix because that's a > predicate function. > I would prefer "has" since it refers to a property inside a node : > this node "has" the corresponding property, so "is" is not a good > candidate. The boolean property in question describes a feature of the node (device). Say the feature would be redness and call the property "red". You would then generally ask whether the node *is red*, rather than whether it has (the property) red (or has redness). I'm actually inclined to just sticking to the current name "system-power-controller" and just drop the vendor prefixes. Perhaps your helper function can be used to parse both versions (i.e. with or without a vendor prefix) as we will still need to support both. I suggest you call that helper function of_is_system_power_controller(node) or alternatively of_is_power_off_controller(node) if that property name is preferred. Note also that in at least one case (rtc-omap, patches in mm, see [1]) the property describes that the RTC is used to control an external PMIC, which both allows us to power off the system *and* power back on again on subsequent RTC alarms. This seems to suggest that the more generic "system-power-controller" property name should be preferred. Thanks, Johan [1] https://lkml.org/lkml/2014/10/21/631 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to
Re: [PATCH 1/3] genirq: Allow the irqchip state of an IRQ to be save/restored
On Sat, 25 Oct 2014, Thomas Gleixner wrote: Bah, hit send way too fast :) > On Sat, 25 Oct 2014, Marc Zyngier wrote: > > +int irq_get_irqchip_state(unsigned int irq, int state) get_state(state) does not make sense. get_state(which) probably more so. And 'which' wants to be an enum btw. > > + chip_bus_lock(desc); > > + val = chip->irq_get_irqchip_state(data, state); > > Hmm. What's the irq_get_irqchip_state() callback supposed to return? Either an error code or a boolean value, right? Does not mix very well I think. int irq_get_irqchip_state(unsigned int irq, enum xxx which, bool *val) Might be a more clear interface. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ATTN
You have been sanction a donation. Reply for info. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] zram: avoid NULL pointer access when reading mem_used_total
There is a rare NULL pointer bug in mem_used_total_show() in concurrent
situation, like this:
zram is not initialized, process A is a mem_used_total reader which runs
periodicity, while process B try to init zram.
process A process B
access meta, get a NULL value
init zram, done
init_done() is true
access meta->mem_pool, get a NULL pointer BUG
This patch fixes this issue.
Signed-off-by: Weijie Yang
---
drivers/block/zram/zram_drv.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 64dd79a..2ffd7d8 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -99,11 +99,12 @@ static ssize_t mem_used_total_show(struct device *dev,
{
u64 val = 0;
struct zram *zram = dev_to_zram(dev);
- struct zram_meta *meta = zram->meta;
down_read(>init_lock);
- if (init_done(zram))
+ if (init_done(zram)) {
+ struct zram_meta *meta = zram->meta;
val = zs_get_total_pages(meta->mem_pool);
+ }
up_read(>init_lock);
return scnprintf(buf, PAGE_SIZE, "%llu\n", val << PAGE_SHIFT);
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] zram: make max_used_pages reset work correctly
The commit 461a8eee6a ("zram: report maximum used memory") introduces a new
knob "mem_used_max" in zram.stats sysfs, and wants to reset it via write 0
to the sysfs interface.
However, the current code cann't reset it correctly, so let's fix it.
Signed-off-by: Weijie Yang
---
drivers/block/zram/zram_drv.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 0e63e8a..64dd79a 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -173,7 +173,6 @@ static ssize_t mem_used_max_store(struct device *dev,
int err;
unsigned long val;
struct zram *zram = dev_to_zram(dev);
- struct zram_meta *meta = zram->meta;
err = kstrtoul(buf, 10, );
if (err || val != 0)
@@ -181,8 +180,7 @@ static ssize_t mem_used_max_store(struct device *dev,
down_read(>init_lock);
if (init_done(zram))
- atomic_long_set(>stats.max_used_pages,
- zs_get_total_pages(meta->mem_pool));
+ atomic_long_set(>stats.max_used_pages, 0);
up_read(>init_lock);
return len;
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] genirq: Allow the irqchip state of an IRQ to be save/restored
On Sat, 25 Oct 2014, Marc Zyngier wrote:
> +int irq_get_irqchip_state(unsigned int irq, int state)
> +{
> + struct irq_desc *desc;
> + struct irq_data *data;
> + struct irq_chip *chip;
> + int val;
> +
> + desc = irq_to_desc(irq);
> + if (!desc)
> + return -EINVAL;
> +
> + data = irq_desc_get_irq_data(desc);
> +
> + chip = irq_desc_get_chip(desc);
> + if (!chip->irq_get_irqchip_state)
> + return -EINVAL;
> +
> + chip_bus_lock(desc);
> + val = chip->irq_get_irqchip_state(data, state);
Hmm. What's the irq_get_irqchip_state() callback supposed to return?
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] pinctrl: add helpers for group based drivers
On 20.10.2014 10:04, Antoine Tenart wrote: Linus, Sebastian, As discussed earlier this year[1], this series introduce helpers for group based pinctrl drivers: - of_pinctrl_utils_read_function(): reads the function name of a specified node, and gets the number of groups it should be applied to. - of_pinctrl_for_each_function_group(): navigates through the groups of a specified node, reading at each iteration the name of the current group. A generic function to parse nodes for group based drivers is also added, and then used in the Berlin pinctrl driver: - pinconf_generic_function_groups_dt_node_to_map() [1] https://lkml.org/lkml/2014/5/17/38 Antoine, thanks for looking into this! From Berlin POV, Acked-by: Sebastian Hesselbarth Antoine Tenart (4): Documentation: bindings: pinctrl: document the generic groups property pinctrl: add helpers for group based drivers pinctrl: add a generic way to map node to map for group based drivers pinctrl: berlin: use the generic node to map function .../bindings/pinctrl/pinctrl-bindings.txt | 1 + drivers/pinctrl/berlin/Kconfig | 1 + drivers/pinctrl/berlin/berlin.c| 53 +- drivers/pinctrl/pinconf-generic.c | 36 +++ drivers/pinctrl/pinctrl-utils.c| 26 +++ drivers/pinctrl/pinctrl-utils.h| 9 include/linux/pinctrl/pinconf-generic.h| 3 ++ 7 files changed, 78 insertions(+), 51 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] futex: fix a race condition between REQUEUE_PI and task death
On Thu, 23 Oct 2014, Brian Silverman wrote:
First of all. Nice catch!
> pi_state_free and exit_pi_state_list both clean up futex_pi_state's.
> exit_pi_state_list takes the hb lock first, and most callers of
> pi_state_free do too. requeue_pi didn't, which causes lots of problems.
"causes lots of problems" is not really a good explanation of the root
cause. That wants a proper description of the race, i.e.
CPU 0 CPU 1
...
I'm surely someone who is familiar with that code, but it took me
quite some time to understand whats going on. The casual reader will
just go into brain spiral mode and give up.
> +/**
> + * Must be called with the hb lock held.
> + */
Having that comment is nice, but there is nothing which enforces
it. So we really should add another argument to that function,
i.e. struct futex_hash_bucket *hb and verify that the lock is held at
least when lockdep is enabled.
> static void free_pi_state(struct futex_pi_state *pi_state)
> @@ -1558,6 +1552,14 @@ retry_private:
> ret = get_futex_value_locked(, uaddr1);
>
> if (unlikely(ret)) {
> + if (flags & FLAGS_SHARED && pi_state != NULL) {
Why is this dependend on "flags & FLAGS_SHARED"? The shared/private
property has nothing to do with that at all, but I might be missing
something.
> + /*
> + * We will have to lookup the pi_state again, so
> + * free this one to keep the accounting correct.
> + */
> + free_pi_state(pi_state);
> + pi_state = NULL;
Instead of copying the same code over and over, we should change
free_pi_state() to handle being called with a NULL pointer.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 2/7] iio: core: Introduce IIO_ACTIVITY channel and TRANSITION event
On 25/10/14 20:19, Daniel Baluta wrote: > On Sat, Oct 25, 2014 at 10:01 PM, Jonathan Cameron wrote: >> On 09/10/14 13:39, Daniel Baluta wrote: >>> This channel will be used for exposing information about >>> activity composite sensors. Activities supported so far: >>> * running >>> * jogging >>> * walking >>> * still >>> >>> TRANSITION event is used to signal a change in the activity >>> state. >>> >>> We associate a confidence interval for each activity expressed >>> as a percentage from 0 to 100. >>> * 0, means the sensor IS NOT reporting that activity. >>> * 100, means the sensor IS reporting that activity. >>> >>> Users of this interface have two possibile means to gather >>> information about the ongoing activities. >>> >>> 1. Event based, via event file descriptor >>> * sensor may report an event when ENTERING an activity or LEAVING >>> an activity based on a threshold value. >>> * drivers will wake up applications waiting data on the event fd >>> >>> 2. Polling, by reading the sysfs associated attribute files: >>> * /sys/bus/iio/devices/iio:device0/in_activity_running_input >>> expressed as percentage confidence value from 0 to 100. >>> >>> This will offer an interface for Android significant motion >>> composite sensor defined here: >>> http://source.android.com/devices/sensors/composite_sensors.html >>> >>> Activities listed above are supported by Freescale's MMA9553 sensor: >>> http://freescale.com/files/sensors/doc/ref_manual/MMA9553LSWRM.pdf >>> >>> Signed-off-by: Irina Tirdea >>> Signed-off-by: Daniel Baluta >> >> I don't see why we need the transition event. A transition is simply >> a threshold rising (or falling) event much like any other - just >> on a confidence interval. >> >> So it would be possible to be interested in the confidence that are not >> sitting rising above 20% on the basis that some other sensor needs enabling. >> > > Using a THRESHOLD event type also work for us. > >> See below for resulting suggestions. >> >> Other than that little point this looks good to me. >>> --- >>> Documentation/ABI/testing/sysfs-bus-iio | 44 >>> + >>> drivers/iio/industrialio-core.c | 5 >>> drivers/iio/industrialio-event.c| 1 + >>> include/linux/iio/types.h | 8 +- >>> 4 files changed, 57 insertions(+), 1 deletion(-) >>> >>> diff --git a/Documentation/ABI/testing/sysfs-bus-iio >>> b/Documentation/ABI/testing/sysfs-bus-iio >>> index d760b02..12d0385 100644 >>> --- a/Documentation/ABI/testing/sysfs-bus-iio >>> +++ b/Documentation/ABI/testing/sysfs-bus-iio >>> @@ -776,6 +776,40 @@ Description: >>> met before an event is generated. If direction is not >>> specified then this period applies to both directions. >>> >>> +What:/sys/.../events/in_activity_still_transition_rising_en >> What: /sys/.../events/in_activity_threshold_rising_en > > Shouldn't this be: > > What: /sys/.../events/in_activity_still_threshold_rising_en ? > > Perhaps, one needs to enable events per activity type. Absolutely. > >>> +What: >>> /sys/.../events/in_activity_still_transition_falling_en >> What: /sys/.../events/in_activity_threshold_falling_en > Also, here: > > What: /sys/.../events/in_activity_still_threshold_falling_en > >> etc >>> +What: >>> /sys/.../events/in_activity_walking_transition_rising_en >>> +What: >>> /sys/.../events/in_activity_walking_transition_falling_en >>> +What: >>> /sys/.../events/in_activity_jogging_transition_rising_en >>> +What: >>> /sys/.../events/in_activity_jogging_transition_falling_en >>> +What: >>> /sys/.../events/in_activity_running_transition_rising_en >>> +What: >>> /sys/.../events/in_activity_running_transition_falling_en >>> +KernelVersion: 3.19 >>> +Contact: linux-...@vger.kernel.org >>> +Description: >>> + Enables or disables activitity events. Depending on direction >>> + an event is generated when sensor ENTERS or LEAVES a given >>> state. >>> + >>> +What: >>> /sys/.../events/in_activity_still_transition_rising_value >> What: /sys/.../events/in_activity_still_threshold_rising_value etc > > This looks good to me :) > >>> +What: >>> /sys/.../events/in_activity_still_transition_falling_value >>> +What: >>> /sys/.../events/in_activity_walking_transition_rising_value >>> +What: >>> /sys/.../events/in_activity_walking_transition_falling_value >>> +What: >>> /sys/.../events/in_activity_jogging_transition_rising_value >>> +What: >>> /sys/.../events/in_activity_jogging_transition_falling_value >>> +What: >>> /sys/.../events/in_activity_running_transition_rising_value >>> +What: >>> /sys/.../events/in_activity_running_transition_falling_value
Re: [RFC PATCH v2 6/7] iio: dummy: Demonstrate the usage of new channel types
On 09/10/14 13:39, Daniel Baluta wrote:
> Adds support for the new channel types in the dummy driver:
> * a new channel IIO_ACTIVITY
> * two state transition events (running and walking)
> * a new channel IIO_STEPS and support for reading and writing
> pedometer step counter
> * step detect event
> * a new channel IIO_HEIGHT and support for reading and writing
> height
>
> Signed-off-by: Irina Tirdea
> Signed-off-by: Daniel Baluta
This looks fine, allowing for changes due to suggestions / discussions
about earlier patches.
> ---
> drivers/staging/iio/iio_simple_dummy.c| 199
> +++---
> drivers/staging/iio/iio_simple_dummy.h| 5 +
> drivers/staging/iio/iio_simple_dummy_events.c | 38 +
> 3 files changed, 223 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/staging/iio/iio_simple_dummy.c
> b/drivers/staging/iio/iio_simple_dummy.c
> index bf78e6f..5430aed 100644
> --- a/drivers/staging/iio/iio_simple_dummy.c
> +++ b/drivers/staging/iio/iio_simple_dummy.c
> @@ -69,6 +69,34 @@ static const struct iio_event_spec iio_dummy_event = {
> .mask_separate = BIT(IIO_EV_INFO_VALUE) | BIT(IIO_EV_INFO_ENABLE),
> };
>
> +/*
> + * simple step detect event - triggered when a step is detected
> + */
> +static const struct iio_event_spec step_detect_event = {
> + .type = IIO_EV_TYPE_INSTANCE,
> + .dir = IIO_EV_DIR_NONE,
> + .mask_separate = BIT(IIO_EV_INFO_ENABLE),
> +};
> +
> +/*
> + * simple transition event - triggered when the reported running confidence
> + * value rises above a threshold value
> + */
> +static const struct iio_event_spec iio_running_event = {
> + .type = IIO_EV_TYPE_TRANSITION,
> + .dir = IIO_EV_DIR_RISING,
> + .mask_separate = BIT(IIO_EV_INFO_VALUE) | BIT(IIO_EV_INFO_ENABLE),
> +};
> +
> +/*
> + * simple transition event - triggered when the reported walking confidence
> + * value falls under a threshold value
> + */
> +static const struct iio_event_spec iio_walking_event = {
> + .type = IIO_EV_TYPE_TRANSITION,
> + .dir = IIO_EV_DIR_FALLING,
> + .mask_separate = BIT(IIO_EV_INFO_VALUE) | BIT(IIO_EV_INFO_ENABLE),
> +};
> #endif
>
> /*
> @@ -215,6 +243,42 @@ static const struct iio_chan_spec iio_dummy_channels[] =
> {
> .indexed = 1,
> .channel = 0,
> },
> + {
> + .type = IIO_STEPS,
> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_ENABLE),
> + .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED),
> + .scan_index = -1,
> +#ifdef CONFIG_IIO_SIMPLE_DUMMY_EVENTS
> + .event_spec = _detect_event,
> + .num_event_specs = 1,
> +#endif /* CONFIG_IIO_SIMPLE_DUMMY_EVENTS */
> + },
> + {
> + .type = IIO_HEIGHT,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),
> + .scan_index = -1,
> + },
> + {
> + .type = IIO_ACTIVITY,
> + .modified = 1,
> + .channel2 = IIO_MOD_RUNNING,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED),
> +#ifdef CONFIG_IIO_SIMPLE_DUMMY_EVENTS
> + .event_spec = _running_event,
> + .num_event_specs = 1,
> +#endif /* CONFIG_IIO_SIMPLE_DUMMY_EVENTS */
> + },
> + {
> + .type = IIO_ACTIVITY,
> + .modified = 1,
> + .channel2 = IIO_MOD_WALKING,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED),
> +#ifdef CONFIG_IIO_SIMPLE_DUMMY_EVENTS
> + .event_spec = _walking_event,
> + .num_event_specs = 1,
> +#endif /* CONFIG_IIO_SIMPLE_DUMMY_EVENTS */
> + },
> };
>
> /**
> @@ -259,6 +323,34 @@ static int iio_dummy_read_raw(struct iio_dev *indio_dev,
> *val = st->accel_val;
> ret = IIO_VAL_INT;
> break;
> + case IIO_HEIGHT:
> + *val = st->height;
> + ret = IIO_VAL_INT;
> + break;
> + default:
> + break;
> + }
> + break;
> + case IIO_CHAN_INFO_PROCESSED:
> + switch (chan->type) {
> + case IIO_STEPS:
> + *val = st->steps;
> + ret = IIO_VAL_INT;
> + break;
> + case IIO_ACTIVITY:
> + switch (chan->channel2) {
> + case IIO_MOD_RUNNING:
> + *val = st->activity_running;
> + ret = IIO_VAL_INT;
> + break;
> + case IIO_MOD_WALKING:
> + *val = st->activity_walking;
> + ret = IIO_VAL_INT;
> + break;
> + default:
> + break;
> + }
> +
Re: [PATCH V2 net-next] Bluetooth: fix shadow warning in hci_disconnect()
Hi Fabian, > use clkoff_cp for hci_cp_read_clock_offset instead of cp > (already defined above). > > Suggested-by: Marcel Holtmann > Signed-off-by: Fabian Frederick > --- > V2: use clkoff_cp instead of cpr (suggested by Marcel Holtmann) > > net/bluetooth/hci_conn.c | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) patch has been applied to bluetooth-next tree. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
UKSM: What's maintainers think about it?
Good time of day, people. I try to find 'mm' subsystem specific people and lists, but list linux-mm looks dead and mail archive look like deprecated. If i must to sent this message to another list or add CC people, let me know. If questions are already asked (i can't find activity before), feel free to kick me. The main questions: 1. Somebody test it? I see many reviews about it. I already port it to latest linux-next-git kernel and its work without issues. http://pastebin.com/6FMuKagS (if it matter, i can describe use cases and results, if somebody ask it) 2. Developers of UKSM already tried to merge it? Somebody talked with uksm devs? offtop: now i try to communicate with dev's on kerneldedup.org forum, but i have problems with email verification and wait admin registration approval. (i already sent questions to http://kerneldedup.org/forum/home.php?mod=space=xianai , because him looks like team leader) 3. I just want collect feedbacks from linux maintainers team, if you decide what UKSM not needed in kernel, all other comments (as i understand) not matter. Like KSM, but better. UKSM - Ultra Kernel Samepage Merging http://kerneldedup.org/en/projects/uksm/introduction/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 5/7] iio: core: Introduce HEIGHT channel type
On 09/10/14 13:39, Daniel Baluta wrote:
> From: Irina Tirdea
>
> Some devices need the height of the user to compute various
> parameters. One of this devices is Freescale's MMA9553L
> (http://www.freescale.com/files/sensors/doc/ref_manual/MMA9553LSWRM.pdf)
> that needs the height of the user to compute the stride length which
> is used further to determine distance, speed and activity type.
>
> Introduce a new channel type HEIGHT to export these values.
Now I'd love to make this generic as
in_distance_z_input etc but I guess that's pretty confusing for users ;)
Sadly altitude is going to be even more confusing.
I wonder if we should make this more explicit and have it as
in_steps_calibheight (repeated for all the channels whose computation
it effects). It's really a parameter of those channels rather than on
its own.
It should be out_height_input etc given you are setting it (like a trim
DAC on some ADC setup)
The there is an implication as that you are changing the users height
which, whilst it would be 'interesting', is probably the wrong impression!
*laughs* Maybe you were right to keep this an RFC for now ;)
>
> Signed-off-by: Irina Tirdea
> Signed-off-by: Daniel Baluta
> ---
> Documentation/ABI/testing/sysfs-bus-iio | 9 +
> drivers/iio/industrialio-core.c | 1 +
> include/linux/iio/types.h | 1 +
> 3 files changed, 11 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> b/Documentation/ABI/testing/sysfs-bus-iio
> index 3557a69..fc027cb 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -256,6 +256,7 @@ What:
> /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_scale
> What:/sys/bus/iio/devices/iio:deviceX/in_accel_scale
> What:/sys/bus/iio/devices/iio:deviceX/in_accel_peak_scale
> What:/sys/bus/iio/devices/iio:deviceX/in_anglvel_scale
> +What:/sys/bus/iio/devices/iio:deviceX/in_height_scale
> What:/sys/bus/iio/devices/iio:deviceX/in_magn_scale
> What:/sys/bus/iio/devices/iio:deviceX/in_magn_x_scale
> What:/sys/bus/iio/devices/iio:deviceX/in_magn_y_scale
> @@ -1010,6 +1011,14 @@ Description:
> For a list of available output power modes read
> in_accel_power_mode_available.
>
> +What:/sys/.../iio:deviceX/in_height_input
> +What:/sys/.../iio:deviceX/in_height_raw
> +KernelVersion: 3.17
> +Contact: linux-...@vger.kernel.org
> +Description:
> + This attribute is used to set and read the user's height.
> + Units after application of scale are centimeters.
> +
> What:/sys/bus/iio/devices/iio:deviceX/store_eeprom
> KernelVersion: 3.4.0
> Contact: linux-...@vger.kernel.org
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index 1e060f3..f08b278 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -72,6 +72,7 @@ static const char * const iio_chan_type_name_spec[] = {
> [IIO_HUMIDITYRELATIVE] = "humidityrelative",
> [IIO_ACTIVITY] = "activity",
> [IIO_STEPS] = "steps",
> + [IIO_HEIGHT] = "height",
> };
>
> static const char * const iio_modifier_names[] = {
> diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h
> index af0b6e0..a23b2e7 100644
> --- a/include/linux/iio/types.h
> +++ b/include/linux/iio/types.h
> @@ -32,6 +32,7 @@ enum iio_chan_type {
> IIO_HUMIDITYRELATIVE,
> IIO_ACTIVITY,
> IIO_STEPS,
> + IIO_HEIGHT,
> };
>
> enum iio_modifier {
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] ARM: dts: socfpga: fpga bridges bindings docs
Hi Pantelis! On Fri, Oct 24, 2014 at 12:20:53PM +0300, Pantelis Antoniou wrote: > Hi Stefan, Allan, > > Sorry, haven’t had a chance to review all this yet; will do so in the weekend. > Just wanted to pop in and comment on a few things. > > > On Oct 24, 2014, at 10:00 AM, Steffen Trumtrar > > wrote: > > > > Hi! > > > > On Thu, Oct 23, 2014 at 06:51:06PM -0500, at...@opensource.altera.com wrote: > >> From: Alan Tull > > > > (...) > > > >> diff --git > >> a/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt > >> b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt > >> new file mode 100644 > >> index 000..bc24a2e > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt > >> @@ -0,0 +1,53 @@ > >> +Altera FPGA/HPS Bridge Driver > >> + > >> +This driver manages a bridge between a FPGA and a host processor system > >> (HPS). > >> +User space can enable or disable the bridge by writing a "1" or a "0", > >> +respectively, to its enable file under bridge's entry in > >> +/sys/class/fpga-bridge. Typically, one disables the bridges before > >> +reprogramming the FPGA. Once the FPGA is reprogrammed, the bridges are > >> +reenabled. > >> + > > > > NAK. > > > > This is all linux specific and doesn't belong here. > > > > We know. The DT spec hasn’t been updated for a while, and this is going to be > part of what we want to do with the restarting of the ePAPR spec process. > As we don't have a new spec yet, I go with the current state of the art. And I don't see how "file under ... /sys/class/fpga-bridge" fits the current spec. > So absolutes like “DT is a hardware description only" might be too strong > statements, that > do not work in practice anymore. > > There’s no such thing as pure hardware devices lately - there is always a > configuration > component; some of it OS specific, some of it not. > If it really is necessary, I'm not against it, don't get me wrong. But in the grand scheme I wouldn't say that this fits my experience. There are some devices that need configuration and often when it is done in the DT, it is just a shortcut or not thought through. And can be also introspected dynamically. With some discussion on the list these bindings often change. Regarding OS specifics: already there, e.g. console setup in the chosen node. And other things I saw are ethernet aliases just for u-boot. Not a problem of the spec, just a problem of u-boot and unneccessary "configuration". Just to fix a bad bootloader. barebox can handle this without any such stuff. Maybe we should integrate the DT "overlays" barebox uses into the in-kernel DTs as well...but does it really help/interest someone who decides to use u-boot where barebox stores its environment? I guess not. > We have to be engaged in the process and figure out how to update the spec > for what is > now the state of the art in the industry. > Again, not against that if it is necessary. For example your overlay stuff might be a good update to the spec. Would be better if it is official instead of a "hack". I want that for SoCFPGA. But having looked at one or two vendor kernels+DTs, the state of the art in the industry is: using DT wrong. (And doing HW wrong, which makes some updates to the ePAPR necessary ;-)) Regards, Steffen -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
