Re: [PATCH v2] phy: sun4i: check PMU presence when poking unknown bit of pmu

[Kishon Vijay Abraham I]

On Friday 28 October 2016 11:45 PM, Hans de Goede wrote:
> Hi,
> 
> On 28-10-16 18:27, Icenowy Zheng wrote:
>> Allwinner SoC's PHY 0, when used as OTG controller, have no pmu part.
>> The code that poke some unknown bit of PMU for H3/A64 didn't check
>> the PHY, and will cause kernel oops when PHY 0 is used.
>>
>> This patch will check whether the pmu is not NULL before poking.
>>
>> Fixes: b3e0d141ca9f (phy: sun4i: add support for A64 usb phy)
>>
>> Signed-off-by: Icenowy Zheng 
>> Acked-by: Maxime Ripard 
> 
> Patch LGTM too:
> 
> Reviewed-by: Hans de Goede 

merged, thanks.

-Kishon
> 
> Regards,
> 
> Hans
> 
> 
>> ---
>>  drivers/phy/phy-sun4i-usb.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
>> index b9342a2..fec34f5 100644
>> --- a/drivers/phy/phy-sun4i-usb.c
>> +++ b/drivers/phy/phy-sun4i-usb.c
>> @@ -264,7 +264,7 @@ static int sun4i_usb_phy_init(struct phy *_phy)
>>  return ret;
>>  }
>>
>> -if (data->cfg->enable_pmu_unk1) {
>> +if (phy->pmu && data->cfg->enable_pmu_unk1) {
>>  val = readl(phy->pmu + REG_PMU_UNK1);
>>  writel(val & ~2, phy->pmu + REG_PMU_UNK1);
>>  }
>>

Re: [PATCH v2] phy: sun4i: check PMU presence when poking unknown bit of pmu

[Kishon Vijay Abraham I]

On Friday 28 October 2016 11:45 PM, Hans de Goede wrote:
> Hi,
> 
> On 28-10-16 18:27, Icenowy Zheng wrote:
>> Allwinner SoC's PHY 0, when used as OTG controller, have no pmu part.
>> The code that poke some unknown bit of PMU for H3/A64 didn't check
>> the PHY, and will cause kernel oops when PHY 0 is used.
>>
>> This patch will check whether the pmu is not NULL before poking.
>>
>> Fixes: b3e0d141ca9f (phy: sun4i: add support for A64 usb phy)
>>
>> Signed-off-by: Icenowy Zheng 
>> Acked-by: Maxime Ripard 
> 
> Patch LGTM too:
> 
> Reviewed-by: Hans de Goede 

merged, thanks.

-Kishon
> 
> Regards,
> 
> Hans
> 
> 
>> ---
>>  drivers/phy/phy-sun4i-usb.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
>> index b9342a2..fec34f5 100644
>> --- a/drivers/phy/phy-sun4i-usb.c
>> +++ b/drivers/phy/phy-sun4i-usb.c
>> @@ -264,7 +264,7 @@ static int sun4i_usb_phy_init(struct phy *_phy)
>>  return ret;
>>  }
>>
>> -if (data->cfg->enable_pmu_unk1) {
>> +if (phy->pmu && data->cfg->enable_pmu_unk1) {
>>  val = readl(phy->pmu + REG_PMU_UNK1);
>>  writel(val & ~2, phy->pmu + REG_PMU_UNK1);
>>  }
>>

Re: [PATCH] phy-rockchip-pcie: remove deassert of phy_rst from exit callback

[Kishon Vijay Abraham I]

On Friday 28 October 2016 02:01 PM, Heiko Stuebner wrote:
> Am Donnerstag, 13. Oktober 2016, 12:42:13 CEST schrieb Shawn Lin:
>> The deassert of phy_rst from exit callback is incorrect as when
>> doing phy_exit, we expect the phy_rst is on asserted state which was
>> done by power_off callback, but not deasserted state. Meanwhile when
>> disabling clk_pciephy_ref, the assert/deassert signal can't actually
>> take effect on the phy. So let's fix it anyway.
>>
>> Signed-off-by: Shawn Lin 
> 
> looks ok to have that removed, as any future phy_init call will make sure it 
> gets asserted anyway.
> 
> Reviewed-by: Heiko Stuebner 

merged, thanks.

-Kishon
> 

Re: [PATCH] phy-rockchip-pcie: remove deassert of phy_rst from exit callback

[Kishon Vijay Abraham I]

On Friday 28 October 2016 02:01 PM, Heiko Stuebner wrote:
> Am Donnerstag, 13. Oktober 2016, 12:42:13 CEST schrieb Shawn Lin:
>> The deassert of phy_rst from exit callback is incorrect as when
>> doing phy_exit, we expect the phy_rst is on asserted state which was
>> done by power_off callback, but not deasserted state. Meanwhile when
>> disabling clk_pciephy_ref, the assert/deassert signal can't actually
>> take effect on the phy. So let's fix it anyway.
>>
>> Signed-off-by: Shawn Lin 
> 
> looks ok to have that removed, as any future phy_init call will make sure it 
> gets asserted anyway.
> 
> Reviewed-by: Heiko Stuebner 

merged, thanks.

-Kishon
> 

Re: [PATCH V3 0/6] ARM64: Uprobe support added

[Pratyush Anand]

On Saturday 05 November 2016 12:16 AM, Catalin Marinas wrote:

On Fri, Nov 04, 2016 at 11:49:51AM -0600, Catalin Marinas wrote:

On Wed, Nov 02, 2016 at 02:40:40PM +0530, Pratyush Anand wrote:

Pratyush Anand (6):
  arm64: kprobe: protect/rename few definitions to be reused by uprobe
  arm64: kgdb_step_brk_fn: ignore other's exception
  arm64: Handle TRAP_TRACE for user mode as well
  arm64: Handle TRAP_BRKPT for user mode as well
  arm64: introduce mm context flag to keep 32 bit task information
  arm64: Add uprobe support


I queued the patches for 4.10. I will push them into -next sometime next
week once I do some testing (I'm currently at the LPC).


I spoke too soon. With these patches on top of 4.9-rc3, defconfig
together with FTRACE and UPROBE_EVENT enabled I get:

In file included from 
/work/Linux/linux-2.6-aarch64/arch/arm64/kernel/probes/decode-insn.c:20:0:
/work/Linux/linux-2.6-aarch64/arch/arm64/include/asm/kprobes.h:52:5: error: 
conflicting types for 'kprobe_fault_handler'
 int kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr);
 ^~~~
In file included from 
/work/Linux/linux-2.6-aarch64/arch/arm64/kernel/probes/decode-insn.c:17:0:
/work/Linux/linux-2.6-aarch64/include/linux/kprobes.h:398:90: note: previous 
definition of 'kprobe_fault_handler' was here
 static inline int kprobe_fault_handler(struct pt_regs *regs, int trapnr)

  ^
/work/Linux/linux-2.6-aarch64/scripts/Makefile.build:290: recipe for target 
'arch/arm64/kernel/probes/decode-insn.o' failed



Hu...CONFIG_KPROBE was defined in my setup and did not notice it :( 
. We need to remove #include  from

/arch/arm64/kernel/probes/decode-insn.c.
 is already included from  under #ifdef 
CONFIG_KPROBE.


diff --git a/arch/arm64/kernel/probes/decode-insn.c 
b/arch/arm64/kernel/probes/decode-insn.c

index 8a29d29..6bf6657 100644
--- a/arch/arm64/kernel/probes/decode-insn.c
+++ b/arch/arm64/kernel/probes/decode-insn.c
@@ -17,7 +17,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 

So, do you want me to send V4 or a separate topup fixup patch. Please 
let me know, will do accordingly.


~Pratyush

Re: [PATCH V3 0/6] ARM64: Uprobe support added

[Pratyush Anand]

On Saturday 05 November 2016 12:16 AM, Catalin Marinas wrote:

On Fri, Nov 04, 2016 at 11:49:51AM -0600, Catalin Marinas wrote:

On Wed, Nov 02, 2016 at 02:40:40PM +0530, Pratyush Anand wrote:

Pratyush Anand (6):
  arm64: kprobe: protect/rename few definitions to be reused by uprobe
  arm64: kgdb_step_brk_fn: ignore other's exception
  arm64: Handle TRAP_TRACE for user mode as well
  arm64: Handle TRAP_BRKPT for user mode as well
  arm64: introduce mm context flag to keep 32 bit task information
  arm64: Add uprobe support


I queued the patches for 4.10. I will push them into -next sometime next
week once I do some testing (I'm currently at the LPC).


I spoke too soon. With these patches on top of 4.9-rc3, defconfig
together with FTRACE and UPROBE_EVENT enabled I get:

In file included from 
/work/Linux/linux-2.6-aarch64/arch/arm64/kernel/probes/decode-insn.c:20:0:
/work/Linux/linux-2.6-aarch64/arch/arm64/include/asm/kprobes.h:52:5: error: 
conflicting types for 'kprobe_fault_handler'
 int kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr);
 ^~~~
In file included from 
/work/Linux/linux-2.6-aarch64/arch/arm64/kernel/probes/decode-insn.c:17:0:
/work/Linux/linux-2.6-aarch64/include/linux/kprobes.h:398:90: note: previous 
definition of 'kprobe_fault_handler' was here
 static inline int kprobe_fault_handler(struct pt_regs *regs, int trapnr)

  ^
/work/Linux/linux-2.6-aarch64/scripts/Makefile.build:290: recipe for target 
'arch/arm64/kernel/probes/decode-insn.o' failed



Hu...CONFIG_KPROBE was defined in my setup and did not notice it :( 
. We need to remove #include  from

/arch/arm64/kernel/probes/decode-insn.c.
 is already included from  under #ifdef 
CONFIG_KPROBE.


diff --git a/arch/arm64/kernel/probes/decode-insn.c 
b/arch/arm64/kernel/probes/decode-insn.c

index 8a29d29..6bf6657 100644
--- a/arch/arm64/kernel/probes/decode-insn.c
+++ b/arch/arm64/kernel/probes/decode-insn.c
@@ -17,7 +17,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 

So, do you want me to send V4 or a separate topup fixup patch. Please 
let me know, will do accordingly.


~Pratyush

Re: [PATCH v2 2/3] phy: da8xx-usb: rename the ohci device to ohci-da8xx

[Kishon Vijay Abraham I]

On Thursday 03 November 2016 09:33 PM, Axel Haslam wrote:
> The ohci device name has changed in the board configuraion files,
> hence, change the phy lookup table to match the new name.
> 
> Signed-off-by: Axel Haslam 

merged, thanks.

-Kishon
> ---
>  drivers/phy/phy-da8xx-usb.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/phy/phy-da8xx-usb.c b/drivers/phy/phy-da8xx-usb.c
> index 32ae78c..c85fb0b 100644
> --- a/drivers/phy/phy-da8xx-usb.c
> +++ b/drivers/phy/phy-da8xx-usb.c
> @@ -198,7 +198,8 @@ static int da8xx_usb_phy_probe(struct platform_device 
> *pdev)
>   } else {
>   int ret;
>  
> - ret = phy_create_lookup(d_phy->usb11_phy, "usb-phy", "ohci.0");
> + ret = phy_create_lookup(d_phy->usb11_phy, "usb-phy",
> + "ohci-da8xx");
>   if (ret)
>   dev_warn(dev, "Failed to create usb11 phy lookup\n");
>   ret = phy_create_lookup(d_phy->usb20_phy, "usb-phy",
> @@ -216,7 +217,7 @@ static int da8xx_usb_phy_remove(struct platform_device 
> *pdev)
>  
>   if (!pdev->dev.of_node) {
>   phy_remove_lookup(d_phy->usb20_phy, "usb-phy", "musb-da8xx");
> - phy_remove_lookup(d_phy->usb11_phy, "usb-phy", "ohci.0");
> + phy_remove_lookup(d_phy->usb11_phy, "usb-phy", "ohci-da8xx");
>   }
>  
>   return 0;
> 

Re: [PATCH v2 2/3] phy: da8xx-usb: rename the ohci device to ohci-da8xx

[Kishon Vijay Abraham I]

On Thursday 03 November 2016 09:33 PM, Axel Haslam wrote:
> The ohci device name has changed in the board configuraion files,
> hence, change the phy lookup table to match the new name.
> 
> Signed-off-by: Axel Haslam 

merged, thanks.

-Kishon
> ---
>  drivers/phy/phy-da8xx-usb.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/phy/phy-da8xx-usb.c b/drivers/phy/phy-da8xx-usb.c
> index 32ae78c..c85fb0b 100644
> --- a/drivers/phy/phy-da8xx-usb.c
> +++ b/drivers/phy/phy-da8xx-usb.c
> @@ -198,7 +198,8 @@ static int da8xx_usb_phy_probe(struct platform_device 
> *pdev)
>   } else {
>   int ret;
>  
> - ret = phy_create_lookup(d_phy->usb11_phy, "usb-phy", "ohci.0");
> + ret = phy_create_lookup(d_phy->usb11_phy, "usb-phy",
> + "ohci-da8xx");
>   if (ret)
>   dev_warn(dev, "Failed to create usb11 phy lookup\n");
>   ret = phy_create_lookup(d_phy->usb20_phy, "usb-phy",
> @@ -216,7 +217,7 @@ static int da8xx_usb_phy_remove(struct platform_device 
> *pdev)
>  
>   if (!pdev->dev.of_node) {
>   phy_remove_lookup(d_phy->usb20_phy, "usb-phy", "musb-da8xx");
> - phy_remove_lookup(d_phy->usb11_phy, "usb-phy", "ohci.0");
> + phy_remove_lookup(d_phy->usb11_phy, "usb-phy", "ohci-da8xx");
>   }
>  
>   return 0;
> 

Re: [RFC 0/8] Define coherent device memory node

[Anshuman Khandual]

On 10/25/2016 09:56 AM, Aneesh Kumar K.V wrote:
> I looked at the hmm-v13 w.r.t migration and I guess some form of device
> callback/acceleration during migration is something we should definitely
> have. I still haven't figured out how non addressable and coherent device
> memory can fit together there. I was waiting for the page cache
> migration support to be pushed to the repository before I start looking
> at this closely.

Aneesh, did not get that. Currently basic page cache migration is supported,
right ? The device callback during migration, fault etc are supported through
page->pgmap pointer and extending dev_pagemap structure to accommodate new
members. IIUC that is the reason ZONE_DEVICE is being modified so that page
->pgmap overloading can be used for various driver/device specific callbacks
while inside core VM functions or HMM functions.

HMM V13 has introduced non-addressable ZONE_DEVICE based device memory which
can have it's struct pages in system RAM but they cannot be accessed from the
CPU. Now coherent device memory is kind of similar to persistent memory like
NVDIMM which is already supported through ZONE_DEVICE (though we might not
want to use vmemap_altmap instead have the struct pages in the system RAM).
Now HMM has to learn working with 'dev_pagemap->addressable' type of device
memory and then support all possible migrations through it's API. So in a
nutshell, these are the changes we need to do to make HMM work with coherent
device memory.

(0) Support all possible migrations between system RAM and device memory
for current un-addressable device memory and make the HMM migration
API layer comprehensive and complete.

(1) Create coherent device memory representation in ZONE_DEVICE
(a) Make it exactly the same as that of persistent memory/NVDIMM

or

(b) Create a new type for coherent device memory representation

(2) Support all possible migrations between system RAM and device memory
for new addressable coherent device memory represented in ZONE_DEVICE
extending the HMM migration API layer.

Right now, HMM V13 patch series supports migration for a subset of private
anonymous pages for un-addressable device memory. I am wondering how difficult
is it to implement all possible anon, file mapping migration support for both
un-addressable and addressable coherent device memory through ZONE_DEVICE.

Re: [RFC 0/8] Define coherent device memory node

[Anshuman Khandual]

On 10/25/2016 09:56 AM, Aneesh Kumar K.V wrote:
> I looked at the hmm-v13 w.r.t migration and I guess some form of device
> callback/acceleration during migration is something we should definitely
> have. I still haven't figured out how non addressable and coherent device
> memory can fit together there. I was waiting for the page cache
> migration support to be pushed to the repository before I start looking
> at this closely.

Aneesh, did not get that. Currently basic page cache migration is supported,
right ? The device callback during migration, fault etc are supported through
page->pgmap pointer and extending dev_pagemap structure to accommodate new
members. IIUC that is the reason ZONE_DEVICE is being modified so that page
->pgmap overloading can be used for various driver/device specific callbacks
while inside core VM functions or HMM functions.

HMM V13 has introduced non-addressable ZONE_DEVICE based device memory which
can have it's struct pages in system RAM but they cannot be accessed from the
CPU. Now coherent device memory is kind of similar to persistent memory like
NVDIMM which is already supported through ZONE_DEVICE (though we might not
want to use vmemap_altmap instead have the struct pages in the system RAM).
Now HMM has to learn working with 'dev_pagemap->addressable' type of device
memory and then support all possible migrations through it's API. So in a
nutshell, these are the changes we need to do to make HMM work with coherent
device memory.

(0) Support all possible migrations between system RAM and device memory
for current un-addressable device memory and make the HMM migration
API layer comprehensive and complete.

(1) Create coherent device memory representation in ZONE_DEVICE
(a) Make it exactly the same as that of persistent memory/NVDIMM

or

(b) Create a new type for coherent device memory representation

(2) Support all possible migrations between system RAM and device memory
for new addressable coherent device memory represented in ZONE_DEVICE
extending the HMM migration API layer.

Right now, HMM V13 patch series supports migration for a subset of private
anonymous pages for un-addressable device memory. I am wondering how difficult
is it to implement all possible anon, file mapping migration support for both
un-addressable and addressable coherent device memory through ZONE_DEVICE.

Re: redraw issues on i915 since 4.9-rc

[Norbert Preining]

> It won't apply directly, but you could try testing that commit and its
> parent to see if my hunch was correct.

Unfortunately parent commit was also ok. I am trying to bisect, but
somehow git tells me something about "...merge commit..." - will see
how it goes.

Norbert

--
PREINING Norbert + TeX Live & Debian Developer + http://www.preining.info
GPG: 0x860CDC13fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Re: redraw issues on i915 since 4.9-rc

[Norbert Preining]

> It won't apply directly, but you could try testing that commit and its
> parent to see if my hunch was correct.

Unfortunately parent commit was also ok. I am trying to bisect, but
somehow git tells me something about "...merge commit..." - will see
how it goes.

Norbert

--
PREINING Norbert + TeX Live & Debian Developer + http://www.preining.info
GPG: 0x860CDC13fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

task isolation discussion at Linux Plumbers

[Chris Metcalf]

A bunch of people got together this week at the Linux Plumbers
Conference to discuss nohz_full, task isolation, and related stuff.
(Thanks to Thomas for getting everyone gathered at one place and time!)

Here are the notes I took; I welcome any corrections and follow-up.


== rcu_nocbs ==

We started out by discussing this option.  It is automatically enabled
by nohz_full, but we spent a little while side-tracking on the
implementation of one kthread per rcu flavor per core.  The suggestion
was made (by Peter or Andy; I forget) that each kthread could handle
all flavors per core by using a dedicated worklist.  It certainly
seems like removing potentially dozens or hundreds of kthreads from
larger systems will be a win if this works out.

Paul said he would look into this possibility.


== Remote statistics ==

We discussed the possibility of remote statistics gathering, i.e. load
average etc.  The idea would be that we could have housekeeping
core(s) periodically iterate over the nohz cores to load their rq
remotely and do update_current etc.  Presumably it should be possible
for a single housekeeping core to handle doing this for all the
nohz_full cores, as we only need to do it quite infrequently.

Thomas suggested that this might be the last remaining thing that
needed to be done to allow disabling the current behavior of falling
back to a 1 Hz clock in nohz_full.

I believe Thomas said he had a patch to do this already.


== Remote LRU cache drain ==

One of the issues with task isolation currently is that the LRU cache
drain must be done prior to entering userspace, but it requires
interrupts enabled and thus can't be done atomically.  My previous
patch series have handled this by checking with interrupts disabled,
but then looping around with interrupts enabled to try to drain the
LRU pagevecs.  Experimentally this works, but it's not provable that
it terminates, which is worrisome.  Andy suggested adding a percpu
flag to disable creation of deferred work like LRU cache pages.

Thomas suggested using an RT "local lock" to guard the LRU cache
flush; he is planning on bringing the concept to mainline in any case.
However, after some discussion we converged on simply using a spinlock
to guard the appropriate resources.  As a result, the
lru_add_drain_all() code that currently queues work on each remote cpu
to drain it, can instead simply acquire the lock and drain it remotely.
This means that a task isolation task no longer needs to worry about
being interrupted by SMP function call IPIs, so we don't have to deal
with this in the task isolation framework any more.

I don't recall anyone else volunteering to tackle this, so I will plan
to look at it.  The patch to do that should be orthogonal to the
revised task isolation patch series.


== Quiescing vmstat ==

Another issue that task isolation handles is ensuring that the vmstat
worker is quiesced before returning to user space.  Currently we
cancel the vmstat delayed work, then invoke refresh_cpu_vm_stats().
Currently neither of these things appears safe to do in the
interrupts-disabled context just before return to userspace, because
they both can call schedule(): refresh_cpu_vm_stats() via a
cond_resched() under CONFIG_NUMA, and cancel_delayed_work_sync() via a
schedule() in __cancel_work_timer().

Christoph offered to work with me to make sure that we could do the
appropriate quiescing with interrupts disabled, and seemed confident
it should be doable.


== Remote kernel TLB flush ==

Andy then brought up the issue of remote kernel TLB flush, which I've
been trying to sweep under the rug for the initial task isolation
series.  Remote TLB flush causes an interrupt on many systems (x86 and
tile, for example, although not arm64), so to the extent that it
occurs frequently, it becomes important to handle for task isolation.
With the recent addition of vmap kernel stacks, this becomes suddenly
much more important than it used to be, to the point where we now
really have to handle it for task isolation.

The basic insight here is that you can safely skip interrupting
userspace cores when you are sending remote kernel TLB flushes, since
by definition they can't touch the kernel pages in question anyway.
Then you just need to guarantee to flush the kernel TLB space next
time the userspace task re-enters the kernel.

The original Tilera dataplane code handled this by tracking task state
(kernel, user, or user-flushed) and manipulating the state atomically
at TLB flush time and kernel entry time.  After some discussion of the
overheads of such atomics, Andy pointed out that there is already an
atomic increment being done in the RCU code, and we should be able to
leverage that word to achieve this effect.  The idea is that remote
cores would do a compare-exchange of 0 to 1, which if it succeeded
would indicate that the remote core was in userspace and thus didn't
need to be IPI'd, but that it was now tagged for a kernel flush next
time the remote task 

task isolation discussion at Linux Plumbers

[Chris Metcalf]

A bunch of people got together this week at the Linux Plumbers
Conference to discuss nohz_full, task isolation, and related stuff.
(Thanks to Thomas for getting everyone gathered at one place and time!)

Here are the notes I took; I welcome any corrections and follow-up.


== rcu_nocbs ==

We started out by discussing this option.  It is automatically enabled
by nohz_full, but we spent a little while side-tracking on the
implementation of one kthread per rcu flavor per core.  The suggestion
was made (by Peter or Andy; I forget) that each kthread could handle
all flavors per core by using a dedicated worklist.  It certainly
seems like removing potentially dozens or hundreds of kthreads from
larger systems will be a win if this works out.

Paul said he would look into this possibility.


== Remote statistics ==

We discussed the possibility of remote statistics gathering, i.e. load
average etc.  The idea would be that we could have housekeeping
core(s) periodically iterate over the nohz cores to load their rq
remotely and do update_current etc.  Presumably it should be possible
for a single housekeeping core to handle doing this for all the
nohz_full cores, as we only need to do it quite infrequently.

Thomas suggested that this might be the last remaining thing that
needed to be done to allow disabling the current behavior of falling
back to a 1 Hz clock in nohz_full.

I believe Thomas said he had a patch to do this already.


== Remote LRU cache drain ==

One of the issues with task isolation currently is that the LRU cache
drain must be done prior to entering userspace, but it requires
interrupts enabled and thus can't be done atomically.  My previous
patch series have handled this by checking with interrupts disabled,
but then looping around with interrupts enabled to try to drain the
LRU pagevecs.  Experimentally this works, but it's not provable that
it terminates, which is worrisome.  Andy suggested adding a percpu
flag to disable creation of deferred work like LRU cache pages.

Thomas suggested using an RT "local lock" to guard the LRU cache
flush; he is planning on bringing the concept to mainline in any case.
However, after some discussion we converged on simply using a spinlock
to guard the appropriate resources.  As a result, the
lru_add_drain_all() code that currently queues work on each remote cpu
to drain it, can instead simply acquire the lock and drain it remotely.
This means that a task isolation task no longer needs to worry about
being interrupted by SMP function call IPIs, so we don't have to deal
with this in the task isolation framework any more.

I don't recall anyone else volunteering to tackle this, so I will plan
to look at it.  The patch to do that should be orthogonal to the
revised task isolation patch series.


== Quiescing vmstat ==

Another issue that task isolation handles is ensuring that the vmstat
worker is quiesced before returning to user space.  Currently we
cancel the vmstat delayed work, then invoke refresh_cpu_vm_stats().
Currently neither of these things appears safe to do in the
interrupts-disabled context just before return to userspace, because
they both can call schedule(): refresh_cpu_vm_stats() via a
cond_resched() under CONFIG_NUMA, and cancel_delayed_work_sync() via a
schedule() in __cancel_work_timer().

Christoph offered to work with me to make sure that we could do the
appropriate quiescing with interrupts disabled, and seemed confident
it should be doable.


== Remote kernel TLB flush ==

Andy then brought up the issue of remote kernel TLB flush, which I've
been trying to sweep under the rug for the initial task isolation
series.  Remote TLB flush causes an interrupt on many systems (x86 and
tile, for example, although not arm64), so to the extent that it
occurs frequently, it becomes important to handle for task isolation.
With the recent addition of vmap kernel stacks, this becomes suddenly
much more important than it used to be, to the point where we now
really have to handle it for task isolation.

The basic insight here is that you can safely skip interrupting
userspace cores when you are sending remote kernel TLB flushes, since
by definition they can't touch the kernel pages in question anyway.
Then you just need to guarantee to flush the kernel TLB space next
time the userspace task re-enters the kernel.

The original Tilera dataplane code handled this by tracking task state
(kernel, user, or user-flushed) and manipulating the state atomically
at TLB flush time and kernel entry time.  After some discussion of the
overheads of such atomics, Andy pointed out that there is already an
atomic increment being done in the RCU code, and we should be able to
leverage that word to achieve this effect.  The idea is that remote
cores would do a compare-exchange of 0 to 1, which if it succeeded
would indicate that the remote core was in userspace and thus didn't
need to be IPI'd, but that it was now tagged for a kernel flush next
time the remote task 

Re: [PATCH 4/7] mm: defer vmalloc from atomic context

[Joel Fernandes]

On Mon, Oct 24, 2016 at 8:44 AM, Andrey Ryabinin
 wrote:
>
>
> On 10/22/2016 06:17 PM, Christoph Hellwig wrote:
>> We want to be able to use a sleeping lock for freeing vmap to keep
>> latency down.  For this we need to use the deferred vfree mechanisms
>> no only from interrupt, but from any atomic context.
>>
>> Signed-off-by: Christoph Hellwig 
>> ---
>>  mm/vmalloc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
>> index a4e2cec..bcc1a64 100644
>> --- a/mm/vmalloc.c
>> +++ b/mm/vmalloc.c
>> @@ -1509,7 +1509,7 @@ void vfree(const void *addr)
>>
>>   if (!addr)
>>   return;
>> - if (unlikely(in_interrupt())) {
>> + if (unlikely(in_atomic())) {
>
> in_atomic() cannot always detect atomic context, thus it shouldn't be used 
> here.
> You can add something like vfree_in_atomic() and use it in atomic call sites.
>

So because in_atomic doesn't work for !CONFIG_PREEMPT kernels, can we
always defer the work in these cases?

So for non-preemptible kernels, we always defer:

if (!IS_ENABLED(CONFIG_PREEMPT) || in_atomic()) {
  // defer
}

Is this fine? Or any other ideas?

Thanks,
Joel

Re: [PATCH 4/7] mm: defer vmalloc from atomic context

[Joel Fernandes]

On Mon, Oct 24, 2016 at 8:44 AM, Andrey Ryabinin
 wrote:
>
>
> On 10/22/2016 06:17 PM, Christoph Hellwig wrote:
>> We want to be able to use a sleeping lock for freeing vmap to keep
>> latency down.  For this we need to use the deferred vfree mechanisms
>> no only from interrupt, but from any atomic context.
>>
>> Signed-off-by: Christoph Hellwig 
>> ---
>>  mm/vmalloc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
>> index a4e2cec..bcc1a64 100644
>> --- a/mm/vmalloc.c
>> +++ b/mm/vmalloc.c
>> @@ -1509,7 +1509,7 @@ void vfree(const void *addr)
>>
>>   if (!addr)
>>   return;
>> - if (unlikely(in_interrupt())) {
>> + if (unlikely(in_atomic())) {
>
> in_atomic() cannot always detect atomic context, thus it shouldn't be used 
> here.
> You can add something like vfree_in_atomic() and use it in atomic call sites.
>

So because in_atomic doesn't work for !CONFIG_PREEMPT kernels, can we
always defer the work in these cases?

So for non-preemptible kernels, we always defer:

if (!IS_ENABLED(CONFIG_PREEMPT) || in_atomic()) {
  // defer
}

Is this fine? Or any other ideas?

Thanks,
Joel

Re: [PATCH 2/3] ARM: cache-uniphier: refactor jump label to follow coding style guideline

[Masahiro Yamada]

2016-11-04 22:32 GMT+09:00 Russell King - ARM Linux :
> On Fri, Nov 04, 2016 at 09:50:56PM +0900, Masahiro Yamada wrote:
>> Hi Russell,
>>
>> 2016-11-04 21:23 GMT+09:00 Russell King - ARM Linux :
>> > On Fri, Nov 04, 2016 at 08:43:35PM +0900, Masahiro Yamada wrote:
>> >> Documentation/CodingStyle recommends to use label names which say
>> >> what the goto does or why the goto exists.
>> >>
>> >> Just in case, split it up into three labels because the CodingStyle
>> >> says "one err bugs" is a common type of bug (although, I do not
>> >> believe the current code includes such a bug).
>> >
>> > However, this has the effect of making the code unnecessarily more
>> > complicated, which is a bad thing.  Avoiding unnecessary code
>> > complexity wins over style rules.
>>
>>
>> I thought this patch is stupid, but makes the code more straight-forward;
>> the failure path only calls really needed iounmap/kfree()
>> without exploiting that NULL input makes them no-op.
>
> ... while making it more fragile, because we're going back to a
> situation where the right places need to jump to the right label
> in the cleanup, so that the right functions are called.
>
> This is a backwards step.
>
> The reason that iounmap() and kfree() check for NULL pointers is to
> allow the cleanup paths to be simple, and that's very important as
> many cleanup paths are simply _not_ tested.


OK, fair enough.



-- 
Best Regards
Masahiro Yamada

Re: [PATCH 2/3] ARM: cache-uniphier: refactor jump label to follow coding style guideline

[Masahiro Yamada]

2016-11-04 22:32 GMT+09:00 Russell King - ARM Linux :
> On Fri, Nov 04, 2016 at 09:50:56PM +0900, Masahiro Yamada wrote:
>> Hi Russell,
>>
>> 2016-11-04 21:23 GMT+09:00 Russell King - ARM Linux :
>> > On Fri, Nov 04, 2016 at 08:43:35PM +0900, Masahiro Yamada wrote:
>> >> Documentation/CodingStyle recommends to use label names which say
>> >> what the goto does or why the goto exists.
>> >>
>> >> Just in case, split it up into three labels because the CodingStyle
>> >> says "one err bugs" is a common type of bug (although, I do not
>> >> believe the current code includes such a bug).
>> >
>> > However, this has the effect of making the code unnecessarily more
>> > complicated, which is a bad thing.  Avoiding unnecessary code
>> > complexity wins over style rules.
>>
>>
>> I thought this patch is stupid, but makes the code more straight-forward;
>> the failure path only calls really needed iounmap/kfree()
>> without exploiting that NULL input makes them no-op.
>
> ... while making it more fragile, because we're going back to a
> situation where the right places need to jump to the right label
> in the cleanup, so that the right functions are called.
>
> This is a backwards step.
>
> The reason that iounmap() and kfree() check for NULL pointers is to
> allow the cleanup paths to be simple, and that's very important as
> many cleanup paths are simply _not_ tested.


OK, fair enough.



-- 
Best Regards
Masahiro Yamada

[PATCH v2 2/2] Revert "f2fs: do not recover from previous remained wrong dnodes"

[Chao Yu]

From: Chao Yu 

i_times of inode will be set with current system time which can be
configured through 'date', so it's not safe to judge dnode block as
garbage data or unchanged inode depend on i_times.

Now, we have used enhanced 'cp_ver + cp' crc method to verify valid
dnode block, so I expect recoverying invalid dnode is almost not
possible.

This reverts commit 807b1e1c8e08452948495b1a9985ab46d329e5c2.

Signed-off-by: Chao Yu 
---
 fs/f2fs/recovery.c | 31 +--
 1 file changed, 1 insertion(+), 30 deletions(-)

diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index d2ba4da..62523b2 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -196,32 +196,6 @@ static void recover_inode(struct inode *inode, struct page 
*page)
ino_of_node(page), name);
 }
 
-static bool is_same_inode(struct inode *inode, struct page *ipage)
-{
-   struct f2fs_inode *ri = F2FS_INODE(ipage);
-   struct timespec disk;
-
-   if (!IS_INODE(ipage))
-   return true;
-
-   disk.tv_sec = le64_to_cpu(ri->i_ctime);
-   disk.tv_nsec = le32_to_cpu(ri->i_ctime_nsec);
-   if (timespec_compare(>i_ctime, ) > 0)
-   return false;
-
-   disk.tv_sec = le64_to_cpu(ri->i_atime);
-   disk.tv_nsec = le32_to_cpu(ri->i_atime_nsec);
-   if (timespec_compare(>i_atime, ) > 0)
-   return false;
-
-   disk.tv_sec = le64_to_cpu(ri->i_mtime);
-   disk.tv_nsec = le32_to_cpu(ri->i_mtime_nsec);
-   if (timespec_compare(>i_mtime, ) > 0)
-   return false;
-
-   return true;
-}
-
 static int find_fsync_dnodes(struct f2fs_sb_info *sbi, struct list_head *head)
 {
struct curseg_info *curseg;
@@ -248,10 +222,7 @@ static int find_fsync_dnodes(struct f2fs_sb_info *sbi, 
struct list_head *head)
goto next;
 
entry = get_fsync_inode(head, ino_of_node(page));
-   if (entry) {
-   if (!is_same_inode(entry->inode, page))
-   goto next;
-   } else {
+   if (!entry) {
if (IS_INODE(page) && is_dent_dnode(page)) {
err = recover_inode_page(sbi, page);
if (err)
-- 
2.10.1

[PATCH v2 2/2] Revert "f2fs: do not recover from previous remained wrong dnodes"

[Chao Yu]

From: Chao Yu 

i_times of inode will be set with current system time which can be
configured through 'date', so it's not safe to judge dnode block as
garbage data or unchanged inode depend on i_times.

Now, we have used enhanced 'cp_ver + cp' crc method to verify valid
dnode block, so I expect recoverying invalid dnode is almost not
possible.

This reverts commit 807b1e1c8e08452948495b1a9985ab46d329e5c2.

Signed-off-by: Chao Yu 
---
 fs/f2fs/recovery.c | 31 +--
 1 file changed, 1 insertion(+), 30 deletions(-)

diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index d2ba4da..62523b2 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -196,32 +196,6 @@ static void recover_inode(struct inode *inode, struct page 
*page)
ino_of_node(page), name);
 }
 
-static bool is_same_inode(struct inode *inode, struct page *ipage)
-{
-   struct f2fs_inode *ri = F2FS_INODE(ipage);
-   struct timespec disk;
-
-   if (!IS_INODE(ipage))
-   return true;
-
-   disk.tv_sec = le64_to_cpu(ri->i_ctime);
-   disk.tv_nsec = le32_to_cpu(ri->i_ctime_nsec);
-   if (timespec_compare(>i_ctime, ) > 0)
-   return false;
-
-   disk.tv_sec = le64_to_cpu(ri->i_atime);
-   disk.tv_nsec = le32_to_cpu(ri->i_atime_nsec);
-   if (timespec_compare(>i_atime, ) > 0)
-   return false;
-
-   disk.tv_sec = le64_to_cpu(ri->i_mtime);
-   disk.tv_nsec = le32_to_cpu(ri->i_mtime_nsec);
-   if (timespec_compare(>i_mtime, ) > 0)
-   return false;
-
-   return true;
-}
-
 static int find_fsync_dnodes(struct f2fs_sb_info *sbi, struct list_head *head)
 {
struct curseg_info *curseg;
@@ -248,10 +222,7 @@ static int find_fsync_dnodes(struct f2fs_sb_info *sbi, 
struct list_head *head)
goto next;
 
entry = get_fsync_inode(head, ino_of_node(page));
-   if (entry) {
-   if (!is_same_inode(entry->inode, page))
-   goto next;
-   } else {
+   if (!entry) {
if (IS_INODE(page) && is_dent_dnode(page)) {
err = recover_inode_page(sbi, page);
if (err)
-- 
2.10.1

Re: [PATCH 2/2] f2fs: don't skip recovering inode depend on i_times

[Chao Yu]

On 2016/11/5 6:53, Jaegeuk Kim wrote:
> On Fri, Nov 04, 2016 at 04:30:09PM +0800, Chao Yu wrote:
>> On 2016/11/4 2:02, Jaegeuk Kim wrote:
>>> On Fri, Nov 04, 2016 at 12:26:56AM +0800, Chao Yu wrote:
 From: Chao Yu 

 i_times of inode will be set with current system time which can be
 configured through 'date', so it's not safe to judge dnode block as
 garbage data depend on i_times.
>>>
>>> This is not to detect garbage data, but to skip redundant unchanged inode.
>>
>> Oops, seems 807b1e1c8e08 ("f2fs: do not recover from previous remained wrong
>> dnodes") did't describe like that. But after reading the codes, it looks like
>> the purpose of this change is to skip unchanged inode. So, commit log in
>> original is incorrect, right?
> 
> Oh, right. This indicats both of purposes: stale data and detecting same 
> inodes.

Alright.

> Let me just revert the original patch.

I can see that you have did reverting it in your git tree, but seems commit
number is not right.

Could you please merge my updated v2 patch instead?

Thanks,

> 
> Thanks,
> 
>>
>> Thanks,

Re: [PATCH 2/2] f2fs: don't skip recovering inode depend on i_times

[Chao Yu]

On 2016/11/5 6:53, Jaegeuk Kim wrote:
> On Fri, Nov 04, 2016 at 04:30:09PM +0800, Chao Yu wrote:
>> On 2016/11/4 2:02, Jaegeuk Kim wrote:
>>> On Fri, Nov 04, 2016 at 12:26:56AM +0800, Chao Yu wrote:
 From: Chao Yu 

 i_times of inode will be set with current system time which can be
 configured through 'date', so it's not safe to judge dnode block as
 garbage data depend on i_times.
>>>
>>> This is not to detect garbage data, but to skip redundant unchanged inode.
>>
>> Oops, seems 807b1e1c8e08 ("f2fs: do not recover from previous remained wrong
>> dnodes") did't describe like that. But after reading the codes, it looks like
>> the purpose of this change is to skip unchanged inode. So, commit log in
>> original is incorrect, right?
> 
> Oh, right. This indicats both of purposes: stale data and detecting same 
> inodes.

Alright.

> Let me just revert the original patch.

I can see that you have did reverting it in your git tree, but seems commit
number is not right.

Could you please merge my updated v2 patch instead?

Thanks,

> 
> Thanks,
> 
>>
>> Thanks,

Re: [PATCH] include/linux/rtmutex.h: NOOP rt_mutex_destroy if !CONFIG_DEBUG_RT_MUTEXES

[Alex Goins]

Pinging in case this got buried.

Thanks,
Alex

Re: [PATCH] include/linux/rtmutex.h: NOOP rt_mutex_destroy if !CONFIG_DEBUG_RT_MUTEXES

[Alex Goins]

Pinging in case this got buried.

Thanks,
Alex

Re: [GIT PULL] overlayfs fixes for 4.9-rc3

[Linus Torvalds]

On Fri, Nov 4, 2016 at 2:30 AM, Miklos Szeredi  wrote:
>
> Also introduce the concept of feature flags to allow backward incompatible
> changes to the overlay format.  This should have been there from day one; the
> best we can do now is backport to stable kernels.  Add the check for features
> without adding any actual features yet.

No. I pulled the three other commits, but not that last one.

That feature just seems to actively *encourage* backwards incompatible
features. It's a bad idea. Don't do it. If we've been able to do
without it so far, then why should we suddenly start doing things like
this?

So I don't agree that it should have been there since day one, it just
shouldn't exist at all.

  Linus

Re: [GIT PULL] overlayfs fixes for 4.9-rc3

[Linus Torvalds]

On Fri, Nov 4, 2016 at 2:30 AM, Miklos Szeredi  wrote:
>
> Also introduce the concept of feature flags to allow backward incompatible
> changes to the overlay format.  This should have been there from day one; the
> best we can do now is backport to stable kernels.  Add the check for features
> without adding any actual features yet.

No. I pulled the three other commits, but not that last one.

That feature just seems to actively *encourage* backwards incompatible
features. It's a bad idea. Don't do it. If we've been able to do
without it so far, then why should we suddenly start doing things like
this?

So I don't agree that it should have been there since day one, it just
shouldn't exist at all.

  Linus

Re: [PATCH 1/3] tpm, tpm_vtpm_proxy: add kdoc comments for VTPM_PROXY_IOC_NEW_DEV

[Jarkko Sakkinen]

On Thu, Nov 03, 2016 at 05:57:50PM -0600, Jarkko Sakkinen wrote:
> Added kdoc comments for VTPM_PROXY_IOC_NEW_DEV so that these can be
> imported to the kernel documentation written with rst markup and
> generated with Sphinx.
> 
> Signed-off-by: Jarkko Sakkinen 

Stefan, is this OK? Are you willing to give Reviewed-by?

/Jarkko

> ---
>  drivers/char/tpm/tpm_vtpm_proxy.c | 72 
> +--
>  include/uapi/linux/vtpm_proxy.h   | 23 ++---
>  2 files changed, 65 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm_vtpm_proxy.c 
> b/drivers/char/tpm/tpm_vtpm_proxy.c
> index 9a94033..3d6f6ca 100644
> --- a/drivers/char/tpm/tpm_vtpm_proxy.c
> +++ b/drivers/char/tpm/tpm_vtpm_proxy.c
> @@ -1,5 +1,6 @@
>  /*
>   * Copyright (C) 2015, 2016 IBM Corporation
> + * Copyright (C) 2016 Intel Corporation
>   *
>   * Author: Stefan Berger 
>   *
> @@ -524,6 +525,50 @@ static void vtpm_proxy_delete_device(struct proxy_dev 
> *proxy_dev)
>   * Code related to the control device /dev/vtpmx
>   */
>  
> +/**
> + * vtpmx_ioc_new_dev - handler for the %VTPM_PROXY_IOC_NEW_DEV ioctl
> + * @file:/dev/vtpmx
> + * @ioctl:   the ioctl number
> + * @arg: pointer to the struct vtpmx_proxy_new_dev
> + *
> + * Creates an anonymous file that is used by the process acting as a TPM to
> + * communicate with the client processes. The function will also add a new 
> TPM
> + * device through which data is proxied to this TPM acting process. The 
> caller
> + * will be provided with a file descriptor to communicate with the clients 
> and
> + * major and minor numbers for the TPM device.
> + */
> +static long vtpmx_ioc_new_dev(struct file *file, unsigned int ioctl,
> +   unsigned long arg)
> +{
> + void __user *argp = (void __user *)arg;
> + struct vtpm_proxy_new_dev __user *vtpm_new_dev_p;
> + struct vtpm_proxy_new_dev vtpm_new_dev;
> + struct file *vtpm_file;
> +
> + if (!capable(CAP_SYS_ADMIN))
> + return -EPERM;
> +
> + vtpm_new_dev_p = argp;
> +
> + if (copy_from_user(_new_dev, vtpm_new_dev_p,
> +sizeof(vtpm_new_dev)))
> + return -EFAULT;
> +
> + vtpm_file = vtpm_proxy_create_device(_new_dev);
> + if (IS_ERR(vtpm_file))
> + return PTR_ERR(vtpm_file);
> +
> + if (copy_to_user(vtpm_new_dev_p, _new_dev,
> +  sizeof(vtpm_new_dev))) {
> + put_unused_fd(vtpm_new_dev.fd);
> + fput(vtpm_file);
> + return -EFAULT;
> + }
> +
> + fd_install(vtpm_new_dev.fd, vtpm_file);
> + return 0;
> +}
> +
>  /*
>   * vtpmx_fops_ioctl: ioctl on /dev/vtpmx
>   *
> @@ -531,34 +576,11 @@ static void vtpm_proxy_delete_device(struct proxy_dev 
> *proxy_dev)
>   *  Returns 0 on success, a negative error code otherwise.
>   */
>  static long vtpmx_fops_ioctl(struct file *f, unsigned int ioctl,
> -unsigned long arg)
> +  unsigned long arg)
>  {
> - void __user *argp = (void __user *)arg;
> - struct vtpm_proxy_new_dev __user *vtpm_new_dev_p;
> - struct vtpm_proxy_new_dev vtpm_new_dev;
> - struct file *file;
> -
>   switch (ioctl) {
>   case VTPM_PROXY_IOC_NEW_DEV:
> - if (!capable(CAP_SYS_ADMIN))
> - return -EPERM;
> - vtpm_new_dev_p = argp;
> - if (copy_from_user(_new_dev, vtpm_new_dev_p,
> -sizeof(vtpm_new_dev)))
> - return -EFAULT;
> - file = vtpm_proxy_create_device(_new_dev);
> - if (IS_ERR(file))
> - return PTR_ERR(file);
> - if (copy_to_user(vtpm_new_dev_p, _new_dev,
> -  sizeof(vtpm_new_dev))) {
> - put_unused_fd(vtpm_new_dev.fd);
> - fput(file);
> - return -EFAULT;
> - }
> -
> - fd_install(vtpm_new_dev.fd, file);
> - return 0;
> -
> + return vtpmx_ioc_new_dev(f, ioctl, arg);
>   default:
>   return -ENOIOCTLCMD;
>   }
> diff --git a/include/uapi/linux/vtpm_proxy.h b/include/uapi/linux/vtpm_proxy.h
> index 41e8e22..a69e991 100644
> --- a/include/uapi/linux/vtpm_proxy.h
> +++ b/include/uapi/linux/vtpm_proxy.h
> @@ -1,6 +1,7 @@
>  /*
>   * Definitions for the VTPM proxy driver
>   * Copyright (c) 2015, 2016, IBM Corporation
> + * Copyright (C) 2016 Intel Corporation
>   *
>   * This program is free software; you can redistribute it and/or modify it
>   * under the terms and conditions of the GNU General Public License,
> @@ -18,8 +19,23 @@
>  #include 
>  #include 
>  
> -/* ioctls */
> +/**
> + * enum vtpm_proxy_flags - flags for the proxy TPM
> + * @VTPM_PROXY_FLAG_TPM2:the proxy TPM uses TPM 2.0 protocol
> + */
> +enum vtpm_proxy_flags {
> + 

Re: [PATCH 1/3] tpm, tpm_vtpm_proxy: add kdoc comments for VTPM_PROXY_IOC_NEW_DEV

[Jarkko Sakkinen]

On Thu, Nov 03, 2016 at 05:57:50PM -0600, Jarkko Sakkinen wrote:
> Added kdoc comments for VTPM_PROXY_IOC_NEW_DEV so that these can be
> imported to the kernel documentation written with rst markup and
> generated with Sphinx.
> 
> Signed-off-by: Jarkko Sakkinen 

Stefan, is this OK? Are you willing to give Reviewed-by?

/Jarkko

> ---
>  drivers/char/tpm/tpm_vtpm_proxy.c | 72 
> +--
>  include/uapi/linux/vtpm_proxy.h   | 23 ++---
>  2 files changed, 65 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm_vtpm_proxy.c 
> b/drivers/char/tpm/tpm_vtpm_proxy.c
> index 9a94033..3d6f6ca 100644
> --- a/drivers/char/tpm/tpm_vtpm_proxy.c
> +++ b/drivers/char/tpm/tpm_vtpm_proxy.c
> @@ -1,5 +1,6 @@
>  /*
>   * Copyright (C) 2015, 2016 IBM Corporation
> + * Copyright (C) 2016 Intel Corporation
>   *
>   * Author: Stefan Berger 
>   *
> @@ -524,6 +525,50 @@ static void vtpm_proxy_delete_device(struct proxy_dev 
> *proxy_dev)
>   * Code related to the control device /dev/vtpmx
>   */
>  
> +/**
> + * vtpmx_ioc_new_dev - handler for the %VTPM_PROXY_IOC_NEW_DEV ioctl
> + * @file:/dev/vtpmx
> + * @ioctl:   the ioctl number
> + * @arg: pointer to the struct vtpmx_proxy_new_dev
> + *
> + * Creates an anonymous file that is used by the process acting as a TPM to
> + * communicate with the client processes. The function will also add a new 
> TPM
> + * device through which data is proxied to this TPM acting process. The 
> caller
> + * will be provided with a file descriptor to communicate with the clients 
> and
> + * major and minor numbers for the TPM device.
> + */
> +static long vtpmx_ioc_new_dev(struct file *file, unsigned int ioctl,
> +   unsigned long arg)
> +{
> + void __user *argp = (void __user *)arg;
> + struct vtpm_proxy_new_dev __user *vtpm_new_dev_p;
> + struct vtpm_proxy_new_dev vtpm_new_dev;
> + struct file *vtpm_file;
> +
> + if (!capable(CAP_SYS_ADMIN))
> + return -EPERM;
> +
> + vtpm_new_dev_p = argp;
> +
> + if (copy_from_user(_new_dev, vtpm_new_dev_p,
> +sizeof(vtpm_new_dev)))
> + return -EFAULT;
> +
> + vtpm_file = vtpm_proxy_create_device(_new_dev);
> + if (IS_ERR(vtpm_file))
> + return PTR_ERR(vtpm_file);
> +
> + if (copy_to_user(vtpm_new_dev_p, _new_dev,
> +  sizeof(vtpm_new_dev))) {
> + put_unused_fd(vtpm_new_dev.fd);
> + fput(vtpm_file);
> + return -EFAULT;
> + }
> +
> + fd_install(vtpm_new_dev.fd, vtpm_file);
> + return 0;
> +}
> +
>  /*
>   * vtpmx_fops_ioctl: ioctl on /dev/vtpmx
>   *
> @@ -531,34 +576,11 @@ static void vtpm_proxy_delete_device(struct proxy_dev 
> *proxy_dev)
>   *  Returns 0 on success, a negative error code otherwise.
>   */
>  static long vtpmx_fops_ioctl(struct file *f, unsigned int ioctl,
> -unsigned long arg)
> +  unsigned long arg)
>  {
> - void __user *argp = (void __user *)arg;
> - struct vtpm_proxy_new_dev __user *vtpm_new_dev_p;
> - struct vtpm_proxy_new_dev vtpm_new_dev;
> - struct file *file;
> -
>   switch (ioctl) {
>   case VTPM_PROXY_IOC_NEW_DEV:
> - if (!capable(CAP_SYS_ADMIN))
> - return -EPERM;
> - vtpm_new_dev_p = argp;
> - if (copy_from_user(_new_dev, vtpm_new_dev_p,
> -sizeof(vtpm_new_dev)))
> - return -EFAULT;
> - file = vtpm_proxy_create_device(_new_dev);
> - if (IS_ERR(file))
> - return PTR_ERR(file);
> - if (copy_to_user(vtpm_new_dev_p, _new_dev,
> -  sizeof(vtpm_new_dev))) {
> - put_unused_fd(vtpm_new_dev.fd);
> - fput(file);
> - return -EFAULT;
> - }
> -
> - fd_install(vtpm_new_dev.fd, file);
> - return 0;
> -
> + return vtpmx_ioc_new_dev(f, ioctl, arg);
>   default:
>   return -ENOIOCTLCMD;
>   }
> diff --git a/include/uapi/linux/vtpm_proxy.h b/include/uapi/linux/vtpm_proxy.h
> index 41e8e22..a69e991 100644
> --- a/include/uapi/linux/vtpm_proxy.h
> +++ b/include/uapi/linux/vtpm_proxy.h
> @@ -1,6 +1,7 @@
>  /*
>   * Definitions for the VTPM proxy driver
>   * Copyright (c) 2015, 2016, IBM Corporation
> + * Copyright (C) 2016 Intel Corporation
>   *
>   * This program is free software; you can redistribute it and/or modify it
>   * under the terms and conditions of the GNU General Public License,
> @@ -18,8 +19,23 @@
>  #include 
>  #include 
>  
> -/* ioctls */
> +/**
> + * enum vtpm_proxy_flags - flags for the proxy TPM
> + * @VTPM_PROXY_FLAG_TPM2:the proxy TPM uses TPM 2.0 protocol
> + */
> +enum vtpm_proxy_flags {
> + VTPM_PROXY_FLAG_TPM2= 1,
> +};
>  
> +/**
> + * struct 

Re: [PATCH 2/3] tpm: transition tpm_vtpm_proxy documentation to the Sphinx

[Jarkko Sakkinen]

On Thu, Nov 03, 2016 at 05:57:51PM -0600, Jarkko Sakkinen wrote:
> Transitioned the tpm_vtpm_proxy documentation to the Sphinx
> infrastructure and removed parts from the documentation that are easier
> to pull from the sources. Restructured vtpm_proxy.h and tpm_vtpm_proxy.c
> to be compatible with this approach and wrote associated documentation
> comments.
> 
> Signed-off-by: Jarkko Sakkinen 

Stefan?

/Jarkko

> ---
>  Documentation/index.rst|  1 +
>  Documentation/tpm/index.rst|  7 +++
>  .../tpm/{tpm_vtpm_proxy.txt => tpm_vtpm_proxy.rst} | 55 
> +++---
>  3 files changed, 25 insertions(+), 38 deletions(-)
>  create mode 100644 Documentation/tpm/index.rst
>  rename Documentation/tpm/{tpm_vtpm_proxy.txt => tpm_vtpm_proxy.rst} (53%)
> 
> diff --git a/Documentation/index.rst b/Documentation/index.rst
> index e0fc729..0058b65 100644
> --- a/Documentation/index.rst
> +++ b/Documentation/index.rst
> @@ -19,6 +19,7 @@ Contents:
> media/dvb-drivers/index
> media/v4l-drivers/index
> gpu/index
> +   tpm/index
>  
>  Indices and tables
>  ==
> diff --git a/Documentation/tpm/index.rst b/Documentation/tpm/index.rst
> new file mode 100644
> index 000..af77a7b
> --- /dev/null
> +++ b/Documentation/tpm/index.rst
> @@ -0,0 +1,7 @@
> +=
> +Trusted Platform Module documentation
> +=
> +
> +.. toctree::
> +
> +   tpm_vtpm_proxy
> diff --git a/Documentation/tpm/tpm_vtpm_proxy.txt 
> b/Documentation/tpm/tpm_vtpm_proxy.rst
> similarity index 53%
> rename from Documentation/tpm/tpm_vtpm_proxy.txt
> rename to Documentation/tpm/tpm_vtpm_proxy.rst
> index 30d1902..ea08e76 100644
> --- a/Documentation/tpm/tpm_vtpm_proxy.txt
> +++ b/Documentation/tpm/tpm_vtpm_proxy.rst
> @@ -1,71 +1,50 @@
> +=
>  Virtual TPM Proxy Driver for Linux Containers
> +=
>  
> -Authors: Stefan Berger (IBM)
> +| Authors:
> +| Stefan Berger 
>  
>  This document describes the virtual Trusted Platform Module (vTPM)
>  proxy device driver for Linux containers.
>  
> -INTRODUCTION
> -
> +Introduction
> +
>  
>  The goal of this work is to provide TPM functionality to each Linux
>  container. This allows programs to interact with a TPM in a container
>  the same way they interact with a TPM on the physical system. Each
>  container gets its own unique, emulated, software TPM.
>  
> -
> -DESIGN
> ---
> +Design
> +==
>  
>  To make an emulated software TPM available to each container, the container
>  management stack needs to create a device pair consisting of a client TPM
> -character device /dev/tpmX (with X=0,1,2...) and a 'server side' file
> +character device ``/dev/tpmX`` (with X=0,1,2...) and a 'server side' file
>  descriptor. The former is moved into the container by creating a character
>  device with the appropriate major and minor numbers while the file descriptor
>  is passed to the TPM emulator. Software inside the container can then send
>  TPM commands using the character device and the emulator will receive the
>  commands via the file descriptor and use it for sending back responses.
>  
> -To support this, the virtual TPM proxy driver provides a device /dev/vtpmx
> +To support this, the virtual TPM proxy driver provides a device 
> ``/dev/vtpmx``
>  that is used to create device pairs using an ioctl. The ioctl takes as
>  an input flags for configuring the device. The flags  for example indicate
>  whether TPM 1.2 or TPM 2 functionality is supported by the TPM emulator.
>  The result of the ioctl are the file descriptor for the 'server side'
>  as well as the major and minor numbers of the character device that was 
> created.
> -Besides that the number of the TPM character device is return. If for
> -example /dev/tpm10 was created, the number (dev_num) 10 is returned.
> -
> -The following is the data structure of the TPM_PROXY_IOC_NEW_DEV ioctl:
> -
> -struct vtpm_proxy_new_dev {
> - __u32 flags; /* input */
> - __u32 tpm_num;   /* output */
> - __u32 fd;/* output */
> - __u32 major; /* output */
> - __u32 minor; /* output */
> -};
> -
> -Note that if unsupported flags are passed to the device driver, the ioctl 
> will
> -fail and errno will be set to EOPNOTSUPP. Similarly, if an unsupported ioctl 
> is
> -called on the device driver, the ioctl will fail and errno will be set to
> -ENOTTY.
> -
> -See /usr/include/linux/vtpm_proxy.h for definitions related to the public 
> interface
> -of this vTPM device driver.
> +Besides that the number of the TPM character device is returned. If for
> +example ``/dev/tpm10`` was created, the number (``dev_num``) 10 is returned.
>  
>  Once the device has been created, the driver will immediately try 

Re: [PATCH 2/3] tpm: transition tpm_vtpm_proxy documentation to the Sphinx

[Jarkko Sakkinen]

On Thu, Nov 03, 2016 at 05:57:51PM -0600, Jarkko Sakkinen wrote:
> Transitioned the tpm_vtpm_proxy documentation to the Sphinx
> infrastructure and removed parts from the documentation that are easier
> to pull from the sources. Restructured vtpm_proxy.h and tpm_vtpm_proxy.c
> to be compatible with this approach and wrote associated documentation
> comments.
> 
> Signed-off-by: Jarkko Sakkinen 

Stefan?

/Jarkko

> ---
>  Documentation/index.rst|  1 +
>  Documentation/tpm/index.rst|  7 +++
>  .../tpm/{tpm_vtpm_proxy.txt => tpm_vtpm_proxy.rst} | 55 
> +++---
>  3 files changed, 25 insertions(+), 38 deletions(-)
>  create mode 100644 Documentation/tpm/index.rst
>  rename Documentation/tpm/{tpm_vtpm_proxy.txt => tpm_vtpm_proxy.rst} (53%)
> 
> diff --git a/Documentation/index.rst b/Documentation/index.rst
> index e0fc729..0058b65 100644
> --- a/Documentation/index.rst
> +++ b/Documentation/index.rst
> @@ -19,6 +19,7 @@ Contents:
> media/dvb-drivers/index
> media/v4l-drivers/index
> gpu/index
> +   tpm/index
>  
>  Indices and tables
>  ==
> diff --git a/Documentation/tpm/index.rst b/Documentation/tpm/index.rst
> new file mode 100644
> index 000..af77a7b
> --- /dev/null
> +++ b/Documentation/tpm/index.rst
> @@ -0,0 +1,7 @@
> +=
> +Trusted Platform Module documentation
> +=
> +
> +.. toctree::
> +
> +   tpm_vtpm_proxy
> diff --git a/Documentation/tpm/tpm_vtpm_proxy.txt 
> b/Documentation/tpm/tpm_vtpm_proxy.rst
> similarity index 53%
> rename from Documentation/tpm/tpm_vtpm_proxy.txt
> rename to Documentation/tpm/tpm_vtpm_proxy.rst
> index 30d1902..ea08e76 100644
> --- a/Documentation/tpm/tpm_vtpm_proxy.txt
> +++ b/Documentation/tpm/tpm_vtpm_proxy.rst
> @@ -1,71 +1,50 @@
> +=
>  Virtual TPM Proxy Driver for Linux Containers
> +=
>  
> -Authors: Stefan Berger (IBM)
> +| Authors:
> +| Stefan Berger 
>  
>  This document describes the virtual Trusted Platform Module (vTPM)
>  proxy device driver for Linux containers.
>  
> -INTRODUCTION
> -
> +Introduction
> +
>  
>  The goal of this work is to provide TPM functionality to each Linux
>  container. This allows programs to interact with a TPM in a container
>  the same way they interact with a TPM on the physical system. Each
>  container gets its own unique, emulated, software TPM.
>  
> -
> -DESIGN
> ---
> +Design
> +==
>  
>  To make an emulated software TPM available to each container, the container
>  management stack needs to create a device pair consisting of a client TPM
> -character device /dev/tpmX (with X=0,1,2...) and a 'server side' file
> +character device ``/dev/tpmX`` (with X=0,1,2...) and a 'server side' file
>  descriptor. The former is moved into the container by creating a character
>  device with the appropriate major and minor numbers while the file descriptor
>  is passed to the TPM emulator. Software inside the container can then send
>  TPM commands using the character device and the emulator will receive the
>  commands via the file descriptor and use it for sending back responses.
>  
> -To support this, the virtual TPM proxy driver provides a device /dev/vtpmx
> +To support this, the virtual TPM proxy driver provides a device 
> ``/dev/vtpmx``
>  that is used to create device pairs using an ioctl. The ioctl takes as
>  an input flags for configuring the device. The flags  for example indicate
>  whether TPM 1.2 or TPM 2 functionality is supported by the TPM emulator.
>  The result of the ioctl are the file descriptor for the 'server side'
>  as well as the major and minor numbers of the character device that was 
> created.
> -Besides that the number of the TPM character device is return. If for
> -example /dev/tpm10 was created, the number (dev_num) 10 is returned.
> -
> -The following is the data structure of the TPM_PROXY_IOC_NEW_DEV ioctl:
> -
> -struct vtpm_proxy_new_dev {
> - __u32 flags; /* input */
> - __u32 tpm_num;   /* output */
> - __u32 fd;/* output */
> - __u32 major; /* output */
> - __u32 minor; /* output */
> -};
> -
> -Note that if unsupported flags are passed to the device driver, the ioctl 
> will
> -fail and errno will be set to EOPNOTSUPP. Similarly, if an unsupported ioctl 
> is
> -called on the device driver, the ioctl will fail and errno will be set to
> -ENOTTY.
> -
> -See /usr/include/linux/vtpm_proxy.h for definitions related to the public 
> interface
> -of this vTPM device driver.
> +Besides that the number of the TPM character device is returned. If for
> +example ``/dev/tpm10`` was created, the number (``dev_num``) 10 is returned.
>  
>  Once the device has been created, the driver will immediately try to talk
>  to the TPM. All commands from the driver can be 

Re: [PATCH v2 1/2] phy: rockchip-inno-usb2: support otg-port for rk3399

[wlf]

Hi Kishon,

在 2016年11月04日 01:17, Kishon Vijay Abraham I 写道:


On Thursday 03 November 2016 07:36 AM, William Wu wrote:

The rk3399 SoC USB2 PHY is comprised of one Host port and
one OTG port. And OTG port is for USB2.0 part of USB3.0 OTG
controller, as a part to construct a fully feature Type-C
subsystem.

With this patch, we can support OTG port with the following
functions:
- Support BC1.2 charger detect, and use extcon notifier to
   send USB charger types to power driver.
- Support PHY suspend for power management.
- Support OTG Host only mode.

Also, correct 480MHz output clock stable time. We found that
the system crashed due to 480MHz output clock of USB2 PHY was
unstable after clock had been enabled by gpu module.

Can you split the clock fix into a separate patch?

OK, I will separate the clock patch in next version.

Best regards,
 wulf


Thanks
Kishon

Theoretically, 1 millisecond is a critical value for 480 output
clock stable time, so we try changing the delay time to 1.2
millisecond to avoid this issue.

Signed-off-by: William Wu 
---
Changes in v2:
- remove wakelock

  drivers/phy/phy-rockchip-inno-usb2.c | 593 +--
  1 file changed, 562 insertions(+), 31 deletions(-)

diff --git a/drivers/phy/phy-rockchip-inno-usb2.c 
b/drivers/phy/phy-rockchip-inno-usb2.c
index ac20310..8f2d2b6 100644
--- a/drivers/phy/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/phy-rockchip-inno-usb2.c
@@ -17,6 +17,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -30,11 +31,15 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
+#include 
+#include 
  
  #define BIT_WRITEABLE_SHIFT	16

-#define SCHEDULE_DELAY (60 * HZ)
+#define SCHEDULE_DELAY (60 * HZ)
+#define OTG_SCHEDULE_DELAY (2 * HZ)
  
  enum rockchip_usb2phy_port_id {

USB2PHY_PORT_OTG,
@@ -49,6 +54,37 @@ enum rockchip_usb2phy_host_state {
PHY_STATE_FS_LS_ONLINE  = 4,
  };
  
+/**

+ * Different states involved in USB charger detection.
+ * USB_CHG_STATE_UNDEFINED USB charger is not connected or detection
+ * process is not yet started.
+ * USB_CHG_STATE_WAIT_FOR_DCD  Waiting for Data pins contact.
+ * USB_CHG_STATE_DCD_DONE  Data pin contact is detected.
+ * USB_CHG_STATE_PRIMARY_DONE  Primary detection is completed (Detects
+ * between SDP and DCP/CDP).
+ * USB_CHG_STATE_SECONDARY_DONESecondary detection is completed 
(Detects
+ * between DCP and CDP).
+ * USB_CHG_STATE_DETECTED  USB charger type is determined.
+ */
+enum usb_chg_state {
+   USB_CHG_STATE_UNDEFINED = 0,
+   USB_CHG_STATE_WAIT_FOR_DCD,
+   USB_CHG_STATE_DCD_DONE,
+   USB_CHG_STATE_PRIMARY_DONE,
+   USB_CHG_STATE_SECONDARY_DONE,
+   USB_CHG_STATE_DETECTED,
+};
+
+static const unsigned int rockchip_usb2phy_extcon_cable[] = {
+   EXTCON_USB,
+   EXTCON_USB_HOST,
+   EXTCON_CHG_USB_SDP,
+   EXTCON_CHG_USB_CDP,
+   EXTCON_CHG_USB_DCP,
+   EXTCON_CHG_USB_SLOW,
+   EXTCON_NONE,
+};
+
  struct usb2phy_reg {
unsigned intoffset;
unsigned intbitend;
@@ -58,19 +94,55 @@ struct usb2phy_reg {
  };
  
  /**

+ * struct rockchip_chg_det_reg: usb charger detect registers
+ * @cp_det: charging port detected successfully.
+ * @dcp_det: dedicated charging port detected successfully.
+ * @dp_det: assert data pin connect successfully.
+ * @idm_sink_en: open dm sink curren.
+ * @idp_sink_en: open dp sink current.
+ * @idp_src_en: open dm source current.
+ * @rdm_pdwn_en: open dm pull down resistor.
+ * @vdm_src_en: open dm voltage source.
+ * @vdp_src_en: open dp voltage source.
+ * @opmode: utmi operational mode.
+ */
+struct rockchip_chg_det_reg {
+   struct usb2phy_reg  cp_det;
+   struct usb2phy_reg  dcp_det;
+   struct usb2phy_reg  dp_det;
+   struct usb2phy_reg  idm_sink_en;
+   struct usb2phy_reg  idp_sink_en;
+   struct usb2phy_reg  idp_src_en;
+   struct usb2phy_reg  rdm_pdwn_en;
+   struct usb2phy_reg  vdm_src_en;
+   struct usb2phy_reg  vdp_src_en;
+   struct usb2phy_reg  opmode;
+};
+
+/**
   * struct rockchip_usb2phy_port_cfg: usb-phy port configuration.
   * @phy_sus: phy suspend register.
+ * @bvalid_det_en: vbus valid rise detection enable register.
+ * @bvalid_det_st: vbus valid rise detection status register.
+ * @bvalid_det_clr: vbus valid rise detection clear register.
   * @ls_det_en: linestate detection enable register.
   * @ls_det_st: linestate detection state register.
   * @ls_det_clr: linestate detection clear register.
+ * @utmi_avalid: utmi vbus avalid status register.
+ * @utmi_bvalid: utmi vbus bvalid status register.
   * @utmi_ls: utmi linestate state register.
   * @utmi_hstdet: utmi host disconnect register.
   */
  struct rockchip_usb2phy_port_cfg {
struct usb2phy_reg 

Re: [PATCH v2 1/2] phy: rockchip-inno-usb2: support otg-port for rk3399

[wlf]

Hi Kishon,

在 2016年11月04日 01:17, Kishon Vijay Abraham I 写道:


On Thursday 03 November 2016 07:36 AM, William Wu wrote:

The rk3399 SoC USB2 PHY is comprised of one Host port and
one OTG port. And OTG port is for USB2.0 part of USB3.0 OTG
controller, as a part to construct a fully feature Type-C
subsystem.

With this patch, we can support OTG port with the following
functions:
- Support BC1.2 charger detect, and use extcon notifier to
   send USB charger types to power driver.
- Support PHY suspend for power management.
- Support OTG Host only mode.

Also, correct 480MHz output clock stable time. We found that
the system crashed due to 480MHz output clock of USB2 PHY was
unstable after clock had been enabled by gpu module.

Can you split the clock fix into a separate patch?

OK, I will separate the clock patch in next version.

Best regards,
 wulf


Thanks
Kishon

Theoretically, 1 millisecond is a critical value for 480 output
clock stable time, so we try changing the delay time to 1.2
millisecond to avoid this issue.

Signed-off-by: William Wu 
---
Changes in v2:
- remove wakelock

  drivers/phy/phy-rockchip-inno-usb2.c | 593 +--
  1 file changed, 562 insertions(+), 31 deletions(-)

diff --git a/drivers/phy/phy-rockchip-inno-usb2.c 
b/drivers/phy/phy-rockchip-inno-usb2.c
index ac20310..8f2d2b6 100644
--- a/drivers/phy/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/phy-rockchip-inno-usb2.c
@@ -17,6 +17,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -30,11 +31,15 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
+#include 
+#include 
  
  #define BIT_WRITEABLE_SHIFT	16

-#define SCHEDULE_DELAY (60 * HZ)
+#define SCHEDULE_DELAY (60 * HZ)
+#define OTG_SCHEDULE_DELAY (2 * HZ)
  
  enum rockchip_usb2phy_port_id {

USB2PHY_PORT_OTG,
@@ -49,6 +54,37 @@ enum rockchip_usb2phy_host_state {
PHY_STATE_FS_LS_ONLINE  = 4,
  };
  
+/**

+ * Different states involved in USB charger detection.
+ * USB_CHG_STATE_UNDEFINED USB charger is not connected or detection
+ * process is not yet started.
+ * USB_CHG_STATE_WAIT_FOR_DCD  Waiting for Data pins contact.
+ * USB_CHG_STATE_DCD_DONE  Data pin contact is detected.
+ * USB_CHG_STATE_PRIMARY_DONE  Primary detection is completed (Detects
+ * between SDP and DCP/CDP).
+ * USB_CHG_STATE_SECONDARY_DONESecondary detection is completed 
(Detects
+ * between DCP and CDP).
+ * USB_CHG_STATE_DETECTED  USB charger type is determined.
+ */
+enum usb_chg_state {
+   USB_CHG_STATE_UNDEFINED = 0,
+   USB_CHG_STATE_WAIT_FOR_DCD,
+   USB_CHG_STATE_DCD_DONE,
+   USB_CHG_STATE_PRIMARY_DONE,
+   USB_CHG_STATE_SECONDARY_DONE,
+   USB_CHG_STATE_DETECTED,
+};
+
+static const unsigned int rockchip_usb2phy_extcon_cable[] = {
+   EXTCON_USB,
+   EXTCON_USB_HOST,
+   EXTCON_CHG_USB_SDP,
+   EXTCON_CHG_USB_CDP,
+   EXTCON_CHG_USB_DCP,
+   EXTCON_CHG_USB_SLOW,
+   EXTCON_NONE,
+};
+
  struct usb2phy_reg {
unsigned intoffset;
unsigned intbitend;
@@ -58,19 +94,55 @@ struct usb2phy_reg {
  };
  
  /**

+ * struct rockchip_chg_det_reg: usb charger detect registers
+ * @cp_det: charging port detected successfully.
+ * @dcp_det: dedicated charging port detected successfully.
+ * @dp_det: assert data pin connect successfully.
+ * @idm_sink_en: open dm sink curren.
+ * @idp_sink_en: open dp sink current.
+ * @idp_src_en: open dm source current.
+ * @rdm_pdwn_en: open dm pull down resistor.
+ * @vdm_src_en: open dm voltage source.
+ * @vdp_src_en: open dp voltage source.
+ * @opmode: utmi operational mode.
+ */
+struct rockchip_chg_det_reg {
+   struct usb2phy_reg  cp_det;
+   struct usb2phy_reg  dcp_det;
+   struct usb2phy_reg  dp_det;
+   struct usb2phy_reg  idm_sink_en;
+   struct usb2phy_reg  idp_sink_en;
+   struct usb2phy_reg  idp_src_en;
+   struct usb2phy_reg  rdm_pdwn_en;
+   struct usb2phy_reg  vdm_src_en;
+   struct usb2phy_reg  vdp_src_en;
+   struct usb2phy_reg  opmode;
+};
+
+/**
   * struct rockchip_usb2phy_port_cfg: usb-phy port configuration.
   * @phy_sus: phy suspend register.
+ * @bvalid_det_en: vbus valid rise detection enable register.
+ * @bvalid_det_st: vbus valid rise detection status register.
+ * @bvalid_det_clr: vbus valid rise detection clear register.
   * @ls_det_en: linestate detection enable register.
   * @ls_det_st: linestate detection state register.
   * @ls_det_clr: linestate detection clear register.
+ * @utmi_avalid: utmi vbus avalid status register.
+ * @utmi_bvalid: utmi vbus bvalid status register.
   * @utmi_ls: utmi linestate state register.
   * @utmi_hstdet: utmi host disconnect register.
   */
  struct rockchip_usb2phy_port_cfg {
struct usb2phy_reg  phy_sus;
+   

Re: [PATCH 0/3] Add memremap executable mapping and extend drivers/misc/sram.c

[Alexandre Belloni]

Hi,

On 27/10/2016 at 13:56:09 -0500, Dave Gerlach wrote :
> There are several instances when one would want to execute out of on-chip
> SRAM, such as PM code on ARM platforms, so once again revisiting this
> series to allow that in a generic manner. Seems that having a solution for
> allowing SRAM to be mapped as executable will help clean up PM code on several
> ARM platforms that are using ARM internal __arm_ioremap_exec API
> and also open the door for PM support on new platforms like TI AM335x and
> AM437x. This was last sent as RFC here [1] and based on comments from Russell
> King and Arnd Bergmann has been rewritten to use memremap API rather than
> ioremap API, as executable iomem does not really make sense.
> 
> I still see several platforms (at-91, imx6, socfpga) that could make use
> of this and use the generic sram driver to allocate the SRAM needed for PM.
> This series allows direct allocation of SRAM using the generic SRAM driver
> that will be already mapped as executable. Otherwise platform SRAM allocation
> code must be used or if the generic sram driver is used as-is the memory
> must be remapped as executable after it has been mapped normally by the
> SRAM driver.
> 

Rockchip also actually needs that.

> I had sent omap3 series to convert from using old omap sram platform
> mapping code to using the generic sram driver instead here [2] which was
> based on previous RFC but can easily be rebased on this updated series.
> Finally, forthcoming TI am335x and am437x PM code must make use of
> it as well, as portions of PM code are moving in to drivers.
> 
> Changes from the RFC include:
> 
> - Rather than introduce ioremap_exec API, use memremap API, as the concept
>   of executable iomem does not make sense; any memory that can used to
>   run code should not have io side effects like iomem.
> - Rather than having a fallback mapping if a platform does not support
>   exec mappings under the memremap API, have the mapping fail, as if you
>   are mapping memory as exec, presumably you will then try to run code
>   from it which will fail anyway, so it makes more sense to prevent the
>   mapping in the first place.
> - Update sram driver to use memremap rather than ioremap for exec flags.
> 
> Regards,
> Dave
> 
> [1] http://www.spinics.net/lists/arm-kernel/msg503071.html
> [2] http://www.spinics.net/lists/linux-omap/msg128753.html
> 
> Dave Gerlach (3):
>   ARM: memremap: implement arch_memremap_exec/exec_nocache
>   memremap: add MEMREMAP_EXEC and MEMREMAP_EXEC_NOCACHE flags
>   misc: SRAM: Add option to map SRAM to allow code execution
> 
>  Documentation/devicetree/bindings/sram/sram.txt |  2 ++
>  arch/arm/include/asm/io.h   |  5 
>  arch/arm/mm/ioremap.c   | 16 
>  arch/arm/mm/nommu.c | 12 +
>  drivers/misc/sram.c |  7 +
>  include/linux/io.h  |  2 ++
>  kernel/memremap.c   | 34 
> -
>  7 files changed, 77 insertions(+), 1 deletion(-)
> 

To the whole series:
Tested-by: Alexandre Belloni 



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

Re: [PATCH 0/3] Add memremap executable mapping and extend drivers/misc/sram.c

[Alexandre Belloni]

Hi,

On 27/10/2016 at 13:56:09 -0500, Dave Gerlach wrote :
> There are several instances when one would want to execute out of on-chip
> SRAM, such as PM code on ARM platforms, so once again revisiting this
> series to allow that in a generic manner. Seems that having a solution for
> allowing SRAM to be mapped as executable will help clean up PM code on several
> ARM platforms that are using ARM internal __arm_ioremap_exec API
> and also open the door for PM support on new platforms like TI AM335x and
> AM437x. This was last sent as RFC here [1] and based on comments from Russell
> King and Arnd Bergmann has been rewritten to use memremap API rather than
> ioremap API, as executable iomem does not really make sense.
> 
> I still see several platforms (at-91, imx6, socfpga) that could make use
> of this and use the generic sram driver to allocate the SRAM needed for PM.
> This series allows direct allocation of SRAM using the generic SRAM driver
> that will be already mapped as executable. Otherwise platform SRAM allocation
> code must be used or if the generic sram driver is used as-is the memory
> must be remapped as executable after it has been mapped normally by the
> SRAM driver.
> 

Rockchip also actually needs that.

> I had sent omap3 series to convert from using old omap sram platform
> mapping code to using the generic sram driver instead here [2] which was
> based on previous RFC but can easily be rebased on this updated series.
> Finally, forthcoming TI am335x and am437x PM code must make use of
> it as well, as portions of PM code are moving in to drivers.
> 
> Changes from the RFC include:
> 
> - Rather than introduce ioremap_exec API, use memremap API, as the concept
>   of executable iomem does not make sense; any memory that can used to
>   run code should not have io side effects like iomem.
> - Rather than having a fallback mapping if a platform does not support
>   exec mappings under the memremap API, have the mapping fail, as if you
>   are mapping memory as exec, presumably you will then try to run code
>   from it which will fail anyway, so it makes more sense to prevent the
>   mapping in the first place.
> - Update sram driver to use memremap rather than ioremap for exec flags.
> 
> Regards,
> Dave
> 
> [1] http://www.spinics.net/lists/arm-kernel/msg503071.html
> [2] http://www.spinics.net/lists/linux-omap/msg128753.html
> 
> Dave Gerlach (3):
>   ARM: memremap: implement arch_memremap_exec/exec_nocache
>   memremap: add MEMREMAP_EXEC and MEMREMAP_EXEC_NOCACHE flags
>   misc: SRAM: Add option to map SRAM to allow code execution
> 
>  Documentation/devicetree/bindings/sram/sram.txt |  2 ++
>  arch/arm/include/asm/io.h   |  5 
>  arch/arm/mm/ioremap.c   | 16 
>  arch/arm/mm/nommu.c | 12 +
>  drivers/misc/sram.c |  7 +
>  include/linux/io.h  |  2 ++
>  kernel/memremap.c   | 34 
> -
>  7 files changed, 77 insertions(+), 1 deletion(-)
> 

To the whole series:
Tested-by: Alexandre Belloni 



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

Re: [f2fs-dev] [PATCH 3/3 v2] f2fs: keep dirty inodes selectively for checkpoint

[Chao Yu]

On 2016/10/20 10:26, Jaegeuk Kim wrote:
> Change log from v1:
>  o avoid performance regression
> 
>>From b34a3d3c4c3fa2d6e000acc99bc5216a247bd6cb Mon Sep 17 00:00:00 2001
> From: Jaegeuk Kim 
> Date: Fri, 14 Oct 2016 11:51:23 -0700
> Subject: [PATCH] f2fs: keep dirty inodes selectively for checkpoint
> 
> This is to avoid no free segment bug during checkpoint caused by a number of
> dirty inodes.
> 
> The case was reported by Chao like this.
> 
> 1. mount with lazytime option
> 2. fragment space
> 3. touch all files in the image
> 4. umount
> 
> In this case, we actually don't need to flush dirty inode to inode page during
> checkpoint.
> 
> Reported-by: Chao Yu 
> Signed-off-by: Jaegeuk Kim 

Good job! IMO, main job of checkpoint is to keep filesystem being consistent,
not flush dirty datas of vfs/fs as much as possible, if there are some
restrictions for the interface like fsync, syncfs, sync, the caller of
checkpoint() should do related job like marking lazytime inode I_DIRTY_SYNC or
flush last data in dirty inode into filesystem's cache, and so on. :)

BTW, can you change commit log a bit as below:

1. mount with lazytime option
2. fill 4k file until disk is full
3. sync filesystem
4. read all files in the image
5. umount

Reviewed-by: Chao Yu 

Thanks,

Re: [f2fs-dev] [PATCH 3/3 v2] f2fs: keep dirty inodes selectively for checkpoint

[Chao Yu]

On 2016/10/20 10:26, Jaegeuk Kim wrote:
> Change log from v1:
>  o avoid performance regression
> 
>>From b34a3d3c4c3fa2d6e000acc99bc5216a247bd6cb Mon Sep 17 00:00:00 2001
> From: Jaegeuk Kim 
> Date: Fri, 14 Oct 2016 11:51:23 -0700
> Subject: [PATCH] f2fs: keep dirty inodes selectively for checkpoint
> 
> This is to avoid no free segment bug during checkpoint caused by a number of
> dirty inodes.
> 
> The case was reported by Chao like this.
> 
> 1. mount with lazytime option
> 2. fragment space
> 3. touch all files in the image
> 4. umount
> 
> In this case, we actually don't need to flush dirty inode to inode page during
> checkpoint.
> 
> Reported-by: Chao Yu 
> Signed-off-by: Jaegeuk Kim 

Good job! IMO, main job of checkpoint is to keep filesystem being consistent,
not flush dirty datas of vfs/fs as much as possible, if there are some
restrictions for the interface like fsync, syncfs, sync, the caller of
checkpoint() should do related job like marking lazytime inode I_DIRTY_SYNC or
flush last data in dirty inode into filesystem's cache, and so on. :)

BTW, can you change commit log a bit as below:

1. mount with lazytime option
2. fill 4k file until disk is full
3. sync filesystem
4. read all files in the image
5. umount

Reviewed-by: Chao Yu 

Thanks,

Re: [PATCH] KVM: nVMX: add tracepoint for vmwrite

[kbuild test robot]

Hi Paolo,

[auto build test ERROR on kvm/linux-next]
[also build test ERROR on v4.9-rc3 next-20161028]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Paolo-Bonzini/KVM-nVMX-add-tracepoint-for-vmwrite/20161105-081951
base:   https://git.kernel.org/pub/scm/virt/kvm/kvm.git linux-next
config: x86_64-rhel-7.2 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> ERROR: "__tracepoint_kvm_vmwrite" [arch/x86/kvm/kvm-intel.ko] undefined!

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


.config.gz
Description: application/gzip

Re: [PATCH] KVM: nVMX: add tracepoint for vmwrite

[kbuild test robot]

Hi Paolo,

[auto build test ERROR on kvm/linux-next]
[also build test ERROR on v4.9-rc3 next-20161028]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Paolo-Bonzini/KVM-nVMX-add-tracepoint-for-vmwrite/20161105-081951
base:   https://git.kernel.org/pub/scm/virt/kvm/kvm.git linux-next
config: x86_64-rhel-7.2 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> ERROR: "__tracepoint_kvm_vmwrite" [arch/x86/kvm/kvm-intel.ko] undefined!

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


.config.gz
Description: application/gzip

Re: [PATCH 1/2] rtc: omap: Fix selecting external osc

[Alexandre Belloni]

On 27/10/2016 at 11:27:25 +0530, Keerthy wrote :
> From: Lokesh Vutla 
> 
> RTC can be clocked from an external 32KHz oscillator, or from the
> Peripheral PLL. The RTC has an internal oscillator buffer to support
> direct operation with a crystal.
> 
> 
> |   Device  -   |
> |   |   |   |
> |   | RTCSS |   |
> |   -   |   |   |
> OSC |<--| RTC   |   |   |   |
> |-->| OSC   |---|   |   |
> |      ||   |   |
> |   |clk|   |
> |      ||   |   |
> |   | PRCM  |---|   |   |
> |   |
> 
> 
> The RTC functional clock is sourced by default from the clock derived
> from the Peripheral PLL. In order to select source as external osc clk
> the following changes needs to be done:
> - Enable the RTC OSC (RTC_OSC_REG[4]OSC32K_GZ = 0)
> - Enable the clock mux(RTC_OSC_REG[6]K32CLK_EN = 1)
> - Select the external clock source (RTC_OSC_REG[3]32KCLK_SEL = 1)
> 
> Fixes: 399cf0f63f6f2 ("rtc: omap: Add external clock enabling support")
> Signed-off-by: Keerthy 
> Signed-off-by: Lokesh Vutla 
> Signed-off-by: Dave Gerlach 
> ---
> 
> Boot tested and checked for rtc ticking on am335x-boneblack, am335x-bone
> am437x-gp-evm, dra7-evm, dra72-evm.
> 
>  drivers/rtc/rtc-omap.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
Both applied, thanks.

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

Re: [PATCH 1/2] rtc: omap: Fix selecting external osc

[Alexandre Belloni]

On 27/10/2016 at 11:27:25 +0530, Keerthy wrote :
> From: Lokesh Vutla 
> 
> RTC can be clocked from an external 32KHz oscillator, or from the
> Peripheral PLL. The RTC has an internal oscillator buffer to support
> direct operation with a crystal.
> 
> 
> |   Device  -   |
> |   |   |   |
> |   | RTCSS |   |
> |   -   |   |   |
> OSC |<--| RTC   |   |   |   |
> |-->| OSC   |---|   |   |
> |      ||   |   |
> |   |clk|   |
> |      ||   |   |
> |   | PRCM  |---|   |   |
> |   |
> 
> 
> The RTC functional clock is sourced by default from the clock derived
> from the Peripheral PLL. In order to select source as external osc clk
> the following changes needs to be done:
> - Enable the RTC OSC (RTC_OSC_REG[4]OSC32K_GZ = 0)
> - Enable the clock mux(RTC_OSC_REG[6]K32CLK_EN = 1)
> - Select the external clock source (RTC_OSC_REG[3]32KCLK_SEL = 1)
> 
> Fixes: 399cf0f63f6f2 ("rtc: omap: Add external clock enabling support")
> Signed-off-by: Keerthy 
> Signed-off-by: Lokesh Vutla 
> Signed-off-by: Dave Gerlach 
> ---
> 
> Boot tested and checked for rtc ticking on am335x-boneblack, am335x-bone
> am437x-gp-evm, dra7-evm, dra72-evm.
> 
>  drivers/rtc/rtc-omap.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
Both applied, thanks.

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

[PATCH] pstore/dump: solution pstore data abort.

[Li Pengcheng]

If not return,data abort will happen
when two threads call pstore_dump at the same time.

Signed-off-by: Liu Hailong 
Signed-off-by: Li Pengcheng 
Signed-off-by: Li Zhong 
---
 fs/pstore/platform.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index 14984d9..60e6db6 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -493,6 +493,7 @@ static void pstore_dump(struct kmsg_dumper *dumper,
if (!is_locked) {
pr_err("pstore dump routine blocked in %s path, may 
corrupt error record\n"
   , in_nmi() ? "NMI" : why);
+   return;
}
} else {
spin_lock_irqsave(>buf_lock, flags);
-- 
1.9.1

[PATCH] pstore/dump: solution pstore data abort.

[Li Pengcheng]

If not return,data abort will happen
when two threads call pstore_dump at the same time.

Signed-off-by: Liu Hailong 
Signed-off-by: Li Pengcheng 
Signed-off-by: Li Zhong 
---
 fs/pstore/platform.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index 14984d9..60e6db6 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -493,6 +493,7 @@ static void pstore_dump(struct kmsg_dumper *dumper,
if (!is_locked) {
pr_err("pstore dump routine blocked in %s path, may 
corrupt error record\n"
   , in_nmi() ? "NMI" : why);
+   return;
}
} else {
spin_lock_irqsave(>buf_lock, flags);
-- 
1.9.1

Re: How to debug DEBUG_TEST_DRIVER_REMOVE hang during loading of kernel?

[Randy Dunlap]

On 11/04/16 13:47, Maarten Maathuis wrote:
> Anyone have advice where else I can ask?
> 
> On Sat, Oct 29, 2016 at 1:07 PM, Maarten Maathuis  
> wrote:
>> Anyone have suggestions?

Besides serial console, there are also netconsole, earlycon (probably not
useful to you), and earlyprintk.

You can use the boot option "initcall_debug" to see what drivers are being 
loaded
and possibly which one is causing the system hang.

You can use the boot option "ignore_loglevel" to have all kernel messages 
printed.


Who is enabling DEBUG_TEST_DRIVER_REMOVE?  Its help text says:

  This option is expected to find errors and may render your system
  unusable. You should say N here unless you are explicitly looking to
  test this functionality.


>> On Thu, Oct 27, 2016 at 8:42 PM, Maarten Maathuis  
>> wrote:
>>> Hi,
>>>
>>> I recently had trouble with loading a 4.9rcX kernel, which was hanging
>>> after loading the initial kernel ramdisk. After some painful bisecting
>>> I found this:
>>>
>>> bea5b158ff0da9c7246ff391f754f5f38e34577a is the first bad commit
>>> commit bea5b158ff0da9c7246ff391f754f5f38e34577a
>>> Author: Rob Herring 
>>> Date:   Thu Aug 11 10:20:58 2016 -0500
>>>
>>> driver core: add test of driver remove calls during probe
>>>
>>> In recent discussions on ksummit-discuss[1], it was suggested to do a
>>> sequence of probe, remove, probe for testing driver remove paths. This
>>> adds a kconfig option for said test.
>>>
>>> [1] 
>>> https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003459.html
>>>
>>> Suggested-by: Arnd Bergmann 
>>> Cc: Greg Kroah-Hartman 
>>> Signed-off-by: Rob Herring 
>>> Signed-off-by: Greg Kroah-Hartman 
>>>
>>> It turns out that the package i was using to build the kernel had
>>> DEBUG_TEST_DRIVER_REMOVE enabled.
>>>
>>> How do I actually figure out why this test causes a hang. I don't have
>>> a COM port available to use as serial console, and i don't know if it
>>> would even help.
>>>
>>> Please CC me as i'm not a member of this mailinglist.
>>>
>>> Maarten.


-- 
~Randy

Re: How to debug DEBUG_TEST_DRIVER_REMOVE hang during loading of kernel?

[Randy Dunlap]

On 11/04/16 13:47, Maarten Maathuis wrote:
> Anyone have advice where else I can ask?
> 
> On Sat, Oct 29, 2016 at 1:07 PM, Maarten Maathuis  
> wrote:
>> Anyone have suggestions?

Besides serial console, there are also netconsole, earlycon (probably not
useful to you), and earlyprintk.

You can use the boot option "initcall_debug" to see what drivers are being 
loaded
and possibly which one is causing the system hang.

You can use the boot option "ignore_loglevel" to have all kernel messages 
printed.


Who is enabling DEBUG_TEST_DRIVER_REMOVE?  Its help text says:

  This option is expected to find errors and may render your system
  unusable. You should say N here unless you are explicitly looking to
  test this functionality.


>> On Thu, Oct 27, 2016 at 8:42 PM, Maarten Maathuis  
>> wrote:
>>> Hi,
>>>
>>> I recently had trouble with loading a 4.9rcX kernel, which was hanging
>>> after loading the initial kernel ramdisk. After some painful bisecting
>>> I found this:
>>>
>>> bea5b158ff0da9c7246ff391f754f5f38e34577a is the first bad commit
>>> commit bea5b158ff0da9c7246ff391f754f5f38e34577a
>>> Author: Rob Herring 
>>> Date:   Thu Aug 11 10:20:58 2016 -0500
>>>
>>> driver core: add test of driver remove calls during probe
>>>
>>> In recent discussions on ksummit-discuss[1], it was suggested to do a
>>> sequence of probe, remove, probe for testing driver remove paths. This
>>> adds a kconfig option for said test.
>>>
>>> [1] 
>>> https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003459.html
>>>
>>> Suggested-by: Arnd Bergmann 
>>> Cc: Greg Kroah-Hartman 
>>> Signed-off-by: Rob Herring 
>>> Signed-off-by: Greg Kroah-Hartman 
>>>
>>> It turns out that the package i was using to build the kernel had
>>> DEBUG_TEST_DRIVER_REMOVE enabled.
>>>
>>> How do I actually figure out why this test causes a hang. I don't have
>>> a COM port available to use as serial console, and i don't know if it
>>> would even help.
>>>
>>> Please CC me as i'm not a member of this mailinglist.
>>>
>>> Maarten.


-- 
~Randy

[PATCH] drm: move allocation out of drm_get_format_name()

[Eric Engestrom]

Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07

drm: make drm_get_format_name thread-safe

Signed-off-by: Eric Engestrom 
[danvet: Clarify that the returned pointer must be freed with
kfree().]
Signed-off-by: Daniel Vetter 

Suggested-by: Ville Syrjälä 
Signed-off-by: Eric Engestrom 
---
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |  7 ++---
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |  7 ++---
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c   |  3 +-
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   |  7 ++---
 drivers/gpu/drm/drm_atomic.c|  7 +++--
 drivers/gpu/drm/drm_crtc.c  |  7 +++--
 drivers/gpu/drm/drm_fourcc.c| 12 +++-
 drivers/gpu/drm/drm_framebuffer.c   |  7 +++--
 drivers/gpu/drm/drm_modeset_helper.c|  7 +++--
 drivers/gpu/drm/drm_plane.c |  7 +++--
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  7 ++---
 drivers/gpu/drm/i915/i915_debugfs.c |  8 ++---
 drivers/gpu/drm/i915/intel_atomic_plane.c   |  8 ++---
 drivers/gpu/drm/i915/intel_display.c| 41 ++---
 drivers/gpu/drm/radeon/atombios_crtc.c  | 14 -
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  3 +-
 include/drm/drm_fourcc.h|  3 +-
 17 files changed, 71 insertions(+), 84 deletions(-)

diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index dc0aafa..5a8cb4b 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -54,6 +54,7 @@ int drm_format_horz_chroma_subsampling(uint32_t format);
 int drm_format_vert_chroma_subsampling(uint32_t format);
 int drm_format_plane_width(int width, uint32_t format, int plane);
 int drm_format_plane_height(int height, uint32_t format, int plane);
-char *drm_get_format_name(uint32_t format) __malloc;
+typedef char drm_format_name_buf[32];
+char *drm_get_format_name(uint32_t format, drm_format_name_buf buf);
 
 #endif /* __DRM_FOURCC_H__ */
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index cbb8b77..34ed520 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -79,17 +79,13 @@ uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t 
depth)
 EXPORT_SYMBOL(drm_mode_legacy_fb_format);
 
 /**
- * drm_get_format_name - return a string for drm fourcc format
+ * drm_get_format_name - fill a string with a drm fourcc format's name
  * @format: format to compute name of
+ * @buf: caller-supplied buffer
- *
- * Note that the buffer returned by this function is owned by the caller
- * and will need to be freed using kfree().
  */
-char *drm_get_format_name(uint32_t format)
+char *drm_get_format_name(uint32_t format, drm_format_name_buf buf)
 {
-   char *buf = kmalloc(32, GFP_KERNEL);
-
-   snprintf(buf, 32,
+   snprintf(buf, sizeof(drm_format_name_buf),
 "%c%c%c%c %s-endian (0x%08x)",
 printable_char(format & 0xff),
 printable_char((format >> 8) & 0xff),
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index 199d3f7..cefa3d8 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -2032,7 +2032,7 @@ static int dce_v10_0_crtc_do_set_base(struct drm_crtc 
*crtc,
u32 tmp, viewport_w, viewport_h;
int r;
bool bypass_lut = false;
-   char *format_name;
+   drm_format_name_buf format_name;
 
/* no fb bound */
if (!atomic && !crtc->primary->fb) {
@@ -2144,9 +2144,8 @@ static int dce_v10_0_crtc_do_set_base(struct drm_crtc 
*crtc,
bypass_lut = true;
break;
default:
-   format_name = drm_get_format_name(target_fb->pixel_format);
-   DRM_ERROR("Unsupported screen format %s\n", format_name);
-   kfree(format_name);
+   DRM_ERROR("Unsupported screen format %s\n",
+ drm_get_format_name(target_fb->pixel_format, 
format_name));
return -EINVAL;
}
 
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index ecd000e..462abb8 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -2013,7 +2013,7 @@ static int dce_v11_0_crtc_do_set_base(struct drm_crtc 
*crtc,
u32 tmp, viewport_w, viewport_h;
int r;
bool bypass_lut = false;
-   char *format_name;
+   drm_format_name_buf format_name;
 
/* no fb bound */
if (!atomic && !crtc->primary->fb) {
@@ -2125,9 +2125,8 @@ static int dce_v11_0_crtc_do_set_base(struct drm_crtc 
*crtc,
bypass_lut = true;
break;
default:
-   format_name = drm_get_format_name(target_fb->pixel_format);
-   

[PATCH] drm: move allocation out of drm_get_format_name()

[Eric Engestrom]

Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07

drm: make drm_get_format_name thread-safe

Signed-off-by: Eric Engestrom 
[danvet: Clarify that the returned pointer must be freed with
kfree().]
Signed-off-by: Daniel Vetter 

Suggested-by: Ville Syrjälä 
Signed-off-by: Eric Engestrom 
---
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |  7 ++---
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |  7 ++---
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c   |  3 +-
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   |  7 ++---
 drivers/gpu/drm/drm_atomic.c|  7 +++--
 drivers/gpu/drm/drm_crtc.c  |  7 +++--
 drivers/gpu/drm/drm_fourcc.c| 12 +++-
 drivers/gpu/drm/drm_framebuffer.c   |  7 +++--
 drivers/gpu/drm/drm_modeset_helper.c|  7 +++--
 drivers/gpu/drm/drm_plane.c |  7 +++--
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  7 ++---
 drivers/gpu/drm/i915/i915_debugfs.c |  8 ++---
 drivers/gpu/drm/i915/intel_atomic_plane.c   |  8 ++---
 drivers/gpu/drm/i915/intel_display.c| 41 ++---
 drivers/gpu/drm/radeon/atombios_crtc.c  | 14 -
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  3 +-
 include/drm/drm_fourcc.h|  3 +-
 17 files changed, 71 insertions(+), 84 deletions(-)

diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index dc0aafa..5a8cb4b 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -54,6 +54,7 @@ int drm_format_horz_chroma_subsampling(uint32_t format);
 int drm_format_vert_chroma_subsampling(uint32_t format);
 int drm_format_plane_width(int width, uint32_t format, int plane);
 int drm_format_plane_height(int height, uint32_t format, int plane);
-char *drm_get_format_name(uint32_t format) __malloc;
+typedef char drm_format_name_buf[32];
+char *drm_get_format_name(uint32_t format, drm_format_name_buf buf);
 
 #endif /* __DRM_FOURCC_H__ */
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index cbb8b77..34ed520 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -79,17 +79,13 @@ uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t 
depth)
 EXPORT_SYMBOL(drm_mode_legacy_fb_format);
 
 /**
- * drm_get_format_name - return a string for drm fourcc format
+ * drm_get_format_name - fill a string with a drm fourcc format's name
  * @format: format to compute name of
+ * @buf: caller-supplied buffer
- *
- * Note that the buffer returned by this function is owned by the caller
- * and will need to be freed using kfree().
  */
-char *drm_get_format_name(uint32_t format)
+char *drm_get_format_name(uint32_t format, drm_format_name_buf buf)
 {
-   char *buf = kmalloc(32, GFP_KERNEL);
-
-   snprintf(buf, 32,
+   snprintf(buf, sizeof(drm_format_name_buf),
 "%c%c%c%c %s-endian (0x%08x)",
 printable_char(format & 0xff),
 printable_char((format >> 8) & 0xff),
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index 199d3f7..cefa3d8 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -2032,7 +2032,7 @@ static int dce_v10_0_crtc_do_set_base(struct drm_crtc 
*crtc,
u32 tmp, viewport_w, viewport_h;
int r;
bool bypass_lut = false;
-   char *format_name;
+   drm_format_name_buf format_name;
 
/* no fb bound */
if (!atomic && !crtc->primary->fb) {
@@ -2144,9 +2144,8 @@ static int dce_v10_0_crtc_do_set_base(struct drm_crtc 
*crtc,
bypass_lut = true;
break;
default:
-   format_name = drm_get_format_name(target_fb->pixel_format);
-   DRM_ERROR("Unsupported screen format %s\n", format_name);
-   kfree(format_name);
+   DRM_ERROR("Unsupported screen format %s\n",
+ drm_get_format_name(target_fb->pixel_format, 
format_name));
return -EINVAL;
}
 
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index ecd000e..462abb8 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -2013,7 +2013,7 @@ static int dce_v11_0_crtc_do_set_base(struct drm_crtc 
*crtc,
u32 tmp, viewport_w, viewport_h;
int r;
bool bypass_lut = false;
-   char *format_name;
+   drm_format_name_buf format_name;
 
/* no fb bound */
if (!atomic && !crtc->primary->fb) {
@@ -2125,9 +2125,8 @@ static int dce_v11_0_crtc_do_set_base(struct drm_crtc 
*crtc,
bypass_lut = true;
break;
default:
-   format_name = drm_get_format_name(target_fb->pixel_format);
-   DRM_ERROR("Unsupported screen format %s\n", format_name);
-   kfree(format_name);

Re: Children Under Miserable Condition

[Mrs. Maima Farooq]

Good Day,

As an Aging widow with no child, suffering from long time incurable illness; 
presently admitted in a private hospital.

I decided to give away my estate to the vulnerable through a sincere person.

This is because at this point, life seems miserable for there is nobody to 
inherit my estate.

Can I confide in you to set up an orphanage home under my sponsorship?

Can you volunteer or make yourself available in putting smiles on the faces of 
the poor or an end to the sufferings of our children out there?

If you are willing, get back at me for more details.

Mrs. Maim Farooq

Re: Children Under Miserable Condition

[Mrs. Maima Farooq]

Good Day,

As an Aging widow with no child, suffering from long time incurable illness; 
presently admitted in a private hospital.

I decided to give away my estate to the vulnerable through a sincere person.

This is because at this point, life seems miserable for there is nobody to 
inherit my estate.

Can I confide in you to set up an orphanage home under my sponsorship?

Can you volunteer or make yourself available in putting smiles on the faces of 
the poor or an end to the sufferings of our children out there?

If you are willing, get back at me for more details.

Mrs. Maim Farooq

[GIT PULL] MD update for 4.9-rc3

[Shaohua Li]

Hi Linus,

Please pull MD changes for 4.9-rc3. There are several bug fixes queued:
- Fix raid5-cache recovery bugs
- Fix discard IO error handling for raid1/10
- Fix array sync writes bogus position to superblock
- Fix IO error handling for raid array with external metadata

Thanks,
Shaohua


The following changes since commit 07d9a380680d1c0eb51ef87ff2eab5c994949e69:

  Linux 4.9-rc2 (2016-10-23 17:10:14 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/shli/md.git tags/md/4.9-rc3

for you to fetch changes up to 1217e1d1999ed6c9c1e1b1acae0a74ab70464ae2:

  md: be careful not lot leak internal curr_resync value into metadata. -- 
(all) (2016-10-28 22:04:05 -0700)


NeilBrown (1):
  md: be careful not lot leak internal curr_resync value into metadata. -- 
(all)

Shaohua Li (3):
  RAID1: ignore discard error
  RAID10: ignore discard error
  raid5-cache: correct condition for empty metadata write

Tomasz Majchrzak (2):
  md: report 'write_pending' state when array in sync
  raid1: handle read error also in readonly mode

Zhengyuan Liu (2):
  md/raid5: initialize next_checkpoint field before use
  md/raid5: write an empty meta-block when creating log super-block

 drivers/md/md.c  | 10 +-
 drivers/md/raid1.c   | 26 +++---
 drivers/md/raid10.c  |  7 +--
 drivers/md/raid5-cache.c |  6 +-
 4 files changed, 30 insertions(+), 19 deletions(-)

[GIT PULL] MD update for 4.9-rc3

[Shaohua Li]

Hi Linus,

Please pull MD changes for 4.9-rc3. There are several bug fixes queued:
- Fix raid5-cache recovery bugs
- Fix discard IO error handling for raid1/10
- Fix array sync writes bogus position to superblock
- Fix IO error handling for raid array with external metadata

Thanks,
Shaohua


The following changes since commit 07d9a380680d1c0eb51ef87ff2eab5c994949e69:

  Linux 4.9-rc2 (2016-10-23 17:10:14 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/shli/md.git tags/md/4.9-rc3

for you to fetch changes up to 1217e1d1999ed6c9c1e1b1acae0a74ab70464ae2:

  md: be careful not lot leak internal curr_resync value into metadata. -- 
(all) (2016-10-28 22:04:05 -0700)


NeilBrown (1):
  md: be careful not lot leak internal curr_resync value into metadata. -- 
(all)

Shaohua Li (3):
  RAID1: ignore discard error
  RAID10: ignore discard error
  raid5-cache: correct condition for empty metadata write

Tomasz Majchrzak (2):
  md: report 'write_pending' state when array in sync
  raid1: handle read error also in readonly mode

Zhengyuan Liu (2):
  md/raid5: initialize next_checkpoint field before use
  md/raid5: write an empty meta-block when creating log super-block

 drivers/md/md.c  | 10 +-
 drivers/md/raid1.c   | 26 +++---
 drivers/md/raid10.c  |  7 +--
 drivers/md/raid5-cache.c |  6 +-
 4 files changed, 30 insertions(+), 19 deletions(-)

I Hope You Get My Message This Time

[Dr Friedrich Mayrhofer]

-- 
This is the second time i am sending you this mail.I, Friedrich Mayrhofer
Donate $ 1,000,000.00 to You, Email  Me personally for more details.

Regards.
Friedrich Mayrhofer

I Hope You Get My Message This Time

[Dr Friedrich Mayrhofer]

-- 
This is the second time i am sending you this mail.I, Friedrich Mayrhofer
Donate $ 1,000,000.00 to You, Email  Me personally for more details.

Regards.
Friedrich Mayrhofer

Re: Children Under Miserable Condition

[Mrs. Maima Farooq]

Good Day,

As an Aging widow with no child, suffering from long time incurable illness; 
presently admitted in a private hospital.

I decided to give away my estate to the vulnerable through a sincere person.

This is because at this point, life seems miserable for there is nobody to 
inherit my estate.

Can I confide in you to set up an orphanage home under my sponsorship?

Can you volunteer or make yourself available in putting smiles on the faces of 
the poor or an end to the sufferings of our children out there?

If you are willing, get back at me for more details.

Mrs. Maim Farooq

Re: Children Under Miserable Condition

[Mrs. Maima Farooq]

Good Day,

As an Aging widow with no child, suffering from long time incurable illness; 
presently admitted in a private hospital.

I decided to give away my estate to the vulnerable through a sincere person.

This is because at this point, life seems miserable for there is nobody to 
inherit my estate.

Can I confide in you to set up an orphanage home under my sponsorship?

Can you volunteer or make yourself available in putting smiles on the faces of 
the poor or an end to the sufferings of our children out there?

If you are willing, get back at me for more details.

Mrs. Maim Farooq

[GIT PULL] MTD updates for 4.9-rc4

[Brian Norris]

Hi Linus,

The following changes since commit 07d9a380680d1c0eb51ef87ff2eab5c994949e69:

  Linux 4.9-rc2 (2016-10-23 17:10:14 -0700)

are available in the git repository at:

  git://git.infradead.org/linux-mtd.git tags/for-linus-20161104

for you to fetch changes up to 0e2ce9d3fcba5f92dd6c2b27d82690e49d0c0854:

  Merge tag 'nand/fixes-for-4.9-rc3' of github.com:linux-nand/linux (2016-10-28 
19:05:25 -0700)


MTD updates for 4.9-rc4:

 * MAINTAINERS updates to reflect some new maintainers/submaintainers -- we
   have some great volunteers who've been developing and reviewing already.
   We're going to try a group maintainership model, so eventually you'll
   probably see pull requests from people besides me.

 * NAND fixes from Boris:
   """
   Three simple fixes:

   - the first one is fixing a non-critical bug in the gpmi driver
   - the second one is fixing a bug in the 'automatic NAND timings
 selection' feature introduced in 4.9-rc1
   - the last one is fixing a false positive uninitialized-var warning
   """


Arnd Bergmann (1):
  mtd: mtk: avoid warning in mtk_ecc_encode

Boris Brezillon (2):
  MAINTAINERS: add more people to the MTD maintainer team
  mtd: nand: Fix data interface configuration logic

Brian Norris (1):
  Merge tag 'nand/fixes-for-4.9-rc3' of github.com:linux-nand/linux

Cyrille Pitchen (1):
  MAINTAINERS: add a maintainer for the SPI NOR subsystem

Fabio Estevam (1):
  mtd: nand: gpmi: disable the clocks on errors

 MAINTAINERS   | 15 +
 drivers/mtd/nand/gpmi-nand/gpmi-lib.c |  6 ++--
 drivers/mtd/nand/mtk_ecc.c| 19 ++-
 drivers/mtd/nand/nand_base.c  | 60 ---
 include/linux/mtd/nand.h  |  2 +-
 5 files changed, 71 insertions(+), 31 deletions(-)

[GIT PULL] MTD updates for 4.9-rc4

[Brian Norris]

Hi Linus,

The following changes since commit 07d9a380680d1c0eb51ef87ff2eab5c994949e69:

  Linux 4.9-rc2 (2016-10-23 17:10:14 -0700)

are available in the git repository at:

  git://git.infradead.org/linux-mtd.git tags/for-linus-20161104

for you to fetch changes up to 0e2ce9d3fcba5f92dd6c2b27d82690e49d0c0854:

  Merge tag 'nand/fixes-for-4.9-rc3' of github.com:linux-nand/linux (2016-10-28 
19:05:25 -0700)


MTD updates for 4.9-rc4:

 * MAINTAINERS updates to reflect some new maintainers/submaintainers -- we
   have some great volunteers who've been developing and reviewing already.
   We're going to try a group maintainership model, so eventually you'll
   probably see pull requests from people besides me.

 * NAND fixes from Boris:
   """
   Three simple fixes:

   - the first one is fixing a non-critical bug in the gpmi driver
   - the second one is fixing a bug in the 'automatic NAND timings
 selection' feature introduced in 4.9-rc1
   - the last one is fixing a false positive uninitialized-var warning
   """


Arnd Bergmann (1):
  mtd: mtk: avoid warning in mtk_ecc_encode

Boris Brezillon (2):
  MAINTAINERS: add more people to the MTD maintainer team
  mtd: nand: Fix data interface configuration logic

Brian Norris (1):
  Merge tag 'nand/fixes-for-4.9-rc3' of github.com:linux-nand/linux

Cyrille Pitchen (1):
  MAINTAINERS: add a maintainer for the SPI NOR subsystem

Fabio Estevam (1):
  mtd: nand: gpmi: disable the clocks on errors

 MAINTAINERS   | 15 +
 drivers/mtd/nand/gpmi-nand/gpmi-lib.c |  6 ++--
 drivers/mtd/nand/mtk_ecc.c| 19 ++-
 drivers/mtd/nand/nand_base.c  | 60 ---
 include/linux/mtd/nand.h  |  2 +-
 5 files changed, 71 insertions(+), 31 deletions(-)

Re: [PATCH v8 7/7] KVM: x86: virtualize cpuid faulting

[David Matlack]

On Fri, Nov 4, 2016 at 2:57 PM, Paolo Bonzini  wrote:
>
> On 04/11/2016 21:34, David Matlack wrote:
>> On Mon, Oct 31, 2016 at 6:37 PM, Kyle Huey  wrote:
>>> +   case MSR_PLATFORM_INFO:
>>> +   /* cpuid faulting is supported */
>>> +   msr_info->data = PLATINFO_CPUID_FAULT;
>>> +   break;
>>
>> This could break save/restore, if for example, a VM is migrated to a
>> version of KVM without MSR_PLATFORM_INFO support. I think the way to
>> handle this is to make MSR_PLATFORM_INFO writeable (but only from
>> userspace) so that hypervisors can defend themselves (by setting this
>> MSR to 0).
>
> Right---and with my QEMU hat on, this feature will have to be enabled
> manually on the command line because of the way QEMU supports running
> with old kernels. :(  This however does not impact the KVM patch.
>
> We may decide that, because CPUID faulting doesn't have a CPUID bit and
> is relatively a "fringe" feature, we are okay if the kernel enables this
> unconditionally and then userspace can arrange to block migration (in
> QEMU this would use a subsection).  David, Eduardo, opinions?

Sounds reasonable. Accurate CPU virtualization might be another reason
to disable this feature from userspace.

My worry is a kernel rollback, where migrating to an older kernel
version is unavoidable.

>
>>
>>> +   case MSR_MISC_FEATURES_ENABLES:
>>> +   msr_info->data = 0;
>>> +   if (vcpu->arch.cpuid_fault)
>>> +   msr_info->data |= CPUID_FAULT_ENABLE;
>>> +   break;
>>
>> MSR_MISC_FEATURES_ENABLES should be added to emulated_msrs[] so that
>> the hypervisor will maintain the value of CPUID_FAULT_ENABLE across a
>> save/restore.
>
> This is definitely necessary.  Thanks David.
>
> Paolo
>
>>> default:
>>> if (kvm_pmu_is_valid_msr(vcpu, msr_info->index))
>>> return kvm_pmu_get_msr(vcpu, msr_info->index, 
>>> _info->data);
>>> if (!ignore_msrs) {
>>> vcpu_unimpl(vcpu, "unhandled rdmsr: 0x%x\n", 
>>> msr_info->index);
>>> return 1;
>>> } else {
>>> vcpu_unimpl(vcpu, "ignored rdmsr: 0x%x\n", 
>>> msr_info->index);
>>> @@ -7493,16 +7507,18 @@ void kvm_vcpu_reset(struct kvm_vcpu *vcpu, bool 
>>> init_event)
>>> kvm_update_dr0123(vcpu);
>>> vcpu->arch.dr6 = DR6_INIT;
>>> kvm_update_dr6(vcpu);
>>> vcpu->arch.dr7 = DR7_FIXED_1;
>>> kvm_update_dr7(vcpu);
>>>
>>> vcpu->arch.cr2 = 0;
>>>
>>> +   vcpu->arch.cpuid_fault = false;
>>> +
>>> kvm_make_request(KVM_REQ_EVENT, vcpu);
>>> vcpu->arch.apf.msr_val = 0;
>>> vcpu->arch.st.msr_val = 0;
>>>
>>> kvmclock_reset(vcpu);
>>>
>>> kvm_clear_async_pf_completion_queue(vcpu);
>>> kvm_async_pf_hash_reset(vcpu);
>>> --
>>> 2.10.2
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>

Re: [PATCH v8 7/7] KVM: x86: virtualize cpuid faulting

[David Matlack]

On Fri, Nov 4, 2016 at 2:57 PM, Paolo Bonzini  wrote:
>
> On 04/11/2016 21:34, David Matlack wrote:
>> On Mon, Oct 31, 2016 at 6:37 PM, Kyle Huey  wrote:
>>> +   case MSR_PLATFORM_INFO:
>>> +   /* cpuid faulting is supported */
>>> +   msr_info->data = PLATINFO_CPUID_FAULT;
>>> +   break;
>>
>> This could break save/restore, if for example, a VM is migrated to a
>> version of KVM without MSR_PLATFORM_INFO support. I think the way to
>> handle this is to make MSR_PLATFORM_INFO writeable (but only from
>> userspace) so that hypervisors can defend themselves (by setting this
>> MSR to 0).
>
> Right---and with my QEMU hat on, this feature will have to be enabled
> manually on the command line because of the way QEMU supports running
> with old kernels. :(  This however does not impact the KVM patch.
>
> We may decide that, because CPUID faulting doesn't have a CPUID bit and
> is relatively a "fringe" feature, we are okay if the kernel enables this
> unconditionally and then userspace can arrange to block migration (in
> QEMU this would use a subsection).  David, Eduardo, opinions?

Sounds reasonable. Accurate CPU virtualization might be another reason
to disable this feature from userspace.

My worry is a kernel rollback, where migrating to an older kernel
version is unavoidable.

>
>>
>>> +   case MSR_MISC_FEATURES_ENABLES:
>>> +   msr_info->data = 0;
>>> +   if (vcpu->arch.cpuid_fault)
>>> +   msr_info->data |= CPUID_FAULT_ENABLE;
>>> +   break;
>>
>> MSR_MISC_FEATURES_ENABLES should be added to emulated_msrs[] so that
>> the hypervisor will maintain the value of CPUID_FAULT_ENABLE across a
>> save/restore.
>
> This is definitely necessary.  Thanks David.
>
> Paolo
>
>>> default:
>>> if (kvm_pmu_is_valid_msr(vcpu, msr_info->index))
>>> return kvm_pmu_get_msr(vcpu, msr_info->index, 
>>> _info->data);
>>> if (!ignore_msrs) {
>>> vcpu_unimpl(vcpu, "unhandled rdmsr: 0x%x\n", 
>>> msr_info->index);
>>> return 1;
>>> } else {
>>> vcpu_unimpl(vcpu, "ignored rdmsr: 0x%x\n", 
>>> msr_info->index);
>>> @@ -7493,16 +7507,18 @@ void kvm_vcpu_reset(struct kvm_vcpu *vcpu, bool 
>>> init_event)
>>> kvm_update_dr0123(vcpu);
>>> vcpu->arch.dr6 = DR6_INIT;
>>> kvm_update_dr6(vcpu);
>>> vcpu->arch.dr7 = DR7_FIXED_1;
>>> kvm_update_dr7(vcpu);
>>>
>>> vcpu->arch.cr2 = 0;
>>>
>>> +   vcpu->arch.cpuid_fault = false;
>>> +
>>> kvm_make_request(KVM_REQ_EVENT, vcpu);
>>> vcpu->arch.apf.msr_val = 0;
>>> vcpu->arch.st.msr_val = 0;
>>>
>>> kvmclock_reset(vcpu);
>>>
>>> kvm_clear_async_pf_completion_queue(vcpu);
>>> kvm_async_pf_hash_reset(vcpu);
>>> --
>>> 2.10.2
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>

[PATCH] staging: lustre: o2iblnd: replace space indentation with tabs

[Nicholas Hanley]

This patch fixes all CODE_INDENT checkpatch errors in o2iblnd.

Signed-off-by: Nicholas Hanley 
---
 .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c|  2 +-
 .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c | 22 +++---
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c 
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
index 9e88021..13235b0 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
@@ -1637,7 +1637,7 @@ int kiblnd_fmr_pool_map(struct kib_fmr_poolset *fps, 
struct kib_tx *tx,
 {
__u64 *pages = tx->tx_pages;
bool is_rx = (rd != tx->tx_rd);
-bool tx_pages_mapped = 0;
+   bool tx_pages_mapped = 0;
struct kib_fmr_pool *fpo;
int npages = 0;
__u64 version;
diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c 
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
index b27de88..92692a2 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
@@ -1912,12 +1912,12 @@ kiblnd_close_conn_locked(struct kib_conn *conn, int 
error)
   libcfs_nid2str(peer->ibp_nid));
} else {
CNETERR("Closing conn to %s: error %d%s%s%s%s%s\n",
-   libcfs_nid2str(peer->ibp_nid), error,
-   list_empty(>ibc_tx_queue) ? "" : "(sending)",
-   list_empty(>ibc_tx_noops) ? "" : 
"(sending_noops)",
-   list_empty(>ibc_tx_queue_rsrvd) ? "" : 
"(sending_rsrvd)",
-   list_empty(>ibc_tx_queue_nocred) ? "" : 
"(sending_nocred)",
-   list_empty(>ibc_active_txs) ? "" : "(waiting)");
+   libcfs_nid2str(peer->ibp_nid), error,
+   list_empty(>ibc_tx_queue) ? "" : "(sending)",
+   list_empty(>ibc_tx_noops) ? "" : 
"(sending_noops)",
+   list_empty(>ibc_tx_queue_rsrvd) ? "" : 
"(sending_rsrvd)",
+   list_empty(>ibc_tx_queue_nocred) ? "" : 
"(sending_nocred)",
+   list_empty(>ibc_active_txs) ? "" : "(waiting)");
}
 
dev = ((struct kib_net *)peer->ibp_ni->ni_data)->ibn_dev;
@@ -2643,7 +2643,7 @@ kiblnd_check_reconnect(struct kib_conn *conn, int version,
if (incarnation)
peer->ibp_incarnation = incarnation;
 out:
-write_unlock_irqrestore(glock, flags);
+   write_unlock_irqrestore(glock, flags);
 
CNETERR("%s: %s (%s), %x, %x, msg_size: %d, queue_depth: %d/%d, 
max_frags: %d/%d\n",
libcfs_nid2str(peer->ibp_nid),
@@ -2651,7 +2651,7 @@ kiblnd_check_reconnect(struct kib_conn *conn, int version,
reason, IBLND_MSG_VERSION, version, msg_size,
conn->ibc_queue_depth, queue_dep,
conn->ibc_max_frags, frag_num);
-/**
+   /**
 * if conn::ibc_reconnect is TRUE, connd will reconnect to the peer
 * while destroying the zombie
 */
@@ -2976,7 +2976,7 @@ kiblnd_cm_callback(struct rdma_cm_id *cmid, struct 
rdma_cm_event *event)
case RDMA_CM_EVENT_ADDR_ERROR:
peer = (struct kib_peer *)cmid->context;
CNETERR("%s: ADDR ERROR %d\n",
-   libcfs_nid2str(peer->ibp_nid), event->status);
+   libcfs_nid2str(peer->ibp_nid), event->status);
kiblnd_peer_connect_failed(peer, 1, -EHOSTUNREACH);
kiblnd_peer_decref(peer);
return -EHOSTUNREACH;  /* rc destroys cmid */
@@ -3021,7 +3021,7 @@ kiblnd_cm_callback(struct rdma_cm_id *cmid, struct 
rdma_cm_event *event)
return kiblnd_active_connect(cmid);
 
CNETERR("Can't resolve route for %s: %d\n",
-   libcfs_nid2str(peer->ibp_nid), event->status);
+   libcfs_nid2str(peer->ibp_nid), event->status);
kiblnd_peer_connect_failed(peer, 1, event->status);
kiblnd_peer_decref(peer);
return event->status;  /* rc destroys cmid */
@@ -3031,7 +3031,7 @@ kiblnd_cm_callback(struct rdma_cm_id *cmid, struct 
rdma_cm_event *event)
LASSERT(conn->ibc_state == IBLND_CONN_ACTIVE_CONNECT ||
conn->ibc_state == IBLND_CONN_PASSIVE_WAIT);
CNETERR("%s: UNREACHABLE %d\n",
-   libcfs_nid2str(conn->ibc_peer->ibp_nid), event->status);
+   libcfs_nid2str(conn->ibc_peer->ibp_nid), event->status);
kiblnd_connreq_done(conn, -ENETDOWN);
kiblnd_conn_decref(conn);
return 0;
-- 
2.10.1

[PATCH] staging: lustre: o2iblnd: replace space indentation with tabs

[Nicholas Hanley]

This patch fixes all CODE_INDENT checkpatch errors in o2iblnd.

Signed-off-by: Nicholas Hanley 
---
 .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c|  2 +-
 .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c | 22 +++---
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c 
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
index 9e88021..13235b0 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
@@ -1637,7 +1637,7 @@ int kiblnd_fmr_pool_map(struct kib_fmr_poolset *fps, 
struct kib_tx *tx,
 {
__u64 *pages = tx->tx_pages;
bool is_rx = (rd != tx->tx_rd);
-bool tx_pages_mapped = 0;
+   bool tx_pages_mapped = 0;
struct kib_fmr_pool *fpo;
int npages = 0;
__u64 version;
diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c 
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
index b27de88..92692a2 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
@@ -1912,12 +1912,12 @@ kiblnd_close_conn_locked(struct kib_conn *conn, int 
error)
   libcfs_nid2str(peer->ibp_nid));
} else {
CNETERR("Closing conn to %s: error %d%s%s%s%s%s\n",
-   libcfs_nid2str(peer->ibp_nid), error,
-   list_empty(>ibc_tx_queue) ? "" : "(sending)",
-   list_empty(>ibc_tx_noops) ? "" : 
"(sending_noops)",
-   list_empty(>ibc_tx_queue_rsrvd) ? "" : 
"(sending_rsrvd)",
-   list_empty(>ibc_tx_queue_nocred) ? "" : 
"(sending_nocred)",
-   list_empty(>ibc_active_txs) ? "" : "(waiting)");
+   libcfs_nid2str(peer->ibp_nid), error,
+   list_empty(>ibc_tx_queue) ? "" : "(sending)",
+   list_empty(>ibc_tx_noops) ? "" : 
"(sending_noops)",
+   list_empty(>ibc_tx_queue_rsrvd) ? "" : 
"(sending_rsrvd)",
+   list_empty(>ibc_tx_queue_nocred) ? "" : 
"(sending_nocred)",
+   list_empty(>ibc_active_txs) ? "" : "(waiting)");
}
 
dev = ((struct kib_net *)peer->ibp_ni->ni_data)->ibn_dev;
@@ -2643,7 +2643,7 @@ kiblnd_check_reconnect(struct kib_conn *conn, int version,
if (incarnation)
peer->ibp_incarnation = incarnation;
 out:
-write_unlock_irqrestore(glock, flags);
+   write_unlock_irqrestore(glock, flags);
 
CNETERR("%s: %s (%s), %x, %x, msg_size: %d, queue_depth: %d/%d, 
max_frags: %d/%d\n",
libcfs_nid2str(peer->ibp_nid),
@@ -2651,7 +2651,7 @@ kiblnd_check_reconnect(struct kib_conn *conn, int version,
reason, IBLND_MSG_VERSION, version, msg_size,
conn->ibc_queue_depth, queue_dep,
conn->ibc_max_frags, frag_num);
-/**
+   /**
 * if conn::ibc_reconnect is TRUE, connd will reconnect to the peer
 * while destroying the zombie
 */
@@ -2976,7 +2976,7 @@ kiblnd_cm_callback(struct rdma_cm_id *cmid, struct 
rdma_cm_event *event)
case RDMA_CM_EVENT_ADDR_ERROR:
peer = (struct kib_peer *)cmid->context;
CNETERR("%s: ADDR ERROR %d\n",
-   libcfs_nid2str(peer->ibp_nid), event->status);
+   libcfs_nid2str(peer->ibp_nid), event->status);
kiblnd_peer_connect_failed(peer, 1, -EHOSTUNREACH);
kiblnd_peer_decref(peer);
return -EHOSTUNREACH;  /* rc destroys cmid */
@@ -3021,7 +3021,7 @@ kiblnd_cm_callback(struct rdma_cm_id *cmid, struct 
rdma_cm_event *event)
return kiblnd_active_connect(cmid);
 
CNETERR("Can't resolve route for %s: %d\n",
-   libcfs_nid2str(peer->ibp_nid), event->status);
+   libcfs_nid2str(peer->ibp_nid), event->status);
kiblnd_peer_connect_failed(peer, 1, event->status);
kiblnd_peer_decref(peer);
return event->status;  /* rc destroys cmid */
@@ -3031,7 +3031,7 @@ kiblnd_cm_callback(struct rdma_cm_id *cmid, struct 
rdma_cm_event *event)
LASSERT(conn->ibc_state == IBLND_CONN_ACTIVE_CONNECT ||
conn->ibc_state == IBLND_CONN_PASSIVE_WAIT);
CNETERR("%s: UNREACHABLE %d\n",
-   libcfs_nid2str(conn->ibc_peer->ibp_nid), event->status);
+   libcfs_nid2str(conn->ibc_peer->ibp_nid), event->status);
kiblnd_connreq_done(conn, -ENETDOWN);
kiblnd_conn_decref(conn);
return 0;
-- 
2.10.1

Re: [PATCH v2 1/3] remoteproc: qcom: Encapsulate pvt data structure for q6v56 hexagon.

[kbuild test robot]

Hi Avaneesh,

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.9-rc3 next-20161028]
[cannot apply to remoteproc/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/Avaneesh-Kumar-Dwivedi/remoteproc-qcom-Encapsulate-pvt-data-structure-for-q6v56-hexagon/20161104-220712
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm64-allyesconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

Note: the 
linux-review/Avaneesh-Kumar-Dwivedi/remoteproc-qcom-Encapsulate-pvt-data-structure-for-q6v56-hexagon/20161104-220712
 HEAD 1b4c0b8bb3bb8cd30a996282b7a6aa9f352836a2 builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   drivers/remoteproc/qcom_q6v5_pil.c: In function 'q6_probe':
   drivers/remoteproc/qcom_q6v5_pil.c:848:7: warning: assignment discards 
'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
 desc = of_device_get_match_data(>dev);
  ^
   drivers/remoteproc/qcom_q6v5_pil.c: At top level:
>> drivers/remoteproc/qcom_q6v5_pil.c:986:19: error: initialization from 
>> incompatible pointer type [-Werror=incompatible-pointer-types]
 .q6_reset_init = q6v5_init_reset,
  ^~~
   drivers/remoteproc/qcom_q6v5_pil.c:986:19: note: (near initialization for 
'msm_8916_res.q6_reset_init')
   cc1: some warnings being treated as errors

vim +986 drivers/remoteproc/qcom_q6v5_pil.c

   842  {
   843  struct q6v5 *qproc;
   844  struct rproc *rproc;
   845  struct q6_rproc_res *desc;
   846  int ret;
   847  
 > 848  desc = of_device_get_match_data(>dev);
   849  if (!desc)
   850  return -EINVAL;
   851  
   852  rproc = rproc_alloc(>dev, pdev->name, _ops,
   853  desc->q6_mba_image, sizeof(*qproc));
   854  if (!rproc) {
   855  dev_err(>dev, "failed to allocate rproc\n");
   856  return -ENOMEM;
   857  }
   858  
   859  rproc->fw_ops = _fw_ops;
   860  
   861  qproc = (struct q6v5 *)rproc->priv;
   862  qproc->dev = >dev;
   863  qproc->rproc = rproc;
   864  platform_set_drvdata(pdev, qproc);
   865  
   866  init_completion(>start_done);
   867  init_completion(>stop_done);
   868  
   869  qproc->q6_rproc_res = desc;
   870  ret = q6v5_init_mem(qproc, pdev);
   871  if (ret)
   872  goto free_rproc;
   873  
   874  ret = q6v5_alloc_memory_region(qproc);
   875  if (ret)
   876  goto free_rproc;
   877  
   878  ret = q6v5_init_clocks(qproc);
   879  if (ret)
   880  goto free_rproc;
   881  
   882  ret = q6v5_regulator_init(qproc);
   883  if (ret)
   884  goto free_rproc;
   885  
   886  ret = qproc->q6_rproc_res->q6_reset_init(qproc, pdev);
   887  if (ret)
   888  goto free_rproc;
   889  
   890  ret = q6v5_request_irq(qproc, pdev, "wdog", 
q6v5_wdog_interrupt);
   891  if (ret < 0)
   892  goto free_rproc;
   893  
   894  ret = q6v5_request_irq(qproc, pdev, "fatal", 
q6v5_fatal_interrupt);
   895  if (ret < 0)
   896  goto free_rproc;
   897  
   898  ret = q6v5_request_irq(qproc, pdev, "handover", 
q6v5_handover_interrupt);
   899  if (ret < 0)
   900  goto free_rproc;
   901  
   902  ret = q6v5_request_irq(qproc, pdev, "stop-ack", 
q6v5_stop_ack_interrupt);
   903  if (ret < 0)
   904  goto free_rproc;
   905  
   906  qproc->state = qcom_smem_state_get(>dev, "stop", 
>stop_bit);
   907  if (IS_ERR(qproc->state))
   908  goto free_rproc;
   909  
   910  ret = rproc_add(rproc);
   911  if (ret)
   912  goto free_rproc;
   913  
   914  return 0;
   915  
   916  free_rproc:
   917  rproc_put(rproc);
   918  
   919  return ret;
   920  }
   921  
   922  static int q6_remove(struct platform_device *pdev)

Re: [PATCH v2 1/3] remoteproc: qcom: Encapsulate pvt data structure for q6v56 hexagon.

[kbuild test robot]

Hi Avaneesh,

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.9-rc3 next-20161028]
[cannot apply to remoteproc/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/Avaneesh-Kumar-Dwivedi/remoteproc-qcom-Encapsulate-pvt-data-structure-for-q6v56-hexagon/20161104-220712
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm64-allyesconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

Note: the 
linux-review/Avaneesh-Kumar-Dwivedi/remoteproc-qcom-Encapsulate-pvt-data-structure-for-q6v56-hexagon/20161104-220712
 HEAD 1b4c0b8bb3bb8cd30a996282b7a6aa9f352836a2 builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   drivers/remoteproc/qcom_q6v5_pil.c: In function 'q6_probe':
   drivers/remoteproc/qcom_q6v5_pil.c:848:7: warning: assignment discards 
'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
 desc = of_device_get_match_data(>dev);
  ^
   drivers/remoteproc/qcom_q6v5_pil.c: At top level:
>> drivers/remoteproc/qcom_q6v5_pil.c:986:19: error: initialization from 
>> incompatible pointer type [-Werror=incompatible-pointer-types]
 .q6_reset_init = q6v5_init_reset,
  ^~~
   drivers/remoteproc/qcom_q6v5_pil.c:986:19: note: (near initialization for 
'msm_8916_res.q6_reset_init')
   cc1: some warnings being treated as errors

vim +986 drivers/remoteproc/qcom_q6v5_pil.c

   842  {
   843  struct q6v5 *qproc;
   844  struct rproc *rproc;
   845  struct q6_rproc_res *desc;
   846  int ret;
   847  
 > 848  desc = of_device_get_match_data(>dev);
   849  if (!desc)
   850  return -EINVAL;
   851  
   852  rproc = rproc_alloc(>dev, pdev->name, _ops,
   853  desc->q6_mba_image, sizeof(*qproc));
   854  if (!rproc) {
   855  dev_err(>dev, "failed to allocate rproc\n");
   856  return -ENOMEM;
   857  }
   858  
   859  rproc->fw_ops = _fw_ops;
   860  
   861  qproc = (struct q6v5 *)rproc->priv;
   862  qproc->dev = >dev;
   863  qproc->rproc = rproc;
   864  platform_set_drvdata(pdev, qproc);
   865  
   866  init_completion(>start_done);
   867  init_completion(>stop_done);
   868  
   869  qproc->q6_rproc_res = desc;
   870  ret = q6v5_init_mem(qproc, pdev);
   871  if (ret)
   872  goto free_rproc;
   873  
   874  ret = q6v5_alloc_memory_region(qproc);
   875  if (ret)
   876  goto free_rproc;
   877  
   878  ret = q6v5_init_clocks(qproc);
   879  if (ret)
   880  goto free_rproc;
   881  
   882  ret = q6v5_regulator_init(qproc);
   883  if (ret)
   884  goto free_rproc;
   885  
   886  ret = qproc->q6_rproc_res->q6_reset_init(qproc, pdev);
   887  if (ret)
   888  goto free_rproc;
   889  
   890  ret = q6v5_request_irq(qproc, pdev, "wdog", 
q6v5_wdog_interrupt);
   891  if (ret < 0)
   892  goto free_rproc;
   893  
   894  ret = q6v5_request_irq(qproc, pdev, "fatal", 
q6v5_fatal_interrupt);
   895  if (ret < 0)
   896  goto free_rproc;
   897  
   898  ret = q6v5_request_irq(qproc, pdev, "handover", 
q6v5_handover_interrupt);
   899  if (ret < 0)
   900  goto free_rproc;
   901  
   902  ret = q6v5_request_irq(qproc, pdev, "stop-ack", 
q6v5_stop_ack_interrupt);
   903  if (ret < 0)
   904  goto free_rproc;
   905  
   906  qproc->state = qcom_smem_state_get(>dev, "stop", 
>stop_bit);
   907  if (IS_ERR(qproc->state))
   908  goto free_rproc;
   909  
   910  ret = rproc_add(rproc);
   911  if (ret)
   912  goto free_rproc;
   913  
   914  return 0;
   915  
   916  free_rproc:
   917  rproc_put(rproc);
   918  
   919  return ret;
   920  }
   921  
   922  static int q6_remove(struct platform_device *pdev)

Re: [PATCH] mm: only enable sys_pkey* when ARCH_HAS_PKEYS

[Mark Rutland]

On Wed, Nov 02, 2016 at 12:15:50PM -0700, Dave Hansen wrote:
> On 10/31/2016 05:08 PM, Mark Rutland wrote:
> > When an architecture does not select CONFIG_ARCH_HAS_PKEYS, the pkey_alloc
> > syscall will return -ENOSPC for all (otherwise well-formed) requests, as the
> > generic implementation of mm_pkey_alloc() returns -1. The other pkey 
> > syscalls
> > perform some work before always failing, in a similar fashion.
> > 
> > This implies the absence of keys, but otherwise functional pkey support. 
> > This
> > is odd, since the architecture provides no such support. Instead, it would 
> > be
> > preferable to indicate that the syscall is not implemented, since this is
> > effectively the case.
> 
> This makes the behavior of an x86 cpu without pkeys and an arm cpu
> without pkeys differ.  Is that what we want?

My rationale was that we have no idea whether architectures will have pkey
support in future, and if/when they do, we may have to apply additional checks
anyhow. i.e. in cases we'd return -ENOSPC today, we might want to return
another error code.

Returning -ENOSYS retains the current behaviour, and allows us to handle that
ABI issue when we know what architecture support looks like.

Other architectures not using the generic syscalls seem to handle this with
-ENOSYS, e.g. parisc with commit 18088db042dd9ae2, so there's differing
behaviour regardless of arm specifically.

> An application that _wants_ to use protection keys but can't needs to handle
> -ENOSPC anyway.

Sure, and that application *also* has to handle -ENOSYS, given current kernels.

> On an architecture that will never support pkeys, it makes sense to do
> -ENOSYS, but that's not the case for arm, right?

I don't know whether arm or other architectures will have (user-accessible)
pkey-like suport.

Thanks,
Mark.

Re: [PATCH] mm: only enable sys_pkey* when ARCH_HAS_PKEYS

[Mark Rutland]

On Wed, Nov 02, 2016 at 12:15:50PM -0700, Dave Hansen wrote:
> On 10/31/2016 05:08 PM, Mark Rutland wrote:
> > When an architecture does not select CONFIG_ARCH_HAS_PKEYS, the pkey_alloc
> > syscall will return -ENOSPC for all (otherwise well-formed) requests, as the
> > generic implementation of mm_pkey_alloc() returns -1. The other pkey 
> > syscalls
> > perform some work before always failing, in a similar fashion.
> > 
> > This implies the absence of keys, but otherwise functional pkey support. 
> > This
> > is odd, since the architecture provides no such support. Instead, it would 
> > be
> > preferable to indicate that the syscall is not implemented, since this is
> > effectively the case.
> 
> This makes the behavior of an x86 cpu without pkeys and an arm cpu
> without pkeys differ.  Is that what we want?

My rationale was that we have no idea whether architectures will have pkey
support in future, and if/when they do, we may have to apply additional checks
anyhow. i.e. in cases we'd return -ENOSPC today, we might want to return
another error code.

Returning -ENOSYS retains the current behaviour, and allows us to handle that
ABI issue when we know what architecture support looks like.

Other architectures not using the generic syscalls seem to handle this with
-ENOSYS, e.g. parisc with commit 18088db042dd9ae2, so there's differing
behaviour regardless of arm specifically.

> An application that _wants_ to use protection keys but can't needs to handle
> -ENOSPC anyway.

Sure, and that application *also* has to handle -ENOSYS, given current kernels.

> On an architecture that will never support pkeys, it makes sense to do
> -ENOSYS, but that's not the case for arm, right?

I don't know whether arm or other architectures will have (user-accessible)
pkey-like suport.

Thanks,
Mark.

[PATCH] drm/vc4: Use runtime autosuspend to avoid thrashing V3D power state.

[Eric Anholt]

The pm_runtime_put() we were using immediately released power on the
device, which meant that we were generally turning the device off and
on once per frame.  In many profiles I've looked at, that added up to
about 1% of CPU time, but this could get worse in the case of frequent
rendering and readback (as may happen in X rendering).  By keeping the
device on until we've been idle for a couple of frames, we drop the
overhead of runtime PM down to sub-.1%.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_drv.c | 9 ++---
 drivers/gpu/drm/vc4/vc4_gem.c | 6 --
 drivers/gpu/drm/vc4/vc4_v3d.c | 2 ++
 3 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index b087404c2784..7abfe088f2d1 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -61,21 +61,24 @@ static int vc4_get_param_ioctl(struct drm_device *dev, void 
*data,
if (ret < 0)
return ret;
args->value = V3D_READ(V3D_IDENT0);
-   pm_runtime_put(>v3d->pdev->dev);
+   pm_runtime_mark_last_busy(>v3d->pdev->dev);
+   pm_runtime_put_autosuspend(>v3d->pdev->dev);
break;
case DRM_VC4_PARAM_V3D_IDENT1:
ret = pm_runtime_get_sync(>v3d->pdev->dev);
if (ret < 0)
return ret;
args->value = V3D_READ(V3D_IDENT1);
-   pm_runtime_put(>v3d->pdev->dev);
+   pm_runtime_mark_last_busy(>v3d->pdev->dev);
+   pm_runtime_put_autosuspend(>v3d->pdev->dev);
break;
case DRM_VC4_PARAM_V3D_IDENT2:
ret = pm_runtime_get_sync(>v3d->pdev->dev);
if (ret < 0)
return ret;
args->value = V3D_READ(V3D_IDENT2);
-   pm_runtime_put(>v3d->pdev->dev);
+   pm_runtime_mark_last_busy(>v3d->pdev->dev);
+   pm_runtime_put_autosuspend(>v3d->pdev->dev);
break;
case DRM_VC4_PARAM_SUPPORTS_BRANCHES:
case DRM_VC4_PARAM_SUPPORTS_ETC1:
diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index 303f23c96220..db920771bfb5 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -709,8 +709,10 @@ vc4_complete_exec(struct drm_device *dev, struct 
vc4_exec_info *exec)
}
 
mutex_lock(>power_lock);
-   if (--vc4->power_refcount == 0)
-   pm_runtime_put(>v3d->pdev->dev);
+   if (--vc4->power_refcount == 0) {
+   pm_runtime_mark_last_busy(>v3d->pdev->dev);
+   pm_runtime_put_autosuspend(>v3d->pdev->dev);
+   }
mutex_unlock(>power_lock);
 
kfree(exec);
diff --git a/drivers/gpu/drm/vc4/vc4_v3d.c b/drivers/gpu/drm/vc4/vc4_v3d.c
index e6d3c6028341..7cc346ad9b0b 100644
--- a/drivers/gpu/drm/vc4/vc4_v3d.c
+++ b/drivers/gpu/drm/vc4/vc4_v3d.c
@@ -222,6 +222,8 @@ static int vc4_v3d_bind(struct device *dev, struct device 
*master, void *data)
return ret;
}
 
+   pm_runtime_use_autosuspend(dev);
+   pm_runtime_set_autosuspend_delay(dev, 40); /* a little over 2 frames. */
pm_runtime_enable(dev);
 
return 0;
-- 
2.10.2

Re: [PATCH v3 1/3] dt-bindings: mediatek: Add a binding for Mediatek JPEG Decoder

[Laurent Pinchart]

Hi Rick,

Thank you for the patch.

On Friday 04 Nov 2016 13:51:18 Rick Chang wrote:
> Add a DT binding documentation for Mediatek JPEG Decoder of
> MT2701 SoC.

This version looks much better !

> Signed-off-by: Rick Chang 
> Signed-off-by: Minghsiu Tsai 
> ---
>  .../bindings/media/mediatek-jpeg-codec.txt | 35 +++
>  1 file changed, 35 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt
> b/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt new file
> mode 100644
> index 000..b2b19ed
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt
> @@ -0,0 +1,35 @@
> +* Mediatek JPEG Decoder
> +
> +Mediatek JPEG Decoder is the JPEG decode hw present in Mediatek SoCs

Nitpicking, I'd write hardware instead of hw.

> +Required properties:
> +- compatible : "mediatek,mt2701-jpgdec"

As commented on the previous version, is this JPEG decoder unique to the 
MT2701, or is it also used (possibly with different interrupts, clocks, ...) 
in other SoCs ? In the latter case, if the JPEG decoder IP core is identical 
in multiple SoCs, a more generic compatible string would be better.

> +- reg : physical base address of the jpeg decoder registers and length of
> +  memory mapped region.
> +- interrupts : interrupt number to the interrupt controller.
> +- clocks: device clocks, see
> +  Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
> +- clock-names: must contain "jpgdec-smi" and "jpgdec".
> +- power-domains: a phandle to the power domain, see
> +  Documentation/devicetree/bindings/power/power_domain.txt for details.
> +- mediatek,larb: must contain the local arbiters in the current Socs, see
> + 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
> +  for details.
> +- iommus: should point to the respective IOMMU block with master port as
> +  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> +  for details.
> +
> +Example:
> + jpegdec: jpegdec@15004000 {
> + compatible = "mediatek,mt2701-jpgdec";
> + reg = <0 0x15004000 0 0x1000>;
> + interrupts = ;
> + clocks =  < CLK_IMG_JPGDEC_SMI>,
> +   < CLK_IMG_JPGDEC>;
> + clock-names = "jpgdec-smi",
> +   "jpgdec";
> + power-domains = < MT2701_POWER_DOMAIN_ISP>;
> + mediatek,larb = <>;
> + iommus = < MT2701_M4U_PORT_JPGDEC_WDMA>,
> +  < MT2701_M4U_PORT_JPGDEC_BSDMA>;
> + };

-- 
Regards,

Laurent Pinchart

[PATCH] drm/vc4: Use runtime autosuspend to avoid thrashing V3D power state.

[Eric Anholt]

The pm_runtime_put() we were using immediately released power on the
device, which meant that we were generally turning the device off and
on once per frame.  In many profiles I've looked at, that added up to
about 1% of CPU time, but this could get worse in the case of frequent
rendering and readback (as may happen in X rendering).  By keeping the
device on until we've been idle for a couple of frames, we drop the
overhead of runtime PM down to sub-.1%.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_drv.c | 9 ++---
 drivers/gpu/drm/vc4/vc4_gem.c | 6 --
 drivers/gpu/drm/vc4/vc4_v3d.c | 2 ++
 3 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index b087404c2784..7abfe088f2d1 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -61,21 +61,24 @@ static int vc4_get_param_ioctl(struct drm_device *dev, void 
*data,
if (ret < 0)
return ret;
args->value = V3D_READ(V3D_IDENT0);
-   pm_runtime_put(>v3d->pdev->dev);
+   pm_runtime_mark_last_busy(>v3d->pdev->dev);
+   pm_runtime_put_autosuspend(>v3d->pdev->dev);
break;
case DRM_VC4_PARAM_V3D_IDENT1:
ret = pm_runtime_get_sync(>v3d->pdev->dev);
if (ret < 0)
return ret;
args->value = V3D_READ(V3D_IDENT1);
-   pm_runtime_put(>v3d->pdev->dev);
+   pm_runtime_mark_last_busy(>v3d->pdev->dev);
+   pm_runtime_put_autosuspend(>v3d->pdev->dev);
break;
case DRM_VC4_PARAM_V3D_IDENT2:
ret = pm_runtime_get_sync(>v3d->pdev->dev);
if (ret < 0)
return ret;
args->value = V3D_READ(V3D_IDENT2);
-   pm_runtime_put(>v3d->pdev->dev);
+   pm_runtime_mark_last_busy(>v3d->pdev->dev);
+   pm_runtime_put_autosuspend(>v3d->pdev->dev);
break;
case DRM_VC4_PARAM_SUPPORTS_BRANCHES:
case DRM_VC4_PARAM_SUPPORTS_ETC1:
diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index 303f23c96220..db920771bfb5 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -709,8 +709,10 @@ vc4_complete_exec(struct drm_device *dev, struct 
vc4_exec_info *exec)
}
 
mutex_lock(>power_lock);
-   if (--vc4->power_refcount == 0)
-   pm_runtime_put(>v3d->pdev->dev);
+   if (--vc4->power_refcount == 0) {
+   pm_runtime_mark_last_busy(>v3d->pdev->dev);
+   pm_runtime_put_autosuspend(>v3d->pdev->dev);
+   }
mutex_unlock(>power_lock);
 
kfree(exec);
diff --git a/drivers/gpu/drm/vc4/vc4_v3d.c b/drivers/gpu/drm/vc4/vc4_v3d.c
index e6d3c6028341..7cc346ad9b0b 100644
--- a/drivers/gpu/drm/vc4/vc4_v3d.c
+++ b/drivers/gpu/drm/vc4/vc4_v3d.c
@@ -222,6 +222,8 @@ static int vc4_v3d_bind(struct device *dev, struct device 
*master, void *data)
return ret;
}
 
+   pm_runtime_use_autosuspend(dev);
+   pm_runtime_set_autosuspend_delay(dev, 40); /* a little over 2 frames. */
pm_runtime_enable(dev);
 
return 0;
-- 
2.10.2

Re: [PATCH v3 1/3] dt-bindings: mediatek: Add a binding for Mediatek JPEG Decoder

[Laurent Pinchart]

Hi Rick,

Thank you for the patch.

On Friday 04 Nov 2016 13:51:18 Rick Chang wrote:
> Add a DT binding documentation for Mediatek JPEG Decoder of
> MT2701 SoC.

This version looks much better !

> Signed-off-by: Rick Chang 
> Signed-off-by: Minghsiu Tsai 
> ---
>  .../bindings/media/mediatek-jpeg-codec.txt | 35 +++
>  1 file changed, 35 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt
> b/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt new file
> mode 100644
> index 000..b2b19ed
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt
> @@ -0,0 +1,35 @@
> +* Mediatek JPEG Decoder
> +
> +Mediatek JPEG Decoder is the JPEG decode hw present in Mediatek SoCs

Nitpicking, I'd write hardware instead of hw.

> +Required properties:
> +- compatible : "mediatek,mt2701-jpgdec"

As commented on the previous version, is this JPEG decoder unique to the 
MT2701, or is it also used (possibly with different interrupts, clocks, ...) 
in other SoCs ? In the latter case, if the JPEG decoder IP core is identical 
in multiple SoCs, a more generic compatible string would be better.

> +- reg : physical base address of the jpeg decoder registers and length of
> +  memory mapped region.
> +- interrupts : interrupt number to the interrupt controller.
> +- clocks: device clocks, see
> +  Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
> +- clock-names: must contain "jpgdec-smi" and "jpgdec".
> +- power-domains: a phandle to the power domain, see
> +  Documentation/devicetree/bindings/power/power_domain.txt for details.
> +- mediatek,larb: must contain the local arbiters in the current Socs, see
> + 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
> +  for details.
> +- iommus: should point to the respective IOMMU block with master port as
> +  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> +  for details.
> +
> +Example:
> + jpegdec: jpegdec@15004000 {
> + compatible = "mediatek,mt2701-jpgdec";
> + reg = <0 0x15004000 0 0x1000>;
> + interrupts = ;
> + clocks =  < CLK_IMG_JPGDEC_SMI>,
> +   < CLK_IMG_JPGDEC>;
> + clock-names = "jpgdec-smi",
> +   "jpgdec";
> + power-domains = < MT2701_POWER_DOMAIN_ISP>;
> + mediatek,larb = <>;
> + iommus = < MT2701_M4U_PORT_JPGDEC_WDMA>,
> +  < MT2701_M4U_PORT_JPGDEC_BSDMA>;
> + };

-- 
Regards,

Laurent Pinchart

Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

[Pandruvada, Srinivas]

On Fri, 2016-11-04 at 23:16 +0100, Pavel Machek wrote:
> Hi!
> 

[...]

> So we seem to have thermal or ACPI regression in v4.9-rc3.
> 
It is possible. Can you add either add printk
in acpi_processor_ppc_has_changed() or use ftrace and see do you get to
these functions

acpi_processor_ppc_init()
acpi_processor_ppc_has_changed()
acpi_processor_ppc_notifier()

?

When temperature limit is reached acpi_processor_ppc_notifier() should
be called.

Thanks,
Srinivas

Re: [v17 2/2] drm/bridge: Add I2C based driver for ps8640 bridge

[Daniel Kurtz]

On Tue, Oct 25, 2016 at 6:23 AM, Matthias Brugger
 wrote:
>
> On 10/18/2016 04:37 PM, Enric Balletbo Serra wrote:
> [...]
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
> [...]
>>>
>>> +
>>> +/* Firmware */
>>> +#define PS_FW_NAME "ps864x_fw.bin"
>>> +
>>
>> From where I can download this firmware image?
>
> I suppose this FW bits have to be added to linux-firmware repository first, 
> before this patch can be accepted.

All PS8640 devices should already ship with working firmware.
The firmware update procedure is only used in the unlikely event where
one wants to update the bridge to a different firmware provided by
Parade.

Why must the lack of firmware really block landing this driver?

If this is really so, can we just land the functional part of the
driver first, and add the firmware update in a follow-up patch.

>
> Regards,
> Matthias

Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

[Pandruvada, Srinivas]

On Fri, 2016-11-04 at 23:16 +0100, Pavel Machek wrote:
> Hi!
> 

[...]

> So we seem to have thermal or ACPI regression in v4.9-rc3.
> 
It is possible. Can you add either add printk
in acpi_processor_ppc_has_changed() or use ftrace and see do you get to
these functions

acpi_processor_ppc_init()
acpi_processor_ppc_has_changed()
acpi_processor_ppc_notifier()

?

When temperature limit is reached acpi_processor_ppc_notifier() should
be called.

Thanks,
Srinivas

Re: [v17 2/2] drm/bridge: Add I2C based driver for ps8640 bridge

[Daniel Kurtz]

On Tue, Oct 25, 2016 at 6:23 AM, Matthias Brugger
 wrote:
>
> On 10/18/2016 04:37 PM, Enric Balletbo Serra wrote:
> [...]
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
> [...]
>>>
>>> +
>>> +/* Firmware */
>>> +#define PS_FW_NAME "ps864x_fw.bin"
>>> +
>>
>> From where I can download this firmware image?
>
> I suppose this FW bits have to be added to linux-firmware repository first, 
> before this patch can be accepted.

All PS8640 devices should already ship with working firmware.
The firmware update procedure is only used in the unlikely event where
one wants to update the bridge to a different firmware provided by
Parade.

Why must the lack of firmware really block landing this driver?

If this is really so, can we just land the functional part of the
driver first, and add the firmware update in a follow-up patch.

>
> Regards,
> Matthias

[PATCH] KVM: nVMX: add tracepoint for vmwrite

[Paolo Bonzini]

Both the field and the value are in registers, so they are not clear from
existing tracepoints.

Cc: Ladi Prosek 
Signed-off-by: Paolo Bonzini 
---
 arch/x86/kvm/trace.h | 23 +++
 arch/x86/kvm/vmx.c   |  2 ++
 2 files changed, 25 insertions(+)

diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h
index 0a6cc6754ec5..b3d4dec78ae2 100644
--- a/arch/x86/kvm/trace.h
+++ b/arch/x86/kvm/trace.h
@@ -723,6 +723,29 @@ TRACE_EVENT(kvm_skinit,
flags;  \
})
 
+/*
+ * Tracepoint for nested #vmexit because of vmwrite
+ */
+TRACE_EVENT(kvm_vmwrite,
+   TP_PROTO(__u64 vmptr, __u16 field, __u64 value),
+   TP_ARGS(vmptr, field, value),
+
+   TP_STRUCT__entry(
+   __field(__u64,  vmptr   )
+   __field(__u16,  field   )
+   __field(__u64,  value   )
+   ),
+
+   TP_fast_assign(
+   __entry->vmptr  =   vmptr;
+   __entry->field  =   field;
+   __entry->value  =   value;
+   ),
+
+   TP_printk("vmcs: 0x%016llx field: 0x%04x value: 0x%llx",
+ __entry->vmptr, __entry->field, __entry->value)
+);
+
 TRACE_EVENT(kvm_emulate_insn,
TP_PROTO(struct kvm_vcpu *vcpu, __u8 failed),
TP_ARGS(vcpu, failed),
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 5382b82462fc..e7d01d7d350b 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -7474,6 +7474,7 @@ static int handle_vmwrite(struct kvm_vcpu *vcpu)
 {
unsigned long field;
gva_t gva;
+   struct vcpu_vmx *vmx = to_vmx(vcpu);
unsigned long exit_qualification = vmcs_readl(EXIT_QUALIFICATION);
u32 vmx_instruction_info = vmcs_read32(VMX_INSTRUCTION_INFO);
/* The value to write might be 32 or 64 bits, depending on L1's long
@@ -7512,6 +7513,7 @@ static int handle_vmwrite(struct kvm_vcpu *vcpu)
return 1;
}
 
+   trace_kvm_vmwrite(vmx->nested.current_vmptr, field, field_value);
if (vmcs12_write_any(vcpu, field, field_value) < 0) {
nested_vmx_failValid(vcpu, VMXERR_UNSUPPORTED_VMCS_COMPONENT);
skip_emulated_instruction(vcpu);
-- 
2.7.4

[PATCH] KVM: nVMX: add tracepoint for vmwrite

[Paolo Bonzini]

Both the field and the value are in registers, so they are not clear from
existing tracepoints.

Cc: Ladi Prosek 
Signed-off-by: Paolo Bonzini 
---
 arch/x86/kvm/trace.h | 23 +++
 arch/x86/kvm/vmx.c   |  2 ++
 2 files changed, 25 insertions(+)

diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h
index 0a6cc6754ec5..b3d4dec78ae2 100644
--- a/arch/x86/kvm/trace.h
+++ b/arch/x86/kvm/trace.h
@@ -723,6 +723,29 @@ TRACE_EVENT(kvm_skinit,
flags;  \
})
 
+/*
+ * Tracepoint for nested #vmexit because of vmwrite
+ */
+TRACE_EVENT(kvm_vmwrite,
+   TP_PROTO(__u64 vmptr, __u16 field, __u64 value),
+   TP_ARGS(vmptr, field, value),
+
+   TP_STRUCT__entry(
+   __field(__u64,  vmptr   )
+   __field(__u16,  field   )
+   __field(__u64,  value   )
+   ),
+
+   TP_fast_assign(
+   __entry->vmptr  =   vmptr;
+   __entry->field  =   field;
+   __entry->value  =   value;
+   ),
+
+   TP_printk("vmcs: 0x%016llx field: 0x%04x value: 0x%llx",
+ __entry->vmptr, __entry->field, __entry->value)
+);
+
 TRACE_EVENT(kvm_emulate_insn,
TP_PROTO(struct kvm_vcpu *vcpu, __u8 failed),
TP_ARGS(vcpu, failed),
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 5382b82462fc..e7d01d7d350b 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -7474,6 +7474,7 @@ static int handle_vmwrite(struct kvm_vcpu *vcpu)
 {
unsigned long field;
gva_t gva;
+   struct vcpu_vmx *vmx = to_vmx(vcpu);
unsigned long exit_qualification = vmcs_readl(EXIT_QUALIFICATION);
u32 vmx_instruction_info = vmcs_read32(VMX_INSTRUCTION_INFO);
/* The value to write might be 32 or 64 bits, depending on L1's long
@@ -7512,6 +7513,7 @@ static int handle_vmwrite(struct kvm_vcpu *vcpu)
return 1;
}
 
+   trace_kvm_vmwrite(vmx->nested.current_vmptr, field, field_value);
if (vmcs12_write_any(vcpu, field, field_value) < 0) {
nested_vmx_failValid(vcpu, VMXERR_UNSUPPORTED_VMCS_COMPONENT);
skip_emulated_instruction(vcpu);
-- 
2.7.4

[PATCH] crypto: caam: do not register AES-XTS mode on LP units

[Sven Ebenfeld]

When using AES-XTS on a Wandboard, we receive a Mode error:
caam_jr 2102000.jr1: 20001311: CCB: desc idx 19: AES: Mode error.

Due to the Security Reference Manual, the Low Power AES units
of the i.MX6 do not support the XTS mode. Therefore we should
try to provide them them in the API.

Signed-off-by: Sven Ebenfeld 
---
 drivers/crypto/caam/caamalg.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index 156aad1..f5a63ba 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -4583,6 +4583,15 @@ static int __init caam_algapi_init(void)
if (!aes_inst && (alg_sel == OP_ALG_ALGSEL_AES))
continue;
 
+   /*
+* Check support for AES modes not available
+* on LP devices.
+*/
+   if ((cha_vid & CHA_ID_LS_AES_MASK) == CHA_ID_LS_AES_LP)
+   if ((alg->class1_alg_type & OP_ALG_AAI_MASK) ==
+OP_ALG_AAI_XTS)
+   continue;
+
t_alg = caam_alg_alloc(alg);
if (IS_ERR(t_alg)) {
err = PTR_ERR(t_alg);
-- 
2.7.4

[PATCH] crypto: caam: do not register AES-XTS mode on LP units

[Sven Ebenfeld]

When using AES-XTS on a Wandboard, we receive a Mode error:
caam_jr 2102000.jr1: 20001311: CCB: desc idx 19: AES: Mode error.

Due to the Security Reference Manual, the Low Power AES units
of the i.MX6 do not support the XTS mode. Therefore we should
try to provide them them in the API.

Signed-off-by: Sven Ebenfeld 
---
 drivers/crypto/caam/caamalg.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index 156aad1..f5a63ba 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -4583,6 +4583,15 @@ static int __init caam_algapi_init(void)
if (!aes_inst && (alg_sel == OP_ALG_ALGSEL_AES))
continue;
 
+   /*
+* Check support for AES modes not available
+* on LP devices.
+*/
+   if ((cha_vid & CHA_ID_LS_AES_MASK) == CHA_ID_LS_AES_LP)
+   if ((alg->class1_alg_type & OP_ALG_AAI_MASK) ==
+OP_ALG_AAI_XTS)
+   continue;
+
t_alg = caam_alg_alloc(alg);
if (IS_ERR(t_alg)) {
err = PTR_ERR(t_alg);
-- 
2.7.4

Re: [PATCH 1/4] block: add scalable completion tracking of requests

[Ming Lei]

On Fri, Nov 4, 2016 at 12:55 AM, Jens Axboe  wrote:
> On 11/03/2016 08:57 AM, Ming Lei wrote:
>>
>> On Thu, Nov 3, 2016 at 9:38 PM, Jens Axboe  wrote:
>>>
>>> On 11/03/2016 05:17 AM, Ming Lei wrote:
>
>
> diff --git a/block/blk-core.c b/block/blk-core.c
> index 0bfaa54d3e9f..ca77c725b4e5 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -2462,6 +2462,8 @@ void blk_start_request(struct request *req)
>  {
> blk_dequeue_request(req);
>
> +   blk_stat_set_issue_time(>issue_stat);
> +
> /*
>  * We are now handing the request to the hardware, initialize
>  * resid_len to full count and add the timeout handler.
> @@ -2529,6 +2531,8 @@ bool blk_update_request(struct request *req, int
> error, unsigned int nr_bytes)
>
> trace_block_rq_complete(req->q, req, nr_bytes);
>
> +   blk_stat_add(>q->rq_stats[rq_data_dir(req)], req);



 blk_update_request() is often called lockless, so it isn't good to
 do it here.
>>>
>>>
>>>
>>> It's not really a concern, not for the legacy path here nor the mq one
>>> where it is per sw context. The collisions are rare enough that it'll
>>
>>
>> How do you get the conclusion that the collisions are rare enough
>> when the counting becomes completely lockless?
>
>
> Of all the races I can spot, it basically boils down to accounting one
> IO to little or too many.
>
>> Even though it is true, the statistics still may become a mess with rare
>> collisons.
>
>
> How so? Not saying we could not improve it, but we're trading off
> precision for scalability. My claim is that the existing code is good
> enough. I've run a TON of testing on it, since I've used it for multiple
> projects, and it's been solid.

+static void blk_stat_flush_batch(struct blk_rq_stat *stat)
+{
+   if (!stat->nr_batch)
+   return;
+   if (!stat->nr_samples)
+   stat->mean = div64_s64(stat->batch, stat->nr_batch);

For example, two reqs(A & B) are completed at the same time, and
A is on CPU0, and B is on CPU1.

If the two last writting in the function is reordered observed from CPU1,
for B, CPU1 runs the above branch when it just sees stat->batch is set as zero,
but nr_samples isn't updated yet, then div_zero is triggered.


+   else {
+   stat->mean = div64_s64((stat->mean * stat->nr_samples) +
+   stat->batch,
+   stat->nr_samples + stat->nr_batch);
+   }

BTW, the above 'if else' can be removed, and 'stat->mean' can be computed
in the 2nd way.

+
+   stat->nr_samples += stat->nr_batch;

one addition of stat->nr_batch can be overrideed, and it may not
be accounted into stat->mean at all.

+   stat->nr_batch = stat->batch = 0;
+}

>
>>> skew the latencies a bit for that short window, but then go away again.
>>> I'd much rather take that, than adding locking for this part.
>>
>>
>> For legacy case, blk_stat_add() can be moved into blk_finish_request()
>> for avoiding the collision.
>
>
> Yes, that might be a good idea, since it doesn't cost us anything. For
> the mq case, I'm hard pressed to think of areas where we could complete
> IO in parallel on the same software queue. You'll never have a software
> queue mapped to multiple hardware queues. So we should essentially be
> serialized.

For blk-mq, blk_mq_stat_add() is called in __blk_mq_complete_request()
which is often run from interrupt handler, and the CPU serving the interrupt
can be different with the submitting CPU for rq->mq_ctx. And there can be
several CPUs handling the interrupts originating from same sw queue.

BTW, I don't object to this patch actually, but maybe we should add
comment about this kind of race. Cause in the future someone might find
the statistics becomes not accurate, and they may understand or
try to improve.


Thanks,
Ming Lei

Re: [PATCH 1/4] block: add scalable completion tracking of requests

[Ming Lei]

On Fri, Nov 4, 2016 at 12:55 AM, Jens Axboe  wrote:
> On 11/03/2016 08:57 AM, Ming Lei wrote:
>>
>> On Thu, Nov 3, 2016 at 9:38 PM, Jens Axboe  wrote:
>>>
>>> On 11/03/2016 05:17 AM, Ming Lei wrote:
>
>
> diff --git a/block/blk-core.c b/block/blk-core.c
> index 0bfaa54d3e9f..ca77c725b4e5 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -2462,6 +2462,8 @@ void blk_start_request(struct request *req)
>  {
> blk_dequeue_request(req);
>
> +   blk_stat_set_issue_time(>issue_stat);
> +
> /*
>  * We are now handing the request to the hardware, initialize
>  * resid_len to full count and add the timeout handler.
> @@ -2529,6 +2531,8 @@ bool blk_update_request(struct request *req, int
> error, unsigned int nr_bytes)
>
> trace_block_rq_complete(req->q, req, nr_bytes);
>
> +   blk_stat_add(>q->rq_stats[rq_data_dir(req)], req);



 blk_update_request() is often called lockless, so it isn't good to
 do it here.
>>>
>>>
>>>
>>> It's not really a concern, not for the legacy path here nor the mq one
>>> where it is per sw context. The collisions are rare enough that it'll
>>
>>
>> How do you get the conclusion that the collisions are rare enough
>> when the counting becomes completely lockless?
>
>
> Of all the races I can spot, it basically boils down to accounting one
> IO to little or too many.
>
>> Even though it is true, the statistics still may become a mess with rare
>> collisons.
>
>
> How so? Not saying we could not improve it, but we're trading off
> precision for scalability. My claim is that the existing code is good
> enough. I've run a TON of testing on it, since I've used it for multiple
> projects, and it's been solid.

+static void blk_stat_flush_batch(struct blk_rq_stat *stat)
+{
+   if (!stat->nr_batch)
+   return;
+   if (!stat->nr_samples)
+   stat->mean = div64_s64(stat->batch, stat->nr_batch);

For example, two reqs(A & B) are completed at the same time, and
A is on CPU0, and B is on CPU1.

If the two last writting in the function is reordered observed from CPU1,
for B, CPU1 runs the above branch when it just sees stat->batch is set as zero,
but nr_samples isn't updated yet, then div_zero is triggered.


+   else {
+   stat->mean = div64_s64((stat->mean * stat->nr_samples) +
+   stat->batch,
+   stat->nr_samples + stat->nr_batch);
+   }

BTW, the above 'if else' can be removed, and 'stat->mean' can be computed
in the 2nd way.

+
+   stat->nr_samples += stat->nr_batch;

one addition of stat->nr_batch can be overrideed, and it may not
be accounted into stat->mean at all.

+   stat->nr_batch = stat->batch = 0;
+}

>
>>> skew the latencies a bit for that short window, but then go away again.
>>> I'd much rather take that, than adding locking for this part.
>>
>>
>> For legacy case, blk_stat_add() can be moved into blk_finish_request()
>> for avoiding the collision.
>
>
> Yes, that might be a good idea, since it doesn't cost us anything. For
> the mq case, I'm hard pressed to think of areas where we could complete
> IO in parallel on the same software queue. You'll never have a software
> queue mapped to multiple hardware queues. So we should essentially be
> serialized.

For blk-mq, blk_mq_stat_add() is called in __blk_mq_complete_request()
which is often run from interrupt handler, and the CPU serving the interrupt
can be different with the submitting CPU for rq->mq_ctx. And there can be
several CPUs handling the interrupts originating from same sw queue.

BTW, I don't object to this patch actually, but maybe we should add
comment about this kind of race. Cause in the future someone might find
the statistics becomes not accurate, and they may understand or
try to improve.


Thanks,
Ming Lei

Re: [PATCH 3/4] rtc: Enable compile testing for Maxim and Samsung drivers

[Alexandre Belloni]

On 02/10/2016 at 22:58:16 +0200, Krzysztof Kozlowski wrote :
> max8907, max77686 and s5m RTC drivers can be compile tested to increase
> build coverage.  The s5m-rtc uses REGMAP_IRQ so add this as explicit
> dependency.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  drivers/rtc/Kconfig | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
Applied, thanks.

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

Re: [PATCH 3/4] rtc: Enable compile testing for Maxim and Samsung drivers

[Alexandre Belloni]

On 02/10/2016 at 22:58:16 +0200, Krzysztof Kozlowski wrote :
> max8907, max77686 and s5m RTC drivers can be compile tested to increase
> build coverage.  The s5m-rtc uses REGMAP_IRQ so add this as explicit
> dependency.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  drivers/rtc/Kconfig | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
Applied, thanks.

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

Re: [PATCH v3 1/7] rtc: rtc-jz4740: Add support for the RTC in the jz4780 SoC

[Alexandre Belloni]

On 31/10/2016 at 21:39:45 +0100, Paul Cercueil wrote :
> The RTC unit present in the JZ4780 works mostly the same as the one in
> the JZ4740. The major difference is that register writes need to be
> explicitly enabled, by writing a magic code (0xA55A) to a "write
> enable" register before each access.
> 
> Signed-off-by: Paul Cercueil 
> Acked-by: Maarten ter Huurne 
> ---
>  drivers/rtc/Kconfig  |  6 +++---
>  drivers/rtc/rtc-jz4740.c | 50 
> ++--
>  2 files changed, 51 insertions(+), 5 deletions(-)
> 
> v2: No change
> v3: No change
> 

All applied, thanks


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

Re: [PATCH v3 1/7] rtc: rtc-jz4740: Add support for the RTC in the jz4780 SoC

[Alexandre Belloni]

On 31/10/2016 at 21:39:45 +0100, Paul Cercueil wrote :
> The RTC unit present in the JZ4780 works mostly the same as the one in
> the JZ4740. The major difference is that register writes need to be
> explicitly enabled, by writing a magic code (0xA55A) to a "write
> enable" register before each access.
> 
> Signed-off-by: Paul Cercueil 
> Acked-by: Maarten ter Huurne 
> ---
>  drivers/rtc/Kconfig  |  6 +++---
>  drivers/rtc/rtc-jz4740.c | 50 
> ++--
>  2 files changed, 51 insertions(+), 5 deletions(-)
> 
> v2: No change
> v3: No change
> 

All applied, thanks


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

Re: Children Under Miserable Condition

[Mrs. Maima Farooq]

Good Day,

As an Aging widow with no child, suffering from long time incurable illness; 
presently admitted in a private hospital.

I decided to give away my estate to the vulnerable through a sincere person.

This is because at this point, life seems miserable for there is nobody to 
inherit my estate.

Can I confide in you to set up an orphanage home under my sponsorship?

Can you volunteer or make yourself available in putting smiles on the faces of 
the poor or an end to the sufferings of our children out there?

If you are willing, get back at me for more details.

Mrs. Maim Farooq

Re: Children Under Miserable Condition

[Mrs. Maima Farooq]

Good Day,

As an Aging widow with no child, suffering from long time incurable illness; 
presently admitted in a private hospital.

I decided to give away my estate to the vulnerable through a sincere person.

This is because at this point, life seems miserable for there is nobody to 
inherit my estate.

Can I confide in you to set up an orphanage home under my sponsorship?

Can you volunteer or make yourself available in putting smiles on the faces of 
the poor or an end to the sufferings of our children out there?

If you are willing, get back at me for more details.

Mrs. Maim Farooq

Re: [PATCH V5] pinctrl: qcom: Add msm8994 pinctrl driver

[Linus Walleij]

On Thu, Nov 3, 2016 at 10:15 PM, Michael Scott  wrote:

> Initial pinctrl driver for QCOM msm8994 platforms.
>
> In order to continue the initial board support for QCOM msm8994/msm8992
> presented in patches from Jeremy McNicoll , let's put
> a proper pinctrl driver in place.
>
> Currently, the DT for these platforms uses the msm8x74 pinctrl driver to
> enable basic UART.  Beyond the first few pins the rest are different enough
> to justify it's own driver.
>
> Note: This driver is also used by QCOM's msm8992 platform as it's TLM block
> is the same.
>
> - Initial formatting and style was taken from the msm8x74 pinctrl driver
>   added by Björn Andersson 
> - Data was then adjusted per QCOM MSM8994v2 documentation for Top Level
>   Multiplexing
> - Bindings documentation was based on qcom,msm8996-pinctrl.txt by
>   Joonwoo Park  and then modified for msm8994
>   content
>
> Signed-off-by: Michael Scott 
> Tested-by: Jeremy McNicoll 
> Acked-by: Bjorn Andersson 
> Acked-by: Rob Herring 
> ---
> V5:

This v5 version applied.

Yours,
Linus Walleij

Re: [PATCH V5] pinctrl: qcom: Add msm8994 pinctrl driver

[Linus Walleij]

On Thu, Nov 3, 2016 at 10:15 PM, Michael Scott  wrote:

> Initial pinctrl driver for QCOM msm8994 platforms.
>
> In order to continue the initial board support for QCOM msm8994/msm8992
> presented in patches from Jeremy McNicoll , let's put
> a proper pinctrl driver in place.
>
> Currently, the DT for these platforms uses the msm8x74 pinctrl driver to
> enable basic UART.  Beyond the first few pins the rest are different enough
> to justify it's own driver.
>
> Note: This driver is also used by QCOM's msm8992 platform as it's TLM block
> is the same.
>
> - Initial formatting and style was taken from the msm8x74 pinctrl driver
>   added by Björn Andersson 
> - Data was then adjusted per QCOM MSM8994v2 documentation for Top Level
>   Multiplexing
> - Bindings documentation was based on qcom,msm8996-pinctrl.txt by
>   Joonwoo Park  and then modified for msm8994
>   content
>
> Signed-off-by: Michael Scott 
> Tested-by: Jeremy McNicoll 
> Acked-by: Bjorn Andersson 
> Acked-by: Rob Herring 
> ---
> V5:

This v5 version applied.

Yours,
Linus Walleij

[PATCH 2/2] f2fs: remove checkpoint in f2fs_freeze

[Jaegeuk Kim]

The generic freeze_super() calls sync_filesystems() before f2fs_freeze().
So, basically we don't need to do checkpoint in f2fs_freeze(). But, in xfs/068,
it triggers circular locking problem below due to gc_mutex for checkpoint.

==
[ INFO: possible circular locking dependency detected ]
4.9.0-rc1+ #132 Tainted: G   OE
---

1. wait for __sb_start_write() by

 [] dump_stack+0x85/0xc2
 [] print_circular_bug+0x1cf/0x230
 [] __lock_acquire+0x19e0/0x1bc0
 [] lock_acquire+0x11b/0x220
 [] ? f2fs_drop_inode+0x9b/0x160 [f2fs]
 [] __sb_start_write+0x130/0x200
 [] ? f2fs_drop_inode+0x9b/0x160 [f2fs]
 [] f2fs_drop_inode+0x9b/0x160 [f2fs]
 [] iput+0x171/0x2c0
 [] f2fs_sync_inode_meta+0x3f/0xf0 [f2fs]
 [] block_operations+0x84/0x110 [f2fs]
 [] write_checkpoint+0xe8/0xf20 [f2fs]
 [] ? trace_hardirqs_on+0xd/0x10
 [] ? f2fs_sync_fs+0x79/0x190 [f2fs]
 [] ? sched_clock+0x9/0x10
 [] ? f2fs_sync_fs+0x79/0x190 [f2fs]
 [] f2fs_sync_fs+0x85/0x190 [f2fs]
 [] ? do_fsync+0x70/0x70
 [] ? do_fsync+0x70/0x70
 [] sync_fs_one_sb+0x20/0x30
 [] iterate_supers+0xae/0x100
 [] sys_sync+0x55/0x90
 [] entry_SYSCALL_64_fastpath+0x23/0xc6

2. wait for sbi->gc_mutex by

 [] lock_acquire+0x11b/0x220
 [] mutex_lock_nested+0x76/0x3f0
 [] f2fs_sync_fs+0x79/0x190 [f2fs]
 [] f2fs_freeze+0x1c/0x20 [f2fs]
 [] freeze_super+0xcf/0x190
 [] do_vfs_ioctl+0x53c/0x6a0
 [] SyS_ioctl+0x79/0x90
 [] entry_SYSCALL_64_fastpath+0x23/0xc6

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/super.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 12a4f3f..eca9aea 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -800,13 +800,17 @@ int f2fs_sync_fs(struct super_block *sb, int sync)
 
 static int f2fs_freeze(struct super_block *sb)
 {
-   int err;
-
if (f2fs_readonly(sb))
return 0;
 
-   err = f2fs_sync_fs(sb, 1);
-   return err;
+   /* IO error happened before */
+   if (unlikely(f2fs_cp_error(F2FS_SB(sb
+   return -EIO;
+
+   /* must be clean, since sync_filesystem() was already called */
+   if (is_sbi_flag_set(F2FS_SB(sb), SBI_IS_DIRTY))
+   return -EINVAL;
+   return 0;
 }
 
 static int f2fs_unfreeze(struct super_block *sb)
@@ -2152,3 +2156,4 @@ module_exit(exit_f2fs_fs)
 MODULE_AUTHOR("Samsung Electronics's Praesto Team");
 MODULE_DESCRIPTION("Flash Friendly File System");
 MODULE_LICENSE("GPL");
+
-- 
2.8.3

[PATCH 2/2] f2fs: remove checkpoint in f2fs_freeze

[Jaegeuk Kim]

The generic freeze_super() calls sync_filesystems() before f2fs_freeze().
So, basically we don't need to do checkpoint in f2fs_freeze(). But, in xfs/068,
it triggers circular locking problem below due to gc_mutex for checkpoint.

==
[ INFO: possible circular locking dependency detected ]
4.9.0-rc1+ #132 Tainted: G   OE
---

1. wait for __sb_start_write() by

 [] dump_stack+0x85/0xc2
 [] print_circular_bug+0x1cf/0x230
 [] __lock_acquire+0x19e0/0x1bc0
 [] lock_acquire+0x11b/0x220
 [] ? f2fs_drop_inode+0x9b/0x160 [f2fs]
 [] __sb_start_write+0x130/0x200
 [] ? f2fs_drop_inode+0x9b/0x160 [f2fs]
 [] f2fs_drop_inode+0x9b/0x160 [f2fs]
 [] iput+0x171/0x2c0
 [] f2fs_sync_inode_meta+0x3f/0xf0 [f2fs]
 [] block_operations+0x84/0x110 [f2fs]
 [] write_checkpoint+0xe8/0xf20 [f2fs]
 [] ? trace_hardirqs_on+0xd/0x10
 [] ? f2fs_sync_fs+0x79/0x190 [f2fs]
 [] ? sched_clock+0x9/0x10
 [] ? f2fs_sync_fs+0x79/0x190 [f2fs]
 [] f2fs_sync_fs+0x85/0x190 [f2fs]
 [] ? do_fsync+0x70/0x70
 [] ? do_fsync+0x70/0x70
 [] sync_fs_one_sb+0x20/0x30
 [] iterate_supers+0xae/0x100
 [] sys_sync+0x55/0x90
 [] entry_SYSCALL_64_fastpath+0x23/0xc6

2. wait for sbi->gc_mutex by

 [] lock_acquire+0x11b/0x220
 [] mutex_lock_nested+0x76/0x3f0
 [] f2fs_sync_fs+0x79/0x190 [f2fs]
 [] f2fs_freeze+0x1c/0x20 [f2fs]
 [] freeze_super+0xcf/0x190
 [] do_vfs_ioctl+0x53c/0x6a0
 [] SyS_ioctl+0x79/0x90
 [] entry_SYSCALL_64_fastpath+0x23/0xc6

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/super.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 12a4f3f..eca9aea 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -800,13 +800,17 @@ int f2fs_sync_fs(struct super_block *sb, int sync)
 
 static int f2fs_freeze(struct super_block *sb)
 {
-   int err;
-
if (f2fs_readonly(sb))
return 0;
 
-   err = f2fs_sync_fs(sb, 1);
-   return err;
+   /* IO error happened before */
+   if (unlikely(f2fs_cp_error(F2FS_SB(sb
+   return -EIO;
+
+   /* must be clean, since sync_filesystem() was already called */
+   if (is_sbi_flag_set(F2FS_SB(sb), SBI_IS_DIRTY))
+   return -EINVAL;
+   return 0;
 }
 
 static int f2fs_unfreeze(struct super_block *sb)
@@ -2152,3 +2156,4 @@ module_exit(exit_f2fs_fs)
 MODULE_AUTHOR("Samsung Electronics's Praesto Team");
 MODULE_DESCRIPTION("Flash Friendly File System");
 MODULE_LICENSE("GPL");
+
-- 
2.8.3

[PATCH 1/2] f2fs: assign segments correctly for direct_io

[Jaegeuk Kim]

Previously, we assigned CURSEG_WARM_DATA for direct_io, but if we have two or
four logs, we do not use that type at all.
Let's fix it.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/segment.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 6ba4cd4..819209b 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -1501,8 +1501,12 @@ void allocate_data_block(struct f2fs_sb_info *sbi, 
struct page *page,
struct curseg_info *curseg;
bool direct_io = (type == CURSEG_DIRECT_IO);
 
-   type = direct_io ? CURSEG_WARM_DATA : type;
-
+   if (direct_io) {
+   if (sbi->active_logs <= 4)
+   type = CURSEG_HOT_DATA;
+   else
+   type = CURSEG_WARM_DATA;
+   }
curseg = CURSEG_I(sbi, type);
 
mutex_lock(>curseg_mutex);
-- 
2.8.3

[PATCH 1/2] f2fs: assign segments correctly for direct_io

[Jaegeuk Kim]

Previously, we assigned CURSEG_WARM_DATA for direct_io, but if we have two or
four logs, we do not use that type at all.
Let's fix it.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/segment.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 6ba4cd4..819209b 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -1501,8 +1501,12 @@ void allocate_data_block(struct f2fs_sb_info *sbi, 
struct page *page,
struct curseg_info *curseg;
bool direct_io = (type == CURSEG_DIRECT_IO);
 
-   type = direct_io ? CURSEG_WARM_DATA : type;
-
+   if (direct_io) {
+   if (sbi->active_logs <= 4)
+   type = CURSEG_HOT_DATA;
+   else
+   type = CURSEG_WARM_DATA;
+   }
curseg = CURSEG_I(sbi, type);
 
mutex_lock(>curseg_mutex);
-- 
2.8.3

Re: [PATCH 2/2] f2fs: don't skip recovering inode depend on i_times

[Jaegeuk Kim]

On Fri, Nov 04, 2016 at 04:30:09PM +0800, Chao Yu wrote:
> On 2016/11/4 2:02, Jaegeuk Kim wrote:
> > On Fri, Nov 04, 2016 at 12:26:56AM +0800, Chao Yu wrote:
> >> From: Chao Yu 
> >>
> >> i_times of inode will be set with current system time which can be
> >> configured through 'date', so it's not safe to judge dnode block as
> >> garbage data depend on i_times.
> > 
> > This is not to detect garbage data, but to skip redundant unchanged inode.
> 
> Oops, seems 807b1e1c8e08 ("f2fs: do not recover from previous remained wrong
> dnodes") did't describe like that. But after reading the codes, it looks like
> the purpose of this change is to skip unchanged inode. So, commit log in
> original is incorrect, right?

Oh, right. This indicats both of purposes: stale data and detecting same inodes.
Let me just revert the original patch.

Thanks,

> 
> Thanks,

Re: [PATCH 2/2] f2fs: don't skip recovering inode depend on i_times

[Jaegeuk Kim]

On Fri, Nov 04, 2016 at 04:30:09PM +0800, Chao Yu wrote:
> On 2016/11/4 2:02, Jaegeuk Kim wrote:
> > On Fri, Nov 04, 2016 at 12:26:56AM +0800, Chao Yu wrote:
> >> From: Chao Yu 
> >>
> >> i_times of inode will be set with current system time which can be
> >> configured through 'date', so it's not safe to judge dnode block as
> >> garbage data depend on i_times.
> > 
> > This is not to detect garbage data, but to skip redundant unchanged inode.
> 
> Oops, seems 807b1e1c8e08 ("f2fs: do not recover from previous remained wrong
> dnodes") did't describe like that. But after reading the codes, it looks like
> the purpose of this change is to skip unchanged inode. So, commit log in
> original is incorrect, right?

Oh, right. This indicats both of purposes: stale data and detecting same inodes.
Let me just revert the original patch.

Thanks,

> 
> Thanks,

[PATCH net-next 5/5] net: l2tp: fix negative assignment to unsigned int

[Asbjoern Sloth Toennesen]

recv_seq, send_seq and lns_mode mode are all defined as
unsigned int foo:1;

Signed-off-by: Asbjoern Sloth Toennesen 
---
 net/l2tp/l2tp_core.c | 2 +-
 net/l2tp/l2tp_ppp.c  | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
index a2ed3bd..85948c6 100644
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -715,7 +715,7 @@ void l2tp_recv_common(struct l2tp_session *session, struct 
sk_buff *skb,
l2tp_info(session, L2TP_MSG_SEQ,
  "%s: requested to enable seq numbers by 
LNS\n",
  session->name);
-   session->send_seq = -1;
+   session->send_seq = 1;
l2tp_session_set_header_len(session, tunnel->version);
}
} else {
diff --git a/net/l2tp/l2tp_ppp.c b/net/l2tp/l2tp_ppp.c
index 41d47bf..2ddfec1 100644
--- a/net/l2tp/l2tp_ppp.c
+++ b/net/l2tp/l2tp_ppp.c
@@ -1272,7 +1272,7 @@ static int pppol2tp_session_setsockopt(struct sock *sk,
err = -EINVAL;
break;
}
-   session->recv_seq = val ? -1 : 0;
+   session->recv_seq = !!val;
l2tp_info(session, PPPOL2TP_MSG_CONTROL,
  "%s: set recv_seq=%d\n",
  session->name, session->recv_seq);
@@ -1283,7 +1283,7 @@ static int pppol2tp_session_setsockopt(struct sock *sk,
err = -EINVAL;
break;
}
-   session->send_seq = val ? -1 : 0;
+   session->send_seq = !!val;
{
struct sock *ssk  = ps->sock;
struct pppox_sock *po = pppox_sk(ssk);
@@ -1301,7 +1301,7 @@ static int pppol2tp_session_setsockopt(struct sock *sk,
err = -EINVAL;
break;
}
-   session->lns_mode = val ? -1 : 0;
+   session->lns_mode = !!val;
l2tp_info(session, PPPOL2TP_MSG_CONTROL,
  "%s: set lns_mode=%d\n",
  session->name, session->lns_mode);
-- 
2.10.1

[PATCH net-next 5/5] net: l2tp: fix negative assignment to unsigned int

[Asbjoern Sloth Toennesen]

recv_seq, send_seq and lns_mode mode are all defined as
unsigned int foo:1;

Signed-off-by: Asbjoern Sloth Toennesen 
---
 net/l2tp/l2tp_core.c | 2 +-
 net/l2tp/l2tp_ppp.c  | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
index a2ed3bd..85948c6 100644
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -715,7 +715,7 @@ void l2tp_recv_common(struct l2tp_session *session, struct 
sk_buff *skb,
l2tp_info(session, L2TP_MSG_SEQ,
  "%s: requested to enable seq numbers by 
LNS\n",
  session->name);
-   session->send_seq = -1;
+   session->send_seq = 1;
l2tp_session_set_header_len(session, tunnel->version);
}
} else {
diff --git a/net/l2tp/l2tp_ppp.c b/net/l2tp/l2tp_ppp.c
index 41d47bf..2ddfec1 100644
--- a/net/l2tp/l2tp_ppp.c
+++ b/net/l2tp/l2tp_ppp.c
@@ -1272,7 +1272,7 @@ static int pppol2tp_session_setsockopt(struct sock *sk,
err = -EINVAL;
break;
}
-   session->recv_seq = val ? -1 : 0;
+   session->recv_seq = !!val;
l2tp_info(session, PPPOL2TP_MSG_CONTROL,
  "%s: set recv_seq=%d\n",
  session->name, session->recv_seq);
@@ -1283,7 +1283,7 @@ static int pppol2tp_session_setsockopt(struct sock *sk,
err = -EINVAL;
break;
}
-   session->send_seq = val ? -1 : 0;
+   session->send_seq = !!val;
{
struct sock *ssk  = ps->sock;
struct pppox_sock *po = pppox_sk(ssk);
@@ -1301,7 +1301,7 @@ static int pppol2tp_session_setsockopt(struct sock *sk,
err = -EINVAL;
break;
}
-   session->lns_mode = val ? -1 : 0;
+   session->lns_mode = !!val;
l2tp_info(session, PPPOL2TP_MSG_CONTROL,
  "%s: set lns_mode=%d\n",
  session->name, session->lns_mode);
-- 
2.10.1

[PATCH net-next 4/5] net: l2tp: cleanup: remove redundant condition

[Asbjoern Sloth Toennesen]

These assignments follow this pattern:

unsigned int foo:1;
struct nlattr *nla = info->attrs[bar];

if (nla)
foo = nla_get_flag(nla); /* expands to: foo = !!nla */

This could be simplified to: if (nla) foo = 1;
but lets just remove the condition and use the macro,

foo = nla_get_flag(nla);

Signed-off-by: Asbjoern Sloth Toennesen 
---
 net/l2tp/l2tp_netlink.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/net/l2tp/l2tp_netlink.c b/net/l2tp/l2tp_netlink.c
index 1b3fcde..abf6bf1 100644
--- a/net/l2tp/l2tp_netlink.c
+++ b/net/l2tp/l2tp_netlink.c
@@ -220,14 +220,14 @@ static int l2tp_nl_cmd_tunnel_create(struct sk_buff *skb, 
struct genl_info *info
cfg.local_udp_port = 
nla_get_u16(info->attrs[L2TP_ATTR_UDP_SPORT]);
if (info->attrs[L2TP_ATTR_UDP_DPORT])
cfg.peer_udp_port = 
nla_get_u16(info->attrs[L2TP_ATTR_UDP_DPORT]);
-   if (info->attrs[L2TP_ATTR_UDP_CSUM])
-   cfg.use_udp_checksums = 
nla_get_flag(info->attrs[L2TP_ATTR_UDP_CSUM]);
+   cfg.use_udp_checksums = nla_get_flag(
+   info->attrs[L2TP_ATTR_UDP_CSUM]);
 
 #if IS_ENABLED(CONFIG_IPV6)
-   if (info->attrs[L2TP_ATTR_UDP_ZERO_CSUM6_TX])
-   cfg.udp6_zero_tx_checksums = 
nla_get_flag(info->attrs[L2TP_ATTR_UDP_ZERO_CSUM6_TX]);
-   if (info->attrs[L2TP_ATTR_UDP_ZERO_CSUM6_RX])
-   cfg.udp6_zero_rx_checksums = 
nla_get_flag(info->attrs[L2TP_ATTR_UDP_ZERO_CSUM6_RX]);
+   cfg.udp6_zero_tx_checksums = nla_get_flag(
+   info->attrs[L2TP_ATTR_UDP_ZERO_CSUM6_TX]);
+   cfg.udp6_zero_rx_checksums = nla_get_flag(
+   info->attrs[L2TP_ATTR_UDP_ZERO_CSUM6_RX]);
 #endif
}
 
-- 
2.10.1

[PATCH net-next 4/5] net: l2tp: cleanup: remove redundant condition

[Asbjoern Sloth Toennesen]

These assignments follow this pattern:

unsigned int foo:1;
struct nlattr *nla = info->attrs[bar];

if (nla)
foo = nla_get_flag(nla); /* expands to: foo = !!nla */

This could be simplified to: if (nla) foo = 1;
but lets just remove the condition and use the macro,

foo = nla_get_flag(nla);

Signed-off-by: Asbjoern Sloth Toennesen 
---
 net/l2tp/l2tp_netlink.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/net/l2tp/l2tp_netlink.c b/net/l2tp/l2tp_netlink.c
index 1b3fcde..abf6bf1 100644
--- a/net/l2tp/l2tp_netlink.c
+++ b/net/l2tp/l2tp_netlink.c
@@ -220,14 +220,14 @@ static int l2tp_nl_cmd_tunnel_create(struct sk_buff *skb, 
struct genl_info *info
cfg.local_udp_port = 
nla_get_u16(info->attrs[L2TP_ATTR_UDP_SPORT]);
if (info->attrs[L2TP_ATTR_UDP_DPORT])
cfg.peer_udp_port = 
nla_get_u16(info->attrs[L2TP_ATTR_UDP_DPORT]);
-   if (info->attrs[L2TP_ATTR_UDP_CSUM])
-   cfg.use_udp_checksums = 
nla_get_flag(info->attrs[L2TP_ATTR_UDP_CSUM]);
+   cfg.use_udp_checksums = nla_get_flag(
+   info->attrs[L2TP_ATTR_UDP_CSUM]);
 
 #if IS_ENABLED(CONFIG_IPV6)
-   if (info->attrs[L2TP_ATTR_UDP_ZERO_CSUM6_TX])
-   cfg.udp6_zero_tx_checksums = 
nla_get_flag(info->attrs[L2TP_ATTR_UDP_ZERO_CSUM6_TX]);
-   if (info->attrs[L2TP_ATTR_UDP_ZERO_CSUM6_RX])
-   cfg.udp6_zero_rx_checksums = 
nla_get_flag(info->attrs[L2TP_ATTR_UDP_ZERO_CSUM6_RX]);
+   cfg.udp6_zero_tx_checksums = nla_get_flag(
+   info->attrs[L2TP_ATTR_UDP_ZERO_CSUM6_TX]);
+   cfg.udp6_zero_rx_checksums = nla_get_flag(
+   info->attrs[L2TP_ATTR_UDP_ZERO_CSUM6_RX]);
 #endif
}
 
-- 
2.10.1

[PATCH net-next 1/5] net: l2tp: fix L2TP_ATTR_UDP_CSUM attribute type

[Asbjoern Sloth Toennesen]

L2TP_ATTR_UDP_CSUM is a flag, and gets read with
nla_get_flag, but it is defined as NLA_U8 in
the nla_policy.

It appears that this is only publicly used in
iproute2, where it's broken, because it's used as
a NLA_FLAG, and fails validation as a NLA_U8.

The only place it's used as a NLA_U8 is in
l2tp_nl_tunnel_send(), but iproute2 again reads that
as a flag, it's therefore always set. Fortunately
it is never used for anything, just read.

CC: Miao Wang 
Signed-off-by: Asbjoern Sloth Toennesen 
---
 include/uapi/linux/l2tp.h |  2 +-
 net/l2tp/l2tp_netlink.c   | 12 +---
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/include/uapi/linux/l2tp.h b/include/uapi/linux/l2tp.h
index 4bd27d0..73e3a23 100644
--- a/include/uapi/linux/l2tp.h
+++ b/include/uapi/linux/l2tp.h
@@ -104,7 +104,7 @@ enum {
L2TP_ATTR_PEER_CONN_ID, /* u32 */
L2TP_ATTR_SESSION_ID,   /* u32 */
L2TP_ATTR_PEER_SESSION_ID,  /* u32 */
-   L2TP_ATTR_UDP_CSUM, /* u8 */
+   L2TP_ATTR_UDP_CSUM, /* flag */
L2TP_ATTR_VLAN_ID,  /* u16 */
L2TP_ATTR_COOKIE,   /* 0, 4 or 8 bytes */
L2TP_ATTR_PEER_COOKIE,  /* 0, 4 or 8 bytes */
diff --git a/net/l2tp/l2tp_netlink.c b/net/l2tp/l2tp_netlink.c
index 59aa2d2..1fe05da 100644
--- a/net/l2tp/l2tp_netlink.c
+++ b/net/l2tp/l2tp_netlink.c
@@ -379,9 +379,15 @@ static int l2tp_nl_tunnel_send(struct sk_buff *skb, u32 
portid, u32 seq, int fla
 
switch (tunnel->encap) {
case L2TP_ENCAPTYPE_UDP:
+   switch (sk->sk_family) {
+   case AF_INET:
+   if ((!sk->sk_no_check_tx) &&
+   nla_put_flag(skb, L2TP_ATTR_UDP_CSUM))
+   goto nla_put_failure;
+   break;
+   }
if (nla_put_u16(skb, L2TP_ATTR_UDP_SPORT, 
ntohs(inet->inet_sport)) ||
-   nla_put_u16(skb, L2TP_ATTR_UDP_DPORT, 
ntohs(inet->inet_dport)) ||
-   nla_put_u8(skb, L2TP_ATTR_UDP_CSUM, !sk->sk_no_check_tx))
+   nla_put_u16(skb, L2TP_ATTR_UDP_DPORT, 
ntohs(inet->inet_dport)))
goto nla_put_failure;
/* NOBREAK */
case L2TP_ENCAPTYPE_IP:
@@ -873,7 +879,7 @@ static const struct nla_policy l2tp_nl_policy[L2TP_ATTR_MAX 
+ 1] = {
[L2TP_ATTR_PEER_CONN_ID]= { .type = NLA_U32, },
[L2TP_ATTR_SESSION_ID]  = { .type = NLA_U32, },
[L2TP_ATTR_PEER_SESSION_ID] = { .type = NLA_U32, },
-   [L2TP_ATTR_UDP_CSUM]= { .type = NLA_U8, },
+   [L2TP_ATTR_UDP_CSUM]= { .type = NLA_FLAG, },
[L2TP_ATTR_VLAN_ID] = { .type = NLA_U16, },
[L2TP_ATTR_DEBUG]   = { .type = NLA_U32, },
[L2TP_ATTR_RECV_SEQ]= { .type = NLA_U8, },
-- 
2.10.1

[PATCH net-next 2/5] net: l2tp: fix L2TP_ATTR_UDP_ZERO_CSUM6_{RX,TX} attribute types

[Asbjoern Sloth Toennesen]

The attributes L2TP_ATTR_UDP_ZERO_CSUM6_RX and
L2TP_ATTR_UDP_ZERO_CSUM6_TX are used as flags,
but is defined as a u8 in a comment.

This patch redocuments them as flags, and adds
them to the nla_policy, so they gets validated.

The only publicly user, iproute2, already treat
these attributes as flags.

CC: Miao Wang 
Signed-off-by: Asbjoern Sloth Toennesen 
---
 include/uapi/linux/l2tp.h | 4 ++--
 net/l2tp/l2tp_netlink.c   | 2 ++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/include/uapi/linux/l2tp.h b/include/uapi/linux/l2tp.h
index 73e3a23..345e49f 100644
--- a/include/uapi/linux/l2tp.h
+++ b/include/uapi/linux/l2tp.h
@@ -124,8 +124,8 @@ enum {
L2TP_ATTR_STATS,/* nested */
L2TP_ATTR_IP6_SADDR,/* struct in6_addr */
L2TP_ATTR_IP6_DADDR,/* struct in6_addr */
-   L2TP_ATTR_UDP_ZERO_CSUM6_TX,/* u8 */
-   L2TP_ATTR_UDP_ZERO_CSUM6_RX,/* u8 */
+   L2TP_ATTR_UDP_ZERO_CSUM6_TX,/* flag */
+   L2TP_ATTR_UDP_ZERO_CSUM6_RX,/* flag */
L2TP_ATTR_PAD,
__L2TP_ATTR_MAX,
 };
diff --git a/net/l2tp/l2tp_netlink.c b/net/l2tp/l2tp_netlink.c
index 1fe05da..e45c5409 100644
--- a/net/l2tp/l2tp_netlink.c
+++ b/net/l2tp/l2tp_netlink.c
@@ -880,6 +880,8 @@ static const struct nla_policy l2tp_nl_policy[L2TP_ATTR_MAX 
+ 1] = {
[L2TP_ATTR_SESSION_ID]  = { .type = NLA_U32, },
[L2TP_ATTR_PEER_SESSION_ID] = { .type = NLA_U32, },
[L2TP_ATTR_UDP_CSUM]= { .type = NLA_FLAG, },
+   [L2TP_ATTR_UDP_ZERO_CSUM6_TX]   = { .type = NLA_FLAG, },
+   [L2TP_ATTR_UDP_ZERO_CSUM6_RX]   = { .type = NLA_FLAG, },
[L2TP_ATTR_VLAN_ID] = { .type = NLA_U16, },
[L2TP_ATTR_DEBUG]   = { .type = NLA_U32, },
[L2TP_ATTR_RECV_SEQ]= { .type = NLA_U8, },
-- 
2.10.1

[PATCH net-next 1/5] net: l2tp: fix L2TP_ATTR_UDP_CSUM attribute type

[Asbjoern Sloth Toennesen]

L2TP_ATTR_UDP_CSUM is a flag, and gets read with
nla_get_flag, but it is defined as NLA_U8 in
the nla_policy.

It appears that this is only publicly used in
iproute2, where it's broken, because it's used as
a NLA_FLAG, and fails validation as a NLA_U8.

The only place it's used as a NLA_U8 is in
l2tp_nl_tunnel_send(), but iproute2 again reads that
as a flag, it's therefore always set. Fortunately
it is never used for anything, just read.

CC: Miao Wang 
Signed-off-by: Asbjoern Sloth Toennesen 
---
 include/uapi/linux/l2tp.h |  2 +-
 net/l2tp/l2tp_netlink.c   | 12 +---
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/include/uapi/linux/l2tp.h b/include/uapi/linux/l2tp.h
index 4bd27d0..73e3a23 100644
--- a/include/uapi/linux/l2tp.h
+++ b/include/uapi/linux/l2tp.h
@@ -104,7 +104,7 @@ enum {
L2TP_ATTR_PEER_CONN_ID, /* u32 */
L2TP_ATTR_SESSION_ID,   /* u32 */
L2TP_ATTR_PEER_SESSION_ID,  /* u32 */
-   L2TP_ATTR_UDP_CSUM, /* u8 */
+   L2TP_ATTR_UDP_CSUM, /* flag */
L2TP_ATTR_VLAN_ID,  /* u16 */
L2TP_ATTR_COOKIE,   /* 0, 4 or 8 bytes */
L2TP_ATTR_PEER_COOKIE,  /* 0, 4 or 8 bytes */
diff --git a/net/l2tp/l2tp_netlink.c b/net/l2tp/l2tp_netlink.c
index 59aa2d2..1fe05da 100644
--- a/net/l2tp/l2tp_netlink.c
+++ b/net/l2tp/l2tp_netlink.c
@@ -379,9 +379,15 @@ static int l2tp_nl_tunnel_send(struct sk_buff *skb, u32 
portid, u32 seq, int fla
 
switch (tunnel->encap) {
case L2TP_ENCAPTYPE_UDP:
+   switch (sk->sk_family) {
+   case AF_INET:
+   if ((!sk->sk_no_check_tx) &&
+   nla_put_flag(skb, L2TP_ATTR_UDP_CSUM))
+   goto nla_put_failure;
+   break;
+   }
if (nla_put_u16(skb, L2TP_ATTR_UDP_SPORT, 
ntohs(inet->inet_sport)) ||
-   nla_put_u16(skb, L2TP_ATTR_UDP_DPORT, 
ntohs(inet->inet_dport)) ||
-   nla_put_u8(skb, L2TP_ATTR_UDP_CSUM, !sk->sk_no_check_tx))
+   nla_put_u16(skb, L2TP_ATTR_UDP_DPORT, 
ntohs(inet->inet_dport)))
goto nla_put_failure;
/* NOBREAK */
case L2TP_ENCAPTYPE_IP:
@@ -873,7 +879,7 @@ static const struct nla_policy l2tp_nl_policy[L2TP_ATTR_MAX 
+ 1] = {
[L2TP_ATTR_PEER_CONN_ID]= { .type = NLA_U32, },
[L2TP_ATTR_SESSION_ID]  = { .type = NLA_U32, },
[L2TP_ATTR_PEER_SESSION_ID] = { .type = NLA_U32, },
-   [L2TP_ATTR_UDP_CSUM]= { .type = NLA_U8, },
+   [L2TP_ATTR_UDP_CSUM]= { .type = NLA_FLAG, },
[L2TP_ATTR_VLAN_ID] = { .type = NLA_U16, },
[L2TP_ATTR_DEBUG]   = { .type = NLA_U32, },
[L2TP_ATTR_RECV_SEQ]= { .type = NLA_U8, },
-- 
2.10.1

[PATCH net-next 2/5] net: l2tp: fix L2TP_ATTR_UDP_ZERO_CSUM6_{RX,TX} attribute types

[Asbjoern Sloth Toennesen]

The attributes L2TP_ATTR_UDP_ZERO_CSUM6_RX and
L2TP_ATTR_UDP_ZERO_CSUM6_TX are used as flags,
but is defined as a u8 in a comment.

This patch redocuments them as flags, and adds
them to the nla_policy, so they gets validated.

The only publicly user, iproute2, already treat
these attributes as flags.

CC: Miao Wang 
Signed-off-by: Asbjoern Sloth Toennesen 
---
 include/uapi/linux/l2tp.h | 4 ++--
 net/l2tp/l2tp_netlink.c   | 2 ++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/include/uapi/linux/l2tp.h b/include/uapi/linux/l2tp.h
index 73e3a23..345e49f 100644
--- a/include/uapi/linux/l2tp.h
+++ b/include/uapi/linux/l2tp.h
@@ -124,8 +124,8 @@ enum {
L2TP_ATTR_STATS,/* nested */
L2TP_ATTR_IP6_SADDR,/* struct in6_addr */
L2TP_ATTR_IP6_DADDR,/* struct in6_addr */
-   L2TP_ATTR_UDP_ZERO_CSUM6_TX,/* u8 */
-   L2TP_ATTR_UDP_ZERO_CSUM6_RX,/* u8 */
+   L2TP_ATTR_UDP_ZERO_CSUM6_TX,/* flag */
+   L2TP_ATTR_UDP_ZERO_CSUM6_RX,/* flag */
L2TP_ATTR_PAD,
__L2TP_ATTR_MAX,
 };
diff --git a/net/l2tp/l2tp_netlink.c b/net/l2tp/l2tp_netlink.c
index 1fe05da..e45c5409 100644
--- a/net/l2tp/l2tp_netlink.c
+++ b/net/l2tp/l2tp_netlink.c
@@ -880,6 +880,8 @@ static const struct nla_policy l2tp_nl_policy[L2TP_ATTR_MAX 
+ 1] = {
[L2TP_ATTR_SESSION_ID]  = { .type = NLA_U32, },
[L2TP_ATTR_PEER_SESSION_ID] = { .type = NLA_U32, },
[L2TP_ATTR_UDP_CSUM]= { .type = NLA_FLAG, },
+   [L2TP_ATTR_UDP_ZERO_CSUM6_TX]   = { .type = NLA_FLAG, },
+   [L2TP_ATTR_UDP_ZERO_CSUM6_RX]   = { .type = NLA_FLAG, },
[L2TP_ATTR_VLAN_ID] = { .type = NLA_U16, },
[L2TP_ATTR_DEBUG]   = { .type = NLA_U32, },
[L2TP_ATTR_RECV_SEQ]= { .type = NLA_U8, },
-- 
2.10.1