Re: Linux-next parallel cp workload hang

2016-05-17 Thread Dave Chinner
On Wed, May 18, 2016 at 09:46:15AM +0800, Xiong Zhou wrote:
> Hi,
> 
> Parallel cp workload (xfstests generic/273) hangs like blow.
> It's reproducible with a small chance, less the 1/100 i think.
> 
> Have hit this in linux-next 20160504 0506 0510 trees, testing on
> xfs with loop or block device. Ext4 survived several rounds
> of testing.
> 
> Linux next 20160510 tree hangs within 500 rounds testing several
> times. The same tree with vfs parallel lookup patchset reverted
> survived 900 rounds testing. Reverted commits are attached.

What hardware?

> Bisecting in this patchset ided this commit:
> 
> 3b0a3c1ac1598722fc289da19219d14f2a37b31f is the first bad commit
> commit 3b0a3c1ac1598722fc289da19219d14f2a37b31f
> Author: Al Viro 
> Date:   Wed Apr 20 23:42:46 2016 -0400
> 
> simple local filesystems: switch to ->iterate_shared()
> 
> no changes needed (XFS isn't simple, but it has the same parallelism
> in the interesting parts exercised from CXFS).
> 
> With this commit reverted on top of Linux next 0510 tree, 5000+ rounds
> of testing passed.
> 
> Although 2000 rounds testing had been conducted before good/bad
> verdict, i'm not 100 percent sure about all this, since it's
> so hard to hit, and i am not that lucky..
> 
> Bisect log and full blocked state process dump log are also attached.
> 
> Furthermore, this was first hit when testing fs dax on nvdimm,
> however it's reproducible without dax mount option, and also
> reproducible on loop device, just seems harder to hit.
> 
> Thanks,
> Xiong
> 
> [0.771475] INFO: task cp:49033 blocked for more than 120 seconds.
> [0.794263]   Not tainted 4.6.0-rc6-next-20160504 #5
> [0.812515] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
> this message.
> [0.841801] cp  D 880b4e977928 0 49033  49014
> 0x0080
> [0.868923]  880b4e977928 880ba275d380 880b8d712b80
> 880b4e978000
> [0.897504]  7fff 0002 
> 880b8d712b80
> [0.925234]  880b4e977940 816cbc25 88035a1dabb0
> 880b4e9779e8
> [0.953237] Call Trace:
> [0.958314]  [] schedule+0x35/0x80
> [0.974854]  [] schedule_timeout+0x231/0x2d0
> [0.995728]  [] ? down_trylock+0x2d/0x40
> [1.015351]  [] ? xfs_iext_bno_to_ext+0xa2/0x190 [xfs]
> [1.040182]  [] __down_common+0xaa/0x104
> [1.059021]  [] ? _xfs_buf_find+0x162/0x340 [xfs]
> [1.081357]  [] __down+0x1d/0x1f
> [1.097166]  [] down+0x41/0x50
> [1.112869]  [] xfs_buf_lock+0x3c/0xf0 [xfs]
> [1.134504]  [] _xfs_buf_find+0x162/0x340 [xfs]
> [1.156871]  [] xfs_buf_get_map+0x2a/0x270 [xfs]

So what's holding that directory data buffer lock? It should only be
held if there is either IO in progress, or a modification of the
buffer in progress that is blocked somewhere else.

> [1.180010]  [] xfs_buf_read_map+0x2d/0x180 [xfs]
> [1.203538]  [] xfs_trans_read_buf_map+0xf1/0x300 [xfs]
> [1.229194]  [] xfs_da_read_buf+0xd1/0x100 [xfs]
> [1.251948]  [] xfs_dir3_data_read+0x26/0x60 [xfs]
> [1.275736]  [] xfs_dir2_leaf_readbuf.isra.12+0x1be/0x4a0 
> [xfs]
> [1.305094]  [] ? down_read+0x12/0x30
> [1.323787]  [] ? xfs_ilock+0xe4/0x110 [xfs]
> [1.345114]  [] xfs_dir2_leaf_getdents+0x13b/0x3d0 [xfs]
> [1.371818]  [] xfs_readdir+0x1a6/0x1c0 [xfs]

So we should be holding the ilock in shared mode here...

> [1.393471]  [] xfs_file_readdir+0x2b/0x30 [xfs]
> [1.416874]  [] iterate_dir+0x173/0x190
> [1.436709]  [] ? do_audit_syscall_entry+0x66/0x70
> [1.460951]  [] SyS_getdents+0x98/0x120
> [1.480566]  [] ? iterate_dir+0x190/0x190
> [1.500909]  [] do_syscall_64+0x62/0x110
> [1.520847]  [] entry_SYSCALL64_slow_path+0x25/0x25
> [1.545372] INFO: task cp:49040 blocked for more than 120 seconds.
> [1.568933]   Not tainted 4.6.0-rc6-next-20160504 #5
> [1.587943] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
> this message.
> [1.618544] cp  D 880b91463b00 0 49040  49016
> 0x0080
> [1.645502]  880b91463b00 880464d5c140 88029b475700
> 880b91464000
> [1.674145]  880411c42610  880411c42628
> 8802c10bc610
> [1.702834]  880b91463b18 816cbc25 88029b475700
> 880b91463b88
> [1.731501] Call Trace:
> [1.736866]  [] schedule+0x35/0x80
> [1.754119]  [] rwsem_down_read_failed+0xf2/0x140
> [1.777411]  [] ? xfs_ilock_data_map_shared+0x30/0x40
> [xfs]
> [1.805090]  [] call_rwsem_down_read_failed+0x18/0x30
> [1.830482]  [] down_read+0x20/0x30
> [1.848505]  [] xfs_ilock+0xe4/0x110 [xfs]
> [1.869293]  [] xfs_ilock_data_map_shared+0x30/0x40

And it this is an attempt to lock the inode shared, so if that is
failing while there's another shared holder, than means there's an
exclusive waiter queued up (i.e. read iheld -> write blocked -> read
blocked).


So looking at dump-g273xfs0510:

[  845.727907] INFO: task cp:40126 blocked for more than 120 seconds.
[  845.751175]   Not tainted 4.6.0-rc7-next-20160510 #9
[  845.770011] "echo 0 > 

Re: [PATCH 1/2] arm64: dts: NS2: Add all of the UARTs

2016-05-17 Thread Kefeng Wang


On 2016/5/18 3:56, Florian Fainelli wrote:
> On 05/15/2016 06:11 PM, Kefeng Wang wrote:
>>> I can confirm that with your change and the change to the bootargs you 
>>> describe above, it works as desired.  Was your change already accepted?
>>>
>>
>> Great, thanks a lot. it is still being reviewing for now and waiting for 
>> response for now.
> 
> Then I would be inclined to take Jon's patch as-is, and follow up with
> an additional patch to the NS2 DTS once yours lands in.
> 

Sure, please.

Kefeng



[RFC][PATCH 8/7] sched/fair: Use utilization distance to filter affine sync wakeups

2016-05-17 Thread Mike Galbraith
On Mon, 2016-05-09 at 12:48 +0200, Peter Zijlstra wrote:
> Hai,

(got some of the frozen variety handy?:)

> here be a semi coherent patch series for the recent select_idle_siblings()
> tinkering. Happy benchmarking..

And tinkering on top of your rewrite series...

sched/fair: Use utilization distance to filter affine sync wakeups

Identifying truly synchronous tasks accurately is annoyingly fragile,
which led to the demise of the old avg_overlap heuristic, which meant
that we schedule tasks high frequency localhost communicating buddies
to L3 vs L2, causing them to take painful cache misses needlessly.

To combat this, track average utilization distance, and when both
waker/wakee are short duration tasks cycling at the ~same frequency
(ie can't have any appreciable reclaimable overlap), and the sync
hint has been passed, take that as a queue that pulling the wakee
to hot L2 is very likely to be a win.  Changes in behavior, such
as taking a long nap, bursts of other activity, or sharing the rq
with tasks that are not cycling rapidly will quickly encourage the
pair to search for a new home, where they can again find each other.

This only helps really fast movers, but that's ok (if we can get
away with it at all), as these are the ones that need some help.

It's dirt simple, cheap, and seems to work pretty well.  It does
help fast movers, does not wreck lmbench AF_UNIX/TCP throughput
gains that select_idle_sibling() provided, and didn't change pgbench
numbers one bit on my desktop box, ie tight discrimination criteria
seems to work out ok in light testing, so _maybe_ not completely
useless...
 
4 x E7-8890 tbench
Throughput 598.158 MB/sec  1 clients  1 procs  max_latency=0.287 ms 
1.000
Throughput 1166.26 MB/sec  2 clients  2 procs  max_latency=0.076 ms 
1.000
Throughput 2214.55 MB/sec  4 clients  4 procs  max_latency=0.087 ms 
1.000
Throughput 4264.44 MB/sec  8 clients  8 procs  max_latency=0.164 ms 
1.000
Throughput 7780.58 MB/sec  16 clients  16 procs  max_latency=0.109 ms   
1.000
Throughput 15199.3 MB/sec  32 clients  32 procs  max_latency=0.293 ms   
1.000
Throughput 21714.8 MB/sec  64 clients  64 procs  max_latency=0.872 ms   
1.000
Throughput 44916.1 MB/sec  128 clients  128 procs  max_latency=4.821 ms 
1.000
Throughput 76294.5 MB/sec  256 clients  256 procs  max_latency=7.375 ms 
1.000

+IDLE_SYNC
Throughput 737.781 MB/sec  1 clients  1 procs  max_latency=0.248 ms 
1.233
Throughput 1478.49 MB/sec  2 clients  2 procs  max_latency=0.321 ms 
1.267
Throughput 2506.98 MB/sec  4 clients  4 procs  max_latency=0.413 ms 
1.132
Throughput 4359.15 MB/sec  8 clients  8 procs  max_latency=0.306 ms 
1.022
Throughput 9025.05 MB/sec  16 clients  16 procs  max_latency=0.349 ms   
1.159
Throughput 18703.1 MB/sec  32 clients  32 procs  max_latency=0.290 ms   
1.230
Throughput 33600.8 MB/sec  64 clients  64 procs  max_latency=6.469 ms   
1.547
Throughput 59084.3 MB/sec  128 clients  128 procs  max_latency=5.031 ms 
1.315
Throughput 75705.8 MB/sec  256 clients  256 procs  max_latency=24.113 ms
0.992

1 x i4790 lmbench3
*Local* Communication bandwidths in MB/s - bigger is better
-
HostOS  Pipe AFTCP  File   Mmap  Bcopy  Bcopy  Mem   Mem
 UNIX  reread reread (libc) (hand) read write
- -    -- -- -- --  -
IDLE_CORE+IDLE_CPU+IDLE_SMT
homer 4.6.0-masterx 6027 14.K 9773 8905.2  15.2K  10.1K 6775.0 15.K 10.0K
homer 4.6.0-masterx 5962 14.K 9881 8900.7  15.0K  10.1K 6785.2 15.K 10.0K
homer 4.6.0-masterx 5935 14.K 9917 8946.2  15.0K  10.1K 6761.8 15.K 9826.
+IDLE_SYNC
homer 4.6.0-masterx 8865 14.K 9807 8880.6  14.7K  10.1K 6777.9 15.K 9966.
homer 4.6.0-masterx 8855 13.K 9856 8844.5  15.2K  10.1K 6752.1 15.K 10.0K
homer 4.6.0-masterx 8896 14.K 9836 8880.1  15.0K  10.2K 6771.6 15.K 9941.
^++  ^+-  ^+-
select_idle_sibling() completely disabled
homer 4.6.0-masterx 8810 9807 7109 8982.8  15.4K  10.2K 6831.7 15.K 10.1K
homer 4.6.0-masterx 8877 9757 6864 8970.1  15.3K  10.2K 6826.6 15.K 10.1K
homer 4.6.0-masterx 8779 9736 10.K 8975.6  15.4K  10.1K 6830.2 15.K 10.1K
^++  ^--  ^--

Signed-off-by: Mike Galbraith 
---
 include/linux/sched.h   |2 -
 kernel/sched/core.c |6 -
 kernel/sched/fair.c |   49 +---
 kernel/sched/features.h |1 
 kernel/sched/sched.h|7 ++
 5 files changed, 51 insertions(+), 14 deletions(-)

--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1302,7 +1302,7 @@ struct load_weight {
  * issues.
  */
 struct sched_avg {
-   u64 last_update_time, load_sum;
+   u64 last_update_time, load_sum, util_dist_us;
u32 util_sum, 

Re: UBSAN: Undefined behaviour in block/blk-mq.c:1459:27 with pata_amd

2016-05-17 Thread Meelis Roos
> Does the patch below help?
> 
> From: Bartlomiej Zolnierkiewicz 
> Subject: [PATCH] blk-mq: fix undefined behaviour in order_to_size()
> 
> When this_order variable in blk_mq_init_rq_map() becomes zero
> the code incorrectly decrements the variable and passes the result
> to order_to_size() helper causing undefined behaviour:
> 
>  UBSAN: Undefined behaviour in block/blk-mq.c:1459:27
>  shift exponent 4294967295 is too large for 32-bit type 'unsigned int'
>  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc6-00072-g33656a1 #22
> 
> Fix the code by checking this_order variable for not having the zero
> value first.
> 
> Reported-by: Meelis Roos 
> Fixes: 320ae51feed5 ("blk-mq: new multi-queue block IO queueing mechanism")
> Signed-off-by: Bartlomiej Zolnierkiewicz 

It fixes the warning independently of the pata driver - ata_piix 
pata_via pata_serverworks pata_macio 3ware were fixed too.

-- 
Meelis Roos (mr...@linux.ee)


Re: [PATCH] arc: axs103_smp: Fix CPU frequency to 100MHz for dual-core

2016-05-17 Thread Vineet Gupta
On Monday 16 May 2016 03:27 PM, Alexey Brodkin wrote:
> The most recent release of AXS103 [v1.1] is proven to work
> at 100 MHz in dual-core mode so this change uses mentioned feature.
> For that we:
>  * Update axc003_idu.dtsi with mention of really-used CPU clock freq
>  * Remove clock override in AXS platform code for dual-core HW
> 
> Note we're still leaving a hack for clock "downgrade" on early boot
> for quad-core hardware.
> 
> Also note this change will break functionality of AXS103 v1.0 hardware.
> That means all users of AXS103 __must__ upgrade their boards with the
> most recent firmware.
> 
> Signed-off-by: Alexey Brodkin 

Applied for 4.7

Thx,
-Vineet


Re: [PATCH] ARC: Troubleshoot execution of UP Linux on SMP HW and vice versa

2016-05-17 Thread Vineet Gupta
On Wednesday 18 May 2016 02:36 AM, Alexey Brodkin wrote:
> ARC SMP hardware heavily relies on Interrupt Distribution Unit (IDU)
> for all interrupts serving. And UP ARC hardware lacks this block.
> 
> That leads to incompatibility between UP and SMP Linux builds.
> 
> Even though UP build of Linux will run on SMP hardware at some
> point strange behavior will appear. Very good example is serial port
> will stop functioning once it switches from earlycon driver (which
> doesn't use interrupts) to full-scale serial driver (that will rely
> on interrupts).
> 
> The same is applicable to reverse combination: SMP build won't
> work on UP hardware and symptoms will be pretty much the same.

This is not necessarily correct. I'm pretty sure that if u have right DT 
(despite
embedded, if you have uboot provide a different one), SMP kernel will infact 
boot
on UP hardware - and if not - we should actively try to achieve that. That is
where world is moving: fwiw ARM64 kernel forces CONFIG_SMP because and doesn't
even support UP anymore.

> And so to save [especially  newcomers] from spending hours in
> frustration we're doing a check very early on boot if the kernel was
> configured with CONFIG_ARC_MCIP (which is automatically selected as
> a dependency of CONFIG_SMP) and in run-time we're seeing SMP-specific
> register that holds a number of SMP cores.
> 
> Signed-off-by: Alexey Brodkin 
> ---
>  arch/arc/kernel/setup.c | 12 
...
> @@ -374,6 +375,8 @@ static inline int is_kernel(unsigned long addr)
>  
>  void __init setup_arch(char **cmdline_p)
>  {
> + unsigned int num_cores;
> +
>  #ifdef CONFIG_ARC_UBOOT_SUPPORT
>   /* make sure that uboot passed pointer to cmdline/dtb is valid */
>   if (uboot_tag && is_kernel((unsigned long)uboot_arg))
> @@ -413,6 +416,15 @@ void __init setup_arch(char **cmdline_p)
>   if (machine_desc->init_early)
>   machine_desc->init_early();
>  
> + num_cores = (read_aux_reg(ARC_REG_MCIP_BCR) >> 16) & 0x3F;
> +#ifdef CONFIG_ARC_MCIP
> + if (!num_cores)
> + panic("SMP kernel is run on a UP hardware!\n");
> +#else
> + if (num_cores)
> + panic("UP kernel is run on a SMP hardware!\n");
> +#endif

This is ugly: if AXS platform has trouble booting with UP/SMP hw/sw mismatch, do
that in platform early init code w/o littering platform agnostic code unless
absolutely necessary.

> +
>   smp_init_cpus();
>  
>   setup_processor();
> 



Re: [PATCH] net: au1000 eth: simplify logical expression

2016-05-17 Thread Florian Fainelli
Le 17/05/2016 16:58, Heinrich Schuchardt a écrit :
> (a && a > 0) is equivalent to (a > 0).
> 
> Signed-off-by: Heinrich Schuchardt 

Acked-by: Florian Fainelli 
-- 
Florian


Re: Crashes in -next due to 'phy: add support for a reset-gpio specification'

2016-05-17 Thread Florian Fainelli
Le 17/05/2016 21:37, Guenter Roeck a écrit :
> Hi,
> 
> my xtensa qemu tests crash in -next as follows.
> 
> [ ... ]
> 
> [9.366256] libphy: ethoc-mdio: probed
> [9.367389]  (null): could not attach to PHY
> [9.368555]  (null): failed to probe MDIO bus
> [9.371540] Unable to handle kernel paging request at virtual address
> 001c
> [9.371540]  pc = d0320926, ra = 903209d1
> [9.375358] Oops: sig: 11 [#1]
> [9.376081] PREEMPT
> [9.377080] CPU: 0 PID: 1 Comm: swapper Not tainted
> 4.6.0-next-20160517 #1
> [9.378397] task: d7c2c000 ti: d7c3 task.ti: d7c3
> [9.379394] a00: 903209d1 d7c31bd0 d7fb5810 0001 
>  d7f45c00 d7c31bd0
> [9.382298] a08:     00060100
> d04b0c10 d7f45dfc d7c31bb0
> [9.385732] pc: d0320926, ps: 00060110, depc: 0018, excvaddr:
> 001c
> [9.387061] lbeg: d0322e35, lend: d0322e57 lcount: , sar:
> 0011
> [9.388173]
> Stack: d7c31be0 00060700 d7f45c00 d7c31bd0 9021d509 d7c31c30 d7f45c00
> 
>d0485dcc d0485dcc d7fb5810 d7c2c000  d7c31c30 d7f45c00
> d025befc
>d0485dcc d7c3 d7f45c34 d7c31bf0 9021c985 d7c31c50 d7f45c00
> d7f45c34
> [9.396652] Call Trace:
> [9.397469]  [] __device_release_driver+0x7d/0x98
> [9.398869]  [] device_release_driver+0x15/0x20
> [9.400247]  [] bus_remove_device+0xc1/0xd4
> [9.401569]  [] device_del+0x109/0x15c
> [9.402794]  [] phy_mdio_device_remove+0xd/0x18
> [9.404124]  [] mdiobus_unregister+0x40/0x5c
> [9.405444]  [] ethoc_probe+0x534/0x5b8
> [9.406742]  [] platform_drv_probe+0x28/0x48
> [9.408122]  [] driver_probe_device+0x101/0x234
> [9.409499]  [] __driver_attach+0x7d/0x98
> [9.410809]  [] bus_for_each_dev+0x30/0x5c
> [9.412104]  [] driver_attach+0x14/0x18
> [9.413385]  [] bus_add_driver+0xc9/0x198
> [9.414686]  [] driver_register+0x70/0xa0
> [9.416001]  [] __platform_driver_register+0x24/0x28
> [9.417463]  [] ethoc_driver_init+0x10/0x14
> [9.418824]  [] do_one_initcall+0x80/0x1ac
> [9.420083]  [] kernel_init_freeable+0x131/0x198
> [9.421504]  [] kernel_init+0xc/0xb0
> [9.422693]  [] ret_from_kernel_thread+0x8/0xc
> 
> Bisect points to commit da47b4572056 ("phy: add support for a reset-gpio
> specification").
> Bisect log is attached. Reverting the patch fixes the problem.

Aside from what you pointed out, this patch was still in dicussion when
it got merged, since we got a concurrent patch from Sergei which tries
to deal with the same kind of problem.

Do you mind sending a revert, or I can do that first thing in the morning.

> 
> I think there may be a number of problems, all of them exposed by the patch
> but really separate.
> 
> GPIOLIB is not configured in my test case, meaning gpiod_get_optional()
> returns -ENOSYS, and phy_probe() thus returns an error. Question here is if
> it is really appropriate for the XXX_optional() gpiolib functions to return
> an error if GPIOLIB is not configured. Either case, result is that pretty
> much all phy registrations will now fail if GPIOLIB is not configured.
> 
> Also, I suspect that there may be a bug in the error handling path
> of ethoc_probe(). No idea what exactly is wrong, though. Other drivers
> use pretty much the same code sequence for mdio registration and associated
> error handling.
> 
> Last but not least, something seems to be wrong with the use of dev_err()
> with >dev if register_netdev() has not yet been called. Maybe
> someone
> has some insight ?

It all depends if SET_NETDEV_DEV() has had a chance to run, but in
general it is kind of a bad idea to use netdev_* before the interface
has been registered, since it won't have any valid name.
-- 
Florian


[PATCH 1/1] Staging: comedi: fix CHECK: Prefer using the BIT macro issues in pcmmio.c

2016-05-17 Thread Ravishankar Karkala Mallikarjunayya
This patch Replace all occurences of (1<
---
 drivers/staging/comedi/drivers/pcmmio.c | 40 -
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/comedi/drivers/pcmmio.c 
b/drivers/staging/comedi/drivers/pcmmio.c
index 10472e6..70ad497 100644
--- a/drivers/staging/comedi/drivers/pcmmio.c
+++ b/drivers/staging/comedi/drivers/pcmmio.c
@@ -84,25 +84,25 @@
 #define PCMMIO_AI_LSB_REG  0x00
 #define PCMMIO_AI_MSB_REG  0x01
 #define PCMMIO_AI_CMD_REG  0x02
-#define PCMMIO_AI_CMD_SE   (1 << 7)
-#define PCMMIO_AI_CMD_ODD_CHAN (1 << 6)
+#define PCMMIO_AI_CMD_SE   BIT(7)
+#define PCMMIO_AI_CMD_ODD_CHAN BIT(6)
 #define PCMMIO_AI_CMD_CHAN_SEL(x)  (((x) & 0x3) << 4)
 #define PCMMIO_AI_CMD_RANGE(x) (((x) & 0x3) << 2)
 #define PCMMIO_RESOURCE_REG0x02
 #define PCMMIO_RESOURCE_IRQ(x) (((x) & 0xf) << 0)
 #define PCMMIO_AI_STATUS_REG   0x03
-#define PCMMIO_AI_STATUS_DATA_READY(1 << 7)
-#define PCMMIO_AI_STATUS_DATA_DMA_PEND (1 << 6)
-#define PCMMIO_AI_STATUS_CMD_DMA_PEND  (1 << 5)
-#define PCMMIO_AI_STATUS_IRQ_PEND  (1 << 4)
-#define PCMMIO_AI_STATUS_DATA_DRQ_ENA  (1 << 2)
-#define PCMMIO_AI_STATUS_REG_SEL   (1 << 3)
-#define PCMMIO_AI_STATUS_CMD_DRQ_ENA   (1 << 1)
-#define PCMMIO_AI_STATUS_IRQ_ENA   (1 << 0)
+#define PCMMIO_AI_STATUS_DATA_READYBIT(7)
+#define PCMMIO_AI_STATUS_DATA_DMA_PEND BIT(6)
+#define PCMMIO_AI_STATUS_CMD_DMA_PEND  BIT(5)
+#define PCMMIO_AI_STATUS_IRQ_PEND  BIT(4)
+#define PCMMIO_AI_STATUS_DATA_DRQ_ENA  BIT(2)
+#define PCMMIO_AI_STATUS_REG_SEL   BIT(3)
+#define PCMMIO_AI_STATUS_CMD_DRQ_ENA   BIT(1)
+#define PCMMIO_AI_STATUS_IRQ_ENA   BIT(0)
 #define PCMMIO_AI_RES_ENA_REG  0x03
 #define PCMMIO_AI_RES_ENA_CMD_REG_ACCESS   (0 << 3)
-#define PCMMIO_AI_RES_ENA_AI_RES_ACCESS(1 << 3)
-#define PCMMIO_AI_RES_ENA_DIO_RES_ACCESS   (1 << 4)
+#define PCMMIO_AI_RES_ENA_AI_RES_ACCESSBIT(3)
+#define PCMMIO_AI_RES_ENA_DIO_RES_ACCESS   BIT(4)
 #define PCMMIO_AI_2ND_ADC_OFFSET   0x04
 
 #define PCMMIO_AO_LSB_REG  0x08
@@ -125,14 +125,14 @@
 #define PCMMIO_AO_CMD_CHAN_SEL(x)  (((x) & 0x03) << 1)
 #define PCMMIO_AO_CMD_CHAN_SEL_ALL (0x0f << 0)
 #define PCMMIO_AO_STATUS_REG   0x0b
-#define PCMMIO_AO_STATUS_DATA_READY(1 << 7)
-#define PCMMIO_AO_STATUS_DATA_DMA_PEND (1 << 6)
-#define PCMMIO_AO_STATUS_CMD_DMA_PEND  (1 << 5)
-#define PCMMIO_AO_STATUS_IRQ_PEND  (1 << 4)
-#define PCMMIO_AO_STATUS_DATA_DRQ_ENA  (1 << 2)
-#define PCMMIO_AO_STATUS_REG_SEL   (1 << 3)
-#define PCMMIO_AO_STATUS_CMD_DRQ_ENA   (1 << 1)
-#define PCMMIO_AO_STATUS_IRQ_ENA   (1 << 0)
+#define PCMMIO_AO_STATUS_DATA_READYBIT(7)
+#define PCMMIO_AO_STATUS_DATA_DMA_PEND BIT(6)
+#define PCMMIO_AO_STATUS_CMD_DMA_PEND  BIT(5)
+#define PCMMIO_AO_STATUS_IRQ_PEND  BIT(4)
+#define PCMMIO_AO_STATUS_DATA_DRQ_ENA  BIT(2)
+#define PCMMIO_AO_STATUS_REG_SEL   BIT(3)
+#define PCMMIO_AO_STATUS_CMD_DRQ_ENA   BIT(1)
+#define PCMMIO_AO_STATUS_IRQ_ENA   BIT(0)
 #define PCMMIO_AO_RESOURCE_ENA_REG 0x0b
 #define PCMMIO_AO_2ND_DAC_OFFSET   0x04
 
-- 
1.9.1



Crashes in -next due to 'phy: add support for a reset-gpio specification'

2016-05-17 Thread Guenter Roeck

Hi,

my xtensa qemu tests crash in -next as follows.

[ ... ]

[9.366256] libphy: ethoc-mdio: probed
[9.367389]  (null): could not attach to PHY
[9.368555]  (null): failed to probe MDIO bus
[9.371540] Unable to handle kernel paging request at virtual address 
001c
[9.371540]  pc = d0320926, ra = 903209d1
[9.375358] Oops: sig: 11 [#1]
[9.376081] PREEMPT
[9.377080] CPU: 0 PID: 1 Comm: swapper Not tainted 4.6.0-next-20160517 #1
[9.378397] task: d7c2c000 ti: d7c3 task.ti: d7c3
[9.379394] a00: 903209d1 d7c31bd0 d7fb5810 0001   
d7f45c00 d7c31bd0
[9.382298] a08:     00060100 d04b0c10 
d7f45dfc d7c31bb0
[9.385732] pc: d0320926, ps: 00060110, depc: 0018, excvaddr: 001c
[9.387061] lbeg: d0322e35, lend: d0322e57 lcount: , sar: 0011
[9.388173]
Stack: d7c31be0 00060700 d7f45c00 d7c31bd0 9021d509 d7c31c30 d7f45c00 
   d0485dcc d0485dcc d7fb5810 d7c2c000  d7c31c30 d7f45c00 d025befc
   d0485dcc d7c3 d7f45c34 d7c31bf0 9021c985 d7c31c50 d7f45c00 d7f45c34
[9.396652] Call Trace:
[9.397469]  [] __device_release_driver+0x7d/0x98
[9.398869]  [] device_release_driver+0x15/0x20
[9.400247]  [] bus_remove_device+0xc1/0xd4
[9.401569]  [] device_del+0x109/0x15c
[9.402794]  [] phy_mdio_device_remove+0xd/0x18
[9.404124]  [] mdiobus_unregister+0x40/0x5c
[9.405444]  [] ethoc_probe+0x534/0x5b8
[9.406742]  [] platform_drv_probe+0x28/0x48
[9.408122]  [] driver_probe_device+0x101/0x234
[9.409499]  [] __driver_attach+0x7d/0x98
[9.410809]  [] bus_for_each_dev+0x30/0x5c
[9.412104]  [] driver_attach+0x14/0x18
[9.413385]  [] bus_add_driver+0xc9/0x198
[9.414686]  [] driver_register+0x70/0xa0
[9.416001]  [] __platform_driver_register+0x24/0x28
[9.417463]  [] ethoc_driver_init+0x10/0x14
[9.418824]  [] do_one_initcall+0x80/0x1ac
[9.420083]  [] kernel_init_freeable+0x131/0x198
[9.421504]  [] kernel_init+0xc/0xb0
[9.422693]  [] ret_from_kernel_thread+0x8/0xc

Bisect points to commit da47b4572056 ("phy: add support for a reset-gpio 
specification").
Bisect log is attached. Reverting the patch fixes the problem.

I think there may be a number of problems, all of them exposed by the patch
but really separate.

GPIOLIB is not configured in my test case, meaning gpiod_get_optional()
returns -ENOSYS, and phy_probe() thus returns an error. Question here is if
it is really appropriate for the XXX_optional() gpiolib functions to return
an error if GPIOLIB is not configured. Either case, result is that pretty
much all phy registrations will now fail if GPIOLIB is not configured.

Also, I suspect that there may be a bug in the error handling path
of ethoc_probe(). No idea what exactly is wrong, though. Other drivers
use pretty much the same code sequence for mdio registration and associated
error handling.

Last but not least, something seems to be wrong with the use of dev_err()
with >dev if register_netdev() has not yet been called. Maybe someone
has some insight ?

Test scripts and root file system used for the test are available at
https://github.com/groeck/linux-build-test/tree/master/rootfs/xtensa.

Guenter

---
# bad: [31b8ce4d1f8150fdc29d2f8a649dc4835e7f2961] arm: Use _rcuidle suffix to 
allow clk_core_enable() to used from idle
# good: [2dcd0af568b0cf583645c8a317dd12e344b1c72a] Linux 4.6
git bisect start 'HEAD' 'v4.6'
# bad: [dfd08ad591ff4f6d19896f21fb6c10dc4998dae4] Merge remote-tracking branch 
'net-next/master'
git bisect bad dfd08ad591ff4f6d19896f21fb6c10dc4998dae4
# good: [eeb1cd39e9e27d89375b33c3a907807fb5adba7e] Merge remote-tracking branch 
'xfs/for-next'
git bisect good eeb1cd39e9e27d89375b33c3a907807fb5adba7e
# good: [b75803d52a2ce1f6cbaf7ae0ae40a369210070cf] tcp: refactor struct 
tcp_skb_cb
git bisect good b75803d52a2ce1f6cbaf7ae0ae40a369210070cf
# good: [c2f40435ab0963284d348993b10ac66de6329b74] Merge remote-tracking branch 
'v4l-dvb/master'
git bisect good c2f40435ab0963284d348993b10ac66de6329b74
# good: [678c657e09034d6f87d254b3183873d6e4a493e4] Merge remote-tracking branch 
'slave-dma/next'
git bisect good 678c657e09034d6f87d254b3183873d6e4a493e4
# good: [6a47a570321fdcd2b6fc9e6537b2a3650d0fd04b] Merge branch 'mlx5-next'
git bisect good 6a47a570321fdcd2b6fc9e6537b2a3650d0fd04b
# good: [06566e5dd4e53f57fc3daa12fb8b5252772d70de] i40e: Refactor ethtool 
get_settings
git bisect good 06566e5dd4e53f57fc3daa12fb8b5252772d70de
# bad: [10cbc6843446165ee250e1ee80dc19ee325f1e6d] net/sched: cls_flower: 
Hardware offloaded filters statistics support
git bisect bad 10cbc6843446165ee250e1ee80dc19ee325f1e6d
# bad: [da47b4572056487fd7941c26f73b3e8815ff712a] phy: add support for a 
reset-gpio specification
git bisect bad da47b4572056487fd7941c26f73b3e8815ff712a
# good: [5049e33b559a44e9f216d86c58c7c7fce6f5df2f] bnxt_en: Add BCM57314 device 
ID.
git bisect good 5049e33b559a44e9f216d86c58c7c7fce6

Re: [PATCH v2 1/9] powerpc/powernv: Move CHECK_HMI_INTERRUPT to exception-64s header

2016-05-17 Thread Gautham R Shenoy
On Tue, May 03, 2016 at 01:54:30PM +0530, Shreyas B. Prabhu wrote:
> CHECK_HMI_INTERRUPT is used to check for HMI's in reset vector. Move
> the macro to a common location (exception-64s.h)
> This patch does not change any functionality.
> 

I suppose this code movement is to facilitate the invocation of
CHECK_HMI_INTERRUPT in some later patch ? In this case you could
add this to the commit message.

Otherwise,
Reviewed-by: Gautham R. Shenoy 
> ---
>  arch/powerpc/include/asm/exception-64s.h | 18 ++
>  arch/powerpc/kernel/idle_power7.S| 20 +---
>  2 files changed, 19 insertions(+), 19 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/exception-64s.h 
> b/arch/powerpc/include/asm/exception-64s.h
> index 93ae809..6a625af 100644
> --- a/arch/powerpc/include/asm/exception-64s.h
> +++ b/arch/powerpc/include/asm/exception-64s.h
> @@ -545,4 +545,22 @@ END_FTR_SECTION_IFSET(CPU_FTR_CAN_NAP)
>  #define FINISH_NAP
>  #endif
> 
> +#define CHECK_HMI_INTERRUPT  \
> + mfspr   r0,SPRN_SRR1;   \
> +BEGIN_FTR_SECTION_NESTED(66);
> \
> + rlwinm  r0,r0,45-31,0xf;  /* extract wake reason field (P8) */  \
> +FTR_SECTION_ELSE_NESTED(66); \
> + rlwinm  r0,r0,45-31,0xe;  /* P7 wake reason field is 3 bits */  \
> +ALT_FTR_SECTION_END_NESTED_IFSET(CPU_FTR_ARCH_207S, 66); \
> + cmpwi   r0,0xa; /* Hypervisor maintenance ? */  \
> + bne 20f;\
> + /* Invoke opal call to handle hmi */\
> + ld  r2,PACATOC(r13);\
> + ld  r1,PACAR1(r13); \
> + std r3,ORIG_GPR3(r1);   /* Save original r3 */  \
> + li  r0,OPAL_HANDLE_HMI; /* Pass opal token argument*/   \
> + bl  opal_call_realmode; \
> + ld  r3,ORIG_GPR3(r1);   /* Restore original r3 */   \
> +20:  nop;
> +
>  #endif   /* _ASM_POWERPC_EXCEPTION_H */
> diff --git a/arch/powerpc/kernel/idle_power7.S 
> b/arch/powerpc/kernel/idle_power7.S
> index 470ceeb..6b3404b 100644
> --- a/arch/powerpc/kernel/idle_power7.S
> +++ b/arch/powerpc/kernel/idle_power7.S
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> 
>  #undef DEBUG
> @@ -257,25 +258,6 @@ _GLOBAL(power7_winkle)
>   b   power7_powersave_common
>   /* No return */
> 
> -#define CHECK_HMI_INTERRUPT  \
> - mfspr   r0,SPRN_SRR1;   \
> -BEGIN_FTR_SECTION_NESTED(66);
> \
> - rlwinm  r0,r0,45-31,0xf;  /* extract wake reason field (P8) */  \
> -FTR_SECTION_ELSE_NESTED(66); \
> - rlwinm  r0,r0,45-31,0xe;  /* P7 wake reason field is 3 bits */  \
> -ALT_FTR_SECTION_END_NESTED_IFSET(CPU_FTR_ARCH_207S, 66); \
> - cmpwi   r0,0xa; /* Hypervisor maintenance ? */  \
> - bne 20f;\
> - /* Invoke opal call to handle hmi */\
> - ld  r2,PACATOC(r13);\
> - ld  r1,PACAR1(r13); \
> - std r3,ORIG_GPR3(r1);   /* Save original r3 */  \
> - li  r0,OPAL_HANDLE_HMI; /* Pass opal token argument*/   \
> - bl  opal_call_realmode; \
> - ld  r3,ORIG_GPR3(r1);   /* Restore original r3 */   \
> -20:  nop;
> -
> -
>  _GLOBAL(power7_wakeup_tb_loss)
>   ld  r2,PACATOC(r13);
>   ld  r1,PACAR1(r13)
> -- 
> 2.4.11
> 



linux-next: Tree for May 18

2016-05-17 Thread Stephen Rothwell
Hi all,

Please do not add any v4.8 destined material to your linux-next included
branches until after v4.7-rc1 has been released.

Changes since 20160517:

New tree: dax-misc

The dax-misc tree gained a conflict against the nvdimm tree.

The akpm-current tree gained a conflict against the dax-misc tree.

Non-merge commits (relative to Linus' tree): 8785
 7390 files changed, 389214 insertions(+), 158994 deletions(-)



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

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 236 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (7f427d3a6029 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs)
Merging fixes/master (b507146bb6b9 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (44549e8f5eea Linux 4.6-rc7)
Merging arm-current/fixes (ec953b70f368 ARM: 8573/1: domain: move 
{set,get}_domain under config guard)
Merging m68k-current/for-linus (9a6462763b17 m68k/mvme16x: Include generic 
)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (b4c112114aab powerpc: Fix bad inline asm 
constraint in create_zero_mask())
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (33656a1f2ee5 Merge branch 'for_linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs)
Merging net/master (2dcd0af568b0 Linux 4.6)
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (f28f20da704d Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging wireless-drivers/master (cbbba30f1ac9 Merge tag 
'iwlwifi-for-kalle-2016-05-04' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (e6436be21e77 mac80211: fix statistics leak if 
dev_alloc_name() fails)
Merging sound-current/for-linus (c7c5856b6f6f sound: oss: Use setup_timer and 
mod_timer.)
Merging pci-current/for-linus (9a2a5a638f8e PCI: Do not treat EPROBE_DEFER as 
device attach failure)
Merging driver-core.current/driver-core-linus (c3b46c73264b Linux 4.6-rc4)
Merging tty.current/tty-linus (44549e8f5eea Linux 4.6-rc7)
Merging usb.current/usb-linus (44549e8f5eea Linux 4.6-rc7)
Merging usb-gadget-fixes/fixes (38740a5b87d5 usb: gadget: f_fs: Fix 
use-after-free)
Merging usb-serial-fixes/usb-linus (74d2a91aec97 USB: serial: option: add even 
more ZTE device ids)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (44549e8f5eea Linux 4.6-rc7)
Merging char-misc.current/char-misc-linus (44549e8f5eea Linux 4.6-rc7)
Merging input-current/for-linus (23ea5967d6bd Merge branch 'next' into 
for-linus)
Merging crypto-current/master (4a6b27b79da5 crypto: sha1-mb - make 
sha1_x8_avx2() conform to C function ABI)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (8160c4e45582 v

Re: [PATCH] mmc: dw_mmc: Consider HLE errors to be data and command errors

2016-05-17 Thread Doug Anderson
Hi,

On Tue, May 17, 2016 at 7:08 PM, Jaehoon Chung  wrote:
> On 05/18/2016 09:47 AM, Doug Anderson wrote:
>> Jaehoon,
>>
>> On Mon, Mar 30, 2015 at 8:47 AM, Doug Anderson  wrote:
>>> Jaehoon,
>>>
>>> On Sun, Mar 29, 2015 at 5:55 PM, Jaehoon Chung  
>>> wrote:
 Dear Doug,

 I'm considering to control HLE error..So holding this patch.
 If this is absolutely necessary patch, let me know, plz.

 Best Regards,
 Jaehoon Chung
>>>
>>> Sounds OK.  I have certainly applied this locally and the driver isn't
>>> robust against insertions / removals without it, but once the card is
>>> inserted things are OK so it's probably not urgent that it be applied
>>> upstream.  Hopefully we can figure out a better solution...
>>
>> I'm now testing a nice new rebased kernel and I'm hitting this again.
>>
>> Of course I'll just pick my same patch to my new kernel tree, but
>> since it's been a year and nobody has done anything better, would you
>> consider landing my patch?  It is certainly better than nothing.
>
> Sure, it's right.
> I think that main reason of HLE is wait_prvdata_complete. (I'm guessing..)
> On other hands, dwmmc controller is handling something wrong. (I found that 
> HLE is occurred the similar case.)
> After find the main solution, it's not bad that your patch is applied on 
> dwmmc controller.
>
> Ulf have sent PR for next..So if we needs to apply this, i will apply on fix.

It's not new, so I'd say just queue it up for the next version
whenever it's convenient.

-Doug


Re: [PATCH] mmc: dw_mmc: Consider HLE errors to be data and command errors

2016-05-17 Thread Doug Anderson
Hi,

On Tue, May 17, 2016 at 6:59 PM, Shawn Lin
 wrote:
> Could you try this patch to see if you can still find HLE?
>
> @@ -2356,12 +2356,22 @@ static void dw_mci_cmd_interrupt(struct dw_mci
> *host, u32 status)
>  static void dw_mci_handle_cd(struct dw_mci *host)
>  {
> int i;
> +   int present;
>
> for (i = 0; i < host->num_slots; i++) {
> struct dw_mci_slot *slot = host->slot[i];
>
> if (!slot)
> continue;
>
> +   present = !(mci_readl(slot->host, CDETECT) & (1 <<
> slot->id));
> +   if (present)
> +   set_bit(DW_MMC_CARD_PRESENT, >flags);
> +   else
> +   clear_bit(DW_MMC_CARD_PRESENT, >flags);

No, because we don't use the builtin card detect on veyron.  ;)

We use GPIO card detect because we didn't like the way JTAG and SD
interacted.  Also on rk3288 the builtin card detect line had the wrong
voltage domain (you couldn't detect a card when the IO lines were
powered off).  The builtin card detect line is always driven low on
veyron.


I'm nearly certain that the root cause of my HLE errors is actually
related to the same problem addressed by the commit 7c5209c315ea
("mmc: core: Increase delay for voltage to stabilize from 3.3V to
1.8V").  I think that on minnie we're still on the hairy edge and
sometimes the line doesn't transition fast enough.

It appears that increasing this to 30ms avoids the HLE errors.

I _think_ I can actually fully fix this properly by temporarily
engaging the internal pull-ups while the voltage switch is happening.
This will bleed away the voltage just a little bit faster (since lines
are driven low here).  I'll try to confirm that.


In any case, it seems like we should take this patch since (without
this patch) the failure case when you get HLE errors is that the
interrupt controller fires over and over again (with no printouts) and
your system stalls with no error messages.

-Doug


Re: QRTR merge conflict resolution

2016-05-17 Thread Bjorn Andersson
On Tue 17 May 17:43 PDT 2016, Stephen Rothwell wrote:

> Hi David,
> 
> On Tue, 17 May 2016 14:11:54 -0400 (EDT) David Miller  
> wrote:
> >
> > From: Bjorn Andersson 
> > Date: Fri, 13 May 2016 15:19:09 -0700
> > 
> > > I have prepared the merge of net-next and the conflicting tag from the
> > > Qualcomm SOC, please include this in your pull towards Linus to avoid
> > > the merge conflict.  
> > 
> > Pulled, thanks.
> 
> Except in the merge resolution, the 2 new functions added to
> include/linux/soc/qcom/smd.h (qcom_smd_get_drvdata and
> qcom_smd_set_drvdata) were not marked "static inline" :-(
> 

How silly of me to miss that, sorry about that.

I didn't spot this in my compile testing either, because this is the
only driver in the tree including that file that doesn't depend on
QCOM_SMD.

As there is no immediate problem with moving forward I suggest that I'll
fix this, through arm-soc, once the code has landed.

Regards,
Bjorn


Re: [PATCH] sched/cputime: add steal time support to full dynticks CPU time accounting

2016-05-17 Thread Rik van Riel
On Tue, 2016-05-10 at 13:34 +0800, Wanpeng Li wrote:
> From: Wanpeng Li 
> 
> This patch adds steal guest time support to full dynticks CPU time 
> accounting. After commit ff9a9b4c(sched, time: Switch
> VIRT_CPU_ACCOUNTING_GEN 
> to jiffy granularity), time is jiffy based sampling even if it's 
> still listened to ring boundaries, so steal_account_process_tick() 
> is reused to account how much 'ticks' are steal time after the 
> last accumulation. 
> 
> Suggested-by: Rik van Riel 
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra (Intel) 
> Cc: Rik van Riel 
> Cc: Thomas Gleixner 
> Cc: Frederic Weisbecker 
> Cc: Paolo Bonzini 
> Cc: Radim 
> Signed-off-by: Wanpeng Li 
> 

Acked-by: Rik van Riel 

-- 
All Rights Reversed.



signature.asc
Description: This is a digitally signed message part


Re: [PATCH v12 05/10] arm64: Kprobes with single stepping support

2016-05-17 Thread Masami Hiramatsu
On Thu, 12 May 2016 16:01:54 +0100
James Morse  wrote:

> Hi David, Sandeepa,
> 
> On 27/04/16 19:53, David Long wrote:
> > From: Sandeepa Prabhu 
> 
> > diff --git a/arch/arm64/kernel/kprobes.c b/arch/arm64/kernel/kprobes.c
> > new file mode 100644
> > index 000..dfa1b1f
> > --- /dev/null
> > +++ b/arch/arm64/kernel/kprobes.c
> > @@ -0,0 +1,520 @@
> > +/*
> > + * arch/arm64/kernel/kprobes.c
> > + *
> > + * Kprobes support for ARM64
> > + *
> > + * Copyright (C) 2013 Linaro Limited.
> > + * Author: Sandeepa Prabhu 
> > + *
> > + * 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.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> > + * General Public License for more details.
> > + *
> > + */
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "kprobes-arm64.h"
> > +
> > +#define MIN_STACK_SIZE(addr)   min((unsigned long)MAX_STACK_SIZE,  
> > \
> > +   (unsigned long)current_thread_info() + THREAD_START_SP - (addr))
> 
> What if we probe something called on the irq stack?
> This needs the on_irq_stack() checks too, the start/end can be found from the
> per-cpu irq_stack value.
> 
> [ ... ]
> 
> > +int __kprobes setjmp_pre_handler(struct kprobe *p, struct pt_regs *regs)
> > +{
> > +   struct jprobe *jp = container_of(p, struct jprobe, kp);
> > +   struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
> > +   long stack_ptr = kernel_stack_pointer(regs);
> > +
> > +   kcb->jprobe_saved_regs = *regs;
> > +   memcpy(kcb->jprobes_stack, (void *)stack_ptr,
> > +  MIN_STACK_SIZE(stack_ptr));
> 
> I wonder if we need this stack save/restore?
> 
> The comment next to the equivalent code for x86 says:
> > gcc assumes that the callee owns the argument space and could overwrite it,
> > e.g. tailcall optimization. So, to be absolutely safe we also save and
> > restore enough stack bytes to cover the argument area.
> 
> On arm64 the first eight arguments are passed in registers, so we might not 
> need
> this stack copy. (sparc and powerpc work like this too, their versions of this
> function don't copy chunks of the stack).

Hmm, maybe sparc and powerpc implementation should also be fixed...

> ... then I went looking for functions with >8 arguments...
> 
> Looking at the arm64 defconfig dwarf debug data, there are 71 of these that
> don't get inlined, picking at random:
> > rockchip_clk_register_pll() has 13
> > fib_dump_info() has 11
> > vma_merge() has 10
> > vring_create_virtqueue() has 10
> etc...
> 
> So we do need this stack copying, so that we can probe these function without
> risking the arguments being modified.
> 
> It may be worth including a comment to the effect that this stack save/restore
> is needed for functions that pass >8 arguments where the pre-handler may 
> change
> these values on the stack.

Indeed, commenting on this code can help us to understand the reason why.

Thank you!

> 
> 
> > +   preempt_enable_no_resched();
> > +   return 1;
> > +}
> > +
> 
> 
> Thanks,
> 
> James


-- 
Masami Hiramatsu 


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

2016-05-17 Thread Stephen Rothwell
Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in:

  include/linux/dax.h

between commit:

  ecdb4bf9e327 ("dax: export a low-level __dax_zero_page_range helper")

from the dax-misc tree and commit:

  29d44f6759f6 ("dax: add dax_get_unmapped_area for pmd mappings")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/dax.h
index 7743e51f826c,184b1714900c..
--- a/include/linux/dax.h
+++ b/include/linux/dax.h
@@@ -14,19 -17,15 +14,22 @@@ int __dax_fault(struct vm_area_struct *
  
  #ifdef CONFIG_FS_DAX
  struct page *read_dax_sector(struct block_device *bdev, sector_t n);
 +int __dax_zero_page_range(struct block_device *bdev, sector_t sector,
 +  unsigned int offset, unsigned int length);
+ unsigned long dax_get_unmapped_area(struct file *filp, unsigned long addr,
+   unsigned long len, unsigned long pgoff, unsigned long flags);
  #else
  static inline struct page *read_dax_sector(struct block_device *bdev,
sector_t n)
  {
return ERR_PTR(-ENXIO);
  }
 +static inline int __dax_zero_page_range(struct block_device *bdev,
 +  sector_t sector, unsigned int offset, unsigned int length)
 +{
 +  return -ENXIO;
 +}
+ #define dax_get_unmapped_area NULL
  #endif
  
  #ifdef CONFIG_TRANSPARENT_HUGEPAGE


[PATCH] MM: increase safety margin provided by PF_LESS_THROTTLE

2016-05-17 Thread NeilBrown

When nfsd is exporting a filesystem over NFS which is then NFS-mounted
on the local machine there is a risk of deadlock.  This happens when
there are lots of dirty pages in the NFS filesystem and they cause
NFSD to be throttled, either in throttle_vm_writeout() or in
balance_dirty_pages().

To avoid this problem the PF_LESS_THROTTLE flag is set for NFSD
threads and it provides a 25% increase to the limits that affect NFSD.
Any process writing to an NFS filesystem will be throttled well
before the number of dirty NFS pages reaches the limit imposed on
NFSD, so NFSD will not deadlock on pages that it needs to write out.
At least it shouldn't.

All processes are allowed a small excess margin to avoid performing
too many calculations: ratelimit_pages.

ratelimit_pages is set so that if a thread on every CPU uses the
entire margin, the total will only go 3% over the limit, and this is
much less than the 25% bonus that PF_LESS_THROTTLE provides, so this
margin shouldn't be a problem.  But it is.

The "total memory" that these 3% and 25% are calculated against are not
really total memory but are "global_dirtyable_memory()" which doesn't
include anonymous memory, just free memory and page-cache memory.

The "ratelimit_pages" number is based on whatever the
global_dirtyable_memory was on the last CPU hot-plug, which might not
be what you expect, but is probably close to the total freeable memory.

The throttle threshold uses the global_dirtable_memory at the moment
when the throttling happens, which could be much less than at the last
CPU hotplug.  So if lots of anonymous memory has been allocated, thus
pushing out lots of page-cache pages, then NFSD might end up being
throttled due to dirty NFS pages because the "25%" bonus it gets is
calculated against a rather small amount of dirtyable memory, while
the "3%" margin that other processes are allowed to dirty without
penalty is calculated against a much larger number.

To remove this possibility of deadlock we need to make sure that the
margin granted to PF_LESS_THROTTLE exceeds that rate-limit margin.
Simply adding ratelimit_pages isn't enough as that should be
multiplied by the number of cpus.

So add "global_wb_domain.dirty_limit / 32" as that more accurately
reflects the current total over-shoot margin.  This ensures that the
number of dirty NFS pages never gets so high that nfsd will be
throttled waiting for them to be written.

Signed-off-by: NeilBrown 

diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index bc5149d5ec38..bbdcd7ccef57 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -407,8 +407,8 @@ static void domain_dirty_limits(struct 
dirty_throttle_control *dtc)
bg_thresh = thresh / 2;
tsk = current;
if (tsk->flags & PF_LESS_THROTTLE || rt_task(tsk)) {
-   bg_thresh += bg_thresh / 4;
-   thresh += thresh / 4;
+   bg_thresh += bg_thresh / 4 + global_wb_domain.dirty_limit / 32;
+   thresh += thresh / 4 + global_wb_domain.dirty_limit / 32;
}
dtc->thresh = thresh;
dtc->bg_thresh = bg_thresh;


signature.asc
Description: PGP signature


Re: [GIT] Networking

2016-05-17 Thread Emmanuel Grumbach
On Wed, May 18, 2016 at 4:00 AM, Linus Torvalds
 wrote:
> On Tue, May 17, 2016 at 12:11 PM, David Miller  wrote:
>>
>> Highlights:
>
> Lowlights:
>
>  1) the iwlwifi driver seems to be broken
>
> My laptop that uses the intel 7680 iwlwifi module no longer connects
> to the network. It fails with a "Microcode SW error detected." and
> spews out register state over and over again.

Can we have the register state and the ASSERT / NMI / whatever that
goes along with it?
This clearly means that the firmware is crashing, but I don't know why,
I copied here the lines that I need from another bug with another
device with another firmware,
but the log that we will still explain what I need:

[  800.880402] iwlwifi :02:00.0: Start IWL Error Log Dump:
[  800.880406] iwlwifi :02:00.0: Status: 0x, count: 6
[  800.880409] iwlwifi :02:00.0: Loaded firmware version: 21.311951.0
[  800.880413] iwlwifi :02:00.0: 0x0394 | ADVANCED_SYSASSERT
[  800.880416] iwlwifi :02:00.0: 0x0220 | trm_hw_status0
[  800.880419] iwlwifi :02:00.0: 0x | trm_hw_status1
[  800.880422] iwlwifi :02:00.0: 0x0BD8 | branchlink2
[  800.880425] iwlwifi :02:00.0: 0x00026AC4 | interruptlink1
[  800.880428] iwlwifi :02:00.0: 0x | interruptlink2
[  800.880431] iwlwifi :02:00.0: 0x0001 | data1
[  800.880434] iwlwifi :02:00.0: 0x02039845 | data2
[  800.880437] iwlwifi :02:00.0: 0x0056 | data3
[  800.880440] iwlwifi :02:00.0: 0x8E4184A7 | beacon time
[  800.880443] iwlwifi :02:00.0: 0x30E2CB41 | tsf low
[  800.880446] iwlwifi :02:00.0: 0x0027 | tsf hi
[  800.880449] iwlwifi :02:00.0: 0x | time gp1
[  800.880451] iwlwifi :02:00.0: 0x2F842F8A | time gp2
[  800.880454] iwlwifi :02:00.0: 0x | uCode revision type
[  800.880457] iwlwifi :02:00.0: 0x0015 | uCode version major
[  800.880460] iwlwifi :02:00.0: 0x0004C28F | uCode version minor
[  800.880463] iwlwifi :02:00.0: 0x0201 | hw version
[  800.880466] iwlwifi :02:00.0: 0x00489008 | board version
[  800.880469] iwlwifi :02:00.0: 0x001C | hcmd
[  800.880472] iwlwifi :02:00.0: 0x24022000 | isr0
[  800.880475] iwlwifi :02:00.0: 0x0100 | isr1
[  800.880478] iwlwifi :02:00.0: 0x580A | isr2
[  800.880481] iwlwifi :02:00.0: 0x4041FCC1 | isr3
[  800.880483] iwlwifi :02:00.0: 0x | isr4
[  800.880486] iwlwifi :02:00.0: 0x00800110 | last cmd Id
[  800.880489] iwlwifi :02:00.0: 0x | wait_event
[  800.880492] iwlwifi :02:00.0: 0x02C8 | l2p_control
[  800.880495] iwlwifi :02:00.0: 0x00018030 | l2p_duration
[  800.880498] iwlwifi :02:00.0: 0x00BF | l2p_mhvalid
[  800.880501] iwlwifi :02:00.0: 0x00EF | l2p_addr_match
[  800.880503] iwlwifi :02:00.0: 0x000D | lmpm_pmg_sel
[  800.880506] iwlwifi :02:00.0: 0x30031805 | timestamp
[  800.880509] iwlwifi :02:00.0: 0xE0F0 | flow_handler




>
> The last thing it says before falling over is:
>
>   wlp1s0: authenticate with xx:xx:xx:xx:xx:xx
>   wlp1s0: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
>   wlp1s0: send auth to xx:xx:xx:xx:xx:xx (try 2/3)
>
> and then it goes all titsup.
>
> I thought that it might be because I had downloaded one of the daily
> firmware versions (it calls itself iwlwifi-7260-17.ucode, but isn't a
> real release afaik - but it has worked fien for me before), but the
> problem persists with the ver-16 ucode too, so that wasn't it.
>
> I haven't bisected it, but there is absolutely nothing odd in my hardware.
>
> I do have a 802.11ac network, which apparently not everybody does,
> judging by previous bug-reports of mine..
>
> Intel iwlwifi people: please check this out.
>
>Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


linux-next: manual merge of the dax-misc tree with the nvdimm tree

2016-05-17 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the dax-misc tree got a conflict in:

  fs/block_dev.c

between commit:

  8044aae6f374 ("Revert "block: enable dax for raw block devices"")

from the nvdimm tree and commit:

  02fbd139759f ("dax: Remove complete_unwritten argument")

from the dax-misc tree.

I fixed it up (the former removed the code modified by the latter) and
can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell


Re: 45aebeaf4f67 "ovl: Ensure upper filesystem supports d_type" breaking Docker

2016-05-17 Thread Daniel Axtens
Hi Vivek,

My sincere apologies - it turns out I *was* running on xfs with
ftype=0. Someone in the office had moved docker's storage without
me noticing.

Apologies to all whose time I wasted.

Regards,
Daniel

Vivek Goyal  writes:

> On Tue, May 17, 2016 at 10:15:21AM +0200, Miklos Szeredi wrote:
>> On Tue, May 17, 2016 at 8:28 AM, Al Viro  wrote:
>> > On Mon, May 16, 2016 at 09:07:27AM -0400, Vivek Goyal wrote:
>> >> So it became clear that we need a check at mount time to make sure
>> >> d_type is supported otherwise error out. This will require users to
>> >> do mkfs.xfs with ftype=1 to make progress.
>> >>
>> >> I think new defaults for mkfs.xfs are such that ftype=1 is set. I am
>> >> not sure which version that change was made in.
>> >
>> > Dumb question - can we end up with empty workdir at that point?  Because
>> > if we do, the check would appear to return a false negative, no matter
>> > what fs supports...
>> 
>> ovl_workdir_create() creates a subdirectory of workdir ("work") so
>> workdir itself won't be empty after that.  If somebody else messes
>> with workdir, then we are screwed anyway.
>
> Right. Initially I was creating a directory of my own and later realized
> that ovl_workdir_create() already creates one.
>
> Having said that, what happens when ovl_workdir_create() fails and we
> mount overlayfs read only. In that case I think we will conclude that
> underlying fs does not support d_type and mounting will fail.
>
> Any thoughts, on how to handle this failure path better?
>
> Daniel,
>
> Yesterday Eric Sandeen told me that I can run "xfs_info " to
> figure out if ftype is 0 or 1. You might want to run "xfs_info /" and 
> ensure ftype=0 in your case and overlay is not detecting it wrong.
>
> Thanks
> Vivek


Re: [PATCH 02/17] perf tools: Add evlist channel helpers

2016-05-17 Thread Wangnan (F)



On 2016/5/13 21:05, Arnaldo Carvalho de Melo wrote:

Em Fri, May 13, 2016 at 07:55:59AM +, Wang Nan escreveu:

In this commit sereval helpers are introduced to support the principle

  several


of channel. Channels hold different groups of evsels which configured
differently. It will be used for overwritable evsels, which allows perf

why not use multiple evlists? An "evlist" is a "list of evsels", why do
we need yet another way of grouping evlists?

- Arnaldo



There's an assumption all over perf that there's only one evlist: in 
'struct record'
there's an 'evlist' pointer, in 'struct session' there's also an 
'evlist' pointer.
Trying to change them to an array results in 181 errors, so I think 
fundamentally

moving to multiple evlists is nearly impossible.

Now I'm thinking introducing auxiliary evlists to perf record. We still 
obey one

evlist assumption, only creates separated evlists for mmap.

Thank you.



Re: [PATCH v12 05/10] arm64: Kprobes with single stepping support

2016-05-17 Thread Masami Hiramatsu
On Tue, 17 May 2016 16:58:09 +0800
Huang Shijie  wrote:

> On Wed, Apr 27, 2016 at 02:53:00PM -0400, David Long wrote:
> > +
> > +/*
> > + * Interrupts need to be disabled before single-step mode is set, and not
> > + * reenabled until after single-step mode ends.
> > + * Without disabling interrupt on local CPU, there is a chance of
> > + * interrupt occurrence in the period of exception return and  start of
> > + * out-of-line single-step, that result in wrongly single stepping
> > + * into the interrupt handler.
> > + */
> > +static void __kprobes kprobes_save_local_irqflag(struct pt_regs *regs)
> > +{
> > + struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
> 
> Why not add a parameter for this function to save the @kcb?

Good catch, it should use same kcb of caller.

> 
> > +
> > + kcb->saved_irqflag = regs->pstate;
> > + regs->pstate |= PSR_I_BIT;
> > +}
> > +
> > +static void __kprobes kprobes_restore_local_irqflag(struct pt_regs *regs)
> > +{
> > + struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
> ditto.
> 
> > +
> > + if (kcb->saved_irqflag & PSR_I_BIT)
> > + regs->pstate |= PSR_I_BIT;
> > + else
> > + regs->pstate &= ~PSR_I_BIT;
> > +}
> > +
> > +static void __kprobes
> > +set_ss_context(struct kprobe_ctlblk *kcb, unsigned long addr)
> > +{
> > + kcb->ss_ctx.ss_pending = true;
> > + kcb->ss_ctx.match_addr = addr + sizeof(kprobe_opcode_t);
> > +}
> > +
> > +static void __kprobes clear_ss_context(struct kprobe_ctlblk *kcb)
> > +{
> > + kcb->ss_ctx.ss_pending = false;
> > + kcb->ss_ctx.match_addr = 0;
> > +}
> > +
> > +static void __kprobes setup_singlestep(struct kprobe *p,
> > +struct pt_regs *regs,
> > +struct kprobe_ctlblk *kcb, int reenter)
> > +{
> > + unsigned long slot;
> > +
> > + if (reenter) {
> > + save_previous_kprobe(kcb);
> > + set_current_kprobe(p);
> > + kcb->kprobe_status = KPROBE_REENTER;
> > + } else {
> > + kcb->kprobe_status = KPROBE_HIT_SS;
> > + }
> > +
> > + if (p->ainsn.insn) {
> > + /* prepare for single stepping */
> > + slot = (unsigned long)p->ainsn.insn;
> > +
> > + set_ss_context(kcb, slot);  /* mark pending ss */
> > +
> > + if (kcb->kprobe_status == KPROBE_REENTER)
> > + spsr_set_debug_flag(regs, 0);
> > +
> > + /* IRQs and single stepping do not mix well. */
> > + kprobes_save_local_irqflag(regs);
> > + kernel_enable_single_step(regs);
> > + instruction_pointer(regs) = slot;
> > + } else  {
> > + BUG();

You'd better use BUG_ON(!p->ainsn.insn);

> > + }
> > +}
> > +
> > +static int __kprobes reenter_kprobe(struct kprobe *p,
> > + struct pt_regs *regs,
> > + struct kprobe_ctlblk *kcb)
> > +{
> > + switch (kcb->kprobe_status) {
> > + case KPROBE_HIT_SSDONE:
> > + case KPROBE_HIT_ACTIVE:
> > + kprobes_inc_nmissed_count(p);
> > + setup_singlestep(p, regs, kcb, 1);
> > + break;
> > + case KPROBE_HIT_SS:
> > + case KPROBE_REENTER:
> > + pr_warn("Unrecoverable kprobe detected at %p.\n", p->addr);
> > + dump_kprobe(p);
> > + BUG();
> > + break;
> > + default:
> > + WARN_ON(1);
> > + return 0;
> > + }
> > +
> > + return 1;
> > +}
> > +
> > +static void __kprobes
> > +post_kprobe_handler(struct kprobe_ctlblk *kcb, struct pt_regs *regs)
> > +{
> > + struct kprobe *cur = kprobe_running();
> > +
> > + if (!cur)
> > + return;
> > +
> > + /* return addr restore if non-branching insn */
> > + if (cur->ainsn.restore.type == RESTORE_PC) {
> > + instruction_pointer(regs) = cur->ainsn.restore.addr;
> > + if (!instruction_pointer(regs))
> > + BUG();
> > + }
> > +
> > + /* restore back original saved kprobe variables and continue */
> > + if (kcb->kprobe_status == KPROBE_REENTER) {
> > + restore_previous_kprobe(kcb);
> > + return;
> > + }
> > + /* call post handler */
> > + kcb->kprobe_status = KPROBE_HIT_SSDONE;
> > + if (cur->post_handler)  {
> > + /* post_handler can hit breakpoint and single step
> > +  * again, so we enable D-flag for recursive exception.
> > +  */
> > + cur->post_handler(cur, regs, 0);
> > + }
> > +
> > + reset_current_kprobe();
> > +}
> > +
> > +int __kprobes kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr)
> > +{
> > + struct kprobe *cur = kprobe_running();
> > + struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
> > +
> > + switch (kcb->kprobe_status) {
> > + case KPROBE_HIT_SS:
> > + case 

Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core

2016-05-17 Thread Peter Chen
On Mon, May 16, 2016 at 12:51:53PM +0300, Roger Quadros wrote:
> On 16/05/16 12:23, Peter Chen wrote:
> > On Mon, May 16, 2016 at 11:26:57AM +0300, Roger Quadros wrote:
> >> Hi,
> >>
> >> On 16/05/16 10:02, Peter Chen wrote:
> >>> On Fri, May 13, 2016 at 01:03:27PM +0300, Roger Quadros wrote:
>  +
>  +static int usb_gadget_connect_control(struct usb_gadget *gadget, bool 
>  connect)
>  +{
>  +struct usb_udc *udc;
>  +
>  +mutex_lock(_lock);
>  +udc = usb_gadget_to_udc(gadget);
>  +if (!udc) {
>  +dev_err(gadget->dev.parent, "%s: gadget not 
>  registered.\n",
>  +__func__);
>  +mutex_unlock(_lock);
>  +return -EINVAL;
>  +}
>  +
>  +if (connect) {
>  +if (!gadget->connected)
>  +usb_gadget_connect(udc->gadget);
>  +} else {
>  +if (gadget->connected) {
>  +usb_gadget_disconnect(udc->gadget);
>  +udc->driver->disconnect(udc->gadget);
>  +}
>  +}
>  +
>  +mutex_unlock(_lock);
>  +
>  +return 0;
>  +}
>  +
> >>>
> >>> Since this is called for vbus interrupt, why not using
> >>> usb_udc_vbus_handler directly, and call udc->driver->disconnect
> >>> at usb_gadget_stop.
> >>
> >> We can't assume that this is always called for vbus interrupt so
> >> I decided not to call usb_udc_vbus_handler.
> >>
> >> udc->vbus is really pointless for us. We keep vbus states in our
> >> state machine and leave udc->vbus as ture always.
> >>
> >> Why do you want to move udc->driver->disconnect() to stop?
> >> If USB controller disconnected from bus then the gadget driver
> >> must be notified about the disconnect immediately. The controller
> >> may or may not be stopped by the core.
> >>
> > 
> > Then, would you give some comments when this API will be used?
> > I was assumed it is only used for drd state machine.
> 
> drd_state machine didn't even need this API in the first place :).
> You guys wanted me to separate out start/stop and connect/disconnect for full 
> OTG case.
> Won't full OTG state machine want to use this API? If not what would it use?
> 

Oh, I meant only drd and fully otg state machine needs it. I am
wondering if we need have a new API to do it. Two questions:

- Except for vbus interrupt, any chances this API will be used at
current logic?
- When this API is called but without a coming gadget->stop?

-- 

Best Regards,
Peter Chen


Re: Re: [PATCH v8 3/5] mfd: hi655x: Add MFD driver for hi655x

2016-05-17 Thread Guodong Xu
On 19 April 2016 at 14:53, Lee Jones <lee.jo...@linaro.org> wrote:
>
> On Tue, 19 Apr 2016, Guodong Xu wrote:
>
> > On 13 April 2016 at 08:51, Chen Feng <puck.c...@hisilicon.com> wrote:
> > >
> > >
> > >
> > >  Forwarded Message 
> > > Subject: Re: [PATCH v8 3/5] mfd: hi655x: Add MFD driver for hi655x
> > > Date: Mon, 11 Apr 2016 11:41:06 +0100
> > > From: Lee Jones <lee.jo...@linaro.org>
> > > To: Chen Feng <puck.c...@hisilicon.com>
> > > CC: lgirdw...@gmail.com, broo...@kernel.org, 
> > > linux-kernel@vger.kernel.org, w...@huawei.com, 
> > > kong.kongxin...@hisilicon.com, haojian.zhu...@linaro.org, 
> > > suzhuangl...@hisilicon.com, dan.z...@hisilicon.com
> > >
> > > On Sun, 14 Feb 2016, Chen Feng wrote:
> > >
> > > > Add PMIC MFD driver to support hisilicon hi665x.
> > > >
> > > > Signed-off-by: Chen Feng <puck.c...@hisilicon.com>
> > > > Signed-off-by: Fei Wang <w...@huawei.com>
> > > > Signed-off-by: Xinwei Kong <kong.kongxin...@hisilicon.com>
> > > > Reviewed-by: Haojian Zhuang <haojian.zhu...@linaro.org>
> > > > Acked-by: Lee Jones <lee.jo...@linaro.org>
> > > > ---
> > > >  drivers/mfd/Kconfig |  10 +++
> > > >  drivers/mfd/Makefile|   1 +
> > > >  drivers/mfd/hi655x-pmic.c   | 162 
> > > > 
> > > >  include/linux/mfd/hi655x-pmic.h |  55 ++
> > > >  4 files changed, 228 insertions(+)
> > > >  create mode 100644 drivers/mfd/hi655x-pmic.c
> > > >  create mode 100644 include/linux/mfd/hi655x-pmic.h
> > >
> > > Applied, thanks.
> >
> > Hi, Lee, Mark
> >
> > I still didn't see this patch in linux-next (next-20160418) since your
> > replied "Applied". Are you expecting anything else? Dependencies?
> >
> > I didn't see any unsolved review comments actually. But if there is,
> > please let us know, so I can send an updated version.
>
> When I applied your patch, I also added ~40 other patches.  I haven't
> yet got around to editing and pushing them all to -next.  I will put
> some time aside this morning in order to complete the push.


Hi, Lee

As of this morning, I still cannot see hi655x in your for-mfd-next
branch and in linux-next (next-20160517)

I saw this patch integrated on Apr/19:
mfd: hi655x: Add document for hi665x PMIC

But apparently missing this one:
[PATCH v8 3/5] mfd: hi655x: Add MFD driver for hi655x

Would you please have a check? Sorry if I'm asking something stupid.
Look forward to seeing it in v4.7-rcs.

Thank you.

-Guodong

>
>
> > > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > > > index 9ca66de..5b1c091 100644
> > > > --- a/drivers/mfd/Kconfig
> > > > +++ b/drivers/mfd/Kconfig
> > > > @@ -284,6 +284,16 @@ config MFD_HI6421_PMIC
> > > > menus in order to enable them.
> > > > We communicate with the Hi6421 via memory-mapped I/O.
> > > >
> > > > +config MFD_HI655X_PMIC
> > > > + tristate "HiSilicon Hi655X series PMU/Codec IC"
> > > > + depends on ARCH_HISI || COMPILE_TEST
> > > > + depends on OF
> > > > + select MFD_CORE
> > > > + select REGMAP_MMIO
> > > > + select REGMAP_IRQ
> > > > + help
> > > > +   Select this option to enable Hisilicon hi655x series pmic 
> > > > driver.
> > > > +
> > > >  config HTC_EGPIO
> > > >   bool "HTC EGPIO support"
> > > >   depends on GPIOLIB && ARM
> > > > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> > > > index 0f230a6..1e166c1 100644
> > > > --- a/drivers/mfd/Makefile
> > > > +++ b/drivers/mfd/Makefile
> > > > @@ -190,6 +190,7 @@ obj-$(CONFIG_MFD_STW481X) += stw481x.o
> > > >  obj-$(CONFIG_MFD_IPAQ_MICRO) += ipaq-micro.o
> > > >  obj-$(CONFIG_MFD_MENF21BMC)  += menf21bmc.o
> > > >  obj-$(CONFIG_MFD_HI6421_PMIC)+= hi6421-pmic-core.o
> > > > +obj-$(CONFIG_MFD_HI655X_PMIC)   += hi655x-pmic.o
> > > >  obj-$(CONFIG_MFD_DLN2)   += dln2.o
> > > >  obj-$(CONFIG_MFD_RT5033) += rt5033.o
> > > >  obj-$(CONFIG_MFD_SKY81452)   += sky81452.o
> > > > diff --git a/drivers/mfd/hi655x-pmic.c b/drivers/mfd/hi655x-pmic.c
> > >

RE: [PATCH 1/3] ACPI: table upgrade: use cacheable map for tables

2016-05-17 Thread Zheng, Lv
Hi,

> From: Aleksey Makarov [mailto:aleksey.maka...@linaro.org]
> Subject: [PATCH 1/3] ACPI: table upgrade: use cacheable map for tables
> 
> The new memory allocated in acpi_table_initrd_init() is used to
> copy the upgraded tables to it.  So it should be mapped with
> early_memunmap() instead of early_ioremap().
> 
> This is critical for ARM.
> 
> Signed-off-by: Aleksey Makarov 
[Lv Zheng] 
Acked-by: Lv Zheng 

Thanks
-Lv

> ---
>  drivers/acpi/tables.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
> index a372f9e..449a649 100644
> --- a/drivers/acpi/tables.c
> +++ b/drivers/acpi/tables.c
> @@ -578,10 +578,10 @@ static void __init acpi_table_initrd_init(void *data,
> size_t size)
>   clen = size;
>   if (clen > MAP_CHUNK_SIZE - slop)
>   clen = MAP_CHUNK_SIZE - slop;
> - dest_p = early_ioremap(dest_addr & PAGE_MASK,
> + dest_p = early_memremap(dest_addr & PAGE_MASK,
>clen + slop);
>   memcpy(dest_p + slop, src_p, clen);
> - early_iounmap(dest_p, clen + slop);
> + early_memunmap(dest_p, clen + slop);
>   src_p += clen;
>   dest_addr += clen;
>   size -= clen;
> --
> 2.8.2



Re: [PATCH v3 3/7 UPDATE] perf tools: Add option for the path of buildid dsos under symfs

2016-05-17 Thread David Ahern

On 5/17/16 8:48 PM, Hekuang wrote:

I don't understand why dso-prefix option is needed? Why make me type
yet more options to the analysis command? Why can't the directory be
located under the symfs tree in a known location and populated the
same way it is without symfs?



Because the default buidid folder path is $HOME/.debug/.buildid,
and this $HOME is on the target machine, not the same as $HOME
on the host. Without that option, we need to copy $HOME/.debug/.buildid
to the 'known location in symfs', that's also an extra work.



My argument for symfs is that $HOME is not relevant or if it is the path 
is symfs/$HOME. The use case is dealing with countless images -- some 
development, some production. I should be able to nuke the symfs when 
the analysis is done and everything related to it is gone. With the 
$HOME/.debug path it just grows on and on with no real means of pruning it.


If the vdsos are for a particular symfs then why aren't the vdso's under 
it in a known location?


Re: [PATCH v3 3/7 UPDATE] perf tools: Add option for the path of buildid dsos under symfs

2016-05-17 Thread Hekuang



在 2016/5/18 9:51, David Ahern 写道:

On 5/17/16 7:47 PM, Hekuang wrote:



在 2016/5/16 10:50, David Ahern 写道:

On 5/15/16 7:30 PM, Hekuang wrote:

In previous patch, I use 'perf buildid-cache -a' to add vdso
binary into the HOST buildid dir.


So 'perf buildid-cache' needs the symfs option?



With this patch 'PATCH v3 3/7 UPDATE', the tree of symfs dir is
like this:

├── debug($(dso-prefix))
│   ├── .build-id
│   │   ├── 3a
│   │   │   └── e5ba6d4e532ad529e43ccf1ce1ddf8a64a4fdd ->
../../[kernel.kallsyms]/3ae5ba6d4e532ad529e43ccf1ce1ddf8a64a4fdd
│   │   └── 84
│   │   └── dbd75729adba57cc42f5544b25de571c0c8731 ->
../../[vdso32]/84dbd75729adba57cc42f5544b25de571c0c8731
│   ├── [kernel.kallsyms]
│   │   └── 3ae5ba6d4e532ad529e43ccf1ce1ddf8a64a4fdd
│   ├── [vdso]
│   │   └── 84dbd75729adba57cc42f5544b25de571c0c8731
│   └── [vdso32]
│   └── 84dbd75729adba57cc42f5544b25de571c0c8731
├── lib
│   ├── ld-2.22.so
│   └── libc-2.22.so
├── tmp
│   └── hello
└── xxx

So all binaries we need are included in the symfs dir. I think
this is consistent with your idea explained in previous mails.

With this symfs, we do not need buildid dir anymore and what's
your idea on 'perf buildid-cache' needs symfs option? after all,
that only effects on buildid dir.


I don't understand why dso-prefix option is needed? Why make me type 
yet more options to the analysis command? Why can't the directory be 
located under the symfs tree in a known location and populated the 
same way it is without symfs?




Because the default buidid folder path is $HOME/.debug/.buildid,
and this $HOME is on the target machine, not the same as $HOME
on the host. Without that option, we need to copy $HOME/.debug/.buildid
to the 'known location in symfs', that's also an extra work.




Re: CQ and RDMA READ/WRITE APIs

2016-05-17 Thread Parav Pandit
Hi Doug,

On Tue, May 17, 2016 at 11:02 PM, Doug Ledford  wrote:
> Nice catch there Bart.  That was well before my role as maintainer and
> so settles things well enough for me.  IOW, I don't feel I need to worry
> about trying to maintain the dual license nature of the RDMA stack as it
> was broken long before I took over.  Thanks for pointing that out.
>

Does it mean we can submit new code files under GPL only license?
I submitted RDMA cgroup related code in ib_core under GPLv2 only license.
Existing files which are calling those new APIs will continue to be
dual license (similar to CQ and RDMA APIs)?

Parav


Re: [RFC][PATCH 5/5] sched/core: Add debug code to catch missing update_rq_clock()

2016-05-17 Thread Yuyang Du
On Tue, May 17, 2016 at 01:24:15PM +0100, Matt Fleming wrote:
> So, if the code looks like the following, either now or in the future,
> 
> static void __schedule(bool preempt)
> {
>   ...
>   /* Clear RQCF_ACT_SKIP */
>   rq->clock_update_flags = 0;
>   ...
>   delta = rq_clock();
> }
 
Sigh, you even said "Clear RQCF_ACT_SKIP", but you not only clear it,
you clear everything. And if you clear the RQCF_UPDATE also (maybe you
shouldn't, but actually it does not matter), of course you will get
a warning...

In addition, it looks like multiple skips are possible, so:

update_rq_clock() {
rq->clock_update_flags |= RQCF_UPDATE;

...
}

instead of clearing the skip flag there.


[PATCH] mm: fix duplicate words and typos

2016-05-17 Thread Li Peng
Signed-off-by: Li Peng 
---
 mm/memcontrol.c | 2 +-
 mm/page_alloc.c | 6 +++---
 mm/vmscan.c | 7 +++
 mm/zswap.c  | 2 +-
 4 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index fe787f5..4b74255 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2293,7 +2293,7 @@ struct kmem_cache *__memcg_kmem_get_cache(struct 
kmem_cache *cachep, gfp_t gfp)
 
/*
 * If we are in a safe context (can wait, and not in interrupt
-* context), we could be be predictable and return right away.
+* context), we could be predictable and return right away.
 * This would guarantee that the allocation being performed
 * already belongs in the new cache.
 *
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index c1069ef..93824cb 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3030,7 +3030,7 @@ retry:
/*
 * If an allocation failed after direct reclaim, it could be because
 * pages are pinned on the per-cpu lists or in high alloc reserves.
-* Shrink them them and try again
+* Shrink them and try again.
 */
if (!page && !drained) {
unreserve_highatomic_pageblock(ac);
@@ -4812,7 +4812,7 @@ static int zone_batchsize(struct zone *zone)
  * locking.
  *
  * Any new users of pcp->batch and pcp->high should ensure they can cope with
- * those fields changing asynchronously (acording the the above rule).
+ * those fields changing asynchronously (according to the above rule).
  *
  * mutex_is_locked(_batch_high_lock) required when calling this function
  * outside of boot time (or some other assurance that no concurrent updaters
@@ -5024,7 +5024,7 @@ int __meminit __early_pfn_to_nid(unsigned long pfn,
  * @max_low_pfn: The highest PFN that will be passed to memblock_free_early_nid
  *
  * If an architecture guarantees that all ranges registered contain no holes
- * and may be freed, this this function may be used instead of calling
+ * and may be freed, this function may be used instead of calling
  * memblock_free_early_nid() manually.
  */
 void __init free_bootmem_with_active_regions(int nid, unsigned long 
max_low_pfn)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 142cb61..8ff5a79 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1683,8 +1683,8 @@ shrink_inactive_list(unsigned long nr_to_scan, struct 
lruvec *lruvec,
set_bit(ZONE_DIRTY, >flags);
 
/*
-* If kswapd scans pages marked marked for immediate
-* reclaim and under writeback (nr_immediate), it implies
+* If kswapd scans pages marked for immediate reclaim
+* and under writeback (nr_immediate), it implies
 * that pages are cycling through the LRU faster than
 * they are written so also forcibly stall.
 */
@@ -3267,8 +3267,7 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int 
classzone_idx)
/*
 * There should be no need to raise the scanning
 * priority if enough pages are already being scanned
-* that that high watermark would be met at 100%
-* efficiency.
+* that high watermark would be met at 100% efficiency.
 */
if (kswapd_shrink_zone(zone, end_zone, ))
raise_priority = false;
diff --git a/mm/zswap.c b/mm/zswap.c
index de0f119b..6d829d7 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -928,7 +928,7 @@ static int zswap_writeback_entry(struct zpool *pool, 
unsigned long handle)
* a load may happening concurrently
* it is safe and okay to not free the entry
* if we free the entry in the following put
-   * it it either okay to return !0
+   * it either okay to return !0
*/
 fail:
spin_lock(>lock);
-- 
1.8.3.1



Re: [PATCH v12 00/10] arm64: Add kernel probes (kprobes) support

2016-05-17 Thread Huang Shijie
On Thu, May 12, 2016 at 10:26:40AM +0800, Li Bin wrote:
> 
> 
> on 2016/5/11 23:33, James Morse wrote:
> > Hi David,
> > 
> > On 27/04/16 19:52, David Long wrote:
> >> From: "David A. Long" 
> >>
> >> This patchset is heavily based on Sandeepa Prabhu's ARM v8 kprobes patches,
> >> first seen in October 2013. This version attempts to address concerns 
> >> raised by
> >> reviewers and also fixes problems discovered during testing.
> >>
> >> This patchset adds support for kernel probes(kprobes), jump probes(jprobes)
> >> and return probes(kretprobes) support for ARM64.
> >>
> >> The kprobes mechanism makes use of software breakpoint and single stepping
> >> support available in the ARM v8 kernel.
> > 
> > I applied this series on v4.6-rc7, and built the sample kprobes. They work 
> > fine,
> > unless I throw ftrace into the mix too.
> > 
> > I enabled the function_graph tracer, then tried to load the jprobe example 
> > module:
> > -%<-
> > root@ubuntu:/sys/kernel/debug/tracing# insmod /root/jprobe_example.ko
> > Planted jprobe at ff80080c8f20, handler addr ff8000bb3000
> > root@ubuntu:/sys/kernel/debug/tracing# jprobe: clone_flags = 0x1200011, 
> > stack_st
> > art = 0x0 stack_size = 0x0
> > Bad mode in Synchronous Abort handler detected, code 0x8605 -- IABT 
> > (current
> >  EL)
> > CPU: 5 PID: 1047 Comm: systemd-udevd Not tainted 4.6.0-rc7+ #4064
> > Hardware name: ARM Juno development board (r1) (DT)
> > task: ffc975948300 ti: ffc974e4c000 task.ti: ffc974e4c000
> > PC is at 0x0
> > LR is at 0x0
> > 
> > pc : [<>] lr : [<>] pstate: 6145
> > sp : ffc974e4ff00
> > x29: 01200011 x28: ffc974e4c000
> > x27: ff80088d x26: 00dc
> > x25: 0120 x24: 0015
> > x23: 6000 x22: 007fa1b40e60
> > x21: 007fa1ce70d0 x20: 
> > x19:  x18: 0a03
> > x17: 007fa1b40d90 x16: ff80080c9708
> > x15: 003b9aca x14: 007fddb7e5c0
> > x13: 007fa1b40e2c x12: 00d00ff0
> > x11: ff8009c4d000 x10: ff800920c000
> > x9 : ff8008f5c000 x8 : ffc976c06800
> > x7 : 0006daf2 x6 : 0015
> > x5 : 0004 x4 : ffc96e8690a0
> > x3 : 001ed7cbab74 x2 : ffc96e869000
> > x1 :  x0 : 
> > 
> > Internal error: Oops - bad mode: 0 [#1] PREEMPT SMP
> > Modules linked in: jprobe_example
> > CPU: 5 PID: 1047 Comm: systemd-udevd Not tainted 4.6.0-rc7+ #4064
> > Hardware name: ARM Juno development board (r1) (DT)
> > task: ffc975948300 ti: ffc974e4c000 task.ti: ffc974e4c000
> > PC is at 0x0
> > LR is at 0x0
> > 
> > pc : [<>] lr : [<>] pstate: 6145
> > sp : ffc974e4ff00
> > x29: 01200011 x28: ffc974e4c000
> > x27: ff80088d x26: 00dc
> > x25: 0120 x24: 0015
> > x23: 6000 x22: 007fa1b40e60
> > x21: 007fa1ce70d0 x20: 
> > x19:  x18: 0a03
> > x17: 007fa1b40d90 x16: ff80080c9708
> > x15: 003b9aca x14: 007fddb7e5c0
> > x13: 007fa1b40e2c x12: 00d00ff0
> > x11: ff8009c4d000 x10: ff800920c000
> > x9 : ff8008f5c000 x8 : ffc976c06800
> > x7 : 0006daf2 x6 : 0015
> > x5 : 0004 x4 : ffc96e8690a0
> > x3 : 001ed7cbab74 x2 : ffc96e869000
> > x1 :  x0 : 
> > 
> > Process systemd-udevd (pid: 1047, stack limit = 0xffc974e4c020)
> > Stack: (0xffc974e4ff00 to 0xffc974e5)
> > ff00: 0417 007fa1ce76f0 00dc 0417
> > ff20:  007fddb7ecf8 0005 
> > ff40: ff01 003b9aca 00555b3868b0 007fa1b40d90
> > ff60: 0a03 007fddb7e5c0  007fddb7e5e0
> > ff80: 00555b358000 00558f56f0e0  00558f574f00
> > ffa0: 00558f574f00 04fa 00558f56f010 007fddb7e600
> > ffc0: 007fa1b40e2c 007fddb7e5c0 007fa1b40e60 6000
> > ffe0: 01200011 00dc 000484000200 08000200
> > Call trace:
> > [<  (null)>]   (null)
> > Code: bad PC value
> > ---[ end trace 35d24aad799c2941 ]---
> > -%<-
> > 
> 
> To solve this, it should pause function tracing before the jprobe handler is 
> called
> and unpause it before it returns back to the function it probed.
> 
> diff --git a/arch/arm64/kernel/kprobes.c b/arch/arm64/kernel/kprobes.c
> index db2d95c..b21ed00 100644
> --- a/arch/arm64/kernel/kprobes.c
> +++ b/arch/arm64/kernel/kprobes.c
> @@ -714,6 +714,7 @@ int __kprobes setjmp_pre_handler(struct kprobe *p, struct 
> pt_regs *regs)
> 
> 

Re: [PATCH] mmc: dw_mmc: Consider HLE errors to be data and command errors

2016-05-17 Thread Jaehoon Chung
On 05/18/2016 09:47 AM, Doug Anderson wrote:
> Jaehoon,
> 
> On Mon, Mar 30, 2015 at 8:47 AM, Doug Anderson  wrote:
>> Jaehoon,
>>
>> On Sun, Mar 29, 2015 at 5:55 PM, Jaehoon Chung  
>> wrote:
>>> Dear Doug,
>>>
>>> I'm considering to control HLE error..So holding this patch.
>>> If this is absolutely necessary patch, let me know, plz.
>>>
>>> Best Regards,
>>> Jaehoon Chung
>>
>> Sounds OK.  I have certainly applied this locally and the driver isn't
>> robust against insertions / removals without it, but once the card is
>> inserted things are OK so it's probably not urgent that it be applied
>> upstream.  Hopefully we can figure out a better solution...
> 
> I'm now testing a nice new rebased kernel and I'm hitting this again.
> 
> Of course I'll just pick my same patch to my new kernel tree, but
> since it's been a year and nobody has done anything better, would you
> consider landing my patch?  It is certainly better than nothing.

Sure, it's right.
I think that main reason of HLE is wait_prvdata_complete. (I'm guessing..)
On other hands, dwmmc controller is handling something wrong. (I found that HLE 
is occurred the similar case.)
After find the main solution, it's not bad that your patch is applied on dwmmc 
controller.

Ulf have sent PR for next..So if we needs to apply this, i will apply on fix.

Best Regards,
Jaehoon Chung

> 
> -Doug
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 



[PATCH v2] Drivers: hv: vmbus: fix the race when querying & updating the percpu list

2016-05-17 Thread Dexuan Cui
There is a rare race when we remove an entry from the global list
hv_context.percpu_list[cpu] in hv_process_channel_removal() ->
percpu_channel_deq() -> list_del(): at this time, if vmbus_on_event() ->
process_chn_event() -> pcpu_relid2channel() is trying to query the list,
we can get the general protection fault:

general protection fault:  [#1] SMP
...
RIP: 0010:[]  [] vmbus_on_event+0xc4/0x149

Similarly, we also have the issue in the code path: vmbus_process_offer() ->
percpu_channel_enq().

We can resolve the issue by disabling the tasklet when updating the list.

Reported-by: Rolf Neugebauer 
Cc: Vitaly Kuznetsov 
Signed-off-by: Dexuan Cui 
---

v2: added tasklet_schedule() after tasklet_enable(). Thanks, Vitaly!

 drivers/hv/channel.c  |  5 +
 drivers/hv/channel_mgmt.c | 24 +---
 include/linux/hyperv.h|  3 +++
 3 files changed, 21 insertions(+), 11 deletions(-)

diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index 56dd261..17c4711 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -546,8 +546,11 @@ static int vmbus_close_internal(struct vmbus_channel 
*channel)
put_cpu();
smp_call_function_single(channel->target_cpu, reset_channel_cb,
 channel, true);
+   smp_call_function_single(channel->target_cpu,
+percpu_channel_deq, channel, true);
} else {
reset_channel_cb(channel);
+   percpu_channel_deq(channel);
put_cpu();
}
 
@@ -592,6 +595,8 @@ static int vmbus_close_internal(struct vmbus_channel 
*channel)
 
 out:
tasklet_enable(tasklet);
+   /* for possible pending event */
+   tasklet_schedule(tasklet);
 
return ret;
 }
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 38b682ba..8e251e3 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -21,6 +21,7 @@
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -277,7 +278,7 @@ static void free_channel(struct vmbus_channel *channel)
kfree(channel);
 }
 
-static void percpu_channel_enq(void *arg)
+void percpu_channel_enq(void *arg)
 {
struct vmbus_channel *channel = arg;
int cpu = smp_processor_id();
@@ -285,7 +286,7 @@ static void percpu_channel_enq(void *arg)
list_add_tail(>percpu_list, _context.percpu_list[cpu]);
 }
 
-static void percpu_channel_deq(void *arg)
+void percpu_channel_deq(void *arg)
 {
struct vmbus_channel *channel = arg;
 
@@ -313,15 +314,6 @@ void hv_process_channel_removal(struct vmbus_channel 
*channel, u32 relid)
BUG_ON(!channel->rescind);
BUG_ON(!mutex_is_locked(_connection.channel_mutex));
 
-   if (channel->target_cpu != get_cpu()) {
-   put_cpu();
-   smp_call_function_single(channel->target_cpu,
-percpu_channel_deq, channel, true);
-   } else {
-   percpu_channel_deq(channel);
-   put_cpu();
-   }
-
if (channel->primary_channel == NULL) {
list_del(>listentry);
 
@@ -363,6 +355,7 @@ void vmbus_free_channels(void)
  */
 static void vmbus_process_offer(struct vmbus_channel *newchannel)
 {
+   struct tasklet_struct *tasklet;
struct vmbus_channel *channel;
bool fnew = true;
unsigned long flags;
@@ -409,6 +402,8 @@ static void vmbus_process_offer(struct vmbus_channel 
*newchannel)
 
init_vp_index(newchannel, dev_type);
 
+   tasklet = hv_context.event_dpc[newchannel->target_cpu];
+   tasklet_disable(tasklet);
if (newchannel->target_cpu != get_cpu()) {
put_cpu();
smp_call_function_single(newchannel->target_cpu,
@@ -418,6 +413,9 @@ static void vmbus_process_offer(struct vmbus_channel 
*newchannel)
percpu_channel_enq(newchannel);
put_cpu();
}
+   tasklet_enable(tasklet);
+   /* for possible pending event */
+   tasklet_schedule(tasklet);
 
/*
 * This state is used to indicate a successful open
@@ -469,6 +467,7 @@ err_deq_chan:
list_del(>listentry);
mutex_unlock(_connection.channel_mutex);
 
+   tasklet_disable(tasklet);
if (newchannel->target_cpu != get_cpu()) {
put_cpu();
smp_call_function_single(newchannel->target_cpu,
@@ -477,6 +476,9 @@ err_deq_chan:
percpu_channel_deq(newchannel);
put_cpu();
}
+   tasklet_enable(tasklet);
+   /* for possible pending event */
+   tasklet_schedule(tasklet);
 
 err_free_chan:
free_channel(newchannel);
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 7be7237..95aea09 100644
--- a/include/linux/hyperv.h
+++ 

Re: [PATCH] mmc: dw_mmc: Consider HLE errors to be data and command errors

2016-05-17 Thread Shawn Lin

Hi Doug,

On 2016-5-18 8:47, Doug Anderson wrote:

Jaehoon,

On Mon, Mar 30, 2015 at 8:47 AM, Doug Anderson  wrote:

Jaehoon,

On Sun, Mar 29, 2015 at 5:55 PM, Jaehoon Chung  wrote:

Dear Doug,

I'm considering to control HLE error..So holding this patch.
If this is absolutely necessary patch, let me know, plz.

Best Regards,
Jaehoon Chung

Sounds OK.  I have certainly applied this locally and the driver isn't
robust against insertions / removals without it, but once the card is
inserted things are OK so it's probably not urgent that it be applied
upstream.  Hopefully we can figure out a better solution...

I'm now testing a nice new rebased kernel and I'm hitting this again.

Of course I'll just pick my same patch to my new kernel tree, but
since it's been a year and nobody has done anything better, would you
consider landing my patch?  It is certainly better than nothing.


Could you try this patch to see if you can still find HLE?

@@ -2356,12 +2356,22 @@ static void dw_mci_cmd_interrupt(struct dw_mci *host, 
u32 status)
 static void dw_mci_handle_cd(struct dw_mci *host)
 {
int i;
+   int present;

for (i = 0; i < host->num_slots; i++) {
struct dw_mci_slot *slot = host->slot[i];

if (!slot)
continue;

+   present = !(mci_readl(slot->host, CDETECT) & (1 << slot->id));
+   if (present)
+   set_bit(DW_MMC_CARD_PRESENT, >flags);
+   else
+   clear_bit(DW_MMC_CARD_PRESENT, >flags);

if (slot->mmc->ops->card_event)
slot->mmc->ops->card_event(slot->mmc);




-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html





Re: [PATCH v3 3/7 UPDATE] perf tools: Add option for the path of buildid dsos under symfs

2016-05-17 Thread Hekuang



在 2016/5/16 10:50, David Ahern 写道:

On 5/15/16 7:30 PM, Hekuang wrote:

In previous patch, I use 'perf buildid-cache -a' to add vdso
binary into the HOST buildid dir.


So 'perf buildid-cache' needs the symfs option?



With this patch 'PATCH v3 3/7 UPDATE', the tree of symfs dir is
like this:

├── debug($(dso-prefix))
│   ├── .build-id
│   │   ├── 3a
│   │   │   └── e5ba6d4e532ad529e43ccf1ce1ddf8a64a4fdd -> 
../../[kernel.kallsyms]/3ae5ba6d4e532ad529e43ccf1ce1ddf8a64a4fdd

│   │   └── 84
│   │   └── dbd75729adba57cc42f5544b25de571c0c8731 -> 
../../[vdso32]/84dbd75729adba57cc42f5544b25de571c0c8731

│   ├── [kernel.kallsyms]
│   │   └── 3ae5ba6d4e532ad529e43ccf1ce1ddf8a64a4fdd
│   ├── [vdso]
│   │   └── 84dbd75729adba57cc42f5544b25de571c0c8731
│   └── [vdso32]
│   └── 84dbd75729adba57cc42f5544b25de571c0c8731
├── lib
│   ├── ld-2.22.so
│   └── libc-2.22.so
├── tmp
│   └── hello
└── xxx

So all binaries we need are included in the symfs dir. I think
this is consistent with your idea explained in previous mails.

With this symfs, we do not need buildid dir anymore and what's
your idea on 'perf buildid-cache' needs symfs option? after all,
that only effects on buildid dir.

Thanks.




Re: [PATCH v3 3/7 UPDATE] perf tools: Add option for the path of buildid dsos under symfs

2016-05-17 Thread David Ahern

On 5/17/16 7:47 PM, Hekuang wrote:



在 2016/5/16 10:50, David Ahern 写道:

On 5/15/16 7:30 PM, Hekuang wrote:

In previous patch, I use 'perf buildid-cache -a' to add vdso
binary into the HOST buildid dir.


So 'perf buildid-cache' needs the symfs option?



With this patch 'PATCH v3 3/7 UPDATE', the tree of symfs dir is
like this:

├── debug($(dso-prefix))
│   ├── .build-id
│   │   ├── 3a
│   │   │   └── e5ba6d4e532ad529e43ccf1ce1ddf8a64a4fdd ->
../../[kernel.kallsyms]/3ae5ba6d4e532ad529e43ccf1ce1ddf8a64a4fdd
│   │   └── 84
│   │   └── dbd75729adba57cc42f5544b25de571c0c8731 ->
../../[vdso32]/84dbd75729adba57cc42f5544b25de571c0c8731
│   ├── [kernel.kallsyms]
│   │   └── 3ae5ba6d4e532ad529e43ccf1ce1ddf8a64a4fdd
│   ├── [vdso]
│   │   └── 84dbd75729adba57cc42f5544b25de571c0c8731
│   └── [vdso32]
│   └── 84dbd75729adba57cc42f5544b25de571c0c8731
├── lib
│   ├── ld-2.22.so
│   └── libc-2.22.so
├── tmp
│   └── hello
└── xxx

So all binaries we need are included in the symfs dir. I think
this is consistent with your idea explained in previous mails.

With this symfs, we do not need buildid dir anymore and what's
your idea on 'perf buildid-cache' needs symfs option? after all,
that only effects on buildid dir.


I don't understand why dso-prefix option is needed? Why make me type yet 
more options to the analysis command? Why can't the directory be located 
under the symfs tree in a known location and populated the same way it 
is without symfs?




Linux-next parallel cp workload hang

2016-05-17 Thread Xiong Zhou
Hi,

Parallel cp workload (xfstests generic/273) hangs like blow.
It's reproducible with a small chance, less the 1/100 i think.

Have hit this in linux-next 20160504 0506 0510 trees, testing on
xfs with loop or block device. Ext4 survived several rounds
of testing.

Linux next 20160510 tree hangs within 500 rounds testing several
times. The same tree with vfs parallel lookup patchset reverted
survived 900 rounds testing. Reverted commits are attached.

Bisecting in this patchset ided this commit:

3b0a3c1ac1598722fc289da19219d14f2a37b31f is the first bad commit
commit 3b0a3c1ac1598722fc289da19219d14f2a37b31f
Author: Al Viro 
Date:   Wed Apr 20 23:42:46 2016 -0400

simple local filesystems: switch to ->iterate_shared()

no changes needed (XFS isn't simple, but it has the same parallelism
in the interesting parts exercised from CXFS).

With this commit reverted on top of Linux next 0510 tree, 5000+ rounds
of testing passed.

Although 2000 rounds testing had been conducted before good/bad
verdict, i'm not 100 percent sure about all this, since it's
so hard to hit, and i am not that lucky..

Bisect log and full blocked state process dump log are also attached.

Furthermore, this was first hit when testing fs dax on nvdimm,
however it's reproducible without dax mount option, and also
reproducible on loop device, just seems harder to hit.

Thanks,
Xiong

[0.771475] INFO: task cp:49033 blocked for more than 120 seconds.
[0.794263]   Not tainted 4.6.0-rc6-next-20160504 #5
[0.812515] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
this message.
[0.841801] cp  D 880b4e977928 0 49033  49014
0x0080
[0.868923]  880b4e977928 880ba275d380 880b8d712b80
880b4e978000
[0.897504]  7fff 0002 
880b8d712b80
[0.925234]  880b4e977940 816cbc25 88035a1dabb0
880b4e9779e8
[0.953237] Call Trace:
[0.958314]  [] schedule+0x35/0x80
[0.974854]  [] schedule_timeout+0x231/0x2d0
[0.995728]  [] ? down_trylock+0x2d/0x40
[1.015351]  [] ? xfs_iext_bno_to_ext+0xa2/0x190 [xfs]
[1.040182]  [] __down_common+0xaa/0x104
[1.059021]  [] ? _xfs_buf_find+0x162/0x340 [xfs]
[1.081357]  [] __down+0x1d/0x1f
[1.097166]  [] down+0x41/0x50
[1.112869]  [] xfs_buf_lock+0x3c/0xf0 [xfs]
[1.134504]  [] _xfs_buf_find+0x162/0x340 [xfs]
[1.156871]  [] xfs_buf_get_map+0x2a/0x270 [xfs]
[1.180010]  [] xfs_buf_read_map+0x2d/0x180 [xfs]
[1.203538]  [] xfs_trans_read_buf_map+0xf1/0x300 [xfs]
[1.229194]  [] xfs_da_read_buf+0xd1/0x100 [xfs]
[1.251948]  [] xfs_dir3_data_read+0x26/0x60 [xfs]
[1.275736]  []
xfs_dir2_leaf_readbuf.isra.12+0x1be/0x4a0 [xfs]
[1.305094]  [] ? down_read+0x12/0x30
[1.323787]  [] ? xfs_ilock+0xe4/0x110 [xfs]
[1.345114]  [] xfs_dir2_leaf_getdents+0x13b/0x3d0
[xfs]
[1.371818]  [] xfs_readdir+0x1a6/0x1c0 [xfs]
[1.393471]  [] xfs_file_readdir+0x2b/0x30 [xfs]
[1.416874]  [] iterate_dir+0x173/0x190
[1.436709]  [] ? do_audit_syscall_entry+0x66/0x70
[1.460951]  [] SyS_getdents+0x98/0x120
[1.480566]  [] ? iterate_dir+0x190/0x190
[1.500909]  [] do_syscall_64+0x62/0x110
[1.520847]  [] entry_SYSCALL64_slow_path+0x25/0x25
[1.545372] INFO: task cp:49040 blocked for more than 120 seconds.
[1.568933]   Not tainted 4.6.0-rc6-next-20160504 #5
[1.587943] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
this message.
[1.618544] cp  D 880b91463b00 0 49040  49016
0x0080
[1.645502]  880b91463b00 880464d5c140 88029b475700
880b91464000
[1.674145]  880411c42610  880411c42628
8802c10bc610
[1.702834]  880b91463b18 816cbc25 88029b475700
880b91463b88
[1.731501] Call Trace:
[1.736866]  [] schedule+0x35/0x80
[1.754119]  [] rwsem_down_read_failed+0xf2/0x140
[1.777411]  [] ? xfs_ilock_data_map_shared+0x30/0x40
[xfs]
[1.805090]  [] call_rwsem_down_read_failed+0x18/0x30
[1.830482]  [] down_read+0x20/0x30
[1.848505]  [] xfs_ilock+0xe4/0x110 [xfs]
[1.869293]  [] xfs_ilock_data_map_shared+0x30/0x40
[xfs]
[1.896775]  [] xfs_dir_open+0x30/0x60 [xfs]
[1.917882]  [] do_dentry_open+0x20f/0x320
[1.938919]  [] ? xfs_file_mmap+0x50/0x50 [xfs]
[1.961532]  [] vfs_open+0x57/0x60
[1.978945]  [] path_openat+0x325/0x14e0
[1.999273]  [] ? putname+0x53/0x60
[2.017695]  [] do_filp_open+0x91/0x100
[2.036893]  [] ? __alloc_fd+0x46/0x180
[2.055479]  [] do_sys_open+0x124/0x210
[2.073783]  [] ? __audit_syscall_exit+0x1db/0x260
[2.096426]  [] SyS_openat+0x14/0x20
[2.113690]  [] do_syscall_64+0x62/0x110
[2.132417]  [] entry_SYSCALL64_slow_path+0x25/0x25



g273-block-dumps.tar.gz
Description: application/gzip


Re: [PATCH] doc: self-protection: provide initial details

2016-05-17 Thread Kees Cook
On Tue, May 17, 2016 at 6:26 PM, Jonathan Corbet  wrote:
> On Mon, 16 May 2016 19:27:28 -0700
> Kees Cook  wrote:
>
>> This document attempts to codify the intent around kernel self-protection
>> along with discussion of both existing and desired technologies, with
>> attention given to the rationale behind them, and the expectations of
>> their usage.
>
> I've applied this to the docs tree.  In the process, I took the liberty
> of applying the suggestions from Randy, hope you don't mind...

Ah, thanks! I'll send a follow-up. I had a suggestion for another
section and a typo fix.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security


[PATCH] mm: disable fault around on emulated access bit architecture

2016-05-17 Thread Minchan Kim
On Tue, May 17, 2016 at 03:34:23PM +0300, Kirill A. Shutemov wrote:
> On Mon, May 16, 2016 at 11:56:32PM +0900, Minchan Kim wrote:
> > On Mon, May 16, 2016 at 05:29:00PM +0300, Kirill A. Shutemov wrote:
> > > > Kirill,
> > > > You wanted to test non-HW access bit system and I did.
> > > > What's your opinion?
> > > 
> > > Sorry, for late response.
> > > 
> > > My patch is incomlete: we need to find a way to not mark pte as old if we
> > > handle page fault for the address the pte represents.
> > 
> > I'm sure you can handle it but my point is there wouldn't be a big gain
> > although you can handle it in non-HW access bit system. Okay, let's be
> > more clear because I don't have every non-HW access bit architecture.
> > At least, current mobile workload in ARM which I have wouldn't be huge
> > benefit.
> > I will say one more.
> > I tested the workload on quad-core system and core speed is not so slow
> > compared to recent other mobile phone SoC. Even when I tested the benchmark
> > without pte_mkold, the benefit is within noise because storage is really
> > slow so major fault is dominant factor. So, I decide test storage from eMMC
> > to eSATA. And then finally, I manage to see the a little beneift with
> > fault_around without pte_mkold.
> > 
> > However, let's consider side-effect aspect from fault_around.
> > 
> > 1. Increase slab shrinking compard to old
> > 2. high level vmpressure compared to old
> > 
> > With considering that regressions on my system, it's really not worth to
> > try at the moment.
> > That's why I wanted to disable fault_around as default in non-HW access
> > bit system.
> 
> Feel free to post such patch. I guess it's reasonable.

>From d926a2a19cd0921b34279c3f6a3bae8b7508646d Mon Sep 17 00:00:00 2001
From: Minchan Kim 
Date: Wed, 18 May 2016 08:36:59 +0900
Subject: [PATCH] mm: disable fault around on emulated access bit architecture

The fault_around aims for reducing minor fault of file-backed pages
via speculative ahead pte mapping with relying on readahead logic.
However, on non-HW access bit architecture, the benefit is highly
limited because they should emulate young bit with minor fault
for page aging algorithm of reclaim. IOW, we cannot reduce minor fault
on those architectures.

I did quick test in my ARM machine.

512M file mmap sequential every word read on eSATA drive with 4 times.
stdev is stable.

= fault_around 4096 =
elapsed time(usec): 6747645

= fault_around 65536 =
elapsed time(usec): 6709263

0.5% gain.

Even, when I tested it with eMMC, there is no gain because I guess
with slow storage, major fault is more dominant factor.

As well, fault_around has side effect to shrink slab more aggressively
and higher vmpressure so if such speculation fails, it can evict slab
more which can result in page I/O(e.g., inode cache), in the end,
it would make void benefit of fault_around.

So let's make default disable on those architectures.

Cc: Kirill A. Shutemov 
Cc: linux-a...@vger.kernel.org
Signed-off-by: Minchan Kim 
---
 mm/memory.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/mm/memory.c b/mm/memory.c
index b762b17aa4c5..9f652fdc0295 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2897,8 +2897,16 @@ void do_set_pte(struct vm_area_struct *vma, unsigned 
long address,
update_mmu_cache(vma, address, pte);
 }
 
+/*
+ * If architecture emulates "accessed" or "young" bit without HW support,
+ * there is no much gain with fault_around.
+ */
 static unsigned long fault_around_bytes __read_mostly =
+#ifndef __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS
+   PAGE_SIZE;
+#else
rounddown_pow_of_two(65536);
+#endif
 
 #ifdef CONFIG_DEBUG_FS
 static int fault_around_bytes_get(void *data, u64 *val)
-- 
1.9.1




[PATCH 1/2] kprobes: add a new module parameter

2016-05-17 Thread Huang Shijie
This patch adds a new module parameter which can be used as the
symbol name. With this parameter, the module becomes more flexable.

Signed-off-by: Huang Shijie 
---
 samples/kprobes/kprobe_example.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/samples/kprobes/kprobe_example.c b/samples/kprobes/kprobe_example.c
index 727eb21..2bb190d 100644
--- a/samples/kprobes/kprobe_example.c
+++ b/samples/kprobes/kprobe_example.c
@@ -14,9 +14,13 @@
 #include 
 #include 
 
+#define MAX_SYMBOL_LEN 64
+static char symbol[MAX_SYMBOL_LEN] = "_do_fork";
+module_param_string(symbol, symbol, sizeof(symbol), 0644);
+
 /* For each probe you need to allocate a kprobe structure */
 static struct kprobe kp = {
-   .symbol_name= "_do_fork",
+   .symbol_name= symbol,
 };
 
 /* kprobe pre_handler: called just before the probed instruction is executed */
-- 
2.5.5



[PATCH 2/2] kprobes: print out the symbol name for the hooks

2016-05-17 Thread Huang Shijie
Print out the symbol name for the hooks, it makes the logs more readable.

Signed-off-by: Huang Shijie 
---
 samples/kprobes/kprobe_example.c | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/samples/kprobes/kprobe_example.c b/samples/kprobes/kprobe_example.c
index 2bb190d..ed0ca0c 100644
--- a/samples/kprobes/kprobe_example.c
+++ b/samples/kprobes/kprobe_example.c
@@ -27,24 +27,24 @@ static struct kprobe kp = {
 static int handler_pre(struct kprobe *p, struct pt_regs *regs)
 {
 #ifdef CONFIG_X86
-   printk(KERN_INFO "pre_handler: p->addr = 0x%p, ip = %lx,"
+   printk(KERN_INFO "<%s> pre_handler: p->addr = 0x%p, ip = %lx,"
" flags = 0x%lx\n",
-   p->addr, regs->ip, regs->flags);
+   p->symbol_name, p->addr, regs->ip, regs->flags);
 #endif
 #ifdef CONFIG_PPC
-   printk(KERN_INFO "pre_handler: p->addr = 0x%p, nip = 0x%lx,"
+   printk(KERN_INFO "<%s> pre_handler: p->addr = 0x%p, nip = 0x%lx,"
" msr = 0x%lx\n",
-   p->addr, regs->nip, regs->msr);
+   p->symbol_name, p->addr, regs->nip, regs->msr);
 #endif
 #ifdef CONFIG_MIPS
-   printk(KERN_INFO "pre_handler: p->addr = 0x%p, epc = 0x%lx,"
+   printk(KERN_INFO "<%s> pre_handler: p->addr = 0x%p, epc = 0x%lx,"
" status = 0x%lx\n",
-   p->addr, regs->cp0_epc, regs->cp0_status);
+   p->symbol_name, p->addr, regs->cp0_epc, regs->cp0_status);
 #endif
 #ifdef CONFIG_TILEGX
-   printk(KERN_INFO "pre_handler: p->addr = 0x%p, pc = 0x%lx,"
+   printk(KERN_INFO "<%s> pre_handler: p->addr = 0x%p, pc = 0x%lx,"
" ex1 = 0x%lx\n",
-   p->addr, regs->pc, regs->ex1);
+   p->symbol_name, p->addr, regs->pc, regs->ex1);
 #endif
 
/* A dump_stack() here will give a stack backtrace */
@@ -56,20 +56,20 @@ static void handler_post(struct kprobe *p, struct pt_regs 
*regs,
unsigned long flags)
 {
 #ifdef CONFIG_X86
-   printk(KERN_INFO "post_handler: p->addr = 0x%p, flags = 0x%lx\n",
-   p->addr, regs->flags);
+   printk(KERN_INFO "<%s> post_handler: p->addr = 0x%p, flags = 0x%lx\n",
+   p->symbol_name, p->addr, regs->flags);
 #endif
 #ifdef CONFIG_PPC
-   printk(KERN_INFO "post_handler: p->addr = 0x%p, msr = 0x%lx\n",
-   p->addr, regs->msr);
+   printk(KERN_INFO "<%s> post_handler: p->addr = 0x%p, msr = 0x%lx\n",
+   p->symbol_name, p->addr, regs->msr);
 #endif
 #ifdef CONFIG_MIPS
-   printk(KERN_INFO "post_handler: p->addr = 0x%p, status = 0x%lx\n",
-   p->addr, regs->cp0_status);
+   printk(KERN_INFO "<%s> post_handler: p->addr = 0x%p, status = 0x%lx\n",
+   p->symbol_name, p->addr, regs->cp0_status);
 #endif
 #ifdef CONFIG_TILEGX
-   printk(KERN_INFO "post_handler: p->addr = 0x%p, ex1 = 0x%lx\n",
-   p->addr, regs->ex1);
+   printk(KERN_INFO "<%s> post_handler: p->addr = 0x%p, ex1 = 0x%lx\n",
+   p->symbol_name, p->addr, regs->ex1);
 #endif
 }
 
-- 
2.5.5



Re: [PATCH v12 10/10] kprobes: Add arm64 case in kprobe example module

2016-05-17 Thread Huang Shijie
On Tue, May 17, 2016 at 11:24:27AM +0100, Mark Brown wrote:
> On Tue, May 17, 2016 at 05:57:33PM +0800, Huang Shijie wrote:
> > On Wed, Apr 27, 2016 at 02:53:05PM -0400, David Long wrote:
> 
> > > +#ifdef CONFIG_ARM64
> > > + pr_info("pre_handler: p->addr = 0x%p, pc = 0x%lx\n",
> 
> > I think you miss the KERN_INFO here.
> 
> That's what pr_info() does over printk() - it adds the KERN_INFO more
> cleanly.
sorry, I thought the "pr_info" to "printk" when I first read this code.

thanks
Huang Shijie



Re: [f2fs-dev] [PATCH] f2fs: use bio count instead of F2FS_WRITEBACK page count

2016-05-17 Thread Jaegeuk Kim
On Wed, May 18, 2016 at 09:17:00AM +0800, Chao Yu wrote:
> Hi Jaegeuk,
> 
> On 2016/5/18 8:44, Jaegeuk Kim wrote:
> > This can reduce page counting overhead.
> 
> We change to increase one reference for one bio, but block layer can split or
> merge bios by itself, and write_end will be called per bio, so the reference 
> may
> be maintained incorrectly?

Well, block layer will merge bios in a same request, and then finally call
end_io for each original bios, no?
So far I've seen no error in any test cases.
Am I missing something?

Thanks,

> 
> Thanks,
> 
> > 
> > Signed-off-by: Jaegeuk Kim 
> > ---
> >  fs/f2fs/checkpoint.c |  2 +-
> >  fs/f2fs/data.c   | 26 +++---
> >  fs/f2fs/debug.c  |  6 +++---
> >  fs/f2fs/f2fs.h   |  4 ++--
> >  fs/f2fs/super.c  |  2 +-
> >  5 files changed, 22 insertions(+), 18 deletions(-)
> > 
> > diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
> > index d04113b..447e2a9 100644
> > --- a/fs/f2fs/checkpoint.c
> > +++ b/fs/f2fs/checkpoint.c
> > @@ -914,7 +914,7 @@ static void wait_on_all_pages_writeback(struct 
> > f2fs_sb_info *sbi)
> > for (;;) {
> > prepare_to_wait(>cp_wait, , TASK_UNINTERRUPTIBLE);
> >  
> > -   if (!get_pages(sbi, F2FS_WRITEBACK))
> > +   if (!atomic_read(>nr_wb_bios))
> > break;
> >  
> > io_schedule_timeout(5*HZ);
> > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> > index 1013836..faef666 100644
> > --- a/fs/f2fs/data.c
> > +++ b/fs/f2fs/data.c
> > @@ -71,10 +71,9 @@ static void f2fs_write_end_io(struct bio *bio)
> > f2fs_stop_checkpoint(sbi);
> > }
> > end_page_writeback(page);
> > -   dec_page_count(sbi, F2FS_WRITEBACK);
> > }
> > -
> > -   if (!get_pages(sbi, F2FS_WRITEBACK) && wq_has_sleeper(>cp_wait))
> > +   if (atomic_dec_and_test(>nr_wb_bios) &&
> > +   wq_has_sleeper(>cp_wait))
> > wake_up(>cp_wait);
> >  
> > bio_put(bio);
> > @@ -98,6 +97,14 @@ static struct bio *__bio_alloc(struct f2fs_sb_info *sbi, 
> > block_t blk_addr,
> > return bio;
> >  }
> >  
> > +static inline void __submit_bio(struct f2fs_sb_info *sbi, int rw,
> > +   struct bio *bio)
> > +{
> > +   if (!is_read_io(rw))
> > +   atomic_inc(>nr_wb_bios);
> > +   submit_bio(rw, bio);
> > +}
> > +
> >  static void __submit_merged_bio(struct f2fs_bio_info *io)
> >  {
> > struct f2fs_io_info *fio = >fio;
> > @@ -110,7 +117,7 @@ static void __submit_merged_bio(struct f2fs_bio_info 
> > *io)
> > else
> > trace_f2fs_submit_write_bio(io->sbi->sb, fio, io->bio);
> >  
> > -   submit_bio(fio->rw, io->bio);
> > +   __submit_bio(io->sbi, fio->rw, io->bio);
> > io->bio = NULL;
> >  }
> >  
> > @@ -228,7 +235,7 @@ int f2fs_submit_page_bio(struct f2fs_io_info *fio)
> > return -EFAULT;
> > }
> >  
> > -   submit_bio(fio->rw, bio);
> > +   __submit_bio(fio->sbi, fio->rw, bio);
> > return 0;
> >  }
> >  
> > @@ -248,9 +255,6 @@ void f2fs_submit_page_mbio(struct f2fs_io_info *fio)
> >  
> > down_write(>io_rwsem);
> >  
> > -   if (!is_read)
> > -   inc_page_count(sbi, F2FS_WRITEBACK);
> > -
> > if (io->bio && (io->last_block_in_bio != fio->new_blkaddr - 1 ||
> > io->fio.rw != fio->rw))
> > __submit_merged_bio(io);
> > @@ -1047,7 +1051,7 @@ got_it:
> >  */
> > if (bio && (last_block_in_bio != block_nr - 1)) {
> >  submit_and_realloc:
> > -   submit_bio(READ, bio);
> > +   __submit_bio(F2FS_I_SB(inode), READ, bio);
> > bio = NULL;
> > }
> > if (bio == NULL) {
> > @@ -1090,7 +1094,7 @@ set_error_page:
> > goto next_page;
> >  confused:
> > if (bio) {
> > -   submit_bio(READ, bio);
> > +   __submit_bio(F2FS_I_SB(inode), READ, bio);
> > bio = NULL;
> > }
> > unlock_page(page);
> > @@ -1100,7 +1104,7 @@ next_page:
> > }
> > BUG_ON(pages && !list_empty(pages));
> > if (bio)
> > -   submit_bio(READ, bio);
> > +   __submit_bio(F2FS_I_SB(inode), READ, bio);
> > return 0;
> >  }
> >  
> > diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
> > index 37615b2..a188973 100644
> > --- a/fs/f2fs/debug.c
> > +++ b/fs/f2fs/debug.c
> > @@ -48,7 +48,7 @@ static void update_general_status(struct f2fs_sb_info 
> > *sbi)
> > si->ndirty_dirs = sbi->ndirty_inode[DIR_INODE];
> > si->ndirty_files = sbi->ndirty_inode[FILE_INODE];
> > si->inmem_pages = get_pages(sbi, F2FS_INMEM_PAGES);
> > -   si->wb_pages = get_pages(sbi, F2FS_WRITEBACK);
> > +   si->wb_bios = atomic_read(>nr_wb_bios);
> > si->total_count = (int)sbi->user_block_count / sbi->blocks_per_seg;
> > si->rsvd_segs = reserved_segments(sbi);
> >

Re: [PATCH] Staging: comedi: quatech_daqp_cs.c: fixed a warning issue

2016-05-17 Thread Amit Ghadge
On Tue, May 17, 2016 at 06:47:56AM -0700, Greg KH wrote:
> A: http://en.wikipedia.org/wiki/Top_post
> Q: Were do I find info about this thing called top-posting?
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
> 
> A: No.
> Q: Should I include quotations after my reply?
> 
> http://daringfireball.net/2007/07/on_top
Thanks for this valuable information.

> 
> On Tue, May 17, 2016 at 09:31:56AM +0530, Amit Ghadge wrote:
> > Hello Greg KH,
> > 
> > I make patch same like other, I'm new and I nerver see changelog in other 
> > patches.
> > 
> > Where to add changelog? I followed you are tutorial.
> 
> It's the area in the email before the patch, it ends up in the changelog
> when the patch is committed to the kernel tree.  You wrote something
> this time, but it was vague and didn't make sense.  Please fix that up
> and resend.
I resend this patch with patch description.

> 
> greg k-h


[PATCH v4 3/5] locking/rwsem: Don't wake up one's own task

2016-05-17 Thread Waiman Long
As rwsem_down_read_failed() will queue itself and potentially call
__rwsem_do_wake(sem, RWSEM_WAKE_ANY), it is possible that a reader
will try to wake up its own task. This patch adds a check to make
sure that this won't happen.

Signed-off-by: Waiman Long 
Reviewed-by: Peter Hurley 
---
 kernel/locking/rwsem-xadd.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
index c278f5a..007814f 100644
--- a/kernel/locking/rwsem-xadd.c
+++ b/kernel/locking/rwsem-xadd.c
@@ -202,7 +202,8 @@ __rwsem_do_wake(struct rw_semaphore *sem, enum 
rwsem_wake_type wake_type)
 */
smp_mb();
waiter->task = NULL;
-   wake_up_process(tsk);
+   if (tsk != current)
+   wake_up_process(tsk);
put_task_struct(tsk);
} while (--loop);
 
-- 
1.7.1



[PATCH v4 5/5] locking/rwsem: Streamline the rwsem_optimistic_spin() code

2016-05-17 Thread Waiman Long
This patch moves the owner loading and checking code entirely inside of
rwsem_spin_on_owner() to simplify the logic of rwsem_optimistic_spin()
loop.

Suggested-by: Peter Hurley 
Signed-off-by: Waiman Long 
Reviewed-by: Peter Hurley 
---
 kernel/locking/rwsem-xadd.c |   38 --
 1 files changed, 20 insertions(+), 18 deletions(-)

diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
index e3a7e06..a85a2bd 100644
--- a/kernel/locking/rwsem-xadd.c
+++ b/kernel/locking/rwsem-xadd.c
@@ -332,9 +332,16 @@ done:
return ret;
 }
 
-static noinline
-bool rwsem_spin_on_owner(struct rw_semaphore *sem, struct task_struct *owner)
+/*
+ * Return true only if we can still spin on the owner field of the rwsem.
+ */
+static noinline bool rwsem_spin_on_owner(struct rw_semaphore *sem)
 {
+   struct task_struct *owner = READ_ONCE(sem->owner);
+
+   if (!rwsem_owner_is_writer(owner))
+   goto out;
+
rcu_read_lock();
while (sem->owner == owner) {
/*
@@ -354,7 +361,7 @@ bool rwsem_spin_on_owner(struct rw_semaphore *sem, struct 
task_struct *owner)
cpu_relax_lowlatency();
}
rcu_read_unlock();
-
+out:
/*
 * If there is a new owner or the owner is not set, we continue
 * spinning.
@@ -364,7 +371,6 @@ bool rwsem_spin_on_owner(struct rw_semaphore *sem, struct 
task_struct *owner)
 
 static bool rwsem_optimistic_spin(struct rw_semaphore *sem)
 {
-   struct task_struct *owner;
bool taken = false;
 
preempt_disable();
@@ -376,21 +382,17 @@ static bool rwsem_optimistic_spin(struct rw_semaphore 
*sem)
if (!osq_lock(>osq))
goto done;
 
-   while (true) {
-   owner = READ_ONCE(sem->owner);
+   /*
+* Optimistically spin on the owner field and attempt to acquire the
+* lock whenever the owner changes. Spinning will be stopped when:
+*  1) the owning writer isn't running; or
+*  2) readers own the lock as we can't determine if they are
+* actively running or not.
+*/
+   while (rwsem_spin_on_owner(sem)) {
/*
-* Don't spin if
-* 1) the owner is a reader as we we can't determine if the
-*reader is actively running or not.
-* 2) The rwsem_spin_on_owner() returns false which means
-*the owner isn't running.
+* Try to acquire the lock
 */
-   if (rwsem_owner_is_reader(owner) ||
-  (rwsem_owner_is_writer(owner) &&
-  !rwsem_spin_on_owner(sem, owner)))
-   break;
-
-   /* wait_lock will be acquired if write_lock is obtained */
if (rwsem_try_write_lock_unqueued(sem)) {
taken = true;
break;
@@ -402,7 +404,7 @@ static bool rwsem_optimistic_spin(struct rw_semaphore *sem)
 * we're an RT task that will live-lock because we won't let
 * the owner complete.
 */
-   if (!owner && (need_resched() || rt_task(current)))
+   if (!sem->owner && (need_resched() || rt_task(current)))
break;
 
/*
-- 
1.7.1



[PATCH v4 0/5] [PATCH v3 0/4] locking/rwsem: Add reader-owned state to the owner field

2016-05-17 Thread Waiman Long
 v3->v4:
  - Add a new patch 2 to use WRITE_ONCE() for all rwsem->owner stores
to prevent store tearing.

 v2->v3:
  - Make minor code changes as suggested by PeterZ & Peter Hurley.
  - Add 2 minor patches (#2 & #3) to improve the rwsem code
  - Add a 4th patch to streamline the rwsem_optimistic_spin() code.

 v1->v2:
  - Add rwsem_is_reader_owned() helper & rename rwsem_reader_owned()
to rwsem_set_reader_owned().
  - Add more comments to clarify the purpose of some of the code
changes.

Patch 1 is the main patch of this series.

Patch 2 protects against store tearing of rwsem->owner field which 
can cause problem when a reader tries to dereference it.

Patch 3 eliminates redundant wakeup caused by a reader waking itself.

Patch 4 improves the efficiency of the reader wakeup code.

Patch 5 streamlines the rwsem_optimistic_spin() to make it simpler.

Waiman Long (5):
  locking/rwsem: Add reader-owned state to the owner field
  locking/rwsem: Protect all writes to owner by WRITE_ONCE()
  locking/rwsem: Don't wake up one's own task
  locking/rwsem: Improve reader wakeup code
  locking/rwsem: Streamline the rwsem_optimistic_spin() code

 kernel/locking/rwsem-xadd.c |   75 --
 kernel/locking/rwsem.c  |8 +++-
 kernel/locking/rwsem.h  |   52 -
 3 files changed, 99 insertions(+), 36 deletions(-)



[PATCH v4 1/5] locking/rwsem: Add reader-owned state to the owner field

2016-05-17 Thread Waiman Long
Currently, it is not possible to determine for sure if a reader
owns a rwsem by looking at the content of the rwsem data structure.
This patch adds a new state RWSEM_READER_OWNED to the owner field
to indicate that readers currently own the lock. This enables us to
address the following 2 issues in the rwsem optimistic spinning code:

 1) rwsem_can_spin_on_owner() will disallow optimistic spinning if
the owner field is NULL which can mean either the readers own
the lock or the owning writer hasn't set the owner field yet.
In the latter case, we miss the chance to do optimistic spinning.

 2) While a writer is waiting in the OSQ and a reader takes the lock,
the writer will continue to spin when out of the OSQ in the main
rwsem_optimistic_spin() loop as the owner field is NULL wasting
CPU cycles if some of readers are sleeping.

Adding the new state will allow optimistic spinning to go forward as
long as the owner field is not RWSEM_READER_OWNED and the owner is
running, if set, but stop immediately when that state has been reached.

On a 4-socket Haswell machine running on a 4.6-rc1 based kernel, the
fio test with multithreaded randrw and randwrite tests on the same
file on a XFS partition on top of a NVDIMM were run, the aggregated
bandwidths before and after the patch were as follows:

  Test  BW before patch BW after patch  % change
    --- --  
  randrw 988 MB/s  1192 MB/s  +21%
  randwrite 1513 MB/s  1623 MB/s  +7.3%

The perf profile of the rwsem_down_write_failed() function in randrw
before and after the patch were:

   19.95%  5.88%  fio  [kernel.vmlinux]  [k] rwsem_down_write_failed
   14.20%  1.52%  fio  [kernel.vmlinux]  [k] rwsem_down_write_failed

The actual CPU cycles spend in rwsem_down_write_failed() dropped from
5.88% to 1.52% after the patch.

The xfstests was also run and no regression was observed.

Signed-off-by: Waiman Long 
Acked-by: Jason Low 
Acked-by: Davidlohr Bueso 
---
 kernel/locking/rwsem-xadd.c |   41 ++---
 kernel/locking/rwsem.c  |8 ++--
 kernel/locking/rwsem.h  |   41 +
 3 files changed, 69 insertions(+), 21 deletions(-)

diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
index 09e30c6..c278f5a 100644
--- a/kernel/locking/rwsem-xadd.c
+++ b/kernel/locking/rwsem-xadd.c
@@ -155,6 +155,12 @@ __rwsem_do_wake(struct rw_semaphore *sem, enum 
rwsem_wake_type wake_type)
/* Last active locker left. Retry waking readers. */
goto try_reader_grant;
}
+   /*
+* It is not really necessary to set it to reader-owned here,
+* but it gives the spinners an early indication that the
+* readers now have the lock.
+*/
+   rwsem_set_reader_owned(sem);
}
 
/* Grant an infinite number of read locks to the readers at the front
@@ -306,16 +312,11 @@ static inline bool rwsem_can_spin_on_owner(struct 
rw_semaphore *sem)
 
rcu_read_lock();
owner = READ_ONCE(sem->owner);
-   if (!owner) {
-   long count = READ_ONCE(sem->count);
+   if (!rwsem_owner_is_writer(owner)) {
/*
-* If sem->owner is not set, yet we have just recently entered 
the
-* slowpath with the lock being active, then there is a 
possibility
-* reader(s) may have the lock. To be safe, bail spinning in 
these
-* situations.
+* Don't spin if the rwsem is readers owned.
 */
-   if (count & RWSEM_ACTIVE_MASK)
-   ret = false;
+   ret = !rwsem_owner_is_reader(owner);
goto done;
}
 
@@ -328,8 +329,6 @@ done:
 static noinline
 bool rwsem_spin_on_owner(struct rw_semaphore *sem, struct task_struct *owner)
 {
-   long count;
-
rcu_read_lock();
while (sem->owner == owner) {
/*
@@ -350,16 +349,11 @@ bool rwsem_spin_on_owner(struct rw_semaphore *sem, struct 
task_struct *owner)
}
rcu_read_unlock();
 
-   if (READ_ONCE(sem->owner))
-   return true; /* new owner, continue spinning */
-
/*
-* When the owner is not set, the lock could be free or
-* held by readers. Check the counter to verify the
-* state.
+* If there is a new owner or the owner is not set, we continue
+* spinning.
 */
-   count = READ_ONCE(sem->count);
-   return (count == 0 || count == RWSEM_WAITING_BIAS);
+   return !rwsem_owner_is_reader(READ_ONCE(sem->owner));
 }
 
 static bool rwsem_optimistic_spin(struct rw_semaphore *sem)
@@ -378,7 +372,16 @@ static bool rwsem_optimistic_spin(struct 

[PATCH v4 2/5] locking/rwsem: Protect all writes to owner by WRITE_ONCE()

2016-05-17 Thread Waiman Long
Without using WRITE_ONCE(), the compiler can potentially break a
write into multiple smaller ones (store tearing). So a read from the
same data by another task concurrently may return a partial result.
This can result in a kernel crash if the data is a memory address
that is being dereferenced.

This patch changes all write to rwsem->owner to use WRITE_ONCE()
to make sure that store tearing will not happen. READ_ONCE() may
not be needed for rwsem->owner as long as the value is only used for
comparison and not dereferencing.

Signed-off-by: Waiman Long 
---
 kernel/locking/rwsem.h |   13 ++---
 1 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/kernel/locking/rwsem.h b/kernel/locking/rwsem.h
index 8f43ba2..a699f40 100644
--- a/kernel/locking/rwsem.h
+++ b/kernel/locking/rwsem.h
@@ -16,14 +16,21 @@
 #define RWSEM_READER_OWNED ((struct task_struct *)1UL)
 
 #ifdef CONFIG_RWSEM_SPIN_ON_OWNER
+/*
+ * All writes to owner are protected by WRITE_ONCE() to make sure that
+ * store tearing can't happen as optimistic spinners may read and use
+ * the owner value concurrently without lock. Read from owner, however,
+ * may not need READ_ONCE() as long as the pointer value is only used
+ * for comparison and isn't being dereferenced.
+ */
 static inline void rwsem_set_owner(struct rw_semaphore *sem)
 {
-   sem->owner = current;
+   WRITE_ONCE(sem->owner, current);
 }
 
 static inline void rwsem_clear_owner(struct rw_semaphore *sem)
 {
-   sem->owner = NULL;
+   WRITE_ONCE(sem->owner, NULL);
 }
 
 static inline void rwsem_set_reader_owned(struct rw_semaphore *sem)
@@ -34,7 +41,7 @@ static inline void rwsem_set_reader_owned(struct rw_semaphore 
*sem)
 * to minimize cacheline contention.
 */
if (sem->owner != RWSEM_READER_OWNED)
-   sem->owner = RWSEM_READER_OWNED;
+   WRITE_ONCE(sem->owner, RWSEM_READER_OWNED);
 }
 
 static inline bool rwsem_owner_is_writer(struct task_struct *owner)
-- 
1.7.1



[PATCH v4 4/5] locking/rwsem: Improve reader wakeup code

2016-05-17 Thread Waiman Long
In __rwsem_do_wake(), the reader wakeup code will assume a writer
has stolen the lock if the active reader/writer count is not 0.
However, this is not as reliable an indicator as the original
"< RWSEM_WAITING_BIAS" check. If another reader is present, the code
will still break out and exit even if the writer is gone. This patch
changes it to check the same "< RWSEM_WAITING_BIAS" condition to
reduce the chance of false positive.

Signed-off-by: Waiman Long 
Reviewed-by: Peter Hurley 
---
 kernel/locking/rwsem-xadd.c |   11 ---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
index 007814f..e3a7e06 100644
--- a/kernel/locking/rwsem-xadd.c
+++ b/kernel/locking/rwsem-xadd.c
@@ -148,9 +148,14 @@ __rwsem_do_wake(struct rw_semaphore *sem, enum 
rwsem_wake_type wake_type)
  try_reader_grant:
oldcount = rwsem_atomic_update(adjustment, sem) - adjustment;
if (unlikely(oldcount < RWSEM_WAITING_BIAS)) {
-   /* A writer stole the lock. Undo our reader grant. */
-   if (rwsem_atomic_update(-adjustment, sem) &
-   RWSEM_ACTIVE_MASK)
+   /*
+* If the count is still less than RWSEM_WAITING_BIAS
+* after removing the adjustment, it is assumed that
+* a writer has stolen the lock. We have to undo our
+* reader grant.
+*/
+   if (rwsem_atomic_update(-adjustment, sem)
+   < RWSEM_WAITING_BIAS)
goto out;
/* Last active locker left. Retry waking readers. */
goto try_reader_grant;
-- 
1.7.1



RE: [RFC PATCH 1/2] ACPI / button: Send "open" state after boot/resume

2016-05-17 Thread Zheng, Lv
Hi, Rafael

Thanks for the review.

> From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of
> Rafael J. Wysocki
> Sent: Wednesday, May 18, 2016 7:37 AM
> To: Zheng, Lv 
> Cc: Wysocki, Rafael J ; Rafael J. Wysocki
> ; Brown, Len ; Lv Zheng
> ; Linux Kernel Mailing List  ker...@vger.kernel.org>; ACPI Devel Maling List ;
> Bastien Nocera: 
> Subject: Re: [RFC PATCH 1/2] ACPI / button: Send "open" state after
> boot/resume
> 
> On Tue, May 17, 2016 at 10:27 AM, Lv Zheng  wrote:
> > (This patch hasn't been tested, it's sent for comments)
> 
> I have a couple of concerns (see below).
> 
> > Linux userspace (systemd-logind) keeps on rechecking lid state when the
> > lid state is closed. If it failed to update the lid state to open after
> > boot/resume, it could suspend the system. But as:
> > 1. Traditional ACPI platform may not generate the lid open event after
> >resuming as the open event is actually handled by the BIOS and the system
> >is then resumed from a FACS vector.
> > 2. The _LID control method's initial returning value is not reliable. The
> >_LID control method is described to return the "current" lid state,
> >however the word of "current" has ambiguity, many BIOSen return lid
> >state upon last lid notification while the developers may think the
> >BIOSen should always return the lid state upon last _LID evaluation.
> >There won't be difference when we evaluate _LID during the runtime, the
> >problem is the initial returning value of this function. When the BIOSen
> >implement this control method with cached value, the initial returning
> >value is likely not reliable.
> > Thus there is no mean for the ACPI lid driver to provide such an event
> > conveying correct current lid state. When there is no such an event or the
> > event conveys wrong result, false suspending can be examined.
> >
> > The root cause of the issue is systemd itself, it could handle the ACPI
> > control method lid device by implementing a special option like
> > LidSwitchLevelTriggered=False when it detected the ACPI lid device. However
> > there is no explicit documentation clarified the ambiguity, we need to
> > work it around in the kernel before systemd changing its mind.
> 
> The above doesn't explain how the issue is addressed here.
[Lv Zheng] 
The story is a bit long.
We can see several issues that some platform suspends right after boot/resume.
We noticed that on that platforms, _LID is always implemented with cached lid 
state returned.
And it's initial returning value may be "closed" after boot/resume.

It appears the acpi_lid_send_state() sent after boot/resume is the culprit to 
report the wrong lid state to the userspace.
But to our surprise, after delete the 2 lines, reporters still can see suspends 
after boot/resume.
That's because of systemd implementation.
It contains code logic that:
When the lid state is closed, a re-checking mechanism is installed.
So if we do not send any notification after boot/resume and the old lid state 
is "closed".
systemd determines to suspend in the re-checking mechanism.


> 
> > Link 1: https://lkml.org/2016/3/7/460
> > Link 2: https://github.com/systemd/systemd/issues/2087
> > Link 3: https://bugzilla.kernel.org/show_bug.cgi?id=89211
> > https://bugzilla.kernel.org/show_bug.cgi?id=106151
> > https://bugzilla.kernel.org/show_bug.cgi?id=106941
> > Signed-off-by: Lv Zheng 
> > Cc: Bastien Nocera: 
> > ---
> >  drivers/acpi/button.c |   63
> +
> >  1 file changed, 59 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
> > index 5c3b091..bb14ca5 100644
> > --- a/drivers/acpi/button.c
> > +++ b/drivers/acpi/button.c
> > @@ -53,6 +53,10 @@
> >  #define ACPI_BUTTON_DEVICE_NAME_LID"Lid Switch"
> >  #define ACPI_BUTTON_TYPE_LID   0x05
> >
> > +#define ACPI_BUTTON_LID_INIT_IGNORE0x00
> > +#define ACPI_BUTTON_LID_INIT_OPEN  0x01
> > +#define ACPI_BUTTON_LID_INIT_METHOD0x02
> > +
> >  #define _COMPONENT ACPI_BUTTON_COMPONENT
> >  ACPI_MODULE_NAME("button");
> >
> > @@ -105,6 +109,7 @@ struct acpi_button {
> >
> >  static BLOCKING_NOTIFIER_HEAD(acpi_lid_notifier);
> >  static struct acpi_device *lid_device;
> > +static u8 lid_init_state = ACPI_BUTTON_LID_INIT_OPEN;
> >
> >  /* 
> > --
> >FS Interface (/proc)
> > @@ -246,7 +251,8 @@ int acpi_lid_open(void)
> >  }
> >  EXPORT_SYMBOL(acpi_lid_open);
> >
> > -static int acpi_lid_send_state(struct acpi_device *device)
> > +static int acpi_lid_send_state(struct acpi_device *device,
> > +  bool 

Re: [PATCH v7 00/10] Add error checking to spi-nor read and write

2016-05-17 Thread Brian Norris
On Mon, May 16, 2016 at 09:47:20PM +0200, Michal Suchanek wrote:
> Hello,
> 
> On 6 May 2016 at 02:31, Brian Norris  wrote:
> > Hi,
> >
> > I'm picking up Michal's patch set, since he dropped it on the floor, and 
> > it's
> > useful for others. My additions:
> >
> >  * rebased on latest
> >  * added fixes for drivers that have been merged in the meantime
> >  * addressed most of Heiner's comments
> >
> 
> Since that offset error slipped into the previous rebase I was
> planning to do some more thorough testing before resubmit but did not
> get to it yet.
> 
> Thanks for picking this up.

No problem. If you get the chance, one or more of
{Reviewed,Tested,Acked}-by would be helpful.

Brian


[PATCH v2] net: Fix coding style warnings and errors.

2016-05-17 Thread Amit Ghadge
This is a patch to clean checkpatch warnings and errors
in the Space.c file.
Clean up the following warnings and errors.

WARNING :
* Block comments use * on subsequent lines
* Missing a blank line after declarations
* networking block comments don't use an empty /* line, use /*
* please, no space before tabs
* please, no spaces at the start of a line
* line over 80 characters

ERROR :
* code indent should use tabs where possible
* space prohibited after that open parenthesis '('

Signed-off-by: Amit Ghadge 
---
Changes v2 :
  - Added space between the "/*" and "ISA".
---
 drivers/net/Space.c | 21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/drivers/net/Space.c b/drivers/net/Space.c
index 67977f1..11fe712 100644
--- a/drivers/net/Space.c
+++ b/drivers/net/Space.c
@@ -35,8 +35,8 @@
 #include 
 
 /* A unified ethernet device probe.  This is the easiest way to have every
-   ethernet adaptor have the name "eth[0123...]".
-   */
+ * ethernet adaptor have the name "eth[0123...]".
+ */
 
 struct devprobe2 {
struct net_device *(*probe)(int unit);
@@ -46,6 +46,7 @@ struct devprobe2 {
 static int __init probe_list2(int unit, struct devprobe2 *p, int autoprobe)
 {
struct net_device *dev;
+
for (; p->probe; p++) {
if (autoprobe && p->status)
continue;
@@ -58,8 +59,7 @@ static int __init probe_list2(int unit, struct devprobe2 *p, 
int autoprobe)
return -ENODEV;
 }
 
-/*
- * ISA probes that touch addresses < 0x400 (including those that also
+/* ISA probes that touch addresses < 0x400 (including those that also
  * look for EISA/PCI cards in addition to ISA cards).
  */
 static struct devprobe2 isa_probes[] __initdata = {
@@ -86,11 +86,11 @@ static struct devprobe2 isa_probes[] __initdata = {
 #endif
 #ifdef CONFIG_CS89x0
 #ifndef CONFIG_CS89x0_PLATFORM
-   {cs89x0_probe, 0},
+   {cs89x0_probe, 0},
 #endif
 #endif
-#if defined(CONFIG_MVME16x_NET) || defined(CONFIG_BVME6000_NET)/* 
Intel I82596 */
-   {i82596_probe, 0},
+#if defined(CONFIG_MVME16x_NET) || defined(CONFIG_BVME6000_NET)/* 
Intel */
+   {i82596_probe, 0},  /* I82596 */
 #endif
 #ifdef CONFIG_NI65
{ni65_probe, 0},
@@ -118,13 +118,12 @@ static struct devprobe2 m68k_probes[] __initdata = {
{mac8390_probe, 0},
 #endif
 #ifdef CONFIG_MAC89x0
-   {mac89x0_probe, 0},
+   {mac89x0_probe, 0},
 #endif
{NULL, 0},
 };
 
-/*
- * Unified ethernet device probe, segmented per architecture and
+/* Unified ethernet device probe, segmented per architecture and
  * per bus interface. This drives the legacy devices only for now.
  */
 
@@ -135,7 +134,7 @@ static void __init ethif_probe2(int unit)
if (base_addr == 1)
return;
 
-   (void)( probe_list2(unit, m68k_probes, base_addr == 0) &&
+   (void)(probe_list2(unit, m68k_probes, base_addr == 0) &&
probe_list2(unit, isa_probes, base_addr == 0));
 }
 
-- 
2.5.5



Re: [f2fs-dev] [PATCH] f2fs: use bio count instead of F2FS_WRITEBACK page count

2016-05-17 Thread Chao Yu
Hi Jaegeuk,

On 2016/5/18 8:44, Jaegeuk Kim wrote:
> This can reduce page counting overhead.

We change to increase one reference for one bio, but block layer can split or
merge bios by itself, and write_end will be called per bio, so the reference may
be maintained incorrectly?

Thanks,

> 
> Signed-off-by: Jaegeuk Kim 
> ---
>  fs/f2fs/checkpoint.c |  2 +-
>  fs/f2fs/data.c   | 26 +++---
>  fs/f2fs/debug.c  |  6 +++---
>  fs/f2fs/f2fs.h   |  4 ++--
>  fs/f2fs/super.c  |  2 +-
>  5 files changed, 22 insertions(+), 18 deletions(-)
> 
> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
> index d04113b..447e2a9 100644
> --- a/fs/f2fs/checkpoint.c
> +++ b/fs/f2fs/checkpoint.c
> @@ -914,7 +914,7 @@ static void wait_on_all_pages_writeback(struct 
> f2fs_sb_info *sbi)
>   for (;;) {
>   prepare_to_wait(>cp_wait, , TASK_UNINTERRUPTIBLE);
>  
> - if (!get_pages(sbi, F2FS_WRITEBACK))
> + if (!atomic_read(>nr_wb_bios))
>   break;
>  
>   io_schedule_timeout(5*HZ);
> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> index 1013836..faef666 100644
> --- a/fs/f2fs/data.c
> +++ b/fs/f2fs/data.c
> @@ -71,10 +71,9 @@ static void f2fs_write_end_io(struct bio *bio)
>   f2fs_stop_checkpoint(sbi);
>   }
>   end_page_writeback(page);
> - dec_page_count(sbi, F2FS_WRITEBACK);
>   }
> -
> - if (!get_pages(sbi, F2FS_WRITEBACK) && wq_has_sleeper(>cp_wait))
> + if (atomic_dec_and_test(>nr_wb_bios) &&
> + wq_has_sleeper(>cp_wait))
>   wake_up(>cp_wait);
>  
>   bio_put(bio);
> @@ -98,6 +97,14 @@ static struct bio *__bio_alloc(struct f2fs_sb_info *sbi, 
> block_t blk_addr,
>   return bio;
>  }
>  
> +static inline void __submit_bio(struct f2fs_sb_info *sbi, int rw,
> + struct bio *bio)
> +{
> + if (!is_read_io(rw))
> + atomic_inc(>nr_wb_bios);
> + submit_bio(rw, bio);
> +}
> +
>  static void __submit_merged_bio(struct f2fs_bio_info *io)
>  {
>   struct f2fs_io_info *fio = >fio;
> @@ -110,7 +117,7 @@ static void __submit_merged_bio(struct f2fs_bio_info *io)
>   else
>   trace_f2fs_submit_write_bio(io->sbi->sb, fio, io->bio);
>  
> - submit_bio(fio->rw, io->bio);
> + __submit_bio(io->sbi, fio->rw, io->bio);
>   io->bio = NULL;
>  }
>  
> @@ -228,7 +235,7 @@ int f2fs_submit_page_bio(struct f2fs_io_info *fio)
>   return -EFAULT;
>   }
>  
> - submit_bio(fio->rw, bio);
> + __submit_bio(fio->sbi, fio->rw, bio);
>   return 0;
>  }
>  
> @@ -248,9 +255,6 @@ void f2fs_submit_page_mbio(struct f2fs_io_info *fio)
>  
>   down_write(>io_rwsem);
>  
> - if (!is_read)
> - inc_page_count(sbi, F2FS_WRITEBACK);
> -
>   if (io->bio && (io->last_block_in_bio != fio->new_blkaddr - 1 ||
>   io->fio.rw != fio->rw))
>   __submit_merged_bio(io);
> @@ -1047,7 +1051,7 @@ got_it:
>*/
>   if (bio && (last_block_in_bio != block_nr - 1)) {
>  submit_and_realloc:
> - submit_bio(READ, bio);
> + __submit_bio(F2FS_I_SB(inode), READ, bio);
>   bio = NULL;
>   }
>   if (bio == NULL) {
> @@ -1090,7 +1094,7 @@ set_error_page:
>   goto next_page;
>  confused:
>   if (bio) {
> - submit_bio(READ, bio);
> + __submit_bio(F2FS_I_SB(inode), READ, bio);
>   bio = NULL;
>   }
>   unlock_page(page);
> @@ -1100,7 +1104,7 @@ next_page:
>   }
>   BUG_ON(pages && !list_empty(pages));
>   if (bio)
> - submit_bio(READ, bio);
> + __submit_bio(F2FS_I_SB(inode), READ, bio);
>   return 0;
>  }
>  
> diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
> index 37615b2..a188973 100644
> --- a/fs/f2fs/debug.c
> +++ b/fs/f2fs/debug.c
> @@ -48,7 +48,7 @@ static void update_general_status(struct f2fs_sb_info *sbi)
>   si->ndirty_dirs = sbi->ndirty_inode[DIR_INODE];
>   si->ndirty_files = sbi->ndirty_inode[FILE_INODE];
>   si->inmem_pages = get_pages(sbi, F2FS_INMEM_PAGES);
> - si->wb_pages = get_pages(sbi, F2FS_WRITEBACK);
> + si->wb_bios = atomic_read(>nr_wb_bios);
>   si->total_count = (int)sbi->user_block_count / sbi->blocks_per_seg;
>   si->rsvd_segs = reserved_segments(sbi);
>   si->overp_segs = overprovision_segments(sbi);
> @@ -299,8 +299,8 @@ static int stat_show(struct seq_file *s, void *v)
>   seq_printf(s, "  - Inner Struct Count: tree: %d(%d), node: 
> %d\n",
>   si->ext_tree, si->zombie_tree, si->ext_node);
>   seq_puts(s, "\nBalancing F2FS Async:\n");
> - seq_printf(s, "  - inmem: %4d, wb: %4d\n",

RE: [PATCH 2/3] ACPI: table upgrade: move early_initrd_acpi_init() to header file

2016-05-17 Thread Zheng, Lv
Hi,

> From: Aleksey Makarov [mailto:aleksey.maka...@linaro.org]
> Subject: [PATCH 2/3] ACPI: table upgrade: move early_initrd_acpi_init() to
> header file
> 
> Move early_initrd_acpi_init() to header file so that
> it can be used with architectures other than X86
[Lv Zheng] 
The patch looks OK to me.
Except 2 possible improvements.
You can feel free to add Acked-by: Lv Zheng 

> 
> Signed-off-by: Aleksey Makarov 
> ---
>  arch/x86/kernel/setup.c | 7 ---
>  drivers/acpi/tables.c   | 7 +--
>  include/linux/acpi.h| 4 ++--
>  3 files changed, 7 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index c4e7b39..5ddbbfd 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -399,10 +399,6 @@ static void __init reserve_initrd(void)
>   memblock_free(ramdisk_image, ramdisk_end - ramdisk_image);
>  }
> 
> -static void __init early_initrd_acpi_init(void)
> -{
> - early_acpi_table_init((void *)initrd_start, initrd_end - initrd_start);
> -}
>  #else
>  static void __init early_reserve_initrd(void)
>  {
> @@ -410,9 +406,6 @@ static void __init early_reserve_initrd(void)
>  static void __init reserve_initrd(void)
>  {
>  }
> -static void __init early_initrd_acpi_init(void)
> -{
> -}
>  #endif /* CONFIG_BLK_DEV_INITRD */
> 
>  static void __init parse_setup_data(void)
> diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
> index 449a649..82be84a 100644
> --- a/drivers/acpi/tables.c
> +++ b/drivers/acpi/tables.c
> @@ -34,6 +34,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "internal.h"
> 
>  #ifdef CONFIG_ACPI_CUSTOM_DSDT
> @@ -742,9 +743,11 @@ acpi_os_table_override(struct acpi_table_header
> *existing_table,
>   return AE_OK;
>  }
> 
> -void __init early_acpi_table_init(void *data, size_t size)
> +void __init early_initrd_acpi_init(void)
>  {
> - acpi_table_initrd_init(data, size);
> +#ifdef CONFIG_BLK_DEV_INITRD
> + acpi_table_initrd_init((void *)initrd_start, initrd_end - initrd_start);
> +#endif
>  }
[Lv Zheng] 
Please avoid to make #ifdef appearing in a function body.
You may consider a way to maintain #ifdef CONFIG_xxx at function boundary.
The point is:
#ifdef should be maintained at the function boundary, this is an implicit 
(maybe explicit in Documentation) programming rule in Linux.
This helps to split the "functionality" and the "dependency" to make the code 
cleaner and easier to follow.

For this case, you may:
#ifdef CONFIG_BLK_DEV_INTRD
#define ACPI_TABLE_INITRD_DATA  (initrd_start)
#define ACPI_TABLE_INITRD_SIZE  (initrd_end - initrd_start)
#else
#define ACPI_TABLE_INITRD_DATA  NULL
#define ACPI_TABLE_INITRD_SIZE  0
#endif

Or you can:
Use initrd_start, inird_end directly in acpi_table_initrd_init, and delete its 
arguments.
By doing so, you are able to achieve in-function #ifdef elimination by 
providing a stub for acpi_table_initrd_init().

> 
>  /*
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 288fac5..cb700c1 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -208,7 +208,7 @@ void acpi_boot_table_init (void);
>  int acpi_mps_check (void);
>  int acpi_numa_init (void);
> 
> -void early_acpi_table_init(void *data, size_t size);
> +void early_initrd_acpi_init(void);
>  int acpi_table_init (void);
>  int acpi_table_parse(char *id, acpi_tbl_table_handler handler);
>  int __init acpi_parse_entries(char *id, unsigned long table_size,
> @@ -588,7 +588,7 @@ static inline const char *acpi_dev_name(struct
> acpi_device *adev)
>   return NULL;
>  }
> 
> -static inline void early_acpi_table_init(void *data, size_t size) { }
> +static inline void early_initrd_acpi_init(void) { }
>  static inline void acpi_early_init(void) { }
>  static inline void acpi_subsystem_init(void) { }
> 
[Lv Zheng] 
You can rename early_initrd_acpi_init to early_acpi_table_init.
We'd prefer not to export "initrd" awareness from acpi.h.

Thanks and best regards
-Lv

> --
> 2.8.2



Re: [PATCH 1/1] net: hns: avoid null pointer dereference

2016-05-17 Thread Yisen Zhuang
Hi Heinrich,

This patch is fine to me.

Thanks,

Yisen

在 2016/5/18 4:01, Heinrich Schuchardt 写道:
> In the statement
>   assert(priv || priv->ae_handle);
> the right side of || is only evaluated if priv is null.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  drivers/net/ethernet/hisilicon/hns/hns_ethtool.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c 
> b/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c
> index 3d746c8..834a50a 100644
> --- a/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c
> +++ b/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c
> @@ -720,7 +720,7 @@ static int hns_set_pauseparam(struct net_device *net_dev,
>   struct hnae_handle *h;
>   struct hnae_ae_ops *ops;
>  
> - assert(priv || priv->ae_handle);
> + assert(priv && priv->ae_handle);
>  
>   h = priv->ae_handle;
>   ops = h->dev->ops;
> @@ -780,7 +780,7 @@ static int hns_set_coalesce(struct net_device *net_dev,
>   struct hnae_ae_ops *ops;
>   int ret;
>  
> - assert(priv || priv->ae_handle);
> + assert(priv && priv->ae_handle);
>  
>   ops = priv->ae_handle->dev->ops;
>  
> @@ -,7 +,7 @@ void hns_get_regs(struct net_device *net_dev, struct 
> ethtool_regs *cmd,
>   struct hns_nic_priv *priv = netdev_priv(net_dev);
>   struct hnae_ae_ops *ops;
>  
> - assert(priv || priv->ae_handle);
> + assert(priv && priv->ae_handle);
>  
>   ops = priv->ae_handle->dev->ops;
>  
> @@ -1135,7 +1135,7 @@ static int hns_get_regs_len(struct net_device *net_dev)
>   struct hns_nic_priv *priv = netdev_priv(net_dev);
>   struct hnae_ae_ops *ops;
>  
> - assert(priv || priv->ae_handle);
> + assert(priv && priv->ae_handle);
>  
>   ops = priv->ae_handle->dev->ops;
>   if (!ops->get_regs_len) {
> 



Re: [PATCH] mm: unhide vmstat_text definition for CONFIG_SMP

2016-05-17 Thread Hugh Dickins
On Tue, 17 May 2016, Michal Hocko wrote:
> On Mon 16-05-16 15:36:56, Andrew Morton wrote:
> > On Mon, 16 May 2016 16:23:33 +0200 Michal Hocko  wrote:
> > 
> > > Andrew, I think that the following is more straightforward fix and
> > > should be folded in to the patch which has introduced vmstat_refresh.
> > > ---
> > > >From b8dd18fb7df040e1bfe61aadde1d903589de15e4 Mon Sep 17 00:00:00 2001
> > > From: Michal Hocko 
> > > Date: Mon, 16 May 2016 16:19:53 +0200
> > > Subject: [PATCH] mmotm: 
> > > mm-proc-sys-vm-stat_refresh-to-force-vmstat-update-fix
> > > 
> > > Arnd has reported:
> > > In randconfig builds with sysfs, procfs and numa all disabled,
> > > but SMP enabled, we now get a link error in the newly introduced
> > > vmstat_refresh function:
> > > 
> > > mm/built-in.o: In function `vmstat_refresh':
> > > :(.text+0x15c78): undefined reference to `vmstat_text'
> > > 
> > > vmstat_refresh is proc_fs specific so there is no reason to define it
> > > when !CONFIG_PROC_FS.
> > 
> > I already had this:
> > 
> > From: Christoph Lameter 
> > Subject: Do not build vmstat_refresh if there is no procfs support
> > 
> > It makes no sense to build functionality into the kernel that
> > cannot be used and causes build issues.
> > 
> > Link: 
> > http://lkml.kernel.org/r/alpine.deb.2.20.1605111011260.9...@east.gentwo.org
> > Signed-off-by: Christoph Lameter 
> > Reported-by: Arnd Bergmann 
> > Signed-off-by: Andrew Morton 
> 
> But this is broken:
> http://lkml.kernel.org/r/20160516073144.ga23...@dhcp22.suse.cz and
> kbuild robot agrees
> http://lkml.kernel.org/r/201605171333.anqjcwpy%fengguang...@intel.com

Sorry for my noise, sorry for my silence, thanks to Arnd and everyone
for chipping in.  But now I try it, I find that even Michal's is not
quite right: if you build without CONFIG_PROC_FS, then it gives you
mm/vmstat.c:1381:13: warning: `refresh_vm_stats' defined but not used 
[-Wunused-function]
(well, that was on a tree with different line numbering).
So here's my attempt...

Signed-off-by: Hugh Dickins 
---
Fix to merge into mm-proc-sys-vm-stat_refresh-to-force-vmstat-update.patch

 mm/vmstat.c |2 ++
 1 file changed, 2 insertions(+)

--- 4.6-rc7-mm1/mm/vmstat.c 2016-05-14 08:29:10.609386264 -0700
+++ linux/mm/vmstat.c   2016-05-17 17:43:02.861862648 -0700
@@ -1365,6 +1365,7 @@ static struct workqueue_struct *vmstat_w
 static DEFINE_PER_CPU(struct delayed_work, vmstat_work);
 int sysctl_stat_interval __read_mostly = HZ;
 
+#ifdef CONFIG_PROC_FS
 static void refresh_vm_stats(struct work_struct *work)
 {
refresh_cpu_vm_stats(true);
@@ -1422,6 +1423,7 @@ int vmstat_refresh(struct ctl_table *tab
*lenp = 0;
return 0;
 }
+#endif /* CONFIG_PROC_FS */
 
 static void vmstat_update(struct work_struct *w)
 {


Re: [GIT] Networking

2016-05-17 Thread Linus Torvalds
On Tue, May 17, 2016 at 12:11 PM, David Miller  wrote:
>
> Highlights:

Lowlights:

 1) the iwlwifi driver seems to be broken

My laptop that uses the intel 7680 iwlwifi module no longer connects
to the network. It fails with a "Microcode SW error detected." and
spews out register state over and over again.

The last thing it says before falling over is:

  wlp1s0: authenticate with xx:xx:xx:xx:xx:xx
  wlp1s0: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
  wlp1s0: send auth to xx:xx:xx:xx:xx:xx (try 2/3)

and then it goes all titsup.

I thought that it might be because I had downloaded one of the daily
firmware versions (it calls itself iwlwifi-7260-17.ucode, but isn't a
real release afaik - but it has worked fien for me before), but the
problem persists with the ver-16 ucode too, so that wasn't it.

I haven't bisected it, but there is absolutely nothing odd in my hardware.

I do have a 802.11ac network, which apparently not everybody does,
judging by previous bug-reports of mine..

Intel iwlwifi people: please check this out.

   Linus


[PATCH 1/1] brcm80211: simplify assignment

2016-05-17 Thread Heinrich Schuchardt
Simplify assignment in wlc_phy_rxcal_gainctrl_nphy_rev5.

Signed-off-by: Heinrich Schuchardt 
---
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
index 99dac9b..b3aab2f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
@@ -27017,7 +27017,7 @@ wlc_phy_rxcal_gainctrl_nphy_rev5(struct brcms_phy *pi, 
u8 rx_core,
tx_core = 1 - rx_core;
 
num_samps = 1024;
-   desired_log2_pwr = (cal_type == 0) ? 13 : 13;
+   desired_log2_pwr = 13;
 
wlc_phy_rx_iq_coeffs_nphy(pi, 0, _comp);
zero_comp.a0 = zero_comp.b0 = zero_comp.a1 = zero_comp.b1 = 0x0;
-- 
2.1.4



Re: [PATCH] powercap/rapl: Do not load in virtualized environments

2016-05-17 Thread Rafael J. Wysocki
On Tue, May 17, 2016 at 1:34 PM, Prarit Bhargava  wrote:
> intel_rapl is currently not supported in virtualized environments.  When
> booting the warning message
>
> intel_rapl: no valid rapl domains found in package 0

You seem to be saying that this message is problematic for some
reason, so why is it?

> is output for every virtual core.
>
> This patch stops the driver from being loaded in virtual boots.
>
> Cc: Srinivas Pandruvada 
> Cc: Jacob Jun Pan 
> Cc: "Rafael J. Wysocki" 
> Cc: linux...@vger.kernel.org
> Signed-off-by: Prarit Bhargava 
> ---
>  drivers/powercap/intel_rapl.c |5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c
> index f2201d42a9cd..bebfbe8acccd 100644
> --- a/drivers/powercap/intel_rapl.c
> +++ b/drivers/powercap/intel_rapl.c
> @@ -29,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  #include 
> @@ -1600,6 +1601,10 @@ static int __init rapl_init(void)
> return -ENODEV;
> }
>
> +   /* Intel RAPL is not supported on virtualized environments */
> +   if (x86_hyper)
> +   return -ENODEV;
> +
> rapl_defaults = (struct rapl_defaults *)id->driver_data;
>
> cpu_notifier_register_begin();
> --


Re: [PATCH] mmc: dw_mmc: Consider HLE errors to be data and command errors

2016-05-17 Thread Doug Anderson
Jaehoon,

On Mon, Mar 30, 2015 at 8:47 AM, Doug Anderson  wrote:
> Jaehoon,
>
> On Sun, Mar 29, 2015 at 5:55 PM, Jaehoon Chung  wrote:
>> Dear Doug,
>>
>> I'm considering to control HLE error..So holding this patch.
>> If this is absolutely necessary patch, let me know, plz.
>>
>> Best Regards,
>> Jaehoon Chung
>
> Sounds OK.  I have certainly applied this locally and the driver isn't
> robust against insertions / removals without it, but once the card is
> inserted things are OK so it's probably not urgent that it be applied
> upstream.  Hopefully we can figure out a better solution...

I'm now testing a nice new rebased kernel and I'm hitting this again.

Of course I'll just pick my same patch to my new kernel tree, but
since it's been a year and nobody has done anything better, would you
consider landing my patch?  It is certainly better than nothing.

-Doug


[PATCH] f2fs: use bio count instead of F2FS_WRITEBACK page count

2016-05-17 Thread Jaegeuk Kim
This can reduce page counting overhead.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/checkpoint.c |  2 +-
 fs/f2fs/data.c   | 26 +++---
 fs/f2fs/debug.c  |  6 +++---
 fs/f2fs/f2fs.h   |  4 ++--
 fs/f2fs/super.c  |  2 +-
 5 files changed, 22 insertions(+), 18 deletions(-)

diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index d04113b..447e2a9 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -914,7 +914,7 @@ static void wait_on_all_pages_writeback(struct f2fs_sb_info 
*sbi)
for (;;) {
prepare_to_wait(>cp_wait, , TASK_UNINTERRUPTIBLE);
 
-   if (!get_pages(sbi, F2FS_WRITEBACK))
+   if (!atomic_read(>nr_wb_bios))
break;
 
io_schedule_timeout(5*HZ);
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 1013836..faef666 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -71,10 +71,9 @@ static void f2fs_write_end_io(struct bio *bio)
f2fs_stop_checkpoint(sbi);
}
end_page_writeback(page);
-   dec_page_count(sbi, F2FS_WRITEBACK);
}
-
-   if (!get_pages(sbi, F2FS_WRITEBACK) && wq_has_sleeper(>cp_wait))
+   if (atomic_dec_and_test(>nr_wb_bios) &&
+   wq_has_sleeper(>cp_wait))
wake_up(>cp_wait);
 
bio_put(bio);
@@ -98,6 +97,14 @@ static struct bio *__bio_alloc(struct f2fs_sb_info *sbi, 
block_t blk_addr,
return bio;
 }
 
+static inline void __submit_bio(struct f2fs_sb_info *sbi, int rw,
+   struct bio *bio)
+{
+   if (!is_read_io(rw))
+   atomic_inc(>nr_wb_bios);
+   submit_bio(rw, bio);
+}
+
 static void __submit_merged_bio(struct f2fs_bio_info *io)
 {
struct f2fs_io_info *fio = >fio;
@@ -110,7 +117,7 @@ static void __submit_merged_bio(struct f2fs_bio_info *io)
else
trace_f2fs_submit_write_bio(io->sbi->sb, fio, io->bio);
 
-   submit_bio(fio->rw, io->bio);
+   __submit_bio(io->sbi, fio->rw, io->bio);
io->bio = NULL;
 }
 
@@ -228,7 +235,7 @@ int f2fs_submit_page_bio(struct f2fs_io_info *fio)
return -EFAULT;
}
 
-   submit_bio(fio->rw, bio);
+   __submit_bio(fio->sbi, fio->rw, bio);
return 0;
 }
 
@@ -248,9 +255,6 @@ void f2fs_submit_page_mbio(struct f2fs_io_info *fio)
 
down_write(>io_rwsem);
 
-   if (!is_read)
-   inc_page_count(sbi, F2FS_WRITEBACK);
-
if (io->bio && (io->last_block_in_bio != fio->new_blkaddr - 1 ||
io->fio.rw != fio->rw))
__submit_merged_bio(io);
@@ -1047,7 +1051,7 @@ got_it:
 */
if (bio && (last_block_in_bio != block_nr - 1)) {
 submit_and_realloc:
-   submit_bio(READ, bio);
+   __submit_bio(F2FS_I_SB(inode), READ, bio);
bio = NULL;
}
if (bio == NULL) {
@@ -1090,7 +1094,7 @@ set_error_page:
goto next_page;
 confused:
if (bio) {
-   submit_bio(READ, bio);
+   __submit_bio(F2FS_I_SB(inode), READ, bio);
bio = NULL;
}
unlock_page(page);
@@ -1100,7 +1104,7 @@ next_page:
}
BUG_ON(pages && !list_empty(pages));
if (bio)
-   submit_bio(READ, bio);
+   __submit_bio(F2FS_I_SB(inode), READ, bio);
return 0;
 }
 
diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
index 37615b2..a188973 100644
--- a/fs/f2fs/debug.c
+++ b/fs/f2fs/debug.c
@@ -48,7 +48,7 @@ static void update_general_status(struct f2fs_sb_info *sbi)
si->ndirty_dirs = sbi->ndirty_inode[DIR_INODE];
si->ndirty_files = sbi->ndirty_inode[FILE_INODE];
si->inmem_pages = get_pages(sbi, F2FS_INMEM_PAGES);
-   si->wb_pages = get_pages(sbi, F2FS_WRITEBACK);
+   si->wb_bios = atomic_read(>nr_wb_bios);
si->total_count = (int)sbi->user_block_count / sbi->blocks_per_seg;
si->rsvd_segs = reserved_segments(sbi);
si->overp_segs = overprovision_segments(sbi);
@@ -299,8 +299,8 @@ static int stat_show(struct seq_file *s, void *v)
seq_printf(s, "  - Inner Struct Count: tree: %d(%d), node: 
%d\n",
si->ext_tree, si->zombie_tree, si->ext_node);
seq_puts(s, "\nBalancing F2FS Async:\n");
-   seq_printf(s, "  - inmem: %4d, wb: %4d\n",
-  si->inmem_pages, si->wb_pages);
+   seq_printf(s, "  - inmem: %4d, wb_bios: %4d\n",
+  si->inmem_pages, si->wb_bios);
seq_printf(s, "  - nodes: %4d in %4d\n",
   si->ndirty_node, si->node_pages);
seq_printf(s, "  - dents: %4d in dirs:%4d\n",
diff --git 

[PATCH 1/1] rtlwifi: rtl8192ee: simplify coding

2016-05-17 Thread Heinrich Schuchardt
Simplify _rtl92ee_phy_path_adda_on.

Signed-off-by: Heinrich Schuchardt 
---
 drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c
index 018340a..c2bf8d1 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c
@@ -2414,19 +2414,10 @@ static void _rtl92ee_phy_reload_mac_registers(struct 
ieee80211_hw *hw,
 static void _rtl92ee_phy_path_adda_on(struct ieee80211_hw *hw, u32 *addareg,
  bool is_patha_on, bool is2t)
 {
-   u32 pathon;
u32 i;
 
-   pathon = is_patha_on ? 0x0fc01616 : 0x0fc01616;
-   if (!is2t) {
-   pathon = 0x0fc01616;
-   rtl_set_bbreg(hw, addareg[0], MASKDWORD, 0x0fc01616);
-   } else {
-   rtl_set_bbreg(hw, addareg[0], MASKDWORD, pathon);
-   }
-
-   for (i = 1; i < IQK_ADDA_REG_NUM; i++)
-   rtl_set_bbreg(hw, addareg[i], MASKDWORD, pathon);
+   for (i = 0; i < IQK_ADDA_REG_NUM; i++)
+   rtl_set_bbreg(hw, addareg[i], MASKDWORD, 0x0fc01616);
 }
 
 static void _rtl92ee_phy_mac_setting_calibration(struct ieee80211_hw *hw,
-- 
2.1.4



Re: QRTR merge conflict resolution

2016-05-17 Thread Stephen Rothwell
Hi David,

On Tue, 17 May 2016 14:11:54 -0400 (EDT) David Miller  
wrote:
>
> From: Bjorn Andersson 
> Date: Fri, 13 May 2016 15:19:09 -0700
> 
> > I have prepared the merge of net-next and the conflicting tag from the
> > Qualcomm SOC, please include this in your pull towards Linus to avoid
> > the merge conflict.  
> 
> Pulled, thanks.

Except in the merge resolution, the 2 new functions added to
include/linux/soc/qcom/smd.h (qcom_smd_get_drvdata and
qcom_smd_set_drvdata) were not marked "static inline" :-(

-- 
Cheers,
Stephen Rothwell


Re: [PATCH] tty: vt: Fix soft lockup in fbcon cursor blink timer.

2016-05-17 Thread Ming Lei
On Wed, May 18, 2016 at 4:49 AM, Pavel Machek  wrote:
> On Tue 2016-05-17 11:41:04, David Daney wrote:
>> From: David Daney 
>>
>> We are getting somewhat random soft lockups with this signature:
>>
>> [   86.992215] [] el1_irq+0xa0/0x10c
>> [   86.997082] [] cursor_timer_handler+0x30/0x54
>> [   87.002991] [] call_timer_fn+0x54/0x1a8
>> [   87.008378] [] run_timer_softirq+0x1c4/0x2bc
>> [   87.014200] [] __do_softirq+0x114/0x344
>> [   87.019590] [] irq_exit+0x74/0x98
>> [   87.024458] [] __handle_domain_irq+0x98/0xfc
>> [   87.030278] [] gic_handle_irq+0x94/0x190
>>
>> This is caused by the vt visual_init() function calling into
>> fbcon_init() with a vc_cur_blink_ms value of zero.  This is a
>> transient condition, as it is later set to a non-zero value.  But, if
>> the timer happens to expire while the blink rate is zero, it goes into
>> an endless loop, and we get soft lockup.
>>
>> The fix is to initialize vc_cur_blink_ms before calling the con_init()
>> function.
>>
>> Signed-off-by: David Daney 
>> Cc: sta...@vger.kernel.org
>
> Acked-by: Pavel Machek 

Tested-by: Ming Lei 

Thanks David and Pavel for making it work!

>
> (And it is amazing how many problems configurable blink speed caused).
>
> Thanks!
> Pavel
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


[PATCH] f2fs: make exit_f2fs_fs more clear

2016-05-17 Thread Tiezhu Yang
init_f2fs_fs does:
1) f2fs_build_trace_ios
2) init_inodecache
3) create_node_manager_caches
4) create_segment_manager_caches
5) create_checkpoint_caches
6) create_extent_cache
7) kset_create_and_add
8) kobject_init_and_add
9) register_shrinker
10) register_filesystem
11) f2fs_create_root_stats
12) proc_mkdir

exit_f2fs_fs should do cleanup in the reverse order
to make the code more clear.

Signed-off-by: Tiezhu Yang 
---
 fs/f2fs/super.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index bbfeb6a..741fba1 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -1928,17 +1928,17 @@ static void __exit exit_f2fs_fs(void)
 {
remove_proc_entry("fs/f2fs", NULL);
f2fs_destroy_root_stats();
-   unregister_shrinker(_shrinker_info);
unregister_filesystem(_fs_type);
+   unregister_shrinker(_shrinker_info);
+#ifdef CONFIG_F2FS_FAULT_INJECTION
+   kobject_put(_fault_inject);
+#endif
+   kset_unregister(f2fs_kset);
destroy_extent_cache();
destroy_checkpoint_caches();
destroy_segment_manager_caches();
destroy_node_manager_caches();
destroy_inodecache();
-#ifdef CONFIG_F2FS_FAULT_INJECTION
-   kobject_put(_fault_inject);
-#endif
-   kset_unregister(f2fs_kset);
f2fs_destroy_trace_ios();
 }
 
-- 
1.8.3.1

RE: [PATCH 5/5] drm/amd/amdgpu : Remove unused variable

2016-05-17 Thread Zhang, Jerry
Reviewed-by: Junwei Zhang 

Regards,
Jerry (Junwei Zhang)

SRDC SW Development
AMD Shanghai
_

> -Original Message-
> From: Muhammad Falak R Wani [mailto:falakre...@gmail.com]
> Sent: Tuesday, May 17, 2016 5:43 PM
> To: David Airlie
> Cc: Deucher, Alexander; Koenig, Christian; Zhou, Jammy; Dave Airlie; StDenis,
> Tom; Yang, Young; Zhang, Jerry; dri-de...@lists.freedesktop.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH 5/5] drm/amd/amdgpu : Remove unused variable
> 
> Remove unused variable 'ret', and directly return 0.
> 
> Signed-off-by: Muhammad Falak R Wani 
> ---
>  drivers/gpu/drm/amd/amdgpu/tonga_ih.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/tonga_ih.c
> b/drivers/gpu/drm/amd/amdgpu/tonga_ih.c
> index 55cdab8..cba951a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/tonga_ih.c
> +++ b/drivers/gpu/drm/amd/amdgpu/tonga_ih.c
> @@ -99,7 +99,6 @@ static void tonga_ih_disable_interrupts(struct
> amdgpu_device *adev)
>   */
>  static int tonga_ih_irq_init(struct amdgpu_device *adev)  {
> - int ret = 0;
>   int rb_bufsz;
>   u32 interrupt_cntl, ih_rb_cntl, ih_doorbell_rtpr;
>   u64 wptr_off;
> @@ -165,7 +164,7 @@ static int tonga_ih_irq_init(struct amdgpu_device *adev)
>   /* enable interrupts */
>   tonga_ih_enable_interrupts(adev);
> 
> - return ret;
> + return 0;
>  }
> 
>  /**
> --
> 1.9.1



[PATCH] wifi: ath6kl: simplify logical condition

2016-05-17 Thread Heinrich Schuchardt
x <= 7 implies x < 8.

Signed-off-by: Heinrich Schuchardt 
---
 drivers/net/wireless/ath/ath6kl/wmi.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath6kl/wmi.c 
b/drivers/net/wireless/ath/ath6kl/wmi.c
index 631c3a0..b8cf04d 100644
--- a/drivers/net/wireless/ath/ath6kl/wmi.c
+++ b/drivers/net/wireless/ath/ath6kl/wmi.c
@@ -2544,8 +2544,7 @@ int ath6kl_wmi_create_pstream_cmd(struct wmi *wmi, u8 
if_idx,
s32 nominal_phy = 0;
int ret;
 
-   if (!((params->user_pri < 8) &&
- (params->user_pri <= 0x7) &&
+   if (!((params->user_pri <= 0x7) &&
  (up_to_ac[params->user_pri & 0x7] == params->traffic_class) &&
  (params->traffic_direc == UPLINK_TRAFFIC ||
   params->traffic_direc == DNLINK_TRAFFIC ||
-- 
2.1.4



[PATCH v7 1/3] ASoC: cygnus: Add DT bindings for Broadcom Cygnus audio

2016-05-17 Thread Simran Rai
From: Simran Rai 

Add bindings for audio driver in Broadcom Cygnus.

Signed-off-by: Lori Hikichi 
Signed-off-by: Simran Rai 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
Acked-by: Rob Herring 
---
 .../bindings/sound/brcm,cygnus-audio.txt   | 67 ++
 1 file changed, 67 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/sound/brcm,cygnus-audio.txt

diff --git a/Documentation/devicetree/bindings/sound/brcm,cygnus-audio.txt 
b/Documentation/devicetree/bindings/sound/brcm,cygnus-audio.txt
new file mode 100644
index 000..b139e66
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/brcm,cygnus-audio.txt
@@ -0,0 +1,67 @@
+BROADCOM Cygnus Audio I2S/TDM/SPDIF controller
+
+Required properties:
+   - compatible : "brcm,cygnus-audio"
+   - #address-cells: 32bit valued, 1 cell.
+   - #size-cells:  32bit valued, 0 cell.
+   - reg : Should contain audio registers location and length
+   - reg-names: names of the registers listed in "reg" property
+   Valid names are "aud" and "i2s_in". "aud" contains a
+   set of DMA, I2S_OUT and SPDIF registers. "i2s_in" contains
+   a set of I2S_IN registers.
+   - clocks: PLL and leaf clocks used by audio ports
+   - assigned-clocks: PLL and leaf clocks
+   - assigned-clock-parents: parent clocks of the assigned clocks
+   (usually the PLL)
+   - assigned-clock-rates: List of clock frequencies of the
+   assigned clocks
+   - clock-names: names of 3 leaf clocks used by audio ports
+   Valid names are "ch0_audio", "ch1_audio", "ch2_audio"
+   - interrupts: audio DMA interrupt number
+
+SSP Subnode properties:
+- reg: The index of ssp port interface to use
+   Valid value are 0, 1, 2, or 3 (for spdif)
+
+Example:
+   cygnus_audio: audio@180ae000 {
+   compatible = "brcm,cygnus-audio";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x180ae000 0xafd>, <0x180aec00 0x1f8>;
+   reg-names = "aud", "i2s_in";
+   clocks = < BCM_CYGNUS_AUDIOPLL_CH0>,
+   < BCM_CYGNUS_AUDIOPLL_CH1>,
+   < BCM_CYGNUS_AUDIOPLL_CH2>;
+   assigned-clocks = < BCM_CYGNUS_AUDIOPLL>,
+   < 
BCM_CYGNUS_AUDIOPLL_CH0>,
+   < 
BCM_CYGNUS_AUDIOPLL_CH1>,
+   < 
BCM_CYGNUS_AUDIOPLL_CH2>;
+   assigned-clock-parents = < BCM_CYGNUS_AUDIOPLL>;
+   assigned-clock-rates = <1769470191>,
+   <0>,
+   <0>,
+   <0>;
+   clock-names = "ch0_audio", "ch1_audio", "ch2_audio";
+   interrupts = ;
+
+   ssp0: ssp_port@0 {
+   reg = <0>;
+   status = "okay";
+   };
+
+   ssp1: ssp_port@1 {
+   reg = <1>;
+   status = "disabled";
+   };
+
+   ssp2: ssp_port@2 {
+   reg = <2>;
+   status = "disabled";
+   };
+
+   spdif: spdif_port@3 {
+   reg = <3>;
+   status = "disabled";
+   };
+   };
-- 
1.9.1



[PATCH v7 0/3] ASoC: cygnus: Add audio support for Broadcom Cygnus SoC

2016-05-17 Thread Simran Rai
Hi,

This patchset contains audio support for Broadcom's Cygnus SoC.
It contains DT bindings and core audio driver. The audio driver supports
both capture and playback of Audio PCM samples over I2S/TDM interface and
provides playback support over SPDIF interface.

This patchset is derived from a previously submitted patchset:
http://lkml.iu.edu/hypermail/linux/kernel/1503.3/05434.html

This patchset has been tested on Cygnus wireless audio bcm958305K board.
It is based on v4.6-rc1 and is available from github:

repo: https://github.com/Broadcom/cygnus-linux/tree/cygnus-sound-v7

Changes from v6:
- DT bindings acknowledged by Rob Herring
Changes from v5:
- Fix code style, e.g. change "if" statements to "switch" statements
- Fix SPDIF output enable register field
- Set BUFFER_PAIR_ENABLE for both mono, stereo and TDM modes
- Reflect PCM bit formats for SPDIF, SSP and TDM as supported by
hardware
Changes from v4:
- Fix power suspend function and add power resume function
- Move clock initialization code from audio driver to clock framework
Changes from v3:
- Fix the subject lines to match the style for the subsystem
Changes from v2:
- Split patchset 2/2 from v2 into patchsets 2/3 and 3/3.
- Remove SND_SOC_CYGNUS_DIAG. Diagnostics can be performed using
standard kernel trace infrastructure.
- Fix interrupt handler. Acknowledge only those interrupts that are
handledby ISR.
- Modify configure_vco() and the pll_macro_entry() struct to make it
better readable. The functionality did not change.
- Remove casts on macros
- Remove surround sound channel grouping from the driver.
Changes from v1:
- Address code review comments. Fix print format of type size_t and
pointer.

Simran Rai (3):
  ASoC: cygnus: Add DT bindings for Broadcom Cygnus audio
  ASoC: cygnus: Add Cygnus audio DAI driver
  ASoC: cygnus: Add Cygnus audio DMA driver

 .../bindings/sound/brcm,cygnus-audio.txt   |   67 +
 sound/soc/bcm/Kconfig  |9 +
 sound/soc/bcm/Makefile |5 +
 sound/soc/bcm/cygnus-pcm.c |  861 +++
 sound/soc/bcm/cygnus-ssp.c | 1529 
 sound/soc/bcm/cygnus-ssp.h |  139 ++
 6 files changed, 2610 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/sound/brcm,cygnus-audio.txt
 create mode 100644 sound/soc/bcm/cygnus-pcm.c
 create mode 100644 sound/soc/bcm/cygnus-ssp.c
 create mode 100644 sound/soc/bcm/cygnus-ssp.h

-- 
1.9.1



[PATCH v7 2/3] ASoC: cygnus: Add Cygnus audio DAI driver

2016-05-17 Thread Simran Rai
This patch adds Cygnus audio DAI driver. It supports I2S, TDM
and SPDIF modes and uses three clocks derived from PLL.

This patchset has been tested on Cygnus wireless audio
bcm958305K board.

Signed-off-by: Lori Hikichi 
Signed-off-by: Simran Rai 
Reviewed-by: Ray Jui 
Reviewed-by: Arun Parameswaran 
Reviewed-by: Scott Branden 
---
 sound/soc/bcm/cygnus-ssp.c | 1529 
 sound/soc/bcm/cygnus-ssp.h |  139 
 2 files changed, 1668 insertions(+)
 create mode 100644 sound/soc/bcm/cygnus-ssp.c
 create mode 100644 sound/soc/bcm/cygnus-ssp.h

diff --git a/sound/soc/bcm/cygnus-ssp.c b/sound/soc/bcm/cygnus-ssp.c
new file mode 100644
index 000..e710bb0
--- /dev/null
+++ b/sound/soc/bcm/cygnus-ssp.c
@@ -0,0 +1,1529 @@
+/*
+ * Copyright (C) 2014-2015 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "cygnus-ssp.h"
+
+#define DEFAULT_VCO1354750204
+
+#define CYGNUS_TDM_RATE \
+   (SNDRV_PCM_RATE_8000 | SNDRV_PCM_RATE_16000 | \
+   SNDRV_PCM_RATE_11025 | SNDRV_PCM_RATE_22050 | \
+   SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_44100 | \
+   SNDRV_PCM_RATE_48000)
+
+#define CAPTURE_FCI_ID_BASE 0x180
+#define CYGNUS_SSP_TRISTATE_MASK 0x001fff
+#define CYGNUS_PLLCLKSEL_MASK 0xf
+
+/* Used with stream_on field to indicate which streams are active */
+#define  PLAYBACK_STREAM_MASK   BIT(0)
+#define  CAPTURE_STREAM_MASKBIT(1)
+
+#define I2S_STREAM_CFG_MASK  0xff003ff
+#define I2S_CAP_STREAM_CFG_MASK  0xf0
+#define SPDIF_STREAM_CFG_MASK0x3ff
+#define CH_GRP_STEREO0x1
+
+/* Begin register offset defines */
+#define AUD_MISC_SEROUT_OE_REG_BASE  0x01c
+#define AUD_MISC_SEROUT_SPDIF_OE  12
+#define AUD_MISC_SEROUT_MCLK_OE   3
+#define AUD_MISC_SEROUT_LRCK_OE   2
+#define AUD_MISC_SEROUT_SCLK_OE   1
+#define AUD_MISC_SEROUT_SDAT_OE   0
+
+/* AUD_FMM_BF_CTRL_xxx regs */
+#define BF_DST_CFG0_OFFSET  0x100
+#define BF_DST_CFG1_OFFSET  0x104
+#define BF_DST_CFG2_OFFSET  0x108
+
+#define BF_DST_CTRL0_OFFSET 0x130
+#define BF_DST_CTRL1_OFFSET 0x134
+#define BF_DST_CTRL2_OFFSET 0x138
+
+#define BF_SRC_CFG0_OFFSET  0x148
+#define BF_SRC_CFG1_OFFSET  0x14c
+#define BF_SRC_CFG2_OFFSET  0x150
+#define BF_SRC_CFG3_OFFSET  0x154
+
+#define BF_SRC_CTRL0_OFFSET 0x1c0
+#define BF_SRC_CTRL1_OFFSET 0x1c4
+#define BF_SRC_CTRL2_OFFSET 0x1c8
+#define BF_SRC_CTRL3_OFFSET 0x1cc
+
+#define BF_SRC_GRP0_OFFSET  0x1fc
+#define BF_SRC_GRP1_OFFSET  0x200
+#define BF_SRC_GRP2_OFFSET  0x204
+#define BF_SRC_GRP3_OFFSET  0x208
+
+#define BF_SRC_GRP_EN_OFFSET0x320
+#define BF_SRC_GRP_FLOWON_OFFSET0x324
+#define BF_SRC_GRP_SYNC_DIS_OFFSET  0x328
+
+/* AUD_FMM_IOP_OUT_I2S_xxx regs */
+#define OUT_I2S_0_STREAM_CFG_OFFSET 0xa00
+#define OUT_I2S_0_CFG_OFFSET0xa04
+#define OUT_I2S_0_MCLK_CFG_OFFSET   0xa0c
+
+#define OUT_I2S_1_STREAM_CFG_OFFSET 0xa40
+#define OUT_I2S_1_CFG_OFFSET0xa44
+#define OUT_I2S_1_MCLK_CFG_OFFSET   0xa4c
+
+#define OUT_I2S_2_STREAM_CFG_OFFSET 0xa80
+#define OUT_I2S_2_CFG_OFFSET0xa84
+#define OUT_I2S_2_MCLK_CFG_OFFSET   0xa8c
+
+/* AUD_FMM_IOP_OUT_SPDIF_xxx regs */
+#define SPDIF_STREAM_CFG_OFFSET  0xac0
+#define SPDIF_CTRL_OFFSET0xac4
+#define SPDIF_FORMAT_CFG_OFFSET  0xad8
+#define SPDIF_MCLK_CFG_OFFSET0xadc
+
+/* AUD_FMM_IOP_PLL_0_xxx regs */
+#define IOP_PLL_0_MACRO_OFFSET0xb00
+#define IOP_PLL_0_MDIV_Ch0_OFFSET 0xb14
+#define IOP_PLL_0_MDIV_Ch1_OFFSET 0xb18
+#define IOP_PLL_0_MDIV_Ch2_OFFSET 0xb1c
+
+#define IOP_PLL_0_ACTIVE_MDIV_Ch0_OFFSET 0xb30
+#define IOP_PLL_0_ACTIVE_MDIV_Ch1_OFFSET 0xb34
+#define IOP_PLL_0_ACTIVE_MDIV_Ch2_OFFSET 0xb38
+
+/* AUD_FMM_IOP_xxx regs */
+#define IOP_PLL_0_CONTROL_OFFSET 0xb04
+#define IOP_PLL_0_USER_NDIV_OFFSET   0xb08
+#define IOP_PLL_0_ACTIVE_NDIV_OFFSET 0xb20
+#define IOP_PLL_0_RESET_OFFSET   0xb5c
+
+/* AUD_FMM_IOP_IN_I2S_xxx regs */
+#define IN_I2S_0_STREAM_CFG_OFFSET 0x00
+#define IN_I2S_0_CFG_OFFSET0x04
+#define IN_I2S_1_STREAM_CFG_OFFSET 0x40
+#define IN_I2S_1_CFG_OFFSET0x44
+#define IN_I2S_2_STREAM_CFG_OFFSET 0x80
+#define IN_I2S_2_CFG_OFFSET0x84
+
+/* AUD_FMM_IOP_MISC_xxx regs */
+#define IOP_SW_INIT_LOGIC  0x1c0
+
+/* End register offset defines */
+
+
+/* AUD_FMM_IOP_OUT_I2S_x_MCLK_CFG_0_REG */
+#define 

[PATCH v7 3/3] ASoC: cygnus: Add Cygnus audio DMA driver

2016-05-17 Thread Simran Rai
From: Simran Rai 

This patch adds Cygnus audio DMA driver. It supports playback
and capture modes and uses ringbuffers for data transfer.

Signed-off-by: Lori Hikichi 
Signed-off-by: Simran Rai 
Reviewed-by: Ray Jui 
Reviewed-by: Arun Parameswaran 
Reviewed-by: Scott Branden 
---
 sound/soc/bcm/Kconfig  |   9 +
 sound/soc/bcm/Makefile |   5 +
 sound/soc/bcm/cygnus-pcm.c | 861 +
 3 files changed, 875 insertions(+)
 create mode 100644 sound/soc/bcm/cygnus-pcm.c

diff --git a/sound/soc/bcm/Kconfig b/sound/soc/bcm/Kconfig
index 6a834e1..d528aac 100644
--- a/sound/soc/bcm/Kconfig
+++ b/sound/soc/bcm/Kconfig
@@ -7,3 +7,12 @@ config SND_BCM2835_SOC_I2S
  Say Y or M if you want to add support for codecs attached to
  the BCM2835 I2S interface. You will also need
  to select the audio interfaces to support below.
+
+config SND_SOC_CYGNUS
+   tristate "SoC platform audio for Broadcom Cygnus chips"
+   depends on ARCH_BCM_CYGNUS || COMPILE_TEST
+   help
+ Say Y if you want to add support for ASoC audio on Broadcom
+ Cygnus chips (bcm958300, bcm958305, bcm911360)
+
+ If you don't know what to do here, say N.
\ No newline at end of file
diff --git a/sound/soc/bcm/Makefile b/sound/soc/bcm/Makefile
index bc816b7..fc739d0 100644
--- a/sound/soc/bcm/Makefile
+++ b/sound/soc/bcm/Makefile
@@ -3,3 +3,8 @@ snd-soc-bcm2835-i2s-objs := bcm2835-i2s.o
 
 obj-$(CONFIG_SND_BCM2835_SOC_I2S) += snd-soc-bcm2835-i2s.o
 
+# CYGNUS Platform Support
+snd-soc-cygnus-objs := cygnus-pcm.o cygnus-ssp.o
+
+obj-$(CONFIG_SND_SOC_CYGNUS) += snd-soc-cygnus.o
+
diff --git a/sound/soc/bcm/cygnus-pcm.c b/sound/soc/bcm/cygnus-pcm.c
new file mode 100644
index 000..d616e096
--- /dev/null
+++ b/sound/soc/bcm/cygnus-pcm.c
@@ -0,0 +1,861 @@
+/*
+ * Copyright (C) 2014-2015 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "cygnus-ssp.h"
+
+/* Register offset needed for ASoC PCM module */
+
+#define INTH_R5F_STATUS_OFFSET 0x040
+#define INTH_R5F_CLEAR_OFFSET  0x048
+#define INTH_R5F_MASK_SET_OFFSET   0x050
+#define INTH_R5F_MASK_CLEAR_OFFSET 0x054
+
+#define BF_REARM_FREE_MARK_OFFSET 0x344
+#define BF_REARM_FULL_MARK_OFFSET 0x348
+
+/* Ring Buffer Ctrl Regs --- Start */
+/* AUD_FMM_BF_CTRL_SOURCECH_RINGBUF_X_RDADDR_REG_BASE */
+#define SRC_RBUF_0_RDADDR_OFFSET 0x500
+#define SRC_RBUF_1_RDADDR_OFFSET 0x518
+#define SRC_RBUF_2_RDADDR_OFFSET 0x530
+#define SRC_RBUF_3_RDADDR_OFFSET 0x548
+#define SRC_RBUF_4_RDADDR_OFFSET 0x560
+#define SRC_RBUF_5_RDADDR_OFFSET 0x578
+#define SRC_RBUF_6_RDADDR_OFFSET 0x590
+
+/* AUD_FMM_BF_CTRL_SOURCECH_RINGBUF_X_WRADDR_REG_BASE */
+#define SRC_RBUF_0_WRADDR_OFFSET 0x504
+#define SRC_RBUF_1_WRADDR_OFFSET 0x51c
+#define SRC_RBUF_2_WRADDR_OFFSET 0x534
+#define SRC_RBUF_3_WRADDR_OFFSET 0x54c
+#define SRC_RBUF_4_WRADDR_OFFSET 0x564
+#define SRC_RBUF_5_WRADDR_OFFSET 0x57c
+#define SRC_RBUF_6_WRADDR_OFFSET 0x594
+
+/* AUD_FMM_BF_CTRL_SOURCECH_RINGBUF_X_BASEADDR_REG_BASE */
+#define SRC_RBUF_0_BASEADDR_OFFSET 0x508
+#define SRC_RBUF_1_BASEADDR_OFFSET 0x520
+#define SRC_RBUF_2_BASEADDR_OFFSET 0x538
+#define SRC_RBUF_3_BASEADDR_OFFSET 0x550
+#define SRC_RBUF_4_BASEADDR_OFFSET 0x568
+#define SRC_RBUF_5_BASEADDR_OFFSET 0x580
+#define SRC_RBUF_6_BASEADDR_OFFSET 0x598
+
+/* AUD_FMM_BF_CTRL_SOURCECH_RINGBUF_X_ENDADDR_REG_BASE */
+#define SRC_RBUF_0_ENDADDR_OFFSET 0x50c
+#define SRC_RBUF_1_ENDADDR_OFFSET 0x524
+#define SRC_RBUF_2_ENDADDR_OFFSET 0x53c
+#define SRC_RBUF_3_ENDADDR_OFFSET 0x554
+#define SRC_RBUF_4_ENDADDR_OFFSET 0x56c
+#define SRC_RBUF_5_ENDADDR_OFFSET 0x584
+#define SRC_RBUF_6_ENDADDR_OFFSET 0x59c
+
+/* AUD_FMM_BF_CTRL_SOURCECH_RINGBUF_X_FREE_MARK_REG_BASE */
+#define SRC_RBUF_0_FREE_MARK_OFFSET 0x510
+#define SRC_RBUF_1_FREE_MARK_OFFSET 0x528
+#define SRC_RBUF_2_FREE_MARK_OFFSET 0x540
+#define SRC_RBUF_3_FREE_MARK_OFFSET 0x558
+#define SRC_RBUF_4_FREE_MARK_OFFSET 0x570
+#define SRC_RBUF_5_FREE_MARK_OFFSET 0x588
+#define SRC_RBUF_6_FREE_MARK_OFFSET 0x5a0
+
+/* AUD_FMM_BF_CTRL_DESTCH_RINGBUF_X_RDADDR_REG_BASE */
+#define DST_RBUF_0_RDADDR_OFFSET 0x5c0
+#define DST_RBUF_1_RDADDR_OFFSET 0x5d8
+#define DST_RBUF_2_RDADDR_OFFSET 0x5f0
+#define DST_RBUF_3_RDADDR_OFFSET 0x608
+#define DST_RBUF_4_RDADDR_OFFSET 0x620
+#define 

[PATCH 1/1] net: pegasus: remove dead coding

2016-05-17 Thread Heinrich Schuchardt
(!count || count < 4) is always true.
So let's remove the coding which is dead at least since 2005.

Signed-off-by: Heinrich Schuchardt 
---
 drivers/net/usb/pegasus.c | 53 ---
 1 file changed, 53 deletions(-)

diff --git a/drivers/net/usb/pegasus.c b/drivers/net/usb/pegasus.c
index 36cd7f0..1903d2e 100644
--- a/drivers/net/usb/pegasus.c
+++ b/drivers/net/usb/pegasus.c
@@ -470,61 +470,8 @@ static void read_bulk_callback(struct urb *urb)
return;
default:
netif_dbg(pegasus, rx_err, net, "RX status %d\n", status);
-   goto goon;
}
 
-   if (!count || count < 4)
-   goto goon;
-
-   rx_status = buf[count - 2];
-   if (rx_status & 0x1e) {
-   netif_dbg(pegasus, rx_err, net,
- "RX packet error %x\n", rx_status);
-   pegasus->stats.rx_errors++;
-   if (rx_status & 0x06)   /* long or runt */
-   pegasus->stats.rx_length_errors++;
-   if (rx_status & 0x08)
-   pegasus->stats.rx_crc_errors++;
-   if (rx_status & 0x10)   /* extra bits   */
-   pegasus->stats.rx_frame_errors++;
-   goto goon;
-   }
-   if (pegasus->chip == 0x8513) {
-   pkt_len = le32_to_cpu(*(__le32 *)urb->transfer_buffer);
-   pkt_len &= 0x0fff;
-   pegasus->rx_skb->data += 2;
-   } else {
-   pkt_len = buf[count - 3] << 8;
-   pkt_len += buf[count - 4];
-   pkt_len &= 0xfff;
-   pkt_len -= 4;
-   }
-
-   /*
-* If the packet is unreasonably long, quietly drop it rather than
-* kernel panicing by calling skb_put.
-*/
-   if (pkt_len > PEGASUS_MTU)
-   goto goon;
-
-   /*
-* at this point we are sure pegasus->rx_skb != NULL
-* so we go ahead and pass up the packet.
-*/
-   skb_put(pegasus->rx_skb, pkt_len);
-   pegasus->rx_skb->protocol = eth_type_trans(pegasus->rx_skb, net);
-   netif_rx(pegasus->rx_skb);
-   pegasus->stats.rx_packets++;
-   pegasus->stats.rx_bytes += pkt_len;
-
-   if (pegasus->flags & PEGASUS_UNPLUG)
-   return;
-
-   pegasus->rx_skb = __netdev_alloc_skb_ip_align(pegasus->net, PEGASUS_MTU,
- GFP_ATOMIC);
-
-   if (pegasus->rx_skb == NULL)
-   goto tl_sched;
 goon:
usb_fill_bulk_urb(pegasus->rx_urb, pegasus->usb,
  usb_rcvbulkpipe(pegasus->usb, 1),
-- 
2.1.4



Re: [PATCHv2] rcu: tree: correctly handle sparse possible CPUs

2016-05-17 Thread Paul E. McKenney
On Tue, May 17, 2016 at 12:01:06PM -0700, Paul E. McKenney wrote:
> On Tue, May 17, 2016 at 11:22:10AM +0100, Mark Rutland wrote:
> > In many cases in the RCU tree code, we iterate over the set of CPUs for
> > a leaf node described by rcu_node::grplo and rcu_node::grphi, checking
> > per-cpu data for each CPU in this range. However, if the set of possible
> > CPUs is sparse, some CPUs described in this range are not possible, and
> > thus no per-cpu region will have been allocated (or initialised) for
> > them by the generic percpu code.
> > 
> > Erroneous accesses to a per-cpu area for these !possible CPUs may fault
> > or may hit other data depending on the addressed generated when the
> > erroneous per cpu offset is applied. In practice, both cases have been
> > observed on arm64 hardware (the former being silent, but detectable with
> > additional patches).
> > 
> > To avoid issues resulting from this, we must iterate over the set of
> > *possible* cpus for a given leaf node. This patch adds new helpers to
> > enable this (also unifying and simplifying some related bitmask
> > manipulation logic), and moves the RCU tree code over to them.
> > 
> > Without this patch, running reboot at a shell can result in an oops
> > like:
> 
> Very good, this one applies cleanly and I have queued it for review
> and testing.
> 
> One question below, though.

And some build errors:

In file included from 
/home/paulmck/public_git/linux-rcu/kernel/rcu/tree.c:4209:0:
/home/paulmck/public_git/linux-rcu/kernel/rcu/tree_plugin.h: In function 
‘rcu_boost_kthread_setaffinity’:
/home/paulmck/public_git/linux-rcu/kernel/rcu/tree_plugin.h:1168:2: error: 
implicit declaration of function ‘for_each_leaf_node_cpu_bit’ 
[-Werror=implicit-function-declaration]
  for_each_leaf_node_cpu_bit(rnp, cpu, bit)
  ^
/home/paulmck/public_git/linux-rcu/kernel/rcu/tree_plugin.h:1169:3: error: 
expected ‘;’ before ‘if’
   if ((mask & bit) && cpu != outgoingcpu)
   ^
/home/paulmck/public_git/linux-rcu/kernel/rcu/tree_plugin.h:1159:16: warning: 
unused variable ‘mask’ [-Wunused-variable]
  unsigned long mask = rcu_rnp_online_cpus(rnp);
^

Please see below for the .config.

I have dropped the patch from my tree, looking forward to getting an
update that fixes the build errors.

Thanx, Paul



#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.6.0-rc2 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx 
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEBUG_RODATA=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y

Re: [PATCH 0/5] add bus driver for Unisys s-Par paravirtualized devices to arch/x86

2016-05-17 Thread Greg KH
On Tue, May 17, 2016 at 07:49:53PM -0400, Jes Sorensen wrote:
> Greg KH  writes:
> > On Tue, May 17, 2016 at 10:01:55AM -0400, Jes Sorensen wrote:
> >> Greg KH  writes:
> >> > On Tue, May 17, 2016 at 03:27:56AM -0400, David Kershner wrote:
> >> >> This patchset moves the visorbus driver
> >> >> (fromdrivers/staging/unisys/visorbus)
> >> >> and its dependent headers files (from drivers/staging/unisys/include)
> >> >> out of staging into the main kernel tree.
> >> >> 
> >> >> The visorbus driver is a bus driver for various paravirtualized devices
> >> >> presented within a Unisys s-Par guest environment.  Drivers for these
> >> >> devices are also currently present under drivers/staging/unisys/, which 
> >> >> we
> >> >> intend to also move out of staging immediately after visorbus.  All of
> >> >> these other drivers are dependent upon visorbus and the include 
> >> >> directory,
> >> >> which is why we would like to move these first.
> >> >> 
> >> >> Our initial consultations with various members of the community have 
> >> >> led us
> >> >> to the conclusion that the most appropriate locations for these is:
> >> >> arch/x86/visorbus/   (driver)
> >> >> include/linux/visorbus/  (header files)
> >> >> 
> >> >> The rationale is that visorbus is dependent on x86-64 architecture.
> >> >
> >> > What makes it dependent on x86?  What prevents it from running on some
> >> > other architecture (not the fact that no one has made such hardware,
> >> > just the code reasons please.)
> >> 
> >> It's dependent on system firmware which is only available on the S-Par
> >> platform which is x86_64 only. The closest similarity is probably what
> >> you find on the PPC and Sparc platforms.
> >
> > Ok, but still no need to put it under arch/ anything, it should go in
> > drivers/ like all other drivers and busses are, no matter what the arch
> > it happens to run on is.
> 
> I don't think thats obvious. arch/x86/kvm is an example of this, Sparc
> and PPC also have their stuff under arch/.

For some things, yes, but let's not make the same mistakes as others :)

Look at drivers/hv/ for an example of a very x86-only bus and driver
subsystem living in drivers/  Please don't burry driver stuff in arch/
the ARM developers are trying to fix their mistakes of the past and move
all of their cruft out of arch/ for that reason.

thanks,

greg k-h


[GIT PULL] libata changes for v4.7-rc1

2016-05-17 Thread Tejun Heo
Hello, Linus.

Trivial changes except for special case timeout bumping.  I have two
more libata branches which depend on SCSI and dmaengine tree
respectively.  I'll send pull requests for them once the prerequisite
trees are pulled in.

Thanks.

The following changes since commit 535dac4ab5f42e040e8405b31e309a6b6d4eee57:

  ata: add AMD Seattle platform driver (2016-04-13 15:14:24 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git for-4.7

for you to fetch changes up to f8d1a93930a754c4ea27238ae1c0fb2356d12e9a:

  Merge branch 'for-4.6-fixes' into for-4.7 (2016-05-13 17:20:48 -0400)


Andy Shevchenko (1):
  libata-scsi: use %*ph to dump small buffers

Damien Le Moal (1):
  libata-core: Allow longer timeout for drive spinup from PUIS

Masanari Iida (1):
  treewide: Fix typos in libata.xml

Sander Eikelenboom (1):
  libata: Fixup awkward whitespace in warning by removing line continuation.

Tejun Heo (1):
  Merge branch 'for-4.6-fixes' into for-4.7

 drivers/ata/libahci.c |  4 ++--
 drivers/ata/libata-core.c | 22 +-
 drivers/ata/libata-scsi.c |  9 +++--
 include/linux/ata.h   |  3 ++-
 4 files changed, 20 insertions(+), 18 deletions(-)

-- 
tejun


[PATCH] net: au1000 eth: simplify logical expression

2016-05-17 Thread Heinrich Schuchardt
(a && a > 0) is equivalent to (a > 0).

Signed-off-by: Heinrich Schuchardt 
---
 drivers/net/ethernet/amd/au1000_eth.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/amd/au1000_eth.c 
b/drivers/net/ethernet/amd/au1000_eth.c
index 9af309e..e0fb0f1 100644
--- a/drivers/net/ethernet/amd/au1000_eth.c
+++ b/drivers/net/ethernet/amd/au1000_eth.c
@@ -1269,7 +1269,7 @@ static int au1000_probe(struct platform_device *pdev)
aup->phy_irq = pd->phy_irq;
}
 
-   if (aup->phy_busid && aup->phy_busid > 0) {
+   if (aup->phy_busid > 0) {
dev_err(>dev, "MAC0-associated PHY attached 2nd MACs MII 
bus not supported yet\n");
err = -ENODEV;
goto err_mdiobus_alloc;
-- 
2.1.4



Re: [PATCH v4 03/21] fs: Allow sysfs and cgroupfs to share super blocks between user namespaces

2016-05-17 Thread Seth Forshee
On Tue, May 17, 2016 at 05:39:33PM -0500, Eric W. Biederman wrote:
> Seth Forshee  writes:
> 
> > Both of these filesystems already have use cases for mounting the
> > same super block from multiple user namespaces. For sysfs this
> > happens when using criu for snapshotting a container, where sysfs
> > is mnounted in the containers network ns but the hosts user ns.
> > The cgroup filesystem shares the same super block for all mounts
> > of the same hierarchy regardless of the namespace.
> >
> > As a result, the restriction on mounting a super block from a
> > single user namespace creates regressions for existing uses of
> > these filesystems. For these specific filesystems this
> > restriction isn't really necessary since the backing store is
> > objects in kernel memory and thus the ids assigned from inodes
> > is not subject to translation relative to s_user_ns.
> >
> > Add a new filesystem flag, FS_USERNS_SHARE_SB, which when set
> > causes sget_userns() to skip the check of s_user_ns. Set this
> > flag for the sysfs and cgroup filesystems to fix the
> > regressions.
> 
> So this one needs to be sget_userns(..., _user_ns, ...).
> And not a new special case.

This is actually what I wanted to do, but based on a previous discussion
where I had suggested doing this (for a different reason) I came away
thinking you did not want it that way. So I'm happy with that change.

But if we do that it violates some of the assumptions of the patch to
rework MNT_NODEV on your testing branch (and also those behind patch 2
in this series). Something will need to be changed there to prevent a
regression in mount behavior when a user ns tries to mount without
MNT_NODEV when the mount inherited from its parent has it set.

> Apologies for not catching this earlier.

Actually this is a more recent patch, so you possibly hadn't seen it
before.

> I am looking at folding all of this into the patch that introduces
> sget_userns so that even bisects won't have regresssions.

That's fine with me.

Thanks,
Seth



Re: usb: dwc2: regression on MyBook Live Duo / Canyonlands since 4.3.0-rc4

2016-05-17 Thread John Youn
On 5/14/2016 6:11 AM, Christian Lamparter wrote:
> On Thursday, May 12, 2016 11:40:28 AM John Youn wrote:
>> On 5/12/2016 6:30 AM, Christian Lamparter wrote:
>>> On Thursday, May 12, 2016 01:55:44 PM Arnd Bergmann wrote:
 On Thursday 12 May 2016 11:58:18 Christian Lamparter wrote:
 Detecting the endianess of the
 device is probably the best future-proof solution, but it's also
 considerably more work to do in the driver, and comes with a
 tiny runtime overhead.
>>>
>>> The runtime overhead is probably non-measurable compared with the cost
>>> of the actual MMIOs.
>>
>> Right. The code size increase is probably measurable (but still small),
>> the runtime overhead is not.
>
> Ok, so no rebuts or complains have been posted.
>
> I've tested the patch you made in: https://lkml.org/lkml/2016/5/9/354
> and it works: 
>
> Tested-by: Christian Lamparter 
>
> So, how do we go from here? There is are two small issues with the
> original patch (#ifdef DWC2_LOG_WRITES got converted to lower case:
> #ifdef dwc2_log_writes) and I guess a proper subject would be nice.  
>
> Arnd, can you please respin and post it (cc'd stable as well)?
> So this is can be picked up? Or what's your plan?

 (I just realized my reply was stuck in my outbox, so the patch
 went out first)

 If I recall correctly, the rough consensus was to go with your longer
 patch in the future (fixed up for the comments that BenH and
 I sent), and I'd suggest basing it on top of a fixed version of
 my patch.
>>> Well, but it comes with the "overhead"! So this was just as I said:
>>> "Let's look at it and see if it's any good"... And I think it isn't
>>> since the usb/host/ehci people also opted for #ifdef CONFIG_BIG_ENDIAN
>>> archs etc...
>>
>> I slightly prefer the more general patch for future kernel versions.
>> The overhead will probably be negligible, but we can perform some
>> testing to make sure.
>>
>> Can you resubmit with all gathered feedback?
> 
> Yes, here are the changes.
> 
> I've tested it on my MyBook Live Duo. The usbotg comes right up:
> [12610.540004] dwc2 4bff8.usbotg: USB bus 1 deregistered
> [12612.513934] dwc2 4bff8.usbotg: Specified GNPTXFDEP=1024 > 256
> [12612.518756] dwc2 4bff8.usbotg: EPs: 3, shared fifos, 2042 entries in 
> SPRAM
> [12612.530112] dwc2 4bff8.usbotg: DWC OTG Controller
> [12612.533948] dwc2 4bff8.usbotg: new USB bus registered, assigned bus 
> number 1
> [12612.540083] dwc2 4bff8.usbotg: irq 33, io mem 0x
> 
> John: Can you run some perf test with it?
> 
> I've based this on:
> 
> commit 6ea2fffc9057a67df1994d85a7c085d899eaa25a
> Author: Arnd Bergmann 
> Date:   Fri May 13 15:52:27 2016 +0200
> 
> usb: dwc2: fix regression on big-endian PowerPC/ARM systems
> 
> so naturally, it needs to be applied first.
> Most of the conversion work was done by the attached
> coccinelle semantic patches. 
> 
> I had to edit the __bic32 and __orr32 helpers by hand.
> As well as some debugfs code and stuff in gadget.c.
> 

Thanks Christian.

I'll keep this in our internal tree and send it to Felipe later. This
causes a bunch of conflicts that I have to fix up and I should do a
bit of testing as well.

And since there is a patch that fixes the regression this is can wait.

Regards,
John


Re: [PATCH 0/5] add bus driver for Unisys s-Par paravirtualized devices to arch/x86

2016-05-17 Thread Jes Sorensen
Greg KH  writes:
> On Tue, May 17, 2016 at 10:01:55AM -0400, Jes Sorensen wrote:
>> Greg KH  writes:
>> > On Tue, May 17, 2016 at 03:27:56AM -0400, David Kershner wrote:
>> >> This patchset moves the visorbus driver
>> >> (fromdrivers/staging/unisys/visorbus)
>> >> and its dependent headers files (from drivers/staging/unisys/include)
>> >> out of staging into the main kernel tree.
>> >> 
>> >> The visorbus driver is a bus driver for various paravirtualized devices
>> >> presented within a Unisys s-Par guest environment.  Drivers for these
>> >> devices are also currently present under drivers/staging/unisys/, which we
>> >> intend to also move out of staging immediately after visorbus.  All of
>> >> these other drivers are dependent upon visorbus and the include directory,
>> >> which is why we would like to move these first.
>> >> 
>> >> Our initial consultations with various members of the community have led 
>> >> us
>> >> to the conclusion that the most appropriate locations for these is:
>> >> arch/x86/visorbus/   (driver)
>> >> include/linux/visorbus/  (header files)
>> >> 
>> >> The rationale is that visorbus is dependent on x86-64 architecture.
>> >
>> > What makes it dependent on x86?  What prevents it from running on some
>> > other architecture (not the fact that no one has made such hardware,
>> > just the code reasons please.)
>> 
>> It's dependent on system firmware which is only available on the S-Par
>> platform which is x86_64 only. The closest similarity is probably what
>> you find on the PPC and Sparc platforms.
>
> Ok, but still no need to put it under arch/ anything, it should go in
> drivers/ like all other drivers and busses are, no matter what the arch
> it happens to run on is.

I don't think thats obvious. arch/x86/kvm is an example of this, Sparc
and PPC also have their stuff under arch/.

I am open, if people prefer to have drivers/visorbus I can support that.
I find right now it's really messy with things being put all over the
place, and it's not obvious what the real placement is for all of this.

Jes


Re: [RFC PATCH 1/2] ACPI / button: Send "open" state after boot/resume

2016-05-17 Thread Rafael J. Wysocki
On Tue, May 17, 2016 at 10:27 AM, Lv Zheng  wrote:
> (This patch hasn't been tested, it's sent for comments)

I have a couple of concerns (see below).

> Linux userspace (systemd-logind) keeps on rechecking lid state when the
> lid state is closed. If it failed to update the lid state to open after
> boot/resume, it could suspend the system. But as:
> 1. Traditional ACPI platform may not generate the lid open event after
>resuming as the open event is actually handled by the BIOS and the system
>is then resumed from a FACS vector.
> 2. The _LID control method's initial returning value is not reliable. The
>_LID control method is described to return the "current" lid state,
>however the word of "current" has ambiguity, many BIOSen return lid
>state upon last lid notification while the developers may think the
>BIOSen should always return the lid state upon last _LID evaluation.
>There won't be difference when we evaluate _LID during the runtime, the
>problem is the initial returning value of this function. When the BIOSen
>implement this control method with cached value, the initial returning
>value is likely not reliable.
> Thus there is no mean for the ACPI lid driver to provide such an event
> conveying correct current lid state. When there is no such an event or the
> event conveys wrong result, false suspending can be examined.
>
> The root cause of the issue is systemd itself, it could handle the ACPI
> control method lid device by implementing a special option like
> LidSwitchLevelTriggered=False when it detected the ACPI lid device. However
> there is no explicit documentation clarified the ambiguity, we need to
> work it around in the kernel before systemd changing its mind.

The above doesn't explain how the issue is addressed here.

> Link 1: https://lkml.org/2016/3/7/460
> Link 2: https://github.com/systemd/systemd/issues/2087
> Link 3: https://bugzilla.kernel.org/show_bug.cgi?id=89211
> https://bugzilla.kernel.org/show_bug.cgi?id=106151
> https://bugzilla.kernel.org/show_bug.cgi?id=106941
> Signed-off-by: Lv Zheng 
> Cc: Bastien Nocera: 
> ---
>  drivers/acpi/button.c |   63 
> +
>  1 file changed, 59 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
> index 5c3b091..bb14ca5 100644
> --- a/drivers/acpi/button.c
> +++ b/drivers/acpi/button.c
> @@ -53,6 +53,10 @@
>  #define ACPI_BUTTON_DEVICE_NAME_LID"Lid Switch"
>  #define ACPI_BUTTON_TYPE_LID   0x05
>
> +#define ACPI_BUTTON_LID_INIT_IGNORE0x00
> +#define ACPI_BUTTON_LID_INIT_OPEN  0x01
> +#define ACPI_BUTTON_LID_INIT_METHOD0x02
> +
>  #define _COMPONENT ACPI_BUTTON_COMPONENT
>  ACPI_MODULE_NAME("button");
>
> @@ -105,6 +109,7 @@ struct acpi_button {
>
>  static BLOCKING_NOTIFIER_HEAD(acpi_lid_notifier);
>  static struct acpi_device *lid_device;
> +static u8 lid_init_state = ACPI_BUTTON_LID_INIT_OPEN;
>
>  /* --
>FS Interface (/proc)
> @@ -246,7 +251,8 @@ int acpi_lid_open(void)
>  }
>  EXPORT_SYMBOL(acpi_lid_open);
>
> -static int acpi_lid_send_state(struct acpi_device *device)
> +static int acpi_lid_send_state(struct acpi_device *device,
> +  bool notify_init_state)
>  {
> struct acpi_button *button = acpi_driver_data(device);
> unsigned long long state;
> @@ -257,6 +263,10 @@ static int acpi_lid_send_state(struct acpi_device 
> *device)
> if (ACPI_FAILURE(status))
> return -ENODEV;
>
> +   if (notify_init_state &&
> +   lid_init_state == ACPI_BUTTON_LID_INIT_OPEN)
> +   state = 1;
> +

Why do we need to complicate this function?

Can't we have a separate function for sending the fake "lid open" event?

> /* input layer checks if event is redundant */
> input_report_switch(button->input, SW_LID, !state);
> input_sync(button->input);
> @@ -278,6 +288,13 @@ static int acpi_lid_send_state(struct acpi_device 
> *device)
> return ret;
>  }
>
> +static int acpi_lid_send_init_state(struct acpi_device *device)
> +{
> +   if (lid_init_state != ACPI_BUTTON_LID_INIT_IGNORE)
> +   return acpi_lid_send_state(device, true);
> +   return 0;
> +}
> +
>  static void acpi_button_notify(struct acpi_device *device, u32 event)
>  {
> struct acpi_button *button = acpi_driver_data(device);
> @@ -290,7 +307,7 @@ static void acpi_button_notify(struct acpi_device 
> *device, u32 event)
> case ACPI_BUTTON_NOTIFY_STATUS:
> input = button->input;
> if (button->type == ACPI_BUTTON_TYPE_LID) {
> -   acpi_lid_send_state(device);
> +   acpi_lid_send_state(device, false);

I wouldn't change this code at all.


[git pull] vfs.git#sendmsg.cifs

2016-05-17 Thread Al Viro
cifs iovec cleanups.  The first one is an infrastructure patch that had been
pulled into davem's tree (as of commit 6c61403daea578dcfe84f187c204db1a3fa3d6ae
Merge: 743b03a 2da6290
Author: David S. Miller 
Date:   Thu Apr 14 00:39:15 2016 -0400

Merge branch 'for-davem' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
), the rest are cifs-specific.  One trivial conflict with PAGE_CACHE_SIZE ->
PAGE_SIZE conversion (in fs/cifs/file.c; resolved by taking my version and
replacing all PAGE_CACHE_SIZE with PAGE_SIZE in the result; note that one
instance is just prior to the lines git considers a conflict).

The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca:

  Linux 4.6-rc1 (2016-03-26 16:03:24 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git sendmsg.cifs

for you to fetch changes up to 71335664c38f03de10d7cf1d82705fe55a130b33:

  cifs: don't bother with kmap on read_pages side (2016-03-28 14:05:52 -0400)


Al Viro (6):
  [net] drop 'size' argument of sock_recvmsg()
  cifs: merge the hash calculation helpers
  cifs: quit playing games with draining iovecs
  cifs: no need to wank with copying and advancing iovec on recvmsg side 
either
  cifs_readv_receive: use cifs_read_from_socket()
  cifs: don't bother with kmap on read_pages side

 drivers/target/iscsi/iscsi_target_util.c |   5 +-
 fs/cifs/cifsencrypt.c|  97 +++--
 fs/cifs/cifsglob.h   |   2 -
 fs/cifs/cifsproto.h  |  12 +--
 fs/cifs/cifssmb.c|  11 +--
 fs/cifs/connect.c| 127 
 fs/cifs/file.c   |  53 
 fs/cifs/smb2transport.c  | 107 +++
 fs/cifs/transport.c  | 141 +--
 include/linux/net.h  |   3 +-
 net/socket.c |  23 +++--
 11 files changed, 180 insertions(+), 401 deletions(-)


[PATCH 1/1] iwlwifi: rs: remove superfluous check

2016-05-17 Thread Heinrich Schuchardt
If we dereference a variable anyway in other parts of the code,
there is no need to check against NULL in a single place.

Signed-off-by: Heinrich Schuchardt 
---
 drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
index 81dd2f6..bab01ea 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
@@ -2867,7 +2867,7 @@ static void rs_get_rate(void *mvm_r, struct ieee80211_sta 
*sta, void *mvm_sta,
/* TODO: handle rate_idx_mask and rate_idx_mcs_mask */
 
/* Treat uninitialized rate scaling data same as non-existing. */
-   if (lq_sta && !lq_sta->pers.drv) {
+   if (!lq_sta->pers.drv) {
IWL_DEBUG_RATE(mvm, "Rate scaling not initialized yet.\n");
mvm_sta = NULL;
}
-- 
2.1.4



Re: [PATCH v2 0/4] ACPI 2.0: Enable TermList interpretion for table loading

2016-05-17 Thread Rafael J. Wysocki
On Tue, May 17, 2016 at 2:29 AM, Zheng, Lv  wrote:
> Hi, Rafael
>
> Can we queue this up in linux-next?
> ASLTS recursive tests are done in ACPICA upstream and no regressions can be 
> seen.
> We need more tests around this experimental change from the real users to 
> have the chances to learn the unknown cases.
> If they reported regressions, we could stop the regressions by reverting 
> [PATCH 4/4].
> So it should be safe to do such experiments in the Linux upstream.
> Thanks in advance.

There is a rule that during a merge window linux-next should only
contain material for that merge window.  That is, currently linux-next
should only contain material targeted at v4.7.

For this reason, I can't put the series into linux-next right now, but
I'll do that as soon as 4.7-rc1 is released.


[git pull] vfs.git - the rest of work.xattr

2016-05-17 Thread Al Viro
The rest of work.xattr (non-cifs conversions).  There is one difference from
what had been in -next - the commit message of next-to-last commit has
been fixed and the last one had been cherry-picked on top of that.  Strictly
speaking, that violates your no-rebases rule, but here all integration testing
remains provably valid - the same sequence of commits, no reordering, the same
trees all along, etc.  If that's not acceptable, I can send a truncated
pull request (all but the last two), then send those over email.  Up to you...

The following changes since commit ce23e640133484eebc20ca7b7668388213e11327:

  ->getxattr(): pass dentry and inode as separate arguments (2016-04-11 
00:48:00 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus

for you to fetch changes up to e0d46f5c6e0ba3a79e64cd60e62b7b7191ed93f3:

  btrfs: Switch to generic xattr handlers (2016-05-17 19:17:09 -0400)


Al Viro (1):
  gfs2: Switch to generic xattr handlers

Andreas Gruenbacher (6):
  ceph: Get rid of d_find_alias in ceph_set_acl
  ceph: Switch to generic xattr handlers
  jfs: Clean up xattr name mapping
  jfs: Switch to generic xattr handlers
  ubifs: Switch to generic xattr handlers
  btrfs: Switch to generic xattr handlers

Yan, Zheng (1):
  ceph: kill __ceph_removexattr()

 fs/btrfs/inode.c   |  16 ++--
 fs/btrfs/xattr.c   |  22 +-
 fs/btrfs/xattr.h   |   3 -
 fs/ceph/acl.c  |  14 ++--
 fs/ceph/dir.c  |   7 +-
 fs/ceph/inode.c|  29 ---
 fs/ceph/super.h|   8 +-
 fs/ceph/xattr.c| 192 ++---
 fs/gfs2/acl.c  |  58 +++---
 fs/gfs2/acl.h  |   1 +
 fs/gfs2/inode.c|  82 +++-
 fs/gfs2/xattr.c|  46 +--
 fs/jfs/file.c  |   6 +-
 fs/jfs/jfs_xattr.h |   6 +-
 fs/jfs/namei.c |   6 +-
 fs/jfs/symlink.c   |  12 +--
 fs/jfs/xattr.c | 224 -
 fs/ubifs/dir.c |   6 +-
 fs/ubifs/file.c|  12 +--
 fs/ubifs/super.c   |   1 +
 fs/ubifs/ubifs.h   |   7 +-
 fs/ubifs/xattr.c   | 143 --
 22 files changed, 338 insertions(+), 563 deletions(-)


Re: [linux-sunxi] Re: PATH[1/3] ARM: axp20x_usb_power.c add device tree configuration options for REG 30H: VBUS-IPSOUT

2016-05-17 Thread Julian Calaby
Hi Ene,

On Wed, May 18, 2016 at 3:50 AM, Ene Alexandru  wrote:
> the documentation is updated to describe how to convert actual values to the
> provided parameters
>
> ---
> diff -uprN -X linux-sunxi-original/Documentation/dontdiff
> linux-sunxi-original/Documentation/devicetree/bindings/power_supply/axp20x_usb_power.txt
> linux-sunxi/Documentation/devicetree/bindings/power_supply/axp20x_usb_power.txt
> ---
> linux-sunxi-original/Documentation/devicetree/bindings/power_supply/axp20x_usb_power.txt
> 2016-05-09 16:48:46.0 +0200
> +++
> linux-sunxi/Documentation/devicetree/bindings/power_supply/axp20x_usb_power.txt
> 2016-05-11 13:05:58.995873267 +0200
> @@ -5,6 +5,26 @@ Required Properties:
>  This node is a subnode of the axp20x PMIC.
> +The following 3 parameters are configurable from the device-tree:
> +  - vhold-enable
> +  - bit 6 of register REG 30H: VBUS-IPSOUT Power Path
> Management

I don't think it's necessary to go into this much detail here.

> +  - available values are:
> +  - 0x00 : VBUS VHOLD voltage limiting
> control disabled
> +  - 0x01 : VBUS VHOLD voltage limiting
> control enabled

If these are the only options available, why not make this property a boolean?

> +  - vhold-set
> +  - bits <5-3> of register REG 30H: VBUS-IPSOUT Power
> Path Management
> +  - available values are from 0x00 to 0x07
> +  - VHOLD = [400 + ( vhold-set & 0x07 ) * 10]
> in uV

What does this actually do? Is this the lower limit on the voltage? Is
this the voltage it'll try to maintain?

> +  - ibus-limit
> +  - bits <1-0> of register REG 30H: VBUS-IPSOUT Power
> Path Management
> +  - available values are :
> +  - 0x00 : 90uA
> +  - 0x01 : 50uA
> +  - 0x02 : 10uA
> +  - 0x03 : unlimited

Again, what does this actually do? It looks like the current limit?

> +
> +

Extra blank line.

> Example:
>  axp209: pmic@34 {
> @@ -30,5 +50,8 @@ axp209: pmic@34 {
> usb-power-supply: usb-power-supply {
>compatible = "x-powers,axp202-usb-power-supply";
> +  vhold-enable = <0x01>;
> +  vhold-set = <0x04>;
> +  ibus-limit = <0x01>;
>};
> };

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/


[PATCH 1/1] mwiflex: avoid possible null pointer dereference

2016-05-17 Thread Heinrich Schuchardt
Do not dereference card before checking against NULL value.

Signed-off-by: Heinrich Schuchardt 
---
 drivers/net/wireless/marvell/mwifiex/pcie.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 0c7937e..ae1f79e 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -2901,10 +2901,11 @@ static void mwifiex_unregister_dev(struct 
mwifiex_adapter *adapter)
 {
struct pcie_service_card *card = adapter->card;
const struct mwifiex_pcie_card_reg *reg;
-   struct pci_dev *pdev = card->dev;
+   struct pci_dev *pdev;
int i;
 
if (card) {
+   pdev = card->dev;
if (card->msix_enable) {
for (i = 0; i < MWIFIEX_NUM_MSIX_VECTORS; i++)
synchronize_irq(card->msix_entries[i].vector);
-- 
2.1.4



Re: [linux-sunxi] Re: PATH[1/3] ARM: axp20x_usb_power.c add device tree configuration options for REG 30H: VBUS-IPSOUT

2016-05-17 Thread Julian Calaby
Hi Ene,

On Wed, May 18, 2016 at 3:47 AM, Ene Alexandru  wrote:
> axp20x_usb_power.c is modified to read those parameters from the device tree
> configuration.
> if a configuration value is not found then the corresponding register value
> is not changed.
>
> also, debug messages are added, controlled by "CONFIG_POWER_SUPPLY_DEBUG" :
>
> Signed-off-by: Ene Alexandru 
>
>
> ---
> diff -uprN -X linux-sunxi-original/Documentation/dontdiff
> linux-sunxi-original/drivers/power/axp20x_usb_power.c
> linux-sunxi/drivers/power/axp20x_usb_power.c
> --- linux-sunxi-original/drivers/power/axp20x_usb_power.c  2016-05-09
> 16:51:44.0 +0200
> +++ linux-sunxi/drivers/power/axp20x_usb_power.c  2016-05-11
> 13:26:24.444681579 +0200
> @@ -41,6 +41,19 @@
>  #define AXP20X_VBUS_MON_VBUS_VALID   BIT(3)
> +/* bit defines for REG 30H: VBUS-IPSOUT Power Path Management */
> +/* VBUS VHOLD voltage limiting control  */
> +#define AXP20X_VBUS_IPSOUT_MGMT_VHOLD   BIT(6)
> +#define AXP20X_VBUS_IPSOUT_MGMT_VHOLD_ENA  BIT(6)
> +#define AXP20X_VBUS_IPSOUT_MGMT_VHOLD_DISBIT(0)
> +/* VHOLD Set voltage */
> +#define AXP20X_VBUS_IPSOUT_MGMT_VHOLD_SET_MASK (BIT(5)|BIT(4)|BIT(3))
> +#define AXP20X_VBUS_IPSOUT_MGMT_VHOLD_SET_SHIFT (3)
> +/* VBUS current-limit selection */
> +#define AXP20X_VBUS_IPSOUT_MGMT_IBUS_MASK (BIT(1) | BIT(0))
> +
> +
> +

Drop the two extra empty lines here.

> struct axp20x_usb_power {
>struct regmap *regmap;
>struct power_supply *supply;
> @@ -164,6 +177,93 @@ static const struct power_supply_desc ax
>.get_property = axp20x_usb_power_get_property,
> };
> +
> +static int axp20x_usb_power_read_params(const struct device_node *node,
> +  struct axp20x_usb_power *power, struct
> platform_device *pdev)
> +{
> +  const u32 *prop;
> +  int ret;
> +
> +  /*
> +  * configurable parameters are:
> +  * register VBUS-IPSOUT
> +  * bit 6: VBUS VHOLD voltage limiting control
> +  *   0: No voltage drop limit
> +  *   1: Limit the voltage drop
> +  * bit 5-3 VHOLD Set VHOLD = [4.0+ (Bit5-3) * 0.1] V
> +  * bit 1-0 VBUS current-limit selection
> +  *   00:900mA
> +  *   01:500mA
> +  *   10:100mA
> +  *   11:no limit
> +  */
> +
> +  prop = of_get_property(node, "vhold-enable", NULL);
> +  if (prop) {
> +  /* either 1 or 0 */
> +#ifdef DEBUG
> +  dev_info(>dev, "set vhold-enable property to
> %d",
> +  !!(*prop));
> +#endif

Use dev_dbg() instead of wrapping the dev_info() calls in #ifdefs.

> +  if (!!(*prop)) {
> +  ret = regmap_update_bits(power->regmap,
> +
> AXP20X_VBUS_IPSOUT_MGMT,
> +
> AXP20X_VBUS_IPSOUT_MGMT_VHOLD,
> +
> AXP20X_VBUS_IPSOUT_MGMT_VHOLD_ENA);
> +  } else {
> +  ret = regmap_update_bits(power->regmap,
> +
> AXP20X_VBUS_IPSOUT_MGMT,
> +
> AXP20X_VBUS_IPSOUT_MGMT_VHOLD,
> +
> AXP20X_VBUS_IPSOUT_MGMT_VHOLD_DIS);
> +  }
> +  if (ret)
> +  return ret;
> +  } else {
> +#ifdef DEBUG
> +  dev_info(>dev, "no vhold-enable property
> found");
> +#endif

Ditto.

> +  }
> +
> +  prop = of_get_property(node, "vhold-set", NULL);
> +  if (prop) {
> +  /* from 0b000 to 0b111 */
> +#ifdef DEBUG
> +  dev_info(>dev, "set vhold-set property to
> %02X",
> +  ((*prop)>>24));
> +#endif

Ditto.

> +  ret = regmap_update_bits(power->regmap,
> +  AXP20X_VBUS_IPSOUT_MGMT,
> +
> AXP20X_VBUS_IPSOUT_MGMT_VHOLD_SET_MASK,
> +  ((*prop)>>24) <<
> AXP20X_VBUS_IPSOUT_MGMT_VHOLD_SET_SHIFT);
> +  if (ret)
> +  return ret;
> +  } else {
> +#ifdef DEBUG
> +  dev_info(>dev, "no vhold-set property found");
> +#endif

Ditto.

> +  }
> +
> +  prop = of_get_property(node, "ibus-limit", NULL);
> +  if (prop) {
> +  /* from 0b0 to 0b11 */
> +#ifdef DEBUG
> +  dev_info(>dev, "set ibus-limit property to
> %02X",
> +  ((*prop)>>24));
> +#endif

Ditto.

> +  ret = regmap_update_bits(power->regmap,
> AXP20X_VBUS_IPSOUT_MGMT,
> +
> AXP20X_VBUS_IPSOUT_MGMT_IBUS_MASK,
> +  ((*prop)>>24));
> +  if (ret)
> +  return ret;
> +  } else {
> +#ifdef DEBUG
> +   

Re: S3 resume regression [1cf4f629d9d2 ("cpu/hotplug: Move online calls to hotplugged cpu")]

2016-05-17 Thread Rafael J. Wysocki

On 5/16/2016 9:39 PM, Ville Syrjälä wrote:

On Wed, May 11, 2016 at 04:34:06PM +0300, Ville Syrjälä wrote:

On Wed, May 11, 2016 at 08:44:45AM -0400, Steven Rostedt wrote:

On Wed, 11 May 2016 15:21:16 +0300
Ville Syrjälä  wrote:


Yeah can't get anything from the machine at that point. netconsole
didn't help either, and no serial on this machine. And IIRC I've
tried ramoops on this thing in the past but unfortunately the memory
got cleared on reboot.


Can you look at the documentation in the kernel code at

Documentation/power/basic-pm-debugging.txt And follow the procedures
for testing suspend to RAM (although it requires mostly running the
same tests as for hibernation suspending).

You can also use the tool s2ram for this as well.

See Documentation/power/s2ram.txt

Perhaps this can give us a bit more light onto the problem.

Basically the above does partial suspend and resume, and can pinpoint
problem areas down to a more select location.

All the pm_test modes work fine. The only difference between them was
that 'platform' required me to manually wake up the machine (hitting a
key was sufficient), whereas the others woke up without help.

pm_trace gave me
[1.306633]   Magic number: 0:185:178
[1.322880]   hash matches ../drivers/base/power/main.c:1070
[1.339270] acpi device:0e: hash matches
[1.355414]  platform: hash matches

which is the TRACE_SUSPEND in __device_suspend_noirq(), so no help
there.

I guess I could try to sprinkle more TRACE_RESUMEs around into some
early resume code. If anyone has good ideas where to put them it
might speed things up a bit.

So I did a bunch of that and found that it gets stuck somewhere
around executing the _WAK method:
platform_resume_noirq
  acpi_pm_finish
   acpi_leave_sleep_state
acpi_hw_sleep_dispatch
 acpi_hw_legacy_wake
  acpi_hw_execute_sleep_method
   acpi_evaluate_object
acpi_ns_evaluate
 acpi_ps_execute_method
  acpi_ps_parse_aml

It also seesm that adding a few TRACE_RESUME()s or an msleep() right
after enable_nonboot_cpus() can avoid the hang, sometimes.

I've attached the DSDT in case anyone is interested in looking at it.



What if you comment out the execution of _WAK (line 318 of 
drivers/acpi/acpica/hwsleep.c in 4.6)?  Does that make any difference?




[PATCH 1/1] mwifiex: illegal assignment

2016-05-17 Thread Heinrich Schuchardt
Variable adapter is incorrectly initialized.

Fixes: bf00dc22bc7a ("mwifiex: AMSDU Rx frame handling in AP mode")
Signed-off-by: Heinrich Schuchardt 
---
 drivers/net/wireless/marvell/mwifiex/uap_txrx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/uap_txrx.c 
b/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
index 666e91a..bf5660e 100644
--- a/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
+++ b/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
@@ -272,7 +272,7 @@ int mwifiex_handle_uap_rx_forward(struct mwifiex_private 
*priv,
 int mwifiex_uap_recv_packet(struct mwifiex_private *priv,
struct sk_buff *skb)
 {
-   struct mwifiex_adapter *adapter = adapter;
+   struct mwifiex_adapter *adapter = priv->adapter;
struct mwifiex_sta_node *src_node;
struct ethhdr *p_ethhdr;
struct sk_buff *skb_uap;
-- 
2.1.4



Re: [PATCH] asix: Fix offset calculation in asix_rx_fixup() causing slow transmissions

2016-05-17 Thread Dean Jenkins

Hi John,

Thanks for your patch. I think the patch has already been applied.

The git commit subject of
"asix: Fix offset calculation in asix_rx_fixup() causing slow transmissions"

I think is a bit misleading as the bug relates to reception and not 
transmission.


I guess that your intent was to say that "the through-put of 
communications was low" due to the bug.


Personally, I would of used a git subject like
"asix: Fix asix_rx_fixup_interval() offset calculation for spanned frames"

But anyway, I have no real issue with the patch.

On 17/05/16 04:36, John Stultz wrote:

In testing with HiKey, we found that since
commit 3f30b158eba5 ("asix: On RX avoid creating bad Ethernet
frames"),
we're seeing lots of noise during network transfers:

[  239.027993] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header synchronisation 
was lost, remaining 988
[  239.037310] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 
0x54ebb5ec, offset 4
[  239.045519] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 
0xcdffe7a2, offset 4
[  239.275044] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header synchronisation 
was lost, remaining 988
[  239.284355] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 
0x1d36f59d, offset 4
[  239.292541] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 
0xaef3c1e9, offset 4
[  239.518996] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header synchronisation 
was lost, remaining 988
[  239.528300] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 
0x2881912, offset 4
[  239.536413] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 
0x5638f7e2, offset 4

And network throughput ends up being pretty bursty and slow with
a overall throughput of at best ~30kB/s (where as previously we
got 1.1MB/s with the slower USB1.1 "full speed" host).

We found the issue also was reproducible on a x86_64 system,
using a "high-speed" USB2.0 port but the throughput did not
measurably drop (possibly due to the scp transfer being cpu
bound on my slow test hardware).

After lots of debugging, I found the check added in the
problematic commit seems to be calculating the offset
incorrectly.

In the normal case, in the main loop of the function, we do:
(where offset is zero, or set to "offset += (copy_length + 1) &
0xfffe" in the previous loop)
 rx->header = get_unaligned_le32(skb->data +
 offset);
 offset += sizeof(u32);

But the problematic patch calculates:
 offset = ((rx->remaining + 1) & 0xfffe) + sizeof(u32);
 rx->header = get_unaligned_le32(skb->data + offset);

Adding some debug logic to check those offset calculation used
to find rx->header, the one in problematic code is always too
large by sizeof(u32).

Thus, this patch removes the incorrect " + sizeof(u32)" addition
in the problematic calculation, and resolves the issue.

Cc: Dean Jenkins 
Cc: "David B. Robins" 
Cc: Mark Craske 
Cc: Emil Goode 
Cc: "David S. Miller" 
Cc: YongQin Liu 
Cc: Guodong Xu 
Cc: Ivan Vecera 
Cc: linux-...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: stable  #4.4+
Reported-by: Yongqin Liu 
Signed-off-by: John Stultz 
---
  drivers/net/usb/asix_common.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/asix_common.c b/drivers/net/usb/asix_common.c
index 0c5c22b..7de5ab5 100644
--- a/drivers/net/usb/asix_common.c
+++ b/drivers/net/usb/asix_common.c
@@ -66,7 +66,7 @@ int asix_rx_fixup_internal(struct usbnet *dev, struct sk_buff 
*skb,
 * buffer.
 */
if (rx->remaining && (rx->remaining + sizeof(u32) <= skb->len)) {
-   offset = ((rx->remaining + 1) & 0xfffe) + sizeof(u32);
+   offset = ((rx->remaining + 1) & 0xfffe);
I have verified that this fixes my ARM board. Thanks for finding the 
mistake.
Note that the outer set of brackets could of been removed as they are 
redundant.



rx->header = get_unaligned_le32(skb->data + offset);
offset = 0;
  

Thanks,

Best regards,
Dean

--
Dean Jenkins
Embedded Software Engineer
Linux Transportation Solutions
Mentor Embedded Software Division
Mentor Graphics (UK) Ltd.



[GIT PULL] Audit patches for 4.7

2016-05-17 Thread Paul Moore
Hi Linus,

Four small audit patches for 4.7; two are simple cleanups around the audit 
thread management code, one adds a tty field to AUDIT_LOGIN events, and the 
final patch makes tty_name() usable regardless of CONFIG_TTY.  Nothing 
controversial, and it all passes our regression test.  Please pull for 4.7.

Thanks,
-Paul

---
The following changes since commit b562e44f507e863c6792946e4e1b1449fbbac85d:

  Linux 4.5 (2016-03-13 21:28:54 -0700)

are available in the git repository at:

  git://git.infradead.org/users/pcmoore/audit stable-4.7

for you to fetch changes up to 188e3c5cd2b672620291e64a21f1598fe91e40b6:

  tty: provide tty_name() even without CONFIG_TTY (2016-04-27 17:12:58 -0400)


Arnd Bergmann (1):
  tty: provide tty_name() even without CONFIG_TTY

Jiri Slaby (1):
  audit: cleanup prune_tree_thread

Paul Moore (1):
  audit: we don't need to __set_current_state(TASK_RUNNING)

Richard Guy Briggs (1):
  audit: add tty field to LOGIN event

 include/linux/audit.h | 24 
 include/linux/tty.h   |  4 +++-
 kernel/audit.c| 30 ++
 kernel/audit_tree.c   | 12 +---
 kernel/auditsc.c  |  8 ++--
 5 files changed, 48 insertions(+), 30 deletions(-)

-- 
paul moore
security @ redhat




Re: livepatch: change to a per-task consistency model

2016-05-17 Thread Jessica Yu

+++ Josh Poimboeuf [28/04/16 15:44 -0500]:

[snip]


diff --git a/Documentation/livepatch/livepatch.txt 
b/Documentation/livepatch/livepatch.txt
index 6c43f6e..bee86d0 100644
--- a/Documentation/livepatch/livepatch.txt
+++ b/Documentation/livepatch/livepatch.txt
@@ -72,7 +72,8 @@ example, they add a NULL pointer or a boundary check, fix a 
race by adding
a missing memory barrier, or add some locking around a critical section.
Most of these changes are self contained and the function presents itself
the same way to the rest of the system. In this case, the functions might
-be updated independently one by one.
+be updated independently one by one.  (This can be done by setting the
+'immediate' flag in the klp_patch struct.)

But there are more complex fixes. For example, a patch might change
ordering of locking in multiple functions at the same time. Or a patch
@@ -86,20 +87,103 @@ or no data are stored in the modified structures at the 
moment.
The theory about how to apply functions a safe way is rather complex.
The aim is to define a so-called consistency model. It attempts to define
conditions when the new implementation could be used so that the system
-stays consistent. The theory is not yet finished. See the discussion at
-http://thread.gmane.org/gmane.linux.kernel/1823033/focus=1828189
-
-The current consistency model is very simple. It guarantees that either
-the old or the new function is called. But various functions get redirected
-one by one without any synchronization.
-
-In other words, the current implementation _never_ modifies the behavior
-in the middle of the call. It is because it does _not_ rewrite the entire
-function in the memory. Instead, the function gets redirected at the
-very beginning. But this redirection is used immediately even when
-some other functions from the same patch have not been redirected yet.
-
-See also the section "Limitations" below.
+stays consistent.
+
+Livepatch has a consistency model which is a hybrid of kGraft and
+kpatch:  it uses kGraft's per-task consistency and syscall barrier
+switching combined with kpatch's stack trace switching.  There are also
+a number of fallback options which make it quite flexible.
+
+Patches are applied on a per-task basis, when the task is deemed safe to
+switch over.  When a patch is enabled, livepatch enters into a
+transition state where tasks are converging to the patched state.
+Usually this transition state can complete in a few seconds.  The same
+sequence occurs when a patch is disabled, except the tasks converge from
+the patched state to the unpatched state.
+
+An interrupt handler inherits the patched state of the task it
+interrupts.  The same is true for forked tasks: the child inherits the
+patched state of the parent.
+
+Livepatch uses several complementary approaches to determine when it's
+safe to patch tasks:
+
+1. The first and most effective approach is stack checking of sleeping
+   tasks.  If no affected functions are on the stack of a given task,
+   the task is patched.  In most cases this will patch most or all of
+   the tasks on the first try.  Otherwise it'll keep trying
+   periodically.  This option is only available if the architecture has
+   reliable stacks (CONFIG_RELIABLE_STACKTRACE and
+   CONFIG_STACK_VALIDATION).
+
+2. The second approach, if needed, is kernel exit switching.  A
+   task is switched when it returns to user space from a system call, a
+   user space IRQ, or a signal.  It's useful in the following cases:
+
+   a) Patching I/O-bound user tasks which are sleeping on an affected
+  function.  In this case you have to send SIGSTOP and SIGCONT to
+  force it to exit the kernel and be patched.


See below -


+   b) Patching CPU-bound user tasks.  If the task is highly CPU-bound
+  then it will get patched the next time it gets interrupted by an
+  IRQ.
+   c) Applying patches for architectures which don't yet have
+  CONFIG_RELIABLE_STACKTRACE.  In this case you'll have to signal
+  most of the tasks on the system.  However this isn't a complete
+  solution, because there's currently no way to patch kthreads
+  without CONFIG_RELIABLE_STACKTRACE.
+
+   Note: since idle "swapper" tasks don't ever exit the kernel, they
+   instead have a kpatch_patch_task() call in the idle loop which allows
+   them to patched before the CPU enters the idle state.
+
+3. A third approach (not yet implemented) is planned for the case where
+   a kthread is sleeping on an affected function.  In that case we could
+   kick the kthread with a signal and then try to patch the task from
+   the to-be-patched function's livepatch ftrace handler when it
+   re-enters the function.  This will require
+   CONFIG_RELIABLE_STACKTRACE.
+
+All the above approaches may be skipped by setting the 'immediate' flag
+in the 'klp_patch' struct, which will patch all tasks immediately.  This
+can be useful if the patch doesn't change any function or data
+semantics.  Note that, even 

Re: [RFC v2 PATCH 0/8] VFS:userns: support portable root filesystems

2016-05-17 Thread Eric W. Biederman
James Bottomley  writes:

> On Sat, 2016-05-14 at 21:21 -0500, Eric W. Biederman wrote:
>> James Bottomley  writes:
>> 
>> > On Sat, 2016-05-14 at 10:53 +0100, Djalal Harouni wrote:
>> 
>> Just a couple of quick comments from a very high level design point.
>> 
>> - I think a shiftfs is valuable in the same way that overlayfs is
>>   valuable.
>> 
>>   Esepcially in the Docker case where a lot of containers want a shared
>>   base image (for efficiency), but it is desirable to run those
>>   containers in different user namespaces for safety.
>> 
>> - It is also the plan to make it possible to mount a filesystem where
>>   the uids and gids of that filesystem on disk do not have a one to one
>>   mapping to kernel uids and gids.  99% of the work has already be done,
>>   for all filesystem except XFS.
>
> Can you elaborate a bit more on why we want to do this?  I think only
> having a single shift of uid_t to kuid_t across the kernel to user
> boundary is a nice feature of user namespaces.  Architecturally, it's
> not such a big thing to do it as the data goes on to the disk as well,
> but what's the use case for it?

fuse/nfs or just plain sanity.  As the data comes off disk we convert it
into the kernel internal form kuid_t and kgid_t.   For shiftfs this
would be converting the uids when they come from your underlying
filesystem to the upper level vfs abstractions.

Converting to the kernel form for a filesystem such as fuse that is does
all that is necessary to keep evil users from breaking the kernel means
that we call allow users in a user namespace to mount fuse themselves.
Supply whatever uids and gids they want in the fuse messages.  If the
uids/gids don't map from the mounting users user namespace into the
kernel then we set inode->i_uid to INVALID_UID.

That is all we ask of a filesystem, and we are sorting out the rest in
the VFS as nothing sets INVALID_UID in inode->i_uid today.


>>   That said there are some significant issues to work through, before
>>   something like that can be enabled.
>> 
>>   * Handling of uids/gids on disk that don't map into a kuid/kgid.
>
> So I think this is nicely handled in the capability checks in
> generic_permission() (capable_wrt_inode_uidgid()) is there a need to
> make it more complex (and thus more error prone)?

No just a need to handle INVALID_UID, and INVALID_GID which we don't
handle today.

>>   * Safety from poisoned filesystem images.
>
> By poisoned FS image, you mean an image over whose internal data the
> user has control?  The basic problem of how do we give users write
> access to data devices they can then cause to be mounted as
> filesystems?

Yes.  For fuse except for uids and gids this is already solved for most
other filesystems it is a whole new world of horror.

The general case of evil usb devices (think android) that look like
block devices but can return whatever they want already exists in the
wild.

>>   I have slowly been working with Seth Forshee on these issues as
>>   the last thing I want is to introduce more security bugs right now.
>>   Seth being a braver man than I am has already merged his changes into
>>   the Ubuntu kernel.
>> 
>>   Right now we are targeting fuse, because fuse is already designed to
>>   handle poisoned filesystem images.  So to safely enable this kind of
>>   mapping for fuse is not a giant step.
>> 
>>   The big thing from my point of view is to get the VFS interfaces
>>   correct so that the VFS handles all of the weird cases that come up
>>   with uids and gids that don't map, and any other weird cases.  Keeping
>>   the weird bits out of the filesystems.
>
> If by VFS interfaces, you mean where we've already got the mapping 
> confined, absolutely.

Yes.  It is just making certain we handle INVALID_UID and INVALID_GID
that results from a mapping failure.  As we don't handle that in 4.6.0.

>> James I think you are missing the fact that all filesystems already 
>> have the make_kuid and make_kgid calls right where the data comes off
>> disk,
>
> I beg to differ: they certainly don't.  The underlying filesystem
> populates the inode in ->lookup with the data off the disk which goes
> into the inode as a kuid_t/kgid_t  It remains forever in the inode as
> that.  We convert it as it goes out of the kernel in the stat calls
> (actually stat.c:cp_old/new_stat())

They do.  i_uid_write calls make_kuid to map the in comming uid from
disk into a kuid_t.  That is all I was referring to.

The only thing I am looking at infrastructure wise it to make it so that
we cleanly handle when the first parameter to make_kuid is not
_user_ns.  That is the core point of Seths work.

>>  and the from_kuid and from_kgid calls right where the on-disk data
>> is being created just before it goes on disk.  Which means that the
>> actual impact on filesystems of the translation is trivial.
>
> Are you looking at a different tree from me?  I'm 

Re: [PATCH v4 03/21] fs: Allow sysfs and cgroupfs to share super blocks between user namespaces

2016-05-17 Thread Eric W. Biederman
Seth Forshee  writes:

> Both of these filesystems already have use cases for mounting the
> same super block from multiple user namespaces. For sysfs this
> happens when using criu for snapshotting a container, where sysfs
> is mnounted in the containers network ns but the hosts user ns.
> The cgroup filesystem shares the same super block for all mounts
> of the same hierarchy regardless of the namespace.
>
> As a result, the restriction on mounting a super block from a
> single user namespace creates regressions for existing uses of
> these filesystems. For these specific filesystems this
> restriction isn't really necessary since the backing store is
> objects in kernel memory and thus the ids assigned from inodes
> is not subject to translation relative to s_user_ns.
>
> Add a new filesystem flag, FS_USERNS_SHARE_SB, which when set
> causes sget_userns() to skip the check of s_user_ns. Set this
> flag for the sysfs and cgroup filesystems to fix the
> regressions.

So this one needs to be sget_userns(..., _user_ns, ...).
And not a new special case.

Apologies for not catching this earlier.

I am looking at folding all of this into the patch that introduces
sget_userns so that even bisects won't have regresssions.

We loose the ability to call mount -o remount and actually affect
these filesystems (which we don't have without s_user_ns) but we gain a
whole lot of simplicity, and we don't break the xattr and security label
on sysfs code.

Eric


[PATCH 1/1] rtlwifi: rtl8723be: avoid undefined behavior

2016-05-17 Thread Heinrich Schuchardt
Do not return undefined value for transmission power
if the rate is invalid.

Signed-off-by: Heinrich Schuchardt 
---
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/phy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/phy.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/phy.c
index 445f681..c5ca9df 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/phy.c
@@ -1019,7 +1019,7 @@ static u8 _rtl8723be_get_txpower_index(struct 
ieee80211_hw *hw, u8 path,
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_efuse *rtlefuse = rtl_efuse(rtl_priv(hw));
u8 index = (channel - 1);
-   u8 txpower;
+   u8 txpower = 0;
u8 power_diff_byrate = 0;
 
if (channel > 14 || channel < 1) {
-- 
2.1.4



Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

2016-05-17 Thread Arnd Bergmann
On Tuesday 17 May 2016 18:02:36 Andreas Schwab wrote:
> Joseph Myers  writes:
> 
> > On Tue, 17 May 2016, Arnd Bergmann wrote:
> >
> >> I think it has become easier to override now and we just need to
> >> update sysdeps/unix/sysv/linux/generic/bits/typesizes.h to set
> >> 
> >> #define __INO64_T_TYPE  __UQUAD_TYPE
> >> #define __OFF64_T_TYPE  __UQUAD_TYPE
> >> #define __OFF_T_MATCHES_OFF64_T1
> >> #define __INO_T_MATCHES_INO64_T1
> >> 
> >> for new architectures (obviously not the ones that already use the
> >> 32-bit types). I haven't tries this, so there may be other things
> >> that are required.
> >
> > I think more than that would be needed to get struct stat to match and get 
> > things aliased for that (which is presumably desirable).
> 
> Looking at sysdeps/unix/sysv/linux/generic/bits/stat.h, there is at
> least blkcnt_t that differs between stat and stat64.  And you probably
> want to alias statfs and statfs64 as well, ie. fs{blk,fil}cnt_t.

Makes sense. Indeed that is a bit more work than I hoped, in particular
if we have to audit the uses of __WORDSIZE as well.

Arnd


Re: SCHED_DEADLINE cpudeadline.{h,c} fixup

2016-05-17 Thread Tommaso Cucinotta

On 17/05/2016 13:46, luca abeni wrote:

Maybe the ... change can be split in a separate
patch, which is a bugfix (and IMHO uncontroversial)?


Ok, the bugfix alone might look like the attached. Couldn't avoid
the little refactoring of the multiple occurrences of the same loop
up the heap into the heapify_up(), mirroring the heapify() that was
already there (renamed heapify_down() for clarity).

I'll rebase the speed-up patch on top of this, if it's a better approach.

Anyone with further comments?

Thanks again!

T.
--
Tommaso Cucinotta, Computer Engineering PhD
Associate Professor at the Real-Time Systems Laboratory (ReTiS)
Scuola Superiore Sant'Anna, Pisa, Italy
http://retis.sssup.it/people/tommaso
>From cfaa75eb77843f7da875a54c7e6631b271bf0663 Mon Sep 17 00:00:00 2001
From: Tommaso Cucinotta 
Date: Tue, 17 May 2016 15:54:11 +0200
Subject: [PATCH] Deadline wrap-around bugfix for the SCHED_DEADLINE cpu heap.

---
 kernel/sched/cpudeadline.c | 38 +++---
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/kernel/sched/cpudeadline.c b/kernel/sched/cpudeadline.c
index 5be5882..3c42702 100644
--- a/kernel/sched/cpudeadline.c
+++ b/kernel/sched/cpudeadline.c
@@ -41,7 +41,7 @@ static void cpudl_exchange(struct cpudl *cp, int a, int b)
 	swap(cp->elements[cpu_a].idx, cp->elements[cpu_b].idx);
 }
 
-static void cpudl_heapify(struct cpudl *cp, int idx)
+static void cpudl_heapify_down(struct cpudl *cp, int idx)
 {
 	int l, r, largest;
 
@@ -66,20 +66,25 @@ static void cpudl_heapify(struct cpudl *cp, int idx)
 	}
 }
 
+static void cpudl_heapify_up(struct cpudl *cp, int idx)
+{
+	while (idx > 0 && dl_time_before(cp->elements[parent(idx)].dl,
+			cp->elements[idx].dl)) {
+		cpudl_exchange(cp, idx, parent(idx));
+		idx = parent(idx);
+	}
+}
+
 static void cpudl_change_key(struct cpudl *cp, int idx, u64 new_dl)
 {
 	WARN_ON(idx == IDX_INVALID || !cpu_present(idx));
 
 	if (dl_time_before(new_dl, cp->elements[idx].dl)) {
 		cp->elements[idx].dl = new_dl;
-		cpudl_heapify(cp, idx);
+		cpudl_heapify_down(cp, idx);
 	} else {
 		cp->elements[idx].dl = new_dl;
-		while (idx > 0 && dl_time_before(cp->elements[parent(idx)].dl,
-	cp->elements[idx].dl)) {
-			cpudl_exchange(cp, idx, parent(idx));
-			idx = parent(idx);
-		}
+		cpudl_heapify_up(cp, idx);
 	}
 }
 
@@ -154,24 +159,19 @@ void cpudl_set(struct cpudl *cp, int cpu, u64 dl, int is_valid)
 		cp->size--;
 		cp->elements[new_cpu].idx = old_idx;
 		cp->elements[cpu].idx = IDX_INVALID;
-		while (old_idx > 0 && dl_time_before(
-cp->elements[parent(old_idx)].dl,
-cp->elements[old_idx].dl)) {
-			cpudl_exchange(cp, old_idx, parent(old_idx));
-			old_idx = parent(old_idx);
-		}
+		cpudl_heapify_up(cp, old_idx);
 		cpumask_set_cpu(cpu, cp->free_cpus);
-cpudl_heapify(cp, old_idx);
+cpudl_heapify_down(cp, old_idx);
 
 		goto out;
 	}
 
 	if (old_idx == IDX_INVALID) {
-		cp->size++;
-		cp->elements[cp->size - 1].dl = 0;
-		cp->elements[cp->size - 1].cpu = cpu;
-		cp->elements[cpu].idx = cp->size - 1;
-		cpudl_change_key(cp, cp->size - 1, dl);
+		int size1 = cp->size++;
+		cp->elements[size1].dl = dl;
+		cp->elements[size1].cpu = cpu;
+		cp->elements[cpu].idx = size1;
+		cpudl_heapify_up(cp, size1);
 		cpumask_clear_cpu(cpu, cp->free_cpus);
 	} else {
 		cpudl_change_key(cp, old_idx, dl);
-- 
2.7.4



  1   2   3   4   5   6   7   >