3.13-rc7 USB networking oops
I hit this on 3.13-rc7 while transferring data over an ASIX88179 USB 3 to gigabit ethernet adapter, transferring data at only 4MB/s. What other debug options apart from SG debug would be useful here? Thanks, Daniel On 30 December 2013 23:26, Daniel J Blueman wrote: > When rsyncing data from a USB3 disk over a USB3-ethernet adapter to > local server on 3.13-rc5 [1], I ran into fatal page-not-readable fault > [2]. > > Full dmesg (before the disk was plugged in) is at > http://quora.org/2013/dmesg.txt > > I can test patches on the weekend if needed. > > Thanks and Happy New Year! > Daniel > > --- [1] > > http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13-rc5-trusty/linux-image-3.13.0-031300rc5-generic_3.13.0-031300rc5.201312221635_amd64.deb > > --- [2] (apologies for any typos due to OCR) > > BUG: unable to handle kernel NULL pointer dereference at (null) > IP: [] sg_next+0x2/0x20 > PGD 2354c5067 PUD 1b25b1067 PMD 0 > Oops: [#1] SMP > Modules linked in: usb_storage dm_crypt autofs4 snd_hda_codec_hdmi > parport_pc ppdev tusb bluetooth snd_page_alloc ax88179_178e usbnet > snd_seq_midi crctlOdif_pcImul vldepdev snd_sedird _ich apple_gmux > apple_bl mac_hid nIs_iS08859_1 lp parport btrfs xor raid6_pq libcrc32c > hid_generic > CPU: 0 PID: 6395 Comm: pool Not tainted 3.13.0-031300rc5-generic #201312221635 > Hardware name: Apple Inc. MacBookFro10,1/Mac-C3EC7CD22292981F, BIOS > M8P101.632.00EE.I > task: 880178ec6000 ti: 880061914000 task.ti: 880061914000 > RIP: 0010:[] k813979f2A sg_next+0x2/0x20 > RSP: 0018:880061915740 EFLAGS: 00010046 > RAX: RBX: ff1f880036255000 RCX: 0003 > RDX: 0003 RSI: 880036255000 RDI: > R6P: 880061915798 R08: 0201 R09: 3578 > R10: 8163fa52 R11: 02c0 R12: 88025e5dfc00 > R13: 8802634f2098 R14: 0001 R15: 81c26c40 > FS: 7fc7c4b37700() OS:fff188026f20() knIGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: CR3: 0001e8b12000 CR4: 001407f0 > Stack: > 8156d8fe 88010003 88011c144e40 > 0003245ded00 8801245ded00 880036255000 88025e5dfc00 > 0020 0200 1fff88007a3e59fc 8800619157d8 > Call Trace: > [] ? usb_hcd_map_urb_for_dma+0x30e/0x4b0 > [] usb_hcd_submit_urb+0x125/0x1b0 > [] usb_submit_urb.part.7+0x15f/0x430 > [] ? __pm_runtime_resume+0x69/0x90 > [1 usb_submit_urb+0x35/0x80 > [] usbnet_stert_xmit+0x245/0x640 [usbnet] > [] dev_hard_start_xmit+0x54d/0x5f0 > [] ? dev_hard_start_xmit+0x54d/0x5f0 > [] sch_direct_xmit+0x100/0x1d0 > [] dev_queue_xmit+0x172/0x4b0 > [] ip_finish_output+0x224/0x3f0 > [] ip_output+0x58/0x90 > [] 1p_local_out+0x29/0x30 > [] ip_queue_xmit+0x140/0x3d0 > [] tcp_transmit_skb+0x3ba/0x620 > [] tcp_write_xmit+0xlic/0x470 > [] __tcp_push_pend1ng_frames+0x32/0xd0 > [] tcp_sendmsg+0xl2f/0xd70 > [] inet_sendmsg+0x61/0xb0 > [] ? __remove_hrtimer+0x60/0xc0 > [] do_sock_write.isra.16+0xc2/0xe0 > [] sock_aio_write+0x48/0x60 > [] ? hrtimer_cance1+0x22/0x30 > [] do_sync_readv_writev+0x48/0x80 > [] do_readv_writev+0xc8/0x2a0 > [] ? vtime_account_user+0x5d/0x70 > [] vfs_writev+0x37/0x50 > [] SyS_writev+0x52/0xc0 > [] tracesys+0xe1/0xe6 > Code: 5c 41 5d 41 5e 41 5f 5d c3 55 48 c7 c2 00 7e 39 81 be 80 00 00 > 00 4S 89 eS e8 6b > RIP [] sg_next+0x2/0x20 > RSP > CR2: > Kernel panic - not syncing: Fatal exception in interrupt > drm_kms_helper: panic occurred, switching back to text console -- Daniel J Blueman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mm/zswap: Check all pool pages instead of one pool pages
zswap can support multiple swapfiles. So we need to check
all zbud pool pages in zswap.
Signed-off-by: Cai Liu
---
mm/zswap.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/mm/zswap.c b/mm/zswap.c
index d93afa6..2438344 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -291,7 +291,6 @@ static void zswap_free_entry(struct zswap_tree *tree,
zbud_free(tree->pool, entry->handle);
zswap_entry_cache_free(entry);
atomic_dec(_stored_pages);
- zswap_pool_pages = zbud_get_pool_size(tree->pool);
}
/* caller must hold the tree lock */
@@ -405,10 +404,24 @@ cleanup:
/*
* helpers
**/
+static u64 get_zswap_pool_pages(void)
+{
+ int i;
+ u64 pool_pages = 0;
+
+ for (i = 0; i < MAX_SWAPFILES; i++) {
+ if (zswap_trees[i])
+ pool_pages += zbud_get_pool_size(zswap_trees[i]->pool);
+ }
+ zswap_pool_pages = pool_pages;
+
+ return pool_pages;
+}
+
static bool zswap_is_full(void)
{
return (totalram_pages * zswap_max_pool_percent / 100 <
- zswap_pool_pages);
+ get_zswap_pool_pages());
}
/*
@@ -716,7 +729,6 @@ static int zswap_frontswap_store(unsigned type, pgoff_t
offset,
/* update stats */
atomic_inc(_stored_pages);
- zswap_pool_pages = zbud_get_pool_size(tree->pool);
return 0;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 3/4] futex: Document ordering guarantees
On Thu, Jan 02, 2014 at 07:05:19AM -0800, Davidlohr Bueso wrote: > From: Thomas Gleixner > > That's essential, if you want to hack on futexes. > > Cc: Ingo Molnar > Cc: Darren Hart > Acked-by: Peter Zijlstra > Cc: Thomas Gleixner > Cc: 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 Reviewed-by: Paul E. McKenney > --- > 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/
Re: [PATCH v5 2/4] futex: Larger hash table
On Thu, Jan 02, 2014 at 07:05:18AM -0800, Davidlohr Bueso wrote:
> 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
> Cc: 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
Reviewed-by: Paul E. McKenney
> ---
> 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[1< +static unsigned long __read_mostly futex_hashsize;
> +
> +static struct futex_hash_bucket *futex_queues;
>
> /*
> * We hash on the keys returned from get_futex_key (see below).
> @@ -161,7 +162,7 @@ static struct futex_hash_bucket *hash_futex(union
> futex_key *key)
> u32 hash = jhash2((u32*)>both.word,
> (sizeof(key->both.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 =
Re: [PATCH v5 1/4] futex: Misc cleanups
On Thu, Jan 02, 2014 at 07:05:17AM -0800, Davidlohr Bueso wrote:
> 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
> 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
> Signed-off-by: Jason Low
> Signed-off-by: Davidlohr Bueso
Reviewed-by: Paul E. McKenney
> ---
> 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();
>
Re: [PATCH 0/2] rcu_dereference_check_fdtable fix/cleanups
On Fri, Jan 10, 2014 at 04:34:59PM +0100, Oleg Nesterov wrote:
> On 01/08, Paul E. McKenney wrote:
> >
> > On Wed, Jan 08, 2014 at 04:19:18PM +0100, Oleg Nesterov wrote:
> > > On 01/08, Paul E. McKenney wrote:
> > > >
> > > > Another approach would be to add an argument to files_fdtable()
> > > > that is zero normally and one for "we know we don't need RCU
> > > > protection." Then rcu_dereference_check() could be something
> > > > like the following:
> > > >
> > > > #define files_fdtable(files, c) \
> > > > (rcu_dereference_check_fdtable((files), (files)->fdt)
> > > > || c)
> > > >
> > > > Would that work?
> > >
> > > Yes, I considered this optiion, but this needs much more uglifications^W
> > > changes.
> > >
> > > Either we need to change all users of files_fdtable(), or we need
> > > something
> > > like
> >
> > There are only about 20 uses of files_fdtable() in 3.12, with almost all
> > of them in fs/file.c. So is changing all the users really all that
> > problematic?
>
> But only one user, close_files(), needs files_fdtable(files, true). Why
> complicate the patch and the code? I think it would be better to simply
> change close_files() to use rcu_dereference_raw().
>
> And note that rcu_dereference_check_fdtable() needs the new argument too.
>
> And we should also take care of fcheck_files(),
>
> > > static inline struct file *__fcheck_files(struct files_struct *files,
> > > unsigned int fd)
> > > {
> > > struct fdtable *fdt = rcu_dereference_raw(files->fdt);
> > > struct file *file = NULL;
> > >
> > > if (fd < fdt->max_fds)
> > > file = rcu_dereference_raw(fdt->fd[fd]);
> > >
> > > return file;
> > > }
> > >
> > > static inline struct file *fcheck_files(struct files_struct *files,
> > > unsigned int fd)
> > > {
> > > rcu_lockdep_assert(rcu_read_lock_held() ||
> > > lockdep_is_held(files->file_lock),
> > > "message");
> > > return __fcheck_files(files, fd);
> > > }
>
> doesn't this look much simpler than adding the "bool unshared" argument
> and changing the callers?
I might be being too paranoid, but my concern with using rcu_lock_acquire()
and rcu_lock_release() is the possibility of code needing rcu_read_lock()
appearing somewhere in the function-call graph between rcu_lock_acquire()
and rcu_lock_release(). In that case, lockdep would be happy, but the
required RCU protection would not be present.
Sort of like my experience with people using RCU from idle.
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: [BUG] at include/linux/page-flags.h:415 (PageTransHuge)
On Fri, 10 Jan 2014 19:23:26 +0100 Daniel Borkmann
wrote:
> This is being reliably triggered for each mmaped() packet(7)
> socket from user space, basically during unmapping resp.
> closing the TX socket.
>
> I believe due to some change in transparent hugepages code ?
>
> When I disable transparent hugepages, everything works fine,
> no BUG triggered.
>
> I'd be happy to test patches.
Did the inclusion of c424be1cbbf852e46acc8 ("mm: munlock: fix a bug
where THP tail page is encountered") in current mainline fix this?
> With using default kernel config:
>
> [ 63.887947] kernel BUG at include/linux/page-flags.h:415!
> [ 63.889296] invalid opcode: [#4] SMP
> [ 63.890637] Modules linked in: fuse ebtable_nat xt_CHECKSUM bridge stp llc
> rfcomm bnep nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE
> ip6table_nat nf_nat_ipv6 ip6table_mangle ip6t_REJECT nf_conntrack_ipv6
> nf_defrag_ipv6 iptable_nat nf_nat_ipv4 nf_nat iptable_mangle
> nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_filter
> ebtables ip6table_filter ip6_tables snd_hda_codec_hdmi snd_hda_codec_realtek
> snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm iwlwifi
> snd_page_alloc btusb snd_timer bluetooth cfg80211 wmi joydev thinkpad_acpi
> snd iTCO_wdt iTCO_vendor_support pcspkr e1000e tpm_tis tpm uvcvideo i2c_i801
> soundcore sdhci_pci sdhci lpc_ich rfkill videobuf2_vmalloc videobuf2_memops
> videobuf2_core mmc_core mfd_core ptp videodev pps_core media uinput i915
> [ 63.895055] i2c_algo_bit drm_kms_helper drm i2c_core video
> [ 63.896529] CPU: 2 PID: 1598 Comm: trafgen Tainted: G D
> 3.13.0-rc6+ #12
> [ 63.898010] Hardware name: LENOVO 2429BP3/2429BP3, BIOS G4ET37WW (1.12 )
> 05/29/2012
> [ 63.899494] task: 8801eca6c1a0 ti: 88020e694000 task.ti:
> 88020e694000
> [ 63.900988] RIP: 0010:[] []
> PageTransHuge.part.11+0x4/0x6
> [ 63.902498] RSP: 0018:88020e695df8 EFLAGS: 00010282
> [ 63.903996] RAX: 005fffc08004 RBX: 88020254cac8 RCX:
> 078ed340
> [ 63.905492] RDX: 8116b3c6 RSI: 0001 RDI:
> 88020cf80640
> [ 63.906992] RBP: 88020e695df8 R08: R09:
>
> [ 63.908485] R10: 8801eca6c1a0 R11: 10fb R12:
> ea00078ed340
> [ 63.909970] R13: 88020e695f48 R14: 7f274a5f3000 R15:
> 7f274a5f4000
> [ 63.911456] FS: 7f274e5f3740() GS:88021e28()
> knlGS:
> [ 63.912946] CS: 0010 DS: ES: CR0: 80050033
> [ 63.914430] CR2: 003724a35a90 CR3: 0001eabb6000 CR4:
> 001407e0
> [ 63.915919] Stack:
> [ 63.917404] 88020e695ee0 8116fa7a 000ed78ec480
> 7f274e5f2fff
> [ 63.918913] 0001 7f274e5f3000 810c864b
> 8801fb16aca8
> [ 63.920430] 88020e695e58
> 0046
> [ 63.921938] Call Trace:
> [ 63.923451] [] munlock_vma_pages_range+0x2ea/0x2f0
> [ 63.924978] [] ? trace_hardirqs_off+0xd/0x10
> [ 63.926454] [] ? vma_merge+0xc2/0x330
> [ 63.927870] [] mlock_fixup+0xfc/0x190
> [ 63.929288] [] do_mlockall+0x87/0xc0
> [ 63.930702] [] sys_munlockall+0x2f/0x50
> [ 63.932117] [] system_call_fastpath+0x16/0x1b
> [ 63.933531] Code: c1 e0 06 48 29 d8 eb 02 31 c0 5b 41 5c 5d c3 55 48 89 e5
> 0f 0b 55 48 89 e5 0f 0b 55 48 89 e5 0f 0b 55 48 89 e5 0f 0b 55 48 89 e5 <0f>
> 0b 55 48 89 e5 0f 0b 55 48 89 e5 0f 0b 55 48 8b 07 31 c9 48
> [ 63.935103] RIP [] PageTransHuge.part.11+0x4/0x6
> [ 63.936580] RSP
> [ 63.938021] ---[ end trace 67b7aa3fba09186d ]---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] Staging: comedi: Checkpatch cleanups in ni_mio_common.c
Oops, left out some of my cover letter. Here is the amended patchset cover letter. On Fri, Jan 10, 2014 at 10:07 PM, Chase Southwood wrote: > > This patch series fixes several warnings reported by checkpatch.pl in > ni_mio_common.c of the comedi driver. > > Among the issues fixed: > *Many unnecessary braces have been removed. > *Improper indentation has been corrected. > *Extra whitespace before semicolons has been removed. > *Extra whitespace after function pointer name has been removed. > > Several checkpatch warnings still remain (mainly 80 character+ line lengths), > but no new warnings have been introduced, and no functionality changes have > been made. > Chase Southwood (3): Staging: comedi: fix numerous brace coding style issues in ni_mio_common.c. Staging: comedi: fix indentation coding style issue in ni_mio_common.c. Staging: comedi: fix extra whitespace style issues in ni_mio_common.c. drivers/staging/comedi/drivers/ni_mio_common.c | 138 + 1 file changed, 50 insertions(+), 88 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 v2] clk: sirf: re-arch to make the codes support both prima2 and atlas6
2014/1/6 Barry Song <21cn...@gmail.com>: > From: Barry Song > > sirfprima2 and sirfatlas6 are two different SoCs in CSR SiRF series. for > prima2 and atlas6, there are many shared clocks but there are still > some different register layout and hardware clocks, then result in > different clock table. > > here we re-arch the driver to > 1. clk-common.c provides common clocks for prima2 and atlas6, > 2. clk-prima2.h describles registers of prima2 and clk-prima2.c provides > prima2 specific clocks and clock table. > 3. clk-atlas6.h describles registers of atlas6 and clk-atlas6.c provides > atlas6 specific clocks and clock table. > 4. clk.h and clk.c expose external interfaces and provide uniform entry > for both prima2 and atlas6. > > so both prima2 and atlas6 will get support by drivers/clk/sirf. > > Signed-off-by: Barry Song > Signed-off-by: Rongjun Ying > --- > -v2: > rebase to 3.13-rc; > use CLK_OF_DECLARE and make init function static Hi Mike, any feedback for this? i sent v1 some time ago and didn't get your answer. and here it has been v2. -barry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/7] ipc,msg: document barriers
On Fri, 2014-01-10 at 10:48 -0800, Davidlohr Bueso wrote:
> Both expunge_all() and pipeline_send() rely on both a nil msg value and a
> full barrier to guarantee the correct ordering when waking up a task. While
> its counter part at the receiving end is well documented for the lockless
> recv algorithm, we still need to document these specific smp_mb() calls.
>
> Signed-off-by: Davidlohr Bueso
> ---
> ipc/msg.c | 19 +--
> 1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/ipc/msg.c b/ipc/msg.c
> index 4377f4a..8c1cc76 100644
> --- a/ipc/msg.c
> +++ b/ipc/msg.c
> @@ -253,8 +253,14 @@ static void expunge_all(struct msg_queue *msq, int res)
> struct msg_receiver *msr, *t;
>
> list_for_each_entry_safe(msr, t, >q_receivers, r_list) {
> - msr->r_msg = NULL;
> + msr->r_msg = NULL; /* initialize expunge ordering */
> wake_up_process(msr->r_tsk);
> + /*
> + * Ensure that the wakeup is visible before setting r_msg as
> + * the receiving end depends on it: either spinning on a nil,
> + * or dealing with -EAGAIN cases. See lockless reveice part 1
^^^
lysdexic fingers
> + * and 2 in do_msgrcv().
> + */
> smp_mb();
> msr->r_msg = ERR_PTR(res);
> }
> @@ -638,15 +644,22 @@ static inline int pipelined_send(struct msg_queue *msq,
> struct msg_msg *msg)
>
> list_del(>r_list);
> if (msr->r_maxsize < msg->m_ts) {
> + /* initialize pipelined send ordering */
> msr->r_msg = NULL;
> wake_up_process(msr->r_tsk);
> - smp_mb();
> + smp_mb(); /* see barrier comment below */
> msr->r_msg = ERR_PTR(-E2BIG);
> } else {
> msr->r_msg = NULL;
> msq->q_lrpid = task_pid_vnr(msr->r_tsk);
> msq->q_rtime = get_seconds();
> wake_up_process(msr->r_tsk);
> + /*
> + * Ensure that the wakeup is visible before
> + * setting r_msg, as the receiving end depends
> + * on it. See lockless reveice part 1 and 2 in
^^^ ditto
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Question] Should we make the primary interrupt handler configurable for regmap_add_irq_chip()?
Hi, Mark: Sorry to trouble you; I have a question about the regmap_add_irq_chip(): at present, we use the default primary interrupt handler to handle the parent interrupt from a mfd device; I met a scenario: As soon as the interrupt is triggered, a wakelock is needed to be held until the threaded handler finishes, I think we may hold it in the primary interrupt handler, but now it's NULL by default; so could we make the the primary interrupt handler configurable? for example, add a parameter to regmap_add_irq_chip(), then the user can choose to use current solution or his/her own handler; what do you think? could you please share your opinion? thanks very much; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] Staging: comedi: Checkpatch cleanups in ni_mio_common.c
This patch series fixes several warnings reported by checkpatch.pl in ni_mio_common.c of the comedi driver. Among the issues fixed: *Many unnecessary braces have been removed. *Improper indentation has been corrected. *Extra whitespace before semicolons has been removed. *Extra whitespace after function pointer name has been removed. Several checkpatch warnings still remain (mainly 80 character+ line lengths), but no new warnings have been introduced, and no functionality changes have been made. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] Staging: comedi: fix numerous brace coding style issues in ni_mio_common.c.
This patch for ni_mio_common.c removes many unneccesary braces to fix
checkpatch.pl warnings.
Signed-off-by: Chase Southwood
---
drivers/staging/comedi/drivers/ni_mio_common.c | 124 +
1 file changed, 43 insertions(+), 81 deletions(-)
diff --git a/drivers/staging/comedi/drivers/ni_mio_common.c
b/drivers/staging/comedi/drivers/ni_mio_common.c
index eb9f517..116174a 100644
--- a/drivers/staging/comedi/drivers/ni_mio_common.c
+++ b/drivers/staging/comedi/drivers/ni_mio_common.c
@@ -451,11 +451,10 @@ static inline void ni_set_gpct_dma_channel(struct
comedi_device *dev,
{
unsigned bitfield;
- if (mite_channel >= 0) {
+ if (mite_channel >= 0)
bitfield = GPCT_DMA_Select_Bits(gpct_index, mite_channel);
- } else {
+ else
bitfield = 0;
- }
ni_set_bitfield(dev, G0_G1_Select, GPCT_DMA_Select_Mask(gpct_index),
bitfield);
}
@@ -871,9 +870,8 @@ static void mite_handle_b_linkc(struct mite_struct *mite,
unsigned long flags;
spin_lock_irqsave(>mite_channel_lock, flags);
- if (devpriv->ao_mite_chan) {
+ if (devpriv->ao_mite_chan)
mite_sync_output_dma(devpriv->ao_mite_chan, s->async);
- }
spin_unlock_irqrestore(>mite_channel_lock, flags);
}
@@ -921,9 +919,8 @@ static void ni_handle_eos(struct comedi_device *dev, struct
comedi_subdevice *s)
#endif
}
/* handle special case of single scan using AI_End_On_End_Of_Scan */
- if ((devpriv->ai_cmd2 & AI_End_On_End_Of_Scan)) {
+ if ((devpriv->ai_cmd2 & AI_End_On_End_Of_Scan))
shutdown_ai_command(dev);
- }
}
static void shutdown_ai_command(struct comedi_device *dev)
@@ -987,19 +984,15 @@ static void ack_a_interrupt(struct comedi_device *dev,
unsigned short a_status)
struct ni_private *devpriv = dev->private;
unsigned short ack = 0;
- if (a_status & AI_SC_TC_St) {
+ if (a_status & AI_SC_TC_St)
ack |= AI_SC_TC_Interrupt_Ack;
- }
- if (a_status & AI_START1_St) {
+ if (a_status & AI_START1_St)
ack |= AI_START1_Interrupt_Ack;
- }
- if (a_status & AI_START_St) {
+ if (a_status & AI_START_St)
ack |= AI_START_Interrupt_Ack;
- }
- if (a_status & AI_STOP_St) {
+ if (a_status & AI_STOP_St)
/* not sure why we used to ack the START here also, instead of
doing it independently. Frank Hess 2007-07-06 */
ack |= AI_STOP_Interrupt_Ack /*| AI_START_Interrupt_Ack */ ;
- }
if (ack)
devpriv->stc_writew(dev, ack, Interrupt_A_Ack_Register);
}
@@ -1015,9 +1008,8 @@ static void handle_a_interrupt(struct comedi_device *dev,
unsigned short status,
return;
#ifdef PCIDMA
- if (ai_mite_status & CHSR_LINKC) {
+ if (ai_mite_status & CHSR_LINKC)
ni_sync_ai_dma(dev);
- }
if (ai_mite_status & ~(CHSR_INT | CHSR_LINKC | CHSR_DONE | CHSR_MRDY |
CHSR_DRDY | CHSR_DRQ1 | CHSR_DRQ0 | CHSR_ERROR |
@@ -1061,9 +1053,8 @@ static void handle_a_interrupt(struct comedi_device *dev,
unsigned short status,
return;
}
if (status & AI_SC_TC_St) {
- if (!devpriv->ai_continuous) {
+ if (!devpriv->ai_continuous)
shutdown_ai_command(dev);
- }
}
}
#ifndef PCIDMA
@@ -1082,9 +1073,8 @@ static void handle_a_interrupt(struct comedi_device *dev,
unsigned short status,
}
#endif /* !PCIDMA */
- if ((status & AI_STOP_St)) {
+ if ((status & AI_STOP_St))
ni_handle_eos(dev, s);
- }
ni_event(dev, s);
}
@@ -1094,27 +1084,20 @@ static void ack_b_interrupt(struct comedi_device *dev,
unsigned short b_status)
struct ni_private *devpriv = dev->private;
unsigned short ack = 0;
- if (b_status & AO_BC_TC_St) {
+ if (b_status & AO_BC_TC_St)
ack |= AO_BC_TC_Interrupt_Ack;
- }
- if (b_status & AO_Overrun_St) {
+ if (b_status & AO_Overrun_St)
ack |= AO_Error_Interrupt_Ack;
- }
- if (b_status & AO_START_St) {
+ if (b_status & AO_START_St)
ack |= AO_START_Interrupt_Ack;
- }
- if (b_status & AO_START1_St) {
+ if (b_status & AO_START1_St)
ack |= AO_START1_Interrupt_Ack;
- }
- if (b_status & AO_UC_TC_St) {
+ if (b_status & AO_UC_TC_St)
ack |= AO_UC_TC_Interrupt_Ack;
- }
- if (b_status & AO_UI2_TC_St) {
+ if (b_status & AO_UI2_TC_St)
ack |= AO_UI2_TC_Interrupt_Ack;
- }
- if (b_status & AO_UPDATE_St) {
+ if (b_status & AO_UPDATE_St)
ack |=
[PATCH 3/3] Staging: comedi: fix extra whitespace style issues in ni_mio_common.c.
This patch for ni_mio_common.c removes extra whitespace causing
checkpatch.pl warnings.
Signed-off-by: Chase Southwood
---
drivers/staging/comedi/drivers/ni_mio_common.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/comedi/drivers/ni_mio_common.c
b/drivers/staging/comedi/drivers/ni_mio_common.c
index 95f4e37..457b884 100644
--- a/drivers/staging/comedi/drivers/ni_mio_common.c
+++ b/drivers/staging/comedi/drivers/ni_mio_common.c
@@ -992,7 +992,7 @@ static void ack_a_interrupt(struct comedi_device *dev,
unsigned short a_status)
ack |= AI_START_Interrupt_Ack;
if (a_status & AI_STOP_St)
/* not sure why we used to ack the START here also, instead of
doing it independently. Frank Hess 2007-07-06 */
- ack |= AI_STOP_Interrupt_Ack /*| AI_START_Interrupt_Ack */ ;
+ ack |= AI_STOP_Interrupt_Ack /*| AI_START_Interrupt_Ack */;
if (ack)
devpriv->stc_writew(dev, ack, Interrupt_A_Ack_Register);
}
@@ -4262,7 +4262,7 @@ static int ni_E_init(struct comedi_device *dev)
s->n_chan = board->num_p0_dio_channels;
if (board->reg_type & ni_reg_m_series_mask) {
s->subdev_flags |=
- SDF_LSAMPL | SDF_CMD_WRITE /* | SDF_CMD_READ */ ;
+ SDF_LSAMPL | SDF_CMD_WRITE /* | SDF_CMD_READ */;
s->insn_bits = _m_series_dio_insn_bits;
s->insn_config = _m_series_dio_insn_config;
s->do_cmd = _cdio_cmd;
@@ -4731,7 +4731,7 @@ static int pack_ad8842(int addr, int val, int *bitstring);
struct caldac_struct {
int n_chans;
int n_bits;
- int (*packbits) (int, int, int *);
+ int (*packbits)(int, int, int *);
};
static struct caldac_struct caldacs[] = {
--
1.8.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] Staging: comedi: fix indentation coding style issue in ni_mio_common.c.
This patch for ni_mio_common.c fixes several indentation warnings from
checkpatch.pl.
Signed-off-by: Chase Southwood
---
drivers/staging/comedi/drivers/ni_mio_common.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/comedi/drivers/ni_mio_common.c
b/drivers/staging/comedi/drivers/ni_mio_common.c
index 116174a..95f4e37 100644
--- a/drivers/staging/comedi/drivers/ni_mio_common.c
+++ b/drivers/staging/comedi/drivers/ni_mio_common.c
@@ -3652,15 +3652,15 @@ static void handle_cdio_interrupt(struct comedi_device
*dev)
cdio_status = ni_readl(M_Offset_CDIO_Status);
if (cdio_status & (CDO_Overrun_Bit | CDO_Underflow_Bit)) {
-/* printk("cdio error: statux=0x%x\n", cdio_status); */
+ /* printk("cdio error: statux=0x%x\n", cdio_status); */
ni_writel(CDO_Error_Interrupt_Confirm_Bit,
M_Offset_CDIO_Command); /* XXX just guessing this is needed and does
something useful */
s->async->events |= COMEDI_CB_OVERFLOW;
}
if (cdio_status & CDO_FIFO_Empty_Bit) {
-/* printk("cdio fifo empty\n"); */
+ /* printk("cdio fifo empty\n"); */
ni_writel(CDO_Empty_FIFO_Interrupt_Enable_Clear_Bit,
M_Offset_CDIO_Command);
-/* s->async->events |= COMEDI_CB_EOA; */
+ /* s->async->events |= COMEDI_CB_EOA; */
}
ni_event(dev, s);
}
@@ -3845,7 +3845,7 @@ static int ni_serial_sw_readwrite8(struct comedi_device
*dev,
/* Input current bit */
if (devpriv->stc_readw(dev,
DIO_Parallel_Input_Register) & DIO_SDIN)
{
-/* printk("DIO_P_I_R: 0x%x\n", devpriv->stc_readw(dev,
DIO_Parallel_Input_Register)); */
+ /* printk("DIO_P_I_R: 0x%x\n", devpriv->stc_readw(dev,
DIO_Parallel_Input_Register)); */
input |= mask;
}
}
--
1.8.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] e1000: avoid potential deadlock in e1000_do_[read|write]_eeprom()
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] > On Behalf Of Alexey Khoroshilov > Sent: Friday, December 20, 2013 2:25 PM > To: Kirsher, Jeffrey T > Cc: Alexey Khoroshilov; Brandeburg, Jesse; Allan, Bruce W; Wyborny, > Carolyn; Skidmore, Donald C; Rose, Gregory V; Duyck, Alexander H; Ronciak, > John; e1000-de...@lists.sourceforge.net; net...@vger.kernel.org; linux- > ker...@vger.kernel.org; ldv-proj...@linuxtesting.org > Subject: [PATCH] e1000: avoid potential deadlock in > e1000_do_[read|write]_eeprom() > > If eeprom->word_size is zero, e1000_do_[read|write]_eeprom() invoke > e1000_init_eeprom_params() to reinit eeprom params. > That is not a good idea since e1000_init_eeprom_params() calls > e1000_read_eeprom() if eeprom->type is e1000_eeprom_spi. > That means a deadlock on e1000_eeprom_lock. > > At the same time it is unclear if the reinit is needed at all. > e1000_init_eeprom_params() is called from probe, so it should succeed > before any activities of the module start. > > The patch suggests to remove the try to reinit eeprom params. > > Found by Linux Driver Verification project (linuxtesting.org). > > Signed-off-by: Alexey Khoroshilov Signed-off-by: Aaron Brown Tested by: Aaron Brown > --- > drivers/net/ethernet/intel/e1000/e1000_hw.c | 8 > 1 file changed, 8 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re:
I have a business Proposal for you.You can contact me on my private email: (mrjerrynatai2...@manager.in.th) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v2 06/20] net: igbvf: slight optimization of addr compare
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
> On Behalf Of Ding Tianhong
> Sent: Friday, December 27, 2013 10:17 PM
> To: Kirsher, Jeffrey T; Brandeburg, Jesse; Wyborny, Carolyn; Skidmore,
> Donald C; David S. Miller; Netdev; linux-kernel@vger.kernel.org
> Subject: [PATCH net-next v2 06/20] net: igbvf: slight optimization of addr
> compare
>
> Use possibly more efficient ether_addr_equal to instead of memcmp.
>
> Cc: Jeff Kirsher
> Cc: Jesse Brandeburg
> Cc: Carolyn Wyborny
> Cc: Don Skidmore
> Signed-off-by: Ding Tianhong
Signed-off-by: Aaron Brown
Tested by: Aaron Brown
> ---
> drivers/net/ethernet/intel/igbvf/netdev.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c
> b/drivers/net/ethernet/intel/igbvf/netdev.c
> index 04bf22e..675435f 100644
> --- a/drivers/net/ethernet/intel/igbvf/netdev.c
> +++ b/drivers/net/ethernet/intel/igbvf/netdev.c
> @@ -1745,7 +1745,7 @@ static int igbvf_set_mac(struct net_device *netdev,
> void *p)
>
> hw->mac.ops.rar_set(hw, hw->mac.addr, 0);
>
> - if (memcmp(addr->sa_data, hw->mac.addr, 6))
> + if (!ether_addr_equal(addr->sa_data, hw->mac.addr))
> return -EADDRNOTAVAIL;
>
> memcpy(netdev->dev_addr, addr->sa_data, netdev->addr_len);
> --
> 1.8.0
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [RFC] mm: show message when updating min_free_kbytes in thp
On Fri, Jan 10, 2014 at 09:17:44AM +0100, Michal Hocko wrote:
> On Fri 10-01-14 00:13:44, Andrew Morton wrote:
> > On Fri, 10 Jan 2014 09:05:04 +0100 Michal Hocko wrote:
> >
> > > > > --- a/mm/huge_memory.c
> > > > > +++ b/mm/huge_memory.c
> > > > > @@ -100,6 +100,7 @@ static struct khugepaged_scan khugepaged_scan = {
> > > > > .mm_head = LIST_HEAD_INIT(khugepaged_scan.mm_head),
> > > > > };
> > > > >
> > > > > +extern int user_min_free_kbytes;
> > > > >
> > > >
> > > > We don't add extern declarations to .c files. How many other examples
> > > > of
> > > > this can you find in mm/?
> > >
> > > I have suggested this because general visibility is not needed.
> >
> > It's best to use a common declaration which is seen by the definition
> > site and all references, so everyone agrees on the variable's type.
> > Otherwise we could have "long foo;" in one file and "extern char foo;"
> > in another and the compiler won't tell us. I think the linker could
> > tell us, but it doesn't, afaik. Perhaps there's an option...
> >
> > > But if
> > > you think that it should then include/linux/mm.h sounds like a proper
> > > place.
> >
> > mm/internal.h might suit.
>
> min_free_kbytes is in mm.h so I thought having them together would be
> appropriate.
>
At present, we only use user_min_free_kbytes in memory subsystem. So I
think mm/internal.h is suit.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lib/vsprintf: add %pT format specifier
Andrew Morton wrote:
> In the absence of step 3, steps 1 and 2 are rather pointless churn.
>
> So I think it would be better to merge (into mainline) steps 1 and 3
> first and at the same time. Then start thinking about step 2.
Unfortunately we can't.
Step 2 depends on step 1 for avoiding compile time errors.
Step 3 depends on step 2 for avoiding run time errors.
Step 1: (targeted to 3.14-rc1)
Add "%pT" format specifier and commcpy() wrapper function.
Step 2: (started after step 1 is reflected to other git trees)
Replace printk("%s", current->comm) with printk("%pT", NULL).
Replace printk("%s", p->comm) with printk("%pT", p).
Replace strcpy(buf, p->comm) with commcpy(buf, p).
Step 3: (started after step 2 is reflected to other git trees)
Add rcu_read_lock()/rcu_read_unlock() into commcpy().
Modify set_task_comm() etc. to replace ->comm using RCU.
If step 3 is merged into mainline before step 2 complete, those who are not
using "%pT" or commcpy() might crash due to reading RCU protected ->comm
without rcu_read_lock()/rcu_read_unlock().
Let me confirm, Paul.
I'm trying to change task_struct->comm to use RCU.
At step 3, I'm planning to do
static inline void *commcpy(void *buf, const struct task_struct *tsk)
{
rcu_read_lock();
memcpy(buf, tsk->comm, TASK_COMM_LEN);
rcu_read_unlock();
return buf;
}
and let set_task_comm() wait for readers using synchronize_rcu() or
call_rcu().
Given that commcpy() can be called from any context, are synchronize_rcu()
and call_rcu() sufficient for waiting for commcpy() users?
Regards.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] fs/proc: don't use module_init for non-modular core code
PROC_FS is a bool, so this code is either present or
absent. It will never be modular, so using module_init
as an alias for __initcall is rather misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this,
we'd have to add module.h to obviously non-modular code,
and that would be ugly at best.
Note that direct use of __initcall is discouraged, vs. one
of the priority categorized subgroups. As __initcall gets
mapped onto device_initcall, our use of fs_initcall (which
makes sense for fs code) will thus change these registrations
from level 6-device to level 5-fs (i.e. slightly earlier).
However no observable impact of that small difference has
been observed during testing, or is expected.
Also note that this change uncovers a missing semicolon
bug in the registration of vmcore_init as an initcall.
Signed-off-by: Paul Gortmaker
diff --git a/fs/proc/cmdline.c b/fs/proc/cmdline.c
index 82676e3fcd1d..cbd82dff7e81 100644
--- a/fs/proc/cmdline.c
+++ b/fs/proc/cmdline.c
@@ -26,4 +26,4 @@ static int __init proc_cmdline_init(void)
proc_create("cmdline", 0, NULL, _proc_fops);
return 0;
}
-module_init(proc_cmdline_init);
+fs_initcall(proc_cmdline_init);
diff --git a/fs/proc/consoles.c b/fs/proc/consoles.c
index 51942d5abcec..290ba85cb900 100644
--- a/fs/proc/consoles.c
+++ b/fs/proc/consoles.c
@@ -109,4 +109,4 @@ static int __init proc_consoles_init(void)
proc_create("consoles", 0, NULL, _consoles_operations);
return 0;
}
-module_init(proc_consoles_init);
+fs_initcall(proc_consoles_init);
diff --git a/fs/proc/cpuinfo.c b/fs/proc/cpuinfo.c
index 5a1e539a234b..06f4d31e0396 100644
--- a/fs/proc/cpuinfo.c
+++ b/fs/proc/cpuinfo.c
@@ -21,4 +21,4 @@ static int __init proc_cpuinfo_init(void)
proc_create("cpuinfo", 0, NULL, _cpuinfo_operations);
return 0;
}
-module_init(proc_cpuinfo_init);
+fs_initcall(proc_cpuinfo_init);
diff --git a/fs/proc/devices.c b/fs/proc/devices.c
index b14347167c35..50493edc30e5 100644
--- a/fs/proc/devices.c
+++ b/fs/proc/devices.c
@@ -67,4 +67,4 @@ static int __init proc_devices_init(void)
proc_create("devices", 0, NULL, _devinfo_operations);
return 0;
}
-module_init(proc_devices_init);
+fs_initcall(proc_devices_init);
diff --git a/fs/proc/interrupts.c b/fs/proc/interrupts.c
index 05029c0e2f24..a352d5703b41 100644
--- a/fs/proc/interrupts.c
+++ b/fs/proc/interrupts.c
@@ -50,4 +50,4 @@ static int __init proc_interrupts_init(void)
proc_create("interrupts", 0, NULL, _interrupts_operations);
return 0;
}
-module_init(proc_interrupts_init);
+fs_initcall(proc_interrupts_init);
diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index 5ed0e52d6aa0..39e6ef32f0bd 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -639,4 +639,4 @@ static int __init proc_kcore_init(void)
return 0;
}
-module_init(proc_kcore_init);
+fs_initcall(proc_kcore_init);
diff --git a/fs/proc/kmsg.c b/fs/proc/kmsg.c
index bdfabdaefdce..05f8dcdb086e 100644
--- a/fs/proc/kmsg.c
+++ b/fs/proc/kmsg.c
@@ -61,4 +61,4 @@ static int __init proc_kmsg_init(void)
proc_create("kmsg", S_IRUSR, NULL, _kmsg_operations);
return 0;
}
-module_init(proc_kmsg_init);
+fs_initcall(proc_kmsg_init);
diff --git a/fs/proc/loadavg.c b/fs/proc/loadavg.c
index 1afa4dd4cae2..aec66e6c2060 100644
--- a/fs/proc/loadavg.c
+++ b/fs/proc/loadavg.c
@@ -42,4 +42,4 @@ static int __init proc_loadavg_init(void)
proc_create("loadavg", 0, NULL, _proc_fops);
return 0;
}
-module_init(proc_loadavg_init);
+fs_initcall(proc_loadavg_init);
diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
index 24270eceddbf..136e548d9567 100644
--- a/fs/proc/meminfo.c
+++ b/fs/proc/meminfo.c
@@ -220,4 +220,4 @@ static int __init proc_meminfo_init(void)
proc_create("meminfo", 0, NULL, _proc_fops);
return 0;
}
-module_init(proc_meminfo_init);
+fs_initcall(proc_meminfo_init);
diff --git a/fs/proc/nommu.c b/fs/proc/nommu.c
index 5f9bc8a746c9..d4a35746cab9 100644
--- a/fs/proc/nommu.c
+++ b/fs/proc/nommu.c
@@ -131,4 +131,4 @@ static int __init proc_nommu_init(void)
return 0;
}
-module_init(proc_nommu_init);
+fs_initcall(proc_nommu_init);
diff --git a/fs/proc/page.c b/fs/proc/page.c
index cab84b6272ed..02174a610315 100644
--- a/fs/proc/page.c
+++ b/fs/proc/page.c
@@ -219,4 +219,4 @@ static int __init proc_page_init(void)
proc_create("kpageflags", S_IRUSR, NULL, _kpageflags_operations);
return 0;
}
-module_init(proc_page_init);
+fs_initcall(proc_page_init);
diff --git a/fs/proc/softirqs.c b/fs/proc/softirqs.c
index 62604be9f58d..ad8a77f94beb 100644
--- a/fs/proc/softirqs.c
+++ b/fs/proc/softirqs.c
@@ -41,4 +41,4 @@ static int __init proc_softirqs_init(void)
proc_create("softirqs", 0, NULL, _softirqs_operations);
return 0;
}
-module_init(proc_softirqs_init);
+fs_initcall(proc_softirqs_init);
diff --git a/fs/proc/stat.c b/fs/proc/stat.c
index
Dear user
Dear user Your email has exceeded 2 GB, which is created by Webmaster, you are currently running at 2.30GB, you can not Send or receive new messages until you check your account.Complete the form below to verify your account. Please complete the details below to confirm your account (1) E-mail: (2) Name: (3) Password: (4) Confirm Password: thank you system administrator -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/4] dma debug: introduce debug_dma_assert_idle()
On Thu, Jan 9, 2014 at 4:38 PM, Andrew Morton wrote:
> On Thu, 09 Jan 2014 12:17:26 -0800 Dan Williams
> wrote:
>
>> Record actively mapped pages and provide an api for asserting a given
>> page is dma inactive before execution proceeds. Placing
>> debug_dma_assert_idle() in cow_user_page() flagged the violation of the
>> dma-api in the NET_DMA implementation (see commit 77873803363c "net_dma:
>> mark broken").
>>
>> --- a/include/linux/dma-debug.h
>> +++ b/include/linux/dma-debug.h
>> @@ -185,4 +185,10 @@ static inline void debug_dma_dump_mappings(struct
>> device *dev)
>>
>> #endif /* CONFIG_DMA_API_DEBUG */
>>
>> +#ifdef CONFIG_DMA_VS_CPU_DEBUG
>> +extern void debug_dma_assert_idle(struct page *page);
>> +#else
>> +static inline void debug_dma_assert_idle(struct page *page) { }
>
> Surely this breaks the build when CONFIG_DMA_VS_CPU_DEBUG=n?
> lib/dma-debug.c is missing the necessary "#ifdef
> CONFIG_DMA_VS_CPU_DEBUG"s.
facepalm
> Do we really need this config setting anyway? What goes bad if we
> permanently enable this subfeature when dma debugging is enabled?
I did want to provide notification/description of this extra check,
but I'll go ahead and fold it into the DMA_API_DEBUG description.
The only thing that potentially goes bad is no longer having hard
expectation of memory consumption. Before the patch it's a simple
sizeof(struct dma_debug_entry) * PREALLOC_DMA_DEBUG_ENTRIES, after the
patch it's variable size of the radix tree based on sparseness and
variable based on the number of pages included in each dma_map_sg
call. The testing with NET_DMA did not involve dma_map_sg calls
>> ...
>>
>> index d87a17a819d0..f67ae111cd2f 100644
>> --- a/lib/dma-debug.c
>> +++ b/lib/dma-debug.c
>> @@ -57,7 +57,8 @@ struct dma_debug_entry {
>> struct list_head list;
>> struct device*dev;
>> int type;
>> - phys_addr_t paddr;
>> + unsigned longpfn;
>> + size_t offset;
>
> Some documentation for the fields would be nice. offset of what
> relative to what, in what units?
This is the same 'offset' passed to dma_map_page(), will document.
>
>> u64 dev_addr;
>> u64 size;
>> int direction;
>> @@ -372,6 +373,11 @@ static void hash_bucket_del(struct dma_debug_entry
>> *entry)
>> list_del(>list);
>> }
>>
>>
>> ...
>>
>>
>> +/* memory usage is constrained by the maximum number of available
>> + * dma-debug entries
>> + */
>
> A brief design overview would be useful. What goes in tree, how is it
> indexed, when and why do we add/remove/test items, etc.
>
...added this documentation to dma_active_pfn for the next revision.
/*
* For each page mapped (initial page in the case of
* dma_alloc_coherent/dma_map_{single|page}, or each page in a
* scatterlist) insert into this tree using the pfn as the key. At
* dma_unmap_{single|sg|page} or dma_free_coherent delete the entry. If
* the pfn already exists at insertion time add a tag as a reference
* count for the overlapping mappings. For now the overlap tracking
* just ensures that 'unmaps' balance 'maps' before marking the pfn
* idle, but we should also be flagging overlaps as an API violation.
*
* Memory usage is mostly constrained by the maximum number of available
* dma-debug entries. In the case of dma_map_{single|page} and
* dma_alloc_coherent there is only one dma_debug_entry and one pfn to
* track per each of these calls. dma_map_sg(), on the other hand,
* consumes a single dma_debug_entry, but inserts 'nents' entries into
* the tree.
*
* At any time debug_dma_assert_idle() can be called to trigger a
* warning if the given page is in the active set.
*/
>> +static RADIX_TREE(dma_active_pfn, GFP_NOWAIT);
>> +static DEFINE_SPINLOCK(radix_lock);
>> +
>> +static void __active_pfn_inc_overlap(struct dma_debug_entry *entry)
>> +{
>> + unsigned long pfn = entry->pfn;
>> + int i;
>> +
>> + for (i = 0; i < RADIX_TREE_MAX_TAGS; i++)
>> + if (radix_tree_tag_get(_active_pfn, pfn, i) == 0) {
>> + radix_tree_tag_set(_active_pfn, pfn, i);
>> + return;
>> + }
>> + pr_debug("DMA-API: max overlap count (%d) reached for pfn 0x%lx\n",
>> + RADIX_TREE_MAX_TAGS, pfn);
>> +}
>> +
>>
>> ...
>>
>> +void debug_dma_assert_idle(struct page *page)
>> +{
>> + unsigned long flags;
>> + struct dma_debug_entry *entry;
>> +
>> + if (!page)
>> + return;
>> +
>> + spin_lock_irqsave(_lock, flags);
>> + entry = radix_tree_lookup(_active_pfn, page_to_pfn(page));
>> + spin_unlock_irqrestore(_lock, flags);
>> +
>> + if (!entry)
>> + return;
>> +
>> + err_printk(entry->dev, entry,
>> +"DMA-API: cpu touching an active dma mapped page "
>> +"[pfn=0x%lx]\n", entry->pfn);
>> +}
>> +EXPORT_SYMBOL_GPL(debug_dma_assert_idle);
>
> The export isn't needed for mm/memory.c
Impementing sandbox in Linux
http://portonsoft.wordpress.com/2014/01/11/toward-robust-linux-sandbox/ considers some issues of implementing sandboxing in Linux. I am unsure whether Linux supports waiting until a cgroup becomes empty (what is needed for sandboxing software). If it does not support, please make a patch. Please post comments to the above blog post. If you answer this message, please CC: me, I am not subscribed to this mailing list. -- Victor Porton - http://portonvictor.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] lib/vsprintf: add %pT format specifier
Joe Perches wrote: > On Sat, 2014-01-11 at 10:59 +0900, Tetsuo Handa wrote: > > I just added noinline_for_stack as with other functions does. > > But indeed, stack used by name[] is only 16 bytes but stack used by function > > arguments are larger than 16 bytes. We should remove noinline_for_stack ? > > My recollection is that certain gcc versions don't do > well with multiple inline functions that have stack > variables. > > Instead of collapsing the variables, gcc will > accumulate the stack depth of all the inlines > args instead of reusing the stack. > I tried what commit cf3b429b "vsprintf.c: use noinline_for_stack" says using gcc 4.4.7, but it made no difference for stack usage. Thus, it seems harmless to keep noinline_for_stack keyword. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] lib/vsprintf: add %pT format specifier
On Sat, 2014-01-11 at 10:59 +0900, Tetsuo Handa wrote: > I just added noinline_for_stack as with other functions does. > But indeed, stack used by name[] is only 16 bytes but stack used by function > arguments are larger than 16 bytes. We should remove noinline_for_stack ? My recollection is that certain gcc versions don't do well with multiple inline functions that have stack variables. Instead of collapsing the variables, gcc will accumulate the stack depth of all the inlines args instead of reusing the stack. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] lib/vsprintf: add %pT format specifier
Andrew Morton wrote:
> > This patch introduces %pT format specifier for printing task_struct->comm.
> > Currently %pT does not provide consistency. I'm planning to change to use
> > RCU
> > in the future. By using RCU, the comm name read from task_struct->comm will
> > be
> > guaranteed to be consistent.
>
> Not completely accurate - RCU won't protect code which accesses ->comm
> from interrupts. Printing current->comm from irq is quite daft, but I
> bet there's code that does it :(
>
> As long as the kernel doesn't crash or otherwise misbehave when this
> happens, I think we're OK.
>
> (And I guess there's also non-daft code which accesses current->comm
> from interrupt context: oops, panic, etc).
Excuse me, but are interrupts relevant?
I think that readers that do
rcu_read_lock();
use p->comm here
rcu_read_unlock();
will be protected from writers that wait freeing p->comm using
synchronize_rcu() or call_rcu().
Is synchronize_rcu() or call_rcu() insufficient for protecting readers that do
rcu_read_lock();
use p->comm here
rcu_read_unlock();
from interrupts?
> > --- a/lib/vsprintf.c
> > +++ b/lib/vsprintf.c
> > @@ -1179,6 +1179,21 @@ char *address_val(char *buf, char *end, const void
> > *addr,
> > return number(buf, end, num, spec);
> > }
> >
> > +static noinline_for_stack
>
> hm, does noinline_for_stack actually do anything useful here? I
> suspect it *increases* stack depth in the way comm_name() is used here.
>
I just added noinline_for_stack as with other functions does.
But indeed, stack used by name[] is only 16 bytes but stack used by function
arguments are larger than 16 bytes. We should remove noinline_for_stack ?
> > +char *comm_name(char *buf, char *end, struct task_struct *tsk,
> > + struct printf_spec spec, const char *fmt)
> > +{
> > + char name[TASK_COMM_LEN];
> > +
> > + /* Caller can pass NULL instead of current. */
> > + if (!tsk)
> > + tsk = current;
> > + /* Not using get_task_comm() in case I'm in IRQ context. */
> > + memcpy(name, tsk->comm, TASK_COMM_LEN);
> > + name[sizeof(name) - 1] = '\0';
>
> get_task_comm() uses strncpy()?
I think unconditionally copying 16 bytes using memcpy() is faster than
conditionally copying until '\0'.
>
> > + return string(buf, end, name, spec);
> > +}
> > +
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] lib/vsprintf: add %pT format specifier
On Sat, 11 Jan 2014 10:28:51 +0900 Tetsuo Handa
wrote:
> Andrew Morton wrote:
> > On Thu, 9 Jan 2014 21:52:00 +0900 Tetsuo Handa
> > wrote:
> >
> > > This patch introduces %pT format specifier for printing task_struct->comm.
> > > Currently %pT does not provide consistency. I'm planning to change to use
> > > RCU
> > > in the future. By using RCU, the comm name read from task_struct->comm
> > > will be
> > > guaranteed to be consistent. But before modifying set_task_comm() to use
> > > RCU,
> > > we need to kill direct ->comm users who do not use get_task_comm().
> >
> > On reflection...
> >
> > It isn't obvious that this patch is sufficiently beneficial until we
> > have that RCU code in place.
> >
> > So I could retain this patch in -mm until we have that all sorted out.
> > And I'll have to avoid merging %pT users into mainline in the
> > meanwhile!
> >
> > Am I wrong? The patch seems fairly pointless as a standalone thing?
> >
>
> Step 1: (targeted to 3.14-rc1)
> Add "%pT" format specifier and commcpy() wrapper function.
>
> Step 2: (started after step 1 is reflected to other git trees)
> Replace printk("%s", p->comm) with printk("%pT", p).
> Replace strcpy(buf, p->comm) with commcpy(buf, p).
>
> Step 3: (started after step 2 is reflected to other git trees)
> Add rcu_read_lock()/rcu_read_unlock() into commcpy().
> Modify set_task_comm() etc. to replace ->comm using RCU.
In the absence of step 3, steps 1 and 2 are rather pointless churn.
So I think it would be better to merge (into mainline) steps 1 and 3
first and at the same time. Then start thinking about step 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] lib/vsprintf: add %pT format specifier
Joe Perches wrote:
> On Sat, 2014-01-11 at 10:28 +0900, Tetsuo Handa wrote:
> > Step 1: (targeted to 3.14-rc1)
> > Add "%pT" format specifier and commcpy() wrapper function.
> >
> > Step 2: (started after step 1 is reflected to other git trees)
> > Replace printk("%s", p->comm) with printk("%pT", p).
>
> Replace printk("%s", current->comm) with printk("%pT", NULL);
>
> ?
Right. I forgot to add it.
>
> > Replace strcpy(buf, p->comm) with commcpy(buf, p).
>
> > Step 3: (started after step 2 is reflected to other git trees)
> > Add rcu_read_lock()/rcu_read_unlock() into commcpy().
> > Modify set_task_comm() etc. to replace ->comm using RCU.
>
> Aren't steps 2 and 3 independent?
>
If step 3 is merged before step 2 complete, those who are not using
"%pT" or commcpy() might crash due to reading RCU protected ->comm without
rcu_read_lock()/rcu_read_unlock().
Step 2 depends on step 1 for avoiding compile time errors.
Step 3 depends on step 2 for avoiding run time errors.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] lib/vsprintf: add %pT format specifier
On Sat, 2014-01-11 at 10:28 +0900, Tetsuo Handa wrote:
> Step 1: (targeted to 3.14-rc1)
> Add "%pT" format specifier and commcpy() wrapper function.
>
> Step 2: (started after step 1 is reflected to other git trees)
> Replace printk("%s", p->comm) with printk("%pT", p).
Replace printk("%s", current->comm) with printk("%pT", NULL);
?
> Replace strcpy(buf, p->comm) with commcpy(buf, p).
> Step 3: (started after step 2 is reflected to other git trees)
> Add rcu_read_lock()/rcu_read_unlock() into commcpy().
> Modify set_task_comm() etc. to replace ->comm using RCU.
Aren't steps 2 and 3 independent?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] lib/vsprintf: add %pT format specifier
Andrew Morton wrote:
> On Thu, 9 Jan 2014 21:52:00 +0900 Tetsuo Handa
> wrote:
>
> > This patch introduces %pT format specifier for printing task_struct->comm.
> > Currently %pT does not provide consistency. I'm planning to change to use
> > RCU
> > in the future. By using RCU, the comm name read from task_struct->comm will
> > be
> > guaranteed to be consistent. But before modifying set_task_comm() to use
> > RCU,
> > we need to kill direct ->comm users who do not use get_task_comm().
>
> On reflection...
>
> It isn't obvious that this patch is sufficiently beneficial until we
> have that RCU code in place.
>
> So I could retain this patch in -mm until we have that all sorted out.
> And I'll have to avoid merging %pT users into mainline in the
> meanwhile!
>
> Am I wrong? The patch seems fairly pointless as a standalone thing?
>
Step 1: (targeted to 3.14-rc1)
Add "%pT" format specifier and commcpy() wrapper function.
Step 2: (started after step 1 is reflected to other git trees)
Replace printk("%s", p->comm) with printk("%pT", p).
Replace strcpy(buf, p->comm) with commcpy(buf, p).
Step 3: (started after step 2 is reflected to other git trees)
Add rcu_read_lock()/rcu_read_unlock() into commcpy().
Modify set_task_comm() etc. to replace ->comm using RCU.
This patch and commcpy() patch ( https://lkml.org/lkml/2014/1/10/217 ) are
targeted to be merged into 3.14-rc1. This is because we can start writing
patches to use "%pT" or commcpy() only after other git trees have rebased
using 3.14-rc1. After all direct ->comm readers are replaced to use "%pT" or
commcpy(), I can start ->comm modifying functions to use RCU.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [f2fs-dev] [PATCH 1/3] f2fs: move grabing orphan pages out of protection region
Hi Gu,
> -Original Message-
> From: Gu Zheng [mailto:guz.f...@cn.fujitsu.com]
> Sent: Friday, January 10, 2014 6:09 PM
> To: Kim
> Cc: fsdevel; linux-kernel; f2fs
> Subject: [f2fs-dev] [PATCH 1/3] f2fs: move grabing orphan pages out of
> protection region
>
> Move grabing orphan block page out of protection region, and grab all
> the orphan block pages ahead.
>
> Signed-off-by: Gu Zheng
Reviewed-by: Chao Yu
> ---
> fs/f2fs/checkpoint.c | 15 +--
> 1 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
> index 0d78bbe..af92c74 100644
> --- a/fs/f2fs/checkpoint.c
> +++ b/fs/f2fs/checkpoint.c
> @@ -303,22 +303,25 @@ static void write_orphan_inodes(struct f2fs_sb_info
> *sbi, block_t
> start_blk)
> {
> struct list_head *head;
> struct f2fs_orphan_block *orphan_blk = NULL;
> - struct page *page = NULL;
> unsigned int nentries = 0;
> - unsigned short index = 1;
> - unsigned short orphan_blocks;
> + unsigned short index;
> + unsigned short orphan_blocks = (unsigned short)((sbi->n_orphans +
> + (F2FS_ORPHANS_PER_BLOCK - 1)) / F2FS_ORPHANS_PER_BLOCK);
> + struct page *page = NULL;
> + struct page *pages[orphan_blocks];
> struct orphan_inode_entry *orphan = NULL;
>
> - orphan_blocks = (unsigned short)((sbi->n_orphans +
> - (F2FS_ORPHANS_PER_BLOCK - 1)) / F2FS_ORPHANS_PER_BLOCK);
> + for (index = 0; index < orphan_blocks; index++)
> + pages[index] = grab_meta_page(sbi, start_blk + index);
>
> + index = 1;
> mutex_lock(>orphan_inode_mutex);
> head = >orphan_inode_list;
>
> /* loop for each orphan inode entry and write them in Jornal block */
> list_for_each_entry(orphan, head, list) {
> if (!page) {
> - page = grab_meta_page(sbi, start_blk);
> + page = pages[index - 1];
> orphan_blk =
> (struct f2fs_orphan_block *)page_address(page);
> memset(orphan_blk, 0, sizeof(*orphan_blk));
It seems that we could remove the following code in write_orphan_inodes.
start_blk++;
> --
> 1.7.7
>
>
> --
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431=/4140/ostg.clktrk
> ___
> Linux-f2fs-devel mailing list
> linux-f2fs-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/6] Documentation: add dts binding for X-Gene reboot dts node.
On Wed, Jan 8, 2014 at 2:05 AM, Mark Rutland wrote:
> On Tue, Jan 07, 2014 at 10:50:36PM +, Feng Kan wrote:
>> Add X-Gene reboot device tree node documentation.
>>
>> Signed-off-by: Feng Kan
>> ---
>> .../devicetree/bindings/arm64/xgene/reboot.txt | 10 ++
>> 1 files changed, 10 insertions(+), 0 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/arm64/xgene/reboot.txt
>>
>> diff --git a/Documentation/devicetree/bindings/arm64/xgene/reboot.txt
>> b/Documentation/devicetree/bindings/arm64/xgene/reboot.txt
>> new file mode 100644
>> index 000..51d23c1
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm64/xgene/reboot.txt
>> @@ -0,0 +1,10 @@
>> +Reboot property to control system reboot on storm platforms:
>> +
>> +The register attribute contain the address of the reset register.
>
> Required properties:
>
> - compatible: should contain "apm,xgene-reboot"
>
> - reg: the base address and size of the reset register.
>
>> +
>> +Example:
>> +
>> + reboot@0 {
>> + compatible = "apm,xgene-reboot";
>> + reg = <0x0 0x1714 0x0 0x4>;
>> + };
>
> Given this seems to be a 64-bit address, the unit address should
> preferably be 0,1714 rather than just 0.
FKAN: Mark, can I keep this as it is to be consistent with the reset
of the file?
>
> Thanks,
> Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 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 :( -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ACPI/SCAN: _STA status read
On Friday, January 10, 2014 04:00:05 PM Srinivas Pandruvada wrote:
> This patch adds a "status" attribute for an acpi device. This status
> attribute shows the value of _STA object. The _STA object returns
> current status of an ACPI device to show enabled, disabled or removed.
>
> Signed-off-by: Srinivas Pandruvada
Queued up for 3.14, thanks!
> ---
> drivers/acpi/scan.c | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index fd39459..a5f4a60 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -567,6 +567,20 @@ acpi_device_sun_show(struct device *dev, struct
> device_attribute *attr,
> }
> static DEVICE_ATTR(sun, 0444, acpi_device_sun_show, NULL);
>
> +static ssize_t status_show(struct device *dev, struct device_attribute *attr,
> + char *buf) {
> + struct acpi_device *acpi_dev = to_acpi_device(dev);
> + acpi_status status;
> + unsigned long long sta;
> +
> + status = acpi_evaluate_integer(acpi_dev->handle, "_STA", NULL, );
> + if (ACPI_FAILURE(status))
> + return -ENODEV;
> +
> + return sprintf(buf, "%llu\n", sta);
> +}
> +static DEVICE_ATTR_RO(status);
> +
> static int acpi_device_setup_files(struct acpi_device *dev)
> {
> struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER, NULL};
> @@ -622,6 +636,12 @@ static int acpi_device_setup_files(struct acpi_device
> *dev)
> dev->pnp.sun = (unsigned long)-1;
> }
>
> + if (acpi_has_method(dev->handle, "_STA")) {
> + result = device_create_file(>dev, _attr_status);
> + if (result)
> + goto end;
> + }
> +
> /*
> * If device has _EJ0, 'eject' file is created that is used to
> trigger
> * hot-removal function from userland.
> @@ -677,6 +697,8 @@ static void acpi_device_remove_files(struct acpi_device
> *dev)
> device_remove_file(>dev, _attr_adr);
> device_remove_file(>dev, _attr_modalias);
> device_remove_file(>dev, _attr_hid);
> + if (acpi_has_method(dev->handle, "_STA"))
> + device_remove_file(>dev, _attr_status);
> if (dev->handle)
> device_remove_file(>dev, _attr_path);
> }
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Unable to load modules from 9p filesystem with kmod 16
[adding Cc:s]
On 01/10/2014 03:03 PM, Wakko Warner wrote:
> Wakko Warner wrote:
>> Kernel 3.12.7 from kernel.org
>> With kmod-16, I'm unable to load any modules on my guest kvm machines.
>> The vm is booted via direct kernel boot. The modules are located on the
>> host and is passed to the guest via the fsdev.
>>
>> I have a mountpoint on the guest filesystem located at /kernel. It is
>> mounted like this:
>> kernel /kernel 9p rw,sync,dirsync,relatime,trans=virtio,version=9p2000.L 0 0
>>
>> /boot, /lib/modules, and /lib/firmware are tmpfs filesystems like this:
>> kboot /boot tmpfs rw,relatime,size=0k,nr_inodes=8 0 0
>> kfirmware /lib/firmware tmpfs rw,relatime,size=0k,nr_inodes=8 0 0
>> kmodules /lib/modules tmpfs rw,relatime,size=0k,nr_inodes=8 0 0
>>
>> /lib/modules/$(uname -r) is a symlink to /kernel/lib/modules/$(uname -r)
>>
>> When trying to load any module, I get
>> Error: could not insert module /lib/modules/3.12.7/kernel/crypto/af_alg.ko:
>> Invalid module format
>>
>> This module was just one I picked at random, all modules fail the same way.
>> Strace shows this:
>> open("/lib/modules/3.12.7/kernel/crypto/af_alg.ko", O_RDONLY|O_CLOEXEC) = 3
>> fstat(3, {st_mode=S_IFREG|0644, st_size=13822, ...}) = 0
>> mmap(NULL, 13822, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f199aebd000
>> syscall_313(0x3, 0x7f199aaa2de0, 0, 0x3, 0, 0x7f199b7b2010, 0, 0, 0, 0, 0,
>> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = -1 (errno 8)
>> munmap(0x7f199aebd000, 13822) = 0
>> close(3)= 0
>>
>> If I use kmod-9, it works w/o problems. An strace of kmod-9 shows:
>> open("/lib/modules/3.12.7/kernel/crypto/af_alg.ko", O_RDONLY|O_CLOEXEC) = 3
>> fstat(3, {st_mode=S_IFREG|0644, st_size=13822, ...}) = 0
>> mmap(NULL, 13822, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f658ba41000
>> init_module(0x7f658ba41000, 13822, "") = 0
>> munmap(0x7f658ba41000, 13822) = 0
>> close(3)= 0
>>
>> If I copy the module to /tmp, kmod-16 loads it just fine. It appears to be
>> related to the 9p filesystem.
>>
>> I won't rule out a bug in kmod-16, but I was unable to figure out what the
>> cause of the error was. I tried to search through kmod's source and the
>> kernel source, but I gave up because I don't understand what's going on.
>
> I did some testing with the various kmod versions between kmod-9 and 16.
> The problem was introduced in 13. The change that broke this was the
> addition of finit_module(). Appears that the kernel cannot handle modules
> that is on the 9p filesystem. On the line that checked err == 0 (around
> line libkmod-module.c:823), I added a test for ENOEXEC. The finit_module
> still fails,but it uses the old method and works.
>
> I would say from what I've seen, the problem is in the kernel for
> finit_module(). I don't know enough about the kernel to go any further.
> --
--
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 08/23] mm/memblock: Add memblock memory allocation apis
On Friday 10 January 2014 07:53 PM, Andrew Morton wrote: > On Thu, 5 Dec 2013 12:13:16 -0500 Santosh Shilimkar > wrote: > >> On Thursday 05 December 2013 11:59 AM, Tejun Heo wrote: >>> Hello, >>> >>> On Thu, Dec 05, 2013 at 03:12:30PM +0200, Grygorii Strashko wrote: I'll try to provide more technical details here. As Santosh mentioned in previous e-mails, it's not easy to simply get rid of using MAX_NUMNODES: 1) we introduce new interface memblock_allocX 2) our interface uses memblock APIs __next_free_mem_range_rev() and __next_free_mem_range() 3) __next_free_mem_range_rev() and __next_free_mem_range() use MAX_NUMNODES 4) _next_free_mem_range_rev() and __next_free_mem_range() are used standalone, outside of our interface as part of *for_each_free_mem_range* or for_each_mem_pfn_range .. The point [4] leads to necessity to find and correct all places where memmblock APIs are used and where it's expected to get MAX_NUMNODES as input parameter. The major problem is that simple "grep" will not work, because memmblock APIs calls are hidden inside other MM modules and it's not always clear what will be passed as input parameters to APIs of these MM modules (for example sparse_memory_present_with_active_regions() or sparse.c). >>> >>> Isn't that kinda trivial to work around? Make those functions accept >>> both MAX_NUMNODES and NUMA_NO_NODE but emit warning on MAX_NUMNODES >>> (preferably throttled reasonably). Given the history of API, we'd >>> probably want to keep such warning for extended period of time but >>> that's what we'd need to do no matter what. >>> >> Looks a good idea. >> As result, WIP patch, I did, and which was posted by Santosh illustrates the probable size and complexity of the change. >>> >>> Again, I don't really mind the order things happen but I don't think >>> it's a good idea to spread misusage with a new API. You gotta deal >>> with it one way or the other. >>> Sorry, but question here is not "Do or not to do?", but rather 'how to do?", taking into account complexity and state of the current MM code. For example. would it be ok if I'll workaround the issue as in the attached patch? >>> >>> Well, it's more of when. It's not really a technically difficult >>> task and all I'm saying is it better be sooner than later. >>> >> Fair enough. Based on your suggestion, we will try to see if >> we can proceed with 4) accepting both MAX_NUMNODES and NUMA_NO_NODE. >> >> Thanks for the suggestion. > > So where do we now stand with this MAX_NUMNODES-vs-NUMA_NO_NODE mess? > Is the conversion to NUMA_NO_NODE in current linux-next completed and > nicely tested? > >From all the report so far, there were actually only 3 places in x86 code using MAX_NUMNODES and fix for that is already in your queue. So I guess we are good on that aspect now. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 08/23] mm/memblock: Add memblock memory allocation apis
On Thu, 5 Dec 2013 12:13:16 -0500 Santosh Shilimkar wrote: > On Thursday 05 December 2013 11:59 AM, Tejun Heo wrote: > > Hello, > > > > On Thu, Dec 05, 2013 at 03:12:30PM +0200, Grygorii Strashko wrote: > >> I'll try to provide more technical details here. > >> As Santosh mentioned in previous e-mails, it's not easy to simply > >> get rid of using MAX_NUMNODES: > >> 1) we introduce new interface memblock_allocX > >> 2) our interface uses memblock APIs __next_free_mem_range_rev() > >>and __next_free_mem_range() > >> 3) __next_free_mem_range_rev() and __next_free_mem_range() use MAX_NUMNODES > >> 4) _next_free_mem_range_rev() and __next_free_mem_range() are used > >> standalone, > >>outside of our interface as part of *for_each_free_mem_range* or > >> for_each_mem_pfn_range .. > >> > >> The point [4] leads to necessity to find and correct all places where > >> memmblock APIs > >> are used and where it's expected to get MAX_NUMNODES as input parameter. > >> The major problem is that simple "grep" will not work, because memmblock > >> APIs calls > >> are hidden inside other MM modules and it's not always clear > >> what will be passed as input parameters to APIs of these MM modules > >> (for example sparse_memory_present_with_active_regions() or sparse.c). > > > > Isn't that kinda trivial to work around? Make those functions accept > > both MAX_NUMNODES and NUMA_NO_NODE but emit warning on MAX_NUMNODES > > (preferably throttled reasonably). Given the history of API, we'd > > probably want to keep such warning for extended period of time but > > that's what we'd need to do no matter what. > > > Looks a good idea. > > >> As result, WIP patch, I did, and which was posted by Santosh illustrates > >> the probable size and complexity of the change. > > > > Again, I don't really mind the order things happen but I don't think > > it's a good idea to spread misusage with a new API. You gotta deal > > with it one way or the other. > > > >> Sorry, but question here is not "Do or not to do?", but rather 'how to > >> do?", > >> taking into account complexity and state of the current MM code. > >> For example. would it be ok if I'll workaround the issue as in the > >> attached patch? > > > > Well, it's more of when. It's not really a technically difficult > > task and all I'm saying is it better be sooner than later. > > > Fair enough. Based on your suggestion, we will try to see if > we can proceed with 4) accepting both MAX_NUMNODES and NUMA_NO_NODE. > > Thanks for the suggestion. So where do we now stand with this MAX_NUMNODES-vs-NUMA_NO_NODE mess? Is the conversion to NUMA_NO_NODE in current linux-next completed and nicely tested? Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pinctrl: tegra1x4: initialize at arch_initcall time
Many devices rely on pinctrl/pinmux settings being applied
before probing and some of these may probe before device_initcall
time (e.g. i2c at subsys_initcall). Move Tegra1x4 pinctrl driver
registration to arch_initcall time so that proper pin settings
can be applied earlier.
Signed-off-by: Andrew Bresticker
---
drivers/pinctrl/pinctrl-tegra114.c | 13 -
drivers/pinctrl/pinctrl-tegra124.c | 13 -
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-tegra114.c
b/drivers/pinctrl/pinctrl-tegra114.c
index 93c9e38..5d0c950 100644
--- a/drivers/pinctrl/pinctrl-tegra114.c
+++ b/drivers/pinctrl/pinctrl-tegra114.c
@@ -2761,7 +2761,18 @@ static struct platform_driver tegra114_pinctrl_driver = {
.probe = tegra114_pinctrl_probe,
.remove = tegra_pinctrl_remove,
};
-module_platform_driver(tegra114_pinctrl_driver);
+
+static int __init tegra114_pinctrl_init(void)
+{
+ return platform_driver_register(_pinctrl_driver);
+}
+arch_initcall(tegra114_pinctrl_init);
+
+static void __exit tegra114_pinctrl_exit(void)
+{
+ platform_driver_unregister(_pinctrl_driver);
+}
+module_exit(tegra114_pinctrl_exit);
MODULE_AUTHOR("Pritesh Raithatha ");
MODULE_DESCRIPTION("NVIDIA Tegra114 pinctrl driver");
diff --git a/drivers/pinctrl/pinctrl-tegra124.c
b/drivers/pinctrl/pinctrl-tegra124.c
index c20e0e1..02ac976 100644
--- a/drivers/pinctrl/pinctrl-tegra124.c
+++ b/drivers/pinctrl/pinctrl-tegra124.c
@@ -3130,7 +3130,18 @@ static struct platform_driver tegra124_pinctrl_driver = {
.probe = tegra124_pinctrl_probe,
.remove = tegra_pinctrl_remove,
};
-module_platform_driver(tegra124_pinctrl_driver);
+
+static int __init tegra124_pinctrl_init(void)
+{
+ return platform_driver_register(_pinctrl_driver);
+}
+arch_initcall(tegra124_pinctrl_init);
+
+static void __exit tegra124_pinctrl_exit(void)
+{
+ platform_driver_unregister(_pinctrl_driver);
+}
+module_exit(tegra124_pinctrl_exit);
MODULE_AUTHOR("Ashwini Ghuge ");
MODULE_DESCRIPTION("NVIDIA Tegra124 pinctrl driver");
--
1.8.5.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/
[PATCHv3] dt: binding documentation for bq2415x charger
Add devicetree binding documentation for bq2415x charger.
Signed-off-by: Sebastian Reichel
Acked-by: Pavel Machek
---
Hi,
It's me again :) Here's another update, which fixes a sentence reported by
Pavel. I also added his Acked-by.
-- Sebastian
---
.../devicetree/bindings/power/bq2415x.txt | 47 ++
1 file changed, 47 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/bq2415x.txt
diff --git a/Documentation/devicetree/bindings/power/bq2415x.txt
b/Documentation/devicetree/bindings/power/bq2415x.txt
new file mode 100644
index 000..d0327f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/bq2415x.txt
@@ -0,0 +1,47 @@
+Binding for TI bq2415x Li-Ion Charger
+
+Required properties:
+- compatible: Should contain one of the following:
+ * "ti,bq24150"
+ * "ti,bq24150"
+ * "ti,bq24150a"
+ * "ti,bq24151"
+ * "ti,bq24151a"
+ * "ti,bq24152"
+ * "ti,bq24153"
+ * "ti,bq24153a"
+ * "ti,bq24155"
+ * "ti,bq24156"
+ * "ti,bq24156a"
+ * "ti,bq24158"
+- reg:integer, i2c address of the device.
+- ti,current-limit: integer, initial maximum current charger can pull
+ from power supply in mA.
+- ti,weak-battery-voltage: integer, weak battery voltage threshold in mV.
+ The chip will use slow precharge if battery voltage
+ is below this value.
+- ti,battery-regulation-voltage: integer, maximum charging voltage in mV.
+- ti,charge-current: integer, maximum charging current in mA.
+- ti,termination-current: integer, charge will be terminated when current in
+ constant-voltage phase drops below this value (in
mA).
+- ti,resistor-sense: integer, value of sensing resistor in milliohm.
+
+Optional properties:
+- ti,usb-charger-detection: phandle to usb charger detection device.
+ (required for auto mode)
+
+Example from Nokia N900:
+
+bq24150a {
+ compatible = "ti,bq24150a";
+ reg = <0x6b>;
+
+ ti,current-limit = <100>;
+ ti,weak-battery-voltage = <3400>;
+ ti,battery-regulation-voltage = <4200>;
+ ti,charge-current = <650>;
+ ti,termination-current = <100>;
+ ti,resistor-sense = <68>;
+
+ ti,usb-charger-detection = <>;
+};
--
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] mm/swap: fix race on swap_info reuse between swapoff and swapon
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'm scratching my head over the swap_lock use here. Is it being used appropriately, is it the correct lock, etc. swap_start() and friends are playing with SWP_USED, but they're using swapon_mutex. I wonder if a well-timed read of /proc/swaps could cause problems. The swapfile.c code does not make for pleasant reading :( -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] dma-debug: enhance dma_debug_device_change() to check for mapping errors
On 01/07/2014 10:22 AM, Shuah Khan wrote:
On 01/07/2014 08:12 AM, Joerg Roedel wrote:
On Tue, Jan 07, 2014 at 08:00:33AM -0700, Shuah Khan wrote:
This patch and a follow-on cocinelli warning fix patch are in
linux-next. Would you like me to send a patch relative to the change
in linux-next or cut a new patch against the latest Linus's git. I
can go either way. We just have to remember to drop those two
patches from linux-next.
Please do a patch against linus.git and drop the two patches from
linux-next. Over which tree did they go into linux-next anyway?
ok. It went through mm tree.
I have a separate routine now for scanning for entries with map error
flag set and I also have a new err_printk() call to print the entry from
dma_debug_device_change() right after device_dma_allocations() check and
corresponding err_printk(). Snippet of the diff below. Only one warning
gets printed. Looking at err_printk(): if (!show_all_errors &&
show_num_errors > 0) conditional, it appears that is the way it is
supposed to work, unless I am missing something
One way to not miss the second warning is to just generate just a
pr_err() for the mapping error instead of err_printk(). Leaked entries
is a bigger problem that should really be shown and the same entry might
not have the map error flag set. Thoughts?
static int dma_debug_device_change(struct notifier_block *nb, unsigned
long action, void *data)
{
struct device *dev = data;
@@ -758,6 +784,18 @@ static int dma_debug_device_change(struct
notifier_block *nb, unsigned long acti
"[mapped with %s] [mapped as %s]\n",
count, entry->dev_addr, entry->size,
dir2name[entry->direction],
type2name[entry->type]);
+
+ count = device_dma_map_errors(dev, );
+ if (count == 0)
+ break;
+ err_printk(dev, entry,
+ "DMA-API: device driver failed to check
map err"
+ ": [count=%d]\n"
+ "Details of an entry with map error flag
set: "
+ "[device address=0x%016llx] [size=%llu
bytes] "
+ "[mapped with %s] [mapped as %s]\n",
+ count, entry->dev_addr, entry->size,
+ dir2name[entry->direction], type2name[entry->type]);
break;
--
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah...@samsung.com | (970) 672-0658
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/9] cpuidle: rework device state count handling
On Friday, December 20, 2013 07:47:22 PM Bartlomiej Zolnierkiewicz wrote: > Hi, > > Some cpuidle drivers assume that cpuidle core will handle cases where > device->state_count is smaller than driver->state_count, unfortunately > currently this is untrue (device->state_count is used only for handling > cpuidle state sysfs entries and driver->state_count is used for all > other cases) and will not be fixed in the future as device->state_count > is planned to be removed [1]. > > This patchset fixes such drivers (ARM EXYNOS cpuidle driver and ACPI > cpuidle driver), removes superflous device->state_count initialization > from drivers for which device->state_count equals driver->state_count > (POWERPC pseries cpuidle driver and intel_idle driver) and finally > removes state_count field from struct cpuidle_device. > > Additionaly (while at it) this patchset fixes C1E promotion disable > quirk handling (in intel_idle driver) and converts cpuidle drivers code > to use the common cpuidle_[un]register() routines (in POWERPC pseries > cpuidle driver and intel_idle driver). > > [1] http://permalink.gmane.org/gmane.linux.power-management.general/36908 > > Reference to v1: > http://comments.gmane.org/gmane.linux.power-management.general/37390 > > Changes since v1: > - synced patch series with next-20131220 > - added ACKs from Daniel Lezcano This series breaks boot on one of my test machines with intel_idle, so I'm not sure how well it has been tested. I've dropped it entirely for now. If I have the time, I will try to identify the root cause of the failure, but that may not happen before the merge window. Sorry about that. Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Bluetooth: Add hci_h4p driver
Hi!
> > +static inline void hci_h4p_handle_byte(struct hci_h4p_info *info, u8 byte)
>
> pretty big function to be inline
Called from just one place, so that should be ok.
> > +static void hci_h4p_rx_tasklet(unsigned long data)
> > +{
> []
> > + while (hci_h4p_inb(info, UART_LSR) & UART_LSR_DR) {
> []
> > + pr_debug("0x%.2x ", byte);
>
> pr_debug is prefixed by a newline if necessary
> and then <7>, one for each use.
>
> This will produce a lot of dmesg output lines
> (1 for each byte) and isn't in my opinion
> necessary/useful.
Ok, I just killed it.
> > + if (set != !!test_bit(H4P_ACTIVE_MODE, >pm_flags)) {
> > + bt_plat_data->set_pm_limits(info->dev, set);
> > + if (set)
> > + set_bit(H4P_ACTIVE_MODE, >pm_flags);
> > + else
> > + clear_bit(H4P_ACTIVE_MODE, >pm_flags);
> > + BT_DBG("Change pm constraints to: %s", sset);
>
> missing newline
Actually, it is the other way around. BT_DBG adds the newline. I'll
remove it from the rest.
> > + if (!hdev) {
> > + printk(KERN_WARNING "hci_h4p: Frame for unknown device\n");
> > + return -ENODEV;
> > + }
>
> Is this possible?
Probably not, removed.
> > + if (ret != 6)
> > + return -EINVAL;
> > +
> > + for (i = 0; i < 6; i++)
> > + info->bd_addr[i] = bdaddr[i] & 0xff;
>
> This could also return -EINVAL if bdaddr[i] > 0xff
Why not.
> > +static int hci_h4p_bcm_set_bdaddr(struct hci_h4p_info *info, struct
> > sk_buff *skb)
> > +{
> > + int i;
> > + static const u8 nokia_oui[3] = {0x00, 0x1f, 0xdf};
> > + int not_valid;
> > +
> > + not_valid = 1;
> > + for (i = 0; i < 6; i++) {
> > + if (info->bd_addr[i] != 0x00) {
> > + not_valid = 0;
> > + break;
> > + }
> > + }
>
> This seems wrong as addresses can have valid 0 bytes.
> Perhaps use:
>
> if (!is_valid_ether_addr(info->bd_addr))
>
I am not sure bluetooth rules are same as ethernet. And notice that it
only errors out on 00:00:00:00:00:00 which seems like invalid address
to me.
I fixed the other ones.
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHSET v3 driver-core-next] kernfs, sysfs, driver-core: implement synchronous self-removal
On Fri, Jan 10, 2014 at 07:08:56AM -0800, Greg KH wrote: > On Fri, Jan 10, 2014 at 08:57:17AM -0500, Tejun Heo wrote: > > Hello, > > > > This is v3 of kernfs self-removal patchset. v2 posting mistakenly > > sent out slightly old set of patches, so the v3. Sorry about the > > noise. Changes from the first take[L] are, > > It's really late in the -rc cycle for me to take this for 3.14, but I > see patch 1 is a good one to have, so I'll take that now, and queue the > rest up for after 3.14-rc1 is out for 3.15. Is that ok with you, or do > you have patches that depend on this series for 3.14? Oh nevermind, these are all good, now applied :) greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] APM
On Friday, January 10, 2014 11:50:08 AM Jiri Kosina wrote: > Rafael, > > please consider pulling > > git://git.kernel.org/pub/scm/linux/kernel/git/jikos/apm.git for-next > > into linux-pm.git, to receive: > > > - addition of hibernation events to apm-emulation, from Bin Shi > > > Thanks. > > Bin Shi (1): > apm-emulation: add hibernation APM events to support suspend2disk > > drivers/char/apm-emulation.c | 11 +-- > include/uapi/linux/apm_bios.h |2 ++ > 2 files changed, 11 insertions(+), 2 deletions(-) Pulled, thanks Jiri! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 3/3] dt-bindings: pci: xgene pcie device tree bindings
On Tue, Jan 7, 2014 at 7:35 AM, Arnd Bergmann wrote:
> On Tuesday 07 January 2014, Tanmay Inamdar wrote:
>> On Fri, Jan 3, 2014 at 1:49 AM, Arnd Bergmann wrote:
>> >> +Required properties:
>> >> +- status: Either "ok" or "disabled".
>> >> +- device_type: set to "pci"
>> >> +- compatible: should contain "xgene,pcie" to identify the core.
>> >> +- reg: base addresses and lengths of the pcie controller configuration
>> >> + space register.
>> >> +- #address-cells: set to <3>
>> >> +- #size-cells: set to <2>
>> >> +- ranges: ranges for the PCI memory, I/O regions, config and MSI regions
>> >> +- #interrupt-cells: set to <1>
>> >> +- interrupt-map-mask and interrupt-map: standard PCI properties
>> >> + to define the mapping of the PCIe interface to interrupt
>> >> + numbers.
>> >> +- clocks: from common clock binding: handle to pci clock.
>> >> +- clock-names: from common clock binding. Should be "pcieclk".
>> >> +
>> >
>> > Better use an anonymous clock?
>>
>> Sorry. Can you please elaborate?
>
> I mean drop the "clock-names" property.
>
Did you mean clock-names in pcie-clock node or pcie node? I can drop
clock-names from pcie clock node. However if I drop clock-names from
pcie node, then clk_get call from pcie host driver would result in
failure. Right?
>> >> +SoC specific DT Entry:
>> >> + pcie0: pcie@1f2b {
>> >> + status = "disabled";
>> >> + device_type = "pci";
>> >> + compatible = "xgene,pcie";
>> >> + #interrupt-cells = <1>;
>> >> + #size-cells = <2>;
>> >> + #address-cells = <3>;
>> >> + reg = < 0x00 0x1f2b 0x0 0x0001>;
>> >> + ranges = <0x0200 0x0 0x 0xe0 0x 0x0
>> >> 0x1000 /* mem*/
>> >
>> >
>> > Also, do you support no prefetchable memory?
>>
>> HW has either IO or Memory regions for mapping device's memory space.
>> There is no separate prefetchable memory space.
>
> Are you sure the memory is non-prefetchable then? I would have expected
> 0x4200 rather than 0x0200, but I could be misremembering it.
>
>> >
>> >> + 0x 0x0 0xd000 0xe0 0xd000 0x0
>> >> 0x0020 /* cfg */
>> >
>> > config space is not normally in the ranges property, and I think you will
>> > need
>> > it in the pcie node itself as a 'reg' property so the code can access it.
>>
>> pcie-designware.c does it that way. I just followed their implementation.
>
> I don't remember what led to that, it still seems wrong and I can't find
> anything
> in the PCI binding for host bridges telling their config space this way.
>
>> >> + interrupt-map-mask = <0x0 0x0 0x0 0x7>;
>> >> + interrupt-map = <0x0 0x0 0x0 0x1 0x0 0xc2 0x1>;
>> >
>> > Only one IRQ for all devices?
>>
>> The node represents a port. I believe that Linux framework uses only
>> one of the legacy IRQs per port. Rest all remain unused. Hence I
>> removed them. Please correct me if I am wrong.
>
> Any PCI device can normally have four interrupts (IntA through IntD), which
> are
> traditionally separate pins on a PCI bus, but get emulated on PCIe. While it's
> not common for any normal device to use more than one IRQ, a bridge device
> will swizzle these (virtual) IRQ lines, so a device behind the bridge actually
> gets a different host IRQ.
>
> 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/
Re: [PATCH] lib/vsprintf: add %pT format specifier
On Thu, 9 Jan 2014 21:52:00 +0900 Tetsuo Handa wrote: > This patch introduces %pT format specifier for printing task_struct->comm. > Currently %pT does not provide consistency. I'm planning to change to use RCU > in the future. By using RCU, the comm name read from task_struct->comm will be > guaranteed to be consistent. But before modifying set_task_comm() to use RCU, > we need to kill direct ->comm users who do not use get_task_comm(). On reflection... It isn't obvious that this patch is sufficiently beneficial until we have that RCU code in place. So I could retain this patch in -mm until we have that all sorted out. And I'll have to avoid merging %pT users into mainline in the meanwhile! Am I wrong? The patch seems fairly pointless as a standalone thing? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ACPI/SCAN: _STA status read
This patch adds a "status" attribute for an acpi device. This status
attribute shows the value of _STA object. The _STA object returns
current status of an ACPI device to show enabled, disabled or removed.
Signed-off-by: Srinivas Pandruvada
---
drivers/acpi/scan.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index fd39459..a5f4a60 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -567,6 +567,20 @@ acpi_device_sun_show(struct device *dev, struct
device_attribute *attr,
}
static DEVICE_ATTR(sun, 0444, acpi_device_sun_show, NULL);
+static ssize_t status_show(struct device *dev, struct device_attribute *attr,
+ char *buf) {
+ struct acpi_device *acpi_dev = to_acpi_device(dev);
+ acpi_status status;
+ unsigned long long sta;
+
+ status = acpi_evaluate_integer(acpi_dev->handle, "_STA", NULL, );
+ if (ACPI_FAILURE(status))
+ return -ENODEV;
+
+ return sprintf(buf, "%llu\n", sta);
+}
+static DEVICE_ATTR_RO(status);
+
static int acpi_device_setup_files(struct acpi_device *dev)
{
struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER, NULL};
@@ -622,6 +636,12 @@ static int acpi_device_setup_files(struct acpi_device *dev)
dev->pnp.sun = (unsigned long)-1;
}
+ if (acpi_has_method(dev->handle, "_STA")) {
+ result = device_create_file(>dev, _attr_status);
+ if (result)
+ goto end;
+ }
+
/*
* If device has _EJ0, 'eject' file is created that is used to trigger
* hot-removal function from userland.
@@ -677,6 +697,8 @@ static void acpi_device_remove_files(struct acpi_device
*dev)
device_remove_file(>dev, _attr_adr);
device_remove_file(>dev, _attr_modalias);
device_remove_file(>dev, _attr_hid);
+ if (acpi_has_method(dev->handle, "_STA"))
+ device_remove_file(>dev, _attr_status);
if (dev->handle)
device_remove_file(>dev, _attr_path);
}
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lib/vsprintf: add %pT format specifier
On Thu, 9 Jan 2014 21:52:00 +0900 Tetsuo Handa
wrote:
> Hello.
>
> Since addition of %pT itself seems to be agreed,
sort-of. The reason I suggested inventing a new token was code
density: avoid pointlessly passing current all the time.
Oh well, whatever - this patch has other intentions.
> I refreshed this patch using
> linux-next-20140109. Please pick up if this patch is OK for you; I will start
> making patches for killing most of direct ->comm readers.
>
> Regards.
>
> >From 0d1f03d59a477459f3d3c190593d9e78f5d67de8 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa
> Date: Thu, 9 Jan 2014 21:32:22 +0900
> Subject: [PATCH] lib/vsprintf: add %pT format specifier
>
> Since task_struct->comm can be modified by other threads while the current
> thread is reading it, it is recommended to use get_task_comm() for reading it.
>
> However, since get_task_comm() holds task_struct->alloc_lock spinlock,
> some users cannot use get_task_comm(). Also, a lot of users are directly
> reading from task_struct->comm even if they can use get_task_comm().
> Such users might obtain inconsistent result.
>
> This patch introduces %pT format specifier for printing task_struct->comm.
> Currently %pT does not provide consistency. I'm planning to change to use RCU
> in the future. By using RCU, the comm name read from task_struct->comm will be
> guaranteed to be consistent.
Not completely accurate - RCU won't protect code which accesses ->comm
from interrupts. Printing current->comm from irq is quite daft, but I
bet there's code that does it :(
As long as the kernel doesn't crash or otherwise misbehave when this
happens, I think we're OK.
(And I guess there's also non-daft code which accesses current->comm
from interrupt context: oops, panic, etc).
> But before modifying set_task_comm() to use RCU,
> we need to kill direct ->comm users who do not use get_task_comm().
>
> An example for converting direct ->comm users is shown below. Since many debug
> printings use p == current, you can pass NULL instead of p if p == current.
>
> pr_info("comm=%s\n", p->comm); => pr_info("comm=%pT\n", p);
> pr_info("comm=%s\n", current->comm); => pr_info("comm=%pT\n", NULL);
>
> Signed-off-by: Tetsuo Handa
> Reviewed-by: Pavel Machek
> ---
> Documentation/printk-formats.txt |6 ++
> lib/vsprintf.c | 20 +++-
> 2 files changed, 25 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/printk-formats.txt
> b/Documentation/printk-formats.txt
> index 6f4eb32..94459b4 100644
> --- a/Documentation/printk-formats.txt
> +++ b/Documentation/printk-formats.txt
> @@ -184,6 +184,12 @@ dentry names:
> equivalent of %s dentry->d_name.name we used to use, %pd prints
> n last components. %pD does the same thing for struct file.
>
> +task_struct comm name:
> +
> +%pT
> +
> +For printing task_struct->comm.
> +
> struct va_format:
>
> %pV
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 185b6d3..a97f18b 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -1179,6 +1179,21 @@ char *address_val(char *buf, char *end, const void
> *addr,
> return number(buf, end, num, spec);
> }
>
> +static noinline_for_stack
hm, does noinline_for_stack actually do anything useful here? I
suspect it *increases* stack depth in the way comm_name() is used here.
> +char *comm_name(char *buf, char *end, struct task_struct *tsk,
> + struct printf_spec spec, const char *fmt)
> +{
> + char name[TASK_COMM_LEN];
> +
> + /* Caller can pass NULL instead of current. */
> + if (!tsk)
> + tsk = current;
> + /* Not using get_task_comm() in case I'm in IRQ context. */
> + memcpy(name, tsk->comm, TASK_COMM_LEN);
> + name[sizeof(name) - 1] = '\0';
get_task_comm() uses strncpy()?
> + return string(buf, end, name, spec);
> +}
> +
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [RFCv4 05/11] Documentation: DT: omap-ssi binding documentation
Hi Tony, On Thu, Dec 19, 2013 at 11:03:44AM -0800, Tony Lindgren wrote: > > +Required properties: > > +- compatible: Should include "ti,omap3-ssi". > > +- reg-names: Contains the values "sys" and "gdd". > > Do you need the reg-names? The order won't change so you can just > document the order in the binding? The names are not needed, but I like self-documenting code/bindings. Also the examples in Documentation/devicetree/bindings/resource-names.txt look similar to this case. What do you have against the -names properties? The same statement goes for the following -names comments, so I will skip them ;) > [...] > > +- ti,ssi-cawake-gpio: Defines which GPIO pin is used to signify CAWAKE > > + events for the port. This is an optional board-specific > > + property. If it's missing the port will not be > > + enabled. > > Hmm this might be just a wake-up GPIO? If so, you should be able to > just set it up as an interrupt and do a request_irq on the pinctrl-single > entry for it. Yes, this gpio is used as interrupt in the driver, but its also read directly. I already considered making it an irq in the DT data (since its mainly used as irq), but I could not find out how to read the current status of an irq line. > It might even be one of the already mapped interrupt lines that the code is > remuxing to a GPIO for idle? If so, then you can just use the new binding > for interrupts-extended to handle the wake-up events. > > If you post the GPIO number for ti,ssi-cawake-gpio and the interrupt > numbers I can check if there's a need to handle it separately as a GPIO > pin or if it already can be automatically handled for the wake-up events. You can see it in one of the next patches, which adds the needed nodes in omap3-n900.dts. The used GPIO on N900 is 151 (gpio5 23) and I use the following pinmux configuration: 0x152 (PIN_INPUT | WAKEUP_EN | MUX_MODE4) P.S.: I intend to get this into 3.15. Before I will send an updated series, which uses the omap clock DT bindings as requested by DT binding maintainers. -- Sebastian signature.asc Description: Digital signature
VELGØRENHED BISTAND
VELGØRENHED BISTAND Hej Ven . Mens du læser dette , jeg vil have dig til at blive rørt , fordi jeg tror, at alle vil dø en dag. Mit navn er Rod Thompson, en købmand . Jeg er blevet diagnosticeret med kræft i spiserøret . Det har besmittet alle former for medicinsk behandling, og lige nu har jeg kun omkring et par måneder at leve i henhold til medicinske eksperter . Jeg har ikke særlig levet mit liv så godt, som jeg aldrig rigtig passet for nogen (ikke engang mig selv ), men min forretning. Selvom jeg er meget rig , var jeg aldrig gavmild , jeg kun fokuseret på min virksomhed , da det var det eneste, jeg plejet. Men nu jeg fortryder alt dette, som jeg ved nu, at der er mere i livet end bare ønsker at have eller gøre alle de penge i verden. Jeg tror, når Gud giver mig en chance for at komme til denne verden, jeg ville leve mit liv på en anden måde fra, hvordan jeg har levet det . Nu, Gud har kaldet mig, jeg har villet og givet det meste af min ejendom og aktiver til min umiddelbare og udvidede familiemedlemmer samt et par nære venner. Jeg ønsker Gud at være barmhjertig til mig og acceptere min sjæl, så jeg har besluttet at give almisser til velgørende organisationer , som jeg vil have det til at være en af de sidste gode gerninger , jeg gør på jorden. Nu, mit helbred er forværret så dårligt , kan jeg ikke gøre det selv længere. Jeg spurgte engang medlemmer af min familie at lukke en af mine konti og distribuere de penge, som jeg har der til velgørenhed organisation i Bulgarien og Pakistan , de nægtede og beholdt pengene til sig selv. Derfor behøver jeg ikke stoler på dem længere, som de synes ikke at være tilfreds med hvad jeg har tilbage for dem. Den sidste af mine penge , som ingen kender , er den enorme kontant depositum på 6 millioner euro. (Seks millioner euro) , som jeg har med en finansiel institution i Holland. Jeg vil have dig til at hjælpe mig at indsamle dette depositum og sendt det til velgørende organisationer , jeg har nævnt ovenfor. Jeg har afsat 15% for dig og for din tid. Gud være med dig . bedes du svar på min private e-mail : rodthompso...@aol.com Hilsen , Rod Thompson ( rodthompso...@aol.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 0/9] re-shrink 'struct page' when SLUB is on.
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. > So all this testing was performed in a VM? If so, how much is that > likely to have impacted the results? Nope, none of it was in a VM. All the results here are from bare-metal. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 Fri, 10 Jan 2014 12:52:32 -0800 Dave Hansen wrote:
> On 01/05/2014 08:32 PM, Joonsoo Kim wrote:
> > On Fri, Jan 03, 2014 at 02:18:16PM -0800, Andrew Morton wrote:
> >> On Fri, 03 Jan 2014 10:01:47 -0800 Dave Hansen wrote:
> >>> SLUB depends on a 16-byte cmpxchg for an optimization which
> >>> allows it to not disable interrupts in its fast path. This
> >>> optimization has some small but measurable benefits:
> >>>
> >>> http://lkml.kernel.org/r/52b345a3.6090...@sr71.net
> >>
> >> So really the only significant benefit from the cmpxchg16 is with
> >> cache-cold eight-byte kmalloc/kfree? 8% faster in this case? But with
> >> cache-hot kmalloc/kfree the benefit of cmpxchg16 is precisely zero.
> >
> > I guess that cmpxchg16 is not used in this cache-hot kmalloc/kfree test,
> > because kfree would be done in free fast-path. In this case,
> > this_cpu_cmpxchg_double() would be called, so you cannot find any effect
> > of cmpxchg16.
>
> That's a good point. I also confirmed this theory with the
> free_{fast,slow}path slub counters. So, I ran another round of tests.
>
> One important difference from the last round: I'm now writing to each
> allocation. I originally did this so that I could store the allocations
> in a linked-list, but I also realized that it's important. It's rare in
> practice to do an allocation and not write _something_ to it. This
> change adds a bit of cache pressure which changed the results pretty
> substantially.
>
> 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.
> There are a few important takeaways here:
> 1. The double-cmpxchg optimization has a measurable benefit
> 2. 64-byte 'struct page' is faster than the 56-byte one independent of
>the cmpxchg optimization. Maybe because foo/sizeof(struct page) is
>then a simple shift.
> 3. My new code is probably _slightly_ slower than the existing code,
>but still has the huge space savings
> 4. All of these deltas are greatly magnified here and are hard or
>impossible to demonstrate in practice.
>
> Why does the double-cmpxchg help? The extra cache references that it
> takes to go out and touch the paravirt structures and task struct to
> disable interrupts in the spinlock cases start to show up and hurt our
> allocation rates by about 30%.
So all this testing was performed in a VM? If so, how much is that
likely to have impacted the results?
> This advantage starts to evaporate when
> there is more noise in the caches, or when we start to run the tests
> across more cores.
>
> But the real question here is whether we can shrink 'struct page'. The
> existing (64-byte struct page) slub code wins on allocations under 256b
> by as much as 5% (the 32-byte kmalloc()), but my new code wins on
> allocations over 1k. 4k allocations just happen to be the most common
> on my systems, and they're also very near the "sweet spot" for the new
> code. But, the delta here is _much_ smaller that it was in the spinlock
> vs. cmpxchg cases. This advantage also evaporates when we run things
> across more cores or in less synthetic benchmarks.
>
> I also explored that 5% hit that my code caused in the 32-byte
> allocation case. It looked to me to be mostly explained by the code
> that I added. There were more instructions executed and the
> cycles-per-instruction went down. This looks to be mostly due to a ~15%
> increase in branch misses, probably from the increased code size and
> complexity.
>
> This is the perf stat output for a run doing 16.8M kmalloc(32)/kfree()'s:
> vanilla:
> >883,412 LLC-loads #0.296 M/sec
> > [39.76%]
> >566,546 LLC-load-misses # 64.13% of all LL-cache
> > hits[39.98%]
> patched:
> >556,751 LLC-loads #0.186 M/sec
> > [39.86%]
> >339,106 LLC-load-misses # 60.91% of all LL-cache
> > hits[39.72%]
>
> My best guess is that most of the LLC references are going out and
> touching the struct pages for slab management. It's why we see such a
> big change.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] Input: synaptics-rmi4 - split of transport ops into a separate structure
On 01/09/2014 11:44 PM, Dmitry Torokhov wrote:
Split off transport operations from rmi_transport_dev into a separate
structure that will be shared between all devices using the same transport
and use const pointer to access it.
Change signature on transport methods so that length is using the proper
tyep - size_t.
Also rename rmi_transport_info to rmi_transport_stats and move protocol
name (which is the only immutable piece of data there) into the transport
device itself.
Acked-by: Christopher Heiny
Signed-off-by: Dmitry Torokhov
---
drivers/input/rmi4/rmi_bus.h| 64 -
drivers/input/rmi4/rmi_driver.c | 8 +++---
drivers/input/rmi4/rmi_i2c.c| 49 ---
3 files changed, 67 insertions(+), 54 deletions(-)
diff --git a/drivers/input/rmi4/rmi_bus.h b/drivers/input/rmi4/rmi_bus.h
index 3e8b57a..ccf26dc 100644
--- a/drivers/input/rmi4/rmi_bus.h
+++ b/drivers/input/rmi4/rmi_bus.h
@@ -135,26 +135,25 @@ struct rmi_driver {
#define to_rmi_driver(d) \
container_of(d, struct rmi_driver, driver);
-/** struct rmi_transport_info - diagnostic information about the RMI transport
+/**
+ * struct rmi_transport_stats - diagnostic information about the RMI transport
* device, used in the xport_info debugfs file.
*
* @proto String indicating the protocol being used.
* @tx_count Number of transmit operations.
- * @tx_bytes Number of bytes transmitted.
* @tx_errs Number of errors encountered during transmit operations.
+ * @tx_bytes Number of bytes transmitted.
* @rx_count Number of receive operations.
- * @rx_bytes Number of bytes received.
* @rx_errs Number of errors encountered during receive operations.
- * @att_count Number of times ATTN assertions have been handled.
+ * @rx_bytes Number of bytes received.
*/
-struct rmi_transport_info {
- const char *proto;
- long tx_count;
- long tx_bytes;
- long tx_errs;
- long rx_count;
- long rx_bytes;
- long rx_errs;
+struct rmi_transport_stats {
+ unsigned long tx_count;
+ unsigned long tx_errs;
+ size_t tx_bytes;
+ unsigned long rx_count;
+ unsigned long rx_errs;
+ size_t rx_bytes;
};
/**
@@ -162,13 +161,14 @@ struct rmi_transport_info {
*
* @dev: Pointer to the communication device, e.g. i2c or spi
* @rmi_dev: Pointer to the RMI device
- * @write_block: Writing a block of data to the specified address
- * @read_block: Read a block of data from the specified address.
* @irq_thread: if not NULL, the sensor driver will use this instead of the
* default irq_thread implementation.
* @hard_irq: if not NULL, the sensor driver will use this for the hard IRQ
* handling
* @data: Private data pointer
+ * @proto_name: name of the transport protocol (SPI, i2c, etc)
+ * @ops: pointer to transport operations implementation
+ * @stats: transport statistics
*
* The RMI transport device implements the glue between different
communication
* buses such as I2C and SPI.
@@ -178,20 +178,30 @@ struct rmi_transport_dev {
struct device *dev;
struct rmi_device *rmi_dev;
- int (*write_block)(struct rmi_transport_dev *xport, u16 addr,
- const void *buf, const int len);
- int (*read_block)(struct rmi_transport_dev *xport, u16 addr,
- void *buf, const int len);
-
- int (*enable_device) (struct rmi_transport_dev *xport);
- void (*disable_device) (struct rmi_transport_dev *xport);
-
irqreturn_t (*irq_thread)(int irq, void *p);
irqreturn_t (*hard_irq)(int irq, void *p);
void *data;
- struct rmi_transport_info info;
+ const char *proto_name;
+ const struct rmi_transport_ops *ops;
+ struct rmi_transport_stats stats;
+};
+
+/**
+ * struct rmi_transport_ops - defines transport protocol operations.
+ *
+ * @write_block: Writing a block of data to the specified address
+ * @read_block: Read a block of data from the specified address.
+ */
+struct rmi_transport_ops {
+ int (*write_block)(struct rmi_transport_dev *xport, u16 addr,
+ const void *buf, size_t len);
+ int (*read_block)(struct rmi_transport_dev *xport, u16 addr,
+ void *buf, size_t len);
+
+ int (*enable_device) (struct rmi_transport_dev *xport);
+ void (*disable_device) (struct rmi_transport_dev *xport);
};
/**
@@ -232,7 +242,7 @@ bool rmi_is_physical_device(struct device *dev);
*/
static inline int rmi_read(struct rmi_device *d, u16 addr, void *buf)
{
- return d->xport->read_block(d->xport, addr, buf, 1);
+ return d->xport->ops->read_block(d->xport, addr, buf, 1);
}
/**
@@ -248,7 +258,7 @@ static inline int rmi_read(struct rmi_device *d, u16 addr,
void *buf)
static inline int rmi_read_block(struct rmi_device *d, u16 addr, void *buf,
const int len)
Re: [PATCH 3/4] Input: synaptics-rmi4 - fix I2C functionality check
On 01/09/2014 11:44 PM, Dmitry Torokhov wrote:
When adapter does not support required functionality (I2C_FUNC_I2C) we were
returning 0 to the upper layers, making them believe that device bound
successfully.
Acked-by: Christopher Heiny
Signed-off-by: Dmitry Torokhov
---
drivers/input/rmi4/rmi_i2c.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/input/rmi4/rmi_i2c.c b/drivers/input/rmi4/rmi_i2c.c
index cdc8527..c176218 100644
--- a/drivers/input/rmi4/rmi_i2c.c
+++ b/drivers/input/rmi4/rmi_i2c.c
@@ -193,11 +193,10 @@ static int rmi_i2c_probe(struct i2c_client *client,
pdata->sensor_name ? pdata->sensor_name : "-no name-",
client->addr, pdata->attn_gpio);
- retval = i2c_check_functionality(client->adapter, I2C_FUNC_I2C);
- if (!retval) {
- dev_err(>dev, "i2c_check_functionality error %d.\n",
- retval);
- return retval;
+ if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
+ dev_err(>dev,
+ "adapter does not support required functionality.\n");
+ return -ENODEV;
}
if (pdata->gpio_config) {
--
Christopher Heiny
Senior Staff Firmware Engineer
Synaptics Incorporated
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] Input: synaptics-rmi4 - rework transport device allocation
On 01/09/2014 11:44 PM, Dmitry Torokhov wrote:
Instead of allocating common and private part of transport device
separately make private wrap common part and get rid of private data
pointer in the transport device.
Also rename rmi_i2c_data -> rmi_i2c_xport and data -> rmi_i2c.
Acked-by: Christopher Heiny
Signed-off-by: Dmitry Torokhov
---
drivers/input/rmi4/rmi_bus.h | 3 --
drivers/input/rmi4/rmi_i2c.c | 112 +--
2 files changed, 56 insertions(+), 59 deletions(-)
diff --git a/drivers/input/rmi4/rmi_bus.h b/drivers/input/rmi4/rmi_bus.h
index ccf26dc..decb479 100644
--- a/drivers/input/rmi4/rmi_bus.h
+++ b/drivers/input/rmi4/rmi_bus.h
@@ -165,7 +165,6 @@ struct rmi_transport_stats {
* default irq_thread implementation.
* @hard_irq: if not NULL, the sensor driver will use this for the hard IRQ
* handling
- * @data: Private data pointer
* @proto_name: name of the transport protocol (SPI, i2c, etc)
* @ops: pointer to transport operations implementation
* @stats: transport statistics
@@ -181,8 +180,6 @@ struct rmi_transport_dev {
irqreturn_t (*irq_thread)(int irq, void *p);
irqreturn_t (*hard_irq)(int irq, void *p);
- void *data;
-
const char *proto_name;
const struct rmi_transport_ops *ops;
struct rmi_transport_stats stats;
diff --git a/drivers/input/rmi4/rmi_i2c.c b/drivers/input/rmi4/rmi_i2c.c
index 40badf3..cdc8527 100644
--- a/drivers/input/rmi4/rmi_i2c.c
+++ b/drivers/input/rmi4/rmi_i2c.c
@@ -17,22 +17,25 @@
#define BUFFER_SIZE_INCREMENT 32
/**
- * struct rmi_i2c_data - stores information for i2c communication
+ * struct rmi_i2c_xport - stores information for i2c communication
+ *
+ * @xport: The transport interface structure
*
* @page_mutex: Locks current page to avoid changing pages in unexpected ways.
* @page: Keeps track of the current virtual page
- * @xport: Pointer to the transport interface
*
* @tx_buf: Buffer used for transmitting data to the sensor over i2c.
* @tx_buf_size: Size of the buffer
*/
-struct rmi_i2c_data {
+struct rmi_i2c_xport {
+ struct rmi_transport_dev xport;
+ struct i2c_client *client;
+
struct mutex page_mutex;
int page;
- struct rmi_transport_dev *xport;
u8 *tx_buf;
- int tx_buf_size;
+ size_t tx_buf_size;
};
#define RMI_PAGE_SELECT_REGISTER 0xff
@@ -52,10 +55,10 @@ struct rmi_i2c_data {
*
* Returns zero on success, non-zero on failure.
*/
-static int rmi_set_page(struct rmi_transport_dev *xport, u8 page)
+static int rmi_set_page(struct rmi_i2c_xport *rmi_i2c, u8 page)
{
- struct i2c_client *client = to_i2c_client(xport->dev);
- struct rmi_i2c_data *data = xport->data;
+ struct rmi_transport_dev *xport = _i2c->xport;
+ struct i2c_client *client = rmi_i2c->client;
u8 txbuf[2] = {RMI_PAGE_SELECT_REGISTER, page};
int retval;
@@ -70,37 +73,40 @@ static int rmi_set_page(struct rmi_transport_dev *xport, u8
page)
"%s: set page failed: %d.", __func__, retval);
return (retval < 0) ? retval : -EIO;
}
- data->page = page;
+ rmi_i2c->page = page;
return 0;
}
static int rmi_i2c_write_block(struct rmi_transport_dev *xport, u16 addr,
const void *buf, size_t len)
{
- struct i2c_client *client = to_i2c_client(xport->dev);
- struct rmi_i2c_data *data = xport->data;
+ struct rmi_i2c_xport *rmi_i2c =
+ container_of(xport, struct rmi_i2c_xport, xport);
+ struct i2c_client *client = rmi_i2c->client;
size_t tx_size = len + 1;
int retval;
- mutex_lock(>page_mutex);
-
- if (!data->tx_buf || data->tx_buf_size < tx_size) {
- if (data->tx_buf)
- devm_kfree(>dev, data->tx_buf);
- data->tx_buf_size = tx_size + BUFFER_SIZE_INCREMENT;
- data->tx_buf = devm_kzalloc(>dev, data->tx_buf_size,
- GFP_KERNEL);
- if (!data->tx_buf) {
- data->tx_buf_size = 0;
+ mutex_lock(_i2c->page_mutex);
+
+ if (!rmi_i2c->tx_buf || rmi_i2c->tx_buf_size < tx_size) {
+ if (rmi_i2c->tx_buf)
+ devm_kfree(>dev, rmi_i2c->tx_buf);
+ rmi_i2c->tx_buf_size = tx_size + BUFFER_SIZE_INCREMENT;
+ rmi_i2c->tx_buf = devm_kzalloc(>dev,
+ rmi_i2c->tx_buf_size,
+ GFP_KERNEL);
+ if (!rmi_i2c->tx_buf) {
+ rmi_i2c->tx_buf_size = 0;
retval = -ENOMEM;
goto exit;
}
}
- data->tx_buf[0] = addr & 0xff;
- memcpy(data->tx_buf + 1, buf, len);
- if (RMI_I2C_PAGE(addr) != data->page) {
- retval
Re: [PATCH 4/4] Input: synaptics-rmi4 - switch to using i2c_transfer()
On 01/09/2014 11:44 PM, Dmitry Torokhov wrote:
Instead of using 2 separate transactions when reading from the device let's
use i2c_transfer. Because we now have single point of failure I had to
change how we collect statistics. I elected to drop control data from the
stats and only track number of bytes read/written for the device data.
Also, since we are not prepared to deal with short reads and writes change
read_block_data and write_block_data to indicate error if we detect short
transfers.
We tried this change once before a couple of years ago, but the
conversion was unsuccessful on some older platforms. I've tested it on
some more current platforms, though, and it works there. The old
platforms are running 2.6.xx series kernels, and don't look likely ever
to be updated, So
Acked-by: Christopher Heiny
Signed-off-by: Dmitry Torokhov
---
drivers/input/rmi4/rmi_i2c.c | 71
1 file changed, 39 insertions(+), 32 deletions(-)
diff --git a/drivers/input/rmi4/rmi_i2c.c b/drivers/input/rmi4/rmi_i2c.c
index c176218..51f5bc8 100644
--- a/drivers/input/rmi4/rmi_i2c.c
+++ b/drivers/input/rmi4/rmi_i2c.c
@@ -57,22 +57,17 @@ struct rmi_i2c_xport {
*/
static int rmi_set_page(struct rmi_i2c_xport *rmi_i2c, u8 page)
{
- struct rmi_transport_dev *xport = _i2c->xport;
struct i2c_client *client = rmi_i2c->client;
u8 txbuf[2] = {RMI_PAGE_SELECT_REGISTER, page};
int retval;
- dev_dbg(>dev, "writes 3 bytes: %02x %02x\n",
- txbuf[0], txbuf[1]);
- xport->stats.tx_count++;
- xport->stats.tx_bytes += sizeof(txbuf);
retval = i2c_master_send(client, txbuf, sizeof(txbuf));
if (retval != sizeof(txbuf)) {
- xport->stats.tx_errs++;
dev_err(>dev,
"%s: set page failed: %d.", __func__, retval);
return (retval < 0) ? retval : -EIO;
}
+
rmi_i2c->page = page;
return 0;
}
@@ -107,22 +102,27 @@ static int rmi_i2c_write_block(struct rmi_transport_dev
*xport, u16 addr,
if (RMI_I2C_PAGE(addr) != rmi_i2c->page) {
retval = rmi_set_page(rmi_i2c, RMI_I2C_PAGE(addr));
- if (retval < 0)
+ if (retval)
goto exit;
}
+ retval = i2c_master_send(client, rmi_i2c->tx_buf, tx_size);
+ if (retval == tx_size)
+ retval = 0;
+ else if (retval >= 0)
+ retval = -EIO;
+
+exit:
dev_dbg(>dev,
- "writes %zd bytes at %#06x: %*ph\n", len, addr, (int)len, buf);
+ "write %zd bytes at %#06x: %d (%*ph)\n",
+ len, addr, retval, (int)len, buf);
xport->stats.tx_count++;
- xport->stats.tx_bytes += tx_size;
- retval = i2c_master_send(client, rmi_i2c->tx_buf, tx_size);
- if (retval < 0)
+ if (retval)
xport->stats.tx_errs++;
else
- retval--; /* don't count the address byte */
+ xport->stats.tx_bytes += len;
-exit:
mutex_unlock(_i2c->page_mutex);
return retval;
}
@@ -133,40 +133,47 @@ static int rmi_i2c_read_block(struct rmi_transport_dev
*xport, u16 addr,
struct rmi_i2c_xport *rmi_i2c =
container_of(xport, struct rmi_i2c_xport, xport);
struct i2c_client *client = rmi_i2c->client;
- u8 txbuf[1] = {addr & 0xff};
+ u8 addr_offset = addr & 0xff;
int retval;
+ struct i2c_msg msgs[] = {
+ {
+ .addr = client->addr,
+ .len= sizeof(addr_offset),
+ .buf= _offset,
+ },
+ {
+ .addr = client->addr,
+ .flags = I2C_M_RD,
+ .len= len,
+ .buf= buf,
+ },
+ };
mutex_lock(_i2c->page_mutex);
if (RMI_I2C_PAGE(addr) != rmi_i2c->page) {
retval = rmi_set_page(rmi_i2c, RMI_I2C_PAGE(addr));
- if (retval < 0)
+ if (retval)
goto exit;
}
- dev_dbg(>dev, "writes 1 bytes: %02x\n", txbuf[0]);
+ retval = i2c_transfer(client->adapter, msgs, sizeof(msgs));
+ if (retval == sizeof(msgs))
+ retval = 0; /* success */
+ else if (retval >= 0)
+ retval = -EIO;
- xport->stats.tx_count++;
- xport->stats.tx_bytes += sizeof(txbuf);
- retval = i2c_master_send(client, txbuf, sizeof(txbuf));
- if (retval != sizeof(txbuf)) {
- xport->stats.tx_errs++;
- retval = (retval < 0) ? retval : -EIO;
- goto exit;
- }
+exit:
+ dev_dbg(>dev,
+ "read %zd bytes at %#06x: %d (%*ph)\n",
+ len, addr, retval, (int)len, buf);
xport->stats.rx_count++;
-
Re: [PATCH 2/2] PCI: Only enable realloc auto when root bus has 64bit mmio
On Fri, Jan 10, 2014 at 1:54 PM, Joseph Salisbury wrote: > On 01/10/2014 12:13 PM, Yinghai Lu wrote: > > In a prior email you mentioned: "Yes, if that works, we would not need > to put the patch in upstream for limiting realloc auto scope." Is the > git tree at > git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git > somehow different now? but you boot with "pci=realloc=off", right? Anyway please try pci/next to see if there is any help. git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/next -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] hwmon: (sht15) add include guard
On 01/10/2014 01:44 PM, Vivien Didelot wrote:
Add include guard to include/linux/platform_data/sht15.h to prevent
multiple inclusion.
Signed-off-by: Vivien Didelot
---
Applied to hwmon-next.
Thanks,
Guenter
include/linux/platform_data/sht15.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/platform_data/sht15.h
b/include/linux/platform_data/sht15.h
index 33e0fd2..12289c1 100644
--- a/include/linux/platform_data/sht15.h
+++ b/include/linux/platform_data/sht15.h
@@ -12,6 +12,9 @@
* For further information, see the Documentation/hwmon/sht15 file.
*/
+#ifndef _PDATA_SHT15_H
+#define _PDATA_SHT15_H
+
/**
* struct sht15_platform_data - sht15 connectivity info
* @gpio_data:no. of gpio to which bidirectional data line is
@@ -31,3 +34,5 @@ struct sht15_platform_data {
bool no_otp_reload;
bool low_resolution;
};
+
+#endif /* _PDATA_SHT15_H */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 01/10/2014 01:10 PM, 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. > Signed-off-by: Johannes Weiner Reviewed-by: Rik van Riel -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] hwmon: (max197) add include guard
On 01/10/2014 01:44 PM, Vivien Didelot wrote:
Add include guard to include/linux/platform_data/max197.h to prevent
multiple inclusion.
Signed-off-by: Vivien Didelot
---
Applied to hwmon-next.
Thanks,
Guenter
include/linux/platform_data/max197.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/platform_data/max197.h
b/include/linux/platform_data/max197.h
index e2a41dd..8da8f94 100644
--- a/include/linux/platform_data/max197.h
+++ b/include/linux/platform_data/max197.h
@@ -11,6 +11,9 @@
* For further information, see the Documentation/hwmon/max197 file.
*/
+#ifndef _PDATA_MAX197_H
+#define _PDATA_MAX197_H
+
/**
* struct max197_platform_data - MAX197 connectivity info
* @convert: Function used to start a conversion with control byte ctrl.
@@ -19,3 +22,5 @@
struct max197_platform_data {
int (*convert)(u8 ctrl);
};
+
+#endif /* _PDATA_MAX197_H */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Unable to load modules from 9p filesystem with kmod 16
Wakko Warner wrote:
> Kernel 3.12.7 from kernel.org
> With kmod-16, I'm unable to load any modules on my guest kvm machines.
> The vm is booted via direct kernel boot. The modules are located on the
> host and is passed to the guest via the fsdev.
>
> I have a mountpoint on the guest filesystem located at /kernel. It is
> mounted like this:
> kernel /kernel 9p rw,sync,dirsync,relatime,trans=virtio,version=9p2000.L 0 0
>
> /boot, /lib/modules, and /lib/firmware are tmpfs filesystems like this:
> kboot /boot tmpfs rw,relatime,size=0k,nr_inodes=8 0 0
> kfirmware /lib/firmware tmpfs rw,relatime,size=0k,nr_inodes=8 0 0
> kmodules /lib/modules tmpfs rw,relatime,size=0k,nr_inodes=8 0 0
>
> /lib/modules/$(uname -r) is a symlink to /kernel/lib/modules/$(uname -r)
>
> When trying to load any module, I get
> Error: could not insert module /lib/modules/3.12.7/kernel/crypto/af_alg.ko:
> Invalid module format
>
> This module was just one I picked at random, all modules fail the same way.
> Strace shows this:
> open("/lib/modules/3.12.7/kernel/crypto/af_alg.ko", O_RDONLY|O_CLOEXEC) = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=13822, ...}) = 0
> mmap(NULL, 13822, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f199aebd000
> syscall_313(0x3, 0x7f199aaa2de0, 0, 0x3, 0, 0x7f199b7b2010, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = -1 (errno 8)
> munmap(0x7f199aebd000, 13822) = 0
> close(3)= 0
>
> If I use kmod-9, it works w/o problems. An strace of kmod-9 shows:
> open("/lib/modules/3.12.7/kernel/crypto/af_alg.ko", O_RDONLY|O_CLOEXEC) = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=13822, ...}) = 0
> mmap(NULL, 13822, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f658ba41000
> init_module(0x7f658ba41000, 13822, "") = 0
> munmap(0x7f658ba41000, 13822) = 0
> close(3)= 0
>
> If I copy the module to /tmp, kmod-16 loads it just fine. It appears to be
> related to the 9p filesystem.
>
> I won't rule out a bug in kmod-16, but I was unable to figure out what the
> cause of the error was. I tried to search through kmod's source and the
> kernel source, but I gave up because I don't understand what's going on.
I did some testing with the various kmod versions between kmod-9 and 16.
The problem was introduced in 13. The change that broke this was the
addition of finit_module(). Appears that the kernel cannot handle modules
that is on the 9p filesystem. On the line that checked err == 0 (around
line libkmod-module.c:823), I added a test for ENOEXEC. The finit_module
still fails,but it uses the old method and works.
I would say from what I've seen, the problem is in the kernel for
finit_module(). I don't know enough about the kernel to go any further.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] LED fix for 3.13
My email was bounced back by LKML and Linux LED mail list. I forget to use plain text mode. So I forward it again. Thanks, -Bryan On Fri, Jan 10, 2014 at 2:57 PM, Bryan Wu wrote: > > Hi Linus, > > Pali Rohár and Pavel Machek reported the LED of Nokia N900 doesn't work with > our latest 3.13-rc6 kernel. Milo fixed the regression here. > > So please consider the following changes since commit > 802eee95bde72fd0cd0f3a5b2098375a487d1eda: > > Linux 3.13-rc6 (2013-12-29 16:01:33 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds.git > leds-fixes-for-3.13 > > for you to fetch changes up to e70988d1aaf73221355e06125c9937bd4b27761c: > > leds: lp5521/5523: Remove duplicate mutex (2014-01-10 14:48:07 -0800) > > > Milo Kim (1): > leds: lp5521/5523: Remove duplicate mutex > > drivers/leds/leds-lp5521.c | 12 > drivers/leds/leds-lp5523.c | 12 > 2 files changed, 8 insertions(+), 16 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Staging: rtl8188eu: Fixed whitespace related coding style issues
This patch fixes two spaces at the start of the line aswell as all space after
opening parenthesis and space before closeing parenthesis checkpatch.pl warnings
in rtw_mlme.h
Signed-off-by: Tim Jester-Pfadt
---
drivers/staging/rtl8188eu/include/rtw_mlme.h | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/rtl8188eu/include/rtw_mlme.h
b/drivers/staging/rtl8188eu/include/rtw_mlme.h
index 33965ca..144f79c 100644
--- a/drivers/staging/rtl8188eu/include/rtw_mlme.h
+++ b/drivers/staging/rtl8188eu/include/rtw_mlme.h
@@ -129,17 +129,17 @@ struct rt_link_detect {
struct profile_info {
u8 ssidlen;
- u8 ssid[ WLAN_SSID_MAXLEN ];
- u8 peermac[ ETH_ALEN ];
+ u8 ssid[WLAN_SSID_MAXLEN];
+ u8 peermac[ETH_ALEN];
};
struct tx_invite_req_info {
u8 token;
u8 benable;
- u8 go_ssid[ WLAN_SSID_MAXLEN ];
+ u8 go_ssid[WLAN_SSID_MAXLEN];
u8 ssidlen;
- u8 go_bssid[ ETH_ALEN ];
- u8 peer_macaddr[ ETH_ALEN ];
+ u8 go_bssid[ETH_ALEN];
+ u8 peer_macaddr[ETH_ALEN];
u8 operating_ch; /* This information will be set by using the
* p2p_set op_ch=x */
u8 peer_ch;/* The listen channel for peer P2P device */
@@ -182,9 +182,9 @@ struct tx_nego_req_info {
};
struct group_id_info {
- u8 go_device_addr[ ETH_ALEN ]; /* The GO's device address of
+ u8 go_device_addr[ETH_ALEN]; /* The GO's device address of
* this P2P group */
- u8 ssid[ WLAN_SSID_MAXLEN ]; /* The SSID of this P2P group */
+ u8 ssid[WLAN_SSID_MAXLEN]; /* The SSID of this P2P group */
};
struct scan_limit_info {
@@ -388,7 +388,7 @@ struct mlme_priv {
u8 *assoc_rsp;
u32 assoc_rsp_len;
-#if defined (CONFIG_88EU_AP_MODE)
+#if defined(CONFIG_88EU_AP_MODE)
/* Number of associated Non-ERP stations (i.e., stations using 802.11b
* in 802.11g BSS) */
int num_sta_non_erp;
@@ -472,7 +472,7 @@ void rtw_join_timeout_handler(void *FunctionContext);
void _rtw_scan_timeout_handler(void *FunctionContext);
void rtw_free_network_queue(struct adapter *adapter, u8 isfreeall);
int rtw_init_mlme_priv(struct adapter *adapter);
-void rtw_free_mlme_priv (struct mlme_priv *pmlmepriv);
+void rtw_free_mlme_priv(struct mlme_priv *pmlmepriv);
int rtw_select_and_join_from_scanned_queue(struct mlme_priv *pmlmepriv);
int rtw_set_key(struct adapter *adapter, struct security_priv *psecuritypriv,
int keyid, u8 set_tx);
@@ -572,7 +572,7 @@ struct wlan_network *rtw_get_oldest_wlan_network(struct
__queue *scanned_queue);
void rtw_free_assoc_resources(struct adapter *adapter, int lock_scanned_queue);
void rtw_indicate_disconnect(struct adapter *adapter);
void rtw_indicate_connect(struct adapter *adapter);
-void rtw_indicate_scan_done( struct adapter *padapter, bool aborted);
+void rtw_indicate_scan_done(struct adapter *padapter, bool aborted);
void rtw_scan_abort(struct adapter *adapter);
int rtw_restruct_sec_ie(struct adapter *adapter, u8 *in_ie, u8 *out_ie,
@@ -588,7 +588,7 @@ void rtw_get_encrypt_decrypt_from_registrypriv(struct
adapter *adapter);
void _rtw_join_timeout_handler(struct adapter *adapter);
void rtw_scan_timeout_handler(struct adapter *adapter);
- void rtw_dynamic_check_timer_handlder(struct adapter *adapter);
+void rtw_dynamic_check_timer_handlder(struct adapter *adapter);
#define rtw_is_scan_deny(adapter) false
#define rtw_clear_scan_deny(adapter) do {} while (0)
#define rtw_set_scan_deny_timer_hdl(adapter) do {} while (0)
@@ -605,7 +605,7 @@ int _rtw_enqueue_network(struct __queue *queue, struct
wlan_network *pnetwork);
struct wlan_network *_rtw_dequeue_network(struct __queue *queue);
- struct wlan_network *_rtw_alloc_network(struct mlme_priv *pmlmepriv);
+struct wlan_network *_rtw_alloc_network(struct mlme_priv *pmlmepriv);
void _rtw_free_network(struct mlme_priv *pmlmepriv,
--
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 8/9] lib: radix_tree: tree node interface
On 01/10/2014 01:10 PM, Johannes Weiner wrote: > Make struct radix_tree_node part of the public interface and provide > API functions to create, look up, and delete whole nodes. Refactor > the existing insert, look up, delete functions on top of these new > node primitives. > > This will allow the VM to track and garbage collect page cache radix > tree nodes. > > Signed-off-by: Johannes Weiner Reviewed-by: Rik van Riel -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Xen-devel] [PATCH] xen-blkfront: remove type check from blkfront_setup_discard
On 01/10/2014 05:49 PM, Olaf Hering wrote: On Fri, Jan 10, Boris Ostrovsky wrote: I think we should at clear feature_discard and print an error in the log if *either* of xenbus_gather() calls fail. Are you sure about that? AFAIK many other properties are optional as well. I dont think there is a formal spec about the discard related properties. Should every backend be required to provide all four properties? It's not whether the properties are required or not. It's that they may have been set by the admin but we ignored them. I am particularly concerned about security setting. Can you determine from the error whether the call failed or the property wasn't available? Alternatively, we may have to require the toolstack that if feature-discard is provided then all three of these are provided as well. And then you disable discard on any error. -boris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 01/10/2014 01:10 PM, Johannes Weiner wrote: > 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: Rik van Riel -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Xen-devel] [PATCH] xen-blkfront: remove type check from blkfront_setup_discard
On Fri, Jan 10, Boris Ostrovsky wrote: > I think we should at clear feature_discard and print an error in the log if > *either* of xenbus_gather() calls fail. Are you sure about that? AFAIK many other properties are optional as well. I dont think there is a formal spec about the discard related properties. Should every backend be required to provide all four properties? Olaf -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 Sun, Jan 5, 2014 at 12:48 PM, Ravi Patel wrote: > On Sun, Jan 5, 2014 at 10:11 AM, Arnd Bergmann wrote: >> On Sunday 05 January 2014, Ravi Patel wrote: >>> On Sat, Dec 21, 2013 at 11:03 PM, Arnd Bergmann wrote: >>> > >>> > Please describe here what the purpose of the qmtm is, as this is not >>> > entirely clear from the code or from your reply. >>> > >>> > Greg was guessing that it's a bus controller, my best guess is a DMA >>> > engine. If it's something completely different, you have to let >>> > us know what it is so we can do a proper review rather than guessing. >>> > >>> > Please provide a link to the data sheet if you are unable to explain. >>> >>> Here is URL to a text document explaining role of QMTM device with CPU, >>> Ethernet >>> subsystem. >>> >>> https://drive.google.com/file/d/0B28TgQZ3JLoRRGNnbjJoUGNHWW8/edit?usp=sharing >>> >>> For simplicity, I have shown only Ethernet. >>> PktDMA and Security subsystem interfaces with QMTM in the same way as >>> Ethernet. >> >> Thanks, that helps a lot. Please add this file to an appropriate place >> in the Documentation directory in the next version of your patches. >> >> There is still one central aspect that remains unclear to me, which is >> what the QMTM is actually good for, as opposed to how it gets used from >> the OS. > > The document shows the run-time flow of messages between CPU, QMTM and > Ethernet. > QMTM is a centralized resource manager/driver which exports APIs to > 1. Initialize & allocate queue & pbn to the Ethernet, PktDMA and > Security subsystem. > 2. Read queue state so that subsystems driver knows how much more work > it can offload > to its subsystem. > 3. Apply QoS for subsystems on their queues. > >> In the text description, it sounds like the ethernet is the DMA >> master and performs DMA all by itself but from that it's not clear why >> a message to and from the QMTM is needed. From your drawing on the other >> hand, it seems like the QMTM is really the DMA master and performs the >> DMA on behalf of the ethernet device, which isn't connected to the >> coherent interface itself. If this is correct, it seems that QMTM is more >> like a DMA engine after all that should use the existing slave API to >> provide services to slave drivers. > > Each subsystem defines their own format of work message. > A message (or queue descriptor) has attribute fields (QMTM specific) > which is common > for all subsystem work messages. > The remaining fields of a message are specific to subsystem. > QMTM device doesn't have any knowledge of these subsystem specific > fields and the data > operation which subsystem is going to perform using these fields. > e.g. > 1. Ethernet work message includes data address & length which is used > by Ethernet > DMA engine for copying the data to/from its internal FIFO > 2. PktDMA work message includes multiple data addresses & lengths for > doing scatter/gather, > XOR operations and result data address/es to give back result to the > CPU (driver) > 3. Security work message includes data address & length for doing > encryption or decryption, > the type of encryption or decryption and result data address to give > back result to the CPU (driver) 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] mm: thp: Add per-mm_struct flag to control THP
On Fri, Jan 10, 2014 at 11:10:10PM +0100, Peter Zijlstra wrote: > We already have the information to determine if a page is shared across > nodes, Mel even had some prototype code to do splits under those > conditions. I'm aware that we can determine if pages are shared across nodes, but I thought that Mel's code to split pages under these conditions had some performance issues. I know I've seen the code that Mel wrote to do this, but I can't seem to dig it up right now. Could you point me to it? - 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/
[PATCHv2] dt: binding documentation for bq2415x charger
Add devicetree binding documentation for bq2415x charger.
Signed-off-by: Sebastian Reichel
---
Hi,
This is the second version of the bq2415x binding documentation. The
only changes since PATCHv1 are a rewording of the property descriptions
as requested by Pavel Machek.
I narrowed down the CCs for this patch, since there were no comments on
PATCHv1 from omap or DT binding guys and Anton has applied the driver changes
already. This patch is intended for 3.14, so that it gets merged together
with the driver changes.
-- Sebastian
---
.../devicetree/bindings/power/bq2415x.txt | 48 ++
1 file changed, 48 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/bq2415x.txt
diff --git a/Documentation/devicetree/bindings/power/bq2415x.txt
b/Documentation/devicetree/bindings/power/bq2415x.txt
new file mode 100644
index 000..64f4a7f
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/bq2415x.txt
@@ -0,0 +1,48 @@
+Binding for TI bq2415x Li-Ion Charger
+
+Required properties:
+- compatible: Should contain one of the following:
+ * "ti,bq24150"
+ * "ti,bq24150"
+ * "ti,bq24150a"
+ * "ti,bq24151"
+ * "ti,bq24151a"
+ * "ti,bq24152"
+ * "ti,bq24153"
+ * "ti,bq24153a"
+ * "ti,bq24155"
+ * "ti,bq24156"
+ * "ti,bq24156a"
+ * "ti,bq24158"
+- reg:integer, i2c address of the device.
+- ti,current-limit: integer, initial maximum current charger can pull
+ from power supply in mA.
+- ti,weak-battery-voltage: integer, weak battery voltage threshold in mV.
+ The chip will use slow precharge if battery voltage
+ is below this value.
+- ti,battery-regulation-voltage: integer, maximum charging voltage in mV.
+- ti,charge-current: integer, maximum charging current in mA.
+- ti,termination-current: integer, charge will be terminated when current in
+ constant-voltage phase drops below this value (in
+ mA), charge is terminated.
+- ti,resistor-sense: integer, value of sensing resistor in milliohm.
+
+Optional properties:
+- ti,usb-charger-detection: phandle to usb charger detection device.
+ (required for auto mode)
+
+Example from Nokia N900:
+
+bq24150a {
+ compatible = "ti,bq24150a";
+ reg = <0x6b>;
+
+ ti,current-limit = <100>;
+ ti,weak-battery-voltage = <3400>;
+ ti,battery-regulation-voltage = <4200>;
+ ti,charge-current = <650>;
+ ti,termination-current = <100>;
+ ti,resistor-sense = <68>;
+
+ ti,usb-charger-detection = <>;
+};
--
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/2] mm, memcg: avoid oom notification when current needs access to memory reserves
On Fri, Jan 10, 2014 at 01:38:50PM -0800, David Rientjes wrote: > On Fri, 10 Jan 2014, Michal Hocko wrote: > > > I have already explained why I have acked it. I will not repeat > > it here again. I have also proposed an alternative solution > > (https://lkml.org/lkml/2013/12/12/174) which IMO is more viable because > > it handles both user/kernel memcg OOM consistently. This patch still has > > to be discussed because of other Johannes concerns. I plan to repost it > > in a near future. > > > > This three ring circus has to end. Really. > > 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. 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 6/6] arm64: add EFI runtime services
This patch adds EFI runtime support for arm64. The runtime support allows
the kernel to access various EFI runtime services provided by EFI firmware.
Things like reboot, real time clock, EFI boot variables, and others.
Signed-off-by: Mark Salter
---
arch/arm64/Kconfig | 16 ++
arch/arm64/include/asm/efi.h | 12 ++
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/efi.c | 353 +++
arch/arm64/kernel/setup.c| 6 +
include/linux/efi.h | 2 +-
6 files changed, 389 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/include/asm/efi.h
create mode 100644 arch/arm64/kernel/efi.c
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 3f1c2b2..862026d 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -249,6 +249,20 @@ config CMDLINE_FORCE
This is useful if you cannot or don't want to change the
command-line options your boot loader passes to the kernel.
+config EFI
+bool "EFI runtime service support"
+ depends on !ARM64_64K_PAGES && OF
+ select UCS2_STRING
+ select LIBFDT
+ select UEFI_PARAMS_FROM_FDT
+ help
+ This enables the kernel to use UEFI runtime services that are
+ available (such as the UEFI variable services).
+
+ This option is only useful on systems that have UEFI firmware.
+ However, even with this option, the resultant kernel should
+ continue to boot on existing non-UEFI platforms.
+
config EFI_STUB
bool "EFI stub support"
depends on !ARM64_64K_PAGES && OF
@@ -290,6 +304,8 @@ source "net/Kconfig"
source "drivers/Kconfig"
+source "drivers/firmware/Kconfig"
+
source "fs/Kconfig"
source "arch/arm64/kvm/Kconfig"
diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h
new file mode 100644
index 000..a835b2c
--- /dev/null
+++ b/arch/arm64/include/asm/efi.h
@@ -0,0 +1,12 @@
+#ifndef _ASM_ARM64_EFI_H
+#define _ASM_ARM64_EFI_H
+
+#include
+
+#ifdef CONFIG_EFI
+extern void efi_init(void);
+#else
+#define efi_init()
+#endif
+
+#endif /* _ASM_ARM64_EFI_H */
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 1c52b84..8897cf5a5 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -21,6 +21,7 @@ arm64-obj-$(CONFIG_HW_PERF_EVENTS)+= perf_event.o
arm64-obj-$(CONFIG_HAVE_HW_BREAKPOINT)+= hw_breakpoint.o
arm64-obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
arm64-obj-$(CONFIG_EFI_STUB) += efi-stub.o efi-entry.o
+arm64-obj-$(CONFIG_EFI)+= efi.o
obj-y += $(arm64-obj-y) vdso/
obj-m += $(arm64-obj-m)
diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
new file mode 100644
index 000..a42dc38
--- /dev/null
+++ b/arch/arm64/kernel/efi.c
@@ -0,0 +1,353 @@
+/*
+ * Extensible Firmware Interface
+ *
+ * Based on Extensible Firmware Interface Specification version 2.4
+ *
+ * Copyright (C) 2013 Linaro Ltd.
+ *
+ * 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
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+struct efi_memory_map memmap;
+
+static efi_runtime_services_t *runtime;
+
+static u64 efi_system_table;
+
+static unsigned long arm_efi_facility;
+
+/*
+ * Returns 1 if 'facility' is enabled, 0 otherwise.
+ */
+int efi_enabled(int facility)
+{
+ return test_bit(facility, _efi_facility) != 0;
+}
+EXPORT_SYMBOL(efi_enabled);
+
+static int uefi_debug __initdata;
+static int __init uefi_debug_setup(char *str)
+{
+ uefi_debug = 1;
+
+ return 0;
+}
+early_param("uefi_debug", uefi_debug_setup);
+
+static void __init efi_setup_idmap(void)
+{
+ unsigned long len;
+ struct memblock_region *r;
+
+ for_each_memblock(memory, r) {
+ /* section align addr/len */
+ len = ALIGN(r->size + (r->base & ~SECTION_MASK), SECTION_SIZE);
+ create_id_mapping(r->base & SECTION_MASK, len);
+ }
+}
+
+static int __init uefi_init(void)
+{
+ efi_char16_t *c16;
+ char vendor[100] = "unknown";
+ int i, retval;
+
+ efi.systab = early_memremap(efi_system_table,
+ sizeof(efi_system_table_t));
+ if (efi.systab == NULL) {
+ pr_warn("Unable to map EFI system table.\n");
+ return -ENOMEM;
+ }
+
+ set_bit(EFI_BOOT, _efi_facility);
+ set_bit(EFI_64BIT, _efi_facility);
+
+ /*
+* Verify the EFI Table
+*/
+ if (efi.systab->hdr.signature != EFI_SYSTEM_TABLE_SIGNATURE) {
+ pr_err("System table signature incorrect\n");
+ return -EINVAL;
+ }
+ if ((efi.systab->hdr.revision
[PATCH 0/6] arm64: Add EFI stub and runtime services support
This patch series adds EFI support to the arm64 kernel. This support has two main parts: an EFI stub and runtime support. The EFI stub support has the kernel masquerade as a PE/COFF application which can be directly booted by EFI firmware (or by secondary loaders with EFI support). The runtime services support provides access to various EFI firmware services such as reboot, real-time clock, boot variables, and others. Changes since v1: * Added Acks (well, one anyway) * The first 3 patches are new for v2 and provide more generic support for for following EFI patches. * Lots of changes based on feedback from Catalin mostly. I think I addressed all of his comments. These patches have dependencies on other patches which are not yet in the kernel but have been posted and are currently under review. In particular: - Generic fixmap support being discussed here: http://lkml.org/lkml/2013/11/25/474 This is now in the akpm tree - early_ioremap support being discussed here: https://lkml.org/lkml/2014/1/9/708 - shared EFI update_fdt() function in this series: http://news.gmane.org/gmane.linux.kernel.efi A repo with this patch series and the prerequisite patches is at: git://github.com/mosalter/linux.git (arm64-efi-patches-v2 branch) Mark Salter (6): efi: create memory map iteration helper arm64: Add function to create identity mappings efi: add helper function to get UEFI params from FDT arm64: add EFI stub doc: arm64: add description of EFI stub support arm64: add EFI runtime services Documentation/arm64/booting.txt | 4 + Documentation/efi-stub.txt | 12 +- arch/arm64/Kconfig | 26 +++ arch/arm64/include/asm/efi.h| 12 ++ arch/arm64/include/asm/mmu.h| 1 + arch/arm64/kernel/Makefile | 4 + arch/arm64/kernel/efi-entry.S | 93 +++ arch/arm64/kernel/efi-stub.c| 181 arch/arm64/kernel/efi.c | 353 arch/arm64/kernel/head.S| 112 + arch/arm64/kernel/setup.c | 6 + arch/arm64/mm/mmu.c | 34 ++-- drivers/firmware/efi/Kconfig| 7 + drivers/firmware/efi/efi.c | 79 + include/linux/efi.h | 17 +- 15 files changed, 927 insertions(+), 14 deletions(-) create mode 100644 arch/arm64/include/asm/efi.h create mode 100644 arch/arm64/kernel/efi-entry.S create mode 100644 arch/arm64/kernel/efi-stub.c create mode 100644 arch/arm64/kernel/efi.c -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/6] efi: create memory map iteration helper
There are a lot of places in the kernel which iterate through an EFI memory map. Most of these places use essentially the same for-loop code. This patch adds a for_each_efi_memory_desc() helper to clean up all of the existing duplicate code and avoid more in the future. Signed-off-by: Mark Salter --- include/linux/efi.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/include/linux/efi.h b/include/linux/efi.h index 11ce678..9dc5b05 100644 --- a/include/linux/efi.h +++ b/include/linux/efi.h @@ -618,6 +618,12 @@ extern int efi_set_rtc_mmss(const struct timespec *now); extern void efi_reserve_boot_services(void); extern struct efi_memory_map memmap; +/* Iterate through an efi_memory_map */ +#define for_each_efi_memory_desc(m, md) \ + for ((md) = (m)->map; \ +(md) <= (efi_memory_desc_t *)((m)->map_end - (m)->desc_size); \ +(md) = (void *)(md) + (m)->desc_size) + /** * efi_range_is_wc - check the WC bit on an address range * @start: starting kvirt address -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 6/9] mm + fs: store shadow entries in page cache
On 01/10/2014 01:10 PM, 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-by: Rik van Riel -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6] arm64: Add function to create identity mappings
At boot time, UEFI runtime support needs to call into the UEFI firmware
to switch to a virtual address map. This call must be made with UEFI
memory regions identity mapped. The exisitng early boot code creates
an identity map of kernel text/data but this is not sufficient for UEFI.
This patch adds a create_id_mapping() function which reuses the core
code of create_mapping() used to create the kernel RAM mappings.
Signed-off-by: Mark Salter
CC: Catalin Marinas
CC: Will Deacon
CC: linux-arm-ker...@lists.infradead.org
---
arch/arm64/include/asm/mmu.h | 1 +
arch/arm64/mm/mmu.c | 34 --
2 files changed, 25 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
index f600d40..9ad4dd4 100644
--- a/arch/arm64/include/asm/mmu.h
+++ b/arch/arm64/include/asm/mmu.h
@@ -28,5 +28,6 @@ extern void paging_init(void);
extern void setup_mm_for_reboot(void);
extern void __iomem *early_io_map(phys_addr_t phys, unsigned long virt);
extern void init_mem_pgprot(void);
+extern void create_id_mapping(phys_addr_t addr, phys_addr_t size);
#endif
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 7b345e3..ccfca44 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -228,22 +228,14 @@ static void __init alloc_init_pud(pgd_t *pgd, unsigned
long addr,
* Create the page directory entries and any necessary page tables for the
* mapping specified by 'md'.
*/
-static void __init create_mapping(phys_addr_t phys, unsigned long virt,
- phys_addr_t size)
+static void __init __create_mapping(pgd_t *pgd, phys_addr_t phys,
+ unsigned long virt, phys_addr_t size)
{
unsigned long addr, length, end, next;
- pgd_t *pgd;
-
- if (virt < VMALLOC_START) {
- pr_warning("BUG: not creating mapping for 0x%016llx at 0x%016lx
- outside kernel range\n",
- phys, virt);
- return;
- }
addr = virt & PAGE_MASK;
length = PAGE_ALIGN(size + (virt & ~PAGE_MASK));
- pgd = pgd_offset_k(addr);
end = addr + length;
do {
next = pgd_addr_end(addr, end);
@@ -252,6 +244,28 @@ static void __init create_mapping(phys_addr_t phys,
unsigned long virt,
} while (pgd++, addr = next, addr != end);
}
+static void __init create_mapping(phys_addr_t phys, unsigned long virt,
+ phys_addr_t size)
+{
+ if (virt < VMALLOC_START) {
+ pr_warn("BUG: not creating mapping for 0x%016llx at 0x%016lx -
outside kernel range\n",
+ phys, virt);
+ return;
+ }
+ __create_mapping(pgd_offset_k(virt & PAGE_MASK), phys, virt, size);
+}
+
+void __init create_id_mapping(phys_addr_t addr, phys_addr_t size)
+{
+ pgd_t *pgd = _pg_dir[pgd_index(addr)];
+
+ if (pgd >= _pg_dir[ARRAY_SIZE(idmap_pg_dir)]) {
+ pr_warn("BUG: not creating id mapping for 0x%016llx\n", addr);
+ return;
+ }
+ __create_mapping(pgd, addr, addr, size);
+}
+
static void __init map_mem(void)
{
struct memblock_region *reg;
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] doc: arm64: add description of EFI stub support
Add explanation of arm64 EFI stub and kernel image header changes needed to masquerade as a PE/COFF application. Signed-off-by: Mark Salter Acked-by: Grant Likely CC: linux-...@vger.kernel.org CC: Rob Landley --- Documentation/arm64/booting.txt | 4 Documentation/efi-stub.txt | 12 +--- 2 files changed, 13 insertions(+), 3 deletions(-) diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt index a9691cc..aa95d38c 100644 --- a/Documentation/arm64/booting.txt +++ b/Documentation/arm64/booting.txt @@ -85,6 +85,10 @@ The decompressed kernel image contains a 64-byte header as follows: Header notes: - code0/code1 are responsible for branching to stext. +- when booting through EFI, code0/code1 are initially skipped. + res5 is an offset to the PE header and the PE header has the EFI + entry point (efi_stub_entry). When the stub has done its work, it + jumps to code0 to resume the normal boot process. The image must be placed at the specified offset (currently 0x8) from the start of the system RAM and called there. The start of the diff --git a/Documentation/efi-stub.txt b/Documentation/efi-stub.txt index a55a0cd..d8ad0c1 100644 --- a/Documentation/efi-stub.txt +++ b/Documentation/efi-stub.txt @@ -12,6 +12,11 @@ arch/arm/boot/compressed/efi-header.S and arch/arm/boot/compressed/efi-stub.c. EFI stub code that is shared between architectures is in drivers/firmware/efi/efi-stub-helper.c. +For arm64, there is no compressed kernel support, so the Image itself +masquerades as a PE/COFF image and the EFI stub is linked into the +kernel. The arm64 EFI stub lives in arch/arm64/kernel/efi-entry.S +and arch/arm64/kernel/efi-stub.c. + By using the EFI boot stub it's possible to boot a Linux kernel without the use of a conventional EFI boot loader, such as grub or elilo. Since the EFI boot stub performs the jobs of a boot loader, in @@ -28,7 +33,8 @@ the extension the EFI firmware loader will refuse to execute it. It's not possible to execute bzImage.efi from the usual Linux file systems because EFI firmware doesn't have support for them. For ARM the arch/arm/boot/zImage should be copied to the system partition, and it -may not need to be renamed. +may not need to be renamed. Similarly for arm64, arch/arm64/boot/Image +should be copied but not necessarily renamed. Passing kernel parameters from the EFI shell @@ -72,7 +78,7 @@ is passed to bzImage.efi. The "dtb=" option -For the ARM architecture, we also need to be able to provide a device -tree to the kernel. This is done with the "dtb=" command line option, +For the ARM and arm64 architectures, we also need to be able to provide a +device tree to the kernel. This is done with the "dtb=" command line option, and is processed in the same manner as the "initrd=" option that is described above. -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xen-blkfront: remove type check from blkfront_setup_discard
On 01/10/2014 04:37 PM, Olaf Hering wrote:
On Fri, Jan 10, Boris Ostrovsky wrote:
If the call below fails, is it safe to continue using discard feature? At
the least, are discard_granularity and discard_alignment guaranteed to have
sane/safe values?
Its up to the toolstack to provide sane values. In the worst case
discard fails. In this specific case the three values are optional, so
the calls can fail. I do not know what happens if the backend device
actually needs the values, but the frontend can not send proper discard
requests. Hopefully it will not damage the hardware..
I don't know discard code works but it seems to me that if you pass, for
example, zero as discard_granularity (which may happen if
xenbus_gather() fails) then blkdev_issue_discard() in the backend will
set granularity to 1 and continue with discard. This may not be what the
the guest admin requested. And he won't know about this since no error
message is printed anywhere.
Similarly, if xenbug_gather("discard-secure") fails, I think the code
will assume that secure discard has not been requested. I don't know
what security implications this will have but it sounds bad to me.
I think we should at clear feature_discard and print an error in the log
if *either* of xenbus_gather() calls fail.
-boris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] openrisc: fix PTRS_PER_PGD define
On OpenRISC, with its 8k pages, PAGE_SHIFT is defined to be 13.
That makes the expression (1UL << (PAGE_SHIFT-2)) evaluate
to 2048.
The correct value for PTRS_PER_PGD should be 256.
Correcting the PTRS_PER_PGD define unveiled a bug in map_ram(),
where PTRS_PER_PGD was used when the intent was to iterate
over a set of page table entries.
This patch corrects that issue as well.
Signed-off-by: Stefan Kristiansson
---
arch/openrisc/include/asm/pgtable.h | 2 +-
arch/openrisc/mm/init.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/openrisc/include/asm/pgtable.h
b/arch/openrisc/include/asm/pgtable.h
index 37bf6a3..5630d03 100644
--- a/arch/openrisc/include/asm/pgtable.h
+++ b/arch/openrisc/include/asm/pgtable.h
@@ -69,7 +69,7 @@ extern void paging_init(void);
*/
#define PTRS_PER_PTE (1UL << (PAGE_SHIFT-2))
-#define PTRS_PER_PGD (1UL << (PAGE_SHIFT-2))
+#define PTRS_PER_PGD (1UL << (32-PGDIR_SHIFT))
/* calculate how many PGD entries a user-level program can use
* the first mappable virtual address is 0
diff --git a/arch/openrisc/mm/init.c b/arch/openrisc/mm/init.c
index 7f94652..b782ce9 100644
--- a/arch/openrisc/mm/init.c
+++ b/arch/openrisc/mm/init.c
@@ -110,7 +110,7 @@ static void __init map_ram(void)
set_pmd(pme, __pmd(_KERNPG_TABLE + __pa(pte)));
/* Fill the newly allocated page with PTE'S */
- for (j = 0; p < e && j < PTRS_PER_PGD;
+ for (j = 0; p < e && j < PTRS_PER_PTE;
v += PAGE_SIZE, p += PAGE_SIZE, j++, pte++) {
if (v >= (u32) _e_kernel_ro ||
v < (u32) _s_kernel_ro)
--
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: [RFC PATCH] mm: thp: Add per-mm_struct flag to control THP
On Fri, Jan 10, 2014 at 04:01:55PM -0600, Alex Thorlton wrote: > On Fri, Jan 10, 2014 at 10:23:10PM +0200, Kirill A. Shutemov wrote: > > Do you know what cause the difference? I prefer to fix THP instead of > > adding new knob to disable it. > > The issue is that when you touch 1 byte of an untouched, contiguous 2MB > chunk, a THP will be handed out, and the THP will be stuck on whatever > node the chunk was originally referenced from. If many remote nodes > need to do work on that same chunk, they'll be making remote accesses. > With THP disabled, 4K pages can be handed out to separate nodes as > they're needed, greatly reducing the amount of remote accesses to > memory. I think this problem *potentially* could be fixed by NUMA balancer. (Although, I don't really know how balancer works...) If we see NUMA hint faults for addresses in different 4k pages inside huge page from more then one node, we could split the huge page. Mel, is it possible? Do we collect enough info to make the decision? -- Kirill A. Shutemov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 Thu, Jan 09, 2014 at 04:23:50PM -0800, David Rientjes wrote: > On Thu, 9 Jan 2014, Andrew Morton wrote: > > > > > It was dropped because the other memcg developers disagreed with it. > > > > > > > > > > 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. > > And 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 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] mm: thp: Add per-mm_struct flag to control THP
On Fri, Jan 10, 2014 at 04:01:55PM -0600, Alex Thorlton wrote: > On Fri, Jan 10, 2014 at 10:23:10PM +0200, Kirill A. Shutemov wrote: > > Do you know what cause the difference? I prefer to fix THP instead of > > adding new knob to disable it. > > The issue is that when you touch 1 byte of an untouched, contiguous 2MB > chunk, a THP will be handed out, and the THP will be stuck on whatever > node the chunk was originally referenced from. If many remote nodes > need to do work on that same chunk, they'll be making remote accesses. > With THP disabled, 4K pages can be handed out to separate nodes as > they're needed, greatly reducing the amount of remote accesses to > memory. I give a bit better description here: > > https://lkml.org/lkml/2013/8/27/397 > > I had been looking into better ways to handle this issues, but after > spinning through a few other ideas: > > - Per cpuset flag to control THP: > https://lkml.org/lkml/2013/6/10/331 > > - Threshold to determine when to hand out THPs: > https://lkml.org/lkml/2013/12/12/394 > > We've arrived back here. Andrea seemed to think that this is an > acceptable approach to solve the problem, at least as a starting point: > > https://lkml.org/lkml/2013/12/17/397 > > I agree that we should, ideally, come up with a way to appropriately > handle this problem in the kernel, but as of right now, it appears that > that might be a rather large undertaking. We already have the information to determine if a page is shared across nodes, Mel even had some prototype code to do splits under those conditions. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/platform] arch: x86: New MailBox support driver for Intel SOC's
Commit-ID: 46184415368a6095d5da33991c5e011f1084353d Gitweb: http://git.kernel.org/tip/46184415368a6095d5da33991c5e011f1084353d Author: David E. Box AuthorDate: Wed, 8 Jan 2014 13:27:51 -0800 Committer: H. Peter Anvin CommitDate: Wed, 8 Jan 2014 14:36:29 -0800 arch: x86: New MailBox support driver for Intel SOC's Current Intel SOC cores use a MailBox Interface (MBI) to provide access to configuration registers on devices (called units) connected to the system fabric. This is a support driver that implements access to this interface on those platforms that can enumerate the device using PCI. Initial support is for BayTrail, for which port definitons are provided. This is a requirement for implementing platform specific features (e.g. RAPL driver requires this to perform platform specific power management using the registers in PUNIT). Dependant modules should select IOSF_MBI in their respective Kconfig configuraiton. Serialized access is handled by all exported routines with spinlocks. The API includes 3 functions for access to unit registers: int iosf_mbi_read(u8 port, u8 opcode, u32 offset, u32 *mdr) int iosf_mbi_write(u8 port, u8 opcode, u32 offset, u32 mdr) int iosf_mbi_modify(u8 port, u8 opcode, u32 offset, u32 mdr, u32 mask) port: indicating the unit being accessed opcode: the read or write port specific opcode offset: the register offset within the port mdr:the register data to be read, written, or modified mask: bit locations in mdr to change Returns nonzero on error Note: GPU code handles access to the GFX unit. Therefore access to that unit with this driver is disallowed to avoid conflicts. Signed-off-by: David E. Box Link: http://lkml.kernel.org/r/1389216471-734-1-git-send-email-david.e@linux.intel.com Signed-off-by: H. Peter Anvin Cc: Rafael J. Wysocki Cc: Matthew Garrett --- arch/x86/Kconfig| 8 ++ arch/x86/include/asm/iosf_mbi.h | 90 arch/x86/kernel/Makefile| 1 + arch/x86/kernel/iosf_mbi.c | 226 4 files changed, 325 insertions(+) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 0952ecd..ca5959a 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2393,6 +2393,14 @@ config X86_DMA_REMAP bool depends on STA2X11 +config IOSF_MBI + bool + depends on PCI + ---help--- + To be selected by modules requiring access to the Intel OnChip System + Fabric (IOSF) Sideband MailBox Interface (MBI). For MBI platforms + enumerable by PCI. + source "net/Kconfig" source "drivers/Kconfig" diff --git a/arch/x86/include/asm/iosf_mbi.h b/arch/x86/include/asm/iosf_mbi.h new file mode 100644 index 000..8e71c79 --- /dev/null +++ b/arch/x86/include/asm/iosf_mbi.h @@ -0,0 +1,90 @@ +/* + * iosf_mbi.h: Intel OnChip System Fabric MailBox access support + */ + +#ifndef IOSF_MBI_SYMS_H +#define IOSF_MBI_SYMS_H + +#define MBI_MCR_OFFSET 0xD0 +#define MBI_MDR_OFFSET 0xD4 +#define MBI_MCRX_OFFSET0xD8 + +#define MBI_RD_MASK0xFEFF +#define MBI_WR_MASK0X0100 + +#define MBI_MASK_HI0xFF00 +#define MBI_MASK_LO0x00FF +#define MBI_ENABLE 0xF0 + +/* Baytrail available units */ +#define BT_MBI_UNIT_AUNIT 0x00 +#define BT_MBI_UNIT_SMC0x01 +#define BT_MBI_UNIT_CPU0x02 +#define BT_MBI_UNIT_BUNIT 0x03 +#define BT_MBI_UNIT_PMC0x04 +#define BT_MBI_UNIT_GFX0x06 +#define BT_MBI_UNIT_SMI0x0C +#define BT_MBI_UNIT_USB0x43 +#define BT_MBI_UNIT_SATA 0xA3 +#define BT_MBI_UNIT_PCIE 0xA6 + +/* Baytrail read/write opcodes */ +#define BT_MBI_AUNIT_READ 0x10 +#define BT_MBI_AUNIT_WRITE 0x11 +#define BT_MBI_SMC_READ0x10 +#define BT_MBI_SMC_WRITE 0x11 +#define BT_MBI_CPU_READ0x10 +#define BT_MBI_CPU_WRITE 0x11 +#define BT_MBI_BUNIT_READ 0x10 +#define BT_MBI_BUNIT_WRITE 0x11 +#define BT_MBI_PMC_READ0x06 +#define BT_MBI_PMC_WRITE 0x07 +#define BT_MBI_GFX_READ0x00 +#define BT_MBI_GFX_WRITE 0x01 +#define BT_MBI_SMIO_READ 0x06 +#define BT_MBI_SMIO_WRITE 0x07 +#define BT_MBI_USB_READ0x06 +#define BT_MBI_USB_WRITE 0x07 +#define BT_MBI_SATA_READ 0x00 +#define BT_MBI_SATA_WRITE 0x01 +#define BT_MBI_PCIE_READ 0x00 +#define BT_MBI_PCIE_WRITE 0x01 + +/** + * iosf_mbi_read() - MailBox Interface read command + * @port: port indicating subunit being accessed + * @opcode:port specific read or write opcode + * @offset:register address offset + * @mdr: register data to be read + * + * Locking is handled by spinlock - cannot sleep. + * Return: Nonzero on error + */ +int iosf_mbi_read(u8 port, u8 opcode, u32 offset, u32 *mdr); + +/** + * iosf_mbi_write() - MailBox unmasked
[PATCHv3 1/6] Crashdump-Accepting-Active-IOMMU-Flags-and-Prototype
The following series implements a fix for:
A kdump problem about DMA that has been discussed for a long time. That is,
when a kernel panics and boots into the kdump kernel, DMA started by the
panicked kernel is not stopped before the kdump kernel is booted and the
kdump kernel disables the IOMMU while this DMA continues. This causes the
IOMMU to stop translating the DMA addresses as IOVAs and begin to treat them
as physical memory addresses -- which causes the DMA to either:
(1) generate DMAR errors or (2) generate PCI SERR errors or (3) transfer
data to or from incorrect areas of memory. Often this causes the dump to fail.
This patch set modifies the behavior of the iommu in the (new) crashdump kernel:
1. to accept the iommu hardware in an active state,
2. to leave the current translations in-place so that legacy DMA will continue
using its current buffers until the device drivers in the crashdump kernel
initialize and initialize their devices,
3. to use different portions of the iova address ranges for the device drivers
in the crashdump kernel than the iova ranges that were in-use at the time
of the panic.
4. to mark as in-use each domain-id that an IOMMU was using at the
time of the panic -- so that if the crashdump kernel contains a
device that was not in the panicked kernel (and therefore needs
a new domain-id) that device will be given an unused domain-id.
Advantages of this approach:
1. All manipulation of the IO-device is done by the Linux device-driver
for that device.
2. This approach behaves in a manner very similar to operation without an
active iommu.
3. Any activity between the IO-device and its RMRR areas is handled by the
device-driver in the same manner as during a non-kdump boot.
4. If an IO-device has no driver in the kdump kernel, it is simply left alone.
This supports the practice of creating a special kdump kernel without
drivers for any devices that are not required for taking a crashdump.
This patch contains global flags used by many sections of the code and
prototypes of the interface functions which are coded at the end of
the source file.
Static struct 'pr_dbg' contains bit-flags that control the amount of debug
print placed on the console. Note that the amount of print increases greatly
(probably geometrically if not faster) as additional bits further down the
structure are enabled. These flags and the pr_debug() lines scattered
throughout the code are only for the developer or analyst. At this time,
no means is provided to modify the flags without a re-compile.
v1->v2:
Updated patch description
v2->v3:
No change
Signed-off-by: Bill Sumner
---
drivers/iommu/intel-iommu.c | 75 +
1 file changed, 75 insertions(+)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 43b9bfe..17c4537 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -48,6 +48,7 @@
#include "irq_remapping.h"
#include "pci.h"
+#include
#define ROOT_SIZE VTD_PAGE_SIZE
#define CONTEXT_SIZE VTD_PAGE_SIZE
@@ -164,6 +165,80 @@ static inline unsigned long virt_to_dma_pfn(void *p)
return page_to_dma_pfn(virt_to_page(p));
}
+#ifdef CONFIG_CRASH_DUMP
+/* ===
+ * Crashdump Accepting Active IOMMU
+ * Enhances the crashdump kernel to deal with an active iommu
+ * and legacy DMA from the (old) panic'd kernel in a manner similar to how
+ * legacy DMA is handled when no hardware iommu was in use by the old kernel --
+ * allow the legacy DMA to continue into its current buffers.
+ *
+ * This code:
+ * 1. accepts the iommu hardware in an active state from the old kernel,
+ * 2. leaves the current translations in-place so that legacy DMA will
+ *continue to use its current buffers,
+ * 3. allocates to the device drivers in the crashdump kernel
+ *portions of the iova address ranges that are different
+ *from the iova address ranges that were being used by the old kernel
+ *at the time of the panic.
+ * ---
+ */
+
+/* Flags for Crashdump Accepting Active IOMMU */
+
+static int crashdump_accepting_active_iommu; /* activate this feature */
+static int intel_iommu_translation_tables_are_mapped; /* table copy done */
+
+static struct {/* run-time pr_debug() flags */
+ unsigned in_crashdump:1;/* if crashdump_accepting_active_iommu
*/
+ unsigned domain_get:1; /* pr_debug in domain_get* functions */
+ unsigned copy_page_table:1; /* enter/leave copy_page_table() */
+ unsigned copy_page_addr:1; /* enter/leave copy_page_addr() */
+ unsigned addr_ranges:1; /* accumulated addr ranges */
+ unsigned reserved_ranges:1; /* accumulated addr ranges reserved */
+ unsigned page_addr:1; /* adr(each page
[PATCHv3 2/6] Crashdump-Accepting-Active-IOMMU-Utility-functions
-.-.-.-.-.-.-.
Most of the code for Crashdump Accepting Active IOMMU is contained
in a large section at the end of intel-iommu.c -- beginning here.
This patch contains small utility functions used to access the
bit fields of the context entry, plus one to copy from a physically-
addressed area of memory (primarily pages from the panicked kernel)
into a virtually-addressed area within the crashdump kernel.
v1->v2:
Updated patch description
v2->v3:
No change
Signed-off-by: Bill Sumner
---
drivers/iommu/intel-iommu.c | 74 +
1 file changed, 74 insertions(+)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 17c4537..4172a2b 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -4455,3 +4455,77 @@ static void __init check_tylersburg_isoch(void)
printk(KERN_WARNING "DMAR: Recommended TLB entries for ISOCH unit is
16; your BIOS set %d\n",
vtisochctrl);
}
+#ifdef CONFIG_CRASH_DUMP
+
+/*
+ * Utility functions for accessing the iommu Translation Tables
+ *
+ */
+static inline struct context_entry *
+get_context_phys_from_root(struct root_entry *root)
+{
+ return (struct context_entry *)
+ (root_present(root) ? (void *) (root->val & VTD_PAGE_MASK)
+ : NULL);
+}
+
+static int
+context_get_p(struct context_entry *c){return((c->lo >> 0) & 0x1); }
+
+static int
+context_get_fpdi(struct context_entry *c) {return((c->lo >> 1) & 0x1); }
+
+static int
+context_get_t(struct context_entry *c){return((c->lo >> 2) & 0x3); }
+
+static u64
+context_get_asr(struct context_entry *c) {return((c->lo >> 12)); }
+
+static int
+context_get_aw(struct context_entry *c) {return((c->hi >> 0) & 0x7); }
+
+static int
+context_get_aval(struct context_entry *c) {return((c->hi >> 3) & 0xf); }
+
+static int
+context_get_did(struct context_entry *c) {return((c->hi >> 8) & 0x); }
+
+static void context_put_asr(struct context_entry *c, unsigned long asr)
+{
+ c->lo &= (~VTD_PAGE_MASK);
+ c->lo |= (asr << VTD_PAGE_SHIFT);
+}
+
+
+/*
+ * Copy memory from a physically-addressed area into a virtually-addressed area
+ */
+static int oldcopy(void *to, void *from, int size)
+{
+ size_t ret = 0; /* Length copied */
+ unsigned long pfn; /* Page Frame Number */
+ char *buf = to; /* Adr(Output buffer) */
+ size_t csize = (size_t)size;/* Num(bytes to copy) */
+ unsigned long offset; /* Lower 12 bits of from */
+ int userbuf = 0;/* to is in kernel space */
+
+ if (pr_dbg.enter_oldcopy)
+ pr_debug("ENTER %s to=%16.16llx, from = %16.16llx, size = %d\n",
+ __func__,
+ (unsigned long long) to,
+ (unsigned long long) from, size);
+
+ if (intel_iommu_translation_tables_are_mapped)
+ memcpy(to, phys_to_virt((phys_addr_t)from), csize);
+ else {
+ pfn = ((unsigned long) from) >> VTD_PAGE_SHIFT;
+ offset = ((unsigned long) from) & (~VTD_PAGE_MASK);
+ ret = copy_oldmem_page(pfn, buf, csize, offset, userbuf);
+ }
+
+ if (pr_dbg.leave_oldcopy)
+ pr_debug("LEAVE %s ret=%d\n", __func__, (int) ret);
+
+ return (int) ret;
+}
+#endif /* CONFIG_CRASH_DUMP */
--
Bill Sumner
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3 6/6] Crashdump-Accepting-Active-IOMMU-Call-From-Mainline
At a high level, this code operates primarily during iommu initialization
and device-driver initialization
During intel-iommu hardware initialization:
In intel_iommu_init(void)
* If (This is the crash kernel)
. Set flag: crashdump_accepting_active_iommu (all changes below check this)
. Skip disabling the iommu hardware translations
In init_dmars()
* Duplicate the intel iommu translation tables from the old kernel
in the new kernel
. The root-entry table, all context-entry tables,
and all page-translation-entry tables
. The duplicate tables contain updated physical addresses to link them
together.
. The duplicate tables are mapped into kernel virtual addresses
in the new kernel which allows most of the existing iommu code
to operate without change.
. Do some minimal sanity-checks during the copy
. Place the address of the new root-entry structure into "struct intel_iommu"
* Skip setting-up new domains for 'si', 'rmrr', 'isa'
. Translations for 'rmrr' and 'isa' ranges have been copied from the old
kernel
. This patch has not yet been tested with iommu pass-through enabled
* Existing (unchanged) code near the end of dmar_init:
. Loads the address of the (now new) root-entry structure from
"struct intel_iommu" into the iommu hardware and does the hardware flushes.
This changes the active translation tables from the ones in the old kernel
to the copies in the new kernel.
. This is legal because the translations in the two sets of tables are
currently identical:
Virtualization Technology for Directed I/O. Architecture Specification,
February 2011, Rev. 1.3 (section 11.2, paragraph 2)
In iommu_init_domains()
* Mark as in-use all domain-id's from the old kernel
. In case the new kernel contains a device that was not in the old kernel
and a new, unused domain-id is actually needed, the bitmap will give us one.
When a new domain is created for a device:
* If (this device has a context in the old kernel)
. Get domain-id, address-width, and IOVA ranges from the old kernel context;
. Get address(page-entry-tables) from the copy in the new kernel;
. And apply all of the above values to the new domain structure.
* Else
. Create a new domain as normal
v1->v2:
Updated patch description
v2->v3:
No change
Signed-off-by: Bill Sumner
---
drivers/iommu/intel-iommu.c | 272 +---
1 file changed, 204 insertions(+), 68 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 457ac80b..4f702d1 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -21,6 +21,8 @@
* Author: Fenghua Yu
*/
+/* #define DEBUG 1 */ /* Enable/Disable debug print in this source
file */
+
#include
#include
#include
@@ -1357,6 +1359,12 @@ static int iommu_init_domains(struct intel_iommu *iommu)
*/
if (cap_caching_mode(iommu->cap))
set_bit(0, iommu->domain_ids);
+
+#ifdef CONFIG_CRASH_DUMP
+ if (crashdump_accepting_active_iommu)
+ intel_iommu_get_dids_from_old_kernel(iommu);
+#endif /* CONFIG_CRASH_DUMP */
+
return 0;
}
@@ -1430,7 +1438,8 @@ static struct dmar_domain *alloc_domain(void)
}
static int iommu_attach_domain(struct dmar_domain *domain,
- struct intel_iommu *iommu)
+ struct intel_iommu *iommu,
+ int domain_number)
{
int num;
unsigned long ndomains;
@@ -1440,12 +1449,15 @@ static int iommu_attach_domain(struct dmar_domain
*domain,
spin_lock_irqsave(>lock, flags);
- num = find_first_zero_bit(iommu->domain_ids, ndomains);
- if (num >= ndomains) {
- spin_unlock_irqrestore(>lock, flags);
- printk(KERN_ERR "IOMMU: no free domain ids\n");
- return -ENOMEM;
- }
+ if (domain_number < 0) {
+ num = find_first_zero_bit(iommu->domain_ids, ndomains);
+ if (num >= ndomains) {
+ spin_unlock_irqrestore(>lock, flags);
+ printk(KERN_ERR "IOMMU: no free domain ids\n");
+ return -ENOMEM;
+ }
+ } else
+ num = domain_number;
domain->id = num;
set_bit(num, iommu->domain_ids);
@@ -2056,8 +2068,17 @@ static struct dmar_domain *get_domain_for_dev(struct
pci_dev *pdev, int gaw)
int bus = 0, devfn = 0;
int segment;
int ret;
+ int did = -1; /* Default to "no domain_id supplied" */
domain = find_domain(pdev);
+
+#ifdef CONFIG_CRASH_DUMP
+ if (domain)
+ if (pr_dbg.in_crashdump && crashdump_accepting_active_iommu)
+ pr_debug("IOMMU: Found domain (%d) for device %s\n",
+ domain->id, pci_name(pdev));
+#endif /* CONFIG_CRASH_DUMP */
+
if (domain)
[PATCHv3 4/6] Crashdump-Accepting-Active-IOMMU-Copy-Translations
-.-.-.-.-.-.-.
This patch contains a set of functions that duplicate into the
crashdump kernel the IOMMU translation tables that were in-use by the
panicked kernel at the time of the panic. Note that all of these
tables (pages) are linked together by physical memory addresses --
beginning with the address of the root-entry-table which is obtained
from the IOMMU hardware. These functions are located in reverse order
of being called -- from the highest-level (copying the root entry table)
to the lowest-level (accumulating each IOVA address range) -- while the
copy operation works its way down the tree of tables from the root-entry
to the lowest-level page-table.
During the traversal up and down this set of functions the structure
'copy_page_addr_parms' is passed as an anonymous structure via a void*
since most of the functions do not need it. Those functions that do
need it cast the pointer appropriately.
Entry to this set of functions from the mainline code is only through
the interface function 'copy_intel_iommu_translation_tables' which
instantiates the 'copy_page_addr_parms' structure on its stack, initializes
the global lists of domain-id structures (once only) and begins the copy.
The function that copies the individual page tables is recursive (max 6)
to accomodate various IOVA address widths. It stops either when the
address width reaches 12 bits (4k page addresses) or earlier when a
page table contains superpage addresses.
Note: The copying of the translation tables into the crashdump kernel
is done during system initialization when there is only one CPU active;
therefore no locks are necessary during the copy. After the copied
translation tables become active, the locks within the existing code
protect them.
v1->v2:
Updated patch description
v2->v3
Added "init_iova_domain(>iovad, DMA_32BIT_PFN);" as recommended
by Baoquan He [b...@redhat.com]
Signed-off-by: Bill Sumner
---
drivers/iommu/intel-iommu.c | 530
1 file changed, 530 insertions(+)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 85e30e5..6737550 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -4795,3 +4795,533 @@ static int intel_iommu_get_dids_from_old_kernel(struct
intel_iommu *iommu)
return 0;
}
#endif /* CONFIG_CRASH_DUMP */
+#ifdef CONFIG_CRASH_DUMP
+
+
+
+/*
+ * Copy iommu translation tables from old kernel into new kernel
+ * Entry to this set of functions is: copy_intel_iommu_translation_tables()
+ *
+ */
+
+/*
+ * Struct copy_page_addr_parms is used to allow copy_page_addr()
+ * to accumulate values across multiple calls and returns.
+ */
+struct copy_page_addr_parms {
+ u32 first; /* flag: first-time */
+ u32 last; /* flag: last-time */
+ u32 bus;/* last bus number we saw */
+ u32 devfn; /* last devfn we saw */
+ u32 shift; /* last shift we saw */
+ u64 pte;/* Page Table Entry */
+ u64 next_addr; /* next-expected page_addr */
+
+ u64 page_addr; /* page_addr accumulating size */
+ u64 page_size; /* page_size accumulated */
+
+ struct dmar_domain *domain; /* to accumulate iova ranges */
+};
+
+/*
+ * constant for initializing instances of copy_page_addr_parms properly.
+ */
+static struct copy_page_addr_parms copy_page_addr_parms_init = {1, 0};
+
+
+
+/*
+ * Lowest-level function in the 'Copy Page Tables' set
+ * Called once for each page_addr present in an iommu page-address table.
+ */
+static int copy_page_addr(u64 page_addr, u32 shift, u32 bus, u32 devfn,
+ u64 pte, struct dmar_domain *domain,
+ void *parms)
+{
+ struct copy_page_addr_parms *ppap = parms;
+
+ u64 page_size = ((u64)1 << shift); /* page_size */
+ u64 pfn_lo; /* For reserving IOVA range */
+ u64 pfn_hi; /* For reserving IOVA range */
+ struct iova *iova_p;/* For reserving IOVA range */
+
+ if (!ppap) {
+ pr_err("ERROR: ppap is NULL: 0x%3.3x(%3.3d) DevFn:
0x%3.3x(%3.3d) Page: 0x%16.16llx Size: 0x%16.16llx(%lld)\n",
+ bus, bus, devfn, devfn, page_addr,
+ page_size, page_size);
+ return 0;
+ }
+
+ if (!ppap->last) { /* If (Not last time) */
+ if (pr_dbg.copy_page_addr)
+ pr_debug("ADDR::B:D:F=%2.2x:%2.2x:%1.1x
Addr:0x%12.12llx Size:0x%12.12llx(%lld) Pte:0x%16.16llx\n",
+ bus, devfn >> 3, devfn & 0x7,
+ page_addr, page_size, page_size, pte);
+
+ /* If (only extending
[PATCHv3 3/6] Crashdump-Accepting-Active-IOMMU-Domain-Interfaces
-.-.-.-.-.-.-.
This patch contains functions called from among the mainline code
to retrieve information from the translation tables that have been
copied into the crashdump kernel from the panicked kernel.
Most often this happens when the crashdump kernel is setting-up a new
domain for a device. The crashdump kernel will assign to the device
(and to its new domain) the same IOVA addressing width and domain-id
that were used for this device by the panicked kernel. In the new
domain all of the IOVA addresses that were in-use by this device at
the time of the panic will be marked as "in-use" so that the crashdump
kernel will avoid re-using them.
This patch also includes one function to retrieve a bitmap of all
domain-ids in-use by the panicked kernel. These are marked "in-use"
so that if there is a device being used by the crashdump kernel that
was not being used by the panicked kernel then that new device will
receive a fresh, unused domain-id.
The 'device_domain_values_list' is used during the operation of
duplicating (copying) the translation tables from the panicked kernel
into the crashdump kernel, to insure that all devices that were assigned
to any specific domain-id in the panicked kernel are also assigned to
that same domain-id in the crashdump kernel. Additionally, all context
entries (there is one per device) that contain the same domain-id *must*
point to the same set of page-tables. The 'device_domain_values_list'
insures that if the copy operation has already seen 'this' domain-id,
it will simply point the current context entry to the same top-level
page-table that has been created previously for this domain-id.
No locks are necessary for 'device_domain_values_list'. Updates
are done only during the initialization operation of copying the
translation tables -- when only a single CPU is active.
Accesses after Linux goes multi-CPU are all read-only.
v1->v2:
Updated patch description
v2->v3:
No change
Signed-off-by: Bill Sumner
---
drivers/iommu/intel-iommu.c | 266
1 file changed, 266 insertions(+)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 4172a2b..85e30e5 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -4529,3 +4529,269 @@ static int oldcopy(void *to, void *from, int size)
return (int) ret;
}
#endif /* CONFIG_CRASH_DUMP */
+#ifdef CONFIG_CRASH_DUMP
+
+
+
+/*
+ * Interfaces for when a new domain in the new kernel needs some values
+ * from the old kernel's context entries
+ *
+ */
+
+/* List to hold domain values found during the copy operation */
+static struct list_head *device_domain_values_list;
+
+
+/* Utility function for interface functions that follow. */
+static int
+context_get_entry(struct context_entry *context_addr,
+ struct intel_iommu *iommu, u32 bus, int devfn)
+{
+ unsigned long long q; /* quadword scratch */
+ struct root_entry *root_phys; /* Phys adr (root table entry) */
+ struct root_entry root_temp; /* Local copy of root_entry */
+ struct context_entry *context_phys; /* Phys adr */
+
+ if (pr_dbg.domain_get)
+ pr_debug("ENTER %s B:D:F=%2.2x:%2.2x:%1.1x
_entry:0x%llx _iommu:0x%llx\n",
+ __func__, bus, devfn>>3, devfn&7,
+ (u64)context_addr, (u64)iommu);
+
+ if (bus > 255) /* Sanity check */
+ return -5;
+ if (devfn > 255 || devfn < 0) /* Sanity check */
+ return -6;
+
+ q = readq(iommu->reg + DMAR_RTADDR_REG);
+ pr_debug("IOMMU %d: DMAR_RTADDR_REG:0x%16.16llx\n", iommu->seq_id, q);
+ if (!q)
+ return -1;
+
+ root_phys = (struct root_entry *) q;/* Adr(base of vector) */
+ root_phys += bus; /* Adr(entry we want) */
+
+ oldcopy(_temp, root_phys, sizeof(root_temp));
+
+ pr_debug("root_temp.val:0x%llx .rsvd1:0x%llx root_phys:0x%llx\n",
+ root_temp.val, root_temp.rsvd1, (u64)root_phys);
+
+ if (!root_present(_temp))
+ return -2;
+
+ pr_debug("B:D:F=%2.2x:%2.2x:%1.1x root_temp.val: %llx .rsvd1: %llx\n",
+ bus, devfn >> 3, devfn & 7, root_temp.val, root_temp.rsvd1);
+
+ if (root_temp.rsvd1)/* If (root_entry is bad) */
+ return -3;
+
+ context_phys = get_context_phys_from_root(_temp);
+ if (!context_phys)
+ return -4;
+
+ context_phys += devfn; /* Adr(context_entry we want) */
+
+
+ oldcopy(context_addr, context_phys, sizeof(*context_addr));
+
+ if (pr_dbg.domain_get)
+ pr_debug("LEAVE %s returning:
[PATCHv3 0/6] Crashdump Accepting Active IOMMU
v2->v3: 1. Commented-out "#define DEBUG 1" to eliminate debug messages 2. Updated the comments about changes in each version in all patches in the set. 3. Fixed: one-line added to Copy-Translations" patch to initialize the iovad struct as recommended by Baoquan He [b...@redhat.com] init_iova_domain(>iovad, DMA_32BIT_PFN); v1->v2: The following series implements a fix for: A kdump problem about DMA that has been discussed for a long time. That is, when a kernel panics and boots into the kdump kernel, DMA started by the panicked kernel is not stopped before the kdump kernel is booted and the kdump kernel disables the IOMMU while this DMA continues. This causes the IOMMU to stop translating the DMA addresses as IOVAs and begin to treat them as physical memory addresses -- which causes the DMA to either: (1) generate DMAR errors or (2) generate PCI SERR errors or (3) transfer data to or from incorrect areas of memory. Often this causes the dump to fail. This patch set modifies the behavior of the iommu in the (new) crashdump kernel: 1. to accept the iommu hardware in an active state, 2. to leave the current translations in-place so that legacy DMA will continue using its current buffers until the device drivers in the crashdump kernel initialize and initialize their devices, 3. to use different portions of the iova address ranges for the device drivers in the crashdump kernel than the iova ranges that were in-use at the time of the panic. Advantages of this approach: 1. All manipulation of the IO-device is done by the Linux device-driver for that device. 2. This approach behaves in a manner very similar to operation without an active iommu. 3. Any activity between the IO-device and its RMRR areas is handled by the device-driver in the same manner as during a non-kdump boot. 4. If an IO-device has no driver in the kdump kernel, it is simply left alone. This supports the practice of creating a special kdump kernel without drivers for any devices that are not required for taking a crashdump. Changes since the RFC version of this patch: 1. Consolidated all of the operational code into the "copy..." functions. The "process..." functions were primarily used for diagnostics and exploration; however, there was a small amount of operational code that used the "process..." functions. This operational code has been moved into the "copy..." functions. 2. Removed the "Process ..." functions and the diagnostic code that ran on that function set. This removed about 1/4 of the code -- which this operational patch set no longer needs. These portions of the RFC patch could be formatted as a separate patch and submitted independently at a later date. 3. Re-formatted the code to the Linux Coding Standards. The checkpatch script still finds some lines to complain about; however most of these lines are either (1) lines that I did not change, or (2) lines that only changed by adding a level of indent which pushed them over 80-characters, or (3) new lines whose intent is far clearer when longer than 80-characters. 4. Updated the remaining debug print to be significantly more flexible. This allows control over the amount of debug print to the console -- which can vary widely. 5. Fixed a couple of minor bugs found by testing on a machine with a very large IO configuration. At a high level, this code operates primarily during iommu initialization and device-driver initialization During intel-iommu hardware initialization: In intel_iommu_init(void) * If (This is the crash kernel) . Set flag: crashdump_accepting_active_iommu (all changes below check this) . Skip disabling the iommu hardware translations In init_dmars() * Duplicate the intel iommu translation tables from the old kernel in the new kernel . The root-entry table, all context-entry tables, and all page-translation-entry tables . The duplicate tables contain updated physical addresses to link them together. . The duplicate tables are mapped into kernel virtual addresses in the new kernel which allows most of the existing iommu code to operate without change. . Do some minimal sanity-checks during the copy . Place the address of the new root-entry structure into "struct intel_iommu" * Skip setting-up new domains for 'si', 'rmrr', 'isa' . Translations for 'rmrr' and 'isa' ranges have been copied from the old kernel . This patch has not yet been tested with iommu pass-through enabled * Existing (unchanged) code near the end of dmar_init: . Loads the address of the (now new) root-entry structure from "struct intel_iommu" into the iommu hardware and does the hardware flushes. This changes the active translation tables from the ones in the old kernel to the copies in the new kernel. . This is legal because the translations in the two sets of tables are currently identical: Virtualization Technology
[PATCHv3 5/6] Crashdump-Accepting-Active-IOMMU-Debug-Print-IOMMU
This patch contains a function to print the hardware registers of each
IOMMU onto the system console during crashdump kernel initialization.
This function seemed far too useful to leave out.
v1->v2:
Updated patch description
Fixed: "Advanced Fault Log register"
v2->v3:
No change
Signed-off-by: Bill Sumner
---
drivers/iommu/intel-iommu.c | 76 +
1 file changed, 76 insertions(+)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 6737550..457ac80b 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -5325,3 +5325,79 @@ static int copy_intel_iommu_translation_tables(struct
dmar_drhd_unit *drhd,
return 0;
}
#endif /* CONFIG_CRASH_DUMP */
+#ifdef CONFIG_CRASH_DUMP
+
+
+/* =
+ * Diagnostic print
+ *
+ */
+
+static struct intel_iommu_register_print {
+ int len;/* Length of register */
+ int idx;/* Index to read register */
+ charreg[20];/* Linux name of register */
+ chartxt[40];/* Description */
+} intel_iommu_register_print_v[] = {
+ {1, DMAR_VER_REG, "DMAR_VER_REG", "Arch version supported
by this IOMMU"},
+ {2, DMAR_CAP_REG, "DMAR_CAP_REG", "Hardware supported
capabilities"},
+ {2, DMAR_ECAP_REG, "DMAR_ECAP_REG","Extended capabilities
supported"},
+ {1, DMAR_GCMD_REG, "DMAR_GCMD_REG","Global command
register"},
+ {1, DMAR_GSTS_REG, "DMAR_GSTS_REG","Global status register
"},
+ {2, DMAR_RTADDR_REG,"DMAR_RTADDR_REG", "Root entry table"},
+ {2, DMAR_CCMD_REG, "DMAR_CCMD_REG","Context command reg"},
+ {1, DMAR_FSTS_REG, "DMAR_FSTS_REG","Fault Status
register"},
+ {1, DMAR_FECTL_REG, "DMAR_FECTL_REG", "Fault control
register"},
+ {1, DMAR_FEDATA_REG,"DMAR_FEDATA_REG", "Fault event interrupt
data register"},
+ {1, DMAR_FEADDR_REG,"DMAR_FEADDR_REG", "Fault event interrupt
addr register"},
+ {1, DMAR_FEUADDR_REG, "DMAR_FEUADDR_REG", "Upper address
register"},
+ {2, DMAR_AFLOG_REG, "DMAR_AFLOG_REG", "Advanced Fault Log
register"},
+ {1, DMAR_PMEN_REG, "DMAR_PMEN_REG","Enable Protected
Memory Region"},
+ {1, DMAR_PLMBASE_REG, "DMAR_PLMBASE_REG", "PMRR Low addr"},
+ {1, DMAR_PLMLIMIT_REG, "DMAR_PLMLIMIT_REG","PMRR low limit"},
+ {2, DMAR_PHMBASE_REG, "DMAR_PHMBASE_REG", "pmrr high base addr"},
+ {2, DMAR_PHMLIMIT_REG, "DMAR_PHMLIMIT_REG","pmrr high limit"},
+ {2, DMAR_IQH_REG, "DMAR_IQH_REG", "Invalidation queue
head register"},
+ {2, DMAR_IQT_REG, "DMAR_IQT_REG", "Invalidation queue
tail register"},
+ {2, DMAR_IQA_REG, "DMAR_IQA_REG", "Invalidation queue
addr register"},
+ {1, DMAR_ICS_REG, "DMAR_ICS_REG", "Invalidation complete
status register"},
+ {2, DMAR_IRTA_REG, "DMAR_IRTA_REG","Interrupt remapping
table addr register"},
+};
+
+static void print_intel_iommu_registers(struct dmar_drhd_unit *drhd)
+{
+ struct intel_iommu *iommu; /* Virt adr(iommu hardware registers) */
+ unsigned long long q; /* quadword scratch */
+ u32 ver;/* DMAR_VER_REG */
+
+ int m = sizeof(intel_iommu_register_print_v) /
+ sizeof(intel_iommu_register_print_v[0]);
+ struct intel_iommu_register_print *p = _iommu_register_print_v[0];
+
+ iommu = drhd->iommu;
+
+ pr_debug("ENTER %s\n", __func__);
+ ver = readl(iommu->reg + DMAR_VER_REG);
+ pr_debug("IOMMU %d: reg_base_addr %llx ver %d:%d cap %llx ecap %llx\n",
+ iommu->seq_id,
+ (unsigned long long)drhd->reg_base_addr,
+ DMAR_VER_MAJOR(ver), DMAR_VER_MINOR(ver),
+ (unsigned long long)iommu->cap,
+ (unsigned long long)iommu->ecap);
+
+ q = readq(iommu->reg + DMAR_RTADDR_REG);
+ pr_debug("IOMMU %d: DMAR_RTADDR_REG:0x%16.16llx\n", iommu->seq_id, q);
+
+ for (; p < _iommu_register_print_v[m]; p++)
+ if (p->len == 2)
+ pr_debug("0x%16.16llx %-20s %-40s\n",
+ (u64)readq(iommu->reg + p->idx), p->reg,
+ p->txt);
+ else
+ pr_debug("0x%8.8x %-20s %-40s\n",
+ (u32)readl(iommu->reg + p->idx), p->reg,
+ p->txt);
+
+ pr_debug("LEAVE %s\n", __func__);
+}
+#endif /* CONFIG_CRASH_DUMP */
--
Bill Sumner
--
To unsubscribe from this list: send the line
Re: Freeing of dev->p
Hi Greg,
On Fri, 10 Jan 2014 07:24:02 -0800, Greg Kroah-Hartman wrote:
> On Fri, Jan 10, 2014 at 03:39:07PM +0100, Jean Delvare wrote:
> > + * @driver_data: Private pointer for driver specific info. Will turn into
> > a
> > + * list soon.
>
> Ah, this comment reminds me of why I originally did this. I was working
> on moving for a way to have multiple drivers bound to the same device,
> as people needed that type of thing for something that I can't remember
> at the moment.
Presumably this was to handle multifunction devices. But now we have
the MFD infrastructure which deals with the problem gracefully, so
indeed there no longer is any point in making driver_data a list. The
second part of the comment above can go away.
> As it's been years now with no real movement forward on that idea, I
> guess it's not going to happen :)
Agreed, problem was simply solved differently.
> > * @power: For device power management.
> > * See Documentation/power/devices.txt for details.
> > * @pm_domain: Provide callbacks that are executed during system
> > suspend,
> > @@ -737,6 +739,8 @@ struct device {
> >device */
> > void*platform_data; /* Platform specific data, device
> >core doesn't touch it */
> > + void*driver_data; /* Driver data, set and get with
> > + dev_set/get_drvdata */
> > struct dev_pm_info power;
> > struct dev_pm_domain*pm_domain;
> >
> >
> > For performance I'd even question the point of the dev check in
> > dev_get_drvdata(), especially when there is no such check in
> > dev_set_drvdata() which presumably is always called first.
>
> It's nice to not oops if a NULL pointer is passed in :)
Or not. Is there any case where passing NULL could be desirable? If not
and passing NULL is always going to be a bug (which I think is the
case) then a oops is the right answer to bogus code. This ensure the
bug will be caught and fixed early. Not oopsing here most certainly
means oopsing at the next line in the driver anyway when it tries to
access the driver data and certainly doesn't expect it to be NULL
either.
> > Plus dev_set_drvdata() can no longer fail (something only 3 drivers in
> > the whole kernel tree were checking for anyway) so it could return
> > void instead of int.
>
> True.
>
> > Then I suppose we could inline both functions
> > again, for performance. Well, put in short, really revering
> > b4028437876866aba4747a655ede00f892089e14 would be the way to go IMHO.
>
> Almost, the copyright lines should stay :)
As you wish :)
> > Really, while I understand your envy to protect driver core internals
> > from unwanted access, the cost here was simply too high IMHO, both in
> > terms of getting things right and performance. Some drivers are calling
> > dev_get_drvdata() directly or indirectly repeatedly at run-time. They
> > had no reason not to as this used to be so fast, and now it is no
> > longer an inline function, it has conditionals and a double pointer
> > indirection...
> >
> > Plus, I can't think of anything really bad that could result from
> > accessing driver_data directly, contrary to the other members of struct
> > device_private.
>
> See first response above for why I did this, it wasn't to just make
> things "harder" to mess up, I actually had a reason to do it (imagine
> that!)
Shocking! :D
> Thanks for the detailed response, I think I'll just revert most of that
> patch and see if it's still workable.
Sounds like a good plan, yeah.
Thanks,
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] alpha: don't use module_init for non-modular core code
The srm console is always built in. It will never be modular, so using module_init as an alias for __initcall is rather misleading. Fix this up now, so that we can relocate module_init from init.h into module.h in the future. If we don't do this, we'd have to add module.h to obviously non-modular code, and that would be a worse thing. Direct use of __initcall is discouraged, vs prioritized ones. Use of device_initcall is consistent with what __initcall maps onto, and hence does not change the init order, making the impact of this change zero. Should someone with real hardware for boot testing want to change it later to arch_initcall or console_initcall, they can do that at a later date. Signed-off-by: Paul Gortmaker diff --git a/arch/alpha/kernel/srmcons.c b/arch/alpha/kernel/srmcons.c index 6f01d9ad7b81..72b59511e59a 100644 --- a/arch/alpha/kernel/srmcons.c +++ b/arch/alpha/kernel/srmcons.c @@ -237,8 +237,7 @@ srmcons_init(void) return -ENODEV; } - -module_init(srmcons_init); +device_initcall(srmcons_init); /* -- 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: [RFC PATCH] mm: thp: Add per-mm_struct flag to control THP
On Fri, Jan 10, 2014 at 10:23:10PM +0200, Kirill A. Shutemov wrote: > Do you know what cause the difference? I prefer to fix THP instead of > adding new knob to disable it. The issue is that when you touch 1 byte of an untouched, contiguous 2MB chunk, a THP will be handed out, and the THP will be stuck on whatever node the chunk was originally referenced from. If many remote nodes need to do work on that same chunk, they'll be making remote accesses. With THP disabled, 4K pages can be handed out to separate nodes as they're needed, greatly reducing the amount of remote accesses to memory. I give a bit better description here: https://lkml.org/lkml/2013/8/27/397 I had been looking into better ways to handle this issues, but after spinning through a few other ideas: - Per cpuset flag to control THP: https://lkml.org/lkml/2013/6/10/331 - Threshold to determine when to hand out THPs: https://lkml.org/lkml/2013/12/12/394 We've arrived back here. Andrea seemed to think that this is an acceptable approach to solve the problem, at least as a starting point: https://lkml.org/lkml/2013/12/17/397 I agree that we should, ideally, come up with a way to appropriately handle this problem in the kernel, but as of right now, it appears that that might be a rather large undertaking. - 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/
Steroid Products Manufacturer--Numberone Biotech Inc.
Dear, We supply products-injection steroids, oral steroids. Min. order quantity: As your request. Payment type: Western Union, Bank Transfer. Delivery time: within 10 working days after get payment. Shipping term: express mail (with registered tracking number, door delivery). Supplying ability: 5000 vials(bottles) per week. Return policy: we will return your money if our products don’t have good effect. We can develop and product the injectable steroids as your request too. You can learn the details of our products on our web: . If you are interested in our products, we are pleased to send you our price quote for them. We hope to receiving orders from you and build a long lasting working relation with you. Sincerely, Overseas Sales Division Numberone Biotech Co., Ltd.
Re: [PATCH 2/2] PCI: Only enable realloc auto when root bus has 64bit mmio
On 01/10/2014 12:13 PM, Yinghai Lu wrote: > On Fri, Jan 10, 2014 at 8:19 AM, Joseph Salisbury > wrote: >> On 12/11/2013 02:55 PM, Yinghai Lu wrote: >>> On Wed, Dec 11, 2013 at 11:19 AM, Joseph Salisbury >>> wrote: On 12/09/2013 03:10 PM, Yinghai Lu wrote: > On Mon, Dec 9, 2013 at 11:42 AM, Bjorn Helgaas > wrote: >> That doesn't answer my question at all. >> >> I understand that this change makes it so Joseph doesn't have to use >> "pci=realloc=off". But why should auto-reallocation be limited to >> buses that have resources above 4GB? That doesn't make any sense. >> >> We should fix the reallocation code so it can deal with this case. If >> there's not enough space for everything, obviously we have to leave >> something unassigned. A ROM BAR is a good candidate for leaving >> unassigned, because most of the time we can get along without it. > Yes, that is ideal and not that simple. > but that would be hard to backport to old kernels. > > BTW, Joseph, can you try > git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git > for-pci-3.14 > with pci=realloc=on > > on that system? > > Thanks > > Yinghai I noticed there was some back and forth on this thread. Do you still want me to test this version, Yinghai? >>> Yes, if that works, we would not need to put the patch in upstream for >>> limiting >>> realloc auto scope. >>> >> Another user has confirmed that at test kernel from your branch[0] does >> resolve the bug. > Hi, Joe, > > Bjorn does not want to limit auto realloc, so this patch can not make > to upstream at this point. > > so we may have to ask user to append "pci=realloc=off" before we find > more smart way to realloc > resource. > > Thanks > > Yinghai Hi Yinghai, In a prior email you mentioned: "Yes, if that works, we would not need to put the patch in upstream for limiting realloc auto scope." Is the git tree at git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git somehow different now? Thanks, Joe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] char: random: stir the output pools differently when the random_write lenght allows splitting the seed
On Fri, Jan 10, 2014 at 12:37:26PM +0100, Clemens Ladisch wrote: > Stephan Mueller wrote: > > Am Freitag, 10. Januar 2014, 09:13:57 schrieb Clemens Ladisch: > >> Rafael Aquini wrote: > >>> This patch introduces changes to the random_write method so it can > >>> split the given seed and completely stir the output pools with > >>> different halves of it, when seed lenght allows us doing so. > >>> > >>> - ret = write_pool(_pool, buffer, count); > >>> + ret = write_pool(pool1, buffer, count1); > >>> if (ret) > >>> return ret; > >>> - ret = write_pool(_pool, buffer, count); > >>> + ret = write_pool(pool2, buffer + offset, count2); > >> > >> Doesn't this assume that both halves of the buffer contain some > >> (uncredited) entropy? In other words, wouldn't this result in worse > >> randomness for pool2 if the second half of the buffer contains just > >> zero padding? > > > > [...] > > Coming back to your concern: sure, the caller can pad any data injected > > into /dev/?random with zeros. > > Assume that the userspace of an embedded device wants to do the same > kind of initialization that a call to add_device_randomness() does, and > that it has some data like "char serial_number[256]". The padding > wouldn't be done intentionally, it's just a property of the data (and it > wouldn't have mattered before this patch). > > > But as writing to the character files is allowed to every user, this > > per definition must not matter (e.g. an attacker may simply write > > zeros or other known data into the character file). And the random.c > > driver handles that case appropriately by not increasing the entropy > > estimator when receiving data. > > The problem is not with the entropy estimate. > > > All the patch tries to achieve is to ensure that both pools are not > > always mixed with the same values. > > Before this patch, both pools got mixed with the same values. After > this patch, both pools indeed get mixed with different values, but now > one pool gets mixed with a known value if one half of the buffer happens > to be known. > Yeah, nice catch. I haven't thought about it. Theoretically speaking there's no big difference between using the same seed to mix both output pools and split the seed to use its different halves to mix the pools separately in this case. Supposing an attacker could successfully compromise the blocking pool (/dev/random) by injecting a known pattern seed into /dev/urandom, a split seed would also not be able to do any greater good for us, as the attacker can surely handcraft an input that shows the same pattern on both halves. I'm wondering if doing something like initializing an extra structentropy_store, fill in its pool with 'OUTPUT_POOL_SIZE' get_random_bytes(), stir this extra pool with whatever came in as seed from userland and extract two seeds from this pool to then separately stir the output pools would be something more feasible here, or would it just be considered too much for too little... if the approach above is sth worth to pursue, I'll come up with something next week. Thank you all for the comments till here, and have you all a nice weekend! -- Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] hwmon: (max197) add include guard
Add include guard to include/linux/platform_data/max197.h to prevent
multiple inclusion.
Signed-off-by: Vivien Didelot
---
include/linux/platform_data/max197.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/platform_data/max197.h
b/include/linux/platform_data/max197.h
index e2a41dd..8da8f94 100644
--- a/include/linux/platform_data/max197.h
+++ b/include/linux/platform_data/max197.h
@@ -11,6 +11,9 @@
* For further information, see the Documentation/hwmon/max197 file.
*/
+#ifndef _PDATA_MAX197_H
+#define _PDATA_MAX197_H
+
/**
* struct max197_platform_data - MAX197 connectivity info
* @convert: Function used to start a conversion with control byte ctrl.
@@ -19,3 +22,5 @@
struct max197_platform_data {
int (*convert)(u8 ctrl);
};
+
+#endif /* _PDATA_MAX197_H */
--
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/
[PATCH] hwmon: (sht15) add include guard
Add include guard to include/linux/platform_data/sht15.h to prevent
multiple inclusion.
Signed-off-by: Vivien Didelot
---
include/linux/platform_data/sht15.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/platform_data/sht15.h
b/include/linux/platform_data/sht15.h
index 33e0fd2..12289c1 100644
--- a/include/linux/platform_data/sht15.h
+++ b/include/linux/platform_data/sht15.h
@@ -12,6 +12,9 @@
* For further information, see the Documentation/hwmon/sht15 file.
*/
+#ifndef _PDATA_SHT15_H
+#define _PDATA_SHT15_H
+
/**
* struct sht15_platform_data - sht15 connectivity info
* @gpio_data: no. of gpio to which bidirectional data line is
@@ -31,3 +34,5 @@ struct sht15_platform_data {
bool no_otp_reload;
bool low_resolution;
};
+
+#endif /* _PDATA_SHT15_H */
--
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/
