date:20210220

Hi Arnd,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   f40ddce88593482919761f74910f42f4b84c004b
commit: 17132da70eb766785b9b4677bacce18cc11ea442 ARM: samsung: move pm check 
code to drivers/soc
date:   6 months ago
config: arm-randconfig-m031-20210221 (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
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=17132da70eb766785b9b4677bacce18cc11ea442
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 17132da70eb766785b9b4677bacce18cc11ea442
# 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/soc/samsung/s3c-pm-debug.c: In function 's3c_pm_dbg':
>> drivers/soc/samsung/s3c-pm-debug.c:30:2: warning: function 's3c_pm_dbg' 
>> might be a candidate for 'gnu_printf' format attribute 
>> [-Wsuggest-attribute=format]
  30 |  vsnprintf(buff, sizeof(buff), fmt, va);
 |  ^


vim +30 drivers/soc/samsung/s3c-pm-debug.c

72551f6cf13e2f arch/arm/plat-samsung/pm-debug.c Tomasz Figa 2014-03-18  23  
72551f6cf13e2f arch/arm/plat-samsung/pm-debug.c Tomasz Figa 2014-03-18  24  
void s3c_pm_dbg(const char *fmt, ...)
72551f6cf13e2f arch/arm/plat-samsung/pm-debug.c Tomasz Figa 2014-03-18  25  {
72551f6cf13e2f arch/arm/plat-samsung/pm-debug.c Tomasz Figa 2014-03-18  26  
va_list va;
72551f6cf13e2f arch/arm/plat-samsung/pm-debug.c Tomasz Figa 2014-03-18  27  
char buff[256];
72551f6cf13e2f arch/arm/plat-samsung/pm-debug.c Tomasz Figa 2014-03-18  28  
72551f6cf13e2f arch/arm/plat-samsung/pm-debug.c Tomasz Figa 2014-03-18  29  
va_start(va, fmt);
72551f6cf13e2f arch/arm/plat-samsung/pm-debug.c Tomasz Figa 2014-03-18 @30  
vsnprintf(buff, sizeof(buff), fmt, va);
72551f6cf13e2f arch/arm/plat-samsung/pm-debug.c Tomasz Figa 2014-03-18  31  
va_end(va);
72551f6cf13e2f arch/arm/plat-samsung/pm-debug.c Tomasz Figa 2014-03-18  32  
72551f6cf13e2f arch/arm/plat-samsung/pm-debug.c Tomasz Figa 2014-03-18  33  
printascii(buff);
72551f6cf13e2f arch/arm/plat-samsung/pm-debug.c Tomasz Figa 2014-03-18  34  }
72551f6cf13e2f arch/arm/plat-samsung/pm-debug.c Tomasz Figa 2014-03-18  35  

:: The code at line 30 was first introduced by commit
:: 72551f6cf13e2f3a1d273b7007b5d7d7fd69c554 ARM: SAMSUNG: Move Samsung PM 
debug code into separate file

:: TO: Tomasz Figa 
:: CC: Kukjin Kim 

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


.config.gz
Description: application/gzip

Re: [PATCH] rtw88: 8822ce: fix wifi disconnect after S3/S4 on HONOR laptop

On Sat, Feb 20, 2021 at 04:46:02PM +0800, Hao Chen wrote:
> When the laptop HONOR MagicBook 14 sleep to S3/S4, the laptop can't
> resume.
> The dmesg of kernel report:
> "[   99.990168] pcieport :00:01.2: can't change power state
> from D3hot to D0 (config space inaccessible)
> [   99.993334] rtw_pci :01:00.0: can't change power state
> from D3hot to D0 (config space inaccessible)
> [  104.435004] rtw_pci :01:00.0: mac power on failed
> [  104.435010] rtw_pci :01:00.0: failed to power on mac"
> When try to pointer the driver.pm to NULL, the problem is fixed.
> This driver hasn't implemented pm ops yet.It makes the sleep and
> wake procedure expected when pm's ops not NULL.
>
> Fixed: commit e3037485c68e ("rtw88: new Realtek 802.11ac driver")
>
> Signed-off-by: Hao Chen 
> ---
>  drivers/net/wireless/realtek/rtw88/rtw8822ce.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/realtek/rtw88/rtw8822ce.c 
> b/drivers/net/wireless/realtek/rtw88/rtw8822ce.c
> index 3845b1333dc3..b4c6762ba7ac 100644
> --- a/drivers/net/wireless/realtek/rtw88/rtw8822ce.c
> +++ b/drivers/net/wireless/realtek/rtw88/rtw8822ce.c
> @@ -25,7 +25,7 @@ static struct pci_driver rtw_8822ce_driver = {
>   .id_table = rtw_8822ce_id_table,
>   .probe = rtw_pci_probe,
>   .remove = rtw_pci_remove,
> - .driver.pm = _pm_ops,
> + .driver.pm = NULL,

The NULL is the default, it is enough to delete ".driver.pm = _pm_ops," 
line.

Thanks

>   .shutdown = rtw_pci_shutdown,
>  };
>  module_pci_driver(rtw_8822ce_driver);
> --
> 2.20.1
>
>
>

Re: [PATCH] drivers: infiniband: sw: rxe: fix kconfig dependency on CRYPTO

On Fri, Feb 19, 2021 at 06:32:26PM -0500, Julian Braha wrote:
> commit 6e61907779ba99af785f5b2397a84077c289888a
> Author: Julian Braha 
> Date:   Fri Feb 19 18:20:57 2021 -0500
>
> drivers: infiniband: sw: rxe: fix kconfig dependency on CRYPTO
>
> When RDMA_RXE is enabled and CRYPTO is disabled,
> Kbuild gives the following warning:
>
> WARNING: unmet direct dependencies detected for CRYPTO_CRC32
>   Depends on [n]: CRYPTO [=n]
>   Selected by [y]:
>   - RDMA_RXE [=y] && (INFINIBAND_USER_ACCESS [=y] || 
> !INFINIBAND_USER_ACCESS [=y]) && INET [=y] && PCI [=y] && INFINIBAND [=y] && 
> INFINIBAND_VIRT_DMA [=y]
>
> This is because RDMA_RXE selects CRYPTO_CRC32,
> without depending on or selecting CRYPTO, despite that config option
> being subordinate to CRYPTO.
>
> Signed-off-by: Julian Braha 

Please use git sent-email to send patches and please fix crypto Kconfig
to enable CRYPTO if CRYPTO_* selected.

It is a little bit awkward to request all users of CRYPTO_* to request
select CRYPTO too.

Thanks

>
> diff --git a/drivers/infiniband/sw/rxe/Kconfig 
> b/drivers/infiniband/sw/rxe/Kconfig
> index 452149066792..06b8dc5093f7 100644
> --- a/drivers/infiniband/sw/rxe/Kconfig
> +++ b/drivers/infiniband/sw/rxe/Kconfig
> @@ -4,6 +4,7 @@ config RDMA_RXE
> depends on INET && PCI && INFINIBAND
> depends on INFINIBAND_VIRT_DMA
> select NET_UDP_TUNNEL
> +  select CRYPTO
> select CRYPTO_CRC32
> help
> This driver implements the InfiniBand RDMA transport over
>
>
>

Re: [PATCH net-next RFC v4] net: hdlc_x25: Queue outgoing LAPB frames

On Fri, Feb 19, 2021 at 12:28:12PM -0800, Xie He wrote:
> On Fri, Feb 19, 2021 at 10:39 AM Jakub Kicinski  wrote:
> >
> > Not entirely sure what the argument is about but adding constants would
> > certainly help.
>
> Leon wants me to replace this:
>
> dev->needed_headroom = 3 - 1;
>
> with this:
>

Leon wants this line to be written good enough:

> /* 2 is the result of 3 - 1 */

And this line like you wrote here:

> dev->needed_headroom = 2;


<...>

> Yes, this patch will break backward compatibility. Users with old
> scripts will find them no longer working.

Did you search in debian/fedora code repositories to see if such scripts exist
as part of any distro package?

Thanks

Re: [PATCH v15 2/4] phy: Add media type and speed serdes configuration interfaces

On Thu, Feb 18, 2021 at 05:14:49PM +0100, Steen Hegelund wrote:
> Provide new phy configuration interfaces for media type and speed that
> allows e.g. PHYs used for ethernet to be configured with this
> information.
>
> Signed-off-by: Lars Povlsen 
> Signed-off-by: Steen Hegelund 
> Reviewed-by: Andrew Lunn 
> Reviewed-by: Alexandre Belloni 
> ---
>  drivers/phy/phy-core.c  | 30 ++
>  include/linux/phy/phy.h | 26 ++
>  2 files changed, 56 insertions(+)
>
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index 71cb10826326..ccb575b13777 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -373,6 +373,36 @@ int phy_set_mode_ext(struct phy *phy, enum phy_mode 
> mode, int submode)
>  }
>  EXPORT_SYMBOL_GPL(phy_set_mode_ext);
>
> +int phy_set_media(struct phy *phy, enum phy_media media)
> +{
> + int ret;
> +
> + if (!phy || !phy->ops->set_media)
> + return 0;
> +
> + mutex_lock(>mutex);
> + ret = phy->ops->set_media(phy, media);
> + mutex_unlock(>mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(phy_set_media);
> +
> +int phy_set_speed(struct phy *phy, int speed)
> +{
> + int ret;
> +
> + if (!phy || !phy->ops->set_speed)
> + return 0;
> +
> + mutex_lock(>mutex);
> + ret = phy->ops->set_speed(phy, speed);
> + mutex_unlock(>mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(phy_set_speed);
> +
>  int phy_reset(struct phy *phy)
>  {
>   int ret;
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index e435bdb0bab3..0ed434d02196 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -44,6 +44,12 @@ enum phy_mode {
>   PHY_MODE_DP
>  };
>
> +enum phy_media {
> + PHY_MEDIA_DEFAULT,
> + PHY_MEDIA_SR,
> + PHY_MEDIA_DAC,
> +};
> +
>  /**
>   * union phy_configure_opts - Opaque generic phy configuration
>   *
> @@ -64,6 +70,8 @@ union phy_configure_opts {
>   * @power_on: powering on the phy
>   * @power_off: powering off the phy
>   * @set_mode: set the mode of the phy
> + * @set_media: set the media type of the phy (optional)
> + * @set_speed: set the speed of the phy (optional)
>   * @reset: resetting the phy
>   * @calibrate: calibrate the phy
>   * @release: ops to be performed while the consumer relinquishes the PHY
> @@ -75,6 +83,8 @@ struct phy_ops {
>   int (*power_on)(struct phy *phy);
>   int (*power_off)(struct phy *phy);
>   int (*set_mode)(struct phy *phy, enum phy_mode mode, int submode);
> + int (*set_media)(struct phy *phy, enum phy_media media);
> + int (*set_speed)(struct phy *phy, int speed);
>
>   /**
>* @configure:
> @@ -215,6 +225,8 @@ int phy_power_off(struct phy *phy);
>  int phy_set_mode_ext(struct phy *phy, enum phy_mode mode, int submode);
>  #define phy_set_mode(phy, mode) \
>   phy_set_mode_ext(phy, mode, 0)
> +int phy_set_media(struct phy *phy, enum phy_media media);
> +int phy_set_speed(struct phy *phy, int speed);
>  int phy_configure(struct phy *phy, union phy_configure_opts *opts);
>  int phy_validate(struct phy *phy, enum phy_mode mode, int submode,
>union phy_configure_opts *opts);
> @@ -344,6 +356,20 @@ static inline int phy_set_mode_ext(struct phy *phy, enum 
> phy_mode mode,
>  #define phy_set_mode(phy, mode) \
>   phy_set_mode_ext(phy, mode, 0)
>
> +static inline int phy_set_media(struct phy *phy, enum phy_media media)
> +{
> + if (!phy)
> + return 0;

I'm curious, why do you check for the NULL in all newly introduced functions?
How is it possible that calls to phy_*() supply NULL as the main struct?

Thanks

> + return -ENODEV;
> +}
> +
> +static inline int phy_set_speed(struct phy *phy, int speed)
> +{
> + if (!phy)
> + return 0;
> + return -ENODEV;
> +}
> +
>  static inline enum phy_mode phy_get_mode(struct phy *phy)
>  {
>   return PHY_MODE_INVALID;
> --
> 2.30.0
>

Re: [GIT PULL] PNP updates for v5.12-rc1

The pull request you sent on Mon, 15 Feb 2021 19:47:14 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git pnp-5.12-rc1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/55f62bc873477dae2c45bbbc30b86cf3e0982f3b

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] ACPI updates for v5.12-rc1

The pull request you sent on Mon, 15 Feb 2021 19:45:53 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git 
> acpi-5.12-rc1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/3c8f504b3a486e4e984ac8dc619eba3afa24cec4

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] Power management updates for v5.12-rc1

The pull request you sent on Mon, 15 Feb 2021 19:43:59 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git pm-5.12-rc1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/02f9fc286e039d0bef7284fb1200ee755b525bde

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [RFC][PATCH 6/6] objtool,x86: Rewrite retpoline thunk calls

2021-02-20 Thread Jürgen Groß


On 20.02.21 23:32, Peter Zijlstra wrote:

On Sat, Feb 20, 2021 at 06:41:01PM +0100, Borislav Petkov wrote:

  - if we had negative alternatives objtool doesn't need to actually
rewrite code in this case. It could simply emit alternative entries
and call it a day.


I don't mind the negative alt per se - I mind the implementation I saw.
I'm sure we can come up with something nicer, like, for example, struct
alt_instr.flags to denote that this feature is a NOT feature.


So you don't like the ~ or - on cpuid? ISTR we talked about
alt_instr::flags before, but Google isn't playing ball today so I can't
seem to find it.


If you want I can cook up a patch and include it in my paravirt
cleanup series.

Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: [GIT PULL] TTY / Serial driver changes for 5.12-rc1

The pull request you sent on Mon, 15 Feb 2021 17:27:18 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tags/tty-5.12-rc1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e4286926abbbaab9b047c8bc25cae78ec990928f

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] USB / Thunderbolt driver changes for 5.12-rc1

The pull request you sent on Mon, 15 Feb 2021 17:27:57 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git tags/usb-5.12-rc1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/780607b9731feef575514108fc7956c54180f16e

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] Staging/IIO driver patches for 5.12-rc1

The pull request you sent on Mon, 15 Feb 2021 17:28:17 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
> tags/staging-5.12-rc1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/5d99aa093b566d234b51b7822c67059e2bd3ed8d

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

[PATCH] nvme: Apply the same fix Kingston SKC2000 nVME SSD as A2000

2021-02-20 Thread Zoltán Böszörményi

From: Zoltán Böszörményi 

My 2TB SKC2000 showed the exact same symptoms that were provided
in 538e4a8c57 ("nvme-pci: avoid the deepest sleep state on
Kingston A2000 SSDs"), i.e. a complete NVME lockup that needed
cold boot to get it back.

According to some sources, the A2000 is simply a rebadged
SKC2000 with a slightly optimized firmware.

Adding the SKC2000 PCI ID to the quirk list with the same workaround
as the A2000 made my laptop survive a 5 hours long Yocto bootstrap
buildfest which reliably triggered the SSD lockup previously.

Tested against 5.10.17.

Signed-off-by: Zoltán Böszörményi 

---
 drivers/nvme/host/pci.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 4a33287..3af6a95 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -3264,6 +3264,8 @@ static const struct pci_device_id nvme_id_table[] = {
.driver_data = NVME_QUIRK_DISABLE_WRITE_ZEROES, },
{ PCI_DEVICE(0x15b7, 0x2001),   /*  Sandisk Skyhawk */
.driver_data = NVME_QUIRK_DISABLE_WRITE_ZEROES, },
+   { PCI_DEVICE(0x2646, 0x2262),   /* KINGSTON SKC2000 NVMe SSD  */
+   .driver_data = NVME_QUIRK_NO_DEEPEST_PS, },
{ PCI_DEVICE(0x2646, 0x2263),   /* KINGSTON A2000 NVMe SSD  */
.driver_data = NVME_QUIRK_NO_DEEPEST_PS, },
{ PCI_DEVICE(PCI_VENDOR_ID_APPLE, 0x2001),
-- 
2.29.2

Re: [PATCH 1/2] staging: rtl8192e: Pass array value to memcpy instead of struct pointer

2021-02-20 Thread Atul Gopinathan

On Sat, Feb 20, 2021 at 12:34:15PM -0600, Gustavo A. R. Silva wrote:
> 
> 
> On 2/20/21 12:21, Atul Gopinathan wrote:
> > The variable "info_element" is of the following type:
> > struct rtllib_info_element *info_element
> > 
> > rtllib_info_element is a struct containing the following fields as
> > defined in drivers/staging/rtl8192e/rtllib.h:
> > 
> > struct rtllib_info_element {
> > u8 id;
> > u8 len;
> > u8 data[];
> > } __packed;
> > 
> > The following code of interest (to which this patch applies) is
> > supposed to check if the "info_element->len" is greater than 4 and
> > equal to 6, if this is satisfied then, the last two bytes (the
> > 4th and 5th index of u8 "data" array) are copied into
> > "network->CcxRmState".
> > 
> > Currently the code uses "memcpy()" with the source as
> > "_element[4]" which would copy in wrong and unintended
> > information.
> > 
> > This patch rectifies this error by using "_element->data[4]" which
> > rightly copies the last two bytes as the required state information.
> 
> You should include a 'Fixes' tag for this.

Sure! Will resend the patches.
I have a doubt about the Fixes tag, the previous commit pertaining to the
lines I'm modifying is a checkpatch.pl fix (found using simple "git blame").
Should I write that as the Fixes ? Or should I write in the
commit id which created that file and hence, that specific line?

git blame -L1960,1980 -- rtllib_rx.c -> returns a single commit which
was a checkpatch fix (1970, is the line my patch-1 modifies)

git log -S'_element[4]' -- rtllib_rx.c -> returned the commit which
created the file (the file which my patch-1 modifies)

Which one should I write in the Fixes tag?

Thanks!
Atul

Re: [GIT PULL] x86/asm for v5.12

The pull request you sent on Mon, 15 Feb 2021 13:40:50 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> tags/x86_asm_for_v5.12

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2c405d1ab8b3103df2df541aaacc2113dc6c9fac

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] EFI updates for v5.12

The pull request you sent on Mon, 15 Feb 2021 13:44:26 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> tags/efi-next-for-v5.12

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/70cd33d34c6026cbc2efb172f8063fccb2ebeb9a

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] x86/build for v5.12

The pull request you sent on Mon, 15 Feb 2021 13:38:07 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> tags/x86_build_for_v5.12

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/26a30952390499a95a0accad0c49379e5301

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] x86/cpu for v5.12

The pull request you sent on Mon, 15 Feb 2021 12:55:38 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> tags/x86_cpu_for_v5.12

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0570b69305276a349ef7a17c8c54dfeed76f3954

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] x86/cache for v5.12

The pull request you sent on Mon, 15 Feb 2021 12:59:05 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> tags/x86_cache_for_v5.12

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b0fb29382d822a6cd6f5d8d441471f0072cd3133

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] x86/fpu for v5.12

The pull request you sent on Mon, 15 Feb 2021 12:52:14 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> tags/x86_fpu_for_v5.12

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8831d718aa5a9540aaeb527a582af5fc140aed6e

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] x86/misc for v5.12

The pull request you sent on Mon, 15 Feb 2021 12:41:32 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> tags/x86_misc_for_v5.12

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/317d4f459393e27b3efedf571bd9e78a23fcd2ed

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] x86/microcode for v5.12

The pull request you sent on Mon, 15 Feb 2021 12:45:04 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> tags/x86_microcode_for_v5.12

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d00c4ed02e90c1a4290acdd4f9bc4d056a573859

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] x86/paravirt for v5.12

The pull request you sent on Mon, 15 Feb 2021 11:53:24 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> tags/x86_paravirt_for_v5.12

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1255f44017c02d14e3ad5b63cdf619a734d765a1

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] x86/seves for v5.12

The pull request you sent on Mon, 15 Feb 2021 11:43:39 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> tags/x86_seves_for_v5.12

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b9cdab6820ae740dad1e87e609d78dbea7a297f2

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] RAS updates for v5.12

The pull request you sent on Mon, 15 Feb 2021 11:01:16 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> tags/ras_updates_for_v5.12

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/3e89c7ea7a828fec5694101e0f0ff7240e634470

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] x86/mm for v5.12

The pull request you sent on Mon, 15 Feb 2021 12:02:49 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> tags/x86_mm_for_v5.12

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ae821d2107e378bb086a02afcce82d0f43c29a6f

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] x86/platform for v5.12

The pull request you sent on Mon, 15 Feb 2021 11:49:22 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> tags/x86_platform_for_v5.12

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/4f7a4028d8b48d1dc6b51b0737087f5e3c16c336

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] x86/sgx for v5.12

The pull request you sent on Mon, 15 Feb 2021 11:30:43 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> tags/x86_sgx_for_v5.12

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/4bf0b820d146682d997248ff1d49665475f9df16

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] EDAC updates for v5.12

The pull request you sent on Mon, 15 Feb 2021 10:16:53 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git 
> tags/edac_updates_for_v5.12

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8518496639123ebcceb1be173c4f00edf178bfbd

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [PATCH 5/6] driver core: lift dma_default_coherent into common code

2021-02-20 Thread Maciej W. Rozycki

On Mon, 15 Feb 2021, Maciej W. Rozycki wrote:

>  I hope to have the adapter properly fixed soon and I'll look at the Malta 
> side now, possibly using the old server whose DEFPA has worked flawlessly 
> for some 20 years now.  I have planned to use the interface to supply NFS 
> root, which I think should be enough of a stress test.

 Card reworked now and network wired, so using the new server actually.  
I haven't booted Linux on my Malta for a while now, but it turns out to 
work just fine, and your patch set does not regress it booting multi-user 
NFS-rooted over FDDI.

 I note however that the system does not reboot properly:

sd 0:0:0:0: [sda] Synchronizing SCSI cache
reboot: Restarting system
Reboot failed -- System halted

which is a regression, and also the MMIO-mapped discrete CBUS UART (ttyS2) 
does not sign in anymore either:

Serial: 8250/16550 driver, 5 ports, IRQ sharing enabled
printk: console [ttyS0] disabled
serial8250.0: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
printk: console [ttyS0] enabled
printk: console [ttyS0] enabled
printk: bootconsole [uart8250] disabled
printk: bootconsole [uart8250] disabled
serial8250.0: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A

while long ago:

Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI 
enabled
ttyS28 at 0x03f8 (irq = 4) is a 16550A
ttyS29 at 0x02f8 (irq = 3) is a 16550A
ttyS30 at 0x (irq = 20) is a 16550

(I don't know why the line numbers reported were so odd back then, but the 
standard character device major:minor numbers for ttyS0-2 just worked), so 
there's probably something wrong with platform device registration.  ISTR 
using the CBUS UART as a console device at one point too.

  Maciej

Re: [PATCH 1/6] MIPS/malta: simplify plat_setup_iocoherency

2021-02-20 Thread Maciej W. Rozycki

On Wed, 10 Feb 2021, Christoph Hellwig wrote:

> Given that plat_mem_setup runs before earlyparams are handled and malta
> selects CONFIG_DMA_MAYBE_COHERENT, coherentio can only be set to
> IO_COHERENCE_DEFAULT at this point.  So remove the checking for other
> options and merge plat_enable_iocoherency into plat_setup_iocoherency
> to simplify the code a bit.

Tested-by: Maciej W. Rozycki 

 FWIW,

  Maciej

Re: [GIT] Networking

The pull request you sent on Wed, 17 Feb 2021 18:52:00 -0800 (PST):

> git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git 
> refs/heads/master

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/51e6d17809c85e1934600ec4cdb85552e9bda254

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [PATCH v2] video: fbdev: pm2fb: avoid stall on fb_sync

On Sat, Feb 20, 2021 at 7:36 PM Randy Dunlap  wrote:
> I suppose the rest of the patch is OK since it works for you.
>
> I don't know any of this code. It would be nice to know what some
> of those pm2_RD(par, SOME_REG) mean so that I could sort of
> understand what it is doing, but don't go spending time on it
> just for me. It's not worth doing that IMO.
>
>
> --
> ~Randy

Thank you Randy. I have sent another revision.
I am also curious about those registers -- but it is hard to
accurately figure it out without datasheet --
my speculation is that it calls the device to do some sort of frame
buffer synchronizations here
Thanks,
- Tong

[PATCH v3] video: fbdev: pm2fb: avoid stall on fb_sync

pm2fb_sync is called when doing /dev/fb read or write.
The original pm2fb_sync wait indefinitely on hardware flags which can
possibly stall kernel and make everything unresponsive.
Instead of waiting indefinitely, we can timeout to give user a chance to
get back control.

[   39.503356] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
rel-1.13.0-48-gd9c812dda5194
[   39.503947] Call Trace:
[   39.504081]  
[   39.504193]  dump_stack+0x7d/0xa3
[   39.504377]  nmi_cpu_backtrace.cold+0x32/0x7e
[   39.504613]  ? lapic_can_unplug_cpu+0x70/0x70
[   39.504850]  nmi_trigger_cpumask_backtrace+0xdf/0x100
[   39.505121]  rcu_dump_cpu_stacks+0xed/0x130
[   39.505349]  rcu_sched_clock_irq.cold+0x3b1/0x61d
[   39.505602]  ? hrtimer_run_queues+0x2c/0x1b0
[   39.505833]  ? __acct_update_integrals+0x136/0x160
[   39.506091]  update_process_times+0xb9/0xf0
[   39.506317]  tick_sched_handle.isra.0+0x5c/0x80
[   39.506562]  tick_sched_timer+0x70/0x90
[   39.506770]  __hrtimer_run_queues+0x1c6/0x3e0
[   39.517095]  ? tick_sched_handle.isra.0+0x80/0x80
[   39.517349]  ? enqueue_hrtimer+0xd0/0xd0
[   39.517561]  ? _raw_write_lock_irqsave+0xd0/0xd0
[   39.517812]  ? ktime_get+0x45/0xb0
[   39.517997]  ? ktime_get_update_offsets_now+0x96/0x150
[   39.518273]  hrtimer_interrupt+0x1a0/0x340
[   39.518496]  __sysvec_apic_timer_interrupt+0x7f/0x160
[   39.518768]  asm_call_irq_on_stack+0xf/0x20
[   39.518997]  
[   39.519114]  sysvec_apic_timer_interrupt+0x6f/0x80
[   39.519372]  asm_sysvec_apic_timer_interrupt+0x12/0x20
[   39.519647] RIP: 0010:pm2fb_sync+0x47/0x70 [pm2fb]
[   39.519907] Code: 89 ef e8 0c 87 2c c1 48 8b 53 08 31 c0 89 82 40 8c 00 00 
0f ae f0 48 8b 53 08 1
[   39.520885] RSP: 0018:88810a1f7df8 EFLAGS: 0202
[   39.521165] RAX: 72d5d49f RBX: 88810a034418 RCX: c90b0020
[   39.521542] RDX: c90b RSI: 0246 RDI: 88810a034420
[   39.521920] RBP: 88810a034420 R08:  R09: ed102143ef64
[   39.522297] R10: 0003 R11: ed102143ef63 R12: 88810a1f7ed0
[   39.522673] R13: 88810a034000 R14: c9000280 R15: 888109e5e000
[   39.523053]  ? pm2fb_sync+0x24/0x70 [pm2fb]
[   39.523280]  fb_write+0x1c2/0x2d0
[   39.523461]  vfs_write+0x108/0x380
[   39.523647]  ksys_write+0xb4/0x150
[   39.523832]  ? __ia32_sys_read+0x40/0x40
[   39.524043]  ? fpregs_assert_state_consistent+0x4d/0x60
[   39.524322]  do_syscall_64+0x33/0x40
[   39.524517]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   39.524788] RIP: 0033:0x7f5e50097970
[   39.524981] Code: 73 01 c3 48 8b 0d 28 d5 2b 00 f7 d8 64 89 01 48 83 c8 ff 
c3 66 0f 1f 44 00 00 4
[   39.525952] RSP: 002b:7ffec6895b38 EFLAGS: 0246 ORIG_RAX: 
0001
[   39.526352] RAX: ffda RBX:  RCX: 7f5e50097970
[   39.526726] RDX: 0200 RSI: 56491a6ad000 RDI: 0001
[   39.537261] RBP: 0200 R08:  R09: 56491a6ad030
[   39.537633] R10: 0871 R11: 0246 R12: 0800
[   39.538008] R13: 56491a6ad000 R14: 0200 R15: 

Signed-off-by: Tong Zhang 
---
 v3: initialize timeout_fifo to 0, and added comment for WAIT_FIFO_TIMEOUT
 v2: fix typo and add console log according to Randy's  
comment
 drivers/video/fbdev/pm2fb.c | 30 +++---
 1 file changed, 27 insertions(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/pm2fb.c b/drivers/video/fbdev/pm2fb.c
index 27893fa139b0..37db7e740221 100644
--- a/drivers/video/fbdev/pm2fb.c
+++ b/drivers/video/fbdev/pm2fb.c
@@ -183,12 +183,24 @@ static inline void pm2v_RDAC_WR(struct pm2fb_par *p, s32 
idx, u32 v)
 
 #ifdef CONFIG_FB_PM2_FIFO_DISCONNECT
 #define WAIT_FIFO(p, a)
+#define WAIT_FIFO_TIMEOUT(p, a) (0)
 #else
 static inline void WAIT_FIFO(struct pm2fb_par *p, u32 a)
 {
while (pm2_RD(p, PM2R_IN_FIFO_SPACE) < a)
cpu_relax();
 }
+/* return 1 for timeout, otherwise 0 */
+static inline int WAIT_FIFO_TIMEOUT(struct pm2fb_par *p, u32 a)
+{
+   int timeout = 1;
+   while (pm2_RD(p, PM2R_IN_FIFO_SPACE) < a) {
+   cpu_relax();
+   if (--timeout == 0)
+   return 1;
+   }
+   return 0;
+}
 #endif
 
 /*
@@ -1031,15 +1043,27 @@ static int pm2fb_blank(int blank_mode, struct fb_info 
*info)
 static int pm2fb_sync(struct fb_info *info)
 {
struct pm2fb_par *par = info->par;
+   int timeout_sync = 1;
+   int timeout_fifo = 0;
 
-   WAIT_FIFO(par, 1);
+   if (WAIT_FIFO_TIMEOUT(par, 1))
+   goto end;
pm2_WR(par, PM2R_SYNC, 0);
mb();
do {
-   while (pm2_RD(par, PM2R_OUT_FIFO_WORDS) == 0)
+   timeout_fifo = 1;
+   while (pm2_RD(par, PM2R_OUT_FIFO_WORDS) == 0) {
cpu_relax();
-   } while (pm2_RD(par, PM2R_OUT_FIFO) != PM2TAG(PM2R_SYNC));
+   if (--timeout_fifo ==

Re: [PATCH] arp: Remove the arp_hh_ops structure

2021-02-20 Thread Yejune Deng

Sorry,it was my fault, I will resubmit.

On Sun, Feb 21, 2021 at 9:54 AM David Ahern  wrote:
>
> On 2/19/21 9:32 PM, Yejune Deng wrote:
> >  static const struct neigh_ops arp_direct_ops = {
> >   .family =   AF_INET,
> >   .output =   neigh_direct_output,
> > @@ -277,15 +269,10 @@ static int arp_constructor(struct neighbour *neigh)
> >   memcpy(neigh->ha, dev->broadcast, dev->addr_len);
> >   }
> >
> > - if (dev->header_ops->cache)
> > - neigh->ops = _hh_ops;
> > - else
> > - neigh->ops = _generic_ops;
>
> How did you test this?
>
> you took out the neigh->ops assignment, so all of the neigh->ops in
> net/core/neighbour.c are going to cause a NULL dereference.
>
>
> > -
> > - if (neigh->nud_state & NUD_VALID)
> > - neigh->output = neigh->ops->connected_output;
> > + if (!dev->header_ops->cache && (neigh->nud_state & NUD_VALID))
> > + neigh->output = arp_generic_ops.connected_output;
> >   else
> > - neigh->output = neigh->ops->output;
> > + neigh->output = arp_generic_ops.output;
> >   }
> >   return 0;
> >  }
> >
>

[PATCH] virtio: remove export for virtio_config_{enable, disable}

2021-02-20 Thread Xianting Tian

virtio_config_enable(), virtio_config_disable() are only used inside
drivers/virtio/virtio.c, so it doesn't need export the symbols.

Signed-off-by: Xianting Tian 
---
 drivers/virtio/virtio.c | 6 ++
 include/linux/virtio.h  | 2 --
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
index 42e09cc..4b15c00 100644
--- a/drivers/virtio/virtio.c
+++ b/drivers/virtio/virtio.c
@@ -141,15 +141,14 @@ void virtio_config_changed(struct virtio_device *dev)
 }
 EXPORT_SYMBOL_GPL(virtio_config_changed);
 
-void virtio_config_disable(struct virtio_device *dev)
+static void virtio_config_disable(struct virtio_device *dev)
 {
spin_lock_irq(>config_lock);
dev->config_enabled = false;
spin_unlock_irq(>config_lock);
 }
-EXPORT_SYMBOL_GPL(virtio_config_disable);
 
-void virtio_config_enable(struct virtio_device *dev)
+static void virtio_config_enable(struct virtio_device *dev)
 {
spin_lock_irq(>config_lock);
dev->config_enabled = true;
@@ -158,7 +157,6 @@ void virtio_config_enable(struct virtio_device *dev)
dev->config_change_pending = false;
spin_unlock_irq(>config_lock);
 }
-EXPORT_SYMBOL_GPL(virtio_config_enable);
 
 void virtio_add_status(struct virtio_device *dev, unsigned int status)
 {
diff --git a/include/linux/virtio.h b/include/linux/virtio.h
index 55ea329..b1894e0 100644
--- a/include/linux/virtio.h
+++ b/include/linux/virtio.h
@@ -132,8 +132,6 @@ static inline struct virtio_device *dev_to_virtio(struct 
device *_dev)
 void virtio_break_device(struct virtio_device *dev);
 
 void virtio_config_changed(struct virtio_device *dev);
-void virtio_config_disable(struct virtio_device *dev);
-void virtio_config_enable(struct virtio_device *dev);
 int virtio_finalize_features(struct virtio_device *dev);
 #ifdef CONFIG_PM_SLEEP
 int virtio_device_freeze(struct virtio_device *dev);
-- 
1.8.3.1

[PATCH] x86/sgx: Add a basic NUMA allocation scheme to sgx_alloc_epc_page()

2021-02-20 Thread Jarkko Sakkinen

Background
==

EPC section is covered by one or more SRAT entries that are associated with
one and only one PXM (NUMA node). The motivation behind this patch is to
provide basic elements of building allocation scheme based on this premise.

It does not try to fully address NUMA. For instance, it does not provide
integration to the mempolicy API, but neither does introduce any
bottlenecks to address this later on. Memory allocation is a complex topic,
and thus it's better to start with baby steps.

Solution


Use phys_to_target_node() to associate each NUMA node with the EPC sections
contained within its range.

In sgx_alloc_epc_page(), first try to allocate from the NUMA node, where
the CPU is executing. If that fails, fallback to the legacy allocation.

Link: 
https://lore.kernel.org/lkml/158188326978.894464.217282995221175417.st...@dwillia2-desk3.amr.corp.intel.com/
Signed-off-by: Jarkko Sakkinen 
---
 arch/x86/Kconfig   |  1 +
 arch/x86/kernel/cpu/sgx/main.c | 52 +-
 arch/x86/kernel/cpu/sgx/sgx.h  |  1 +
 3 files changed, 53 insertions(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 21f851179ff0..dcb73a5edf63 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1941,6 +1941,7 @@ config X86_SGX
depends on CRYPTO_SHA256=y
select SRCU
select MMU_NOTIFIER
+   select NUMA_KEEP_MEMINFO if NUMA
help
  Intel(R) Software Guard eXtensions (SGX) is a set of CPU instructions
  that can be used by applications to set aside private regions of code
diff --git a/arch/x86/kernel/cpu/sgx/main.c b/arch/x86/kernel/cpu/sgx/main.c
index 8df81a3ed945..21addedc5240 100644
--- a/arch/x86/kernel/cpu/sgx/main.c
+++ b/arch/x86/kernel/cpu/sgx/main.c
@@ -18,6 +18,12 @@ static int sgx_nr_epc_sections;
 static struct task_struct *ksgxd_tsk;
 static DECLARE_WAIT_QUEUE_HEAD(ksgxd_waitq);
 
+/* Nodes with one or more EPC sections. */
+static nodemask_t sgx_numa_mask;
+
+/* Array of lists of EPC sections for each NUMA node. */
+struct list_head *sgx_numa_nodes;
+
 /*
  * These variables are part of the state of the reclaimer, and must be accessed
  * with sgx_reclaimer_lock acquired.
@@ -473,6 +479,26 @@ static struct sgx_epc_page 
*__sgx_alloc_epc_page_from_section(struct sgx_epc_sec
return page;
 }
 
+static struct sgx_epc_page *__sgx_alloc_epc_page_from_node(int nid)
+{
+   struct sgx_epc_section *section;
+   struct sgx_epc_page *page;
+
+   if (WARN_ON_ONCE(nid < 0 || nid >= MAX_NUMNODES))
+   return NULL;
+
+   if (!node_isset(nid, sgx_numa_mask))
+   return NULL;
+
+   list_for_each_entry(section, _numa_nodes[nid], section_list) {
+   page = __sgx_alloc_epc_page_from_section(section);
+   if (page)
+   return page;
+   }
+
+   return NULL;
+}
+
 /**
  * __sgx_alloc_epc_page() - Allocate an EPC page
  *
@@ -485,13 +511,17 @@ static struct sgx_epc_page 
*__sgx_alloc_epc_page_from_section(struct sgx_epc_sec
  */
 struct sgx_epc_page *__sgx_alloc_epc_page(void)
 {
+   int current_nid = numa_node_id();
struct sgx_epc_section *section;
struct sgx_epc_page *page;
int i;
 
+   page = __sgx_alloc_epc_page_from_node(current_nid);
+   if (page)
+   return page;
+
for (i = 0; i < sgx_nr_epc_sections; i++) {
section = _epc_sections[i];
-
page = __sgx_alloc_epc_page_from_section(section);
if (page)
return page;
@@ -665,8 +695,12 @@ static bool __init sgx_page_cache_init(void)
 {
u32 eax, ebx, ecx, edx, type;
u64 pa, size;
+   int nid;
int i;
 
+   nodes_clear(sgx_numa_mask);
+   sgx_numa_nodes = kmalloc_array(MAX_NUMNODES, sizeof(*sgx_numa_nodes), 
GFP_KERNEL);
+
for (i = 0; i < ARRAY_SIZE(sgx_epc_sections); i++) {
cpuid_count(SGX_CPUID, i + SGX_CPUID_EPC, , , , 
);
 
@@ -690,6 +724,22 @@ static bool __init sgx_page_cache_init(void)
}
 
sgx_nr_epc_sections++;
+
+   nid = numa_map_to_online_node(phys_to_target_node(pa));
+
+   if (nid == NUMA_NO_NODE) {
+   pr_err(FW_BUG "unable to map EPC section %d to online 
node.\n", nid);
+   nid = 0;
+   } else if (WARN_ON_ONCE(nid < 0 || nid >= MAX_NUMNODES)) {
+   nid = 0;
+   }
+
+   if (!node_isset(nid, sgx_numa_mask)) {
+   INIT_LIST_HEAD(_numa_nodes[nid]);
+   node_set(nid, sgx_numa_mask);
+   }
+
+   list_add_tail(_epc_sections[i].section_list, 
_numa_nodes[nid]);
}
 
if (!sgx_nr_epc_sections) {
diff --git a/arch/x86/kernel/cpu/sgx/sgx.h b/arch/x86/kernel/cpu/sgx/sgx.h
index 5fa42d143feb..4bc31bc4bacf 100644
--- a/arch/x86/kernel/cpu/sgx/sgx.h

Re: [PATCH] video: fbdev: pm2fb: avoid stall on fb_sync

Hi Tong,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.11 next-20210219]
[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/Tong-Zhang/video-fbdev-pm2fb-avoid-stall-on-fb_sync/20210221-070421
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
f40ddce88593482919761f74910f42f4b84c004b
config: x86_64-randconfig-a003-20210221 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
c9439ca36342fb6013187d0a69aef92736951476)
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
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# 
https://github.com/0day-ci/linux/commit/77b85e0ba17f78b0335bf283901691ec3942dec3
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Tong-Zhang/video-fbdev-pm2fb-avoid-stall-on-fb_sync/20210221-070421
git checkout 77b85e0ba17f78b0335bf283901691ec3942dec3
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

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

All errors (new ones prefixed by >>):

>> drivers/video/fbdev/pm2fb.c:193:19: error: cannot combine with previous 
>> 'int' declaration specifier
   static int inline void WAIT_FIFO_TIMEOUT(struct pm2fb_par *p, u32 a)
 ^
   1 error generated.


vim +/int +193 drivers/video/fbdev/pm2fb.c

   183  
   184  #ifdef CONFIG_FB_PM2_FIFO_DISCONNECT
   185  #define WAIT_FIFO(p, a)
   186  #define WAIT_FIFO_TIMEOUT(p, a) (0)
   187  #else
   188  static inline void WAIT_FIFO(struct pm2fb_par *p, u32 a)
   189  {
   190  while (pm2_RD(p, PM2R_IN_FIFO_SPACE) < a)
   191  cpu_relax();
   192  }
 > 193  static int inline void WAIT_FIFO_TIMEOUT(struct pm2fb_par *p, u32 a)
   194  {
   195  int timeout = 1;
   196  while (pm2_RD(p, PM2R_IN_FIFO_SPACE) < a) {
   197  cpu_relax();
   198  if (--timeout==0)
   199  return 1;
   200  }
   201  return 0;
   202  }
   203  #endif
   204  

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


.config.gz
Description: application/gzip

Urgent Response

2021-02-20 Thread Alexandra Kelly

Dear friend,

I am contacting you independently of my investigation in
my bank and no one is informed of this communication. I need your
urgent assistance in transferring the sum of $5.3 million dollars to
your private account,that belongs to one of our foreign customers who
died a longtime with his supposed NEXT OF KIN since July 22, 2003. The
money has been here in our Bank lying dormant for years now without
anybody coming for the claim of it.

I want to release the money to you as the relative to our deceased
customer , the Banking laws here does not allow such money to stay
more than 18 years, because the money will be recalled to the Bank
treasury account as unclaimed fund. I am ready to share with you 40%
for you and 60% will be kept for me, by indicating your interest i
will send you the full details on how the business will be executed, i
will be waiting for your urgent response.

Re: [PATCH] arp: Remove the arp_hh_ops structure

2021-02-20 Thread David Ahern

On 2/19/21 9:32 PM, Yejune Deng wrote:
>  static const struct neigh_ops arp_direct_ops = {
>   .family =   AF_INET,
>   .output =   neigh_direct_output,
> @@ -277,15 +269,10 @@ static int arp_constructor(struct neighbour *neigh)
>   memcpy(neigh->ha, dev->broadcast, dev->addr_len);
>   }
>  
> - if (dev->header_ops->cache)
> - neigh->ops = _hh_ops;
> - else
> - neigh->ops = _generic_ops;

How did you test this?

you took out the neigh->ops assignment, so all of the neigh->ops in
net/core/neighbour.c are going to cause a NULL dereference.


> -
> - if (neigh->nud_state & NUD_VALID)
> - neigh->output = neigh->ops->connected_output;
> + if (!dev->header_ops->cache && (neigh->nud_state & NUD_VALID))
> + neigh->output = arp_generic_ops.connected_output;
>   else
> - neigh->output = neigh->ops->output;
> + neigh->output = arp_generic_ops.output;
>   }
>   return 0;
>  }
>

Re: [PATCH] virt: acrn: Use vfs_poll() instead of f_op->poll()

2021-02-20 Thread Liu, Shuo A




On 2/20/2021 22:53, Yejune Deng wrote:
> Use vfs_poll() is a more advanced function in acrn_irqfd_assign().
> as the same time, modify the definition of events.
> 
> Signed-off-by: Yejune Deng 

Thanks for the update.
Reviewed-by: Shuo Liu 

Hi Greg,
Need i do more work on this patch?
Or you will review and apply on your tree directly?

Thanks
shuo

> ---
>  drivers/virt/acrn/irqfd.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/virt/acrn/irqfd.c b/drivers/virt/acrn/irqfd.c
> index a8766d528e29..98d6e9b18f9e 100644
> --- a/drivers/virt/acrn/irqfd.c
> +++ b/drivers/virt/acrn/irqfd.c
> @@ -112,7 +112,7 @@ static int acrn_irqfd_assign(struct acrn_vm *vm, struct 
> acrn_irqfd *args)
>  {
>   struct eventfd_ctx *eventfd = NULL;
>   struct hsm_irqfd *irqfd, *tmp;
> - unsigned int events;
> + __poll_t events;
>   struct fd f;
>   int ret = 0;
>  
> @@ -158,7 +158,7 @@ static int acrn_irqfd_assign(struct acrn_vm *vm, struct 
> acrn_irqfd *args)
>   mutex_unlock(>irqfds_lock);
>  
>   /* Check the pending event in this stage */
> - events = f.file->f_op->poll(f.file, >pt);
> + events = vfs_poll(f.file, >pt);
>  
>   if (events & POLLIN)
>   acrn_irqfd_inject(irqfd);
>

Re: KASAN: use-after-free Read in blk_update_request

2021-02-20 Thread syzbot

syzbot has found a reproducer for the following issue on:

HEAD commit:f40ddce8 Linux 5.11
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1156374ad0
kernel config:  https://syzkaller.appspot.com/x/.config?x=4b919ebed7b4902
dashboard link: https://syzkaller.appspot.com/bug?extid=a3f809f70c0f239cda46
compiler:   Debian clang version 11.0.1-2
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=143ee67ad0
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1585d40cd0

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+a3f809f70c0f239cd...@syzkaller.appspotmail.com

==
BUG: KASAN: use-after-free in debug_spin_unlock 
kernel/locking/spinlock_debug.c:97 [inline]
BUG: KASAN: use-after-free in do_raw_spin_unlock+0x481/0x8a0 
kernel/locking/spinlock_debug.c:138
Read of size 4 at addr 888020c03154 by task ksoftirqd/0/12

CPU: 0 PID: 12 Comm: ksoftirqd/0 Not tainted 5.11.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:79 [inline]
 dump_stack+0x137/0x1be lib/dump_stack.c:120
 print_address_description+0x5f/0x3a0 mm/kasan/report.c:230
 __kasan_report mm/kasan/report.c:396 [inline]
 kasan_report+0x15e/0x200 mm/kasan/report.c:413
 debug_spin_unlock kernel/locking/spinlock_debug.c:97 [inline]
 do_raw_spin_unlock+0x481/0x8a0 kernel/locking/spinlock_debug.c:138
 __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:159 [inline]
 _raw_spin_unlock_irqrestore+0x20/0x60 kernel/locking/spinlock.c:191
 spin_unlock_irqrestore include/linux/spinlock.h:409 [inline]
 __wake_up_common_lock kernel/sched/wait.c:140 [inline]
 __wake_up+0xe2/0x140 kernel/sched/wait.c:157
 req_bio_endio block/blk-core.c:264 [inline]
 blk_update_request+0x7f7/0x14f0 block/blk-core.c:1462
 blk_mq_end_request+0x39/0x70 block/blk-mq.c:564
 blk_done_softirq+0x2fd/0x380 block/blk-mq.c:588
 __do_softirq+0x318/0x714 kernel/softirq.c:343
 run_ksoftirqd+0x63/0xa0 kernel/softirq.c:650
 smpboot_thread_fn+0x572/0x970 kernel/smpboot.c:165
 kthread+0x39a/0x3c0 kernel/kthread.c:292
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296

Allocated by task 8906:
 kasan_save_stack mm/kasan/common.c:38 [inline]
 kasan_set_track mm/kasan/common.c:46 [inline]
 set_alloc_info mm/kasan/common.c:401 [inline]
 kasan_kmalloc+0xbd/0xf0 mm/kasan/common.c:429
 kasan_kmalloc include/linux/kasan.h:219 [inline]
 kmem_cache_alloc_trace+0x200/0x300 mm/slub.c:2919
 kmalloc include/linux/slab.h:552 [inline]
 lbmLogInit fs/jfs/jfs_logmgr.c:1829 [inline]
 lmLogInit+0x26e/0x1530 fs/jfs/jfs_logmgr.c:1278
 open_inline_log fs/jfs/jfs_logmgr.c:1183 [inline]
 lmLogOpen+0x4c6/0xeb0 fs/jfs/jfs_logmgr.c:1077
 jfs_mount_rw+0x91/0x4a0 fs/jfs/jfs_mount.c:259
 jfs_fill_super+0x57e/0x960 fs/jfs/super.c:571
 mount_bdev+0x26c/0x3a0 fs/super.c:1366
 legacy_get_tree+0xea/0x180 fs/fs_context.c:592
 vfs_get_tree+0x86/0x270 fs/super.c:1496
 do_new_mount fs/namespace.c:2881 [inline]
 path_mount+0x17ad/0x2a00 fs/namespace.c:3211
 do_mount fs/namespace.c:3224 [inline]
 __do_sys_mount fs/namespace.c:3432 [inline]
 __se_sys_mount+0x28c/0x320 fs/namespace.c:3409
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9

Freed by task 8906:
 kasan_save_stack mm/kasan/common.c:38 [inline]
 kasan_set_track+0x3d/0x70 mm/kasan/common.c:46
 kasan_set_free_info+0x1f/0x40 mm/kasan/generic.c:356
 kasan_slab_free+0xe2/0x110 mm/kasan/common.c:362
 kasan_slab_free include/linux/kasan.h:192 [inline]
 slab_free_hook mm/slub.c:1547 [inline]
 slab_free_freelist_hook+0xd6/0x1a0 mm/slub.c:1580
 slab_free mm/slub.c:3143 [inline]
 kfree+0xd1/0x2a0 mm/slub.c:4139
 lbmLogShutdown fs/jfs/jfs_logmgr.c:1872 [inline]
 lmLogInit+0xfb5/0x1530 fs/jfs/jfs_logmgr.c:1423
 open_inline_log fs/jfs/jfs_logmgr.c:1183 [inline]
 lmLogOpen+0x4c6/0xeb0 fs/jfs/jfs_logmgr.c:1077
 jfs_mount_rw+0x91/0x4a0 fs/jfs/jfs_mount.c:259
 jfs_fill_super+0x57e/0x960 fs/jfs/super.c:571
 mount_bdev+0x26c/0x3a0 fs/super.c:1366
 legacy_get_tree+0xea/0x180 fs/fs_context.c:592
 vfs_get_tree+0x86/0x270 fs/super.c:1496
 do_new_mount fs/namespace.c:2881 [inline]
 path_mount+0x17ad/0x2a00 fs/namespace.c:3211
 do_mount fs/namespace.c:3224 [inline]
 __do_sys_mount fs/namespace.c:3432 [inline]
 __se_sys_mount+0x28c/0x320 fs/namespace.c:3409
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9

Last potentially related work creation:
 kasan_save_stack+0x27/0x50 mm/kasan/common.c:38
 kasan_record_aux_stack+0xcc/0x100 mm/kasan/generic.c:344
 insert_work+0x54/0x400 kernel/workqueue.c:1331
 __queue_work+0x97f/0xcc0 kernel/workqueue.c:1497
 queue_work_on+0xc1/0x120 kernel/workqueue.c:1524
 queue_work include/linux/workqueue.h:507 [inline]
 call_usermodehelper_exec+0x206/0x3d0 kernel/umh.c:433

Re: [PATCH] video: fbdev: pm2fb: avoid stall on fb_sync

Hi Tong,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.11 next-20210219]
[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/Tong-Zhang/video-fbdev-pm2fb-avoid-stall-on-fb_sync/20210221-070421
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
f40ddce88593482919761f74910f42f4b84c004b
config: i386-randconfig-s002-20210221 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.3-229-g60c1f270-dirty
# 
https://github.com/0day-ci/linux/commit/77b85e0ba17f78b0335bf283901691ec3942dec3
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Tong-Zhang/video-fbdev-pm2fb-avoid-stall-on-fb_sync/20210221-070421
git checkout 77b85e0ba17f78b0335bf283901691ec3942dec3
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386 

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

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

>> drivers/video/fbdev/pm2fb.c:193:1: warning: 'inline' is not at beginning of 
>> declaration [-Wold-style-declaration]
 193 | static int inline void WAIT_FIFO_TIMEOUT(struct pm2fb_par *p, u32 a)
 | ^~
>> drivers/video/fbdev/pm2fb.c:193:19: error: two or more data types in 
>> declaration specifiers
 193 | static int inline void WAIT_FIFO_TIMEOUT(struct pm2fb_par *p, u32 a)
 |   ^~~~


vim +193 drivers/video/fbdev/pm2fb.c

   183  
   184  #ifdef CONFIG_FB_PM2_FIFO_DISCONNECT
   185  #define WAIT_FIFO(p, a)
   186  #define WAIT_FIFO_TIMEOUT(p, a) (0)
   187  #else
   188  static inline void WAIT_FIFO(struct pm2fb_par *p, u32 a)
   189  {
   190  while (pm2_RD(p, PM2R_IN_FIFO_SPACE) < a)
   191  cpu_relax();
   192  }
 > 193  static int inline void WAIT_FIFO_TIMEOUT(struct pm2fb_par *p, u32 a)
   194  {
   195  int timeout = 1;
   196  while (pm2_RD(p, PM2R_IN_FIFO_SPACE) < a) {
   197  cpu_relax();
   198  if (--timeout==0)
   199  return 1;
   200  }
   201  return 0;
   202  }
   203  #endif
   204  

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


.config.gz
Description: application/gzip

Re: WARNING in iov_iter_revert (2)

2021-02-20 Thread Linus Torvalds

[ Let's see how long this lasts, but I've got a generator for the
laptop, and hopefully I'll be able to start doing pulls tonight, and
get "real" power tomorrow ]

On Sat, Feb 20, 2021 at 11:30 AM Al Viro  wrote:
>
> IOW, it's not iov_iter_revert() being weird or do_tty_write() misuing it -
> it's tpk_write() playing silly buggers.

Ok, that's actually not as bad I was was afraid it might be.

> Do we want to preserve that weirdness of /dev/ttyprintk writes?
> That's orthogonal to the iov_iter uses in there.

I don't think the ttyprintk weirdness was intentional. I'd fix that,
but in the meantime clearly we should make do_tty_write() protect
against this insanity, and do something like

   --- a/drivers/tty/tty_io.c
   +++ b/drivers/tty/tty_io.c
   @@ -961,6 +961,9 @@ static inline ssize_t do_tty_write(
ret = write(tty, file, tty->write_buf, size);
if (ret <= 0)
break;
   +/* ttyprintk historical oddity */
   +if (ret > size)
   +break;

/* FIXME! Have Al check this! */
if (ret != size)

in there. Because right now we clearly do strange and not-so-wonderful
things if the write routine returns a bigger value than it was
passed.. Not limited to that iov_iter_revert() thing, but the whole
loop.

Comments?

  Linus

Re: [PATCH v2] video: fbdev: pm2fb: avoid stall on fb_sync

2021-02-20 Thread Randy Dunlap

On 2/20/21 4:00 PM, Tong Zhang wrote:
> pm2fb_sync is called when doing /dev/fb read or write.
> The original pm2fb_sync wait indefinitely on hardware flags which can
> possibly stall kernel and make everything unresponsive.
> Instead of waiting indefinitely, we can timeout to give user a chance to
> get back control.
> 
> [   39.503356] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
> rel-1.13.0-48-gd9c812dda5194
> [   39.503947] Call Trace:
> [   39.504081]  
> [   39.504193]  dump_stack+0x7d/0xa3
> [   39.504377]  nmi_cpu_backtrace.cold+0x32/0x7e
> [   39.504613]  ? lapic_can_unplug_cpu+0x70/0x70
> [   39.504850]  nmi_trigger_cpumask_backtrace+0xdf/0x100
> [   39.505121]  rcu_dump_cpu_stacks+0xed/0x130
> [   39.505349]  rcu_sched_clock_irq.cold+0x3b1/0x61d
> [   39.505602]  ? hrtimer_run_queues+0x2c/0x1b0
> [   39.505833]  ? __acct_update_integrals+0x136/0x160
> [   39.506091]  update_process_times+0xb9/0xf0
> [   39.506317]  tick_sched_handle.isra.0+0x5c/0x80
> [   39.506562]  tick_sched_timer+0x70/0x90
> [   39.506770]  __hrtimer_run_queues+0x1c6/0x3e0
> [   39.517095]  ? tick_sched_handle.isra.0+0x80/0x80
> [   39.517349]  ? enqueue_hrtimer+0xd0/0xd0
> [   39.517561]  ? _raw_write_lock_irqsave+0xd0/0xd0
> [   39.517812]  ? ktime_get+0x45/0xb0
> [   39.517997]  ? ktime_get_update_offsets_now+0x96/0x150
> [   39.518273]  hrtimer_interrupt+0x1a0/0x340
> [   39.518496]  __sysvec_apic_timer_interrupt+0x7f/0x160
> [   39.518768]  asm_call_irq_on_stack+0xf/0x20
> [   39.518997]  
> [   39.519114]  sysvec_apic_timer_interrupt+0x6f/0x80
> [   39.519372]  asm_sysvec_apic_timer_interrupt+0x12/0x20
> [   39.519647] RIP: 0010:pm2fb_sync+0x47/0x70 [pm2fb]
> [   39.519907] Code: 89 ef e8 0c 87 2c c1 48 8b 53 08 31 c0 89 82 40 8c 00 00 
> 0f ae f0 48 8b 53 08 1
> [   39.520885] RSP: 0018:88810a1f7df8 EFLAGS: 0202
> [   39.521165] RAX: 72d5d49f RBX: 88810a034418 RCX: 
> c90b0020
> [   39.521542] RDX: c90b RSI: 0246 RDI: 
> 88810a034420
> [   39.521920] RBP: 88810a034420 R08:  R09: 
> ed102143ef64
> [   39.522297] R10: 0003 R11: ed102143ef63 R12: 
> 88810a1f7ed0
> [   39.522673] R13: 88810a034000 R14: c9000280 R15: 
> 888109e5e000
> [   39.523053]  ? pm2fb_sync+0x24/0x70 [pm2fb]
> [   39.523280]  fb_write+0x1c2/0x2d0
> [   39.523461]  vfs_write+0x108/0x380
> [   39.523647]  ksys_write+0xb4/0x150
> [   39.523832]  ? __ia32_sys_read+0x40/0x40
> [   39.524043]  ? fpregs_assert_state_consistent+0x4d/0x60
> [   39.524322]  do_syscall_64+0x33/0x40
> [   39.524517]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [   39.524788] RIP: 0033:0x7f5e50097970
> [   39.524981] Code: 73 01 c3 48 8b 0d 28 d5 2b 00 f7 d8 64 89 01 48 83 c8 ff 
> c3 66 0f 1f 44 00 00 4
> [   39.525952] RSP: 002b:7ffec6895b38 EFLAGS: 0246 ORIG_RAX: 
> 0001
> [   39.526352] RAX: ffda RBX:  RCX: 
> 7f5e50097970
> [   39.526726] RDX: 0200 RSI: 56491a6ad000 RDI: 
> 0001
> [   39.537261] RBP: 0200 R08:  R09: 
> 56491a6ad030
> [   39.537633] R10: 0871 R11: 0246 R12: 
> 0800
> [   39.538008] R13: 56491a6ad000 R14: 0200 R15: 
> 
> 
> Signed-off-by: Tong Zhang 
> ---
>  v2: fix typo and add console log according to Randy's 
>  comment
> 
>  drivers/video/fbdev/pm2fb.c | 29 ++---
>  1 file changed, 26 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/video/fbdev/pm2fb.c b/drivers/video/fbdev/pm2fb.c
> index 27893fa139b0..d6731e04252f 100644
> --- a/drivers/video/fbdev/pm2fb.c
> +++ b/drivers/video/fbdev/pm2fb.c
> @@ -183,12 +183,23 @@ static inline void pm2v_RDAC_WR(struct pm2fb_par *p, 
> s32 idx, u32 v)
>  
>  #ifdef CONFIG_FB_PM2_FIFO_DISCONNECT
>  #define WAIT_FIFO(p, a)
> +#define WAIT_FIFO_TIMEOUT(p, a) (0)
>  #else
>  static inline void WAIT_FIFO(struct pm2fb_par *p, u32 a)
>  {
>   while (pm2_RD(p, PM2R_IN_FIFO_SPACE) < a)
>   cpu_relax();
>  }

/* return 1 for timeout, otherwise 0 */
> +static inline int WAIT_FIFO_TIMEOUT(struct pm2fb_par *p, u32 a)
> +{
> + int timeout = 1;
> + while (pm2_RD(p, PM2R_IN_FIFO_SPACE) < a) {
> + cpu_relax();
> + if (--timeout == 0)
> + return 1;
> + }
> + return 0;
> +}
>  #endif
>  
>  /*
> @@ -1031,15 +1042,27 @@ static int pm2fb_blank(int blank_mode, struct fb_info 
> *info)
>  static int pm2fb_sync(struct fb_info *info)
>  {
>   struct pm2fb_par *par = info->par;
> + int timeout_sync = 1;
> + int timeout_fifo;
>  
> - WAIT_FIFO(par, 1);
> + if (WAIT_FIFO_TIMEOUT(par, 1))
> + goto end;

if the above goto happens, timeout_fifo is used but not initialized
at label end:

>   pm2_WR(par, PM2R_SYNC, 0);
>   mb();
>   do {
> - while (pm2_RD(par,

Re: linux-next: manual merge of the arm-soc tree with the arm tree

2021-02-20 Thread Stephen Rothwell

Hi Alain,

On Sat, 20 Feb 2021 20:45:25 +0100 Alain Volmat  wrote:
>
> sorry for the delay, is there anything I should do concerning this issue
> ?

No, it should be taken care of my the maintainers when they get Linus
to merge their trees.

-- 
Cheers,
Stephen Rothwell

pgp6n6zDuD5bG.pgp
Description: OpenPGP digital signature

[PATCH] ia64: fix ia64_syscall_get_set_arguments() for break-based syscalls

2021-02-20 Thread Sergei Trofimovich

In https://bugs.gentoo.org/769614 Dmitry noticed that
`ptrace(PTRACE_GET_SYSCALL_INFO)` does not work for syscalls called
via glibc's syscall() wrapper.

ia64 has two ways to call syscalls from userspace: via `break` and via
`eps` instructions.

The difference is in stack layout:

1. `eps` creates simple stack frame: no locals, in{0..7} == out{0..8}
2. `break` uses userspace stack frame: may be locals (glibc provides
   one), in{0..7} == out{0..8}.

Both work fine in syscall handling cde itself.

But `ptrace(PTRACE_GET_SYSCALL_INFO)` uses unwind mechanism to
re-extract syscall arguments but it does not account for locals.

The change always skips locals registers. It should not change `eps`
path as kernel's handler already enforces locals=0 and fixes `break`.

Tested on v5.10 on rx3600 machine (ia64 9040 CPU).

CC: Oleg Nesterov 
CC: linux-i...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
CC: Andrew Morton 
Reported-by: Dmitry V. Levin 
Bug: https://bugs.gentoo.org/769614
Signed-off-by: Sergei Trofimovich 
---
 arch/ia64/kernel/ptrace.c | 24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/arch/ia64/kernel/ptrace.c b/arch/ia64/kernel/ptrace.c
index c3490ee2daa5..e14f5653393a 100644
--- a/arch/ia64/kernel/ptrace.c
+++ b/arch/ia64/kernel/ptrace.c
@@ -2013,27 +2013,39 @@ static void syscall_get_set_args_cb(struct 
unw_frame_info *info, void *data)
 {
struct syscall_get_set_args *args = data;
struct pt_regs *pt = args->regs;
-   unsigned long *krbs, cfm, ndirty;
+   unsigned long *krbs, cfm, ndirty, nlocals, nouts;
int i, count;
 
if (unw_unwind_to_user(info) < 0)
return;
 
+   /*
+* We get here via a few paths:
+* - break instruction: cfm is shared with caller.
+*   syscall args are in out= regs, locals are non-empty.
+* - epsinstruction: cfm is set by br.call
+*   locals don't exist.
+*
+* For both cases argguments are reachable in cfm.sof - cfm.sol.
+* CFM: [ ... | sor: 17..14 | sol : 13..7 | sof : 6..0 ]
+*/
cfm = pt->cr_ifs;
+   nlocals = (cfm >> 7) & 0x7f; /* aka sol */
+   nouts = (cfm & 0x7f) - nlocals; /* aka sof - sol */
krbs = (unsigned long *)info->task + IA64_RBS_OFFSET/8;
ndirty = ia64_rse_num_regs(krbs, krbs + (pt->loadrs >> 19));
 
count = 0;
if (in_syscall(pt))
-   count = min_t(int, args->n, cfm & 0x7f);
+   count = min_t(int, args->n, nouts);
 
+   /* Iterate over outs. */
for (i = 0; i < count; i++) {
+   int j = ndirty + nlocals + i + args->i;
if (args->rw)
-   *ia64_rse_skip_regs(krbs, ndirty + i + args->i) =
-   args->args[i];
+   *ia64_rse_skip_regs(krbs, j) = args->args[i];
else
-   args->args[i] = *ia64_rse_skip_regs(krbs,
-   ndirty + i + args->i);
+   args->args[i] = *ia64_rse_skip_regs(krbs, j);
}
 
if (!args->rw) {
-- 
2.30.1

[PATCH] ia64: fix ptrace(PTRACE_SYSCALL_INFO_EXIT) sign

2021-02-20 Thread Sergei Trofimovich

In https://bugs.gentoo.org/769614 Dmitry noticed that
`ptrace(PTRACE_GET_SYSCALL_INFO)` does not return error sign properly.

The bug is in mismatch between get/set errors:

static inline long syscall_get_error(struct task_struct *task,
 struct pt_regs *regs)
{
return regs->r10 == -1 ? regs->r8:0;
}

static inline long syscall_get_return_value(struct task_struct *task,
struct pt_regs *regs)
{
return regs->r8;
}

static inline void syscall_set_return_value(struct task_struct *task,
struct pt_regs *regs,
int error, long val)
{
if (error) {
/* error < 0, but ia64 uses > 0 return value */
regs->r8 = -error;
regs->r10 = -1;
} else {
regs->r8 = val;
regs->r10 = 0;
}
}

Tested on v5.10 on rx3600 machine (ia64 9040 CPU).

CC: linux-i...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
CC: Andrew Morton 
Reported-by: Dmitry V. Levin 
Bug: https://bugs.gentoo.org/769614
Signed-off-by: Sergei Trofimovich 
---
 arch/ia64/include/asm/syscall.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/ia64/include/asm/syscall.h b/arch/ia64/include/asm/syscall.h
index 6c6f16e409a8..0d23c0049301 100644
--- a/arch/ia64/include/asm/syscall.h
+++ b/arch/ia64/include/asm/syscall.h
@@ -32,7 +32,7 @@ static inline void syscall_rollback(struct task_struct *task,
 static inline long syscall_get_error(struct task_struct *task,
 struct pt_regs *regs)
 {
-   return regs->r10 == -1 ? regs->r8:0;
+   return regs->r10 == -1 ? -regs->r8:0;
 }
 
 static inline long syscall_get_return_value(struct task_struct *task,
-- 
2.30.1

Re: [PATCH] video: fbdev: pm2fb: avoid stall on fb_sync

Hi Randy,
Thanks for the comment.
I currently have this problem on my machine.
I have submitted a revised patch -- which includes the console log.
Thanks!
- Tong

On Sat, Feb 20, 2021 at 6:33 PM Randy Dunlap  wrote:
>
> Hi--
>
> On 2/20/21 3:02 PM, Tong Zhang wrote:
> > pm2fb_sync is called when doing /dev/fb read or write.
> > The original pm2fb_sync wait indefinitely on hardware flags which can
> > possibly stall kernel and make everything unresponsive.
> > Instead of waiting indefinitely, we can timeout to give user a chance to
> > get back control.
>
> Is this a real problem or theoretical?
> Does someone still use this driver?
>
>
> > Signed-off-by: Tong Zhang 
> > ---
> >  drivers/video/fbdev/pm2fb.c | 29 ++---
> >  1 file changed, 26 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/pm2fb.c b/drivers/video/fbdev/pm2fb.c
> > index 27893fa139b0..8578c64a0c54 100644
> > --- a/drivers/video/fbdev/pm2fb.c
> > +++ b/drivers/video/fbdev/pm2fb.c
> > @@ -183,12 +183,23 @@ static inline void pm2v_RDAC_WR(struct pm2fb_par *p, 
> > s32 idx, u32 v)
> >
> >  #ifdef CONFIG_FB_PM2_FIFO_DISCONNECT
> >  #define WAIT_FIFO(p, a)
> > +#define WAIT_FIFO_TIMEOUT(p, a) (0)
> >  #else
> >  static inline void WAIT_FIFO(struct pm2fb_par *p, u32 a)
> >  {
> >   while (pm2_RD(p, PM2R_IN_FIFO_SPACE) < a)
> >   cpu_relax();
> >  }
> > +static int inline void WAIT_FIFO_TIMEOUT(struct pm2fb_par *p, u32 a)
>
> drop  void   ^^^
> It's already "int".
> Did you compile this?
>
> > +{
> > + int timeout = 1;
> > + while (pm2_RD(p, PM2R_IN_FIFO_SPACE) < a) {
> > + cpu_relax();
> > + if (--timeout==0)
>
> spaces around ==
>
> > + return 1;
> > + }
> > + return 0;
> > +}
> >  #endif
> >
> >  /*
> > @@ -1031,15 +1042,27 @@ static int pm2fb_blank(int blank_mode, struct 
> > fb_info *info)
> >  static int pm2fb_sync(struct fb_info *info)
> >  {
> >   struct pm2fb_par *par = info->par;
> > + int timeout_sync = 1;
> > + int timeout_fifo;
> >
> > - WAIT_FIFO(par, 1);
> > + if (WAIT_FIFO_TIMEOUT(par, 1))
> > + goto end;
> >   pm2_WR(par, PM2R_SYNC, 0);
> >   mb();
> >   do {
> > - while (pm2_RD(par, PM2R_OUT_FIFO_WORDS) == 0)
> > + timeout_fifo = 1;
> > + while (pm2_RD(par, PM2R_OUT_FIFO_WORDS) == 0) {
> >   cpu_relax();
> > - } while (pm2_RD(par, PM2R_OUT_FIFO) != PM2TAG(PM2R_SYNC));
> > + if (--timeout_fifo==0)
>
> spaces around ==
>
> > + goto end;
> > + }
> > + if (pm2_RD(par, PM2R_OUT_FIFO) == PM2TAG(PM2R_SYNC))
> > + break;
> > + } while (--timeout_sync>0);
>
> spaces around >
>
> >
> > +end:
> > + if ((!timeout_sync) || (!timeout_fifo))
> > + printk_ratelimited(KERN_WARNING "pm2fb: sync timeout!\n");
> >   return 0;
> >  }
> >
> >
>
>
> thanks.
> --
> ~Randy

[PATCH v2] video: fbdev: pm2fb: avoid stall on fb_sync

pm2fb_sync is called when doing /dev/fb read or write.
The original pm2fb_sync wait indefinitely on hardware flags which can
possibly stall kernel and make everything unresponsive.
Instead of waiting indefinitely, we can timeout to give user a chance to
get back control.

[   39.503356] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
rel-1.13.0-48-gd9c812dda5194
[   39.503947] Call Trace:
[   39.504081]  
[   39.504193]  dump_stack+0x7d/0xa3
[   39.504377]  nmi_cpu_backtrace.cold+0x32/0x7e
[   39.504613]  ? lapic_can_unplug_cpu+0x70/0x70
[   39.504850]  nmi_trigger_cpumask_backtrace+0xdf/0x100
[   39.505121]  rcu_dump_cpu_stacks+0xed/0x130
[   39.505349]  rcu_sched_clock_irq.cold+0x3b1/0x61d
[   39.505602]  ? hrtimer_run_queues+0x2c/0x1b0
[   39.505833]  ? __acct_update_integrals+0x136/0x160
[   39.506091]  update_process_times+0xb9/0xf0
[   39.506317]  tick_sched_handle.isra.0+0x5c/0x80
[   39.506562]  tick_sched_timer+0x70/0x90
[   39.506770]  __hrtimer_run_queues+0x1c6/0x3e0
[   39.517095]  ? tick_sched_handle.isra.0+0x80/0x80
[   39.517349]  ? enqueue_hrtimer+0xd0/0xd0
[   39.517561]  ? _raw_write_lock_irqsave+0xd0/0xd0
[   39.517812]  ? ktime_get+0x45/0xb0
[   39.517997]  ? ktime_get_update_offsets_now+0x96/0x150
[   39.518273]  hrtimer_interrupt+0x1a0/0x340
[   39.518496]  __sysvec_apic_timer_interrupt+0x7f/0x160
[   39.518768]  asm_call_irq_on_stack+0xf/0x20
[   39.518997]  
[   39.519114]  sysvec_apic_timer_interrupt+0x6f/0x80
[   39.519372]  asm_sysvec_apic_timer_interrupt+0x12/0x20
[   39.519647] RIP: 0010:pm2fb_sync+0x47/0x70 [pm2fb]
[   39.519907] Code: 89 ef e8 0c 87 2c c1 48 8b 53 08 31 c0 89 82 40 8c 00 00 
0f ae f0 48 8b 53 08 1
[   39.520885] RSP: 0018:88810a1f7df8 EFLAGS: 0202
[   39.521165] RAX: 72d5d49f RBX: 88810a034418 RCX: c90b0020
[   39.521542] RDX: c90b RSI: 0246 RDI: 88810a034420
[   39.521920] RBP: 88810a034420 R08:  R09: ed102143ef64
[   39.522297] R10: 0003 R11: ed102143ef63 R12: 88810a1f7ed0
[   39.522673] R13: 88810a034000 R14: c9000280 R15: 888109e5e000
[   39.523053]  ? pm2fb_sync+0x24/0x70 [pm2fb]
[   39.523280]  fb_write+0x1c2/0x2d0
[   39.523461]  vfs_write+0x108/0x380
[   39.523647]  ksys_write+0xb4/0x150
[   39.523832]  ? __ia32_sys_read+0x40/0x40
[   39.524043]  ? fpregs_assert_state_consistent+0x4d/0x60
[   39.524322]  do_syscall_64+0x33/0x40
[   39.524517]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   39.524788] RIP: 0033:0x7f5e50097970
[   39.524981] Code: 73 01 c3 48 8b 0d 28 d5 2b 00 f7 d8 64 89 01 48 83 c8 ff 
c3 66 0f 1f 44 00 00 4
[   39.525952] RSP: 002b:7ffec6895b38 EFLAGS: 0246 ORIG_RAX: 
0001
[   39.526352] RAX: ffda RBX:  RCX: 7f5e50097970
[   39.526726] RDX: 0200 RSI: 56491a6ad000 RDI: 0001
[   39.537261] RBP: 0200 R08:  R09: 56491a6ad030
[   39.537633] R10: 0871 R11: 0246 R12: 0800
[   39.538008] R13: 56491a6ad000 R14: 0200 R15: 

Signed-off-by: Tong Zhang 
---
 v2: fix typo and add console log according to Randy's  
comment

 drivers/video/fbdev/pm2fb.c | 29 ++---
 1 file changed, 26 insertions(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/pm2fb.c b/drivers/video/fbdev/pm2fb.c
index 27893fa139b0..d6731e04252f 100644
--- a/drivers/video/fbdev/pm2fb.c
+++ b/drivers/video/fbdev/pm2fb.c
@@ -183,12 +183,23 @@ static inline void pm2v_RDAC_WR(struct pm2fb_par *p, s32 
idx, u32 v)
 
 #ifdef CONFIG_FB_PM2_FIFO_DISCONNECT
 #define WAIT_FIFO(p, a)
+#define WAIT_FIFO_TIMEOUT(p, a) (0)
 #else
 static inline void WAIT_FIFO(struct pm2fb_par *p, u32 a)
 {
while (pm2_RD(p, PM2R_IN_FIFO_SPACE) < a)
cpu_relax();
 }
+static inline int WAIT_FIFO_TIMEOUT(struct pm2fb_par *p, u32 a)
+{
+   int timeout = 1;
+   while (pm2_RD(p, PM2R_IN_FIFO_SPACE) < a) {
+   cpu_relax();
+   if (--timeout == 0)
+   return 1;
+   }
+   return 0;
+}
 #endif
 
 /*
@@ -1031,15 +1042,27 @@ static int pm2fb_blank(int blank_mode, struct fb_info 
*info)
 static int pm2fb_sync(struct fb_info *info)
 {
struct pm2fb_par *par = info->par;
+   int timeout_sync = 1;
+   int timeout_fifo;
 
-   WAIT_FIFO(par, 1);
+   if (WAIT_FIFO_TIMEOUT(par, 1))
+   goto end;
pm2_WR(par, PM2R_SYNC, 0);
mb();
do {
-   while (pm2_RD(par, PM2R_OUT_FIFO_WORDS) == 0)
+   timeout_fifo = 1;
+   while (pm2_RD(par, PM2R_OUT_FIFO_WORDS) == 0) {
cpu_relax();
-   } while (pm2_RD(par, PM2R_OUT_FIFO) != PM2TAG(PM2R_SYNC));
+   if (--timeout_fifo == 0)
+   goto end;
+   }
+   if (pm2_RD(par, PM2R_OUT_FIFO) ==

Re: [PATCH v8 16/22] counter: Move counter enums to uapi header

2021-02-20 Thread David Lechner


On 2/12/21 6:13 AM, William Breathitt Gray wrote:

This is in preparation for a subsequent patch implementing a character
device interface for the Counter subsystem.

Signed-off-by: William Breathitt Gray 
---


Reviewed-by: David Lechner

contact

2021-02-20 Thread admin

We are reaching you once again as regards the estate of Late George Brumley, 
you were made one of the beneficiaries of his estate. Do get back to me at your 
earliest convenience. The Trustees

Re: [PATCH] video: fbdev: pm2fb: avoid stall on fb_sync

2021-02-20 Thread Randy Dunlap

Hi--

On 2/20/21 3:02 PM, Tong Zhang wrote:
> pm2fb_sync is called when doing /dev/fb read or write.
> The original pm2fb_sync wait indefinitely on hardware flags which can
> possibly stall kernel and make everything unresponsive.
> Instead of waiting indefinitely, we can timeout to give user a chance to
> get back control.

Is this a real problem or theoretical?
Does someone still use this driver?


> Signed-off-by: Tong Zhang 
> ---
>  drivers/video/fbdev/pm2fb.c | 29 ++---
>  1 file changed, 26 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/video/fbdev/pm2fb.c b/drivers/video/fbdev/pm2fb.c
> index 27893fa139b0..8578c64a0c54 100644
> --- a/drivers/video/fbdev/pm2fb.c
> +++ b/drivers/video/fbdev/pm2fb.c
> @@ -183,12 +183,23 @@ static inline void pm2v_RDAC_WR(struct pm2fb_par *p, 
> s32 idx, u32 v)
>  
>  #ifdef CONFIG_FB_PM2_FIFO_DISCONNECT
>  #define WAIT_FIFO(p, a)
> +#define WAIT_FIFO_TIMEOUT(p, a) (0)
>  #else
>  static inline void WAIT_FIFO(struct pm2fb_par *p, u32 a)
>  {
>   while (pm2_RD(p, PM2R_IN_FIFO_SPACE) < a)
>   cpu_relax();
>  }
> +static int inline void WAIT_FIFO_TIMEOUT(struct pm2fb_par *p, u32 a)

drop  void   ^^^
It's already "int".
Did you compile this?

> +{
> + int timeout = 1;
> + while (pm2_RD(p, PM2R_IN_FIFO_SPACE) < a) {
> + cpu_relax();
> + if (--timeout==0)

spaces around ==

> + return 1;
> + }
> + return 0;
> +}
>  #endif
>  
>  /*
> @@ -1031,15 +1042,27 @@ static int pm2fb_blank(int blank_mode, struct fb_info 
> *info)
>  static int pm2fb_sync(struct fb_info *info)
>  {
>   struct pm2fb_par *par = info->par;
> + int timeout_sync = 1;
> + int timeout_fifo;
>  
> - WAIT_FIFO(par, 1);
> + if (WAIT_FIFO_TIMEOUT(par, 1))
> + goto end;
>   pm2_WR(par, PM2R_SYNC, 0);
>   mb();
>   do {
> - while (pm2_RD(par, PM2R_OUT_FIFO_WORDS) == 0)
> + timeout_fifo = 1;
> + while (pm2_RD(par, PM2R_OUT_FIFO_WORDS) == 0) {
>   cpu_relax();
> - } while (pm2_RD(par, PM2R_OUT_FIFO) != PM2TAG(PM2R_SYNC));
> + if (--timeout_fifo==0)

spaces around ==

> + goto end;
> + }
> + if (pm2_RD(par, PM2R_OUT_FIFO) == PM2TAG(PM2R_SYNC))
> + break;
> + } while (--timeout_sync>0);

spaces around >

>  
> +end:
> + if ((!timeout_sync) || (!timeout_fifo))
> + printk_ratelimited(KERN_WARNING "pm2fb: sync timeout!\n");
>   return 0;
>  }
>  
> 


thanks.
-- 
~Randy

Re: [PATCH v4 2/2] Input: add MStar MSG2638 touchscreen driver

2021-02-20 Thread Dmitry Torokhov

Hi Vincent,

On Wed, Feb 10, 2021 at 06:33:52PM +0100, Vincent Knecht wrote:
> +
> + for (i = 0; i < MAX_SUPPORTED_FINGER_NUM; i++) {
> + p = _event.pkt[i];
> + /* Ignore non-pressed finger data */
> + if (p->xy_hi == 0xFF && p->x_low == 0xFF && p->y_low == 0xFF)
> + continue;
> +
> + coord.x = (((p->xy_hi & 0xF0) << 4) | p->x_low) * 
> msg2638->prop.max_x / TPD_WIDTH;
> + coord.y = (((p->xy_hi & 0x0F) << 8) | p->y_low) * 
> msg2638->prop.max_y / TPD_HEIGHT;
> + msg2638_report_finger(msg2638, i, );

We do not scale the coordinates in the kernel. Rather we provide
resolution, if known, and min/max coordinates reported by the hardware,
and let userspace handle the rest.

> +static int __maybe_unused msg2638_suspend(struct device *dev)
> +{
> + struct i2c_client *client = to_i2c_client(dev);
> + struct msg2638_ts_data *msg2638 = i2c_get_clientdata(client);
> +
> + mutex_lock(>input_dev->mutex);
> +
> + if (input_device_enabled(msg2638->input_dev))
> + msg2638_stop(msg2638);

I believe that you should power down the device only if it is not
configures as wakeup source. In fact (and I think most drivers are
wrong in this), you may want to power up the device if it is a wakeup
source and it does not have any users.

Thanks.

-- 
Dmitry

[PATCH v6 9/9] smp: inline on_each_cpu_cond() and on_each_cpu()

From: Nadav Amit 

Simplify the code and avoid having an additional function on the stack
by inlining on_each_cpu_cond() and on_each_cpu().

Cc: Andy Lutomirski 
Cc: Thomas Gleixner 
Suggested-by: Peter Zijlstra 
Signed-off-by: Nadav Amit 
---
 include/linux/smp.h | 50 
 kernel/smp.c| 56 -
 2 files changed, 36 insertions(+), 70 deletions(-)

diff --git a/include/linux/smp.h b/include/linux/smp.h
index 70c6f6284dcf..84a0b4828f66 100644
--- a/include/linux/smp.h
+++ b/include/linux/smp.h
@@ -50,30 +50,52 @@ extern unsigned int total_cpus;
 int smp_call_function_single(int cpuid, smp_call_func_t func, void *info,
 int wait);
 
+void on_each_cpu_cond_mask(smp_cond_func_t cond_func, smp_call_func_t func,
+  void *info, bool wait, const struct cpumask *mask);
+
+int smp_call_function_single_async(int cpu, call_single_data_t *csd);
+
 /*
  * Call a function on all processors
  */
-void on_each_cpu(smp_call_func_t func, void *info, int wait);
+static inline void on_each_cpu(smp_call_func_t func, void *info, int wait)
+{
+   on_each_cpu_cond_mask(NULL, func, info, wait, cpu_online_mask);
+}
 
-/*
- * Call a function on processors specified by mask, which might include
- * the local one.
+/**
+ * on_each_cpu_mask(): Run a function on processors specified by
+ * cpumask, which may include the local processor.
+ * @mask: The set of cpus to run on (only runs on online subset).
+ * @func: The function to run. This must be fast and non-blocking.
+ * @info: An arbitrary pointer to pass to the function.
+ * @wait: If true, wait (atomically) until function has completed
+ *on other CPUs.
+ *
+ * If @wait is true, then returns once @func has returned.
+ *
+ * You must not call this function with disabled interrupts or from a
+ * hardware interrupt handler or from a bottom half handler.  The
+ * exception is that it may be used during early boot while
+ * early_boot_irqs_disabled is set.
  */
-void on_each_cpu_mask(const struct cpumask *mask, smp_call_func_t func,
-   void *info, bool wait);
+static inline void on_each_cpu_mask(const struct cpumask *mask,
+   smp_call_func_t func, void *info, bool wait)
+{
+   on_each_cpu_cond_mask(NULL, func, info, wait, mask);
+}
 
 /*
  * Call a function on each processor for which the supplied function
  * cond_func returns a positive value. This may include the local
- * processor.
+ * processor.  May be used during early boot while early_boot_irqs_disabled is
+ * set. Use local_irq_save/restore() instead of local_irq_disable/enable().
  */
-void on_each_cpu_cond(smp_cond_func_t cond_func, smp_call_func_t func,
- void *info, bool wait);
-
-void on_each_cpu_cond_mask(smp_cond_func_t cond_func, smp_call_func_t func,
-  void *info, bool wait, const struct cpumask *mask);
-
-int smp_call_function_single_async(int cpu, call_single_data_t *csd);
+static inline void on_each_cpu_cond(smp_cond_func_t cond_func,
+   smp_call_func_t func, void *info, bool wait)
+{
+   on_each_cpu_cond_mask(cond_func, func, info, wait, cpu_online_mask);
+}
 
 #ifdef CONFIG_SMP
 
diff --git a/kernel/smp.c b/kernel/smp.c
index c8a5a1facc1a..b6375d775e93 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -847,55 +847,6 @@ void __init smp_init(void)
smp_cpus_done(setup_max_cpus);
 }
 
-/*
- * Call a function on all processors.  May be used during early boot while
- * early_boot_irqs_disabled is set.  Use local_irq_save/restore() instead
- * of local_irq_disable/enable().
- */
-void on_each_cpu(smp_call_func_t func, void *info, int wait)
-{
-   unsigned long flags;
-
-   preempt_disable();
-   smp_call_function(func, info, wait);
-   local_irq_save(flags);
-   func(info);
-   local_irq_restore(flags);
-   preempt_enable();
-}
-EXPORT_SYMBOL(on_each_cpu);
-
-/**
- * on_each_cpu_mask(): Run a function on processors specified by
- * cpumask, which may include the local processor.
- * @mask: The set of cpus to run on (only runs on online subset).
- * @func: The function to run. This must be fast and non-blocking.
- * @info: An arbitrary pointer to pass to the function.
- * @wait: If true, wait (atomically) until function has completed
- *on other CPUs.
- *
- * If @wait is true, then returns once @func has returned.
- *
- * You must not call this function with disabled interrupts or from a
- * hardware interrupt handler or from a bottom half handler.  The
- * exception is that it may be used during early boot while
- * early_boot_irqs_disabled is set.
- */
-void on_each_cpu_mask(const struct cpumask *mask, smp_call_func_t func,
-   void *info, bool wait)
-{
-   unsigned int scf_flags;
-
-   scf_flags = SCF_RUN_LOCAL;
-   if (wait)
-   scf_flags |= SCF_WAIT;
-
-

[PATCH v6 8/9] x86/mm/tlb: Remove unnecessary uses of the inline keyword

From: Nadav Amit 

The compiler is smart enough without these hints.

Cc: Andy Lutomirski 
Cc: Peter Zijlstra 
Suggested-by: Dave Hansen 
Reviewed-by: Dave Hansen 
Signed-off-by: Nadav Amit 
---
 arch/x86/mm/tlb.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 17ec4bfeee67..f4b162f273f5 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -316,7 +316,7 @@ void switch_mm(struct mm_struct *prev, struct mm_struct 
*next,
local_irq_restore(flags);
 }
 
-static inline unsigned long mm_mangle_tif_spec_ib(struct task_struct *next)
+static unsigned long mm_mangle_tif_spec_ib(struct task_struct *next)
 {
unsigned long next_tif = task_thread_info(next)->flags;
unsigned long ibpb = (next_tif >> TIF_SPEC_IB) & LAST_USER_MM_IBPB;
@@ -880,7 +880,7 @@ static DEFINE_PER_CPU_SHARED_ALIGNED(struct flush_tlb_info, 
flush_tlb_info);
 static DEFINE_PER_CPU(unsigned int, flush_tlb_info_idx);
 #endif
 
-static inline struct flush_tlb_info *get_flush_tlb_info(struct mm_struct *mm,
+static struct flush_tlb_info *get_flush_tlb_info(struct mm_struct *mm,
unsigned long start, unsigned long end,
unsigned int stride_shift, bool freed_tables,
u64 new_tlb_gen)
@@ -907,7 +907,7 @@ static inline struct flush_tlb_info 
*get_flush_tlb_info(struct mm_struct *mm,
return info;
 }
 
-static inline void put_flush_tlb_info(void)
+static void put_flush_tlb_info(void)
 {
 #ifdef CONFIG_DEBUG_VM
/* Complete reentrency prevention checks */
-- 
2.25.1

[PATCH v6 7/9] cpumask: Mark functions as pure

From: Nadav Amit 

cpumask_next_and() and cpumask_any_but() are pure, and marking them as
such seems to generate different and presumably better code for
native_flush_tlb_multi().

Reviewed-by: Dave Hansen 
Signed-off-by: Nadav Amit 
---
 include/linux/cpumask.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index 383684e30f12..c53364c4296d 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -235,7 +235,7 @@ static inline unsigned int cpumask_last(const struct 
cpumask *srcp)
return find_last_bit(cpumask_bits(srcp), nr_cpumask_bits);
 }
 
-unsigned int cpumask_next(int n, const struct cpumask *srcp);
+unsigned int __pure cpumask_next(int n, const struct cpumask *srcp);
 
 /**
  * cpumask_next_zero - get the next unset cpu in a cpumask
@@ -252,8 +252,8 @@ static inline unsigned int cpumask_next_zero(int n, const 
struct cpumask *srcp)
return find_next_zero_bit(cpumask_bits(srcp), nr_cpumask_bits, n+1);
 }
 
-int cpumask_next_and(int n, const struct cpumask *, const struct cpumask *);
-int cpumask_any_but(const struct cpumask *mask, unsigned int cpu);
+int __pure cpumask_next_and(int n, const struct cpumask *, const struct 
cpumask *);
+int __pure cpumask_any_but(const struct cpumask *mask, unsigned int cpu);
 unsigned int cpumask_local_spread(unsigned int i, int node);
 int cpumask_any_and_distribute(const struct cpumask *src1p,
   const struct cpumask *src2p);
-- 
2.25.1

[PATCH v6 6/9] x86/mm/tlb: Do not make is_lazy dirty for no reason

From: Nadav Amit 

Blindly writing to is_lazy for no reason, when the written value is
identical to the old value, makes the cacheline dirty for no reason.
Avoid making such writes to prevent cache coherency traffic for no
reason.

Cc: Andy Lutomirski 
Cc: Peter Zijlstra 
Suggested-by: Dave Hansen 
Reviewed-by: Dave Hansen 
Signed-off-by: Nadav Amit 
---
 arch/x86/mm/tlb.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 345a0aff5de4..17ec4bfeee67 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -469,7 +469,8 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct 
mm_struct *next,
__flush_tlb_all();
}
 #endif
-   this_cpu_write(cpu_tlbstate_shared.is_lazy, false);
+   if (was_lazy)
+   this_cpu_write(cpu_tlbstate_shared.is_lazy, false);
 
/*
 * The membarrier system call requires a full memory barrier and
-- 
2.25.1

[PATCH v6 5/9] x86/mm/tlb: Privatize cpu_tlbstate

From: Nadav Amit 

cpu_tlbstate is mostly private and only the variable is_lazy is shared.
This causes some false-sharing when TLB flushes are performed.

Break cpu_tlbstate intro cpu_tlbstate and cpu_tlbstate_shared, and mark
each one accordingly.

Cc: Andy Lutomirski 
Cc: Peter Zijlstra 
Reviewed-by: Dave Hansen 
Signed-off-by: Nadav Amit 

---
v5 -> v6:
* Fixed warning due to mismatch in
  {DEFINE|DECLARE}_PER_CPU_{SHARED_}ALIGNED
---
 arch/x86/include/asm/tlbflush.h | 39 ++---
 arch/x86/kernel/alternative.c   |  2 +-
 arch/x86/mm/init.c  |  2 +-
 arch/x86/mm/tlb.c   | 17 --
 4 files changed, 33 insertions(+), 27 deletions(-)

diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index 3c6681def912..fa952eadbc2e 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -89,23 +89,6 @@ struct tlb_state {
u16 loaded_mm_asid;
u16 next_asid;
 
-   /*
-* We can be in one of several states:
-*
-*  - Actively using an mm.  Our CPU's bit will be set in
-*mm_cpumask(loaded_mm) and is_lazy == false;
-*
-*  - Not using a real mm.  loaded_mm == _mm.  Our CPU's bit
-*will not be set in mm_cpumask(_mm) and is_lazy == false.
-*
-*  - Lazily using a real mm.  loaded_mm != _mm, our bit
-*is set in mm_cpumask(loaded_mm), but is_lazy == true.
-*We're heuristically guessing that the CR3 load we
-*skipped more than makes up for the overhead added by
-*lazy mode.
-*/
-   bool is_lazy;
-
/*
 * If set we changed the page tables in such a way that we
 * needed an invalidation of all contexts (aka. PCIDs / ASIDs).
@@ -151,7 +134,27 @@ struct tlb_state {
 */
struct tlb_context ctxs[TLB_NR_DYN_ASIDS];
 };
-DECLARE_PER_CPU_SHARED_ALIGNED(struct tlb_state, cpu_tlbstate);
+DECLARE_PER_CPU_ALIGNED(struct tlb_state, cpu_tlbstate);
+
+struct tlb_state_shared {
+   /*
+* We can be in one of several states:
+*
+*  - Actively using an mm.  Our CPU's bit will be set in
+*mm_cpumask(loaded_mm) and is_lazy == false;
+*
+*  - Not using a real mm.  loaded_mm == _mm.  Our CPU's bit
+*will not be set in mm_cpumask(_mm) and is_lazy == false.
+*
+*  - Lazily using a real mm.  loaded_mm != _mm, our bit
+*is set in mm_cpumask(loaded_mm), but is_lazy == true.
+*We're heuristically guessing that the CR3 load we
+*skipped more than makes up for the overhead added by
+*lazy mode.
+*/
+   bool is_lazy;
+};
+DECLARE_PER_CPU_SHARED_ALIGNED(struct tlb_state_shared, cpu_tlbstate_shared);
 
 bool nmi_uaccess_okay(void);
 #define nmi_uaccess_okay nmi_uaccess_okay
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 8d778e46725d..94649f86d653 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -813,7 +813,7 @@ static inline temp_mm_state_t use_temporary_mm(struct 
mm_struct *mm)
 * with a stale address space WITHOUT being in lazy mode after
 * restoring the previous mm.
 */
-   if (this_cpu_read(cpu_tlbstate.is_lazy))
+   if (this_cpu_read(cpu_tlbstate_shared.is_lazy))
leave_mm(smp_processor_id());
 
temp_state.mm = this_cpu_read(cpu_tlbstate.loaded_mm);
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index dd694fb93916..ed2e36748758 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -1017,7 +1017,7 @@ void __init zone_sizes_init(void)
free_area_init(max_zone_pfns);
 }
 
-__visible DEFINE_PER_CPU_SHARED_ALIGNED(struct tlb_state, cpu_tlbstate) = {
+__visible DEFINE_PER_CPU_ALIGNED(struct tlb_state, cpu_tlbstate) = {
.loaded_mm = _mm,
.next_asid = 1,
.cr4 = ~0UL,/* fail hard if we screw up cr4 shadow initialization */
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 8db87cd92e6b..345a0aff5de4 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -300,7 +300,7 @@ void leave_mm(int cpu)
return;
 
/* Warn if we're not lazy. */
-   WARN_ON(!this_cpu_read(cpu_tlbstate.is_lazy));
+   WARN_ON(!this_cpu_read(cpu_tlbstate_shared.is_lazy));
 
switch_mm(NULL, _mm, NULL);
 }
@@ -424,7 +424,7 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct 
mm_struct *next,
 {
struct mm_struct *real_prev = this_cpu_read(cpu_tlbstate.loaded_mm);
u16 prev_asid = this_cpu_read(cpu_tlbstate.loaded_mm_asid);
-   bool was_lazy = this_cpu_read(cpu_tlbstate.is_lazy);
+   bool was_lazy = this_cpu_read(cpu_tlbstate_shared.is_lazy);
unsigned cpu = smp_processor_id();
u64 next_tlb_gen;
bool need_flush;
@@ -469,7 +469,7 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct

[PATCH v6 4/9] x86/mm/tlb: Flush remote and local TLBs concurrently

From: Nadav Amit 

To improve TLB shootdown performance, flush the remote and local TLBs
concurrently. Introduce flush_tlb_multi() that does so. Introduce
paravirtual versions of flush_tlb_multi() for KVM, Xen and hyper-v (Xen
and hyper-v are only compile-tested).

While the updated smp infrastructure is capable of running a function on
a single local core, it is not optimized for this case. The multiple
function calls and the indirect branch introduce some overhead, and
might make local TLB flushes slower than they were before the recent
changes.

Before calling the SMP infrastructure, check if only a local TLB flush
is needed to restore the lost performance in this common case. This
requires to check mm_cpumask() one more time, but unless this mask is
updated very frequently, this should impact performance negatively.

Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Cc: Sasha Levin 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: x...@kernel.org
Cc: Juergen Gross 
Cc: Paolo Bonzini 
Cc: Andy Lutomirski 
Cc: Peter Zijlstra 
Cc: Boris Ostrovsky 
Cc: linux-hyp...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: k...@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
Reviewed-by: Michael Kelley  # Hyper-v parts
Reviewed-by: Juergen Gross  # Xen and paravirt parts
Reviewed-by: Dave Hansen 
Signed-off-by: Nadav Amit 

---
v5->v6:
* Use on_each_cpu_mask() instead of on_each_cpu_cond_mask() [PeterZ]
* Use cond_cpumask when needed instead of cpumask
* Rename remaining instance of native_flush_tlb_others()
---
 arch/x86/hyperv/mmu.c | 10 +++---
 arch/x86/include/asm/paravirt.h   |  6 ++--
 arch/x86/include/asm/paravirt_types.h |  4 +--
 arch/x86/include/asm/tlbflush.h   |  4 +--
 arch/x86/include/asm/trace/hyperv.h   |  2 +-
 arch/x86/kernel/kvm.c | 11 +--
 arch/x86/kernel/paravirt.c|  2 +-
 arch/x86/mm/tlb.c | 46 +--
 arch/x86/xen/mmu_pv.c | 11 +++
 include/trace/events/xen.h|  2 +-
 10 files changed, 57 insertions(+), 41 deletions(-)

diff --git a/arch/x86/hyperv/mmu.c b/arch/x86/hyperv/mmu.c
index 2c87350c1fb0..681dba8de4f2 100644
--- a/arch/x86/hyperv/mmu.c
+++ b/arch/x86/hyperv/mmu.c
@@ -52,8 +52,8 @@ static inline int fill_gva_list(u64 gva_list[], int offset,
return gva_n - offset;
 }
 
-static void hyperv_flush_tlb_others(const struct cpumask *cpus,
-   const struct flush_tlb_info *info)
+static void hyperv_flush_tlb_multi(const struct cpumask *cpus,
+  const struct flush_tlb_info *info)
 {
int cpu, vcpu, gva_n, max_gvas;
struct hv_tlb_flush **flush_pcpu;
@@ -61,7 +61,7 @@ static void hyperv_flush_tlb_others(const struct cpumask 
*cpus,
u64 status = U64_MAX;
unsigned long flags;
 
-   trace_hyperv_mmu_flush_tlb_others(cpus, info);
+   trace_hyperv_mmu_flush_tlb_multi(cpus, info);
 
if (!hv_hypercall_pg)
goto do_native;
@@ -164,7 +164,7 @@ static void hyperv_flush_tlb_others(const struct cpumask 
*cpus,
if (!(status & HV_HYPERCALL_RESULT_MASK))
return;
 do_native:
-   native_flush_tlb_others(cpus, info);
+   native_flush_tlb_multi(cpus, info);
 }
 
 static u64 hyperv_flush_tlb_others_ex(const struct cpumask *cpus,
@@ -239,6 +239,6 @@ void hyperv_setup_mmu_ops(void)
return;
 
pr_info("Using hypercall for remote TLB flush\n");
-   pv_ops.mmu.flush_tlb_others = hyperv_flush_tlb_others;
+   pv_ops.mmu.flush_tlb_multi = hyperv_flush_tlb_multi;
pv_ops.mmu.tlb_remove_table = tlb_remove_table;
 }
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 4abf110e2243..45b55e3e0630 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -50,7 +50,7 @@ static inline void slow_down_io(void)
 void native_flush_tlb_local(void);
 void native_flush_tlb_global(void);
 void native_flush_tlb_one_user(unsigned long addr);
-void native_flush_tlb_others(const struct cpumask *cpumask,
+void native_flush_tlb_multi(const struct cpumask *cpumask,
 const struct flush_tlb_info *info);
 
 static inline void __flush_tlb_local(void)
@@ -68,10 +68,10 @@ static inline void __flush_tlb_one_user(unsigned long addr)
PVOP_VCALL1(mmu.flush_tlb_one_user, addr);
 }
 
-static inline void __flush_tlb_others(const struct cpumask *cpumask,
+static inline void __flush_tlb_multi(const struct cpumask *cpumask,
  const struct flush_tlb_info *info)
 {
-   PVOP_VCALL2(mmu.flush_tlb_others, cpumask, info);
+   PVOP_VCALL2(mmu.flush_tlb_multi, cpumask, info);
 }
 
 static inline void paravirt_tlb_remove_table(struct mmu_gather *tlb, void 
*table)
diff --git a/arch/x86/include/asm/paravirt_types.h

[PATCH v6 3/9] x86/mm/tlb: Open-code on_each_cpu_cond_mask() for tlb_is_not_lazy()

From: Nadav Amit 

Open-code on_each_cpu_cond_mask() in native_flush_tlb_others() to
optimize the code. Open-coding eliminates the need for the indirect branch
that is used to call is_lazy(), and in CPUs that are vulnerable to
Spectre v2, it eliminates the retpoline. In addition, it allows to use a
preallocated cpumask to compute the CPUs that should be.

This would later allow us not to adapt on_each_cpu_cond_mask() to
support local and remote functions.

Note that calling tlb_is_not_lazy() for every CPU that needs to be
flushed, as done in native_flush_tlb_multi() might look ugly, but it is
equivalent to what is currently done in on_each_cpu_cond_mask().
Actually, native_flush_tlb_multi() does it more efficiently since it
avoids using an indirect branch for the matter.

Reviewed-by: Dave Hansen 
Cc: Peter Zijlstra 
Cc: Rik van Riel 
Cc: Thomas Gleixner 
Cc: Andy Lutomirski 
Cc: Josh Poimboeuf 
Signed-off-by: Nadav Amit 
---
 arch/x86/mm/tlb.c | 37 -
 1 file changed, 32 insertions(+), 5 deletions(-)

diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index bf12371db6c4..07b6701a540a 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -788,11 +788,13 @@ static void flush_tlb_func(void *info)
nr_invalidate);
 }
 
-static bool tlb_is_not_lazy(int cpu, void *data)
+static bool tlb_is_not_lazy(int cpu)
 {
return !per_cpu(cpu_tlbstate.is_lazy, cpu);
 }
 
+static DEFINE_PER_CPU(cpumask_t, flush_tlb_mask);
+
 STATIC_NOPV void native_flush_tlb_others(const struct cpumask *cpumask,
 const struct flush_tlb_info *info)
 {
@@ -813,12 +815,37 @@ STATIC_NOPV void native_flush_tlb_others(const struct 
cpumask *cpumask,
 * up on the new contents of what used to be page tables, while
 * doing a speculative memory access.
 */
-   if (info->freed_tables)
+   if (info->freed_tables) {
smp_call_function_many(cpumask, flush_tlb_func,
   (void *)info, 1);
-   else
-   on_each_cpu_cond_mask(tlb_is_not_lazy, flush_tlb_func,
-   (void *)info, 1, cpumask);
+   } else {
+   /*
+* Although we could have used on_each_cpu_cond_mask(),
+* open-coding it has performance advantages, as it eliminates
+* the need for indirect calls or retpolines. In addition, it
+* allows to use a designated cpumask for evaluating the
+* condition, instead of allocating one.
+*
+* This code works under the assumption that there are no nested
+* TLB flushes, an assumption that is already made in
+* flush_tlb_mm_range().
+*
+* cond_cpumask is logically a stack-local variable, but it is
+* more efficient to have it off the stack and not to allocate
+* it on demand. Preemption is disabled and this code is
+* non-reentrant.
+*/
+   struct cpumask *cond_cpumask = this_cpu_ptr(_tlb_mask);
+   int cpu;
+
+   cpumask_clear(cond_cpumask);
+
+   for_each_cpu(cpu, cpumask) {
+   if (tlb_is_not_lazy(cpu))
+   __cpumask_set_cpu(cpu, cond_cpumask);
+   }
+   smp_call_function_many(cond_cpumask, flush_tlb_func, (void 
*)info, 1);
+   }
 }
 
 void flush_tlb_others(const struct cpumask *cpumask,
-- 
2.25.1

[PATCH v6 2/9] x86/mm/tlb: Unify flush_tlb_func_local() and flush_tlb_func_remote()

From: Nadav Amit 

The unification of these two functions allows to use them in the updated
SMP infrastrucutre.

To do so, remove the reason argument from flush_tlb_func_local(), add
a member to struct tlb_flush_info that says which CPU initiated the
flush and act accordingly. Optimize the size of flush_tlb_info while we
are at it.

Unfortunately, this prevents us from using a constant tlb_flush_info for
arch_tlbbatch_flush(), but in a later stage we may be able to inline
tlb_flush_info into the IPI data, so it should not have an impact
eventually.

Reviewed-by: Dave Hansen 
Cc: Peter Zijlstra 
Cc: Rik van Riel 
Cc: Thomas Gleixner 
Cc: Andy Lutomirski 
Cc: Josh Poimboeuf 
Signed-off-by: Nadav Amit 
---
 arch/x86/include/asm/tlbflush.h |  5 +-
 arch/x86/mm/tlb.c   | 81 +++--
 2 files changed, 39 insertions(+), 47 deletions(-)

diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index 8c87a2e0b660..a7a598af116d 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -201,8 +201,9 @@ struct flush_tlb_info {
unsigned long   start;
unsigned long   end;
u64 new_tlb_gen;
-   unsigned intstride_shift;
-   boolfreed_tables;
+   unsigned intinitiating_cpu;
+   u8  stride_shift;
+   u8  freed_tables;
 };
 
 void flush_tlb_local(void);
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 569ac1d57f55..bf12371db6c4 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -439,7 +439,7 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct 
mm_struct *next,
 * NB: leave_mm() calls us with prev == NULL and tsk == NULL.
 */
 
-   /* We don't want flush_tlb_func_* to run concurrently with us. */
+   /* We don't want flush_tlb_func() to run concurrently with us. */
if (IS_ENABLED(CONFIG_PROVE_LOCKING))
WARN_ON_ONCE(!irqs_disabled());
 
@@ -647,14 +647,13 @@ void initialize_tlbstate_and_flush(void)
 }
 
 /*
- * flush_tlb_func_common()'s memory ordering requirement is that any
+ * flush_tlb_func()'s memory ordering requirement is that any
  * TLB fills that happen after we flush the TLB are ordered after we
  * read active_mm's tlb_gen.  We don't need any explicit barriers
  * because all x86 flush operations are serializing and the
  * atomic64_read operation won't be reordered by the compiler.
  */
-static void flush_tlb_func_common(const struct flush_tlb_info *f,
- bool local, enum tlb_flush_reason reason)
+static void flush_tlb_func(void *info)
 {
/*
 * We have three different tlb_gen values in here.  They are:
@@ -665,14 +664,26 @@ static void flush_tlb_func_common(const struct 
flush_tlb_info *f,
 * - f->new_tlb_gen: the generation that the requester of the flush
 *   wants us to catch up to.
 */
+   const struct flush_tlb_info *f = info;
struct mm_struct *loaded_mm = this_cpu_read(cpu_tlbstate.loaded_mm);
u32 loaded_mm_asid = this_cpu_read(cpu_tlbstate.loaded_mm_asid);
u64 mm_tlb_gen = atomic64_read(_mm->context.tlb_gen);
u64 local_tlb_gen = 
this_cpu_read(cpu_tlbstate.ctxs[loaded_mm_asid].tlb_gen);
+   bool local = smp_processor_id() == f->initiating_cpu;
+   unsigned long nr_invalidate = 0;
 
/* This code cannot presently handle being reentered. */
VM_WARN_ON(!irqs_disabled());
 
+   if (!local) {
+   inc_irq_stat(irq_tlb_count);
+   count_vm_tlb_event(NR_TLB_REMOTE_FLUSH_RECEIVED);
+
+   /* Can only happen on remote CPUs */
+   if (f->mm && f->mm != loaded_mm)
+   return;
+   }
+
if (unlikely(loaded_mm == _mm))
return;
 
@@ -700,8 +711,7 @@ static void flush_tlb_func_common(const struct 
flush_tlb_info *f,
 * be handled can catch us all the way up, leaving no work for
 * the second flush.
 */
-   trace_tlb_flush(reason, 0);
-   return;
+   goto done;
}
 
WARN_ON_ONCE(local_tlb_gen > mm_tlb_gen);
@@ -748,46 +758,34 @@ static void flush_tlb_func_common(const struct 
flush_tlb_info *f,
f->new_tlb_gen == local_tlb_gen + 1 &&
f->new_tlb_gen == mm_tlb_gen) {
/* Partial flush */
-   unsigned long nr_invalidate = (f->end - f->start) >> 
f->stride_shift;
unsigned long addr = f->start;
 
+   nr_invalidate = (f->end - f->start) >> f->stride_shift;
+
while (addr < f->end) {
flush_tlb_one_user(addr);
addr += 1UL << f->stride_shift;
}
if (local)

[PATCH v6 1/9] smp: Run functions concurrently in smp_call_function_many_cond()

From: Nadav Amit 

Currently, on_each_cpu() and similar functions do not exploit the
potential of concurrency: the function is first executed remotely and
only then it is executed locally. Functions such as TLB flush can take
considerable time, so this provides an opportunity for performance
optimization.

To do so, modify smp_call_function_many_cond(), to allows the callers to
provide a function that should be executed (remotely/locally), and run
them concurrently. Keep other smp_call_function_many() semantic as it is
today for backward compatibility: the called function is not executed in
this case locally.

smp_call_function_many_cond() does not use the optimized version for a
single remote target that smp_call_function_single() implements. For
synchronous function call, smp_call_function_single() keeps a
call_single_data (which is used for synchronization) on the stack.
Interestingly, it seems that not using this optimization provides
greater performance improvements (greater speedup with a single remote
target than with multiple ones). Presumably, holding data structures
that are intended for synchronization on the stack can introduce
overheads due to TLB misses and false-sharing when the stack is used for
other purposes.

Reviewed-by: Dave Hansen 
Cc: Peter Zijlstra 
Cc: Rik van Riel 
Cc: Thomas Gleixner 
Cc: Andy Lutomirski 
Cc: Josh Poimboeuf 
Signed-off-by: Nadav Amit 

---
v5 -> v6:
* on_each_cpu_cond_mask() was missing preempt_disable/enable() [PeterZ]
* use multiplication instead of condition [PeterZ]
* assert preempt disabled on smp_call_function_many_cond()
* Break 80-char lines (Christoph)
---
 kernel/smp.c | 156 +--
 1 file changed, 88 insertions(+), 68 deletions(-)

diff --git a/kernel/smp.c b/kernel/smp.c
index aeb0adfa0606..c8a5a1facc1a 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -608,12 +608,28 @@ int smp_call_function_any(const struct cpumask *mask,
 }
 EXPORT_SYMBOL_GPL(smp_call_function_any);
 
+/*
+ * Flags to be used as scf_flags argument of smp_call_function_many_cond().
+ *
+ * %SCF_WAIT:  Wait until function execution is completed
+ * %SCF_RUN_LOCAL: Run also locally if local cpu is set in cpumask
+ */
+#define SCF_WAIT   (1U << 0)
+#define SCF_RUN_LOCAL  (1U << 1)
+
 static void smp_call_function_many_cond(const struct cpumask *mask,
smp_call_func_t func, void *info,
-   bool wait, smp_cond_func_t cond_func)
+   unsigned int scf_flags,
+   smp_cond_func_t cond_func)
 {
+   int cpu, last_cpu, this_cpu = smp_processor_id();
struct call_function_data *cfd;
-   int cpu, next_cpu, this_cpu = smp_processor_id();
+   bool wait = scf_flags & SCF_WAIT;
+   bool run_remote = false;
+   bool run_local = false;
+   int nr_cpus = 0;
+
+   lockdep_assert_preemption_disabled();
 
/*
 * Can deadlock when called with interrupts disabled.
@@ -621,8 +637,9 @@ static void smp_call_function_many_cond(const struct 
cpumask *mask,
 * send smp call function interrupt to this cpu and as such deadlocks
 * can't happen.
 */
-   WARN_ON_ONCE(cpu_online(this_cpu) && irqs_disabled()
-&& !oops_in_progress && !early_boot_irqs_disabled);
+   if (cpu_online(this_cpu) && !oops_in_progress &&
+   !early_boot_irqs_disabled)
+   lockdep_assert_irqs_enabled();
 
/*
 * When @wait we can deadlock when we interrupt between llist_add() and
@@ -632,60 +649,65 @@ static void smp_call_function_many_cond(const struct 
cpumask *mask,
 */
WARN_ON_ONCE(!in_task());
 
-   /* Try to fastpath.  So, what's a CPU they want? Ignoring this one. */
+   /* Check if we need local execution. */
+   if ((scf_flags & SCF_RUN_LOCAL) && cpumask_test_cpu(this_cpu, mask))
+   run_local = true;
+
+   /* Check if we need remote execution, i.e., any CPU excluding this one. 
*/
cpu = cpumask_first_and(mask, cpu_online_mask);
if (cpu == this_cpu)
cpu = cpumask_next_and(cpu, mask, cpu_online_mask);
+   if (cpu < nr_cpu_ids)
+   run_remote = true;
 
-   /* No online cpus?  We're done. */
-   if (cpu >= nr_cpu_ids)
-   return;
-
-   /* Do we have another CPU which isn't us? */
-   next_cpu = cpumask_next_and(cpu, mask, cpu_online_mask);
-   if (next_cpu == this_cpu)
-   next_cpu = cpumask_next_and(next_cpu, mask, cpu_online_mask);
-
-   /* Fastpath: do that cpu by itself. */
-   if (next_cpu >= nr_cpu_ids) {
-   if (!cond_func || cond_func(cpu, info))
-   smp_call_function_single(cpu, func, info, wait);
-   return;
-   }
-
-   cfd = this_cpu_ptr(_data);
+   if (run_remote) {
+   cfd =

[PATCH v6 0/9] x86/tlb: Concurrent TLB flushes

From: Nadav Amit 

The series improves TLB shootdown by flushing the local TLB concurrently
with remote TLBs, overlapping the IPI delivery time with the local
flush. Performance numbers can be found in the previous version [1].

v5 was rebased on 5.11 (long time after v4), and had some bugs and
embarrassing build errors. Peter Zijlstra and Christoph Hellwig had some
comments as well. These issues were addressed (excluding one 82-chars
line that I left). Based on their feedback, an additional patch was also
added to reuse on_each_cpu_cond_mask() code and avoid unnecessary calls
by inlining.

KernelCI showed RCU stalls on arm64, which I could not figure out from
the kernel splat. If this issue persists, I would appreciate it someone
can assist in debugging or at least provide the output when running the
kernel with CONFIG_CSD_LOCK_WAIT_DEBUG=Y.

[1] https://lore.kernel.org/lkml/20190823224153.15223-1-na...@vmware.com/

v5 -> v6:
* Address build warnings due to rebase mistakes
* Reuse code from on_each_cpu_cond_mask() and inline [PeterZ]
* Fix some style issues [Hellwig]

v4 -> v5:
* Rebase on 5.11
* Move concurrent smp logic to smp_call_function_many_cond() 
* Remove SGI-UV patch which is not needed anymore

v3 -> v4:
* Merge flush_tlb_func_local and flush_tlb_func_remote() [Peter]
* Prevent preemption on_each_cpu(). It is not needed, but it prevents
  concerns. [Peter/tglx]
* Adding acked-, review-by tags

v2 -> v3:
* Open-code the remote/local-flush decision code [Andy]
* Fix hyper-v, Xen implementations [Andrew]
* Fix redundant TLB flushes.

v1 -> v2:
* Removing the patches that Thomas took [tglx]
* Adding hyper-v, Xen compile-tested implementations [Dave]
* Removing UV [Andy]
* Adding lazy optimization, removing inline keyword [Dave]
* Restructuring patch-set

RFCv2 -> v1:
* Fix comment on flush_tlb_multi [Juergen]
* Removing async invalidation optimizations [Andy]
* Adding KVM support [Paolo]

Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Boris Ostrovsky 
Cc: Dave Hansen 
Cc: Haiyang Zhang 
Cc: Ingo Molnar 
Cc: Josh Poimboeuf 
Cc: Juergen Gross 
Cc: "K. Y. Srinivasan" 
Cc: Paolo Bonzini 
Cc: Peter Zijlstra 
Cc: Rik van Riel 
Cc: Sasha Levin 
Cc: Stephen Hemminger 
Cc: Thomas Gleixner 
Cc: k...@vger.kernel.org
Cc: linux-hyp...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: x...@kernel.org
Cc: xen-de...@lists.xenproject.org

Nadav Amit (9):
  smp: Run functions concurrently in smp_call_function_many_cond()
  x86/mm/tlb: Unify flush_tlb_func_local() and flush_tlb_func_remote()
  x86/mm/tlb: Open-code on_each_cpu_cond_mask() for tlb_is_not_lazy()
  x86/mm/tlb: Flush remote and local TLBs concurrently
  x86/mm/tlb: Privatize cpu_tlbstate
  x86/mm/tlb: Do not make is_lazy dirty for no reason
  cpumask: Mark functions as pure
  x86/mm/tlb: Remove unnecessary uses of the inline keyword
  smp: inline on_each_cpu_cond() and on_each_cpu()

 arch/x86/hyperv/mmu.c |  10 +-
 arch/x86/include/asm/paravirt.h   |   6 +-
 arch/x86/include/asm/paravirt_types.h |   4 +-
 arch/x86/include/asm/tlbflush.h   |  48 ---
 arch/x86/include/asm/trace/hyperv.h   |   2 +-
 arch/x86/kernel/alternative.c |   2 +-
 arch/x86/kernel/kvm.c |  11 +-
 arch/x86/kernel/paravirt.c|   2 +-
 arch/x86/mm/init.c|   2 +-
 arch/x86/mm/tlb.c | 176 +--
 arch/x86/xen/mmu_pv.c |  11 +-
 include/linux/cpumask.h   |   6 +-
 include/linux/smp.h   |  50 +--
 include/trace/events/xen.h|   2 +-
 kernel/smp.c  | 196 +++---
 15 files changed, 278 insertions(+), 250 deletions(-)

-- 
2.25.1

[PATCH] video: fbdev: pm2fb: avoid stall on fb_sync

pm2fb_sync is called when doing /dev/fb read or write.
The original pm2fb_sync wait indefinitely on hardware flags which can
possibly stall kernel and make everything unresponsive.
Instead of waiting indefinitely, we can timeout to give user a chance to
get back control.

Signed-off-by: Tong Zhang 
---
 drivers/video/fbdev/pm2fb.c | 29 ++---
 1 file changed, 26 insertions(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/pm2fb.c b/drivers/video/fbdev/pm2fb.c
index 27893fa139b0..8578c64a0c54 100644
--- a/drivers/video/fbdev/pm2fb.c
+++ b/drivers/video/fbdev/pm2fb.c
@@ -183,12 +183,23 @@ static inline void pm2v_RDAC_WR(struct pm2fb_par *p, s32 
idx, u32 v)
 
 #ifdef CONFIG_FB_PM2_FIFO_DISCONNECT
 #define WAIT_FIFO(p, a)
+#define WAIT_FIFO_TIMEOUT(p, a) (0)
 #else
 static inline void WAIT_FIFO(struct pm2fb_par *p, u32 a)
 {
while (pm2_RD(p, PM2R_IN_FIFO_SPACE) < a)
cpu_relax();
 }
+static int inline void WAIT_FIFO_TIMEOUT(struct pm2fb_par *p, u32 a)
+{
+   int timeout = 1;
+   while (pm2_RD(p, PM2R_IN_FIFO_SPACE) < a) {
+   cpu_relax();
+   if (--timeout==0)
+   return 1;
+   }
+   return 0;
+}
 #endif
 
 /*
@@ -1031,15 +1042,27 @@ static int pm2fb_blank(int blank_mode, struct fb_info 
*info)
 static int pm2fb_sync(struct fb_info *info)
 {
struct pm2fb_par *par = info->par;
+   int timeout_sync = 1;
+   int timeout_fifo;
 
-   WAIT_FIFO(par, 1);
+   if (WAIT_FIFO_TIMEOUT(par, 1))
+   goto end;
pm2_WR(par, PM2R_SYNC, 0);
mb();
do {
-   while (pm2_RD(par, PM2R_OUT_FIFO_WORDS) == 0)
+   timeout_fifo = 1;
+   while (pm2_RD(par, PM2R_OUT_FIFO_WORDS) == 0) {
cpu_relax();
-   } while (pm2_RD(par, PM2R_OUT_FIFO) != PM2TAG(PM2R_SYNC));
+   if (--timeout_fifo==0)
+   goto end;
+   }
+   if (pm2_RD(par, PM2R_OUT_FIFO) == PM2TAG(PM2R_SYNC))
+   break;
+   } while (--timeout_sync>0);
 
+end:
+   if ((!timeout_sync) || (!timeout_fifo))
+   printk_ratelimited(KERN_WARNING "pm2fb: sync timeout!\n");
return 0;
 }
 
-- 
2.25.1

arch/arm/mach-s3c/irq-s3c24xx.c:683:13: warning: no previous prototype for 's3c2410_init_irq'

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   f40ddce88593482919761f74910f42f4b84c004b
commit: 71b9114d2c13a648fbe6523dd859e611c316ad90 ARM: s3c: move into a common 
directory
date:   6 months ago
config: arm-randconfig-r034-20210221 (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
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=71b9114d2c13a648fbe6523dd859e611c316ad90
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 71b9114d2c13a648fbe6523dd859e611c316ad90
# 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 >>):

   arch/arm/mach-s3c/irq-s3c24xx.c:360:39: warning: no previous prototype for 
's3c24xx_handle_irq' [-Wmissing-prototypes]
 360 | asmlinkage void __exception_irq_entry s3c24xx_handle_irq(struct 
pt_regs *regs)
 |   ^~
>> arch/arm/mach-s3c/irq-s3c24xx.c:683:13: warning: no previous prototype for 
>> 's3c2410_init_irq' [-Wmissing-prototypes]
 683 | void __init s3c2410_init_irq(void)
 | ^~~~
   arch/arm/mach-s3c/irq-s3c24xx.c:961:13: warning: no previous prototype for 
's3c2440_init_irq' [-Wmissing-prototypes]
 961 | void __init s3c2440_init_irq(void)
 | ^~~~
   arch/arm/mach-s3c/irq-s3c24xx.c:1034:13: warning: no previous prototype for 
's3c2442_init_irq' [-Wmissing-prototypes]
1034 | void __init s3c2442_init_irq(void)
 | ^~~~
   arch/arm/mach-s3c/irq-s3c24xx.c:1308:12: warning: no previous prototype for 
's3c2410_init_intc_of' [-Wmissing-prototypes]
1308 | int __init s3c2410_init_intc_of(struct device_node *np,
 |^~~~
   arch/arm/mach-s3c/irq-s3c24xx.c:1330:12: warning: no previous prototype for 
's3c2416_init_intc_of' [-Wmissing-prototypes]
1330 | int __init s3c2416_init_intc_of(struct device_node *np,
 |^~~~


vim +/s3c2410_init_irq +683 arch/arm/mach-s3c/irq-s3c24xx.c

a21765a70ec06b arch/arm/plat-s3c24xx/irq.c   Ben Dooks  2007-02-11  682  
f182aa1dfa6283 arch/arm/mach-s3c24xx/irq.c   Heiko Stuebner 2013-03-07 @683  
void __init s3c2410_init_irq(void)
1f629b7a3ced8e arch/arm/plat-s3c24xx/irq.c   Heiko Stuebner 2013-01-29  684  {
1f629b7a3ced8e arch/arm/plat-s3c24xx/irq.c   Heiko Stuebner 2013-01-29  685  
#ifdef CONFIG_FIQ
1f629b7a3ced8e arch/arm/plat-s3c24xx/irq.c   Heiko Stuebner 2013-01-29  686 
init_FIQ(FIQ_START);
1f629b7a3ced8e arch/arm/plat-s3c24xx/irq.c   Heiko Stuebner 2013-01-29  687  
#endif
a21765a70ec06b arch/arm/plat-s3c24xx/irq.c   Ben Dooks  2007-02-11  688  
658dc8fb9cbc77 drivers/irqchip/irq-s3c24xx.c Heiko Stuebner 2013-04-04  689 
s3c_intc[0] = s3c24xx_init_intc(NULL, _s3c2410base[0], NULL,
658dc8fb9cbc77 drivers/irqchip/irq-s3c24xx.c Heiko Stuebner 2013-04-04  690 
0x4a00);
658dc8fb9cbc77 drivers/irqchip/irq-s3c24xx.c Heiko Stuebner 2013-04-04  691 
if (IS_ERR(s3c_intc[0])) {
1f629b7a3ced8e arch/arm/plat-s3c24xx/irq.c   Heiko Stuebner 2013-01-29  692 
pr_err("irq: could not create main interrupt controller\n");
1f629b7a3ced8e arch/arm/plat-s3c24xx/irq.c   Heiko Stuebner 2013-01-29  693 
return;
a21765a70ec06b arch/arm/plat-s3c24xx/irq.c   Ben Dooks  2007-02-11  694 
}
a21765a70ec06b arch/arm/plat-s3c24xx/irq.c   Ben Dooks  2007-02-11  695  
658dc8fb9cbc77 drivers/irqchip/irq-s3c24xx.c Heiko Stuebner 2013-04-04  696 
s3c_intc[1] = s3c24xx_init_intc(NULL, _s3c2410subint[0],
658dc8fb9cbc77 drivers/irqchip/irq-s3c24xx.c Heiko Stuebner 2013-04-04  697 
s3c_intc[0], 0x4a18);
658dc8fb9cbc77 drivers/irqchip/irq-s3c24xx.c Heiko Stuebner 2013-04-04  698 
s3c24xx_init_intc(NULL, _eint[0], s3c_intc[0], 0x56a4);
a21765a70ec06b arch/arm/plat-s3c24xx/irq.c   Ben Dooks  2007-02-11  699  }
f182aa1dfa6283 arch/arm/mach-s3c24xx/irq.c   Heiko Stuebner 2013-03-07  700  
#endif
ef602eb53c8410 arch/arm/plat-s3c24xx/irq.c   Heiko Stuebner 2013-01-29  701  

:: The code at line 683 was first introduced by commit
:: f182aa1dfa6283a1193308c4917aef4a7a982b8c ARM: S3C24XX: move 
s3c24xx_init_irq to s3c2410_init_irq

:: TO: Heiko Stuebner 
:: CC: Kukjin Kim 

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


.config.gz
Description:

Re: [RFC][PATCH 6/6] objtool,x86: Rewrite retpoline thunk calls

2021-02-20 Thread Peter Zijlstra

On Sat, Feb 20, 2021 at 11:28:02PM +0100, Peter Zijlstra wrote:
> On Sat, Feb 20, 2021 at 06:41:01PM +0100, Borislav Petkov wrote:
> > >  - I have more cases for objtool to rewrite code (I'll see if I can
> > >rebase and post that this weekend -- no promises).
> > 
> > Oh noes.
> 
> 11 patches and one beer later, it even boots :-)
> 
> Saves more than 6k on a defconfig build.
> 
> I'll push it out to git in a bit.

https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/log/?h=locking/jump_label

Re: [RFC][PATCH 6/6] objtool,x86: Rewrite retpoline thunk calls

2021-02-20 Thread Peter Zijlstra

On Sat, Feb 20, 2021 at 06:41:01PM +0100, Borislav Petkov wrote:
> >  - if we had negative alternatives objtool doesn't need to actually
> >rewrite code in this case. It could simply emit alternative entries
> >and call it a day.
> 
> I don't mind the negative alt per se - I mind the implementation I saw.
> I'm sure we can come up with something nicer, like, for example, struct
> alt_instr.flags to denote that this feature is a NOT feature. 

So you don't like the ~ or - on cpuid? ISTR we talked about
alt_instr::flags before, but Google isn't playing ball today so I can't
seem to find it.

I can certainly look at adding the flags thing.

Re: [RFC][PATCH 6/6] objtool,x86: Rewrite retpoline thunk calls

2021-02-20 Thread Peter Zijlstra

On Sat, Feb 20, 2021 at 06:41:01PM +0100, Borislav Petkov wrote:
> >  - I have more cases for objtool to rewrite code (I'll see if I can
> >rebase and post that this weekend -- no promises).
> 
> Oh noes.

11 patches and one beer later, it even boots :-)

Saves more than 6k on a defconfig build.

I'll push it out to git in a bit.

--- a/arch/x86/include/asm/jump_label.h
+++ b/arch/x86/include/asm/jump_label.h
@@ -4,12 +4,12 @@
 
 #define HAVE_JUMP_LABEL_BATCH
 
-#define JUMP_LABEL_NOP_SIZE 5
-
 #ifdef CONFIG_X86_64
-# define STATIC_KEY_INIT_NOP P6_NOP5_ATOMIC
+# define STATIC_KEY_NOP2 P6_NOP2
+# define STATIC_KEY_NOP5 P6_NOP5_ATOMIC
 #else
-# define STATIC_KEY_INIT_NOP GENERIC_NOP5_ATOMIC
+# define STATIC_KEY_NOP2 GENERIC_NOP2
+# define STATIC_KEY_NOP5 GENERIC_NOP5_ATOMIC
 #endif
 
 #include 
@@ -20,15 +20,35 @@
 #include 
 #include 
 
+#define JUMP_TABLE_ENTRY   \
+   ".pushsection __jump_table,  \"aw\" \n\t"   \
+   _ASM_ALIGN "\n\t"   \
+   ".long 1b - . \n\t" \
+   ".long %l[l_yes] - . \n\t"  \
+   _ASM_PTR "%c0 + %c1 - .\n\t"\
+   ".popsection \n\t"
+
+#ifdef CONFIG_STACK_VALIDATION
+
+static __always_inline bool arch_static_branch(struct static_key *key, bool 
branch)
+{
+   asm_volatile_goto("1:"
+   "jmp %l[l_yes] # objtool NOPs this \n\t"
+   JUMP_TABLE_ENTRY
+   : :  "i" (key), "i" (2 | branch) : : l_yes);
+
+   return false;
+l_yes:
+   return true;
+}
+
+#else
+
 static __always_inline bool arch_static_branch(struct static_key *key, bool 
branch)
 {
asm_volatile_goto("1:"
-   ".byte " __stringify(STATIC_KEY_INIT_NOP) "\n\t"
-   ".pushsection __jump_table,  \"aw\" \n\t"
-   _ASM_ALIGN "\n\t"
-   ".long 1b - ., %l[l_yes] - . \n\t"
-   _ASM_PTR "%c0 + %c1 - .\n\t"
-   ".popsection \n\t"
+   ".byte " __stringify(STATIC_KEY_NOP5) "\n\t"
+   JUMP_TABLE_ENTRY
: :  "i" (key), "i" (branch) : : l_yes);
 
return false;
@@ -36,16 +56,13 @@ static __always_inline bool arch_static_
return true;
 }
 
+#endif /* STACK_VALIDATION */
+
 static __always_inline bool arch_static_branch_jump(struct static_key *key, 
bool branch)
 {
asm_volatile_goto("1:"
-   ".byte 0xe9\n\t .long %l[l_yes] - 2f\n\t"
-   "2:\n\t"
-   ".pushsection __jump_table,  \"aw\" \n\t"
-   _ASM_ALIGN "\n\t"
-   ".long 1b - ., %l[l_yes] - . \n\t"
-   _ASM_PTR "%c0 + %c1 - .\n\t"
-   ".popsection \n\t"
+   "jmp %l[l_yes]\n\t"
+   JUMP_TABLE_ENTRY
: :  "i" (key), "i" (branch) : : l_yes);
 
return false;
@@ -53,41 +70,7 @@ static __always_inline bool arch_static_
return true;
 }
 
-#else  /* __ASSEMBLY__ */
-
-.macro STATIC_JUMP_IF_TRUE target, key, def
-.Lstatic_jump_\@:
-   .if \def
-   /* Equivalent to "jmp.d32 \target" */
-   .byte   0xe9
-   .long   \target - .Lstatic_jump_after_\@
-.Lstatic_jump_after_\@:
-   .else
-   .byte   STATIC_KEY_INIT_NOP
-   .endif
-   .pushsection __jump_table, "aw"
-   _ASM_ALIGN
-   .long   .Lstatic_jump_\@ - ., \target - .
-   _ASM_PTR\key - .
-   .popsection
-.endm
-
-.macro STATIC_JUMP_IF_FALSE target, key, def
-.Lstatic_jump_\@:
-   .if \def
-   .byte   STATIC_KEY_INIT_NOP
-   .else
-   /* Equivalent to "jmp.d32 \target" */
-   .byte   0xe9
-   .long   \target - .Lstatic_jump_after_\@
-.Lstatic_jump_after_\@:
-   .endif
-   .pushsection __jump_table, "aw"
-   _ASM_ALIGN
-   .long   .Lstatic_jump_\@ - ., \target - .
-   _ASM_PTR\key + 1 - .
-   .popsection
-.endm
+extern int arch_jump_entry_size(struct jump_entry *entry);
 
 #endif /* __ASSEMBLY__ */
 
--- a/arch/x86/include/asm/nops.h
+++ b/arch/x86/include/asm/nops.h
@@ -5,6 +5,7 @@
 /*
  * Define nops for use with alternative() and for tracing.
  *
+ * *_NOP2 must be a single instruction
  * *_NOP5_ATOMIC must be a single instruction.
  */
 
--- a/arch/x86/kernel/jump_label.c
+++ b/arch/x86/kernel/jump_label.c
@@ -16,53 +16,81 @@
 #include 
 #include 
 
-static void bug_at(const void *ip, int line)
+int arch_jump_entry_size(struct jump_entry *entry)
 {
-   /*
-* The location is not an op that we were expecting.
-* Something went wrong. Crash the box, as something could be
-* corrupting the kernel.
-*/
-   pr_crit("jump_label: Fatal kernel bug, unexpected op at %pS [%p] (%5ph) 
%d\n", ip, ip, ip, line);
-   BUG();
+   struct insn insn;
+
+   kernel_insn_init(, (void *)jump_entry_code(entry), MAX_INSN_SIZE);
+   insn_get_length();
+

2nd Info

2021-02-20 Thread admin

After several failed attempts,we are reaching you once again as regards the 
estate of Late George Brumley, you were made one of the beneficiaries of his 
estate. Do get back to me at your earliest convenience. The Trustees

Re: [PATCH v5 07/22] media: camss: Add support for VFE hardware version Titan 170

2021-02-20 Thread Andrey Konovalov


Hi Robert,

Thank you for your patch!

On 17.02.2021 14:21, Robert Foss wrote:

Add register definitions for version 170 of the Titan architecture
and implement support for the RDI output mode.

The RDI mode as opposed to the PIX output mode for the VFE unit does
not support any ISP functionality. This means essentially only
supporting dumping the output of the whatever the CSI decoder receives
from the sensor.

For example will a sensor outputting YUV pixel format frames, only
allow the VFE to dump those frames as they are received by the ISP
to memory through the RDI interface.

Signed-off-by: Robert Foss 
---


Changes since v1:
  - Andrey: Remove commented out chunk
  - Remove left over WIP comments

Changes since v4:
  - Andrey: Remove traces of PIX support
  - Andrey: Fix vfe_global_reset() overwriting reset command
  - Remove unused variable



  drivers/media/platform/qcom/camss/Makefile|   1 +
  .../media/platform/qcom/camss/camss-vfe-170.c | 790 ++
  drivers/media/platform/qcom/camss/camss-vfe.c |  47 +-
  drivers/media/platform/qcom/camss/camss-vfe.h |  26 +-
  .../media/platform/qcom/camss/camss-video.c   |  52 ++
  drivers/media/platform/qcom/camss/camss.c |  61 ++
  6 files changed, 957 insertions(+), 20 deletions(-)
  create mode 100644 drivers/media/platform/qcom/camss/camss-vfe-170.c

diff --git a/drivers/media/platform/qcom/camss/Makefile 
b/drivers/media/platform/qcom/camss/Makefile
index 940c0ae3e003..052c4f405fa3 100644
--- a/drivers/media/platform/qcom/camss/Makefile
+++ b/drivers/media/platform/qcom/camss/Makefile
@@ -11,6 +11,7 @@ qcom-camss-objs += \
camss-vfe-4-1.o \
camss-vfe-4-7.o \
camss-vfe-4-8.o \
+   camss-vfe-170.o \
camss-vfe-gen1.o \
camss-vfe.o \
camss-video.o \
diff --git a/drivers/media/platform/qcom/camss/camss-vfe-170.c 
b/drivers/media/platform/qcom/camss/camss-vfe-170.c
new file mode 100644
index ..c4991b1f22f8
--- /dev/null
+++ b/drivers/media/platform/qcom/camss/camss-vfe-170.c
@@ -0,0 +1,790 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * camss-vfe-4-7.c
+ *
+ * Qualcomm MSM Camera Subsystem - VFE (Video Front End) Module v4.7
+ *
+ * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2015-2018 Linaro Ltd.


- it looks like the header comes from v4.7 without updating to Titan 170


+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "camss.h"
+#include "camss-vfe.h"
+
+#define VFE_HW_VERSION (0x000)
+
+#define VFE_GLOBAL_RESET_CMD   (0x018)
+#defineGLOBAL_RESET_CMD_CORE   BIT(0)
+#defineGLOBAL_RESET_CMD_CAMIF  BIT(1)
+#defineGLOBAL_RESET_CMD_BUSBIT(2)
+#defineGLOBAL_RESET_CMD_BUS_BDGBIT(3)
+#defineGLOBAL_RESET_CMD_REGISTER   BIT(4)
+#defineGLOBAL_RESET_CMD_PM BIT(5)
+#defineGLOBAL_RESET_CMD_BUS_MISR   BIT(6)
+#defineGLOBAL_RESET_CMD_TESTGENBIT(7)
+#defineGLOBAL_RESET_CMD_DSPBIT(8)
+#defineGLOBAL_RESET_CMD_IDLE_CGC   BIT(9)
+#defineGLOBAL_RESET_CMD_RDI0   BIT(10)
+#defineGLOBAL_RESET_CMD_RDI1   BIT(11)
+#defineGLOBAL_RESET_CMD_RDI2   BIT(12)
+#defineGLOBAL_RESET_CMD_RDI3   BIT(13)
+#defineGLOBAL_RESET_CMD_VFE_DOMAIN BIT(30)
+#defineGLOBAL_RESET_CMD_RESET_BYPASS   BIT(31)
+
+
+#define VFE_CORE_CFG   (0x050)
+#defineCFG_PIXEL_PATTERN_YCBYCR(0x4)
+#defineCFG_PIXEL_PATTERN_YCRYCB(0x5)
+#defineCFG_PIXEL_PATTERN_CBYCRY(0x6)
+#defineCFG_PIXEL_PATTERN_CRYCBY(0x7)
+#defineCFG_COMPOSITE_REG_UPDATE_EN BIT(4)
+
+#define VFE_IRQ_CMD(0x058)
+#defineCMD_GLOBAL_CLEARBIT(0)
+
+#define VFE_IRQ_MASK_0 (0x05c)
+#defineMASK_0_CAMIF_SOFBIT(0)
+#defineMASK_0_CAMIF_EOFBIT(1)
+#defineMASK_0_RDI_REG_UPDATE(n)BIT((n) + 5)
+#defineMASK_0_IMAGE_MASTER_n_PING_PONG(n)  BIT((n) + 8)
+#defineMASK_0_IMAGE_COMPOSITE_DONE_n(n)BIT((n) + 25)
+#defineMASK_0_RESET_ACKBIT(31)
+
+#define VFE_IRQ_MASK_1 (0x060)
+#defineMASK_1_CAMIF_ERROR  BIT(0)
+#defineMASK_1_VIOLATIONBIT(7)
+#defineMASK_1_BUS_BDG_HALT_ACK BIT(8)
+#define

Re: [PATCH v5 07/22] media: camss: Add support for VFE hardware version Titan 170

2021-02-20 Thread Andrey Konovalov


Hi Robert,

Thank you for your patch!

On 17.02.2021 14:21, Robert Foss wrote:

Add register definitions for version 170 of the Titan architecture
and implement support for the RDI output mode.

The RDI mode as opposed to the PIX output mode for the VFE unit does
not support any ISP functionality. This means essentially only
supporting dumping the output of the whatever the CSI decoder receives
from the sensor.

For example will a sensor outputting YUV pixel format frames, only
allow the VFE to dump those frames as they are received by the ISP
to memory through the RDI interface.

Signed-off-by: Robert Foss 
---


Changes since v1:
  - Andrey: Remove commented out chunk
  - Remove left over WIP comments

Changes since v4:
  - Andrey: Remove traces of PIX support
  - Andrey: Fix vfe_global_reset() overwriting reset command
  - Remove unused variable



  drivers/media/platform/qcom/camss/Makefile|   1 +
  .../media/platform/qcom/camss/camss-vfe-170.c | 790 ++
  drivers/media/platform/qcom/camss/camss-vfe.c |  47 +-
  drivers/media/platform/qcom/camss/camss-vfe.h |  26 +-
  .../media/platform/qcom/camss/camss-video.c   |  52 ++
  drivers/media/platform/qcom/camss/camss.c |  61 ++
  6 files changed, 957 insertions(+), 20 deletions(-)
  create mode 100644 drivers/media/platform/qcom/camss/camss-vfe-170.c

diff --git a/drivers/media/platform/qcom/camss/Makefile 
b/drivers/media/platform/qcom/camss/Makefile
index 940c0ae3e003..052c4f405fa3 100644
--- a/drivers/media/platform/qcom/camss/Makefile
+++ b/drivers/media/platform/qcom/camss/Makefile
@@ -11,6 +11,7 @@ qcom-camss-objs += \
camss-vfe-4-1.o \
camss-vfe-4-7.o \
camss-vfe-4-8.o \
+   camss-vfe-170.o \
camss-vfe-gen1.o \
camss-vfe.o \
camss-video.o \
diff --git a/drivers/media/platform/qcom/camss/camss-vfe-170.c 
b/drivers/media/platform/qcom/camss/camss-vfe-170.c
new file mode 100644
index ..c4991b1f22f8
--- /dev/null
+++ b/drivers/media/platform/qcom/camss/camss-vfe-170.c
@@ -0,0 +1,790 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * camss-vfe-4-7.c
+ *
+ * Qualcomm MSM Camera Subsystem - VFE (Video Front End) Module v4.7
+ *
+ * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2015-2018 Linaro Ltd.


- it looks like the header comes from v4.7 without updating to Titan 170


+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "camss.h"
+#include "camss-vfe.h"
+
+#define VFE_HW_VERSION (0x000)
+
+#define VFE_GLOBAL_RESET_CMD   (0x018)
+#defineGLOBAL_RESET_CMD_CORE   BIT(0)
+#defineGLOBAL_RESET_CMD_CAMIF  BIT(1)
+#defineGLOBAL_RESET_CMD_BUSBIT(2)
+#defineGLOBAL_RESET_CMD_BUS_BDGBIT(3)
+#defineGLOBAL_RESET_CMD_REGISTER   BIT(4)
+#defineGLOBAL_RESET_CMD_PM BIT(5)
+#defineGLOBAL_RESET_CMD_BUS_MISR   BIT(6)
+#defineGLOBAL_RESET_CMD_TESTGENBIT(7)
+#defineGLOBAL_RESET_CMD_DSPBIT(8)
+#defineGLOBAL_RESET_CMD_IDLE_CGC   BIT(9)
+#defineGLOBAL_RESET_CMD_RDI0   BIT(10)
+#defineGLOBAL_RESET_CMD_RDI1   BIT(11)
+#defineGLOBAL_RESET_CMD_RDI2   BIT(12)
+#defineGLOBAL_RESET_CMD_RDI3   BIT(13)
+#defineGLOBAL_RESET_CMD_VFE_DOMAIN BIT(30)
+#defineGLOBAL_RESET_CMD_RESET_BYPASS   BIT(31)
+
+
+#define VFE_CORE_CFG   (0x050)
+#defineCFG_PIXEL_PATTERN_YCBYCR(0x4)
+#defineCFG_PIXEL_PATTERN_YCRYCB(0x5)
+#defineCFG_PIXEL_PATTERN_CBYCRY(0x6)
+#defineCFG_PIXEL_PATTERN_CRYCBY(0x7)
+#defineCFG_COMPOSITE_REG_UPDATE_EN BIT(4)
+
+#define VFE_IRQ_CMD(0x058)
+#defineCMD_GLOBAL_CLEARBIT(0)
+
+#define VFE_IRQ_MASK_0 (0x05c)
+#defineMASK_0_CAMIF_SOFBIT(0)
+#defineMASK_0_CAMIF_EOFBIT(1)
+#defineMASK_0_RDI_REG_UPDATE(n)BIT((n) + 5)
+#defineMASK_0_IMAGE_MASTER_n_PING_PONG(n)  BIT((n) + 8)
+#defineMASK_0_IMAGE_COMPOSITE_DONE_n(n)BIT((n) + 25)
+#defineMASK_0_RESET_ACKBIT(31)
+
+#define VFE_IRQ_MASK_1 (0x060)
+#defineMASK_1_CAMIF_ERROR  BIT(0)
+#defineMASK_1_VIOLATIONBIT(7)
+#defineMASK_1_BUS_BDG_HALT_ACK BIT(8)
+#define

Re: [PATCH 1/8] af_unix: take address assignment/hash insertion into a new helper

On Sat, Feb 20, 2021 at 12:31:49PM -0800, Cong Wang wrote:
> Because it does not lock the lock, just compare:
> 
> lock();
> __unix_set_addr();
> unlock();
> 
> to:
> 
> lock();
> __unix_set_addr();
> 
> Clearly the former is more readable and less error-prone. Even
> if you really want to do unlock, pick a name which explicitly says
> it, for example, __unix_set_addr_unlock().

*shrug*

If anything, __unix_complete_bind() might make a better name for that,
with dropping ->bindlock also pulled in, but TBH I don't have sufficiently
strong preferences - might as well leave dropping the lock to caller.

I'll post that series to netdev tonight.

INFO: rcu detected stall in __hrtimer_run_queues

2021-02-20 Thread syzbot

Hello,

syzbot found the following issue on:

HEAD commit:f40ddce8 Linux 5.11
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1397f498d0
kernel config:  https://syzkaller.appspot.com/x/.config?x=e53d04227c52a0df
dashboard link: https://syzkaller.appspot.com/bug?extid=de9526ade17c659d8336
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=17a81012d0
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1282b6d2d0

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+de9526ade17c659d8...@syzkaller.appspotmail.com

rcu: INFO: rcu_preempt self-detected stall on CPU
rcu:1-: (10153 ticks this GP) idle=f1a/1/0x4000 
softirq=10867/10868 fqs=925 
(t=10502 jiffies g=10029 q=19103)
NMI backtrace for cpu 1
CPU: 1 PID: 10530 Comm: syz-executor248 Not tainted 5.11.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 
 __dump_stack lib/dump_stack.c:79 [inline]
 dump_stack+0x107/0x163 lib/dump_stack.c:120
 nmi_cpu_backtrace.cold+0x44/0xd7 lib/nmi_backtrace.c:105
 nmi_trigger_cpumask_backtrace+0x1b3/0x230 lib/nmi_backtrace.c:62
 trigger_single_cpu_backtrace include/linux/nmi.h:164 [inline]
 rcu_dump_cpu_stacks+0x1f4/0x230 kernel/rcu/tree_stall.h:337
 print_cpu_stall kernel/rcu/tree_stall.h:569 [inline]
 check_cpu_stall kernel/rcu/tree_stall.h:643 [inline]
 rcu_pending kernel/rcu/tree.c:3751 [inline]
 rcu_sched_clock_irq.cold+0x48e/0xedf kernel/rcu/tree.c:2580
 update_process_times+0x16d/0x200 kernel/time/timer.c:1782
 tick_sched_handle+0x9b/0x180 kernel/time/tick-sched.c:226
 tick_sched_timer+0x1b0/0x2d0 kernel/time/tick-sched.c:1369
 __run_hrtimer kernel/time/hrtimer.c:1519 [inline]
 __hrtimer_run_queues+0x1c0/0xe40 kernel/time/hrtimer.c:1583
 hrtimer_interrupt+0x334/0x940 kernel/time/hrtimer.c:1645
 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1089 [inline]
 __sysvec_apic_timer_interrupt+0x146/0x540 arch/x86/kernel/apic/apic.c:1106
 run_sysvec_on_irqstack_cond arch/x86/include/asm/irq_stack.h:91 [inline]
 sysvec_apic_timer_interrupt+0x48/0x100 arch/x86/kernel/apic/apic.c:1100
 asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:629
RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:161 
[inline]
RIP: 0010:_raw_spin_unlock_irqrestore+0x25/0x50 kernel/locking/spinlock.c:191
Code: f8 5d c3 66 90 55 48 89 fd 48 83 c7 18 53 48 89 f3 48 8b 74 24 10 e8 9a 
d6 5b f8 48 89 ef e8 42 8b 5c f8 f6 c7 02 75 1a 53 9d  01 00 00 00 e8 81 92 
50 f8 65 8b 05 7a f8 04 77 85 c0 74 0a 5b
RSP: 0018:c9db0e48 EFLAGS: 0286
RAX: 00ce281a RBX: 0286 RCX: 11b46a19
RDX:  RSI: 0102 RDI: 
RBP: 8880b9d26a00 R08: 0001 R09: 0001
R10: 8178a8b8 R11:  R12: 00a80fcc296a
R13: 8880b9d26c80 R14: 8880b9d26a00 R15: 851589e0
 __run_hrtimer kernel/time/hrtimer.c:1515 [inline]
 __hrtimer_run_queues+0x51a/0xe40 kernel/time/hrtimer.c:1583
 hrtimer_run_softirq+0x17b/0x360 kernel/time/hrtimer.c:1600
 __do_softirq+0x29b/0x9f6 kernel/softirq.c:343
 asm_call_irq_on_stack+0xf/0x20
 
 __run_on_irqstack arch/x86/include/asm/irq_stack.h:26 [inline]
 run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:77 [inline]
 do_softirq_own_stack+0xaa/0xd0 arch/x86/kernel/irq_64.c:77
 invoke_softirq kernel/softirq.c:226 [inline]
 __irq_exit_rcu kernel/softirq.c:420 [inline]
 irq_exit_rcu+0x134/0x200 kernel/softirq.c:432
 sysvec_apic_timer_interrupt+0x4d/0x100 arch/x86/kernel/apic/apic.c:1100
 asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:629
RIP: 0010:queue_work_on+0x83/0xd0 kernel/workqueue.c:1530
Code: 31 ff 89 ee e8 6e 02 29 00 40 84 ed 74 46 e8 e4 fb 28 00 31 ff 48 89 de 
e8 ca 03 29 00 48 85 db 75 26 e8 d0 fb 28 00 41 56 9d <48> 83 c4 08 44 89 f8 5b 
5d 41 5c 41 5d 41 5e 41 5f c3 e8 b6 fb 28
RSP: 0018:c90002e5fc80 EFLAGS: 0293
RAX:  RBX: 0200 RCX: 
RDX: 8880265f5340 RSI: 8149da20 RDI: 
RBP: c90002e68000 R08: 0001 R09: 0001
R10: 8178a8b8 R11:  R12: 8880b9d31568
R13: 888010c64c00 R14: 0293 R15: 0001
 queue_work include/linux/workqueue.h:507 [inline]
 schedule_work include/linux/workqueue.h:568 [inline]
 __vfree_deferred mm/vmalloc.c:2307 [inline]
 vfree_atomic+0xac/0xe0 mm/vmalloc.c:2325
 free_thread_stack kernel/fork.c:291 [inline]
 release_task_stack kernel/fork.c:428 [inline]
 put_task_stack+0x29c/0x480 kernel/fork.c:439
 finish_task_switch.isra.0+0x557/0x7e0 kernel/sched/core.c:4236
 context_switch kernel/sched/core.c:4330 [inline]
 __schedule+0x914/0x21a0 kernel/sched/core.c:5078
 preempt_schedule_common+0x45/0xc0 kernel/sched/core.c:5238
 preempt_schedule_thunk+0x16/0x18

Re: [PATCH v3 8/8] xen/evtchn: use READ/WRITE_ONCE() for accessing ring indices

2021-02-20 Thread Boris Ostrovsky



On 2/19/21 10:40 AM, Juergen Gross wrote:
> For avoiding read- and write-tearing by the compiler use READ_ONCE()
> and WRITE_ONCE() for accessing the ring indices in evtchn.c.
>
> Signed-off-by: Juergen Gross 


Reviewed-by: Boris Ostrovsky

Re: NFS Caching broken in 4.19.37

2021-02-20 Thread Anton Ivanov

On 20/02/2021 20:04, Salvatore Bonaccorso wrote:

Hi,

On Mon, Jul 08, 2019 at 07:19:54PM +0100, Anton Ivanov wrote:

Hi list,

NFS caching appears broken in 4.19.37.

The more cores/threads the easier to reproduce. Tested with identical
results on Ryzen 1600 and 1600X.

1. Mount an openwrt build tree over NFS v4
2. Run make -j `cat /proc/cpuinfo | grep vendor | wc -l` ; make clean in a
loop
3. Result after 3-4 iterations:

State on the client

ls -laF
/var/autofs/local/src/openwrt/build_dir/target-mips_24kc_musl/linux-ar71xx_tiny/linux-4.14.125/arch/mips/include/generated/uapi/asm

total 8
drwxr-xr-x 2 anivanov anivanov 4096 Jul 8 11:40 ./
drwxr-xr-x 3 anivanov anivanov 4096 Jul 8 11:40 ../

State as seen on the server (mounted via nfs from localhost):

ls -laF
/var/autofs/local/src/openwrt/build_dir/target-mips_24kc_musl/linux-ar71xx_tiny/linux-4.14.125/arch/mips/include/generated/uapi/asm
total 12
drwxr-xr-x 2 anivanov anivanov 4096 Jul 8 11:40 ./
drwxr-xr-x 3 anivanov anivanov 4096 Jul 8 11:40 ../
-rw-r--r-- 1 anivanov anivanov 32 Jul 8 11:40 ipcbuf.h

Actual state on the filesystem:

ls -laF
/exports/work/src/openwrt/build_dir/target-mips_24kc_musl/linux-ar71xx_tiny/linux-4.14.125/arch/mips/include/generated/uapi/asm
total 12
drwxr-xr-x 2 anivanov anivanov 4096 Jul 8 11:40 ./
drwxr-xr-x 3 anivanov anivanov 4096 Jul 8 11:40 ../
-rw-r--r-- 1 anivanov anivanov 32 Jul 8 11:40 ipcbuf.h

So the client has quite clearly lost the plot. Telling it to drop caches and
re-reading the directory shows the file present.

It is possible to reproduce this using a linux kernel tree too, just takes
much more iterations - 10+ at least.

Both client and server run 4.19.37 from Debian buster. This is filed as
debian bug 931500. I originally thought it to be autofs related, but IMHO it
is actually something fundamentally broken in nfs caching resulting in cache
corruption.

According to the reporter downstream in Debian, at
https://bugs.debian.org/940821#26 thi seem still reproducible with
more recent kernels than the initial reported. Is there anything Anton
can provide to try to track down the issue?

Anton, can you reproduce with current stable series?

100% reproducible with any kernel from 4.9 to 5.4, stable or backports.
It may exist in earlier versions, but I do not have a machine with
anything before 4.9 to test at present.

From 1-2 make clean && make cycles to one afternoon depending on the
number of machine cores. More cores/threads the faster it does it.

I tried playing with protocol minor versions, caching options, etc - it
is still reproducible for any nfs4 settings as long as there is client
side caching of metadata.

Regards,
Salvatore

--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/

Re: [PATCH 1/8] af_unix: take address assignment/hash insertion into a new helper

2021-02-20 Thread Cong Wang

On Sat, Feb 20, 2021 at 11:32 AM Al Viro  wrote:
>
> On Sat, Feb 20, 2021 at 11:12:33AM -0800, Cong Wang wrote:
> > On Thu, Feb 18, 2021 at 8:22 PM Al Viro  wrote:
> > >
> > > Duplicated logics in all bind variants (autobind, bind-to-path,
> > > bind-to-abstract) gets taken into a common helper.
> > >
> > > Signed-off-by: Al Viro 
> > > ---
> > >  net/unix/af_unix.c | 30 +++---
> > >  1 file changed, 15 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
> > > index 41c3303c3357..179b4fe837e6 100644
> > > --- a/net/unix/af_unix.c
> > > +++ b/net/unix/af_unix.c
> > > @@ -262,6 +262,16 @@ static void __unix_insert_socket(struct hlist_head 
> > > *list, struct sock *sk)
> > > sk_add_node(sk, list);
> > >  }
> > >
> > > +static void __unix_set_addr(struct sock *sk, struct unix_address *addr,
> > > +   unsigned hash)
> > > +   __releases(_table_lock)
> > > +{
> > > +   __unix_remove_socket(sk);
> > > +   smp_store_release(_sk(sk)->addr, addr);
> > > +   __unix_insert_socket(_socket_table[hash], sk);
> > > +   spin_unlock(_table_lock);
> >
> > Please take the unlock out, it is clearly an anti-pattern.
>
> Why?  "Insert into locked and unlock" is fairly common...

Because it does not lock the lock, just compare:

lock();
__unix_set_addr();
unlock();

to:

lock();
__unix_set_addr();

Clearly the former is more readable and less error-prone. Even
if you really want to do unlock, pick a name which explicitly says
it, for example, __unix_set_addr_unlock().

Thanks.

[PATCH v8 3/3] docs/pinctrl: document debugfs files

Document debugfs directories and files created for pinctrl subsystem.

Suggested-by: Andy Shevchenko 
Reviewed-by: Andy Shevchenko 
Reviewed-by: Tony Lindgren 
Signed-off-by: Drew Fustini 
---
 Documentation/driver-api/pinctl.rst | 37 +
 1 file changed, 37 insertions(+)

diff --git a/Documentation/driver-api/pinctl.rst 
b/Documentation/driver-api/pinctl.rst
index 3d2deaf48841..c905b273e833 100644
--- a/Documentation/driver-api/pinctl.rst
+++ b/Documentation/driver-api/pinctl.rst
@@ -1428,3 +1428,40 @@ on the pins defined by group B::
 The above has to be done from process context. The reservation of the pins
 will be done when the state is activated, so in effect one specific pin
 can be used by different functions at different times on a running system.
+
+
+Debugfs files
+=
+These files are created in ``/sys/kernel/debug/pinctrl``:
+
+- ``pinctrl-devices``: prints each pin controller device along with columns to
+  indicate support for pinmux and pinconf
+
+- ``pinctrl-handles``: prints each configured pin controller handle and the
+  corresponding pinmux maps
+
+- ``pinctrl-maps``: print all pinctrl maps
+
+A sub-directory is created inside of ``/sys/kernel/debug/pinctrl`` for each pin
+controller device containing these files:
+
+- ``pins``: prints a line for each pin registered on the pin controller. The
+  pinctrl driver may add additional information such as register contents.
+
+- ``gpio-ranges``: print ranges that map gpio lines to pins on the controller
+
+- ``pingroups``: print all pin groups registered on the pin controller
+
+- ``pinconf-pins``: print pin config settings for each pin
+
+- ``pinconf-groups``: print pin config settings per pin group
+
+- ``pinmux-functions``: print each pin function along with the pin groups that
+  map to the pin function
+
+- ``pinmux-pins``: iterate through all pins and print mux owner, gpio owner
+  and if the pin is a hog
+
+- ``pinmux-select``: write to this file to activate a pin function for a 
group::
+
+echo "" > pinmux-select
-- 
2.25.1

[PATCH v8 2/3] pinctrl: pinmux: Add pinmux-select debugfs file

Add "pinmux-select" to debugfs which will activate a pin function for a
given pin group:

  echo "" > pinmux-select

The write operation pinmux_select() handles this by checking that the
names map to valid selectors and then calling ops->set_mux().

The existing "pinmux-functions" debugfs file lists the pin functions
registered for the pin controller. For example:

  function: pinmux-uart0, groups = [ pinmux-uart0-pins ]
  function: pinmux-mmc0, groups = [ pinmux-mmc0-pins ]
  function: pinmux-mmc1, groups = [ pinmux-mmc1-pins ]
  function: pinmux-i2c0, groups = [ pinmux-i2c0-pins ]
  function: pinmux-i2c1, groups = [ pinmux-i2c1-pins ]
  function: pinmux-spi1, groups = [ pinmux-spi1-pins ]

To activate function pinmux-i2c1 on group pinmux-i2c1-pins:

  echo "pinmux-i2c1-pins pinmux-i2c1" > pinmux-select

Reviewed-by: Andy Shevchenko 
Reviewed-by: Tony Lindgren 
Reviewed-by: Geert Uytterhoeven 
Tested-by: Geert Uytterhoeven 
Signed-off-by: Drew Fustini 
---
 drivers/pinctrl/pinmux.c | 102 +++
 1 file changed, 102 insertions(+)

diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
index c651b2db0925..f4abfaecfc5c 100644
--- a/drivers/pinctrl/pinmux.c
+++ b/drivers/pinctrl/pinmux.c
@@ -12,6 +12,7 @@
  */
 #define pr_fmt(fmt) "pinmux core: " fmt
 
+#include 
 #include 
 #include 
 #include 
@@ -673,6 +674,105 @@ void pinmux_show_setting(struct seq_file *s,
 DEFINE_SHOW_ATTRIBUTE(pinmux_functions);
 DEFINE_SHOW_ATTRIBUTE(pinmux_pins);
 
+#define PINMUX_SELECT_MAX 128
+static ssize_t pinmux_select(struct file *file, const char __user *user_buf,
+  size_t len, loff_t *ppos)
+{
+   struct seq_file *sfile = file->private_data;
+   struct pinctrl_dev *pctldev = sfile->private;
+   const struct pinmux_ops *pmxops = pctldev->desc->pmxops;
+   const char *const *groups;
+   char *buf, *gname, *fname;
+   unsigned int num_groups;
+   int fsel, gsel, ret;
+
+   if (len > PINMUX_SELECT_MAX)
+   return -ENOMEM;
+
+   buf = kzalloc(PINMUX_SELECT_MAX, GFP_KERNEL);
+   if (!buf)
+   return -ENOMEM;
+
+   ret = strncpy_from_user(buf, user_buf, PINMUX_SELECT_MAX);
+   if (ret < 0)
+   goto exit_free_buf;
+   buf[len-1] = '\0';
+
+   /* remove leading and trailing spaces of input buffer */
+   gname = strstrip(buf);
+   if (*gname == '\0') {
+   ret = -EINVAL;
+   goto exit_free_buf;
+   }
+
+   /* find a separator which is a spacelike character */
+   for (fname = gname; !isspace(*fname); fname++) {
+   if (*fname == '\0') {
+   ret = -EINVAL;
+   goto exit_free_buf;
+   }
+   }
+   *fname = '\0';
+
+   /* drop extra spaces between function and group names */
+   fname = skip_spaces(fname + 1);
+   if (*fname == '\0') {
+   ret = -EINVAL;
+   goto exit_free_buf;
+   }
+
+   ret = pinmux_func_name_to_selector(pctldev, fname);
+   if (ret < 0) {
+   dev_err(pctldev->dev, "invalid function %s in map table\n", 
fname);
+   goto exit_free_buf;
+   }
+   fsel = ret;
+
+   ret = pmxops->get_function_groups(pctldev, fsel, , _groups);
+   if (ret) {
+   dev_err(pctldev->dev, "no groups for function %d (%s)", fsel, 
fname);
+   goto exit_free_buf;
+   }
+
+   ret = match_string(groups, num_groups, gname);
+   if (ret < 0) {
+   dev_err(pctldev->dev, "invalid group %s", gname);
+   goto exit_free_buf;
+   }
+
+   ret = pinctrl_get_group_selector(pctldev, gname);
+   if (ret < 0) {
+   dev_err(pctldev->dev, "failed to get group selector for %s", 
gname);
+   goto exit_free_buf;
+   }
+   gsel = ret;
+
+   ret = pmxops->set_mux(pctldev, fsel, gsel);
+   if (ret) {
+   dev_err(pctldev->dev, "set_mux() failed: %d", ret);
+   goto exit_free_buf;
+   }
+   ret = len;
+
+exit_free_buf:
+   kfree(buf);
+
+   return ret;
+}
+
+static int pinmux_select_open(struct inode *inode, struct file *file)
+{
+   return single_open(file, NULL, inode->i_private);
+}
+
+static const struct file_operations pinmux_select_ops = {
+   .owner = THIS_MODULE,
+   .open = pinmux_select_open,
+   .write = pinmux_select,
+   .llseek = no_llseek,
+   .release = single_release,
+};
+
 void pinmux_init_device_debugfs(struct dentry *devroot,
 struct pinctrl_dev *pctldev)
 {
@@ -680,6 +780,8 @@ void pinmux_init_device_debugfs(struct dentry *devroot,
devroot, pctldev, _functions_fops);
debugfs_create_file("pinmux-pins", 0444,
devroot, pctldev, _pins_fops);
+   debugfs_create_file("pinmux-select", 0200,
+   devroot,

[PATCH v8 1/3] pinctrl: use to octal permissions for debugfs files

Switch over pinctrl debugfs files to use octal permissions as they are
preferred over symbolic permissions. Refer to commit f90774e1fd27
("checkpatch: look for symbolic permissions and suggest octal instead").

Note: S_IFREG flag is added to the mode by __debugfs_create_file()
in fs/debugfs/inode.c

Suggested-by: Joe Perches 
Suggested-by: Andy Shevchenko 
Reviewed-by: Andy Shevchenko 
Reviewed-by: Geert Uytterhoeven 
Reviewed-by: Tony Lindgren 
Signed-off-by: Drew Fustini 
---
 drivers/pinctrl/core.c| 12 ++--
 drivers/pinctrl/pinconf.c |  4 ++--
 drivers/pinctrl/pinmux.c  |  4 ++--
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 3663d87f51a0..07458742bc0f 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -1888,11 +1888,11 @@ static void pinctrl_init_device_debugfs(struct 
pinctrl_dev *pctldev)
dev_name(pctldev->dev));
return;
}
-   debugfs_create_file("pins", S_IFREG | S_IRUGO,
+   debugfs_create_file("pins", 0444,
device_root, pctldev, _pins_fops);
-   debugfs_create_file("pingroups", S_IFREG | S_IRUGO,
+   debugfs_create_file("pingroups", 0444,
device_root, pctldev, _groups_fops);
-   debugfs_create_file("gpio-ranges", S_IFREG | S_IRUGO,
+   debugfs_create_file("gpio-ranges", 0444,
device_root, pctldev, _gpioranges_fops);
if (pctldev->desc->pmxops)
pinmux_init_device_debugfs(device_root, pctldev);
@@ -1914,11 +1914,11 @@ static void pinctrl_init_debugfs(void)
return;
}
 
-   debugfs_create_file("pinctrl-devices", S_IFREG | S_IRUGO,
+   debugfs_create_file("pinctrl-devices", 0444,
debugfs_root, NULL, _devices_fops);
-   debugfs_create_file("pinctrl-maps", S_IFREG | S_IRUGO,
+   debugfs_create_file("pinctrl-maps", 0444,
debugfs_root, NULL, _maps_fops);
-   debugfs_create_file("pinctrl-handles", S_IFREG | S_IRUGO,
+   debugfs_create_file("pinctrl-handles", 0444,
debugfs_root, NULL, _fops);
 }
 
diff --git a/drivers/pinctrl/pinconf.c b/drivers/pinctrl/pinconf.c
index 02c075cc010b..d9d54065472e 100644
--- a/drivers/pinctrl/pinconf.c
+++ b/drivers/pinctrl/pinconf.c
@@ -370,9 +370,9 @@ DEFINE_SHOW_ATTRIBUTE(pinconf_groups);
 void pinconf_init_device_debugfs(struct dentry *devroot,
 struct pinctrl_dev *pctldev)
 {
-   debugfs_create_file("pinconf-pins", S_IFREG | S_IRUGO,
+   debugfs_create_file("pinconf-pins", 0444,
devroot, pctldev, _pins_fops);
-   debugfs_create_file("pinconf-groups", S_IFREG | S_IRUGO,
+   debugfs_create_file("pinconf-groups", 0444,
devroot, pctldev, _groups_fops);
 }
 
diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
index bab888fe3f8e..c651b2db0925 100644
--- a/drivers/pinctrl/pinmux.c
+++ b/drivers/pinctrl/pinmux.c
@@ -676,9 +676,9 @@ DEFINE_SHOW_ATTRIBUTE(pinmux_pins);
 void pinmux_init_device_debugfs(struct dentry *devroot,
 struct pinctrl_dev *pctldev)
 {
-   debugfs_create_file("pinmux-functions", S_IFREG | S_IRUGO,
+   debugfs_create_file("pinmux-functions", 0444,
devroot, pctldev, _functions_fops);
-   debugfs_create_file("pinmux-pins", S_IFREG | S_IRUGO,
+   debugfs_create_file("pinmux-pins", 0444,
devroot, pctldev, _pins_fops);
 }
 
-- 
2.25.1

[PATCH v8 0/3] pinctrl: pinmux: Add pinmux-select debugfs file

This series first converts the debugfs files in the pinctrl subsystem to
octal permissions and then adds a new debugfs file "pinmux-select".

Group name and function name can be written to "pinmux-select" which
will cause the pin function for the specified group to be activated on
the pin controller.

The final patch in this series documents the debugfs files for pinctrl.

Notes for PATCH v8:
- add 'Reviewed-by:' from Geert Uytterhoeven for pinmux-select patch
- add 'Tested-by:' from Geert Uytterhoeven for pinmux-select patch
- change pinmux-select format to '' based on
  feedback from Geert
- rephrase parts of documentation per Geert's comments

Notes for PATCH v7:
- add 'Reviewed-by:' from Andy Shevchenko for pinmux-select patch
- add 'Reviewed-by:' from Andy Shevchenko for documentation patch
- add 'Reviewed-by:' from Tony Lindgren to all patches
- change order of '#include ' per Andy's suggestion
- change PINMUX_SELECT_MAX back to 128 as I had accidentally changed it
  to 50 and Andy pointed this out.
- grammer fixes as suggested by Andy
- rework assignment of fsel and ret from pinmux_func_name_to_selector()
- rework assignment of gsel and ret from pinctrl_get_group_selector()

Notes for PATCH v6:
- add 'Suggested-by:' for Joe Perches to octal permissions patch
- add 'Reviewed-by:' from Andy and Geert to octal permissions patch
- reword example in the pinmux-select patch per Andy's advice
- indent the example output per Andy's advice
- remove usage error messages as Andy advised it is too verbose
- return -ENOMEM when write is too big for the input buffer per Andy's advice
- handle whitespace before, in between, and after the function name and
  group name as suggested by Andy
- rename free_buf to exit_free_buf per Andy's advice
- add documentation patch to series which documents the debugfs files
  for the pinctrl subsystem including the new pinmux-select file

Notes for PATCH v5:
- convert permissions from symbolic to octal for debugfs_create_file()
  calls in core.c that Joe Perches pointed out I had missed
- Linus W: please let me know if I should break this series apart as you
  already applied an earlier version of octal conversion patch today [1]
- switch from sscanf() to just pointing to function name and group name
  inside of the buffer. This also avoids having to allocate additional
  buffers for fname and gname. Geert and Andy highlighted this security
  issue and Andy suggested code to use instead of sscanf().
- switch from devm_kfree() to kfree() after Dan Carpenter warned me
- remove .read from pinmux_select_ops per Geert since it is write only
- add usage format to error when unable find fname or gname in buffer

Notes for PATCH v4:
- correct the commit message in the second patch to reference function
  and group name instead of integer selectors. Apologies for not fixing
  that in v3
- fix typos in cover letter

Notes for PATCH v3:
- add Suggested-by: Andy Shevchenko to the "pinctrl: use to octal
  permissions for debugfs files" patch
- change the octal permissions from 0400 to 0444 to correctly match the
  symbolic permissions (thanks to Joe Perches and Geert Uytterhoeven)
- note that S_IFREG flag is added to the mode in __debugfs_create_file()
  (thanks to Andy for highlighting this and Joe for suggesting I should
  add a note to the commit message)
- fix order of the goto labels so that the buffers are freed correctly
  as suggested by Dan Carpenter
- move from devm_kzalloc() to kzalloc() as the buffers are only used
  inside the pinmux_select() function and not related to the lifetime
  of the pin controller device (thanks to Andy for pointing this out)
- correct the pinmux-select example in commit message to use the
  function and group name instead of selector (thanks to Geert)

Notes for PATCH v2:
- create patch series that includes patch to switch all the debugfs
  files in pinctrl subsystem over to octal permission
- write function name and group name, instead of error-prone selector
  numbers, to the 'pinmux-select' file
- switch from static to dynamic allocation for the kernel buffer filled
  by strncpy_from_user()
- look up function selector from function name using
  pinmux_func_name_to_selector()
- validate group name with get_function_groups() and match_string()
- look up selector for group name with pinctrl_get_group_selector()

Notes for PATCH v1:
- posted seperate patch to switch all the debugfs files in pinctrl
  subsystem over to octal permission
- there is no existing documentation for any of the debugfs enteries for
  pinctrl, so it seemed to have a bigger scope than just this patch. I
  also noticed that rst documentation is confusingly named "pinctl" (no
  'r') and started thread about that [2]. Linus suggested chaning that
  to 'pin-control'. Thus I am planning a seperate documentation patch
  series where the file is renamed, references changed and a section on
  the pinctrl debugfs files is added.

Notes for RFC v2 [3]:
- rename debugfs file "pinmux-set" to

Re: NFS Caching broken in 4.19.37

2021-02-20 Thread Chuck Lever




> On Feb 20, 2021, at 3:13 PM, Anton Ivanov  
> wrote:
> 
> On 20/02/2021 20:04, Salvatore Bonaccorso wrote:
>> Hi,
>> 
>> On Mon, Jul 08, 2019 at 07:19:54PM +0100, Anton Ivanov wrote:
>>> Hi list,
>>> 
>>> NFS caching appears broken in 4.19.37.
>>> 
>>> The more cores/threads the easier to reproduce. Tested with identical
>>> results on Ryzen 1600 and 1600X.
>>> 
>>> 1. Mount an openwrt build tree over NFS v4
>>> 2. Run make -j `cat /proc/cpuinfo | grep vendor | wc -l` ; make clean in a
>>> loop
>>> 3. Result after 3-4 iterations:
>>> 
>>> State on the client
>>> 
>>> ls -laF 
>>> /var/autofs/local/src/openwrt/build_dir/target-mips_24kc_musl/linux-ar71xx_tiny/linux-4.14.125/arch/mips/include/generated/uapi/asm
>>> 
>>> total 8
>>> drwxr-xr-x 2 anivanov anivanov 4096 Jul  8 11:40 ./
>>> drwxr-xr-x 3 anivanov anivanov 4096 Jul  8 11:40 ../
>>> 
>>> State as seen on the server (mounted via nfs from localhost):
>>> 
>>> ls -laF 
>>> /var/autofs/local/src/openwrt/build_dir/target-mips_24kc_musl/linux-ar71xx_tiny/linux-4.14.125/arch/mips/include/generated/uapi/asm
>>> total 12
>>> drwxr-xr-x 2 anivanov anivanov 4096 Jul  8 11:40 ./
>>> drwxr-xr-x 3 anivanov anivanov 4096 Jul  8 11:40 ../
>>> -rw-r--r-- 1 anivanov anivanov   32 Jul  8 11:40 ipcbuf.h
>>> 
>>> Actual state on the filesystem:
>>> 
>>> ls -laF 
>>> /exports/work/src/openwrt/build_dir/target-mips_24kc_musl/linux-ar71xx_tiny/linux-4.14.125/arch/mips/include/generated/uapi/asm
>>> total 12
>>> drwxr-xr-x 2 anivanov anivanov 4096 Jul  8 11:40 ./
>>> drwxr-xr-x 3 anivanov anivanov 4096 Jul  8 11:40 ../
>>> -rw-r--r-- 1 anivanov anivanov   32 Jul  8 11:40 ipcbuf.h
>>> 
>>> So the client has quite clearly lost the plot. Telling it to drop caches and
>>> re-reading the directory shows the file present.
>>> 
>>> It is possible to reproduce this using a linux kernel tree too, just takes
>>> much more iterations - 10+ at least.
>>> 
>>> Both client and server run 4.19.37 from Debian buster. This is filed as
>>> debian bug 931500. I originally thought it to be autofs related, but IMHO it
>>> is actually something fundamentally broken in nfs caching resulting in cache
>>> corruption.
>> According to the reporter downstream in Debian, at
>> https://bugs.debian.org/940821#26 thi seem still reproducible with
>> more recent kernels than the initial reported. Is there anything Anton
>> can provide to try to track down the issue?
>> 
>> Anton, can you reproduce with current stable series?
> 
> 100% reproducible with any kernel from 4.9 to 5.4, stable or backports. It 
> may exist in earlier versions, but I do not have a machine with anything 
> before 4.9 to test at present.

Confirming you are varying client-side kernels. Should the Linux
NFS client maintainers be Cc'd?


> From 1-2 make clean && make  cycles to one afternoon depending on the number 
> of machine cores. More cores/threads the faster it does it.
> 
> I tried playing with protocol minor versions, caching options, etc - it is 
> still reproducible for any nfs4 settings as long as there is client side 
> caching of metadata.
> 
> A.
> 
>> 
>> Regards,
>> Salvatore
>> 
> 
> -- 
> Anton R. Ivanov
> Cambridgegreys Limited. Registered in England. Company Number 10273661
> https://www.cambridgegreys.com/

--
Chuck Lever

Re: [PATCH v4] arm: OABI compat: fix build when EPOLL is not enabled

2021-02-20 Thread Russell King - ARM Linux admin

On Sat, Feb 20, 2021 at 10:47:48AM -0800, Randy Dunlap wrote:
> ---
> KernelVersion: v5.11
> I don't know what format is used for KernelVersion.
> This patch applies to any Linux kernel v5.x and probably even older.

I normally ask for it to be the kernel version (without git) that the
patch was generated against, so if there's problems applying it, I
can try a bit harder to apply it (such as checking out that version
and applying it there, and then merging the result.)

It's original purpose was when I was maintaining the 2.4 and 2.5/2.6
kernel trees at the same time - it was critical to know which tree
people wanted their patch applied to.

Note that the patch system email parser can cope with the tag
appearing almost anywhere in the email - either the message header
or the body of the email, except intermingling with the patch itself.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: NFS Caching broken in 4.19.37

2021-02-20 Thread Salvatore Bonaccorso

Hi,

On Mon, Jul 08, 2019 at 07:19:54PM +0100, Anton Ivanov wrote:
> Hi list,
> 
> NFS caching appears broken in 4.19.37.
> 
> The more cores/threads the easier to reproduce. Tested with identical
> results on Ryzen 1600 and 1600X.
> 
> 1. Mount an openwrt build tree over NFS v4
> 2. Run make -j `cat /proc/cpuinfo | grep vendor | wc -l` ; make clean in a
> loop
> 3. Result after 3-4 iterations:
> 
> State on the client
> 
> ls -laF 
> /var/autofs/local/src/openwrt/build_dir/target-mips_24kc_musl/linux-ar71xx_tiny/linux-4.14.125/arch/mips/include/generated/uapi/asm
> 
> total 8
> drwxr-xr-x 2 anivanov anivanov 4096 Jul  8 11:40 ./
> drwxr-xr-x 3 anivanov anivanov 4096 Jul  8 11:40 ../
> 
> State as seen on the server (mounted via nfs from localhost):
> 
> ls -laF 
> /var/autofs/local/src/openwrt/build_dir/target-mips_24kc_musl/linux-ar71xx_tiny/linux-4.14.125/arch/mips/include/generated/uapi/asm
> total 12
> drwxr-xr-x 2 anivanov anivanov 4096 Jul  8 11:40 ./
> drwxr-xr-x 3 anivanov anivanov 4096 Jul  8 11:40 ../
> -rw-r--r-- 1 anivanov anivanov   32 Jul  8 11:40 ipcbuf.h
> 
> Actual state on the filesystem:
> 
> ls -laF 
> /exports/work/src/openwrt/build_dir/target-mips_24kc_musl/linux-ar71xx_tiny/linux-4.14.125/arch/mips/include/generated/uapi/asm
> total 12
> drwxr-xr-x 2 anivanov anivanov 4096 Jul  8 11:40 ./
> drwxr-xr-x 3 anivanov anivanov 4096 Jul  8 11:40 ../
> -rw-r--r-- 1 anivanov anivanov   32 Jul  8 11:40 ipcbuf.h
> 
> So the client has quite clearly lost the plot. Telling it to drop caches and
> re-reading the directory shows the file present.
> 
> It is possible to reproduce this using a linux kernel tree too, just takes
> much more iterations - 10+ at least.
> 
> Both client and server run 4.19.37 from Debian buster. This is filed as
> debian bug 931500. I originally thought it to be autofs related, but IMHO it
> is actually something fundamentally broken in nfs caching resulting in cache
> corruption.

According to the reporter downstream in Debian, at
https://bugs.debian.org/940821#26 thi seem still reproducible with
more recent kernels than the initial reported. Is there anything Anton
can provide to try to track down the issue?

Anton, can you reproduce with current stable series?

Regards,
Salvatore

[PATCH v2] hwrng: iproc: set quality to 1024

2021-02-20 Thread Álvaro Fernández Rojas

This allows khwrngd to make use of iproc-rng200.

Justification:
cat /dev/hwrng | rngtest -c 1000
rngtest 6.10
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO 
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 2032
rngtest: FIPS 140-2 successes: 1000
rngtest: FIPS 140-2 failures: 0
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=107.179; avg=200.770; 
max=9765625.000)Kibits/s
rngtest: FIPS tests speed: (min=34.742; avg=39.905; max=66.458)Mibits/s
rngtest: Program run time: 97829648 microseconds

1000 successes and 0 failures -> 100% success rate

Signed-off-by: Álvaro Fernández Rojas 
---
 v2: set quality to 1024 and add justification

 drivers/char/hw_random/iproc-rng200.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/char/hw_random/iproc-rng200.c 
b/drivers/char/hw_random/iproc-rng200.c
index 01583faf9893..d22406528ac5 100644
--- a/drivers/char/hw_random/iproc-rng200.c
+++ b/drivers/char/hw_random/iproc-rng200.c
@@ -199,6 +199,7 @@ static int iproc_rng200_probe(struct platform_device *pdev)
priv->rng.read = iproc_rng200_read;
priv->rng.init = iproc_rng200_init;
priv->rng.cleanup = iproc_rng200_cleanup;
+   priv->rng.quality = 1024;
 
/* Register driver */
ret = devm_hwrng_register(dev, >rng);
-- 
2.20.1

[PATCH v2] hwrng: bcm2835: set quality to 1000

2021-02-20 Thread Álvaro Fernández Rojas

This allows devices without a high precission timer to speed up boot from
more 100 s to lest than 30s.

Justification:
root@OpenWrt:/# cat /dev/hwrng | rngtest -c 1000
rngtest 6.10
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 2032
rngtest: FIPS 140-2 successes: 996
rngtest: FIPS 140-2 failures: 4
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 1
rngtest: FIPS 140-2(2001-10-10) Long run: 3
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=146.002; avg=349.394;
max=1302083.333)Kibits/s
rngtest: FIPS tests speed: (min=12.126; avg=22.750; max=23.432)Mibits/s
rngtest: Program run time: 56826982 microseconds

996 successes and 4 failures -> 99.6% success rate
1024 * 99.6% = 1019 (rounded down to 1000)

Signed-off-by: Álvaro Fernández Rojas 
---
 v2: add jusftification

 drivers/char/hw_random/bcm2835-rng.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/char/hw_random/bcm2835-rng.c 
b/drivers/char/hw_random/bcm2835-rng.c
index 1a7c43b43c6b..4b48cb7176b0 100644
--- a/drivers/char/hw_random/bcm2835-rng.c
+++ b/drivers/char/hw_random/bcm2835-rng.c
@@ -163,6 +163,7 @@ static int bcm2835_rng_probe(struct platform_device *pdev)
priv->rng.init = bcm2835_rng_init;
priv->rng.read = bcm2835_rng_read;
priv->rng.cleanup = bcm2835_rng_cleanup;
+   priv->rng.quality = 1000;
 
if (dev_of_node(dev)) {
rng_id = of_match_node(bcm2835_rng_of_match, dev->of_node);
-- 
2.20.1

Re: [PATCH v3 5/9] arm64: dts: imx8mm-nitrogen-r2: rework UART 2

On Fri, Feb 19, 2021 at 03:30:24PM +0100, Adrien Grassein wrote:
> Remove useless clocks in UART 2
> 
> Signed-off-by: Adrien Grassein 
> ---
>  arch/arm64/boot/dts/freescale/imx8mm-nitrogen-r2.dts | 2 --
>  1 file changed, 2 deletions(-)

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: KASAN: use-after-free Write in j1939_can_recv

2021-02-20 Thread Pavel Machek

Can we get some kind of common prefix for the subjects?


> This report is generated by a bot. It may contain errors.

It is less useful than average lkml mail, so it should be easy to
filter.


> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
> 
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: Digital signature

Re: linux-next: manual merge of the arm-soc tree with the arm tree

2021-02-20 Thread Alain Volmat

Hi Stephen,

sorry for the delay, is there anything I should do concerning this issue
?

Cheers,
Alain

On Mon, Feb 15, 2021 at 09:14:44AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> On Tue, 2 Feb 2021 09:01:35 +1100 Stephen Rothwell  
> wrote:
> >
> > Today's linux-next merge of the arm-soc tree got a conflict in:
> > 
> >   arch/arm/Kconfig.debug
> > 
> > between commits:
> > 
> >   9ca4efec0aba ("ARM: 9040/1: use DEBUG_UART_PHYS and DEBUG_UART_VIRT for 
> > sti LL_UART")
> >   6e959ad8bb90 ("ARM: 9041/1: sti LL_UART: add STiH418 SBC UART0 support")
> > 
> > from the arm tree and commits:
> > 
> >   f3a732843acc ("ARM: remove sirf prima2/atlas platforms")
> >   89d4f98ae90d ("ARM: remove zte zx platform")
> > 
> > from the arm-soc tree.
> > 
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging.  You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
> > 
> > diff --cc arch/arm/Kconfig.debug
> > index 7a8697a97c98,c36c5d4c6e9c..
> > --- a/arch/arm/Kconfig.debug
> > +++ b/arch/arm/Kconfig.debug
> > @@@ -1623,10 -1546,7 +1550,9 @@@ config DEBUG_LL_INCLUD
> > default "debug/renesas-scif.S" if DEBUG_RMOBILE_SCIFA4
> > default "debug/s3c24xx.S" if DEBUG_S3C24XX_UART || DEBUG_S3C64XX_UART
> > default "debug/s5pv210.S" if DEBUG_S5PV210_UART
> > -   default "debug/sirf.S" if DEBUG_SIRFSOC_UART
> >  -  default "debug/sti.S" if DEBUG_STI_UART
> >  +  default "debug/sti.S" if DEBUG_STIH41X_ASC2
> >  +  default "debug/sti.S" if DEBUG_STIH41X_SBC_ASC1
> >  +  default "debug/sti.S" if DEBUG_STIH418_SBC_ASC0
> > default "debug/stm32.S" if DEBUG_STM32_UART
> > default "debug/tegra.S" if DEBUG_TEGRA_UART
> > default "debug/ux500.S" if DEBUG_UX500_UART
> > @@@ -1659,8 -1579,6 +1585,7 @@@ config DEBUG_UART_PHY
> > default 0x02531000 if DEBUG_KEYSTONE_UART1
> > default 0x03010fe0 if ARCH_RPC
> > default 0x0700 if DEBUG_SUN9I_UART0
> > -   default 0x09405000 if DEBUG_ZTE_ZX
> >  +  default 0x0953 if DEBUG_STIH418_SBC_ASC0
> > default 0x10009000 if DEBUG_REALVIEW_STD_PORT || \
> > DEBUG_VEXPRESS_UART0_CA9
> > default 0x1010c000 if DEBUG_REALVIEW_PB1176_PORT
> > @@@ -1789,10 -1698,8 +1707,10 @@@
> > DEBUG_RMOBILE_SCIFA4 || DEBUG_S3C24XX_UART || \
> > DEBUG_S3C64XX_UART || \
> > DEBUG_BCM63XX_UART || DEBUG_ASM9260_UART || \
> > -   DEBUG_SIRFSOC_UART || DEBUG_DIGICOLOR_UA0 || \
> > +   DEBUG_DIGICOLOR_UA0 || \
> >  -  DEBUG_AT91_UART || DEBUG_STM32_UART
> >  +  DEBUG_AT91_UART || DEBUG_STM32_UART || \
> >  +  DEBUG_STIH41X_ASC2 || DEBUG_STIH41X_SBC_ASC1 || \
> >  +  DEBUG_STIH418_SBC_ASC0
> >   
> >   config DEBUG_UART_VIRT
> > hex "Virtual base address of debug UART"
> > @@@ -1854,12 -1760,9 +1772,11 @@@
> > default 0xfb02 if DEBUG_OMAP3UART3
> > default 0xfb042000 if DEBUG_OMAP3UART4
> > default 0xfb10c000 if DEBUG_REALVIEW_PB1176_PORT
> > -   default 0xfc705000 if DEBUG_ZTE_ZX
> > default 0xfcfe8600 if DEBUG_BCM63XX_UART
> > default 0xfd00 if DEBUG_SPEAR3XX || DEBUG_SPEAR13XX
> >  +  default 0xfd531000 if DEBUG_STIH41X_SBC_ASC1
> > default 0xfd883000 if DEBUG_ALPINE_UART0
> >  +  default 0xfdd32000 if DEBUG_STIH41X_ASC2
> > default 0xfe01 if STM32MP1_DEBUG_UART
> > default 0xfe017000 if DEBUG_MMP_UART2
> > default 0xfe018000 if DEBUG_MMP_UART3
> > @@@ -1904,10 -1802,8 +1816,10 @@@
> > DEBUG_QCOM_UARTDM || DEBUG_S3C24XX_UART || \
> > DEBUG_S3C64XX_UART || \
> > DEBUG_BCM63XX_UART || DEBUG_ASM9260_UART || \
> > -   DEBUG_SIRFSOC_UART || DEBUG_DIGICOLOR_UA0 || \
> > +   DEBUG_DIGICOLOR_UA0 || \
> >  -  DEBUG_AT91_UART || DEBUG_STM32_UART
> >  +  DEBUG_AT91_UART || DEBUG_STM32_UART || \
> >  +  DEBUG_STIH41X_ASC2 || DEBUG_STIH41X_SBC_ASC1 || \
> >  +  DEBUG_STIH418_SBC_ASC0
> >   
> >   config DEBUG_UART_8250_SHIFT
> > int "Register offset shift for the 8250 debug UART"
> 
> With the merge window about to open, this is a reminder that this
> conflict still exists.
> 
> -- 
> Cheers,
> Stephen Rothwell

Re: WARNING in iov_iter_revert (2)

On Sat, Feb 20, 2021 at 07:29:57PM +, Al Viro wrote:

> And then you notice that it has reports
> successful write of amount other than what you'd passed and tries
> to pull back.

Sorry, half-edited sentence has escaped ;-/  Should be

"And there the caller notices that callback has reported a successful
write, but the amount apparently written is not the same as the
amount it had asked to write.  It interprets that as a short write
and tries to pull back.  Only it's actually _forward_, since we'd
asked to write 0 bytes and got a small positive number from the
callback."

Re: [PATCH] hwrng: bcm2835: set quality to 1000

2021-02-20 Thread Andrew Lunn

On Sat, Feb 20, 2021 at 08:12:45PM +0100, Álvaro Fernández Rojas wrote:
> Hi Andrew,
> 
> I ran rngtest and this is what I got:
> root@OpenWrt:/# cat /dev/hwrng | rngtest -c 1000
> rngtest 6.10
> Copyright (c) 2004 by Henrique de Moraes Holschuh
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> rngtest: starting FIPS tests...
> rngtest: bits received from input: 2032
> rngtest: FIPS 140-2 successes: 996
> rngtest: FIPS 140-2 failures: 4
> rngtest: FIPS 140-2(2001-10-10) Monobit: 0
> rngtest: FIPS 140-2(2001-10-10) Poker: 0
> rngtest: FIPS 140-2(2001-10-10) Runs: 1
> rngtest: FIPS 140-2(2001-10-10) Long run: 3
> rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
> rngtest: input channel speed: (min=146.002; avg=349.394;
> max=1302083.333)Kibits/s
> rngtest: FIPS tests speed: (min=12.126; avg=22.750; max=23.432)Mibits/s
> rngtest: Program run time: 56826982 microseconds
> 
> 996 successes and 4 failures -> 99.6% success rate
> 1024 * 99.6% = 1019 (rounded down to 1000)
> 
> I'm not sure if I can rely on rngtest for that...

Hi Álvaro

You need some sort of justification for setting the quality
value. Please include what you have written above in the commit
message. It then becomes possible for reviewers to say if this
justification is valid or not.

Andrew

Re: [PATCH 1/8] af_unix: take address assignment/hash insertion into a new helper

On Sat, Feb 20, 2021 at 11:12:33AM -0800, Cong Wang wrote:
> On Thu, Feb 18, 2021 at 8:22 PM Al Viro  wrote:
> >
> > Duplicated logics in all bind variants (autobind, bind-to-path,
> > bind-to-abstract) gets taken into a common helper.
> >
> > Signed-off-by: Al Viro 
> > ---
> >  net/unix/af_unix.c | 30 +++---
> >  1 file changed, 15 insertions(+), 15 deletions(-)
> >
> > diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
> > index 41c3303c3357..179b4fe837e6 100644
> > --- a/net/unix/af_unix.c
> > +++ b/net/unix/af_unix.c
> > @@ -262,6 +262,16 @@ static void __unix_insert_socket(struct hlist_head 
> > *list, struct sock *sk)
> > sk_add_node(sk, list);
> >  }
> >
> > +static void __unix_set_addr(struct sock *sk, struct unix_address *addr,
> > +   unsigned hash)
> > +   __releases(_table_lock)
> > +{
> > +   __unix_remove_socket(sk);
> > +   smp_store_release(_sk(sk)->addr, addr);
> > +   __unix_insert_socket(_socket_table[hash], sk);
> > +   spin_unlock(_table_lock);
> 
> Please take the unlock out, it is clearly an anti-pattern.

Why?  "Insert into locked and unlock" is fairly common...

> And please Cc netdev for networking changes.

Sorry about that - I'd ended up emulating git send-email by hand
and missed the Cc.  Sorted out by now...

Re: WARNING in iov_iter_revert (2)

On Sat, Feb 20, 2021 at 05:38:49PM +, Al Viro wrote:
> On Sat, Feb 20, 2021 at 08:56:40AM -0800, Linus Torvalds wrote:
> > Al,
> >  This is the "FIXME! Have Al check this!" case in do_tty_write(). You were
> > in on that whole discussion, but we never did get to that issue...
> > 
> > There are some subtle rules about doing the iov_iter_revert(), but what's
> > the best way to do this properly? Instead of doing a copy_from_iter() and
> > then reverting the part that didn't fit in the buffer, doing a
> > non-advancing copy and then advancing the amount that did fit, or what?
> > 
> > I still don't have power, so this is all me on mobile with html email
> > (sorry), and limited ability to really look closer.
> > 
> > "Help me, Albi-wan Viro, you're my only hope"
> 
> Will check...  BTW, when you get around to doing pulls, could you pick
> the replacement (in followup) instead of the first pull request for
> work.namei?  Jens has caught a braino in the last commit there...

It turned out to be really amusing.  What happens is write(fd, NULL, 0)
on /dev/ttyprintk, with N_GSM0710 for ldisc (== "pass the data as
is to tty->op->write()".  And that's the first write since opening
that sucker, so we end up with
/* write_buf/write_cnt is protected by the atomic_write_lock mutex */
if (tty->write_cnt < chunk) {
unsigned char *buf_chunk;

if (chunk < 1024)
chunk = 1024;

buf_chunk = kmalloc(chunk, GFP_KERNEL);
if (!buf_chunk) {
ret = -ENOMEM;
goto out;
}
kfree(tty->write_buf);
tty->write_cnt = chunk;
tty->write_buf = buf_chunk;
}
doing nothing - ->write_cnt is still 0 and ->write_buf - NULL.  Then
we copy 0 bytes from source to ->write_buf(), which reports that 0
bytes had been copied, TYVM.  Then we call
ret = write(tty, file, tty->write_buf, size);
i.e.
ret = gsm_write(tty, file, NULL, 0);
which calls
tpk_write(tty, NULL, 0)
which does
tpk_printk(NULL, 0);
and _that_ has a very special semantics:
int i = tpk_curr;

if (buf == NULL) {
tpk_flush();
return i;
}  
i.e. it *can* return a positive number that gets propagated all way
back to do_tty_write().  And then you notice that it has reports
successful write of amount other than what you'd passed and tries
to pull back.  By amount passed - amount written.  With iov_iter_revert()
saying that some tosser has asked it to revert by something close to
~(size_t)0.

IOW, it's not iov_iter_revert() being weird or do_tty_write() misuing it -
it's tpk_write() playing silly buggers.  Note that old tree would've
gone through seriously weird contortions on the same call:
// chunk and count are 0, ->write_buf is NULL
for (;;) {
size_t size = count;
if (size > chunk)
size = chunk;
ret = -EFAULT;
if (copy_from_user(tty->write_buf, buf, size))
break;
ret = write(tty, file, tty->write_buf, size);
if (ret <= 0)
break;
written += ret;
buf += ret;
count -= ret;
if (!count)
break;
ret = -ERESTARTSYS;
if (signal_pending(current))
break;
cond_resched();
}
and we get written = ret = small positive, count = - that amount,
buf = NULL + that mount.  On the next iteration size = 0 (since
chunk is still 0), with same no-op copy_from_user() of 0 bytes,
then gsm_write(tty, file, NULL, 0) and since tpk_flush() zeroes
tpk_curr we finally get 0 out of tpk_printk/tpk_write/gsm_write
and bugger off on if (ret <= 0).  Then we have the value in written
returned.

So yeah, this return value *was* returned to userland.  Except that
if we had done any writes before that, we'd find ->write_buf
non-NULL and the magical semantics of write(fd, NULL, 0) would
*not* have triggered - we would've gotten zero.

Do we want to preserve that weirdness of /dev/ttyprintk writes?
That's orthogonal to the iov_iter uses in there.

Re: [PATCH v3 4/9] arm64: dts: imx8mm-nitrogen-r2: add UARTs

On Fri, Feb 19, 2021 at 03:30:23PM +0100, Adrien Grassein wrote:
> Add description and pin muxing for UARTs.
> 
> Signed-off-by: Adrien Grassein 
> ---
>  .../boot/dts/freescale/imx8mm-nitrogen-r2.dts | 48 +++
>  1 file changed, 48 insertions(+)
> 

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH v3 1/9] arm64: dts: imx8mm-nitrogen-r2: add wifi/bt chip

On Fri, Feb 19, 2021 at 03:30:20PM +0100, Adrien Grassein wrote:
> Add usdhc3 description which corresponds to the wifi/bt chip
> 
> Signed-off-by: Adrien Grassein 
> ---
>  .../boot/dts/freescale/imx8mm-nitrogen-r2.dts | 38 +++
>  1 file changed, 38 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-nitrogen-r2.dts 
> b/arch/arm64/boot/dts/freescale/imx8mm-nitrogen-r2.dts
> index c0c384d76147..4a3dabeb8c85 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm-nitrogen-r2.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-nitrogen-r2.dts
> @@ -9,6 +9,24 @@
>  / {
>   model = "Boundary Devices i.MX8MMini Nitrogen8MM Rev2";
>   compatible = "boundary,imx8mm-nitrogen8mm", "fsl,imx8mm";
> +
> + reg_vref_1v8: regulator-vref-1v8 {
> + compatible = "regulator-fixed";
> + regulator-name = "vref-1v8";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + };
> +
> + reg_wlan_vmmc: regulator-wlan-vmmc {
> + compatible = "regulator-fixed";
> + pinctrl-names = "default";
> + pinctrl-0 = <_reg_wlan_vmmc>;
> + regulator-name = "reg_wlan_vmmc";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + gpio = < 20 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
>  };
>  
>  _0 {
> @@ -206,6 +224,20 @@  {
>   status = "okay";
>  };
>  
> +/* wlan */
> + {
> + bus-width = <4>;
> + sdhci-caps-mask = <0x2 0x0>;
> + non-removable;
> + pinctrl-names = "default", "state_100mhz", "state_200mhz";
> + pinctrl-0 = <_usdhc3>;
> + pinctrl-1 = <_usdhc3_100mhz>;
> + pinctrl-2 = <_usdhc3_200mhz>;
> + vmmc-supply = <_wlan_vmmc>;
> + vqmmc-supply = <_vref_1v8>;

You sent v3 before I replied on your comments. I don't think there is
any benefit in fixed-regulator which cannot be controlled. Are you sure
vqmmc (the bus clock, host interface, controller core?) does not go from
the PMIC?

Best regards,
Krzysztof

Re: [PATCH v2 3/8] arm64: dts: imx8mm-nitrogen-r2: add espi2 support