Re: [PATCH/RFC] iio: hi8435: do not enable all events by default

[Nikita Yushchenko]

>> Still, isn't there subsystem-level default that all events are disabled
>> by default?  If such, then current hi8435 state breaks subsystem-level
>> rules, which is a [userspace-visible] bug.  I'm not sure how far should
>> we go in bug compatibility.
>
> It is indeed the subsystem default (as much as we have one)
> 
> This is a moderately obscure chip for linux systems, do we have a good handle
> on where it is being used - i.e. are most of the devices under control of
> people we can discuss this with?

Company I work with, uses this chip in several boards; what they need is
a service that monitors all connected chip's outputs and detects
changes.  They originally wanted gpio-style access to use with userspace
polling, and were not pleased with entire IIO thing. However it's
important for them to minimize required kernel patches against mainline,
thus if mainline supports this chip as IIO device that's ok for them.

Questions like default event enable state has little practical impact.
It's more about keeping architecture clean.

Nikita

Re: [PATCH/RFC] iio: hi8435: do not enable all events by default

[Nikita Yushchenko]

>> Still, isn't there subsystem-level default that all events are disabled
>> by default?  If such, then current hi8435 state breaks subsystem-level
>> rules, which is a [userspace-visible] bug.  I'm not sure how far should
>> we go in bug compatibility.
>
> It is indeed the subsystem default (as much as we have one)
> 
> This is a moderately obscure chip for linux systems, do we have a good handle
> on where it is being used - i.e. are most of the devices under control of
> people we can discuss this with?

Company I work with, uses this chip in several boards; what they need is
a service that monitors all connected chip's outputs and detects
changes.  They originally wanted gpio-style access to use with userspace
polling, and were not pleased with entire IIO thing. However it's
important for them to minimize required kernel patches against mainline,
thus if mainline supports this chip as IIO device that's ok for them.

Questions like default event enable state has little practical impact.
It's more about keeping architecture clean.

Nikita

Re: [PATCH] ubifs: Add freeze support

[Amir Goldstein]

On Mon, May 29, 2017 at 7:40 AM, Hyunchul Lee  wrote:
>
> and I missed the following case.
>
> in some embedded systems, clean-up for shutdown should be fast.
> during this clean-up, freeze file system to guarantee integrity.
> umount with MNT_DETACH is not suitable because of not killing tasks.
>

Interesting point. It seems that good old "sync; reboot" does not cut
it anymore.
Not even emergency remount read-only sysrq trigger.

Some of you may have been following this thread on fsdevel:
https://www.spinics.net/lists/linux-xfs/msg06953.html

Probably less have been following this longer thread on xfs list:
https://www.spinics.net/lists/linux-xfs/msg06883.html

linux-next: build failure after merge of the gpio tree

[Stephen Rothwell]

Hi Linus,

After merging the gpio tree, today's linux-next build (arm
orion5x_defconfig) failed like this:

drivers/gpio/gpio-mvebu.c:1062: undefined reference to 
`__devm_regmap_init_mmio_clk'
drivers/gpio/gpio-mvebu.c:1078: undefined reference to 
`__devm_regmap_init_mmio_clk'

Caused by commit

  2233bf7a92e7 ("gpio: mvebu: switch to regmap for register access")

Presumably a missing Kconfig dependency.  Yeah, CONFIG_REGMAP_MMIO is
not set for this build.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH] ubifs: Add freeze support

[Amir Goldstein]

On Mon, May 29, 2017 at 7:40 AM, Hyunchul Lee  wrote:
>
> and I missed the following case.
>
> in some embedded systems, clean-up for shutdown should be fast.
> during this clean-up, freeze file system to guarantee integrity.
> umount with MNT_DETACH is not suitable because of not killing tasks.
>

Interesting point. It seems that good old "sync; reboot" does not cut
it anymore.
Not even emergency remount read-only sysrq trigger.

Some of you may have been following this thread on fsdevel:
https://www.spinics.net/lists/linux-xfs/msg06953.html

Probably less have been following this longer thread on xfs list:
https://www.spinics.net/lists/linux-xfs/msg06883.html

linux-next: build failure after merge of the gpio tree

[Stephen Rothwell]

Hi Linus,

After merging the gpio tree, today's linux-next build (arm
orion5x_defconfig) failed like this:

drivers/gpio/gpio-mvebu.c:1062: undefined reference to 
`__devm_regmap_init_mmio_clk'
drivers/gpio/gpio-mvebu.c:1078: undefined reference to 
`__devm_regmap_init_mmio_clk'

Caused by commit

  2233bf7a92e7 ("gpio: mvebu: switch to regmap for register access")

Presumably a missing Kconfig dependency.  Yeah, CONFIG_REGMAP_MMIO is
not set for this build.

-- 
Cheers,
Stephen Rothwell

Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc

[Michael Ellerman]

Reza Arbab  writes:

> On Fri, May 26, 2017 at 01:46:58PM +1000, Michael Ellerman wrote:
>>Reza Arbab  writes:
>>
>>> On Thu, May 25, 2017 at 04:19:53PM +1000, Michael Ellerman wrote:
The commit message for 3af229f2071f says:

In practice, we never see a system with 256 NUMA nodes, and in fact, we
do not support node hotplug on power in the first place, so the nodes
^^^
that are online when we come up are the nodes that will be present for
the lifetime of this kernel.

Is that no longer true?
>>>
>>> I don't know what the reasoning behind that statement was at the time,
>>> but as far as I can tell, the only thing missing for node hotplug now is
>>> Balbir's patchset [1]. He fixes the resource issue which motivated
>>> 3af229f2071f and reverts it.
>>>
>>> With that set, I can instantiate a new numa node just by doing
>>> add_memory(nid, ...) where nid doesn't currently exist.
>>
>>But does that actually happen on any real system?
>
> I don't know if anything currently tries to do this. My interest in 
> having this working is so that in the future, our coherent gpu memory 
> could be added as a distinct node by the device driver.

Sure. If/when that happens, we would hopefully still have some way to
limit the size of the possible map.

That would ideally be a firmware property that tells us the maximum
number of GPUs that might be hot-added, or we punt and cap it at some
"sane" maximum number.

But until that happens it's silly to say we can have up to 256 nodes
when in practice most of our systems have 8 or less.

So I'm still waiting for an explanation from Michael B on how he's
seeing this bug in practice.

cheers

Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc

[Michael Ellerman]

Reza Arbab  writes:

> On Fri, May 26, 2017 at 01:46:58PM +1000, Michael Ellerman wrote:
>>Reza Arbab  writes:
>>
>>> On Thu, May 25, 2017 at 04:19:53PM +1000, Michael Ellerman wrote:
The commit message for 3af229f2071f says:

In practice, we never see a system with 256 NUMA nodes, and in fact, we
do not support node hotplug on power in the first place, so the nodes
^^^
that are online when we come up are the nodes that will be present for
the lifetime of this kernel.

Is that no longer true?
>>>
>>> I don't know what the reasoning behind that statement was at the time,
>>> but as far as I can tell, the only thing missing for node hotplug now is
>>> Balbir's patchset [1]. He fixes the resource issue which motivated
>>> 3af229f2071f and reverts it.
>>>
>>> With that set, I can instantiate a new numa node just by doing
>>> add_memory(nid, ...) where nid doesn't currently exist.
>>
>>But does that actually happen on any real system?
>
> I don't know if anything currently tries to do this. My interest in 
> having this working is so that in the future, our coherent gpu memory 
> could be added as a distinct node by the device driver.

Sure. If/when that happens, we would hopefully still have some way to
limit the size of the possible map.

That would ideally be a firmware property that tells us the maximum
number of GPUs that might be hot-added, or we punt and cap it at some
"sane" maximum number.

But until that happens it's silly to say we can have up to 256 nodes
when in practice most of our systems have 8 or less.

So I'm still waiting for an explanation from Michael B on how he's
seeing this bug in practice.

cheers

[PATCH v2] mm: introduce MADV_RESET_HUGEPAGE

[Mike Rapoport]

Currently applications can explicitly enable or disable THP for a memory
region using MADV_HUGEPAGE or MADV_NOHUGEPAGE. However, once either of
these advises is used, the region will always have
VM_HUGEPAGE/VM_NOHUGEPAGE flag set in vma->vm_flags.
The MADV_RESET_HUGEPAGE resets both these flags and allows managing THP in
the region according to system-wide settings.

Signed-off-by: Mike Rapoport 
Acked-by: Kirill A. Shutemov 
---

v2 changes:
* Use _RESET_ instead of _CLR_ as per Kirill's suggestion
* Fix build on arches that do not include mman-common.h


 arch/alpha/include/uapi/asm/mman.h | 3 +++
 arch/mips/include/uapi/asm/mman.h  | 3 +++
 arch/parisc/include/uapi/asm/mman.h| 3 +++
 arch/xtensa/include/uapi/asm/mman.h| 3 +++
 include/uapi/asm-generic/mman-common.h | 3 +++
 mm/khugepaged.c| 7 +++
 mm/madvise.c   | 5 +
 7 files changed, 27 insertions(+)

diff --git a/arch/alpha/include/uapi/asm/mman.h 
b/arch/alpha/include/uapi/asm/mman.h
index 02760f6..cb3095f 100644
--- a/arch/alpha/include/uapi/asm/mman.h
+++ b/arch/alpha/include/uapi/asm/mman.h
@@ -64,6 +64,9 @@
   overrides the coredump filter bits */
 #define MADV_DODUMP17  /* Clear the MADV_NODUMP flag */
 
+#define MADV_RESET_HUGEPAGE 18 /* Reset flags controlling backing with
+  hugepages */
+
 /* compatibility flags */
 #define MAP_FILE   0
 
diff --git a/arch/mips/include/uapi/asm/mman.h 
b/arch/mips/include/uapi/asm/mman.h
index 655e2fb..b5a181b 100644
--- a/arch/mips/include/uapi/asm/mman.h
+++ b/arch/mips/include/uapi/asm/mman.h
@@ -91,6 +91,9 @@
   overrides the coredump filter bits */
 #define MADV_DODUMP17  /* Clear the MADV_NODUMP flag */
 
+#define MADV_RESET_HUGEPAGE 18 /* Reset flags controlling backing with
+  hugepages */
+
 /* compatibility flags */
 #define MAP_FILE   0
 
diff --git a/arch/parisc/include/uapi/asm/mman.h 
b/arch/parisc/include/uapi/asm/mman.h
index 5979745..d671906 100644
--- a/arch/parisc/include/uapi/asm/mman.h
+++ b/arch/parisc/include/uapi/asm/mman.h
@@ -60,6 +60,9 @@
   overrides the coredump filter bits */
 #define MADV_DODUMP70  /* Clear the MADV_NODUMP flag */
 
+#define MADV_RESET_HUGEPAGE 71 /* Reset flags controlling backing with
+  hugepages */
+
 /* compatibility flags */
 #define MAP_FILE   0
 #define MAP_VARIABLE   0
diff --git a/arch/xtensa/include/uapi/asm/mman.h 
b/arch/xtensa/include/uapi/asm/mman.h
index 24365b3..9c038d0 100644
--- a/arch/xtensa/include/uapi/asm/mman.h
+++ b/arch/xtensa/include/uapi/asm/mman.h
@@ -103,6 +103,9 @@
   overrides the coredump filter bits */
 #define MADV_DODUMP17  /* Clear the MADV_NODUMP flag */
 
+#define MADV_RESET_HUGEPAGE 18 /* Reset flags controlling backing with
+  hugepages */
+
 /* compatibility flags */
 #define MAP_FILE   0
 
diff --git a/include/uapi/asm-generic/mman-common.h 
b/include/uapi/asm-generic/mman-common.h
index 8c27db0..fa62825 100644
--- a/include/uapi/asm-generic/mman-common.h
+++ b/include/uapi/asm-generic/mman-common.h
@@ -58,6 +58,9 @@
   overrides the coredump filter bits */
 #define MADV_DODUMP17  /* Clear the MADV_DONTDUMP flag */
 
+#define MADV_RESET_HUGEPAGE 18 /* Reset flags controlling backing with
+  hugepages */
+
 /* compatibility flags */
 #define MAP_FILE   0
 
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index 945fd1c..32c66e7 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -336,6 +336,13 @@ int hugepage_madvise(struct vm_area_struct *vma,
 * it got registered before VM_NOHUGEPAGE was set.
 */
break;
+   case MADV_RESET_HUGEPAGE:
+   *vm_flags &= ~(VM_HUGEPAGE | VM_NOHUGEPAGE);
+   /*
+* The vma will be treated according to the
+* system-wide settings in transparent_hugepage_flags
+*/
+   break;
}
 
return 0;
diff --git a/mm/madvise.c b/mm/madvise.c
index 25b78ee..6d6dd09 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -105,6 +105,7 @@ static long madvise_behavior(struct vm_area_struct *vma,
break;
case MADV_HUGEPAGE:
case MADV_NOHUGEPAGE:
+   case MADV_RESET_HUGEPAGE:
error = hugepage_madvise(vma, _flags, behavior);
if (error) {
/*
@@ -684,6 +685,7 @@ madvise_behavior_valid(int behavior)
 #ifdef 

[PATCH v2] mm: introduce MADV_RESET_HUGEPAGE

[Mike Rapoport]

Currently applications can explicitly enable or disable THP for a memory
region using MADV_HUGEPAGE or MADV_NOHUGEPAGE. However, once either of
these advises is used, the region will always have
VM_HUGEPAGE/VM_NOHUGEPAGE flag set in vma->vm_flags.
The MADV_RESET_HUGEPAGE resets both these flags and allows managing THP in
the region according to system-wide settings.

Signed-off-by: Mike Rapoport 
Acked-by: Kirill A. Shutemov 
---

v2 changes:
* Use _RESET_ instead of _CLR_ as per Kirill's suggestion
* Fix build on arches that do not include mman-common.h


 arch/alpha/include/uapi/asm/mman.h | 3 +++
 arch/mips/include/uapi/asm/mman.h  | 3 +++
 arch/parisc/include/uapi/asm/mman.h| 3 +++
 arch/xtensa/include/uapi/asm/mman.h| 3 +++
 include/uapi/asm-generic/mman-common.h | 3 +++
 mm/khugepaged.c| 7 +++
 mm/madvise.c   | 5 +
 7 files changed, 27 insertions(+)

diff --git a/arch/alpha/include/uapi/asm/mman.h 
b/arch/alpha/include/uapi/asm/mman.h
index 02760f6..cb3095f 100644
--- a/arch/alpha/include/uapi/asm/mman.h
+++ b/arch/alpha/include/uapi/asm/mman.h
@@ -64,6 +64,9 @@
   overrides the coredump filter bits */
 #define MADV_DODUMP17  /* Clear the MADV_NODUMP flag */
 
+#define MADV_RESET_HUGEPAGE 18 /* Reset flags controlling backing with
+  hugepages */
+
 /* compatibility flags */
 #define MAP_FILE   0
 
diff --git a/arch/mips/include/uapi/asm/mman.h 
b/arch/mips/include/uapi/asm/mman.h
index 655e2fb..b5a181b 100644
--- a/arch/mips/include/uapi/asm/mman.h
+++ b/arch/mips/include/uapi/asm/mman.h
@@ -91,6 +91,9 @@
   overrides the coredump filter bits */
 #define MADV_DODUMP17  /* Clear the MADV_NODUMP flag */
 
+#define MADV_RESET_HUGEPAGE 18 /* Reset flags controlling backing with
+  hugepages */
+
 /* compatibility flags */
 #define MAP_FILE   0
 
diff --git a/arch/parisc/include/uapi/asm/mman.h 
b/arch/parisc/include/uapi/asm/mman.h
index 5979745..d671906 100644
--- a/arch/parisc/include/uapi/asm/mman.h
+++ b/arch/parisc/include/uapi/asm/mman.h
@@ -60,6 +60,9 @@
   overrides the coredump filter bits */
 #define MADV_DODUMP70  /* Clear the MADV_NODUMP flag */
 
+#define MADV_RESET_HUGEPAGE 71 /* Reset flags controlling backing with
+  hugepages */
+
 /* compatibility flags */
 #define MAP_FILE   0
 #define MAP_VARIABLE   0
diff --git a/arch/xtensa/include/uapi/asm/mman.h 
b/arch/xtensa/include/uapi/asm/mman.h
index 24365b3..9c038d0 100644
--- a/arch/xtensa/include/uapi/asm/mman.h
+++ b/arch/xtensa/include/uapi/asm/mman.h
@@ -103,6 +103,9 @@
   overrides the coredump filter bits */
 #define MADV_DODUMP17  /* Clear the MADV_NODUMP flag */
 
+#define MADV_RESET_HUGEPAGE 18 /* Reset flags controlling backing with
+  hugepages */
+
 /* compatibility flags */
 #define MAP_FILE   0
 
diff --git a/include/uapi/asm-generic/mman-common.h 
b/include/uapi/asm-generic/mman-common.h
index 8c27db0..fa62825 100644
--- a/include/uapi/asm-generic/mman-common.h
+++ b/include/uapi/asm-generic/mman-common.h
@@ -58,6 +58,9 @@
   overrides the coredump filter bits */
 #define MADV_DODUMP17  /* Clear the MADV_DONTDUMP flag */
 
+#define MADV_RESET_HUGEPAGE 18 /* Reset flags controlling backing with
+  hugepages */
+
 /* compatibility flags */
 #define MAP_FILE   0
 
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index 945fd1c..32c66e7 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -336,6 +336,13 @@ int hugepage_madvise(struct vm_area_struct *vma,
 * it got registered before VM_NOHUGEPAGE was set.
 */
break;
+   case MADV_RESET_HUGEPAGE:
+   *vm_flags &= ~(VM_HUGEPAGE | VM_NOHUGEPAGE);
+   /*
+* The vma will be treated according to the
+* system-wide settings in transparent_hugepage_flags
+*/
+   break;
}
 
return 0;
diff --git a/mm/madvise.c b/mm/madvise.c
index 25b78ee..6d6dd09 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -105,6 +105,7 @@ static long madvise_behavior(struct vm_area_struct *vma,
break;
case MADV_HUGEPAGE:
case MADV_NOHUGEPAGE:
+   case MADV_RESET_HUGEPAGE:
error = hugepage_madvise(vma, _flags, behavior);
if (error) {
/*
@@ -684,6 +685,7 @@ madvise_behavior_valid(int behavior)
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
case MADV_HUGEPAGE:
case 

[PATCH] Input: synaptics - clear device info before filling in

[Eric Biggers]

From: Eric Biggers 

synaptics_query_hardware() was being passed a
'struct synaptics_device_info' in uninitialized stack memory, then not
always initializing all fields.  This caused garbage to show up in
certain fields, making the touchpad unusable.

Fix by zeroing the device info, so all fields default to 0.

Fixes: 6c53694fb222 ("Input: synaptics - split device info into a separate 
structure")
Signed-off-by: Eric Biggers 
---
 drivers/input/mouse/synaptics.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index 131df9d3660f..4f97970abc94 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -397,6 +397,8 @@ static int synaptics_query_hardware(struct psmouse *psmouse,
 {
int error;
 
+   memset(info, 0, sizeof(*info));
+
error = synaptics_identify(psmouse, info);
if (error)
return error;
-- 
2.13.0

[PATCH] Input: synaptics - clear device info before filling in

[Eric Biggers]

From: Eric Biggers 

synaptics_query_hardware() was being passed a
'struct synaptics_device_info' in uninitialized stack memory, then not
always initializing all fields.  This caused garbage to show up in
certain fields, making the touchpad unusable.

Fix by zeroing the device info, so all fields default to 0.

Fixes: 6c53694fb222 ("Input: synaptics - split device info into a separate 
structure")
Signed-off-by: Eric Biggers 
---
 drivers/input/mouse/synaptics.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index 131df9d3660f..4f97970abc94 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -397,6 +397,8 @@ static int synaptics_query_hardware(struct psmouse *psmouse,
 {
int error;
 
+   memset(info, 0, sizeof(*info));
+
error = synaptics_identify(psmouse, info);
if (error)
return error;
-- 
2.13.0

Re: [linux-next] PPC Lpar fail to boot with error hid: module verification failed: signature and/or required key missing - tainting kernel

[Michael Ellerman]

Rob Landley  writes:

> On 05/25/2017 04:24 PM, Stephen Rothwell wrote:
>> Hi Michael,
>> 
>> On Thu, 25 May 2017 23:02:06 +1000 Michael Ellerman  
>> wrote:
>>>
>>> It'll be:
>>>
>>> ee35011fd032 ("initramfs: make initramfs honor CONFIG_DEVTMPFS_MOUNT")
>>
>> And Andrew has asked me to drop that patch from linux-next which will
>> happen today.
>
> What approach do the kernel developers suggest I take here?

Well I'm just *a* kernel developer, but rule #1 is don't break userspace.

> I would have thought letting it soak in linux-next for a release so
> people could fix userspace bugs would be the next step, but this sounds
> like that's not an option?

You say they're userspace bugs, userspace will say it's a bug that the
kernel has changed its behaviour.

> Is the behavior the patch implements wrong?

Yes, because it breaks existing setups for no particularly good reason.

If CONFIG_DEVTMPFS_MOUNT had always meant devtmpfs was mounted in the
initramfs then that would have been fine.

But because it didn't, there are now systems out there that depend on
the existing behaviour, and changing it is therefore wrong IMHO.

As I said in another mail you can avoid breaking existing setups by
adding a new config option to control mounting devtmpfs in the
initramfs. It's a pity to need yet another config option, but such is
life.

cheers

Re: [linux-next] PPC Lpar fail to boot with error hid: module verification failed: signature and/or required key missing - tainting kernel

[Michael Ellerman]

Rob Landley  writes:

> On 05/25/2017 04:24 PM, Stephen Rothwell wrote:
>> Hi Michael,
>> 
>> On Thu, 25 May 2017 23:02:06 +1000 Michael Ellerman  
>> wrote:
>>>
>>> It'll be:
>>>
>>> ee35011fd032 ("initramfs: make initramfs honor CONFIG_DEVTMPFS_MOUNT")
>>
>> And Andrew has asked me to drop that patch from linux-next which will
>> happen today.
>
> What approach do the kernel developers suggest I take here?

Well I'm just *a* kernel developer, but rule #1 is don't break userspace.

> I would have thought letting it soak in linux-next for a release so
> people could fix userspace bugs would be the next step, but this sounds
> like that's not an option?

You say they're userspace bugs, userspace will say it's a bug that the
kernel has changed its behaviour.

> Is the behavior the patch implements wrong?

Yes, because it breaks existing setups for no particularly good reason.

If CONFIG_DEVTMPFS_MOUNT had always meant devtmpfs was mounted in the
initramfs then that would have been fine.

But because it didn't, there are now systems out there that depend on
the existing behaviour, and changing it is therefore wrong IMHO.

As I said in another mail you can avoid breaking existing setups by
adding a new config option to control mounting devtmpfs in the
initramfs. It's a pity to need yet another config option, but such is
life.

cheers

Re: [PATCH v6 3/6] ACPI/IORT: Ignore all errors except EPROBE_DEFER

[Sricharan R]

Hi Rafael,

On 5/28/2017 12:48 AM, Rafael J. Wysocki wrote:
> On Saturday, May 27, 2017 07:17:42 PM Sricharan R wrote:
>> While deferring the probe of IOMMU masters, xlate and
>> add_device callbacks called from iort_iommu_configure
>> can pass back error values like -ENODEV, which means
>> the IOMMU cannot be connected with that master for real
>> reasons. Before the IOMMU probe deferral, all such errors
>> were ignored. Now all those errors are propagated back,
>> killing the master's probe for such errors. Instead ignore
>> all the errors except EPROBE_DEFER, which is the only one
>> of concern and let the master work without IOMMU, thus
>> restoring the old behavior. Also make explicit that
>> acpi_dma_configure handles only -EPROBE_DEFER from
>> iort_iommu_configure.
>>
>> Fixes: 5a1bb638d567 ("drivers: acpi: Handle IOMMU lookup failure with 
>> deferred probing or error")
>> Signed-off-by: Sricharan R 
>> ---
>>  drivers/acpi/arm64/iort.c | 6 ++
>>  drivers/acpi/scan.c   | 4 ++--
>>  2 files changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
>> index c5fecf9..16e101f 100644
>> --- a/drivers/acpi/arm64/iort.c
>> +++ b/drivers/acpi/arm64/iort.c
>> @@ -782,6 +782,12 @@ const struct iommu_ops *iort_iommu_configure(struct 
>> device *dev)
>>  if (err)
>>  ops = ERR_PTR(err);
>>  
>> +/* Ignore all other errors apart from EPROBE_DEFER */
>> +if (IS_ERR(ops) && (PTR_ERR(ops) != -EPROBE_DEFER)) {
>> +dev_dbg(dev, "Adding to IOMMU failed: %ld\n", PTR_ERR(ops));
>> +ops = NULL;
>> +}
>> +
>>  return ops;
>>  }
>>  
>> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
>> index e39ec7b..3a10d757 100644
>> --- a/drivers/acpi/scan.c
>> +++ b/drivers/acpi/scan.c
>> @@ -1371,8 +1371,8 @@ int acpi_dma_configure(struct device *dev, enum 
>> dev_dma_attr attr)
>>  iort_set_dma_mask(dev);
>>  
>>  iommu = iort_iommu_configure(dev);
>> -if (IS_ERR(iommu))
>> -return PTR_ERR(iommu);
>> +if (IS_ERR(iommu) && PTR_ERR(iommu) == -EPROBE_DEFER)
>> +return -EPROBE_DEFER;
>>  
>>  size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
>>  /*
>>
> 
> ACK for the scan.c change and I'm assuming this to go in via ARM64.
> 

Thanks for the ACK, should go through the IOMMU tree, since this fixes the 
IOMMU probe deferral
that got merged through it.

Regards,
 Sricharan

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

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH v6 3/6] ACPI/IORT: Ignore all errors except EPROBE_DEFER

[Sricharan R]

Hi Rafael,

On 5/28/2017 12:48 AM, Rafael J. Wysocki wrote:
> On Saturday, May 27, 2017 07:17:42 PM Sricharan R wrote:
>> While deferring the probe of IOMMU masters, xlate and
>> add_device callbacks called from iort_iommu_configure
>> can pass back error values like -ENODEV, which means
>> the IOMMU cannot be connected with that master for real
>> reasons. Before the IOMMU probe deferral, all such errors
>> were ignored. Now all those errors are propagated back,
>> killing the master's probe for such errors. Instead ignore
>> all the errors except EPROBE_DEFER, which is the only one
>> of concern and let the master work without IOMMU, thus
>> restoring the old behavior. Also make explicit that
>> acpi_dma_configure handles only -EPROBE_DEFER from
>> iort_iommu_configure.
>>
>> Fixes: 5a1bb638d567 ("drivers: acpi: Handle IOMMU lookup failure with 
>> deferred probing or error")
>> Signed-off-by: Sricharan R 
>> ---
>>  drivers/acpi/arm64/iort.c | 6 ++
>>  drivers/acpi/scan.c   | 4 ++--
>>  2 files changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
>> index c5fecf9..16e101f 100644
>> --- a/drivers/acpi/arm64/iort.c
>> +++ b/drivers/acpi/arm64/iort.c
>> @@ -782,6 +782,12 @@ const struct iommu_ops *iort_iommu_configure(struct 
>> device *dev)
>>  if (err)
>>  ops = ERR_PTR(err);
>>  
>> +/* Ignore all other errors apart from EPROBE_DEFER */
>> +if (IS_ERR(ops) && (PTR_ERR(ops) != -EPROBE_DEFER)) {
>> +dev_dbg(dev, "Adding to IOMMU failed: %ld\n", PTR_ERR(ops));
>> +ops = NULL;
>> +}
>> +
>>  return ops;
>>  }
>>  
>> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
>> index e39ec7b..3a10d757 100644
>> --- a/drivers/acpi/scan.c
>> +++ b/drivers/acpi/scan.c
>> @@ -1371,8 +1371,8 @@ int acpi_dma_configure(struct device *dev, enum 
>> dev_dma_attr attr)
>>  iort_set_dma_mask(dev);
>>  
>>  iommu = iort_iommu_configure(dev);
>> -if (IS_ERR(iommu))
>> -return PTR_ERR(iommu);
>> +if (IS_ERR(iommu) && PTR_ERR(iommu) == -EPROBE_DEFER)
>> +return -EPROBE_DEFER;
>>  
>>  size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
>>  /*
>>
> 
> ACK for the scan.c change and I'm assuming this to go in via ARM64.
> 

Thanks for the ACK, should go through the IOMMU tree, since this fixes the 
IOMMU probe deferral
that got merged through it.

Regards,
 Sricharan

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

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH 1/1] - Fix reiserfs WARNING in dquot_writeback_dquots

[Tim Savannah]

Oops, sent last one without patch on accident. Attached this time.


This has been happening for me since 4.10

dquot_writeback_dquots expects a lock to be held on super_block->s_umount ,

and reiserfs_sync_fs, which calls dquot_writeback_dquots, does not
obtain such a lock.

Thus, the following warning is generated:

[Sun May 28 04:58:06 2017] [ cut here ]
[Sun May 28 04:58:06 2017] WARNING: CPU: 0 PID: 31 at
fs/quota/dquot.c:620 dquot_writeback_dquots+0x248/0x250
[Sun May 28 04:58:06 2017] Modules linked in: bbswitch(O)
nls_iso8859_1 nls_cp437 iTCO_wdt iTCO_vendor_support acer_wmi
sparse_keymap coretemp efi_pstore hwmon intel_rapl
x86_pkg_temp_thermal intel_powerclamp pcspkr ath9k ath9k_common
ath9k_hw ath efivars mac80211 joydev psmouse i2c_i801 cfg80211
input_leds led_class nvidiafb vgastate fb_ddc atl1c i915
drm_kms_helper drm intel_gtt syscopyarea sysfillrect sysimgblt mei_me
fb_sys_fops i2c_algo_bit mei lpc_ich shpchp acpi_cpufreq thermal wmi
video tpm_tis tpm_tis_core button tpm sch_fq_codel evdev mac_hid
uvcvideo vboxnetflt(O) videobuf2_vmalloc videobuf2_memops
vboxnetadp(O) videobuf2_v4l2 videobuf2_core pci_stub videodev
vboxpci(O) media ath3k btusb btrtl btbcm btintel vboxdrv(O) bluetooth
rfkill loop usbip_host usbip_core sg ip_tables x_tables hid_generic
usbhid
[Sun May 28 04:58:06 2017]  hid sr_mod cdrom sd_mod serio_raw atkbd
libps2 ehci_pci xhci_pci ahci xhci_hcd ehci_hcd libahci libata
scsi_mod usbcore usb_common i8042 serio raid1 raid0 dm_mod md_mod
[Sun May 28 04:58:06 2017] CPU: 0 PID: 31 Comm: kworker/0:1 Tainted: G
  O4.11.3-1-ck2-ck #1
[Sun May 28 04:58:06 2017] Hardware name: Acer Aspire V3-771/VA70_HC,
BIOS V2.16 01/14/2013
[Sun May 28 04:58:06 2017] Workqueue: events_long flush_old_commits
[Sun May 28 04:58:06 2017] Call Trace:
[Sun May 28 04:58:06 2017]  ? dump_stack+0x5c/0x7a
[Sun May 28 04:58:06 2017]  ? __warn+0xb4/0xd0
[Sun May 27 04:58:06 2017]  ? dquot_writeback_dquots+0x248/0x250
[Sun May 27 04:58:06 2017]  ? reiserfs_sync_fs+0x12/0x70
[Sun May 27 04:58:06 2017]  ? dbs_work_handler+0x3d/0x50
[Sun May 27 04:58:06 2017]  ? flush_old_commits+0x30/0x50
[Sun May 27 04:58:06 2017]  ? process_one_work+0x1b1/0x3a0
[Sun May 27 04:58:06 2017]  ? worker_thread+0x42/0x4c0
[Sun May 27 04:58:06 2017]  ? kthread+0xf2/0x130
[Sun May 27 04:58:06 2017]  ? process_one_work+0x3a0/0x3a0
[Sun May 27 04:58:06 2017]  ? kthread_create_on_node+0x40/0x40
[Sun May 27 04:58:06 2017]  ? ret_from_fork+0x26/0x40
[Sun May 27 04:58:06 2017] ---[ end trace 7e040d020ba99607 ]---


This occurs during system boot on a fully-updated Archlinux system,
and has so since 4.10 100% of the time. It may occur after as well,
but it's a WARN_ONCE.

The attached patch corrects this issue by first trying to obtain a
readlock on said structure member, and if it got it, releases it
before returning.

After applying the patch, my system is completely stable and the
warning no longer occurs. Mounting and unmounting works as expected
without issue.

Thanks,
- Tim Savannah
--- a/fs/reiserfs/super.c	2017-05-29 00:14:45.0 -0400
+++ b/fs/reiserfs/super.c	2017-05-29 00:51:44.0 -0400
@@ -67,17 +67,28 @@
 static int reiserfs_sync_fs(struct super_block *s, int wait)
 {
 	struct reiserfs_transaction_handle th;
+	int got_lock;
 
 	/*
 	 * Writeback quota in non-journalled quota case - journalled quota has
 	 * no dirty dquots
 	 */
+
+	if ( down_read_trylock(>s_umount) )
+		got_lock = 1;
+	else
+		got_lock = 0;
+
 	dquot_writeback_dquots(s, -1);
 	reiserfs_write_lock(s);
 	if (!journal_begin(, s, 1))
 		if (!journal_end_sync())
 			reiserfs_flush_old_commits(s);
 	reiserfs_write_unlock(s);
+
+	if ( got_lock )
+		up_read(>s_umount);
+
 	return 0;
 }
 

[PATCH 1/1] - Fix reiserfs WARNING in dquot_writeback_dquots

[Tim Savannah]

Oops, sent last one without patch on accident. Attached this time.


This has been happening for me since 4.10

dquot_writeback_dquots expects a lock to be held on super_block->s_umount ,

and reiserfs_sync_fs, which calls dquot_writeback_dquots, does not
obtain such a lock.

Thus, the following warning is generated:

[Sun May 28 04:58:06 2017] [ cut here ]
[Sun May 28 04:58:06 2017] WARNING: CPU: 0 PID: 31 at
fs/quota/dquot.c:620 dquot_writeback_dquots+0x248/0x250
[Sun May 28 04:58:06 2017] Modules linked in: bbswitch(O)
nls_iso8859_1 nls_cp437 iTCO_wdt iTCO_vendor_support acer_wmi
sparse_keymap coretemp efi_pstore hwmon intel_rapl
x86_pkg_temp_thermal intel_powerclamp pcspkr ath9k ath9k_common
ath9k_hw ath efivars mac80211 joydev psmouse i2c_i801 cfg80211
input_leds led_class nvidiafb vgastate fb_ddc atl1c i915
drm_kms_helper drm intel_gtt syscopyarea sysfillrect sysimgblt mei_me
fb_sys_fops i2c_algo_bit mei lpc_ich shpchp acpi_cpufreq thermal wmi
video tpm_tis tpm_tis_core button tpm sch_fq_codel evdev mac_hid
uvcvideo vboxnetflt(O) videobuf2_vmalloc videobuf2_memops
vboxnetadp(O) videobuf2_v4l2 videobuf2_core pci_stub videodev
vboxpci(O) media ath3k btusb btrtl btbcm btintel vboxdrv(O) bluetooth
rfkill loop usbip_host usbip_core sg ip_tables x_tables hid_generic
usbhid
[Sun May 28 04:58:06 2017]  hid sr_mod cdrom sd_mod serio_raw atkbd
libps2 ehci_pci xhci_pci ahci xhci_hcd ehci_hcd libahci libata
scsi_mod usbcore usb_common i8042 serio raid1 raid0 dm_mod md_mod
[Sun May 28 04:58:06 2017] CPU: 0 PID: 31 Comm: kworker/0:1 Tainted: G
  O4.11.3-1-ck2-ck #1
[Sun May 28 04:58:06 2017] Hardware name: Acer Aspire V3-771/VA70_HC,
BIOS V2.16 01/14/2013
[Sun May 28 04:58:06 2017] Workqueue: events_long flush_old_commits
[Sun May 28 04:58:06 2017] Call Trace:
[Sun May 28 04:58:06 2017]  ? dump_stack+0x5c/0x7a
[Sun May 28 04:58:06 2017]  ? __warn+0xb4/0xd0
[Sun May 27 04:58:06 2017]  ? dquot_writeback_dquots+0x248/0x250
[Sun May 27 04:58:06 2017]  ? reiserfs_sync_fs+0x12/0x70
[Sun May 27 04:58:06 2017]  ? dbs_work_handler+0x3d/0x50
[Sun May 27 04:58:06 2017]  ? flush_old_commits+0x30/0x50
[Sun May 27 04:58:06 2017]  ? process_one_work+0x1b1/0x3a0
[Sun May 27 04:58:06 2017]  ? worker_thread+0x42/0x4c0
[Sun May 27 04:58:06 2017]  ? kthread+0xf2/0x130
[Sun May 27 04:58:06 2017]  ? process_one_work+0x3a0/0x3a0
[Sun May 27 04:58:06 2017]  ? kthread_create_on_node+0x40/0x40
[Sun May 27 04:58:06 2017]  ? ret_from_fork+0x26/0x40
[Sun May 27 04:58:06 2017] ---[ end trace 7e040d020ba99607 ]---


This occurs during system boot on a fully-updated Archlinux system,
and has so since 4.10 100% of the time. It may occur after as well,
but it's a WARN_ONCE.

The attached patch corrects this issue by first trying to obtain a
readlock on said structure member, and if it got it, releases it
before returning.

After applying the patch, my system is completely stable and the
warning no longer occurs. Mounting and unmounting works as expected
without issue.

Thanks,
- Tim Savannah
--- a/fs/reiserfs/super.c	2017-05-29 00:14:45.0 -0400
+++ b/fs/reiserfs/super.c	2017-05-29 00:51:44.0 -0400
@@ -67,17 +67,28 @@
 static int reiserfs_sync_fs(struct super_block *s, int wait)
 {
 	struct reiserfs_transaction_handle th;
+	int got_lock;
 
 	/*
 	 * Writeback quota in non-journalled quota case - journalled quota has
 	 * no dirty dquots
 	 */
+
+	if ( down_read_trylock(>s_umount) )
+		got_lock = 1;
+	else
+		got_lock = 0;
+
 	dquot_writeback_dquots(s, -1);
 	reiserfs_write_lock(s);
 	if (!journal_begin(, s, 1))
 		if (!journal_end_sync())
 			reiserfs_flush_old_commits(s);
 	reiserfs_write_unlock(s);
+
+	if ( got_lock )
+		up_read(>s_umount);
+
 	return 0;
 }
 

[PATCH 1/1] - Fix reiserfs WARNING in dquot_writeback_dquots

[Tim Savannah]

This has been happening for me since 4.10

dquot_writeback_dquots expects a lock to be held on super_block->s_umount ,

and reiserfs_sync_fs, which calls dquot_writeback_dquots, does not
obtain such a lock.

Thus, the following warning is generated:

[Sun May 28 04:58:06 2017] [ cut here ]
[Sun May 28 04:58:06 2017] WARNING: CPU: 0 PID: 31 at
fs/quota/dquot.c:620 dquot_writeback_dquots+0x248/0x250
[Sun May 28 04:58:06 2017] Modules linked in: bbswitch(O)
nls_iso8859_1 nls_cp437 iTCO_wdt iTCO_vendor_support acer_wmi
sparse_keymap coretemp efi_pstore hwmon intel_rapl
x86_pkg_temp_thermal intel_powerclamp pcspkr ath9k ath9k_common
ath9k_hw ath efivars mac80211 joydev psmouse i2c_i801 cfg80211
input_leds led_class nvidiafb vgastate fb_ddc atl1c i915
drm_kms_helper drm intel_gtt syscopyarea sysfillrect sysimgblt mei_me
fb_sys_fops i2c_algo_bit mei lpc_ich shpchp acpi_cpufreq thermal wmi
video tpm_tis tpm_tis_core button tpm sch_fq_codel evdev mac_hid
uvcvideo vboxnetflt(O) videobuf2_vmalloc videobuf2_memops
vboxnetadp(O) videobuf2_v4l2 videobuf2_core pci_stub videodev
vboxpci(O) media ath3k btusb btrtl btbcm btintel vboxdrv(O) bluetooth
rfkill loop usbip_host usbip_core sg ip_tables x_tables hid_generic
usbhid
[Sun May 28 04:58:06 2017]  hid sr_mod cdrom sd_mod serio_raw atkbd
libps2 ehci_pci xhci_pci ahci xhci_hcd ehci_hcd libahci libata
scsi_mod usbcore usb_common i8042 serio raid1 raid0 dm_mod md_mod
[Sun May 28 04:58:06 2017] CPU: 0 PID: 31 Comm: kworker/0:1 Tainted: G
  O4.11.3-1-ck2-ck #1
[Sun May 28 04:58:06 2017] Hardware name: Acer Aspire V3-771/VA70_HC,
BIOS V2.16 01/14/2013
[Sun May 28 04:58:06 2017] Workqueue: events_long flush_old_commits
[Sun May 28 04:58:06 2017] Call Trace:
[Sun May 28 04:58:06 2017]  ? dump_stack+0x5c/0x7a
[Sun May 28 04:58:06 2017]  ? __warn+0xb4/0xd0
[Sun May 27 04:58:06 2017]  ? dquot_writeback_dquots+0x248/0x250
[Sun May 27 04:58:06 2017]  ? reiserfs_sync_fs+0x12/0x70
[Sun May 27 04:58:06 2017]  ? dbs_work_handler+0x3d/0x50
[Sun May 27 04:58:06 2017]  ? flush_old_commits+0x30/0x50
[Sun May 27 04:58:06 2017]  ? process_one_work+0x1b1/0x3a0
[Sun May 27 04:58:06 2017]  ? worker_thread+0x42/0x4c0
[Sun May 27 04:58:06 2017]  ? kthread+0xf2/0x130
[Sun May 27 04:58:06 2017]  ? process_one_work+0x3a0/0x3a0
[Sun May 27 04:58:06 2017]  ? kthread_create_on_node+0x40/0x40
[Sun May 27 04:58:06 2017]  ? ret_from_fork+0x26/0x40
[Sun May 27 04:58:06 2017] ---[ end trace 7e040d020ba99607 ]---


This occurs during system boot on a fully-updated Archlinux system,
and has so since 4.10 100% of the time. It may occur after as well,
but it's a WARN_ONCE.

The attached patch corrects this issue by first trying to obtain a
readlock on said structure member, and if it got it, releases it
before returning.

After applying the patch, my system is completely stable and the
warning no longer occurs. Mounting and unmounting works as expected
without issue.

Thanks,
- Tim Savannah

[PATCH 1/1] - Fix reiserfs WARNING in dquot_writeback_dquots

[Tim Savannah]

This has been happening for me since 4.10

dquot_writeback_dquots expects a lock to be held on super_block->s_umount ,

and reiserfs_sync_fs, which calls dquot_writeback_dquots, does not
obtain such a lock.

Thus, the following warning is generated:

[Sun May 28 04:58:06 2017] [ cut here ]
[Sun May 28 04:58:06 2017] WARNING: CPU: 0 PID: 31 at
fs/quota/dquot.c:620 dquot_writeback_dquots+0x248/0x250
[Sun May 28 04:58:06 2017] Modules linked in: bbswitch(O)
nls_iso8859_1 nls_cp437 iTCO_wdt iTCO_vendor_support acer_wmi
sparse_keymap coretemp efi_pstore hwmon intel_rapl
x86_pkg_temp_thermal intel_powerclamp pcspkr ath9k ath9k_common
ath9k_hw ath efivars mac80211 joydev psmouse i2c_i801 cfg80211
input_leds led_class nvidiafb vgastate fb_ddc atl1c i915
drm_kms_helper drm intel_gtt syscopyarea sysfillrect sysimgblt mei_me
fb_sys_fops i2c_algo_bit mei lpc_ich shpchp acpi_cpufreq thermal wmi
video tpm_tis tpm_tis_core button tpm sch_fq_codel evdev mac_hid
uvcvideo vboxnetflt(O) videobuf2_vmalloc videobuf2_memops
vboxnetadp(O) videobuf2_v4l2 videobuf2_core pci_stub videodev
vboxpci(O) media ath3k btusb btrtl btbcm btintel vboxdrv(O) bluetooth
rfkill loop usbip_host usbip_core sg ip_tables x_tables hid_generic
usbhid
[Sun May 28 04:58:06 2017]  hid sr_mod cdrom sd_mod serio_raw atkbd
libps2 ehci_pci xhci_pci ahci xhci_hcd ehci_hcd libahci libata
scsi_mod usbcore usb_common i8042 serio raid1 raid0 dm_mod md_mod
[Sun May 28 04:58:06 2017] CPU: 0 PID: 31 Comm: kworker/0:1 Tainted: G
  O4.11.3-1-ck2-ck #1
[Sun May 28 04:58:06 2017] Hardware name: Acer Aspire V3-771/VA70_HC,
BIOS V2.16 01/14/2013
[Sun May 28 04:58:06 2017] Workqueue: events_long flush_old_commits
[Sun May 28 04:58:06 2017] Call Trace:
[Sun May 28 04:58:06 2017]  ? dump_stack+0x5c/0x7a
[Sun May 28 04:58:06 2017]  ? __warn+0xb4/0xd0
[Sun May 27 04:58:06 2017]  ? dquot_writeback_dquots+0x248/0x250
[Sun May 27 04:58:06 2017]  ? reiserfs_sync_fs+0x12/0x70
[Sun May 27 04:58:06 2017]  ? dbs_work_handler+0x3d/0x50
[Sun May 27 04:58:06 2017]  ? flush_old_commits+0x30/0x50
[Sun May 27 04:58:06 2017]  ? process_one_work+0x1b1/0x3a0
[Sun May 27 04:58:06 2017]  ? worker_thread+0x42/0x4c0
[Sun May 27 04:58:06 2017]  ? kthread+0xf2/0x130
[Sun May 27 04:58:06 2017]  ? process_one_work+0x3a0/0x3a0
[Sun May 27 04:58:06 2017]  ? kthread_create_on_node+0x40/0x40
[Sun May 27 04:58:06 2017]  ? ret_from_fork+0x26/0x40
[Sun May 27 04:58:06 2017] ---[ end trace 7e040d020ba99607 ]---


This occurs during system boot on a fully-updated Archlinux system,
and has so since 4.10 100% of the time. It may occur after as well,
but it's a WARN_ONCE.

The attached patch corrects this issue by first trying to obtain a
readlock on said structure member, and if it got it, releases it
before returning.

After applying the patch, my system is completely stable and the
warning no longer occurs. Mounting and unmounting works as expected
without issue.

Thanks,
- Tim Savannah

[PATCH V5] hwmon: (ibmpowernv) Add highest/lowest attributes to sensors

[Shilpasri G Bhat]

OCC provides historical minimum and maximum value for the sensor
readings. This patch exports them as highest and lowest attributes
for the inband sensors copied by OCC to main memory.

Signed-off-by: Shilpasri G Bhat 
---
Changes from V4:
- Got rid of 'len' variable in populate_attr_groups

 drivers/hwmon/ibmpowernv.c | 68 +-
 1 file changed, 61 insertions(+), 7 deletions(-)

diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
index 6d2e660..b562323 100644
--- a/drivers/hwmon/ibmpowernv.c
+++ b/drivers/hwmon/ibmpowernv.c
@@ -298,10 +298,14 @@ static int populate_attr_groups(struct platform_device 
*pdev)
sensor_groups[type].attr_count++;
 
/*
-* add a new attribute for labels
+* add attributes for labels, min and max
 */
if (!of_property_read_string(np, "label", ))
sensor_groups[type].attr_count++;
+   if (of_find_property(np, "sensor-data-min", NULL))
+   sensor_groups[type].attr_count++;
+   if (of_find_property(np, "sensor-data-max", NULL))
+   sensor_groups[type].attr_count++;
}
 
of_node_put(opal);
@@ -337,6 +341,41 @@ static void create_hwmon_attr(struct sensor_data *sdata, 
const char *attr_name,
sdata->dev_attr.show = show;
 }
 
+static void populate_sensor(struct sensor_data *sdata, int od, int hd, int sid,
+   const char *attr_name, enum sensors type,
+   const struct attribute_group *pgroup,
+   ssize_t (*show)(struct device *dev,
+   struct device_attribute *attr,
+   char *buf))
+{
+   sdata->id = sid;
+   sdata->type = type;
+   sdata->opal_index = od;
+   sdata->hwmon_index = hd;
+   create_hwmon_attr(sdata, attr_name, show);
+   pgroup->attrs[sensor_groups[type].attr_count++] = >dev_attr.attr;
+}
+
+static char *get_max_attr(enum sensors type)
+{
+   switch (type) {
+   case POWER_INPUT:
+   return "input_highest";
+   default:
+   return "highest";
+   }
+}
+
+static char *get_min_attr(enum sensors type)
+{
+   switch (type) {
+   case POWER_INPUT:
+   return "input_lowest";
+   default:
+   return "lowest";
+   }
+}
+
 /*
  * Iterate through the device tree for each child of 'sensors' node, create
  * a sysfs attribute file, the file is named by translating the DT node name
@@ -417,16 +456,31 @@ static int create_device_attrs(struct platform_device 
*pdev)
 * attribute. They are related to the same
 * sensor.
 */
-   sdata[count].type = type;
-   sdata[count].opal_index = sdata[count - 1].opal_index;
-   sdata[count].hwmon_index = sdata[count - 1].hwmon_index;
 
make_sensor_label(np, [count], label);
+   populate_sensor([count], opal_index,
+   sdata[count - 1].hwmon_index,
+   sensor_id, "label", type, pgroups[type],
+   show_label);
+   count++;
+   }
 
-   create_hwmon_attr([count], "label", show_label);
+   if (!of_property_read_u32(np, "sensor-data-max", _id)) {
+   attr_name = get_max_attr(type);
+   populate_sensor([count], opal_index,
+   sdata[count - 1].hwmon_index,
+   sensor_id, attr_name, type,
+   pgroups[type], show_sensor);
+   count++;
+   }
 
-   pgroups[type]->attrs[sensor_groups[type].attr_count++] =
-   [count++].dev_attr.attr;
+   if (!of_property_read_u32(np, "sensor-data-min", _id)) {
+   attr_name = get_min_attr(type);
+   populate_sensor([count], opal_index,
+   sdata[count - 1].hwmon_index,
+   sensor_id, attr_name, type,
+   pgroups[type], show_sensor);
+   count++;
}
}
 
-- 
1.8.3.1

[PATCH V5] hwmon: (ibmpowernv) Add highest/lowest attributes to sensors

[Shilpasri G Bhat]

OCC provides historical minimum and maximum value for the sensor
readings. This patch exports them as highest and lowest attributes
for the inband sensors copied by OCC to main memory.

Signed-off-by: Shilpasri G Bhat 
---
Changes from V4:
- Got rid of 'len' variable in populate_attr_groups

 drivers/hwmon/ibmpowernv.c | 68 +-
 1 file changed, 61 insertions(+), 7 deletions(-)

diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
index 6d2e660..b562323 100644
--- a/drivers/hwmon/ibmpowernv.c
+++ b/drivers/hwmon/ibmpowernv.c
@@ -298,10 +298,14 @@ static int populate_attr_groups(struct platform_device 
*pdev)
sensor_groups[type].attr_count++;
 
/*
-* add a new attribute for labels
+* add attributes for labels, min and max
 */
if (!of_property_read_string(np, "label", ))
sensor_groups[type].attr_count++;
+   if (of_find_property(np, "sensor-data-min", NULL))
+   sensor_groups[type].attr_count++;
+   if (of_find_property(np, "sensor-data-max", NULL))
+   sensor_groups[type].attr_count++;
}
 
of_node_put(opal);
@@ -337,6 +341,41 @@ static void create_hwmon_attr(struct sensor_data *sdata, 
const char *attr_name,
sdata->dev_attr.show = show;
 }
 
+static void populate_sensor(struct sensor_data *sdata, int od, int hd, int sid,
+   const char *attr_name, enum sensors type,
+   const struct attribute_group *pgroup,
+   ssize_t (*show)(struct device *dev,
+   struct device_attribute *attr,
+   char *buf))
+{
+   sdata->id = sid;
+   sdata->type = type;
+   sdata->opal_index = od;
+   sdata->hwmon_index = hd;
+   create_hwmon_attr(sdata, attr_name, show);
+   pgroup->attrs[sensor_groups[type].attr_count++] = >dev_attr.attr;
+}
+
+static char *get_max_attr(enum sensors type)
+{
+   switch (type) {
+   case POWER_INPUT:
+   return "input_highest";
+   default:
+   return "highest";
+   }
+}
+
+static char *get_min_attr(enum sensors type)
+{
+   switch (type) {
+   case POWER_INPUT:
+   return "input_lowest";
+   default:
+   return "lowest";
+   }
+}
+
 /*
  * Iterate through the device tree for each child of 'sensors' node, create
  * a sysfs attribute file, the file is named by translating the DT node name
@@ -417,16 +456,31 @@ static int create_device_attrs(struct platform_device 
*pdev)
 * attribute. They are related to the same
 * sensor.
 */
-   sdata[count].type = type;
-   sdata[count].opal_index = sdata[count - 1].opal_index;
-   sdata[count].hwmon_index = sdata[count - 1].hwmon_index;
 
make_sensor_label(np, [count], label);
+   populate_sensor([count], opal_index,
+   sdata[count - 1].hwmon_index,
+   sensor_id, "label", type, pgroups[type],
+   show_label);
+   count++;
+   }
 
-   create_hwmon_attr([count], "label", show_label);
+   if (!of_property_read_u32(np, "sensor-data-max", _id)) {
+   attr_name = get_max_attr(type);
+   populate_sensor([count], opal_index,
+   sdata[count - 1].hwmon_index,
+   sensor_id, attr_name, type,
+   pgroups[type], show_sensor);
+   count++;
+   }
 
-   pgroups[type]->attrs[sensor_groups[type].attr_count++] =
-   [count++].dev_attr.attr;
+   if (!of_property_read_u32(np, "sensor-data-min", _id)) {
+   attr_name = get_min_attr(type);
+   populate_sensor([count], opal_index,
+   sdata[count - 1].hwmon_index,
+   sensor_id, attr_name, type,
+   pgroups[type], show_sensor);
+   count++;
}
}
 
-- 
1.8.3.1

Re: [PATCH] ubifs: Add freeze support

[Hyunchul Lee]

and I missed the following case.

in some embedded systems, clean-up for shutdown should be fast.
during this clean-up, freeze file system to guarantee integrity.
umount with MNT_DETACH is not suitable because of not killing tasks.

On Mon, May 29, 2017 at 10:18:34AM +0900, Hyunchul Lee wrote:
> Hi, Richard.
> 
> On Fri, May 26, 2017 at 11:52:42AM +0200, Richard Weinberger wrote:
> > Hyunchul,
> > 
> > Am 26.05.2017 um 01:30 schrieb Hyunchul Lee:
> > > From: Hyunchul Lee 
> > > 
> > > for un/freeze support, implement freeze_super and un/freeze_fs
> > > of super_operations.
> > > ubifs_freeze_super just calls freeze_super. because freeze_super always
> > > succeeds if file system is read-only,  UBIFS errors should be checked.
> > > if there are errors, UBIFS is switched to read-only mode.
> > > ubifs_freeze_fs runs commit if TNC/LPT isn't clean. though all writes
> > > are blocked and sync_fs is called before, if commit alreay was started
> > > before writes are blocked, TNC/LPT might have dirty COW nodes.
> > 
> > you explain how you implement that feature, but not why.
> > What is the use-case?
> > I always thought this interface is only being used by LVM.
> 
> Sorry, I forgot this. I implement this to make a backup of some files, and
> support fsfreeze utility and SysRq's freeze/thaw commmand.
> 
> > 
> > Thanks,
> > //richard
> > 
> > __
> > Linux MTD discussion mailing list
> > http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 
> -- 
> 
> Thanks,
> Hyunchul
> 
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

-- 

Thanks,
Hyunchul

Re: [PATCH] ubifs: Add freeze support

[Hyunchul Lee]

and I missed the following case.

in some embedded systems, clean-up for shutdown should be fast.
during this clean-up, freeze file system to guarantee integrity.
umount with MNT_DETACH is not suitable because of not killing tasks.

On Mon, May 29, 2017 at 10:18:34AM +0900, Hyunchul Lee wrote:
> Hi, Richard.
> 
> On Fri, May 26, 2017 at 11:52:42AM +0200, Richard Weinberger wrote:
> > Hyunchul,
> > 
> > Am 26.05.2017 um 01:30 schrieb Hyunchul Lee:
> > > From: Hyunchul Lee 
> > > 
> > > for un/freeze support, implement freeze_super and un/freeze_fs
> > > of super_operations.
> > > ubifs_freeze_super just calls freeze_super. because freeze_super always
> > > succeeds if file system is read-only,  UBIFS errors should be checked.
> > > if there are errors, UBIFS is switched to read-only mode.
> > > ubifs_freeze_fs runs commit if TNC/LPT isn't clean. though all writes
> > > are blocked and sync_fs is called before, if commit alreay was started
> > > before writes are blocked, TNC/LPT might have dirty COW nodes.
> > 
> > you explain how you implement that feature, but not why.
> > What is the use-case?
> > I always thought this interface is only being used by LVM.
> 
> Sorry, I forgot this. I implement this to make a backup of some files, and
> support fsfreeze utility and SysRq's freeze/thaw commmand.
> 
> > 
> > Thanks,
> > //richard
> > 
> > __
> > Linux MTD discussion mailing list
> > http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 
> -- 
> 
> Thanks,
> Hyunchul
> 
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

-- 

Thanks,
Hyunchul

[PATCH] pinctrl: xway: fix copy/paste error in xrx200_grps

[Martin Schiller]

Signed-off-by: Martin Schiller 
---
 drivers/pinctrl/pinctrl-xway.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/pinctrl-xway.c b/drivers/pinctrl/pinctrl-xway.c
index d4167e2..f9e98a7 100644
--- a/drivers/pinctrl/pinctrl-xway.c
+++ b/drivers/pinctrl/pinctrl-xway.c
@@ -1028,7 +1028,7 @@ static const struct ltq_pin_group xrx200_grps[] = {
GRP_MUX("spi_cs5", SPI, xrx200_pins_spi_cs5),
GRP_MUX("spi_cs6", SPI, xrx200_pins_spi_cs6),
GRP_MUX("usif uart_rx", USIF, xrx200_pins_usif_uart_rx),
-   GRP_MUX("usif uart_rx", USIF, xrx200_pins_usif_uart_tx),
+   GRP_MUX("usif uart_tx", USIF, xrx200_pins_usif_uart_tx),
GRP_MUX("usif uart_rts", USIF, xrx200_pins_usif_uart_rts),
GRP_MUX("usif uart_cts", USIF, xrx200_pins_usif_uart_cts),
GRP_MUX("usif uart_dtr", USIF, xrx200_pins_usif_uart_dtr),
-- 
2.1.4

[PATCH] pinctrl: xway: fix copy/paste error in xrx200_grps

[Martin Schiller]

Signed-off-by: Martin Schiller 
---
 drivers/pinctrl/pinctrl-xway.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/pinctrl-xway.c b/drivers/pinctrl/pinctrl-xway.c
index d4167e2..f9e98a7 100644
--- a/drivers/pinctrl/pinctrl-xway.c
+++ b/drivers/pinctrl/pinctrl-xway.c
@@ -1028,7 +1028,7 @@ static const struct ltq_pin_group xrx200_grps[] = {
GRP_MUX("spi_cs5", SPI, xrx200_pins_spi_cs5),
GRP_MUX("spi_cs6", SPI, xrx200_pins_spi_cs6),
GRP_MUX("usif uart_rx", USIF, xrx200_pins_usif_uart_rx),
-   GRP_MUX("usif uart_rx", USIF, xrx200_pins_usif_uart_tx),
+   GRP_MUX("usif uart_tx", USIF, xrx200_pins_usif_uart_tx),
GRP_MUX("usif uart_rts", USIF, xrx200_pins_usif_uart_rts),
GRP_MUX("usif uart_cts", USIF, xrx200_pins_usif_uart_cts),
GRP_MUX("usif uart_dtr", USIF, xrx200_pins_usif_uart_dtr),
-- 
2.1.4

Re: [PATCH] spi: add null check before pointer dereference

[Andi Shyti]

Hi Gustavo,

>   desc = dmaengine_prep_slave_sg(dma->ch, sgt->sgl, sgt->nents,
>  dma->direction, DMA_PREP_INTERRUPT);
>  
> + if (!desc) {
> + dev_err(>master->dev,
> + "%s:dmaengine_prep_slave_sg Failed\n", __func__);
> + return;
> + }
> +

I'm sorry, I would nack this patch for now. There was a smilar I
sent before, but, as Krzysztof said, this needs more testing and
a proper solution.

That's anyway in my todo list.

Thanks,
Andi

Re: [PATCH] spi: add null check before pointer dereference

[Andi Shyti]

Hi Gustavo,

>   desc = dmaengine_prep_slave_sg(dma->ch, sgt->sgl, sgt->nents,
>  dma->direction, DMA_PREP_INTERRUPT);
>  
> + if (!desc) {
> + dev_err(>master->dev,
> + "%s:dmaengine_prep_slave_sg Failed\n", __func__);
> + return;
> + }
> +

I'm sorry, I would nack this patch for now. There was a smilar I
sent before, but, as Krzysztof said, this needs more testing and
a proper solution.

That's anyway in my todo list.

Thanks,
Andi

linux-next: Tree for May 29

[Stephen Rothwell]

Hi all,

Changes since 20170526:

Non-merge commits (relative to Linus' tree): 2862
 3154 files changed, 118750 insertions(+), 64872 deletions(-)



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

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

Below is a summary of the state of the merge.

I am currently merging 261 trees (counting Linus' and 40 trees of bug
fix patches pending for the current merge release).

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (249f1efd8e3d Merge tag 'tty-4.12-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty)
Merging fixes/master (97da3854c526 Linux 4.11-rc3)
Merging kbuild-current/fixes (05d8cba4a1e8 kbuild: skip install/check of 
headers right under uapi directories)
Merging arc-current/for-curr (a4da5b17736d arc: Set IO-coherency aperture base 
to LINUX_LINK_BASE)
Merging arm-current/fixes (2ea659a9ef48 Linux 4.12-rc1)
Merging m68k-current/for-linus (f6ab4d59a5fe nubus: Add MVC and VSC video card 
definitions)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (a4700a261072 powerpc: Add PPC_FEATURE userspace 
bits for SCV and DARN instructions)
Merging sparc/master (7485af89a6fd arch/sparc: increase CONFIG_NODES_SHIFT on 
SPARC64 to 5)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (c21fbe29f858 net: dsa: mv88e6xxx: Add missing static to 
stub functions)
Merging ipsec/master (a486cd23661c xfrm: fix state migration copy replay 
sequence numbers)
Merging netfilter/master (fefa92679dbe netfilter: ctnetlink: fix incorrect 
nf_ct_put during hash resize)
Merging ipvs/master (3c5ab3f395d6 ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (6d18c732b95c bridge: start hello_timer when 
enabling KERNEL_STP in br_stp_start)
Merging mac80211/master (029c58178b9a Merge tag 'mac80211-for-davem-2017-05-23' 
of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211)
Merging sound-current/for-linus (1fc2e41f7af4 ALSA: hda - apply 
STAC_9200_DELL_M22 quirk for Dell Latitude D430)
Merging pci-current/for-linus (bd2df9b1e094 PCI: Make error code types 
consistent in pci_{read,write}_config_*)
Merging driver-core.current/driver-core-linus (08332893e37a Linux 4.12-rc2)
Merging tty.current/tty-linus (59fe2cc8b1c3 serial: altera_uart: call iounmap() 
at driver remove)
Merging usb.current/usb-linus (b3addcf0d1f0 usb: musb: dsps: keep VBUS on for 
host-only mode)
Merging usb-gadget-fixes/fixes (a351e9b9fc24 Linux 4.11)
Merging usb-serial-fixes/usb-linus (08332893e37a Linux 4.12-rc2)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (a380b78b799b phy: qualcomm: phy-qcom-qmp: fix application of 
sizeof to pointer)
Merging staging.current/staging-linus (3d51b9562673 staging: ccree: add CRYPTO 
dependency)
Merging char-misc.current/char-misc-linus (cdc1daca1b9b MAINTAINERS: Change 
maintainer of genwqe driver)
Merging input-current/for-linus (a04f144059ac Input: elan_i2c - ignore signals 
when finishing updating firmware)
Merging crypto-current/master (f3ad587070d6 crypto: gcm - wait for crypto op 
not signal safe)
Merging ide/master (acfead32f3f9 ide: don't call memcpy with the same source 
and destination)
Merging vfio-fixes/for-linus (39da7c509acf Linux 4.11-rc6)
Merging kselftest-fixes/fixes (2ea659a9ef48 Linux 4.12-rc1)
Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: 
Handle 

linux-next: Tree for May 29

[Stephen Rothwell]

Hi all,

Changes since 20170526:

Non-merge commits (relative to Linus' tree): 2862
 3154 files changed, 118750 insertions(+), 64872 deletions(-)



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

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

Below is a summary of the state of the merge.

I am currently merging 261 trees (counting Linus' and 40 trees of bug
fix patches pending for the current merge release).

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (249f1efd8e3d Merge tag 'tty-4.12-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty)
Merging fixes/master (97da3854c526 Linux 4.11-rc3)
Merging kbuild-current/fixes (05d8cba4a1e8 kbuild: skip install/check of 
headers right under uapi directories)
Merging arc-current/for-curr (a4da5b17736d arc: Set IO-coherency aperture base 
to LINUX_LINK_BASE)
Merging arm-current/fixes (2ea659a9ef48 Linux 4.12-rc1)
Merging m68k-current/for-linus (f6ab4d59a5fe nubus: Add MVC and VSC video card 
definitions)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (a4700a261072 powerpc: Add PPC_FEATURE userspace 
bits for SCV and DARN instructions)
Merging sparc/master (7485af89a6fd arch/sparc: increase CONFIG_NODES_SHIFT on 
SPARC64 to 5)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (c21fbe29f858 net: dsa: mv88e6xxx: Add missing static to 
stub functions)
Merging ipsec/master (a486cd23661c xfrm: fix state migration copy replay 
sequence numbers)
Merging netfilter/master (fefa92679dbe netfilter: ctnetlink: fix incorrect 
nf_ct_put during hash resize)
Merging ipvs/master (3c5ab3f395d6 ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (6d18c732b95c bridge: start hello_timer when 
enabling KERNEL_STP in br_stp_start)
Merging mac80211/master (029c58178b9a Merge tag 'mac80211-for-davem-2017-05-23' 
of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211)
Merging sound-current/for-linus (1fc2e41f7af4 ALSA: hda - apply 
STAC_9200_DELL_M22 quirk for Dell Latitude D430)
Merging pci-current/for-linus (bd2df9b1e094 PCI: Make error code types 
consistent in pci_{read,write}_config_*)
Merging driver-core.current/driver-core-linus (08332893e37a Linux 4.12-rc2)
Merging tty.current/tty-linus (59fe2cc8b1c3 serial: altera_uart: call iounmap() 
at driver remove)
Merging usb.current/usb-linus (b3addcf0d1f0 usb: musb: dsps: keep VBUS on for 
host-only mode)
Merging usb-gadget-fixes/fixes (a351e9b9fc24 Linux 4.11)
Merging usb-serial-fixes/usb-linus (08332893e37a Linux 4.12-rc2)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (a380b78b799b phy: qualcomm: phy-qcom-qmp: fix application of 
sizeof to pointer)
Merging staging.current/staging-linus (3d51b9562673 staging: ccree: add CRYPTO 
dependency)
Merging char-misc.current/char-misc-linus (cdc1daca1b9b MAINTAINERS: Change 
maintainer of genwqe driver)
Merging input-current/for-linus (a04f144059ac Input: elan_i2c - ignore signals 
when finishing updating firmware)
Merging crypto-current/master (f3ad587070d6 crypto: gcm - wait for crypto op 
not signal safe)
Merging ide/master (acfead32f3f9 ide: don't call memcpy with the same source 
and destination)
Merging vfio-fixes/for-linus (39da7c509acf Linux 4.11-rc6)
Merging kselftest-fixes/fixes (2ea659a9ef48 Linux 4.12-rc1)
Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: 
Handle 

Re: [PATCH v3 1/2] mmc: dw_mmc: Use device_property_read instead of of_property_read

[Jaehoon Chung]

On 05/27/2017 06:53 AM, David Woods wrote:
> Using the device_property interfaces allows the dw_mmc driver to work
> on platforms which run on either device tree or ACPI.
> 
> Signed-off-by: David Woods 
> Reviewed-by: Chris Metcalf 
> Cc: sta...@vger.linux.org

Acked-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

> ---
>  drivers/mmc/host/dw_mmc.c | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index e45129f..efde0f2 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -2707,8 +2707,8 @@ static int dw_mci_init_slot(struct dw_mci *host, 
> unsigned int id)
>   host->slot[id] = slot;
>  
>   mmc->ops = _mci_ops;
> - if (of_property_read_u32_array(host->dev->of_node,
> -"clock-freq-min-max", freq, 2)) {
> + if (device_property_read_u32_array(host->dev, "clock-freq-min-max",
> +freq, 2)) {
>   mmc->f_min = DW_MCI_FREQ_MIN;
>   mmc->f_max = DW_MCI_FREQ_MAX;
>   } else {
> @@ -2808,7 +2808,6 @@ static void dw_mci_init_dma(struct dw_mci *host)
>  {
>   int addr_config;
>   struct device *dev = host->dev;
> - struct device_node *np = dev->of_node;
>  
>   /*
>   * Check tansfer mode from HCON[17:16]
> @@ -2869,8 +2868,9 @@ static void dw_mci_init_dma(struct dw_mci *host)
>   dev_info(host->dev, "Using internal DMA controller.\n");
>   } else {
>   /* TRANS_MODE_EDMAC: check dma bindings again */
> - if ((of_property_count_strings(np, "dma-names") < 0) ||
> - (!of_find_property(np, "dmas", NULL))) {
> + if ((device_property_read_string_array(dev, "dma-names",
> +NULL, 0) < 0) ||
> + !device_property_present(dev, "dmas")) {
>   goto no_dma;
>   }
>   host->dma_ops = _mci_edmac_ops;
> @@ -2937,7 +2937,6 @@ static struct dw_mci_board *dw_mci_parse_dt(struct 
> dw_mci *host)
>  {
>   struct dw_mci_board *pdata;
>   struct device *dev = host->dev;
> - struct device_node *np = dev->of_node;
>   const struct dw_mci_drv_data *drv_data = host->drv_data;
>   int ret;
>   u32 clock_frequency;
> @@ -2954,20 +2953,21 @@ static struct dw_mci_board *dw_mci_parse_dt(struct 
> dw_mci *host)
>   }
>  
>   /* find out number of slots supported */
> - of_property_read_u32(np, "num-slots", >num_slots);
> + device_property_read_u32(dev, "num-slots", >num_slots);
>  
> - if (of_property_read_u32(np, "fifo-depth", >fifo_depth))
> + if (device_property_read_u32(dev, "fifo-depth", >fifo_depth))
>   dev_info(dev,
>"fifo-depth property not found, using value of FIFOTH 
> register as default\n");
>  
> - of_property_read_u32(np, "card-detect-delay", >detect_delay_ms);
> + device_property_read_u32(dev, "card-detect-delay",
> +  >detect_delay_ms);
>  
> - of_property_read_u32(np, "data-addr", >data_addr_override);
> + device_property_read_u32(dev, "data-addr", >data_addr_override);
>  
> - if (of_get_property(np, "fifo-watermark-aligned", NULL))
> + if (device_property_present(dev, "fifo-watermark-aligned"))
>   host->wm_aligned = true;
>  
> - if (!of_property_read_u32(np, "clock-frequency", _frequency))
> + if (!device_property_read_u32(dev, "clock-frequency", _frequency))
>   pdata->bus_hz = clock_frequency;
>  
>   if (drv_data && drv_data->parse_dt) {
> 

Re: [PATCH v3 1/2] mmc: dw_mmc: Use device_property_read instead of of_property_read

[Jaehoon Chung]

On 05/27/2017 06:53 AM, David Woods wrote:
> Using the device_property interfaces allows the dw_mmc driver to work
> on platforms which run on either device tree or ACPI.
> 
> Signed-off-by: David Woods 
> Reviewed-by: Chris Metcalf 
> Cc: sta...@vger.linux.org

Acked-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

> ---
>  drivers/mmc/host/dw_mmc.c | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index e45129f..efde0f2 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -2707,8 +2707,8 @@ static int dw_mci_init_slot(struct dw_mci *host, 
> unsigned int id)
>   host->slot[id] = slot;
>  
>   mmc->ops = _mci_ops;
> - if (of_property_read_u32_array(host->dev->of_node,
> -"clock-freq-min-max", freq, 2)) {
> + if (device_property_read_u32_array(host->dev, "clock-freq-min-max",
> +freq, 2)) {
>   mmc->f_min = DW_MCI_FREQ_MIN;
>   mmc->f_max = DW_MCI_FREQ_MAX;
>   } else {
> @@ -2808,7 +2808,6 @@ static void dw_mci_init_dma(struct dw_mci *host)
>  {
>   int addr_config;
>   struct device *dev = host->dev;
> - struct device_node *np = dev->of_node;
>  
>   /*
>   * Check tansfer mode from HCON[17:16]
> @@ -2869,8 +2868,9 @@ static void dw_mci_init_dma(struct dw_mci *host)
>   dev_info(host->dev, "Using internal DMA controller.\n");
>   } else {
>   /* TRANS_MODE_EDMAC: check dma bindings again */
> - if ((of_property_count_strings(np, "dma-names") < 0) ||
> - (!of_find_property(np, "dmas", NULL))) {
> + if ((device_property_read_string_array(dev, "dma-names",
> +NULL, 0) < 0) ||
> + !device_property_present(dev, "dmas")) {
>   goto no_dma;
>   }
>   host->dma_ops = _mci_edmac_ops;
> @@ -2937,7 +2937,6 @@ static struct dw_mci_board *dw_mci_parse_dt(struct 
> dw_mci *host)
>  {
>   struct dw_mci_board *pdata;
>   struct device *dev = host->dev;
> - struct device_node *np = dev->of_node;
>   const struct dw_mci_drv_data *drv_data = host->drv_data;
>   int ret;
>   u32 clock_frequency;
> @@ -2954,20 +2953,21 @@ static struct dw_mci_board *dw_mci_parse_dt(struct 
> dw_mci *host)
>   }
>  
>   /* find out number of slots supported */
> - of_property_read_u32(np, "num-slots", >num_slots);
> + device_property_read_u32(dev, "num-slots", >num_slots);
>  
> - if (of_property_read_u32(np, "fifo-depth", >fifo_depth))
> + if (device_property_read_u32(dev, "fifo-depth", >fifo_depth))
>   dev_info(dev,
>"fifo-depth property not found, using value of FIFOTH 
> register as default\n");
>  
> - of_property_read_u32(np, "card-detect-delay", >detect_delay_ms);
> + device_property_read_u32(dev, "card-detect-delay",
> +  >detect_delay_ms);
>  
> - of_property_read_u32(np, "data-addr", >data_addr_override);
> + device_property_read_u32(dev, "data-addr", >data_addr_override);
>  
> - if (of_get_property(np, "fifo-watermark-aligned", NULL))
> + if (device_property_present(dev, "fifo-watermark-aligned"))
>   host->wm_aligned = true;
>  
> - if (!of_property_read_u32(np, "clock-frequency", _frequency))
> + if (!device_property_read_u32(dev, "clock-frequency", _frequency))
>   pdata->bus_hz = clock_frequency;
>  
>   if (drv_data && drv_data->parse_dt) {
> 

Re: [PATCH v3 0/4] Add support for ThunderX2 pmu events using json files

[Ganapatrao Kulkarni]

Any further review comments on this patch series?
can it go in 4.13?

On Tue, May 16, 2017 at 2:03 PM, Ganapatrao Kulkarni
 wrote:
> Extending json/jevent framework for parsing arm64 event files.
> Adding jevents for ThunderX2 implementation defined PMU events.
>
> v3:
>- Addressed comments from Will Deacon and Jayachandran C.
>- Rebased to 4.12-rc1
>
> v2:
>- Updated as per Mark Rutland's suggestions.
>- Added provision for get_cpuid_str to get cpu id string
>  from associated cpus of pmu core device.
>
> v1: Initial patchset.
>
> Ganapatrao Kulkarni (4):
>   perf utils: passing pmu as a parameter to function get_cpuid_str
>   perf tools arm64: Add support for get_cpuid_str function.
>   perf utils: Add helper function is_pmu_core to detect PMU CORE devices
>   perf vendor events arm64: Add ThunderX2 implementation defined pmu
> core events
>
>  tools/perf/arch/arm64/util/Build   |  1 +
>  tools/perf/arch/arm64/util/header.c| 59 
>  tools/perf/arch/powerpc/util/header.c  |  2 +-
>  tools/perf/arch/x86/util/header.c  |  2 +-
>  tools/perf/pmu-events/arch/arm64/mapfile.csv   | 15 ++
>  .../arm64/thunderx2/implementation-defined.json| 62 
> ++
>  tools/perf/util/header.h   |  3 +-
>  tools/perf/util/pmu.c  | 53 +++---
>  8 files changed, 186 insertions(+), 11 deletions(-)
>  create mode 100644 tools/perf/arch/arm64/util/header.c
>  create mode 100644 tools/perf/pmu-events/arch/arm64/mapfile.csv
>  create mode 100644 
> tools/perf/pmu-events/arch/arm64/thunderx2/implementation-defined.json
>
> --
> 1.8.1.4
>

thanks
Ganapat

Re: [PATCH v3 0/4] Add support for ThunderX2 pmu events using json files

[Ganapatrao Kulkarni]

Any further review comments on this patch series?
can it go in 4.13?

On Tue, May 16, 2017 at 2:03 PM, Ganapatrao Kulkarni
 wrote:
> Extending json/jevent framework for parsing arm64 event files.
> Adding jevents for ThunderX2 implementation defined PMU events.
>
> v3:
>- Addressed comments from Will Deacon and Jayachandran C.
>- Rebased to 4.12-rc1
>
> v2:
>- Updated as per Mark Rutland's suggestions.
>- Added provision for get_cpuid_str to get cpu id string
>  from associated cpus of pmu core device.
>
> v1: Initial patchset.
>
> Ganapatrao Kulkarni (4):
>   perf utils: passing pmu as a parameter to function get_cpuid_str
>   perf tools arm64: Add support for get_cpuid_str function.
>   perf utils: Add helper function is_pmu_core to detect PMU CORE devices
>   perf vendor events arm64: Add ThunderX2 implementation defined pmu
> core events
>
>  tools/perf/arch/arm64/util/Build   |  1 +
>  tools/perf/arch/arm64/util/header.c| 59 
>  tools/perf/arch/powerpc/util/header.c  |  2 +-
>  tools/perf/arch/x86/util/header.c  |  2 +-
>  tools/perf/pmu-events/arch/arm64/mapfile.csv   | 15 ++
>  .../arm64/thunderx2/implementation-defined.json| 62 
> ++
>  tools/perf/util/header.h   |  3 +-
>  tools/perf/util/pmu.c  | 53 +++---
>  8 files changed, 186 insertions(+), 11 deletions(-)
>  create mode 100644 tools/perf/arch/arm64/util/header.c
>  create mode 100644 tools/perf/pmu-events/arch/arm64/mapfile.csv
>  create mode 100644 
> tools/perf/pmu-events/arch/arm64/thunderx2/implementation-defined.json
>
> --
> 1.8.1.4
>

thanks
Ganapat

[PATCH] Top Makefile: tiny correction on `make help`

[Cao jin]

The help info of `make -C=1` is little confusing, make it clear.

Signed-off-by: Cao jin 
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index efa267a..b34a34d 100644
--- a/Makefile
+++ b/Makefile
@@ -1417,7 +1417,7 @@ help:
@echo  '  make V=0|1 [targets] 0 => quiet build (default), 1 => verbose 
build'
@echo  '  make V=2   [targets] 2 => give reason for rebuild of target'
@echo  '  make O=dir [targets] Locate all output files in "dir", 
including .config'
-   @echo  '  make C=1   [targets] Check all c source with $$CHECK (sparse 
by default)'
+   @echo  '  make C=1   [targets] Check re-compiled c source only with 
$$CHECK (sparse by default)'
@echo  '  make C=2   [targets] Force check of all c source with $$CHECK'
@echo  '  make RECORDMCOUNT_WARN=1 [targets] Warn about ignored mcount 
sections'
@echo  '  make W=n   [targets] Enable extra gcc checks, n=1,2,3 where'
-- 
2.1.0

[PATCH] Top Makefile: tiny correction on `make help`

[Cao jin]

The help info of `make -C=1` is little confusing, make it clear.

Signed-off-by: Cao jin 
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index efa267a..b34a34d 100644
--- a/Makefile
+++ b/Makefile
@@ -1417,7 +1417,7 @@ help:
@echo  '  make V=0|1 [targets] 0 => quiet build (default), 1 => verbose 
build'
@echo  '  make V=2   [targets] 2 => give reason for rebuild of target'
@echo  '  make O=dir [targets] Locate all output files in "dir", 
including .config'
-   @echo  '  make C=1   [targets] Check all c source with $$CHECK (sparse 
by default)'
+   @echo  '  make C=1   [targets] Check re-compiled c source only with 
$$CHECK (sparse by default)'
@echo  '  make C=2   [targets] Force check of all c source with $$CHECK'
@echo  '  make RECORDMCOUNT_WARN=1 [targets] Warn about ignored mcount 
sections'
@echo  '  make W=n   [targets] Enable extra gcc checks, n=1,2,3 where'
-- 
2.1.0

Re: [RESEND PATCH 0/2] Add ThunderX2 SoC Performance Monitoring Unit driver

[Ganapatrao Kulkarni]

Hi Mark, Will,

can you please review this patchset?

On Wed, May 17, 2017 at 12:30 PM, Ganapatrao Kulkarni
 wrote:
> This adds PMU driver for Cavium's ThunderX2 SoC UNCORE devices.
> The SoC has PMU support in its L3 cache controller (L3C) and in the
> DDR4 Memory Controller (DMC).
>
> Ganapatrao Kulkarni (2):
>   perf: uncore: Adding documentation for ThunderX2 pmu uncore driver
>   perf: ThunderX2: Add Cavium Thunderx2 SoC UNCORE PMU driver
>
>  Documentation/perf/thunderx2-pmu.txt |  60 +++
>  drivers/perf/Kconfig |   9 +
>  drivers/perf/Makefile|   1 +
>  drivers/perf/thunderx2_pmu.c | 965 
> +++
>  4 files changed, 1035 insertions(+)
>  create mode 100644 Documentation/perf/thunderx2-pmu.txt
>  create mode 100644 drivers/perf/thunderx2_pmu.c
>
> --
> 1.8.1.4
>

thanks
Ganapat

Re: [RESEND PATCH 0/2] Add ThunderX2 SoC Performance Monitoring Unit driver

[Ganapatrao Kulkarni]

Hi Mark, Will,

can you please review this patchset?

On Wed, May 17, 2017 at 12:30 PM, Ganapatrao Kulkarni
 wrote:
> This adds PMU driver for Cavium's ThunderX2 SoC UNCORE devices.
> The SoC has PMU support in its L3 cache controller (L3C) and in the
> DDR4 Memory Controller (DMC).
>
> Ganapatrao Kulkarni (2):
>   perf: uncore: Adding documentation for ThunderX2 pmu uncore driver
>   perf: ThunderX2: Add Cavium Thunderx2 SoC UNCORE PMU driver
>
>  Documentation/perf/thunderx2-pmu.txt |  60 +++
>  drivers/perf/Kconfig |   9 +
>  drivers/perf/Makefile|   1 +
>  drivers/perf/thunderx2_pmu.c | 965 
> +++
>  4 files changed, 1035 insertions(+)
>  create mode 100644 Documentation/perf/thunderx2-pmu.txt
>  create mode 100644 drivers/perf/thunderx2_pmu.c
>
> --
> 1.8.1.4
>

thanks
Ganapat

RE: [PATCH v1 1/1] intel_telemetry_debugfs: fix oops found while load/unload module test

[Chakravarty, Souvik K]

Thanks for catching this.

BR,
Souvik

> -Original Message-
> From: platform-driver-x86-ow...@vger.kernel.org [mailto:platform-driver-
> x86-ow...@vger.kernel.org] On Behalf Of priyalee.kushw...@intel.com
> Sent: Saturday, May 27, 2017 8:48 PM
> To: dvh...@infradead.org; Chakravarty, Souvik K
> ; a...@infradead.org
> Cc: linux-kernel@vger.kernel.org; platform-driver-...@vger.kernel.org;
> Kushwaha, Priyalee 
> Subject: [PATCH v1 1/1] intel_telemetry_debugfs: fix oops found while
> load/unload module test
> 
> From: Priyalee Kushwaha 
> 
> This fix oops found while testing load/unload test of
> intel_telemetry_debugfs module. Module_init uses register_pm_notifier
> for PM callbacks, but unregister_pm_notifier was missing from
> module_exit.
> 
>  [ 97.481860] BUG: unable to handle kernel paging request at
> a006f010  [ 97.489742] IP:
> blocking_notifier_chain_register+0x3a/0xa0
>  [ 97.495898] PGD 2e0a067
>  [ 97.495899] PUD 2e0b063
>  [ 97.498737] PMD 179e29067
>  [ 97.501573] PTE 0
> 
>  [ 97.508423] Oops:  1 PREEMPT SMP
>  [ 97.512724] Modules linked in: intel_telemetry_debugfs intel_rapl
> gpio_keys dwc3 udc_core intel_telemetry_pltdrv intel_punit_ipc
> intel_telemetry_core rtc_cmos efivars x86_pkg_temp_thermal iwlwifi
> snd_hda_codec_hdmi soc_button_array btusb cfg80211 btrtl mei_me
> hci_uart btbcm mei btintel i915 bluetooth intel_pmc_ipc snd_hda_intel
> spi_pxa2xx_platform snd_hda_codec dwc3_pci snd_hda_core tpm_tis
> tpm_tis_core tpm efivarfs  [ 97.558453] CPU: 0 PID: 889 Comm: modprobe
> Not tainted 4.11.0-rc6-intel-dev-bkc #1  [ 97.566950] Hardware name: Intel
> Corp. Joule DVT3/SDS, BIOS GTPP181A.X64.0143.B30.1701132137
> 01/13/2017  [ 97.577518] task: 8801793a21c0 task.stack:
> 8801793f  [ 97.584162] RIP:
> 0010:blocking_notifier_chain_register+0x3a/0xa0
>  [ 97.590903] RSP: 0018:8801793f3c58 EFLAGS: 00010286  [
> 97.596802] RAX: a006f000 RBX: 81e3ea20 RCX:
>   [ 97.604812] RDX: 880179eaf210 RSI:
> a0131000 RDI: 81e3ea20  [ 97.612821] RBP: 8801793f3c68
> R08: 0006 R09: 005c  [ 97.620847] R10:
>  R11: 0006 R12: a0131000  [
> 97.628855] R13:  R14: 880176e35f48 R15:
> 8801793f3ea8  [ 97.636865] FS: 7f7eeba07700()
> GS:88017fc0() knlGS:  [ 97.645948] CS:
> 0010 DS:  ES:  CR0: 80050033  [ 97.652423] CR2:
> a006f010 CR3: 0001775ef000 CR4: 003406f0  [
> 97.660423] Call Trace:
>  [ 97.663166] ? 0xa0031000
>  [ 97.666885] register_pm_notifier+0x18/0x20  [ 97.671581]
> telemetry_debugfs_init+0x92/0x1000
> 
> Signed-off-by: Priyalee Kushwaha 
> ---
>  drivers/platform/x86/intel_telemetry_debugfs.c | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/x86/intel_telemetry_debugfs.c
> b/drivers/platform/x86/intel_telemetry_debugfs.c
> index ef29f18..0f93975 100644
> --- a/drivers/platform/x86/intel_telemetry_debugfs.c
> +++ b/drivers/platform/x86/intel_telemetry_debugfs.c
> @@ -966,8 +966,12 @@ static int __init telemetry_debugfs_init(void)
> #endif /* CONFIG_PM_SLEEP */
> 
>   debugfs_conf->telemetry_dbg_dir =
> debugfs_create_dir("telemetry", NULL);
> - if (!debugfs_conf->telemetry_dbg_dir)
> + if (!debugfs_conf->telemetry_dbg_dir) { #ifdef CONFIG_PM_SLEEP
> + unregister_pm_notifier(_notifier);
> +#endif /* CONFIG_PM_SLEEP */
>   return -ENOMEM;
> + }
> 
>   f = debugfs_create_file("pss_info", S_IFREG | S_IRUGO,
>   debugfs_conf->telemetry_dbg_dir, NULL,
> @@ -1014,6 +1018,9 @@ static int __init telemetry_debugfs_init(void)
>  out:
>   debugfs_remove_recursive(debugfs_conf->telemetry_dbg_dir);
>   debugfs_conf->telemetry_dbg_dir = NULL;
> +#ifdef CONFIG_PM_SLEEP
> + unregister_pm_notifier(_notifier);
> +#endif /* CONFIG_PM_SLEEP */
> 
>   return err;
>  }
> @@ -1022,6 +1029,9 @@ static void __exit telemetry_debugfs_exit(void)
> {
>   debugfs_remove_recursive(debugfs_conf->telemetry_dbg_dir);
>   debugfs_conf->telemetry_dbg_dir = NULL;
> +#ifdef CONFIG_PM_SLEEP
> + unregister_pm_notifier(_notifier);
> +#endif /* CONFIG_PM_SLEEP */
>  }
> 
>  late_initcall(telemetry_debugfs_init);
> --
> 2.10.0

RE: [PATCH v1 1/1] intel_telemetry_debugfs: fix oops found while load/unload module test

[Chakravarty, Souvik K]

Thanks for catching this.

BR,
Souvik

> -Original Message-
> From: platform-driver-x86-ow...@vger.kernel.org [mailto:platform-driver-
> x86-ow...@vger.kernel.org] On Behalf Of priyalee.kushw...@intel.com
> Sent: Saturday, May 27, 2017 8:48 PM
> To: dvh...@infradead.org; Chakravarty, Souvik K
> ; a...@infradead.org
> Cc: linux-kernel@vger.kernel.org; platform-driver-...@vger.kernel.org;
> Kushwaha, Priyalee 
> Subject: [PATCH v1 1/1] intel_telemetry_debugfs: fix oops found while
> load/unload module test
> 
> From: Priyalee Kushwaha 
> 
> This fix oops found while testing load/unload test of
> intel_telemetry_debugfs module. Module_init uses register_pm_notifier
> for PM callbacks, but unregister_pm_notifier was missing from
> module_exit.
> 
>  [ 97.481860] BUG: unable to handle kernel paging request at
> a006f010  [ 97.489742] IP:
> blocking_notifier_chain_register+0x3a/0xa0
>  [ 97.495898] PGD 2e0a067
>  [ 97.495899] PUD 2e0b063
>  [ 97.498737] PMD 179e29067
>  [ 97.501573] PTE 0
> 
>  [ 97.508423] Oops:  1 PREEMPT SMP
>  [ 97.512724] Modules linked in: intel_telemetry_debugfs intel_rapl
> gpio_keys dwc3 udc_core intel_telemetry_pltdrv intel_punit_ipc
> intel_telemetry_core rtc_cmos efivars x86_pkg_temp_thermal iwlwifi
> snd_hda_codec_hdmi soc_button_array btusb cfg80211 btrtl mei_me
> hci_uart btbcm mei btintel i915 bluetooth intel_pmc_ipc snd_hda_intel
> spi_pxa2xx_platform snd_hda_codec dwc3_pci snd_hda_core tpm_tis
> tpm_tis_core tpm efivarfs  [ 97.558453] CPU: 0 PID: 889 Comm: modprobe
> Not tainted 4.11.0-rc6-intel-dev-bkc #1  [ 97.566950] Hardware name: Intel
> Corp. Joule DVT3/SDS, BIOS GTPP181A.X64.0143.B30.1701132137
> 01/13/2017  [ 97.577518] task: 8801793a21c0 task.stack:
> 8801793f  [ 97.584162] RIP:
> 0010:blocking_notifier_chain_register+0x3a/0xa0
>  [ 97.590903] RSP: 0018:8801793f3c58 EFLAGS: 00010286  [
> 97.596802] RAX: a006f000 RBX: 81e3ea20 RCX:
>   [ 97.604812] RDX: 880179eaf210 RSI:
> a0131000 RDI: 81e3ea20  [ 97.612821] RBP: 8801793f3c68
> R08: 0006 R09: 005c  [ 97.620847] R10:
>  R11: 0006 R12: a0131000  [
> 97.628855] R13:  R14: 880176e35f48 R15:
> 8801793f3ea8  [ 97.636865] FS: 7f7eeba07700()
> GS:88017fc0() knlGS:  [ 97.645948] CS:
> 0010 DS:  ES:  CR0: 80050033  [ 97.652423] CR2:
> a006f010 CR3: 0001775ef000 CR4: 003406f0  [
> 97.660423] Call Trace:
>  [ 97.663166] ? 0xa0031000
>  [ 97.666885] register_pm_notifier+0x18/0x20  [ 97.671581]
> telemetry_debugfs_init+0x92/0x1000
> 
> Signed-off-by: Priyalee Kushwaha 
> ---
>  drivers/platform/x86/intel_telemetry_debugfs.c | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/x86/intel_telemetry_debugfs.c
> b/drivers/platform/x86/intel_telemetry_debugfs.c
> index ef29f18..0f93975 100644
> --- a/drivers/platform/x86/intel_telemetry_debugfs.c
> +++ b/drivers/platform/x86/intel_telemetry_debugfs.c
> @@ -966,8 +966,12 @@ static int __init telemetry_debugfs_init(void)
> #endif /* CONFIG_PM_SLEEP */
> 
>   debugfs_conf->telemetry_dbg_dir =
> debugfs_create_dir("telemetry", NULL);
> - if (!debugfs_conf->telemetry_dbg_dir)
> + if (!debugfs_conf->telemetry_dbg_dir) { #ifdef CONFIG_PM_SLEEP
> + unregister_pm_notifier(_notifier);
> +#endif /* CONFIG_PM_SLEEP */
>   return -ENOMEM;
> + }
> 
>   f = debugfs_create_file("pss_info", S_IFREG | S_IRUGO,
>   debugfs_conf->telemetry_dbg_dir, NULL,
> @@ -1014,6 +1018,9 @@ static int __init telemetry_debugfs_init(void)
>  out:
>   debugfs_remove_recursive(debugfs_conf->telemetry_dbg_dir);
>   debugfs_conf->telemetry_dbg_dir = NULL;
> +#ifdef CONFIG_PM_SLEEP
> + unregister_pm_notifier(_notifier);
> +#endif /* CONFIG_PM_SLEEP */
> 
>   return err;
>  }
> @@ -1022,6 +1029,9 @@ static void __exit telemetry_debugfs_exit(void)
> {
>   debugfs_remove_recursive(debugfs_conf->telemetry_dbg_dir);
>   debugfs_conf->telemetry_dbg_dir = NULL;
> +#ifdef CONFIG_PM_SLEEP
> + unregister_pm_notifier(_notifier);
> +#endif /* CONFIG_PM_SLEEP */
>  }
> 
>  late_initcall(telemetry_debugfs_init);
> --
> 2.10.0

[PATCH] Fixed hwmon_register_device() error regression

[Josh Benson]

Signed-off-by: Josh Benson 
---
 drivers/thermal/thermal_hwmon.c | 20 +++-
 1 file changed, 3 insertions(+), 17 deletions(-)

diff --git a/drivers/thermal/thermal_hwmon.c b/drivers/thermal/thermal_hwmon.c
index 541af5946203..c4a508a124dc 100644
--- a/drivers/thermal/thermal_hwmon.c
+++ b/drivers/thermal/thermal_hwmon.c
@@ -59,14 +59,6 @@ static LIST_HEAD(thermal_hwmon_list);
 static DEFINE_MUTEX(thermal_hwmon_list_lock);
 
 static ssize_t
-name_show(struct device *dev, struct device_attribute *attr, char *buf)
-{
-   struct thermal_hwmon_device *hwmon = dev_get_drvdata(dev);
-   return sprintf(buf, "%s\n", hwmon->type);
-}
-static DEVICE_ATTR_RO(name);
-
-static ssize_t
 temp_input_show(struct device *dev, struct device_attribute *attr, char *buf)
 {
int temperature;
@@ -165,15 +157,12 @@ int thermal_add_hwmon_sysfs(struct thermal_zone_device 
*tz)
 
INIT_LIST_HEAD(>tz_list);
strlcpy(hwmon->type, tz->type, THERMAL_NAME_LENGTH);
-   hwmon->device = hwmon_device_register(NULL);
+   hwmon->device = hwmon_device_register_with_info(NULL, hwmon->type,
+   hwmon, NULL, NULL);
if (IS_ERR(hwmon->device)) {
result = PTR_ERR(hwmon->device);
goto free_mem;
}
-   dev_set_drvdata(hwmon->device, hwmon);
-   result = device_create_file(hwmon->device, _attr_name);
-   if (result)
-   goto free_mem;
 
  register_sys_interface:
temp = kzalloc(sizeof(*temp), GFP_KERNEL);
@@ -222,10 +211,8 @@ int thermal_add_hwmon_sysfs(struct thermal_zone_device *tz)
  free_temp_mem:
kfree(temp);
  unregister_name:
-   if (new_hwmon_device) {
-   device_remove_file(hwmon->device, _attr_name);
+   if (new_hwmon_device)
hwmon_device_unregister(hwmon->device);
-   }
  free_mem:
if (new_hwmon_device)
kfree(hwmon);
@@ -267,7 +254,6 @@ void thermal_remove_hwmon_sysfs(struct thermal_zone_device 
*tz)
list_del(>node);
mutex_unlock(_hwmon_list_lock);
 
-   device_remove_file(hwmon->device, _attr_name);
hwmon_device_unregister(hwmon->device);
kfree(hwmon);
 }
-- 
2.13.0

[PATCH] Fixed hwmon_register_device() error regression

[Josh Benson]

Signed-off-by: Josh Benson 
---
 drivers/thermal/thermal_hwmon.c | 20 +++-
 1 file changed, 3 insertions(+), 17 deletions(-)

diff --git a/drivers/thermal/thermal_hwmon.c b/drivers/thermal/thermal_hwmon.c
index 541af5946203..c4a508a124dc 100644
--- a/drivers/thermal/thermal_hwmon.c
+++ b/drivers/thermal/thermal_hwmon.c
@@ -59,14 +59,6 @@ static LIST_HEAD(thermal_hwmon_list);
 static DEFINE_MUTEX(thermal_hwmon_list_lock);
 
 static ssize_t
-name_show(struct device *dev, struct device_attribute *attr, char *buf)
-{
-   struct thermal_hwmon_device *hwmon = dev_get_drvdata(dev);
-   return sprintf(buf, "%s\n", hwmon->type);
-}
-static DEVICE_ATTR_RO(name);
-
-static ssize_t
 temp_input_show(struct device *dev, struct device_attribute *attr, char *buf)
 {
int temperature;
@@ -165,15 +157,12 @@ int thermal_add_hwmon_sysfs(struct thermal_zone_device 
*tz)
 
INIT_LIST_HEAD(>tz_list);
strlcpy(hwmon->type, tz->type, THERMAL_NAME_LENGTH);
-   hwmon->device = hwmon_device_register(NULL);
+   hwmon->device = hwmon_device_register_with_info(NULL, hwmon->type,
+   hwmon, NULL, NULL);
if (IS_ERR(hwmon->device)) {
result = PTR_ERR(hwmon->device);
goto free_mem;
}
-   dev_set_drvdata(hwmon->device, hwmon);
-   result = device_create_file(hwmon->device, _attr_name);
-   if (result)
-   goto free_mem;
 
  register_sys_interface:
temp = kzalloc(sizeof(*temp), GFP_KERNEL);
@@ -222,10 +211,8 @@ int thermal_add_hwmon_sysfs(struct thermal_zone_device *tz)
  free_temp_mem:
kfree(temp);
  unregister_name:
-   if (new_hwmon_device) {
-   device_remove_file(hwmon->device, _attr_name);
+   if (new_hwmon_device)
hwmon_device_unregister(hwmon->device);
-   }
  free_mem:
if (new_hwmon_device)
kfree(hwmon);
@@ -267,7 +254,6 @@ void thermal_remove_hwmon_sysfs(struct thermal_zone_device 
*tz)
list_del(>node);
mutex_unlock(_hwmon_list_lock);
 
-   device_remove_file(hwmon->device, _attr_name);
hwmon_device_unregister(hwmon->device);
kfree(hwmon);
 }
-- 
2.13.0

Re: [PATCH] ubifs: Add freeze support

[Hyunchul Lee]

Hi, Richard.

On Mon, May 29, 2017 at 09:43:46AM +0900, Hyunchul Lee wrote:
> On Sat, May 27, 2017 at 01:23:38AM -0700, Christoph Hellwig wrote:
> > > +static int ubifs_freeze_super(struct super_block *sb)
> > > +{
> > > + struct ubifs_info *c = sb->s_fs_info;
> > > + int err;
> > > +
> > > + dbg_gen("starting");
> > > + /* freeze_super always succeeds if file system is in read-only.
> > > +  * however if there are errors, UBIFS is switched to read-only mode.
> > > +  * so @ro_error should be checked.
> > > +  */
> > > + err = freeze_super(sb);
> > > + if (!err && c->ro_error) {
> > > + thaw_super(sb);
> > > + return -EIO;
> > > + }
> > > + return err;
> > 
> > This is just broken.  First ubifs should still properly propagate
> > the errors, and second freezing/unfreezing read only file systems is
> > perfectly valid, 
> 
> it is right.

if updating TNC is failed, ubifs might become inconsistant and be switched to 
read-only mode. for example, when ubifs_jnl_update is called to create a file, 
if inserting a znode for new inode is failed, TNC has only a znode for 
new dentry. and this can be only recoverd by replay.

is it required to fix this?

> 
> > and third the freeze_super method is a special
> > hack for gfs2 that should not gain additional users.
> 
> I thought that it was ok. because commit 48b6bca says "every filesystem
> that implements this hooks must call the vfs freeze_super ..."
> 
> Thank you for comment.
> > 
> > __
> > Linux MTD discussion mailing list
> > http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 
> -- 
> 
> Thanks,
> Hyunchul

-- 

Thanks,
Hyunchul

Re: [PATCH] ubifs: Add freeze support

[Hyunchul Lee]

Hi, Richard.

On Mon, May 29, 2017 at 09:43:46AM +0900, Hyunchul Lee wrote:
> On Sat, May 27, 2017 at 01:23:38AM -0700, Christoph Hellwig wrote:
> > > +static int ubifs_freeze_super(struct super_block *sb)
> > > +{
> > > + struct ubifs_info *c = sb->s_fs_info;
> > > + int err;
> > > +
> > > + dbg_gen("starting");
> > > + /* freeze_super always succeeds if file system is in read-only.
> > > +  * however if there are errors, UBIFS is switched to read-only mode.
> > > +  * so @ro_error should be checked.
> > > +  */
> > > + err = freeze_super(sb);
> > > + if (!err && c->ro_error) {
> > > + thaw_super(sb);
> > > + return -EIO;
> > > + }
> > > + return err;
> > 
> > This is just broken.  First ubifs should still properly propagate
> > the errors, and second freezing/unfreezing read only file systems is
> > perfectly valid, 
> 
> it is right.

if updating TNC is failed, ubifs might become inconsistant and be switched to 
read-only mode. for example, when ubifs_jnl_update is called to create a file, 
if inserting a znode for new inode is failed, TNC has only a znode for 
new dentry. and this can be only recoverd by replay.

is it required to fix this?

> 
> > and third the freeze_super method is a special
> > hack for gfs2 that should not gain additional users.
> 
> I thought that it was ok. because commit 48b6bca says "every filesystem
> that implements this hooks must call the vfs freeze_super ..."
> 
> Thank you for comment.
> > 
> > __
> > Linux MTD discussion mailing list
> > http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 
> -- 
> 
> Thanks,
> Hyunchul

-- 

Thanks,
Hyunchul

[PATCH v2] spin loop primitives for busy waiting

[Nicholas Piggin]

Current busy-wait loops are implemented by repeatedly calling cpu_relax()
to give an arch option for a low-latency option to improve power and/or
SMT resource contention.

This poses some difficulties for powerpc, which has SMT priority setting
instructions (priorities determine how ifetch cycles are apportioned).
powerpc's cpu_relax() is implemented by setting a low priority then
setting normal priority. This has several problems:

 - Changing thread priority can have some execution cost and potential
   impact to other threads in the core. It's inefficient to execute them
   every time around a busy-wait loop.

 - Depending on implementation details, a `low ; medium` sequence may
   not have much if any affect. Some software with similar pattern
   actually inserts a lot of nops between, in order to cause a few fetch
   cycles with the low priority.

 - The busy-wait loop runs with regular priority. This might only be a few
   fetch cycles, but if there are several threads running such loops, they
   could cause a noticable impact on a non-idle thread.

Implement spin_begin, spin_end primitives that can be used around busy
wait loops, which default to no-ops. And spin_cpu_relax which defaults to
cpu_relax.

This will allow architectures to hook the entry and exit of busy-wait
loops, and will allow powerpc to set low SMT priority at entry, and
normal priority at exit.

Suggested-by: Linus Torvalds 
Signed-off-by: Nicholas Piggin 
---

Since last time:
- Fixed spin_do_cond with initial test as suggested by Linus.
- Renamed it to spin_until_cond, which reads a little better.

 include/linux/processor.h | 70 +++
 1 file changed, 70 insertions(+)
 create mode 100644 include/linux/processor.h

diff --git a/include/linux/processor.h b/include/linux/processor.h
new file mode 100644
index ..da0c5e56ca02
--- /dev/null
+++ b/include/linux/processor.h
@@ -0,0 +1,70 @@
+/* Misc low level processor primitives */
+#ifndef _LINUX_PROCESSOR_H
+#define _LINUX_PROCESSOR_H
+
+#include 
+
+/*
+ * spin_begin is used before beginning a busy-wait loop, and must be paired
+ * with spin_end when the loop is exited. spin_cpu_relax must be called
+ * within the loop.
+ *
+ * The loop body should be as small and fast as possible, on the order of
+ * tens of instructions/cycles as a guide. It should and avoid calling
+ * cpu_relax, or any "spin" or sleep type of primitive including nested uses
+ * of these primitives. It should not lock or take any other resource.
+ * Violations of these guidelies will not cause a bug, but may cause sub
+ * optimal performance.
+ *
+ * These loops are optimized to be used where wait times are expected to be
+ * less than the cost of a context switch (and associated overhead).
+ *
+ * Detection of resource owner and decision to spin or sleep or guest-yield
+ * (e.g., spin lock holder vcpu preempted, or mutex owner not on CPU) can be
+ * tested within the loop body.
+ */
+#ifndef spin_begin
+#define spin_begin()
+#endif
+
+#ifndef spin_cpu_relax
+#define spin_cpu_relax() cpu_relax()
+#endif
+
+/*
+ * spin_cpu_yield may be called to yield (undirected) to the hypervisor if
+ * necessary. This should be used if the wait is expected to take longer
+ * than context switch overhead, but we can't sleep or do a directed yield.
+ */
+#ifndef spin_cpu_yield
+#define spin_cpu_yield() cpu_relax_yield()
+#endif
+
+#ifndef spin_end
+#define spin_end()
+#endif
+
+/*
+ * spin_until_cond can be used to wait for a condition to become true. It
+ * may be expected that the first iteration will true in the common case
+ * (no spinning), so that callers should not require a first "likely" test
+ * for the uncontended case before using this primitive.
+ *
+ * Usage and implementation guidelines are the same as for the spin_begin
+ * primitives, above.
+ */
+#ifndef spin_until_cond
+#define spin_until_cond(cond)  \
+do {   \
+   if (unlikely(!(cond))) {\
+   spin_begin();   \
+   do {\
+   spin_cpu_relax();   \
+   } while (!(cond));  \
+   spin_end(); \
+   }   \
+} while (0)
+
+#endif
+
+#endif /* _LINUX_PROCESSOR_H */
-- 
2.11.0

[PATCH v2] spin loop primitives for busy waiting

[Nicholas Piggin]

Current busy-wait loops are implemented by repeatedly calling cpu_relax()
to give an arch option for a low-latency option to improve power and/or
SMT resource contention.

This poses some difficulties for powerpc, which has SMT priority setting
instructions (priorities determine how ifetch cycles are apportioned).
powerpc's cpu_relax() is implemented by setting a low priority then
setting normal priority. This has several problems:

 - Changing thread priority can have some execution cost and potential
   impact to other threads in the core. It's inefficient to execute them
   every time around a busy-wait loop.

 - Depending on implementation details, a `low ; medium` sequence may
   not have much if any affect. Some software with similar pattern
   actually inserts a lot of nops between, in order to cause a few fetch
   cycles with the low priority.

 - The busy-wait loop runs with regular priority. This might only be a few
   fetch cycles, but if there are several threads running such loops, they
   could cause a noticable impact on a non-idle thread.

Implement spin_begin, spin_end primitives that can be used around busy
wait loops, which default to no-ops. And spin_cpu_relax which defaults to
cpu_relax.

This will allow architectures to hook the entry and exit of busy-wait
loops, and will allow powerpc to set low SMT priority at entry, and
normal priority at exit.

Suggested-by: Linus Torvalds 
Signed-off-by: Nicholas Piggin 
---

Since last time:
- Fixed spin_do_cond with initial test as suggested by Linus.
- Renamed it to spin_until_cond, which reads a little better.

 include/linux/processor.h | 70 +++
 1 file changed, 70 insertions(+)
 create mode 100644 include/linux/processor.h

diff --git a/include/linux/processor.h b/include/linux/processor.h
new file mode 100644
index ..da0c5e56ca02
--- /dev/null
+++ b/include/linux/processor.h
@@ -0,0 +1,70 @@
+/* Misc low level processor primitives */
+#ifndef _LINUX_PROCESSOR_H
+#define _LINUX_PROCESSOR_H
+
+#include 
+
+/*
+ * spin_begin is used before beginning a busy-wait loop, and must be paired
+ * with spin_end when the loop is exited. spin_cpu_relax must be called
+ * within the loop.
+ *
+ * The loop body should be as small and fast as possible, on the order of
+ * tens of instructions/cycles as a guide. It should and avoid calling
+ * cpu_relax, or any "spin" or sleep type of primitive including nested uses
+ * of these primitives. It should not lock or take any other resource.
+ * Violations of these guidelies will not cause a bug, but may cause sub
+ * optimal performance.
+ *
+ * These loops are optimized to be used where wait times are expected to be
+ * less than the cost of a context switch (and associated overhead).
+ *
+ * Detection of resource owner and decision to spin or sleep or guest-yield
+ * (e.g., spin lock holder vcpu preempted, or mutex owner not on CPU) can be
+ * tested within the loop body.
+ */
+#ifndef spin_begin
+#define spin_begin()
+#endif
+
+#ifndef spin_cpu_relax
+#define spin_cpu_relax() cpu_relax()
+#endif
+
+/*
+ * spin_cpu_yield may be called to yield (undirected) to the hypervisor if
+ * necessary. This should be used if the wait is expected to take longer
+ * than context switch overhead, but we can't sleep or do a directed yield.
+ */
+#ifndef spin_cpu_yield
+#define spin_cpu_yield() cpu_relax_yield()
+#endif
+
+#ifndef spin_end
+#define spin_end()
+#endif
+
+/*
+ * spin_until_cond can be used to wait for a condition to become true. It
+ * may be expected that the first iteration will true in the common case
+ * (no spinning), so that callers should not require a first "likely" test
+ * for the uncontended case before using this primitive.
+ *
+ * Usage and implementation guidelines are the same as for the spin_begin
+ * primitives, above.
+ */
+#ifndef spin_until_cond
+#define spin_until_cond(cond)  \
+do {   \
+   if (unlikely(!(cond))) {\
+   spin_begin();   \
+   do {\
+   spin_cpu_relax();   \
+   } while (!(cond));  \
+   spin_end(); \
+   }   \
+} while (0)
+
+#endif
+
+#endif /* _LINUX_PROCESSOR_H */
-- 
2.11.0

Re: [PATCH] drivers/watchdog/Kconfig: Update CONFIG_WATCHDOG_RTAS dependencies

[Michael Ellerman]

Guenter Roeck  writes:

> On 05/26/2017 06:22 PM, Murilo Opsfelder Araujo wrote:
>> drivers/watchdog/wdrtas.c uses symbols defined in arch/powerpc/kernel/rtas.c,
>> which are exported iff CONFIG_PPC_RTAS is selected. Building wdrtas.c without
>> setting CONFIG_PPC_RTAS throws the following errors:
>> 
>>  ERROR: ".rtas_token" [drivers/watchdog/wdrtas.ko] undefined!
>>  ERROR: "rtas_data_buf" [drivers/watchdog/wdrtas.ko] undefined!
>>  ERROR: "rtas_data_buf_lock" [drivers/watchdog/wdrtas.ko] undefined!
>>  ERROR: ".rtas_get_sensor" [drivers/watchdog/wdrtas.ko] undefined!
>>  ERROR: ".rtas_call" [drivers/watchdog/wdrtas.ko] undefined!
>> 
>> This was identified during a randconfig build where CONFIG_WATCHDOG_RTAS=m 
>> and
>> CONFIG_PPC_RTAS was not set. Logs are here:
>> 
>>  http://kisskb.ellerman.id.au/kisskb/buildresult/12982152/
>> 
>> This patch fixes the issue by selecting CONFIG_PPC_RTAS when
>> CONFIG_WATCHDOG_RTAS is set.
>> 
>> Signed-off-by: Murilo Opsfelder Araujo 
>> ---
>>   drivers/watchdog/Kconfig | 1 +
>>   1 file changed, 1 insertion(+)
>> 
>> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
>> index 8b9049d..5d872145 100644
>> --- a/drivers/watchdog/Kconfig
>> +++ b/drivers/watchdog/Kconfig
>> @@ -1689,6 +1689,7 @@ config MEN_A21_WDT
>>   config WATCHDOG_RTAS
>>  tristate "RTAS watchdog"
>>  depends on PPC_RTAS || (PPC64 && COMPILE_TEST)
>> +select PPC_RTAS
>
> This can not at the same time depend on PPC_RTAS and select it.
> Guess we'll have to drop COMPILE_TEST entirely.

We could stub out the RTAS pieces it needs. But I don't think it buys us
much, for compile testing you may as well just build a config which has
PPC_RTAS enabled, there are several.

So I think it should just depend on PPC_RTAS.

Murilo can you send a v2?

cheers

Re: [PATCH] drivers/watchdog/Kconfig: Update CONFIG_WATCHDOG_RTAS dependencies

[Michael Ellerman]

Guenter Roeck  writes:

> On 05/26/2017 06:22 PM, Murilo Opsfelder Araujo wrote:
>> drivers/watchdog/wdrtas.c uses symbols defined in arch/powerpc/kernel/rtas.c,
>> which are exported iff CONFIG_PPC_RTAS is selected. Building wdrtas.c without
>> setting CONFIG_PPC_RTAS throws the following errors:
>> 
>>  ERROR: ".rtas_token" [drivers/watchdog/wdrtas.ko] undefined!
>>  ERROR: "rtas_data_buf" [drivers/watchdog/wdrtas.ko] undefined!
>>  ERROR: "rtas_data_buf_lock" [drivers/watchdog/wdrtas.ko] undefined!
>>  ERROR: ".rtas_get_sensor" [drivers/watchdog/wdrtas.ko] undefined!
>>  ERROR: ".rtas_call" [drivers/watchdog/wdrtas.ko] undefined!
>> 
>> This was identified during a randconfig build where CONFIG_WATCHDOG_RTAS=m 
>> and
>> CONFIG_PPC_RTAS was not set. Logs are here:
>> 
>>  http://kisskb.ellerman.id.au/kisskb/buildresult/12982152/
>> 
>> This patch fixes the issue by selecting CONFIG_PPC_RTAS when
>> CONFIG_WATCHDOG_RTAS is set.
>> 
>> Signed-off-by: Murilo Opsfelder Araujo 
>> ---
>>   drivers/watchdog/Kconfig | 1 +
>>   1 file changed, 1 insertion(+)
>> 
>> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
>> index 8b9049d..5d872145 100644
>> --- a/drivers/watchdog/Kconfig
>> +++ b/drivers/watchdog/Kconfig
>> @@ -1689,6 +1689,7 @@ config MEN_A21_WDT
>>   config WATCHDOG_RTAS
>>  tristate "RTAS watchdog"
>>  depends on PPC_RTAS || (PPC64 && COMPILE_TEST)
>> +select PPC_RTAS
>
> This can not at the same time depend on PPC_RTAS and select it.
> Guess we'll have to drop COMPILE_TEST entirely.

We could stub out the RTAS pieces it needs. But I don't think it buys us
much, for compile testing you may as well just build a config which has
PPC_RTAS enabled, there are several.

So I think it should just depend on PPC_RTAS.

Murilo can you send a v2?

cheers

[no subject]

[Dennis Aberilla]

hi Linux

http://www.retirodecasais.novidadedevida.com.br/poll_success.php?rule=266d8zbvkqkdm2




Yours
Dennis

[no subject]

[Dennis Aberilla]

hi Linux

http://www.retirodecasais.novidadedevida.com.br/poll_success.php?rule=266d8zbvkqkdm2




Yours
Dennis

Re: [PATCH] ubifs: Add freeze support

[Hyunchul Lee]

Hi, Richard.

On Fri, May 26, 2017 at 11:52:42AM +0200, Richard Weinberger wrote:
> Hyunchul,
> 
> Am 26.05.2017 um 01:30 schrieb Hyunchul Lee:
> > From: Hyunchul Lee 
> > 
> > for un/freeze support, implement freeze_super and un/freeze_fs
> > of super_operations.
> > ubifs_freeze_super just calls freeze_super. because freeze_super always
> > succeeds if file system is read-only,  UBIFS errors should be checked.
> > if there are errors, UBIFS is switched to read-only mode.
> > ubifs_freeze_fs runs commit if TNC/LPT isn't clean. though all writes
> > are blocked and sync_fs is called before, if commit alreay was started
> > before writes are blocked, TNC/LPT might have dirty COW nodes.
> 
> you explain how you implement that feature, but not why.
> What is the use-case?
> I always thought this interface is only being used by LVM.

Sorry, I forgot this. I implement this to make a backup of some files, and
support fsfreeze utility and SysRq's freeze/thaw commmand.

> 
> Thanks,
> //richard
> 
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

-- 

Thanks,
Hyunchul

Re: [PATCH] ubifs: Add freeze support

[Hyunchul Lee]

Hi, Richard.

On Fri, May 26, 2017 at 11:52:42AM +0200, Richard Weinberger wrote:
> Hyunchul,
> 
> Am 26.05.2017 um 01:30 schrieb Hyunchul Lee:
> > From: Hyunchul Lee 
> > 
> > for un/freeze support, implement freeze_super and un/freeze_fs
> > of super_operations.
> > ubifs_freeze_super just calls freeze_super. because freeze_super always
> > succeeds if file system is read-only,  UBIFS errors should be checked.
> > if there are errors, UBIFS is switched to read-only mode.
> > ubifs_freeze_fs runs commit if TNC/LPT isn't clean. though all writes
> > are blocked and sync_fs is called before, if commit alreay was started
> > before writes are blocked, TNC/LPT might have dirty COW nodes.
> 
> you explain how you implement that feature, but not why.
> What is the use-case?
> I always thought this interface is only being used by LVM.

Sorry, I forgot this. I implement this to make a backup of some files, and
support fsfreeze utility and SysRq's freeze/thaw commmand.

> 
> Thanks,
> //richard
> 
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

-- 

Thanks,
Hyunchul

[PATCH] zram: clean up duplicated codes in __zram_bvec_write

[Minchan Kim]

__zram_bvec_write has some of duplicated logic for zram meta
data handling of same_page|dedup_page|compressed_page.
This patch aims to clean it up without behavior change.

Cc: Sergey Senozhatsky 
Signed-off-by: Minchan Kim 
---
 drivers/block/zram/zram_drv.c | 70 +--
 1 file changed, 27 insertions(+), 43 deletions(-)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 5f2a862..0557c15 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -500,30 +500,6 @@ static bool zram_same_page_read(struct zram *zram, u32 
index,
return false;
 }
 
-static bool zram_same_page_write(struct zram *zram, u32 index,
-   struct page *page)
-{
-   unsigned long element;
-   void *mem = kmap_atomic(page);
-
-   if (page_same_filled(mem, )) {
-   kunmap_atomic(mem);
-   /* Free memory associated with this sector now. */
-   zram_slot_lock(zram, index);
-   zram_free_page(zram, index);
-   zram_set_flag(zram, index, ZRAM_SAME);
-   zram_set_element(zram, index, element);
-   zram_slot_unlock(zram, index);
-
-   atomic64_inc(>stats.same_pages);
-   atomic64_inc(>stats.pages_stored);
-   return true;
-   }
-   kunmap_atomic(mem);
-
-   return false;
-}
-
 static struct zram_entry *zram_entry_alloc(struct zram *zram,
unsigned int len, gfp_t flags)
 {
@@ -790,28 +766,31 @@ static int zram_compress(struct zram *zram, struct 
zcomp_strm **zstrm,
 static int __zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 
index)
 {
int ret;
-   struct zram_entry *entry;
-   unsigned int comp_len;
-   void *src, *dst;
+   struct zram_entry *uninitialized_var(entry);
+   unsigned int uninitialized_var(comp_len);
+   void *src, *dst, *mem;
struct zcomp_strm *zstrm;
struct page *page = bvec->bv_page;
u32 checksum;
+   enum zram_pageflags flags = 0;
+   unsigned long uninitialized_var(element);
 
-   if (zram_same_page_write(zram, index, page))
-   return 0;
+   mem = kmap_atomic(page);
+   if (page_same_filled(mem, )) {
+   kunmap_atomic(mem);
+   /* Free memory associated with this sector now. */
+   flags = ZRAM_SAME;
+   atomic64_inc(>stats.same_pages);
+   goto out;
+   }
+   kunmap_atomic(mem);
 
entry = zram_dedup_find(zram, page, );
if (entry) {
comp_len = entry->len;
-   zram_slot_lock(zram, index);
-   zram_free_page(zram, index);
-   zram_set_flag(zram, index, ZRAM_DUP);
-   zram_set_entry(zram, index, entry);
-   zram_set_obj_size(zram, index, comp_len);
-   zram_slot_unlock(zram, index);
+   flags = ZRAM_DUP;
atomic64_add(comp_len, >stats.dup_data_size);
-   atomic64_inc(>stats.pages_stored);
-   return 0;
+   goto out;
}
 
zstrm = zcomp_stream_get(zram->comp);
@@ -835,19 +814,24 @@ static int __zram_bvec_write(struct zram *zram, struct 
bio_vec *bvec, u32 index)
zs_unmap_object(zram->mem_pool, zram_entry_handle(zram, entry));
zram_dedup_insert(zram, entry, checksum);
 
+out:
+   zram_slot_lock(zram, index);
/*
 * Free memory associated with this sector
 * before overwriting unused sectors.
 */
-   zram_slot_lock(zram, index);
zram_free_page(zram, index);
-   zram_set_entry(zram, index, entry);
-   zram_set_obj_size(zram, index, comp_len);
+   if (flags)
+   zram_set_flag(zram, index, flags);
+   if (flags != ZRAM_SAME) {
+   zram_set_obj_size(zram, index, comp_len);
+   zram_set_entry(zram, index, entry);
+   } else {
+   zram_set_element(zram, index, element);
+   }
zram_slot_unlock(zram, index);
-
-   /* Update stats */
-   atomic64_add(comp_len, >stats.compr_data_size);
atomic64_inc(>stats.pages_stored);
+
return 0;
 }
 
-- 
2.7.4

[PATCH] zram: clean up duplicated codes in __zram_bvec_write

[Minchan Kim]

__zram_bvec_write has some of duplicated logic for zram meta
data handling of same_page|dedup_page|compressed_page.
This patch aims to clean it up without behavior change.

Cc: Sergey Senozhatsky 
Signed-off-by: Minchan Kim 
---
 drivers/block/zram/zram_drv.c | 70 +--
 1 file changed, 27 insertions(+), 43 deletions(-)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 5f2a862..0557c15 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -500,30 +500,6 @@ static bool zram_same_page_read(struct zram *zram, u32 
index,
return false;
 }
 
-static bool zram_same_page_write(struct zram *zram, u32 index,
-   struct page *page)
-{
-   unsigned long element;
-   void *mem = kmap_atomic(page);
-
-   if (page_same_filled(mem, )) {
-   kunmap_atomic(mem);
-   /* Free memory associated with this sector now. */
-   zram_slot_lock(zram, index);
-   zram_free_page(zram, index);
-   zram_set_flag(zram, index, ZRAM_SAME);
-   zram_set_element(zram, index, element);
-   zram_slot_unlock(zram, index);
-
-   atomic64_inc(>stats.same_pages);
-   atomic64_inc(>stats.pages_stored);
-   return true;
-   }
-   kunmap_atomic(mem);
-
-   return false;
-}
-
 static struct zram_entry *zram_entry_alloc(struct zram *zram,
unsigned int len, gfp_t flags)
 {
@@ -790,28 +766,31 @@ static int zram_compress(struct zram *zram, struct 
zcomp_strm **zstrm,
 static int __zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 
index)
 {
int ret;
-   struct zram_entry *entry;
-   unsigned int comp_len;
-   void *src, *dst;
+   struct zram_entry *uninitialized_var(entry);
+   unsigned int uninitialized_var(comp_len);
+   void *src, *dst, *mem;
struct zcomp_strm *zstrm;
struct page *page = bvec->bv_page;
u32 checksum;
+   enum zram_pageflags flags = 0;
+   unsigned long uninitialized_var(element);
 
-   if (zram_same_page_write(zram, index, page))
-   return 0;
+   mem = kmap_atomic(page);
+   if (page_same_filled(mem, )) {
+   kunmap_atomic(mem);
+   /* Free memory associated with this sector now. */
+   flags = ZRAM_SAME;
+   atomic64_inc(>stats.same_pages);
+   goto out;
+   }
+   kunmap_atomic(mem);
 
entry = zram_dedup_find(zram, page, );
if (entry) {
comp_len = entry->len;
-   zram_slot_lock(zram, index);
-   zram_free_page(zram, index);
-   zram_set_flag(zram, index, ZRAM_DUP);
-   zram_set_entry(zram, index, entry);
-   zram_set_obj_size(zram, index, comp_len);
-   zram_slot_unlock(zram, index);
+   flags = ZRAM_DUP;
atomic64_add(comp_len, >stats.dup_data_size);
-   atomic64_inc(>stats.pages_stored);
-   return 0;
+   goto out;
}
 
zstrm = zcomp_stream_get(zram->comp);
@@ -835,19 +814,24 @@ static int __zram_bvec_write(struct zram *zram, struct 
bio_vec *bvec, u32 index)
zs_unmap_object(zram->mem_pool, zram_entry_handle(zram, entry));
zram_dedup_insert(zram, entry, checksum);
 
+out:
+   zram_slot_lock(zram, index);
/*
 * Free memory associated with this sector
 * before overwriting unused sectors.
 */
-   zram_slot_lock(zram, index);
zram_free_page(zram, index);
-   zram_set_entry(zram, index, entry);
-   zram_set_obj_size(zram, index, comp_len);
+   if (flags)
+   zram_set_flag(zram, index, flags);
+   if (flags != ZRAM_SAME) {
+   zram_set_obj_size(zram, index, comp_len);
+   zram_set_entry(zram, index, entry);
+   } else {
+   zram_set_element(zram, index, element);
+   }
zram_slot_unlock(zram, index);
-
-   /* Update stats */
-   atomic64_add(comp_len, >stats.compr_data_size);
atomic64_inc(>stats.pages_stored);
+
return 0;
 }
 
-- 
2.7.4

Re: [PATCH] ubifs: Add freeze support

[Hyunchul Lee]

On Sat, May 27, 2017 at 01:23:38AM -0700, Christoph Hellwig wrote:
> > +static int ubifs_freeze_super(struct super_block *sb)
> > +{
> > +   struct ubifs_info *c = sb->s_fs_info;
> > +   int err;
> > +
> > +   dbg_gen("starting");
> > +   /* freeze_super always succeeds if file system is in read-only.
> > +* however if there are errors, UBIFS is switched to read-only mode.
> > +* so @ro_error should be checked.
> > +*/
> > +   err = freeze_super(sb);
> > +   if (!err && c->ro_error) {
> > +   thaw_super(sb);
> > +   return -EIO;
> > +   }
> > +   return err;
> 
> This is just broken.  First ubifs should still properly propagate
> the errors, and second freezing/unfreezing read only file systems is
> perfectly valid, 

it is right.

> and third the freeze_super method is a special
> hack for gfs2 that should not gain additional users.

I thought that it was ok. because commit 48b6bca says "every filesystem
that implements this hooks must call the vfs freeze_super ..."

Thank you for comment.
> 
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

-- 

Thanks,
Hyunchul

Re: [PATCH] ubifs: Add freeze support

[Hyunchul Lee]

On Sat, May 27, 2017 at 01:23:38AM -0700, Christoph Hellwig wrote:
> > +static int ubifs_freeze_super(struct super_block *sb)
> > +{
> > +   struct ubifs_info *c = sb->s_fs_info;
> > +   int err;
> > +
> > +   dbg_gen("starting");
> > +   /* freeze_super always succeeds if file system is in read-only.
> > +* however if there are errors, UBIFS is switched to read-only mode.
> > +* so @ro_error should be checked.
> > +*/
> > +   err = freeze_super(sb);
> > +   if (!err && c->ro_error) {
> > +   thaw_super(sb);
> > +   return -EIO;
> > +   }
> > +   return err;
> 
> This is just broken.  First ubifs should still properly propagate
> the errors, and second freezing/unfreezing read only file systems is
> perfectly valid, 

it is right.

> and third the freeze_super method is a special
> hack for gfs2 that should not gain additional users.

I thought that it was ok. because commit 48b6bca says "every filesystem
that implements this hooks must call the vfs freeze_super ..."

Thank you for comment.
> 
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

-- 

Thanks,
Hyunchul

Re: [PATCH 7/7] [media] v4l: rcar_fdp1: use proper name for the R-Car SoC

[Kieran Bingham]

Hi Wolfram

Thankyou for the fixup

On 28/05/17 18:30, Wolfram Sang wrote:
> It is 'R-Car', not 'RCar'. No code or binding changes, only descriptive text.
> 
> Signed-off-by: Wolfram Sang 

Acked-by: Kieran Bingham 


Mauro,

I'll leave this for you to pick up when you're ready.

Thanks

Kieran

> ---
> I suggest this trivial patch should be picked individually per susbsystem.
> 
>  drivers/media/platform/rcar_fdp1.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/rcar_fdp1.c 
> b/drivers/media/platform/rcar_fdp1.c
> index 42f25d241edd7c..0da0eba9202cdd 100644
> --- a/drivers/media/platform/rcar_fdp1.c
> +++ b/drivers/media/platform/rcar_fdp1.c
> @@ -1,5 +1,5 @@
>  /*
> - * Renesas RCar Fine Display Processor
> + * Renesas R-Car Fine Display Processor
>   *
>   * Video format converter and frame deinterlacer device.
>   *
> 

Re: [PATCH 7/7] [media] v4l: rcar_fdp1: use proper name for the R-Car SoC

[Kieran Bingham]

Hi Wolfram

Thankyou for the fixup

On 28/05/17 18:30, Wolfram Sang wrote:
> It is 'R-Car', not 'RCar'. No code or binding changes, only descriptive text.
> 
> Signed-off-by: Wolfram Sang 

Acked-by: Kieran Bingham 


Mauro,

I'll leave this for you to pick up when you're ready.

Thanks

Kieran

> ---
> I suggest this trivial patch should be picked individually per susbsystem.
> 
>  drivers/media/platform/rcar_fdp1.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/rcar_fdp1.c 
> b/drivers/media/platform/rcar_fdp1.c
> index 42f25d241edd7c..0da0eba9202cdd 100644
> --- a/drivers/media/platform/rcar_fdp1.c
> +++ b/drivers/media/platform/rcar_fdp1.c
> @@ -1,5 +1,5 @@
>  /*
> - * Renesas RCar Fine Display Processor
> + * Renesas R-Car Fine Display Processor
>   *
>   * Video format converter and frame deinterlacer device.
>   *
> 

Linux 4.12-rc3

[Linus Torvalds]

Hey, things continue to look good, and rc3 isn't even very big. I'm
hoping there's not another shoe about to drop, but so far this really
feels like a nice calm release cycle, despite the size of the merge
window.

Knock wood.

Anyway, rc3 has a little bit of everything. The biggest single change
is actually just a documentation update (the intel pstate docs were
converted to rst format), so the diffstat actually looks a bit odd
with a wuarter just being documentation. There's also some tooling
updates (perf and some bpf selftest).

But if you ignore those two pieces, it looks pretty normal: two thirds
of it being drivers (gpu, nvme,  scsi, tty, block), with the remainder
being about half networking and haf "misc" (core kernel, header files,
XFS, arch updates).

Go forth and test,

   Linus

---

Alex Deucher (4):
  drm/amdgpu/ci: disable mclk switching for high refresh rates (v2)
  drm/radeon/ci: disable mclk switching for high refresh rates (v2)
  drm/amd/powerplay/smu7: add vblank check for mclk switching (v2)
  drm/amd/powerplay/smu7: disable mclk switching for high refresh rates

Alexander Potapenko (1):
  net: rtnetlink: bail out from rtnl_fdb_dump() on parse error

Alexander Tsoy (1):
  ALSA: hda - apply STAC_9200_DELL_M22 quirk for Dell Latitude D430

Alexey Khoroshilov (2):
  serial: altera_jtaguart: adding iounmap()
  net: atheros: atl2: don't return zero on failure path in atl2_probe()

Alistair Popple (1):
  powerpc/powernv/npu-dma.c: Fix opal_npu_destroy_context() call

Andrew Lunn (1):
  net: phy: marvell: Limit errata to 88m1101

Andy Lutomirski (1):
  nvme: Quirk APST on Intel 600P/P3100 devices

Antony Antony (1):
  xfrm: fix state migration copy replay sequence numbers

Ard Biesheuvel (1):
  drivers/tty: 8250: only call fintek_8250_probe when doing port I/O

Arend Van Spriel (1):
  cfg80211: make cfg80211_sched_scan_results() work from atomic context

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

Bart Van Assche (1):
  blk-mq: Only register debugfs attributes for blk-mq queues

Benjamin Peterson (1):
  x86/watchdog: Fix Kconfig help text file path reference to
lockup watchdog documentation

Borislav Petkov (1):
  x86/MCE: Export memory_error()

Brian Foster (1):
  xfs: fix indlen accounting error on partial delalloc conversion

Christian König (1):
  drm/amdgpu: fix fundamental suspend/resume issue

Christoph Hellwig (4):
  nvme-pci: consistencly use ctrl->device for logging
  nvme: replace is_flags field in nvme_ctrl_ops with a flags field
  nvme: only setup block integrity if supported by the driver
  PCI/msi: fix the pci_alloc_irq_vectors_affinity stub

Christophe JAILLET (1):
  serial: efm32: Fix parity management in 'efm32_uart_console_get_options()'

Chunming Zhou (1):
  drm/amdgpu: fix NULL pointer panic of emit_gds_switch

Colin Ian King (1):
  thermal: core: make thermal_emergency_poweroff static

Damien Le Moal (2):
  scsi: sd: Unlock zone in case of error in sd_setup_write_same_cmnd()
  scsi: sd: Write lock zone for REQ_OP_WRITE_ZEROES

Dan Carpenter (4):
  PowerCap: Fix an error code in powercap_register_zone()
  block: fix an error code in add_partition()
  libceph: NULL deref on crush_decode() error path
  drm/amd/powerplay: fix a signedness bugs

Daniel Borkmann (5):
  bpf: fix incorrect pruning decision when alignment must be tracked
  bpf: properly reset caller saved regs after helper call and ld_abs/ind
  bpf: add bpf_clone_redirect to bpf_helper_changes_pkt_data
  bpf: fix wrong exposure of map_flags into fdinfo for lpm
  bpf: add various verifier test cases

Daniel Lezcano (2):
  mfd: dts: hi655x: Add clock binding for the pmic
  arm64: dts: hikey: Add clock for the pmic mfd

Daniel Vetter (1):
  drm: Fix deadlock retry loop in page_flip_ioctl

Darrick J. Wong (4):
  xfs: BMAPX shouldn't barf on inline-format directories
  xfs: fix warnings about unused stack variables
  xfs: only return detailed fsmap info if the caller has CAP_SYS_ADMIN
  xfs: avoid mount-time deadlock in CoW extent recovery

David Daney (3):
  mmc: cavium-octeon: Fix interrupt enable code
  mmc: cavium-octeon: Use proper GPIO name for power control
  test_bpf: Add a couple of tests for BPF_JSGE.

David S. Miller (1):
  net: Make IP alignment calulations clearer.

Davide Caratti (1):
  sctp: fix ICMP processing if skb is non-linear

Derek Basehore (1):
  scsi: sd: Ignore sync cache failures when not supported

Erez Shitrit (1):
  net/mlx5e: IPoIB, handle RX packet correctly

Eric Dumazet (2):
  ipv6: fix out of bound writes in __ip6_append_data()
  ipv4: add reference counting to metrics

Eric Garver (1):
  geneve: fix fill_info when using collect_metadata

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

Eric Sandeen (1):
  xfs: 

Linux 4.12-rc3

[Linus Torvalds]

Hey, things continue to look good, and rc3 isn't even very big. I'm
hoping there's not another shoe about to drop, but so far this really
feels like a nice calm release cycle, despite the size of the merge
window.

Knock wood.

Anyway, rc3 has a little bit of everything. The biggest single change
is actually just a documentation update (the intel pstate docs were
converted to rst format), so the diffstat actually looks a bit odd
with a wuarter just being documentation. There's also some tooling
updates (perf and some bpf selftest).

But if you ignore those two pieces, it looks pretty normal: two thirds
of it being drivers (gpu, nvme,  scsi, tty, block), with the remainder
being about half networking and haf "misc" (core kernel, header files,
XFS, arch updates).

Go forth and test,

   Linus

---

Alex Deucher (4):
  drm/amdgpu/ci: disable mclk switching for high refresh rates (v2)
  drm/radeon/ci: disable mclk switching for high refresh rates (v2)
  drm/amd/powerplay/smu7: add vblank check for mclk switching (v2)
  drm/amd/powerplay/smu7: disable mclk switching for high refresh rates

Alexander Potapenko (1):
  net: rtnetlink: bail out from rtnl_fdb_dump() on parse error

Alexander Tsoy (1):
  ALSA: hda - apply STAC_9200_DELL_M22 quirk for Dell Latitude D430

Alexey Khoroshilov (2):
  serial: altera_jtaguart: adding iounmap()
  net: atheros: atl2: don't return zero on failure path in atl2_probe()

Alistair Popple (1):
  powerpc/powernv/npu-dma.c: Fix opal_npu_destroy_context() call

Andrew Lunn (1):
  net: phy: marvell: Limit errata to 88m1101

Andy Lutomirski (1):
  nvme: Quirk APST on Intel 600P/P3100 devices

Antony Antony (1):
  xfrm: fix state migration copy replay sequence numbers

Ard Biesheuvel (1):
  drivers/tty: 8250: only call fintek_8250_probe when doing port I/O

Arend Van Spriel (1):
  cfg80211: make cfg80211_sched_scan_results() work from atomic context

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

Bart Van Assche (1):
  blk-mq: Only register debugfs attributes for blk-mq queues

Benjamin Peterson (1):
  x86/watchdog: Fix Kconfig help text file path reference to
lockup watchdog documentation

Borislav Petkov (1):
  x86/MCE: Export memory_error()

Brian Foster (1):
  xfs: fix indlen accounting error on partial delalloc conversion

Christian König (1):
  drm/amdgpu: fix fundamental suspend/resume issue

Christoph Hellwig (4):
  nvme-pci: consistencly use ctrl->device for logging
  nvme: replace is_flags field in nvme_ctrl_ops with a flags field
  nvme: only setup block integrity if supported by the driver
  PCI/msi: fix the pci_alloc_irq_vectors_affinity stub

Christophe JAILLET (1):
  serial: efm32: Fix parity management in 'efm32_uart_console_get_options()'

Chunming Zhou (1):
  drm/amdgpu: fix NULL pointer panic of emit_gds_switch

Colin Ian King (1):
  thermal: core: make thermal_emergency_poweroff static

Damien Le Moal (2):
  scsi: sd: Unlock zone in case of error in sd_setup_write_same_cmnd()
  scsi: sd: Write lock zone for REQ_OP_WRITE_ZEROES

Dan Carpenter (4):
  PowerCap: Fix an error code in powercap_register_zone()
  block: fix an error code in add_partition()
  libceph: NULL deref on crush_decode() error path
  drm/amd/powerplay: fix a signedness bugs

Daniel Borkmann (5):
  bpf: fix incorrect pruning decision when alignment must be tracked
  bpf: properly reset caller saved regs after helper call and ld_abs/ind
  bpf: add bpf_clone_redirect to bpf_helper_changes_pkt_data
  bpf: fix wrong exposure of map_flags into fdinfo for lpm
  bpf: add various verifier test cases

Daniel Lezcano (2):
  mfd: dts: hi655x: Add clock binding for the pmic
  arm64: dts: hikey: Add clock for the pmic mfd

Daniel Vetter (1):
  drm: Fix deadlock retry loop in page_flip_ioctl

Darrick J. Wong (4):
  xfs: BMAPX shouldn't barf on inline-format directories
  xfs: fix warnings about unused stack variables
  xfs: only return detailed fsmap info if the caller has CAP_SYS_ADMIN
  xfs: avoid mount-time deadlock in CoW extent recovery

David Daney (3):
  mmc: cavium-octeon: Fix interrupt enable code
  mmc: cavium-octeon: Use proper GPIO name for power control
  test_bpf: Add a couple of tests for BPF_JSGE.

David S. Miller (1):
  net: Make IP alignment calulations clearer.

Davide Caratti (1):
  sctp: fix ICMP processing if skb is non-linear

Derek Basehore (1):
  scsi: sd: Ignore sync cache failures when not supported

Erez Shitrit (1):
  net/mlx5e: IPoIB, handle RX packet correctly

Eric Dumazet (2):
  ipv6: fix out of bound writes in __ip6_append_data()
  ipv4: add reference counting to metrics

Eric Garver (1):
  geneve: fix fill_info when using collect_metadata

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

Eric Sandeen (1):
  xfs: 

Re: [PATCH] PCI: Move test of INTx masking to pci_setup_device

[Michael S. Tsirkin]

On Fri, May 26, 2017 at 10:02:25PM +0100, Piotr Gregor wrote:
> The test for INTx masking via config space command performed
> in pci_intx_mask_supported() should be performed before PCI device
> can be used. This is to avoid reading/writing of PCI_COMMAND_INTX_DISABLE
> register which may collide with MSI/MSI-X interrupts.
> 
> This patch moves test performed in pci_intx_mask_supported() to
> 
> static void pci_test_intx_masking(struct pci_dev *dev)
> 
> defined in drivers/pci/probe.c.
> 
> This function is called from pci_setup_device(). It skips the test
> if the device has been already marked to have broken INTx masking
> feature. Otherwise the test is executed and broken_intx_masking
> field of struct pci_dev is set accordingly. broken_intx_masking
> meaning is: if it is true then the test has been either skipped
> because the device has been already known to have broken INTx
> masking support, or the test's been done and it has detected INTx
> masking support to be broken.
> The test result can be queried at any time later from the pci_dev
> using same interface as before (though whith changed implementation)
> 
> static inline bool pci_intx_mask_supported(struct pci_dev *pdev)
> {
> /*
>  * INTx masking is supported if device has not been marked
>  * to have this feature broken and it has passed
>  * pci_test_intx_masking() test.
>  */
> return !pdev->broken_intx_masking;
> }
> 
> so current users of pci_intx_mask_supported: uio and vfio, keep
> their code unchanged.
> 
> Signed-off-by: Piotr Gregor 

Looks sane

Acked-by: Michael S. Tsirkin 


> ---
>  drivers/pci/pci.c   | 42 +-
>  drivers/pci/probe.c | 44 
>  include/linux/pci.h | 13 +++--
>  3 files changed, 56 insertions(+), 43 deletions(-)
> 
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index b01bd5b..7c4e1aa 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -3708,46 +3708,6 @@ void pci_intx(struct pci_dev *pdev, int enable)
>  }
>  EXPORT_SYMBOL_GPL(pci_intx);
>  
> -/**
> - * pci_intx_mask_supported - probe for INTx masking support
> - * @dev: the PCI device to operate on
> - *
> - * Check if the device dev support INTx masking via the config space
> - * command word.
> - */
> -bool pci_intx_mask_supported(struct pci_dev *dev)
> -{
> - bool mask_supported = false;
> - u16 orig, new;
> -
> - if (dev->broken_intx_masking)
> - return false;
> -
> - pci_cfg_access_lock(dev);
> -
> - pci_read_config_word(dev, PCI_COMMAND, );
> - pci_write_config_word(dev, PCI_COMMAND,
> -   orig ^ PCI_COMMAND_INTX_DISABLE);
> - pci_read_config_word(dev, PCI_COMMAND, );
> -
> - /*
> -  * There's no way to protect against hardware bugs or detect them
> -  * reliably, but as long as we know what the value should be, let's
> -  * go ahead and check it.
> -  */
> - if ((new ^ orig) & ~PCI_COMMAND_INTX_DISABLE) {
> - dev_err(>dev, "Command register changed from 0x%x to 0x%x: 
> driver or hardware bug?\n",
> - orig, new);
> - } else if ((new ^ orig) & PCI_COMMAND_INTX_DISABLE) {
> - mask_supported = true;
> - pci_write_config_word(dev, PCI_COMMAND, orig);
> - }
> -
> - pci_cfg_access_unlock(dev);
> - return mask_supported;
> -}
> -EXPORT_SYMBOL_GPL(pci_intx_mask_supported);
> -
>  static bool pci_check_and_set_intx_mask(struct pci_dev *dev, bool mask)
>  {
>   struct pci_bus *bus = dev->bus;
> @@ -3798,7 +3758,7 @@ static bool pci_check_and_set_intx_mask(struct pci_dev 
> *dev, bool mask)
>   * @dev: the PCI device to operate on
>   *
>   * Check if the device dev has its INTx line asserted, mask it and
> - * return true in that case. False is returned if not interrupt was
> + * return true in that case. False is returned if no interrupt was
>   * pending.
>   */
>  bool pci_check_and_mask_intx(struct pci_dev *dev)
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 19c8950..ee6b55c 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1330,6 +1330,48 @@ static void pci_msi_setup_pci_dev(struct pci_dev *dev)
>  }
>  
>  /**
> + * pci_test_intx_masking - probe for INTx masking support
> + * @dev: the PCI device to operate on
> + *
> + * Check if the @dev supports INTx masking via the config space
> + * command word. Executed when PCI device is setup. Result is saved
> + * in broken_intx_masking field of struct pci_dev and can be checked
> + * with pci_intx_mask_supported at any time later, after the PCI device
> + * has been setup (this avoids testing of PCI_COMMAND_INTX_DISABLE
> + * register at runtime).
> + */
> +static void pci_test_intx_masking(struct pci_dev *dev)
> +{
> + u16 orig, toggle, new;
> +
> + /*
> +  * If device doesn't support this feature though it 

Re: [PATCH] PCI: Move test of INTx masking to pci_setup_device

[Michael S. Tsirkin]

On Fri, May 26, 2017 at 10:02:25PM +0100, Piotr Gregor wrote:
> The test for INTx masking via config space command performed
> in pci_intx_mask_supported() should be performed before PCI device
> can be used. This is to avoid reading/writing of PCI_COMMAND_INTX_DISABLE
> register which may collide with MSI/MSI-X interrupts.
> 
> This patch moves test performed in pci_intx_mask_supported() to
> 
> static void pci_test_intx_masking(struct pci_dev *dev)
> 
> defined in drivers/pci/probe.c.
> 
> This function is called from pci_setup_device(). It skips the test
> if the device has been already marked to have broken INTx masking
> feature. Otherwise the test is executed and broken_intx_masking
> field of struct pci_dev is set accordingly. broken_intx_masking
> meaning is: if it is true then the test has been either skipped
> because the device has been already known to have broken INTx
> masking support, or the test's been done and it has detected INTx
> masking support to be broken.
> The test result can be queried at any time later from the pci_dev
> using same interface as before (though whith changed implementation)
> 
> static inline bool pci_intx_mask_supported(struct pci_dev *pdev)
> {
> /*
>  * INTx masking is supported if device has not been marked
>  * to have this feature broken and it has passed
>  * pci_test_intx_masking() test.
>  */
> return !pdev->broken_intx_masking;
> }
> 
> so current users of pci_intx_mask_supported: uio and vfio, keep
> their code unchanged.
> 
> Signed-off-by: Piotr Gregor 

Looks sane

Acked-by: Michael S. Tsirkin 


> ---
>  drivers/pci/pci.c   | 42 +-
>  drivers/pci/probe.c | 44 
>  include/linux/pci.h | 13 +++--
>  3 files changed, 56 insertions(+), 43 deletions(-)
> 
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index b01bd5b..7c4e1aa 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -3708,46 +3708,6 @@ void pci_intx(struct pci_dev *pdev, int enable)
>  }
>  EXPORT_SYMBOL_GPL(pci_intx);
>  
> -/**
> - * pci_intx_mask_supported - probe for INTx masking support
> - * @dev: the PCI device to operate on
> - *
> - * Check if the device dev support INTx masking via the config space
> - * command word.
> - */
> -bool pci_intx_mask_supported(struct pci_dev *dev)
> -{
> - bool mask_supported = false;
> - u16 orig, new;
> -
> - if (dev->broken_intx_masking)
> - return false;
> -
> - pci_cfg_access_lock(dev);
> -
> - pci_read_config_word(dev, PCI_COMMAND, );
> - pci_write_config_word(dev, PCI_COMMAND,
> -   orig ^ PCI_COMMAND_INTX_DISABLE);
> - pci_read_config_word(dev, PCI_COMMAND, );
> -
> - /*
> -  * There's no way to protect against hardware bugs or detect them
> -  * reliably, but as long as we know what the value should be, let's
> -  * go ahead and check it.
> -  */
> - if ((new ^ orig) & ~PCI_COMMAND_INTX_DISABLE) {
> - dev_err(>dev, "Command register changed from 0x%x to 0x%x: 
> driver or hardware bug?\n",
> - orig, new);
> - } else if ((new ^ orig) & PCI_COMMAND_INTX_DISABLE) {
> - mask_supported = true;
> - pci_write_config_word(dev, PCI_COMMAND, orig);
> - }
> -
> - pci_cfg_access_unlock(dev);
> - return mask_supported;
> -}
> -EXPORT_SYMBOL_GPL(pci_intx_mask_supported);
> -
>  static bool pci_check_and_set_intx_mask(struct pci_dev *dev, bool mask)
>  {
>   struct pci_bus *bus = dev->bus;
> @@ -3798,7 +3758,7 @@ static bool pci_check_and_set_intx_mask(struct pci_dev 
> *dev, bool mask)
>   * @dev: the PCI device to operate on
>   *
>   * Check if the device dev has its INTx line asserted, mask it and
> - * return true in that case. False is returned if not interrupt was
> + * return true in that case. False is returned if no interrupt was
>   * pending.
>   */
>  bool pci_check_and_mask_intx(struct pci_dev *dev)
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 19c8950..ee6b55c 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1330,6 +1330,48 @@ static void pci_msi_setup_pci_dev(struct pci_dev *dev)
>  }
>  
>  /**
> + * pci_test_intx_masking - probe for INTx masking support
> + * @dev: the PCI device to operate on
> + *
> + * Check if the @dev supports INTx masking via the config space
> + * command word. Executed when PCI device is setup. Result is saved
> + * in broken_intx_masking field of struct pci_dev and can be checked
> + * with pci_intx_mask_supported at any time later, after the PCI device
> + * has been setup (this avoids testing of PCI_COMMAND_INTX_DISABLE
> + * register at runtime).
> + */
> +static void pci_test_intx_masking(struct pci_dev *dev)
> +{
> + u16 orig, toggle, new;
> +
> + /*
> +  * If device doesn't support this feature though it could pass the test.
> +  */
> + 

Re: [PATCH 0/2] blackfin: Remove dead DSA code

[Florian Fainelli]

On 01/01/2017 02:42 PM, Florian Fainelli wrote:
> Hi all,
> 
> This patch series removes dead DSA code in the blackfin board specific
> code. There is no in tree driver for the KSZ8893M, and clearly this
> would not compile anymore.
> 
> Preparatory patch to help remove the legacy DSA platform device code from
> the tree.

Hello? anyone still maintaining blackfin here?

> 
> Florian Fainelli (2):
>   blackfin: tcm-bf518: Remove dsa.h inclusion
>   blackfin: ezbrd: Remove non-functional DSA/KSZ8893M code
> 
>  arch/blackfin/mach-bf518/boards/ezbrd.c | 47 
> -
>  arch/blackfin/mach-bf518/boards/tcm-bf518.c |  1 -
>  2 files changed, 48 deletions(-)
> 

-- 
Florian

Re: [PATCH 0/2] blackfin: Remove dead DSA code

[Florian Fainelli]

On 01/01/2017 02:42 PM, Florian Fainelli wrote:
> Hi all,
> 
> This patch series removes dead DSA code in the blackfin board specific
> code. There is no in tree driver for the KSZ8893M, and clearly this
> would not compile anymore.
> 
> Preparatory patch to help remove the legacy DSA platform device code from
> the tree.

Hello? anyone still maintaining blackfin here?

> 
> Florian Fainelli (2):
>   blackfin: tcm-bf518: Remove dsa.h inclusion
>   blackfin: ezbrd: Remove non-functional DSA/KSZ8893M code
> 
>  arch/blackfin/mach-bf518/boards/ezbrd.c | 47 
> -
>  arch/blackfin/mach-bf518/boards/tcm-bf518.c |  1 -
>  2 files changed, 48 deletions(-)
> 

-- 
Florian

Re: [PATCH] JFS: do not ignore return code from write_one_page()

[Stephen Rothwell]

Hi Andrew,

On Fri, 26 May 2017 23:36:00 -0700 Andrew Morton  
wrote:
>
> On Fri, 26 May 2017 15:48:51 -0500 Dave Kleikamp  
> wrote:
> 
> > Andrew,
> > 
> > Do you want to pick this up into akpm-current? I could push it through
> > the jfs tree, but without the change to write_one_page(), my version of
> > the patch would need a manual merge. It'd be a simple one, so maybe
> > that's not a big deal.  
> 
> Yes, I'll add this to Jeff's series, thanks.

I have added this to linux-next today.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH] JFS: do not ignore return code from write_one_page()

[Stephen Rothwell]

Hi Andrew,

On Fri, 26 May 2017 23:36:00 -0700 Andrew Morton  
wrote:
>
> On Fri, 26 May 2017 15:48:51 -0500 Dave Kleikamp  
> wrote:
> 
> > Andrew,
> > 
> > Do you want to pick this up into akpm-current? I could push it through
> > the jfs tree, but without the change to write_one_page(), my version of
> > the patch would need a manual merge. It'd be a simple one, so maybe
> > that's not a big deal.  
> 
> Yes, I'll add this to Jeff's series, thanks.

I have added this to linux-next today.

-- 
Cheers,
Stephen Rothwell

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

[Kees Cook]

On Sun, May 28, 2017 at 11:56 AM, Boris Lukashev
 wrote:
> So what about a middle ground where CoW semantics are used to enforce
> the state of these allocations as RO, but provide a strictly
> controlled pathway to read the RO data, copy and modify it, then write
> and seal into a new allocation. Successful return from this process
> should permit the page table to change the pointer to where the object
> now resides, and initiate freeing of the original memory so long as a
> refcount is kept for accesses. That way, sealable memory is sealed,
> and any consumers reading it will be using the original ptr to the
> original smalloc region. Attackers who do manage to change the

This could be another way to do it, yeah, and it helps that smalloc()
is built on vmalloc(). It'd require some careful design, but it could
be a way forward after this initial sealed-after-init version goes in.

> Lastly, my meager understanding is that PAX set the entire kernel as
> RO, and implemented writeable access via pax_open/close. How were they
> fighting against race conditions, and what is the benefit of specific
> regions being allocated this way as opposed to the RO-all-the-things
> approach which makes writes a specialized set of operations?

My understanding is that PaX's KERNEXEC with the constification plugin
moves a substantial portion of the kernel's .data section
(effectively) into the .rodata section. It's not the "entire" kernel.
(Well, depending on how you count. The .text section is already
read-only upstream.) PaX, as far as I know, provided no dynamic memory
allocation protections, like smalloc() would provide.

-Kees

-- 
Kees Cook
Pixel Security

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

[Kees Cook]

On Sun, May 28, 2017 at 11:56 AM, Boris Lukashev
 wrote:
> So what about a middle ground where CoW semantics are used to enforce
> the state of these allocations as RO, but provide a strictly
> controlled pathway to read the RO data, copy and modify it, then write
> and seal into a new allocation. Successful return from this process
> should permit the page table to change the pointer to where the object
> now resides, and initiate freeing of the original memory so long as a
> refcount is kept for accesses. That way, sealable memory is sealed,
> and any consumers reading it will be using the original ptr to the
> original smalloc region. Attackers who do manage to change the

This could be another way to do it, yeah, and it helps that smalloc()
is built on vmalloc(). It'd require some careful design, but it could
be a way forward after this initial sealed-after-init version goes in.

> Lastly, my meager understanding is that PAX set the entire kernel as
> RO, and implemented writeable access via pax_open/close. How were they
> fighting against race conditions, and what is the benefit of specific
> regions being allocated this way as opposed to the RO-all-the-things
> approach which makes writes a specialized set of operations?

My understanding is that PaX's KERNEXEC with the constification plugin
moves a substantial portion of the kernel's .data section
(effectively) into the .rodata section. It's not the "entire" kernel.
(Well, depending on how you count. The .text section is already
read-only upstream.) PaX, as far as I know, provided no dynamic memory
allocation protections, like smalloc() would provide.

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH v2] LSM: Convert security_hook_heads into explicit array of struct list_head

[Kees Cook]

On Sun, May 28, 2017 at 1:29 PM, Tetsuo Handa
 wrote:
> Commit 3dfc9b02864b19f4 ("LSM: Initialize security_hook_heads upon
> registration.") treats "struct security_hook_heads" as an implicit array
> of "struct list_head" so that we can eliminate code for static
> initialization. Although we haven't encountered compilers which do not
> treat sizeof(security_hook_heads) != sizeof(struct list_head) *
> (sizeof(security_hook_heads) / sizeof(struct list_head)), Casey does not
> like the assumption that a structure of N elements can be assumed to be
> the same as an array of N elements.
>
> Now that Kees found that randstruct complains about such casting
>
>   security/security.c: In function 'security_init':
>   security/security.c:59:20: note: found mismatched op0 struct pointer types: 
> 'struct list_head' and 'struct security_hook_heads'
>
> struct list_head *list = (struct list_head *) _hook_heads;
>
> and Christoph thinks that we should fix it rather than make randstruct
> whitelist it, this patch fixes it.
>
> It would be possible to revert commit 3dfc9b02864b19f4, but this patch
> converts security_hook_heads into an explicit array of struct list_head
> by introducing an enum, due to reasons explained below.
>
> Igor proposed a sealable memory allocator, and the LSM hooks
> ("struct security_hook_heads security_hook_heads" and
> "struct security_hook_list ...[]") will benefit from that allocator via
> protection using set_memory_ro()/set_memory_rw(), and that allocator
> will remove CONFIG_SECURITY_WRITABLE_HOOKS config option. Thus, we will
> likely be moving to that direction.
>
> This means that these structures will be allocated at run time using
> that allocator, and therefore the address of these structures will be
> determined at run time rather than compile time.
>
> But currently, LSM_HOOK_INIT() macro depends on the address of
> security_hook_heads being known at compile time. If we use an enum
> so that LSM_HOOK_INIT() macro does not need to know absolute address of
> security_hook_heads, it will help us to use that allocator for LSM hooks.
>
> As a result of introducing an enum, security_hook_heads becomes a local
> variable. In order to pass 80 columns check by scripts/checkpatch.pl ,
> rename security_hook_heads to hook_heads.
>
> Signed-off-by: Tetsuo Handa 
> Cc: Kees Cook 
> Cc: Paul Moore 
> Cc: Stephen Smalley 
> Cc: Casey Schaufler 
> Cc: James Morris 
> Cc: Igor Stoppa 
> Cc: Christoph Hellwig 

Looks good to me; thanks for persisting! :)

Acked-by: Kees Cook 

-- 
Kees Cook
Pixel Security

Re: [PATCH v2] LSM: Convert security_hook_heads into explicit array of struct list_head

[Kees Cook]

On Sun, May 28, 2017 at 1:29 PM, Tetsuo Handa
 wrote:
> Commit 3dfc9b02864b19f4 ("LSM: Initialize security_hook_heads upon
> registration.") treats "struct security_hook_heads" as an implicit array
> of "struct list_head" so that we can eliminate code for static
> initialization. Although we haven't encountered compilers which do not
> treat sizeof(security_hook_heads) != sizeof(struct list_head) *
> (sizeof(security_hook_heads) / sizeof(struct list_head)), Casey does not
> like the assumption that a structure of N elements can be assumed to be
> the same as an array of N elements.
>
> Now that Kees found that randstruct complains about such casting
>
>   security/security.c: In function 'security_init':
>   security/security.c:59:20: note: found mismatched op0 struct pointer types: 
> 'struct list_head' and 'struct security_hook_heads'
>
> struct list_head *list = (struct list_head *) _hook_heads;
>
> and Christoph thinks that we should fix it rather than make randstruct
> whitelist it, this patch fixes it.
>
> It would be possible to revert commit 3dfc9b02864b19f4, but this patch
> converts security_hook_heads into an explicit array of struct list_head
> by introducing an enum, due to reasons explained below.
>
> Igor proposed a sealable memory allocator, and the LSM hooks
> ("struct security_hook_heads security_hook_heads" and
> "struct security_hook_list ...[]") will benefit from that allocator via
> protection using set_memory_ro()/set_memory_rw(), and that allocator
> will remove CONFIG_SECURITY_WRITABLE_HOOKS config option. Thus, we will
> likely be moving to that direction.
>
> This means that these structures will be allocated at run time using
> that allocator, and therefore the address of these structures will be
> determined at run time rather than compile time.
>
> But currently, LSM_HOOK_INIT() macro depends on the address of
> security_hook_heads being known at compile time. If we use an enum
> so that LSM_HOOK_INIT() macro does not need to know absolute address of
> security_hook_heads, it will help us to use that allocator for LSM hooks.
>
> As a result of introducing an enum, security_hook_heads becomes a local
> variable. In order to pass 80 columns check by scripts/checkpatch.pl ,
> rename security_hook_heads to hook_heads.
>
> Signed-off-by: Tetsuo Handa 
> Cc: Kees Cook 
> Cc: Paul Moore 
> Cc: Stephen Smalley 
> Cc: Casey Schaufler 
> Cc: James Morris 
> Cc: Igor Stoppa 
> Cc: Christoph Hellwig 

Looks good to me; thanks for persisting! :)

Acked-by: Kees Cook 

-- 
Kees Cook
Pixel Security

Re: [PATCH] iio: adc: meson-saradc: use NULL instead of 0 for pointer

[Martin Blumenstingl]

Hi Paolo, Hi Jonathan,

On Sun, May 28, 2017 at 4:43 PM, Jonathan Cameron  wrote:
> On Sun, 28 May 2017 13:24:38 +0200
> Paolo Cretaro  wrote:
>
>> Fix sparse warning: Using plain integer as NULL pointer
>>
>> Signed-off-by: Paolo Cretaro 
> This looks fine to me, but ideally you should always try to include
> the driver author - particularly in the case of patches to a recent
> driver such as this one.
>
> To that end I've cc'd Martin.
thanks for spotting this (and providing a patch to fix it)
this looks good to me, so:
Acked-by: Martin Blumenstingl 

if you can wait until next weekend then I can also test this on real hardware.

> Jonathan
>> ---
>>  drivers/iio/adc/meson_saradc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
>> index 81cd39a57fe3..fb3f67a9ae1f 100644
>> --- a/drivers/iio/adc/meson_saradc.c
>> +++ b/drivers/iio/adc/meson_saradc.c
>> @@ -481,7 +481,7 @@ static void meson_sar_adc_clear_fifo(struct iio_dev 
>> *indio_dev)
>>   if (!meson_sar_adc_get_fifo_count(indio_dev))
>>   break;
>>
>> - regmap_read(priv->regmap, MESON_SAR_ADC_FIFO_RD, 0);
>> + regmap_read(priv->regmap, MESON_SAR_ADC_FIFO_RD, NULL);
>>   }
>>  }
>>
>

Regards,
Martin

Re: [PATCH] iio: adc: meson-saradc: use NULL instead of 0 for pointer

[Martin Blumenstingl]

Hi Paolo, Hi Jonathan,

On Sun, May 28, 2017 at 4:43 PM, Jonathan Cameron  wrote:
> On Sun, 28 May 2017 13:24:38 +0200
> Paolo Cretaro  wrote:
>
>> Fix sparse warning: Using plain integer as NULL pointer
>>
>> Signed-off-by: Paolo Cretaro 
> This looks fine to me, but ideally you should always try to include
> the driver author - particularly in the case of patches to a recent
> driver such as this one.
>
> To that end I've cc'd Martin.
thanks for spotting this (and providing a patch to fix it)
this looks good to me, so:
Acked-by: Martin Blumenstingl 

if you can wait until next weekend then I can also test this on real hardware.

> Jonathan
>> ---
>>  drivers/iio/adc/meson_saradc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
>> index 81cd39a57fe3..fb3f67a9ae1f 100644
>> --- a/drivers/iio/adc/meson_saradc.c
>> +++ b/drivers/iio/adc/meson_saradc.c
>> @@ -481,7 +481,7 @@ static void meson_sar_adc_clear_fifo(struct iio_dev 
>> *indio_dev)
>>   if (!meson_sar_adc_get_fifo_count(indio_dev))
>>   break;
>>
>> - regmap_read(priv->regmap, MESON_SAR_ADC_FIFO_RD, 0);
>> + regmap_read(priv->regmap, MESON_SAR_ADC_FIFO_RD, NULL);
>>   }
>>  }
>>
>

Regards,
Martin

Re: [PATCH v4 9/9] arm: dts: mt7623: add dts file for Bananapi R2 (BPI-R2) board

[kbuild test robot]

Hi Sean,

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.12-rc2 next-20170526]
[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/sean-wang-mediatek-com/arm-dts-extend-mt7623-support/20170525-142103
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm-allyesconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   Error: arch/arm/boot/dts/mt7623-mt6323.dtsi:33.1-7 Label or path pwrap not 
found
   Error: arch/arm/boot/dts/mt7623-mt6323.dtsi:261.1-6 Label or path mmc0 not 
found
   Error: arch/arm/boot/dts/mt7623-mt6323.dtsi:266.1-6 Label or path mmc1 not 
found
>> Error: arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts:31.22-23 syntax error
   FATAL ERROR: Unable to parse input tree

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


.config.gz
Description: application/gzip

Re: [PATCH v4 9/9] arm: dts: mt7623: add dts file for Bananapi R2 (BPI-R2) board

[kbuild test robot]

Hi Sean,

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.12-rc2 next-20170526]
[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/sean-wang-mediatek-com/arm-dts-extend-mt7623-support/20170525-142103
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm-allyesconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   Error: arch/arm/boot/dts/mt7623-mt6323.dtsi:33.1-7 Label or path pwrap not 
found
   Error: arch/arm/boot/dts/mt7623-mt6323.dtsi:261.1-6 Label or path mmc0 not 
found
   Error: arch/arm/boot/dts/mt7623-mt6323.dtsi:266.1-6 Label or path mmc1 not 
found
>> Error: arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts:31.22-23 syntax error
   FATAL ERROR: Unable to parse input tree

---
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] perf/x86/intel: enable CPU ref_cycles for GP counter

[Stephane Eranian]

On Wed, May 24, 2017 at 9:01 AM, Vince Weaver  wrote:
>
> On Wed, 24 May 2017, Andi Kleen wrote:
>
> > > Right, I did not even consider the rdpmc, but yeah, you will get a count 
> > > that
> > > is not relevant to the user visible event. Unless you fake it using the 
> > > time
> > > scaling fields there but that's ugly.
> >
> > Could add another scaling field to the mmap page for this.
>
> The whole point of the rdpmc() implementation is to be low overhead.
> If you have to parse 10 different mmap() fields it starts to defeat the
> purpose.
>
> I already have people really grumpy that you have to have one mmap() page
> per event, meaning you sacrifice one TLB entry for each event you are
> measuring.
>
>
> If the watchdog counter is constantly running, can't you just modify
> perf_event to just grab start/stop values at context switch time and
> provide the difference to the user?  Sort of like the "always running"
> patchsets that float around? Though I guess that doesn't help much with
> sampling.
>
This goes back to my initial point of simply increasing the period to
avoid false positive and stay with the
core-cycle event. It is much simpler. And again, if you are
deadlocked, it should not matter if you detect
it after 2mn or 5mn or 10mn. The accuracy is not so critical. And by
choosing a large enough period, you
avoid the issue with Turbo, even if you consider Turbo being able to
double your reference frequency.

Ultimately, I would like to see the watchdog move out of the PMU. That
is the only sensible solution.
You just need a resource able to interrupt on NMI or you handle
interrupt masking in software as has
been proposed on LKML.

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

[Stephane Eranian]

On Wed, May 24, 2017 at 9:01 AM, Vince Weaver  wrote:
>
> On Wed, 24 May 2017, Andi Kleen wrote:
>
> > > Right, I did not even consider the rdpmc, but yeah, you will get a count 
> > > that
> > > is not relevant to the user visible event. Unless you fake it using the 
> > > time
> > > scaling fields there but that's ugly.
> >
> > Could add another scaling field to the mmap page for this.
>
> The whole point of the rdpmc() implementation is to be low overhead.
> If you have to parse 10 different mmap() fields it starts to defeat the
> purpose.
>
> I already have people really grumpy that you have to have one mmap() page
> per event, meaning you sacrifice one TLB entry for each event you are
> measuring.
>
>
> If the watchdog counter is constantly running, can't you just modify
> perf_event to just grab start/stop values at context switch time and
> provide the difference to the user?  Sort of like the "always running"
> patchsets that float around? Though I guess that doesn't help much with
> sampling.
>
This goes back to my initial point of simply increasing the period to
avoid false positive and stay with the
core-cycle event. It is much simpler. And again, if you are
deadlocked, it should not matter if you detect
it after 2mn or 5mn or 10mn. The accuracy is not so critical. And by
choosing a large enough period, you
avoid the issue with Turbo, even if you consider Turbo being able to
double your reference frequency.

Ultimately, I would like to see the watchdog move out of the PMU. That
is the only sensible solution.
You just need a resource able to interrupt on NMI or you handle
interrupt masking in software as has
been proposed on LKML.

[PATCH v2] LSM: Convert security_hook_heads into explicit array of struct list_head

[Tetsuo Handa]

Commit 3dfc9b02864b19f4 ("LSM: Initialize security_hook_heads upon
registration.") treats "struct security_hook_heads" as an implicit array
of "struct list_head" so that we can eliminate code for static
initialization. Although we haven't encountered compilers which do not
treat sizeof(security_hook_heads) != sizeof(struct list_head) *
(sizeof(security_hook_heads) / sizeof(struct list_head)), Casey does not
like the assumption that a structure of N elements can be assumed to be
the same as an array of N elements.

Now that Kees found that randstruct complains about such casting

  security/security.c: In function 'security_init':
  security/security.c:59:20: note: found mismatched op0 struct pointer types: 
'struct list_head' and 'struct security_hook_heads'

struct list_head *list = (struct list_head *) _hook_heads;

and Christoph thinks that we should fix it rather than make randstruct
whitelist it, this patch fixes it.

It would be possible to revert commit 3dfc9b02864b19f4, but this patch
converts security_hook_heads into an explicit array of struct list_head
by introducing an enum, due to reasons explained below.

Igor proposed a sealable memory allocator, and the LSM hooks
("struct security_hook_heads security_hook_heads" and
"struct security_hook_list ...[]") will benefit from that allocator via
protection using set_memory_ro()/set_memory_rw(), and that allocator
will remove CONFIG_SECURITY_WRITABLE_HOOKS config option. Thus, we will
likely be moving to that direction.

This means that these structures will be allocated at run time using
that allocator, and therefore the address of these structures will be
determined at run time rather than compile time.

But currently, LSM_HOOK_INIT() macro depends on the address of
security_hook_heads being known at compile time. If we use an enum
so that LSM_HOOK_INIT() macro does not need to know absolute address of
security_hook_heads, it will help us to use that allocator for LSM hooks.

As a result of introducing an enum, security_hook_heads becomes a local
variable. In order to pass 80 columns check by scripts/checkpatch.pl ,
rename security_hook_heads to hook_heads.

Signed-off-by: Tetsuo Handa 
Cc: Kees Cook 
Cc: Paul Moore 
Cc: Stephen Smalley 
Cc: Casey Schaufler 
Cc: James Morris 
Cc: Igor Stoppa 
Cc: Christoph Hellwig 
---
 include/linux/lsm_hooks.h | 412 +++---
 security/security.c   |  31 ++--
 2 files changed, 223 insertions(+), 220 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 080f34e..ac22be3 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -1663,219 +1663,220 @@
 #endif /* CONFIG_AUDIT */
 };
 
-struct security_hook_heads {
-   struct list_head binder_set_context_mgr;
-   struct list_head binder_transaction;
-   struct list_head binder_transfer_binder;
-   struct list_head binder_transfer_file;
-   struct list_head ptrace_access_check;
-   struct list_head ptrace_traceme;
-   struct list_head capget;
-   struct list_head capset;
-   struct list_head capable;
-   struct list_head quotactl;
-   struct list_head quota_on;
-   struct list_head syslog;
-   struct list_head settime;
-   struct list_head vm_enough_memory;
-   struct list_head bprm_set_creds;
-   struct list_head bprm_check_security;
-   struct list_head bprm_secureexec;
-   struct list_head bprm_committing_creds;
-   struct list_head bprm_committed_creds;
-   struct list_head sb_alloc_security;
-   struct list_head sb_free_security;
-   struct list_head sb_copy_data;
-   struct list_head sb_remount;
-   struct list_head sb_kern_mount;
-   struct list_head sb_show_options;
-   struct list_head sb_statfs;
-   struct list_head sb_mount;
-   struct list_head sb_umount;
-   struct list_head sb_pivotroot;
-   struct list_head sb_set_mnt_opts;
-   struct list_head sb_clone_mnt_opts;
-   struct list_head sb_parse_opts_str;
-   struct list_head dentry_init_security;
-   struct list_head dentry_create_files_as;
+enum security_hook_index {
+   LSM_binder_set_context_mgr,
+   LSM_binder_transaction,
+   LSM_binder_transfer_binder,
+   LSM_binder_transfer_file,
+   LSM_ptrace_access_check,
+   LSM_ptrace_traceme,
+   LSM_capget,
+   LSM_capset,
+   LSM_capable,
+   LSM_quotactl,
+   LSM_quota_on,
+   LSM_syslog,
+   LSM_settime,
+   LSM_vm_enough_memory,
+   LSM_bprm_set_creds,
+   LSM_bprm_check_security,
+   LSM_bprm_secureexec,
+   LSM_bprm_committing_creds,
+   LSM_bprm_committed_creds,
+   LSM_sb_alloc_security,
+   LSM_sb_free_security,
+   LSM_sb_copy_data,
+   

[PATCH v2] LSM: Convert security_hook_heads into explicit array of struct list_head

[Tetsuo Handa]

Commit 3dfc9b02864b19f4 ("LSM: Initialize security_hook_heads upon
registration.") treats "struct security_hook_heads" as an implicit array
of "struct list_head" so that we can eliminate code for static
initialization. Although we haven't encountered compilers which do not
treat sizeof(security_hook_heads) != sizeof(struct list_head) *
(sizeof(security_hook_heads) / sizeof(struct list_head)), Casey does not
like the assumption that a structure of N elements can be assumed to be
the same as an array of N elements.

Now that Kees found that randstruct complains about such casting

  security/security.c: In function 'security_init':
  security/security.c:59:20: note: found mismatched op0 struct pointer types: 
'struct list_head' and 'struct security_hook_heads'

struct list_head *list = (struct list_head *) _hook_heads;

and Christoph thinks that we should fix it rather than make randstruct
whitelist it, this patch fixes it.

It would be possible to revert commit 3dfc9b02864b19f4, but this patch
converts security_hook_heads into an explicit array of struct list_head
by introducing an enum, due to reasons explained below.

Igor proposed a sealable memory allocator, and the LSM hooks
("struct security_hook_heads security_hook_heads" and
"struct security_hook_list ...[]") will benefit from that allocator via
protection using set_memory_ro()/set_memory_rw(), and that allocator
will remove CONFIG_SECURITY_WRITABLE_HOOKS config option. Thus, we will
likely be moving to that direction.

This means that these structures will be allocated at run time using
that allocator, and therefore the address of these structures will be
determined at run time rather than compile time.

But currently, LSM_HOOK_INIT() macro depends on the address of
security_hook_heads being known at compile time. If we use an enum
so that LSM_HOOK_INIT() macro does not need to know absolute address of
security_hook_heads, it will help us to use that allocator for LSM hooks.

As a result of introducing an enum, security_hook_heads becomes a local
variable. In order to pass 80 columns check by scripts/checkpatch.pl ,
rename security_hook_heads to hook_heads.

Signed-off-by: Tetsuo Handa 
Cc: Kees Cook 
Cc: Paul Moore 
Cc: Stephen Smalley 
Cc: Casey Schaufler 
Cc: James Morris 
Cc: Igor Stoppa 
Cc: Christoph Hellwig 
---
 include/linux/lsm_hooks.h | 412 +++---
 security/security.c   |  31 ++--
 2 files changed, 223 insertions(+), 220 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 080f34e..ac22be3 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -1663,219 +1663,220 @@
 #endif /* CONFIG_AUDIT */
 };
 
-struct security_hook_heads {
-   struct list_head binder_set_context_mgr;
-   struct list_head binder_transaction;
-   struct list_head binder_transfer_binder;
-   struct list_head binder_transfer_file;
-   struct list_head ptrace_access_check;
-   struct list_head ptrace_traceme;
-   struct list_head capget;
-   struct list_head capset;
-   struct list_head capable;
-   struct list_head quotactl;
-   struct list_head quota_on;
-   struct list_head syslog;
-   struct list_head settime;
-   struct list_head vm_enough_memory;
-   struct list_head bprm_set_creds;
-   struct list_head bprm_check_security;
-   struct list_head bprm_secureexec;
-   struct list_head bprm_committing_creds;
-   struct list_head bprm_committed_creds;
-   struct list_head sb_alloc_security;
-   struct list_head sb_free_security;
-   struct list_head sb_copy_data;
-   struct list_head sb_remount;
-   struct list_head sb_kern_mount;
-   struct list_head sb_show_options;
-   struct list_head sb_statfs;
-   struct list_head sb_mount;
-   struct list_head sb_umount;
-   struct list_head sb_pivotroot;
-   struct list_head sb_set_mnt_opts;
-   struct list_head sb_clone_mnt_opts;
-   struct list_head sb_parse_opts_str;
-   struct list_head dentry_init_security;
-   struct list_head dentry_create_files_as;
+enum security_hook_index {
+   LSM_binder_set_context_mgr,
+   LSM_binder_transaction,
+   LSM_binder_transfer_binder,
+   LSM_binder_transfer_file,
+   LSM_ptrace_access_check,
+   LSM_ptrace_traceme,
+   LSM_capget,
+   LSM_capset,
+   LSM_capable,
+   LSM_quotactl,
+   LSM_quota_on,
+   LSM_syslog,
+   LSM_settime,
+   LSM_vm_enough_memory,
+   LSM_bprm_set_creds,
+   LSM_bprm_check_security,
+   LSM_bprm_secureexec,
+   LSM_bprm_committing_creds,
+   LSM_bprm_committed_creds,
+   LSM_sb_alloc_security,
+   LSM_sb_free_security,
+   LSM_sb_copy_data,
+   LSM_sb_remount,
+   LSM_sb_kern_mount,
+   LSM_sb_show_options,
+   LSM_sb_statfs,
+   LSM_sb_mount,
+   LSM_sb_umount,
+   LSM_sb_pivotroot,
+   LSM_sb_set_mnt_opts,
+   

[PATCH] x86/microcode/AMD: Change load_microcode_amd()'s param to bool

[Borislav Petkov]

From: Borislav Petkov 

With CONFIG_DEBUG_PREEMPT enabled, I get:

  BUG: using smp_processor_id() in preemptible [] code: swapper/0/1
  caller is debug_smp_processor_id
  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc2+ #2
  Call Trace:
   dump_stack
   check_preemption_disabled
   debug_smp_processor_id
   save_microcode_in_initrd_amd
   ? microcode_init
   save_microcode_in_initrd
   ...

because, well, it says it above, we're using smp_processor_id() in
preemptible code.

But passing the CPU number is not really needed. It is only used to
determine whether we're on the BSP, and, if so, to save the microcode
patch for early loading.

 [ We don't absolutely need to do it on the BSP but we do that
   customarily there. ]

Instead, convert that function parameter to a boolean which denotes
whether the patch should be saved or not, thereby avoiding the use of
smp_processor_id() in preemptible code.

Signed-off-by: Borislav Petkov 
---
 arch/x86/kernel/cpu/microcode/amd.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/cpu/microcode/amd.c 
b/arch/x86/kernel/cpu/microcode/amd.c
index 45db4d2ebd01..e9f4d762aa5b 100644
--- a/arch/x86/kernel/cpu/microcode/amd.c
+++ b/arch/x86/kernel/cpu/microcode/amd.c
@@ -320,7 +320,7 @@ void load_ucode_amd_ap(unsigned int cpuid_1_eax)
 }
 
 static enum ucode_state
-load_microcode_amd(int cpu, u8 family, const u8 *data, size_t size);
+load_microcode_amd(bool save, u8 family, const u8 *data, size_t size);
 
 int __init save_microcode_in_initrd_amd(unsigned int cpuid_1_eax)
 {
@@ -338,8 +338,7 @@ int __init save_microcode_in_initrd_amd(unsigned int 
cpuid_1_eax)
if (!desc.mc)
return -EINVAL;
 
-   ret = load_microcode_amd(smp_processor_id(), x86_family(cpuid_1_eax),
-desc.data, desc.size);
+   ret = load_microcode_amd(true, x86_family(cpuid_1_eax), desc.data, 
desc.size);
if (ret != UCODE_OK)
return -EINVAL;
 
@@ -675,7 +674,7 @@ static enum ucode_state __load_microcode_amd(u8 family, 
const u8 *data,
 }
 
 static enum ucode_state
-load_microcode_amd(int cpu, u8 family, const u8 *data, size_t size)
+load_microcode_amd(bool save, u8 family, const u8 *data, size_t size)
 {
enum ucode_state ret;
 
@@ -689,8 +688,8 @@ load_microcode_amd(int cpu, u8 family, const u8 *data, 
size_t size)
 
 #ifdef CONFIG_X86_32
/* save BSP's matching patch for early load */
-   if (cpu_data(cpu).cpu_index == boot_cpu_data.cpu_index) {
-   struct ucode_patch *p = find_patch(cpu);
+   if (save) {
+   struct ucode_patch *p = find_patch(0);
if (p) {
memset(amd_ucode_patch, 0, PATCH_MAX_SIZE);
memcpy(amd_ucode_patch, p->data, min_t(u32, 
ksize(p->data),
@@ -722,11 +721,12 @@ static enum ucode_state request_microcode_amd(int cpu, 
struct device *device,
 {
char fw_name[36] = "amd-ucode/microcode_amd.bin";
struct cpuinfo_x86 *c = _data(cpu);
+   bool bsp = c->cpu_index == boot_cpu_data.cpu_index;
enum ucode_state ret = UCODE_NFOUND;
const struct firmware *fw;
 
/* reload ucode container only on the boot cpu */
-   if (!refresh_fw || c->cpu_index != boot_cpu_data.cpu_index)
+   if (!refresh_fw || !bsp)
return UCODE_OK;
 
if (c->x86 >= 0x15)
@@ -743,7 +743,7 @@ static enum ucode_state request_microcode_amd(int cpu, 
struct device *device,
goto fw_release;
}
 
-   ret = load_microcode_amd(cpu, c->x86, fw->data, fw->size);
+   ret = load_microcode_amd(bsp, c->x86, fw->data, fw->size);
 
  fw_release:
release_firmware(fw);
-- 
2.11.0

[PATCH] x86/microcode/AMD: Change load_microcode_amd()'s param to bool

[Borislav Petkov]

From: Borislav Petkov 

With CONFIG_DEBUG_PREEMPT enabled, I get:

  BUG: using smp_processor_id() in preemptible [] code: swapper/0/1
  caller is debug_smp_processor_id
  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc2+ #2
  Call Trace:
   dump_stack
   check_preemption_disabled
   debug_smp_processor_id
   save_microcode_in_initrd_amd
   ? microcode_init
   save_microcode_in_initrd
   ...

because, well, it says it above, we're using smp_processor_id() in
preemptible code.

But passing the CPU number is not really needed. It is only used to
determine whether we're on the BSP, and, if so, to save the microcode
patch for early loading.

 [ We don't absolutely need to do it on the BSP but we do that
   customarily there. ]

Instead, convert that function parameter to a boolean which denotes
whether the patch should be saved or not, thereby avoiding the use of
smp_processor_id() in preemptible code.

Signed-off-by: Borislav Petkov 
---
 arch/x86/kernel/cpu/microcode/amd.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/cpu/microcode/amd.c 
b/arch/x86/kernel/cpu/microcode/amd.c
index 45db4d2ebd01..e9f4d762aa5b 100644
--- a/arch/x86/kernel/cpu/microcode/amd.c
+++ b/arch/x86/kernel/cpu/microcode/amd.c
@@ -320,7 +320,7 @@ void load_ucode_amd_ap(unsigned int cpuid_1_eax)
 }
 
 static enum ucode_state
-load_microcode_amd(int cpu, u8 family, const u8 *data, size_t size);
+load_microcode_amd(bool save, u8 family, const u8 *data, size_t size);
 
 int __init save_microcode_in_initrd_amd(unsigned int cpuid_1_eax)
 {
@@ -338,8 +338,7 @@ int __init save_microcode_in_initrd_amd(unsigned int 
cpuid_1_eax)
if (!desc.mc)
return -EINVAL;
 
-   ret = load_microcode_amd(smp_processor_id(), x86_family(cpuid_1_eax),
-desc.data, desc.size);
+   ret = load_microcode_amd(true, x86_family(cpuid_1_eax), desc.data, 
desc.size);
if (ret != UCODE_OK)
return -EINVAL;
 
@@ -675,7 +674,7 @@ static enum ucode_state __load_microcode_amd(u8 family, 
const u8 *data,
 }
 
 static enum ucode_state
-load_microcode_amd(int cpu, u8 family, const u8 *data, size_t size)
+load_microcode_amd(bool save, u8 family, const u8 *data, size_t size)
 {
enum ucode_state ret;
 
@@ -689,8 +688,8 @@ load_microcode_amd(int cpu, u8 family, const u8 *data, 
size_t size)
 
 #ifdef CONFIG_X86_32
/* save BSP's matching patch for early load */
-   if (cpu_data(cpu).cpu_index == boot_cpu_data.cpu_index) {
-   struct ucode_patch *p = find_patch(cpu);
+   if (save) {
+   struct ucode_patch *p = find_patch(0);
if (p) {
memset(amd_ucode_patch, 0, PATCH_MAX_SIZE);
memcpy(amd_ucode_patch, p->data, min_t(u32, 
ksize(p->data),
@@ -722,11 +721,12 @@ static enum ucode_state request_microcode_amd(int cpu, 
struct device *device,
 {
char fw_name[36] = "amd-ucode/microcode_amd.bin";
struct cpuinfo_x86 *c = _data(cpu);
+   bool bsp = c->cpu_index == boot_cpu_data.cpu_index;
enum ucode_state ret = UCODE_NFOUND;
const struct firmware *fw;
 
/* reload ucode container only on the boot cpu */
-   if (!refresh_fw || c->cpu_index != boot_cpu_data.cpu_index)
+   if (!refresh_fw || !bsp)
return UCODE_OK;
 
if (c->x86 >= 0x15)
@@ -743,7 +743,7 @@ static enum ucode_state request_microcode_amd(int cpu, 
struct device *device,
goto fw_release;
}
 
-   ret = load_microcode_amd(cpu, c->x86, fw->data, fw->size);
+   ret = load_microcode_amd(bsp, c->x86, fw->data, fw->size);
 
  fw_release:
release_firmware(fw);
-- 
2.11.0

Re: [PATCH v5 2/7] staging: atomisp: Do not call dev_warn with a NULL device

[Alan Cox]

> The code for the special v1p8 / v2p8 gpios is ugly as sin, it operates on
> a global v2p8_gpio value rather then storing info in the gmin_subdev struct,
> as such passing the subdev->dev pointer would be simply wrong. AFAICT the
> v1p8 / v2p8 gpio code is the only caller passing in a NULL pointer and
> as said since thisv1p8 / v2p8 gpio code is only for some special evaluation
> boards, silencing the error when these variables are not present actually
> is the right thing to do.

Unfortunately I don't think it is constrained to RVPs. As with all
developer hacks on code that isn't subject to public review at the time
they escape into the wild 8(

Agreed though. The patch makes sense if you don't want to print anything.

> > which if my understanding of the subdevices is correct should pass the
> > right valid device field from the atomisp.
> > 
> > Please also cc me if you are proposing patches this driver - and also
> > linux-media.  
> 
> Sorry about that, I messed up my git send-email foo and send this to
> a wrong set of addresses (and also added v5 in the subject which should
> not be there) I did send out a fresh-copy with the full 7 patch patch-set
> directly after CTRL+c-ing this wrong send-email (which only got the
> first 3 patches send).

So I discovered just afterwards 8)

Alan

Re: [PATCH v5 2/7] staging: atomisp: Do not call dev_warn with a NULL device

[Alan Cox]

> The code for the special v1p8 / v2p8 gpios is ugly as sin, it operates on
> a global v2p8_gpio value rather then storing info in the gmin_subdev struct,
> as such passing the subdev->dev pointer would be simply wrong. AFAICT the
> v1p8 / v2p8 gpio code is the only caller passing in a NULL pointer and
> as said since thisv1p8 / v2p8 gpio code is only for some special evaluation
> boards, silencing the error when these variables are not present actually
> is the right thing to do.

Unfortunately I don't think it is constrained to RVPs. As with all
developer hacks on code that isn't subject to public review at the time
they escape into the wild 8(

Agreed though. The patch makes sense if you don't want to print anything.

> > which if my understanding of the subdevices is correct should pass the
> > right valid device field from the atomisp.
> > 
> > Please also cc me if you are proposing patches this driver - and also
> > linux-media.  
> 
> Sorry about that, I messed up my git send-email foo and send this to
> a wrong set of addresses (and also added v5 in the subject which should
> not be there) I did send out a fresh-copy with the full 7 patch patch-set
> directly after CTRL+c-ing this wrong send-email (which only got the
> first 3 patches send).

So I discovered just afterwards 8)

Alan

Re: [PATCH] staging: atomisp: lm3554: fix sparse warnings(was not declared. Should it be static?)

[Alan Cox]

On Mon, 29 May 2017 02:06:41 +0800
Chen Guanqiao  wrote:

> Fix "symbol 'xxx' was not declared. Should it be static?" sparse warnings.
> 
> Signed-off-by: Chen Guanqiao 
> ---

Reviewed-by: Alan Cox 

Re: [PATCH] staging: atomisp: lm3554: fix sparse warnings(was not declared. Should it be static?)

[Alan Cox]

On Mon, 29 May 2017 02:06:41 +0800
Chen Guanqiao  wrote:

> Fix "symbol 'xxx' was not declared. Should it be static?" sparse warnings.
> 
> Signed-off-by: Chen Guanqiao 
> ---

Reviewed-by: Alan Cox 

single-threaded wq lockdep is broken

[Johannes Berg]

Hi Tejun,

I suspect this is a long-standing bug introduced by all the pool rework
you did at some point, but I don't really know nor can I figure out how
to fix it right now. I guess it could possibly also be a lockdep issue,
or an issue in how it's used, but I definitely know that this used to
work (i.e. warn) back when I introduced the lockdep checking to the WQ
code. I was actually bitten by a bug like this, and erroneously
dismissed it as not being the case because lockdep hadn't warned (and
the actual deadlock debug output is basically not existent).

In any case, the following code really should result in a warning from
lockdep, but doesn't. If you comment in the #define DEADLOCK, it will
actually cause a deadlock :)


#include 
#include 
#include 
#include 
#include 

DEFINE_MUTEX(mtx);
static struct workqueue_struct *wq;
static struct work_struct w1, w2;

static void w1_wk(struct work_struct *w)
{
mutex_lock();
msleep(100);
mutex_unlock();
}

static void w2_wk(struct work_struct *w)
{
}

/*
 * if not defined, then lockdep should warn only,
 * if defined, the system will really deadlock.
 */

//#define DEADLOCK

static int init(void)
{
wq = create_singlethread_workqueue("test");
if (!wq)
return -ENOMEM;
INIT_WORK(, w1_wk);
INIT_WORK(, w2_wk);

#ifdef DEADLOCK
queue_work(wq, );
queue_work(wq, );
#endif
mutex_lock();
flush_work();
mutex_unlock();

#ifndef DEADLOCK
queue_work(wq, );
queue_work(wq, );
#endif

return 0;
}
module_init(init);


(to test, just copy it to some C file and add "obj-y += myfile.o" to
the Makefile in that directory, then boot the kernel - perhaps in a VM)

johannes

single-threaded wq lockdep is broken

[Johannes Berg]

Hi Tejun,

I suspect this is a long-standing bug introduced by all the pool rework
you did at some point, but I don't really know nor can I figure out how
to fix it right now. I guess it could possibly also be a lockdep issue,
or an issue in how it's used, but I definitely know that this used to
work (i.e. warn) back when I introduced the lockdep checking to the WQ
code. I was actually bitten by a bug like this, and erroneously
dismissed it as not being the case because lockdep hadn't warned (and
the actual deadlock debug output is basically not existent).

In any case, the following code really should result in a warning from
lockdep, but doesn't. If you comment in the #define DEADLOCK, it will
actually cause a deadlock :)


#include 
#include 
#include 
#include 
#include 

DEFINE_MUTEX(mtx);
static struct workqueue_struct *wq;
static struct work_struct w1, w2;

static void w1_wk(struct work_struct *w)
{
mutex_lock();
msleep(100);
mutex_unlock();
}

static void w2_wk(struct work_struct *w)
{
}

/*
 * if not defined, then lockdep should warn only,
 * if defined, the system will really deadlock.
 */

//#define DEADLOCK

static int init(void)
{
wq = create_singlethread_workqueue("test");
if (!wq)
return -ENOMEM;
INIT_WORK(, w1_wk);
INIT_WORK(, w2_wk);

#ifdef DEADLOCK
queue_work(wq, );
queue_work(wq, );
#endif
mutex_lock();
flush_work();
mutex_unlock();

#ifndef DEADLOCK
queue_work(wq, );
queue_work(wq, );
#endif

return 0;
}
module_init(init);


(to test, just copy it to some C file and add "obj-y += myfile.o" to
the Makefile in that directory, then boot the kernel - perhaps in a VM)

johannes

Re: [PATCH] CodingStyle: delete "kmalloc(sizeof(*var))" as preferred allocation form

[Pavel Machek]

On Thu 2017-05-25 12:46:04, Bernd Petrovitsch wrote:
> On Thu, 2017-05-25 at 03:35 -0700, Joe Perches wrote:
> > On Wed, 2017-05-24 at 13:18 +0300, Alexey Dobriyan wrote:
> > > Proper fix is to introduce typed allocation macros with the following
> > > signatures:
> > > 
> > > T* lmalloc(T, gfp);
> 
> Ack (FWIW).
> 
> [...]
> > > struct foo *x;
> > > x = lmalloc(struct foo, GFP_KERNEL);
> > 
> > Then code would be written
> > 
> > x = lmalloc(typeof(*x), GFP_KERNEL);
> 
> At least it is correct and changes automagically if x changes the type
> which
>   struct bar *x;
>   x = kmalloc(sizeof(struct foo), GFP_KERNEL);
> doesn't do and the compiler doesn't complain.
> 
> And the typeof() version could be written that way today but I can't
> remember seeing it (in the kernel and elsewhere).

Do we need new() macro that does all the magic internally?

If we have to provide "new and improved" malloc interface at least it should
be improved :-).
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH] CodingStyle: delete "kmalloc(sizeof(*var))" as preferred allocation form

[Pavel Machek]

On Thu 2017-05-25 12:46:04, Bernd Petrovitsch wrote:
> On Thu, 2017-05-25 at 03:35 -0700, Joe Perches wrote:
> > On Wed, 2017-05-24 at 13:18 +0300, Alexey Dobriyan wrote:
> > > Proper fix is to introduce typed allocation macros with the following
> > > signatures:
> > > 
> > > T* lmalloc(T, gfp);
> 
> Ack (FWIW).
> 
> [...]
> > > struct foo *x;
> > > x = lmalloc(struct foo, GFP_KERNEL);
> > 
> > Then code would be written
> > 
> > x = lmalloc(typeof(*x), GFP_KERNEL);
> 
> At least it is correct and changes automagically if x changes the type
> which
>   struct bar *x;
>   x = kmalloc(sizeof(struct foo), GFP_KERNEL);
> doesn't do and the compiler doesn't complain.
> 
> And the typeof() version could be written that way today but I can't
> remember seeing it (in the kernel and elsewhere).

Do we need new() macro that does all the magic internally?

If we have to provide "new and improved" malloc interface at least it should
be improved :-).
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 5/5] power: supply: bq27xxx: Correct supply status with current draw

[Pavel Machek]

Hi!

> The status reported directly by the battery controller is not always
> reliable and should be corrected based on the current draw information.
> 
> This implements such a correction with a dedicated function, called
> when retrieving the supply status.
> 

> @@ -1182,6 +1196,8 @@ static int bq27xxx_battery_status(struct 
> bq27xxx_device_info *di,
>   else
>   status = POWER_SUPPLY_STATUS_DISCHARGING;
>   } else {
> + curr = (int)((s16)curr) * 1000;

Umm.

> @@ -1190,6 +1206,18 @@ static int bq27xxx_battery_status(struct 
> bq27xxx_device_info *di,
>   status = POWER_SUPPLY_STATUS_CHARGING;
>   }
>  
> +
> + if (curr == 0 && status != POWER_SUPPLY_STATUS_NOT_CHARGING)
> + status = POWER_SUPPLY_STATUS_FULL;
> +
> + if (status == POWER_SUPPLY_STATUS_FULL) {
> + /* Drawing or providing current when full */
> + if (curr > 0)
> + status = POWER_SUPPLY_STATUS_CHARGING;
> + else if (curr < 0)
> + status = POWER_SUPPLY_STATUS_DISCHARGING;
> + }

Are you sure this works? On N900, we normally see small currents to/from "full" 
battery.

Should the test be for absolute_value(curr) < something rather than for == 0?

What hw did you test it on?

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 5/5] power: supply: bq27xxx: Correct supply status with current draw

[Pavel Machek]

Hi!

> The status reported directly by the battery controller is not always
> reliable and should be corrected based on the current draw information.
> 
> This implements such a correction with a dedicated function, called
> when retrieving the supply status.
> 

> @@ -1182,6 +1196,8 @@ static int bq27xxx_battery_status(struct 
> bq27xxx_device_info *di,
>   else
>   status = POWER_SUPPLY_STATUS_DISCHARGING;
>   } else {
> + curr = (int)((s16)curr) * 1000;

Umm.

> @@ -1190,6 +1206,18 @@ static int bq27xxx_battery_status(struct 
> bq27xxx_device_info *di,
>   status = POWER_SUPPLY_STATUS_CHARGING;
>   }
>  
> +
> + if (curr == 0 && status != POWER_SUPPLY_STATUS_NOT_CHARGING)
> + status = POWER_SUPPLY_STATUS_FULL;
> +
> + if (status == POWER_SUPPLY_STATUS_FULL) {
> + /* Drawing or providing current when full */
> + if (curr > 0)
> + status = POWER_SUPPLY_STATUS_CHARGING;
> + else if (curr < 0)
> + status = POWER_SUPPLY_STATUS_DISCHARGING;
> + }

Are you sure this works? On N900, we normally see small currents to/from "full" 
battery.

Should the test be for absolute_value(curr) < something rather than for == 0?

What hw did you test it on?

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Boris Lukashev]

One-time sealable memory makes the most sense from a defensive
perspective - red team reads this stuff, the races mentioned will be
implemented as described to win the day, and probably in other
innovative ways. If a gap is left in the implementation, without
explicit coverage by an adjacent function, it will be used no matter
how small the chances of it occurring in the real world are - grooming
systems to create unlikely conditions is fair play (look at
eternalblue's SMB pool machinations).
However, out of tree modules will likely not appreciate this - third
party LSMs, tpe module, SCST, etc. I dont want to get into the "NIH"
debate, they're real functional components, used by real companies,
often enough that they need to be considered a member of the
ecosystem, even if not a first-order member.
So what about a middle ground where CoW semantics are used to enforce
the state of these allocations as RO, but provide a strictly
controlled pathway to read the RO data, copy and modify it, then write
and seal into a new allocation. Successful return from this process
should permit the page table to change the pointer to where the object
now resides, and initiate freeing of the original memory so long as a
refcount is kept for accesses. That way, sealable memory is sealed,
and any consumers reading it will be using the original ptr to the
original smalloc region. Attackers who do manage to change the
allocation by writing a new one still have to figure out how to change
the region used by an existing consumer. New consumers will get hit by
whatever they changed, but the change will be tracked and require them
to gain execution control over the allocator itself in order to affect
the change (or ROP chain something else into doing it, but thats's a
discussion on RAP/CFI).
CPU-local ops are great, if they dont halt the other cores. Stopping
all other CPUs is going to be DoA in HPC and other CPU intensive
workloads - think what ZFS would do if its pipelines kept getting
halted by something running a lot of smallocs (they get
non-preemptible often enough, requiring waits on both sides of the
op), how how LIO would behave - iSCSI waits for no man or woman, or
their allocator strategies. I'm all for "security should be more of a
concern than performance - its easier to build a faster car later if
you're still alive to do it," but keeping in mind who the consumers
are, i can easily see this functionality staying disabled in most
distributions and thus receiving much less testing and beatdown than
it should.
Lastly, my meager understanding is that PAX set the entire kernel as
RO, and implemented writeable access via pax_open/close. How were they
fighting against race conditions, and what is the benefit of specific
regions being allocated this way as opposed to the RO-all-the-things
approach which makes writes a specialized set of operations?

On Sun, May 28, 2017 at 2:23 PM, Kees Cook  wrote:
> On Wed, May 24, 2017 at 10:45 AM, Igor Stoppa  wrote:
>> On 23/05/17 23:11, Kees Cook wrote:
>>> On Tue, May 23, 2017 at 2:43 AM, Igor Stoppa  wrote:
>>> I meant this:
>>>
>>> CPU 1 CPU 2
>>> create
>>> alloc
>>> write
>>> seal
>>> ...
>>> unseal
>>> write
>>> write
>>> seal
>>>
>>> The CPU 2 write would be, for example, an attacker using a
>>> vulnerability to attempt to write to memory in the sealed area. All it
>>> would need to do to succeed would be to trigger an action in the
>>> kernel that would do a "legitimate" write (which requires the unseal),
>>> and race it. Unsealing should be CPU-local, if the API is going to
>>> support this kind of access.
>>
>> I see.
>> If the CPU1 were to forcibly halt anything that can race with it, then
>> it would be sure that there was no interference.
>
> Correct. This is actually what ARM does for doing kernel memory
> writing when poking stuff for kprobes, etc. It's rather dramatic,
> though. :)
>
>> A reactive approach could be, instead, to re-validate the content after
>> the sealing, assuming that it is possible.
>
> I would prefer to avoid this, as that allows an attacker to still have
> made the changes (which could even result in them then disabling the
> re-validation during the attack).
>
>>> I am more concerned about _any_ unseal after initial seal. And even
>>> then, it'd be nice to keep things CPU-local. My concerns are related
>>> to the write-rarely proposal (https://lkml.org/lkml/2017/3/29/704)
>>> which is kind of like this, but focused on the .data section, not
>>> dynamic memory. It has similar concerns about CPU-locality.
>>> Additionally, even writing to memory and then making it read-only
>>> later runs risks (see threads about BPF JIT races vs making things
>>> read-only: https://patchwork.kernel.org/patch/9662653/ Alexei's NAK
>>> doesn't change the risk this series is fixing: races with attacker
>>> writes during assignment but before read-only marking).
>>
>> If you are 

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

[Boris Lukashev]

One-time sealable memory makes the most sense from a defensive
perspective - red team reads this stuff, the races mentioned will be
implemented as described to win the day, and probably in other
innovative ways. If a gap is left in the implementation, without
explicit coverage by an adjacent function, it will be used no matter
how small the chances of it occurring in the real world are - grooming
systems to create unlikely conditions is fair play (look at
eternalblue's SMB pool machinations).
However, out of tree modules will likely not appreciate this - third
party LSMs, tpe module, SCST, etc. I dont want to get into the "NIH"
debate, they're real functional components, used by real companies,
often enough that they need to be considered a member of the
ecosystem, even if not a first-order member.
So what about a middle ground where CoW semantics are used to enforce
the state of these allocations as RO, but provide a strictly
controlled pathway to read the RO data, copy and modify it, then write
and seal into a new allocation. Successful return from this process
should permit the page table to change the pointer to where the object
now resides, and initiate freeing of the original memory so long as a
refcount is kept for accesses. That way, sealable memory is sealed,
and any consumers reading it will be using the original ptr to the
original smalloc region. Attackers who do manage to change the
allocation by writing a new one still have to figure out how to change
the region used by an existing consumer. New consumers will get hit by
whatever they changed, but the change will be tracked and require them
to gain execution control over the allocator itself in order to affect
the change (or ROP chain something else into doing it, but thats's a
discussion on RAP/CFI).
CPU-local ops are great, if they dont halt the other cores. Stopping
all other CPUs is going to be DoA in HPC and other CPU intensive
workloads - think what ZFS would do if its pipelines kept getting
halted by something running a lot of smallocs (they get
non-preemptible often enough, requiring waits on both sides of the
op), how how LIO would behave - iSCSI waits for no man or woman, or
their allocator strategies. I'm all for "security should be more of a
concern than performance - its easier to build a faster car later if
you're still alive to do it," but keeping in mind who the consumers
are, i can easily see this functionality staying disabled in most
distributions and thus receiving much less testing and beatdown than
it should.
Lastly, my meager understanding is that PAX set the entire kernel as
RO, and implemented writeable access via pax_open/close. How were they
fighting against race conditions, and what is the benefit of specific
regions being allocated this way as opposed to the RO-all-the-things
approach which makes writes a specialized set of operations?

On Sun, May 28, 2017 at 2:23 PM, Kees Cook  wrote:
> On Wed, May 24, 2017 at 10:45 AM, Igor Stoppa  wrote:
>> On 23/05/17 23:11, Kees Cook wrote:
>>> On Tue, May 23, 2017 at 2:43 AM, Igor Stoppa  wrote:
>>> I meant this:
>>>
>>> CPU 1 CPU 2
>>> create
>>> alloc
>>> write
>>> seal
>>> ...
>>> unseal
>>> write
>>> write
>>> seal
>>>
>>> The CPU 2 write would be, for example, an attacker using a
>>> vulnerability to attempt to write to memory in the sealed area. All it
>>> would need to do to succeed would be to trigger an action in the
>>> kernel that would do a "legitimate" write (which requires the unseal),
>>> and race it. Unsealing should be CPU-local, if the API is going to
>>> support this kind of access.
>>
>> I see.
>> If the CPU1 were to forcibly halt anything that can race with it, then
>> it would be sure that there was no interference.
>
> Correct. This is actually what ARM does for doing kernel memory
> writing when poking stuff for kprobes, etc. It's rather dramatic,
> though. :)
>
>> A reactive approach could be, instead, to re-validate the content after
>> the sealing, assuming that it is possible.
>
> I would prefer to avoid this, as that allows an attacker to still have
> made the changes (which could even result in them then disabling the
> re-validation during the attack).
>
>>> I am more concerned about _any_ unseal after initial seal. And even
>>> then, it'd be nice to keep things CPU-local. My concerns are related
>>> to the write-rarely proposal (https://lkml.org/lkml/2017/3/29/704)
>>> which is kind of like this, but focused on the .data section, not
>>> dynamic memory. It has similar concerns about CPU-locality.
>>> Additionally, even writing to memory and then making it read-only
>>> later runs risks (see threads about BPF JIT races vs making things
>>> read-only: https://patchwork.kernel.org/patch/9662653/ Alexei's NAK
>>> doesn't change the risk this series is fixing: races with attacker
>>> writes during assignment but before read-only marking).
>>
>> If you are talking about an attacker, rather than protection against
>> accidental 

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[Andy Lutomirski]

On Sun, May 28, 2017 at 11:18 AM, Bernhard Held  wrote:
> Hi,
>
> this patch breaks the boot of my kernel. The last message is "Booting
> the kernel.".
>
> My setup might be unusual: I'm running a Xenon E5450 (LGA 771) in a
> Gigbayte G33-DS3R board (LGA 775). The BIOS is patched with the
> microcode of the E5450 and recognizes the CPU.
>
> Please find below the dmesg of a the latest kernel w/o the PAT-patch.
> I'm happy to provide more information or to test patches.

I think this patch is bogus.  pat_enabled() sure looks like it's
supposed to return true if PAT is *enabled*, and these days PAT is
"enabled" even if there's no HW PAT support.  Even if the patch were
somehow correct, it should have been split up into two patches, one to
change pat_enabled() and one to use this_cpu_has().

Ingo, I'd suggest reverting the patch, cc-ing stable on the revert so
-stable knows not to backport it, and starting over with the fix.
>From very brief inspection, the right fix is to make sure that
pat_init(), or at least init_cache_modes(), gets called on the
affected CPUs.

As a future cleanup, I think that pat_enabled() could be deleted
outright and, if needed, replaced by functions like have_memtype_wc()
or similar.  (Do we already have helpers like that?)  Toshi, am I
right?

--Andy

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[Andy Lutomirski]

On Sun, May 28, 2017 at 11:18 AM, Bernhard Held  wrote:
> Hi,
>
> this patch breaks the boot of my kernel. The last message is "Booting
> the kernel.".
>
> My setup might be unusual: I'm running a Xenon E5450 (LGA 771) in a
> Gigbayte G33-DS3R board (LGA 775). The BIOS is patched with the
> microcode of the E5450 and recognizes the CPU.
>
> Please find below the dmesg of a the latest kernel w/o the PAT-patch.
> I'm happy to provide more information or to test patches.

I think this patch is bogus.  pat_enabled() sure looks like it's
supposed to return true if PAT is *enabled*, and these days PAT is
"enabled" even if there's no HW PAT support.  Even if the patch were
somehow correct, it should have been split up into two patches, one to
change pat_enabled() and one to use this_cpu_has().

Ingo, I'd suggest reverting the patch, cc-ing stable on the revert so
-stable knows not to backport it, and starting over with the fix.
>From very brief inspection, the right fix is to make sure that
pat_init(), or at least init_cache_modes(), gets called on the
affected CPUs.

As a future cleanup, I think that pat_enabled() could be deleted
outright and, if needed, replaced by functions like have_memtype_wc()
or similar.  (Do we already have helpers like that?)  Toshi, am I
right?

--Andy

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[Bernhard Held]

Hi,

this patch breaks the boot of my kernel. The last message is "Booting
the kernel.".

My setup might be unusual: I'm running a Xenon E5450 (LGA 771) in a
Gigbayte G33-DS3R board (LGA 775). The BIOS is patched with the
microcode of the E5450 and recognizes the CPU.

Please find below the dmesg of a the latest kernel w/o the PAT-patch.
I'm happy to provide more information or to test patches.

Have fun,
Bernhard

[0.00] Linux version 4.12.0-rc2-linus+ (berny@quad) (gcc version 6.3.1 
20170202 [gcc-6-branch revision 245119] (SUSE Linux) ) #152 SMP PREEMPT Sun May 
28 19:26:20 CEST 2017
[0.00] Command line: BOOT_IMAGE=/vmlinuz-4.12.0-rc2-linus+ 
root=/dev/mapper/VGMX300-root resume=/dev/sda2 showopts radeon.dpm=1 
memmap=1$0xe4fd net.ifnames=0
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Enabled xstate features 0x3, context size is 576 bytes, 
using 'standard' format.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009dbff] usable
[0.00] BIOS-e820: [mem 0x0009f800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xcfed] usable
[0.00] BIOS-e820: [mem 0xcfee-0xcfee2fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xcfee3000-0xcfee] ACPI data
[0.00] BIOS-e820: [mem 0xcfef-0xcfef] reserved
[0.00] BIOS-e820: [mem 0xd000-0xdfff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x0001afff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] e820: user-defined physical RAM map:
[0.00] user: [mem 0x-0xe4fc] usable
[0.00] user: [mem 0xe4fd-0xe4fd] reserved
[0.00] user: [mem 0xe4fe-0x0009dbff] usable
[0.00] user: [mem 0x0009f800-0x0009] reserved
[0.00] user: [mem 0x000f-0x000f] reserved
[0.00] user: [mem 0x0010-0xcfed] usable
[0.00] user: [mem 0xcfee-0xcfee2fff] ACPI NVS
[0.00] user: [mem 0xcfee3000-0xcfee] ACPI data
[0.00] user: [mem 0xcfef-0xcfef] reserved
[0.00] user: [mem 0xd000-0xdfff] reserved
[0.00] user: [mem 0xfec0-0x] reserved
[0.00] user: [mem 0x0001-0x0001afff] usable
[0.00] SMBIOS 2.4 present.
[0.00] DMI: Gigabyte Technology Co., Ltd. G33-DS3R/G33-DS3R, BIOS F7L 
07/31/2009
[0.00] tsc: Fast TSC calibration using PIT
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x1b max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-CDFFF write-protect
[0.00]   CE000-E uncachable
[0.00]   F-F write-through
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 00 mask 0F write-back
[0.00]   1 base 00E000 mask 0FE000 uncachable
[0.00]   2 base 00D000 mask 0FF000 uncachable
[0.00]   3 base 01 mask 0F write-back
[0.00]   4 base 01C000 mask 0FC000 uncachable
[0.00]   5 base 01B000 mask 0FF000 uncachable
[0.00]   6 base 00CFF0 mask 00 uncachable
[0.00]   7 disabled
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT
[0.00] mtrr: your BIOS has configured an incorrect mask, fixing it.
[0.00] mtrr: your BIOS has configured an incorrect mask, fixing it.
[0.00] mtrr: your BIOS has configured an incorrect mask, fixing it.
[0.00] mtrr: your BIOS has configured an incorrect mask, fixing it.
[0.00] mtrr: your BIOS has configured an incorrect mask, fixing it.
[0.00] mtrr: your BIOS has configured an incorrect mask, fixing it.
[0.00] mtrr: your BIOS has configured an incorrect mask, fixing it.
[0.00] total RAM covered: 6143M
[0.00] Found optimal setting for mtrr clean up
[0.00]  gran_size: 64K  chunk_size: 2M  num_reg: 7  lose cover RAM: 
0G
[0.00] e820: update [mem 0xcff0-0x] usable ==> reserved
[0.00] 

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[Bernhard Held]

Hi,

this patch breaks the boot of my kernel. The last message is "Booting
the kernel.".

My setup might be unusual: I'm running a Xenon E5450 (LGA 771) in a
Gigbayte G33-DS3R board (LGA 775). The BIOS is patched with the
microcode of the E5450 and recognizes the CPU.

Please find below the dmesg of a the latest kernel w/o the PAT-patch.
I'm happy to provide more information or to test patches.

Have fun,
Bernhard

[0.00] Linux version 4.12.0-rc2-linus+ (berny@quad) (gcc version 6.3.1 
20170202 [gcc-6-branch revision 245119] (SUSE Linux) ) #152 SMP PREEMPT Sun May 
28 19:26:20 CEST 2017
[0.00] Command line: BOOT_IMAGE=/vmlinuz-4.12.0-rc2-linus+ 
root=/dev/mapper/VGMX300-root resume=/dev/sda2 showopts radeon.dpm=1 
memmap=1$0xe4fd net.ifnames=0
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Enabled xstate features 0x3, context size is 576 bytes, 
using 'standard' format.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009dbff] usable
[0.00] BIOS-e820: [mem 0x0009f800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xcfed] usable
[0.00] BIOS-e820: [mem 0xcfee-0xcfee2fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xcfee3000-0xcfee] ACPI data
[0.00] BIOS-e820: [mem 0xcfef-0xcfef] reserved
[0.00] BIOS-e820: [mem 0xd000-0xdfff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x0001afff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] e820: user-defined physical RAM map:
[0.00] user: [mem 0x-0xe4fc] usable
[0.00] user: [mem 0xe4fd-0xe4fd] reserved
[0.00] user: [mem 0xe4fe-0x0009dbff] usable
[0.00] user: [mem 0x0009f800-0x0009] reserved
[0.00] user: [mem 0x000f-0x000f] reserved
[0.00] user: [mem 0x0010-0xcfed] usable
[0.00] user: [mem 0xcfee-0xcfee2fff] ACPI NVS
[0.00] user: [mem 0xcfee3000-0xcfee] ACPI data
[0.00] user: [mem 0xcfef-0xcfef] reserved
[0.00] user: [mem 0xd000-0xdfff] reserved
[0.00] user: [mem 0xfec0-0x] reserved
[0.00] user: [mem 0x0001-0x0001afff] usable
[0.00] SMBIOS 2.4 present.
[0.00] DMI: Gigabyte Technology Co., Ltd. G33-DS3R/G33-DS3R, BIOS F7L 
07/31/2009
[0.00] tsc: Fast TSC calibration using PIT
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x1b max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-CDFFF write-protect
[0.00]   CE000-E uncachable
[0.00]   F-F write-through
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 00 mask 0F write-back
[0.00]   1 base 00E000 mask 0FE000 uncachable
[0.00]   2 base 00D000 mask 0FF000 uncachable
[0.00]   3 base 01 mask 0F write-back
[0.00]   4 base 01C000 mask 0FC000 uncachable
[0.00]   5 base 01B000 mask 0FF000 uncachable
[0.00]   6 base 00CFF0 mask 00 uncachable
[0.00]   7 disabled
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT
[0.00] mtrr: your BIOS has configured an incorrect mask, fixing it.
[0.00] mtrr: your BIOS has configured an incorrect mask, fixing it.
[0.00] mtrr: your BIOS has configured an incorrect mask, fixing it.
[0.00] mtrr: your BIOS has configured an incorrect mask, fixing it.
[0.00] mtrr: your BIOS has configured an incorrect mask, fixing it.
[0.00] mtrr: your BIOS has configured an incorrect mask, fixing it.
[0.00] mtrr: your BIOS has configured an incorrect mask, fixing it.
[0.00] total RAM covered: 6143M
[0.00] Found optimal setting for mtrr clean up
[0.00]  gran_size: 64K  chunk_size: 2M  num_reg: 7  lose cover RAM: 
0G
[0.00] e820: update [mem 0xcff0-0x] usable ==> reserved
[0.00] 

Re: [PATCH] clocksource: moxart: Add AST2500 compatible string

[Daniel Lezcano]

On 28/05/2017 15:59, Linus Walleij wrote:
> On Tue, May 16, 2017 at 9:58 AM, Andrew Jeffery  wrote:
> 
>> Also clean up space-before-tab issues in the documentation.
>>
>> Signed-off-by: Andrew Jeffery 
> 
> Reviewed-by: Linus Walleij 
> 
> Does this collide with Daniel's 2500 patch?
> 
> Sorry for the mess, tell me if I need to fix something up :(

It is ok, an usual collision change to be fixed when merging ;)

By the way, can you have a look at fttmr010_read_sched_clock to remove
the local_fttmr->count_down test?

Thanks.

  -- Daniel

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

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH] clocksource: moxart: Add AST2500 compatible string

[Daniel Lezcano]

On 28/05/2017 15:59, Linus Walleij wrote:
> On Tue, May 16, 2017 at 9:58 AM, Andrew Jeffery  wrote:
> 
>> Also clean up space-before-tab issues in the documentation.
>>
>> Signed-off-by: Andrew Jeffery 
> 
> Reviewed-by: Linus Walleij 
> 
> Does this collide with Daniel's 2500 patch?
> 
> Sorry for the mess, tell me if I need to fix something up :(

It is ok, an usual collision change to be fixed when merging ;)

By the way, can you have a look at fttmr010_read_sched_clock to remove
the local_fttmr->count_down test?

Thanks.

  -- Daniel

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

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH v5 2/7] staging: atomisp: Do not call dev_warn with a NULL device

[Hans de Goede]

Hi,

On 28-05-17 19:08, Alan Cox wrote:

On Sun, 28 May 2017 14:30:35 +0200
Hans de Goede  wrote:


Do not call dev_warn with a NULL device, this silence the following 2
warnings:

[   14.392194] (NULL device *): Failed to find gmin variable gmin_V2P8GPIO
[   14.392257] (NULL device *): Failed to find gmin variable gmin_V1P8GPIO

We could switch to using pr_warn for dev == NULL instead, but as comments
in the source indicate, the check for these 2 special gmin variables with
a NULL device is a workaround for 2 specific evaluation boards, so
completely silencing the missing warning for these actually is a good
thing.


At which point real missing variables won't get reported so NAK. I think
the right fix is to make the offending callers pass

subdev->dev


The code for the special v1p8 / v2p8 gpios is ugly as sin, it operates on
a global v2p8_gpio value rather then storing info in the gmin_subdev struct,
as such passing the subdev->dev pointer would be simply wrong. AFAICT the
v1p8 / v2p8 gpio code is the only caller passing in a NULL pointer and
as said since thisv1p8 / v2p8 gpio code is only for some special evaluation
boards, silencing the error when these variables are not present actually
is the right thing to do.


which if my understanding of the subdevices is correct should pass the
right valid device field from the atomisp.

Please also cc me if you are proposing patches this driver - and also
linux-media.


Sorry about that, I messed up my git send-email foo and send this to
a wrong set of addresses (and also added v5 in the subject which should
not be there) I did send out a fresh-copy with the full 7 patch patch-set
directly after CTRL+c-ing this wrong send-email (which only got the
first 3 patches send).

Regards,

Hans

Re: [PATCH v5 2/7] staging: atomisp: Do not call dev_warn with a NULL device

[Hans de Goede]

Hi,

On 28-05-17 19:08, Alan Cox wrote:

On Sun, 28 May 2017 14:30:35 +0200
Hans de Goede  wrote:


Do not call dev_warn with a NULL device, this silence the following 2
warnings:

[   14.392194] (NULL device *): Failed to find gmin variable gmin_V2P8GPIO
[   14.392257] (NULL device *): Failed to find gmin variable gmin_V1P8GPIO

We could switch to using pr_warn for dev == NULL instead, but as comments
in the source indicate, the check for these 2 special gmin variables with
a NULL device is a workaround for 2 specific evaluation boards, so
completely silencing the missing warning for these actually is a good
thing.


At which point real missing variables won't get reported so NAK. I think
the right fix is to make the offending callers pass

subdev->dev


The code for the special v1p8 / v2p8 gpios is ugly as sin, it operates on
a global v2p8_gpio value rather then storing info in the gmin_subdev struct,
as such passing the subdev->dev pointer would be simply wrong. AFAICT the
v1p8 / v2p8 gpio code is the only caller passing in a NULL pointer and
as said since thisv1p8 / v2p8 gpio code is only for some special evaluation
boards, silencing the error when these variables are not present actually
is the right thing to do.


which if my understanding of the subdevices is correct should pass the
right valid device field from the atomisp.

Please also cc me if you are proposing patches this driver - and also
linux-media.


Sorry about that, I messed up my git send-email foo and send this to
a wrong set of addresses (and also added v5 in the subject which should
not be there) I did send out a fresh-copy with the full 7 patch patch-set
directly after CTRL+c-ing this wrong send-email (which only got the
first 3 patches send).

Regards,

Hans