[PATCH RFC v2 1/1] scsi: ufs: Fix ufs power down/on specs violation

[Ziqi Chen]

As per specs, e.g, JESD220E chapter 7.2, while powering
off/on the ufs device, RST_N signal and REF_CLK signal
should be between VSS(Ground) and VCCQ/VCCQ2.

To flexibly control device reset line, re-name the function
ufschd_vops_device_reset(sturct ufs_hba *hba) to ufshcd_
vops_toggle_device_reset(sturct ufs_hba *hba, bool up). The
new parameter "bool up" is used to separate device reset
line pulling up from pulling down.

Cc: Kiwoong Kim 
Cc: Stanley Chu 
Signed-off-by: Ziqi Chen 
---
 drivers/scsi/ufs/ufs-mediatek.c | 27 +-
 drivers/scsi/ufs/ufs-qcom.c | 22 ++---
 drivers/scsi/ufs/ufshcd.c   | 43 ++---
 drivers/scsi/ufs/ufshcd.h   | 10 +-
 4 files changed, 56 insertions(+), 46 deletions(-)

diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index 80618af..bff2c42 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -841,27 +841,18 @@ static int ufs_mtk_link_startup_notify(struct ufs_hba 
*hba,
return ret;
 }
 
-static int ufs_mtk_device_reset(struct ufs_hba *hba)
+static int ufs_mtk_toggle_device_reset(struct ufs_hba *hba, bool down)
 {
struct arm_smccc_res res;
 
-   ufs_mtk_device_reset_ctrl(0, res);
-
-   /*
-* The reset signal is active low. UFS devices shall detect
-* more than or equal to 1us of positive or negative RST_n
-* pulse width.
-*
-* To be on safe side, keep the reset low for at least 10us.
-*/
-   usleep_range(10, 15);
-
-   ufs_mtk_device_reset_ctrl(1, res);
-
-   /* Some devices may need time to respond to rst_n */
-   usleep_range(1, 15000);
+   if (down) {
+   ufs_mtk_device_reset_ctrl(0, res);
+   } else {
+   ufs_mtk_device_reset_ctrl(1, res);
 
-   dev_info(hba->dev, "device reset done\n");
+   /* Some devices may need time to respond to rst_n */
+   usleep_range(1, 15000);
+   }
 
return 0;
 }
@@ -1052,7 +1043,7 @@ static const struct ufs_hba_variant_ops ufs_hba_mtk_vops 
= {
.suspend = ufs_mtk_suspend,
.resume  = ufs_mtk_resume,
.dbg_register_dump   = ufs_mtk_dbg_register_dump,
-   .device_reset= ufs_mtk_device_reset,
+   .toggle_device_reset= ufs_mtk_toggle_device_reset,
.event_notify= ufs_mtk_event_notify,
 };
 
diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index 2206b1e..c2ccaa5 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -1404,12 +1404,13 @@ static void ufs_qcom_dump_dbg_regs(struct ufs_hba *hba)
 }
 
 /**
- * ufs_qcom_device_reset() - toggle the (optional) device reset line
+ * ufs_qcom_toggle_device_reset() - toggle the (optional) device reset line
  * @hba: per-adapter instance
+ * @down: pull down or pull up device reset line
  *
  * Toggles the (optional) reset line to reset the attached device.
  */
-static int ufs_qcom_device_reset(struct ufs_hba *hba)
+static int ufs_qcom_toggle_device_reset(struct ufs_hba *hba, bool down)
 {
struct ufs_qcom_host *host = ufshcd_get_variant(hba);
 
@@ -1417,15 +1418,12 @@ static int ufs_qcom_device_reset(struct ufs_hba *hba)
if (!host->device_reset)
return -EOPNOTSUPP;
 
-   /*
-* The UFS device shall detect reset pulses of 1us, sleep for 10us to
-* be on the safe side.
-*/
-   gpiod_set_value_cansleep(host->device_reset, 1);
-   usleep_range(10, 15);
-
-   gpiod_set_value_cansleep(host->device_reset, 0);
-   usleep_range(10, 15);
+   if (down) {
+   gpiod_set_value_cansleep(host->device_reset, 1);
+   } else {
+   gpiod_set_value_cansleep(host->device_reset, 0);
+   usleep_range(10, 15);
+   }
 
return 0;
 }
@@ -1473,7 +1471,7 @@ static const struct ufs_hba_variant_ops ufs_hba_qcom_vops 
= {
.suspend= ufs_qcom_suspend,
.resume = ufs_qcom_resume,
.dbg_register_dump  = ufs_qcom_dump_dbg_regs,
-   .device_reset   = ufs_qcom_device_reset,
+   .toggle_device_reset= ufs_qcom_toggle_device_reset,
.config_scaling_param = ufs_qcom_config_scaling_param,
.program_key= ufs_qcom_ice_program_key,
 };
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index e221add..2ee905f 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -585,7 +585,20 @@ static void ufshcd_device_reset(struct ufs_hba *hba)
 {
int err;
 
-   err = ufshcd_vops_device_reset(hba);
+   err = ufshcd_vops_toggle_device_reset(hba, true);
+   if (err) {
+   dev_err(hba->dev, "device reset pulling down failure: %d\n", 
err);
+   return;
+   }
+
+   /*
+* The reset signal is active lo

[PATCH RFC v3 1/1] scsi: ufs: Fix ufs power down/on specs violation

[Ziqi Chen]

As per specs, e.g, JESD220E chapter 7.2, while powering
off/on the ufs device, RST_N signal and REF_CLK signal
should be between VSS(Ground) and VCCQ/VCCQ2.

To flexibly control device reset line, re-name the function
ufschd_vops_device_reset(sturct ufs_hba *hba) to ufshcd_
vops_toggle_device_reset(sturct ufs_hba *hba, bool down). The
new parameter "bool down" is used to separate device reset
line pulling down from pulling up.

Cc: Kiwoong Kim 
Cc: Stanley Chu 
Signed-off-by: Ziqi Chen 
---
 drivers/scsi/ufs/ufs-mediatek.c | 27 +-
 drivers/scsi/ufs/ufs-qcom.c | 22 ++---
 drivers/scsi/ufs/ufshcd.c   | 43 ++---
 drivers/scsi/ufs/ufshcd.h   | 10 +-
 4 files changed, 56 insertions(+), 46 deletions(-)

diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index 80618af..bff2c42 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -841,27 +841,18 @@ static int ufs_mtk_link_startup_notify(struct ufs_hba 
*hba,
return ret;
 }
 
-static int ufs_mtk_device_reset(struct ufs_hba *hba)
+static int ufs_mtk_toggle_device_reset(struct ufs_hba *hba, bool down)
 {
struct arm_smccc_res res;
 
-   ufs_mtk_device_reset_ctrl(0, res);
-
-   /*
-* The reset signal is active low. UFS devices shall detect
-* more than or equal to 1us of positive or negative RST_n
-* pulse width.
-*
-* To be on safe side, keep the reset low for at least 10us.
-*/
-   usleep_range(10, 15);
-
-   ufs_mtk_device_reset_ctrl(1, res);
-
-   /* Some devices may need time to respond to rst_n */
-   usleep_range(1, 15000);
+   if (down) {
+   ufs_mtk_device_reset_ctrl(0, res);
+   } else {
+   ufs_mtk_device_reset_ctrl(1, res);
 
-   dev_info(hba->dev, "device reset done\n");
+   /* Some devices may need time to respond to rst_n */
+   usleep_range(1, 15000);
+   }
 
return 0;
 }
@@ -1052,7 +1043,7 @@ static const struct ufs_hba_variant_ops ufs_hba_mtk_vops 
= {
.suspend = ufs_mtk_suspend,
.resume  = ufs_mtk_resume,
.dbg_register_dump   = ufs_mtk_dbg_register_dump,
-   .device_reset= ufs_mtk_device_reset,
+   .toggle_device_reset= ufs_mtk_toggle_device_reset,
.event_notify= ufs_mtk_event_notify,
 };
 
diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index 2206b1e..c2ccaa5 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -1404,12 +1404,13 @@ static void ufs_qcom_dump_dbg_regs(struct ufs_hba *hba)
 }
 
 /**
- * ufs_qcom_device_reset() - toggle the (optional) device reset line
+ * ufs_qcom_toggle_device_reset() - toggle the (optional) device reset line
  * @hba: per-adapter instance
+ * @down: pull down or pull up device reset line
  *
  * Toggles the (optional) reset line to reset the attached device.
  */
-static int ufs_qcom_device_reset(struct ufs_hba *hba)
+static int ufs_qcom_toggle_device_reset(struct ufs_hba *hba, bool down)
 {
struct ufs_qcom_host *host = ufshcd_get_variant(hba);
 
@@ -1417,15 +1418,12 @@ static int ufs_qcom_device_reset(struct ufs_hba *hba)
if (!host->device_reset)
return -EOPNOTSUPP;
 
-   /*
-* The UFS device shall detect reset pulses of 1us, sleep for 10us to
-* be on the safe side.
-*/
-   gpiod_set_value_cansleep(host->device_reset, 1);
-   usleep_range(10, 15);
-
-   gpiod_set_value_cansleep(host->device_reset, 0);
-   usleep_range(10, 15);
+   if (down) {
+   gpiod_set_value_cansleep(host->device_reset, 1);
+   } else {
+   gpiod_set_value_cansleep(host->device_reset, 0);
+   usleep_range(10, 15);
+   }
 
return 0;
 }
@@ -1473,7 +1471,7 @@ static const struct ufs_hba_variant_ops ufs_hba_qcom_vops 
= {
.suspend= ufs_qcom_suspend,
.resume = ufs_qcom_resume,
.dbg_register_dump  = ufs_qcom_dump_dbg_regs,
-   .device_reset   = ufs_qcom_device_reset,
+   .toggle_device_reset= ufs_qcom_toggle_device_reset,
.config_scaling_param = ufs_qcom_config_scaling_param,
.program_key= ufs_qcom_ice_program_key,
 };
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index e221add..2ee905f 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -585,7 +585,20 @@ static void ufshcd_device_reset(struct ufs_hba *hba)
 {
int err;
 
-   err = ufshcd_vops_device_reset(hba);
+   err = ufshcd_vops_toggle_device_reset(hba, true);
+   if (err) {
+   dev_err(hba->dev, "device reset pulling down failure: %d\n", 
err);
+   return;
+   }
+
+   /*
+* The reset signal is activ

[PATCH] docs: driver-model: bus.rst: Clean up the formatting, expound, modernize

[Michael Witten]

* The reStructuredText had some indentation issues.

* The HTML output was not properly formatted in places.

* Some of the details were lacking or needed clarification (especially
  with regard to how a `struct bus_type` object should be defined).

* The sysfs example hierarchy appeared outdated; I've updated it with
  output based on what my own system currently displays.

Signed-off-by: Michael Witten 
---
 Documentation/driver-api/driver-model/bus.rst | 110 +
 1 file changed, 67 insertions(+), 43 deletions(-)

diff --git a/Documentation/driver-api/driver-model/bus.rst 
b/Documentation/driver-api/driver-model/bus.rst
index 016b15a6e8ea..68a95389b1eb 100644
--- a/Documentation/driver-api/driver-model/bus.rst
+++ b/Documentation/driver-api/driver-model/bus.rst
@@ -4,34 +4,58 @@ Bus Types
 
 Definition
 ~~
-See the kerneldoc for the struct bus_type.
-
-int bus_register(struct bus_type * bus);
+* ``struct bus_type``;
+* ``int bus_register(struct bus_type *bus);``
 
 
 Declaration
 ~~~
 
-Each bus type in the kernel (PCI, USB, etc) should declare one static
-object of this type. They must initialize the name field, and may
-optionally initialize the match callback::
+For each bus type (PCI, USB, etc), there should be code that defines
+one object of type ``struct bus_type``:
+
+1. The definition should declare a file-scope identifier that has
+   external linkage.
+
+   * There should be a header that provides a declaration of this
+ identifier.
+
+   * The identifier should be explicitly exported.
+
+2. The definition should initialize the ``name`` member. Other
+   members may also be initialized (such as the ``match`` callback
+   member).
+
+For instance, here is the definition for the PCI bus type::
 
-   struct bus_type pci_bus_type = {
-  .name= "pci",
-  .match   = pci_bus_match,
-   };
+   struct bus_type pci_bus_type = {
+   .name  = "pci",   // REQUIRED
+   .match = pci_bus_match,
+   .uevent= pci_uevent,
+   .probe = pci_device_probe,
+   .remove= pci_device_remove,
+   .shutdown  = pci_device_shutdown,
+   .dev_groups= pci_dev_groups,
+   .bus_groups= pci_bus_groups,
+   .drv_groups= pci_drv_groups,
+   .pm= PCI_PM_OPS_PTR,
+   .num_vf= pci_bus_num_vf,
+   .dma_configure = pci_dma_configure,
+   };
 
-The structure should be exported to drivers in a header file:
+   EXPORT_SYMBOL(pci_bus_type);
 
-extern struct bus_type pci_bus_type;
+The relevant API header should include the following declaration::
+
+   extern struct bus_type pci_bus_type;
 
 
 Registration
 
 
-When a bus driver is initialized, it calls bus_register. This
-initializes the rest of the fields in the bus object and inserts it
-into a global list of bus types. Once the bus object is registered,
+During initialization of a bus driver, ``bus_register()`` is called; this
+initializes the rest of the fields in the bus type object and inserts it
+into a global list of bus types. Once the bus type object is registered,
 the fields in it are usable by the bus driver.
 
 
@@ -61,22 +85,25 @@ does not have a driver associated with it.
 Device and Driver Lists
 ~~~
 
-The lists of devices and drivers are intended to replace the local
-lists that many buses keep. They are lists of struct devices and
-struct device_drivers, respectively. Bus drivers are free to use the
-lists as they please, but conversion to the bus-specific type may be
-necessary.
+There are generic facilities for keeping lists of devices and drivers:
+
+* There is a list of ``struct device`` objects.
+* There is a list of ``struct device_driver`` objects.
+
+Bus drivers are free to use the lists as they please, but conversion
+to a bus-specific type may be necessary.
 
 The LDM core provides helper functions for iterating over each list::
 
-  int bus_for_each_dev(struct bus_type * bus, struct device * start,
-  void * data,
-  int (*fn)(struct device *, void *));
+   int bus_for_each_dev(struct bus_type *bus, struct device *start,
+void *data,
+int (*fn)(struct device *, void *));
 
-  int bus_for_each_drv(struct bus_type * bus, struct device_driver * start,
-  void * data, int (*fn)(struct device_driver *, void *));
+   int bus_for_each_drv(struct bus_type *bus, struct device_driver *start,
+void *data,
+int (*fn)(struct device_driver *, void *));
 
-These helpers iterate over the respective list, and call the callback
+These helpers iterate over the respective list, and call the callback (``fn``)
 for each device or driver in the list. All list acces

Re: [PATCH v2] docs/zh_CN: Improve Cinese transolation quality.

[Alex Shi]

在 2020/12/19 上午11:42, Ran Wang 写道:
> Hi Jonathan,
> 
> On Tuesday, December 8, 2020 11:00 PM Jonathan Corbet wrote:
>  
>> On Tue,  8 Dec 2020 21:16:04 +0800
>> Ran Wang  wrote:
>>
>>> Signed-off-by: Ran Wang 
>>> ---
>>> Change in v2:
>>>    - For 'cn_development_coding' part, change back to >'是关于编码过程的'
>>>
>>>   .../translations/zh_CN/process/1.Intro.rst    | 61 >++-
>>>   1 file changed, 32 insertions(+), 29 deletions(-)
>>
>> Thank you for working to improve the documentation!  >Please, though,
>> include a changelog with your patch; what does "improve >translation
>> quality" mean here?
>>
>> Thanks,
>>
>> jon
> 
> Sorry I missed your mail.
> 
> Actually I feel difficult to list the change log to describe this (after not 
> I am not a language teacher :) ).
> 
> I would say the original translation looks like a little bit more by machine: 
> English word to Chinese word directly without considering particular 
> scenarios (such as software development related terms we used in Chinese, a 
> little bit different to normal usage maybe). So I tried to re-tell the story 
> in a way more kind of 'human' to make everything clearer for Chinese reader.

Hi Ran,

I don't think you describe correctly for your new translation. And you are not 
're-tell story'
for a standard community co-work process, which we don't need. Also the 
original translation is
not by machine, it's by myself.

What you did right is polishing the Chinese words, make it more fluency and fit 
better for Chinese
custom, although it costs a bit verboseness and a bit precision.


Thanks
Alex

> 
> Anyway, I am willing to provide you such change log if you could provide me 
> an example for reference (this is my first time to post such patch).
> 
> Thanks & Regards,
> Ran
> 

Re: [PATCH 9/9] mfd: sec-irq: Do not enforce (incorrect) interrupt trigger type

[Krzysztof Kozlowski]

On Mon, Dec 21, 2020 at 08:36:02AM +0100, Marek Szyprowski wrote:
> Hi Krzysztof,
> 
> On 18.12.2020 15:22, Krzysztof Kozlowski wrote:
> > On Fri, Dec 18, 2020 at 02:25:39PM +0100, Marek Szyprowski wrote:
> >> On 10.12.2020 22:29, Krzysztof Kozlowski wrote:
> >>> Interrupt line can be configured on different hardware in different way,
> >>> even inverted.  Therefore driver should not enforce specific trigger
> >>> type - edge falling - but instead rely on Devicetree to configure it.
> >>>
> >>> The Samsung PMIC drivers are used only on Devicetree boards.
> >>>
> >>> Additionally, the PMIC datasheets describe the interrupt line as active
> >>> low with a requirement of acknowledge from the CPU therefore the edge
> >>> falling is not correct.
> >>>
> >>> Signed-off-by: Krzysztof Kozlowski 
> >> Tested-by: Marek Szyprowski 
> >>
> >> It looks that this together with DTS change fixes RTC alarm failure that
> >> I've observed from time to time on TM2e board!
> > Great! I'll add this to the commit msg.
> >
> > Thanks for testing.
> 
> BTW, while playing with this, maybe it would make sense to fix the 
> reported interrupt type for the PMIC sub-interrupts:
> 
> # grep s2mps /proc/interrupts
> 120:  0  gpa0   7 Level s2mps13
> 121:  0   s2mps13  10 Edge  rtc-alarm0

I also spotted this. It's a virtual interrupt and I am not sure whether
we can actually configure it when the hardware does not allow to set the
type (the regmap_irq_type requires register offsets).

Best regards,
Krzysztof

Re: [PATCH v3 3/5] ipmi: kcs: aspeed: Adapt to new LPC DTS layout

[Haiyue Wang]

On 12/21/2020 13:56, Chia-Wei, Wang wrote:

Add check against LPC device v2 compatible string to
ensure that the fixed device tree layout is adopted.
The LPC register offsets are also fixed accordingly.

Signed-off-by: Chia-Wei, Wang 
---
  drivers/char/ipmi/kcs_bmc_aspeed.c | 35 ++
  1 file changed, 21 insertions(+), 14 deletions(-)

diff --git a/drivers/char/ipmi/kcs_bmc_aspeed.c 
b/drivers/char/ipmi/kcs_bmc_aspeed.c
index a140203c079b..6283bfef4ea7 100644
--- a/drivers/char/ipmi/kcs_bmc_aspeed.c
+++ b/drivers/char/ipmi/kcs_bmc_aspeed.c
@@ -27,7 +27,6 @@
  
  #define KCS_CHANNEL_MAX 4
  
-/* mapped to lpc-bmc@0 IO space */

  #define LPC_HICR00x000
  #define LPC_HICR0_LPC3E  BIT(7)
  #define LPC_HICR0_LPC2E  BIT(6)
@@ -52,15 +51,13 @@
  #define LPC_STR1 0x03C
  #define LPC_STR2 0x040
  #define LPC_STR3 0x044
-
-/* mapped to lpc-host@80 IO space */
-#define LPC_HICRB0x080
+#define LPC_HICRB0x100
  #define LPC_HICRB_IBFIF4 BIT(1)
  #define LPC_HICRB_LPC4E  BIT(0)
-#define LPC_LADR40x090
-#define LPC_IDR4 0x094
-#define LPC_ODR4 0x098
-#define LPC_STR4 0x09C
+#define LPC_LADR40x110
+#define LPC_IDR4 0x114
+#define LPC_ODR4 0x118
+#define LPC_STR4 0x11C
  
  struct aspeed_kcs_bmc {

struct regmap *map;
@@ -345,15 +342,25 @@ static int aspeed_kcs_probe(struct platform_device *pdev)
  {
struct device *dev = &pdev->dev;
struct kcs_bmc *kcs_bmc;
-   struct device_node *np;
+   struct device_node *kcs_np;
+   struct device_node *lpc_np;
int rc;
  


I think you can just use 'np' to do LPC compatible checking:

np = pdev->dev.of_node->parent;

if (!of_device_is_compatible(lpc_np, "aspeed,ast2400-lpc-v2") &&
!of_device_is_compatible(lpc_np, "aspeed,ast2500-lpc-v2") &&
!of_device_is_compatible(lpc_np, "aspeed,ast2600-lpc-v2")) {
dev_err(dev, "unsupported LPC device binding\n");
return -ENODEV;
}


before:

np = pdev->dev.of_node;
if (of_device_is_compatible(np, "aspeed,ast2400-kcs-bmc") ||
of_device_is_compatible(np, "aspeed,ast2500-kcs-bmc"))

Then the patch is clear. ;-)


-   np = pdev->dev.of_node;
-   if (of_device_is_compatible(np, "aspeed,ast2400-kcs-bmc") ||
-   of_device_is_compatible(np, "aspeed,ast2500-kcs-bmc"))
+   kcs_np = dev->of_node;
+   lpc_np = kcs_np->parent;
+
+   if (!of_device_is_compatible(lpc_np, "aspeed,ast2400-lpc-v2") &&
+   !of_device_is_compatible(lpc_np, "aspeed,ast2500-lpc-v2") &&
+   !of_device_is_compatible(lpc_np, "aspeed,ast2600-lpc-v2")) {
+   dev_err(dev, "unsupported LPC device binding\n");
+   return -ENODEV;
+   }
+
+   if (of_device_is_compatible(kcs_np, "aspeed,ast2400-kcs-bmc") ||
+   of_device_is_compatible(kcs_np, 
"aspeed,ast2500-kcs-bmc"))
kcs_bmc = aspeed_kcs_probe_of_v1(pdev);
-   else if (of_device_is_compatible(np, "aspeed,ast2400-kcs-bmc-v2") ||
-   of_device_is_compatible(np, 
"aspeed,ast2500-kcs-bmc-v2"))
+   else if (of_device_is_compatible(kcs_np, "aspeed,ast2400-kcs-bmc-v2") ||
+   of_device_is_compatible(kcs_np, 
"aspeed,ast2500-kcs-bmc-v2"))
kcs_bmc = aspeed_kcs_probe_of_v2(pdev);
else
return -EINVAL;

Re: [PATCH v8 3/4] arm64: dts: imx8m: add NVMEM provider and consumer to read soc unique ID

[Krzysztof Kozlowski]

On Mon, Dec 21, 2020 at 03:10:52AM +, Alice Guo (OSS) wrote:
> 
> 
> > -Original Message-
> > From: Krzysztof Kozlowski 
> > Sent: 2020年12月19日 20:17
> > To: Alice Guo (OSS) 
> > Cc: robh...@kernel.org; shawn...@kernel.org; s.ha...@pengutronix.de;
> > ker...@pengutronix.de; feste...@gmail.com; devicet...@vger.kernel.org;
> > linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; 
> > dl-linux-imx
> > 
> > Subject: Re: [PATCH v8 3/4] arm64: dts: imx8m: add NVMEM provider and
> > consumer to read soc unique ID
> > 
> > On Fri, Dec 18, 2020 at 04:37:25PM +0800, Alice Guo (OSS) wrote:
> > > From: Alice Guo 
> > >
> > > In order to be able to use NVMEM APIs to read soc unique ID, add the
> > > nvmem data cell and name for nvmem-cells to the "soc" node, and add a
> > > nvmem node which provides soc unique ID to efuse@3035.
> > >
> > > Signed-off-by: Alice Guo 
> > > ---
> > > Changes for v8:
> > >  - none
> > > Changes for v7:
> > >  - add Reviewed-by
> > 
> > What happened with my reviewed-by?
> > 
> > Best regards,
> > Krzysztof
> 
> Hi,
> I forgot to add reviewed-by. ☹

It was there already, so you had to remove it for some reason... but you
kept the changelog.

Best regards,
Krzysztof

Re: [PATCH net v2 1/3] ethernet: ucc_geth: set dev->max_mtu to 1518

[Vladimir Oltean]

On Fri, Dec 18, 2020 at 11:55:36AM +0100, Rasmus Villemoes wrote:
> All the buffers and registers are already set up appropriately for an
> MTU slightly above 1500, so we just need to expose this to the
> networking stack. AFAICT, there's no need to implement .ndo_change_mtu
> when the receive buffers are always set up to support the max_mtu.
> 
> This fixes several warnings during boot on our mpc8309-board with an
> embedded mv88e6250 switch:
> 
> mv88e6085 mdio@e0102120:10: nonfatal error -34 setting MTU 1500 on port 0
> ...
> mv88e6085 mdio@e0102120:10: nonfatal error -34 setting MTU 1500 on port 4
> ucc_geth e0102000.ethernet eth1: error -22 setting MTU to 1504 to include DSA 
> overhead
> 
> The last line explains what the DSA stack tries to do: achieving an MTU
> of 1500 on-the-wire requires that the master netdevice connected to
> the CPU port supports an MTU of 1500+the tagging overhead.
> 
> Fixes: bfcb813203e6 ("net: dsa: configure the MTU for switch ports")
> Cc: Vladimir Oltean 
> Reviewed-by: Andrew Lunn 
> Signed-off-by: Rasmus Villemoes 
> ---

Reviewed-by: Vladimir Oltean 

Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect

[Nadav Amit]

> On Dec 19, 2020, at 10:05 PM, Yu Zhao  wrote:
> 
> On Sat, Dec 19, 2020 at 01:34:29PM -0800, Nadav Amit wrote:
>> [ cc’ing some more people who have experience with similar problems ]
>> 
>>> On Dec 19, 2020, at 11:15 AM, Andrea Arcangeli  wrote:
>>> 
>>> Hello,
>>> 
>>> On Fri, Dec 18, 2020 at 08:30:06PM -0800, Nadav Amit wrote:
 Analyzing this problem indicates that there is a real bug since
 mmap_lock is only taken for read in mwriteprotect_range(). This might
>>> 
>>> Never having to take the mmap_sem for writing, and in turn never
>>> blocking, in order to modify the pagetables is quite an important
>>> feature in uffd that justifies uffd instead of mprotect. It's not the
>>> most important reason to use uffd, but it'd be nice if that guarantee
>>> would remain also for the UFFDIO_WRITEPROTECT API, not only for the
>>> other pgtable manipulations.
>>> 
 Consider the following scenario with 3 CPUs (cpu2 is not shown):
 
 cpu0   cpu1
    
 userfaultfd_writeprotect()
 [ write-protecting ]
 mwriteprotect_range()
 mmap_read_lock()
 change_protection()
 change_protection_range()
  ...
  change_pte_range()
  [ defer TLB flushes]
userfaultfd_writeprotect()
 mmap_read_lock()
 change_protection()
 [ write-unprotect ]
 ...
  [ unprotect PTE logically ]
...
[ page-fault]
...
wp_page_copy()
[ set new writable page in PTE]
> 
> I don't see any problem in this example -- wp_page_copy() calls
> ptep_clear_flush_notify(), which should take care of the stale entry
> left by cpu0.
> 
> That being said, I suspect the memory corruption you observed is
> related this example, with cpu1 running something else that flushes
> conditionally depending on pte_write().
> 
> Do you know which type of pages were corrupted? file, anon, etc.

First, Yu, you are correct. My analysis is incorrect, but let me have
another try (below). To answer your (and Andrea’s) question - this happens
with upstream without any changes, excluding a small fix to the selftest,
since it failed (got stuck) due to missing wake events. [1]

We are talking about anon memory.

So to correct myself, I think that what I really encountered was actually
during MM_CP_UFFD_WP_RESOLVE (i.e., when the protection is removed). The
problem was that in this case the “write”-bit was removed during unprotect.
Sorry for the strange formatting to fit within 80 columns:


[ Start: PTE is writable ]

cpu0cpu1cpu2

[ Writable PTE 
  cached in TLB ]
userfaultfd_writeprotect()  
[ write-*unprotect* ]
mwriteprotect_range()
mmap_read_lock()
change_protection()

change_protection_range()
 ...
 change_pte_range()
 [ *clear* “write”-bit ]
 [ defer TLB flushes]
[ page-fault ]
…
wp_page_copy()
 cow_user_page()
  [ copy page ]
[ write to old
  page ]
…
 set_pte_at_notify()

[ End: cpu2 write not copied form old to new page. ]


So this was actually resolved by the second part of the patch - changing
preserve_write in change_pte_range(). I removed the acquisition of mmap_lock
for write, left the change in change_pte_range() and the test passes.

Let me give some more thought on whether a mmap_lock is needed 
for write. I need to rehash this TLB flushing algorithm.

Thanks,
Nadav

[1] https://lore.kernel.org/patchwork/patch/1346386

[PATCH] IB/sa: Fix memleak in ib_nl_make_request

[Dinghao Liu]

When rdma_nl_multicast() fails, skb should be freed
just like when ibnl_put_msg() fails.

Signed-off-by: Dinghao Liu 
---
 drivers/infiniband/core/sa_query.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/infiniband/core/sa_query.c 
b/drivers/infiniband/core/sa_query.c
index 89a831fa1885..8bd23b5cc913 100644
--- a/drivers/infiniband/core/sa_query.c
+++ b/drivers/infiniband/core/sa_query.c
@@ -873,8 +873,10 @@ static int ib_nl_make_request(struct ib_sa_query *query, 
gfp_t gfp_mask)
spin_lock_irqsave(&ib_nl_request_lock, flags);
ret = rdma_nl_multicast(&init_net, skb, RDMA_NL_GROUP_LS, gfp_flag);
 
-   if (ret)
+   if (ret) {
+   nlmsg_free(skb);
goto out;
+   }
 
/* Put the request on the list.*/
delay = msecs_to_jiffies(sa_local_svc_timeout_ms);
-- 
2.17.1

[PATCH v2 0/5] Fix the incorrect memmep defer init handling and do some cleanup

[Baoquan He]

VMware reported the performance regression during memmap_init() invocation.
And they bisected to commit 73a6e474cb376 ("mm: memmap_init: iterate over
memblock regions rather that check each PFN") causing it.

https://lore.kernel.org/linux-mm/dm6pr05mb52921ff90fa01cc337dd23a1a4...@dm6pr05mb5292.namprd05.prod.outlook.com/

After investigation, it's caused by incorrect memmap init defer handling
in memmap_init_zone() after commit 73a6e474cb376. The current
memmap_init_zone() only handle one memory region of one zone, while
memmap_init() iterates over all its memory regions and pass them one by
one into memmap_init_zone() to handle.

So in this patchset, patch 1/5 fixes the bug observed by VMware. Patch
2~5/5 clean up codes.
accordingly.

VMware helped do the testing for the patch 1 of v1 version which was based
on master branch of Linus's tree on their VMware ESI platform, while the
patch 1 is not changed in functionality in v2. And I haven't got a
ia64 machine to compile or test, will really appreciate if anyone can help
compile this patchset on one. This patchset is based on the latest next/master,
only did the basic test.  

Baoquan He (5):
  mm: memmap defer init dosn't work as expected
  mm: rename memmap_init() and memmap_init_zone()
  mm: simplify parater of function memmap_init_zone()
  mm: simplify parameter of setup_usemap()
  mm: remove unneeded local variable in free_area_init_core

 arch/ia64/include/asm/pgtable.h |  3 +-
 arch/ia64/mm/init.c | 16 +
 include/linux/mm.h  |  5 +--
 mm/memory_hotplug.c |  2 +-
 mm/page_alloc.c | 60 -
 5 files changed, 43 insertions(+), 43 deletions(-)

-- 
2.17.2

[PATCH v2 2/5] mm: rename memmap_init() and memmap_init_zone()

[Baoquan He]

The current memmap_init_zone() only handles memory region inside one zone,
actually memmap_init() does the memmap init of one zone. So rename both of
them accordingly.

And also rename the function parameter 'range_start_pfn' and local variable
'range_end_pfn' of memmap_init() to zone_start_pfn/zone_end_pfn.

Signed-off-by: Baoquan He 
---
 arch/ia64/include/asm/pgtable.h |  2 +-
 arch/ia64/mm/init.c |  6 +++---
 include/linux/mm.h  |  2 +-
 mm/memory_hotplug.c |  2 +-
 mm/page_alloc.c | 24 
 5 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/arch/ia64/include/asm/pgtable.h b/arch/ia64/include/asm/pgtable.h
index 779b6972aa84..dce2ff37df65 100644
--- a/arch/ia64/include/asm/pgtable.h
+++ b/arch/ia64/include/asm/pgtable.h
@@ -520,7 +520,7 @@ extern struct page *zero_page_memmap_ptr;
 
 #  ifdef CONFIG_VIRTUAL_MEM_MAP
   /* arch mem_map init routine is needed due to holes in a virtual mem_map */
-extern void memmap_init (unsigned long size, int nid, unsigned long zone,
+extern void memmap_init_zone(unsigned long size, int nid, unsigned long 
zone,
 unsigned long start_pfn);
 #  endif /* CONFIG_VIRTUAL_MEM_MAP */
 # endif /* !__ASSEMBLY__ */
diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
index e76386a3479e..c8e68e92beb3 100644
--- a/arch/ia64/mm/init.c
+++ b/arch/ia64/mm/init.c
@@ -535,18 +535,18 @@ virtual_memmap_init(u64 start, u64 end, void *arg)
/ sizeof(struct page));
 
if (map_start < map_end)
-   memmap_init_zone((unsigned long)(map_end - map_start),
+   memmap_init_range((unsigned long)(map_end - map_start),
 args->nid, args->zone, page_to_pfn(map_start), 
page_to_pfn(map_end),
 MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
return 0;
 }
 
 void __meminit
-memmap_init (unsigned long size, int nid, unsigned long zone,
+memmap_init_zone(unsigned long size, int nid, unsigned long zone,
 unsigned long start_pfn)
 {
if (!vmem_map) {
-   memmap_init_zone(size, nid, zone, start_pfn, start_pfn + size,
+   memmap_init_range(size, nid, zone, start_pfn, start_pfn + size,
 MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
} else {
struct page *start;
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 92e06ea053f4..f72c138c2272 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2432,7 +2432,7 @@ extern int __meminit early_pfn_to_nid(unsigned long pfn);
 #endif
 
 extern void set_dma_reserve(unsigned long new_dma_reserve);
-extern void memmap_init_zone(unsigned long, int, unsigned long,
+extern void memmap_init_range(unsigned long, int, unsigned long,
unsigned long, unsigned long, enum meminit_context,
struct vmem_altmap *, int migratetype);
 extern void setup_per_zone_wmarks(void);
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index f9d57b9be8c7..ddcb1cd24c60 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -713,7 +713,7 @@ void __ref move_pfn_range_to_zone(struct zone *zone, 
unsigned long start_pfn,
 * expects the zone spans the pfn range. All the pages in the range
 * are reserved so nobody should be touching them so we should be safe
 */
-   memmap_init_zone(nr_pages, nid, zone_idx(zone), start_pfn, 0,
+   memmap_init_range(nr_pages, nid, zone_idx(zone), start_pfn, 0,
 MEMINIT_HOTPLUG, altmap, migratetype);
 
set_zone_contiguous(zone);
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 32645f2e7b96..4b46326099d9 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6117,7 +6117,7 @@ overlap_memmap_init(unsigned long zone, unsigned long 
*pfn)
  * (usually MIGRATE_MOVABLE). Besides setting the migratetype, no related
  * zone stats (e.g., nr_isolate_pageblock) are touched.
  */
-void __meminit memmap_init_zone(unsigned long size, int nid, unsigned long 
zone,
+void __meminit memmap_init_range(unsigned long size, int nid, unsigned long 
zone,
unsigned long start_pfn, unsigned long zone_end_pfn,
enum meminit_context context,
struct vmem_altmap *altmap, int migratetype)
@@ -6292,24 +6292,24 @@ static inline u64 init_unavailable_range(unsigned long 
spfn, unsigned long epfn,
 }
 #endif
 
-void __init __weak memmap_init(unsigned long size, int nid,
+void __init __weak memmap_init_zone(unsigned long size, int nid,
   unsigned long zone,
-  unsigned long range_start_pfn)
+  unsigned long zone_start_pfn)
 {
unsigned long start_pfn, end_pfn, hole_start_pfn = 0;
-   unsigned long range_end_pfn = range_start_pfn + size;
+   unsigned long zone_end_pfn = zone_start_pfn + size;
u64 pgcnt = 0;
in

[PATCH v2 3/5] mm: simplify parater of function memmap_init_zone()

[Baoquan He]

As David suggested, simply passing 'struct zone *zone' is enough. We can
get all needed information from 'struct zone*' easily.

Suggested-by: David Hildenbrand 
Signed-off-by: Baoquan He 
---
 arch/ia64/include/asm/pgtable.h |  3 +--
 arch/ia64/mm/init.c | 12 +++-
 mm/page_alloc.c | 20 ++--
 3 files changed, 18 insertions(+), 17 deletions(-)

diff --git a/arch/ia64/include/asm/pgtable.h b/arch/ia64/include/asm/pgtable.h
index dce2ff37df65..2c81394a2430 100644
--- a/arch/ia64/include/asm/pgtable.h
+++ b/arch/ia64/include/asm/pgtable.h
@@ -520,8 +520,7 @@ extern struct page *zero_page_memmap_ptr;
 
 #  ifdef CONFIG_VIRTUAL_MEM_MAP
   /* arch mem_map init routine is needed due to holes in a virtual mem_map */
-extern void memmap_init_zone(unsigned long size, int nid, unsigned long 
zone,
-unsigned long start_pfn);
+extern void memmap_init_zone(struct zone *zone);
 #  endif /* CONFIG_VIRTUAL_MEM_MAP */
 # endif /* !__ASSEMBLY__ */
 
diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
index c8e68e92beb3..ccbda1a74c95 100644
--- a/arch/ia64/mm/init.c
+++ b/arch/ia64/mm/init.c
@@ -541,12 +541,14 @@ virtual_memmap_init(u64 start, u64 end, void *arg)
return 0;
 }
 
-void __meminit
-memmap_init_zone(unsigned long size, int nid, unsigned long zone,
-unsigned long start_pfn)
+void __meminit memmap_init_zone(struct zone *zone)
 {
+   unsigned long size = zone->spanned_pages;
+   int nid = zone_to_nid(zone), zone_id = zone_idx(zone);
+   unsigned long start_pfn = zone->zone_start_pfn;
+
if (!vmem_map) {
-   memmap_init_range(size, nid, zone, start_pfn, start_pfn + size,
+   memmap_init_range(size, nid, zone_id, start_pfn, start_pfn + 
size,
 MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
} else {
struct page *start;
@@ -556,7 +558,7 @@ memmap_init_zone(unsigned long size, int nid, unsigned long 
zone,
args.start = start;
args.end = start + size;
args.nid = nid;
-   args.zone = zone;
+   args.zone = zone_id;
 
efi_memmap_walk(virtual_memmap_init, &args);
}
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 4b46326099d9..7a6626351ed7 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6292,16 +6292,16 @@ static inline u64 init_unavailable_range(unsigned long 
spfn, unsigned long epfn,
 }
 #endif
 
-void __init __weak memmap_init_zone(unsigned long size, int nid,
-  unsigned long zone,
-  unsigned long zone_start_pfn)
+void __init __weak memmap_init_zone(struct zone *zone)
 {
unsigned long start_pfn, end_pfn, hole_start_pfn = 0;
-   unsigned long zone_end_pfn = zone_start_pfn + size;
+   int i, nid = zone_to_nid(zone), zone_id = zone_idx(zone);
+   unsigned long zone_start_pfn = zone->zone_start_pfn;
+   unsigned long zone_end_pfn = zone_start_pfn + zone->spanned_pages;
u64 pgcnt = 0;
-   int i;
 
for_each_mem_pfn_range(i, nid, &start_pfn, &end_pfn, NULL) {
+   unsigned long size;
start_pfn = clamp(start_pfn, zone_start_pfn, zone_end_pfn);
end_pfn = clamp(end_pfn, zone_start_pfn, zone_end_pfn);
hole_start_pfn = clamp(hole_start_pfn, zone_start_pfn,
@@ -6309,13 +6309,13 @@ void __init __weak memmap_init_zone(unsigned long size, 
int nid,
 
if (end_pfn > start_pfn) {
size = end_pfn - start_pfn;
-   memmap_init_range(size, nid, zone, start_pfn, 
zone_end_pfn,
+   memmap_init_range(size, nid, zone_id, start_pfn, 
zone_end_pfn,
 MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
}
 
if (hole_start_pfn < start_pfn)
pgcnt += init_unavailable_range(hole_start_pfn,
-   start_pfn, zone, nid);
+   start_pfn, zone_id, 
nid);
hole_start_pfn = end_pfn;
}
 
@@ -6328,11 +6328,11 @@ void __init __weak memmap_init_zone(unsigned long size, 
int nid,
 */
if (hole_start_pfn < zone_end_pfn)
pgcnt += init_unavailable_range(hole_start_pfn, zone_end_pfn,
-   zone, nid);
+   zone_id, nid);
 
if (pgcnt)
pr_info("%s: Zeroed struct page in unavailable ranges: %lld\n",
-   zone_names[zone], pgcnt);
+   zone_names[zone_id], pgcnt);
 }
 
 static int zone_batchsize(struct zone *zone)
@@ -7039,7 +7039,7 @@ static void __init free_area_init_core(struct pglist_data 
*pgdat)
set_pageblock_order();
setup_u

[PATCH v2 4/5] mm: simplify parameter of setup_usemap()

[Baoquan He]

Parameter 'zone' has got needed information, let's remove other
unnecessary parameters.

Signed-off-by: Baoquan He 
---
 mm/page_alloc.c | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 7a6626351ed7..7f0a917ab858 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6824,25 +6824,22 @@ static unsigned long __init usemap_size(unsigned long 
zone_start_pfn, unsigned l
return usemapsize / 8;
 }
 
-static void __ref setup_usemap(struct pglist_data *pgdat,
-   struct zone *zone,
-   unsigned long zone_start_pfn,
-   unsigned long zonesize)
+static void __ref setup_usemap(struct zone *zone)
 {
-   unsigned long usemapsize = usemap_size(zone_start_pfn, zonesize);
+   unsigned long usemapsize = usemap_size(zone->zone_start_pfn,
+  zone->spanned_pages);
zone->pageblock_flags = NULL;
if (usemapsize) {
zone->pageblock_flags =
memblock_alloc_node(usemapsize, SMP_CACHE_BYTES,
-   pgdat->node_id);
+   zone_to_nid(zone));
if (!zone->pageblock_flags)
panic("Failed to allocate %ld bytes for zone %s 
pageblock flags on node %d\n",
- usemapsize, zone->name, pgdat->node_id);
+ usemapsize, zone->name, zone_to_nid(zone));
}
 }
 #else
-static inline void setup_usemap(struct pglist_data *pgdat, struct zone *zone,
-   unsigned long zone_start_pfn, unsigned long 
zonesize) {}
+static inline void setup_usemap(struct zone *zone) {}
 #endif /* CONFIG_SPARSEMEM */
 
 #ifdef CONFIG_HUGETLB_PAGE_SIZE_VARIABLE
@@ -7037,7 +7034,7 @@ static void __init free_area_init_core(struct pglist_data 
*pgdat)
continue;
 
set_pageblock_order();
-   setup_usemap(pgdat, zone, zone_start_pfn, size);
+   setup_usemap(zone);
init_currently_empty_zone(zone, zone_start_pfn, size);
memmap_init_zone(zone);
}
-- 
2.17.2

[PATCH v2 5/5] mm: remove unneeded local variable in free_area_init_core

[Baoquan He]

Local variable 'zone_start_pfn' is not needed since there's only
one call site in free_area_init_core(). Let's remove it and pass
zone->zone_start_pfn directly to init_currently_empty_zone().

Signed-off-by: Baoquan He 
---
 mm/page_alloc.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 7f0a917ab858..189a86253c93 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6986,7 +6986,6 @@ static void __init free_area_init_core(struct pglist_data 
*pgdat)
for (j = 0; j < MAX_NR_ZONES; j++) {
struct zone *zone = pgdat->node_zones + j;
unsigned long size, freesize, memmap_pages;
-   unsigned long zone_start_pfn = zone->zone_start_pfn;
 
size = zone->spanned_pages;
freesize = zone->present_pages;
@@ -7035,7 +7034,7 @@ static void __init free_area_init_core(struct pglist_data 
*pgdat)
 
set_pageblock_order();
setup_usemap(zone);
-   init_currently_empty_zone(zone, zone_start_pfn, size);
+   init_currently_empty_zone(zone, zone->zone_start_pfn, size);
memmap_init_zone(zone);
}
 }
-- 
2.17.2

[PATCH v2 1/5] mm: memmap defer init dosn't work as expected

[Baoquan He]

VMware observed a performance regression during memmap init on their platform,
and bisected to commit 73a6e474cb376 ("mm: memmap_init: iterate over memblock
regions rather that check each PFN") causing it.

Before the commit:

  [0.033176] Normal zone: 1445888 pages used for memmap
  [0.033176] Normal zone: 89391104 pages, LIFO batch:63
  [0.035851] ACPI: PM-Timer IO Port: 0x448

With commit

  [0.026874] Normal zone: 1445888 pages used for memmap
  [0.026875] Normal zone: 89391104 pages, LIFO batch:63
  [2.028450] ACPI: PM-Timer IO Port: 0x448

The root cause is the current memmap defer init doesn't work as expected.
Before, memmap_init_zone() was used to do memmap init of one whole zone, to
initialize all low zones of one numa node, but defer memmap init of the
last zone in that numa node. However, since commit 73a6e474cb376, function
memmap_init() is adapted to iterater over memblock regions inside one zone,
then call memmap_init_zone() to do memmap init for each region.

E.g, on VMware's system, the memory layout is as below, there are two memory
regions in node 2. The current code will mistakenly initialize the whole 1st
region [mem 0xab-0xfc], then do memmap defer to iniatialize
only one memmory section on the 2nd region [mem 0x100-0x1033fff].
In fact, we only expect to see that there's only one memory section's memmap
initialized. That's why more time is costed at the time.

[0.008842] ACPI: SRAT: Node 0 PXM 0 [mem 0x-0x0009]
[0.008842] ACPI: SRAT: Node 0 PXM 0 [mem 0x0010-0xbfff]
[0.008843] ACPI: SRAT: Node 0 PXM 0 [mem 0x1-0x55]
[0.008844] ACPI: SRAT: Node 1 PXM 1 [mem 0x56-0xaa]
[0.008844] ACPI: SRAT: Node 2 PXM 2 [mem 0xab-0xfc]
[0.008845] ACPI: SRAT: Node 2 PXM 2 [mem 0x100-0x1033fff]

Now, let's add a parameter 'zone_end_pfn' to memmap_init_zone() to pass
down the real zone end pfn so that defer_init() can use it to judge whether
defer need be taken in zone wide.

Fixes: commit 73a6e474cb376 ("mm: memmap_init: iterate over memblock regions 
rather that check each PFN")
Reported-by: Rahul Gopakumar 
Signed-off-by: Baoquan He 
Cc: sta...@vger.kernel.org
---
 arch/ia64/mm/init.c | 4 ++--
 include/linux/mm.h  | 5 +++--
 mm/memory_hotplug.c | 2 +-
 mm/page_alloc.c | 8 +---
 4 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
index 9b5acf8fb092..e76386a3479e 100644
--- a/arch/ia64/mm/init.c
+++ b/arch/ia64/mm/init.c
@@ -536,7 +536,7 @@ virtual_memmap_init(u64 start, u64 end, void *arg)
 
if (map_start < map_end)
memmap_init_zone((unsigned long)(map_end - map_start),
-args->nid, args->zone, page_to_pfn(map_start),
+args->nid, args->zone, page_to_pfn(map_start), 
page_to_pfn(map_end),
 MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
return 0;
 }
@@ -546,7 +546,7 @@ memmap_init (unsigned long size, int nid, unsigned long 
zone,
 unsigned long start_pfn)
 {
if (!vmem_map) {
-   memmap_init_zone(size, nid, zone, start_pfn,
+   memmap_init_zone(size, nid, zone, start_pfn, start_pfn + size,
 MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
} else {
struct page *start;
diff --git a/include/linux/mm.h b/include/linux/mm.h
index e4e5be20b0c2..92e06ea053f4 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2432,8 +2432,9 @@ extern int __meminit early_pfn_to_nid(unsigned long pfn);
 #endif
 
 extern void set_dma_reserve(unsigned long new_dma_reserve);
-extern void memmap_init_zone(unsigned long, int, unsigned long, unsigned long,
-   enum meminit_context, struct vmem_altmap *, int migratetype);
+extern void memmap_init_zone(unsigned long, int, unsigned long,
+   unsigned long, unsigned long, enum meminit_context,
+   struct vmem_altmap *, int migratetype);
 extern void setup_per_zone_wmarks(void);
 extern int __meminit init_per_zone_wmark_min(void);
 extern void mem_init(void);
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index af41fb990820..f9d57b9be8c7 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -713,7 +713,7 @@ void __ref move_pfn_range_to_zone(struct zone *zone, 
unsigned long start_pfn,
 * expects the zone spans the pfn range. All the pages in the range
 * are reserved so nobody should be touching them so we should be safe
 */
-   memmap_init_zone(nr_pages, nid, zone_idx(zone), start_pfn,
+   memmap_init_zone(nr_pages, nid, zone_idx(zone), start_pfn, 0,
 MEMINIT_HOTPLUG, altmap, migratetype);
 
set_zone_contiguous(zone);
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 8cea0823b70e..32645f2e7b96 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -423,6 +423,8 @@ defer_

[PATCH] net: ethernet: mvneta: Fix error handling in mvneta_probe

[Dinghao Liu]

When mvneta_port_power_up() fails, we should execute
cleanup functions after label err_netdev to avoid memleak.

Fixes: 41c2b6b4f0f80 ("net: ethernet: mvneta: Add back interface mode 
validation")
Signed-off-by: Dinghao Liu 
---
 drivers/net/ethernet/marvell/mvneta.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c 
b/drivers/net/ethernet/marvell/mvneta.c
index 563ceac3060f..3369ec717a51 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -5255,7 +5255,7 @@ static int mvneta_probe(struct platform_device *pdev)
err = mvneta_port_power_up(pp, pp->phy_interface);
if (err < 0) {
dev_err(&pdev->dev, "can't power up port\n");
-   return err;
+   goto err_netdev;
}
 
/* Armada3700 network controller does not support per-cpu
-- 
2.17.1

[PATCH v3] pinctrl: remove empty lines in pinctrl subsystem

[Zhaoyu Liu]

Remove all empty lines at the end of functions in pinctrl subsystem,
and make the code neat.

Reviewed-by: Bjorn Andersson 
Reviewed-by: Geert Uytterhoeven 
Reviewed-by: Linus Walleij 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Zhaoyu Liu 
---
Changelog:
v3:
- Rebuild the patch based on "devel" branch of linux-pinctrl.
- Delete "Target files" description from the commit message.
v2:
- Fixed the same problem in all files in pinctrl subsystem.
v1:
- Remove the blank line in pinctrl_register().
---
 drivers/pinctrl/actions/pinctrl-owl.c | 1 -
 drivers/pinctrl/core.c| 1 -
 drivers/pinctrl/freescale/pinctrl-imx1-core.c | 1 -
 drivers/pinctrl/mvebu/pinctrl-armada-37xx.c   | 1 -
 drivers/pinctrl/pinctrl-at91.c| 1 -
 drivers/pinctrl/pinctrl-st.c  | 1 -
 drivers/pinctrl/pinctrl-sx150x.c  | 1 -
 drivers/pinctrl/qcom/pinctrl-sdm845.c | 1 -
 drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c   | 1 -
 drivers/pinctrl/renesas/pfc-r8a77950.c| 1 -
 drivers/pinctrl/renesas/pfc-r8a77951.c| 1 -
 drivers/pinctrl/renesas/pfc-r8a7796.c | 1 -
 drivers/pinctrl/renesas/pfc-r8a77965.c| 1 -
 13 files changed, 13 deletions(-)

diff --git a/drivers/pinctrl/actions/pinctrl-owl.c 
b/drivers/pinctrl/actions/pinctrl-owl.c
index 903a4baf3846..c8b3e396ea27 100644
--- a/drivers/pinctrl/actions/pinctrl-owl.c
+++ b/drivers/pinctrl/actions/pinctrl-owl.c
@@ -444,7 +444,6 @@ static int owl_group_config_get(struct pinctrl_dev 
*pctrldev,
*config = pinconf_to_config_packed(param, arg);
 
return ret;
-
 }
 
 static int owl_group_config_set(struct pinctrl_dev *pctrldev,
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 9fc4433fece4..7d3370289938 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -2117,7 +2117,6 @@ struct pinctrl_dev *pinctrl_register(struct pinctrl_desc 
*pctldesc,
return ERR_PTR(error);
 
return pctldev;
-
 }
 EXPORT_SYMBOL_GPL(pinctrl_register);
 
diff --git a/drivers/pinctrl/freescale/pinctrl-imx1-core.c 
b/drivers/pinctrl/freescale/pinctrl-imx1-core.c
index 08d110078c43..70186448d2f4 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx1-core.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx1-core.c
@@ -290,7 +290,6 @@ static const struct pinctrl_ops imx1_pctrl_ops = {
.pin_dbg_show = imx1_pin_dbg_show,
.dt_node_to_map = imx1_dt_node_to_map,
.dt_free_map = imx1_dt_free_map,
-
 };
 
 static int imx1_pmx_set(struct pinctrl_dev *pctldev, unsigned selector,
diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c 
b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
index 68894e9e05d2..5a68e242f6b3 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
@@ -188,7 +188,6 @@ static struct armada_37xx_pin_group armada_37xx_nb_groups[] 
= {
PIN_GRP_GPIO_2("led1_od", 12, 1, BIT(21), BIT(21), 0, "led"),
PIN_GRP_GPIO_2("led2_od", 13, 1, BIT(22), BIT(22), 0, "led"),
PIN_GRP_GPIO_2("led3_od", 14, 1, BIT(23), BIT(23), 0, "led"),
-
 };
 
 static struct armada_37xx_pin_group armada_37xx_sb_groups[] = {
diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
index 72edc675431c..9015486e38c1 100644
--- a/drivers/pinctrl/pinctrl-at91.c
+++ b/drivers/pinctrl/pinctrl-at91.c
@@ -733,7 +733,6 @@ static const struct at91_pinctrl_mux_ops sam9x60_ops = {
.get_slewrate   = at91_mux_sam9x60_get_slewrate,
.set_slewrate   = at91_mux_sam9x60_set_slewrate,
.irq_type   = alt_gpio_irq_type,
-
 };
 
 static struct at91_pinctrl_mux_ops sama5d3_ops = {
diff --git a/drivers/pinctrl/pinctrl-st.c b/drivers/pinctrl/pinctrl-st.c
index 7b8c7a0b13de..43d9e6c7fd81 100644
--- a/drivers/pinctrl/pinctrl-st.c
+++ b/drivers/pinctrl/pinctrl-st.c
@@ -541,7 +541,6 @@ static void st_pinconf_set_retime_packed(struct st_pinctrl 
*info,
st_regmap_field_bit_set_clear_pin(rt_p->delay_0, delay & 0x1, pin);
/* 2 bit delay, msb */
st_regmap_field_bit_set_clear_pin(rt_p->delay_1, delay & 0x2, pin);
-
 }
 
 static void st_pinconf_set_retime_dedicated(struct st_pinctrl *info,
diff --git a/drivers/pinctrl/pinctrl-sx150x.c b/drivers/pinctrl/pinctrl-sx150x.c
index c110f780407b..484a3b9e875c 100644
--- a/drivers/pinctrl/pinctrl-sx150x.c
+++ b/drivers/pinctrl/pinctrl-sx150x.c
@@ -443,7 +443,6 @@ static void sx150x_gpio_set(struct gpio_chip *chip, 
unsigned int offset,
sx150x_gpio_oscio_set(pctl, value);
else
__sx150x_gpio_set(pctl, offset, value);
-
 }
 
 static void sx150x_gpio_set_multiple(struct gpio_chip *chip,
diff --git a/drivers/pinctrl/qcom/pinctrl-sdm845.c 
b/drivers/pinctrl/qcom/pinctrl-sdm845.c
index 2834d2c1338c..c51793f6546f 100644
--- a/drivers/pinctrl/qcom/pinctrl-sdm845.c
+++ b/drivers/pinctrl/qcom/pinctrl-sdm845.c
@@ -1310,7 +1310,6 @@ static const struct msm_pinctrl_soc_data sdm845_pinctrl = 
{
.n

Fair Pay Initiative, OS is now €-X.

[Ywe Cærlyn]

We think we can simplify the name to €-X, Euro being optimal for a 
digital currency.


I have updated my homepage:

https://ihsan-code.eu/

Serenity,
Ywe Cærlyn.

Re: [PATCH] Add spi-nor driver for Realtek RTL838x/RTL839x switch SoCs

[Chuanhong Guo]

Hi!

On Sun, Dec 20, 2020 at 7:01 AM Bert Vermeulen  wrote:
>
> On 12/16/20 9:30 AM, tudor.amba...@microchip.com wrote:
> > On 12/15/20 11:46 PM, Bert Vermeulen wrote:
> >> This driver supports the spiflash core in all RTL838x/RTL839x SoCs,
> >> and likely some older models as well (RTL8196C).
> >>
> > Can we use SPIMEM and move this under drivers/spi/ instead?
>
> I wasn't aware spimem was the thing to use for new drivers. I will rewrite
> the driver to that API.

Are there any limitations preventing this from being implemented as a
generic SPI controller?
spi-nor and spi-mem are designed for controllers which can only perform
spi-mem/spi-nor specific transfers. I can't find such limitations from
your current driver code.

BTW I found a SPI controller driver for RTL8196C here: [0]
It seems pretty similar to the controller you are working on.

[0]: 
https://github.com/hackpascal/lede-rtl8196c/blob/realtek/target/linux/realtek/files/drivers/spi/spi-realtek.c

-- 
Regards,
Chuanhong Guo

[PATCH] m68k: Enable seccomp architecture tracking

[Geert Uytterhoeven]

To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size.

Signed-off-by: Geert Uytterhoeven 
---
Needed for CONFIG_SECCOMP_CACHE_DEBUG.
Note that upstream doesn't have m68k seccomp support yet.

 arch/m68k/include/asm/Kbuild|  1 -
 arch/m68k/include/asm/seccomp.h | 11 +++
 2 files changed, 11 insertions(+), 1 deletion(-)
 create mode 100644 arch/m68k/include/asm/seccomp.h

diff --git a/arch/m68k/include/asm/Kbuild b/arch/m68k/include/asm/Kbuild
index d9f0f283707ff352..1bff55aa2d54e2ce 100644
--- a/arch/m68k/include/asm/Kbuild
+++ b/arch/m68k/include/asm/Kbuild
@@ -4,5 +4,4 @@ generic-y += extable.h
 generic-y += kvm_para.h
 generic-y += local64.h
 generic-y += mcs_spinlock.h
-generic-y += seccomp.h
 generic-y += spinlock.h
diff --git a/arch/m68k/include/asm/seccomp.h b/arch/m68k/include/asm/seccomp.h
new file mode 100644
index ..feefe511dd1f370d
--- /dev/null
+++ b/arch/m68k/include/asm/seccomp.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef _ASM_M68K_SECCOMP_H
+#define _ASM_M68K_SECCOMP_H
+
+#include 
+
+#define SECCOMP_ARCH_NATIVEAUDIT_ARCH_M68K
+#define SECCOMP_ARCH_NATIVE_NR NR_syscalls
+#define SECCOMP_ARCH_NATIVE_NAME   "m68k"
+
+#endif /* _ASM_M68K_SECCOMP_H */
-- 
2.25.1

Re: [RFC PATCH 0/13] sparc32: sunset sun4m and sun4d

[Julian Calaby]

Hi Romain, Sam,

On Sun, Dec 20, 2020 at 6:46 PM Romain Dolbeau  wrote:
>
> Le sam. 19 déc. 2020 à 22:41, Sam Ravnborg  a écrit :
> > Another said that it would be a shame to sunset sun4m and sun4d because
> > there are so many machines around, and netbsd is also active on the
> > sparc32 area.
>
> Yes, those were plentiful back in the day and there's still quite a few 
> around.

I have three: two SparcStation 10s and a SparcStation LX.

If I want to run them, assuming the hardware still works, I need to
netboot them as I cannot find working, compatible HDDs for them as
everything has switched to SATA or SAS.

Then there's the issue of finding a monitor as they're not
electrically compatible with VGA and I'm pretty sure none of the VGA
compatible monitors I have or can lay hands on works with their
specific sync frequencies.

Ultimately it's one of those things where there's enough "stuff" in
the way that booting one up for fun is simply impractical and they're
old and slow enough that they're not useful for anything else.

Then we get to the not-so-significant issue of software...

> > The second mail also re-reminded me of an interesting project
> > implementing SPARC V8 and the sun4m platform in VHDL.
>
> There's also new hardware being developed for SBus systems :-)
> 
> (disclaimer: work-in-progress and shameless self-promotion here!).

Interesting project!

Amusingly enough you're not the first to hook an FPGA up to sBus. I
had a card that was some form of high-speed sampling thing which was
effectively some electrically isolated front-end hooked to a Xylinx
FPGA. I ended up trashing it as it had no markings and I couldn't find
out anything about it.

> If there's still a distribution willing to build for Sparc v8, then I
> believe the kernel
> should try to keep support of the relevant machine architectures if at all
> possible...

And here's where the problem lies. The last (official) version of
Debian to support Sparc32 was Etch and I believe it was one of the
last ones to drop support.

I believe that Gentoo is architecture-neutral enough that it'd work,
but I believe that you'll have to compile everything - there'll be no
pre-built anything for sparc32 - and as it's fairly slow hardware by
today's standards, that's going to take a long time, however you could
probably use distcc and cross-compilers to speed it up.

Long painful story short, it's difficult to get the hardware running,
there's practically no Linux distros that support it, and the kernel
code has probably bitrotted due to lack of testing.

As much as it pains me to say this, I think this code's time has come
and it's time to get rid of it.

If there were more people using it or more testing, or more distros
supporting it - not just (theoretically?) working on it - then I'd be
fighting to keep it.

But there isn't.

I think it's time for it to go.

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

On Sun, Dec 20, 2020 at 6:46 PM Romain Dolbeau  wrote:
>
> Le sam. 19 déc. 2020 à 22:41, Sam Ravnborg  a écrit :
> > Another said that it would be a shame to sunset sun4m and sun4d because
> > there are so many machines around, and netbsd is also active on the
> > sparc32 area.
>
> Yes, those were plentiful back in the day and there's still quite a few 
> around.
>
> > The second mail also re-reminded me of an interesting project
> > implementing SPARC V8 and the sun4m platform in VHDL.
>
> There's also new hardware being developed for SBus systems :-)
> 
> (disclaimer: work-in-progress and shameless self-promotion here!).
>
> If there's still a distribution willing to build for Sparc v8, then I
> believe the kernel
> should try to keep support of the relevant machine architectures if at all
> possible...
>
> Cordially,
>
> --
> Romain Dolbeau



-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

[GIT PULL] KVM changes for Linux 5.11

[Paolo Bonzini]

Linus,

The following changes since commit 701f49065e68741a26752e6ae235c02bcafa2424:

  arm64: mark __system_matches_cap as __maybe_unused (2020-12-03 16:54:57 +)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus

for you to fetch changes up to d45f89f7437d0f2c8275b4434096164db106384d:

  KVM: SVM: fix 32-bit compilation (2020-12-16 13:08:21 -0500)


ARM:
* PSCI relay at EL2 when "protected KVM" is enabled
* New exception injection code
* Simplification of AArch32 system register handling
* Fix PMU accesses when no PMU is enabled
* Expose CSV3 on non-Meltdown hosts
* Cache hierarchy discovery fixes
* PV steal-time cleanups
* Allow function pointers at EL2
* Various host EL2 entry cleanups
* Simplification of the EL2 vector allocation

s390:
* memcg accouting for s390 specific parts of kvm and gmap
* selftest for diag318
* new kvm_stat for when async_pf falls back to sync

x86:
* Tracepoints for the new pagetable code from 5.10
* Catch VFIO and KVM irqfd events before userspace
* Reporting dirty pages to userspace with a ring buffer
* SEV-ES host support
* Nested VMX support for wait-for-SIPI activity state
* New feature flag (AVX512 FP16)
* New system ioctl to report Hyper-V-compatible paravirtualization features

Generic:
* Selftest improvements



Much x86 work was pushed out to 5.12, but ARM more than made up for it.

There is a very minor conflict in arch/x86/kvm/svm/svm.c, plus one in
arch/arm64/include/asm/kvm_asm.h because of a fix that was routed
through the arm64 tree.  The resolutions are at the end of this message.

Paolo


Aaron Lewis (2):
  selftests: kvm: Test MSR exiting to userspace
  selftests: kvm: Merge user_msr_test into userspace_msr_exit_test

Alex Shi (1):
  x86/kvm: remove unused macro HV_CLOCK_SIZE

Alexandru Elisei (1):
  KVM: arm64: Refuse to run VCPU if PMU is not initialized

Andrew Jones (7):
  KVM: selftests: Make vm_create_default common
  KVM: selftests: Introduce vm_create_[default_]_with_vcpus
  KVM: selftests: Also build dirty_log_perf_test on AArch64
  KVM: selftests: Make test skipping consistent
  KVM: selftests: x86: Set supported CPUIDs on default VM
  KVM: arm64: CSSELR_EL1 max is 13
  KVM: arm64: selftests: Filter out DEMUX registers

Ben Gardon (2):
  kvm: x86/mmu: Add existing trace points to TDP MMU
  kvm: x86/mmu: Add TDP MMU SPTE changed trace point

Cathy Avery (1):
  KVM: SVM: Move asid to vcpu_svm

Cathy Zhang (1):
  KVM: x86: Expose AVX512_FP16 for supported CPUID

Christian Borntraeger (3):
  KVM: s390: Add memcg accounting to KVM allocations
  s390/gmap: make gmap memcg aware
  KVM: s390: track synchronous pfault events in kvm_stat

Collin Walling (1):
  KVM: selftests: sync_regs test for diag318

David Brazdil (26):
  KVM: arm64: Add kvm-arm.mode early kernel parameter
  KVM: arm64: Add ARM64_KVM_PROTECTED_MODE CPU capability
  psci: Support psci_ops.get_version for v0.1
  psci: Split functions to v0.1 and v0.2+ variants
  psci: Replace psci_function_id array with a struct
  psci: Add accessor for psci_0_1_function_ids
  arm64: Make cpu_logical_map() take unsigned int
  arm64: Extract parts of el2_setup into a macro
  KVM: arm64: Remove vector_ptr param of hyp-init
  KVM: arm64: Move hyp-init params to a per-CPU struct
  KVM: arm64: Init MAIR/TCR_EL2 from params struct
  KVM: arm64: Add .hyp.data..ro_after_init ELF section
  KVM: arm64: Support per_cpu_ptr in nVHE hyp code
  KVM: arm64: Create nVHE copy of cpu_logical_map
  KVM: arm64: Add SMC handler in nVHE EL2
  KVM: arm64: Bootstrap PSCI SMC handler in nVHE EL2
  KVM: arm64: Add offset for hyp VA <-> PA conversion
  KVM: arm64: Forward safe PSCI SMCs coming from host
  KVM: arm64: Extract __do_hyp_init into a helper function
  KVM: arm64: Add function to enter host from KVM nVHE hyp code
  KVM: arm64: Intercept host's CPU_ON SMCs
  KVM: arm64: Intercept host's CPU_SUSPEND PSCI SMCs
  KVM: arm64: Intercept host's SYSTEM_SUSPEND PSCI SMCs
  KVM: arm64: Keep nVHE EL2 vector installed
  KVM: arm64: Trap host SMCs in protected mode
  KVM: arm64: Fix EL2 mode availability checks

David Woodhouse (5):
  sched/wait: Add add_wait_queue_priority()
  kvm/eventfd: Use priority waitqueue to catch events before userspace
  eventfd: Export eventfd_ctx_do_read()
  vfio/virqfd: Drain events from eventfd in virqfd_wakeup()
  kvm/eventfd: Drain events from eventfd in irqfd_wakeup()

Jim Mattson (1):
  kvm: x86: Sink cpuid update into vendor-specific set_cr4 functions

Keqian Zhu (2):
  KVM: arm64: Some fixes of PV-time interface document
  KVM: arm64: Use kvm_write_guest_lock when init stolen time

Kyung Min Park (1):
 

Re: [RFC PATCH 0/13] sparc32: sunset sun4m and sun4d

[Romain Dolbeau]

Le dim. 20 déc. 2020 à 09:54, Julian Calaby  a écrit :
> If I want to run them, assuming the hardware still works, I need to
> netboot them as I cannot find working, compatible HDDs for them as
> everything has switched to SATA or SAS.

SCSI2SD ()
are a bit expensive, but solve that problem (I own both a V5 and a V6,
both work well in my SPARCstations, tried sun4c and sun4m).
As it takes micro-sd cards, it's quite easy to keep multiple OSes
on hand.

> Then there's the issue of finding a monitor as they're not
> electrically compatible with VGA

Huh? There is Sun's 13W3-to-vga adapters and cables, and many
monitors will sync to Sun's frequency (though not the most recent
LCDs whose analog circuitry is pathetic compared to old-school
CRTs). Some framebuffers will output 1280x1024 (rarer than for
1152x900), and some can be coerced to do almost anything with
some Forth knowledge (see e.g.
, again blowing my
own horn here sorry...).

> (...) booting one up for fun is simply impractical

An SCSI2SD and either a null-modem serial cable or a
Sun keyboard/13w3 cable/17"LCD combo and you're good to
go. You might need another unix-like box to netboot the system.

> I believe that Gentoo is architecture-neutral enough that it'd work,
> but I believe that you'll have to compile everything - there'll be no
> pre-built anything for sparc32

Trying gentoo is on my todo list... has been for a long time :-(

> and as it's fairly slow hardware by
> today's standards, that's going to take a long time, however you could
> probably use distcc and cross-compilers to speed it up.

Isn't that what Qemu is for ? :-) I've managed to recompile LLVM
and clang in NetBSD 9 for my SS20, one by cross-compiling
(LLVM requires too much memory), the other in QEmu.
Unfortunately, Qemu doesn't yet support mt-tcg (multithreaded
emulation) for sparc so single-core only - still faster than the HW,
mostly because of incomparably faster I/O.

> If there were more people using it or more testing, or more distros
> supporting it - not just (theoretically?) working on it - then I'd be
> fighting to keep it.

I wish I had some arguments for that point... I will just re-mention Qemu,
as it makes testing quite easy and reasonably not-too-slow.

Cordially,

-- 
Romain Dolbeau

[PATCH v2 1/5] venus: vdec: Fix non reliable setting of LAST flag

[Stanimir Varbanov]

In real use of dynamic-resolution-change it is observed that the
LAST buffer flag (which marks the last decoded buffer with the
resolution before the resolution-change event) is not reliably set.

Fix this by set the LAST buffer flag on next queued capture buffer
after the resolution-change event.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/core.h|  5 +--
 drivers/media/platform/qcom/venus/helpers.c |  6 +++
 drivers/media/platform/qcom/venus/vdec.c| 45 -
 3 files changed, 33 insertions(+), 23 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/core.h 
b/drivers/media/platform/qcom/venus/core.h
index f03ed427accd..db0e6738281e 100644
--- a/drivers/media/platform/qcom/venus/core.h
+++ b/drivers/media/platform/qcom/venus/core.h
@@ -285,7 +285,6 @@ enum venus_dec_state {
VENUS_DEC_STATE_DRAIN   = 5,
VENUS_DEC_STATE_DECODING= 6,
VENUS_DEC_STATE_DRC = 7,
-   VENUS_DEC_STATE_DRC_FLUSH_DONE  = 8,
 };
 
 struct venus_ts_metadata {
@@ -350,7 +349,7 @@ struct venus_ts_metadata {
  * @priv:  a private for HFI operations callbacks
  * @session_type:  the type of the session (decoder or encoder)
  * @hprop: a union used as a holder by get property
- * @last_buf:  last capture buffer for dynamic-resoluton-change
+ * @next_buf_last: a flag to mark next queued capture buffer as last
  */
 struct venus_inst {
struct list_head list;
@@ -413,7 +412,7 @@ struct venus_inst {
union hfi_get_property hprop;
unsigned int core_acquired: 1;
unsigned int bit_depth;
-   struct vb2_buffer *last_buf;
+   bool next_buf_last;
 };
 
 #define IS_V1(core)((core)->res->hfi_version == HFI_VERSION_1XX)
diff --git a/drivers/media/platform/qcom/venus/helpers.c 
b/drivers/media/platform/qcom/venus/helpers.c
index 50439eb1ffea..5ca3920237c5 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -1347,6 +1347,12 @@ void venus_helper_vb2_buf_queue(struct vb2_buffer *vb)
 
v4l2_m2m_buf_queue(m2m_ctx, vbuf);
 
+   /* Skip processing queued capture buffers after LAST flag */
+   if (inst->session_type == VIDC_SESSION_TYPE_DEC &&
+   V4L2_TYPE_IS_CAPTURE(vb->vb2_queue->type) &&
+   inst->codec_state == VENUS_DEC_STATE_DRC)
+   goto unlock;
+
cache_payload(inst, vb);
 
if (inst->session_type == VIDC_SESSION_TYPE_ENC &&
diff --git a/drivers/media/platform/qcom/venus/vdec.c 
b/drivers/media/platform/qcom/venus/vdec.c
index 8488411204c3..eb94e167e282 100644
--- a/drivers/media/platform/qcom/venus/vdec.c
+++ b/drivers/media/platform/qcom/venus/vdec.c
@@ -917,10 +917,6 @@ static int vdec_start_capture(struct venus_inst *inst)
return 0;
 
 reconfigure:
-   ret = hfi_session_flush(inst, HFI_FLUSH_OUTPUT, true);
-   if (ret)
-   return ret;
-
ret = vdec_output_conf(inst);
if (ret)
return ret;
@@ -948,6 +944,8 @@ static int vdec_start_capture(struct venus_inst *inst)
 
venus_pm_load_scale(inst);
 
+   inst->next_buf_last = false;
+
ret = hfi_session_continue(inst);
if (ret)
goto free_dpb_bufs;
@@ -988,6 +986,7 @@ static int vdec_start_output(struct venus_inst *inst)
venus_helper_init_instance(inst);
inst->sequence_out = 0;
inst->reconfig = false;
+   inst->next_buf_last = false;
 
ret = vdec_set_properties(inst);
if (ret)
@@ -1081,9 +1080,7 @@ static int vdec_stop_capture(struct venus_inst *inst)
inst->codec_state = VENUS_DEC_STATE_STOPPED;
break;
case VENUS_DEC_STATE_DRC:
-   WARN_ON(1);
-   fallthrough;
-   case VENUS_DEC_STATE_DRC_FLUSH_DONE:
+   ret = hfi_session_flush(inst, HFI_FLUSH_OUTPUT, true);
inst->codec_state = VENUS_DEC_STATE_CAPTURE_SETUP;
venus_helper_free_dpb_bufs(inst);
break;
@@ -1207,9 +1204,28 @@ static void vdec_buf_cleanup(struct vb2_buffer *vb)
 static void vdec_vb2_buf_queue(struct vb2_buffer *vb)
 {
struct venus_inst *inst = vb2_get_drv_priv(vb->vb2_queue);
+   struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
+   static const struct v4l2_event eos = { .type = V4L2_EVENT_EOS };
 
vdec_pm_get_put(inst);
 
+   mutex_lock(&inst->lock);
+
+   if (inst->next_buf_last && V4L2_TYPE_IS_CAPTURE(vb->vb2_queue->type) &&
+   inst->codec_state == VENUS_DEC_STATE_DRC) {
+   vbuf->flags |= V4L2_BUF_FLAG_LAST;
+   vbuf->sequence = inst->sequence_cap++;
+   vbuf->field = V4L2_FIELD_NONE;
+   vb2_set_plane_payload(vb, 0, 0);
+   v4l2_m2m_buf_done(vbuf, VB2_BUF_STATE_DONE);
+   v4l2_event_queue_fh(&inst->fh, &eos);
+   inst->next_buf_last = false;
+   m

[PATCH v2 0/5] Venus dynamic resolution change fixes

[Stanimir Varbanov]

Hi,

Changes since v1:
 * In 1/5
   - clear next_buf_last flag before session_continue in vdec_start_capture
   - on event, flush output buffers unconditiannly
 * Added two more patches from Alex (4/5) and Fritz (5/5)

v1 can be found at: https://www.spinics.net/lists/linux-media/msg177801.html 

regards,
Stan

Alexandre Courbot (1):
  media: venus: preserve DRC state across seeks

Fritz Koenig (1):
  venus: vdec: Handle DRC after drain

Stanimir Varbanov (3):
  venus: vdec: Fix non reliable setting of LAST flag
  venus: vdec: Make decoder return LAST flag for sufficient event
  venus: helpers: Lock outside of buffer queue helper

 drivers/media/platform/qcom/venus/core.h|   6 +-
 drivers/media/platform/qcom/venus/helpers.c |  15 +--
 drivers/media/platform/qcom/venus/vdec.c| 110 +---
 drivers/media/platform/qcom/venus/venc.c|  11 +-
 4 files changed, 93 insertions(+), 49 deletions(-)

-- 
2.17.1

[PATCH v2 4/5] media: venus: preserve DRC state across seeks

[Stanimir Varbanov]

From: Alexandre Courbot 

DRC events can happen virtually at anytime, including when we are
starting a seek. Should this happen, we must make sure to return to the
DRC state, otherwise the firmware will expect buffers of the new
resolution whereas userspace will still work with the old one.

Returning to the DRC state upon resume for seeking makes sure that the
client will get the DRC event and will reallocate the buffers to fit the
firmware's expectations.

Signed-off-by: Alexandre Courbot 
Signed-off-by: Stanimir Varbanov 
---

No changes since v1.

 drivers/media/platform/qcom/venus/vdec.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/vdec.c 
b/drivers/media/platform/qcom/venus/vdec.c
index 9f2c7b3e7d4c..d27f4fd0ca01 100644
--- a/drivers/media/platform/qcom/venus/vdec.c
+++ b/drivers/media/platform/qcom/venus/vdec.c
@@ -987,7 +987,10 @@ static int vdec_start_output(struct venus_inst *inst)
 
if (inst->codec_state == VENUS_DEC_STATE_SEEK) {
ret = venus_helper_process_initial_out_bufs(inst);
-   inst->codec_state = VENUS_DEC_STATE_DECODING;
+   if (inst->next_buf_last)
+   inst->codec_state = VENUS_DEC_STATE_DRC;
+   else
+   inst->codec_state = VENUS_DEC_STATE_DECODING;
goto done;
}
 
@@ -1093,8 +1096,10 @@ static int vdec_stop_capture(struct venus_inst *inst)
ret = hfi_session_flush(inst, HFI_FLUSH_ALL, true);
fallthrough;
case VENUS_DEC_STATE_DRAIN:
-   vdec_cancel_dst_buffers(inst);
inst->codec_state = VENUS_DEC_STATE_STOPPED;
+   fallthrough;
+   case VENUS_DEC_STATE_SEEK:
+   vdec_cancel_dst_buffers(inst);
break;
case VENUS_DEC_STATE_DRC:
ret = hfi_session_flush(inst, HFI_FLUSH_OUTPUT, true);
@@ -1116,6 +1121,7 @@ static int vdec_stop_output(struct venus_inst *inst)
case VENUS_DEC_STATE_DECODING:
case VENUS_DEC_STATE_DRAIN:
case VENUS_DEC_STATE_STOPPED:
+   case VENUS_DEC_STATE_DRC:
ret = hfi_session_flush(inst, HFI_FLUSH_ALL, true);
inst->codec_state = VENUS_DEC_STATE_SEEK;
break;
@@ -1389,6 +1395,7 @@ static void vdec_event_change(struct venus_inst *inst,
dev_dbg(dev, VDBGH "flush output error %d\n", ret);
}
 
+   inst->next_buf_last = true;
inst->reconfig = true;
v4l2_event_queue_fh(&inst->fh, &ev);
wake_up(&inst->reconf_wait);
-- 
2.17.1

[PATCH v2 5/5] venus: vdec: Handle DRC after drain

[Stanimir Varbanov]

From: Fritz Koenig 

If the DRC is near the end of the stream the client
may send a V4L2_DEC_CMD_STOP before the DRC occurs.
V4L2_DEC_CMD_STOP puts the driver into the
VENUS_DEC_STATE_DRAIN state.  DRC must be aware so
that after the DRC event the state can be restored
correctly.

Signed-off-by: Fritz Koenig 
Signed-off-by: Stanimir Varbanov 
---

Changes since v2 (from Fritz):
 - moved state transition from vdec_event_notify to vdec_event_change. 

 drivers/media/platform/qcom/venus/core.h |  1 +
 drivers/media/platform/qcom/venus/vdec.c | 14 --
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/core.h 
b/drivers/media/platform/qcom/venus/core.h
index db0e6738281e..765ab7ed881b 100644
--- a/drivers/media/platform/qcom/venus/core.h
+++ b/drivers/media/platform/qcom/venus/core.h
@@ -413,6 +413,7 @@ struct venus_inst {
unsigned int core_acquired: 1;
unsigned int bit_depth;
bool next_buf_last;
+   bool drain_active;
 };
 
 #define IS_V1(core)((core)->res->hfi_version == HFI_VERSION_1XX)
diff --git a/drivers/media/platform/qcom/venus/vdec.c 
b/drivers/media/platform/qcom/venus/vdec.c
index d27f4fd0ca01..6cc35ffe2d6e 100644
--- a/drivers/media/platform/qcom/venus/vdec.c
+++ b/drivers/media/platform/qcom/venus/vdec.c
@@ -519,8 +519,10 @@ vdec_decoder_cmd(struct file *file, void *fh, struct 
v4l2_decoder_cmd *cmd)
 
ret = hfi_session_process_buf(inst, &fdata);
 
-   if (!ret && inst->codec_state == VENUS_DEC_STATE_DECODING)
+   if (!ret && inst->codec_state == VENUS_DEC_STATE_DECODING) {
inst->codec_state = VENUS_DEC_STATE_DRAIN;
+   inst->drain_active = true;
+   }
}
 
 unlock:
@@ -969,9 +971,13 @@ static int vdec_start_capture(struct venus_inst *inst)
 
inst->codec_state = VENUS_DEC_STATE_DECODING;
 
+   if (inst->drain_active)
+   inst->codec_state = VENUS_DEC_STATE_DRAIN;
+
inst->streamon_cap = 1;
inst->sequence_cap = 0;
inst->reconfig = false;
+   inst->drain_active = false;
 
return 0;
 
@@ -1097,6 +1103,7 @@ static int vdec_stop_capture(struct venus_inst *inst)
fallthrough;
case VENUS_DEC_STATE_DRAIN:
inst->codec_state = VENUS_DEC_STATE_STOPPED;
+   inst->drain_active = false;
fallthrough;
case VENUS_DEC_STATE_SEEK:
vdec_cancel_dst_buffers(inst);
@@ -1296,8 +1303,10 @@ static void vdec_buf_done(struct venus_inst *inst, 
unsigned int buf_type,
 
v4l2_event_queue_fh(&inst->fh, &ev);
 
-   if (inst->codec_state == VENUS_DEC_STATE_DRAIN)
+   if (inst->codec_state == VENUS_DEC_STATE_DRAIN) {
+   inst->drain_active = false;
inst->codec_state = VENUS_DEC_STATE_STOPPED;
+   }
}
 
if (!bytesused)
@@ -1373,6 +1382,7 @@ static void vdec_event_change(struct venus_inst *inst,
inst->codec_state = VENUS_DEC_STATE_CAPTURE_SETUP;
break;
case VENUS_DEC_STATE_DECODING:
+   case VENUS_DEC_STATE_DRAIN:
inst->codec_state = VENUS_DEC_STATE_DRC;
break;
default:
-- 
2.17.1

[PATCH v2 3/5] venus: helpers: Lock outside of buffer queue helper

[Stanimir Varbanov]

After adding more logic in vdec buf_queue vb2 op it is not
practical to have two lock/unlock for one decoder buf_queue.
So move the instance lock in encoder and decoder vb2 buf_queue
operations.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/helpers.c | 11 +++
 drivers/media/platform/qcom/venus/vdec.c|  3 +--
 drivers/media/platform/qcom/venus/venc.c| 11 ++-
 3 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/helpers.c 
b/drivers/media/platform/qcom/venus/helpers.c
index 5ca3920237c5..2b6925b6c274 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -1343,34 +1343,29 @@ void venus_helper_vb2_buf_queue(struct vb2_buffer *vb)
struct v4l2_m2m_ctx *m2m_ctx = inst->m2m_ctx;
int ret;
 
-   mutex_lock(&inst->lock);
-
v4l2_m2m_buf_queue(m2m_ctx, vbuf);
 
/* Skip processing queued capture buffers after LAST flag */
if (inst->session_type == VIDC_SESSION_TYPE_DEC &&
V4L2_TYPE_IS_CAPTURE(vb->vb2_queue->type) &&
inst->codec_state == VENUS_DEC_STATE_DRC)
-   goto unlock;
+   return;
 
cache_payload(inst, vb);
 
if (inst->session_type == VIDC_SESSION_TYPE_ENC &&
!(inst->streamon_out && inst->streamon_cap))
-   goto unlock;
+   return;
 
if (vb2_start_streaming_called(vb->vb2_queue)) {
ret = is_buf_refed(inst, vbuf);
if (ret)
-   goto unlock;
+   return;
 
ret = session_process_buf(inst, vbuf);
if (ret)
return_buf_error(inst, vbuf);
}
-
-unlock:
-   mutex_unlock(&inst->lock);
 }
 EXPORT_SYMBOL_GPL(venus_helper_vb2_buf_queue);
 
diff --git a/drivers/media/platform/qcom/venus/vdec.c 
b/drivers/media/platform/qcom/venus/vdec.c
index 4ce23c2fc6eb..9f2c7b3e7d4c 100644
--- a/drivers/media/platform/qcom/venus/vdec.c
+++ b/drivers/media/platform/qcom/venus/vdec.c
@@ -1241,9 +1241,8 @@ static void vdec_vb2_buf_queue(struct vb2_buffer *vb)
return;
}
 
-   mutex_unlock(&inst->lock);
-
venus_helper_vb2_buf_queue(vb);
+   mutex_unlock(&inst->lock);
 }
 
 static const struct vb2_ops vdec_vb2_ops = {
diff --git a/drivers/media/platform/qcom/venus/venc.c 
b/drivers/media/platform/qcom/venus/venc.c
index 1c61602c5de1..4ecf78e30b59 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -929,13 +929,22 @@ static int venc_start_streaming(struct vb2_queue *q, 
unsigned int count)
return ret;
 }
 
+static void venc_vb2_buf_queue(struct vb2_buffer *vb)
+{
+   struct venus_inst *inst = vb2_get_drv_priv(vb->vb2_queue);
+
+   mutex_lock(&inst->lock);
+   venus_helper_vb2_buf_queue(vb);
+   mutex_unlock(&inst->lock);
+}
+
 static const struct vb2_ops venc_vb2_ops = {
.queue_setup = venc_queue_setup,
.buf_init = venus_helper_vb2_buf_init,
.buf_prepare = venus_helper_vb2_buf_prepare,
.start_streaming = venc_start_streaming,
.stop_streaming = venus_helper_vb2_stop_streaming,
-   .buf_queue = venus_helper_vb2_buf_queue,
+   .buf_queue = venc_vb2_buf_queue,
 };
 
 static void venc_buf_done(struct venus_inst *inst, unsigned int buf_type,
-- 
2.17.1

[PATCH v2 2/5] venus: vdec: Make decoder return LAST flag for sufficient event

[Stanimir Varbanov]

This makes the decoder to behaives equally for sufficient and
insufficient events. After this change the LAST buffer flag will be set
when the new resolution (in dynamic-resolution-change state) is smaller
then the old bitstream resolution.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/vdec.c | 41 
 1 file changed, 27 insertions(+), 14 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/vdec.c 
b/drivers/media/platform/qcom/venus/vdec.c
index eb94e167e282..4ce23c2fc6eb 100644
--- a/drivers/media/platform/qcom/venus/vdec.c
+++ b/drivers/media/platform/qcom/venus/vdec.c
@@ -637,6 +637,7 @@ static int vdec_output_conf(struct venus_inst *inst)
 {
struct venus_core *core = inst->core;
struct hfi_enable en = { .enable = 1 };
+   struct hfi_buffer_requirements bufreq;
u32 width = inst->out_width;
u32 height = inst->out_height;
u32 out_fmt, out2_fmt;
@@ -712,6 +713,22 @@ static int vdec_output_conf(struct venus_inst *inst)
}
 
if (IS_V3(core) || IS_V4(core)) {
+   ret = venus_helper_get_bufreq(inst, HFI_BUFFER_OUTPUT, &bufreq);
+   if (ret)
+   return ret;
+
+   if (bufreq.size > inst->output_buf_size)
+   return -EINVAL;
+
+   if (inst->dpb_fmt) {
+   ret = venus_helper_get_bufreq(inst, HFI_BUFFER_OUTPUT2, 
&bufreq);
+   if (ret)
+   return ret;
+
+   if (bufreq.size > inst->output2_buf_size)
+   return -EINVAL;
+   }
+
if (inst->output2_buf_size) {
ret = venus_helper_set_bufsize(inst,
   inst->output2_buf_size,
@@ -1346,19 +1363,15 @@ static void vdec_event_change(struct venus_inst *inst,
dev_dbg(dev, VDBGM "event %s sufficient resources (%ux%u)\n",
sufficient ? "" : "not", ev_data->width, ev_data->height);
 
-   if (sufficient) {
-   hfi_session_continue(inst);
-   } else {
-   switch (inst->codec_state) {
-   case VENUS_DEC_STATE_INIT:
-   inst->codec_state = VENUS_DEC_STATE_CAPTURE_SETUP;
-   break;
-   case VENUS_DEC_STATE_DECODING:
-   inst->codec_state = VENUS_DEC_STATE_DRC;
-   break;
-   default:
-   break;
-   }
+   switch (inst->codec_state) {
+   case VENUS_DEC_STATE_INIT:
+   inst->codec_state = VENUS_DEC_STATE_CAPTURE_SETUP;
+   break;
+   case VENUS_DEC_STATE_DECODING:
+   inst->codec_state = VENUS_DEC_STATE_DRC;
+   break;
+   default:
+   break;
}
 
/*
@@ -1367,7 +1380,7 @@ static void vdec_event_change(struct venus_inst *inst,
 * itself doesn't mark the last decoder output buffer with HFI EOS flag.
 */
 
-   if (!sufficient && inst->codec_state == VENUS_DEC_STATE_DRC) {
+   if (inst->codec_state == VENUS_DEC_STATE_DRC) {
int ret;
 
inst->next_buf_last = true;
-- 
2.17.1

Re: INFO: rcu detected stall in tipc_release

[syzbot]

syzbot suspects this issue was fixed by commit:

commit cc00bcaa589914096edef7fb87ca5cee4a166b5c
Author: Subash Abhinov Kasiviswanathan 
Date:   Wed Nov 25 18:27:22 2020 +

netfilter: x_tables: Switch synchronization to RCU

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=1445cb3750
start commit:   7cc2a8ea Merge tag 'block-5.8-2020-07-01' of git://git.ker..
git tree:   upstream
kernel config:  https://syzkaller.appspot.com/x/.config?x=7be693511b29b338
dashboard link: https://syzkaller.appspot.com/bug?extid=3654c027d861c6df4b06
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1294823310
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=11344c0510

If the result looks correct, please mark the issue as fixed by replying with:

#syz fix: netfilter: x_tables: Switch synchronization to RCU

For information about bisection process see: https://goo.gl/tpsmEJ#bisection

[PATCH v5 4/6] staging: mt7621-dts: make use of new 'mt7621-clk'

[Sergio Paracuellos]

Clocks for SoC mt7621 have been properly integrated so there is
no need to declare fixed clocks at all in the device tree. Remove
all of them, add new device tree nodes for mt7621-clk and update
the rest of the nodes to use them.

Signed-off-by: Sergio Paracuellos 
---
 drivers/staging/mt7621-dts/gbpc1.dts   | 11 
 drivers/staging/mt7621-dts/mt7621.dtsi | 73 --
 2 files changed, 34 insertions(+), 50 deletions(-)

diff --git a/drivers/staging/mt7621-dts/gbpc1.dts 
b/drivers/staging/mt7621-dts/gbpc1.dts
index a7c0d3115d72..7716d0efe524 100644
--- a/drivers/staging/mt7621-dts/gbpc1.dts
+++ b/drivers/staging/mt7621-dts/gbpc1.dts
@@ -100,17 +100,6 @@ partition@5 {
};
 };
 
-&sysclock {
-   compatible = "fixed-clock";
-   /* This is normally 1/4 of cpuclock */
-   clock-frequency = <22500>;
-};
-
-&cpuclock {
-   compatible = "fixed-clock";
-   clock-frequency = <9>;
-};
-
 &pcie {
pinctrl-names = "default";
pinctrl-0 = <&pcie_pins>;
diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi 
b/drivers/staging/mt7621-dts/mt7621.dtsi
index 5b9d3bf82cb1..51d83cb3b4ee 100644
--- a/drivers/staging/mt7621-dts/mt7621.dtsi
+++ b/drivers/staging/mt7621-dts/mt7621.dtsi
@@ -1,5 +1,6 @@
 #include 
 #include 
+#include 
 
 / {
#address-cells = <1>;
@@ -27,27 +28,6 @@ aliases {
serial0 = &uartlite;
};
 
-   cpuclock: cpuclock@0 {
-   #clock-cells = <0>;
-   compatible = "fixed-clock";
-
-   /* FIXME: there should be way to detect this */
-   clock-frequency = <88000>;
-   };
-
-   sysclock: sysclock@0 {
-   #clock-cells = <0>;
-   compatible = "fixed-clock";
-
-   /* This is normally 1/4 of cpuclock */
-   clock-frequency = <22000>;
-   };
-
-   mmc_clock: mmc_clock@0 {
-   #clock-cells = <0>;
-   compatible = "fixed-clock";
-   clock-frequency = <4800>;
-   };
 
mmc_fixed_3v3: fixedregulator@0 {
compatible = "regulator-fixed";
@@ -80,6 +60,14 @@ sysc: sysc@0 {
reg = <0x0 0x100>;
};
 
+   pll: pll {
+   compatible = "mediatek,mt7621-clk";
+   #clock-cells = <1>;
+   clock-output-names = "xtal", "cpu", "bus",
+"50m", "125m", "150m",
+"250m", "270m";
+   };
+
wdt: wdt@100 {
compatible = "mtk,mt7621-wdt";
reg = <0x100 0x100>;
@@ -101,8 +89,8 @@ i2c: i2c@900 {
compatible = "mediatek,mt7621-i2c";
reg = <0x900 0x100>;
 
-   clocks = <&sysclock>;
-
+   clocks = <&pll MT7621_CLK_I2C>;
+   clock-names = "i2c";
resets = <&rstctrl 16>;
reset-names = "i2c";
 
@@ -119,8 +107,8 @@ i2s: i2s@a00 {
compatible = "mediatek,mt7621-i2s";
reg = <0xa00 0x100>;
 
-   clocks = <&sysclock>;
-
+   clocks = <&pll MT7621_CLK_I2S>;
+   clock-names = "i2s";
resets = <&rstctrl 17>;
reset-names = "i2s";
 
@@ -156,8 +144,8 @@ uartlite: uartlite@c00 {
compatible = "ns16550a";
reg = <0xc00 0x100>;
 
-   clocks = <&sysclock>;
-   clock-frequency = <5000>;
+   clocks = <&pll MT7621_CLK_UART1>;
+   clock-names = "uart1";
 
interrupt-parent = <&gic>;
interrupts = ;
@@ -173,7 +161,8 @@ spi0: spi@b00 {
compatible = "ralink,mt7621-spi";
reg = <0xb00 0x100>;
 
-   clocks = <&sysclock>;
+   clocks = <&pll MT7621_CLK_SPI>;
+   clock-names = "spi";
 
resets = <&rstctrl 18>;
reset-names = "spi";
@@ -189,6 +178,8 @@ gdma: gdma@2800 {
compatible = "ralink,rt3883-gdma";
reg = <0x2800 0x800>;
 
+   clocks = <&pll MT7621_CLK_GDMA>;
+   clock-names = "gdma";
resets = <&rstctrl 14>;
reset-names = "dma";
 
@@ -206,6 +197,8 @@ hsdma: hsdma@7000 {
compatible = "mediatek,mt7621-hsdma";
reg = <0x7000 0x1000>;
 
+   clocks = <&pll MT7621_CLK_HSDMA>;
+   clock-names = "hsdma";
 

[PATCH v5 0/6] MIPS: ralink: add CPU clock detection and clock driver for MT7621

[Sergio Paracuellos]

This patchset ports CPU clock detection for MT7621 from OpenWrt
and adds a complete clock plan for the mt7621 SOC.

The documentation for this SOC only talks about two registers
regarding to the clocks:
* SYSC_REG_CPLL_CLKCFG0 - provides some information about boostrapped
refclock. PLL and dividers used for CPU and some sort of BUS (AHB?).
* SYSC_REG_CPLL_CLKCFG1 - a banch of gates to enable/disable clocks for
all or some ip cores. 

No documentation about a probably existent set of dividers for each ip
core is included in the datasheets. So we cannot make anything better,
AFAICT.

Looking into driver code, and some openWRT patched there are
another frequences which are used in some drivers (uart, sd...).
According to all of this information the clock plan for this
SoC is set as follows:
 - Main top clock "xtal" from where all the rest of the world is
   derived.
 - CPU clock "cpu" derived from "xtal" frequencies and a bunch of
   register reads and predividers.
 - BUS clock "bus" derived from "cpu" and with (cpu / 4) MHz.
 - Fixed clocks from "xtal":
* "50m": 50 MHz.
* "125m": 125 MHz.
* "150m": 150 MHz.
* "250m": 250 MHz.
* "270m": 270 MHz.

We also have a buch of gate clocks with their parents:
 - "hsdma": "150m"
 - "fe": "250m"
 - "sp_divtx": "270m"
 - "timer": "50m"
 - "pcm": "270m"
 - "pio": "50m"
 - "gdma": "bus"
 - "nand": "125m"
 - "i2c": "50m"
 - "i2s": "270m"
 - "spi": "bus"
 - "uart1": "50m"
 - "uart2": "50m"
 - "uart3": "50m"
 - "eth": "50m"
 - "pcie0": "125m"
 - "pcie1": "125m"
 - "pcie2": "125m"
 - "crypto": "250m"
 - "shxc": "50m"

There was a previous attempt of doing this here[0] but the author
(Chuanhong Guo) did not wanted to make assumptions of a clock plan
for the platform that time. It seems that now he has a better idea of
how the clocks are dispossed for this SoC so he share code[1] where
some frequencies and clock parents for the gates are coded from a
real mediatek private clock plan.

I do really want this to be upstreamed so according to the comments
in previous attempt[0] from Oleksij Rempel and the frequencies in
code[1] I have tried to do this by myself.

All of this patches have been tested in a GNUBee PC1 resulting in a
working platform.

Changes in v5:
 - Avoid the use of syscon. All drivers of this platform are just using
   platform operations defined in 'asm/mach-ralink/ralink_regs.h'. We also
   need them for some PLL registers that are not in the sys control area.
   Hence, since we must use this dependency avoid to define clock driver
   as a child of the sysc node in the device tree and follow current
   platform code style.
 - Update bindings documentation to don't refer the syscon and make
   remove 'clock-output-names' property from required ones.
 - Use 'asm/mach-ralink/ralink_regs.h' platform read and write operations
   instead of regmap from the syscon node.
 - Remove 'mt7621_clk_provider' and directly declare 'clk_hw_onecell_data'
   pointer in 'mt7621_clk_init' and pass from there into different register
   functions. Remove pointers to 'mt7621_clk_provider' in the rest fo structs
   used in this driver.
 - Remove MHZ macro and just pass values directly in hertzs.
 - Avoid 'CLK_IGNORE_UNUSED' flag for gates and add a new function called
   'mt7621_prepare_enable_clocks' to prepare all of them to make clocks
   referenced and don't affect current driver code.
 - Remove COMPILE_TEST from Kconfig because of the use of especific arch
   stuff.
 - Fix commit message where a typo for "frequencies" word was present.
 - Make use of parent_clk_data in 'CLK_BASE' macro.
 - Remove MODULE_* macros from code since this is not a module.
 - Remove not needed includes.
 - Hardcode "xtal" as parent in FIXED macro.
 - Change 'else if' clause into 'if' clause since a return statement was
   being used in 'mt7621_xtal_recalc_rate'.

 NOTES:
   - Driver is still being declared using 'CLK_OF_DECLARE' for all the  
 clocks. I have explored the possibility to make some of them available
 afterwards using 'CLK_OF_DECLARE_DRIVER' for top clocks and the rest
 using a platform driver. The resulting code was uglier since we only want
 to use the same device tree node and the top clocks must be copied again
 for the new platform register stuff to properly have a good hierarchy.
 New globals needs to be introduced and in this particular case I don't
 really see the benefits of doing in this way. I am totally ok to have all
 the clocks registered at early stage since from other drivers perspective
 we only really need to enable gates. So, I prefer to have them in that
 way if it is not a real problem, of course.

Changes in v4:
 - Add Acked-by from Rob Herring for binding headers (PATCH 1/6).
 - Convert bindings to not use syscon phandle and declare clock as
   a child of the syscon node. Update device tree and binding doc
   accordly.
 - Make use of 'syscon_node_to_regmap' in driv

[PATCH v5 3/6] clk: ralink: add clock driver for mt7621 SoC

[Sergio Paracuellos]

The documentation for this SOC only talks about two
registers regarding to the clocks:
* SYSC_REG_CPLL_CLKCFG0 - provides some information about
boostrapped refclock. PLL and dividers used for CPU and some
sort of BUS.
* SYSC_REG_CPLL_CLKCFG1 - a banch of gates to enable/disable
clocks for all or some ip cores.

Looking into driver code, and some openWRT patched there are
another frequencies which are used in some drivers (uart, sd...).
According to all of this information the clock plan for this
SoC is set as follows:
- Main top clock "xtal" from where all the rest of the world is
derived.
- CPU clock "cpu" derived from "xtal" frequencies and a bunch of
register reads and predividers.
- BUS clock "bus" derived from "cpu" and with (cpu / 4) MHz.
- Fixed clocks from "xtal":
* "50m": 50 MHz.
* "125m": 125 MHz.
* "150m": 150 MHz.
* "250m": 250 MHz.
* "270m": 270 MHz.

We also have a buch of gate clocks with their parents:
  * "hsdma": "150m"
  * "fe": "250m"
  * "sp_divtx": "270m"
  * "timer": "50m"
  * "pcm": "270m"
  * "pio": "50m"
  * "gdma": "bus"
  * "nand": "125m"
  * "i2c": "50m"
  * "i2s": "270m"
  * "spi": "bus"
  * "uart1": "50m"
  * "uart2": "50m"
  * "uart3": "50m"
  * "eth": "50m"
  * "pcie0": "125m"
  * "pcie1": "125m"
  * "pcie2": "125m"
  * "crypto": "250m"
  * "shxc": "50m"

With this information the clk driver will provide clock and gates
functionality from a a set of hardcoded clocks allowing to define
a nice device tree without fixed clocks.

Signed-off-by: Sergio Paracuellos 
---
 drivers/clk/Kconfig |   1 +
 drivers/clk/Makefile|   1 +
 drivers/clk/ralink/Kconfig  |  14 ++
 drivers/clk/ralink/Makefile |   2 +
 drivers/clk/ralink/clk-mt7621.c | 411 
 5 files changed, 429 insertions(+)
 create mode 100644 drivers/clk/ralink/Kconfig
 create mode 100644 drivers/clk/ralink/Makefile
 create mode 100644 drivers/clk/ralink/clk-mt7621.c

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 85856cff506c..7c6ad73c985c 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -381,6 +381,7 @@ source "drivers/clk/mediatek/Kconfig"
 source "drivers/clk/meson/Kconfig"
 source "drivers/clk/mvebu/Kconfig"
 source "drivers/clk/qcom/Kconfig"
+source "drivers/clk/ralink/Kconfig"
 source "drivers/clk/renesas/Kconfig"
 source "drivers/clk/rockchip/Kconfig"
 source "drivers/clk/samsung/Kconfig"
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index dbdc590e7de3..29b957d83c4e 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -101,6 +101,7 @@ obj-$(CONFIG_COMMON_CLK_NXP)+= nxp/
 obj-$(CONFIG_MACH_PISTACHIO)   += pistachio/
 obj-$(CONFIG_COMMON_CLK_PXA)   += pxa/
 obj-$(CONFIG_COMMON_CLK_QCOM)  += qcom/
+obj-y  += ralink/
 obj-y  += renesas/
 obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/
 obj-$(CONFIG_COMMON_CLK_SAMSUNG)   += samsung/
diff --git a/drivers/clk/ralink/Kconfig b/drivers/clk/ralink/Kconfig
new file mode 100644
index ..f1de548ed781
--- /dev/null
+++ b/drivers/clk/ralink/Kconfig
@@ -0,0 +1,14 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# MediaTek Mt7621 Clock Driver
+#
+menu "Clock driver for Mediatek mt7621 SoC"
+   depends on SOC_MT7621
+
+config CLK_MT7621
+   bool "Clock driver for MediaTek MT7621"
+   depends on SOC_MT7621
+   default SOC_MT7621
+   help
+ This driver supports MediaTek MT7621 basic clocks.
+endmenu
diff --git a/drivers/clk/ralink/Makefile b/drivers/clk/ralink/Makefile
new file mode 100644
index ..cf6f9216379d
--- /dev/null
+++ b/drivers/clk/ralink/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_CLK_MT7621) += clk-mt7621.o
diff --git a/drivers/clk/ralink/clk-mt7621.c b/drivers/clk/ralink/clk-mt7621.c
new file mode 100644
index ..52aa98318abf
--- /dev/null
+++ b/drivers/clk/ralink/clk-mt7621.c
@@ -0,0 +1,411 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Mediatek MT7621 Clock Driver
+ * Author: Sergio Paracuellos 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Configuration registers */
+#define SYSC_REG_SYSTEM_CONFIG0 0x10
+#define SYSC_REG_SYSTEM_CONFIG1 0x14
+#define SYSC_REG_CLKCFG0   0x2c
+#define SYSC_REG_CLKCFG1   0x30
+#define SYSC_REG_CUR_CLK_STS   0x44
+
+#define MEMC_REG_CPU_PLL   0x648
+#define XTAL_MODE_SEL_MASK 0x7
+#define XTAL_MODE_SEL_SHIFT6
+
+#define CPU_CLK_SEL_MASK   0x3
+#define CPU_CLK_SEL_SHIFT  30
+
+#define CUR_CPU_FDIV_MASK  0x1f
+#define CUR_CPU_FDIV_SHIFT 8
+#define CUR_CPU_FFRAC_MASK 0x1f
+#define CUR_CPU_FFRAC_SHIFT0
+
+#define CPU_PLL_PREDIV_MASK0x3
+#define CPU_PLL_PREDIV_SHIFT   12
+#define CPU_PLL_FBDIV_MASK 0x

[PATCH v5 2/6] dt: bindings: add mt7621-clk device tree binding documentation

[Sergio Paracuellos]

Adds device tree binding documentation for clocks in the
MT7621 SOC.

Signed-off-by: Sergio Paracuellos 
---
 .../bindings/clock/mediatek,mt7621-clk.yaml   | 52 +++
 1 file changed, 52 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml

diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml 
b/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
new file mode 100644
index ..f58d01bdc82c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/mediatek,mt7621-clk.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MT7621 Clock Device Tree Bindings
+
+maintainers:
+  - Sergio Paracuellos 
+
+description: |
+  The MT7621 has a PLL controller from where the cpu clock is provided
+  as well as derived clocks for the bus and the peripherals. It also
+  can gate SoC device clocks.
+
+  Each clock is assigned an identifier and client nodes use this identifier
+  to specify the clock which they consume.
+
+  All these identifiers could be found in:
+  [1]: .
+
+properties:
+  compatible:
+const: mediatek,mt7621-clk
+
+  "#clock-cells":
+description:
+  The first cell indicates the clock number, see [1] for available
+  clocks.
+const: 1
+
+  clock-output-names:
+maxItems: 8
+
+required:
+  - compatible
+  - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+
+pll {
+  compatible = "mediatek,mt7621-clk";
+  #clock-cells = <1>;
+  clock-output-names = "xtal", "cpu", "bus",
+   "50m", "125m", "150m",
+   "250m", "270m";
+};
-- 
2.25.1

[PATCH v5 6/6] MAINTAINERS: add MT7621 CLOCK maintainer

[Sergio Paracuellos]

Adding myself as maintainer for mt7621 clock driver.

Signed-off-by: Sergio Paracuellos 
---
 MAINTAINERS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f5eafee83bc6..f0c51d9760ec 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11247,6 +11247,12 @@ L: linux-wirel...@vger.kernel.org
 S: Maintained
 F: drivers/net/wireless/mediatek/mt7601u/
 
+MEDIATEK MT7621 CLOCK DRIVER
+M: Sergio Paracuellos 
+S: Maintained
+F: Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
+F: drivers/clk/ralink/clk-mt7621.c
+
 MEDIATEK MT7621/28/88 I2C DRIVER
 M: Stefan Roese 
 L: linux-...@vger.kernel.org
-- 
2.25.1

[PATCH v5 5/6] staging: mt7621-dts: use valid vendor 'mediatek' instead of invalid 'mtk'

[Sergio Paracuellos]

Vendor listed for mediatek in kernel vendor file 'vendor-prefixes.yaml'
contains 'mediatek' as a valid vendor string. Some nodes in the device
tree are using an invalid vendor string vfor 'mtk' instead. Fix all of
them in dts file. Update also ralink mt7621 related code to properly
match new strings. Even there are used in the device tree there are
some strings that are not referred anywhere but have been also updated
with new vendor name. These are 'mtk,mt7621-wdt', 'mtk,mt7621-nand',
'mtk,mt7621-mc', and 'mtk,mt7621-cpc'.

Signed-off-by: Sergio Paracuellos 
---
 arch/mips/ralink/mt7621.c  |  6 +++---
 drivers/staging/mt7621-dts/mt7621.dtsi | 12 ++--
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/mips/ralink/mt7621.c b/arch/mips/ralink/mt7621.c
index ca0ac607b0f3..5d74fc1c96ac 100644
--- a/arch/mips/ralink/mt7621.c
+++ b/arch/mips/ralink/mt7621.c
@@ -112,8 +112,8 @@ phys_addr_t mips_cpc_default_phys_base(void)
 
 void __init ralink_of_remap(void)
 {
-   rt_sysc_membase = plat_of_remap_node("mtk,mt7621-sysc");
-   rt_memc_membase = plat_of_remap_node("mtk,mt7621-memc");
+   rt_sysc_membase = plat_of_remap_node("mediatek,mt7621-sysc");
+   rt_memc_membase = plat_of_remap_node("mediatek,mt7621-memc");
 
if (!rt_sysc_membase || !rt_memc_membase)
panic("Failed to remap core resources");
@@ -181,7 +181,7 @@ void prom_soc_init(struct ralink_soc_info *soc_info)
 
if (n0 == MT7621_CHIP_NAME0 && n1 == MT7621_CHIP_NAME1) {
name = "MT7621";
-   soc_info->compatible = "mtk,mt7621-soc";
+   soc_info->compatible = "mediatek,mt7621-soc";
} else {
panic("mt7621: unknown SoC, n0:%08x n1:%08x\n", n0, n1);
}
diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi 
b/drivers/staging/mt7621-dts/mt7621.dtsi
index 51d83cb3b4ee..ba113e5ced51 100644
--- a/drivers/staging/mt7621-dts/mt7621.dtsi
+++ b/drivers/staging/mt7621-dts/mt7621.dtsi
@@ -56,7 +56,7 @@ palmbus: palmbus@1E00 {
#size-cells = <1>;
 
sysc: sysc@0 {
-   compatible = "mtk,mt7621-sysc";
+   compatible = "mediatek,mt7621-sysc";
reg = <0x0 0x100>;
};
 
@@ -69,7 +69,7 @@ pll: pll {
};
 
wdt: wdt@100 {
-   compatible = "mtk,mt7621-wdt";
+   compatible = "mediatek,mt7621-wdt";
reg = <0x100 0x100>;
};
 
@@ -126,17 +126,17 @@ i2s: i2s@a00 {
};
 
memc: memc@5000 {
-   compatible = "mtk,mt7621-memc";
+   compatible = "mediatek,mt7621-memc";
reg = <0x5000 0x1000>;
};
 
cpc: cpc@1fbf {
-compatible = "mtk,mt7621-cpc";
+compatible = "mediatek,mt7621-cpc";
 reg = <0x1fbf 0x8000>;
};
 
mc: mc@1fbf8000 {
-   compatible = "mtk,mt7621-mc";
+   compatible = "mediatek,mt7621-mc";
reg = <0x1fbf8000 0x8000>;
};
 
@@ -369,7 +369,7 @@ timer {
nand: nand@1e003000 {
status = "disabled";
 
-   compatible = "mtk,mt7621-nand";
+   compatible = "mediatek,mt7621-nand";
bank-width = <2>;
reg = <0x1e003000 0x800
0x1e003800 0x800>;
-- 
2.25.1

[PATCH v5 1/6] dt-bindings: clock: add dt binding header for mt7621 clocks

[Sergio Paracuellos]

Adds dt binding header for 'mediatek,mt7621-clk' clocks.

Acked-by: Rob Herring 
Signed-off-by: Sergio Paracuellos 
---
 include/dt-bindings/clock/mt7621-clk.h | 41 ++
 1 file changed, 41 insertions(+)
 create mode 100644 include/dt-bindings/clock/mt7621-clk.h

diff --git a/include/dt-bindings/clock/mt7621-clk.h 
b/include/dt-bindings/clock/mt7621-clk.h
new file mode 100644
index ..1422badcf9de
--- /dev/null
+++ b/include/dt-bindings/clock/mt7621-clk.h
@@ -0,0 +1,41 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Author: Sergio Paracuellos 
+ */
+
+#ifndef _DT_BINDINGS_CLK_MT7621_H
+#define _DT_BINDINGS_CLK_MT7621_H
+
+#define MT7621_CLK_XTAL0
+#define MT7621_CLK_CPU 1
+#define MT7621_CLK_BUS 2
+#define MT7621_CLK_50M 3
+#define MT7621_CLK_125M4
+#define MT7621_CLK_150M5
+#define MT7621_CLK_250M6
+#define MT7621_CLK_270M7
+
+#define MT7621_CLK_HSDMA   8
+#define MT7621_CLK_FE  9
+#define MT7621_CLK_SP_DIVTX10
+#define MT7621_CLK_TIMER   11
+#define MT7621_CLK_PCM 12
+#define MT7621_CLK_PIO 13
+#define MT7621_CLK_GDMA14
+#define MT7621_CLK_NAND15
+#define MT7621_CLK_I2C 16
+#define MT7621_CLK_I2S 17
+#define MT7621_CLK_SPI 18
+#define MT7621_CLK_UART1   19
+#define MT7621_CLK_UART2   20
+#define MT7621_CLK_UART3   21
+#define MT7621_CLK_ETH 22
+#define MT7621_CLK_PCIE0   23
+#define MT7621_CLK_PCIE1   24
+#define MT7621_CLK_PCIE2   25
+#define MT7621_CLK_CRYPTO  26
+#define MT7621_CLK_SHXC27
+
+#define MT7621_CLK_MAX 28
+
+#endif /* _DT_BINDINGS_CLK_MT7621_H */
-- 
2.25.1

Re: [PATCH v1 0/4] s390/kvm: fix MVPG when in VSIE

[David Hildenbrand]

On 18.12.20 15:18, Claudio Imbrenda wrote:
> The current handling of the MVPG instruction when executed in a nested
> guest is wrong, and can lead to the nested guest hanging.

Hi,

thanks for spotting and debugging! Is this related to nested guests
hanging while migrating (mentioned by Janosch at some point)?

Or can this not be reproduced with actual Linux guests?

Thanks!

> 
> This patchset fixes the behaviour to be more architecturally correct,
> and fixes the hangs observed.
> 
> Claudio Imbrenda (4):
>   s390/kvm: VSIE: stop leaking host addresses
>   s390/kvm: extend guest_translate for MVPG interpretation
>   s390/kvm: add kvm_s390_vsie_mvpg_check needed for VSIE MVPG
>   s390/kvm: VSIE: correctly handle MVPG when in VSIE
> 
>  arch/s390/kvm/gaccess.c | 88 ++---
>  arch/s390/kvm/gaccess.h |  3 ++
>  arch/s390/kvm/vsie.c| 78 +---
>  3 files changed, 159 insertions(+), 10 deletions(-)
> 


-- 
Thanks,

David / dhildenb

Re: [PATCH v1 1/4] s390/kvm: VSIE: stop leaking host addresses

[David Hildenbrand]

On 18.12.20 15:18, Claudio Imbrenda wrote:
> The addresses in the SIE control block of the host should not be
> forwarded to the guest. They are only meaningful to the host, and
> moreover it would be a clear security issue.

It's really almost impossible for someone without access to
documentation to understand what we leak. I assume we're leaking the g1
address of a page table (entry), used for translation of g2->g3 to g1.
Can you try making that clearer?

In that case, it's pretty much a random number (of a random page used as
a leave page table) and does not let g1 identify locations of symbols
etc. If so, I don't think this is a "clear security issue" and suggest
squashing this into the actual fix (#p4 I assume).

@Christian, @Janosch? Am I missing something?

> 
> Subsequent patches will actually put the right values in the guest SIE
> control block.
> 
> Fixes: a3508fbe9dc6d ("KVM: s390: vsie: initial support for nested 
> virtualization")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Claudio Imbrenda 
> ---
>  arch/s390/kvm/vsie.c | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/arch/s390/kvm/vsie.c b/arch/s390/kvm/vsie.c
> index 4f3cbf6003a9..ada49583e530 100644
> --- a/arch/s390/kvm/vsie.c
> +++ b/arch/s390/kvm/vsie.c
> @@ -416,11 +416,6 @@ static void unshadow_scb(struct kvm_vcpu *vcpu, struct 
> vsie_page *vsie_page)
>   memcpy((void *)((u64)scb_o + 0xc0),
>  (void *)((u64)scb_s + 0xc0), 0xf0 - 0xc0);
>   break;
> - case ICPT_PARTEXEC:
> - /* MVPG only */
> - memcpy((void *)((u64)scb_o + 0xc0),
> -(void *)((u64)scb_s + 0xc0), 0xd0 - 0xc0);
> - break;
>   }
>  
>   if (scb_s->ihcpu != 0xU)
> 


-- 
Thanks,

David / dhildenb

Re: [RFC PATCH] badblocks: Improvement badblocks_set() for handling multiple ranges

[Coly Li]

On 12/20/20 4:02 AM, antlists wrote:
> On 03/12/2020 17:15, Coly Li wrote:
>> This patch is an initial effort to improve badblocks_set() for setting
>> bad blocks range when it covers multiple already set bad ranges in the
>> bad blocks table, and to do it as fast as possible.
> 
> Is this your patch, or submitted as part of the bug report?

This is not finished yet. The final version should go into upstream as a
fix for current badblocks routines.

> 
> "Heavily based on MD badblocks code from Neil Brown"
> 
> How much has this code got to do with the mdraid subsystem? Because
> badblocks in mdraid has an appalling reputation, with many people
> wanting to just rip it out.

This is in-memory data structure management which is almost irrelevant
to md raid or other on-disk layout.


> 
> If this code is separate from the mdraid implementation, any chance you
> can work with it, and fix that at the same time? Or make it redundant! I

This is 100% separated from md raid, as well as current badblocks code,
it is just about combine or split some [start, length] extent in a
table. The purpose of this patch is to fixing some reported issue from
users and our customers.

> don't quite see why mdraid should need a badblocks list given modern
> disk drives.
> 

For me the motivation is just people report bugs and I fix it. If there
is new code to replace it in upstream, then I just continue to maintain
the new code for our users and customers.

> And it's on my to-do list (if I can find the time!!!) to integrate
> dm-integrity into mdraid, at which point md badblocks should be irrelevant.
> 
> Hope I'm not being a shower of cold water, and if you want to fix all
> this, good on you, but to the extent that this is relevant to
> linux-raid, I think a lot of people will be asking "What's the point?"

Currently blocks/badblocks.c is used by md raid and nvdimm code, and the
badblocks table is irrelevant to any of these two subsystems.

If there will be better code for similar or better functionality, it
should be cool. For me, if the reporting bug is fixed, no difference in
my view :-)

Thanks.

Coly Li

Re: [RFC PATCH] badblocks: Improvement badblocks_set() for handling multiple ranges

[Coly Li]

On 12/18/20 11:25 AM, Dan Williams wrote:
> [ add Neil, original gooodguy who wrote badblocks ]
> 
> 
> On Thu, Dec 3, 2020 at 9:16 AM Coly Li  wrote:
>>
>> Recently I received a bug report that current badblocks code does not
>> properly handle multiple ranges. For example,
>> badblocks_set(bb, 32, 1, true);
>> badblocks_set(bb, 34, 1, true);
>> badblocks_set(bb, 36, 1, true);
>> badblocks_set(bb, 32, 12, true);
>> Then indeed badblocks_show() reports,
>> 32 3
>> 36 1
>> But the expected bad blocks table should be,
>> 32 12
>> Obviously only the first 2 ranges are merged and badblocks_set() returns
>> and ignores the rest setting range.
>>
>> This behavior is improper, if the caller of badblocks_set() wants to set
>> a range of blocks into bad blocks table, all of the blocks in the range
>> should be handled even the previous part encountering failure.
>>
>> The desired way to set bad blocks range by badblocks_set() is,
>> - Set as many as blocks in the setting range into bad blocks table.
>> - Merge the bad blocks ranges and occupy as less as slots in the bad
>>   blocks table.
>> - Fast.
>>
>> Indeed the above proposal is complicated, especially with the following
>> restrictions,
>> - The setting bad blocks range can be ackknowledged or not acknowledged.


Hi Dan,

> 
> s/ackknowledged/acknowledged/
> 
> I'd run checkpatch --codespell for future versions...

Thanks for the hint. I will do it next time.


> 
>> - The bad blocks table size is limited.
>> - Memory allocation should be avoided.
>>
>> This patch is an initial effort to improve badblocks_set() for setting
>> bad blocks range when it covers multiple already set bad ranges in the
>> bad blocks table, and to do it as fast as possible.
>>
>> The basic idea of the patch is to categorize all possible bad blocks
>> range setting combinationsinto to much less simplified and more less
>> special conditions. Inside badblocks_set() there is an implicit loop
>> composed by jumping between labels 're_insert' and 'update_sectors'. No
>> matter how large the setting bad blocks range is, in every loop just a
>> minimized range from the head is handled by a pre-defined behavior from
>> one of the categorized conditions. The logic is simple and code flow is
>> manageable.
>>
>> This patch is unfinished yet, it only improves badblocks_set() and not
>> touch badblocks_clear() and badblocks_show() yet. I post it earlier
>> because this patch will be large (more then 1000 lines of change), I
>> want more people to give me comments earlier before I go too far away.
>>
> 
> I wonder if this isn't indication that the base data structure should
> be replaced... but I have not had a chance to devote deeper thought to
> this.
> 

No existing data structure changed. Even the in-memory badblocks table I
don't change it at all. I just fix the report issue by handle more
corner cases, on-disk and in-memory stuffs are untouched and consistent.


Coly Li

> 
>> The code logic is tested as user space programmer, this patch passes
>> compiling but not tested in kernel mode yet. Right now it is only for
>> RFC purpose. I will post tested patch in further versions.
>>
>> Thank you in advance for any review or comments on this patch.
>>

[snipped]

[PATCH] MAINTAINERS: mark dca driver orphan

[Lukas Bulwahn]

The dca driver did not have any maintainer section since its inclusion.
As discussed with Dan Williams, there is no maintainer for this driver
since the initial developers moved away.

Introduce a new DIRECT CACHE ACCESS (DCA) DRIVER section and mark the
driver orphan.

Signed-off-by: Lukas Bulwahn 
---
applies cleanly on next-20201218 and current master

Dan, please pick this trivial clarification patch.

 MAINTAINERS | 5 +
 1 file changed, 5 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f5eafee83bc6..c8cc5e1a759f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5223,6 +5223,11 @@ L:   linux-...@vger.kernel.org
 S: Maintained
 F: drivers/i2c/busses/i2c-diolan-u2c.c
 
+DIRECT CACHE ACCESS (DCA) DRIVER
+S: Orphan
+F: drivers/dca/
+F: include/linux/dca.h
+
 DIRECTORY NOTIFICATION (DNOTIFY)
 M: Jan Kara 
 R: Amir Goldstein 
-- 
2.17.1

Re: [RFC PATCH 0/13] sparc32: sunset sun4m and sun4d

[Julian Calaby]

Hi Romain,

On Sun, Dec 20, 2020 at 8:26 PM Romain Dolbeau  wrote:
>
> Le dim. 20 déc. 2020 à 09:54, Julian Calaby  a écrit 
> :
> > If I want to run them, assuming the hardware still works, I need to
> > netboot them as I cannot find working, compatible HDDs for them as
> > everything has switched to SATA or SAS.
>
> SCSI2SD ()
> are a bit expensive, but solve that problem (I own both a V5 and a V6,
> both work well in my SPARCstations, tried sun4c and sun4m).
> As it takes micro-sd cards, it's quite easy to keep multiple OSes
> on hand.

I'd forgotten about that. Fair point =)

> > Then there's the issue of finding a monitor as they're not
> > electrically compatible with VGA
>
> Huh? There is Sun's 13W3-to-vga adapters and cables, and many
> monitors will sync to Sun's frequency (though not the most recent
> LCDs whose analog circuitry is pathetic compared to old-school
> CRTs). Some framebuffers will output 1280x1024 (rarer than for
> 1152x900), and some can be coerced to do almost anything with
> some Forth knowledge (see e.g.
> , again blowing my
> own horn here sorry...).

Yeah, my issue is that I have no CRTs anymore - all my monitors are
LCDs and none of them sync to the frequencies SUNs use.

So yeah, you can make adapters (i have home-made adapters to convert
both ways) however out of the 4 monitors I own with VGA ports, none of
them sync to Sun frequencies.

> > (...) booting one up for fun is simply impractical
>
> An SCSI2SD and either a null-modem serial cable or a
> Sun keyboard/13w3 cable/17"LCD combo and you're good to
> go. You might need another unix-like box to netboot the system.

That's almost exactly what I was planning to do, but I'd still be
lacking a Linux distro to run.

> > I believe that Gentoo is architecture-neutral enough that it'd work,
> > but I believe that you'll have to compile everything - there'll be no
> > pre-built anything for sparc32
>
> Trying gentoo is on my todo list... has been for a long time :-(

Same.

IIRC there's some ancient versions that have the bits to netboot a
SparcStation so you can then do the necessary stuff to install the
minimal binaries and stuff, at which point you can do the various
configurations, pull in the latest portage tree and emerge world,
however the last time I tried this, the disk I was using - my last one
- failed somewhere in the middle of that process.

> > and as it's fairly slow hardware by
> > today's standards, that's going to take a long time, however you could
> > probably use distcc and cross-compilers to speed it up.
>
> Isn't that what Qemu is for ? :-) I've managed to recompile LLVM
> and clang in NetBSD 9 for my SS20, one by cross-compiling
> (LLVM requires too much memory), the other in QEmu.
> Unfortunately, Qemu doesn't yet support mt-tcg (multithreaded
> emulation) for sparc so single-core only - still faster than the HW,
> mostly because of incomparably faster I/O.

My distcc plan was to have it talk to a cross compiler on my x86
desktop. I never got to the point where it would have actually used
it.

> > If there were more people using it or more testing, or more distros
> > supporting it - not just (theoretically?) working on it - then I'd be
> > fighting to keep it.
>
> I wish I had some arguments for that point... I will just re-mention Qemu,
> as it makes testing quite easy and reasonably not-too-slow.

QEMU is somewhat slow and never _exactly_ the same as real hardware,
so I can see why distros might not use it as a build machine or
whatever. And if they do build for QEMU and it doesn't work on real
hardware, then we have a distro that's only for virtual hardware and
that seems pointless.

You're right that with the right bits and pieces resurrecting a
Sparc32 machine is relatively "easy", however there's still no modern
distros supporting this ancient hardware so the upstream kernel has
most likely bitrotted.

I still don't think it's worth saving.

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect

[Yu Zhao]

On Sun, Dec 20, 2020 at 12:06:38AM -0800, Nadav Amit wrote:
> > On Dec 19, 2020, at 10:05 PM, Yu Zhao  wrote:
> > 
> > On Sat, Dec 19, 2020 at 01:34:29PM -0800, Nadav Amit wrote:
> >> [ cc’ing some more people who have experience with similar problems ]
> >> 
> >>> On Dec 19, 2020, at 11:15 AM, Andrea Arcangeli  
> >>> wrote:
> >>> 
> >>> Hello,
> >>> 
> >>> On Fri, Dec 18, 2020 at 08:30:06PM -0800, Nadav Amit wrote:
>  Analyzing this problem indicates that there is a real bug since
>  mmap_lock is only taken for read in mwriteprotect_range(). This might
> >>> 
> >>> Never having to take the mmap_sem for writing, and in turn never
> >>> blocking, in order to modify the pagetables is quite an important
> >>> feature in uffd that justifies uffd instead of mprotect. It's not the
> >>> most important reason to use uffd, but it'd be nice if that guarantee
> >>> would remain also for the UFFDIO_WRITEPROTECT API, not only for the
> >>> other pgtable manipulations.
> >>> 
>  Consider the following scenario with 3 CPUs (cpu2 is not shown):
>  
>  cpu0 cpu1
>   
>  userfaultfd_writeprotect()
>  [ write-protecting ]
>  mwriteprotect_range()
>  mmap_read_lock()
>  change_protection()
>  change_protection_range()
>   ...
>   change_pte_range()
>   [ defer TLB flushes]
>   userfaultfd_writeprotect()
>    mmap_read_lock()
>    change_protection()
>    [ write-unprotect ]
>    ...
> [ unprotect PTE logically ]
>   ...
>   [ page-fault]
>   ...
>   wp_page_copy()
>   [ set new writable page in PTE]
> > 
> > I don't see any problem in this example -- wp_page_copy() calls
> > ptep_clear_flush_notify(), which should take care of the stale entry
> > left by cpu0.
> > 
> > That being said, I suspect the memory corruption you observed is
> > related this example, with cpu1 running something else that flushes
> > conditionally depending on pte_write().
> > 
> > Do you know which type of pages were corrupted? file, anon, etc.
> 
> First, Yu, you are correct. My analysis is incorrect, but let me have
> another try (below). To answer your (and Andrea’s) question - this happens
> with upstream without any changes, excluding a small fix to the selftest,
> since it failed (got stuck) due to missing wake events. [1]
> 
> We are talking about anon memory.
> 
> So to correct myself, I think that what I really encountered was actually
> during MM_CP_UFFD_WP_RESOLVE (i.e., when the protection is removed). The
> problem was that in this case the “write”-bit was removed during unprotect.

Thanks. You are right about when the problem happens: UFD write-
UNprotecting. But it's not UFD write-UNprotecting that removes the
writable bit -- the bit can only be removed during COW or UFD
write-protecting. So your original example was almost correct, except
the last line describing cpu1.

The problem is how do_wp_page() handles non-COW pages. (For COW pages,
do_wp_page() works correctly by either reusing an existing page or
make a new copy out of it.) In UFD case, the existing page may not
have been properly write-protected. As you pointed out, the tlb flush
may not be done yet. Making a copy can potentially race with the
writer on cpu2.

Should we fix the problem by ensuring integrity of the copy? IMO, no,
because do_wp_page() shouldn't copy at all in this case. It seems it
was recently broken by

  be068f29034f mm: fix misplaced unlock_page in do_wp_page()
  09854ba94c6a mm: do_wp_page() simplification

I haven't study them carefully. But if you could just revert them and
run the test again, we'd know where exactly to look at next.

> Sorry for the strange formatting to fit within 80 columns:
> 
> 
> [ Start: PTE is writable ]
> 
> cpu0  cpu1cpu2
>   
>   [ Writable PTE 
> cached in TLB ]
> userfaultfd_writeprotect()
> [ write-*unprotect* ]
> mwriteprotect_range()
> mmap_read_lock()
> change_protection()
> 
> change_protection_range()
>  ...
>  change_pte_range()
>  [ *clear* “write”-bit ]
>  [ defer TLB flushes]
>   [ page-fault ]
>   …
>   wp_page_copy()
>cow_user_page()
> [ copy page ]
>   [ write to old
> page ]
>   

[PATCH] epoll: fix compat syscall wire up of epoll_pwait2

[Heiko Carstens]

Commit b0a0c2615f6f ("epoll: wire up syscall epoll_pwait2") wired up
the 64 bit syscall instead of the compat variant in a couple of places.

Cc: Willem de Bruijn 
Cc: Al Viro 
Cc: Arnd Bergmann 
Cc: Matthew Wilcox (Oracle) 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Thomas Bogendoerfer 
Cc: Vasily Gorbik 
Cc: Christian Borntraeger 
Cc: "David S. Miller" 
Fixes: b0a0c2615f6f ("epoll: wire up syscall epoll_pwait2")
Signed-off-by: Heiko Carstens 
---
 arch/arm64/include/asm/unistd32.h | 2 +-
 arch/mips/kernel/syscalls/syscall_n32.tbl | 2 +-
 arch/s390/kernel/syscalls/syscall.tbl | 2 +-
 arch/sparc/kernel/syscalls/syscall.tbl| 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/include/asm/unistd32.h 
b/arch/arm64/include/asm/unistd32.h
index f4bca2b90218..cccfbbefbf95 100644
--- a/arch/arm64/include/asm/unistd32.h
+++ b/arch/arm64/include/asm/unistd32.h
@@ -890,7 +890,7 @@ __SYSCALL(__NR_faccessat2, sys_faccessat2)
 #define __NR_process_madvise 440
 __SYSCALL(__NR_process_madvise, sys_process_madvise)
 #define __NR_epoll_pwait2 441
-__SYSCALL(__NR_epoll_pwait2, sys_epoll_pwait2)
+__SYSCALL(__NR_epoll_pwait2, compat_sys_epoll_pwait2)
 
 /*
  * Please add new compat syscalls above this comment and update
diff --git a/arch/mips/kernel/syscalls/syscall_n32.tbl 
b/arch/mips/kernel/syscalls/syscall_n32.tbl
index ad9c3dd0ab1f..0f03ad223f33 100644
--- a/arch/mips/kernel/syscalls/syscall_n32.tbl
+++ b/arch/mips/kernel/syscalls/syscall_n32.tbl
@@ -379,4 +379,4 @@
 438n32 pidfd_getfd sys_pidfd_getfd
 439n32 faccessat2  sys_faccessat2
 440n32 process_madvise sys_process_madvise
-441n32 epoll_pwait2sys_epoll_pwait2
+441n32 epoll_pwait2compat_sys_epoll_pwait2
diff --git a/arch/s390/kernel/syscalls/syscall.tbl 
b/arch/s390/kernel/syscalls/syscall.tbl
index 14f6525886a8..d443423495e5 100644
--- a/arch/s390/kernel/syscalls/syscall.tbl
+++ b/arch/s390/kernel/syscalls/syscall.tbl
@@ -443,4 +443,4 @@
 438  commonpidfd_getfd sys_pidfd_getfd 
sys_pidfd_getfd
 439  commonfaccessat2  sys_faccessat2  
sys_faccessat2
 440  commonprocess_madvise sys_process_madvise 
sys_process_madvise
-441  commonepoll_pwait2sys_epoll_pwait2
sys_epoll_pwait2
+441  commonepoll_pwait2sys_epoll_pwait2
compat_sys_epoll_pwait2
diff --git a/arch/sparc/kernel/syscalls/syscall.tbl 
b/arch/sparc/kernel/syscalls/syscall.tbl
index c7da4c3271e6..40d8c7cd8298 100644
--- a/arch/sparc/kernel/syscalls/syscall.tbl
+++ b/arch/sparc/kernel/syscalls/syscall.tbl
@@ -486,4 +486,4 @@
 438common  pidfd_getfd sys_pidfd_getfd
 439common  faccessat2  sys_faccessat2
 440common  process_madvise sys_process_madvise
-441common  epoll_pwait2sys_epoll_pwait2
+441common  epoll_pwait2sys_epoll_pwait2
compat_sys_epoll_pwait2
-- 
2.17.1

Re: [PATCH v1 4/4] s390/kvm: VSIE: correctly handle MVPG when in VSIE

[David Hildenbrand]

On 18.12.20 15:18, Claudio Imbrenda wrote:
> Correctly handle the MVPG instruction when issued by a VSIE guest.
> 

I remember that MVPG SIE documentation was completely crazy and full of
corner cases. :)

Looking at arch/s390/kvm/intercept.c:handle_mvpg_pei(), I can spot that

1. "This interception can only happen for guests with DAT disabled ..."
2. KVM does not make use of any mvpg state inside the SCB.

Can this be observed with Linux guests?


Can I get some information on what information is stored at [0xc0, 0xd)
inside the SCB? I assume it's:

0xc0: guest physical address of source PTE
0xc8: guest physical address of target PTE


Also, which conditions have to be met such that we get a ICPT_PARTEXEC:

a) State of guest DAT (I assume off?)
b) State of PTEs: What happens if there is no PTE (I assume we need two
PTEs, otherwise no such intercept)? I assume we get an intercept if one
of both PTEs is not present or the destination PTE is protected. Correct?

So, when we (g1) get an intercept for g3, can we be sure 0xc0 and 0xc8
in the scb are both valid g1 addresses pointing at our PTE, and what do
we know about these PTEs (one not present or destination protected)?

[...]
>  /*
>   * Run the vsie on a shadow scb and a shadow gmap, without any further
>   * sanity checks, handling SIE faults.
> @@ -1063,6 +1132,10 @@ static int do_vsie_run(struct kvm_vcpu *vcpu, struct 
> vsie_page *vsie_page)
>   if ((scb_s->ipa & 0xf000) != 0xf000)
>   scb_s->ipa += 0x1000;
>   break;
> + case ICPT_PARTEXEC:
> + if (scb_s->ipa == 0xb254)

Old code hat "/* MVPG only */" - why is this condition now necessary?

> + rc = vsie_handle_mvpg(vcpu, vsie_page);
> + break;
>   }
>   return rc;
>  }
> 


-- 
Thanks,

David / dhildenb

Re: 5.10.1: UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:1

[Toralf Förster]

On 12/20/20 2:09 AM, Randy Dunlap wrote:

On 12/18/20 2:20 AM, Toralf Förster wrote:

On 12/18/20 7:54 AM, Randy Dunlap wrote:

Hi,

[adding linux-mm]

On 12/16/20 1:54 AM, Toralf Förster wrote:

Hi,

I got this recently at this hardened Gentoo Linux server:

Linux mr-fox 5.10.1 #1 SMP Tue Dec 15 22:09:42 CET 2020 x86_64 Intel(R)
Xeon(R) CPU E5-1650 v3 @ 3.50GHz GenuineIntel GNU/Linux


Dec 15 23:31:51 mr-fox kernel: [ 1974.206972]

Dec 15 23:31:51 mr-fox kernel: [ 1974.206977] UBSAN: shift-out-of-bounds
in ./include/linux/log2.h:57:13
Dec 15 23:31:51 mr-fox kernel: [ 1974.206980] shift exponent 64 is too
large for 64-bit type 'long unsigned int'
Dec 15 23:31:51 mr-fox kernel: [ 1974.206982] CPU: 11 PID: 21051 Comm:
cc1 Tainted: G    T 5.10.1 #1
Dec 15 23:31:51 mr-fox kernel: [ 1974.206984] Hardware name: ASUSTeK
COMPUTER INC. Z10PA-U8 Series/Z10PA-U8 Series, BIOS 3703 08/02/2018
Dec 15 23:31:51 mr-fox kernel: [ 1974.206985] Call Trace:
Dec 15 23:31:51 mr-fox kernel: [ 1974.206993]  dump_stack+0x57/0x6a
Dec 15 23:31:51 mr-fox kernel: [ 1974.206996]  ubsan_epilogue+0x5/0x40
Dec 15 23:31:51 mr-fox kernel: [ 1974.206999]
__ubsan_handle_shift_out_of_bounds.cold+0x61/0x10e
Dec 15 23:31:51 mr-fox kernel: [ 1974.207002]
ondemand_readahead.cold+0x16/0x21
Dec 15 23:31:51 mr-fox kernel: [ 1974.207007]
generic_file_buffered_read+0x452/0x890
Dec 15 23:31:51 mr-fox kernel: [ 1974.207011]  new_sync_read+0x156/0x200
Dec 15 23:31:51 mr-fox kernel: [ 1974.207014]  vfs_read+0xf8/0x190
Dec 15 23:31:51 mr-fox kernel: [ 1974.207016]  ksys_read+0x65/0xe0
Dec 15 23:31:51 mr-fox kernel: [ 1974.207018]  do_syscall_64+0x33/0x40
Dec 15 23:31:51 mr-fox kernel: [ 1974.207021]
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Dec 15 23:31:51 mr-fox kernel: [ 1974.207024] RIP: 0033:0x7f01b2df198e
Dec 15 23:31:51 mr-fox kernel: [ 1974.207026] Code: c0 e9 b6 fe ff ff 50
48 8d 3d 66 c3 09 00 e8 59 e2 01 00 66 0f 1f 84 00 00 00 00 00 64 8b 04
25 18 00 00 00 85 c0 75 14 0f 05 <48> 3d 00 f0 ff ff 77 5a c3 66 0f 1f
84 00 00 00 00 00 48 83 ec 28
Dec 15 23:31:51 mr-fox kernel: [ 1974.207028] RSP: 002b:7fff2167e998
EFLAGS: 0246 ORIG_RAX: 
Dec 15 23:31:51 mr-fox kernel: [ 1974.207030] RAX: ffda RBX:
 RCX: 7f01b2df198e
Dec 15 23:31:51 mr-fox kernel: [ 1974.207032] RDX:  RSI:
054dcc50 RDI: 0004
Dec 15 23:31:51 mr-fox kernel: [ 1974.207033] RBP: 054dcc50 R08:
054dcc50 R09: 
Dec 15 23:31:51 mr-fox kernel: [ 1974.207034] R10:  R11:
0246 R12: 054dc3b0
Dec 15 23:31:51 mr-fox kernel: [ 1974.207035] R13: 8000 R14:
054c9800 R15: 
Dec 15 23:31:51 mr-fox kernel: [ 1974.207037]



Known issue ?


Not that I have heard about, but that's not conclusive.

Looks to me like this is in mm/readahead.c:

static unsigned long get_init_ra_size(unsigned long size, unsigned long max)
{
 unsigned long newsize = roundup_pow_of_two(size);


What filesystem?  What workload?


/ is a 32 GB ext4 filesystem.
Data are at 3 BTRFS filesystems, 1x 500 GB and 2x 1.6TB.

2 Tor relays run at 100% each and utilizes the 1 GBit/s by 50%-60% [1]

7 build bots are running over the Gentoo software repostory [2]
1 AFL bot fuzzies the Tor sources.
Those 8 jobs are contained by a cgroup of 9 CPUs and 120 GB RAM [3],
each job is contained further by an own sub cgroup of 1.5 CPU and 20 GB
RAM [4]

The host is monitored using sysstat, the load is about 11.8, CPU[all] at
80%, proc/s at 1800, cswchs/s at 2 and so on.


[1] https://metrics.torproject.org/rs.html#search/zwiebeltoralf
[2] https://zwiebeltoralf.de/tinderbox.html
[3] https://github.com/toralf/tinderbox/blob/master/bin/cgroup.sh
[4] https://github.com/toralf/tinderbox/blob/master/bin/bwrap.sh#L15

--


Hi Toralf,

Is this something that happens more than once?


Till now only once.


I think we would like to find out what is causing it.
I see a couple of problems.

(a)
   UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13
   shift exponent 64 is too large for 64-bit type 'long unsigned int'

:57: is like so:

 50 /**
 51  * __roundup_pow_of_two() - round up to nearest power of two
 52  * @n: value to round up
 53  */
 54 static inline __attribute__((const))
 55 unsigned long __roundup_pow_of_two(unsigned long n)
 56 {
 57 return 1UL << fls_long(n - 1);
 58 }

It's OK/valid for fls_long() [fls64()] to return 64 for a bit
position -- it just means the high-order bit in a 64-bit value.
So this code should either always subtract 1 from fls_long() or
do that if fls_long() == 64.


(b) in mm/readahead.c:get_init_ra_size():

305 /*
306  * Set the initial window size, round to next power of 2 and square
307  * for small si

RE: [EXT] Re: [PATCH net v3] net: mvpp2: Fix GoP port 3 Networking Complex Control configurations

[Stefan Chulski]

> External Email
> 
> --
> On Thu, 17 Dec 2020 14:37:28 +0200 stef...@marvell.com wrote:
> > From: Stefan Chulski 
> >
> > During GoP port 2 Networking Complex Control mode of operation
> > configurations, also GoP port 3 mode of operation was wrongly set.
> > Patch removes these configurations.
> > GENCONF_CTRL0_PORTX naming also fixed.
> 
> Testing the stable backport it looks like this addition change will be
> problematic. Not to mention it goes against the "fixes should be minimal" 
> rule.
> 
> Could you please send just a one liner which removes the offending ORing in
> of the bad bit?
> 
> We can do the rename soon after in net-next, the trees are merged pretty
> much every week so it won't be a long wait.

I would repost with single line change.

Regards,
Stefan.

[PATCH net v4] net: mvpp2: Fix GoP port 3 Networking Complex Control configurations

[stefanc]

From: Stefan Chulski 

During GoP port 2 Networking Complex Control mode of operation configurations,
also GoP port 3 mode of operation was wrongly set.
Patch removes these configurations.

Fixes: f84bf386f395 ("net: mvpp2: initialize the GoP")
Acked-by: Marcin Wojtas 
Signed-off-by: Stefan Chulski 
---

Changes in v4:
- Remove rename change.
Changes in v3:
- No changes.
Changes in v2:
- Added Fixes tag.

 drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c 
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index d64dc12..82c6bef 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -1231,7 +1231,7 @@ static void mvpp22_gop_init_rgmii(struct mvpp2_port *port)
 
regmap_read(priv->sysctrl_base, GENCONF_CTRL0, &val);
if (port->gop_id == 2)
-   val |= GENCONF_CTRL0_PORT0_RGMII | GENCONF_CTRL0_PORT1_RGMII;
+   val |= GENCONF_CTRL0_PORT0_RGMII;
else if (port->gop_id == 3)
val |= GENCONF_CTRL0_PORT1_RGMII_MII;
regmap_write(priv->sysctrl_base, GENCONF_CTRL0, val);
-- 
1.9.1

[PATCH 1/1] v4l: ioctl: Fix memory leak in video_usercopy

[Sakari Ailus]

When an IOCTL with argument size larger than 128 that also used array
arguments were handled, two memory allocations were made but alas, only
the latter one of them was released. This happened because there was only
a single local variable to hold such a temporary allocation.

Fix this by adding separate variables to hold the pointers to the
temporary allocations.

Reported-by: Arnd Bergmann 
Reported-by: syzbot+1115e79c8df6472c6...@syzkaller.appspotmail.com
Fixes: d14e6d76ebf7 ("[media] v4l: Add multi-planar ioctl handling code")
Cc: sta...@vger.kernel.org
Signed-off-by: Sakari Ailus 
---
 drivers/media/v4l2-core/v4l2-ioctl.c | 31 +---
 1 file changed, 14 insertions(+), 17 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 3198abdd538ce..f42a779948779 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -3283,7 +3283,7 @@ video_usercopy(struct file *file, unsigned int orig_cmd, 
unsigned long arg,
   v4l2_kioctl func)
 {
charsbuf[128];
-   void*mbuf = NULL;
+   void*mbuf = NULL, *array_buf = NULL;
void*parg = (void *)arg;
longerr  = -EINVAL;
boolhas_array_args;
@@ -3318,27 +3318,21 @@ video_usercopy(struct file *file, unsigned int 
orig_cmd, unsigned long arg,
has_array_args = err;
 
if (has_array_args) {
-   /*
-* When adding new types of array args, make sure that the
-* parent argument to ioctl (which contains the pointer to the
-* array) fits into sbuf (so that mbuf will still remain
-* unused up to here).
-*/
-   mbuf = kvmalloc(array_size, GFP_KERNEL);
+   array_buf = kvmalloc(array_size, GFP_KERNEL);
err = -ENOMEM;
-   if (NULL == mbuf)
+   if (array_buf == NULL)
goto out_array_args;
err = -EFAULT;
if (in_compat_syscall())
-   err = v4l2_compat_get_array_args(file, mbuf, user_ptr,
-array_size, orig_cmd,
-parg);
+   err = v4l2_compat_get_array_args(file, array_buf,
+user_ptr, array_size,
+orig_cmd, parg);
else
-   err = copy_from_user(mbuf, user_ptr, array_size) ?
+   err = copy_from_user(array_buf, user_ptr, array_size) ?
-EFAULT : 0;
if (err)
goto out_array_args;
-   *kernel_ptr = mbuf;
+   *kernel_ptr = array_buf;
}
 
/* Handles IOCTL */
@@ -3360,12 +3354,14 @@ video_usercopy(struct file *file, unsigned int 
orig_cmd, unsigned long arg,
if (in_compat_syscall()) {
int put_err;
 
-   put_err = v4l2_compat_put_array_args(file, user_ptr, 
mbuf,
-array_size, 
orig_cmd,
+   put_err = v4l2_compat_put_array_args(file, user_ptr,
+array_buf,
+array_size,
+orig_cmd,
 parg);
if (put_err)
err = put_err;
-   } else if (copy_to_user(user_ptr, mbuf, array_size)) {
+   } else if (copy_to_user(user_ptr, array_buf, array_size)) {
err = -EFAULT;
}
goto out_array_args;
@@ -3381,6 +3377,7 @@ video_usercopy(struct file *file, unsigned int orig_cmd, 
unsigned long arg,
if (video_put_user((void __user *)arg, parg, cmd, orig_cmd))
err = -EFAULT;
 out:
+   kvfree(array_buf);
kvfree(mbuf);
return err;
 }
-- 
2.20.1

Re: [PATCH 1/1] v4l: ioctl: Fix memory leak in video_usercopy

[Hans Verkuil]

On 20/12/2020 12:06, Sakari Ailus wrote:
> When an IOCTL with argument size larger than 128 that also used array
> arguments were handled, two memory allocations were made but alas, only
> the latter one of them was released. This happened because there was only
> a single local variable to hold such a temporary allocation.
> 
> Fix this by adding separate variables to hold the pointers to the
> temporary allocations.
> 
> Reported-by: Arnd Bergmann 
> Reported-by: syzbot+1115e79c8df6472c6...@syzkaller.appspotmail.com
> Fixes: d14e6d76ebf7 ("[media] v4l: Add multi-planar ioctl handling code")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Sakari Ailus 

Acked-by: Hans Verkuil 

Regards,

Hans

> ---
>  drivers/media/v4l2-core/v4l2-ioctl.c | 31 +---
>  1 file changed, 14 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
> b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 3198abdd538ce..f42a779948779 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -3283,7 +3283,7 @@ video_usercopy(struct file *file, unsigned int 
> orig_cmd, unsigned long arg,
>  v4l2_kioctl func)
>  {
>   charsbuf[128];
> - void*mbuf = NULL;
> + void*mbuf = NULL, *array_buf = NULL;
>   void*parg = (void *)arg;
>   longerr  = -EINVAL;
>   boolhas_array_args;
> @@ -3318,27 +3318,21 @@ video_usercopy(struct file *file, unsigned int 
> orig_cmd, unsigned long arg,
>   has_array_args = err;
>  
>   if (has_array_args) {
> - /*
> -  * When adding new types of array args, make sure that the
> -  * parent argument to ioctl (which contains the pointer to the
> -  * array) fits into sbuf (so that mbuf will still remain
> -  * unused up to here).
> -  */
> - mbuf = kvmalloc(array_size, GFP_KERNEL);
> + array_buf = kvmalloc(array_size, GFP_KERNEL);
>   err = -ENOMEM;
> - if (NULL == mbuf)
> + if (array_buf == NULL)
>   goto out_array_args;
>   err = -EFAULT;
>   if (in_compat_syscall())
> - err = v4l2_compat_get_array_args(file, mbuf, user_ptr,
> -  array_size, orig_cmd,
> -  parg);
> + err = v4l2_compat_get_array_args(file, array_buf,
> +  user_ptr, array_size,
> +  orig_cmd, parg);
>   else
> - err = copy_from_user(mbuf, user_ptr, array_size) ?
> + err = copy_from_user(array_buf, user_ptr, array_size) ?
>   -EFAULT : 0;
>   if (err)
>   goto out_array_args;
> - *kernel_ptr = mbuf;
> + *kernel_ptr = array_buf;
>   }
>  
>   /* Handles IOCTL */
> @@ -3360,12 +3354,14 @@ video_usercopy(struct file *file, unsigned int 
> orig_cmd, unsigned long arg,
>   if (in_compat_syscall()) {
>   int put_err;
>  
> - put_err = v4l2_compat_put_array_args(file, user_ptr, 
> mbuf,
> -  array_size, 
> orig_cmd,
> + put_err = v4l2_compat_put_array_args(file, user_ptr,
> +  array_buf,
> +  array_size,
> +  orig_cmd,
>parg);
>   if (put_err)
>   err = put_err;
> - } else if (copy_to_user(user_ptr, mbuf, array_size)) {
> + } else if (copy_to_user(user_ptr, array_buf, array_size)) {
>   err = -EFAULT;
>   }
>   goto out_array_args;
> @@ -3381,6 +3377,7 @@ video_usercopy(struct file *file, unsigned int 
> orig_cmd, unsigned long arg,
>   if (video_put_user((void __user *)arg, parg, cmd, orig_cmd))
>   err = -EFAULT;
>  out:
> + kvfree(array_buf);
>   kvfree(mbuf);
>   return err;
>  }
> 

RE: [EXT] Re: [PATCH net-next] net: mvpp2: prs: improve ipv4 parse flow

[Stefan Chulski]

> 
> --
> On Thu, 17 Dec 2020 18:07:58 +0200 stef...@marvell.com wrote:
> > From: Stefan Chulski 
> >
> > Patch didn't fix any issue, just improve parse flow and align ipv4
> > parse flow with ipv6 parse flow.
> >
> > Currently ipv4 kenguru parser first check IP protocol(TCP/UDP) and
> > then destination IP address.
> > Patch introduce reverse ipv4 parse, first destination IP address
> > parsed and only then IP protocol.
> > This would allow extend capability for packet L4 parsing and align
> > ipv4 parsing flow with ipv6.
> >
> > Suggested-by: Liron Himi 
> > Signed-off-by: Stefan Chulski 
> 
> This one will need to wait until after the merge window
> 
> --
> 
> # Form letter - net-next is closed
> 
> We have already sent the networking pull request for 5.11 and therefore net-
> next is closed for new drivers, features, code refactoring and optimizations.
> We are currently accepting bug fixes only.
> 
> Please repost when net-next reopens after 5.11-rc1 is cut.

OK, Thanks.

> Look out for the announcement on the mailing list or check:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__vger.kernel.org_-
> 7Edavem_net-
> 2Dnext.html&d=DwICAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=DDQ3dKwkTIxKAl
> 6_Bs7GMx4zhJArrXKN2mDMOXGh7lg&m=2CcDqbEJMvxpx15rGBe2og6oh1eZ
> hVee8xvK-mjfd0E&s=r1d6bSIPQmjwJqe-
> mkU_s5wyqHOU82D18G6SkVuUg5A&e=
> 
> RFC patches sent for review only are obviously welcome at any time.

If I post RFC patches for review only, should I add some prefix or tag for this?
And if all reviewers OK with change(or no comments at all), should I repost 
this patch again after net-next opened?

Thanks,
Stefan.

Re: [PATCH] m68k: Enable seccomp architecture tracking

[John Paul Adrian Glaubitz]

Hi Geert!

On 12/20/20 9:51 AM, Geert Uytterhoeven wrote:
> To enable seccomp constant action bitmaps, we need to have a static
> mapping to the audit architecture and system call table size.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
> Needed for CONFIG_SECCOMP_CACHE_DEBUG.
> Note that upstream doesn't have m68k seccomp support yet.

Have we added SECCOMP support for m68k to the kernel yet?

It's actually something I was hoping to do over the holidays ;-).

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH] ovl: fix dentry leak in ovl_get_redirect

[Joseph Qi]

On 12/19/20 12:17 AM, Liangyan wrote:
> We need to lock d_parent->d_lock before dget_dlock, or this may
> have d_lockref updated parallelly like calltrace below which will
> cause dentry->d_lockref leak and risk a crash.
> 
> npm-20576 [028]  5705749.040094:
> [28] ovl_set_redirect+0x11c/0x310 //tmp = dget_dlock(d->d_parent);
> [28]?  ovl_set_redirect+0x5/0x310
> [28] ovl_rename+0x4db/0x790 [overlay]
> [28] vfs_rename+0x6e8/0x920
> [28] do_renameat2+0x4d6/0x560
> [28] __x64_sys_rename+0x1c/0x20
> [28] do_syscall_64+0x55/0x1a0
> [28] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> 
> npm-20574 [036]  5705749.040094:
> [36] __d_lookup+0x107/0x140 //dentry->d_lockref.count++;
> [36] lookup_fast+0xe0/0x2d0
> [36] walk_component+0x48/0x350
> [36] link_path_walk+0x1bf/0x650
> [36]?  path_init+0x1f6/0x2f0
> [36] path_lookupat+0x82/0x210
> [36] filename_lookup+0xb8/0x1a0
> [36]?  __audit_getname+0xa2/0xb0
> [36]?  getname_flags+0xb9/0x1e0
> [36]?  vfs_statx+0x73/0xe0
> [36] vfs_statx+0x73/0xe0
> [36] __do_sys_statx+0x3b/0x80
> [36]?  syscall_trace_enter+0x1ae/0x2c0
> [36] do_syscall_64+0x55/0x1a0
> [36] entry_SYSCALL_64_
> 
> [   49.799059] PGD 80061fed7067 P4D 80061fed7067 PUD 61fec5067 PMD 0
> [   49.799689] Oops: 0002 [#1] SMP PTI
> [   49.800019] CPU: 2 PID: 2332 Comm: node Not tainted 
> 4.19.24-7.20.al7.x86_64 #1
> [   49.800678] Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 8a46cfe 
> 04/01/2014
> [   49.801380] RIP: 0010:_raw_spin_lock+0xc/0x20
> [   49.803470] RSP: 0018:ac6fc5417e98 EFLAGS: 00010246
> [   49.803949] RAX:  RBX: 93b8da3446c0 RCX: 
> 000a
> [   49.804600] RDX: 0001 RSI: 000a RDI: 
> 0088
> [   49.805252] RBP:  R08:  R09: 
> 993cf040
> [   49.805898] R10: 93b92292e580 R11: d27f188a4b80 R12: 
> 
> [   49.806548] R13: ff9c R14: fffe R15: 
> 93b8da3446c0
> [   49.807200] FS:  7ffbedffb700() GS:93b92788() 
> knlGS:
> [   49.807935] CS:  0010 DS:  ES:  CR0: 80050033
> [   49.808461] CR2: 0088 CR3: 0005e3f74006 CR4: 
> 003606a0
> [   49.809113] DR0:  DR1:  DR2: 
> 
> [   49.809758] DR3:  DR6: fffe0ff0 DR7: 
> 0400
> [   49.810410] Call Trace:
> [   49.810653]  d_delete+0x2c/0xb0
> [   49.810951]  vfs_rmdir+0xfd/0x120
> [   49.811264]  do_rmdir+0x14f/0x1a0
> [   49.811573]  do_syscall_64+0x5b/0x190
> [   49.811917]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [   49.812385] RIP: 0033:0x7ffbf505ffd7
> [   49.814404] RSP: 002b:7ffbedffada8 EFLAGS: 0297 ORIG_RAX: 
> 0054
> [   49.815098] RAX: ffda RBX: 7ffbedffb640 RCX: 
> 7ffbf505ffd7
> [   49.815744] RDX: 04449700 RSI:  RDI: 
> 06c8cd50
> [   49.816394] RBP: 7ffbedffaea0 R08:  R09: 
> 00017d0b
> [   49.817038] R10:  R11: 0297 R12: 
> 0012
> [   49.817687] R13: 072823d8 R14: 7ffbedffb700 R15: 
> 072823d8
> [   49.818338] Modules linked in: pvpanic cirrusfb button qemu_fw_cfg atkbd 
> libps2 i8042
> [   49.819052] CR2: 0088
> [   49.819368] ---[ end trace 4e652b8aa299aa2d ]---
> [   49.819796] RIP: 0010:_raw_spin_lock+0xc/0x20
> [   49.821880] RSP: 0018:ac6fc5417e98 EFLAGS: 00010246
> [   49.822363] RAX:  RBX: 93b8da3446c0 RCX: 
> 000a
> [   49.823008] RDX: 0001 RSI: 000a RDI: 
> 0088
> [   49.823658] RBP:  R08:  R09: 
> 993cf040
> [   49.825404] R10: 93b92292e580 R11: d27f188a4b80 R12: 
> 
> [   49.827147] R13: ff9c R14: fffe R15: 
> 93b8da3446c0
> [   49.828890] FS:  7ffbedffb700() GS:93b92788() 
> knlGS:
> [   49.830725] CS:  0010 DS:  ES:  CR0: 80050033
> [   49.832359] CR2: 0088 CR3: 0005e3f74006 CR4: 
> 003606a0
> [   49.834085] DR0:  DR1:  DR2: 
> 
> [   49.835792] DR3:  DR6: fffe0ff0 DR7: 
> 0400
> 
> Fixes: a6c606551141 ("ovl: redirect on rename-dir")
> Signed-off-by: Liangyan 
> Suggested-by: Joseph Qi 
> ---
>  fs/overlayfs/dir.c | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/fs/overlayfs/dir.c b/fs/overlayfs/dir.c
> index 28a075b5f5b2..9831e7046038 100644
> --- a/fs/overlayfs/dir.c
> +++ b/fs/overlayfs/dir.c
> @@ -973,6 +973,7 @@ static char *ovl_get_redirect(struct dentry *dentry, bool 
> abs_redirect)
>   for (d = dget(dentry); !IS_ROOT(d);) {
>   const char *name;
>   int thislen;
> + struct dentry *parent = NULL;
>  
>   spin_loc

Re: [PATCH] inotify, memcg: account inotify instances to kmemcg

[Amir Goldstein]

On Sun, Dec 20, 2020 at 6:24 AM Shakeel Butt  wrote:
>
> On Sat, Dec 19, 2020 at 8:25 AM Amir Goldstein  wrote:
> >
> > On Sat, Dec 19, 2020 at 4:31 PM Shakeel Butt  wrote:
> > >
> > > On Sat, Dec 19, 2020 at 1:48 AM Amir Goldstein  wrote:
> > > >
> > > > On Sat, Dec 19, 2020 at 12:11 AM Shakeel Butt  
> > > > wrote:
> > > > >
> > > > > Currently the fs sysctl inotify/max_user_instances is used to limit 
> > > > > the
> > > > > number of inotify instances on the system. For systems running 
> > > > > multiple
> > > > > workloads, the per-user namespace sysctl max_inotify_instances can be
> > > > > used to further partition inotify instances. However there is no easy
> > > > > way to set a sensible system level max limit on inotify instances and
> > > > > further partition it between the workloads. It is much easier to 
> > > > > charge
> > > > > the underlying resource (i.e. memory) behind the inotify instances to
> > > > > the memcg of the workload and let their memory limits limit the number
> > > > > of inotify instances they can create.
> > > >
> > > > Not that I have a problem with this patch, but what problem does it try 
> > > > to
> > > > solve?
> > >
> > > I am aiming for the simplicity to not set another limit which can
> > > indirectly be limited by memcg limits. I just want to set the memcg
> > > limit on our production environment which runs multiple workloads on a
> > > system and not think about setting a sensible value to
> > > max_user_instances in production. I would prefer to set
> > > max_user_instances to max int and let the memcg limits of the
> > > workloads limit their inotify usage.
> > >
> >
> > understood.
> > and I guess the multiple workloads cannot run each in their own userns?
> > because then you wouldn't need to change max_user_instances limit.
> >
>
> No workloads can run in their own user namespace but please note that
> max_user_instances is shared between all the user namespaces.

/proc/sys/fs/inotify/max_user_instances is shared between all the user
namespaces, but it only controls the init_user_ns limits.
/proc/sys/user/max_inotify_instances is per user ns and it is the one that
actually controls the inotify limits in non init_user_ns.

That said, I see that it is always initialized to MAX_INT on non init user ns,
which is exactly the setup that you are aiming at:

$ unshare -U
$ cat /proc/sys/user/max_inotify_instances
2147483647
$ cat /proc/sys/fs/inotify/max_user_instances
128

Thanks,
Amir.

Re: [PATCH v2] inotify, memcg: account inotify instances to kmemcg

[Amir Goldstein]

On Sun, Dec 20, 2020 at 6:46 AM Shakeel Butt  wrote:
>
> Currently the fs sysctl inotify/max_user_instances is used to limit the
> number of inotify instances on the system. For systems running multiple
> workloads, the per-user namespace sysctl max_inotify_instances can be
> used to further partition inotify instances. However there is no easy
> way to set a sensible system level max limit on inotify instances and
> further partition it between the workloads. It is much easier to charge
> the underlying resource (i.e. memory) behind the inotify instances to
> the memcg of the workload and let their memory limits limit the number
> of inotify instances they can create.
>
> With inotify instances charged to memcg, the admin can simply set
> max_user_instances to INT_MAX and let the memcg limits of the jobs limit
> their inotify instances.
>
> Signed-off-by: Shakeel Butt 
Reviewed-by: Amir Goldstein 

> ---
> Changes since v1:
> - introduce fsnotify_alloc_user_group() and convert fanotify in addition
>   to inotify to use that function. [suggested by Amir]
>
>  fs/notify/fanotify/fanotify_user.c |  2 +-
>  fs/notify/group.c  | 25 -
>  fs/notify/inotify/inotify_user.c   |  4 ++--
>  include/linux/fsnotify_backend.h   |  1 +
>  4 files changed, 24 insertions(+), 8 deletions(-)
>
> diff --git a/fs/notify/fanotify/fanotify_user.c 
> b/fs/notify/fanotify/fanotify_user.c
> index 3e01d8f2ab90..7e7afc2b62e1 100644
> --- a/fs/notify/fanotify/fanotify_user.c
> +++ b/fs/notify/fanotify/fanotify_user.c
> @@ -976,7 +976,7 @@ SYSCALL_DEFINE2(fanotify_init, unsigned int, flags, 
> unsigned int, event_f_flags)
> f_flags |= O_NONBLOCK;
>
> /* fsnotify_alloc_group takes a ref.  Dropped in fanotify_release */
> -   group = fsnotify_alloc_group(&fanotify_fsnotify_ops);
> +   group = fsnotify_alloc_user_group(&fanotify_fsnotify_ops);
> if (IS_ERR(group)) {
> free_uid(user);
> return PTR_ERR(group);
> diff --git a/fs/notify/group.c b/fs/notify/group.c
> index a4a4b1c64d32..ffd723ffe46d 100644
> --- a/fs/notify/group.c
> +++ b/fs/notify/group.c
> @@ -111,14 +111,12 @@ void fsnotify_put_group(struct fsnotify_group *group)
>  }
>  EXPORT_SYMBOL_GPL(fsnotify_put_group);
>
> -/*
> - * Create a new fsnotify_group and hold a reference for the group returned.
> - */
> -struct fsnotify_group *fsnotify_alloc_group(const struct fsnotify_ops *ops)
> +static struct fsnotify_group *__fsnotify_alloc_group(
> +   const struct fsnotify_ops *ops, gfp_t gfp)
>  {
> struct fsnotify_group *group;
>
> -   group = kzalloc(sizeof(struct fsnotify_group), GFP_KERNEL);
> +   group = kzalloc(sizeof(struct fsnotify_group), gfp);
> if (!group)
> return ERR_PTR(-ENOMEM);
>
> @@ -139,8 +137,25 @@ struct fsnotify_group *fsnotify_alloc_group(const struct 
> fsnotify_ops *ops)
>
> return group;
>  }
> +
> +/*
> + * Create a new fsnotify_group and hold a reference for the group returned.
> + */
> +struct fsnotify_group *fsnotify_alloc_group(const struct fsnotify_ops *ops)
> +{
> +   return __fsnotify_alloc_group(ops, GFP_KERNEL);
> +}
>  EXPORT_SYMBOL_GPL(fsnotify_alloc_group);
>
> +/*
> + * Create a new fsnotify_group and hold a reference for the group returned.
> + */
> +struct fsnotify_group *fsnotify_alloc_user_group(const struct fsnotify_ops 
> *ops)
> +{
> +   return __fsnotify_alloc_group(ops, GFP_KERNEL_ACCOUNT);
> +}
> +EXPORT_SYMBOL_GPL(fsnotify_alloc_user_group);
> +
>  int fsnotify_fasync(int fd, struct file *file, int on)
>  {
> struct fsnotify_group *group = file->private_data;
> diff --git a/fs/notify/inotify/inotify_user.c 
> b/fs/notify/inotify/inotify_user.c
> index 59c177011a0f..266d17e8ecb9 100644
> --- a/fs/notify/inotify/inotify_user.c
> +++ b/fs/notify/inotify/inotify_user.c
> @@ -632,11 +632,11 @@ static struct fsnotify_group 
> *inotify_new_group(unsigned int max_events)
> struct fsnotify_group *group;
> struct inotify_event_info *oevent;
>
> -   group = fsnotify_alloc_group(&inotify_fsnotify_ops);
> +   group = fsnotify_alloc_user_group(&inotify_fsnotify_ops);
> if (IS_ERR(group))
> return group;
>
> -   oevent = kmalloc(sizeof(struct inotify_event_info), GFP_KERNEL);
> +   oevent = kmalloc(sizeof(struct inotify_event_info), 
> GFP_KERNEL_ACCOUNT);
> if (unlikely(!oevent)) {
> fsnotify_destroy_group(group);
> return ERR_PTR(-ENOMEM);
> diff --git a/include/linux/fsnotify_backend.h 
> b/include/linux/fsnotify_backend.h
> index a2e42d3cd87c..e5409b83e731 100644
> --- a/include/linux/fsnotify_backend.h
> +++ b/include/linux/fsnotify_backend.h
> @@ -470,6 +470,7 @@ static inline void fsnotify_update_flags(struct dentry 
> *dentry)
>
>  /* create a new group */
>  extern struct fsnotify_group *fsnotify_alloc_group(const struct fsnotify_ops 
> *ops);

Re: [PATCH 1/1] v4l: ioctl: Fix memory leak in video_usercopy

[Arnd Bergmann]

On Sun, Dec 20, 2020 at 12:06 PM Sakari Ailus
 wrote:
>
> When an IOCTL with argument size larger than 128 that also used array
> arguments were handled, two memory allocations were made but alas, only
> the latter one of them was released. This happened because there was only
> a single local variable to hold such a temporary allocation.
>
> Fix this by adding separate variables to hold the pointers to the
> temporary allocations.
>
> Reported-by: Arnd Bergmann 
> Reported-by: syzbot+1115e79c8df6472c6...@syzkaller.appspotmail.com
> Fixes: d14e6d76ebf7 ("[media] v4l: Add multi-planar ioctl handling code")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Sakari Ailus 

Acked-by: Arnd Bergmann 

>  out:
> +   kvfree(array_buf);
> kvfree(mbuf);

I think it would make sense to change mbuf back to kzalloc()/kfree
after this, since the size of the ioctl argument has an upper bound
of 2^_IOC_SIZEBITS (16KB), which does not need the vmalloc
path, unlike the array args.

Arnd

Re: [PATCH] epoll: fix compat syscall wire up of epoll_pwait2

[Arnd Bergmann]

On Sun, Dec 20, 2020 at 11:00 AM Heiko Carstens  wrote:
>
> Commit b0a0c2615f6f ("epoll: wire up syscall epoll_pwait2") wired up
> the 64 bit syscall instead of the compat variant in a couple of places.
>
> Cc: Willem de Bruijn 
> Cc: Al Viro 
> Cc: Arnd Bergmann 
> Cc: Matthew Wilcox (Oracle) 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: Thomas Bogendoerfer 
> Cc: Vasily Gorbik 
> Cc: Christian Borntraeger 
> Cc: "David S. Miller" 
> Fixes: b0a0c2615f6f ("epoll: wire up syscall epoll_pwait2")
> Signed-off-by: Heiko Carstens 
> ---
>  arch/arm64/include/asm/unistd32.h | 2 +-
>  arch/mips/kernel/syscalls/syscall_n32.tbl | 2 +-
>  arch/s390/kernel/syscalls/syscall.tbl | 2 +-
>  arch/sparc/kernel/syscalls/syscall.tbl| 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)

I double-checked all the entries to make sure you caught all
the missing ones, looks good.

Acked-by: Arnd Bergmann 

Re: [PATCH 1/1] v4l: ioctl: Fix memory leak in video_usercopy

[Sakari Ailus]

On Sun, Dec 20, 2020 at 12:36:23PM +0100, Arnd Bergmann wrote:
> On Sun, Dec 20, 2020 at 12:06 PM Sakari Ailus
>  wrote:
> >
> > When an IOCTL with argument size larger than 128 that also used array
> > arguments were handled, two memory allocations were made but alas, only
> > the latter one of them was released. This happened because there was only
> > a single local variable to hold such a temporary allocation.
> >
> > Fix this by adding separate variables to hold the pointers to the
> > temporary allocations.
> >
> > Reported-by: Arnd Bergmann 
> > Reported-by: syzbot+1115e79c8df6472c6...@syzkaller.appspotmail.com
> > Fixes: d14e6d76ebf7 ("[media] v4l: Add multi-planar ioctl handling code")
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Sakari Ailus 
> 
> Acked-by: Arnd Bergmann 

Thanks!

> 
> >  out:
> > +   kvfree(array_buf);
> > kvfree(mbuf);
> 
> I think it would make sense to change mbuf back to kzalloc()/kfree
> after this, since the size of the ioctl argument has an upper bound
> of 2^_IOC_SIZEBITS (16KB), which does not need the vmalloc
> path, unlike the array args.

Good point. I can send a patch for that, too.

-- 
Sakari Ailus

Re: [PATCH AUTOSEL 5.4 08/10] selftests/bpf: Fix array access with signed variable test

[Jean-Philippe Brucker]

Hi,

On Sat, Dec 19, 2020 at 10:34:55PM -0500, Sasha Levin wrote:
> From: Jean-Philippe Brucker 
> 
> [ Upstream commit 77ce220c0549dcc3db8226c61c60e83fc59dfafc ]
> 
> The test fails because of a recent fix to the verifier, even though this

That fix is commit b02709587ea3 ("bpf: Fix propagation of 32-bit signed
bounds from 64-bit bounds.") upstream, which only needed backport to 5.9.
So although backporting this patch to 5.4 shouldn't break anything, I
wouldn't bother. 

Thanks,
Jean

> program is valid. In details what happens is:
> 
> 7: (61) r1 = *(u32 *)(r0 +0)
> 
> Load a 32-bit value, with signed bounds [S32_MIN, S32_MAX]. The bounds
> of the 64-bit value are [0, U32_MAX]...
> 
> 8: (65) if r1 s> 0x goto pc+1
> 
> ... therefore this is always true (the operand is sign-extended).
> 
> 10: (b4) w2 = 11
> 11: (6d) if r2 s> r1 goto pc+1
> 
> When true, the 64-bit bounds become [0, 10]. The 32-bit bounds are still
> [S32_MIN, 10].
> 
> 13: (64) w1 <<= 2
> 
> Because this is a 32-bit operation, the verifier propagates the new
> 32-bit bounds to the 64-bit ones, and the knowledge gained from insn 11
> is lost.
> 
> 14: (0f) r0 += r1
> 15: (7a) *(u64 *)(r0 +0) = 4
> 
> Then the verifier considers r0 unbounded here, rejecting the test. To
> make the test work, change insn 8 to check the sign of the 32-bit value.
> 
> Signed-off-by: Jean-Philippe Brucker 
> Acked-by: John Fastabend 
> Signed-off-by: Alexei Starovoitov 
> Signed-off-by: Sasha Levin 
> ---
>  tools/testing/selftests/bpf/verifier/array_access.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/testing/selftests/bpf/verifier/array_access.c 
> b/tools/testing/selftests/bpf/verifier/array_access.c
> index f3c33e128709b..a80d806ead15f 100644
> --- a/tools/testing/selftests/bpf/verifier/array_access.c
> +++ b/tools/testing/selftests/bpf/verifier/array_access.c
> @@ -68,7 +68,7 @@
>   BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem),
>   BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 9),
>   BPF_LDX_MEM(BPF_W, BPF_REG_1, BPF_REG_0, 0),
> - BPF_JMP_IMM(BPF_JSGT, BPF_REG_1, 0x, 1),
> + BPF_JMP32_IMM(BPF_JSGT, BPF_REG_1, 0x, 1),
>   BPF_MOV32_IMM(BPF_REG_1, 0),
>   BPF_MOV32_IMM(BPF_REG_2, MAX_ENTRIES),
>   BPF_JMP_REG(BPF_JSGT, BPF_REG_2, BPF_REG_1, 1),
> -- 
> 2.27.0
> 

[PATCH v2] ovl: fix dentry leak in ovl_get_redirect

[Liangyan]

We need to lock d_parent->d_lock before dget_dlock, or this may
have d_lockref updated parallelly like calltrace below which will
cause dentry->d_lockref leak and risk a crash.

npm-20576 [028]  5705749.040094:
[28] ovl_set_redirect+0x11c/0x310 //tmp = dget_dlock(d->d_parent);
[28]?  ovl_set_redirect+0x5/0x310
[28] ovl_rename+0x4db/0x790 [overlay]
[28] vfs_rename+0x6e8/0x920
[28] do_renameat2+0x4d6/0x560
[28] __x64_sys_rename+0x1c/0x20
[28] do_syscall_64+0x55/0x1a0
[28] entry_SYSCALL_64_after_hwframe+0x44/0xa9

npm-20574 [036]  5705749.040094:
[36] __d_lookup+0x107/0x140 //dentry->d_lockref.count++;
[36] lookup_fast+0xe0/0x2d0
[36] walk_component+0x48/0x350
[36] link_path_walk+0x1bf/0x650
[36]?  path_init+0x1f6/0x2f0
[36] path_lookupat+0x82/0x210
[36] filename_lookup+0xb8/0x1a0
[36]?  __audit_getname+0xa2/0xb0
[36]?  getname_flags+0xb9/0x1e0
[36]?  vfs_statx+0x73/0xe0
[36] vfs_statx+0x73/0xe0
[36] __do_sys_statx+0x3b/0x80
[36]?  syscall_trace_enter+0x1ae/0x2c0
[36] do_syscall_64+0x55/0x1a0
[36] entry_SYSCALL_64_

[   49.799059] PGD 80061fed7067 P4D 80061fed7067 PUD 61fec5067 PMD 0
[   49.799689] Oops: 0002 [#1] SMP PTI
[   49.800019] CPU: 2 PID: 2332 Comm: node Not tainted 4.19.24-7.20.al7.x86_64 
#1
[   49.800678] Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 8a46cfe 
04/01/2014
[   49.801380] RIP: 0010:_raw_spin_lock+0xc/0x20
[   49.803470] RSP: 0018:ac6fc5417e98 EFLAGS: 00010246
[   49.803949] RAX:  RBX: 93b8da3446c0 RCX: 000a
[   49.804600] RDX: 0001 RSI: 000a RDI: 0088
[   49.805252] RBP:  R08:  R09: 993cf040
[   49.805898] R10: 93b92292e580 R11: d27f188a4b80 R12: 
[   49.806548] R13: ff9c R14: fffe R15: 93b8da3446c0
[   49.807200] FS:  7ffbedffb700() GS:93b92788() 
knlGS:
[   49.807935] CS:  0010 DS:  ES:  CR0: 80050033
[   49.808461] CR2: 0088 CR3: 0005e3f74006 CR4: 003606a0
[   49.809113] DR0:  DR1:  DR2: 
[   49.809758] DR3:  DR6: fffe0ff0 DR7: 0400
[   49.810410] Call Trace:
[   49.810653]  d_delete+0x2c/0xb0
[   49.810951]  vfs_rmdir+0xfd/0x120
[   49.811264]  do_rmdir+0x14f/0x1a0
[   49.811573]  do_syscall_64+0x5b/0x190
[   49.811917]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   49.812385] RIP: 0033:0x7ffbf505ffd7
[   49.814404] RSP: 002b:7ffbedffada8 EFLAGS: 0297 ORIG_RAX: 
0054
[   49.815098] RAX: ffda RBX: 7ffbedffb640 RCX: 7ffbf505ffd7
[   49.815744] RDX: 04449700 RSI:  RDI: 06c8cd50
[   49.816394] RBP: 7ffbedffaea0 R08:  R09: 00017d0b
[   49.817038] R10:  R11: 0297 R12: 0012
[   49.817687] R13: 072823d8 R14: 7ffbedffb700 R15: 072823d8
[   49.818338] Modules linked in: pvpanic cirrusfb button qemu_fw_cfg atkbd 
libps2 i8042
[   49.819052] CR2: 0088
[   49.819368] ---[ end trace 4e652b8aa299aa2d ]---
[   49.819796] RIP: 0010:_raw_spin_lock+0xc/0x20
[   49.821880] RSP: 0018:ac6fc5417e98 EFLAGS: 00010246
[   49.822363] RAX:  RBX: 93b8da3446c0 RCX: 000a
[   49.823008] RDX: 0001 RSI: 000a RDI: 0088
[   49.823658] RBP:  R08:  R09: 993cf040
[   49.825404] R10: 93b92292e580 R11: d27f188a4b80 R12: 
[   49.827147] R13: ff9c R14: fffe R15: 93b8da3446c0
[   49.828890] FS:  7ffbedffb700() GS:93b92788() 
knlGS:
[   49.830725] CS:  0010 DS:  ES:  CR0: 80050033
[   49.832359] CR2: 0088 CR3: 0005e3f74006 CR4: 003606a0
[   49.834085] DR0:  DR1:  DR2: 
[   49.835792] DR3:  DR6: fffe0ff0 DR7: 0400

Fixes: a6c606551141 ("ovl: redirect on rename-dir")
Signed-off-by: Liangyan 
Suggested-by: Joseph Qi 
---
 fs/overlayfs/dir.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/fs/overlayfs/dir.c b/fs/overlayfs/dir.c
index 28a075b5f5b2..a78d35017371 100644
--- a/fs/overlayfs/dir.c
+++ b/fs/overlayfs/dir.c
@@ -973,6 +973,7 @@ static char *ovl_get_redirect(struct dentry *dentry, bool 
abs_redirect)
for (d = dget(dentry); !IS_ROOT(d);) {
const char *name;
int thislen;
+   struct dentry *parent = NULL;
 
spin_lock(&d->d_lock);
name = ovl_dentry_get_redirect(d);
@@ -992,7 +993,22 @@ static char *ovl_get_redirect(struct dentry *dentry, bool 
abs_redirect)
 
buflen -= thislen;
memcpy(&buf[buflen], name, thislen);
-   tmp = dget_dlock(

Re: [-next] mt76: mt7915: fix MESH ifdef block

[Kalle Valo]

Randy Dunlap  wrote:

> Fix a build error when CONFIG_MAC80211_MESH is not enabled:
> 
> ../drivers/net/wireless/mediatek/mt76/mt7915/init.c:47:2: error: expected 
> expression before '}' token
>   }, {
>   ^
> 
> Fixes: af901eb4ab80 ("mt76: mt7915: get rid of dbdc debugfs knob")
> Signed-off-by: Randy Dunlap 
> Cc: Shayne Chen 
> Cc: Ryder Lee 
> Cc: Lorenzo Bianconi 
> Cc: Felix Fietkau 
> Cc: linux-wirel...@vger.kernel.org
> Cc: Kalle Valo 

Patch applied to wireless-drivers.git, thanks.

0bd157fa2aaa mt76: mt7915: fix MESH ifdef block

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/20201218173202.23159-1-rdun...@infradead.org/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

[PATCH] net/ncsi: Use real net-device for response handler

[John Wang]

When aggregating ncsi interfaces and dedicated interfaces to bond
interfaces, the ncsi response handler will use the wrong net device to
find ncsi_dev, so that the ncsi interface will not work properly.
Here, we use the net device registered to packet_type to fix it.

Fixes: 138635cc27c9 ("net/ncsi: NCSI response packet handler")
Signed-off-by: John Wang 
---
 net/ncsi/ncsi-rsp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ncsi/ncsi-rsp.c b/net/ncsi/ncsi-rsp.c
index a94bb59793f0..60ae32682904 100644
--- a/net/ncsi/ncsi-rsp.c
+++ b/net/ncsi/ncsi-rsp.c
@@ -1120,7 +1120,7 @@ int ncsi_rcv_rsp(struct sk_buff *skb, struct net_device 
*dev,
int payload, i, ret;
 
/* Find the NCSI device */
-   nd = ncsi_find_dev(dev);
+   nd = ncsi_find_dev(pt->dev);
ndp = nd ? TO_NCSI_DEV_PRIV(nd) : NULL;
if (!ndp)
return -ENODEV;
-- 
2.25.1

Re: [RFC] exit: do exit_task_work() before shooting off mm

[Pavel Begunkov]

On 08/12/2020 01:37, Al Viro wrote:
> On Thu, Dec 03, 2020 at 02:30:46AM +, Pavel Begunkov wrote:
>> Handle task works and lock it earlier before it starts killing off
>> task's resources like mm. io_uring makes use of it a lot and it'd
>> nicer to have all added task_work finding tasks in a consistent state.
>>
>> Signed-off-by: Pavel Begunkov 
>> ---
>>
>> Would it be correct? I clearly don't know all the exit invariants, but
>> can't find any users relying on task_works in-between.
> 
> You've just gotten rid of exit_task_work() anywhere after exit_files().
> And exit_mm() can trigger the final fput() just as easily as exit_files().
> 
> IOW, you have just made the effect of final close on exit() completely
> asynchronous.

One more moment, after we've set PF_EXITING any task_work_run() would be
equivalent to exit_task_work()

static inline void exit_task_work(struct task_struct *task)
{
   task_work_run();
}

It sounds from your words that this is not expected, is it? io_uring
may want (currently doesn't) to run works for cancellation purposes.
Shouldn't it be like below (not tested)? Also simplifies task_work_run().

CC Oleg

diff --git a/include/linux/task_work.h b/include/linux/task_work.h
index 0d848a1e9e62..6aae0e6c3a04 100644
--- a/include/linux/task_work.h
+++ b/include/linux/task_work.h
@@ -24,10 +24,6 @@ int task_work_add(struct task_struct *task, struct 
callback_head *twork,
 
 struct callback_head *task_work_cancel(struct task_struct *, task_work_func_t);
 void task_work_run(void);
-
-static inline void exit_task_work(struct task_struct *task)
-{
-   task_work_run();
-}
+void exit_task_work(struct task_struct *task);
 
 #endif /* _LINUX_TASK_WORK_H */
diff --git a/kernel/task_work.c b/kernel/task_work.c
index 9cde961875c0..60715f3d91a0 100644
--- a/kernel/task_work.c
+++ b/kernel/task_work.c
@@ -107,26 +107,15 @@ task_work_cancel(struct task_struct *task, 
task_work_func_t func)
 void task_work_run(void)
 {
struct task_struct *task = current;
-   struct callback_head *work, *head, *next;
+   struct callback_head *work, *next;
 
for (;;) {
-   /*
-* work->func() can do task_work_add(), do not set
-* work_exited unless the list is empty.
-*/
do {
-   head = NULL;
work = READ_ONCE(task->task_works);
-   if (!work) {
-   if (task->flags & PF_EXITING)
-   head = &work_exited;
-   else
-   break;
-   }
-   } while (cmpxchg(&task->task_works, work, head) != work);
+   if (!work)
+   return;
+   } while (cmpxchg(&task->task_works, work, NULL) != work);
 
-   if (!work)
-   break;
/*
 * Synchronize with task_work_cancel(). It can not remove
 * the first entry == work, cmpxchg(task_works) must fail.
@@ -143,3 +132,17 @@ void task_work_run(void)
} while (work);
}
 }
+
+void exit_task_work(struct task_struct *task)
+{
+   WARN_ON(task != current);
+   WARN_ON(!(task->flags & PF_EXITING));
+   WARN_ON(READ_ONCE(task->task_works) == &work_exited);
+
+   /*
+* work->func() can do task_work_add(), do not set
+* work_exited unless the list is empty.
+*/
+   while (cmpxchg(&task->task_works, NULL, &work_exited) != NULL)
+   task_work_run();
+}

-- 
Pavel Begunkov

KASAN: global-out-of-bounds Read in smc_nl_get_sys_info

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:3db1a3fa Merge tag 'staging-5.11-rc1' of git://git.kernel...
git tree:   net
console output: https://syzkaller.appspot.com/x/log.txt?x=121dc93750
kernel config:  https://syzkaller.appspot.com/x/.config?x=2764fc28a92339f9
dashboard link: https://syzkaller.appspot.com/bug?extid=f4708c391121cfc58396
compiler:   gcc (GCC) 10.1.0-syz 20200507
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1652228750
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1144680f50

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

==
BUG: KASAN: global-out-of-bounds in string_nocheck lib/vsprintf.c:611 [inline]
BUG: KASAN: global-out-of-bounds in string+0x39c/0x3d0 lib/vsprintf.c:693
Read of size 1 at addr 8faea960 by task syz-executor646/8509

CPU: 0 PID: 8509 Comm: syz-executor646 Not tainted 5.10.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:79 [inline]
 dump_stack+0x107/0x163 lib/dump_stack.c:120
 print_address_description.constprop.0.cold+0x5/0x4c8 mm/kasan/report.c:385
 __kasan_report mm/kasan/report.c:545 [inline]
 kasan_report.cold+0x1f/0x37 mm/kasan/report.c:562
 string_nocheck lib/vsprintf.c:611 [inline]
 string+0x39c/0x3d0 lib/vsprintf.c:693
 vsnprintf+0x71b/0x14f0 lib/vsprintf.c:2618
 snprintf+0xbb/0xf0 lib/vsprintf.c:2751
 smc_nl_get_sys_info+0x493/0x880 net/smc/smc_core.c:249
 genl_lock_dumpit+0x60/0x90 net/netlink/genetlink.c:623
 netlink_dump+0x4b9/0xb70 net/netlink/af_netlink.c:2268
 __netlink_dump_start+0x642/0x900 net/netlink/af_netlink.c:2373
 genl_family_rcv_msg_dumpit+0x2af/0x310 net/netlink/genetlink.c:686
 genl_family_rcv_msg net/netlink/genetlink.c:780 [inline]
 genl_rcv_msg+0x434/0x580 net/netlink/genetlink.c:800
 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2494
 genl_rcv+0x24/0x40 net/netlink/genetlink.c:811
 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline]
 netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1330
 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1919
 sock_sendmsg_nosec net/socket.c:652 [inline]
 sock_sendmsg+0xcf/0x120 net/socket.c:672
 sys_sendmsg+0x6e8/0x810 net/socket.c:2336
 ___sys_sendmsg+0xf3/0x170 net/socket.c:2390
 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2423
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x440299
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 
7b 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7fff4b943e58 EFLAGS: 0246 ORIG_RAX: 002e
RAX: ffda RBX: 004002c8 RCX: 00440299
RDX:  RSI: 2180 RDI: 0003
RBP: 006ca018 R08:  R09: 004002c8
R10:  R11: 0246 R12: 00401aa0
R13: 00401b30 R14:  R15: 

The buggy address belongs to the variable:
 smc_hostname+0x20/0x40

Memory state around the buggy address:
 8faea800: 00 00 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9
 8faea880: 00 00 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9
>8faea900: 00 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 f9 f9 f9 f9
   ^
 8faea980: 04 f9 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9
 8faeaa00: 00 00 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9
==


---
This report 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 issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches

Re: general protection fault in j1939_netdev_notify (2)

[Oliver Hartkopp]

Hello Oleksij,

I assume there is some ndev->ml_priv value set - but not from a CAN 
netdevice.


What was the reason to fiddle with the 'priv' stuff in 
j1939_netdev_notify() before checking if it was a CAN device?


Would this patch fix the issue then?

diff --git a/net/can/j1939/main.c b/net/can/j1939/main.c
index bb914d8b4216..6940f98b81fb 100644
--- a/net/can/j1939/main.c
+++ b/net/can/j1939/main.c
@@ -348,26 +348,25 @@ static int j1939_netdev_notify(struct 
notifier_block *nb,

   unsigned long msg, void *data)
 {
struct net_device *ndev = netdev_notifier_info_to_dev(data);
struct j1939_priv *priv;

+   if (ndev->type != ARPHRD_CAN)
+   goto notify_done;
+
priv = j1939_priv_get_by_ndev(ndev);
if (!priv)
goto notify_done;

-   if (ndev->type != ARPHRD_CAN)
-   goto notify_put;
-
switch (msg) {
case NETDEV_DOWN:
j1939_cancel_active_session(priv, NULL);
j1939_sk_netdev_event_netdown(priv);
j1939_ecu_unmap_all(priv);
break;
}

-notify_put:
j1939_priv_put(priv);

 notify_done:
return NOTIFY_DONE;
 }

If so, I can send a proper patch if you like.

Best regards,
Oliver


On 20.12.20 06:34, syzbot wrote:

Hello,

syzbot found the following issue on:

HEAD commit:d635a69d Merge tag 'net-next-5.11' of git://git.kernel.org..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1315f12350
kernel config:  https://syzkaller.appspot.com/x/.config?x=c3556e4856b17a95
dashboard link: https://syzkaller.appspot.com/bug?extid=5138c4dd15a0401bec7b
compiler:   clang version 11.0.0 (https://github.com/llvm/llvm-project.git 
ca2dcbd030eadbf0aa9b660efe864ff08af6e18b)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1295512350
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=10f2f30f50

The issue was bisected to:

commit 497a5757ce4e8f37219a3989ac6a561eb9a8e6c7
Author: Heiner Kallweit 
Date:   Sat Nov 7 20:50:56 2020 +

 tun: switch to net core provided statistics counters

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=143b845b50
final oops: https://syzkaller.appspot.com/x/report.txt?x=163b845b50
console output: https://syzkaller.appspot.com/x/log.txt?x=123b845b50

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+5138c4dd15a0401be...@syzkaller.appspotmail.com
Fixes: 497a5757ce4e ("tun: switch to net core provided statistics counters")

general protection fault, probably for non-canonical address 
0xe80fe8c072f1:  [#1] PREEMPT SMP KASAN
KASAN: probably user-memory-access in range 
[0x607f46039788-0x607f4603978f]
CPU: 1 PID: 8472 Comm: syz-executor635 Not tainted 5.10.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
RIP: 0010:j1939_ndev_to_priv net/can/j1939/main.c:219 [inline]
RIP: 0010:j1939_priv_get_by_ndev_locked net/can/j1939/main.c:231 [inline]
RIP: 0010:j1939_priv_get_by_ndev net/can/j1939/main.c:243 [inline]
RIP: 0010:j1939_netdev_notify+0x115/0x320 net/can/j1939/main.c:353
Code: 00 74 08 48 89 df e8 ba 1e 48 f9 48 8b 1b 48 85 db 0f 84 f0 00 00 00 4c 89 64 
24 08 48 81 c3 28 60 00 00 48 89 d8 48 c1 e8 03 <42> 80 3c 30 00 74 08 48 89 df 
e8 8c 1e 48 f9 4c 8b 23 4d 85 e4 0f
RSP: 0018:c9e9fd68 EFLAGS: 00010202
RAX: 0c0fe8c072f1 RBX: 607f46039788 RCX: 88801456d040
RDX: 88801456d040 RSI: 0118 RDI: 0118
RBP: 0118 R08: 8870585d R09: f520001d3fa5
R10: f520001d3fa5 R11:  R12: 0010
R13: 11100293e848 R14: dc00 R15: 8880149f4244
FS:  01d13880() GS:8880b9d0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 2080 CR3: 1402f000 CR4: 001506e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
  notifier_call_chain kernel/notifier.c:83 [inline]
  raw_notifier_call_chain+0xe7/0x170 kernel/notifier.c:410
  call_netdevice_notifiers_info net/core/dev.c:2022 [inline]
  call_netdevice_notifiers_extack net/core/dev.c:2034 [inline]
  call_netdevice_notifiers+0xeb/0x150 net/core/dev.c:2048
  __tun_chr_ioctl+0x2337/0x4860 drivers/net/tun.c:3093
  vfs_ioctl fs/ioctl.c:48 [inline]
  __do_sys_ioctl fs/ioctl.c:753 [inline]
  __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:739
  do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
  entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x440359
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 
48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b 13 
fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7fffd37b9c98 EFLAGS: 0246 ORIG_

Re: general protection fault in rose_send_frame

[syzbot]

syzbot suspects this issue was fixed by commit:

commit 3b3fd068c56e3fbea30090859216a368398e39bf
Author: Anmol Karn 
Date:   Thu Nov 19 19:10:43 2020 +

rose: Fix Null pointer dereference in rose_send_frame()

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=139e2b9b50
start commit:   23ee3e4e Merge tag 'pci-v5.8-fixes-2' of git://git.kernel...
git tree:   upstream
kernel config:  https://syzkaller.appspot.com/x/.config?x=f87a5e4232fdb267
dashboard link: https://syzkaller.appspot.com/bug?extid=7078ae989d857fe17988
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=157e896490
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=10046c5490

If the result looks correct, please mark the issue as fixed by replying with:

#syz fix: rose: Fix Null pointer dereference in rose_send_frame()

For information about bisection process see: https://goo.gl/tpsmEJ#bisection

Re: [PATCH] hwrng: ingenic - Fix a resource leak in an error handling path

[Zhou Yanjie]

Hi Christophe,

On 2020/12/19 下午3:52, Christophe JAILLET wrote:

In case of error, we should call 'clk_disable_unprepare()' to undo a
previous 'clk_prepare_enable()' call, as already done in the remove
function.

Fixes: 406346d22278 ("hwrng: ingenic - Add hardware TRNG for Ingenic X1830")
Signed-off-by: Christophe JAILLET 
---
  drivers/char/hw_random/ingenic-trng.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)



Thanks for fixing it, and apologize for my carelessness.

Tested-by: 周琰杰 (Zhou Yanjie) 



diff --git a/drivers/char/hw_random/ingenic-trng.c 
b/drivers/char/hw_random/ingenic-trng.c
index 954a8411d67d..0eb80f786f4d 100644
--- a/drivers/char/hw_random/ingenic-trng.c
+++ b/drivers/char/hw_random/ingenic-trng.c
@@ -113,13 +113,17 @@ static int ingenic_trng_probe(struct platform_device 
*pdev)
ret = hwrng_register(&trng->rng);
if (ret) {
dev_err(&pdev->dev, "Failed to register hwrng\n");
-   return ret;
+   goto err_unprepare_clk;
}
  
  	platform_set_drvdata(pdev, trng);
  
  	dev_info(&pdev->dev, "Ingenic DTRNG driver registered\n");

return 0;
+
+err_unprepare_clk:
+   clk_disable_unprepare(trng->clk);
+   return ret;
  }
  
  static int ingenic_trng_remove(struct platform_device *pdev)

Re: [PATCH 5.10 00/16] 5.10.2-rc1 review

[Jon Hunter]

On 19/12/2020 12:57, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.2 release.
> There are 16 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Mon, 21 Dec 2020 12:53:29 +.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.2-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-5.10.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h


Test results for stable-v5.10:
12 builds:  12 pass, 0 fail
26 boots:   26 pass, 0 fail
64 tests:   63 pass, 1 fail

Linux version:  5.10.2-rc1-gc96cfd687a3f
Boards tested:  tegra124-jetson-tk1, tegra186-p2771-,
tegra194-p2972-, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-,
tegra30-cardhu-a04

Test failures:  tegra194-p2972-: boot.py


Same warning failure as before. The fix for this is now in the mainline
if you would like to pick it up ...

commit c9f64d1fc101c64ea2be1b2e562b4395127befc9
Author: Thierry Reding 
Date:   Tue Nov 10 08:37:57 2020 +0100

net: ipconfig: Avoid spurious blank lines in boot log


Otherwise ...

Tested-by: Jon Hunter 

Cheers
Jon

-- 
nvpublic

Re: [RFC] exit: do exit_task_work() before shooting off mm

[Oleg Nesterov]

On 12/20, Pavel Begunkov wrote:
>
> On 08/12/2020 01:37, Al Viro wrote:
> > On Thu, Dec 03, 2020 at 02:30:46AM +, Pavel Begunkov wrote:
> >> Handle task works and lock it earlier before it starts killing off
> >> task's resources like mm. io_uring makes use of it a lot and it'd
> >> nicer to have all added task_work finding tasks in a consistent state.

I too do not understand this patch. task_work_add() will fail after
exit_task_work(). This means that, for example, exit_files() will use
schedule_delayed_work().

> One more moment, after we've set PF_EXITING any task_work_run() would be
> equivalent to exit_task_work()

Yes, currently task_work_run() can not be called after exit_signals().
And shouldn't be called imo ;)

> io_uring
> may want (currently doesn't) to run works for cancellation purposes.

Please see https://lore.kernel.org/io-uring/20200407163816.gb9...@redhat.com/

> Shouldn't it be like below (not tested)? Also simplifies task_work_run().

I'd prefer the patch from the link above, but your version looks correct too.
However, I still think it would be better to not abuse task_work_run() too
much...

Oleg.

Re: [PATCH 1/1] v4l: ioctl: Fix memory leak in video_usercopy

[Laurent Pinchart]

Hi Sakari,

Thank you for the patch.

On Sun, Dec 20, 2020 at 01:06:51PM +0200, Sakari Ailus wrote:
> When an IOCTL with argument size larger than 128 that also used array
> arguments were handled, two memory allocations were made but alas, only
> the latter one of them was released.

Alas, this fills my heart with sorrow indeed :-)

> This happened because there was only
> a single local variable to hold such a temporary allocation.
> 
> Fix this by adding separate variables to hold the pointers to the
> temporary allocations.
> 
> Reported-by: Arnd Bergmann 
> Reported-by: syzbot+1115e79c8df6472c6...@syzkaller.appspotmail.com
> Fixes: d14e6d76ebf7 ("[media] v4l: Add multi-planar ioctl handling code")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Sakari Ailus 
> ---
>  drivers/media/v4l2-core/v4l2-ioctl.c | 31 +---
>  1 file changed, 14 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
> b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 3198abdd538ce..f42a779948779 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -3283,7 +3283,7 @@ video_usercopy(struct file *file, unsigned int 
> orig_cmd, unsigned long arg,
>  v4l2_kioctl func)
>  {
>   charsbuf[128];
> - void*mbuf = NULL;
> + void*mbuf = NULL, *array_buf = NULL;
>   void*parg = (void *)arg;
>   longerr  = -EINVAL;
>   boolhas_array_args;
> @@ -3318,27 +3318,21 @@ video_usercopy(struct file *file, unsigned int 
> orig_cmd, unsigned long arg,
>   has_array_args = err;
>  
>   if (has_array_args) {
> - /*
> -  * When adding new types of array args, make sure that the
> -  * parent argument to ioctl (which contains the pointer to the
> -  * array) fits into sbuf (so that mbuf will still remain
> -  * unused up to here).
> -  */
> - mbuf = kvmalloc(array_size, GFP_KERNEL);
> + array_buf = kvmalloc(array_size, GFP_KERNEL);
>   err = -ENOMEM;
> - if (NULL == mbuf)
> + if (array_buf == NULL)
>   goto out_array_args;
>   err = -EFAULT;
>   if (in_compat_syscall())
> - err = v4l2_compat_get_array_args(file, mbuf, user_ptr,
> -  array_size, orig_cmd,
> -  parg);
> + err = v4l2_compat_get_array_args(file, array_buf,
> +  user_ptr, array_size,
> +  orig_cmd, parg);
>   else
> - err = copy_from_user(mbuf, user_ptr, array_size) ?
> + err = copy_from_user(array_buf, user_ptr, array_size) ?
>   -EFAULT : 0;
>   if (err)
>   goto out_array_args;
> - *kernel_ptr = mbuf;
> + *kernel_ptr = array_buf;
>   }
>  
>   /* Handles IOCTL */
> @@ -3360,12 +3354,14 @@ video_usercopy(struct file *file, unsigned int 
> orig_cmd, unsigned long arg,
>   if (in_compat_syscall()) {
>   int put_err;
>  
> - put_err = v4l2_compat_put_array_args(file, user_ptr, 
> mbuf,
> -  array_size, 
> orig_cmd,
> + put_err = v4l2_compat_put_array_args(file, user_ptr,
> +  array_buf,
> +  array_size,
> +  orig_cmd,
>parg);

orig_cmd and pargs would fit on the same line if you want to.

Reviewed-by: Laurent Pinchart 

>   if (put_err)
>   err = put_err;
> - } else if (copy_to_user(user_ptr, mbuf, array_size)) {
> + } else if (copy_to_user(user_ptr, array_buf, array_size)) {
>   err = -EFAULT;
>   }
>   goto out_array_args;
> @@ -3381,6 +3377,7 @@ video_usercopy(struct file *file, unsigned int 
> orig_cmd, unsigned long arg,
>   if (video_put_user((void __user *)arg, parg, cmd, orig_cmd))
>   err = -EFAULT;
>  out:
> + kvfree(array_buf);
>   kvfree(mbuf);
>   return err;
>  }

-- 
Regards,

Laurent Pinchart

Re: [PATCH] signal: Don't init struct kernel_siginfo fields to zero again

[Oleg Nesterov]

On 12/20, Leesoo Ahn wrote:
>
> clear_siginfo() is responsible for clearing struct kernel_siginfo object.
> It's obvious that manually initializing those fields is needless as
> a commit[1] explains why the function introduced and its guarantee that
> all bits in the struct are cleared after it.
>
> [1]: commit 8c5dbf2ae00b ("signal: Introduce clear_siginfo")
>
> Signed-off-by: Leesoo Ahn 

Acked-by: Oleg Nesterov 


> ---
>  kernel/signal.c | 21 -
>  1 file changed, 21 deletions(-)
> 
> diff --git a/kernel/signal.c b/kernel/signal.c
> index 5736c55aaa1a..8f49fa3ade33 100644
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -603,10 +603,7 @@ static void collect_signal(int sig, struct sigpending 
> *list, kernel_siginfo_t *i
>*/
>   clear_siginfo(info);
>   info->si_signo = sig;
> - info->si_errno = 0;
>   info->si_code = SI_USER;
> - info->si_pid = 0;
> - info->si_uid = 0;
>   }
>  }
>  
> @@ -1120,7 +1117,6 @@ static int __send_signal(int sig, struct kernel_siginfo 
> *info, struct task_struc
>   case (unsigned long) SEND_SIG_NOINFO:
>   clear_siginfo(&q->info);
>   q->info.si_signo = sig;
> - q->info.si_errno = 0;
>   q->info.si_code = SI_USER;
>   q->info.si_pid = task_tgid_nr_ns(current,
>   task_active_pid_ns(t));
> @@ -1133,10 +1129,7 @@ static int __send_signal(int sig, struct 
> kernel_siginfo *info, struct task_struc
>   case (unsigned long) SEND_SIG_PRIV:
>   clear_siginfo(&q->info);
>   q->info.si_signo = sig;
> - q->info.si_errno = 0;
>   q->info.si_code = SI_KERNEL;
> - q->info.si_pid = 0;
> - q->info.si_uid = 0;
>   break;
>   default:
>   copy_siginfo(&q->info, info);
> @@ -1623,10 +1616,7 @@ void force_sig(int sig)
>  
>   clear_siginfo(&info);
>   info.si_signo = sig;
> - info.si_errno = 0;
>   info.si_code = SI_KERNEL;
> - info.si_pid = 0;
> - info.si_uid = 0;
>   force_sig_info(&info);
>  }
>  EXPORT_SYMBOL(force_sig);
> @@ -1659,7 +1649,6 @@ int force_sig_fault_to_task(int sig, int code, void 
> __user *addr
>  
>   clear_siginfo(&info);
>   info.si_signo = sig;
> - info.si_errno = 0;
>   info.si_code  = code;
>   info.si_addr  = addr;
>  #ifdef __ARCH_SI_TRAPNO
> @@ -1691,7 +1680,6 @@ int send_sig_fault(int sig, int code, void __user *addr
>  
>   clear_siginfo(&info);
>   info.si_signo = sig;
> - info.si_errno = 0;
>   info.si_code  = code;
>   info.si_addr  = addr;
>  #ifdef __ARCH_SI_TRAPNO
> @@ -1712,7 +1700,6 @@ int force_sig_mceerr(int code, void __user *addr, short 
> lsb)
>   WARN_ON((code != BUS_MCEERR_AO) && (code != BUS_MCEERR_AR));
>   clear_siginfo(&info);
>   info.si_signo = SIGBUS;
> - info.si_errno = 0;
>   info.si_code = code;
>   info.si_addr = addr;
>   info.si_addr_lsb = lsb;
> @@ -1726,7 +1713,6 @@ int send_sig_mceerr(int code, void __user *addr, short 
> lsb, struct task_struct *
>   WARN_ON((code != BUS_MCEERR_AO) && (code != BUS_MCEERR_AR));
>   clear_siginfo(&info);
>   info.si_signo = SIGBUS;
> - info.si_errno = 0;
>   info.si_code = code;
>   info.si_addr = addr;
>   info.si_addr_lsb = lsb;
> @@ -1740,7 +1726,6 @@ int force_sig_bnderr(void __user *addr, void __user 
> *lower, void __user *upper)
>  
>   clear_siginfo(&info);
>   info.si_signo = SIGSEGV;
> - info.si_errno = 0;
>   info.si_code  = SEGV_BNDERR;
>   info.si_addr  = addr;
>   info.si_lower = lower;
> @@ -1755,7 +1740,6 @@ int force_sig_pkuerr(void __user *addr, u32 pkey)
>  
>   clear_siginfo(&info);
>   info.si_signo = SIGSEGV;
> - info.si_errno = 0;
>   info.si_code  = SEGV_PKUERR;
>   info.si_addr  = addr;
>   info.si_pkey  = pkey;
> @@ -1934,7 +1918,6 @@ bool do_notify_parent(struct task_struct *tsk, int sig)
>  
>   clear_siginfo(&info);
>   info.si_signo = sig;
> - info.si_errno = 0;
>   /*
>* We are under tasklist_lock here so our parent is tied to
>* us and cannot change.
> @@ -2033,7 +2016,6 @@ static void do_notify_parent_cldstop(struct task_struct 
> *tsk,
>  
>   clear_siginfo(&info);
>   info.si_signo = SIGCHLD;
> - info.si_errno = 0;
>   /*
>* see comment in do_notify_parent() about the following 4 lines
>*/
> @@ -2506,7 +2488,6 @@ static int ptrace_signal(int signr, kernel_siginfo_t 
> *info)
>   if (signr != info->si_signo) {
>   clear_siginfo(info);
>   info->si_signo = signr;
> - info->si_errno = 0;
>   info->si_code = SI_USER;
>  

RE: [RFC PATCH 0/13] sparc32: sunset sun4m and sun4d

[David Laight]

From: Julian Calaby
> Sent: 20 December 2020 08:55
> 
> On Sun, Dec 20, 2020 at 6:46 PM Romain Dolbeau  wrote:
> >
> > Le sam. 19 déc. 2020 à 22:41, Sam Ravnborg  a écrit :
> > > Another said that it would be a shame to sunset sun4m and sun4d because
> > > there are so many machines around, and netbsd is also active on the
> > > sparc32 area.

The advantage of netbsd is that the build gives you a kernel and userspace
from the same source tree and it is designed to cross build.
Even the compilers get built - so all you need is a native compiler
that will compile the (probably slightly older) version of gcc.
This used to be problematic because gcc sources tended to use gcc-only
features (which have been deprecated).

The userspace will also be a lot less bloated than a typical Linux,
but more complete than the 'busybox' tools often used on small/embedded
Linux systems.

> > Yes, those were plentiful back in the day and there's still quite a few 
> > around.
> 
> I have three: two SparcStation 10s and a SparcStation LX.
> 
> If I want to run them, assuming the hardware still works, I need to
> netboot them as I cannot find working, compatible HDDs for them as
> everything has switched to SATA or SAS.

I trashed the PSU on my sun3 trying to get netboot to work.
The main problem seemed to be that the switching fet wasn't
actually rated for 240v input! (needs to be a 400v device).

I never did get around to connecting an ATX psu up to the connector.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)

Re: [PATCH] m68k: Enable seccomp architecture tracking

[Geert Uytterhoeven]

Hi Adrian,

On Sun, Dec 20, 2020 at 12:24 PM John Paul Adrian Glaubitz
 wrote:
> On 12/20/20 9:51 AM, Geert Uytterhoeven wrote:
> > To enable seccomp constant action bitmaps, we need to have a static
> > mapping to the audit architecture and system call table size.
> >
> > Signed-off-by: Geert Uytterhoeven 
> > ---
> > Needed for CONFIG_SECCOMP_CACHE_DEBUG.
> > Note that upstream doesn't have m68k seccomp support yet.
>
> Have we added SECCOMP support for m68k to the kernel yet?

No, but I have applied locally the patches floating on the list...

> It's actually something I was hoping to do over the holidays ;-).

Happy to hear that!

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: general protection fault in j1939_netdev_notify (2)

[Oleksij Rempel]

Hello Oliver,

On Sun, Dec 20, 2020 at 02:18:27PM +0100, Oliver Hartkopp wrote:
> Hello Oleksij,
> 
> I assume there is some ndev->ml_priv value set - but not from a CAN
> netdevice.

it is kind of CAN device :)

> What was the reason to fiddle with the 'priv' stuff in j1939_netdev_notify()
> before checking if it was a CAN device?
> 
> Would this patch fix the issue then?

No, j1939_priv_get_by_ndev() already has an internal test for
ARPHRD_CAN. One of this tests can be removed, to make the code clear.
So, we get netdev with ARPHRD_CAN and ml_priv == something.

Right now I do not know how to fix it.

Ideas?

> diff --git a/net/can/j1939/main.c b/net/can/j1939/main.c
> index bb914d8b4216..6940f98b81fb 100644
> --- a/net/can/j1939/main.c
> +++ b/net/can/j1939/main.c
> @@ -348,26 +348,25 @@ static int j1939_netdev_notify(struct notifier_block
> *nb,
>  unsigned long msg, void *data)
>  {
>   struct net_device *ndev = netdev_notifier_info_to_dev(data);
>   struct j1939_priv *priv;
> 
> + if (ndev->type != ARPHRD_CAN)
> + goto notify_done;
> +
>   priv = j1939_priv_get_by_ndev(ndev);
>   if (!priv)
>   goto notify_done;
> 
> - if (ndev->type != ARPHRD_CAN)
> - goto notify_put;
> -
>   switch (msg) {
>   case NETDEV_DOWN:
>   j1939_cancel_active_session(priv, NULL);
>   j1939_sk_netdev_event_netdown(priv);
>   j1939_ecu_unmap_all(priv);
>   break;
>   }
> 
> -notify_put:
>   j1939_priv_put(priv);
> 
>  notify_done:
>   return NOTIFY_DONE;
>  }
> 
> If so, I can send a proper patch if you like.
> 
> Best regards,
> Oliver
> 
> 
> On 20.12.20 06:34, syzbot wrote:
> > Hello,
> > 
> > syzbot found the following issue on:
> > 
> > HEAD commit:d635a69d Merge tag 'net-next-5.11' of git://git.kernel.org..
> > git tree:   upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1315f12350
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=c3556e4856b17a95
> > dashboard link: https://syzkaller.appspot.com/bug?extid=5138c4dd15a0401bec7b
> > compiler:   clang version 11.0.0 
> > (https://github.com/llvm/llvm-project.git 
> > ca2dcbd030eadbf0aa9b660efe864ff08af6e18b)
> > syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1295512350
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=10f2f30f50
> > 
> > The issue was bisected to:
> > 
> > commit 497a5757ce4e8f37219a3989ac6a561eb9a8e6c7
> > Author: Heiner Kallweit 
> > Date:   Sat Nov 7 20:50:56 2020 +
> > 
> >  tun: switch to net core provided statistics counters
> > 
> > bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=143b845b50
> > final oops: https://syzkaller.appspot.com/x/report.txt?x=163b845b50
> > console output: https://syzkaller.appspot.com/x/log.txt?x=123b845b50
> > 
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+5138c4dd15a0401be...@syzkaller.appspotmail.com
> > Fixes: 497a5757ce4e ("tun: switch to net core provided statistics counters")
> > 
> > general protection fault, probably for non-canonical address 
> > 0xe80fe8c072f1:  [#1] PREEMPT SMP KASAN
> > KASAN: probably user-memory-access in range 
> > [0x607f46039788-0x607f4603978f]
> > CPU: 1 PID: 8472 Comm: syz-executor635 Not tainted 5.10.0-syzkaller #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS 
> > Google 01/01/2011
> > RIP: 0010:j1939_ndev_to_priv net/can/j1939/main.c:219 [inline]
> > RIP: 0010:j1939_priv_get_by_ndev_locked net/can/j1939/main.c:231 [inline]
> > RIP: 0010:j1939_priv_get_by_ndev net/can/j1939/main.c:243 [inline]
> > RIP: 0010:j1939_netdev_notify+0x115/0x320 net/can/j1939/main.c:353
> > Code: 00 74 08 48 89 df e8 ba 1e 48 f9 48 8b 1b 48 85 db 0f 84 f0 00 00 00 
> > 4c 89 64 24 08 48 81 c3 28 60 00 00 48 89 d8 48 c1 e8 03 <42> 80 3c 30 00 
> > 74 08 48 89 df e8 8c 1e 48 f9 4c 8b 23 4d 85 e4 0f
> > RSP: 0018:c9e9fd68 EFLAGS: 00010202
> > RAX: 0c0fe8c072f1 RBX: 607f46039788 RCX: 88801456d040
> > RDX: 88801456d040 RSI: 0118 RDI: 0118
> > RBP: 0118 R08: 8870585d R09: f520001d3fa5
> > R10: f520001d3fa5 R11:  R12: 0010
> > R13: 11100293e848 R14: dc00 R15: 8880149f4244
> > FS:  01d13880() GS:8880b9d0() knlGS:
> > CS:  0010 DS:  ES:  CR0: 80050033
> > CR2: 2080 CR3: 1402f000 CR4: 001506e0
> > DR0:  DR1:  DR2: 
> > DR3:  DR6: fffe0ff0 DR7: 0400
> > Call Trace:
> >   notifier_call_chain kernel/notifier.c:83 [inline]
> >   raw_notifier_call_chain+0xe7/0x170 kernel/notifier.c:410
> >   call_netdevice_notifiers_info net/core/dev.c:2022 [inline]
> >   call_net

Re: [RFC] exit: do exit_task_work() before shooting off mm

[Pavel Begunkov]

On 20/12/2020 13:58, Oleg Nesterov wrote:
> On 12/20, Pavel Begunkov wrote:
>>
>> On 08/12/2020 01:37, Al Viro wrote:
>>> On Thu, Dec 03, 2020 at 02:30:46AM +, Pavel Begunkov wrote:
 Handle task works and lock it earlier before it starts killing off
 task's resources like mm. io_uring makes use of it a lot and it'd
 nicer to have all added task_work finding tasks in a consistent state.
> 
> I too do not understand this patch. task_work_add() will fail after
> exit_task_work(). This means that, for example, exit_files() will use
> schedule_delayed_work().

The first one? Between PF_EXITING and exit_task_work() do_exit() will
kill mm/etc., I wanted to not see tasks half dismantled for task_works
run in the exit_task_work(). Anyway, forget about it :)

>> One more moment, after we've set PF_EXITING any task_work_run() would be
>> equivalent to exit_task_work()
> 
> Yes, currently task_work_run() can not be called after exit_signals().
> And shouldn't be called imo ;)
> 
>> io_uring
>> may want (currently doesn't) to run works for cancellation purposes.t
> 
> Please see 
> https://lore.kernel.org/io-uring/20200407163816.gb9...@redhat.com/>> 
> Shouldn't it be like below (not tested)? Also simplifies task_work_run().
> 
> I'd prefer the patch from the link above, but your version looks correct too.

I missed the thread, thanks! tbh, splitting into 2 functions looks better
to me, but it's not like that matters

> However, I still think it would be better to not abuse task_work_run() too
> much...

The problem is that io_uring cancels requests in exit_files() and some
of them may be sitting in task_works, and we need to get them out of there
to complete.

Also, I need to double check, but seems new requests may be added during
and by cancellation because we did not yet set it to work_exited by the
time (in exit_files()). 

-- 
Pavel Begunkov

RE: [PATCH 0/2] drop unused POWER_AVS option for ARM/ARM64 config

[ZHIZHIKIN Andrey]

Hello Arnd,

A while ago, I've submitted this series to clean-up the unused POWER_AVS config 
option, and
It looks like it did not land in anyone's tree until now.

Similar patch to clean-up the same option in omap2plus_defconfig has been 
already picked up
by Tony Lindgren and is already present in the linux-next tree, commit 
0437141b4e22 ("ARM:
configs: drop unused BACKLIGHT_GENERIC option").

Series has been already reviewed by Krzysztof and Nishanth, but nobody seems to 
pick it up further.

Since at the time of sending this series, I was not aware that ARM SOC list 
should also be included
(same thing as for BACKLIGHT_GENERIC series [1]), I wanted to ask you if you 
can take care of this
series further as it does touch the multi config for arm32 and aarch64.

Or should I re-send the series with collected tags and include ARM SOC list 
(same as I did for 
BACKLIGHT_GENERIC [1])?

> -Original Message-
> From: ZHIZHIKIN Andrey 
> Sent: Monday, November 30, 2020 12:27 PM
> To: catalin.mari...@arm.com; w...@kernel.org; bjorn.anders...@linaro.org;
> shawn...@kernel.org; leoyang...@nxp.com; vk...@kernel.org;
> geert+rene...@glider.be; anson.hu...@nxp.com; mich...@walle.cc;
> k...@kernel.org; o...@lixom.net; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org
> Cc: ZHIZHIKIN Andrey 
> Subject: [PATCH 0/2] drop unused POWER_AVS option for ARM/ARM64 config
> 
> This series cleans up kernel config files, removing the unused POWER_AVS
> option.
> 
> It has been removed in commit 785b5bb41b0a ("PM: AVS: Drop the avs
> directory and the corresponding Kconfig"), from the tree and
> therefore should be removed frorm default config files delivered for ARM
> and ARM64 builds.
> 
> Andrey Zhizhikin (2):
>   arm64: defconfig: drop unused POWER_AVS option
>   ARM: multi_v7_defconfig: drop unused POWER_AVS option
> 
>  arch/arm/configs/multi_v7_defconfig | 1 -
>  arch/arm64/configs/defconfig| 1 -
>  2 files changed, 2 deletions(-)
> 
> --
> 2.17.1

Link: [1]: 
https://lore.kernel.org/linux-arm-kernel/20201201222922.3183-1-andrey.zhizhi...@leica-geosystems.com/

-- Andrey

[PATCH v2 1/5] csky: Remove custom asm/atomic.h implementation

[guoren]

From: Guo Ren 

Use generic atomic implementation based on cmpxchg. So remove csky
asm/atomic.h.

Signed-off-by: Guo Ren 
Cc: Peter Zijlstra 
Cc: Arnd Bergmann 
Cc: Paul E. McKenney 
---
 arch/csky/include/asm/atomic.h | 212 -
 1 file changed, 212 deletions(-)
 delete mode 100644 arch/csky/include/asm/atomic.h

diff --git a/arch/csky/include/asm/atomic.h b/arch/csky/include/asm/atomic.h
deleted file mode 100644
index e369d73..
--- a/arch/csky/include/asm/atomic.h
+++ /dev/null
@@ -1,212 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-
-#ifndef __ASM_CSKY_ATOMIC_H
-#define __ASM_CSKY_ATOMIC_H
-
-#include 
-#include 
-#include 
-
-#ifdef CONFIG_CPU_HAS_LDSTEX
-
-#define __atomic_add_unless __atomic_add_unless
-static inline int __atomic_add_unless(atomic_t *v, int a, int u)
-{
-   unsigned long tmp, ret;
-
-   smp_mb();
-
-   asm volatile (
-   "1: ldex.w  %0, (%3) \n"
-   "   mov %1, %0   \n"
-   "   cmpne   %0, %4   \n"
-   "   bf  2f   \n"
-   "   add %0, %2   \n"
-   "   stex.w  %0, (%3) \n"
-   "   bez %0, 1b   \n"
-   "2:  \n"
-   : "=&r" (tmp), "=&r" (ret)
-   : "r" (a), "r"(&v->counter), "r"(u)
-   : "memory");
-
-   if (ret != u)
-   smp_mb();
-
-   return ret;
-}
-
-#define ATOMIC_OP(op, c_op)\
-static inline void atomic_##op(int i, atomic_t *v) \
-{  \
-   unsigned long tmp;  \
-   \
-   asm volatile (  \
-   "1: ldex.w  %0, (%2) \n"\
-   "   " #op " %0, %1   \n"\
-   "   stex.w  %0, (%2) \n"\
-   "   bez %0, 1b   \n"\
-   : "=&r" (tmp)   \
-   : "r" (i), "r"(&v->counter) \
-   : "memory");\
-}
-
-#define ATOMIC_OP_RETURN(op, c_op) \
-static inline int atomic_##op##_return(int i, atomic_t *v) \
-{  \
-   unsigned long tmp, ret; \
-   \
-   smp_mb();   \
-   asm volatile (  \
-   "1: ldex.w  %0, (%3) \n"\
-   "   " #op " %0, %2   \n"\
-   "   mov %1, %0   \n"\
-   "   stex.w  %0, (%3) \n"\
-   "   bez %0, 1b   \n"\
-   : "=&r" (tmp), "=&r" (ret)  \
-   : "r" (i), "r"(&v->counter) \
-   : "memory");\
-   smp_mb();   \
-   \
-   return ret; \
-}
-
-#define ATOMIC_FETCH_OP(op, c_op)  \
-static inline int atomic_fetch_##op(int i, atomic_t *v)
\
-{  \
-   unsigned long tmp, ret; \
-   \
-   smp_mb();   \
-   asm volatile (  \
-   "1: ldex.w  %0, (%3) \n"\
-   "   mov %1, %0   \n"\
-   "   " #op " %0, %2   \n"\
-   "   stex.w  %0, (%3) \n"\
-   "   bez %0, 1b   \n"\
-   : "=&r" (tmp), "=&r" (ret)  \
-   : "r" (i), "r"(&v->counter) \
-   : "memory");\
-   smp_mb();   \
-

Re: [PATCH] staging: qlge: Removed duplicate word in comment.

[Kari Argillander]

On Fri, Dec 18, 2020 at 05:48:29PM -0800, Daniel West wrote:
> This patch fixes the checkpatch warning:
> 
> WARNING: Possible repeated word: 'and'
> 
> Signed-off-by: Daniel West 
> ---
>  drivers/staging/qlge/qlge_main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/qlge/qlge_main.c 
> b/drivers/staging/qlge/qlge_main.c
> index e6b7baa12cd6..22167eca7c50 100644
> --- a/drivers/staging/qlge/qlge_main.c
> +++ b/drivers/staging/qlge/qlge_main.c
> @@ -3186,7 +3186,7 @@ static void ql_enable_msix(struct ql_adapter *qdev)
>"Running with legacy interrupts.\n");
>  }
>  
> -/* Each vector services 1 RSS ring and and 1 or more
> +/* Each vector services 1 RSS ring and 1 or more
>   * TX completion rings.  This function loops through
>   * the TX completion rings and assigns the vector that
>   * will service it.  An example would be if there are

Patch it self looks good. I nit pick a little bit because this is
staging and were here to learn mostly. You should use imperative mood
in subject line. So Removed -> Remove. Also no period in subject line.

I'm also confused by your email. Other patch which you send has sign of
is with daniel.s.west.dev and another is daniel.west.dev. So do you use
both? I also think that you made this email becouse you want to get all 
lkml mails. That is perfectly fine and many does this. But many does it
just for reading. That way if someone needs to send you email it wont be
lost because  you do not read that email anymore. Many does that they
still send  messages from they real email so that email do get so many
emails. This is ofcourse your decission I'm just telling you options.

--
Kari Argillander

Re: [PATCH] fs: io_uring.c: Add skip option for __io_sqe_files_update

[Pavel Begunkov]

On 20/12/2020 06:50, noah wrote:> From: noah 
> 
> This patch makes it so that specify a file descriptor value of -2 will
> skip updating the corresponding fixed file index.
> 
> This will allow for users to reduce the number of syscalls necessary
> to update a sparse file range when using the fixed file option.

Answering the github thread -- it's indeed a simple change, I had it the
same day you posted the issue. See below it's a bit cleaner. However, I
want to first review "io_uring: buffer registration enhancements", and
if it's good, for easier merging/etc I'd rather prefer to let it go
first (even if partially).

diff --git a/fs/io_uring.c b/fs/io_uring.c
index 941fe9b64fd9..b3ae9d5da17e 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -7847,9 +7847,8 @@ static int __io_sqe_files_update(struct io_ring_ctx *ctx,
if (IS_ERR(ref_node))
return PTR_ERR(ref_node);
 
-   done = 0;
fds = u64_to_user_ptr(up->fds);
-   while (nr_args) {
+   for (done = 0; done < nr_args; done++) {
struct fixed_file_table *table;
unsigned index;
 
@@ -7858,7 +7857,10 @@ static int __io_sqe_files_update(struct io_ring_ctx *ctx,
err = -EFAULT;
break;
}
-   i = array_index_nospec(up->offset, ctx->nr_user_files);
+   if (fd == IORING_REGISTER_FILES_SKIP)
+   continue;
+
+   i = array_index_nospec(up->offset + done, ctx->nr_user_files);
table = &ctx->file_data->table[i >> IORING_FILE_TABLE_SHIFT];
index = i & IORING_FILE_TABLE_MASK;
if (table->files[index]) {
@@ -7896,9 +7898,6 @@ static int __io_sqe_files_update(struct io_ring_ctx *ctx,
break;
}
}
-   nr_args--;
-   done++;
-   up->offset++;
}
 
if (needs_switch) {

-- 
Pavel Begunkov

Re: [PATCH] signal: Don't init struct kernel_siginfo fields to zero again

[Christian Brauner]

On Sun, Dec 20, 2020 at 04:45:54PM +0900, Leesoo Ahn wrote:
> clear_siginfo() is responsible for clearing struct kernel_siginfo object.
> It's obvious that manually initializing those fields is needless as
> a commit[1] explains why the function introduced and its guarantee that
> all bits in the struct are cleared after it.
> 
> [1]: commit 8c5dbf2ae00b ("signal: Introduce clear_siginfo")
> 
> Signed-off-by: Leesoo Ahn 
> ---

Acked-by: Christian Brauner 

I have a __user annotation fix in my tree from Jann that I plan to send
soon so I'll just stick this on top of it if noone minds.

Christian

[PATCH] block: aoe: Use seq_putc() if possible

[Amey Narkhede]

This is a single character that is printed out. Use seq_putc() for
it to simplify the code.

Signed-off-by: Amey Narkhede 
---
 drivers/block/aoe/aoeblk.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/block/aoe/aoeblk.c b/drivers/block/aoe/aoeblk.c
index c34e71b0c4a9..742c353aff54 100644
--- a/drivers/block/aoe/aoeblk.c
+++ b/drivers/block/aoe/aoeblk.c
@@ -147,7 +147,7 @@ static int aoedisk_debugfs_show(struct seq_file *s, void 
*ignored)
seq_printf(s, "%c%s", c, ifp->nd->name);
c = ',';
}
-   seq_puts(s, "\n");
+   seq_putc(s, '\n');
}
spin_unlock_irqrestore(&d->lock, flags);

@@ -465,4 +465,3 @@ aoeblk_init(void)
aoe_debugfs_dir = debugfs_create_dir("aoe", NULL);
return 0;
 }
-
--
2.29.2

Re: [PATCH 8455/8455] staging: rtl8188eu: core: fixed a comment format issue.

[Kari Argillander]

On Sat, Dec 19, 2020 at 02:43:12PM -0800, Daniel West wrote:
> Fixed a checkpatch warning:
> 
> WARNING: Block comments use * on subsequent lines
>  #4595: FILE: drivers/staging/rtl8188eu/core/rtw_mlme_ext.c:4595:
> +/
> +
> 
> The code is full of comments like this. Should the coding style
> be inforced here, even when there is a logic to the way the code
> was broken up?

You should make one patch which atleast fix one file at ones. It would
be even better if it fixes whole stuff (example one driver) right a way.
Also note that you should not but this kind messages to your patch
message. If you want to note this kind of thing you can use --- and
after that it will not included in patch itself. You can read it online
more.

Also where does this [PATCH 8455/8455] even come from? Good thing is
that you really didn't send so many patches or atleast I won't see them.

And it seems that you are new so welcome a board :)

--
Kari Argillander

Re: [PATCH] Add spi-nor driver for Realtek RTL838x/RTL839x switch SoCs

[Bert Vermeulen]

On 12/20/20 9:51 AM, Chuanhong Guo wrote:

Hi!

On Sun, Dec 20, 2020 at 7:01 AM Bert Vermeulen  wrote:


On 12/16/20 9:30 AM, tudor.amba...@microchip.com wrote:
> On 12/15/20 11:46 PM, Bert Vermeulen wrote:
>> This driver supports the spiflash core in all RTL838x/RTL839x SoCs,
>> and likely some older models as well (RTL8196C).
>>
> Can we use SPIMEM and move this under drivers/spi/ instead?

I wasn't aware spimem was the thing to use for new drivers. I will rewrite
the driver to that API.


Are there any limitations preventing this from being implemented as a
generic SPI controller?
spi-nor and spi-mem are designed for controllers which can only perform
spi-mem/spi-nor specific transfers. I can't find such limitations from
your current driver code.

>
> BTW I found a SPI controller driver for RTL8196C here: [0]
> It seems pretty similar to the controller you are working on.
>
> [0]: 
https://github.com/hackpascal/lede-rtl8196c/blob/realtek/target/linux/realtek/files/drivers/spi/spi-realtek.c


The SoC's SPI core is very much intended for SPI flash use only, and indeed 
we haven't come across anything else connected to that SPI bus in dozens of 
devices.


I wrote my driver based on Realtek code and a datasheet for the (older) 
RTL8196C found floating around the net, and found no inconsistencies.


I hadn't seen that RTL8196C driver, but if it works that proves a plain SPI 
driver will do. I'll investigate.



--
Bert Vermeulen
b...@biot.com

[PATCH v2 1/5] csky: Remove custom asm/atomic.h implementation

[guoren]

From: Guo Ren 

Use generic atomic implementation based on cmpxchg. So remove csky
asm/atomic.h.

Signed-off-by: Guo Ren 
Cc: Peter Zijlstra 
Cc: Arnd Bergmann 
Cc: Paul E. McKenney 
---
 arch/csky/include/asm/atomic.h | 212 -
 1 file changed, 212 deletions(-)
 delete mode 100644 arch/csky/include/asm/atomic.h

diff --git a/arch/csky/include/asm/atomic.h b/arch/csky/include/asm/atomic.h
deleted file mode 100644
index e369d73..
--- a/arch/csky/include/asm/atomic.h
+++ /dev/null
@@ -1,212 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-
-#ifndef __ASM_CSKY_ATOMIC_H
-#define __ASM_CSKY_ATOMIC_H
-
-#include 
-#include 
-#include 
-
-#ifdef CONFIG_CPU_HAS_LDSTEX
-
-#define __atomic_add_unless __atomic_add_unless
-static inline int __atomic_add_unless(atomic_t *v, int a, int u)
-{
-   unsigned long tmp, ret;
-
-   smp_mb();
-
-   asm volatile (
-   "1: ldex.w  %0, (%3) \n"
-   "   mov %1, %0   \n"
-   "   cmpne   %0, %4   \n"
-   "   bf  2f   \n"
-   "   add %0, %2   \n"
-   "   stex.w  %0, (%3) \n"
-   "   bez %0, 1b   \n"
-   "2:  \n"
-   : "=&r" (tmp), "=&r" (ret)
-   : "r" (a), "r"(&v->counter), "r"(u)
-   : "memory");
-
-   if (ret != u)
-   smp_mb();
-
-   return ret;
-}
-
-#define ATOMIC_OP(op, c_op)\
-static inline void atomic_##op(int i, atomic_t *v) \
-{  \
-   unsigned long tmp;  \
-   \
-   asm volatile (  \
-   "1: ldex.w  %0, (%2) \n"\
-   "   " #op " %0, %1   \n"\
-   "   stex.w  %0, (%2) \n"\
-   "   bez %0, 1b   \n"\
-   : "=&r" (tmp)   \
-   : "r" (i), "r"(&v->counter) \
-   : "memory");\
-}
-
-#define ATOMIC_OP_RETURN(op, c_op) \
-static inline int atomic_##op##_return(int i, atomic_t *v) \
-{  \
-   unsigned long tmp, ret; \
-   \
-   smp_mb();   \
-   asm volatile (  \
-   "1: ldex.w  %0, (%3) \n"\
-   "   " #op " %0, %2   \n"\
-   "   mov %1, %0   \n"\
-   "   stex.w  %0, (%3) \n"\
-   "   bez %0, 1b   \n"\
-   : "=&r" (tmp), "=&r" (ret)  \
-   : "r" (i), "r"(&v->counter) \
-   : "memory");\
-   smp_mb();   \
-   \
-   return ret; \
-}
-
-#define ATOMIC_FETCH_OP(op, c_op)  \
-static inline int atomic_fetch_##op(int i, atomic_t *v)
\
-{  \
-   unsigned long tmp, ret; \
-   \
-   smp_mb();   \
-   asm volatile (  \
-   "1: ldex.w  %0, (%3) \n"\
-   "   mov %1, %0   \n"\
-   "   " #op " %0, %2   \n"\
-   "   stex.w  %0, (%3) \n"\
-   "   bez %0, 1b   \n"\
-   : "=&r" (tmp), "=&r" (ret)  \
-   : "r" (i), "r"(&v->counter) \
-   : "memory");\
-   smp_mb();   \
-

[PATCH v2 2/5] csky: Fixup barrier design

[guoren]

From: Guo Ren 

Remove shareable bit for ordering barrier, just keep ordering
in current hart is enough for SMP. Using three continuous
sync.is as PTW barrier to prevent speculative PTW in 860
microarchitecture.

Signed-off-by: Guo Ren 
---
 arch/csky/include/asm/barrier.h | 82 ++---
 1 file changed, 60 insertions(+), 22 deletions(-)

diff --git a/arch/csky/include/asm/barrier.h b/arch/csky/include/asm/barrier.h
index a430e7f..117e622 100644
--- a/arch/csky/include/asm/barrier.h
+++ b/arch/csky/include/asm/barrier.h
@@ -8,6 +8,61 @@
 
 #define nop()  asm volatile ("nop\n":::"memory")
 
+#ifdef CONFIG_SMP
+
+/*
+ * bar.brwarws: ordering barrier for all load/store instructions
+ *  before/after
+ *
+ * |31|30 26|25 21|20 16|15  10|9   5|4   0|
+ *  1  1 0 0 111 0 bw br aw ar
+ *
+ * b: before
+ * a: after
+ * r: read
+ * w: write
+ *
+ * Here are all combinations:
+ *
+ * bar.brw
+ * bar.br
+ * bar.bw
+ * bar.arw
+ * bar.ar
+ * bar.aw
+ * bar.brwarw
+ * bar.brarw
+ * bar.bwarw
+ * bar.brwar
+ * bar.brwaw
+ * bar.brar
+ * bar.bwaw
+ */
+#define __bar_brw()asm volatile (".long 0x842cc000\n":::"memory")
+#define __bar_br() asm volatile (".long 0x8424c000\n":::"memory")
+#define __bar_bw() asm volatile (".long 0x8428c000\n":::"memory")
+#define __bar_arw()asm volatile (".long 0x8423c000\n":::"memory")
+#define __bar_ar() asm volatile (".long 0x8421c000\n":::"memory")
+#define __bar_aw() asm volatile (".long 0x8422c000\n":::"memory")
+#define __bar_brwarw() asm volatile (".long 0x842fc000\n":::"memory")
+#define __bar_brarw()  asm volatile (".long 0x8427c000\n":::"memory")
+#define __bar_bwarw()  asm volatile (".long 0x842bc000\n":::"memory")
+#define __bar_brwar()  asm volatile (".long 0x842dc000\n":::"memory")
+#define __bar_brwaw()  asm volatile (".long 0x842ec000\n":::"memory")
+#define __bar_brar()   asm volatile (".long 0x8425c000\n":::"memory")
+#define __bar_brar()   asm volatile (".long 0x8425c000\n":::"memory")
+#define __bar_bwaw()   asm volatile (".long 0x842ac000\n":::"memory")
+
+#define __smp_mb() __bar_brwarw()
+#define __smp_rmb()__bar_brar()
+#define __smp_wmb()__bar_bwaw()
+
+#define ACQUIRE_FENCE  ".long 0x8427c000\n"
+#define __smp_acquire_fence()  __bar_brarw()
+#define __smp_release_fence()  __bar_brwaw()
+
+#endif /* CONFIG_SMP */
+
 /*
  * sync:completion barrier, all sync.xx instructions
  *  guarantee the last response recieved by bus transaction
@@ -15,31 +70,14 @@
  * sync.s:  inherit from sync, but also shareable to other cores
  * sync.i:  inherit from sync, but also flush cpu pipeline
  * sync.is: the same with sync.i + sync.s
- *
- * bar.brwarw:  ordering barrier for all load/store instructions before it
- * bar.brwarws: ordering barrier for all load/store instructions before it
- * and shareable to other cores
- * bar.brar:ordering barrier for all load   instructions before it
- * bar.brars:   ordering barrier for all load   instructions before it
- * and shareable to other cores
- * bar.bwaw:ordering barrier for all store  instructions before it
- * bar.bwaws:   ordering barrier for all store  instructions before it
- * and shareable to other cores
  */
+#define mb()   asm volatile ("sync\n":::"memory")
 
 #ifdef CONFIG_CPU_HAS_CACHEV2
-#define mb()   asm volatile ("sync.s\n":::"memory")
-
-#ifdef CONFIG_SMP
-#define __smp_mb() asm volatile ("bar.brwarws\n":::"memory")
-#define __smp_rmb()asm volatile ("bar.brars\n":::"memory")
-#define __smp_wmb()asm volatile ("bar.bwaws\n":::"memory")
-#endif /* CONFIG_SMP */
-
-#define sync_is()  asm volatile ("sync.is\n":::"memory")
-
-#else /* !CONFIG_CPU_HAS_CACHEV2 */
-#define mb()   asm volatile ("sync\n":::"memory")
+/*
+ * Using three sync.is to prevent speculative PTW
+ */
+#define sync_is()  asm volatile ("sync.is\nsync.is\nsync.is\n":::"memory")
 #endif
 
 #include 
-- 
2.7.4

[PATCH v2 4/5] csky: Fixup asm/cmpxchg.h with correct ordering barrier

[guoren]

From: Guo Ren 

Optimize the performance of cmpxchg by using more fine-grained
acquire/release barriers.

Signed-off-by: Guo Ren 
Cc: Peter Zijlstra 
Cc: Arnd Bergmann 
Cc: Paul E. McKenney 
---
 arch/csky/include/asm/cmpxchg.h | 27 +--
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/arch/csky/include/asm/cmpxchg.h b/arch/csky/include/asm/cmpxchg.h
index 8922453..dabc8e4 100644
--- a/arch/csky/include/asm/cmpxchg.h
+++ b/arch/csky/include/asm/cmpxchg.h
@@ -3,12 +3,12 @@
 #ifndef __ASM_CSKY_CMPXCHG_H
 #define __ASM_CSKY_CMPXCHG_H
 
-#ifdef CONFIG_CPU_HAS_LDSTEX
+#ifdef CONFIG_SMP
 #include 
 
 extern void __bad_xchg(void);
 
-#define __xchg(new, ptr, size) \
+#define __xchg_relaxed(new, ptr, size) \
 ({ \
__typeof__(ptr) __ptr = (ptr);  \
__typeof__(new) __new = (new);  \
@@ -16,7 +16,6 @@ extern void __bad_xchg(void);
unsigned long tmp;  \
switch (size) { \
case 4: \
-   smp_mb();   \
asm volatile (  \
"1: ldex.w  %0, (%3) \n"\
"   mov %1, %2   \n"\
@@ -25,7 +24,6 @@ extern void __bad_xchg(void);
: "=&r" (__ret), "=&r" (tmp)\
: "r" (__new), "r"(__ptr)   \
:); \
-   smp_mb();   \
break;  \
default:\
__bad_xchg();   \
@@ -33,9 +31,10 @@ extern void __bad_xchg(void);
__ret;  \
 })
 
-#define xchg(ptr, x)   (__xchg((x), (ptr), sizeof(*(ptr
+#define xchg_relaxed(ptr, x) \
+   (__xchg_relaxed((x), (ptr), sizeof(*(ptr
 
-#define __cmpxchg(ptr, old, new, size) \
+#define __cmpxchg_relaxed(ptr, old, new, size) \
 ({ \
__typeof__(ptr) __ptr = (ptr);  \
__typeof__(new) __new = (new);  \
@@ -44,7 +43,6 @@ extern void __bad_xchg(void);
__typeof__(*(ptr)) __ret;   \
switch (size) { \
case 4: \
-   smp_mb();   \
asm volatile (  \
"1: ldex.w  %0, (%3) \n"\
"   cmpne   %0, %4   \n"\
@@ -56,7 +54,6 @@ extern void __bad_xchg(void);
: "=&r" (__ret), "=&r" (__tmp)  \
: "r" (__new), "r"(__ptr), "r"(__old)   \
:); \
-   smp_mb();   \
break;  \
default:\
__bad_xchg();   \
@@ -64,8 +61,18 @@ extern void __bad_xchg(void);
__ret;  \
 })
 
-#define cmpxchg(ptr, o, n) \
-   (__cmpxchg((ptr), (o), (n), sizeof(*(ptr
+#define cmpxchg_relaxed(ptr, o, n) \
+   (__cmpxchg_relaxed((ptr), (o), (n), sizeof(*(ptr
+
+#define cmpxchg(ptr, o, n) \
+({ \
+   __typeof__(*(ptr)) __ret;   \
+   __smp_release_fence();  \
+   __ret = cmpxchg_relaxed(ptr, o, n); \
+   __smp_acquire_fence();  \
+   __ret;  \
+})
+
 #else
 #include 
 #endif
-- 
2.7.4

[PATCH v2 5/5] csky: Cleanup asm/spinlock.h

[guoren]

From: Guo Ren 

There are two implementation of spinlock in arch/csky:
 - simple one (NR_CPU = 1,2)
 - tick's one (NR_CPU = 3,4)
Remove the simple one.

There is already smp_mb in spinlock, so remove the definition of
smp_mb__after_spinlock.

Link: 
https://lore.kernel.org/linux-csky/20200807081253.gd2...@hirez.programming.kicks-ass.net/#t
Signed-off-by: Guo Ren 
Cc: Peter Zijlstra k
Cc: Arnd Bergmann 
---
 arch/csky/Kconfig  |   2 +-
 arch/csky/include/asm/spinlock.h   | 167 -
 arch/csky/include/asm/spinlock_types.h |  10 --
 3 files changed, 1 insertion(+), 178 deletions(-)

diff --git a/arch/csky/Kconfig b/arch/csky/Kconfig
index e254dc2..5ebb05a 100644
--- a/arch/csky/Kconfig
+++ b/arch/csky/Kconfig
@@ -7,7 +7,7 @@ config CSKY
select ARCH_HAS_SYNC_DMA_FOR_CPU
select ARCH_HAS_SYNC_DMA_FOR_DEVICE
select ARCH_USE_BUILTIN_BSWAP
-   select ARCH_USE_QUEUED_RWLOCKS if NR_CPUS>2
+   select ARCH_USE_QUEUED_RWLOCKS
select ARCH_WANT_FRAME_POINTERS if !CPU_CK610
select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
select COMMON_CLK
diff --git a/arch/csky/include/asm/spinlock.h b/arch/csky/include/asm/spinlock.h
index 7cf3f2b..69f5aa2 100644
--- a/arch/csky/include/asm/spinlock.h
+++ b/arch/csky/include/asm/spinlock.h
@@ -6,8 +6,6 @@
 #include 
 #include 
 
-#ifdef CONFIG_QUEUED_RWLOCKS
-
 /*
  * Ticket-based spin-locking.
  */
@@ -88,169 +86,4 @@ static inline int arch_spin_is_contended(arch_spinlock_t 
*lock)
 
 #include 
 
-/* See include/linux/spinlock.h */
-#define smp_mb__after_spinlock()   smp_mb()
-
-#else /* CONFIG_QUEUED_RWLOCKS */
-
-/*
- * Test-and-set spin-locking.
- */
-static inline void arch_spin_lock(arch_spinlock_t *lock)
-{
-   u32 *p = &lock->lock;
-   u32 tmp;
-
-   asm volatile (
-   "1: ldex.w  %0, (%1) \n"
-   "   bnez%0, 1b   \n"
-   "   movi%0, 1\n"
-   "   stex.w  %0, (%1) \n"
-   "   bez %0, 1b   \n"
-   : "=&r" (tmp)
-   : "r"(p)
-   : "cc");
-   smp_mb();
-}
-
-static inline void arch_spin_unlock(arch_spinlock_t *lock)
-{
-   smp_mb();
-   WRITE_ONCE(lock->lock, 0);
-}
-
-static inline int arch_spin_trylock(arch_spinlock_t *lock)
-{
-   u32 *p = &lock->lock;
-   u32 tmp;
-
-   asm volatile (
-   "1: ldex.w  %0, (%1) \n"
-   "   bnez%0, 2f   \n"
-   "   movi%0, 1\n"
-   "   stex.w  %0, (%1) \n"
-   "   bez %0, 1b   \n"
-   "   movi%0, 0\n"
-   "2:  \n"
-   : "=&r" (tmp)
-   : "r"(p)
-   : "cc");
-
-   if (!tmp)
-   smp_mb();
-
-   return !tmp;
-}
-
-#define arch_spin_is_locked(x) (READ_ONCE((x)->lock) != 0)
-
-/*
- * read lock/unlock/trylock
- */
-static inline void arch_read_lock(arch_rwlock_t *lock)
-{
-   u32 *p = &lock->lock;
-   u32 tmp;
-
-   asm volatile (
-   "1: ldex.w  %0, (%1) \n"
-   "   blz %0, 1b   \n"
-   "   addi%0, 1\n"
-   "   stex.w  %0, (%1) \n"
-   "   bez %0, 1b   \n"
-   : "=&r" (tmp)
-   : "r"(p)
-   : "cc");
-   smp_mb();
-}
-
-static inline void arch_read_unlock(arch_rwlock_t *lock)
-{
-   u32 *p = &lock->lock;
-   u32 tmp;
-
-   smp_mb();
-   asm volatile (
-   "1: ldex.w  %0, (%1) \n"
-   "   subi%0, 1\n"
-   "   stex.w  %0, (%1) \n"
-   "   bez %0, 1b   \n"
-   : "=&r" (tmp)
-   : "r"(p)
-   : "cc");
-}
-
-static inline int arch_read_trylock(arch_rwlock_t *lock)
-{
-   u32 *p = &lock->lock;
-   u32 tmp;
-
-   asm volatile (
-   "1: ldex.w  %0, (%1) \n"
-   "   blz %0, 2f   \n"
-   "   addi%0, 1\n"
-   "   stex.w  %0, (%1) \n"
-   "   bez %0, 1b   \n"
-   "   movi%0, 0\n"
-   "2:  \n"
-   : "=&r" (tmp)
-   : "r"(p)
-   : "cc");
-
-   if (!tmp)
-   smp_mb();
-
-   return !tmp;
-}
-
-/*
- * write lock/unlock/trylock
- */
-static inline void arch_write_lock(arch_rwlock_t *lock)
-{
-   u32 *p = &lock->lock;
-   u32 tmp;
-
-   asm volatile (
-   "1: ldex.w  %0, (%1) \n"
-   "   bnez%0, 1b   \n"
-   "   su

[PATCH v2 3/5] csky: Fixup futex SMP implementation

[guoren]

From: Guo Ren 

Arnd said:
I would guess that for csky, this is a mistake, as the architecture
is fairly new and should be able to implement it.

Guo reply:
The c610, c807, c810 don't support SMP, so futex_cmpxchg_enabled = 1
with asm-generic's implementation.
For c860, there is no HAVE_FUTEX_CMPXCHG and cmpxchg_inatomic/inuser
implementation, so futex_cmpxchg_enabled = 0.

Thx for point it out, we'll implement cmpxchg_inatomic/inuser for
C860 and still use asm-generic for non-smp CPUs.

LTP test:
futex_wait011  TPASS  :  futex_wait(): errno=ETIMEDOUT(110): Connection 
timed out
futex_wait012  TPASS  :  futex_wait(): errno=EAGAIN/EWOULDBLOCK(11): 
Resource temporarily unavailable
futex_wait013  TPASS  :  futex_wait(): errno=ETIMEDOUT(110): Connection 
timed out
futex_wait014  TPASS  :  futex_wait(): errno=EAGAIN/EWOULDBLOCK(11): 
Resource temporarily unavailable
futex_wait021  TPASS  :  futex_wait() woken up
futex_wait031  TPASS  :  futex_wait() woken up
futex_wait041  TPASS  :  futex_wait() returned -1: 
errno=EAGAIN/EWOULDBLOCK(11): Resource temporarily unavailable

Signed-off-by: Guo Ren 
Cc: Arnd Bergmann 
Cc: Peter Zijlstra 
Cc: Paul E. McKenney 
Link: 
https://lore.kernel.org/lkml/CAK8P3a3+WaQNyJ6Za2qfu6=0mBgU1hApnRXrdp1b1=p7wwy...@mail.gmail.com/
---
 arch/csky/Kconfig |   1 +
 arch/csky/include/asm/futex.h | 127 ++
 2 files changed, 128 insertions(+)
 create mode 100644 arch/csky/include/asm/futex.h

diff --git a/arch/csky/Kconfig b/arch/csky/Kconfig
index 50bb8b4..e254dc2 100644
--- a/arch/csky/Kconfig
+++ b/arch/csky/Kconfig
@@ -49,6 +49,7 @@ config CSKY
select HAVE_FUNCTION_TRACER
select HAVE_FUNCTION_GRAPH_TRACER
select HAVE_FUNCTION_ERROR_INJECTION
+   select HAVE_FUTEX_CMPXCHG if FUTEX && SMP
select HAVE_FTRACE_MCOUNT_RECORD
select HAVE_KERNEL_GZIP
select HAVE_KERNEL_LZO
diff --git a/arch/csky/include/asm/futex.h b/arch/csky/include/asm/futex.h
new file mode 100644
index ..dbe2f99
--- /dev/null
+++ b/arch/csky/include/asm/futex.h
@@ -0,0 +1,127 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef __ASM_CSKY_FUTEX_H
+#define __ASM_CSKY_FUTEX_H
+
+#ifndef CONFIG_SMP
+#include 
+#else
+#include 
+#include 
+#include 
+#include 
+
+#define __futex_atomic_op(insn, ret, oldval, uaddr, oparg) \
+{  \
+   u32 tmp;\
+   \
+   __atomic_pre_full_fence();  \
+   \
+   __asm__ __volatile__ (  \
+   "1: ldex.w  %[ov], %[u] \n" \
+   "   "insn"  \n" \
+   "2: stex.w  %[t], %[u]  \n" \
+   "   bez %[t], 1b\n" \
+   "4: \n" \
+   "   .section .fixup,\"ax\"  \n" \
+   "   .balign 4   \n" \
+   "5: mov %[r], %[e]  \n" \
+   "   jmpi 4b \n" \
+   "   .previous   \n" \
+   "   .section __ex_table,\"a\"   \n" \
+   "   .balign 4   \n" \
+   "   .long   1b, 5b  \n" \
+   "   .long   2b, 5b  \n" \
+   "   .previous   \n" \
+   : [r] "+r" (ret), [ov] "=&r" (oldval),  \
+ [u] "+m" (*uaddr), [t] "=&r" (tmp)\
+   : [op] "Jr" (oparg), [e] "jr" (-EFAULT) \
+   : "memory");\
+   \
+   __atomic_post_full_fence(); \
+}
+
+static inline int
+arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *uaddr)
+{
+   int oldval = 0, ret = 0;
+
+   if (!access_ok(uaddr, sizeof(u32)))
+   return -EFAULT;
+
+   switch (op) {
+   case FUTEX_OP_SET:
+   __futex_atomic_op("mov %[t], %[ov]",
+ ret, oldval, uaddr, oparg);
+   break;
+   case FUTEX_OP_ADD:
+   __futex_atomic_op("add %[t], %[ov], %[op]",
+ ret, oldval, uaddr, oparg);
+   break;
+   case FUTEX_OP_OR:
+   

Re: [PATCH] signal: Don't init struct kernel_siginfo fields to zero again

[Rae Kim]

It looks like compiler optimization is smart enough to know that
assigning zero is unnecessary after clear_siginfo() which is memset()
under the hood. At least in my x86_64 machine, w/ or w/o this patch,
there is no difference in final compiled machine code. (I've compared
"objdump -d" results for "__send_signal()", "do_tkill()", and
"collect_signal()")

Wouldn't it be nicer to have more information for both human and
compiler since it doesn't generate extra machine code?

On Sun, Dec 20, 2020 at 03:21:35PM +0100, Oleg Nesterov wrote:
> On 12/20, Leesoo Ahn wrote:
> >
> > clear_siginfo() is responsible for clearing struct kernel_siginfo object.
> > It's obvious that manually initializing those fields is needless as
> > a commit[1] explains why the function introduced and its guarantee that
> > all bits in the struct are cleared after it.
> >
> > [1]: commit 8c5dbf2ae00b ("signal: Introduce clear_siginfo")
> >
> > Signed-off-by: Leesoo Ahn 
> 
> Acked-by: Oleg Nesterov 
> 
> 
> > ---
> >  kernel/signal.c | 21 -
> >  1 file changed, 21 deletions(-)
> > 
> > diff --git a/kernel/signal.c b/kernel/signal.c
> > index 5736c55aaa1a..8f49fa3ade33 100644
> > --- a/kernel/signal.c
> > +++ b/kernel/signal.c
> > @@ -603,10 +603,7 @@ static void collect_signal(int sig, struct sigpending 
> > *list, kernel_siginfo_t *i
> >  */
> > clear_siginfo(info);
> > info->si_signo = sig;
> > -   info->si_errno = 0;
> > info->si_code = SI_USER;
> > -   info->si_pid = 0;
> > -   info->si_uid = 0;
> > }
> >  }
> >  
> > @@ -1120,7 +1117,6 @@ static int __send_signal(int sig, struct 
> > kernel_siginfo *info, struct task_struc
> > case (unsigned long) SEND_SIG_NOINFO:
> > clear_siginfo(&q->info);
> > q->info.si_signo = sig;
> > -   q->info.si_errno = 0;
> > q->info.si_code = SI_USER;
> > q->info.si_pid = task_tgid_nr_ns(current,
> > task_active_pid_ns(t));
> > @@ -1133,10 +1129,7 @@ static int __send_signal(int sig, struct 
> > kernel_siginfo *info, struct task_struc
> > case (unsigned long) SEND_SIG_PRIV:
> > clear_siginfo(&q->info);
> > q->info.si_signo = sig;
> > -   q->info.si_errno = 0;
> > q->info.si_code = SI_KERNEL;
> > -   q->info.si_pid = 0;
> > -   q->info.si_uid = 0;
> > break;
> > default:
> > copy_siginfo(&q->info, info);
> > @@ -1623,10 +1616,7 @@ void force_sig(int sig)
> >  
> > clear_siginfo(&info);
> > info.si_signo = sig;
> > -   info.si_errno = 0;
> > info.si_code = SI_KERNEL;
> > -   info.si_pid = 0;
> > -   info.si_uid = 0;
> > force_sig_info(&info);
> >  }
> >  EXPORT_SYMBOL(force_sig);
> > @@ -1659,7 +1649,6 @@ int force_sig_fault_to_task(int sig, int code, void 
> > __user *addr
> >  
> > clear_siginfo(&info);
> > info.si_signo = sig;
> > -   info.si_errno = 0;
> > info.si_code  = code;
> > info.si_addr  = addr;
> >  #ifdef __ARCH_SI_TRAPNO
> > @@ -1691,7 +1680,6 @@ int send_sig_fault(int sig, int code, void __user 
> > *addr
> >  
> > clear_siginfo(&info);
> > info.si_signo = sig;
> > -   info.si_errno = 0;
> > info.si_code  = code;
> > info.si_addr  = addr;
> >  #ifdef __ARCH_SI_TRAPNO
> > @@ -1712,7 +1700,6 @@ int force_sig_mceerr(int code, void __user *addr, 
> > short lsb)
> > WARN_ON((code != BUS_MCEERR_AO) && (code != BUS_MCEERR_AR));
> > clear_siginfo(&info);
> > info.si_signo = SIGBUS;
> > -   info.si_errno = 0;
> > info.si_code = code;
> > info.si_addr = addr;
> > info.si_addr_lsb = lsb;
> > @@ -1726,7 +1713,6 @@ int send_sig_mceerr(int code, void __user *addr, 
> > short lsb, struct task_struct *
> > WARN_ON((code != BUS_MCEERR_AO) && (code != BUS_MCEERR_AR));
> > clear_siginfo(&info);
> > info.si_signo = SIGBUS;
> > -   info.si_errno = 0;
> > info.si_code = code;
> > info.si_addr = addr;
> > info.si_addr_lsb = lsb;
> > @@ -1740,7 +1726,6 @@ int force_sig_bnderr(void __user *addr, void __user 
> > *lower, void __user *upper)
> >  
> > clear_siginfo(&info);
> > info.si_signo = SIGSEGV;
> > -   info.si_errno = 0;
> > info.si_code  = SEGV_BNDERR;
> > info.si_addr  = addr;
> > info.si_lower = lower;
> > @@ -1755,7 +1740,6 @@ int force_sig_pkuerr(void __user *addr, u32 pkey)
> >  
> > clear_siginfo(&info);
> > info.si_signo = SIGSEGV;
> > -   info.si_errno = 0;
> > info.si_code  = SEGV_PKUERR;
> > info.si_addr  = addr;
> > info.si_pkey  = pkey;
> > @@ -1934,7 +1918,6 @@ bool do_notify_parent(struct task_struct *tsk, int 
> > sig)
> >  
> > clear_siginfo(&info);
> > info.si_signo = sig;
> > -   info.si_errno = 0;
> > /*
> >  * We are 

Re: [PATCH 1/2] futex: mark futex_detect_cmpxchg() as 'noinline'

[Guo Ren]

Hi Arnd,

On Tue, Dec 15, 2020 at 7:26 PM Arnd Bergmann  wrote:
>
> On Tue, Dec 15, 2020 at 7:09 AM Guo Ren  wrote:
> > On Mon, Dec 14, 2020 at 9:15 PM Arnd Bergmann  wrote:
> > > I had a look at what other architectures always implement
> > > futex_atomic_cmpxchg_inatomic() or can use the asm-generic non-SMP 
> > > version,
> > > and I found that it's pretty much all of them, the odd ones being just 
> > > sparc32
> > > and csky, which use asm-generic/futex.h but do have an SMP option,
> > > as well as xtensa
> > >
> > > I would guess that for csky, this is a mistake, as the architecture is 
> > > fairly
> > > new and should be able to implement it. Not sure about sparc32.
> >
> > The c610, c807, c810 don't support SMP, so futex_cmpxchg_enabled = 1
> > with asm-generic's implementation.
> > For c860, there is no HAVE_FUTEX_CMPXCHG and cmpxchg_inatomic/inuser
> > implementation, so futex_cmpxchg_enabled = 0.
> >
> > Thx for point it out, we'll implement cmpxchg_inatomic/inuser for C860
> > and still use asm-generic for non-smp CPUs.
>
> Sounds good to me.
Done: 
https://lore.kernel.org/linux-csky/1608478763-60148-3-git-send-email-guo...@kernel.org/T/#u

-- 
Best Regards
 Guo Ren

ML: https://lore.kernel.org/linux-csky/

Re: [PATCH] staging: rtl8192e: fix bool comparison in expressions

[Kari Argillander]

On Thu, Dec 17, 2020 at 05:12:04PM +0530, Aditya Srivastava wrote:
> There are certain conditional expressions in rtl8192e, where a boolean
> variable is compared with true/false, in forms such as (foo == true) or
> (false != bar), which does not comply with checkpatch.pl (CHECK:
> BOOL_COMPARISON), according to which boolean variables should be
> themselves used in the condition, rather than comparing with true/false
> 
> E.g. in drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c,
> "if (Type == true)" can be replaced with: "if (Type)"
> 
> Replace all such expressions with the bool variables appropriately
> 
> Signed-off-by: Aditya Srivastava 
> ---
> - the changes made are compile tested
> - the patch applies perfectly over next-20201204
> 
>  drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c | 4 ++--
>  drivers/staging/rtl8192e/rtl8192e/rtl_core.c   | 4 ++--
>  drivers/staging/rtl8192e/rtl8192e/rtl_dm.c | 4 ++--
>  drivers/staging/rtl8192e/rtllib_rx.c   | 4 ++--
>  drivers/staging/rtl8192e/rtllib_tx.c   | 8 
>  5 files changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c 
> b/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
> index 9f869fb3eaa8..c4a3fc79fb40 100644
> --- a/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
> +++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
> @@ -129,9 +129,9 @@ void rtl92e_set_reg(struct net_device *dev, u8 variable, 
> u8 *val)
>   RegRCR = rtl92e_readl(dev, RCR);
>   priv->ReceiveConfig = RegRCR;
>  
> - if (Type == true)
> + if (Type)
>   RegRCR |= (RCR_CBSSID);
> - else if (Type == false)
> + else if (!Type)

Just else here?

>   RegRCR &= (~RCR_CBSSID);
>  
>   rtl92e_writel(dev, RCR, RegRCR);
> diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c 
> b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
> index 663675efcfe4..9078fadd65f9 100644
> --- a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
> +++ b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
> @@ -1389,7 +1389,7 @@ static void _rtl92e_watchdog_wq_cb(void *data)
>  
>   rtl92e_dm_watchdog(dev);
>  
> - if (rtllib_act_scanning(priv->rtllib, false) == false) {
> + if (!rtllib_act_scanning(priv->rtllib, false)) {
>   if ((ieee->iw_mode == IW_MODE_INFRA) && (ieee->state ==
>RTLLIB_NOLINK) &&
>(ieee->eRFPowerState == eRfOn) && !ieee->is_set_key &&
> @@ -2471,7 +2471,7 @@ static int _rtl92e_pci_probe(struct pci_dev *pdev,
>  
>   priv->ops = ops;
>  
> - if (rtl92e_check_adapter(pdev, dev) == false)
> + if (!rtl92e_check_adapter(pdev, dev))
>   goto err_unmap;
>  
>   dev->irq = pdev->irq;
> diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c 
> b/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
> index 462835684e8b..e340be3ebb97 100644
> --- a/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
> +++ b/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
> @@ -1765,7 +1765,7 @@ static void _rtl92e_dm_cts_to_self(struct net_device 
> *dev)
>   unsigned long curTxOkCnt = 0;
>   unsigned long curRxOkCnt = 0;
>  
> - if (priv->rtllib->bCTSToSelfEnable != true) {
> + if (!priv->rtllib->bCTSToSelfEnable) {
>   pHTInfo->IOTAction &= ~HT_IOT_ACT_FORCED_CTS2SELF;
>   return;
>   }
> @@ -2447,7 +2447,7 @@ static void _rtl92e_dm_dynamic_tx_power(struct 
> net_device *dev)
>   unsigned int txhipower_threshold = 0;
>   unsigned int txlowpower_threshold = 0;
>  
> - if (priv->rtllib->bdynamic_txpower_enable != true) {
> + if (!priv->rtllib->bdynamic_txpower_enable) {
>   priv->bDynamicTxHighPower = false;
>   priv->bDynamicTxLowPower = false;
>   return;
> diff --git a/drivers/staging/rtl8192e/rtllib_rx.c 
> b/drivers/staging/rtl8192e/rtllib_rx.c
> index d31b5e1c8df4..217557ac8d80 100644
> --- a/drivers/staging/rtl8192e/rtllib_rx.c
> +++ b/drivers/staging/rtl8192e/rtllib_rx.c
> @@ -924,7 +924,7 @@ static int rtllib_rx_check_duplicate(struct rtllib_device 
> *ieee,
>   sc = le16_to_cpu(hdr->seq_ctl);
>   frag = WLAN_GET_SEQ_FRAG(sc);
>  
> - if ((ieee->pHTInfo->bCurRxReorderEnable == false) ||
> + if ((!ieee->pHTInfo->bCurRxReorderEnable) ||

No need for brackets. Atleast after you remove check.

>   !ieee->current_network.qos_data.active ||
>   !IsDataFrame(skb->data) ||
>   IsLegacyDataFrame(skb->data)) {
> @@ -1442,7 +1442,7 @@ static int rtllib_rx_InfraAdhoc(struct rtllib_device 
> *ieee, struct sk_buff *skb,
>   }
>  
>   /* Indicate packets to upper layer or Rx Reorder */
> - if (ieee->pHTInfo->bCurRxReorderEnable == false || pTS == NULL ||
> + if (!ieee->pHTInfo->bCurRxReorderEnable || pTS == NULL ||
>   bToOtherSTA)

Now bToOtherSTA would fit same line. It is ok to fix that also.

>   

Re: [PATCH] signal: Don't init struct kernel_siginfo fields to zero again

[Christian Brauner]

On Mon, Dec 21, 2020 at 12:43:05AM +0900, Rae Kim wrote:
> 
> It looks like compiler optimization is smart enough to know that
> assigning zero is unnecessary after clear_siginfo() which is memset()
> under the hood. At least in my x86_64 machine, w/ or w/o this patch,
> there is no difference in final compiled machine code. (I've compared
> "objdump -d" results for "__send_signal()", "do_tkill()", and
> "collect_signal()")
> 
> Wouldn't it be nicer to have more information for both human and
> compiler since it doesn't generate extra machine code?

I don't have a strong preference. But the name clear_siginfo() is pretty
obvious imho. Say a new field "foo" were added to siginfo. We would
almost certainly reject a patch that would add an extra info->foo = 0
into all places where siginfo is initialized as being unnecessary unless
there was severe potential for confusion which I don't think is the case
here when removing this in favor of just relying on clear_siginfo(). But
as I said I don't have a strong opinion. I've picked this up but I'm
happy to drop it if other maintainers agree with you.

Christian

> 
> On Sun, Dec 20, 2020 at 03:21:35PM +0100, Oleg Nesterov wrote:
> > On 12/20, Leesoo Ahn wrote:
> > >
> > > clear_siginfo() is responsible for clearing struct kernel_siginfo object.
> > > It's obvious that manually initializing those fields is needless as
> > > a commit[1] explains why the function introduced and its guarantee that
> > > all bits in the struct are cleared after it.
> > >
> > > [1]: commit 8c5dbf2ae00b ("signal: Introduce clear_siginfo")
> > >
> > > Signed-off-by: Leesoo Ahn 
> > 
> > Acked-by: Oleg Nesterov 
> > 
> > 
> > > ---
> > >  kernel/signal.c | 21 -
> > >  1 file changed, 21 deletions(-)
> > > 
> > > diff --git a/kernel/signal.c b/kernel/signal.c
> > > index 5736c55aaa1a..8f49fa3ade33 100644
> > > --- a/kernel/signal.c
> > > +++ b/kernel/signal.c
> > > @@ -603,10 +603,7 @@ static void collect_signal(int sig, struct 
> > > sigpending *list, kernel_siginfo_t *i
> > >*/
> > >   clear_siginfo(info);
> > >   info->si_signo = sig;
> > > - info->si_errno = 0;
> > >   info->si_code = SI_USER;
> > > - info->si_pid = 0;
> > > - info->si_uid = 0;
> > >   }
> > >  }
> > >  
> > > @@ -1120,7 +1117,6 @@ static int __send_signal(int sig, struct 
> > > kernel_siginfo *info, struct task_struc
> > >   case (unsigned long) SEND_SIG_NOINFO:
> > >   clear_siginfo(&q->info);
> > >   q->info.si_signo = sig;
> > > - q->info.si_errno = 0;
> > >   q->info.si_code = SI_USER;
> > >   q->info.si_pid = task_tgid_nr_ns(current,
> > >   task_active_pid_ns(t));
> > > @@ -1133,10 +1129,7 @@ static int __send_signal(int sig, struct 
> > > kernel_siginfo *info, struct task_struc
> > >   case (unsigned long) SEND_SIG_PRIV:
> > >   clear_siginfo(&q->info);
> > >   q->info.si_signo = sig;
> > > - q->info.si_errno = 0;
> > >   q->info.si_code = SI_KERNEL;
> > > - q->info.si_pid = 0;
> > > - q->info.si_uid = 0;
> > >   break;
> > >   default:
> > >   copy_siginfo(&q->info, info);
> > > @@ -1623,10 +1616,7 @@ void force_sig(int sig)
> > >  
> > >   clear_siginfo(&info);
> > >   info.si_signo = sig;
> > > - info.si_errno = 0;
> > >   info.si_code = SI_KERNEL;
> > > - info.si_pid = 0;
> > > - info.si_uid = 0;
> > >   force_sig_info(&info);
> > >  }
> > >  EXPORT_SYMBOL(force_sig);
> > > @@ -1659,7 +1649,6 @@ int force_sig_fault_to_task(int sig, int code, void 
> > > __user *addr
> > >  
> > >   clear_siginfo(&info);
> > >   info.si_signo = sig;
> > > - info.si_errno = 0;
> > >   info.si_code  = code;
> > >   info.si_addr  = addr;
> > >  #ifdef __ARCH_SI_TRAPNO
> > > @@ -1691,7 +1680,6 @@ int send_sig_fault(int sig, int code, void __user 
> > > *addr
> > >  
> > >   clear_siginfo(&info);
> > >   info.si_signo = sig;
> > > - info.si_errno = 0;
> > >   info.si_code  = code;
> > >   info.si_addr  = addr;
> > >  #ifdef __ARCH_SI_TRAPNO
> > > @@ -1712,7 +1700,6 @@ int force_sig_mceerr(int code, void __user *addr, 
> > > short lsb)
> > >   WARN_ON((code != BUS_MCEERR_AO) && (code != BUS_MCEERR_AR));
> > >   clear_siginfo(&info);
> > >   info.si_signo = SIGBUS;
> > > - info.si_errno = 0;
> > >   info.si_code = code;
> > >   info.si_addr = addr;
> > >   info.si_addr_lsb = lsb;
> > > @@ -1726,7 +1713,6 @@ int send_sig_mceerr(int code, void __user *addr, 
> > > short lsb, struct task_struct *
> > >   WARN_ON((code != BUS_MCEERR_AO) && (code != BUS_MCEERR_AR));
> > >   clear_siginfo(&info);
> > >   info.si_signo = SIGBUS;
> > > - info.si_errno = 0;
> > >   info.si_code = code;
> > >   info.si_addr = addr;
> > >   info.si_addr_lsb = lsb;
> > > @@ -1740,7 +1726,6 @@ int force_sig_bn

Re: [PATCH v4 1/9] media: uvcvideo: Move guid to entity

[Laurent Pinchart]

Hi Ricardo,

Thank you for the patch.

On Tue, Dec 15, 2020 at 04:44:31PM +0100, Ricardo Ribalda wrote:
> Instead of having multiple copies of the entity guid on the code, move
> it to the entity structure.
> 
> Reviewed-by: Laurent Pinchart 
> Signed-off-by: Ricardo Ribalda 
> ---
>  drivers/media/usb/uvc/uvc_ctrl.c   | 30 --
>  drivers/media/usb/uvc/uvc_driver.c | 26 --
>  drivers/media/usb/uvc/uvcvideo.h   |  2 +-
>  3 files changed, 29 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c 
> b/drivers/media/usb/uvc/uvc_ctrl.c
> index 011e69427b7c..9f6174a10e73 100644
> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> @@ -826,31 +826,10 @@ static void uvc_set_le_value(struct uvc_control_mapping 
> *mapping,
>   * Terminal and unit management
>   */
>  
> -static const u8 uvc_processing_guid[16] = UVC_GUID_UVC_PROCESSING;
> -static const u8 uvc_camera_guid[16] = UVC_GUID_UVC_CAMERA;
> -static const u8 uvc_media_transport_input_guid[16] =
> - UVC_GUID_UVC_MEDIA_TRANSPORT_INPUT;
> -
>  static int uvc_entity_match_guid(const struct uvc_entity *entity,
> - const u8 guid[16])
> +  const u8 guid[16])
>  {
> - switch (UVC_ENTITY_TYPE(entity)) {
> - case UVC_ITT_CAMERA:
> - return memcmp(uvc_camera_guid, guid, 16) == 0;
> -
> - case UVC_ITT_MEDIA_TRANSPORT_INPUT:
> - return memcmp(uvc_media_transport_input_guid, guid, 16) == 0;
> -
> - case UVC_VC_PROCESSING_UNIT:
> - return memcmp(uvc_processing_guid, guid, 16) == 0;
> -
> - case UVC_VC_EXTENSION_UNIT:
> - return memcmp(entity->extension.guidExtensionCode,
> -   guid, 16) == 0;
> -
> - default:
> - return 0;
> - }
> + return memcmp(entity->guid, guid, sizeof(entity->guid)) == 0;
>  }
>  
>  /* 
> @@ -1776,8 +1755,7 @@ static int uvc_ctrl_fill_xu_info(struct uvc_device *dev,
>   if (data == NULL)
>   return -ENOMEM;
>  
> - memcpy(info->entity, ctrl->entity->extension.guidExtensionCode,
> -sizeof(info->entity));
> + memcpy(info->entity, ctrl->entity->guid, sizeof(info->entity));
>   info->index = ctrl->index;
>   info->selector = ctrl->index + 1;
>  
> @@ -1883,7 +1861,7 @@ int uvc_xu_ctrl_query(struct uvc_video_chain *chain,
>  
>   if (!found) {
>   uvc_trace(UVC_TRACE_CONTROL, "Control %pUl/%u not found.\n",
> - entity->extension.guidExtensionCode, xqry->selector);
> + entity->guid, xqry->selector);
>   return -ENOENT;
>   }
>  
> diff --git a/drivers/media/usb/uvc/uvc_driver.c 
> b/drivers/media/usb/uvc/uvc_driver.c
> index ddb9eaa11be7..4cdd65d252d9 100644
> --- a/drivers/media/usb/uvc/uvc_driver.c
> +++ b/drivers/media/usb/uvc/uvc_driver.c
> @@ -1019,6 +1019,11 @@ static int uvc_parse_streaming(struct uvc_device *dev,
>   return ret;
>  }
>  
> +static const u8 uvc_camera_guid[16] = UVC_GUID_UVC_CAMERA;
> +static const u8 uvc_media_transport_input_guid[16] =
> + UVC_GUID_UVC_MEDIA_TRANSPORT_INPUT;
> +static const u8 uvc_processing_guid[16] = UVC_GUID_UVC_PROCESSING;
> +
>  static struct uvc_entity *uvc_alloc_entity(u16 type, u8 id,
>   unsigned int num_pads, unsigned int extra_size)
>  {
> @@ -1038,6 +1043,23 @@ static struct uvc_entity *uvc_alloc_entity(u16 type, 
> u8 id,
>   entity->id = id;
>   entity->type = type;
>  
> +

Nearly there, just one blank line to remove :-) I'll fix this when
applying.

> + /*
> +  * Set the GUID for standard entity types. For extension units, the GUID
> +  * is initialized by the caller.
> +  */
> + switch (type) {
> + case UVC_ITT_CAMERA:
> + memcpy(entity->guid, uvc_camera_guid, 16);
> + break;
> + case UVC_ITT_MEDIA_TRANSPORT_INPUT:
> + memcpy(entity->guid, uvc_media_transport_input_guid, 16);
> + break;
> + case UVC_VC_PROCESSING_UNIT:
> + memcpy(entity->guid, uvc_processing_guid, 16);
> + break;
> + }
> +
>   entity->num_links = 0;
>   entity->num_pads = num_pads;
>   entity->pads = ((void *)(entity + 1)) + extra_size;
> @@ -1109,7 +1131,7 @@ static int uvc_parse_vendor_control(struct uvc_device 
> *dev,
>   if (unit == NULL)
>   return -ENOMEM;
>  
> - memcpy(unit->extension.guidExtensionCode, &buffer[4], 16);
> + memcpy(unit->guid, &buffer[4], 16);
>   unit->extension.bNumControls = buffer[20];
>   memcpy(unit->baSourceID, &buffer[22], p);
>   unit->extension.bControlSize = buffer[22+p];
> @@ -1368,7 +1390,7 @@ static int uvc_parse_standard_control(struct uvc_device 
> *dev,
>   if (unit == NULL)
>   re

Re: [PATCH v4 3/9] media: uvcvideo: Allow entities with no pads

[Laurent Pinchart]

Hi Ricardo,

Thank you for the patch.

On Tue, Dec 15, 2020 at 04:44:33PM +0100, Ricardo Ribalda wrote:
> Avoid an underflow while calculating the number of inputs for entities
> with zero pads.
> 
> Signed-off-by: Ricardo Ribalda 
> ---
>  drivers/media/usb/uvc/uvc_driver.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_driver.c 
> b/drivers/media/usb/uvc/uvc_driver.c
> index 9f4451a2e0a6..534629ecd60d 100644
> --- a/drivers/media/usb/uvc/uvc_driver.c
> +++ b/drivers/media/usb/uvc/uvc_driver.c
> @@ -1033,7 +1033,11 @@ static struct uvc_entity *uvc_alloc_entity(u16 type, 
> u16 id,
>   unsigned int i;
>  
>   extra_size = roundup(extra_size, sizeof(*entity->pads));
> - num_inputs = (type & UVC_TERM_OUTPUT) ? num_pads : num_pads - 1;
> + if (num_pads)
> + num_inputs = (type & UVC_TERM_OUTPUT) ? num_pads :
> + num_pads - 1;

This is a weird indentation. How about the following ?

num_inputs = type & UVC_TERM_OUTPUT ? num_pads : num_pads - 1;

I can fix this when applying.

Reviewed-by: Laurent Pinchart 

> + else
> + num_inputs = 0;
>   size = sizeof(*entity) + extra_size + sizeof(*entity->pads) * num_pads
>+ num_inputs;
>   entity = kzalloc(size, GFP_KERNEL);
> @@ -1066,7 +1070,7 @@ static struct uvc_entity *uvc_alloc_entity(u16 type, 
> u16 id,
>  
>   for (i = 0; i < num_inputs; ++i)
>   entity->pads[i].flags = MEDIA_PAD_FL_SINK;
> - if (!UVC_ENTITY_IS_OTERM(entity))
> + if (!UVC_ENTITY_IS_OTERM(entity) && num_pads)
>   entity->pads[num_pads-1].flags = MEDIA_PAD_FL_SOURCE;
>  
>   entity->bNrInPins = num_inputs;

-- 
Regards,

Laurent Pinchart

Re: [PATCH v4 4/9] media: uvcvideo: Entity defined get_info and get_cur

[Laurent Pinchart]

Hi Ricardo,

Thank you for the patch.

Maybe s/Entity defined/Allow entity-defined/ in the subject line ?

On Tue, Dec 15, 2020 at 04:44:34PM +0100, Ricardo Ribalda wrote:
> Allows controls to get their properties and current value
> from an entity-defined function instead of via a query to the USB
> device.
> 
> Signed-off-by: Ricardo Ribalda 
> ---
>  drivers/media/usb/uvc/uvc_ctrl.c | 22 ++
>  drivers/media/usb/uvc/uvcvideo.h |  5 +
>  2 files changed, 23 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c 
> b/drivers/media/usb/uvc/uvc_ctrl.c
> index 9f6174a10e73..531816762892 100644
> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> @@ -980,10 +980,20 @@ static int __uvc_ctrl_get(struct uvc_video_chain *chain,
>   return -EACCES;
>  
>   if (!ctrl->loaded) {
> - ret = uvc_query_ctrl(chain->dev, UVC_GET_CUR, ctrl->entity->id,
> - chain->dev->intfnum, ctrl->info.selector,
> + if (ctrl->entity->get_cur) {
> + ret = ctrl->entity->get_cur(chain->dev,
> + ctrl->entity,
> + ctrl->info.selector,
>   uvc_ctrl_data(ctrl, UVC_CTRL_DATA_CURRENT),
>   ctrl->info.size);
> + } else {
> + ret = uvc_query_ctrl(chain->dev, UVC_GET_CUR,
> + ctrl->entity->id,
> + chain->dev->intfnum,
> + ctrl->info.selector,
> + uvc_ctrl_data(ctrl, UVC_CTRL_DATA_CURRENT),
> + ctrl->info.size);

We could possibly set entity->get_cur by default to a function wrapping
uvc_query_ctrl() to avoid the condition here. This isn't mandatory for
now though, but I'll toy with it on top of the series to avoid storing
function pointers in a non-const structure.

Reviewed-by: Laurent Pinchart 

> + }
>   if (ret < 0)
>   return ret;
>  
> @@ -1687,8 +1697,12 @@ static int uvc_ctrl_get_flags(struct uvc_device *dev,
>   if (data == NULL)
>   return -ENOMEM;
>  
> - ret = uvc_query_ctrl(dev, UVC_GET_INFO, ctrl->entity->id, dev->intfnum,
> -  info->selector, data, 1);
> + if (ctrl->entity->get_info)
> + ret = ctrl->entity->get_info(dev, ctrl->entity,
> +  ctrl->info.selector, data);
> + else
> + ret = uvc_query_ctrl(dev, UVC_GET_INFO, ctrl->entity->id,
> +  dev->intfnum, info->selector, data, 1);
>   if (!ret)
>   info->flags |= (data[0] & UVC_CONTROL_CAP_GET ?
>   UVC_CTRL_FLAG_GET_CUR : 0)
> diff --git a/drivers/media/usb/uvc/uvcvideo.h 
> b/drivers/media/usb/uvc/uvcvideo.h
> index 00f985001c1d..ae464ba83f4f 100644
> --- a/drivers/media/usb/uvc/uvcvideo.h
> +++ b/drivers/media/usb/uvc/uvcvideo.h
> @@ -353,6 +353,11 @@ struct uvc_entity {
>   u8 bNrInPins;
>   u8 *baSourceID;
>  
> + int (*get_info)(struct uvc_device *dev, struct uvc_entity *entity,
> + u8 cs, u8 *caps);
> + int (*get_cur)(struct uvc_device *dev, struct uvc_entity *entity,
> +u8 cs, void *data, u16 size);
> +
>   unsigned int ncontrols;
>   struct uvc_control *controls;
>  };

-- 
Regards,

Laurent Pinchart

Re: [PATCH] clk: mvebu: a3700: fix the XTAL MODE pin to MPP1_9

[Pali Rohár]

On Saturday 19 December 2020 15:51:30 Stephen Boyd wrote:
> Quoting Pali Rohár (2020-11-06 02:00:39)
> > From: Terry Zhou 
> > 
> > There is an error in the current code that the XTAL MODE
> > pin was set to NB MPP1_31 which should be NB MPP1_9.
> > The latch register of NB MPP1_9 has different offset of 0x8.
> > 
> > Signed-off-by: Terry Zhou 
> > [pali: Fix pin name in commit message]
> > Signed-off-by: Pali Rohár 
> > Fixes: 7ea8250406a6 ("clk: mvebu: Add the xtal clock for Armada 3700 SoC")
> > Cc: sta...@vger.kernel.org
> > 
> > ---
> 
> Applied to clk-next

Hello Stephen! As this is fix also for stable releases, could you please
queue this patch for 5.11 release?

Re: [PATCH] cpufreq: intel_pstate: Use most recent guaranteed performance values

[Rafael J. Wysocki]

On Sat, Dec 19, 2020 at 6:21 AM srinivas pandruvada
 wrote:
>
> On Thu, 2020-12-17 at 20:17 +0100, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki 
> >
> > When turbo has been disabled by the BIOS, but HWP_CAP.GUARANTEED is
> > changed later, user space may want to take advantage of this
> > increased
> > guaranteed performance.
> >
> > HWP_CAP.GUARANTEED is not a static value.  It can be adjusted by an
> > out-of-band agent or during an Intel Speed Select performance level
> > change.  The HWP_CAP.MAX is still the maximum achievable performance
> > with turbo disabled by the BIOS, so HWP_CAP.GUARANTEED can still
> > change as long as it remains less than or equal to HWP_CAP.MAX.
> >
> > When HWP_CAP.GUARANTEED is changed, the sysfs base_frequency
> > attribute shows the most recent guaranteed frequency value. This
> > attribute can be used by user space software to update the scaling
> > min/max limits of the CPU.
> >
> > Currently, the ->setpolicy() callback already uses the latest
> > HWP_CAP values when setting HWP_REQ, but the ->verify() callback will
> > restrict the user settings to the to old guaranteed performance value
> > which prevents user space from making use of the extra CPU capacity
> > theoretically available to it after increasing HWP_CAP.GUARANTEED.
> >
> > To address this, read HWP_CAP in intel_pstate_verify_cpu_policy()
> > to obtain the maximum P-state that can be used and use that to
> > confine the policy max limit instead of using the cached and
> > possibly stale pstate.max_freq value for this purpose.
> >
> > For consistency, update intel_pstate_update_perf_limits() to use the
> > maximum available P-state returned by intel_pstate_get_hwp_max() to
> > compute the maximum frequency instead of using the return value of
> > intel_pstate_get_max_freq() which, again, may be stale.
> >
> > This issue is a side-effect of fixing the scaling frequency limits in
> > commit eacc9c5a927e ("cpufreq: intel_pstate: Fix
> > intel_pstate_get_hwp_max()
> > for turbo disabled") which currected
> corrected

Right, thanks!

[PATCH] block: aoe: replace use of __constant_htons to htons

[Amey Narkhede]

The macro htons expands to __swab16 which has special
case for constants in little endian case. In big
endian case both __constant_htons and htons macros
expand to the same code. So, replace __constant_htons
with htons to get rid of the definition of __constant_htons
completely.

Signed-off-by: Amey Narkhede 
---
 drivers/block/aoe/aoecmd.c | 2 +-
 drivers/block/aoe/aoenet.c | 3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/block/aoe/aoecmd.c b/drivers/block/aoe/aoecmd.c
index 313f0b946fe2..7a5374a57b55 100644
--- a/drivers/block/aoe/aoecmd.c
+++ b/drivers/block/aoe/aoecmd.c
@@ -69,7 +69,7 @@ new_skb(ulong len)
skb_reserve(skb, MAX_HEADER);
skb_reset_mac_header(skb);
skb_reset_network_header(skb);
-   skb->protocol = __constant_htons(ETH_P_AOE);
+   skb->protocol = htons(ETH_P_AOE);
skb_checksum_none_assert(skb);
}
return skb;
diff --git a/drivers/block/aoe/aoenet.c b/drivers/block/aoe/aoenet.c
index 63773a90581d..2532e35774e0 100644
--- a/drivers/block/aoe/aoenet.c
+++ b/drivers/block/aoe/aoenet.c
@@ -192,7 +192,7 @@ aoenet_rcv(struct sk_buff *skb, struct net_device *ifp, 
struct packet_type *pt,
 }

 static struct packet_type aoe_pt __read_mostly = {
-   .type = __constant_htons(ETH_P_AOE),
+   .type = htons(ETH_P_AOE),
.func = aoenet_rcv,
 };

@@ -220,4 +220,3 @@ aoenet_exit(void)
skb_queue_purge(&skbtxq);
dev_remove_pack(&aoe_pt);
 }
-
--
2.29.2