[PATCH v7 5/6] perf report: support time percent and multiple time ranges

[Jin Yao]

perf report has a --time option to limit the time range of output.
It only supports absolute time.

Now this option is extended to support multiple time ranges and
support the percent of time.

For example:

1. Select the first and second 10% time slices
perf report --time 10%/1,10%/2

2. Select from 0% to 10% and 30% to 40% slices
perf report --time 0%-10%,30%-40%

Change log:
---
v6: Fix the merge issue with latest perf/core branch.
No functional changes.

v5: Add checking of first/last sample time to detect if it's recorded
in perf.data. If it's not recorded, returns error message to user.

v4: Remove perf_time__skip_sample, only uses perf_time__ranges_skip_sample

v3: Since the definitions of first_sample_time/last_sample_time
are moved from perf_session to perf_evlist so change the
related code.

Signed-off-by: Jin Yao 
---
 tools/perf/Documentation/perf-report.txt | 16 
 tools/perf/builtin-report.c  | 31 ++-
 2 files changed, 42 insertions(+), 5 deletions(-)

diff --git a/tools/perf/Documentation/perf-report.txt 
b/tools/perf/Documentation/perf-report.txt
index ddde2b5..ed36553 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -402,6 +402,22 @@ OPTIONS
stop time is not given (i.e, time string is 'x.y,') then analysis goes
to end of file.
 
+   Also support time percent with multipe time range. Time string is
+   'a%/n,b%/m,...' or 'a%-b%,c%-%d,...'. The maximum number of slices is 
10.
+
+   For example:
+   Select the second 10% time slice
+   perf report --time 10%/2
+
+   Select from 0% to 10% time slice
+   perf report --time 0%-10%
+
+   Select the first and second 10% time slices
+   perf report --time 10%/1,10%/2
+
+   Select from 0% to 10% and 30% to 40% slices
+   perf report --time 0%-10%,30%-40%
+
 --itrace::
Options for decoding instruction tracing data. The options are:
 
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index eb9ce63..946f146 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -52,6 +52,8 @@
 #include 
 #include 
 
+#define PTIME_RANGE_MAX10
+
 struct report {
struct perf_tooltool;
struct perf_session *session;
@@ -69,7 +71,8 @@ struct report {
const char  *cpu_list;
const char  *symbol_filter_str;
const char  *time_str;
-   struct perf_time_interval ptime;
+   struct perf_time_interval ptime_range[PTIME_RANGE_MAX];
+   int range_num;
float   min_percent;
u64 nr_entries;
u64 queue_size;
@@ -186,8 +189,10 @@ static int process_sample_event(struct perf_tool *tool,
};
int ret = 0;
 
-   if (perf_time__skip_sample(>ptime, sample->time))
+   if (perf_time__ranges_skip_sample(rep->ptime_range, rep->range_num,
+ sample->time)) {
return 0;
+   }
 
if (machine__resolve(machine, , sample) < 0) {
pr_debug("problem processing %d event, skipping it.\n",
@@ -1077,9 +1082,25 @@ int cmd_report(int argc, const char **argv)
if (symbol__init(>header.env) < 0)
goto error;
 
-   if (perf_time__parse_str(, report.time_str) != 0) {
-   pr_err("Invalid time string\n");
-   return -EINVAL;
+   if (perf_time__parse_str(report.ptime_range, report.time_str) != 0) {
+   if (session->evlist->first_sample_time == 0 &&
+   session->evlist->last_sample_time == 0) {
+   pr_err("No first/last sample time in perf data\n");
+   return -EINVAL;
+   }
+
+   report.range_num = perf_time__percent_parse_str(
+   report.ptime_range, PTIME_RANGE_MAX,
+   report.time_str,
+   session->evlist->first_sample_time,
+   session->evlist->last_sample_time);
+
+   if (report.range_num < 0) {
+   pr_err("Invalid time string\n");
+   return -EINVAL;
+   }
+   } else {
+   report.range_num = 1;
}
 
sort__setup_elide(stdout);
-- 
2.7.4

Re: [PATCH v2 06/35] nds32: MMU fault handling and page table management

[Greentime Hu]

2017-12-08 0:40 GMT+08:00 Al Viro :
> On Mon, Nov 27, 2017 at 08:27:53PM +0800, Greentime Hu wrote:
>> +void do_page_fault(unsigned long entry, unsigned long addr,
>> +unsigned int error_code, struct pt_regs *regs)
> [snip]
>> + /*
>> +  * If we're in an interrupt or have no user
>> +  * context, we must not take the fault..
>> +  */
>> + if (unlikely(in_atomic() || !mm))
>
> Broken.  in_atomic() is wrong here - it should be faulthandler_disabled().

Thanks.
I will include  and replace in_atomic() with
faulthandler_disabled()
I will fix it in the next version patch.

Re: [PATCH v1 1/2] ASoC: rsnd: ssi: fix race condition in rsnd_ssi_pointer_update

[Kuninori Morimoto]

Hi Jiada

> >> Currently there is race condition between set of byte_pos and wrap
> >> it around when new buffer starts. If .pointer is called in-between
> >> it will result in inconsistent pointer position be returned
> >> from .pointer callback.
> >>
> >> This patch increments buffer pointer atomically to avoid this issue.
> >>
> >> Signed-off-by: Jiada Wang
> >> Reviewed-by: Takashi Sakamoto
> >> ---
> > You using playback with PIO mode ?
> > Because this function is no longer used on DMA mode
> No, we are using rcar sound in DMA mode,
> our original patch resolves the issue in core.c for both PIO & DMA mode.
> 
> but with your commit a97a06c ("ASoC: rsnd: cleanup pointer related code"),
> DMA mode no longer has the race condition issue,
> so I ported our fix patch to only address the issue in PIO mode

Thanks. Nice to know.

Best regards
---
Kuninori Morimoto

Re: [PATCH 1/2] tools/lib/lockdep: Add missing declaration of 'pr_cont()'

[Ingo Molnar]

* alexander.le...@verizon.com  wrote:

> From: Mengting Zhang 
> 
> An annoying compile warning due to missing declaration is shown below:
> In file included from lockdep.c:27:0:
> ../../../kernel/locking/lockdep.c: In function 'print_unlock_imbalance_bug' :
> ../../../kernel/locking/lockdep.c:3544:2: warning: implicit declaration of 
> function 'pr_cont' [-Wimplicit-function-declaration]
>   pr_cont(") at:\n");
>   ^

All build warnings are annoying, please formulate this in a more neutral 
fashion.

Also, please separate the compiler splat from the changelog text with an empty 
line, and align it vertically as well so that it seprates more.

Please do this for the second patch as well, and try to harmonize the style of 
the 
changelogs.

This is an example of a clean changelog that fixes a build warning:

commit 1b3b5219abfd6a214e99018747e9fe98514b43ca
Author: Arnaldo Carvalho de Melo 
Date:   Mon Nov 27 12:18:23 2017 -0300

tools headers: Syncronize mman.h ABI header

To add support for the MAP_SYNC flag introduced in:

  b6fb293f2497 ("mm: Define MAP_SYNC and VM_SYNC flags")

Update tools/perf/trace/beauty/mmap.c to support that flag.

This silences this perf build warning:

  Warning: Kernel ABI header at 'tools/include/uapi/asm-generic/mman.h' 
differs from latest version at 'include/uapi/asm-generic/mman.h'

Cc: Adrian Hunter 
Cc: Dan Williams 
Cc: David Ahern 
Cc: Jan Kara 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: https://lkml.kernel.org/n/tip-14zyk3iywrj37c7g1eagm...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 

Thanks,

Ingo

Re: [PATCH v4 72/73] xfs: Convert mru cache to XArray

[Dave Chinner]

On Fri, Dec 08, 2017 at 01:45:52PM +0900, Byungchul Park wrote:
> On Fri, Dec 08, 2017 at 09:22:16AM +1100, Dave Chinner wrote:
> > On Thu, Dec 07, 2017 at 11:06:34AM -0500, Theodore Ts'o wrote:
> > > On Wed, Dec 06, 2017 at 06:06:48AM -0800, Matthew Wilcox wrote:
> > > > > Unfortunately for you, I don't find arguments along the lines of
> > > > > "lockdep will save us" at all convincing.  lockdep already throws
> > > > > too many false positives to be useful as a tool that reliably and
> > > > > accurately points out rare, exciting, complex, intricate locking
> > > > > problems.
> > > > 
> > > > But it does reliably and accurately point out "dude, you forgot to take
> > > > the lock".  It's caught a number of real problems in my own testing that
> > > > you never got to see.
> > > 
> > > The problem is that if it has too many false positives --- and it's
> > > gotten *way* worse with the completion callback "feature", people will
> > > just stop using Lockdep as being too annyoing and a waste of developer
> > > time when trying to figure what is a legitimate locking bug versus
> > > lockdep getting confused.
> > > 
> > > I can't even disable the new Lockdep feature which is throwing
> > > lots of new false positives --- it's just all or nothing.
> > > 
> > > Dave has just said he's already stopped using Lockdep, as a result.
> > 
> > This is compeltely OT, but FYI I stopped using lockdep a long time
> > ago.  We've spend orders of magnitude more time and effort to shut
> > up lockdep false positives in the XFS code than we ever have on
> > locking problems that lockdep has uncovered. And still lockdep
> > throws too many false positives on XFS workloads to be useful to me.
> > 
> > But it's more than that: I understand just how much lockdep *doesn't
> > check* and that means *I know I can't rely on lockdep* for potential
> > deadlock detection. e.g.  it doesn't cover semaphores, which means
> 
> Hello,
> 
> I'm careful in saying the following since you seem to feel not good at
> crossrelease and even lockdep. Now that cross-release has been
> introduced, semaphores can be covered as you might know. Actually, all
> general waiters can.

And all it will do is create a whole bunch more work for us XFS guys
to shut up all the the false positive crap that falls out from it
because the locking model we have is far more complex than any of
the lockdep developers thought was necessary to support, just like
happened with the XFS inode annotations all those years ago.

e.g. nobody has ever bothered to ask us what is needed to describe
XFS's semaphore locking model.  If you did that, you'd know that we
nest *thousands* of locked semaphores in compeltely random lock
order during metadata buffer writeback. And that this lock order
does not reflect the actual locking order rules we have for locking
buffers during transactions.

Oh, and you'd also know that a semaphore's lock order and context
can change multiple times during the life time of the buffer.  Say
we free a block and the reallocate it as something else before it is
reclaimed - that buffer now might have a different lock order. Or
maybe we promote a buffer to be a root btree block as a result of a
join - it's now the first buffer in a lock run, rather than a child.
Or we split a tree, and the root is now a node and so no longer is
the first buffer in a lock run. Or that we walk sideways along the
leaf nodes siblings during searches.  IOWs, there is no well defined
static lock ordering at all for buffers - and therefore semaphores -
in XFS at all.

And knowing that, you wouldn't simply mention that lockdep can
support semaphores now as though that is necessary to "make it work"
for XFS.  It's going to be much simpler for us to just turn off
lockdep and ignore whatever crap it sends our way than it is to
spend unplanned weeks of our time to try to make lockdep sorta work
again. Sure, we might get there in the end, but it's likely to take
months, if not years like it did with the XFS inode annotations.

> > it has zero coverage of the entire XFS metadata buffer subsystem and
> > the complex locking orders we have for metadata updates.
> > 
> > Put simply: lockdep doesn't provide me with any benefit, so I don't
> > use it...
> 
> Sad..

I don't think you understand. I'll try to explain.

The lockdep infrastructure by itself doesn't make lockdep a useful
tool - it mostly generates false positives because it has no
concept of locking models that don't match it's internal tracking
assumptions and/or limitations.

That means if we can't suppress the false positives, then lockdep is
going to be too noisy to find real problems.  It's taken the XFS
developers months of work over the past 7-8 years to suppress all
the *common* false positives that lockdep throws on XFS. And despite
all that work, there's still too many false positives occuring
because we can't easily suppress them with annotations. IOWs, the
signal to noise ratio is still too low for lockdep to find 

Re: [PATCH] LDT improvements

[Ingo Molnar]

* Andy Lutomirski  wrote:

> 
> 
> > On Dec 7, 2017, at 9:23 AM, Thomas Gleixner  wrote:
> > 
> >> On Thu, 7 Dec 2017, Andy Lutomirski wrote:
> >> 
> >>> On Thu, Dec 7, 2017 at 4:43 AM, Borislav Petkov  wrote:
>  On Wed, Dec 06, 2017 at 11:22:21PM -0800, Andy Lutomirski wrote:
>  I think I like this approach.  I also think it might be nice to move the
>  whole cpu_entry_area into this new pgd range so that we can stop mucking
>  around with the fixmap.
> >>> 
> >>> Yeah, and also, I don't like the idea of sacrificing a whole PGD
> >>> only for the LDT crap which is optional, even. Frankly - and this
> >>> is just me - I'd make CONFIG_KERNEL_PAGE_TABLE_ISOLATION xor
> >>> CONFIG_MODIFY_LDT_SYSCALL and don't give a rat's *ss about the LDT.
> >> 
> >> The PGD sacrifice doesn't bother me.  Putting a writable LDT map at a
> >> constant address does bother me.  We could probably get away with RO
> >> if we trapped and handled the nasty faults, but that could be very
> >> problematic.
> > 
> > Where is the problem? You can map it RO into user space with the USER bit
> > cleared. The kernel knows how to access the real stuff.
> 
> Blows up when the CPU tries to set the accessed bit.

BTW., could we force the accessed bit to be always set, without breaking the 
ABI?

> > The approach I've taken is to create a VMA and map it into user space with
> > the USER bit cleared. A little bit more effort code wise, but that avoids
> > all the page table muck and keeps it straight attached to the process.
> > 
> > Will post once in a bit.
> 
> I don't love mucking with user address space.  I'm also quite nervous about 
> putting it in our near anything that could pass an access_ok check, since 
> we're 
> totally screwed if the bad guys can figure out how to write to it.

Hm, robustness of the LDT address wrt. access_ok() is a valid concern.

Can we have vmas with high addresses, in the vmalloc space for example?
IIRC the GPU code has precedents in that area.

Since this is x86-64, limitation of the vmalloc() space is not an issue.

I like Thomas's solution:

 - have the LDT in a regular mmap space vma (hence per process ASLR 
randomized), 
   but with the system bit set.

 - That would be an advantage even for non-PTI kernels, because mmap() is 
probably 
   more randomized than kmalloc().

 - It would also be a cleaner approach all around, and would avoid the fixmap
   complications and the scheduler muckery.

Thanks,

Ingo

Re: [PATCH 2/2] hwmon (pmbus): cffps: Add debugfs entries

[Guenter Roeck]

On Thu, Dec 07, 2017 at 01:50:38PM -0600, Eddie James wrote:
> From: "Edward A. James" 
> 
> Add debugfs entries for additional power supply data, including part
> number, serial number, FRU number, firmware revision, ccin, and the
> input history of the power supply. The input history is 10 minutes of
> input power data in the form of twenty 30-second packets. Each packet
> contains average and maximum power for that 30 second period.
> 
> Signed-off-by: Edward A. James 
> ---
>  drivers/hwmon/pmbus/ibm-cffps.c | 199 
> +++-
>  1 file changed, 198 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hwmon/pmbus/ibm-cffps.c b/drivers/hwmon/pmbus/ibm-cffps.c
> index cb56da6..6d19399 100644
> --- a/drivers/hwmon/pmbus/ibm-cffps.c
> +++ b/drivers/hwmon/pmbus/ibm-cffps.c
> @@ -8,12 +8,26 @@
>   */
>  
>  #include 
> +#include 
>  #include 
> +#include 
>  #include 
> +#include 
>  #include 
> +#include 
>  
>  #include "pmbus.h"
>  
> +#define CFFPS_FRU_CMD0x9A
> +#define CFFPS_PN_CMD 0x9B
> +#define CFFPS_SN_CMD 0x9E
> +#define CFFPS_CCIN_CMD   0xBD
> +#define CFFPS_FW_CMD_START   0xFA
> +#define CFFPS_FW_NUM_BYTES   4
> +
> +#define CFFPS_INPUT_HISTORY_CMD  0xD6
> +#define CFFPS_INPUT_HISTORY_SIZE 100
> +
>  /* STATUS_MFR_SPECIFIC bits */
>  #define CFFPS_MFR_FAN_FAULT  BIT(0)
>  #define CFFPS_MFR_THERMAL_FAULT  BIT(1)
> @@ -24,6 +38,144 @@
>  #define CFFPS_MFR_VAUX_FAULT BIT(6)
>  #define CFFPS_MFR_CURRENT_SHARE_WARNING  BIT(7)
>  
> +enum {
> + CFFPS_DEBUGFS_INPUT_HISTORY = 0,
> + CFFPS_DEBUGFS_FRU,
> + CFFPS_DEBUGFS_PN,
> + CFFPS_DEBUGFS_SN,
> + CFFPS_DEBUGFS_CCIN,
> + CFFPS_DEBUGFS_FW,
> + CFFPS_DEBUGFS_NUM_ENTRIES
> +};
> +
> +struct ibm_cffps_input_history {
> + struct mutex update_lock;
> + unsigned long last_update;
> +
> + u8 byte_count;
> + u8 data[CFFPS_INPUT_HISTORY_SIZE];
> +};
> +
> +struct ibm_cffps {
> + struct i2c_client *client;
> +
> + struct ibm_cffps_input_history input_history;
> +
> + int debugfs_entries[CFFPS_DEBUGFS_NUM_ENTRIES];
> +};
> +
> +#define to_psu(x, y) container_of((x), struct ibm_cffps, 
> debugfs_entries[(y)])
> +
> +static ssize_t ibm_cffps_read_input_history(struct ibm_cffps *psu,
> + char __user *buf, size_t count,
> + loff_t *ppos)
> +{
> + int rc;
> + u8 msgbuf0[1] = { CFFPS_INPUT_HISTORY_CMD };
> + u8 msgbuf1[CFFPS_INPUT_HISTORY_SIZE + 1] = { 0 };
> + struct i2c_msg msg[2] = {
> + {
> + .addr = psu->client->addr,
> + .flags = psu->client->flags,
> + .len = 1,
> + .buf = msgbuf0,
> + }, {
> + .addr = psu->client->addr,
> + .flags = psu->client->flags | I2C_M_RD,
> + .len = CFFPS_INPUT_HISTORY_SIZE + 1,
> + .buf = msgbuf1,
> + },
> + };
> +
> + if (!*ppos) {
> + mutex_lock(>input_history.update_lock);
> + if (time_after(jiffies, psu->input_history.last_update + HZ)) {
> + /*
> +  * Use a raw i2c transfer, since we need more bytes
> +  * than Linux I2C supports through smbus xfr (only 32).
> +  */
> + rc = i2c_transfer(psu->client->adapter, msg, 2);
> + if (rc < 0) {
> + mutex_unlock(>input_history.update_lock);
> + return rc;
> + }
> +
> + psu->input_history.byte_count = msgbuf1[0];
> + memcpy(psu->input_history.data, [1],
> +CFFPS_INPUT_HISTORY_SIZE);
> + psu->input_history.last_update = jiffies;
> + }
> +
> + mutex_unlock(>input_history.update_lock);
> + }
> +
> + return simple_read_from_buffer(buf, count, ppos,
> +psu->input_history.data,
> +psu->input_history.byte_count);
> +}
> +
> +static ssize_t ibm_cffps_debugfs_op(struct file *file, char __user *buf,
> + size_t count, loff_t *ppos)
> +{
> + u8 cmd;
> + int i, rc;
> + int *idxp = file->private_data;
> + int idx = *idxp;
> + struct ibm_cffps *psu = to_psu(idxp, idx);
> + char data[I2C_SMBUS_BLOCK_MAX] = { 0 };
> +
> + switch (idx) {
> + case CFFPS_DEBUGFS_INPUT_HISTORY:
> + return ibm_cffps_read_input_history(psu, buf, count, ppos);
> + case CFFPS_DEBUGFS_FRU:
> +   

Re: [PATCH v2] doc: convert printk-formats.txt to rst

[Jonathan Corbet]

On Fri, 8 Dec 2017 07:44:34 +1100
"Tobin C. Harding"  wrote:

> Where is Jon's tree hosted please, I don't see it on kernel.org

>From the MAINTAINERS file:

T:  git git://git.lwn.net/linux.git docs-next

jon

Re: [PATCH 3.18 00/26] 3.18.87-stable review

[Guenter Roeck]

On Thu, Dec 07, 2017 at 01:48:13PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.87 release.
> There are 26 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sat Dec  9 12:46:34 UTC 2017.
> Anything received after that time might be too late.
> 
Build results:
total: 136 pass: 136 fail: 0
Qemu test results:
total: 112 pass: 112 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

Re: [PATCH 4.4 00/49] 4.4.105-stable review

[Guenter Roeck]

On Thu, Dec 07, 2017 at 02:06:54PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.105 release.
> There are 49 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sat Dec  9 12:46:41 UTC 2017.
> Anything received after that time might be too late.
> 

Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 116 pass: 116 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

Re: [PATCH 4.14 00/75] 4.14.5-stable review

[Guenter Roeck]

On Thu, Dec 07, 2017 at 02:07:22PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.5 release.
> There are 75 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sat Dec  9 13:07:57 UTC 2017.
> Anything received after that time might be too late.
> 

Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 124 pass: 124 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

Re: [PATCH 4.9 000/109] 4.9.68-stable review

[Guenter Roeck]

On Thu, Dec 07, 2017 at 01:55:44PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.68 release.
> There are 109 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sat Dec  9 12:56:03 UTC 2017.
> Anything received after that time might be too late.
> 

Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 124 pass: 124 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

Re: [Intel-gfx] [PATCH] kthread: finer-grained lockdep/cross-release completion

[Daniel Vetter]

On Thu, Dec 07, 2017 at 08:57:09PM +0100, Peter Zijlstra wrote:
> On Thu, Dec 07, 2017 at 03:58:28PM +0100, Daniel Vetter wrote:
> 
> > [   85.069417] gem_exec_captur/2810 is trying to acquire lock:
> > [   85.069419]  ((completion)>parked){+.+.}, at: [] 
> > kthread_park+0x3d/0x50
> > [   85.069426] 
> >but task is already holding lock:
> > [   85.069428]  (>struct_mutex){+.+.}, at: [] 
> > i915_reset_device+0x1bd/0x230 [i915]
> > [   85.069448] 
> >which lock already depends on the new lock.
> > 
> > [   85.069451] 
> >the existing dependency chain (in reverse order) is:
> > [   85.069454] 
> >-> #3 (>struct_mutex){+.+.}:
> > [   85.069460]__mutex_lock+0x81/0x9b0
> > [   85.069481]i915_mutex_lock_interruptible+0x47/0x130 [i915]
> > [   85.069502]i915_gem_fault+0x201/0x760 [i915]
> > [   85.069507]__do_fault+0x15/0x70
> > [   85.069509]__handle_mm_fault+0x7bf/0xda0
> > [   85.069512]handle_mm_fault+0x14f/0x2f0
> > [   85.069515]__do_page_fault+0x2d1/0x560
> > [   85.069518]page_fault+0x22/0x30
> > [   85.069520] 
> >-> #2 (>mmap_sem){}:
> > [   85.069525]__might_fault+0x63/0x90
> > [   85.069529]_copy_to_user+0x1e/0x70
> > [   85.069532]perf_read+0x21d/0x290
> > [   85.069534]__vfs_read+0x1e/0x120
> > [   85.069536]vfs_read+0xa1/0x150
> > [   85.069539]SyS_read+0x40/0xa0
> > [   85.069541]entry_SYSCALL_64_fastpath+0x1c/0x89
> 
> >-> #0 ((completion)>parked){+.+.}:
> 
> > [   85.069692] Chain exists of:
> >  (completion)>parked --> >mmap_sem --> 
> > >struct_mutex
> 
> > [   85.069718] 3 locks held by gem_exec_captur/2810:
> 
> > [   85.069732]  #2:  (>struct_mutex){+.+.}, at: [] 
> > i915_reset_device+0x1bd/0x230 [i915]
> 
> >stack backtrace:
> 
> > [   85.069788]  lock_acquire+0xaf/0x200
> > [   85.069793]  wait_for_common+0x54/0x210
> > [   85.069807]  kthread_park+0x3d/0x50
> > [   85.069827]  i915_gem_reset_prepare_engine+0x1d/0x90 [i915]
> > [   85.069849]  i915_gem_reset_prepare+0x2c/0x60 [i915]
> > [   85.069865]  i915_reset+0x66/0x230 [i915]
> > [   85.069881]  i915_reset_device+0x1cb/0x230 [i915]
> > [   85.069919]  i915_handle_error+0x2d3/0x430 [i915]
> > [   85.069951]  i915_wedged_set+0x79/0xc0 [i915]
> > [   85.069955]  simple_attr_write+0xab/0xc0
> > [   85.069959]  full_proxy_write+0x4b/0x70
> > [   85.069961]  __vfs_write+0x1e/0x130
> > [   85.069976]  vfs_write+0xc0/0x1b0
> > [   85.069979]  SyS_write+0x40/0xa0
> > [   85.069982]  entry_SYSCALL_64_fastpath+0x1c/0x89
> 
> 
>   Thread-Ak-Thread
> 
>   i915_reset_device
> #3  mutex_lock(>struct_mutex)
> i915_reset()
>   i915_gem_reset_prepare()
> i915_gem_reset_prepare_engine()
>   kthread_park()
> 
>   __do_page_fault()
> #2  down_read(>mmap_sem);
> handle_mm_fault()
>   __handle_mm_fault()
> __do_fault()
>   i915_gem_fault()
> 
> i915_mutex_lock_interruptible()
> #3
> mutex_lock(>struct_mutex)
> 
>   /* twiddles thumbs 
> forever more */
> 
> #0  wait_for_common()
> 
> #0complete()
> 
> 
> Is what it says I suppose. Now I don't know enough about that i915 code
> to say if that breadcrumbs_signal thread can ever trigger a fault or
> not. I got properly lost in that dma_fence callback maze.
> 
> You're saying not?

Our own kthread, no. At least a tons of run on our CI with the kthread
patch applied shut up lockdep splats for good. And since we have all the
i915 kthreads still with the same lockdep_map even with the patch applied,
since they are all created in the same function, I think that's pretty
solid evidence.

[There's also really no reasonable reason for it to fault, but I trust
automated tools more to check this stuff than my own brain. The test suite
we're running is fairly nasty and does all kinds of corner case
thrashing. Note that the dma_fence callbacks can be provideded by any
other driver (think multi-gpu desktops and stuff), but the contract is
that they must be able to handle hardirq context. Faulting's definitely
not on the table.]

The problem lockdep seems to complain about is that some random other
kthread could fault, end up in the i915 fault handler, and get stuck until
i915_reset_device is done doing what it needs to do. But as long as that
kthread is in turn not providing a service that 

Re: [PATCH] checkpatch: add check for tag Co-Developed-by

[Tobin C. Harding]

On Thu, Dec 07, 2017 at 08:26:58AM -0800, Joe Perches wrote:
> On Thu, 2017-12-07 at 11:59 +1100, Tobin C. Harding wrote:
> > Recently signature tag Co-Developed-by was added to the
> > kernel (Documentation/process/5.Posting.rst). checkpatch.pl doesn't know
> > about it yet. All prior tags used all lowercase characters except for first
> > character. Checks for this format had to be re-worked to allow for the
> > new tag.
> > 
> > Add checkpatch checks for Co-Developed-by tag.
> 
> This patch is not extensible.
> 
> If this is to be done at all, the Co-Developed-by:
> should not be a special case because a new and
> different one might be added in the future.

I agree, fixing individual corner cases is bad style.

> Better to verify that a case insensitive match exists
> in $signature_tags and then complain if the match is
> not exact.

I'll have a go at this.

thanks,
Tobin.

Re: [PATCH net-next] net: dsa: lan9303: Protect ALR operations with mutex

[Andrew Lunn]

On Thu, Dec 07, 2017 at 07:56:04PM +0100, Egil Hjelmeland wrote:
> ALR table operations are a sequence of related register operations which
> should be protected from concurrent access. The alr_cache should also be
> protected. Add alr_mutex doing that.
> 
> Signed-off-by: Egil Hjelmeland 

Reviewed-by: Andrew Lunn 

Andrew

Re: USB: hub: Delete an error message for a failed memory allocation in usb_hub_clear_tt_buffer()

[Dan Carpenter]

On Thu, Dec 07, 2017 at 10:12:27AM -0500, Alan Stern wrote:
> The real problem is that the kernel development community doesn't have
> a fixed policy on how to handle memory allocation errors.  There are
> several possibilities:
> 
>   Ignore them on the grounds that they will never happen.
>   (Really?  And what is the size limit above which they
>   might happen?)
> 

It's pretty rare to ignore allocation failures these days.  It causes
static checker warnings.

Sometimes it's accepted for people to ignore errors during boot but
I hate that because how am I supposed to filter out those static checker
warnings?  It's better to pretend that the kernel will still boot
without essential hardware instead of wasting everyone's time who looks
at checker output.

>   Ignore them on the grounds that the machine will hang or
>   crash in the near future.  (Is this guaranteed?)

On boot sometimes yes.

> 
>   Treat them like other errors: try to press forward (perhaps
>   in a degraded mode).
> 
>   Treat them like other errors: log an error message and try
>   to press forward.
> 

The standard is to treat them like errors and try press forward in a
degraded mode but don't print a message.  Checkpatch.pl complains if you
print a warning for allocation failures.  A lot of low level functions
handle their own messages pretty well but especially kmalloc() does.

I also have a special static checker warning for when people do:

foo = alloc();
BUG_ON(!foo);

People do that occasionally but fortunately it's pretty rare.  10 years
ago that's how btrfs did error handling, but now there are only 4 of
these still remaining in btrfs.

regards,
dan carpenter

Re: [patches] Re: [GIT PULL] RISC-V Cleanups and ABI Fixes for 4.15-rc2

[Palmer Dabbelt]

On Sat, 02 Dec 2017 19:20:02 PST (-0800), parri.and...@gmail.com wrote:

On Fri, Dec 01, 2017 at 01:39:12PM -0800, Palmer Dabbelt wrote:

  RISC-V: Remove smb_mb__{before,after}_spinlock()


I wonder whether you really meant to remove smp_mb__after_spinlock():
on the one hand, this primitive doesn't seem "obsolete" (as suggested
by the commit message); on the other hand, the Draft Specification at

  https://marc.info/?l=linux-kernel=151218405830993=2

suggests that you need "to strengthen" the generic implementation for
this primitive (considered the current spinlock.h in riscv).  What am
I missing?


The comment was incorrect, which caused me to incorrectly remove the fence from 
our port.  I just sent out a patch (well, actually, I did last night -- I just 
found this email sitting in a buffer...).


 https://lkml.org/lkml/2017/12/6/1136

Thanks for catching this!

Re: [PATCH AUTOSEL for 4.14 012/135] ASoC: cs42l56: Fix reset GPIO name in example DT binding

[alexander . levin]

On Thu, Dec 07, 2017 at 05:25:02PM +, Mark Brown wrote:
>On Thu, Dec 07, 2017 at 03:45:32PM +, alexander.le...@verizon.com wrote:
>
>> The binding states the reset GPIO property shall be named
>> "cirrus,gpio-nreset" and this is what the driver looks for,
>> but the example uses "gpio-reset". Fix this here.
>
>We shouldn't be getting into adding completely new DT properties in
>stable backports like this.  Old kernels have the bindings they have.

I thought that this one just adjust the example to match the code, and
doesn't actually change anything?

I was not sure how much we need it since it's not an actual code
change, but I thought that this one should go in because it does
change buggy example code in documentation that can be copy pasted
somewhere.

-- 

Thanks,
Sasha

Re: [PATCH v2 3/3] checkpatch: warn for use of %px

[Tobin C. Harding]

On Wed, Dec 06, 2017 at 02:37:08PM +1100, Tobin C. Harding wrote:
> Usage of the new %px specifier potentially leaks sensitive
> inforamtion. Printing kernel addresses exposes the kernel layout in
> memory, this is potentially exploitable. We have tools in the kernel to
> help us do the right thing. We can have checkpatch warn developers of
> potential dangers of using %px.
> 
> Have checkpatch emit a warning for usage of specifier %px.
> 
> Signed-off-by: Tobin C. Harding 
> Co-developed-by: Joe Perches 

  Co-Developed-by:

Woops.

Joe I didn't quite understand what you meant when you said that this
could go in via any tree. I'm still learning the whole kernel tree
management thing. Don't checkpatch patches go in via Andy's tree?

https://git.kernel.org/pub/scm/linux/kernel/git/apw/checkpatch.git/

In any case, please drop this set. I'll fix the tag and re-spin.

thanks,
Tobin.

> Acked-by: Joe Perches 
> ---
>  scripts/checkpatch.pl | 31 ---
>  1 file changed, 24 insertions(+), 7 deletions(-)
> 
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 4534c9a9aefa..6df99d1ebca5 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -5750,21 +5750,38 @@ sub process {
>   defined $stat &&
>   $stat =~ /^\+(?![^\{]*\{\s*).*\b(\w+)\s*\(.*$String\s*,/s &&
>   $1 !~ /^_*volatile_*$/) {
> - my $bad_extension = "";
> + my $specifier;
> + my $extension;
> + my $bad_specifier = "";
> + my $stat_real;
> +
>   my $lc = $stat =~ tr@\n@@;
>   $lc = $lc + $linenr;
>   for (my $count = $linenr; $count <= $lc; $count++) {
>   my $fmt = get_quoted_string($lines[$count - 1], 
> raw_line($count, 0));
>   $fmt =~ s/%%//g;
> - if ($fmt =~ 
> /(\%[\*\d\.]*p(?![\WFfSsBKRraEhMmIiUDdgVCbGNOx]).)/) {
> - $bad_extension = $1;
> - last;
> +
> + while ($fmt =~ /(\%[\*\d\.]*p(\w))/g) {
> + $specifier = $1;
> + $extension = $2;
> + if ($extension !~ 
> /[FfSsBKRraEhMmIiUDdgVCbGNOx]/) {
> + $bad_specifier = $specifier;
> + last;
> + }
> + if ($extension eq "x" && 
> !defined($stat_real)) {
> + if (!defined($stat_real)) {
> + $stat_real = 
> get_stat_real($linenr, $lc);
> + }
> + WARN("VSPRINTF_SPECIFIER_PX",
> +  "Using vsprintf specifier 
> '\%px' potentially exposes the kernel memory layout, if you don't really need 
> the address please consider using '\%p'.\n" . "$here\n$stat_real\n");
> + }
>   }
> +
>   }
> - if ($bad_extension ne "") {
> - my $stat_real = get_stat_real($linenr, $lc);
> + if ($bad_specifier ne "") {
> + $stat_real = get_stat_real($linenr, $lc);
>   WARN("VSPRINTF_POINTER_EXTENSION",
> -  "Invalid vsprintf pointer extension 
> '$bad_extension'\n" . "$here\n$stat_real\n");
> +  "Invalid vsprintf pointer extension 
> '$bad_specifier'\n" . "$here\n$stat_real\n");
>   }
>   }
>  
> -- 
> 2.7.4
> 

Re: [PATCH] SCSI: run queue if SCSI device queue isn't ready and queue is idle

[Bart Van Assche]

On Wed, 2017-12-06 at 00:28 +0800, Ming Lei wrote:
> On Tue, Dec 05, 2017 at 04:08:20PM +, Bart Van Assche wrote:
> > On Tue, 2017-12-05 at 15:52 +0800, Ming Lei wrote:
> > > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> > > index db9556662e27..1816dd8259b3 100644
> > > --- a/drivers/scsi/scsi_lib.c
> > > +++ b/drivers/scsi/scsi_lib.c
> > > @@ -1967,6 +1967,8 @@ static bool scsi_mq_get_budget(struct blk_mq_hw_ctx 
> > > *hctx)
> > >  out_put_device:
> > >   put_device(>sdev_gendev);
> > >  out:
> > > + if (atomic_read(>device_busy) == 0 && !scsi_device_blocked(sdev))
> > > + blk_mq_delay_run_hw_queue(hctx, SCSI_QUEUE_DELAY);
> > >   return false;
> > >  }
> > 
> > This cannot work since multiple threads can call scsi_mq_get_budget()
> 
> That is exactly the way we are handling these cases before 0df21c86bdbf(scsi:
> implement .get_budget and .put_budget for blk-mq), so if it can't work,
> that is not fault of commit 0df21c86bdbf.
> 
> > concurrently and hence it can happen that none of them sees
> > atomic_read(>device_busy) == 0. BTW, the above patch is something I
> 
> If there is concurrent .get_budget(), one of them will see the counter
> becoming zero finally because each sdev->device_busy is inc/dec
> atomically. Or scsi_dev_queue_ready() return true.
> 
> Anyway, we need this patch to avoid possible regression. If you think
> there are bugs in blk-mq RESTART, just root cause and and fix it.

Hello Ming,

When I looked at the patch at the start of this thread for the first time I
got frustrated because I didn't see how this patch could fix the queue stall
I ran into myself. Today I started realizing that what Holger reported is
probably another issue than what I ran into myself. Since this patch by
itself looks now useful to me:

Reviewed-by: Bart Van Assche 

BTW, do you think the patch at the start of this thread also fixes the issue
that resulted in commit 826a70a08b12 ("SCSI: don't get target/host busy_count
in scsi_mq_get_budget()")? Do you think we still need that patch?

Bart.

[PATCH] mux: add SPDX identifiers to all mux source files

[Peter Rosin]

Remove all free-text license texts.

This is done on a quest to remove the 700+ different ways that files in
the kernel describe the GPL license text.

No copyright headers or other non-license-description text was removed.

Signed-off-by: Peter Rosin 
---

Hi Philipp,

I assume this is ok with you for the mmio file, but asking just in case...

Cheers,
Peter

 drivers/mux/Kconfig  | 1 +
 drivers/mux/Makefile | 1 +
 drivers/mux/adg792a.c| 5 +
 drivers/mux/core.c   | 5 +
 drivers/mux/gpio.c   | 5 +
 drivers/mux/mmio.c   | 5 +
 include/linux/mux/consumer.h | 5 +
 include/linux/mux/driver.h   | 5 +
 8 files changed, 8 insertions(+), 24 deletions(-)

diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
index 19e4e904c9bf..6241678e99af 100644
--- a/drivers/mux/Kconfig
+++ b/drivers/mux/Kconfig
@@ -1,3 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
 #
 # Multiplexer devices
 #
diff --git a/drivers/mux/Makefile b/drivers/mux/Makefile
index 0e1e59760e3f..c3d883955fd5 100644
--- a/drivers/mux/Makefile
+++ b/drivers/mux/Makefile
@@ -1,3 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
 #
 # Makefile for multiplexer devices.
 #
diff --git a/drivers/mux/adg792a.c b/drivers/mux/adg792a.c
index 12aa221ab90d..6a8725cf3d71 100644
--- a/drivers/mux/adg792a.c
+++ b/drivers/mux/adg792a.c
@@ -1,13 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * Multiplexer driver for Analog Devices ADG792A/G Triple 4:1 mux
  *
  * Copyright (C) 2017 Axentia Technologies AB
  *
  * Author: Peter Rosin 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
  */
 
 #include 
diff --git a/drivers/mux/core.c b/drivers/mux/core.c
index 2260063b0ea8..959d22aaa063 100644
--- a/drivers/mux/core.c
+++ b/drivers/mux/core.c
@@ -1,13 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * Multiplexer subsystem
  *
  * Copyright (C) 2017 Axentia Technologies AB
  *
  * Author: Peter Rosin 
- *
- * 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.
  */
 
 #define pr_fmt(fmt) "mux-core: " fmt
diff --git a/drivers/mux/gpio.c b/drivers/mux/gpio.c
index 468bf1709606..6fdd9316db8b 100644
--- a/drivers/mux/gpio.c
+++ b/drivers/mux/gpio.c
@@ -1,13 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * GPIO-controlled multiplexer driver
  *
  * Copyright (C) 2017 Axentia Technologies AB
  *
  * Author: Peter Rosin 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
  */
 
 #include 
diff --git a/drivers/mux/mmio.c b/drivers/mux/mmio.c
index 37c1de359a70..935ac44aa209 100644
--- a/drivers/mux/mmio.c
+++ b/drivers/mux/mmio.c
@@ -1,11 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * MMIO register bitfield-controlled multiplexer driver
  *
  * Copyright (C) 2017 Pengutronix, Philipp Zabel 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
  */
 
 #include 
diff --git a/include/linux/mux/consumer.h b/include/linux/mux/consumer.h
index ea96d4c82be7..5fc6bb2fefad 100644
--- a/include/linux/mux/consumer.h
+++ b/include/linux/mux/consumer.h
@@ -1,13 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0 */
 /*
  * mux/consumer.h - definitions for the multiplexer consumer interface
  *
  * Copyright (C) 2017 Axentia Technologies AB
  *
  * Author: Peter Rosin 
- *
- * 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.
  */
 
 #ifndef _LINUX_MUX_CONSUMER_H
diff --git a/include/linux/mux/driver.h b/include/linux/mux/driver.h
index 35c3579c3304..627a2c6bc02d 100644
--- a/include/linux/mux/driver.h
+++ b/include/linux/mux/driver.h
@@ -1,13 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0 */
 /*
  * mux/driver.h - definitions for the multiplexer driver interface
  *
  * Copyright (C) 2017 Axentia Technologies AB
  *
  * Author: Peter Rosin 
- *
- * 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.
  */
 
 #ifndef _LINUX_MUX_DRIVER_H
-- 
2.11.0

[PATCH V7 4/7] OF: properties: Implement get_match_data() callback

[Sinan Kaya]

Now that we have a get_match_data() callback as part of the firmware node,
implement the OF specific piece for it.

Signed-off-by: Sinan Kaya 
Reviewed-by: Rob Herring 
Acked-by: Sakari Ailus 
---
 drivers/of/property.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/of/property.c b/drivers/of/property.c
index 264c355..543e059 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -981,10 +981,18 @@ static int of_fwnode_graph_parse_endpoint(const struct 
fwnode_handle *fwnode,
return 0;
 }
 
+static void *
+of_fwnode_device_get_match_data(const struct fwnode_handle *fwnode,
+   const struct device *dev)
+{
+   return (void *)of_device_get_match_data(dev);
+}
+
 const struct fwnode_operations of_fwnode_ops = {
.get = of_fwnode_get,
.put = of_fwnode_put,
.device_is_available = of_fwnode_device_is_available,
+   .device_get_match_data = of_fwnode_device_get_match_data,
.property_present = of_fwnode_property_present,
.property_read_int_array = of_fwnode_property_read_int_array,
.property_read_string_array = of_fwnode_property_read_string_array,
-- 
1.9.1

[PATCH V7 7/7] dmaengine: qcom_hidma: Add identity register support

[Sinan Kaya]

The location for destination event channel register has been relocated from
offset 0x28 to 0x40. Update the code accordingly.

Signed-off-by: Sinan Kaya 
---
 drivers/dma/qcom/hidma.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index c146c6d..963cc52 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -107,6 +107,7 @@ static void hidma_free(struct hidma_dev *dmadev)
 
 enum hidma_cap {
HIDMA_MSI_CAP = 1,
+   HIDMA_IDENTITY_CAP,
 };
 
 /* process completed descriptors */
@@ -838,7 +839,10 @@ static int hidma_probe(struct platform_device *pdev)
if (!dmadev->nr_descriptors)
dmadev->nr_descriptors = HIDMA_NR_DEFAULT_DESC;
 
-   dmadev->chidx = readl(dmadev->dev_trca + 0x28);
+   if (hidma_test_capability(>dev, HIDMA_IDENTITY_CAP))
+   dmadev->chidx = readl(dmadev->dev_trca + 0x40);
+   else
+   dmadev->chidx = readl(dmadev->dev_trca + 0x28);
 
/* Set DMA mask to 64 bits. */
rc = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(64));
@@ -944,7 +948,7 @@ static int hidma_remove(struct platform_device *pdev)
 static const struct acpi_device_id hidma_acpi_ids[] = {
{"QCOM8061"},
{"QCOM8062", HIDMA_MSI_CAP},
-   {"QCOM8063", HIDMA_MSI_CAP},
+   {"QCOM8063", (HIDMA_MSI_CAP | HIDMA_IDENTITY_CAP)},
{},
 };
 MODULE_DEVICE_TABLE(acpi, hidma_acpi_ids);
@@ -953,7 +957,8 @@ static int hidma_remove(struct platform_device *pdev)
 static const struct of_device_id hidma_match[] = {
{.compatible = "qcom,hidma-1.0",},
{.compatible = "qcom,hidma-1.1", .data = (void *)(HIDMA_MSI_CAP),},
-   {.compatible = "qcom,hidma-1.2", .data = (void *)(HIDMA_MSI_CAP),},
+   {.compatible = "qcom,hidma-1.2",
+.data = (void *)(HIDMA_MSI_CAP | HIDMA_IDENTITY_CAP),},
{},
 };
 MODULE_DEVICE_TABLE(of, hidma_match);
-- 
1.9.1

Re: linux-next: build failure after merge of the scsi-mkp tree

[Paul E. McKenney]

On Fri, Dec 08, 2017 at 07:34:39AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> On Thu, 7 Dec 2017 09:40:38 -0800 "Paul E. McKenney" 
>  wrote:
> >
> > On Thu, Dec 07, 2017 at 05:30:03PM +, Bart Van Assche wrote:
> > > However, what's not clear to me is through which tree this patch should be
> > > sent to Linus? Should the above patch be sent as a v4.15-rc fix or should
> > > Martin perhaps queue it in his tree for v4.16-rc1?  
> > 
> > I have to defer to you guys on that one.  Left to myself, I will just
> > push it into the next merge window (as opposed to using my normal process,
> > which at this point would get it into the one following).
> > 
> > So please let me know how you would like to proceed.
> 
> Clearly, it needs to go via Martin's tree as otherwise his tree will
> not build in some circumstances ... or if it going to cause problems
> for Paul, then it should be in a separate non-rebasing branch (probably
> of Paul's tree) that is merged into Pauls main branch and Marin's tree.

It is unlikely to cause problems, so please let it go up where convenient.

Just please let me know.

Thanx, Paul

[PATCH V7 3/7] device property: Introduce a common API to fetch device match data

[Sinan Kaya]

There is an OF/ACPI function to obtain the driver data. We want to hide
OF/ACPI details from the device drivers and abstract following the device
family of functions.

Signed-off-by: Sinan Kaya 
Reviewed-by: Rob Herring 
Acked-by: Sakari Ailus 
---
 drivers/base/property.c  | 7 +++
 include/linux/fwnode.h   | 4 
 include/linux/property.h | 2 ++
 3 files changed, 13 insertions(+)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index 7ed99c1..ee704a8 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -1335,3 +1335,10 @@ int fwnode_graph_parse_endpoint(const struct 
fwnode_handle *fwnode,
return fwnode_call_int_op(fwnode, graph_parse_endpoint, endpoint);
 }
 EXPORT_SYMBOL(fwnode_graph_parse_endpoint);
+
+void *device_get_match_data(struct device *dev)
+{
+   return fwnode_call_ptr_op(dev_fwnode(dev), device_get_match_data,
+ dev);
+}
+EXPORT_SYMBOL_GPL(device_get_match_data);
diff --git a/include/linux/fwnode.h b/include/linux/fwnode.h
index 0c35b6c..e2b4b22 100644
--- a/include/linux/fwnode.h
+++ b/include/linux/fwnode.h
@@ -15,6 +15,7 @@
 #include 
 
 struct fwnode_operations;
+struct device;
 
 struct fwnode_handle {
struct fwnode_handle *secondary;
@@ -51,6 +52,7 @@ struct fwnode_reference_args {
  * struct fwnode_operations - Operations for fwnode interface
  * @get: Get a reference to an fwnode.
  * @put: Put a reference to an fwnode.
+ * @device_get_match_data: Return the device driver match data.
  * @property_present: Return true if a property is present.
  * @property_read_integer_array: Read an array of integer properties. Return
  *  zero on success, a negative error code
@@ -71,6 +73,8 @@ struct fwnode_operations {
void (*get)(struct fwnode_handle *fwnode);
void (*put)(struct fwnode_handle *fwnode);
bool (*device_is_available)(const struct fwnode_handle *fwnode);
+   void *(*device_get_match_data)(const struct fwnode_handle *fwnode,
+  const struct device *dev);
bool (*property_present)(const struct fwnode_handle *fwnode,
 const char *propname);
int (*property_read_int_array)(const struct fwnode_handle *fwnode,
diff --git a/include/linux/property.h b/include/linux/property.h
index 6bebee1..01fa55b 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -275,6 +275,8 @@ int device_add_properties(struct device *dev,
 
 enum dev_dma_attr device_get_dma_attr(struct device *dev);
 
+void *device_get_match_data(struct device *dev);
+
 int device_get_phy_mode(struct device *dev);
 
 void *device_get_mac_address(struct device *dev, char *addr, int alen);
-- 
1.9.1

[PATCH V7 2/7] ACPI / bus: Introduce acpi_get_match_data() function

[Sinan Kaya]

OF has of_device_get_match_data() function to extract driver specific data
structure. Add a similar function for ACPI.

Signed-off-by: Sinan Kaya 
---
 drivers/acpi/bus.c   | 18 ++
 include/linux/acpi.h |  6 ++
 2 files changed, 24 insertions(+)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 4d0979e..f87ed3b 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -785,6 +785,24 @@ const struct acpi_device_id *acpi_match_device(const 
struct acpi_device_id *ids,
 }
 EXPORT_SYMBOL_GPL(acpi_match_device);
 
+void *acpi_get_match_data(const struct device *dev)
+{
+   const struct acpi_device_id *match;
+
+   if (!dev->driver)
+   return NULL;
+
+   if (!dev->driver->acpi_match_table)
+   return NULL;
+
+   match = acpi_match_device(dev->driver->acpi_match_table, dev);
+   if (!match)
+   return NULL;
+
+   return (void *)match->driver_data;
+}
+EXPORT_SYMBOL_GPL(acpi_get_match_data);
+
 int acpi_match_device_ids(struct acpi_device *device,
  const struct acpi_device_id *ids)
 {
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 502af53..a927260 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -584,6 +584,7 @@ extern int acpi_nvs_for_each_region(int (*func)(__u64, 
__u64, void *),
 const struct acpi_device_id *acpi_match_device(const struct acpi_device_id 
*ids,
   const struct device *dev);
 
+void *acpi_get_match_data(const struct device *dev);
 extern bool acpi_driver_match_device(struct device *dev,
 const struct device_driver *drv);
 int acpi_device_uevent_modalias(struct device *, struct kobj_uevent_env *);
@@ -755,6 +756,11 @@ static inline const struct acpi_device_id 
*acpi_match_device(
return NULL;
 }
 
+static inline void *acpi_get_match_data(const struct device *dev)
+{
+   return NULL;
+}
+
 static inline bool acpi_driver_match_device(struct device *dev,
const struct device_driver *drv)
 {
-- 
1.9.1

[PATCH V7 6/7] dmaengine: qcom_hidma: Add support for the new revision

[Sinan Kaya]

Add support for probing the newer HW and also organize MSI capable hardware
into an array for maintenance reasons.

Signed-off-by: Sinan Kaya 
---
 drivers/dma/qcom/hidma.c | 34 +-
 1 file changed, 13 insertions(+), 21 deletions(-)

diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index e366985..c146c6d 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -50,6 +50,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -104,6 +105,9 @@ static void hidma_free(struct hidma_dev *dmadev)
 module_param(nr_desc_prm, uint, 0644);
 MODULE_PARM_DESC(nr_desc_prm, "number of descriptors (default: 0)");
 
+enum hidma_cap {
+   HIDMA_MSI_CAP = 1,
+};
 
 /* process completed descriptors */
 static void hidma_process_completed(struct hidma_chan *mchan)
@@ -736,25 +740,12 @@ static int hidma_request_msi(struct hidma_dev *dmadev,
 #endif
 }
 
-static bool hidma_msi_capable(struct device *dev)
+static bool hidma_test_capability(struct device *dev, enum hidma_cap test_cap)
 {
-   struct acpi_device *adev = ACPI_COMPANION(dev);
-   const char *of_compat;
-   int ret = -EINVAL;
-
-   if (!adev || acpi_disabled) {
-   ret = device_property_read_string(dev, "compatible",
- _compat);
-   if (ret)
-   return false;
+   enum hidma_cap cap;
 
-   ret = strcmp(of_compat, "qcom,hidma-1.1");
-   } else {
-#ifdef CONFIG_ACPI
-   ret = strcmp(acpi_device_hid(adev), "QCOM8062");
-#endif
-   }
-   return ret == 0;
+   cap = (enum hidma_cap) device_get_match_data(dev);
+   return cap ? ((cap & test_cap) > 0) : 0;
 }
 
 static int hidma_probe(struct platform_device *pdev)
@@ -834,8 +825,7 @@ static int hidma_probe(struct platform_device *pdev)
 * Determine the MSI capability of the platform. Old HW doesn't
 * support MSI.
 */
-   msi = hidma_msi_capable(>dev);
-
+   msi = hidma_test_capability(>dev, HIDMA_MSI_CAP);
device_property_read_u32(>dev, "desc-count",
 >nr_descriptors);
 
@@ -953,7 +943,8 @@ static int hidma_remove(struct platform_device *pdev)
 #if IS_ENABLED(CONFIG_ACPI)
 static const struct acpi_device_id hidma_acpi_ids[] = {
{"QCOM8061"},
-   {"QCOM8062"},
+   {"QCOM8062", HIDMA_MSI_CAP},
+   {"QCOM8063", HIDMA_MSI_CAP},
{},
 };
 MODULE_DEVICE_TABLE(acpi, hidma_acpi_ids);
@@ -961,7 +952,8 @@ static int hidma_remove(struct platform_device *pdev)
 
 static const struct of_device_id hidma_match[] = {
{.compatible = "qcom,hidma-1.0",},
-   {.compatible = "qcom,hidma-1.1",},
+   {.compatible = "qcom,hidma-1.1", .data = (void *)(HIDMA_MSI_CAP),},
+   {.compatible = "qcom,hidma-1.2", .data = (void *)(HIDMA_MSI_CAP),},
{},
 };
 MODULE_DEVICE_TABLE(of, hidma_match);
-- 
1.9.1

[PATCH V7 5/7] ACPI: properties: Implement get_match_data() callback

[Sinan Kaya]

Now that we have a get_match_data() callback as part of the firmware node,
implement the ACPI specific piece for it.

Signed-off-by: Sinan Kaya 
Acked-by: Sakari Ailus 
---
 drivers/acpi/property.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
index e26ea20..466d150 100644
--- a/drivers/acpi/property.c
+++ b/drivers/acpi/property.c
@@ -1271,9 +1271,17 @@ static int acpi_fwnode_graph_parse_endpoint(const struct 
fwnode_handle *fwnode,
return 0;
 }
 
+static void *
+acpi_fwnode_device_get_match_data(const struct fwnode_handle *fwnode,
+ const struct device *dev)
+{
+   return acpi_get_match_data(dev);
+}
+
 #define DECLARE_ACPI_FWNODE_OPS(ops) \
const struct fwnode_operations ops = {  \
.device_is_available = acpi_fwnode_device_is_available, \
+   .device_get_match_data = acpi_fwnode_device_get_match_data, \
.property_present = acpi_fwnode_property_present,   \
.property_read_int_array =  \
acpi_fwnode_property_read_int_array,\
-- 
1.9.1

Re: [PATCH] SCSI: run queue if SCSI device queue isn't ready and queue is idle

[Bart Van Assche]

On Thu, 2017-12-07 at 09:31 +0800, Ming Lei wrote:
> But if you always call blk_mq_sched_mark_restart_hctx() before a new
> dispatch, that may affect performance on NVMe which may never trigger
> BLK_STS_RESOURCE.

Hmm ... only the SCSI core implements .get_budget() and .put_budget() and
I proposed to insert a blk_mq_sched_mark_restart_hctx() call under "if
(q->mq_ops->get_budget)". In other words, I proposed to insert a
blk_mq_sched_mark_restart_hctx() call in a code path that is never triggered
by the NVMe driver. So I don't see how the change I proposed could affect
the performance of the NVMe driver?

Bart.

[PATCH V7 1/7] Documentation: DT: qcom_hidma: Bump HW revision for the bugfixed HW

[Sinan Kaya]

A new version of the HIDMA IP has been released with bug fixes. Bumping the
hardware version to differentiate from others.

Signed-off-by: Sinan Kaya 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt 
b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
index 55492c2..5d93d6d 100644
--- a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
@@ -47,8 +47,8 @@ When the OS is not in control of the management interface 
(i.e. it's a guest),
 the channel nodes appear on their own, not under a management node.
 
 Required properties:
-- compatible: must contain "qcom,hidma-1.0" for initial HW or "qcom,hidma-1.1"
-for MSI capable HW.
+- compatible: must contain "qcom,hidma-1.0" for initial HW or
+  "qcom,hidma-1.1"/"qcom,hidma-1.2" for MSI capable HW.
 - reg: Addresses for the transfer and event channel
 - interrupts: Should contain the event interrupt
 - desc-count: Number of asynchronous requests this channel can handle
-- 
1.9.1

[PATCH] staging: pi433: Add spaces around & and + operator

[Simon Sandström]

Fixes checkpatch warning: "spaces preferred around that '&'".

Signed-off-by: Simon Sandström 
---
 drivers/staging/pi433/rf69.c | 29 ++---
 1 file changed, 14 insertions(+), 15 deletions(-)

diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
index 7140fa2ea592..33a01318e840 100644
--- a/drivers/staging/pi433/rf69.c
+++ b/drivers/staging/pi433/rf69.c
@@ -82,7 +82,6 @@ int rf69_set_mode(struct spi_device *spi, enum mode mode)
// we are using packet mode, so this check is not really needed
// but waiting for mode ready is necessary when going from sleep 
because the FIFO may not be immediately available from previous mode
//while (_mode == RF69_MODE_SLEEP && (READ_REG(REG_IRQFLAGS1) & 
RF_IRQFLAGS1_MODEREADY) == 0x00); // Wait for ModeReady
-
 }
 
 int rf69_set_data_mode(struct spi_device *spi, u8 data_mode)
@@ -173,8 +172,8 @@ int rf69_set_bit_rate(struct spi_device *spi, u16 bitRate)
// calculate reg settings
bitRate_reg = (F_OSC / bitRate);
 
-   msb = (bitRate_reg&0xff00)   >>  8;
-   lsb = (bitRate_reg&0xff);
+   msb = (bitRate_reg & 0xff00) >> 8;
+   lsb = (bitRate_reg & 0xff);
 
// transmit to RF 69
retval = rf69_write_reg(spi, REG_BITRATE_MSB, msb);
@@ -214,8 +213,8 @@ int rf69_set_deviation(struct spi_device *spi, u32 
deviation)
f_reg = deviation * factor;
do_div(f_reg, f_step);
 
-   msb = (f_reg&0xff00)   >>  8;
-   lsb = (f_reg&0xff);
+   msb = (f_reg & 0xff00) >> 8;
+   lsb = (f_reg & 0xff);
 
// check msb
if (msb & ~FDEVMASB_MASK) {
@@ -264,9 +263,9 @@ int rf69_set_frequency(struct spi_device *spi, u32 
frequency)
f_reg = frequency * factor;
do_div(f_reg, f_step);
 
-   msb = (f_reg&0xff) >> 16;
-   mid = (f_reg&0xff00)   >>  8;
-   lsb = (f_reg&0xff);
+   msb = (f_reg & 0xff) >> 16;
+   mid = (f_reg & 0xff00)   >>  8;
+   lsb = (f_reg & 0xff);
 
// write to chip
retval = rf69_write_reg(spi, REG_FRF_MSB, msb);
@@ -685,8 +684,8 @@ int rf69_set_preamble_length(struct spi_device *spi, u16 
preambleLength)
/* no value check needed - u16 exactly matches register size */
 
/* calculate reg settings */
-   msb = (preambleLength&0xff00)   >>  8;
-   lsb = (preambleLength&0xff);
+   msb = (preambleLength & 0xff00) >> 8;
+   lsb = (preambleLength & 0xff);
 
/* transmit to chip */
retval = rf69_write_reg(spi, REG_PREAMBLE_MSB, msb);
@@ -930,14 +929,14 @@ int rf69_read_fifo (struct spi_device *spi, u8 *buffer, 
unsigned int size)
memset(, 0, sizeof(transfer));
transfer.tx_buf = local_buffer;
transfer.rx_buf = local_buffer;
-   transfer.len= size+1;
+   transfer.len= size + 1;
 
retval = spi_sync_transfer(spi, , 1);
 
-   #ifdef DEBUG_FIFO_ACCESS
-   for (i = 0; i < size; i++)
-   dev_dbg(>dev, "%d - 0x%x\n", i, local_buffer[i+1]);
-   #endif
+#ifdef DEBUG_FIFO_ACCESS
+   for (i = 0; i < size; i++)
+   dev_dbg(>dev, "%d - 0x%x\n", i, local_buffer[i + 1]);
+#endif
 
memcpy(buffer, _buffer[1], size);  // TODO: ohne memcopy w�re 
sch�ner
 
-- 
2.11.0

Re: linux-next: build failure after merge of the scsi-mkp tree

[Martin K. Petersen]

Stephen,

>> I have to defer to you guys on that one.  Left to myself, I will just
>> push it into the next merge window (as opposed to using my normal
>> process, which at this point would get it into the one following).
>> 
>> So please let me know how you would like to proceed.
>
> Clearly, it needs to go via Martin's tree as otherwise his tree will
> not build in some circumstances ... or if it going to cause problems
> for Paul, then it should be in a separate non-rebasing branch (probably
> of Paul's tree) that is merged into Pauls main branch and Marin's tree.

I'm perfectly OK with taking it through the SCSI tree. Probably the path
of least resistance.

-- 
Martin K. Petersen  Oracle Linux Engineering

[PATCH 0/4] USB over IP Secuurity fixes

[Shuah Khan]

Jakub Jirasek from Secunia Research at Flexera reported security
vulnerabilities in the USB over IP driver. This patch series all
the 4 reported problems.

Jakub, could you please suggest an email address I can use for the
Reported-by tag?

Shuah Khan (4):
  usbip: fix stub_rx: get_pipe() to validate endpoint number
  usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input
  usbip: prevent vhci_hcd driver from leaking a socket pointer address
  usbip: fix stub_send_ret_submit() vulnerability to null
transfer_buffer

 drivers/usb/usbip/stub_rx.c  | 51 +---
 drivers/usb/usbip/stub_tx.c  |  7 +
 drivers/usb/usbip/usbip_common.h |  1 +
 drivers/usb/usbip/vhci_sysfs.c   | 25 +++---
 tools/usb/usbip/libsrc/vhci_driver.c |  8 +++---
 5 files changed, 69 insertions(+), 23 deletions(-)

-- 
2.14.1

[PATCH 3/4] usbip: prevent vhci_hcd driver from leaking a socket pointer address

[Shuah Khan]

When a client has a USB device attached over IP, the vhci_hcd driver is
locally leaking a socket pointer address via the

/sys/devices/platform/vhci_hcd/status file (world-readable) and in debug
output when "usbip --debug port" is run.

Fix it to not leak. The socket pointer address is not used at the moment
and it was made visible as a convenient way to find IP address from socket
pointer address by looking up /proc/net/{tcp,tcp6}.

As this opens a security hole, the fix replaces socket pointer address with
sockfd.

Signed-off-by: Shuah Khan 
---
 drivers/usb/usbip/usbip_common.h |  1 +
 drivers/usb/usbip/vhci_sysfs.c   | 25 -
 tools/usb/usbip/libsrc/vhci_driver.c |  8 
 3 files changed, 21 insertions(+), 13 deletions(-)

diff --git a/drivers/usb/usbip/usbip_common.h b/drivers/usb/usbip/usbip_common.h
index e5de35c8c505..473fb8a87289 100644
--- a/drivers/usb/usbip/usbip_common.h
+++ b/drivers/usb/usbip/usbip_common.h
@@ -256,6 +256,7 @@ struct usbip_device {
/* lock for status */
spinlock_t lock;
 
+   int sockfd;
struct socket *tcp_socket;
 
struct task_struct *tcp_rx;
diff --git a/drivers/usb/usbip/vhci_sysfs.c b/drivers/usb/usbip/vhci_sysfs.c
index e78f7472cac4..091f76b7196d 100644
--- a/drivers/usb/usbip/vhci_sysfs.c
+++ b/drivers/usb/usbip/vhci_sysfs.c
@@ -17,15 +17,20 @@
 
 /*
  * output example:
- * hub port sta spd dev  socket   local_busid
- * hs   004 000  c5a7bb80 1-2.3
+ * hub port sta spd dev   sockfdlocal_busid
+ * hs   004 000   3 1-2.3
  * 
- * ss  0008 004 000  d8cee980 2-3.4
+ * ss  0008 004 000   4 2-3.4
  * 
  *
- * IP address can be retrieved from a socket pointer address by looking
- * up /proc/net/{tcp,tcp6}. Also, a userland program may remember a
- * port number and its peer IP address.
+ * Output includes socket fd instead of socket pointer address to avoid
+ * leaking kernel memory address in:
+ * /sys/devices/platform/vhci_hcd.0/status and in debug output.
+ * The socket pointer address is not used at the moment and it was made
+ * visible as a convenient way to find IP address from socket pointer
+ * address by looking up /proc/net/{tcp,tcp6}. As this opens a security
+ * hole, the change is made to use sockfd instead.
+ *
  */
 static void port_show_vhci(char **out, int hub, int port, struct vhci_device 
*vdev)
 {
@@ -39,8 +44,8 @@ static void port_show_vhci(char **out, int hub, int port, 
struct vhci_device *vd
if (vdev->ud.status == VDEV_ST_USED) {
*out += sprintf(*out, "%03u %08x ",
  vdev->speed, vdev->devid);
-   *out += sprintf(*out, "%16p %s",
- vdev->ud.tcp_socket,
+   *out += sprintf(*out, "%u %s",
+ vdev->ud.sockfd,
  dev_name(>udev->dev));
 
} else {
@@ -160,7 +165,8 @@ static ssize_t nports_show(struct device *dev, struct 
device_attribute *attr,
char *s = out;
 
/*
-* Half the ports are for SPEED_HIGH and half for SPEED_SUPER, thus the 
* 2.
+* Half the ports are for SPEED_HIGH and half for SPEED_SUPER,
+* thus the * 2.
 */
out += sprintf(out, "%d\n", VHCI_PORTS * vhci_num_controllers);
return out - s;
@@ -366,6 +372,7 @@ static ssize_t store_attach(struct device *dev, struct 
device_attribute *attr,
 
vdev->devid = devid;
vdev->speed = speed;
+   vdev->ud.sockfd = sockfd;
vdev->ud.tcp_socket = socket;
vdev->ud.status = VDEV_ST_NOTASSIGNED;
 
diff --git a/tools/usb/usbip/libsrc/vhci_driver.c 
b/tools/usb/usbip/libsrc/vhci_driver.c
index 8a1cd1616de4..d1fc0f9f00fb 100644
--- a/tools/usb/usbip/libsrc/vhci_driver.c
+++ b/tools/usb/usbip/libsrc/vhci_driver.c
@@ -50,14 +50,14 @@ static int parse_status(const char *value)
 
while (*c != '\0') {
int port, status, speed, devid;
-   unsigned long socket;
+   int sockfd;
char lbusid[SYSFS_BUS_ID_SIZE];
struct usbip_imported_device *idev;
char hub[3];
 
-   ret = sscanf(c, "%2s  %d %d %d %x %lx %31s\n",
+   ret = sscanf(c, "%2s  %d %d %d %x %u %31s\n",
hub, , , ,
-   , , lbusid);
+   , , lbusid);
 
if (ret < 5) {
dbg("sscanf failed: %d", ret);
@@ -66,7 +66,7 @@ static int parse_status(const char *value)
 
dbg("hub %s port %d status %d speed %d devid %x",
hub, port, status, speed, devid);
-   dbg("socket %lx lbusid 

Re: [PATCH v2 3/3] checkpatch: warn for use of %px

[Tobin C. Harding]

On Fri, Dec 08, 2017 at 08:06:53AM +1100, Tobin C. Harding wrote:
> On Wed, Dec 06, 2017 at 02:37:08PM +1100, Tobin C. Harding wrote:
> > Usage of the new %px specifier potentially leaks sensitive
> > inforamtion. Printing kernel addresses exposes the kernel layout in
> > memory, this is potentially exploitable. We have tools in the kernel to
> > help us do the right thing. We can have checkpatch warn developers of
> > potential dangers of using %px.
> > 
> > Have checkpatch emit a warning for usage of specifier %px.
> > 
> > Signed-off-by: Tobin C. Harding 
> > Co-developed-by: Joe Perches 
> 
>   Co-Developed-by:
> 
> Woops.
> 
> Joe I didn't quite understand what you meant when you said that this
> could go in via any tree. I'm still learning the whole kernel tree
> management thing. Don't checkpatch patches go in via Andy's tree?
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/apw/checkpatch.git/

Oh, I see that tree is not super active. If there are no NACK's do you
want me to put this through my tree? Perhaps once the Co-Developed-by
stuff is in an acceptable form we could put them all together? Please do
say if I'm going about things wrong, here to learn.

thanks,
Tobin.

[PATCH 0/2] tty/serial/sccnxp: Adjustments for sccnxp_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 7 Dec 2017 22:14:32 +0100

Two update suggestions were taken into account
from static source code analysis.

Markus Elfring (2):
  Delete an error message for a failed memory allocation
  Improve a size determination

 drivers/tty/serial/sccnxp.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

-- 
2.15.1

Re: [PATCH] PM / sleep: Avoid excess pm_runtime_enable() calls in device_resume()

[Rafael J. Wysocki]

On Thu, Dec 7, 2017 at 8:44 PM, Ulf Hansson  wrote:
> On 7 December 2017 at 03:26, Rafael J. Wysocki  wrote:
>> From: Rafael J. Wysocki 
>>
>> Middle-layer code doing suspend-time optimizations for devices with
>> the DPM_FLAG_SMART_SUSPEND flag set (currently, the PCI bus type and
>> the ACPI PM domain) needs to make the core skip ->thaw_early and
>> ->thaw callbacks for those devices in some cases and it sets the
>> power.direct_complete flag for them for this purpose.
>>
>> However, it turns out that setting power.direct_complete outside of
>> the PM core is a bad idea as it triggers an excessive invocation of
>> pm_runtime_enable() in device_resume().
>
> Do we need to clarify the comment about the flag in pm.h?
>
> Or is "/* Owned by the PM core */" sufficient?

That should be sufficient (and I sort of tried to ignore it ...).

>>
>> For this reason, provide a helper to clear power.is_late_suspended
>> and power.is_suspended to be invoked by the middle-layer code in
>> question instead of setting power.direct_complete and make that code
>> call the new helper.
>>
>> Fixes: c4b65157aeef (PCI / PM: Take SMART_SUSPEND driver flag into account)
>> Fixes: 05087360fd7a (ACPI / PM: Take SMART_SUSPEND driver flag into account)
>> Signed-off-by: Rafael J. Wysocki 
>
> Reviewed-by: Ulf Hansson 

Thanks!

[PATCH 2/4] usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input

[Shuah Khan]

Harden CMD_SUBMIT path to handle malicious input that could trigger
large memory allocations. Add checks to validate transfer_buffer_length
and number_of_packets to protect against bad input requesting for
unbounded memory allocations. Validate early in get_pipe() and return
failure.

Signed-off-by: Shuah Khan 
---
 drivers/usb/usbip/stub_rx.c | 35 +++
 1 file changed, 31 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/usbip/stub_rx.c b/drivers/usb/usbip/stub_rx.c
index 4d61063c259d..493ac2928391 100644
--- a/drivers/usb/usbip/stub_rx.c
+++ b/drivers/usb/usbip/stub_rx.c
@@ -322,11 +322,13 @@ static struct stub_priv *stub_priv_alloc(struct 
stub_device *sdev,
return priv;
 }
 
-static int get_pipe(struct stub_device *sdev, int epnum, int dir)
+static int get_pipe(struct stub_device *sdev, struct usbip_header *pdu)
 {
struct usb_device *udev = sdev->udev;
struct usb_host_endpoint *ep;
struct usb_endpoint_descriptor *epd = NULL;
+   int epnum = pdu->base.ep;
+   int dir = pdu->base.direction;
 
if (epnum < 0 || epnum > 15)
goto err_ret;
@@ -339,6 +341,15 @@ static int get_pipe(struct stub_device *sdev, int epnum, 
int dir)
goto err_ret;
 
epd = >desc;
+
+   /* validate transfer_buffer_length */
+   if (pdu->u.cmd_submit.transfer_buffer_length > INT_MAX) {
+   dev_err(>udev->dev,
+   "CMD_SUBMIT: -EMSGSIZE transfer_buffer_length %d\n",
+   pdu->u.cmd_submit.transfer_buffer_length);
+   return -1;
+   }
+
if (usb_endpoint_xfer_control(epd)) {
if (dir == USBIP_DIR_OUT)
return usb_sndctrlpipe(udev, epnum);
@@ -361,6 +372,21 @@ static int get_pipe(struct stub_device *sdev, int epnum, 
int dir)
}
 
if (usb_endpoint_xfer_isoc(epd)) {
+   /* validate packet size and number of packets */
+   unsigned int maxp, packets, bytes;
+
+   maxp = usb_endpoint_maxp(epd);
+   maxp *= usb_endpoint_maxp_mult(epd);
+   bytes = pdu->u.cmd_submit.transfer_buffer_length;
+   packets = DIV_ROUND_UP(bytes, maxp);
+
+   if (pdu->u.cmd_submit.number_of_packets < 0 ||
+   pdu->u.cmd_submit.number_of_packets > packets) {
+   dev_err(>udev->dev,
+   "CMD_SUBMIT: isoc invalid num packets %d\n",
+   pdu->u.cmd_submit.number_of_packets);
+   return -1;
+   }
if (dir == USBIP_DIR_OUT)
return usb_sndisocpipe(udev, epnum);
else
@@ -369,7 +395,7 @@ static int get_pipe(struct stub_device *sdev, int epnum, 
int dir)
 
 err_ret:
/* NOT REACHED */
-   dev_err(>udev->dev, "get pipe() invalid epnum %d\n", epnum);
+   dev_err(>udev->dev, "CMD_SUBMIT: invalid epnum %d\n", epnum);
return -1;
 }
 
@@ -434,7 +460,7 @@ static void stub_recv_cmd_submit(struct stub_device *sdev,
struct stub_priv *priv;
struct usbip_device *ud = >ud;
struct usb_device *udev = sdev->udev;
-   int pipe = get_pipe(sdev, pdu->base.ep, pdu->base.direction);
+   int pipe = get_pipe(sdev, pdu);
 
if (pipe == -1)
return;
@@ -456,7 +482,8 @@ static void stub_recv_cmd_submit(struct stub_device *sdev,
}
 
/* allocate urb transfer buffer, if needed */
-   if (pdu->u.cmd_submit.transfer_buffer_length > 0) {
+   if (pdu->u.cmd_submit.transfer_buffer_length > 0 &&
+   pdu->u.cmd_submit.transfer_buffer_length <= INT_MAX) {
priv->urb->transfer_buffer =
kzalloc(pdu->u.cmd_submit.transfer_buffer_length,
GFP_KERNEL);
-- 
2.14.1

[PATCH 4/4] usbip: fix stub_send_ret_submit() vulnerability to null transfer_buffer

[Shuah Khan]

stub_send_ret_submit() handles urb with a potential null transfer_buffer,
when it replays a packet with potential malicious data that could contain
a null buffer. Add a check for the condition when actual_length > 0 and
transfer_buffer is null.

Signed-off-by: Shuah Khan 
---
 drivers/usb/usbip/stub_tx.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/usbip/stub_tx.c b/drivers/usb/usbip/stub_tx.c
index b18bce96c212..53172b1f6257 100644
--- a/drivers/usb/usbip/stub_tx.c
+++ b/drivers/usb/usbip/stub_tx.c
@@ -167,6 +167,13 @@ static int stub_send_ret_submit(struct stub_device *sdev)
memset(_header, 0, sizeof(pdu_header));
memset(, 0, sizeof(msg));
 
+   if (urb->actual_length > 0 && !urb->transfer_buffer) {
+   dev_err(>udev->dev,
+   "urb: actual_length %d transfer_buffer null\n",
+   urb->actual_length);
+   return -1;
+   }
+
if (usb_pipetype(urb->pipe) == PIPE_ISOCHRONOUS)
iovnum = 2 + urb->number_of_packets;
else
-- 
2.14.1

Re: [PATCH v2 3/3] checkpatch: warn for use of %px

[Joe Perches]

On Fri, 2017-12-08 at 08:06 +1100, Tobin C. Harding wrote:
> On Wed, Dec 06, 2017 at 02:37:08PM +1100, Tobin C. Harding wrote:
> > Usage of the new %px specifier potentially leaks sensitive
> > inforamtion. Printing kernel addresses exposes the kernel layout in
> > memory, this is potentially exploitable. We have tools in the kernel to
> > help us do the right thing. We can have checkpatch warn developers of
> > potential dangers of using %px.
> > 
> > Have checkpatch emit a warning for usage of specifier %px.
> > 
> > Signed-off-by: Tobin C. Harding 
> > Co-developed-by: Joe Perches 
> 
>   Co-Developed-by:
> 
> Woops.
> 
> Joe I didn't quite understand what you meant when you said that this
> could go in via any tree. I'm still learning the whole kernel tree
> management thing. Don't checkpatch patches go in via Andy's tree?
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/apw/checkpatch.git/

No, not in quite awhile.

Most checkpatch patches go through Andrew Morton's
quilt/mm tree.

Re: [PATCH v2] doc: convert printk-formats.txt to rst

[Tobin C. Harding]

On Thu, Dec 07, 2017 at 01:52:56PM -0700, Jonathan Corbet wrote:
> On Fri, 8 Dec 2017 07:44:34 +1100
> "Tobin C. Harding"  wrote:
> 
> > Where is Jon's tree hosted please, I don't see it on kernel.org
> 
> From the MAINTAINERS file:
> 
>   T:  git git://git.lwn.net/linux.git docs-next
> 
> jon

Amateur hour at my house.

thanks Jon,
Tobin

[PATCH 1/2] serial: sccnxp: Delete an error message for a failed memory allocation in sccnxp_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 7 Dec 2017 21:55:09 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/tty/serial/sccnxp.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/serial/sccnxp.c b/drivers/tty/serial/sccnxp.c
index d6ae3086c2a2..ba1653ba5f37 100644
--- a/drivers/tty/serial/sccnxp.c
+++ b/drivers/tty/serial/sccnxp.c
@@ -857,10 +857,9 @@ static int sccnxp_probe(struct platform_device *pdev)
return PTR_ERR(membase);
 
s = devm_kzalloc(>dev, sizeof(struct sccnxp_port), GFP_KERNEL);
-   if (!s) {
-   dev_err(>dev, "Error allocating port structure\n");
+   if (!s)
return -ENOMEM;
-   }
+
platform_set_drvdata(pdev, s);
 
spin_lock_init(>lock);
-- 
2.15.1

[PATCH 1/4] usbip: fix stub_rx: get_pipe() to validate endpoint number

[Shuah Khan]

get_pipe() routine doesn't validate the input endpoint number
and uses to reference ep_in and ep_out arrays. Invalid endpoint
number can trigger BUG(). Range check the epnum and returning
error instead of calling BUG().

Change caller stub_recv_cmd_submit() to handle the get_pipe()
error return.

Signed-off-by: Shuah Khan 
---
 drivers/usb/usbip/stub_rx.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/usbip/stub_rx.c b/drivers/usb/usbip/stub_rx.c
index 536e037f541f..4d61063c259d 100644
--- a/drivers/usb/usbip/stub_rx.c
+++ b/drivers/usb/usbip/stub_rx.c
@@ -328,15 +328,15 @@ static int get_pipe(struct stub_device *sdev, int epnum, 
int dir)
struct usb_host_endpoint *ep;
struct usb_endpoint_descriptor *epd = NULL;
 
+   if (epnum < 0 || epnum > 15)
+   goto err_ret;
+
if (dir == USBIP_DIR_IN)
ep = udev->ep_in[epnum & 0x7f];
else
ep = udev->ep_out[epnum & 0x7f];
-   if (!ep) {
-   dev_err(>udev->dev, "no such endpoint?, %d\n",
-   epnum);
-   BUG();
-   }
+   if (!ep)
+   goto err_ret;
 
epd = >desc;
if (usb_endpoint_xfer_control(epd)) {
@@ -367,9 +367,10 @@ static int get_pipe(struct stub_device *sdev, int epnum, 
int dir)
return usb_rcvisocpipe(udev, epnum);
}
 
+err_ret:
/* NOT REACHED */
-   dev_err(>udev->dev, "get pipe, epnum %d\n", epnum);
-   return 0;
+   dev_err(>udev->dev, "get pipe() invalid epnum %d\n", epnum);
+   return -1;
 }
 
 static void masking_bogus_flags(struct urb *urb)
@@ -435,6 +436,9 @@ static void stub_recv_cmd_submit(struct stub_device *sdev,
struct usb_device *udev = sdev->udev;
int pipe = get_pipe(sdev, pdu->base.ep, pdu->base.direction);
 
+   if (pipe == -1)
+   return;
+
priv = stub_priv_alloc(sdev, pdu);
if (!priv)
return;
-- 
2.14.1

Re: [PATCH v8 1/3] arm: npcm: add basic support for Nuvoton BMCs

[Philippe Ombredanne]

Brendan,

On Thu, Dec 7, 2017 at 9:37 PM, Brendan Higgins
 wrote:
> Any update on this?
>
> On Fri, Nov 17, 2017 at 11:07 AM, Brendan Higgins
>  wrote:
>> Adds basic support for the Nuvoton NPCM750 BMC.
>>
>> Signed-off-by: Brendan Higgins 
>> Reviewed-by: Tomer Maimon 
>> Reviewed-by: Avi Fishman 
>> Tested-by: Tomer Maimon 
>> Tested-by: Avi Fishman 



>> --- /dev/null
>> +++ b/arch/arm/mach-npcm/npcm7xx.c
>> @@ -0,0 +1,25 @@
>> +/*
>> + * Copyright (c) 2017 Nuvoton Technology corporation.
>> + * Copyright 2017 Google, Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */

Have you considered using the new SPDX ids here instead of the
traditional license boilerplate?

This could come out this way:

// SPDX-License-Identifier: GPL-2.0
// Copyright (c) 2017 Nuvoton Technology corporation.
// Copyright 2017 Google, Inc.

It is shorter and simpler, with a better code/comments ratio.
And if you wonder about why using C++ style comment, please check
Linus posts on the topic, as well as Thomas doc patches.

Thank you for your kind consideration!

-- 
Cordially
Philippe Ombredanne

Re: [Part2 PATCH v9 12/38] crypto: ccp: Add Platform Security Processor (PSP) device support

[Philippe Ombredanne]

On Thu, Dec 7, 2017 at 9:21 PM, Brijesh Singh  wrote:
>
>
> On 12/06/2017 03:10 PM, Philippe Ombredanne wrote:>> diff --git
> a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
>>>
>>> new file mode 100644
>>> index ..b5789f878560
>>> --- /dev/null
>>> +++ b/drivers/crypto/ccp/psp-dev.c
>>> @@ -0,0 +1,105 @@
>>> +/*
>>> + * AMD Platform Security Processor (PSP) interface
>>> + *
>>> + * Copyright (C) 2016-2017 Advanced Micro Devices, Inc.
>>> + *
>>> + * Author: Brijesh Singh 
>>> + *
>>> + * 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.
>>> + */
>>
>>
>> Dear Brijesh,
>>
>> Have you considered using the new SPDX license ids instead?
>>
>> This would come out this way:
>>>
>>> +// SDPX-License-Identifier: GPL-2.0
>>> +/*
>>> + * AMD Platform Security Processor (PSP) interface
>>> + *
>>> + * Copyright (C) 2016-2017 Advanced Micro Devices, Inc.
>>> + *
>>> + * Author: Brijesh Singh 
>>> + */
>>
>>
>> It is much cleaner and simpler, right?
>>
>> For the C++ comment style and first line placement, please see Thomas
>> (tlgx) doc patches and Linus posts explaining his rationale of why he
>> wants it this way.
>> It would be awesome if this could be applied to all AMD contributions btw!
>>
>
> Hi Philippe,
>
> I was not aware of SPDX identifier, If v10 is needed for SEV series then I
> will certainly update the patches to use SPDX license identifier. thanks


Brijesh, that's very kind of you!

-- 
Cordially
Philippe Ombredanne

[PATCH 2/2] serial: sccnxp: Improve a size determination in sccnxp_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 7 Dec 2017 22:00:40 +0100

Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/tty/serial/sccnxp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/sccnxp.c b/drivers/tty/serial/sccnxp.c
index ba1653ba5f37..21be1fb5fd6d 100644
--- a/drivers/tty/serial/sccnxp.c
+++ b/drivers/tty/serial/sccnxp.c
@@ -856,7 +856,7 @@ static int sccnxp_probe(struct platform_device *pdev)
if (IS_ERR(membase))
return PTR_ERR(membase);
 
-   s = devm_kzalloc(>dev, sizeof(struct sccnxp_port), GFP_KERNEL);
+   s = devm_kzalloc(>dev, sizeof(*s), GFP_KERNEL);
if (!s)
return -ENOMEM;
 
-- 
2.15.1

Re: [PATCH 4.4 95/96] s390/kbuild: enable modversions for symbols exported from asm

[Ben Hutchings]

On Tue, 2017-11-28 at 11:23 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Heiko Carstens 
> 
> 
> [ Upstream commit cabab3f9f5ca077535080b3252e6168935b914af ]
> 
> s390 version of commit 334bb7738764 ("x86/kbuild: enable modversions
> for symbols exported from asm") so we get also rid of all these
> warnings:
[...]

This was only needed for 4.9.  Please revert it on the 3.18 and 4.4
branches.

Ben.

-- 
Ben Hutchings
Software Developer, Codethink Ltd.

Re: Multiple oom_reaper BUGs: unmap_page_range racing with exit_mmap

[David Rientjes]

On Thu, 7 Dec 2017, Michal Hocko wrote:

> Very well spotted! It could be any task in fact (e.g. somebody reading
> from /proc/ file which requires mm_struct).
> 
> oom_reaperoom_victim  task
>   mmget_not_zero
>   exit_mmap
> mmput
> __oom_reap_task_mmmmput
> __mmput
>   exit_mmap
> remove_vma
>   unmap_page_range
> 
> So we need a more robust test for the oom victim. Your suggestion is
> basically what I came up with originally [1] and which was deemed
> ineffective because we took the mmap_sem even for regular paths and
> Kirill was afraid this adds some unnecessary cycles to the exit path
> which is quite hot.
> 

Yes, I can confirm that in all crashes that we have analyzed so far that 
MMF_OOM_SKIP is actually set at the time that oom_reaper causes BUGs of 
various stack traces all originating from unmap_page_range() which is 
certainly not supposed to happen.

> So I guess we have to do something else instead. We have to store the
> oom flag to the mm struct as well. Something like the patch below.
> 
> [1] http://lkml.kernel.org/r/20170724072332.31903-1-mho...@kernel.org
> ---
> diff --git a/include/linux/oom.h b/include/linux/oom.h
> index 27cd36b762b5..b7668b5d3e14 100644
> --- a/include/linux/oom.h
> +++ b/include/linux/oom.h
> @@ -77,6 +77,11 @@ static inline bool tsk_is_oom_victim(struct task_struct * 
> tsk)
>   return tsk->signal->oom_mm;
>  }
>  
> +static inline bool mm_is_oom_victim(struct mm_struct *mm)
> +{
> + return test_bit(MMF_OOM_VICTIM, >flags);
> +}
> +
>  /*
>   * Checks whether a page fault on the given mm is still reliable.
>   * This is no longer true if the oom reaper started to reap the
> diff --git a/include/linux/sched/coredump.h b/include/linux/sched/coredump.h
> index 9c8847395b5e..da673ca66e7a 100644
> --- a/include/linux/sched/coredump.h
> +++ b/include/linux/sched/coredump.h
> @@ -68,8 +68,9 @@ static inline int get_dumpable(struct mm_struct *mm)
>  #define MMF_RECALC_UPROBES   20  /* MMF_HAS_UPROBES can be wrong */
>  #define MMF_OOM_SKIP 21  /* mm is of no interest for the OOM 
> killer */
>  #define MMF_UNSTABLE 22  /* mm is unstable for copy_from_user */
> -#define MMF_HUGE_ZERO_PAGE   23  /* mm has ever used the global huge 
> zero page */
> -#define MMF_DISABLE_THP  24  /* disable THP for all VMAs */
> +#define MMF_OOM_VICTIM   23  /* mm is the oom victim */
> +#define MMF_HUGE_ZERO_PAGE   24  /* mm has ever used the global huge 
> zero page */
> +#define MMF_DISABLE_THP  25  /* disable THP for all VMAs */
>  #define MMF_DISABLE_THP_MASK (1 << MMF_DISABLE_THP)
>  
>  #define MMF_INIT_MASK(MMF_DUMPABLE_MASK | 
> MMF_DUMP_FILTER_MASK |\

Could we not adjust the bit values, but simply add new one for 
MMF_OOM_VICTIM?  We have automated tools that look at specific bits in 
mm->flags and it would be nice to not have them be inconsistent between 
kernel versions.  Not absolutely required, but nice to avoid.

> diff --git a/mm/mmap.c b/mm/mmap.c
> index 476e810cf100..d00a06248ef1 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -3005,7 +3005,7 @@ void exit_mmap(struct mm_struct *mm)
>   unmap_vmas(, vma, 0, -1);
>  
>   set_bit(MMF_OOM_SKIP, >flags);
> - if (unlikely(tsk_is_oom_victim(current))) {
> + if (unlikely(mm_is_oom_victim(mm))) {
>   /*
>* Wait for oom_reap_task() to stop working on this
>* mm. Because MMF_OOM_SKIP is already set before
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 3b0d0fed8480..e4d290b6804b 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -666,8 +666,10 @@ static void mark_oom_victim(struct task_struct *tsk)
>   return;
>  
>   /* oom_mm is bound to the signal struct life time. */
> - if (!cmpxchg(>signal->oom_mm, NULL, mm))
> + if (!cmpxchg(>signal->oom_mm, NULL, mm)) {
>   mmgrab(tsk->signal->oom_mm);
> + set_bit(MMF_OOM_VICTIM, >flags);
> + }
>  
>   /*
>* Make sure that the task is woken up from uninterruptible sleep

Looks good, I see the other email with the same functional change plus a 
follow-up based on a suggestion by Tetsuo.  I'll test it alongside a 
change to not adjust existing MMF_* bit numbers.

Re: [PATCH v2] doc: convert printk-formats.txt to rst

[Tobin C. Harding]

On Thu, Dec 07, 2017 at 01:52:56PM -0700, Jonathan Corbet wrote:
> On Fri, 8 Dec 2017 07:44:34 +1100
> "Tobin C. Harding"  wrote:
> 
> > Where is Jon's tree hosted please, I don't see it on kernel.org
> 
> From the MAINTAINERS file:
> 
>   T:  git git://git.lwn.net/linux.git docs-next

Unless I'm a proper wombat that entry is not in the mainline MAINTAINERS
file.

You have two entries

CAFE CMOS INTEGRATED CAMERA CONTROLLER DRIVER
OMNIVISION OV7670 SENSOR DRIVER

but none for docs?

thanks,
Tobin.

Re: [v2 PATCH] cpufreq: powernv: Correctly parse the sign of pstates on POWER8 vs POWER9

[Rafael J. Wysocki]

On Thu, Dec 7, 2017 at 6:59 AM, Gautham R. Shenoy
 wrote:
> From: "Gautham R. Shenoy" 
>
> On POWERNV platform, Pstates are 8-bit values. On POWER8 they are
> negatively numbered while on POWER9 they are positively
> numbered. Thus, on POWER9, the maximum number of pstates could be as
> high as 256.
>
> The current code interprets pstates as a signed 8-bit value. This
> causes a problem on POWER9 platforms which have more than 128 pstates.
> On such systems, on a CPU that is in a lower pstate whose number is
> greater than 128, querying the current pstate returns a "pstate X is
> out of bound" error message and the current pstate is reported as the
> nominal pstate.
>
> This patch fixes the aforementioned issue by correctly differentiating
> the sign whenever a pstate value read, depending on whether the
> pstates are positively numbered or negatively numbered.
>
> Fixes: commit 09ca4c9b5958 ("cpufreq: powernv: Replacing pstate_id with 
> frequency table index")
> Cc:  #v4.8
> Signed-off-by: Gautham R. Shenoy 
> Tested-and-reviewed-by: Shilpasri G Bhat 
> Acked-by: Viresh Kumar 

I'm going to apply this, or please let me know if you want to route it
differently.

> ---
>  drivers/cpufreq/powernv-cpufreq.c | 43 
> ++-
>  1 file changed, 33 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/cpufreq/powernv-cpufreq.c 
> b/drivers/cpufreq/powernv-cpufreq.c
> index b6d7c4c..bb7586e 100644
> --- a/drivers/cpufreq/powernv-cpufreq.c
> +++ b/drivers/cpufreq/powernv-cpufreq.c
> @@ -41,11 +41,14 @@
>  #define POWERNV_MAX_PSTATES256
>  #define PMSR_PSAFE_ENABLE  (1UL << 30)
>  #define PMSR_SPR_EM_DISABLE(1UL << 31)
> -#define PMSR_MAX(x)((x >> 32) & 0xFF)
> +#define EXTRACT_BYTE(x, shift) (((x) >> shift) & 0xFF)
> +#define MAX_SHIFT  32
>  #define LPSTATE_SHIFT  48
>  #define GPSTATE_SHIFT  56
> -#define GET_LPSTATE(x) (((x) >> LPSTATE_SHIFT) & 0xFF)
> -#define GET_GPSTATE(x) (((x) >> GPSTATE_SHIFT) & 0xFF)
> +#define GET_PMSR_MAX(x)EXTRACT_BYTE(x, MAX_SHIFT)
> +#define GET_LPSTATE(x) EXTRACT_BYTE(x, LPSTATE_SHIFT)
> +#define GET_GPSTATE(x) EXTRACT_BYTE(x, GPSTATE_SHIFT)
> +
>
>  #define MAX_RAMP_DOWN_TIME 5120
>  /*
> @@ -64,6 +67,12 @@
>
>  /* Interval after which the timer is queued to bring down global pstate */
>  #define GPSTATE_TIMER_INTERVAL 2000
> +/*
> + * On POWER8 the pstates are negatively numbered. On POWER9, they are
> + * positively numbered.  Use this flag to track whether we have
> + * positive or negative numbered pstates.
> + */
> +static bool pos_pstates;
>
>  /**
>   * struct global_pstate_info - Per policy data structure to maintain history 
> of
> @@ -164,7 +173,7 @@ static inline unsigned int pstate_to_idx(int pstate)
> int min = powernv_freqs[powernv_pstate_info.min].driver_data;
> int max = powernv_freqs[powernv_pstate_info.max].driver_data;
>
> -   if (min > 0) {
> +   if (pos_pstates) {
> if (unlikely((pstate < max) || (pstate > min))) {
> pr_warn_once("pstate %d is out of bound\n", pstate);
> return powernv_pstate_info.nominal;
> @@ -301,6 +310,9 @@ static int init_powernv_pstates(void)
> }
> }
>
> +   if ((int)pstate_min > 0)
> +   pos_pstates = true;
> +
> /* End of list marker entry */
> powernv_freqs[i].frequency = CPUFREQ_TABLE_END;
> return 0;
> @@ -438,7 +450,6 @@ struct powernv_smp_call_data {
>  static void powernv_read_cpu_freq(void *arg)
>  {
> unsigned long pmspr_val;
> -   s8 local_pstate_id;
> struct powernv_smp_call_data *freq_data = arg;
>
> pmspr_val = get_pmspr(SPRN_PMSR);
> @@ -447,8 +458,11 @@ static void powernv_read_cpu_freq(void *arg)
>  * The local pstate id corresponds bits 48..55 in the PMSR.
>  * Note: Watch out for the sign!
>  */
> -   local_pstate_id = (pmspr_val >> 48) & 0xFF;
> -   freq_data->pstate_id = local_pstate_id;
> +   if (pos_pstates)
> +   freq_data->pstate_id = (u8)GET_LPSTATE(pmspr_val);
> +   else
> +   freq_data->pstate_id = (s8)GET_LPSTATE(pmspr_val);
> +
> freq_data->freq = pstate_id_to_freq(freq_data->pstate_id);
>
> pr_debug("cpu %d pmsr %016lX pstate_id %d frequency %d kHz\n",
> @@ -522,7 +536,10 @@ static void powernv_cpufreq_throttle_check(void *data)
> chip = this_cpu_read(chip_info);
>
> /* Check for Pmax Capping */
> -   pmsr_pmax = (s8)PMSR_MAX(pmsr);
> +   if (pos_pstates)
> +   pmsr_pmax = (u8)GET_PMSR_MAX(pmsr);
> +   else
> +   pmsr_pmax = (s8)GET_PMSR_MAX(pmsr);
> 

Re: WARNING in x86_emulate_insn

[Jim Mattson]

Try disabling the module parameter, "unrestricted_guest." Make sure
that the module parameter, "emulate_invalid_guest_state" is enabled.
This combination allows userspace to feed invalid guest state into the
in-kernel emulator.

On Thu, Dec 7, 2017 at 2:40 AM, Wanpeng Li  wrote:
> 2017-12-07 15:52 GMT+08:00 Wanpeng Li :
>> 2017-12-07 15:49 GMT+08:00 蓝天宇 :
>>> Hi Dmitry:
>>>  I tried to reproduce the issue via syz-execprog with attached
>>> reproducer on latest linux-next but it causes VM-entry failure due to
>>> invalid guest state...
>>
>> Because rflags is 0 in his program. You can set ept=0 and retry.
>
> In addition, you can apply this commit
> https://lkml.org/lkml/2017/12/7/144 before testing.
>
>>
>> Regards,
>> Wanpeng Li
>>
>>>
>>> 2017-12-07 14:25 GMT+08:00 Dmitry Vyukov :
 On Thu, Dec 7, 2017 at 1:44 AM, Wanpeng Li  wrote:
> 2017-12-06 4:07 GMT+08:00 syzbot
> :
>> Hello,
>>
>> syzkaller hit the following crash on
>> fb20eb9d798d2f4c1a75b7fe981d72dfa8d7270d
>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached
>> Raw console output is attached.
>>
>> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>> for information about syzkaller reproducers
>>
>
> Is there a c program to reproduce?

 No, syzbot does not hide reproducers. See the referenced doc for
 details: 
 https://github.com/google/syzkaller/blob/master/docs/syzbot.md#syzkaller-reproducers


> Regards,
> Wanpeng Li
>
>>
>> kvm: KVM_SET_TSS_ADDR need to be called before entering vcpu
>> WARNING: CPU: 1 PID: 3526 at arch/x86/kvm/emulate.c:5654
>> x86_emulate_insn+0xd01/0x3cf0 arch/x86/kvm/emulate.c:5654
>> Kernel panic - not syncing: panic_on_warn set ...
>>
>> CPU: 1 PID: 3526 Comm: syz-executor4 Not tainted 
>> 4.15.0-rc1-next-20171201+
>> #57
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>>  __dump_stack lib/dump_stack.c:17 [inline]
>>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>>  panic+0x1e4/0x41c kernel/panic.c:183
>>  __warn+0x1dc/0x200 kernel/panic.c:547
>>  report_bug+0x211/0x2d0 lib/bug.c:184
>>  fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:177
>>  fixup_bug arch/x86/kernel/traps.c:246 [inline]
>>  do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:295
>>  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:314
>>  invalid_op+0x22/0x40 arch/x86/entry/entry_64.S:1066
>> RIP: 0010:x86_emulate_insn+0xd01/0x3cf0 arch/x86/kvm/emulate.c:5654
>> RSP: 0018:8801d0fff3e8 EFLAGS: 00010293
>> RAX: 8801d17b60c0 RBX: 11003a1ffe86 RCX: 81154351
>> RDX:  RSI:  RDI: 8801d0b5b5c8
>> RBP: 8801d0fff4f8 R08: 8801d0b58d80 R09: 85224da0
>> R10: 0001 R11: ed003a16b6d4 R12: 00ff
>> R13: 8801d0b5b5a0 R14: 0002 R15: 8801d0b5b6c3
>>  x86_emulate_instruction+0x411/0x1ad0 arch/x86/kvm/x86.c:5771
>>  emulate_instruction arch/x86/include/asm/kvm_host.h:1164 [inline]
>>  complete_emulated_io arch/x86/kvm/x86.c:7190 [inline]
>>  complete_emulated_pio+0xdd/0x1b0 arch/x86/kvm/x86.c:7201
>>  kvm_arch_vcpu_ioctl_run+0x2db2/0x5c60 arch/x86/kvm/x86.c:7305
>>  kvm_vcpu_ioctl+0x64c/0x1010 
>> arch/x86/kvm/../../../virt/kvm/kvm_main.c:2574
>>  vfs_ioctl fs/ioctl.c:46 [inline]
>>  do_vfs_ioctl+0x1b1/0x1530 fs/ioctl.c:686
>>  SYSC_ioctl fs/ioctl.c:701 [inline]
>>  SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
>>  entry_SYSCALL_64_fastpath+0x1f/0x96
>> RIP: 0033:0x4529d9
>> RSP: 002b:7f6b6b2d5c58 EFLAGS: 0212 ORIG_RAX: 0010
>> RAX: ffda RBX: 00758020 RCX: 004529d9
>> RDX:  RSI: ae80 RDI: 0004
>> RBP: 039b R08:  R09: 
>> R10:  R11: 0212 R12: 006f2728
>> R13:  R14: 7f6b6b2d66d4 R15: 
>> Dumping ftrace buffer:
>>(ftrace buffer empty)
>> Kernel Offset: disabled
>> Rebooting in 86400 seconds..
>>
>>
>> ---
>> This bug is generated by a dumb bot. It may contain errors.
>> See https://goo.gl/tpsmEJ for details.
>> Direct all questions to syzkal...@googlegroups.com.
>> Please credit me with: Reported-by: syzbot 
>>
>> syzbot will keep track of this bug report.
>> Once a fix for this bug is committed, please reply to this email with:
>> #syz fix: 

Re: [PATCH] mux: add SPDX identifiers to all mux source files

[Philippe Ombredanne]

On Thu, Dec 7, 2017 at 10:08 PM, Peter Rosin  wrote:
> Remove all free-text license texts.
>
> This is done on a quest to remove the 700+ different ways that files in
> the kernel describe the GPL license text.
>
> No copyright headers or other non-license-description text was removed.
>
> Signed-off-by: Peter Rosin 
> ---
>
> Hi Philipp,
>
> I assume this is ok with you for the mmio file, but asking just in case...
>
> Cheers,
> Peter
>
>  drivers/mux/Kconfig  | 1 +
>  drivers/mux/Makefile | 1 +
>  drivers/mux/adg792a.c| 5 +
>  drivers/mux/core.c   | 5 +
>  drivers/mux/gpio.c   | 5 +
>  drivers/mux/mmio.c   | 5 +
>  include/linux/mux/consumer.h | 5 +
>  include/linux/mux/driver.h   | 5 +
>  8 files changed, 8 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
> index 19e4e904c9bf..6241678e99af 100644
> --- a/drivers/mux/Kconfig
> +++ b/drivers/mux/Kconfig
> @@ -1,3 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0
>  #
>  # Multiplexer devices
>  #
> diff --git a/drivers/mux/Makefile b/drivers/mux/Makefile
> index 0e1e59760e3f..c3d883955fd5 100644
> --- a/drivers/mux/Makefile
> +++ b/drivers/mux/Makefile
> @@ -1,3 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0
>  #
>  # Makefile for multiplexer devices.
>  #
> diff --git a/drivers/mux/adg792a.c b/drivers/mux/adg792a.c
> index 12aa221ab90d..6a8725cf3d71 100644
> --- a/drivers/mux/adg792a.c
> +++ b/drivers/mux/adg792a.c
> @@ -1,13 +1,10 @@
> +// SPDX-License-Identifier: GPL-2.0
>  /*
>   * Multiplexer driver for Analog Devices ADG792A/G Triple 4:1 mux
>   *
>   * Copyright (C) 2017 Axentia Technologies AB
>   *
>   * Author: Peter Rosin 
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
>   */
>
>  #include 
> diff --git a/drivers/mux/core.c b/drivers/mux/core.c
> index 2260063b0ea8..959d22aaa063 100644
> --- a/drivers/mux/core.c
> +++ b/drivers/mux/core.c
> @@ -1,13 +1,10 @@
> +// SPDX-License-Identifier: GPL-2.0
>  /*
>   * Multiplexer subsystem
>   *
>   * Copyright (C) 2017 Axentia Technologies AB
>   *
>   * Author: Peter Rosin 
> - *
> - * 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.
>   */
>
>  #define pr_fmt(fmt) "mux-core: " fmt
> diff --git a/drivers/mux/gpio.c b/drivers/mux/gpio.c
> index 468bf1709606..6fdd9316db8b 100644
> --- a/drivers/mux/gpio.c
> +++ b/drivers/mux/gpio.c
> @@ -1,13 +1,10 @@
> +// SPDX-License-Identifier: GPL-2.0
>  /*
>   * GPIO-controlled multiplexer driver
>   *
>   * Copyright (C) 2017 Axentia Technologies AB
>   *
>   * Author: Peter Rosin 
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
>   */
>
>  #include 
> diff --git a/drivers/mux/mmio.c b/drivers/mux/mmio.c
> index 37c1de359a70..935ac44aa209 100644
> --- a/drivers/mux/mmio.c
> +++ b/drivers/mux/mmio.c
> @@ -1,11 +1,8 @@
> +// SPDX-License-Identifier: GPL-2.0
>  /*
>   * MMIO register bitfield-controlled multiplexer driver
>   *
>   * Copyright (C) 2017 Pengutronix, Philipp Zabel 
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
>   */
>
>  #include 
> diff --git a/include/linux/mux/consumer.h b/include/linux/mux/consumer.h
> index ea96d4c82be7..5fc6bb2fefad 100644
> --- a/include/linux/mux/consumer.h
> +++ b/include/linux/mux/consumer.h
> @@ -1,13 +1,10 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
>  /*
>   * mux/consumer.h - definitions for the multiplexer consumer interface
>   *
>   * Copyright (C) 2017 Axentia Technologies AB
>   *
>   * Author: Peter Rosin 
> - *
> - * 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.
>   */
>
>  #ifndef _LINUX_MUX_CONSUMER_H
> diff --git a/include/linux/mux/driver.h b/include/linux/mux/driver.h
> index 35c3579c3304..627a2c6bc02d 100644
> --- a/include/linux/mux/driver.h
> +++ b/include/linux/mux/driver.h
> @@ -1,13 +1,10 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
>  /*
>   * mux/driver.h - definitions for the multiplexer driver interface
>   *
>   * Copyright (C) 2017 Axentia Technologies AB
>   *
>   * Author: Peter Rosin 
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General 

Re: [PATCH v3 10/16] iommu: introduce device fault report API

[Alex Williamson]

On Fri, 17 Nov 2017 10:55:08 -0800
Jacob Pan  wrote:

> Traditionally, device specific faults are detected and handled within
> their own device drivers. When IOMMU is enabled, faults such as DMA
> related transactions are detected by IOMMU. There is no generic
> reporting mechanism to report faults back to the in-kernel device
> driver or the guest OS in case of assigned devices.
> 
> Faults detected by IOMMU is based on the transaction's source ID which
> can be reported at per device basis, regardless of the device type is a
> PCI device or not.
> 
> The fault types include recoverable (e.g. page request) and
> unrecoverable faults(e.g. access error). In most cases, faults can be
> handled by IOMMU drivers internally. The primary use cases are as
> follows:
> 1. page request fault originated from an SVM capable device that is
> assigned to guest via vIOMMU. In this case, the first level page tables
> are owned by the guest. Page request must be propagated to the guest to
> let guest OS fault in the pages then send page response. In this
> mechanism, the direct receiver of IOMMU fault notification is VFIO,
> which can relay notification events to QEMU or other user space
> software.
> 
> 2. faults need more subtle handling by device drivers. Other than
> simply invoke reset function, there are needs to let device driver
> handle the fault with a smaller impact.
> 
> This patchset is intended to create a generic fault report API such
> that it can scale as follows:
> - all IOMMU types
> - PCI and non-PCI devices
> - recoverable and unrecoverable faults
> - VFIO and other other in kernel users
> - DMA & IRQ remapping (TBD)
> The original idea was brought up by David Woodhouse and discussions
> summarized at https://lwn.net/Articles/608914/.
> 
> Signed-off-by: Jacob Pan 
> Signed-off-by: Ashok Raj 
> ---
>  drivers/iommu/iommu.c | 63 
> ++-
>  include/linux/iommu.h | 36 +
>  2 files changed, 98 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 829e9e9..97b7990 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -581,6 +581,12 @@ int iommu_group_add_device(struct iommu_group *group, 
> struct device *dev)
>   goto err_free_name;
>   }
>  
> + dev->iommu_param = kzalloc(sizeof(struct iommu_fault_param), 
> GFP_KERNEL);
> + if (!dev->iommu_param) {
> + ret = -ENOMEM;
> + goto err_free_name;
> + }
> +
>   kobject_get(group->devices_kobj);
>  
>   dev->iommu_group = group;
> @@ -657,7 +663,7 @@ void iommu_group_remove_device(struct device *dev)
>   sysfs_remove_link(>kobj, "iommu_group");
>  
>   trace_remove_device_from_group(group->id, dev);
> -
> + kfree(dev->iommu_param);
>   kfree(device->name);
>   kfree(device);
>   dev->iommu_group = NULL;
> @@ -791,6 +797,61 @@ int iommu_group_unregister_notifier(struct iommu_group 
> *group,
>  }
>  EXPORT_SYMBOL_GPL(iommu_group_unregister_notifier);
>  
> +int iommu_register_device_fault_handler(struct device *dev,
> + iommu_dev_fault_handler_t handler,
> + void *data)
> +{
> + struct iommu_param *idata = dev->iommu_param;
> +
> + /*
> +  * Device iommu_param should have been allocated when device is
> +  * added to its iommu_group.
> +  */
> + if (!idata)
> + return -EINVAL;
> + /* Only allow one fault handler registered for each device */
> + if (idata->fault_param)
> + return -EBUSY;
> + get_device(dev);
> + idata->fault_param =
> + kzalloc(sizeof(struct iommu_fault_param), GFP_KERNEL);
> + if (!idata->fault_param)
> + return -ENOMEM;
> + idata->fault_param->handler = handler;
> + idata->fault_param->data = data;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(iommu_register_device_fault_handler);
> +
> +int iommu_unregister_device_fault_handler(struct device *dev)
> +{
> + struct iommu_param *idata = dev->iommu_param;
> +
> + if (!idata)
> + return -EINVAL;
> +
> + kfree(idata->fault_param);
> + idata->fault_param = NULL;
> + put_device(dev);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(iommu_unregister_device_fault_handler);
> +
> +
> +int iommu_report_device_fault(struct device *dev, struct iommu_fault_event 
> *evt)
> +{
> + /* we only report device fault if there is a handler registered */
> + if (!dev->iommu_param || !dev->iommu_param->fault_param ||
> + !dev->iommu_param->fault_param->handler)
> + return -ENOSYS;
> +
> + return dev->iommu_param->fault_param->handler(evt,
> + 
> dev->iommu_param->fault_param->data);
> +}
> 

Re: USB: hub: Delete an error message for a failed memory allocation in usb_hub_clear_tt_buffer()

[Alan Stern]

On Thu, 7 Dec 2017, Dan Carpenter wrote:

> On Thu, Dec 07, 2017 at 10:12:27AM -0500, Alan Stern wrote:
> > The real problem is that the kernel development community doesn't have
> > a fixed policy on how to handle memory allocation errors.  There are
> > several possibilities:
> > 
> > Ignore them on the grounds that they will never happen.
> > (Really?  And what is the size limit above which they
> > might happen?)
> > 
> 
> It's pretty rare to ignore allocation failures these days.  It causes
> static checker warnings.
> 
> Sometimes it's accepted for people to ignore errors during boot but
> I hate that because how am I supposed to filter out those static checker
> warnings?  It's better to pretend that the kernel will still boot
> without essential hardware instead of wasting everyone's time who looks
> at checker output.
> 
> > Ignore them on the grounds that the machine will hang or
> > crash in the near future.  (Is this guaranteed?)
> 
> On boot sometimes yes.
> 
> > 
> > Treat them like other errors: try to press forward (perhaps
> > in a degraded mode).
> > 
> > Treat them like other errors: log an error message and try
> > to press forward.
> > 
> 
> The standard is to treat them like errors and try press forward in a
> degraded mode but don't print a message.  Checkpatch.pl complains if you
> print a warning for allocation failures.  A lot of low level functions
> handle their own messages pretty well but especially kmalloc() does.

Which brings us back to my original objection.  If an allocation 
failure has localized effects, but the low-level warning is unable to 
specify what will be affected, how is the user supposed to connect the 
effect to the cause?

Alan Stern

> 
> I also have a special static checker warning for when people do:
> 
>   foo = alloc();
>   BUG_ON(!foo);
> 
> People do that occasionally but fortunately it's pretty rare.  10 years
> ago that's how btrfs did error handling, but now there are only 4 of
> these still remaining in btrfs.
> 
> regards,
> dan carpenter
> 
> 
> 

Re: [PATCH v2 3/3] checkpatch: warn for use of %px

[Joe Perches]

On Fri, 2017-12-08 at 08:15 +1100, Tobin C. Harding wrote:
> On Fri, Dec 08, 2017 at 08:06:53AM +1100, Tobin C. Harding wrote:
> > On Wed, Dec 06, 2017 at 02:37:08PM +1100, Tobin C. Harding wrote:
> > > Usage of the new %px specifier potentially leaks sensitive
> > > inforamtion. Printing kernel addresses exposes the kernel layout in
> > > memory, this is potentially exploitable. We have tools in the kernel to
> > > help us do the right thing. We can have checkpatch warn developers of
> > > potential dangers of using %px.
> > > 
> > > Have checkpatch emit a warning for usage of specifier %px.
> > > 
> > > Signed-off-by: Tobin C. Harding 
> > > Co-developed-by: Joe Perches 
> > 
> >   Co-Developed-by:
> > 
> > Woops.
> > 
> > Joe I didn't quite understand what you meant when you said that this
> > could go in via any tree. I'm still learning the whole kernel tree
> > management thing. Don't checkpatch patches go in via Andy's tree?
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/apw/checkpatch.git/
> 
> Oh, I see that tree is not super active. If there are no NACK's do you
> want me to put this through my tree? Perhaps once the Co-Developed-by
> stuff is in an acceptable form we could put them all together? Please do
> say if I'm going about things wrong, here to learn.

No worries, you could push it through your tree.

btw:  Here's an attempt at the case-sensitive signature matching
---
 scripts/checkpatch.pl | 47 --
-
 1 file changed, 24 insertions(+), 23 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 6b130a4116fa..59e8d62e0eb0 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -461,16 +461,18 @@ our $logFunctions = qr{(?x:
seq_vprintf|seq_printf|seq_puts
 )};
 
-our $signature_tags = qr{(?xi:
-   Signed-off-by:|
-   Acked-by:|
-   Tested-by:|
-   Reviewed-by:|
-   Reported-by:|
-   Suggested-by:|
-   To:|
-   Cc:
-)};
+our @valid_signatures = (
+   "Signed-off-by:",
+   "Acked-by:",
+   "Tested-by:",
+   "Reviewed-by:",
+   "Reported-by:",
+   "Suggested-by:",
+   "Co-Developed-by:",
+   "To:",
+   "Cc:"
+);
+my $signature_tags = "(?x:" . join('|', @valid_signatures) . ")";
 
 our @typeListMisordered = (
qr{char\s+(?:un)?signed},
@@ -2467,35 +2469,34 @@ sub process {
my $sign_off = $2;
my $space_after = $3;
my $email = $4;
-   my $ucfirst_sign_off = ucfirst(lc($sign_off));
+   my $preferred_sign_off = ucfirst(lc($sign_off));
 
-   if ($sign_off !~ /$signature_tags/) {
+   if ($sign_off !~ /$signature_tags/i) {
WARN("BAD_SIGN_OFF",
 "Non-standard signature: $sign_off\n" . 
$herecurr);
-   }
-   if (defined $space_before && $space_before ne "") {
+   } elsif ($sign_off !~ /$signature_tags/) {
+   $preferred_sign_off = $valid_signatures[ grep { 
$valid_signatures[$_] eq $sign_off } 0..$#valid_signatures ];
if (WARN("BAD_SIGN_OFF",
-"Do not use whitespace before 
$ucfirst_sign_off\n" . $herecurr) &&
+"'$preferred_sign_off' is the 
preferred signature form\n" . $herecurr) &&
$fix) {
-   $fixed[$fixlinenr] =
-   "$ucfirst_sign_off $email";
+   $fixed[$fixlinenr] = 
"$preferred_sign_off $email";
}
}
-   if ($sign_off =~ /-by:$/i && $sign_off ne 
$ucfirst_sign_off) {
+   if (defined $space_before && $space_before ne "") {
if (WARN("BAD_SIGN_OFF",
-"'$ucfirst_sign_off' is the preferred 
signature form\n" . $herecurr) &&
+"Do not use whitespace before 
$preferred_sign_off\n" . $herecurr) &&
$fix) {
$fixed[$fixlinenr] =
-   "$ucfirst_sign_off $email";
+   "$preferred_sign_off $email";
}
-
}
+
if (!defined $space_after || $space_after ne " ") {
if (WARN("BAD_SIGN_OFF",
-"Use a single space after 
$ucfirst_sign_off\n" . $herecurr) &&
+"Use a single space after 
$preferred_sign_off\n" . $herecurr) &&
  

Re: [PATCH v2] doc: convert printk-formats.txt to rst

[Tobin C. Harding]

On Thu, Dec 07, 2017 at 01:52:56PM -0700, Jonathan Corbet wrote:
> On Fri, 8 Dec 2017 07:44:34 +1100
> "Tobin C. Harding"  wrote:
> 
> > Where is Jon's tree hosted please, I don't see it on kernel.org
> 
> From the MAINTAINERS file:
> 
>   T:  git git://git.lwn.net/linux.git docs-next

Just in case it is of any use to you Jon

Adding a remote using the above URL

# Jon's docs tree
[remote "corbet"]
url = git://git.lwn.net/linux.git
fetch = +refs/heads/*:refs/remotes/corbet/*
pushurl = no_push


fails to git fetch, but ping showed me

git://git3.lwn.net/linux.git

Using that URL, fetched just fine.

thanks,
Tobin.

[PATCH] i2c: hix5hd2: Make sure clk is disabled in remove

[Alexey Khoroshilov]

pm_runtime_set_suspended() does not lead to call of suspend callback,
so clk may be left undisabled in hix5hd2_i2c_remove().

By the way, the patch adds error handling for clk_prepare_enable().

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
---
 drivers/i2c/busses/i2c-hix5hd2.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-hix5hd2.c b/drivers/i2c/busses/i2c-hix5hd2.c
index bb68957d3da5..8a921b5135ad 100644
--- a/drivers/i2c/busses/i2c-hix5hd2.c
+++ b/drivers/i2c/busses/i2c-hix5hd2.c
@@ -446,7 +446,11 @@ static int hix5hd2_i2c_probe(struct platform_device *pdev)
dev_err(>dev, "cannot get clock\n");
return PTR_ERR(priv->clk);
}
-   clk_prepare_enable(priv->clk);
+   ret = clk_prepare_enable(priv->clk);
+   if (ret) {
+   dev_err(>dev, "cannot enable clock\n");
+   return ret;
+   }
 
strlcpy(priv->adap.name, "hix5hd2-i2c", sizeof(priv->adap.name));
priv->dev = >dev;
@@ -496,8 +500,9 @@ static int hix5hd2_i2c_remove(struct platform_device *pdev)
struct hix5hd2_i2c_priv *priv = platform_get_drvdata(pdev);
 
i2c_del_adapter(>adap);
-   pm_runtime_disable(priv->dev);
-   pm_runtime_set_suspended(priv->dev);
+
+   /* Make sure priv->clk is disabled */
+   pm_runtime_force_suspend(priv->dev);
 
return 0;
 }
-- 
2.7.4

Re: [PATCH 2/3] bluetooth: hci_ll: add constant for vendor-specific command

[David Lechner]

On 12/04/2017 12:23 AM, Marcel Holtmann wrote:

Hi David,


This adds a #define for the vendor-specific HCI command to set the
baudrate instead of using the bare 0xff36 multiple times.

Signed-off-by: David Lechner 
---
drivers/bluetooth/hci_ll.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)


patch has been applied to bluetooth-next tree.



I am new to the bluetooth tree, so just to be sure... does this mean I 
should not include this patch in v2 of this series since this patch has 
been applied?

[PATCH] x86/pci: Add a break condition when enabling BAR

[Bandan Das]

On an old flaky system with AMD Opteron 6320, boot hangs
with the following trace since commit fa564ad9:

[   28.181012] Hardware name: HP ProLiant DL385p Gen8, BIOS A28 09/03/2014
[   28.184022] RIP: 0010:lock_acquire+0xd5/0x1e0
[   28.185010] RSP: 0018:b7ad818c39a8 EFLAGS: 0246 ORIG_RAX: 
ff11
[   28.187010] RAX: a074fb39b140 RBX: 0246 RCX: 
[   28.189014] RDX: b20a55a9 RSI: 00040009 RDI: 0246
[   28.191012] RBP:  R08: 0006 R09: 
[   28.193020] R10: 0001 R11: dac664b5 R12: 
[   28.196013] R13:  R14: 0001 R15: 
[   28.197011] FS:  () GS:a074fbd0() 
knlGS:
[   28.201014] CS:  0010 DS:  ES:  CR0: 80050033
[   28.201014] CR2:  CR3: 0003b6e1 CR4: 000406e0
[   28.205008] Call Trace:
[   28.205013]  ? request_resource_conflict+0x19/0x40
[   28.207013]  _raw_write_lock+0x2e/0x40
[   28.209008]  ? request_resource_conflict+0x19/0x40
[   28.209010]  request_resource_conflict+0x19/0x40
[   28.212013]  pci_amd_enable_64bit_bar+0x103/0x1a0
[   28.213025]  pci_fixup_device+0xd4/0x210
[   28.213025]  pci_setup_device+0x193/0x570
[   28.215010]  ? get_device+0x13/0x20
[   28.217008]  pci_scan_single_device+0x98/0xd0
[   28.217011]  pci_scan_slot+0x90/0x130
[   28.219010]  pci_scanild_bus_extend+0x3a/0x270
[   28.321008]  acpi_pci_root_create+0x1a9/0x210
[   28.321014]  ? pci_acpi_scan_root+0x135/0x1b0
[   28.324013]  pci_acpi_scan_root+0x15f/0x1b0
[   28.325008]  acpi_pci_root_add+0x283/0x560
[   28.325014]  ? acpi_match_device_ids+0xc/0x20
[   28.327013]  acpi_bus_attach+0xf9/0x1c0
[   28.329008]  acpi_bus_attach+0x82/0x1c0
[   28.329044]  acpi_bus_attach+0x82/0x1c0
[   28.331010]  acpi_bus_scan+0x47/0xa0
[   28.333008]  acpi_scan_init+0x12d/0x28d
[   28.333013]  ? bus_register+0x208/0x280
[   28.333013]  acpi_init+0x30f/0x36f
[   28.335010]  ? acpi_sleep_proc_init+0x24/0x24
[   28.337013]  do_one_initcall+0x4d/0x19c
[   28.337013]  ? do_early_param+0x29/0x86
[   28.340013]  kernel_init_freeable+0x209/0x2a4
[   28.341008]  ? set_debug_rodata+0x11/0x11
[   28.341011]  ? rest_init+0xc0/0xc0
[   28.343013]  kernel_init+0xa/0x104
[   28.345008]  ret_from_fork+0x24/0x30
[   28.345010] Code: 24 08 49 c1 e9 09 49 83 f1 01 41 83 e1 01 e8 73
e4 ff ff 65 48 8b 04 25 c0 d4 00 00 48 89 df c7 80 fc 0c 00 00 00 00
00 00 57 9d <0f> 1f 44 00 00 48 83 c4 30 5b 5d 41 5c 41 5d 41 5e 41 5f
c3 65

Since request_resource() will unconditionally return a conflict for invalid
regions, there will be no way to break out of the loop when enabling 64bit BAR.
Add checks and exit the loop in these cases without attempting to enable
BAR.

Signed-off-by: Bandan Das 
---
 arch/x86/pci/fixup.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index 1e996df..8933a1b 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -696,8 +696,13 @@ static void pci_amd_enable_64bit_bar(struct pci_dev *dev)
res->end = 0xfdull - 1;
 
/* Just grab the free area behind system memory for this */
-   while ((conflict = request_resource_conflict(_resource, res)))
+   while ((conflict = request_resource_conflict(_resource, res))) {
+   if ((res->start > res->end) ||
+   (res->start < iomem_resource.start) ||
+   (res->end > iomem_resource.end))
+   break;
res->start = conflict->end + 1;
+   }
 
dev_info(>dev, "adding root bus resource %pR\n", res);
 
-- 
2.9.4

Re: Multiple oom_reaper BUGs: unmap_page_range racing with exit_mmap

[Michal Hocko]

On Thu 07-12-17 09:28:01, Michal Hocko wrote:
[...]
> oom_reaperoom_victim  task
>   mmget_not_zero
>   exit_mmap

bleh, this should have been do_exit

> mmput
> __oom_reap_task_mmmmput
> __mmput
>   exit_mmap
> remove_vma
>   unmap_page_range
-- 
Michal Hocko
SUSE Labs

Re: USB: hub: Delete an error message for a failed memory allocation in usb_hub_clear_tt_buffer()

[Geert Uytterhoeven]

Hi Dan,

On Thu, Dec 7, 2017 at 9:35 AM, Dan Carpenter  wrote:
> On Thu, Dec 07, 2017 at 08:40:07AM +0100, Geert Uytterhoeven wrote:
>> On Wed, Dec 6, 2017 at 11:02 PM, Alan Stern  
>> wrote:
>> > On Wed, 6 Dec 2017, SF Markus Elfring wrote:
>> >> >>> Does the existing memory allocation error message include the
>> >> >>> >dev device name and driver name?  If it doesn't, there will be
>> >> >>> no way for the user to tell that the error message is related to the
>> >> >>> device failure.
>> >> >>
>> >> >> No, but the effect is similar.
>> >> >>
>> >> >> OOM does a dump_stack() so this function's call tree is shown.
>> >> >
>> >> > A call stack doesn't tell you which device was being handled.
>> >>
>> >> Do you find a default Linux allocation failure report insufficient then?
>> >>
>> >> Would you like to to achieve that the requested information can be 
>> >> determined
>> >> from a backtrace?
>> >
>> > It is not practical to do this.  The memory allocation routines do not
>> > for what purpose the memory is being allocated; hence when a failure
>> > occurs they cannot tell what device (or other part of the system) will
>> > be affected.
>>
>> If even allocation of 24 bytes fails, lots of other devices and other parts 
>> of
>> the system will start failing really soon...
>
> Small allocations never fail in the current kernel.

A few comments (this is in response to a patch from Markus, so there have
to be lots of questions and uncertainties ;-)
1. In the current kernel. What about the future?
2. If a small allocation cannot fail, what happens if the small memory slab
   is exhausted? A new page must be allocated, which will trigger an OOM,
   and some other part of the system will be killed and fail.
3. This driver uses GFP_ATOMIC, is that guaranteed to succeed? I think not.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v2 33/35] clocksource/drivers/atcpit100: Add andestech atcpit100 timer

[Daniel Lezcano]

On 27/11/2017 13:28, Greentime Hu wrote:
> From: Rick Chen 
> 
> ATCPIT100 is often used on the Andes architecture,
> This timer provide 4 PIT channels. Each PIT channel is a
> multi-function timer, can be configured as 32,16,8 bit timers
> or PWM as well.
> 
> For system timer it will set channel 1 32-bit timer0 as clock
> source and count downwards until underflow and restart again.
> 
> It also set channel 0 32-bit timer0 as clock event and count
> downwards until condition match. It will generate an interrupt
> for handling periodically.
> 
> Signed-off-by: Rick Chen 
> Signed-off-by: Greentime Hu 
> ---

Looks good.

Please resend this patch folded with the Makefile change and the DT
binding (fixed) as suggested by Arnd. I will merge them.

Thanks

  -- Daniel


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH 1/2] arm64: defconfig: enable MUSB HDRC along with Allwinner glue

[Maxime Ripard]

On Wed, Dec 06, 2017 at 11:19:58PM +0530, Jagan Teki wrote:
> Allwinner SoCs typically have a Mentor Graphics Inventra MUSB
> dual role controller for USB OTG. This is need for verifying
> gadget functions, so enable them by default.
> 
> Tested 'otg' mode with mass storage function.
> 
> Signed-off-by: Jagan Teki 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH v4 6/9] drm/i915: Make use of indexed write GMBUS feature

[Daniel Vetter]

On Wed, Dec 06, 2017 at 07:00:09PM -0500, Sean Paul wrote:
> This patch enables the indexed write feature of the GMBUS to concatenate
> 2 consecutive messages into one. The criteria for an indexed write is
> that both messages are writes, the first is length == 1, and the second
> is length > 0. The first message is sent out by the GMBUS as the slave
> command, and the second one is sent via the GMBUS FIFO as usual.
> 
> Changes in v3:
> - Added to series
> Changes in v4:
> - Combine indexed reads and writes (Ville)
> 
> Cc: Daniel Vetter 
> Suggested-by: Ville Syrjälä 
> Signed-off-by: Sean Paul 

Even prettier!

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/intel_i2c.c | 34 --
>  1 file changed, 20 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c 
> b/drivers/gpu/drm/i915/intel_i2c.c
> index 49fdf09f9919..d78ce758fbfa 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -373,7 +373,8 @@ gmbus_xfer_read(struct drm_i915_private *dev_priv, struct 
> i2c_msg *msg,
>  
>  static int
>  gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
> -unsigned short addr, u8 *buf, unsigned int len)
> +unsigned short addr, u8 *buf, unsigned int len,
> +u32 gmbus1_index)
>  {
>   unsigned int chunk_size = len;
>   u32 val, loop;
> @@ -386,7 +387,7 @@ gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
>  
>   I915_WRITE_FW(GMBUS3, val);
>   I915_WRITE_FW(GMBUS1,
> -   GMBUS_CYCLE_WAIT |
> +   gmbus1_index | GMBUS_CYCLE_WAIT |
> (chunk_size << GMBUS_BYTE_COUNT_SHIFT) |
> (addr << GMBUS_SLAVE_ADDR_SHIFT) |
> GMBUS_SLAVE_WRITE | GMBUS_SW_RDY);
> @@ -409,7 +410,8 @@ gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
>  }
>  
>  static int
> -gmbus_xfer_write(struct drm_i915_private *dev_priv, struct i2c_msg *msg)
> +gmbus_xfer_write(struct drm_i915_private *dev_priv, struct i2c_msg *msg,
> +  u32 gmbus1_index)
>  {
>   u8 *buf = msg->buf;
>   unsigned int tx_size = msg->len;
> @@ -419,7 +421,8 @@ gmbus_xfer_write(struct drm_i915_private *dev_priv, 
> struct i2c_msg *msg)
>   do {
>   len = min(tx_size, GMBUS_BYTE_COUNT_MAX);
>  
> - ret = gmbus_xfer_write_chunk(dev_priv, msg->addr, buf, len);
> + ret = gmbus_xfer_write_chunk(dev_priv, msg->addr, buf, len,
> +  gmbus1_index);
>   if (ret)
>   return ret;
>  
> @@ -431,21 +434,21 @@ gmbus_xfer_write(struct drm_i915_private *dev_priv, 
> struct i2c_msg *msg)
>  }
>  
>  /*
> - * The gmbus controller can combine a 1 or 2 byte write with a read that
> - * immediately follows it by using an "INDEX" cycle.
> + * The gmbus controller can combine a 1 or 2 byte write with another 
> read/write
> + * that immediately follows it by using an "INDEX" cycle.
>   */
>  static bool
> -gmbus_is_index_read(struct i2c_msg *msgs, int i, int num)
> +gmbus_is_index_xfer(struct i2c_msg *msgs, int i, int num)
>  {
>   return (i + 1 < num &&
>   msgs[i].addr == msgs[i + 1].addr &&
>   !(msgs[i].flags & I2C_M_RD) &&
>   (msgs[i].len == 1 || msgs[i].len == 2) &&
> - (msgs[i + 1].flags & I2C_M_RD));
> + msgs[i + 1].len > 0);
>  }
>  
>  static int
> -gmbus_xfer_index_read(struct drm_i915_private *dev_priv, struct i2c_msg 
> *msgs)
> +gmbus_index_xfer(struct drm_i915_private *dev_priv, struct i2c_msg *msgs)
>  {
>   u32 gmbus1_index = 0;
>   u32 gmbus5 = 0;
> @@ -462,7 +465,10 @@ gmbus_xfer_index_read(struct drm_i915_private *dev_priv, 
> struct i2c_msg *msgs)
>   if (gmbus5)
>   I915_WRITE_FW(GMBUS5, gmbus5);
>  
> - ret = gmbus_xfer_read(dev_priv, [1], gmbus1_index);
> + if (msgs[1].flags & I2C_M_RD)
> + ret = gmbus_xfer_read(dev_priv, [1], gmbus1_index);
> + else
> + ret = gmbus_xfer_write(dev_priv, [1], gmbus1_index);
>  
>   /* Clear GMBUS5 after each index transfer */
>   if (gmbus5)
> @@ -486,13 +492,13 @@ do_gmbus_xfer(struct i2c_adapter *adapter, struct 
> i2c_msg *msgs, int num)
>  
>   for (; i < num; i += inc) {
>   inc = 1;
> - if (gmbus_is_index_read(msgs, i, num)) {
> - ret = gmbus_xfer_index_read(dev_priv, [i]);
> - inc = 2; /* an index read is two msgs */
> + if (gmbus_is_index_xfer(msgs, i, num)) {
> + ret = gmbus_index_xfer(dev_priv, [i]);
> + inc = 2; /* an index transmission is two msgs */
>   } else if (msgs[i].flags & I2C_M_RD) {
>   ret = gmbus_xfer_read(dev_priv, [i], 0);

Re: [PATCH net-next] bnxt: Don't print message, if DAC isn't connected on both ends

[Thomas Bogendoerfer]

On Wed, 6 Dec 2017 11:27:31 -0800
Michael Chan  wrote:

> On Tue, Dec 5, 2017 at 4:33 AM, Thomas Bogendoerfer
>  wrote:
> > bnxt driver spams logfiles with
> >
> > [  541.003065] bnxt_en :5d:00.1 eth5: Link speed -1 no longer supported
> >
> > if a direct attached cable (DAC) is plugged into the bnxt card and is
> > unplugged on the other side. This patch removes the code printing this
> > message, since it doesn't provide any useful information.
> >
> > Signed-off-by: Thomas Bogendoerfer 
> > ---
> >  drivers/net/ethernet/broadcom/bnxt/bnxt.c | 9 -
> >  1 file changed, 9 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c 
> > b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> > index 8c1dd60eab6f..8a2319ed79dc 100644
> > --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> > +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> > @@ -1701,18 +1701,9 @@ static int bnxt_async_event_process(struct bnxt *bp,
> > /* TODO CHIMP_FW: Define event id's for link change, error etc */
> > switch (event_id) {
> > case ASYNC_EVENT_CMPL_EVENT_ID_LINK_SPEED_CFG_CHANGE: {
> > -   u32 data1 = le32_to_cpu(cmpl->event_data1);
> > -   struct bnxt_link_info *link_info = >link_info;
> > -
> > if (BNXT_VF(bp))
> > goto async_event_process_exit;
> > -   if (data1 & 0x2) {
> > -   u16 fw_speed = link_info->force_link_speed;
> > -   u32 speed = bnxt_fw_to_ethtool_speed(fw_speed);
> >
> > -   netdev_warn(bp->dev, "Link speed %d no longer 
> > supported\n",
> > -   speed);
> > -   }
> 
> This is supposed to provide useful information to the user under some
> conditions. 

well, it will print the forced rate, if there is one configured and -1 
otherwise,
if the link is lost or will not come up because of a cable problem. I don't see 
much
value in that...

Thomas.

-- 
SUSE Linux GmbH
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [PATCHv4 3/4] x86/boot/compressed/64: Introduce place_trampoline()

[Ingo Molnar]

* Matthew Wilcox  wrote:

> On Thu, Dec 07, 2017 at 07:30:48AM +0100, Ingo Molnar wrote:
> > > But if the bootloader put the kernel above 4G (not sure if anybody does
> > > this), we would loose control as soon as paging is disabled as code
> > > becomes unreachable.
> > 
> > Yeah, so instead of the double 'as' which is syntactically right but a bit 
> > confusing to read, how about something like:
> > 
> >   But if the bootloader put the kernel above 4G (not sure if anybody does
> >   this), we would loose control as soon as paging is disabled, because the
> >   code becomes unreachable to the CPU.
> 
> btw, it's "lose control".

Indeed!

Thanks,

Ingo

Re: [patch 41/60] x86/mm/kpti: Share entry text PMD

[Borislav Petkov]

On Mon, Dec 04, 2017 at 03:07:47PM +0100, Thomas Gleixner wrote:
> From: Thomas Gleixner 
> 
> Share the entry text PMD of the kernel mapping with the user space
> mapping. If large pages are enabled this is a single PMD entry and at the
> point where it is copied into the user page table the RW bit has not been
> cleared yet. Clear it right away so the user space visible map becomes RX.
> 
> Signed-off-by: Thomas Gleixner 
> ---
>  arch/x86/mm/kpti.c |   10 ++
>  1 file changed, 10 insertions(+)

Reviewed-by: Borislav Petkov 

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

Re: [PATCH] mm: terminate shrink_slab loop if signal is pending

[Michal Hocko]

On Wed 06-12-17 11:20:26, Suren Baghdasaryan wrote:
> Slab shrinkers can be quite time consuming and when signal
> is pending they can delay handling of the signal. If fatal
> signal is pending there is no point in shrinking that process
> since it will be killed anyway. This change checks for pending
> fatal signals inside shrink_slab loop and if one is detected
> terminates this loop early.

This is not enough. You would have to make sure the direct reclaim will
bail out immeditally which is not at all that simple. We do check fatal
signals in throttle_direct_reclaim and conditionally in shrink_inactive_list
so even if you bail out from shrinkers we could still finish the full
reclaim cycle.

Besides that shrinkers shouldn't really take very long so this looks
like it papers over a real bug somewhere else. I am not saying the patch
is wrong but it would deserve much more details to judge wether this is
the right way to go for your particular problem.

> Signed-off-by: Suren Baghdasaryan 
> ---
>  mm/vmscan.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index c02c850ea349..69296528ff33 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -486,6 +486,13 @@ static unsigned long shrink_slab(gfp_t gfp_mask, int nid,
>   .memcg = memcg,
>   };
>  
> + /*
> +  * We are about to die and free our memory.
> +  * Stop shrinking which might delay signal handling.
> +  */
> + if (unlikely(fatal_signal_pending(current))
> + break;
> +
>   /*
>* If kernel memory accounting is disabled, we ignore
>* SHRINKER_MEMCG_AWARE flag and call all shrinkers
> -- 
> 2.15.1.424.g9478a66081-goog
> 

-- 
Michal Hocko
SUSE Labs

Re: [PATCH] tpm: return a TPM_RC_COMMAND_CODE response if a command isn't implemented

[Javier Martinez Canillas]

Hello Jarkko,

On 12/07/2017 02:32 AM, Jarkko Sakkinen wrote:
> On Mon, Nov 27, 2017 at 12:30:12AM +0100, Javier Martinez Canillas wrote:
>> According to the TPM Library Specification, a TPM device must do a command
>> header validation before processing and return a TPM_RC_COMMAND_CODE code
>> if the command is not implemented.
>>
>> So user-space will expect to handle that response as an error. But if the
>> in-kernel resource manager is used (/dev/tpmrm?), an -EINVAL errno code is
>> returned instead if the command isn't implemented. This confuses userspace
>> since it doesn't expect that error value.
>>
>> This also isn't consistent with the behavior when not using TPM spaces and
>> accessing the TPM directly (/dev/tpm?). In this case, the command is sent
>> to the TPM even when not implemented and the TPM responds with an error.
>>
>> Instead of returning an -EINVAL errno code when the tpm_validate_command()
>> function fails, synthesize a TPM command response so user-space can get a
>> TPM_RC_COMMAND_CODE as expected when a chip doesn't implement the command.
>>
>> The TPM only sets 12 of the 32 bits in the TPM_RC response, so the TSS and
>> TAB specifications define that higher layers in the stack should use some
>> of the unused 20 bits to specify from which level of the stack the error
>> is coming from.
>>
>> Since the TPM_RC_COMMAND_CODE response code is sent by the kernel resource
>> manager, set the error level to the TAB/RM layer so user-space is aware of
>> this.
>>
>> Suggested-by: Jason Gunthorpe 
>> Signed-off-by: Javier Martinez Canillas 
>>
>> ---
>>
>> Changes since RFCv2:
>> - Set the error level to the TAB/RM layer so user-space is aware that the 
>> error
>>   is not coming from the TPM (suggested by Philip Tricca and Jarkko 
>> Sakkinen).
>>
>> Changes since RFCv1:
>> - Don't pass not validated commands to the TPM, instead return a synthesized
>>   response with the correct TPM return code (suggested by Jason Gunthorpe).
>>
>> And example of user-space getting confused by the TPM chardev returning 
>> -EINVAL
>> when sending a not supported TPM command can be seen in this tpm2-tools 
>> issue:
>>
>> https://github.com/intel/tpm2-tools/issues/621
>>
>> Best regards,
>> Javier
>>
>>  drivers/char/tpm/tpm-interface.c | 28 
>>  drivers/char/tpm/tpm.h   |  8 
>>  2 files changed, 28 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/char/tpm/tpm-interface.c 
>> b/drivers/char/tpm/tpm-interface.c
>> index ebe0a1d36d8c..9391811c5f83 100644
>> --- a/drivers/char/tpm/tpm-interface.c
>> +++ b/drivers/char/tpm/tpm-interface.c
>> @@ -328,7 +328,7 @@ unsigned long tpm_calc_ordinal_duration(struct tpm_chip 
>> *chip,
>>  }
>>  EXPORT_SYMBOL_GPL(tpm_calc_ordinal_duration);
>>  
>> -static bool tpm_validate_command(struct tpm_chip *chip,
>> +static int tpm_validate_command(struct tpm_chip *chip,
>>   struct tpm_space *space,
>>   const u8 *cmd,
>>   size_t len)
>> @@ -340,10 +340,10 @@ static bool tpm_validate_command(struct tpm_chip *chip,
>>  unsigned int nr_handles;
>>  
>>  if (len < TPM_HEADER_SIZE)
>> -return false;
>> +return -EINVAL;
>>  
>>  if (!space)
>> -return true;
>> +return 0;
>>  
>>  if (chip->flags & TPM_CHIP_FLAG_TPM2 && chip->nr_commands) {
>>  cc = be32_to_cpu(header->ordinal);
>> @@ -352,7 +352,7 @@ static bool tpm_validate_command(struct tpm_chip *chip,
>>  if (i < 0) {
>>  dev_dbg(>dev, "0x%04X is an invalid command\n",
>>  cc);
>> -return false;
>> +return -EOPNOTSUPP;
>>  }
>>  
>>  attrs = chip->cc_attrs_tbl[i];
>> @@ -362,11 +362,11 @@ static bool tpm_validate_command(struct tpm_chip *chip,
>>  goto err_len;
>>  }
>>  
>> -return true;
>> +return 0;
>>  err_len:
>>  dev_dbg(>dev,
>>  "%s: insufficient command length %zu", __func__, len);
>> -return false;
>> +return -EINVAL;
>>  }
>>  
>>  /**
>> @@ -391,8 +391,20 @@ ssize_t tpm_transmit(struct tpm_chip *chip, struct 
>> tpm_space *space,
>>  unsigned long stop;
>>  bool need_locality;
>>  
>> -if (!tpm_validate_command(chip, space, buf, bufsiz))
>> -return -EINVAL;
>> +rc = tpm_validate_command(chip, space, buf, bufsiz);
>> +if (rc == -EINVAL)
>> +return rc;
>> +/*
>> + * If the command is not implemented by the TPM, synthesize a
>> + * response with a TPM2_RC_COMMAND_CODE return for user-space.
>> + */
>> +if (rc == -EOPNOTSUPP) {
>> +header->length = cpu_to_be32(sizeof(*header));
>> +header->tag = cpu_to_be16(TPM2_ST_NO_SESSIONS);
>> +header->return_code = cpu_to_be32(TPM2_RC_COMMAND_CODE |
>> +  

Re: [PATCH] gpio: gpio-reg: fix build

[Linus Walleij]

On Wed, Dec 6, 2017 at 6:37 PM, Grygorii Strashko
 wrote:

> Revert changes introduced by commit f0fbe7bce733 ("gpio: Move irqdomain
> into struct gpio_irq_chip") as they are not aplicable to this driver.
>
> Cc: Russell King - ARM Linux 
> Fixes: f0fbe7bce733 ("gpio: Move irqdomain into struct gpio_irq_chip")
> Signed-off-by: Grygorii Strashko 

Patch applied for fixes.

Yours,
Linus Walleij

Re: [PATCH 2/2] clk: sunxi-ng: sun50i: a64: Add 2x fixed post-divider to MMC module clocks

[Maxime Ripard]

On Thu, Dec 07, 2017 at 12:10:39AM +0800, Chen-Yu Tsai wrote:
> On Wed, Dec 6, 2017 at 11:56 PM, Maxime Ripard
>  wrote:
> > Hi,
> >
> > On Wed, Dec 06, 2017 at 10:30:26AM +0800, Chen-Yu Tsai wrote:
> >> On Wed, Dec 6, 2017 at 3:59 AM, Maxime Ripard
> >>  wrote:
> >> > Hi,
> >> >
> >> > On Mon, Dec 04, 2017 at 01:19:12PM +0800, Chen-Yu Tsai wrote:
> >> >> On the A64, the MMC module clocks are fixed in the new timing mode,
> >> >> i.e. they do not have a bit to select the mode. These clocks have
> >> >> a 2x divider somewhere between the clock and the MMC module.
> >> >>
> >> >> To be consistent with other SoCs supporting the new timing mode,
> >> >> we model the 2x divider as a fixed post-divider on the MMC module
> >> >> clocks.
> >> >>
> >> >> This patch adds the post-dividers to the MMC clocks.
> >> >>
> >> >> Signed-off-by: Chen-Yu Tsai 
> >> >
> >> > I had a doubt applying that one... sorry.
> >> >
> >> >> ---
> >> >>  drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 57 
> >> >> +++
> >> >>  1 file changed, 37 insertions(+), 20 deletions(-)
> >> >>
> >> >> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c 
> >> >> b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> >> >> index 2bb4cabf802f..ee9c12cf3f08 100644
> >> >> --- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> >> >> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> >> >> @@ -400,28 +400,45 @@ static SUNXI_CCU_MP_WITH_MUX_GATE(nand_clk, 
> >> >> "nand", mod0_default_parents, 0x080,
> >> >> BIT(31),  /* gate */
> >> >> 0);
> >> >>
> >> >> +/*
> >> >> + * MMC clocks are the new timing mode (see A83T & H3) variety, but 
> >> >> without
> >> >> + * the mode switch. This means they have a 2x post divider between the 
> >> >> clock
> >> >> + * and the MMC module. This is not documented in the manual, but is 
> >> >> taken
> >> >> + * into consideration when setting the mmc module clocks in the BSP 
> >> >> kernel.
> >> >> + * Without it, MMC performance is degraded.
> >> >> + *
> >> >> + * We model it here to be consistent with other SoCs supporting this 
> >> >> mode.
> >> >> + * The alternative would be to add the 2x multiplier when setting the 
> >> >> MMC
> >> >> + * module clock in the MMC driver, just for the A64.
> >> >> + */
> >> >>  static const char * const mmc_default_parents[] = { "osc24M", 
> >> >> "pll-periph0-2x",
> >> >>   "pll-periph1-2x" };
> >> >> -static SUNXI_CCU_MP_WITH_MUX_GATE(mmc0_clk, "mmc0", 
> >> >> mmc_default_parents, 0x088,
> >> >> -   0, 4, /* M */
> >> >> -   16, 2,/* P */
> >> >> -   24, 2,/* mux */
> >> >> -   BIT(31),  /* gate */
> >> >> -   0);
> >> >> -
> >> >> -static SUNXI_CCU_MP_WITH_MUX_GATE(mmc1_clk, "mmc1", 
> >> >> mmc_default_parents, 0x08c,
> >> >> -   0, 4, /* M */
> >> >> -   16, 2,/* P */
> >> >> -   24, 2,/* mux */
> >> >> -   BIT(31),  /* gate */
> >> >> -   0);
> >> >> -
> >> >> -static SUNXI_CCU_MP_WITH_MUX_GATE(mmc2_clk, "mmc2", 
> >> >> mmc_default_parents, 0x090,
> >> >> -   0, 4, /* M */
> >> >> -   16, 2,/* P */
> >> >> -   24, 2,/* mux */
> >> >> -   BIT(31),  /* gate */
> >> >> -   0);
> >> >> +static SUNXI_CCU_MP_WITH_MUX_GATE_POSTDIV(mmc0_clk, "mmc0",
> >> >> +   mmc_default_parents, 0x088,
> >> >> +   0, 4, /* M */
> >> >> +   16, 2,/* P */
> >> >> +   24, 2,/* mux */
> >> >> +   BIT(31),  /* gate */
> >> >> +   2,/* post-div */
> >> >> +   0);
> >> >> +
> >> >> +static SUNXI_CCU_MP_WITH_MUX_GATE_POSTDIV(mmc1_clk, "mmc1",
> >> >> +   mmc_default_parents, 0x08c,
> >> >> +   0, 4, /* M */
> >> >> +   16, 2,/* P */
> >> >> +   24, 2,/* mux */
> >> >> +   BIT(31),  /* gate */
> >> >> +   2,/* post-div */
> >> >> +   0);
> >> >> +
> >> >
> >> > Are you sure that the divider there for the non-eMMC clocks? Usually,
> >> > the 

Re: [PATCH v5 00/11] add pinmuxing support for pins in AXP209 and AXP813 PMICs

[Linus Walleij]

On Tue, Dec 5, 2017 at 3:46 PM, Quentin Schulz
 wrote:

> The AXP209 and AXP813 PMICs have several pins (respectively 3 and 2) that can
> be used either as GPIOs or for other purposes (ADC or LDO here).
>
> We already have a GPIO driver for the GPIO use of those pins on the AXP209.
> Let's "upgrade" this driver to support all the functions these pins can have.
>
> Then we add support to this driver for the AXP813 which is slighlty different
> (basically a different offset in two registers and one less pin).
>
> I suggest patches 1 to 8 go through Linus's tree and 9 via Lee's.
>
> v5:
>   - add reference to pinctrl dt-bindings in driver's dt-binding,
>   - add statement that this driver employs per-pin muxing pattern,
>   - add a patch on top of the patch series to fix checkpatch warnings,
>   - add a few information to the Kconfig to make checkpatch happy,

I have applied patches 1-8 to an immutable branch in the GPIO
tree, then merged that into the GPIO "devel" branch as well as the
pinctrl "devel" branch so we can develop the driver in the pinctrl
tree henceforth.

Yours,
Linus Walleij

Re: [PATCH] scsi: bfa: fix type conversion warning

[Johannes Thumshirn]

Thanks Arnd,
Reviewed-by: Johannes Thumshirn 

-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

Re: [PATCH] uio: Allow to take irq bottom-half into irq_handler with additional dt-binding

[Greg KH]

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

On Wed, Dec 06, 2017 at 05:59:01PM +0100, Andrey Zhizhikin wrote:
> Hello Greg,
> 
> Thanks a lot for your prompt reply!
> 
> First of, this is my first patch submission to the Kernel, so thanks a
> lot for your additional guidelines here regarding missing pieces.
> Please don't judge me hard here. :)

No worries, everyone has to start somewhere :)

> I would add new DT bindings to Documentation and contact DT
> maintainers to have a new binding discussed. However, I was not able
> to find any dt-binding documentation for uio drivers in the kernel,
> presumably I would have to create a new entry there...

The uio-phys driver does use DT bindings, so perhaps look at how those
are defined.

> As for the win against latency and running the patch against the
> system which has all IRQ in threaded mode:
> 
> I've actually originated this patch based on the PREEMPT_RT kernel
> configuration, where all IRQs are threaded. I have ARM-based system
> running around 20 genirq UIO instances, and was demoting 2 of those
> from threaded to non-threaded IRQ handlers without any issues recorded
> to all the IRQ handlers. This patch actually is aimed exactly with the
> logic that if new property is not found - then system behavior is not
> amended, and all IRQs stays threaded. If needed, then a developer can
> enable this property for it's node, but then he should be well-aware
> of what this property implications are.
> 
> In average, using ftrace and kernelshark to analyze I observed the
> gain of 20-30 usec per chain: irq_handler_entry -> irq/XX-uio ->  space IRQ part> so I would say the gain is not very significant for
> average user-space task. However IMHO, there are several hidden
> benefits here with having this modification, namely:
> - It eliminates few re-scheduling operations, making INT ACK code more
> robust and relieves the pressure from the scheduler when HW interrupt
> for this IRQ is signaled at a high-enough frequency;
> - It makes top and bottom half to be executed back-to-back with IRQ
> OFF, making operation pseudo-atomic;
> - Above gain might be significant when average latency times for the
> systems are comparable.

Ok, that all seems like a good thing to have the ability to do here, you
should mention it in the changelog text when you redo this patch.

thanks,

greg k-h

Re: [patch 40/60] x86: PMD align entry text

[Borislav Petkov]

On Mon, Dec 04, 2017 at 03:07:46PM +0100, Thomas Gleixner wrote:
> From: Thomas Gleixner 
> 
> The (irq)entry text must be visible in the user space page tables. To allow
> simple PMD based sharing, make the entry text PMD aligned.
> 
> Signed-off-by: Thomas Gleixner 
> 
> ---
>  arch/x86/kernel/vmlinux.lds.S |8 
>  1 file changed, 8 insertions(+)

Reviewed-by: Borislav Petkov 

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

Re: [PATCHv4 3/4] x86/boot/compressed/64: Introduce place_trampoline()

[Matthew Wilcox]

On Thu, Dec 07, 2017 at 07:30:48AM +0100, Ingo Molnar wrote:
> > But if the bootloader put the kernel above 4G (not sure if anybody does
> > this), we would loose control as soon as paging is disabled as code
> > becomes unreachable.
> 
> Yeah, so instead of the double 'as' which is syntactically right but a bit 
> confusing to read, how about something like:
> 
>   But if the bootloader put the kernel above 4G (not sure if anybody does
>   this), we would loose control as soon as paging is disabled, because the
>   code becomes unreachable to the CPU.

btw, it's "lose control".

Re: [PATCH 1/1] codestyle issue fixed drivers/staging/vc04_services

[Stefan Wahren]

Hello Mikhail,

Am 07.12.2017 um 08:47 schrieb Mikhail Shvetsov:
> From: Mike 

please provide your full name and a changelog. Also the subject should
start with something like "staging: vchiq_arm:".

>
> Signed-off-by: Mike 
> ---
>  .../interface/vchiq_arm/vchiq_kern_lib.c   | 64 
> --
>  1 file changed, 35 insertions(+), 29 deletions(-)
>
> diff --git 
> a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c 
> b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
> index 34f746db19cd..d21bb154f78c 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
> @@ -65,10 +65,10 @@ vchiq_blocking_bulk_transfer(VCHIQ_SERVICE_HANDLE_T 
> handle, void *data,
>   unsigned int size, VCHIQ_BULK_DIR_T dir);
>  
>  /
> -*
> -*   vchiq_initialise
> -*
> -***/
> + *
> + *   vchiq_initialise
> + *
> + ***/

Instead of fixing the comment style, i prefer to drop this kind of
useless comments in a separate patch.

>  #define VCHIQ_INIT_RETRIES 10
>  VCHIQ_STATUS_T vchiq_initialise(VCHIQ_INSTANCE_T *instance_out)
>  {
> @@ -80,7 +80,9 @@ VCHIQ_STATUS_T vchiq_initialise(VCHIQ_INSTANCE_T 
> *instance_out)
>   vchiq_log_trace(vchiq_core_log_level, "%s called", __func__);
>  
>   /* VideoCore may not be ready due to boot up timing.
> -It may never be ready if kernel and firmware are mismatched, so 
> don't block forever. */
> +  * It may never be ready if kernel and firmware are mismatched, so don't
> +  * block forever.
> +  */
>   for (i = 0; i < VCHIQ_INIT_RETRIES; i++) {
>   state = vchiq_get_state();
>   if (state)
> @@ -93,7 +95,8 @@ VCHIQ_STATUS_T vchiq_initialise(VCHIQ_INSTANCE_T 
> *instance_out)
>   goto failed;
>   } else if (i > 0) {
>   vchiq_log_warning(vchiq_core_log_level,
> - "%s: videocore initialized after %d retries\n", 
> __func__, i);
> + "%s: videocore initialized after %d retries\n",
> + __func__, i);

This isn't a comment, so it should be a separate patch.

>   }
>  
>   instance = kzalloc(sizeof(*instance), GFP_KERNEL);
> @@ -121,10 +124,10 @@ VCHIQ_STATUS_T vchiq_initialise(VCHIQ_INSTANCE_T 
> *instance_out)
>  EXPORT_SYMBOL(vchiq_initialise);
>  
>  /
> -*
> -*   vchiq_shutdown
> -*
> -***/
> + *
> + *   vchiq_shutdown
> + *
> + ***/
>  
>  VCHIQ_STATUS_T vchiq_shutdown(VCHIQ_INSTANCE_T instance)
>  {
> @@ -169,10 +172,10 @@ VCHIQ_STATUS_T vchiq_shutdown(VCHIQ_INSTANCE_T instance)
>  EXPORT_SYMBOL(vchiq_shutdown);
>  
>  /
> -*
> -*   vchiq_is_connected
> -*
> -***/
> + *
> + *   vchiq_is_connected
> + *
> + ***/
>  
>  static int vchiq_is_connected(VCHIQ_INSTANCE_T instance)
>  {
> @@ -180,10 +183,10 @@ static int vchiq_is_connected(VCHIQ_INSTANCE_T instance)
>  }
>  
>  /
> -*
> -*   vchiq_connect
> -*
> -***/
> + *
> + *   vchiq_connect
> + *
> + ***/
>  
>  VCHIQ_STATUS_T vchiq_connect(VCHIQ_INSTANCE_T instance)
>  {
> @@ -215,10 +218,10 @@ VCHIQ_STATUS_T vchiq_connect(VCHIQ_INSTANCE_T instance)
>  EXPORT_SYMBOL(vchiq_connect);
>  
>  /
> -*
> -*   vchiq_add_service
> -*
> -***/
> + *
> + *   vchiq_add_service
> + *
> + ***/
>  
>  VCHIQ_STATUS_T vchiq_add_service(
>   VCHIQ_INSTANCE_T  instance,
> @@ -260,10 +263,10 @@ VCHIQ_STATUS_T vchiq_add_service(
>  EXPORT_SYMBOL(vchiq_add_service);
>  
>  /
> -*
> -*   vchiq_open_service
> -*
> -***/
> + *
> + *   vchiq_open_service
> + *
> + ***/
>  
>  VCHIQ_STATUS_T vchiq_open_service(
>   

[PATCH net-next 0/6] net: mvpp2: various improvements

[Antoine Tenart]

Hi all,

These patches are sent as a series to avoid any possible conflict, even
though there're not entirely related. I can send them separately if
needed. The series applies on today's net-next tree.

Patches 1-2 improve the TSO support, with one logic update: if the TSO
related buffers can't be allocate the feature is deactivated but the
driver won't fail to probe.

The other patches are small improvements.

Thanks!
Antoine

Antoine Tenart (5):
  net: mvpp2: only free the TSO header buffers when it was allocated
  net: mvpp2: disable TSO if its buffers cannot be allocated
  net: mvpp2: align values in ethtool get_coalesce
  net: mvpp2: report the tx-usec coalescing information to ethtool
  net: mvpp2: adjust the coalescing parameters

Yan Markman (1):
  net: mvpp2: split the max ring size from the default one

 drivers/net/ethernet/marvell/mvpp2.c | 79 ++--
 1 file changed, 58 insertions(+), 21 deletions(-)

-- 
2.14.3

Re: [PATCH 0/2] [RFC] Ktest: add email support

[Steven Rostedt]

Unfortunately not, and my internet at the hotel is dismissal. I can't get any 
work done this week.

-- Steve

On December 6, 2017 10:35:16 PM GMT+01:00, Tim Tianyang Chen 
 wrote:
>
>
>On 12/01/2017 03:55 PM, Steven Rostedt wrote:
>> On Tue, 21 Nov 2017 10:53:27 -0800
>> Tim Tianyang Chen  wrote:
>>
>>> This patch series will let users define mailer and email address for
>receiving
>>> notifications during automated testings. Users need to setup the
>specified mailer
>>> prior to using this feature.
>>>
>>> Emails will be sent when the script completes, is aborted due to
>errors or interrupted
>>> by Sig-Int.
>>>
>> Hi Tim,
>>
>> I was hoping to get to these this week, but unfortunately I wasn't
>able
>> to finish my current workload. I leave tomorrow for Germany, and
>> hopefully I can spend some time looking at these on that trip.
>>
>> Feel free to send me a ping if you don't hear from me next week.
>>
>> Thanks!
>>
>> -- Steve
>Hey Steve, did you get a chance to take a look at it yet?
>
>Thanks,
>Tim

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [tip:x86/mpx] x86/insn-eval: Add utility function to get segment descriptor

[Borislav Petkov]

On Wed, Dec 06, 2017 at 11:23:59PM -0800, Ricardo Neri wrote:
> In UMIP emulation we can potentially access the LDT twice. Once when
> determining the base address of the code segment and again when determining
> the base address and limit of the segment in which the result of the
> emulation is written. I guess that mm->context.ldt_seq needs to not change
> not only while decoding a particular linear address but across these two
> linear address decodings.

Yap, stuff which needs to see an *unchanged* LDT should use the cookie
to verify that and the LDT code should change the cookie when the LDT
is modified.

> Sure, I will look into implementing this idea and post patches for it.

Thanks!

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

Re: Multiple oom_reaper BUGs: unmap_page_range racing with exit_mmap

[Michal Hocko]

On Thu 07-12-17 16:20:47, Tetsuo Handa wrote:
[...]
> int main(int argc, char *argv[])
> {
>   int i;
>   char *stack;
>   if (fork() || fork() || setsid() == EOF || pipe(pipe_fd))
>   _exit(0);
>   stack = mmap(NULL, STACKSIZE * NUMTHREADS, PROT_WRITE | PROT_READ,
>MAP_ANONYMOUS | MAP_PRIVATE, EOF, 0);
>   for (i = 0; i < NUMTHREADS; i++)
>   if (clone(memory_eater, stack + (i + 1) * STACKSIZE,
> /*CLONE_THREAD | CLONE_SIGHAND | */CLONE_VM | 
> CLONE_FS |
> CLONE_FILES, NULL) == -1)
>   break;

Hmm, so you are creating a separate process (from the signal point of
view) and I suspect it is one of those that holds the last reference to
the mm_struct which is released here and it has tsk_oom_victim = F

[...]
> [  113.273394] Freed by task 1377:
> [  113.276211]  kasan_slab_free+0x71/0xc0
> [  113.279093]  kmem_cache_free+0xaf/0x1e0
> [  113.281974]  remove_vma+0x9d/0xb0
> [  113.284734]  exit_mmap+0x179/0x250
> [  113.287651]  mmput+0x7d/0x1b0
> [  113.290456]  do_exit+0x408/0x1290
> [  113.293268]  do_group_exit+0x84/0x140
> [  113.296109]  get_signal+0x291/0x9b0
> [  113.298915]  do_signal+0x8e/0xa70
> [  113.301637]  exit_to_usermode_loop+0x71/0xb0
> [  113.304632]  do_syscall_64+0x343/0x390
> [  113.307349]  return_from_SYSCALL_64+0x0/0x75

[...]

> What we overlooked is the fact that "it is not always the process which
> got ->signal->oom_mm set, it is any thread which called mmput() which
> invoked __mmput() path". Therefore, below patch fixes oops in my case.
> If some unrelated kernel thread was holding mm_users ref, it is possible
> that we miss down_write()/up_write() synchronization.

Very well spotted! It could be any task in fact (e.g. somebody reading
from /proc/ file which requires mm_struct).

oom_reaper  oom_victim  task
mmget_not_zero
exit_mmap
  mmput
__oom_reap_task_mm  mmput
  __mmput
exit_mmap
  remove_vma
  unmap_page_range

So we need a more robust test for the oom victim. Your suggestion is
basically what I came up with originally [1] and which was deemed
ineffective because we took the mmap_sem even for regular paths and
Kirill was afraid this adds some unnecessary cycles to the exit path
which is quite hot.

So I guess we have to do something else instead. We have to store the
oom flag to the mm struct as well. Something like the patch below.

[1] http://lkml.kernel.org/r/20170724072332.31903-1-mho...@kernel.org
---
diff --git a/include/linux/oom.h b/include/linux/oom.h
index 27cd36b762b5..b7668b5d3e14 100644
--- a/include/linux/oom.h
+++ b/include/linux/oom.h
@@ -77,6 +77,11 @@ static inline bool tsk_is_oom_victim(struct task_struct * 
tsk)
return tsk->signal->oom_mm;
 }
 
+static inline bool mm_is_oom_victim(struct mm_struct *mm)
+{
+   return test_bit(MMF_OOM_VICTIM, >flags);
+}
+
 /*
  * Checks whether a page fault on the given mm is still reliable.
  * This is no longer true if the oom reaper started to reap the
diff --git a/include/linux/sched/coredump.h b/include/linux/sched/coredump.h
index 9c8847395b5e..da673ca66e7a 100644
--- a/include/linux/sched/coredump.h
+++ b/include/linux/sched/coredump.h
@@ -68,8 +68,9 @@ static inline int get_dumpable(struct mm_struct *mm)
 #define MMF_RECALC_UPROBES 20  /* MMF_HAS_UPROBES can be wrong */
 #define MMF_OOM_SKIP   21  /* mm is of no interest for the OOM 
killer */
 #define MMF_UNSTABLE   22  /* mm is unstable for copy_from_user */
-#define MMF_HUGE_ZERO_PAGE 23  /* mm has ever used the global huge 
zero page */
-#define MMF_DISABLE_THP24  /* disable THP for all VMAs */
+#define MMF_OOM_VICTIM 23  /* mm is the oom victim */
+#define MMF_HUGE_ZERO_PAGE 24  /* mm has ever used the global huge 
zero page */
+#define MMF_DISABLE_THP25  /* disable THP for all VMAs */
 #define MMF_DISABLE_THP_MASK   (1 << MMF_DISABLE_THP)
 
 #define MMF_INIT_MASK  (MMF_DUMPABLE_MASK | MMF_DUMP_FILTER_MASK |\
diff --git a/mm/mmap.c b/mm/mmap.c
index 476e810cf100..d00a06248ef1 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -3005,7 +3005,7 @@ void exit_mmap(struct mm_struct *mm)
unmap_vmas(, vma, 0, -1);
 
set_bit(MMF_OOM_SKIP, >flags);
-   if (unlikely(tsk_is_oom_victim(current))) {
+   if (unlikely(mm_is_oom_victim(mm))) {
/*
 * Wait for oom_reap_task() to stop working on this
 * mm. Because MMF_OOM_SKIP is already set before
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 3b0d0fed8480..e4d290b6804b 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c

Re: [PATCH] ACPI / GED: unregister interrupts during shutdown

[Greg Kroah-Hartman]

On Thu, Dec 07, 2017 at 12:19:25AM +0100, Rafael J. Wysocki wrote:
> Hi Greg,
> 
> On Wed, Dec 6, 2017 at 6:16 PM, Rafael J. Wysocki  wrote:
> > On Wed, Dec 6, 2017 at 5:55 PM, Sinan Kaya  wrote:
> >> On 12/6/2017 11:41 AM, Rafael J. Wysocki wrote:
> >>> On Wed, Dec 6, 2017 at 5:11 PM, Sinan Kaya  wrote:
>  On 12/6/2017 9:57 AM, Sinan Kaya wrote:
> >> Yes, it should, so I'm not sure why you need the list in the first 
> >> place.
> >>
> >> Also it looks like something along the lines of devres_release_all()
> >> should be sufficient.
> > Good suggestion, let me test this.
> >
> 
>  I tried to pull the code into GED but the API is not public. I also 
>  looked
>  at how it is used. I was afraid to mess up with the internals of base.c 
>  by
>  calling devres_release_all() externally first and by the driver framework
>  next. I moved away from this approach.
> >>>
> >>> Are you sure it is called by the core in the shutdown path?
> >>
> >> Sorry, I was thinking about a general case not the shutdown path. If we 
> >> open
> >> this API and have device drivers call it from arbitrary places; then we 
> >> could
> >> be opening a new can of worms that show up during device driver removal.
> 
> [cut]
> 
> >
> > OK
> >
> > Anyway, it looks like something is missing in the core.
> >
> > You shouldn't really need to do all that dance in a driver.
> 
> We have a problem with the ACPI GED driver which essentially is a
> platform driver requesting a number of interrupts and handling them by
> dispatching a specific AML method.
> 
> It uses devm_request_threaded_irq() to request the interrupts, so it
> doesn't need a ->remove() callback, but it turns out to need a
> ->shutdown() one to free all of these interrupts at the shutdown time.
> 
> While we can add a ->shutdown() callback to it, that essentially needs
> to duplicate devres_release_all() somewhat.
> 
> Any suggestions what to do with that?

Just don't use devm_request_threaded_irq()?  :)

Seriously, those are just "helper" functions if your code happens to
follow the pattern they provide, if not, then don't use them, it's not
that hard to provide the correct code to unwind things properly by "open
coding" this logic as needed.

The devm_*irq() functions are known for not being able to be used all of
the time for lots of shutdown and cleanup issues, this isn't the first
time it has happened, which is why we are very careful when taking
"cleanup" patches that use those functions.

thanks,

greg k-h

Re: [PATCH 01/10] staging: ccree: remove inline qualifiers

[Dan Carpenter]

On Thu, Dec 07, 2017 at 09:00:11AM +0200, Gilad Ben-Yossef wrote:
> On Mon, Dec 4, 2017 at 11:36 AM, Dan Carpenter  
> wrote:
> > On Sun, Dec 03, 2017 at 01:58:12PM +, Gilad Ben-Yossef wrote:
> >> The ccree drivers was marking a lot of big functions in C file as
> >> static inline for no good reason. Remove the inline qualifier from
> >> any but the few truly single line functions.
> >>
> >
> > The compiler is free to ignore inline hints...  It probably would make
> > single line functions inline anyway.
> >
> 
> Yes. I think of it more as a note to the reader: "don't add stuff to
> this function. it is meant to be short and simple".
> 

Ah.  Fine.

regards,
dan carpenter

Re: [PATCH RT] vfio-pci: Set MSI/MSI-X ISR to non-threaded

[Steven Rostedt]

On Thu, 7 Dec 2017 01:27:03 +
"Su, David W"  wrote:

> >And spin_lock() turns into a mutex in PREEMPT_RT, which means it can
> >sleep. You can't sleep in hard interrupt context. This will eventually
> >crash the kernel.  
> 
> Steve, thanks for your review and comment.
> 
> I can think of 2 scenarios where there is contention for the eventfd
> context lock.
> 
> One scenario is an eventfd is used to notify a VFIO application of
> 2 or more IRQs.  But in this case the application wouldn't be able to
> tell which IRQ occurred and so I think it should be considered a
> programming error of the application and not a proper usage of
> VFIO.

Remember, if there is contention, the system will CRASH! Boom, panic,
end of story. Are you blowing this off to just a programming error of
the application? I'm sure lots of root kit developers are excited about
this.

> 
> The other is a device IRQ is configured to be delivered to multiple
> CPU cores at the same time.  However, I have never seen such a
> device and cannot think of any good reason for a device to be
> designed this way.
> 
> So, IMHO it is safe to set vfio-pci ISR to non-threaded.

Please tell me that you are not arguing that it's OK to have a sleeping
mutex in a hard threaded IRQ handler because "proper programming will
prevent contention". If that is truly your argument, then I'm done
here, with a perpetual NACK on your patches.

-- Steve

> 
> >
> >And no, we are not going to convert the ctx->wqh.lock into a
> >raw_spin_lock.
> >

Re: [PATCH] drm/sun4i: Fix uninitialized variables in vi layer

[Maxime Ripard]

Hi,

On Wed, Dec 06, 2017 at 04:26:03PM +0100, Jernej Skrabec wrote:
> min_scale and max_scale in sun8i_vi_layer_atomic_check() can be used
> without initialization.
> 
> Fix that.
> 
> Fixes:b862a648de3b (drm/sun4i: Add support for HW scaling to DE2)
> 
> Signed-off-by: Jernej Skrabec 

I've applied this, but your fixes tag was at the wrong format. You
should use the one documented here:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes

or you can even use the git option to generate it directly.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

[PATCH net-next 4/6] net: mvpp2: align values in ethtool get_coalesce

[Antoine Tenart]

Cosmetic patch aligning values in the ethtool get_coalesce function.
This patch do not modify in anyway the driver's behaviour.

Signed-off-by: Antoine Tenart 
---
 drivers/net/ethernet/marvell/mvpp2.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2.c 
b/drivers/net/ethernet/marvell/mvpp2.c
index 1e4129f71071..65e2e5338f66 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -7354,9 +7354,9 @@ static int mvpp2_ethtool_get_coalesce(struct net_device 
*dev,
 {
struct mvpp2_port *port = netdev_priv(dev);
 
-   c->rx_coalesce_usecs= port->rxqs[0]->time_coal;
-   c->rx_max_coalesced_frames  = port->rxqs[0]->pkts_coal;
-   c->tx_max_coalesced_frames =  port->txqs[0]->done_pkts_coal;
+   c->rx_coalesce_usecs   = port->rxqs[0]->time_coal;
+   c->rx_max_coalesced_frames = port->rxqs[0]->pkts_coal;
+   c->tx_max_coalesced_frames = port->txqs[0]->done_pkts_coal;
return 0;
 }
 
-- 
2.14.3

[PATCH net-next 3/6] net: mvpp2: split the max ring size from the default one

[Antoine Tenart]

From: Yan Markman 

The Rx/Tx ring sizes can be adjusted thanks to ethtool given specific
network needs. This commit splits the default ring size from its max
value to allow ethtool to vary the parameters in both ways.

Signed-off-by: Yan Markman 
[Antoine: commit message]
Signed-off-by: Antoine Tenart 
---
 drivers/net/ethernet/marvell/mvpp2.c | 24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2.c 
b/drivers/net/ethernet/marvell/mvpp2.c
index 2f86358614a6..1e4129f71071 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -504,10 +504,12 @@
 #define MVPP2_DEFAULT_RXQ  4
 
 /* Max number of Rx descriptors */
-#define MVPP2_MAX_RXD  128
+#define MVPP2_MAX_RXD_MAX  1024
+#define MVPP2_MAX_RXD_DFLT 128
 
 /* Max number of Tx descriptors */
-#define MVPP2_MAX_TXD  1024
+#define MVPP2_MAX_TXD_MAX  2048
+#define MVPP2_MAX_TXD_DFLT 1024
 
 /* Amount of Tx descriptors that can be reserved at once by CPU */
 #define MVPP2_CPU_DESC_CHUNK   64
@@ -6866,13 +6868,13 @@ static int mvpp2_check_ringparam_valid(struct 
net_device *dev,
if (ring->rx_pending == 0 || ring->tx_pending == 0)
return -EINVAL;
 
-   if (ring->rx_pending > MVPP2_MAX_RXD)
-   new_rx_pending = MVPP2_MAX_RXD;
+   if (ring->rx_pending > MVPP2_MAX_RXD_MAX)
+   new_rx_pending = MVPP2_MAX_RXD_MAX;
else if (!IS_ALIGNED(ring->rx_pending, 16))
new_rx_pending = ALIGN(ring->rx_pending, 16);
 
-   if (ring->tx_pending > MVPP2_MAX_TXD)
-   new_tx_pending = MVPP2_MAX_TXD;
+   if (ring->tx_pending > MVPP2_MAX_TXD_MAX)
+   new_tx_pending = MVPP2_MAX_TXD_MAX;
else if (!IS_ALIGNED(ring->tx_pending, 32))
new_tx_pending = ALIGN(ring->tx_pending, 32);
 
@@ -7374,8 +7376,8 @@ static void mvpp2_ethtool_get_ringparam(struct net_device 
*dev,
 {
struct mvpp2_port *port = netdev_priv(dev);
 
-   ring->rx_max_pending = MVPP2_MAX_RXD;
-   ring->tx_max_pending = MVPP2_MAX_TXD;
+   ring->rx_max_pending = MVPP2_MAX_RXD_MAX;
+   ring->tx_max_pending = MVPP2_MAX_TXD_MAX;
ring->rx_pending = port->rx_ring_size;
ring->tx_pending = port->tx_ring_size;
 }
@@ -7822,7 +7824,7 @@ static int mvpp2_port_probe(struct platform_device *pdev,
goto err_free_netdev;
}
 
-   dev->tx_queue_len = MVPP2_MAX_TXD;
+   dev->tx_queue_len = MVPP2_MAX_TXD_MAX;
dev->watchdog_timeo = 5 * HZ;
dev->netdev_ops = _netdev_ops;
dev->ethtool_ops = _eth_tool_ops;
@@ -7905,8 +7907,8 @@ static int mvpp2_port_probe(struct platform_device *pdev,
 
mvpp2_port_copy_mac_addr(dev, priv, port_node, _from);
 
-   port->tx_ring_size = MVPP2_MAX_TXD;
-   port->rx_ring_size = MVPP2_MAX_RXD;
+   port->tx_ring_size = MVPP2_MAX_TXD_DFLT;
+   port->rx_ring_size = MVPP2_MAX_RXD_DFLT;
SET_NETDEV_DEV(dev, >dev);
 
err = mvpp2_port_init(port);
-- 
2.14.3

Re: [PATCH V6 01/12] drivers: move clock common macros out from vendor directories

[Chunyan Zhang]

On 7 December 2017 at 14:47, Stephen Boyd  wrote:
> On 11/27, Chunyan Zhang wrote:
>> These macros are used by more than one SoC vendor platforms, avoid to
>> have many copies of these code, this patch moves them to the common
>> clock directory which every clock drivers can access to.
>>
>> Signed-off-by: Chunyan Zhang 
>> ---
>>  drivers/clk/clk_common.h | 60 
>> 
>>  1 file changed, 60 insertions(+)
>>  create mode 100644 drivers/clk/clk_common.h
>>
>> diff --git a/drivers/clk/clk_common.h b/drivers/clk/clk_common.h
>> new file mode 100644
>> index 000..21e93d2
>> --- /dev/null
>> +++ b/drivers/clk/clk_common.h
>> @@ -0,0 +1,60 @@
>> +/*
>> + * drivers/clk/clk_common.h
>
> We don't need this in the file too. Please remove this line.
>
>> + *
>> + * SPDX-License-Identifier: GPL-2.0
>> + */
>> +
>> +#ifndef _CLK_COMMON_H_
>> +#define _CLK_COMMON_H_
>> +
>> +#include 
>
> Maybe these macros should just go into clk-provider.h?

Ok.  And I will also remove the same macros from sunxi-ng/ccu_common.h
and zte/clk.h.

>
>> +
>> +#define CLK_HW_INIT(_name, _parent, _ops, _flags)\
>> + (&(struct clk_init_data) {  \
>> + .flags  = _flags,   \
>> + .name   = _name,\
>> + .parent_names   = (const char *[]) { _parent }, \
>> + .num_parents= 1,\
>> + .ops= _ops, \
>> + })
>
> Hopefully we don't extend the init structure anymore to have
> something else. I guess we'll do something if that happens.
>
>> +
>> +#define CLK_HW_INIT_PARENTS(_name, _parents, _ops, _flags)   \
>> + (&(struct clk_init_data) {  \
>> + .flags  = _flags,   \
>> + .name   = _name,\
>> + .parent_names   = _parents, \
>> + .num_parents= ARRAY_SIZE(_parents), \
>> + .ops= _ops, \
>> + })
>> +
>> +#define CLK_HW_INIT_NO_PARENT(_name, _ops, _flags) \
>> + (&(struct clk_init_data) {  \
>> + .flags  = _flags,   \
>> + .name   = _name,\
>> + .parent_names   = NULL, \
>> + .num_parents= 0,\
>> + .ops= _ops, \
>> + })
>> +
>> +#define CLK_FIXED_FACTOR(_struct, _name, _parent,\
>> + _div, _mult, _flags)\
>> + struct clk_fixed_factor _struct = { \
>> + .div= _div, \
>> + .mult   = _mult,\
>> + .hw.init= CLK_HW_INIT(_name,\
>> +   _parent,  \
>> +   _fixed_factor_ops,\
>> +   _flags),  \
>> + }
>> +
>> +#define CLK_FIXED_RATE(_struct, _name, _flags,  
>>  \
>> +_fixed_rate, _fixed_accuracy)\
>> + struct clk_fixed_rate _struct = {   \
>> + .fixed_rate = _fixed_rate,  \
>> + .fixed_accuracy = _fixed_accuracy,  \
>> + .hw.init= CLK_HW_INIT_NO_PARENT(_name,  \
>> +   _fixed_rate_ops,  \
>> + _flags),\
>> + }
>
> Maybe don't add this one? Usually fixed rate clks come from DT.

Ok, will also move the fixed rate clks from our driver to DT.

Thanks,
Chunyan

>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

Re: general protection fault in lockdep_invariant_state (2)

[Dmitry Vyukov]

On Wed, Dec 6, 2017 at 5:31 PM, Dmitry Vyukov  wrote:
>>>  > R13: 00402260 R14: 004022f0 R15: 
>>>  > kasan: CONFIG_KASAN_INLINE enabled
>>>  > kasan: GPF could be caused by NULL-ptr deref or user memory access
>>>  > general protection fault:  [#1] SMP KASAN
>>>  > Dumping ftrace buffer:
>>>  >(ftrace buffer empty)
>>>  > Modules linked in:
>>>  > CPU: 3 PID: 2982 Comm: syzkaller521009 Not tainted 
>>>  > 4.14.0-rc7-next-20171103+
>>>  > #10
>>>  > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 
>>>  > 01/01/2011
>>>  > task: 88003d6b25c0 task.stack: 88003abd
>>>  > RIP: 0010:invalidate_xhlock kernel/locking/lockdep.c:4719 [inline]
>>>  > RIP: 0010:lockdep_invariant_state+0xd6/0x120 
>>>  > kernel/locking/lockdep.c:4793
>>> >>>
>>> >>>
>>> >>> Does this help?
>>> >>>
>>> >>> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
>>> >>> index db933d063bfc..da2904418599 100644
>>> >>> --- a/kernel/locking/lockdep.c
>>> >>> +++ b/kernel/locking/lockdep.c
>>> >>> @@ -4793,7 +4793,8 @@ void lockdep_invariant_state(bool force)
>>> >>>  * Verify the former, enforce the latter.
>>> >>>  */
>>> >>> WARN_ON_ONCE(!force && current->lockdep_depth);
>>> >>> -   invalidate_xhlock((current->xhlock_idx));
>>> >>> +   if (current->xhlocks)
>>> >>> +   invalidate_xhlock((current->xhlock_idx));
>>> >>>  }
>>> >>>
>>> >>>  static int cross_lock(struct lockdep_map *lock)
>>> >>
>>> >>
>>> >> Hi Peter,
>>> >>
>>> >> We are not able to test all fixes for all bugs, but we are rolling out
>>> >> a patch testing feature for syzbot:
>>> >>
>>> >> https://github.com/google/syzkaller/blob/master/docs/syzbot.md#communication-with-syzbot
>>> >>
>>> >> Please give it a try!
>>> >
>>> >
>>> > Peter, ping.
>>> > This still happens. Please either submit the fix if you already tested
>>> > it, or test using syzbot and submit.
>>>
>>>
>>> Peter, do you want me to mail your patch?
>>
>> Urgh, sorry, got stuck doing KAISER muck. I'll go write up a proper
>> patch.
>
> Thanks!



I see the patch is landed in tip. Please also follow this part:

> syzbot will keep track of this bug report.
> Once a fix for this bug is committed, please reply to this email with:
> #syz fix: exact-commit-title
> Note: all commands must start from beginning of the line.

This will greatly help to keep the process running.

Re: [PATCH 1/1] zram: better utilization of zram swap space

[Sergey Senozhatsky]

On (12/07/17 13:52), Gopi Sai Teja wrote:
> If the length of the compressed page is greater than 75% of the PAGE_SIZE,
> then the page is stored uncompressed in zram space. Zram space utilization
> is improved if the threshold is 80%(5 compressed pages can be stored in
> 4 pages).
> 
> If the compressed length is greater than 3068 and less than 3261, pages
> still can be stored in compressed form in zs_malloc class 3264.
> Currently these compressed pages belong to 4096 zs malloc class.

so this makes sense. I had another idea awhile ago

lkml.kernel.org/r/1456061274-20059-2-git-send-email-sergey.senozhat...@gmail.com

in short, 3261 is good, but not as good as it possibly can be. for the
time being, our huge-class watermark starts at 3264. but this can
change.


a side note, I think we have sort of wrong API. zsmalloc knows better which
object is huge. and who knows, may be we will change the number of huge
classes someday or huge-class watermark, etc. so having "hey zsmalloc, is
this object huge or not" API seems to be better than ZRAM's enforcement
"hey zsmalloc, this object is huge".

-ss

[PATCH V2] ACPI / LPSS: Add device link for CHT SD card dependency on I2C

[Adrian Hunter]

Some Cherry Trail boards have a dependency between the SDHCI host
controller used for SD cards and an external PMIC accessed via I2C. Add a
device link between the SDHCI host controller (consumer) and the I2C
adapter (supplier).

This patch depends on a fix to devices links, namely commit 0ff26c662d5f
("driver core: Fix device link deferred probe"). And also either,
commit 126dbc6b49c8 ("PM: i2c-designware-platdrv: Clean up PM handling in
probe"), or patch "PM / runtime: Fix handling of suppliers with disabled
runtime PM".

Signed-off-by: Adrian Hunter 
---


Changes in V2:

Add a comment about why it is necessary to hardcode the links
information in the code


 drivers/acpi/acpi_lpss.c | 146 +++
 1 file changed, 146 insertions(+)

diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 7f2b02cc8ea1..9cfe6b71078b 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -290,6 +290,11 @@ static void bsw_pwm_setup(struct lpss_private_data *pdata)
{}
 };
 
+static const struct x86_cpu_id cht_cpu[] = {
+   ICPU(INTEL_FAM6_ATOM_AIRMONT),  /* Braswell, Cherry Trail */
+   {}
+};
+
 #else
 
 #define LPSS_ADDR(desc) (0UL)
@@ -427,6 +432,146 @@ static int register_device_clock(struct acpi_device *adev,
return 0;
 }
 
+struct lpss_device_links {
+   const char *supplier_hid;
+   const char *supplier_uid;
+   const char *consumer_hid;
+   const char *consumer_uid;
+   const struct x86_cpu_id *cpus;
+   u32 flags;
+};
+
+/*
+ * The _DEP method is used to identify dependencies but instead of creating
+ * device links for every handle in _DEP, only links in the following list are
+ * created. That is necessary because, in the general case, _DEP can refer to
+ * devices that might not have drivers, or that are on different buses, or 
where
+ * the supplier is not enumerated until after the consumer is probed.
+ */
+static const struct lpss_device_links lpss_device_links[] = {
+   {"808622C1", "7", "80860F14", "3", cht_cpu, DL_FLAG_PM_RUNTIME},
+};
+
+static bool hid_uid_match(const char *hid1, const char *uid1,
+ const char *hid2, const char *uid2)
+{
+   return !strcmp(hid1, hid2) && uid1 && uid2 && !strcmp(uid1, uid2);
+}
+
+static bool acpi_lpss_is_supplier(struct acpi_device *adev,
+ const struct lpss_device_links *link)
+{
+   return hid_uid_match(acpi_device_hid(adev), acpi_device_uid(adev),
+link->supplier_hid, link->supplier_uid);
+}
+
+static bool acpi_lpss_is_consumer(struct acpi_device *adev,
+ const struct lpss_device_links *link)
+{
+   return hid_uid_match(acpi_device_hid(adev), acpi_device_uid(adev),
+link->consumer_hid, link->consumer_uid);
+}
+
+struct hid_uid {
+   const char *hid;
+   const char *uid;
+};
+
+static int match_hid_uid(struct device *dev, void *data)
+{
+   struct acpi_device *adev = ACPI_COMPANION(dev);
+   struct hid_uid *id = data;
+
+   if (!adev)
+   return 0;
+
+   return hid_uid_match(acpi_device_hid(adev), acpi_device_uid(adev),
+id->hid, id->uid);
+}
+
+static struct device *acpi_lpss_find_device(const char *hid, const char *uid)
+{
+   struct hid_uid data = {
+   .hid = hid,
+   .uid = uid,
+   };
+
+   return bus_find_device(_bus_type, NULL, , match_hid_uid);
+}
+
+static bool acpi_lpss_dep(struct acpi_device *adev, acpi_handle handle)
+{
+   struct acpi_handle_list dep_devices;
+   acpi_status status;
+   int i;
+
+   if (!acpi_has_method(adev->handle, "_DEP"))
+   return false;
+
+   status = acpi_evaluate_reference(adev->handle, "_DEP", NULL,
+_devices);
+   if (ACPI_FAILURE(status)) {
+   dev_dbg(>dev, "Failed to evaluate _DEP.\n");
+   return false;
+   }
+
+   for (i = 0; i < dep_devices.count; i++) {
+   if (dep_devices.handles[i] == handle)
+   return true;
+   }
+
+   return false;
+}
+
+static void acpi_lpss_link_consumer(struct device *dev1,
+   const struct lpss_device_links *link)
+{
+   struct device *dev2;
+
+   dev2 = acpi_lpss_find_device(link->consumer_hid, link->consumer_uid);
+   if (!dev2)
+   return;
+
+   if (acpi_lpss_dep(ACPI_COMPANION(dev2), ACPI_HANDLE(dev1)))
+   device_link_add(dev2, dev1, link->flags);
+
+   put_device(dev2);
+}
+
+static void acpi_lpss_link_supplier(struct device *dev1,
+   const struct lpss_device_links *link)
+{
+   struct device *dev2;
+
+   dev2 = acpi_lpss_find_device(link->supplier_hid, link->supplier_uid);
+   if (!dev2)
+   return;

Re: [PATCH 3/8] mfd: axp20x: probe axp20x_adc driver for AXP813

[Quentin Schulz]

Hi Chen-Yu,

On 07/12/2017 09:54, Chen-Yu Tsai wrote:
> On Thu, Dec 7, 2017 at 4:51 PM, Quentin Schulz
>  wrote:
>> Hi Maxime,
>>
>> On 05/12/2017 09:08, Maxime Ripard wrote:
>>> On Mon, Dec 04, 2017 at 03:12:49PM +0100, Quentin Schulz wrote:
 This makes the axp20x_adc driver probe with platform device id
 "axp813-adc".

 Signed-off-by: Quentin Schulz 
 ---
  drivers/mfd/axp20x.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

 diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
 index 2468b43..42e54d1 100644
 --- a/drivers/mfd/axp20x.c
 +++ b/drivers/mfd/axp20x.c
 @@ -878,7 +878,9 @@ static struct mfd_cell axp813_cells[] = {
  .resources  = axp803_pek_resources,
  }, {
  .name   = "axp20x-regulator",
 -}
 +}, {
 +.name   = "axp813-adc",
 +},
>>>
>>> Any particular reason you're not adding it to the DT?
>>>
>>
>> No, no particular reason. It's just the way it is currently for AXP209
>> and AXP22x so did the same for AXP813.
>>
>> I'll add DT "support" in next version for all AXPs supported by this
>> driver. Or is it worthy of a small separate patch series?
> 
> IIRC there's no DT support because there's no need to reference
> it in the device tree.
> 

No current need but that does not mean there won't be a need later for
drivers to map IIO channels from the ADC driver (i.e. some components
wired to GPIOs of the PMIC for example).

Quentin
-- 
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v2] ARM: dts: sun8i: h3: enable USB OTG for NanoPi Neo board

[Maxime Ripard]

On Tue, Dec 05, 2017 at 11:03:58PM +0100, Krzysztof Adamski wrote:
> Similarly to Orange Pi Zero, NanoPi Neo board has an USB OTG port with
> an ID pin but with unpowered VBUS. This patch enables this port in
> forced peripheral mode.
> 
> ohci/ehci nodes are still enabled since the host mode may work if
> external power source is used. In that case, the mode can be switched
> for example via sysfs. The same strategy is used for Orange Pi Zero
> board DTS.
> 
> Signed-off-by: Krzysztof Adamski 

Applied, thanks!

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH 8/9] ARM: dts: imx7-colibri: add MCP2515 CAN controller

[Stefan Agner]

On 2017-12-06 16:30, Stefan Agner wrote:
> The Colibri Evaluation Carrier Board provides a MCP2515 CAN
> controller connected via SPI. Note that the i.MX 7 provides
> an internal CAN controller which is much better suited for CAN
> operations. Using the MCP2515 with a Colibri iMX7 module is
> mainly useful to test the SPI interface.
> 
> Signed-off-by: Stefan Agner 
> ---
>  arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi | 25 +
>  arch/arm/boot/dts/imx7-colibri.dtsi | 14 +-
>  2 files changed, 38 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
> b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
> index 87c23b769a08..3d6c282dd258 100644
> --- a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
> +++ b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
> @@ -45,6 +45,13 @@
>   stdout-path = "serial0:115200n8";
>   };
>  
> + /* fixed crystal dedicated to mpc258x */
> + clk16m: clk16m {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <1600>;
> + };
> +
>   panel: panel {
>   compatible = "edt,et057090dhu";
>   backlight = <>;
> @@ -99,6 +106,24 @@
>   status = "okay";
>  };
>  
> + {
> + status = "okay";
> +
> + mcp258x0: mcp258x@0 {


Just realized that this is somewhat bogus, this should be "mcp2515:
can@0".

--
Stefan

> + compatible = "microchip,mcp2515";
> + pinctrl-names = "default";
> + pinctrl-0 = <_can_int>;
> + reg = <0>;
> + clocks = <>;
> + interrupt-parent = <>;
> + interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
> + spi-max-frequency = <1000>;
> + vdd-supply = <_3v3>;
> + xceiver-supply = <_5v0>;
> + status = "okay";
> + };
> +};
> +
>   {
>   status = "okay";
>  };
> diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi
> b/arch/arm/boot/dts/imx7-colibri.dtsi
> index 689ff6822634..e1c6da0a65e4 100644
> --- a/arch/arm/boot/dts/imx7-colibri.dtsi
> +++ b/arch/arm/boot/dts/imx7-colibri.dtsi
> @@ -92,6 +92,13 @@
>   cpu-supply = <_DCDC2>;
>  };
>  
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_ecspi3 _ecspi3_cs>;
> + num-cs = <1>;
> + cs-gpios = < 11 GPIO_ACTIVE_HIGH>;
> +};
> +
>   {
>   pinctrl-names = "default";
>   pinctrl-0 = <_enet1>;
> @@ -313,7 +320,6 @@
>   fsl,pins = <
>   MX7D_PAD_ENET1_RGMII_RD3__GPIO7_IO3 0x74 /* SODIMM 
> 55 */
>   MX7D_PAD_ENET1_RGMII_RD2__GPIO7_IO2 0x74 /* SODIMM 
> 63 */
> - MX7D_PAD_SD1_RESET_B__GPIO5_IO2 0X14 /* SODIMM 
> 73 */
>   MX7D_PAD_SAI1_RX_SYNC__GPIO6_IO16   0x14 /* SODIMM 
> 77 */
>   MX7D_PAD_EPDC_DATA09__GPIO2_IO9 0x14 /* SODIMM 
> 89 */
>   MX7D_PAD_EPDC_DATA08__GPIO2_IO8 0x74 /* SODIMM 
> 91 */
> @@ -400,6 +406,12 @@
>   >;
>   };
>  
> + pinctrl_can_int: can-int-grp {
> + fsl,pins = <
> + MX7D_PAD_SD1_RESET_B__GPIO5_IO2 0X14 /* SODIMM 
> 73 */
> + >;
> + };
> +
>   pinctrl_enet1: enet1grp {
>   fsl,pins = <
>   MX7D_PAD_ENET1_CRS__GPIO7_IO14  0x14

Re: [PATCH 3/8] mfd: axp20x: probe axp20x_adc driver for AXP813

[Chen-Yu Tsai]

On Thu, Dec 7, 2017 at 5:03 PM, Quentin Schulz
 wrote:
> Hi Chen-Yu,
>
> On 07/12/2017 09:54, Chen-Yu Tsai wrote:
>> On Thu, Dec 7, 2017 at 4:51 PM, Quentin Schulz
>>  wrote:
>>> Hi Maxime,
>>>
>>> On 05/12/2017 09:08, Maxime Ripard wrote:
 On Mon, Dec 04, 2017 at 03:12:49PM +0100, Quentin Schulz wrote:
> This makes the axp20x_adc driver probe with platform device id
> "axp813-adc".
>
> Signed-off-by: Quentin Schulz 
> ---
>  drivers/mfd/axp20x.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 2468b43..42e54d1 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -878,7 +878,9 @@ static struct mfd_cell axp813_cells[] = {
>  .resources  = axp803_pek_resources,
>  }, {
>  .name   = "axp20x-regulator",
> -}
> +}, {
> +.name   = "axp813-adc",
> +},

 Any particular reason you're not adding it to the DT?

>>>
>>> No, no particular reason. It's just the way it is currently for AXP209
>>> and AXP22x so did the same for AXP813.
>>>
>>> I'll add DT "support" in next version for all AXPs supported by this
>>> driver. Or is it worthy of a small separate patch series?
>>
>> IIRC there's no DT support because there's no need to reference
>> it in the device tree.
>>
>
> No current need but that does not mean there won't be a need later for
> drivers to map IIO channels from the ADC driver (i.e. some components
> wired to GPIOs of the PMIC for example).

Hmm... Why would you map the IIO channels from the ADC? I thought those
were all accessible from userspace?

However, proper muxing of the GPIO pin to the ADC function makes sense.

ChenYu

Re: [tip:x86/mpx] x86/insn-eval: Add utility function to get segment descriptor

[Borislav Petkov]

On Wed, Dec 06, 2017 at 11:26:05PM -0800, Ricardo Neri wrote:
> At the moment MPX and UMIP are using the insn-eval decoder to determine
> linear addresses.

If we're keeping a whole instruction decoder in the kernel, it better
be designed generically enough and usable (and used) by everything that
needs it.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

[PATCH v1 1/2] ASoC: rsnd: ssi: fix race condition in rsnd_ssi_pointer_update

[jiada_wang]

From: Jiada Wang 

Currently there is race condition between set of byte_pos and wrap
it around when new buffer starts. If .pointer is called in-between
it will result in inconsistent pointer position be returned
from .pointer callback.

This patch increments buffer pointer atomically to avoid this issue.

Signed-off-by: Jiada Wang 
Reviewed-by: Takashi Sakamoto 
---
 sound/soc/sh/rcar/ssi.c |   16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/sound/soc/sh/rcar/ssi.c b/sound/soc/sh/rcar/ssi.c
index fece1e5f..cbf3bf3 100644
--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -446,25 +446,29 @@ static bool rsnd_ssi_pointer_update(struct rsnd_mod *mod,
int byte)
 {
struct rsnd_ssi *ssi = rsnd_mod_to_ssi(mod);
+   bool ret = false;
+   int byte_pos;
 
-   ssi->byte_pos += byte;
+   byte_pos = ssi->byte_pos + byte;
 
-   if (ssi->byte_pos >= ssi->next_period_byte) {
+   if (byte_pos >= ssi->next_period_byte) {
struct snd_pcm_runtime *runtime = rsnd_io_to_runtime(io);
 
ssi->period_pos++;
ssi->next_period_byte += ssi->byte_per_period;
 
if (ssi->period_pos >= runtime->periods) {
-   ssi->byte_pos = 0;
+   byte_pos = 0;
ssi->period_pos = 0;
ssi->next_period_byte = ssi->byte_per_period;
}
 
-   return true;
+   ret = true;
}
 
-   return false;
+   WRITE_ONCE(ssi->byte_pos, byte_pos);
+
+   return ret;
 }
 
 /*
@@ -838,7 +842,7 @@ static int rsnd_ssi_pointer(struct rsnd_mod *mod,
struct rsnd_ssi *ssi = rsnd_mod_to_ssi(mod);
struct snd_pcm_runtime *runtime = rsnd_io_to_runtime(io);
 
-   *pointer = bytes_to_frames(runtime, ssi->byte_pos);
+   *pointer = bytes_to_frames(runtime, READ_ONCE(ssi->byte_pos));
 
return 0;
 }
-- 
1.7.9.5

[PATCH v1 0/2] fix race condition in rsnd_ssi_pointer_update

[jiada_wang]

From: Jiada Wang 

This patch set aims to fix the race condition in rsnd_ssi_pointer_update,
between set of byte_pos and wrap it around when new buffer starts.
 
Jiada Wang (2):
  ASoC: rsnd: ssi: fix race condition in rsnd_ssi_pointer_update
  ASoC: rsnd: ssi: remove unnesessary period_pos

 sound/soc/sh/rcar/ssi.c |   25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

-- 
1.7.9.5

[PATCH v2 2/2] ASoC: rsnd: ssi: remove unnesessary period_pos

[jiada_wang]

From: Jiada Wang 

period_pos can always be calculated by byte_pos and
byte_per_period, there is no reason to maintain this
variable in rsnd_dai_stream.
Further more, if the passed 'byte' amount to
rsnd_ssi_pointer_update() is more than byte_per_period.
the calculation of next_period_byte isn't correct.

This patch removes period_pos from rsnd_ssi and calculates
next_period_byte with consideration of actual byte_pos value.

Signed-off-by: Jiada Wang 
---
 sound/soc/sh/rcar/ssi.c |9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/sound/soc/sh/rcar/ssi.c b/sound/soc/sh/rcar/ssi.c
index cbf3bf3..f212024 100644
--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -80,7 +80,6 @@ struct rsnd_ssi {
unsigned int usrcnt;
 
int byte_pos;
-   int period_pos;
int byte_per_period;
int next_period_byte;
 };
@@ -421,7 +420,6 @@ static void rsnd_ssi_pointer_init(struct rsnd_mod *mod,
struct snd_pcm_runtime *runtime = rsnd_io_to_runtime(io);
 
ssi->byte_pos   = 0;
-   ssi->period_pos = 0;
ssi->byte_per_period= runtime->period_size *
  runtime->channels *
  samples_to_bytes(runtime, 1);
@@ -453,13 +451,12 @@ static bool rsnd_ssi_pointer_update(struct rsnd_mod *mod,
 
if (byte_pos >= ssi->next_period_byte) {
struct snd_pcm_runtime *runtime = rsnd_io_to_runtime(io);
+   int period_pos = byte_pos / ssi->byte_per_period;
 
-   ssi->period_pos++;
-   ssi->next_period_byte += ssi->byte_per_period;
+   ssi->next_period_byte = (period_pos + 1) * ssi->byte_per_period;
 
-   if (ssi->period_pos >= runtime->periods) {
+   if (period_pos >= runtime->periods) {
byte_pos = 0;
-   ssi->period_pos = 0;
ssi->next_period_byte = ssi->byte_per_period;
}
 
-- 
1.7.9.5

Re: [PATCH] Scheduler: Removed first parameter from prepare_lock_switch

[Peter Zijlstra]

On Wed, Dec 06, 2017 at 09:50:19PM -0200, Rodrigo Siqueira wrote:
> > Yes, this is correct. However it had me looking at that code and pretty
> > much everything else is completely wrong :-)
> > 
> > That is, its functionally correct (probably), but the function name is
> > not descriptive of what the function does and the comment is just plain
> > wrong.
> > 
> > Also, since both functions are only used in core.c we should probably
> > move them there.
> 
> I'm not sure I understood it completely. What do you mean for wrong? Will 
> CONFIG_SMP a meaningless check here?

So the actual effective code is ok; including the #ifdef for SMP. But
the comment is complete nonsense.

Look at the comments:

 - in finish_lock_switch() doing smp_store_release()
 - before try_to_wake_up() describing migration/blocking
 - in try_to_wake_up() doing smp_cond_load_acquire().

To get a feeling for what on_cpu actually does; it doesn't have anything
much to do with SMP rebalancing code from interrupt contexts (although
that too still cares through can_migrate_task() <- task_running()).

> How about moving 'prepare_lock_switch' code from sched.h to 
> prepare_task_switch
> in core.c?

With a rename; yes. Maybe something like 'acquire_task()' would do.

Then split the smp_store_release() out from finish_lock_switch() and
call it release_task(), and place is near the new acquire_task()
function -- don't forget to update all comments referring to
finish_lock_switch().

This then leaves the actual rq->lock fiddling in finish_lock_switch();
and that whole function too can be moved to core.c, somewhere near
finish_task_switch() I think.