Re: [v2 1/4] coccinelle: api: extend memdup_user transformation with GFP_USER

[Markus Elfring]

> Applied.

Do you care for patch review concerns according to this SmPL script adjustment?

* https://lore.kernel.org/cocci/5c0dae88-e172-3ba6-f86c-d1a6238bb...@web.de/
  https://lkml.org/lkml/2020/6/9/568

* https://lore.kernel.org/cocci/c3464cad-e567-9ef5-b4e3-a01e3b111...@web.de/
  https://lkml.org/lkml/2020/6/8/637

Regards,
Markus

Re: [GIT PULL] EFI fixes for v5.8-rc

[Ard Biesheuvel]

On Thu, 9 Jul 2020 at 16:28, Ard Biesheuvel  wrote:
>
> The following changes since commit 2a55280a3675203496d302463b941834228b9875:
>
>   efi/libstub: arm: Print CPU boot mode and MMU state at boot (2020-06-17 
> 15:29:11 +0200)
>
> are available in the Git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git 
> tags/efi-urgent-for-v5.8-rc4
>
> for you to fetch changes up to 769e0fe1171e95d90ea5a2d6d0b2bdc7d5d2e7b2:
>
>   efi: Revert "efi/x86: Fix build with gcc 4" (2020-07-09 10:14:29 +0300)
>
> 
> EFI fixes for v5.8-rc4:
> - Fix the layering violation in the use of the EFI runtime services
>   availability mask in users of the 'efivars' abstraction
> - Revert build fix for GCC v4.8 which is no longer supported
> - Some fixes for build issues found by Atish while working on RISC-V support
> - Avoid --whole-archive when linking the stub on arm64
> - Some x86 EFI stub cleanups from Arvind
>
> 
> Ard Biesheuvel (2):
>   efi/efivars: Expose RT service availability via efivars abstraction
>   efi: Revert "efi/x86: Fix build with gcc 4"
>
> Arvind Sankar (2):
>   efi/x86: Remove unused variables
>   efi/x86: Only copy upto the end of setup_header
>
> Atish Patra (2):
>   efi/libstub: Fix gcc error around __umoddi3 for 32 bit builds
>   efi/libstub: Move the function prototypes to header file
>
> Masahiro Yamada (1):
>   efi/libstub/arm64: link stub lib.a conditionally
>
>  arch/arm64/Makefile   |  2 +-
>  drivers/firmware/efi/efi-pstore.c |  5 +
>  drivers/firmware/efi/efi.c| 12 
>  drivers/firmware/efi/efivars.c|  5 +
>  drivers/firmware/efi/libstub/Makefile |  3 +--
>  drivers/firmware/efi/libstub/alignedmem.c |  2 +-
>  drivers/firmware/efi/libstub/efi-stub.c   | 17 -
>  drivers/firmware/efi/libstub/efistub.h| 16 
>  drivers/firmware/efi/libstub/x86-stub.c   |  8 
>  drivers/firmware/efi/vars.c   |  6 ++
>  fs/efivarfs/super.c   |  6 +++---
>  include/linux/efi.h   |  1 +
>  12 files changed, 43 insertions(+), 40 deletions(-)

Ping?

Re: [PATCH 1/3] media: rkvdec: Fix H264 scaling list order

[Mauro Carvalho Chehab]

Em Sat, 18 Jul 2020 07:05:54 +0200
Mauro Carvalho Chehab  escreveu:

> From: Jonas Karlman 
> 
> The Rockchip Video Decoder driver is expecting that the values in a
> scaling list are in zig-zag order and applies the inverse scanning process
> to get the values in matrix order.
> 
> Commit 0b0393d59eb4 ("media: uapi: h264: clarify expected
> scaling_list_4x4/8x8 order") clarified that the values in the scaling list
> should already be in matrix order.
> 
> Fix this by removing the reordering and change to use two memcpy.

Please ignore this one. This patch is already merged, and it is
not related to the 2 atomisp patches on this short series.

Thanks,
Mauro

Re: [RFC][PATCH] x86: optimization to avoid CAL+RES IPIs

[Josh Don]

Hey Andy, thanks for taking a look.

On Fri, Jul 17, 2020 at 8:14 PM Andy Lutomirski  wrote:
>
> PeterZ and I fixed a whole series of bugs a few years ago, and remote
> wakeups *should* already do this. Did we miss something?  Did it
> regress?  Even the call_function_single path ought to go through this:
>
> void send_call_function_single_ipi(int cpu)
> {
> struct rq *rq = cpu_rq(cpu);
>
> if (!set_nr_if_polling(rq->idle))
> arch_send_call_function_single_ipi(cpu);
> else
> trace_sched_wake_idle_without_ipi(cpu);
> }
>

Yep, I was sitting on this for a bit and raced with b2a02fc43a there.
90b5363ac also got rid of the last smp_send_reschedule() that was
triggering the ipiless handling.

One of the nice parts of the patch was that it could blanket apply to
all of the smp_call/reschedule.  However, with the above patches that
isn't a concern; it makes more sense to keep the existing
TIF_POLLING_NRFLAG logic.

Re: [PATCH RFC V2 12/17] memremap: Add zone device access protection

[Ira Weiny]

On Fri, Jul 17, 2020 at 11:17:18AM +0200, Peter Zijlstra wrote:
> On Fri, Jul 17, 2020 at 12:20:51AM -0700, ira.we...@intel.com wrote:
> > +void dev_access_disable(void)
> > +{
> > +   unsigned long flags;
> > +
> > +   if (!static_branch_unlikely(_protection_static_key))
> > +   return;
> > +
> > +   local_irq_save(flags);
> > +   current->dev_page_access_ref--;
> > +   if (current->dev_page_access_ref == 0)
> 
>   if (!--current->dev_page_access_ref)

It's not my style but I'm ok with it.

> 
> > +   pks_update_protection(dev_page_pkey, PKEY_DISABLE_ACCESS);
> > +   local_irq_restore(flags);
> > +}
> > +EXPORT_SYMBOL_GPL(dev_access_disable);
> > +
> > +void dev_access_enable(void)
> > +{
> > +   unsigned long flags;
> > +
> > +   if (!static_branch_unlikely(_protection_static_key))
> > +   return;
> > +
> > +   local_irq_save(flags);
> > +   /* 0 clears the PKEY_DISABLE_ACCESS bit, allowing access */
> > +   if (current->dev_page_access_ref == 0)
> > +   pks_update_protection(dev_page_pkey, 0);
> > +   current->dev_page_access_ref++;
> 
>   if (!current->dev_page_access_ref++)

Sure.

> 
> > +   local_irq_restore(flags);
> > +}
> > +EXPORT_SYMBOL_GPL(dev_access_enable);
> 
> 
> Also, you probably want something like:
> 
> static __always_inline devm_access_disable(void)

Yes that is better.

However, again Dan and I agree devm is not the right prefix here.

I've updated.

Thanks!
Ira

> {
>   if (static_branch_unlikely(_protection_static_key))
>   __devm_access_disable();
> }
> 
> static __always_inline devm_access_enable(void)
> {
>   if (static_branch_unlikely(_protection_static_key))
>   __devm_access_enable();
> }

[PATCH] mt76: mt76u: add missing release on skb in __mt76x02u_mcu_send_msg

[Navid Emamdoost]

In the implementation of __mt76x02u_mcu_send_msg() the skb is consumed
all execution paths except one. Release skb before returning if
test_bit() fails.

Signed-off-by: Navid Emamdoost 
---
 drivers/net/wireless/mediatek/mt76/mt76x02_usb_mcu.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_usb_mcu.c 
b/drivers/net/wireless/mediatek/mt76/mt76x02_usb_mcu.c
index a30bb536fc8a..e43d13d7c988 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_usb_mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_usb_mcu.c
@@ -87,8 +87,10 @@ __mt76x02u_mcu_send_msg(struct mt76_dev *dev, struct sk_buff 
*skb,
u32 info;
int ret;
 
-   if (test_bit(MT76_REMOVED, >phy.state))
-   return 0;
+   if (test_bit(MT76_REMOVED, >phy.state)) {
+   ret = 0;
+   goto out;
+   }
 
if (wait_resp) {
seq = ++dev->mcu.msg_seq & 0xf;
@@ -111,6 +113,7 @@ __mt76x02u_mcu_send_msg(struct mt76_dev *dev, struct 
sk_buff *skb,
if (wait_resp)
ret = mt76x02u_mcu_wait_resp(dev, seq);
 
+out:
consume_skb(skb);
 
return ret;
-- 
2.17.1

Re: [PATCH v5 03/17] perf ftrace: add option -t/--tid to filter by thread id

[Changbin Du]

On Fri, Jul 17, 2020 at 01:01:24PM -0400, Steven Rostedt wrote:
> On Fri, 17 Jul 2020 21:26:50 +0800
> Changbin Du  wrote:
> 
> > On Thu, Jul 16, 2020 at 12:36:30PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Sat, Jul 11, 2020 at 08:40:21PM +0800, Changbin Du escreveu:  
> > > > This allows us to trace single thread instead of the whole process.
> > > > 
> > > > Signed-off-by: Changbin Du 
> > > > ---
> > > >  tools/perf/Documentation/perf-ftrace.txt | 4 
> > > >  tools/perf/builtin-ftrace.c  | 2 ++
> > > >  2 files changed, 6 insertions(+)
> > > > 
> > > > diff --git a/tools/perf/Documentation/perf-ftrace.txt 
> > > > b/tools/perf/Documentation/perf-ftrace.txt
> > > > index d79560dea19f..e204bf6d50d8 100644
> > > > --- a/tools/perf/Documentation/perf-ftrace.txt
> > > > +++ b/tools/perf/Documentation/perf-ftrace.txt
> > > > @@ -38,6 +38,10 @@ OPTIONS
> > > >  --pid=::
> > > > Trace on existing process id (comma separated list).
> > > >  
> > > > +-t::
> > > > +--tid=::
> > > > +   Trace on existing thread id (comma separated list).
> > > > +  
> > > 
> > > 
> > > Humm, I just  tried:
> > > 
> > > [root@five ~]# yes > /dev/null &
> > > [1] 18265
> > > [root@five ~]# perf ftrace --tid 18265
> > > ^C[root@five ~]#
> > > 
> > > After waiting for a while, nothing, what am I doing wrong?
> > >  
> > I got it wrong. Currently ftrace only can filter by pid. If the pid is not
> > the main thread it won't work.
> 
> Wait what?
> 
> The "pid" for ftrace is really a "task id" which is a thread id.
>
My bad. I traced a sleeping thread yesterday so no event generated.

Now it works:
$ pstree -p 2378
qemu-system-x86(2378)─┬─{qemu-system-x86}(2379)
  ├─{qemu-system-x86}(2382)
  ├─{qemu-system-x86}(2385)
  ├─{qemu-system-x86}(2387)
  ├─{qemu-system-x86}(2388)
  ├─{qemu-system-x86}(2389)
  ├─{qemu-system-x86}(2390)
  ├─{qemu-system-x86}(2391)
  ├─{qemu-system-x86}(2392)
$ sudo ./perf ftrace --tid 2388
[sudo] password for changbin:
# tracer: function
#
# entries-in-buffer/entries-written: 0/0   #P:8
#
#   TASK-PID CPU#   TIMESTAMP  FUNCTION
#  | | |   | |
  -0 [001]   6561.553989: switch_mm_irqs_off <-__schedule
  -0 [001]   6561.553996: load_new_mm_cr3 <-switch_mm_irqs_off
 qemu-system-x86-2388  [001]   6561.553997: finish_task_switch <-__schedule
 qemu-system-x86-2388  [001]   6561.553998: smp_irq_work_interrupt 
<-irq_work_interrupt
 qemu-system-x86-2388  [001]   6561.553999: irq_enter <-smp_irq_work_interrupt
 qemu-system-x86-2388  [001]   6561.553999: rcu_irq_enter <-irq_enter
 qemu-system-x86-2388  [001]   6561.554000: __wake_up <-rb_wake_up_waiters
 qemu-system-x86-2388  [001]   6561.554000: __wake_up_common_lock <-__wake_up
 qemu-system-x86-2388  [001]   6561.554000: _raw_spin_lock_irqsave 
<-__wake_up_common_lock
 qemu-system-x86-2388  [001]   6561.554000: __wake_up_common 
<-__wake_up_common_lock
 ...
> [root@bxtest ~]# yes > /dev/null &
> [1] 6799
> [root@bxtest ~]# trace-cmd record -e all -P 6799
> Hit Ctrl^C to stop recording
> ^CCPU 0: 3573031 events lost
> CPU0 data recorded at offset=0x838000
> 627675136 bytes in size
> CPU1 data recorded at offset=0x25ed1000
> 0 bytes in size
> CPU2 data recorded at offset=0x25ed1000
> 0 bytes in size
> CPU3 data recorded at offset=0x25ed1000
> 0 bytes in size
> CPU4 data recorded at offset=0x25ed1000
> 0 bytes in size
> CPU5 data recorded at offset=0x25ed1000
> 0 bytes in size
> CPU6 data recorded at offset=0x25ed1000
> 0 bytes in size
> CPU7 data recorded at offset=0x25ed1000
> 0 bytes in size
> [root@bxtest ~]# trace-cmd report | head 
> CPU 1 is empty
> CPU 2 is empty
> CPU 3 is empty
> CPU 4 is empty
> CPU 5 is empty
> CPU 6 is empty
> CPU 7 is empty
> cpus=8
>  yes-6799  [000] 67825.580902: sys_exit: NR 1 = 8192
>  yes-6799  [000] 67825.580903: sys_exit_write:   0x2000
> 
> 
> What's different about tid vs pid?
> 
> -- Steve
> 
> 
> 
> > 
> > So this patch makes no sense. will drop this.
> > 

-- 
Cheers,
Changbin Du

Re: [PATCH 06/13] fs/kernel_read_file: Remove redundant size argument

[Scott Branden]

Hi Kees,

On 2020-07-17 3:06 p.m., Kees Cook wrote:

On Fri, Jul 17, 2020 at 12:04:18PM -0700, Scott Branden wrote:

On 2020-07-17 10:43 a.m., Kees Cook wrote:

In preparation for refactoring kernel_read_file*(), remove the redundant
"size" argument which is not needed: it can be included in the return

I don't think the size argument is redundant though.
The existing kernel_read_file functions always read the whole file.
Now, what happens if the file is bigger than the buffer.
How does kernel_read_file know it read the whole file by looking at the
return value?

Yes; an entirely reasonable concern. This is why I add the file_size
output argument later in the series.
There is something wrong with this patch.  I apply patches 1-5 and these 
pass the kernel self test.

Patch 6 does not pass the kernel-selftest/firmware/fw_run_tests.sh


code, with callers adjusted. (VFS reads already cannot be larger than
INT_MAX.)
[...]
-   if (i_size > SIZE_MAX || (max_size > 0 && i_size > max_size)) {
+   if (i_size > INT_MAX || (max_size > 0 && i_size > max_size)) {

Should this be SSIZE_MAX?

No, for two reasons: then we need to change the return value and likely
the callers need more careful checks, and more importantly, because the
VFS already limits single read actions to INT_MAX, so limits above this
make no sense. Win win! :)

Re: [PATCH v5 0/7] x86/boot: Remove run-time relocations from compressed kernel

[Ard Biesheuvel]

On Fri, 17 Jul 2020 at 21:17, Nick Desaulniers  wrote:
>
> On Fri, Jul 17, 2020 at 6:46 AM Arvind Sankar  wrote:
> >
> > On Tue, Jul 14, 2020 at 08:41:26PM -0400, Arvind Sankar wrote:
> > > The compressed kernel currently contains bogus run-time relocations in
> > > the startup code in head_{32,64}.S, which are generated by the linker,
> > > but must not actually be processed at run-time.
> > >
> > > This generates warnings when linking with the BFD linker, and errors
> > > with LLD, which defaults to erroring on run-time relocations in read-only
> > > sections. It also requires the -z noreloc-overflow hack for the 64-bit
> > > kernel, which prevents us from linking it as -pie on an older BFD linker
> > > (<= 2.26) or on LLD, because the locations that are to be apparently
> > > relocated are only 32-bits in size and so cannot really have
> > > R_X86_64_RELATIVE relocations.
> > >
> > > This series aims to get rid of these relocations. I've build- and
> > > boot-tested with combinations of clang/gcc-10 with lld/bfd-2.34, and
> > > gcc-4.9.0 with bfd-2.24, skipping clang on 32-bit because it currently
> > > has other issues [0].
> > >
> >
> > Hi Thomas, Ingo, Borislav, would you be able to take a look over this
> > series in time for 5.9?
>
> Hi Arvind, thanks for the series; I'm behind on testing.  When I try
> to apply this series on top of linux-next, I get a collision in
> drivers/firmware/efi/libstub/Makefile:27 when applying "0002
> x86/boot/compressed: Force hidden visibility for all symbol
> references". Would you mind refreshing the series to avoid that
> collision?

That is not the right way to deal with conflicts against -next.

This series targets the -tip tree, and applies fine against it. If you
want to apply it on some other tree and test it, that is fine, and
highly appreciated, but 'refreshing' the series against -next means it
no longer applies to -tip, and may be based on unidentified conflict
resolutions performed by Stephen that the maintainers will have to
deal with.

Boris, Ingo, Thomas,

Mind taking v5 of this series? (With Nick's Tested-by) I think these
patches have been simmering long enough. Do note there is a conflict
against the kbuild tree, but the resolution should be straightforward.

[PATCH] arm64: dts: meson: update spifc node name on Khadas VIM3/VIM3L

[Christian Hewitt]

The VIM3/VIM3L Boards use w25q128 not w25q32 - this is a cosmetic change
only - the device probes fine with the current device-tree.

Fixes: 0e1610e726d3 ("arm64: dts: khadas-vim3: add SPIFC controller node")
Signed-off-by: Christian Hewitt 
---
 arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
index 27408c10a811..6b75157265e1 100644
--- a/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
@@ -360,7 +360,7 @@
pinctrl-0 = <_pins>;
pinctrl-names = "default";
 
-   w25q32: spi-flash@0 {
+   w25q128: spi-flash@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "winbond,w25q128fw", "jedec,spi-nor";
-- 
2.17.1

[PATCH] arm64: dts: meson: fix mmc0 tuning error on Khadas VIM3

[Christian Hewitt]

Similar to other G12B devices using the W400 dtsi, I see reports of mmc0
tuning errors on VIM3 after a few hours uptime:

[12483.917391] mmc0: tuning execution failed: -5
[30535.551221] mmc0: tuning execution failed: -5
[35359.953671] mmc0: tuning execution failed: -5
[35561.875332] mmc0: tuning execution failed: -5
[61733.348709] mmc0: tuning execution failed: -5

I do not see the same on VIM3L, so remove sd-uhs-sdr50 from the common dtsi
to silence the error, then (re)add it to the VIM3L dts.

Signed-off-by: Chrisitan Hewitt 
---
 arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi | 1 -
 arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts | 4 
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
index 27408c10a811..ddfd52b88002 100644
--- a/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
@@ -293,7 +293,6 @@
 
bus-width = <4>;
cap-sd-highspeed;
-   sd-uhs-sdr50;
max-frequency = <1>;
 
non-removable;
diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts 
b/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts
index dbbf29a0dbf6..026b21708b07 100644
--- a/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts
@@ -88,6 +88,10 @@
status = "okay";
 };
 
+_emmc_a {
+   sd-uhs-sdr50;
+};
+
  {
phys = <_phy0>, <_phy1>;
phy-names = "usb2-phy0", "usb2-phy1";
-- 
2.17.1

[PATCH] nfc: s3fwrn5: add missing release on skb in s3fwrn5_recv_frame

[Navid Emamdoost]

The implementation of s3fwrn5_recv_frame() is supposed to consume skb on
all execution paths. Release skb before returning -ENODEV.

Signed-off-by: Navid Emamdoost 
---
 drivers/nfc/s3fwrn5/core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/nfc/s3fwrn5/core.c b/drivers/nfc/s3fwrn5/core.c
index 91d4d5b28a7d..ba6c486d6465 100644
--- a/drivers/nfc/s3fwrn5/core.c
+++ b/drivers/nfc/s3fwrn5/core.c
@@ -198,6 +198,7 @@ int s3fwrn5_recv_frame(struct nci_dev *ndev, struct sk_buff 
*skb,
case S3FWRN5_MODE_FW:
return s3fwrn5_fw_recv_frame(ndev, skb);
default:
+   kfree_skb(skb);
return -ENODEV;
}
 }
-- 
2.17.1

[PATCH] arm64: dts: meson: misc fixups for w400 dtsi

[Christian Hewitt]

Current devices using the W400 dtsi show mmc tuning errors:

[12483.917391] mmc0: tuning execution failed: -5
[30535.551221] mmc0: tuning execution failed: -5
[35359.953671] mmc0: tuning execution failed: -5
[35561.875332] mmc0: tuning execution failed: -5
[61733.348709] mmc0: tuning execution failed: -5

Removing "sd-uhs-sdr50" from the SDIO node prevents this. We also add
keep-power-in-suspend to the SDIO node and fix an indentation.

Signed-off-by: Christian Hewitt 
---
 arch/arm64/boot/dts/amlogic/meson-g12b-w400.dtsi | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-w400.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-g12b-w400.dtsi
index 98b70d216a6f..2802ddbb83ac 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-w400.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-w400.dtsi
@@ -336,9 +336,11 @@
 
bus-width = <4>;
cap-sd-highspeed;
-   sd-uhs-sdr50;
max-frequency = <1>;
 
+   /* WiFi firmware requires power to be kept while in suspend */
+   keep-power-in-suspend;
+
non-removable;
disable-wp;
 
@@ -398,7 +400,7 @@
shutdown-gpios = < GPIOX_17 GPIO_ACTIVE_HIGH>;
max-speed = <200>;
clocks = <>;
-   clock-names = "lpo";
+   clock-names = "lpo";
};
 };
 
-- 
2.17.1

Re: [PATCH] tools/memory-model: document the "one-time init" pattern

[Eric Biggers]

On Sat, Jul 18, 2020 at 03:13:04AM +0100, Matthew Wilcox wrote:
> On Fri, Jul 17, 2020 at 06:38:39PM -0700, Eric Biggers wrote:
> > On Fri, Jul 17, 2020 at 06:47:50PM +0100, Matthew Wilcox wrote:
> > > On Thu, Jul 16, 2020 at 09:44:27PM -0700, Eric Biggers wrote:
> > > > +If that doesn't apply, you'll have to implement one-time init yourself.
> > > > +
> > > > +The simplest implementation just uses a mutex and an 'inited' flag.
> > > > +This implementation should be used where feasible:
> > > 
> > > I think some syntactic sugar should make it feasible for normal people
> > > to implement the most efficient version of this just like they use locks.
> > 
> > Note that the cmpxchg version is not necessarily the "most efficient".
> > 
> > If the one-time initialization is expensive, e.g. if it allocates a lot of
> > memory or if takes a long time, it could be better to use the mutex version 
> > so
> > that at most one task does it.
> 
> Sure, but I think those are far less common than just allocating a single
> thing.
> 
> > > How about something like this ...
> > > 
> > > once.h:
> > > 
> > > static struct init_once_pointer {
> > >   void *p;
> > > };
> > > 
> > > static inline void *once_get(struct init_once_pointer *oncep)
> > > { ... }
> > > 
> > > static inline bool once_store(struct init_once_pointer *oncep, void *p)
> > > { ... }
> > > 
> > > --- foo.c ---
> > > 
> > > struct foo *get_foo(gfp_t gfp)
> > > {
> > >   static struct init_once_pointer my_foo;
> > >   struct foo *foop;
> > > 
> > >   foop = once_get(_foo);
> > >   if (foop)
> > >   return foop;
> > > 
> > >   foop = alloc_foo(gfp);
> > >   if (!once_store(_foo, foop)) {
> > >   free_foo(foop);
> > >   foop = once_get(_foo);
> > >   }
> > > 
> > >   return foop;
> > > }
> > > 
> > > Any kernel programmer should be able to handle that pattern.  And no 
> > > mutex!
> > 
> > I don't think this version would be worthwhile.  It eliminates type safety 
> > due
> > to the use of 'void *', and doesn't actually save any lines of code.  Nor 
> > does
> > it eliminate the need to correctly implement the cmpxchg failure case, 
> > which is
> > tricky (it must free the object and get the new one) and will be rarely 
> > tested.
> 
> You're missing the point.  It prevents people from trying to optimise
> "can I use READ_ONCE() here, or do I need to use smp_rmb()?"  The type
> safety is provided by the get_foo() function.  I suppose somebody could
> play some games with _Generic or something, but there's really no need to.
> It's like using a list_head and casting to the container_of.
> 
> > It also forces all users of the struct to use this helper function to 
> > access it.
> > That could be considered a good thing, but it's also bad because even with
> > one-time init there's still usually some sort of ordering of 
> > "initialization"
> > vs. "use".  Just taking a random example I'm familiar with, we do one-time 
> > init
> > of inode::i_crypt_info when we open an encrypted file, so we guarantee it's 
> > set
> > for all I/O to the file, where we then simply access ->i_crypt_info 
> > directly.
> > We don't want the code to read like it's initializing ->i_crypt_info in the
> > middle of ->writepages(), since that would be wrong.
> 
> Right, and I wouldn't use this pattern for that.  You can't get to
> writepages without having opened the file, so just initialising the
> pointer in open is fine.
> 
> > An improvement might be to make once_store() take the free function as a
> > parameter so that it would handle the failure case for you:
> > 
> > struct foo *get_foo(gfp_t gfp)
> > {
> > static struct init_once_pointer my_foo;
> > struct foo *foop;
> >  
> > foop = once_get(_foo);
> > if (!foop) {
> > foop = alloc_foo(gfp);
> > if (foop)
> > once_store(_foo, foop, free_foo);
> 
> Need to mark once_store as __must_check to avoid the bug you have here:
> 
>   foop = once_store(_foo, foop, free_foo);
> 
> Maybe we could use a macro for once_store so we could write:
> 
> void *once_get(struct init_pointer_once *);
> int once_store(struct init_pointer_once *, void *);
> 
> #define once_alloc(s, o_alloc, o_free) ({   \
> void *__p = o_alloc;\
> if (__p) {  \
> if (!once_store(s, __p)) {  \
> o_free(__p);\
> __p = once_get(s);  \
> }   \
> }   \
> __p;\
> })
> 
> ---
> 
> struct foo *alloc_foo(gfp_t);
> void free_foo(struct foo *);
> 
> struct foo *get_foo(gfp_t gfp)
> 

[tip:x86/platform] BUILD SUCCESS 3bcf25a40b018e632d70bb866d75746748953fbc

[kernel test robot]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git  
x86/platform
branch HEAD: 3bcf25a40b018e632d70bb866d75746748953fbc  x86/efi: Remove unused 
EFI_UV1_MEMMAP code

elapsed time: 720m

configs tested: 101
configs skipped: 80

The following configs have been built successfully.
More configs may be tested in the coming days.

arm defconfig
arm  allyesconfig
arm  allmodconfig
arm   allnoconfig
arm64allyesconfig
arm64   defconfig
arm64allmodconfig
arm64 allnoconfig
arm   corgi_defconfig
shedosk7760_defconfig
mipsomega2p_defconfig
powerpc  storcenter_defconfig
arm   tegra_defconfig
ia64  tiger_defconfig
mipsjmr3927_defconfig
armxcep_defconfig
i386  allnoconfig
i386 allyesconfig
i386defconfig
i386  debian-10.3
ia64 allmodconfig
ia64defconfig
ia64  allnoconfig
ia64 allyesconfig
nios2   defconfig
nios2allyesconfig
openriscdefconfig
c6x  allyesconfig
c6x   allnoconfig
openrisc allyesconfig
nds32   defconfig
nds32 allnoconfig
csky allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
h8300allmodconfig
xtensa  defconfig
arc defconfig
arc  allyesconfig
sh   allmodconfig
shallnoconfig
microblazeallnoconfig
mips allyesconfig
mips  allnoconfig
mips allmodconfig
pariscallnoconfig
parisc  defconfig
parisc   allyesconfig
parisc   allmodconfig
powerpc  allyesconfig
powerpc  rhel-kconfig
powerpc  allmodconfig
powerpc   allnoconfig
powerpc defconfig
i386 randconfig-a001-20200717
i386 randconfig-a005-20200717
i386 randconfig-a002-20200717
i386 randconfig-a006-20200717
i386 randconfig-a003-20200717
i386 randconfig-a004-20200717
x86_64   randconfig-a012-20200716
x86_64   randconfig-a011-20200716
x86_64   randconfig-a016-20200716
x86_64   randconfig-a014-20200716
x86_64   randconfig-a013-20200716
x86_64   randconfig-a015-20200716
x86_64   randconfig-a005-20200717
x86_64   randconfig-a006-20200717
x86_64   randconfig-a002-20200717
x86_64   randconfig-a001-20200717
x86_64   randconfig-a003-20200717
x86_64   randconfig-a004-20200717
i386 randconfig-a016-20200717
i386 randconfig-a011-20200717
i386 randconfig-a015-20200717
i386 randconfig-a012-20200717
i386 randconfig-a013-20200717
i386 randconfig-a014-20200717
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscvallmodconfig
s390 allyesconfig
s390  allnoconfig
s390 allmodconfig
s390defconfig
sparcallyesconfig
sparc   defconfig
sparc64 defconfig
sparc64   allnoconfig
sparc64  allyesconfig
sparc64  allmodconfig
x86_64rhel-7.6-kselftests
x86_64   rhel-8.3
x86_64  kexec
x86_64   rhel
x86_64lkp
x86_64  fedora-25

[PATCH] mt7601u: add missing release on skb in mt7601u_mcu_msg_send

[Navid Emamdoost]

In the implementation of mt7601u_mcu_msg_send(), skb is supposed to be
consumed on all execution paths. Release skb before returning if
test_bit() fails.

Signed-off-by: Navid Emamdoost 
---
 drivers/net/wireless/mediatek/mt7601u/mcu.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt7601u/mcu.c 
b/drivers/net/wireless/mediatek/mt7601u/mcu.c
index af55ed82b96f..1b5cc271a9e1 100644
--- a/drivers/net/wireless/mediatek/mt7601u/mcu.c
+++ b/drivers/net/wireless/mediatek/mt7601u/mcu.c
@@ -116,8 +116,10 @@ mt7601u_mcu_msg_send(struct mt7601u_dev *dev, struct 
sk_buff *skb,
int sent, ret;
u8 seq = 0;
 
-   if (test_bit(MT7601U_STATE_REMOVED, >state))
+   if (test_bit(MT7601U_STATE_REMOVED, >state)) {
+   consume_skb(skb);
return 0;
+   }
 
mutex_lock(>mcu.mutex);
 
-- 
2.17.1

[PATCH 2/2] arm64: dts: meson: add initial Beelink GS-King-X device-tree

[Christian Hewitt]

The Shenzen AZW (Beelink) GS-King-X is based on the Amlogic W400 reference
board with an S922X-H chip.

- 4GB LPDDR4 RAM
- 64GB eMMC storage
- 10/100/1000 Base-T Ethernet
- AP6356S Wireless (802.11 a/b/g/n/ac, BT 4.1)
- HDMI 2.1 video
- S/PDIF optical output
- 2x ESS9018 audio DACs
- 4x Ricor RT6862 audio amps
- Analogue headphone output
- 1x USB 2.0 OTG port
- 3x USB 3.0 ports
- IR receiver
- 1x micro SD card slot (internal)
- USB SATA controller with 2x 3.5" drive bays
- 1x Power on/off button

Signed-off-by: Christian Hewitt 
---
 arch/arm64/boot/dts/amlogic/Makefile  |   1 +
 .../boot/dts/amlogic/meson-g12b-gsking-x.dts  | 170 ++
 2 files changed, 171 insertions(+)
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12b-gsking-x.dts

diff --git a/arch/arm64/boot/dts/amlogic/Makefile 
b/arch/arm64/boot/dts/amlogic/Makefile
index 5cac4d1d487d..99a6e8e0b644 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -3,6 +3,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-axg-s400.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-g12a-sei510.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-g12a-u200.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-g12a-x96-max.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-g12b-gsking-x.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-g12b-gtking.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-g12b-gtking-pro.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-g12b-a311d-khadas-vim3.dtb
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-gsking-x.dts 
b/arch/arm64/boot/dts/amlogic/meson-g12b-gsking-x.dts
new file mode 100644
index ..60b681d6cfe3
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-gsking-x.dts
@@ -0,0 +1,170 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre, SAS
+ * Author: Neil Armstrong 
+ * Copyright (c) 2019 Christian Hewitt 
+ */
+
+/dts-v1/;
+
+#include "meson-g12b-w400.dtsi"
+#include 
+#include 
+
+/ {
+   compatible = "azw,gsking-x", "amlogic,g12b";
+   model = "Beelink GS-King X";
+
+   gpio-keys-polled {
+   compatible = "gpio-keys-polled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   poll-interval = <100>;
+
+   power-button {
+   label = "power";
+   linux,code = ;
+   gpios = <_ao GPIOAO_3 GPIO_ACTIVE_HIGH>;
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   blue {
+   color = ;
+   function = LED_FUNCTION_STATUS;
+   gpios = <_ao GPIOAO_11 GPIO_ACTIVE_HIGH>;
+   default-state = "on";
+   };
+   };
+
+   spdif_dit: audio-codec-1 {
+   #sound-dai-cells = <0>;
+   compatible = "linux,spdif-dit";
+   status = "okay";
+   sound-name-prefix = "DIT";
+   };
+
+   sound {
+   compatible = "amlogic,axg-sound-card";
+   model = "G12B-GSKING-X";
+   audio-aux-devs = <_b>;
+   audio-routing = "TDMOUT_B IN 0", "FRDDR_A OUT 1",
+   "TDMOUT_B IN 1", "FRDDR_B OUT 1",
+   "TDMOUT_B IN 2", "FRDDR_C OUT 1",
+   "TDM_B Playback", "TDMOUT_B OUT",
+   "SPDIFOUT IN 0", "FRDDR_A OUT 3",
+   "SPDIFOUT IN 1", "FRDDR_B OUT 3",
+   "SPDIFOUT IN 2", "FRDDR_C OUT 3";
+
+   assigned-clocks = < CLKID_MPLL2>,
+ < CLKID_MPLL0>,
+ < CLKID_MPLL1>;
+   assigned-clock-parents = <0>, <0>, <0>;
+   assigned-clock-rates = <294912000>,
+  <270950400>,
+  <393216000>;
+   status = "okay";
+
+   dai-link-0 {
+   sound-dai = <_a>;
+   };
+
+   dai-link-1 {
+   sound-dai = <_b>;
+   };
+
+   dai-link-2 {
+   sound-dai = <_c>;
+   };
+
+   /* 8ch hdmi interface */
+   dai-link-3 {
+   sound-dai = <_b>;
+   dai-format = "i2s";
+   dai-tdm-slot-tx-mask-0 = <1 1>;
+   dai-tdm-slot-tx-mask-1 = <1 1>;
+   dai-tdm-slot-tx-mask-2 = <1 1>;
+   dai-tdm-slot-tx-mask-3 = <1 1>;
+   mclk-fs = <256>;
+
+   codec {
+   sound-dai = < TOHDMITX_I2S_IN_B>;
+   };
+   };
+
+   /* spdif hdmi or toslink interface */
+   dai-link-4 {
+   sound-dai = <>;
+
+   codec-0 {
+   

[PATCH 1/2] dt-bindings: arm: amlogic: add support for the Beelink GS-King-X

[Christian Hewitt]

The Shenzen AZW (Beelink) GS-King-X is based on the Amlogic W400 reference
board with an S922X-H chip.

Signed-off-by: Christian Hewitt 
---
 Documentation/devicetree/bindings/arm/amlogic.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml 
b/Documentation/devicetree/bindings/arm/amlogic.yaml
index 378229fa8310..8711fa57ee25 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -149,6 +149,7 @@ properties:
   - description: Boards with the Amlogic Meson G12B S922X SoC
 items:
   - enum:
+  - azw,gsking-x
   - azw,gtking
   - azw,gtking-pro
   - hardkernel,odroid-n2
-- 
2.17.1

[PATCH] cxgb4: add missing release on skb in uld_send()

[Navid Emamdoost]

In the implementation of uld_send(), the skb is consumed on all
execution paths except one. Release skb when returning NET_XMIT_DROP.

Signed-off-by: Navid Emamdoost 
---
 drivers/net/ethernet/chelsio/cxgb4/sge.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c 
b/drivers/net/ethernet/chelsio/cxgb4/sge.c
index 32a45dc51ed7..d8c37fd4b808 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c
@@ -2938,6 +2938,7 @@ static inline int uld_send(struct adapter *adap, struct 
sk_buff *skb,
txq_info = adap->sge.uld_txq_info[tx_uld_type];
if (unlikely(!txq_info)) {
WARN_ON(true);
+   consume_skb(skb);
return NET_XMIT_DROP;
}
 
-- 
2.17.1

[PATCH 1/3] media: rkvdec: Fix H264 scaling list order

[Mauro Carvalho Chehab]

From: Jonas Karlman 

The Rockchip Video Decoder driver is expecting that the values in a
scaling list are in zig-zag order and applies the inverse scanning process
to get the values in matrix order.

Commit 0b0393d59eb4 ("media: uapi: h264: clarify expected
scaling_list_4x4/8x8 order") clarified that the values in the scaling list
should already be in matrix order.

Fix this by removing the reordering and change to use two memcpy.

Fixes: cd33c830448b ("media: rkvdec: Add the rkvdec driver")
Signed-off-by: Jonas Karlman 
Tested-by: Nicolas Dufresne 
Reviewed-by: Ezequiel Garcia 
[hverkuil-ci...@xs4all.nl: rkvdec_scaling_matrix -> rkvdec_h264_scaling_list]
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/staging/media/rkvdec/rkvdec-h264.c | 66 +++---
 1 file changed, 20 insertions(+), 46 deletions(-)

diff --git a/drivers/staging/media/rkvdec/rkvdec-h264.c 
b/drivers/staging/media/rkvdec/rkvdec-h264.c
index cd4980d06be7..7b66e2743a4f 100644
--- a/drivers/staging/media/rkvdec/rkvdec-h264.c
+++ b/drivers/staging/media/rkvdec/rkvdec-h264.c
@@ -18,11 +18,16 @@
 /* Size with u32 units. */
 #define RKV_CABAC_INIT_BUFFER_SIZE (3680 + 128)
 #define RKV_RPS_SIZE   ((128 + 128) / 4)
-#define RKV_SCALING_LIST_SIZE  (6 * 16 + 6 * 64 + 128)
 #define RKV_ERROR_INFO_SIZE(256 * 144 * 4)
 
 #define RKVDEC_NUM_REFLIST 3
 
+struct rkvdec_h264_scaling_list {
+   u8 scaling_list_4x4[6][16];
+   u8 scaling_list_8x8[6][64];
+   u8 padding[128];
+};
+
 struct rkvdec_sps_pps_packet {
u32 info[8];
 };
@@ -86,7 +91,7 @@ struct rkvdec_ps_field {
 /* Data structure describing auxiliary buffer format. */
 struct rkvdec_h264_priv_tbl {
s8 cabac_table[4][464][2];
-   u8 scaling_list[RKV_SCALING_LIST_SIZE];
+   struct rkvdec_h264_scaling_list scaling_list;
u32 rps[RKV_RPS_SIZE];
struct rkvdec_sps_pps_packet param_set[256];
u8 err_info[RKV_ERROR_INFO_SIZE];
@@ -785,56 +790,25 @@ static void assemble_hw_rps(struct rkvdec_ctx *ctx,
}
 }
 
-/*
- * NOTE: The values in a scaling list are in zig-zag order, apply inverse
- * scanning process to get the values in matrix order.
- */
-static const u32 zig_zag_4x4[16] = {
-   0, 1, 4, 8, 5, 2, 3, 6, 9, 12, 13, 10, 7, 11, 14, 15
-};
-
-static const u32 zig_zag_8x8[64] = {
-   0,  1,  8, 16,  9,  2,  3, 10, 17, 24, 32, 25, 18, 11,  4,  5,
-   12, 19, 26, 33, 40, 48, 41, 34, 27, 20, 13,  6,  7, 14, 21, 28,
-   35, 42, 49, 56, 57, 50, 43, 36, 29, 22, 15, 23, 30, 37, 44, 51,
-   58, 59, 52, 45, 38, 31, 39, 46, 53, 60, 61, 54, 47, 55, 62, 63
-};
-
-static void reorder_scaling_list(struct rkvdec_ctx *ctx,
-struct rkvdec_h264_run *run)
+static void assemble_hw_scaling_list(struct rkvdec_ctx *ctx,
+struct rkvdec_h264_run *run)
 {
const struct v4l2_ctrl_h264_scaling_matrix *scaling = 
run->scaling_matrix;
-   const size_t num_list_4x4 = ARRAY_SIZE(scaling->scaling_list_4x4);
-   const size_t list_len_4x4 = ARRAY_SIZE(scaling->scaling_list_4x4[0]);
-   const size_t num_list_8x8 = ARRAY_SIZE(scaling->scaling_list_8x8);
-   const size_t list_len_8x8 = ARRAY_SIZE(scaling->scaling_list_8x8[0]);
struct rkvdec_h264_ctx *h264_ctx = ctx->priv;
struct rkvdec_h264_priv_tbl *tbl = h264_ctx->priv_tbl.cpu;
-   u8 *dst = tbl->scaling_list;
-   const u8 *src;
-   int i, j;
 
-   BUILD_BUG_ON(ARRAY_SIZE(zig_zag_4x4) != list_len_4x4);
-   BUILD_BUG_ON(ARRAY_SIZE(zig_zag_8x8) != list_len_8x8);
-   BUILD_BUG_ON(ARRAY_SIZE(tbl->scaling_list) <
-num_list_4x4 * list_len_4x4 +
-num_list_8x8 * list_len_8x8);
+   BUILD_BUG_ON(sizeof(tbl->scaling_list.scaling_list_4x4) !=
+sizeof(scaling->scaling_list_4x4));
+   BUILD_BUG_ON(sizeof(tbl->scaling_list.scaling_list_8x8) !=
+sizeof(scaling->scaling_list_8x8));
 
-   src = >scaling_list_4x4[0][0];
-   for (i = 0; i < num_list_4x4; ++i) {
-   for (j = 0; j < list_len_4x4; ++j)
-   dst[zig_zag_4x4[j]] = src[j];
-   src += list_len_4x4;
-   dst += list_len_4x4;
-   }
+   memcpy(tbl->scaling_list.scaling_list_4x4,
+  scaling->scaling_list_4x4,
+  sizeof(scaling->scaling_list_4x4));
 
-   src = >scaling_list_8x8[0][0];
-   for (i = 0; i < num_list_8x8; ++i) {
-   for (j = 0; j < list_len_8x8; ++j)
-   dst[zig_zag_8x8[j]] = src[j];
-   src += list_len_8x8;
-   dst += list_len_8x8;
-   }
+   memcpy(tbl->scaling_list.scaling_list_8x8,
+  scaling->scaling_list_8x8,
+  sizeof(scaling->scaling_list_8x8));
 }
 
 /*
@@ -1126,7 +1100,7 @@ static int rkvdec_h264_run(struct rkvdec_ctx *ctx)

Re: [PATCH RFC V2 12/17] memremap: Add zone device access protection

[Ira Weiny]

On Fri, Jul 17, 2020 at 11:10:53AM +0200, Peter Zijlstra wrote:
> On Fri, Jul 17, 2020 at 12:20:51AM -0700, ira.we...@intel.com wrote:
> > +static pgprot_t dev_protection_enable_get(struct dev_pagemap *pgmap, 
> > pgprot_t prot)
> > +{
> > +   if (pgmap->flags & PGMAP_PROT_ENABLED && dev_page_pkey != PKEY_INVALID) 
> > {
> > +   pgprotval_t val = pgprot_val(prot);
> > +
> > +   static_branch_inc(_protection_static_key);
> > +   prot = __pgprot(val | _PAGE_PKEY(dev_page_pkey));
> > +   }
> > +   return prot;
> > +}
> 
> Every other pgprot modifying function is called pgprot_*(), although I
> suppose we have the exceptions phys_mem_access_prot() and dma_pgprot().

Yea...  this function kind of morphed.  The issue is that this is also a 'get'
with a corresponding 'put'.  So I'm at a loss for what makes sense between the
2 functions.

> 
> How about we call this one devm_pgprot() ?

Dan Williams mentioned to me that the devm is not an appropriate prefix.  Thus
the 'dev' prefix instead.

How about dev_pgprot_{get,put}()?

Ira

[PATCH 2/3] media: atomisp: fix the handling of clock number

[Mauro Carvalho Chehab]

Right now, the driver is not doing the right thing to detect
the clock like used by the sensor, at least on devices
without the gmin's EFI vars.

Add some notes at the code to explain why and skip the wrong
value provided by the _DSM table.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../media/atomisp/pci/atomisp_gmin_platform.c | 49 ---
 1 file changed, 42 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
index 1af9da8acf4c..cb360b8399e5 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
@@ -26,6 +26,9 @@ enum clock_rate {
 #define CLK_RATE_19_2MHZ   1920
 #define CLK_RATE_25_0MHZ   2500
 
+/* Valid clock number range from 0 to 5 */
+#define MAX_CLK_COUNT   5
+
 /* X-Powers AXP288 register set */
 #define ALDO1_SEL_REG  0x28
 #define ALDO1_CTRL3_REG0x13
@@ -61,7 +64,6 @@ enum clock_rate {
 
 struct gmin_subdev {
struct v4l2_subdev *subdev;
-   int clock_num;
enum clock_rate clock_src;
bool clock_on;
struct clk *pmc_clk;
@@ -447,7 +449,7 @@ static struct gmin_subdev *gmin_subdev_add(struct 
v4l2_subdev *subdev)
struct acpi_device *adev;
acpi_handle handle;
struct device *dev;
-   int i, ret;
+   int i, ret, clock_num;
 
if (!client)
return NULL;
@@ -492,17 +494,37 @@ static struct gmin_subdev *gmin_subdev_add(struct 
v4l2_subdev *subdev)
}
 
gmin_subdevs[i].subdev = subdev;
-   gmin_subdevs[i].clock_num = gmin_get_var_int(dev, false, "CamClk", 0);
+
/*WA:CHT requires XTAL clock as PLL is not stable.*/
gmin_subdevs[i].clock_src = gmin_get_var_int(dev, false, "ClkSrc",
VLV2_CLK_PLL_19P2MHZ);
gmin_subdevs[i].csi_port = gmin_get_var_int(dev, false, "CsiPort", 0);
gmin_subdevs[i].csi_lanes = gmin_get_var_int(dev, false, "CsiLanes", 1);
 
-   /* get PMC clock with clock framework */
-   snprintf(gmin_pmc_clk_name,
-sizeof(gmin_pmc_clk_name),
-"%s_%d", "pmc_plt_clk", gmin_subdevs[i].clock_num);
+   /*
+* FIXME:
+*
+* According with :
+*   
https://github.com/projectceladon/hardware-intel-kernelflinger/blob/master/doc/fastboot.md
+*
+* The "CamClk" EFI var is set via fastboot on some Android devices,
+* and seems to contain the number of the clock used to feed the
+* sensor.
+*
+* On systems with a proper ACPI table, this is given via the _PR0
+* power resource table. The logic below should first check if there
+* is a power resource already, falling back to the EFI vars detection
+* otherwise.
+*/
+   clock_num = gmin_get_var_int(dev, false, "CamClk", -1);
+
+   if (clock_num < 0 || clock_num > MAX_CLK_COUNT) {
+   dev_err(dev, "Invalid clock number\n");
+   return NULL;
+   }
+
+   snprintf(gmin_pmc_clk_name, sizeof(gmin_pmc_clk_name),
+"%s_%d", "pmc_plt_clk", clock_num);
 
gmin_subdevs[i].pmc_clk = devm_clk_get(dev, gmin_pmc_clk_name);
if (IS_ERR(gmin_subdevs[i].pmc_clk)) {
@@ -515,6 +537,7 @@ static struct gmin_subdev *gmin_subdev_add(struct 
v4l2_subdev *subdev)
 
return NULL;
}
+   dev_info(dev, "Will use CLK%d (%s)\n", clock_num, gmin_pmc_clk_name);
 
/*
 * The firmware might enable the clock at
@@ -957,6 +980,18 @@ static int gmin_get_config_dsm_var(struct device *dev,
union acpi_object *obj, *cur = NULL;
int i;
 
+   /*
+* The data reported by "CamClk" seems to be either 0 or 1 at the
+* _DSM table.
+*
+* At the ACPI tables we looked so far, this is not related to the
+* actual clock source for the sensor, which is given by the
+* _PR0 ACPI table. So, ignore it, as otherwise this will be
+* set to a wrong value.
+*/
+   if (!strcmp(var, "CamClk"))
+   return -EINVAL;
+
obj = acpi_evaluate_dsm(handle, _dsm_guid, 0, 0, NULL);
if (!obj) {
dev_info_once(dev, "Didn't find ACPI _DSM table.\n");
-- 
2.26.2

[PATCH 3/3] media: atomisp: reorganize the code under gmin_subdev_add()

[Mauro Carvalho Chehab]

The gmin_subdev_add() currently doesn't use ACPI device
power management. In order to prepare for adding support
for it, let's shift some things, placing the PM-related
stuff at the end of the probing logic.

Let's also store the current gs on a temporary var, in
order to simplify the source code.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../media/atomisp/pci/atomisp_gmin_platform.c | 119 +-
 1 file changed, 60 insertions(+), 59 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
index cb360b8399e5..81d89d8c549a 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
@@ -447,6 +447,7 @@ static struct gmin_subdev *gmin_subdev_add(struct 
v4l2_subdev *subdev)
 {
struct i2c_client *power = NULL, *client = v4l2_get_subdevdata(subdev);
struct acpi_device *adev;
+   struct gmin_subdev *gs;
acpi_handle handle;
struct device *dev;
int i, ret, clock_num;
@@ -457,16 +458,39 @@ static struct gmin_subdev *gmin_subdev_add(struct 
v4l2_subdev *subdev)
dev = >dev;
 
handle = ACPI_HANDLE(dev);
-
-   // FIXME: may need to release resources allocated by 
acpi_bus_get_device()
-   if (!handle || acpi_bus_get_device(handle, )) {
-   dev_err(dev, "Error could not get ACPI device\n");
-   return NULL;
-   }
+   adev = ACPI_COMPANION(>dev);
 
dev_info(>dev, "%s: ACPI detected it on bus ID=%s, HID=%s\n",
__func__, acpi_device_bid(adev), acpi_device_hid(adev));
 
+   for (i = 0; i < MAX_SUBDEVS && gmin_subdevs[i].subdev; i++)
+   ;
+   if (i >= MAX_SUBDEVS)
+   return NULL;
+
+   gs = _subdevs[i];
+   gs->subdev = subdev;
+
+   /*WA:CHT requires XTAL clock as PLL is not stable.*/
+   gmin_subdevs[i].clock_src = gmin_get_var_int(dev, false, "ClkSrc",
+   VLV2_CLK_PLL_19P2MHZ);
+
+   gs->csi_port = gmin_get_var_int(dev, false, "CsiPort", 0);
+   gs->csi_lanes = gmin_get_var_int(dev, false, "CsiLanes", 1);
+
+   gs->gpio0 = gpiod_get_index(dev, NULL, 0, GPIOD_OUT_LOW);
+   if (IS_ERR(gs->gpio0))
+   gs->gpio0 = NULL;
+
+   gs->gpio1 = gpiod_get_index(dev, NULL, 1, GPIOD_OUT_LOW);
+   if (IS_ERR(gs->gpio1))
+   gs->gpio1 = NULL;
+
+   /*
+* FIXME: the code below doesn't rely on ACPI device_pm.c code to
+* set clocks and do power management.
+*/
+
if (!pmic_id) {
if (gmin_i2c_dev_exists(dev, PMIC_ACPI_TI, ))
pmic_id = PMIC_TI;
@@ -478,13 +502,8 @@ static struct gmin_subdev *gmin_subdev_add(struct 
v4l2_subdev *subdev)
pmic_id = PMIC_REGULATOR;
}
 
-   for (i = 0; i < MAX_SUBDEVS && gmin_subdevs[i].subdev; i++)
-   ;
-   if (i >= MAX_SUBDEVS)
-   return NULL;
-
if (power) {
-   gmin_subdevs[i].pwm_i2c_addr = power->addr;
+   gs->pwm_i2c_addr = power->addr;
dev_info(dev,
 "gmin: power management provided via %s (i2c addr 
0x%02x)\n",
 pmic_name[pmic_id], power->addr);
@@ -493,17 +512,7 @@ static struct gmin_subdev *gmin_subdev_add(struct 
v4l2_subdev *subdev)
 pmic_name[pmic_id]);
}
 
-   gmin_subdevs[i].subdev = subdev;
-
-   /*WA:CHT requires XTAL clock as PLL is not stable.*/
-   gmin_subdevs[i].clock_src = gmin_get_var_int(dev, false, "ClkSrc",
-   VLV2_CLK_PLL_19P2MHZ);
-   gmin_subdevs[i].csi_port = gmin_get_var_int(dev, false, "CsiPort", 0);
-   gmin_subdevs[i].csi_lanes = gmin_get_var_int(dev, false, "CsiLanes", 1);
-
/*
-* FIXME:
-*
 * According with :
 *   
https://github.com/projectceladon/hardware-intel-kernelflinger/blob/master/doc/fastboot.md
 *
@@ -526,9 +535,9 @@ static struct gmin_subdev *gmin_subdev_add(struct 
v4l2_subdev *subdev)
snprintf(gmin_pmc_clk_name, sizeof(gmin_pmc_clk_name),
 "%s_%d", "pmc_plt_clk", clock_num);
 
-   gmin_subdevs[i].pmc_clk = devm_clk_get(dev, gmin_pmc_clk_name);
-   if (IS_ERR(gmin_subdevs[i].pmc_clk)) {
-   ret = PTR_ERR(gmin_subdevs[i].pmc_clk);
+   gs->pmc_clk = devm_clk_get(dev, gmin_pmc_clk_name);
+   if (IS_ERR(gs->pmc_clk)) {
+   ret = PTR_ERR(gs->pmc_clk);
 
dev_err(dev,
"Failed to get clk from %s : %d\n",
@@ -549,25 +558,17 @@ static struct gmin_subdev *gmin_subdev_add(struct 
v4l2_subdev *subdev)
 * to disable a clock that has not been enabled,
 * we need to enable the clock first.
 */
-   ret = clk_prepare_enable(gmin_subdevs[i].pmc_clk);
+   ret = 

[PATCH 2/2] arm64: dts: meson: add support for the WeTek Core 2

[Christian Hewitt]

The WeTek Core2 is a commercial device based on the Amlogic Q200 reference
design but with the following differences:

- 3GB RAM, 32GB eMMC
- Blue and Red LEDs used to signal on/off status
- uart_AO can be accessed after opening the case; soldering required
- USB OTG is not accessible (inside the case)
- Realtek RTL8152 Ethernet (internal USB connection)

Signed-off-by: Christian Hewitt 
---
 arch/arm64/boot/dts/amlogic/Makefile  |  1 +
 .../dts/amlogic/meson-gxm-wetek-core2.dts | 90 +++
 2 files changed, 91 insertions(+)
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm-wetek-core2.dts

diff --git a/arch/arm64/boot/dts/amlogic/Makefile 
b/arch/arm64/boot/dts/amlogic/Makefile
index 5cac4d1d487d..4e2239ffcaa5 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -41,6 +41,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxm-q201.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxm-rbox-pro.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxm-s912-libretech-pc.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxm-vega-s96.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-gxm-wetek-core2.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-sm1-sei610.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-sm1-khadas-vim3l.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-sm1-odroid-c4.dtb
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-wetek-core2.dts 
b/arch/arm64/boot/dts/amlogic/meson-gxm-wetek-core2.dts
new file mode 100644
index ..44fc5ea38dc0
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-wetek-core2.dts
@@ -0,0 +1,90 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2020 Christian Hewitt 
+ */
+
+/dts-v1/;
+
+#include "meson-gxm.dtsi"
+#include "meson-gx-p23x-q20x.dtsi"
+#include 
+#include 
+
+/ {
+   compatible = "wetek,core2", "amlogic,s912", "amlogic,meson-gxm";
+   model = "WeTek Core 2";
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x0 0x0 0x8000>; /* 2 GiB or 3 GiB */
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   blue {
+   color = ;
+   function = LED_FUNCTION_STATUS;
+   gpios = < GPIODV_24 GPIO_ACTIVE_HIGH>;
+   default-state = "on";
+   };
+   };
+
+   adc-keys {
+   compatible = "adc-keys";
+   io-channels = < 0>;
+   io-channel-names = "buttons";
+   keyup-threshold-microvolt = <171>;
+
+   button-update {
+   label = "update";
+   linux,code = ;
+   press-threshold-microvolt = <1>;
+   };
+   };
+
+   gpio-keys-polled {
+   compatible = "gpio-keys-polled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   poll-interval = <100>;
+
+   button-power {
+   label = "power";
+   linux,code = ;
+   gpios = <_ao GPIOAO_2 GPIO_ACTIVE_LOW>;
+   };
+   };
+};
+
+/* This is disabled as Realtek RTL8152 USB provides Ethernet */
+ {
+   status = "disabled";
+   phy-mode = "rmii";
+   phy-handle = <_phy>;
+};
+
+_phy {
+   pinctrl-0 = <_link_led_pins>, <_act_led_pins>;
+   pinctrl-names = "default";
+};
+
+ {
+   linux,rc-map-name = "rc-wetek-play2";
+};
+
+/* This is connected to the Bluetooth module: */
+_A {
+   status = "okay";
+   pinctrl-0 = <_a_pins>, <_a_cts_rts_pins>;
+   pinctrl-names = "default";
+   uart-has-rtscts;
+
+   bluetooth {
+   compatible = "brcm,bcm43438-bt";
+   enable-gpios = < GPIOX_17 GPIO_ACTIVE_HIGH>;
+   max-speed = <200>;
+   clocks = <>;
+   clock-names = "lpo";
+   };
+};
-- 
2.17.1

[PATCH 1/2] dt-bindings: arm: amlogic: add support for the WeTek Core 2

[Christian Hewitt]

The WeTek Core 2 is a commercial Android device based on the Amlogic Q200
reference design using the S912-H chipset. Specs:

3GB DDR3 RAM
32GB eMMC storage
10/100 Ethernet using Realtek RTL8152 (internal USB)
802.11 a/b/g/n/ac + BT 4.1 sdio wireless module (AP6356S)
2x single colour LEDs to indicate power
1x power button
1x reset button on the underside of the box
HDMI 2.0 (4k@60p) video
Composite video + 2-channel audio output on 3.5mm jack
S/PDIF audio output
2x USB 2.0 ports
1x USB OTG port (internal)
1x micro SD card slot
UART pins (internal)
IR Sensor

Signed-off-by: Christian Hewitt 
---
 Documentation/devicetree/bindings/arm/amlogic.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml 
b/Documentation/devicetree/bindings/arm/amlogic.yaml
index 378229fa8310..5eba9f48823e 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -121,6 +121,7 @@ properties:
   - libretech,aml-s912-pc
   - nexbox,a1
   - tronsmart,vega-s96
+  - wetek,core2
   - const: amlogic,s912
   - const: amlogic,meson-gxm
 
-- 
2.17.1

Re: [PATCH] MIPS: Prevent READ_IMPLIES_EXEC propagation

[YunQiang Su]

Tiezhu Yang  于2020年7月18日周六 上午11:59写道：
>
> On 07/18/2020 08:04 AM, YunQiang Su wrote:
> > Maciej W. Rozycki  于2020年7月17日周五 下午6:00写道：
> >> On Wed, 8 Jul 2020, Tiezhu Yang wrote:
> >>
> >>>>> In the MIPS architecture, we should clear the security-relevant
> >>>>> flag READ_IMPLIES_EXEC in the function SET_PERSONALITY2() of the
> >>>>> file arch/mips/include/asm/elf.h.
> >>>>>
> >>>>> Otherwise, with this flag set, PROT_READ implies PROT_EXEC for
> >>>>> mmap to make memory executable that is not safe, because this
> >>>>> condition allows an attacker to simply jump to and execute bytes
> >>>>> that are considered to be just data [1].
> >>>>Why isn't the arrangement made with `mips_elf_read_implies_exec'
> >>>> sufficient?
> >>> We inherit the READ_IMPLIES_EXEC personality flag across fork().
> >>> If we do not explicitly clear this flag in SET_PERSONALITY2(),
> >>> PROT_READ implies PROT_EXEC for mmap to make memory executable
> >>> even if used with the GCC option "-z noexecstack" when compile.
> > With next-20200717 with this patch on a Loongson 3A 4000 machine is
> > AMDGPU video card it get
>
> Hi Yunqiang,
>
> Thanks for your test and report.
>
> I test this patch used with Radeon and there is no this problem,
> here is log:
>
> [3.554403] radeon :03:00.0: VRAM: 2048M 0x - 
> 0x7FFF (2048M used)
> [3.554410] radeon :03:00.0: GTT: 2048M 0x8000 - 
> 0x
> [3.554414] [drm] Detected VRAM RAM=2048M, BAR=256M
> [3.554418] [drm] RAM width 64bits DDR
> [3.554611] snd_hda_intel :03:00.1: Force to snoop mode by module 
> option
> [3.555277] [TTM] Zone  kernel: Available graphics memory: 3852912 KiB
> [3.555281] [TTM] Zone   dma32: Available graphics memory: 2097152 KiB
> [3.555284] [TTM] Initializing pool allocator
> [3.555298] [TTM] Initializing DMA pool allocator
> [3.555365] [drm] radeon: 2048M of VRAM memory ready
> [3.555369] [drm] radeon: 2048M of GTT memory ready.
> [3.555375] [drm] Loading oland Microcode
> [3.564885] [drm] Internal thermal controller with fan control
> [3.577104] snd_hda_codec_generic hdaudioC0D0: autoconfig for Generic: 
> line_outs=0 (0x0/0x0/0x0/0x0/0x0) type:line
> [3.577112] snd_hda_codec_generic hdaudioC0D0:speaker_outs=0 
> (0x0/0x0/0x0/0x0/0x0)
> [3.577121] snd_hda_codec_generic hdaudioC0D0:hp_outs=0 
> (0x0/0x0/0x0/0x0/0x0)
> [3.577126] snd_hda_codec_generic hdaudioC0D0:mono: mono_out=0x0
> [3.577131] snd_hda_codec_generic hdaudioC0D0:dig-out=0x3/0x0
> [3.577135] snd_hda_codec_generic hdaudioC0D0:inputs:
> [3.579113] input: HDA ATI HDMI HDMI as 
> /devices/platform/bus@1000/1a00.pci/pci:00/:00:0f.0/:03:00.1/sound/card0/input6
> [3.584927] [drm] radeon: dpm initialized
> [3.590769] [drm] Found VCE firmware/feedback version 50.0.1 / 17!
> [3.590797] [drm] GART: num cpu pages 131072, num gpu pages 524288
> [3.592380] [drm] PCIE gen 2 link speeds already enabled
> [3.729862] [drm] PCIE GART of 2048M enabled (table at 0x001DC000).
> [3.730241] radeon :03:00.0: WB enabled
> [3.730252] radeon :03:00.0: fence driver on ring 0 use gpu addr 
> 0x8c00 and cpu addr 0x6703df0a
> [3.730258] radeon :03:00.0: fence driver on ring 1 use gpu addr 
> 0x8c04 and cpu addr 0xd769f606
> [3.730263] radeon :03:00.0: fence driver on ring 2 use gpu addr 
> 0x8c08 and cpu addr 0xf843f9c0
> [3.730269] radeon :03:00.0: fence driver on ring 3 use gpu addr 
> 0x8c0c and cpu addr 0x8a749926
> [3.730275] radeon :03:00.0: fence driver on ring 4 use gpu addr 
> 0x8c10 and cpu addr 0x63a5bdd6
> [3.761115] radeon :03:00.0: fence driver on ring 5 use gpu addr 
> 0x00075a18 and cpu addr 0x30827134
> [3.875028] radeon :03:00.0: failed VCE resume (-145).
> [3.875037] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [3.875042] radeon :03:00.0: radeon: MSI limited to 32-bit
> [3.875117] radeon :03:00.0: radeon: using MSI.
> [3.875171] [drm] radeon: irq initialized.
> [4.072354] [drm] ring test on 0 succeeded in 1 usecs
> [4.072363] [drm] ring test on 1 succeeded in 1 usecs
> [4.072372] [drm] ring test on 2 succeeded in 1 usecs
> [4.072388] [drm] ring test on 3 succeeded in 4 usecs
> [4.072401] [drm] ring test on 4 succe

[PATCH v4] pwm: bcm-iproc: handle clk_get_rate() return

[Scott Branden]

From: Rayagonda Kokatanur 

Handle clk_get_rate() returning 0 to avoid possible division by zero.

Fixes: daa5abc41c80 ("pwm: Add support for Broadcom iProc PWM controller")
Signed-off-by: Rayagonda Kokatanur 
Signed-off-by: Scott Branden 
Reviewed-by: Ray Jui 

---
Changes from v3: fixed typo in commit message: Reviewed-off-by.
Hopefully everything clean now.
Changes from v2: update commit message to remove <= condition
as clk_get_rate only returns value >= 0
---
 drivers/pwm/pwm-bcm-iproc.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/pwm/pwm-bcm-iproc.c b/drivers/pwm/pwm-bcm-iproc.c
index 1f829edd8ee7..d392a828fc49 100644
--- a/drivers/pwm/pwm-bcm-iproc.c
+++ b/drivers/pwm/pwm-bcm-iproc.c
@@ -85,8 +85,6 @@ static void iproc_pwmc_get_state(struct pwm_chip *chip, 
struct pwm_device *pwm,
u64 tmp, multi, rate;
u32 value, prescale;
 
-   rate = clk_get_rate(ip->clk);
-
value = readl(ip->base + IPROC_PWM_CTRL_OFFSET);
 
if (value & BIT(IPROC_PWM_CTRL_EN_SHIFT(pwm->hwpwm)))
@@ -99,6 +97,13 @@ static void iproc_pwmc_get_state(struct pwm_chip *chip, 
struct pwm_device *pwm,
else
state->polarity = PWM_POLARITY_INVERSED;
 
+   rate = clk_get_rate(ip->clk);
+   if (rate == 0) {
+   state->period = 0;
+   state->duty_cycle = 0;
+   return;
+   }
+
value = readl(ip->base + IPROC_PWM_PRESCALE_OFFSET);
prescale = value >> IPROC_PWM_PRESCALE_SHIFT(pwm->hwpwm);
prescale &= IPROC_PWM_PRESCALE_MAX;
-- 
2.17.1

Re: [PATCH v3 4/5] LSM: Define SELinux function to measure security state

[kernel test robot]

Hi Lakshmi,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on integrity/next-integrity]
[cannot apply to pcmoore-selinux/next security/next-testing linus/master 
v5.8-rc5 next-20200717]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Lakshmi-Ramasubramanian/LSM-Measure-security-module-state/20200718-063111
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git 
next-integrity
config: sparc-allyesconfig (attached as .config)
compiler: sparc64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=sparc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All error/warnings (new ones prefixed by >>):

   security/selinux/measure.c: In function 'selinux_hash_policy':
>> security/selinux/measure.c:57:8: error: implicit declaration of function 
>> 'crypto_alloc_shash' [-Werror=implicit-function-declaration]
  57 |  tfm = crypto_alloc_shash(hash_alg_name, 0, 0);
 |^~
>> security/selinux/measure.c:57:6: warning: assignment to 'struct crypto_shash 
>> *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
  57 |  tfm = crypto_alloc_shash(hash_alg_name, 0, 0);
 |  ^
>> security/selinux/measure.c:61:14: error: implicit declaration of function 
>> 'crypto_shash_descsize' [-Werror=implicit-function-declaration]
  61 |  desc_size = crypto_shash_descsize(tfm) + sizeof(*desc);
 |  ^
>> security/selinux/measure.c:61:50: error: dereferencing pointer to incomplete 
>> type 'struct shash_desc'
  61 |  desc_size = crypto_shash_descsize(tfm) + sizeof(*desc);
 |  ^
>> security/selinux/measure.c:62:16: error: implicit declaration of function 
>> 'crypto_shash_digestsize' [-Werror=implicit-function-declaration]
  62 |  digest_size = crypto_shash_digestsize(tfm);
 |^~~
>> security/selinux/measure.c:78:8: error: implicit declaration of function 
>> 'crypto_shash_digest' [-Werror=implicit-function-declaration]
  78 |  ret = crypto_shash_digest(desc, policy, policy_len, digest);
 |^~~
>> security/selinux/measure.c:90:2: error: implicit declaration of function 
>> 'crypto_free_shash' [-Werror=implicit-function-declaration]
  90 |  crypto_free_shash(tfm);
 |  ^
   security/selinux/measure.c: In function 'selinux_measure_state':
   security/selinux/measure.c:132:11: warning: comparison of unsigned 
expression >= 0 is always true [-Wtype-limits]
 132 |  if (curr >= 0 && curr < selinux_state_string_len)
 |   ^~
   security/selinux/measure.c:148:2: error: implicit declaration of function 
'vfree'; did you mean 'kvfree'? [-Werror=implicit-function-declaration]
 148 |  vfree(policy);
 |  ^
 |  kvfree
   cc1: some warnings being treated as errors

vim +/crypto_alloc_shash +57 security/selinux/measure.c

45  
46  static int selinux_hash_policy(const char *hash_alg_name,
47 void *policy, size_t policy_len,
48 void **policy_hash, int *policy_hash_len)
49  {
50  struct crypto_shash *tfm;
51  struct shash_desc *desc = NULL;
52  void *digest = NULL;
53  int desc_size;
54  int digest_size;
55  int ret = 0;
56  
  > 57  tfm = crypto_alloc_shash(hash_alg_name, 0, 0);
58  if (IS_ERR(tfm))
59  return PTR_ERR(tfm);
60  
  > 61  desc_size = crypto_shash_descsize(tfm) + sizeof(*desc);
  > 62  digest_size = crypto_shash_digestsize(tfm);
63  
64  digest = kmalloc(digest_size, GFP_KERNEL);
65  if (!digest) {
66  ret = -ENOMEM;
67  goto error;
68  }
69  
70  desc = kzalloc(desc_size, GFP_KERNEL);
71  if (!desc) {
72  ret = -ENOMEM;
73  goto error;
74  }
75  
76  desc->tfm = tfm;
77  
  > 78  ret = crypto_shash_digest(desc, policy, policy_len, digest);
79  if (ret < 0)
80  goto error;
81  
82  *policy

Re: [PATCH v3] x86/ioperm: Fix io bitmap invalidation on Xen PV

[Jürgen Groß]

On 18.07.20 01:53, Andy Lutomirski wrote:

tss_invalidate_io_bitmap() wasn't wired up properly through the pvop
machinery, so the TSS and Xen's io bitmap would get out of sync
whenever disabling a valid io bitmap.

Add a new pvop for tss_invalidate_io_bitmap() to fix it.

This is XSA-329.

Cc: Juergen Gross 
Cc: Boris Ostrovsky 
Cc: Stefano Stabellini 
Cc: sta...@vger.kernel.org
Fixes: 22fe5b0439dd ("x86/ioperm: Move TSS bitmap update to exit to user work")
Reviewed-by: Juergen Gross 
Reviewed-by: Thomas Gleixner 
Signed-off-by: Andy Lutomirski 


Reviewed-by: Juergen Gross 


Juergen

Re: [PATCH] m68k: Replace HTTP links with HTTPS ones

[Finn Thain]

On Fri, 17 Jul 2020, Alexander A. Klimov wrote:

> Rationale:
> Reduces attack surface on kernel devs opening the links for 
> MITM as HTTPS traffic is much harder to manipulate.
> 

Has that actually happened?

You still need to fix the chain of trust in all the relevant browsers 
(unless you're planning to ship root certificates with the kernel source).

Even then, developers using "HTTPS Everywhere" or equivalent will not 
benefit from this patch.

And these new links are just as stale as the old ones, so I have to use 
web.archive.org anyway. So this patch achieves practically nothing.

> Deterministic algorithm:
> For each file:
>   If not .svg:

Are URLs in .svg files not exploitable by MITM attack?

> For each line:
>   If doesn't contain `\bxmlns\b`:

Are XML parsers not exploitable by MITM attack?

> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:

Are ftp:// links etc. not exploitable by MITM attack?

> If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:

Should developers be more concerned about MITM attack or lawsuit?

> If both the HTTP and HTTPS versions
> return 200 OK and serve the same content:

...then you have not been MITM attacked.

>   Replace HTTP with HTTPS.
> 

Will you also require developers to use DNSSEC?

> Signed-off-by: Alexander A. Klimov 
> ---
>  Continuing my work started at 93431e0607e5.
>  See also: git log --oneline '--author=Alexander A. Klimov 
> ' v5.7..master
> 
>  If there are any URLs to be removed completely
>  or at least not (just) HTTPSified:
>  Just clearly say so and I'll *undo my change*.
>  See also: https://lkml.org/lkml/2020/6/27/64
> 
>  If there are any valid, but yet not changed URLs:
>  See: https://lkml.org/lkml/2020/6/26/837
> 
>  If you apply the patch, please let me know.
> 
> 
>  arch/m68k/include/asm/mac_via.h | 4 ++--
>  arch/m68k/mac/config.c  | 2 +-
>  arch/m68k/mac/macboing.c| 2 +-
>  3 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/m68k/include/asm/mac_via.h b/arch/m68k/include/asm/mac_via.h
> index 1149251ea58d..0cbab71f2592 100644
> --- a/arch/m68k/include/asm/mac_via.h
> +++ b/arch/m68k/include/asm/mac_via.h
> @@ -30,7 +30,7 @@
>   *  http://www.rs6000.ibm.com/resource/technology/chrpio/via5.mak.html
>   *  
> ftp://ftp.austin.ibm.com/pub/technology/spec/chrp/inwork/CHRP_IORef_1.0.pdf
>   *
> - * also, http://developer.apple.com/technotes/hw/hw_09.html claims the
> + * also, https://developer.apple.com/technotes/hw/hw_09.html claims the
>   * following changes for IIfx:
>   * VIA1A_vSccWrReq not available and that VIA1A_vSync has moved to an IOP.
>   * Also, "All of the functionality of VIA2 has been moved to other chips".
> @@ -178,7 +178,7 @@
>* on others, 0=disable processor's instruction
>* and data caches. */
>  
> -/* Apple sez: http://developer.apple.com/technotes/ov/ov_04.html
> +/* Apple sez: https://developer.apple.com/technotes/ov/ov_04.html
>   * Another example of a valid function that has no ROM support is the use
>   * of the alternate video page for page-flipping animation. Since there
>   * is no ROM call to flip pages, it is necessary to go play with the
> diff --git a/arch/m68k/mac/config.c b/arch/m68k/mac/config.c
> index 5c9f3a2d6538..6f2eb1dcfc0c 100644
> --- a/arch/m68k/mac/config.c
> +++ b/arch/m68k/mac/config.c
> @@ -240,7 +240,7 @@ static struct mac_model mac_data_table[] = {
>* Weirdified Mac II hardware - all subtly different. Gee thanks
>* Apple. All these boxes seem to have VIA2 in a different place to
>* the Mac II (+1A000 rather than +4000)
> -  * CSA: see http://developer.apple.com/technotes/hw/hw_09.html
> +  * CSA: see https://developer.apple.com/technotes/hw/hw_09.html
>*/
>  
>   {
> diff --git a/arch/m68k/mac/macboing.c b/arch/m68k/mac/macboing.c
> index 388780797f7d..a904146dc4e6 100644
> --- a/arch/m68k/mac/macboing.c
> +++ b/arch/m68k/mac/macboing.c
> @@ -116,7 +116,7 @@ static void mac_init_asc( void )
>*   support 16-bit stereo output, but only mono input."
>*
>*   Technical Information Library (TIL) article number 
> 16405. 
> -  *   http://support.apple.com/kb/TA32601 
> +  *   https://support.apple.com/kb/TA32601 
>*
>* --David Kilzer
>*/
> 

drivers/edac/i10nm_base.c:149:19: sparse: sparse: cast removes address space '__iomem' of expression

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   4ebf8d7649cd86c41c41bf48da4b7761da2d5009
commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to 
define address spaces
date:   4 weeks ago
config: x86_64-randconfig-s021-20200718 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-14) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.2-49-g707c5017-dirty
git checkout 670d0a4b10704667765f7d18f7592993d02783aa
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 


sparse warnings: (new ones prefixed by >>)

>> drivers/edac/i10nm_base.c:149:19: sparse: sparse: cast removes address space 
>> '__iomem' of expression
   drivers/edac/i10nm_base.c:170:31: sparse: sparse: cast removes address space 
'__iomem' of expression
   drivers/edac/i10nm_base.c:171:37: sparse: sparse: cast removes address space 
'__iomem' of expression

vim +/__iomem +149 drivers/edac/i10nm_base.c

d4dc89d069aab9 Qiuxu Zhuo 2019-01-30  144  
d4dc89d069aab9 Qiuxu Zhuo 2019-01-30  145  static bool i10nm_check_ecc(struct 
skx_imc *imc, int chan)
d4dc89d069aab9 Qiuxu Zhuo 2019-01-30  146  {
d4dc89d069aab9 Qiuxu Zhuo 2019-01-30  147   u32 mcmtr;
d4dc89d069aab9 Qiuxu Zhuo 2019-01-30  148  
d4dc89d069aab9 Qiuxu Zhuo 2019-01-30 @149   mcmtr = *(u32 *)(imc->mbase + 
0x20ef8 + chan * 0x4000);
d4dc89d069aab9 Qiuxu Zhuo 2019-01-30  150   edac_dbg(1, "ch%d mcmtr reg 
%x\n", chan, mcmtr);
d4dc89d069aab9 Qiuxu Zhuo 2019-01-30  151  
d4dc89d069aab9 Qiuxu Zhuo 2019-01-30  152   return !!GET_BITFIELD(mcmtr, 2, 
2);
d4dc89d069aab9 Qiuxu Zhuo 2019-01-30  153  }
d4dc89d069aab9 Qiuxu Zhuo 2019-01-30  154  

:: The code at line 149 was first introduced by commit
:: d4dc89d069aab9074e2493a4c2f3969a0a0b91c1 EDAC, i10nm: Add a driver for 
Intel 10nm server processors

:: TO: Qiuxu Zhuo 
:: CC: Borislav Petkov 

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

[PATCH v3 1/4] scsi: ufs: Add checks before setting clk-gating states

[Can Guo]

Clock gating features can be turned on/off selectively which means its
state information is only important if it is enabled. This change makes
sure that we only look at state of clk-gating if it is enabled.

Signed-off-by: Can Guo 
---
 drivers/scsi/ufs/ufshcd.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index efc0a6c..9ddfd13 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1839,6 +1839,8 @@ static void ufshcd_init_clk_gating(struct ufs_hba *hba)
if (!ufshcd_is_clkgating_allowed(hba))
return;
 
+   hba->clk_gating.state = CLKS_ON;
+
hba->clk_gating.delay_ms = 150;
INIT_DELAYED_WORK(>clk_gating.gate_work, ufshcd_gate_work);
INIT_WORK(>clk_gating.ungate_work, ufshcd_ungate_work);
@@ -2538,7 +2540,8 @@ static int ufshcd_queuecommand(struct Scsi_Host *host, 
struct scsi_cmnd *cmd)
err = SCSI_MLQUEUE_HOST_BUSY;
goto out;
}
-   WARN_ON(hba->clk_gating.state != CLKS_ON);
+   WARN_ON(ufshcd_is_clkgating_allowed(hba) &&
+   (hba->clk_gating.state != CLKS_ON));
 
lrbp = >lrb[tag];
 
@@ -8315,8 +8318,11 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum 
ufs_pm_op pm_op)
/* If link is active, device ref_clk can't be switched off */
__ufshcd_setup_clocks(hba, false, true);
 
-   hba->clk_gating.state = CLKS_OFF;
-   trace_ufshcd_clk_gating(dev_name(hba->dev), hba->clk_gating.state);
+   if (ufshcd_is_clkgating_allowed(hba)) {
+   hba->clk_gating.state = CLKS_OFF;
+   trace_ufshcd_clk_gating(dev_name(hba->dev),
+   hba->clk_gating.state);
+   }
 
/* Put the host controller in low power mode if possible */
ufshcd_hba_vreg_set_lpm(hba);
@@ -8456,6 +8462,11 @@ static int ufshcd_resume(struct ufs_hba *hba, enum 
ufs_pm_op pm_op)
if (hba->clk_scaling.is_allowed)
ufshcd_suspend_clkscaling(hba);
ufshcd_setup_clocks(hba, false);
+   if (ufshcd_is_clkgating_allowed(hba)) {
+   hba->clk_gating.state = CLKS_OFF;
+   trace_ufshcd_clk_gating(dev_name(hba->dev),
+   hba->clk_gating.state);
+   }
 out:
hba->pm_op_in_progress = 0;
if (ret)
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH v3 4/4] scsi: ufs: Fix up and simplify error recovery mechanism

[Can Guo]

Current UFS error recovery mechanism has two major problems, and neither of
them is rare.

- Error recovery can be invoked from multiple paths, including hibern8
  enter/exit, some vendor vops, ufshcd_eh_host_reset_handler(), resume and
  eh_work scheduled from IRQ context. Ultimately, these paths are trying to
  invoke ufshcd_reset_and_restore(), in either sync or async manner. Since
  there is no proper protection or synchronization, concurrency of these
  paths most likely leads UFS device and host to bad states.

- Error recovery cannot work well or recover hba runtime PM errors if
  ufshcd_suspend/resume has failed due to UFS errors, e.g. SSU cmd error.
  When this happens, error handler may fail doing full reset and restore
  because error handler always assumes that powers, IRQs and clocks are
  ready after pm_runtime_get_sync returns, but actually they are not if
  ufshcd_reusme fails [1]. Besides, if ufschd_suspend/resume fails due to
  UFS error, runtime PM framework saves the error to power.runtime_error.
  After that, hba dev runtime suspend/resume would not be invoked anymore
  unless runtime_error is cleared [2].

To fix the concurrency problem, this change queues eh_work on a single
threaded workqueue and remove link recovery from hibern8 enter/exit path.
Meanwhile, flushing eh_work in eh_host_reset_handler instead of calling
ufshcd_reset_and_restore.

In case of ufshcd_suspend/resume fails due to UFS errors, for scenario [1],
error handler cannot assume anything of pm_runtime_get_sync, meaning error
handler should explicitly turn ON powers, IRQs and clocks. To get the hba
runtime PM work again as regard for scenario [2], error handler can clear
the runtime_error by calling pm_runtime_set_active() if reset and restore
succeeds. Meanwhile, if pm_runtime_set_active() returns no error, which
means runtime_error is cleared, we also need to explicitly resume those
scsi devices under hba in case any of them has failed to be resumed due to
hba runtime resume error.

Signed-off-by: Can Guo 
---
 drivers/scsi/ufs/ufs-sysfs.c |   1 +
 drivers/scsi/ufs/ufshcd.c| 454 ++-
 drivers/scsi/ufs/ufshcd.h|  15 ++
 3 files changed, 290 insertions(+), 180 deletions(-)

diff --git a/drivers/scsi/ufs/ufs-sysfs.c b/drivers/scsi/ufs/ufs-sysfs.c
index 2d71d23..02d379f00 100644
--- a/drivers/scsi/ufs/ufs-sysfs.c
+++ b/drivers/scsi/ufs/ufs-sysfs.c
@@ -16,6 +16,7 @@ static const char *ufschd_uic_link_state_to_string(
case UIC_LINK_OFF_STATE:return "OFF";
case UIC_LINK_ACTIVE_STATE: return "ACTIVE";
case UIC_LINK_HIBERN8_STATE:return "HIBERN8";
+   case UIC_LINK_BROKEN_STATE: return "BROKEN";
default:return "UNKNOWN";
}
 }
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 4a34f2a..cb32430 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -15,6 +15,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include "ufshcd.h"
 #include "ufs_quirks.h"
 #include "unipro.h"
@@ -125,7 +127,8 @@ enum {
UFSHCD_STATE_RESET,
UFSHCD_STATE_ERROR,
UFSHCD_STATE_OPERATIONAL,
-   UFSHCD_STATE_EH_SCHEDULED,
+   UFSHCD_STATE_EH_SCHEDULED_FATAL,
+   UFSHCD_STATE_EH_SCHEDULED_NON_FATAL,
 };
 
 /* UFSHCD error handling flags */
@@ -228,6 +231,11 @@ static int ufshcd_scale_clks(struct ufs_hba *hba, bool 
scale_up);
 static irqreturn_t ufshcd_intr(int irq, void *__hba);
 static int ufshcd_change_power_mode(struct ufs_hba *hba,
 struct ufs_pa_layer_attr *pwr_mode);
+static void ufshcd_schedule_eh_work(struct ufs_hba *hba);
+static int ufshcd_setup_hba_vreg(struct ufs_hba *hba, bool on);
+static int ufshcd_setup_vreg(struct ufs_hba *hba, bool on);
+static inline int ufshcd_config_vreg_hpm(struct ufs_hba *hba,
+struct ufs_vreg *vreg);
 static int ufshcd_wb_buf_flush_enable(struct ufs_hba *hba);
 static int ufshcd_wb_buf_flush_disable(struct ufs_hba *hba);
 static int ufshcd_wb_ctrl(struct ufs_hba *hba, bool enable);
@@ -411,15 +419,6 @@ static void ufshcd_print_err_hist(struct ufs_hba *hba,
 static void ufshcd_print_host_regs(struct ufs_hba *hba)
 {
ufshcd_dump_regs(hba, 0, UFSHCI_REG_SPACE_SIZE, "host_regs: ");
-   dev_err(hba->dev, "hba->ufs_version = 0x%x, hba->capabilities = 0x%x\n",
-   hba->ufs_version, hba->capabilities);
-   dev_err(hba->dev,
-   "hba->outstanding_reqs = 0x%x, hba->outstanding_tasks = 0x%x\n",
-   (u32)hba->outstanding_reqs, (u32)hba->outstanding_tasks);
-   dev_err(hba->dev,
-   "last_hibern8_exit_tstamp at %lld us, hibern8_exit_cnt = %d\n",
-   ktime_to_us(hba->ufs_stats.last_hibern8_exit_tstamp),
-   hba->ufs_stats.hibern8_exit_cnt);
 
ufshcd_print_err_hist(hba, >ufs_stats.pa_err, "pa_err");
ufshcd_print_err_hist(hba, 

[PATCH v3 3/4] ufs: ufs-qcom: Fix a few BUGs in func ufs_qcom_dump_dbg_regs()

[Can Guo]

Dumping testbus registers needs to sleep a bit intermittently as there are
too many of them. Skip them for those contexts where sleep is not allowed.

Meanwhile, if ufs_qcom_dump_dbg_regs() calls ufs_qcom_testbus_config() from
ufshcd_suspend/resume and/or clk gate/ungate context, pm_runtime_get_sync()
and ufshcd_hold() will cause racing problems. Fix it by removing the
unnecessary calls of pm_runtime_get_sync() and ufshcd_hold().

Signed-off-by: Can Guo 
---
 drivers/scsi/ufs/ufs-qcom.c | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index 2e6ddb5..3743c17 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -1604,9 +1604,6 @@ int ufs_qcom_testbus_config(struct ufs_qcom_host *host)
 */
}
mask <<= offset;
-
-   pm_runtime_get_sync(host->hba->dev);
-   ufshcd_hold(host->hba, false);
ufshcd_rmwl(host->hba, TEST_BUS_SEL,
(u32)host->testbus.select_major << 19,
REG_UFS_CFG1);
@@ -1619,8 +1616,6 @@ int ufs_qcom_testbus_config(struct ufs_qcom_host *host)
 * committed before returning.
 */
mb();
-   ufshcd_release(host->hba);
-   pm_runtime_put_sync(host->hba->dev);
 
return 0;
 }
@@ -1658,11 +1653,13 @@ static void ufs_qcom_dump_dbg_regs(struct ufs_hba *hba)
 
/* sleep a bit intermittently as we are dumping too much data */
ufs_qcom_print_hw_debug_reg_all(hba, NULL, ufs_qcom_dump_regs_wrapper);
-   udelay(1000);
-   ufs_qcom_testbus_read(hba);
-   udelay(1000);
-   ufs_qcom_print_unipro_testbus(hba);
-   udelay(1000);
+   if (in_task()) {
+   udelay(1000);
+   ufs_qcom_testbus_read(hba);
+   udelay(1000);
+   ufs_qcom_print_unipro_testbus(hba);
+   udelay(1000);
+   }
 }
 
 /**
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH v3 2/4] scsi: ufs: Fix imbalanced scsi_block_reqs_cnt caused by ufshcd_hold()

[Can Guo]

The scsi_block_reqs_cnt increased in ufshcd_hold() is supposed to be
decreased back in ufshcd_ungate_work() in a paired way. However, if
specific ufshcd_hold/release sequences are met, it is possible that
scsi_block_reqs_cnt is increased twice but only one ungate work is
queued. To make sure scsi_block_reqs_cnt is handled by ufshcd_hold() and
ufshcd_ungate_work() in a paired way, increase it only if queue_work()
returns true.

Signed-off-by: Can Guo 
---
 drivers/scsi/ufs/ufshcd.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 9ddfd13..4a34f2a 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1611,12 +1611,12 @@ int ufshcd_hold(struct ufs_hba *hba, bool async)
 */
/* fallthrough */
case CLKS_OFF:
-   ufshcd_scsi_block_requests(hba);
hba->clk_gating.state = REQ_CLKS_ON;
trace_ufshcd_clk_gating(dev_name(hba->dev),
hba->clk_gating.state);
-   queue_work(hba->clk_gating.clk_gating_workq,
-  >clk_gating.ungate_work);
+   if (queue_work(hba->clk_gating.clk_gating_workq,
+  >clk_gating.ungate_work))
+   ufshcd_scsi_block_requests(hba);
/*
 * fall through to check if we should wait for this
 * work to be done or not.
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.

Re: [PATCH] MIPS: Prevent READ_IMPLIES_EXEC propagation

[Tiezhu Yang]

On 07/18/2020 08:04 AM, YunQiang Su wrote:

Maciej W. Rozycki  于2020年7月17日周五 下午6:00写道：

On Wed, 8 Jul 2020, Tiezhu Yang wrote:


In the MIPS architecture, we should clear the security-relevant
flag READ_IMPLIES_EXEC in the function SET_PERSONALITY2() of the
file arch/mips/include/asm/elf.h.

Otherwise, with this flag set, PROT_READ implies PROT_EXEC for
mmap to make memory executable that is not safe, because this
condition allows an attacker to simply jump to and execute bytes
that are considered to be just data [1].

   Why isn't the arrangement made with `mips_elf_read_implies_exec'
sufficient?

We inherit the READ_IMPLIES_EXEC personality flag across fork().
If we do not explicitly clear this flag in SET_PERSONALITY2(),
PROT_READ implies PROT_EXEC for mmap to make memory executable
even if used with the GCC option "-z noexecstack" when compile.

With next-20200717 with this patch on a Loongson 3A 4000 machine is
AMDGPU video card it get


Hi Yunqiang,

Thanks for your test and report.

I test this patch used with Radeon and there is no this problem,
here is log:

[3.554403] radeon :03:00.0: VRAM: 2048M 0x - 
0x7FFF (2048M used)
[3.554410] radeon :03:00.0: GTT: 2048M 0x8000 - 
0x
[3.554414] [drm] Detected VRAM RAM=2048M, BAR=256M
[3.554418] [drm] RAM width 64bits DDR
[3.554611] snd_hda_intel :03:00.1: Force to snoop mode by module option
[3.555277] [TTM] Zone  kernel: Available graphics memory: 3852912 KiB
[3.555281] [TTM] Zone   dma32: Available graphics memory: 2097152 KiB
[3.555284] [TTM] Initializing pool allocator
[3.555298] [TTM] Initializing DMA pool allocator
[3.555365] [drm] radeon: 2048M of VRAM memory ready
[3.555369] [drm] radeon: 2048M of GTT memory ready.
[3.555375] [drm] Loading oland Microcode
[3.564885] [drm] Internal thermal controller with fan control
[3.577104] snd_hda_codec_generic hdaudioC0D0: autoconfig for Generic: 
line_outs=0 (0x0/0x0/0x0/0x0/0x0) type:line
[3.577112] snd_hda_codec_generic hdaudioC0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[3.577121] snd_hda_codec_generic hdaudioC0D0:hp_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[3.577126] snd_hda_codec_generic hdaudioC0D0:mono: mono_out=0x0
[3.577131] snd_hda_codec_generic hdaudioC0D0:dig-out=0x3/0x0
[3.577135] snd_hda_codec_generic hdaudioC0D0:inputs:
[3.579113] input: HDA ATI HDMI HDMI as 
/devices/platform/bus@1000/1a00.pci/pci:00/:00:0f.0/:03:00.1/sound/card0/input6
[3.584927] [drm] radeon: dpm initialized
[3.590769] [drm] Found VCE firmware/feedback version 50.0.1 / 17!
[3.590797] [drm] GART: num cpu pages 131072, num gpu pages 524288
[3.592380] [drm] PCIE gen 2 link speeds already enabled
[3.729862] [drm] PCIE GART of 2048M enabled (table at 0x001DC000).
[3.730241] radeon :03:00.0: WB enabled
[3.730252] radeon :03:00.0: fence driver on ring 0 use gpu addr 
0x8c00 and cpu addr 0x6703df0a
[3.730258] radeon :03:00.0: fence driver on ring 1 use gpu addr 
0x8c04 and cpu addr 0xd769f606
[3.730263] radeon :03:00.0: fence driver on ring 2 use gpu addr 
0x8c08 and cpu addr 0xf843f9c0
[3.730269] radeon :03:00.0: fence driver on ring 3 use gpu addr 
0x8c0c and cpu addr 0x8a749926
[3.730275] radeon :03:00.0: fence driver on ring 4 use gpu addr 
0x8c10 and cpu addr 0x63a5bdd6
[3.761115] radeon :03:00.0: fence driver on ring 5 use gpu addr 
0x00075a18 and cpu addr 0x30827134
[3.875028] radeon :03:00.0: failed VCE resume (-145).
[3.875037] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[3.875042] radeon :03:00.0: radeon: MSI limited to 32-bit
[3.875117] radeon :03:00.0: radeon: using MSI.
[3.875171] [drm] radeon: irq initialized.
[4.072354] [drm] ring test on 0 succeeded in 1 usecs
[4.072363] [drm] ring test on 1 succeeded in 1 usecs
[4.072372] [drm] ring test on 2 succeeded in 1 usecs
[4.072388] [drm] ring test on 3 succeeded in 4 usecs
[4.072401] [drm] ring test on 4 succeeded in 4 usecs
[4.249024] [drm] ring test on 5 succeeded in 1 usecs
[4.249034] [drm] UVD initialized successfully.
[4.249384] [drm] ib test on ring 0 succeeded in 0 usecs
[4.249445] [drm] ib test on ring 1 succeeded in 0 usecs
[4.249501] [drm] ib test on ring 2 succeeded in 0 usecs
[4.249547] [drm] ib test on ring 3 succeeded in 0 usecs
[4.249587] [drm] ib test on ring 4 succeeded in 0 usecs
[4.400723] [drm] ib test on ring 5 succeeded
[4.401930] [drm] Radeon Display Connectors
[4.401934] [drm] Connector 0:
[4.401937] [drm]   HDMI-A-1
[4.401940] [drm]   HPD2
[4.401945] [drm]   DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 
0x653c
[4.401947] [drm] 

[PATCH v3] PCI: hv: Fix a timing issue which causes kdump to fail occasionally

[Wei Hu]

Kdump could fail sometime on Hyper-V guest over Accelerated Network
interface. This is because the retry in hv_pci_enter_d0() relies on
an asynchronous host event arriving before the guest calls
hv_send_resources_allocated(). Fix the problem by moving retry
to hv_pci_probe(), removing this dependency and making the calling
sequence synchronous.

Fixes: c81992e7f4aa ("PCI: hv: Retry PCI bus D0 entry on invalid device state")
Signed-off-by: Wei Hu 
---
v2: Adding Fixes tag according to Michael Kelley's review comment.
v3: Fix couple typos and reword commit message to make it clearer.
Thanks the comments from Bjorn Helgaas.

 drivers/pci/controller/pci-hyperv.c | 66 ++---
 1 file changed, 32 insertions(+), 34 deletions(-)

diff --git a/drivers/pci/controller/pci-hyperv.c 
b/drivers/pci/controller/pci-hyperv.c
index bf40ff09c99d..738ee30f3334 100644
--- a/drivers/pci/controller/pci-hyperv.c
+++ b/drivers/pci/controller/pci-hyperv.c
@@ -2759,10 +2759,8 @@ static int hv_pci_enter_d0(struct hv_device *hdev)
struct pci_bus_d0_entry *d0_entry;
struct hv_pci_compl comp_pkt;
struct pci_packet *pkt;
-   bool retry = true;
int ret;
 
-enter_d0_retry:
/*
 * Tell the host that the bus is ready to use, and moved into the
 * powered-on state.  This includes telling the host which region
@@ -2789,38 +2787,6 @@ static int hv_pci_enter_d0(struct hv_device *hdev)
if (ret)
goto exit;
 
-   /*
-* In certain case (Kdump) the pci device of interest was
-* not cleanly shut down and resource is still held on host
-* side, the host could return invalid device status.
-* We need to explicitly request host to release the resource
-* and try to enter D0 again.
-*/
-   if (comp_pkt.completion_status < 0 && retry) {
-   retry = false;
-
-   dev_err(>device, "Retrying D0 Entry\n");
-
-   /*
-* Hv_pci_bus_exit() calls hv_send_resource_released()
-* to free up resources of its child devices.
-* In the kdump kernel we need to set the
-* wslot_res_allocated to 255 so it scans all child
-* devices to release resources allocated in the
-* normal kernel before panic happened.
-*/
-   hbus->wslot_res_allocated = 255;
-
-   ret = hv_pci_bus_exit(hdev, true);
-
-   if (ret == 0) {
-   kfree(pkt);
-   goto enter_d0_retry;
-   }
-   dev_err(>device,
-   "Retrying D0 failed with ret %d\n", ret);
-   }
-
if (comp_pkt.completion_status < 0) {
dev_err(>device,
"PCI Pass-through VSP failed D0 Entry with status %x\n",
@@ -3058,6 +3024,7 @@ static int hv_pci_probe(struct hv_device *hdev,
struct hv_pcibus_device *hbus;
u16 dom_req, dom;
char *name;
+   bool enter_d0_retry = true;
int ret;
 
/*
@@ -3178,11 +3145,42 @@ static int hv_pci_probe(struct hv_device *hdev,
if (ret)
goto free_fwnode;
 
+retry:
ret = hv_pci_query_relations(hdev);
if (ret)
goto free_irq_domain;
 
ret = hv_pci_enter_d0(hdev);
+   /*
+* In certain case (Kdump) the pci device of interest was
+* not cleanly shut down and resource is still held on host
+* side, the host could return invalid device status.
+* We need to explicitly request host to release the resource
+* and try to enter D0 again.
+* The retry should start from hv_pci_query_relations() call.
+*/
+   if (ret == -EPROTO && enter_d0_retry) {
+   enter_d0_retry = false;
+
+   dev_err(>device, "Retrying D0 Entry\n");
+
+   /*
+* Hv_pci_bus_exit() calls hv_send_resources_released()
+* to free up resources of its child devices.
+* In the kdump kernel we need to set the
+* wslot_res_allocated to 255 so it scans all child
+* devices to release resources allocated in the
+* normal kernel before panic happened.
+*/
+   hbus->wslot_res_allocated = 255;
+   ret = hv_pci_bus_exit(hdev, true);
+
+   if (ret == 0)
+   goto retry;
+
+   dev_err(>device,
+   "Retrying D0 failed with ret %d\n", ret);
+   }
if (ret)
goto free_irq_domain;
 
-- 
2.20.1

RE: [PATCH v2] PCI: hv: Fix a timing issue which causes kdump to fail occasionally

[Wei Hu]

> -Original Message-
> From: Bjorn Helgaas 
> Sent: Saturday, July 18, 2020 4:11 AM
> To: Wei Hu 
> Cc: KY Srinivasan ; Haiyang Zhang
> ; Stephen Hemminger ;
> wei@kernel.org; lorenzo.pieral...@arm.com; r...@kernel.org;
> bhelg...@google.com; linux-hyp...@vger.kernel.org; linux-
> p...@vger.kernel.org; linux-kernel@vger.kernel.org; Dexuan Cui
> ; Michael Kelley 
> Subject: Re: [PATCH v2] PCI: hv: Fix a timing issue which causes kdump to fail
> occasionally
> 
> On Fri, Jul 17, 2020 at 10:55:28AM +0800, Wei Hu wrote:
> > Kdump could fail sometime on HyperV guest over Accerlated Network
> > interface. This is because the retry in hv_pci_enter_d0() relies on an
> > asynchronous host event to arrive guest before calling
> > hv_send_resources_allocated(). This fixes the problem by moving retry
> > to hv_pci_probe(), removing this dependence and making the calling
> > sequence synchronous.
> 
> Lorenzo, if you apply this, can you fix this typo?
> 
>   s/Accerlated/Accelerated/
> 
> and maybe even
> 
>   s/HyperV/Hyper-V/
>   s/This fixes the problem/Fix the problem/
>   s/this dependence/this dependency/
> 
> Not sure if "relies on ... event to arrive guest" means "relies on ...
> event arriving in the guest"?  Or maybe "relies on ... event arriving before 
> the
> guest calls ..."?
> 
> This would probably all make perfect sense to me if I understood more about
> Hyper-V :)
> 
> > v2: Adding Fixes tag according to Michael Kelley's review comment.
> 
> There's no need to include this "v2" comment in the commit log.  I think if 
> you
> put it after a line containing only "---" (or maybe "--"?), it will be in the 
> email
> but not in the commit log.
> 
Thanks Bjorn. I will send out a v3 version shortly to correct all these. 
Lorenzo, please pick up my v3 version if you have not started to apply it yet. 

Thanks so much,
Wei

drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:959:30: warning: variable 'topology' set but not used

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   4ebf8d7649cd86c41c41bf48da4b7761da2d5009
commit: de3916c70a24e3e1bdbf6b0a77d75b069d8953d9 drm/msm/dpu: Track resources 
in global state
date:   4 months ago
config: arm-randconfig-r026-20200717 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout de3916c70a24e3e1bdbf6b0a77d75b069d8953d9
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c: In function 
'dpu_encoder_virt_mode_set':
>> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:959:30: warning: variable 
>> 'topology' set but not used [-Wunused-but-set-variable]
 959 |  struct msm_display_topology topology;
 |  ^~~~

vim +/topology +959 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c

25fdd5933e4c0f Jeykumar Sankaran 2018-06-27   946  
25fdd5933e4c0f Jeykumar Sankaran 2018-06-27   947  static void 
dpu_encoder_virt_mode_set(struct drm_encoder *drm_enc,
25fdd5933e4c0f Jeykumar Sankaran 2018-06-27   948   
  struct drm_display_mode *mode,
25fdd5933e4c0f Jeykumar Sankaran 2018-06-27   949   
  struct drm_display_mode *adj_mode)
25fdd5933e4c0f Jeykumar Sankaran 2018-06-27   950  {
25fdd5933e4c0f Jeykumar Sankaran 2018-06-27   951   struct dpu_encoder_virt 
*dpu_enc;
25fdd5933e4c0f Jeykumar Sankaran 2018-06-27   952   struct msm_drm_private 
*priv;
25fdd5933e4c0f Jeykumar Sankaran 2018-06-27   953   struct dpu_kms *dpu_kms;
25fdd5933e4c0f Jeykumar Sankaran 2018-06-27   954   struct list_head 
*connector_list;
25fdd5933e4c0f Jeykumar Sankaran 2018-06-27   955   struct drm_connector 
*conn = NULL, *conn_iter;
c2ab55a68a3374 Jeykumar Sankaran 2019-02-13   956   struct drm_crtc 
*drm_crtc;
b107603b4ad0f2 Jeykumar Sankaran 2019-02-13   957   struct dpu_crtc_state 
*cstate;
de3916c70a24e3 Drew Davenport2020-02-19   958   struct dpu_global_state 
*global_state;
25fdd5933e4c0f Jeykumar Sankaran 2018-06-27  @959   struct 
msm_display_topology topology;
b954fa6baaca7a Drew Davenport2020-02-19   960   struct dpu_hw_blk 
*hw_pp[MAX_CHANNELS_PER_ENC];
b954fa6baaca7a Drew Davenport2020-02-19   961   struct dpu_hw_blk 
*hw_ctl[MAX_CHANNELS_PER_ENC];
b954fa6baaca7a Drew Davenport2020-02-19   962   struct dpu_hw_blk 
*hw_lm[MAX_CHANNELS_PER_ENC];
b954fa6baaca7a Drew Davenport2020-02-19   963   int num_lm, num_ctl, 
num_pp;
de3916c70a24e3 Drew Davenport2020-02-19   964   int i, j;
25fdd5933e4c0f Jeykumar Sankaran 2018-06-27   965  
25fdd5933e4c0f Jeykumar Sankaran 2018-06-27   966   if (!drm_enc) {
25fdd5933e4c0f Jeykumar Sankaran 2018-06-27   967   
DPU_ERROR("invalid encoder\n");
25fdd5933e4c0f Jeykumar Sankaran 2018-06-27   968   return;
25fdd5933e4c0f Jeykumar Sankaran 2018-06-27   969   }
25fdd5933e4c0f Jeykumar Sankaran 2018-06-27   970  
25fdd5933e4c0f Jeykumar Sankaran 2018-06-27   971   dpu_enc = 
to_dpu_encoder_virt(drm_enc);
25fdd5933e4c0f Jeykumar Sankaran 2018-06-27   972   DPU_DEBUG_ENC(dpu_enc, 
"\n");
25fdd5933e4c0f Jeykumar Sankaran 2018-06-27   973  
25fdd5933e4c0f Jeykumar Sankaran 2018-06-27   974   priv = 
drm_enc->dev->dev_private;
25fdd5933e4c0f Jeykumar Sankaran 2018-06-27   975   dpu_kms = 
to_dpu_kms(priv->kms);
25fdd5933e4c0f Jeykumar Sankaran 2018-06-27   976   connector_list = 
_kms->dev->mode_config.connector_list;
25fdd5933e4c0f Jeykumar Sankaran 2018-06-27   977  
de3916c70a24e3 Drew Davenport2020-02-19   978   global_state = 
dpu_kms_get_existing_global_state(dpu_kms);
de3916c70a24e3 Drew Davenport2020-02-19   979   if 
(IS_ERR_OR_NULL(global_state)) {
de3916c70a24e3 Drew Davenport2020-02-19   980   
DPU_ERROR("Failed to get global state");
de3916c70a24e3 Drew Davenport2020-02-19   981   return;
de3916c70a24e3 Drew Davenport2020-02-19   982   }
de3916c70a24e3 Drew Davenport2020-02-19   983  
25fdd5933e4c0f Jeykumar Sankaran 2018-06-27   984   
trace_dpu_enc_mode_set(DRMID(drm_enc));
25fdd5933e4c0f Jeykumar Sankaran 2018-06-27   985  
25fdd5933e4c0f Jeykumar Sankaran 2018-06-27   986   
list_for_each_entry(conn_iter, connector_list, head)
25fdd5933e4c0f Jeykumar Sankaran 2018-06-27   987   if 
(conn_iter->encoder == drm_enc)
25fdd5933e4c0f Jeykumar Sankaran 2018-06-27   988   conn = 
conn_iter;

Re: [PATCH v5 0/6] capabilities: Introduce CAP_CHECKPOINT_RESTORE

[Serge E. Hallyn]

On Wed, Jul 15, 2020 at 04:49:48PM +0200, Adrian Reber wrote:
> This is v5 of the 'Introduce CAP_CHECKPOINT_RESTORE' patchset. The
> changes to v4 are:
> 
>  * split into more patches to have the introduction of
>CAP_CHECKPOINT_RESTORE and the actual usage in different
>patches
>  * reduce the /proc/self/exe patch to only be about
>CAP_CHECKPOINT_RESTORE
> 
> Adrian Reber (5):
>   capabilities: Introduce CAP_CHECKPOINT_RESTORE
>   pid: use checkpoint_restore_ns_capable() for set_tid
>   pid_namespace: use checkpoint_restore_ns_capable() for ns_last_pid
>   proc: allow access in init userns for map_files with CAP_CHECKPOINT_RESTORE
>   selftests: add clone3() CAP_CHECKPOINT_RESTORE test
> 
> Nicolas Viennot (1):
>   prctl: Allow checkpoint/restore capable processes to change exe link

(This is probably bad form, but)  All

Reviewed-by: Serge Hallyn 

Assuming you changes patches 4 and 6 per Christian's suggestions,
I'd like to re-review those then.

> 
>  fs/proc/base.c|   8 +-
>  include/linux/capability.h|   6 +
>  include/uapi/linux/capability.h   |   9 +-
>  kernel/pid.c  |   2 +-
>  kernel/pid_namespace.c|   2 +-
>  kernel/sys.c  |  12 +-
>  security/selinux/include/classmap.h   |   5 +-
>  tools/testing/selftests/clone3/Makefile   |   4 +-
>  .../clone3/clone3_cap_checkpoint_restore.c| 203 ++
>  9 files changed, 236 insertions(+), 15 deletions(-)
>  create mode 100644 
> tools/testing/selftests/clone3/clone3_cap_checkpoint_restore.c
> 
> 
> base-commit: d31958b30ea3b7b6e522d6bf449427748ad45822
> -- 
> 2.26.2

Re: [PATCH] locking: fcntl.h: drop duplicated word in a comment

[Matthew Wilcox]

On Fri, Jul 17, 2020 at 07:54:13PM -0700, Randy Dunlap wrote:
> +++ linux-next-20200714/include/uapi/asm-generic/fcntl.h
> @@ -143,7 +143,7 @@
>   * record  locks, but are "owned" by the open file description, not the
>   * process. This means that they are inherited across fork() like BSD (flock)
>   * locks, and they are only released automatically when the last reference to
> - * the the open file against which they were acquired is put.
> + * the open file against which they were acquired is put.

This is the kind of sentence up with which I shall not put!

How about "This means that they are inherited across fork() like BSD
  (flock) locks, and they are automatically released when the last
  reference is released for the file they were acquired against.

Even that is a bit too convoluted for my tastes.  Better suggestions
welcome.

Re: [PATCH v3 4/5] LSM: Define SELinux function to measure security state

[kernel test robot]

Hi Lakshmi,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on integrity/next-integrity]
[cannot apply to pcmoore-selinux/next security/next-testing linus/master 
v5.8-rc5 next-20200717]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Lakshmi-Ramasubramanian/LSM-Measure-security-module-state/20200718-063111
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git 
next-integrity
config: parisc-allyesconfig (attached as .config)
compiler: hppa-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=parisc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   security/selinux/measure.c: In function 'selinux_measure_state':
   security/selinux/measure.c:132:11: warning: comparison of unsigned 
expression >= 0 is always true [-Wtype-limits]
 132 |  if (curr >= 0 && curr < selinux_state_string_len)
 |   ^~
>> security/selinux/measure.c:148:2: error: implicit declaration of function 
>> 'vfree'; did you mean 'kvfree'? [-Werror=implicit-function-declaration]
 148 |  vfree(policy);
 |  ^
 |  kvfree
   cc1: some warnings being treated as errors

vim +148 security/selinux/measure.c

94  
95  void selinux_measure_state(struct selinux_state *selinux_state)
96  {
97  void *policy = NULL;
98  void *policy_hash = NULL;
99  size_t curr, buflen;
   100  int i, policy_hash_len, rc = 0;
   101  
   102  if (!selinux_initialized(selinux_state)) {
   103  pr_warn("%s: SELinux not yet initialized.\n", __func__);
   104  return;
   105  }
   106  
   107  if (!selinux_state_string) {
   108  pr_warn("%s: Buffer for state not allocated.\n", 
__func__);
   109  return;
   110  }
   111  
   112  curr = snprintf(selinux_state_string, selinux_state_string_len,
   113  str_format, "enabled",
   114  !selinux_disabled(selinux_state));
   115  curr += snprintf((selinux_state_string + curr),
   116   (selinux_state_string_len - curr),
   117   str_format, "enforcing",
   118   enforcing_enabled(selinux_state));
   119  curr += snprintf((selinux_state_string + curr),
   120   (selinux_state_string_len - curr),
   121   str_format, "checkreqprot",
   122   selinux_checkreqprot(selinux_state));
   123  
   124  for (i = 3; i < selinux_state_count; i++) {
   125  curr += snprintf((selinux_state_string + curr),
   126   (selinux_state_string_len - curr),
   127   str_format,
   128   selinux_policycap_names[i - 3],
   129   selinux_state->policycap[i - 3]);
   130  }
   131  
 > 132  if (curr >= 0 && curr < selinux_state_string_len)
   133  ima_lsm_state("selinux-state", selinux_state_string, 
curr);
   134  else {
   135  rc = -EINVAL;
   136  goto out;
   137  }
   138  
   139  rc = security_read_policy_kernel(selinux_state, , 
);
   140  if (!rc)
   141  rc = selinux_hash_policy("sha256", policy, buflen,
   142   _hash, 
_hash_len);
   143  if (!rc)
   144  ima_lsm_state("selinux-policy-hash", policy_hash,
   145policy_hash_len);
   146  
   147  out:
 > 148  vfree(policy);
   149  kfree(policy_hash);
   150  }
   151  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

Re: [RFC][PATCH] x86: optimization to avoid CAL+RES IPIs

[Andy Lutomirski]

> On Jul 17, 2020, at 7:13 PM, Josh Don  wrote:
>
> From: Venkatesh Pallipadi 
>
> smp_call_function_single and smp_send_reschedule send unconditional IPI
> to target CPU. However, if the target CPU is in some form of poll based
> idle, we can do IPI-less wakeups.
>
> Doing this has certain advantages:
> * Lower overhead on Async "no wait" IPI send path.
> * Avoiding actual interrupts reduces system non-idle cycles.
>
> Note that this only helps when target CPU is idle. When it is busy we
> will still send an IPI as before.

PeterZ and I fixed a whole series of bugs a few years ago, and remote
wakeups *should* already do this. Did we miss something?  Did it
regress?  Even the call_function_single path ought to go through this:

void send_call_function_single_ipi(int cpu)
{
struct rq *rq = cpu_rq(cpu);

if (!set_nr_if_polling(rq->idle))
arch_send_call_function_single_ipi(cpu);
else
trace_sched_wake_idle_without_ipi(cpu);
}


>
> *** RFC NOTE ***
> This patch breaks idle time accounting (and to a lesser degree, softirq
> accounting). This is because this patch violates the assumption that
> softirq can only be run either on the tail of a hard IRQ or inline on
> a non-idle thread via local_bh_enable(), since we can now process
> softirq inline within the idle loop. These ssues can be resolved in a
> later version of this patch.
>
> Signed-off-by: Josh Don 
> ---
> arch/x86/include/asm/mwait.h   |  5 +-
> arch/x86/include/asm/processor.h   |  1 +
> arch/x86/include/asm/thread_info.h |  2 +
> arch/x86/kernel/apic/ipi.c |  8 +++
> arch/x86/kernel/smpboot.c  |  4 ++
> drivers/cpuidle/poll_state.c   |  5 +-
> include/linux/ipiless_wake.h   | 93 ++
> kernel/sched/idle.c| 10 +++-
> 8 files changed, 124 insertions(+), 4 deletions(-)
> create mode 100644 include/linux/ipiless_wake.h
>
> diff --git a/arch/x86/include/asm/mwait.h b/arch/x86/include/asm/mwait.h
> index e039a933aca3..aed393f38a39 100644
> --- a/arch/x86/include/asm/mwait.h
> +++ b/arch/x86/include/asm/mwait.h
> @@ -2,6 +2,7 @@
> #ifndef _ASM_X86_MWAIT_H
> #define _ASM_X86_MWAIT_H
>
> +#include 
> #include 
> #include 
>
> @@ -109,6 +110,7 @@ static inline void __sti_mwait(unsigned long eax, 
> unsigned long ecx)
> static inline void mwait_idle_with_hints(unsigned long eax, unsigned long ecx)
> {
>if (static_cpu_has_bug(X86_BUG_MONITOR) || 
> !current_set_polling_and_test()) {
> +enter_ipiless_idle();
>if (static_cpu_has_bug(X86_BUG_CLFLUSH_MONITOR)) {
>mb();
>clflush((void *)_thread_info()->flags);
> @@ -116,8 +118,9 @@ static inline void mwait_idle_with_hints(unsigned long 
> eax, unsigned long ecx)
>}
>
>__monitor((void *)_thread_info()->flags, 0, 0);
> -if (!need_resched())
> +if (!is_ipiless_wakeup_pending())
>__mwait(eax, ecx);
> +exit_ipiless_idle();
>}
>current_clr_polling();
> }
> diff --git a/arch/x86/include/asm/processor.h 
> b/arch/x86/include/asm/processor.h
> index 03b7c4ca425a..045fc9bbd095 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -568,6 +568,7 @@ static inline void arch_thread_struct_whitelist(unsigned 
> long *offset,
>  * have to worry about atomic accesses.
>  */
> #define TS_COMPAT0x0002/* 32bit syscall active (64BIT)*/
> +#define TS_IPILESS_WAKEUP0x0010/* pending IPI-work on idle exit */

What's this for?

> +#define _TIF_IN_IPILESS_IDLE(1 << TIF_IN_IPILESS_IDLE)

We already have TIF_POLLING_NRFLAG.  Why do we need this?


> #include "local.h"
> @@ -67,11 +68,18 @@ void native_smp_send_reschedule(int cpu)
>WARN(1, "sched: Unexpected reschedule of offline CPU#%d!\n", cpu);
>return;
>}
> +
> +if (try_ipiless_wakeup(cpu))
> +return;
> +

I think this shouldn’t be called if the target is idle unless we lost
a race. What am I missing?

>apic->send_IPI(cpu, RESCHEDULE_VECTOR);
> }
>
> void native_send_call_func_single_ipi(int cpu)
> {
> +if (try_ipiless_wakeup(cpu))
> +return;
> +
>apic->send_IPI(cpu, CALL_FUNCTION_SINGLE_VECTOR);
> }

This function's caller already does this.

> +static inline void exit_ipiless_idle(void)
> +{
> +if (!test_and_clear_thread_flag(TIF_IN_IPILESS_IDLE)) {

This has the unfortunate property that, if you try to wake the same
polling CPU twice in rapid succession, the second try will send an
IPI.  One might debate whether this is a real problem, but the
existing code does not have this issue.

I could poke at this more, but I'm wondering whether you might have
developed this against a rather old kernel and blindly forward-ported
it.

--Andy

[PATCH net-next 4/4] net: dsa: Setup dsa_netdev_ops

[Florian Fainelli]

Now that we hav all the infrastructure in place for calling into the
dsa_ptr->netdev_ops function pointers, install them when we configure
the DSA CPU/management interface and tear them down. The flow is
unchanged from before, but now we preserve equality of tests when
network device drivers do tests like dev->netdev_ops == _ops which
was not the case before since we were allocating an entirely new
structure.

Signed-off-by: Florian Fainelli 
---
 include/net/dsa.h |  1 -
 net/dsa/master.c  | 52 ---
 2 files changed, 13 insertions(+), 40 deletions(-)

diff --git a/include/net/dsa.h b/include/net/dsa.h
index 681ba2752514..c9f350303947 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -230,7 +230,6 @@ struct dsa_port {
 * Original copy of the master netdev net_device_ops
 */
const struct dsa_netdevice_ops *netdev_ops;
-   const struct net_device_ops *orig_ndo_ops;
 
bool setup;
 };
diff --git a/net/dsa/master.c b/net/dsa/master.c
index 480a61460c23..0a90911ae31b 100644
--- a/net/dsa/master.c
+++ b/net/dsa/master.c
@@ -220,12 +220,17 @@ static int dsa_master_ioctl(struct net_device *dev, 
struct ifreq *ifr, int cmd)
break;
}
 
-   if (cpu_dp->orig_ndo_ops && cpu_dp->orig_ndo_ops->ndo_do_ioctl)
-   err = cpu_dp->orig_ndo_ops->ndo_do_ioctl(dev, ifr, cmd);
+   if (dev->netdev_ops->ndo_do_ioctl)
+   err = dev->netdev_ops->ndo_do_ioctl(dev, ifr, cmd);
 
return err;
 }
 
+static const struct dsa_netdevice_ops dsa_netdev_ops = {
+   .ndo_do_ioctl = dsa_master_ioctl,
+   .ndo_get_phys_port_name = dsa_master_get_phys_port_name,
+};
+
 static int dsa_master_ethtool_setup(struct net_device *dev)
 {
struct dsa_port *cpu_dp = dev->dsa_ptr;
@@ -260,38 +265,10 @@ static void dsa_master_ethtool_teardown(struct net_device 
*dev)
cpu_dp->orig_ethtool_ops = NULL;
 }
 
-static int dsa_master_ndo_setup(struct net_device *dev)
-{
-   struct dsa_port *cpu_dp = dev->dsa_ptr;
-   struct dsa_switch *ds = cpu_dp->ds;
-   struct net_device_ops *ops;
-
-   if (dev->netdev_ops->ndo_get_phys_port_name)
-   return 0;
-
-   ops = devm_kzalloc(ds->dev, sizeof(*ops), GFP_KERNEL);
-   if (!ops)
-   return -ENOMEM;
-
-   cpu_dp->orig_ndo_ops = dev->netdev_ops;
-   if (cpu_dp->orig_ndo_ops)
-   memcpy(ops, cpu_dp->orig_ndo_ops, sizeof(*ops));
-
-   ops->ndo_get_phys_port_name = dsa_master_get_phys_port_name;
-   ops->ndo_do_ioctl = dsa_master_ioctl;
-
-   dev->netdev_ops  = ops;
-
-   return 0;
-}
-
-static void dsa_master_ndo_teardown(struct net_device *dev)
+static void dsa_netdev_ops_set(struct net_device *dev,
+  const struct dsa_netdevice_ops *ops)
 {
-   struct dsa_port *cpu_dp = dev->dsa_ptr;
-
-   if (cpu_dp->orig_ndo_ops)
-   dev->netdev_ops = cpu_dp->orig_ndo_ops;
-   cpu_dp->orig_ndo_ops = NULL;
+   dev->dsa_ptr->netdev_ops = ops;
 }
 
 static ssize_t tagging_show(struct device *d, struct device_attribute *attr,
@@ -353,9 +330,7 @@ int dsa_master_setup(struct net_device *dev, struct 
dsa_port *cpu_dp)
if (ret)
return ret;
 
-   ret = dsa_master_ndo_setup(dev);
-   if (ret)
-   goto out_err_ethtool_teardown;
+   dsa_netdev_ops_set(dev, _netdev_ops);
 
ret = sysfs_create_group(>dev.kobj, _group);
if (ret)
@@ -364,8 +339,7 @@ int dsa_master_setup(struct net_device *dev, struct 
dsa_port *cpu_dp)
return ret;
 
 out_err_ndo_teardown:
-   dsa_master_ndo_teardown(dev);
-out_err_ethtool_teardown:
+   dsa_netdev_ops_set(dev, NULL);
dsa_master_ethtool_teardown(dev);
return ret;
 }
@@ -373,7 +347,7 @@ int dsa_master_setup(struct net_device *dev, struct 
dsa_port *cpu_dp)
 void dsa_master_teardown(struct net_device *dev)
 {
sysfs_remove_group(>dev.kobj, _group);
-   dsa_master_ndo_teardown(dev);
+   dsa_netdev_ops_set(dev, NULL);
dsa_master_ethtool_teardown(dev);
dsa_master_reset_mtu(dev);
 
-- 
2.25.1

[PATCH net-next 0/4] net: dsa: Setup dsa_netdev_ops

[Florian Fainelli]

Hi David, Jakub,

This patch series addresses the overloading of a DSA CPU/management
interface's netdev_ops for the purpose of providing useful information
from the switch side.

Up until now we had duplicated the existing netdev_ops structure and
added specific function pointers to return information of interest. Here
we have a more controlled way of doing this by involving the specific
netdev_ops function pointers that we want to be patched, which is easier
for auditing code in the future. As a byproduct we can now maintain
netdev_ops pointer comparisons which would be failing before (no known
in tree problems because of that though).

Let me know if this approach looks reasonable to you and we might do the
same with our ethtool_ops overloading as well.

Thanks!

Florian Fainelli (4):
  net: Wrap ndo_do_ioctl() to prepare for DSA stacked ops
  net: dsa: Add wrappers for overloaded ndo_ops
  net: Call into DSA netdevice_ops wrappers
  net: dsa: Setup dsa_netdev_ops

 include/net/dsa.h| 42 ++-
 net/core/dev.c   |  5 +
 net/core/dev_ioctl.c | 29 ++--
 net/dsa/master.c | 52 +++-
 4 files changed, 81 insertions(+), 47 deletions(-)

-- 
2.25.1

[PATCH net-next 1/4] net: Wrap ndo_do_ioctl() to prepare for DSA stacked ops

[Florian Fainelli]

In preparation for adding another layer of call into a DSA stacked ops
singleton, wrap the ndo_do_ioctl() call into dev_do_ioctl().

Signed-off-by: Florian Fainelli 
---
 net/core/dev_ioctl.c | 24 +---
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/net/core/dev_ioctl.c b/net/core/dev_ioctl.c
index 547b587c1950..a213c703c90a 100644
--- a/net/core/dev_ioctl.c
+++ b/net/core/dev_ioctl.c
@@ -225,6 +225,22 @@ static int net_hwtstamp_validate(struct ifreq *ifr)
return 0;
 }
 
+static int dev_do_ioctl(struct net_device *dev,
+   struct ifreq *ifr, unsigned int cmd)
+{
+   const struct net_device_ops *ops = dev->netdev_ops;
+   int err = -EOPNOTSUPP;
+
+   if (ops->ndo_do_ioctl) {
+   if (netif_device_present(dev))
+   err = ops->ndo_do_ioctl(dev, ifr, cmd);
+   else
+   err = -ENODEV;
+   }
+
+   return err;
+}
+
 /*
  * Perform the SIOCxIFxxx calls, inside rtnl_lock()
  */
@@ -323,13 +339,7 @@ static int dev_ifsioc(struct net *net, struct ifreq *ifr, 
unsigned int cmd)
cmd == SIOCSHWTSTAMP ||
cmd == SIOCGHWTSTAMP ||
cmd == SIOCWANDEV) {
-   err = -EOPNOTSUPP;
-   if (ops->ndo_do_ioctl) {
-   if (netif_device_present(dev))
-   err = ops->ndo_do_ioctl(dev, ifr, cmd);
-   else
-   err = -ENODEV;
-   }
+   err = dev_do_ioctl(dev, ifr, cmd);
} else
err = -EINVAL;
 
-- 
2.25.1

[PATCH net-next 2/4] net: dsa: Add wrappers for overloaded ndo_ops

[Florian Fainelli]

Add definitions for the dsa_netdevice_ops structure which is a subset of
the net_device_ops structure for the specific operations that we care
about overlaying on top of the DSA CPU port net_device and provide
inline stubs that take core managing whether DSA code is reachable.

Signed-off-by: Florian Fainelli 
---
 include/net/dsa.h | 41 +
 1 file changed, 41 insertions(+)

diff --git a/include/net/dsa.h b/include/net/dsa.h
index 6fa418ff1175..681ba2752514 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -86,6 +86,18 @@ struct dsa_device_ops {
enum dsa_tag_protocol proto;
 };
 
+/* This structure defines the control interfaces that are overlayed by the
+ * DSA layer on top of the DSA CPU/management net_device instance. This is
+ * used by the core net_device layer while calling various net_device_ops
+ * function pointers.
+ */
+struct dsa_netdevice_ops {
+   int (*ndo_do_ioctl)(struct net_device *dev, struct ifreq *ifr,
+   int cmd);
+   int (*ndo_get_phys_port_name)(struct net_device *dev, char *name,
+ size_t len);
+};
+
 #define DSA_TAG_DRIVER_ALIAS "dsa_tag-"
 #define MODULE_ALIAS_DSA_TAG_DRIVER(__proto)   \
MODULE_ALIAS(DSA_TAG_DRIVER_ALIAS __stringify(__proto##_VALUE))
@@ -217,6 +229,7 @@ struct dsa_port {
/*
 * Original copy of the master netdev net_device_ops
 */
+   const struct dsa_netdevice_ops *netdev_ops;
const struct net_device_ops *orig_ndo_ops;
 
bool setup;
@@ -679,6 +692,34 @@ static inline bool dsa_can_decode(const struct sk_buff 
*skb,
return false;
 }
 
+#if IS_ENABLED(CONFIG_NET_DSA)
+#define dsa_build_ndo_op(name, arg1_type, arg1_name, arg2_type, arg2_name) \
+static int inline dsa_##name(struct net_device *dev, arg1_type arg1_name, \
+arg2_type arg2_name)   \
+{  \
+   const struct dsa_netdevice_ops *ops;\
+   int err = -EOPNOTSUPP;  \
+   \
+   if (!dev->dsa_ptr)  \
+   return err; \
+   \
+   ops = dev->dsa_ptr->netdev_ops; \
+   if (!ops || !ops->name) \
+   return err; \
+   \
+   return ops->name(dev, arg1_name, arg2_name);\
+}
+#else
+#define dsa_build_ndo_op(name, ...)\
+static inline int dsa_##name(struct net_device *dev, ...) \
+{  \
+   return -EOPNOTSUPP; \
+}
+#endif
+
+dsa_build_ndo_op(ndo_do_ioctl, struct ifreq *, ifr, int, cmd);
+dsa_build_ndo_op(ndo_get_phys_port_name, char *, name, size_t, len);
+
 void dsa_unregister_switch(struct dsa_switch *ds);
 int dsa_register_switch(struct dsa_switch *ds);
 struct dsa_switch *dsa_switch_find(int tree_index, int sw_index);
-- 
2.25.1

[PATCH net-next 3/4] net: Call into DSA netdevice_ops wrappers

[Florian Fainelli]

Make the core net_device code call into our ndo_do_ioctl() and
ndo_get_phys_port_name() functions via the wrappers defined previously

Signed-off-by: Florian Fainelli 
---
 net/core/dev.c   | 5 +
 net/core/dev_ioctl.c | 5 +
 2 files changed, 10 insertions(+)

diff --git a/net/core/dev.c b/net/core/dev.c
index 062a00fdca9b..19f1abc26fcd 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -98,6 +98,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -8602,6 +8603,10 @@ int dev_get_phys_port_name(struct net_device *dev,
const struct net_device_ops *ops = dev->netdev_ops;
int err;
 
+   err  = dsa_ndo_get_phys_port_name(dev, name, len);
+   if (err == 0 || err != -EOPNOTSUPP)
+   return err;
+
if (ops->ndo_get_phys_port_name) {
err = ops->ndo_get_phys_port_name(dev, name, len);
if (err != -EOPNOTSUPP)
diff --git a/net/core/dev_ioctl.c b/net/core/dev_ioctl.c
index a213c703c90a..b2cf9b7bb7b8 100644
--- a/net/core/dev_ioctl.c
+++ b/net/core/dev_ioctl.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /*
@@ -231,6 +232,10 @@ static int dev_do_ioctl(struct net_device *dev,
const struct net_device_ops *ops = dev->netdev_ops;
int err = -EOPNOTSUPP;
 
+   err = dsa_ndo_do_ioctl(dev, ifr, cmd);
+   if (err == 0 || err != -EOPNOTSUPP)
+   return err;
+
if (ops->ndo_do_ioctl) {
if (netif_device_present(dev))
err = ops->ndo_do_ioctl(dev, ifr, cmd);
-- 
2.25.1

[PATCH v2] highmem: linux/highmem.h: fix duplicated words in a comment

[Randy Dunlap]

From: Randy Dunlap 

Change the doubled word "is" in a comment to "it is".

Signed-off-by: Randy Dunlap 
Cc: Andrew Morton 
Cc: linux...@kvack.org
---
v2: instead of dropping one "is", change to "it is" [thanks Willy]

 include/linux/highmem.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20200714.orig/include/linux/highmem.h
+++ linux-next-20200714/include/linux/highmem.h
@@ -73,7 +73,7 @@ static inline void kunmap(struct page *p
  * no global lock is needed and because the kmap code must perform a global TLB
  * invalidation when the kmap pool wraps.
  *
- * However when holding an atomic kmap is is not legal to sleep, so atomic
+ * However when holding an atomic kmap it is not legal to sleep, so atomic
  * kmaps are appropriate for short, tight code paths only.
  *
  * The use of kmap_atomic/kunmap_atomic is discouraged - kmap/kunmap

Re: [PATCH] LSM: drop duplicated words in header file comments

[Serge E. Hallyn]

On Fri, Jul 17, 2020 at 04:36:40PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap 
> 
> Drop the doubled words "the" and "and" in comments.
> 
> Signed-off-by: Randy Dunlap 
> Cc: James Morris 
> Cc: "Serge E. Hallyn" 

Acked-by: Serge Hallyn 

> Cc: linux-security-mod...@vger.kernel.org
> ---
>  include/linux/lsm_hook_defs.h |2 +-
>  include/linux/lsm_hooks.h |2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> --- linux-next-20200714.orig/include/linux/lsm_hook_defs.h
> +++ linux-next-20200714/include/linux/lsm_hook_defs.h
> @@ -15,7 +15,7 @@
>   */
>  
>  /*
> - * The macro LSM_HOOK is used to define the data structures required by the
> + * The macro LSM_HOOK is used to define the data structures required by
>   * the LSM framework using the pattern:
>   *
>   *   LSM_HOOK(, , , args...)
> --- linux-next-20200714.orig/include/linux/lsm_hooks.h
> +++ linux-next-20200714/include/linux/lsm_hooks.h
> @@ -822,7 +822,7 @@
>   *   structure. Note that the security field was not added directly to the
>   *   socket structure, but rather, the socket security information is stored
>   *   in the associated inode.  Typically, the inode alloc_security hook will
> - *   allocate and and attach security information to
> + *   allocate and attach security information to
>   *   SOCK_INODE(sock)->i_security.  This hook may be used to update the
>   *   SOCK_INODE(sock)->i_security field with additional information that
>   *   wasn't available when the inode was allocated.
> 

Re: [PATCH v2] usb: gadget: configfs: Fix use-after-free issue with udc_name

[Macpaul Lin]

On Sat, 2020-07-18 at 10:45 +0800, Macpaul Lin wrote:
> From: Eddie Hung 
> 

Well, it's strange, I simply replaced the uploader's name to my
colleague, git send-email pop up this line automatically.

Shouldn't I do that kind of change. It did not happened before.
Do I need to change it back and update patch v3?
 
> There is a use-after-free issue, if access udc_name
> in function gadget_dev_desc_UDC_store after another context
> free udc_name in function unregister_gadget.
> 
> Context 1:
> gadget_dev_desc_UDC_store()->unregister_gadget()->
> free udc_name->set udc_name to NULL
> 
> Context 2:
> gadget_dev_desc_UDC_show()-> access udc_name
> 
> Call trace:
> dump_backtrace+0x0/0x340
> show_stack+0x14/0x1c
> dump_stack+0xe4/0x134
> print_address_description+0x78/0x478
> __kasan_report+0x270/0x2ec
> kasan_report+0x10/0x18
> __asan_report_load1_noabort+0x18/0x20
> string+0xf4/0x138
> vsnprintf+0x428/0x14d0
> sprintf+0xe4/0x12c
> gadget_dev_desc_UDC_show+0x54/0x64
> configfs_read_file+0x210/0x3a0
> __vfs_read+0xf0/0x49c
> vfs_read+0x130/0x2b4
> SyS_read+0x114/0x208
> el0_svc_naked+0x34/0x38
> 
> Add mutex_lock to protect this kind of scenario.
> 
> Signed-off-by: Eddie Hung 
> Signed-off-by: Macpaul Lin 
> Reviewed-by: Peter Chen 
> Cc: sta...@vger.kernel.org
> ---
> Changes for v2:
>   - Fix typo %s/contex/context, Thanks Peter.
> 
>  drivers/usb/gadget/configfs.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)

Thanks.
Macpaul Lin

Re: [PATCH] clang: linux/compiler-clang.h: drop duplicated word in a comment

[Nathan Chancellor]

On Fri, Jul 17, 2020 at 07:55:02PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap 
> 
> Drop the doubled word "the" in a comment.
> 
> Signed-off-by: Randy Dunlap 
> Cc: clang-built-li...@googlegroups.com

Reviewed-by: Nathan Chancellor 

> ---
>  include/linux/compiler-clang.h |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- linux-next-20200714.orig/include/linux/compiler-clang.h
> +++ linux-next-20200714/include/linux/compiler-clang.h
> @@ -40,7 +40,7 @@
>  #endif
>  
>  /*
> - * Not all versions of clang implement the the type-generic versions
> + * Not all versions of clang implement the type-generic versions
>   * of the builtin overflow checkers. Fortunately, clang implements
>   * __has_builtin allowing us to avoid awkward version
>   * checks. Unfortunately, we don't know which version of gcc clang
> 

Re: [PATCH] highmem: linux/highmem.h: drop duplicated word in a comment

[Randy Dunlap]

On 7/17/20 7:53 PM, Matthew Wilcox wrote:
> On Fri, Jul 17, 2020 at 07:52:07PM -0700, Randy Dunlap wrote:
>>   *
>> - * However when holding an atomic kmap is is not legal to sleep, so atomic
>> + * However when holding an atomic kmap is not legal to sleep, so atomic
> 
> instead, s/is/it/
> 

Yes, will resend.

thanks.
-- 
~Randy

[PATCH] linux/exportfs.h: drop duplicated word in a comment

[Randy Dunlap]

From: Randy Dunlap 

Drop the doubled word "a" in a comment.

Signed-off-by: Randy Dunlap 
Cc: Alexander Viro 
Cc: linux-fsde...@vger.kernel.org
---
 include/linux/exportfs.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20200714.orig/include/linux/exportfs.h
+++ linux-next-20200714/include/linux/exportfs.h
@@ -178,7 +178,7 @@ struct fid {
  * get_name:
  *@get_name should find a name for the given @child in the given @parent
  *directory.  The name should be stored in the @name (with the
- *understanding that it is already pointing to a a %NAME_MAX+1 sized
+ *understanding that it is already pointing to a %NAME_MAX+1 sized
  *buffer.   get_name() should return %0 on success, a negative error code
  *or error.  @get_name will be called without @parent->i_mutex held.
  *

[PATCH] clang: linux/compiler-clang.h: drop duplicated word in a comment

[Randy Dunlap]

From: Randy Dunlap 

Drop the doubled word "the" in a comment.

Signed-off-by: Randy Dunlap 
Cc: clang-built-li...@googlegroups.com
---
 include/linux/compiler-clang.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20200714.orig/include/linux/compiler-clang.h
+++ linux-next-20200714/include/linux/compiler-clang.h
@@ -40,7 +40,7 @@
 #endif
 
 /*
- * Not all versions of clang implement the the type-generic versions
+ * Not all versions of clang implement the type-generic versions
  * of the builtin overflow checkers. Fortunately, clang implements
  * __has_builtin allowing us to avoid awkward version
  * checks. Unfortunately, we don't know which version of gcc clang

Re: [PATCH] capabilities: Replace HTTP links with HTTPS ones

[Serge E. Hallyn]

On Mon, Jul 13, 2020 at 12:34:28PM +0200, Alexander A. Klimov wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
> 
> Deterministic algorithm:
> For each file:
>   If not .svg:
> For each line:
>   If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
> If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
> If both the HTTP and HTTPS versions
> return 200 OK and serve the same content:
>   Replace HTTP with HTTPS.
> 
> Signed-off-by: Alexander A. Klimov 

Reviewed-by: Serge Hallyn 

> ---
>  Continuing my work started at 93431e0607e5.
>  See also: git log --oneline '--author=Alexander A. Klimov 
> ' v5.7..master
>  (Actually letting a shell for loop submit all this stuff for me.)
> 
>  If there are any URLs to be removed completely or at least not just 
> HTTPSified:
>  Just clearly say so and I'll *undo my change*.
>  See also: https://lkml.org/lkml/2020/6/27/64
> 
>  If there are any valid, but yet not changed URLs:
>  See: https://lkml.org/lkml/2020/6/26/837
> 
>  If you apply the patch, please let me know.
> 
>  Sorry again to all maintainers who complained about subject lines.
>  Now I realized that you want an actually perfect prefixes,
>  not just subsystem ones.
>  I tried my best...
>  And yes, *I could* (at least half-)automate it.
>  Impossible is nothing! :)
> 
> 
>  kernel/capability.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/capability.c b/kernel/capability.c
> index 1444f3954d75..a8a20ebc43ee 100644
> --- a/kernel/capability.c
> +++ b/kernel/capability.c
> @@ -40,7 +40,7 @@ __setup("no_file_caps", file_caps_disable);
>  /*
>   * More recent versions of libcap are available from:
>   *
> - *   http://www.kernel.org/pub/linux/libs/security/linux-privs/
> + *   https://www.kernel.org/pub/linux/libs/security/linux-privs/
>   */
>  
>  static void warn_legacy_capability_use(void)
> -- 
> 2.27.0

[PATCH] linux/async_tx.h: drop duplicated word in a comment

[Randy Dunlap]

From: Randy Dunlap 

Drop the doubled word "the" in a comment.

Signed-off-by: Randy Dunlap 
Cc: Dan Williams 
---
 include/linux/async_tx.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20200714.orig/include/linux/async_tx.h
+++ linux-next-20200714/include/linux/async_tx.h
@@ -36,7 +36,7 @@ struct dma_chan_ref {
 /**
  * async_tx_flags - modifiers for the async_* calls
  * @ASYNC_TX_XOR_ZERO_DST: this flag must be used for xor operations where the
- * the destination address is not a source.  The asynchronous case handles this
+ * destination address is not a source.  The asynchronous case handles this
  * implicitly, the synchronous case needs to zero the destination block.
  * @ASYNC_TX_XOR_DROP_DST: this flag must be used if the destination address is
  * also one of the source addresses.  In the synchronous case the destination

[PATCH] locking: fcntl.h: drop duplicated word in a comment

[Randy Dunlap]

From: Randy Dunlap 

Drop the doubled word "the" in a comment.

Signed-off-by: Randy Dunlap 
Cc: Jeff Layton 
Cc: "J. Bruce Fields" 
Cc: linux-fsde...@vger.kernel.org
---
 include/uapi/asm-generic/fcntl.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20200714.orig/include/uapi/asm-generic/fcntl.h
+++ linux-next-20200714/include/uapi/asm-generic/fcntl.h
@@ -143,7 +143,7 @@
  * record  locks, but are "owned" by the open file description, not the
  * process. This means that they are inherited across fork() like BSD (flock)
  * locks, and they are only released automatically when the last reference to
- * the the open file against which they were acquired is put.
+ * the open file against which they were acquired is put.
  */
 #define F_OFD_GETLK36
 #define F_OFD_SETLK37

[PATCH] linux/mdev.h: drop duplicated word in a comment

[Randy Dunlap]

From: Randy Dunlap 

Drop the doubled word "a" in a comment.

Signed-off-by: Randy Dunlap 
Cc: Kirti Wankhede 
Cc: k...@vger.kernel.org
---
 include/linux/mdev.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20200714.orig/include/linux/mdev.h
+++ linux-next-20200714/include/linux/mdev.h
@@ -42,7 +42,7 @@ struct device *mdev_get_iommu_device(str
  * @mdev: mdev_device structure on of mediated device
  *   that is being created
  * Returns integer: success (0) or error (< 0)
- * @remove:Called to free resources in parent device's driver for a
+ * @remove:Called to free resources in parent device's driver for
  * a mediated device. It is mandatory to provide 'remove'
  * ops.
  * @mdev: mdev_device device structure which is being

Re: [PATCH] highmem: linux/highmem.h: drop duplicated word in a comment

[Matthew Wilcox]

On Fri, Jul 17, 2020 at 07:52:07PM -0700, Randy Dunlap wrote:
>   *
> - * However when holding an atomic kmap is is not legal to sleep, so atomic
> + * However when holding an atomic kmap is not legal to sleep, so atomic

instead, s/is/it/

[PATCH] highmem: linux/highmem.h: drop duplicated word in a comment

[Randy Dunlap]

From: Randy Dunlap 

Drop the doubled word "is" in a comment.

Signed-off-by: Randy Dunlap 
Cc: Andrew Morton 
Cc: linux...@kvack.org
---
 include/linux/highmem.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20200714.orig/include/linux/highmem.h
+++ linux-next-20200714/include/linux/highmem.h
@@ -73,7 +73,7 @@ static inline void kunmap(struct page *p
  * no global lock is needed and because the kmap code must perform a global TLB
  * invalidation when the kmap pool wraps.
  *
- * However when holding an atomic kmap is is not legal to sleep, so atomic
+ * However when holding an atomic kmap is not legal to sleep, so atomic
  * kmaps are appropriate for short, tight code paths only.
  *
  * The use of kmap_atomic/kunmap_atomic is discouraged - kmap/kunmap

Re: Re: Re: Re: [PATCH v18 06/14] mm/damon: Implement callbacks for the virtual memory address spaces

[SeongJae Park]

On Fri, 17 Jul 2020 19:23:28 -0700 Shakeel Butt  wrote:

> On Fri, Jul 17, 2020 at 9:24 AM SeongJae Park  wrote:
> >
> > On Fri, 17 Jul 2020 08:17:09 -0700 Shakeel Butt  wrote:
> >
> > > On Thu, Jul 16, 2020 at 11:54 PM SeongJae Park  wrote:
> > > >
> > > > On Thu, 16 Jul 2020 17:46:54 -0700 Shakeel Butt  
> > > > wrote:
> > > >
> > > > > On Mon, Jul 13, 2020 at 1:44 AM SeongJae Park  
> > > > > wrote:
> > > > > >
> > > > > > From: SeongJae Park 
> > > > > >
> > > > > > This commit introduces a reference implementation of the address 
> > > > > > space
> > > > > > specific low level primitives for the virtual address space, so that
> > > > > > users of DAMON can easily monitor the data accesses on virtual 
> > > > > > address
> > > > > > spaces of specific processes by simply configuring the 
> > > > > > implementation to
> > > > > > be used by DAMON.
> > > > > >
> > > > > > The low level primitives for the fundamental access monitoring are
> > > > > > defined in two parts:
> > > > > > 1. Identification of the monitoring target address range for the 
> > > > > > address
> > > > > > space.
> > > > > > 2. Access check of specific address range in the target space.
> > > > > >
> > > > > > The reference implementation for the virtual address space provided 
> > > > > > by
> > > > > > this commit is designed as below.
> > > > > >
> > > > > > PTE Accessed-bit Based Access Check
> > > > > > ---
> > > > > >
> > > > > > The implementation uses PTE Accessed-bit for basic access checks.  
> > > > > > That
> > > > > > is, it clears the bit for next sampling target page and checks 
> > > > > > whether
> > > > > > it set again after one sampling period.  To avoid disturbing other
> > > > > > Accessed bit users such as the reclamation logic, the implementation
> > > > > > adjusts the ``PG_Idle`` and ``PG_Young`` appropriately, as same to 
> > > > > > the
> > > > > > 'Idle Page Tracking'.
> > > > > >
> > > > > > VMA-based Target Address Range Construction
> > > > > > ---
> > > > > >
> > > > > > Only small parts in the super-huge virtual address space of the
> > > > > > processes are mapped to physical memory and accessed.  Thus, 
> > > > > > tracking
> > > > > > the unmapped address regions is just wasteful.  However, because 
> > > > > > DAMON
> > > > > > can deal with some level of noise using the adaptive regions 
> > > > > > adjustment
> > > > > > mechanism, tracking every mapping is not strictly required but could
> > > > > > even incur a high overhead in some cases.  That said, too huge 
> > > > > > unmapped
> > > > > > areas inside the monitoring target should be removed to not take the
> > > > > > time for the adaptive mechanism.
> > > > > >
> > > > > > For the reason, this implementation converts the complex mappings to
> > > > > > three distinct regions that cover every mapped area of the address
> > > > > > space.  Also, the two gaps between the three regions are the two 
> > > > > > biggest
> > > > > > unmapped areas in the given address space.  The two biggest unmapped
> > > > > > areas would be the gap between the heap and the uppermost mmap()-ed
> > > > > > region, and the gap between the lowermost mmap()-ed region and the 
> > > > > > stack
> > > > > > in most of the cases.  Because these gaps are exceptionally huge in
> > > > > > usual address spacees, excluding these will be sufficient to make a
> > > > > > reasonable trade-off.  Below shows this in detail::
> > > > > >
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > (small mmap()-ed regions and munmap()-ed regions)
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > >
> > > > > > Signed-off-by: SeongJae Park 
> > > > > > Reviewed-by: Leonard Foerster 
> > > > > [snip]
> > > > > > +
> > > > > > +static void damon_mkold(struct mm_struct *mm, unsigned long addr)
> > > > > > +{
> > > > > > +   pte_t *pte = NULL;
> > > > > > +   pmd_t *pmd = NULL;
> > > > > > +   spinlock_t *ptl;
> > > > > > +
> > > > > > +   if (follow_pte_pmd(mm, addr, NULL, , , ))
> > > > > > +   return;
> > > > > > +
> > > > > > +   if (pte) {
> > > > > > +   if (pte_young(*pte)) {
> > > > >
> > > > > Any reason for skipping mmu_notifier_clear_young()? Why exclude VMs as
> > > > > DAMON's target applications?
> > > >
> > > > Obviously my mistake, thank you for pointing this!  I will add the 
> > > > function
> > > > call in the next spin.
> > > >
> > >
> > > Similarly mmu_notifier_test_young() for the damon_young().
> >
> > Yes, indeed.  Thanks for pointing this, either :)
> >
> > > BTW I think we can combine ctx->prepare_access_checks() and
> > > ctx->check_accesses() into one i.e. get the young state for the previous
> > > cycle and mkold for the next cycle in a single step.
> >
> > Yes, we could.  But, I'm unsure what is the advantage of doing that.  First 
> > of
> > all, if the combined implementation is required, peopld could simply 
> > 

[PATCH] frontswap: linux/frontswap.h: drop duplicated word in a comment

[Randy Dunlap]

From: Randy Dunlap 

Drop the doubled word "in" in a comment.

Signed-off-by: Randy Dunlap 
Cc: Konrad Rzeszutek Wilk 
Cc: Andrew Morton 
Cc: linux...@kvack.org
---
 include/linux/frontswap.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20200714.orig/include/linux/frontswap.h
+++ linux-next-20200714/include/linux/frontswap.h
@@ -10,7 +10,7 @@
 /*
  * Return code to denote that requested number of
  * frontswap pages are unused(moved to page cache).
- * Used in in shmem_unuse and try_to_unuse.
+ * Used in shmem_unuse and try_to_unuse.
  */
 #define FRONTSWAP_PAGES_UNUSED 2
 

[PATCH] dmaengine: linux/dmaengine.h: drop duplicated word in a comment

[Randy Dunlap]

From: Randy Dunlap 

Drop the doubled word "has" in a comment.

Signed-off-by: Randy Dunlap 
Cc: Vinod Koul 
Cc: dmaeng...@vger.kernel.org
---
 include/linux/dmaengine.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20200714.orig/include/linux/dmaengine.h
+++ linux-next-20200714/include/linux/dmaengine.h
@@ -164,7 +164,7 @@ struct dma_interleaved_template {
  * @DMA_PREP_INTERRUPT - trigger an interrupt (callback) upon completion of
  *  this transaction
  * @DMA_CTRL_ACK - if clear, the descriptor cannot be reused until the client
- *  acknowledges receipt, i.e. has has a chance to establish any dependency
+ *  acknowledges receipt, i.e. has a chance to establish any dependency
  *  chains
  * @DMA_PREP_PQ_DISABLE_P - prevent generation of P while generating Q
  * @DMA_PREP_PQ_DISABLE_Q - prevent generation of Q while generating P

Re: [PATCH v18 02/14] mm: Introduce Data Access MONitor (DAMON)

[Shakeel Butt]

On Mon, Jul 13, 2020 at 1:43 AM SeongJae Park  wrote:
>
> From: SeongJae Park 
>
> DAMON is a data access monitoring framework subsystem for the Linux
> kernel.  The core mechanisms of DAMON make it
>
>  - accurate (the monitoring output is useful enough for DRAM level
>memory management; It might not appropriate for CPU Cache levels,
>though),
>  - light-weight (the monitoring overhead is low enough to be applied
>online), and
>  - scalable (the upper-bound of the overhead is in constant range
>regardless of the size of target workloads).
>
> Using this framework, therefore, the kernel's memory management
> mechanisms can make advanced decisions.  Experimental memory management
> optimization works that incurring high data accesses monitoring overhead
> could implemented again.  In user space, meanwhile, users who have some
> special workloads can write personalized applications for better
> understanding and optimizations of their workloads and systems.
>
> This commit is implementing only the stub for the module load/unload,
> basic data structures, and simple manipulation functions of the
> structures to keep the size of commit small.  The core mechanisms of
> DAMON will be implemented one by one by following commits.
>
> Signed-off-by: SeongJae Park 
> Reviewed-by: Leonard Foerster 
> Reviewed-by: Varad Gautam 
> ---
>  include/linux/damon.h |  63 ++
>  mm/Kconfig|  12 +++
>  mm/Makefile   |   1 +
>  mm/damon.c| 188 ++
>  4 files changed, 264 insertions(+)
>  create mode 100644 include/linux/damon.h
>  create mode 100644 mm/damon.c
>
> diff --git a/include/linux/damon.h b/include/linux/damon.h
> new file mode 100644
> index ..c8f8c1c41a45
> --- /dev/null
> +++ b/include/linux/damon.h
> @@ -0,0 +1,63 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * DAMON api
> + *
> + * Copyright 2019-2020 Amazon.com, Inc. or its affiliates.
> + *
> + * Author: SeongJae Park 
> + */
> +
> +#ifndef _DAMON_H_
> +#define _DAMON_H_
> +
> +#include 
> +#include 
> +
> +/**
> + * struct damon_addr_range - Represents an address region of [@start, @end).
> + * @start: Start address of the region (inclusive).
> + * @end:   End address of the region (exclusive).
> + */
> +struct damon_addr_range {
> +   unsigned long start;
> +   unsigned long end;
> +};
> +
> +/**
> + * struct damon_region - Represents a monitoring target region.
> + * @ar:The address range of the region.
> + * @sampling_addr: Address of the sample for the next access check.
> + * @nr_accesses:   Access frequency of this region.
> + * @list:  List head for siblings.
> + */
> +struct damon_region {
> +   struct damon_addr_range ar;
> +   unsigned long sampling_addr;
> +   unsigned int nr_accesses;
> +   struct list_head list;
> +};
> +
> +/**
> + * struct damon_task - Represents a monitoring target task.
> + * @pid:   Process id of the task.
> + * @regions_list:  Head of the monitoring target regions of this task.
> + * @list:  List head for siblings.
> + *
> + * If the monitoring target address space is task independent (e.g., physical
> + * memory address space monitoring), @pid should be '-1'.
> + */
> +struct damon_task {
> +   int pid;

Storing and accessing pid like this is racy. Why not save the "struct
pid" after getting the reference? I am still going over the usage,
maybe storing mm_struct would be an even better choice.

> +   struct list_head regions_list;
> +   struct list_head list;
> +};
> +
> +/**
> + * struct damon_ctx - Represents a context for each monitoring.
> + * @tasks_list:Head of monitoring target tasks (_task) 
> list.
> + */
> +struct damon_ctx {
> +   struct list_head tasks_list;/* 'damon_task' objects */
> +};
> +
> +#endif
> diff --git a/mm/Kconfig b/mm/Kconfig
> index c1acc34c1c35..464e9594dcec 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -867,4 +867,16 @@ config ARCH_HAS_HUGEPD
>  config MAPPING_DIRTY_HELPERS
>  bool
>
> +config DAMON
> +   tristate "Data Access Monitor"
> +   depends on MMU
> +   help
> + This feature allows to monitor access frequency of each memory
> + region. The information can be useful for performance-centric DRAM
> + level memory management.
> +
> + See https://damonitor.github.io/doc/html/latest-damon/index.html for
> + more information.
> + If unsure, say N.
> +
>  endmenu
> diff --git a/mm/Makefile b/mm/Makefile
> index fccd3756b25f..230e545b6e07 100644
> --- a/mm/Makefile
> +++ b/mm/Makefile
> @@ -112,3 +112,4 @@ obj-$(CONFIG_MEMFD_CREATE) += memfd.o
>  obj-$(CONFIG_MAPPING_DIRTY_HELPERS) += mapping_dirty_helpers.o
>  obj-$(CONFIG_PTDUMP_CORE) += ptdump.o
>  obj-$(CONFIG_PAGE_REPORTING) += page_reporting.o
> +obj-$(CONFIG_DAMON) += damon.o
> diff --git a/mm/damon.c 

[PATCH v2] usb: gadget: configfs: Fix use-after-free issue with udc_name

[Macpaul Lin]

From: Eddie Hung 

There is a use-after-free issue, if access udc_name
in function gadget_dev_desc_UDC_store after another context
free udc_name in function unregister_gadget.

Context 1:
gadget_dev_desc_UDC_store()->unregister_gadget()->
free udc_name->set udc_name to NULL

Context 2:
gadget_dev_desc_UDC_show()-> access udc_name

Call trace:
dump_backtrace+0x0/0x340
show_stack+0x14/0x1c
dump_stack+0xe4/0x134
print_address_description+0x78/0x478
__kasan_report+0x270/0x2ec
kasan_report+0x10/0x18
__asan_report_load1_noabort+0x18/0x20
string+0xf4/0x138
vsnprintf+0x428/0x14d0
sprintf+0xe4/0x12c
gadget_dev_desc_UDC_show+0x54/0x64
configfs_read_file+0x210/0x3a0
__vfs_read+0xf0/0x49c
vfs_read+0x130/0x2b4
SyS_read+0x114/0x208
el0_svc_naked+0x34/0x38

Add mutex_lock to protect this kind of scenario.

Signed-off-by: Eddie Hung 
Signed-off-by: Macpaul Lin 
Reviewed-by: Peter Chen 
Cc: sta...@vger.kernel.org
---
Changes for v2:
  - Fix typo %s/contex/context, Thanks Peter.

 drivers/usb/gadget/configfs.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index 9dc06a4e1b30..21110b2865b9 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -221,9 +221,16 @@ static ssize_t gadget_dev_desc_bcdUSB_store(struct 
config_item *item,
 
 static ssize_t gadget_dev_desc_UDC_show(struct config_item *item, char *page)
 {
-   char *udc_name = to_gadget_info(item)->composite.gadget_driver.udc_name;
+   struct gadget_info *gi = to_gadget_info(item);
+   char *udc_name;
+   int ret;
+
+   mutex_lock(>lock);
+   udc_name = gi->composite.gadget_driver.udc_name;
+   ret = sprintf(page, "%s\n", udc_name ?: "");
+   mutex_unlock(>lock);
 
-   return sprintf(page, "%s\n", udc_name ?: "");
+   return ret;
 }
 
 static int unregister_gadget(struct gadget_info *gi)
-- 
2.18.0

Re: [External] Re: [PATCH RESEND] smp: Fix a potential usage of stale nr_cpus

[Muchun Song]

On Sat, Jul 18, 2020 at 4:15 AM Thomas Gleixner  wrote:
>
> Muchun,
>
> Muchun Song  writes:
>
> > The get_option() maybe return 0, it means that the nr_cpus is
> > not initialized.
>
> Good catch, but see below.
>
> > Then we will use the stale nr_cpus to initialize
>
> We use nothing. Please describe your changes in technical neutral
> language.
>
> > the nr_cpu_ids. So fix it.
>
> 'So fix it.' is not much valuable information. What about:
>
> Check the return value to prevent this.
>
> Hmm?

Looks fine to me. Thanks.

>
> > Signed-off-by: Muchun Song 
> > ---
> >  kernel/smp.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/kernel/smp.c b/kernel/smp.c
> > index 472c2b274c65..2a9a04acf123 100644
> > --- a/kernel/smp.c
> > +++ b/kernel/smp.c
> > @@ -634,8 +634,7 @@ static int __init nrcpus(char *str)
> >  {
> >   int nr_cpus;
> >
> > - get_option(, _cpus);
> > - if (nr_cpus > 0 && nr_cpus < nr_cpu_ids)
> > + if (get_option(, _cpus) && nr_cpus > 0 && nr_cpus < nr_cpu_ids)
> >   nr_cpu_ids = nr_cpus;
> >
> >   return 0;
>
> get_option() can return 0 - 3:
>
>  *  0 - no int in string
>  *  1 - int found, no subsequent comma
>  *  2 - int found including a subsequent comma
>  *  3 - hyphen found to denote a range
>
> For this parameter exists only one valid format: '1 - int found, no comma',
> right?

Yeah.

>
> So why fixing it just half and why returning '0' aka success if the
> parameter is bogus?

Thanks. Will fix it.

>
> Thanks,
>
> tglx



-- 
Yours,
Muchun

Re: Re: Re: [PATCH v18 06/14] mm/damon: Implement callbacks for the virtual memory address spaces

[Shakeel Butt]

On Fri, Jul 17, 2020 at 9:24 AM SeongJae Park  wrote:
>
> On Fri, 17 Jul 2020 08:17:09 -0700 Shakeel Butt  wrote:
>
> > On Thu, Jul 16, 2020 at 11:54 PM SeongJae Park  wrote:
> > >
> > > On Thu, 16 Jul 2020 17:46:54 -0700 Shakeel Butt  
> > > wrote:
> > >
> > > > On Mon, Jul 13, 2020 at 1:44 AM SeongJae Park  wrote:
> > > > >
> > > > > From: SeongJae Park 
> > > > >
> > > > > This commit introduces a reference implementation of the address space
> > > > > specific low level primitives for the virtual address space, so that
> > > > > users of DAMON can easily monitor the data accesses on virtual address
> > > > > spaces of specific processes by simply configuring the implementation 
> > > > > to
> > > > > be used by DAMON.
> > > > >
> > > > > The low level primitives for the fundamental access monitoring are
> > > > > defined in two parts:
> > > > > 1. Identification of the monitoring target address range for the 
> > > > > address
> > > > > space.
> > > > > 2. Access check of specific address range in the target space.
> > > > >
> > > > > The reference implementation for the virtual address space provided by
> > > > > this commit is designed as below.
> > > > >
> > > > > PTE Accessed-bit Based Access Check
> > > > > ---
> > > > >
> > > > > The implementation uses PTE Accessed-bit for basic access checks.  
> > > > > That
> > > > > is, it clears the bit for next sampling target page and checks whether
> > > > > it set again after one sampling period.  To avoid disturbing other
> > > > > Accessed bit users such as the reclamation logic, the implementation
> > > > > adjusts the ``PG_Idle`` and ``PG_Young`` appropriately, as same to the
> > > > > 'Idle Page Tracking'.
> > > > >
> > > > > VMA-based Target Address Range Construction
> > > > > ---
> > > > >
> > > > > Only small parts in the super-huge virtual address space of the
> > > > > processes are mapped to physical memory and accessed.  Thus, tracking
> > > > > the unmapped address regions is just wasteful.  However, because DAMON
> > > > > can deal with some level of noise using the adaptive regions 
> > > > > adjustment
> > > > > mechanism, tracking every mapping is not strictly required but could
> > > > > even incur a high overhead in some cases.  That said, too huge 
> > > > > unmapped
> > > > > areas inside the monitoring target should be removed to not take the
> > > > > time for the adaptive mechanism.
> > > > >
> > > > > For the reason, this implementation converts the complex mappings to
> > > > > three distinct regions that cover every mapped area of the address
> > > > > space.  Also, the two gaps between the three regions are the two 
> > > > > biggest
> > > > > unmapped areas in the given address space.  The two biggest unmapped
> > > > > areas would be the gap between the heap and the uppermost mmap()-ed
> > > > > region, and the gap between the lowermost mmap()-ed region and the 
> > > > > stack
> > > > > in most of the cases.  Because these gaps are exceptionally huge in
> > > > > usual address spacees, excluding these will be sufficient to make a
> > > > > reasonable trade-off.  Below shows this in detail::
> > > > >
> > > > > 
> > > > > 
> > > > > 
> > > > > (small mmap()-ed regions and munmap()-ed regions)
> > > > > 
> > > > > 
> > > > > 
> > > > >
> > > > > Signed-off-by: SeongJae Park 
> > > > > Reviewed-by: Leonard Foerster 
> > > > [snip]
> > > > > +
> > > > > +static void damon_mkold(struct mm_struct *mm, unsigned long addr)
> > > > > +{
> > > > > +   pte_t *pte = NULL;
> > > > > +   pmd_t *pmd = NULL;
> > > > > +   spinlock_t *ptl;
> > > > > +
> > > > > +   if (follow_pte_pmd(mm, addr, NULL, , , ))
> > > > > +   return;
> > > > > +
> > > > > +   if (pte) {
> > > > > +   if (pte_young(*pte)) {
> > > >
> > > > Any reason for skipping mmu_notifier_clear_young()? Why exclude VMs as
> > > > DAMON's target applications?
> > >
> > > Obviously my mistake, thank you for pointing this!  I will add the 
> > > function
> > > call in the next spin.
> > >
> >
> > Similarly mmu_notifier_test_young() for the damon_young().
>
> Yes, indeed.  Thanks for pointing this, either :)
>
> > BTW I think we can combine ctx->prepare_access_checks() and
> > ctx->check_accesses() into one i.e. get the young state for the previous
> > cycle and mkold for the next cycle in a single step.
>
> Yes, we could.  But, I'm unsure what is the advantage of doing that.  First of
> all, if the combined implementation is required, peopld could simply implement
> the two logics in the combined way in one of the callbacks and leave the other
> one blank.  Also, I'm worrying if combining those could make the code a little
> bit hard to read.  IMHO, I think separating those makes the 'kdamond_fn()' 
> code
> little bit easier to read.  Actually, I started from the combined approach but
> separated the two logics since v7 after 

[GIT PULL] FPGA Manager changes for 5.9-rc1

[Moritz Fischer]

The following changes since commit b3a9e3b9622ae10064826dccb4f7a52bd88c7407:

  Linux 5.8-rc1 (2020-06-14 12:45:04 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mdf/linux-fpga.git 
tags/fpga-for-5.9

for you to fetch changes up to eacfbf589c904bf8362cbd2d6cac123b0230e272:

  fpga: dfl: pci: add device id for Intel FPGA PAC N3000 (2020-07-12 19:00:37 
-0700)


FPGA Manager changes for 5.9-rc1

Here is the (slightly larger than usual) patch set for the 5.9-rc1 merge
window.

DFL:
- Xu's changes add support for AFU interrupt handling and puts them to
  use for error handling.
- Xu's other change also adds another device-id for the Intel FPGA PAC N3000.
- John's change converts from using get_user_pages() to
  pin_user_pages().
- Gustavo's patch cleans up some of the allocation by using
  struct_size().

Xilinx:
- Luca's changes clean up the xilinx-spi and xilinx-slave-serial drivers
  and updates the comments and dt-bindings to reflect the fact it also
  supports 7 series devices.

Core:
- Tom cleaned up the fpga-bridge / fpga-mgr core by removing some
  dead-stores.

All patches have been reviewed on the mailing list, and have been in the
last few linux-next releases (as part of my for-next branch) without issues.

Signed-off-by: Moritz Fischer 


Gustavo A. R. Silva (1):
  fpga: dfl: Use struct_size() in kzalloc()

John Hubbard (1):
  fpga: dfl: afu: convert get_user_pages() --> pin_user_pages()

Luca Ceresoli (5):
  dt-bindings: fpga: xilinx-slave-serial: valid for the 7 Series too
  fpga manager: xilinx-spi: valid for the 7 Series too
  fpga manager: xilinx-spi: remove unneeded, mistyped variables
  dt-bindings: fpga: xilinx-slave-serial: add optional INIT_B GPIO
  fpga manager: xilinx-spi: check INIT_B pin during write_init

Tom Rix (2):
  fpga: Fix dead store fpga-mgr.c
  fpga: Fix dead store in fpga-bridge.c

Xu Yilun (8):
  fpga: dfl: parse interrupt info for feature devices on enumeration
  fpga: dfl: pci: add irq info for feature devices enumeration
  fpga: dfl: introduce interrupt trigger setting API
  fpga: dfl: afu: add interrupt support for port error reporting
  fpga: dfl: fme: add interrupt support for global error reporting
  fpga: dfl: afu: add AFU interrupt support
  Documentation: fpga: dfl: add descriptions for interrupt related 
interfaces.
  fpga: dfl: pci: add device id for Intel FPGA PAC N3000

 .../bindings/fpga/xilinx-slave-serial.txt  |  16 +-
 Documentation/fpga/dfl.rst |  19 ++
 drivers/fpga/dfl-afu-dma-region.c  |  19 +-
 drivers/fpga/dfl-afu-error.c   |  17 ++
 drivers/fpga/dfl-afu-main.c|  32 +++
 drivers/fpga/dfl-fme-error.c   |  18 ++
 drivers/fpga/dfl-fme-main.c|   6 +
 drivers/fpga/dfl-pci.c |  78 -
 drivers/fpga/dfl.c | 313 -
 drivers/fpga/dfl.h |  63 -
 drivers/fpga/fpga-bridge.c |   6 +-
 drivers/fpga/fpga-mgr.c|   4 +-
 drivers/fpga/xilinx-spi.c  |  61 +++-
 include/uapi/linux/fpga-dfl.h  |  82 ++
 14 files changed, 687 insertions(+), 47 deletions(-)

[RFC][PATCH] x86: optimization to avoid CAL+RES IPIs

[Josh Don]

From: Venkatesh Pallipadi 

smp_call_function_single and smp_send_reschedule send unconditional IPI
to target CPU. However, if the target CPU is in some form of poll based
idle, we can do IPI-less wakeups.

Doing this has certain advantages:
* Lower overhead on Async "no wait" IPI send path.
* Avoiding actual interrupts reduces system non-idle cycles.

Note that this only helps when target CPU is idle. When it is busy we
will still send an IPI as before.

*** RFC NOTE ***
This patch breaks idle time accounting (and to a lesser degree, softirq
accounting). This is because this patch violates the assumption that
softirq can only be run either on the tail of a hard IRQ or inline on
a non-idle thread via local_bh_enable(), since we can now process
softirq inline within the idle loop. These ssues can be resolved in a
later version of this patch.

Signed-off-by: Josh Don 
---
 arch/x86/include/asm/mwait.h   |  5 +-
 arch/x86/include/asm/processor.h   |  1 +
 arch/x86/include/asm/thread_info.h |  2 +
 arch/x86/kernel/apic/ipi.c |  8 +++
 arch/x86/kernel/smpboot.c  |  4 ++
 drivers/cpuidle/poll_state.c   |  5 +-
 include/linux/ipiless_wake.h   | 93 ++
 kernel/sched/idle.c| 10 +++-
 8 files changed, 124 insertions(+), 4 deletions(-)
 create mode 100644 include/linux/ipiless_wake.h

diff --git a/arch/x86/include/asm/mwait.h b/arch/x86/include/asm/mwait.h
index e039a933aca3..aed393f38a39 100644
--- a/arch/x86/include/asm/mwait.h
+++ b/arch/x86/include/asm/mwait.h
@@ -2,6 +2,7 @@
 #ifndef _ASM_X86_MWAIT_H
 #define _ASM_X86_MWAIT_H
 
+#include 
 #include 
 #include 
 
@@ -109,6 +110,7 @@ static inline void __sti_mwait(unsigned long eax, unsigned 
long ecx)
 static inline void mwait_idle_with_hints(unsigned long eax, unsigned long ecx)
 {
if (static_cpu_has_bug(X86_BUG_MONITOR) || 
!current_set_polling_and_test()) {
+   enter_ipiless_idle();
if (static_cpu_has_bug(X86_BUG_CLFLUSH_MONITOR)) {
mb();
clflush((void *)_thread_info()->flags);
@@ -116,8 +118,9 @@ static inline void mwait_idle_with_hints(unsigned long eax, 
unsigned long ecx)
}
 
__monitor((void *)_thread_info()->flags, 0, 0);
-   if (!need_resched())
+   if (!is_ipiless_wakeup_pending())
__mwait(eax, ecx);
+   exit_ipiless_idle();
}
current_clr_polling();
 }
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 03b7c4ca425a..045fc9bbd095 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -568,6 +568,7 @@ static inline void arch_thread_struct_whitelist(unsigned 
long *offset,
  * have to worry about atomic accesses.
  */
 #define TS_COMPAT  0x0002  /* 32bit syscall active (64BIT)*/
+#define TS_IPILESS_WAKEUP  0x0010  /* pending IPI-work on idle exit */
 
 static inline void
 native_load_sp0(unsigned long sp0)
diff --git a/arch/x86/include/asm/thread_info.h 
b/arch/x86/include/asm/thread_info.h
index 8de8ceccb8bc..b6d3fa3c1578 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -98,6 +98,7 @@ struct thread_info {
 #define TIF_IO_BITMAP  22  /* uses I/O bitmap */
 #define TIF_FORCED_TF  24  /* true if TF in eflags artificially */
 #define TIF_BLOCKSTEP  25  /* set when we want DEBUGCTLMSR_BTF */
+#define TIF_IN_IPILESS_IDLE26  /* task in IPIless idle state */
 #define TIF_LAZY_MMU_UPDATES   27  /* task is updating the mmu lazily */
 #define TIF_SYSCALL_TRACEPOINT 28  /* syscall tracepoint instrumentation */
 #define TIF_ADDR32 29  /* 32-bit address space on 64 bits */
@@ -127,6 +128,7 @@ struct thread_info {
 #define _TIF_IO_BITMAP (1 << TIF_IO_BITMAP)
 #define _TIF_FORCED_TF (1 << TIF_FORCED_TF)
 #define _TIF_BLOCKSTEP (1 << TIF_BLOCKSTEP)
+#define _TIF_IN_IPILESS_IDLE   (1 << TIF_IN_IPILESS_IDLE)
 #define _TIF_LAZY_MMU_UPDATES  (1 << TIF_LAZY_MMU_UPDATES)
 #define _TIF_SYSCALL_TRACEPOINT(1 << TIF_SYSCALL_TRACEPOINT)
 #define _TIF_ADDR32(1 << TIF_ADDR32)
diff --git a/arch/x86/kernel/apic/ipi.c b/arch/x86/kernel/apic/ipi.c
index 6ca0f91372fd..6739aea98aee 100644
--- a/arch/x86/kernel/apic/ipi.c
+++ b/arch/x86/kernel/apic/ipi.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 
 #include 
+#include 
 #include 
 
 #include "local.h"
@@ -67,11 +68,18 @@ void native_smp_send_reschedule(int cpu)
WARN(1, "sched: Unexpected reschedule of offline CPU#%d!\n", 
cpu);
return;
}
+
+   if (try_ipiless_wakeup(cpu))
+   return;
+
apic->send_IPI(cpu, RESCHEDULE_VECTOR);
 }
 
 void native_send_call_func_single_ipi(int cpu)
 {
+   if (try_ipiless_wakeup(cpu))
+   return;
+
apic->send_IPI(cpu, 

Re: [PATCH] tools/memory-model: document the "one-time init" pattern

[Matthew Wilcox]

On Fri, Jul 17, 2020 at 06:38:39PM -0700, Eric Biggers wrote:
> On Fri, Jul 17, 2020 at 06:47:50PM +0100, Matthew Wilcox wrote:
> > On Thu, Jul 16, 2020 at 09:44:27PM -0700, Eric Biggers wrote:
> > > +If that doesn't apply, you'll have to implement one-time init yourself.
> > > +
> > > +The simplest implementation just uses a mutex and an 'inited' flag.
> > > +This implementation should be used where feasible:
> > 
> > I think some syntactic sugar should make it feasible for normal people
> > to implement the most efficient version of this just like they use locks.
> 
> Note that the cmpxchg version is not necessarily the "most efficient".
> 
> If the one-time initialization is expensive, e.g. if it allocates a lot of
> memory or if takes a long time, it could be better to use the mutex version so
> that at most one task does it.

Sure, but I think those are far less common than just allocating a single
thing.

> > How about something like this ...
> > 
> > once.h:
> > 
> > static struct init_once_pointer {
> > void *p;
> > };
> > 
> > static inline void *once_get(struct init_once_pointer *oncep)
> > { ... }
> > 
> > static inline bool once_store(struct init_once_pointer *oncep, void *p)
> > { ... }
> > 
> > --- foo.c ---
> > 
> > struct foo *get_foo(gfp_t gfp)
> > {
> > static struct init_once_pointer my_foo;
> > struct foo *foop;
> > 
> > foop = once_get(_foo);
> > if (foop)
> > return foop;
> > 
> > foop = alloc_foo(gfp);
> > if (!once_store(_foo, foop)) {
> > free_foo(foop);
> > foop = once_get(_foo);
> > }
> > 
> > return foop;
> > }
> > 
> > Any kernel programmer should be able to handle that pattern.  And no mutex!
> 
> I don't think this version would be worthwhile.  It eliminates type safety due
> to the use of 'void *', and doesn't actually save any lines of code.  Nor does
> it eliminate the need to correctly implement the cmpxchg failure case, which 
> is
> tricky (it must free the object and get the new one) and will be rarely 
> tested.

You're missing the point.  It prevents people from trying to optimise
"can I use READ_ONCE() here, or do I need to use smp_rmb()?"  The type
safety is provided by the get_foo() function.  I suppose somebody could
play some games with _Generic or something, but there's really no need to.
It's like using a list_head and casting to the container_of.

> It also forces all users of the struct to use this helper function to access 
> it.
> That could be considered a good thing, but it's also bad because even with
> one-time init there's still usually some sort of ordering of "initialization"
> vs. "use".  Just taking a random example I'm familiar with, we do one-time 
> init
> of inode::i_crypt_info when we open an encrypted file, so we guarantee it's 
> set
> for all I/O to the file, where we then simply access ->i_crypt_info directly.
> We don't want the code to read like it's initializing ->i_crypt_info in the
> middle of ->writepages(), since that would be wrong.

Right, and I wouldn't use this pattern for that.  You can't get to
writepages without having opened the file, so just initialising the
pointer in open is fine.

> An improvement might be to make once_store() take the free function as a
> parameter so that it would handle the failure case for you:
> 
> struct foo *get_foo(gfp_t gfp)
> {
>   static struct init_once_pointer my_foo;
>   struct foo *foop;
>  
>   foop = once_get(_foo);
>   if (!foop) {
>   foop = alloc_foo(gfp);
>   if (foop)
>   once_store(_foo, foop, free_foo);

Need to mark once_store as __must_check to avoid the bug you have here:

foop = once_store(_foo, foop, free_foo);

Maybe we could use a macro for once_store so we could write:

void *once_get(struct init_pointer_once *);
int once_store(struct init_pointer_once *, void *);

#define once_alloc(s, o_alloc, o_free) ({   \
void *__p = o_alloc;\
if (__p) {  \
if (!once_store(s, __p)) {  \
o_free(__p);\
__p = once_get(s);  \
}   \
}   \
__p;\
})

---

struct foo *alloc_foo(gfp_t);
void free_foo(struct foo *);

struct foo *get_foo(gfp_t gfp)
{
static struct init_pointer_once my_foo;
struct foo *foop;

foop = once_get(_foo);
if (!foop)
foop = once_alloc(_foo, alloc_foo(gfp), free_foo);
return foop;
}

That's pretty hard to misuse (I compile-tested it, and it works).

Re: [PATCH net-next 0/2] net: atlantic: add support for FW 4.x

[David Miller]

From: Mark Starovoytov 
Date: Fri, 17 Jul 2020 21:01:45 +0300

> This patch set adds support for FW 4.x, which is about to get into the
> production for some products.
> 4.x is mostly compatible with 3.x, save for soft reset, which requires
> the acquisition of 2 additional semaphores.
> Other differences (e.g. absence of PTP support) are handled via
> capabilities.
> 
> Note: 4.x targets specific products only. 3.x is still the main firmware
> branch, which should be used by most users (at least for now).

Series applied, thanks.

Re: [PATCH] tools/memory-model: document the "one-time init" pattern

[Dave Chinner]

On Fri, Jul 17, 2020 at 09:25:55PM -0400, Alan Stern wrote:
> On Fri, Jul 17, 2020 at 05:58:57PM -0700, Eric Biggers wrote:
> > On Fri, Jul 17, 2020 at 01:53:40PM -0700, Darrick J. Wong wrote:
> > > > +There are also cases in which the smp_load_acquire() can be replaced by
> > > > +the more lightweight READ_ONCE().  (smp_store_release() is still
> > > > +required.)  Specifically, if all initialized memory is transitively
> > > > +reachable from the pointer itself, then there is no control dependency
> > > 
> > > I don't quite understand what "transitively reachable from the pointer
> > > itself" means?  Does that describe the situation where all the objects
> > > reachable through the object that the global struct foo pointer points
> > > at are /only/ reachable via that global pointer?
> > > 
> > 
> > The intent is that "transitively reachable" means that all initialized 
> > memory
> > can be reached by dereferencing the pointer in some way, e.g. p->a->b[5]->c.
> > 
> > It could also be the case that allocating the object initializes some 
> > global or
> > static data, which isn't reachable in that way.  Access to that data would 
> > then
> > be a control dependency, which a data dependency barrier wouldn't work for.
> > 
> > It's possible I misunderstood something.  (Note the next paragraph does say 
> > that
> > using READ_ONCE() is discouraged, exactly for this reason -- it can be hard 
> > to
> > tell whether it's correct.)  Suggestions of what to write here are 
> > appreciated.
> 
> Perhaps something like this:
> 
>   Specifically, if the only way to reach the initialized memory 
>   involves dereferencing the pointer itself then READ_ONCE() is 
>   sufficient.  This is because there will be an address dependency 
>   between reading the pointer and accessing the memory, which will 
>   ensure proper ordering.  But if some of the initialized memory 
>   is reachable some other way (for example, if it is global or 
>   static data) then there need not be an address dependency, 
>   merely a control dependency (checking whether the pointer is 
>   non-NULL).  Control dependencies do not always ensure ordering 
>   -- certainly not for reads, and depending on the compiler, 
>   possibly not for some writes -- and therefore a load-acquire is 
>   necessary.

Recipes are aimed at people who simply don't understand any of that
goobledegook. This won't help them -write correct code-.

> Perhaps this is more wordy than you want, but it does get the important 
> ideas across.

You think they are important because you understand what those words
mean.  Large numbers of developers do not understand what they mean,
nor how to put them into practise correctly.

Seriously: if you want people to use this stuff correctly, you need
to -dumb it down-, not make it even more challenging by explaining
words people don't understand with yet more words they don't
understand...

This is the "curse of knowledge" cognative bias in a nutshell.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [PATCH] tools/memory-model: document the "one-time init" pattern

[Eric Biggers]

On Fri, Jul 17, 2020 at 09:25:55PM -0400, Alan Stern wrote:
> On Fri, Jul 17, 2020 at 05:58:57PM -0700, Eric Biggers wrote:
> > On Fri, Jul 17, 2020 at 01:53:40PM -0700, Darrick J. Wong wrote:
> > > > +There are also cases in which the smp_load_acquire() can be replaced by
> > > > +the more lightweight READ_ONCE().  (smp_store_release() is still
> > > > +required.)  Specifically, if all initialized memory is transitively
> > > > +reachable from the pointer itself, then there is no control dependency
> > > 
> > > I don't quite understand what "transitively reachable from the pointer
> > > itself" means?  Does that describe the situation where all the objects
> > > reachable through the object that the global struct foo pointer points
> > > at are /only/ reachable via that global pointer?
> > > 
> > 
> > The intent is that "transitively reachable" means that all initialized 
> > memory
> > can be reached by dereferencing the pointer in some way, e.g. p->a->b[5]->c.
> > 
> > It could also be the case that allocating the object initializes some 
> > global or
> > static data, which isn't reachable in that way.  Access to that data would 
> > then
> > be a control dependency, which a data dependency barrier wouldn't work for.
> > 
> > It's possible I misunderstood something.  (Note the next paragraph does say 
> > that
> > using READ_ONCE() is discouraged, exactly for this reason -- it can be hard 
> > to
> > tell whether it's correct.)  Suggestions of what to write here are 
> > appreciated.
> 
> Perhaps something like this:
> 
>   Specifically, if the only way to reach the initialized memory 
>   involves dereferencing the pointer itself then READ_ONCE() is 
>   sufficient.  This is because there will be an address dependency 
>   between reading the pointer and accessing the memory, which will 
>   ensure proper ordering.  But if some of the initialized memory 
>   is reachable some other way (for example, if it is global or 
>   static data) then there need not be an address dependency, 
>   merely a control dependency (checking whether the pointer is 
>   non-NULL).  Control dependencies do not always ensure ordering 
>   -- certainly not for reads, and depending on the compiler, 
>   possibly not for some writes -- and therefore a load-acquire is 
>   necessary.
> 
> Perhaps this is more wordy than you want, but it does get the important 
> ideas across.
> 

How about:

There are also cases in which the smp_load_acquire() can be replaced by
the more lightweight READ_ONCE().  (smp_store_release() is still
required.)  Specifically, if the only way to reach the initialized
memory involves dereferencing the pointer itself, then the data
dependency barrier provided by READ_ONCE() is sufficient.  However, if
some of the initialized memory is reachable some other way (for example,
if it is global or static data) then there need not be an address
dependency, merely a control dependency (checking whether the pointer is
non-NULL).  READ_ONCE() is *not* sufficient in that case.

The optimization of replacing smp_load_acquire() with READ_ONCE() is
discouraged for nontrivial data structures, since it can be difficult to
determine if it is correct.  In particular, for complex data structures
the correctness of the READ_ONCE() optimization may depend on internal
implementation details of other kernel subsystems.

Re: [net-next PATCH v3 2/7] net: hsr: introduce common code for skb initialization

[David Miller]

From: Murali Karicheri 
Date: Fri, 17 Jul 2020 11:15:06 -0400

> +static void send_hsr_supervision_frame(struct hsr_port *master,
> +u8 type, u8 hsr_ver)
> +{
> + struct sk_buff *skb;
> + struct hsr_tag *hsr_tag;
> + struct hsr_sup_tag *hsr_stag;
> + struct hsr_sup_payload *hsr_sp;
> + unsigned long irqflags;

Reverse christmas tree please.

Re: [net-next PATCH v3 1/7] hsr: enhance netlink socket interface to support PRP

[David Miller]

From: Murali Karicheri 
Date: Fri, 17 Jul 2020 11:15:05 -0400

> @@ -32,7 +33,9 @@ static int hsr_newlink(struct net *src_net, struct 
> net_device *dev,
>  struct netlink_ext_ack *extack)
>  {
>   struct net_device *link[2];
> - unsigned char multicast_spec, hsr_version;
> + unsigned char multicast_spec;
> + enum hsr_version proto_version;
> + u8 proto = HSR_PROTOCOL_HSR;

Please use reverse christmas tree ordering for local variables.

Thank you.

Re: [PATCH 2/2 v2] net: hsr: validate address B before copying to skb

[David Miller]

From: Murali Karicheri 
Date: Fri, 17 Jul 2020 10:55:10 -0400

> Validate MAC address before copying the same to outgoing frame
> skb destination address. Since a node can have zero mac
> address for Link B until a valid frame is received over
> that link, this fix address the issue of a zero MAC address
> being in the packet.
> 
> Signed-off-by: Murali Karicheri 

Applied.

Re: [PATCH 1/2 v2] net: hsr: fix incorrect lsdu size in the tag of HSR frames for small frames

[David Miller]

From: Murali Karicheri 
Date: Fri, 17 Jul 2020 10:55:09 -0400

> For small Ethernet frames with size less than minimum size 66 for HSR
> vs 60 for regular Ethernet frames, hsr driver currently doesn't pad the
> frame to make it minimum size. This results in incorrect LSDU size being
> populated in the HSR tag for these frames. Fix this by padding the frame
> to the minimum size applicable for HSR.
> 
> Signed-off-by: Murali Karicheri 

Applied.

Re: [PATCH] net: ethernet: et131x: Remove redundant register read

[David Miller]

From: Mark Einon 
Date: Fri, 17 Jul 2020 14:21:35 +0100

> Following the removal of an unused variable assignment (remove
> unused variable 'pm_csr') the associated register read can also go,
> as the read also occurs in the subsequent et1310_in_phy_coma()
> call.
> 
> Signed-off-by: Mark Einon 

Applied to net-next.

Re: [PATCH] net: ethernet: ti: add NETIF_F_HW_TC hw feature flag for taprio offload

[David Miller]

From: Grygorii Strashko 
Date: Fri, 17 Jul 2020 15:19:32 +0300

> From: Murali Karicheri 
> 
> Currently drive supports taprio offload which is a tc feature offloaded
> to cpsw hardware. So driver has to set the hw feature flag, NETIF_F_HW_TC
> in the net device to be compliant. This patch adds the flag.
> 
> Fixes: 8127224c2708 ("ethernet: ti: am65-cpsw-qos: add TAPRIO offload 
> support")
> Signed-off-by: Murali Karicheri 
> Signed-off-by: Grygorii Strashko 

How was the commit adding TAPRIO support even tested since without the
NETIF_F_HW_TC bit set tc_can_offload() always returns false?

Re: [PATCH net-next] net: ethernet: et131x: Remove unused variable 'pm_csr'

[David Miller]

From: Zhang Changzhong 
Date: Fri, 17 Jul 2020 18:33:30 +0800

> Gcc report warning as follows:
> 
> drivers/net/ethernet/agere/et131x.c:953:6: warning:
>  variable 'pm_csr' set but not used [-Wunused-but-set-variable]
>   953 |  u32 pm_csr;
>   |  ^~
> drivers/net/ethernet/agere/et131x.c:1002:6:warning:
>  variable 'pm_csr' set but not used [-Wunused-but-set-variable]
>  1002 |  u32 pm_csr;
>   |  ^~
> drivers/net/ethernet/agere/et131x.c:3446:8: warning:
>  variable 'pm_csr' set but not used [-Wunused-but-set-variable]
>  3446 |u32 pm_csr;
>   |^~
> 
> After commit 38df6492eb51 ("et131x: Add PCIe gigabit ethernet driver
> et131x to drivers/net"), 'pm_csr' is never used in these functions,
> so removing it to avoid build warning.
> 
> Reported-by: Hulk Robot 
> Signed-off-by: Zhang Changzhong 

Applied.

Re: [PATCH] Fix memory overwriting issue when copy an address to user space

[David Miller]

From: lebon zhou 
Date: Fri, 17 Jul 2020 10:31:54 +

> When application provided buffer size less than sockaddr_storage, then
> kernel will overwrite some memory area which may cause memory corruption,
> e.g.: in recvmsg case, let msg_name=malloc(8) and msg_namelen=8, then
> usually application can call recvmsg successful but actually application
> memory get corrupted.
> 
> Fix to return EINVAL when application buffer size less than
> sockaddr_storage.
> 
> Signed-off-by: lebon.zhou 

Please post networking fixes to net...@vger.kernel.org

Thank you.

Re: [PATCH net-next] net: bna: Remove unused variable 't'

[David Miller]

From: Zhang Changzhong 
Date: Fri, 17 Jul 2020 18:23:04 +0800

> Gcc report warning as follows:
> 
> drivers/net/ethernet/brocade/bna/bfa_ioc.c:1538:6: warning:
>  variable 't' set but not used [-Wunused-but-set-variable]
>  1538 |  u32 t;
>   |  ^
> 
> After commit c107ba171f3d ("bna: Firmware Patch Simplification"),
> 't' is never used, so removing it to avoid build warning.
> 
> Reported-by: Hulk Robot 
> Signed-off-by: Zhang Changzhong 

Applied, thanks.

Re: [PATCH] tools/memory-model: document the "one-time init" pattern

[Dave Chinner]

On Thu, Jul 16, 2020 at 09:44:27PM -0700, Eric Biggers wrote:
> From: Eric Biggers 
> 
> The "one-time init" pattern is implemented incorrectly in various places
> in the kernel.  And when people do try to implement it correctly, it is
> unclear what to use.  Try to give some proper guidance.
> 
> This is motivated by the discussion at
> https://lkml.kernel.org/linux-fsdevel/2020071300.205104-1-ebigg...@kernel.org/T/#u
> regarding fixing the initialization of super_block::s_dio_done_wq.

You're still using words that the target audience of the
documentation will not understand.

This is known as the "curse of knowledge" cognative bias, where
subject matter experts try to explain something to non-experts using
terms only subject matter experts understand

This is one of the reasons that the LKMM documetnation is so damn
difficult to read and understand: just understanding the vocabulary
it uses requires a huge learning curve, and it's not defined
anywhere. Understanding the syntax of examples requires a huge
learning curve, because it's not defined anywhere. 

Recipes are *not useful* if you need to understand the LKMM
documenation to select the correct recipe to use. Recipes are not
useful if you say "here's 5 different variations of the same thing,
up to you to understand which one you need to use". Recipes are not
useful if changes in other code can silently break the recipe that
was selected by the user by carefully considering the most optimal
variant at the time they selected it.

i.e. Recipes are not for experts who understand the LKMM - recipes
are for developers who don't really understand how the LKMM all
works and just want a single, solid, reliable pattern they can use
just about everywhere for that specific operation.

Performance and optimisation doesn't even enter the picture here -
we need to provide a simple, easy to use and understand pattern that
just works. We need to stop making this harder than it should be.

So

> Cc: Nicholas Piggin 
> Cc: Paul E. McKenney 
> Cc: Peter Zijlstra 
> Cc: Will Deacon 
> Signed-off-by: Eric Biggers 
> ---
>  tools/memory-model/Documentation/recipes.txt | 151 +++
>  1 file changed, 151 insertions(+)
> 
> diff --git a/tools/memory-model/Documentation/recipes.txt 
> b/tools/memory-model/Documentation/recipes.txt
> index 7fe8d7aa3029..04beb06dbfc7 100644
> --- a/tools/memory-model/Documentation/recipes.txt
> +++ b/tools/memory-model/Documentation/recipes.txt
> @@ -519,6 +519,157 @@ CPU1 puts the waiting task to sleep and CPU0 fails to 
> wake it up.
>  
>  Note that use of locking can greatly simplify this pattern.
>  
> +One-time init
> +-
> +
> +The "one-time init" pattern is when multiple tasks can race to
> +initialize the same data structure(s) on first use.
> +
> +In many cases, it's best to just avoid the need for this by simply
> +initializing the data ahead of time.
> +
> +But in cases where the data would often go unused, one-time init can be
> +appropriate to avoid wasting kernel resources.  It can also be
> +appropriate if the initialization has other prerequisites which preclude
> +it being done ahead of time.
> +
> +First, consider if your data has (a) global or static scope, (b) can be
> +initialized from atomic context, and (c) cannot fail to be initialized.
> +If all of those apply, just use DO_ONCE() from :
> +
> + DO_ONCE(func);
> +
> +If that doesn't apply, you'll have to implement one-time init yourself.
> +
> +The simplest implementation just uses a mutex and an 'inited' flag.
> +This implementation should be used where feasible:
> +
> + static bool foo_inited;
> + static DEFINE_MUTEX(foo_init_mutex);
> +
> + int init_foo_if_needed(void)
> + {
> + int err = 0;
> +
> + mutex_lock(_init_mutex);
> + if (!foo_inited) {
> + err = init_foo();
> + if (err == 0)
> + foo_inited = true;
> + }
> + mutex_unlock(_init_mutex);
> + return err;
> + }
> +
> +The above example uses static variables, but this solution also works
> +for initializing something that is part of another data structure.  The
> +mutex may still be static.

All good up to here - people will see this and understand that this
is the pattern they want to use, and DO_ONCE() is a great, simple
API that is easy to use.

What needs to follow is a canonical example of how to do it
locklessly and efficiently, without describing conditional use of it
using words like "initialised memory is transitively reachable" (I
don't know WTF that means!).  Don't discuss potential optimisations,
control flow/data dependencies, etc, because failing to understand
those details are the reason people are looking for a simple recipe
that does what they need in the first place ("curse of knowledge").

However, I think the whole problem around code like this is that it
is being open-coded and that is the 

Re: [PATCH] tools/memory-model: document the "one-time init" pattern

[Matthew Wilcox]

On Fri, Jul 17, 2020 at 09:25:55PM -0400, Alan Stern wrote:
> On Fri, Jul 17, 2020 at 05:58:57PM -0700, Eric Biggers wrote:
> > On Fri, Jul 17, 2020 at 01:53:40PM -0700, Darrick J. Wong wrote:
> > > > +There are also cases in which the smp_load_acquire() can be replaced by
> > > > +the more lightweight READ_ONCE().  (smp_store_release() is still
> > > > +required.)  Specifically, if all initialized memory is transitively
> > > > +reachable from the pointer itself, then there is no control dependency
> > > 
> > > I don't quite understand what "transitively reachable from the pointer
> > > itself" means?  Does that describe the situation where all the objects
> > > reachable through the object that the global struct foo pointer points
> > > at are /only/ reachable via that global pointer?
> > > 
> > 
> > The intent is that "transitively reachable" means that all initialized 
> > memory
> > can be reached by dereferencing the pointer in some way, e.g. p->a->b[5]->c.
> > 
> > It could also be the case that allocating the object initializes some 
> > global or
> > static data, which isn't reachable in that way.  Access to that data would 
> > then
> > be a control dependency, which a data dependency barrier wouldn't work for.
> > 
> > It's possible I misunderstood something.  (Note the next paragraph does say 
> > that
> > using READ_ONCE() is discouraged, exactly for this reason -- it can be hard 
> > to
> > tell whether it's correct.)  Suggestions of what to write here are 
> > appreciated.
> 
> Perhaps something like this:
> 
>   Specifically, if the only way to reach the initialized memory 
>   involves dereferencing the pointer itself then READ_ONCE() is 
>   sufficient.  This is because there will be an address dependency 
>   between reading the pointer and accessing the memory, which will 
>   ensure proper ordering.  But if some of the initialized memory 
>   is reachable some other way (for example, if it is global or 
>   static data) then there need not be an address dependency, 
>   merely a control dependency (checking whether the pointer is 
>   non-NULL).  Control dependencies do not always ensure ordering 
>   -- certainly not for reads, and depending on the compiler, 
>   possibly not for some writes -- and therefore a load-acquire is 
>   necessary.
> 
> Perhaps this is more wordy than you want, but it does get the important 
> ideas across.

I don't think we should worry about wordsmithing this.  We should just
say "Use the init_pointer_once API" and then people who want to worry
about optimising the implementation of that API never have to talk to
the people who want to use that API.

Re: linux-next: Tree for Jul 17 (drivers/rtc/rtc-ds1374.o)

[Stephen Rothwell]

Hi Randy,

[Please trim your emails a bit more, thanks]

On Fri, 17 Jul 2020 09:49:05 -0700 Randy Dunlap  wrote:
> on x86_64:
> # CONFIG_WATCHDOG is not set
> 
> ld: drivers/rtc/rtc-ds1374.o: in function `ds1374_probe':
> rtc-ds1374.c:(.text+0x736): undefined reference to `watchdog_init_timeout'
> ld: rtc-ds1374.c:(.text+0x77e): undefined reference to 
> `devm_watchdog_register_device'

Caused by commit

  d3de4beb14a8 ("rtc: ds1374: wdt: Use watchdog core for watchdog part")

from the rtc tree.
-- 
Cheers,
Stephen Rothwell


pgpoVJaP86VqL.pgp
Description: OpenPGP digital signature

Re: [PATCH 1/6] syscalls: use uaccess_kernel in addr_limit_user_check

[Guenter Roeck]

Hi,

On Tue, Jul 14, 2020 at 12:55:00PM +0200, Christoph Hellwig wrote:
> Use the uaccess_kernel helper instead of duplicating it.
> 
> Signed-off-by: Christoph Hellwig 

This patch causes a severe hiccup with my mps2-an385 boot test.

[8.545195] [ cut here ]
[8.545294] WARNING: CPU: 0 PID: 1 at ./include/linux/syscalls.h:267 
addr_limit_check_failed+0x11/0x24
[8.545376] Invalid address limit on user-mode return
[8.545487] CPU: 0 PID: 1 Comm: init Not tainted 5.8.0-rc5-next-20200717 #1
[8.545603] Hardware name: MPS2 (Device Tree Support)
[8.546053] [<2100af9d>] (unwind_backtrace) from [<2100a353>] 
(show_stack+0xb/0xc)
[8.546240] [<2100a353>] (show_stack) from [<2100dadb>] (__warn+0x6f/0x80)
[8.546311] [<2100dadb>] (__warn) from [<2100db1d>] 
(warn_slowpath_fmt+0x31/0x60)
[8.546383] [<2100db1d>] (warn_slowpath_fmt) from [<2100a159>] 
(addr_limit_check_failed+0x11/0x24)
[8.546464] [<2100a159>] (addr_limit_check_failed) from [<210080f3>] 
(ret_to_user_from_irq+0xf/0x18)
[8.546567] Exception stack(0x21427fb0 to 0x21427ff8)
[8.546649] 7fa0:   
 
[8.546729] 7fc0:       
21744f80 
[8.546800] 7fe0:  21757fa8  21700b6c 0100 
[8.546910] ---[ end trace f1b0cd10cc3456dc ]---

This keeps happening until qemu aborts.

Reverting the patch isn't possible since segment_eq() is gone in
next-20200717.

Guenter

---
# bad: [aab7ee9f8ff0110bfcd594b33dc33748dc1baf46] Add linux-next specific files 
for 20200717
# good: [11ba468877bb23f28956a35e896356252d63c983] Linux 5.8-rc5
git bisect start 'HEAD' 'v5.8-rc5'
# good: [4d55a7a1298d197755c1a0f4512f56917e938a83] Merge remote-tracking branch 
'crypto/master'
git bisect good 4d55a7a1298d197755c1a0f4512f56917e938a83
# good: [e63bf5dcce255302e355cb2277a3a39c83752c92] Merge remote-tracking branch 
'devicetree/for-next'
git bisect good e63bf5dcce255302e355cb2277a3a39c83752c92
# good: [94d932ec3afb923efd8c736974f8316413175a5b] Merge remote-tracking branch 
'thunderbolt/next'
git bisect good 94d932ec3afb923efd8c736974f8316413175a5b
# good: [5ddd2e0dbe8fceb80b0b36bd38a32217be7a04a5] Merge remote-tracking branch 
'livepatching/for-next'
git bisect good 5ddd2e0dbe8fceb80b0b36bd38a32217be7a04a5
# bad: [40346f79983caf46fb92f779b0353422d43580a9] ipc/shm.c: Remove the 
superfluous break
git bisect bad 40346f79983caf46fb92f779b0353422d43580a9
# good: [0b917599517f71ddef5f7274a8199a33cecd49b2] kasan: update required 
compiler versions in documentation
git bisect good 0b917599517f71ddef5f7274a8199a33cecd49b2
# good: [701571ae06641cc0632d113a6d25f54ce651e723] mm,hwpoison: rework soft 
offline for free pages
git bisect good 701571ae06641cc0632d113a6d25f54ce651e723
# bad: [1c21deffe923b068d2d297c248845ec93531d1bf] lib/test_bits.c: add tests of 
GENMASK
git bisect bad 1c21deffe923b068d2d297c248845ec93531d1bf
# bad: [9549375184b2cb4f63fa7917665acf9c44114499] uaccess: add 
force_uaccess_{begin,end} helpers
git bisect bad 9549375184b2cb4f63fa7917665acf9c44114499
# good: [233d009c15719e43c53b73296144664e0bd59a2e] mm/memory_hotplug: introduce 
default dummy memory_add_physaddr_to_nid()
git bisect good 233d009c15719e43c53b73296144664e0bd59a2e
# good: [42889ca325dd735ce964838cff81a444637d9d01] mm: drop duplicated words in 

git bisect good 42889ca325dd735ce964838cff81a444637d9d01
# bad: [3b17e98704eedeeff41672b2f64cef1bbefbb8b2] nds32: use uaccess_kernel in 
show_regs
git bisect bad 3b17e98704eedeeff41672b2f64cef1bbefbb8b2
# bad: [02dc30b876b111276fe7d83d492ddfc2b39b80e3] syscalls: use uaccess_kernel 
in addr_limit_user_check
git bisect bad 02dc30b876b111276fe7d83d492ddfc2b39b80e3
# first bad commit: [02dc30b876b111276fe7d83d492ddfc2b39b80e3] syscalls: use 
uaccess_kernel in addr_limit_user_check

Re: [PATCH] net: cxgb3: add missed destroy_workqueue in cxgb3 probe failure

[David Miller]

From: Wang Hai 
Date: Fri, 17 Jul 2020 14:21:17 +0800

> The driver forgets to call destroy_workqueue when cxgb3 probe fails.
> Add the missed calls to fix it.
> 
> Fixes: 4d22de3e6cc4 ("Add support for the latest 1G/10G Chelsio adapter, T3.")
> Reported-by: Hulk Robot 
> Signed-off-by: Wang Hai 

You have to handle the case that the probing of one or more devices
fails yet one or more others succeed.

And you can't know in advance how this will play out.

This is why the workqueue is unconditionally created, and only destroyed
on module remove.

Re: [PATCH] tools/memory-model: document the "one-time init" pattern

[Eric Biggers]

On Fri, Jul 17, 2020 at 06:47:50PM +0100, Matthew Wilcox wrote:
> On Thu, Jul 16, 2020 at 09:44:27PM -0700, Eric Biggers wrote:
> > +If that doesn't apply, you'll have to implement one-time init yourself.
> > +
> > +The simplest implementation just uses a mutex and an 'inited' flag.
> > +This implementation should be used where feasible:
> 
> I think some syntactic sugar should make it feasible for normal people
> to implement the most efficient version of this just like they use locks.

Note that the cmpxchg version is not necessarily the "most efficient".

If the one-time initialization is expensive, e.g. if it allocates a lot of
memory or if takes a long time, it could be better to use the mutex version so
that at most one task does it.

> How about something like this ...
> 
> once.h:
> 
> static struct init_once_pointer {
>   void *p;
> };
> 
> static inline void *once_get(struct init_once_pointer *oncep)
> { ... }
> 
> static inline bool once_store(struct init_once_pointer *oncep, void *p)
> { ... }
> 
> --- foo.c ---
> 
> struct foo *get_foo(gfp_t gfp)
> {
>   static struct init_once_pointer my_foo;
>   struct foo *foop;
> 
>   foop = once_get(_foo);
>   if (foop)
>   return foop;
> 
>   foop = alloc_foo(gfp);
>   if (!once_store(_foo, foop)) {
>   free_foo(foop);
>   foop = once_get(_foo);
>   }
> 
>   return foop;
> }
> 
> Any kernel programmer should be able to handle that pattern.  And no mutex!

I don't think this version would be worthwhile.  It eliminates type safety due
to the use of 'void *', and doesn't actually save any lines of code.  Nor does
it eliminate the need to correctly implement the cmpxchg failure case, which is
tricky (it must free the object and get the new one) and will be rarely tested.

It also forces all users of the struct to use this helper function to access it.
That could be considered a good thing, but it's also bad because even with
one-time init there's still usually some sort of ordering of "initialization"
vs. "use".  Just taking a random example I'm familiar with, we do one-time init
of inode::i_crypt_info when we open an encrypted file, so we guarantee it's set
for all I/O to the file, where we then simply access ->i_crypt_info directly.
We don't want the code to read like it's initializing ->i_crypt_info in the
middle of ->writepages(), since that would be wrong.

An improvement might be to make once_store() take the free function as a
parameter so that it would handle the failure case for you:

struct foo *get_foo(gfp_t gfp)
{
static struct init_once_pointer my_foo;
struct foo *foop;
 
foop = once_get(_foo);
if (!foop) {
foop = alloc_foo(gfp);
if (foop)
once_store(_foo, foop, free_foo);
}
return foop;
}

I'm not sure even that version would be worthwhile, though.

What I do like is DO_ONCE() in , which is used as just:

DO_ONCE(func)

But it has limitations:

   - Only atomic context
   - Initialization can't fail
   - Only global/static data

We could address the first two limitations by splitting it into DO_ONCE_ATOMIC()
and DO_ONCE_BLOCKING(), and by allowing the initialization function to return an
error code.  That would make it work for all global/static data cases, I think.

Ideally we'd have something almost as simple for non-global/non-static data too.
I'm not sure the best way to do it, though.  It would have to be something more
complex like:

ONETIME_INIT_DATA(_foo, alloc_foo, free_foo)

- Eric

Re: [PATCH] rhashtable: drop duplicated word in

[David Miller]

From: Randy Dunlap 
Date: Fri, 17 Jul 2020 16:37:25 -0700

> From: Randy Dunlap 
> 
> Drop the doubled word "be" in a comment.
> 
> Signed-off-by: Randy Dunlap 

Applied, thank you.

Re: [PATCH net] net: macb: use phy_interface_mode_is_rgmii everywhere

[David Miller]

From: Alexandre Belloni 
Date: Sat, 18 Jul 2020 01:32:21 +0200

> There is one RGMII check not using the phy_interface_mode_is_rgmii()
> helper. This prevents the driver from configuring the MAC properly when
> using a phy-mode that is not just rgmii, e.g. rgmii-rxid. This became an
> issue on sama5d3 xplained since the ksz9031 driver is hadling phy-mode
> properly and the phy-mode has to be set to rgmii-rxid.
> 
> Fixes: bcf3440c6dd78bfe ("net: phy: micrel: add phy-mode support for the 
> KSZ9031 PHY")
> Signed-off-by: Alexandre Belloni 

Applied, thank you.

Re: [PATCH] crypto: hash.h: drop duplicated word in a comment

[David Miller]

From: Randy Dunlap 
Date: Fri, 17 Jul 2020 16:35:33 -0700

> From: Randy Dunlap 
> 
> Drop the doubled word "in" in a comment.
> 
> Signed-off-by: Randy Dunlap 

Acked-by: David S. Miller 

Re: [PATCH] crypto: skcipher.h: drop duplicated word in kernel-doc

[David Miller]

From: Randy Dunlap 
Date: Fri, 17 Jul 2020 16:35:49 -0700

> From: Randy Dunlap 
> 
> Drop the doubled word "request" in a kernel-doc comment.
> 
> Signed-off-by: Randy Dunlap 

Acked-by: David S. Miller 

Re: mmotm 2020-07-16-22-52 uploaded (mm/hugetlb.c)

[Stephen Rothwell]

Hi Randy,

On Fri, 17 Jul 2020 08:35:45 -0700 Randy Dunlap  wrote:
>
> on i386:
> 6 of 10 builds failed with:
> 
> ../mm/hugetlb.c:1302:20: error: redefinition of 
> ‘destroy_compound_gigantic_page’
>  static inline void destroy_compound_gigantic_page(struct hstate *h,
> ^~
> ../mm/hugetlb.c:1223:13: note: previous definition of 
> ‘destroy_compound_gigantic_page’ was here
>  static void destroy_compound_gigantic_page(struct hstate *h, struct page 
> *page,
>  ^~

Reported here: 
https://lore.kernel.org/lkml/20200717213127.3bd42...@canb.auug.org.au/

> ../mm/hugetlb.c:1223:13: warning: ‘destroy_compound_gigantic_page’ defined 
> but not used [-Wunused-function]
> ../mm/hugetlb.c:50:https://lore.kernel.org/lkml/2020070919.0b63f...@canb.auug.org.au/20:
>  warning: ‘hugetlb_cma’ defined but not used [-Wunused-variable]
>  static struct cma *hugetlb_cma[MAX_NUMNODES];
> ^~~

Reported here: 
https://lore.kernel.org/lkml/2020070919.0b63f...@canb.auug.org.au/

-- 
Cheers,
Stephen Rothwell


pgpODB4XGnSTJ.pgp
Description: OpenPGP digital signature

Re: mmotm 2020-07-16-22-52 uploaded (net: IPVS)

[Stephen Rothwell]

Hi all,

On Fri, 17 Jul 2020 08:30:04 -0700 Randy Dunlap  wrote:
>
> (also in linux-next)
> 
> Many of these errors:
> 
> In file included from ../net/netfilter/ipvs/ip_vs_conn.c:37:0:
> ../include/net/ip_vs.h: In function ‘ip_vs_enqueue_expire_nodest_conns’:
> ../include/net/ip_vs.h:1536:61: error: parameter name omitted
>  static inline void ip_vs_enqueue_expire_nodest_conns(struct netns_ipvs) {}

Caused by commit

  04231e52d355 ("ipvs: queue delayed work to expire no destination connections 
if expire_nodest_conn=1")

from the netfilter-next tree.
-- 
Cheers,
Stephen Rothwell


pgpzropxbpxSy.pgp
Description: OpenPGP digital signature

Re: [PATCH] tools/memory-model: document the "one-time init" pattern

[Alan Stern]

On Fri, Jul 17, 2020 at 05:58:57PM -0700, Eric Biggers wrote:
> On Fri, Jul 17, 2020 at 01:53:40PM -0700, Darrick J. Wong wrote:
> > > +There are also cases in which the smp_load_acquire() can be replaced by
> > > +the more lightweight READ_ONCE().  (smp_store_release() is still
> > > +required.)  Specifically, if all initialized memory is transitively
> > > +reachable from the pointer itself, then there is no control dependency
> > 
> > I don't quite understand what "transitively reachable from the pointer
> > itself" means?  Does that describe the situation where all the objects
> > reachable through the object that the global struct foo pointer points
> > at are /only/ reachable via that global pointer?
> > 
> 
> The intent is that "transitively reachable" means that all initialized memory
> can be reached by dereferencing the pointer in some way, e.g. p->a->b[5]->c.
> 
> It could also be the case that allocating the object initializes some global 
> or
> static data, which isn't reachable in that way.  Access to that data would 
> then
> be a control dependency, which a data dependency barrier wouldn't work for.
> 
> It's possible I misunderstood something.  (Note the next paragraph does say 
> that
> using READ_ONCE() is discouraged, exactly for this reason -- it can be hard to
> tell whether it's correct.)  Suggestions of what to write here are 
> appreciated.

Perhaps something like this:

Specifically, if the only way to reach the initialized memory 
involves dereferencing the pointer itself then READ_ONCE() is 
sufficient.  This is because there will be an address dependency 
between reading the pointer and accessing the memory, which will 
ensure proper ordering.  But if some of the initialized memory 
is reachable some other way (for example, if it is global or 
static data) then there need not be an address dependency, 
merely a control dependency (checking whether the pointer is 
non-NULL).  Control dependencies do not always ensure ordering 
-- certainly not for reads, and depending on the compiler, 
possibly not for some writes -- and therefore a load-acquire is 
necessary.

Perhaps this is more wordy than you want, but it does get the important 
ideas across.

Alan Stern

Re: [PATCH net] net: atlantic: disable PTP on AQC111, AQC112

[David Miller]

From: Mark Starovoytov 
Date: Fri, 17 Jul 2020 23:39:49 +0300

> From: Nikita Danilov 
> 
> This patch disables PTP on AQC111 and AQC112 due to a known HW issue,
> which can cause datapath issues.
> 
> Ideally PTP block should have been disabled via PHY provisioning, but
> unfortunately many units have been shipped with enabled PTP block.
> Thus, we have to work around this in the driver.
> 
> Fixes: dbcd6806af420 ("net: aquantia: add support for Phy access")
> Signed-off-by: Nikita Danilov 
> Signed-off-by: Mark Starovoytov 
> Signed-off-by: Igor Russkikh 

Applied and queued up for -stable, thank you.

Re: [RFT PATCH v3 1/9] RISC-V: Move DT mapping outof fixmap

[Atish Patra]

On Thu, Jul 16, 2020 at 11:32 PM Arnd Bergmann  wrote:
>
> On Fri, Jul 17, 2020 at 1:41 AM Atish Patra  wrote:
> >
> > From: Anup Patel 
> >
> > Currently, RISC-V reserves 1MB of fixmap memory for device tree. However,
> > it maps only single PMD (2MB) space for fixmap which leaves only < 1MB space
> > left for other kernel features such as early ioremap which requires fixmap
> > as well. The fixmap size can be increased by another 2MB but it brings
> > additional complexity and changes the virtual memory layout as well.
> > If we require some additional feature requiring fixmap again, it has to be
> > moved again.
> >
> > Technically, DT doesn't need a fixmap as the memory occupied by the DT is
> > only used during boot. Thus, init memory section can be used for the same
> > purpose as well. This simplifies fixmap implementation.
> >
> > Signed-off-by: Anup Patel 
> > Signed-off-by: Atish Patra 
>
> The patch seems fine for the moment, but I have one concern for the
> long run:
>
> > +#define DTB_EARLY_SIZE SZ_1M
> > +static char early_dtb[DTB_EARLY_SIZE] __initdata;
>
> Hardcoding the size in .bss seems slightly problematic both for
> small and for big systems. On machines with very little memory,
> this can lead to running out of free pages before .initdata gets freed,
> and it increases the size of the uncompressed vmlinux file by quite
> a bit.
>
> On some systems, the 1MB limit may get too small. While most dtbs
> would fall into the range between 10KB and 100KB, it can also be
> much larger than that, e.g. when there are DT properties that include
> blobs like device firmware that gets loaded into hardware by a kernel
> driver.
>
I was not aware that we can do such things. Is there a current example of that ?

> Is there anything stopping you from parsing the FDT in its original
> location without the extra copy before it gets unflattened?
>

That's what the original code was doing. A fixmap entry was added to
map the original fdt
location to a virtual so that parse_dtb can be operated on a virtual
address. But we can't map
both FDT & early ioremap within a single PMD region( 2MB ). That's why
we removed the DT
mapping from the fixmap to .bss section. The other alternate option is
to increase the fixmap space to
4MB which seems more fragile.

>Arnd



-- 
Regards,
Atish

Re: [PATCH] tools/memory-model: document the "one-time init" pattern

[Eric Biggers]

On Fri, Jul 17, 2020 at 01:51:38PM -0400, Alan Stern wrote:
> On Fri, Jul 17, 2020 at 06:47:50PM +0100, Matthew Wilcox wrote:
> > On Thu, Jul 16, 2020 at 09:44:27PM -0700, Eric Biggers wrote:
> ...
> > > + /* on success, pairs with smp_load_acquire() above and below */
> > > + if (cmpxchg_release(, NULL, p) != NULL) {
> > 
> > Why do we have cmpxchg_release() anyway?  Under what circumstances is
> > cmpxchg() useful _without_ having release semantics?
> 
> To answer just the last question: cmpxchg() is useful for lock 
> acquisition, in which case it needs to have acquire semantics rather 
> than release semantics.
> 

To clarify, there are 4 versions of cmpxchg:

cmpxchg(): does ACQUIRE and RELEASE (on success)
cmpxchg_acquire(): does ACQUIRE only (on success)
cmpxchg_release(): does RELEASE only (on success)
cmpxchg_relaxed(): no barriers

The problem here is that here we need RELEASE on success and ACQUIRE on failure.
But no version guarantees any barrier on failure.

So as far as I can tell, the best we can do is use cmpxchg_release() (or
cmpxchg() which would be stronger but unnecessary), followed by a separate
ACQUIRE on failure.

- Eric

warning unloading wmi

[Matteo Croce]

Hi,

I get this warning when unloading wmi:

[  246.219255] [ cut here ]
[  246.219257] sysfs group 'power' not found for kobject 
'1F13AB7F-6220-4210-8F8E-8BB5E71EE969'
[  246.219271] WARNING: CPU: 4 PID: 1744 at fs/sysfs/group.c:279 
sysfs_remove_group+0x6f/0x80
[  246.219271] Modules linked in: ccm rfcomm xt_CHECKSUM xt_MASQUERADE 
xt_conntrack ipt_REJECT nf_nat_tftp nft_objref nf_conntrack_tftp nft_counter 
tun bridge stp llc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib 
nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat 
nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c ip6_tables 
nft_compat ip_set nf_tables nfnetlink cmac bnep vfat fat elan_i2c mei_hdcp 
mei_wdt intel_rapl_msr iTCO_wdt iTCO_vendor_support x86_pkg_temp_thermal 
intel_powerclamp coretemp kvm_intel kvm snd_sof_pci snd_sof_intel_byt 
snd_sof_intel_ipc irqbypass snd_sof_intel_hda_common snd_soc_hdac_hda 
snd_sof_xtensa_dsp intel_cstate snd_sof_intel_hda snd_sof intel_uncore 
snd_hda_codec_hdmi intel_rapl_perf snd_soc_skl snd_soc_sst_ipc snd_soc_sst_dsp 
snd_hda_ext_core iwlmvm snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core 
snd_hda_codec_realtek snd_hda_codec_generic snd_compress ac97_bus mac80211 
snd_pcm_dmaengine snd_hda_intel uvcvideo
[  246.219291]  snd_intel_dspcfg btusb snd_hda_codec btrtl videobuf2_vmalloc 
pcspkr btbcm videobuf2_memops btintel libarc4 snd_hda_core bluetooth 
videobuf2_v4l2 videobuf2_common snd_hwdep iwlwifi videodev joydev thunderbolt 
snd_seq mc snd_seq_device ecdh_generic ecc cfg80211 snd_pcm ucsi_acpi mei_me 
processor_thermal_device intel_rapl_common snd_timer mei intel_soc_dts_iosf 
i2c_i801 intel_pch_thermal typec_ucsi typec thinkpad_acpi ledtrig_audio snd 
soundcore rfkill int3403_thermal int340x_thermal_zone int3400_thermal 
acpi_thermal_rel acpi_pad i2c_dev ip_tables i915 hid_multitouch rtsx_pci_sdmmc 
mmc_core crct10dif_pclmul crc32_pclmul crc32c_intel i2c_algo_bit cec 
drm_kms_helper e1000e ghash_clmulni_intel nvme drm serio_raw nvme_core rtsx_pci 
wmi(-) video pinctrl_cannonlake pinctrl_intel fuse [last unloaded: 
intel_wmi_thunderbolt]
[  246.219312] CPU: 4 PID: 1744 Comm: rmmod Not tainted 5.7.8-200.fc32.x86_64 #1
[  246.219312] Hardware name: LENOVO 20NYSA084G/20NYSA084G, BIOS N2JET88W (1.66 
) 04/22/2020
[  246.219315] RIP: 0010:sysfs_remove_group+0x6f/0x80
[  246.219317] Code: ff 5b 48 89 ef 5d 41 5c e9 8e c3 ff ff 48 89 ef e8 e6 bc 
ff ff eb d1 49 8b 14 24 48 8b 33 48 c7 c7 f0 68 39 9e e8 a8 09 d1 ff <0f> 0b 5b 
5d 41 5c c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00
[  246.219318] RSP: 0018:ac1580de3dc8 EFLAGS: 00010292
[  246.219319] RAX: 0050 RBX: 9e0f6400 RCX: 0007
[  246.219320] RDX: fff8 RSI: 0092 RDI: 9527fe719cc0
[  246.219320] RBP:  R08: 04dd R09: 0003
[  246.219321] R10:  R11: 0001 R12: 9527fb505c00
[  246.219322] R13: 9527fb505c80 R14: 9527fb423000 R15: 
[  246.219323] FS:  7fcfa6e60740() GS:9527fe70() 
knlGS:
[  246.219324] CS:  0010 DS:  ES:  CR0: 80050033
[  246.219325] CR2: 55b55a202078 CR3: 00047a64e005 CR4: 003606e0
[  246.219326] DR0:  DR1:  DR2: 
[  246.219326] DR3:  DR6: fffe0ff0 DR7: 0400
[  246.219327] Call Trace:
[  246.219334]  device_del+0x97/0x3f0
[  246.219338]  ? acpi_os_signal_semaphore+0x29/0x40
[  246.219341]  ? acpi_ut_release_mutex+0x70/0x75
[  246.219343]  device_unregister+0x16/0x60
[  246.219346]  acpi_wmi_remove+0xf0/0x110 [wmi]
[  246.219348]  platform_drv_remove+0x24/0x40
[  246.219350]  __device_release_driver+0x15c/0x210
[  246.219352]  driver_detach+0xcb/0x10d
[  246.219353]  bus_remove_driver+0x58/0xcc
[  246.219356]  acpi_wmi_exit+0xc/0xfac [wmi]
[  246.219358]  __do_sys_delete_module.constprop.0+0x14e/0x2d0
[  246.219362]  do_syscall_64+0x5b/0xf0
[  246.219366]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  246.219368] RIP: 0033:0x7fcfa6f9031b
[  246.219369] Code: 73 01 c3 48 8b 0d 7d 0b 0c 00 f7 d8 64 89 01 48 83 c8 ff 
c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d 4d 0b 0c 00 f7 d8 64 89 01 48
[  246.219370] RSP: 002b:7ffcb61b3f28 EFLAGS: 0206 ORIG_RAX: 
00b0
[  246.219371] RAX: ffda RBX: 55b55a1f7760 RCX: 7fcfa6f9031b
[  246.219372] RDX: 000a RSI: 0800 RDI: 55b55a1f77c8
[  246.219373] RBP: 55b55a1f72a0 R08: 1999 R09: 
[  246.219373] R10: 7fcfa7004ac0 R11: 0206 R12: 7ffcb61b471e
[  246.219374] R13:  R14: 7ffcb61b4150 R15: 55b55a1f7760
[  246.219376] ---[ end trace e72269a76e8f7465 ]---
[  246.219420] [ cut here ]
[  246.219421] sysfs group 'power' not