RE: [PATCH v22 2/4] scsi: ufs: L2P map management for HPB read
> + if (!ufshpb_is_hpb_rsp_valid(hba, lrbp, rsp_field))
> + return;
> +
> + hpb->stats.rb_noti_cnt++;
> + switch (rsp_field->hpb_op) {
> + case HPB_RSP_NONE:
> + /* nothing to do */
> + break;
Maybe checks this too in ufshpb_is_hpb_rsp_valid
> + case HPB_RSP_REQ_REGION_UPDATE:
> + WARN_ON(data_seg_len != DEV_DATA_SEG_LEN);
> + ufshpb_rsp_req_region_update(hpb, rsp_field);
> + break;
> + case HPB_RSP_DEV_RESET:
> + dev_warn(>sdev_ufs_lu->sdev_dev,
> +"UFS device lost HPB information during PM.\n");
> + break;
> + default:
> + dev_notice(>sdev_ufs_lu->sdev_dev,
> + "hpb_op is not available: %d\n",
> + rsp_field->hpb_op);
> + break;
> + }
> +}
Re: [PATCH v3 4/4] PCI: j721e: Add support to provide refclk to PCIe connector
Hi Kishon,
url:
https://github.com/0day-ci/linux/commits/Kishon-Vijay-Abraham-I/AM64-Add-PCIe-bindings-and-driver-support/20210222-194422
base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: i386-randconfig-m021-20210222 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
Reported-by: Dan Carpenter
smatch warnings:
drivers/pci/controller/cadence/pci-j721e.c:420 j721e_pcie_probe() warn: missing
error code 'ret'
vim +/ret +420 drivers/pci/controller/cadence/pci-j721e.c
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 305 static int
j721e_pcie_probe(struct platform_device *pdev)
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 306 {
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 307 struct device *dev =
>dev;
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 308 struct device_node
*node = dev->of_node;
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 309 struct pci_host_bridge
*bridge;
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 310 struct j721e_pcie_data
*data;
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 311 struct cdns_pcie
*cdns_pcie;
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 312 struct j721e_pcie *pcie;
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 313 struct cdns_pcie_rc *rc;
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 314 struct cdns_pcie_ep *ep;
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 315 struct gpio_desc *gpiod;
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 316 void __iomem *base;
c77817a9fba361 Kishon Vijay Abraham I 2021-02-22 317 struct clk *clk;
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 318 u32 num_lanes;
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 319 u32 mode;
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 320 int ret;
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 321 int irq;
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 322
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 323 data = (struct
j721e_pcie_data *)of_device_get_match_data(dev);
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 324 if (!data)
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 325 return -EINVAL;
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 326
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 327 mode = (u32)data->mode;
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 328
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 329 pcie =
devm_kzalloc(dev, sizeof(*pcie), GFP_KERNEL);
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 330 if (!pcie)
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 331 return -ENOMEM;
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 332
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 333 pcie->dev = dev;
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 334 pcie->mode = mode;
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 335
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 336 base =
devm_platform_ioremap_resource_byname(pdev, "intd_cfg");
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 337 if (IS_ERR(base))
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 338 return
PTR_ERR(base);
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 339 pcie->intd_cfg_base =
base;
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 340
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 341 base =
devm_platform_ioremap_resource_byname(pdev, "user_cfg");
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 342 if (IS_ERR(base))
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 343 return
PTR_ERR(base);
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 344 pcie->user_cfg_base =
base;
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 345
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 346 ret =
of_property_read_u32(node, "num-lanes", _lanes);
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 347 if (ret || num_lanes >
MAX_LANES)
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 348 num_lanes = 1;
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 349 pcie->num_lanes =
num_lanes;
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 350
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 351 if
(dma_set_mask_and_coherent(dev, DMA_BIT_MASK(48)))
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 352 return -EINVAL;
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 353
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 354 irq =
platform_get_irq_byname(pdev, "link_state");
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 355 if (irq < 0)
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 356 return irq;
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 357
f3e25911a430ed Kishon Vijay Abraham I 2020-07-22 358 dev_set_drvdata(dev,
pcie);
f3e2591
Re: [PATCH 02/13] dt-bindings: firmware: scm: Add SC7280 support
Quoting Rajendra Nayak (2021-02-11 23:28:39) > Add compatible for SC7280 SoC > > Signed-off-by: Rajendra Nayak > --- Reviewed-by: Stephen Boyd
Re: [PATCH 01/13] dt-bindings: arm: qcom: Document SC7280 SoC and board
Quoting Rajendra Nayak (2021-02-11 23:28:38) > Document the SC7280 SoC and the IDP board bindings > > Signed-off-by: Rajendra Nayak > --- Reviewed-by: Stephen Boyd
RE: [PATCH v22 2/4] scsi: ufs: L2P map management for HPB read
> +/*
> + * This function will parse recommended active subregion information in
> sense
> + * data field of response UPIU with SAM_STAT_GOOD state.
> + */
> +void ufshpb_rsp_upiu(struct ufs_hba *hba, struct ufshcd_lrb *lrbp)
> +{
> + struct ufshpb_lu *hpb;
> + struct scsi_device *sdev;
> + struct utp_hpb_rsp *rsp_field = >ucd_rsp_ptr->hr;
> + int data_seg_len;
> + bool found = false;
> +
> + __shost_for_each_device(sdev, hba->host) {
> + hpb = ufshpb_get_hpb_data(sdev);
> +
> + if (!hpb)
> + continue;
> +
> + if (rsp_field->lun == hpb->lun) {
> + found = true;
> + break;
This piece of code looks awkward, although it is probably working.
Why not just having a reference to the hpb luns, e.g. something like:
struct ufshpb_lu *hpb_luns[8] in struct ufs_hba.
Less elegant - but much more effective than iterating the scsi host on every
completion interrupt.
> + }
> + }
> +
> + if (!found)
> + return;
> +
> + if ((ufshpb_get_state(hpb) != HPB_PRESENT) &&
> + (ufshpb_get_state(hpb) != HPB_SUSPEND)) {
> + dev_notice(>sdev_ufs_lu->sdev_dev,
> + "%s: ufshpb state is not PRESENT/SUSPEND\n",
> + __func__);
> + return;
> + }
> +
> + data_seg_len = be32_to_cpu(lrbp->ucd_rsp_ptr->header.dword_2)
> + & MASK_RSP_UPIU_DATA_SEG_LEN;
> +
> + /* To flush remained rsp_list, we queue the map_work task */
> + if (!data_seg_len) {
data_seg_len should be 0x14
> + if (!ufshpb_is_general_lun(hpb->lun))
> + return;
> +
> + ufshpb_kick_map_work(hpb);
> + return;
> + }
> +
> + /* Check HPB_UPDATE_ALERT */
> + if (!(lrbp->ucd_rsp_ptr->header.dword_2 &
> + UPIU_HEADER_DWORD(0, 2, 0, 0)))
> + return;
> +
> + BUILD_BUG_ON(sizeof(struct utp_hpb_rsp) != UTP_HPB_RSP_SIZE);
> +
> + if (!ufshpb_is_hpb_rsp_valid(hba, lrbp, rsp_field))
> + return;
How about moving both the data_seg_len and alert bit checks into
ufshpb_is_hpb_rsp_valid,
And moving ufshpb_is_hpb_rsp_valid to the beginning of the function?
This way you would save redundant stuff if not a valid response.
Thanks,
Avri
Re: [PATCH 13/13] arm64: dts: qcom: sc7280: Add cpuidle states
Quoting Rajendra Nayak (2021-02-11 23:28:50)
> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> index 8f2002b..3b86052 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> @@ -186,12 +207,69 @@
> compatible = "arm,kryo";
> reg = <0x0 0x700>;
> enable-method = "psci";
> + cpu-idle-states = <_CPU_SLEEP_0
> + _CPU_SLEEP_1
> + _SLEEP_0>;
> next-level-cache = <_700>;
> L2_700: l2-cache {
> compatible = "cache";
> next-level-cache = <_0>;
> };
> };
> +
> + idle-states {
> + entry-method = "psci";
> +
> + LITTLE_CPU_SLEEP_0: cpu-sleep-0-0 {
> + compatible = "arm,idle-state";
> + idle-state-name = "little-power-down";
> + arm,psci-suspend-param = <0x4003>;
> + entry-latency-us = <549>;
> + exit-latency-us = <901>;
> + min-residency-us = <1774>;
Are these preliminary numbers? They're the same as sc7180 from what I
can tell, but presumably things changed between SoC versions?
> + local-timer-stop;
> + };
> +
> + LITTLE_CPU_SLEEP_1: cpu-sleep-0-1 {
> + compatible = "arm,idle-state";
> + idle-state-name = "little-rail-power-down";
> + arm,psci-suspend-param = <0x4004>;
> + entry-latency-us = <702>;
> + exit-latency-us = <915>;
> + min-residency-us = <4001>;
> + local-timer-stop;
> + };
> +
> + BIG_CPU_SLEEP_0: cpu-sleep-1-0 {
> + compatible = "arm,idle-state";
> + idle-state-name = "big-power-down";
> + arm,psci-suspend-param = <0x4003>;
> + entry-latency-us = <523>;
> + exit-latency-us = <1244>;
> + min-residency-us = <2207>;
Re: [PATCH v2 0/7] Allocate memmap from hotadded memory (per device)
On Mon, Feb 22, 2021 at 12:28:22PM +0100, David Hildenbrand wrote: > -EBUSY, will try having a look this week! sure, thanks for the effort David ;-) -- Oscar Salvador SUSE L3
[PATCH] i2c/busses:remove unneeded variable: "ret"
From: dingsenjie
remove unneeded variable: "ret".
Signed-off-by: dingsenjie
---
drivers/i2c/busses/i2c-aspeed.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
index 724bf30..efad900 100644
--- a/drivers/i2c/busses/i2c-aspeed.c
+++ b/drivers/i2c/busses/i2c-aspeed.c
@@ -175,7 +175,6 @@ struct aspeed_i2c_bus {
static int aspeed_i2c_recover_bus(struct aspeed_i2c_bus *bus)
{
unsigned long time_left, flags;
- int ret = 0;
u32 command;
spin_lock_irqsave(>lock, flags);
@@ -232,7 +231,7 @@ static int aspeed_i2c_recover_bus(struct aspeed_i2c_bus
*bus)
out:
spin_unlock_irqrestore(>lock, flags);
- return ret;
+ return 0;
reset_out:
spin_unlock_irqrestore(>lock, flags);
--
1.9.1
[tip:x86/entry] BUILD SUCCESS 724c8a23d589d8a002d2e39633c2f9a5a429616f
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/entry branch HEAD: 724c8a23d589d8a002d2e39633c2f9a5a429616f objtool: Fix stack-swizzle for FRAME_POINTER=y elapsed time: 726m configs tested: 104 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig powerpc akebono_defconfig x86_64 alldefconfig mipsgpr_defconfig powerpc mpc836x_mds_defconfig sh ap325rxa_defconfig mips ip27_defconfig sh rts7751r2dplus_defconfig mipsbcm63xx_defconfig m68k m5475evb_defconfig powerpc mgcoge_defconfig m68k sun3x_defconfig armmulti_v5_defconfig arm simpad_defconfig powerpc mpc837x_rdb_defconfig armclps711x_defconfig powerpc ep88xc_defconfig powerpc mpc8315_rdb_defconfig powerpc mpc885_ads_defconfig openrisc or1klitex_defconfig m68km5307c3_defconfig mipsomega2p_defconfig powerpc sbc8548_defconfig powerpcwarp_defconfig powerpc bamboo_defconfig powerpcmpc7448_hpc2_defconfig mips tb0226_defconfig arm multi_v4t_defconfig openrisc simple_smp_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig s390 allmodconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386 tinyconfig i386defconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a001-20210222 x86_64 randconfig-a002-20210222 x86_64 randconfig-a003-20210222 x86_64 randconfig-a005-20210222 x86_64 randconfig-a006-20210222 x86_64 randconfig-a004-20210222 i386 randconfig-a005-20210222 i386 randconfig-a006-20210222 i386 randconfig-a004-20210222 i386 randconfig-a003-20210222 i386 randconfig-a001-20210222 i386 randconfig-a002-20210222 i386 randconfig-a013-20210222 i386 randconfig-a012-20210222 i386 randconfig-a011-20210222 i386 randconfig-a014-20210222 i386 randconfig-a016-20210222 i386 randconfig-a015-20210222 riscvnommu_k210_defconfig riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig riscvallmodconfig x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 rhel-8.3-kbuiltin x86_64 kexec clang tested configs: x86_64 randconfig-a015-20210222 x86_64 randconfig-a011-20210222 x86_64
Re: [PATCH 11/13] arm64: dts: qcom: sc7280: Add APSS watchdog node
Quoting Rajendra Nayak (2021-02-11 23:28:48) > From: Sai Prakash Ranjan > > Add APSS (Application Processor Subsystem) watchdog > DT node for SC7280 SoC. > > Signed-off-by: Sai Prakash Ranjan > Signed-off-by: Rajendra Nayak > --- Reviewed-by: Stephen Boyd
Re: [PATCH v3] erofs: support adjust lz4 history window size
On Tue, Feb 23, 2021 at 03:31:19PM +0800, Huang Jianan via Linux-erofs wrote:
> lz4 uses LZ4_DISTANCE_MAX to record history preservation. When
> using rolling decompression, a block with a higher compression
> ratio will cause a larger memory allocation (up to 64k). It may
> cause a large resource burden in extreme cases on devices with
> small memory and a large number of concurrent IOs. So appropriately
> reducing this value can improve performance.
>
> Decreasing this value will reduce the compression ratio (except
> when input_size currently only supports 4k output, reducing this value will not
> significantly reduce the compression benefits.
>
> The maximum value of LZ4_DISTANCE_MAX defined by lz4 is 64k, and
> we can only reduce this value. For the old kernel, it just can't
> reduce the memory allocation during rolling decompression without
> affecting the decompression result.
>
> Signed-off-by: Huang Jianan
> Signed-off-by: Guo Weichao
> ---
>
> change since v2:
> - use z_erofs_load_lz4_config to calculate lz4_distance_pages
> - add description about the compatibility of the old kernel version
> - drop useless comment
>
> fs/erofs/decompressor.c | 22 ++
> fs/erofs/erofs_fs.h | 3 ++-
> fs/erofs/internal.h | 7 +++
> fs/erofs/super.c| 2 ++
> 4 files changed, 29 insertions(+), 5 deletions(-)
>
> diff --git a/fs/erofs/decompressor.c b/fs/erofs/decompressor.c
> index 1cb1ffd10569..0bb7903e3f9b 100644
> --- a/fs/erofs/decompressor.c
> +++ b/fs/erofs/decompressor.c
> @@ -28,6 +28,18 @@ struct z_erofs_decompressor {
> char *name;
> };
>
> +int z_erofs_load_lz4_config(struct erofs_sb_info *sbi,
> + struct erofs_super_block *dsb)
> +{
> + u16 distance = le16_to_cpu(dsb->lz4_max_distance);
> +
> + sbi->lz4_max_distance_pages = distance ?
> + (DIV_ROUND_UP(distance, PAGE_SIZE) + 1)
> :
Unneeded parentheses here (I'll update it when applying).
Otherwise it looks good to me.
Reviewed-by: Gao Xiang
Thanks,
Gao Xiang
Re: [PATCH 09/13] arm64: dts: qcom: Add reserved memory for fw
Quoting Rajendra Nayak (2021-02-11 23:28:46) > From: Maulik Shah > > Add fw reserved memory area for CPUCP and AOP. Does CPUCP stand for CPU Content Protection? AOP is Always On Processor. It would help if the commit text told us what these acronyms were. > > Signed-off-by: Maulik Shah > Signed-off-by: Rajendra Nayak > --- > arch/arm64/boot/dts/qcom/sc7280.dtsi | 10 ++ > 1 file changed, 10 insertions(+) >
Re: [PATCH 10/13] dt-bindings: watchdog: Add compatible for SC7280 SoC
Quoting Rajendra Nayak (2021-02-11 23:28:47) > From: Sai Prakash Ranjan > > Add compatible for watchdog timer on SC7280 SoC. > > Signed-off-by: Sai Prakash Ranjan > Signed-off-by: Rajendra Nayak > --- Reviewed-by: Stephen Boyd
Re: [PATCH 06/13] arm64: dts: qcom: SC7280: Add rpmhcc clock controller node
Quoting Rajendra Nayak (2021-02-11 23:28:43)
> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> index 7848e88..10851e7 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> @@ -6,6 +6,7 @@
> */
>
> #include
> +#include
> #include
> #include
>
> @@ -29,6 +30,42 @@
> clock-frequency = <32000>;
> #clock-cells = <0>;
> };
> +
> + pcie_0_pipe_clk: pcie-0-pipe-clk {
> + compatible = "fixed-clock";
> + clock-frequency = <1000>;
> + #clock-cells = <0>;
> + };
> +
> + pcie_1_pipe_clk: pcie-1-pipe-clk {
> + compatible = "fixed-clock";
> + clock-frequency = <1000>;
> + #clock-cells = <0>;
> + };
> +
> + ufs_phy_rx_symbol_0_clk: ufs-phy-rx-symbol-0-clk {
> + compatible = "fixed-clock";
> + clock-frequency = <1000>;
> + #clock-cells = <0>;
> + };
> +
> + ufs_phy_rx_symbol_1_clk: ufs-phy-rx-symbol-1-clk {
> + compatible = "fixed-clock";
> + clock-frequency = <1000>;
> + #clock-cells = <0>;
> + };
> +
> + ufs_phy_tx_symbol_0_clk: ufs-phy-tx-symbol-0-clk {
> + compatible = "fixed-clock";
> + clock-frequency = <1000>;
> + #clock-cells = <0>;
> + };
> +
> + usb3_phy_wrapper_gcc_usb30_pipe_clk:
> usb3-phy-wrapper-gcc-usb30-pipe-clk {
> + compatible = "fixed-clock";
> + clock-frequency = <1000>;
> + #clock-cells = <0>;
> + };
Shouldn't these come from the phys? Why are they being added here?
> };
>
> reserved_memory: reserved-memory {
> @@ -174,6 +211,17 @@
> gcc: clock-controller@10 {
> compatible = "qcom,gcc-sc7280";
> reg = <0 0x0010 0 0x1f>;
> + clocks = < RPMH_CXO_CLK>,
> +< RPMH_CXO_CLK_A>, <_clk>,
> +<_0_pipe_clk>, <_1_pipe_clk>,
> +<_phy_rx_symbol_0_clk>,
> <_phy_rx_symbol_1_clk>,
> +<_phy_tx_symbol_0_clk>,
> +<_phy_wrapper_gcc_usb30_pipe_clk>;
If the phys aren't ready then <0> should work. Unless something goes
wrong?
> + clock-names = "bi_tcxo", "bi_tcxo_ao", "sleep_clk",
> + "pcie_0_pipe_clk", "pcie_1_pipe-clk",
> + "ufs_phy_rx_symbol_0_clk",
> "ufs_phy_rx_symbol_1_clk",
> + "ufs_phy_tx_symbol_0_clk",
> + "usb3_phy_wrapper_gcc_usb30_pipe_clk";
> #clock-cells = <1>;
> #reset-cells = <1>;
> #power-domain-cells = <1>;
> @@ -325,6 +373,13 @@
> ,
> ,
> ;
> +
> + rpmhcc: qcom,rpmhcc {
rpmhcc: clock-controller {
> + compatible = "qcom,sc7280-rpmh-clk";
> + clocks = <_board>;
> + clock-names = "xo";
> + #clock-cells = <1>;
> + };
> };
> };
>
Re: [PATCH 07/13] dt-bindings: arm-smmu: Add compatible for SC7280 SoC
Quoting Rajendra Nayak (2021-02-11 23:28:44) > From: Sai Prakash Ranjan > > Add the SoC specific compatible for SC7280 implementing > arm,mmu-500. > > Signed-off-by: Sai Prakash Ranjan > Signed-off-by: Rajendra Nayak > --- Reviewed-by: Stephen Boyd
Re: [PATCH] f2fs: compress: Allow modular (de)compression algorithms
Hi Yamada-san,
On Tue, Feb 23, 2021 at 7:31 AM Masahiro Yamada wrote:
> On Mon, Feb 22, 2021 at 9:59 PM Geert Uytterhoeven
> wrote:
> > If F2FS_FS is modular, enabling the compressions options
> > F2FS_FS_{LZ4,LZ4HZ,LZO,LZORLE,ZSTD} will make the (de)compression
> > algorithms {LZ4,LZ4HC,LZO,ZSTD}_{,DE}COMPRESS builtin instead of
> > modular, as the former depend on an intermediate boolean
> > F2FS_FS_COMPRESSION, which in-turn depends on tristate F2FS_FS.
> >
> > Indeed, if a boolean symbol A depends directly on a tristate symbol B
> > and selects another tristate symbol C:
> >
> > tristate B
> >
> > tristate C
> >
> > bool A
> > depends on B
> > select C
> >
> > and B is modular, then C will also be modular.
> >
> > However, if there is an intermediate boolean D in the dependency chain
> > between A and B:
> >
> > tristate B
> >
> > tristate C
> >
> > bool D
> > depends on B
> >
> > bool A
> > depends on D
> > select C
> >
> > then the modular state won't propagate from B to C, and C will be
> > builtin instead of modular.
> >
> > Fix this by making the various compression options depend directly on
> > F2FS_FS using a big if/endif block. Drop the now superfluous
> > dependencies on F2FS_FS from individual symbols.
> >
> > Signed-off-by: Geert Uytterhoeven
> > ---
> > Perhaps the propagation logic in Kconfig should be fixed instead?
> > Else people may reintroduce this issue when removing seemingly-unneeded
> > dependencies.
>
> I checked the code in menu_finalize(), and this seems to work like this.
>
> I discussed the oddity of the select behavior before
> (https://lore.kernel.org/linux-kbuild/e1a6228d-1341-6264-d97a-e2bd52a65...@infradead.org/),
> but I was not confident about what the right direction was.
>
>
> Anyway, the behavior is obscure from the current code.
>
> If you want to make this more robust,
> you can write as follows:
>
> config F2FS_FS
> tristate "F2FS filesystem support"
> depends on BLOCK
> select NLS
> select CRYPTO
> select CRYPTO_CRC32
> select F2FS_FS_XATTR if FS_ENCRYPTION
> select FS_ENCRYPTION_ALGS if FS_ENCRYPTION
> select LZO_COMPRESS if F2FS_FS_LZO
> select LZO_DECOMPRESS if F2FS_FS_LZO
> select LZ4_COMPRESS if F2FS_FS_LZ4
> select LZ4_DECOMPRESS if F2FS_FS_LZ4
> select LZ4HC_COMPRESS if F2FS_FS_LZ4HC
> select ZSTD_COMPRESS if F2FS_FS_ZSTD
> select ZSTD_DECOMPRESS if F2FS_FS_ZSTD
>
> The code is a bit clumsy, but it is clear
> that the module (F2FS_FS) is selecting the
> compress/decompress libraries.
Actually the above is what I tried first ;-) Works fine.
Then I started to look for similar cases in other file systems (e.g.
EROFS_FS_ZIP), and discovered the issue doesn't happen there, which
sparked my investigation. So I settled on the direct dependency,
because it keeps all compression-related logic together.
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: [PATCH 05/13] arm64: dts: qcom: sc7280: Add RSC and PDC devices
Quoting Rajendra Nayak (2021-02-11 23:28:42)
> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> index 1fe2eba..7848e88 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> @@ -7,6 +7,7 @@
>
> #include
> #include
> +#include
>
> / {
> interrupt-parent = <>;
> @@ -30,6 +31,18 @@
> };
> };
>
> + reserved_memory: reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + aop_cmd_db_mem: memory@8086 {
> + reg = <0x0 0x8086 0x0 0x2>;
> + compatible = "qcom,cmd-db";
> + no-map;
> + };
> + };
> +
> cpus {
> #address-cells = <2>;
> #size-cells = <0>;
> @@ -189,6 +202,19 @@
> };
> };
>
> + pdc: interrupt-controller@b22 {
> + compatible = "qcom,sc7280-pdc", "qcom,pdc";
> + reg = <0 0xb22 0 0x3>;
Can you pad out reg to 8 digits? 0x0b22
> + qcom,pdc-ranges = <0 480 40>, <40 140 14>, <54 263 1>,
> + <55 306 4>, <59 312 3>, <62 374 2>,
> + <64 434 2>, <66 438 3>, <69 86 1>,
> + <70 520 54>, <124 609 31>, <155 63
> 1>,
> + <156 716 12>;
> + #interrupt-cells = <2>;
> + interrupt-parent = <>;
> + interrupt-controller;
> + };
> +
> tlmm: pinctrl@f10 {
> compatible = "qcom,sc7280-pinctrl";
> reg = <0 0xf10 0 0x100>;
The same applies to the previous patch. Sorry for missing that.
> @@ -198,6 +224,7 @@
> interrupt-controller;
> #interrupt-cells = <2>;
> gpio-ranges = < 0 0 175>;
> + wakeup-parent = <>;
>
> qup_uart5_default: qup-uart5-default {
> pins = "gpio46", "gpio47";
> @@ -282,6 +309,23 @@
> status = "disabled";
> };
> };
> +
> + apps_rsc: rsc@1820 {
> + compatible = "qcom,rpmh-rsc";
> + reg = <0 0x1820 0 0x1>,
> + <0 0x1821 0 0x1>,
> + <0 0x1822 0 0x1>;
> + reg-names = "drv-0", "drv-1", "drv-2";
> + interrupts = ,
> +,
> +;
> + qcom,tcs-offset = <0xd00>;
> + qcom,drv-id = <2>;
> + qcom,tcs-config = ,
> + ,
> + ,
> + ;
> + };
> };
Re: [GIT PULL]: dmaengine updates for 5.12-rc1
On 23-02-21, 09:45, Vinod Koul wrote: > Hello Linus, > > Please consider merging to get dmaengine updates for this cycle. We have > couple of drivers removed a new driver and bunch of new device support > and few updates to drivers for this round. Sorry, not sure why I tagged it as PULL REQUEST, fixed the subject line now! > > The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: > > Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine.git > tags/dmaengine-5.12-rc1 > > for you to fetch changes up to eda38ce482b2c88b27e3a7c8aa1ddffa646f3e7f: > > dmaengine: dw-axi-dmac: remove redundant null check on desc (2021-02-08 > 17:39:39 +0530) > > > dmaengine updates for v5.12-rc1 > > New drivers/devices > - Intel LGM SoC DMA driver > - Actions Semi S500 DMA controller > - Renesas r8a779a0 dma controller > - Ingenic JZ4760(B) dma controller > - Intel KeemBay AxiDMA controller > > Removed > - Coh901318 dma driver > - Zte zx dma driver > - Sirfsoc dma driver > > Updates: > - mmp_pdma, mmp_tdma gained module support > - imx-sdma become modern and dropped platform data support > - dw-axi driver gained slave and cyclic dma support > > > Alexandre Belloni (1): > dmaengine: at_hdmac: remove platform data header > > Amireddy Mallikarjuna reddy (2): > dt-bindings: dma: Add bindings for Intel LGM SoC > dmaengine: Add Intel LGM SoC DMA support. > > Arnd Bergmann (3): > dmaengine: remove sirfsoc driver > dmaengine: remove zte zx driver > dmaengine: remove coh901318 driver > > Bjorn Andersson (1): > dt-bindings: dma: intel-ldma: Fix $ref specifier > > Bjorn Helgaas (1): > dmaengine: stedma40: fix 'physical' typo > > Christophe JAILLET (3): > dmaengine: fsldma: Fix a resource leak in the remove function > dmaengine: fsldma: Fix a resource leak in an error handling path of the > probe function > dmaengine: owl-dma: Fix a resource leak in the remove function > > Colin Ian King (1): > dmaengine: dw-axi-dmac: remove redundant null check on desc > > Cristian Ciocaltea (2): > dt-bindings: dma: owl: Add compatible string for Actions Semi S500 SoC > dmaengine: owl: Add compatible for the Actions Semi S500 DMA controller > > Dave Jiang (2): > dmaengine: idxd: set DMA channel to be private > dmaengine: idxd: add module parameter to force disable of SVA > > Fabio Estevam (2): > dmaengine: imx-sdma: Remove platform data support > dmaengine: imx-sdma: Use of_device_get_match_data() > > Ferry Toth (1): > dmaengine: hsu: disable spurious interrupt > > Geert Uytterhoeven (5): > dt-bindings: renesas,rcar-dmac: Add r8a779a0 support > dmaengine: rcar-dmac: Add for_each_rcar_dmac_chan() helper > dmaengine: rcar-dmac: Add helpers for clearing DMA channel status > dmaengine: rcar-dmac: Add support for R-Car V3U > dmaengine: INTEL_LDMA should depend on X86 > > Grygorii Strashko (1): > dmaengine: ti: k3-psil: optimize struct psil_endpoint_config for size > > Lubomir Rintel (3): > dmaengine: mmp_pdma: Remove mmp_pdma_filter_fn() > dmaengine: mmp_pdma: Allow building as a module > dmaengine: mmp_tdma: Allow building as a module > > Nathan Chancellor (1): > dmaengine: qcom: Always inline gpi_update_reg > > Paul Cercueil (2): > dt-bindings: dma: ingenic: Add compatible strings for JZ4760(B) SoCs > dmaengine: jz4780: Add support for the JZ4760(B) > > Peter Ujfalusi (3): > dmaengine: Extend the dmaengine_alignment for 128 and 256 bytes > dmaengine: ti: k3-udma: Add support for burst_size configuration for > mem2mem > dmaengine: ti: k3-udma: Do not initialize ret in tisci channel config > functions > > Richard Fitzgerald (1): > dmaengine: xilinx_dma: Alloc tx descriptors GFP_NOWAIT > > Sia Jee Heng (17): > dt-bindings: dma: Add YAML schemas for dw-axi-dmac > dmaengine: dw-axi-dmac: simplify descriptor management > dmaengine: dw-axi-dmac: move dma_pool_create() to alloc_chan_resources() > dmaengine: dw-axi-dmac: Add device_synchronize() callback > dmaengine: dw-axi-dmac: Add device_config operation > dmaengine: dw-axi-dmac: Support device_prep_slave_sg > dmaegine: dw-axi-dmac: Support device_prep_dma_cyclic() > dmaengine: dw-axi-dmac: Support of_dma_controller_register() > dmaengine: dw-axi-dmac: Support burst residue granularity > dt-binding: dma: dw-axi-dmac: Add support for Intel KeemBay AxiDMA > dmaengine: dw-axi-dmac: Add Intel KeemBay DMA register fields > dmaengine: drivers: Kconfig: add HAS_IOMEM dependency to DW_AXI_DMAC > dmaengine: dw-axi-dmac: Add Intel KeemBay
Re: [PATCH 04/13] dt-bindings: qcom,pdc: Add compatible for sc7280
Quoting Rajendra Nayak (2021-02-11 23:28:41) > Add the compatible string for sc7180 SoC from Qualcomm > > Signed-off-by: Rajendra Nayak > --- > Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt | 1 + Is this being YAML-ified at some point?
Re: [PATCH 04/13] dt-bindings: qcom,pdc: Add compatible for sc7280
Quoting Rajendra Nayak (2021-02-11 23:28:41) > Add the compatible string for sc7180 SoC from Qualcomm > > Signed-off-by: Rajendra Nayak > --- Reviewed-by: Stephen Boyd
Re: [REGRESSION] "split bio_kmalloc from bio_alloc_bioset" causing crash shortly after bootup
On 2/22/21 23:10, Christoph Hellwig wrote: > On Tue, Feb 23, 2021 at 03:51:23AM +, Chaitanya Kulkarni wrote: >> Looking at the other call sites do we need something like following ? >> Since __blk_queue_bounce() passes the NULL for the passthru case as a >> bio_set value ? > Well, that is a somewhat odd calling convention. What about the patch below > instead? That being we really need to kill this bouncing code off.. I assume you are sending this patch, let me know otherwise. If you do please add, looks good. Reviewed-by: Chaitanya Kulkarni
[PATCH] perf-probe: dso: Add symbols in .text.* subsections to text symbol map in kenrel modules
The kernel modules have .text.* subsections such as .text.unlikely.
Since dso__process_kernel_symbol() only identify the symbols in the ".text"
section as the text symbols and inserts it in the default dso in the map,
the symbols in such subsections can not be found by map__find_symbol().
This adds the symbols in those subsections to the default dso in the map so
that map__find_symbol() can find them. This solves the perf-probe issue on
probing online module.
Without this fix, probing on a symbol in .text.unlikely fails.
# perf probe -m nf_conntrack nf_l4proto_log_invalid
Probe point 'nf_l4proto_log_invalid' not found.
Error: Failed to add events.
With this fix, it works because map__find_symbol() can find the symbol
correctly.
# perf probe -m nf_conntrack nf_l4proto_log_invalid
Added new event:
probe:nf_l4proto_log_invalid (on nf_l4proto_log_invalid in nf_conntrack)
You can now use it in all perf tools, such as:
perf record -e probe:nf_l4proto_log_invalid -aR sleep 1
Reported-by: Evgenii Shatokhin
Signed-off-by: Masami Hiramatsu
---
tools/perf/util/symbol-elf.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 6dff843fd883..0c1113236913 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -985,7 +985,9 @@ static int dso__process_kernel_symbol(struct dso *dso,
struct map *map,
if (strcmp(section_name, (curr_dso->short_name + dso->short_name_len))
== 0)
return 0;
- if (strcmp(section_name, ".text") == 0) {
+ /* .text and .text.* are included in the text dso */
+ if (strncmp(section_name, ".text", 5) == 0 &&
+ (section_name[5] == '\0' || section_name[5] == '.')) {
/*
* The initial kernel mapping is based on
* kallsyms and identity maps. Overwrite it to
Re: [PATCH 03/13] arm64: dts: sc7280: Add basic dts/dtsi files for SC7280 soc
Quoting Rajendra Nayak (2021-02-11 23:28:40)
> Add initial device tree support for the SC7280 SoC and the IDP
> boards based on this SoC
>
> Signed-off-by: Rajendra Nayak
> ---
Reviewed-by: Stephen Boyd
> diff --git a/arch/arm64/boot/dts/qcom/sc7280-idp.dts
> b/arch/arm64/boot/dts/qcom/sc7280-idp.dts
> new file mode 100644
> index 000..428f863
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sc7280-idp.dts
> @@ -0,0 +1,47 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * sc7280 IDP board device tree source
Is it capitalized or not capitalized for SC?
> + *
> + * Copyright (c) 2021, The Linux Foundation. All rights reserved.
> + */
> +
> +/dts-v1/;
> +
> +#include "sc7280.dtsi"
> +
> +/ {
> + model = "Qualcomm Technologies, Inc. SC7280 IDP platform";
Because it is capitalized here.
Re: 'perf probe' and symbols from .text.
On Tue, 23 Feb 2021 10:23:31 +0900 Masami Hiramatsu wrote: > On Mon, 22 Feb 2021 11:51:50 -0600 > Josh Poimboeuf wrote: > > > On Tue, Feb 23, 2021 at 12:05:08AM +0900, Masami Hiramatsu wrote: > > > > Of course, one could place probes using absolute addresses of the > > > > functions but that would be less convenient. > > > > > > > > This also affects many livepatch modules where the kernel code can be > > > > compiled with -ffunction-sections and each function may end up in a > > > > separate section .text.. 'perf probe' cannot be used > > > > there, except with the absolute addresses. > > > > > > > > Moreover, if FGKASLR patches are merged > > > > (https://lwn.net/Articles/832434/) and the kernel is built with FGKASLR > > > > enabled, -ffunction-sections will be used too. 'perf probe' will be > > > > unable to see the kernel functions then. > > > > > > Hmm, if the FGKASLAR really randomizes the symbol address, perf-probe > > > should give up "_text-relative" probe for that kernel, and must fallback > > > to the "symbol-based" probe. (Are there any way to check the FGKASLR is > > > on?) > > > The problem of "symbol-based" probe is that local (static) symbols > > > may share a same name sometimes. In that case, it can not find correct > > > symbol. (Maybe I can find a candidate from its size.) > > > Anyway, sometimes the security and usability are trade-off. > > > > We had a similar issue with FGKASLR and live patching. The proposed > > solution is a new linker flag which eliminates duplicates: -z > > unique-symbol. > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=26391 > > Interesting, but it might not be enough for perf-probe. > Since the perf-probe has to handle both dwarf and elf, both must be > changed. I think the problem is that the dwarf is generated while > compiling, but this -z seems converting elf symbols in linkage. > As far as I can see, this appends ".COUNT" suffix to the non-unique > symbols in the linkage phase. Is that also applied to dwarf too? Ah, OK. If there is an offline elf binary with symbol map, I can convert DWARF symbol -> address -> offline elf symbol (unique name)-> kallsyms. Currently, it directly converts address by kallsyms, so I will change it to find elf-symbol and solve address by kallsyms in post processing. Thank you, -- Masami Hiramatsu
Re: [PATCH] perf-probe: Failback to symbol-base probe for probes on module
Please ignore this. I will send a better fix.
Thanks,
On Tue, 23 Feb 2021 10:48:30 +0900
Masami Hiramatsu wrote:
> If an error occurs on post processing (this converts probe point to
> _text relative address for identifying non-unique symbols) for the
> probes on module, failback to symbol-base probe.
>
> There are many non-unique name symbols (local static functions can
> be in the different name spaces) in the kernel. If perf-probe uses
> a symbol-based probe definition, it can be put on an unintended
> symbol. To avoid such mistake, perf-probe tries to convert the
> address to the _text relative address expression.
>
> However, such symbol duplication is rare for only one module. Thus
> even if the conversion fails, perf probe can failback to the symbol
> based probe.
>
> Signed-off-by: Masami Hiramatsu
> ---
> tools/perf/util/probe-event.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
> index a9cff3a50ddf..af946f68e32e 100644
> --- a/tools/perf/util/probe-event.c
> +++ b/tools/perf/util/probe-event.c
> @@ -779,16 +779,16 @@ post_process_module_probe_trace_events(struct
> probe_trace_event *tevs,
>
> map = get_target_map(module, NULL, false);
> if (!map || debuginfo__get_text_offset(dinfo, _offs, true) < 0) {
> - pr_warning("Failed to get ELF symbols for %s\n", module);
> - return -EINVAL;
> + pr_info("NOTE: Failed to get ELF symbols for %s. Use symbol
> based probe.\n", module);
> + return 0;
> }
>
> mod_name = find_module_name(module);
> for (i = 0; i < ntevs; i++) {
> - ret = post_process_probe_trace_point([i].point,
> - map, (unsigned long)text_offs);
> - if (ret < 0)
> - break;
> + if (post_process_probe_trace_point([i].point,
> + map, (unsigned long)text_offs) < 0)
> + pr_info("NOTE: %s is not in the symbol map. Use symbol
> based probe.\n",
> +tevs[i].point.symbol);
> tevs[i].point.module =
> strdup(mod_name ? mod_name : module);
> if (!tevs[i].point.module) {
>
--
Masami Hiramatsu
[PATCH v3] erofs: support adjust lz4 history window size
lz4 uses LZ4_DISTANCE_MAX to record history preservation. When
using rolling decompression, a block with a higher compression
ratio will cause a larger memory allocation (up to 64k). It may
cause a large resource burden in extreme cases on devices with
small memory and a large number of concurrent IOs. So appropriately
reducing this value can improve performance.
Decreasing this value will reduce the compression ratio (except
when input_size
Signed-off-by: Guo Weichao
---
change since v2:
- use z_erofs_load_lz4_config to calculate lz4_distance_pages
- add description about the compatibility of the old kernel version
- drop useless comment
fs/erofs/decompressor.c | 22 ++
fs/erofs/erofs_fs.h | 3 ++-
fs/erofs/internal.h | 7 +++
fs/erofs/super.c| 2 ++
4 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/fs/erofs/decompressor.c b/fs/erofs/decompressor.c
index 1cb1ffd10569..0bb7903e3f9b 100644
--- a/fs/erofs/decompressor.c
+++ b/fs/erofs/decompressor.c
@@ -28,6 +28,18 @@ struct z_erofs_decompressor {
char *name;
};
+int z_erofs_load_lz4_config(struct erofs_sb_info *sbi,
+ struct erofs_super_block *dsb)
+{
+ u16 distance = le16_to_cpu(dsb->lz4_max_distance);
+
+ sbi->lz4_max_distance_pages = distance ?
+ (DIV_ROUND_UP(distance, PAGE_SIZE) + 1)
:
+ LZ4_MAX_DISTANCE_PAGES;
+
+ return 0;
+}
+
static int z_erofs_lz4_prepare_destpages(struct z_erofs_decompress_req *rq,
struct list_head *pagepool)
{
@@ -36,6 +48,8 @@ static int z_erofs_lz4_prepare_destpages(struct
z_erofs_decompress_req *rq,
struct page *availables[LZ4_MAX_DISTANCE_PAGES] = { NULL };
unsigned long bounced[DIV_ROUND_UP(LZ4_MAX_DISTANCE_PAGES,
BITS_PER_LONG)] = { 0 };
+ unsigned int lz4_max_distance_pages =
+ EROFS_SB(rq->sb)->lz4_max_distance_pages;
void *kaddr = NULL;
unsigned int i, j, top;
@@ -44,14 +58,14 @@ static int z_erofs_lz4_prepare_destpages(struct
z_erofs_decompress_req *rq,
struct page *const page = rq->out[i];
struct page *victim;
- if (j >= LZ4_MAX_DISTANCE_PAGES)
+ if (j >= lz4_max_distance_pages)
j = 0;
/* 'valid' bounced can only be tested after a complete round */
if (test_bit(j, bounced)) {
- DBG_BUGON(i < LZ4_MAX_DISTANCE_PAGES);
- DBG_BUGON(top >= LZ4_MAX_DISTANCE_PAGES);
- availables[top++] = rq->out[i - LZ4_MAX_DISTANCE_PAGES];
+ DBG_BUGON(i < lz4_max_distance_pages);
+ DBG_BUGON(top >= lz4_max_distance_pages);
+ availables[top++] = rq->out[i - lz4_max_distance_pages];
}
if (page) {
diff --git a/fs/erofs/erofs_fs.h b/fs/erofs/erofs_fs.h
index 9ad1615f4474..b27d0e4e4ab5 100644
--- a/fs/erofs/erofs_fs.h
+++ b/fs/erofs/erofs_fs.h
@@ -39,7 +39,8 @@ struct erofs_super_block {
__u8 uuid[16]; /* 128-bit uuid for volume */
__u8 volume_name[16]; /* volume name */
__le32 feature_incompat;
- __u8 reserved2[44];
+ __le16 lz4_max_distance;
+ __u8 reserved2[42];
};
/*
diff --git a/fs/erofs/internal.h b/fs/erofs/internal.h
index 67a7ec945686..4cb2395db45c 100644
--- a/fs/erofs/internal.h
+++ b/fs/erofs/internal.h
@@ -70,6 +70,9 @@ struct erofs_sb_info {
/* pseudo inode to manage cached pages */
struct inode *managed_cache;
+
+ /* # of pages needed for EROFS lz4 rolling decompression */
+ u16 lz4_max_distance_pages;
#endif /* CONFIG_EROFS_FS_ZIP */
u32 blocks;
u32 meta_blkaddr;
@@ -420,6 +423,8 @@ int erofs_try_to_free_all_cached_pages(struct erofs_sb_info
*sbi,
struct erofs_workgroup *egrp);
int erofs_try_to_free_cached_page(struct address_space *mapping,
struct page *page);
+int z_erofs_load_lz4_config(struct erofs_sb_info *sbi,
+ struct erofs_super_block *dsb);
#else
static inline void erofs_shrinker_register(struct super_block *sb) {}
static inline void erofs_shrinker_unregister(struct super_block *sb) {}
@@ -427,6 +432,8 @@ static inline int erofs_init_shrinker(void) { return 0; }
static inline void erofs_exit_shrinker(void) {}
static inline int z_erofs_init_zip_subsystem(void) { return 0; }
static inline void z_erofs_exit_zip_subsystem(void) {}
+static inline int z_erofs_load_lz4_config(struct erofs_sb_info *sbi,
+ struct erofs_super_block *dsb) {
return 0; }
#endif /* !CONFIG_EROFS_FS_ZIP */
#define EFSCORRUPTEDEUCLEAN /* Filesystem is corrupted
Re: [PATCH] scripts/gdb: document lx_current is only supported by x86
On 22.02.21 22:18, Song Bao Hua (Barry Song) wrote:
>
>
>> -Original Message-
>> From: Kieran Bingham [mailto:kieran.bing...@ideasonboard.com]
>> Sent: Tuesday, February 23, 2021 12:06 AM
>> To: Song Bao Hua (Barry Song) ; cor...@lwn.net;
>> linux-...@vger.kernel.org; jan.kis...@siemens.com
>> Cc: linux-kernel@vger.kernel.org; linux...@openeuler.org
>> Subject: Re: [PATCH] scripts/gdb: document lx_current is only supported by
>> x86
>>
>> Hi Barry
>>
>> On 21/02/2021 21:35, Barry Song wrote:
>>> lx_current depends on the per_cpu current_task which exists on x86 only:
>>>
>>> arch$ git grep current_task | grep -i per_cpu
>>> x86/include/asm/current.h:DECLARE_PER_CPU(struct task_struct *,
>> current_task);
>>> x86/kernel/cpu/common.c:DEFINE_PER_CPU(struct task_struct *, current_task)
>> cacheline_aligned =
>>> x86/kernel/cpu/common.c:EXPORT_PER_CPU_SYMBOL(current_task);
>>> x86/kernel/cpu/common.c:DEFINE_PER_CPU(struct task_struct *, current_task)
>> = _task;
>>> x86/kernel/cpu/common.c:EXPORT_PER_CPU_SYMBOL(current_task);
>>> x86/kernel/smpboot.c: per_cpu(current_task, cpu) = idle;
>>>
>>> On other architectures, lx_current() will lead to a python exception:
>>> (gdb) p $lx_current().pid
>>> Python Exception No symbol "current_task" in current
>> context.:
>>> Error occurred in Python: No symbol "current_task" in current context.
>>>
>>> To avoid more people struggling and wasting time in other architectures,
>>> document it.
>>>
>>> Cc: Jan Kiszka
>>> Signed-off-by: Barry Song
>>> ---
>>> Documentation/dev-tools/gdb-kernel-debugging.rst | 2 +-
>>> scripts/gdb/linux/cpus.py| 10 --
>>> 2 files changed, 9 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/Documentation/dev-tools/gdb-kernel-debugging.rst
>> b/Documentation/dev-tools/gdb-kernel-debugging.rst
>>> index 4756f6b3a04e..1586901b683c 100644
>>> --- a/Documentation/dev-tools/gdb-kernel-debugging.rst
>>> +++ b/Documentation/dev-tools/gdb-kernel-debugging.rst
>>> @@ -114,7 +114,7 @@ Examples of using the Linux-provided gdb helpers
>>> [ 0.00] BIOS-e820: [mem 0x0009fc00-0x0009]
>> reserved
>>>
>>>
>>> -- Examine fields of the current task struct::
>>> +- Examine fields of the current task struct(supported by x86 only)::
>>>
>>> (gdb) p $lx_current().pid
>>> $1 = 4998
>>> diff --git a/scripts/gdb/linux/cpus.py b/scripts/gdb/linux/cpus.py
>>> index 008e62f3190d..f382762509d3 100644
>>> --- a/scripts/gdb/linux/cpus.py
>>> +++ b/scripts/gdb/linux/cpus.py
>>> @@ -156,6 +156,13 @@ Note that VAR has to be quoted as string."""
>>>
>>> PerCpu()
>>>
>>> +def get_current_task(cpu):
>>> +if utils.is_target_arch("x86"):
>>> + var_ptr = gdb.parse_and_eval("_task")
>>> + return per_cpu(var_ptr, cpu).dereference()
>>> +else:
>>> +raise gdb.GdbError("Sorry, obtaining the current task is not yet "
>>> + "supported with this arch")
>>
>> I've wondered in the past how we should handle the architecture specific
>> layers.
>>
>> Perhaps we need to have an interface of functionality to implement on
>> each architecture so that we can create a per-arch set of helpers.
>>
>> or break it up into arch specific subdirs at least...
>>
>>
>>> class LxCurrentFunc(gdb.Function):
>>> """Return current task.
>>> @@ -167,8 +174,7 @@ number. If CPU is omitted, the CPU of the current
>>> context
>> is used."""
>>> super(LxCurrentFunc, self).__init__("lx_current")
>>>
>>> def invoke(self, cpu=-1):
>>> -var_ptr = gdb.parse_and_eval("_task")
>>> -return per_cpu(var_ptr, cpu).dereference()
>>> +return get_current_task(cpu)
>>>
>>
>> And then perhaps we simply shouldn't even expose commands which can not
>> be supported on those architectures?
>
> I feel it is better to tell users this function is not supported on its arch
> than simply hiding the function.
>
> If we hide it, users still have many chances to try it as they have got
> information of lx_current from google or somewhere.
> They will try, if it turns out the lx_current is not in the list and an
> error like "invalid data type for function to be called", they will
> probably suspect their gdb/python environment is not set up correctly,
> and continue to waste time in checking their environment.
> Finally they figure out this function is not supported by its arch so it is
> not exposed. But they have wasted a couple of hours before knowing that.
>
> It seems it is more friendly to directly tell users this is not supported
> on its arch explicitly and clearly than reporting a "invalid data type
> for function to be called.
>
>>
>> Is it easy to disable this command if it's not supportable on the
>> architecture?
>>
>
> TBH, I'm not a python expert. I don't know how to do that in an elegant
> way :-) on the other hand, it seems lx_current isn’t a command like
> lx-dmesg. Lx_current is actually similar with
[PATCH v2] iio: core: use kstrdup_const/kfree_const for buffer attributes
When the buffer attributes were wrapped in iio_dev_attr types, I forgot to
duplicate the names, so that when iio_free_chan_devattr_list() gets called
on cleanup, these get free'd.
I stumbled over this while accidentally breaking a driver doing
iio_device_register(), and then the issue appeared.
Some ways to fix this are:
1. Just use kstrdup() during iio_buffer_wrap_attr()
2. Just use kfree_const() during iio_free_chan_devattr_list
3. Use both kstrdup_const() & kfree_const() (in the places mentioned above)
This implements the third option, as it allows some users/drivers to
specify some attributes allocated on the heap.
Fixes: a1a11142f66c ("iio: buffer: wrap all buffer attributes into
iio_dev_attr")
Signed-off-by: Alexandru Ardelean
---
drivers/iio/industrialio-buffer.c | 1 +
drivers/iio/industrialio-core.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/industrialio-buffer.c
b/drivers/iio/industrialio-buffer.c
index 5d641f8adfbd..ac882e60c419 100644
--- a/drivers/iio/industrialio-buffer.c
+++ b/drivers/iio/industrialio-buffer.c
@@ -1306,6 +1306,7 @@ static struct attribute *iio_buffer_wrap_attr(struct
iio_buffer *buffer,
return NULL;
iio_attr->buffer = buffer;
+ iio_attr->dev_attr.attr.name = kstrdup_const(attr->name, GFP_KERNEL);
memcpy(_attr->dev_attr, dattr, sizeof(iio_attr->dev_attr));
list_add(_attr->l, >buffer_attr_list);
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 0d8c6e88d993..cb2735d2ae4b 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -1358,7 +1358,7 @@ void iio_free_chan_devattr_list(struct list_head
*attr_list)
struct iio_dev_attr *p, *n;
list_for_each_entry_safe(p, n, attr_list, l) {
- kfree(p->dev_attr.attr.name);
+ kfree_const(p->dev_attr.attr.name);
list_del(>l);
kfree(p);
}
--
2.25.1
Re: [PULL] fixes around VM_PFNMAP and follow_pfn for 5.12 merge window
On Tue, Feb 23, 2021 at 2:42 AM Linus Torvalds
wrote:
>
> On Mon, Feb 22, 2021 at 2:25 AM Daniel Vetter wrote:
> >
> > Cc all the mailing lists ... my usual script crashed and I had to
> > hand-roll the email and screwed it up ofc :-/
>
> Oh, and my reply thus also became just a reply to you personally.
>
> So repeating it here, in case somebody has comments about that
> access_process_vm() issue.
>
> On Mon, Feb 22, 2021 at 2:23 AM Daniel Vetter wrote:
> >
> > I've stumbled over this for my own learning and then realized there's a
> > bunch of races around VM_PFNMAP mappings vs follow pfn.
> >
> > If you're happy with this [..]
>
> Happy? No. But it seems an improvement.
>
> I did react to some of this: commit 0fb1b1ed7dd9 ("/dev/mem: Only set
> filp->f_mapping") talks about _what_ it does, but not so much _why_ it
> does it. It doesn't seem to actually matter, and seems almost
> incidental (because you've looked at f_mapping and i_mapping just
> didn't matter but was adjacent.
Yeah it doesn't matter, it just confused me, so I wrote a patch to
remove it and get experts to tell me it actually really doesn't
matter. So that's really the entirety of that one. Like I said, I
mostly stumbled into this rat hole because I had some questions,
wanted to understand stuff better, and the code did not provide
consistent answers :-)
> And generic_access_phys() remains horrific. Does anything actually use
> this outside of the odd magical access_remote_vm() code?
>
> I'm wondering if that code shouldn't just be removed entirely. It's
> quite old, I'm not sure it's really relevant. See commit 28b2ee20c7cb
> ("access_process_vm device memory infrastructure").
>
> I guess you do debug the X server, but still.. Do you actually ever
> look at device memory through the debugger? I'd hope that you'd use an
> access function and make gdb call it in the context of the debuggee?
tbh I had no idea this exists, but yeah I've fired up gdb on some of
the register dumper tools we have that use the pci mmap files, and
after fixing some thinko in the first version it was still working
after the conversion.
>From a quick git grep almost nothing wires this up, so yeah no idea
whether it's still used. Definitely not useful for X hackery anymore.
It is wired up for uio framework, and I guess for debugging userspace
drivers this comes handy. Although letting your debugger do
reads/writes to device registers sounds scary.
-Daniel
> Whatever. I've pulled it, and I'm not _unhappy_ with it, but I'd also
> not call myself overly giddy and over the moon happy about this code.
>
> Linus
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [REGRESSION] "split bio_kmalloc from bio_alloc_bioset" causing crash shortly after bootup
On Tue, Feb 23, 2021 at 08:04:08AM +0100, Christoph Hellwig wrote:
> The problem is that the blk-crypto fallback code calls bio_split
> with a NULL bioset. That was aready broken before, as the mempool
> needed to guarantee forward progress was missing, but is not fatal.
>
> Satya, can you look into adding a mempool that can guarantees forward
> progress here?
Something like this would be the minimum viable fix:
diff --git a/block/blk-crypto-fallback.c b/block/blk-crypto-fallback.c
index e8327c50d7c9f4..c176b7af56a7a5 100644
--- a/block/blk-crypto-fallback.c
+++ b/block/blk-crypto-fallback.c
@@ -80,6 +80,7 @@ static struct blk_crypto_keyslot {
static struct blk_keyslot_manager blk_crypto_ksm;
static struct workqueue_struct *blk_crypto_wq;
static mempool_t *blk_crypto_bounce_page_pool;
+static struct bio_set crypto_bio_split;
/*
* This is the key we set when evicting a keyslot. This *should* be the all 0's
@@ -224,7 +225,8 @@ static bool blk_crypto_split_bio_if_needed(struct bio
**bio_ptr)
if (num_sectors < bio_sectors(bio)) {
struct bio *split_bio;
- split_bio = bio_split(bio, num_sectors, GFP_NOIO, NULL);
+ split_bio = bio_split(bio, num_sectors, GFP_NOIO,
+ _bio_split);
if (!split_bio) {
bio->bi_status = BLK_STS_RESOURCE;
return false;
@@ -538,9 +540,13 @@ static int blk_crypto_fallback_init(void)
prandom_bytes(blank_key, BLK_CRYPTO_MAX_KEY_SIZE);
- err = blk_ksm_init(_crypto_ksm, blk_crypto_num_keyslots);
+ err = bioset_init(_bio_split, 64, 0, 0);
if (err)
goto out;
+
+ err = blk_ksm_init(_crypto_ksm, blk_crypto_num_keyslots);
+ if (err)
+ goto fail_free_bioset;
err = -ENOMEM;
blk_crypto_ksm.ksm_ll_ops = blk_crypto_ksm_ll_ops;
@@ -591,6 +597,8 @@ static int blk_crypto_fallback_init(void)
destroy_workqueue(blk_crypto_wq);
fail_free_ksm:
blk_ksm_destroy(_crypto_ksm);
+fail_free_bioset:
+ bioset_exit(_bio_split);
out:
return err;
}
Re: [REGRESSION] "split bio_kmalloc from bio_alloc_bioset" causing crash shortly after bootup
On 2/22/21 23:10, Christoph Hellwig wrote:
> Well, that is a somewhat odd calling convention. What about the patch below
> instead? That being we really need to kill this bouncing code off..
If we can kill it off soon it will be great.
>
> diff --git a/block/bounce.c b/block/bounce.c
> index fc55314aa4269a..789fbcacb1e92a 100644
> --- a/block/bounce.c
> +++ b/block/bounce.c
> @@ -214,9 +214,9 @@ static void bounce_end_io_read_isa(struct bio *bio)
> __bounce_end_io_read(bio, _page_pool);
> }
>
> -static struct bio *bounce_clone_bio(struct bio *bio_src, gfp_t gfp_mask,
> - struct bio_set *bs)
> +static struct bio *bounce_clone_bio(struct bio *bio_src, bool passthrough)
> {
> + unsigned int nr_vecs = bio_segments(bio_src);
> struct bvec_iter iter;
> struct bio_vec bv;
> struct bio *bio;
> @@ -242,8 +242,10 @@ static struct bio *bounce_clone_bio(struct bio *bio_src,
> gfp_t gfp_mask,
>*asking for trouble and would force extra work on
>*__bio_clone_fast() anyways.
>*/
> -
> - bio = bio_alloc_bioset(gfp_mask, bio_segments(bio_src), bs);
> + if (passthrough)
> + bio = bio_kmalloc(GFP_NOIO, nr_vecs);
> + else
> + bio = bio_alloc_bioset(GFP_NOIO, nr_vecs, _bio_set);
> if (!bio)
> return NULL;
> bio->bi_bdev= bio_src->bi_bdev;
> @@ -269,11 +271,11 @@ static struct bio *bounce_clone_bio(struct bio
> *bio_src, gfp_t gfp_mask,
> break;
> }
>
> - if (bio_crypt_clone(bio, bio_src, gfp_mask) < 0)
> + if (bio_crypt_clone(bio, bio_src, GFP_NOIO) < 0)
> goto err_put;
>
> if (bio_integrity(bio_src) &&
> - bio_integrity_clone(bio, bio_src, gfp_mask) < 0)
> + bio_integrity_clone(bio, bio_src, GFP_NOIO) < 0)
> goto err_put;
>
> bio_clone_blkg_association(bio, bio_src);
> @@ -313,8 +315,7 @@ static void __blk_queue_bounce(struct request_queue *q,
> struct bio **bio_orig,
> submit_bio_noacct(*bio_orig);
> *bio_orig = bio;
> }
> - bio = bounce_clone_bio(*bio_orig, GFP_NOIO, passthrough ? NULL :
> - _bio_set);
> + bio = bounce_clone_bio(*bio_orig, passthrough);
>
> /*
>* Bvec table can't be updated by bio_for_each_segment_all(),
>
Seems like this fixes the issue and does the cleanup in one patch, looks
good.
Re: [PATCH v4 bpf-next 2/6] bpf: prevent deadlock from recursive bpf_task_storage_[get|delete]
On Mon, Feb 22, 2021 at 11:16 PM Song Liu wrote: > > > > > On Feb 22, 2021, at 10:21 PM, Andrii Nakryiko > > wrote: > > > > On Mon, Feb 22, 2021 at 5:23 PM Song Liu wrote: > >> > >> BPF helpers bpf_task_storage_[get|delete] could hold two locks: > >> bpf_local_storage_map_bucket->lock and bpf_local_storage->lock. Calling > >> these helpers from fentry/fexit programs on functions in bpf_*_storage.c > >> may cause deadlock on either locks. > >> > >> Prevent such deadlock with a per cpu counter, bpf_task_storage_busy, which > >> is similar to bpf_prog_active. We need this counter to be global, because > >> the two locks here belong to two different objects: bpf_local_storage_map > >> and bpf_local_storage. If we pick one of them as the owner of the counter, > >> it is still possible to trigger deadlock on the other lock. For example, > >> if bpf_local_storage_map owns the counters, it cannot prevent deadlock > >> on bpf_local_storage->lock when two maps are used. > >> > >> Signed-off-by: Song Liu > >> --- > >> kernel/bpf/bpf_task_storage.c | 57 ++- > >> 1 file changed, 50 insertions(+), 7 deletions(-) > >> > > > > [...] > > > >> @@ -109,7 +136,9 @@ static void *bpf_pid_task_storage_lookup_elem(struct > >> bpf_map *map, void *key) > >>goto out; > >>} > >> > >> + bpf_task_storage_lock(); > >>sdata = task_storage_lookup(task, map, true); > >> + bpf_task_storage_unlock(); > >>put_pid(pid); > >>return sdata ? sdata->data : NULL; > >> out: > >> @@ -141,8 +170,10 @@ static int bpf_pid_task_storage_update_elem(struct > >> bpf_map *map, void *key, > >>goto out; > >>} > >> > >> + bpf_task_storage_lock(); > >>sdata = bpf_local_storage_update( > >>task, (struct bpf_local_storage_map *)map, value, > >> map_flags); > > > > this should probably be container_of() instead of casting > > bpf_task_storage.c uses casting in multiple places. How about we fix it in a > separate patch? > Sure, let's fix all uses in a separate patch. My point is that this makes an assumption (that struct bpf_map map field is always the very first one) which is not enforced and not documented in struct bpf_local_storage_map. > Thanks, > Song > > > > >> + bpf_task_storage_unlock(); > >> > >>err = PTR_ERR_OR_ZERO(sdata); > >> out: > >> @@ -185,7 +216,9 @@ static int bpf_pid_task_storage_delete_elem(struct > >> bpf_map *map, void *key) > >>goto out; > >>} > >> > >> + bpf_task_storage_lock(); > >>err = task_storage_delete(task, map); > >> + bpf_task_storage_unlock(); > >> out: > >>put_pid(pid); > >>return err; > > > > [...] >
Re: [PATCH v6 0/2] add support for GPIO or IRQ based evemt counter
Hi William, On Mon, Feb 22, 2021 at 10:48:56AM +0900, William Breathitt Gray wrote: > On Tue, Feb 16, 2021 at 09:13:54AM +0100, Oleksij Rempel wrote: > > changes v6: > > - rename it to interrupt-counter > > Hi Oleksij, > > Sorry to nitpick again, I think "irq-counter" as Jonathan suggested in > an earlier review would be a better name afterall. Would you be able to > rename this driver to use that name instead? I would prefer not to rename it. IRQ (Interrupt Request) is a signal outside of the system. Below some frequency rate, amount of counted ISR (interrupt service routine) calls or events would be equal to the actual IRQs. If frequency is too high, we will count ISR, but not IRQs. In any case, interrupt-counter is more or leas neutral, without triggering too many wrong assumptions. Regards, Oleksij -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH 5.4 00/13] 5.4.100-rc1 review
On Mon, 22 Feb 2021 at 17:46, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.4.100 release. > There are 13 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 Wed, 24 Feb 2021 12:07:46 +. > 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.4.100-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.4.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing Summary kernel: 5.4.100-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.4.y git commit: b467dd44a81c97f9d99fbab61ef081f35e824773 git describe: v5.4.99-15-gb467dd44a81c Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.99-15-gb467dd44a81c No regressions (compared to build v5.4.99) No fixes (compared to build v5.4.99) Ran 50146 total tests in the following environments and test suites. Environments -- - arc - arm - arm64 - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - juno-r2-compat - juno-r2-kasan - mips - nxp-ls2088 - nxp-ls2088-64k_page_size - parisc - powerpc - qemu-arm-clang - qemu-arm64-clang - qemu-arm64-kasan - qemu-x86_64-clang - qemu-x86_64-kasan - qemu-x86_64-kcsan - qemu_arm - qemu_arm64 - qemu_arm64-compat - qemu_i386 - qemu_x86_64 - qemu_x86_64-compat - riscv - s390 - sh - sparc - x15 - x86 - x86-kasan - x86_64 Test Suites --- * build * linux-log-parser * igt-gpu-tools * install-android-platform-tools-r2600 * kselftest-android * kselftest-bpf * kselftest-capabilities * kselftest-cgroup * kselftest-clone3 * kselftest-core * kselftest-cpu-hotplug * kselftest-cpufreq * kselftest-efivarfs * kselftest-filesystems * kselftest-firmware * kselftest-fpu * kselftest-futex * kselftest-gpio * kselftest-intel_pstate * kselftest-ipc * kselftest-ir * kselftest-kcmp * kselftest-kvm * kselftest-lib * kselftest-livepatch * kselftest-lkdtm * kselftest-membarrier * kselftest-memfd * kselftest-memory-hotplug * kselftest-mincore * kselftest-mount * kselftest-mqueue * kselftest-net * kselftest-netfilter * kselftest-nsfs * kselftest-openat2 * kselftest-pid_namespace * kselftest-pidfd * kselftest-proc * kselftest-pstore * kselftest-ptrace * kselftest-rseq * kselftest-rtc * kselftest-seccomp * kselftest-sigaltstack * kselftest-size * kselftest-splice * kselftest-static_keys * kselftest-sync * kselftest-sysctl * kselftest-tc-testing * kselftest-timens * kselftest-timers * kselftest-tmpfs * kselftest-tpm2 * kselftest-user * kselftest-zram * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-securebits-tests * perf * v4l2-compliance * fwts * ltp-commands-tests * ltp-controllers-tests * ltp-math-tests * ltp-sched-tests * ltp-syscalls-tests * ltp-tracing-tests * network-basic-tests * kselftest-kexec * kselftest-vm * kselftest-x86 * ltp-open-posix-tests * kvm-unit-tests * rcutorture * ssuite * timesync-off -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH v4 bpf-next 2/6] bpf: prevent deadlock from recursive bpf_task_storage_[get|delete]
> On Feb 22, 2021, at 10:21 PM, Andrii Nakryiko > wrote: > > On Mon, Feb 22, 2021 at 5:23 PM Song Liu wrote: >> >> BPF helpers bpf_task_storage_[get|delete] could hold two locks: >> bpf_local_storage_map_bucket->lock and bpf_local_storage->lock. Calling >> these helpers from fentry/fexit programs on functions in bpf_*_storage.c >> may cause deadlock on either locks. >> >> Prevent such deadlock with a per cpu counter, bpf_task_storage_busy, which >> is similar to bpf_prog_active. We need this counter to be global, because >> the two locks here belong to two different objects: bpf_local_storage_map >> and bpf_local_storage. If we pick one of them as the owner of the counter, >> it is still possible to trigger deadlock on the other lock. For example, >> if bpf_local_storage_map owns the counters, it cannot prevent deadlock >> on bpf_local_storage->lock when two maps are used. >> >> Signed-off-by: Song Liu >> --- >> kernel/bpf/bpf_task_storage.c | 57 ++- >> 1 file changed, 50 insertions(+), 7 deletions(-) >> > > [...] > >> @@ -109,7 +136,9 @@ static void *bpf_pid_task_storage_lookup_elem(struct >> bpf_map *map, void *key) >>goto out; >>} >> >> + bpf_task_storage_lock(); >>sdata = task_storage_lookup(task, map, true); >> + bpf_task_storage_unlock(); >>put_pid(pid); >>return sdata ? sdata->data : NULL; >> out: >> @@ -141,8 +170,10 @@ static int bpf_pid_task_storage_update_elem(struct >> bpf_map *map, void *key, >>goto out; >>} >> >> + bpf_task_storage_lock(); >>sdata = bpf_local_storage_update( >>task, (struct bpf_local_storage_map *)map, value, map_flags); > > this should probably be container_of() instead of casting bpf_task_storage.c uses casting in multiple places. How about we fix it in a separate patch? Thanks, Song > >> + bpf_task_storage_unlock(); >> >>err = PTR_ERR_OR_ZERO(sdata); >> out: >> @@ -185,7 +216,9 @@ static int bpf_pid_task_storage_delete_elem(struct >> bpf_map *map, void *key) >>goto out; >>} >> >> + bpf_task_storage_lock(); >>err = task_storage_delete(task, map); >> + bpf_task_storage_unlock(); >> out: >>put_pid(pid); >>return err; > > [...]
Re: [PATCH v2] memcg: charge before adding to swapcache on swapin
Hi Shakeel,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on next-20210222]
[cannot apply to linus/master hnaz-linux-mm/master v5.11 v5.11-rc7 v5.11-rc6
v5.11]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Shakeel-Butt/memcg-charge-before-adding-to-swapcache-on-swapin/20210223-135711
base:37dfbfbdca66834bc0f64ec9b35e09ac6c8898da
config: arm-colibri_pxa300_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/7ad6fb47580886394809b563b7476954a35f3054
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Shakeel-Butt/memcg-charge-before-adding-to-swapcache-on-swapin/20210223-135711
git checkout 7ad6fb47580886394809b563b7476954a35f3054
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
In file included from include/linux/swap.h:9,
from mm/swap_state.c:13:
include/linux/memcontrol.h:1149:1: error: expected identifier or '(' before
'{' token
1149 | {
| ^
>> include/linux/memcontrol.h:1147:19: warning: 'mem_cgroup_charge_swapin_page'
>> used but never defined
1147 | static inline int mem_cgroup_charge_swapin_page(struct page *page,
| ^
vim +/mem_cgroup_charge_swapin_page +1147 include/linux/memcontrol.h
1146
> 1147 static inline int mem_cgroup_charge_swapin_page(struct page *page,
1148 struct mm_struct *mm, gfp_t gfp, swp_entry_t
entry);
> 1149 {
1150 return 0;
1151 }
1152
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
mipsel-linux-ld: warning: orphan section `.data.$LPBX1' from `arch/mips/kernel/perf_regs.o' being placed in section `.data.$LPBX1'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 3b9cdafb5358eb9f3790de2f728f765fef100731 commit: 1ddc96bd42daeeb58f66c9515e506f245ccb00c6 MIPS: kernel: Support extracting off-line stack traces from user-space with perf date: 3 weeks ago config: mips-randconfig-r014-20210222 (attached as .config) compiler: mipsel-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1ddc96bd42daeeb58f66c9515e506f245ccb00c6 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 1ddc96bd42daeeb58f66c9515e506f245ccb00c6 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=mips If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): mipsel-linux-ld: warning: orphan section `.data.$LPBX1' from `init/main.o' being placed in section `.data.$LPBX1' mipsel-linux-ld: warning: orphan section `.data.$LPBX0' from `init/main.o' being placed in section `.data.$LPBX0' mipsel-linux-ld: warning: orphan section `.data.$LPBX1' from `init/do_mounts.o' being placed in section `.data.$LPBX1' mipsel-linux-ld: warning: orphan section `.data.$LPBX0' from `init/do_mounts.o' being placed in section `.data.$LPBX0' mipsel-linux-ld: warning: orphan section `.data.$LPBX1' from `init/do_mounts_initrd.o' being placed in section `.data.$LPBX1' mipsel-linux-ld: warning: orphan section `.data.$LPBX0' from `init/do_mounts_initrd.o' being placed in section `.data.$LPBX0' mipsel-linux-ld: warning: orphan section `.data.$LPBX1' from `init/initramfs.o' being placed in section `.data.$LPBX1' mipsel-linux-ld: warning: orphan section `.data.$LPBX0' from `init/initramfs.o' being placed in section `.data.$LPBX0' mipsel-linux-ld: warning: orphan section `.data.$LPBX1' from `init/calibrate.o' being placed in section `.data.$LPBX1' mipsel-linux-ld: warning: orphan section `.data.$LPBX0' from `init/calibrate.o' being placed in section `.data.$LPBX0' mipsel-linux-ld: warning: orphan section `.data.$LPBX1' from `arch/mips/loongson32/common/time.o' being placed in section `.data.$LPBX1' mipsel-linux-ld: warning: orphan section `.data.$LPBX0' from `arch/mips/loongson32/common/time.o' being placed in section `.data.$LPBX0' mipsel-linux-ld: warning: orphan section `.data.$LPBX1' from `arch/mips/loongson32/common/irq.o' being placed in section `.data.$LPBX1' mipsel-linux-ld: warning: orphan section `.data.$LPBX0' from `arch/mips/loongson32/common/irq.o' being placed in section `.data.$LPBX0' mipsel-linux-ld: warning: orphan section `.data.$LPBX1' from `arch/mips/loongson32/common/platform.o' being placed in section `.data.$LPBX1' mipsel-linux-ld: warning: orphan section `.data.$LPBX0' from `arch/mips/loongson32/common/platform.o' being placed in section `.data.$LPBX0' mipsel-linux-ld: warning: orphan section `.data.$LPBX1' from `arch/mips/loongson32/common/prom.o' being placed in section `.data.$LPBX1' mipsel-linux-ld: warning: orphan section `.data.$LPBX0' from `arch/mips/loongson32/common/prom.o' being placed in section `.data.$LPBX0' mipsel-linux-ld: warning: orphan section `.data.$LPBX1' from `arch/mips/loongson32/common/reset.o' being placed in section `.data.$LPBX1' mipsel-linux-ld: warning: orphan section `.data.$LPBX0' from `arch/mips/loongson32/common/reset.o' being placed in section `.data.$LPBX0' mipsel-linux-ld: warning: orphan section `.data.$LPBX1' from `arch/mips/loongson32/common/setup.o' being placed in section `.data.$LPBX1' mipsel-linux-ld: warning: orphan section `.data.$LPBX0' from `arch/mips/loongson32/common/setup.o' being placed in section `.data.$LPBX0' mipsel-linux-ld: warning: orphan section `.data.$LPBX1' from `arch/mips/loongson32/ls1b/board.o' being placed in section `.data.$LPBX1' mipsel-linux-ld: warning: orphan section `.data.$LPBX0' from `arch/mips/loongson32/ls1b/board.o' being placed in section `.data.$LPBX0' mipsel-linux-ld: warning: orphan section `.data.$LPBX1' from `arch/mips/kernel/branch.o' being placed in section `.data.$LPBX1' mipsel-linux-ld: warning: orphan section `.data.$LPBX0' from `arch/mips/kernel/branch.o' being placed in section `.data.$LPBX0' mipsel-linux-ld: warning: orphan section `.data.$LPBX1' from `arch/mips/kernel/cmpxchg.o' being placed in section `.data.$LPBX1' mipsel-linux-ld: warning: orphan section `.data.$LPBX0' from `arch/mips/kernel/cmpxchg.o' being placed in section `.data.$LPBX0' mipsel-linux-ld: warning: orphan section `.data.$LPBX1' from `arch/mips/kernel
[PATCH v9 4/7] crypto: and expose ecc curves
Move 'ecc_get_curve' to 'include/crypto/ecc_curve.h', so everyone
in kernel tree can easily get ecc curve params;
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
---
crypto/ecc.c | 5 -
crypto/ecc.h | 37 ++--
include/crypto/ecc_curve.h | 53 ++
3 files changed, 59 insertions(+), 36 deletions(-)
create mode 100644 include/crypto/ecc_curve.h
diff --git a/crypto/ecc.c b/crypto/ecc.c
index c80aa25..4b55ad0 100644
--- a/crypto/ecc.c
+++ b/crypto/ecc.c
@@ -24,6 +24,7 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
+#include
#include
#include
#include
@@ -42,7 +43,8 @@ typedef struct {
u64 m_high;
} uint128_t;
-static inline const struct ecc_curve *ecc_get_curve(unsigned int curve_id)
+
+const struct ecc_curve *ecc_get_curve(unsigned int curve_id)
{
switch (curve_id) {
/* In FIPS mode only allow P256 and higher */
@@ -54,6 +56,7 @@ static inline const struct ecc_curve *ecc_get_curve(unsigned
int curve_id)
return NULL;
}
}
+EXPORT_SYMBOL(ecc_get_curve);
static u64 *ecc_alloc_digits_space(unsigned int ndigits)
{
diff --git a/crypto/ecc.h b/crypto/ecc.h
index d4e546b..38a81d4 100644
--- a/crypto/ecc.h
+++ b/crypto/ecc.h
@@ -26,6 +26,8 @@
#ifndef _CRYPTO_ECC_H
#define _CRYPTO_ECC_H
+#include
+
/* One digit is u64 qword. */
#define ECC_CURVE_NIST_P192_DIGITS 3
#define ECC_CURVE_NIST_P256_DIGITS 4
@@ -33,44 +35,9 @@
#define ECC_DIGITS_TO_BYTES_SHIFT 3
-/**
- * struct ecc_point - elliptic curve point in affine coordinates
- *
- * @x: X coordinate in vli form.
- * @y: Y coordinate in vli form.
- * @ndigits: Length of vlis in u64 qwords.
- */
-struct ecc_point {
- u64 *x;
- u64 *y;
- u8 ndigits;
-};
-
#define ECC_POINT_INIT(x, y, ndigits) (struct ecc_point) { x, y, ndigits }
/**
- * struct ecc_curve - definition of elliptic curve
- *
- * @name: Short name of the curve.
- * @g: Generator point of the curve.
- * @p: Prime number, if Barrett's reduction is used for this curve
- * pre-calculated value 'mu' is appended to the @p after ndigits.
- * Use of Barrett's reduction is heuristically determined in
- * vli_mmod_fast().
- * @n: Order of the curve group.
- * @a: Curve parameter a.
- * @b: Curve parameter b.
- */
-struct ecc_curve {
- char *name;
- struct ecc_point g;
- u64 *p;
- u64 *n;
- u64 *a;
- u64 *b;
-};
-
-/**
* ecc_is_key_valid() - Validate a given ECDH private key
*
* @curve_id: id representing the curve to use
diff --git a/include/crypto/ecc_curve.h b/include/crypto/ecc_curve.h
new file mode 100644
index 000..19a35da
--- /dev/null
+++ b/include/crypto/ecc_curve.h
@@ -0,0 +1,53 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (c) 2021 HiSilicon */
+
+#ifndef _CRYTO_ECC_CURVE_H
+#define _CRYTO_ECC_CURVE_H
+
+#include
+
+/**
+ * struct ecc_point - elliptic curve point in affine coordinates
+ *
+ * @x: X coordinate in vli form.
+ * @y: Y coordinate in vli form.
+ * @ndigits: Length of vlis in u64 qwords.
+ */
+struct ecc_point {
+ u64 *x;
+ u64 *y;
+ u8 ndigits;
+};
+
+/**
+ * struct ecc_curve - definition of elliptic curve
+ *
+ * @name: Short name of the curve.
+ * @g: Generator point of the curve.
+ * @p: Prime number, if Barrett's reduction is used for this curve
+ * pre-calculated value 'mu' is appended to the @p after ndigits.
+ * Use of Barrett's reduction is heuristically determined in
+ * vli_mmod_fast().
+ * @n: Order of the curve group.
+ * @a: Curve parameter a.
+ * @b: Curve parameter b.
+ */
+struct ecc_curve {
+ char *name;
+ struct ecc_point g;
+ u64 *p;
+ u64 *n;
+ u64 *a;
+ u64 *b;
+};
+
+/**
+ * ecc_get_curve() - get elliptic curve;
+ * @curve_id: Curves IDs:
+ * defined in 'include/crypto/ecdh.h';
+ *
+ * Returns curve if get curve succssful, NULL otherwise
+ */
+const struct ecc_curve *ecc_get_curve(unsigned int curve_id);
+
+#endif
--
2.8.1
[PATCH v9 0/7] add ECDH and CURVE25519 algorithms support for Kunpeng 930
1. Move curve ID from the key into the algorithm name (like 'ecdh-nist-pxxx'
so we get its tfm like 'crypto_alloc_kpp("ecdh-nist-p256", 0, 0)'),
in 'crypto/ecc.c' (has been verified by testmgr) and 'crypto/atmel-ecc.c'
(only compiled, not do test), and modify 'testmgr.c' and
'net/bluetooth/smp.c'
(only compiled, not do test) to adapt the modification;
2. Add new file 'include/crypto/ecc_curve.h', and move 'struct ecc_point' and
'struct ecc_curve' definitions to it, also add new APIs 'ecc_get_curveXXX'
into it, with these APIs, users in kernel tree can get ECDH and
curve25519 parameters;
3. Add ECDH and CURVE25519 algorithms support for Kunpeng 930.
v8->v9:
- patch #3: squash patches 3-5 in v8 into one in v9
- patch #4: delete ECDH curve parameters: P224, P384 and P521
- patch #5: delete ecdh-nist-p224, ecdh-nist-p384 and ecdh-nist-p521 support in
HPRE
v7->v8:
- patch #3 and #5: move the curve ID from the key into the algorithm name
instead
v6->v7:
- patch #4: add function interface to expose elliptic curve parameters
- patch #4: eliminate warning by 'kernel test robot'
- patch #5: add function interface to expose curve25519 parameters
v5->v6:
- patch #1: add a new patch (the first patch), which is the "depend on" patch
before
v4->v5:
- patch #4: delete P-128 and P-320 curve, as the few using case in the kernel
v3 -> v4:
- patch #3: add new, and move ecc_curve params to "include/crypto"
v2 -> v3:
- patch #5: fix sparse warnings
- patch #5: add 'CRYPTO_LIB_CURVE25519_GENERIC' in 'Kconfig'
v1 -> v2:
- patch #5: delete `curve25519_null_point'
Meng Yu (7):
crypto: hisilicon/hpre - add version adapt to new algorithms
crypto: hisilicon/hpre - add algorithm type
crypto: move curve_id of ECDH from the key to algorithm name
crypto: and expose ecc curves
crypto: hisilicon/hpre - add 'ECDH' algorithm
crypto: add curve25519 params and expose them
crypto: hisilicon/hpre - add 'CURVE25519' algorithm
crypto/ecc.c| 11 +-
crypto/ecc.h| 37 +-
crypto/ecc_curve_defs.h | 17 +
crypto/ecdh.c | 72 ++-
crypto/ecdh_helper.c| 4 +-
crypto/testmgr.c| 13 +-
crypto/testmgr.h| 34 +-
drivers/crypto/atmel-ecc.c | 14 +-
drivers/crypto/hisilicon/Kconfig| 1 +
drivers/crypto/hisilicon/hpre/hpre.h| 17 +-
drivers/crypto/hisilicon/hpre/hpre_crypto.c | 881 +++-
drivers/crypto/hisilicon/hpre/hpre_main.c | 12 +-
drivers/crypto/hisilicon/qm.c | 4 +-
drivers/crypto/hisilicon/qm.h | 4 +-
drivers/crypto/hisilicon/sec2/sec.h | 4 +-
drivers/crypto/hisilicon/sec2/sec_crypto.c | 4 +-
drivers/crypto/hisilicon/sec2/sec_crypto.h | 4 +-
drivers/crypto/hisilicon/zip/zip.h | 4 +-
drivers/crypto/hisilicon/zip/zip_crypto.c | 4 +-
include/crypto/ecc_curve.h | 60 ++
include/crypto/ecdh.h | 2 -
net/bluetooth/ecdh_helper.c | 2 -
net/bluetooth/selftest.c| 2 +-
net/bluetooth/smp.c | 6 +-
24 files changed, 1085 insertions(+), 128 deletions(-)
create mode 100644 include/crypto/ecc_curve.h
--
2.8.1
[PATCH v9 7/7] crypto: hisilicon/hpre - add 'CURVE25519' algorithm
Enable 'CURVE25519' algorithm in Kunpeng 930.
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
Reported-by: kernel test robot
---
drivers/crypto/hisilicon/Kconfig| 1 +
drivers/crypto/hisilicon/hpre/hpre.h| 2 +
drivers/crypto/hisilicon/hpre/hpre_crypto.c | 366 +++-
3 files changed, 361 insertions(+), 8 deletions(-)
diff --git a/drivers/crypto/hisilicon/Kconfig b/drivers/crypto/hisilicon/Kconfig
index 8431926..c45adb1 100644
--- a/drivers/crypto/hisilicon/Kconfig
+++ b/drivers/crypto/hisilicon/Kconfig
@@ -65,6 +65,7 @@ config CRYPTO_DEV_HISI_HPRE
depends on UACCE || UACCE=n
depends on ARM64 || (COMPILE_TEST && 64BIT)
depends on ACPI
+ select CRYPTO_LIB_CURVE25519_GENERIC
select CRYPTO_DEV_HISI_QM
select CRYPTO_DH
select CRYPTO_RSA
diff --git a/drivers/crypto/hisilicon/hpre/hpre.h
b/drivers/crypto/hisilicon/hpre/hpre.h
index 50e6b2e..92892e3 100644
--- a/drivers/crypto/hisilicon/hpre/hpre.h
+++ b/drivers/crypto/hisilicon/hpre/hpre.h
@@ -84,6 +84,8 @@ enum hpre_alg_type {
HPRE_ALG_DH_G2 = 0x4,
HPRE_ALG_DH = 0x5,
HPRE_ALG_ECC_MUL = 0xD,
+ /* shared by x25519 and x448, but x448 is not supported now */
+ HPRE_ALG_CURVE25519_MUL = 0x10,
};
struct hpre_sqe {
diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
index a6010b1..53068d2 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
/* Copyright (c) 2019 HiSilicon Limited. */
#include
+#include
#include
#include
#include
@@ -89,6 +90,16 @@ struct hpre_ecdh_ctx {
dma_addr_t dma_g;
};
+struct hpre_curve25519_ctx {
+ /* low address: p->a->k */
+ unsigned char *p;
+ dma_addr_t dma_p;
+
+ /* gx coordinate */
+ unsigned char *g;
+ dma_addr_t dma_g;
+};
+
struct hpre_ctx {
struct hisi_qp *qp;
struct hpre_asym_request **req_list;
@@ -101,6 +112,7 @@ struct hpre_ctx {
struct hpre_rsa_ctx rsa;
struct hpre_dh_ctx dh;
struct hpre_ecdh_ctx ecdh;
+ struct hpre_curve25519_ctx curve25519;
};
/* for ecc algorithms */
unsigned int curve_id;
@@ -115,6 +127,7 @@ struct hpre_asym_request {
struct akcipher_request *rsa;
struct kpp_request *dh;
struct kpp_request *ecdh;
+ struct kpp_request *curve25519;
} areq;
int err;
int req_id;
@@ -437,7 +450,6 @@ static void hpre_alg_cb(struct hisi_qp *qp, void *resp)
struct hpre_sqe *sqe = resp;
struct hpre_asym_request *req = ctx->req_list[le16_to_cpu(sqe->tag)];
-
if (unlikely(!req)) {
atomic64_inc([HPRE_INVALID_REQ_CNT].value);
return;
@@ -1167,6 +1179,12 @@ static void hpre_ecc_clear_ctx(struct hpre_ctx *ctx,
bool is_clear_all,
memzero_explicit(ctx->ecdh.p + shift, sz);
dma_free_coherent(dev, sz << 3, ctx->ecdh.p, ctx->ecdh.dma_p);
ctx->ecdh.p = NULL;
+ } else if (!is_ecdh && ctx->curve25519.p) {
+ /* curve25519: p->a->k */
+ memzero_explicit(ctx->curve25519.p + shift, sz);
+ dma_free_coherent(dev, sz << 2, ctx->curve25519.p,
+ ctx->curve25519.dma_p);
+ ctx->curve25519.p = NULL;
}
hpre_ctx_clear(ctx, is_clear_all);
@@ -1549,6 +1567,312 @@ static void hpre_ecdh_exit_tfm(struct crypto_kpp *tfm)
hpre_ecc_clear_ctx(ctx, true, true);
}
+static void hpre_curve25519_fill_curve(struct hpre_ctx *ctx, const void *buf,
+ unsigned int len)
+{
+ u8 secret[CURVE25519_KEY_SIZE] = { 0 };
+ unsigned int sz = ctx->key_sz;
+ const struct ecc_curve *curve;
+ unsigned int shift = sz << 1;
+ void *p;
+
+ /*
+* The key from 'buf' is in little-endian, we should preprocess it as
+* the description in rfc7748: "k[0] &= 248, k[31] &= 127, k[31] |= 64",
+* then convert it to big endian. Only in this way, the result can be
+* the same as the software curve-25519 that exists in crypto.
+*/
+ memcpy(secret, buf, len);
+ curve25519_clamp_secret(secret);
+ hpre_key_to_big_end(secret, CURVE25519_KEY_SIZE);
+
+ p = ctx->curve25519.p + sz - len;
+
+ curve = ecc_get_curve25519();
+
+ /* fill curve parameters */
+ fill_curve_param(p, curve->p, len, curve->g.ndigits);
+ fill_curve_param(p + sz, curve->a, len, curve->g.ndigits);
+ memcpy(p + shift, secret, len);
+ fill_curve_param(p + shift + sz, curve->g.x, len, curve->g.ndigits);
+ memzero_explicit(secret, CURVE25519_KEY_SIZE);
+}
+
+static int hpre_curve25519_set_param(struct hpre_ctx
[PATCH v9 6/7] crypto: add curve25519 params and expose them
1. Add curve 25519 parameters in 'crypto/ecc_curve_defs.h';
2. Add curve25519 interface 'ecc_get_curve25519_param' in
'include/crypto/ecc_curve.h', to make its parameters be
exposed to everyone in kernel tree.
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
---
crypto/ecc.c | 6 ++
crypto/ecc_curve_defs.h| 17 +
include/crypto/ecc_curve.h | 7 +++
3 files changed, 30 insertions(+)
diff --git a/crypto/ecc.c b/crypto/ecc.c
index 4b55ad0..0798a18 100644
--- a/crypto/ecc.c
+++ b/crypto/ecc.c
@@ -43,6 +43,12 @@ typedef struct {
u64 m_high;
} uint128_t;
+/* Returns curv25519 curve param */
+const struct ecc_curve *ecc_get_curve25519(void)
+{
+ return _25519;
+}
+EXPORT_SYMBOL(ecc_get_curve25519);
const struct ecc_curve *ecc_get_curve(unsigned int curve_id)
{
diff --git a/crypto/ecc_curve_defs.h b/crypto/ecc_curve_defs.h
index 69be6c7..d7769cc 100644
--- a/crypto/ecc_curve_defs.h
+++ b/crypto/ecc_curve_defs.h
@@ -54,4 +54,21 @@ static struct ecc_curve nist_p256 = {
.b = nist_p256_b
};
+/* curve25519 */
+static u64 curve25519_g_x[] = { 0x0009, 0x,
+ 0x, 0x };
+static u64 curve25519_p[] = { 0xffed, 0x,
+ 0x, 0x7fff };
+static u64 curve25519_a[] = { 0x0001DB41, 0x,
+ 0x, 0x };
+static const struct ecc_curve ecc_25519 = {
+ .name = "curve25519",
+ .g = {
+ .x = curve25519_g_x,
+ .ndigits = 4,
+ },
+ .p = curve25519_p,
+ .a = curve25519_a,
+};
+
#endif
diff --git a/include/crypto/ecc_curve.h b/include/crypto/ecc_curve.h
index 19a35da..7096478 100644
--- a/include/crypto/ecc_curve.h
+++ b/include/crypto/ecc_curve.h
@@ -50,4 +50,11 @@ struct ecc_curve {
*/
const struct ecc_curve *ecc_get_curve(unsigned int curve_id);
+/**
+ * ecc_get_curve25519() - get curve25519 curve;
+ *
+ * Returns curve25519
+ */
+const struct ecc_curve *ecc_get_curve25519(void);
+
#endif
--
2.8.1
[PATCH v9 2/7] crypto: hisilicon/hpre - add algorithm type
Algorithm type is brought in to get hardware HPRE queue
to support different algorithms.
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
---
drivers/crypto/hisilicon/hpre/hpre.h| 10 +-
drivers/crypto/hisilicon/hpre/hpre_crypto.c | 12 ++--
drivers/crypto/hisilicon/hpre/hpre_main.c | 11 +--
3 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/crypto/hisilicon/hpre/hpre.h
b/drivers/crypto/hisilicon/hpre/hpre.h
index cc50f23..02193e1 100644
--- a/drivers/crypto/hisilicon/hpre/hpre.h
+++ b/drivers/crypto/hisilicon/hpre/hpre.h
@@ -10,6 +10,14 @@
#define HPRE_PF_DEF_Q_NUM 64
#define HPRE_PF_DEF_Q_BASE 0
+/*
+ * type used in qm sqc DW6.
+ * 0 - Algorithm which has been supported in V2, like RSA, DH and so on;
+ * 1 - ECC algorithm in V3.
+ */
+#define HPRE_V2_ALG_TYPE 0
+#define HPRE_V3_ECC_ALG_TYPE 1
+
enum {
HPRE_CLUSTER0,
HPRE_CLUSTER1,
@@ -92,7 +100,7 @@ struct hpre_sqe {
__le32 rsvd1[_HPRE_SQE_ALIGN_EXT];
};
-struct hisi_qp *hpre_create_qp(void);
+struct hisi_qp *hpre_create_qp(u8 type);
int hpre_algs_register(struct hisi_qm *qm);
void hpre_algs_unregister(struct hisi_qm *qm);
diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
index d89b2f5..712bea9 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
@@ -152,12 +152,12 @@ static void hpre_rm_req_from_ctx(struct hpre_asym_request
*hpre_req)
}
}
-static struct hisi_qp *hpre_get_qp_and_start(void)
+static struct hisi_qp *hpre_get_qp_and_start(u8 type)
{
struct hisi_qp *qp;
int ret;
- qp = hpre_create_qp();
+ qp = hpre_create_qp(type);
if (!qp) {
pr_err("Can not create hpre qp!\n");
return ERR_PTR(-ENODEV);
@@ -422,11 +422,11 @@ static void hpre_alg_cb(struct hisi_qp *qp, void *resp)
req->cb(ctx, resp);
}
-static int hpre_ctx_init(struct hpre_ctx *ctx)
+static int hpre_ctx_init(struct hpre_ctx *ctx, u8 type)
{
struct hisi_qp *qp;
- qp = hpre_get_qp_and_start();
+ qp = hpre_get_qp_and_start(type);
if (IS_ERR(qp))
return PTR_ERR(qp);
@@ -674,7 +674,7 @@ static int hpre_dh_init_tfm(struct crypto_kpp *tfm)
{
struct hpre_ctx *ctx = kpp_tfm_ctx(tfm);
- return hpre_ctx_init(ctx);
+ return hpre_ctx_init(ctx, HPRE_V2_ALG_TYPE);
}
static void hpre_dh_exit_tfm(struct crypto_kpp *tfm)
@@ -1100,7 +1100,7 @@ static int hpre_rsa_init_tfm(struct crypto_akcipher *tfm)
return PTR_ERR(ctx->rsa.soft_tfm);
}
- ret = hpre_ctx_init(ctx);
+ ret = hpre_ctx_init(ctx, HPRE_V2_ALG_TYPE);
if (ret)
crypto_free_akcipher(ctx->rsa.soft_tfm);
diff --git a/drivers/crypto/hisilicon/hpre/hpre_main.c
b/drivers/crypto/hisilicon/hpre/hpre_main.c
index e7a2c70..76f0a87 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_main.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_main.c
@@ -226,13 +226,20 @@ static u32 vfs_num;
module_param_cb(vfs_num, _num_ops, _num, 0444);
MODULE_PARM_DESC(vfs_num, "Number of VFs to enable(1-63), 0(default)");
-struct hisi_qp *hpre_create_qp(void)
+struct hisi_qp *hpre_create_qp(u8 type)
{
int node = cpu_to_node(smp_processor_id());
struct hisi_qp *qp = NULL;
int ret;
- ret = hisi_qm_alloc_qps_node(_devices, 1, 0, node, );
+ if (type != HPRE_V2_ALG_TYPE && type != HPRE_V3_ECC_ALG_TYPE)
+ return NULL;
+
+ /*
+* type: 0 - RSA/DH. algorithm supported in V2,
+* 1 - ECC algorithm in V3.
+*/
+ ret = hisi_qm_alloc_qps_node(_devices, 1, type, node, );
if (!ret)
return qp;
--
2.8.1
[PATCH v9 5/7] crypto: hisilicon/hpre - add 'ECDH' algorithm
1. Enable 'ECDH' algorithm in Kunpeng 930;
2. HPRE ECDH Support: ecdh-nist-p192, ecdh-nist-p256.
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
---
drivers/crypto/hisilicon/hpre/hpre.h| 2 +-
drivers/crypto/hisilicon/hpre/hpre_crypto.c | 515 +++-
drivers/crypto/hisilicon/hpre/hpre_main.c | 1 +
3 files changed, 513 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/hisilicon/hpre/hpre.h
b/drivers/crypto/hisilicon/hpre/hpre.h
index 02193e1..50e6b2e 100644
--- a/drivers/crypto/hisilicon/hpre/hpre.h
+++ b/drivers/crypto/hisilicon/hpre/hpre.h
@@ -83,6 +83,7 @@ enum hpre_alg_type {
HPRE_ALG_KG_CRT = 0x3,
HPRE_ALG_DH_G2 = 0x4,
HPRE_ALG_DH = 0x5,
+ HPRE_ALG_ECC_MUL = 0xD,
};
struct hpre_sqe {
@@ -104,5 +105,4 @@ struct hisi_qp *hpre_create_qp(u8 type);
int hpre_algs_register(struct hisi_qm *qm);
void hpre_algs_unregister(struct hisi_qm *qm);
-
#endif
diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
index 712bea9..a6010b1 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
@@ -2,6 +2,8 @@
/* Copyright (c) 2019 HiSilicon Limited. */
#include
#include
+#include
+#include
#include
#include
#include
@@ -36,6 +38,13 @@ struct hpre_ctx;
#define HPRE_DFX_SEC_TO_US 100
#define HPRE_DFX_US_TO_NS 1000
+/* size in bytes of the n prime */
+#define HPRE_ECC_NIST_P192_N_SIZE 24
+#define HPRE_ECC_NIST_P256_N_SIZE 32
+
+/* size in bytes */
+#define HPRE_ECC_HW256_KSZ_B 32
+
typedef void (*hpre_cb)(struct hpre_ctx *ctx, void *sqe);
struct hpre_rsa_ctx {
@@ -61,14 +70,25 @@ struct hpre_dh_ctx {
* else if base if the counterpart public key we
* compute the shared secret
* ZZ = yb^xa mod p; [RFC2631 sec 2.1.1]
+* low address: d--->n, please refer to Hisilicon HPRE UM
*/
- char *xa_p; /* low address: d--->n, please refer to Hisilicon HPRE UM */
+ char *xa_p;
dma_addr_t dma_xa_p;
char *g; /* m */
dma_addr_t dma_g;
};
+struct hpre_ecdh_ctx {
+ /* low address: p->a->k->b */
+ unsigned char *p;
+ dma_addr_t dma_p;
+
+ /* low address: x->y */
+ unsigned char *g;
+ dma_addr_t dma_g;
+};
+
struct hpre_ctx {
struct hisi_qp *qp;
struct hpre_asym_request **req_list;
@@ -80,7 +100,10 @@ struct hpre_ctx {
union {
struct hpre_rsa_ctx rsa;
struct hpre_dh_ctx dh;
+ struct hpre_ecdh_ctx ecdh;
};
+ /* for ecc algorithms */
+ unsigned int curve_id;
};
struct hpre_asym_request {
@@ -91,6 +114,7 @@ struct hpre_asym_request {
union {
struct akcipher_request *rsa;
struct kpp_request *dh;
+ struct kpp_request *ecdh;
} areq;
int err;
int req_id;
@@ -1115,6 +1139,416 @@ static void hpre_rsa_exit_tfm(struct crypto_akcipher
*tfm)
crypto_free_akcipher(ctx->rsa.soft_tfm);
}
+static void hpre_key_to_big_end(u8 *data, int len)
+{
+ int i, j;
+ u8 tmp;
+
+ for (i = 0; i < len / 2; i++) {
+ j = len - i - 1;
+ tmp = data[j];
+ data[j] = data[i];
+ data[i] = tmp;
+ }
+}
+
+static void hpre_ecc_clear_ctx(struct hpre_ctx *ctx, bool is_clear_all,
+ bool is_ecdh)
+{
+ struct device *dev = HPRE_DEV(ctx);
+ unsigned int sz = ctx->key_sz;
+ unsigned int shift = sz << 1;
+
+ if (is_clear_all)
+ hisi_qm_stop_qp(ctx->qp);
+
+ if (is_ecdh && ctx->ecdh.p) {
+ /* ecdh: p->a->k->b */
+ memzero_explicit(ctx->ecdh.p + shift, sz);
+ dma_free_coherent(dev, sz << 3, ctx->ecdh.p, ctx->ecdh.dma_p);
+ ctx->ecdh.p = NULL;
+ }
+
+ hpre_ctx_clear(ctx, is_clear_all);
+}
+
+static unsigned int hpre_ecdh_supported_curve(unsigned short id)
+{
+ switch (id) {
+ case ECC_CURVE_NIST_P192:
+ case ECC_CURVE_NIST_P256:
+ return HPRE_ECC_HW256_KSZ_B;
+ default:
+ break;
+ }
+
+ return 0;
+}
+
+static void fill_curve_param(void *addr, u64 *param, unsigned int cur_sz, u8
ndigits)
+{
+ unsigned int sz = cur_sz - (ndigits - 1) * sizeof(u64);
+ u8 i = 0;
+
+ while (i < ndigits - 1) {
+ memcpy(addr + sizeof(u64) * i, [i], sizeof(u64));
+ i++;
+ }
+
+ memcpy(addr + sizeof(u64) * i, [ndigits - 1], sz);
+ hpre_key_to_big_end((u8 *)addr, cur_sz);
+}
+
+static int hpre_ecdh_fill_curve(struct hpre_ctx *ctx, struct ecdh *params,
+ unsigned int cur_sz)
+{
+ unsigned int shifta = ctx->key_sz << 1;
+ unsigned int shiftb = ctx->key_sz << 2;
+ void *p = ctx->ecdh.p + ctx->key_sz -
[PATCH v9 3/7] crypto: move curve_id of ECDH from the key to algorithm name
1. crypto and crypto/atmel-ecc:
Move curve id of ECDH from the key into the algorithm name instead
in crypto and atmel-ecc, so ECDH algorithm name change form 'ecdh'
to 'ecdh-nist-pxxx', and we cannot use 'curve_id' in 'struct ecdh';
2. crypto/testmgr and net/bluetooth:
Modify 'testmgr.c', 'testmgr.h' and 'net/bluetooth' to adapt
the modification.
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
Reported-by: kernel test robot
---
crypto/ecdh.c | 72 +++--
crypto/ecdh_helper.c| 4 +--
crypto/testmgr.c| 13 ++--
crypto/testmgr.h| 34 ++---
drivers/crypto/atmel-ecc.c | 14 -
include/crypto/ecdh.h | 2 --
net/bluetooth/ecdh_helper.c | 2 --
net/bluetooth/selftest.c| 2 +-
net/bluetooth/smp.c | 6 ++--
9 files changed, 88 insertions(+), 61 deletions(-)
diff --git a/crypto/ecdh.c b/crypto/ecdh.c
index 96f80c8..04a427b 100644
--- a/crypto/ecdh.c
+++ b/crypto/ecdh.c
@@ -23,33 +23,16 @@ static inline struct ecdh_ctx *ecdh_get_ctx(struct
crypto_kpp *tfm)
return kpp_tfm_ctx(tfm);
}
-static unsigned int ecdh_supported_curve(unsigned int curve_id)
-{
- switch (curve_id) {
- case ECC_CURVE_NIST_P192: return ECC_CURVE_NIST_P192_DIGITS;
- case ECC_CURVE_NIST_P256: return ECC_CURVE_NIST_P256_DIGITS;
- default: return 0;
- }
-}
-
static int ecdh_set_secret(struct crypto_kpp *tfm, const void *buf,
unsigned int len)
{
struct ecdh_ctx *ctx = ecdh_get_ctx(tfm);
struct ecdh params;
- unsigned int ndigits;
if (crypto_ecdh_decode_key(buf, len, ) < 0 ||
- params.key_size > sizeof(ctx->private_key))
+ params.key_size > sizeof(u64) * ctx->ndigits)
return -EINVAL;
- ndigits = ecdh_supported_curve(params.curve_id);
- if (!ndigits)
- return -EINVAL;
-
- ctx->curve_id = params.curve_id;
- ctx->ndigits = ndigits;
-
if (!params.key || !params.key_size)
return ecc_gen_privkey(ctx->curve_id, ctx->ndigits,
ctx->private_key);
@@ -140,13 +123,24 @@ static unsigned int ecdh_max_size(struct crypto_kpp *tfm)
return ctx->ndigits << (ECC_DIGITS_TO_BYTES_SHIFT + 1);
}
-static struct kpp_alg ecdh = {
+static int ecdh_nist_p192_init_tfm(struct crypto_kpp *tfm)
+{
+ struct ecdh_ctx *ctx = ecdh_get_ctx(tfm);
+
+ ctx->curve_id = ECC_CURVE_NIST_P192;
+ ctx->ndigits = ECC_CURVE_NIST_P192_DIGITS;
+
+ return 0;
+}
+
+static struct kpp_alg ecdh_nist_p192 = {
.set_secret = ecdh_set_secret,
.generate_public_key = ecdh_compute_value,
.compute_shared_secret = ecdh_compute_value,
.max_size = ecdh_max_size,
+ .init = ecdh_nist_p192_init_tfm,
.base = {
- .cra_name = "ecdh",
+ .cra_name = "ecdh-nist-p192",
.cra_driver_name = "ecdh-generic",
.cra_priority = 100,
.cra_module = THIS_MODULE,
@@ -154,14 +148,48 @@ static struct kpp_alg ecdh = {
},
};
+static int ecdh_nist_p256_init_tfm(struct crypto_kpp *tfm)
+{
+ struct ecdh_ctx *ctx = ecdh_get_ctx(tfm);
+
+ ctx->curve_id = ECC_CURVE_NIST_P256;
+ ctx->ndigits = ECC_CURVE_NIST_P256_DIGITS;
+
+ return 0;
+}
+
+static struct kpp_alg ecdh_nist_p256 = {
+ .set_secret = ecdh_set_secret,
+ .generate_public_key = ecdh_compute_value,
+ .compute_shared_secret = ecdh_compute_value,
+ .max_size = ecdh_max_size,
+ .init = ecdh_nist_p256_init_tfm,
+ .base = {
+ .cra_name = "ecdh-nist-p256",
+ .cra_driver_name = "ecdh-generic",
+ .cra_priority = 100,
+ .cra_module = THIS_MODULE,
+ .cra_ctxsize = sizeof(struct ecdh_ctx),
+ },
+};
+
+static bool ecdh_nist_p192_registered;
+
static int ecdh_init(void)
{
- return crypto_register_kpp();
+ int ret;
+
+ ret = crypto_register_kpp(_nist_p192);
+ ecdh_nist_p192_registered = ret == 0;
+
+ return crypto_register_kpp(_nist_p256);
}
static void ecdh_exit(void)
{
- crypto_unregister_kpp();
+ if (ecdh_nist_p192_registered)
+ crypto_unregister_kpp(_nist_p192);
+ crypto_unregister_kpp(_nist_p256);
}
subsys_initcall(ecdh_init);
diff --git a/crypto/ecdh_helper.c b/crypto/ecdh_helper.c
index fca63b5..f18f902 100644
--- a/crypto/ecdh_helper.c
+++ b/crypto/ecdh_helper.c
@@ -10,7 +10,7 @@
#include
#include
-#define ECDH_KPP_SECRET_MIN_SIZE (sizeof(struct kpp_secret) + 2 *
sizeof(short))
+#define ECDH_KPP_SECRET_MIN_SIZE (sizeof(struct kpp_secret) + sizeof(short))
static inline u8 *ecdh_pack_data(void *dst, const void *src, size_t sz)
{
@@ -46,7 +46,6 @@ int crypto_ecdh_encode_key(char *buf, unsigned int len,
return -EINVAL;
[PATCH v9 1/7] crypto: hisilicon/hpre - add version adapt to new algorithms
A new generation of accelerator Kunpeng930 has appeared, and the
corresponding driver needs to be updated to support some new
algorithms of Kunpeng930. To be compatible with Kunpeng920, we
add parameter 'struct hisi_qm *qm' to sec_algs_(un)register to
identify the chip's version.
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
Reviewed-by: Longfang Liu
---
drivers/crypto/hisilicon/hpre/hpre.h| 5 +++--
drivers/crypto/hisilicon/hpre/hpre_crypto.c | 4 ++--
drivers/crypto/hisilicon/qm.c | 4 ++--
drivers/crypto/hisilicon/qm.h | 4 ++--
drivers/crypto/hisilicon/sec2/sec.h | 4 ++--
drivers/crypto/hisilicon/sec2/sec_crypto.c | 4 ++--
drivers/crypto/hisilicon/sec2/sec_crypto.h | 4 ++--
drivers/crypto/hisilicon/zip/zip.h | 4 ++--
drivers/crypto/hisilicon/zip/zip_crypto.c | 4 ++--
9 files changed, 19 insertions(+), 18 deletions(-)
diff --git a/drivers/crypto/hisilicon/hpre/hpre.h
b/drivers/crypto/hisilicon/hpre/hpre.h
index 181c109..cc50f23 100644
--- a/drivers/crypto/hisilicon/hpre/hpre.h
+++ b/drivers/crypto/hisilicon/hpre/hpre.h
@@ -93,7 +93,8 @@ struct hpre_sqe {
};
struct hisi_qp *hpre_create_qp(void);
-int hpre_algs_register(void);
-void hpre_algs_unregister(void);
+int hpre_algs_register(struct hisi_qm *qm);
+void hpre_algs_unregister(struct hisi_qm *qm);
+
#endif
diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
index a87f990..d89b2f5 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
@@ -1154,7 +1154,7 @@ static struct kpp_alg dh = {
};
#endif
-int hpre_algs_register(void)
+int hpre_algs_register(struct hisi_qm *qm)
{
int ret;
@@ -1171,7 +1171,7 @@ int hpre_algs_register(void)
return ret;
}
-void hpre_algs_unregister(void)
+void hpre_algs_unregister(struct hisi_qm *qm)
{
crypto_unregister_akcipher();
#ifdef CONFIG_CRYPTO_DH
diff --git a/drivers/crypto/hisilicon/qm.c b/drivers/crypto/hisilicon/qm.c
index 13cb421..bc23174 100644
--- a/drivers/crypto/hisilicon/qm.c
+++ b/drivers/crypto/hisilicon/qm.c
@@ -4084,7 +4084,7 @@ int hisi_qm_alg_register(struct hisi_qm *qm, struct
hisi_qm_list *qm_list)
mutex_unlock(_list->lock);
if (flag) {
- ret = qm_list->register_to_crypto();
+ ret = qm_list->register_to_crypto(qm);
if (ret) {
mutex_lock(_list->lock);
list_del(>list);
@@ -4115,7 +4115,7 @@ void hisi_qm_alg_unregister(struct hisi_qm *qm, struct
hisi_qm_list *qm_list)
mutex_unlock(_list->lock);
if (list_empty(_list->list))
- qm_list->unregister_from_crypto();
+ qm_list->unregister_from_crypto(qm);
}
EXPORT_SYMBOL_GPL(hisi_qm_alg_unregister);
diff --git a/drivers/crypto/hisilicon/qm.h b/drivers/crypto/hisilicon/qm.h
index 54967c6..f91110f 100644
--- a/drivers/crypto/hisilicon/qm.h
+++ b/drivers/crypto/hisilicon/qm.h
@@ -199,8 +199,8 @@ struct hisi_qm_err_ini {
struct hisi_qm_list {
struct mutex lock;
struct list_head list;
- int (*register_to_crypto)(void);
- void (*unregister_from_crypto)(void);
+ int (*register_to_crypto)(struct hisi_qm *qm);
+ void (*unregister_from_crypto)(struct hisi_qm *qm);
};
struct hisi_qm {
diff --git a/drivers/crypto/hisilicon/sec2/sec.h
b/drivers/crypto/hisilicon/sec2/sec.h
index 0849191..17ddb20 100644
--- a/drivers/crypto/hisilicon/sec2/sec.h
+++ b/drivers/crypto/hisilicon/sec2/sec.h
@@ -183,6 +183,6 @@ struct sec_dev {
void sec_destroy_qps(struct hisi_qp **qps, int qp_num);
struct hisi_qp **sec_create_qps(void);
-int sec_register_to_crypto(void);
-void sec_unregister_from_crypto(void);
+int sec_register_to_crypto(struct hisi_qm *qm);
+void sec_unregister_from_crypto(struct hisi_qm *qm);
#endif
diff --git a/drivers/crypto/hisilicon/sec2/sec_crypto.c
b/drivers/crypto/hisilicon/sec2/sec_crypto.c
index 2eaa516..f835514 100644
--- a/drivers/crypto/hisilicon/sec2/sec_crypto.c
+++ b/drivers/crypto/hisilicon/sec2/sec_crypto.c
@@ -1634,7 +1634,7 @@ static struct aead_alg sec_aeads[] = {
AES_BLOCK_SIZE, AES_BLOCK_SIZE, SHA512_DIGEST_SIZE),
};
-int sec_register_to_crypto(void)
+int sec_register_to_crypto(struct hisi_qm *qm)
{
int ret;
@@ -1651,7 +1651,7 @@ int sec_register_to_crypto(void)
return ret;
}
-void sec_unregister_from_crypto(void)
+void sec_unregister_from_crypto(struct hisi_qm *qm)
{
crypto_unregister_skciphers(sec_skciphers,
ARRAY_SIZE(sec_skciphers));
diff --git a/drivers/crypto/hisilicon/sec2/sec_crypto.h
b/drivers/crypto/hisilicon/sec2/sec_crypto.h
index b2786e1..0e933e7 100644
--- a/drivers/crypto/hisilicon/sec2/sec_crypto.h
+++ b/drivers/crypto/hisilicon/sec2/sec_crypto.h
@@ -211,6 +211,6 @@ struct sec_sqe {
struct sec_sqe_type2 type2;
};
-int
Re: [REGRESSION] "split bio_kmalloc from bio_alloc_bioset" causing crash shortly after bootup
On Mon, Feb 22, 2021 at 08:22:09PM -0800, John Stultz wrote: > I'm wondering if given there are multiple call sites, that in > bio_alloc_bioset() would something like the following make more sense? > (apologies, copy pasted so this is whitespace corrupted) > thanks No. The fallback from the mempool backing to plain kmalloc is highly dangerous, which is one of the reasons it was removed. The other being that we don't want to disturb the fast path with this slow path.
Re: [REGRESSION] "split bio_kmalloc from bio_alloc_bioset" causing crash shortly after bootup
On Tue, Feb 23, 2021 at 03:51:23AM +, Chaitanya Kulkarni wrote:
> Looking at the other call sites do we need something like following ?
> Since __blk_queue_bounce() passes the NULL for the passthru case as a
> bio_set value ?
Well, that is a somewhat odd calling convention. What about the patch below
instead? That being we really need to kill this bouncing code off..
diff --git a/block/bounce.c b/block/bounce.c
index fc55314aa4269a..789fbcacb1e92a 100644
--- a/block/bounce.c
+++ b/block/bounce.c
@@ -214,9 +214,9 @@ static void bounce_end_io_read_isa(struct bio *bio)
__bounce_end_io_read(bio, _page_pool);
}
-static struct bio *bounce_clone_bio(struct bio *bio_src, gfp_t gfp_mask,
- struct bio_set *bs)
+static struct bio *bounce_clone_bio(struct bio *bio_src, bool passthrough)
{
+ unsigned int nr_vecs = bio_segments(bio_src);
struct bvec_iter iter;
struct bio_vec bv;
struct bio *bio;
@@ -242,8 +242,10 @@ static struct bio *bounce_clone_bio(struct bio *bio_src,
gfp_t gfp_mask,
*asking for trouble and would force extra work on
*__bio_clone_fast() anyways.
*/
-
- bio = bio_alloc_bioset(gfp_mask, bio_segments(bio_src), bs);
+ if (passthrough)
+ bio = bio_kmalloc(GFP_NOIO, nr_vecs);
+ else
+ bio = bio_alloc_bioset(GFP_NOIO, nr_vecs, _bio_set);
if (!bio)
return NULL;
bio->bi_bdev= bio_src->bi_bdev;
@@ -269,11 +271,11 @@ static struct bio *bounce_clone_bio(struct bio *bio_src,
gfp_t gfp_mask,
break;
}
- if (bio_crypt_clone(bio, bio_src, gfp_mask) < 0)
+ if (bio_crypt_clone(bio, bio_src, GFP_NOIO) < 0)
goto err_put;
if (bio_integrity(bio_src) &&
- bio_integrity_clone(bio, bio_src, gfp_mask) < 0)
+ bio_integrity_clone(bio, bio_src, GFP_NOIO) < 0)
goto err_put;
bio_clone_blkg_association(bio, bio_src);
@@ -313,8 +315,7 @@ static void __blk_queue_bounce(struct request_queue *q,
struct bio **bio_orig,
submit_bio_noacct(*bio_orig);
*bio_orig = bio;
}
- bio = bounce_clone_bio(*bio_orig, GFP_NOIO, passthrough ? NULL :
- _bio_set);
+ bio = bounce_clone_bio(*bio_orig, passthrough);
/*
* Bvec table can't be updated by bio_for_each_segment_all(),
Re: 'perf probe' and symbols from .text.
Hi,
On Tue, 23 Feb 2021 00:05:08 +0900
Masami Hiramatsu wrote:
>
> /* Adjust symbol name and address */
> static int post_process_probe_trace_point(struct probe_trace_point *tp,
>struct map *map, unsigned long
> offs)
> {
> struct symbol *sym;
> u64 addr = tp->address - offs;
>
> sym = map__find_symbol(map, addr);
> if (!sym)
> return -ENOENT;
>
>
> So it seems "map" may not load the symbol out of ".text".
> This need to be fixed, since the map is widely used in the perf.
OK, I found a root cause of this issue.
dso__process_kernel_symbol() (which invoked from map__load() path) only adds the
symbols in ".text" section to the symbol list. It must be fixed.
Thank you,
--
Masami Hiramatsu
drivers/video/fbdev/aty/atyfb_base.c:2002:7: error: implicit declaration of function 'aty_ld_lcd'
Hi Vaibhav,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 3b9cdafb5358eb9f3790de2f728f765fef100731
commit: 4e139a9abb007370e8d0266ea31192e606c800cf fbdev: aty: remove CONFIG_PM
container
date: 5 months ago
config: powerpc64-randconfig-r036-20210223 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
c9439ca36342fb6013187d0a69aef92736951476)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc64 cross compiling tool for clang build
# apt-get install binutils-powerpc64-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4e139a9abb007370e8d0266ea31192e606c800cf
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 4e139a9abb007370e8d0266ea31192e606c800cf
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross
ARCH=powerpc64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/video/fbdev/aty/atyfb_base.c:2002:7: error: implicit declaration of
>> function 'aty_ld_lcd' [-Werror,-Wimplicit-function-declaration]
pm = aty_ld_lcd(POWER_MANAGEMENT, par);
^
>> drivers/video/fbdev/aty/atyfb_base.c:2004:2: error: implicit declaration of
>> function 'aty_st_lcd' [-Werror,-Wimplicit-function-declaration]
aty_st_lcd(POWER_MANAGEMENT, pm, par);
^
drivers/video/fbdev/aty/atyfb_base.c:2004:2: note: did you mean 'aty_ld_lcd'?
drivers/video/fbdev/aty/atyfb_base.c:2002:7: note: 'aty_ld_lcd' declared here
pm = aty_ld_lcd(POWER_MANAGEMENT, par);
^
2 errors generated.
vim +/aty_ld_lcd +2002 drivers/video/fbdev/aty/atyfb_base.c
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16
1993
efc08a75d3a2d4 drivers/video/aty/atyfb_base.c Ville Syrjala 2006-12-08
1994 #ifdef CONFIG_PPC_PMAC
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16
1995 /* Power management routines. Those are used for PowerBook sleep.
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16
1996 */
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16
1997 static int aty_power_mgmt(int sleep, struct atyfb_par *par)
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16
1998 {
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16
1999 u32 pm;
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16
2000 int timeout;
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16
2001
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16
@2002 pm = aty_ld_lcd(POWER_MANAGEMENT, par);
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16
2003 pm = (pm & ~PWR_MGT_MODE_MASK) | PWR_MGT_MODE_REG;
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16
@2004 aty_st_lcd(POWER_MANAGEMENT, pm, par);
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16
2005 pm = aty_ld_lcd(POWER_MANAGEMENT, par);
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16
2006
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16
2007 timeout = 2000;
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16
2008 if (sleep) {
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16
2009 /* Sleep */
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16
2010 pm &= ~PWR_MGT_ON;
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16
2011 aty_st_lcd(POWER_MANAGEMENT, pm, par);
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16
2012 pm = aty_ld_lcd(POWER_MANAGEMENT, par);
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16
2013 udelay(10);
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16
2014 pm &= ~(PWR_BLON | AUTO_PWR_UP);
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16
2015 pm |= SUSPEND_NOW;
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16
2016 aty_st_lcd(POWER_MANAGEMENT, pm, par);
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16
2017 pm =
Re: [PATCH v2] rtw88: 8822ce: fix wifi disconnect after S3/S4 on HONOR laptop
Pkshih writes:
>> > --- a/drivers/net/wireless/realtek/rtw88/rtw8822ce.c
>> > +++ b/drivers/net/wireless/realtek/rtw88/rtw8822ce.c
>> > @@ -25,7 +25,6 @@ static struct pci_driver rtw_8822ce_driver = {
>> >Â Â .id_table = rtw_8822ce_id_table,
>> >Â Â .probe = rtw_pci_probe,
>> >Â Â .remove = rtw_pci_remove,
>> > - .driver.pm = _pm_ops,
>>
>> Why just 8822ce? Why not remove rtw_pm_ops entirely if it just creates
>> problems?
>
> I think we can't remove rtw_pm_ops, because wowlan will not work.
Ah. A comment code in the code stating that would be nice.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [REGRESSION] "split bio_kmalloc from bio_alloc_bioset" causing crash shortly after bootup
The problem is that the blk-crypto fallback code calls bio_split with a NULL bioset. That was aready broken before, as the mempool needed to guarantee forward progress was missing, but is not fatal. Satya, can you look into adding a mempool that can guarantees forward progress here?
[PATCH net v4 1/1] net: introduce CAN specific pointer in the struct net_device
Since 20dd3850bcf8 ("can: Speed up CAN frame receiption by using
ml_priv") the CAN framework uses per device specific data in the AF_CAN
protocol. For this purpose the struct net_device->ml_priv is used. Later
the ml_priv usage in CAN was extended for other users, one of them being
CAN_J1939.
Later in the kernel ml_priv was converted to an union, used by other
drivers. E.g. the tun driver started storing it's stats pointer.
Since tun devices can claim to be a CAN device, CAN specific protocols
will wrongly interpret this pointer, which will cause system crashes.
Mostly this issue is visible in the CAN_J1939 stack.
To fix this issue, we request a dedicated CAN pointer within the
net_device struct.
Reported-by: syzbot+5138c4dd15a0401be...@syzkaller.appspotmail.com
Fixes: 20dd3850bcf8 ("can: Speed up CAN frame receiption by using ml_priv")
Fixes: ffd956eef69b ("can: introduce CAN midlayer private and allocate it
automatically")
Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
Fixes: 497a5757ce4e ("tun: switch to net core provided statistics counters")
Signed-off-by: Oleksij Rempel
---
drivers/net/can/dev/dev.c | 4 +++-
drivers/net/can/slcan.c| 4 +++-
drivers/net/can/vcan.c | 2 +-
drivers/net/can/vxcan.c| 6 +-
include/linux/can/can-ml.h | 12
include/linux/netdevice.h | 34 +-
net/can/af_can.c | 34 ++
net/can/j1939/main.c | 22 --
net/can/j1939/socket.c | 13 -
net/can/proc.c | 19 +--
10 files changed, 84 insertions(+), 66 deletions(-)
diff --git a/drivers/net/can/dev/dev.c b/drivers/net/can/dev/dev.c
index d9281ae853f8..311d8564d611 100644
--- a/drivers/net/can/dev/dev.c
+++ b/drivers/net/can/dev/dev.c
@@ -239,6 +239,7 @@ void can_setup(struct net_device *dev)
struct net_device *alloc_candev_mqs(int sizeof_priv, unsigned int echo_skb_max,
unsigned int txqs, unsigned int rxqs)
{
+ struct can_ml_priv *can_ml;
struct net_device *dev;
struct can_priv *priv;
int size;
@@ -270,7 +271,8 @@ struct net_device *alloc_candev_mqs(int sizeof_priv,
unsigned int echo_skb_max,
priv = netdev_priv(dev);
priv->dev = dev;
- dev->ml_priv = (void *)priv + ALIGN(sizeof_priv, NETDEV_ALIGN);
+ can_ml = (void *)priv + ALIGN(sizeof_priv, NETDEV_ALIGN);
+ can_set_ml_priv(dev, can_ml);
if (echo_skb_max) {
priv->echo_skb_max = echo_skb_max;
diff --git a/drivers/net/can/slcan.c b/drivers/net/can/slcan.c
index a1bd1be09548..30c8d53c9745 100644
--- a/drivers/net/can/slcan.c
+++ b/drivers/net/can/slcan.c
@@ -516,6 +516,7 @@ static struct slcan *slc_alloc(void)
int i;
char name[IFNAMSIZ];
struct net_device *dev = NULL;
+ struct can_ml_priv *can_ml;
struct slcan *sl;
int size;
@@ -538,7 +539,8 @@ static struct slcan *slc_alloc(void)
dev->base_addr = i;
sl = netdev_priv(dev);
- dev->ml_priv = (void *)sl + ALIGN(sizeof(*sl), NETDEV_ALIGN);
+ can_ml = (void *)sl + ALIGN(sizeof(*sl), NETDEV_ALIGN);
+ can_set_ml_priv(dev, can_ml);
/* Initialize channel control data */
sl->magic = SLCAN_MAGIC;
diff --git a/drivers/net/can/vcan.c b/drivers/net/can/vcan.c
index 39ca14b0585d..067705e2850b 100644
--- a/drivers/net/can/vcan.c
+++ b/drivers/net/can/vcan.c
@@ -153,7 +153,7 @@ static void vcan_setup(struct net_device *dev)
dev->addr_len = 0;
dev->tx_queue_len = 0;
dev->flags = IFF_NOARP;
- dev->ml_priv= netdev_priv(dev);
+ can_set_ml_priv(dev, netdev_priv(dev));
/* set flags according to driver capabilities */
if (echo)
diff --git a/drivers/net/can/vxcan.c b/drivers/net/can/vxcan.c
index f9a524c5f6d6..8861a7d875e7 100644
--- a/drivers/net/can/vxcan.c
+++ b/drivers/net/can/vxcan.c
@@ -141,6 +141,8 @@ static const struct net_device_ops vxcan_netdev_ops = {
static void vxcan_setup(struct net_device *dev)
{
+ struct can_ml_priv *can_ml;
+
dev->type = ARPHRD_CAN;
dev->mtu= CANFD_MTU;
dev->hard_header_len= 0;
@@ -149,7 +151,9 @@ static void vxcan_setup(struct net_device *dev)
dev->flags = (IFF_NOARP|IFF_ECHO);
dev->netdev_ops = _netdev_ops;
dev->needs_free_netdev = true;
- dev->ml_priv= netdev_priv(dev) + ALIGN(sizeof(struct
vxcan_priv), NETDEV_ALIGN);
+
+ can_ml = netdev_priv(dev) + ALIGN(sizeof(struct vxcan_priv),
NETDEV_ALIGN);
+ can_set_ml_priv(dev, can_ml);
}
/* forward declaration for rtnl_create_link() */
diff --git a/include/linux/can/can-ml.h b/include/linux/can/can-ml.h
index 2f5d731ae251..8afa92d15a66 100644
--- a/include/linux/can/can-ml.h
+++ b/include/linux/can/can-ml.h
Re: [PATCH] arp: Remove the arp_hh_ops structure
Thank you for the clarification. On Tue, Feb 23, 2021 at 12:07 AM David Ahern wrote: > > On 2/22/21 1:37 AM, Eric Dumazet wrote: > > > > > > On 2/22/21 4:15 AM, Yejune Deng wrote: > >> The arp_hh_ops structure is similar to the arp_generic_ops structure. > >> but the latter is more general,so remove the arp_hh_ops structure. > >> > >> Fix when took out the neigh->ops assignment: > >> 8.973653] #PF: supervisor read access in kernel mode > >> [8.975027] #PF: error_code(0x) - not-present page > >> [8.976310] PGD 0 P4D 0 > >> [8.977036] Oops: [#1] SMP PTI > >> [8.977973] CPU: 1 PID: 210 Comm: sd-resolve Not tainted > >> 5.11.0-rc7-02046-g4591591ab715 #1 > >> [8.979998] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > >> 1.12.0-1 04/01/2014 > >> [8.981996] RIP: 0010:neigh_probe > >> (kbuild/src/consumer/net/core/neighbour.c:1009) > >> > > > > I have a hard time understanding this patch submission. > > > > This seems a mix of a net-next and net material ? > > It is net-next at best. > > > > > > > > >> Reported-by: kernel test robot > > > > If this is a bug fix, we want a Fixes: tag > > > > This will really help us. Please don't let us guess what is going on. > > > > This patch is a v2. v1 was clearly wrong and not tested; I responded as > such 12 hours before the robot test.
Re: [PATCH v2] memcg: charge before adding to swapcache on swapin
Hi Shakeel,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on next-20210222]
[cannot apply to linus/master hnaz-linux-mm/master v5.11 v5.11-rc7 v5.11-rc6
v5.11]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Shakeel-Butt/memcg-charge-before-adding-to-swapcache-on-swapin/20210223-135711
base:37dfbfbdca66834bc0f64ec9b35e09ac6c8898da
config: x86_64-randconfig-m031-20210223 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
#
https://github.com/0day-ci/linux/commit/7ad6fb47580886394809b563b7476954a35f3054
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Shakeel-Butt/memcg-charge-before-adding-to-swapcache-on-swapin/20210223-135711
git checkout 7ad6fb47580886394809b563b7476954a35f3054
# save the attached .config to linux build tree
make W=1 ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
In file included from include/linux/swap.h:9,
from include/linux/suspend.h:5,
from arch/x86/kernel/asm-offsets.c:13:
>> include/linux/memcontrol.h:1149:1: error: expected identifier or '(' before
>> '{' token
1149 | {
| ^
include/linux/memcontrol.h:1147:19: warning: 'mem_cgroup_charge_swapin_page'
declared 'static' but never defined [-Wunused-function]
1147 | static inline int mem_cgroup_charge_swapin_page(struct page *page,
| ^
--
In file included from include/linux/swap.h:9,
from include/linux/suspend.h:5,
from arch/x86/kernel/asm-offsets.c:13:
>> include/linux/memcontrol.h:1149:1: error: expected identifier or '(' before
>> '{' token
1149 | {
| ^
include/linux/memcontrol.h:1147:19: warning: 'mem_cgroup_charge_swapin_page'
declared 'static' but never defined [-Wunused-function]
1147 | static inline int mem_cgroup_charge_swapin_page(struct page *page,
| ^
make[2]: *** [scripts/Makefile.build:117: arch/x86/kernel/asm-offsets.s]
Error 1
make[2]: Target '__build' not remade because of errors.
make[1]: *** [Makefile:1228: prepare0] Error 2
make[1]: Target 'modules_prepare' not remade because of errors.
make: *** [Makefile:185: __sub-make] Error 2
make: Target 'modules_prepare' not remade because of errors.
--
In file included from include/linux/swap.h:9,
from include/linux/suspend.h:5,
from arch/x86/kernel/asm-offsets.c:13:
>> include/linux/memcontrol.h:1149:1: error: expected identifier or '(' before
>> '{' token
1149 | {
| ^
include/linux/memcontrol.h:1147:19: warning: 'mem_cgroup_charge_swapin_page'
declared 'static' but never defined [-Wunused-function]
1147 | static inline int mem_cgroup_charge_swapin_page(struct page *page,
| ^
make[2]: *** [scripts/Makefile.build:117: arch/x86/kernel/asm-offsets.s]
Error 1
make[2]: Target '__build' not remade because of errors.
make[1]: *** [Makefile:1228: prepare0] Error 2
make[1]: Target 'prepare' not remade because of errors.
make: *** [Makefile:185: __sub-make] Error 2
make: Target 'prepare' not remade because of errors.
vim +1149 include/linux/memcontrol.h
1146
1147 static inline int mem_cgroup_charge_swapin_page(struct page *page,
1148 struct mm_struct *mm, gfp_t gfp, swp_entry_t
entry);
> 1149 {
1150 return 0;
1151 }
1152
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH net v3] net: introduce CAN specific pointer in the struct net_device
Hi Jakub,
On Mon, Feb 22, 2021 at 05:30:12PM -0800, Jakub Kicinski wrote:
> On Mon, 22 Feb 2021 16:02:51 +0100 Oleksij Rempel wrote:
> > Since 20dd3850bcf8 ("can: Speed up CAN frame receiption by using
> > ml_priv") the CAN framework uses per device specific data in the AF_CAN
> > protocol. For this purpose the struct net_device->ml_priv is used. Later
> > the ml_priv usage in CAN was extended for other users, one of them being
> > CAN_J1939.
> >
> > Later in the kernel ml_priv was converted to an union, used by other
> > drivers. E.g. the tun driver started storing it's stats pointer.
> >
> > Since tun devices can claim to be a CAN device, CAN specific protocols
> > will wrongly interpret this pointer, which will cause system crashes.
> > Mostly this issue is visible in the CAN_J1939 stack.
> >
> > To fix this issue, we request a dedicated CAN pointer within the
> > net_device struct.
> >
> > Reported-by: syzbot+5138c4dd15a0401be...@syzkaller.appspotmail.com
> > Fixes: 20dd3850bcf8 ("can: Speed up CAN frame receiption by using ml_priv")
> > Fixes: ffd956eef69b ("can: introduce CAN midlayer private and allocate it
> > automatically")
> > Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
> > Fixes: 497a5757ce4e ("tun: switch to net core provided statistics counters")
> > Signed-off-by: Oleksij Rempel
>
> > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> > index ddf4cfc12615..6e25c6f0f190 100644
> > --- a/include/linux/netdevice.h
> > +++ b/include/linux/netdevice.h
> > @@ -1584,6 +1584,16 @@ enum netdev_priv_flags {
> > #define IFF_L3MDEV_RX_HANDLER IFF_L3MDEV_RX_HANDLER
> > #define IFF_LIVE_RENAME_OK IFF_LIVE_RENAME_OK
> >
> > +/**
> > + * enum netdev_ml_priv_type - net_device ml_priv_type
> > + *
> > + * This enum specifies the type of the struct net_device::ml_priv pointer.
> > + */
>
> kdoc (scripts/kernel-doc -none include/linux/netdevice.h) is not happy
> about the fact enum values are not defined. Perhaps they will be
> sufficiently self-explanatory to not bother documenting?
>
> Maybe just:
>
> /* Specifies the type of the struct net_device::ml_priv pointer */
>
> ?
sounds good, done.
> > +enum netdev_ml_priv_type {
> > + ML_PRIV_NONE,
> > + ML_PRIV_CAN,
> > +};
> > +
> > /**
> > * struct net_device - The DEVICE structure.
> > *
> > @@ -1779,6 +1789,7 @@ enum netdev_priv_flags {
> > * @nd_net:Network namespace this network device
> > is inside
> > *
> > * @ml_priv: Mid-layer private
> > + @ml_priv_type: Mid-layer private type
>
> missing '*' at the start of the line
done
> > * @lstats:Loopback statistics
> > * @tstats:Tunnel statistics
> > * @dstats:Dummy statistics
> > @@ -2094,8 +2105,10 @@ struct net_device {
> > possible_net_t nd_net;
> >
> > /* mid-layer private */
> > + void*ml_priv;
> > + enum netdev_ml_priv_typeml_priv_type;
> > +
> > union {
> > - void*ml_priv;
> > struct pcpu_lstats __percpu *lstats;
> > struct pcpu_sw_netstats __percpu*tstats;
> > struct pcpu_dstats __percpu *dstats;
> > @@ -2286,6 +2299,29 @@ static inline void netdev_reset_rx_headroom(struct
> > net_device *dev)
> > netdev_set_rx_headroom(dev, -1);
> > }
> >
> > +static inline void *netdev_get_ml_priv(struct net_device *dev,
> > + enum netdev_ml_priv_type type)
> > +{
> > + if (dev->ml_priv_type != type)
> > + return NULL;
> > +
> > + return dev->ml_priv;
> > +}
> > +
> > +static inline void netdev_set_ml_priv(struct net_device *dev,
> > + void *ml_priv,
> > + enum netdev_ml_priv_type type)
> > +{
> > + WARN_ONCE(dev->ml_priv_type && dev->ml_priv_type != type,
> > + "Overwriting already set ml_priv_type (%u) with different
> > ml_priv_type (%u)!\n",
> > + dev->ml_priv_type, type);
> > + WARN_ONCE(!dev->ml_priv_type && dev->ml_priv,
> > + "Overwriting already set ml_priv and ml_priv_type is
> > ML_PRIV_NONE!\n");
>
> nit: do we need the _ONCE() this helper should be used on control path
> and relatively rarely, no?
I have no strong opinion right now. Changed to WARN()
> > + dev->ml_priv = ml_priv;
> > + dev->ml_priv_type = type;
> > +}
> > +
> > /*
> > * Net namespace inlines
> > */
>
> > @@ -454,6 +455,7 @@ static int j1939_sk_bind(struct socket *sock, struct
> > sockaddr *uaddr, int len)
> > j1939_local_ecu_put(priv, jsk->addr.src_name, jsk->addr.sa);
> > } else {
> > struct net_device *ndev;
> > + struct can_ml_priv *can_ml;
>
> nit: rev xmas treei
done
>
> >
> > ndev = dev_get_by_index(net, addr->can_ifindex);
> >
Re: [PATCH 10/10] clocksource/drivers/hyper-v: Move handling of STIMER0 interrupts
On Wed, Jan 27, 2021 at 12:23:45PM -0800, Michael Kelley wrote:
> STIMER0 interrupts are most naturally modeled as per-cpu IRQs. But
> because x86/x64 doesn't have per-cpu IRQs, the core STIMER0 interrupt
> handling machinery is done in code under arch/x86 and Linux IRQs are
> not used. Adding support for ARM64 means adding equivalent code
> using per-cpu IRQs under arch/arm64.
>
> A better model is to treat per-cpu IRQs as the normal path (which it is
> for modern architectures), and the x86/x64 path as the exception. Do this
> by incorporating standard Linux per-cpu IRQ allocation into the main
> SITMER0 driver code, and bypass it in the x86/x64 exception case. For
> x86/x64, special case code is retained under arch/x86, but no STIMER0
> interrupt handling code is needed under arch/arm64.
>
> No functional change.
>
> Signed-off-by: Michael Kelley
> ---
> arch/x86/hyperv/hv_init.c | 2 +-
> arch/x86/include/asm/mshyperv.h| 4 -
> arch/x86/kernel/cpu/mshyperv.c | 10 +--
> drivers/clocksource/hyperv_timer.c | 170
> +
> include/asm-generic/mshyperv.h | 5 --
> include/clocksource/hyperv_timer.h | 3 +-
> 6 files changed, 123 insertions(+), 71 deletions(-)
>
> diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
> index 22e9557..fe37546 100644
> --- a/arch/x86/hyperv/hv_init.c
> +++ b/arch/x86/hyperv/hv_init.c
> @@ -371,7 +371,7 @@ void __init hyperv_init(void)
>* Ignore any errors in setting up stimer clockevents
>* as we can run with the LAPIC timer as a fallback.
>*/
> - (void)hv_stimer_alloc();
> + (void)hv_stimer_alloc(false);
>
> hv_apic_init();
>
> diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
> index 5ccbba8..941dd55 100644
> --- a/arch/x86/include/asm/mshyperv.h
> +++ b/arch/x86/include/asm/mshyperv.h
> @@ -31,10 +31,6 @@ static inline u64 hv_get_register(unsigned int reg)
>
> void hyperv_vector_handler(struct pt_regs *regs);
>
> -static inline void hv_enable_stimer0_percpu_irq(int irq) {}
> -static inline void hv_disable_stimer0_percpu_irq(int irq) {}
> -
> -
> #if IS_ENABLED(CONFIG_HYPERV)
> extern void *hv_hypercall_pg;
> extern void __percpu **hyperv_pcpu_input_arg;
> diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
> index 5679100a1..440507e 100644
> --- a/arch/x86/kernel/cpu/mshyperv.c
> +++ b/arch/x86/kernel/cpu/mshyperv.c
> @@ -85,21 +85,17 @@ void hv_remove_vmbus_handler(void)
> set_irq_regs(old_regs);
> }
>
> -int hv_setup_stimer0_irq(int *irq, int *vector, void (*handler)(void))
> +/* For x86/x64, override weak placeholders in hyperv_timer.c */
> +void hv_setup_stimer0_handler(void (*handler)(void))
> {
> - *vector = HYPERV_STIMER0_VECTOR;
> - *irq = -1; /* Unused on x86/x64 */
> hv_stimer0_handler = handler;
> - return 0;
> }
> -EXPORT_SYMBOL_GPL(hv_setup_stimer0_irq);
>
> -void hv_remove_stimer0_irq(int irq)
> +void hv_remove_stimer0_handler(void)
> {
> /* We have no way to deallocate the interrupt gate */
> hv_stimer0_handler = NULL;
> }
> -EXPORT_SYMBOL_GPL(hv_remove_stimer0_irq);
>
> void hv_setup_kexec_handler(void (*handler)(void))
> {
> diff --git a/drivers/clocksource/hyperv_timer.c
> b/drivers/clocksource/hyperv_timer.c
> index edf2d43..c553b8c 100644
> --- a/drivers/clocksource/hyperv_timer.c
> +++ b/drivers/clocksource/hyperv_timer.c
> @@ -18,6 +18,9 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> #include
> #include
> #include
> @@ -43,14 +46,13 @@
> */
> static bool direct_mode_enabled;
>
> -static int stimer0_irq;
> -static int stimer0_vector;
> +static int stimer0_irq = -1;
> +static long __percpu *stimer0_evt;
> static int stimer0_message_sint;
>
> /*
> - * ISR for when stimer0 is operating in Direct Mode. Direct Mode
> - * does not use VMbus or any VMbus messages, so process here and not
> - * in the VMbus driver code.
> + * Common code for stimer0 interrupts coming via Direct Mode or
> + * as a VMbus message.
> */
> void hv_stimer0_isr(void)
> {
> @@ -61,6 +63,16 @@ void hv_stimer0_isr(void)
> }
> EXPORT_SYMBOL_GPL(hv_stimer0_isr);
>
> +/*
> + * stimer0 interrupt handler for architectures that support
> + * per-cpu interrupts, which also implies Direct Mode.
> + */
> +static irqreturn_t hv_stimer0_percpu_isr(int irq, void *dev_id)
> +{
> + hv_stimer0_isr();
> + return IRQ_HANDLED;
> +}
> +
> static int hv_ce_set_next_event(unsigned long delta,
> struct clock_event_device *evt)
> {
> @@ -76,8 +88,8 @@ static int hv_ce_shutdown(struct clock_event_device *evt)
> {
> hv_set_register(HV_REGISTER_STIMER0_COUNT, 0);
> hv_set_register(HV_REGISTER_STIMER0_CONFIG, 0);
> - if (direct_mode_enabled)
> - hv_disable_stimer0_percpu_irq(stimer0_irq);
> + if (direct_mode_enabled && stimer0_irq >= 0)
> +
Re: [PATCH] sound: core: fixed coding style errors
Alright, I will resubmit the patch.
[PATCH] drivers: staging: wimax: fix code style issues
Fixes 'WARNING: Missing a blank line after declarations' generated by
checkpatch.pl script.
Signed-off-by: Hassan Shahbazi
---
drivers/staging/wimax/stack.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/wimax/stack.c b/drivers/staging/wimax/stack.c
index ace24a6dfd2d..0d0f6ab79bf5 100644
--- a/drivers/staging/wimax/stack.c
+++ b/drivers/staging/wimax/stack.c
@@ -156,6 +156,7 @@ int wimax_gnl_re_state_change_send(
{
int result = 0;
struct device *dev = wimax_dev_to_dev(wimax_dev);
+
d_fnstart(3, dev, "(wimax_dev %p report_skb %p)\n",
wimax_dev, report_skb);
if (report_skb == NULL) {
@@ -362,6 +363,7 @@ EXPORT_SYMBOL_GPL(wimax_state_change);
enum wimax_st wimax_state_get(struct wimax_dev *wimax_dev)
{
enum wimax_st state;
+
mutex_lock(_dev->mutex);
state = wimax_dev->state;
mutex_unlock(_dev->mutex);
--
2.26.2
Re: [PATCH] sound: core: fixed coding style errors
On Mon, 22 Feb 2021 20:41:56 +0100,
Rajesh Kumbhakar wrote:
>
> fixing ERROR: "foo * bar" should be "foo *bar"
> fixing WARNING: Missing a blank line after declarations
>
> Signed-off-by: Rajesh Kumbhakar
> ---
> sound/core/hwdep_compat.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/sound/core/hwdep_compat.c b/sound/core/hwdep_compat.c
> index a0b76706c..d8624a14a 100644
> --- a/sound/core/hwdep_compat.c
> +++ b/sound/core/hwdep_compat.c
> @@ -36,11 +36,13 @@ enum {
> SNDRV_HWDEP_IOCTL_DSP_LOAD32 = _IOW('H', 0x03, struct
> snd_hwdep_dsp_image32)
> };
>
> -static long snd_hwdep_ioctl_compat(struct file * file, unsigned int cmd,
> +static long snd_hwdep_ioctl_compat(struct file *file, unsigned int cmd,
> unsigned long arg)
> {
> struct snd_hwdep *hw = file->private_data;
> +
> void __user *argp = compat_ptr(arg);
You shouldn't put a blank line here.
thanks,
Takashi
Re: [PATCH 1/2] iio: core: use kfree_const in iio_free_chan_devattr_list() to free names
On Mon, Feb 22, 2021 at 6:06 PM Jonathan Cameron
wrote:
>
> On Fri, 19 Feb 2021 10:58:25 +0200
> Alexandru Ardelean wrote:
>
> > When the buffer attributes were wrapped in iio_dev_attr types, I forgot to
> > duplicate the names, so that when iio_free_chan_devattr_list() gets called
> > on cleanup, these get free'd.
> > I stumbled over this while accidentally breaking a driver doing
> > iio_device_register(), and then the issue appeared.
> >
> > The fix can be just
> > 1. Just use kstrdup() during iio_buffer_wrap_attr()
> > 2. Just use kfree_const() during iio_free_chan_devattr_list
> > 3. Use both kstrdup_const() & kfree_const() (in the places mentioned above)
> >
> > Using kfree_const() should be sufficient, as the attribute names will
> > either be allocated or be stored in rodata.
> >
> > Fixes: a1a11142f66c ("iio: buffer: wrap all buffer attributes into
> > iio_dev_attr")
> > Signed-off-by: Alexandru Ardelean
>
> Thinking more on this... It's fine for the users today, but there is
> nothing stopping a driver passing in names it allocated on the heap. So
> I think we should revisit this. Perhaps we need 1 or 3.
Ok.
Will re-send this as 3; that sounds like it gives the best of both worlds.
> > ---
> > drivers/iio/industrialio-core.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/iio/industrialio-core.c
> > b/drivers/iio/industrialio-core.c
> > index 0d8c6e88d993..cb2735d2ae4b 100644
> > --- a/drivers/iio/industrialio-core.c
> > +++ b/drivers/iio/industrialio-core.c
> > @@ -1358,7 +1358,7 @@ void iio_free_chan_devattr_list(struct list_head
> > *attr_list)
> > struct iio_dev_attr *p, *n;
> >
> > list_for_each_entry_safe(p, n, attr_list, l) {
> > - kfree(p->dev_attr.attr.name);
> > + kfree_const(p->dev_attr.attr.name);
> > list_del(>l);
> > kfree(p);
> > }
>
linux-next: Tree for Feb 23
Hi all, Please do not add any changes destined for v5.13 to your linux-next included branches until after v5.12-rc1 has been released. Changes since 20210222: The kbuild tree gained a conflict against Linus' tree and lost its build failure. The pci tree gained a conflict against Linus' tree. The amdgpu tree gained a build failure so I used the version from next-20210222. The block tree gained a build failure so I used the version from next-20210222. Non-merge commits (relative to Linus' tree): 2322 2565 files changed, 93612 insertions(+), 53208 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig and htmldocs. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 333 trees (counting Linus' and 87 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (7c70f3a7488d Merge tag 'nfsd-5.12-1' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux) Merging fixes/fixes (e71ba9452f0b Linux 5.11-rc2) Merging kbuild-current/fixes (fe968c41ac4f scripts: set proper OpenSSL include dir also for sign-file) Merging arc-current/for-curr (7c53f6b671f4 Linux 5.11-rc3) Merging arm-current/fixes (4d62e81b60d4 ARM: kexec: fix oops after TLB are invalidated) Merging arm64-fixes/for-next/fixes (2596b6ae412b kexec: move machine_kexec_post_load() to public interface) Merging arm-soc-fixes/arm/fixes (090e502e4e63 Merge tag 'socfpga_dts_fix_for_v5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux into arm/fixes) Merging drivers-memory-fixes/fixes (5c8fe583cce5 Linux 5.11-rc1) Merging m68k-current/for-linus (c396dd2ec5bb macintosh/adb-iop: Use big-endian autopoll mask) Merging powerpc-fixes/fixes (f40ddce88593 Linux 5.11) Merging s390-fixes/fixes (92bf22614b21 Linux 5.11-rc7) Merging sparc/master (356184fb6d67 sparc: make xchg() into a statement expression) CONFLICT (content): Merge conflict in arch/sparc/Kconfig Merging fscrypt-current/for-stable (d19d8d345eec fscrypt: fix inline encryption not used on new files) Merging net/master (3a2eb515d136 octeontx2-af: Fix an off by one in rvu_dbg_qsize_write()) Merging bpf/master (53f523f3052a bpf: Clear percpu pointers in bpf_prog_clone_free()) Merging ipsec/master (3a2eb515d136 octeontx2-af: Fix an off by one in rvu_dbg_qsize_write()) Merging netfilter/master (3af409ca278d net: enetc: fix destroyed phylink dereference during unbind) Merging ipvs/master (44a674d6f798 Merge tag 'mlx5-fixes-2021-01-26' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux) Merging wireless-drivers/master (4538c5ed0f7e iwlwifi: avoid crash on unsupported debug collection) Merging mac80211/master (3af409ca278d net: enetc: fix destroyed phylink dereference during unbind) Merging rdma-fixes/for-rc (1048ba83fb1c Linux 5.11-rc6) Merging sound-current/for-linus (c4294d7f057d ALSA: hda: intel-dsp-config: add Alder Lake support) Merging sound-asoc-fixes/for-linus (ceae5d20f386 Merge remote-tracking branch 'asoc/for-5.12' into asoc-linus) Merging regmap-fixes/for-linus (19c329f68089 Linux 5.11-rc4) Merging regulator-fixes/for-linus (e124039e9567 Merge remote-tracking branch 'regulator/for-5.12' into regulator-linus) Merging spi-fixes/for-linus (ecce3daec27a Merge remote-tracking branch 'spi/for-5.12' into spi-linus) Merging pci-current/for-linus (7e69d07d7c3c Revert "PCI/ASPM: Save/restore L1SS Capa
Re: [PATCH v3 6/6] iio: buffer-dma: add support for cyclic DMA transfers
On Sun, Feb 21, 2021 at 2:11 PM Jonathan Cameron wrote:
>
> On Fri, 19 Feb 2021 14:40:12 +0200
> Alexandru Ardelean wrote:
>
> > From: Lars-Peter Clausen
> >
> > This change adds support for cyclic DMA transfers using the IIO buffer DMA
> > infrastructure.
> > To do this, userspace must set the IIO_BUFFER_BLOCK_FLAG_CYCLIC flag on the
> > block when enqueueing them via the ENQUEUE_BLOCK ioctl().
> >
> > Signed-off-by: Lars-Peter Clausen
> > Signed-off-by: Alexandru Ardelean
> Series in general looks good to me, but this change needs a little more
> detail + probably some level of example userspace flow.
>
> I don't really understand how this is used!
>
> Also, it's easy to test output buffers with the kfifo support so we
> should be able to move forward quickly with that part (1-3, 4 is probably
> fine as well as clearly harmless).
>
> The dma stuff worries me more, at least partly based on the experience
> of the original dma buffers which basically sat their unused (in upstream)
> for a very long time. So to move these forward, they need to come
> with users...
So, this series will need to be re-sent/re-tested by someone else.
I'm on my last week at ADI and I'm on vacation.
Maybe I can manage to setup something to test as well, but it will take a while.
>
> Thanks,
>
> Jonathan
>
> > ---
> > .../buffer/industrialio-buffer-dmaengine.c| 24 ---
> > include/uapi/linux/iio/buffer.h | 1 +
> > 2 files changed, 17 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> > b/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> > index 65458a6cc81a..39cc230c7991 100644
> > --- a/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> > +++ b/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> > @@ -82,14 +82,22 @@ static int iio_dmaengine_buffer_submit_block(struct
> > iio_dma_buffer_queue *queue,
> >
> > direction = dmaengine_buffer->is_tx ? DMA_MEM_TO_DEV : DMA_DEV_TO_MEM;
> >
> > - desc = dmaengine_prep_slave_single(dmaengine_buffer->chan,
> > - block->phys_addr, block->block.bytes_used, direction,
> > - DMA_PREP_INTERRUPT);
> > - if (!desc)
> > - return -ENOMEM;
> > -
> > - desc->callback_result = iio_dmaengine_buffer_block_done;
> > - desc->callback_param = block;
> > + if (block->block.flags & IIO_BUFFER_BLOCK_FLAG_CYCLIC) {
> > + desc = dmaengine_prep_dma_cyclic(dmaengine_buffer->chan,
> > + block->phys_addr, block->block.bytes_used,
> > + block->block.bytes_used, direction, 0);
> > + if (!desc)
> > + return -ENOMEM;
> > + } else {
> > + desc = dmaengine_prep_slave_single(dmaengine_buffer->chan,
> > + block->phys_addr, block->block.bytes_used, direction,
> > + DMA_PREP_INTERRUPT);
> > + if (!desc)
> > + return -ENOMEM;
> > +
> > + desc->callback_result = iio_dmaengine_buffer_block_done;
> > + desc->callback_param = block;
> > + }
> >
> > cookie = dmaengine_submit(desc);
> > if (dma_submit_error(cookie))
> > diff --git a/include/uapi/linux/iio/buffer.h
> > b/include/uapi/linux/iio/buffer.h
> > index 4e4ee9befea1..1bde508fe1b9 100644
> > --- a/include/uapi/linux/iio/buffer.h
> > +++ b/include/uapi/linux/iio/buffer.h
> > @@ -33,6 +33,7 @@ struct iio_buffer_block_alloc_req {
> >
> > /* A function will be assigned later for BIT(0) */
> > #define IIO_BUFFER_BLOCK_FLAG_RESERVED (1 << 0)
> > +#define IIO_BUFFER_BLOCK_FLAG_CYCLIC (1 << 1)
> >
> > /**
> > * struct iio_buffer_block - Descriptor for a single IIO block
>
Re: [PATCH] f2fs: compress: Allow modular (de)compression algorithms
On Mon, Feb 22, 2021 at 9:59 PM Geert Uytterhoeven wrote:
>
> If F2FS_FS is modular, enabling the compressions options
> F2FS_FS_{LZ4,LZ4HZ,LZO,LZORLE,ZSTD} will make the (de)compression
> algorithms {LZ4,LZ4HC,LZO,ZSTD}_{,DE}COMPRESS builtin instead of
> modular, as the former depend on an intermediate boolean
> F2FS_FS_COMPRESSION, which in-turn depends on tristate F2FS_FS.
>
> Indeed, if a boolean symbol A depends directly on a tristate symbol B
> and selects another tristate symbol C:
>
> tristate B
>
> tristate C
>
> bool A
> depends on B
> select C
>
> and B is modular, then C will also be modular.
>
> However, if there is an intermediate boolean D in the dependency chain
> between A and B:
>
> tristate B
>
> tristate C
>
> bool D
> depends on B
>
> bool A
> depends on D
> select C
>
> then the modular state won't propagate from B to C, and C will be
> builtin instead of modular.
>
> Fix this by making the various compression options depend directly on
> F2FS_FS using a big if/endif block. Drop the now superfluous
> dependencies on F2FS_FS from individual symbols.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> Perhaps the propagation logic in Kconfig should be fixed instead?
> Else people may reintroduce this issue when removing seemingly-unneeded
> dependencies.
I checked the code in menu_finalize(), and this seems to work like this.
I discussed the oddity of the select behavior before
(https://lore.kernel.org/linux-kbuild/e1a6228d-1341-6264-d97a-e2bd52a65...@infradead.org/),
but I was not confident about what the right direction was.
Anyway, the behavior is obscure from the current code.
If you want to make this more robust,
you can write as follows:
config F2FS_FS
tristate "F2FS filesystem support"
depends on BLOCK
select NLS
select CRYPTO
select CRYPTO_CRC32
select F2FS_FS_XATTR if FS_ENCRYPTION
select FS_ENCRYPTION_ALGS if FS_ENCRYPTION
select LZO_COMPRESS if F2FS_FS_LZO
select LZO_DECOMPRESS if F2FS_FS_LZO
select LZ4_COMPRESS if F2FS_FS_LZ4
select LZ4_DECOMPRESS if F2FS_FS_LZ4
select LZ4HC_COMPRESS if F2FS_FS_LZ4HC
select ZSTD_COMPRESS if F2FS_FS_ZSTD
select ZSTD_DECOMPRESS if F2FS_FS_ZSTD
The code is a bit clumsy, but it is clear
that the module (F2FS_FS) is selecting the
compress/decompress libraries.
> ---
> fs/f2fs/Kconfig | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/fs/f2fs/Kconfig b/fs/f2fs/Kconfig
> index 62e638a49bbf089a..20a82ecb72b42f84 100644
> --- a/fs/f2fs/Kconfig
> +++ b/fs/f2fs/Kconfig
> @@ -20,9 +20,10 @@ config F2FS_FS
>
> If unsure, say N.
>
> +if F2FS_FS
> +
> config F2FS_STAT_FS
> bool "F2FS Status Information"
> - depends on F2FS_FS
> default y
> help
> /sys/kernel/debug/f2fs/ contains information about all the
> partitions
> @@ -35,7 +36,6 @@ config F2FS_STAT_FS
>
> config F2FS_FS_XATTR
> bool "F2FS extended attributes"
> - depends on F2FS_FS
> default y
> help
> Extended attributes are name:value pairs associated with inodes by
> @@ -70,7 +70,6 @@ config F2FS_FS_SECURITY
>
> config F2FS_CHECK_FS
> bool "F2FS consistency checking feature"
> - depends on F2FS_FS
> help
> Enables BUG_ONs which check the filesystem consistency in runtime.
>
> @@ -78,7 +77,6 @@ config F2FS_CHECK_FS
>
> config F2FS_FAULT_INJECTION
> bool "F2FS fault injection facility"
> - depends on F2FS_FS
> help
> Test F2FS to inject faults such as ENOMEM, ENOSPC, and so on.
>
> @@ -86,7 +84,6 @@ config F2FS_FAULT_INJECTION
>
> config F2FS_FS_COMPRESSION
> bool "F2FS compression feature"
> - depends on F2FS_FS
> help
> Enable filesystem-level compression on f2fs regular files,
> multiple back-end compression algorithms are supported.
> @@ -137,3 +134,5 @@ config F2FS_FS_LZORLE
> default y
> help
> Support LZO-RLE compress algorithm, if unsure, say Y.
> +
> +endif
> --
> 2.25.1
>
--
Best Regards
Masahiro Yamada
Re: [REGRESSION] "add a disk_uevent helper" breaks booting Andorid w/ dynamic partitions
Please try the patch below:
---
>From 85943345b41ec04f5a9e92dfad85b0fb24e2d2eb Mon Sep 17 00:00:00 2001
From: Christoph Hellwig
Date: Tue, 23 Feb 2021 07:28:22 +0100
Subject: block: don't skip empty device in in disk_uevent
Restore the previous behavior by using the correct flag for the whole device
("part0").
Fixes: 99dfc43ecbf6 ("block: use ->bi_bdev for bio based I/O accounting")
Reported-by: John Stultz
Signed-off-by: Christoph Hellwig
---
block/genhd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/genhd.c b/block/genhd.c
index dbb92e24ef65ed..fcc530164b5ab4 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -476,7 +476,7 @@ void disk_uevent(struct gendisk *disk, enum kobject_action
action)
struct disk_part_iter piter;
struct block_device *part;
- disk_part_iter_init(, disk, DISK_PITER_INCL_PART0);
+ disk_part_iter_init(, disk, DISK_PITER_INCL_EMPTY_PART0);
while ((part = disk_part_iter_next()))
kobject_uevent(bdev_kobj(part), action);
disk_part_iter_exit();
--
2.29.2
Re: [PATCH] kunit: tool: Fix a python tuple typing error
On Mon, Feb 22, 2021 at 9:49 PM 'David Gow' via KUnit Development
wrote:
>
> The first argument to namedtuple() should match the name of the type,
> which wasn't the case for KconfigEntryBase.
>
> Fixing this is enough to make mypy show no python typing errors again.
Ah, this is something apparently only newer versions of mypy detect.
On 0.782 I didn't see it, but after pip install --upgrade to 0.812, I
see the error.
While I'm here, I also upgraded my pytype install and checked.
It's happy w/ or w/o this patch.
So while this is in some sense an error only mypy cares about, this
fix does make the code more stylistically correct and should
definitely go in.
>
> Fixes 97752c39bd ("kunit: kunit_tool: Allow .kunitconfig to disable config
> items")
> Signed-off-by: David Gow
Reviewed-by: Daniel Latypov
> ---
> tools/testing/kunit/kunit_config.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/testing/kunit/kunit_config.py
> b/tools/testing/kunit/kunit_config.py
> index 0b550cbd667d..1e2683dcc0e7 100644
> --- a/tools/testing/kunit/kunit_config.py
> +++ b/tools/testing/kunit/kunit_config.py
> @@ -13,7 +13,7 @@ from typing import List, Set
> CONFIG_IS_NOT_SET_PATTERN = r'^# CONFIG_(\w+) is not set$'
> CONFIG_PATTERN = r'^CONFIG_(\w+)=(\S+|".*")$'
>
> -KconfigEntryBase = collections.namedtuple('KconfigEntry', ['name', 'value'])
> +KconfigEntryBase = collections.namedtuple('KconfigEntryBase', ['name',
> 'value'])
>
> class KconfigEntry(KconfigEntryBase):
>
> --
> 2.30.0.617.g56c4b15f3c-goog
>
> --
> You received this message because you are subscribed to the Google Groups
> "KUnit Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kunit-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/kunit-dev/20210223054930.234-1-davidgow%40google.com.
Re: [PATCH v4 bpf-next 5/6] bpf: runqslower: prefer using local vmlimux to generate vmlinux.h
On Mon, Feb 22, 2021 at 5:24 PM Song Liu wrote: > > Update the Makefile to prefer using $(O)/mvlinux, $(KBUILD_OUTPUT)/vmlinux > (for selftests) or ../../../vmlinux. These two files should have latest > definitions for vmlinux.h. > > Signed-off-by: Song Liu > --- Acked-by: Andrii Nakryiko > tools/bpf/runqslower/Makefile | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/tools/bpf/runqslower/Makefile b/tools/bpf/runqslower/Makefile > index 9d9fb6209be1b..c96ba90c6f018 100644 > --- a/tools/bpf/runqslower/Makefile > +++ b/tools/bpf/runqslower/Makefile > @@ -16,7 +16,10 @@ CFLAGS := -g -Wall > > # Try to detect best kernel BTF source > KERNEL_REL := $(shell uname -r) > -VMLINUX_BTF_PATHS := /sys/kernel/btf/vmlinux /boot/vmlinux-$(KERNEL_REL) > +VMLINUX_BTF_PATHS := $(if $(O),$(O)/vmlinux) \ > + $(if $(KBUILD_OUTPUT),$(KBUILD_OUTPUT)/vmlinux) \ > + ../../../vmlinux /sys/kernel/btf/vmlinux\ > + /boot/vmlinux-$(KERNEL_REL) > VMLINUX_BTF_PATH := $(or $(VMLINUX_BTF),$(firstword > \ > $(wildcard $(VMLINUX_BTF_PATHS > > -- > 2.24.1 >
[PATCH] perf tools: check perf_event_paranoid and kptr_restrict on 'perf top'
Perf top will segfault, we should give prompt information like perf
record instead of crashing directly.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Mark Rutland
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Namhyung Kim
Signed-off-by: Jackie Liu
---
tools/perf/builtin-top.c | 8
1 file changed, 8 insertions(+)
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 3673c04d16b6..b257fadba3bd 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -1239,6 +1239,14 @@ static int __cmd_top(struct perf_top *top)
return ret;
}
+ if (symbol_conf.kptr_restrict && !evlist__exclude_kernel(top->evlist)) {
+ pr_warning(
+"Kernel address maps (/proc/{kallsyms,modules}) are restricted.\n\n"
+"Check /proc/sys/kernel/kptr_restrict and
/proc/sys/kernel/perf_event_paranoid.\n\n"
+"Kernel samples will not be resolved.\n");
+ return -1;
+ }
+
ret = callchain_param__setup_sample_type(_param);
if (ret)
return ret;
--
2.25.1
[PATCH] selftests: timers: remove unneeded semicolon
Fix the following coccicheck warnings: ./tools/testing/selftests/timers/alarmtimer-suspend.c:82:2-3: Unneeded semicolon. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- tools/testing/selftests/timers/alarmtimer-suspend.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/timers/alarmtimer-suspend.c b/tools/testing/selftests/timers/alarmtimer-suspend.c index 4da09db..54da4b08 100644 --- a/tools/testing/selftests/timers/alarmtimer-suspend.c +++ b/tools/testing/selftests/timers/alarmtimer-suspend.c @@ -79,7 +79,7 @@ char *clockstring(int clockid) return "CLOCK_BOOTTIME_ALARM"; case CLOCK_TAI: return "CLOCK_TAI"; - }; + } return "UNKNOWN_CLOCKID"; } -- 1.8.3.1
Re: [PATCH v4 bpf-next 2/6] bpf: prevent deadlock from recursive bpf_task_storage_[get|delete]
On Mon, Feb 22, 2021 at 5:23 PM Song Liu wrote: > > BPF helpers bpf_task_storage_[get|delete] could hold two locks: > bpf_local_storage_map_bucket->lock and bpf_local_storage->lock. Calling > these helpers from fentry/fexit programs on functions in bpf_*_storage.c > may cause deadlock on either locks. > > Prevent such deadlock with a per cpu counter, bpf_task_storage_busy, which > is similar to bpf_prog_active. We need this counter to be global, because > the two locks here belong to two different objects: bpf_local_storage_map > and bpf_local_storage. If we pick one of them as the owner of the counter, > it is still possible to trigger deadlock on the other lock. For example, > if bpf_local_storage_map owns the counters, it cannot prevent deadlock > on bpf_local_storage->lock when two maps are used. > > Signed-off-by: Song Liu > --- > kernel/bpf/bpf_task_storage.c | 57 ++- > 1 file changed, 50 insertions(+), 7 deletions(-) > [...] > @@ -109,7 +136,9 @@ static void *bpf_pid_task_storage_lookup_elem(struct > bpf_map *map, void *key) > goto out; > } > > + bpf_task_storage_lock(); > sdata = task_storage_lookup(task, map, true); > + bpf_task_storage_unlock(); > put_pid(pid); > return sdata ? sdata->data : NULL; > out: > @@ -141,8 +170,10 @@ static int bpf_pid_task_storage_update_elem(struct > bpf_map *map, void *key, > goto out; > } > > + bpf_task_storage_lock(); > sdata = bpf_local_storage_update( > task, (struct bpf_local_storage_map *)map, value, map_flags); this should probably be container_of() instead of casting > + bpf_task_storage_unlock(); > > err = PTR_ERR_OR_ZERO(sdata); > out: > @@ -185,7 +216,9 @@ static int bpf_pid_task_storage_delete_elem(struct > bpf_map *map, void *key) > goto out; > } > > + bpf_task_storage_lock(); > err = task_storage_delete(task, map); > + bpf_task_storage_unlock(); > out: > put_pid(pid); > return err; [...]
Re: [PATCH v3 1/1] security: Add CONFIG_LSM_AUTO to handle default LSM stack ordering
On Mon, Feb 22, 2021 at 11:46 PM Casey Schaufler wrote: > > > On 2/22/2021 1:12 PM, Nicolas Iooss wrote: > > On Mon, Feb 22, 2021 at 9:32 PM Casey Schaufler > > wrote: > >> On 2/22/2021 10:31 AM, Mickaël Salaün wrote: > >>> On 22/02/2021 17:51, Casey Schaufler wrote: > On 2/22/2021 7:06 AM, Mickaël Salaün wrote: > > From: Mickaël Salaün > > > > Add a new option CONFIG_LSM_AUTO to enable users to delegate default LSM > > stacking order to kernel developers. This enable to keep a consistent > > order of enabled LSM when changing the LSM selection, especially when a > > new LSM is added to the kernel. > TL;DR - NAK > > Do you think that we might have considered this when stacking was > introduced? > >>> I didn't dig the detailed history of LSM stacking, but you are in Cc > >>> because I know that you know. I may have though that the main goal of > >>> the current LSM stacking implementation was to enable to stack existing > >>> LSMs, which works well with this CONFIG_LSM list, but doesn't work as > >>> well for new LSMs. > >> It works just fine for new LSMs if you treat them as significant > >> features which may have significant impact on the behavior of the > >> system. > >> > Did you even consider the implications before sending > the patch? > >>> Yes, and it doesn't change much the current behavior without user > >>> interaction. However, it gives the choice to users to choose how they > >>> want their configuration to evolve. > >> Automatic inclusions of new LSMs would be counter to existing practice. > >> It won't work for "major" LSMs. > >> > >> > This only makes any sense if you want to compile in > AppArmor and/or Smack but always use SELinux. The existing Kconfig > model handles that perfectly well. > >>> This patch series doesn't change this behavior if the user doesn't want > >>> it to change. > >> Well, there's the question. If a distribution/system uses the new scheme > >> "users" are going to get new LSMs spontaniously. If they don't it's up to > >> the "user". Unsophisticated users won't want this, and the others don't > >> need it. > > Hello, sorry if I missed something simple but I did not understand > > what "Automatic inclusions of new LSMs " and "get new LSMs > > spontaniously" is about. If I understood the kernel practice > > development correctly, when a new LSM will be included, it will have a > > dedicated "config SECURITY_MYNEWLSM" which will be default to "n" in > > order to respect the "principle of least astonishment". How could such > > a new LSM be automatically/spontaneously added to the LSM list? > > It wouldn't. But compiling the new LSM mynewlsm doesn't add it to > the list, either. Today no one should expect a LSM to be active if > it hasn't been added to the CONFIG_LSM list. The proposed addition > of CONFIG_LSM_AUTO would change that. "make oldconfig" would add > security modules that are built to the list. This is unnecessary > since whoever changed CONFIG_SECURITY_MYNEWLSM to "y" could easily > have added it to CONFIG_LSM. In the right place. > > > I understand that this is a tough issue and that the subject might > > have been discussed a few years ago, and if that's the case, it would > > be nice to have pointers to some clear documentation or past emails > > (and it would be very very nice if the kernel documentation was > > updated to document the current state of LSM stacking: > > I'm not going to argue against that. > > > for example > > https://www.kernel.org/doc/html/v5.11/admin-guide/LSM/index.html still > > documents the "security=" kernel parameter even though it conflicts > > with CONFIG_LSM and can be ignored by the kernel in practise). > > You can still select one "major" module using security= if you > don't use lsm= to specify a full list. We put real effort into > being backward compatible. No, this is not true. If CONFIG_LSM is defined to "lockdown,yama,bpf" and if the kernel command line contains "security=selinux" without any "lsm" parameter, then SELinux is not enabled properly. This broke the configuration of several Arch Linux users (cf. https://bbs.archlinux.org/viewtopic.php?id=263360 and https://github.com/archlinuxhardened/selinux/issues/81) and I reported this on some kernel mailing lists a few days ago (https://lore.kernel.org/linux-security-module/CAJfZ7=nwjisw2rrw2avfgpykqk_pghudebqitqxnfeds2id...@mail.gmail.com/). Your answer to this issue was very clear (and thank you for explaining this): « You can't (currently) use SELinux and BPF at the same time. This is because the infrastructure does not support multiple secid<->secctx translation hooks. You get the first one in the list. BPF provides all hooks, so the SELinux hooks aren't reached and the secid to secctx translation fails in the "bpf,selinux" case. » Anyway, this means that using "security=..." does not work if CONFIG_LSM contains the BPF LSM module, so no: you *cannot* select one major module
[PATCH 7/8] ARM: mstar: Add OPP table for infinity3
The infinity3 has a slightly higher max frequency
compared to the infinity so extend the OPP table.
Co-authored-by: Willy Tarreau
Signed-off-by: Daniel Palmer
---
arch/arm/boot/dts/mstar-infinity3.dtsi | 58 ++
1 file changed, 58 insertions(+)
diff --git a/arch/arm/boot/dts/mstar-infinity3.dtsi
b/arch/arm/boot/dts/mstar-infinity3.dtsi
index 9857e2a9934d..a56cf29e5d82 100644
--- a/arch/arm/boot/dts/mstar-infinity3.dtsi
+++ b/arch/arm/boot/dts/mstar-infinity3.dtsi
@@ -6,6 +6,64 @@
#include "mstar-infinity.dtsi"
+_opp_table {
+ opp-100800 {
+ opp-hz = /bits/ 64 <100800>;
+ opp-microvolt = <100>;
+ clock-latency-ns = <30>;
+ };
+
+ // overclock frequencies below, shown to work fine up to 1.3 GHz
+ opp-10800 {
+ opp-hz = /bits/ 64 <108000>;
+ opp-microvolt = <100>;
+ clock-latency-ns = <30>;
+ turbo-mode;
+ };
+
+ opp-118800 {
+ opp-hz = /bits/ 64 <118800>;
+ opp-microvolt = <100>;
+ clock-latency-ns = <30>;
+ turbo-mode;
+ };
+
+ opp-129600 {
+ opp-hz = /bits/ 64 <129600>;
+ opp-microvolt = <100>;
+ clock-latency-ns = <30>;
+ turbo-mode;
+ };
+
+ opp-135000 {
+ opp-hz = /bits/ 64 <135000>;
+ opp-microvolt = <100>;
+ clock-latency-ns = <30>;
+ turbo-mode;
+ };
+
+ opp-140400 {
+ opp-hz = /bits/ 64 <140400>;
+ opp-microvolt = <100>;
+ clock-latency-ns = <30>;
+ turbo-mode;
+ };
+
+ opp-145800 {
+ opp-hz = /bits/ 64 <145800>;
+ opp-microvolt = <100>;
+ clock-latency-ns = <30>;
+ turbo-mode;
+ };
+
+ opp-151200 {
+ opp-hz = /bits/ 64 <151200>;
+ opp-microvolt = <100>;
+ clock-latency-ns = <30>;
+ turbo-mode;
+ };
+};
+
{
reg = <0xa000 0x2>;
};
--
2.30.0.rc2
[PATCH 6/8] ARM: mstar: Add OPP table for infinity
Add an OPP table for the inifinity chips so
that cpu frequency scaling can happen.
Co-authored-by: Willy Tarreau
Signed-off-by: Daniel Palmer
---
arch/arm/boot/dts/mstar-infinity.dtsi | 34 +++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/mstar-infinity.dtsi
b/arch/arm/boot/dts/mstar-infinity.dtsi
index 0bee517797f4..441a917b88ba 100644
--- a/arch/arm/boot/dts/mstar-infinity.dtsi
+++ b/arch/arm/boot/dts/mstar-infinity.dtsi
@@ -8,6 +8,40 @@
#include
+/ {
+ cpu0_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp-24000 {
+ opp-hz = /bits/ 64 <24000>;
+ opp-microvolt = <100>;
+ clock-latency-ns = <30>;
+ };
+
+ opp-4 {
+ opp-hz = /bits/ 64 <4>;
+ opp-microvolt = <100>;
+ clock-latency-ns = <30>;
+ };
+ opp-6 {
+ opp-hz = /bits/ 64 <6>;
+ opp-microvolt = <100>;
+ clock-latency-ns = <30>;
+ };
+
+ opp-8 {
+ opp-hz = /bits/ 64 <8>;
+ opp-microvolt = <100>;
+ clock-latency-ns = <30>;
+ };
+ };
+};
+
+ {
+ operating-points-v2 = <_opp_table>;
+};
+
{
reg = <0xa000 0x16000>;
};
--
2.30.0.rc2
[PATCH 8/8] ARM: mstar: Add OPP table for mercury5
Add an OPP table for mercury5 so that cpu frequency scaling can
happen.
Signed-off-by: Daniel Palmer
---
arch/arm/boot/dts/mstar-mercury5.dtsi | 36 +++
1 file changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/mstar-mercury5.dtsi
b/arch/arm/boot/dts/mstar-mercury5.dtsi
index a7d0dd9d6132..80a19bd23c9c 100644
--- a/arch/arm/boot/dts/mstar-mercury5.dtsi
+++ b/arch/arm/boot/dts/mstar-mercury5.dtsi
@@ -6,6 +6,42 @@
#include "mstar-v7.dtsi"
+/ {
+ cpu0_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp-1 {
+ opp-hz = /bits/ 64 <1>;
+ opp-microvolt = <80 80 85>;
+ clock-latency-ns = <30>;
+ };
+
+ opp-2 {
+ opp-hz = /bits/ 64 <2>;
+ opp-microvolt = <85 85 88>;
+ clock-latency-ns = <30>;
+ };
+
+ opp-4 {
+ opp-hz = /bits/ 64 <4>;
+ opp-microvolt = <88 88 89>;
+ clock-latency-ns = <30>;
+ };
+ opp-6 {
+ opp-hz = /bits/ 64 <6>;
+ opp-microvolt = <90 90 100>;
+ clock-latency-ns = <30>;
+ };
+
+ opp-8 {
+ opp-hz = /bits/ 64 <8>;
+ opp-microvolt = <90 90 100>;
+ clock-latency-ns = <30>;
+ };
+ };
+};
+
{
reg = <0xa000 0x2>;
};
--
2.30.0.rc2
[PATCH 5/8] ARM: mstar: Link cpupll to second core
The second core also sources it's clock from the CPU PLL.
Signed-off-by: Daniel Palmer
---
arch/arm/boot/dts/mstar-infinity2m.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/mstar-infinity2m.dtsi
b/arch/arm/boot/dts/mstar-infinity2m.dtsi
index 6d4d1d224e96..dc339cd29778 100644
--- a/arch/arm/boot/dts/mstar-infinity2m.dtsi
+++ b/arch/arm/boot/dts/mstar-infinity2m.dtsi
@@ -11,6 +11,8 @@ cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x1>;
+ clocks = <>;
+ clock-names = "cpuclk";
};
};
--
2.30.0.rc2
[PATCH V4 3/3] vdpa: introduce virtio pci driver
This patch introduce a vDPA driver for virtio-pci device. It bridges
the virtio-pci control command to the vDPA bus. This will be used for
features prototyping and testing.
Note that get/restore virtqueue state is not supported which needs
extension on the virtio specification.
Signed-off-by: Jason Wang
---
drivers/vdpa/Kconfig | 7 +
drivers/vdpa/Makefile | 1 +
drivers/vdpa/virtio_pci/Makefile | 2 +
drivers/vdpa/virtio_pci/vp_vdpa.c | 458 ++
4 files changed, 468 insertions(+)
create mode 100644 drivers/vdpa/virtio_pci/Makefile
create mode 100644 drivers/vdpa/virtio_pci/vp_vdpa.c
diff --git a/drivers/vdpa/Kconfig b/drivers/vdpa/Kconfig
index ffd1e098bfd2..a245809c99d0 100644
--- a/drivers/vdpa/Kconfig
+++ b/drivers/vdpa/Kconfig
@@ -52,4 +52,11 @@ config MLX5_VDPA_NET
be executed by the hardware. It also supports a variety of stateless
offloads depending on the actual device used and firmware version.
+config VP_VDPA
+ tristate "Virtio PCI bridge vDPA driver"
+ select VIRTIO_PCI_LIB
+ depends on PCI_MSI
+ help
+ This kernel module bridges virtio PCI device to vDPA bus.
+
endif # VDPA
diff --git a/drivers/vdpa/Makefile b/drivers/vdpa/Makefile
index d160e9b63a66..67fe7f3d6943 100644
--- a/drivers/vdpa/Makefile
+++ b/drivers/vdpa/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_VDPA) += vdpa.o
obj-$(CONFIG_VDPA_SIM) += vdpa_sim/
obj-$(CONFIG_IFCVF)+= ifcvf/
obj-$(CONFIG_MLX5_VDPA) += mlx5/
+obj-$(CONFIG_VP_VDPA)+= virtio_pci/
diff --git a/drivers/vdpa/virtio_pci/Makefile b/drivers/vdpa/virtio_pci/Makefile
new file mode 100644
index ..231088d3af7d
--- /dev/null
+++ b/drivers/vdpa/virtio_pci/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_VP_VDPA) += vp_vdpa.o
diff --git a/drivers/vdpa/virtio_pci/vp_vdpa.c
b/drivers/vdpa/virtio_pci/vp_vdpa.c
new file mode 100644
index ..1321a2fcd088
--- /dev/null
+++ b/drivers/vdpa/virtio_pci/vp_vdpa.c
@@ -0,0 +1,458 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * vDPA bridge driver for modern virtio-pci device
+ *
+ * Copyright (c) 2020, Red Hat Inc. All rights reserved.
+ * Author: Jason Wang
+ *
+ * Based on virtio_pci_modern.c.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define VP_VDPA_QUEUE_MAX 256
+#define VP_VDPA_DRIVER_NAME "vp_vdpa"
+#define VP_VDPA_NAME_SIZE 256
+
+struct vp_vring {
+ void __iomem *notify;
+ char msix_name[VP_VDPA_NAME_SIZE];
+ struct vdpa_callback cb;
+ int irq;
+};
+
+struct vp_vdpa {
+ struct vdpa_device vdpa;
+ struct virtio_pci_modern_device mdev;
+ struct vp_vring *vring;
+ struct vdpa_callback config_cb;
+ char msix_name[VP_VDPA_NAME_SIZE];
+ int config_irq;
+ int queues;
+ int vectors;
+};
+
+static struct vp_vdpa *vdpa_to_vp(struct vdpa_device *vdpa)
+{
+ return container_of(vdpa, struct vp_vdpa, vdpa);
+}
+
+static struct virtio_pci_modern_device *vdpa_to_mdev(struct vdpa_device *vdpa)
+{
+ struct vp_vdpa *vp_vdpa = vdpa_to_vp(vdpa);
+
+ return _vdpa->mdev;
+}
+
+static u64 vp_vdpa_get_features(struct vdpa_device *vdpa)
+{
+ struct virtio_pci_modern_device *mdev = vdpa_to_mdev(vdpa);
+
+ return vp_modern_get_features(mdev);
+}
+
+static int vp_vdpa_set_features(struct vdpa_device *vdpa, u64 features)
+{
+ struct virtio_pci_modern_device *mdev = vdpa_to_mdev(vdpa);
+
+ vp_modern_set_features(mdev, features);
+
+ return 0;
+}
+
+static u8 vp_vdpa_get_status(struct vdpa_device *vdpa)
+{
+ struct virtio_pci_modern_device *mdev = vdpa_to_mdev(vdpa);
+
+ return vp_modern_get_status(mdev);
+}
+
+static void vp_vdpa_free_irq(struct vp_vdpa *vp_vdpa)
+{
+ struct virtio_pci_modern_device *mdev = _vdpa->mdev;
+ struct pci_dev *pdev = mdev->pci_dev;
+ int i;
+
+ for (i = 0; i < vp_vdpa->queues; i++) {
+ if (vp_vdpa->vring[i].irq != VIRTIO_MSI_NO_VECTOR) {
+ vp_modern_queue_vector(mdev, i, VIRTIO_MSI_NO_VECTOR);
+ devm_free_irq(>dev, vp_vdpa->vring[i].irq,
+ _vdpa->vring[i]);
+ vp_vdpa->vring[i].irq = VIRTIO_MSI_NO_VECTOR;
+ }
+ }
+
+ if (vp_vdpa->config_irq != VIRTIO_MSI_NO_VECTOR) {
+ vp_modern_config_vector(mdev, VIRTIO_MSI_NO_VECTOR);
+ devm_free_irq(>dev, vp_vdpa->config_irq, vp_vdpa);
+ vp_vdpa->config_irq = VIRTIO_MSI_NO_VECTOR;
+ }
+
+ if (vp_vdpa->vectors) {
+ pci_free_irq_vectors(pdev);
+ vp_vdpa->vectors = 0;
+ }
+}
+
+static irqreturn_t vp_vdpa_vq_handler(int irq, void *arg)
+{
+ struct vp_vring *vring = arg;
+
+ if (vring->cb.callback)
+ return vring->cb.callback(vring->cb.private);
+
+
[PATCH V4 2/3] vdpa: set the virtqueue num during register
This patch delay the queue number setting to vDPA device
registering. This allows us to probe the virtqueue numbers between
device allocation and registering.
Reviewed-by: Stefano Garzarella
Signed-off-by: Jason Wang
---
drivers/vdpa/ifcvf/ifcvf_main.c | 5 ++---
drivers/vdpa/mlx5/net/mlx5_vnet.c| 4 ++--
drivers/vdpa/vdpa.c | 18 ++
drivers/vdpa/vdpa_sim/vdpa_sim.c | 2 +-
drivers/vdpa/vdpa_sim/vdpa_sim_net.c | 2 +-
include/linux/vdpa.h | 10 +-
6 files changed, 21 insertions(+), 20 deletions(-)
diff --git a/drivers/vdpa/ifcvf/ifcvf_main.c b/drivers/vdpa/ifcvf/ifcvf_main.c
index 7c8bbfcf6c3e..d555a6a5d1ba 100644
--- a/drivers/vdpa/ifcvf/ifcvf_main.c
+++ b/drivers/vdpa/ifcvf/ifcvf_main.c
@@ -431,8 +431,7 @@ static int ifcvf_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
}
adapter = vdpa_alloc_device(struct ifcvf_adapter, vdpa,
- dev, _vdpa_ops,
- IFCVF_MAX_QUEUE_PAIRS * 2, NULL);
+ dev, _vdpa_ops, NULL);
if (adapter == NULL) {
IFCVF_ERR(pdev, "Failed to allocate vDPA structure");
return -ENOMEM;
@@ -456,7 +455,7 @@ static int ifcvf_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
for (i = 0; i < IFCVF_MAX_QUEUE_PAIRS * 2; i++)
vf->vring[i].irq = -EINVAL;
- ret = vdpa_register_device(>vdpa);
+ ret = vdpa_register_device(>vdpa, IFCVF_MAX_QUEUE_PAIRS * 2);
if (ret) {
IFCVF_ERR(pdev, "Failed to register ifcvf to vdpa bus");
goto err;
diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
b/drivers/vdpa/mlx5/net/mlx5_vnet.c
index 10e9b09932eb..71397fdafa6a 100644
--- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
+++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
@@ -1982,7 +1982,7 @@ static int mlx5v_probe(struct auxiliary_device *adev,
max_vqs = min_t(u32, max_vqs, MLX5_MAX_SUPPORTED_VQS);
ndev = vdpa_alloc_device(struct mlx5_vdpa_net, mvdev.vdev,
mdev->device, _vdpa_ops,
-2 * mlx5_vdpa_max_qps(max_vqs), NULL);
+NULL);
if (IS_ERR(ndev))
return PTR_ERR(ndev);
@@ -2009,7 +2009,7 @@ static int mlx5v_probe(struct auxiliary_device *adev,
if (err)
goto err_res;
- err = vdpa_register_device(>vdev);
+ err = vdpa_register_device(>vdev, 2 *
mlx5_vdpa_max_qps(max_vqs));
if (err)
goto err_reg;
diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c
index 3d997b389345..55a15c51e243 100644
--- a/drivers/vdpa/vdpa.c
+++ b/drivers/vdpa/vdpa.c
@@ -69,7 +69,6 @@ static void vdpa_release_dev(struct device *d)
* initialized but before registered.
* @parent: the parent device
* @config: the bus operations that is supported by this device
- * @nvqs: number of virtqueues supported by this device
* @size: size of the parent structure that contains private data
* @name: name of the vdpa device; optional.
*
@@ -81,7 +80,7 @@ static void vdpa_release_dev(struct device *d)
*/
struct vdpa_device *__vdpa_alloc_device(struct device *parent,
const struct vdpa_config_ops *config,
- int nvqs, size_t size, const char *name)
+ size_t size, const char *name)
{
struct vdpa_device *vdev;
int err = -EINVAL;
@@ -107,7 +106,6 @@ struct vdpa_device *__vdpa_alloc_device(struct device
*parent,
vdev->index = err;
vdev->config = config;
vdev->features_valid = false;
- vdev->nvqs = nvqs;
if (name)
err = dev_set_name(>dev, "%s", name);
@@ -136,10 +134,12 @@ static int vdpa_name_match(struct device *dev, const void
*data)
return (strcmp(dev_name(>dev), data) == 0);
}
-static int __vdpa_register_device(struct vdpa_device *vdev)
+static int __vdpa_register_device(struct vdpa_device *vdev, int nvqs)
{
struct device *dev;
+ vdev->nvqs = nvqs;
+
lockdep_assert_held(_dev_mutex);
dev = bus_find_device(_bus, NULL, dev_name(>dev),
vdpa_name_match);
if (dev) {
@@ -155,15 +155,16 @@ static int __vdpa_register_device(struct vdpa_device
*vdev)
* Caller must invoke this routine in the management device dev_add()
* callback after setting up valid mgmtdev for this vdpa device.
* @vdev: the vdpa device to be registered to vDPA bus
+ * @nvqs: number of virtqueues supported by this device
*
* Returns an error when fail to add device to vDPA bus
*/
-int _vdpa_register_device(struct vdpa_device *vdev)
+int _vdpa_register_device(struct vdpa_device *vdev, int nvqs)
{
if (!vdev->mdev)
return -EINVAL;
- return __vdpa_register_device(vdev);
+ return __vdpa_register_device(vdev, nvqs);
}
[PATCH V4 1/3] virtio: don't prompt CONFIG_VIRTIO_PCI_MODERN
We used to prompt CONFIG_VIRTIO_PCI_MODERN to user which may bring a
lot of confusion. E.g it may break various default configs which want
virtio devices.
So this patch fixes this by hiding the prompot and documenting the
dependency. While at it, rename the module to VIRTIO_PCI_LIB.
Cc: Arnd Bergmann
Cc: Anders Roxell
Cc: Guenter Roeck
Reported-by: Naresh Kamboju
Fixes: 86b87c9d858b6 ("virtio-pci: introduce modern device module")
Signed-off-by: Jason Wang
---
drivers/virtio/Kconfig | 11 ++-
drivers/virtio/Makefile | 2 +-
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 6b9b81f4b8c2..ce1b3f6ec325 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -12,13 +12,13 @@ config ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
This option is selected if the architecture may need to enforce
VIRTIO_F_ACCESS_PLATFORM
-config VIRTIO_PCI_MODERN
- tristate "Modern Virtio PCI Device"
- depends on PCI
+config VIRTIO_PCI_LIB
+ tristate
help
Modern PCI device implementation. This module implements the
basic probe and control for devices which are based on modern
- PCI device with possible vendor specific extensions.
+ PCI device with possible vendor specific extensions. Any
+ module that selects this module must depend on PCI.
menuconfig VIRTIO_MENU
bool "Virtio drivers"
@@ -28,7 +28,8 @@ if VIRTIO_MENU
config VIRTIO_PCI
tristate "PCI driver for virtio devices"
- depends on VIRTIO_PCI_MODERN
+ depends on PCI
+ select VIRTIO_PCI_LIB
select VIRTIO
help
This driver provides support for virtio based paravirtual device
diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
index f097578aaa8f..699bbea0465f 100644
--- a/drivers/virtio/Makefile
+++ b/drivers/virtio/Makefile
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_VIRTIO) += virtio.o virtio_ring.o
-obj-$(CONFIG_VIRTIO_PCI_MODERN) += virtio_pci_modern_dev.o
+obj-$(CONFIG_VIRTIO_PCI_LIB) += virtio_pci_modern_dev.o
obj-$(CONFIG_VIRTIO_MMIO) += virtio_mmio.o
obj-$(CONFIG_VIRTIO_PCI) += virtio_pci.o
virtio_pci-y := virtio_pci_modern.o virtio_pci_common.o
--
2.25.1
[PATCH 4/8] ARM: mstar: Link cpupll to cpu
The CPU clock is sourced from the CPU PLL.
Link cpupll to the cpu so that frequency scaling can happen.
Signed-off-by: Daniel Palmer
---
arch/arm/boot/dts/mstar-v7.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/mstar-v7.dtsi b/arch/arm/boot/dts/mstar-v7.dtsi
index d323c1a3f3c2..4d9991294f7c 100644
--- a/arch/arm/boot/dts/mstar-v7.dtsi
+++ b/arch/arm/boot/dts/mstar-v7.dtsi
@@ -21,6 +21,8 @@ cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x0>;
+ clocks = <>;
+ clock-names = "cpuclk";
};
};
--
2.30.0.rc2
[PATCH V4 0/3] virtio-pci: introduce modern device module
Hi all: This series tries to implement a vDPA driver for virtio-pci device which will bridge between vDPA bus and virtio-pci device. This could be used for future feature prototyping and testing. Please review Changes since V4: - include the patch to let VIRTIO_PCI_LIB to be auto selected - style fixes in the Kconfig for vp-vdpa driver - fix the err value returned during vp-vdpa driver probing Changes since V3: - rebase to vhost.git Changes since V2: - tweak config prompt - switch from 'cb' to 'config_cb' for vp_vdpa config interrupt - use a macro for vp_vdpa msix name length Changes since V1: - don't try to use devres for virtio-pci core - tweak the commit log - split the patches furtherly to ease the reviewing Changes since RFC: - Split common codes from virito-pci and share it with vDPA driver - Use dynamic id in order to be less confusing with virtio-pci driver - No feature whitelist, supporting any features (mq, config etc) Jason Wang (3): virtio: don't prompt CONFIG_VIRTIO_PCI_MODERN vdpa: set the virtqueue num during register vdpa: introduce virtio pci driver drivers/vdpa/Kconfig | 7 + drivers/vdpa/Makefile| 1 + drivers/vdpa/ifcvf/ifcvf_main.c | 5 +- drivers/vdpa/mlx5/net/mlx5_vnet.c| 4 +- drivers/vdpa/vdpa.c | 18 +- drivers/vdpa/vdpa_sim/vdpa_sim.c | 2 +- drivers/vdpa/vdpa_sim/vdpa_sim_net.c | 2 +- drivers/vdpa/virtio_pci/Makefile | 2 + drivers/vdpa/virtio_pci/vp_vdpa.c| 458 +++ drivers/virtio/Kconfig | 11 +- drivers/virtio/Makefile | 2 +- include/linux/vdpa.h | 10 +- 12 files changed, 496 insertions(+), 26 deletions(-) create mode 100644 drivers/vdpa/virtio_pci/Makefile create mode 100644 drivers/vdpa/virtio_pci/vp_vdpa.c -- 2.25.1
[PATCH 3/8] ARM: mstar: Add cpupll to base dtsi
All MStar/SigmaStar ARMv7 SoCs have the CPU PLL at the same
place so add it to the base dtsi.
Signed-off-by: Daniel Palmer
---
arch/arm/boot/dts/mstar-v7.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/mstar-v7.dtsi b/arch/arm/boot/dts/mstar-v7.dtsi
index 075d583d6f40..d323c1a3f3c2 100644
--- a/arch/arm/boot/dts/mstar-v7.dtsi
+++ b/arch/arm/boot/dts/mstar-v7.dtsi
@@ -132,6 +132,13 @@ mpll: mpll@206000 {
clocks = <>;
};
+ cpupll: cpupll@206400 {
+ compatible = "mstar,msc313-cpupll";
+ reg = <0x206400 0x200>;
+ #clock-cells = <0>;
+ clocks = < MSTAR_MSC313_MPLL_DIV2>;
+ };
+
gpio: gpio@207800 {
#gpio-cells = <2>;
reg = <0x207800 0x200>;
--
2.30.0.rc2
[PATCH 2/8] clk: mstar: msc313 cpupll clk driver
Add a driver for the CPU pll/ARM pll/MIPS pll that is present
in MStar SoCs.
Currently there is no documentation for this block so it's possible
this driver isn't entirely correct.
Only tested on the version of this IP in the MStar/SigmaStar
ARMv7 SoCs.
Co-authored-by: Willy Tarreau
Signed-off-by: Daniel Palmer
---
drivers/clk/mstar/Kconfig | 7 +
drivers/clk/mstar/Makefile| 1 +
drivers/clk/mstar/clk-msc313-cpupll.c | 228 ++
3 files changed, 236 insertions(+)
create mode 100644 drivers/clk/mstar/clk-msc313-cpupll.c
diff --git a/drivers/clk/mstar/Kconfig b/drivers/clk/mstar/Kconfig
index de37e1bce2d2..a44ca2b180ff 100644
--- a/drivers/clk/mstar/Kconfig
+++ b/drivers/clk/mstar/Kconfig
@@ -7,3 +7,10 @@ config MSTAR_MSC313_MPLL
help
Support for the MPLL PLL and dividers block present on
MStar/Sigmastar SoCs.
+
+config MSTAR_MSC313_CPUPLL
+ bool "MStar CPUPLL driver"
+ depends on ARCH_MSTARV7 || COMPILE_TEST
+ default ARCH_MSTARV7
+ help
+ Support for the CPU PLL present on MStar/Sigmastar SoCs.
diff --git a/drivers/clk/mstar/Makefile b/drivers/clk/mstar/Makefile
index f8dcd25ede1d..9f05b73a0619 100644
--- a/drivers/clk/mstar/Makefile
+++ b/drivers/clk/mstar/Makefile
@@ -4,3 +4,4 @@
#
obj-$(CONFIG_MSTAR_MSC313_MPLL) += clk-msc313-mpll.o
+obj-$(CONFIG_MSTAR_MSC313_CPUPLL) += clk-msc313-cpupll.o
diff --git a/drivers/clk/mstar/clk-msc313-cpupll.c
b/drivers/clk/mstar/clk-msc313-cpupll.c
new file mode 100644
index ..3f250404ecda
--- /dev/null
+++ b/drivers/clk/mstar/clk-msc313-cpupll.c
@@ -0,0 +1,228 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Daniel Palmer
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * This IP is not documented outside of the messy vendor driver.
+ * Below is what we think the registers look like based on looking at
+ * the vendor code and poking at the hardware:
+ *
+ * 0x140 -- LPF low. Seems to store one half of the clock transition
+ * 0x144 /
+ * 0x148 -- LPF high. Seems to store one half of the clock transition
+ * 0x14c /
+ * 0x150 -- vendor code says "toggle lpf enable"
+ * 0x154 -- mu?
+ * 0x15c -- lpf_update_count?
+ * 0x160 -- vendor code says "switch to LPF". Clock source config? Register
bank?
+ * 0x164 -- vendor code says "from low to high" which seems to mean transition
from LPF low to LPF high.
+ * 0x174 -- Seems to be the PLL lock status bit
+ * 0x180 -- Seems to be the current frequency, this might need to be populated
by software?
+ * 0x184 / The vendor driver uses these to set the initial value of LPF low
+ *
+ * Frequency seems to be calculated like this:
+ * (parent clock (432mhz) / register_magic_value) * 16 * 524288
+ * Only the lower 24 bits of the resulting value will be used. In addition, the
+ * PLL doesn't seem to be able to lock on frequencies lower than 220 MHz, as
+ * divisor 0xfb586f (220 MHz) works but 0xfb7fff locks up.
+ *
+ * Vendor values:
+ * frequency - register value
+ *
+ * 4 - 0x0067AE14
+ * 6 - 0x00451EB8,
+ * 8 - 0x0033D70A,
+ * 10 - 0x002978d4,
+ */
+
+#define REG_LPF_LOW_L 0x140
+#define REG_LPF_LOW_H 0x144
+#define REG_LPF_HIGH_BOTTOM0x148
+#define REG_LPF_HIGH_TOP 0x14c
+#define REG_LPF_TOGGLE 0x150
+#define REG_LPF_MYSTERYTWO 0x154
+#define REG_LPF_UPDATE_COUNT 0x15c
+#define REG_LPF_MYSTERYONE 0x160
+#define REG_LPF_TRANSITIONCTRL 0x164
+#define REG_LPF_LOCK 0x174
+#define REG_CURRENT0x180
+
+#define MULTIPLIER_1 16
+#define MULTIPLIER_2 524288
+#define MULTIPLIER (MULTIPLIER_1 * MULTIPLIER_2)
+
+struct msc313_cpupll {
+ void __iomem *base;
+ struct clk_hw clk_hw;
+};
+
+#define to_cpupll(_hw) container_of(_hw, struct msc313_cpupll, clk_hw)
+
+static u32 msc313_cpupll_reg_read32(struct msc313_cpupll *cpupll, unsigned int
reg)
+{
+ u32 value;
+
+ value = ioread16(cpupll->base + reg + 4) << 16;
+ value |= ioread16(cpupll->base + reg);
+
+ return value;
+}
+
+static void msc313_cpupll_reg_write32(struct msc313_cpupll *cpupll, unsigned
int reg, u32 value)
+{
+ u16 l = value & 0x, h = (value >> 16) & 0x;
+
+ iowrite16(l, cpupll->base + reg);
+ iowrite16(h, cpupll->base + reg + 4);
+}
+
+static void msc313_cpupll_setfreq(struct msc313_cpupll *cpupll, u32 regvalue)
+{
+ msc313_cpupll_reg_write32(cpupll, REG_LPF_HIGH_BOTTOM, regvalue);
+
+ iowrite16(0x1, cpupll->base + REG_LPF_MYSTERYONE);
+ iowrite16(0x6, cpupll->base + REG_LPF_MYSTERYTWO);
+ iowrite16(0x8, cpupll->base + REG_LPF_UPDATE_COUNT);
+ iowrite16(BIT(12), cpupll->base + REG_LPF_TRANSITIONCTRL);
+
+ iowrite16(0, cpupll->base + REG_LPF_TOGGLE);
+ iowrite16(1, cpupll->base + REG_LPF_TOGGLE);
+
+ while (!(ioread16(cpupll->base + REG_LPF_LOCK)))
+
[PATCH 1/8] dt-bindings: clk: mstar msc313 cpupll binding description
Add a binding description for the MStar/SigmaStar CPU PLL block.
Signed-off-by: Daniel Palmer
---
.../bindings/clock/mstar,msc313-cpupll.yaml | 45 +++
1 file changed, 45 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/mstar,msc313-cpupll.yaml
diff --git a/Documentation/devicetree/bindings/clock/mstar,msc313-cpupll.yaml
b/Documentation/devicetree/bindings/clock/mstar,msc313-cpupll.yaml
new file mode 100644
index ..a9ad7ab5230c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mstar,msc313-cpupll.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/mstar,msc313-cpupll.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MStar/Sigmastar MSC313 CPU PLL
+
+maintainers:
+ - Daniel Palmer
+
+description: |
+ The MStar/SigmaStar MSC313 and later ARMv7 chips have a scalable
+ PLL that can be used as the clock source for the CPU(s).
+
+properties:
+ compatible:
+const: mstar,msc313-cpupll
+
+ "#clock-cells":
+const: 1
+
+ clocks:
+maxItems: 1
+
+ reg:
+maxItems: 1
+
+required:
+ - compatible
+ - "#clock-cells"
+ - clocks
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+cpupll: cpupll@206400 {
+compatible = "mstar,msc313-cpupll";
+reg = <0x206400 0x200>;
+#clock-cells = <1>;
+clocks = < MSTAR_MSC313_MPLL_DIV2>;
+};
--
2.30.0.rc2
Re: [f2fs-dev] [PATCH v2] f2fs: fix a spelling error
On 2021/2/23 9:31, Yehan Xu wrote: From: xuyehan Delete the letter 'e' before 'number' Signed-off-by: xuyehan Reviewed-by: Chao Yu Thanks,
RE: [Linuxarm] Re: [PATCH] Documentation/features: mark BATCHED_UNMAP_TLB_FLUSH doesn't apply to ARM64
> -Original Message- > From: Anshuman Khandual [mailto:anshuman.khand...@arm.com] > Sent: Tuesday, February 23, 2021 7:10 PM > To: Song Bao Hua (Barry Song) ; cor...@lwn.net; > linux-...@vger.kernel.org; a...@linux-foundation.org; linux...@kvack.org > Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; > linux...@openeuler.org; Mel Gorman ; Andy Lutomirski > ; Catalin Marinas ; Will Deacon > > Subject: [Linuxarm] Re: [PATCH] Documentation/features: mark > BATCHED_UNMAP_TLB_FLUSH doesn't apply to ARM64 > > > > On 2/23/21 6:02 AM, Barry Song wrote: > > BATCHED_UNMAP_TLB_FLUSH is used on x86 to do batched tlb shootdown by > > sending one IPI to TLB flush all entries after unmapping pages rather > > than sending an IPI to flush each individual entry. > > On arm64, tlb shootdown is done by hardware. Flush instructions are > > innershareable. The local flushes are limited to the boot (1 per CPU) > > and when a task is getting a new ASID. > > Is there any previous discussion around this ? I copied the declaration of local flushes from: "ARM64 Linux kernel is SMP-aware (no possibility to build only for UP). Most of the flush instructions are innershareable. The local flushes are limited to the boot (1 per CPU) and when a task is getting a new ASIC." https://patchwork.kernel.org/project/xen-devel/patch/1461756173-10300-1-git-send-email-julien.gr...@arm.com/ I am not sure if getting a new asid and the boot are the only two cases of local flushes while I think this is probably true. But even we find more corner cases, hardly the trend arm64 doesn't need BATCHED_UNMAP_TLB_FLUSH will be changed. > > > So marking this feature as "TODO" is not proper. ".." isn't good as > > well. So this patch adds a "N/A" for this kind of features which are > > not needed on some architectures. > > > > Cc: Mel Gorman > > Cc: Andy Lutomirski > > Cc: Catalin Marinas > > Cc: Will Deacon > > Signed-off-by: Barry Song > > --- > > Documentation/features/arch-support.txt| 1 + > > Documentation/features/vm/TLB/arch-support.txt | 2 +- > > 2 files changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/features/arch-support.txt > b/Documentation/features/arch-support.txt > > index d22a1095e661..118ae031840b 100644 > > --- a/Documentation/features/arch-support.txt > > +++ b/Documentation/features/arch-support.txt > > @@ -8,4 +8,5 @@ The meaning of entries in the tables is: > > | ok | # feature supported by the architecture > > |TODO| # feature not yet supported by the architecture > > | .. | # feature cannot be supported by the hardware > > +| N/A| # feature doesn't apply to the architecture > > NA might be better here. s/doesn't apply/not applicable/ in order to match NA. > Still wondering if NA is really needed when there is already ".." ? Regardless > either way should be fine. I don't think ".." is proper here. ".." means hardware doesn't support the feature. But here it is just opposite, arm64 has the hardware support of tlb shootdown rather than depending on a software IPI. > > > > > diff --git a/Documentation/features/vm/TLB/arch-support.txt > b/Documentation/features/vm/TLB/arch-support.txt > > index 30f75a79ce01..0d070f9f98d8 100644 > > --- a/Documentation/features/vm/TLB/arch-support.txt > > +++ b/Documentation/features/vm/TLB/arch-support.txt > > @@ -9,7 +9,7 @@ > > | alpha: | TODO | > > | arc: | TODO | > > | arm: | TODO | > > -| arm64: | TODO | > > +| arm64: | N/A | > > | c6x: | .. | > > |csky: | TODO | > > | h8300: | .. | > > Thanks Barry
[PATCH 0/8] ARM: mstar: cpupll
This series adds a scrappy driver for the PLL that generates the cpu clock on MStar/SigmaStar ARMv7 SoCs. Unfortunately there isn't much documentation for this thing so there are few magic values and guesses. This needs to come after the MPLL DT changes. Daniel Palmer (8): dt-bindings: clk: mstar msc313 cpupll binding description clk: mstar: msc313 cpupll clk driver ARM: mstar: Add cpupll to base dtsi ARM: mstar: Link cpupll to cpu ARM: mstar: Link cpupll to second core ARM: mstar: Add OPP table for infinity ARM: mstar: Add OPP table for infinity3 ARM: mstar: Add OPP table for mercury5 .../bindings/clock/mstar,msc313-cpupll.yaml | 45 arch/arm/boot/dts/mstar-infinity.dtsi | 34 +++ arch/arm/boot/dts/mstar-infinity2m.dtsi | 2 + arch/arm/boot/dts/mstar-infinity3.dtsi| 58 + arch/arm/boot/dts/mstar-mercury5.dtsi | 36 +++ arch/arm/boot/dts/mstar-v7.dtsi | 9 + drivers/clk/mstar/Kconfig | 7 + drivers/clk/mstar/Makefile| 1 + drivers/clk/mstar/clk-msc313-cpupll.c | 228 ++ 9 files changed, 420 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/mstar,msc313-cpupll.yaml create mode 100644 drivers/clk/mstar/clk-msc313-cpupll.c -- 2.30.0.rc2
Re: [PATCH 0/2] optee: fix OOM seen due to tee_shm_free()
The following out of memory errors are seen on kexec reboot from the optee core. [0.368428] tee_bnxt_fw optee-clnt0: tee_shm_alloc failed [0.368461] tee_bnxt_fw: probe of optee-clnt0 failed with error -22 tee_shm_release() is not invoked on dma shm buffer. Implement .shutdown() in optee core as well as bnxt firmware driver to handle the release of the buffers correctly. More info: https://github.com/OP-TEE/optee_os/issues/3637 Jens, Could you please take sometime out and review the series. Thanks. Allen Pais (2): optee: fix tee out of memory failure seen during kexec reboot firmware: tee_bnxt: implement shutdown method to handle kexec reboots drivers/firmware/broadcom/tee_bnxt_fw.c | 9 drivers/tee/optee/core.c| 69 ++--- 2 files changed, 58 insertions(+), 20 deletions(-)
[PATCH] drm/amd/display: Remove unnecessary conversion to bool
Fix the following coccicheck warnings: ./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:8260:16-21: WARNING: conversion to bool not needed here. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 94cd5dd..323473d 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -8253,8 +8253,7 @@ static void amdgpu_dm_atomic_commit_tail(struct drm_atomic_state *state) hdcp_update_display( adev->dm.hdcp_workqueue, aconnector->dc_link->link_index, aconnector, new_con_state->hdcp_content_type, - new_con_state->content_protection == DRM_MODE_CONTENT_PROTECTION_DESIRED ? true - : false); + new_con_state->content_protection == DRM_MODE_CONTENT_PROTECTION_DESIRED); } #endif -- 1.8.3.1
Re: [PATCH] Documentation/features: mark BATCHED_UNMAP_TLB_FLUSH doesn't apply to ARM64
On 2/23/21 6:02 AM, Barry Song wrote: > BATCHED_UNMAP_TLB_FLUSH is used on x86 to do batched tlb shootdown by > sending one IPI to TLB flush all entries after unmapping pages rather > than sending an IPI to flush each individual entry. > On arm64, tlb shootdown is done by hardware. Flush instructions are > innershareable. The local flushes are limited to the boot (1 per CPU) > and when a task is getting a new ASID. Is there any previous discussion around this ? > So marking this feature as "TODO" is not proper. ".." isn't good as > well. So this patch adds a "N/A" for this kind of features which are > not needed on some architectures. > > Cc: Mel Gorman > Cc: Andy Lutomirski > Cc: Catalin Marinas > Cc: Will Deacon > Signed-off-by: Barry Song > --- > Documentation/features/arch-support.txt| 1 + > Documentation/features/vm/TLB/arch-support.txt | 2 +- > 2 files changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Documentation/features/arch-support.txt > b/Documentation/features/arch-support.txt > index d22a1095e661..118ae031840b 100644 > --- a/Documentation/features/arch-support.txt > +++ b/Documentation/features/arch-support.txt > @@ -8,4 +8,5 @@ The meaning of entries in the tables is: > | ok | # feature supported by the architecture > |TODO| # feature not yet supported by the architecture > | .. | # feature cannot be supported by the hardware > +| N/A| # feature doesn't apply to the architecture NA might be better here. s/doesn't apply/not applicable/ in order to match NA. Still wondering if NA is really needed when there is already ".." ? Regardless either way should be fine. > > diff --git a/Documentation/features/vm/TLB/arch-support.txt > b/Documentation/features/vm/TLB/arch-support.txt > index 30f75a79ce01..0d070f9f98d8 100644 > --- a/Documentation/features/vm/TLB/arch-support.txt > +++ b/Documentation/features/vm/TLB/arch-support.txt > @@ -9,7 +9,7 @@ > | alpha: | TODO | > | arc: | TODO | > | arm: | TODO | > -| arm64: | TODO | > +| arm64: | N/A | > | c6x: | .. | > |csky: | TODO | > | h8300: | .. | >
Re: [PATCH V3 XRT Alveo 02/18] fpga: xrt: driver metadata helper functions
Hi Tom, On 02/20/2021 09:07 AM, Tom Rix wrote: On 2/17/21 10:40 PM, Lizhi Hou wrote: XRT drivers use device tree as metadata format to discover HW subsystems behind PCIe BAR. Thus libfdt functions are called for driver to parse for the driver to parse the will fix. device tree blob. Signed-off-by: Sonal Santan Signed-off-by: Max Zhen Signed-off-by: Lizhi Hou --- drivers/fpga/xrt/include/metadata.h | 229 drivers/fpga/xrt/metadata/metadata.c | 524 +++ 2 files changed, 753 insertions(+) create mode 100644 drivers/fpga/xrt/include/metadata.h create mode 100644 drivers/fpga/xrt/metadata/metadata.c diff --git a/drivers/fpga/xrt/include/metadata.h b/drivers/fpga/xrt/include/metadata.h new file mode 100644 index ..b929bc469b73 --- /dev/null +++ b/drivers/fpga/xrt/include/metadata.h @@ -0,0 +1,229 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Header file for Xilinx Runtime (XRT) driver + * + * Copyright (C) 2020-2021 Xilinx, Inc. + * + * Authors: + * Lizhi Hou + */ + +#ifndef _XRT_METADATA_H +#define _XRT_METADATA_H + +#include +#include +#include + +#define XRT_MD_INVALID_LENGTH (~0UL) + These #defines could be in alphabetical order Some #define with embedded acronyms could be expanded ex/ XRT_MD_NODE_CMC_REG , what is CMC ? Will reorder. Expanding might make macro name too long. I will add comment as below: /* * IP nodes * AF: AXI Firewall * CMC: Card Management Controller * ERT: Embedded Runtime * PLP: Provider Reconfigurable Partition * ULP: User Reconfigurable Partition */ +#define XRT_MD_PROP_COMPATIBLE "compatible" +#define XRT_MD_PROP_PF_NUM "pcie_physical_function" +#define XRT_MD_PROP_BAR_IDX "pcie_bar_mapping" +#define XRT_MD_PROP_IO_OFFSET "reg" +#define XRT_MD_PROP_INTERRUPTS "interrupts" +#define XRT_MD_PROP_INTERFACE_UUID "interface_uuid" +#define XRT_MD_PROP_LOGIC_UUID "logic_uuid" +#define XRT_MD_PROP_VERSION_MAJOR "firmware_version_major" + +#define XRT_MD_PROP_HWICAP "axi_hwicap" +#define XRT_MD_PROP_PDI_CONFIG "pdi_config_mem" + +#define XRT_MD_NODE_ENDPOINTS "addressable_endpoints" +#define XRT_MD_INTERFACES_PATH "/interfaces" + +#define XRT_MD_NODE_FIRMWARE "firmware" +#define XRT_MD_NODE_INTERFACES "interfaces" +#define XRT_MD_NODE_PARTITION_INFO "partition_info" + +#define XRT_MD_NODE_FLASH "ep_card_flash_program_00" +#define XRT_MD_NODE_XVC_PUB "ep_debug_bscan_user_00" +#define XRT_MD_NODE_XVC_PRI "ep_debug_bscan_mgmt_00" +#define XRT_MD_NODE_SYSMON "ep_cmp_sysmon_00" +#define XRT_MD_NODE_AF_BLP_CTRL_MGMT "ep_firewall_blp_ctrl_mgmt_00" +#define XRT_MD_NODE_AF_BLP_CTRL_USER "ep_firewall_blp_ctrl_user_00" +#define XRT_MD_NODE_AF_CTRL_MGMT "ep_firewall_ctrl_mgmt_00" +#define XRT_MD_NODE_AF_CTRL_USER "ep_firewall_ctrl_user_00" +#define XRT_MD_NODE_AF_CTRL_DEBUG "ep_firewall_ctrl_debug_00" +#define XRT_MD_NODE_AF_DATA_H2C "ep_firewall_data_h2c_00" +#define XRT_MD_NODE_AF_DATA_C2H "ep_firewall_data_c2h_00" +#define XRT_MD_NODE_AF_DATA_P2P "ep_firewall_data_p2p_00" +#define XRT_MD_NODE_AF_DATA_M2M "ep_firewall_data_m2m_00" +#define XRT_MD_NODE_CMC_REG "ep_cmc_regmap_00" +#define XRT_MD_NODE_CMC_RESET "ep_cmc_reset_00" +#define XRT_MD_NODE_CMC_MUTEX "ep_cmc_mutex_00" +#define XRT_MD_NODE_CMC_FW_MEM "ep_cmc_firmware_mem_00" +#define XRT_MD_NODE_ERT_FW_MEM "ep_ert_firmware_mem_00" +#define XRT_MD_NODE_ERT_CQ_MGMT "ep_ert_command_queue_mgmt_00" +#define XRT_MD_NODE_ERT_CQ_USER "ep_ert_command_queue_user_00" +#define XRT_MD_NODE_MAILBOX_MGMT "ep_mailbox_mgmt_00" +#define XRT_MD_NODE_MAILBOX_USER "ep_mailbox_user_00" +#define XRT_MD_NODE_GATE_PLP "ep_pr_isolate_plp_00" +#define XRT_MD_NODE_GATE_ULP "ep_pr_isolate_ulp_00" +#define XRT_MD_NODE_PCIE_MON "ep_pcie_link_mon_00" +#define XRT_MD_NODE_DDR_CALIB "ep_ddr_mem_calib_00" +#define XRT_MD_NODE_CLK_KERNEL1 "ep_aclk_kernel_00" +#define XRT_MD_NODE_CLK_KERNEL2 "ep_aclk_kernel_01" +#define XRT_MD_NODE_CLK_KERNEL3 "ep_aclk_hbm_00" +#define XRT_MD_NODE_KDMA_CTRL "ep_kdma_ctrl_00" +#define XRT_MD_NODE_FPGA_CONFIG "ep_fpga_configuration_00" +#define XRT_MD_NODE_ERT_SCHED "ep_ert_sched_00" +#define XRT_MD_NODE_XDMA "ep_xdma_00" +#define XRT_MD_NODE_MSIX "ep_msix_00" +#define XRT_MD_NODE_QDMA "ep_qdma_00" +#define XRT_MD_XRT_MD_NODE_QDMA4 "ep_qdma4_00" +#define XRT_MD_NODE_STM "ep_stream_traffic_manager_00" +#define XRT_MD_NODE_STM4 "ep_stream_traffic_manager4_00" +#define XRT_MD_NODE_CLK_SHUTDOWN "ep_aclk_shutdown_00" +#define XRT_MD_NODE_ERT_BASE "ep_ert_base_address_00" +#define XRT_MD_NODE_ERT_RESET "ep_ert_reset_00" +#define XRT_MD_NODE_CLKFREQ_K1 "ep_freq_cnt_aclk_kernel_00" +#define XRT_MD_NODE_CLKFREQ_K2 "ep_freq_cnt_aclk_kernel_01" +#define XRT_MD_NODE_CLKFREQ_HBM "ep_freq_cnt_aclk_hbm_00" +#define XRT_MD_NODE_GAPPING "ep_gapping_demand_00" +#define XRT_MD_NODE_UCS_CONTROL_STATUS "ep_ucs_control_status_00" +#define XRT_MD_NODE_P2P "ep_p2p_00" +#define XRT_MD_NODE_REMAP_P2P "ep_remap_p2p_00" +#define XRT_MD_NODE_DDR4_RESET_GATE "ep_ddr_mem_srsr_gate_00"
[PATCH -next] docs: proc.rst: fix indentation warning
Fix indentation snafu in proc.rst as reported by Stephen.
next-20210219/Documentation/filesystems/proc.rst:697: WARNING: Unexpected
indentation.
Fixes: 93ea4a0b8fce ("Documentation: proc.rst: add more about the 6 fields in
loadavg")
Reported-by: Stephen Rothwell
Signed-off-by: Randy Dunlap
Cc: Jonathan Corbet
Cc: linux-...@vger.kernel.org
---
shame on me.
Documentation/filesystems/proc.rst |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20210219.orig/Documentation/filesystems/proc.rst
+++ linux-next-20210219/Documentation/filesystems/proc.rst
@@ -694,7 +694,7 @@ files are there, and which are missing.
All fields are separated by one space except "number of
processes currently runnable" and "total number of processes
in system", which are separated by a slash ('/'). Example:
- 0.61 0.61 0.55 3/828 22084
+0.61 0.61 0.55 3/828 22084
locksKernel locks
meminfo Memory info
misc Miscellaneous
Re: hi
[PATCH v2] memcg: charge before adding to swapcache on swapin
Currently the kernel adds the page, allocated for swapin, to the
swapcache before charging the page. This is fine but now we want a
per-memcg swapcache stat which is essential for folks who wants to
transparently migrate from cgroup v1's memsw to cgroup v2's memory and
swap counters. In addition charging a page before exposing it to other
parts of the kernel is a step in the right direction.
To correctly maintain the per-memcg swapcache stat, this patch has
adopted to charge the page before adding it to swapcache. One
challenge in this option is the failure case of add_to_swap_cache() on
which we need to undo the mem_cgroup_charge(). Specifically undoing
mem_cgroup_uncharge_swap() is not simple.
To resolve the issue, this patch introduces transaction like interface
to charge a page for swapin. The function mem_cgroup_charge_swapin_page()
initiates the charging of the page and mem_cgroup_finish_swapin_page()
completes the charging process. So, the kernel starts the charging
process of the page for swapin with mem_cgroup_charge_swapin_page(),
adds the page to the swapcache and on success completes the charging
process with mem_cgroup_finish_swapin_page().
Signed-off-by: Shakeel Butt
---
Changes since v1:
- Removes __GFP_NOFAIL and introduced transaction interface for charging
(suggested by Johannes)
- Updated the commit message
include/linux/memcontrol.h | 14 +
mm/memcontrol.c| 116 +++--
mm/memory.c| 14 ++---
mm/swap_state.c| 11 ++--
4 files changed, 97 insertions(+), 58 deletions(-)
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index e6dc793d587d..585d96bda4f5 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -596,6 +596,9 @@ static inline bool mem_cgroup_below_min(struct mem_cgroup
*memcg)
}
int mem_cgroup_charge(struct page *page, struct mm_struct *mm, gfp_t gfp_mask);
+int mem_cgroup_charge_swapin_page(struct page *page, struct mm_struct *mm,
+ gfp_t gfp, swp_entry_t entry);
+void mem_cgroup_finish_swapin_page(struct page *page, swp_entry_t entry);
void mem_cgroup_uncharge(struct page *page);
void mem_cgroup_uncharge_list(struct list_head *page_list);
@@ -1141,6 +1144,17 @@ static inline int mem_cgroup_charge(struct page *page,
struct mm_struct *mm,
return 0;
}
+static inline int mem_cgroup_charge_swapin_page(struct page *page,
+ struct mm_struct *mm, gfp_t gfp, swp_entry_t entry);
+{
+ return 0;
+}
+
+static inline void mem_cgroup_finish_swapin_page(struct page *page,
+swp_entry_t entry)
+{
+}
+
static inline void mem_cgroup_uncharge(struct page *page)
{
}
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 2db2aeac8a9e..226b7bccb44c 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -6690,6 +6690,27 @@ void mem_cgroup_calculate_protection(struct mem_cgroup
*root,
atomic_long_read(>memory.children_low_usage)));
}
+static int __mem_cgroup_charge(struct page *page, struct mem_cgroup *memcg,
+ gfp_t gfp)
+{
+ unsigned int nr_pages = thp_nr_pages(page);
+ int ret;
+
+ ret = try_charge(memcg, gfp, nr_pages);
+ if (ret)
+ goto out;
+
+ css_get(>css);
+ commit_charge(page, memcg);
+
+ local_irq_disable();
+ mem_cgroup_charge_statistics(memcg, page, nr_pages);
+ memcg_check_events(memcg, page);
+ local_irq_enable();
+out:
+ return ret;
+}
+
/**
* mem_cgroup_charge - charge a newly allocated page to a cgroup
* @page: page to charge
@@ -6699,55 +6720,70 @@ void mem_cgroup_calculate_protection(struct mem_cgroup
*root,
* Try to charge @page to the memcg that @mm belongs to, reclaiming
* pages according to @gfp_mask if necessary.
*
+ * Do not use this for pages allocated for swapin.
+ *
* Returns 0 on success. Otherwise, an error code is returned.
*/
int mem_cgroup_charge(struct page *page, struct mm_struct *mm, gfp_t gfp_mask)
{
- unsigned int nr_pages = thp_nr_pages(page);
- struct mem_cgroup *memcg = NULL;
- int ret = 0;
+ struct mem_cgroup *memcg;
+ int ret;
if (mem_cgroup_disabled())
- goto out;
+ return 0;
- if (PageSwapCache(page)) {
- swp_entry_t ent = { .val = page_private(page), };
- unsigned short id;
+ memcg = get_mem_cgroup_from_mm(mm);
+ ret = __mem_cgroup_charge(page, memcg, gfp_mask);
+ css_put(>css);
- /*
-* Every swap fault against a single page tries to charge the
-* page, bail as early as possible. shmem_unuse() encounters
-* already charged pages, too. page and memcg binding is
-* protected by the page lock, which serializes swap cache
-* removal, which
[PATCH net v2 2/2] can: fix ref count warning if socket was closed before skb was cloned
There are two ref count variables controlling the free()ing of a socket:
- struct sock::sk_refcnt - which is changed by sock_hold()/sock_put()
- struct sock::sk_wmem_alloc - which accounts the memory allocated by
the skbs in the send path.
If the socket is closed the struct sock::sk_refcnt will finally reach 0
and sk_free() is called. Which then calls
refcount_dec_and_test(>sk_wmem_alloc). If sk_wmem_alloc reaches 0
the socket is actually free()ed.
In case there are still TX skbs on the fly and the socket() is closed,
the struct sock::sk_refcnt reaches 0. In the TX-path the CAN stack
clones an "echo" skb, calls sock_hold() on the original socket and
references it. This produces the following back trace:
| WARNING: CPU: 0 PID: 280 at lib/refcount.c:25
refcount_warn_saturate+0x114/0x134
| refcount_t: addition on 0; use-after-free.
| Modules linked in: coda_vpu(E) v4l2_jpeg(E) videobuf2_vmalloc(E) imx_vdoa(E)
| CPU: 0 PID: 280 Comm: test_can.sh Tainted: GE
5.11.0-04577-gf8ff6603c617 #203
| Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
| Backtrace:
| [<80bafea4>] (dump_backtrace) from [<80bb0280>] (show_stack+0x20/0x24)
r7: r6:600f0113 r5: r4:81441220
| [<80bb0260>] (show_stack) from [<80bb593c>] (dump_stack+0xa0/0xc8)
| [<80bb589c>] (dump_stack) from [<8012b268>] (__warn+0xd4/0x114) r9:0019
r8:80f4a8c2 r7:83e4150c r6: r5:0009 r4:80528f90
| [<8012b194>] (__warn) from [<80bb09c4>] (warn_slowpath_fmt+0x88/0xc8)
r9:83f26400 r8:80f4a8d1 r7:0009 r6:80528f90 r5:0019 r4:80f4a8c2
| [<80bb0940>] (warn_slowpath_fmt) from [<80528f90>]
(refcount_warn_saturate+0x114/0x134) r8: r7: r6:82b44000
r5:834e5600 r4:83f4d540
| [<80528e7c>] (refcount_warn_saturate) from [<8079a4c8>]
(__refcount_add.constprop.0+0x4c/0x50)
| [<8079a47c>] (__refcount_add.constprop.0) from [<8079a57c>]
(can_put_echo_skb+0xb0/0x13c)
| [<8079a4cc>] (can_put_echo_skb) from [<8079ba98>]
(flexcan_start_xmit+0x1c4/0x230) r9:0010 r8:83f48610 r7:0fdc
r6:0c08 r5:82b44000 r4:834e5600
| [<8079b8d4>] (flexcan_start_xmit) from [<80969078>]
(netdev_start_xmit+0x44/0x70) r9:814c0ba0 r8:80c8790c r7: r6:834e5600
r5:82b44000 r4:82ab1f00
| [<80969034>] (netdev_start_xmit) from [<809725a4>]
(dev_hard_start_xmit+0x19c/0x318) r9:814c0ba0 r8: r7:82ab1f00
r6:82b44000 r5: r4:834e5600
| [<80972408>] (dev_hard_start_xmit) from [<809c6584>]
(sch_direct_xmit+0xcc/0x264) r10:834e5600 r9: r8: r7:82b44000
r6:82ab1f00 r5:834e5600 r4:83f27400
| [<809c64b8>] (sch_direct_xmit) from [<809c6c0c>] (__qdisc_run+0x4f0/0x534)
To fix this problem, we have to take into account, that the socket
technically still there but should not used (by any new skbs) any more.
The function skb_clone_sk_optional() (introduced in the previous patch)
takes care of this. It will only clone the skb, if the sk is set and the
refcount has not reached 0.
Cc: Oliver Hartkopp
Cc: Andre Naujoks
Cc: Eric Dumazet
Fixes: 0ae89beb283a ("can: add destructor for self generated skbs")
Signed-off-by: Oleksij Rempel
---
include/linux/can/skb.h | 3 +--
net/can/af_can.c | 6 +++---
net/can/j1939/main.c | 3 +--
net/can/j1939/socket.c| 3 +--
net/can/j1939/transport.c | 4 +---
5 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/include/linux/can/skb.h b/include/linux/can/skb.h
index 685f34cfba20..bc1af38697a2 100644
--- a/include/linux/can/skb.h
+++ b/include/linux/can/skb.h
@@ -79,13 +79,12 @@ static inline struct sk_buff *can_create_echo_skb(struct
sk_buff *skb)
{
struct sk_buff *nskb;
- nskb = skb_clone(skb, GFP_ATOMIC);
+ nskb = skb_clone_sk_optional(skb);
if (unlikely(!nskb)) {
kfree_skb(skb);
return NULL;
}
- can_skb_set_owner(nskb, skb->sk);
consume_skb(skb);
return nskb;
}
diff --git a/net/can/af_can.c b/net/can/af_can.c
index cce2af10eb3e..9e1bd60e7e1b 100644
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -251,20 +251,20 @@ int can_send(struct sk_buff *skb, int loop)
* its own. Example: can_raw sockopt CAN_RAW_RECV_OWN_MSGS
* Therefore we have to ensure that skb->sk remains the
* reference to the originating sock by restoring skb->sk
-* after each skb_clone() or skb_orphan() usage.
+* after each skb_clone() or skb_orphan() usage -
+* skb_clone_sk_optional() takes care of that.
*/
if (!(skb->dev->flags & IFF_ECHO)) {
/* If the interface is not capable to do loopback
* itself, we do it here.
*/
- newskb = skb_clone(skb, GFP_ATOMIC);
+ newskb = skb_clone_sk_optional(skb);
if (!newskb) {
kfree_skb(skb);
[PATCH net v2 1/2] skbuff: skb_clone_sk_optional(): add function to always clone a skb and increase refcount on sk if valid
There already the function skb_clone_sk(), which clones the skb, but
only if the sk is valid.
There are several users in the networking stack, which always need a
clone of a skb with the sk refcount incremented (but only if the sk is
valid). This patch adds such a function.
Signed-off-by: Oleksij Rempel
---
include/linux/skbuff.h | 1 +
net/core/skbuff.c | 27 +++
2 files changed, 28 insertions(+)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 6d0a33d1c0db..99d552017508 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -3874,6 +3874,7 @@ static inline void skb_metadata_clear(struct sk_buff *skb)
skb_metadata_set(skb, 0);
}
+struct sk_buff *skb_clone_sk_optional(struct sk_buff *skb);
struct sk_buff *skb_clone_sk(struct sk_buff *skb);
#ifdef CONFIG_NETWORK_PHY_TIMESTAMPING
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 545a472273a5..97341f173fb0 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -4671,6 +4671,33 @@ struct sk_buff *sock_dequeue_err_skb(struct sock *sk)
}
EXPORT_SYMBOL(sock_dequeue_err_skb);
+/**
+ * skb_clone_sk_optional - create clone of skb, and take reference to socket if
+ * socket is referenced in original skb
+ * @skb: the skb to clone
+ *
+ * This function always creates a clone of a buffer. If it that holds a valid
+ * reference on sk_refcnt this is increased.
+ */
+struct sk_buff *skb_clone_sk_optional(struct sk_buff *skb)
+{
+ struct sock *sk = skb->sk;
+ struct sk_buff *clone;
+
+ clone = skb_clone(skb, GFP_ATOMIC);
+ if (!clone)
+ return NULL;
+
+ if (!sk || !refcount_inc_not_zero(>sk_refcnt))
+ return clone;
+
+ clone->sk = sk;
+ clone->destructor = sock_efree;
+
+ return clone;
+}
+EXPORT_SYMBOL(skb_clone_sk_optional);
+
/**
* skb_clone_sk - create clone of skb, and take reference to socket
* @skb: the skb to clone
--
2.29.2
[PATCH net v2 0/2] add support for skb with sk ref cloning
changes v2: - drop mac80211 patch for now, it can go separately if needed Hello, this series tries to fix a long standing problem in the CAN echo SKB handling. The problem shows up if an echo SKB for a SKB that references an already closed socket is created. It looks like the mac80211/tx.c has the same problem, see RFC patch 3 for details. regards, Oleksij Oleksij Rempel (2): skbuff: skb_clone_sk_optional(): add function to always clone a skb and increase refcount on sk if valid can: fix ref count warning if socket was closed before skb was cloned include/linux/can/skb.h | 3 +-- include/linux/skbuff.h| 1 + net/can/af_can.c | 6 +++--- net/can/j1939/main.c | 3 +-- net/can/j1939/socket.c| 3 +-- net/can/j1939/transport.c | 4 +--- net/core/skbuff.c | 27 +++ 7 files changed, 35 insertions(+), 12 deletions(-) -- 2.29.2
[PATCH 1/3] entry: Check that syscall entries and syscall exits match
If arch code calls the wrong kernel entry helpers, syscall entries and
exits can get out of sync. Add a new field to task_struct to track the
syscall state and validate that it transitions correctly.
Signed-off-by: Andy Lutomirski
---
I'm not in love with this patch. I'm imagining moving TS_COMPAT and such
into the new kentry_syscall_state field. What do you all think?
include/linux/entry-common.h | 11 +++
include/linux/sched.h| 1 +
init/init_task.c | 9 +
kernel/entry/common.c| 25 -
4 files changed, 45 insertions(+), 1 deletion(-)
diff --git a/include/linux/entry-common.h b/include/linux/entry-common.h
index ca86a00abe86..c2463b6b71fe 100644
--- a/include/linux/entry-common.h
+++ b/include/linux/entry-common.h
@@ -60,6 +60,17 @@
_TIF_NEED_RESCHED | _TIF_PATCH_PENDING | _TIF_NOTIFY_SIGNAL | \
ARCH_EXIT_TO_USER_MODE_WORK)
+/*
+ * task_struct::kentry_syscall_state
+ *
+ * kentry_syscall_state is reset to zero on syscall exit. For efficiency
+ * reasons, if CONFIG_PROVE_LOCKING=n, kentry_syscall_state is permitted
+ * to remain 0 even inside a syscall.
+ */
+#ifdef CONFIG_PROVE_LOCKING
+# define KENTRY_SYSCALL_STATE_IN_SYSCALL 1
+#endif
+
/**
* arch_check_user_regs - Architecture specific sanity check for user mode regs
* @regs: Pointer to currents pt_regs
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 6e3a5eeec509..691057a3b48d 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1002,6 +1002,7 @@ struct task_struct {
#endif
struct seccomp seccomp;
struct syscall_user_dispatchsyscall_dispatch;
+ u32 kentry_syscall_state;
/* Thread group tracking: */
u64 parent_exec_id;
diff --git a/init/init_task.c b/init/init_task.c
index 8a992d73e6fb..91050c4f0bb3 100644
--- a/init/init_task.c
+++ b/init/init_task.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
@@ -212,6 +213,14 @@ struct task_struct init_task
#ifdef CONFIG_SECCOMP
.seccomp= { .filter_count = ATOMIC_INIT(0) },
#endif
+#ifdef CONFIG_PROVE_LOCKING
+ /*
+* The init task, and kernel threads in general, are considered
+* to be "in a syscall". This way they can execve() and then exit
+* the supposed syscall that they were in to go to user mode.
+*/
+ .kentry_syscall_state = KENTRY_SYSCALL_STATE_IN_SYSCALL,
+#endif
};
EXPORT_SYMBOL(init_task);
diff --git a/kernel/entry/common.c b/kernel/entry/common.c
index 378341642f94..7e971b866ad2 100644
--- a/kernel/entry/common.c
+++ b/kernel/entry/common.c
@@ -83,7 +83,16 @@ static long syscall_trace_enter(struct pt_regs *regs, long
syscall,
static __always_inline long
__syscall_enter_from_user_work(struct pt_regs *regs, long syscall)
{
- unsigned long work = READ_ONCE(current_thread_info()->syscall_work);
+ unsigned long work;
+
+ if (IS_ENABLED(CONFIG_PROVE_LOCKING)) {
+ WARN_ONCE(current->kentry_syscall_state,
+ "entering syscall %ld while already in a syscall",
+ syscall);
+ current->kentry_syscall_state = KENTRY_SYSCALL_STATE_IN_SYSCALL;
+ }
+
+ work = READ_ONCE(current_thread_info()->syscall_work);
if (work & SYSCALL_WORK_ENTER)
syscall = syscall_trace_enter(regs, syscall, work);
@@ -195,6 +204,12 @@ static void exit_to_user_mode_prepare(struct pt_regs *regs)
{
unsigned long ti_work = READ_ONCE(current_thread_info()->flags);
+ if (IS_ENABLED(CONFIG_PROVE_LOCKING)) {
+ WARN_ONCE(current->kentry_syscall_state &
+ KENTRY_SYSCALL_STATE_IN_SYSCALL,
+ "exiting to user mode while in syscall context");
+ }
+
lockdep_assert_irqs_disabled();
if (unlikely(ti_work & EXIT_TO_USER_MODE_WORK))
@@ -282,6 +297,14 @@ static void syscall_exit_to_user_mode_prepare(struct
pt_regs *regs)
*/
if (unlikely(work & SYSCALL_WORK_EXIT))
syscall_exit_work(regs, work);
+
+ if (IS_ENABLED(CONFIG_PROVE_LOCKING)) {
+ WARN_ONCE(!(current->kentry_syscall_state &
+ KENTRY_SYSCALL_STATE_IN_SYSCALL),
+ "exiting syscall %lu without entering first", nr);
+ }
+
+ current->kentry_syscall_state = 0;
}
static __always_inline void __syscall_exit_to_user_mode_work(struct pt_regs
*regs)
--
2.29.2
[PATCH 2/3] x86/entry: Fix entry/exit mismatch on failed fast 32-bit syscalls
On a 32-bit fast syscall that fails to read its arguments from user
memory, the kernel currently does syscall exit work but not
syscall exit work. This would confuse audit and ptrace.
This is a minimal fix intended for ease of backporting. A more
complete cleanup is coming.
Cc: sta...@vger.kernel.org
Fixes: 0b085e68f407 ("x86/entry: Consolidate 32/64 bit syscall entry")
Signed-off-by: Andy Lutomirski
---
arch/x86/entry/common.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
index 0904f5676e4d..cf4dcf346ca8 100644
--- a/arch/x86/entry/common.c
+++ b/arch/x86/entry/common.c
@@ -128,7 +128,8 @@ static noinstr bool __do_fast_syscall_32(struct pt_regs
*regs)
regs->ax = -EFAULT;
instrumentation_end();
- syscall_exit_to_user_mode(regs);
+ local_irq_disable();
+ exit_to_user_mode();
return false;
}
--
2.29.2
[PATCH 1/1] vsprintf: dump full information of page flags in pGp fix
The name of the flag should be printed using default_str_spec. There's no difference in the output after this change because the string is printed as-is with both default_dec_spec and default_flag_spec. This patch is a followup of the patchset "mm, vsprintf: dump full information of page flags in pGp" [1] [1]. https://lore.kernel.org/linux-mm/20210215155141.47432-1-laoar.s...@gmail.com/ Signed-off-by: Yafang Shao Cc: Petr Mladek Cc: Matthew Wilcox Cc: Andy Shevchenko Cc: Vlastimil Babka Cc: Miaohe Lin Cc: Joe Perches Cc: David Hildenbrand --- lib/vsprintf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/vsprintf.c b/lib/vsprintf.c index 533ac5404180..5d034e799c06 100644 --- a/lib/vsprintf.c +++ b/lib/vsprintf.c @@ -1963,7 +1963,7 @@ char *format_page_flags(char *buf, char *end, unsigned long flags) buf++; } - buf = string(buf, end, p->name, *p->spec); + buf = string(buf, end, p->name, default_str_spec); if (buf < end) *buf = '='; buf++; -- 2.17.1
[PATCH 0/3] x86/entry: A compat syscall bugfix and some test stuff
The compat syscall argument fixup error path is wrong. Fix it. This also adds some sanity checks to the kernel that catch the bug when running selftests. Andy Lutomirski (3): entry: Check that syscall entries and syscall exits match x86/entry: Fix entry/exit mismatch on failed fast 32-bit syscalls selftests/x86: Add a missing .note.GNU-stack section to thunks_32.S arch/x86/entry/common.c | 3 ++- include/linux/entry-common.h| 11 +++ include/linux/sched.h | 1 + init/init_task.c| 9 + kernel/entry/common.c | 25 - tools/testing/selftests/x86/thunks_32.S | 2 ++ 6 files changed, 49 insertions(+), 2 deletions(-) -- 2.29.2
[PATCH 3/3] selftests/x86: Add a missing .note.GNU-stack section to thunks_32.S
test_syscall_vdso_32 ended up with an executable stacks because the asm was
missing the annotation that says that it is modern and doesn't need an
executable stack. Add the annotation.
This was missed in commit aeaaf005da1d ("selftests/x86: Add missing
.note.GNU-stack sections").
Signed-off-by: Andy Lutomirski
---
tools/testing/selftests/x86/thunks_32.S | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/testing/selftests/x86/thunks_32.S
b/tools/testing/selftests/x86/thunks_32.S
index a71d92da8f46..f3f56e681e9f 100644
--- a/tools/testing/selftests/x86/thunks_32.S
+++ b/tools/testing/selftests/x86/thunks_32.S
@@ -45,3 +45,5 @@ call64_from_32:
ret
.size call64_from_32, .-call64_from_32
+
+.section .note.GNU-stack,"",%progbits
--
2.29.2
