Re: [PATCH 0/4] x86: Add Cache QoS Monitoring (CQM) support
On Fri, Jan 10, 2014 at 06:55:11PM +, Waskiewicz Jr, Peter P wrote:
> I've spoken with the CPU architect, and he's set me straight. I was
> getting some simulation data and reality mixed up, so apologies.
>
> The cacheline is tagged with the RMID being tracked when it's brought
> into the cache. That is the only time it's tagged, it does not get
> updated (I was looking at data showing impacts if it was updated).
>
> If there are frequent RMID updates for a particular process, then there
> is the possibility that any remaining old data for that process can be
> accounted for on a different RMID. This really is workload dependent,
> and my architect provided their data showing that this occurrence is
> pretty much in the noise.
What change frequency and what sided workloads did they test?
I can make it significant; take a multi-threaded workload that mostly
fits in cache, then assign all theads but one RMDI 0, then fairly
quickly rotate RMID 1 between the threads.
The problem is, since there's a limited number of RMIDs we have to
rotate at some point, but since changing RMIDs is nondeterministic we
can't.
> Also, I did ask about the granularity of the RMID, and it is
> per-cacheline. So if there is a non-exclusive cacheline, then the
> occupancy data in the other part of the cacheline will count against the
> RMID.
One more question:
u64 i;
u64 rmid_val[];
for (i = 0; i < rmid_max; i++) {
wrmsr(IA32_QM_EVTSEL, 1 | (i << 32));
rdmsr(IA32_QM_CTR, rmid_val[i]);
}
Is this the right way of reading these values? I couldn't find anything
that says the event must 'run' to accumulate a value at all, so all it
seems it a direct value read with a multiplexer to the RMID.
> > So my current mental model would tag a line with the current (ASSOC)
> > RMID on:
> > - load from DRAM -> L*, even for non-exclusive
> > - any to exclusive transition
> >
> > The result of such rules is that when the effective RMID of a task
> > changes it takes an indeterminate amount of time before the residency
> > stats reflect reality again.
> >
> > Furthermore; the IA32_QM_CTR is a misnomer as its a VALUE not a COUNTER.
> > Not to mention the entire SDM 17.14.2 section is a mess; it purports to
> > describe how to detect the thing using CPUID but then also maybe
> > describes how to program it.
>
> I've given this feedback to the section owner in the SDM. There is an
> update due this month, and there will be some updates to this section
> (along with some additions).
>
> I should have my alternate implementation sent out shortly, just working
> a few kinks out of it. This is the proc-based and sysfs-based interface
> that will rely on a userspace program to handle the logic of grouping
> and assigning stuff together.
I've not figured out how to deal with this stuff yet; exposing RMIDs to
userspace is a guaranteed fail though. Any interface that disallows the
kernel to manage the RMIDs is broken.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-Xtensa] [PATCH v2] perf: add support for the xtensa architecture
Hi perf maintainers,
Ping?
Anyone taking this for v3.14?
baruch
On Thu, Jan 02, 2014 at 09:57:10AM +0200, Baruch Siach wrote:
> Signed-off-by: Baruch Siach
> ---
> v2: use the "core ID" field from /proc/cpuinfo (Max Filippov)
> ---
> tools/perf/perf.h | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/tools/perf/perf.h b/tools/perf/perf.h
> index b079304bd53d..e441864dbe03 100644
> --- a/tools/perf/perf.h
> +++ b/tools/perf/perf.h
> @@ -132,6 +132,13 @@
> #define CPUINFO_PROC "CPU"
> #endif
>
> +#ifdef __xtensa__
> +#define mb() asm volatile("memw" ::: "memory")
> +#define wmb()asm volatile("memw" ::: "memory")
> +#define rmb()asm volatile("" ::: "memory")
> +#define CPUINFO_PROC "core ID"
> +#endif
> +
> #define barrier() asm volatile ("" ::: "memory")
>
> #ifndef cpu_relax
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sched: Calculate effective load even if local weight is 0
Hi,
On Mon, Jan 6, 2014 at 5:09 PM, Mel Gorman wrote:
> (Rik, you authored this patch so it should be sent from you and needs a
> signed-off assuming people are ok with the changelog.)
>
> Thomas Hellstrom bisected a regression where erratic 3D performance is
> experienced on virtual machines as measured by glxgears. It identified
> commit 58d081b5 (sched/numa: Avoid overloading CPUs on a preferred NUMA
> node) as the problem which had modified the behaviour of effective_load.
>
> Effective load calculates the difference to the system-wide load if a
> scheduling entity was moved to another CPU. The task group is not heavier
> as a result of the move but overall system load can increase/decrease as a
> result of the change. Commit 58d081b5 (sched/numa: Avoid overloading CPUs
> on a preferred NUMA node) changed effective_load to make it suitable for
> calculating if a particular NUMA node was compute overloaded. To reduce
> the cost of the function, it assumed that a current sched entity weight
> of 0 was uninteresting but that is not the case.
>
> wake_affine uses a weight of 0 for sync wakeups on the grounds that it
> is assuming the waking task will sleep and not contribute to load in the
> near future. In this case, we still want to calculate the effective load
> of the sched entity hierarchy. As effective_load is no longer used by
Would it be worth mentioning that besides sync wakeups, wake_affine() uses a
weight of 0 for the sched entity, for effective load calculation on
the prev_cpu as well?
This is so as to find the effect of moving this task away from the
prev_cpu. Here
too we are interested in calculating the effective load of the root
task group of this
sched entity on the prev_cpu and the below restored check will be relevant.
Without the below check the difference in the loads of the wake affine
CPU and the
prev_cpu can get messed up.
Thanks
Regards
Preeti U Murthy
> task_numa_compare since commit fb13c7ee (sched/numa: Use a system-wide
> search to find swap/migration candidates), this patch simply restores the
> historical behaviour.
>
> [mgor...@suse.de: Wrote changelog]
> Reported-and-tested-by: Thomas Hellstrom
> Should-be-signed-off-and-authored-by-Rik
> ---
> kernel/sched/fair.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index c7395d9..e64b079 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -3923,7 +3923,7 @@ static long effective_load(struct task_group *tg, int
> cpu, long wl, long wg)
> {
> struct sched_entity *se = tg->se[cpu];
>
> - if (!tg->parent || !wl) /* the trivial, non-cgroup case */
> + if (!tg->parent)/* the trivial, non-cgroup case */
> return wl;
>
> for_each_sched_entity(se) {
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@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: [PATCH 07/11] vfs: add cross-rename
On Wed 08-01-14 23:10:11, Miklos Szeredi wrote:
> From: Miklos Szeredi
>
> If flags contain RENAME_EXCHANGE then exchange source and destination files.
> There's no restriction on the type of the files; e.g. a directory can be
> exchanged with a symlink.
>
> Signed-off-by: Miklos Szeredi
> ---
> fs/dcache.c | 46 +
> fs/namei.c | 107
> +---
> include/linux/dcache.h | 1 +
> include/uapi/linux/fs.h | 1 +
> security/security.c | 16
> 5 files changed, 131 insertions(+), 40 deletions(-)
>
> diff --git a/fs/namei.c b/fs/namei.c
> index 3fbc95c72e31..97c6dbb47eca 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -4020,6 +4020,8 @@ int vfs_rename(struct inode *old_dir, struct dentry
> *old_dentry,
> const unsigned char *old_name;
> struct inode *source = old_dentry->d_inode;
> struct inode *target = new_dentry->d_inode;
> + bool new_is_dir = false;
> + unsigned max_links = new_dir->i_sb->s_max_links;
>
> if (source == target)
> return 0;
> @@ -4028,10 +4030,16 @@ int vfs_rename(struct inode *old_dir, struct dentry
> *old_dentry,
> if (error)
> return error;
>
> - if (!target)
> + if (!target) {
> error = may_create(new_dir, new_dentry);
> - else
> - error = may_delete(new_dir, new_dentry, is_dir);
> + } else {
> + new_is_dir = d_is_dir(new_dentry);
> +
> + if (!(flags & RENAME_EXCHANGE))
> + error = may_delete(new_dir, new_dentry, is_dir);
> + else
> + error = may_delete(new_dir, new_dentry, new_is_dir);
> + }
> if (error)
> return error;
>
> @@ -4042,10 +4050,17 @@ int vfs_rename(struct inode *old_dir, struct dentry
> *old_dentry,
>* If we are going to change the parent - check write permissions,
>* we'll need to flip '..'.
>*/
> - if (is_dir && new_dir != old_dir) {
> - error = inode_permission(source, MAY_WRITE);
> - if (error)
> - return error;
> + if (new_dir != old_dir) {
> + if (is_dir) {
> + error = inode_permission(source, MAY_WRITE);
> + if (error)
> + return error;
> + }
> + if ((flags & RENAME_EXCHANGE) && new_is_dir) {
> + error = inode_permission(target, MAY_WRITE);
> + if (error)
> + return error;
> + }
> }
>
> error = security_inode_rename(old_dir, old_dentry, new_dir, new_dentry,
> @@ -4055,25 +4070,24 @@ int vfs_rename(struct inode *old_dir, struct dentry
> *old_dentry,
>
> old_name = fsnotify_oldname_init(old_dentry->d_name.name);
> dget(new_dentry);
> - if (!is_dir)
> - lock_two_nondirectories(source, target);
> - else if (target)
> - mutex_lock(>i_mutex);
> + if (!(flags & RENAME_EXCHANGE)) {
> + if (!is_dir)
> + lock_two_nondirectories(source, target);
> + else if (target)
> + mutex_lock(>i_mutex);
> + }
>
> error = -EBUSY;
> if (d_mountpoint(old_dentry) || d_mountpoint(new_dentry))
> goto out;
>
> - if (is_dir) {
> - unsigned max_links = new_dir->i_sb->s_max_links;
> -
> + if (max_links && new_dir != old_dir) {
> error = -EMLINK;
> - if (max_links && !target && new_dir != old_dir &&
> - new_dir->i_nlink >= max_links)
> + if (is_dir && !new_is_dir && new_dir->i_nlink >= max_links)
> + goto out;
> + if ((flags & RENAME_EXCHANGE) && !is_dir && new_is_dir &&
> + old_dir->i_nlink > max_links)
This should be >=, shouldn't it?
> goto out;
> -
> - if (target)
> - shrink_dcache_parent(new_dentry);
> } else {
> error = try_break_deleg(source, delegated_inode);
> if (error)
> @@ -4084,27 +4098,40 @@ int vfs_rename(struct inode *old_dir, struct dentry
> *old_dentry,
> goto out;
> }
> }
> + if (is_dir && !(flags & RENAME_EXCHANGE) && target)
> + shrink_dcache_parent(new_dentry);
> error = old_dir->i_op->rename(old_dir, old_dentry, new_dir, new_dentry,
> flags);
> if (error)
> goto out;
>
> - if (target) {
> + if (!(flags & RENAME_EXCHANGE) && target) {
> if (is_dir)
> target->i_flags |= S_DEAD;
> dont_mount(new_dentry);
> }
> - if (!(old_dir->i_sb->s_type->fs_flags & FS_RENAME_DOES_D_MOVE))
> - d_move(old_dentry, new_dentry);
> + if
Re: [PATCH] mtd: nand: assign mtd->name in find_full_id_nand
On Mon, Jan 13, 2014 at 04:12:45AM +, Caizhiyong wrote:
> > -Original Message-
> > From: Brian Norris [mailto:computersforpe...@gmail.com]
> > Sent: Sunday, January 12, 2014 4:10 AM
> >
> > On Thu, Dec 26, 2013 at 10:19:39AM +0800, Huang Shijie wrote:
> > > On Thu, Dec 26, 2013 at 01:51:58AM +, Caizhiyong wrote:
> > > > From: Cai Zhiyong
> > > > Date: Wed, 25 Dec 2013 21:19:21 +0800
> > > > Subject: [PATCH] mtd: nand: assign mtd->name in find_full_id_nand
> > > >
> > > > This patch assigned the type->name to mtd->name when mtd->name is
> > > > NULL in function "find_full_id_nand".
> > > > mtd->name is NULL may cause some problem.
> > > >
> > > > Signed-off-by: Cai Zhiyong
> > > Acked-by: Huang Shijie
> >
> > Thanks, the patch looks good. Pushed to l2-mtd.git.
> >
> > Wouldn't this trigger an exception when reading
> > /sys/class/mtd/mtdX/name? If so, should this be marked for stable?
>
> View the source code, if mtd->name is NULL, cat "/sys/class/mtd/mtdX/name"
> will get string "(null)".
>
> static ssize_t mtd_name_show(struct device *dev, struct device_attribute
> *attr, char *buf)
> {
> struct mtd_info *mtd = dev_get_drvdata(dev);
>
> return snprintf(buf, PAGE_SIZE, "%s\n", mtd->name);
> }
Thanks, I forgot that the kernel's printf-like functions handle NULL
pointers gracefully. In that case, this probably doesn't need to be in
-stable.
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] mm/swap: fix race on swap_info reuse between swapoff and swapon
On Mon, Jan 13, 2014 at 2:27 PM, Mateusz Guzik wrote: > On Mon, Jan 13, 2014 at 11:51:42AM +0800, Weijie Yang wrote: >> On Mon, Jan 13, 2014 at 11:27 AM, Andrew Morton >> wrote: >> > On Mon, 13 Jan 2014 11:08:58 +0800 Weijie Yang >> > wrote: >> > >> >> >> --- a/mm/swapfile.c >> >> >> +++ b/mm/swapfile.c >> >> >> @@ -1922,7 +1922,6 @@ SYSCALL_DEFINE1(swapoff, const char __user *, >> >> >> specialfile) >> >> >> p->swap_map = NULL; >> >> >> cluster_info = p->cluster_info; >> >> >> p->cluster_info = NULL; >> >> >> - p->flags = 0; >> >> >> frontswap_map = frontswap_map_get(p); >> >> >> spin_unlock(>lock); >> >> >> spin_unlock(_lock); >> >> >> @@ -1948,6 +1947,16 @@ SYSCALL_DEFINE1(swapoff, const char __user *, >> >> >> specialfile) >> >> >> mutex_unlock(>i_mutex); >> >> >> } >> >> >> filp_close(swap_file, NULL); >> >> >> + >> >> >> + /* >> >> >> + * clear SWP_USED flag after all resources freed >> >> >> + * so that swapon can reuse this swap_info in alloc_swap_info() >> >> >> safely >> >> >> + * it is ok to not hold p->lock after we cleared its SWP_WRITEOK >> >> >> + */ >> >> >> + spin_lock(_lock); >> >> >> + p->flags = 0; >> >> >> + spin_unlock(_lock); >> >> >> + >> >> >> err = 0; >> >> >> atomic_inc(_poll_event); >> >> >> wake_up_interruptible(_poll_wait); >> > But do you agree that your >> > http://ozlabs.org/~akpm/mmots/broken-out/mm-swap-fix-race-on-swap_info-reuse-between-swapoff-and-swapon.patch >> > makes Krzysztof's >> > http://ozlabs.org/~akpm/mmots/broken-out/swap-fix-setting-page_size-blocksize-during-swapoff-swapon-race.patch >> > obsolete? >> >> Yes, I agree. >> >> > I've been sitting on Krzysztof's >> > swap-fix-setting-page_size-blocksize-during-swapoff-swapon-race.patch >> > for several months - Hugh had issues with it so I put it on hold and >> > nothing further happened. >> > >> >> I will try to resend a patchset to make lock usage in swapfile.c clear >> >> and fine grit >> > >> > OK, thanks. In the meanwhile I'm planning on dropping Krzysztof's >> > patch and merging your patch into 3.14-rc1, which is why I'd like >> > confirmation that your patch addresses the issues which Krzysztof >> > identified? >> > >> >> I think so, Krzysztof and I both try to fix the same issue(reuse >> swap_info while its >> previous resources are not cleared completely). The different is >> Krzysztof's patch >> uses a global swapon_mutex and its commit log only focuses on >> set_blocksize(), >> while my patch try to maintain the fine grit lock usage. >> > > Maybe I should get some sleep first, but I found some minor nits. > > Newly introduced window: > > p->swap_map == NULL && (p->flags & SWP_USED) > > breaks swap_info_get: > if (!(p->flags & SWP_USED)) > goto bad_device; > offset = swp_offset(entry); > if (offset >= p->max) > goto bad_offset; > if (!p->swap_map[offset]) > goto bad_free; > > so that would need a trivial adjustment. > Hi, Mateusz. Thanks for review. It could not happen. swapoff call try_to_unuse() to force all swp_entries unused before set p->swap_map NULL. So if somebody still hold a swp_entry by this time, there must be some error elsewhere. Say more about it, I don't think it is a newly introduced window, the current code set p->swap_map NULL and then clear p->flags in swapoff, swap_info_get access these fields without lock, so this impossible window "exist" for many years. It is really confusing, that is why I plan to resend a patchset to make it clear, by comments at least. > Another nit is that swap_start and swap_next do the following: > if (!(si->flags & SWP_USED) || !si->swap_map) > continue; > > Testing for swap_map does not look very nice and regardless of your > patch the latter cannot be true if the former is not, thus the check > can be simplified to mere !si->swap_map. Yes, mere !si->swap_map is enough. But how about use SWP_WRITEOK, I think it is more clear and hurt nobody. > I'm wondering if it would make sense to dedicate a flag (SWP_ALLOCATED?) > to control whether swapon can use give swap_info. That is, it would be > tested and set in alloc_swap_info & cleared like you clear SWP_USED now. > SWP_USED would be cleared as it is and would be set in _enable_swap_info > > Then swap_info_get would be left unchanged and swap_* would test for > SWP_USED only. I think SWP_USED and SWP_WRITEOK are enough, introduce another flag would make things more complex. The first thing in my opition is make the lock and flag usage more clear and readable in swapfile.c If I miss something, plead let me know. Thanks! > -- > Mateusz Guzik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 9/9] mm: keep page cache radix tree nodes in check
On Fri, Jan 10, 2014 at 01:10:43PM -0500, Johannes Weiner wrote:
> Previously, page cache radix tree nodes were freed after reclaim
> emptied out their page pointers. But now reclaim stores shadow
> entries in their place, which are only reclaimed when the inodes
> themselves are reclaimed. This is problematic for bigger files that
> are still in use after they have a significant amount of their cache
> reclaimed, without any of those pages actually refaulting. The shadow
> entries will just sit there and waste memory. In the worst case, the
> shadow entries will accumulate until the machine runs out of memory.
>
> To get this under control, the VM will track radix tree nodes
> exclusively containing shadow entries on a per-NUMA node list.
> Per-NUMA rather than global because we expect the radix tree nodes
> themselves to be allocated node-locally and we want to reduce
> cross-node references of otherwise independent cache workloads. A
> simple shrinker will then reclaim these nodes on memory pressure.
>
> A few things need to be stored in the radix tree node to implement the
> shadow node LRU and allow tree deletions coming from the list:
>
> 1. There is no index available that would describe the reverse path
>from the node up to the tree root, which is needed to perform a
>deletion. To solve this, encode in each node its offset inside the
>parent. This can be stored in the unused upper bits of the same
>member that stores the node's height at no extra space cost.
>
> 2. The number of shadow entries needs to be counted in addition to the
>regular entries, to quickly detect when the node is ready to go to
>the shadow node LRU list. The current entry count is an unsigned
>int but the maximum number of entries is 64, so a shadow counter
>can easily be stored in the unused upper bits.
>
> 3. Tree modification needs tree lock and tree root, which are located
>in the address space, so store an address_space backpointer in the
>node. The parent pointer of the node is in a union with the 2-word
>rcu_head, so the backpointer comes at no extra cost as well.
>
> 4. The node needs to be linked to an LRU list, which requires a list
>head inside the node. This does increase the size of the node, but
>it does not change the number of objects that fit into a slab page.
>
> Signed-off-by: Johannes Weiner
> ---
> include/linux/list_lru.h | 2 +
> include/linux/mmzone.h | 1 +
> include/linux/radix-tree.h | 32 +---
> include/linux/swap.h | 1 +
> lib/radix-tree.c | 36 --
> mm/filemap.c | 77 +++--
> mm/list_lru.c | 8 +++
> mm/truncate.c | 20 +++-
> mm/vmstat.c| 1 +
> mm/workingset.c| 121
> +
> 10 files changed, 259 insertions(+), 40 deletions(-)
>
> diff --git a/include/linux/list_lru.h b/include/linux/list_lru.h
> index 3ce541753c88..b02fc233eadd 100644
> --- a/include/linux/list_lru.h
> +++ b/include/linux/list_lru.h
> @@ -13,6 +13,8 @@
> /* list_lru_walk_cb has to always return one of those */
> enum lru_status {
> LRU_REMOVED,/* item removed from list */
> + LRU_REMOVED_RETRY, /* item removed, but lock has been
> +dropped and reacquired */
> LRU_ROTATE, /* item referenced, give another pass */
> LRU_SKIP, /* item cannot be locked, skip */
> LRU_RETRY, /* item not freeable. May drop the lock
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 118ba9f51e86..8cac5a7ef7a7 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -144,6 +144,7 @@ enum zone_stat_item {
> #endif
> WORKINGSET_REFAULT,
> WORKINGSET_ACTIVATE,
> + WORKINGSET_NODERECLAIM,
> NR_ANON_TRANSPARENT_HUGEPAGES,
> NR_FREE_CMA_PAGES,
> NR_VM_ZONE_STAT_ITEMS };
> diff --git a/include/linux/radix-tree.h b/include/linux/radix-tree.h
> index 13636c40bc42..33170dbd9db4 100644
> --- a/include/linux/radix-tree.h
> +++ b/include/linux/radix-tree.h
> @@ -72,21 +72,37 @@ static inline int radix_tree_is_indirect_ptr(void *ptr)
> #define RADIX_TREE_TAG_LONGS \
> ((RADIX_TREE_MAP_SIZE + BITS_PER_LONG - 1) / BITS_PER_LONG)
>
> +#define RADIX_TREE_INDEX_BITS (8 /* CHAR_BIT */ * sizeof(unsigned long))
> +#define RADIX_TREE_MAX_PATH (DIV_ROUND_UP(RADIX_TREE_INDEX_BITS, \
> + RADIX_TREE_MAP_SHIFT))
> +
> +/* Height component in node->path */
> +#define RADIX_TREE_HEIGHT_SHIFT (RADIX_TREE_MAX_PATH + 1)
> +#define RADIX_TREE_HEIGHT_MASK ((1UL << RADIX_TREE_HEIGHT_SHIFT) - 1)
> +
> +/* Internally used bits of node->count */
> +#define RADIX_TREE_COUNT_SHIFT (RADIX_TREE_MAP_SHIFT + 1)
> +#define RADIX_TREE_COUNT_MASK((1UL << RADIX_TREE_COUNT_SHIFT) -
Re: [PATCH 9/9] printk: Hand over printing to console if printing too long
On Mon 06-01-14 10:46:08, Jan Kara wrote: > On Sat 04-01-14 23:57:43, Andrew Morton wrote: > > On Mon, 23 Dec 2013 21:39:30 +0100 Jan Kara wrote: > > > > > Currently, console_unlock() prints messages from kernel printk buffer to > > > console while the buffer is non-empty. When serial console is attached, > > > printing is slow and thus other CPUs in the system have plenty of time > > > to append new messages to the buffer while one CPU is printing. Thus the > > > CPU can spend unbounded amount of time doing printing in console_unlock(). > > > This is especially serious problem if the printk() calling > > > console_unlock() was called with interrupts disabled. > > > > > > In practice users have observed a CPU can spend tens of seconds printing > > > in console_unlock() (usually during boot when hundreds of SCSI devices > > > are discovered) resulting in RCU stalls (CPU doing printing doesn't > > > reach quiescent state for a long time), softlockup reports (IPIs for the > > > printing CPU don't get served and thus other CPUs are spinning waiting > > > for the printing CPU to process IPIs), and eventually a machine death > > > (as messages from stalls and lockups append to printk buffer faster than > > > we are able to print). So these machines are unable to boot with serial > > > console attached. Also during artificial stress testing SATA disk > > > disappears from the system because its interrupts aren't served for too > > > long. > > > > > > This patch implements a mechanism where after printing specified number > > > of characters (tunable as a kernel parameter printk.offload_chars), CPU > > > doing printing asks for help by setting a 'hand over' state. The CPU > > > still keeps printing until another CPU running printk() or a CPU being > > > pinged by an IPI comes and takes over printing. This way no CPU should > > > spend printing too long if there is heavy printk traffic. > > > > It all seems to rely on luck? If there are 100k characters queued and > > all the other CPUs stop calling printk(), the CPU which is left in > > printk is screwed, isn't it? If so, perhaps it can send an async IPI > > to ask for help? > Let me cite a sentence from the changelog: > "... until another CPU running printk() or a CPU being pinged by an IPI > comes and takes over printing." > > So sending IPI (async one) to another CPU to come and take over printing > is already implemented :). Do you have a better suggestion how to make that > more obvious in the changelog? Ping Andrew, did you have a look at the patch? Honza -- Jan Kara SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[STABLE] find missing bug fixes in a stable kernel
We have several long-term and extended stable kernels, and it's possible that a bug fix is in some stable versions but is missing in some other versions, so I've written a script to find out those fixes. Take 3.4.xx and 3.2.xx for example. If a bug fix was merged into upstream kernel after 3.4, and then it was backported to 3.2.xx, then it probably needs to be backported to 3.4.xx. The result is, there're ~430 bug fixes in 3.2.xx that probably need to be backported to 3.4.xx. Given there're about 4500 commits in 3.2.xx, that is ~10%, which is quite a big number for stable kernels. We (our team in Huawei) are going to go through the whole list to filter out fixes that're applicable for 3.4.xx. I've attached the lists for 3.4 and 3.10. If a commit ID appears more than once in changelogs, it's possible that's because the commit was reverted later, so I tagged this kind of commits in the lists. [upstream commit][stable commit][occurrences] 8c4f3c3fa968 874d3954a35c 2 1 8821f5dc187b 0b568069764b b963a22e6d1a 245d4b4480c2 3806b45ba465 cf3f5a3dbf78 ff88b4724fde 325aa5f2c582 503cf95c061a 4fe644c42cb5 230c83afdd9c 8bd981aa4b60 8b3b005d6757 612e9718fa79 8704211f65a2 75a4cfafc737 43659222e7a0 cb80debe9515 89f4d45b2752 47c55eb0a98d 9dda2769af4f 8ccf25d7c629 ba4c4d0a9021 b7536448ffe4 2fea6cd303c0 6f4847186175 1b672224d128 e06c33874253 46a51c80216c dccfb68c2630 8e7ee6f5dfb5 56f1f4bb5770 2435dcb98cfe 6b7cfe5a757a 84b073868b9d 36d04a55f34a 4a82fd7c4e78 a687a58fd0fa 365da4adebb1 bca06620c941 b1d93356427b baf48b7f96f5 6408eac26659 ad308321f9f9 4e9b45a19241 f2414ee66a29 ad5066d4c2b1 fa01206912e5 0c5d63f0ab67 8e1028cb190c 603e7729920e 434700a29d1e 522e66464467 d8c3245c9749 778d226a1462 2a4c85e77b4b 8f42d7698751 9712d74ae818 59c8e66378fb d81980f44bbc f262f0f5cad0 898c8e6f4386 27ef63c7e97d da4eda14795e 9f961a5f6efc 17318fb39430 954a73d5d307 75b23979f42e f74b75e7f920 4a6c6bb2be9c 7b6bc07ab554 d83ceadbcef3 e92aee330837 40c8b4ee658b dcc01c086482 7e6337b69496 b5e2f339865f 840834b57880 58932e96e438 5874fd1d23ed bc5bd37ce48c 2afe1a102cd3 3edc8376c061 640c4ad6d759 3f0116c3238a 8b7a25d8eb78 3f3f8d2f48ac c12558716007 61875f30daf6 ee698d67a4af 638298dc66ea 21f58875dda7 455f58925247 3585a755cec3 f217c980ca98 dc77997de6b3 25f2bd7f5add 83e92c513be4 08a5dd3842f2 a6f20aa6d2d1 20ecf9fd3beb 24d009c5a58b 6329b8d917ad f9ec1e9afbfe bf378d341e48 d08b0a5594dd 75c7caf5a052 498a727b33ee 5676005acf26 8f0ce108f5e1 d1211af3049f 28cfcc851d5c 8f21bd009005 0b2d10f8f2e6 7f42ec394156 ccebcc74c81d 85601f8cf67c 798761949ee8 b62cd96de316 47bd9ac912fe f875fdbf344b c9e34fa1d28f 19b85cfb190e 4f31ab80a2bf fc0919c68cb2 73449fe73fa3 38a172bef8c9 f1f1e271a236 0a3658cccdf5 50a0ff96891f 855f5f1d882a b8f651365224 cc6b54aa54bf 32eed83c07cc cac6a5ae0118 fbeecda256ba efeb9e60d48f b5f9e3533584 2e923a0527ac 9eb9bfa030d8 280847b53243 559a2e36f047 06a7c3c27814 941781515755 18e391862cce c68d59cb0bd6 9d8924297cd9 bc96269f7222 69820e01aa75 60d3bfb16dc6 73d9f7eef3d9 be47dfad8e39 212a871a3934 384a27453c74 df0cfd699034 c3ffb34128a3 2b29a9fdcb92 13380d462256 41aacc1eea64 ac8905cf6be3 b22ce2785d97 fbbd6511ab0d f5f6cbb61610 c349bf07d6c0 d74c6d514fe3 efd99ef3a97b 4704fe4f03a5 5e72fdb8d827 ff8a43c10f14 8ab959a23fae e877dd2f2581 c372ce3c31bf d482b9d55860 735143e24807 4c2aee0032b7 81b043782e78 5ece263f1d93 ea8e22401547 6fab3febf6d9 d03160d52da8 757c4f6260fe eb4a22ba43d9 ddb6b5a96437 4f440a7abb7c 9186a1fd9ed1 14d747003cb7 d8a083cc7466 6380025aff79 acfdd4b1f759 2c8efb72eb19 1d5b569ef85d b395e4661bfa 1ebd0b21ab14 39a53ec969b5 5b77a1f3d7b7 ba1251e87fc4 84eb2ae1807d fb2e4631a7e2 178c059e7640 ff98736cbbbe 0fc110f4e4f5 64bb65c2cc9b a1923f1d4723 5e61ced05ec8 707aee401d24 c971eae7d1ca 0439f31c35d1 70bea7f2c038 bd5fe738e388 0aaf4c42a313 61ac51301e6c d546eadecc19 5dae5fd24071 2ca3bc2ba143 5f8a2e68b679 3c574b0665d5 4b18f08be01a 1f8adde06e86 e4daf1ffbe6c 6fa3efc24bdb 96f15f29038e 6af864ccfe6d f7929f34fa0e b8aea41ad64a d52392b1a804 8dd6177dc6b5 7ae48b56f8d9 a35561fe3af2 86f0b5b86d14 4bcfe68e7e4d 61be2b9a18ec 8ac7e3f3ac40 46f6c1aaf790 272f254b2719 5be1efb4c2ed e93a7f00a3db 9538aa46c242 a4d0e7c132a9 5b9ab3f7324a 28518ed66242 cc7282b8d5ab 53fcffc423f4 60478295d687 c0a05a14a4e7 016fcab8ff46 95d909e86710 8e3f8755545c 9371cadbbcc7 8d9256906a97 79c4d036e08c c378f70adbc1 b5f8e9877fee 8246aca7058f 1aa33199c596 14611e51a57d 2235df8b82f6 7e6d72c15ff4 809feb1735e5 6241f22ca12a e4498ad1ef9c b0df96a0068d 93cfcb8c998e 3f6fa3d489e1 a1b0505ef3db 1cfc7df3de10 d23288a5a9fb 414abbd2cd4c 2af951daef68 35848f68b07d e4af376d04b0 bddee96b5d0d 28009d3918aa 696df78509d1 df8c1e2ba1f2 77d848372875 9990a882ec3c 30d5b709da23 041aacd868cd 693026ef2e75 51f2a0a803cd 5863e10b441e e1c3e37d2c1d 12a7ad3b810e 624d1705fa1d 39a9b8ac9333 29c303b89a1b 57ab048532c0 9e443904906c 2 2 6030ea9b3597 fd162a76f160 b996ac90f595 4e9169bee6bc dbda92d16f86 ff766b8d26c7 698b82236314 21544884d7d5 b8cb62f82103 b35b16d2be61 f8b8404337de 134c3faa909c d1603990ea62 ea3d15ac86cb bf593907f723 e4f37de094d8 df465abfe06f 08647d0f99db 2d8f4447b58b
[PATCHv2 4/6] ASoC: simple-card: add sound-widgets usage
Signed-off-by: Xiubo Li
---
Documentation/devicetree/bindings/sound/simple-card.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/simple-card.txt
b/Documentation/devicetree/bindings/sound/simple-card.txt
index e9e20ec..01eb2d0 100644
--- a/Documentation/devicetree/bindings/sound/simple-card.txt
+++ b/Documentation/devicetree/bindings/sound/simple-card.txt
@@ -15,6 +15,10 @@ Optional properties:
Each entry is a pair of strings, the
first being the
connection's sink, the second being
the connection's
source.
+- sound-widgets: The name of the audio card's
off-CODEC widgets. If the
+ audio card need the off-CODEC
widgets, the card driver
+ should register its widgets with one
specified name:
+ "", and in dt node the
sound-widgets = "".
Required subnodes:
@@ -42,6 +46,7 @@ Example:
sound {
compatible = "simple-audio-card";
+ sound-widgets = "widgets"
simple-audio-card,format = "left_j";
simple-audio-routing =
"MIC_IN", "Mic Jack",
--
1.8.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/
[PATCHv2 6/6] ARM: dts: Enable SGTL5000 codec based audio driver node for VF610 TOWER.
This patch adds and enables SGTL5000 codec support, and also specified
the corresponding SAI node.
Signed-off-by: Xiubo Li
---
arch/arm/boot/dts/vf610-twr.dts | 47 +
1 file changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
index e60c20c..acc860a 100644
--- a/arch/arm/boot/dts/vf610-twr.dts
+++ b/arch/arm/boot/dts/vf610-twr.dts
@@ -34,6 +34,43 @@
};
};
+ regulators {
+ compatible = "simple-bus";
+
+ reg_3p3v: 3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ sound-widgets = "vf610-sgtl5000";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,routing =
+ "MIC_IN", "Mic Jack",
+ "Mic Jack", "Mic Bias",
+ "LINE_IN", "Line In Jack",
+ "Headphone Jack", "HP_OUT",
+ "Ext Spk", "LINE_OUT";
+
+ simple-audio-card,cpu {
+ sound-dai = <>;
+ master-clkdir-out;
+ frame-master;
+ bitclock-master;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <>;
+ frame-master;
+ bitclock-master;
+ };
+ };
+
};
{
@@ -72,9 +109,19 @@
pinctrl-names = "default";
pinctrl-0 = <_i2c0_1>;
status = "okay";
+
+ codec: sgtl5000@0a {
+ #sound-dai-cells = <0>;
+ compatible = "fsl,sgtl5000";
+ reg = <0x0a>;
+ VDDA-supply = <_3p3v>;
+ VDDIO-supply = <_3p3v>;
+ clocks = < VF610_CLK_SAI2>;
+ };
};
{
+ #sound-dai-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <_sai2_1>;
status = "okay";
--
1.8.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/
[PATCHv2 0/6] One simple card use case
This patch series is one use case of simple card driver based on dts. For some audio cards they need to add some off-CODEC widgets. For the audio card, if it needs off-CODEC widgets, some explict code for a simple audio is needed, if not, just ignore of this. This can make the audio card driver simpler and easier to debug by using the simple card driver and some explict code if needed. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 1/6] ASoC: core: add off-CODEC widgets list register/unregister
This will be need for some audio card, which maybe using the simple
card and the off-CODEC widgets is needed.
Signed-off-by: Xiubo Li
---
include/sound/soc.h | 10 ++
sound/soc/soc-core.c | 39 +++
2 files changed, 49 insertions(+)
diff --git a/include/sound/soc.h b/include/sound/soc.h
index 03ce45b..23f9572 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -326,6 +326,7 @@ struct snd_soc_platform_driver;
struct snd_soc_codec;
struct snd_soc_codec_driver;
struct snd_soc_component;
+struct snd_soc_widgets;
struct snd_soc_component_driver;
struct soc_enum;
struct snd_soc_jack;
@@ -385,6 +386,8 @@ int devm_snd_soc_register_component(struct device *dev,
const struct snd_soc_component_driver *cmpnt_drv,
struct snd_soc_dai_driver *dai_drv, int num_dai);
void snd_soc_unregister_component(struct device *dev);
+int snd_soc_register_widgets(struct snd_soc_widgets *wdg);
+void snd_soc_unregister_widgets(struct snd_soc_widgets *wdg);
int snd_soc_codec_volatile_register(struct snd_soc_codec *codec,
unsigned int reg);
int snd_soc_codec_readable_register(struct snd_soc_codec *codec,
@@ -664,6 +667,13 @@ struct snd_soc_component {
const struct snd_soc_component_driver *driver;
};
+struct snd_soc_widgets {
+ const char *name;
+ struct list_head list;
+ const struct snd_soc_dapm_widget *widgets;
+ unsigned int cnt;
+};
+
/* SoC Audio Codec device */
struct snd_soc_codec {
const char *name;
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 3a128f0..9adcada 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -3821,6 +3821,45 @@ int snd_soc_unregister_card(struct snd_soc_card *card)
}
EXPORT_SYMBOL_GPL(snd_soc_unregister_card);
+static DEFINE_MUTEX(widgets_mutex);
+static LIST_HEAD(widgets_list);
+/**
+ * snd_soc_register_widgets - Register off codec widgets with
+ * the ASoC core
+ *
+ * @wdg: widgets to register
+ *
+ */
+int snd_soc_register_widgets(struct snd_soc_widgets *wdg)
+{
+ int ret;
+
+ if (!wdg)
+ return -EINVAL;
+
+ mutex_lock(_mutex);
+ list_add(>list, _list);
+ mutex_unlock(_mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(snd_soc_register_widgets);
+
+/**
+ * snd_soc_unregister_widgets - Unregister off codec widgets with
+ * the ASoC core
+ *
+ * @wdg: widgets to unregister
+ *
+ */
+void snd_soc_unregister_widgets(struct snd_soc_widgets *wdg)
+{
+ mutex_lock(_mutex);
+ list_del(>list);
+ mutex_unlock(_mutex);
+}
+EXPORT_SYMBOL_GPL(snd_soc_unregister_widgets);
+
/*
* Simplify DAI link configuration by removing ".-1" from device names
* and sanitizing names.
--
1.8.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/
[PATCHv2 3/6] ASoC: simple-card: simple audio card widgets getting
Signed-off-by: Xiubo Li
---
sound/soc/generic/simple-card.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index b7dc63e..dbd93cc 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -125,6 +125,7 @@ static int asoc_simple_card_parse_of(struct device_node
*node,
struct device_node **of_codec,
struct device_node **of_platform)
{
+ struct snd_soc_widgets *wdg;
struct device_node *np;
char *name;
int ret;
@@ -133,6 +134,14 @@ static int asoc_simple_card_parse_of(struct device_node
*node,
info->daifmt = snd_soc_of_parse_daifmt(node, "simple-audio-card,") &
(SND_SOC_DAIFMT_FORMAT_MASK | SND_SOC_DAIFMT_INV_MASK);
+ wdg = snd_soc_get_widgets(node);
+ if (!IS_ERR_OR_NULL(wdg)) {
+ info->snd_card.dapm_widgets = wdg->widgets;
+ info->snd_card.num_dapm_widgets = wdg->cnt;
+ } else if (IS_ERR(wdg)) {
+ return PTR_ERR(wdg);
+ }
+
/* DAPM routes */
if (of_property_read_bool(node, "simple-audio-card,routing")) {
ret = snd_soc_of_parse_audio_routing(>snd_card,
--
1.8.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/
linux-next: Tree for Jan 13
Hi all, This tree fails (more than usual) the powerpc allyesconfig build. Changes since 20140110: Dropped tree: sh (complex merge conflicts against very old commits) The powerpc tree still had its build failure. The sound-asoc tree gained a conflict against the slave-dma tree. The mmc tree gained a conflict against Linus' tree. The tip tree gained conflicts against the net-next, xtense and pm trees. The kvm tree still had its build failure so I used the version from next-20140109. The workqueues gained a conflict against with Linus' tree. The clk tree gained conflicts against the v4l-dvb and arm-soc trees. The akpm tree gained a conflict against the tip tree. Non-merge commits (relative to Linus' tree): 7799 7424 files changed, 367590 insertions(+), 189373 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. I am currently merging 209 trees (counting Linus' and 29 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (7e22e91102c6 Linux 3.13-rc8) Merging fixes/master (b0031f227e47 Merge tag 's2mps11-build' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator) Merging kbuild-current/rc-fixes (19514fc665ff arm, kbuild: make "make install" not depend on vmlinux) Merging arc-current/for-curr (1e01c7eb7c43 ARC: Allow conditional multiple inclusion of uapi/asm/unistd.h) Merging arm-current/fixes (d6cd989477e2 ARM: 7939/1: traps: fix opcode endianness when read from user memory) Merging m68k-current/for-linus (77a42796786c m68k: Remove deprecated IRQF_DISABLED) Merging metag-fixes/fixes (3b2f64d00c46 Linux 3.11-rc2) Merging powerpc-merge/merge (f991db1cf1bd Merge remote-tracking branch 'agust/merge' into merge) Merging sparc/master (ef350bb7c5e0 Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4) Merging net/master (228fdc083b01 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging ipsec/master (965cdea82569 dccp: catch failed request_module call in dccp_probe init) Merging sound-current/for-linus (150116bcfbd9 ALSA: hiface: Fix typo in 352800 rate definition) Merging pci-current/for-linus (f0b75693cbb2 MAINTAINERS: Add DesignWare, i.MX6, Armada, R-Car PCI host maintainers) Merging wireless/master (2eff7c791a18 Merge tag 'nfc-fixes-3.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-fixes) Merging driver-core.current/driver-core-linus (413541dd66d5 Linux 3.13-rc5) Merging tty.current/tty-linus (413541dd66d5 Linux 3.13-rc5) Merging usb.current/usb-linus (413541dd66d5 Linux 3.13-rc5) Merging staging.current/staging-linus (413541dd66d5 Linux 3.13-rc5) Merging char-misc.current/char-misc-linus (802eee95bde7 Linux 3.13-rc6) Merging input-current/for-linus (8e2f2325b73f Input: xpad - add new USB IDs for Logitech F310 and F710) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (efb753b8e013 crypto: ixp4xx - Fix kernel compile error) Merging ide/master (c2f7d1e103ef ide: pmac: remove unnecessary pci_set_drvdata()) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging sh-current/sh-fixes-for-linus (44033109e99c SH: Convert
[PATCHv2 5/6] ASoC: fsl: Add VF610 simple audio card widgets driver.
This is the SGTL5000 codec based off-CODEC widgets supports.
Signed-off-by: Xiubo Li
---
sound/soc/fsl/Kconfig | 25 ++
sound/soc/fsl/Makefile| 3 +++
sound/soc/fsl/snd-soc-simple-card-vf610.c | 43 +++
3 files changed, 71 insertions(+)
create mode 100644 sound/soc/fsl/snd-soc-simple-card-vf610.c
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 324988d..1a09028 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -219,3 +219,28 @@ config SND_SOC_IMX_MC13783
select SND_SOC_IMX_PCM_DMA
endif # SND_IMX_SOC
+
+menuconfig SND_VF610_SOC
+ tristate "SoC Audio for Freescale VF610 CPUs"
+ select DMA_ENGINE
+ help
+ Say Y or M if you want to add support for codecs attached to
+ the VF610 CPUs.
+
+ This will enable Freeacale SAI and SGTL5000 codec, and an extra
+ TWR-AUDIO-SGTL sub-board is needed for SGTL5000.
+
+if SND_VF610_SOC
+
+config SND_SOC_VF610_SGTL5000
+ tristate "SoC Audio support for VF610 boards with SGTL5000"
+ depends on OF && I2C
+ select SND_SOC_FSL_SAI
+ select SND_SOC_SGTL5000
+ select SND_SIMPLE_CARD
+ help
+ Say Y if you want to add support for SoC audio on an VF610 board with
+ a SGTL5000 codec and a SAI.
+
+
+endif #SND_VF610_SOC
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index b12ad4b..668cead 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -60,3 +60,6 @@ obj-$(CONFIG_SND_SOC_IMX_SGTL5000) += snd-soc-imx-sgtl5000.o
obj-$(CONFIG_SND_SOC_IMX_WM8962) += snd-soc-imx-wm8962.o
obj-$(CONFIG_SND_SOC_IMX_SPDIF) += snd-soc-imx-spdif.o
obj-$(CONFIG_SND_SOC_IMX_MC13783) += snd-soc-imx-mc13783.o
+
+# Simple audio card widgets Support
+obj-$(CONFIG_SND_SOC_VF610_SGTL5000) += snd-soc-simple-card-vf610.o
diff --git a/sound/soc/fsl/snd-soc-simple-card-vf610.c
b/sound/soc/fsl/snd-soc-simple-card-vf610.c
new file mode 100644
index 000..ee28748
--- /dev/null
+++ b/sound/soc/fsl/snd-soc-simple-card-vf610.c
@@ -0,0 +1,43 @@
+/*
+ * ASoC VF610 SGTL5000 off-CODEC widgets support
+ *
+ * Copyright 2014 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+
+static const struct snd_soc_dapm_widget vf610_sgtl5000_dapm_widgets[] = {
+ SND_SOC_DAPM_MIC("Mic Jack", NULL),
+ SND_SOC_DAPM_LINE("Line In Jack", NULL),
+ SND_SOC_DAPM_HP("Headphone Jack", NULL),
+ SND_SOC_DAPM_SPK("Line Out Jack", NULL),
+ SND_SOC_DAPM_SPK("Ext Spk", NULL),
+};
+
+struct snd_soc_widgets vf610_sgtl5000_widgets = {
+ .name = "vf610-sgtl5000",
+ .widgets = vf610_sgtl5000_dapm_widgets,
+ .cnt = ARRAY_SIZE(vf610_sgtl5000_dapm_widgets),
+};
+
+static int __init __vf610_sgtl5000_widgets_init(void)
+{
+ return snd_soc_register_widgets(_sgtl5000_widgets);
+}
+module_init(__vf610_sgtl5000_widgets_init);
+
+static void __exit __vf610_sgtl5000_widgets_exit(void)
+{
+ snd_soc_unregister_widgets(_sgtl5000_widgets);
+}
+module_exit(__vf610_sgtl5000_widgets_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:vf610-simple-card-widgets");
+MODULE_DESCRIPTION("ASoC Simple Sound Card Widgets");
+MODULE_AUTHOR("Xiubo Li ");
--
1.8.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/
[PATCHv2 2/6] ASoC: core: add snd_soc_get_widgets
Add widgets list getting.
Signed-off-by: Xiubo Li
---
include/sound/soc.h | 1 +
sound/soc/soc-core.c | 31 +++
2 files changed, 32 insertions(+)
diff --git a/include/sound/soc.h b/include/sound/soc.h
index 23f9572..f352333 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -388,6 +388,7 @@ int devm_snd_soc_register_component(struct device *dev,
void snd_soc_unregister_component(struct device *dev);
int snd_soc_register_widgets(struct snd_soc_widgets *wdg);
void snd_soc_unregister_widgets(struct snd_soc_widgets *wdg);
+struct snd_soc_widgets *snd_soc_get_widgets(struct device_node *np);
int snd_soc_codec_volatile_register(struct snd_soc_codec *codec,
unsigned int reg);
int snd_soc_codec_readable_register(struct snd_soc_codec *codec,
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 9adcada..e1d26e6 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -3860,6 +3860,37 @@ void snd_soc_unregister_widgets(struct snd_soc_widgets
*wdg)
}
EXPORT_SYMBOL_GPL(snd_soc_unregister_widgets);
+struct snd_soc_widgets *snd_soc_get_widgets(struct device_node *np)
+{
+ struct snd_soc_widgets *wdg;
+ const char *string;
+ int ret;
+
+ if (!np)
+ return ERR_PTR(-EINVAL);
+
+ if (!of_property_read_bool(np, "sound-widgets"))
+ return NULL;
+
+ ret = of_property_read_string(np, "sound-widgets",
+ );
+ if (ret < 0)
+ return ERR_PTR(ret);
+
+ mutex_lock(_mutex);
+ list_for_each_entry(wdg, _list, list) {
+ if (!strcmp(string, wdg->name)) {
+ mutex_unlock(_mutex);
+ return wdg;
+ }
+
+ }
+ mutex_unlock(_mutex);
+
+ return ERR_PTR(-EPROBE_DEFER);
+}
+EXPORT_SYMBOL_GPL(snd_soc_get_widgets);
+
/*
* Simplify DAI link configuration by removing ".-1" from device names
* and sanitizing names.
--
1.8.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] ARM: shmobile: compile drivers/sh for CONFIG_ARCH_SHMOBILE_MULTI
On 12/01/14 22:01, Laurent Pinchart wrote: Hi Ben, On Sunday 12 January 2014 22:54:15 Laurent Pinchart wrote: Hi Ben, Thank you for the patch. On Saturday 11 January 2014 13:06:29 Ben Dooks wrote: If the kernel is built to support multi-arm configurmation with shmobile support built in, then the drivers/sh is not built. This contains drivers that are essential to devices support by that configuration, including the PM runtime code in drivers/sh/pm_runtime.c (which implicitly enables the bus clocks for all devices). Thinking a bit more about this, I think the approach taken in drivers/sh/pm_runtime.c isn't good. The code enables device clocks when devices are bound to a driver, increasing power consumption when devices are idle. Instead of enabling it for ARCH_SHMOBILE_MULTI I'd like to either add explicit clock support to drivers, or to integrate clocks with runtime PM only. If pm-runtime is enabled, then I believe that the device clocks are kept in sync with the active state of the device, which means that they should be shut down when the device is not needed. There have been recent discussions about this with respect to the PCI bridges used by the USB host system. Given the above, I'm not sure exactly what you mean by the statement "I think the approach taken in drivers/sh/pm_runtime.c isn't good." as if we're going to abstract the clock management we have the following issues. - If pm-runtime is not enabled then we need something to manage the clocks for the driver. If we put that code in the driver then there is not a lot of point in having the pm-runtime clock code here as the driver really only needs a helper to turn them on and off at the right place. - If just standard power management is enabled, then do we really care about the power consumption of leaving peripherals running when their devices are bound? Managing the device clock optimally is hardly a concern if device drivers are not going to be idled when they are not being used. When discussing this on freenode's #armkernel channel, several people including Mark Brown wanted to keep this as it made driver's handling of clocks much easier (there was no longer any need to deal with the clk code when writing a simple driver). My view is it is a pain as we now have a mix of drivers which expect to do their own clock work and some that do not. (It is possible there are even some shmobile drivers that still do their own clock management). Personally I do not like hiding the implementation of this, as it ends up confusing people when they first come to it. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] power: clock_ops.c: fixup clk prepare/unprepare count
On 12/01/14 22:04, Laurent Pinchart wrote:
Hi Ben,
Thank you for the patch.
On Saturday 11 January 2014 13:05:38 Ben Dooks wrote:
The drivers/base/power/clock_ops.c file is causing warnings from
the clock driver (as shown below) due to failing to do a clk_prepare()
call before enabling a clock. It also fails to check the balance of
prepare/unprepare as __pm_clk_remove() do clk_disable_unprepare() call.
This bug has probably been in since commit b2476490e ("clk: introduce
the common clock framework") as the warning was part of the original
commit. It is strange that it has not been noticed (although this has
also been coupled with a failure for certain SH builds to not build the
necessary glue to use this method of controlling the clocks).
In summary, this is probably needed in several stable branches but need
advice on which ones.
On the Renesas Lager board, this causes numerous warnings of the following
and even worse the clock system will not enable clocks, causing drivers
that are in development to fail to work:
WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:883 __clk_enable+0x2c/0xa0()
I've never noticed this on Lager, probably because Lager multiplatform doesn't
make use of clock_ops.c as drivers/sh/pm_runtime.c (which you addressed in
another patch that I've also replied to). I'm thus not sure we need to apply
this as a fix and backport it to stable branches.
Yes, it seems that a lot of the lager drivers assume that this support
is there, and the work seems to have been sponsored by Renesas.
I think there must be people still building the old style of kernel
as there is still work going on for board-lager.c which leads me to
being a bit surprised that no-one had noticed this (as it isn't as
if it produces a pile of warnings on the console output).
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm/swap: fix race on swap_info reuse between swapoff and swapon
On Mon, Jan 13, 2014 at 11:51:42AM +0800, Weijie Yang wrote: > On Mon, Jan 13, 2014 at 11:27 AM, Andrew Morton > wrote: > > On Mon, 13 Jan 2014 11:08:58 +0800 Weijie Yang > > wrote: > > > >> >> --- a/mm/swapfile.c > >> >> +++ b/mm/swapfile.c > >> >> @@ -1922,7 +1922,6 @@ SYSCALL_DEFINE1(swapoff, const char __user *, > >> >> specialfile) > >> >> p->swap_map = NULL; > >> >> cluster_info = p->cluster_info; > >> >> p->cluster_info = NULL; > >> >> - p->flags = 0; > >> >> frontswap_map = frontswap_map_get(p); > >> >> spin_unlock(>lock); > >> >> spin_unlock(_lock); > >> >> @@ -1948,6 +1947,16 @@ SYSCALL_DEFINE1(swapoff, const char __user *, > >> >> specialfile) > >> >> mutex_unlock(>i_mutex); > >> >> } > >> >> filp_close(swap_file, NULL); > >> >> + > >> >> + /* > >> >> + * clear SWP_USED flag after all resources freed > >> >> + * so that swapon can reuse this swap_info in alloc_swap_info() > >> >> safely > >> >> + * it is ok to not hold p->lock after we cleared its SWP_WRITEOK > >> >> + */ > >> >> + spin_lock(_lock); > >> >> + p->flags = 0; > >> >> + spin_unlock(_lock); > >> >> + > >> >> err = 0; > >> >> atomic_inc(_poll_event); > >> >> wake_up_interruptible(_poll_wait); > > But do you agree that your > > http://ozlabs.org/~akpm/mmots/broken-out/mm-swap-fix-race-on-swap_info-reuse-between-swapoff-and-swapon.patch > > makes Krzysztof's > > http://ozlabs.org/~akpm/mmots/broken-out/swap-fix-setting-page_size-blocksize-during-swapoff-swapon-race.patch > > obsolete? > > Yes, I agree. > > > I've been sitting on Krzysztof's > > swap-fix-setting-page_size-blocksize-during-swapoff-swapon-race.patch > > for several months - Hugh had issues with it so I put it on hold and > > nothing further happened. > > > >> I will try to resend a patchset to make lock usage in swapfile.c clear > >> and fine grit > > > > OK, thanks. In the meanwhile I'm planning on dropping Krzysztof's > > patch and merging your patch into 3.14-rc1, which is why I'd like > > confirmation that your patch addresses the issues which Krzysztof > > identified? > > > > I think so, Krzysztof and I both try to fix the same issue(reuse > swap_info while its > previous resources are not cleared completely). The different is > Krzysztof's patch > uses a global swapon_mutex and its commit log only focuses on set_blocksize(), > while my patch try to maintain the fine grit lock usage. > Maybe I should get some sleep first, but I found some minor nits. Newly introduced window: p->swap_map == NULL && (p->flags & SWP_USED) breaks swap_info_get: if (!(p->flags & SWP_USED)) goto bad_device; offset = swp_offset(entry); if (offset >= p->max) goto bad_offset; if (!p->swap_map[offset]) goto bad_free; so that would need a trivial adjustment. Another nit is that swap_start and swap_next do the following: if (!(si->flags & SWP_USED) || !si->swap_map) continue; Testing for swap_map does not look very nice and regardless of your patch the latter cannot be true if the former is not, thus the check can be simplified to mere !si->swap_map. I'm wondering if it would make sense to dedicate a flag (SWP_ALLOCATED?) to control whether swapon can use give swap_info. That is, it would be tested and set in alloc_swap_info & cleared like you clear SWP_USED now. SWP_USED would be cleared as it is and would be set in _enable_swap_info Then swap_info_get would be left unchanged and swap_* would test for SWP_USED only. -- Mateusz Guzik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ARM: shmobile: compile drivers/sh for CONFIG_ARCH_SHMOBILE_MULTI
On 13/01/14 00:30, Simon Horman wrote:
On Fri, Jan 10, 2014 at 03:18:15PM +, Ben Dooks wrote:
If the kernel is built to support multi-arm configurmation with shmobile
support built in, then the drivers/sh is not built. This contains drivers
that are essential to devices support by that configuration, including the
PM runtime code in drivers/sh/pm_runtime.c (which implicitly enables the
bus clocks for all devices).
If CONFIG_ARCH_SHMOBILE_MULTI then build the drivers/sh directory,
but ensure that bits that may conflict (drivers/sh/clk if the common
clock framework is not enabled) are built.
The ARCH_SHMOBILE_MULTI was added by efacfce5f8a ("ARM: shmobile: Introduce
ARCH_SHMOBILE_MULTI") but this has only just recently been found due to
building device-tree only kernels.
Cc: Linux Kernel list
Cc: Linus SH list
Cc: Simon Horman
Cc: Magnus Damm
Cc: Greg Kroah-Hartman
Signed-off-by: Ben Dooks
---
drivers/Makefile| 1 +
drivers/sh/Makefile | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/Makefile b/drivers/Makefile
index 8e3b8b0..abc4744 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -118,6 +118,7 @@ obj-$(CONFIG_SGI_SN)+= sn/
obj-y += firmware/
obj-$(CONFIG_CRYPTO) += crypto/
obj-$(CONFIG_SUPERH) += sh/
+obj-$(CONFIG_ARCH_SHMOBILE_MULTI) += sh/
obj-$(CONFIG_ARCH_SHMOBILE_LEGACY)+= sh/
Can't we just do the following?
I think this is probably a better fix. I am wondering what the original
logic of not doing this was.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] video: add OpenCores VGA/LCD framebuffer driver
On Mon, Jan 13, 2014 at 10:24:49AM +0900, Jingoo Han wrote:
> On Saturday, January 11, 2014 5:13 AM, Stefan Kristiansson wrote:
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
>
> Would you re-order these headers alphabetically?
> It enhances the readability.
>
OK
> [.]
>
> > +struct ocfb_dev {
> > + struct fb_info info;
> > + void __iomem *regs;
> > + /* flag indicating whether the regs are little endian accessed */
> > + int little_endian;
> > + /* Physical and virtual addresses of framebuffer */
> > + phys_addr_t fb_phys;
> > + void __iomem *fb_virt;
> > + u32 pseudo_palette[PALETTE_SIZE];
> > +};
>
> Here, 'fb_virt' is already defined as 'void __iomem *'.
>
> [.]
>
> > + fbdev->info.fix.smem_start = fbdev->fb_phys;
> > + fbdev->info.screen_base = (void __iomem *)fbdev->fb_virt;
>
> Please remove unnecessary casting as below, because 'fb_virt' is already
> defined as 'void __iomem *'.
>
> + fbdev->info.screen_base = fbdev->fb_virt;
>
> > + fbdev->info.pseudo_palette = fbdev->pseudo_palette;
> > +
> > + /* Clear framebuffer */
> > + memset_io((void __iomem *)fbdev->fb_virt, 0, fbsize);
>
> Same here.
>
> + memset_io(fbdev->fb_virt, 0, fbsize);
>
Nice catch, will do.
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the akpm tree with the tip tree
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
kernel/softirq.c between commit c795eb55e740 ("sched/preempt, locking:
Rework local_bh_{dis,en}able()") from the tip tree and commit ("softirq:
use const char * const for softirq_to_name, whitespace neatening") from
the akpm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc kernel/softirq.c
index e60c41d0087a,527520152ad2..
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@@ -138,10 -149,9 +138,9 @@@ void _local_bh_enable(void
WARN_ON_ONCE(in_irq());
__local_bh_enable(SOFTIRQ_DISABLE_OFFSET);
}
-
EXPORT_SYMBOL(_local_bh_enable);
-static inline void _local_bh_enable_ip(unsigned long ip)
+void __local_bh_enable_ip(unsigned long ip, unsigned int cnt)
{
WARN_ON_ONCE(in_irq() || irqs_disabled());
#ifdef CONFIG_TRACE_IRQFLAGS
@@@ -155,8 -165,8 +154,8 @@@
/*
* Keep preemption disabled until we are done with
* softirq processing:
-*/
+*/
- preempt_count_sub(SOFTIRQ_DISABLE_OFFSET - 1);
+ preempt_count_sub(cnt - 1);
if (unlikely(!in_interrupt() && local_softirq_pending())) {
/*
pgpwEwxuh8yIv.pgp
Description: PGP signature
RE: [PATCH] ASoC: fsl-sai: Add device tree nodes and its availiable check
> > + if (!np || !of_device_is_available(np)) > > + return -ENODEV; > > + > > I would expect the of_device_is_available() check to be done by the > driver core rather than by individual drivers - every single driver > should have that check. Is this not happening? The check for np is OK > though. Yes, I hasn't found the core driver does that for now... And IMO this is needed since the SAI driver is only base dts. And maybe the device is not presently operational, but it might become operational in the future (for example, something is not plugged in, or switched off). Or A serious error was detected in the device, and it is unlikely to become operational without repair... And for now for the individual drivers, before calling the of_device_is_available the '!np' check is need, because: While in __of_device_is_available: > status = of_get_property(device, "status", ); > if (status == NULL) > return 1; The status value returned from 'of_get_property()' will be NULL in two cases: Firstly: the 'device' value (device node) is NULL. Secondly: the 'status' property is actaully not exist. If the device node is NULL, the __of_device_is_available will return true too, that will mean the absent state of the 'status' property. Thanks, -- Best Regards, Xiubo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 mmotm/next] fanotify: fix corruption preventing startup
On Sat 11-01-14 22:54:15, Hugh Dickins wrote:
> Two of my machines couldn't boot mmotm with fanotify enabled:
> 0x4020 was being or'ed into a group's notification_waitq next
> pointer, with sad results. It comes from an over-simplification in
> fanotify_merge(): test_event isn't NULL when the loop finds no merge.
That's a really dumb bug. Thanks for the fix! It looks good, you can add:
Reviewed-by: Jan Kara
I was wondering why I didn't see this problem during my testing. I was
always running my tests with various debug options enabled (in a hope to
catch more problems ;), in particular with spinlock debugging enabled which
shifted the waitqueue pointers further and the corruption landed in
spinlock debugging fields and never got noticed... Ew :-|
Honza
>
> Signed-off-by: Hugh Dickins
> ---
> Fixes fsnotify-do-not-share-events-between-notification-groups.patch
>
> fs/notify/fanotify/fanotify.c |9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> --- mmotm/fs/notify/fanotify/fanotify.c 2014-01-10 18:25:01.700448941
> -0800
> +++ linux/fs/notify/fanotify/fanotify.c 2014-01-11 22:15:31.580961010
> -0800
> @@ -37,16 +37,19 @@ static bool should_merge(struct fsnotify
> static struct fsnotify_event *fanotify_merge(struct list_head *list,
>struct fsnotify_event *event)
> {
> - struct fsnotify_event *test_event = NULL;
> + struct fsnotify_event *test_event;
> + bool do_merge = false;
>
> pr_debug("%s: list=%p event=%p\n", __func__, list, event);
>
> list_for_each_entry_reverse(test_event, list, list) {
> - if (should_merge(test_event, event))
> + if (should_merge(test_event, event)) {
> + do_merge = true;
> break;
> + }
> }
>
> - if (!test_event)
> + if (!do_merge)
> return NULL;
>
> test_event->mask |= event->mask;
--
Jan Kara
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/2] ARM: imx: add select on ARCH_MXC for cpufreq support
On Sun, Jan 12, 2014 at 08:54:18PM -0800, John Tobias wrote: > I tested leaving the HAVE_IMX_ANATOP under SOC_IMX6Q and SOC_IMX6SL. > The iMX6Q cpufreq driver won't show up in menu config / gconfig and > that's the reason why I added it. I tested the following changes against my for-next branch, and I can see iMX6Q cpufreq driver in menuconfig. Note, the drivers/cpufreq/Kconfig.arm change is on cpufreq tree, so I have to make the change locally for the testing. Shawn diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index 1e70150..7071468 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -1,5 +1,7 @@ config ARCH_MXC bool "Freescale i.MX family" if ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 + select ARCH_HAS_CPUFREQ + select ARCH_HAS_OPP select ARCH_REQUIRE_GPIOLIB select ARM_CPU_SUSPEND if PM select ARM_PATCH_PHYS_VIRT @@ -12,6 +14,7 @@ config ARCH_MXC select MIGHT_HAVE_CACHE_L2X0 if ARCH_MULTI_V6_V7 select MULTI_IRQ_HANDLER select PINCTRL + select PM_OPP if PM select SOC_BUS select SPARSE_IRQ select USE_OF @@ -787,8 +790,6 @@ config SOC_IMX53 config SOC_IMX6Q bool "i.MX6 Quad/DualLite support" - select ARCH_HAS_CPUFREQ - select ARCH_HAS_OPP select ARM_ERRATA_754322 select ARM_ERRATA_764369 if SMP select ARM_ERRATA_775420 @@ -808,7 +809,6 @@ config SOC_IMX6Q select PL310_ERRATA_588369 if CACHE_PL310 select PL310_ERRATA_727915 if CACHE_PL310 select PL310_ERRATA_769419 if CACHE_PL310 - select PM_OPP if PM help This enables support for Freescale i.MX6 Quad processor. diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm index ce52ed9..21e069e 100644 --- a/drivers/cpufreq/Kconfig.arm +++ b/drivers/cpufreq/Kconfig.arm @@ -80,7 +80,7 @@ config ARM_HIGHBANK_CPUFREQ config ARM_IMX6Q_CPUFREQ tristate "Freescale i.MX6Q cpufreq support" - depends on SOC_IMX6Q + depends on ARCH_MXC depends on REGULATOR_ANATOP help This adds cpufreq driver support for Freescale i.MX6Q SOC. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [sched] 73628fba4: +69% context switches
On 01/11/2014 06:19 PM, Fengguang Wu wrote:
> Alex,
>
> FYI, we find much increased interrupts and context switches introduced
> by commit 73628fba4 ("sched: unify imbalance bias for target group")
> in your noload branch:
Many thanks for the generous and quick testing! :)
few questions for the results and give a testing patch for try. it also push on
github.
What's about the aim7 shell_rtns_1 and shared throughput?
>
> 7bea8c18805a5f1 73628fba451ae72221b155696
> --- -
> 14979 ~ 4% +1304.8% 210434 ~ 1% lkp-ne04/micro/aim7/shell_rtns_1
> 2748 ~ 5%+977.4% 29607 ~ 0% nhm-white/micro/aim7/shared
> 17727+1254.1% 240041 TOTAL interrupts.RES
RES interrupt increased about 200,000, but vmstat's interrupt increased a
little. guess the vmstat data is per seconds, right? If so, it is better give
how long time the vmstat running.
The same problem on the time.involuntary_context_switches and vmstat cs.
According to involuntary CS definition in time, RES interrupt will cause
involuntary CS. but here 29607 RES of aim7/shared cause 233218 time inv CS,
does sth I missed or the data is incorrect?
>
> 7bea8c18805a5f1 73628fba451ae72221b155696
> --- -
> 3617 ~ 0% +69.2% 6118 ~ 0% lkp-ne04/micro/aim7/shell_rtns_1
> 3617 +69.2% 6118 TOTAL vmstat.system.in
>
> 7bea8c18805a5f1 73628fba451ae72221b155696
> --- -
> 132746 ~ 0% +69.0% 224346 ~ 1% lkp-ne04/micro/aim7/shell_rtns_1
> 220038 ~ 0% +6.0% 233218 ~ 0% nhm-white/micro/aim7/shared
> 352785 +29.7% 457564 TOTAL
> time.involuntary_context_switches
>
> 7bea8c18805a5f1 73628fba451ae72221b155696
> --- -
>1424581 ~ 0% +8.6%1546786 ~ 0% lkp-ne04/micro/aim7/shell_rtns_1
>1424581 +8.6%1546786 TOTAL
> time.voluntary_context_switches
>
> 7bea8c18805a5f1 73628fba451ae72221b155696
> --- -
> 20982 ~ 0% +12.5% 23599 ~ 0% lkp-ne04/micro/aim7/shell_rtns_1
> 6005 ~ 0% +4.2% 6256 ~ 0% nhm-white/micro/aim7/shared
> 26988 +10.6% 29856 TOTAL vmstat.system.cs
>
> vmstat.system.cs
>
commit c5a8778a132cfa882609fbccb4ee6542eac9866d
Author: Alex Shi
Date: Mon Jan 13 13:54:30 2014 +0800
more bias towards local cpu group
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 2b216ad..046ca2c 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4008,7 +4008,6 @@ static int wake_affine(struct sched_domain *sd, struct
task_struct *p, int sync)
struct task_group *tg;
unsigned long weight;
int balanced;
- int bias = 100 + (sd->imbalance_pct -100) / 2;
/*
* If we wake multiple tasks be careful to not bounce
@@ -4020,7 +4019,7 @@ static int wake_affine(struct sched_domain *sd, struct
task_struct *p, int sync)
this_cpu = smp_processor_id();
prev_cpu = task_cpu(p);
load = source_load(prev_cpu);
- this_load = target_load(this_cpu, bias);
+ this_load = target_load(this_cpu, sd->imbalance_pct);
/*
* If sync wakeup then subtract the (maximum possible)
@@ -4055,7 +4054,7 @@ static int wake_affine(struct sched_domain *sd, struct
task_struct *p, int sync)
this_eff_load *= this_load +
effective_load(tg, this_cpu, weight, weight);
- prev_eff_load = bias;
+ prev_eff_load = 100 + (sd->imbalance_pct - 100) / 2;
prev_eff_load *= power_of(this_cpu);
prev_eff_load *= load + effective_load(tg, prev_cpu, 0, weight);
@@ -4100,7 +4099,6 @@ find_idlest_group(struct sched_domain *sd, struct
task_struct *p, int this_cpu)
{
struct sched_group *idlest = NULL, *group = sd->groups;
unsigned long min_load = ULONG_MAX, this_load = 0;
- int imbalance = 100 + (sd->imbalance_pct-100)/2;
do {
unsigned long load, avg_load;
@@ -4123,7 +4121,7 @@ find_idlest_group(struct sched_domain *sd, struct
task_struct *p, int this_cpu)
if (local_group)
load = source_load(i);
else
- load = target_load(i, imbalance);
+ load = target_load(i, sd->imbalance_pct);
avg_load += load;
}
--
Thanks
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/
Re: #pragma once?
On Sun, Jan 12, 2014 at 11:14:56AM -0500, Patrick Palka wrote: > On Mon, Jan 6, 2014 at 3:47 PM, Josh Triplett wrote: > > Does anyone have any objection to the use of "#pragma once" instead of > > the usual #ifndef-#define-...-#endif include guard? GCC, LLVM/clang, > > and the latest Sparse all support either method just fine. (I added > > support to Sparse myself.) Both have equivalent performance. "#pragma > > once" is simpler, and avoids the possibility of a typo in the defined > > guard symbol. > > Unfortunately in GCC #pragma once is slower and slightly buggier than > regular include guards: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52566 > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58770 The bug in question doesn't seem to apply to any likely use in the Linux kernel. As for performance, that benchmark seems somewhat odd to me, and I'm not entirely convinced that it's representative of real-world projects, which don't typically include ten thousand include files in one compilation. I've benchmarked the case of a single main.c including a single guarded.h with both types of guards, and found the two guard types indistinguishable in performance. Beyond that, I'd say real-world benchmarks would be preferable to artificial ones before declaring a performance difference between the two types of guards. - Josh Trpilett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 4/4] efi: Make efi virtual runtime map passing more robust
On 01/11/14 at 09:49pm, Borislav Petkov wrote:
> From: Borislav Petkov
>
> Currently, running SetVirtualAddressMap() and passing the physical
> address of the virtual map array was working only by a lucky coincidence
> because the memory was present in the EFI page table too. Until Toshi
> went and booted this on a big HP box - the krealloc() manner of resizing
> the memmap we're doing did allocate from such physical addresses which
> were not mapped anymore and boom:
>
> http://lkml.kernel.org/r/1386806463.1791.295.ca...@misato.fc.hp.com
>
> One way to take care of that issue is to reimplement the krealloc thing
> but with pages. We start with contiguous pages of order 1, i.e. 2 pages,
> and when we deplete that memory (shouldn't happen all that often but you
> know firmware) we realloc the next power-of-two pages.
>
> Having the pages, it is much more handy and easy to map them into the
> EFI page table with the already existing mapping code which we're using
> for building the virtual mappings.
>
> And, it doesn't matter all that much how much pages we've used as we're
> freeing them right after they've fulfilled their purpose at the end of
> the function anyway.
>
> Reported-by: Toshi Kani
> Signed-off-by: Borislav Petkov
> ---
> arch/x86/include/asm/efi.h | 3 +-
> arch/x86/platform/efi/efi.c| 62
> ++
> arch/x86/platform/efi/efi_32.c | 6 +++-
> arch/x86/platform/efi/efi_64.c | 31 +++--
> 4 files changed, 80 insertions(+), 22 deletions(-)
>
> diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
> index 3b978c472d08..0e7973f7492e 100644
> --- a/arch/x86/include/asm/efi.h
> +++ b/arch/x86/include/asm/efi.h
> @@ -130,7 +130,8 @@ extern void efi_memory_uc(u64 addr, unsigned long size);
> extern void __init efi_map_region(efi_memory_desc_t *md);
> extern void __init efi_map_region_fixed(efi_memory_desc_t *md);
> extern void efi_sync_low_kernel_mappings(void);
> -extern void efi_setup_page_tables(void);
> +extern int efi_setup_page_tables(unsigned long pa_memmap, unsigned
> num_pages);
> +extern void efi_cleanup_page_tables(unsigned long pa_memmap, unsigned
> num_pages);
> extern void __init old_map_region(efi_memory_desc_t *md);
>
> struct efi_setup_data {
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index c34be4ce94c9..65a8c969db87 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -948,14 +948,36 @@ static void __init efi_map_regions_fixed(void)
>
> }
>
> +static void *realloc_pages(void *old_memmap, int old_shift)
> +{
> + void *ret;
> +
> + ret = (void *)__get_free_pages(GFP_KERNEL, old_shift + 1);
> + if (!ret)
> + goto out;
> +
> + /*
> + * A first-time allocation doesn't have anything to copy.
> + */
> + if (!old_memmap)
> + return ret;
> +
> + memcpy(ret, old_memmap, PAGE_SIZE << old_shift);
> +
> +out:
> + __free_pages(old_memmap, old_shift);
> + return ret;
> +}
> +
> /*
> - * Map efi memory ranges for runtime serivce and update new_memmap with
> virtual
> - * addresses.
> + * Map the efi memory ranges of the runtime services and update new_mmap with
> + * virtual addresses.
> */
> -static void * __init efi_map_regions(int *count)
> +static void * __init efi_map_regions(int *count, int *pg_shift)
> {
> + void *p, *new_memmap = NULL;
> + unsigned long left = 0;
> efi_memory_desc_t *md;
> - void *p, *tmp, *new_memmap = NULL;
>
> for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
> md = p;
> @@ -970,20 +992,23 @@ static void * __init efi_map_regions(int *count)
> efi_map_region(md);
> get_systab_virt_addr(md);
>
> - tmp = krealloc(new_memmap, (*count + 1) * memmap.desc_size,
> -GFP_KERNEL);
> - if (!tmp)
> - goto out;
> - new_memmap = tmp;
> + if (left < memmap.desc_size) {
> + new_memmap = realloc_pages(new_memmap, *pg_shift);
> + if (!new_memmap)
> + return NULL;
> +
> + left += PAGE_SIZE << *pg_shift;
> + (*pg_shift)++;
> + }
> +
> memcpy(new_memmap + (*count * memmap.desc_size), md,
> memmap.desc_size);
> +
> + left -= memmap.desc_size;
Adding a safeguard check for desc_size is better though currently it's
impossible
for the desc_size > PAGE_SIZE?
> (*count)++;
> }
>
> return new_memmap;
> -out:
> - kfree(new_memmap);
> - return NULL;
> }
>
> /*
> @@ -1009,9 +1034,9 @@ out:
> */
> void __init efi_enter_virtual_mode(void)
> {
> - efi_status_t status;
> + int err, count = 0, pg_shift = 0;
> void *new_memmap = NULL;
> - int err, count = 0;
> +
Re: [PATCH 1/4] x86, ptdump: Add the functionality to dump an arbitrary pagetable
On 01/11/14 at 09:49pm, Borislav Petkov wrote:
> From: Borislav Petkov
>
> With reusing the ->trampoline_pgd page table for mapping EFI regions in
> order to use them after having switched to EFI virtual mode, it is very
> useful to be able to dump aforementioned page table in dmesg. This adds
> that functionality through the walk_pgd_level() interface which can be
> called from somewhere else.
>
> The original functionality of dumping to debugfs remains untouched.
>
> Cc: Arjan van de Ven
> Signed-off-by: Borislav Petkov
> ---
> arch/x86/include/asm/pgtable.h | 3 +-
> arch/x86/mm/dump_pagetables.c | 77
> --
> 2 files changed, 53 insertions(+), 27 deletions(-)
>
> diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
> index bbc8b12fa443..0001851fa785 100644
> --- a/arch/x86/include/asm/pgtable.h
> +++ b/arch/x86/include/asm/pgtable.h
> @@ -15,9 +15,10 @@
>: (prot))
>
> #ifndef __ASSEMBLY__
> -
> #include
>
> +void walk_pgd_level(struct seq_file *m, pgd_t *pgd);
> +
> /*
> * ZERO_PAGE is a global shared page that is always zero: used
> * for zero-mapped memory areas etc..
> diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
> index 0002a3a33081..f987ecff9226 100644
> --- a/arch/x86/mm/dump_pagetables.c
> +++ b/arch/x86/mm/dump_pagetables.c
> @@ -19,6 +19,8 @@
>
> #include
>
> +static bool dump_to_dmesg;
> +
> /*
> * The dumper groups pagetable entries of the same type into one, and for
> * that it needs to keep some state when walking, and flush this state
> @@ -88,6 +90,24 @@ static struct addr_marker address_markers[] = {
> #define PUD_LEVEL_MULT (PTRS_PER_PMD * PMD_LEVEL_MULT)
> #define PGD_LEVEL_MULT (PTRS_PER_PUD * PUD_LEVEL_MULT)
>
> +#define pt_dump_seq_printf(m, fmt, args...) \
> +({ \
> + if (dump_to_dmesg) \
> + printk(KERN_INFO fmt, ##args); \
pr_info? This is for debug purpose, maybe pr_debug is better?
Ditto to other printk callbacks.
> + else\
> + if (m) \
> + seq_printf(m, fmt, ##args); \
> +})
> +
> +#define pt_dump_cont_printf(m, fmt, args...) \
> +({ \
> + if (dump_to_dmesg) \
> + printk(KERN_CONT fmt, ##args); \
> + else\
> + if (m) \
> + seq_printf(m, fmt, ##args); \
> +})
> +
> /*
> * Print a readable form of a pgprot_t to the seq_file
> */
> @@ -99,47 +119,47 @@ static void printk_prot(struct seq_file *m, pgprot_t
> prot, int level)
>
> if (!pgprot_val(prot)) {
> /* Not present */
> - seq_printf(m, " ");
> + pt_dump_cont_printf(m, " ");
> } else {
> if (pr & _PAGE_USER)
> - seq_printf(m, "USR ");
> + pt_dump_cont_printf(m, "USR ");
> else
> - seq_printf(m, "");
> + pt_dump_cont_printf(m, "");
> if (pr & _PAGE_RW)
> - seq_printf(m, "RW ");
> + pt_dump_cont_printf(m, "RW ");
> else
> - seq_printf(m, "ro ");
> + pt_dump_cont_printf(m, "ro ");
> if (pr & _PAGE_PWT)
> - seq_printf(m, "PWT ");
> + pt_dump_cont_printf(m, "PWT ");
> else
> - seq_printf(m, "");
> + pt_dump_cont_printf(m, "");
> if (pr & _PAGE_PCD)
> - seq_printf(m, "PCD ");
> + pt_dump_cont_printf(m, "PCD ");
> else
> - seq_printf(m, "");
> + pt_dump_cont_printf(m, "");
>
> /* Bit 9 has a different meaning on level 3 vs 4 */
> if (level <= 3) {
> if (pr & _PAGE_PSE)
> - seq_printf(m, "PSE ");
> + pt_dump_cont_printf(m, "PSE ");
> else
> - seq_printf(m, "");
> + pt_dump_cont_printf(m, "");
> } else {
> if (pr & _PAGE_PAT)
> - seq_printf(m, "pat ");
> + pt_dump_cont_printf(m, "pat ");
> else
> - seq_printf(m, "");
> +
[PATCH] Driver/IFC: Move Freescale IFC driver to a common driver
Freescale IFC controller has been used for mpc8xxx. It will be used
for ARM-based SoC as well. This patch moves the driver to driver/misc
and fix the header file includes.
Signed-off-by: Prabhakar Kushwaha
---
arch/powerpc/sysdev/Makefile |1 -
drivers/misc/Makefile |1 +
{arch/powerpc/sysdev => drivers/misc}/fsl_ifc.c|2 +-
drivers/mtd/nand/fsl_ifc_nand.c|2 +-
.../include/asm => include/linux}/fsl_ifc.h|0
5 files changed, 3 insertions(+), 3 deletions(-)
rename {arch/powerpc/sysdev => drivers/misc}/fsl_ifc.c (99%)
rename {arch/powerpc/include/asm => include/linux}/fsl_ifc.h (100%)
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index f67ac90..afbcc37 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -21,7 +21,6 @@ obj-$(CONFIG_FSL_SOC) += fsl_soc.o fsl_mpic_err.o
obj-$(CONFIG_FSL_PCI) += fsl_pci.o $(fsl-msi-obj-y)
obj-$(CONFIG_FSL_PMC) += fsl_pmc.o
obj-$(CONFIG_FSL_LBC) += fsl_lbc.o
-obj-$(CONFIG_FSL_IFC) += fsl_ifc.o
obj-$(CONFIG_FSL_GTM) += fsl_gtm.o
obj-$(CONFIG_FSL_85XX_CACHE_SRAM) += fsl_85xx_l2ctlr.o
fsl_85xx_cache_sram.o
obj-$(CONFIG_SIMPLE_GPIO) += simple_gpio.o
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index f45473e..61c6271 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_BMP085_I2C) += bmp085-i2c.o
obj-$(CONFIG_BMP085_SPI) += bmp085-spi.o
obj-$(CONFIG_DUMMY_IRQ)+= dummy-irq.o
obj-$(CONFIG_ICS932S401) += ics932s401.o
+obj-$(CONFIG_FSL_IFC) += fsl_ifc.o
obj-$(CONFIG_LKDTM)+= lkdtm.o
obj-$(CONFIG_TIFM_CORE)+= tifm_core.o
obj-$(CONFIG_TIFM_7XX1)+= tifm_7xx1.o
diff --git a/arch/powerpc/sysdev/fsl_ifc.c b/drivers/misc/fsl_ifc.c
similarity index 99%
rename from arch/powerpc/sysdev/fsl_ifc.c
rename to drivers/misc/fsl_ifc.c
index d7fc722..d4ae878 100644
--- a/arch/powerpc/sysdev/fsl_ifc.c
+++ b/drivers/misc/fsl_ifc.c
@@ -30,8 +30,8 @@
#include
#include
#include
+#include
#include
-#include
struct fsl_ifc_ctrl *fsl_ifc_ctrl_dev;
EXPORT_SYMBOL(fsl_ifc_ctrl_dev);
diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
index 4335577..865b323 100644
--- a/drivers/mtd/nand/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/fsl_ifc_nand.c
@@ -30,7 +30,7 @@
#include
#include
#include
-#include
+#include
#define FSL_IFC_V1_1_0 0x0101
#define ERR_BYTE 0xFF /* Value returned for read
diff --git a/arch/powerpc/include/asm/fsl_ifc.h b/include/linux/fsl_ifc.h
similarity index 100%
rename from arch/powerpc/include/asm/fsl_ifc.h
rename to include/linux/fsl_ifc.h
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the clk tree with the arm-soc tree
Hi Mike,
Today's linux-next merge of the clk tree got a conflict in
drivers/clk/samsung/clk-exynos4.c between commit 86576fbe201b ("clk:
samsung: exynos4: Fix definition of div_mmc_pre4 divider") from the
arm-soc tree and commit 2d7382375054 ("clk: exynos4: replace clock ID
private enums with IDs from DT header") from the clk tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/clk/samsung/clk-exynos4.c
index 3852e44db0f8,2f7e440aebf8..
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@@ -498,64 -437,63 +437,64 @@@ static struct samsung_mux_clock exynos4
/* list of divider clocks supported in all exynos4 soc's */
static struct samsung_div_clock exynos4_div_clks[] __initdata = {
- DIV(none, "div_core", "mout_core", DIV_CPU0, 0, 3),
- DIV(none, "div_core2", "div_core", DIV_CPU0, 28, 3),
- DIV(none, "div_fimc0", "mout_fimc0", DIV_CAM, 0, 4),
- DIV(none, "div_fimc1", "mout_fimc1", DIV_CAM, 4, 4),
- DIV(none, "div_fimc2", "mout_fimc2", DIV_CAM, 8, 4),
- DIV(none, "div_fimc3", "mout_fimc3", DIV_CAM, 12, 4),
- DIV(none, "div_cam0", "mout_cam0", DIV_CAM, 16, 4),
- DIV(none, "div_cam1", "mout_cam1", DIV_CAM, 20, 4),
- DIV(none, "div_csis0", "mout_csis0", DIV_CAM, 24, 4),
- DIV(none, "div_csis1", "mout_csis1", DIV_CAM, 28, 4),
- DIV(sclk_mfc, "sclk_mfc", "mout_mfc", DIV_MFC, 0, 4),
- DIV_F(none, "div_g3d", "mout_g3d", DIV_G3D, 0, 4,
+ DIV(0, "div_core", "mout_core", DIV_CPU0, 0, 3),
+ DIV(0, "div_core2", "div_core", DIV_CPU0, 28, 3),
+ DIV(0, "div_fimc0", "mout_fimc0", DIV_CAM, 0, 4),
+ DIV(0, "div_fimc1", "mout_fimc1", DIV_CAM, 4, 4),
+ DIV(0, "div_fimc2", "mout_fimc2", DIV_CAM, 8, 4),
+ DIV(0, "div_fimc3", "mout_fimc3", DIV_CAM, 12, 4),
+ DIV(0, "div_cam0", "mout_cam0", DIV_CAM, 16, 4),
+ DIV(0, "div_cam1", "mout_cam1", DIV_CAM, 20, 4),
+ DIV(0, "div_csis0", "mout_csis0", DIV_CAM, 24, 4),
+ DIV(0, "div_csis1", "mout_csis1", DIV_CAM, 28, 4),
+ DIV(CLK_SCLK_MFC, "sclk_mfc", "mout_mfc", DIV_MFC, 0, 4),
+ DIV_F(0, "div_g3d", "mout_g3d", DIV_G3D, 0, 4,
CLK_SET_RATE_PARENT, 0),
- DIV(none, "div_fimd0", "mout_fimd0", DIV_LCD0, 0, 4),
- DIV(none, "div_mipi0", "mout_mipi0", DIV_LCD0, 16, 4),
- DIV(none, "div_audio0", "mout_audio0", DIV_MAUDIO, 0, 4),
- DIV(sclk_pcm0, "sclk_pcm0", "sclk_audio0", DIV_MAUDIO, 4, 8),
- DIV(none, "div_mmc0", "mout_mmc0", DIV_FSYS1, 0, 4),
- DIV(none, "div_mmc1", "mout_mmc1", DIV_FSYS1, 16, 4),
- DIV(none, "div_mmc2", "mout_mmc2", DIV_FSYS2, 0, 4),
- DIV(none, "div_mmc3", "mout_mmc3", DIV_FSYS2, 16, 4),
- DIV(sclk_pixel, "sclk_pixel", "sclk_vpll", DIV_TV, 0, 4),
- DIV(aclk100, "aclk100", "mout_aclk100", DIV_TOP, 4, 4),
- DIV(aclk160, "aclk160", "mout_aclk160", DIV_TOP, 8, 3),
- DIV(aclk133, "aclk133", "mout_aclk133", DIV_TOP, 12, 3),
- DIV(none, "div_onenand", "mout_onenand1", DIV_TOP, 16, 3),
- DIV(sclk_slimbus, "sclk_slimbus", "sclk_epll", DIV_PERIL3, 4, 4),
- DIV(sclk_pcm1, "sclk_pcm1", "sclk_audio1", DIV_PERIL4, 4, 8),
- DIV(sclk_pcm2, "sclk_pcm2", "sclk_audio2", DIV_PERIL4, 20, 8),
- DIV(sclk_i2s1, "sclk_i2s1", "sclk_audio1", DIV_PERIL5, 0, 6),
- DIV(sclk_i2s2, "sclk_i2s2", "sclk_audio2", DIV_PERIL5, 8, 6),
- DIV(none, "div_mmc4", "mout_mmc4", DIV_FSYS3, 0, 4),
- DIV_F(none, "div_mmc_pre4", "div_mmc4", DIV_FSYS3, 8, 8,
+ DIV(0, "div_fimd0", "mout_fimd0", DIV_LCD0, 0, 4),
+ DIV(0, "div_mipi0", "mout_mipi0", DIV_LCD0, 16, 4),
+ DIV(0, "div_audio0", "mout_audio0", DIV_MAUDIO, 0, 4),
+ DIV(CLK_SCLK_PCM0, "sclk_pcm0", "sclk_audio0", DIV_MAUDIO, 4, 8),
+ DIV(0, "div_mmc0", "mout_mmc0", DIV_FSYS1, 0, 4),
+ DIV(0, "div_mmc1", "mout_mmc1", DIV_FSYS1, 16, 4),
+ DIV(0, "div_mmc2", "mout_mmc2", DIV_FSYS2, 0, 4),
+ DIV(0, "div_mmc3", "mout_mmc3", DIV_FSYS2, 16, 4),
+ DIV(CLK_SCLK_PIXEL, "sclk_pixel", "sclk_vpll", DIV_TV, 0, 4),
+ DIV(CLK_ACLK100, "aclk100", "mout_aclk100", DIV_TOP, 4, 4),
+ DIV(CLK_ACLK160, "aclk160", "mout_aclk160", DIV_TOP, 8, 3),
+ DIV(CLK_ACLK133, "aclk133", "mout_aclk133", DIV_TOP, 12, 3),
+ DIV(0, "div_onenand", "mout_onenand1", DIV_TOP, 16, 3),
+ DIV(CLK_SCLK_SLIMBUS, "sclk_slimbus", "sclk_epll", DIV_PERIL3, 4, 4),
+ DIV(CLK_SCLK_PCM1, "sclk_pcm1", "sclk_audio1", DIV_PERIL4, 4, 8),
+ DIV(CLK_SCLK_PCM2, "sclk_pcm2", "sclk_audio2", DIV_PERIL4, 20, 8),
+ DIV(CLK_SCLK_I2S1, "sclk_i2s1", "sclk_audio1", DIV_PERIL5, 0, 6),
+ DIV(CLK_SCLK_I2S2, "sclk_i2s2", "sclk_audio2", DIV_PERIL5, 8, 6),
+ DIV(0, "div_mmc4", "mout_mmc4", DIV_FSYS3, 0, 4),
- DIV(0, "div_mmc_pre4", "div_mmc4", DIV_FSYS3, 8, 8),
++
linux-next: manual merge of the clk tree with the v4l-dvb tree
Hi Mike,
Today's linux-next merge of the clk tree got a conflict in MAINTAINERS
between commit 7d459937dc09 ("[media] Add driver for Samsung S5K5BAF
camera sensor") from the v4l-dvb tree and commit 310e39c9b320
("MAINTAINERS: Add entry for Samsung SoC clock drivers") from the clk
tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc MAINTAINERS
index 0188725a5658,273311e10b5b..
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@@ -7460,13 -7334,12 +7468,19 @@@ L: linux-me...@vger.kernel.or
S:Supported
F:drivers/media/i2c/s5c73m3/*
+SAMSUNG S5K5BAF CAMERA DRIVER
+M:Kyungmin Park
+M:Andrzej Hajda
+L:linux-me...@vger.kernel.org
+S:Supported
+F:drivers/media/i2c/s5k5baf.c
+
+ SAMSUNG SOC CLOCK DRIVERS
+ M:Tomasz Figa
+ S:Supported
+ L:linux-samsung-...@vger.kernel.org (moderated for non-subscribers)
+ F:drivers/clk/samsung/
+
SERIAL DRIVERS
M:Greg Kroah-Hartman
L:linux-ser...@vger.kernel.org
pgpFsbEM4EyDa.pgp
Description: PGP signature
Re: [PATCH v4 2/2] cpufreq: imx6q-cpufreq driver depends on SOC_IMX6Q/SOC_IMX6SL
That's ok. On Sun, Jan 12, 2014 at 7:26 PM, Shawn Guo wrote: > On Thu, Jan 09, 2014 at 06:39:52PM -0800, John Tobias wrote: >> The ARCH_HAS_CPUFREQ, HAVE_IMX_ANATOP and PM_OPP are moved up to ARCH_MCX. >> The driver should show if the SOC_IMX6Q and/or SOC_IMX6SL is/are selected. >> >> Signed-off-by: John Tobias >> --- >> drivers/cpufreq/Kconfig.arm | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm >> index 3ba5dcc..230c663 100644 >> --- a/drivers/cpufreq/Kconfig.arm >> +++ b/drivers/cpufreq/Kconfig.arm >> @@ -80,7 +80,7 @@ config ARM_HIGHBANK_CPUFREQ >> >> config ARM_IMX6Q_CPUFREQ >> tristate "Freescale i.MX6 cpufreq support" >> - depends on ARCH_MXC >> + depends on SOC_IMX6Q || SOC_IMX6SL > > No. We do not want to touch this line where there is another IMX6xx can > reuse the driver. Depending on ARCH_MXC is good enough, since we > already have the symbol prompt and help text to tell the targets that > the driver supports. > > Shawn > >> depends on REGULATOR_ANATOP >> help >> This adds cpufreq driver support for Freescale i.MX6 series SoCs. >> -- >> 1.8.3.2 >> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] ARM: imx: add select on ARCH_MXC for cpufreq support
I tested leaving the HAVE_IMX_ANATOP under SOC_IMX6Q and SOC_IMX6SL. The iMX6Q cpufreq driver won't show up in menu config / gconfig and that's the reason why I added it. Regards, john On Sun, Jan 12, 2014 at 7:20 PM, Shawn Guo wrote: > On Thu, Jan 09, 2014 at 06:39:51PM -0800, John Tobias wrote: >> Moved ARCH_HAS_CPUFREQ, HAVE_IMX_ANATOP and PM_OPP on ARCH_MXC so that >> the user can enable the cpufreq support for iMX6Q and/or iMX6SL. > > All I was asking is to move the following: > > select ARCH_HAS_CPUFREQ > select ARCH_HAS_OPP > select PM_OPP if PM > > So leave HAVE_IMX_ANATOP out there, and only move the above ones please. > > Shawn > >> >> Signed-off-by: John Tobias >> --- >> arch/arm/mach-imx/Kconfig | 13 ++--- >> 1 file changed, 6 insertions(+), 7 deletions(-) >> >> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig >> index 7a6e6f7..d6aa34d 100644 >> --- a/arch/arm/mach-imx/Kconfig >> +++ b/arch/arm/mach-imx/Kconfig >> @@ -1,5 +1,6 @@ >> config ARCH_MXC >> bool "Freescale i.MX family" if ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 >> + select ARCH_HAS_CPUFREQ >> select ARCH_REQUIRE_GPIOLIB >> select ARM_CPU_SUSPEND if PM >> select ARM_PATCH_PHYS_VIRT >> @@ -9,8 +10,10 @@ config ARCH_MXC >> select GENERIC_ALLOCATOR >> select GENERIC_CLOCKEVENTS >> select GENERIC_IRQ_CHIP >> + select HAVE_IMX_ANATOP if SOC_IMX6Q || SOC_IMX6SL >> select MIGHT_HAVE_CACHE_L2X0 if ARCH_MULTI_V6_V7 >> select MULTI_IRQ_HANDLER >> + select PM_OPP if PM >> select SOC_BUS >> select SPARSE_IRQ >> select USE_OF >> @@ -779,16 +782,14 @@ config SOC_IMX53 >> >> config SOC_IMX6Q >> bool "i.MX6 Quad/DualLite support" >> - select ARCH_HAS_CPUFREQ >> - select ARCH_HAS_OPP >> + select ARCH_HAS_OPP >> select ARM_ERRATA_754322 >> select ARM_ERRATA_764369 if SMP >> select ARM_ERRATA_775420 >> select ARM_GIC >> select CPU_V7 >> select HAVE_ARM_SCU if SMP >> - select HAVE_ARM_TWD if SMP >> - select HAVE_IMX_ANATOP >> + select HAVE_ARM_TWD if SMP >> select HAVE_IMX_GPC >> select HAVE_IMX_MMDC >> select HAVE_IMX_SRC >> @@ -800,8 +801,7 @@ config SOC_IMX6Q >> select PINCTRL_IMX6Q >> select PL310_ERRATA_588369 if CACHE_PL310 >> select PL310_ERRATA_727915 if CACHE_PL310 >> - select PL310_ERRATA_769419 if CACHE_PL310 >> - select PM_OPP if PM >> + select PL310_ERRATA_769419 if CACHE_PL310 >> >> help >> This enables support for Freescale i.MX6 Quad processor. >> @@ -812,7 +812,6 @@ config SOC_IMX6SL >> select ARM_ERRATA_775420 >> select ARM_GIC >> select CPU_V7 >> - select HAVE_IMX_ANATOP >> select HAVE_IMX_GPC >> select HAVE_IMX_MMDC >> select HAVE_IMX_SRC >> -- >> 1.8.3.2 >> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH mmotm/next] cgroup: remove stray references to css_id
Trivial: remove the few stray references to css_id, which itself
was removed in v3.13's 2ff2a7d03bbe "cgroup: kill css_id".
Signed-off-by: Hugh Dickins
---
But I don't know your plans with respect to the XXX in
kernel/cgroup.c, so perhaps you'd prefer to amend this.
drivers/md/bcache/request.c |1 -
include/linux/cgroup.h |3 ---
mm/page_cgroup.c|2 +-
3 files changed, 1 insertion(+), 5 deletions(-)
--- mmotm/drivers/md/bcache/request.c 2014-01-10 18:24:58.212448858 -0800
+++ linux/drivers/md/bcache/request.c 2014-01-12 20:00:07.641685957 -0800
@@ -163,7 +163,6 @@ static struct cgroup_subsys_state *bcach
static void bcachecg_destroy(struct cgroup *cgroup)
{
struct bch_cgroup *cg = cgroup_to_bcache(cgroup);
- free_css_id(_subsys, >css);
kfree(cg);
}
--- mmotm/include/linux/cgroup.h2014-01-10 18:25:01.820448944 -0800
+++ linux/include/linux/cgroup.h2014-01-12 20:00:07.645685957 -0800
@@ -29,7 +29,6 @@ struct cgroupfs_root;
struct cgroup_subsys;
struct inode;
struct cgroup;
-struct css_id;
extern int cgroup_init_early(void);
extern int cgroup_init(void);
@@ -79,8 +78,6 @@ struct cgroup_subsys_state {
struct cgroup_subsys_state *parent;
unsigned long flags;
- /* ID for this css, if possible */
- struct css_id __rcu *id;
/* percpu_ref killing and RCU release */
struct rcu_head rcu_head;
--- mmotm/mm/page_cgroup.c 2014-01-10 18:25:02.256448954 -0800
+++ linux/mm/page_cgroup.c 2014-01-12 20:00:07.645685957 -0800
@@ -452,7 +452,7 @@ unsigned short swap_cgroup_record(swp_en
* lookup_swap_cgroup_id - lookup mem_cgroup id tied to swap entry
* @ent: swap entry to be looked up.
*
- * Returns CSS ID of mem_cgroup at success. 0 at failure. (0 is invalid ID)
+ * Returns ID of mem_cgroup at success. 0 at failure. (0 is invalid ID)
*/
unsigned short lookup_swap_cgroup_id(swp_entry_t ent)
{
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mtd: nand: assign mtd->name in find_full_id_nand
> -Original Message-
> From: Brian Norris [mailto:computersforpe...@gmail.com]
> Sent: Sunday, January 12, 2014 4:10 AM
> To: Huang Shijie; Caizhiyong
> Cc: linux-...@lists.infradead.org; Wanglin (Albert); David Woodhouse;
> linux-kernel@vger.kernel.org; Artem Bityutskiy
> Subject: Re: [PATCH] mtd: nand: assign mtd->name in find_full_id_nand
>
> Hi,
>
> On Thu, Dec 26, 2013 at 10:19:39AM +0800, Huang Shijie wrote:
> > On Thu, Dec 26, 2013 at 01:51:58AM +, Caizhiyong wrote:
> > > From: Cai Zhiyong
> > > Date: Wed, 25 Dec 2013 21:19:21 +0800
> > > Subject: [PATCH] mtd: nand: assign mtd->name in find_full_id_nand
> > >
> > > This patch assigned the type->name to mtd->name when mtd->name is
> > > NULL in function "find_full_id_nand".
> > > mtd->name is NULL may cause some problem.
> > >
> > > Signed-off-by: Cai Zhiyong
> > Acked-by: Huang Shijie
>
> Thanks, the patch looks good. Pushed to l2-mtd.git.
>
> Wouldn't this trigger an exception when reading
> /sys/class/mtd/mtdX/name? If so, should this be marked for stable?
View the source code, if mtd->name is NULL, cat "/sys/class/mtd/mtdX/name" will
get string "(null)".
static ssize_t mtd_name_show(struct device *dev, struct device_attribute *attr,
char *buf)
{
struct mtd_info *mtd = dev_get_drvdata(dev);
return snprintf(buf, PAGE_SIZE, "%s\n", mtd->name);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the workqueues tree with Linus' tree
Hi Tejun,
Today's linux-next merge of the workqueues tree got a conflict in
kernel/workqueue.c between commit 12997d1a999c ("Revert "workqueue: allow
work_on_cpu() to be called recursively"") from Linus' tree and commit
440a11360326 ("workqueue: Calling destroy_work_on_stack() to pair with
INIT_WORK_ONSTACK()") from the workqueues tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc kernel/workqueue.c
index b010eac595d2,fdeec6e9d025..
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@@ -4827,7 -4833,15 +4828,8 @@@ long work_on_cpu(int cpu, long (*fn)(vo
INIT_WORK_ONSTACK(, work_for_cpu_fn);
schedule_work_on(cpu, );
-
- /*
- * The work item is on-stack and can't lead to deadlock through
- * flushing. Use __flush_work() to avoid spurious lockdep warnings
- * when work_on_cpu()s are nested.
- */
- __flush_work();
-
+ flush_work();
+ destroy_work_on_stack();
return wfc.ret;
}
EXPORT_SYMBOL_GPL(work_on_cpu);
pgpEDtEwLpegT.pgp
Description: PGP signature
[PATCH] of: Fix __of_device_is_available check
>From IEEE 1275, there defined a standard 'status' property indicating the operational status of one device. The 'status' property has four possible values: 'okay/ok', 'disabled', 'fail' and 'fail-xxx'. If it is absent, that means the status of the device is unknown or okay. The __of_device_is_available checks the state of the 'status' property of a device. If the property is absent or set to 'okay/ok', it returns 1. Otherwise it returns 0. While in __of_device_is_available: > status = of_get_property(device, "status", ); > if (status == NULL) > return 1; The status value returned from 'of_get_property()' will be NULL in two cases: Firstly: the 'device' value (device node) is NULL. Secondly: the 'status' property is actaully not exist. If the device node is NULL, the __of_device_is_available will return true, that will mean the absent state of the 'status' property. So this add the device node check before checking the 'status' property's state, and if the device node is not exist, 0 will be returned. Signed-off-by: Xiubo Li --- drivers/of/base.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/of/base.c b/drivers/of/base.c index f807d0e..ba195fb 100644 --- a/drivers/of/base.c +++ b/drivers/of/base.c @@ -415,6 +415,9 @@ static int __of_device_is_available(const struct device_node *device) const char *status; int statlen; + if (!device) + return 0; + status = __of_get_property(device, "status", ); if (status == NULL) return 1; -- 1.8.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/
next bio iters break discard?
When I try to exercise heavy swapping with discard on mmotm 2014-01-09, I soon hit a NULL pointer dereference in __blk_recalc_rq_segments(): __blk_recalc_rq_segments blk_recount_segments ll_back_merge_fn bio_attempt_back_merge blk_queue_bio generic_make_request submit_bio blkdev_issue_discard swap_do_scheduled_discard scan_swap_map_try_ssd_cluster scan_swap_map get_swap_page add_to_swap shrink_page_list etc. etc. The crash is on the NULL struct page pointer in page_to_pfn(bv.bv_page) on line 35 of block/blk-merge.c. The code around there is not very different from 3.13-rc8 (which doesn't crash), and I didn't notice REQ_DISCARD or bio_has_data() checks removed. I think it worked before because the old bio_for_each_segment() iterator was a straightforward "i < bio->bi_vcnt" loop which would do nothing when bi_vcnt is 0; but the new iterators are relying (perhaps) on bio->bi_iter.bi_size which is non-0 despite no data? I expect it would crash in the same way on other recent nexts and mmotms, I've not tried. Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/swap: fix race on swap_info reuse between swapoff and swapon
On Mon, Jan 13, 2014 at 11:27 AM, Andrew Morton wrote: > On Mon, 13 Jan 2014 11:08:58 +0800 Weijie Yang > wrote: > >> >> --- a/mm/swapfile.c >> >> +++ b/mm/swapfile.c >> >> @@ -1922,7 +1922,6 @@ SYSCALL_DEFINE1(swapoff, const char __user *, >> >> specialfile) >> >> p->swap_map = NULL; >> >> cluster_info = p->cluster_info; >> >> p->cluster_info = NULL; >> >> - p->flags = 0; >> >> frontswap_map = frontswap_map_get(p); >> >> spin_unlock(>lock); >> >> spin_unlock(_lock); >> >> @@ -1948,6 +1947,16 @@ SYSCALL_DEFINE1(swapoff, const char __user *, >> >> specialfile) >> >> mutex_unlock(>i_mutex); >> >> } >> >> filp_close(swap_file, NULL); >> >> + >> >> + /* >> >> + * clear SWP_USED flag after all resources freed >> >> + * so that swapon can reuse this swap_info in alloc_swap_info() >> >> safely >> >> + * it is ok to not hold p->lock after we cleared its SWP_WRITEOK >> >> + */ >> >> + spin_lock(_lock); >> >> + p->flags = 0; >> >> + spin_unlock(_lock); >> >> + >> >> err = 0; >> >> atomic_inc(_poll_event); >> >> wake_up_interruptible(_poll_wait); >> > >> > I didn't look too closely, but this patch might also address the race >> > which Krzysztof addressed with >> > http://ozlabs.org/~akpm/mmots/broken-out/swap-fix-setting-page_size-blocksize-during-swapoff-swapon-race.patch. >> > Can we please check that out? >> > >> > I do prefer fixing all these swapon-vs-swapoff races with some large, >> > simple, wide-scope exclusion scheme. Perhaps SWP_USED is that scheme. >> > >> > An alternative would be to add another mutex and just make sys_swapon() >> > and sys_swapoff() 100% exclusive. But that is plastering yet another >> > lock over this mess to hide the horrors which lurk within :( >> > >> >> Hi, Andrew. Thanks for your suggestion. >> >> I checked Krzysztof's patch, it use the global swapon_mutex to protect >> race condition among >> swapon, swapoff and swap_start(). It is a kind of correct method, but >> a heavy method. > > But do you agree that your > http://ozlabs.org/~akpm/mmots/broken-out/mm-swap-fix-race-on-swap_info-reuse-between-swapoff-and-swapon.patch > makes Krzysztof's > http://ozlabs.org/~akpm/mmots/broken-out/swap-fix-setting-page_size-blocksize-during-swapoff-swapon-race.patch > obsolete? Yes, I agree. > I've been sitting on Krzysztof's > swap-fix-setting-page_size-blocksize-during-swapoff-swapon-race.patch > for several months - Hugh had issues with it so I put it on hold and > nothing further happened. > >> I will try to resend a patchset to make lock usage in swapfile.c clear >> and fine grit > > OK, thanks. In the meanwhile I'm planning on dropping Krzysztof's > patch and merging your patch into 3.14-rc1, which is why I'd like > confirmation that your patch addresses the issues which Krzysztof > identified? > I think so, Krzysztof and I both try to fix the same issue(reuse swap_info while its previous resources are not cleared completely). The different is Krzysztof's patch uses a global swapon_mutex and its commit log only focuses on set_blocksize(), while my patch try to maintain the fine grit lock usage. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v8 4/4] qrwlock: Use smp_store_release() in write_unlock()
On Mon, Jan 13, 2014 at 10:47:36AM +0800, Daniel J Blueman wrote: > On Thursday, 9 January 2014 01:10:03 UTC+8, Waiman Long wrote: > > This patch modifies the queue_write_unlock() function to use the > > new smp_store_release() function in another pending patch. It also > > removes the temporary implementation of smp_load_acquire() and > > smp_store_release() function in qrwlock.c. > > > > This patch should only be merged if PeterZ's linux-arch patch patch > > was merged. > > > > Signed-off-by: Waiman Long > > Reviewed-by: Paul E. McKenney > > --- > > include/asm-generic/qrwlock.h |4 +--- > > kernel/locking/qrwlock.c | 34 -- > > 2 files changed, 1 insertions(+), 37 deletions(-) > > > > diff --git a/include/asm-generic/qrwlock.h > b/include/asm-generic/qrwlock.h > > index 2b9a7b4..4d4bd04 100644 > > --- a/include/asm-generic/qrwlock.h > > +++ b/include/asm-generic/qrwlock.h > > @@ -179,9 +179,7 @@ static inline void queue_write_unlock(struct > qrwlock *lock) > > /* > > * Make sure that none of the critical section will be leaked out. > > */ > > - smp_mb__before_clear_bit(); > > - ACCESS_ONCE(lock->cnts.writer) = 0; > > - smp_mb__after_clear_bit(); > > + smp_store_release(>cnts.writer, 0) > > This will fail compilation, so probably needs further testing with > Peter's load_acquire/store_release barrier patches. Peter's patch just hit -tip, so this should be esay to do. In Waiman's defense, he does call attention to this in the commit log. 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: linux-next: manual merge of the tip tree with the xtensa tree
Hi Stephen,
Thanks for the fix! I actually just got an updated set for most of the
patches currently in the for_next tree for xtensa and might have to do a
rebase to integrate them better. I'll include your fix when I come
across the issue.
Thanks again,
-Chris
On 1/12/14 7:26 PM, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the tip tree got a conflict in
arch/xtensa/include/asm/barrier.h between commit dbacef090841 ("xtensa:
add SMP support") from the xtensa tree and commit 93ea02bb8435 ("arch:
Clean up asm/barrier.h implementations using asm-generic/barrier.h") from
the tip tree.
I fixed it up (I am pretty sure - see below) and can carry the fix as
necessary (no action is required).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/9] re-shrink 'struct page' when SLUB is on.
On Mon, 2014-01-13 at 10:44 +0900, Joonsoo Kim wrote: > On Sat, Jan 11, 2014 at 06:55:39PM -0600, Christoph Lameter wrote: > > On Sat, 11 Jan 2014, Pekka Enberg wrote: > > > > > On Sat, Jan 11, 2014 at 1:42 AM, Dave Hansen wrote: > > > > On 01/10/2014 03:39 PM, Andrew Morton wrote: > > > >>> I tested 4 cases, all of these on the "cache-cold kfree()" case. The > > > >>> first 3 are with vanilla upstream kernel source. The 4th is patched > > > >>> with my new slub code (all single-threaded): > > > >>> > > > >>> http://www.sr71.net/~dave/intel/slub/slub-perf-20140109.png > > > >> > > > >> So we're converging on the most complex option. argh. > > > > > > > > Yeah, looks that way. > > > > > > Seems like a reasonable compromise between memory usage and allocation > > > speed. > > > > > > Christoph? > > > > Fundamentally I think this is good. I need to look at the details but I am > > only going to be able to do that next week when I am back in the office. > > Hello, > > I have another guess about the performance result although I didn't look at > these patches in detail. I guess that performance win of 64-byte sturct on > small allocations can be caused by low latency when accessing slub's metadata, > that is, struct page. > > Following is pages per slab via '/proc/slabinfo'. > > sizepages per slab > ... > 256 1 > 512 1 > 10242 > 20484 > 40968 > 81928 > > We only touch one struct page on small allocation. > In 64-byte case, we always use one cacheline for touching struct page, since > it is aligned to cacheline size. However, in 56-byte case, we possibly use > two cachelines because struct page isn't aligned to cacheline size. > > This aspect can change on large allocation cases. For example, consider > 4096-byte allocation case. In 64-byte case, it always touches 8 cachelines > for metadata, however, in 56-byte case, it touches 7 or 8 cachelines since > 8 struct page occupies 8 * 56 bytes memory, that is, 7 cacheline size. > > This guess may be wrong, so if you think it wrong, please ignore it. :) > > And I have another opinion on this patchset. Diminishing struct page size > will affect other usecases beside the slub. As we know, Dave found this > by doing sequential 'dd'. I think that it may be the best case for 56-byte > case. > If we randomly touch the struct page, this un-alignment can cause regression > since touching the struct page will cause two cachline misses. So, I think > that it is better to get more benchmark results to this patchset for > convincing > ourselves. If possible, how about asking Fengguang to run whole set of > his benchmarks before going forward? Cc'ing him. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the tip tree with the pm tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in
drivers/acpi/apei/einj.c between commit 8b48463f8942 ("ACPI: Clean up
inclusions of ACPI header files") from the pm tree and commit
d3ab3edc029b ("ACPI, APEI: Cleanup alignment-aware accesses") from the
tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/acpi/apei/einj.c
index ca0c6d7ec0d4,7dcc8a824aae..
--- a/drivers/acpi/apei/einj.c
+++ b/drivers/acpi/apei/einj.c
@@@ -33,6 -33,8 +33,7 @@@
#include
#include
#include
-#include
+ #include
#include "apei-internal.h"
pgpKNEr9RZMYF.pgp
Description: PGP signature
linux-next: manual merge of the tip tree with the xtensa tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in
arch/xtensa/include/asm/barrier.h between commit dbacef090841 ("xtensa:
add SMP support") from the xtensa tree and commit 93ea02bb8435 ("arch:
Clean up asm/barrier.h implementations using asm-generic/barrier.h") from
the tip tree.
I fixed it up (I am pretty sure - see below) and can carry the fix as
necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/xtensa/include/asm/barrier.h
index 8e5e5c980a7a,e1ee6b51dfc5..
--- a/arch/xtensa/include/asm/barrier.h
+++ b/arch/xtensa/include/asm/barrier.h
@@@ -16,16 -13,10 +13,6 @@@
#define rmb() barrier()
#define wmb() mb()
--#ifdef CONFIG_SMP
- #define smp_mb() mb()
- #define smp_rmb() rmb()
- #define smp_wmb() wmb()
- #else
- #define smp_mb() barrier()
- #define smp_rmb() barrier()
- #define smp_wmb() barrier()
-#error smp_* not defined
--#endif
--
- #define set_mb(var, value)do { var = value; mb(); } while (0)
+ #include
#endif /* _XTENSA_SYSTEM_H */
pgp9IapbFB0Rf.pgp
Description: PGP signature
linux-next: manual merge of the tip tree with the xtensa tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in
arch/xtensa/include/asm/barrier.h between commit dbacef090841 ("xtensa:
add SMP support") from the xtensa tree and commit 93ea02bb8435 ("arch:
Clean up asm/barrier.h implementations using asm-generic/barrier.h") from
the tip tree.
I fixed it up (I am pretty sure - see below) and can carry the fix as
necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/xtensa/include/asm/barrier.h
index 8e5e5c980a7a,e1ee6b51dfc5..
--- a/arch/xtensa/include/asm/barrier.h
+++ b/arch/xtensa/include/asm/barrier.h
@@@ -16,16 -13,10 +13,6 @@@
#define rmb() barrier()
#define wmb() mb()
--#ifdef CONFIG_SMP
- #define smp_mb() mb()
- #define smp_rmb() rmb()
- #define smp_wmb() wmb()
- #else
- #define smp_mb() barrier()
- #define smp_rmb() barrier()
- #define smp_wmb() barrier()
-#error smp_* not defined
--#endif
--
- #define set_mb(var, value)do { var = value; mb(); } while (0)
+ #include
#endif /* _XTENSA_SYSTEM_H */
pgpbwZ2lSUIvt.pgp
Description: PGP signature
Re: [PATCH] mm/swap: fix race on swap_info reuse between swapoff and swapon
On Mon, 13 Jan 2014 11:08:58 +0800 Weijie Yang wrote: > >> --- a/mm/swapfile.c > >> +++ b/mm/swapfile.c > >> @@ -1922,7 +1922,6 @@ SYSCALL_DEFINE1(swapoff, const char __user *, > >> specialfile) > >> p->swap_map = NULL; > >> cluster_info = p->cluster_info; > >> p->cluster_info = NULL; > >> - p->flags = 0; > >> frontswap_map = frontswap_map_get(p); > >> spin_unlock(>lock); > >> spin_unlock(_lock); > >> @@ -1948,6 +1947,16 @@ SYSCALL_DEFINE1(swapoff, const char __user *, > >> specialfile) > >> mutex_unlock(>i_mutex); > >> } > >> filp_close(swap_file, NULL); > >> + > >> + /* > >> + * clear SWP_USED flag after all resources freed > >> + * so that swapon can reuse this swap_info in alloc_swap_info() safely > >> + * it is ok to not hold p->lock after we cleared its SWP_WRITEOK > >> + */ > >> + spin_lock(_lock); > >> + p->flags = 0; > >> + spin_unlock(_lock); > >> + > >> err = 0; > >> atomic_inc(_poll_event); > >> wake_up_interruptible(_poll_wait); > > > > I didn't look too closely, but this patch might also address the race > > which Krzysztof addressed with > > http://ozlabs.org/~akpm/mmots/broken-out/swap-fix-setting-page_size-blocksize-during-swapoff-swapon-race.patch. > > Can we please check that out? > > > > I do prefer fixing all these swapon-vs-swapoff races with some large, > > simple, wide-scope exclusion scheme. Perhaps SWP_USED is that scheme. > > > > An alternative would be to add another mutex and just make sys_swapon() > > and sys_swapoff() 100% exclusive. But that is plastering yet another > > lock over this mess to hide the horrors which lurk within :( > > > > Hi, Andrew. Thanks for your suggestion. > > I checked Krzysztof's patch, it use the global swapon_mutex to protect > race condition among > swapon, swapoff and swap_start(). It is a kind of correct method, but > a heavy method. But do you agree that your http://ozlabs.org/~akpm/mmots/broken-out/mm-swap-fix-race-on-swap_info-reuse-between-swapoff-and-swapon.patch makes Krzysztof's http://ozlabs.org/~akpm/mmots/broken-out/swap-fix-setting-page_size-blocksize-during-swapoff-swapon-race.patch obsolete? I've been sitting on Krzysztof's swap-fix-setting-page_size-blocksize-during-swapoff-swapon-race.patch for several months - Hugh had issues with it so I put it on hold and nothing further happened. > I will try to resend a patchset to make lock usage in swapfile.c clear > and fine grit OK, thanks. In the meanwhile I'm planning on dropping Krzysztof's patch and merging your patch into 3.14-rc1, which is why I'd like confirmation that your patch addresses the issues which Krzysztof identified? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v8 4/4] qrwlock: Use smp_store_release() in write_unlock()
On Thursday, 9 January 2014 01:10:03 UTC+8, Waiman Long wrote: > This patch modifies the queue_write_unlock() function to use the > new smp_store_release() function in another pending patch. It also > removes the temporary implementation of smp_load_acquire() and > smp_store_release() function in qrwlock.c. > > This patch should only be merged if PeterZ's linux-arch patch patch > was merged. > > Signed-off-by: Waiman Long > Reviewed-by: Paul E. McKenney > --- > include/asm-generic/qrwlock.h |4 +--- > kernel/locking/qrwlock.c | 34 -- > 2 files changed, 1 insertions(+), 37 deletions(-) > > diff --git a/include/asm-generic/qrwlock.h b/include/asm-generic/qrwlock.h > index 2b9a7b4..4d4bd04 100644 > --- a/include/asm-generic/qrwlock.h > +++ b/include/asm-generic/qrwlock.h > @@ -179,9 +179,7 @@ static inline void queue_write_unlock(struct qrwlock *lock) >/* > * Make sure that none of the critical section will be leaked out. > */ > - smp_mb__before_clear_bit(); > - ACCESS_ONCE(lock->cnts.writer) = 0; > - smp_mb__after_clear_bit(); > + smp_store_release(>cnts.writer, 0) This will fail compilation, so probably needs further testing with Peter's load_acquire/store_release barrier patches. 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 v4 2/2] cpufreq: imx6q-cpufreq driver depends on SOC_IMX6Q/SOC_IMX6SL
On Thu, Jan 09, 2014 at 06:39:52PM -0800, John Tobias wrote: > The ARCH_HAS_CPUFREQ, HAVE_IMX_ANATOP and PM_OPP are moved up to ARCH_MCX. > The driver should show if the SOC_IMX6Q and/or SOC_IMX6SL is/are selected. > > Signed-off-by: John Tobias > --- > drivers/cpufreq/Kconfig.arm | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm > index 3ba5dcc..230c663 100644 > --- a/drivers/cpufreq/Kconfig.arm > +++ b/drivers/cpufreq/Kconfig.arm > @@ -80,7 +80,7 @@ config ARM_HIGHBANK_CPUFREQ > > config ARM_IMX6Q_CPUFREQ > tristate "Freescale i.MX6 cpufreq support" > - depends on ARCH_MXC > + depends on SOC_IMX6Q || SOC_IMX6SL No. We do not want to touch this line where there is another IMX6xx can reuse the driver. Depending on ARCH_MXC is good enough, since we already have the symbol prompt and help text to tell the targets that the driver supports. Shawn > depends on REGULATOR_ANATOP > help > This adds cpufreq driver support for Freescale i.MX6 series SoCs. > -- > 1.8.3.2 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] x86, mpx: hook #BR exception handler to allocate bound tables
On 01/12/2014 05:20 PM, Borislav Petkov wrote:
On Sun, Jan 12, 2014 at 05:20:00PM +0800, Qiaowei Ren wrote:
+static bool allocate_bt(unsigned long bd_entry)
+{
+ unsigned long bt_size = 1UL << (MPX_L2_BITS+MPX_L2_SHIFT);
+ unsigned long bt_addr, old_val;
+
+ bt_addr = sys_mmap_pgoff(0, bt_size, PROT_READ | PROT_WRITE,
+ MAP_ANONYMOUS | MAP_PRIVATE | MAP_POPULATE, -1, 0);
Are we sure about this? We can do a possible memory allocation in
mmap_region() in this exception handler context. And yes, we do a
conditional_sti(), which makes it all the more susceptible.
Have you run this with lockdep enabled?
Yes, I run this with lockdep enabled.
Thanks,
Qiaowei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the tip tree with the net-next tree
Hi all,
On Mon, 13 Jan 2014 14:18:24 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the tip tree got conflicts in
> arch/arc/include/asm/Kbuild, arch/cris/include/asm/Kbuild,
> arch/hexagon/include/asm/Kbuild, arch/microblaze/include/asm/Kbuild,
> arch/parisc/include/asm/Kbuild and arch/score/include/asm/Kbuild between
> commit e3fec2f74f7f ("lib: Add missing arch generic-y entries for
> asm-generic/hash.h") from the net-next tree and commit 93ea02bb8435
> ("arch: Clean up asm/barrier.h implementations using
> asm-generic/barrier.h") from the tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>
> BTW: thanks for not keeping the Kbuild files sorted :-(
I missed arch/mn10300/include/asm/Kbuild the first time round.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/mn10300/include/asm/Kbuild
index bc42f14c9c2e,367ef399ddf7..
--- a/arch/mn10300/include/asm/Kbuild
+++ b/arch/mn10300/include/asm/Kbuild
@@@ -1,6 -1,6 +1,7 @@@
++generic-y += barrier.h
generic-y += clkdev.h
generic-y += exec.h
++generic-y += hash.h
generic-y += trace_clock.h
generic-y += preempt.h
- generic-y += hash.h
-generic-y += barrier.h
pgphVTkMMq45W.pgp
Description: PGP signature
Re: [PATCH v4 1/2] ARM: imx: add select on ARCH_MXC for cpufreq support
On Thu, Jan 09, 2014 at 06:39:51PM -0800, John Tobias wrote: > Moved ARCH_HAS_CPUFREQ, HAVE_IMX_ANATOP and PM_OPP on ARCH_MXC so that > the user can enable the cpufreq support for iMX6Q and/or iMX6SL. All I was asking is to move the following: select ARCH_HAS_CPUFREQ select ARCH_HAS_OPP select PM_OPP if PM So leave HAVE_IMX_ANATOP out there, and only move the above ones please. Shawn > > Signed-off-by: John Tobias > --- > arch/arm/mach-imx/Kconfig | 13 ++--- > 1 file changed, 6 insertions(+), 7 deletions(-) > > diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig > index 7a6e6f7..d6aa34d 100644 > --- a/arch/arm/mach-imx/Kconfig > +++ b/arch/arm/mach-imx/Kconfig > @@ -1,5 +1,6 @@ > config ARCH_MXC > bool "Freescale i.MX family" if ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 > + select ARCH_HAS_CPUFREQ > select ARCH_REQUIRE_GPIOLIB > select ARM_CPU_SUSPEND if PM > select ARM_PATCH_PHYS_VIRT > @@ -9,8 +10,10 @@ config ARCH_MXC > select GENERIC_ALLOCATOR > select GENERIC_CLOCKEVENTS > select GENERIC_IRQ_CHIP > + select HAVE_IMX_ANATOP if SOC_IMX6Q || SOC_IMX6SL > select MIGHT_HAVE_CACHE_L2X0 if ARCH_MULTI_V6_V7 > select MULTI_IRQ_HANDLER > + select PM_OPP if PM > select SOC_BUS > select SPARSE_IRQ > select USE_OF > @@ -779,16 +782,14 @@ config SOC_IMX53 > > config SOC_IMX6Q > bool "i.MX6 Quad/DualLite support" > - select ARCH_HAS_CPUFREQ > - select ARCH_HAS_OPP > + select ARCH_HAS_OPP > select ARM_ERRATA_754322 > select ARM_ERRATA_764369 if SMP > select ARM_ERRATA_775420 > select ARM_GIC > select CPU_V7 > select HAVE_ARM_SCU if SMP > - select HAVE_ARM_TWD if SMP > - select HAVE_IMX_ANATOP > + select HAVE_ARM_TWD if SMP > select HAVE_IMX_GPC > select HAVE_IMX_MMDC > select HAVE_IMX_SRC > @@ -800,8 +801,7 @@ config SOC_IMX6Q > select PINCTRL_IMX6Q > select PL310_ERRATA_588369 if CACHE_PL310 > select PL310_ERRATA_727915 if CACHE_PL310 > - select PL310_ERRATA_769419 if CACHE_PL310 > - select PM_OPP if PM > + select PL310_ERRATA_769419 if CACHE_PL310 > > help > This enables support for Freescale i.MX6 Quad processor. > @@ -812,7 +812,6 @@ config SOC_IMX6SL > select ARM_ERRATA_775420 > select ARM_GIC > select CPU_V7 > - select HAVE_IMX_ANATOP > select HAVE_IMX_GPC > select HAVE_IMX_MMDC > select HAVE_IMX_SRC > -- > 1.8.3.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/
linux-next: manual merge of the tip tree with the net-next tree
Hi all,
Today's linux-next merge of the tip tree got conflicts in
arch/arc/include/asm/Kbuild, arch/cris/include/asm/Kbuild,
arch/hexagon/include/asm/Kbuild, arch/microblaze/include/asm/Kbuild,
arch/parisc/include/asm/Kbuild and arch/score/include/asm/Kbuild between
commit e3fec2f74f7f ("lib: Add missing arch generic-y entries for
asm-generic/hash.h") from the net-next tree and commit 93ea02bb8435
("arch: Clean up asm/barrier.h implementations using
asm-generic/barrier.h") from the tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
BTW: thanks for not keeping the Kbuild files sorted :-(
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arc/include/asm/Kbuild
index 93e6ca919620,e07c786011af..
--- a/arch/arc/include/asm/Kbuild
+++ b/arch/arc/include/asm/Kbuild
@@@ -1,4 -1,4 +1,5 @@@
generic-y += auxvec.h
++generic-y += barrier.h
generic-y += bugs.h
generic-y += bitsperlong.h
generic-y += clkdev.h
@@@ -11,6 -11,6 +12,7 @@@ generic-y += fcntl.
generic-y += fb.h
generic-y += ftrace.h
generic-y += hardirq.h
++generic-y += hash.h
generic-y += hw_irq.h
generic-y += ioctl.h
generic-y += ioctls.h
@@@ -47,4 -47,4 +49,3 @@@ generic-y += user.
generic-y += vga.h
generic-y += xor.h
generic-y += preempt.h
- generic-y += hash.h
-generic-y += barrier.h
diff --cc arch/cris/include/asm/Kbuild
index c5963b3e4624,35ec2e5ca832..
--- a/arch/cris/include/asm/Kbuild
+++ b/arch/cris/include/asm/Kbuild
@@@ -3,8 -3,8 +3,10 @@@ header-y += arch-v10
header-y += arch-v32/
++generic-y += barrier.h
generic-y += clkdev.h
generic-y += exec.h
++generic-y += hash.h
generic-y += kvm_para.h
generic-y += linkage.h
generic-y += module.h
@@@ -12,4 -12,4 +14,3 @@@ generic-y += trace_clock.
generic-y += vga.h
generic-y += xor.h
generic-y += preempt.h
- generic-y += hash.h
-generic-y += barrier.h
diff --cc arch/hexagon/include/asm/Kbuild
index 469d223950ff,a614ec9747a6..
--- a/arch/hexagon/include/asm/Kbuild
+++ b/arch/hexagon/include/asm/Kbuild
@@@ -2,6 -2,6 +2,7 @@@
header-y += ucontext.h
generic-y += auxvec.h
++generic-y += barrier.h
generic-y += bug.h
generic-y += bugs.h
generic-y += clkdev.h
@@@ -15,6 -15,6 +16,7 @@@ generic-y += fb.
generic-y += fcntl.h
generic-y += ftrace.h
generic-y += hardirq.h
++generic-y += hash.h
generic-y += hw_irq.h
generic-y += ioctl.h
generic-y += ioctls.h
@@@ -54,4 -54,4 +56,3 @@@ generic-y += ucontext.
generic-y += unaligned.h
generic-y += xor.h
generic-y += preempt.h
- generic-y += hash.h
-generic-y += barrier.h
diff --cc arch/microblaze/include/asm/Kbuild
index 43eec338ff50,f77fb6630b11..
--- a/arch/microblaze/include/asm/Kbuild
+++ b/arch/microblaze/include/asm/Kbuild
@@@ -1,7 -1,7 +1,8 @@@
++generic-y += barrier.h
generic-y += clkdev.h
generic-y += exec.h
++generic-y += hash.h
generic-y += trace_clock.h
generic-y += syscalls.h
generic-y += preempt.h
- generic-y += hash.h
-generic-y += barrier.h
diff --cc arch/parisc/include/asm/Kbuild
index 75edd5fcc6ff,8df06d0074f4..
--- a/arch/parisc/include/asm/Kbuild
+++ b/arch/parisc/include/asm/Kbuild
@@@ -1,8 -1,8 +1,9 @@@
++generic-y += barrier.h
generic-y += word-at-a-time.h auxvec.h user.h cputime.h emergency-restart.h \
segment.h topology.h vga.h device.h percpu.h hw_irq.h mutex.h \
div64.h irq_regs.h kdebug.h kvm_para.h local64.h local.h param.h \
poll.h xor.h clkdev.h exec.h
++generic-y += hash.h
generic-y += trace_clock.h
generic-y += preempt.h
- generic-y += hash.h
-generic-y += barrier.h
diff --cc arch/score/include/asm/Kbuild
index 099e7ba40599,ee2993b6e5d1..
--- a/arch/score/include/asm/Kbuild
+++ b/arch/score/include/asm/Kbuild
@@@ -1,9 -1,8 +1,9 @@@
header-y +=
++generic-y += barrier.h
generic-y += clkdev.h
++generic-y += hash.h
generic-y += trace_clock.h
generic-y += xor.h
generic-y += preempt.h
- generic-y += hash.h
-
-generic-y += barrier.h
pgpKKkLTUJdJO.pgp
Description: PGP signature
Re: [PATCH 5/5] x86, mpx: extend siginfo structure to include bound violation information
On 01/13/2014 01:03 AM, Borislav Petkov wrote: On Sun, Jan 12, 2014 at 08:49:21AM -0800, H. Peter Anvin wrote: I saw a previous version of the code that did that, and it really didn't work out well -- it ended up being more complex and slower. I suspected as much. But, we still probably should use the generic struct insn, insn_field, etc and act on them in mpx.c instead of defining our own mpx_insn, mpx_insn_field, X86_MODRM_MOD, etc in the header which are more or less copied from insn.h, right? I tried to use generic structure and macro, but many members of generic struct insn are not used for MPX, and except this I have to add one member into this structure. So I define mpx specific struct insn. And so I guess only struct insn_field and several macros like X86_XXX may use generic version. Anyway, I will try to use their generic version in next version for this patchset. Thanks, Qiaowei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mm/swap: fix race on swap_info reuse between swapoff and swapon
On Sat, Jan 11, 2014 at 9:11 AM, Andrew Morton wrote: > On Thu, 09 Jan 2014 13:39:55 +0800 Weijie Yang > wrote: > >> swapoff clear swap_info's SWP_USED flag prematurely and free its resources >> after that. A concurrent swapon will reuse this swap_info while its previous >> resources are not cleared completely. >> >> These late freed resources are: >> - p->percpu_cluster >> - swap_cgroup_ctrl[type] >> - block_device setting >> - inode->i_flags &= ~S_SWAPFILE >> >> This patch clear SWP_USED flag after all its resources freed, so that swapon >> can reuse this swap_info by alloc_swap_info() safely. >> >> ... >> >> --- a/mm/swapfile.c >> +++ b/mm/swapfile.c >> @@ -1922,7 +1922,6 @@ SYSCALL_DEFINE1(swapoff, const char __user *, >> specialfile) >> p->swap_map = NULL; >> cluster_info = p->cluster_info; >> p->cluster_info = NULL; >> - p->flags = 0; >> frontswap_map = frontswap_map_get(p); >> spin_unlock(>lock); >> spin_unlock(_lock); >> @@ -1948,6 +1947,16 @@ SYSCALL_DEFINE1(swapoff, const char __user *, >> specialfile) >> mutex_unlock(>i_mutex); >> } >> filp_close(swap_file, NULL); >> + >> + /* >> + * clear SWP_USED flag after all resources freed >> + * so that swapon can reuse this swap_info in alloc_swap_info() safely >> + * it is ok to not hold p->lock after we cleared its SWP_WRITEOK >> + */ >> + spin_lock(_lock); >> + p->flags = 0; >> + spin_unlock(_lock); >> + >> err = 0; >> atomic_inc(_poll_event); >> wake_up_interruptible(_poll_wait); > > I didn't look too closely, but this patch might also address the race > which Krzysztof addressed with > http://ozlabs.org/~akpm/mmots/broken-out/swap-fix-setting-page_size-blocksize-during-swapoff-swapon-race.patch. > Can we please check that out? > > I do prefer fixing all these swapon-vs-swapoff races with some large, > simple, wide-scope exclusion scheme. Perhaps SWP_USED is that scheme. > > An alternative would be to add another mutex and just make sys_swapon() > and sys_swapoff() 100% exclusive. But that is plastering yet another > lock over this mess to hide the horrors which lurk within :( > Hi, Andrew. Thanks for your suggestion. I checked Krzysztof's patch, it use the global swapon_mutex to protect race condition among swapon, swapoff and swap_start(). It is a kind of correct method, but a heavy method. I will try to resend a patchset to make lock usage in swapfile.c clear and fine grit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 7/9] mm: thrash detection-based file cache sizing
On Fri, Jan 10, 2014 at 01:10:41PM -0500, Johannes Weiner wrote:
> The VM maintains cached filesystem pages on two types of lists. One
> list holds the pages recently faulted into the cache, the other list
> holds pages that have been referenced repeatedly on that first list.
> The idea is to prefer reclaiming young pages over those that have
> shown to benefit from caching in the past. We call the recently used
> list "inactive list" and the frequently used list "active list".
>
> Currently, the VM aims for a 1:1 ratio between the lists, which is the
> "perfect" trade-off between the ability to *protect* frequently used
> pages and the ability to *detect* frequently used pages. This means
> that working set changes bigger than half of cache memory go
> undetected and thrash indefinitely, whereas working sets bigger than
> half of cache memory are unprotected against used-once streams that
> don't even need caching.
>
> Historically, every reclaim scan of the inactive list also took a
> smaller number of pages from the tail of the active list and moved
> them to the head of the inactive list. This model gave established
> working sets more gracetime in the face of temporary use-once streams,
> but ultimately was not significantly better than a FIFO policy and
> still thrashed cache based on eviction speed, rather than actual
> demand for cache.
>
> This patch solves one half of the problem by decoupling the ability to
> detect working set changes from the inactive list size. By
> maintaining a history of recently evicted file pages it can detect
> frequently used pages with an arbitrarily small inactive list size,
> and subsequently apply pressure on the active list based on actual
> demand for cache, not just overall eviction speed.
>
> Every zone maintains a counter that tracks inactive list aging speed.
> When a page is evicted, a snapshot of this counter is stored in the
> now-empty page cache radix tree slot. On refault, the minimum access
> distance of the page can be assessed, to evaluate whether the page
> should be part of the active list or not.
>
> This fixes the VM's blindness towards working set changes in excess of
> the inactive list. And it's the foundation to further improve the
> protection ability and reduce the minimum inactive list size of 50%.
>
> Signed-off-by: Johannes Weiner
Reviewed-by: Minchan Kim
Really nice description and code to understand.
I believe we should really merge/maintain such advanced algorithm,
which will end up putting more advanced concept easily.
Johannes, thanks for the your effort!
> ---
> include/linux/mmzone.h | 5 +
> include/linux/swap.h | 5 +
> mm/Makefile| 2 +-
> mm/filemap.c | 61
> mm/swap.c | 2 +
> mm/vmscan.c| 24 -
> mm/vmstat.c| 2 +
> mm/workingset.c| 253
> +
> 8 files changed, 331 insertions(+), 23 deletions(-)
> create mode 100644 mm/workingset.c
>
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index bd791e452ad7..118ba9f51e86 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -142,6 +142,8 @@ enum zone_stat_item {
> NUMA_LOCAL, /* allocation from local node */
> NUMA_OTHER, /* allocation from other node */
> #endif
> + WORKINGSET_REFAULT,
> + WORKINGSET_ACTIVATE,
> NR_ANON_TRANSPARENT_HUGEPAGES,
> NR_FREE_CMA_PAGES,
> NR_VM_ZONE_STAT_ITEMS };
> @@ -392,6 +394,9 @@ struct zone {
> spinlock_t lru_lock;
> struct lruvec lruvec;
>
> + /* Evictions & activations on the inactive file list */
> + atomic_long_t inactive_age;
> +
> unsigned long pages_scanned; /* since last reclaim */
> unsigned long flags; /* zone flags, see below */
>
> diff --git a/include/linux/swap.h b/include/linux/swap.h
> index 46ba0c6c219f..b83cf61403ed 100644
> --- a/include/linux/swap.h
> +++ b/include/linux/swap.h
> @@ -260,6 +260,11 @@ struct swap_list_t {
> int next; /* swapfile to be used next */
> };
>
> +/* linux/mm/workingset.c */
> +void *workingset_eviction(struct address_space *mapping, struct page *page);
> +bool workingset_refault(void *shadow);
> +void workingset_activation(struct page *page);
> +
> /* linux/mm/page_alloc.c */
> extern unsigned long totalram_pages;
> extern unsigned long totalreserve_pages;
> diff --git a/mm/Makefile b/mm/Makefile
> index 305d10acd081..b30aeb86abd6 100644
> --- a/mm/Makefile
> +++ b/mm/Makefile
> @@ -17,7 +17,7 @@ obj-y := filemap.o mempool.o
> oom_kill.o fadvise.o \
> util.o mmzone.o vmstat.o backing-dev.o \
> mm_init.o mmu_context.o percpu.o slab_common.o \
> compaction.o balloon_compaction.o \
> -interval_tree.o
Re: [patch 6/9] mm + fs: store shadow entries in page cache
On Fri, Jan 10, 2014 at 01:10:40PM -0500, Johannes Weiner wrote: > Reclaim will be leaving shadow entries in the page cache radix tree > upon evicting the real page. As those pages are found from the LRU, > an iput() can lead to the inode being freed concurrently. At this > point, reclaim must no longer install shadow pages because the inode > freeing code needs to ensure the page tree is really empty. > > Add an address_space flag, AS_EXITING, that the inode freeing code > sets under the tree lock before doing the final truncate. Reclaim > will check for this flag before installing shadow pages. > > Signed-off-by: Johannes Weiner Reviewed only vm part, NOT fs part. Reviewed-by: Minchan Kim > --- > Documentation/filesystems/porting | 6 +-- > drivers/staging/lustre/lustre/llite/llite_lib.c | 2 +- > fs/9p/vfs_inode.c | 2 +- > fs/affs/inode.c | 2 +- > fs/afs/inode.c | 2 +- > fs/bfs/inode.c | 2 +- > fs/block_dev.c | 4 +- > fs/btrfs/inode.c| 2 +- > fs/cifs/cifsfs.c| 2 +- > fs/coda/inode.c | 2 +- > fs/ecryptfs/super.c | 2 +- > fs/exofs/inode.c| 2 +- > fs/ext2/inode.c | 2 +- > fs/ext3/inode.c | 2 +- > fs/ext4/inode.c | 4 +- > fs/f2fs/inode.c | 2 +- > fs/fat/inode.c | 2 +- > fs/freevxfs/vxfs_inode.c| 2 +- > fs/fuse/inode.c | 2 +- > fs/gfs2/super.c | 2 +- > fs/hfs/inode.c | 2 +- > fs/hfsplus/super.c | 2 +- > fs/hostfs/hostfs_kern.c | 2 +- > fs/hpfs/inode.c | 2 +- > fs/inode.c | 4 +- > fs/jffs2/fs.c | 2 +- > fs/jfs/inode.c | 4 +- > fs/logfs/readwrite.c| 2 +- > fs/minix/inode.c| 2 +- > fs/ncpfs/inode.c| 2 +- > fs/nfs/inode.c | 2 +- > fs/nfs/nfs4super.c | 2 +- > fs/nilfs2/inode.c | 6 +-- > fs/ntfs/inode.c | 2 +- > fs/ocfs2/inode.c| 4 +- > fs/omfs/inode.c | 2 +- > fs/proc/inode.c | 2 +- > fs/reiserfs/inode.c | 2 +- > fs/sysfs/inode.c| 2 +- > fs/sysv/inode.c | 2 +- > fs/ubifs/super.c| 2 +- > fs/udf/inode.c | 4 +- > fs/ufs/inode.c | 2 +- > fs/xfs/xfs_super.c | 2 +- > include/linux/fs.h | 1 + > include/linux/mm.h | 1 + > include/linux/pagemap.h | 13 +- > mm/filemap.c| 33 --- > mm/truncate.c | 54 > +++-- > mm/vmscan.c | 2 +- > 50 files changed, 147 insertions(+), 65 deletions(-) > > diff --git a/Documentation/filesystems/porting > b/Documentation/filesystems/porting > index f0890581f7f6..fc0de703066b 100644 > --- a/Documentation/filesystems/porting > +++ b/Documentation/filesystems/porting > @@ -295,9 +295,9 @@ in the beginning of ->setattr unconditionally. > ->clear_inode() and ->delete_inode() are gone; ->evict_inode() should > be used instead. It gets called whenever the inode is evicted, whether it > has > remaining links or not. Caller does *not* evict the pagecache or > inode-associated > -metadata buffers; getting rid of those is responsibility of method, as it had > -been for ->delete_inode(). Caller makes sure async writeback cannot be > running > -for the inode while (or after) ->evict_inode() is called. > +metadata buffers; the method has to use truncate_inode_pages_final() to get > rid > +of those. Caller makes sure async writeback cannot be running for the inode > while > +(or after) ->evict_inode() is called. > > ->drop_inode() returns int now; it's called on final iput() with > inode->i_lock held and it returns true if filesystems wants the inode to be > diff --git a/drivers/staging/lustre/lustre/llite/llite_lib.c >
linux-next: manual merge of the mmc tree with Linus' tree
Hi Chris,
Today's linux-next merge of the mmc tree got a conflict in MAINTAINERS
between commit c2fd4e380322 ("MAINTAINERS: set up proper record for
Xilinx Zynq") from Linus' tree and commit 45f210424b4b ("mmc: arasan: Add
driver for Arasan SDHCI") from the mmc tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc MAINTAINERS
index 64b39e610589,518bf717b02b..
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@@ -1387,9 -1371,7 +1387,10 @@@ T: git git://git.xilinx.com/linux-xlnx.
S:Supported
F:arch/arm/mach-zynq/
F:drivers/cpuidle/cpuidle-zynq.c
+N:zynq
+N:xilinx
+F:drivers/clocksource/cadence_ttc_timer.c
+ F:drivers/mmc/host/sdhci-of-arasan.c
ARM SMMU DRIVER
M:Will Deacon
pgpGV3SFjFD3E.pgp
Description: PGP signature
RE: [alsa-devel] [PATCH] ASoC: simple-card: fix one bug to writing to the platform data
Hi Jean-Francois, > > If the original cinfo is not used anymore, the use of its structure to > handle the card information is not a good idea: > > - almost all cinfo information are in the struct snd_soc_card, > > - this cinfo structure cannot be extended to handle many DAI links, > > - it contains simple-card information which are of no use for the > platform caller. > > So, I'd rather have seen: > > - the removal of 'snd_link' and 'snd_card' from the platform interface > (struct asoc_simple_card_info), > > - the definition of a local struct simple_card_data containing the > struct snd_soc_card and a pointer to an array of fmt/sysclk values > (one per DAI link). > I have sent one patch to fix some of these and mainly fixed the bug from Mark's comments in another early email. Thanks, -- Best Regards, Xiubo
Re: [patch 5/9] mm + fs: prepare for non-page entries in page cache radix trees
On Fri, Jan 10, 2014 at 01:10:39PM -0500, Johannes Weiner wrote:
> shmem mappings already contain exceptional entries where swap slot
> information is remembered.
>
> To be able to store eviction information for regular page cache,
> prepare every site dealing with the radix trees directly to handle
> entries other than pages.
>
> The common lookup functions will filter out non-page entries and
> return NULL for page cache holes, just as before. But provide a raw
> version of the API which returns non-page entries as well, and switch
> shmem over to use it.
>
> Signed-off-by: Johannes Weiner
Reviewed-by: Minchan Kim
Below are just nitpicks.
> ---
> fs/btrfs/compression.c | 2 +-
> include/linux/mm.h | 8 ++
> include/linux/pagemap.h | 15 ++--
> include/linux/pagevec.h | 3 +
> include/linux/shmem_fs.h | 1 +
> mm/filemap.c | 196
> +--
> mm/mincore.c | 20 +++--
> mm/readahead.c | 2 +-
> mm/shmem.c | 97 +--
> mm/swap.c| 47
> mm/truncate.c| 73 ++
> 11 files changed, 336 insertions(+), 128 deletions(-)
>
> diff --git a/fs/btrfs/compression.c b/fs/btrfs/compression.c
> index 6aad98cb343f..c88316587900 100644
> --- a/fs/btrfs/compression.c
> +++ b/fs/btrfs/compression.c
> @@ -474,7 +474,7 @@ static noinline int add_ra_bio_pages(struct inode *inode,
> rcu_read_lock();
> page = radix_tree_lookup(>page_tree, pg_index);
> rcu_read_unlock();
> - if (page) {
> + if (page && !radix_tree_exceptional_entry(page)) {
> misses++;
> if (misses > 4)
> break;
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 8b6e55ee8855..c09ef3ae55bc 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -906,6 +906,14 @@ extern void show_free_areas(unsigned int flags);
> extern bool skip_free_areas_node(unsigned int flags, int nid);
>
> int shmem_zero_setup(struct vm_area_struct *);
> +#ifdef CONFIG_SHMEM
> +bool shmem_mapping(struct address_space *mapping);
> +#else
> +static inline bool shmem_mapping(struct address_space *mapping)
> +{
> + return false;
> +}
> +#endif
>
> extern int can_do_mlock(void);
> extern int user_shm_lock(size_t, struct user_struct *);
> diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
> index c73130c607c4..b6854b7c58cb 100644
> --- a/include/linux/pagemap.h
> +++ b/include/linux/pagemap.h
> @@ -248,12 +248,15 @@ pgoff_t page_cache_next_hole(struct address_space
> *mapping,
> pgoff_t page_cache_prev_hole(struct address_space *mapping,
>pgoff_t index, unsigned long max_scan);
>
> -extern struct page * find_get_page(struct address_space *mapping,
> - pgoff_t index);
> -extern struct page * find_lock_page(struct address_space *mapping,
> - pgoff_t index);
> -extern struct page * find_or_create_page(struct address_space *mapping,
> - pgoff_t index, gfp_t gfp_mask);
> +struct page *__find_get_page(struct address_space *mapping, pgoff_t offset);
> +struct page *find_get_page(struct address_space *mapping, pgoff_t offset);
> +struct page *__find_lock_page(struct address_space *mapping, pgoff_t offset);
> +struct page *find_lock_page(struct address_space *mapping, pgoff_t offset);
> +struct page *find_or_create_page(struct address_space *mapping, pgoff_t
> index,
> + gfp_t gfp_mask);
> +unsigned __find_get_pages(struct address_space *mapping, pgoff_t start,
> + unsigned int nr_pages, struct page **pages,
> + pgoff_t *indices);
> unsigned find_get_pages(struct address_space *mapping, pgoff_t start,
> unsigned int nr_pages, struct page **pages);
> unsigned find_get_pages_contig(struct address_space *mapping, pgoff_t start,
> diff --git a/include/linux/pagevec.h b/include/linux/pagevec.h
> index e4dbfab37729..3c6b8b1e945b 100644
> --- a/include/linux/pagevec.h
> +++ b/include/linux/pagevec.h
> @@ -22,6 +22,9 @@ struct pagevec {
>
> void __pagevec_release(struct pagevec *pvec);
> void __pagevec_lru_add(struct pagevec *pvec);
> +unsigned __pagevec_lookup(struct pagevec *pvec, struct address_space
> *mapping,
> + pgoff_t start, unsigned nr_pages, pgoff_t *indices);
> +void pagevec_remove_exceptionals(struct pagevec *pvec);
> unsigned pagevec_lookup(struct pagevec *pvec, struct address_space *mapping,
> pgoff_t start, unsigned nr_pages);
> unsigned pagevec_lookup_tag(struct pagevec *pvec,
> diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h
> index 30aa0dc60d75..deb49609cd36 100644
> --- a/include/linux/shmem_fs.h
> +++ b/include/linux/shmem_fs.h
> @@ -49,6 +49,7 @@
Re: [PATCH 0/7] improve robustness on handling migratetype
On Fri, Jan 10, 2014 at 09:48:34AM +, Mel Gorman wrote: > On Fri, Jan 10, 2014 at 05:48:55PM +0900, Joonsoo Kim wrote: > > On Thu, Jan 09, 2014 at 09:27:20AM +, Mel Gorman wrote: > > > On Thu, Jan 09, 2014 at 04:04:40PM +0900, Joonsoo Kim wrote: > > > > Hello, > > > > > > > > I found some weaknesses on handling migratetype during code review and > > > > testing CMA. > > > > > > > > First, we don't have any synchronization method on get/set pageblock > > > > migratetype. When we change migratetype, we hold the zone lock. So > > > > writer-writer race doesn't exist. But while someone changes migratetype, > > > > others can get migratetype. This may introduce totally unintended value > > > > as migratetype. Although I haven't heard of any problem report about > > > > that, it is better to protect properly. > > > > > > > > > > This is deliberate. The migratetypes for the majority of users are > > > advisory > > > and aimed for fragmentation avoidance. It was important that the cost of > > > that be kept as low as possible and the general case is that migration > > > types > > > change very rarely. In many cases, the zone lock is held. In other cases, > > > such as splitting free pages, the cost is simply not justified. > > > > > > I doubt there is any amount of data you could add in support that would > > > justify hammering the free fast paths (which call get_pageblock_type). > > > > Hello, Mel. > > > > There is a possibility that we can get unintended value such as 6 as > > migratetype > > if reader-writer (get/set pageblock_migratetype) race happends. It can be > > possible, because we read the value without any synchronization method. And > > this migratetype, 6, has no place in buddy freelist, so array index overrun > > can > > be possible and the system can break, although I haven't heard that it > > occurs. > > > > I think that my solution is too expensive. However, I think that we need > > solution. aren't we? Do you have any better idea? > > > > It's not something I have ever heard or seen of occurring but > if you've identified that it's a real possibility then split > get_pageblock_migratetype into locked and unlocked versions. Ensure > that calls to set_pageblock_migratetype is always under zone->lock and > get_pageblock_migratetype is also under zone->lock which both should be > true in the majority of cases. Use the unlocked version otherwise but > instead of synchronoing, check if it's returning >= MIGRATE_TYPES and > return MIGRATE_MOVABLE in the unlikely event of a race. This will avoid > harming the fast paths for the majority of users and limit the damage if > a MIGRATE_CMA region is accidentally treated as MIGRATe_MOVABLE Okay. I will re-investigate it and if I have indentified that it's a real possiblity, I will re-make this patch according to your advice. Thanks for comment! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/9] re-shrink 'struct page' when SLUB is on.
On Sat, Jan 11, 2014 at 06:55:39PM -0600, Christoph Lameter wrote: > On Sat, 11 Jan 2014, Pekka Enberg wrote: > > > On Sat, Jan 11, 2014 at 1:42 AM, Dave Hansen wrote: > > > On 01/10/2014 03:39 PM, Andrew Morton wrote: > > >>> I tested 4 cases, all of these on the "cache-cold kfree()" case. The > > >>> first 3 are with vanilla upstream kernel source. The 4th is patched > > >>> with my new slub code (all single-threaded): > > >>> > > >>> http://www.sr71.net/~dave/intel/slub/slub-perf-20140109.png > > >> > > >> So we're converging on the most complex option. argh. > > > > > > Yeah, looks that way. > > > > Seems like a reasonable compromise between memory usage and allocation > > speed. > > > > Christoph? > > Fundamentally I think this is good. I need to look at the details but I am > only going to be able to do that next week when I am back in the office. Hello, I have another guess about the performance result although I didn't look at these patches in detail. I guess that performance win of 64-byte sturct on small allocations can be caused by low latency when accessing slub's metadata, that is, struct page. Following is pages per slab via '/proc/slabinfo'. sizepages per slab ... 256 1 512 1 10242 20484 40968 81928 We only touch one struct page on small allocation. In 64-byte case, we always use one cacheline for touching struct page, since it is aligned to cacheline size. However, in 56-byte case, we possibly use two cachelines because struct page isn't aligned to cacheline size. This aspect can change on large allocation cases. For example, consider 4096-byte allocation case. In 64-byte case, it always touches 8 cachelines for metadata, however, in 56-byte case, it touches 7 or 8 cachelines since 8 struct page occupies 8 * 56 bytes memory, that is, 7 cacheline size. This guess may be wrong, so if you think it wrong, please ignore it. :) And I have another opinion on this patchset. Diminishing struct page size will affect other usecases beside the slub. As we know, Dave found this by doing sequential 'dd'. I think that it may be the best case for 56-byte case. If we randomly touch the struct page, this un-alignment can cause regression since touching the struct page will cause two cachline misses. So, I think that it is better to get more benchmark results to this patchset for convincing ourselves. If possible, how about asking Fengguang to run whole set of his benchmarks before going forward? Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the sound-asoc tree with the slave-dma tree
Hi all,
Today's linux-next merge of the sound-asoc tree got a conflict in
sound/soc/fsl/fsl_ssi.c between commit 0da9e55e71bc ("ASoC: fsl_ssi: Add
dual fifo mode support") from the slave-dma tree and commit 2b56b5f02029
("ASoC: fsl_ssi: Set default slot number for common cases") from the
sound-asoc tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc sound/soc/fsl/fsl_ssi.c
index 2101fc5c5739,7864ec5cf5f9..
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@@ -140,8 -162,9 +162,10 @@@ struct fsl_ssi_private
bool ssi_on_imx;
bool imx_ac97;
bool use_dma;
+ bool use_dual_fifo;
bool baudclk_locked;
+ bool irq_stats;
+ bool offline_config;
u8 i2s_mode;
spinlock_t baudclk_lock;
struct clk *baudclk;
@@@ -421,12 -711,17 +712,23 @@@ static int fsl_ssi_setup(struct fsl_ssi
if (ssi_private->imx_ac97)
fsl_ssi_setup_ac97(ssi_private);
+ if (ssi_private->use_dual_fifo) {
+ write_ssi_mask(>srcr, 0, CCSR_SSI_SRCR_RFEN1);
+ write_ssi_mask(>stcr, 0, CCSR_SSI_STCR_TFEN1);
+ write_ssi_mask(>scr, 0, CCSR_SSI_SCR_TCH_EN);
+ }
+
+ /*
+* Set a default slot number so that there is no need for those common
+* cases like I2S mode to call the extra set_tdm_slot() any more.
+*/
+ if (!ssi_private->imx_ac97) {
+ write_ssi_mask(>stccr, CCSR_SSI_SxCCR_DC_MASK,
+ CCSR_SSI_SxCCR_DC(2));
+ write_ssi_mask(>srccr, CCSR_SSI_SxCCR_DC_MASK,
+ CCSR_SSI_SxCCR_DC(2));
+ }
+
return 0;
}
@@@ -1170,8 -1343,35 +1359,35 @@@ static int fsl_ssi_probe(struct platfor
ssi_private->baudclk_locked = false;
spin_lock_init(_private->baudclk_lock);
- if (of_device_is_compatible(pdev->dev.of_node, "fsl,imx21-ssi")) {
+ /*
+* imx51 and later SoCs have a slightly different IP that allows the
+* SSI configuration while the SSI unit is running.
+*
+* More important, it is necessary on those SoCs to configure the
+* sperate TX/RX DMA bits just before starting the stream
+* (fsl_ssi_trigger). The SDMA unit has to be configured before fsl_ssi
+* sends any DMA requests to the SDMA unit, otherwise it is not defined
+* how the SDMA unit handles the DMA request.
+*
+* SDMA units are present on devices starting at imx35 but the imx35
+* reference manual states that the DMA bits should not be changed
+* while the SSI unit is running (SSIEN). So we support the necessary
+* online configuration of fsl-ssi starting at imx51.
+*/
+ switch (hw_type) {
+ case FSL_SSI_MCP8610:
+ case FSL_SSI_MX21:
+ case FSL_SSI_MX35:
+ ssi_private->offline_config = true;
+ break;
+ case FSL_SSI_MX51:
+ ssi_private->offline_config = false;
+ break;
+ }
+
+ if (hw_type == FSL_SSI_MX21 || hw_type == FSL_SSI_MX51 ||
+ hw_type == FSL_SSI_MX35) {
- u32 dma_events[2];
+ u32 dma_events[2], dmas[4];
ssi_private->ssi_on_imx = true;
ssi_private->clk = devm_clk_get(>dev, NULL);
@@@ -1234,16 -1435,13 +1451,22 @@@
dma_events[0], shared ? IMX_DMATYPE_SSI_SP :
IMX_DMATYPE_SSI);
imx_pcm_dma_params_init_data(_private->filter_data_rx,
dma_events[1], shared ? IMX_DMATYPE_SSI_SP :
IMX_DMATYPE_SSI);
+ if (!of_property_read_u32_array(pdev->dev.of_node, "dmas",
dmas, 4)
+ && dmas[2] == IMX_DMATYPE_SSI_DUAL) {
+ ssi_private->use_dual_fifo = true;
+ /* When using dual fifo mode, we need to keep watermark
+ * as even numbers due to dma script limitation.
+ */
+ ssi_private->dma_params_tx.maxburst &= ~0x1;
+ ssi_private->dma_params_rx.maxburst &= ~0x1;
+ }
- } else if (ssi_private->use_dma) {
+ }
+
+ /*
+* Enable interrupts only for MCP8610 and MX51. The other MXs have
+* different writeable interrupt status registers.
+*/
+ if (ssi_private->use_dma) {
/* The 'name' should not have any slashes in it. */
ret = devm_request_irq(>dev, ssi_private->irq,
fsl_ssi_isr, 0, ssi_private->name,
pgpamUu9eaMi5.pgp
Description: PGP signature
Re: [PATCH v5] video: add OpenCores VGA/LCD framebuffer driver
On Saturday, January 11, 2014 5:13 AM, Stefan Kristiansson wrote:
>
> This adds support for the VGA/LCD core available from OpenCores:
> http://opencores.org/project,vga_lcd
>
> The driver have been tested together with both OpenRISC and
> ARM (socfpga) processors.
>
> Signed-off-by: Stefan Kristiansson
> ---
> Changes in v2:
> - Add Microblaze as an example user and fix a typo in Xilinx Zynq
>
> Changes in v3:
> - Use devm_kzalloc instead of kzalloc
> - Remove superflous MODULE #ifdef
>
> Changes in v4:
> - Remove 'default n' in Kconfig
> - Simplify ioremap/request_mem_region by using devm_ioremap_resource
> - Remove release_mem_region
>
> Changes in v5:
> - Remove static structs to support multiple devices
> ---
> drivers/video/Kconfig | 16 ++
> drivers/video/Makefile | 1 +
> drivers/video/ocfb.c | 440
> +
> 3 files changed, 457 insertions(+)
> create mode 100644 drivers/video/ocfb.c
It looks good.
However, I added some minor comments. :-)
Sorry for late response.
[.]
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Would you re-order these headers alphabetically?
It enhances the readability.
[.]
> +struct ocfb_dev {
> + struct fb_info info;
> + void __iomem *regs;
> + /* flag indicating whether the regs are little endian accessed */
> + int little_endian;
> + /* Physical and virtual addresses of framebuffer */
> + phys_addr_t fb_phys;
> + void __iomem *fb_virt;
> + u32 pseudo_palette[PALETTE_SIZE];
> +};
Here, 'fb_virt' is already defined as 'void __iomem *'.
[.]
> + fbdev->info.fix.smem_start = fbdev->fb_phys;
> + fbdev->info.screen_base = (void __iomem *)fbdev->fb_virt;
Please remove unnecessary casting as below, because 'fb_virt' is already
defined as 'void __iomem *'.
+ fbdev->info.screen_base = fbdev->fb_virt;
> + fbdev->info.pseudo_palette = fbdev->pseudo_palette;
> +
> + /* Clear framebuffer */
> + memset_io((void __iomem *)fbdev->fb_virt, 0, fbsize);
Same here.
+ memset_io(fbdev->fb_virt, 0, fbsize);
Best regards,
Jingoo Han
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/9] mm: filemap: move radix tree hole searching here
On Fri, Jan 10, 2014 at 01:10:38PM -0500, Johannes Weiner wrote: > The radix tree hole searching code is only used for page cache, for > example the readahead code trying to get a a picture of the area > surrounding a fault. > > It sufficed to rely on the radix tree definition of holes, which is > "empty tree slot". But this is about to change, though, as shadow > page descriptors will be stored in the page cache after the actual > pages get evicted from memory. > > Move the functions over to mm/filemap.c and make them native page > cache operations, where they can later be adapted to handle the new > definition of "page cache hole". > > Signed-off-by: Johannes Weiner Reviewed-by: Minchan Kim -- 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/
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Here's one regression fix for 3.13 that I would appreciate if you could still pull in. It was an "interesting" one to debug, basically it's an old bug that got somewhat "exposed" by new code breaking the boot on PA Semi boards (yes, it does appear that some people are still using these !). Cheers, Ben. The following changes since commit f991db1cf1bdca43675b5d2df0af991719727029: Merge remote-tracking branch 'agust/merge' into merge (2013-12-30 14:48:27 +1100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge for you to fetch changes up to 10348f5976830e5d8f74e8abb04a9a057a5e8478: powerpc: Check return value of instance-to-package OF call (2014-01-13 09:49:17 +1100) Benjamin Herrenschmidt (1): powerpc: Check return value of instance-to-package OF call arch/powerpc/kernel/prom_init.c | 22 +- 1 file changed, 13 insertions(+), 9 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/9] fs: cachefiles: use add_to_page_cache_lru()
On Fri, Jan 10, 2014 at 01:10:35PM -0500, Johannes Weiner wrote:
> This code used to have its own lru cache pagevec up until a0b8cab3
> ("mm: remove lru parameter from __pagevec_lru_add and remove parts of
> pagevec API"). Now it's just add_to_page_cache() followed by
> lru_cache_add(), might as well use add_to_page_cache_lru() directly.
>
> Signed-off-by: Johannes Weiner
> Reviewed-by: Rik van Riel
Reviewed-by: Minchan Kim
--
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: powerpc32 broken by ef1313deafb7
On Sun, 2014-01-12 at 18:27 -0600, Rob Landley wrote: > Using the attached config, toolchain from > http://landley.net/aboriginal/bin/cross-compiler-powerpc.tar.bz2 but > presumably any 32 bit powerpc one should work, building ala make > ARCH=powerpc CROSS_COMPILE=powerpc- > >CC arch/powerpc/lib/xor_vmx.o > In file included from include/linux/thread_info.h:10, > from include/linux/preempt.h:9, > from arch/powerpc/lib/xor_vmx.c:22: > include/linux/types.h:29: error: both 'unsigned' and '_Bool' in > declaration specifiers > cc1: warnings being treated as errors > include/linux/types.h:29: warning: useless type name in empty > declaration > In file included from include/linux/kernel.h:11, > from include/asm-generic/bug.h:13, > from > /home/landley/linux/linux/arch/powerpc/include/asm/bug.h:127, > from include/linux/bug.h:4, > from include/linux/thread_info.h:11, > from include/linux/preempt.h:9, > from arch/powerpc/lib/xor_vmx.c:22: > > And then pages more errors. The commit before that one didn't do that. Your attached config has ... CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" So it's probably not what you wanted :-) I'm not sure what the problem you see is because I've definitely run all of these versions through my usual set of test configs without any trouble, including a bunch of 32-bit ones. Cheers, Ben. > Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] fix omap compile with randconfig
This fixes: arch/arm/mach-omap2/built-in.o: In function `omap_reserve': /data/l/linux-n900/arch/arm/mach-omap2/common.c:36: undefined reference to `omap_fb_reserve_memblock' Signed-off-by: Pavel Machek diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c index 9beecde..857907f 100644 --- a/arch/arm/mach-omap2/common.c +++ b/arch/arm/mach-omap2/common.c @@ -33,5 +33,7 @@ void __init omap_reserve(void) omap_dsp_reserve_sdram_memblock(); omap_secure_ram_reserve_memblock(); omap_barrier_reserve_memblock(); +#ifdef CONFIG_OMAP2_VRFB omap_fb_reserve_memblock(); +#endif } -- (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] PCI / remove: Check parent kobject in pci_destroy_dev() (was: Re: [PATCH v2 04/10] PCI: Destroy pci dev only once)
On Saturday, December 07, 2013 02:27:51 AM Rafael J. Wysocki wrote:
> On Thursday, December 05, 2013 10:52:36 PM Yinghai Lu wrote:
> > On Mon, Dec 2, 2013 at 6:49 AM, Rafael J. Wysocki
> > wrote:
> > >
> > > Scenario 5: pci_stop_and_remove_bus_device() is run concurrently
> > > for a device and its parent bridge via remove_callback().
> > >
> > > In that case both code paths attempt to acquire
> > > pci_remove_rescan_mutex. If the child device removal acquires
> > > it first, there will be no problems. However, if the parent
> > > bridge removal acquires it first, it will eventually execute
> > > pci_destroy_dev() for the child device, but that device will
> > > not be freed yet due to the reference held by the concurrent
> > > child removal. Consequently, both pci_stop_bus_device() and
> > > pci_remove_bus_device() will be executed for that device
> > > unnecessarily and pci_destroy_dev() will see a corrupted list
> > > head in that object. Moreover, an excess put_device() will
> > > be executed for that device in that case which may lead to a
> > > use-after-free in the final kobject_put() done by
> > > sysfs_schedule_callback_work().
> > >
> > > Index: linux-pm/include/linux/pci.h
> > > ===
> > > --- linux-pm.orig/include/linux/pci.h
> > > +++ linux-pm/include/linux/pci.h
> > > @@ -321,6 +321,7 @@ struct pci_dev {
> > > unsigned intmultifunction:1;/* Part of multi-function device
> > > */
> > > /* keep track of device state */
> > > unsigned intis_added:1;
> > > + unsigned intis_gone:1;
> > > unsigned intis_busmaster:1; /* device is busmaster */
> > > unsigned intno_msi:1; /* device may not use msi */
> > > unsigned intblock_cfg_access:1; /* config space access is
> > > blocked */
> > > Index: linux-pm/drivers/pci/remove.c
> > > ===
> > > --- linux-pm.orig/drivers/pci/remove.c
> > > +++ linux-pm/drivers/pci/remove.c
> > > @@ -34,6 +34,7 @@ static void pci_stop_dev(struct pci_dev
> > >
> > > static void pci_destroy_dev(struct pci_dev *dev)
> > > {
> > > + dev->is_gone = 1;
> > > device_del(>dev);
> > >
> > > down_write(_bus_sem);
> > > @@ -109,8 +110,10 @@ static void pci_remove_bus_device(struct
> > > */
> > > void pci_stop_and_remove_bus_device(struct pci_dev *dev)
> > > {
> > > - pci_stop_bus_device(dev);
> > > - pci_remove_bus_device(dev);
> > > + if (!dev->is_gone) {
> > > + pci_stop_bus_device(dev);
> > > + pci_remove_bus_device(dev);
> > > + }
> > > }
> > > EXPORT_SYMBOL(pci_stop_and_remove_bus_device);
> > >
> >
> > Yes, above change should address sys double remove problem.
>
> I've just realized that we don't need a new flag for that, though.
>
> It looks like we only need to check dev->dev.kobj.parent and return if that is
> NULL, because that means pci_destroy_dev() has run for that device already
> (I'm wondering why device_del() doesn't clear dev->parent, BTW, it looks like
> it should do that?).
>
> Of course, that still is going to be racy if we don't hold
> pci_remove_rescan_mutex around pci_stop_and_remove_bus_device() in every code
> path using it (or use another similar synchronization mechanism).
Before I forget about this, on top of the series I sent out on Friday.
Thanks,
Rafael
---
From: Rafael J. Wysocki
Subject: PCI / remove: Check parent kobject in pci_destroy_dev()
If pci_stop_and_remove_bus_device() is run concurrently for a device
and its parent bridge via remove_callback(), both code paths attempt
to acquire pci_rescan_remove_lock. If the child device removal
acquires it first, there will be no problems. However, if the parent
bridge removal acquires it first, it will eventually execute
pci_destroy_dev() for the child device, but that device object will
not be freed yet due to the reference held by the concurrent child
removal. Consequently, both pci_stop_bus_device() and
pci_remove_bus_device() will be executed for that device unnecessarily
and pci_destroy_dev() will see a corrupted list head in that object.
Moreover, an excess put_device() will be executed for that device in
that case which may lead to a use-after-free in the final
kobject_put() done by sysfs_schedule_callback_work().
To avoid that problem, make pci_destroy_dev() check if the device's
parent kobject is NULL, which only happens after device_del() has
already run for it. Make pci_destroy_dev() return immediately
whithout doing anything in that case.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/remove.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-pm/drivers/pci/remove.c
===
--- linux-pm.orig/drivers/pci/remove.c
+++ linux-pm/drivers/pci/remove.c
@@ -34,6 +34,9 @@ static void
Re: [PATCH] ARM: shmobile: compile drivers/sh for CONFIG_ARCH_SHMOBILE_MULTI
On Fri, Jan 10, 2014 at 03:18:15PM +, Ben Dooks wrote:
> If the kernel is built to support multi-arm configurmation with shmobile
> support built in, then the drivers/sh is not built. This contains drivers
> that are essential to devices support by that configuration, including the
> PM runtime code in drivers/sh/pm_runtime.c (which implicitly enables the
> bus clocks for all devices).
>
> If CONFIG_ARCH_SHMOBILE_MULTI then build the drivers/sh directory,
> but ensure that bits that may conflict (drivers/sh/clk if the common
> clock framework is not enabled) are built.
>
> The ARCH_SHMOBILE_MULTI was added by efacfce5f8a ("ARM: shmobile: Introduce
> ARCH_SHMOBILE_MULTI") but this has only just recently been found due to
> building device-tree only kernels.
>
> Cc: Linux Kernel list
> Cc: Linus SH list
> Cc: Simon Horman
> Cc: Magnus Damm
> Cc: Greg Kroah-Hartman
> Signed-off-by: Ben Dooks
> ---
> drivers/Makefile| 1 +
> drivers/sh/Makefile | 3 +++
> 2 files changed, 4 insertions(+)
>
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 8e3b8b0..abc4744 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -118,6 +118,7 @@ obj-$(CONFIG_SGI_SN) += sn/
> obj-y+= firmware/
> obj-$(CONFIG_CRYPTO) += crypto/
> obj-$(CONFIG_SUPERH) += sh/
> +obj-$(CONFIG_ARCH_SHMOBILE_MULTI)+= sh/
> obj-$(CONFIG_ARCH_SHMOBILE_LEGACY) += sh/
Can't we just do the following?
obj-$(CONFIG_ARCH_SHMOBILE) += sh/
> ifndef CONFIG_ARCH_USES_GETTIMEOFFSET
> obj-y+= clocksource/
> diff --git a/drivers/sh/Makefile b/drivers/sh/Makefile
> index fc67f56..86604a5 100644
> --- a/drivers/sh/Makefile
> +++ b/drivers/sh/Makefile
> @@ -3,7 +3,10 @@
> #
> obj-y:= intc/
>
> +ifeq ($(CONFIG_COMMON_CLK),n)
> obj-$(CONFIG_HAVE_CLK) += clk/
> +endif
> +
> obj-$(CONFIG_MAPLE) += maple/
> obj-$(CONFIG_SUPERHYWAY) += superhyway/
>
> --
> 1.8.5.2
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] lockdep: Kill held_lock->check and "int check" arg of __lock_acquire()
On Sun, Jan 12, 2014 at 06:45:54PM +0100, Oleg Nesterov wrote:
> diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
> index 92b1bfc..13bd13d 100644
> --- a/include/linux/lockdep.h
> +++ b/include/linux/lockdep.h
> @@ -252,7 +252,6 @@ struct held_lock {
> unsigned int trylock:1; /* 16
> bits */
>
> unsigned int read:2;/* see lock_acquire() comment */
> -unsigned int check:2; /* see lock_acquire() comment */
> unsigned int hardirqs_off:1;
> unsigned int references:11; /* 32
> bits */
The 'bits' comments seem to be crap, even before your patch.
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] x86 fixes for v3.13
Hi Linus,
Sorry, meant to push out this batch earlier this weekend.
The following changes since commit d6e0a2dd12f4067a5bcefb8bbd8ddbeff800afbc:
Linux 3.13-rc7 (2014-01-04 15:12:14 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/urgent
The head of this tree is 26bef1318adc1b3a530ecc807ef99346db2aa8b0.
x86, fpu, amd: Clear exceptions in AMD FXSAVE workaround (2014-01-11 19:15:52
-0800)
Linus Torvalds (1):
x86, fpu, amd: Clear exceptions in AMD FXSAVE workaround
Steven Rostedt (1):
ftrace/x86: Load ftrace_ops in parameter not the variable holding it
arch/x86/include/asm/fpu-internal.h | 13 +++--
arch/x86/kernel/entry_32.S | 4 ++--
arch/x86/kernel/entry_64.S | 2 +-
3 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/arch/x86/include/asm/fpu-internal.h
b/arch/x86/include/asm/fpu-internal.h
index c49a613c6452..cea1c76d49bf 100644
--- a/arch/x86/include/asm/fpu-internal.h
+++ b/arch/x86/include/asm/fpu-internal.h
@@ -293,12 +293,13 @@ static inline int restore_fpu_checking(struct task_struct
*tsk)
/* AMD K7/K8 CPUs don't save/restore FDP/FIP/FOP unless an exception
is pending. Clear the x87 state here by setting it to fixed
values. "m" is a random variable that should be in L1 */
- alternative_input(
- ASM_NOP8 ASM_NOP2,
- "emms\n\t" /* clear stack tags */
- "fildl %P[addr]", /* set F?P to defined value */
- X86_FEATURE_FXSAVE_LEAK,
- [addr] "m" (tsk->thread.fpu.has_fpu));
+ if (unlikely(static_cpu_has(X86_FEATURE_FXSAVE_LEAK))) {
+ asm volatile(
+ "fnclex\n\t"
+ "emms\n\t"
+ "fildl %P[addr]"/* set F?P to defined value */
+ : : [addr] "m" (tsk->thread.fpu.has_fpu));
+ }
return fpu_restore_checking(>thread.fpu);
}
diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index 51e2988c5728..a2a4f4697889 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -1082,7 +1082,7 @@ ENTRY(ftrace_caller)
pushl $0/* Pass NULL as regs pointer */
movl 4*4(%esp), %eax
movl 0x4(%ebp), %edx
- leal function_trace_op, %ecx
+ movl function_trace_op, %ecx
subl $MCOUNT_INSN_SIZE, %eax
.globl ftrace_call
@@ -1140,7 +1140,7 @@ ENTRY(ftrace_regs_caller)
movl 12*4(%esp), %eax /* Load ip (1st parameter) */
subl $MCOUNT_INSN_SIZE, %eax/* Adjust ip */
movl 0x4(%ebp), %edx/* Load parent ip (2nd parameter) */
- leal function_trace_op, %ecx /* Save ftrace_pos in 3rd parameter */
+ movl function_trace_op, %ecx /* Save ftrace_pos in 3rd parameter */
pushl %esp /* Save pt_regs as 4th parameter */
GLOBAL(ftrace_regs_call)
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index e21b0785a85b..1e96c3628bf2 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -88,7 +88,7 @@ END(function_hook)
MCOUNT_SAVE_FRAME \skip
/* Load the ftrace_ops into the 3rd parameter */
- leaq function_trace_op, %rdx
+ movq function_trace_op(%rip), %rdx
/* Load ip into the first parameter */
movq RIP(%rsp), %rdi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next v3 8/9] xen-netback: Timeout packets in RX path
On 09/01/14 09:20, Paul Durrant wrote: We are adding the skb to vif->rx_queue even when xenvif_rx_ring_slots_available(vif, min_slots_needed) said there is no space for that. Or am I missing something? Paul? That's correct. Part of the flow control improvement was to get rid of needless packet drops. For your purposes, you basically need to avoid using the queuing discipline and take packets into netback's vif->rx_queue regardless of the state of the shared ring so that you can drop them if they get beyond a certain age. So, perhaps you should never stop the netif queue, place an upper limit on vif->rx_queue (either packet or byte count) and drop when that is exceeded (i.e. mimicking pfifo or bfifo internally). How about this: - when the timer fires first we wake up the thread an tell it to drop all the packets in rx_queue - start_xmit then can drain the qdisc queue into the device queue - additionally, the RX thread should stop that timer when it was able to do some work Regards, Zoli -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] x86: Add check for number of available vectors before CPU down [v7]
On 01/12/2014 04:56 AM, Ingo Molnar wrote: > > * Prarit Bhargava wrote: > >> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64791 >> >> When a cpu is downed on a system, the irqs on the cpu are assigned to >> other cpus. It is possible, however, that when a cpu is downed there >> aren't enough free vectors on the remaining cpus to account for the >> vectors from the cpu that is being downed. >> >> This results in an interesting "overflow" condition where irqs are >> "assigned" to a CPU but are not handled. >> >> For example, when downing cpus on a 1-64 logical processor system: >> >> >> [ 232.021745] smpboot: CPU 61 is now offline >> [ 238.480275] smpboot: CPU 62 is now offline >> [ 245.991080] [ cut here ] >> [ 245.996270] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:264 >> dev_watchdog+0x246/0x250() >> [ 246.005688] NETDEV WATCHDOG: p786p1 (ixgbe): transmit queue 0 timed out >> [ 246.013070] Modules linked in: lockd sunrpc iTCO_wdt iTCO_vendor_support >> sb_edac ixgbe microcode e1000e pcspkr joydev edac_core lpc_ich ioatdma ptp >> mdio mfd_core i2c_i801 dca pps_core i2c_core wmi acpi_cpufreq isci libsas >> scsi_transport_sas >> [ 246.037633] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.12.0+ #14 >> [ 246.044451] Hardware name: Intel Corporation S4600LH >> ../SVRBD-ROW_T, BIOS SE5C600.86B.01.08.0003.022620131521 02/26/2013 >> [ 246.057371] 0009 88081fa03d40 8164fbf6 >> 88081fa0ee48 >> [ 246.065728] 88081fa03d90 88081fa03d80 81054ecc >> 88081fa13040 >> [ 246.074073] 88200cce 0040 >> >> [ 246.082430] Call Trace: >> [ 246.085174][] dump_stack+0x46/0x58 >> [ 246.091633] [] warn_slowpath_common+0x8c/0xc0 >> [ 246.098352] [] warn_slowpath_fmt+0x46/0x50 >> [ 246.104786] [] dev_watchdog+0x246/0x250 >> [ 246.110923] [] ? >> dev_deactivate_queue.constprop.31+0x80/0x80 >> [ 246.119097] [] call_timer_fn+0x3a/0x110 >> [ 246.125224] [] ? update_process_times+0x6f/0x80 >> [ 246.132137] [] ? >> dev_deactivate_queue.constprop.31+0x80/0x80 >> [ 246.140308] [] run_timer_softirq+0x1f0/0x2a0 >> [ 246.146933] [] __do_softirq+0xe0/0x220 >> [ 246.152976] [] call_softirq+0x1c/0x30 >> [ 246.158920] [] do_softirq+0x55/0x90 >> [ 246.164670] [] irq_exit+0xa5/0xb0 >> [ 246.170227] [] smp_apic_timer_interrupt+0x4a/0x60 >> [ 246.177324] [] apic_timer_interrupt+0x6a/0x70 >> [ 246.184041][] ? cpuidle_enter_state+0x5b/0xe0 >> [ 246.191559] [] ? cpuidle_enter_state+0x57/0xe0 >> [ 246.198374] [] cpuidle_idle_call+0xbd/0x200 >> [ 246.204900] [] arch_cpu_idle+0xe/0x30 >> [ 246.210846] [] cpu_startup_entry+0xd0/0x250 >> [ 246.217371] [] rest_init+0x77/0x80 >> [ 246.223028] [] start_kernel+0x3ee/0x3fb >> [ 246.229165] [] ? repair_env_string+0x5e/0x5e >> [ 246.235787] [] x86_64_start_reservations+0x2a/0x2c >> [ 246.242990] [] x86_64_start_kernel+0xf8/0xfc >> [ 246.249610] ---[ end trace fb74fdef54d79039 ]--- >> [ 246.254807] ixgbe :c2:00.0 p786p1: initiating reset due to tx timeout >> [ 246.262489] ixgbe :c2:00.0 p786p1: Reset adapter >> Last login: Mon Nov 11 08:35:14 from 10.18.17.119 >> [root@(none) ~]# [ 246.792676] ixgbe :c2:00.0 p786p1: detected SFP+: 5 >> [ 249.231598] ixgbe :c2:00.0 p786p1: NIC Link is Up 10 Gbps, Flow >> Control: RX/TX >> [ 246.792676] ixgbe :c2:00.0 p786p1: detected SFP+: 5 >> [ 249.231598] ixgbe :c2:00.0 p786p1: NIC Link is Up 10 Gbps, Flow >> Control: RX/TX >> >> (last lines keep repeating. ixgbe driver is dead until module reload.) >> >> If the downed cpu has more vectors than are free on the remaining cpus on the >> system, it is possible that some vectors are "orphaned" even though they are >> assigned to a cpu. In this case, since the ixgbe driver had a watchdog, the >> watchdog fired and notified that something was wrong. >> >> This patch adds a function, check_vectors(), to compare the number of vectors >> on the CPU going down and compares it to the number of vectors available on >> the system. If there aren't enough vectors for the CPU to go down, an >> error is returned and propogated back to userspace. >> >> v2: Do not need to look at percpu irqs >> v3: Need to check affinity to prevent counting of MSIs in IOAPIC Lowest >> Priority Mode >> v4: Additional changes suggested by Gong Chen. >> v5/v6/v7: Updated comment text >> >> Signed-off-by: Prarit Bhargava >> Reviewed-by: Gong Chen >> Cc: Andi Kleen >> Cc: Michel Lespinasse >> Cc: Seiji Aguchi >> Cc: Yang Zhang >> Cc: Paul Gortmaker >> Cc: Janet Morgan >> Cc: Tony Luck >> Cc: Ruiv Wang >> Cc: Gong Chen >> Cc: H. Peter Anvin >> Cc: Gong Chen >> Cc: x...@kernel.org >> --- >> arch/x86/include/asm/irq.h |1 + >> arch/x86/kernel/irq.c | 69 >> >> arch/x86/kernel/smpboot.c |6 >> 3 files changed, 76 insertions(+) >>
Re: [PATCH 2/2] x86, e820 disable ACPI Memory Hotplug if memory mapping is specified by user [v2]
On 01/11/2014 11:35 AM, 7egg...@gmx.de wrote: > > > On Fri, 10 Jan 2014, Prarit Bhargava wrote: > >> kdump uses memmap=exactmap and mem=X values to configure the memory >> mapping for the kdump kernel. If memory is hotadded during the boot of >> the kdump kernel it is possible that the page tables for the new memory >> cause the kdump kernel to run out of memory. >> >> Since the user has specified a specific mapping ACPI Memory Hotplug should be >> disabled in this case. > > I'll ask just in case: Is it possible to want memory hotplug in spite of > using memmap=exactmap or mem=X? Good question -- I can't think of a case. When a user specifies "memmap" or "mem" IMO they are asking for a very specific memory configuration. Having extra memory added above what the user has specified seems to defeat the purpose of "memmap" and "mem". P. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v6 1/5] futex: Misc cleanups
From: Jason Low
- Remove unnecessary head variables.
- Delete unused parameter in queue_unlock().
Cc: Ingo Molnar
Reviewed-by: Darren Hart
Acked-by: Peter Zijlstra
Cc: Thomas Gleixner
Reviewed-by: Paul E. McKenney
Cc: Mike Galbraith
Cc: Jeff Mahoney
Cc: Linus Torvalds
Cc: Scott Norton
Cc: Tom Vaden
Cc: Aswin Chandramouleeswaran
Cc: Waiman Long
Signed-off-by: Jason Low
Signed-off-by: Davidlohr Bueso
---
kernel/futex.c | 39 ---
1 file changed, 12 insertions(+), 27 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index f6ff019..085f5fa 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -598,13 +598,10 @@ lookup_pi_state(u32 uval, struct futex_hash_bucket *hb,
{
struct futex_pi_state *pi_state = NULL;
struct futex_q *this, *next;
- struct plist_head *head;
struct task_struct *p;
pid_t pid = uval & FUTEX_TID_MASK;
- head = >chain;
-
- plist_for_each_entry_safe(this, next, head, list) {
+ plist_for_each_entry_safe(this, next, >chain, list) {
if (match_futex(>key, key)) {
/*
* Another waiter already exists - bump up
@@ -986,7 +983,6 @@ futex_wake(u32 __user *uaddr, unsigned int flags, int
nr_wake, u32 bitset)
{
struct futex_hash_bucket *hb;
struct futex_q *this, *next;
- struct plist_head *head;
union futex_key key = FUTEX_KEY_INIT;
int ret;
@@ -999,9 +995,8 @@ futex_wake(u32 __user *uaddr, unsigned int flags, int
nr_wake, u32 bitset)
hb = hash_futex();
spin_lock(>lock);
- head = >chain;
- plist_for_each_entry_safe(this, next, head, list) {
+ plist_for_each_entry_safe(this, next, >chain, list) {
if (match_futex (>key, )) {
if (this->pi_state || this->rt_waiter) {
ret = -EINVAL;
@@ -1034,7 +1029,6 @@ futex_wake_op(u32 __user *uaddr1, unsigned int flags, u32
__user *uaddr2,
{
union futex_key key1 = FUTEX_KEY_INIT, key2 = FUTEX_KEY_INIT;
struct futex_hash_bucket *hb1, *hb2;
- struct plist_head *head;
struct futex_q *this, *next;
int ret, op_ret;
@@ -1082,9 +1076,7 @@ retry_private:
goto retry;
}
- head = >chain;
-
- plist_for_each_entry_safe(this, next, head, list) {
+ plist_for_each_entry_safe(this, next, >chain, list) {
if (match_futex (>key, )) {
if (this->pi_state || this->rt_waiter) {
ret = -EINVAL;
@@ -1097,10 +1089,8 @@ retry_private:
}
if (op_ret > 0) {
- head = >chain;
-
op_ret = 0;
- plist_for_each_entry_safe(this, next, head, list) {
+ plist_for_each_entry_safe(this, next, >chain, list) {
if (match_futex (>key, )) {
if (this->pi_state || this->rt_waiter) {
ret = -EINVAL;
@@ -1270,7 +1260,6 @@ static int futex_requeue(u32 __user *uaddr1, unsigned int
flags,
int drop_count = 0, task_count = 0, ret;
struct futex_pi_state *pi_state = NULL;
struct futex_hash_bucket *hb1, *hb2;
- struct plist_head *head1;
struct futex_q *this, *next;
u32 curval2;
@@ -1393,8 +1382,7 @@ retry_private:
}
}
- head1 = >chain;
- plist_for_each_entry_safe(this, next, head1, list) {
+ plist_for_each_entry_safe(this, next, >chain, list) {
if (task_count - nr_wake >= nr_requeue)
break;
@@ -1494,7 +1482,7 @@ static inline struct futex_hash_bucket *queue_lock(struct
futex_q *q)
}
static inline void
-queue_unlock(struct futex_q *q, struct futex_hash_bucket *hb)
+queue_unlock(struct futex_hash_bucket *hb)
__releases(>lock)
{
spin_unlock(>lock);
@@ -1867,7 +1855,7 @@ retry_private:
ret = get_futex_value_locked(, uaddr);
if (ret) {
- queue_unlock(q, *hb);
+ queue_unlock(*hb);
ret = get_user(uval, uaddr);
if (ret)
@@ -1881,7 +1869,7 @@ retry_private:
}
if (uval != val) {
- queue_unlock(q, *hb);
+ queue_unlock(*hb);
ret = -EWOULDBLOCK;
}
@@ -2029,7 +2017,7 @@ retry_private:
* Task is exiting and we just wait for the
* exit to complete.
*/
- queue_unlock(, hb);
+ queue_unlock(hb);
put_futex_key();
cond_resched();
goto retry;
@@ -2081,7 +2069,7 @@ retry_private:
goto out_put_key;
out_unlock_put_key:
- queue_unlock(, hb);
+ queue_unlock(hb);
out_put_key:
[PATCH 5/5] futex: Silence uninitialized warnings
From: Davidlohr Bueso
Callers of cmpxchg_futex_value_locked() can trigger the following:
kernel/futex.c: In function ‘futex_lock_pi_atomic’:
kernel/futex.c:725: warning: ‘curval’ may be used uninitialized in this function
This was initially addressed by commit 7cfdaf38, but others still remain.
Silence
these messages once and for all as the variables really aren't uninitialized.
Cc: Ingo Molnar
Acked-by: Darren Hart
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Paul E. McKenney
Cc: Mike Galbraith
Cc: Jeff Mahoney
Cc: Linus Torvalds
Cc: Scott Norton
Cc: Tom Vaden
Cc: Aswin Chandramouleeswaran
Cc: Waiman Long
Cc: Jason Low
Signed-off-by: Davidlohr Bueso
---
kernel/futex.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index be6399a..8d40953 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -838,7 +838,7 @@ static int futex_lock_pi_atomic(u32 __user *uaddr, struct
futex_hash_bucket *hb,
struct task_struct *task, int set_waiters)
{
int lock_taken, ret, force_take = 0;
- u32 uval, newval, curval, vpid = task_pid_vnr(task);
+ u32 uval, newval, uninitialized_var(curval), vpid = task_pid_vnr(task);
retry:
ret = lock_taken = 0;
@@ -2227,7 +2227,7 @@ static int futex_unlock_pi(u32 __user *uaddr, unsigned
int flags)
struct futex_hash_bucket *hb;
struct futex_q *this, *next;
union futex_key key = FUTEX_KEY_INIT;
- u32 uval, vpid = task_pid_vnr(current);
+ u32 uninitialized_var(uval), vpid = task_pid_vnr(current);
int ret;
retry:
@@ -2843,7 +2843,7 @@ SYSCALL_DEFINE6(futex, u32 __user *, uaddr, int, op, u32,
val,
static int __init futex_init(void)
{
- u32 curval;
+ u32 uninitialized_var(curval);
unsigned long i;
#if CONFIG_BASE_SMALL
--
1.8.1.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 v6 2/5] futex: Larger hash table
From: Davidlohr Bueso
Currently, the futex global hash table suffers from it's fixed, smallish
(for today's standards) size of 256 entries, as well as its lack of NUMA
awareness. Large systems, using many futexes, can be prone to high amounts
of collisions; where these futexes hash to the same bucket and lead to
extra contention on the same hb->lock. Furthermore, cacheline bouncing is a
reality when we have multiple hb->locks residing on the same cacheline and
different futexes hash to adjacent buckets.
This patch keeps the current static size of 16 entries for small systems,
or otherwise, 256 * ncpus (or larger as we need to round the number to a
power of 2). Note that this number of CPUs accounts for all CPUs that can
ever be available in the system, taking into consideration things like
hotpluging. While we do impose extra overhead at bootup by making the hash
table larger, this is a one time thing, and does not shadow the benefits
of this patch.
Furthermore, as suggested by tglx, by cache aligning the hash buckets we can
avoid access across cacheline boundaries and also avoid massive cache line
bouncing if multiple cpus are hammering away at different hash buckets which
happen to reside in the same cache line.
Also, similar to other core kernel components (pid, dcache, tcp), by using
alloc_large_system_hash() we benefit from its NUMA awareness and thus the
table is distributed among the nodes instead of in a single one.
For a custom microbenchmark that pounds on the uaddr hashing -- making the wait
path fail at futex_wait_setup() returning -EWOULDBLOCK for large amounts of
futexes, we can see the following benefits on a 80-core, 8-socket 1Tb server:
+-+++---+---+
| threads | baseline (ops/sec) | aligned-only (ops/sec) | large table (ops/sec)
| large table+aligned (ops/sec) |
+-+++---+---+
| 512 | 32426 | 50531 (+55.8%)| 255274 (+687.2%)
| 292553 (+802.2%) |
| 256 | 65360 | 99588 (+52.3%)| 443563 (+578.6%)
| 508088 (+677.3%) |
| 128 | 125635 | 200075 (+59.2%)| 742613 (+491.1%)
| 835452 (+564.9%) |
| 80 | 193559 | 323425 (+67.1%)| 1028147 (+431.1%)
| 1130304 (+483.9%) |
| 64 | 247667 | 443740 (+79.1%)| 997300 (+302.6%)
| 1145494 (+362.5%) |
| 32 | 628412 | 721401 (+14.7%)| 965996 (+53.7%)
| 1122115 (+78.5%) |
+-+++---+---+
Cc: Ingo Molnar
Reviewed-by: Darren Hart
Acked-by: Peter Zijlstra
Cc: Thomas Gleixner
Reviewed-by: Paul E. McKenney
Cc: Mike Galbraith
Cc: Jeff Mahoney
Cc: Linus Torvalds
Cc: Scott Norton
Cc: Tom Vaden
Cc: Aswin Chandramouleeswaran
Reviewed-by: Waiman Long
Reviewed-and-tested-by: Jason Low
Signed-off-by: Davidlohr Bueso
---
kernel/futex.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index 085f5fa..577481d 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -63,6 +63,7 @@
#include
#include
#include
+#include
#include
@@ -70,8 +71,6 @@
int __read_mostly futex_cmpxchg_enabled;
-#define FUTEX_HASHBITS (CONFIG_BASE_SMALL ? 4 : 8)
-
/*
* Futex flags used to encode options to functions and preserve them across
* restarts.
@@ -149,9 +148,11 @@ static const struct futex_q futex_q_init = {
struct futex_hash_bucket {
spinlock_t lock;
struct plist_head chain;
-};
+} cacheline_aligned_in_smp;
-static struct futex_hash_bucket futex_queues[1both.word)+sizeof(key->both.ptr))/4,
key->both.offset);
- return _queues[hash & ((1 << FUTEX_HASHBITS)-1)];
+ return _queues[hash & (futex_hashsize - 1)];
}
/*
@@ -2719,7 +2720,18 @@ SYSCALL_DEFINE6(futex, u32 __user *, uaddr, int, op,
u32, val,
static int __init futex_init(void)
{
u32 curval;
- int i;
+ unsigned long i;
+
+#if CONFIG_BASE_SMALL
+ futex_hashsize = 16;
+#else
+ futex_hashsize = roundup_pow_of_two(256 * num_possible_cpus());
+#endif
+
+ futex_queues = alloc_large_system_hash("futex", sizeof(*futex_queues),
+ futex_hashsize, 0,
+ futex_hashsize < 256 ?
HASH_SMALL : 0,
+ NULL, NULL, futex_hashsize,
futex_hashsize);
/*
* This will fail and we want it. Some arch implementations do
@@ -2734,7 +2746,7 @@ static int __init futex_init(void)
if
[PATCH v6 0/5] futex: Wakeup optimizations
Changes from v5 [https://lkml.org/lkml/2014/1/2/178]: - Added latest review tags - Removed redundant CONFIG_SMP ifdef in futex_get_mm() - Updated comments per Darren's suggestions. Changes from v3/v4 [http://lkml.org/lkml/2013/12/19/627]: - Almost completely redid patch 4, based on suggestions by Linus. Instead of adding an atomic counter to keep track of the plist size, couple the list's head empty call with a check to see if the hb lock is locked. This solves the race that motivated the use of the new atomic field. - Fix grammar in patch 3 - Fix SOB tags. Changes from v2 [http://lwn.net/Articles/575449/]: - Reordered SOB tags to reflect me as primary author. - Improved ordering guarantee comments for patch 4. - Rebased patch 4 against Linus' tree (this patch didn't apply after the recent futex changes/fixes). Changes from v1 [https://lkml.org/lkml/2013/11/22/525]: - Removed patch "futex: Check for pi futex_q only once". - Cleaned up ifdefs for larger hash table. - Added a doc patch from tglx that describes the futex ordering guarantees. - Improved the lockless plist check for the wake calls. Based on the community feedback, the necessary abstractions and barriers are added to maintain ordering guarantees. Code documentation is also updated. - Removed patch "sched,futex: Provide delayed wakeup list". Based on feedback from PeterZ, I will look into this as a separate issue once the other patches are settled. We have been dealing with a customer database workload on large 12Tb, 240 core 16 socket NUMA system that exhibits high amounts of contention on some of the locks that serialize internal futex data structures. This workload specially suffers in the wakeup paths, where waiting on the corresponding hb->lock can account for up to ~60% of the time. The result of such calls can mostly be classified as (i) nothing to wake up and (ii) wakeup large amount of tasks. Before these patches are applied, we can see this pathological behavior: 37.12% 826174 xxx [kernel.kallsyms] [k] _raw_spin_lock --- _raw_spin_lock | |--97.14%-- futex_wake | do_futex | sys_futex | system_call_fastpath | | | |--99.70%-- 0x7f383fbdea1f | | yyy 43.71% 762296 xxx [kernel.kallsyms] [k] _raw_spin_lock --- _raw_spin_lock | |--53.74%-- futex_wake | do_futex | sys_futex | system_call_fastpath | | | |--99.40%-- 0x7fe7d44a4c05 | | zzz |--45.90%-- futex_wait_setup | futex_wait | do_futex | sys_futex | system_call_fastpath | 0x7fe7ba315789 | syscall With these patches, contention is practically non existent: 0.10% 49 xxx [kernel.kallsyms] [k] _raw_spin_lock --- _raw_spin_lock | |--76.06%-- futex_wait_setup | futex_wait | do_futex | sys_futex | system_call_fastpath | | | |--99.90%-- 0x7f3165e63789 | | syscall| ... |--6.27%-- futex_wake | do_futex | sys_futex | system_call_fastpath | | | |--54.56%-- 0x7f317fff2c05 ... Patch 1 is a cleanup. Patch 2 addresses the well known issue of the global hash table. By creating a larger and NUMA aware table, we can reduce the false sharing and collisions, thus reducing the chance of different futexes using hb->lock. Patch 3 documents the futex ordering guarantees. Patch 4 reduces contention on the corresponding hb->lock by not trying to acquire it if there are no blocked tasks in the waitqueue. This particularly deals with point (i) above, where we see that it is not uncommon for up to 90% of wakeup calls end up returning 0, indicating that no tasks were woken. Patch 5 silences a gcc warning msg. This patchset has also been tested on smaller systems for a variety of benchmarks, including java workloads, kernel builds and custom bang-the-hell-out-of hb locks programs. So far, no functional or performance regressions have been seen. Furthermore, no issues were found when running the different tests in the futextest suite: http://git.kernel.org/cgit/linux/kernel/git/dvhart/futextest.git/ This patchset applies on top of Linus' tree as of v3.13-rc6 (9a0bb296) Special thanks to Scott Norton, Tom Vanden,
[PATCH v6 3/5] futex: Document ordering guarantees
From: Thomas Gleixner That's essential, if you want to hack on futexes. Cc: Ingo Molnar Reviewed-by: Darren Hart Acked-by: Peter Zijlstra Cc: Thomas Gleixner Reviewed-by: Paul E. McKenney Cc: Mike Galbraith Cc: Jeff Mahoney Cc: Linus Torvalds Cc: Randy Dunlap Cc: Scott Norton Cc: Tom Vaden Cc: Aswin Chandramouleeswaran Cc: Waiman Long Cc: Jason Low Signed-off-by: Thomas Gleixner Signed-off-by: Davidlohr Bueso --- kernel/futex.c | 57 + 1 file changed, 57 insertions(+) diff --git a/kernel/futex.c b/kernel/futex.c index 577481d..fcc6850 100644 --- a/kernel/futex.c +++ b/kernel/futex.c @@ -69,6 +69,63 @@ #include "locking/rtmutex_common.h" +/* + * Basic futex operation and ordering guarantees: + * + * The waiter reads the futex value in user space and calls + * futex_wait(). This function computes the hash bucket and acquires + * the hash bucket lock. After that it reads the futex user space value + * again and verifies that the data has not changed. If it has not + * changed it enqueues itself into the hash bucket, releases the hash + * bucket lock and schedules. + * + * The waker side modifies the user space value of the futex and calls + * futex_wake(). This functions computes the hash bucket and acquires + * the hash bucket lock. Then it looks for waiters on that futex in the + * hash bucket and wakes them. + * + * Note that the spin_lock serializes waiters and wakers, so that the + * following scenario is avoided: + * + * CPU 0 CPU 1 + * val = *futex; + * sys_futex(WAIT, futex, val); + * futex_wait(futex, val); + * uval = *futex; + * *futex = newval; + * sys_futex(WAKE, futex); + * futex_wake(futex); + * if (queue_empty()) + * return; + * if (uval == val) + * lock(hash_bucket(futex)); + * queue(); + * unlock(hash_bucket(futex)); + * schedule(); + * + * This would cause the waiter on CPU 0 to wait forever because it + * missed the transition of the user space value from val to newval + * and the waker did not find the waiter in the hash bucket queue. + * The spinlock serializes that: + * + * CPU 0 CPU 1 + * val = *futex; + * sys_futex(WAIT, futex, val); + * futex_wait(futex, val); + * lock(hash_bucket(futex)); + * uval = *futex; + * *futex = newval; + * sys_futex(WAKE, futex); + * futex_wake(futex); + * lock(hash_bucket(futex)); + * if (uval == val) + * queue(); + * unlock(hash_bucket(futex)); + * schedule(); if (!queue_empty()) + * wake_waiters(futex); + * unlock(hash_bucket(futex)); + */ + int __read_mostly futex_cmpxchg_enabled; /* -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] futex: Avoid taking hb lock if nothing to wakeup
From: Davidlohr Bueso In futex_wake() there is clearly no point in taking the hb->lock if we know beforehand that there are no tasks to be woken. While the hash bucket's plist head is a cheap way of knowing this, we cannot rely 100% on it as there is a racy window between the futex_wait call and when the task is actually added to the plist. To this end, we couple it with the spinlock check as tasks trying to enter the critical region are most likely potential waiters that will be added to the plist, thus preventing tasks sleeping forever if wakers don't acknowledge all possible waiters. Furthermore, the futex ordering guarantees are preserved, ensuring that waiters either observe the changed user space value before blocking or is woken by a concurrent waker. For wakers, this is done by relying on the barriers in get_futex_key_refs() -- for archs that do not have implicit mb in atomic_inc(), we explicitly add them through a new futex_get_mm function. For waiters we rely on the fact that spin_lock calls already update the head counter, so spinners are visible even if the lock hasn't been acquired yet. For more details please refer to the updated comments in the code and related discussion: https://lkml.org/lkml/2013/11/26/556 Special thanks to tglx for careful review and feedback. Cc: Ingo Molnar Reviewed-by: Darren Hart Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Paul E. McKenney Cc: Mike Galbraith Cc: Jeff Mahoney Suggested-by: Linus Torvalds Cc: Scott Norton Cc: Tom Vaden Cc: Aswin Chandramouleeswaran Cc: Waiman Long Cc: Jason Low Signed-off-by: Davidlohr Bueso --- kernel/futex.c | 115 + 1 file changed, 91 insertions(+), 24 deletions(-) diff --git a/kernel/futex.c b/kernel/futex.c index fcc6850..be6399a 100644 --- a/kernel/futex.c +++ b/kernel/futex.c @@ -75,17 +75,20 @@ * The waiter reads the futex value in user space and calls * futex_wait(). This function computes the hash bucket and acquires * the hash bucket lock. After that it reads the futex user space value - * again and verifies that the data has not changed. If it has not - * changed it enqueues itself into the hash bucket, releases the hash - * bucket lock and schedules. + * again and verifies that the data has not changed. If it has not changed + * it enqueues itself into the hash bucket, releases the hash bucket lock + * and schedules. * * The waker side modifies the user space value of the futex and calls - * futex_wake(). This functions computes the hash bucket and acquires - * the hash bucket lock. Then it looks for waiters on that futex in the - * hash bucket and wakes them. + * futex_wake(). This function computes the hash bucket and acquires the + * hash bucket lock. Then it looks for waiters on that futex in the hash + * bucket and wakes them. * - * Note that the spin_lock serializes waiters and wakers, so that the - * following scenario is avoided: + * In futex wake up scenarios where no tasks are blocked on a futex, taking + * the hb spinlock can be avoided and simply return. In order for this + * optimization to work, ordering guarantees must exist so that the waiter + * being added to the list is acknowledged when the list is concurrently being + * checked by the waker, avoiding scenarios like the following: * * CPU 0 CPU 1 * val = *futex; @@ -106,24 +109,52 @@ * This would cause the waiter on CPU 0 to wait forever because it * missed the transition of the user space value from val to newval * and the waker did not find the waiter in the hash bucket queue. - * The spinlock serializes that: + * + * The correct serialization ensures that a waiter either observes + * the changed user space value before blocking or is woken by a + * concurrent waker: * * CPU 0 CPU 1 * val = *futex; * sys_futex(WAIT, futex, val); * futex_wait(futex, val); - * lock(hash_bucket(futex)); - * uval = *futex; - * *futex = newval; - * sys_futex(WAKE, futex); - * futex_wake(futex); - * lock(hash_bucket(futex)); + * + * waiters++; + * mb(); (A) <-- paired with -. + * | + * lock(hash_bucket(futex)); | + * | + * uval = *futex; | + * |*futex = newval; + * |sys_futex(WAKE, futex); + * | futex_wake(futex); + * | + * `---> mb(); (B) * if (uval == val) - * queue(); + * queue(); * unlock(hash_bucket(futex)); - * schedule(); if (!queue_empty()) - * wake_waiters(futex); - *
Re: [Xen-devel] [PATCH net-next v3 2/9] xen-netback: Change TX path from grant copy to mapping
On 10/01/14 16:02, David Vrabel wrote: On 10/01/14 15:24, Zoltan Kiss wrote: If the grant table code doesn't provide the API calls you need you can either: a) add the new API as a prerequisite patch. b) use the existing API calls and live with the performance problem, until you can refactor the API later on. Adding a netback-specific hack isn't a valid option. David Ok, I've sent in the patch which does a) Zoli -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 02/13] ppc/cell: use get_unused_fd_flags(0) instead of get_unused_fd()
On Tue, 2013-07-02 at 18:39 +0200, Yann Droneaud wrote: > Macro get_unused_fd() is used to allocate a file descriptor with > default flags. Those default flags (0) can be "unsafe": > O_CLOEXEC must be used by default to not leak file descriptor > across exec(). > > Instead of macro get_unused_fd(), functions anon_inode_getfd() > or get_unused_fd_flags() should be used with flags given by userspace. > If not possible, flags should be set to O_CLOEXEC to provide userspace > with a default safe behavor. > > In a further patch, get_unused_fd() will be removed so that > new code start using anon_inode_getfd() or get_unused_fd_flags() > with correct flags. > > This patch replaces calls to get_unused_fd() with equivalent call to > get_unused_fd_flags(0) to preserve current behavor for existing code. > > The hard coded flag value (0) should be reviewed on a per-subsystem basis, > and, if possible, set to O_CLOEXEC. > > Signed-off-by: Yann Droneaud Should I merge this (v5 on patchwork) or let Al do it ? Acked-by: Benjamin Herrenschmidt > --- > arch/powerpc/platforms/cell/spufs/inode.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/powerpc/platforms/cell/spufs/inode.c > b/arch/powerpc/platforms/cell/spufs/inode.c > index f390042..88df441 100644 > --- a/arch/powerpc/platforms/cell/spufs/inode.c > +++ b/arch/powerpc/platforms/cell/spufs/inode.c > @@ -301,7 +301,7 @@ static int spufs_context_open(struct path *path) > int ret; > struct file *filp; > > - ret = get_unused_fd(); > + ret = get_unused_fd_flags(0); > if (ret < 0) > return ret; > > @@ -518,7 +518,7 @@ static int spufs_gang_open(struct path *path) > int ret; > struct file *filp; > > - ret = get_unused_fd(); > + ret = get_unused_fd_flags(0); > if (ret < 0) > return ret; > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mm, memcg: avoid oom notification when current needs access to memory reserves
On Fri, 10 Jan 2014, Johannes Weiner wrote: > > Your patch, which is partially based on my suggestion to move the > > mem_cgroup_oom_notify() and call it from two places to support both > > memory.oom_control == 1 and != 1, is something that I liked as you know. > > It's based on my patch which is now removed from -mm. So if you want to > > rebase that patch and propose it, that's great, but this is yet another > > occurrence of where important patches have been yanked out just before the > > merge window when the problem they are fixing is real and we depend on > > them. > > We tried to discuss and understand the problem, yet all we got was > "it's OBVIOUS" and "Google has been using this patch ever since we > switched to memcg" and flat out repetitions of the same points about > reliable OOM notification that were already put into question. > > You still have not convinced me that the problem exists as you > described it, apart from the aspects that Michal is now fixing > separately because you did not show any signs of cooperating. > I cooperated by suggesting his patch which moves the mem_cgroup_oom_notify(), Johannes. The problem is that it depends on my patch which was removed from -mm. He can rebase that patch, but I'm hoping it is done before the merge window for inclusion in 3.14. > None of this will change until you start working with us and actually > address feedback and inquiries instead of just repeating your talking > points over and over. > I worked with Michal, who acked my patch, and then wrote another patch on top of it based partially on my suggestion, Johannes. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mm, memcg: avoid oom notification when current needs access to memory reserves
On Fri, 10 Jan 2014, Johannes Weiner wrote: > > > > It was acked-by Michal. > > Michal acked it before we had most of the discussions and now he is > proposing an alternate version of yours, a patch that you are even > discussing with him concurrently in another thread. To claim he is > still backing your patch because of that initial ack is disingenuous. > His patch depends on mine, Johannes. > > Johannes is arguing for the same semantics that VMPRESSURE_CRITICAL and/or > > memory thresholds provides, which disagrees from the list of solutions > > that Documentation/cgroups/memory.txt gives for userspace oom handler > > wakeups and is required for any sane implementation. > > No, he's not and I'm sick of you repeating refuted garbage like this. > > You have convinced neither me nor Michal that your problem is entirely > real and when confronted with doubt you just repeat the same points > over and over. > The conditional to check if current needs access to memory reserves to make forward progress and avoid oom killing anything else is done after the memcg notification. It's real per section 6.8.4 of the C99 standard which defines how a conditional works. We do not want a userspace notification in such a case because userspace testing of whether the condition is actionable would be unreliable. This is not dead code, it does get executed. > The one aspect of your change that we DO agree is valid is now fixed > by Michal in a separate attempt because you could not be bothered to > incorporate feedback into your patch. > I suggested his patch, Johannes, but his patch depends on mine. I'm hoping he can rebase his patch and it's done and merged into -mm before the merge window for 3.14 as I've stated. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] power: clock_ops.c: fixup clk prepare/unprepare count
Hi Ben,
Thank you for the patch.
On Saturday 11 January 2014 13:05:38 Ben Dooks wrote:
> The drivers/base/power/clock_ops.c file is causing warnings from
> the clock driver (as shown below) due to failing to do a clk_prepare()
> call before enabling a clock. It also fails to check the balance of
> prepare/unprepare as __pm_clk_remove() do clk_disable_unprepare() call.
>
> This bug has probably been in since commit b2476490e ("clk: introduce
> the common clock framework") as the warning was part of the original
> commit. It is strange that it has not been noticed (although this has
> also been coupled with a failure for certain SH builds to not build the
> necessary glue to use this method of controlling the clocks).
>
> In summary, this is probably needed in several stable branches but need
> advice on which ones.
>
> On the Renesas Lager board, this causes numerous warnings of the following
> and even worse the clock system will not enable clocks, causing drivers
> that are in development to fail to work:
>
> WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:883 __clk_enable+0x2c/0xa0()
I've never noticed this on Lager, probably because Lager multiplatform doesn't
make use of clock_ops.c as drivers/sh/pm_runtime.c (which you addressed in
another patch that I've also replied to). I'm thus not sure we need to apply
this as a fix and backport it to stable branches.
> Cc: "Rafael J. Wysocki"
> Cc: Pavel Machek
> Cc: Greg Kroah-Hartman
> Cc: linux...@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Ben Dooks
> Reviewed-by: Ian Molton
> ---
> drivers/base/power/clock_ops.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/base/power/clock_ops.c b/drivers/base/power/clock_ops.c
> index 9d8fde7..b9dd8fa 100644
> --- a/drivers/base/power/clock_ops.c
> +++ b/drivers/base/power/clock_ops.c
> @@ -43,6 +43,7 @@ static void pm_clk_acquire(struct device *dev, struct
> pm_clock_entry *ce) if (IS_ERR(ce->clk)) {
> ce->status = PCE_STATUS_ERROR;
> } else {
> + clk_prepare(ce->clk);
> ce->status = PCE_STATUS_ACQUIRED;
> dev_dbg(dev, "Clock %s managed by runtime PM.\n", ce->con_id);
> }
> @@ -99,10 +100,12 @@ static void __pm_clk_remove(struct pm_clock_entry *ce)
>
> if (ce->status < PCE_STATUS_ERROR) {
> if (ce->status == PCE_STATUS_ENABLED)
> - clk_disable_unprepare(ce->clk);
> + clk_disable(ce->clk);
>
> - if (ce->status >= PCE_STATUS_ACQUIRED)
> + if (ce->status >= PCE_STATUS_ACQUIRED) {
> + clk_unprepare(ce->clk);
> clk_put(ce->clk);
> + }
> }
>
> kfree(ce->con_id);
--
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/
Re: [PATCH] ARM: shmobile: compile drivers/sh for CONFIG_ARCH_SHMOBILE_MULTI
Hi Ben,
On Sunday 12 January 2014 22:54:15 Laurent Pinchart wrote:
> Hi Ben,
>
> Thank you for the patch.
>
> On Saturday 11 January 2014 13:06:29 Ben Dooks wrote:
> > If the kernel is built to support multi-arm configurmation with shmobile
> > support built in, then the drivers/sh is not built. This contains drivers
> > that are essential to devices support by that configuration, including the
> > PM runtime code in drivers/sh/pm_runtime.c (which implicitly enables the
> > bus clocks for all devices).
Thinking a bit more about this, I think the approach taken in
drivers/sh/pm_runtime.c isn't good. The code enables device clocks when
devices are bound to a driver, increasing power consumption when devices are
idle. Instead of enabling it for ARCH_SHMOBILE_MULTI I'd like to either add
explicit clock support to drivers, or to integrate clocks with runtime PM
only.
> > If CONFIG_ARCH_SHMOBILE_MULTI then build the drivers/sh directory,
> > but ensure that bits that may conflict (drivers/sh/clk if the common
> > clock framework is not enabled) are built.
> >
> > The ARCH_SHMOBILE_MULTI was added by efacfce5f8a ("ARM: shmobile:
> > Introduce ARCH_SHMOBILE_MULTI") but this has only just recently been found
> > due to building device-tree only kernels.
> >
> > Cc: Linux Kernel list
> > Cc: Linus SH list
> > Cc: Simon Horman
> > Cc: Magnus Damm
> > Cc: Greg Kroah-Hartman
> > Signed-off-by: Ben Dooks
> > ---
> >
> > drivers/Makefile| 1 +
> > drivers/sh/Makefile | 3 +++
> > 2 files changed, 4 insertions(+)
> >
> > diff --git a/drivers/Makefile b/drivers/Makefile
> > index 8e3b8b0..abc4744 100644
> > --- a/drivers/Makefile
> > +++ b/drivers/Makefile
> > @@ -118,6 +118,7 @@ obj-$(CONFIG_SGI_SN)+= sn/
> >
> > obj-y += firmware/
> > obj-$(CONFIG_CRYPTO) += crypto/
> > obj-$(CONFIG_SUPERH) += sh/
> >
> > +obj-$(CONFIG_ARCH_SHMOBILE_MULTI) += sh/
> >
> > obj-$(CONFIG_ARCH_SHMOBILE_LEGACY) += sh/
> > ifndef CONFIG_ARCH_USES_GETTIMEOFFSET
> > obj-y += clocksource/
> >
> > diff --git a/drivers/sh/Makefile b/drivers/sh/Makefile
> > index fc67f56..86604a5 100644
> > --- a/drivers/sh/Makefile
> > +++ b/drivers/sh/Makefile
> > @@ -3,7 +3,10 @@
> >
> > #
> > obj-y := intc/
>
> Is intc needed as well ?
>
> > +ifeq ($(CONFIG_COMMON_CLK),n)
> >
> > obj-$(CONFIG_HAVE_CLK) += clk/
> >
> > +endif
> > +
> >
> > obj-$(CONFIG_MAPLE)+= maple/
> > obj-$(CONFIG_SUPERHYWAY) += superhyway/
--
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/
YOUR ATTENTION PLEASE!
Dear Friend, I'm sorry to engage your privacy in this manner. I am Mr.Kuan-Yin Li Hua from China, I need your partnership for a transfer of Fity Five Million United State Dollars. Kindly reply me back in you are interested to enable me provide you with further details. Regards, Mr.Kuan-Yin Li Hu --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: shmobile: compile drivers/sh for CONFIG_ARCH_SHMOBILE_MULTI
Hi Ben,
Thank you for the patch.
On Saturday 11 January 2014 13:06:29 Ben Dooks wrote:
> If the kernel is built to support multi-arm configurmation with shmobile
> support built in, then the drivers/sh is not built. This contains drivers
> that are essential to devices support by that configuration, including the
> PM runtime code in drivers/sh/pm_runtime.c (which implicitly enables the
> bus clocks for all devices).
>
> If CONFIG_ARCH_SHMOBILE_MULTI then build the drivers/sh directory,
> but ensure that bits that may conflict (drivers/sh/clk if the common
> clock framework is not enabled) are built.
>
> The ARCH_SHMOBILE_MULTI was added by efacfce5f8a ("ARM: shmobile: Introduce
> ARCH_SHMOBILE_MULTI") but this has only just recently been found due to
> building device-tree only kernels.
>
> Cc: Linux Kernel list
> Cc: Linus SH list
> Cc: Simon Horman
> Cc: Magnus Damm
> Cc: Greg Kroah-Hartman
> Signed-off-by: Ben Dooks
> ---
> drivers/Makefile| 1 +
> drivers/sh/Makefile | 3 +++
> 2 files changed, 4 insertions(+)
>
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 8e3b8b0..abc4744 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -118,6 +118,7 @@ obj-$(CONFIG_SGI_SN) += sn/
> obj-y+= firmware/
> obj-$(CONFIG_CRYPTO) += crypto/
> obj-$(CONFIG_SUPERH) += sh/
> +obj-$(CONFIG_ARCH_SHMOBILE_MULTI)+= sh/
> obj-$(CONFIG_ARCH_SHMOBILE_LEGACY) += sh/
> ifndef CONFIG_ARCH_USES_GETTIMEOFFSET
> obj-y+= clocksource/
> diff --git a/drivers/sh/Makefile b/drivers/sh/Makefile
> index fc67f56..86604a5 100644
> --- a/drivers/sh/Makefile
> +++ b/drivers/sh/Makefile
> @@ -3,7 +3,10 @@
> #
> obj-y:= intc/
Is intc needed as well ?
>
> +ifeq ($(CONFIG_COMMON_CLK),n)
> obj-$(CONFIG_HAVE_CLK) += clk/
> +endif
> +
> obj-$(CONFIG_MAPLE) += maple/
> obj-$(CONFIG_SUPERHYWAY) += superhyway/
--
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/
Re: [PATCH] iio: tsl2563: Initialize channels
On 12/01/14 21:08, Ivaylo Dimitrov wrote: On 12.01.2014 22:55, Peter Meerwald wrote: I think the fix should rather be if (chan->channel2 == IIO_MOD_LIGHT_BOTH) chip->calib0 = calib_from_sysfs(val); else if (chan->channel2 == IIO_MOD_LIGHT_IR) chip->calib1 = calib_from_sysfs(val); else return -EINVAL; since only the INTENSITY channels have a CALIBSCALE info the light channel incorrectly sets .indexed = 1 and .channel = 0 which should be unnecessary since there is only one IIO_LIGHT channel regards, p. I thought so when I was preparing the patch, but unfortunately couldn't find any documentation for iio subsystem structs and defines, besides what is in the header files (and it is not very descriptive), so I took the easy route. However, I'll send a new patch with the above (and a little more) changes. Leave the indexed bit alone. Whilst unnecessary it is fine within the ABI and changing it would be a userspace ABI change. Otherwise, as described by Peter will be fine. Jonathan Thanks, Ivo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/4] misc: xgene: Add support for APM X-Gene SoC Queue Manager/Traffic Manager
On Friday 10 January 2014, Ravi Patel wrote: > Do you want any further clarification or document related to QMTM. > We want to make sure everyone is on same page, understand and > conclude upon that QMTM is a device and and not a bus or a dma > engine. I have a much better understanding now, but there are still a few open questions from my side. Let me try to explain in my own words what I think is the relevant information (part of this is still guessing). It took me a while to figure out what it does from your description, and then some more time to see what it's actually good for (as opposed to adding complexity). Please confirm or correct the individual statements in this description: The QMTM serves as a relay for short (a few bytes) messages between the OS software and various slave hardware blocks on the SoC. The messages are typically but not always DMA descriptors used by the slave device used for starting bus master transactions by the slave, or for notifying sofware about the competion of a DMA transaction. The message format is specific to the slave device and the QMTM only understands the common header of the message. OS software sees the messages in cache-coherent memory and does not require any cache flushes or MMIO access for inbound messages and only a single posted MMIO write for outbound messages. The queues are likely designed to be per-thread and don't require software-side locking. For outbound messages, the QMTM is the bus master of a device-to-device DMA transaction that gets started once a message is queued and the device has signaled that it is ready for receiving it. The QMTM needs to know the bus address of the device as well as a slave ID for the signal pin. For inbound messages, the QMTM slave initiates a busmaster transaction and needs to know the bus address of its QMTM port, while the QMTM needs to know only the slave ID that is associated with the queue. In addition to those hardware properties, the QMTM driver needs to set up a memory buffer for the message queue as seen by the CPU, and needs tell the QMTM the location as well as some other properties such as the message length. For inbound messages, the QMTM serves a similar purpose as an MSI controller, ensuring that inbound DMA data has arrived in RAM before an interrupt is delivered to the CPU and thereby avoiding the need for an expensive MMIO read to serialize the DMA. The resources managed by the QMTM are both SoC-global (e.g. bus bandwidth) and slave specific (e.g. ethernet bandwith or buffer space). Global resource management is performed to prevent one slave device from monopolizing the system or preventing other slaves from making forward progress. Examples for local resource management (I had to think about this a long time, but probably some of these are wrong) would be * balancing between multiple non-busmaster devices connected to a dma-engine * distributing incoming ethernet data to the available CPUs based on a flow classifier in the MAC, e.g. by IOV MAC address, VLAN tag or even individual TCP connection depending on the NIC's capabilities. * 802.1p flow control for incoming ethernet data based on the amount of data queued up between the MAC and the driver * interrupt mitigation for both inbound data and outbound completion, by delaying the IRQ to the OS until multiple messages have arrived or a queue specific amount of time has passed. * controlling the amount of outbound buffer space per flow to minimize buffer-bloat between an ethernet driver and the NIC hardware. * reordering data from outbound flows based on priority. This is basically my current interpretation, I hope I got at least some of it right this time ;-) Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ASoC: wm8804: Allow control of master clock divider in PLL generation
Signed-off-by: Daniel Matuschek
After some discussions of the patch last week, here is a new version.
Simply reducing the post_table did not work, as for some frequencies
both settings (MCLKDIV=0 and MCLKDIV=1) are needed (e.g. 96 and 192kHz)
WM8804 can run with PLL frequencies of 256xfs and 128xfs for
most sample rates. At 192kHz only 128xfs is supported. The
existing driver selects 128xfs automatically for some lower
samples rates. By using an additional mclk_div divider, is
is now possible to control the behaviour. This allows using
256xfs PLL frequency on all sample rates up to 96kHz. It
should allow lower jitter and better signal quality. The
behavior has to be controlled by the sound card driver,
because some sample frequency share the same setting. e.g.
192kHz and 96kHz use 24.576MHz master clock. The only
difference is the MCLK divider.
---
sound/soc/codecs/wm8804.c | 17 ++---
sound/soc/codecs/wm8804.h |4
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/sound/soc/codecs/wm8804.c b/sound/soc/codecs/wm8804.c
index 1704b1e..4619bf8 100644
--- a/sound/soc/codecs/wm8804.c
+++ b/sound/soc/codecs/wm8804.c
@@ -63,6 +63,7 @@ struct wm8804_priv {
struct regmap *regmap;
struct regulator_bulk_data supplies[WM8804_NUM_SUPPLIES];
struct notifier_block disable_nb[WM8804_NUM_SUPPLIES];
+ int mclk_div;
};
static int txsrc_get(struct snd_kcontrol *kcontrol,
@@ -318,7 +319,7 @@ static struct {
#define FIXED_PLL_SIZE ((1ULL << 22) * 10)
static int pll_factors(struct pll_div *pll_div, unsigned int target,
- unsigned int source)
+ unsigned int source, unsigned int mclk_div)
{
u64 Kpart;
unsigned long int K, Ndiv, Nmod, tmp;
@@ -330,7 +331,8 @@ static int pll_factors(struct pll_div *pll_div, unsigned
int target,
*/
for (i = 0; i < ARRAY_SIZE(post_table); i++) {
tmp = target * post_table[i].div;
- if (tmp >= 9000 && tmp <= 1) {
+ if ((tmp >= 9000 && tmp <= 1) &&
+ (mclk_div == post_table[i].mclkdiv)) {
pll_div->freqmode = post_table[i].freqmode;
pll_div->mclkdiv = post_table[i].mclkdiv;
target *= post_table[i].div;
@@ -387,8 +389,12 @@ static int wm8804_set_pll(struct snd_soc_dai *dai, int
pll_id,
} else {
int ret;
struct pll_div pll_div;
+ struct wm8804_priv *wm8804;
- ret = pll_factors(_div, freq_out, freq_in);
+ wm8804 = snd_soc_codec_get_drvdata(codec);
+
+ ret = pll_factors(_div, freq_out, freq_in,
+ wm8804->mclk_div);
if (ret)
return ret;
@@ -452,6 +458,7 @@ static int wm8804_set_clkdiv(struct snd_soc_dai *dai,
int div_id, int div)
{
struct snd_soc_codec *codec;
+ struct wm8804_priv *wm8804;
codec = dai->codec;
switch (div_id) {
@@ -459,6 +466,10 @@ static int wm8804_set_clkdiv(struct snd_soc_dai *dai,
snd_soc_update_bits(codec, WM8804_PLL5, 0x30,
(div & 0x3) << 4);
break;
+ case WM8804_MCLK_DIV:
+ wm8804 = snd_soc_codec_get_drvdata(codec);
+ wm8804->mclk_div = div;
+ break;
default:
dev_err(dai->dev, "Unknown clock divider: %d\n", div_id);
return -EINVAL;
diff --git a/sound/soc/codecs/wm8804.h b/sound/soc/codecs/wm8804.h
index 8ec14f5..e72d4f4 100644
--- a/sound/soc/codecs/wm8804.h
+++ b/sound/soc/codecs/wm8804.h
@@ -57,5 +57,9 @@
#define WM8804_CLKOUT_SRC_OSCCLK 4
#define WM8804_CLKOUT_DIV 1
+#define WM8804_MCLK_DIV2
+
+#define WM8804_MCLKDIV_256FS 0
+#define WM8804_MCLKDIV_128FS 1
#endif /* _WM8804_H */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iio: tsl2563: Initialize channels
On 12.01.2014 22:55, Peter Meerwald wrote: I think the fix should rather be if (chan->channel2 == IIO_MOD_LIGHT_BOTH) chip->calib0 = calib_from_sysfs(val); else if (chan->channel2 == IIO_MOD_LIGHT_IR) chip->calib1 = calib_from_sysfs(val); else return -EINVAL; since only the INTENSITY channels have a CALIBSCALE info the light channel incorrectly sets .indexed = 1 and .channel = 0 which should be unnecessary since there is only one IIO_LIGHT channel regards, p. I thought so when I was preparing the patch, but unfortunately couldn't find any documentation for iio subsystem structs and defines, besides what is in the header files (and it is not very descriptive), so I took the easy route. However, I'll send a new patch with the above (and a little more) changes. Thanks, Ivo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: check && lockdep_no_validate (Was: lockdep: Introduce wait-type checks)
On Thu, Jan 09, 2014 at 06:54:48PM +0100, Oleg Nesterov wrote:
> But this connects to lockdep_no_validate. Not sure I understand what
> this class should actually do, but consider this code:
>
> DEFINE_MUTEX(m1);
> DEFINE_MUTEX(m2);
> DEFINE_MUTEX(mx);
>
> void lockdep_should_complain(void)
> {
> lockdep_set_novalidate_class();
>
> // m1 -> mx -> m2
> mutex_lock();
> mutex_lock();
> mutex_lock();
> mutex_unlock();
> mutex_unlock();
> mutex_unlock();
>
>
> // m2 -> m1 ; should trigger the warning
> mutex_lock();
> mutex_lock();
> mutex_unlock();
> mutex_unlock();
> }
>
> lockdep doesn't not detect the trivial possible deadlock.
>
> The patch below seems to work but most probably it is not right, and
> I forgot everything (not too much) I knew about lockdep internals.
>
> Oleg.
>
> --- a/kernel/locking/lockdep.c
> +++ b/kernel/locking/lockdep.c
> @@ -1939,7 +1939,8 @@ check_prevs_add(struct task_struct *curr, struct
> held_lock *next)
>* Only non-recursive-read entries get new dependencies
>* added:
>*/
> - if (hlock->read != 2) {
> + if (hlock->read != 2 &&
> + hlock->instance->key != &__lockdep_no_validate__) {
> if (!check_prev_add(curr, hlock, next,
> distance, trylock_loop))
> return 0;
>
Hmm, you are quite right indeed; although I would write it like:
if (hlock->read != 2 && hlock->check == 2)
because the __lockdep_no_validate__ thing forces the ->check value to 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: [PATCH] iio: tsl2563: Initialize channels
Hello,
> Correctly initialize device channels, otherwise writing the calibration
> values to sysfs nodes does not work
I think the fix should rather be
if (chan->channel2 == IIO_MOD_LIGHT_BOTH)
chip->calib0 = calib_from_sysfs(val);
else if (chan->channel2 == IIO_MOD_LIGHT_IR)
chip->calib1 = calib_from_sysfs(val);
else
return -EINVAL;
since only the INTENSITY channels have a CALIBSCALE info
the light channel incorrectly sets .indexed = 1 and .channel = 0 which
should be unnecessary since there is only one IIO_LIGHT channel
regards, p.
> ---
> drivers/iio/light/tsl2563.c |6 --
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/light/tsl2563.c b/drivers/iio/light/tsl2563.c
> index 5e5d9de..a663ea2 100644
> --- a/drivers/iio/light/tsl2563.c
> +++ b/drivers/iio/light/tsl2563.c
> @@ -460,7 +460,7 @@ static int tsl2563_write_raw(struct iio_dev *indio_dev,
> {
> struct tsl2563_chip *chip = iio_priv(indio_dev);
>
> - if (chan->channel == IIO_MOD_LIGHT_BOTH)
> + if (chan->channel == 0)
> chip->calib0 = calib_from_sysfs(val);
> else
> chip->calib1 = calib_from_sysfs(val);
> @@ -543,11 +543,12 @@ static const struct iio_event_spec tsl2563_events[] = {
> static const struct iio_chan_spec tsl2563_channels[] = {
> {
> .type = IIO_LIGHT,
> + .channel = 0,
> .indexed = 1,
> .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED),
> - .channel = 0,
> }, {
> .type = IIO_INTENSITY,
> + .channel = 0,
> .modified = 1,
> .channel2 = IIO_MOD_LIGHT_BOTH,
> .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> @@ -556,6 +557,7 @@ static const struct iio_chan_spec tsl2563_channels[] = {
> .num_event_specs = ARRAY_SIZE(tsl2563_events),
> }, {
> .type = IIO_INTENSITY,
> + .channel = 1,
> .modified = 1,
> .channel2 = IIO_MOD_LIGHT_IR,
> .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
>
--
Peter Meerwald
+43-664-218 (mobile)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] netfilter: nf_conntrack: fix RCU race in nf_conntrack_find_get (v3)
On Sun, 2014-01-12 at 21:50 +0400, Andrey Vagin wrote: > Lets look at destroy_conntrack: > > hlist_nulls_del_rcu(>tuplehash[IP_CT_DIR_ORIGINAL].hnnode); > ... > nf_conntrack_free(ct) > kmem_cache_free(net->ct.nf_conntrack_cachep, ct); > > net->ct.nf_conntrack_cachep is created with SLAB_DESTROY_BY_RCU. > > The hash is protected by rcu, so readers look up conntracks without > locks. > A conntrack is removed from the hash, but in this moment a few readers > still can use the conntrack. Then this conntrack is released and another > thread creates conntrack with the same address and the equal tuple. > After this a reader starts to validate the conntrack: > * It's not dying, because a new conntrack was created > * nf_ct_tuple_equal() returns true. ... > v2: move nf_ct_is_confirmed into the unlikely() annotation > v3: Eric suggested to fix refcnt, so that it becomes zero before adding > in a hash, but we can't find a way how to do that. Another way is to > interpret the confirm bit as part of a search key and check it in > nf_conntrack_find() too. > > Cc: Eric Dumazet > Cc: Florian Westphal > Cc: Pablo Neira Ayuso > Cc: Patrick McHardy > Cc: Jozsef Kadlecsik > Cc: "David S. Miller" > Cc: Cyrill Gorcunov > Signed-off-by: Andrey Vagin > --- Acked-by: Eric Dumazet Thanks Andrey ! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/1] lockdep: Kill held_lock->check and "int check" arg of __lock_acquire()
On Sun, Jan 12, 2014 at 06:45:32PM +0100, Oleg Nesterov wrote: > But could someone please explain me what should lockdep_no_validate > actually do? 1704f47b5 "lockdep: Add novalidate class for dev->mutex > conversion" doesn't tell which kind of warnings it tries to avoid, > and it looks buggy (see another email from me). It should disable lock-order checks for the locks that set that as class. So we can still do the simple checks like detect if we free memory with a held lock in and make sure we do not return to userspace with a held lock; but the class should not participate in the lock graph. I'll have a look at your earlier email again; I did note the question but it slipped my mind :/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] iio: tsl2563: Initialize channels
From: Ivaylo Dimitrov
Correctly initialize device channels, otherwise writing the calibration
values to sysfs nodes does not work
Signed-off-by: Ivaylo Dimitrov
---
drivers/iio/light/tsl2563.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/light/tsl2563.c b/drivers/iio/light/tsl2563.c
index 5e5d9de..a663ea2 100644
--- a/drivers/iio/light/tsl2563.c
+++ b/drivers/iio/light/tsl2563.c
@@ -460,7 +460,7 @@ static int tsl2563_write_raw(struct iio_dev *indio_dev,
{
struct tsl2563_chip *chip = iio_priv(indio_dev);
- if (chan->channel == IIO_MOD_LIGHT_BOTH)
+ if (chan->channel == 0)
chip->calib0 = calib_from_sysfs(val);
else
chip->calib1 = calib_from_sysfs(val);
@@ -543,11 +543,12 @@ static const struct iio_event_spec tsl2563_events[] = {
static const struct iio_chan_spec tsl2563_channels[] = {
{
.type = IIO_LIGHT,
+ .channel = 0,
.indexed = 1,
.info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED),
- .channel = 0,
}, {
.type = IIO_INTENSITY,
+ .channel = 0,
.modified = 1,
.channel2 = IIO_MOD_LIGHT_BOTH,
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
@@ -556,6 +557,7 @@ static const struct iio_chan_spec tsl2563_channels[] = {
.num_event_specs = ARRAY_SIZE(tsl2563_events),
}, {
.type = IIO_INTENSITY,
+ .channel = 1,
.modified = 1,
.channel2 = IIO_MOD_LIGHT_IR,
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
--
1.5.6.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/
