Re: [PATCH 2/2] USB: PHY: JZ4770: Add support for Ingenic X1000 and X1830.

[kbuild test robot]

Hi "周琰杰,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on balbi-usb/testing/next]
[also build test WARNING on v5.7]
[cannot apply to usb/usb-testing next-20200529]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Zhou-Yanjie/Add-USB-PHY-support-for-Ingenic-X1000-and-X1830/20200601-030314
base:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
testing/next
config: x86_64-allyesconfig (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 
2388a096e7865c043e83ece4e26654bd3d1a20d5)
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
# 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: kbuild test robot 

All warnings (new ones prefixed by >>, old ones prefixed by <<):

>> drivers/usb/phy/phy-jz4770.c:267:19: warning: cast to smaller integer type 
>> 'enum ingenic_usb_phy_version' from 'const void *' 
>> [-Wvoid-pointer-to-enum-cast]
priv->version = (enum ingenic_usb_phy_version)match->data;
^
1 warning generated.

vim +267 drivers/usb/phy/phy-jz4770.c

   253  
   254  static int jz4770_phy_probe(struct platform_device *pdev)
   255  {
   256  struct device *dev = &pdev->dev;
   257  struct jz4770_phy *priv;
   258  const struct of_device_id *match;
   259  int err;
   260  
   261  priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
   262  if (!priv)
   263  return -ENOMEM;
   264  
   265  match = of_match_device(ingenic_usb_phy_of_matches, dev);
   266  if (match)
 > 267  priv->version = (enum 
 > ingenic_usb_phy_version)match->data;
   268  else
   269  return -ENODEV;
   270  
   271  platform_set_drvdata(pdev, priv);
   272  priv->dev = dev;
   273  priv->phy.dev = dev;
   274  priv->phy.otg = &priv->otg;
   275  priv->phy.label = "ingenic-usb-phy";
   276  priv->phy.init = jz4770_phy_init;
   277  priv->phy.shutdown = jz4770_phy_shutdown;
   278  
   279  priv->otg.state = OTG_STATE_UNDEFINED;
   280  priv->otg.usb_phy = &priv->phy;
   281  priv->otg.set_host = jz4770_phy_set_host;
   282  priv->otg.set_peripheral = jz4770_phy_set_peripheral;
   283  
   284  priv->base = devm_platform_ioremap_resource(pdev, 0);
   285  if (IS_ERR(priv->base)) {
   286  dev_err(dev, "Failed to map registers");
   287  return PTR_ERR(priv->base);
   288  }
   289  
   290  priv->clk = devm_clk_get(dev, NULL);
   291  if (IS_ERR(priv->clk)) {
   292  err = PTR_ERR(priv->clk);
   293  if (err != -EPROBE_DEFER)
   294  dev_err(dev, "Failed to get clock");
   295  return err;
   296  }
   297  
   298  priv->vcc_supply = devm_regulator_get(dev, "vcc");
   299  if (IS_ERR(priv->vcc_supply)) {
   300  err = PTR_ERR(priv->vcc_supply);
   301  if (err != -EPROBE_DEFER)
   302  dev_err(dev, "Failed to get regulator");
   303  return err;
   304  }
   305  
   306  err = usb_add_phy(&priv->phy, USB_PHY_TYPE_USB2);
   307  if (err) {
   308  if (err != -EPROBE_DEFER)
   309  dev_err(dev, "Unable to register PHY");
   310  return err;
   311  }
   312  
   313  return devm_add_action_or_reset(dev, jz4770_phy_remove, 
&priv->phy);
   314  }
   315  

---
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 v2 5/6] mtd: spi-nor: Convert cadence-quadspi to use spi-mem framework

[Vignesh Raghavendra]

On 30/05/20 7:20 pm, tudor.amba...@microchip.com wrote:
> Hi, Vignesh,
> 
> On Tuesday, May 26, 2020 12:36:03 PM EEST Vignesh Raghavendra wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
>> content is safe
>>
>> From: Ramuthevar Vadivel Murugan
>> 
>>
>> Move cadence-quadspi driver to use spi-mem framework. This is required
>> to make the driver support for SPI NAND flashes in future.
>>
>> Driver is feature compliant with existing SPI NOR version.
>>
>> Signed-off-by: Ramuthevar Vadivel Murugan
>>  Signed-off-by: Vignesh
>> Raghavendra 
>> ---
>>  .../mtd/spi-nor/controllers/cadence-quadspi.c | 469 +++---
>>  1 file changed, 183 insertions(+), 286 deletions(-)
>>
>> diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
>> b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c index
>> 608ca657ff7f..c1df4b221889 100644
>> --- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
>> +++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
>> @@ -3,6 +3,8 @@
>>   * Driver for Cadence QSPI Controller
>>   *
>>   * Copyright Altera Corporation (C) 2012-2014. All rights reserved.
>> + * Copyright Intel Corporation (C) 2019-2020. All rights reserved.
>> + * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com
>>   */
>>  #include 
>>  #include 
>> @@ -17,9 +19,6 @@
>>  #include 
>>  #include 
>>  #include 
>> -#include 
>> -#include 
>> -#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -27,6 +26,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>
>>  #define CQSPI_NAME "cadence-qspi"
>> @@ -36,16 +36,12 @@
>>  #define CQSPI_NEEDS_WR_DELAY   BIT(0)
>>  #define CQSPI_DISABLE_DAC_MODE BIT(1)
>>
>> -/* Capabilities mask */
>> -#define CQSPI_BASE_HWCAPS_MASK \
>> -   (SNOR_HWCAPS_READ | SNOR_HWCAPS_READ_FAST | \
>> -   SNOR_HWCAPS_READ_1_1_2 | SNOR_HWCAPS_READ_1_1_4 |   \
>> -   SNOR_HWCAPS_PP)
>> +/* Capabilities */
>> +#define CQSPI_SUPPORTS_OCTAL   BIT(0)
>>
>>  struct cqspi_st;
>>
>>  struct cqspi_flash_pdata {
>> -   struct spi_nor  nor;
>> struct cqspi_st *cqspi;
>> u32 clk_rate;
>> u32 read_delay;
>> @@ -58,7 +54,6 @@ struct cqspi_flash_pdata {
>> u8  data_width;
>> u8  cs;
>> boolregistered;
> 
> you can drop this, as it is no longer used
> 
>> -   booluse_direct_mode;
>>  };
>>
>>  struct cqspi_st {
>> @@ -71,7 +66,6 @@ struct cqspi_st {
>> void __iomem*ahb_base;
>> resource_size_t ahb_size;
>> struct completion   transfer_complete;
>> -   struct mutexbus_mutex;
>>
>> struct dma_chan *rx_chan;
>> struct completion   rx_dma_complete;
>> @@ -85,6 +79,7 @@ struct cqspi_st {
>> boolrclk_en;
>> u32 trigger_address;
>> u32 wr_delay;
>> +   booluse_dac_mode;
> 
> is use_dac_mode better than use_direct_mode? If you prefer "dac", maybe you 
> can rename this variable in 2/6

I will just keep "use_direct_mode" as is to minimize churn

> 
>> struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
>>  };
>>
>> @@ -283,9 +278,8 @@ static irqreturn_t cqspi_irq_handler(int this_irq, void
>> *dev) return IRQ_HANDLED;
>>  }
>>
>> -static unsigned int cqspi_calc_rdreg(struct spi_nor *nor)
>> +static unsigned int cqspi_calc_rdreg(struct cqspi_flash_pdata *f_pdata)
>>  {
>> -   struct cqspi_flash_pdata *f_pdata = nor->priv;
>> u32 rdreg = 0;
>>
>> rdreg |= f_pdata->inst_width << CQSPI_REG_RD_INSTR_TYPE_INSTR_LSB;
>> @@ -352,19 +346,21 @@ static int cqspi_exec_flash_cmd(struct cqspi_st
>> *cqspi, unsigned int reg) return cqspi_wait_idle(cqspi);
>>  }
>>
>> -static int cqspi_command_read(struct spi_nor *nor, u8 opcode,
>> - u8 *rxbuf, size_t n_rx)
>> +static int cqspi_command_read(struct cqspi_flash_pdata *f_pdata,
>> + const struct spi_mem_op *op)
>>  {
>> -   struct cqspi_flash_pdata *f_pdata = nor->priv;
>> struct cqspi_st *cqspi = f_pdata->cqspi;
>> void __iomem *reg_base = cqspi->iobase;
>> +   u8 *rxbuf = op->data.buf.in;
>> +   u8 opcode = op->cmd.opcode;
> 
> dedicated variable for opcode is not really needed, it is used only once.

I did this intentionaly in view of 2 byte opcodes being added for Octal
DDR mode

> 
>> +   size_t n_rx = op->data.nbytes;
>> unsigned int rdreg;
>> unsigned int reg;
>> size_t read_len;
>> int status;
>>
>> if (!n_rx || n_rx > CQSPI_STIG_DATA_LEN_MAX || !rxbuf) {
>> -   dev_err(nor->dev,
>> +   dev_err(&cqspi->pdev->dev,
>> "Invalid input argument, len %zu rxbuf 0x

Re: [PATCH net-next v4] hinic: add set_channels ethtool_ops support

[Michal Kubecek]

On Mon, Jun 01, 2020 at 09:42:06AM +, Luo bin wrote:
> add support to change TX/RX queue number with ethtool -L ethx combined
> 
> Signed-off-by: Luo bin 
> ---
[...]

The patch looks correct but I'm not sure how is this change

> diff --git a/drivers/net/ethernet/huawei/hinic/hinic_tx.c 
> b/drivers/net/ethernet/huawei/hinic/hinic_tx.c
> index 4c66a0bc1b28..6da761d7a6ef 100644
> --- a/drivers/net/ethernet/huawei/hinic/hinic_tx.c
> +++ b/drivers/net/ethernet/huawei/hinic/hinic_tx.c
> @@ -470,6 +470,11 @@ netdev_tx_t hinic_xmit_frame(struct sk_buff *skb, struct 
> net_device *netdev)
>   struct hinic_txq *txq;
>   struct hinic_qp *qp;
>  
> + if (unlikely(!netif_carrier_ok(netdev))) {
> + dev_kfree_skb_any(skb);
> + return NETDEV_TX_OK;
> + }
> +
>   txq = &nic_dev->txqs[q_id];
>   qp = container_of(txq->sq, struct hinic_qp, sq);
>  

related to the rest. It rather looks as a fix/workaround for a race
condition you encountered while testing it but which could also happen
under other circumstances.

Michal

Re: [PATCH v4 4/4] kdb: Switch to use safer dbg_io_ops over console APIs

[Sumit Garg]

On Sun, 31 May 2020 at 10:58, kbuild test robot  wrote:
>
> Hi Sumit,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on tty/tty-testing]
> [also build test ERROR on usb/usb-testing v5.7-rc7 next-20200529]
> [cannot apply to kgdb/kgdb-next]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improve the system. BTW, we also suggest to use '--base' option to specify the
> base tree in git format-patch, please see 
> https://stackoverflow.com/a/37406982]
>
> url:
> https://github.com/0day-ci/linux/commits/Sumit-Garg/kdb-Improve-console-handling/20200531-075431
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git 
> tty-testing
> config: x86_64-allyesconfig (attached as .config)
> compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 
> 2388a096e7865c043e83ece4e26654bd3d1a20d5)
> 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
> # 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: kbuild test robot 
>
> All errors (new ones prefixed by >>, old ones prefixed by <<):
>
> >> drivers/usb/early/ehci-dbgp.c:1062:24: error: assigning to 'struct console 
> >> *' from incompatible type 'struct console'; take the address with &
> kgdbdbgp_io_ops.cons = early_dbgp_console;
> ^ ~~
> &
> 1 error generated.
>

Ah, my bad. Will fix it up in the next version.

-Sumit

> vim +1062 drivers/usb/early/ehci-dbgp.c
>
>   1046
>   1047  static int __init kgdbdbgp_parse_config(char *str)
>   1048  {
>   1049  char *ptr;
>   1050
>   1051  if (!ehci_debug) {
>   1052  if (early_dbgp_init(str))
>   1053  return -1;
>   1054  }
>   1055  ptr = strchr(str, ',');
>   1056  if (ptr) {
>   1057  ptr++;
>   1058  kgdbdbgp_wait_time = simple_strtoul(ptr, &ptr, 10);
>   1059  }
>   1060  kgdb_register_io_module(&kgdbdbgp_io_ops);
>   1061  if (early_dbgp_console.index != -1)
> > 1062  kgdbdbgp_io_ops.cons = early_dbgp_console;
>   1063
>   1064  return 0;
>   1065  }
>   1066  early_param("kgdbdbgp", kgdbdbgp_parse_config);
>   1067
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org

Wohltätigkeitsspende von 2.000.000 Millionen Euro

[''Tayeb Souami'']

Lieber Freund,

Ich bin Herr Tayeb Souami, New Jersey, Vereinigte Staaten von Amerika, der 
Mega-Gewinner von $ 315million In Mega Millions Jackpot, spende ich an 5 
zufällige Personen, wenn Sie diese E-Mail erhalten, dann wurde Ihre E-Mail nach 
einem Spinball ausgewählt.Ich habe den größten Teil meines Vermögens auf eine 
Reihe von Wohltätigkeitsorganisationen und Organisationen verteilt.Ich habe 
mich freiwillig dazu entschieden, die Summe von € 2.000.000,00 an Sie als eine 
der ausgewählten 5 zu spenden, um meine Gewinne zu überprüfen, sehen Sie bitte 
meine You Tube Seite unten.

UHR MICH HIER: https://www.youtube.com/watch?v=Z6ui8ZDQ6Ks


Das ist dein Spendencode: [TS530342018]


Antworten Sie mit dem SPENDE-CODE an diese

 E-Mail:tayebsouam.spe...@gmail.com

Ich hoffe, Sie und Ihre Familie glücklich zu machen.

Grüße
Herr Tayeb Souami

Re: [RFC PATCH -rcu lkmm] tools/memory-model/README: Expand dependency of klitmus7

[Andrea Parri]

On Mon, Jun 01, 2020 at 12:37:20AM +0900, Akira Yokosawa wrote:
> From 87048d7212f6cb16b0a2b85fa6d2f34c28b078c0 Mon Sep 17 00:00:00 2001
> From: Akira Yokosawa 
> Date: Sun, 31 May 2020 20:04:32 +0900
> Subject: [PATCH RFC] tools/memory-model/README: Expand dependency of klitmus7
> 
> klitmus7 is independent of the memory model but depends on the
> build-target kernel release.
> It occasionally lost compatibility due to kernel API changes [1, 2, 3].
> It was remedied in a backwards-compatible manner respectively [4, 5, 6].
> 
> Reflect this fact in README.
> 
> [1]: b899a850431e ("compiler.h: Remove ACCESS_ONCE()")
> [2]: 0bb95f80a38f ("Makefile: Globally enable VLA warning")
> [3]: d56c0d45f0e2 ("proc: decouple proc from VFS with "struct proc_ops"")
> [4]: https://github.com/herd/herdtools7/commit/e87d7f9287d1
>  ("klitmus: Use WRITE_ONCE and READ_ONCE in place of deprecated 
> ACCESS_ONCE")
> [5]: https://github.com/herd/herdtools7/commit/a0cbb10d02be
>  ("klitmus: Avoid variable length array")
> [6]: https://github.com/herd/herdtools7/commit/46b9412d3a58
>  ("klitmus: Linux kernel v5.6.x compat")
> 
> NOTE: [5] was ahead of herdtools7 7.53, which did not make an
> official release.  Code generated by klitmus7 without [5] can still be
> built targeting Linux 4.20--5.5 if you don't care VLA warnings.
> 
> Signed-off-by: Akira Yokosawa 

Acked-by: Andrea Parri 

  Andrea


> ---
> Hi all,
> 
> Recent struggle of Andrii with the use of klitmus7 on an up-to-date
> Linux system prompted me to add some explanation of klitmus7's dependency
> in README.
> 
> As herdtools7 7.56 is still under development, I called out just HEAD
> in the compatibility table.  Once 7.56 is released, the table can be
> updated.
> 
> I'm not sure if this is the right place to carry such info.
> Anyway, I'd be glad if this patch can trigger a meaningful update of
> README.
> 
> Thanks, Akira
> --
>  tools/memory-model/README | 30 --
>  1 file changed, 28 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/memory-model/README b/tools/memory-model/README
> index b9c562e92981..90af203c3cf1 100644
> --- a/tools/memory-model/README
> +++ b/tools/memory-model/README
> @@ -28,8 +28,34 @@ downloaded separately:
>  See "herdtools7/INSTALL.md" for installation instructions.
>  
>  Note that although these tools usually provide backwards compatibility,
> -this is not absolutely guaranteed.  Therefore, if a later version does
> -not work, please try using the exact version called out above.
> +this is not absolutely guaranteed.
> +
> +For example, a future version of herd7 might not work with the model
> +in this release.  A compatible model will likely be made available in
> +a later release of Linux kernel.
> +
> +If you absolutely need to run the model in this particular release,
> +please try using the exact version called out above.
> +
> +klitmus7 is independent of the model provided here.  It has its own
> +dependency on a target kernel release where converted code is built
> +and executed.  Any change in kernel APIs essential to klitmus7 will
> +necessitate an upgrade of klitmus7.
> +
> +If you find any compatibility issues in klitmus7, please inform the
> +memory model maintainers.
> +
> +klitmus7 Compatibility Table
> +
> +
> +   ==
> + target Linux  herdtools7
> +   --
> +  -- 4.18  7.48 --
> + 4.15 -- 4.19  7.49 --
> + 4.20 -- 5.5   7.54 --
> + 5.6  --   HEAD
> +   ==
>  
>  
>  ==
> -- 
> 2.17.1
> 

Re: [PATCH] RDMA/hns: Uninitialized variable in modify_qp_init_to_rtr()

[Leon Romanovsky]

On Fri, May 29, 2020 at 11:39:18AM +0300, Dan Carpenter wrote:
> The "dmac" variable is used before it is initialized.
>
> Fixes: 494c3b312255 ("RDMA/hns: Refactor the QP context filling process 
> related to WQE buffer configure")
> Signed-off-by: Dan Carpenter 
> ---
>  drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Thanks,
Reviewed-by: Leon Romanovsky 

Re: [PATCH v5 02/11] dt-bindings: dma: dw: Add max burst transaction length property

[Viresh Kumar]

On 29-05-20, 17:40, Serge Semin wrote:
> This array property is used to indicate the maximum burst transaction
> length supported by each DMA channel.
> 
> Signed-off-by: Serge Semin 
> Cc: Alexey Malahov 
> Cc: Thomas Bogendoerfer 
> Cc: Arnd Bergmann 
> Cc: Andy Shevchenko 
> Cc: linux-m...@vger.kernel.org
> 
> ---
> 
> Changelog v2:
> - Rearrange SoBs.
> - Move $ref to the root level of the properties. So do with the
>   constraints.
> - Set default max-burst-len to 256 TR-WIDTH words.
> 
> Changelog v3:
> - Add more details into the property description about what limitations
>   snps,max-burst-len defines.
> ---
>  .../bindings/dma/snps,dma-spear1340.yaml  | 15 +++
>  1 file changed, 15 insertions(+)

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH v5 01/11] dt-bindings: dma: dw: Convert DW DMAC to DT binding

[Viresh Kumar]

On 29-05-20, 17:40, Serge Semin wrote:
> Modern device tree bindings are supposed to be created as YAML-files
> in accordance with dt-schema. This commit replaces the Synopsis
> Designware DMA controller legacy bare text bindings with YAML file.
> The only required prorties are "compatible", "reg", "#dma-cells" and
> "interrupts", which will be used by the driver to correctly find the
> controller memory region and handle its events. The rest of the properties
> are optional, since in case if either "dma-channels" or "dma-masters" isn't
> specified, the driver will attempt to auto-detect the IP core
> configuration.
> 
> Signed-off-by: Serge Semin 
> Reviewed-by: Rob Herring 

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH] RISC-V: Don't mark init section as non-executable

[Anup Patel]

On Sun, May 31, 2020 at 3:28 PM Anup Patel  wrote:
>
> The head text section (i.e. _start, secondary_start_sbi, etc) and the
> init section fall under same page table level-1 mapping.
>
> Currently, the runtime CPU hotplug is broken because we are marking
> init section as non-executable which in-turn marks head text section
> as non-executable.
>
> Further investigating other architectures, it seems marking the init
> section as non-executable is redundant because the init section pages
> are anyway poisoned and freed.
>
> To fix broken runtime CPU hotplug, we simply remove the code marking
> the init section as non-executable.
>
> Fixes: d27c3c90817e ("riscv: add STRICT_KERNEL_RWX support")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Anup Patel 
> ---
>  arch/riscv/mm/init.c | 5 -
>  1 file changed, 5 deletions(-)
>
> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> index 736de6c8739f..e0f8ccab8a41 100644
> --- a/arch/riscv/mm/init.c
> +++ b/arch/riscv/mm/init.c
> @@ -482,11 +482,6 @@ static void __init setup_vm_final(void)
>
>  void free_initmem(void)
>  {
> -   unsigned long init_begin = (unsigned long)__init_begin;
> -   unsigned long init_end = (unsigned long)__init_end;
> -
> -   /* Make the region as non-execuatble. */
> -   set_memory_nx(init_begin, (init_end - init_begin) >> PAGE_SHIFT);
> free_initmem_default(POISON_FREE_INITMEM);
>  }

I just realized that updated free_initmem() over here is exactly
same as generic free_initmem() defined in init/main.c so it's better
to remove free_initmem() from here. I will send v2.

Regards,
Anup

Re: [PATCH v11 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver

[Hsin-Yi Wang]

On Fri, May 15, 2020 at 2:53 PM Xin Ji  wrote:

> +
> +static int anx7625_bridge_attach(struct drm_bridge *bridge)

Latest drm_bridge api:

int (*attach)(struct drm_bridge *bridge,
 enum drm_bridge_attach_flags flags);

https://elixir.bootlin.com/linux/v5.7-rc7/source/include/drm/drm_bridge.h#L70

> +{
> +   struct anx7625_data *ctx = bridge_to_anx7625(bridge);
> +   int err;

Can i trust you?

[Mr Suleman Bello]

Dear Friend,

Please i want you to read this letter very carefully and i must
apologize for berging this message into your mail box without any
formal introduction due to the urgency and confidential of this issue
and i know that this message will come to you as a surprise, Please
this is not a joke and i will not like you to joke with it.I am
Mr.Suleman Bello, a staff in African Development Bank (A.D.B)
Ouagadougou, Burkina faso West Africa.I discovered existing dormant
account for years. When I discovered that there had been neither
continuation nor withdrawals from this account for this long period
and according to the laws and constitution guiding this banking
institution, any unserviceable account for more than (7) seven years,
that fund will be transferred to national treasury as unclaimed fund.

I Hoped that you will not expose or betray this trust and confident
that i am about to extablish with you for the mutual benefit of you
and i,I need your urgent assistance in transferring the sum of $10.5
)million usd into your account within 7 banking days. This money has
been dormant for years in our Bank, and The request of foreigner in
this transaction is necessary because our late customer was a
foreigner and a burkinabe cannot stand as next of kin to a
foreigner.Because of the static of this transaction I want you to
stand as the next of kin so that our bank will accord you the
recognition and have the fund transferred to your account.

Upon your response, I shall then provide you with further information
and more deities that will help you understand the transaction. I am
expecting your urgent response to enable me inform you on how the
business will be executed. Please I would like you to keep this
transaction confidential and as a top secret or delete if you are not
interested.

Thanks
Mr.Suleman Bello.

Re: [PATCH] usb: cdns3: fix possible buffer overflow caused by bad DMA value

[Peter Chen]

On 20-05-30 11:24:00, Jia-Ju Bai wrote:
> In cdns3_ep0_setup_phase():
>   struct usb_ctrlrequest *ctrl = priv_dev->setup_buf;
> 
> Because priv_dev->setup_buf (allocated in cdns3_gadget_start) is stored 
> in DMA memory, and thus ctrl is a DMA value.
> 
> cdns3_ep0_setup_phase()
>   cdns3_ep0_standard_request(priv_dev, ctrl)
> cdns3_req_ep0_get_status(priv_dev, ctrl)
>   index = cdns3_ep_addr_to_index(ctrl->wIndex);
>   priv_ep = priv_dev->eps[index];
> 
> cdns3_ep0_setup_phase()
>   cdns3_ep0_standard_request(priv_dev, ctrl)
> cdns3_req_ep0_handle_feature(priv_dev, ctrl_req, 0)
>   cdns3_ep0_feature_handle_endpoint(priv_dev, ctrl, set)
> index = cdns3_ep_addr_to_index(ctrl->wIndex);
> priv_ep = priv_dev->eps[index];
> 
> In these cases, ctrl->wIndex can be be modified at anytime by malicious
> hardware, and thus a buffer overflow can occur when the code
> "priv_dev->eps[index]" is executed.
> 

Did you see the setup buffer is overwritten before the setup handling is
finished?

> To fix these possible bugs, index is checked before being used.

I think the better fix is to use one additional buffer for struct
usb_ctrlrequest, and copy the dma_buf to it after setup packet
has received, then use the value stored in this buffer for later
operation, it could avoid quitting the code which is useful in fact.

Peter

> 
> Signed-off-by: Jia-Ju Bai 
> ---
>  drivers/usb/cdns3/ep0.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/usb/cdns3/ep0.c b/drivers/usb/cdns3/ep0.c
> index e71240b386b4..0a80c7ade613 100644
> --- a/drivers/usb/cdns3/ep0.c
> +++ b/drivers/usb/cdns3/ep0.c
> @@ -265,6 +265,8 @@ static int cdns3_req_ep0_get_status(struct cdns3_device 
> *priv_dev,
>   return cdns3_ep0_delegate_req(priv_dev, ctrl);
>   case USB_RECIP_ENDPOINT:
>   index = cdns3_ep_addr_to_index(ctrl->wIndex);
> + if (index >= CDNS3_ENDPOINTS_MAX_COUNT)
> + return -EINVAL;
>   priv_ep = priv_dev->eps[index];
>  
>   /* check if endpoint is stalled or stall is pending */
> @@ -388,6 +390,9 @@ static int cdns3_ep0_feature_handle_endpoint(struct 
> cdns3_device *priv_dev,
>   return 0;
>  
>   index = cdns3_ep_addr_to_index(ctrl->wIndex);
> + if (index >= CDNS3_ENDPOINTS_MAX_COUNT)
> + return -EINVAL;
> +
>   priv_ep = priv_dev->eps[index];
>  
>   cdns3_select_ep(priv_dev, ctrl->wIndex);
> -- 
> 2.17.1
> 

-- 

Thanks,
Peter Chen

Re: [PATCH v6 3/6] irqchip: RISC-V per-HART local interrupt controller driver

[Anup Patel]

On Sun, May 31, 2020 at 4:23 PM Marc Zyngier  wrote:
>
> On 2020-05-31 11:06, Anup Patel wrote:
> > On Sun, May 31, 2020 at 3:03 PM Marc Zyngier  wrote:
> >>
> >> On 2020-05-31 06:36, Anup Patel wrote:
> >> > On Sat, May 30, 2020 at 5:31 PM Marc Zyngier  wrote:
> >>
> >> [...]
> >>
> >> >> >   plic_set_threshold(handler, PLIC_DISABLE_THRESHOLD);
> >> >>
> >> >> Why do you need to both disable the interrupt *and* change the
> >> >> priority
> >> >> threshold? It seems to be that one of them should be enough, but my
> >> >> kno9wledge of the PLIC is limited. In any case, this would deserve a
> >> >> comment.
> >> >
> >> > Okay, I will test and remove "disable the interrupt" part from
> >> > plic_dying_cpu().
> >>
> >> Be careful, as interrupt enabling/disabling is refcounted in order
> >> to allow nesting. If you only enable on CPU_ON and not disable
> >> on CPU_OFF, you will end-up with a depth that only increases,
> >> up to the point where you hit the roof (it will take a while though).
> >>
> >> I would keep the enable/disable as is, and drop the priority
> >> setting from the CPU_OFF path.
> >
> > The PLIC threshold is like GICv2 CPU interface enable/disable.
>
> Looking at the documentation[1], that's not really a correct analogy:
>
> - The PLIC is far removed from the CPU, and is more akin a GICv3
>distributor. The INTC itself is more like a GICv3 redistributor,
>as it deals with local interrupts only. I don't see anything
>in the RISC-V architecture that actually behaves like a GIC
>CPU interface (not necessarily a bad thing...).
>
> - The threshold register is not an ON/OFF, but a priority mask,
>similar to the GIC PMR (except that the PMR lives in the CPU
>interface and affects all interrupts targetting this CPU while
>this only seem to affect PLIC interrupts and not the INTC interrupts).
>You may be using it as an ON/OFF for now as you don't support
>multiple priorities yet, but that's just a SW thing.

Yes, your analogy is correct.

BTW, PLIC does not handle MSI and does not have virtualization support
pass-through interrupts. We will most likely see a new RISC-V interrupt
controller spec for these capabilities.

Also, the PLIC spec is now owned by RISC-V foundation (not SiFive) so
we will have to rename the driver to "irq-riscv-plic" and will have a new
generic compatible string "riscv,plic-1.0.0". One of us (me or Palmer) will
send separate patches for this renaming. I hope you will be fine with this??
(Refer, https://github.com/riscv/riscv-plic-spec)

>
> > Based on your comment, we should only program the PLIC threshold
> > in CPU_ON and don't touch the PLIC threshold in CPU_OFF. Right??
>
> This seems like the correct thing to do.

Sure, I will update.

>
>  M.
>
> [1]
> https://sifive.cdn.prismic.io/sifive%2Fdc4980ff-17db-448b-b521-4c7ab26b7488_sifive+u54-mc+manual+v19.08.pdf
> --
> Jazz is not dead. It just smells funny...

Regards,
Anup

Re: [PATCH] OPP: Check for bandwidth values before creating icc paths

[Viresh Kumar]

On 29-05-20, 19:47, Sibi Sankar wrote:
> opp_np needs to be subjected
> to NULL check as well.

No, it isn't. It should already be valid and is set by the OPP core.
Actually we don't need to do of_node_get(opp_table->np) and just use
np, I did that to not have a special case while putting the resource.

> Tested-by: Sibi Sankar 
> Reviewed-by: Sibi Sankar 

Thanks.

-- 
viresh

Re: [RFC][PATCH 0/2] Add support for using reserved memory for ima buffer pass

[Prakhar Srivastava]

On 5/22/20 9:08 PM, Thiago Jung Bauermann wrote:


Hello Prakhar,

Prakhar Srivastava  writes:


On 5/12/20 4:05 PM, Rob Herring wrote:

On Wed, May 06, 2020 at 10:50:04PM -0700, Prakhar Srivastava wrote:

Hi Mark,


Please don't top post.


This patch set currently only address the Pure DT implementation.
EFI and ACPI implementations will be posted in subsequent patchsets.

The logs are intended to be carried over the kexec and once read the
logs are no longer needed and in prior conversation with James(
https://lore.kernel.org/linux-arm-kernel/0053eb68-0905-4679-c97a-00c5cb6f1...@arm.com/)
the apporach of using a chosen node doesn't
support the case.

The DT entries make the reservation permanent and thus doesnt need kernel
segments to be used for this, however using a chosen-node with
reserved memory only changes the node information but memory still is
reserved via reserved-memory section.


I think Mark's point was whether it needs to be permanent. We don't
hardcode the initrd address for example.


Thankyou for clarifying my misunderstanding, i am modelling this keeping to the
TPM log implementation that uses a reserved memory. I will rev up the version
with chosen-node support.
That will make the memory reservation free after use.


Nice. Do you intend to use the same property that powerpc uses
(linux,ima-kexec-buffer)?


I was naming it ima-buffer, but naming is not a huge concern.
I will use linux,ima-kexec-buffer.

On 5/5/20 2:59 AM, Mark Rutland wrote:

Hi Prakhar,

On Mon, May 04, 2020 at 01:38:27PM -0700, Prakhar Srivastava wrote:

IMA during kexec(kexec file load) verifies the kernel signature and measures


What's IMAIMA is a LSM attempting to detect if files have been accidentally or

maliciously altered, both remotely and locally, it can also be used
to appraise a file's measurement against a "good" value stored as an extended
attribute, and enforce local file integrity.

IMA also validates and measures the signers of the kernel and initrd
during kexec. The measurements are extended to PCR 10(configurable) and the logs
stored in memory, however once kexec'd the logs are lost. Kexec is used as
secondary boot loader in may use cases and loosing the signer
creates a security hole.

This patch is an implementation to carry over the logs and making it
possible to remotely validate the signers of the kernel and initrd. Such a
support exits only in powerpc.
This patch makes the carry over of logs architecture independent and puts the
complexity in a driver.


If I'm not mistaken, the code at arch/powerpc/kexec/ima.c isn't actually
powerpc-specific. It could be moved to an arch-independent directory and
used by any other architecture which supports device trees.

I think that's the simplest way forward. And to be honest I'm still
trying to understand why you didn't take that approach. Did you try it
and hit some obstacle or noticed a disadvantage for your use case?

The approach i have in this patch set is to provide an abstraction layer 
that can be called from any architecture.

However taking a deeper look only the setup dtb is probably architecture
specific, only because the architecture specific kexec sets up the 
device tree. I can also move the code up in security/ima. However i do
have some concerns with layering. I am hoping you can provide me with 
some guidance in this aspect, i will send you the patch i am working on

to get some early feedback.

Thanks,
Prakhar Srivastava



--
Thiago Jung Bauermann
IBM Linux Technology Center

Re: [PATCH] input: tablet: aiptek: fix possible buffer overflow caused by bad DMA value in aiptek_irq()

[kbuild test robot]

Hi Jia-Ju,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on input/next]
[also build test WARNING on v5.7 next-20200529]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Jia-Ju-Bai/input-tablet-aiptek-fix-possible-buffer-overflow-caused-by-bad-DMA-value-in-aiptek_irq/20200601-015649
base:   https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
config: mips-randconfig-r032-20200531 (attached as .config)
compiler: mipsel-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=mips 

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

All warnings (new ones prefixed by >>, old ones prefixed by <<):

In file included from include/asm-generic/div64.h:25,
from arch/mips/include/asm/div64.h:12,
from include/linux/math64.h:6,
from include/linux/jiffies.h:6,
from drivers/input/tablet/aiptek.c:60:
drivers/input/tablet/aiptek.c: In function 'aiptek_irq':
drivers/input/tablet/aiptek.c:744:7: error: 'marco' undeclared (first use in 
this function); did you mean 'macro'?
744 |   if (marco > 0 && macro < 25) {
|   ^
include/linux/compiler.h:58:52: note: in definition of macro '__trace_if_var'
58 | #define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) : 
__trace_if_value(cond))
|^~~~
>> drivers/input/tablet/aiptek.c:744:3: note: in expansion of macro 'if'
744 |   if (marco > 0 && macro < 25) {
|   ^~
drivers/input/tablet/aiptek.c:744:7: note: each undeclared identifier is 
reported only once for each function it appears in
744 |   if (marco > 0 && macro < 25) {
|   ^
include/linux/compiler.h:58:52: note: in definition of macro '__trace_if_var'
58 | #define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) : 
__trace_if_value(cond))
|^~~~
>> drivers/input/tablet/aiptek.c:744:3: note: in expansion of macro 'if'
744 |   if (marco > 0 && macro < 25) {
|   ^~

vim +/if +744 drivers/input/tablet/aiptek.c

   377  
   378  /***
   379   * aiptek_irq can receive one of six potential reports.
   380   * The documentation for each is in the body of the function.
   381   *
   382   * The tablet reports on several attributes per invocation of
   383   * aiptek_irq. Because the Linux Input Event system allows the
   384   * transmission of ONE attribute per input_report_xxx() call,
   385   * collation has to be done on the other end to reconstitute
   386   * a complete tablet report. Further, the number of Input Event reports
   387   * submitted varies, depending on what USB report type, and 
circumstance.
   388   * To deal with this, EV_MSC is used to indicate an 'end-of-report'
   389   * message. This has been an undocumented convention understood by the 
kernel
   390   * tablet driver and clients such as gpm and XFree86's tablet drivers.
   391   *
   392   * Of the information received from the tablet, the one piece I
   393   * cannot transmit is the proximity bit (without resorting to an EV_MSC
   394   * convention above.) I therefore have taken over REL_MISC and ABS_MISC
   395   * (for relative and absolute reports, respectively) for communicating
   396   * Proximity. Why two events? I thought it interesting to know if the
   397   * Proximity event occurred while the tablet was in absolute or relative
   398   * mode.
   399   * Update: REL_MISC proved not to be such a good idea. With REL_MISC you
   400   * get an event transmitted each time. ABS_MISC works better, since it
   401   * can be set and re-set. Thus, only using ABS_MISC from now on.
   402   *
   403   * Other tablets use the notion of a certain minimum stylus pressure
   404   * to infer proximity. While that could have been done, that is yet
   405   * another 'by convention' behavior, the documentation for which
   406   * would be spread between two (or more) pieces of software.
   407   *
   408   * EV_MSC usage was terminated for this purpose in Linux 2.5.x, and
   409   * replaced with the input_sync() method (which emits EV_SYN.)
   410   */
   411  
   412  static void aiptek_irq(struct urb *urb)
   413  {
   414  struct aiptek *aiptek = urb->c

Re: [PATCH] i2c: sh_mobile: Fix compilation warning

[Viresh Kumar]

On 29-05-20, 14:12, Wolfram Sang wrote:
> On Thu, May 09, 2019 at 10:13:46AM +0530, Viresh Kumar wrote:
> > This currently generates a warning:
> > 
> > drivers/i2c/busses/i2c-sh_mobile.c: In function 'sh_mobile_i2c_isr':
> > drivers/i2c/busses/i2c-sh_mobile.c:399:26: warning: 'data' may be used 
> > uninitialized in this function [-Wmaybe-uninitialized]
> > 
> > Though the code looks okay and shouldn't ever use the variable
> > uninitialized.
> > 
> > Fix the warning by moving the code around and getting rid of 'data'.
> > 
> > Compile tested only.
> > 
> > Signed-off-by: Viresh Kumar 
> 
> Tested on a Renesas Lager board (R-Car H2). Dumping register sets
> produces identical results.
> 
> Tested-by: Wolfram Sang 
> 
> And code is actually cleaner now.
> 
> Applied to for-next, thanks!
> 

Almost after an year, wondering on how you reached this patch now :)

-- 
viresh

[PATCH V2] mailbox: imx: Add context save/restore for suspend/resume

[Anson Huang]

From: Dong Aisheng 

For "mem" mode suspend on i.MX8 SoCs, MU settings could be
lost because its power is off, so save/restore is needed
for MU settings during suspend/resume. However, the restore
can ONLY be done when MU settings are actually lost, for the
scenario of settings NOT lost in "freeze" mode suspend, since
there could be still IPC going on multiple CPUs, restoring the
MU settings could overwrite the TIE by mistake and cause system
freeze, so need to make sure ONLY restore the MU settings when
it is powered off, Anson fixes this by checking whether restore
is actually needed when resume.

Signed-off-by: Dong Aisheng 
Signed-off-by: Anson Huang 
---
Changes since V1:
- change the author and add more fix note in commit log.
---
 drivers/mailbox/imx-mailbox.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
index 97bf0ac..b53cf63 100644
--- a/drivers/mailbox/imx-mailbox.c
+++ b/drivers/mailbox/imx-mailbox.c
@@ -67,6 +67,8 @@ struct imx_mu_priv {
struct clk  *clk;
int irq;
 
+   u32 xcr;
+
boolside_b;
 };
 
@@ -583,12 +585,45 @@ static const struct of_device_id imx_mu_dt_ids[] = {
 };
 MODULE_DEVICE_TABLE(of, imx_mu_dt_ids);
 
+static int imx_mu_suspend_noirq(struct device *dev)
+{
+   struct imx_mu_priv *priv = dev_get_drvdata(dev);
+
+   priv->xcr = imx_mu_read(priv, priv->dcfg->xCR);
+
+   return 0;
+}
+
+static int imx_mu_resume_noirq(struct device *dev)
+{
+   struct imx_mu_priv *priv = dev_get_drvdata(dev);
+
+   /*
+* ONLY restore MU when context lost, the TIE could
+* be set during noirq resume as there is MU data
+* communication going on, and restore the saved
+* value will overwrite the TIE and cause MU data
+* send failed, may lead to system freeze. This issue
+* is observed by testing freeze mode suspend.
+*/
+   if (!imx_mu_read(priv, priv->dcfg->xCR))
+   imx_mu_write(priv, priv->xcr, priv->dcfg->xCR);
+
+   return 0;
+}
+
+static const struct dev_pm_ops imx_mu_pm_ops = {
+   SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(imx_mu_suspend_noirq,
+ imx_mu_resume_noirq)
+};
+
 static struct platform_driver imx_mu_driver = {
.probe  = imx_mu_probe,
.remove = imx_mu_remove,
.driver = {
.name   = "imx_mu",
.of_match_table = imx_mu_dt_ids,
+   .pm = &imx_mu_pm_ops,
},
 };
 module_platform_driver(imx_mu_driver);
-- 
2.7.4

WARNING in snd_usbmidi_submit_urb/usb_submit_urb

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:bdc48fa1 checkpatch/coding-style: deprecate 80-column warn..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15d6458610
kernel config:  https://syzkaller.appspot.com/x/.config?x=129ea1e5950835e5
dashboard link: https://syzkaller.appspot.com/bug?extid=5f1d24c49c1d2c427497
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=12d70cf210

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

RBP: 0078bf00 R08:  R09: 
R10:  R11: 0246 R12: 0004
R13: 07dc R14: 004cab2a R15: 7f5ab0e216d4
[ cut here ]
URB d6b1ff88 submitted while active
WARNING: CPU: 1 PID: 8661 at drivers/usb/core/urb.c:363 
usb_submit_urb+0x10c1/0x13b0 drivers/usb/core/urb.c:363
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 8661 Comm: syz-executor.0 Not tainted 5.7.0-rc7-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x188/0x20d lib/dump_stack.c:118
 panic+0x2e3/0x75c kernel/panic.c:221
 __warn.cold+0x2f/0x35 kernel/panic.c:582
 report_bug+0x27b/0x2f0 lib/bug.c:195
 fixup_bug arch/x86/kernel/traps.c:175 [inline]
 fixup_bug arch/x86/kernel/traps.c:170 [inline]
 do_error_trap+0x12b/0x220 arch/x86/kernel/traps.c:267
 do_invalid_op+0x32/0x40 arch/x86/kernel/traps.c:286
 invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1027
RIP: 0010:usb_submit_urb+0x10c1/0x13b0 drivers/usb/core/urb.c:363
Code: 89 de e8 32 54 6a fc 84 db 0f 85 42 f6 ff ff e8 f5 52 6a fc 4c 89 fe 48 
c7 c7 60 46 ab 88 c6 05 22 f3 7b 05 01 e8 b7 82 3b fc <0f> 0b e9 20 f6 ff ff c7 
44 24 14 01 00 00 00 e9 d7 f6 ff ff 41 bd
RSP: 0018:c9000a37f2c8 EFLAGS: 00010282
RAX:  RBX:  RCX: 
RDX:  RSI: 815cf161 RDI: f5200146fe4b
RBP: dc00 R08: 88808f2242c0 R09: ed1015ce66a9
R10: 8880ae733547 R11: ed1015ce66a8 R12: 0cc0
R13: fff0 R14: 8880a37b6400 R15: 8880894c1600
 snd_usbmidi_submit_urb+0x19/0x60 sound/usb/midi.c:194
 snd_usbmidi_input_start_ep sound/usb/midi.c:2313 [inline]
 snd_usbmidi_input_start.part.0+0xbe/0x1c0 sound/usb/midi.c:2329
 snd_usbmidi_input_start sound/usb/midi.c:1119 [inline]
 substream_open.isra.0+0x505/0x830 sound/usb/midi.c:1119
 open_substream+0x42e/0x880 sound/core/rawmidi.c:299
 rawmidi_open_priv+0x2e8/0x6e0 sound/core/rawmidi.c:342
 snd_rawmidi_kernel_open+0x1b5/0x270 sound/core/rawmidi.c:382
 midisynth_subscribe+0xf2/0x330 sound/core/seq/seq_midi.c:170
 subscribe_port sound/core/seq/seq_ports.c:412 [inline]
 check_and_subscribe_port+0x5b5/0x800 sound/core/seq/seq_ports.c:495
 snd_seq_port_connect+0x2e4/0x510 sound/core/seq/seq_ports.c:564
 snd_seq_ioctl_subscribe_port+0x1df/0x310 sound/core/seq/seq_clientmgr.c:1484
 snd_seq_kernel_client_ctl+0xeb/0x130 sound/core/seq/seq_clientmgr.c:2353
 snd_seq_oss_midi_open+0x3cb/0x640 sound/core/seq/oss/seq_oss_midi.c:364
 snd_seq_oss_synth_setup_midi+0x123/0x520 sound/core/seq/oss/seq_oss_synth.c:269
 snd_seq_oss_open+0x7fa/0x980 sound/core/seq/oss/seq_oss_init.c:261
 odev_open+0x6c/0x90 sound/core/seq/oss/seq_oss.c:125
 soundcore_open+0x446/0x600 sound/sound_core.c:593
 chrdev_open+0x219/0x5c0 fs/char_dev.c:414
 do_dentry_open+0x4ba/0x1290 fs/open.c:797
 do_open fs/namei.c:3229 [inline]
 path_openat+0x1e59/0x27d0 fs/namei.c:3346
 do_filp_open+0x192/0x260 fs/namei.c:3373
 do_sys_openat2+0x585/0x7d0 fs/open.c:1148


---
This bug is generated by a bot. It may contain errors.
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 bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches

[PATCH] riscv: fix build warning of missing prototypes

[Zong Li]

Add the missing header in file, it was losed in original implementation.

The warning message as follows:
 - no previous prototype for 'patch_text_nosync' [-Wmissing-prototypes]
 - no previous prototype for 'patch_text' [-Wmissing-prototypes]

Signed-off-by: Zong Li 
Reported-by: kbuild test robot 
---
 arch/riscv/kernel/patch.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/riscv/kernel/patch.c b/arch/riscv/kernel/patch.c
index 5805791cd5b5..d4a64dfed342 100644
--- a/arch/riscv/kernel/patch.c
+++ b/arch/riscv/kernel/patch.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct patch_insn {
void *addr;
-- 
2.26.2

[PATCH V2 3/3] clk: imx8mp: add mu root clk

[peng . fan]

From: Peng Fan 

Add mu root clk for mu mailbox usage.

Signed-off-by: Peng Fan 
Reviewed-by: Dong Aisheng 
---
 drivers/clk/imx/clk-imx8mp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/imx/clk-imx8mp.c b/drivers/clk/imx/clk-imx8mp.c
index b4d9db9d5bf1..ca747712400f 100644
--- a/drivers/clk/imx/clk-imx8mp.c
+++ b/drivers/clk/imx/clk-imx8mp.c
@@ -680,6 +680,7 @@ static int imx8mp_clocks_probe(struct platform_device *pdev)
hws[IMX8MP_CLK_I2C2_ROOT] = imx_clk_hw_gate4("i2c2_root_clk", "i2c2", 
ccm_base + 0x4180, 0);
hws[IMX8MP_CLK_I2C3_ROOT] = imx_clk_hw_gate4("i2c3_root_clk", "i2c3", 
ccm_base + 0x4190, 0);
hws[IMX8MP_CLK_I2C4_ROOT] = imx_clk_hw_gate4("i2c4_root_clk", "i2c4", 
ccm_base + 0x41a0, 0);
+   hws[IMX8MP_CLK_MU_ROOT] = imx_clk_hw_gate4("mu_root_clk", "ipg_root", 
ccm_base + 0x4210, 0);
hws[IMX8MP_CLK_OCOTP_ROOT] = imx_clk_hw_gate4("ocotp_root_clk", 
"ipg_root", ccm_base + 0x4220, 0);
hws[IMX8MP_CLK_PCIE_ROOT] = imx_clk_hw_gate4("pcie_root_clk", 
"pcie_aux", ccm_base + 0x4250, 0);
hws[IMX8MP_CLK_PWM1_ROOT] = imx_clk_hw_gate4("pwm1_root_clk", "pwm1", 
ccm_base + 0x4280, 0);
-- 
2.16.4

[PATCH V2 2/3] arm64: dts: imx8m: add mu node

[peng . fan]

From: Peng Fan 

Add mu node to let A53 could communicate with M Core.

Signed-off-by: Peng Fan 
---
 arch/arm64/boot/dts/freescale/imx8mm.dtsi | 9 +
 arch/arm64/boot/dts/freescale/imx8mn.dtsi | 9 +
 arch/arm64/boot/dts/freescale/imx8mp.dtsi | 9 +
 arch/arm64/boot/dts/freescale/imx8mq.dtsi | 9 +
 4 files changed, 36 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index aaf6e71101a1..fc001fb971e9 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -775,6 +775,15 @@
status = "disabled";
};
 
+   mu: mailbox@30aa {
+   compatible = "fsl,imx8mm-mu", "fsl,imx6sx-mu";
+   reg = <0x30aa 0x1>;
+   interrupts = ;
+   clocks = <&clk IMX8MM_CLK_MU_ROOT>;
+   clock-names = "mu";
+   #mbox-cells = <2>;
+   };
+
usdhc1: mmc@30b4 {
compatible = "fsl,imx8mm-usdhc", 
"fsl,imx7d-usdhc";
reg = <0x30b4 0x1>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index 9a4b65a267d4..c8290d21ccc9 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -675,6 +675,15 @@
status = "disabled";
};
 
+   mu: mailbox@30aa {
+   compatible = "fsl,imx8mn-mu", "fsl,imx6sx-mu";
+   reg = <0x30aa 0x1>;
+   interrupts = ;
+   clocks = <&clk IMX8MN_CLK_MU_ROOT>;
+   clock-names = "mu";
+   #mbox-cells = <2>;
+   };
+
usdhc1: mmc@30b4 {
compatible = "fsl,imx8mn-usdhc", 
"fsl,imx7d-usdhc";
reg = <0x30b4 0x1>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index 45e2c0a4e889..b530804f763e 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -621,6 +621,15 @@
status = "disabled";
};
 
+   mu: mailbox@30aa {
+   compatible = "fsl,imx8mp-mu", "fsl,imx6sx-mu";
+   reg = <0x30aa 0x1>;
+   interrupts = ;
+   clocks = <&clk IMX8MP_CLK_MU_ROOT>;
+   clock-names = "mu";
+   #mbox-cells = <2>;
+   };
+
i2c5: i2c@30ad {
compatible = "fsl,imx8mp-i2c", "fsl,imx21-i2c";
#address-cells = <1>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 978f8122c0d2..66ba8da704f6 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -959,6 +959,15 @@
status = "disabled";
};
 
+   mu: mailbox@30aa {
+   compatible = "fsl,imx8mq-mu", "fsl,imx6sx-mu";
+   reg = <0x30aa 0x1>;
+   interrupts = ;
+   clocks = <&clk IMX8MQ_CLK_MU_ROOT>;
+   clock-names = "mu";
+   #mbox-cells = <2>;
+   };
+
usdhc1: mmc@30b4 {
compatible = "fsl,imx8mq-usdhc",
 "fsl,imx7d-usdhc";
-- 
2.16.4

[PATCH V2 1/3] dt-bindings: mailbox: imx-mu: support i.MX8M

[peng . fan]

From: Peng Fan 

Add i.MX8MQ/M/N/P compatible string to support i.MX8M SoCs

Signed-off-by: Peng Fan 
---
 Documentation/devicetree/bindings/mailbox/fsl,mu.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt 
b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
index 26b7a88c2fea..906377acf2cd 100644
--- a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
+++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
@@ -18,7 +18,8 @@ Messaging Unit Device Node:
 Required properties:
 ---
 - compatible : should be "fsl,-mu", the supported chips include
-   imx6sx, imx7s, imx8qxp, imx8qm.
+   imx6sx, imx7s, imx8qxp, imx8qm, imx8mq, imx8mm, imx8mn,
+   imx8mp.
The "fsl,imx6sx-mu" compatible is seen as generic and should
be included together with SoC specific compatible.
There is a version 1.0 MU on imx7ulp, use "fsl,imx7ulp-mu"
-- 
2.16.4

[PATCH V2 0/3] imx8m: add mu support

[peng . fan]

From: Peng Fan 

V2:
 Add dt-bindings
 Merge dts changes into one patch, since all is to add mu node

Add mu dt bindings
Add mu node
Add i.MX8MP mu root clk

Peng Fan (3):
  dt-bindings: mailbox: imx-mu: support i.MX8M
  arm64: dts: imx8m: add mu node
  clk: imx8mp: add mu root clk

 Documentation/devicetree/bindings/mailbox/fsl,mu.txt | 3 ++-
 arch/arm64/boot/dts/freescale/imx8mm.dtsi| 9 +
 arch/arm64/boot/dts/freescale/imx8mn.dtsi| 9 +
 arch/arm64/boot/dts/freescale/imx8mp.dtsi| 9 +
 arch/arm64/boot/dts/freescale/imx8mq.dtsi| 9 +
 drivers/clk/imx/clk-imx8mp.c | 1 +
 6 files changed, 39 insertions(+), 1 deletion(-)

-- 
2.16.4

Re: [PATCH] usb: gadget: f_acm: don't disable disabled EP

[Peter Chen]

On 20-05-30 19:15:52, Michał Mirosław wrote:
> On Sat, May 30, 2020 at 01:03:17AM +, Peter Chen wrote:
> >  
> > > > > @@ -425,9 +425,11 @@ static int acm_set_alt(struct usb_function *f, 
> > > > > unsigned
> > > intf, unsigned alt)
> > > > >   /* we know alt == 0, so this is an activation or a reset */
> > > > >
> > > > >   if (intf == acm->ctrl_id) {
> > > > > - dev_vdbg(&cdev->gadget->dev,
> > > > > - "reset acm control interface %d\n", 
> > > > > intf);
> > > > > - usb_ep_disable(acm->notify);
> > > > > + if (acm->notify->enabled) {
> > > > > + dev_vdbg(&cdev->gadget->dev,
> > > > > + "reset acm control interface 
> > > > > %d\n", intf);
> > > > > + usb_ep_disable(acm->notify);
> > > > > + }
> > > >
> > > > But it does not fix any issues, the usb_ep_disable checks 'enabled' 
> > > > flag.
> > > 
> > > It generates spurious trace events if you enable them.
> > You mean the trace events from core.c? If it is, we could try to improve it
> > and indicate it is already enabled or disabled.
> 
> It is indicated in return code, but the problem is that this generates
> noise and wastes debugging time. The problem I was seeing manifested
> itself as disabling disabled EPs and desync of EP state between core
> and UDC driver. The patch avoids the noise and makes the code obvious.
> (This check was there at some point in time, BTW.)
> 

Reviewed-by: Peter Chen 



-- 

Thanks,
Peter Chen

[PATCH] misc: atmel-ssc: lock with mutex instead of spinlock

[Michał Mirosław]

Uninterruptible context is not needed in the driver and causes lockdep
warning because of mutex taken in of_alias_get_id(). Convert the lock to
mutex to avoid the issue.

Cc: sta...@vger.kernel.org
Signed-off-by: Michał Mirosław 
---
 drivers/misc/atmel-ssc.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
index 1322e29bc37a..5cc032097476 100644
--- a/drivers/misc/atmel-ssc.c
+++ b/drivers/misc/atmel-ssc.c
@@ -10,7 +10,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -20,7 +20,7 @@
 #include "../../sound/soc/atmel/atmel_ssc_dai.h"
 
 /* Serialize access to ssc_list and user count */
-static DEFINE_SPINLOCK(user_lock);
+static DEFINE_MUTEX(user_lock);
 static LIST_HEAD(ssc_list);
 
 struct ssc_device *ssc_request(unsigned int ssc_num)
@@ -28,7 +28,7 @@ struct ssc_device *ssc_request(unsigned int ssc_num)
int ssc_valid = 0;
struct ssc_device *ssc;
 
-   spin_lock(&user_lock);
+   mutex_lock(&user_lock);
list_for_each_entry(ssc, &ssc_list, list) {
if (ssc->pdev->dev.of_node) {
if (of_alias_get_id(ssc->pdev->dev.of_node, "ssc")
@@ -44,18 +44,18 @@ struct ssc_device *ssc_request(unsigned int ssc_num)
}
 
if (!ssc_valid) {
-   spin_unlock(&user_lock);
+   mutex_unlock(&user_lock);
pr_err("ssc: ssc%d platform device is missing\n", ssc_num);
return ERR_PTR(-ENODEV);
}
 
if (ssc->user) {
-   spin_unlock(&user_lock);
+   mutex_unlock(&user_lock);
dev_dbg(&ssc->pdev->dev, "module busy\n");
return ERR_PTR(-EBUSY);
}
ssc->user++;
-   spin_unlock(&user_lock);
+   mutex_unlock(&user_lock);
 
clk_prepare(ssc->clk);
 
@@ -67,14 +67,14 @@ void ssc_free(struct ssc_device *ssc)
 {
bool disable_clk = true;
 
-   spin_lock(&user_lock);
+   mutex_lock(&user_lock);
if (ssc->user)
ssc->user--;
else {
disable_clk = false;
dev_dbg(&ssc->pdev->dev, "device already free\n");
}
-   spin_unlock(&user_lock);
+   mutex_unlock(&user_lock);
 
if (disable_clk)
clk_unprepare(ssc->clk);
@@ -246,9 +246,9 @@ static int ssc_probe(struct platform_device *pdev)
return -ENXIO;
}
 
-   spin_lock(&user_lock);
+   mutex_lock(&user_lock);
list_add_tail(&ssc->list, &ssc_list);
-   spin_unlock(&user_lock);
+   mutex_unlock(&user_lock);
 
platform_set_drvdata(pdev, ssc);
 
@@ -267,9 +267,9 @@ static int ssc_remove(struct platform_device *pdev)
 
ssc_sound_dai_remove(ssc);
 
-   spin_lock(&user_lock);
+   mutex_lock(&user_lock);
list_del(&ssc->list);
-   spin_unlock(&user_lock);
+   mutex_unlock(&user_lock);
 
return 0;
 }
-- 
2.20.1

[PATCH V2] dt-bindings: thermal: Convert qoriq to json-schema

[Anson Huang]

Convert the qoriq thermal binding to DT schema format using json-schema

Signed-off-by: Anson Huang 
---
Changes since V1:
- add 'maxItems' for 'fsl,tmu-range' property;
- add 'minItems'/'maxItems' and items descriptions for 
'fsl,tmu-calibration' property;
- remove description for common property '#thermal-sensor-cells';
- refine 'fsl,tmu-calibration' format in example.
---
 .../devicetree/bindings/thermal/qoriq-thermal.txt  |  71 -
 .../devicetree/bindings/thermal/qoriq-thermal.yaml | 112 +
 2 files changed, 112 insertions(+), 71 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
 create mode 100644 Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml

diff --git a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt 
b/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
deleted file mode 100644
index 28f2cba..000
--- a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
+++ /dev/null
@@ -1,71 +0,0 @@
-* Thermal Monitoring Unit (TMU) on Freescale QorIQ SoCs
-
-Required properties:
-- compatible : Must include "fsl,qoriq-tmu" or "fsl,imx8mq-tmu". The
-   version of the device is determined by the TMU IP Block Revision
-   Register (IPBRR0) at offset 0x0BF8.
-   Table of correspondences between IPBRR0 values and example  chips:
-   Value   Device
-   --  -
-   0x01900102  T1040
-- reg : Address range of TMU registers.
-- interrupts : Contains the interrupt for TMU.
-- fsl,tmu-range : The values to be programmed into TTRnCR, as specified by
-   the SoC reference manual. The first cell is TTR0CR, the second is
-   TTR1CR, etc.
-- fsl,tmu-calibration : A list of cell pairs containing temperature
-   calibration data, as specified by the SoC reference manual.
-   The first cell of each pair is the value to be written to TTCFGR,
-   and the second is the value to be written to TSCFGR.
-- #thermal-sensor-cells : Must be 1. The sensor specifier is the monitoring
-   site ID, and represents the "n" in TRITSRn and TRATSRn.
-
-Optional property:
-- little-endian : If present, the TMU registers are little endian. If absent,
-   the default is big endian.
-- clocks : the clock for clocking the TMU silicon.
-
-Example:
-
-tmu@f {
-   compatible = "fsl,qoriq-tmu";
-   reg = <0xf 0x1000>;
-   interrupts = <18 2 0 0>;
-   fsl,tmu-range = <0x000a 0x00090026 0x0008004a 0x0001006a>;
-   fsl,tmu-calibration = <0x 0x0025
-  0x0001 0x0028
-  0x0002 0x002d
-  0x0003 0x0031
-  0x0004 0x0036
-  0x0005 0x003a
-  0x0006 0x0040
-  0x0007 0x0044
-  0x0008 0x004a
-  0x0009 0x004f
-  0x000a 0x0054
-
-  0x0001 0x000d
-  0x00010001 0x0013
-  0x00010002 0x0019
-  0x00010003 0x001f
-  0x00010004 0x0025
-  0x00010005 0x002d
-  0x00010006 0x0033
-  0x00010007 0x0043
-  0x00010008 0x004b
-  0x00010009 0x0053
-
-  0x0002 0x0010
-  0x00020001 0x0017
-  0x00020002 0x001f
-  0x00020003 0x0029
-  0x00020004 0x0031
-  0x00020005 0x003c
-  0x00020006 0x0042
-  0x00020007 0x004d
-  0x00020008 0x0056
-
-  0x0003 0x0012
-  0x00030001 0x001d>;
-   #thermal-sensor-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml 
b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
new file mode 100644
index 000..c5df999
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/qoriq-thermal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Thermal Monitoring Unit (TMU) on Freescale QorIQ SoCs
+
+maintainers:
+  - Hongtao Jia 
+
+properties:
+  compatible:
+description: |
+  The version of the device is determined by th

Re: Re: [PATCH] drm/nouveau/clk/gm20b: Fix memory leak in gm20b_clk_new

[Ben Skeggs]

On Mon, 1 Jun 2020 at 13:37, Ben Skeggs  wrote:
>
> On Mon, 1 Jun 2020 at 13:27,  wrote:
> >
> >
> > Hi Ben,
> >
> > > > When gk20a_clk_ctor() returns an error code, pointer "clk"
> > > > should be released. It's the same when gm20b_clk_new()
> > > > returns from elsewhere following this call.
> > > This shouldn't be necessary.  If a subdev constructor fails, and
> > > returns a pointer, the core will call the destructor to clean things
> > > up.
> > >
> >
> > I'm not familiar with the behavior of the caller of gm20b_clk_new().
> > If the subdev constructor fails, the core will check the pointer
> > (here is "pclk"), then it's ok and there is no bug (Do you mean
> > this?). If the core executes error handling code only according to
> > the error code, there may be a memory leak bug (the caller cannot
> > know if -ENOMEM comes from the failure of kzalloc or gk20a_clk_ctor).
> > If the core always calls the destructor as long as the constructor
> > fails (even if the kzalloc fails), we may have a double free bug.
> >
> > Would you like to give a more detailed explanation about the behavior
> > of the core?
> If there's *any* error, it'll check the pointer, if it's non-NULL,
> it'll call the destructor.  If kzalloc() fails, the pointer will be
> NULL, there's no double-free bug.  *every* subdev is written this way
> to avoid duplicating cleanup logic.
Actually, gm20b_clk_new_speedo0() may have a bug here if kzalloc()
fails as it doesn't overwrite the previous pointer from
gm20b_clk_new().  That whole ctor() sequence is written a little
strangely.

>
> Ben.
> >
> > Regards,
> > Dinghao

Re: Re: [PATCH] drm/nouveau/clk/gm20b: Fix memory leak in gm20b_clk_new

[Ben Skeggs]

On Mon, 1 Jun 2020 at 13:27,  wrote:
>
>
> Hi Ben,
>
> > > When gk20a_clk_ctor() returns an error code, pointer "clk"
> > > should be released. It's the same when gm20b_clk_new()
> > > returns from elsewhere following this call.
> > This shouldn't be necessary.  If a subdev constructor fails, and
> > returns a pointer, the core will call the destructor to clean things
> > up.
> >
>
> I'm not familiar with the behavior of the caller of gm20b_clk_new().
> If the subdev constructor fails, the core will check the pointer
> (here is "pclk"), then it's ok and there is no bug (Do you mean
> this?). If the core executes error handling code only according to
> the error code, there may be a memory leak bug (the caller cannot
> know if -ENOMEM comes from the failure of kzalloc or gk20a_clk_ctor).
> If the core always calls the destructor as long as the constructor
> fails (even if the kzalloc fails), we may have a double free bug.
>
> Would you like to give a more detailed explanation about the behavior
> of the core?
If there's *any* error, it'll check the pointer, if it's non-NULL,
it'll call the destructor.  If kzalloc() fails, the pointer will be
NULL, there's no double-free bug.  *every* subdev is written this way
to avoid duplicating cleanup logic.

Ben.
>
> Regards,
> Dinghao

Re: [PATCH] opp: avoid uninitialized-variable use

[Viresh Kumar]

On 30-05-20, 14:40, Arnd Bergmann wrote:
> On Sat, May 30, 2020 at 11:21 AM Viresh Kumar  wrote:
> > On 29-05-20, 22:17, Arnd Bergmann wrote:
> > > An uninitialized pointer is passed into another function but
> > > --- a/drivers/opp/core.c
> > > +++ b/drivers/opp/core.c
> > > @@ -872,7 +872,7 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned 
> > > long target_freq)
> > >   goto put_opp_table;
> > >   }
> > >
> > > - ret = _set_opp_bw(opp_table, opp, dev, true);
> > > + ret = _set_opp_bw(opp_table, NULL, dev, true);
> > >   if (ret)
> > >   return ret;
> > >
> >
> > Not sure why people are still seeing this, I pushed a fix for this 2
> > days back.
> 
> I was on next-20200528, which was the first version that was broken for me,
> and I sent all my fixes after I had tested them. Since a lot of things
> got broken
> at once that day, it took me until the end of 20200529 to get it all tested
> properly and then send them out.

Okay, I asked as around 3-4 people have already sent out this patch to
me :)

-- 
viresh

Re: Re: [PATCH] drm/nouveau/clk/gm20b: Fix memory leak in gm20b_clk_new

[dinghao . liu]

Hi Ben,

> > When gk20a_clk_ctor() returns an error code, pointer "clk"
> > should be released. It's the same when gm20b_clk_new()
> > returns from elsewhere following this call.
> This shouldn't be necessary.  If a subdev constructor fails, and
> returns a pointer, the core will call the destructor to clean things
> up.
> 

I'm not familiar with the behavior of the caller of gm20b_clk_new(). 
If the subdev constructor fails, the core will check the pointer
(here is "pclk"), then it's ok and there is no bug (Do you mean 
this?). If the core executes error handling code only according to 
the error code, there may be a memory leak bug (the caller cannot 
know if -ENOMEM comes from the failure of kzalloc or gk20a_clk_ctor). 
If the core always calls the destructor as long as the constructor 
fails (even if the kzalloc fails), we may have a double free bug. 

Would you like to give a more detailed explanation about the behavior
of the core? 

Regards,
Dinghao

Re: [PATCH RFC] KVM: arm64: Sidestep stage2_unmap_vm() on vcpu reset when S2FWB is supported

[Zenghui Yu]

Hi Alex,

On 2020/5/30 18:46, Alexandru Elisei wrote:

Hi,

On 4/20/20 5:10 PM, Alexandru Elisei wrote:


[ For some unknown reasons, I had missed your reply one month ago.
  Sorry, I'm going to fix my email settings ... ]


Hi,

On 4/15/20 8:28 AM, Zenghui Yu wrote:

stage2_unmap_vm() was introduced to unmap user RAM region in the stage2
page table to make the caches coherent. E.g., a guest reboot with stage1
MMU disabled will access memory using non-cacheable attributes. If the
RAM and caches are not coherent at this stage, some evicted dirty cache
line may go and corrupt guest data in RAM.

Since ARMv8.4, S2FWB feature is mandatory and KVM will take advantage
of it to configure the stage2 page table and the attributes of memory
access. So we ensure that guests always access memory using cacheable
attributes and thus, the caches always be coherent.

So on CPUs that support S2FWB, we can safely reset the vcpu without a
heavy stage2 unmapping.

Cc: Marc Zyngier 
Cc: Christoffer Dall 
Cc: James Morse 
Cc: Julien Thierry 
Cc: Suzuki K Poulose 
Signed-off-by: Zenghui Yu 
---

If this is correct, there should be a great performance improvement on
a guest reboot (or reset) on systems support S2FWB. But I'm afraid that
I've missed some points here, so please comment!

The commit 957db105c997 ("arm/arm64: KVM: Introduce stage2_unmap_vm")
was merged about six years ago and I failed to track its histroy and
intention. Instead of a whole stage2 unmapping, something like
stage2_flush_vm() looks enough to me. But again, I'm unsure...

Thanks for having a look!

I had a chat with Christoffer about stage2_unmap_vm, and as I understood it, the
purpose was to make sure that any changes made by userspace were seen by the 
guest
while the MMU is off. When a stage 2 fault happens, we do clean+inval on the
dcache, or inval on the icache if it was an exec fault. This means that whatever
the host userspace writes while the guest is shut down and is still in the 
cache,
the guest will be able to read/execute.

This can be relevant if the guest relocates the kernel and overwrites the 
original
image location, and userspace copies the original kernel image back in before
restarting the vm.


Yes, I-cache coherency is what I had missed! So without a S2 unmapping
on reboot, if there's any stale and "valid" cache line in the I-cache,
guest may fetch the wrong instructions directly from it, and bad things
will happen... (We will otherwise get a translation fault and a
permission fault and invalidate the I-cache as needed.)




  virt/kvm/arm/arm.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
index 48d0ec44ad77..e6378162cdef 100644
--- a/virt/kvm/arm/arm.c
+++ b/virt/kvm/arm/arm.c
@@ -983,8 +983,11 @@ static int kvm_arch_vcpu_ioctl_vcpu_init(struct kvm_vcpu 
*vcpu,
/*
 * Ensure a rebooted VM will fault in RAM pages and detect if the
 * guest MMU is turned off and flush the caches as needed.
+*
+* S2FWB enforces all memory accesses to RAM being cacheable, we
+* ensure that the cache is always coherent.
 */
-   if (vcpu->arch.has_run_once)
+   if (vcpu->arch.has_run_once && 
!cpus_have_const_cap(ARM64_HAS_STAGE2_FWB))

I think userspace does not invalidate the icache when loading a new kernel 
image,
and if the guest patched instructions, they could potentially still be in the
icache. Should the icache be invalidated if FWB is present?


I noticed that this was included in the current pull request and I remembered 
that
I wasn't sure about this part. Did some more digging and it turns out that FWB
implies no cache maintenance needed for *data to instruction* coherence. From 
ARM
DDI 0487F.b, page D5-2635:

"When ARMv8.4-S2FWB is implemented, the architecture requires that
CLIDR_EL1.{LOUU, LOIUS} are zero so that no levels of data cache need to be
cleaned in order to manage coherency with instruction fetches".

However, there's no mention that I found for instruction to data coherence,
meaning that the icache would still need to be invalidated on each vcpu in order
to prevent fetching of patched instructions from the icache. Am I missing 
something?


Thanks for the head up and Marc's fix!


Thanks both,
Zenghui

[PATCH] shmem, memcg: enable memcg aware shrinker

[Greg Thelen]

Since v4.19 commit b0dedc49a2da ("mm/vmscan.c: iterate only over charged
shrinkers during memcg shrink_slab()") a memcg aware shrinker is only
called when the per-memcg per-node shrinker_map indicates that the
shrinker may have objects to release to the memcg and node.

shmem_unused_huge_count and shmem_unused_huge_scan support the per-tmpfs
shrinker which advertises per memcg and numa awareness.  The shmem
shrinker releases memory by splitting hugepages that extend beyond
i_size.

Shmem does not currently set bits in shrinker_map.  So, starting with
b0dedc49a2da, memcg reclaim avoids calling the shmem shrinker under
pressure.  This leads to undeserved memcg OOM kills.
Example that reliably sees memcg OOM kill in unpatched kernel:
  FS=/tmp/fs
  CONTAINER=/cgroup/memory/tmpfs_shrinker
  mkdir -p $FS
  mount -t tmpfs -o huge=always nodev $FS
  # Create 1000 MB container, which shouldn't suffer OOM.
  mkdir $CONTAINER
  echo 1000M > $CONTAINER/memory.limit_in_bytes
  echo $BASHPID >> $CONTAINER/cgroup.procs
  # Create 4000 files.  Ideally each file uses 4k data page + a little
  # metadata.  Assume 8k total per-file, 32MB (4000*8k) should easily
  # fit within container's 1000 MB.  But if data pages use 2MB
  # hugepages (due to aggressive huge=always) then files consume 8GB,
  # which hits memcg 1000 MB limit.
  for i in {1..4000}; do
echo . > $FS/$i
  done

v5.4 commit 87eaceb3faa5 ("mm: thp: make deferred split shrinker memcg
aware") maintains the per-node per-memcg shrinker bitmap for THP
shrinker.  But there's no such logic in shmem.  Make shmem set the
per-memcg per-node shrinker bits when it modifies inodes to have
shrinkable pages.

Fixes: b0dedc49a2da ("mm/vmscan.c: iterate only over charged shrinkers during 
memcg shrink_slab()")
Cc:  # 4.19+
Signed-off-by: Greg Thelen 
---
 mm/shmem.c | 61 +++---
 1 file changed, 35 insertions(+), 26 deletions(-)

diff --git a/mm/shmem.c b/mm/shmem.c
index bd8840082c94..e11090f78cb5 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -1002,6 +1002,33 @@ static int shmem_getattr(const struct path *path, struct 
kstat *stat,
return 0;
 }
 
+/*
+ * Expose inode and optional page to shrinker as having a possibly splittable
+ * hugepage that reaches beyond i_size.
+ */
+static void shmem_shrinker_add(struct shmem_sb_info *sbinfo,
+  struct inode *inode, struct page *page)
+{
+   struct shmem_inode_info *info = SHMEM_I(inode);
+
+   spin_lock(&sbinfo->shrinklist_lock);
+   /*
+* _careful to defend against unlocked access to ->shrink_list in
+* shmem_unused_huge_shrink()
+*/
+   if (list_empty_careful(&info->shrinklist)) {
+   list_add_tail(&info->shrinklist, &sbinfo->shrinklist);
+   sbinfo->shrinklist_len++;
+   }
+   spin_unlock(&sbinfo->shrinklist_lock);
+
+#ifdef CONFIG_MEMCG
+   if (page && PageTransHuge(page))
+   memcg_set_shrinker_bit(page->mem_cgroup, page_to_nid(page),
+  inode->i_sb->s_shrink.id);
+#endif
+}
+
 static int shmem_setattr(struct dentry *dentry, struct iattr *attr)
 {
struct inode *inode = d_inode(dentry);
@@ -1048,17 +1075,13 @@ static int shmem_setattr(struct dentry *dentry, struct 
iattr *attr)
 * to shrink under memory pressure.
 */
if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) {
-   spin_lock(&sbinfo->shrinklist_lock);
-   /*
-* _careful to defend against unlocked access to
-* ->shrink_list in shmem_unused_huge_shrink()
-*/
-   if (list_empty_careful(&info->shrinklist)) {
-   list_add_tail(&info->shrinklist,
-   &sbinfo->shrinklist);
-   sbinfo->shrinklist_len++;
-   }
-   spin_unlock(&sbinfo->shrinklist_lock);
+   struct page *page;
+
+   page = find_get_page(inode->i_mapping,
+   (newsize & HPAGE_PMD_MASK) >> 
PAGE_SHIFT);
+   shmem_shrinker_add(sbinfo, inode, page);
+   if (page)
+   put_page(page);
}
}
}
@@ -1889,21 +1912,7 @@ static int shmem_getpage_gfp(struct inode *inode, 
pgoff_t index,
if (PageTransHuge(page) &&
DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE) <
hindex + HPAGE_PMD_NR - 1) {
-   /*
-* Part of the huge page is beyond i_size: subject
-* to shrink under memory pressure.
-

[PATCH RESEND] mm, swap: delete meaningless __add_to_swap_cache() declaration

[linmiaohe]

From: Miaohe Lin 

Since commit 8d93b41c09d1 ("mm: Convert add_to_swap_cache to XArray"),
__add_to_swap_cache and add_to_swap_cache are combined into one function.
There is no __add_to_swap_cache() anymore.

CC: Matthew Wilcox 
Reviewed-by: "Huang, Ying" 
Signed-off-by: Miaohe Lin 
---
 include/linux/swap.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/linux/swap.h b/include/linux/swap.h
index e1bbf7a16b27..d70e6017d835 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -408,7 +408,6 @@ extern unsigned long total_swapcache_pages(void);
 extern void show_swap_cache_info(void);
 extern int add_to_swap(struct page *page);
 extern int add_to_swap_cache(struct page *, swp_entry_t, gfp_t);
-extern int __add_to_swap_cache(struct page *page, swp_entry_t entry);
 extern void __delete_from_swap_cache(struct page *, swp_entry_t entry);
 extern void delete_from_swap_cache(struct page *);
 extern void free_page_and_swap_cache(struct page *);
-- 
2.19.1

[PATCH] soundwire: bus: clock_stop: don't deal with UNATTACHED Slave devices

[Bard Liao]

We don't need to do anything for the slave if it is unattached during
clock stop prepare and exit sequences.

Signed-off-by: Bard Liao 
---
 drivers/soundwire/bus.c | 23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
index 2289c2ac8c5a..405335fb790a 100644
--- a/drivers/soundwire/bus.c
+++ b/drivers/soundwire/bus.c
@@ -863,13 +863,13 @@ int sdw_bus_prep_clk_stop(struct sdw_bus *bus)
if (!slave->dev_num)
continue;
 
-   /* Identify if Slave(s) are available on Bus */
-   is_slave = true;
-
if (slave->status != SDW_SLAVE_ATTACHED &&
slave->status != SDW_SLAVE_ALERT)
continue;
 
+   /* Identify if Slave(s) are available on Bus */
+   is_slave = true;
+
slave_mode = sdw_get_clk_stop_mode(slave);
slave->curr_clk_stop_mode = slave_mode;
 
@@ -900,6 +900,10 @@ int sdw_bus_prep_clk_stop(struct sdw_bus *bus)
return ret;
}
 
+   /* Don't need to inform slaves if there is no slave attached */
+   if (!is_slave)
+   return ret;
+
/* Inform slaves that prep is done */
list_for_each_entry(slave, &bus->slaves, node) {
if (!slave->dev_num)
@@ -985,13 +989,13 @@ int sdw_bus_exit_clk_stop(struct sdw_bus *bus)
if (!slave->dev_num)
continue;
 
-   /* Identify if Slave(s) are available on Bus */
-   is_slave = true;
-
if (slave->status != SDW_SLAVE_ATTACHED &&
slave->status != SDW_SLAVE_ALERT)
continue;
 
+   /* Identify if Slave(s) are available on Bus */
+   is_slave = true;
+
mode = slave->curr_clk_stop_mode;
 
if (mode == SDW_CLK_STOP_MODE1) {
@@ -1016,6 +1020,13 @@ int sdw_bus_exit_clk_stop(struct sdw_bus *bus)
if (is_slave && !simple_clk_stop)
sdw_bus_wait_for_clk_prep_deprep(bus, SDW_BROADCAST_DEV_NUM);
 
+   /*
+* Don't need to call slave callback function if there is no slave
+* attached
+*/
+   if (!is_slave)
+   return 0;
+
list_for_each_entry(slave, &bus->slaves, node) {
if (!slave->dev_num)
continue;
-- 
2.17.1

Re: [PATCH V2] mm, memory_failure: don't send BUS_MCEERR_AO for action required error

[堀口 直也]

On Sat, May 30, 2020 at 09:08:43AM +0200, Pankaj Gupta wrote:
> > Some processes dont't want to be killed early, but in "Action Required"
> > case, those also may be killed by BUS_MCEERR_AO when sharing memory
> > with other which is accessing the fail memory.
> > And sending SIGBUS with BUS_MCEERR_AO for action required error is
> > strange, so ignore the non-current processes here.
> >
> > Suggested-by: Naoya Horiguchi 
> > Signed-off-by: Wetp Zhang 
> > ---
> >  mm/memory-failure.c | 15 +--
> >  1 file changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> > index a96364be8ab4..dd3862fcf2e9 100644
> > --- a/mm/memory-failure.c
> > +++ b/mm/memory-failure.c
> > @@ -210,14 +210,17 @@ static int kill_proc(struct to_kill *tk, unsigned 
> > long pfn, int flags)
> >  {
> > struct task_struct *t = tk->tsk;
> > short addr_lsb = tk->size_shift;
> > -   int ret;
> > +   int ret = 0;
> >
> > -   pr_err("Memory failure: %#lx: Sending SIGBUS to %s:%d due to 
> > hardware memory corruption\n",
> > -   pfn, t->comm, t->pid);
> > +   if ((t->mm == current->mm) || !(flags & MF_ACTION_REQUIRED))
> > +   pr_err("Memory failure: %#lx: Sending SIGBUS to %s:%d due 
> > to hardware memory corruption\n",
> > +   pfn, t->comm, t->pid);
> 
> Maybe we can generalize the message condition for better readability.
> Thought a bit but did not get any other idea.

This odd condition might imply that we could have better fix in
task_early_kill(), but that should come after fixing priority issue of
early-kill flag, so let's go with this fix for now.

> >
> > -   if ((flags & MF_ACTION_REQUIRED) && t->mm == current->mm) {
> > -   ret = force_sig_mceerr(BUS_MCEERR_AR, (void __user 
> > *)tk->addr,
> > -  addr_lsb);
> > +   if (flags & MF_ACTION_REQUIRED) {
> > +   if (t->mm == current->mm)
> > +   ret = force_sig_mceerr(BUS_MCEERR_AR,
> > +(void __user *)tk->addr, addr_lsb);
> > +   /* send no signal to non-current processes */
> > } else {
> > /*
> >  * Don't use force here, it's convenient if the signal
> > --
> 
> Looks good to me.
> Acked-by: Pankaj Gupta 

Thanks!

Acked-by: Naoya Horiguchi 

Re: [PATCH v3 07/18] nitro_enclaves: Init misc device providing the ioctl interface

[Benjamin Herrenschmidt]

On Thu, 2020-05-28 at 15:12 +0200, Greg KH wrote:
> So at runtime, after all is booted and up and going, you just ripped
> cores out from under someone's feet?  :)
> 
> And the code really handles writing to that value while the module is
> already loaded and up and running?  At a quick glance, it didn't seem
> like it would handle that very well as it only is checked at ne_init()
> time.
> 
> Or am I missing something?
> 
> Anyway, yes, if you can dynamically do this at runtime, that's great,
> but it feels ackward to me to rely on one configuration thing as a
> module parameter, and everything else through the ioctl interface.
> Unification would seem to be a good thing, right?

I personally still prefer a sysfs file :) I really don't like module
parameters as a way to do such things.

Cheers,
Ben.

Re: [PATCH] sh: Implement __get_user_u64() required for 64-bit get_user()

[Rich Felker]

On Sun, May 31, 2020 at 12:43:11PM +0200, Geert Uytterhoeven wrote:
> Hi Adrian,
> 
> On Sun, May 31, 2020 at 11:59 AM John Paul Adrian Glaubitz
>  wrote:
> > On 5/31/20 11:54 AM, John Paul Adrian Glaubitz wrote:
> > > On 5/31/20 11:52 AM, Geert Uytterhoeven wrote:
> > >> As this is the 64-bit variant, I think this single move should be
> > >> replaced by a double move:
> > >>
> > >>"mov  #0,%R1\n\t" \
> > >>"mov  #0,%S1\n\t" \
> > >>
> > >> Same for the big endian version below.
> > >>
> > >> Disclaimer: uncompiled, untested, no SH assembler expert.
> > >
> > > Right, this makes sense. I'll send a new patch shortly.
> >
> > Hmm, this change is not the case for __put_user_asm() vs. __put_user_u64().
> > But I have to admit, I don't know what the part below "3:\n\t" is for.
> 
> It's part of the exception handling, in case the passed (userspace) pointer
> points to an inaccessible address, and triggers an exception.
> 
> For an invalid store, nothing is done, besides returning -EFAULT.
> Hence there's no "mov #0, %1\n\t" in the put_user case.
> For an invalid load, the data is replaced by zero, and -EFAULT is returned.
> 
> > +__asm__ __volatile__( \
> > +   "1:\n\t" \
> > +   "mov.l  %2,%R1\n\t" \
> > +   "mov.l  %T2,%S1\n\t" \
> > +   "2:\n" \
> 
> (reordering the two sections for easier explanation)
> 
> > +   ".section   __ex_table,\"a\"\n\t" \
> > +   ".long  1b, 3b\n\t" \
> 
> In case an exception happens for the instruction at 1b, jump to 3b.
> 
> Note that the m68k version has two entries here: one for each half of
> the 64-bit access[*].
> I don't know if that is really needed (and thus SH needs it, too), or if
> the exception code handles subsequent instructions automatically.

Can I propose a different solution? For archs where there isn't
actually any 64-bit load or store instruction, does it make sense to
be writing asm just to do two 32-bit loads/stores, especially when
this code is not in a hot path?

What about just having the 64-bit versions call the corresponding
32-bit version twice? (Ideally this would even be arch-generic and
could replace the m68k asm.) It would return EFAULT if either of the
32-bit calls did.

Rich

[PATCH] f2fs: protect new segment allocation in expand_inode_data

[Daeho Jeong]

From: Daeho Jeong 

Found a new segemnt allocation without f2fs_lock_op() in
expand_inode_data(). So, when we do fallocate() for a pinned file
and trigger checkpoint very frequently and simultaneously. F2FS gets
stuck in the below code of do_checkpoint() forever.

  f2fs_sync_meta_pages(sbi, META, LONG_MAX, FS_CP_META_IO);
  /* Wait for all dirty meta pages to be submitted for IO */
<= if fallocate() here,
  f2fs_wait_on_all_pages(sbi, F2FS_DIRTY_META); <= it'll wait forever.

Signed-off-by: Daeho Jeong 
Reviewed-by: Chao Yu 
---
 fs/f2fs/file.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index f7de2a1da528..14ace885baa9 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -1660,7 +1660,11 @@ static int expand_inode_data(struct inode *inode, loff_t 
offset,
 
down_write(&sbi->pin_sem);
map.m_seg_type = CURSEG_COLD_DATA_PINNED;
+
+   f2fs_lock_op(sbi);
f2fs_allocate_new_segments(sbi, CURSEG_COLD_DATA);
+   f2fs_unlock_op(sbi);
+
err = f2fs_map_blocks(inode, &map, 1, F2FS_GET_BLOCK_PRE_DIO);
up_write(&sbi->pin_sem);
 
-- 
2.27.0.rc0.183.gde8f92d652-goog

Re: [PATCH v3 01/18] nitro_enclaves: Add ioctl interface definition

[Benjamin Herrenschmidt]

On Wed, 2020-05-27 at 09:49 +0100, Stefan Hajnoczi wrote:
> 
> What about feature bits or a API version number field? If you add
> features to the NE driver, how will userspace detect them?
> 
> Even if you intend to always compile userspace against the exact kernel
> headers that the program will run on, it can still be useful to have an
> API version for informational purposes and to easily prevent user
> errors (running a new userspace binary on an old kernel where the API is
> different).
> 
> Finally, reserved struct fields may come in handy in the future. That
> way userspace and the kernel don't need to explicitly handle multiple
> struct sizes.

Beware, Greg might disagree :)

That said, yes, at least a way to query the API version would be
useful.

Cheers,
Ben.

Re: [PATCH v3 07/18] nitro_enclaves: Init misc device providing the ioctl interface

[Benjamin Herrenschmidt]

On Wed, 2020-05-27 at 00:24 +0200, Greg KH wrote:
> > Would you want random users to get the ability to hot unplug CPUs from your
> > system? At unlimited quantity? I don't :).
> 
> A random user, no, but one with admin rights, why not?  They can do that
> already today on your system, this isn't new.

So I agree with you that a module parameter sucks. I disagree on the
ioctl :)

This is the kind of setup task that will probably end up being done by
some shell script at boot time based on some config file. Being able to
echo something in a sysfs file which will parse the standard-format CPU
list using the existing kernel functions to turn that into a cpu_mask
makes a lot more sense than having a binary interface via an ioctl
which will require an extra userspace program for use by the admin for
that one single task.

So sysfs is my preference here.

Another approach would be configfs, which would provide a more flexible
interface to potentially create multiple "CPU sets" that could be given
to different users or classes of users etc... but that might be pushing
it, I don't know.

Cheers,
Ben.

Re: [PATCH v3 02/18] nitro_enclaves: Define the PCI device interface

[Benjamin Herrenschmidt]

On Wed, 2020-05-27 at 00:21 +0200, Greg KH wrote:
> > There are a couple of data structures with more than one member and multiple
> > field sizes. And for the ones that are not, gathered as feedback from
> > previous rounds of review that should consider adding a "flags" field in
> > there for further extensibility.
> 
> Please do not do that in ioctls.  Just create new calls instead of
> trying to "extend" existing ones.  It's always much easier.
> 
> > I can modify to have "__packed" instead of the attribute callout.
> 
> Make sure you even need that, as I don't think you do for structures
> like the above one, right?

Hrm, my impression (granted I only just started to look at this code)
is that these are protocol messages with the PCI devices, not strictly
just ioctl arguments (though they do get conveyed via such ioctls).

Andra-Irina, did I get that right ? :-)

That said, I still think that by carefully ordering the fields and
using explicit padding, we can avoid the need of the packed attributed.

Cheers,
Ben.

[GIT PULL] pstore updates for v5.8-rc1

[Kees Cook]

Hi Linus,

Please pull these pstore updates for v5.8-rc1. This is a pretty big set
of changes (relative to past pstore pulls), but they've lived in -next
for a while. The biggest change here is the ability to support a block
device as a pstore backend, which has been desired for a while. A lot of
additional fixes and refactorings are also included, mostly in support
of the new features.

Thanks!

-Kees

The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:

  Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git 
tags/pstore-v5.8-rc1

for you to fetch changes up to 78c08247b9d3e03192f8b359aa079024e805a948:

  mtd: Support kmsg dumper based on pstore/blk (2020-05-31 19:49:01 -0700)


Fixes and new features for pstore

- refactor pstore locking for safer module unloading (Kees Cook)
- remove orphaned records from pstorefs when backend unloaded (Kees Cook)
- refactor dump_oops parameter into max_reason (Pavel Tatashin)
- introduce pstore/zone for common code for contiguous storage (WeiXiong Liao)
- introduce pstore/blk for block device backend (WeiXiong Liao)
- introduce mtd backend (WeiXiong Liao)


Kees Cook (22):
  pstore: Drop useless try_module_get() for backend
  pstore: Rename "pstore_lock" to "psinfo_lock"
  pstore: Convert "psinfo" locking to mutex
  pstore: Rename "allpstore" to "records_list"
  pstore: Convert "records_list" locking to mutex
  pstore: Add proper unregister lock checking
  pstore: Refactor pstorefs record list removal
  pstore: Add locking around superblock changes
  pstore: Do not leave timer disabled for next backend
  pstore: Remove filesystem records when backend is unregistered
  pstore: Make sure console capturing will restart
  pstore/platform: Switch pstore_info::name to const
  pstore/platform: Use backend name for console registration
  pstore/platform: Move module params after declarations
  pstore/ram: Adjust module param permissions to reflect reality
  pstore/ram: Refactor DT size parsing
  pstore/ram: Refactor ftrace buffer merging
  pstore/ftrace: Provide ftrace log merging routine
  printk: Collapse shutdown types into a single dump reason
  printk: Introduce kmsg_dump_reason_str()
  pstore/ram: Introduce max_reason and convert dump_oops
  pstore/blk: Introduce "best_effort" mode

Pavel Tatashin (3):
  printk: honor the max_reason field in kmsg_dumper
  pstore/platform: Pass max_reason to kmesg dump
  ramoops: Add "max-reason" optional field to ramoops DT node

WeiXiong Liao (10):
  pstore/zone: Introduce common layer to manage storage zones
  pstore/blk: Introduce backend for block devices
  pstore/zone,blk: Add support for pmsg frontend
  pstore/zone,blk: Add console frontend support
  pstore/zone,blk: Add ftrace frontend support
  Documentation: Add details for pstore/blk
  pstore/zone: Provide way to skip "broken" zone for MTD devices
  pstore/blk: Provide way to query pstore configuration
  pstore/blk: Support non-block storage devices
  mtd: Support kmsg dumper based on pstore/blk

 Documentation/admin-guide/pstore-blk.rst   |  243 
 Documentation/admin-guide/ramoops.rst  |   14 +-
 .../bindings/reserved-memory/ramoops.txt   |   13 +-
 MAINTAINERS|1 +
 arch/powerpc/kernel/nvram_64.c |4 +-
 drivers/mtd/Kconfig|   10 +
 drivers/mtd/Makefile   |1 +
 drivers/mtd/mtdpstore.c|  578 
 drivers/platform/chrome/chromeos_pstore.c  |2 +-
 fs/pstore/Kconfig  |  109 ++
 fs/pstore/Makefile |6 +
 fs/pstore/blk.c|  517 +++
 fs/pstore/ftrace.c |   54 +
 fs/pstore/inode.c  |  129 +-
 fs/pstore/internal.h   |   11 +-
 fs/pstore/platform.c   |  117 +-
 fs/pstore/ram.c|  155 +--
 fs/pstore/zone.c   | 1465 
 include/linux/kmsg_dump.h  |   12 +-
 include/linux/pstore.h |9 +-
 include/linux/pstore_blk.h |  118 ++
 include/linux/pstore_ram.h |2 +-
 include/linux/pstore_zone.h|   60 +
 kernel/printk/printk.c |   32 +-
 kernel/reboot.c|6 +-
 tools/testing/selftests/pstore/pstore_tests|  

Re: [PATCH v3 04/18] nitro_enclaves: Init PCI device driver

[Benjamin Herrenschmidt]

On Tue, 2020-05-26 at 21:35 +0300, Paraschiv, Andra-Irina wrote:
> This was needed to have an identifier for the overall NE logic - PCI 
> dev, ioctl and misc dev.
> 
> The ioctl and misc dev logic has pr_* logs, but I can update them to 
> dev_* with misc dev, then remove this prefix.

Or #define pr_fmt, but dev_ is better.

Cheers,
Ben.

Re: [GIT PULL] sh: remove sh5 support

[Rich Felker]

On Sun, May 31, 2020 at 10:03:13AM +0200, John Paul Adrian Glaubitz wrote:
> On 5/31/20 5:20 AM, Rob Landley wrote:
> > On 5/30/20 3:08 AM, John Paul Adrian Glaubitz wrote:
> >> On 5/29/20 7:53 PM, Rich Felker wrote:
> >>> Frustratingly, I _still_ don't have an official tree on kernel.org for
> >>> the purpose of being the canonical place for linux-next to pull from,
> >>> due to policies around pgp keys and nobody following up on signing
> >>> mine. This is all really silly since there are ridiculously many
> >>> independent channels I could cryptographically validate identity
> >>> through with vanishing probability that they're all compromised. For
> >>> the time being I'll reactivate my repo on git.musl-libc.org.
> >>
> >> May I suggest to pick up these patches, for example? There might be
> >> more I missed, but getting these merged should already help a lot with
> >> the clean-up of arch/sh.
> > 
> > Does that include the 2 fixes to build with current binutils I made puppy 
> > eyes
> > about last -rc7 (in march)?
> > 
> > https://marc.info/?l=linux-sh&m=158544749818664&w=2
> Yes, listed as "[PATCH 1/2] arch/sh: vmlinux.scr".
> 
> @Rich: Do you think you can merge all those fixes in your local tree within
>the next days and send a PR to Linus?
> 
> Otherwise, I can volunteer to become a third maintainer for arch/sh as I have
> the hardware for testing and can accept patches and send PRs.
> 
> We shouldn't let contributors to arch/sh wait for too long.

Yes, I'll try to get my tree ready for next/PR use tomorrow.

Rich

Re: [PATCH v3 02/18] nitro_enclaves: Define the PCI device interface

[Benjamin Herrenschmidt]

On Tue, 2020-05-26 at 20:01 +0300, Paraschiv, Andra-Irina wrote:
> 
> On 26/05/2020 09:44, Greg KH wrote:
> > On Tue, May 26, 2020 at 01:13:18AM +0300, Andra Paraschiv wrote:
> > > +struct enclave_get_slot_req {
> > > + /* Context ID (CID) for the enclave vsock device. */
> > > + u64 enclave_cid;
> > > +} __attribute__ ((__packed__));
> > 
> > Can you really "pack" a single member structure?
> > 
> > Anyway, we have better ways to specify this instead of the "raw"
> > __attribute__ option.  But first see if you really need any of
> > these, at
> > first glance, I do not think you do at all, and they can all be
> > removed.
> 
> There are a couple of data structures with more than one member and 
> multiple field sizes. And for the ones that are not, gathered as 
> feedback from previous rounds of review that should consider adding
> a 
> "flags" field in there for further extensibility.
> 
> I can modify to have "__packed" instead of the attribute callout.

I tend to prefer designing the protocol so that all the fields are
naturally aligned, which should avoid the need for the attribute. Is
it possible in this case ?

Cheers,
Ben.

Re: [PATCH v3 07/18] nitro_enclaves: Init misc device providing the ioctl interface

[Benjamin Herrenschmidt]

On Tue, 2020-05-26 at 14:44 +0200, Alexander Graf wrote:
> So I really don't think an ioctl would be a great user experience. Same 
> for a sysfs file - although that's probably slightly better than the ioctl.

What would be wrong with a sysfs file ?

Another way to approach that makes sense from a kernel perspective is
to have the user first offline the CPUs, then "donate" them to the
driver via a sysfs file.

> Other options I can think of:
> 
>* sysctl (for modules?)

Why would that be any good ? If anything sysctl's are even more awkward
in my book :)

>* module parameter (as implemented here)
>* proc file (deprecated FWIW)

Yeah no.

> The key is the tenant split: Admin sets the pool up, user consumes. This 
> setup should happen (early) on boot, so that system services can spawn 
> enclaves.

Right and you can have some init script or udev rule that sets that up
from a sys admin produced config file at boot upon detection of the
enclave PCI device for example.

> > module parameters are a major pain, you know this :)
> 
> I think in this case it's the least painful option ;). But I'm really 
> happy to hear about an actually good alternative to it. Right now, I 
> just can't think of any.

Cheers,
Ben.

Re: [PATCH] iommu/amd: Fix event counter availability check

[Paul Menzel]

Dear Alexander,


Thank you very much for the patch.


Am 31.05.20 um 09:22 schrieb Alexander Monakov:


Adding Shuah Khan to Cc: I've noticed you've seen this issue on Ryzen 2400GE;
can you have a look at the patch? Would be nice to know if it fixes the
problem for you too.



On Fri, 29 May 2020, Alexander Monakov wrote:


The driver performs an extra check if the IOMMU's capabilities advertise
presence of performance counters: it verifies that counters are writable
by writing a hard-coded value to a counter and testing that reading that
counter gives back the same value.

Unfortunately it does so quite early, even before pci_enable_device is
called for the IOMMU, i.e. when accessing its MMIO space is not
guaranteed to work. On Ryzen 4500U CPU, this actually breaks the test:
the driver assumes the counters are not writable, and disables the
functionality.

Moving init_iommu_perf_ctr just after iommu_flush_all_caches resolves
the issue. This is the earliest point in amd_iommu_init_pci where the
call succeeds on my laptop.

Signed-off-by: Alexander Monakov 
Cc: Joerg Roedel 
Cc: Suravee Suthikulpanit 
Cc: io...@lists.linux-foundation.org
---

PS. I'm seeing another hiccup with IOMMU probing on my system:
pci :00:00.2: can't derive routing for PCI INT A
pci :00:00.2: PCI INT A: not connected

Hopefully I can figure it out, but I'd appreciate hints.


I guess it’s a firmware bug, but I contacted the linux-pci folks [1].


  drivers/iommu/amd_iommu_init.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index 5b81fd16f5fa..1b7ec6b6a282 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -1788,8 +1788,6 @@ static int __init iommu_init_pci(struct amd_iommu *iommu)
if (iommu->cap & (1UL << IOMMU_CAP_NPCACHE))
amd_iommu_np_cache = true;
  
-	init_iommu_perf_ctr(iommu);

-
if (is_rd890_iommu(iommu->dev)) {
int i, j;
  
@@ -1891,8 +1889,10 @@ static int __init amd_iommu_init_pci(void)
  
  	init_device_table_dma();
  
-	for_each_iommu(iommu)

+   for_each_iommu(iommu) {
iommu_flush_all_caches(iommu);
+   init_iommu_perf_ctr(iommu);
+   }
  
  	if (!ret)

print_iommu_info();

base-commit: 75caf310d16cc5e2f851c048cd597f5437013368


Thank you very much for fixing this issue, which is almost two years old 
for me.


Tested-by: Paul Menzel 
MSI MSI MS-7A37/B350M MORTAR with AMD Ryzen 3 2200G
Link: https://lore.kernel.org/linux-iommu/20180727102710.ga6...@8bytes.org/


Kind regards,

Paul


[1]: 
https://lore.kernel.org/linux-pci/8579bd14-e369-1141-917b-204d20cff...@molgen.mpg.de/

Re: [PATCH v3 07/18] nitro_enclaves: Init misc device providing the ioctl interface

[Benjamin Herrenschmidt]

On Tue, 2020-05-26 at 08:51 +0200, Greg KH wrote:
> 
> And get them to sign off on it too, showing they agree with the design
> decisions here :)

Isn't it generally frowned upon to publish a patch with internal sign-
off's on it already ? Or do you mean for us to publicly sign off once
we have reviewed ?

Cheers,
Ben.

[GIT PULL] Crypto Update for 5.8

[Herbert Xu]

Hi Linus:

API:

- Introduce crypto_shash_tfm_digest() and use it wherever possible.
- Fix use-after-free and race in crypto_spawn_alg.
- Add support for parallel and batch requests to crypto_engine.

Algorithms:

- Update jitter RNG for SP800-90B compliance.
- Always use jitter RNG as seed in drbg.

Drivers:

- Add Arm CryptoCell driver cctrng.
- Add support for SEV-ES to the PSP driver in ccp.

The following changes since commit 55b3209acbb01cb02b1ee6b1afe80d83b1aab36d:

  crypto: caam - fix the address of the last entry of S/G (2020-04-16 16:48:56 
+1000)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus 

for you to fetch changes up to 58ca0060ec4e51208d2eee12198fc55fd9e4feb3:

  crypto: hisilicon - fix driver compatibility issue with different versions of 
devices (2020-05-28 17:27:52 +1000)


Andy Shevchenko (1):
  hwrng: optee - Use UUID API for exporting the UUID

Arnd Bergmann (3):
  crypto: ccp -- don't "select" CONFIG_DMADEVICES
  crypto - Avoid free() namespace collision
  crypto: blake2b - Fix clang optimization for ARMv7-M

Barry Song (1):
  crypto: acomp - search acomp with scomp backend in crypto_has_acomp

Christophe JAILLET (2):
  crypto: marvell/octeontx - Add missing '\n' in log messages
  crypto: cavium/nitrox - Fix a typo in a comment

Colin Ian King (2):
  crypto: chelsio - remove redundant assignment to variable error
  crypto: algif_rng - remove redundant assignment to variable err

Corentin Labbe (2):
  crypto: ctr - no longer needs CRYPTO_SEQIV
  crypto: drbg - should select CTR

Daniel Jordan (1):
  padata: add separate cpuhp node for CPUHP_PADATA_DEAD

Eric Biggers (29):
  crypto: algapi - Avoid spurious modprobe on LOADED
  crypto: lib/sha256 - return void
  crypto: hash - introduce crypto_shash_tfm_digest()
  crypto: arm64/aes-glue - use crypto_shash_tfm_digest()
  crypto: essiv - use crypto_shash_tfm_digest()
  crypto: artpec6 - use crypto_shash_tfm_digest()
  crypto: ccp - use crypto_shash_tfm_digest()
  crypto: ccree - use crypto_shash_tfm_digest()
  crypto: hisilicon/sec2 - use crypto_shash_tfm_digest()
  crypto: mediatek - use crypto_shash_tfm_digest()
  crypto: n2 - use crypto_shash_tfm_digest()
  crypto: omap-sham - use crypto_shash_tfm_digest()
  crypto: s5p-sss - use crypto_shash_tfm_digest()
  nfc: s3fwrn5: use crypto_shash_tfm_digest()
  fscrypt: use crypto_shash_tfm_digest()
  ecryptfs: use crypto_shash_tfm_digest()
  nfsd: use crypto_shash_tfm_digest()
  ubifs: use crypto_shash_tfm_digest()
  Bluetooth: use crypto_shash_tfm_digest()
  sctp: use crypto_shash_tfm_digest()
  KEYS: encrypted: use crypto_shash_tfm_digest()
  ASoC: cros_ec_codec: use crypto_shash_tfm_digest()
  mptcp: use SHA256_BLOCK_SIZE, not SHA_MESSAGE_BYTES
  crypto: powerpc/sha1 - remove unused temporary workspace
  crypto: powerpc/sha1 - prefix the "sha1_" functions
  crypto: s390/sha1 - prefix the "sha1_" functions
  crypto: lib/sha1 - rename "sha" to "sha1"
  crypto: lib/sha1 - remove unnecessary includes of linux/cryptohash.h
  crypto: lib/sha1 - fold linux/cryptohash.h into crypto/sha.h

Etienne Carriere (2):
  crypto: stm32/hash - defer probe for reset controller
  crypto: stm32/hash - defer probe for dma device

Hadar Gat (7):
  dt-bindings: add device tree binding for Arm CryptoCell trng engine
  hwrng: cctrng - introduce Arm CryptoCell driver
  MAINTAINERS: add HG as cctrng maintainer
  hwrng: cctrng - add missing include to linux/fips.h
  hwrng: cctrng - Add dependency on OF
  hwrng: cctrng - change default to n
  hwrng: cctrng - update help description

Hao Fang (1):
  crypto: hisilicon - add vfs_num module parameter for hpre/sec

Herbert Xu (4):
  crypto: api - Fix use-after-free and race in crypto_spawn_alg
  hwrng: cctrng - Add dependency on HAS_IOMEM
  hwrng: cctrng - Remove unnecessary FIPS ifdef
  Revert "ASoC: cros_ec_codec: use crypto_shash_tfm_digest()"

Hui Tang (2):
  crypto: hisilicon/hpre - add controller reset support for HPRE
  crypto: hisilicon/hpre - add debugfs for Hisilicon HPRE

Iuliana Prodan (4):
  crypto: algapi - create function to add request in front of queue
  crypto: engine - support for parallel requests based on retry mechanism
  crypto: engine - support for batch requests
  crypto: engine - do not requeue in case of fatal error

Kai Ye (1):
  crypto: hisilicon/sec2 - add debugfs for Hisilicon SEC

Lionel Debieve (1):
  crypto: stm32/hash - don't print error on probe deferral

Longfang Liu (6):
  crypto: hisilicon/sec2 - modify the SEC probe process
  crypto: hisilicon/hpre - modify the HPRE probe process
  crypto: hisilicon/zip - modify the ZIP probe process
  c

Re: [PATCH] irqchip/gic-v3-its: Don't try to move a disabled irq

[Herrenschmidt, Benjamin]

On Sun, 2020-05-31 at 12:09 +0100, Marc Zyngier wrote:
> 
> 
> > Not great indeed. But this is not, as far as I can tell, a GIC
> > driver problem.
> > 
> > The semantic of activate/deactivate (which maps to started/shutdown
> > in the IRQ code) is that the HW resources for a given interrupt are
> > only committed when the interrupt is activated. Trying to perform
> > actions involving the HW on an interrupt that isn't active cannot be
> > guaranteed to take effect.
> > 
> > I'd rather address it in the core code, by preventing set_affinity (and
> > potentially others) to take place when the interrupt is not in the
> > STARTED state. Userspace would get an error, which is perfectly
> > legitimate, and which it already has to deal with it for plenty of
> > other
> > reasons.

So I finally found time to dig a bit in there :) Code has changed a bit
since last I looked. But I have memories of the startup code messing
around with the affinity, and here it is. In irq_startup() :


switch (__irq_startup_managed(desc, aff, force)) {
case IRQ_STARTUP_NORMAL:
ret = __irq_startup(desc);
irq_setup_affinity(desc);
break;
case IRQ_STARTUP_MANAGED:
irq_do_set_affinity(d, aff, false);
ret = __irq_startup(desc);
break;
case IRQ_STARTUP_ABORT:
irqd_set_managed_shutdown(d);
return 0;

So we have two cases here. Normal and managed.

In the managed case, we set the affinity before startup. I feel like your
patch might break that or am I missing something ?

Additionally, your patch would break any userspace program that expects to
be able to change the affinity on an interrupt before it's been started.
I don't know if such a thing exsits but the fact that we hit that bug
makes me think it might.

Now most controller drivers (at least that I'm familiar with, which doesn't
include GiC at this point) can deal with that just fine.

Now there's also another possible issue:

Your patch checks irqd_is_started(). Now I always mixup irqd vs irq_state these
days so I may be wrong but irq_state_set_started() is only done in __irq_startup
which will *not* be called if the interrupt has NOAUTOEN.

Is that ok ? Do we intend for affinity setting not to work until the first
enable_irq() for such an interrupt ? We could check activated instead of
started I suppose. (again provided I didn't mixup two different things
between the irqd and the irq_state stuff).

For these reasons my gut feeling is we should just fix GIC as Ali wanted to
do initially.

The basic idea is simply to defer the HW configuration until the interrupt
has been started. I don't see why that would be an issue. Have set_affinity just
store the mask (and apply whatever other sanity checking it might want to do)
until the itnerrupt is started and when started, apply things to HW.

I might be missing a reason why it's more complicated than that :) But I do
feel a bit uncomfortable with your approach.

Cheers,
Ben.

Re: [PATCH v6] support gce on mt6779 platform

[Dennis-YC Hsieh]

Hi Jassi,

Thanks for your comment

On Sat, 2020-05-30 at 15:34 -0500, Jassi Brar wrote:
> On Thu, May 28, 2020 at 12:05 PM Dennis YC Hsieh
>  wrote:
> >
> > This patch support gce on mt6779 platform.
> >
> > Change since v5:
> > - spearate address shift code in client helper and mailbox controller
> > - separate write_s/write_s_mask and write_s_value/write_s_mask_value so that
> >   client can decide use mask or not
> > - fix typo in header
> >
> > Change since v4:
> > - do not clear disp event again in drm driver
> > - symbolize value 1 to jump relative
> >
> > [... snip ...]
> >
> >
> >
> > Dennis YC Hsieh (16):
> >   dt-binding: gce: add gce header file for mt6779
> >   mailbox: cmdq: variablize address shift in platform
> >   mailbox: cmdq: support mt6779 gce platform definition
> >   mailbox: mediatek: cmdq: clear task in channel before shutdown
> >   soc: mediatek: cmdq: return send msg error code
> >   soc: mediatek: cmdq: add address shift in jump
> >   soc: mediatek: cmdq: add assign function
> >   soc: mediatek: cmdq: add write_s function
> >   soc: mediatek: cmdq: add write_s_mask function
> >   soc: mediatek: cmdq: add read_s function
> >   soc: mediatek: cmdq: add write_s value function
> >   soc: mediatek: cmdq: add write_s_mask value function
> >   soc: mediatek: cmdq: export finalize function
> >   soc: mediatek: cmdq: add jump function
> >   soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api
> >   soc: mediatek: cmdq: add set event function
> >
> >  .../devicetree/bindings/mailbox/mtk-gce.txt   |   8 +-
> >  drivers/gpu/drm/mediatek/mtk_drm_crtc.c   |   3 +-
> >  drivers/mailbox/mtk-cmdq-mailbox.c| 101 ++--
> >  drivers/soc/mediatek/mtk-cmdq-helper.c| 163 -
> >  include/dt-bindings/gce/mt6779-gce.h  | 222 ++
> >  include/linux/mailbox/mtk-cmdq-mailbox.h  |  10 +-
> >  include/linux/soc/mediatek/mtk-cmdq.h | 125 +-
> >
> Please break the patchset into two. The lower mailbox related changes
> with soc changes on top.

Ok, I'll separate patches into two patchset, thanks.


Regards,
Dennis

> 
> thanks

Re: [PATCH v9 2/8] tpm: tpm_tis: Fix expected bit handling and send all bytes in one shot without last byte in exception

[Jarkko Sakkinen]

On Tue, May 26, 2020 at 05:16:52PM +0300, amirmi...@gmail.com wrote:
> From: Amir Mizinski 
> 
> Incorrect implementation of send message was detected. We polled only
> TPM_STS.stsValid bit and then we single-checked the TPM_STS.expect bit
> value.
> TPM_STS.expected bit should be checked at the same time as
> TPM_STS.stsValid bit, and this should be repeated until timeout_A.

I don't understand what the first paragraph is trying to say. It does
not conclude to anything. Please write instead soemthing that explains
what is going on.

> To detect a TPM_STS.expected bit reset, the "wait_for_tpm_stat" function is
> modified to "wait_for_tpm_stat_result". This function regularly reads the
> status register and check the bits defined by "mask" to reach the value
> defined in "mask_result".

Please remove this and explain instead how are you are changing the
existing function.

> This correct implementation is required for using the new CRC calculation
> on I2C TPM command bytes or I2C TPM answer bytes. TPM_STS.expected bit is
> reset after all bytes are acquired and the CRC result is inserted in the
> dedicated register. It introduces a normal latency for TPM_STS.expected
> bit reset.
> 
> Respectively, to send a message, as defined in
> TCG_DesignPrinciples_TPM2p0Driver_vp24_pubrev.pdf, all bytes should be
> sent in one shot instead of sending the last byte separately.
> 
> Suggested-by: Benoit Houyere 
> Signed-off-by: Amir Mizinski 
> ---
>  drivers/char/tpm/tpm_tis_core.c | 74 
> +
>  1 file changed, 30 insertions(+), 44 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
> index 27c6ca0..c725b68 100644
> --- a/drivers/char/tpm/tpm_tis_core.c
> +++ b/drivers/char/tpm/tpm_tis_core.c
> @@ -44,9 +44,10 @@ static bool wait_for_tpm_stat_cond(struct tpm_chip *chip, 
> u8 mask,
>   return false;
>  }
>  
> -static int wait_for_tpm_stat(struct tpm_chip *chip, u8 mask,
> - unsigned long timeout, wait_queue_head_t *queue,
> - bool check_cancel)
> +static int wait_for_tpm_stat_result(struct tpm_chip *chip, u8 mask,
> + u8 mask_result, unsigned long timeout,
> + wait_queue_head_t *queue,
> + bool check_cancel)

Please do not change the function name.

/Jarkko

Re: [PATCH 25/30] KVM: nSVM: leave guest mode when clearing EFER.SVME

[Krish Sadhukhan]

On 5/29/20 8:39 AM, Paolo Bonzini wrote:

According to the AMD manual, the effect of turning off EFER.SVME while a
guest is running is undefined.  We make it leave guest mode immediately,
similar to the effect of clearing the VMX bit in MSR_IA32_FEAT_CTL.



I see that svm_set_efer() is called in enter_svm_guest_mode() and 
nested_svm_vmexit(). In the VMRUN path, we have already checked 
EFER.SVME in nested_vmcb_checks(). So if it was not set, we wouldn't 
come to enter_svm_guest_mode(). Your fix is only for the #VMEXIT path then ?




Signed-off-by: Paolo Bonzini 
---
  arch/x86/kvm/svm/nested.c | 16 
  arch/x86/kvm/svm/svm.c| 10 --
  arch/x86/kvm/svm/svm.h|  1 +
  3 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c
index bd3a89cd4070..369eca73fe3e 100644
--- a/arch/x86/kvm/svm/nested.c
+++ b/arch/x86/kvm/svm/nested.c
@@ -618,6 +618,22 @@ int nested_svm_vmexit(struct vcpu_svm *svm)
return 0;
  }
  
+/*

+ * Forcibly leave nested mode in order to be able to reset the VCPU later on.
+ */
+void svm_leave_nested(struct vcpu_svm *svm)
+{
+   if (is_guest_mode(&svm->vcpu)) {
+   struct vmcb *hsave = svm->nested.hsave;
+   struct vmcb *vmcb = svm->vmcb;
+
+   svm->nested.nested_run_pending = 0;
+   leave_guest_mode(&svm->vcpu);
+   copy_vmcb_control_area(&vmcb->control, &hsave->control);
+   nested_svm_uninit_mmu_context(&svm->vcpu);
+   }
+}
+
  static int nested_svm_exit_handled_msr(struct vcpu_svm *svm)
  {
u32 offset, msr, value;
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index bc08221f6743..b4db9a980469 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -265,6 +265,7 @@ static int get_npt_level(struct kvm_vcpu *vcpu)
  
  void svm_set_efer(struct kvm_vcpu *vcpu, u64 efer)

  {
+   struct vcpu_svm *svm = to_svm(vcpu);
vcpu->arch.efer = efer;
  
  	if (!npt_enabled) {

@@ -275,8 +276,13 @@ void svm_set_efer(struct kvm_vcpu *vcpu, u64 efer)
efer &= ~EFER_LME;
}
  
-	to_svm(vcpu)->vmcb->save.efer = efer | EFER_SVME;

-   mark_dirty(to_svm(vcpu)->vmcb, VMCB_CR);
+   if (!(efer & EFER_SVME)) {
+   svm_leave_nested(svm);
+   svm_set_gif(svm, true);
+   }
+
+   svm->vmcb->save.efer = efer | EFER_SVME;
+   mark_dirty(svm->vmcb, VMCB_CR);
  }
  
  static int is_external_interrupt(u32 info)

diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h
index be8e830f83fa..6ac4c00a5d82 100644
--- a/arch/x86/kvm/svm/svm.h
+++ b/arch/x86/kvm/svm/svm.h
@@ -389,6 +389,7 @@ static inline bool nested_exit_on_nmi(struct vcpu_svm *svm)
  
  void enter_svm_guest_mode(struct vcpu_svm *svm, u64 vmcb_gpa,

  struct vmcb *nested_vmcb);
+void svm_leave_nested(struct vcpu_svm *svm);
  int nested_svm_vmrun(struct vcpu_svm *svm);
  void nested_svm_vmloadsave(struct vmcb *from_vmcb, struct vmcb *to_vmcb);
  int nested_svm_vmexit(struct vcpu_svm *svm);

Re: [PATCH v9 1/8] tpm: tpm_tis: Make implementation of read16, read32 and write32 optional

[Jarkko Sakkinen]

Plese, write the short summary as

tpm: Make read{16, 32}() and write32() in tpm_tis_phy_ops optional

On Tue, May 26, 2020 at 05:16:51PM +0300, amirmi...@gmail.com wrote:
> From: Amir Mizinski 
> 
> Only tpm_tis can use memory-mapped I/O, which is truly mapped into
> the kernel's memory space. Therefore, using ioread16/ioread32/iowrite32
> turns into a straightforward pointer dereference.
> Every other driver requires more complicated operations to read more than
> one byte at a time and will just fall back to read_bytes/write_bytes.
> Therefore, move this common code out of tpm_tis_spi and into tpm_tis_core
> so that it is used automatically when low-level drivers do not implement
> the specialized methods.
> 
> Co-developed-by: Alexander Steffen 
> Signed-off-by: Alexander Steffen 
> Signed-off-by: Amir Mizinski 
> ---
>  drivers/char/tpm/tpm_tis_core.h | 38 +++---
>  drivers/char/tpm/tpm_tis_spi.h  |  4 
>  drivers/char/tpm/tpm_tis_spi_cr50.c |  3 ---
>  drivers/char/tpm/tpm_tis_spi_main.c | 41 
> -
>  4 files changed, 35 insertions(+), 51 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm_tis_core.h b/drivers/char/tpm/tpm_tis_core.h
> index 7337819..d06c65b 100644
> --- a/drivers/char/tpm/tpm_tis_core.h
> +++ b/drivers/char/tpm/tpm_tis_core.h
> @@ -122,13 +122,35 @@ static inline int tpm_tis_read8(struct tpm_tis_data 
> *data, u32 addr, u8 *result)
>  static inline int tpm_tis_read16(struct tpm_tis_data *data, u32 addr,
>u16 *result)
>  {
> - return data->phy_ops->read16(data, addr, result);
> + __le16 result_le;
> + int rc;
> +
> + if (data->phy_ops->read16)
> + return data->phy_ops->read16(data, addr, result);
> +
> + rc = data->phy_ops->read_bytes(data, addr, sizeof(u16),
> +(u8 *)&result_le);
> + if (!rc)
> + *result = le16_to_cpu(result_le);
> +
> + return rc;
>  }
>  
>  static inline int tpm_tis_read32(struct tpm_tis_data *data, u32 addr,
>u32 *result)
>  {
> - return data->phy_ops->read32(data, addr, result);
> + __le32 result_le;
> + int rc;
> +
> + if (data->phy_ops->read32)
> + return data->phy_ops->read32(data, addr, result);
> +
> + rc = data->phy_ops->read_bytes(data, addr, sizeof(u32),
> +(u8 *)&result_le);
> + if (!rc)
> + *result = le32_to_cpu(result_le);
> +
> + return rc;
>  }
>  
>  static inline int tpm_tis_write_bytes(struct tpm_tis_data *data, u32 addr,
> @@ -145,7 +167,17 @@ static inline int tpm_tis_write8(struct tpm_tis_data 
> *data, u32 addr, u8 value)
>  static inline int tpm_tis_write32(struct tpm_tis_data *data, u32 addr,
> u32 value)
>  {
> - return data->phy_ops->write32(data, addr, value);
> + __le32 value_le;
> + int rc;
> +
> + if (data->phy_ops->write32)
> + return data->phy_ops->write32(data, addr, value);
> +
> + value_le = cpu_to_le32(value);
> + rc = data->phy_ops->write_bytes(data, addr, sizeof(u32),
> + (u8 *)&value_le);
> +
> + return rc;
>  }
>  
>  static inline bool is_bsw(void)
> diff --git a/drivers/char/tpm/tpm_tis_spi.h b/drivers/char/tpm/tpm_tis_spi.h
> index bba7397..d0f66f6 100644
> --- a/drivers/char/tpm/tpm_tis_spi.h
> +++ b/drivers/char/tpm/tpm_tis_spi.h
> @@ -31,10 +31,6 @@ extern int tpm_tis_spi_init(struct spi_device *spi, struct 
> tpm_tis_spi_phy *phy,
>  extern int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u16 len,
>   u8 *in, const u8 *out);
>  
> -extern int tpm_tis_spi_read16(struct tpm_tis_data *data, u32 addr, u16 
> *result);
> -extern int tpm_tis_spi_read32(struct tpm_tis_data *data, u32 addr, u32 
> *result);
> -extern int tpm_tis_spi_write32(struct tpm_tis_data *data, u32 addr, u32 
> value);
> -
>  #ifdef CONFIG_TCG_TIS_SPI_CR50
>  extern int cr50_spi_probe(struct spi_device *spi);
>  #else
> diff --git a/drivers/char/tpm/tpm_tis_spi_cr50.c 
> b/drivers/char/tpm/tpm_tis_spi_cr50.c
> index 37d72e8..f339d20 100644
> --- a/drivers/char/tpm/tpm_tis_spi_cr50.c
> +++ b/drivers/char/tpm/tpm_tis_spi_cr50.c
> @@ -215,9 +215,6 @@ static int tpm_tis_spi_cr50_write_bytes(struct 
> tpm_tis_data *data, u32 addr,
>  static const struct tpm_tis_phy_ops tpm_spi_cr50_phy_ops = {
>   .read_bytes = tpm_tis_spi_cr50_read_bytes,
>   .write_bytes = tpm_tis_spi_cr50_write_bytes,
> - .read16 = tpm_tis_spi_read16,
> - .read32 = tpm_tis_spi_read32,
> - .write32 = tpm_tis_spi_write32,
>  };
>  
>  static void cr50_print_fw_version(struct tpm_tis_data *data)
> diff --git a/drivers/char/tpm/tpm_tis_spi_main.c 
> b/drivers/char/tpm/tpm_tis_spi_main.c
> index d1754fd..95fef9d 100644
> --- a/drivers/char/tpm/tpm_tis_spi_main.c
> +++ b/drivers/char/tpm/tpm_tis_spi_main.c
> @@ -152,44

Re: [PATCH] crypto: hisilicon/qm - allow smaller reads in debugfs

[Shukun Tan]

Hi Dan & Zhou,

On 2020/5/28 20:37, Dan Carpenter wrote:
> Originally this code rejected any read less than 256 bytes.  There
> is no need for this artificial limit.
> 
> Also I have changed the snprintf() functions to scnprintf().  The
> difference is that snprintf() returns the number of bytes which would
> have been copied if there were enough space and scnprintf() returns the
> number of bytes which were actually copied.  It doesn't matter here
> because the strings are very short so they can't go over 256 bytes.
> 
> Signed-off-by: Dan Carpenter 
> ---
>  drivers/crypto/hisilicon/qm.c | 18 --
>  1 file changed, 8 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/crypto/hisilicon/qm.c b/drivers/crypto/hisilicon/qm.c
> index a781c02251980..9c0c9f500d91d 100644
> --- a/drivers/crypto/hisilicon/qm.c
> +++ b/drivers/crypto/hisilicon/qm.c
> @@ -1076,16 +1076,15 @@ static ssize_t qm_cmd_read(struct file *filp, char 
> __user *buffer,
>   if (*pos)
>   return 0;
>  
> - if (count < QM_DBG_READ_LEN)
> - return -ENOSPC;
> -

I think we should keep it, maybe you are right when using 'cat', but if you use 
'read'
system call this may make the user read only part of the prompt. This may break 
our
original design. :)

Thanks,
Shukun

> - len = snprintf(buf, QM_DBG_READ_LEN, "%s\n",
> + len = scnprintf(buf, QM_DBG_READ_LEN, "%s\n",
>  "Please echo help to cmd to get help information");
>  
> + len = min_t(size_t, len, count);
>   if (copy_to_user(buffer, buf, len))
>   return -EFAULT;
>  
> - return (*pos = len);
> + *pos = len;
> + return len;
>  }
>  
>  static void *qm_ctx_alloc(struct hisi_qm *qm, size_t ctx_size,
> @@ -2710,19 +2709,18 @@ static ssize_t qm_status_read(struct file *filp, char 
> __user *buffer,
>   if (*pos)
>   return 0;
>  
> - if (count < QM_DBG_READ_LEN)
> - return -ENOSPC;
> -
>   val = atomic_read(&qm->status.flags);
> - len = snprintf(buf, QM_DBG_READ_LEN, "%s\n", qm_s[val]);
> + len = scnprintf(buf, QM_DBG_READ_LEN, "%s\n", qm_s[val]);
>   if (!len)
>   return -EFAULT;
>  
> + len = min_t(size_t, len, count);
>   cp_len = copy_to_user(buffer, buf, len);
>   if (cp_len)
>   return -EFAULT;
>  
> - return (*pos = len);
> + *pos = len;
> + return len;
>  }
>  
>  static const struct file_operations qm_status_fops = {
> 

[PATCH 3/3] arm64: dts: imx8qxp: Add ethernet alias

[peng . fan]

From: Peng Fan 

Add ethernet alias, so bootloader code can use this to find the
primary ethernet device, and set the MAC address.

Signed-off-by: Peng Fan 
---
 arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi 
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 8ce997110cd6..ff6368af7d39 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -23,6 +23,8 @@
i2c1 = &adma_i2c1;
i2c2 = &adma_i2c2;
i2c3 = &adma_i2c3;
+   ethernet0 = &fec1;
+   ethernet1 = &fec2;
gpio0 = &lsio_gpio0;
gpio1 = &lsio_gpio1;
gpio2 = &lsio_gpio2;
-- 
2.16.4

[PATCH 2/3] arm64: dts: imx8qxp: add i2c aliases

[peng . fan]

From: Peng Fan 

The devices could be enumerated properly with aliases.

Signed-off-by: Peng Fan 
---
 arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi 
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 33363c127478..8ce997110cd6 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -19,6 +19,10 @@
#size-cells = <2>;
 
aliases {
+   i2c0 = &adma_i2c0;
+   i2c1 = &adma_i2c1;
+   i2c2 = &adma_i2c2;
+   i2c3 = &adma_i2c3;
gpio0 = &lsio_gpio0;
gpio1 = &lsio_gpio1;
gpio2 = &lsio_gpio2;
-- 
2.16.4

[PATCH 1/3] arm64: dts: imx8qxp: add alias for lsio MU

[peng . fan]

From: Peng Fan 

Add lsio mu alias for all lsio MUs that could communicate with SCU,
imx_scu_enable_general_irq_channel will parse the alias to get
the mu resource id, if using other MU, not MU1, the `mu_resource_id`
is not what we expect, so add alias to fix this issue.

Signed-off-by: Peng Fan 
---
 arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi 
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index d1c3c98e4b39..33363c127478 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -30,7 +30,11 @@
mmc0 = &usdhc1;
mmc1 = &usdhc2;
mmc2 = &usdhc3;
+   mu0 = &lsio_mu0;
mu1 = &lsio_mu1;
+   mu2 = &lsio_mu2;
+   mu3 = &lsio_mu3;
+   mu4 = &lsio_mu4;
serial0 = &adma_lpuart0;
serial1 = &adma_lpuart1;
serial2 = &adma_lpuart2;
-- 
2.16.4

[PATCH 0/3] arm64: dts: imx8qxp: dtb aliases fix/update

[peng . fan]

From: Peng Fan 

Minor patchset to fix and update alias for i.MX8QXP

Peng Fan (3):
  arm64: dts: imx8qxp: add alias for lsio MU
  arm64: dts: imx8qxp: add i2c aliases
  arm64: dts: imx8qxp: Add ethernet alias

 arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 10 ++
 1 file changed, 10 insertions(+)

-- 
2.16.4

Re: [PATCH v4 1/4] KEYS: trusted: Add generic trusted keys framework

[Jarkko Sakkinen]

On Wed, May 06, 2020 at 03:10:14PM +0530, Sumit Garg wrote:
> Current trusted keys framework is tightly coupled to use TPM device as
> an underlying implementation which makes it difficult for implementations
> like Trusted Execution Environment (TEE) etc. to provide trusked keys
> support in case platform doesn't posses a TPM device.
> 
> So this patch tries to add generic trusted keys framework where underlying
> implemtations like TPM, TEE etc. could be easily plugged-in.
> 
> Suggested-by: Jarkko Sakkinen 
> Signed-off-by: Sumit Garg 
> ---
>  include/keys/trusted-type.h |  45 
>  include/keys/trusted_tpm.h  |  15 --
>  security/keys/trusted-keys/Makefile |   1 +
>  security/keys/trusted-keys/trusted_common.c | 333 +++
>  security/keys/trusted-keys/trusted_tpm1.c   | 335 
> +---
>  5 files changed, 437 insertions(+), 292 deletions(-)
>  create mode 100644 security/keys/trusted-keys/trusted_common.c
> 
> diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
> index a94c03a..5559010 100644
> --- a/include/keys/trusted-type.h
> +++ b/include/keys/trusted-type.h
> @@ -40,6 +40,51 @@ struct trusted_key_options {
>   uint32_t policyhandle;
>  };
>  
> +struct trusted_key_ops {
> + /*
> +  * flag to indicate if trusted key implementation supports migration
> +  * or not.
> +  */
> + unsigned char migratable;
> +
> + /* trusted key init */
> + int (*init)(void);
> +
> + /* seal a trusted key */
> + int (*seal)(struct trusted_key_payload *p, char *datablob);
> +
> + /* unseal a trusted key */
> + int (*unseal)(struct trusted_key_payload *p, char *datablob);
> +
> + /* get random trusted key */
> + int (*get_random)(unsigned char *key, size_t key_len);
> +
> + /* trusted key cleanup */
> + void (*cleanup)(void);
> +};
> +
>  extern struct key_type key_type_trusted;
> +#if defined(CONFIG_TCG_TPM)
> +extern struct trusted_key_ops tpm_trusted_key_ops;
> +#endif
> +
> +#define TRUSTED_DEBUG 0
> +
> +#if TRUSTED_DEBUG
> +static inline void dump_payload(struct trusted_key_payload *p)
> +{
> + pr_info("trusted_key: key_len %d\n", p->key_len);
> + print_hex_dump(KERN_INFO, "key ", DUMP_PREFIX_NONE,
> +16, 1, p->key, p->key_len, 0);
> + pr_info("trusted_key: bloblen %d\n", p->blob_len);
> + print_hex_dump(KERN_INFO, "blob ", DUMP_PREFIX_NONE,
> +16, 1, p->blob, p->blob_len, 0);
> + pr_info("trusted_key: migratable %d\n", p->migratable);
> +}
> +#else
> +static inline void dump_payload(struct trusted_key_payload *p)
> +{
> +}
> +#endif
>  
>  #endif /* _KEYS_TRUSTED_TYPE_H */
> diff --git a/include/keys/trusted_tpm.h b/include/keys/trusted_tpm.h
> index a56d8e1..5753231 100644
> --- a/include/keys/trusted_tpm.h
> +++ b/include/keys/trusted_tpm.h
> @@ -60,17 +60,6 @@ static inline void dump_options(struct trusted_key_options 
> *o)
>  16, 1, o->pcrinfo, o->pcrinfo_len, 0);
>  }
>  
> -static inline void dump_payload(struct trusted_key_payload *p)
> -{
> - pr_info("trusted_key: key_len %d\n", p->key_len);
> - print_hex_dump(KERN_INFO, "key ", DUMP_PREFIX_NONE,
> -16, 1, p->key, p->key_len, 0);
> - pr_info("trusted_key: bloblen %d\n", p->blob_len);
> - print_hex_dump(KERN_INFO, "blob ", DUMP_PREFIX_NONE,
> -16, 1, p->blob, p->blob_len, 0);
> - pr_info("trusted_key: migratable %d\n", p->migratable);
> -}
> -
>  static inline void dump_sess(struct osapsess *s)
>  {
>   print_hex_dump(KERN_INFO, "trusted-key: handle ", DUMP_PREFIX_NONE,
> @@ -96,10 +85,6 @@ static inline void dump_options(struct trusted_key_options 
> *o)
>  {
>  }
>  
> -static inline void dump_payload(struct trusted_key_payload *p)
> -{
> -}
> -
>  static inline void dump_sess(struct osapsess *s)
>  {
>  }
> diff --git a/security/keys/trusted-keys/Makefile 
> b/security/keys/trusted-keys/Makefile
> index 7b73ceb..2b1085b 100644
> --- a/security/keys/trusted-keys/Makefile
> +++ b/security/keys/trusted-keys/Makefile
> @@ -4,5 +4,6 @@
>  #
>  
>  obj-$(CONFIG_TRUSTED_KEYS) += trusted.o
> +trusted-y += trusted_common.o
>  trusted-y += trusted_tpm1.o
>  trusted-y += trusted_tpm2.o
> diff --git a/security/keys/trusted-keys/trusted_common.c 
> b/security/keys/trusted-keys/trusted_common.c
> new file mode 100644
> index 000..9bfd081
> --- /dev/null
> +++ b/security/keys/trusted-keys/trusted_common.c
> @@ -0,0 +1,333 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2010 IBM Corporation
> + * Copyright (c) 2019, Linaro Limited
> + *
> + * Author:
> + * David Safford 
> + * Added generic trusted key framework: Sumit Garg 
> + *
> + * See Documentation/security/keys/trusted-encrypted.rst
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#in

Re: [PATCH] input: tablet: aiptek: fix possible buffer overflow caused by bad DMA value in aiptek_irq()

[kbuild test robot]

Hi Jia-Ju,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on input/next]
[also build test ERROR on v5.7 next-20200529]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Jia-Ju-Bai/input-tablet-aiptek-fix-possible-buffer-overflow-caused-by-bad-DMA-value-in-aiptek_irq/20200601-015649
base:   https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
config: s390-allyesconfig (attached as .config)
compiler: s390-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=s390 

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

All errors (new ones prefixed by >>, old ones prefixed by <<):

drivers/input/tablet/aiptek.c: In function 'aiptek_irq':
>> drivers/input/tablet/aiptek.c:744:7: error: 'marco' undeclared (first use in 
>> this function); did you mean 'macro'?
744 |   if (marco > 0 && macro < 25) {
|   ^
|   macro
drivers/input/tablet/aiptek.c:744:7: note: each undeclared identifier is 
reported only once for each function it appears in

vim +744 drivers/input/tablet/aiptek.c

   377  
   378  /***
   379   * aiptek_irq can receive one of six potential reports.
   380   * The documentation for each is in the body of the function.
   381   *
   382   * The tablet reports on several attributes per invocation of
   383   * aiptek_irq. Because the Linux Input Event system allows the
   384   * transmission of ONE attribute per input_report_xxx() call,
   385   * collation has to be done on the other end to reconstitute
   386   * a complete tablet report. Further, the number of Input Event reports
   387   * submitted varies, depending on what USB report type, and 
circumstance.
   388   * To deal with this, EV_MSC is used to indicate an 'end-of-report'
   389   * message. This has been an undocumented convention understood by the 
kernel
   390   * tablet driver and clients such as gpm and XFree86's tablet drivers.
   391   *
   392   * Of the information received from the tablet, the one piece I
   393   * cannot transmit is the proximity bit (without resorting to an EV_MSC
   394   * convention above.) I therefore have taken over REL_MISC and ABS_MISC
   395   * (for relative and absolute reports, respectively) for communicating
   396   * Proximity. Why two events? I thought it interesting to know if the
   397   * Proximity event occurred while the tablet was in absolute or relative
   398   * mode.
   399   * Update: REL_MISC proved not to be such a good idea. With REL_MISC you
   400   * get an event transmitted each time. ABS_MISC works better, since it
   401   * can be set and re-set. Thus, only using ABS_MISC from now on.
   402   *
   403   * Other tablets use the notion of a certain minimum stylus pressure
   404   * to infer proximity. While that could have been done, that is yet
   405   * another 'by convention' behavior, the documentation for which
   406   * would be spread between two (or more) pieces of software.
   407   *
   408   * EV_MSC usage was terminated for this purpose in Linux 2.5.x, and
   409   * replaced with the input_sync() method (which emits EV_SYN.)
   410   */
   411  
   412  static void aiptek_irq(struct urb *urb)
   413  {
   414  struct aiptek *aiptek = urb->context;
   415  unsigned char *data = aiptek->data;
   416  struct input_dev *inputdev = aiptek->inputdev;
   417  struct usb_interface *intf = aiptek->intf;
   418  int jitterable = 0;
   419  int retval, macro, x, y, z, left, right, middle, p, dv, tip, 
bs, pck;
   420  
   421  switch (urb->status) {
   422  case 0:
   423  /* Success */
   424  break;
   425  
   426  case -ECONNRESET:
   427  case -ENOENT:
   428  case -ESHUTDOWN:
   429  /* This urb is terminated, clean up */
   430  dev_dbg(&intf->dev, "%s - urb shutting down with 
status: %d\n",
   431  __func__, urb->status);
   432  return;
   433  
   434  default:
   435  dev_dbg(&intf->dev, "%s - nonzero urb status received: 
%d\n",
   436  __func__, urb->status);
   437  goto exit;
   438  }
   439  
   440  /* See if we are in a delay loop -- throw out report if true.
   441   */
   442  if (aiptek->inDe

[GIT PULL] hwmon updates for v5.8

[Guenter Roeck]

Hi Linus,

Please pull hwmon updates for Linux v5.8 from signed tag:

git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
hwmon-for-v5.8

Thanks,
Guenter
--

The following changes since commit b9bbe6ed63b2b9f2c9ee5cbd0f2c946a2723f4ce:

  Linux 5.7-rc6 (2020-05-17 16:48:37 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
tags/hwmon-for-v5.8

for you to fetch changes up to 87976ce2825d9f1ca2e70ee7d38dec490ad5a6e2:

  hwmon: Add Baikal-T1 PVT sensor driver (2020-05-28 07:59:45 -0700)


hwmon updates for v5.8

Infrastructure
- Add notification support

New drivers
- Baikal-T1 PVT sensor driver
- amd_energy driver to report energy counters
- Driver for Maxim MAX16601
- Gateworks System Controller

Various
- applesmc: avoid overlong udelay()
- dell-smm: Use one DMI match for all XPS models
- ina2xx: Implement alert functions
- lm70: Add support for ACPI
- lm75: Fix coding-style warnings
- lm90: Add max6654 support to lm90 driver
- nct7802: Replace container_of() API
- nct7904: Set default timeout
- nct7904: Add watchdog function
- pmbus: Improve initialization of 'currpage' and 'currphase'


Akinobu Mita (1):
  hwmon: Reduce indentation level in __hwmon_device_register()

Alex Qiu (1):
  hwmon: (ina2xx) Implement alert functions

Andrej Picej (1):
  hwmon: (lm70) Add support for ACPI

Arnd Bergmann (1):
  hwmon: (applesmc) avoid overlong udelay()

Guenter Roeck (4):
  hwmon: (pmbus) Improve initialization of 'currpage' and 'currphase'
  hwmon: (pmbus) Driver for Maxim MAX16601
  Merge tag 'ib-mfd-hwmon-v5.8' into hwmon-next
  hwmon: Add notification support

Josh Lehan (1):
  hwmon: (lm90) Add max6654 support to lm90 driver

Michal Orzel (1):
  hwmon: (lm75) Fix all coding-style warnings on lm75 driver

Naveen Krishna Chatradhi (3):
  hwmon: Add amd_energy driver to report energy counters
  hwmon: (amd_energy) Add documentation
  MAINTAINERS: add entry for AMD energy driver

Serge Semin (2):
  dt-bindings: hwmon: Add Baikal-T1 PVT sensor binding
  hwmon: Add Baikal-T1 PVT sensor driver

Thomas Hebb (1):
  hwmon: (dell-smm) Use one DMI match for all XPS models

Tim Harvey (3):
  dt-bindings: mfd: Add Gateworks System Controller bindings
  mfd: Add Gateworks System Controller core driver
  hwmon: Add Gateworks System Controller support

Wei Yongjun (1):
  hwmon: (amd_energy) Missing platform_driver_unregister() on error in 
amd_energy_init()

Wolfram Sang (1):
  hwmon: (adt7411) update contact email

Yuechao Zhao (2):
  hwmon: (nct7904) Add watchdog function
  hwmon: (nct7904) Set default timeout

hailizheng (1):
  hwmon: (nct7802) Replace container_of() API

zhouchuangao (1):
  hwmon : (nct6775) Use kobj_to_dev() API

 .../devicetree/bindings/hwmon/baikal,bt1-pvt.yaml  |  107 ++
 .../devicetree/bindings/mfd/gateworks-gsc.yaml |  196 
 Documentation/hwmon/amd_energy.rst |  109 ++
 Documentation/hwmon/bt1-pvt.rst|  117 ++
 Documentation/hwmon/gsc-hwmon.rst  |   53 +
 Documentation/hwmon/ina2xx.rst |   19 +
 Documentation/hwmon/index.rst  |4 +
 Documentation/hwmon/lm90.rst   |   23 +-
 Documentation/hwmon/max16601.rst   |  159 +++
 MAINTAINERS|   18 +
 drivers/hwmon/Kconfig  |   59 +-
 drivers/hwmon/Makefile |3 +
 drivers/hwmon/adt7411.c|3 +-
 drivers/hwmon/amd_energy.c |  408 +++
 drivers/hwmon/applesmc.c   |   12 +-
 drivers/hwmon/bt1-pvt.c| 1146 
 drivers/hwmon/bt1-pvt.h|  244 +
 drivers/hwmon/dell-smm-hwmon.c |   26 +-
 drivers/hwmon/gsc-hwmon.c  |  390 +++
 drivers/hwmon/hwmon.c  |  136 ++-
 drivers/hwmon/ina2xx.c |  183 
 drivers/hwmon/lm70.c   |   47 +-
 drivers/hwmon/lm75.c   |8 +-
 drivers/hwmon/lm75.h   |   31 +-
 drivers/hwmon/lm90.c   |   45 +-
 drivers/hwmon/nct6775.c|   10 +-
 drivers/hwmon/nct7802.c|6 +-
 drivers/hwmon/nct7904.c|  138 ++-
 drivers/hwmon/pmbus/Kconfig|9 +
 drivers/hwmon/pmbus/Makefile   |1 +
 drivers/hwmon/pmbus/max16601.c |  314 ++
 drivers/hwmon/pmbus/pmbus_core.c   |

Re: [PATCH v4 1/4] KEYS: trusted: Add generic trusted keys framework

[Jarkko Sakkinen]

On Wed, May 06, 2020 at 03:10:14PM +0530, Sumit Garg wrote:
> Current trusted keys framework is tightly coupled to use TPM device as
> an underlying implementation which makes it difficult for implementations
> like Trusted Execution Environment (TEE) etc. to provide trusked keys
> support in case platform doesn't posses a TPM device.
> 
> So this patch tries to add generic trusted keys framework where underlying
> implemtations like TPM, TEE etc. could be easily plugged-in.
> 
> Suggested-by: Jarkko Sakkinen 
> Signed-off-by: Sumit Garg 
> ---
>  include/keys/trusted-type.h |  45 
>  include/keys/trusted_tpm.h  |  15 --
>  security/keys/trusted-keys/Makefile |   1 +
>  security/keys/trusted-keys/trusted_common.c | 333 +++

I think trusted_core.c would be a better name (less ambiguous).

>  security/keys/trusted-keys/trusted_tpm1.c   | 335 
> +---
>  5 files changed, 437 insertions(+), 292 deletions(-)
>  create mode 100644 security/keys/trusted-keys/trusted_common.c
> 
> diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
> index a94c03a..5559010 100644
> --- a/include/keys/trusted-type.h
> +++ b/include/keys/trusted-type.h
> @@ -40,6 +40,51 @@ struct trusted_key_options {
>   uint32_t policyhandle;
>  };
>  
> +struct trusted_key_ops {
> + /*
> +  * flag to indicate if trusted key implementation supports migration
> +  * or not.
> +  */
> + unsigned char migratable;
> +
> + /* trusted key init */
> + int (*init)(void);

/* Init a key. */

> +
> + /* seal a trusted key */
> + int (*seal)(struct trusted_key_payload *p, char *datablob);

/* Seal a key. */

> +
> + /* unseal a trusted key */
> + int (*unseal)(struct trusted_key_payload *p, char *datablob);

/* Unseal a key. */

> +
> + /* get random trusted key */
> + int (*get_random)(unsigned char *key, size_t key_len);

/* Get a randomized key. */

> +
> + /* trusted key cleanup */
> + void (*cleanup)(void);

Please remove this from this commit since it is not in use in the scope
of this commit. You should instead make a separate commit just for this
callback, which explains what it is and how it will be used in the
follow up commits.


> +};
> +
>  extern struct key_type key_type_trusted;
> +#if defined(CONFIG_TCG_TPM)
> +extern struct trusted_key_ops tpm_trusted_key_ops;
> +#endif
> +
> +#define TRUSTED_DEBUG 0
> +
> +#if TRUSTED_DEBUG
> +static inline void dump_payload(struct trusted_key_payload *p)
> +{
> + pr_info("trusted_key: key_len %d\n", p->key_len);
> + print_hex_dump(KERN_INFO, "key ", DUMP_PREFIX_NONE,
> +16, 1, p->key, p->key_len, 0);
> + pr_info("trusted_key: bloblen %d\n", p->blob_len);
> + print_hex_dump(KERN_INFO, "blob ", DUMP_PREFIX_NONE,
> +16, 1, p->blob, p->blob_len, 0);
> + pr_info("trusted_key: migratable %d\n", p->migratable);
> +}
> +#else
> +static inline void dump_payload(struct trusted_key_payload *p)
> +{
> +}
> +#endif
>  
>  #endif /* _KEYS_TRUSTED_TYPE_H */
> diff --git a/include/keys/trusted_tpm.h b/include/keys/trusted_tpm.h
> index a56d8e1..5753231 100644
> --- a/include/keys/trusted_tpm.h
> +++ b/include/keys/trusted_tpm.h
> @@ -60,17 +60,6 @@ static inline void dump_options(struct trusted_key_options 
> *o)
>  16, 1, o->pcrinfo, o->pcrinfo_len, 0);
>  }
>  
> -static inline void dump_payload(struct trusted_key_payload *p)
> -{
> - pr_info("trusted_key: key_len %d\n", p->key_len);
> - print_hex_dump(KERN_INFO, "key ", DUMP_PREFIX_NONE,
> -16, 1, p->key, p->key_len, 0);
> - pr_info("trusted_key: bloblen %d\n", p->blob_len);
> - print_hex_dump(KERN_INFO, "blob ", DUMP_PREFIX_NONE,
> -16, 1, p->blob, p->blob_len, 0);
> - pr_info("trusted_key: migratable %d\n", p->migratable);
> -}
> -
>  static inline void dump_sess(struct osapsess *s)
>  {
>   print_hex_dump(KERN_INFO, "trusted-key: handle ", DUMP_PREFIX_NONE,
> @@ -96,10 +85,6 @@ static inline void dump_options(struct trusted_key_options 
> *o)
>  {
>  }
>  
> -static inline void dump_payload(struct trusted_key_payload *p)
> -{
> -}
> -
>  static inline void dump_sess(struct osapsess *s)
>  {
>  }
> diff --git a/security/keys/trusted-keys/Makefile 
> b/security/keys/trusted-keys/Makefile
> index 7b73ceb..2b1085b 100644
> --- a/security/keys/trusted-keys/Makefile
> +++ b/security/keys/trusted-keys/Makefile
> @@ -4,5 +4,6 @@
>  #
>  
>  obj-$(CONFIG_TRUSTED_KEYS) += trusted.o
> +trusted-y += trusted_common.o
>  trusted-y += trusted_tpm1.o
>  trusted-y += trusted_tpm2.o
> diff --git a/security/keys/trusted-keys/trusted_common.c 
> b/security/keys/trusted-keys/trusted_common.c
> new file mode 100644
> index 000..9bfd081
> --- /dev/null
> +++ b/security/keys/trusted-keys/trusted_common.c
> @@ -0,0 +1,333 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*

Re: [PATCH RFC] seccomp: Implement syscall isolation based on memory areas

[Andy Lutomirski]

> On May 31, 2020, at 4:50 PM, Brendan Shanks  wrote:
> 
> 
>> On May 31, 2020, at 11:57 AM, Andy Lutomirski  wrote:
>> 
>> Using SECCOMP_RET_USER_NOTIF is likely to be considerably more
>> expensive than my scheme.  On a non-PTI system, my approach will add a
>> few tens of ns to each syscall.  On a PTI system, it will be worse.
>> But using any kind of notifier for all syscalls will cause a context
>> switch to a different user program for each syscall, and that will be
>> much slower.
> 
> There’s also no way (at least to my understanding) to modify register state 
> from SECCOMP_RET_USER_NOTIF, which is how the existing -staging SIGSYS 
> handler works:
> 
> 
> 
>> I think that the implementation may well want to live in seccomp, but
>> doing this as a seccomp filter isn't quite right.  It's not a security
>> thing -- it's an emulation thing.  Seccomp is all about making
>> inescapable sandboxes, but that's not what you're doing at all, and
>> the fact that seccomp filters are preserved across execve() sounds
>> like it'll be annoying for you.
> 
> Definitely. Regardless of what approach is taken, we don’t want it to persist 
> across execve.
> 
>> What if there was a special filter type that ran a BPF program on each
>> syscall, and the program was allowed to access user memory to make its
>> decisions, e.g. to look at some list of memory addresses.  But this
>> would explicitly *not* be a security feature -- execve() would remove
>> the filter, and the filter's outcome would be one of redirecting
>> execution or allowing the syscall.  If the "allow" outcome occurs,
>> then regular seccomp filters run.  Obviously the exact semantics here
>> would need some care.
> 
> Although if that’s running a BPF filter on every syscall, wouldn’t it also 
> incur the ~10% overhead that Paul and Gabriel have seen with existing seccomp?
> 
> 

Unlikely. Some benchmarking is needed, but the seccomp ptrace overhead is 
likely *huge* compared to the overhead of just a filter.

As wild guess numbers on made up modern hardware, cache hot:

Empty syscall: 50ns, or 300ns with PTI

Empty syscall accepted by simple seccomp filter: 10ns more than an empty 
syscall without seccomp

Seccomp ptrace round trip: 6 us  Worse with PTI

Seccomp user notif round trip: 4 us

Syscall hypothetically redirected back to same process: about the same as an 
empty filtered accepted syscall, plus however long it takes to run the handler. 
Add 900ns if using SIGSYS instead of plain redirection. Add an extra 500ns on 
current kernels because signal delivery sucks, but I can fix this.

Take these numbers with a huge grain of salt.  But the point is that the BPF 
part is the least of your worries.

My Dear in the lord

[Mrs. Mina A. Brunel]

My Dear in the lord


My name is Mrs. Mina A. Brunel I am a Norway Citizen who is living in Burkina 
Faso, I am married to Mr. Brunel Patrice, a politician who owns a small gold 
company in Burkina Faso; He died of Leprosy and Radesyge, in the year February 
2010, During his lifetime he deposited the sum of € 8.5 Million Euro) Eight 
million, Five hundred thousand Euros in a bank in Ouagadougou the capital city 
of Burkina Faso in West Africa. The money was from the sale of his company and 
death benefits payment and entitlements of my deceased husband by his company.

I am sending you this message with heavy tears in my eyes and great sorrow in 
my heart, and also praying that it will reach you in good health because I am 
not in good health, I sleep every night without knowing if I may be alive to 
see the next day. I am suffering from long time cancer and presently I am 
partially suffering from Leprosy, which has become difficult for me to move 
around. I was married to my late husband for more than 6 years without having a 
child and my doctor confided that I have less chance to live, having to know 
when the cup of death will come, I decided to contact you to claim the fund 
since I don't have any relation I grew up from an orphanage home.

I have decided to donate this money for the support of helping Motherless 
babies/Less privileged/Widows and churches also to build the house of God 
because I am dying and diagnosed with cancer for about 3 years ago. I have 
decided to donate from what I have inherited from my late husband to you for 
the good work of Almighty God; I will be going in for an operation surgery soon.

Now I want you to stand as my next of kin to claim the funds for charity 
purposes. Because of this money remains unclaimed after my death, the bank 
executives or the government will take the money as unclaimed fund and maybe 
use it for selfishness and worthless ventures, I need a very honest person who 
can claim this money and use it for Charity works, for orphanages, widows and 
also build schools and churches for less privilege that will be named after my 
late husband and my name.

I need your urgent answer to know if you will be able to execute this project, 
and I will give you more information on how the fund will be transferred to 
your bank account or online banking.

Thanks
Mrs. Mina A. Brunel

Re: [PATCHv5 1/3] optee: do drivers initialization before and after tee-supplicant run

[Jarkko Sakkinen]

On Fri, May 29, 2020 at 11:26:59AM +0300, Maxim Uvarov wrote:
> Some drivers (like ftpm) can operate only after tee-supplicant
> runs because of tee-supplicant provides things like storage
> services.  This patch splits probe of non tee-supplicant dependable
> drivers to the early stage, and after tee-supplicant run probe other
> drivers.
> 
> Signed-off-by: Maxim Uvarov 
> Suggested-by: Sumit Garg 
> Suggested-by: Arnd Bergmann 

$ scripts/get_maintainer.pl drivers/tee 
Jens Wiklander  (maintainer:TEE SUBSYSTEM)
tee-...@lists.linaro.org (open list:TEE SUBSYSTEM)
linux-kernel@vger.kernel.org (open list)

tee-dev is missing. Please resend.

/Jarkko

Re: [PATCH] tpm_tis_spi: Don't send anything during flow control

[Jarkko Sakkinen]

On Thu, May 28, 2020 at 03:19:30PM -0700, Douglas Anderson wrote:
> During flow control we are just reading from the TPM, yet our spi_xfer
> has the tx_buf and rx_buf both non-NULL which means we're requesting a
> full duplex transfer.
> 
> SPI is always somewhat of a full duplex protocol anyway and in theory
> the other side shouldn't really be looking at what we're sending it
> during flow control, but it's still a bit ugly to be sending some
> "random" data when we shouldn't.
> 
> The default tpm_tis_spi_flow_control() tries to address this by
> setting 'phy->iobuf[0] = 0'.  This partially avoids the problem of
> sending "random" data, but since our tx_buf and rx_buf both point to
> the same place I believe there is the potential of us sending the
> TPM's previous byte back to it if we hit the retry loop.
> 
> Another flow control implementation, cr50_spi_flow_control(), doesn't
> address this at all.
> 
> Let's clean this up and just make the tx_buf NULL before we call
> flow_control().  Not only does this ensure that we're not sending any
> "random" bytes but it also possibly could make the SPI controller
> behave in a slightly more optimal way.
> 
> NOTE: no actual observed problems are fixed by this patch--it's was
> just made based on code inspection.
> 
> Signed-off-by: Douglas Anderson 
> ---
> 
>  drivers/char/tpm/tpm_tis_spi_main.c | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm_tis_spi_main.c 
> b/drivers/char/tpm/tpm_tis_spi_main.c
> index d96755935529..8d2c581a93c6 100644
> --- a/drivers/char/tpm/tpm_tis_spi_main.c
> +++ b/drivers/char/tpm/tpm_tis_spi_main.c
> @@ -53,8 +53,6 @@ static int tpm_tis_spi_flow_control(struct tpm_tis_spi_phy 
> *phy,
>  
>   if ((phy->iobuf[3] & 0x01) == 0) {
>   // handle SPI wait states
> - phy->iobuf[0] = 0;
> -

Why this should be removed?

/Jarkko

Re: [PATCH] staging: kpc2000: kpc_dma: Convert get_user_pages() --> pin_user_pages()

[John Hubbard]

On 2020-05-31 10:51, Souptick Joarder wrote:

In 2019, we introduced pin_user_pages*() and now we are converting
get_user_pages*() to the new API as appropriate. [1] & [2] could
be referred for more information.

When pin_user_pages() returns numbers of partially mapped pages,
those pages were not unpinned as part of error handling. Fixed
it as part of this patch.



Hi Souptick,

btw, Bharath (+cc) attempted to do the "put" side of this, last year.
That got as far as a v4 patch [1], and then I asked him to let me put
it into my tree. But then it didn't directly apply anymore after the
whole design moved to pin+unpin, and so here we are now.


If Bharath is still doing kernel work, you might offer him a Co-Developed-by:
tag (see https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html).

Anyway, I'd recommend splitting the bug fix(es) into it at least one
separate patch. That's a "best practice", and I don't see any reason
not to do it here, even though the bugs are not huge.

Also I think there may be more than one bug to fix, because I just
noticed that the pre-existing code is doing set_page_dirty(), when
it should be doing set_page_dirty_lock(). See below.



[1] Documentation/core-api/pin_user_pages.rst

[2] "Explicit pinning of user-space pages":
 https://lwn.net/Articles/807108/

Signed-off-by: Souptick Joarder 
Cc: John Hubbard 
---
Hi,

I'm compile tested this, but unable to run-time test, so any testing
help is much appriciated.

  drivers/staging/kpc2000/kpc_dma/fileops.c | 15 ---
  1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/kpc2000/kpc_dma/fileops.c 
b/drivers/staging/kpc2000/kpc_dma/fileops.c
index 8975346..29bab13 100644
--- a/drivers/staging/kpc2000/kpc_dma/fileops.c
+++ b/drivers/staging/kpc2000/kpc_dma/fileops.c
@@ -48,6 +48,7 @@ static int kpc_dma_transfer(struct dev_private_data *priv,
u64 card_addr;
u64 dma_addr;
u64 user_ctl;
+   int nr_pages = 0;


Probably best to correct the "rv" type as well: it should be an int, rather
than a long.

  
  	ldev = priv->ldev;
  
@@ -76,13 +77,15 @@ static int kpc_dma_transfer(struct dev_private_data *priv,
  
  	// Lock the user buffer pages in memory, and hold on to the page pointers (for the sglist)

mmap_read_lock(current->mm);  /*  get memory map semaphore */
-   rv = get_user_pages(iov_base, acd->page_count, FOLL_TOUCH | FOLL_WRITE | 
FOLL_GET, acd->user_pages, NULL);
+   rv = pin_user_pages(iov_base, acd->page_count, FOLL_TOUCH | FOLL_WRITE, 
acd->user_pages, NULL);
mmap_read_unlock(current->mm);/*  release the semaphore */
if (rv != acd->page_count) {
-   dev_err(&priv->ldev->pldev->dev, "Couldn't get_user_pages 
(%ld)\n", rv);
+   dev_err(&priv->ldev->pldev->dev, "Couldn't pin_user_pages 
(%ld)\n", rv);
+   nr_pages = rv;
goto err_get_user_pages;
}
  
+	nr_pages = acd->page_count;

// Allocate and setup the sg_table (scatterlist entries)
rv = sg_alloc_table_from_pages(&acd->sgt, acd->user_pages, acd->page_count, 
iov_base & (PAGE_SIZE - 1), iov_len, GFP_KERNEL);
if (rv) {
@@ -189,10 +192,9 @@ static int kpc_dma_transfer(struct dev_private_data *priv,
sg_free_table(&acd->sgt);
   err_dma_map_sg:
   err_alloc_sg_table:


So now we end up with two unnecessary labels. Probably best to delete two of 
these
three and name the remaining one appropriately:

 err_dma_map_sg:
 err_alloc_sg_table:
 err_get_user_pages:


-   for (i = 0 ; i < acd->page_count ; i++)
-   put_page(acd->user_pages[i]);
-
   err_get_user_pages:
+   if (nr_pages > 0)
+   unpin_user_pages(acd->user_pages, nr_pages);
kfree(acd->user_pages);
   err_alloc_userpages:
kfree(acd);
@@ -217,8 +219,7 @@ void  transfer_complete_cb(struct aio_cb_data *acd, size_t 
xfr_count, u32 flags)
  


There is code up here (not shown in this diff), that does a set_page_dirty().
First of all, that should be set_page_dirty_lock(), and second, maybe (or maybe 
not)
it can all be done after the dma_unmap_sg(), at the same time as the unpin, via
unpin_user_pages_dirty_lock(). In fact, it's misleading at best to leave those
pages mapped, because there is an interval in there after set_page_dirty() and
before put_page(), in which the device could be running and setting pages dirty.
(Remember that writeback attempts can be happening concurrently with all of 
this,
and writeback is deeply involved with page dirtiness.)

I remember Bharath wrestled with this in an earlier conversion attempt (back 
when
we were only converting the "put_page" side of things), let me see if I can dig 
up
that email thread for some guidance...OK, in [1] it appears that everyone
finally settled on keeping the PageReserved check, but OK to move everything 
below
the dma_unmap_sg() call.

[1] https://lore.kernel.org/r/20190720173214.GA4250@bharath12345-Insp

[PATCH v31 11/21] x86/sgx: Linux Enclave Driver

[Jarkko Sakkinen]

Intel Software Guard eXtensions (SGX) is a set of CPU instructions that
can be used by applications to set aside private regions of code and
data. The code outside the SGX hosted software entity is disallowed to
access the memory inside the enclave enforced by the CPU. We call these
entities as enclaves.

This commit implements a driver that provides an ioctl API to construct
and run enclaves. Enclaves are constructed from pages residing in
reserved physical memory areas. The contents of these pages can only be
accessed when they are mapped as part of an enclave, by a hardware
thread running inside the enclave.

The starting state of an enclave consists of a fixed measured set of
pages that are copied to the EPC during the construction process by
using ENCLS leaf functions and Software Enclave Control Structure (SECS)
that defines the enclave properties.

Enclave are constructed by using ENCLS leaf functions ECREATE, EADD and
EINIT. ECREATE initializes SECS, EADD copies pages from system memory to
the EPC and EINIT check a given signed measurement and moves the enclave
into a state ready for execution.

An initialized enclave can only be accessed through special Thread Control
Structure (TCS) pages by using ENCLU (ring-3 only) leaf EENTER.  This leaf
function converts a thread into enclave mode and continues the execution in
the offset defined by the TCS provided to EENTER. An enclave is exited
through syscall, exception, interrupts or by explicitly calling another
ENCLU leaf EEXIT.

The permissions, which enclave page is added will set the limit for maximum
permissions that can be set for mmap() and mprotect(). This will
effectively allow to build different security schemes between producers and
consumers of enclaves. Later on we can increase granularity with LSM hooks
for page addition (i.e. for producers) and mapping of the enclave (i.e. for
consumers)

Cc: linux-security-mod...@vger.kernel.org
Acked-by: Jethro Beekman 
Tested-by: Jethro Beekman 
Tested-by: Haitao Huang 
Tested-by: Chunyang Hui 
Tested-by: Jordan Hand 
Tested-by: Nathaniel McCallum 
Tested-by: Seth Moore 
Co-developed-by: Sean Christopherson 
Signed-off-by: Sean Christopherson 
Co-developed-by: Suresh Siddha 
Signed-off-by: Suresh Siddha 
Signed-off-by: Jarkko Sakkinen 
---
 .../userspace-api/ioctl/ioctl-number.rst  |   1 +
 arch/x86/include/uapi/asm/sgx.h   |  66 ++
 arch/x86/kernel/cpu/sgx/Makefile  |   3 +
 arch/x86/kernel/cpu/sgx/driver.c  | 194 +
 arch/x86/kernel/cpu/sgx/driver.h  |  30 +
 arch/x86/kernel/cpu/sgx/encl.c| 335 +
 arch/x86/kernel/cpu/sgx/encl.h|  87 +++
 arch/x86/kernel/cpu/sgx/ioctl.c   | 706 ++
 arch/x86/kernel/cpu/sgx/main.c|  11 +
 9 files changed, 1433 insertions(+)
 create mode 100644 arch/x86/include/uapi/asm/sgx.h
 create mode 100644 arch/x86/kernel/cpu/sgx/driver.c
 create mode 100644 arch/x86/kernel/cpu/sgx/driver.h
 create mode 100644 arch/x86/kernel/cpu/sgx/encl.c
 create mode 100644 arch/x86/kernel/cpu/sgx/encl.h
 create mode 100644 arch/x86/kernel/cpu/sgx/ioctl.c

diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst 
b/Documentation/userspace-api/ioctl/ioctl-number.rst
index f759edafd938..a9a418a9918c 100644
--- a/Documentation/userspace-api/ioctl/ioctl-number.rst
+++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
@@ -320,6 +320,7 @@ Code  Seq#Include File  
 Comments
  

 0xA3  90-9F  linux/dtlk.h
 0xA4  00-1F  uapi/linux/tee.hGeneric 
TEE subsystem
+0xA4  00-1F  uapi/asm/sgx.h  Intel SGX 
subsystem (a legit conflict as TEE and SGX do not co-exist)
 0xAA  00-3F  linux/uapi/linux/userfaultfd.h
 0xAB  00-1F  linux/nbd.h
 0xAC  00-1F  linux/raw.h
diff --git a/arch/x86/include/uapi/asm/sgx.h b/arch/x86/include/uapi/asm/sgx.h
new file mode 100644
index ..5edb08ab8fd0
--- /dev/null
+++ b/arch/x86/include/uapi/asm/sgx.h
@@ -0,0 +1,66 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) WITH Linux-syscall-note 
*/
+/*
+ * Copyright(c) 2016-19 Intel Corporation.
+ */
+#ifndef _UAPI_ASM_X86_SGX_H
+#define _UAPI_ASM_X86_SGX_H
+
+#include 
+#include 
+
+/**
+ * enum sgx_epage_flags - page control flags
+ * %SGX_PAGE_MEASURE:  Measure the page contents with a sequence of
+ * ENCLS[EEXTEND] operations.
+ */
+enum sgx_page_flags {
+   SGX_PAGE_MEASURE= 0x01,
+};
+
+#define SGX_MAGIC 0xA4
+
+#define SGX_IOC_ENCLAVE_CREATE \
+   _IOW(SGX_MAGIC, 0x00, struct sgx_enclave_create)
+#define SGX_IOC_ENCLAVE_ADD_PAGES \
+   _IOWR(SGX_MAGIC, 0x01, struct sgx_enclave_add_pages)
+#define SGX_IOC_ENCLAVE_INIT \
+   _IOW(SGX_MAGIC, 0x02, struct sgx_enclave_init)
+
+/**
+ * struct sgx_enclave_create -

[PATCH net-next v4] hinic: add set_channels ethtool_ops support

[Luo bin]

add support to change TX/RX queue number with ethtool -L ethx combined

Signed-off-by: Luo bin 
---
 .../net/ethernet/huawei/hinic/hinic_ethtool.c | 40 +++
 .../net/ethernet/huawei/hinic/hinic_main.c|  2 +-
 drivers/net/ethernet/huawei/hinic/hinic_tx.c  |  5 +++
 3 files changed, 38 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c 
b/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
index ace18d258049..efb02e03e7da 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
@@ -619,14 +619,37 @@ static void hinic_get_channels(struct net_device *netdev,
struct hinic_dev *nic_dev = netdev_priv(netdev);
struct hinic_hwdev *hwdev = nic_dev->hwdev;
 
-   channels->max_rx = hwdev->nic_cap.max_qps;
-   channels->max_tx = hwdev->nic_cap.max_qps;
-   channels->max_other = 0;
-   channels->max_combined = 0;
-   channels->rx_count = hinic_hwdev_num_qps(hwdev);
-   channels->tx_count = hinic_hwdev_num_qps(hwdev);
-   channels->other_count = 0;
-   channels->combined_count = 0;
+   channels->max_combined = nic_dev->max_qps;
+   channels->combined_count = hinic_hwdev_num_qps(hwdev);
+}
+
+static int hinic_set_channels(struct net_device *netdev,
+ struct ethtool_channels *channels)
+{
+   struct hinic_dev *nic_dev = netdev_priv(netdev);
+   unsigned int count = channels->combined_count;
+   int err;
+
+   netif_info(nic_dev, drv, netdev, "Set max combined queue number from %d 
to %d\n",
+  hinic_hwdev_num_qps(nic_dev->hwdev), count);
+
+   if (netif_running(netdev)) {
+   netif_info(nic_dev, drv, netdev, "Restarting netdev\n");
+   hinic_close(netdev);
+
+   nic_dev->hwdev->nic_cap.num_qps = count;
+
+   err = hinic_open(netdev);
+   if (err) {
+   netif_err(nic_dev, drv, netdev,
+ "Failed to open netdev\n");
+   return -EFAULT;
+   }
+   } else {
+   nic_dev->hwdev->nic_cap.num_qps = count;
+   }
+
+   return 0;
 }
 
 static int hinic_get_rss_hash_opts(struct hinic_dev *nic_dev,
@@ -1219,6 +1242,7 @@ static const struct ethtool_ops hinic_ethtool_ops = {
.get_ringparam = hinic_get_ringparam,
.set_ringparam = hinic_set_ringparam,
.get_channels = hinic_get_channels,
+   .set_channels = hinic_set_channels,
.get_rxnfc = hinic_get_rxnfc,
.set_rxnfc = hinic_set_rxnfc,
.get_rxfh_key_size = hinic_get_rxfh_key_size,
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_main.c 
b/drivers/net/ethernet/huawei/hinic/hinic_main.c
index c8ab129a7ae8..e9e6f4c9309a 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_main.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_main.c
@@ -326,7 +326,6 @@ static void hinic_enable_rss(struct hinic_dev *nic_dev)
int i, node, err = 0;
u16 num_cpus = 0;
 
-   nic_dev->max_qps = hinic_hwdev_max_num_qps(hwdev);
if (nic_dev->max_qps <= 1) {
nic_dev->flags &= ~HINIC_RSS_ENABLE;
nic_dev->rss_limit = nic_dev->max_qps;
@@ -1031,6 +1030,7 @@ static int nic_dev_init(struct pci_dev *pdev)
nic_dev->rq_depth = HINIC_RQ_DEPTH;
nic_dev->sriov_info.hwdev = hwdev;
nic_dev->sriov_info.pdev = pdev;
+   nic_dev->max_qps = num_qps;
 
sema_init(&nic_dev->mgmt_lock, 1);
 
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_tx.c 
b/drivers/net/ethernet/huawei/hinic/hinic_tx.c
index 4c66a0bc1b28..6da761d7a6ef 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_tx.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_tx.c
@@ -470,6 +470,11 @@ netdev_tx_t hinic_xmit_frame(struct sk_buff *skb, struct 
net_device *netdev)
struct hinic_txq *txq;
struct hinic_qp *qp;
 
+   if (unlikely(!netif_carrier_ok(netdev))) {
+   dev_kfree_skb_any(skb);
+   return NETDEV_TX_OK;
+   }
+
txq = &nic_dev->txqs[q_id];
qp = container_of(txq->sq, struct hinic_qp, sq);
 
-- 
2.17.1

RE: [PATCH v10 00/10] exynos-ufs: Add support for UFS HCI

[Alim Akhtar]

> -Original Message-
> From: Alim Akhtar 
> Sent: 28 May 2020 06:47
> To: r...@kernel.org
> Cc: devicet...@vger.kernel.org; linux-s...@vger.kernel.org; k...@kernel.org;
> avri.alt...@wdc.com; martin.peter...@oracle.com;
> kwmad@samsung.com; stanley@mediatek.com;
> c...@codeaurora.org; linux-samsung-...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; Alim Akhtar
> 
> Subject: [PATCH v10 00/10] exynos-ufs: Add support for UFS HCI
> 
> This patch-set introduces UFS (Universal Flash Storage) host controller 
> support
> for Samsung family SoC. Mostly, it consists of UFS PHY and host specific 
> driver.
> 
.
.
.
> Alim Akhtar (9):
>   scsi: ufs: add quirk to fix mishandling utrlclr/utmrlclr
>   scsi: ufs: add quirk to disallow reset of interrupt aggregation
>   scsi: ufs: add quirk to enable host controller without hce
>   scsi: ufs: introduce UFSHCD_QUIRK_PRDT_BYTE_GRAN quirk
>   dt-bindings: phy: Document Samsung UFS PHY bindings
>   phy: samsung-ufs: add UFS PHY driver for samsung SoC
>   dt-bindings: ufs: Add bindings for Samsung ufs host
>   scsi: ufs-exynos: add UFS host support for Exynos SoCs
>   arm64: dts: Add node for ufs exynos7
> 
> Kiwoong Kim (1):
>   scsi: ufs: add quirk to fix abnormal ocs fatal error
> 
>  .../bindings/phy/samsung,ufs-phy.yaml |   75 +
>  .../bindings/ufs/samsung,exynos-ufs.yaml  |   89 ++
>  .../boot/dts/exynos/exynos7-espresso.dts  |4 +
>  arch/arm64/boot/dts/exynos/exynos7.dtsi   |   43 +-
>  drivers/phy/samsung/Kconfig   |9 +
>  drivers/phy/samsung/Makefile  |1 +
>  drivers/phy/samsung/phy-exynos7-ufs.h |   86 ++
>  drivers/phy/samsung/phy-samsung-ufs.c |  380 +
>  drivers/phy/samsung/phy-samsung-ufs.h |  143 ++
>  drivers/scsi/ufs/Kconfig  |   12 +
>  drivers/scsi/ufs/Makefile |1 +
>  drivers/scsi/ufs/ufs-exynos.c | 1292 +
>  drivers/scsi/ufs/ufs-exynos.h |  287 
>  drivers/scsi/ufs/ufshcd.c |  126 +-
>  drivers/scsi/ufs/ufshcd.h |   29 +
>  drivers/scsi/ufs/unipro.h |   33 +
>  16 files changed, 2596 insertions(+), 14 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/phy/samsung,ufs-
> phy.yaml
>  create mode 100644 Documentation/devicetree/bindings/ufs/samsung,exynos-
> ufs.yaml
>  create mode 100644 drivers/phy/samsung/phy-exynos7-ufs.h
>  create mode 100644 drivers/phy/samsung/phy-samsung-ufs.c
>  create mode 100644 drivers/phy/samsung/phy-samsung-ufs.h
>  create mode 100644 drivers/scsi/ufs/ufs-exynos.c
>  create mode 100644 drivers/scsi/ufs/ufs-exynos.h
> 
Hi Martin and Kishon,
Can you please take the patches into your respective trees?
Thanks,

> 
> base-commit: 0e698dfa282211e414076f9dc7e83c1c288314fd
> --
> 2.17.1

[PATCH v31 13/21] x86/sgx: Add a page reclaimer

[Jarkko Sakkinen]

There is a limited amount of EPC available. Therefore, some of it must be
copied to the regular memory, and only subset kept in the SGX reserved
memory. While kernel cannot directly access enclave memory, SGX provides a
set of ENCLS leaf functions to perform reclaiming.

This commits implements a page reclaimer by using these leaf functions. It
picks the victim pages in LRU fashion from all the enclaves running in the
system. The thread ksgxswapd reclaims pages on the event when the number of
free EPC pages goes below SGX_NR_LOW_PAGES up until it reaches
SGX_NR_HIGH_PAGES.

sgx_alloc_epc_page() can optionally directly reclaim pages with @reclaim
set true. A caller must also supply owner for each page so that the
reclaimer can access the associated enclaves. This is needed for locking,
as most of the ENCLS leafs cannot be executed concurrently for an enclave.
The owner is also needed for accessing SECS, which is required to be
resident when its child pages are being reclaimed.

Cc: linux...@kvack.org
Acked-by: Jethro Beekman 
Tested-by: Jethro Beekman 
Tested-by: Jordan Hand 
Tested-by: Nathaniel McCallum 
Tested-by: Chunyang Hui 
Tested-by: Seth Moore 
Co-developed-by: Sean Christopherson 
Signed-off-by: Sean Christopherson 
Signed-off-by: Jarkko Sakkinen 
---
 arch/x86/kernel/cpu/sgx/driver.c |   1 +
 arch/x86/kernel/cpu/sgx/encl.c   | 339 +-
 arch/x86/kernel/cpu/sgx/encl.h   |  41 +++
 arch/x86/kernel/cpu/sgx/ioctl.c  |  76 -
 arch/x86/kernel/cpu/sgx/main.c   | 469 +++
 arch/x86/kernel/cpu/sgx/sgx.h|  13 +
 6 files changed, 932 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/cpu/sgx/driver.c b/arch/x86/kernel/cpu/sgx/driver.c
index d90114cec1c3..997a7f4117c5 100644
--- a/arch/x86/kernel/cpu/sgx/driver.c
+++ b/arch/x86/kernel/cpu/sgx/driver.c
@@ -32,6 +32,7 @@ static int sgx_open(struct inode *inode, struct file *file)
 
atomic_set(&encl->flags, 0);
kref_init(&encl->refcount);
+   INIT_LIST_HEAD(&encl->va_pages);
INIT_RADIX_TREE(&encl->page_tree, GFP_KERNEL);
mutex_init(&encl->lock);
INIT_LIST_HEAD(&encl->mm_list);
diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c
index 5085724595eb..d9be00aa6d4d 100644
--- a/arch/x86/kernel/cpu/sgx/encl.c
+++ b/arch/x86/kernel/cpu/sgx/encl.c
@@ -12,9 +12,83 @@
 #include "encls.h"
 #include "sgx.h"
 
+static int __sgx_encl_eldu(struct sgx_encl_page *encl_page,
+  struct sgx_epc_page *epc_page,
+  struct sgx_epc_page *secs_page)
+{
+   unsigned long va_offset = SGX_ENCL_PAGE_VA_OFFSET(encl_page);
+   struct sgx_encl *encl = encl_page->encl;
+   struct sgx_pageinfo pginfo;
+   struct sgx_backing b;
+   pgoff_t page_index;
+   int ret;
+
+   if (secs_page)
+   page_index = SGX_ENCL_PAGE_INDEX(encl_page);
+   else
+   page_index = PFN_DOWN(encl->size);
+
+   ret = sgx_encl_get_backing(encl, page_index, &b);
+   if (ret)
+   return ret;
+
+   pginfo.addr = SGX_ENCL_PAGE_ADDR(encl_page);
+   pginfo.contents = (unsigned long)kmap_atomic(b.contents);
+   pginfo.metadata = (unsigned long)kmap_atomic(b.pcmd) +
+ b.pcmd_offset;
+
+   if (secs_page)
+   pginfo.secs = (u64)sgx_get_epc_addr(secs_page);
+   else
+   pginfo.secs = 0;
+
+   ret = __eldu(&pginfo, sgx_get_epc_addr(epc_page),
+sgx_get_epc_addr(encl_page->va_page->epc_page) + 
va_offset);
+   if (ret) {
+   if (encls_failed(ret))
+   ENCLS_WARN(ret, "ELDU");
+
+   ret = -EFAULT;
+   }
+
+   kunmap_atomic((void *)(unsigned long)(pginfo.metadata - b.pcmd_offset));
+   kunmap_atomic((void *)(unsigned long)pginfo.contents);
+
+   sgx_encl_put_backing(&b, false);
+
+   return ret;
+}
+
+static struct sgx_epc_page *sgx_encl_eldu(struct sgx_encl_page *encl_page,
+ struct sgx_epc_page *secs_page)
+{
+   unsigned long va_offset = SGX_ENCL_PAGE_VA_OFFSET(encl_page);
+   struct sgx_encl *encl = encl_page->encl;
+   struct sgx_epc_page *epc_page;
+   int ret;
+
+   epc_page = sgx_alloc_epc_page(encl_page, false);
+   if (IS_ERR(epc_page))
+   return epc_page;
+
+   ret = __sgx_encl_eldu(encl_page, epc_page, secs_page);
+   if (ret) {
+   sgx_free_epc_page(epc_page);
+   return ERR_PTR(ret);
+   }
+
+   sgx_free_va_slot(encl_page->va_page, va_offset);
+   list_move(&encl_page->va_page->list, &encl->va_pages);
+   encl_page->desc &= ~SGX_ENCL_PAGE_VA_OFFSET_MASK;
+   encl_page->epc_page = epc_page;
+
+   return epc_page;
+}
+
 static struct sgx_encl_page *sgx_encl_load_page(struct sgx_encl *encl,
unsigned long addr)
 {
+   struct sgx_epc_page *

RE: [PATCH v10 10/10] arm64: dts: Add node for ufs exynos7

[Alim Akhtar]

> -Original Message-
> From: Krzysztof Kozlowski 
> Sent: 29 May 2020 13:36
> To: Alim Akhtar 
> Cc: r...@kernel.org; devicet...@vger.kernel.org; linux-s...@vger.kernel.org;
> avri.alt...@wdc.com; martin.peter...@oracle.com;
> kwmad@samsung.com; stanley@mediatek.com;
> c...@codeaurora.org; linux-samsung-...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v10 10/10] arm64: dts: Add node for ufs exynos7
> 
> On Thu, May 28, 2020 at 06:46:58AM +0530, Alim Akhtar wrote:
> > Adding dt node foe UFS and UFS-PHY for exynos7 SoC.
> >
> > Signed-off-by: Alim Akhtar 
> > Tested-by: Paweł Chmiel 
> > ---
> >  .../boot/dts/exynos/exynos7-espresso.dts  |  4 ++
> >  arch/arm64/boot/dts/exynos/exynos7.dtsi   | 43 ++-
> 
> Thanks, applied to next/dt-late. It might miss this merge window and in such
> case I will keep it for v5.9 cycle.
Thanks Krzysztof.
> 
> Best regards,
> Krzysztof

[PATCH 2/2] nbd: remove unused 'NBD_MAGIC'

[Dongli Zhang]

Remove 'NBD_MAGIC' as it is not used since commit 5ea8d10802ec ("nbd:
separate out the config information").

Signed-off-by: Dongli Zhang 
---
 drivers/block/nbd.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 74c1363702f5..83435ce141a8 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -141,8 +141,6 @@ static struct dentry *nbd_dbg_dir;
 
 #define nbd_name(nbd) ((nbd)->disk->disk_name)
 
-#define NBD_MAGIC 0x68797548
-
 #define NBD_DEF_BLKSIZE 1024
 
 static unsigned int nbds_max = 16;
-- 
2.17.1

[PATCH 0/2] nbd: two cleanup

[Dongli Zhang]

This is just cleanup without functional change.

Thank you very much!

Dongli Zhang

[PATCH 1/2] nbd: append module param and description following corresponding variables

[Dongli Zhang]

A lot of drivers append the module parameter and its description following
the corresponding variables (e.g., 'g_submit_queues' in null or
'admin_timeout' in nvme).

This patch would do the same for 'nbds_max' and 'max_part' in nbd driver.
This makes it much more friendly to cscope when reading the code.

Signed-off-by: Dongli Zhang 
---
 drivers/block/nbd.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 43cff01a5a67..74c1363702f5 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -146,7 +146,13 @@ static struct dentry *nbd_dbg_dir;
 #define NBD_DEF_BLKSIZE 1024
 
 static unsigned int nbds_max = 16;
+module_param(nbds_max, int, 0444);
+MODULE_PARM_DESC(nbds_max, "number of network block devices to initialize 
(default: 16)");
+
 static int max_part = 16;
+module_param(max_part, int, 0444);
+MODULE_PARM_DESC(max_part, "number of partitions per device (default: 16)");
+
 static int part_shift;
 
 static int nbd_dev_dbg_init(struct nbd_device *nbd);
@@ -2444,8 +2450,3 @@ module_exit(nbd_cleanup);
 
 MODULE_DESCRIPTION("Network Block Device");
 MODULE_LICENSE("GPL");
-
-module_param(nbds_max, int, 0444);
-MODULE_PARM_DESC(nbds_max, "number of network block devices to initialize 
(default: 16)");
-module_param(max_part, int, 0444);
-MODULE_PARM_DESC(max_part, "number of partitions per device (default: 16)");
-- 
2.17.1

Re: [V6 PATCH 2/2] ASoC: max98390: Added Amplifier Driver

[Steve Lee]

On Fri, May 29, 2020 at 6:35 PM Mark Brown  wrote:
>
> On Fri, May 29, 2020 at 05:04:36PM +0900, Steve Lee wrote:
> > On Thu, May 28, 2020 at 8:54 PM Mark Brown  wrote:
>
> > > > Reported-by: kbuild test robot 
>
> > > Don't think the lkp bot asked for this driver! :P
>
> >   Thanks, I will send split patch for this.
>
> No, just don't add the line when it's a new driver.

 Now I understand, thanks for guide.

[PATCH v31 21/21] x86/sgx: Update MAINTAINERS

[Jarkko Sakkinen]

Add the maintainer information for the SGX subsystem.

Cc: Thomas Gleixner 
Cc: Borislav Petkov 
Signed-off-by: Jarkko Sakkinen 
---
 MAINTAINERS | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 091ec22c1a23..cdebc57f9901 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8840,6 +8840,17 @@ F:   Documentation/x86/intel_txt.rst
 F: arch/x86/kernel/tboot.c
 F: include/linux/tboot.h
 
+INTEL SGX
+M: Jarkko Sakkinen 
+M: Sean Christopherson 
+L: linux-...@vger.kernel.org
+S: Maintained
+Q: https://patchwork.kernel.org/project/intel-sgx/list/
+T: git https://github.com/jsakkine-intel/linux-sgx.git
+F: arch/x86/include/uapi/asm/sgx.h
+F: arch/x86/kernel/cpu/sgx/*
+K: \bSGX_
+
 INTERCONNECT API
 M: Georgi Djakov 
 L: linux...@vger.kernel.org
-- 
2.25.1

[PATCH v31 20/21] docs: x86/sgx: Document SGX micro architecture and kernel internals

[Jarkko Sakkinen]

Document the Intel SGX kernel architecture. The fine-grained micro
architecture details can be looked up from Intel SDM Volume 3D.

Cc: linux-...@vger.kernel.org
Acked-by: Randy Dunlap 
Co-developed-by: Sean Christopherson 
Signed-off-by: Sean Christopherson 
Signed-off-by: Jarkko Sakkinen 
---
 Documentation/x86/index.rst |   1 +
 Documentation/x86/sgx.rst   | 206 
 2 files changed, 207 insertions(+)
 create mode 100644 Documentation/x86/sgx.rst

diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst
index 265d9e9a093b..807290bf357c 100644
--- a/Documentation/x86/index.rst
+++ b/Documentation/x86/index.rst
@@ -30,3 +30,4 @@ x86-specific Documentation
usb-legacy-support
i386/index
x86_64/index
+   sgx
diff --git a/Documentation/x86/sgx.rst b/Documentation/x86/sgx.rst
new file mode 100644
index ..9609a3409ad1
--- /dev/null
+++ b/Documentation/x86/sgx.rst
@@ -0,0 +1,206 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+
+Architecture
+
+
+*Software Guard eXtensions (SGX)* is a set of instructions that enable ring-3
+applications to set aside private regions of code and data. These regions are
+called enclaves. An enclave can be entered to a fixed set of entry points. Only
+a CPU running inside the enclave can access its code and data.
+
+The support can be determined by
+
+   ``grep sgx /proc/cpuinfo``
+
+Enclave Page Cache
+==
+
+SGX utilizes an *Enclave Page Cache (EPC)* to store pages that are associated
+with an enclave. It is contained in a BIOS reserved region of physical memory.
+Unlike pages used for regular memory, pages can only be accessed outside the
+enclave for different purposes with the instructions **ENCLS**, **ENCLV** and
+**ENCLU**.
+
+Direct memory accesses to an enclave can be only done by a CPU executing inside
+the enclave. An enclave can be entered with **ENCLU[EENTER]** to a fixed set of
+entry points. However, a CPU executing inside the enclave can do outside memory
+accesses.
+
+Page Types
+--
+
+**SGX Enclave Control Structure (SECS)**
+   Enclave's address range, attributes and other global data are defined
+   by this structure.
+
+**Regular (REG)**
+   Regular EPC pages contain the code and data of an enclave.
+
+**Thread Control Structure (TCS)**
+   Thread Control Structure pages define the entry points to an enclave and
+   track the execution state of an enclave thread.
+
+**Version Array (VA)**
+   Version Array pages contain 512 slots, each of which can contain a version
+   number for a page evicted from the EPC.
+
+Enclave Page Cache Map
+--
+
+The processor tracks EPC pages via the *Enclave Page Cache Map (EPCM)*.  EPCM
+contains an entry for each EPC page, which describes the owning enclave, access
+rights and page type among the other things.
+
+The permissions from EPCM is consulted if and only if walking the kernel page
+tables succeeds. The total permissions are thus a conjunction between page 
table
+and EPCM permissions.
+
+For all intents and purposes the SGX architecture allows the processor to
+invalidate all EPCM entries at will, i.e. requires that software be prepared to
+handle an EPCM fault at any time. The contents of EPC are encrypted with an
+ephemeral key, which is lost on power transitions.
+
+EPC management
+==
+
+EPC pages do not have ``struct page`` instances. They are IO memory from kernel
+perspective. The consequence is that they are always mapped as shared memory.
+Kernel defines ``/dev/sgx/enclave`` that can be mapped as ``MAP_SHARED`` to
+define the address range for an enclave.
+
+EPC Over-subscription
+=
+
+When the amount of free EPC pages goes below a low watermark the swapping 
thread
+starts reclaiming pages. The pages that do not have the **A** bit set are
+selected as victim pages.
+
+Launch Control
+==
+
+SGX provides a launch control mechanism. After all enclave pages have been
+copied, kernel executes **ENCLS[EINIT]**, which initializes the enclave. Only
+after this the CPU can execute inside the enclave.
+
+This leaf function takes an RSA-3072 signature of the enclave measurement and 
an
+optional cryptographic token. Linux does not take advantage of launch tokens.
+The instruction checks that the signature is signed with the key defined in
+**IA32_SGXLEPUBKEYHASH?** MSRs and the measurement is correct. If so, the
+enclave is allowed to be executed.
+
+MSRs can be configured by the BIOS to be either readable or writable. Linux
+supports only writable configuration in order to give full control to the 
kernel
+on launch control policy. Readable configuration requires the use of previously
+mentioned launch tokens.
+
+The current kernel implementation supports only writable MSRs. The launch is
+performed by setting the MSRs to the hash of the enclave signer's public key.
+The alternative would be to have *a launch enclave* that would be signed with
+

[PATCH v31 19/21] selftests/x86: Add a selftest for SGX

[Jarkko Sakkinen]

Add a selftest for SGX. It is a trivial test where a simple enclave
copies one 64-bit word of memory between two memory locations.

Cc: linux-kselft...@vger.kernel.org
Signed-off-by: Jarkko Sakkinen 
---
 tools/testing/selftests/Makefile  |   1 +
 tools/testing/selftests/sgx/.gitignore|   2 +
 tools/testing/selftests/sgx/Makefile  |  53 +++
 tools/testing/selftests/sgx/call.S|  54 +++
 tools/testing/selftests/sgx/defines.h |  21 +
 tools/testing/selftests/sgx/load.c| 282 +
 tools/testing/selftests/sgx/main.c| 199 +
 tools/testing/selftests/sgx/main.h|  38 ++
 tools/testing/selftests/sgx/sigstruct.c   | 395 ++
 tools/testing/selftests/sgx/test_encl.c   |  20 +
 tools/testing/selftests/sgx/test_encl.lds |  40 ++
 .../selftests/sgx/test_encl_bootstrap.S   |  89 
 12 files changed, 1194 insertions(+)
 create mode 100644 tools/testing/selftests/sgx/.gitignore
 create mode 100644 tools/testing/selftests/sgx/Makefile
 create mode 100644 tools/testing/selftests/sgx/call.S
 create mode 100644 tools/testing/selftests/sgx/defines.h
 create mode 100644 tools/testing/selftests/sgx/load.c
 create mode 100644 tools/testing/selftests/sgx/main.c
 create mode 100644 tools/testing/selftests/sgx/main.h
 create mode 100644 tools/testing/selftests/sgx/sigstruct.c
 create mode 100644 tools/testing/selftests/sgx/test_encl.c
 create mode 100644 tools/testing/selftests/sgx/test_encl.lds
 create mode 100644 tools/testing/selftests/sgx/test_encl_bootstrap.S

diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 2ff68702fd41..008497495ae4 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -64,6 +64,7 @@ TARGETS += user
 TARGETS += vm
 TARGETS += x86
 TARGETS += zram
+TARGETS += sgx
 #Please keep the TARGETS list alphabetically sorted
 # Run "make quicktest=1 run_tests" or
 # "make quicktest=1 kselftest" from top level Makefile
diff --git a/tools/testing/selftests/sgx/.gitignore 
b/tools/testing/selftests/sgx/.gitignore
new file mode 100644
index ..fbaf0bda9a92
--- /dev/null
+++ b/tools/testing/selftests/sgx/.gitignore
@@ -0,0 +1,2 @@
+test_sgx
+test_encl.elf
diff --git a/tools/testing/selftests/sgx/Makefile 
b/tools/testing/selftests/sgx/Makefile
new file mode 100644
index ..95e5c4df8014
--- /dev/null
+++ b/tools/testing/selftests/sgx/Makefile
@@ -0,0 +1,53 @@
+top_srcdir = ../../../..
+
+include ../lib.mk
+
+.PHONY: all clean
+
+CAN_BUILD_X86_64 := $(shell ../x86/check_cc.sh $(CC) \
+   ../x86/trivial_64bit_program.c)
+
+ifndef OBJCOPY
+OBJCOPY := $(CROSS_COMPILE)objcopy
+endif
+
+INCLUDES := -I$(top_srcdir)/tools/include
+HOST_CFLAGS := -Wall -Werror -g $(INCLUDES) -fPIC -z noexecstack
+ENCL_CFLAGS := -Wall -Werror -static -nostdlib -nostartfiles -fPIC \
+  -fno-stack-protector -mrdrnd $(INCLUDES)
+
+TEST_CUSTOM_PROGS := $(OUTPUT)/test_sgx $(OUTPUT)/test_encl.elf
+
+ifeq ($(CAN_BUILD_X86_64), 1)
+all: $(TEST_CUSTOM_PROGS)
+endif
+
+$(OUTPUT)/test_sgx: $(OUTPUT)/main.o \
+   $(OUTPUT)/load.o \
+   $(OUTPUT)/sigstruct.o \
+   $(OUTPUT)/call.o
+   $(CC) $(HOST_CFLAGS) -o $@ $^ -lcrypto
+
+$(OUTPUT)/main.o: main.c
+   $(CC) $(HOST_CFLAGS) -c $< -o $@
+
+$(OUTPUT)/load.o: load.c
+   $(CC) $(HOST_CFLAGS) -c $< -o $@
+
+$(OUTPUT)/sigstruct.o: sigstruct.c
+   $(CC) $(HOST_CFLAGS) -c $< -o $@
+
+$(OUTPUT)/call.o: call.S
+   $(CC) $(HOST_CFLAGS) -c $< -o $@
+
+$(OUTPUT)/test_encl.elf: test_encl.lds test_encl.c test_encl_bootstrap.S
+   $(CC) $(ENCL_CFLAGS) -T $^ -o $@
+
+EXTRA_CLEAN := \
+   $(OUTPUT)/test_encl.elf \
+   $(OUTPUT)/load.o \
+   $(OUTPUT)/call.o \
+   $(OUTPUT)/main.o \
+   $(OUTPUT)/sigstruct.o \
+   $(OUTPUT)/test_sgx \
+   $(OUTPUT)/test_sgx.o \
diff --git a/tools/testing/selftests/sgx/call.S 
b/tools/testing/selftests/sgx/call.S
new file mode 100644
index ..77131e83db42
--- /dev/null
+++ b/tools/testing/selftests/sgx/call.S
@@ -0,0 +1,54 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */
+/**
+* Copyright(c) 2016-18 Intel Corporation.
+*/
+
+   .text
+
+   .macro ENCLU
+   .byte 0x0f, 0x01, 0xd7
+   .endm
+
+   .text
+
+   .global sgx_call_vdso
+sgx_call_vdso:
+   .cfi_startproc
+   push%r15
+   .cfi_adjust_cfa_offset  8
+   .cfi_rel_offset %r15, 0
+   push%r14
+   .cfi_adjust_cfa_offset  8
+   .cfi_rel_offset %r14, 0
+   push%r13
+   .cfi_adjust_cfa_offset  8
+   .cfi_rel_offset %r13, 0
+   push%r12
+   .cfi_adjust_cfa_offset  8
+   .cfi_rel_offset %r12, 0
+   push%rbx
+   .cfi_adjust_cfa_offset  8
+   .cfi_rel_offset %rbx, 0
+   push$0
+   .cfi_adjust_cfa_offset  8
+   push   

[PATCH v31 16/21] x86/fault: Add helper function to sanitize error code

[Jarkko Sakkinen]

From: Sean Christopherson 

Add helper function to sanitize error code to prepare for vDSO exception
fixup, which will expose the error code to userspace and runs before
set_signal_archinfo(), i.e. suppresses the signal when fixup is successful.

Acked-by: Jethro Beekman 
Signed-off-by: Sean Christopherson 
Signed-off-by: Jarkko Sakkinen 
---
 arch/x86/mm/fault.c | 24 +---
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 16c53c874bb9..23666e34abbc 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -704,6 +704,18 @@ pgtable_bad(struct pt_regs *regs, unsigned long error_code,
oops_end(flags, regs, sig);
 }
 
+static void sanitize_error_code(unsigned long address,
+   unsigned long *error_code)
+{
+   /*
+* To avoid leaking information about the kernel page
+* table layout, pretend that user-mode accesses to
+* kernel addresses are always protection faults.
+*/
+   if (address >= TASK_SIZE_MAX)
+   *error_code |= X86_PF_PROT;
+}
+
 static void set_signal_archinfo(unsigned long address,
unsigned long error_code)
 {
@@ -760,6 +772,8 @@ no_context(struct pt_regs *regs, unsigned long error_code,
 * faulting through the emulate_vsyscall() logic.
 */
if (current->thread.sig_on_uaccess_err && signal) {
+   sanitize_error_code(address, &error_code);
+
set_signal_archinfo(address, error_code);
 
/* XXX: hwpoison faults will set the wrong code. */
@@ -908,13 +922,7 @@ __bad_area_nosemaphore(struct pt_regs *regs, unsigned long 
error_code,
if (is_errata100(regs, address))
return;
 
-   /*
-* To avoid leaking information about the kernel page table
-* layout, pretend that user-mode accesses to kernel addresses
-* are always protection faults.
-*/
-   if (address >= TASK_SIZE_MAX)
-   error_code |= X86_PF_PROT;
+   sanitize_error_code(address, &error_code);
 
if (likely(show_unhandled_signals))
show_signal_msg(regs, error_code, address, tsk);
@@ -1031,6 +1039,8 @@ do_sigbus(struct pt_regs *regs, unsigned long error_code, 
unsigned long address,
if (is_prefetch(regs, error_code, address))
return;
 
+   sanitize_error_code(address, &error_code);
+
set_signal_archinfo(address, error_code);
 
 #ifdef CONFIG_MEMORY_FAILURE
-- 
2.25.1

[PATCH v31 15/21] x86/vdso: Add support for exception fixup in vDSO functions

[Jarkko Sakkinen]

From: Sean Christopherson 

The basic concept and implementation is very similar to the kernel's
exception fixup mechanism.  The key differences are that the kernel
handler is hardcoded and the fixup entry addresses are relative to
the overall table as opposed to individual entries.

Hardcoding the kernel handler avoids the need to figure out how to
get userspace code to point at a kernel function.  Given that the
expected usage is to propagate information to userspace, dumping all
fault information into registers is likely the desired behavior for
the vast majority of yet-to-be-created functions.  Use registers
DI, SI and DX to communicate fault information, which follows Linux's
ABI for register consumption and hopefully avoids conflict with
hardware features that might leverage the fixup capabilities, e.g.
register usage for SGX instructions was at least partially designed
with calling conventions in mind.

Making fixup addresses relative to the overall table allows the table
to be stripped from the final vDSO image (it's a kernel construct)
without complicating the offset logic, e.g. entry-relative addressing
would also need to account for the table's location relative to the
image.

Regarding stripping the table, modify vdso2c to extract the table from
the raw, a.k.a. unstripped, data and dump it as a standalone byte array
in the resulting .c file.  The original base of the table, its length
and a pointer to the byte array are captured in struct vdso_image.
Alternatively, the table could be dumped directly into the struct,
but because the number of entries can vary per image, that would
require either hardcoding a max sized table into the struct definition
or defining the table as a flexible length array.  The flexible length
array approach has zero benefits, e.g. the base/size are still needed,
and prevents reusing the extraction code, while hardcoding the max size
adds ongoing maintenance just to avoid exporting the explicit size.

The immediate use case is for Intel Software Guard Extensions (SGX).
SGX introduces a new CPL3-only "enclave" mode that runs as a sort of
black box shared object that is hosted by an untrusted "normal" CPl3
process.

Entering an enclave can only be done through SGX-specific instructions,
EENTER and ERESUME, and is a non-trivial process.  Because of the
complexity of transitioning to/from an enclave, the vast majority of
enclaves are expected to utilize a library to handle the actual
transitions.  This is roughly analogous to how e.g. libc implementations
are used by most applications.

Another crucial characteristic of SGX enclaves is that they can generate
exceptions as part of their normal (at least as "normal" as SGX can be)
operation that need to be handled *in* the enclave and/or are unique
to SGX.

And because they are essentially fancy shared objects, a process can
host any number of enclaves, each of which can execute multiple threads
simultaneously.

Putting everything together, userspace enclaves will utilize a library
that must be prepared to handle any and (almost) all exceptions any time
at least one thread may be executing in an enclave.  Leveraging signals
to handle the enclave exceptions is unpleasant, to put it mildly, e.g.
the SGX library must constantly (un)register its signal handler based
on whether or not at least one thread is executing in an enclave, and
filter and forward exceptions that aren't related to its enclaves.  This
becomes particularly nasty when using multiple levels of libraries that
register signal handlers, e.g. running an enclave via cgo inside of the
Go runtime.

Enabling exception fixup in vDSO allows the kernel to provide a vDSO
function that wraps the low-level transitions to/from the enclave, i.e.
the EENTER and ERESUME instructions.  The vDSO function can intercept
exceptions that would otherwise generate a signal and return the fault
information directly to its caller, thus avoiding the need to juggle
signal handlers.

Note that unlike the kernel's _ASM_EXTABLE_HANDLE implementation, the
'C' version of _ASM_VDSO_EXTABLE_HANDLE doesn't use a pre-compiled
assembly macro.  Duplicating four lines of code is simpler than adding
the necessary infrastructure to generate pre-compiled assembly and the
intended benefit of massaging GCC's inlining algorithm is unlikely to
realized in the vDSO any time soon, if ever.

Suggested-by: Andy Lutomirski 
Acked-by: Jethro Beekman 
Signed-off-by: Sean Christopherson 
Signed-off-by: Jarkko Sakkinen 
---
 arch/x86/entry/vdso/Makefile  |  6 +--
 arch/x86/entry/vdso/extable.c | 46 +
 arch/x86/entry/vdso/extable.h | 29 ++
 arch/x86/entry/vdso/vdso-layout.lds.S |  9 -
 arch/x86/entry/vdso/vdso2c.h  | 58 +++
 arch/x86/include/asm/vdso.h   |  5 +++
 6 files changed, 141 insertions(+), 12 deletions(-)
 create mode 100644 arch/x86/entry/vdso/extable.c
 create mode 100644 arch/x86/entry/vdso/extable.h

diff 

[PATCH v31 18/21] x86/vdso: Implement a vDSO for Intel SGX enclave call

[Jarkko Sakkinen]

From: Sean Christopherson 

An SGX runtime must be aware of the exceptions, which happen inside an
enclave. Introduce a vDSO call that wraps EENTER/ERESUME cycle and returns
the CPU exception back to the caller exactly when it happens.

Kernel fixups the exception information to RDI, RSI and RDX. The SGX call
vDSO handler fills this information to the user provided buffer or
alternatively trigger user provided callback at the time of the exception.

The calling convention is custom and does not follow System V x86-64 ABI.

Suggested-by: Andy Lutomirski 
Acked-by: Jethro Beekman 
Tested-by: Jethro Beekman 
Signed-off-by: Sean Christopherson 
Co-developed-by: Cedric Xing 
Signed-off-by: Cedric Xing 
Signed-off-by: Jarkko Sakkinen 
---
 arch/x86/entry/vdso/Makefile |   2 +
 arch/x86/entry/vdso/vdso.lds.S   |   1 +
 arch/x86/entry/vdso/vsgx_enter_enclave.S | 131 +++
 arch/x86/include/asm/enclu.h |   8 ++
 arch/x86/include/uapi/asm/sgx.h  |  98 +
 5 files changed, 240 insertions(+)
 create mode 100644 arch/x86/entry/vdso/vsgx_enter_enclave.S
 create mode 100644 arch/x86/include/asm/enclu.h

diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index 657e01d34d02..fa50c76a17a8 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -24,6 +24,7 @@ VDSO32-$(CONFIG_IA32_EMULATION)   := y
 
 # files to link into the vdso
 vobjs-y := vdso-note.o vclock_gettime.o vgetcpu.o
+vobjs-$(VDSO64-y)  += vsgx_enter_enclave.o
 
 # files to link into kernel
 obj-y  += vma.o extable.o
@@ -90,6 +91,7 @@ $(vobjs): KBUILD_CFLAGS := $(filter-out $(GCC_PLUGINS_CFLAGS) 
$(RETPOLINE_CFLAGS
 CFLAGS_REMOVE_vclock_gettime.o = -pg
 CFLAGS_REMOVE_vdso32/vclock_gettime.o = -pg
 CFLAGS_REMOVE_vgetcpu.o = -pg
+CFLAGS_REMOVE_vsgx_enter_enclave.o = -pg
 
 #
 # X32 processes use x32 vDSO to access 64bit kernel data.
diff --git a/arch/x86/entry/vdso/vdso.lds.S b/arch/x86/entry/vdso/vdso.lds.S
index 36b644e16272..4bf48462fca7 100644
--- a/arch/x86/entry/vdso/vdso.lds.S
+++ b/arch/x86/entry/vdso/vdso.lds.S
@@ -27,6 +27,7 @@ VERSION {
__vdso_time;
clock_getres;
__vdso_clock_getres;
+   __vdso_sgx_enter_enclave;
local: *;
};
 }
diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S 
b/arch/x86/entry/vdso/vsgx_enter_enclave.S
new file mode 100644
index ..be7e467e1efb
--- /dev/null
+++ b/arch/x86/entry/vdso/vsgx_enter_enclave.S
@@ -0,0 +1,131 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "extable.h"
+
+#define EX_LEAF0*8
+#define EX_TRAPNR  0*8+4
+#define EX_ERROR_CODE  0*8+6
+#define EX_ADDRESS 1*8
+
+.code64
+.section .text, "ax"
+
+SYM_FUNC_START(__vdso_sgx_enter_enclave)
+   /* Prolog */
+   .cfi_startproc
+   push%rbp
+   .cfi_adjust_cfa_offset  8
+   .cfi_rel_offset %rbp, 0
+   mov %rsp, %rbp
+   .cfi_def_cfa_register   %rbp
+   push%rbx
+   .cfi_rel_offset %rbx, -8
+
+   mov %ecx, %eax
+.Lenter_enclave:
+   /* EENTER <= leaf <= ERESUME */
+   cmp $EENTER, %eax
+   jb  .Linvalid_leaf
+   cmp $ERESUME, %eax
+   ja  .Linvalid_leaf
+
+   /* Load TCS and AEP */
+   mov 0x10(%rbp), %rbx
+   lea .Lasync_exit_pointer(%rip), %rcx
+
+   /* Single ENCLU serving as both EENTER and AEP (ERESUME) */
+.Lasync_exit_pointer:
+.Lenclu_eenter_eresume:
+   enclu
+
+   /* EEXIT jumps here unless the enclave is doing something fancy. */
+   xor %eax, %eax
+
+   /* Invoke userspace's exit handler if one was provided. */
+.Lhandle_exit:
+   cmp $0, 0x20(%rbp)
+   jne .Linvoke_userspace_handler
+
+.Lout:
+   pop %rbx
+   leave
+   .cfi_def_cfa%rsp, 8
+   ret
+
+   /* The out-of-line code runs with the pre-leave stack frame. */
+   .cfi_def_cfa%rbp, 16
+
+.Linvalid_leaf:
+   mov $(-EINVAL), %eax
+   jmp .Lout
+
+.Lhandle_exception:
+   mov 0x18(%rbp), %rcx
+   test%rcx, %rcx
+   je  .Lskip_exception_info
+
+   /* Fill optional exception info. */
+   mov %eax, EX_LEAF(%rcx)
+   mov %di,  EX_TRAPNR(%rcx)
+   mov %si,  EX_ERROR_CODE(%rcx)
+   mov %rdx, EX_ADDRESS(%rcx)
+.Lskip_exception_info:
+   mov $(-EFAULT), %eax
+   jmp .Lhandle_exit
+
+.Linvoke_userspace_handler:
+   /* Pass the untrusted RSP (at exit) to the callback via %rcx. */
+   mov %rsp, %rcx
+
+   /* Save the untrusted RSP offset in %rbx (non-volatile register). */
+   mov %rsp, %rbx
+   and $0xf, %rbx
+
+   /*
+* Align stack per x86_64 ABI. Note, %rsp needs to be 16-byte aligned
+* _after_ pushing the parameters on the stack, hence the

[PATCH v31 17/21] x86/traps: Attempt to fixup exceptions in vDSO before signaling

[Jarkko Sakkinen]

From: Sean Christopherson 

vDSO functions can now leverage an exception fixup mechanism similar to
kernel exception fixup.  For vDSO exception fixup, the initial user is
Intel's Software Guard Extensions (SGX), which will wrap the low-level
transitions to/from the enclave, i.e. EENTER and ERESUME instructions,
in a vDSO function and leverage fixup to intercept exceptions that would
otherwise generate a signal.  This allows the vDSO wrapper to return the
fault information directly to its caller, obviating the need for SGX
applications and libraries to juggle signal handlers.

Attempt to fixup vDSO exceptions immediately prior to populating and
sending signal information.  Except for the delivery mechanism, an
exception in a vDSO function should be treated like any other exception
in userspace, e.g. any fault that is successfully handled by the kernel
should not be directly visible to userspace.

Although it's debatable whether or not all exceptions are of interest to
enclaves, defer to the vDSO fixup to decide whether to do fixup or
generate a signal.  Future users of vDSO fixup, if there ever are any,
will undoubtedly have different requirements than SGX enclaves, e.g. the
fixup vs. signal logic can be made function specific if/when necessary.

Suggested-by: Andy Lutomirski 
Acked-by: Jethro Beekman 
Signed-off-by: Sean Christopherson 
Signed-off-by: Jarkko Sakkinen 
---
 arch/x86/kernel/traps.c | 14 ++
 arch/x86/mm/fault.c |  8 
 2 files changed, 22 insertions(+)

diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index d54cffdc7cac..cce8fb2c560d 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -57,6 +57,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_X86_64
 #include 
@@ -206,6 +207,9 @@ do_trap_no_signal(struct task_struct *tsk, int trapnr, 
const char *str,
tsk->thread.error_code = error_code;
tsk->thread.trap_nr = trapnr;
die(str, regs, error_code);
+   } else {
+   if (fixup_vdso_exception(regs, trapnr, error_code, 0))
+   return 0;
}
 
/*
@@ -538,6 +542,9 @@ dotraplinkage void do_general_protection(struct pt_regs 
*regs, long error_code)
tsk->thread.error_code = error_code;
tsk->thread.trap_nr = X86_TRAP_GP;
 
+   if (fixup_vdso_exception(regs, X86_TRAP_GP, error_code, 0))
+   return;
+
show_signal(tsk, SIGSEGV, "", desc, regs, error_code);
force_sig(SIGSEGV);
 
@@ -791,6 +798,10 @@ dotraplinkage void do_debug(struct pt_regs *regs, long 
error_code)
SIGTRAP) == NOTIFY_STOP)
goto exit;
 
+   if (user_mode(regs) &&
+   fixup_vdso_exception(regs, X86_TRAP_DB, error_code, 0))
+   goto exit;
+
/*
 * Let others (NMI) know that the debug stack is in use
 * as we may switch to the interrupt stack.
@@ -871,6 +882,9 @@ static void math_error(struct pt_regs *regs, int 
error_code, int trapnr)
if (!si_code)
return;
 
+   if (fixup_vdso_exception(regs, trapnr, error_code, 0))
+   return;
+
force_sig_fault(SIGFPE, si_code,
(void __user *)uprobe_get_trap_addr(regs));
 }
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 23666e34abbc..e9ed3c7299ac 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -30,6 +30,7 @@
 #include   /* store_idt(), ... */
 #include /* exception stack  
*/
 #include  /* VMALLOC_START, ...   */
+#include   /* fixup_vdso_exception()   */
 
 #define CREATE_TRACE_POINTS
 #include 
@@ -924,6 +925,10 @@ __bad_area_nosemaphore(struct pt_regs *regs, unsigned long 
error_code,
 
sanitize_error_code(address, &error_code);
 
+   if (fixup_vdso_exception(regs, X86_TRAP_PF, error_code,
+   address))
+   return;
+
if (likely(show_unhandled_signals))
show_signal_msg(regs, error_code, address, tsk);
 
@@ -1041,6 +1046,9 @@ do_sigbus(struct pt_regs *regs, unsigned long error_code, 
unsigned long address,
 
sanitize_error_code(address, &error_code);
 
+   if (fixup_vdso_exception(regs, X86_TRAP_PF, error_code, address))
+   return;
+
set_signal_archinfo(address, error_code);
 
 #ifdef CONFIG_MEMORY_FAILURE
-- 
2.25.1

[PATCH v31 14/21] x86/sgx: ptrace() support for the SGX driver

[Jarkko Sakkinen]

Add VMA callbacks for ptrace() that can be used with debug enclaves.
With debug enclaves data can be read and write the memory word at a time
by using ENCLS(EDBGRD) and ENCLS(EDBGWR) leaf instructions.

Acked-by: Jethro Beekman 
Signed-off-by: Jarkko Sakkinen 
---
 arch/x86/kernel/cpu/sgx/encl.c | 87 ++
 1 file changed, 87 insertions(+)

diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c
index d9be00aa6d4d..df4ae76dd83f 100644
--- a/arch/x86/kernel/cpu/sgx/encl.c
+++ b/arch/x86/kernel/cpu/sgx/encl.c
@@ -333,10 +333,97 @@ static int sgx_vma_mprotect(struct vm_area_struct *vma, 
unsigned long start,
calc_vm_prot_bits(prot, 0));
 }
 
+static int sgx_edbgrd(struct sgx_encl *encl, struct sgx_encl_page *page,
+ unsigned long addr, void *data)
+{
+   unsigned long offset = addr & ~PAGE_MASK;
+   int ret;
+
+
+   ret = __edbgrd(sgx_get_epc_addr(page->epc_page) + offset, data);
+   if (ret)
+   return -EIO;
+
+   return 0;
+}
+
+static int sgx_edbgwr(struct sgx_encl *encl, struct sgx_encl_page *page,
+ unsigned long addr, void *data)
+{
+   unsigned long offset = addr & ~PAGE_MASK;
+   int ret;
+
+   ret = __edbgwr(sgx_get_epc_addr(page->epc_page) + offset, data);
+   if (ret)
+   return -EIO;
+
+   return 0;
+}
+
+static int sgx_vma_access(struct vm_area_struct *vma, unsigned long addr,
+ void *buf, int len, int write)
+{
+   struct sgx_encl *encl = vma->vm_private_data;
+   struct sgx_encl_page *entry = NULL;
+   char data[sizeof(unsigned long)];
+   unsigned long align;
+   unsigned int flags;
+   int offset;
+   int cnt;
+   int ret = 0;
+   int i;
+
+   /* If process was forked, VMA is still there but vm_private_data is set
+* to NULL.
+*/
+   if (!encl)
+   return -EFAULT;
+
+   flags = atomic_read(&encl->flags);
+
+   if (!(flags & SGX_ENCL_DEBUG) || !(flags & SGX_ENCL_INITIALIZED) ||
+   (flags & SGX_ENCL_DEAD))
+   return -EFAULT;
+
+   for (i = 0; i < len; i += cnt) {
+   entry = sgx_encl_reserve_page(encl, (addr + i) & PAGE_MASK);
+   if (IS_ERR(entry)) {
+   ret = PTR_ERR(entry);
+   break;
+   }
+
+   align = ALIGN_DOWN(addr + i, sizeof(unsigned long));
+   offset = (addr + i) & (sizeof(unsigned long) - 1);
+   cnt = sizeof(unsigned long) - offset;
+   cnt = min(cnt, len - i);
+
+   ret = sgx_edbgrd(encl, entry, align, data);
+   if (ret)
+   goto out;
+
+   if (write) {
+   memcpy(data + offset, buf + i, cnt);
+   ret = sgx_edbgwr(encl, entry, align, data);
+   if (ret)
+   goto out;
+   } else
+   memcpy(buf + i, data + offset, cnt);
+
+out:
+   mutex_unlock(&encl->lock);
+
+   if (ret)
+   break;
+   }
+
+   return ret < 0 ? ret : i;
+}
+
 const struct vm_operations_struct sgx_vm_ops = {
.open = sgx_vma_open,
.fault = sgx_vma_fault,
.may_mprotect = sgx_vma_mprotect,
+   .access = sgx_vma_access,
 };
 
 /**
-- 
2.25.1

[PATCH v31 10/21] mm: Introduce vm_ops->may_mprotect()

[Jarkko Sakkinen]

From: Sean Christopherson 

Add vm_ops()->may_mprotect() to check additional constraints.

SGX uses this callback to add two constraints:

1. Verify that the address range does not have holes: for each page
   address, there is an actual enclave page created.
2. Mapped permissions do not surpass the lowest enclave page permissions
   in the address range.

linux...@kvack.org
Andrew Morton 
Acked-by: Jethro Beekman 
Signed-off-by: Sean Christopherson 
Signed-off-by: Jarkko Sakkinen 
---
 include/linux/mm.h |  2 ++
 mm/mprotect.c  | 14 +++---
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 5a323422d783..dbcc2846b3b8 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -546,6 +546,8 @@ struct vm_operations_struct {
void (*close)(struct vm_area_struct * area);
int (*split)(struct vm_area_struct * area, unsigned long addr);
int (*mremap)(struct vm_area_struct * area);
+   int (*may_mprotect)(struct vm_area_struct *vma, unsigned long start,
+   unsigned long end, unsigned long prot);
vm_fault_t (*fault)(struct vm_fault *vmf);
vm_fault_t (*huge_fault)(struct vm_fault *vmf,
enum page_entry_size pe_size);
diff --git a/mm/mprotect.c b/mm/mprotect.c
index 494192ca954b..079ba92df377 100644
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -603,13 +603,21 @@ static int do_mprotect_pkey(unsigned long start, size_t 
len,
goto out;
}
 
+   tmp = vma->vm_end;
+   if (tmp > end)
+   tmp = end;
+
+   if (vma->vm_ops && vma->vm_ops->may_mprotect) {
+   error = vma->vm_ops->may_mprotect(vma, nstart, tmp,
+ prot);
+   if (error)
+   goto out;
+   }
+
error = security_file_mprotect(vma, reqprot, prot);
if (error)
goto out;
 
-   tmp = vma->vm_end;
-   if (tmp > end)
-   tmp = end;
error = mprotect_fixup(vma, &prev, nstart, tmp, newflags);
if (error)
goto out;
-- 
2.25.1

[PATCH v31 12/21] x86/sgx: Add provisioning

[Jarkko Sakkinen]

In order to provide a mechanism for devilering provisoning rights:

1. Add a new device file /dev/sgx/provision that works as a token for
   allowing an enclave to have the provisioning privileges.
2. Add a new ioctl called SGX_IOC_ENCLAVE_SET_ATTRIBUTE that accepts the
   following data structure:

   struct sgx_enclave_set_attribute {
   __u64 addr;
   __u64 attribute_fd;
   };

A daemon could sit on top of /dev/sgx/provision and send a file
descriptor of this file to a process that needs to be able to provision
enclaves.

The way this API is used is straight-forward. Lets assume that dev_fd is
a handle to /dev/sgx/enclave and prov_fd is a handle to
/dev/sgx/provision.  You would allow SGX_IOC_ENCLAVE_CREATE to
initialize an enclave with the PROVISIONKEY attribute by

params.addr = ;
params.token_fd = prov_fd;

ioctl(dev_fd, SGX_IOC_ENCLAVE_SET_ATTRIBUTE, ¶ms);

Cc: linux-security-mod...@vger.kernel.org
Acked-by: Jethro Beekman 
Suggested-by: Andy Lutomirski 
Signed-off-by: Jarkko Sakkinen 
---
 arch/x86/include/uapi/asm/sgx.h  | 11 
 arch/x86/kernel/cpu/sgx/driver.c | 14 ++
 arch/x86/kernel/cpu/sgx/driver.h |  2 ++
 arch/x86/kernel/cpu/sgx/ioctl.c  | 47 
 4 files changed, 74 insertions(+)

diff --git a/arch/x86/include/uapi/asm/sgx.h b/arch/x86/include/uapi/asm/sgx.h
index 5edb08ab8fd0..57d0d30c79b3 100644
--- a/arch/x86/include/uapi/asm/sgx.h
+++ b/arch/x86/include/uapi/asm/sgx.h
@@ -25,6 +25,8 @@ enum sgx_page_flags {
_IOWR(SGX_MAGIC, 0x01, struct sgx_enclave_add_pages)
 #define SGX_IOC_ENCLAVE_INIT \
_IOW(SGX_MAGIC, 0x02, struct sgx_enclave_init)
+#define SGX_IOC_ENCLAVE_SET_ATTRIBUTE \
+   _IOW(SGX_MAGIC, 0x03, struct sgx_enclave_set_attribute)
 
 /**
  * struct sgx_enclave_create - parameter structure for the
@@ -63,4 +65,13 @@ struct sgx_enclave_init {
__u64 sigstruct;
 };
 
+/**
+ * struct sgx_enclave_set_attribute - parameter structure for the
+ *   %SGX_IOC_ENCLAVE_SET_ATTRIBUTE ioctl
+ * @attribute_fd:  file handle of the attribute file in the securityfs
+ */
+struct sgx_enclave_set_attribute {
+   __u64 attribute_fd;
+};
+
 #endif /* _UAPI_ASM_X86_SGX_H */
diff --git a/arch/x86/kernel/cpu/sgx/driver.c b/arch/x86/kernel/cpu/sgx/driver.c
index b4aa7b9f8376..d90114cec1c3 100644
--- a/arch/x86/kernel/cpu/sgx/driver.c
+++ b/arch/x86/kernel/cpu/sgx/driver.c
@@ -150,6 +150,13 @@ static struct miscdevice sgx_dev_enclave = {
.fops = &sgx_encl_fops,
 };
 
+static struct miscdevice sgx_dev_provision = {
+   .minor = MISC_DYNAMIC_MINOR,
+   .name = "provision",
+   .nodename = "sgx/provision",
+   .fops = &sgx_provision_fops,
+};
+
 int __init sgx_drv_init(void)
 {
unsigned int eax, ebx, ecx, edx;
@@ -190,5 +197,12 @@ int __init sgx_drv_init(void)
return ret;
}
 
+   ret = misc_register(&sgx_dev_provision);
+   if (ret) {
+   pr_err("Creating /dev/sgx/provision failed with %d.\n", ret);
+   misc_deregister(&sgx_dev_enclave);
+   return ret;
+   }
+
return 0;
 }
diff --git a/arch/x86/kernel/cpu/sgx/driver.h b/arch/x86/kernel/cpu/sgx/driver.h
index e4063923115b..72747d01c046 100644
--- a/arch/x86/kernel/cpu/sgx/driver.h
+++ b/arch/x86/kernel/cpu/sgx/driver.h
@@ -23,6 +23,8 @@ extern u64 sgx_attributes_reserved_mask;
 extern u64 sgx_xfrm_reserved_mask;
 extern u32 sgx_xsave_size_tbl[64];
 
+extern const struct file_operations sgx_provision_fops;
+
 long sgx_ioctl(struct file *filep, unsigned int cmd, unsigned long arg);
 
 int sgx_drv_init(void);
diff --git a/arch/x86/kernel/cpu/sgx/ioctl.c b/arch/x86/kernel/cpu/sgx/ioctl.c
index 757cb9a4ae70..713bce437659 100644
--- a/arch/x86/kernel/cpu/sgx/ioctl.c
+++ b/arch/x86/kernel/cpu/sgx/ioctl.c
@@ -669,6 +669,50 @@ static long sgx_ioc_enclave_init(struct sgx_encl *encl, 
void __user *arg)
return ret;
 }
 
+/**
+ * sgx_ioc_enclave_set_attribute - handler for %SGX_IOC_ENCLAVE_SET_ATTRIBUTE
+ * @filep: open file to /dev/sgx
+ * @arg:   userspace pointer to a struct sgx_enclave_set_attribute instance
+ *
+ * Mark the enclave as being allowed to access a restricted attribute bit.
+ * The requested attribute is specified via the attribute_fd field in the
+ * provided struct sgx_enclave_set_attribute.  The attribute_fd must be a
+ * handle to an SGX attribute file, e.g. ???/dev/sgx/provision".
+ *
+ * Failure to explicitly request access to a restricted attribute will cause
+ * sgx_ioc_enclave_init() to fail.  Currently, the only restricted attribute
+ * is access to the PROVISION_KEY.
+ *
+ * Note, access to the EINITTOKEN_KEY is disallowed entirely.
+ *
+ * Return: 0 on success, -errno otherwise
+ */
+static long sgx_ioc_enclave_set_attribute(struct sgx_encl *encl,
+ void __user *arg)
+{
+   struct sgx_enclave_set_attribute params;
+   struct file *attribute_file;
+ 

[PATCH v31 05/21] x86/sgx: Add wrappers for ENCLS leaf functions

[Jarkko Sakkinen]

ENCLS is a ring 0 instruction, which contains a set of leaf functions for
managing an enclave. Enclaves are measured and signed software entities,
which are protected by asserting the outside memory accesses and memory
encryption.

Add a two-layer macro system along with an encoding scheme to allow
wrappers to return trap numbers along ENCLS-specific error codes. The
bottom layer of the macro system splits between the leafs that return an
error code and those that do not. The second layer generates the correct
input/output annotations based on the number of operands for each leaf
function.

ENCLS leaf functions are documented in

  Intel SDM: 36.6 ENCLAVE INSTRUCTIONS AND INTEL®

Acked-by: Jethro Beekman 
Co-developed-by: Sean Christopherson 
Signed-off-by: Sean Christopherson 
Signed-off-by: Jarkko Sakkinen 
---
 arch/x86/kernel/cpu/sgx/encls.h | 238 
 1 file changed, 238 insertions(+)
 create mode 100644 arch/x86/kernel/cpu/sgx/encls.h

diff --git a/arch/x86/kernel/cpu/sgx/encls.h b/arch/x86/kernel/cpu/sgx/encls.h
new file mode 100644
index ..f716b4328614
--- /dev/null
+++ b/arch/x86/kernel/cpu/sgx/encls.h
@@ -0,0 +1,238 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */
+#ifndef _X86_ENCLS_H
+#define _X86_ENCLS_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "sgx.h"
+
+enum sgx_encls_leaf {
+   ECREATE = 0x00,
+   EADD= 0x01,
+   EINIT   = 0x02,
+   EREMOVE = 0x03,
+   EDGBRD  = 0x04,
+   EDGBWR  = 0x05,
+   EEXTEND = 0x06,
+   ELDU= 0x08,
+   EBLOCK  = 0x09,
+   EPA = 0x0A,
+   EWB = 0x0B,
+   ETRACK  = 0x0C,
+};
+
+/**
+ * ENCLS_FAULT_FLAG - flag signifying an ENCLS return code is a trapnr
+ *
+ * ENCLS has its own (positive value) error codes and also generates
+ * ENCLS specific #GP and #PF faults.  And the ENCLS values get munged
+ * with system error codes as everything percolates back up the stack.
+ * Unfortunately (for us), we need to precisely identify each unique
+ * error code, e.g. the action taken if EWB fails varies based on the
+ * type of fault and on the exact SGX error code, i.e. we can't simply
+ * convert all faults to -EFAULT.
+ *
+ * To make all three error types coexist, we set bit 30 to identify an
+ * ENCLS fault.  Bit 31 (technically bits N:31) is used to differentiate
+ * between positive (faults and SGX error codes) and negative (system
+ * error codes) values.
+ */
+#define ENCLS_FAULT_FLAG 0x4000
+
+/* Retrieve the encoded trapnr from the specified return code. */
+#define ENCLS_TRAPNR(r) ((r) & ~ENCLS_FAULT_FLAG)
+
+/* Issue a WARN() about an ENCLS leaf. */
+#define ENCLS_WARN(r, name) {\
+   do {  \
+   int _r = (r); \
+   WARN_ONCE(_r, "%s returned %d (0x%x)\n", (name), _r, _r); \
+   } while (0);  \
+}
+
+/**
+ * encls_failed() - Check if an ENCLS leaf function failed
+ * @ret:   the return value of an ENCLS leaf function call
+ *
+ * Check if an ENCLS leaf function failed. This happens when the leaf function
+ * causes a fault that is not caused by an EPCM conflict or when the leaf
+ * function returns a non-zero value.
+ */
+static inline bool encls_failed(int ret)
+{
+   int epcm_trapnr;
+
+   if (boot_cpu_has(X86_FEATURE_SGX2))
+   epcm_trapnr = X86_TRAP_PF;
+   else
+   epcm_trapnr = X86_TRAP_GP;
+
+   if (ret & ENCLS_FAULT_FLAG)
+   return ENCLS_TRAPNR(ret) != epcm_trapnr;
+
+   return !!ret;
+}
+
+/**
+ * __encls_ret_N - encode an ENCLS leaf that returns an error code in EAX
+ * @rax:   leaf number
+ * @inputs:asm inputs for the leaf
+ *
+ * Emit assembly for an ENCLS leaf that returns an error code, e.g. EREMOVE.
+ * And because SGX isn't complex enough as it is, leafs that return an error
+ * code also modify flags.
+ *
+ * Return:
+ * 0 on success,
+ * SGX error code on failure
+ */
+#define __encls_ret_N(rax, inputs...)  \
+   ({  \
+   int ret;\
+   asm volatile(   \
+   "1: .byte 0x0f, 0x01, 0xcf;\n\t"\
+   "2:\n"  \
+   ".section .fixup,\"ax\"\n"  \
+   "3: orl $"__stringify(ENCLS_FAULT_FLAG)",%%eax\n"   \
+   "   jmp 2b\n"   \
+   ".previous\n"   \
+   _ASM_EXTABLE_FAULT(1b, 3b)  \
+   : "=a"(ret) \
+   : "a"(rax), inputs  

[PATCH v31 09/21] x86/sgx: Add __sgx_alloc_epc_page() and sgx_free_epc_page()

[Jarkko Sakkinen]

Add __sgx_alloc_epc_page(), which iterates through EPC sections and borrows
a page structure that is not used by anyone else. When a page is no longer
needed it must be released with sgx_free_epc_page(). This function
implicitly calls ENCLS[EREMOVE], which will return the page to the
uninitialized state (i.e. not required from caller part).

Acked-by: Jethro Beekman 
Co-developed-by: Sean Christopherson 
Signed-off-by: Sean Christopherson 
Signed-off-by: Jarkko Sakkinen 
---
 arch/x86/kernel/cpu/sgx/main.c | 61 ++
 arch/x86/kernel/cpu/sgx/sgx.h  |  3 ++
 2 files changed, 64 insertions(+)

diff --git a/arch/x86/kernel/cpu/sgx/main.c b/arch/x86/kernel/cpu/sgx/main.c
index c5831e3db14a..b776d249289f 100644
--- a/arch/x86/kernel/cpu/sgx/main.c
+++ b/arch/x86/kernel/cpu/sgx/main.c
@@ -83,6 +83,67 @@ static bool __init sgx_page_reclaimer_init(void)
return true;
 }
 
+static struct sgx_epc_page *__sgx_alloc_epc_page_from_section(struct 
sgx_epc_section *section)
+{
+   struct sgx_epc_page *page;
+
+   if (list_empty(§ion->page_list))
+   return NULL;
+
+   page = list_first_entry(§ion->page_list, struct sgx_epc_page, list);
+   list_del_init(&page->list);
+   return page;
+}
+
+/**
+ * __sgx_alloc_epc_page() - Allocate an EPC page
+ *
+ * Iterate through EPC sections and borrow a free EPC page to the caller. When 
a
+ * page is no longer needed it must be released with sgx_free_epc_page().
+ *
+ * Return:
+ *   an EPC page,
+ *   -errno on error
+ */
+struct sgx_epc_page *__sgx_alloc_epc_page(void)
+{
+   struct sgx_epc_section *section;
+   struct sgx_epc_page *page;
+   int i;
+
+   for (i = 0; i < sgx_nr_epc_sections; i++) {
+   section = &sgx_epc_sections[i];
+   spin_lock(§ion->lock);
+   page = __sgx_alloc_epc_page_from_section(section);
+   spin_unlock(§ion->lock);
+
+   if (page)
+   return page;
+   }
+
+   return ERR_PTR(-ENOMEM);
+}
+
+/**
+ * sgx_free_epc_page() - Free an EPC page
+ * @page:  an EPC page
+ *
+ * Call EREMOVE for an EPC page and insert it back to the list of free pages.
+ */
+void sgx_free_epc_page(struct sgx_epc_page *page)
+{
+   struct sgx_epc_section *section = sgx_get_epc_section(page);
+   int ret;
+
+   ret = __eremove(sgx_get_epc_addr(page));
+   if (WARN_ONCE(ret, "EREMOVE returned %d (0x%x)", ret, ret))
+   return;
+
+   spin_lock(§ion->lock);
+   list_add_tail(&page->list, §ion->page_list);
+   spin_unlock(§ion->lock);
+}
+
 static void __init sgx_free_epc_section(struct sgx_epc_section *section)
 {
struct sgx_epc_page *page;
diff --git a/arch/x86/kernel/cpu/sgx/sgx.h b/arch/x86/kernel/cpu/sgx/sgx.h
index 6508bfefd6d9..aae6bfb3bc8a 100644
--- a/arch/x86/kernel/cpu/sgx/sgx.h
+++ b/arch/x86/kernel/cpu/sgx/sgx.h
@@ -50,4 +50,7 @@ static inline void *sgx_get_epc_addr(struct sgx_epc_page 
*page)
return section->va + (page->desc & PAGE_MASK) - section->pa;
 }
 
+struct sgx_epc_page *__sgx_alloc_epc_page(void);
+void sgx_free_epc_page(struct sgx_epc_page *page);
+
 #endif /* _X86_SGX_H */
-- 
2.25.1

[PATCH v31 06/21] x86/cpu/intel: Detect SGX support

[Jarkko Sakkinen]

From: Sean Christopherson 

Configure SGX as part of feature control MSR initialization and update
the associated X86_FEATURE flags accordingly.  Because the kernel will
require the LE hash MSRs to be writable when running native enclaves,
disable X86_FEATURE_SGX (and all derivatives) if SGX Launch Control is
not (or cannot) be fully enabled via feature control MSR.

The check is done for every CPU, not just BSP, in order to verify that
MSR_IA32_FEATURE_CONTROL is correctly configured on all CPUs. The other
parts of the kernel, like the enclave driver, expect the same
configuration from all CPUs.

Note, unlike VMX, clear the X86_FEATURE_SGX* flags for all CPUs if any
CPU lacks SGX support as the kernel expects SGX to be available on all
CPUs.  X86_FEATURE_VMX is intentionally cleared only for the current CPU
so that KVM can provide additional information if KVM fails to load,
e.g. print which CPU doesn't support VMX.  KVM/VMX requires additional
per-CPU enabling, e.g. to set CR4.VMXE and do VMXON, and so already has
the necessary infrastructure to do per-CPU checks.  SGX on the other
hand doesn't require additional enabling, so clearing the feature flags
on all CPUs means the SGX subsystem doesn't need to manually do support
checks on a per-CPU basis.

Acked-by: Jethro Beekman 
Signed-off-by: Sean Christopherson 
Co-developed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
---
 arch/x86/kernel/cpu/feat_ctl.c | 32 +++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/feat_ctl.c b/arch/x86/kernel/cpu/feat_ctl.c
index 29a3bedabd06..c3afcd2e4342 100644
--- a/arch/x86/kernel/cpu/feat_ctl.c
+++ b/arch/x86/kernel/cpu/feat_ctl.c
@@ -93,16 +93,35 @@ static void init_vmx_capabilities(struct cpuinfo_x86 *c)
 }
 #endif /* CONFIG_X86_VMX_FEATURE_NAMES */
 
+static void clear_sgx_caps(void)
+{
+   setup_clear_cpu_cap(X86_FEATURE_SGX);
+   setup_clear_cpu_cap(X86_FEATURE_SGX_LC);
+   setup_clear_cpu_cap(X86_FEATURE_SGX1);
+   setup_clear_cpu_cap(X86_FEATURE_SGX2);
+}
+
 void init_ia32_feat_ctl(struct cpuinfo_x86 *c)
 {
bool tboot = tboot_enabled();
+   bool enable_sgx;
u64 msr;
 
if (rdmsrl_safe(MSR_IA32_FEAT_CTL, &msr)) {
clear_cpu_cap(c, X86_FEATURE_VMX);
+   clear_sgx_caps();
return;
}
 
+   /*
+* Enable SGX if and only if the kernel supports SGX and Launch Control
+* is supported, i.e. disable SGX if the LE hash MSRs can't be written.
+*/
+   enable_sgx = cpu_has(c, X86_FEATURE_SGX) &&
+cpu_has(c, X86_FEATURE_SGX1) &&
+cpu_has(c, X86_FEATURE_SGX_LC) &&
+IS_ENABLED(CONFIG_INTEL_SGX);
+
if (msr & FEAT_CTL_LOCKED)
goto update_caps;
 
@@ -124,13 +143,16 @@ void init_ia32_feat_ctl(struct cpuinfo_x86 *c)
msr |= FEAT_CTL_VMX_ENABLED_INSIDE_SMX;
}
 
+   if (enable_sgx)
+   msr |= FEAT_CTL_SGX_ENABLED | FEAT_CTL_SGX_LC_ENABLED;
+
wrmsrl(MSR_IA32_FEAT_CTL, msr);
 
 update_caps:
set_cpu_cap(c, X86_FEATURE_MSR_IA32_FEAT_CTL);
 
if (!cpu_has(c, X86_FEATURE_VMX))
-   return;
+   goto update_sgx;
 
if ( (tboot && !(msr & FEAT_CTL_VMX_ENABLED_INSIDE_SMX)) ||
(!tboot && !(msr & FEAT_CTL_VMX_ENABLED_OUTSIDE_SMX))) {
@@ -143,4 +165,12 @@ void init_ia32_feat_ctl(struct cpuinfo_x86 *c)
init_vmx_capabilities(c);
 #endif
}
+
+update_sgx:
+   if (!(msr & FEAT_CTL_SGX_ENABLED) ||
+   !(msr & FEAT_CTL_SGX_LC_ENABLED) || !enable_sgx) {
+   if (enable_sgx)
+   pr_err_once("SGX disabled by BIOS\n");
+   clear_sgx_caps();
+   }
 }
-- 
2.25.1

[PATCH v31 04/21] x86/sgx: Add SGX microarchitectural data structures

[Jarkko Sakkinen]

Define the SGX microarchitectural data structures used by various SGX
opcodes. This is not an exhaustive representation of all SGX data
structures but only those needed by the kernel.

The data structures are described in:

  Intel SDM: 37.6 INTEL® SGX DATA STRUCTURES OVERVIEW

Acked-by: Jethro Beekman 
Signed-off-by: Jarkko Sakkinen 
---
 arch/x86/kernel/cpu/sgx/arch.h | 343 +
 1 file changed, 343 insertions(+)
 create mode 100644 arch/x86/kernel/cpu/sgx/arch.h

diff --git a/arch/x86/kernel/cpu/sgx/arch.h b/arch/x86/kernel/cpu/sgx/arch.h
new file mode 100644
index ..ddae55e9d4d8
--- /dev/null
+++ b/arch/x86/kernel/cpu/sgx/arch.h
@@ -0,0 +1,343 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */
+/**
+ * Copyright(c) 2016-18 Intel Corporation.
+ *
+ * Contains data structures defined by the SGX architecture.  Data structures
+ * defined by the Linux software stack should not be placed here.
+ */
+#ifndef _ASM_X86_SGX_ARCH_H
+#define _ASM_X86_SGX_ARCH_H
+
+#include 
+#include 
+
+#define SGX_CPUID  0x12
+#define SGX_CPUID_FIRST_VARIABLE_SUB_LEAF  2
+
+/**
+ * enum sgx_return_code - The return code type for ENCLS, ENCLU and ENCLV
+ * %SGX_NOT_TRACKED:   Previous ETRACK's shootdown sequence has not
+ * been completed yet.
+ * %SGX_INVALID_EINITTOKEN:EINITTOKEN is invalid and enclave signer's
+ * public key does not match IA32_SGXLEPUBKEYHASH.
+ * %SGX_UNMASKED_EVENT:An unmasked event, e.g. INTR, was 
received
+ */
+enum sgx_return_code {
+   SGX_NOT_TRACKED = 11,
+   SGX_INVALID_EINITTOKEN  = 16,
+   SGX_UNMASKED_EVENT  = 128,
+};
+
+/**
+ * enum sgx_sub_leaf_types - SGX CPUID variable sub-leaf types
+ * %SGX_CPUID_SUB_LEAF_INVALID:Indicates this sub-leaf is 
invalid.
+ * %SGX_CPUID_SUB_LEAF_EPC_SECTION:Sub-leaf enumerates an EPC section.
+ */
+enum sgx_sub_leaf_types {
+   SGX_CPUID_SUB_LEAF_INVALID  = 0x0,
+   SGX_CPUID_SUB_LEAF_EPC_SECTION  = 0x1,
+};
+
+#define SGX_CPUID_SUB_LEAF_TYPE_MASK   GENMASK(3, 0)
+
+#define SGX_MODULUS_SIZE 384
+
+/**
+ * enum sgx_miscselect - additional information to an SSA frame
+ * %SGX_MISC_EXINFO:   Report #PF or #GP to the SSA frame.
+ *
+ * Save State Area (SSA) is a stack inside the enclave used to store processor
+ * state when an exception or interrupt occurs. This enum defines additional
+ * information stored to an SSA frame.
+ */
+enum sgx_miscselect {
+   SGX_MISC_EXINFO = BIT(0),
+};
+
+#define SGX_MISC_RESERVED_MASK GENMASK_ULL(63, 1)
+
+#define SGX_SSA_GPRS_SIZE  184
+#define SGX_SSA_MISC_EXINFO_SIZE   16
+
+/**
+ * enum sgx_attributes - the attributes field in &struct sgx_secs
+ * %SGX_ATTR_INIT: Enclave can be entered (is initialized).
+ * %SGX_ATTR_DEBUG:Allow ENCLS(EDBGRD) and ENCLS(EDBGWR).
+ * %SGX_ATTR_MODE64BIT:Tell that this a 64-bit enclave.
+ * %SGX_ATTR_PROVISIONKEY:  Allow to use provisioning keys for remote
+ * attestation.
+ * %SGX_ATTR_KSS:  Allow to use key separation and sharing (KSS).
+ * %SGX_ATTR_EINITTOKENKEY:Allow to use token signing key that is used to
+ * sign cryptographic tokens that can be passed to
+ * EINIT as an authorization to run an enclave.
+ */
+enum sgx_attribute {
+   SGX_ATTR_INIT   = BIT(0),
+   SGX_ATTR_DEBUG  = BIT(1),
+   SGX_ATTR_MODE64BIT  = BIT(2),
+   SGX_ATTR_PROVISIONKEY   = BIT(4),
+   SGX_ATTR_EINITTOKENKEY  = BIT(5),
+   SGX_ATTR_KSS= BIT(7),
+};
+
+#define SGX_ATTR_RESERVED_MASK (BIT_ULL(3) | BIT_ULL(6) | GENMASK_ULL(63, 8))
+#define SGX_ATTR_ALLOWED_MASK  (SGX_ATTR_DEBUG | SGX_ATTR_MODE64BIT | \
+SGX_ATTR_KSS)
+
+/**
+ * struct sgx_secs - SGX Enclave Control Structure (SECS)
+ * @size:  size of the address space
+ * @base:  base address of the  address space
+ * @ssa_frame_size:size of an SSA frame
+ * @miscselect:additional information stored to an SSA frame
+ * @attributes:attributes for enclave
+ * @xfrm:  XSave-Feature Request Mask (subset of XCR0)
+ * @mrenclave: SHA256-hash of the enclave contents
+ * @mrsigner:  SHA256-hash of the public key used to sign the SIGSTRUCT
+ * @config_id: a user-defined value that is used in key derivation
+ * @isv_prod_id:   a user-defined value that is used in key derivation
+ * @isv_svn:   a user-defined value that is used in key derivation
+ * @config_svn:a user-defined value that is used in key 
derivation
+ *
+ * SGX Enclave Control Structure (SECS) is a special enclave page that is not
+ * visible in the address space. In fact, this structure de

[PATCH v31 07/21] x86/cpu/intel: Add nosgx kernel parameter

[Jarkko Sakkinen]

Add kernel parameter to disable Intel SGX kernel support.

Tested-by: Sean Christopherson 
Reviewed-by: Sean Christopherson 
Signed-off-by: Jarkko Sakkinen 
---
 Documentation/admin-guide/kernel-parameters.txt | 2 ++
 arch/x86/kernel/cpu/feat_ctl.c  | 9 +
 2 files changed, 11 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 7bc83f3d9bdf..9f7202a54db6 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3268,6 +3268,8 @@
 
nosep   [BUGS=X86-32] Disables x86 SYSENTER/SYSEXIT support.
 
+   nosgx   [X86-64,SGX] Disables Intel SGX kernel support.
+
nosmp   [SMP] Tells an SMP kernel to act as a UP kernel,
and disable the IO APIC.  legacy for "maxcpus=0".
 
diff --git a/arch/x86/kernel/cpu/feat_ctl.c b/arch/x86/kernel/cpu/feat_ctl.c
index c3afcd2e4342..1837df39527f 100644
--- a/arch/x86/kernel/cpu/feat_ctl.c
+++ b/arch/x86/kernel/cpu/feat_ctl.c
@@ -101,6 +101,15 @@ static void clear_sgx_caps(void)
setup_clear_cpu_cap(X86_FEATURE_SGX2);
 }
 
+static int __init nosgx(char *str)
+{
+   clear_sgx_caps();
+
+   return 0;
+}
+
+early_param("nosgx", nosgx);
+
 void init_ia32_feat_ctl(struct cpuinfo_x86 *c)
 {
bool tboot = tboot_enabled();
-- 
2.25.1

[PATCH v31 08/21] x86/sgx: Initialize metadata for Enclave Page Cache (EPC) sections

[Jarkko Sakkinen]

From: Sean Christopherson 

Enumerate Enclave Page Cache (EPC) sections via CPUID and add the data
structures necessary to track EPC pages so that they can be easily borrowed
for different uses.

Embed section index to the first eight bits of the EPC page descriptor.
Existing client hardware supports only a single section, while upcoming
server hardware will support at most eight sections. Thus, eight bits
should be enough for long term needs.

Acked-by: Jethro Beekman 
Signed-off-by: Sean Christopherson 
Co-developed-by: Serge Ayoun 
Signed-off-by: Serge Ayoun 
Co-developed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
---
 arch/x86/Kconfig |  16 +++
 arch/x86/kernel/cpu/Makefile |   1 +
 arch/x86/kernel/cpu/sgx/Makefile |   2 +
 arch/x86/kernel/cpu/sgx/main.c   | 216 +++
 arch/x86/kernel/cpu/sgx/sgx.h|  53 
 5 files changed, 288 insertions(+)
 create mode 100644 arch/x86/kernel/cpu/sgx/Makefile
 create mode 100644 arch/x86/kernel/cpu/sgx/main.c
 create mode 100644 arch/x86/kernel/cpu/sgx/sgx.h

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 1197b5596d5a..ead6bdebef51 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1947,6 +1947,22 @@ config X86_INTEL_TSX_MODE_AUTO
  side channel attacks- equals the tsx=auto command line parameter.
 endchoice
 
+config INTEL_SGX
+   bool "Intel SGX"
+   depends on X86_64 && CPU_SUP_INTEL
+   depends on CRYPTO=y
+   depends on CRYPTO_SHA256=y
+   select SRCU
+   select MMU_NOTIFIER
+   help
+ Intel(R) SGX is a set of CPU instructions that can be used by
+ applications to set aside private regions of code and data, referred
+ to as enclaves. An enclave's private memory can only be accessed by
+ code running within the enclave. Accesses from outside the enclave,
+ including other enclaves, are disallowed by hardware.
+
+ If unsure, say N.
+
 config EFI
bool "EFI runtime service support"
depends on ACPI
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 7dc4ad68eb41..45534fb81007 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_X86_MCE) += mce/
 obj-$(CONFIG_MTRR) += mtrr/
 obj-$(CONFIG_MICROCODE)+= microcode/
 obj-$(CONFIG_X86_CPU_RESCTRL)  += resctrl/
+obj-$(CONFIG_INTEL_SGX)+= sgx/
 
 obj-$(CONFIG_X86_LOCAL_APIC)   += perfctr-watchdog.o
 
diff --git a/arch/x86/kernel/cpu/sgx/Makefile b/arch/x86/kernel/cpu/sgx/Makefile
new file mode 100644
index ..79510ce01b3b
--- /dev/null
+++ b/arch/x86/kernel/cpu/sgx/Makefile
@@ -0,0 +1,2 @@
+obj-y += \
+   main.o
diff --git a/arch/x86/kernel/cpu/sgx/main.c b/arch/x86/kernel/cpu/sgx/main.c
new file mode 100644
index ..c5831e3db14a
--- /dev/null
+++ b/arch/x86/kernel/cpu/sgx/main.c
@@ -0,0 +1,216 @@
+// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
+// Copyright(c) 2016-17 Intel Corporation.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "encls.h"
+
+struct sgx_epc_section sgx_epc_sections[SGX_MAX_EPC_SECTIONS];
+static int sgx_nr_epc_sections;
+static struct task_struct *ksgxswapd_tsk;
+
+static void sgx_sanitize_section(struct sgx_epc_section *section)
+{
+   struct sgx_epc_page *page;
+   LIST_HEAD(secs_list);
+   int ret;
+
+   while (!list_empty(§ion->unsanitized_page_list)) {
+   if (kthread_should_stop())
+   return;
+
+   spin_lock(§ion->lock);
+
+   page = list_first_entry(§ion->unsanitized_page_list,
+   struct sgx_epc_page, list);
+
+   ret = __eremove(sgx_get_epc_addr(page));
+   if (!ret)
+   list_move(&page->list, §ion->page_list);
+   else
+   list_move_tail(&page->list, &secs_list);
+
+   spin_unlock(§ion->lock);
+
+   cond_resched();
+   }
+}
+
+static int ksgxswapd(void *p)
+{
+   int i;
+
+   set_freezable();
+
+   /*
+* Reset all pages to uninitialized state. Pages could be in initialized
+* on kmemexec.
+*/
+   for (i = 0; i < sgx_nr_epc_sections; i++)
+   sgx_sanitize_section(&sgx_epc_sections[i]);
+
+   /*
+* 2nd round for the SECS pages as they cannot be removed when they
+* still hold child pages.
+*/
+   for (i = 0; i < sgx_nr_epc_sections; i++) {
+   sgx_sanitize_section(&sgx_epc_sections[i]);
+
+   /* Should never happen. */
+   if (!list_empty(&sgx_epc_sections[i].unsanitized_page_list))
+   WARN(1, "EPC section %d has unsanitized pages.\n", i);
+   }
+
+   return 0;
+}
+
+static bool __init sgx_page_reclaimer

[PATCH v31 02/21] x86/cpufeatures: x86/msr: Add Intel SGX Launch Control hardware bits

[Jarkko Sakkinen]

From: Sean Christopherson 

Add X86_FEATURE_SGX_LC, which informs whether or not the CPU supports SGX
Launch Control.

Add MSR_IA32_SGXLEPUBKEYHASH{0, 1, 2, 3}, which when combined contain a
SHA256 hash of a 3072-bit RSA public key. SGX backed software packages, so
called enclaves, are always signed. All enclaves signed with the public key
are unconditionally allowed to initialize. [1]

Add FEATURE_CONTROL_SGX_LE_WR bit of the feature control MSR, which informs
whether the aformentioned MSRs are writable or not. If the bit is off, the
public key MSRs are read-only for the OS.

If the MSRs are read-only, the platform must provide a launch enclave (LE).
LE can create cryptographic tokens for other enclaves that they can pass
together with their signature to the ENCLS(EINIT) opcode, which is used
to initialize enclaves.

Linux is unlikely to support the locked configuration because it takes away
the control of the launch decisions from the kernel.

[1] Intel SDM: 38.1.4 Intel SGX Launch Control Configuration

Acked-by: Jethro Beekman 
Signed-off-by: Sean Christopherson 
Co-developed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
---
 arch/x86/include/asm/cpufeatures.h | 1 +
 arch/x86/include/asm/msr-index.h   | 7 +++
 2 files changed, 8 insertions(+)

diff --git a/arch/x86/include/asm/cpufeatures.h 
b/arch/x86/include/asm/cpufeatures.h
index fc4422f747d5..c2f8962e8468 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -352,6 +352,7 @@
 #define X86_FEATURE_CLDEMOTE   (16*32+25) /* CLDEMOTE instruction */
 #define X86_FEATURE_MOVDIRI(16*32+27) /* MOVDIRI instruction */
 #define X86_FEATURE_MOVDIR64B  (16*32+28) /* MOVDIR64B instruction */
+#define X86_FEATURE_SGX_LC (16*32+30) /* Software Guard Extensions 
Launch Control */
 
 /* AMD-defined CPU features, CPUID level 0x8007 (EBX), word 17 */
 #define X86_FEATURE_OVERFLOW_RECOV (17*32+ 0) /* MCA overflow recovery 
support */
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index a277d33006c0..4b2e9c25cde3 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -575,6 +575,7 @@
 #define FEAT_CTL_LOCKEDBIT(0)
 #define FEAT_CTL_VMX_ENABLED_INSIDE_SMXBIT(1)
 #define FEAT_CTL_VMX_ENABLED_OUTSIDE_SMX   BIT(2)
+#define FEAT_CTL_SGX_LC_ENABLEDBIT(17)
 #define FEAT_CTL_SGX_ENABLED   BIT(18)
 #define FEAT_CTL_LMCE_ENABLED  BIT(20)
 
@@ -595,6 +596,12 @@
 #define MSR_IA32_UCODE_WRITE   0x0079
 #define MSR_IA32_UCODE_REV 0x008b
 
+/* Intel SGX Launch Enclave Public Key Hash MSRs */
+#define MSR_IA32_SGXLEPUBKEYHASH0  0x008C
+#define MSR_IA32_SGXLEPUBKEYHASH1  0x008D
+#define MSR_IA32_SGXLEPUBKEYHASH2  0x008E
+#define MSR_IA32_SGXLEPUBKEYHASH3  0x008F
+
 #define MSR_IA32_SMM_MONITOR_CTL   0x009b
 #define MSR_IA32_SMBASE0x009e
 
-- 
2.25.1

[PATCH v31 01/21] x86/cpufeatures: x86/msr: Add Intel SGX hardware bits

[Jarkko Sakkinen]

From: Sean Christopherson 

Add X86_FEATURE_SGX from CPUID.(EAX=7, ECX=1), which informs whether the
CPU has SGX.

Add X86_FEATURE_SGX1 and X86_FEATURE_SGX2 from CPUID.(EAX=12H, ECX=0),
which describe the level of SGX support available [1].

Add IA32_FEATURE_CONTROL_SGX_ENABLE. BIOS can use this bit to opt-in SGX
before locking the feature control MSR [2].

[1] Intel SDM: 36.7.2 Intel® SGX Resource Enumeration Leaves
[2] Intel SDM: 36.7.1 Intel® SGX Opt-In Configuration

Cc: Borislav Petkov 
Acked-by: Jethro Beekman 
Signed-off-by: Sean Christopherson 
Co-developed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
---
 arch/x86/include/asm/cpufeature.h|  5 +++--
 arch/x86/include/asm/cpufeatures.h   |  7 ++-
 arch/x86/include/asm/disabled-features.h | 18 +++---
 arch/x86/include/asm/msr-index.h |  1 +
 arch/x86/include/asm/required-features.h |  2 +-
 arch/x86/kernel/cpu/common.c |  4 
 tools/arch/x86/include/asm/cpufeatures.h |  7 ++-
 7 files changed, 36 insertions(+), 8 deletions(-)

diff --git a/arch/x86/include/asm/cpufeature.h 
b/arch/x86/include/asm/cpufeature.h
index 59bf91c57aa8..efbdba5170a3 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -30,6 +30,7 @@ enum cpuid_leafs
CPUID_7_ECX,
CPUID_8000_0007_EBX,
CPUID_7_EDX,
+   CPUID_12_EAX,
 };
 
 #ifdef CONFIG_X86_FEATURE_NAMES
@@ -89,7 +90,7 @@ extern const char * const x86_bug_flags[NBUGINTS*32];
   CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 17, feature_bit) ||\
   CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 18, feature_bit) ||\
   REQUIRED_MASK_CHECK||\
-  BUILD_BUG_ON_ZERO(NCAPINTS != 19))
+  BUILD_BUG_ON_ZERO(NCAPINTS != 20))
 
 #define DISABLED_MASK_BIT_SET(feature_bit) \
 ( CHECK_BIT_IN_MASK_WORD(DISABLED_MASK,  0, feature_bit) ||\
@@ -112,7 +113,7 @@ extern const char * const x86_bug_flags[NBUGINTS*32];
   CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 17, feature_bit) ||\
   CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 18, feature_bit) ||\
   DISABLED_MASK_CHECK||\
-  BUILD_BUG_ON_ZERO(NCAPINTS != 19))
+  BUILD_BUG_ON_ZERO(NCAPINTS != 20))
 
 #define cpu_has(c, bit)
\
(__builtin_constant_p(bit) && REQUIRED_MASK_BIT_SET(bit) ? 1 :  \
diff --git a/arch/x86/include/asm/cpufeatures.h 
b/arch/x86/include/asm/cpufeatures.h
index db189945e9b0..fc4422f747d5 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -13,7 +13,7 @@
 /*
  * Defines x86 CPU feature bits
  */
-#define NCAPINTS   19 /* N 32-bit words worth of 
info */
+#define NCAPINTS   20 /* N 32-bit words worth of 
info */
 #define NBUGINTS   1  /* N 32-bit bug flags */
 
 /*
@@ -238,6 +238,7 @@
 /* Intel-defined CPU features, CPUID level 0x0007:0 (EBX), word 9 */
 #define X86_FEATURE_FSGSBASE   ( 9*32+ 0) /* RDFSBASE, WRFSBASE, 
RDGSBASE, WRGSBASE instructions*/
 #define X86_FEATURE_TSC_ADJUST ( 9*32+ 1) /* TSC adjustment MSR 0x3B */
+#define X86_FEATURE_SGX( 9*32+ 2) /* Software Guard 
Extensions */
 #define X86_FEATURE_BMI1   ( 9*32+ 3) /* 1st group bit 
manipulation extensions */
 #define X86_FEATURE_HLE( 9*32+ 4) /* Hardware Lock 
Elision */
 #define X86_FEATURE_AVX2   ( 9*32+ 5) /* AVX2 instructions */
@@ -372,6 +373,10 @@
 #define X86_FEATURE_CORE_CAPABILITIES  (18*32+30) /* "" IA32_CORE_CAPABILITIES 
MSR */
 #define X86_FEATURE_SPEC_CTRL_SSBD (18*32+31) /* "" Speculative Store 
Bypass Disable */
 
+/* Intel-defined SGX features, CPUID level 0x0012:0 (EAX), word 19 */
+#define X86_FEATURE_SGX1   (19*32+ 0) /* SGX1 leaf functions */
+#define X86_FEATURE_SGX2   (19*32+ 1) /* SGX2 leaf functions */
+
 /*
  * BUG word(s)
  */
diff --git a/arch/x86/include/asm/disabled-features.h 
b/arch/x86/include/asm/disabled-features.h
index 4ea8584682f9..dbe534d5153f 100644
--- a/arch/x86/include/asm/disabled-features.h
+++ b/arch/x86/include/asm/disabled-features.h
@@ -28,13 +28,18 @@
 # define DISABLE_CYRIX_ARR (1<<(X86_FEATURE_CYRIX_ARR & 31))
 # define DISABLE_CENTAUR_MCR   (1<<(X86_FEATURE_CENTAUR_MCR & 31))
 # define DISABLE_PCID  0
+# define DISABLE_SGX1  0
+# define DISABLE_SGX2  0
 #else
 # define DISABLE_VME   0
 # define DISABLE_K6_MTRR   0
 # define DISABLE_CYRIX_ARR 0
 # define DISABLE_CENTAUR_MCR   0
 # define DISABLE_PCID  (1<<(X86_FEATURE_PCID & 31))
-#endif /* CONFIG_X86_64 */
+# define DISABLE_SGX1  (1<<(X86_FEATURE_SGX1 & 31))
+# define DISABLE_SGX2  (1<<(X86_FEATURE_SGX2 & 31))
+ #endif /* CONFIG_X86

[PATCH v31 00/21] Intel SGX foundations

[Jarkko Sakkinen]

Intel(R) SGX is a set of CPU instructions that can be used by applications
to set aside private regions of code and data. The code outside the enclave
is disallowed to access the memory inside the enclave by the CPU access
control.

There is a new hardware unit in the processor called Memory Encryption
Engine (MEE) starting from the Skylake microacrhitecture. BIOS can define
one or many MEE regions that can hold enclave data by configuring them with
PRMRR registers.

The MEE automatically encrypts the data leaving the processor package to
the MEE regions. The data is encrypted using a random key whose life-time
is exactly one power cycle.

The current implementation requires that the firmware sets
IA32_SGXLEPUBKEYHASH* MSRs as writable so that ultimately the kernel can
decide what enclaves it wants run. The implementation does not create
any bottlenecks to support read-only MSRs later on.

You can tell if your CPU supports SGX by looking into /proc/cpuinfo:

cat /proc/cpuinfo  | grep sgx

v31:
* Unset SGX_ENCL_IOCTL in the error path of checking encl->flags in order
  to prevent leaving it set and thus block any further ioctl calls.
* Added missing cleanup_srcu_struct() call to sgx_encl_release().
* Take encl->lock in sgx_encl_add_page() in order to prevent races with
  the page reclaimer.
* Fix a use-after-free bug from the page reclaimer. Call kref_put() for
  encl->refcount only after putting enclave page back to the active page
  list because it could be the last ref to the enclave.
* Filter any CPU disallowed values from sigstruct->vendor
  SGX_IOC_ENCLAVE_INIT.
* Use bits 0-7 of page descriptor for the EPC section index. This
  should be enough for long term needs.
* Refined naming for functions that allocate and free EPC pages to
  be more sound and consistent.
* Merge main.c and reclaim.c into one.

v30:
Bunch of tags added. No actual code changes.

v29:
* The selftest has been moved to selftests/sgx. Because SGX is an execution
  environment of its own, it really isn't a great fit with more "standard"
  x86 tests.

  The RSA key is now generated on fly and the whole signing process has
  been made as part of the enclave loader instead of signing the enclave
  during the compilation time.

  Finally, the enclave loader loads now the test enclave directly from its
  ELF file, which means that ELF file does not need to be coverted as raw
  binary during the build process.
* Version the mm_list instead of using on synchronize_mm() when adding new
  entries. We hold the write lock for the mm_struct, and dup_mm() can thus
  deadlock with the page reclaimer, which could hold the lock for the old
  mm_struct.
* Disallow mmap(PROT_NONE) from /dev/sgx. Any mapping (e.g. anonymous) can
  be used to reserve the address range. Now /dev/sgx supports only opaque
  mappings to the (initialized) enclave data.
* Make the vDSO callable directly from C by preserving RBX and taking leaf
  from RCX.

v28:
* Documented to Documentation/x86/sgx.rst how the kernel manages the
  enclave ownership.
* Removed non-LC flow from sgx_einit().
* Removed struct sgx_einittoken since only the size of the corresponding
  microarchitectural structure is used in the series ATM.

v27:
* Disallow RIE processes to use enclaves as there could a permission
  conflict between VMA and enclave permissions.
* In the documentation, replace "grep /proc/cpuinfo" with
  "grep sgx /proc/cpuinfo".

v26:
* Fixed the commit author in "x86/sgx: Linux Enclave Driver", which was
  changed in v25 by mistake.
* Addressed a bunch of grammar mistakes in sgx.rst (thanks Randy once
  again for such a detailed feedback).
* Added back the MAINTAINERS update commit, which was mistakenly removed
  in v25.
* EREMOVE's for SECS cannot be done while sanitizing an EPC section. The
  CPU does not allow to remove a SECS page before all of its children have
  been removed, and a child page can be in some other section than the one
  currently being processed. Thus, removed special SECS processing from
  sgx_sanitize_page() and instead put sections through it twice. In the
  2nd round the lists should only contain SECS pages.

v25:
* Fix a double-free issue when SGX_IOC_ENCLAVE_ADD_PAGES
  fails on executing ENCLS[EADD]. The rollback path executed
  radix_tree_delete() on the same address twice when this happened.
* Return -EINTR instead of -ERESTARTSYS in SGX_IOC_ENCLAVE_ADD_PAGES when
  a signal is pending.
* As requested by Borislav, move the CPUID 0x12 features to their own word
  in cpufeatures.
* Sean fixed a bug from sgx_reclaimer_write() where sgx_encl_put_backing()
  was called with an uninitialized pointer when sgx_encl_get_backing()
  fails.
* Migrated /dev/sgx/* to misc. This is future-proof as struct miscdevice
  has 'groups' for setting up sysfs attributes for the device.
* Use device_initcall instead of subsys_initcall so that misc_class is
  initialized before SGX is initialized.
* Return -EACCES in SGX_IOC_ENCLAVE_INIT when caller tries to select
 

[PATCH v31 03/21] x86/mm: x86/sgx: Signal SIGSEGV with PF_SGX

[Jarkko Sakkinen]

From: Sean Christopherson 

Include SGX bit to the PF error codes and throw SIGSEGV with PF_SGX when
a #PF with SGX set happens.

CPU throws a #PF with the SGX bit in the event of Enclave Page Cache Map
(EPCM) conflict. The EPCM is a CPU-internal table, which describes the
properties for a enclave page. Enclaves are measured and signed software
entities, which SGX hosts. [1]

Although the primary purpose of the EPCM conflict checks  is to prevent
malicious accesses to an enclave, an illegit access can happen also for
legit reasons.

All SGX reserved memory, including EPCM is encrypted with a transient
key that does not survive from the power transition. Throwing a SIGSEGV
allows user space software react when this happens (e.g. rec-create the
enclave, which was invalidated).

[1] Intel SDM: 36.5.1 Enclave Page Cache Map (EPCM)

Acked-by: Jethro Beekman 
Signed-off-by: Sean Christopherson 
Signed-off-by: Jarkko Sakkinen 
---
 arch/x86/include/asm/traps.h |  1 +
 arch/x86/mm/fault.c  | 13 +
 2 files changed, 14 insertions(+)

diff --git a/arch/x86/include/asm/traps.h b/arch/x86/include/asm/traps.h
index c26a7e1d8a2c..07dd9f74d65a 100644
--- a/arch/x86/include/asm/traps.h
+++ b/arch/x86/include/asm/traps.h
@@ -171,5 +171,6 @@ enum x86_pf_error_code {
X86_PF_RSVD =   1 << 3,
X86_PF_INSTR=   1 << 4,
X86_PF_PK   =   1 << 5,
+   X86_PF_SGX  =   1 << 15,
 };
 #endif /* _ASM_X86_TRAPS_H */
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index a51df516b87b..16c53c874bb9 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -1201,6 +1201,19 @@ access_error(unsigned long error_code, struct 
vm_area_struct *vma)
if (error_code & X86_PF_PK)
return 1;
 
+   /*
+* Access is blocked by the Enclave Page Cache Map (EPCM), i.e. the
+* access is allowed by the PTE but not the EPCM. This usually happens
+* when the EPCM is yanked out from under us, e.g. by hardware after a
+* suspend/resume cycle. In any case, software, i.e. the kernel, can't
+* fix the source of the fault as the EPCM can't be directly modified by
+* software. Handle the fault as an access error in order to signal
+* userspace so that userspace can rebuild their enclave(s), even though
+* userspace may not have actually violated access permissions.
+*/
+   if (unlikely(error_code & X86_PF_SGX))
+   return 1;
+
/*
 * Make sure to check the VMA so that we do not perform
 * faults just to hit a X86_PF_PK as soon as we fill in a
-- 
2.25.1

Re: [PATCH v5 03/14] PCI: cadence: Convert all r/w accessors to perform only 32-bit accesses

[Kishon Vijay Abraham I]

Hi Rob,

On 5/28/2020 3:36 AM, Kishon Vijay Abraham I wrote:
> Hi Rob,
> 
> On 5/27/2020 10:07 PM, Rob Herring wrote:
>> On Wed, May 27, 2020 at 4:49 AM Kishon Vijay Abraham I  wrote:
>>>
>>> Hi Rob,
>>>
>>> On 5/26/2020 8:42 PM, Rob Herring wrote:
 On Sun, May 24, 2020 at 9:30 PM Kishon Vijay Abraham I  
 wrote:
>
> Hi Rob,
>
> On 5/22/2020 9:24 PM, Rob Herring wrote:
>> On Thu, May 21, 2020 at 9:37 PM Kishon Vijay Abraham I  
>> wrote:
>>>
>>> Certain platforms like TI's J721E using Cadence PCIe IP can perform only
>>> 32-bit accesses for reading or writing to Cadence registers. Convert all
>>> read and write accesses to 32-bit in Cadence PCIe driver in preparation
>>> for adding PCIe support in TI's J721E SoC.
>>
>> Looking more closely I don't think cdns_pcie_ep_assert_intx is okay
>> with this and never can be given the PCI_COMMAND and PCI_STATUS
>> registers are in the same word (IIRC, that's the main reason 32-bit
>> config space accesses are broken). So this isn't going to work at
>
> right, PCI_STATUS has write '1' to clear bits and there's a chance that it
> could be reset while raising legacy interrupt. While this cannot be 
> avoided for
> TI's J721E, other platforms doesn't have to have this limitation.
>> least for EP accesses. And maybe you need a custom .raise_irq() hook
>> to minimize any problems (such as making the RMW atomic at least from
>> the endpoint's perspective).
>
> This is to make sure EP doesn't update in-consistent state when RC is 
> updating
> the PCI_STATUS register? Since this involves two different systems, how 
> do we
> make this atomic?

 You can't make it atomic WRT both systems, but is there locking around
 each RMW? Specifically, are preemption and interrupts disabled to
 ensure time between a read and write are minimized? You wouldn't want
 interrupts disabled during the delay too though (i.e. around
 .raise_irq()).
>>>
>>> Okay, I'll add spin spin_lock_irqsave() in cdns_pcie_write_sz(). As you also
>>> pointed below that delay for legacy interrupt is wrong and it has to be 
>>> fixed
>>> (with a later series).
>>
>> But you don't need a lock everywhere. You need locks in the callers
>> (and only sometimes).
> 
> Okay, the locks should be added only for registers where HOST can also write 
> to
> the same register? Maybe only raise_irq then..
> 
>>
>>> How do you want to handle cdns_pcie_ep_fn_writew() now? Because now we are
>>> changing the default implementation to perform only 32-bit access (used for
>>> legacy interrupt, msi-x interrupt and while writing standard headers) and 
>>> it's
>>> not okay only for legacy interrupts for platforms other than TI.
>>
>> Now I'm wondering how set_msi is not racy in the current code with the
>> host setting/clearing PCI_MSI_FLAGS_ENABLE? Maybe that bit is RO from
>> the EP side?
> 
> set_msi/set_msix is a one time configuration that is invoked before the host
> establishes the link with the endpoint. I don't think we have to consider this
> as racy.

Can we try to close on this discussion please?

Thanks
Kishon

> 
> Thanks
> Kishon
> 
>>
>> Ultimately I think you're going to have to provide your own endpoint
>> functions or you need accessors for specific registers like
>> PCI_MSI_FLAGS. Then for example, you just rely on the 2 bytes before
>> PCI_MSI_FLAGS being reserved and do a 32-bit access without a RMW.
>> Trying to abstract this at the register read/write level is going to
>> be fragile
>>
>> Rob
>>