Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

[Mike Rapoport]

On Mon, May 22, 2017 at 05:52:47PM +0200, Vlastimil Babka wrote:
> On 05/22/2017 04:29 PM, Mike Rapoport wrote:
> > On Mon, May 22, 2017 at 03:55:48PM +0200, Michal Hocko wrote:
> >> On Mon 22-05-17 16:36:00, Mike Rapoport wrote:
> >>> On Mon, May 22, 2017 at 02:42:43PM +0300, Kirill A. Shutemov wrote:
>  On Mon, May 22, 2017 at 09:12:42AM +0300, Mike Rapoport wrote:
> > Currently applications can explicitly enable or disable THP for a memory
> > region using MADV_HUGEPAGE or MADV_NOHUGEPAGE. However, once either of
> > these advises is used, the region will always have
> > VM_HUGEPAGE/VM_NOHUGEPAGE flag set in vma->vm_flags.
> > The MADV_CLR_HUGEPAGE resets both these flags and allows managing THP in
> > the region according to system-wide settings.
> 
>  Seems reasonable. But could you describe an use-case when it's useful in
>  real world.
> >>>
> >>> My use-case was combination of pre- and post-copy migration of containers
> >>> with CRIU.
> >>> In this case we populate a part of a memory region with data that was 
> >>> saved
> >>> during the pre-copy stage. Afterwards, the region is registered with
> >>> userfaultfd and we expect to get page faults for the parts of the region
> >>> that were not yet populated. However, khugepaged collapses the pages and
> >>> the page faults we would expect do not occur.
> >>
> >> I am not sure I undestand the problem. Do I get it right that the
> >> khugepaged will effectivelly corrupt the memory by collapsing a range
> >> which is not yet fully populated? If yes shouldn't that be fixed in
> >> khugepaged rather than adding yet another madvise command? Also how do
> >> you prevent on races? (say you VM_NOHUGEPAGE, khugepaged would be in the
> >> middle of the operation and sees a collapsable vma and you get the same
> >> result)
> > 
> > Probably I didn't explained it too well.
> > 
> > The range is intentionally not populated. When we combine pre- and
> > post-copy for process migration, we create memory pre-dump without stopping
> > the process, then we freeze the process without dumping the pages it has
> > dirtied between pre-dump and freeze, and then, during restore, we populate
> > the dirtied pages using userfaultfd.
> > 
> > When CRIU restores a process in such scenario, it does something like:
> > 
> > * mmap() memory region
> > * fill in the pages that were collected during the pre-dump
> > * do some other stuff
> > * register memory region with userfaultfd
> > * populate the missing memory on demand
> > 
> > khugepaged collapses the pages in the partially populated regions before we
> > have a chance to register these regions with userfaultfd, which would
> > prevent the collapse.
> > 
> > We could have used MADV_NOHUGEPAGE right after the mmap() call, and then
> > there would be no race because there would be nothing for khugepaged to
> > collapse at that point. But the problem is that we have no way to reset
> > *HUGEPAGE flags after the memory restore is complete.
> 
> Hmm, I wouldn't be that sure if this is indeed race-free. Check that
> this scenario is indeed impossible?
> 
> - you do the mmap
> - khugepaged will choose the process' mm to scan
> - khugepaged will get to the vma in question, it doesn't have
> MADV_NOHUGEPAGE yet
> - you set MADV_NOHUGEPAGE on the vma
> - you start populating the vma
> - khugepaged sees the vma is non-empty, collapses
> 
> unless I'm wrong, the racers will have mmap_sem for reading only when
> setting/checking the MADV_NOHUGEPAGE? Might be actually considered a bug.

madvise(MADV_*HUGEPAGE) takes mmap_sem for writing, so it is safe.
 
> However, can't you use prctl(PR_SET_THP_DISABLE) instead? "If arg2 has a
> nonzero value, the flag is set, otherwise it is cleared." says the
> manpage. Do it before the mmap and you avoid the race as well?

I've missed that one, thanks Vlastimil!

[PATCH] scsi: hisi_sas: add null check before indirect pointer dereference

[Gustavo A. R. Silva]

Add null check before indirectly dereferencing pointer task->lldd_task
in statement u32 tag = slot->idx;

Addresses-Coverity-ID: 1373843
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/scsi/hisi_sas/hisi_sas_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c 
b/drivers/scsi/hisi_sas/hisi_sas_main.c
index d622db5..f720d3c 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_main.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
@@ -963,7 +963,7 @@ static int hisi_sas_abort_task(struct sas_task *task)
 HISI_SAS_INT_ABT_DEV, 0);
rc = hisi_sas_softreset_ata_disk(device);
}
-   } else if (task->task_proto & SAS_PROTOCOL_SMP) {
+   } else if (task->lldd_task && task->task_proto & SAS_PROTOCOL_SMP) {
/* SMP */
struct hisi_sas_slot *slot = task->lldd_task;
u32 tag = slot->idx;
-- 
2.5.0

Re: Hang/soft lockup in d_invalidate with simultaneous calls

[Khazhismel Kumykov]

On Wed, May 17, 2017 at 2:58 PM Khazhismel Kumykov  wrote:
>
> On Mon, May 15, 2017 at 5:05 PM, Khazhismel Kumykov  wrote:
> > Hi,
> >
> > I'm seeing behavior in d_invalidate, if multiple threads call d_invalidate 
> > on
> > the same tree at the same, behavior time blows up and all the calls hang 
> > with
> > large enough trees/enough simultaneous callers. (e.g. a directory w/ 100k
> > entries in d_subdir, and 5 or so threads calling d_invalidate was able to 
> > hang
> > my test VMs)
> >
> > This seems to be due to thrashing on the dentry locks in multiple threads
> > tightly looping calling d_walk waiting for a shrink_dentry_list call (also
> > thrashing the locks) to complete. (d_invalidate loops calling d_walk so 
> > long as
> > any dentry in the tree is in a dcache shrink list).
> >
> > There was a similar report recently "soft lockup in d_invalidate()" that
> > proposed in the d_invalidate d_walk to ignore dentries marked as in a shrink
> > list already, which does prevent this hang/lockup in this case as well, 
> > although
> > I'm not sure it doesn't violate the contract for d_invalidate. (Although the
> > entries in a shrink list should be dropped eventually, not necessarily by 
> > the
> > time d_invalidate returns).
> >
> > If someone more familiar with the dcache could provide input I would 
> > appreciate.
> >
> > A reliable repro on mainline is:
> >  - create a mountpoint with DCACHE_OP_REVALIDATE, e.g. fuse passthrough
> >  - create a directory and populate with ~100k files with content to
> > populate dcache
> >  - create some background processes opening/reading files in this folder (5
> >   while true; cat $file was enough to get an indefinite hang for me)
> >  - cause the directory to need to be invalidated (e.g., make_bad_inode on 
> > the
> > directory)
> >
> > This results in the background processes all entering d_invalidate and 
> > hanging,
> > while with just one process in d_invalidate (e.g., stat'ing a file in the 
> > dir)
> > things go pretty quickly as expected.
> >
> >
> > (The proposed patch from other thread)
> >
> > diff --git a/fs/dcache.c b/fs/dcache.c
> > index 7b8feb6..3a3b0f37 100644
> > --- a/fs/dcache.c
> > +++ b/fs/dcache.c
> > @@ -1364,7 +1364,7 @@ static enum d_walk_ret select_collect(void *_data,
> > struct dentry *dentry)
> >  goto out;
> >
> >  if (dentry->d_flags & DCACHE_SHRINK_LIST) {
> > -   data->found++;
> > +   goto out;
> >  } else {
> >  if (dentry->d_flags & DCACHE_LRU_LIST)
> >  d_lru_del(dentry);
> >
> >
> > khazhy
>
> Would this change actually violate any guarantees? select_collect
> looks like it used to ignore unused dentries that were part of a
> shrink list before fe91522a7ba82ca1a51b07e19954b3825e4aaa22 (found
> would not be incremented). Once the dentry is on a shrink list would
> it be unreachable anyways, so returning from d_invalidate before all
> the shrink lists finish processing would be ok?
>
> khazhy

Pinging in case this got missed, would appreciate thoughts from someone more
familiar with the dcache.

My previous email wasn't completely correct, while before fe91522a7ba8
("don't remove from shrink list in select_collect()") d_invalidate
would not busy
wait for other workers calling shrink_list to compete, it would return -EBUSY,
rather than success, so a change to return success without waiting would not
be equivalent behavior before. Currently, we will loop calling d_walk repeatedly
causing the extreme slowdown observed.

I still want to understand better, in d_invalidate if we can return
without pruning
in-use dentries safely, would returning before unused dentries are
pruned, so long
as we know they will be pruned by another task (are on a shrink list),
be safe as well?
If not, would it make more sense to have have a mutual exclusion on calling
d_invalidate on the same dentries simultaneously?

khazhy

Re: dmaengine: dw-dmac: Custom cyclic API (Why?)

[Andy Shevchenko]

On Tue, 2017-04-04 at 17:43 +0100, Jose Abreu wrote:
> 
> On 04-04-2017 17:23, Andy Shevchenko wrote:
> > On Mon, 2017-01-02 at 13:56 +, Jose Abreu wrote:
> > > On 02-01-2017 11:30, Andy Shevchenko wrote:
> > > > On Mon, 2017-01-02 at 15:48 +0530, Vinod Koul wrote:
> > > > > On Mon, Jan 02, 2017 at 10:38:00AM +0200, Andy Shevchenko
> > > > > wrote:
> > > > > > On Fri, 2016-12-30 at 12:05 +, Jose Abreu wrote:
> > > > Actually we have AVR32 connected to our lab. So, I can test it
> > > > there,
> > > > but I rather need a patch to use some dummy stub instead of
> > > > codec
> > > > (it
> > > > has no codec connected).
> > > > 
> > > 
> > > Thank you all for the info. I don't have the HW ready to test yet
> > > (I was collecting some info first), but when I do I can test on
> > > my side using Designware I2S and ALSA SoC DMA engine.
> > 
> > Just TWIMC, AVR32 is going to be removed from kernel.
> > It means in particularly I will follow up and remove related bits in
> > dw_dmac driver, including custom cyclic API.
> > 
> 
> Thanks for sharing this! Unfortunately the plans to include a DMA
> for I2S audio were postponed so I never got to the point of
> implementing/testing it. As I don't see any plans in using this
> cyclic DMA for now I guess if I need to use it I will implement
> it again using the standard cyclic DMA engine API.

Just heads up TWIMC the custom API has been removed.

-- 
Andy Shevchenko 
Intel Finland Oy

Re: checkpatch.pl false positive

[Joe Perches]

On Fri, 2017-05-19 at 09:57 +, Antonio Niño Díaz wrote:
> Hello,

Hi.

> I think I've hit a corner case in checkpatch.pl. It is easy to reproduce, 
> just create a patch with a new line such as:
> 
> #define MY_HEADER 

[ checkpatch outputs ]

> config.h:9: ERROR: spaces required around that '<' (ctx:WxV)
> +#define MY_HEADER  ^
> config.h:9: ERROR: spaces required around that '>' (ctx:VxE)
> +#define MY_HEADER 

Yeah, checkpatch doesn't know about the #define before the other
things
it tests.

> Will you add this as an exception, or it is not an issue for
> you as the Linux kernel doesn't really use this weird system?

Probably not as it's not a kernel usage and
I can't think of a decent way to avoid it.

maybe some substitution like

$rawline =~ s/^(\s*#\s*define\s+\w+\s+)<([^>]+>)/\1"\2"/

could help, but it's pretty obscure and probably not
used in many other projects.

Maybe you could add and keep it local to your use.

Re: [RFC][PATCH] time: Add warning about imminent deprecation of CONFIG_GENERIC_TIME_VSYSCALL_OLD

[John Stultz]

On Sun, May 21, 2017 at 5:58 PM, Michael Ellerman  wrote:
> John Stultz  writes:
>
>> CONFIG_GENERIC_TIME_VSYSCALL_OLD was introduced five years ago
>> to allow a transition from the old vsyscall implementations to
>> the new method (which simplified internal accounting and made
>> timekeeping more precise).
>
> I'm sure it's completely obvious to everyone except me what needs to be
> done, but can you spell it out for me? Keeping in mind that I don't know
> anything about the time keeping code.

No. Apologies, I probably should have included something like this.

Basically long ago, timekeeping was handled (roughly) like:

clock_gettime():
now = tk->clock->read()
offset_ns = ((now - tk->cycle_last) * tk->clock->mult) >> tk->clock->shift;
return timespec_add_ns(tk->xtime, offset_ns);

But since for error handling use sub-ns precision, combined with that
for update performance, we accumulate in fixed intervals, there are
situations where in the update, we could accumulate half of a
nanosecond into the base tk->xtime value and leaving half of a
nanosecond in the offset.   This caused the split nanosecond to be
truncated out by the math, causing 1ns discontinuities.

So to address this, we came up with sort of a hack, which when we
accumulate rounds up that partial nanosecond, and adds the amount we
rounded up to the error (which will cause the freq correction code to
slow the clock down slightly). This is the code that is now done in
the old_vsyscall_fixup() logic.

Unfortunately this fix (which generates up to a nanosecond of error
per tick) then made the freq correction code do more work and made it
more difficult to have a stable clock.

So we went for a more proper fix, which was to properly handle the
sub-nanosecond portion of the timekeeping throughout the logic, doing
the truncation last.

clock_gettime():
now = tk->clock->read()
ret.tv_sec = tk->xtime_sec;
offset_sns = (now - tk->cycle_last) * tk->clock->mult;
ret.tv_nsec = (offset_sns + tk->tkr_mono.xtime_nsec) >> tk->clock->shift;
return ret;

So in the above, we now use the tk->tkr_mono.xtime_nsec (which despite
its unfortunate name, stores the accumulated shifted nanoseconds), and
add it to the (current_cycle_delta * clock->mult), then we do the
shift last to preserve as much precision as we can.

Unfortunately we need all the reader code to do the same, which wasn't
easy to transition in some cases. So we provided the
CONFIG_GENERIC_TIME_VSYSCALL_OLD option to preserve the old round-up
behavior while arch maintainers could make the transition.


>> However, PPC and IA64 have yet to make the transition, despite
>> in some cases me sending test patches to try to help it along.
>>
>> http://patches.linaro.org/patch/30501/
>> http://patches.linaro.org/patch/35412/
>
> I've never seen a PPC patch, did you send one?

Yea. The PPC patch I never felt comfortable enough with to send.


>> If its helpful, my last pass at the patches can be found here:
>> https://git.linaro.org/people/john.stultz/linux.git dev/oldvsyscall-cleanup
>
> Looks like it's just a draft for PPC. Do you think that should work and
> it just needs testing? The comment about the vdso being "slightly
> behind" is a little concerning.

So, long ago I talked w/ Paul Mackerras about the ppc vdso code, as
ppc has some other legacy "userspace time" code that has to be
maintained as well (I believe there's not code page, just data page
that userspace pulls directly from). So for that case, we have the
problem where we can't do this sub-ns accounting, so the hack there is
rather then rounding-up and adding to ntp_error in the accumulation
code (which then causes the mult to slow), we're basically doing it
in the reader, slowing down mult by one. This will cause userspace
time to have "steps" where after an accumulation time jumps forward a
bit, but avoids the possibility of a discontinuity where time jumps
backwards.

But again, I don't want to pretend I'm not an expert on the ppc side.
This draft patch doesn't even touch the __kernel_clock_gettime()
implementations, and was trying to preserve the existing ppc logic
while transitioning the core code. Its likely that a better fix should
be done deeper in the ppc side (likely splitting the legacy userspace
data formats out so any hacks only apply to them).

thanks
-john

[PATCH] gpu: drm: nouveau: add null check before pointer dereference

[Gustavo A. R. Silva]

Add null check before dereferencing pointer asyc

Addresses-Coverity-ID: 1397932
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/drm/nouveau/nv50_display.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
b/drivers/gpu/drm/nouveau/nv50_display.c
index a766324..052a60a 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -2107,7 +2107,8 @@ nv50_head_atomic_check(struct drm_crtc *crtc, struct 
drm_crtc_state *state)
asyc->set.dither = true;
}
} else {
-   asyc->set.mask = ~0;
+   if (asyc)
+   asyc->set.mask = ~0;
asyh->set.mask = ~0;
}
 
-- 
2.5.0

Re: [RFC][PATCH 0/9] Make containers kernel objects

[James Bottomley]

On Mon, 2017-05-22 at 14:34 -0400, Jeff Layton wrote:
> On Mon, 2017-05-22 at 09:53 -0700, James Bottomley wrote:
> > [Added missing cc to containers list]
> > On Mon, 2017-05-22 at 17:22 +0100, David Howells wrote:
> > > Here are a set of patches to define a container object for the 
> > > kernel and to provide some methods to create and manipulate them.
> > > 
> > > The reason I think this is necessary is that the kernel has no 
> > > idea how to direct upcalls to what userspace considers to be a
> > > container - current Linux practice appears to make a "container" 
> > > just an arbitrarily chosen junction of namespaces, control groups 
> > > and files, which may be changed individually within the
> > > "container".
> > 
> > This sounds like a step in the wrong direction: the strength of the
> > current container interfaces in Linux is that people who set up
> > containers don't have to agree what they look like.  So I can set 
> > up a user namespace without a mount namespace or an architecture
> > emulation container with only a mount namespace.
> > 
> 
> Does this really mandate what they look like though? AFAICT, you can
> still spawn disconnected namespaces to your heart's content. What 
> this does is provide a container for several different namespaces so 
> that the kernel can actually be aware of the association between 
> them.

Yes, because it imposes a view of what is in a container.  As the
several replies have pointed out (and indeed as I pointed out below for
kubernetes), this isn't something the orchestration systems would find
usable.

>  The way you populate the different namespaces looks to be pretty
> flexible.

OK, but look at it another way: If we provides a container API no
actual consumer of container technologies wants to use just because we
think it makes certain tasks easy, is it really a good API?

Containers are multi-layered and complex.  If you're not ready for this
as a user, then you should use an orchestration system that prevents
you from screwing up.

> > But ignoring my fun foibles with containers and to give a concrete
> > example in terms of a popular orchestration system: in kubernetes,
> > where certain namespaces are shared across pods, do you imagine the
> > kernel's view of the "container" to be the pod or what kubernetes
> > thinks of as the container?  This is important, because half the
> > examples you give below are network related and usually pods share 
> > a network namespace.
> > 
> > > The kernel upcall mechanism then needs to decide which set of 
> > > namespaces, etc., it must exec the appropriate upcall program. 
> > >  Examples of this include:
> > > 
> > >  (1) The DNS resolver.  The DNS cache in the kernel should 
> > > probably be per-network namespace, but in userspace the program, 
> > > its libraries and its config data are associated with a mount 
> > > tree and a user namespace and it gets run in a particular pid
> > > namespace.
> > 
> > All persistent (written to fs data) has to be mount ns associated;
> > there are no ifs, ands and buts to that.  I agree this implies that 
> > if you want to run a separate network namespace, you either take 
> > DNS from the parent (a lot of containers do) or you set up a daemon 
> > to run within the mount namespace.  I agree the latter is a 
> > slightly fiddly operation you have to get right, but that's why we 
> > have orchestration systems.
> > 
> > What is it we could do with the above that we cannot do today?
> > 
> 
> Spawn a task directly from the kernel, already set up in the correct
> namespaces, a'la call_usermodehelper. So far there is no way to do
> that,

Today the usermode helper has to be namespace aware.  We spawn it into
the root namespace and it jumps into the correct namespace/cgroup
combination and re-executes itself or simply performs the requisite
task on behalf of the container.  Is this simple, no; does it work,
yes, provided the host OS is aware of what the container orchestration
system wants it to do.

> and it is something we'd very much desire. Ian Kent has made several
> passes at it recently.

Well, every time we try to remove some of the complexity from
userspace, we end up wrapping around the axle of what exactly we're
trying to achieve, yes.

> > >  (2) NFS ID mapper.  The NFS ID mapping cache should also 
> > > probably be per-network namespace.
> > 
> > I think this is a view but not the only one:  Right at the moment, 
> > NFS ID mapping is used as the one of the ways we can get the user
> > namespace ID mapping writes to file problems fixed ... that makes 
> > it a property of the mount namespace for a lot of containers. 
> >  There are many other instances where they do exactly as you say, 
> > but what I'm saying is that we don't want to lose the flexibility
> > we currently have.
> > 
> > >  (3) nfsdcltrack.  A way for NFSD to access stable storage for 
> > > tracking of persistent state.  Again, network-namespace 
> > > dependent, but also perhaps 

Re: [PATCH net-next 08/20] net: dsa: change scope of ageing time setter

[Florian Fainelli]

On 05/19/2017 02:00 PM, Vivien Didelot wrote:
> Change the scope of the switchdev bridge ageing time attribute setter
> from the DSA slave device to the generic DSA port, so that the future
> port-wide API can also be used for other port types, such as CPU and DSA
> links.
> 
> Also ds->ports is now a contiguous array of dsa_port structures, thus
> their addresses cannot be NULL. Remove the useless check in
> dsa_fastest_ageing_time.

And you are also passing just the ageing time value, and not longer the
full attribute, which is a nice simplification.

> 
> Signed-off-by: Vivien Didelot 

Reviewed-by: Florian Fainelli 
-- 
Florian

Re: [PATCH 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter

[Stephane Eranian]

On Mon, May 22, 2017 at 12:23 PM, Peter Zijlstra  wrote:
> On Mon, May 22, 2017 at 04:55:47PM +, Liang, Kan wrote:
>>
>>
>> > On Fri, May 19, 2017 at 10:06:21AM -0700, kan.li...@intel.com wrote:
>> > > diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index
>> > > 580b60f..e8b2326 100644
>> > > --- a/arch/x86/events/core.c
>> > > +++ b/arch/x86/events/core.c
>> > > @@ -101,6 +101,10 @@ u64 x86_perf_event_update(struct perf_event
>> > *event)
>> > >   delta = (new_raw_count << shift) - (prev_raw_count << shift);
>> > >   delta >>= shift;
>> > >
>> > > + /* Correct the count number if applying ref_cycles replacement */
>> > > + if (!is_sampling_event(event) &&
>> > > + (hwc->flags & PERF_X86_EVENT_REF_CYCLES_REP))
>> > > + delta *= x86_pmu.ref_cycles_factor;
>> >
>> > That condition seems wrong, why only correct for !sampling events?
>> >
>>
>> For sampling, it's either fixed freq mode or fixed period mode.
>>  - In the fixed freq mode, we should do nothing, because the adaptive
>>frequency algorithm will handle it.
>>  - In the fixed period mode, we have already adjusted the period in
>> ref_cycles_rep().
>> Therefore, we should only handle !sampling events here.
>
> How so? For sampling events the actual event count should also be
> accurate.

Yes, it must be. Because you can reconstruct the total number of
occurrences of the event by adding
all the periods recorded in each sample. So the period in each sample
must reflect user event and not
kernel event.

Re: [PATCH 23/29] vfio-mediated-device.txt: standardize document format

[Kirti Wankhede]

On 5/19/2017 6:56 AM, Mauro Carvalho Chehab wrote:
> Each text file under Documentation follows a different
> format. Some doesn't even have titles!
> 
> In this specific document, the title, copyright and authorship
> are added as if it were a C file!
> 
> Change its representation to follow the adopted standard,
> using ReST markups for it to be parseable by Sphinx:
> - convert document preambule to the proper format;
> - mark literal blocks;
> - adjust identation;
> - use numbered lists for references.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Looks good to me.

Reviewed by: Kirti Wankhede 

Thanks,
Kirti

> ---
>  Documentation/vfio-mediated-device.txt | 252 
> +
>  1 file changed, 130 insertions(+), 122 deletions(-)
> 
> diff --git a/Documentation/vfio-mediated-device.txt 
> b/Documentation/vfio-mediated-device.txt
> index e5e57b40f8af..1b3950346532 100644
> --- a/Documentation/vfio-mediated-device.txt
> +++ b/Documentation/vfio-mediated-device.txt
> @@ -1,14 +1,17 @@
> -/*
> - * VFIO Mediated devices
> - *
> - * Copyright (c) 2016, NVIDIA CORPORATION. All rights reserved.
> - * Author: Neo Jia 
> - * Kirti Wankhede 
> - *
> - * 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:: 
> +
> +=
> +VFIO Mediated devices
> +=
> +
> +:Copyright: |copy| 2016, NVIDIA CORPORATION. All rights reserved.
> +:Author: Neo Jia 
> +:Author: Kirti Wankhede 
> +
> +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.
> +
>  
>  Virtual Function I/O (VFIO) Mediated devices[1]
>  ===
> @@ -42,7 +45,7 @@ removes it from a VFIO group.
>  
>  The following high-level block diagram shows the main components and 
> interfaces
>  in the VFIO mediated driver framework. The diagram shows NVIDIA, Intel, and 
> IBM
> -devices as examples, as these devices are the first devices to use this 
> module.
> +devices as examples, as these devices are the first devices to use this 
> module::
>  
>   +---+
>   |   |
> @@ -91,7 +94,7 @@ Registration Interface for a Mediated Bus Driver
>  
>  
>  The registration interface for a mediated bus driver provides the following
> -structure to represent a mediated device's driver:
> +structure to represent a mediated device's driver::
>  
>   /*
>* struct mdev_driver [2] - Mediated device's driver
> @@ -110,14 +113,14 @@ structure to represent a mediated device's driver:
>  A mediated bus driver for mdev should use this structure in the function 
> calls
>  to register and unregister itself with the core driver:
>  
> -* Register:
> +* Register::
>  
> -  extern int  mdev_register_driver(struct mdev_driver *drv,
> +extern int  mdev_register_driver(struct mdev_driver *drv,
>  struct module *owner);
>  
> -* Unregister:
> +* Unregister::
>  
> -  extern void mdev_unregister_driver(struct mdev_driver *drv);
> +extern void mdev_unregister_driver(struct mdev_driver *drv);
>  
>  The mediated bus driver is responsible for adding mediated devices to the 
> VFIO
>  group when devices are bound to the driver and removing mediated devices from
> @@ -152,15 +155,15 @@ The callbacks in the mdev_parent_ops structure are as 
> follows:
>  * mmap: mmap emulation callback
>  
>  A driver should use the mdev_parent_ops structure in the function call to
> -register itself with the mdev core driver:
> +register itself with the mdev core driver::
>  
> -extern int  mdev_register_device(struct device *dev,
> - const struct mdev_parent_ops *ops);
> + extern int  mdev_register_device(struct device *dev,
> +  const struct mdev_parent_ops *ops);
>  
>  However, the mdev_parent_ops structure is not required in the function call
> -that a driver should use to unregister itself with the mdev core driver:
> +that a driver should use to unregister itself with the mdev core driver::
>  
> -extern void mdev_unregister_device(struct device *dev);
> + extern void mdev_unregister_device(struct device *dev);
>  
>  
>  Mediated Device Management Interface Through sysfs
> @@ -183,30 +186,32 @@ with the mdev core driver.
>  Directories and files under the sysfs for Each Physical Device
>  --
>  
> -|- [parent physical device]
> -|--- Vendor-specific-attributes [optional]
> -|--- [mdev_supported_types]
> -| |--- []
> -| |  

Re: [PATCH net-next 18/20] net: dsa: add FDB notifier

[Florian Fainelli]

On 05/19/2017 02:00 PM, Vivien Didelot wrote:
> Add two new DSA_NOTIFIER_FDB_ADD and DSA_NOTIFIER_FDB_DEL events to
> notify not only a single switch, but all switches of a the fabric when
> an FDB entry is added or removed.
> 
> For the moment, keep the current behavior and ignore other switches.
> 
> Signed-off-by: Vivien Didelot 

Reviewed-by: Florian Fainelli 
-- 
Florian

Re: [PATCH 2/5] sctp: Delete an error message for a failed memory allocation in sctp_init()

[SF Markus Elfring]

>> +++ b/net/sctp/protocol.c
>> @@ -1447,5 +1447,4 @@ static __init int sctp_init(void)
>>  if (!sctp_ep_hashtable) {
>> -pr_err("Failed endpoint_hash alloc\n");
> 
> Okay but then why not also delete the one a few lines below this one:
> if (!sctp_port_hashtable) {
> pr_err("Failed bind hash alloc\n");
> status = -ENOMEM;
> goto err_bhash_alloc;
> }
> Seems the same pattern to me.
> 
>>  status = -ENOMEM;
>>  goto err_ehash_alloc;
>>  }

How do you think about to remove the other error message in another
update step if a consensus would be achieved in such a direction
for this software module?

Regards,
Markus

Re: [kernel-hardening] [PATCH 1/1] Sealable memory support

[Igor Stoppa]

On 20/05/17 11:51, Greg KH wrote:
> On Fri, May 19, 2017 at 01:38:11PM +0300, Igor Stoppa wrote:
>> Dynamically allocated variables can be made read only,

[...]

> This is really nice, do you have a follow-on patch showing how any of
> the kernel can be changed to use this new subsystem?

Yes, actually I started from the need of turning into R/O some data
structures in both LSM Hooks and SE Linux.

> Without that, it
> might be hard to get this approved (we don't like adding new apis
> without users.)

Yes, I just wanted to give an early preview of the current
implementation, since it is significantly different from what I
initially proposed. So I was looking for early feedback.

Right now, I'm fixing it up and adding some more structured debugging.

Then I'll re-submit it together with the LSM Hooks example.

---
thanks, igor

Re: [PATCH 2/5] sctp: Delete an error message for a failed memory allocation in sctp_init()

[Marcelo Ricardo Leitner]

On Mon, May 22, 2017 at 09:46:21PM +0200, SF Markus Elfring wrote:
> >> +++ b/net/sctp/protocol.c
> >> @@ -1447,5 +1447,4 @@ static __init int sctp_init(void)
> >>if (!sctp_ep_hashtable) {
> >> -  pr_err("Failed endpoint_hash alloc\n");
> > 
> > Okay but then why not also delete the one a few lines below this one:
> > if (!sctp_port_hashtable) {
> > pr_err("Failed bind hash alloc\n");
> > status = -ENOMEM;
> > goto err_bhash_alloc;
> > }
> > Seems the same pattern to me.
> > 
> >>status = -ENOMEM;
> >>goto err_ehash_alloc;
> >>}
> 
> How do you think about to remove the other error message in another
> update step if a consensus would be achieved in such a direction
> for this software module?

Fine by me.

Regards,
  Marcelo

Re: [PATCH v2 1/2] mfd: intel_quark_i2c_gpio: Use dmi_system_id table for retrieving frequency

[Jan Kiszka]

On 2017-05-22 19:26, Andy Shevchenko wrote:
> On Mon, May 22, 2017 at 8:25 PM, Jan Kiszka  wrote:
>> On 2017-05-22 19:20, Andy Shevchenko wrote:
>>> On Mon, May 22, 2017 at 8:18 PM, Jan Kiszka  wrote:
 On 2017-05-22 19:12, Andy Shevchenko wrote:
> On Mon, May 22, 2017 at 1:53 PM, Jan Kiszka  
> wrote:
>> Avoids reimplementation of DMI matching in intel_quark_i2c_setup.
>
> What's wrong with current approach? I suppose this will make sense
> when we will have an issue / impediment. Right now it looks like
> over-engineering.
>
> (Yes, I know what I said to you about this earlier, OTOH see above)
>

 It allows matching on additional DMI tags without additional code -
 patch 2 depends on it.
>>>
>>> And since there is no difference to the frequency the name is enough.
>>> So, I wouldn't go with this series as is. See above.
>>
>> Nope: Just like for the stmmac, we need to include the asset tags to
>> avoid matching variations of the devices which may carry the same board
>> name. While I will try to avoid that this happens, we are better safe
>> than sorry here.
> 
> Do we have an issue right now?
> Yes / No

Andy, we are trying to design a robust upstream driver here, no ad-hoc
BSP that will not survive the hardware anyway.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

[PATCH] mm: kmemleak: Treat vm_struct as alternative reference to vmalloc'ed objects

[Catalin Marinas]

Kmemleak requires that vmalloc'ed objects have a minimum reference count
of 2: one in the corresponding vm_struct object and the other owned by
the vmalloc() caller. There are cases, however, where the original
vmalloc() returned pointer is lost and, instead, a pointer to vm_struct
is stored (see free_thread_stack()). Kmemleak currently reports such
objects as leaks.

This patch adds support for treating any surplus references to an object
as additional references to a specified object. It introduces the
kmemleak_vmalloc() API function which takes a vm_struct pointer and sets
its surplus reference passing to the actual vmalloc() returned pointer.
The __vmalloc_node_range() calling site has been modified accordingly.

An unrelated minor change is included in this patch to change the type
of kmemleak_object.flags to unsigned int (previously unsigned long).

Reported-by: "Luis R. Rodriguez" 
Cc: Michal Hocko 
Cc: Andy Lutomirski 
Signed-off-by: Catalin Marinas 
---

Hi,

As per [1], I added support to use pointers to vm_struct as an
alternative way to avoid false positives when the original vmalloc()
pointer has been lost. This is slightly harder to reason about but it
seems to work for this use-case. I'm not aware of other cases (than
free_thread_stack()) where the original vmalloc() pointer is removed in
favour of a vm_struct one.

An alternative implementation (simpler to understand), if preferred, is
to annotate alloc_thread_stack_node() and free_thread_stack() with
kmemleak_unignore()/kmemleak_ignore() calls and proper comments.

Feedback welcome, I'm fine with either option.

Thanks.

[1] 
http://lkml.kernel.org/r/20170517110922.ga18...@e104818-lin.cambridge.arm.com

 Documentation/dev-tools/kmemleak.rst |   1 +
 include/linux/kmemleak.h |   7 ++
 mm/kmemleak.c| 136 +--
 mm/vmalloc.c |   7 +-
 4 files changed, 122 insertions(+), 29 deletions(-)

diff --git a/Documentation/dev-tools/kmemleak.rst 
b/Documentation/dev-tools/kmemleak.rst
index b2391b829169..cb8862659178 100644
--- a/Documentation/dev-tools/kmemleak.rst
+++ b/Documentation/dev-tools/kmemleak.rst
@@ -150,6 +150,7 @@ See the include/linux/kmemleak.h header for the functions 
prototype.
 - ``kmemleak_init`` - initialize kmemleak
 - ``kmemleak_alloc``- notify of a memory block allocation
 - ``kmemleak_alloc_percpu`` - notify of a percpu memory block allocation
+- ``kmemleak_vmalloc``  - notify of a vmalloc() memory allocation
 - ``kmemleak_free`` - notify of a memory block freeing
 - ``kmemleak_free_part``- notify of a partial memory block freeing
 - ``kmemleak_free_percpu``  - notify of a percpu memory block freeing
diff --git a/include/linux/kmemleak.h b/include/linux/kmemleak.h
index 1c2a32829620..590343f6c1b1 100644
--- a/include/linux/kmemleak.h
+++ b/include/linux/kmemleak.h
@@ -22,6 +22,7 @@
 #define __KMEMLEAK_H
 
 #include 
+#include 
 
 #ifdef CONFIG_DEBUG_KMEMLEAK
 
@@ -30,6 +31,8 @@ extern void kmemleak_alloc(const void *ptr, size_t size, int 
min_count,
   gfp_t gfp) __ref;
 extern void kmemleak_alloc_percpu(const void __percpu *ptr, size_t size,
  gfp_t gfp) __ref;
+extern void kmemleak_vmalloc(const struct vm_struct *area, size_t size,
+gfp_t gfp) __ref;
 extern void kmemleak_free(const void *ptr) __ref;
 extern void kmemleak_free_part(const void *ptr, size_t size) __ref;
 extern void kmemleak_free_percpu(const void __percpu *ptr) __ref;
@@ -81,6 +84,10 @@ static inline void kmemleak_alloc_percpu(const void __percpu 
*ptr, size_t size,
 gfp_t gfp)
 {
 }
+static inline void kmemleak_vmalloc(const struct vm_struct *area, size_t size,
+   gfp_t gfp)
+{
+}
 static inline void kmemleak_free(const void *ptr)
 {
 }
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 20036d4f9f13..11ab654502fd 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -150,7 +150,7 @@ struct kmemleak_scan_area {
  */
 struct kmemleak_object {
spinlock_t lock;
-   unsigned long flags;/* object status flags */
+   unsigned int flags; /* object status flags */
struct list_head object_list;
struct list_head gray_list;
struct rb_node rb_node;
@@ -159,6 +159,8 @@ struct kmemleak_object {
atomic_t use_count;
unsigned long pointer;
size_t size;
+   /* pass surplus references to this pointer */
+   unsigned long excess_ref;
/* minimum number of a pointers found before it is considered leak */
int min_count;
/* the total number of pointers found pointing to this object */
@@ -253,7 +255,8 @@ enum {
KMEMLEAK_NOT_LEAK,
KMEMLEAK_IGNORE,

Re: [PATCH 3/3] regulator: tps65917: Add support for SMPS12

[Lee Jones]

On Fri, 19 May 2017, Keerthy wrote:

> App support for SMPS12 dual phase regulator.
> 
> Signed-off-by: Keerthy 
> ---
>  drivers/regulator/palmas-regulator.c | 18 +++---

>  include/linux/mfd/palmas.h   |  2 ++

Acked-by: Lee Jones 

>  2 files changed, 17 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/regulator/palmas-regulator.c 
> b/drivers/regulator/palmas-regulator.c
> index 31ae5ee..84df468 100644
> --- a/drivers/regulator/palmas-regulator.c
> +++ b/drivers/regulator/palmas-regulator.c
> @@ -264,6 +264,13 @@
>   .sleep_id   = TPS65917_EXTERNAL_REQSTR_ID_SMPS5,
>   },
>   {
> + .name   = "SMPS12",
> + .sname  = "smps1-in",
> + .vsel_addr  = TPS65917_SMPS1_VOLTAGE,
> + .ctrl_addr  = TPS65917_SMPS1_CTRL,
> + .sleep_id   = TPS65917_EXTERNAL_REQSTR_ID_SMPS12,
> + },
> + {
>   .name   = "LDO1",
>   .sname  = "ldo1-in",
>   .vsel_addr  = TPS65917_LDO1_VOLTAGE,
> @@ -367,6 +374,7 @@
>   EXTERNAL_REQUESTOR_TPS65917(SMPS3, 1, 2),
>   EXTERNAL_REQUESTOR_TPS65917(SMPS4, 1, 3),
>   EXTERNAL_REQUESTOR_TPS65917(SMPS5, 1, 4),
> + EXTERNAL_REQUESTOR_TPS65917(SMPS12, 1, 5),
>   EXTERNAL_REQUESTOR_TPS65917(LDO1, 2, 0),
>   EXTERNAL_REQUESTOR_TPS65917(LDO2, 2, 1),
>   EXTERNAL_REQUESTOR_TPS65917(LDO3, 2, 2),
> @@ -1305,7 +1313,8 @@ static int tps65917_smps_registration(struct 
> palmas_pmic *pmic,
>*/
>   desc = >desc[id];
>   desc->n_linear_ranges = 3;
> - if ((id == TPS65917_REG_SMPS2) && pmic->smps12)
> + if ((id == TPS65917_REG_SMPS2 || id == TPS65917_REG_SMPS1) &&
> + pmic->smps12)
>   continue;
>  
>   /* Initialise sleep/init values from platform data */
> @@ -1427,6 +1436,7 @@ static int tps65917_smps_registration(struct 
> palmas_pmic *pmic,
>   { .name = "smps3", },
>   { .name = "smps4", },
>   { .name = "smps5", },
> + { .name = "smps12",},
>   { .name = "ldo1", },
>   { .name = "ldo2", },
>   { .name = "ldo3", },
> @@ -1455,7 +1465,7 @@ static int tps65917_smps_registration(struct 
> palmas_pmic *pmic,
>  
>  static struct palmas_pmic_driver_data tps65917_ddata = {
>   .smps_start = TPS65917_REG_SMPS1,
> - .smps_end = TPS65917_REG_SMPS5,
> + .smps_end = TPS65917_REG_SMPS12,
>   .ldo_begin = TPS65917_REG_LDO1,
>   .ldo_end = TPS65917_REG_LDO5,
>   .max_reg = TPS65917_NUM_REGS,
> @@ -1643,8 +1653,10 @@ static int palmas_regulators_probe(struct 
> platform_device *pdev)
>   if (ret)
>   return ret;
>  
> - if (reg & PALMAS_SMPS_CTRL_SMPS12_SMPS123_EN)
> + if (reg & PALMAS_SMPS_CTRL_SMPS12_SMPS123_EN) {
>   pmic->smps123 = 1;
> + pmic->smps12 = 1;
> + }
>  
>   if (reg & PALMAS_SMPS_CTRL_SMPS45_SMPS457_EN)
>   pmic->smps457 = 1;
> diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
> index 5c9a1d4..6dec438 100644
> --- a/include/linux/mfd/palmas.h
> +++ b/include/linux/mfd/palmas.h
> @@ -250,6 +250,7 @@ enum tps65917_regulators {
>   TPS65917_REG_SMPS3,
>   TPS65917_REG_SMPS4,
>   TPS65917_REG_SMPS5,
> + TPS65917_REG_SMPS12,
>   /* LDO regulators */
>   TPS65917_REG_LDO1,
>   TPS65917_REG_LDO2,
> @@ -317,6 +318,7 @@ enum tps65917_external_requestor_id {
>   TPS65917_EXTERNAL_REQSTR_ID_SMPS3,
>   TPS65917_EXTERNAL_REQSTR_ID_SMPS4,
>   TPS65917_EXTERNAL_REQSTR_ID_SMPS5,
> + TPS65917_EXTERNAL_REQSTR_ID_SMPS12,
>   TPS65917_EXTERNAL_REQSTR_ID_LDO1,
>   TPS65917_EXTERNAL_REQSTR_ID_LDO2,
>   TPS65917_EXTERNAL_REQSTR_ID_LDO3,

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 03/18] dt-bindings: mfd: Add bindings for Cirrus Logic Madera codecs

[Lee Jones]

On Mon, 24 Apr 2017, Richard Fitzgerald wrote:

> Specification of the bindings for the parent MFD driver component
> of the Cirrus Logic Madera codec drivers.
> 
> Signed-off-by: Richard Fitzgerald 
> ---
> Changes since V1:
> - split out from main MFD patch
> - moved interrupt control binding descriptions into here
> - added description of the regulator child nodes
> - fixed the node name of the example
> - removed the MICBIAS from the example, these have been removed from the code
> 
>  Documentation/devicetree/bindings/mfd/madera.txt | 96 
> 
>  1 file changed, 96 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/madera.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/madera.txt 
> b/Documentation/devicetree/bindings/mfd/madera.txt
> new file mode 100644
> index 000..af9b85f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/madera.txt
> @@ -0,0 +1,96 @@
> +Cirrus Logic Madera class audio codecs multi-function device

Nit: Multi-Functional Device

Other than that:

Acked-by: Lee Jones 

> +These devices are audio SoCs with extensive digital capabilities and a range
> +of analogue I/O.
> +
> +See also the child driver bindings in:
> +bindings/gpio/gpio-madera.txt
> +bindings/pinctrl/cirrus,madera-pinctrl.txt
> +bindings/regulator/arizona-regulator.txt
> +bindings/sound/madera.txt
> +
> +Required properties:
> +
> +  - compatible : One of the following chip-specific strings:
> +"cirrus,cs47l35"
> +"cirrus,cs47l85"
> +"cirrus,cs47l90"
> +"cirrus,cs47l91"
> +"cirrus,wm1840"
> +
> +  - reg : I2C slave address when connected using I2C, chip select number when
> +using SPI.
> +
> +  - DCVDD-supply : Power supply for the device as defined in
> +bindings/regulator/regulator.txt
> +Mandatory on CS47L35, CS47L90, CS47L91
> +Optional on CS47L85, WM1840
> +
> +  - AVDD-supply, DBVDD1-supply, DBVDD2-supply, CPVDD1-supply, CPVDD2-supply :
> +Power supplies for the device
> +
> +  - DBVDD3-supply, DBVDD4-supply : Power supplies for the device
> +(CS47L85, CS47L90, CS47L91, WM1840)
> +
> +  - SPKVDDL-supply, SPKVDDR-supply : Power supplies for the device
> +(CS47L85, WM1840)
> +
> +  - SPKVDD-supply : Power supply for the device
> +(CS47L35)
> +
> +  - interrupt-controller : Madera class devices contain interrupt controllers
> +and may provide interrupt services to other devices.
> +
> +  - #interrupt-cells: the number of cells to describe an IRQ, must be 2.
> +The first cell is the IRQ number.
> +The second cell is the flags, encoded as the trigger masks from
> +bindings/interrupt-controller/interrupts.txt
> +
> +  - interrupt-parent : The parent interrupt controller.
> +
> +  - interrupts : The interrupt line the /IRQ signal for the device is
> +connected to.
> +
> +Optional properties:
> +
> +  - MICVDD-supply : Power supply, only need to be specified if
> +powered externally
> +
> +  - reset-gpios : One entry specifying the GPIO controlling /RESET.
> +As defined in bindings/gpio.txt.
> +Although optional, it is strongly recommended to use a hardware reset
> +
> +  - MICBIASx : Initial data for the MICBIAS regulators, as covered in
> +Documentation/devicetree/bindings/regulator/regulator.txt.
> +One for each MICBIAS generator (MICBIAS1, MICBIAS2, ...)
> +(all codecs)
> +
> +One for each output pin (MICBIAS1A, MIBCIAS1B, MICBIAS2A, ...)
> +(all except CS47L85, WM1840)
> +
> +The following following additional property is supported for the 
> generator
> +nodes:
> +  - cirrus,ext-cap : Set to 1 if the MICBIAS has external decoupling
> +capacitors attached.
> +
> +Optional child nodes:
> +micvdd : Node containing initialization data for the micvdd regulator
> +See bindings/regulator/arizona-regulator.txt
> +
> +ldo1 : Node containing initialization data for the LDO1 regulator
> +See bindings/regulator/arizona-regulator.txt
> +(cs47l85, wm1840)
> +
> +Example:
> +
> +cs47l85@0 {
> + compatible = "cirrus,cs47l85";
> + reg = <0>;
> +
> + reset-gpios = < 0>;
> +
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + interrupts = <_irq1>;
> + interrupt-parent = <>;
> +};

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v5 0/3] watchdog: allow setting deadline for opening /dev/watchdogN

[Alan Cox]

On Mon, 22 May 2017 16:06:36 +0200
Rasmus Villemoes  wrote:

> If a watchdog driver tells the framework that the device is running,
> the framework takes care of feeding the watchdog until userspace opens
> the device. If the userspace application which is supposed to do that
> never comes up properly, the watchdog is fed indefinitely by the
> kernel. This can be especially problematic for embedded devices.
> 
> These patches allow one to set a maximum time for which the kernel
> will feed the watchdog, thus ensuring that either userspace has come
> up, or the board gets reset. This allows fallback logic in the
> bootloader to attempt some recovery (for example, if an automatic
> update is in progress, it could roll back to the previous version).


This makes sense except for being a CONFIG_ option not a boot parameter.
If it's a boot parameter then the same kernel works for multiple systems
and is general. If it's compile time then you have to build a custom
kernel.

For some embedded stuff that might not matter (although I bet they'd
prefer it command line/device tree too) but for something like an x86
platform where you are deploying a standard vendor supplied kernel it's
bad to do it that way IMHO.

In other words I think you should drop patch 3 but the rest is good.

Alan

Re: tty: n_gsm: fix closing multiplexer mode

[Alan Cox]

> disconnect frame before initialising multiplex mode. Since it's not so
> nice that userspace has to know the layout of a disconnect frame,
> the second patch introduces a disconnect ioctl which can be issued
> right before closing the physical port during the first session.
> This ioctl is only useful when during the second session it is known
> the the first session has been closed properly, so I'm not sure
> how useful it is to introduce such an ioctl.

I don't think it justifies an ioctl and the likely use case is that the
tty is hung up when the process dies so would already be in N_TTY at the
point anyone tried to clean up.

A more interesting question - and I don't have enough hardware to test
this any more - would be whether we can safely send that sequence if our
initial connects failed a few times so we try disconnect/reconnect.

Alan

Re: [PATCH 1/1] xilinx ps uart: Adding a kernel parameter for the number of xilinx ps uarts

[Alan Cox]

> We have in soc vendor tree similar patch but the reason is different.
> 
> tty: serial: Added a CONFIG_SERIAL_XILINX_NR_UARTS option.
> 
> This patch Adds CONFIG_SERIAL_XILINX_NR_UARTS option to allow
> the user to provide the Max number of uart ports information.
> If multiple cards (or) PL UARTS are present, the default limit
> of 2 ports should be increased.
> 
> I haven't checked all drivers but in our case we have added this as
> quick fix for scenarios where you use serial aliases where alias is
> pointed to serial2 or more.
> In cdns_uart_init() cdns_uart_uart_driver is passed which contains .nr
> which is required to be passed.
> 
> What's the best driver to look at dynamic allocation?

So there are quite a few that dynamically allocate the objects as they
are enumerated (eg max3100), but have a maximum set that is just pointers
(so for the max number of ports cheaper than the dynamic code)

The other question is why is it a CONFIG_ option. I'm assuming these
platforms are all ARM and in that case you could just pass the value in
the device tree, or hard code a safe maximum number of pointers to a
value which is the worst case and then install them as they are
enumerated.

There are lots of options better than breaking the "one kernel many
platforms" model.

Alan

Re: [PATCH v2 1/7] kernel/locking: Fix compile error with qrwlock.c

[David Miller]

From: Babu Moger 
Date: Fri, 19 May 2017 18:16:55 -0600

> Some architectures use the following guard in include file
>  "asm/spinlock_types.h" to discourage including the file directly.
> 
> Saw these compile errors on SPARC when queued rwlock feature is enabled.
> 
>   CC  kernel/locking/qrwlock.o
> In file included from ./include/asm-generic/qrwlock_types.h:5,
>  from ./arch/sparc/include/asm/qrwlock.h:4,
>  from kernel/locking/qrwlock.c:24:
> ./arch/sparc/include/asm/spinlock_types.h:5:3: error:
> #error "please don't include this file directly"
> 
> Re-arrange the includes in qrwlock_types.h and include spinlock.h
> in qrwlock.c to fix it.
> 
> Also will be removing this stanza from SPARC. Stay tuned.
> 
> Signed-off-by: Babu Moger 
> Reviewed-by: Håkon Bugge 
> Reviewed-by: Jane Chu 
> Reviewed-by: Shannon Nelson 
> Reviewed-by: Vijay Kumar 

In my feedback I said to remove that check from
sparc's asm/spinlock_types.h header.

Which you do in patch #2

But that means this patch #1 here is no longer necessary, since we
conform to the hearder scheme used by other architectures using queued
locks.

So please remove this patch from the series.

Thank you.

Re: [PATCH v2 3/8] thermal: intel_bxt_pmic_thermal: use first level PMIC thermal irq

[sathyanarayanan kuppuswamy]

Hi Rui/Valentin,

Do you have any comments on this patch ? If you agree with this patch, 
Can you please Ack it ?



On 05/22/2017 03:17 AM, Lee Jones wrote:

On Fri, 14 Apr 2017, sathyanarayanan.kuppusw...@linux.intel.com wrote:


From: Kuppuswamy Sathyanarayanan 

PMIC mfd driver only exports first level irq for thermal device.
But currently we are reading the irqs from the second level irq
chip, So this patch fixes this issue by adding support to use
first level PMIC thermal irq.

Signed-off-by: Kuppuswamy Sathyanarayanan 


This still needs a Maintainer Ack.


---
  drivers/thermal/intel_bxt_pmic_thermal.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

Changes since v1:
  * None

diff --git a/drivers/thermal/intel_bxt_pmic_thermal.c 
b/drivers/thermal/intel_bxt_pmic_thermal.c
index 0f19a39..ef6b322 100644
--- a/drivers/thermal/intel_bxt_pmic_thermal.c
+++ b/drivers/thermal/intel_bxt_pmic_thermal.c
@@ -241,7 +241,7 @@ static int pmic_thermal_probe(struct platform_device *pdev)
}
  
  	regmap = pmic->regmap;

-   regmap_irq_chip = pmic->irq_chip_data_level2;
+   regmap_irq_chip = pmic->irq_chip_data;
  
  	pmic_irq_count = 0;

while ((irq = platform_get_irq(pdev, pmic_irq_count)) != -ENXIO) {


--
Sathyanarayanan Kuppuswamy
Linux kernel developer

Re: [PATCH 2/3] RDS: IB: Improve a size determination in rds_ib_add_one()

[Santosh Shilimkar]

On 5/22/2017 7:12 AM, SF Markus Elfring wrote:

From: Markus Elfring 
Date: Mon, 22 May 2017 15:40:21 +0200

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.

Signed-off-by: Markus Elfring 
---

Acked-by: Santosh Shilimkar 

Re: [PATCH net-next 01/20] net: dsa: change scope of STP state setter

[Florian Fainelli]

On 05/19/2017 02:00 PM, Vivien Didelot wrote:
> Instead of having multiple STP state helpers scoping a slave device
> supporting both the DSA logic and the switchdev binding, provide a
> single dsa_port_set_state helper scoping a DSA port, as well as its
> dsa_port_set_state_now wrapper which skips the prepare phase.
> 
> This allows us to better separate the DSA logic from the slave device
> handling.
> 
> Signed-off-by: Vivien Didelot 

Reviewed-by: Florian Fainelli 
-- 
Florian

Re: [PATCH net-next 10/20] net: dsa: move bridging routines

[Florian Fainelli]

On 05/19/2017 02:00 PM, Vivien Didelot wrote:
> Move the DSA port code which bridges a port in port.c, where it belongs.
> 
> Signed-off-by: Vivien Didelot 

Reviewed-by: Florian Fainelli 
-- 
Florian

Re: [PATCH net-next 09/20] net: dsa: move port state setters

[Florian Fainelli]

On 05/19/2017 02:00 PM, Vivien Didelot wrote:
> Add a new port.c file to hold all DSA port-wide logic. This patch moves
> in the code which sets a port state.

Usually, I am not fond of moving code around, but in this case, this
makes the whole directory structure nicer.

> 
> Signed-off-by: Vivien Didelot 

Reviewed-by: Florian Fainelli 
-- 
Florian

Re: [PATCH net-next 17/20] net: dsa: add notifier for ageing time

[Florian Fainelli]

On 05/19/2017 02:00 PM, Vivien Didelot wrote:
> This patch keeps the port-wide ageing time handling code in
> dsa_port_ageing_time, pushes the requested ageing time value in a new
> switch fabric notification, and moves the switch-wide ageing time
> handling code in dsa_switch_ageing_time.
> 
> This has the effect that now not only the switch that the target port
> belongs to can be programmed, but all switches composing the switch
> fabric. For the moment, keep the current behavior and ignore other
> switches.
> 
> Signed-off-by: Vivien Didelot 

Reviewed-by: Florian Fainelli 

> ---
>  net/dsa/dsa_priv.h |  8 
>  net/dsa/port.c | 37 -
>  net/dsa/switch.c   | 46 ++
>  3 files changed, 62 insertions(+), 29 deletions(-)
> 
> diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h
> index c19241eb094b..becaf8a61b13 100644
> --- a/net/dsa/dsa_priv.h
> +++ b/net/dsa/dsa_priv.h
> @@ -17,10 +17,18 @@
>  #include 
>  
>  enum {
> + DSA_NOTIFIER_AGEING_TIME,
>   DSA_NOTIFIER_BRIDGE_JOIN,
>   DSA_NOTIFIER_BRIDGE_LEAVE,

This is so we keep sorting notifier events alphabetically, right?
-- 
Florian

Re: [uml-devel] [PATCH] um: Add mark_rodata_ro support.

[Richard Weinberger]

Thomas,

Am 22.05.2017 um 21:18 schrieb Thomas Meyer:
> 
>> Am 22.05.2017 um 20:34 schrieb Richard Weinberger :
>>
>> Thomas,
>>
>>> Am 22.05.2017 um 20:14 schrieb Thomas Meyer:
>>> It's purely cosmetic; to get rid of the boot message: "This architecture 
>>> does not have kernel memory protection." in init/main.c
>>>
>>> Which isn't true for UML as all read only stuff should end up in a read 
>>> only ELF section. Shouldn't it?
>>
>> Hmm, reading /proc//maps tells a different story on my host.
>> Did you check?
> 
> No... I may should have done so...
> 
> Okay, but it should be possible to mprotect those regions ?

Yes, it should.
Can you give it a try?

Thanks,
//richard

Re: [PATCH net-next 16/20] net: dsa: move notifier info to private header

[Florian Fainelli]

On 05/19/2017 02:00 PM, Vivien Didelot wrote:
> The DSA notifier events and info structure definitions are not meant for
> DSA drivers and users, but only used internally by the DSA core files.
> 
> Move them from the public net/dsa.h file to the private dsa_priv.h file.
> 
> Also use this opportunity to turn the events into an anonymous enum,
> because we don't care about the values, and this will prevent future
> conflicts when adding (and sorting) new events.

LGTM

> 
> Signed-off-by: Vivien Didelot 

Reviewed-by: Florian Fainelli 
-- 
Florian

Re: [PATCH 00/10] paravirt: make amount of paravirtualization configurable

[Boris Ostrovsky]

>  49 files changed, 1548 insertions(+), 1477 deletions(-)
>  create mode 100644 arch/x86/include/asm/paravirt_full.h
>  create mode 100644 arch/x86/include/asm/paravirt_types_full.h
>  create mode 100644 arch/x86/kernel/paravirt_full.c


Do you have this in a tree that can be pulled?

-boris

Re: [PATCH v3 1/2] PCI/portdrv: add support for different MSI interrupts for PCIe port services

[Christoph Hellwig]

On Sun, May 21, 2017 at 03:00:46PM +, Gabriele Paoloni wrote:
> 
> I thought that in your previous review you meant to say that we should
> avoid 2 instances of the same comment (in this patchset I only have this 
> instance as I have removed the same comment from patch 2/2...)

No, there is no pointin the comment.  The whole point of pci_irq_vector
is to abstract away from how to get at the interrupt in detail.  There
is no need to comment on this at the callsite.  If you think the
existing documentation for the function is not good enough send a patch
to improve it there instead of commenting the callsites.

Re: [PATCH 1/3] mfd: lp87565: Add lp87565 PMIC support

[Lee Jones]

On Fri, 19 May 2017, Keerthy wrote:

> The LP87565 chip is a power management IC for Portable Navigation Systems
> and Tablet Computing devices. It contains the following components:
> 
> - Configurable Bucks(Single and multi-phase).
> - Configurable General Purpose Output Signals (GPO).
> 
> The LP87565-Q1 variant device uses two 2-phase outputs configuration,
> Buck0 is master for Buck0/1 output and Buck2 is master for Buck2/3
> output.
> 
> Signed-off-by: Keerthy 
> ---
>  Documentation/devicetree/bindings/mfd/lp87565.txt |  44 
>  drivers/mfd/Kconfig   |  14 ++
>  drivers/mfd/Makefile  |   1 +
>  drivers/mfd/lp87565.c | 103 
>  include/linux/mfd/lp87565.h   | 275 
> ++
>  5 files changed, 437 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/lp87565.txt
>  create mode 100644 drivers/mfd/lp87565.c
>  create mode 100644 include/linux/mfd/lp87565.h
> 
> diff --git a/Documentation/devicetree/bindings/mfd/lp87565.txt 
> b/Documentation/devicetree/bindings/mfd/lp87565.txt
> new file mode 100644
> index 000..38a00a1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/lp87565.txt
> @@ -0,0 +1,44 @@
> +TI LP873565 PMIC MFD driver
> +
> +Required properties:
> +  - compatible:  "ti,lp87565", "ti,lp87565-q1"
> +  - reg: I2C slave address.
> +  - gpio-controller: Marks the device node as a GPIO Controller.
> +  - #gpio-cells: Should be two.  The first cell is the pin number and
> + the second cell is used to specify flags.
> + See ../gpio/gpio.txt for more information.
> +  - xxx-in-supply:   Phandle to parent supply node of each regulator
> + populated under regulators node. xxx should match
> + the supply_name populated in driver.
> +  - regulators:  List of child nodes that specify the regulator
> + initialization data.
> +Example:
> +
> +lp87565: lp87565@60 {
> + compatible = "ti,lp87565-q1";
> + reg = <0x60>;
> + gpio-controller;
> + #gpio-cells = <2>;
> +
> + buck10-in-supply =<_3v3>;
> + buck23-in-supply =<_3v3>;

White space errors.

'\n' here.

> + regulators: regulators {
> + buck10_reg: buck10 {
> + /*VDD_MPU*/

Whitespace errors.

> + regulator-name = "buck10";
> + regulator-min-microvolt = <85>;
> + regulator-max-microvolt = <125>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + buck23_reg: buck23 {
> + /* VDD_GPU*/

Whitespace errors.

> + regulator-name = "buck23";
> + regulator-min-microvolt = <85>;
> + regulator-max-microvolt = <125>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> + };
> +};
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 3eb5c93..5e884f3 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1325,6 +1325,20 @@ config MFD_TI_LP873X
> This driver can also be built as a module. If so, the module
> will be called lp873x.
>  
> +config MFD_TI_LP87565
> + tristate "TI LP87565 Power Management IC"
> + depends on I2C
> + select MFD_CORE
> + select REGMAP_I2C
> + help
> +   If you say yes here then you get support for the LP87565 series of
> +   Power Management Integrated Circuits (PMIC).
> +   These include voltage regulators, thermal protection, configurable
> +   General Purpose Outputs (GPO) that are used in portable devices.
> +
> +   This driver can also be built as a module. If so, the module
> +   will be called lp87565.
> +
>  config MFD_TPS65218
>   tristate "TI TPS65218 Power Management chips"
>   depends on I2C
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index c16bf1e..7edbe1b 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -25,6 +25,7 @@ obj-$(CONFIG_HTC_PASIC3)+= htc-pasic3.o
>  obj-$(CONFIG_HTC_I2CPLD) += htc-i2cpld.o
>  
>  obj-$(CONFIG_MFD_TI_LP873X)  += lp873x.o
> +obj-$(CONFIG_MFD_TI_LP87565) += lp87565.o
>  
>  obj-$(CONFIG_MFD_DAVINCI_VOICECODEC) += davinci_voicecodec.o
>  obj-$(CONFIG_MFD_DM355EVM_MSP)   += dm355evm_msp.o
> diff --git a/drivers/mfd/lp87565.c b/drivers/mfd/lp87565.c
> new file mode 100644
> index 000..dff882f
> --- /dev/null
> +++ b/drivers/mfd/lp87565.c
> @@ -0,0 +1,103 @@
> +/*
> + * Copyright (C) 2017 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * Author: Keerthy 

We usually ask for full "first last" names.

> + * This program is free software; you can redistribute it and/or
> + * 

Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC

[Jernej Škrabec]

Hi,

Dne sobota, 20. maj 2017 ob 03:37:53 CEST je Chen-Yu Tsai napisal(a):
> On Sat, May 20, 2017 at 2:23 AM, Jernej Škrabec  
wrote:
> > Hi,
> > 
> > Dne petek, 19. maj 2017 ob 20:08:18 CEST je Icenowy Zheng napisal(a):
> >> 于 2017年5月20日 GMT+08:00 上午2:03:30, Maxime Ripard  > 
> > electrons.com> 写到:
> >> >On Thu, May 18, 2017 at 12:43:50AM +0800, Icenowy Zheng wrote:
> >> >> Allwinner H3 features a TV encoder similar to the one in earlier
> >> >
> >> >SoCs,
> >> >
> >> >> but with some different points about clocks:
> >> >> - It has a mod clock and a bus clock.
> >> >> - The mod clock must be at a fixed rate to generate signal.
> >> >
> >> >Why?
> >> 
> >> It's experiment result by Jernej.
> >> 
> >> The clock rates in BSP kernel is also specially designed
> >> (PLL_DE at 432MHz) in order to be able to feed the TVE.
> > 
> > My experiments and search through BSP code showed that TVE seems to have
> > additional fixed predivider 8. So if you want to generate 27 MHz clock,
> > unit has to be feed with 216 MHz.
> > 
> > TVE has only one PLL source PLL_DE. And since 216 MHz is a bit low for
> > DE2,
> > BSP defaults to 432 MHz for PLL_DE and use divider 2 to generate 216 MHz.
> > This clock is then divided by 8 internaly to get final 27 MHz.
> > 
> > Please note that I don't have any hard evidence to support that, only
> > experimental data. However, only that explanation make sense to me.
> > 
> > BTW, BSP H3/H5 TV driver supports only PAL and NTSC which both use 27 MHz
> > base clock. Further experiments are needed to check if there is any
> > possibility to have other resolutions by manipulating clocks and give
> > other proper settings. I plan to do that, but not in very near future.
> 
> You only have composite video output, and those are the only 2 standard
> resolutions that make any sense.

Right, other resolutions are for VGA.

Anyway, I did some more digging in A10 and R40 datasheets. I think that H3 TVE 
unit is something in between. R40 TVE has a setting to select "up sample". 
Possible settings are 27 MHz, 54 MHz, 108 MHz and 216 MHz. BSP driver on R40 
has this setting enabled only for PAL and NTSC and it is always 216 MHz. I 
think that H3 may have this hardwired to 216 MHz and this would be the reason 
why 216 MHz is needed.

Has anyone else any better explanation?

Best regards,
Jernej

Re: dm ioctl: Restore __GFP_HIGH in copy_params()

[Mike Snitzer]

On Mon, May 22 2017 at 11:03am -0400,
Michal Hocko  wrote:

> On Mon 22-05-17 10:52:44, Mikulas Patocka wrote:
> > 
> > 
> > On Mon, 22 May 2017, Michal Hocko wrote:
> [...] 
> > > I am not sure I understand. OOM killer is invoked for _all_ allocations
> > > <= PAGE_ALLOC_COSTLY_ORDER that do not have __GFP_NORETRY as long as the
> > > OOM killer is not disabled (oom_killer_disable) and that only happens
> > > from the PM suspend path which makes sure that no userspace is active at
> > > the time. AFAIU this is a userspace triggered path and so the later
> > > shouldn't apply to it and GFP_KERNEL should be therefore sufficient.
> > > Relying to a portion of memory reserves to prevent from deadlock seems
> > > fundamentaly broken  to me.
> > > 
> > 
> > The lvm2 was designed this way - it is broken, but there is not much that 
> > can be done about it - fixing this would mean major rewrite. The only 
> > thing we can do about it is to lower the deadlock probability with 
> > __GFP_HIGH (or PF_MEMALLOC that was used some times ago).

Yes, lvm2 was originally designed to to have access to memory reserves
to ensure forward progress.  But if the mm subsystem has improved to
allow for the required progress without lvm2 trying to stake a claim on
those reserves then we'll gladly avoid (ab)using them.

> But let me repeat. GFP_KERNEL allocation for order-0 page will not fail.

OK, but will it be serviced immediately?  Not failing isn't useful if it
never completes.

> If you need non-failing semantic then just make it clear by adding
> __GFP_NOFAIL rather than __GFP_HIGH. Memory reserves are a scarce
> resource and there are users which might really need it from atomic
> contexts.

While adding the __GFP_NOFAIL flag would serve to document expectations
I'm left unconvinced that the memory allocator will _not fail_ for an
order-0 page -- as Mikulas said most ioctls don't need more than 4K.
(Apologies if you've already covered _why_ we can have confidence in the
mm subsystem's ability to ensure forward progress for these allocations).

Mike

Re: [PATCH v2 00/10] rt2x00: rt2x00: improve calling conventions for register accessors

[Jes Sorensen]

On 05/17/2017 10:46 AM, Arnd Bergmann wrote:

I've managed to split up my long patch into a series of reasonble
steps now.

The first two are required to fix a regression from commit 41977e86c984
("rt2x00: add support for MT7620"), the rest are just cleanups to
have a consistent state across all the register access functions.

  Arnd


Nice work! This is a textbook example of how to do this the right way!

Reviewed-by: Jes Sorensen 

Jes

Re: [PATCH v4 05/10] drm: arc: Use crtc->mode_valid() callback

[Alexey Brodkin]

Hi Jose,

The only nitpicking note from my side is patch name.

Probably full driver name as "arcpgu" might give a bit more context
especially if later something else from ARC appears in "drm" folder.
But IMHO that doesn't worth another respin.

On Fri, 2017-05-19 at 01:52 +0100, Jose Abreu wrote:
> Now that we have a callback to check if crtc supports a given mode
> we can use it in arcpgu so that we restrict the number of probbed
> modes to the ones we can actually display.
> 
> This is specially useful because arcpgu crtc is responsible to set
> a clock value in the commit() stage but unfortunatelly this clock
> does not support all the needed ranges.
> 
> Also, remove the atomic_check() callback as mode_valid() callback
> will be called before.
> 
> Signed-off-by: Jose Abreu 
> Cc: Carlos Palminha 
> Cc: Alexey Brodkin 

Reviewed-by: Alexey Brodkin 

Re: [PATCH v2 4/4] net-next: stmmac: rework the speed selection

[David Miller]

From: Corentin Labbe 
Date: Mon, 22 May 2017 14:33:47 +0200

> The current stmmac_adjust_link() part which handle speed have
> some if (has_platform) code and my dwmac-sun8i will add more of them.
> 
> So we need to handle better speed selection.
> Moreover the struct link member speed and port are hard to guess their
> purpose. And their unique usage are to be combined for writing speed.
> 
> So this patch replace speed/port by simpler
> speed10/speed100/speed1000/speed_mask variables.
> 
> In dwmac4_core_init and dwmac1000_core_init, port/speed value was used
> directly without using the struct link. This patch convert also their
> usage to speedxxx.
> 
> Signed-off-by: Corentin Labbe 
> ---
>  drivers/net/ethernet/stmicro/stmmac/common.h   |  8 ---
>  .../net/ethernet/stmicro/stmmac/dwmac1000_core.c   | 26 
> +-
>  .../net/ethernet/stmicro/stmmac/dwmac100_core.c|  6 +++--
>  drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c  | 26 
> +-
>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c  | 21 -
>  5 files changed, 43 insertions(+), 44 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h 
> b/drivers/net/ethernet/stmicro/stmmac/common.h
> index b7ce3fbb5375..e82b4b70b7be 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/common.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/common.h
> @@ -549,9 +549,11 @@ extern const struct stmmac_hwtimestamp stmmac_ptp;
>  extern const struct stmmac_mode_ops dwmac4_ring_mode_ops;
>  
>  struct mac_link {
> - int port;
> - int duplex;
> - int speed;
> + u32 speed_mask;
> + u32 speed10;
> + u32 speed100;
> + u32 speed1000;
> + u32 duplex;
>  };
>  
>  struct mii_regs {
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c 
> b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
> index f3d9305e5f70..b8848a9d70c5 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
> @@ -45,15 +45,17 @@ static void dwmac1000_core_init(struct mac_device_info 
> *hw, int mtu)
>   if (hw->ps) {
>   value |= GMAC_CONTROL_TE;
>  
> - if (hw->ps == SPEED_1000) {
> - value &= ~GMAC_CONTROL_PS;
> - } else {
> - value |= GMAC_CONTROL_PS;
> -
> - if (hw->ps == SPEED_10)
> - value &= ~GMAC_CONTROL_FES;
> - else
> - value |= GMAC_CONTROL_FES;
> + value &= ~hw->link.speed_mask;
> + switch (hw->ps) {
> + case SPEED_1000:
> + value |= hw->link.speed1000;
> + break;
> + case SPEED_100:
> + value |= hw->link.speed100;
> + break;
> + case SPEED_10:
> + value |= hw->link.speed10;
> + break;
>   }
>   }
>  
> @@ -531,9 +533,11 @@ struct mac_device_info *dwmac1000_setup(void __iomem 
> *ioaddr, int mcbins,
>   mac->mac = _ops;
>   mac->dma = _dma_ops;
>  
> - mac->link.port = GMAC_CONTROL_PS;
>   mac->link.duplex = GMAC_CONTROL_DM;
> - mac->link.speed = GMAC_CONTROL_FES;
> + mac->link.speed10 = GMAC_CONTROL_PS;
> + mac->link.speed100 = GMAC_CONTROL_PS | GMAC_CONTROL_FES;
> + mac->link.speed1000 = 0;
> + mac->link.speed_mask = GENMASK(15, 14);

Neither GMAC_CONTROL_PS nor GMAC_CONTROL_FES are defined with
the GENMASK() macro.  So it is very confusing to see constant
bit specifications here in C code.

There are two ways to do this properly:

1) Use "(GMAC_CONTROL_PS | GMAC_CONTROL_FES)"

2) Define a new GMAC_CONTROL_SPDMASK to "GMAC_CONTROL_PS | GMAC_CONTROL_FES"
   and use that here.

> @@ -747,9 +749,11 @@ struct mac_device_info *dwmac4_setup(void __iomem 
> *ioaddr, int mcbins,
>   if (mac->multicast_filter_bins)
>   mac->mcast_bits_log2 = ilog2(mac->multicast_filter_bins);
>  
> - mac->link.port = GMAC_CONFIG_PS;
>   mac->link.duplex = GMAC_CONFIG_DM;
> - mac->link.speed = GMAC_CONFIG_FES;
> + mac->link.speed10 = GMAC_CONFIG_PS;
> + mac->link.speed100 = GMAC_CONFIG_FES | GMAC_CONFIG_PS;
> + mac->link.speed1000 = 0;
> + mac->link.speed_mask = GENMASK(15, 14);
>   mac->mii.addr = GMAC_MDIO_ADDR;
>   mac->mii.data = GMAC_MDIO_DATA;
>   mac->mii.addr_shift = 21;

Likewise.

Re: [PATCH 10/23] afs: switch to use uuid_t and uuid_gen

[Andy Shevchenko]

On Thu, 2017-05-18 at 08:26 +0200, Christoph Hellwig wrote:

Changelog?

> Signed-off-by: Christoph Hellwig 
> Reviewed-by: David Howells 

> @@ -453,7 +453,7 @@ static int afs_deliver_cb_probe(struct afs_call
> *call)
>  static void SRXAFSCB_ProbeUuid(struct work_struct *work)
>  {
>   struct afs_call *call = container_of(work, struct afs_call,
> work);
> - struct uuid_v1 *r = call->request;
> + uuid_t *r = call->request;
>  
>   struct {
>   __be32  match;
> 

Just to double check that this doesn't create a union aliasing.

-- 
Andy Shevchenko 
Intel Finland Oy

Re: [PATCH 00/13] Linksys WRT3200ACM (Rango) support

[Imre Kaloz]

Hi everyone,

For the whole series feel free to add

Signed-off-by: Imre Kaloz 


Best,

Imre

On 2017-05-21 05:48, Ralph Sennhauser wrote:

Hi everyone

This series adds support for the latest model in Linksys WRT AC series
of routers. The WRT3200ACM was released in October 2016 and the code
name is Rango.

As it comes with a flash chip twice as big the dts Imre Kaloz has
written for OpenWrt isn't based on armada-385-linksys.dtsi to avoid
conflicts. Nonetheless its part of the same family, so the bigger part
of this series is dedicated to reorganize / modernize / cleanup /
somewhat future proof the armada-385-linksys.dtsi and it's dependants so
the dts for the Rango addition can use the same dtsi.

Key differences to the earlier Armada-385 based devices in the series is
a bigger flash chip, next generation wireless modules in the mini pcie
slots as well as a Marvell SD8887. Finally the CPU is clocked at 1866
GHz by default.

The series depends on Linux 4.12-rc1 and is targeted for 4.13.

Ralph


Ralph Sennhauser (13):
   ARM: dts: armada-385-linksys: flatten dtsi
   ARM: dts: armada-385-linksys: label nodes
   ARM: dts: armada-385-linksys: flatten dependan
   ARM: dts: armada-385-linksys: drop redundant properties in dependants
   ARM: dts: armada-385-linksys: bm pools by label order
   ARM: dts: armada-385-linksys: usb3 label cleanup
   ARM: dts: armada-385-linksys: drop leagcy DSA bindings
   ARM: dts: armada-385-linksys: use binary unit prefixes
   ARM: dts: armada-385-linksys: partition layout is board specific
   ARM: dts: armada-385-linksys: group pins in pinctrl
   ARM: dts: armada-385-linksys: fixup button node names
   clk: mvebu: add support for 1866MHz variants
   ARM: dts: mvebu: add support for Linksys WRT3200ACM (Rango)

  arch/arm/boot/dts/Makefile  |   1 +
  arch/arm/boot/dts/armada-385-linksys-caiman.dts | 187 +++-
  arch/arm/boot/dts/armada-385-linksys-cobra.dts  | 187 +++-
  arch/arm/boot/dts/armada-385-linksys-rango.dts  | 203 +
  arch/arm/boot/dts/armada-385-linksys-shelby.dts | 187 +++-
  arch/arm/boot/dts/armada-385-linksys.dtsi   | 362 
  drivers/clk/mvebu/armada-38x.c  |   3 +-
  7 files changed, 695 insertions(+), 435 deletions(-)
  create mode 100644 arch/arm/boot/dts/armada-385-linksys-rango.dts

Re: [PATCH 23/23] uuid: remove uuid_be

[Andy Shevchenko]

On Thu, 2017-05-18 at 10:56 +0200, Christoph Hellwig wrote:
> On Thu, May 18, 2017 at 10:57:24AM +0300, Amir Goldstein wrote:
> > I reviewed the entire series. You may add
> > Reviewed-by: Amir Goldstein 
> > 
> > to any of the patches as you see fit.
> 
> Thanks, done!

Similar from my side, FWIW:
Reviewed-by: Andy Shevchenko 

> 
> > Now let's talk about how this is going to be merged.
> > Do you intend to send Linus a pull request?
> 
> Yes, that might be the best idea.  I'm also contemplating listing
> me plus anyone volunteering (you?, Andy) as maintaines for the uuid
> code.

I would agree to be a designated reviewer for now (too many stuff to
follow as a (co-)maintainer).

> > The reason I am asking is because this last removal patch should
> > probably
> > be applied near the end of the merge window (?).
> > Because maintainers cannot apply patches with code that uses the new
> > uuid_t to linux-next branches and we don't want linux-next build to
> > fail
> > with new code that uses uuid_be...
> 
> Yeah, we can probably defer that one for now.

I would also like to append some of patches from my side, though they
are WIP.

-- 
Andy Shevchenko 
Intel Finland Oy

Power Generation Industry Database

[Chris Harris]

Hi,

 

Are you interested to reach the newly updated Power Generation Industry
Database which includes complete contact details and verified email
addresses of - CEO's, Directors, Decision Makers, Electric Utilities,
Architects/Engineers, Co-generators/Self-generators, Construction &
Maintenance Contractors, Fuel Suppliers, Independent Power Producers,
Original Equipment Manufacturers, Power Industry Consultants, Power Plant
Designers, Project Developers, Research & Development Organizations,
Equipment Inspection and Repair Specialists, Construction Contractors,
Maintenance Service Providers, Operations Service Providers, Project Finance
and Insurance Companies, IT Specialists and many more across USA, UK,
Canada, Australia, Europe and most of the world.

 

If your target audience is not mentioned above, kindly let me know.

 

Please send me your target audience and geographical area, so that I can
give you more information, Counts, Pricing as well as few samples, just for
your review.

 

Target Industry :  _  Target Geography :  __
Target Job Title :  _ 

 

Looking forward to hear from you.

 

Note: Samples are available as per your request.

 

Best Regards,

 

Chris Harris

Online Marketing Manager

 

If you do not wish to receive future emails from us, please reply as 'leave
out'

 

 

Re: Build regressions/improvements in v4.12-rc2

[John David Anglin]

On 2017-05-22, at 5:49 AM, Geert Uytterhoeven wrote:

>> [Deleted 1166 lines about "warning: -ffunction-sections disabled; it makes 
>> profiling impossible [enabled by default]" on parisc-allmodconfig]

Although this issue may be fixed in gcc, do we really want to enable profiling 
by default?

Dave
--
John David Anglin   dave.ang...@bell.net

Re: [RFC][PATCH 0/9] Make containers kernel objects

[Eric W. Biederman]

David Howells  writes:

> Here are a set of patches to define a container object for the kernel and
> to provide some methods to create and manipulate them.
>
> The reason I think this is necessary is that the kernel has no idea how to
> direct upcalls to what userspace considers to be a container - current
> Linux practice appears to make a "container" just an arbitrarily chosen
> junction of namespaces, control groups and files, which may be changed
> individually within the "container".
>

I think this might possibly be a useful abstraction for solving the
keyring upcalls if it was something created implicitly.

fork_into_container for use by keyring upcalls is currently a security
vulnerability as it allows escaping all of a containers cgroups.  But
you have that on your list of things to fix.  However you don't have
seccomp and a few other things.

Before we had kthreadd in the kernel upcalls always had issues because
the code to reset all of the userspace bits and make the forked
task suitable for running upcalls was always missing some detail.  It is
a very bug-prone kind of idiom that you are talking about.  It is doubly
bug-prone because the wrongness is visible to userspace and as such
might get become a frozen KABI guarantee.

Let me suggest a concrete alternative:

- At the time of mount observer the mounters user namespace.
- Find the mounters pid namespace.
- If the mounters pid namespace is owned by the mounters user namespace
  walk up the pid namespace tree to the first pid namespace owned by
  that user namespace.
- If the mounters pid namespace is not owned by the mounters user
  namespace fail the mount it is going to need to make upcalls as
  will not be possible.
- Hold a reference to the pid namespace that was found.

Then when an upcall needs to be made fork a child of the init process
of the specified pid namespace.  Or fail if the init process of the
pid namespace has died.

That should always work and it does not require keeping expensive state
where we did not have it previously.  Further because the semantics are
fork a child of a particular pid namespace's init as features get added
to the kernel this code remains well defined.

For ordinary request-key upcalls we should be able to use the same rules
and just not save/restore things in the kernel.

A huge advantage of my alternative (other than not being a bit-rot
magnet) is that it should drop into existing container infrastructure
without problems.  The rule for container implementors is simple to use
security key infrastructure you need to have created a pid namespace in
your user namespace.

Eric

Re: [PATCH net-next 03/20] net: dsa: change scope of bridging code

[Florian Fainelli]

On 05/19/2017 02:00 PM, Vivien Didelot wrote:
> Now that the bridge join and leave functions only deal with a DSA port,
> change their scope from the DSA slave net_device to the DSA generic
> dsa_port.
> 
> Signed-off-by: Vivien Didelot 

Reviewed-by: Florian Fainelli 
-- 
Florian

Re: [PATCH net-next 04/20] net: dsa: change scope of FDB handlers

[Florian Fainelli]

On 05/19/2017 02:00 PM, Vivien Didelot wrote:
> Change the scope of the switchdev FDB object handlers from the DSA slave
> device to the generic DSA port, so that the future port-wide API can
> also be used for other port types, such as CPU and DSA links.
> 
> Signed-off-by: Vivien Didelot 

Reviewed-by: Florian Fainelli 
-- 
Florian

Re: [PATCH 2/2] perf/x86/intel, watchdog: Switch NMI watchdog to ref cycles on x86

[Peter Zijlstra]

On Mon, May 22, 2017 at 04:58:04PM +, Liang, Kan wrote:
> 
> 
> > On Fri, May 19, 2017 at 10:06:22AM -0700, kan.li...@intel.com wrote:
> > > This patch was once merged, but reverted later.
> > > Because ref-cycles can not be used anymore when watchdog is enabled.
> > > The commit is 44530d588e142a96cf0cd345a7cb8911c4f88720
> > >
> > > The patch 1/2 has extended the ref-cycles to GP counter. The concern
> > > should be gone.
> > 
> > So its not a problem if every Atom prior to Goldmont, and all Core/Core2
> > products regress?
> > 
> > P6 and P4 you've entirely broken, as they don't have REF_CPU_CYCLES at all.
> > 
> > So no, I don't think this is right even now.
> > 
> 
> Right, the patch 1/2 doesn't cover all platforms.
> I will only apply the patch for the platforms,
> which have ref cycles on GP counters.

Right, so if you move the weak function into arch/x86/events/core.c and
simply test for x86_pmu.this_ref_alis_function_thing being !NULL that
should all work.

Re: RFC: better timer interface

[Thomas Gleixner]

On Mon, 22 May 2017, Arnd Bergmann wrote:
> On Sun, May 21, 2017 at 8:14 PM, Thomas Gleixner  wrote:
> > But it's easy enough to provide them. All we need for that is something
> > like
> >
> > unsigned long time_msec;
> >
> > which gets incremented every tick by the appropriate amount of
> > milliseconds.
> >
> > Having that would also allow to replace all the
> >
> >end = jiffies + msec_to_jiffies(xxx);
> >
> >while (time_before(jiffies, end))
> >  
> >
> > constructs with a milliseconds based machinery. So we can remove all
> > *_to_jiffies() interfaces over time.
> 
> A lot of those users could probably just ktime_get()/ktime_before() here,
> as they would by definition not be performance critical.

Right.

> I don't see a way to just tk->tkr_mono.base but with a ktime_get_coarse()
> we could just return the ktime_t of the last tick and not even need a seqlock
> on 64-bit architectures, or have to introduce a new API.

Yeah, that would be possible, but OTOH, for those loop thingies it probably
does not matter at all whether you have the overhead of ktime_get() or
not. We need to look at that stuff deeper.

Thanks,

tglx

[GIT] Networking

[David Miller]

Mostly netfilter bug fixes in here, but we have some bits elsewhere
as well.

1) Don't do SNAT replies for non-NATed connections in IPVS, from Julian
   Anastasov.

2) Don't delete conntrack helpers while they are still in use, from
   Liping Zhang.

3) Fix zero padding in xtables's xt_data_to_user(), from Willem de
   Bruijn.

4) Add proper RCU protection to nf_tables_dump_set() because we cannot
   guarantee that we hold the NFNL_SUBSYS_NFTABLES lock.  From Liping
   Zhang.

5) Initialize rcv_mss in tcp_disconnect(), from Wei Wang.

6) smsc95xx devices can't handle IPV6 checksums fully, so don't
   advertise support for offloading them.  From Nisar Sayed.

7) Fix out-of-bounds access in __ip6_append_data(), from Eric Dumazet.

8) Make atl2_probe() propagate the error code properly on failures,
   from Alexey Khoroshilov.

9) arp_target[] in bond_check_params() is used uninitialized.  This got
   changes from a global static to a local variable, which is how this
   mistake happened.  Fix from Jarod Wilson.

10) Fix fallout from unnecessary NULL check removal in cls_matchall,
from Jiri Pirko.  This is definitely brown paper bag territory...

Please pull, thanks a lot!

The following changes since commit 8b4822de59d5d9919b9b045183a36c673ce20b73:

  Merge tag 'md/4.12-rc2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/shli/md (2017-05-18 12:04:41 
-0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git 

for you to fetch changes up to 2d76b2f8b54abd16225cd80afca36ed43f113c41:

  net: sched: cls_matchall: fix null pointer dereference (2017-05-22 14:54:16 
-0400)


Alexey Khoroshilov (1):
  net: atheros: atl2: don't return zero on failure path in atl2_probe()

David S. Miller (3):
  Merge git://git.kernel.org/.../pablo/nf
  Merge branch 
'arp-always-override-existing-neigh-entries-with-gratuitous-ARP'
  net: Make IP alignment calulations clearer.

Eric Dumazet (1):
  ipv6: fix out of bound writes in __ip6_append_data()

Eric Leblond (1):
  netfilter: synproxy: fix conntrackd interaction

Gao Feng (1):
  ebtables: arpreply: Add the standard target sanity check

Ihar Hrachyshka (4):
  arp: fixed error in a comment
  arp: decompose is_garp logic into a separate function
  arp: postpone addr_type calculation to as late as possible
  arp: always override existing neigh entries with gratuitous ARP

Jarod Wilson (2):
  bonding: fix accounting of active ports in 3ad
  bonding: fix randomly populated arp target array

Jiri Pirko (1):
  net: sched: cls_matchall: fix null pointer dereference

Julian Anastasov (1):
  ipvs: SNAT packet replies only for NATed connections

Liping Zhang (4):
  netfilter: don't setup nat info for confirmed ct
  netfilter: introduce nf_conntrack_helper_put helper function
  netfilter: nfnl_cthelper: reject del request if helper obj is in use
  netfilter: nf_tables: can't assume lock is acquired when dumping set elems

Matthias Kaehlcke (1):
  netfilter: ctnetlink: Make some parameters integer to avoid enum mismatch

Nisar Sayed (1):
  smsc95xx: Support only IPv4 TCP/UDP csum offload

Pablo Neira Ayuso (3):
  Merge tag 'ipvs-fixes-for-v4.12' of http://git.kernel.org/.../horms/ipvs
  netfilter: nf_tables: missing sanitization in data from userspace
  netfilter: nf_tables: revisit chain/object refcounting from elements

WANG Cong (1):
  vsock: use new wait API for vsock_stream_sendmsg()

Wei Wang (1):
  tcp: initialize rcv_mss to TCP_MIN_MSS instead of 0

Willem de Bruijn (2):
  netfilter: xtables: zero padding in data_to_user
  netfilter: xtables: fix build failure from COMPAT_XT_ALIGN outside 
CONFIG_COMPAT

Xin Long (1):
  bridge: start hello_timer when enabling KERNEL_STP in br_stp_start

 drivers/net/bonding/bond_3ad.c  |   2 +-
 drivers/net/bonding/bond_main.c |   5 ++--
 drivers/net/ethernet/atheros/atlx/atl2.c|   8 +++---
 drivers/net/usb/smsc95xx.c  |  13 ++---
 include/linux/netfilter/x_tables.h  |   2 +-
 include/linux/netfilter_bridge/ebtables.h   |   5 
 include/net/netfilter/nf_conntrack_helper.h |   4 +++
 include/net/netfilter/nf_tables.h   |   2 +-
 kernel/bpf/verifier.c   |  12 ++---
 net/bridge/br_stp_if.c  |   1 +
 net/bridge/br_stp_timer.c   |   2 +-
 net/bridge/netfilter/ebt_arpreply.c |   3 +++
 net/bridge/netfilter/ebtables.c |   9 ---
 net/ipv4/arp.c  |  56 
+++
 net/ipv4/tcp.c  |   4 +++
 net/ipv6/ip6_output.c   |  15 ++-
 net/netfilter/ipvs/ip_vs_core.c |  19 ++
 net/netfilter/nf_conntrack_helper.c |  12 +
 

Re: [PATCH net-next 13/20] net: dsa: move FDB handlers

[Florian Fainelli]

On 05/19/2017 02:00 PM, Vivien Didelot wrote:
> Move the DSA port code which handles FDB objects in port.c, where it
> belongs.
> 
> Signed-off-by: Vivien Didelot 

Reviewed-by: Florian Fainelli 
-- 
Florian

Re: [PATCH net-next 14/20] net: dsa: move MDB handlers

[Florian Fainelli]

On 05/19/2017 02:00 PM, Vivien Didelot wrote:
> Move the DSA port code which handles MDB objects in port.c, where it
> belongs.
> 
> Signed-off-by: Vivien Didelot 

Reviewed-by: Florian Fainelli 
-- 
Florian

[GIT PULL] Power management updates for v4.12-rc3

[Rafael J. Wysocki]

Hi Linus,

Please pull from the tag

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 pm-4.12-rc3

with top-most commit bb47e964175e5fb4c163066e4373fac055fe5da0

 Merge branches 'pm-sleep' and 'powercap'

on top of commit 08332893e37af6ae779367e78e444f8f9571511d

 Linux 4.12-rc2

to receive power management updates for v4.12-rc3.

These fix RTC wakeup from suspend-to-idle broken recently, fix CPU
idleness detection condition in the schedutil cpufreq governor, fix
a cpufreq driver build failure, fix an error code path in the power
capping framework, clean up the hibernate core and update the
intel_pstate documentation.

Specifics:

 - Fix RTC wakeup from suspend-to-idle broken by the recent rework
   of ACPI wakeup handling (Rafael Wysocki).

 - Update intel_pstate driver documentation to reflect the current
   code and explain how it works in more detail (Rafael Wysocki).

   That had dependencies in both the PM and documentation trees
   which all have been merged now.

 - Fix an issue related to CPU idleness detection on systems with
   shared cpufreq policies in the schedutil governor (Juri Lelli).

 - Fix a possible build issue in the dbx500 cpufreq driver (Arnd
   Bergmann).

 - Fix a function in the power capping framework core to return
   an error code instead of 0 when there's an error (Dan Carpenter).

 - Clean up variable definition in the hibernation core (Pushkar
   Jambhlekar).

Thanks!


---

Arnd Bergmann (1):
  cpufreq: dbx500: add a Kconfig symbol

Dan Carpenter (1):
  PowerCap: Fix an error code in powercap_register_zone()

Juri Lelli (1):
  cpufreq: schedutil: use now as reference when aggregating shared
policy requests

Pushkar Jambhlekar (1):
  PM / hibernate: Declare variables as static

Rafael J. Wysocki (3):
  cpufreq: intel_pstate: Document the current behavior and user interface
  PM / wakeup: Fix up wakeup_source_report_event()
  RTC: rtc-cmos: Fix wakeup from suspend-to-idle

---

 Documentation/admin-guide/pm/cpufreq.rst  |  19 +-
 Documentation/admin-guide/pm/index.rst|   1 +
 Documentation/admin-guide/pm/intel_pstate.rst | 755 ++
 Documentation/cpu-freq/intel-pstate.txt   | 281 --
 drivers/base/power/wakeup.c   |  11 +-
 drivers/cpufreq/Kconfig.arm   |   9 +
 drivers/cpufreq/Makefile  |   2 +-
 drivers/powercap/powercap_sys.c   |   1 +
 drivers/rtc/rtc-cmos.c|   2 +-
 kernel/power/snapshot.c   |   2 +-
 kernel/sched/cpufreq_schedutil.c  |   7 +-
 11 files changed, 787 insertions(+), 303 deletions(-)

[PATCH] [media] uvcvideo: Prevent heap overflow in uvc driver

[Guenter Roeck]

From: Robb Glasser 

The size of uvc_control_mapping is user controlled leading to a
potential heap overflow in the uvc driver. This adds a check to verify
the user provided size fits within the bounds of the defined buffer
size.

Signed-off-by: Robb Glasser 
[groeck: cherry picked from
 https://source.codeaurora.org/quic/la/kernel/msm-3.10
 commit b7b99e55bc7770187913ed092990852ea52d7892;
 updated subject]
Signed-off-by: Guenter Roeck 
---
Fixes CVE-2017-0627.

 drivers/media/usb/uvc/uvc_ctrl.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c
index c2ee6e39fd0c..252ab991396f 100644
--- a/drivers/media/usb/uvc/uvc_ctrl.c
+++ b/drivers/media/usb/uvc/uvc_ctrl.c
@@ -1992,6 +1992,9 @@ int uvc_ctrl_add_mapping(struct uvc_video_chain *chain,
if (!found)
return -ENOENT;
 
+   if (ctrl->info.size < mapping->size)
+   return -EINVAL;
+
if (mutex_lock_interruptible(>ctrl_mutex))
return -ERESTARTSYS;
 
-- 
2.7.4

Re: [PATCH 3/5] sctp: Fix a typo in a comment line in sctp_init()

[Marcelo Ricardo Leitner]

On Mon, May 22, 2017 at 06:39:29PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Mon, 22 May 2017 17:43:44 +0200
> 
> Add a missing character in this description.
> 
> Signed-off-by: Markus Elfring 

Acked-by: Marcelo Ricardo Leitner 

> ---
>  net/sctp/protocol.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
> index 5e7c8a344770..64756c42cec9 100644
> --- a/net/sctp/protocol.c
> +++ b/net/sctp/protocol.c
> @@ -1454,7 +1454,7 @@ static __init int sctp_init(void)
>   }
>  
>   /* Allocate and initialize the SCTP port hash table.
> -  * Note that order is initalized to start at the max sized
> +  * Note that order is initialized to start at the max sized
>* table we want to support.  If we can't get that many pages
>* reduce the order and try again
>*/
> -- 
> 2.13.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH 4/5] sctp: Improve a size determination in sctp_inetaddr_event()

[Marcelo Ricardo Leitner]

On Mon, May 22, 2017 at 06:40:37PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Mon, 22 May 2017 18:08:24 +0200
> 
> 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.
> 
> Signed-off-by: Markus Elfring 

Acked-by: Marcelo Ricardo Leitner 

> ---
>  net/sctp/protocol.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
> index 64756c42cec9..057479b7bd72 100644
> --- a/net/sctp/protocol.c
> +++ b/net/sctp/protocol.c
> @@ -784,7 +784,7 @@ static int sctp_inetaddr_event(struct notifier_block 
> *this, unsigned long ev,
>  
>   switch (ev) {
>   case NETDEV_UP:
> - addr = kmalloc(sizeof(struct sctp_sockaddr_entry), GFP_ATOMIC);
> + addr = kmalloc(sizeof(*addr), GFP_ATOMIC);
>   if (addr) {
>   addr->a.v4.sin_family = AF_INET;
>   addr->a.v4.sin_port = 0;
> -- 
> 2.13.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH 2/5] sctp: Delete an error message for a failed memory allocation in sctp_init()

[Marcelo Ricardo Leitner]

On Mon, May 22, 2017 at 06:38:21PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Mon, 22 May 2017 17:28:14 +0200
> 
> Omit an extra message for a memory allocation failure in this function.
> 
> This issue was detected by using the Coccinelle software.
> 
> Link: 
> http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
> Signed-off-by: Markus Elfring 

Acked-by: Marcelo Ricardo Leitner 

> ---
>  net/sctp/protocol.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
> index 2b1a6215bd2f..5e7c8a344770 100644
> --- a/net/sctp/protocol.c
> +++ b/net/sctp/protocol.c
> @@ -1447,5 +1447,4 @@ static __init int sctp_init(void)
>   if (!sctp_ep_hashtable) {
> - pr_err("Failed endpoint_hash alloc\n");
>   status = -ENOMEM;
>   goto err_ehash_alloc;
>   }
> -- 
> 2.13.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [RFC PATCH v2 11/17] cgroup: Implement new thread mode semantics

[Waiman Long]

On 05/19/2017 04:26 PM, Tejun Heo wrote:
> Hello, Waiman.
>
> On Mon, May 15, 2017 at 09:34:10AM -0400, Waiman Long wrote:
>> Now we could have something like
>>
>>  R -- A -- B
>>   \
>>T1 -- T2
>>
>> where R is the thread root, A and B are non-threaded cgroups, T1 and
>> T2 are threaded cgroups. The cgroups R, T1, T2 form a threaded subtree
>> where all the non-threaded resources are accounted for in R.  The no
>> internal process constraint does not apply in the threaded subtree.
>> Non-threaded controllers need to properly handle the competition
>> between internal processes and child cgroups at the thread root.
>>
>> This model will be flexible enough to support the need of the threaded
>> controllers.
> Maybe I'm misunderstanding the design, but this seems to push the
> processes which belong to the threaded subtree to the parent which is
> part of the usual resource domain hierarchy thus breaking the no
> internal competition constraint.  I'm not sure this is something we'd
> want.  Given that the limitation of the original threaded mode was the
> required nesting below root and that we treat root special anyway
> (exactly in the way necessary), I wonder whether it'd be better to
> simply allow root to be both domain and thread root.

Yes, root can be both domain and thread root. I haven't placed any
restriction on that.

>
> Specific review points below but we'd probably want to discuss the
> overall design first.
>
>> +static inline bool cgroup_is_threaded(const struct cgroup *cgrp)
>> +{
>> +return cgrp->proc_cgrp && (cgrp->proc_cgrp != cgrp);
>> +}
>> +
>> +static inline bool cgroup_is_thread_root(const struct cgroup *cgrp)
>> +{
>> +return cgrp->proc_cgrp == cgrp;
>> +}
> Maybe add a bit of comments explaining what's going on with
> ->proc_cgrp?

Sure, will do that.

>>  /**
>> + * threaded_children_count - returns # of threaded children
>> + * @cgrp: cgroup to be tested
>> + *
>> + * cgroup_mutex must be held by the caller.
>> + */
>> +static int threaded_children_count(struct cgroup *cgrp)
>> +{
>> +struct cgroup *child;
>> +int count = 0;
>> +
>> +lockdep_assert_held(_mutex);
>> +cgroup_for_each_live_child(child, cgrp)
>> +if (cgroup_is_threaded(child))
>> +count++;
>> +return count;
>> +}
> It probably would be a good idea to keep track of the count so that we
> don't have to count them each time.  There are cases where people end
> up creating a very high number of cgroups and we've already been
> bitten a couple times with silly complexity issues.

Thanks for the suggestion, I can keep a count in the cgroup strcture to
avoid doing that repetitively.

>
>> @@ -2982,22 +3010,48 @@ static int cgroup_enable_threaded(struct cgroup 
>> *cgrp)
>>  LIST_HEAD(csets);
>>  struct cgrp_cset_link *link;
>>  struct css_set *cset, *cset_next;
>> +struct cgroup *child;
>>  int ret;
>> +u16 ss_mask;
>>  
>>  lockdep_assert_held(_mutex);
>>  
>>  /* noop if already threaded */
>> -if (cgrp->proc_cgrp)
>> +if (cgroup_is_threaded(cgrp))
>>  return 0;
>>  
>> -/* allow only if there are neither children or enabled controllers */
>> -if (css_has_online_children(>self) || cgrp->subtree_control)
>> +/*
>> + * Allow only if it is not the root and there are:
>> + * 1) no children,
>> + * 2) no non-threaded controllers are enabled, and
>> + * 3) no attached tasks.
>> + *
>> + * With no attached tasks, it is assumed that no css_sets will be
>> + * linked to the current cgroup. This may not be true if some dead
>> + * css_sets linger around due to task_struct leakage, for example.
>> + */
> It doesn't look like the code is actually making this (incorrect)
> assumption.  I suppose the comment is from before
> cgroup_is_populated() was added?

Yes, it is a bug. I should have checked the tasks_count instead of using
cgroup_is_populated. Thanks for catching that.

>
>>  spin_lock_irq(_set_lock);
>>  list_for_each_entry(link, >cset_links, cset_link) {
>>  cset = link->cset;
>> +if (cset->dead)
>> +continue;
> Hmm... is this a bug fix which is necessary regardless of whether we
> change the threadroot semantics or not?

That is true. I put it there because the the reference counting bug
fixed in patch 6 caused a lot of dead csets hanging around before the
fix. I can pull this out as a separate patch.

Cheers,
Longman

[RFC PATCH] fs: block dev aio request priority support

[adam.manzanares]

From: Adam Manzanares 

Map the aio_reqprio to the bio priority field at
the point the bio is created from the aio iocb.

The aio_reqprio field of iocb is used as a kernel IO class and priority
iff the IOCB_FLAG_IOPRIO flag is set on the iocb.

Late last year device IO priority support was introduced to reduce application
tail latency when iopriority information was set on the process [1]. This 
patch mapped iopriority information to block io requests. This information 
could be leveraged by device drivers to build device specific prioritized 
commands.

The iopriority is set on the iocontext which is a structure associated with 
a process. There exists a system call to set this iopriority information on 
a process, but I believe it would be useful to also have a mechanism to set 
priority on a per io command basis. 

The aio iocb has a field for the request priority which is currently not used 
within the kernel. This patch leverages this field to pass a per command 
iopriority value to devices. This work leverages the work in the previously 
referenced patch [1]. When the bio is generated from the iocb we copy the 
iocb iopriority information into the bio, which is eventually turned into a 
request which also gets a copy of the iopriority information. 

To demonstrate how to use this feature I modified fio to use the new aio 
feature. The modification to fio can be found at [2] and the new options 
are cmndprioclass and cmndprio.

[1] https://lkml.org/lkml/2016/12/6/495
[2] https://github.com/nmtadam/fio/tree/cmnd-prio.v2

Signed-off-by: Adam Manzanares 
---
 fs/aio.c | 9 +
 fs/block_dev.c   | 1 +
 include/linux/fs.h   | 1 +
 include/uapi/linux/aio_abi.h | 6 ++
 4 files changed, 17 insertions(+)

diff --git a/fs/aio.c b/fs/aio.c
index f52d925..a75a279 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -1568,6 +1568,15 @@ static int io_submit_one(struct kioctx *ctx, struct iocb 
__user *user_iocb,
req->common.ki_pos = iocb->aio_offset;
req->common.ki_complete = aio_complete;
req->common.ki_flags = iocb_flags(req->common.ki_filp);
+   if (iocb->aio_flags & IOCB_FLAG_IOPRIO)
+   /*
+* If the IOCB_FLAG_IOPRIO flag of aio_flags is set,
+* then the aio_reqprio is interpreted as a I/O
+* scheduling class and priority. This is then set
+* on the bio that is created from this request, which
+* enables the priority to be passed to device drivers.
+*/
+   req->common.ki_ioprio = iocb->aio_reqprio;
 
if (iocb->aio_flags & IOCB_FLAG_RESFD) {
/*
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 2eca00e..20d18db 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -360,6 +360,7 @@ __blkdev_direct_IO(struct kiocb *iocb, struct iov_iter 
*iter, int nr_pages)
bio->bi_iter.bi_sector = pos >> 9;
bio->bi_private = dio;
bio->bi_end_io = blkdev_bio_end_io;
+   bio->bi_ioprio = iocb->ki_ioprio;
 
ret = bio_iov_iter_get_pages(bio, iter);
if (unlikely(ret)) {
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 866c955..83135f0 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -276,6 +276,7 @@ struct kiocb {
void (*ki_complete)(struct kiocb *iocb, long ret, long ret2);
void*private;
int ki_flags;
+   u16 ki_ioprio; /* See linux/ioprio.h */
 };
 
 static inline bool is_sync_kiocb(struct kiocb *kiocb)
diff --git a/include/uapi/linux/aio_abi.h b/include/uapi/linux/aio_abi.h
index bb2554f..415980d 100644
--- a/include/uapi/linux/aio_abi.h
+++ b/include/uapi/linux/aio_abi.h
@@ -54,6 +54,12 @@ enum {
  */
 #define IOCB_FLAG_RESFD(1 << 0)
 
+/*
+ * IOCB_FLAG_IOPRIO - Set if the "aio_reqprio" member of the "struct iocb"
+ *is interpreted as an I/O scheduling class and priority
+ */
+#define IOCB_FLAG_IOPRIO   (1 << 1)
+
 /* read() from /dev/aio returns these structures. */
 struct io_event {
__u64   data;   /* the data field from the iocb */
-- 
2.7.4

Re: [PATCH] coresight: tmc: Configure DMA mask appropriately

[Mathieu Poirier]

On 18 May 2017 at 09:14, Robin Murphy  wrote:
> Before making any DMA API calls, the ETR driver should really be setting
> its masks to ensure that DMA is possible. Especially since it can
> address more than the 32-bit default mask set by the AMBA bus code.
>
> Signed-off-by: Robin Murphy 
> ---
>  drivers/hwtracing/coresight/coresight-tmc.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/drivers/hwtracing/coresight/coresight-tmc.c 
> b/drivers/hwtracing/coresight/coresight-tmc.c
> index d8517d2a968c..864488793f09 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc.c
> @@ -362,6 +362,13 @@ static int tmc_probe(struct amba_device *adev, const 
> struct amba_id *id)
> desc.type = CORESIGHT_DEV_TYPE_SINK;
> desc.subtype.sink_subtype = CORESIGHT_DEV_SUBTYPE_SINK_BUFFER;
> desc.ops = _etr_cs_ops;
> +   /*
> +* ETR configuration uses a 40-bit AXI master in place of
> +* the embedded SRAM of ETB/ETF.
> +*/
> +   ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(40));
> +   if (ret)
> +   goto out;
> } else {
> desc.type = CORESIGHT_DEV_TYPE_LINKSINK;
> desc.subtype.link_subtype = CORESIGHT_DEV_SUBTYPE_LINK_FIFO;

Applied - thanks.
Mathieu

> --
> 2.12.2.dirty
>

Re: [PATCH v2 02/18] mfd: madera: Add common support for Cirrus Logic Madera codecs

[Lee Jones]

On Mon, 24 Apr 2017, Richard Fitzgerald wrote:

> This adds the generic core support for Cirrus Logic "Madera" class codecs.
> These are complex audio codec SoCs with a variety of digital and analogue
> I/O, onboard audio processing and DSPs, and other features.
> 
> These codecs are all based off a common set of hardware IP so can be
> supported by a core of common code (with a few minor device-to-device
> variations).
> 
> 
> Signed-off-by: Charles Keepax 
> Signed-off-by: Nikesh Oswal 
> Signed-off-by: Richard Fitzgerald 
> ---
> Changes since V1:
> - Moved dt binding into separate patch
> - Fixed some errors with Kconfig options and select MADERA_IRQ directly
>   from MFD
> - Added custom parent supply information, mainly for re-using the Arizona
>   regulators (which don't have their own DT node)
> - re-ordered the error test and debug print in madera_wait_for_boot()
> - re-worked the initialization of the reset gpio configuration from probe
> - renamed madera_of_get_type() to madera_get_type_from_of() to make its
>   purpose clearer
> - removed reading of MICBIAS configuration
> - ordered includes alphabetically
> - added a header comment that struct madera is internal
> - fixed pdata comments to be kerneldoc format
> 
>  MAINTAINERS  |   3 +
>  drivers/mfd/Kconfig  |  29 ++
>  drivers/mfd/Makefile |   4 +
>  drivers/mfd/madera-core.c| 635 
> +++
>  drivers/mfd/madera-i2c.c | 131 
>  drivers/mfd/madera-spi.c | 132 
>  drivers/mfd/madera.h |  52 
>  include/linux/mfd/madera/core.h  | 180 +++
>  include/linux/mfd/madera/pdata.h |  61 
>  9 files changed, 1227 insertions(+)
>  create mode 100644 drivers/mfd/madera-core.c
>  create mode 100644 drivers/mfd/madera-i2c.c
>  create mode 100644 drivers/mfd/madera-spi.c
>  create mode 100644 drivers/mfd/madera.h
>  create mode 100644 include/linux/mfd/madera/core.h
>  create mode 100644 include/linux/mfd/madera/pdata.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4e07159..4a01a2a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3304,7 +3304,10 @@ L: patc...@opensource.wolfsonmicro.com
>  T:   git https://github.com/CirrusLogic/linux-drivers.git
>  W:   https://github.com/CirrusLogic/linux-drivers/wiki
>  S:   Supported
> +F:   Documentation/devicetree/bindings/mfd/madera.txt
>  F:   include/linux/mfd/madera/*
> +F:   drivers/mfd/madera*
> +F:   drivers/mfd/cs47l*
>  
>  CLEANCACHE API
>  M:   Konrad Rzeszutek Wilk 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 3eb5c93..8128aaa 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -203,6 +203,35 @@ config MFD_CROS_EC_SPI
> response time cannot be guaranteed, we support ignoring
> 'pre-amble' bytes before the response actually starts.
>  
> +config MFD_MADERA
> + bool
> +
> +config MFD_MADERA_I2C
> + bool "Cirrus Logic Madera codecs with I2C"
> + select REGMAP
> + select REGMAP_IRQ
> + select MFD_CORE
> + select REGMAP_I2C
> + select MFD_MADERA
> + select MADERA_IRQ
> + depends on I2C
> + help
> +   Support for the Cirrus Logic Madera platform audio SoC
> +   core functionality controlled via I2C.
> +
> +config MFD_MADERA_SPI
> + bool "Cirrus Logic Madera codecs with SPI"
> + select REGMAP
> + select REGMAP_IRQ
> + select MFD_CORE
> + select REGMAP_SPI
> + select MFD_MADERA
> + select MADERA_IRQ
> + depends on SPI_MASTER

Suggest that you move all duplicates/common selects to MFD_MADERA.

And reorder them logically.

> + help
> +   Support for the Cirrus Logic Madera platform audio SoC
> +   core functionality controlled via SPI.
> +
>  config MFD_ASIC3
>   bool "Compaq ASIC3"
>   depends on GPIOLIB && ARM
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index c16bf1e..38b1514 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -72,6 +72,10 @@ obj-$(CONFIG_MFD_WM8350_I2C)   += wm8350-i2c.o
>  wm8994-objs  := wm8994-core.o wm8994-irq.o wm8994-regmap.o
>  obj-$(CONFIG_MFD_WM8994) += wm8994.o
>  
> +obj-$(CONFIG_MFD_MADERA) += madera-core.o
> +obj-$(CONFIG_MFD_MADERA_I2C) += madera-i2c.o
> +obj-$(CONFIG_MFD_MADERA_SPI) += madera-spi.o
> +
>  obj-$(CONFIG_TPS6105X)   += tps6105x.o
>  obj-$(CONFIG_TPS65010)   += tps65010.o
>  obj-$(CONFIG_TPS6507X)   += tps6507x.o
> diff --git a/drivers/mfd/madera-core.c b/drivers/mfd/madera-core.c
> new file mode 100644
> index 000..bed018d
> --- /dev/null
> +++ b/drivers/mfd/madera-core.c
> @@ -0,0 +1,635 @@
> +/*
> + * Core MFD support for Cirrus Logic Madera codecs
> + *
> + * Copyright 2015-2017 Cirrus Logic
> + *
> + * This program is free software; 

Re: [PATCH v2 1/2] mfd: intel_quark_i2c_gpio: Use dmi_system_id table for retrieving frequency

[Jan Kiszka]

On 2017-05-22 19:36, Andy Shevchenko wrote:
> On Mon, May 22, 2017 at 8:34 PM, Jan Kiszka  wrote:
>> On 2017-05-22 19:26, Andy Shevchenko wrote:
>>> On Mon, May 22, 2017 at 8:25 PM, Jan Kiszka  wrote:
 On 2017-05-22 19:20, Andy Shevchenko wrote:
> On Mon, May 22, 2017 at 8:18 PM, Jan Kiszka  
> wrote:
>> On 2017-05-22 19:12, Andy Shevchenko wrote:
>>> On Mon, May 22, 2017 at 1:53 PM, Jan Kiszka  
>>> wrote:
> 
> And since there is no difference to the frequency the name is enough.
> So, I wouldn't go with this series as is. See above.

 Nope: Just like for the stmmac, we need to include the asset tags to
 avoid matching variations of the devices which may carry the same board
 name. While I will try to avoid that this happens, we are better safe
 than sorry here.
>>>
>>> Do we have an issue right now?
>>> Yes / No
>>
>> Andy, we are trying to design a robust upstream driver here, no ad-hoc
>> BSP that will not survive the hardware anyway.
> 
> You didn't answer my question...
> 
> I do not see a good point to solve the issue that might happen in the future.
> 

While I do - that's why your question is misleading.

Then let's leave the decision up to the maintainer.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

[PATCH] dt-bindings: Drop k2g genpd device ID macros

[Dave Gerlach]

Commit 7cc119f29b19 ("dt-bindings: Add TI SCI PM Domains") introduced a
number of K2G_DEV_x macros to represent each device ID available on the
K2G platform for use by the genpd, clock, and reset drivers. Rather than
use these macros, which are only used in the device tree for property
values and not actually used by the drivers, let's just use the device
ID number directly in the device tree to avoid macro bloat.

Signed-off-by: Dave Gerlach 
---
Based on discussion here [1] it was agreed that these macros are not needed
and it is better to just use the device IDs directly in dt.

[1] https://www.spinics.net/lists/arm-kernel/msg577079.html

 .../devicetree/bindings/soc/ti/sci-pm-domain.txt   |  5 +-
 include/dt-bindings/genpd/k2g.h| 90 --
 2 files changed, 3 insertions(+), 92 deletions(-)
 delete mode 100644 include/dt-bindings/genpd/k2g.h

diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt 
b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
index c705db07d820..66e6265fb0aa 100644
--- a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
+++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
@@ -46,12 +46,13 @@ Required Properties:
 - power-domains: phandle pointing to the corresponding PM domain node
 and an ID representing the device.
 
-See dt-bindings/genpd/k2g.h for the list of valid identifiers for k2g.
+See http://processors.wiki.ti.com/index.php/TISCI#66AK2G02_Data for the list
+of valid identifiers for k2g.
 
 Example (K2G):
 
uart0: serial@02530c00 {
compatible = "ns16550a";
...
-   power-domains = <_pds K2G_DEV_UART0>;
+   power-domains = <_pds 0x002c>;
};
diff --git a/include/dt-bindings/genpd/k2g.h b/include/dt-bindings/genpd/k2g.h
deleted file mode 100644
index 1f31f17e19eb..
--- a/include/dt-bindings/genpd/k2g.h
+++ /dev/null
@@ -1,90 +0,0 @@
-/*
- * TI K2G SoC Device definitions
- *
- * Copyright (C) 2015-2017 Texas Instruments Incorporated - http://www.ti.com/
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- */
-
-#ifndef _DT_BINDINGS_GENPD_K2G_H
-#define _DT_BINDINGS_GENPD_K2G_H
-
-/* Documented in http://processors.wiki.ti.com/index.php/TISCI */
-
-#define K2G_DEV_PMMC0  0x
-#define K2G_DEV_MLB0   0x0001
-#define K2G_DEV_DSS0   0x0002
-#define K2G_DEV_MCBSP0 0x0003
-#define K2G_DEV_MCASP0 0x0004
-#define K2G_DEV_MCASP1 0x0005
-#define K2G_DEV_MCASP2 0x0006
-#define K2G_DEV_DCAN0  0x0008
-#define K2G_DEV_DCAN1  0x0009
-#define K2G_DEV_EMIF0  0x000a
-#define K2G_DEV_MMCHS0 0x000b
-#define K2G_DEV_MMCHS1 0x000c
-#define K2G_DEV_GPMC0  0x000d
-#define K2G_DEV_ELM0   0x000e
-#define K2G_DEV_SPI0   0x0010
-#define K2G_DEV_SPI1   0x0011
-#define K2G_DEV_SPI2   0x0012
-#define K2G_DEV_SPI3   0x0013
-#define K2G_DEV_ICSS0  0x0014
-#define K2G_DEV_ICSS1  0x0015
-#define K2G_DEV_USB0   0x0016
-#define K2G_DEV_USB1   0x0017
-#define K2G_DEV_NSS0   0x0018
-#define K2G_DEV_PCIE0  0x0019
-#define K2G_DEV_GPIO0  0x001b
-#define K2G_DEV_GPIO1  0x001c
-#define K2G_DEV_TIMER64_0  0x001d
-#define K2G_DEV_TIMER64_1  0x001e
-#define K2G_DEV_TIMER64_2  0x001f
-#define K2G_DEV_TIMER64_3  0x0020
-#define K2G_DEV_TIMER64_4  0x0021
-#define K2G_DEV_TIMER64_5  0x0022
-#define K2G_DEV_TIMER64_6  0x0023
-#define K2G_DEV_MSGMGR00x0025
-#define K2G_DEV_BOOTCFG0   0x0026
-#define K2G_DEV_ARM_BOOTROM0   0x0027
-#define K2G_DEV_DSP_BOOTROM0   0x0029
-#define K2G_DEV_DEBUGSS0   0x002b
-#define K2G_DEV_UART0  0x002c
-#define K2G_DEV_UART1  0x002d
-#define K2G_DEV_UART2  0x002e
-#define K2G_DEV_EHRPWM00x002f
-#define K2G_DEV_EHRPWM10x0030
-#define K2G_DEV_EHRPWM20x0031
-#define K2G_DEV_EHRPWM30x0032
-#define K2G_DEV_EHRPWM4   

Re: [PATCH v2 1/2] mfd: intel_quark_i2c_gpio: Use dmi_system_id table for retrieving frequency

[Andy Shevchenko]

On Mon, May 22, 2017 at 9:23 PM, Lee Jones  wrote:
> On Mon, 22 May 2017, Andy Shevchenko wrote:
>> On Mon, May 22, 2017 at 8:38 PM, Jan Kiszka  wrote:
>> > On 2017-05-22 19:36, Andy Shevchenko wrote:

>> > Then let's leave the decision up to the maintainer.
>>
>> Lee, just for your convenience I'm repeating myself here:
>>
>> I do not like this series at all since it tries to solve non-existing
>> issue in over-engineering way.
>>
>> If you on opposite side I will be happy to help reviewing it.
>
> New code looks cleaner and appears to use an already defined API.

Got your point.
Jan, care to resend  (an updated?) version?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 02/24] thunderbolt: Do not try to read UID if DROM offset is read as 0

[Andreas Noever]

On Mon, May 22, 2017 at 10:40 AM, Mika Westerberg
 wrote:
> On Sun, May 21, 2017 at 03:46:20PM +0200, Andreas Noever wrote:
>> On Thu, May 18, 2017 at 4:38 PM, Mika Westerberg
>>  wrote:
>> > At least Falcon Ridge when in host mode does not have any kind of DROM
>> > available and reading DROM offset returns 0 for these. Do not try to
>> > read DROM any further in that case.
>> >
>> > Signed-off-by: Mika Westerberg 
>> > Reviewed-by: Yehezkel Bernat 
>> > Reviewed-by: Michael Jamet 
>> > ---
>> >  drivers/thunderbolt/eeprom.c | 3 +++
>> >  1 file changed, 3 insertions(+)
>> >
>>
>> Hi Mika,
>>
>> nice work, it is nice to see Intel contribute to the Thunderbolt
>> driver (I can second Lukas's 'jaw drop' comment)!
>>
>> I will try to read through everything today, but maybe the last few
>> patches will get pushed back to next weekend.
>
> Thanks :)
>
>> > diff --git a/drivers/thunderbolt/eeprom.c b/drivers/thunderbolt/eeprom.c
>> > index 6392990c984d..e4e64b130514 100644
>> > --- a/drivers/thunderbolt/eeprom.c
>> > +++ b/drivers/thunderbolt/eeprom.c
>> > @@ -276,6 +276,9 @@ int tb_drom_read_uid_only(struct tb_switch *sw, u64 
>> > *uid)
>> > if (res)
>> > return res;
>> >
>> > +   if (drom_offset == 0)
>> > +   return -ENODEV;
>> > +
>> I think that this will make tb_switch_resume bail out on the root
>> switch, which is not good. Since the uid is only used to detect
>> whether a different device was plugged in while the system was
>> suspended I think that we can safely ignore the uid on the root
>> switch:
>>  - don't read it in tb_drom_read (route == 0 is already special cased 
>> anyways)
>>  - add a special case for the root switch to tb_switch_resume and
>> don't read the uid - just assume that it did not change (should be
>> impossible anyways)
>>
>> What do you think?
>
> I think there actually is such check already in tb_switch_resume() where
> we special case the root switch ignoring its UID. Unless I'm missing
> something.
>
> I'm testing this on a Mac with Cactus Ridge and the root switch resume
> does not fail :)

Yes there is a check for the root switch, but also one that checks the
return code of tb_drom_read_uid_only :)

err = tb_drom_read_uid_only(sw, );
if (err) {
tb_sw_warn(sw, "uid read failed\n");
return err;
}
if (sw != sw->tb->root_switch && sw->uid != uid) {


The reason it works on the Mac is because drom_offset is not 0, so the
new branch in tb_drom_read_uid_only is not taken. Probably this is the
case for all Cactus Ridge models and Alpine Ridge doesn't go there
since it uses the ICM? Still it wouldn't hurt to only read the uid if
sw != root_switch, the value is not used if sw == root_switch.

Re: [tip:x86/platform 1/1] platform_bt.c:undefined reference to `gpiod_add_lookup_table'

[Andy Shevchenko]

On Mon, 2017-04-03 at 07:23 +0800, kbuild test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> x86/platform
> head:   d4d969909bef4c1e103eec0fc2c820773811fb72
> commit: d4d969909bef4c1e103eec0fc2c820773811fb72 [1/1]
> x86/platform/intel-mid: Enable Bluetooth support on Intel Edison
> config: x86_64-randconfig-s4-04030434 (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> git checkout d4d969909bef4c1e103eec0fc2c820773811fb72
> # save the attached .config to linux build tree
> make ARCH=x86_64 
> 
> All errors (new ones prefixed by >>):
> 
>    arch/x86/built-in.o: In function `tng_bt_sfi_setup':
> > > platform_bt.c:(.init.text+0x13a30): undefined reference to
> > > `gpiod_add_lookup_table'
> 
> 

This is going to be fixed by
https://lkml.org/lkml/2017/5/11/774
when Linus applies the patch.

> ---
> 0-DAY kernel test infrastructureOpen Source Technology
> Center
> https://lists.01.org/pipermail/kbuild-all   Intel
> Corporation

-- 
Andy Shevchenko 
Intel Finland Oy

Re: [PATCH v2 1/2] mfd: intel_quark_i2c_gpio: Use dmi_system_id table for retrieving frequency

[Jan Kiszka]

On 2017-05-22 20:37, Andy Shevchenko wrote:
> On Mon, May 22, 2017 at 9:23 PM, Lee Jones  wrote:
>> On Mon, 22 May 2017, Andy Shevchenko wrote:
>>> On Mon, May 22, 2017 at 8:38 PM, Jan Kiszka  wrote:
 On 2017-05-22 19:36, Andy Shevchenko wrote:
> 
 Then let's leave the decision up to the maintainer.
>>>
>>> Lee, just for your convenience I'm repeating myself here:
>>>
>>> I do not like this series at all since it tries to solve non-existing
>>> issue in over-engineering way.
>>>
>>> If you on opposite side I will be happy to help reviewing it.
>>
>> New code looks cleaner and appears to use an already defined API.
> 
> Got your point.
> Jan, care to resend  (an updated?) version?
> 

Updated in which regard? The one for stmmac is broken, this one should
be fine.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH v4 15/27] fs: retrofit old error reporting API onto new infrastructure

[Jeff Layton]

On Mon, 2017-05-22 at 19:53 +0200, Jan Kara wrote:
> On Mon 22-05-17 09:53:21, Jeff Layton wrote:
> > On Mon, 2017-05-22 at 15:38 +0200, Jan Kara wrote:
> > > On Fri 19-05-17 15:20:52, Jeff Layton wrote:
> > > > On Mon, 2017-05-15 at 12:42 +0200, Jan Kara wrote:
> > > > > On Tue 09-05-17 11:49:18, Jeff Layton wrote:
> > > > > > Now that we have a better way to store and report errors that occur
> > > > > > during writeback, we need to convert the existing codebase to use 
> > > > > > it. We
> > > > > > could just adapt all of the filesystem code and related 
> > > > > > infrastructure
> > > > > > to the new API, but that's a lot of churn.
> > > > > > 
> > > > > > When it comes to setting errors in the mapping, 
> > > > > > filemap_set_wb_error is
> > > > > > a drop-in replacement for mapping_set_error. Turn that function 
> > > > > > into a
> > > > > > simple wrapper around the new one.
> > > > > > 
> > > > > > Because we want to ensure that writeback errors are always reported 
> > > > > > at
> > > > > > fsync time, inject filemap_report_wb_error calls much closer to the
> > > > > > syscall boundary, in call_fsync.
> > > > > > 
> > > > > > For fsync calls (and things like the nfsd equivalent), we either 
> > > > > > return
> > > > > > the error that the fsync operation returns, or the one returned by
> > > > > > filemap_report_wb_error. In both cases, we advance the 
> > > > > > file->f_wb_err to
> > > > > > the latest value. This allows us to provide new fsync semantics that
> > > > > > will return errors that may have occurred previously and been viewed
> > > > > > via other file descriptors.
> > > > > > 
> > > > > > The final piece of the puzzle is what to do about 
> > > > > > filemap_check_errors
> > > > > > calls that are being called directly or via filemap_* functions. 
> > > > > > Here,
> > > > > > we must take a little "creative license".
> > > > > > 
> > > > > > Since we now handle advancing the file->f_wb_err value at the 
> > > > > > generic
> > > > > > filesystem layer, we no longer need those callers to clear errors 
> > > > > > out
> > > > > > of the mapping or advance an errseq_t.
> > > > > > 
> > > > > > A lot of the existing codebase relies on being getting an error back
> > > > > > from those functions when there is a writeback problem, so we do 
> > > > > > still
> > > > > > want to have them report writeback errors somehow.
> > > > > > 
> > > > > > When reporting writeback errors, we will always report errors that 
> > > > > > have
> > > > > > occurred since a particular point in time. With the old writeback 
> > > > > > error
> > > > > > reporting, the time we used was "since it was last tested/cleared" 
> > > > > > which
> > > > > > is entirely arbitrary and potentially racy. Now, we can at least 
> > > > > > report
> > > > > > the latest error that has occurred since an arbitrary point in time
> > > > > > (represented as a sampled errseq_t value).
> > > > > > 
> > > > > > In the case where we don't have a struct file to work with, this 
> > > > > > patch
> > > > > > just has the wrappers sample the current mapping->wb_err value, and 
> > > > > > use
> > > > > > that as an arbitrary point from which to check for errors.
> > > > > 
> > > > > I think this is really dangerous and we shouldn't do this. You are 
> > > > > quite
> > > > > likely to lose IO errors in such calls because you will ignore all 
> > > > > errors
> > > > > that happened during previous background writeback or even for IO that
> > > > > managed to complete before we called filemap_fdatawait(). Maybe we 
> > > > > need to
> > > > > keep the original set-clear-bit IO error reporting for these cases, 
> > > > > until
> > > > > we can convert them to fdatawait_range_since()?
> > > > > 
> > > > > > That's probably not "correct" in all cases, particularly in the 
> > > > > > case of
> > > > > > something like filemap_fdatawait, but I'm not sure it's any worse 
> > > > > > than
> > > > > > what we already have, and this gives us a basis from which to work.
> > > > > > 
> > > > > > A lot of those callers will likely want to change to a model where 
> > > > > > they
> > > > > > sample the errseq_t much earlier (perhaps when starting a 
> > > > > > transaction),
> > > > > > store it in an appropriate place and then use that value later when
> > > > > > checking to see if an error occurred.
> > > > > > 
> > > > > > That will almost certainly take some involvement from other 
> > > > > > subsystem
> > > > > > maintainers. I'm quite open to adding new API functions to help 
> > > > > > enable
> > > > > > this if that would be helpful, but I don't really want to do that 
> > > > > > until
> > > > > > I better understand what's needed.
> > > > > > 
> > > > > > Signed-off-by: Jeff Layton 
> > > > > 
> > > > > ...
> > > > > 
> > > > > > diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> > > > > > index 5f7317875a67..7ce13281925f 100644
> > > > > > --- a/fs/f2fs/file.c
> > > > > > +++ b/fs/f2fs/file.c
> > > > > > 

Re: [PATCH v1] ACPI: Switch to use generic UUID API

[Andy Shevchenko]

On Thu, 2017-05-04 at 12:21 +0300, Andy Shevchenko wrote:
> acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
> bytes. Instead we convert them to use uuid_le type. At the same time
> we
> convert current users.
> 
> acpi_str_to_uuid() becomes useless after the conversion and it's safe
> to
> get rid of it.
> 
> The conversion fixes a potential bug in int340x_thermal as well since
> we have to use memcmp() on binary data.
> 
> Cc: Rafael J. Wysocki 
> Cc: Mika Westerberg 
> Cc: Borislav Petkov 
> Cc: Dan Williams 
> Cc: Amir Goldstein 
> Cc: Jarkko Sakkinen 
> Cc: Jani Nikula 
> Cc: Ben Skeggs 
> Cc: Benjamin Tissoires 
> Cc: Joerg Roedel 
> Cc: Adrian Hunter 
> Cc: Yisen Zhuang 
> Cc: Bjorn Helgaas 
> Cc: Zhang Rui 
> Cc: Felipe Balbi 
> Cc: Mathias Nyman 
> Cc: Heikki Krogerus 
> Cc: Liam Girdwood 
> Cc: Mark Brown 
> Signed-off-by: Andy Shevchenko 

Thank you everyone who gave a tag to this.

I'm going to split and rebase on top of Christoph's branch
http://git.infradead.org/users/hch/vfs.git/shortlog/refs/heads/uuid-type
s

followed by changing types and API calls accordingly (without changing a
logic!).

So, I would like to keep tags in place. If there is any objection, speak
up now!
 
Thanks!

-- 
Andy Shevchenko 
Intel Finland Oy

Re: [PATCH 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter

[Peter Zijlstra]

On Mon, May 22, 2017 at 04:55:47PM +, Liang, Kan wrote:
> 
> 
> > On Fri, May 19, 2017 at 10:06:21AM -0700, kan.li...@intel.com wrote:
> > > diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index
> > > 580b60f..e8b2326 100644
> > > --- a/arch/x86/events/core.c
> > > +++ b/arch/x86/events/core.c
> > > @@ -101,6 +101,10 @@ u64 x86_perf_event_update(struct perf_event
> > *event)
> > >   delta = (new_raw_count << shift) - (prev_raw_count << shift);
> > >   delta >>= shift;
> > >
> > > + /* Correct the count number if applying ref_cycles replacement */
> > > + if (!is_sampling_event(event) &&
> > > + (hwc->flags & PERF_X86_EVENT_REF_CYCLES_REP))
> > > + delta *= x86_pmu.ref_cycles_factor;
> > 
> > That condition seems wrong, why only correct for !sampling events?
> >
> 
> For sampling, it's either fixed freq mode or fixed period mode.
>  - In the fixed freq mode, we should do nothing, because the adaptive
>frequency algorithm will handle it.
>  - In the fixed period mode, we have already adjusted the period in 
> ref_cycles_rep().
> Therefore, we should only handle !sampling events here.

How so? For sampling events the actual event count should also be
accurate.

Re: [PATCH 1/3] RDS: IB: Delete an error message for a failed memory allocation in rds_ib_add_one()

[Santosh Shilimkar]

On 5/22/2017 7:11 AM, SF Markus Elfring wrote:

From: Markus Elfring 
Date: Mon, 22 May 2017 15:34:28 +0200

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

This issue was detected by using the Coccinelle software.

Link: 
http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring 
---
  net/rds/ib.c | 5 +
  1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/net/rds/ib.c b/net/rds/ib.c
index 7a64c8db81ab..c5514d058171 100644
--- a/net/rds/ib.c
+++ b/net/rds/ib.c
@@ -166,8 +166,5 @@ static void rds_ib_add_one(struct ib_device *device)
-   if (!rds_ibdev->vector_load) {
-   pr_err("RDS/IB: %s failed to allocate vector memory\n",
-   __func__);
+   if (!rds_ibdev->vector_load)
goto put_dev;
-   }
  

Well the ENOMEM is not carried here so the message was usefu
but its not critical so its fine to clean that up.

Acked-by: Santosh Shilimkar 

Re: [PATCH net-next 02/20] net: dsa: change scope of notifier call chain

[Florian Fainelli]

On 05/19/2017 02:00 PM, Vivien Didelot wrote:
> Change the scope of the fabric notification helper from the DSA slave to
> the DSA port, since this is a DSA layer specific notion, that can be
> used by non-slave ports (CPU and DSA).
> 
> Signed-off-by: Vivien Didelot 

Reviewed-by: Florian Fainelli 
-- 
Florian

Re: [PATCH v5 0/3] watchdog: allow setting deadline for opening /dev/watchdogN

[Guenter Roeck]

On Mon, May 22, 2017 at 07:07:51PM +0100, Alan Cox wrote:
> On Mon, 22 May 2017 16:06:36 +0200
> Rasmus Villemoes  wrote:
> 
> > If a watchdog driver tells the framework that the device is running,
> > the framework takes care of feeding the watchdog until userspace opens
> > the device. If the userspace application which is supposed to do that
> > never comes up properly, the watchdog is fed indefinitely by the
> > kernel. This can be especially problematic for embedded devices.
> > 
> > These patches allow one to set a maximum time for which the kernel
> > will feed the watchdog, thus ensuring that either userspace has come
> > up, or the board gets reset. This allows fallback logic in the
> > bootloader to attempt some recovery (for example, if an automatic
> > update is in progress, it could roll back to the previous version).
> 
> 
> This makes sense except for being a CONFIG_ option not a boot parameter.
> If it's a boot parameter then the same kernel works for multiple systems
> and is general. If it's compile time then you have to build a custom
> kernel.
> 
> For some embedded stuff that might not matter (although I bet they'd
> prefer it command line/device tree too) but for something like an x86
> platform where you are deploying a standard vendor supplied kernel it's
> bad to do it that way IMHO.
> 
> In other words I think you should drop patch 3 but the rest is good.
> 

Same here. Can we assume a formal Reviewed-by: from you for the first two
patches ?

Thanks,
Guenter

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

Re: [PATCH 2/2] dax: Fix race between colliding PMD & PTE entries

[Ross Zwisler]

On Mon, May 22, 2017 at 04:37:48PM +0200, Jan Kara wrote:
> On Thu 18-05-17 15:29:39, Ross Zwisler wrote:
> > On Thu, May 18, 2017 at 09:50:37AM +0200, Jan Kara wrote:
> > > On Wed 17-05-17 11:16:39, Ross Zwisler wrote:
<>
> > > The first scenario seems to be possible. dax_iomap_pmd_fault() will create
> > > PMD entry in the radix tree. Then dax_iomap_pte_fault() will come, do
> > > grab_mapping_entry(), there it sees entry is PMD but we are doing PTE 
> > > fault
> > > so I'd think that pmd_downgrade = true... But actually the condition there
> > > doesn't trigger in this case. And that's a catch that although we asked
> > > grab_mapping_entry() for PTE, we've got PMD back and that screws us later.
> > 
> > Yep, it was a concious decision when implementing the PMD support to allow 
> > one
> > thread to use PMDs and another to use PTEs in the same range, as long as the
> > thread faulting in PMDs is the first to insert into the radix tree.  A PMD
> > radix tree entry will be inserted and used for locking and dirty tracking, 
> > and
> > each thread or process can fault in either PTEs or PMDs into its own address
> > space as needed.
> 
> Well, for *threads* it doesn't really make good sense to mix PMDs and PTEs
> as they share page tables. However for *processes* it makes some sense to
> allow one process to use PTEs and another process to use PMDs. And I
> remember we were discussing this in the past.

Ugh, I was super sloppy with my use of "thread" and "process" in my previous
email.  Sorry, and thanks for the clarifications.  I think we're on the same
page, even if I had trouble articulating it. :)

> So normal fault path uses alloc_set_pte() for installing new PTE. And that
> uses pte_alloc_one_map() which checks whether PMD is still suitable for
> inserting a PTE. If not, we return VM_FAULT_NOPAGE. Probably it would be
> cleanest to factor our common parts of PTE and PMD insertion so that we can
> use these functions both from DAX and generic fault paths.

Makes sense, thanks.

Re: [PATCH 1/5] sctp: Use kmalloc_array() in sctp_init()

[Marcelo Ricardo Leitner]

On Mon, May 22, 2017 at 06:37:19PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Mon, 22 May 2017 17:20:11 +0200
> 
> * A multiplication for the size determination of a memory allocation
>   indicated that an array data structure should be processed.
>   Thus use the corresponding function "kmalloc_array".
> 
>   This issue was detected by using the Coccinelle software.
> 
> * Replace the specification of a data structure by a pointer dereference
>   to make the corresponding size determination a bit safer according to
>   the Linux coding style convention.
> 
> Signed-off-by: Markus Elfring 

Acked-by: Marcelo Ricardo Leitner 

> ---
>  net/sctp/protocol.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
> index 989a900383b5..2b1a6215bd2f 100644
> --- a/net/sctp/protocol.c
> +++ b/net/sctp/protocol.c
> @@ -1442,6 +1442,6 @@ static __init int sctp_init(void)
>  
>   /* Allocate and initialize the endpoint hash table.  */
>   sctp_ep_hashsize = 64;
> - sctp_ep_hashtable =
> - kmalloc(64 * sizeof(struct sctp_hashbucket), GFP_KERNEL);
> + sctp_ep_hashtable = kmalloc_array(64, sizeof(*sctp_ep_hashtable),
> +   GFP_KERNEL);
>   if (!sctp_ep_hashtable) {
> -- 
> 2.13.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH] LSM: Make security_hook_heads a local variable.

[Igor Stoppa]

On 22/05/17 18:09, Casey Schaufler wrote:
> On 5/22/2017 7:03 AM, Christoph Hellwig wrote:

[...]

>> But even with those we can still chain
>> them together with a list with external linkage.
> 
> I gave up that approach in 2012. Too many unnecessary calls to
> null functions, and massive function vectors with a tiny number
> of non-null entries. From a data structure standpoint, it was
> just wrong. The list scheme is exactly right for the task at
> hand.

I understand this as a green light, for me to continue with the plan of
using LSM Hooks as example for making dynamically allocated data become
read-only, using also Tetsuo's patch (thanks, btw).

Is that correct?

---
thanks, igor

Re: [PATCH V3 1/2] sched/fair: Fix load_balance() affinity redo path

[Christ, Austin]

Hey Dietmar,


On 5/22/2017 3:48 AM, Dietmar Eggemann wrote:

On 19/05/17 14:31, Dietmar Eggemann wrote:

On 18/05/17 20:36, Jeffrey Hugo wrote:

[...]


diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index d711093..a5d41b1 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -8220,7 +8220,24 @@ static int load_balance(int this_cpu, struct rq *this_rq,
/* All tasks on this runqueue were pinned by CPU affinity */
if (unlikely(env.flags & LBF_ALL_PINNED)) {
cpumask_clear_cpu(cpu_of(busiest), cpus);
-   if (!cpumask_empty(cpus)) {
+   /*
+* dst_cpu is not a valid busiest cpu in the following
+* check since load cannot be pulled from dst_cpu to be
+* put on dst_cpu.
+*/
+   cpumask_clear_cpu(env.dst_cpu, cpus);
+   /*
+* Go back to "redo" iff the load-balance cpumask
+* contains other potential busiest cpus for the
+* current sched domain.
+*/
+   if (cpumask_intersects(cpus, 
sched_domain_span(env.sd))) {
+   /*
+* Now that the check has passed, reenable
+* dst_cpu so that load can be calculated on
+* it in the redo path.
+*/
+   cpumask_set_cpu(env.dst_cpu, cpus);

IMHO, this will work nicely and its way easier.

This was too quick ... if we still have other potential dst cpus
available and cpu_of(busiest) is the latest src cpu then this will fail.

It does work on sd with 'group_weight == 1', e.g. your MC sd 'sd->child
== NULL'.

But IMHO 'group_imbalance' propagation has to work on higher sd levels
as well.
Can you clarify the fail case you are seeing? We are only aware of 
dst_cpu being changed under [1] where a dst_cpu will try to move work to 
one of its sched_group siblings.


I'm also not entirely sure I understand what you mean about the flag 
being propagated to higher sd levels.

Another idea might be to check if the LBF_ALL_PINNED is set when we
check if we should clean the imbalance flag.

@@ -8307,14 +8307,13 @@ static int load_balance(int this_cpu, struct rq 
*this_rq,
  * We reach balance although we may have faced some affinity
  * constraints. Clear the imbalance flag if it was set.
  */
-   if (sd_parent) {
+   if (sd_parent && !(env.flags & LBF_ALL_PINNED)) {
 int *group_imbalance = _parent->groups->sgc->imbalance;

 if (*group_imbalance)
 *group_imbalance = 0;
 }

[...]


[1] - 
http://elixir.free-electrons.com/linux/latest/source/kernel/sched/fair.c#L8140


--
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH v2 1/2] mfd: intel_quark_i2c_gpio: Use dmi_system_id table for retrieving frequency

[Jan Kiszka]

On 2017-05-22 19:12, Andy Shevchenko wrote:
> On Mon, May 22, 2017 at 1:53 PM, Jan Kiszka  wrote:
>> Avoids reimplementation of DMI matching in intel_quark_i2c_setup.
> 
> What's wrong with current approach? I suppose this will make sense
> when we will have an issue / impediment. Right now it looks like
> over-engineering.
> 
> (Yes, I know what I said to you about this earlier, OTOH see above)
> 

It allows matching on additional DMI tags without additional code -
patch 2 depends on it.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [RFC][PATCH 0/9] Make containers kernel objects

[Jessica Frazelle]

I had replied but not to the thread with the containers mailing list.
See https://marc.info/?l=linux-cgroups=149547317006676=2

On Mon, May 22, 2017 at 5:53 PM, James Bottomley
 wrote:
> [Added missing cc to containers list]
> On Mon, 2017-05-22 at 17:22 +0100, David Howells wrote:
>> Here are a set of patches to define a container object for the kernel
>> and to provide some methods to create and manipulate them.
>>
>> The reason I think this is necessary is that the kernel has no idea
>> how to direct upcalls to what userspace considers to be a container -
>> current Linux practice appears to make a "container" just an
>> arbitrarily chosen junction of namespaces, control groups and files,
>> which may be changed individually within the "container".
>
> This sounds like a step in the wrong direction: the strength of the
> current container interfaces in Linux is that people who set up
> containers don't have to agree what they look like.  So I can set up a
> user namespace without a mount namespace or an architecture emulation
> container with only a mount namespace.
>
> But ignoring my fun foibles with containers and to give a concrete
> example in terms of a popular orchestration system: in kubernetes,
> where certain namespaces are shared across pods, do you imagine the
> kernel's view of the "container" to be the pod or what kubernetes
> thinks of as the container?  This is important, because half the
> examples you give below are network related and usually pods share a
> network namespace.

I am glad you pointed this out because I was trying to make the same
point, various definitions of containers differ and who is to say
whether the various container runtimes (runc, rkt, systemd-nspawn) or
consumers of containers (kubernetes) won't modify their definition in
the future. How will this scale as new LSMs like Landlock or new
namespaces are added in the future will they be included in the
container kernel object as well...

Seems like a lot more maintenance for something that is really just
making the keyring namespace-aware... unless there are other things I
missed.

>
>> The kernel upcall mechanism then needs to decide which set of
>> namespaces, etc., it must exec the appropriate upcall program.
>>  Examples of this include:
>>
>>  (1) The DNS resolver.  The DNS cache in the kernel should probably
>> be per-network namespace, but in userspace the program, its
>> libraries and its config data are associated with a mount tree and a
>> user namespace and it gets run in a particular pid namespace.
>
> All persistent (written to fs data) has to be mount ns associated;
> there are no ifs, ands and buts to that.  I agree this implies that if
> you want to run a separate network namespace, you either take DNS from
> the parent (a lot of containers do) or you set up a daemon to run
> within the mount namespace.  I agree the latter is a slightly fiddly
> operation you have to get right, but that's why we have orchestration
> systems.
>
> What is it we could do with the above that we cannot do today?
>
>>  (2) NFS ID mapper.  The NFS ID mapping cache should also probably be
>>  per-network namespace.
>
> I think this is a view but not the only one:  Right at the moment, NFS
> ID mapping is used as the one of the ways we can get the user namespace
> ID mapping writes to file problems fixed ... that makes it a property
> of the mount namespace for a lot of containers.  There are many other
> instances where they do exactly as you say, but what I'm saying is that
> we don't want to lose the flexibility we currently have.
>
>>  (3) nfsdcltrack.  A way for NFSD to access stable storage for
>> tracking of persistent state.  Again, network-namespace dependent,
>> but also perhaps mount-namespace dependent.
>
> So again, given we can set this up to work today, this sounds like more
> a restriction that will bite us than an enhancement that gives us extra
> features.
>
>>  (4) General request-key upcalls.  Not particularly namespace
>> dependent, apart from keyrings being somewhat governed by the user
>> namespace and the upcall being configured by the mount namespace.
>
> All mount namespaces have an owning user namespace, so the data
> relations are already there in the kernel, is the problem simply
> finding them?
>
>> These patches are built on top of the mount context patchset so that
>> namespaces can be properly propagated over submounts/automounts.
>
> I'll stop here ... you get the idea that I think this is imposing a set
> of restrictions that will come back to bite us later.  If this is just
> for the sake of figuring out how to get keyring upcalls to work, then
> I'm sure we can come up with something.
>
> James
>
> --
> To unsubscribe from this list: send the line "unsubscribe cgroups" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 


Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 

Re: [PATCH 1/4] iio: hi8435: add raw access

[Vladimir Barinov]

On 20.05.2017 19:33, Jonathan Cameron wrote:

On 19/05/17 15:47, Nikita Yushchenko wrote:

With current event-only driver, it is not possible for user space
application to know current senses if they don't change since
application starts.

Address that by adding raw access to channels.

Signed-off-by: Nikita Yushchenko 

Ideally I'd like Vladimir's ack on these, but I am going to guess
that he is fine with this and rely on him shouting if not ;)

Acked-by: Vladimir Barinov 

Originally it was a part of the patch for HI8435 buffer interface but 
removed during migration to event interface:

http://marc.info/?l=linux-iio=143817462614547=4

This is a case when raw access is needed.

Re: [PATCH v2 1/2] mfd: intel_quark_i2c_gpio: Use dmi_system_id table for retrieving frequency

[Andy Shevchenko]

On Mon, May 22, 2017 at 8:38 PM, Jan Kiszka  wrote:
> On 2017-05-22 19:36, Andy Shevchenko wrote:
>> On Mon, May 22, 2017 at 8:34 PM, Jan Kiszka  wrote:
>>> On 2017-05-22 19:26, Andy Shevchenko wrote:
 On Mon, May 22, 2017 at 8:25 PM, Jan Kiszka  wrote:
> On 2017-05-22 19:20, Andy Shevchenko wrote:
>> On Mon, May 22, 2017 at 8:18 PM, Jan Kiszka  
>> wrote:
>>> On 2017-05-22 19:12, Andy Shevchenko wrote:
 On Mon, May 22, 2017 at 1:53 PM, Jan Kiszka  
 wrote:

>> And since there is no difference to the frequency the name is enough.
>> So, I wouldn't go with this series as is. See above.
>
> Nope: Just like for the stmmac, we need to include the asset tags to
> avoid matching variations of the devices which may carry the same board
> name. While I will try to avoid that this happens, we are better safe
> than sorry here.

 Do we have an issue right now?
 Yes / No
>>>
>>> Andy, we are trying to design a robust upstream driver here, no ad-hoc
>>> BSP that will not survive the hardware anyway.
>>
>> You didn't answer my question...
>>
>> I do not see a good point to solve the issue that might happen in the future.
>>
>
> While I do - that's why your question is misleading.
>
> Then let's leave the decision up to the maintainer.

Lee, just for your convenience I'm repeating myself here:

I do not like this series at all since it tries to solve non-existing
issue in over-engineering way.

If you on opposite side I will be happy to help reviewing it.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v5 5/6] spi: slave: Add SPI slave handler reporting uptime at previous message

[Andy Shevchenko]

On Mon, May 22, 2017 at 4:11 PM, Geert Uytterhoeven
 wrote:
> Add an example SPI slave handler responding with the uptime at the time
> of reception of the last SPI message.
>
> This can be used by an external microcontroller as a dead man's switch.
>

FWIW:
Reviewed-by: Andy Shevchenko 

> Signed-off-by: Geert Uytterhoeven 
> ---
> v5:
>   - Add usage documentation to file header,
>   - Replace pr_*() by dev_*(), stop printing __func__,
>   - Rename rem_ns to rem_us, as the remainder is in microseconds,
>   - Remove spi_setup() call to configure 8 bits per word, as that's the
> default,
>
> v4:
>   - No changes,
>
> v3:
>   - Add #include ,
>
> v2:
>   - Resolve semantic differences in patch description, file header, and
> module description,
>   - Use spi_async() instead of spi_read(),
>   - Submit the next transfer from the previous transfer's completion
> callback, removing the need for a thread,
>   - Let .remove() call spi_slave_abort() to cancel the current ongoing
> transfer, and wait for the completion to terminate,
>   - Remove FIXME about hanging kthread_stop().
> ---
>  drivers/spi/Kconfig  |   6 ++
>  drivers/spi/Makefile |   1 +
>  drivers/spi/spi-slave-time.c | 129 
> +++
>  3 files changed, 136 insertions(+)
>  create mode 100644 drivers/spi/spi-slave-time.c
>
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index f21499b1f71ab7c3..9972ee2a8454a2fc 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -797,6 +797,12 @@ config SPI_SLAVE
>
>  if SPI_SLAVE
>
> +config SPI_SLAVE_TIME
> +   tristate "SPI slave handler reporting boot up time"
> +   help
> + SPI slave handler responding with the time of reception of the last
> + SPI message.
> +
>  endif # SPI_SLAVE
>
>  endif # SPI
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index e50852c6fcb87d8b..fb078693dbe40da4 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -107,3 +107,4 @@ obj-$(CONFIG_SPI_XTENSA_XTFPGA) += 
> spi-xtensa-xtfpga.o
>  obj-$(CONFIG_SPI_ZYNQMP_GQSPI) += spi-zynqmp-gqspi.o
>
>  # SPI slave protocol handlers
> +obj-$(CONFIG_SPI_SLAVE_TIME)   += spi-slave-time.o
> diff --git a/drivers/spi/spi-slave-time.c b/drivers/spi/spi-slave-time.c
> new file mode 100644
> index ..f2e07a392d6863ea
> --- /dev/null
> +++ b/drivers/spi/spi-slave-time.c
> @@ -0,0 +1,129 @@
> +/*
> + * SPI slave handler reporting uptime at reception of previous SPI message
> + *
> + * This SPI slave handler sends the time of reception of the last SPI message
> + * as two 32-bit unsigned integers in binary format and in network byte 
> order,
> + * representing the number of seconds and fractional seconds (in 
> microseconds)
> + * since boot up.
> + *
> + * Copyright (C) 2016-2017 Glider bvba
> + *
> + * This file is subject to the terms and conditions of the GNU General Public
> + * License.  See the file "COPYING" in the main directory of this archive
> + * for more details.
> + *
> + * Usage (assuming /dev/spidev2.0 corresponds to the SPI master on the remote
> + * system):
> + *
> + *   # spidev_test -D /dev/spidev2.0 -p dummy-8B
> + *   spi mode: 0x0
> + *   bits per word: 8
> + *   max speed: 50 Hz (500 KHz)
> + *   RX | 00 00 04 6D 00 09 5B BB ...
> + * ^
> + * seconds  microseconds
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +
> +struct spi_slave_time_priv {
> +   struct spi_device *spi;
> +   struct completion finished;
> +   struct spi_transfer xfer;
> +   struct spi_message msg;
> +   __be32 buf[2];
> +};
> +
> +static int spi_slave_time_submit(struct spi_slave_time_priv *priv);
> +
> +static void spi_slave_time_complete(void *arg)
> +{
> +   struct spi_slave_time_priv *priv = arg;
> +   int ret;
> +
> +   ret = priv->msg.status;
> +   if (ret)
> +   goto terminate;
> +
> +   ret = spi_slave_time_submit(priv);
> +   if (ret)
> +   goto terminate;
> +
> +   return;
> +
> +terminate:
> +   dev_info(>spi->dev, "Terminating\n");
> +   complete(>finished);
> +}
> +
> +static int spi_slave_time_submit(struct spi_slave_time_priv *priv)
> +{
> +   u32 rem_us;
> +   int ret;
> +   u64 ts;
> +
> +   ts = local_clock();
> +   rem_us = do_div(ts, 10) / 1000;
> +
> +   priv->buf[0] = cpu_to_be32(ts);
> +   priv->buf[1] = cpu_to_be32(rem_us);
> +
> +   spi_message_init_with_transfers(>msg, >xfer, 1);
> +
> +   priv->msg.complete = spi_slave_time_complete;
> +   priv->msg.context = priv;
> +
> +   ret = spi_async(priv->spi, >msg);
> +   if (ret)
> +   dev_err(>spi->dev, "spi_async() failed %d\n", ret);
> +
> +   return ret;
> +}
> +
> +static int spi_slave_time_probe(struct 

Re: [PATCH v2] kernel.h: handle pointers to arrays better in container_of()

[Michal Nazarewicz]

On Mon, May 22 2017, Ian Abbott wrote:
> If the first parameter of container_of() is a pointer to a
> non-const-qualified array type (and the third parameter names a
> non-const-qualified array member), the local variable __mptr will be
> defined with a const-qualified array type.  In ISO C, these types are
> incompatible.  They work as expected in GNU C, but some versions will
> issue warnings.  For example, GCC 4.9 produces the warning
> "initialization from incompatible pointer type".
>
> Here is an example of where the problem occurs:
>
> ---
>  #include 
>  #include 
>
> MODULE_LICENSE("GPL");
>
> struct st {
>   int a;
>   char b[16];
> };
>
> static int __init example_init(void) {
>   struct st t = { .a = 101, .b = "hello" };
>   char (*p)[16] = 
>   struct st *x = container_of(p, struct st, b);
>   printk(KERN_DEBUG "%p %p\n", (void *), (void *)x);
>   return 0;
> }
>
> static void __exit example_exit(void) {
> }
>
> module_init(example_init);
> module_exit(example_exit);
> ---
>
> Building the module with gcc-4.9 results in these warnings (where '{m}'
> is the module source and '{k}' is the kernel source):
>
> ---
> In file included from {m}/example.c:1:0:
> {m}/example.c: In function ‘example_init’:
> {k}/include/linux/kernel.h:854:48: warning: initialization from
> incompatible pointer type
>   const typeof( ((type *)0)->member ) *__mptr = (ptr); \
> ^
> {m}/example.c:14:17: note: in expansion of macro ‘container_of’
>   struct st *x = container_of(p, struct st, b);
>  ^
> {k}/include/linux/kernel.h:854:48: warning: (near initialization for
> ‘x’)
>   const typeof( ((type *)0)->member ) *__mptr = (ptr); \
> ^
> {m}/example.c:14:17: note: in expansion of macro ‘container_of’
>   struct st *x = container_of(p, struct st, b);
>  ^
> ---
>
> Fix it by avoiding defining the __mptr variable.  This also avoids other
> GCC extensions.
>
> Signed-off-by: Ian Abbott 
> Cc: Andrew Morton 
> Cc: Michal Nazarewicz 
> Cc: Hidehiro Kawai 
> Cc: Borislav Petkov 
> Cc: Rasmus Villemoes 
> Cc: Johannes Berg 
> Cc: Peter Zijlstra 
> Cc: Alexander Potapenko 
> ---
> v2: Rebased and altered description to provide an example of when the
> compiler warnings occur.  v1 (from 2016-10-10) also modified a
> 'container_of_safe()' macro that never made it out of "linux-next".
> ---
>  include/linux/kernel.h | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 13bc08aba704..169fe6f51b7b 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -850,9 +850,8 @@ static inline void ftrace_dump(enum ftrace_dump_mode 
> oops_dump_mode) { }
>   * @member:  the name of the member within the struct.
>   *
>   */
> -#define container_of(ptr, type, member) ({   \
> - const typeof( ((type *)0)->member ) *__mptr = (ptr);\
> - (type *)( (char *)__mptr - offsetof(type,member) );})
> +#define container_of(ptr, type, member) \
> + ((type *)((char *)(ptr) - offsetof(type, member)))

Now the type of ptr is not checked though.  Using your example, I can
now write:

struct st t = { .a = 101, .b = "hello" };
int *p = 
struct st *x = container_of(p, struct st, b);

and it will compile with no warnings.  Previously it would fail.  The
best I can think of would be (not tested):

#define container_of(ptr, type, member) (   \
_Static_assert(__builtin_types_compatible_p(\
typeof(ptr), typeof( ((type *)0)->member )*), "WUT"),   \
((type *)((char *)(ptr) - offsetof(type, member))); \
)

or maybe:

#define container_of(ptr, type, member) (   \
_Static_assert(__builtin_types_compatible_p(\
typeof(*ptr), typeof( ((type *)0)->member )), "WUT"),   \
((type *)((char *)(ptr) - offsetof(type, member))); \
)

>  
>  /* Rebuild everything on CONFIG_FTRACE_MCOUNT_RECORD */
>  #ifdef CONFIG_FTRACE_MCOUNT_RECORD

-- 
Best regards
ミハウ “퓶퓲퓷퓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»

Re: [PATCH v5 6/6] spi: slave: Add SPI slave handler controlling system state

[Andy Shevchenko]

On Mon, May 22, 2017 at 4:11 PM, Geert Uytterhoeven
 wrote:
> Add an example SPI slave handler to allow remote control of system
> reboot, power off, halt, and suspend.
>

FWIW:
Reviewed-by: Andy Shevchenko 

> Signed-off-by: Geert Uytterhoeven 
> ---
> v5:
>   - Add usage documentation to file header,
>   - Use network byte order for commands, to match the "-p" parameter of
> spidev_test,
>   - Replace pr_*() by dev_*(), stop printing __func__,
>   - Remove spi_setup() call to configure 8 bits per word, as that's the
> default,
>
> v3, v4:
>   - No changes,
>
> v2:
>   - Use spi_async() instead of spi_read(),
>   - Submit the next transfer from the previous transfer's completion
> callback, removing the need for a thread,
>   - Let .remove() call spi_slave_abort() to cancel the current ongoing
> transfer, and wait for the completion to terminate,
>   - Remove FIXME about hanging kthread_stop(),
>   - Fix copy-and-pasted module description.
> ---
>  drivers/spi/Kconfig|   6 ++
>  drivers/spi/Makefile   |   1 +
>  drivers/spi/spi-slave-system-control.c | 154 
> +
>  3 files changed, 161 insertions(+)
>  create mode 100644 drivers/spi/spi-slave-system-control.c
>
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 9972ee2a8454a2fc..82cd818aa06293f5 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -803,6 +803,12 @@ config SPI_SLAVE_TIME
>   SPI slave handler responding with the time of reception of the last
>   SPI message.
>
> +config SPI_SLAVE_SYSTEM_CONTROL
> +   tristate "SPI slave handler controlling system state"
> +   help
> + SPI slave handler to allow remote control of system reboot, power
> + off, halt, and suspend.
> +
>  endif # SPI_SLAVE
>
>  endif # SPI
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index fb078693dbe40da4..1d7923e8c63bc22b 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -108,3 +108,4 @@ obj-$(CONFIG_SPI_ZYNQMP_GQSPI)  += 
> spi-zynqmp-gqspi.o
>
>  # SPI slave protocol handlers
>  obj-$(CONFIG_SPI_SLAVE_TIME)   += spi-slave-time.o
> +obj-$(CONFIG_SPI_SLAVE_SYSTEM_CONTROL) += spi-slave-system-control.o
> diff --git a/drivers/spi/spi-slave-system-control.c 
> b/drivers/spi/spi-slave-system-control.c
> new file mode 100644
> index ..c0257e937995ec53
> --- /dev/null
> +++ b/drivers/spi/spi-slave-system-control.c
> @@ -0,0 +1,154 @@
> +/*
> + * SPI slave handler controlling system state
> + *
> + * This SPI slave handler allows remote control of system reboot, power off,
> + * halt, and suspend.
> + *
> + * Copyright (C) 2016-2017 Glider bvba
> + *
> + * This file is subject to the terms and conditions of the GNU General Public
> + * License.  See the file "COPYING" in the main directory of this archive
> + * for more details.
> + *
> + * Usage (assuming /dev/spidev2.0 corresponds to the SPI master on the remote
> + * system):
> + *
> + *   # reboot='\x7c\x50'
> + *   # poweroff='\x71\x3f'
> + *   # halt='\x38\x76'
> + *   # suspend='\x1b\x1b'
> + *   # spidev_test -D /dev/spidev2.0 -p $suspend # or $reboot, $poweroff, 
> $halt
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * The numbers are chosen to display something human-readable on two 
> 7-segment
> + * displays connected to two 74HC595 shift registers
> + */
> +#define CMD_REBOOT 0x7c50  /* rb */
> +#define CMD_POWEROFF   0x713f  /* OF */
> +#define CMD_HALT   0x3876  /* HL */
> +#define CMD_SUSPEND0x1b1b  /* ZZ */
> +
> +struct spi_slave_system_control_priv {
> +   struct spi_device *spi;
> +   struct completion finished;
> +   struct spi_transfer xfer;
> +   struct spi_message msg;
> +   __be16 cmd;
> +};
> +
> +static
> +int spi_slave_system_control_submit(struct spi_slave_system_control_priv 
> *priv);
> +
> +static void spi_slave_system_control_complete(void *arg)
> +{
> +   struct spi_slave_system_control_priv *priv = arg;
> +   u16 cmd;
> +   int ret;
> +
> +   if (priv->msg.status)
> +   goto terminate;
> +
> +   cmd = be16_to_cpu(priv->cmd);
> +   switch (cmd) {
> +   case CMD_REBOOT:
> +   dev_info(>spi->dev, "Rebooting system...\n");
> +   kernel_restart(NULL);
> +
> +   case CMD_POWEROFF:
> +   dev_info(>spi->dev, "Powering off system...\n");
> +   kernel_power_off();
> +   break;
> +
> +   case CMD_HALT:
> +   dev_info(>spi->dev, "Halting system...\n");
> +   kernel_halt();
> +   break;
> +
> +   case CMD_SUSPEND:
> +   dev_info(>spi->dev, "Suspending system...\n");
> +   pm_suspend(PM_SUSPEND_MEM);
> +   break;
> +
> +   default:
> +   

Re: [PATCH] mm/oom_kill: count global and memory cgroup oom kills

[Roman Guschin]

2017-05-22 10:11 GMT+01:00 Konstantin Khlebnikov :
>
>
> On 19.05.2017 19:34, Roman Guschin wrote:
>>
>> 2017-05-19 15:22 GMT+01:00 Konstantin Khlebnikov
>> :
>>  From a user's point of view the difference between "oom" and "max"
>> becomes really vague here,
>> assuming that "max" is described almost in the same words:
>>
>> "The number of times the cgroup's memory usage was
>> about to go over the max boundary.  If direct reclaim
>> fails to bring it down, the OOM killer is invoked."
>>
>> I wonder, if it's better to fix the existing "oom" value  to show what
>> it has to show, according to docs,
>> rather than to introduce a new one?
>>
>
> Nope, they are different. I think we should rephase documentation somehow
>
> low - count of reclaims below low level
> high - count of post-allocation reclaims above high level
> max - count of direct reclaims
> oom - count of failed direct reclaims
> oom_kill - count of oom killer invocations and killed processes

Definitely worth it.

Also, I would prefer to reserve "oom" for number of oom victims,
and introduce something like "reclaim_failed".
It will be consistent with existing vmstat.

Thanks!

Re: [uml-devel] [PATCH] um: Add mark_rodata_ro support.

[Thomas Meyer]

> Am 21.05.2017 um 23:28 schrieb Richard Weinberger 
> :
> 
> Thomas,
> 
>> On Thu, May 18, 2017 at 12:11 AM, Thomas Meyer  wrote:
>> This is actually a no-op as all read-only should be read-only in the ELF.
> 
> What problem does this patch fix? Or what is the purpose?

Hi,

It's purely cosmetic; to get rid of the boot message: "This architecture does 
not have kernel memory protection." in init/main.c

Which isn't true for UML as all read only stuff should end up in a read only 
ELF section. Shouldn't it?

> 
> -- 
> Thanks,
> //richard
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> User-mode-linux-devel mailing list
> user-mode-linux-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel


smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH v2 1/2] mfd: intel_quark_i2c_gpio: Use dmi_system_id table for retrieving frequency

[Lee Jones]

On Mon, 22 May 2017, Andy Shevchenko wrote:

> On Mon, May 22, 2017 at 8:38 PM, Jan Kiszka  wrote:
> > On 2017-05-22 19:36, Andy Shevchenko wrote:
> >> On Mon, May 22, 2017 at 8:34 PM, Jan Kiszka  wrote:
> >>> On 2017-05-22 19:26, Andy Shevchenko wrote:
>  On Mon, May 22, 2017 at 8:25 PM, Jan Kiszka  
>  wrote:
> > On 2017-05-22 19:20, Andy Shevchenko wrote:
> >> On Mon, May 22, 2017 at 8:18 PM, Jan Kiszka  
> >> wrote:
> >>> On 2017-05-22 19:12, Andy Shevchenko wrote:
>  On Mon, May 22, 2017 at 1:53 PM, Jan Kiszka  
>  wrote:
> 
> >> And since there is no difference to the frequency the name is enough.
> >> So, I wouldn't go with this series as is. See above.
> >
> > Nope: Just like for the stmmac, we need to include the asset tags to
> > avoid matching variations of the devices which may carry the same board
> > name. While I will try to avoid that this happens, we are better safe
> > than sorry here.
> 
>  Do we have an issue right now?
>  Yes / No
> >>>
> >>> Andy, we are trying to design a robust upstream driver here, no ad-hoc
> >>> BSP that will not survive the hardware anyway.
> >>
> >> You didn't answer my question...
> >>
> >> I do not see a good point to solve the issue that might happen in the 
> >> future.
> >>
> >
> > While I do - that's why your question is misleading.
> >
> > Then let's leave the decision up to the maintainer.
> 
> Lee, just for your convenience I'm repeating myself here:
> 
> I do not like this series at all since it tries to solve non-existing
> issue in over-engineering way.
> 
> If you on opposite side I will be happy to help reviewing it.

New code looks cleaner and appears to use an already defined API.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 0/3] stmmac: pci: Refactor DMI probing

[David Miller]

From: Jan Kiszka 
Date: Mon, 22 May 2017 19:06:07 +0200

> On 2017-05-22 18:35, David Miller wrote:
>> From: Jan Kiszka 
>> Date: Mon, 22 May 2017 13:12:06 +0200
>> 
>>> Some cleanups of the way we probe DMI platforms in the driver. Reduces
>>> a bit of open-coding and makes the logic easier reusable for any
>>> potential DMI platform != Quark.
>>>
>>> Tested on IOT2000 and Galileo Gen2.
>> 
>> This doesn't compile:
>> 
>> drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:285:3: error: initializer 
>> element is not computable at load time
>>(kernel_ulong_t)_default_setup,
>>^
>> drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:285:3: note: (near 
>> initialization for ‘stmmac_id_table[0].class’)
>> drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:289:3: error: initializer 
>> element is not computable at load time
>>(kernel_ulong_t)_default_setup,
>>^
>> drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:289:3: note: (near 
>> initialization for ‘stmmac_id_table[1].class’)
>> scripts/Makefile.build:302: recipe for target 
>> 'drivers/net/ethernet/stmicro/stmmac/stmmac_pci.o' failed
>> make[5]: *** [drivers/net/ethernet/stmicro/stmmac/stmmac_pci.o] Error 1
>> 
> 
> Hmm. Which arch is this?

x86_64, allmodconfig

Re: [PATCH 08/13] ARM: dts: armada-385-linksys: use binary unit prefixes

[Ralph Sennhauser]

On Mon, 22 May 2017 17:00:01 +0200
Andrew Lunn  wrote:

> On Sun, May 21, 2017 at 02:48:57PM +0200, Ralph Sennhauser wrote:
> > Use IEEE 1541-2002 unit prefixes for sizes.  
> 
> Does ePAPR recommend this?

Not directly, but the paper (v1.1) itself is using MiB as well which
could be seen as a recommendation.

SI and NIST to my knowledge explicitly state to not use SI prefixes for
anything but powers of 10. Also as far as I'm aware any relevant
standard body adopted / endorsed these.

> 
> I think this looks ugly, so i would not do it.

Needs getting used to indeed. I for myself I can say I've gotten over
it by now. Grepping the Linux tree shows quite a few other examples of
MiB so this one wont feel lonely either.

Ralph

[PATCH] infiniband: hw: qedr: add null check before pointer dereference

[Gustavo A. R. Silva]

Add null check before dereferencing pointer sgid_attr.ndev
inside function rdma_vlan_dev_vlan_id().

Addresses-Coverity-ID: 1373979
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/infiniband/hw/qedr/qedr_cm.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/infiniband/hw/qedr/qedr_cm.c 
b/drivers/infiniband/hw/qedr/qedr_cm.c
index 3d7705c..d86dbe8 100644
--- a/drivers/infiniband/hw/qedr/qedr_cm.c
+++ b/drivers/infiniband/hw/qedr/qedr_cm.c
@@ -270,11 +270,13 @@ static inline int qedr_gsi_build_header(struct qedr_dev 
*dev,
return rc;
}
 
-   vlan_id = rdma_vlan_dev_vlan_id(sgid_attr.ndev);
-   if (vlan_id < VLAN_CFI_MASK)
-   has_vlan = true;
-   if (sgid_attr.ndev)
+   if (sgid_attr.ndev) {
+   vlan_id = rdma_vlan_dev_vlan_id(sgid_attr.ndev);
+   if (vlan_id < VLAN_CFI_MASK)
+   has_vlan = true;
+
dev_put(sgid_attr.ndev);
+   }
 
if (!memcmp(, , sizeof(sgid))) {
DP_ERR(dev, "gsi post send: GID not found GID index %d\n",
-- 
2.5.0

Re: [PATCH 13/23] md: namespace private helper names

[Andy Shevchenko]

On Thu, 2017-05-18 at 08:26 +0200, Christoph Hellwig wrote:
> From: Amir Goldstein 
> 
> The md private helper uuid_equal() collides with a generic helper
> of the same name.
> 
> Rename the md private helper to md_uuid_equal() and do the same for
> md_sb_equal().
> 

While patch is good, shouldn't it go before we introduce those helpers?

> Cc: Shaohua Li 
> Signed-off-by: Amir Goldstein 
> Signed-off-by: Christoph Hellwig 
> ---
>  drivers/md/md.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 82f798be964f..65795cc4cb7d 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -825,7 +825,7 @@ static int read_disk_sb(struct md_rdev *rdev, int
> size)
>   return -EINVAL;
>  }
>  
> -static int uuid_equal(mdp_super_t *sb1, mdp_super_t *sb2)
> +static int md_uuid_equal(mdp_super_t *sb1, mdp_super_t *sb2)
>  {
>   return  sb1->set_uuid0 == sb2->set_uuid0 &&
>   sb1->set_uuid1 == sb2->set_uuid1 &&
> @@ -833,7 +833,7 @@ static int uuid_equal(mdp_super_t *sb1,
> mdp_super_t *sb2)
>   sb1->set_uuid3 == sb2->set_uuid3;
>  }
>  
> -static int sb_equal(mdp_super_t *sb1, mdp_super_t *sb2)
> +static int md_sb_equal(mdp_super_t *sb1, mdp_super_t *sb2)
>  {
>   int ret;
>   mdp_super_t *tmp1, *tmp2;
> @@ -1025,12 +1025,12 @@ static int super_90_load(struct md_rdev *rdev,
> struct md_rdev *refdev, int minor
>   } else {
>   __u64 ev1, ev2;
>   mdp_super_t *refsb = page_address(refdev->sb_page);
> - if (!uuid_equal(refsb, sb)) {
> + if (!md_uuid_equal(refsb, sb)) {
>   pr_warn("md: %s has different UUID to %s\n",
>   b, bdevname(refdev->bdev,b2));
>   goto abort;
>   }
> - if (!sb_equal(refsb, sb)) {
> + if (!md_sb_equal(refsb, sb)) {
>   pr_warn("md: %s has same UUID but different
> superblock to %s\n",
>   b, bdevname(refdev->bdev, b2));
>   goto abort;

-- 
Andy Shevchenko 
Intel Finland Oy

Re: [PATCH v4 1/2] mfd: intel_soc_pmic: Select designware i2c-bus driver

[Andy Shevchenko]

On Mon, 2017-05-22 at 11:57 +0100, Lee Jones wrote:
> On Mon, 15 May 2017, Hans de Goede wrote:
> 
> > The Crystal Cove PMIC provides an ACPI OPRegion handler, which must
> > be
> > available before other drivers using it are loaded, which is why
> > INTEL_SOC_PMIC is a bool.
> > 
> > Just having the driver is not enough, the driver for the i2c-bus
> > must
> > also be built in, to ensure this, this patch adds a select for it.
> > 
> > This fixes errors like these during boot:
> > 
> > mmc0: SDHCI controller on ACPI [80860F14:00] using ADMA
> > ACPI Error: No handler for Region [REGS] (93543b0cc3a8)
> > [UserDefinedRegion] (20170119/evregion-166)
> > ACPI Error: Region UserDefinedRegion (ID=143) has no handler
> > (20170119/exfldio-299)
> > ACPI Error: Method parse/execution failed [\_SB.PCI0.I2C7.PMI5.GET]
> > (Node 93543b0cde10), AE_NOT_EXIST (20170119/psparse-543)
> > ACPI Error: Method parse/execution failed [\_SB.PCI0.SHC1._PS0]
> > (Node 93543b0b5cd0), AE_NOT_EXIST (20170119/psparse-543)
> > acpi 80860F14:02: Failed to change power state to D0
> > 
> > While at it this patch also changes the human readable name of the
> > Kconfig
> > option to make clear the INTEL_SOC_PMIC option selects support for
> > the
> > Intel Crystal Cove PMIC and documents why this is a bool.
> > 
> > Cc: Andy Shevchenko 
> > Signed-off-by: Hans de Goede 
> 
> Would be good to get an Ack by the users/maintainers of this driver.

I'm not sure you will get (active) one.

>From my prospective, FWIW:
Reviewed-by: Andy Shevchenko 


> 
> > ---
> > Note this patch will partially conflicts with (contains the same
> > changes as)
> > a patch in Andy Shevchenko's tree.
> 
> Has this been sorted now?

>From code it looks like (renaming is already done ---vvv).
 
> >  config INTEL_SOC_PMIC
> >     bool "Support for Crystal Cove PMIC"


-- 
Andy Shevchenko 
Intel Finland Oy

Re: [PATCH V1] leds: pca955x: Correct I2C Functionality

[Jacek Anaszewski]

Hi Tin,

On 05/22/2017 11:19 AM, Tin Huynh wrote:
> The driver checks an incorrect flag of functionality of adapter.
> When a driver requires i2c_smbus_read_byte_data and
> i2c_smbus_write_byte_data, it should check I2C_FUNC_SMBUS_BYTE_DATA
> instead I2C_FUNC_I2C.
> This patch fixes the problem.
> 
> Signed-off-by: Tin Huynh 
> ---
>  drivers/leds/leds-pca955x.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/leds/leds-pca955x.c b/drivers/leds/leds-pca955x.c
> index 78a7ce8..9a87311 100644
> --- a/drivers/leds/leds-pca955x.c
> +++ b/drivers/leds/leds-pca955x.c
> @@ -285,7 +285,7 @@ static int pca955x_probe(struct i2c_client *client,
>   "slave address 0x%02x\n",
>   client->name, chip->bits, client->addr);
>  
> - if (!i2c_check_functionality(adapter, I2C_FUNC_I2C))
> + if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA))
>   return -EIO;
>  
>   if (pdata) {
> 

Applied to the fixes-for-4.12rc3 branch of linux-leds.git, thanks.

-- 
Best regards,
Jacek Anaszewski

Re: [PATCH v2 1/5] HID: intel_ish-hid: fix potential uninitialized data usage

[Srinivas Pandruvada]

Hi Arnd,
On Thu, 2017-05-18 at 22:21 +0200, Arnd Bergmann wrote:
> gcc points out an uninialized pointer dereference that could happen
> if we ever get to recv_ishtp_cl_msg_dma() or recv_ishtp_cl_msg()
> with an empty >read_list:
> 
> drivers/hid/intel-ish-hid/ishtp/client.c: In function
> 'recv_ishtp_cl_msg_dma':
> drivers/hid/intel-ish-hid/ishtp/client.c:1049:3: error: 'cl' may be
> used uninitialized in this function [-Werror=maybe-uninitialized]
> 
> The warning only appeared in very few randconfig builds, as the
> spinlocks tend to prevent gcc from tracing the variables. I only
> saw it in configurations that had neither SMP nor LOCKDEP enabled.
> 
> As we can see, we only enter the case if 'complete_rb' is non-NULL,
> and then 'cl' is known to point to complete_rb->cl. Adding another
> initialization to the same pointer is harmless here and makes it
> clear to the compiler that the behavior is well-defined.
> 
Did you get chance to test these changes on a platform with ISH?

Thanks,
Srinivas

> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/hid/intel-ish-hid/ishtp/client.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/hid/intel-ish-hid/ishtp/client.c
> b/drivers/hid/intel-ish-hid/ishtp/client.c
> index aad61328f282..78d393e616a4 100644
> --- a/drivers/hid/intel-ish-hid/ishtp/client.c
> +++ b/drivers/hid/intel-ish-hid/ishtp/client.c
> @@ -925,6 +925,7 @@ void recv_ishtp_cl_msg(struct ishtp_device *dev,
>   }
>  
>   if (complete_rb) {
> + cl = complete_rb->cl;
>   getnstimeofday(>ts_rx);
>   ++cl->recv_msg_cnt_ipc;
>   ishtp_cl_read_complete(complete_rb);
> @@ -1045,6 +1046,7 @@ void recv_ishtp_cl_msg_dma(struct ishtp_device
> *dev, void *msg,
>   }
>  
>   if (complete_rb) {
> + cl = complete_rb->cl;
>   getnstimeofday(>ts_rx);
>   ++cl->recv_msg_cnt_dma;
>   ishtp_cl_read_complete(complete_rb);

Re: [PATCH net-next 05/20] net: dsa: change scope of MDB handlers

[Florian Fainelli]

On 05/19/2017 02:00 PM, Vivien Didelot wrote:
> Change the scope of the switchdev MDB object handlers from the DSA slave
> device to the generic DSA port, so that the future port-wide API can
> also be used for other port types, such as CPU and DSA links.
> 
> Signed-off-by: Vivien Didelot 

Reviewed-by: Florian Fainelli 
-- 
Florian

Re: mm, something wring in page_lock_anon_vma_read()?

[Hugh Dickins]

On Mon, 22 May 2017, Xishi Qiu wrote:
> On 2017/5/20 10:40, Hugh Dickins wrote:
> > On Sat, 20 May 2017, Xishi Qiu wrote:
> >>
> >> Here is a bug report form redhat: 
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1305620
> >> And I meet the bug too. However it is hard to reproduce, and 
> >> 624483f3ea82598("mm: rmap: fix use-after-free in __put_anon_vma") is not 
> >> help.
> >>
> >> From the vmcore, it seems that the page is still mapped(_mapcount=0 and 
> >> _count=2),
> >> and the value of mapping is a valid address(mapping = 0x8801b3e2a101),
> >> but anon_vma has been corrupted.
> >>
> >> Any ideas?
> > 
> > Sorry, no.  I assume that _mapcount has been misaccounted, for example
> > a pte mapped in on top of another pte; but cannot begin tell you where
> 
> Hi Hugh,
> 
> What does "a pte mapped in on top of another pte" mean? Could you give more 
> info?

I mean, there are various places in mm/memory.c which decide what they
intend to do based on orig_pte, then take pte lock, then check that
pte_same(pte, orig_pte) before taking it any further.  If a pte_same()
check were missing (I do not know of any such case), then two racing
tasks might install the same pte, one on top of the other - page
mapcount being incremented twice, but decremented only once when
that pte is finally unmapped later.

Please see similar discussion in the earlier thread at
marc.info/?l=linux-mm=148222656211837=2

Hugh

> 
> Thanks,
> Xishi Qiu
> 
> > in Red Hat's kernel-3.10.0-229.4.2.el7 that might happen.
> > 
> > Hugh

Re: [PATCH net-next 12/20] net: dsa: move ageing time setter

[Florian Fainelli]

On 05/19/2017 02:00 PM, Vivien Didelot wrote:
> Move the DSA port code which sets a port ageing time in port.c, where it
> belongs.
> 
> Signed-off-by: Vivien Didelot 

Reviewed-by: Florian Fainelli 
-- 
Florian

Re: [PATCH net-next 11/20] net: dsa: move VLAN filtering setter

[Florian Fainelli]

On 05/19/2017 02:00 PM, Vivien Didelot wrote:
> Move the DSA port code which sets VLAN filtering on a port in port.c,
> where it belongs.
> 
> Signed-off-by: Vivien Didelot 

Reviewed-by: Florian Fainelli 
-- 
Florian

Re: [PATCH 2/2] dax: Fix race between colliding PMD & PTE entries

[Ross Zwisler]

On Mon, May 22, 2017 at 04:44:57PM +0200, Jan Kara wrote:
> On Wed 17-05-17 11:16:39, Ross Zwisler wrote:
> > We currently have two related PMD vs PTE races in the DAX code.  These can
> > both be easily triggered by having two threads reading and writing
> > simultaneously to the same private mapping, with the key being that private
> > mapping reads can be handled with PMDs but private mapping writes are
> > always handled with PTEs so that we can COW.
> > 
> > Here is the first race:
> > 
> > CPU 0   CPU 1
> > 
> > (private mapping write)
> > __handle_mm_fault()
> >   create_huge_pmd() - FALLBACK
> >   handle_pte_fault()
> > passes check for pmd_devmap()
> > 
> > (private mapping read)
> > __handle_mm_fault()
> >   create_huge_pmd()
> > dax_iomap_pmd_fault() inserts PMD
> > 
> > dax_iomap_pte_fault() does a PTE fault, but we already have a DAX PMD
> >   installed in our page tables at this spot.
> > 
> > Here's the second race:
> > 
> > CPU 0   CPU 1
> > 
> > (private mapping write)
> > __handle_mm_fault()
> >   create_huge_pmd() - FALLBACK
> > (private mapping read)
> > __handle_mm_fault()
> >   passes check for pmd_none()
> >   create_huge_pmd()
> > 
> >   handle_pte_fault()
> > dax_iomap_pte_fault() inserts PTE
> > dax_iomap_pmd_fault() inserts PMD,
> >but we already have a PTE at
> >this spot.
> > 
> > The core of the issue is that while there is isolation between faults to
> > the same range in the DAX fault handlers via our DAX entry locking, there
> > is no isolation between faults in the code in mm/memory.c.  This means for
> > instance that this code in __handle_mm_fault() can run:
> > 
> > if (pmd_none(*vmf.pmd) && transparent_hugepage_enabled(vma)) {
> > ret = create_huge_pmd();
> > 
> > But by the time we actually get to run the fault handler called by
> > create_huge_pmd(), the PMD is no longer pmd_none() because a racing PTE
> > fault has installed a normal PMD here as a parent.  This is the cause of
> > the 2nd race.  The first race is similar - there is the following check in
> > handle_pte_fault():
> > 
> > } else {
> > /* See comment in pte_alloc_one_map() */
> > if (pmd_devmap(*vmf->pmd) || pmd_trans_unstable(vmf->pmd))
> > return 0;
> > 
> > So if a pmd_devmap() PMD (a DAX PMD) has been installed at vmf->pmd, we
> > will bail and retry the fault.  This is correct, but there is nothing
> > preventing the PMD from being installed after this check but before we
> > actually get to the DAX PTE fault handlers.
> > 
> > In my testing these races result in the following types of errors:
> > 
> >  BUG: Bad rss-counter state mm:8800a817d280 idx:1 val:1
> >  BUG: non-zero nr_ptes on freeing mm: 15
> > 
> > Fix this issue by having the DAX fault handlers verify that it is safe to
> > continue their fault after they have taken an entry lock to block other
> > racing faults.
> > 
> > Signed-off-by: Ross Zwisler 
> > Reported-by: Pawel Lebioda 
> > Cc: sta...@vger.kernel.org
> > 
> > ---
> > 
> > I've written a new xfstest for this race, which I will send in response to
> > this patch series.  This series has also survived an xfstest run without
> > any new issues.
> > 
> > ---
> >  fs/dax.c | 18 ++
> >  1 file changed, 18 insertions(+)
> > 
> > diff --git a/fs/dax.c b/fs/dax.c
> > index c22eaf1..3cc02d1 100644
> > --- a/fs/dax.c
> > +++ b/fs/dax.c
> > @@ -1155,6 +1155,15 @@ static int dax_iomap_pte_fault(struct vm_fault *vmf,
> > }
> >  
> > /*
> > +* It is possible, particularly with mixed reads & writes to private
> > +* mappings, that we have raced with a PMD fault that overlaps with
> > +* the PTE we need to set up.  Now that we have a locked mapping entry
> > +* we can safely unmap the huge PMD so that we can install our PTE in
> > +* our page tables.
> > +*/
> > +   split_huge_pmd(vmf->vma, vmf->pmd, vmf->address);
> > +
> 
> Can we just check the PMD and if is isn't as we want it, bail out and retry
> the fault? IMHO it will be more obvious that way (and also more in line
> like these races are handled for the classical THP). Otherwise the patch
> looks good to me.

Yep, that works as well.  I'll do this for v2.

Thanks for the review.

Re: [PATCH net-next 00/20] net: dsa: distribute switch events

[Florian Fainelli]

Yo Vivien,

On 05/19/2017 02:00 PM, Vivien Didelot wrote:
> DSA is by nature the support for a switch fabric, which can be composed
> of a single, or multiple interconnected Ethernet switch chips.
> 
> The current DSA core behavior is to identify the slave port targeted by
> a request (e.g. adding a VLAN entry), and program the switch chip to
> which it belongs accordingly.
> 
> This is problematic in a multi-chip environment, since all chips of a
> fabric must be aware of most configuration changes. Here are some
> concrete examples in a 3-chip environment:
> 
>  [CPU] (mdio)
> (eth0) |   :   :  :
>   _|_______
>  [__sw0__]--[__sw1__]--[__sw2__]
>   |  |  ||  |  ||  |  |
>   v  v  vv  v  vv  v  v
>   p1 p2 p3   p4 p5 p6   p7 p8 p9
> 
> If you add a VLAN entry on p7, sw2 gets programmed, but frames won't
> reach the CPU interface in a VLAN filtered setup. sw0 and sw1 also need
> to be programmed. The same problem comes with MAC addresses (FDB, MDB),
> or ageing time changes for instance.
> 
> This patch series uses the notification chain introduced for bridging,
> to notify not only bridge, but switchdev attributes and objects events
> to all switch chips of the fabric.
> 
> An ugly debug message printing the ignored event and switch info in the
> code handling the switch VLAN events would give us:
> 
> # bridge vlan add dev p7 vid 42
> sw0: ignoring DSA_NOTIFIER_VLAN_ADD for sw2 (prepare phase)
> sw1: ignoring DSA_NOTIFIER_VLAN_ADD for sw2 (prepare phase)
> sw0: ignoring DSA_NOTIFIER_VLAN_ADD for sw2 (commit phase)
> sw1: ignoring DSA_NOTIFIER_VLAN_ADD for sw2 (commit phase)
> 
> To achieve that, patches 1-8 change the scope of the bridge and
> switchdev callbacks from the DSA slave device to the generic DSA port,
> so that the port-wide API can be used later for switch ports not exposed
> to userspace, such as CPU and DSA links.
> 
> Patches 9-15 move the DSA port specific functions in a new port.c file.
> 
> Patches 16-20 introduce new events to notify the fabric about switchdev
> attributes and objects manipulation.
> 
> This patch series only adds the plumbing to support a distributed
> configuration, but for the moment, each switch chip ignores events from
> other chips of the fabric, to keep the current behavior.
> 
> The next patch series will add support for cross-chip configuration of
> bridge ageing time, VLAN and MAC address databases operations, etc.

For this entire series:

Tested-by: Florian Fainelli 

on a 7445 (bcm-sf2), normal bridging still worked, and bridging with
VLAN filtering also did, just like adding VLANs to user-facing ports
also did.

Great job!

> 
> 
> Vivien Didelot (20):
>   net: dsa: change scope of STP state setter
>   net: dsa: change scope of notifier call chain
>   net: dsa: change scope of bridging code
>   net: dsa: change scope of FDB handlers
>   net: dsa: change scope of MDB handlers
>   net: dsa: change scope of VLAN handlers
>   net: dsa: change scope of VLAN filtering setter
>   net: dsa: change scope of ageing time setter
>   net: dsa: move port state setters
>   net: dsa: move bridging routines
>   net: dsa: move VLAN filtering setter
>   net: dsa: move ageing time setter
>   net: dsa: move FDB handlers
>   net: dsa: move MDB handlers
>   net: dsa: move VLAN handlers
>   net: dsa: move notifier info to private header
>   net: dsa: add notifier for ageing time
>   net: dsa: add FDB notifier
>   net: dsa: add MDB notifier
>   net: dsa: add VLAN notifier
> 
>  include/net/dsa.h  |  10 --
>  net/dsa/Makefile   |   2 +-
>  net/dsa/dsa_priv.h |  83 +
>  net/dsa/port.c | 260 +++
>  net/dsa/slave.c| 354 
> +
>  net/dsa/switch.c   | 175 ++
>  6 files changed, 547 insertions(+), 337 deletions(-)
>  create mode 100644 net/dsa/port.c
> 


-- 
Florian