Re: [PATCH] ALSA: aoa: i2sbus: fix possible memory leak in i2sbus_add_dev()
On Thu, 27 Oct 2022 03:34:38 +0200,
Yang Yingliang wrote:
>
> dev_set_name() in soundbus_add_one() allocates memory for name, it need be
> freed when of_device_register() fails, call soundbus_dev_put() to give up
> the reference that hold in device_initialize(), so that it can be freed in
> kobject_cleanup() when the refcount hit to 0. And other resources are also
> freed in i2sbus_release_dev(), so it can return 0 directly.
>
> Fixes: f3d9478b2ce4 ("[ALSA] snd-aoa: add snd-aoa")
> Signed-off-by: Yang Yingliang
The check of kobj state is awkward, but it seems to be the simplest
way... Applied now. Thanks!
Takashi
> ---
> sound/aoa/soundbus/i2sbus/core.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/sound/aoa/soundbus/i2sbus/core.c
> b/sound/aoa/soundbus/i2sbus/core.c
> index faf6b03131ee..f6841daf9e3b 100644
> --- a/sound/aoa/soundbus/i2sbus/core.c
> +++ b/sound/aoa/soundbus/i2sbus/core.c
> @@ -302,6 +302,10 @@ static int i2sbus_add_dev(struct macio_dev *macio,
>
> if (soundbus_add_one(&dev->sound)) {
> printk(KERN_DEBUG "i2sbus: device registration error!\n");
> + if (dev->sound.ofdev.dev.kobj.state_initialized) {
> + soundbus_dev_put(&dev->sound);
> + return 0;
> + }
> goto err;
> }
>
> --
> 2.25.1
>
[PATCH 2/3] ASoC: fsl_sai: Add support for i.MX93 platform
Add compatible string and specific soc data to support SAI on i.MX93
platform.
Signed-off-by: Chancel Liu
---
sound/soc/fsl/fsl_sai.c | 12
1 file changed, 12 insertions(+)
diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index 81f89f6767a2..68e1cc4c369a 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -1579,6 +1579,17 @@ static const struct fsl_sai_soc_data
fsl_sai_imx8ulp_data = {
.max_register = FSL_SAI_RTCAP,
};
+static const struct fsl_sai_soc_data fsl_sai_imx93_data = {
+ .use_imx_pcm = true,
+ .use_edma = true,
+ .fifo_depth = 128,
+ .reg_offset = 8,
+ .mclk0_is_mclk1 = false,
+ .pins = 4,
+ .flags = 0,
+ .max_register = FSL_SAI_MCTL,
+};
+
static const struct of_device_id fsl_sai_ids[] = {
{ .compatible = "fsl,vf610-sai", .data = &fsl_sai_vf610_data },
{ .compatible = "fsl,imx6sx-sai", .data = &fsl_sai_imx6sx_data },
@@ -1590,6 +1601,7 @@ static const struct of_device_id fsl_sai_ids[] = {
{ .compatible = "fsl,imx8mp-sai", .data = &fsl_sai_imx8mp_data },
{ .compatible = "fsl,imx8ulp-sai", .data = &fsl_sai_imx8ulp_data },
{ .compatible = "fsl,imx8mn-sai", .data = &fsl_sai_imx8mp_data },
+ { .compatible = "fsl,imx93-sai", .data = &fsl_sai_imx93_data },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, fsl_sai_ids);
--
2.25.1
[PATCH 3/3] ASoC: fsl_sai: Specify the maxburst to 8 on i.MX93 platform
There is a limit to eDMA AXI on i.MX93. Only TCD that has NBYTES in a
multiple of 8bytes can enable scatter-gather. NBYTES is calculated by
bus width times maxburst. On i.MX93 platform the value of maxburst is
specified to 8. It makes sure that NBYTES is a multiple of 8bytes.
Signed-off-by: Chancel Liu
---
sound/soc/fsl/fsl_sai.c | 11 +++
sound/soc/fsl/fsl_sai.h | 1 +
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index 68e1cc4c369a..a0ea27f06997 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -872,10 +872,10 @@ static int fsl_sai_dai_probe(struct snd_soc_dai *cpu_dai)
regmap_update_bits(sai->regmap, FSL_SAI_TCR1(ofs),
FSL_SAI_CR1_RFW_MASK(sai->soc_data->fifo_depth),
- sai->soc_data->fifo_depth - FSL_SAI_MAXBURST_TX);
+ sai->soc_data->fifo_depth -
sai->dma_params_tx.maxburst);
regmap_update_bits(sai->regmap, FSL_SAI_RCR1(ofs),
FSL_SAI_CR1_RFW_MASK(sai->soc_data->fifo_depth),
- FSL_SAI_MAXBURST_RX - 1);
+ sai->dma_params_rx.maxburst - 1);
snd_soc_dai_init_dma_data(cpu_dai, &sai->dma_params_tx,
&sai->dma_params_rx);
@@ -1416,8 +1416,10 @@ static int fsl_sai_probe(struct platform_device *pdev)
sai->dma_params_rx.addr = sai->res->start + FSL_SAI_RDR0;
sai->dma_params_tx.addr = sai->res->start + FSL_SAI_TDR0;
- sai->dma_params_rx.maxburst = FSL_SAI_MAXBURST_RX;
- sai->dma_params_tx.maxburst = FSL_SAI_MAXBURST_TX;
+ sai->dma_params_rx.maxburst =
+ sai->soc_data->max_burst[RX] ? sai->soc_data->max_burst[RX] :
FSL_SAI_MAXBURST_RX;
+ sai->dma_params_tx.maxburst =
+ sai->soc_data->max_burst[TX] ? sai->soc_data->max_burst[TX] :
FSL_SAI_MAXBURST_TX;
sai->pinctrl = devm_pinctrl_get(&pdev->dev);
@@ -1588,6 +1590,7 @@ static const struct fsl_sai_soc_data fsl_sai_imx93_data =
{
.pins = 4,
.flags = 0,
.max_register = FSL_SAI_MCTL,
+ .max_burst = {8, 8},
};
static const struct of_device_id fsl_sai_ids[] = {
diff --git a/sound/soc/fsl/fsl_sai.h b/sound/soc/fsl/fsl_sai.h
index 697f6690068c..197748a888d5 100644
--- a/sound/soc/fsl/fsl_sai.h
+++ b/sound/soc/fsl/fsl_sai.h
@@ -235,6 +235,7 @@ struct fsl_sai_soc_data {
unsigned int reg_offset;
unsigned int flags;
unsigned int max_register;
+ unsigned int max_burst[2];
};
/**
--
2.25.1
[PATCH 1/3] ASoC: dt-bindings: fsl,sai: Add compatible string for i.MX93 platform
Add compatible string "fsl,imx93-sai" for i.MX93 platform Signed-off-by: Chancel Liu --- Documentation/devicetree/bindings/sound/fsl,sai.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/sound/fsl,sai.yaml b/Documentation/devicetree/bindings/sound/fsl,sai.yaml index 70c4111d59c7..11aab891288d 100644 --- a/Documentation/devicetree/bindings/sound/fsl,sai.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,sai.yaml @@ -26,6 +26,7 @@ properties: - fsl,imx8mq-sai - fsl,imx8qm-sai - fsl,imx8ulp-sai + - fsl,imx93-sai - items: - enum: - fsl,imx8mm-sai -- 2.25.1
[PATCH 0/3] Add support for SAI on i.MX93 platform
This patchset supports SAI on i.MX93 platform. Chancel Liu (3): ASoC: dt-bindings: fsl,sai: Add compatible string for i.MX93 platform ASoC: fsl_sai: Add support for i.MX93 platform ASoC: fsl_sai: Specify the maxburst to 8 on i.MX93 platform .../devicetree/bindings/sound/fsl,sai.yaml| 1 + sound/soc/fsl/fsl_sai.c | 23 +++ sound/soc/fsl/fsl_sai.h | 1 + 3 files changed, 21 insertions(+), 4 deletions(-) -- 2.25.1
[powerpc:merge] BUILD SUCCESS 53c607b08cd6ab06168560e2c830b356a066a13e
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge branch HEAD: 53c607b08cd6ab06168560e2c830b356a066a13e Automatic merge of 'fixes' into merge (2022-10-24 15:06) elapsed time: 4130m configs tested: 91 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: um i386_defconfig um x86_64_defconfig powerpc allnoconfig powerpc allmodconfig mips allyesconfig sh allmodconfig arc defconfig s390 allmodconfig alpha defconfig s390defconfig x86_64 rhel-8.3-func s390 allyesconfig i386defconfig arc allyesconfig x86_64rhel-8.3-kselftests x86_64 allyesconfig x86_64 rhel-8.3-syz alphaallyesconfig x86_64 rhel-8.3 m68k allyesconfig x86_64 rhel-8.3-kunit m68k allmodconfig x86_64 defconfig x86_64 rhel-8.3-kvm i386 allyesconfig arm defconfig x86_64randconfig-a013 x86_64randconfig-a011 x86_64randconfig-a015 i386 randconfig-a015-20221024 i386 randconfig-a016-20221024 ia64 allmodconfig arm allyesconfig arm64allyesconfig arc randconfig-r043-20221023 arc randconfig-r043-20221024 s390 randconfig-r044-20221024 riscvrandconfig-r042-20221024 i386 randconfig-a011-20221024 i386 randconfig-a014-20221024 i386 randconfig-a012-20221024 i386 randconfig-a013-20221024 x86_64 randconfig-a014-20221024 x86_64 randconfig-a015-20221024 x86_64 randconfig-a016-20221024 x86_64 randconfig-a013-20221024 x86_64 randconfig-a012-20221024 x86_64 randconfig-a011-20221024 i386 randconfig-a012 i386 randconfig-a014 i386 randconfig-a016 arc randconfig-r043-20221025 arc randconfig-r043-20221026 s390 randconfig-r044-20221026 riscvrandconfig-r042-20221026 x86_64randconfig-a004 x86_64randconfig-a002 x86_64randconfig-a006 i386 randconfig-a001 i386 randconfig-a003 i386 randconfig-a005 clang tested configs: x86_64 randconfig-a001-20221024 x86_64 randconfig-a003-20221024 x86_64 randconfig-a002-20221024 x86_64 randconfig-a005-20221024 x86_64 randconfig-a006-20221024 x86_64 randconfig-a004-20221024 i386 randconfig-a001-20221024 i386 randconfig-a002-20221024 i386 randconfig-a005-20221024 i386 randconfig-a003-20221024 x86_64randconfig-a012 i386 randconfig-a004-20221024 i386 randconfig-a006-20221024 x86_64randconfig-a016 x86_64randconfig-a014 s390 randconfig-r044-20221023 hexagon randconfig-r041-20221023 riscvrandconfig-r042-20221023 hexagon randconfig-r045-20221023 x86_64randconfig-a005 x86_64randconfig-a003 x86_64randconfig-a001 hexagon randconfig-r045-20221026 i386 randconfig-a002 i386 randconfig-a004 hexagon randconfig-r041-20221026 i386 randconfig-a006 i386 randconfig-a013 i386 randconfig-a015 i386 randconfig-a011 -- 0-DAY CI Kernel Test Service https://01.org/lkp
[powerpc:fixes-test] BUILD SUCCESS 65722736c3baf29e02e964a09e85c9ef71c48e8d
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test branch HEAD: 65722736c3baf29e02e964a09e85c9ef71c48e8d powerpc/64s/interrupt: Fix clear of PACA_IRQS_HARD_DIS when returning to soft-masked context elapsed time: 724m configs tested: 73 configs skipped: 108 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: powerpc allnoconfig powerpc allmodconfig um x86_64_defconfig um i386_defconfig x86_64 defconfig x86_64 allyesconfig x86_64 rhel-8.3 x86_64 rhel-8.3-kvm x86_64 rhel-8.3-syz x86_64 rhel-8.3-kunit m68k allyesconfig m68k allmodconfig arc allyesconfig alphaallyesconfig i386 randconfig-a012 i386 randconfig-a014 i386 randconfig-a016 i386 allyesconfig i386defconfig x86_64randconfig-a006 x86_64randconfig-a004 x86_64randconfig-a002 armkeystone_defconfig powerpc stx_gp3_defconfig arm axm55xx_defconfig powerpc redwood_defconfig sh rts7751r2d1_defconfig mipsvocore2_defconfig mips allyesconfig sh allmodconfig s390defconfig s390 allmodconfig arc defconfig alpha defconfig s390 allyesconfig arm h5000_defconfig m68k hp300_defconfig alphaalldefconfig ia64 allmodconfig arc randconfig-r043-20221026 s390 randconfig-r044-20221026 riscvrandconfig-r042-20221026 arm64allyesconfig arm defconfig arm allyesconfig m68kq40_defconfig arm imxrt_defconfig arm assabet_defconfig arm gemini_defconfig mipsar7_defconfig archsdk_defconfig arm ezx_defconfig shmigor_defconfig nios2 3c120_defconfig sparc defconfig arc alldefconfig armpleb_defconfig mips maltasmvp_defconfig x86_64 rhel-8.3-func x86_64rhel-8.3-kselftests clang tested configs: i386 randconfig-a002 i386 randconfig-a006 i386 randconfig-a004 x86_64randconfig-a012 x86_64randconfig-a014 x86_64randconfig-a016 arm pxa168_defconfig powerpc mpc8560_ads_defconfig x86_64randconfig-a005 x86_64randconfig-a003 x86_64randconfig-a001 powerpc pmac32_defconfig mips bmips_stb_defconfig -- 0-DAY CI Kernel Test Service https://01.org/lkp
[powerpc:fixes] BUILD SUCCESS e59b3399fde5e173b026d4952b215043e77b4521
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes branch HEAD: e59b3399fde5e173b026d4952b215043e77b4521 KVM: PPC: BookS PR-KVM and BookE do not support context tracking elapsed time: 724m configs tested: 73 configs skipped: 108 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: powerpc allnoconfig powerpc allmodconfig um x86_64_defconfig um i386_defconfig x86_64 defconfig x86_64 allyesconfig x86_64 rhel-8.3 x86_64 rhel-8.3-kvm x86_64 rhel-8.3-syz x86_64 rhel-8.3-kunit m68k allyesconfig m68k allmodconfig arc allyesconfig alphaallyesconfig i386 randconfig-a012 i386 randconfig-a014 i386 randconfig-a016 i386 allyesconfig i386defconfig x86_64randconfig-a006 x86_64randconfig-a004 x86_64randconfig-a002 armkeystone_defconfig powerpc stx_gp3_defconfig arm axm55xx_defconfig powerpc redwood_defconfig sh rts7751r2d1_defconfig mipsvocore2_defconfig mips allyesconfig sh allmodconfig s390defconfig s390 allmodconfig arc defconfig alpha defconfig s390 allyesconfig arm h5000_defconfig m68k hp300_defconfig alphaalldefconfig ia64 allmodconfig arc randconfig-r043-20221026 s390 randconfig-r044-20221026 riscvrandconfig-r042-20221026 m68kq40_defconfig arm imxrt_defconfig arm assabet_defconfig arm gemini_defconfig arm64allyesconfig arm defconfig arm allyesconfig mipsar7_defconfig archsdk_defconfig arm ezx_defconfig shmigor_defconfig nios2 3c120_defconfig sparc defconfig arc alldefconfig armpleb_defconfig mips maltasmvp_defconfig x86_64 rhel-8.3-func x86_64rhel-8.3-kselftests clang tested configs: i386 randconfig-a002 i386 randconfig-a006 i386 randconfig-a004 x86_64randconfig-a012 x86_64randconfig-a014 x86_64randconfig-a016 arm pxa168_defconfig powerpc mpc8560_ads_defconfig x86_64randconfig-a005 x86_64randconfig-a003 x86_64randconfig-a001 powerpc pmac32_defconfig mips bmips_stb_defconfig -- 0-DAY CI Kernel Test Service https://01.org/lkp
[PATCH] ALSA: aoa: i2sbus: fix possible memory leak in i2sbus_add_dev()
dev_set_name() in soundbus_add_one() allocates memory for name, it need be
freed when of_device_register() fails, call soundbus_dev_put() to give up
the reference that hold in device_initialize(), so that it can be freed in
kobject_cleanup() when the refcount hit to 0. And other resources are also
freed in i2sbus_release_dev(), so it can return 0 directly.
Fixes: f3d9478b2ce4 ("[ALSA] snd-aoa: add snd-aoa")
Signed-off-by: Yang Yingliang
---
sound/aoa/soundbus/i2sbus/core.c | 4
1 file changed, 4 insertions(+)
diff --git a/sound/aoa/soundbus/i2sbus/core.c b/sound/aoa/soundbus/i2sbus/core.c
index faf6b03131ee..f6841daf9e3b 100644
--- a/sound/aoa/soundbus/i2sbus/core.c
+++ b/sound/aoa/soundbus/i2sbus/core.c
@@ -302,6 +302,10 @@ static int i2sbus_add_dev(struct macio_dev *macio,
if (soundbus_add_one(&dev->sound)) {
printk(KERN_DEBUG "i2sbus: device registration error!\n");
+ if (dev->sound.ofdev.dev.kobj.state_initialized) {
+ soundbus_dev_put(&dev->sound);
+ return 0;
+ }
goto err;
}
--
2.25.1
Re: [PATCH v3] hugetlb: simplify hugetlb handling in follow_page_mask
On 10/26/22 17:59, Peter Xu wrote:
> Hi, Mike,
>
> On Sun, Sep 18, 2022 at 07:13:48PM -0700, Mike Kravetz wrote:
> > +struct page *hugetlb_follow_page_mask(struct vm_area_struct *vma,
> > + unsigned long address, unsigned int flags)
> > +{
> > + struct hstate *h = hstate_vma(vma);
> > + struct mm_struct *mm = vma->vm_mm;
> > + unsigned long haddr = address & huge_page_mask(h);
> > + struct page *page = NULL;
> > + spinlock_t *ptl;
> > + pte_t *pte, entry;
> > +
> > + /*
> > +* FOLL_PIN is not supported for follow_page(). Ordinary GUP goes via
> > +* follow_hugetlb_page().
> > +*/
> > + if (WARN_ON_ONCE(flags & FOLL_PIN))
> > + return NULL;
> > +
> > +retry:
> > + /*
> > +* vma lock prevents racing with another thread doing a pmd unshare.
> > +* This keeps pte as returned by huge_pte_offset valid.
> > +*/
> > + hugetlb_vma_lock_read(vma);
>
> I'm not sure whether it's okay to take a rwsem here, as the code can be
> called by e.g. FOLL_NOWAIT?
I think you are right. This is possible even thought not called this
way today,
> I'm wondering whether it's fine to just drop this anyway, just always walk
> it lockless. IIUC gup callers should be safe here because the worst case
> is the caller will fetch a wrong page, but then it should be invalidated
> very soon with mmu notifiers. One thing worth mention is that pmd unshare
> should never free a pgtable page.
You are correct in that pmd unshare will not directly free a pgtable page.
However, I think a 'very worst case' race could be caused by two threads(1,2)
in the same process A, and another process B. Processes A and B share a PMD.
- Process A thread 1 gets a *ptep via huge_pte_offset and gets scheduled out.
- Process A thread 2 calls mprotect to change protection and unshares
the PMD shared with process B.
- Process B then unmaps the PMD shared with process A and the PMD page
gets deleted.
- The *ptep in Process A thread 1 then points into a freed page.
This is VERY unlikely, but I do think it is possible and is the reason I
may be overcautious about protecting against races with pmd unshare.
--
Mike Kravetz
>
> IIUC it's also the same as fast-gup - afaiu we don't take the read vma lock
> in fast-gup too but I also think it's safe. But I hope I didn't miss
> something.
>
> --
> Peter Xu
>
Re: [PATCH v3] hugetlb: simplify hugetlb handling in follow_page_mask
Hi, Mike,
On Sun, Sep 18, 2022 at 07:13:48PM -0700, Mike Kravetz wrote:
> +struct page *hugetlb_follow_page_mask(struct vm_area_struct *vma,
> + unsigned long address, unsigned int flags)
> +{
> + struct hstate *h = hstate_vma(vma);
> + struct mm_struct *mm = vma->vm_mm;
> + unsigned long haddr = address & huge_page_mask(h);
> + struct page *page = NULL;
> + spinlock_t *ptl;
> + pte_t *pte, entry;
> +
> + /*
> + * FOLL_PIN is not supported for follow_page(). Ordinary GUP goes via
> + * follow_hugetlb_page().
> + */
> + if (WARN_ON_ONCE(flags & FOLL_PIN))
> + return NULL;
> +
> +retry:
> + /*
> + * vma lock prevents racing with another thread doing a pmd unshare.
> + * This keeps pte as returned by huge_pte_offset valid.
> + */
> + hugetlb_vma_lock_read(vma);
I'm not sure whether it's okay to take a rwsem here, as the code can be
called by e.g. FOLL_NOWAIT?
I'm wondering whether it's fine to just drop this anyway, just always walk
it lockless. IIUC gup callers should be safe here because the worst case
is the caller will fetch a wrong page, but then it should be invalidated
very soon with mmu notifiers. One thing worth mention is that pmd unshare
should never free a pgtable page.
IIUC it's also the same as fast-gup - afaiu we don't take the read vma lock
in fast-gup too but I also think it's safe. But I hope I didn't miss
something.
--
Peter Xu
Re: [RFC PATCH] fs/hugetlb: Fix UBSAN warning reported on hugetlb
On 10/26/22 10:50, Aristeu Rozanski wrote:
> On Thu, Sep 08, 2022 at 10:29:59PM +0530, Aneesh Kumar K V wrote:
> > On 9/8/22 10:23 PM, Matthew Wilcox wrote:
> > > On Thu, Sep 08, 2022 at 12:56:59PM +0530, Aneesh Kumar K.V wrote:
> > >> +++ b/fs/dax.c
> > >> @@ -1304,7 +1304,7 @@ EXPORT_SYMBOL_GPL(dax_zero_range);
> > >> int dax_truncate_page(struct inode *inode, loff_t pos, bool *did_zero,
> > >> const struct iomap_ops *ops)
> > >> {
> > >> -unsigned int blocksize = i_blocksize(inode);
> > >> +size_t blocksize = i_blocksize(inode);
> > >> unsigned int off = pos & (blocksize - 1);
> > >
> > > If blocksize is larger than 4GB, then off also needs to be size_t.
> > >
> > >> +++ b/fs/iomap/buffered-io.c
> > >> @@ -955,7 +955,7 @@ int
> > >> iomap_truncate_page(struct inode *inode, loff_t pos, bool *did_zero,
> > >> const struct iomap_ops *ops)
> > >> {
> > >> -unsigned int blocksize = i_blocksize(inode);
> > >> +size_t blocksize = i_blocksize(inode);
> > >> unsigned int off = pos & (blocksize - 1);
> > >
> > > Ditto.
> > >
> > > (maybe there are others; I didn't check closely)
> >
> > Thanks. will check those.
> >
> > Any feedback on statx? Should we really fix that?
> >
> > I am still not clear why we chose to set blocksize = pagesize for hugetlbfs.
> > Was that done to enable application find the hugetlb pagesize via stat()?
>
> I'd like to know that as well. It'd be easier to just limit the hugetlbfs max
> blocksize to 4GB. It's very unlikely anything else will use such large
> blocksizes and having to introduce new user interfaces for it doesn't sound
> right.
I was not around hugetlbfs when the decision was made to set 'blocksize =
pagesize'. However, I must say that it does seem to make sense as you
can only add or remove entire hugetlb pages from a hugetlbfs file. So,
the hugetlb page size does seem to correspond to the meaning of filesystem
blocksize.
Does any application code make use of this? I can not make a guess.
--
Mike Kravetz
[PATCH] ibmvfc: Avoid path failures during live migration
This patch fixes an issue reported when performing a live
migration when multipath is configured with a short fast
fail timeout of 5 seconds and also to have no_path_retry
set to fail. In this scenario, all paths would go into the
devloss state while the ibmvfc driver went through discovery
to log back in. On a loaded system, the discovery might
take longer than 5 seconds, which was resulting in all paths
being marked failed, which then resulted in a read only filesystem.
This patch changes the migration code in ibmvfc to
avoid deleting rports at all in this scenario, so we
avoid losing all paths.
Signed-off-by: Brian King
---
drivers/scsi/ibmvscsi/ibmvfc.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
index 00684e11976b..1a0c0b7289d2 100644
--- a/drivers/scsi/ibmvscsi/ibmvfc.c
+++ b/drivers/scsi/ibmvscsi/ibmvfc.c
@@ -708,8 +708,13 @@ static void ibmvfc_init_host(struct ibmvfc_host *vhost)
memset(vhost->async_crq.msgs.async, 0, PAGE_SIZE);
vhost->async_crq.cur = 0;
- list_for_each_entry(tgt, &vhost->targets, queue)
- ibmvfc_del_tgt(tgt);
+ list_for_each_entry(tgt, &vhost->targets, queue) {
+ if (vhost->client_migrated)
+ tgt->need_login = 1;
+ else
+ ibmvfc_del_tgt(tgt);
+ }
+
scsi_block_requests(vhost->host);
ibmvfc_set_host_action(vhost, IBMVFC_HOST_ACTION_INIT);
vhost->job_step = ibmvfc_npiv_login;
@@ -3235,9 +3240,12 @@ static void ibmvfc_handle_crq(struct ibmvfc_crq *crq,
struct ibmvfc_host *vhost,
/* We need to re-setup the interpartition connection */
dev_info(vhost->dev, "Partition migrated, Re-enabling
adapter\n");
vhost->client_migrated = 1;
+
+ scsi_block_requests(vhost->host);
ibmvfc_purge_requests(vhost, DID_REQUEUE);
- ibmvfc_link_down(vhost, IBMVFC_LINK_DOWN);
+ ibmvfc_set_host_state(vhost, IBMVFC_LINK_DOWN);
ibmvfc_set_host_action(vhost,
IBMVFC_HOST_ACTION_REENABLE);
+ wake_up(&vhost->work_wait_q);
} else if (crq->format == IBMVFC_PARTNER_FAILED || crq->format
== IBMVFC_PARTNER_DEREGISTER) {
dev_err(vhost->dev, "Host partner adapter deregistered
or failed (rc=%d)\n", crq->format);
ibmvfc_purge_requests(vhost, DID_ERROR);
--
2.31.1
Re: [PATCH] powerpc: replace ternary operator with min()
Hi KaiLong,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on linus/master v6.1-rc2 next-20221026]
[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#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/KaiLong-Wang/powerpc-replace-ternary-operator-with-min/20221023-204906
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
patch link:
https://lore.kernel.org/r/4ebda26c.346.18404df6852.Coremail.wangkailong%40jari.cn
patch subject: [PATCH] powerpc: replace ternary operator with min()
config: powerpc-ppc64e_defconfig (attached as .config)
compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project
791a7ae1ba3efd6bca96338e10ffde557ba83920)
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 powerpc cross compiling tool for clang build
# apt-get install binutils-powerpc-linux-gnu
#
https://github.com/intel-lab-lkp/linux/commit/51fa624eb9fa01ea67de462263913ab61a68cbc5
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
KaiLong-Wang/powerpc-replace-ternary-operator-with-min/20221023-204906
git checkout 51fa624eb9fa01ea67de462263913ab61a68cbc5
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=powerpc SHELL=/bin/bash
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> arch/powerpc/xmon/xmon.c:2583:7: error: comparison of distinct pointer types
>> ('typeof (n) *' (aka 'long *') and 'typeof (16) *' (aka 'int *'))
>> [-Werror,-Wcompare-distinct-pointer-types]
r = min(n, 16);
^~
include/linux/minmax.h:45:19: note: expanded from macro 'min'
#define min(x, y) __careful_cmp(x, y, <)
^~
include/linux/minmax.h:36:24: note: expanded from macro '__careful_cmp'
__builtin_choose_expr(__safe_cmp(x, y), \
^~~~
include/linux/minmax.h:26:4: note: expanded from macro '__safe_cmp'
(__typecheck(x, y) && __no_side_effects(x, y))
^
include/linux/minmax.h:20:28: note: expanded from macro '__typecheck'
(!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
~~ ^ ~~
arch/powerpc/xmon/xmon.c:2987:7: error: comparison of distinct pointer types
('typeof (n) *' (aka 'long *') and 'typeof (16) *' (aka 'int *'))
[-Werror,-Wcompare-distinct-pointer-types]
r = min(n, 16);
^~
include/linux/minmax.h:45:19: note: expanded from macro 'min'
#define min(x, y) __careful_cmp(x, y, <)
^~
include/linux/minmax.h:36:24: note: expanded from macro '__careful_cmp'
__builtin_choose_expr(__safe_cmp(x, y), \
^~~~
include/linux/minmax.h:26:4: note: expanded from macro '__safe_cmp'
(__typecheck(x, y) && __no_side_effects(x, y))
^
include/linux/minmax.h:20:28: note: expanded from macro '__typecheck'
(!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
~~ ^ ~~
2 errors generated.
vim +2583 arch/powerpc/xmon/xmon.c
2576
2577 static void xmon_rawdump (unsigned long adrs, long ndump)
2578 {
2579 long n, m, r, nr;
2580 unsigned char temp[16];
2581
2582 for (n = ndump; n > 0;) {
> 2583 r = min(n, 16);
2584 nr = mread(adrs, temp, r);
2585 adrs += nr;
2586 for (m = 0; m < r; ++m) {
2587 if (m < nr)
2588 printf("%.2x", temp[m]);
2589 else
2590 printf("%s", fault_chars[fault_type]);
2591 }
2592 n -= r;
2593 if (nr < r)
2594 break;
2595 }
2596 printf("\n");
2597 }
2598
--
0-DAY CI Kernel Test Service
https://01.org/lkp
.config.gz
Description: application/gzip
Re: sched/debug: CPU hotplug operation suffers in a large cpu systems
On Tue, Oct 18, 2022 at 01:04:40PM +0200, Greg Kroah-Hartman wrote: > Why do you need to? What tools require these debugfs files to be > present? We are not entirely sure what applications (if any) might be using this interface. > And if you only have 7-8 files per CPU, that does not seem like a lot of > files overall (14000-16000)? If you only offline 1 cpu, how is removing > 7 or 8 files a bottleneck? Do you really offline 1999 cpus for a 2k > system? It's 7-8 files per domain per cpu, so, in a system with approx 2k cpus and five domains, the total file count goes above 70k-80k files. And, when we offline 1 CPU, the entire directory is rebuilt, resulting in creation of all the files again. Thanks -- vishal.c signature.asc Description: PGP signature
Re: sched/debug: CPU hotplug operation suffers in a large cpu systems
On Wed, Oct 26, 2022 at 09:02:28AM +0200, Greg Kroah-Hartman wrote: > On Wed, Oct 26, 2022 at 12:07:01PM +0530, Vishal Chourasia wrote: > > On Tue, Oct 18, 2022 at 01:04:40PM +0200, Greg Kroah-Hartman wrote: > > > > > Why do you need to? What tools require these debugfs files to be > > > present? > > > > We are not entirely sure what applications (if any) might be using this > > interface. > > Then just disable it and see what happens :) It's mostly a debug interface for developers. A lot of people complained when I moved things to debugfs, and I told them their program was broken for a SCHED_DEBUG=n build anyway, but nobody complained about this particular thing IIRC. It's mostly affected by things like hotplug and cpusets, you can discover the resulting topology by looking at these files. Also; while we generally try and keep SCHED_DEBUG impact low, it is still measurable; there are a number of people that run SCHED_DEBUG=n kernels for the extra little gain. > > > And if you only have 7-8 files per CPU, that does not seem like a lot of > > > files overall (14000-16000)? If you only offline 1 cpu, how is removing > > > 7 or 8 files a bottleneck? Do you really offline 1999 cpus for a 2k > > > system? > > > > It's 7-8 files per domain per cpu, so, in a system with approx 2k cpus and > > five > > domains, the total file count goes above 70k-80k files. And, when we > > offline 1 > > CPU, the entire directory is rebuilt, resulting in creation of all the files > > again. > > Perhaps change the logic to not rebuild the whole thing and instead just > remove the required files? Unplugging a single cpu can change the topology and the other cpus might need to be updated too. Simplest example would be the SMT case, if you reduce from SMT>1 to SMT1 the SMT domain goes away (because a single CPU domain is as pointless as it sounds) and that affects the CPU that remains. Tracking all that is a pain. Simply rebuilding the whole thing is by *far* the simplest option. And given this all is debug code, simple is good. > Or as I mentioned before, you can move debugfs to use kernfs, which > should resolve most of these issues automatically. Why not take the > time to do that which will solve the problem no matter what gets added > in the future in other subsystems? This sounds like a good approach.
Re: [PATCH net-next] eth: fealnx: delete the driver for Myson MTD-800
On Tue, Oct 25, 2022 at 11:42:54AM -0700, Jakub Kicinski wrote: > The git history for this driver seems to be completely > automated / tree wide changes. I can't find any boards > or systems which would use this chip. Google search > shows pictures of towel warmers and no networking products. > > Signed-off-by: Jakub Kicinski > --- > CC: tsbog...@alpha.franken.de > CC: m...@ellerman.id.au > CC: npig...@gmail.com > CC: christophe.le...@csgroup.eu > CC: lukas.bulw...@gmail.com > CC: a...@arndb.de > CC: step...@networkplumber.org > CC: shay...@amazon.com > CC: l...@kernel.org > CC: m...@semihalf.com > CC: pe...@nvidia.com > CC: wsa+rene...@sang-engineering.com > CC: linux-m...@vger.kernel.org > CC: linuxppc-dev@lists.ozlabs.org > --- > arch/mips/configs/mtx1_defconfig |1 - > arch/powerpc/configs/ppc6xx_defconfig |1 - > drivers/net/ethernet/Kconfig | 10 - > drivers/net/ethernet/Makefile |1 - > drivers/net/ethernet/fealnx.c | 1953 - > 5 files changed, 1966 deletions(-) > delete mode 100644 drivers/net/ethernet/fealnx.c Thanks, Reviewed-by: Leon Romanovsky
[PATCH v2] soc: fsl: qe: Avoid using gpio_to_desc()
We want to get rid of the old GPIO numberspace, so instead of
calling gpio_to_desc() we get the gpio descriptor for the requested
line from the device tree directly without passing through the
GPIO numberspace, and then we get the gpiochip from the descriptor.
Cc: Bartosz Golaszewski
Cc: linux-g...@vger.kernel.org
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Add back the include: we are using the
mm_of_gpio_chip, which should be fixed, but not now.
---
drivers/soc/fsl/qe/gpio.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/soc/fsl/qe/gpio.c b/drivers/soc/fsl/qe/gpio.c
index 99f7de43c3c6..68d48430ab33 100644
--- a/drivers/soc/fsl/qe/gpio.c
+++ b/drivers/soc/fsl/qe/gpio.c
@@ -14,9 +14,8 @@
#include
#include
#include
+#include
#include
-/* FIXME: needed for gpio_to_chip() get rid of this */
-#include
#include
#include
#include
@@ -161,6 +160,7 @@ struct qe_pin *qe_pin_request(struct device_node *np, int
index)
struct qe_pin *qe_pin;
struct gpio_chip *gc;
struct qe_gpio_chip *qe_gc;
+ struct gpio_desc *gpiod;
int err;
unsigned long flags;
@@ -170,14 +170,21 @@ struct qe_pin *qe_pin_request(struct device_node *np, int
index)
return ERR_PTR(-ENOMEM);
}
- err = of_get_gpio(np, index);
- if (err < 0)
+ gpiod = fwnode_gpiod_get_index(of_fwnode_handle(np), NULL, index,
GPIOD_ASIS, "qe");
+ if (IS_ERR(gpiod)) {
+ err = PTR_ERR(gpiod);
goto err0;
- gc = gpio_to_chip(err);
+ }
+ if (!gpiod) {
+ err = -EINVAL;
+ goto err0;
+ }
+ gc = gpiod_to_chip(gpiod);
if (WARN_ON(!gc)) {
err = -ENODEV;
goto err0;
}
+ gpiod_put(gpiod);
if (!of_device_is_compatible(gc->of_node, "fsl,mpc8323-qe-pario-bank"))
{
pr_debug("%s: tried to get a non-qe pin\n", __func__);
--
2.34.1
Re: sched/debug: CPU hotplug operation suffers in a large cpu systems
On Wed, Oct 26, 2022 at 12:07:01PM +0530, Vishal Chourasia wrote: > On Tue, Oct 18, 2022 at 01:04:40PM +0200, Greg Kroah-Hartman wrote: > > > Why do you need to? What tools require these debugfs files to be > > present? > > We are not entirely sure what applications (if any) might be using this > interface. Then just disable it and see what happens :) > > And if you only have 7-8 files per CPU, that does not seem like a lot of > > files overall (14000-16000)? If you only offline 1 cpu, how is removing > > 7 or 8 files a bottleneck? Do you really offline 1999 cpus for a 2k > > system? > > It's 7-8 files per domain per cpu, so, in a system with approx 2k cpus and > five > domains, the total file count goes above 70k-80k files. And, when we offline 1 > CPU, the entire directory is rebuilt, resulting in creation of all the files > again. Perhaps change the logic to not rebuild the whole thing and instead just remove the required files? Or as I mentioned before, you can move debugfs to use kernfs, which should resolve most of these issues automatically. Why not take the time to do that which will solve the problem no matter what gets added in the future in other subsystems? thanks, greg k-h
