Re: [PATCH] Re: KASAN: use-after-free Read in path_init (2)
On Tue, Aug 11, 2020 at 09:29:47PM -0700, Linus Torvalds wrote: > On Tue, Aug 11, 2020 at 9:15 PM Al Viro wrote: > > > > fix breakage in do_rmdir() > > > > putname() should happen only after we'd *not* branched to > > retry, same as it's done in do_unlinkat(). > > Looks obviously correct. > > Do you want me to apply directly, or do you have other fixes pending > and I'll get a pull request? Not at the moment - I can throw it into #fixes and send a pull request if you wish, but there won't be anything else in it...
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:1130 mt7915_mac_sta_stats_work() warn: test_bit() takes a bit number
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: fb893de323e2d39f7a1f6df425703a2edbdf56ea
commit: e57b7901469fc0b021930b83a8094baaf3d81b09 mt76: add mac80211 driver for
MT7915 PCIe-based chipsets
date: 3 months ago
config: parisc-randconfig-m031-20200811 (attached as .config)
compiler: hppa-linux-gcc (GCC) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
smatch warnings:
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:1130
mt7915_mac_sta_stats_work() warn: test_bit() takes a bit number
vim +1130 drivers/net/wireless/mediatek/mt76/mt7915/mac.c
1107
1108 void mt7915_mac_sta_stats_work(struct work_struct *work)
1109 {
1110 struct ieee80211_sta *sta;
struct ieee80211_vif *vif;
1112 struct mt7915_sta_stats *stats;
1113 struct mt7915_sta *msta;
1114 struct mt7915_dev *dev;
1115
1116 msta = container_of(work, struct mt7915_sta, stats_work);
1117 sta = container_of((void *)msta, struct ieee80211_sta,
drv_priv);
1118 vif = container_of((void *)msta->vif, struct ieee80211_vif,
drv_priv);
1119 dev = msta->vif->dev;
1120 stats = >stats;
1121
1122 /* use MT_TX_FREE_RATE to report Tx rate for further devices */
1123 if (time_after(jiffies, stats->jiffies + HZ)) {
1124 mt7915_mcu_get_rate_info(dev, RATE_CTRL_RU_INFO,
1125 msta->wcid.idx);
1126
1127 stats->jiffies = jiffies;
1128 }
1129
> 1130 if (test_and_clear_bit(IEEE80211_RC_SUPP_RATES_CHANGED |
1131 IEEE80211_RC_NSS_CHANGED |
1132 IEEE80211_RC_BW_CHANGED,
>changed))
1133 mt7915_mcu_add_rate_ctrl(dev, vif, sta);
1134
1135 if (test_and_clear_bit(IEEE80211_RC_SMPS_CHANGED,
>changed))
1136 mt7915_mcu_add_smps(dev, vif, sta);
1137
1138 spin_lock_bh(>sta_poll_lock);
1139 if (list_empty(>poll_list))
1140 list_add_tail(>poll_list, >sta_poll_list);
1141 spin_unlock_bh(>sta_poll_lock);
1142 }
1143
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c:224 dwmac_dma_flush_tx_fifo() warn: this loop depends on readl() succeeding
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: fb893de323e2d39f7a1f6df425703a2edbdf56ea
commit: 05933aac7b11911955de307a329dc2a7a14b7bd0 ia64: remove now unused
machvec indirections
date: 12 months ago
config: ia64-randconfig-m031-20200811 (attached as .config)
compiler: ia64-linux-gcc (GCC) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
smatch warnings:
drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c:224 dwmac_dma_flush_tx_fifo()
warn: this loop depends on readl() succeeding
vim +224 drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
aec7ff27814528 drivers/net/stmmac/dwmac_lib.c Giuseppe CAVALLARO 2010-01-06
218
ad01b7d480a4a1 drivers/net/stmmac/dwmac_lib.c Giuseppe CAVALLARO 2010-08-23
219 void dwmac_dma_flush_tx_fifo(void __iomem *ioaddr)
688911c2f5e5e4 drivers/net/stmmac/dwmac_lib.c Giuseppe CAVALLARO 2010-04-13
220 {
688911c2f5e5e4 drivers/net/stmmac/dwmac_lib.c Giuseppe CAVALLARO 2010-04-13
221u32 csr6 = readl(ioaddr + DMA_CONTROL);
688911c2f5e5e4 drivers/net/stmmac/dwmac_lib.c Giuseppe CAVALLARO 2010-04-13
222writel((csr6 | DMA_CONTROL_FTF), ioaddr + DMA_CONTROL);
688911c2f5e5e4 drivers/net/stmmac/dwmac_lib.c Giuseppe CAVALLARO 2010-04-13
223
688911c2f5e5e4 drivers/net/stmmac/dwmac_lib.c Giuseppe CAVALLARO 2010-04-13
@224do {} while ((readl(ioaddr + DMA_CONTROL) & DMA_CONTROL_FTF));
688911c2f5e5e4 drivers/net/stmmac/dwmac_lib.c Giuseppe CAVALLARO 2010-04-13
225 }
aec7ff27814528 drivers/net/stmmac/dwmac_lib.c Giuseppe CAVALLARO 2010-01-06
226
:: The code at line 224 was first introduced by commit
:: 688911c2f5e5e4f33b5a1c32839184f1fdf814ee stmmac: fix Transmit FIFO flush
operation
:: TO: Giuseppe CAVALLARO
:: CC: David S. Miller
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [RFC 0/5] Introduce NMI aware serial drivers
On Tue, 11 Aug 2020 at 20:28, Greg Kroah-Hartman wrote: > > On Tue, Aug 11, 2020 at 07:59:24PM +0530, Sumit Garg wrote: > > Hi Greg, > > > > Thanks for your comments. > > > > On Tue, 11 Aug 2020 at 19:27, Greg Kroah-Hartman > > wrote: > > > > > > On Tue, Aug 11, 2020 at 07:20:26PM +0530, Sumit Garg wrote: > > > > On Tue, 21 Jul 2020 at 17:40, Sumit Garg wrote: > > > > > > > > > > Make it possible for UARTs to trigger magic sysrq from an NMI. With > > > > > the > > > > > advent of pseudo NMIs on arm64 it became quite generic to request > > > > > serial > > > > > device interrupt as an NMI rather than IRQ. And having NMI driven > > > > > serial > > > > > RX will allow us to trigger magic sysrq as an NMI and hence drop into > > > > > kernel debugger in NMI context. > > > > > > > > > > The major use-case is to add NMI debugging capabilities to the kernel > > > > > in order to debug scenarios such as: > > > > > - Primary CPU is stuck in deadlock with interrupts disabled and hence > > > > > doesn't honor serial device interrupt. So having magic sysrq > > > > > triggered > > > > > as an NMI is helpful for debugging. > > > > > - Always enabled NMI based magic sysrq irrespective of whether the > > > > > serial > > > > > TTY port is active or not. > > > > > > > > > > Currently there is an existing kgdb NMI serial driver which provides > > > > > partial implementation in upstream to have a separate ttyNMI0 port but > > > > > that remained in silos with the serial core/drivers which made it a > > > > > bit > > > > > odd to enable using serial device interrupt and hence remained > > > > > unused. It > > > > > seems to be clearly intended to avoid almost all custom NMI changes to > > > > > the UART driver. > > > > > > > > > > But this patch-set allows the serial core/drivers to be NMI aware > > > > > which > > > > > in turn provides NMI debugging capabilities via magic sysrq and hence > > > > > there is no specific reason to keep this special driver. So remove it > > > > > instead. > > > > > > > > > > Approach: > > > > > - > > > > > > > > > > The overall idea is to intercept serial RX characters in NMI context, > > > > > if > > > > > those are specific to magic sysrq then allow corresponding handler to > > > > > run > > > > > in NMI context. Otherwise, defer all other RX and TX operations onto > > > > > IRQ > > > > > work queue in order to run those in normal interrupt context. > > > > > > > > > > This approach is demonstrated using amba-pl011 driver. > > > > > > > > > > Patch-wise description: > > > > > --- > > > > > > > > > > Patch #1 prepares magic sysrq handler to be NMI aware. > > > > > Patch #2 adds NMI framework to serial core. > > > > > Patch #3 and #4 demonstrates NMI aware uart port using amba-pl011 > > > > > driver. > > > > > Patch #5 removes kgdb NMI serial driver. > > > > > > > > > > Goal of this RFC: > > > > > - > > > > > > > > > > My main reason for sharing this as an RFC is to help decide whether or > > > > > not to continue with this approach. The next step for me would to port > > > > > the work to a system with an 8250 UART. > > > > > > > > > > > > > A gentle reminder to seek feedback on this series. > > > > > > It's the middle of the merge window, and I can't do anything. > > > > > > Also, I almost never review RFC patches as I have have way too many > > > patches that people think are "right" to review first... > > > > > > > Okay, I understand and I can definitely wait for your feedback. > > My feedback here is this: > > > > I suggest you work to flesh this out first and submit something that you > > > feels works properly. > > :) > > > IIUC, in order to make this approach substantial I need to make it > > work with 8250 UART (major serial driver), correct? As currently it > > works properly for amba-pl011 driver. > > Yes, try to do that, or better yet, make it work with all serial drivers > automatically. I would like to make serial drivers work automatically but unfortunately the interrupt request/ handling code is pretty specific to the corresponding serial driver. BTW, I will look for ways how we can make it much easier for serial drivers to adapt. -Sumit > > thanks, > > greg k-h
Re: [RFC v2 03/11] tty: serial: qcom_geni_serial: Use OPP API to set clk/perf state
On 8/12/2020 7:03 AM, John Stultz wrote: On Tue, Aug 11, 2020 at 4:11 PM John Stultz wrote: On Wed, Mar 20, 2019 at 2:49 AM Rajendra Nayak wrote: geni serial needs to express a perforamnce state requirement on CX depending on the frequency of the clock rates. Use OPP table from DT to register with OPP framework and use dev_pm_opp_set_rate() to set the clk/perf state. Signed-off-by: Rajendra Nayak Signed-off-by: Stephen Boyd --- drivers/tty/serial/qcom_geni_serial.c | 15 +-- 1 file changed, 13 insertions(+), 2 deletions(-) Hey, I just wanted to follow up on this patch, as I've bisected it (a5819b548af0) down as having broken qca bluetooth on the Dragonboard 845c. I haven't yet had time to debug it yet, but wanted to raise the issue in case anyone else has seen similar trouble. So I dug in a bit further, and this chunk seems to be causing the issue: @@ -961,7 +963,7 @@ static void qcom_geni_serial_set_termios(struct uart_port *uport, goto out_restart_rx; uport->uartclk = clk_rate; - clk_set_rate(port->se.clk, clk_rate); + dev_pm_opp_set_rate(port->dev, clk_rate); ser_clk_cfg = SER_CLK_EN; ser_clk_cfg |= clk_div << CLK_DIV_SHFT; With that applied, I see the following errors in dmesg and bluetooth fails to function: [4.763467] qcom_geni_serial 898000.serial: dev_pm_opp_set_rate: failed to find OPP for freq 10240 (-34) [4.773493] qcom_geni_serial 898000.serial: dev_pm_opp_set_rate: failed to find OPP for freq 10240 (-34) With just that chunk reverted on linus/HEAD, bluetooth seems to work ok. This seems like the same issue that was also reported on venus [1] because the clock frequency tables apparently don;t exactly match the achievable clock frequencies (which we also used to construct the OPP tables) Can you try updating the OPP table for QUP to have 10240 instead of the current 1 and see if that fixes it? [1] https://lkml.org/lkml/2020/7/27/507 thanks -john -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH 10/10] mm/hugetlb: not necessary to abuse temporary page to workaround the nasty free_huge_page
On 08/11/20 at 02:43pm, Mike Kravetz wrote:
> Here is a patch to do that. However, we are optimizing a return path in
> a race condition that we are unlikely to ever hit. I 'tested' it by
> allocating
> an 'extra' page and freeing it via this method in alloc_surplus_huge_page.
>
> From 864c5f8ef4900c95ca3f6f2363a85f3cb25e793e Mon Sep 17 00:00:00 2001
> From: Mike Kravetz
> Date: Tue, 11 Aug 2020 12:45:41 -0700
> Subject: [PATCH] hugetlb: optimize race error return in
> alloc_surplus_huge_page
>
> The routine alloc_surplus_huge_page() could race with with a pool
> size change. If this happens, the allocated page may not be needed.
> To free the page, the current code will 'Abuse temporary page to
> workaround the nasty free_huge_page codeflow'. Instead, directly
> call the low level routine that free_huge_page uses. This works
> out well because the page is new, we hold the only reference and
> already hold the hugetlb_lock.
>
> Signed-off-by: Mike Kravetz
> ---
> mm/hugetlb.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 590111ea6975..ac89b91fba86 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1923,14 +1923,17 @@ static struct page *alloc_surplus_huge_page(struct
> hstate *h, gfp_t gfp_mask,
> /*
>* We could have raced with the pool size change.
>* Double check that and simply deallocate the new page
> - * if we would end up overcommiting the surpluses. Abuse
> - * temporary page to workaround the nasty free_huge_page
> - * codeflow
> + * if we would end up overcommiting the surpluses.
>*/
> if (h->surplus_huge_pages >= h->nr_overcommit_huge_pages) {
> - SetPageHugeTemporary(page);
> + /*
> + * Since this page is new, we hold the only reference, and
> + * we already hold the hugetlb_lock call the low level free
> + * page routine. This saves at least a lock roundtrip.
> + */
> + (void)put_page_testzero(page); /* don't call destructor */
> + update_and_free_page(h, page);
Yeah, taking this code change, or keeping the temporary page way as is,
both looks good.
> spin_unlock(_lock);
> - put_page(page);
> return NULL;
> } else {
> h->surplus_huge_pages++;
Re: [PATCH] i2c: imx: Use dev_err_probe() to simplify error handling
On Wed, Aug 12, 2020 at 11:45:54AM +0800, Anson Huang wrote:
> dev_err_probe() can reduce code size, uniform error handling and record the
> defer probe reason etc., use it to simplify the code.
>
> Signed-off-by: Anson Huang
> ---
> drivers/i2c/busses/i2c-imx.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> index 0ab5381..63f4367 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -1159,11 +1159,9 @@ static int i2c_imx_probe(struct platform_device *pdev)
>
> /* Get I2C clock */
> i2c_imx->clk = devm_clk_get(>dev, NULL);
> - if (IS_ERR(i2c_imx->clk)) {
> - if (PTR_ERR(i2c_imx->clk) != -EPROBE_DEFER)
> - dev_err(>dev, "can't get I2C clock\n");
> - return PTR_ERR(i2c_imx->clk);
> - }
> + if (IS_ERR(i2c_imx->clk))
> + return dev_err_probe(>dev, PTR_ERR(i2c_imx->clk),
> + "can't get I2C clock\n");
>
> ret = clk_prepare_enable(i2c_imx->clk);
> if (ret) {
> --
Acked-by: Oleksij Rempel
--
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- |
signature.asc
Description: PGP signature
Re: [PATCH v5 06/10] powerpc/smp: Optimize start_secondary
Hi Srikar,
On Mon, Aug 10, 2020 at 12:48:30PM +0530, Srikar Dronamraju wrote:
> In start_secondary, even if shared_cache was already set, system does a
> redundant match for cpumask. This redundant check can be removed by
> checking if shared_cache is already set.
>
> While here, localize the sibling_mask variable to within the if
> condition.
>
> Cc: linuxppc-dev
> Cc: LKML
> Cc: Michael Ellerman
> Cc: Nicholas Piggin
> Cc: Anton Blanchard
> Cc: Oliver O'Halloran
> Cc: Nathan Lynch
> Cc: Michael Neuling
> Cc: Gautham R Shenoy
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Valentin Schneider
> Cc: Jordan Niethe
> Cc: Vaidyanathan Srinivasan
> Signed-off-by: Srikar Dronamraju
The change looks good to me.
Reviewed-by: Gautham R. Shenoy
> ---
> Changelog v4 ->v5:
> Retain cache domain, no need for generalization
>(Michael Ellerman, Peter Zijlstra,
>Valentin Schneider, Gautham R. Shenoy)
>
> Changelog v1 -> v2:
> Moved shared_cache topology fixup to fixup_topology (Gautham)
>
> arch/powerpc/kernel/smp.c | 17 +++--
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index 0c960ce3be42..91cf5d05e7ec 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -851,7 +851,7 @@ static int powerpc_shared_cache_flags(void)
> */
> static const struct cpumask *shared_cache_mask(int cpu)
> {
> - return cpu_l2_cache_mask(cpu);
> + return per_cpu(cpu_l2_cache_map, cpu);
> }
>
> #ifdef CONFIG_SCHED_SMT
> @@ -1305,7 +1305,6 @@ static void add_cpu_to_masks(int cpu)
> void start_secondary(void *unused)
> {
> unsigned int cpu = smp_processor_id();
> - struct cpumask *(*sibling_mask)(int) = cpu_sibling_mask;
>
> mmgrab(_mm);
> current->active_mm = _mm;
> @@ -1331,14 +1330,20 @@ void start_secondary(void *unused)
> /* Update topology CPU masks */
> add_cpu_to_masks(cpu);
>
> - if (has_big_cores)
> - sibling_mask = cpu_smallcore_mask;
> /*
>* Check for any shared caches. Note that this must be done on a
>* per-core basis because one core in the pair might be disabled.
>*/
> - if (!cpumask_equal(cpu_l2_cache_mask(cpu), sibling_mask(cpu)))
> - shared_caches = true;
> + if (!shared_caches) {
> + struct cpumask *(*sibling_mask)(int) = cpu_sibling_mask;
> + struct cpumask *mask = cpu_l2_cache_mask(cpu);
> +
> + if (has_big_cores)
> + sibling_mask = cpu_smallcore_mask;
> +
> + if (cpumask_weight(mask) > cpumask_weight(sibling_mask(cpu)))
> + shared_caches = true;
> + }
>
> set_numa_node(numa_cpu_lookup_table[cpu]);
> set_numa_mem(local_memory_node(numa_cpu_lookup_table[cpu]));
> --
> 2.18.2
>
drivers/edac/amd64_edac.c:3065:47: sparse: sparse: incorrect type in argument 3 (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: fb893de323e2d39f7a1f6df425703a2edbdf56ea commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to define address spaces date: 8 weeks ago config: i386-randconfig-s001-20200812 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.2-168-g9554805c-dirty git checkout 670d0a4b10704667765f7d18f7592993d02783aa # save the attached .config to linux build tree make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) >> drivers/edac/amd64_edac.c:3065:47: sparse: sparse: incorrect type in >> argument 3 (different address spaces) @@ expected struct msr *msrs @@ >> got struct msr [noderef] __percpu *static [toplevel] msrs @@ drivers/edac/amd64_edac.c:3065:47: sparse: expected struct msr *msrs >> drivers/edac/amd64_edac.c:3065:47: sparse: got struct msr [noderef] >> __percpu *static [toplevel] msrs drivers/edac/amd64_edac.c:3097:48: sparse: sparse: incorrect type in argument 3 (different address spaces) @@ expected struct msr *msrs @@ got struct msr [noderef] __percpu *static [toplevel] msrs @@ drivers/edac/amd64_edac.c:3097:48: sparse: expected struct msr *msrs drivers/edac/amd64_edac.c:3097:48: sparse: got struct msr [noderef] __percpu *static [toplevel] msrs drivers/edac/amd64_edac.c:3116:48: sparse: sparse: incorrect type in argument 3 (different address spaces) @@ expected struct msr *msrs @@ got struct msr [noderef] __percpu *static [toplevel] msrs @@ drivers/edac/amd64_edac.c:3116:48: sparse: expected struct msr *msrs drivers/edac/amd64_edac.c:3116:48: sparse: got struct msr [noderef] __percpu *static [toplevel] msrs >> drivers/edac/amd64_edac.c:3674:14: sparse: sparse: incorrect type in >> assignment (different address spaces) @@ expected struct msr [noderef] >> __percpu *static [toplevel] msrs @@ got struct msr * @@ >> drivers/edac/amd64_edac.c:3674:14: sparse: expected struct msr [noderef] >> __percpu *static [toplevel] msrs drivers/edac/amd64_edac.c:3674:14: sparse: got struct msr * drivers/edac/amd64_edac.c:3711:19: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct msr *msrs @@ got struct msr [noderef] __percpu *static [toplevel] msrs @@ drivers/edac/amd64_edac.c:3711:19: sparse: expected struct msr *msrs drivers/edac/amd64_edac.c:3711:19: sparse: got struct msr [noderef] __percpu *static [toplevel] msrs >> drivers/edac/amd64_edac.c:3740:19: sparse: sparse: incorrect type in >> argument 1 (different address spaces) @@ expected struct msr *msrs @@ >> got struct msr [noderef] __percpu *static [assigned] [toplevel] msrs @@ drivers/edac/amd64_edac.c:3740:19: sparse: expected struct msr *msrs >> drivers/edac/amd64_edac.c:3740:19: sparse: got struct msr [noderef] >> __percpu *static [assigned] [toplevel] msrs -- >> drivers/video/fbdev/geode/suspend_gx.c:32:28: sparse: sparse: incorrect type >> in argument 2 (different address spaces) @@ expected void const *q @@ >> got void [noderef] __iomem *gp_regs @@ drivers/video/fbdev/geode/suspend_gx.c:32:28: sparse: expected void const *q drivers/video/fbdev/geode/suspend_gx.c:32:28: sparse: got void [noderef] __iomem *gp_regs >> drivers/video/fbdev/geode/suspend_gx.c:33:28: sparse: sparse: incorrect type >> in argument 2 (different address spaces) @@ expected void const *q @@ >> got void [noderef] __iomem *dc_regs @@ drivers/video/fbdev/geode/suspend_gx.c:33:28: sparse: expected void const *q drivers/video/fbdev/geode/suspend_gx.c:33:28: sparse: got void [noderef] __iomem *dc_regs >> drivers/video/fbdev/geode/suspend_gx.c:34:28: sparse: sparse: incorrect type >> in argument 2 (different address spaces) @@ expected void const *q @@ >> got void [noderef] __iomem *vid_regs @@ drivers/video/fbdev/geode/suspend_gx.c:34:28: sparse: expected void const *q drivers/video/fbdev/geode/suspend_gx.c:34:28: sparse: got void [noderef] __iomem *vid_regs >> drivers/video/fbdev/geode/suspend_gx.c:35:39: sparse: sparse: incorrect type >> in argument 2 (different address spaces) @@ expected void const *q @@ >> got void [noderef] __iomem * @@ drivers/video/fbdev/geode/suspend_gx.c:35:39: sparse: expected void const *q drivers/video/fbdev/geode/suspend_gx.c:35:39: sparse: got void [noderef] __iomem * -- drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c: note: in included file (through drivers/net/wireless/intel/iwlwifi/mvm/..//fw/img.h, drivers/net/wireless/intel/iwlwifi/mvm/..//iwl-trans.h, ...):
drivers/gpu/drm/i915/i915_sw_fence.c:84:20: error: unused function 'debug_fence_init_onstack'
Hi Masahiro,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: fb893de323e2d39f7a1f6df425703a2edbdf56ea
commit: 6863f5643dd717376c2fdc85a47a00f9d738a834 kbuild: allow Clang to find
unused static inline functions for W=1 build
date: 11 months ago
config: x86_64-randconfig-a005-20200812 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
4f2ad15db535873dda9bfe248a2771023b64a43c)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
git checkout 6863f5643dd717376c2fdc85a47a00f9d738a834
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/i915/i915_sw_fence.c:84:20: error: unused function
>> 'debug_fence_init_onstack' [-Werror,-Wunused-function]
static inline void debug_fence_init_onstack(struct i915_sw_fence *fence)
^
>> drivers/gpu/drm/i915/i915_sw_fence.c:105:20: error: unused function
>> 'debug_fence_free' [-Werror,-Wunused-function]
static inline void debug_fence_free(struct i915_sw_fence *fence)
^
2 errors generated.
--
>> drivers/gpu/drm/i915/display/intel_hdmi.c:1696:26: error: unused function
>> 'intel_hdmi_hdcp2_protocol' [-Werror,-Wunused-function]
enum hdcp_wired_protocol intel_hdmi_hdcp2_protocol(void)
^
1 error generated.
--
>> drivers/gpu/drm/i915/gvt/gtt.c:263:19: error: unused function 'get_pt_type'
>> [-Werror,-Wunused-function]
static inline int get_pt_type(int type)
^
>> drivers/gpu/drm/i915/gvt/gtt.c:587:20: error: unused function
>> 'ppgtt_set_guest_root_entry' [-Werror,-Wunused-function]
static inline void ppgtt_set_guest_root_entry(struct intel_vgpu_mm *mm,
^
2 errors generated.
vim +/debug_fence_init_onstack +84 drivers/gpu/drm/i915/i915_sw_fence.c
fc1584059d6c43 Chris Wilson 2016-11-25 83
214707fc2ce08d Chris Wilson 2017-10-12 @84 static inline void
debug_fence_init_onstack(struct i915_sw_fence *fence)
214707fc2ce08d Chris Wilson 2017-10-12 85 {
214707fc2ce08d Chris Wilson 2017-10-12 86 }
214707fc2ce08d Chris Wilson 2017-10-12 87
fc1584059d6c43 Chris Wilson 2016-11-25 88 static inline void
debug_fence_activate(struct i915_sw_fence *fence)
fc1584059d6c43 Chris Wilson 2016-11-25 89 {
fc1584059d6c43 Chris Wilson 2016-11-25 90 }
fc1584059d6c43 Chris Wilson 2016-11-25 91
fc1584059d6c43 Chris Wilson 2016-11-25 92 static inline void
debug_fence_set_state(struct i915_sw_fence *fence,
fc1584059d6c43 Chris Wilson 2016-11-25 93
int old, int new)
fc1584059d6c43 Chris Wilson 2016-11-25 94 {
fc1584059d6c43 Chris Wilson 2016-11-25 95 }
fc1584059d6c43 Chris Wilson 2016-11-25 96
fc1584059d6c43 Chris Wilson 2016-11-25 97 static inline void
debug_fence_deactivate(struct i915_sw_fence *fence)
fc1584059d6c43 Chris Wilson 2016-11-25 98 {
fc1584059d6c43 Chris Wilson 2016-11-25 99 }
fc1584059d6c43 Chris Wilson 2016-11-25 100
fc1584059d6c43 Chris Wilson 2016-11-25 101 static inline void
debug_fence_destroy(struct i915_sw_fence *fence)
fc1584059d6c43 Chris Wilson 2016-11-25 102 {
fc1584059d6c43 Chris Wilson 2016-11-25 103 }
fc1584059d6c43 Chris Wilson 2016-11-25 104
fc1584059d6c43 Chris Wilson 2016-11-25 @105 static inline void
debug_fence_free(struct i915_sw_fence *fence)
fc1584059d6c43 Chris Wilson 2016-11-25 106 {
fc1584059d6c43 Chris Wilson 2016-11-25 107 }
fc1584059d6c43 Chris Wilson 2016-11-25 108
:: The code at line 84 was first introduced by commit
:: 214707fc2ce08d09982bc4fe4b7a1c1f010e82be drm/i915/selftests: Wrap a
timer into a i915_sw_fence
:: TO: Chris Wilson
:: CC: Chris Wilson
---
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 v3 06/18] gpiolib: cdev: support GPIO_V2_GET_LINEINFO_IOCTL and GPIO_V2_GET_LINEINFO_WATCH_IOCTL
On Sun, Aug 09, 2020 at 09:25:17PM +0800, Kent Gibson wrote: > Add support for GPIO_V2_GET_LINEINFO_IOCTL and > GPIO_V2_GET_LINEINFO_WATCH_IOCTL. > > Signed-off-by: Kent Gibson > --- > [snip] > > if (copy_from_user(, ip, sizeof(lineinfo))) > return -EFAULT; > @@ -1251,7 +1353,9 @@ static long gpio_ioctl(struct file *file, unsigned int > cmd, unsigned long arg) > if (IS_ERR(desc)) > return PTR_ERR(desc); > > - gpio_desc_to_lineinfo(desc, ); > + gpio_desc_to_lineinfo(desc, _v2); > + lineinfo_v2.offset = lineinfo.line_offset; > + gpio_v2_line_info_to_v1(_v2, ); > This is broken as gpio_desc_to_lineinfo() requires the offset to be already set in the info. I could move the setting of offset before the call, but would rather change gpio_desc_to_lineinfo() to treat info strictly as output (it can determine the offset from the desc) so as not to trap anyone else in the future. I also intend to replace the use of strncpy, from this patch and elsewhere, to placate the build-bot. Cheers, Kent.
drivers/soc/qcom/smd-rpm.c:177:47: sparse: sparse: incorrect type in argument 2 (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: fb893de323e2d39f7a1f6df425703a2edbdf56ea commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to define address spaces date: 8 weeks ago config: powerpc64-randconfig-s032-20200812 (attached as .config) compiler: powerpc-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.2-168-g9554805c-dirty git checkout 670d0a4b10704667765f7d18f7592993d02783aa # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=powerpc64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) >> drivers/soc/qcom/smd-rpm.c:177:47: sparse: sparse: incorrect type in >> argument 2 (different address spaces) @@ expected void const volatile >> [noderef] __iomem *s @@ got unsigned char const * @@ >> drivers/soc/qcom/smd-rpm.c:177:47: sparse: expected void const volatile >> [noderef] __iomem *s drivers/soc/qcom/smd-rpm.c:177:47: sparse: got unsigned char const * -- >> drivers/spi/spi-fsl-cpm.c:58:39: sparse: sparse: incorrect type in argument >> 1 (different base types) @@ expected unsigned int volatile [noderef] >> [usertype] __iomem *addr @@ got restricted __be32 [noderef] __iomem * @@ >> drivers/spi/spi-fsl-cpm.c:58:39: sparse: expected unsigned int volatile >> [noderef] [usertype] __iomem *addr >> drivers/spi/spi-fsl-cpm.c:58:39: sparse: got restricted __be32 [noderef] >> __iomem * >> drivers/spi/spi-fsl-cpm.c:59:39: sparse: sparse: incorrect type in argument >> 1 (different base types) @@ expected unsigned short volatile [noderef] >> [usertype] __iomem *addr @@ got restricted __be16 [noderef] __iomem * @@ >> drivers/spi/spi-fsl-cpm.c:59:39: sparse: expected unsigned short >> volatile [noderef] [usertype] __iomem *addr >> drivers/spi/spi-fsl-cpm.c:59:39: sparse: got restricted __be16 [noderef] >> __iomem * >> drivers/spi/spi-fsl-cpm.c:60:47: sparse: sparse: incorrect type in argument >> 1 (different base types) @@ expected unsigned short const volatile >> [noderef] [usertype] __iomem *addr @@ got restricted __be16 [noderef] >> __iomem * @@ >> drivers/spi/spi-fsl-cpm.c:60:47: sparse: expected unsigned short const >> volatile [noderef] [usertype] __iomem *addr drivers/spi/spi-fsl-cpm.c:60:47: sparse: got restricted __be16 [noderef] __iomem * drivers/spi/spi-fsl-cpm.c:61:39: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef] __iomem * @@ drivers/spi/spi-fsl-cpm.c:61:39: sparse: expected unsigned int volatile [noderef] [usertype] __iomem *addr drivers/spi/spi-fsl-cpm.c:61:39: sparse: got restricted __be32 [noderef] __iomem * drivers/spi/spi-fsl-cpm.c:62:39: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned short volatile [noderef] [usertype] __iomem *addr @@ got restricted __be16 [noderef] __iomem * @@ drivers/spi/spi-fsl-cpm.c:62:39: sparse: expected unsigned short volatile [noderef] [usertype] __iomem *addr drivers/spi/spi-fsl-cpm.c:62:39: sparse: got restricted __be16 [noderef] __iomem * drivers/spi/spi-fsl-cpm.c:63:47: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned short const volatile [noderef] [usertype] __iomem *addr @@ got restricted __be16 [noderef] __iomem * @@ drivers/spi/spi-fsl-cpm.c:63:47: sparse: expected unsigned short const volatile [noderef] [usertype] __iomem *addr drivers/spi/spi-fsl-cpm.c:63:47: sparse: got restricted __be16 [noderef] __iomem * >> drivers/spi/spi-fsl-cpm.c:77:44: sparse: sparse: incorrect type in >> initializer (different address spaces) @@ expected struct fsl_spi_reg >> *reg_base @@ got void [noderef] __iomem *reg_base @@ drivers/spi/spi-fsl-cpm.c:77:44: sparse: expected struct fsl_spi_reg *reg_base >> drivers/spi/spi-fsl-cpm.c:77:44: sparse: got void [noderef] __iomem >> *reg_base >> drivers/spi/spi-fsl-cpm.c:97:32: sparse: sparse: incorrect type in argument >> 1 (different address spaces) @@ expected restricted __be32 [noderef] >> [usertype] __iomem *reg @@ got restricted __be32 * @@ >> drivers/spi/spi-fsl-cpm.c:97:32: sparse: expected restricted __be32 >> [noderef] [usertype] __iomem *reg drivers/spi/spi-fsl-cpm.c:97:32: sparse: got restricted __be32 * drivers/spi/spi-fsl-cpm.c:104:44: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected
drivers/tty/serial/8250/serial_cs.c:148:17: sparse: sparse: cast removes address space '__iomem' of expression
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: fb893de323e2d39f7a1f6df425703a2edbdf56ea commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to define address spaces date: 8 weeks ago config: riscv-randconfig-s031-20200812 (attached as .config) compiler: riscv64-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.2-168-g9554805c-dirty git checkout 670d0a4b10704667765f7d18f7592993d02783aa # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=riscv If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) >> drivers/tty/serial/8250/serial_cs.c:148:17: sparse: sparse: cast removes >> address space '__iomem' of expression >> drivers/tty/serial/8250/serial_cs.c:148:17: sparse: sparse: incorrect type >> in argument 2 (different address spaces) @@ expected void volatile >> [noderef] __iomem *addr @@ got void * @@ >> drivers/tty/serial/8250/serial_cs.c:148:17: sparse: expected void >> volatile [noderef] __iomem *addr drivers/tty/serial/8250/serial_cs.c:148:17: sparse: got void * drivers/tty/serial/8250/serial_cs.c:162:9: sparse: sparse: cast removes address space '__iomem' of expression drivers/tty/serial/8250/serial_cs.c:162:9: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void * @@ drivers/tty/serial/8250/serial_cs.c:162:9: sparse: expected void volatile [noderef] __iomem *addr drivers/tty/serial/8250/serial_cs.c:162:9: sparse: got void * drivers/tty/serial/8250/serial_cs.c:164:9: sparse: sparse: cast removes address space '__iomem' of expression drivers/tty/serial/8250/serial_cs.c:164:9: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void * @@ drivers/tty/serial/8250/serial_cs.c:164:9: sparse: expected void volatile [noderef] __iomem *addr drivers/tty/serial/8250/serial_cs.c:164:9: sparse: got void * drivers/tty/serial/8250/serial_cs.c:166:9: sparse: sparse: cast removes address space '__iomem' of expression drivers/tty/serial/8250/serial_cs.c:166:9: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void * @@ drivers/tty/serial/8250/serial_cs.c:166:9: sparse: expected void volatile [noderef] __iomem *addr drivers/tty/serial/8250/serial_cs.c:166:9: sparse: got void * drivers/tty/serial/8250/serial_cs.c:168:9: sparse: sparse: cast removes address space '__iomem' of expression drivers/tty/serial/8250/serial_cs.c:168:9: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void * @@ drivers/tty/serial/8250/serial_cs.c:168:9: sparse: expected void volatile [noderef] __iomem *addr drivers/tty/serial/8250/serial_cs.c:168:9: sparse: got void * drivers/tty/serial/8250/serial_cs.c:170:9: sparse: sparse: cast removes address space '__iomem' of expression drivers/tty/serial/8250/serial_cs.c:170:9: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void * @@ drivers/tty/serial/8250/serial_cs.c:170:9: sparse: expected void volatile [noderef] __iomem *addr drivers/tty/serial/8250/serial_cs.c:170:9: sparse: got void * drivers/tty/serial/8250/serial_cs.c:172:9: sparse: sparse: cast removes address space '__iomem' of expression drivers/tty/serial/8250/serial_cs.c:172:9: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void * @@ drivers/tty/serial/8250/serial_cs.c:172:9: sparse: expected void volatile [noderef] __iomem *addr drivers/tty/serial/8250/serial_cs.c:172:9: sparse: got void * drivers/tty/serial/8250/serial_cs.c:174:9: sparse: sparse: cast removes address space '__iomem' of expression drivers/tty/serial/8250/serial_cs.c:174:9: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void * @@ drivers/tty/serial/8250/serial_cs.c:174:9: sparse: expected void volatile [noderef] __iomem *addr drivers/tty/serial/8250/serial_cs.c:174:9: sparse: got void * -- >> drivers/video/fbdev/arcfb.c:119:9: sparse: sparse: cast removes address >> space '__iomem' of expression >>
[PATCH v3] f2fs: change virtual mapping way for compression pages
From: Daeho Jeong
By profiling f2fs compression works, I've found vmap() callings have
unexpected hikes in the execution time in our test environment and
those are bottlenecks of f2fs decompression path. Changing these with
vm_map_ram(), we can enhance f2fs decompression speed pretty much.
[Verification]
Android Pixel 3(ARM64, 6GB RAM, 128GB UFS)
Turned on only 0-3 little cores(at 1.785GHz)
dd if=/dev/zero of=dummy bs=1m count=1000
echo 3 > /proc/sys/vm/drop_caches
dd if=dummy of=/dev/zero bs=512k
- w/o compression -
1048576000 bytes (0.9 G) copied, 2.082554 s, 480 M/s
1048576000 bytes (0.9 G) copied, 2.081634 s, 480 M/s
1048576000 bytes (0.9 G) copied, 2.090861 s, 478 M/s
- before patch -
1048576000 bytes (0.9 G) copied, 7.407527 s, 135 M/s
1048576000 bytes (0.9 G) copied, 7.283734 s, 137 M/s
1048576000 bytes (0.9 G) copied, 7.291508 s, 137 M/s
- after patch -
1048576000 bytes (0.9 G) copied, 1.998959 s, 500 M/s
1048576000 bytes (0.9 G) copied, 1.987554 s, 503 M/s
1048576000 bytes (0.9 G) copied, 1.986380 s, 503 M/s
Signed-off-by: Daeho Jeong
---
Changes in v2:
- Added test environment description.
Changes in v3:
- Re-tested using only ARM little cores and maximzing cpu clock.
---
fs/f2fs/compress.c | 42 --
1 file changed, 32 insertions(+), 10 deletions(-)
diff --git a/fs/f2fs/compress.c b/fs/f2fs/compress.c
index 6e7db450006c..46b7e359f313 100644
--- a/fs/f2fs/compress.c
+++ b/fs/f2fs/compress.c
@@ -554,6 +554,8 @@ static void f2fs_compress_free_page(struct page *page)
mempool_free(page, compress_page_pool);
}
+#define MAX_VMAP_RETRIES 3
+
static int f2fs_compress_pages(struct compress_ctx *cc)
{
struct f2fs_sb_info *sbi = F2FS_I_SB(cc->inode);
@@ -590,13 +592,23 @@ static int f2fs_compress_pages(struct compress_ctx *cc)
}
}
- cc->rbuf = vmap(cc->rpages, cc->cluster_size, VM_MAP, PAGE_KERNEL_RO);
+ for (i = 0; i < MAX_VMAP_RETRIES; i++) {
+ cc->rbuf = vm_map_ram(cc->rpages, cc->cluster_size, -1);
+ if (cc->rbuf)
+ break;
+ vm_unmap_aliases();
+ }
if (!cc->rbuf) {
ret = -ENOMEM;
goto out_free_cpages;
}
- cc->cbuf = vmap(cc->cpages, cc->nr_cpages, VM_MAP, PAGE_KERNEL);
+ for (i = 0; i < MAX_VMAP_RETRIES; i++) {
+ cc->cbuf = vm_map_ram(cc->cpages, cc->nr_cpages, -1);
+ if (cc->cbuf)
+ break;
+ vm_unmap_aliases();
+ }
if (!cc->cbuf) {
ret = -ENOMEM;
goto out_vunmap_rbuf;
@@ -624,8 +636,8 @@ static int f2fs_compress_pages(struct compress_ctx *cc)
memset(>cbuf->cdata[cc->clen], 0,
(nr_cpages * PAGE_SIZE) - (cc->clen + COMPRESS_HEADER_SIZE));
- vunmap(cc->cbuf);
- vunmap(cc->rbuf);
+ vm_unmap_ram(cc->cbuf, cc->nr_cpages);
+ vm_unmap_ram(cc->rbuf, cc->cluster_size);
for (i = nr_cpages; i < cc->nr_cpages; i++) {
f2fs_compress_free_page(cc->cpages[i]);
@@ -642,9 +654,9 @@ static int f2fs_compress_pages(struct compress_ctx *cc)
return 0;
out_vunmap_cbuf:
- vunmap(cc->cbuf);
+ vm_unmap_ram(cc->cbuf, cc->nr_cpages);
out_vunmap_rbuf:
- vunmap(cc->rbuf);
+ vm_unmap_ram(cc->rbuf, cc->cluster_size);
out_free_cpages:
for (i = 0; i < cc->nr_cpages; i++) {
if (cc->cpages[i])
@@ -715,13 +727,23 @@ void f2fs_decompress_pages(struct bio *bio, struct page
*page, bool verity)
goto out_free_dic;
}
- dic->rbuf = vmap(dic->tpages, dic->cluster_size, VM_MAP, PAGE_KERNEL);
+ for (i = 0; i < MAX_VMAP_RETRIES; i++) {
+ dic->rbuf = vm_map_ram(dic->tpages, dic->cluster_size, -1);
+ if (dic->rbuf)
+ break;
+ vm_unmap_aliases();
+ }
if (!dic->rbuf) {
ret = -ENOMEM;
goto destroy_decompress_ctx;
}
- dic->cbuf = vmap(dic->cpages, dic->nr_cpages, VM_MAP, PAGE_KERNEL_RO);
+ for (i = 0; i < MAX_VMAP_RETRIES; i++) {
+ dic->cbuf = vm_map_ram(dic->cpages, dic->nr_cpages, -1);
+ if (dic->cbuf)
+ break;
+ vm_unmap_aliases();
+ }
if (!dic->cbuf) {
ret = -ENOMEM;
goto out_vunmap_rbuf;
@@ -738,9 +760,9 @@ void f2fs_decompress_pages(struct bio *bio, struct page
*page, bool verity)
ret = cops->decompress_pages(dic);
out_vunmap_cbuf:
- vunmap(dic->cbuf);
+ vm_unmap_ram(dic->cbuf, dic->nr_cpages);
out_vunmap_rbuf:
- vunmap(dic->rbuf);
+ vm_unmap_ram(dic->rbuf, dic->cluster_size);
destroy_decompress_ctx:
if (cops->destroy_decompress_ctx)
cops->destroy_decompress_ctx(dic);
--
2.28.0.236.gb10cc79966-goog
[RFC V2] kthread: add object debug support
From: Qianli Zhao
Add debugobject support to track the life time of kthread_work
which is used to detect reinitialization/free active object problems
Add kthread_init_work_onstack/kthread_init_delayed_work_onstack for
kthread onstack support
Signed-off-by: Qianli Zhao
---
I got an crash issue since kthread_delayed_work reinitialization,crash log show
us that is a timer NULL pointer exception
[16238.089921] Unable to handle kernel paging request at virtual address
dead0208
[16238.090298] Call trace:
[16238.090307] run_timer_softirq+0x2d0/0xa30
[16238.090318] __do_softirq+0x1dc/0x384
[16238.090328] irq_exit+0xb4/0xb8
[16238.090338] __handle_domain_irq+0x84/0xc0
[16238.090345] gic_handle_irq+0x138/0x1bc
[16238.090353] el1_irq+0xb0/0x128
[16238.090362] queue_work_on+0x54/0x60
[16238.090374] _process_event_group+0x190/0x230
[16238.090382] kgsl_process_event_groups+0x44/0x70
[16238.090391] adreno_dispatcher_work+0x1e4/0xae8
[16238.090400] kthread_worker_fn+0xec/0x180
[16238.090407] kthread+0x118/0x128
[16238.090415] ret_from_fork+0x10/0x18
It turns out that the problem is caused by the timer reinitialization,after
enable CONFIG_DEBUG_OBJECTS_TIMERS,the reason for the problem is obvious.
This timer belongs to kthread_delayed_work,from kernel log we also see list
corruption WARNING:
[30858.395766] list_del corruption. next->prev should be ffe388ebbf88, but
was ffe388ebb588
[30858.395788] WARNING: CPU: 2 PID: 387 at
/home/work/data/miui_codes/build_home/kernel/msm-4.19/lib/list_debug.c:56
__list_del_entry_valid+0xc8/0xd0
...
[30858.405951] list_add corruption. next->prev should be prev
(ffe389392620), but was ffe388ebbf88. (next=ffe388ebbf88).
[30858.405977] WARNING: CPU: 0 PID: 7721 at
/home/work/data/miui_codes/build_home/kernel/msm-4.19/lib/list_debug.c:25
__list_add_valid+0x7c/0xc8
crash> struct kthread_worker.delayed_work_list 0xffe3893925f0
[ffe389392620] delayed_work_list = {
next = 0xffe388ebbf88,
prev = 0xffe388ebb588
}
crash> list 0xffe388ebbf88
ffe388ebbf88
delayed_work_list is corruption,this work is reinitialized.if kthread_work
reinitialized after move to work_list,this work will be carried out forever in
kthread_worker_fn.
Timer and workqueue both provide debugobject support，kthread_work similar with
workqueue,so i think it is necessary to support objectdebug in kthread_work.
---
include/linux/kthread.h | 29 ++-
include/linux/poison.h | 3 ++
kernel/kthread.c| 95 -
lib/Kconfig.debug | 10 ++
4 files changed, 135 insertions(+), 2 deletions(-)
diff --git a/include/linux/kthread.h b/include/linux/kthread.h
index 65b81e0..1530953 100644
--- a/include/linux/kthread.h
+++ b/include/linux/kthread.h
@@ -108,6 +108,16 @@ struct kthread_delayed_work {
struct timer_list timer;
};
+#ifdef CONFIG_DEBUG_OBJECTS_KTHREAD
+extern void __init_kwork(struct kthread_work *kwork, int onstack);
+extern void destroy_kwork_on_stack(struct kthread_work *kwork);
+extern void destroy_delayed_kwork_on_stack(struct kthread_delayed_work
*kdwork);
+#else
+static inline void __init_kwork(struct kthread_work *kwork, int onstack) { }
+static inline void destroy_kwork_on_stack(struct kthread_work *kwork) { }
+static inline void destroy_delayed_kwork_on_stack(struct kthread_delayed_work
*kdwork) { }
+#endif
+
#define KTHREAD_WORKER_INIT(worker){ \
.lock = __RAW_SPIN_LOCK_UNLOCKED((worker).lock),\
.work_list = LIST_HEAD_INIT((worker).work_list),\
@@ -115,7 +125,7 @@ struct kthread_delayed_work {
}
#define KTHREAD_WORK_INIT(work, fn){ \
- .node = LIST_HEAD_INIT((work).node),\
+ .node = { .next = KWORK_ENTRY_STATIC }, \
.func = (fn), \
}
@@ -160,6 +170,15 @@ extern void __kthread_init_worker(struct kthread_worker
*worker,
#define kthread_init_work(work, fn)\
do {\
memset((work), 0, sizeof(struct kthread_work)); \
+ __init_kwork(work, 0);
\
+ INIT_LIST_HEAD(&(work)->node); \
+ (work)->func = (fn);\
+ } while (0)
+
+#define kthread_init_work_onstack(work, fn)
\
+ do {\
+ memset((work), 0, sizeof(struct kthread_work)); \
+ __init_kwork(work, 1);
\
INIT_LIST_HEAD(&(work)->node); \
[PATCH] KVM: x86/pmu: Add '.exclude_hv = 1' for guest perf_event
To emulate PMC counter for guest, KVM would create an event on the host with 'exclude_guest=0, exclude_hv=0' which simply makes no sense and is utterly broken. To keep perf semantics consistent, any event created by pmc_reprogram_counter() should both set exclude_hv and exclude_host in the KVM context. Message-ID: <20200811084548.gw3...@worktop.programming.kicks-ass.net> Signed-off-by: Like Xu --- arch/x86/kvm/pmu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c index 67741d2a0308..6a30763a10d7 100644 --- a/arch/x86/kvm/pmu.c +++ b/arch/x86/kvm/pmu.c @@ -108,6 +108,7 @@ static void pmc_reprogram_counter(struct kvm_pmc *pmc, u32 type, .exclude_host = 1, .exclude_user = exclude_user, .exclude_kernel = exclude_kernel, + .exclude_hv = 1, .config = config, }; -- 2.21.3
[git pull] drm fixes for 5.9-rc1
Hi Linus, This is the fixes pull for 5.9-rc1. I had some fixes from the misc fixes tree come on a later base than drm-next was on, so I had to backmerge 5.8 into this to make things work for me and CI. However it totally messed up the diffstat so I didn't bother including it. The changelog looks fine. This has a few vmwgfx regression fixes we hit from the merge window (one in TTM), it also has a bunch of amdgpu fixes along with a scattering everywhere else. I'm not working for next few days, but I'll be around and have some time if anything comes up, but hopefully this is good enough for rc1, and any pulls after this can wait for rc2. Dave. drm-next-2020-08-12: drm fixes for 5.9-rc1 core: - Fix drm_dp_mst_port refcount leaks in drm_dp_mst_allocate_vcpi - Remove null check for kfree in drm_dev_release. - Fix DRM_FORMAT_MOD_AMLOGIC_FBC definition. - re-added docs for drm_gem_flink_ioctl() - add orientation quirk for ASUS T103HAF ttm: - ttm: fix page-offset calculation within TTM - revert patch causing vmwgfx regressions fbcon: - Fix a fbcon OOB read in fbdev, found by syzbot. vga: - Mark vga_tryget static as it's not used elsewhere. amdgpu: - Re-add spelling typo fix - Sienna Cichlid fixes - Navy Flounder fixes - DC fixes - SMU i2c fix - Power fixes vmwgfx: - regression fixes for modesetting crashes - misc fixes xlnx: - Small fixes to xlnx. omap: - Fix mode initialization in omap_connector_mode_valid(). - force runtime PM suspend on system suspend tidss: - fix modeset init for DPI panels The following changes since commit dc100bc8fae59aafd2ea2e1a1a43ef1f65f8a8bc: Merge tag 'drm-msm-next-2020-07-30' of https://gitlab.freedesktop.org/drm/msm into drm-next (2020-08-05 08:05:31 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-next-2020-08-12 for you to fetch changes up to 62975d27d647a40c58d3b96c29b911fc4f33c310: drm/ttm: revert "drm/ttm: make TT creation purely optional v3" (2020-08-12 13:26:28 +1000) drm fixes for 5.9-rc1 core: - Fix drm_dp_mst_port refcount leaks in drm_dp_mst_allocate_vcpi - Remove null check for kfree in drm_dev_release. - Fix DRM_FORMAT_MOD_AMLOGIC_FBC definition. - re-added docs for drm_gem_flink_ioctl() - add orientation quirk for ASUS T103HAF ttm: - ttm: fix page-offset calculation within TTM - revert patch causing vmwgfx regressions fbcon: - Fix a fbcon OOB read in fbdev, found by syzbot. vga: - Mark vga_tryget static as it's not used elsewhere. amdgpu: - Re-add spelling typo fix - Sienna Cichlid fixes - Navy Flounder fixes - DC fixes - SMU i2c fix - Power fixes vmwgfx: - regression fixes for modesetting crashes - misc fixes xlnx: - Small fixes to xlnx. omap: - Fix mode initialization in omap_connector_mode_valid(). - force runtime PM suspend on system suspend tidss: - fix modeset init for DPI panels Alex Deucher (1): drm/amdgpu/smu: rework i2c adpater registration Alvin Lee (1): drm/amd/display: Don't compare dppclk before updating DTO Aric Cyr (2): drm/amd/display: Fix DP Compliance tests 4.3.2.1 and 4.3.2.2 drm/amd/display: AMD OUI (DPCD 0x00300) skipped on some sink Bhawanpreet Lakha (2): drm/amd/display: Use seperate dmcub firmware for navy_flounder drm/amd/display: Use proper abm/backlight functions for DCN3 Boyuan Zhang (1): drm/amdgpu: update dec ring test for VCN 3.0 Changfeng (2): Revert "drm/amd/powerplay: drop unnecessary message support check" drm/amd/powerplay: drop unnecessary message support check(v2) Christian König (1): drm/ttm: revert "drm/ttm: make TT creation purely optional v3" Christoph Hellwig (1): vgaarb: mark vga_tryget static Colin Ian King (4): drm: xlnx: fix spelling mistake "failes" -> "failed" drm/amdgpu: fix spelling mistake "Falied" -> "Failed" drm/vmwgfx: fix spelling mistake "Cound" -> "Could" drm/vmwgfx: fix spelling mistake "Cant" -> "Can't" Dan Carpenter (3): drm/amd/powerplay: off by one bugs in smu_cmn_to_asic_specific_index() drm/vmwgfx: Use correct vmw_legacy_display_unit pointer drm/vmwgfx: Fix two list_for_each loop exit tests Daniel Vetter (1): drm/vmwgfx/stdu: Use drm_mode_config_reset Dave Airlie (5): Merge tag 'drm-misc-next-fixes-2020-08-05' of git://anongit.freedesktop.org/drm/drm-misc into drm-next Merge tag 'v5.8' into drm-next Merge tag 'drm-misc-fixes-2020-08-04' of git://anongit.freedesktop.org/drm/drm-misc into drm-next Merge tag 'amd-drm-fixes-5.9-2020-08-07' of git://people.freedesktop.org/~agd5f/linux into drm-next Merge branch 'vmwgfx-next-5.9' of git://people.freedesktop.org/~sroland/linux into drm-next Dmytro Laktyushkin (2): drm/amd/display: Clean up global sync param retrieval drm/amd/display: populate new dml variable Eric Bernstein (1):
Re: [PATCH 1/2] exfat: add NameLength check when extracting name
Thanks for your reply.
On 2020/08/09 1:54, Sungjong Seo wrote:
The current implementation doesn't care NameLength when extracting the
name from Name dir-entries, so the name may be incorrect.
(Without null-termination, Insufficient Name dir-entry, etc) Add a
NameLength check when extracting the name from Name dir-entries to extract
correct name.
And, change to get the information of file/stream-ext dir-entries via the
member variable of exfat_entry_set_cache.
** This patch depends on:
'[PATCH v3] exfat: integrates dir-entry getting and validation'.
Signed-off-by: Tetsuhiro Kohada
---
fs/exfat/dir.c | 81 --
1 file changed, 39 insertions(+), 42 deletions(-)
diff --git a/fs/exfat/dir.c b/fs/exfat/dir.c index
91cdbede0fd1..545bb73b95e9 100644
--- a/fs/exfat/dir.c
+++ b/fs/exfat/dir.c
@@ -28,16 +28,15 @@ static int exfat_extract_uni_name(struct exfat_dentry
*ep,
}
-static void exfat_get_uniname_from_ext_entry(struct super_block *sb,
- struct exfat_chain *p_dir, int entry, unsigned short
*uniname)
+static int exfat_get_uniname_from_name_entries(struct
exfat_entry_set_cache *es,
+ struct exfat_uni_name *uniname)
{
- int i;
- struct exfat_entry_set_cache *es;
+ int n, l, i;
struct exfat_dentry *ep;
- es = exfat_get_dentry_set(sb, p_dir, entry, ES_ALL_ENTRIES);
- if (!es)
- return;
+ uniname->name_len = es->de_stream->name_len;
+ if (uniname->name_len == 0)
+ return -EIO;
-EINVAL looks better.
OK.
I'll change in v2.
/*
* First entry : file entry
@@ -45,14 +44,15 @@ static void exfat_get_uniname_from_ext_entry(struct
super_block *sb,
* Third entry : first file-name entry
* So, the index of first file-name dentry should start from 2.
*/
-
- i = 2;
- while ((ep = exfat_get_validated_dentry(es, i++, TYPE_NAME))) {
- exfat_extract_uni_name(ep, uniname);
- uniname += EXFAT_FILE_NAME_LEN;
+ for (l = 0, n = 2; l < uniname->name_len; n++) {
+ ep = exfat_get_validated_dentry(es, n, TYPE_NAME);
+ if (!ep)
+ return -EIO;
+ for (i = 0; l < uniname->name_len && i <
EXFAT_FILE_NAME_LEN;
i++, l++)
+ uniname->name[l] = le16_to_cpu(ep-
dentry.name.unicode_0_14[i]);
Looks good.
}
-
- exfat_free_dentry_set(es, false);
+ uniname->name[l] = 0;
+ return 0;
}
/* read a directory entry from the opened directory */ @@ -63,6 +63,7 @@
static int exfat_readdir(struct inode *inode, struct exfat_dir_entry
*dir_entry)
[snip]
- *uni_name.name = 0x0;
- exfat_get_uniname_from_ext_entry(sb, , dentry,
- uni_name.name);
+ dir_entry->size = le64_to_cpu(es->de_stream-
valid_size);
+
+ exfat_get_uniname_from_name_entries(es, _name);
Modified function has a return value.
It would be better to check the return value.
Oops!
I'll fix it in v2.
exfat_utf16_to_nls(sb, _name,
dir_entry->namebuf.lfn,
dir_entry->namebuf.lfnbuf_len);
- brelse(bh);
- ep = exfat_get_dentry(sb, , i + 1, , NULL);
- if (!ep)
- return -EIO;
- dir_entry->size =
- le64_to_cpu(ep->dentry.stream.valid_size);
- brelse(bh);
+ exfat_free_dentry_set(es, false);
ei->hint_bmap.off = dentry >> dentries_per_clu_bits;
ei->hint_bmap.clu = clu.dir;
--
2.25.1
Re: "mm/vmalloc: Add flag for freeing of special permsissions" broke udev on ia64
On Tue, 2020-08-11 at 23:54 +0200, John Paul Adrian Glaubitz wrote: > Hi Rick! > > I have been bisecting some regressions on ia64 and one problem I ran > into is that > udev is causing the kernel to crash after the following change from > 2019: > > commit 868b104d7379e28013e9d48bdd2db25e0bdcf751 > Author: Rick Edgecombe > Date: Thu Apr 25 17:11:36 2019 -0700 > > mm/vmalloc: Add flag for freeing of special permsissions > > With your patch applied, udev crashes on ia64 when trying to load > modules, I'm pasting > the whole boot message sequence below. > > Any idea what could cause this problem on ia64? > > Thanks, > Adrian > Hi, On non-x86, this patchset shouldn't have changed much, just always flush the TLB and purge the vmalloc area in cases where previously this would only happen intermittently. Despite this, it also caused a problem on sparc. In the end the sparc issue turned out to be an issue with sparc's kernel range TLB flush implementation that was just now being hit earlier during boot instead of after the system had been up for some time. So I'm at first wondering if there might be something like that uncovered here. Unfortunately, it's unlikely that I can get access to ia64 hardware in the near term to debug. Would you be able to test some debug patches? Also, can you post your config? Thanks, Rick
[PATCH v10 3/5] drm/msm/dp: add support for DP PLL driver
From: Chandan Uddaraju
Add the needed DP PLL specific files to support
display port interface on msm targets.
The DP driver calls the DP PLL driver registration.
The DP driver sets the link and pixel clock sources.
Changes in v2:
-- Update copyright markings on all relevant files.
-- Use DRM_DEBUG_DP for debug msgs.
Changes in v4:
-- Update the DP link clock provider names
Changes in V5:
-- Addressed comments from Stephen Boyd, Rob clark.
Changes in V6:
-- Remove PLL as separate driver and include PLL as DP module
-- Remove redundant clock parsing from PLL module and make DP as
clock provider
-- Map USB3 DPCOM and PHY IO using hardcoded register address and
move mapping form parser to PLL module
-- Access DP PHY modules from same base address using offsets instead of
deriving base address of individual module from device tree.
-- Remove dp_pll_10nm_util.c and include its functionality in
dp_pll_10nm.c
-- Introduce new data structures private to PLL module
Changes in v7:
-- Remove DRM_MSM_DP_PLL config from Makefile and Kconfig
-- Remove set_parent from determin_rate API
-- Remove phy_pll_vco_div_clk from parent list
-- Remove flag CLK_DIVIDER_ONE_BASED
-- Remove redundant cell-index property parsing
Changes in v8:
-- Unregister hardware clocks during driver cleanup
Changes in v9:
-- Remove redundant Kconfig option DRM_MSM_DP_10NM_PLL
Signed-off-by: Chandan Uddaraju
Signed-off-by: Vara Reddy
Signed-off-by: Tanmay Shah
---
drivers/gpu/drm/msm/Kconfig | 1 +
drivers/gpu/drm/msm/Makefile| 4 +-
drivers/gpu/drm/msm/dp/dp_catalog.c | 31 +-
drivers/gpu/drm/msm/dp/dp_display.c | 18 +-
drivers/gpu/drm/msm/dp/dp_display.h | 3 +
drivers/gpu/drm/msm/dp/dp_parser.c | 2 +
drivers/gpu/drm/msm/dp/dp_parser.h | 7 +-
drivers/gpu/drm/msm/dp/dp_pll.c | 99 +++
drivers/gpu/drm/msm/dp/dp_pll.h | 61 ++
drivers/gpu/drm/msm/dp/dp_pll_10nm.c| 917
drivers/gpu/drm/msm/dp/dp_pll_private.h | 98 +++
drivers/gpu/drm/msm/dp/dp_power.c | 10 +
drivers/gpu/drm/msm/dp/dp_power.h | 40 +-
drivers/gpu/drm/msm/dp/dp_reg.h | 16 +
14 files changed, 1290 insertions(+), 17 deletions(-)
create mode 100644 drivers/gpu/drm/msm/dp/dp_pll.c
create mode 100644 drivers/gpu/drm/msm/dp/dp_pll.h
create mode 100644 drivers/gpu/drm/msm/dp/dp_pll_10nm.c
create mode 100644 drivers/gpu/drm/msm/dp/dp_pll_private.h
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 0b59e4f184fb..8e6ca119ea94 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -60,6 +60,7 @@ config DRM_MSM_HDMI_HDCP
config DRM_MSM_DP
bool "Enable DisplayPort support in MSM DRM driver"
depends on DRM_MSM
+ default y
help
Compile in support for DP driver in MSM DRM driver. DP external
display support is enabled through this config option. It can
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index af868e791210..6d31188cc776 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -109,7 +109,9 @@ msm-$(CONFIG_DRM_MSM_DP)+= dp/dp_aux.o \
dp/dp_link.o \
dp/dp_panel.o \
dp/dp_parser.o \
- dp/dp_power.o
+ dp/dp_power.o \
+ dp/dp_pll.o \
+ dp/dp_pll_10nm.o
msm-$(CONFIG_DRM_FBDEV_EMULATION) += msm_fbdev.o
msm-$(CONFIG_COMMON_CLK) += disp/mdp4/mdp4_lvds_pll.o
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index 497f97f86c82..e506e0756e92 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -5,6 +5,7 @@
#define pr_fmt(fmt)"[drm-dp] %s: " fmt, __func__
+#include
#include
#include
#include
@@ -131,51 +132,58 @@ static inline void dp_write_ahb(struct dp_catalog_private
*catalog,
static inline void dp_write_phy(struct dp_catalog_private *catalog,
u32 offset, u32 data)
{
+ offset += DP_PHY_REG_OFFSET;
/*
* To make sure phy reg writes happens before any other operation,
* this function uses writel() instread of writel_relaxed()
*/
- writel(data, catalog->io->phy_io.base + offset);
+ writel(data, catalog->io->phy_reg.base + offset);
}
static inline u32 dp_read_phy(struct dp_catalog_private *catalog,
u32 offset)
{
+ offset += DP_PHY_REG_OFFSET;
/*
* To make sure phy reg writes happens before any other operation,
* this function uses writel() instread of writel_relaxed()
*/
- return readl_relaxed(catalog->io->phy_io.base + offset);
+ return readl_relaxed(catalog->io->phy_reg.base + offset);
}
static inline void dp_write_pll(struct dp_catalog_private *catalog,
u32 offset, u32 data)
{
- writel_relaxed(data, catalog->io->dp_pll_io.base +
[PATCH v10 5/5] drm/msm/dp: Add Display Port HPD feature
Configure HPD registers in DP controller and
enable HPD interrupt.
Add interrupt to handle HPD connect and disconnect events.
Changes in v8: None
Signed-off-by: Tanmay Shah
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 18
drivers/gpu/drm/msm/dp/dp_catalog.c | 63 --
drivers/gpu/drm/msm/dp/dp_catalog.h | 5 +-
drivers/gpu/drm/msm/dp/dp_ctrl.c| 1 -
drivers/gpu/drm/msm/dp/dp_display.c | 108 ++--
drivers/gpu/drm/msm/dp/dp_reg.h | 12 +++
drivers/gpu/drm/msm/msm_drv.h | 6 ++
7 files changed, 180 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index fe86d760ed01..99a83d75ce23 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -765,6 +765,23 @@ static void dpu_irq_preinstall(struct msm_kms *kms)
dpu_core_irq_preinstall(dpu_kms);
}
+static int dpu_irq_postinstall(struct msm_kms *kms)
+{
+ struct msm_drm_private *priv;
+ struct dpu_kms *dpu_kms = to_dpu_kms(kms);
+
+ if (!dpu_kms || !dpu_kms->dev)
+ return -EINVAL;
+
+ priv = dpu_kms->dev->dev_private;
+ if (!priv)
+ return -EINVAL;
+
+ msm_dp_irq_postinstall(priv->dp);
+
+ return 0;
+}
+
static void dpu_irq_uninstall(struct msm_kms *kms)
{
struct dpu_kms *dpu_kms = to_dpu_kms(kms);
@@ -775,6 +792,7 @@ static void dpu_irq_uninstall(struct msm_kms *kms)
static const struct msm_kms_funcs kms_funcs = {
.hw_init = dpu_kms_hw_init,
.irq_preinstall = dpu_irq_preinstall,
+ .irq_postinstall = dpu_irq_postinstall,
.irq_uninstall = dpu_irq_uninstall,
.irq = dpu_irq,
.enable_commit = dpu_kms_enable_commit,
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index e506e0756e92..d186424044b1 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -17,7 +17,6 @@
#define POLLING_SLEEP_US 1000
#define POLLING_TIMEOUT_US 1
-#define REFTIMER_DEFAULT_VALUE 0x2
#define SCRAMBLER_RESET_COUNT_VALUE0xFC
#define DP_INTERRUPT_STATUS_ACK_SHIFT 1
@@ -731,35 +730,51 @@ void dp_catalog_ctrl_enable_irq(struct dp_catalog
*dp_catalog,
}
}
-void dp_catalog_ctrl_hpd_config(struct dp_catalog *dp_catalog, bool en)
+void dp_catalog_hpd_config_intr(struct dp_catalog *dp_catalog,
+ u32 intr_mask, bool en)
{
struct dp_catalog_private *catalog = container_of(dp_catalog,
struct dp_catalog_private, dp_catalog);
- if (en) {
- u32 reftimer = dp_read_aux(catalog, REG_DP_DP_HPD_REFTIMER);
+ u32 config = dp_read_aux(catalog, REG_DP_DP_HPD_INT_MASK);
- dp_write_aux(catalog, REG_DP_DP_HPD_INT_ACK,
- DP_DP_HPD_PLUG_INT_ACK |
- DP_DP_IRQ_HPD_INT_ACK |
- DP_DP_HPD_REPLUG_INT_ACK |
- DP_DP_HPD_UNPLUG_INT_ACK);
- dp_write_aux(catalog, REG_DP_DP_HPD_INT_MASK,
- DP_DP_HPD_PLUG_INT_MASK |
- DP_DP_IRQ_HPD_INT_MASK |
- DP_DP_HPD_REPLUG_INT_MASK |
- DP_DP_HPD_UNPLUG_INT_MASK);
+ config = (en ? config | intr_mask : config & ~intr_mask);
- /* Configure REFTIMER */
- reftimer |= REFTIMER_DEFAULT_VALUE;
- dp_write_aux(catalog, REG_DP_DP_HPD_REFTIMER, reftimer);
- /* Enable HPD */
- dp_write_aux(catalog, REG_DP_DP_HPD_CTRL,
- DP_DP_HPD_CTRL_HPD_EN);
- } else {
- /* Disable HPD */
- dp_write_aux(catalog, REG_DP_DP_HPD_CTRL, 0x0);
- }
+ dp_write_aux(catalog, REG_DP_DP_HPD_INT_MASK,
+ config & DP_DP_HPD_INT_MASK);
+}
+
+void dp_catalog_ctrl_hpd_config(struct dp_catalog *dp_catalog)
+{
+ struct dp_catalog_private *catalog = container_of(dp_catalog,
+ struct dp_catalog_private, dp_catalog);
+
+ u32 reftimer = dp_read_aux(catalog, REG_DP_DP_HPD_REFTIMER);
+
+ /* enable HPD interrupts */
+ dp_catalog_hpd_config_intr(dp_catalog,
+ DP_DP_HPD_PLUG_INT_MASK | DP_DP_IRQ_HPD_INT_MASK
+ | DP_DP_HPD_UNPLUG_INT_MASK, true);
+
+ /* Configure REFTIMER and enable it */
+ reftimer |= DP_DP_HPD_REFTIMER_ENABLE;
+ dp_write_aux(catalog, REG_DP_DP_HPD_REFTIMER, reftimer);
+
+ /* Enable HPD */
+ dp_write_aux(catalog, REG_DP_DP_HPD_CTRL, DP_DP_HPD_CTRL_HPD_EN);
+}
+
+u32 dp_catalog_hpd_get_intr_status(struct dp_catalog *dp_catalog)
+{
+ struct
[PATCH v10 4/5] drm/msm/dpu: add display port support in DPU
From: Jeykumar Sankaran
Add display port support in DPU by creating hooks
for DP encoder enumeration and encoder mode
initialization.
changes in v2:
- rebase on [2] (Sean Paul)
- remove unwanted error checks and
switch cases (Jordan Crouse)
[1] https://lwn.net/Articles/768265/
[2] https://lkml.org/lkml/2018/11/17/87
changes in V3:
-- Moved this change as part of the DP driver changes.
-- Addressed compilation issues on the latest code base.
Changes in v6:
-- Fix checkpatch.pl warning
Changes in v7: Remove depends-on tag from commit message.
Changes in v8: None
Changes in v9: None
Signed-off-by: Jeykumar Sankaran
Signed-off-by: Chandan Uddaraju
Signed-off-by: Vara Reddy
Signed-off-by: Tanmay Shah
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 8 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 65 +
2 files changed, 58 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 0a5ad6a9e609..fe0d538099f9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1992,7 +1992,7 @@ static int dpu_encoder_setup_display(struct
dpu_encoder_virt *dpu_enc,
{
int ret = 0;
int i = 0;
- enum dpu_intf_type intf_type;
+ enum dpu_intf_type intf_type = INTF_NONE;
struct dpu_enc_phys_init_params phys_params;
if (!dpu_enc) {
@@ -2014,9 +2014,9 @@ static int dpu_encoder_setup_display(struct
dpu_encoder_virt *dpu_enc,
case DRM_MODE_ENCODER_DSI:
intf_type = INTF_DSI;
break;
- default:
- DPU_ERROR_ENC(dpu_enc, "unsupported display interface type\n");
- return -EINVAL;
+ case DRM_MODE_ENCODER_TMDS:
+ intf_type = INTF_DP;
+ break;
}
WARN_ON(disp_info->num_of_h_tiles < 1);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 680527e28d09..fe86d760ed01 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -492,6 +492,33 @@ static int _dpu_kms_initialize_dsi(struct drm_device *dev,
return rc;
}
+static int _dpu_kms_initialize_displayport(struct drm_device *dev,
+ struct msm_drm_private *priv,
+ struct dpu_kms *dpu_kms)
+{
+ struct drm_encoder *encoder = NULL;
+ int rc = 0;
+
+ if (!priv->dp)
+ return rc;
+
+ encoder = dpu_encoder_init(dev, DRM_MODE_ENCODER_TMDS);
+ if (IS_ERR(encoder)) {
+ DPU_ERROR("encoder init failed for dsi display\n");
+ return PTR_ERR(encoder);
+ }
+
+ rc = msm_dp_modeset_init(priv->dp, dev, encoder);
+ if (rc) {
+ DPU_ERROR("modeset_init failed for DP, rc = %d\n", rc);
+ drm_encoder_cleanup(encoder);
+ return rc;
+ }
+
+ priv->encoders[priv->num_encoders++] = encoder;
+ return rc;
+}
+
/**
* _dpu_kms_setup_displays - create encoders, bridges and connectors
* for underlying displays
@@ -504,12 +531,21 @@ static int _dpu_kms_setup_displays(struct drm_device *dev,
struct msm_drm_private *priv,
struct dpu_kms *dpu_kms)
{
- /**
-* Extend this function to initialize other
-* types of displays
-*/
+ int rc = 0;
+
+ rc = _dpu_kms_initialize_dsi(dev, priv, dpu_kms);
+ if (rc) {
+ DPU_ERROR("initialize_dsi failed, rc = %d\n", rc);
+ return rc;
+ }
- return _dpu_kms_initialize_dsi(dev, priv, dpu_kms);
+ rc = _dpu_kms_initialize_displayport(dev, priv, dpu_kms);
+ if (rc) {
+ DPU_ERROR("initialize_DP failed, rc = %d\n", rc);
+ return rc;
+ }
+
+ return rc;
}
static void _dpu_kms_drm_obj_destroy(struct dpu_kms *dpu_kms)
@@ -694,13 +730,20 @@ static void _dpu_kms_set_encoder_mode(struct msm_kms *kms,
info.capabilities = cmd_mode ? MSM_DISPLAY_CAP_CMD_MODE :
MSM_DISPLAY_CAP_VID_MODE;
- /* TODO: No support for DSI swap */
- for (i = 0; i < ARRAY_SIZE(priv->dsi); i++) {
- if (priv->dsi[i]) {
- info.h_tile_instance[info.num_of_h_tiles] = i;
- info.num_of_h_tiles++;
+ switch (info.intf_type) {
+ case DRM_MODE_ENCODER_DSI:
+ /* TODO: No support for DSI swap */
+ for (i = 0; i < ARRAY_SIZE(priv->dsi); i++) {
+ if (priv->dsi[i]) {
+ info.h_tile_instance[info.num_of_h_tiles] = i;
+ info.num_of_h_tiles++;
+ }
}
- }
+
Re: [PATCH v5 0/4] Allow bigger 64bit window by removing default DMA window
Hello Michael, Do you suggest any change for this patchset? Any chance it can get in this merge window? Best regards, Leonardo Bras On Wed, 2020-08-05 at 00:04 -0300, Leonardo Bras wrote: > There are some devices in which a hypervisor may only allow 1 DMA window > to exist at a time, and in those cases, a DDW is never created to them, > since the default DMA window keeps using this resource. > > LoPAR recommends this procedure: > 1. Remove the default DMA window, > 2. Query for which configs the DDW can be created, > 3. Create a DDW. > > Patch #1: > Create defines for outputs of ibm,ddw-applicable, so it's easier to > identify them. > > Patch #2: > - After LoPAR level 2.8, there is an extension that can make > ibm,query-pe-dma-windows to have 6 outputs instead of 5. This changes the > order of the outputs, and that can cause some trouble. > - query_ddw() was updated to check how many outputs the > ibm,query-pe-dma-windows is supposed to have, update the rtas_call() and > deal correctly with the outputs in both cases. > - This patch looks somehow unrelated to the series, but it can avoid future > problems on DDW creation. > > Patch #3 moves the window-removing code from remove_ddw() to > remove_dma_window(), creating a way to delete any DMA window, so it can be > used to delete the default DMA window. > > Patch #4 makes use of the remove_dma_window() from patch #3 to remove the > default DMA window before query_ddw(). It also implements a new rtas call > to recover the default DMA window, in case anything fails after it was > removed, and a DDW couldn't be created. > > --- > Changes since v4: > - Removed patches 5+ in order to deal with a feature at a time > - Remove unnecessary parentesis in patch #4 > - Changed patch #4 title from > "Remove default DMA window before creating DDW" > - Included David Dai tested-by > - v4 link: > http://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=190051=%2A=both > > Changes since v3: > - Introduces new patch #5, to prepare for an important change in #6 > - struct iommu_table was not being updated, so include a way to do this > in patch #6. > - Improved patch #4 based in a suggestion from Alexey, to make code > more easily understandable > - v3 link: > http://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=187348=%2A=both > > Changes since v2: > - Change the way ibm,ddw-extensions is accessed, using a proper function > instead of doing this inline everytime it's used. > - Remove previous patch #6, as it doesn't look like it would be useful. > - Add new patch, for changing names from direct* to dma*, as indirect > mapping can be used from now on. > - Fix some typos, corrects some define usage. > - v2 link: > http://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=185433=%2A=both > > Changes since v1: > - Add defines for ibm,ddw-applicable and ibm,ddw-extensions outputs > - Merge aux function query_ddw_out_sz() into query_ddw() > - Merge reset_dma_window() patch (prev. #2) into remove default DMA > window patch (#4). > - Keep device_node *np name instead of using pdn in remove_*() > - Rename 'device_node *pdn' into 'parent' in new functions > - Rename dfl_win to default_win > - Only remove the default DMA window if there is no window available > in first query. > - Check if default DMA window can be restored before removing it. > - Fix 'unitialized use' (found by travis mpe:ci-test) > - New patches #5 and #6 > - v1 link: > http://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=184420=%2A=both > > Special thanks for Alexey Kardashevskiy, Brian King and > Oliver O'Halloran for the feedback provided! > > > Leonardo Bras (4): > powerpc/pseries/iommu: Create defines for operations in > ibm,ddw-applicable > powerpc/pseries/iommu: Update call to ibm,query-pe-dma-windows > powerpc/pseries/iommu: Move window-removing part of remove_ddw into > remove_dma_window > powerpc/pseries/iommu: Allow bigger 64bit window by removing default > DMA window > > arch/powerpc/platforms/pseries/iommu.c | 242 - > 1 file changed, 195 insertions(+), 47 deletions(-) >
[PATCH v10 1/5] drm: add constant N value in helper file
From: Chandan Uddaraju The constant N value (0x8000) is used by i915 DP driver. Define this value in dp helper header file to use in multiple Display Port drivers. Change i915 driver accordingly. Change in v6: Change commit message Signed-off-by: Chandan Uddaraju Signed-off-by: Vara Reddy Signed-off-by: Tanmay Shah Reviewed-by: Stephen Boyd Acked-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_display.c | 2 +- include/drm/drm_dp_helper.h | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 729ec6e0d43a..10b8310f290b 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -8114,7 +8114,7 @@ static void compute_m_n(unsigned int m, unsigned int n, * which the devices expect also in synchronous clock mode. */ if (constant_n) - *ret_n = 0x8000; + *ret_n = DP_LINK_CONSTANT_N_VALUE; else *ret_n = min_t(unsigned int, roundup_pow_of_two(n), DATA_LINK_N_MAX); diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index e47dc22ebf50..a31d7aebb8b8 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -1134,6 +1134,7 @@ #define DP_MST_PHYSICAL_PORT_0 0 #define DP_MST_LOGICAL_PORT_0 8 +#define DP_LINK_CONSTANT_N_VALUE 0x8000 #define DP_LINK_STATUS_SIZE 6 bool drm_dp_channel_eq_ok(const u8 link_status[DP_LINK_STATUS_SIZE], int lane_count); -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v10 0/5] Add support for DisplayPort driver on SnapDragon
These patches add Display-Port driver on SnapDragon/msm hardware. This series also contains device-tree bindings for msm DP driver. It also contains Makefile and Kconfig changes to compile msm DP driver. The block diagram of DP driver is shown below: +-+ |DRM FRAMEWORK| +--+--+ | +v+ | DP DRM | +++ | +v+ ++| DP+--++--+ ++---+| DISPLAY |+---+ | | |++-+-+-+| | | || | | | | | || | | | | | || | | | | | vv v v v v v +--+ +--+ +---+ ++ ++ +---+ +-+ | DP | | DP | |DP | | DP | | DP | |DP | | DP | |PARSER| | HPD | |AUX| |LINK| |CTRL| |PHY| |POWER| +--+---+ +---+--+ +---+ ++ +--+-+ +-+-+ +-+ | | | +--v---+ +v-v+ |DEVICE| | DP | | TREE | |CATALOG| +--+ +---+---+ | +---v+ |CTRL/PHY| | HW | ++ Changes in v7: - Modify cover letter description and fix title. - Introduce dp-controller.yaml for common bindings across SOC - Rename dp-sc7180.yaml to dp-controller-sc7180.yaml for SC7180 bindings - Rename compatible string to qcom,sc7180-dp - Add assigned-clocks and assigned-clock-parents properties in bindings - Remove redundant code from driver - Extend series to include HPD detection logic Changes in v8: - Add MDSS AHB clock in bindings - Replace mode->vrefresh use with drm_mode_vrefresh API - Remove redundant aux config code from parser and aux module - Assign default max lanes if data-lanes property is not available - Fix use-after-free during DP driver remove - Unregister hardware clocks during driver cleanup Changes in v9: - Drop YAML bindings change from the series - Use assigne-clock-parents property and remove clk_set_parent use from code - Access register address space without name - Fix DP register dump utility - Disable DP clocks after vsync generated - Avoid 64-bit modulo operation - Drop any unused code and fix function proptotyes to avoid W=1 warnings - Drop DRM_MSM_DP_10NM_PLL config as only 10nm PLL is available Changes in v10: - Fix help description of Kconfig entry Chandan Uddaraju (4): dt-bindings: msm/dp: add bindings of DP/DP-PLL driver for Snapdragon drm: add constant N value in helper file drm/msm/dp: add displayPort driver support drm/msm/dp: add support for DP PLL driver Jeykumar Sankaran (1): drm/msm/dpu: add display port support in DPU Tanmay Shah (1): drm/msm/dp: Add Display Port HPD feature drivers/gpu/drm/i915/display/intel_display.c |2 +- drivers/gpu/drm/msm/Kconfig |9 + drivers/gpu/drm/msm/Makefile | 14 + drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 27 +- .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c |8 + drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 83 +- drivers/gpu/drm/msm/dp/dp_aux.c | 510 + drivers/gpu/drm/msm/dp/dp_aux.h | 29 + drivers/gpu/drm/msm/dp/dp_catalog.c | 1030 ++ drivers/gpu/drm/msm/dp/dp_catalog.h | 104 + drivers/gpu/drm/msm/dp/dp_ctrl.c | 1693 + drivers/gpu/drm/msm/dp/dp_ctrl.h | 35 + drivers/gpu/drm/msm/dp/dp_display.c | 1017 ++ drivers/gpu/drm/msm/dp/dp_display.h | 31 + drivers/gpu/drm/msm/dp/dp_drm.c | 168 ++ drivers/gpu/drm/msm/dp/dp_drm.h | 18 + drivers/gpu/drm/msm/dp/dp_hpd.c | 69 + drivers/gpu/drm/msm/dp/dp_hpd.h | 79 + drivers/gpu/drm/msm/dp/dp_link.c | 1214 drivers/gpu/drm/msm/dp/dp_link.h | 132 ++ drivers/gpu/drm/msm/dp/dp_panel.c | 486 + drivers/gpu/drm/msm/dp/dp_panel.h | 95 + drivers/gpu/drm/msm/dp/dp_parser.c| 269 +++ drivers/gpu/drm/msm/dp/dp_parser.h| 138 ++ drivers/gpu/drm/msm/dp/dp_pll.c | 99 + drivers/gpu/drm/msm/dp/dp_pll.h | 61 + drivers/gpu/drm/msm/dp/dp_pll_10nm.c | 917 + drivers/gpu/drm/msm/dp/dp_pll_private.h | 98 + drivers/gpu/drm/msm/dp/dp_power.c | 373 drivers/gpu/drm/msm/dp/dp_power.h | 103 + drivers/gpu/drm/msm/dp/dp_reg.h | 517 + drivers/gpu/drm/msm/msm_drv.c |2 +
Re: [PATCH] opp: Fix dev_pm_opp_set_rate() to not return early
On 8/11/2020 10:42 PM, Matthias Kaehlcke wrote:
On Mon, Aug 10, 2020 at 12:36:19PM +0530, Rajendra Nayak wrote:
dev_pm_opp_set_rate() can now be called with freq = 0 inorder
to either drop performance or bandwidth votes or to disable
regulators on platforms which support them.
In such cases, a subsequent call to dev_pm_opp_set_rate() with
the same frequency ends up returning early because 'old_freq == freq'
Instead make it fall through and put back the dropped performance
and bandwidth votes and/or enable back the regulators.
Fixes: cd7ea582 ("opp: Make dev_pm_opp_set_rate() handle freq = 0 to drop
performance votes")
Reported-by: Sajida Bhanu
Signed-off-by: Rajendra Nayak
Tested-by: Matthias Kaehlcke
Originally-reported-by: Matthias Kaehlcke
https://patchwork.kernel.org/patch/11675369/#23514895 :P
Sorry to have missed that :/
Thanks for testing.
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag
On Wed, Aug 12, 2020 at 02:13:25AM +0200, Thomas Gleixner wrote: > "Paul E. McKenney" writes: > > Hence Ulad's work on kfree_rcu(). The approach is to allocate a > > page-sized array to hold all the pointers, then fill in the rest of these > > pointers on each subsequent kfree_rcu() call. These arrays of pointers > > also allows use of kfree_bulk() instead of kfree(), which can improve > > performance yet more. It is no big deal if kfree_rcu()'s allocation > > attempts fail occasionally because it can simply fall back to the old > > linked-list approach. And given that the various lockless caches in > > the memory allocator are almost never empty, in theory life is good. > > Of course, it's always the damned reality which ruins the fun. Classic!!! And yes, it always is! > > But in practice, mainline now has CONFIG_PROVE_RAW_LOCK_NESTING, > > and for good reason -- this Kconfig option makes it at least a > > little bit harder for mainline developers to mess up RT. But with > > CONFIG_PROVE_RAW_LOCK_NESTING=y and lockdep enabled, mainline will now > > sometimes complain if you invoke kfree_rcu() while holding a raw spinlock. > > This happens when kfree_rcu() needs to invoke the memory allocator and > > the memory allocator's caches are empty, thus resulting in the memory > > allocator attempting to acquire a non-raw spinlock. > > Right. > > > Because kfree_rcu() has a fallback available (just using the old linked > > list), kfree_rcu() would work well given a way to tell the memory > > allocator to return NULL instead of acquiring a non-raw spinlock. > > Which is exactly what Ulad's recent patches are intended to do. > > That much I understood, but I somehow failed to figure the why out > despite the elaborate changelog. 2 weeks of 30+C seem to have cooked my > brain :) Ouch!!! And what on earth is Germany doing being that warm??? I hate it when that happens... > > Since then, this thread has discussed various other approaches, > > including using existing combinations of GFP_ flags, converting > > the allocator's zone lock to a raw spinlock, and so on. > > > > Does that help, or am I missing the point of your question? > > Yes, that helps so far that I understand what the actual problem is. It > does not really help to make me more happy. :) I must confess that I was not expecting to find anything resembling happiness anywhere down this road, whether for myself or anyone else... > That said, we can support atomic allocations on RT up to the point where > zone->lock comes into play. We don't know yet exactly where the > zone->lock induced damage happens. Presumably it's inside > free_pcppages_bulk() - at least that's where I have faint bad memories > from 15+ years ago. Aside of that I seriously doubt that it can be made > work within a reasonable time frame. I was not considering any approach other than return NULL just before the code would otherwise have acquired zone->lock. > But what makes me really unhappy is that my defense line against > allocations from truly atomic contexts (from RT POV) which was enforced > on RT gets a real big gap shot into it. Understood, and agreed: We do need to keep the RT degradation in check. > It becomes pretty hard to argue why atomic allocations via kmalloc() or > kmem_cache_alloc() should be treated any different. Technically they can > work similar to the page allocations up to the point where regular > spinlocks come into play or the slab cache is exhausted. Where to draw > the line? > > It's also unclear for the page allocator case whether we can and should > stick a limit on the number of pages and/or the pageorder. > > Myself and others spent a considerable amount of time to kill off these > kind of allocations from various interesting places including the guts > of send IPI, the affinity setting path and others where people just > slapped allocations into them because the stack checker warned or > because they happened to copy the code from some other place. > > RT was pretty much a quick crap detector whenever new incarnations of > this got added and to some extent continuous education about these > issues made them less prominent over the years. Using atomic allocations > should always have a real good rationale, not only in the cases where > they collide with RT. > > I can understand your rationale and what you are trying to solve. So, if > we can actually have a distinct GFP variant: > > GFP_I_ABSOLUTELY_HAVE_TO_DO_THAT_AND_I_KNOW_IT_CAN_FAIL_EARLY > > which is easy to grep for then having the page allocator go down to the > point where zone lock gets involved is not the end of the world for > RT in theory - unless that damned reality tells otherwise. :) I have no objection to an otherwise objectionable name in this particular case. After all, we now have 100 characters per line, right? ;-) > The page allocator allocations should also have a limit on the number of > pages and eventually also page order (need to stare at
Re: [PATCH] Re: KASAN: use-after-free Read in path_init (2)
On Tue, Aug 11, 2020 at 9:15 PM Al Viro wrote: > > fix breakage in do_rmdir() > > putname() should happen only after we'd *not* branched to > retry, same as it's done in do_unlinkat(). Looks obviously correct. Do you want me to apply directly, or do you have other fixes pending and I'll get a pull request? Linus
linux-next: Tree for Aug 12
Hi all,
News: The merge window has opened, so please do not add any v5.10
related material to your linux-next included branches until after the
merge window closes again.
Changes since 20200811:
Dropped tree: set_fs at maintainer's request
My fixes tree contains:
73c7adb54169 ("device_cgroup: Fix RCU list debugging warning")
The tip tree gained a conflict against Linus' tree.
Non-merge commits (relative to Linus' tree): 1382
1597 files changed, 41786 insertions(+), 15627 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 327 trees (counting Linus' and 85 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 (bb5baaa9238e Merge tag 'arm64-fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux)
Merging fixes/master (73c7adb54169 device_cgroup: Fix RCU list debugging
warning)
Merging kbuild-current/fixes (06a81c1c7db9 Merge tag 'arm64-fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux)
Merging arc-current/for-curr (11ba468877bb Linux 5.8-rc5)
Merging arm-current/fixes (5c6360ee4a0e ARM: 8988/1: mmu: fix crash in EFI
calls due to p4d typo in create_mapping_late())
Merging arm64-fixes/for-next/fixes (6a7389f0312f MAINTAINERS: Include drivers
subdirs for ARM PMU PROFILING AND DEBUGGING entry)
Merging arm-soc-fixes/arm/fixes (fe1d899f4212 ARM: dts: keystone-k2g-evm: fix
rgmii phy-mode for ksz9031 phy)
Merging uniphier-fixes/fixes (48778464bb7d Linux 5.8-rc2)
Merging drivers-memory-fixes/fixes (b3a9e3b9622a Linux 5.8-rc1)
Merging m68k-current/for-linus (382f429bb559 m68k: defconfig: Update defconfigs
for v5.8-rc3)
Merging powerpc-fixes/fixes (6553fb799f60 powerpc/pkeys: Fix boot failures with
Nemo board (A-EON AmigaOne X1000))
Merging s390-fixes/fixes (00e4db51259a Merge tag 'perf-tools-2020-08-10' of
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux)
Merging sparc/master (0a95a6d1a4cd sparc: use for_each_child_of_node() macro)
Merging fscrypt-current/for-stable (2b4eae95c736 fscrypt: don't evict dirty
inodes after removing key)
Merging net/master (1b8ef1423dbf net: phy: marvell10g: fix null pointer
dereference)
Merging bpf/master (da7bdfdd23b8 selftests/bpf: Fix v4_to_v6 in sk_lookup)
Merging ipsec/master (61ee4137b574 ip_vti: Fix unused variable warning)
Merging netfilter/master (2f941622fd88 netfilter: nft_compat: remove flush
counter optimization)
Merging ipvs/master (7c7ab580db49 net: Convert to use the fallthrough macro)
Merging wireless-drivers/master (1cfd3426ef98 ath10k: Fix NULL pointer
dereference in AHB device probe)
Merging mac80211/master (ac3a0c847296 Merge
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net)
Merging rdma-fixes/for-rc (bcf876870b95 Linux 5.8)
Merging sound-current/for-linus (404690649e6a ALSA: hda - reverse the setting
value in the micmute_led_set)
Merging sound-asoc-fixes/for-linus (b6448e0359f1 Merge remote-tracking branch
'asoc/for-5.9' into asoc-linus)
Merging regmap-fixes/for-linus (2b0f61e27f75 Merge remote-tracking branch
'regmap/for-5.8' into regmap-linus)
Merging regulator-fixes/for-linus (75f4d068cb0d Merge remote-tracking branch
'regulator/for-5.9' into regulator-linus)
Merging spi-fixes/for-linus (3ea884314328 Merge remote-tracking branch
'spi/for-5.9' into
Re: drivers/dma/xilinx/xilinx_dpdma.c:1172 xilinx_dpdma_synchronize() error: double unlocked 'chan->vchan.lock' (orig line 1170)
HI Laurent,
On 12-08-20, 01:50, Laurent Pinchart wrote:
> On Wed, Aug 12, 2020 at 06:37:59AM +0800, kernel test robot wrote:
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > master
> > head: c636eef2ee3696f261a35f34989842701a107895
> > commit: 7cbb0c63de3fc218fd06ecfedb42a4d12f76 dmaengine: xilinx: dpdma:
> > Add the Xilinx DisplayPort DMA engine driver
> > date: 4 weeks ago
> > config: h8300-randconfig-m031-20200811 (attached as .config)
> > compiler: h8300-linux-gcc (GCC) 9.3.0
> >
> > If you fix the issue, kindly add following tag as appropriate
> > Reported-by: kernel test robot
> >
> > smatch warnings:
> > drivers/dma/xilinx/xilinx_dpdma.c:1172 xilinx_dpdma_synchronize() error:
> > double unlocked 'chan->vchan.lock' (orig line 1170)
>
> Unless I'm mistaken, this is a false positive. I'd appreciate if someone
> could check if I'm missing something obvious.
>
> > vim +1172 drivers/dma/xilinx/xilinx_dpdma.c
> >
> > 1140
> > 1141 /**
> > 1142 * xilinx_dpdma_synchronize - Synchronize callback execution
> > 1143 * @dchan: DMA channel
> > 1144 *
> > 1145 * Synchronizing callback execution ensures that all previously
> > issued
> > 1146 * transfers have completed and all associated callbacks have
> > been called and
> > 1147 * have returned.
> > 1148 *
> > 1149 * This function waits for the DMA channel to stop. It assumes
> > it has been
> > 1150 * paused by a previous call to dmaengine_terminate_async(),
> > and that no new
> > 1151 * pending descriptors have been issued with
> > dma_async_issue_pending(). The
> > 1152 * behaviour is undefined otherwise.
> > 1153 */
> > 1154 static void xilinx_dpdma_synchronize(struct dma_chan *dchan)
> > 1155 {
> > 1156 struct xilinx_dpdma_chan *chan = to_xilinx_chan(dchan);
> > 1157 unsigned long flags;
> > 1158
> > 1159 xilinx_dpdma_chan_stop(chan);
> > 1160
> > 1161 spin_lock_irqsave(>vchan.lock, flags);
Lock is held here
> > 1162 if (chan->desc.pending) {
> > 1163
> > vchan_terminate_vdesc(>desc.pending->vdesc);
This should be called with lock held
> > 1164 chan->desc.pending = NULL;
> > 1165 }
> > 1166 if (chan->desc.active) {
> > 1167
> > vchan_terminate_vdesc(>desc.active->vdesc);
same here
> > 1168 chan->desc.active = NULL;
> > 1169 }
> > > 1170 spin_unlock_irqrestore(>vchan.lock, flags);
Dropped
> > 1171
> > > 1172 vchan_synchronize(>vchan);
This should be called without lock
So I agree with you, looks like a false positive to me as well
--
~Vinod
[PATCH] Re: KASAN: use-after-free Read in path_init (2)
On Tue, Aug 11, 2020 at 08:17:16PM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:5631c5e0 Merge tag 'xfs-5.9-merge-7' of git://git.kernel.o..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1707698490
> kernel config: https://syzkaller.appspot.com/x/.config?x=afba7c06f91e56eb
> dashboard link: https://syzkaller.appspot.com/bug?extid=bbeb1c88016c7db4aa24
> compiler: gcc (GCC) 10.1.0-syz 20200507
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1502ce0290
fix breakage in do_rmdir()
putname() should happen only after we'd *not* branched to
retry, same as it's done in do_unlinkat().
Fixes: e24ab0ef689d "fs: push the getname from do_rmdir into the callers"
Signed-off-by: Al Viro
---
diff --git a/fs/namei.c b/fs/namei.c
index fde8fe086c09..9fa10c614de7 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -3770,11 +3770,11 @@ long do_rmdir(int dfd, struct filename *name)
mnt_drop_write(path.mnt);
exit1:
path_put();
- putname(name);
if (retry_estale(error, lookup_flags)) {
lookup_flags |= LOOKUP_REVAL;
goto retry;
}
+ putname(name);
return error;
}
Re: [External] Re: [PATCH] x86/MCE/AMD, EDAC/mce_amd
Ok, as more AMD servers are used in bytedance, we hope to issue a patch to the community as soon as possible. Thank you very much. 在 2020/8/11 上午3:10, Yazen Ghannam 写道: On Sun, Aug 09, 2020 at 12:35:59PM +0800, Feng zhou wrote: From: zhoufeng The edac_mce_amd module calls decode_dram_ecc() on AMD Family17h and later systems. This function is used in amd64_edac_mod to do system-specific decoding for DRAM ECC errors. The function takes a "NodeId" as a parameter. In AMD documentation, NodeId is used to identify a physical die in a system. This can be used to identify a node in the AMD_NB code and also it is used with umc_normaddr_to_sysaddr(). However, the input used for decode_dram_ecc() is currently the NUMA node of a logical CPU. so this will cause the address translation function to fail or report incorrect results. Signed-off-by: zhoufeng --- drivers/edac/mce_amd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/edac/mce_amd.c b/drivers/edac/mce_amd.c index 325aedf46ff2..73c805113322 100644 --- a/drivers/edac/mce_amd.c +++ b/drivers/edac/mce_amd.c @@ -996,7 +996,7 @@ static void decode_smca_error(struct mce *m) } if (bank_type == SMCA_UMC && xec == 0 && decode_dram_ecc) - decode_dram_ecc(cpu_to_node(m->extcpu), m); + decode_dram_ecc(topology_physical_package_id(m->extcpu), m); This will break on Naples systems, because the NodeId and the physical package ID will not match. I can send a patch soon that will work for Naples, Rome, and later systems. Thanks, Yazen
[PATCH 3/3] mm: remove superfluous __ClearPageWaiters()
Presumably __ClearPageWaiters() was added to follow the previously
removed __ClearPageActive() pattern.
Only flags that are in PAGE_FLAGS_CHECK_AT_FREE needs to be properly
cleared because otherwise we think there may be some kind of leak.
PG_waiters is not one of those flags and leaving the clearing to
PAGE_FLAGS_CHECK_AT_PREP is more appropriate.
Signed-off-by: Yu Zhao
---
include/linux/page-flags.h | 2 +-
mm/filemap.c | 2 ++
mm/memremap.c | 2 --
mm/swap.c | 3 ---
4 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index 6be1aa559b1e..dba80a2bdfba 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -318,7 +318,7 @@ static inline int TestClearPage##uname(struct page *page) {
return 0; }
TESTSETFLAG_FALSE(uname) TESTCLEARFLAG_FALSE(uname)
__PAGEFLAG(Locked, locked, PF_NO_TAIL)
-PAGEFLAG(Waiters, waiters, PF_ONLY_HEAD) __CLEARPAGEFLAG(Waiters, waiters,
PF_ONLY_HEAD)
+PAGEFLAG(Waiters, waiters, PF_ONLY_HEAD)
PAGEFLAG(Error, error, PF_NO_TAIL) TESTCLEARFLAG(Error, error, PF_NO_TAIL)
PAGEFLAG(Referenced, referenced, PF_HEAD)
TESTCLEARFLAG(Referenced, referenced, PF_HEAD)
diff --git a/mm/filemap.c b/mm/filemap.c
index f2bb5ff0293d..8a096844ddad 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1079,6 +1079,8 @@ static void wake_up_page_bit(struct page *page, int
bit_nr)
* other pages on it.
*
* That's okay, it's a rare case. The next waker will clear it.
+* Otherwise the bit will be cleared by PAGE_FLAGS_CHECK_AT_PREP
+* when the page is being freed.
*/
}
spin_unlock_irqrestore(>lock, flags);
diff --git a/mm/memremap.c b/mm/memremap.c
index 3a06eb91cb59..a9d02ffaf9e3 100644
--- a/mm/memremap.c
+++ b/mm/memremap.c
@@ -451,8 +451,6 @@ void free_devmap_managed_page(struct page *page)
return;
}
- __ClearPageWaiters(page);
-
mem_cgroup_uncharge(page);
/*
diff --git a/mm/swap.c b/mm/swap.c
index 1f223a02549d..6129692752a5 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -90,7 +90,6 @@ static void __page_cache_release(struct page *page)
del_page_from_lru_list(page, lruvec, page_off_lru(page));
spin_unlock_irqrestore(>lru_lock, flags);
}
- __ClearPageWaiters(page);
}
static void __put_single_page(struct page *page)
@@ -898,8 +897,6 @@ void release_pages(struct page **pages, int nr)
del_page_from_lru_list(page, lruvec,
page_off_lru(page));
}
- __ClearPageWaiters(page);
-
list_add(>lru, _to_free);
}
if (locked_pgdat)
--
2.28.0.236.gb10cc79966-goog
[PATCH 2/3] mm: remove superfluous __ClearPageActive()
To activate a page, mark_page_accessed() always holds a reference on it. It either gets a new reference when adding a page to lru_pvecs.activate_page or reuses an existing one it previously got when it added a page to lru_pvecs.lru_add. So it can't call SetPageActive() on a page that doesn't have any reference left. Therefore, the race is impossible, not these days (I didn't brother to dig into its history). For other paths, namely reclaim and migration, a reference count is always held while calling SetPageActive() on a page. SetPageSlabPfmemalloc() also uses SetPageActive(), but it's irrelevant to LRU pages. Signed-off-by: Yu Zhao --- mm/memremap.c | 2 -- mm/swap.c | 2 -- 2 files changed, 4 deletions(-) diff --git a/mm/memremap.c b/mm/memremap.c index 03e38b7a38f1..3a06eb91cb59 100644 --- a/mm/memremap.c +++ b/mm/memremap.c @@ -451,8 +451,6 @@ void free_devmap_managed_page(struct page *page) return; } - /* Clear Active bit in case of parallel mark_page_accessed */ - __ClearPageActive(page); __ClearPageWaiters(page); mem_cgroup_uncharge(page); diff --git a/mm/swap.c b/mm/swap.c index de257c0a89b1..1f223a02549d 100644 --- a/mm/swap.c +++ b/mm/swap.c @@ -898,8 +898,6 @@ void release_pages(struct page **pages, int nr) del_page_from_lru_list(page, lruvec, page_off_lru(page)); } - /* Clear Active bit in case of parallel mark_page_accessed */ - __ClearPageActive(page); __ClearPageWaiters(page); list_add(>lru, _to_free); -- 2.28.0.236.gb10cc79966-goog
RE: [PATCH RFC v2 00/18] Add VFIO mediated device support and DEV-MSI support for the idxd driver
> From: Jason Wang > Sent: Wednesday, August 12, 2020 11:28 AM > > > On 2020/8/10 下午3:32, Tian, Kevin wrote: > >> From: Jason Gunthorpe > >> Sent: Friday, August 7, 2020 8:20 PM > >> > >> On Wed, Aug 05, 2020 at 07:22:58PM -0600, Alex Williamson wrote: > >> > >>> If you see this as an abuse of the framework, then let's identify those > >>> specific issues and come up with a better approach. As we've discussed > >>> before, things like basic PCI config space emulation are acceptable > >>> overhead and low risk (imo) and some degree of register emulation is > >>> well within the territory of an mdev driver. > >> What troubles me is that idxd already has a direct userspace interface > >> to its HW, and does userspace DMA. The purpose of this mdev is to > >> provide a second direct userspace interface that is a little different > >> and trivially plugs into the virtualization stack. > > No. Userspace DMA and subdevice passthrough (what mdev provides) > > are two distinct usages IMO (at least in idxd context). and this might > > be the main divergence between us, thus let me put more words here. > > If we could reach consensus in this matter, which direction to go > > would be clearer. > > > > First, a passthrough interface requires some unique requirements > > which are not commonly observed in an userspace DMA interface, e.g.: > > > > - Tracking DMA dirty pages for live migration; > > - A set of interfaces for using SVA inside guest; > > * PASID allocation/free (on some platforms); > > * bind/unbind guest mm/page table (nested translation); > > * invalidate IOMMU cache/iotlb for guest page table changes; > > * report page request from device to guest; > > * forward page response from guest to device; > > - Configuring irqbypass for posted interrupt; > > - ... > > > > Second, a passthrough interface requires delegating raw controllability > > of subdevice to guest driver, while the same delegation might not be > > required for implementing an userspace DMA interface (especially for > > modern devices which support SVA). For example, idxd allows following > > setting per wq (guest driver may configure them in any combination): > > - put in dedicated or shared mode; > > - enable/disable SVA; > > - Associate guest-provided PASID to MSI/IMS entry; > > - set threshold; > > - allow/deny privileged access; > > - allocate/free interrupt handle (enlightened for guest); > > - collect error status; > > - ... > > > > We plan to support idxd userspace DMA with SVA. The driver just needs > > to prepare a wq with a predefined configuration (e.g. shared, SVA, > > etc.), bind the process mm to IOMMU (non-nested) and then map > > the portal to userspace. The goal that userspace can do DMA to > > associated wq doesn't change the fact that the wq is still *owned* > > and *controlled* by kernel driver. However as far as passthrough > > is concerned, the wq is considered 'owned' by the guest driver thus > > we need an interface which can support low-level *controllability* > > from guest driver. It is sort of a mess in uAPI when mixing the > > two together. > > > So for userspace drivers like DPDK, it can use both of the two uAPIs? yes. > > > > > > Based on above two reasons, we see distinct requirements between > > userspace DMA and passthrough interfaces, at least in idxd context > > (though other devices may have less distinction in-between). Therefore, > > we didn't see the value/necessity of reinventing the wheel that mdev > > already handles well to evolve an simple application-oriented usespace > > DMA interface to a complex guest-driver-oriented passthrough interface. > > The complexity of doing so would incur far more kernel-side changes > > than the portion of emulation code that you've been concerned about... > > > >> I don't think VFIO should be the only entry point to > >> virtualization. If we say the universe of devices doing user space DMA > >> must also implement a VFIO mdev to plug into virtualization then it > >> will be alot of mdevs. > > Certainly VFIO will not be the only entry point. and This has to be a > > case-by-case decision. > > > The problem is that if we tie all controls via VFIO uAPI, the other > subsystem like vDPA is likely to duplicate them. I wonder if there is a > way to decouple the vSVA out of VFIO uAPI? vSVA is a per-device (either pdev or mdev) feature thus naturally should be managed by its device driver (VFIO or vDPA). From this angle some duplication is inevitable given VFIO and vDPA are orthogonal passthrough frameworks. Within the kernel the majority of vSVA handling is done by IOMMU and IOASID modules thus most logic are shared. > > > > If an userspace DMA interface can be easily > > adapted to be a passthrough one, it might be the choice. > > > It's not that easy even for VFIO which requires a lot of new uAPIs and > infrastructures(e.g mdev) to be invented. > > > > But for idxd, > > we see mdev a much better
[PATCH 1/3] mm: don't call activate_page() on new ksm pages
lru_cache_add_active_or_unevictable() already adds new ksm pages to
active lru. Calling activate_page() isn't really necessary in this
case.
Signed-off-by: Yu Zhao
---
mm/swapfile.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/mm/swapfile.c b/mm/swapfile.c
index 6c26916e95fd..cf115ea26a20 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -1913,16 +1913,16 @@ static int unuse_pte(struct vm_area_struct *vma, pmd_t
*pmd,
pte_mkold(mk_pte(page, vma->vm_page_prot)));
if (page == swapcache) {
page_add_anon_rmap(page, vma, addr, false);
+ /*
+* Move the page to the active list so it is not
+* immediately swapped out again after swapon.
+*/
+ activate_page(page);
} else { /* ksm created a completely new copy */
page_add_new_anon_rmap(page, vma, addr, false);
lru_cache_add_active_or_unevictable(page, vma);
}
swap_free(entry);
- /*
-* Move the page to the active list so it is not
-* immediately swapped out again after swapon.
-*/
- activate_page(page);
out:
pte_unmap_unlock(pte, ptl);
if (page != swapcache) {
--
2.28.0.236.gb10cc79966-goog
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c:3223:63: sparse: expected unsigned char const
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: fb893de323e2d39f7a1f6df425703a2edbdf56ea
commit: 4f58121dc40a1d5dd2f630a5ec4dac5afa1ce3f4 iwlwifi: mvm: Block 26-tone RU
OFDMA transmissions
date: 11 months ago
config: i386-randconfig-s001-20200812 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.2-168-g9554805c-dirty
git checkout 4f58121dc40a1d5dd2f630a5ec4dac5afa1ce3f4
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c: note: in included file
(through drivers/net/wireless/intel/iwlwifi/mvm/..//fw/img.h,
drivers/net/wireless/intel/iwlwifi/mvm/..//iwl-trans.h, ...):
drivers/net/wireless/intel/iwlwifi/mvm/..//fw/file.h:330:19: sparse: sparse:
mixed bitwiseness
drivers/net/wireless/intel/iwlwifi/mvm/..//fw/file.h:475:19: sparse: sparse:
mixed bitwiseness
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c:3223:63: sparse: sparse:
incorrect type in argument 2 (different address spaces) @@ expected
unsigned char const [usertype] *ies @@ got unsigned char const [noderef]
* @@
>> drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c:3223:63: sparse:
>> expected unsigned char const [usertype] *ies
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c:3223:63: sparse: got
unsigned char const [noderef] *
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c: note: in included file
(through include/linux/bitops.h, include/linux/kernel.h):
arch/x86/include/asm/bitops.h:78:37: sparse: sparse: cast truncates bits
from constant value (ff7f becomes 7f)
arch/x86/include/asm/bitops.h:78:37: sparse: sparse: cast truncates bits
from constant value (ff7f becomes 7f)
arch/x86/include/asm/bitops.h:78:37: sparse: sparse: cast truncates bits
from constant value (ff7f becomes 7f)
>> drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c:3224:38: sparse: sparse:
>> dereference of noderef expression
>> drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c:3224:38: sparse: sparse:
>> dereference of noderef expression
vim +3223 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
3215
3216 static void iwl_mvm_check_he_obss_narrow_bw_ru_iter(struct wiphy *wiphy,
3217 struct cfg80211_bss
*bss,
3218 void *_data)
3219 {
3220 struct iwl_mvm_he_obss_narrow_bw_ru_data *data = _data;
3221 const struct element *elem;
3222
> 3223 elem = cfg80211_find_elem(WLAN_EID_EXT_CAPABILITY,
> bss->ies->data,
> 3224bss->ies->len);
3225
3226 if (!elem || elem->datalen < 10 ||
3227 !(elem->data[10] &
3228WLAN_EXT_CAPA10_OBSS_NARROW_BW_RU_TOLERANCE_SUPPORT)) {
3229 data->tolerated = false;
3230 }
3231 }
3232
---
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 v4 1/4] fpga: dfl: change data type of feature id to u16
On Mon, Aug 10, 2020 at 10:41:10AM +0800, Xu Yilun wrote:
> The feature id is stored in a 12 bit field in DFH. So a u16 variable is
> enough for feature id.
>
> This patch changes all feature id related places to fit u16.
>
> Signed-off-by: Xu Yilun
> Reviewed-by: Tom Rix
> Acked-by: Wu Hao
> ---
> v3: no change.
> v4: no change.
> ---
> drivers/fpga/dfl-fme-perf.c | 2 +-
> drivers/fpga/dfl.c | 29 +++--
> drivers/fpga/dfl.h | 10 +-
> 3 files changed, 21 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/fpga/dfl-fme-perf.c b/drivers/fpga/dfl-fme-perf.c
> index 6ce1ed2..5312662 100644
> --- a/drivers/fpga/dfl-fme-perf.c
> +++ b/drivers/fpga/dfl-fme-perf.c
> @@ -148,7 +148,7 @@ struct fme_perf_priv {
> struct device *dev;
> void __iomem *ioaddr;
> struct pmu pmu;
> - u64 id;
> + u16 id;
>
> u32 fab_users;
> u32 fab_port_id;
> diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
> index 649958a..18575d9 100644
> --- a/drivers/fpga/dfl.c
> +++ b/drivers/fpga/dfl.c
> @@ -58,7 +58,7 @@ static const char *dfl_pdata_key_strings[DFL_ID_MAX] = {
> */
> struct dfl_dev_info {
> const char *name;
> - u32 dfh_id;
> + u16 dfh_id;
> struct idr id;
> enum dfl_fpga_devt_type devt_type;
> };
> @@ -134,7 +134,7 @@ static enum dfl_id_type feature_dev_id_type(struct
> platform_device *pdev)
> return DFL_ID_MAX;
> }
>
> -static enum dfl_id_type dfh_id_to_type(u32 id)
> +static enum dfl_id_type dfh_id_to_type(u16 id)
> {
> int i;
>
> @@ -454,7 +454,7 @@ struct build_feature_devs_info {
> * @nr_irqs: number of irqs of this sub feature.
> */
> struct dfl_feature_info {
> - u64 fid;
> + u16 fid;
> struct resource mmio_res;
> void __iomem *ioaddr;
> struct list_head node;
> @@ -649,7 +649,7 @@ static inline u32 feature_size(void __iomem *start)
> return ofst ? ofst : 4096;
> }
>
> -static u64 feature_id(void __iomem *start)
> +static u16 feature_id(void __iomem *start)
> {
> u64 v = readq(start + DFH);
> u16 id = FIELD_GET(DFH_ID, v);
> @@ -667,7 +667,7 @@ static u64 feature_id(void __iomem *start)
> }
>
> static int parse_feature_irqs(struct build_feature_devs_info *binfo,
> - resource_size_t ofst, u64 fid,
> + resource_size_t ofst, u16 fid,
> unsigned int *irq_base, unsigned int *nr_irqs)
> {
> void __iomem *base = binfo->ioaddr + ofst;
> @@ -713,12 +713,12 @@ static int parse_feature_irqs(struct
> build_feature_devs_info *binfo,
> return 0;
> }
>
> - dev_dbg(binfo->dev, "feature: 0x%llx, irq_base: %u, nr_irqs: %u\n",
> + dev_dbg(binfo->dev, "feature: 0x%x, irq_base: %u, nr_irqs: %u\n",
> fid, ibase, inr);
>
> if (ibase + inr > binfo->nr_irqs) {
> dev_err(binfo->dev,
> - "Invalid interrupt number in feature 0x%llx\n", fid);
> + "Invalid interrupt number in feature 0x%x\n", fid);
> return -EINVAL;
> }
>
> @@ -726,7 +726,7 @@ static int parse_feature_irqs(struct
> build_feature_devs_info *binfo,
> virq = binfo->irq_table[ibase + i];
> if (virq < 0 || virq > NR_IRQS) {
> dev_err(binfo->dev,
> - "Invalid irq table entry for feature 0x%llx\n",
> + "Invalid irq table entry for feature 0x%x\n",
> fid);
> return -EINVAL;
> }
> @@ -748,7 +748,7 @@ static int parse_feature_irqs(struct
> build_feature_devs_info *binfo,
> static int
> create_feature_instance(struct build_feature_devs_info *binfo,
> struct dfl_fpga_enum_dfl *dfl, resource_size_t ofst,
> - resource_size_t size, u64 fid)
> + resource_size_t size, u16 fid)
> {
> unsigned int irq_base, nr_irqs;
> struct dfl_feature_info *finfo;
> @@ -819,9 +819,10 @@ static int parse_feature_fiu(struct
> build_feature_devs_info *binfo,
>struct dfl_fpga_enum_dfl *dfl,
>resource_size_t ofst)
> {
> - u32 id, offset;
> - u64 v;
> int ret = 0;
> + u32 offset;
> + u16 id;
> + u64 v;
>
> v = readq(dfl->ioaddr + ofst + DFH);
> id = FIELD_GET(DFH_ID, v);
> @@ -855,8 +856,8 @@ static int parse_feature_private(struct
> build_feature_devs_info *binfo,
>resource_size_t ofst)
> {
> if (!binfo->feature_dev) {
> - dev_err(binfo->dev, "the private feature %llx does not belong
> to any AFU.\n",
> - (unsigned long long)feature_id(dfl->ioaddr + ofst));
> + dev_err(binfo->dev, "the private feature 0x%x does not belong
> to any AFU.\n",
> +
drivers/video/fbdev/arcfb.c:119:9: sparse: got void COPYING CREDITS Documentation Kbuild Kconfig LICENSES MAINTAINERS Makefile README arch block certs crypto drivers fs include init ipc kernel lib mm
Hi Bartlomiej,
First bad commit (maybe != root cause):
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: fb893de323e2d39f7a1f6df425703a2edbdf56ea
commit: 3d3287e609877aa549b1cbb41eafaf73c3742a0b video: fbdev: arcfb: add
COMPILE_TEST support
date: 5 months ago
config: riscv-randconfig-s031-20200812 (attached as .config)
compiler: riscv64-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-168-g9554805c-dirty
git checkout 3d3287e609877aa549b1cbb41eafaf73c3742a0b
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=riscv
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
drivers/video/fbdev/arcfb.c:119:9: sparse: sparse: cast removes address
space '' of expression
drivers/video/fbdev/arcfb.c:119:9: sparse: sparse: incorrect type in
argument 2 (different address spaces) @@ expected void volatile [noderef]
*addr @@ got void * @@
drivers/video/fbdev/arcfb.c:119:9: sparse: expected void volatile
[noderef] *addr
>> drivers/video/fbdev/arcfb.c:119:9: sparse: got void *
drivers/video/fbdev/arcfb.c:120:9: sparse: sparse: cast removes address
space '' of expression
drivers/video/fbdev/arcfb.c:120:9: sparse: sparse: incorrect type in
argument 2 (different address spaces) @@ expected void volatile [noderef]
*addr @@ got void * @@
drivers/video/fbdev/arcfb.c:120:9: sparse: expected void volatile
[noderef] *addr
drivers/video/fbdev/arcfb.c:120:9: sparse: got void *
drivers/video/fbdev/arcfb.c:122:9: sparse: sparse: cast removes address
space '' of expression
drivers/video/fbdev/arcfb.c:122:9: sparse: sparse: incorrect type in
argument 2 (different address spaces) @@ expected void volatile [noderef]
*addr @@ got void * @@
drivers/video/fbdev/arcfb.c:122:9: sparse: expected void volatile
[noderef] *addr
drivers/video/fbdev/arcfb.c:122:9: sparse: got void *
drivers/video/fbdev/arcfb.c:128:9: sparse: sparse: cast removes address
space '' of expression
drivers/video/fbdev/arcfb.c:128:9: sparse: sparse: incorrect type in
argument 2 (different address spaces) @@ expected void volatile [noderef]
*addr @@ got void * @@
drivers/video/fbdev/arcfb.c:128:9: sparse: expected void volatile
[noderef] *addr
drivers/video/fbdev/arcfb.c:128:9: sparse: got void *
drivers/video/fbdev/arcfb.c:134:16: sparse: sparse: cast removes address
space '' of expression
drivers/video/fbdev/arcfb.c:134:16: sparse: sparse: incorrect type in
argument 1 (different address spaces) @@ expected void const volatile
[noderef] *addr @@ got void * @@
drivers/video/fbdev/arcfb.c:134:16: sparse: expected void const volatile
[noderef] *addr
drivers/video/fbdev/arcfb.c:134:16: sparse: got void *
drivers/video/fbdev/arcfb.c:142:9: sparse: sparse: cast removes address
space '' of expression
drivers/video/fbdev/arcfb.c:142:9: sparse: sparse: incorrect type in
argument 2 (different address spaces) @@ expected void volatile [noderef]
*addr @@ got void * @@
drivers/video/fbdev/arcfb.c:142:9: sparse: expected void volatile
[noderef] *addr
drivers/video/fbdev/arcfb.c:142:9: sparse: got void *
drivers/video/fbdev/arcfb.c:143:9: sparse: sparse: cast removes address
space '' of expression
drivers/video/fbdev/arcfb.c:143:9: sparse: sparse: incorrect type in
argument 2 (different address spaces) @@ expected void volatile [noderef]
*addr @@ got void * @@
drivers/video/fbdev/arcfb.c:143:9: sparse: expected void volatile
[noderef] *addr
drivers/video/fbdev/arcfb.c:143:9: sparse: got void *
drivers/video/fbdev/arcfb.c:145:9: sparse: sparse: cast removes address
space '' of expression
drivers/video/fbdev/arcfb.c:145:9: sparse: sparse: incorrect type in
argument 2 (different address spaces) @@ expected void volatile [noderef]
*addr @@ got void * @@
drivers/video/fbdev/arcfb.c:145:9: sparse: expected void volatile
[noderef] *addr
drivers/video/fbdev/arcfb.c:145:9: sparse: got void *
vim +119 drivers/video/fbdev/arcfb.c
1154ea7dcd8eed drivers/video/arcfb.c Jaya Kumar 2005-06-21 113
1154ea7dcd8eed drivers/video/arcfb.c Jaya Kumar 2005-06-21 114 static void
ks108_writeb_ctl(struct arcfb_par *par,
1154ea7dcd8eed drivers/video/arcfb.c Jaya Kumar 2005-06-21 115
unsigned int chipindex, unsigned char value)
1154ea7dcd8eed drivers/video/arcfb.c Jaya Kumar 2005-06-21 116 {
1154ea7dcd8eed drivers/video/arcfb.c Jaya Kumar 2005-06-21 117
Re: [PATCH v1 2/2] perf/core: Fake regs for leaked kernel samples
Hi Peter, On 8/11/2020 4:45 PM, Peter Zijlstra wrote: On Tue, Aug 11, 2020 at 04:31:10PM +0800, Jin, Yao wrote: Hi Peter, On 8/11/2020 3:59 PM, Peter Zijlstra wrote: On Tue, Aug 11, 2020 at 03:50:43PM +0800, Jin, Yao wrote: Could I post v2 which basically refers to your patch but removes some conditions since I see some issues in test if we use these conditions. 1. Remove '!event->attr.exclude_hv || !event->attr.exclude_host || !event->attr.exclude_guest' at the entry of sanitize_sample_regs(). 2. Remove '!attr.exclude_hv || !attr.exclude_host || !attr.exclude_guest' at the perf_event_open syscall entry. exclude_host, maybe -- due to the dodgy semantics of it, but the others should definitely be there. exclude_guest and exclude_hv are tricky too. If we do 'perf record -e cycles:u' in both host and guest, we can see: event->attr.exclude_guest = 0 thus sanitize_sample_regs() returns regs directly even if exclude_kernel = 1. And in guest, exclude_hv = 0, it's out of my expectation too. I'm confused, how can 'perf record -e cycles:u' _ever_ have exclude_guest=0, exclude_hv=0 ? That simply makes no sense and is utterly broken. You explicitly ask for userspace-only, reporting hypervisor or guest events is a straight up bug. If we run 'perf record -e cycles:u', 1. On host, exclude_guest = 0 and exclude_hv = 1 perf tool doesn't specially set 'exclude_guest' when it parses the 'u' modifier. I agree that can be improved. I will post a perf tool patch to fix that. 2. On guest, exclude_guest = 0 and exclude_hv = 0. For exclude_hv = 0, it looks like a bug but x86 doesn't use exclude_hv. But yes, we should fix that. CC Like Xu . Thanks Jin Yao
RE: [RFC PATCH] sched/numa: fix bug in update_task_scan_period
OK. Thanks for your advice and I'll use label instead. In the case of migration failures, if there are still new failures after clearing (meaning the node is still overloaded), the scanning period would be doubled, just like not using this patch. However, if the failures do not increase again, then the scanning period should be adjusted according to the following rules (i.e., ps and lr ratio). I believe this is the original design idea, right? > -Original Message- > From: Mel Gorman > Sent: Tuesday, August 11, 2020 7:02 PM > To: Tianchen Ding > Cc: Ingo Molnar ; Peter Zijlstra > ; Juri Lelli ; Vincent Guittot > ; Dietmar Eggemann > ; Steven Rostedt ; > Ben Segall ; linux-kernel ker...@vger.kernel.org>; ?? > Subject: Re: [RFC PATCH] sched/numa: fix bug in update_task_scan_period > > On Tue, Aug 11, 2020 at 04:30:31PM +0800, ? wrote: > > When p->numa_faults_locality[2] > 0, numa_scan_period is doubled, but > > this array will never be cleared, which causes scanning period always > > reaching its max value. This patch clears numa_faults_locality after > > numa_scan_period being doubled to fix this bug. > > > > An out label at the end of the function to clears numa_faults_locality would > also work with a comment explaining why. That aside, what is the user- > visible impact of the patch? If there are no useful faults or migration failures, > it makes sense that scanning is very slow until the situation changes. The > corner case is that a migration failure might keep the scan rate slower than it > should be but the flip side is that fixing it might increase the scan rate and still > incur migration failures which introduces overhead with no gain. > > -- > Mel Gorman > SUSE Labs
Re: [PATCH v2 2/3] perf/x86/rapl: Support multiple rapl unit quirks
On Wed, 2020-08-12 at 11:29 +0800, Zhang Rui wrote: > Hi, > > Thanks for reviewing. > > On Tue, 2020-08-11 at 11:19 -0700, Joe Perches wrote: > > On Tue, 2020-08-11 at 23:31 +0800, Zhang Rui wrote: > > > There will be more platforms with different fixed energy units. > > > Enhance the code to support different rapl unit quirks for > > > different > > > platforms. > > > > This seems like one quirk per platform. > > > > Should multiple quirks on individual platforms be supported? > > > enum rapl_unit_quirk is just used as a flag. > multiple quirks can be deployed with the same flag, just like what I > did in patch 3/3. > Also different platforms can either have different flags or share the > same flag. Sure, but it does lead to possible code duplication in the quirks as enums can not be combined like bit flags. No worries, your code, your choice...
[PATCH] i2c: imx: Use dev_err_probe() to simplify error handling
dev_err_probe() can reduce code size, uniform error handling and record the
defer probe reason etc., use it to simplify the code.
Signed-off-by: Anson Huang
---
drivers/i2c/busses/i2c-imx.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 0ab5381..63f4367 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -1159,11 +1159,9 @@ static int i2c_imx_probe(struct platform_device *pdev)
/* Get I2C clock */
i2c_imx->clk = devm_clk_get(>dev, NULL);
- if (IS_ERR(i2c_imx->clk)) {
- if (PTR_ERR(i2c_imx->clk) != -EPROBE_DEFER)
- dev_err(>dev, "can't get I2C clock\n");
- return PTR_ERR(i2c_imx->clk);
- }
+ if (IS_ERR(i2c_imx->clk))
+ return dev_err_probe(>dev, PTR_ERR(i2c_imx->clk),
+"can't get I2C clock\n");
ret = clk_prepare_enable(i2c_imx->clk);
if (ret) {
--
2.7.4
[PATCH] brcm: Add 4356 based AP6356S NVRAM for the khadas VIM2
Add a NVRAM file for the wireless module used in khadas VIM2. This
source comes from khadas fenix project's commit 022fdc3a1333 ("hwpacks:
wlan-firmware: add AP6356S firmware for mainline linux"). [1]
[1]:
https://github.com/khadas/fenix/commit/022fdc3a1333d2d16f84c2e59e4507c92a668a3d
Suggested-by: Nick Xie
Signed-off-by: Jian-Hong Pan
---
brcm/brcmfmac4356-sdio.khadas,vim2.txt | 128 +
1 file changed, 128 insertions(+)
create mode 100644 brcm/brcmfmac4356-sdio.khadas,vim2.txt
diff --git a/brcm/brcmfmac4356-sdio.khadas,vim2.txt
b/brcm/brcmfmac4356-sdio.khadas,vim2.txt
new file mode 100644
index 000..4c286cc
--- /dev/null
+++ b/brcm/brcmfmac4356-sdio.khadas,vim2.txt
@@ -0,0 +1,128 @@
+#AP6356SL_V1.1_NVRAM_20150805
+#Modified from AP6356SDP_V1.0_NVRAM_20150216
+NVRAMRev=$Rev: 373428 $
+sromrev=11
+boardrev=0x1121
+boardtype=0x073e
+boardflags=0x02400201
+boardflags2=0x00802000
+boardflags3=0x010a
+macaddr=00:90:4c:1a:10:01
+ccode=0x5855
+regrev=1
+antswitch=0
+pdgain5g=4
+pdgain2g=4
+tworangetssi2g=0
+tworangetssi5g=0
+paprdis=0
+femctrl=10
+vendid=0x14e4
+devid=0x43a3
+manfid=0x2d0
+nocrc=1
+otpimagesize=502
+xtalfreq=37400
+rxgains2gelnagaina0=0
+rxgains2gtrisoa0=7
+rxgains2gtrelnabypa0=0
+rxgains5gelnagaina0=0
+rxgains5gtrisoa0=11
+rxgains5gtrelnabypa0=0
+rxgains5gmelnagaina0=0
+rxgains5gmtrisoa0=13
+rxgains5gmtrelnabypa0=0
+rxgains5ghelnagaina0=0
+rxgains5ghtrisoa0=12
+rxgains5ghtrelnabypa0=0
+rxgains2gelnagaina1=0
+rxgains2gtrisoa1=7
+rxgains2gtrelnabypa1=0
+rxgains5gelnagaina1=0
+rxgains5gtrisoa1=10
+rxgains5gtrelnabypa1=0
+rxgains5gmelnagaina1=0
+rxgains5gmtrisoa1=11
+rxgains5gmtrelnabypa1=0
+rxgains5ghelnagaina1=0
+rxgains5ghtrisoa1=11
+rxgains5ghtrelnabypa1=0
+rxchain=3
+txchain=3
+aa2g=3
+aa5g=3
+agbg0=2
+agbg1=2
+aga0=2
+aga1=2
+tssipos2g=1
+extpagain2g=2
+tssipos5g=1
+extpagain5g=2
+tempthresh=255
+tempoffset=255
+rawtempsense=0x1ff
+pa2ga0=-135,5769,-647
+pa2ga1=-143,6023,-677
+pa5ga0=-183,5746,-697,-172,5801,-685,-176,5707,-680,-180,5445,-659
+pa5ga1=-186,5543,-669,-193,5506,-675,-210,5282,-661,-199,5367,-665
+subband5gver=0x4
+pdoffsetcckma0=0x4
+pdoffsetcckma1=0x4
+pdoffset40ma0=0x
+pdoffset80ma0=0x
+pdoffset40ma1=0x
+pdoffset80ma1=0x
+maxp2ga0=72
+maxp5ga0=69,70,69,68
+maxp2ga1=71
+maxp5ga1=67,67,67,67
+cckbw202gpo=0x1222
+cckbw20ul2gpo=0x
+mcsbw202gpo=0x99E644422
+mcsbw402gpo=0xE9744424
+dot11agofdmhrbw202gpo=0x
+ofdmlrbw202gpo=0x0022
+mcsbw205glpo=0xEEA86661
+mcsbw405glpo=0xEEB86663
+mcsbw805glpo=0xEEB86663
+mcsbw205gmpo=0xAAA86663
+mcsbw405gmpo=0xECB86663
+mcsbw805gmpo=0xEEA86663
+mcsbw205ghpo=0xCC986663
+mcsbw405ghpo=0xEEA86663
+mcsbw805ghpo=0xEEA86663
+mcslr5glpo=0x
+mcslr5gmpo=0x
+mcslr5ghpo=0x
+sb20in40hrpo=0x0
+sb20in80and160hr5glpo=0x0
+sb40and80hr5glpo=0x0
+sb20in80and160hr5gmpo=0x0
+sb40and80hr5gmpo=0x0
+sb20in80and160hr5ghpo=0x0
+sb40and80hr5ghpo=0x0
+sb20in40lrpo=0x0
+sb20in80and160lr5glpo=0x0
+sb40and80lr5glpo=0x0
+sb20in80and160lr5gmpo=0x0
+sb40and80lr5gmpo=0x0
+sb20in80and160lr5ghpo=0x0
+sb40and80lr5ghpo=0x0
+dot11agduphrpo=0x0
+dot11agduplrpo=0x0
+phycal_tempdelta=255
+temps_period=15
+temps_hysteresis=15
+rssicorrnorm_c0=4,4
+rssicorrnorm_c1=4,4
+rssicorrnorm5g_c0=1,2,3,1,2,3,6,6,8,6,6,8
+rssicorrnorm5g_c1=1,2,3,2,2,2,7,7,8,7,7,8
+
+swctrlmap_2g=0x1040,0x4010,0x4010,0x200010,0xff
+swctrlmap_5g=0x0202,0x0101,0x0101,0x00,0x47
+swctrlmapext_5g=0x,0x,0x,0x00,0x000
+swctrlmapext_2g=0x,0x,0x,0x00,0x000
+
+muxenab=0x10
+
--
2.28.0
Re: [PATCH v6 1/2] Add DT bindings YAML schema for PWM fan controller of LGM SoC
Hi Rob, On 1/8/2020 2:19 am, Rob Herring wrote: > On Tue, Jul 28, 2020 at 04:52:12PM +0800, Rahul Tanwar wrote: >> Intel's LGM(Lightning Mountain) SoC contains a PWM fan controller >> which is only used to control the fan attached to the system. This >> PWM controller does not have any other consumer other than fan. >> Add DT bindings documentation for this PWM fan controller. >> >> Signed-off-by: Rahul Tanwar >> --- >> .../devicetree/bindings/pwm/intel,lgm-pwm.yaml | 54 >> ++ >> 1 file changed, 54 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml >> >> diff --git a/Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml >> b/Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml >> new file mode 100644 >> index ..9879972470dc >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml >> @@ -0,0 +1,54 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/pwm/intel,lgm-pwm.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: LGM SoC PWM fan controller >> + >> +maintainers: >> + - Rahul Tanwar >> + >> +properties: >> + compatible: >> +const: intel,lgm-pwm >> + >> + reg: >> +maxItems: 1 >> + >> + "#pwm-cells": >> +const: 2 >> + >> + clocks: >> +maxItems: 1 >> + >> + resets: >> +maxItems: 1 >> + >> + intel,fan-wire: >> +$ref: '/schemas/types.yaml#/definitions/uint32' >> +description: Specifies fan mode. Default when unspecified is 2. >> + >> + intel,max-rpm: >> +$ref: '/schemas/types.yaml#/definitions/uint32' >> +description: >> + Specifies maximum RPM of fan attached to the system. >> + Default when unspecified is 4000. > Again, these are properties of a fan, not the pwm controller. They > belong in a fan node. Our PWM controller is actually a PWM fan controller dedicated for controlling fan. I am looking for some suggestions from you on how to handle fan related optional properties in such a scenario. Should i create a separate child node for fan with PWM node being the parent? Is that what you are suggesting? Thanks. Regards, Rahul
drivers/hwspinlock/u8500_hsem.c:52:39: sparse: got void
Hi Baolin,
First bad commit (maybe != root cause):
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: fb893de323e2d39f7a1f6df425703a2edbdf56ea
commit: ffd0bbfb378ecd56eac22bf932ccdbf89ac7f725 hwspinlock: Allow drivers to
be built with COMPILE_TEST
date: 5 months ago
config: powerpc64-randconfig-s032-20200812 (attached as .config)
compiler: powerpc-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-168-g9554805c-dirty
git checkout ffd0bbfb378ecd56eac22bf932ccdbf89ac7f725
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=powerpc64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
drivers/hwspinlock/u8500_hsem.c:52:39: sparse: sparse: incorrect type in
initializer (different address spaces) @@ expected void [noderef]
*lock_addr @@ got void *priv @@
drivers/hwspinlock/u8500_hsem.c:52:39: sparse: expected void [noderef]
*lock_addr
>> drivers/hwspinlock/u8500_hsem.c:52:39: sparse: got void *priv
drivers/hwspinlock/u8500_hsem.c:65:39: sparse: sparse: incorrect type in
initializer (different address spaces) @@ expected void [noderef]
*lock_addr @@ got void *priv @@
drivers/hwspinlock/u8500_hsem.c:65:39: sparse: expected void [noderef]
*lock_addr
drivers/hwspinlock/u8500_hsem.c:65:39: sparse: got void *priv
drivers/hwspinlock/u8500_hsem.c:116:30: sparse: sparse: incorrect type in
assignment (different address spaces) @@ expected void *priv @@ got
void [noderef] * @@
>> drivers/hwspinlock/u8500_hsem.c:116:30: sparse: expected void *priv
drivers/hwspinlock/u8500_hsem.c:116:30: sparse: got void [noderef]
*
drivers/hwspinlock/u8500_hsem.c:126:52: sparse: sparse: incorrect type in
initializer (different address spaces) @@ expected void [noderef]
*io_base @@ got void * @@
drivers/hwspinlock/u8500_hsem.c:126:52: sparse: expected void [noderef]
*io_base
>> drivers/hwspinlock/u8500_hsem.c:126:52: sparse: got void *
vim +52 drivers/hwspinlock/u8500_hsem.c
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 49
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 50 static int
u8500_hsem_trylock(struct hwspinlock *lock)
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 51 {
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 @52 void __iomem *lock_addr
= lock->priv;
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 53
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 54 writel(HSEM_MASTER_ID,
lock_addr);
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 55
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 56 /* get only first 4 bit
and compare to masterID.
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 57* if equal, we have
the semaphore, otherwise
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 58* someone else has it.
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 59*/
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 60 return (HSEM_MASTER_ID
== (0x0F & readl(lock_addr)));
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 61 }
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 62
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 63 static void
u8500_hsem_unlock(struct hwspinlock *lock)
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 64 {
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 65 void __iomem *lock_addr
= lock->priv;
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 66
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 67 /* release the lock by
writing 0 to it */
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 68 writel(RESET_SEMAPHORE,
lock_addr);
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 69 }
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 70
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 71 /*
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 72 * u8500: what value is
recommended here ?
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 73 */
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 74 static void
u8500_hsem_relax(struct hwspinlock *lock)
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 75 {
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 76 ndelay(50);
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 77 }
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 78
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 79 static const struct
hwspinlock_ops u8500_hwspinlock_ops = {
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 80 .trylock=
u8500_hsem_trylock,
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 81 .unlock =
u8500_hsem_unlock,
f84a8ecfca9229 Mathieu J. Poirier
RE: [PATCH RFC v2 00/18] Add VFIO mediated device support and DEV-MSI support for the idxd driver
> From: Alex Williamson > Sent: Wednesday, August 12, 2020 10:36 AM > On Wed, 12 Aug 2020 01:58:00 + > "Tian, Kevin" wrote: > > > > > > > I'll also remind folks that LPC is coming up in just a couple short > > > weeks and this might be something we should discuss (virtually) > > > in-person. uconf CfPs are currently open.Thanks, > > > > > > > Yes, LPC is a good place to reach consensus. btw I saw there is > > already one VFIO topic called "device assignment/sub-assignment". > > Do you think whether this can be covered under that topic, or > > makes more sense to be a new one? > > All the things listed in the CFP are only potential topics to get ideas > flowing, there is currently no proposal to talk about sub-assignment. > I'd suggest submitting separate topics for each and if we run into time > constraints we can ask that they might be combined together. Thanks, > Done. -- title: Criteria of using VFIO mdev (vs. userspace DMA) Content: VFIO mdev provides a framework for subdevice assignment and reuses existing VFIO uAPI to handle common passthrough-related requirements. However, subdevice (e.g. ADI defined in Intel Scalable IOV) might not be a PCI endpoint (e.g. just a work queue), thus requires some degree of emulation/mediation in kernel to fit into VFIO device API. Then there is a concern on putting emulation in kernel and how to judge abuse of mdev framework by simply using it as an easy path to hook into virtualization stack. An associated open is about differentiating mdev from userspace DMA framework (such as uacce), and whether building passthrough features on top of userspace DMA framework is a better choice than using mdev. Thanks Kevin
Re: [PATCH RFC v2 00/18] Add VFIO mediated device support and DEV-MSI support for the idxd driver
On 2020/8/10 下午3:32, Tian, Kevin wrote: From: Jason Gunthorpe Sent: Friday, August 7, 2020 8:20 PM On Wed, Aug 05, 2020 at 07:22:58PM -0600, Alex Williamson wrote: If you see this as an abuse of the framework, then let's identify those specific issues and come up with a better approach. As we've discussed before, things like basic PCI config space emulation are acceptable overhead and low risk (imo) and some degree of register emulation is well within the territory of an mdev driver. What troubles me is that idxd already has a direct userspace interface to its HW, and does userspace DMA. The purpose of this mdev is to provide a second direct userspace interface that is a little different and trivially plugs into the virtualization stack. No. Userspace DMA and subdevice passthrough (what mdev provides) are two distinct usages IMO (at least in idxd context). and this might be the main divergence between us, thus let me put more words here. If we could reach consensus in this matter, which direction to go would be clearer. First, a passthrough interface requires some unique requirements which are not commonly observed in an userspace DMA interface, e.g.: - Tracking DMA dirty pages for live migration; - A set of interfaces for using SVA inside guest; * PASID allocation/free (on some platforms); * bind/unbind guest mm/page table (nested translation); * invalidate IOMMU cache/iotlb for guest page table changes; * report page request from device to guest; * forward page response from guest to device; - Configuring irqbypass for posted interrupt; - ... Second, a passthrough interface requires delegating raw controllability of subdevice to guest driver, while the same delegation might not be required for implementing an userspace DMA interface (especially for modern devices which support SVA). For example, idxd allows following setting per wq (guest driver may configure them in any combination): - put in dedicated or shared mode; - enable/disable SVA; - Associate guest-provided PASID to MSI/IMS entry; - set threshold; - allow/deny privileged access; - allocate/free interrupt handle (enlightened for guest); - collect error status; - ... We plan to support idxd userspace DMA with SVA. The driver just needs to prepare a wq with a predefined configuration (e.g. shared, SVA, etc.), bind the process mm to IOMMU (non-nested) and then map the portal to userspace. The goal that userspace can do DMA to associated wq doesn't change the fact that the wq is still *owned* and *controlled* by kernel driver. However as far as passthrough is concerned, the wq is considered 'owned' by the guest driver thus we need an interface which can support low-level *controllability* from guest driver. It is sort of a mess in uAPI when mixing the two together. So for userspace drivers like DPDK, it can use both of the two uAPIs? Based on above two reasons, we see distinct requirements between userspace DMA and passthrough interfaces, at least in idxd context (though other devices may have less distinction in-between). Therefore, we didn't see the value/necessity of reinventing the wheel that mdev already handles well to evolve an simple application-oriented usespace DMA interface to a complex guest-driver-oriented passthrough interface. The complexity of doing so would incur far more kernel-side changes than the portion of emulation code that you've been concerned about... I don't think VFIO should be the only entry point to virtualization. If we say the universe of devices doing user space DMA must also implement a VFIO mdev to plug into virtualization then it will be alot of mdevs. Certainly VFIO will not be the only entry point. and This has to be a case-by-case decision. The problem is that if we tie all controls via VFIO uAPI, the other subsystem like vDPA is likely to duplicate them. I wonder if there is a way to decouple the vSVA out of VFIO uAPI? If an userspace DMA interface can be easily adapted to be a passthrough one, it might be the choice. It's not that easy even for VFIO which requires a lot of new uAPIs and infrastructures(e.g mdev) to be invented. But for idxd, we see mdev a much better fit here, given the big difference between what userspace DMA requires and what guest driver requires in this hw. A weak point for mdev is that it can't serve kernel subsystem other than VFIO. In this case, you need some other infrastructures (like [1]) to do this. (For idxd, you probably don't need this, but it's pretty common in the case of networking or storage device.) Thanks [1] https://patchwork.kernel.org/patch/11280547/ I would prefer to see that the existing userspace interface have the extra needed bits for virtualization (eg by having appropriate internal kernel APIs to make this easy) and all the emulation to build the synthetic PCI device be done in userspace. In the
Re: [PATCH v2 2/3] perf/x86/rapl: Support multiple rapl unit quirks
Hi,
Thanks for reviewing.
On Tue, 2020-08-11 at 11:19 -0700, Joe Perches wrote:
> On Tue, 2020-08-11 at 23:31 +0800, Zhang Rui wrote:
> > There will be more platforms with different fixed energy units.
> > Enhance the code to support different rapl unit quirks for
> > different
> > platforms.
>
> This seems like one quirk per platform.
>
> Should multiple quirks on individual platforms be supported?
>
enum rapl_unit_quirk is just used as a flag.
multiple quirks can be deployed with the same flag, just like what I
did in patch 3/3.
Also different platforms can either have different flags or share the
same flag.
thanks,
rui
> > diff --git a/arch/x86/events/rapl.c b/arch/x86/events/rapl.c
>
> []
> > @@ -130,11 +130,16 @@ struct rapl_pmus {
> > struct rapl_pmu *pmus[];
> > };
> >
> > +enum rapl_unit_quirk {
> > + RAPL_UNIT_QUIRK_NONE,
> > + RAPL_UNIT_QUIRK_INTEL_HSW,
> > +};
> > +
> > struct rapl_model {
> > struct perf_msr *rapl_msrs;
> > unsigned long events;
> > unsigned intmsr_power_unit;
> > - boolapply_quirk;
> > + enum rapl_unit_quirkunit_quirk;
> > };
>
>
Re: [Resend PATCH 2/6] mm/memcg: remove useless check on page->mem_cgroup
在 2020/8/11 下午9:56, Michal Hocko 写道: > On Tue 11-08-20 20:54:18, Alex Shi wrote: >> >From beeac61119ab39b1869c520c0f272fb8bab93765 Mon Sep 17 00:00:00 2001 >> From: Alex Shi >> Date: Wed, 5 Aug 2020 21:02:30 +0800 >> Subject: [PATCH 2/6] memcg: bail out early from swap accounting when memcg is >> disabled>> >> If we disabled memcg by cgroup_disable=memory, the swap charges are >> still called. Let's return from the funcs earlier. > They are not, are they? page->memcg will be NULL and so the charge is > skipped and that will trigger a warning with your current ordering. Hi Michal, Thanks for comment! Looks like we both agree the memcg wasn't charged, but funcs just are called. :) > > Let me repeat again. Either you put it first in the series and argue > that we can bail out early or keep the ordering then this makes sure the > warning doesn't trigger. > Is the following commit log fine? Thanks! Alex >From 999b0fe5fc65865c3b59ff28500d45572a4a9570 Mon Sep 17 00:00:00 2001 From: Alex Shi Date: Wed, 5 Aug 2020 21:02:30 +0800 Subject: [PATCH 2/6] mm/memcg: bail out early from swap accounting when memcg is disabled If we disabled memcg by cgroup_disable=memory, page->memcg will be NULL and so the charge is skipped and that will trigger a warning like below. Let's return from the funcs earlier. ---[ end trace f1f34bfc3b32ed2f ]--- anon flags:0x5005b48008000d(locked|uptodate|dirty|swapbacked) raw: 005005b48008000d dead0100 dead0122 8897c7c76ad1 raw: 0022 0002 page dumped because: VM_WARN_ON_ONCE_PAGE(!memcg) Signed-off-by: Alex Shi Reviewed-by: Roman Gushchin Acked-by: Michal Hocko Cc: Johannes Weiner Cc: Michal Hocko Cc: Vladimir Davydov Cc: Andrew Morton Cc: cgro...@vger.kernel.org Cc: linux...@kvack.org Cc: linux-kernel@vger.kernel.org --- mm/memcontrol.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 299382fc55a9..419cf565f40b 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -7098,6 +7098,9 @@ void mem_cgroup_swapout(struct page *page, swp_entry_t entry) VM_BUG_ON_PAGE(PageLRU(page), page); VM_BUG_ON_PAGE(page_count(page), page); + if (mem_cgroup_disabled()) + return; + if (cgroup_subsys_on_dfl(memory_cgrp_subsys)) return; @@ -7163,6 +7166,9 @@ int mem_cgroup_try_charge_swap(struct page *page, swp_entry_t entry) struct mem_cgroup *memcg; unsigned short oldid; + if (mem_cgroup_disabled()) + return 0; + if (!cgroup_subsys_on_dfl(memory_cgrp_subsys)) return 0; -- 1.8.3.1
Re: [kbuild-all] Re: arch/sparc/include/asm/cmpxchg_64.h:161:55: sparse: sparse: cast truncates bits from constant value (ffffffffe0f510cc becomes cc)
On 8/12/20 11:09 AM, Gao Xiang wrote:
Hi,
On Wed, Aug 12, 2020 at 09:49:38AM +0800, kernel test robot wrote:
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: fb893de323e2d39f7a1f6df425703a2edbdf56ea
commit: 47e4937a4a7ca4184fd282791dfee76c6799966a erofs: move erofs out of
staging
date: 12 months ago
config: sparc64-randconfig-s032-20200812 (attached as .config)
compiler: sparc64-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-168-g9554805c-dirty
git checkout 47e4937a4a7ca4184fd282791dfee76c6799966a
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=sparc64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
fs/erofs/utils.c: note: in included file (through
arch/sparc/include/asm/cmpxchg.h, arch/sparc/include/asm/atomic_64.h,
arch/sparc/include/asm/atomic.h, ...):
arch/sparc/include/asm/cmpxchg_64.h:161:55: sparse: sparse: cast truncates bits
from constant value (e0f510cc becomes cc)
--
fs/erofs/zdata.c: note: in included file (through
arch/sparc/include/asm/cmpxchg.h, arch/sparc/include/asm/atomic_64.h,
arch/sparc/include/asm/atomic.h, ...):
arch/sparc/include/asm/cmpxchg_64.h:161:55: sparse: sparse: cast truncates bits
from constant value (e0f510cc becomes cc)
arch/sparc/include/asm/cmpxchg_64.h:161:50: sparse: sparse: cast truncates
bits from constant value (5f0ecafe becomes fe)
arch/sparc/include/asm/cmpxchg_64.h:161:50: sparse: sparse: cast truncates
bits from constant value (5f0ecafe becomes fe)
arch/sparc/include/asm/cmpxchg_64.h:161:55: sparse: sparse: cast truncates
bits from constant value (5f0edead becomes ad)
vim +161 arch/sparc/include/asm/cmpxchg_64.h
d550bbd40c0e10 David Howells 2012-03-28 155
d550bbd40c0e10 David Howells 2012-03-28 156 static inline unsigned long
d550bbd40c0e10 David Howells 2012-03-28 157 __cmpxchg(volatile void *ptr,
unsigned long old, unsigned long new, int size)
d550bbd40c0e10 David Howells 2012-03-28 158 {
d550bbd40c0e10 David Howells 2012-03-28 159switch (size) {
a12ee2349312d7 Babu Moger2017-05-24 160case 1:
a12ee2349312d7 Babu Moger2017-05-24 @161return
__cmpxchg_u8(ptr, old, new);
d550bbd40c0e10 David Howells 2012-03-28 162case 4:
d550bbd40c0e10 David Howells 2012-03-28 163return
__cmpxchg_u32(ptr, old, new);
d550bbd40c0e10 David Howells 2012-03-28 164case 8:
d550bbd40c0e10 David Howells 2012-03-28 165return
__cmpxchg_u64(ptr, old, new);
d550bbd40c0e10 David Howells 2012-03-28 166}
d550bbd40c0e10 David Howells 2012-03-28 167
__cmpxchg_called_with_bad_pointer();
d550bbd40c0e10 David Howells 2012-03-28 168return old;
d550bbd40c0e10 David Howells 2012-03-28 169 }
d550bbd40c0e10 David Howells 2012-03-28 170
Again, I have no idea how to deal with that in my current
gatekeeping code.
I got these reports, but I cannot help to resolve that.
Even I don't know if that's another sparse issue (since I
only got such reports on sparc and alpha arch, but no x86
or arm64.)
https://lore.kernel.org/r/202007251532.y5a10zoo%25...@intel.com
https://lore.kernel.org/r/202007272132.1agbbo3u%25...@intel.com
https://lore.kernel.org/r/202008100408.wc6wgrac%25...@intel.com
https://lore.kernel.org/r/202008120933.yrvhhyoa%25...@intel.com
If no one can help that, could you please silence such reports.
It really makes me confusing.
Hi Gao Xiang,
Sorry for the inconvenience, we'll silence the reports on this commit.
Best Regards,
Rong Chen
Thanks,
Gao Xiang
:: The code at line 161 was first introduced by commit
:: a12ee2349312d7112b9b7c6ac2e70c5ec2ca334e arch/sparc: Introduce
cmpxchg_u8 SPARC
:: TO: Babu Moger
:: CC: David S. Miller
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
___
kbuild-all mailing list -- kbuild-...@lists.01.org
To unsubscribe send an email to kbuild-all-le...@lists.01.org
Re: [PATCH] sched/fair: reduce preemption with IDLE tasks runable(Internet mail)
Hi, > On Aug 11, 2020, at 11:54 PM, Dietmar Eggemann > wrote: > > On 11/08/2020 02:41, benbjiang(蒋彪) wrote: >> Hi, >> >>> On Aug 10, 2020, at 9:24 PM, Dietmar Eggemann >>> wrote: >>> >>> On 06/08/2020 17:52, benbjiang(蒋彪) wrote: Hi, > On Aug 6, 2020, at 9:29 PM, Dietmar Eggemann > wrote: > > On 03/08/2020 13:26, benbjiang(蒋彪) wrote: >> >> >>> On Aug 3, 2020, at 4:16 PM, Dietmar Eggemann >>> wrote: >>> >>> On 01/08/2020 04:32, Jiang Biao wrote: From: Jiang Biao > > [...] > >>> Because of this very small weight (weight=3), compared to a SCHED_NORMAL >>> nice 0 task (weight=1024), a SCHED_IDLE task is penalized by a huge >>> se->vruntime value (1024/3 higher than for a SCHED_NORMAL nice 0 task). >>> This should make sure it doesn't tick preempt a SCHED_NORMAL nice 0 task. >> Could you please explain how the huge penalization of vruntime(1024/3) could >> make sure SCHED_IDLE not tick preempting SCHED_NORMAL nice 0 task? >> >> Thanks a lot. > > Trace a run of 2 SCHED_OTHER (nice 0) tasks and 1 SCHED_IDLE task on a > single CPU and trace_printk the conditions 'if (delta < 0)' and ' if > (delta > ideal_runtime)' in check_preempt_tick(). > > Then do the same with 3 SCHED_OTHER (nice 0) tasks. You can also change > the niceness of the 2 SCHED_OTHER task to 19 to see some differences in > the kernelshark's task layout. > > rt-app (https://github.com/scheduler-tools/rt-app) is a nice tool to > craft those artificial use cases. With rt-app tool, sched_switch traced by ftrace, the result is as what I expected, ** 1normal+1idle: idle preempt normal every 200ms ** <...>-92016 [002] d... 2398066.902477: sched_switch: prev_comm=normal0-0 prev_pid=92016 prev_prio=120 prev_state=S ==> next_comm=idle0-0 next_pid=91814 next_prio=120 <...>-91814 [002] d... 2398066.902527: sched_switch: prev_comm=idle0-0 prev_pid=91814 prev_prio=120 prev_state=R ==> next_comm=normal0-0 next_pid=92016 next_prio=120 <...>-92016 [002] d... 2398066.922472: sched_switch: prev_comm=normal0-0 prev_pid=92016 prev_prio=120 prev_state=S ==> next_comm=idle0-0 next_pid=91814 next_prio=120 <...>-91814 [002] d... 2398066.922522: sched_switch: prev_comm=idle0-0 prev_pid=91814 prev_prio=120 prev_state=R ==> next_comm=normal0-0 next_pid=92016 next_prio=120 <...>-92016 [002] d... 2398066.942292: sched_switch: prev_comm=normal0-0 prev_pid=92016 prev_prio=120 prev_state=S ==> next_comm=idle0-0 next_pid=91814 next_prio=120 <...>-91814 [002] d... 2398066.942343: sched_switch: prev_comm=idle0-0 prev_pid=91814 prev_prio=120 prev_state=R ==> next_comm=normal0-0 next_pid=92016 next_prio=120 <...>-92016 [002] d... 2398066.962331: sched_switch: prev_comm=normal0-0 prev_pid=92016 prev_prio=120 prev_state=S ==> next_comm=idle0-0 next_pid=91814 next_prio=120 ** 2normal+1idle: idle preempt normal every 600+ms ** <...>-49009 [002] d... 2400562.746640: sched_switch: prev_comm=normal0-0 prev_pid=49009 prev_prio=120 prev_state=R ==> next_comm=idle0-0 next_pid=187466 next_prio=120 <...>-187466 [002] d... 2400562.747502: sched_switch: prev_comm=idle0-0 prev_pid=187466 prev_prio=120 prev_state=S ==> next_comm=normal1-0 next_pid=198658 next_prio=120 <...>-198658 [002] d... 2400563.335262: sched_switch: prev_comm=normal1-0 prev_pid=198658 prev_prio=120 prev_state=R ==> next_comm=idle0-0 next_pid=187466 next_prio=120 <...>-187466 [002] d... 2400563.336258: sched_switch: prev_comm=idle0-0 prev_pid=187466 prev_prio=120 prev_state=R ==> next_comm=normal0-0 next_pid=49009 next_prio=120 <...>-198658 [002] d... 2400564.017663: sched_switch: prev_comm=normal1-0 prev_pid=198658 prev_prio=120 prev_state=R ==> next_comm=idle0-0 next_pid=187466 next_prio=120 <...>-187466 [002] d... 2400564.018661: sched_switch: prev_comm=idle0-0 prev_pid=187466 prev_prio=120 prev_state=R ==> next_comm=normal0-0 next_pid=49009 next_prio=120 <...>-198658 [002] d... 2400564.701063: sched_switch: prev_comm=normal1-0 prev_pid=198658 prev_prio=120 prev_state=R ==> next_comm=idle0-0 next_pid=187466 next_prio=120 ** 3normal+idle: idle preempt normal every 1000+ms ** <...>-198658 [002] d... 2400415.780701: sched_switch: prev_comm=normal1-0 prev_pid=198658 prev_prio=120 prev_state=R ==> next_comm=idle0-0 next_pid=187466 next_prio=120 <...>-187466 [002] d... 2400415.781699: sched_switch: prev_comm=idle0-0 prev_pid=187466 prev_prio=120 prev_state=R ==> next_comm=normal2-0 next_pid=46478 next_prio=120 <...>-49009 [002] d... 2400416.806298: sched_switch: prev_comm=normal0-0 prev_pid=49009 prev_prio=120 prev_state=R ==> next_comm=idle0-0 next_pid=187466 next_prio=120 <...>-187466 [002] d... 2400416.807297: sched_switch: prev_comm=idle0-0 prev_pid=187466 prev_prio=120 prev_state=R ==> next_comm=normal2-0
KASAN: use-after-free Read in path_init (2)
Hello,
syzbot found the following issue on:
HEAD commit:5631c5e0 Merge tag 'xfs-5.9-merge-7' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1707698490
kernel config: https://syzkaller.appspot.com/x/.config?x=afba7c06f91e56eb
dashboard link: https://syzkaller.appspot.com/bug?extid=bbeb1c88016c7db4aa24
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1502ce0290
The issue was bisected to:
commit e24ab0ef689de43649327f54cd1088f3dad25bb3
Author: Christoph Hellwig
Date: Tue Jul 21 08:48:15 2020 +
fs: push the getname from do_rmdir into the callers
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=155f36c290
final oops: https://syzkaller.appspot.com/x/report.txt?x=175f36c290
console output: https://syzkaller.appspot.com/x/log.txt?x=135f36c290
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+bbeb1c88016c7db4a...@syzkaller.appspotmail.com
Fixes: e24ab0ef689d ("fs: push the getname from do_rmdir into the callers")
==
BUG: KASAN: use-after-free in path_init+0x116b/0x13c0 fs/namei.c:2207
Read of size 8 at addr 88807853c940 by task syz-executor.2/8233
CPU: 0 PID: 8233 Comm: syz-executor.2 Not tainted 5.8.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x18f/0x20d lib/dump_stack.c:118
print_address_description.constprop.0.cold+0xae/0x436 mm/kasan/report.c:383
__kasan_report mm/kasan/report.c:513 [inline]
kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530
path_init+0x116b/0x13c0 fs/namei.c:2207
path_parentat+0x22/0x1b0 fs/namei.c:2384
filename_parentat+0x188/0x560 fs/namei.c:2407
do_rmdir+0xa8/0x440 fs/namei.c:3732
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45ce79
Code: 2d b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83
fb b5 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7f756fb2bc78 EFLAGS: 0246 ORIG_RAX: 0054
RAX: ffda RBX: 000260c0 RCX: 0045ce79
RDX: RSI: RDI: 20c0
RBP: 0118bff0 R08: R09:
R10: R11: 0246 R12: 0118bfcc
R13: 7ffedeb9931f R14: 7f756fb2c9c0 R15: 0118bfcc
Allocated by task 8233:
save_stack+0x1b/0x40 mm/kasan/common.c:48
set_track mm/kasan/common.c:56 [inline]
__kasan_kmalloc.constprop.0+0xc2/0xd0 mm/kasan/common.c:494
slab_post_alloc_hook mm/slab.h:586 [inline]
slab_alloc mm/slab.c:3320 [inline]
kmem_cache_alloc+0x12c/0x3b0 mm/slab.c:3484
getname_flags.part.0+0x50/0x4f0 fs/namei.c:138
getname_flags include/linux/audit.h:320 [inline]
getname fs/namei.c:209 [inline]
__do_sys_rmdir fs/namei.c:3783 [inline]
__se_sys_rmdir fs/namei.c:3781 [inline]
__x64_sys_rmdir+0xb1/0x100 fs/namei.c:3781
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Freed by task 8233:
save_stack+0x1b/0x40 mm/kasan/common.c:48
set_track mm/kasan/common.c:56 [inline]
kasan_set_free_info mm/kasan/common.c:316 [inline]
__kasan_slab_free+0xf5/0x140 mm/kasan/common.c:455
__cache_free mm/slab.c:3426 [inline]
kmem_cache_free+0x7f/0x310 mm/slab.c:3694
putname+0xe1/0x120 fs/namei.c:259
do_rmdir+0x145/0x440 fs/namei.c:3773
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
The buggy address belongs to the object at 88807853c940
which belongs to the cache names_cache of size 4096
The buggy address is located 0 bytes inside of
4096-byte region [88807853c940, 88807853d940)
The buggy address belongs to the page:
page:ea0001e14f00 refcount:1 mapcount:0 mapping: index:0x0
head:ea0001e14f00 order:1 compound_mapcount:0
flags: 0xfffe010200(slab|head)
raw: 00fffe010200 ea0001e14e88 ea0001e14f88 8880aa246380
raw: 88807853c940 00010001
page dumped because: kasan: bad access detected
Memory state around the buggy address:
88807853c800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
88807853c880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>88807853c900: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
^
88807853c980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
88807853ca00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
Re: [PATCH 2/2] perf sched timehist: Fix use of CPU list with summary option
On 8/11/20 12:42 AM, Namhyung Kim wrote:
>> @@ -2575,7 +2575,8 @@ static int timehist_sched_change_event(struct
>> perf_tool *tool,
>> }
>>
>> if (!sched->idle_hist || thread->tid == 0) {
>> - timehist_update_runtime_stats(tr, t, tprev);
>> + if (!cpu_list || test_bit(sample->cpu, cpu_bitmap))
>> + timehist_update_runtime_stats(tr, t, tprev);
>>
>> if (sched->idle_hist) {
>> struct idle_thread_runtime *itr = (void *)tr;
>> @@ -2848,6 +2849,9 @@ static void timehist_print_summary(struct perf_sched
>> *sched,
>>
>> printf("\nIdle stats:\n");
>> for (i = 0; i < idle_max_cpu; ++i) {
>> + if (!test_bit(i, cpu_bitmap))
>
> Shouldn't it check cpu_list as well?
>
oh, right. will fix.
Re: [PATCH v3 2/2] ASoC: Intel: Add period size constraint on strago board
Mark Brown 於 2020年8月12日 週三 上午1:22寫道： > > On Tue, Aug 11, 2020 at 11:54:38AM -0500, Pierre-Louis Bossart wrote: > > > > constraint logic needs to know about this DSP limitation - it seems like > > > none of this is going to change without something new going into the > > > mix? We at least need a new question to ask about the DSP firmware I > > > think. > > > I just tested aplay -Dhw: on a Cyan Chromebook with the Ubuntu kernel 5.4, > > and I see no issues with the 240 sample period. Same with 432, 960, 9600, > > etc. > > > I also tried just for fun what happens with 256 samples, and I don't see any > > underflows thrown either, so I am wondering what exactly the problem is? > > Something's not adding up. I would definitively favor multiple of 1ms > > periods, since it's the only case that was productized, but there's got to > > me something a side effect of how CRAS programs the hw_params. > > Is it something that goes wrong with longer playbacks possibly (eg, > someone watching a feature film or something)? Thanks for testing! After doing some experiments, I think I can identify the problem more precisely. 1. aplay can not reproduce this issue because it writes samples immediately when there are some space in the buffer. However, you can add --test-position to see how the delay grows with period size 256. > aplay -Dhw:1,0 --period-size=256 --buffer-size=480 /dev/zero -d 1 -f dat > --test-position Playing raw data '/dev/zero' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo Suspicious buffer position (1 total): avail = 0, delay = 2064, buffer = 512 Suspicious buffer position (2 total): avail = 0, delay = 2064, buffer = 512 Suspicious buffer position (3 total): avail = 0, delay = 2096, buffer = 512 ... 2. Since many samples are moved to DSP(delay), the measured rate of the ring-buffer is high. (I measured it by alsa_conformance_test, which only test the sampling rate in the ring buffer of kernel not DSP) 3. Since CRAS writes samples with a fixed frequency, this behavior will take all samples from the ring buffer, which is seen as underrun by CRAS. (It seems that it is not a real underrun because that avail does not larger than buffer size. Maybe CRAS should also take dalay into account.) 4. In spite of it is not a real underrun, the large delay is still a big problem. Can we apply the constraint to fix it? Or any better idea? Thanks, Yu-Hsuan
drivers/net/ethernet/realtek/r8169_main.c:1872 rtl_coalesce_choose_scale() warn: passing a valid pointer to 'PTR_ERR'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: bb5baaa9238ecf8f13b112232c7bbe0d3d598ee8
commit: 2815b30535a0613ee07d477d0c628100f40b6059 r8169: merge scale for tx and
rx irq coalescing
date: 3 months ago
config: parisc-randconfig-m031-20200811 (attached as .config)
compiler: hppa-linux-gcc (GCC) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
New smatch warnings:
drivers/net/ethernet/realtek/r8169_main.c:1872 rtl_coalesce_choose_scale()
warn: passing a valid pointer to 'PTR_ERR'
Old smatch warnings:
drivers/net/ethernet/realtek/r8169_main.c:1837 rtl_get_coalesce() warn: passing
a valid pointer to 'PTR_ERR'
vim +/PTR_ERR +1872 drivers/net/ethernet/realtek/r8169_main.c
1862
1863 /* choose appropriate scale factor and CPlusCmd[0:1] for (speed, nsec)
*/
1864 static int rtl_coalesce_choose_scale(struct rtl8169_private *tp, u32
nsec,
1865 u16 *cp01)
1866 {
1867 const struct rtl_coalesce_info *ci;
1868 u16 i;
1869
1870 ci = rtl_coalesce_info(tp);
1871 if (IS_ERR(ci))
> 1872 return PTR_ERR(ci);
1873
1874 for (i = 0; i < 4; i++) {
1875 if (nsec <= ci->scale_nsecs[i] * RTL_COALESCE_T_MAX) {
1876 *cp01 = i;
1877 return ci->scale_nsecs[i];
1878 }
1879 }
1880
1881 return -EINVAL;
1882 }
1883
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: arch/sparc/include/asm/cmpxchg_64.h:161:55: sparse: sparse: cast truncates bits from constant value (ffffffffe0f510cc becomes cc)
Hi,
On Wed, Aug 12, 2020 at 09:49:38AM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: fb893de323e2d39f7a1f6df425703a2edbdf56ea
> commit: 47e4937a4a7ca4184fd282791dfee76c6799966a erofs: move erofs out of
> staging
> date: 12 months ago
> config: sparc64-randconfig-s032-20200812 (attached as .config)
> compiler: sparc64-linux-gcc (GCC) 9.3.0
> reproduce:
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # apt-get install sparse
> # sparse version: v0.6.2-168-g9554805c-dirty
> git checkout 47e4937a4a7ca4184fd282791dfee76c6799966a
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
> CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=sparc64
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot
>
>
> sparse warnings: (new ones prefixed by >>)
>
>fs/erofs/utils.c: note: in included file (through
> arch/sparc/include/asm/cmpxchg.h, arch/sparc/include/asm/atomic_64.h,
> arch/sparc/include/asm/atomic.h, ...):
> >> arch/sparc/include/asm/cmpxchg_64.h:161:55: sparse: sparse: cast truncates
> >> bits from constant value (e0f510cc becomes cc)
> --
>fs/erofs/zdata.c: note: in included file (through
> arch/sparc/include/asm/cmpxchg.h, arch/sparc/include/asm/atomic_64.h,
> arch/sparc/include/asm/atomic.h, ...):
> >> arch/sparc/include/asm/cmpxchg_64.h:161:55: sparse: sparse: cast truncates
> >> bits from constant value (e0f510cc becomes cc)
>arch/sparc/include/asm/cmpxchg_64.h:161:50: sparse: sparse: cast truncates
> bits from constant value (5f0ecafe becomes fe)
>arch/sparc/include/asm/cmpxchg_64.h:161:50: sparse: sparse: cast truncates
> bits from constant value (5f0ecafe becomes fe)
>arch/sparc/include/asm/cmpxchg_64.h:161:55: sparse: sparse: cast truncates
> bits from constant value (5f0edead becomes ad)
>
> vim +161 arch/sparc/include/asm/cmpxchg_64.h
>
> d550bbd40c0e10 David Howells 2012-03-28 155
> d550bbd40c0e10 David Howells 2012-03-28 156 static inline unsigned long
> d550bbd40c0e10 David Howells 2012-03-28 157 __cmpxchg(volatile void *ptr,
> unsigned long old, unsigned long new, int size)
> d550bbd40c0e10 David Howells 2012-03-28 158 {
> d550bbd40c0e10 David Howells 2012-03-28 159 switch (size) {
> a12ee2349312d7 Babu Moger2017-05-24 160 case 1:
> a12ee2349312d7 Babu Moger2017-05-24 @161 return
> __cmpxchg_u8(ptr, old, new);
> d550bbd40c0e10 David Howells 2012-03-28 162 case 4:
> d550bbd40c0e10 David Howells 2012-03-28 163 return
> __cmpxchg_u32(ptr, old, new);
> d550bbd40c0e10 David Howells 2012-03-28 164 case 8:
> d550bbd40c0e10 David Howells 2012-03-28 165 return
> __cmpxchg_u64(ptr, old, new);
> d550bbd40c0e10 David Howells 2012-03-28 166 }
> d550bbd40c0e10 David Howells 2012-03-28 167
> __cmpxchg_called_with_bad_pointer();
> d550bbd40c0e10 David Howells 2012-03-28 168 return old;
> d550bbd40c0e10 David Howells 2012-03-28 169 }
> d550bbd40c0e10 David Howells 2012-03-28 170
Again, I have no idea how to deal with that in my current
gatekeeping code.
I got these reports, but I cannot help to resolve that.
Even I don't know if that's another sparse issue (since I
only got such reports on sparc and alpha arch, but no x86
or arm64.)
https://lore.kernel.org/r/202007251532.y5a10zoo%25...@intel.com
https://lore.kernel.org/r/202007272132.1agbbo3u%25...@intel.com
https://lore.kernel.org/r/202008100408.wc6wgrac%25...@intel.com
https://lore.kernel.org/r/202008120933.yrvhhyoa%25...@intel.com
If no one can help that, could you please silence such reports.
It really makes me confusing.
Thanks,
Gao Xiang
>
> :: The code at line 161 was first introduced by commit
> :: a12ee2349312d7112b9b7c6ac2e70c5ec2ca334e arch/sparc: Introduce
> cmpxchg_u8 SPARC
>
> :: TO: Babu Moger
> :: CC: David S. Miller
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[PATCH] lib/cmdline: prevent unintented access to address
When args = "\"\0", "i" will be 0 and args[i-1] is used (line:238)
Because of "i" is an unsigned int type,
the function will access at args[0x]
It can make a crash
Signed-off-by: Seungil Kang
---
lib/cmdline.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/cmdline.c b/lib/cmdline.c
index fbb9981a04a4..2fd29d7723b2 100644
--- a/lib/cmdline.c
+++ b/lib/cmdline.c
@@ -200,7 +200,7 @@ bool parse_option_str(const char *str, const char *option)
*/
char *next_arg(char *args, char **param, char **val)
{
- unsigned int i, equals = 0;
+ int i, equals = 0;
int in_quote = 0, quoted = 0;
char *next;
--
2.17.1
[PATCH v3] usb: typec: tcpm: Fix TDA 2.2.1.1 and TDA 2.2.1.2 failures
>From the spec: "7.1.5 Response to Hard Resets Hard Reset Signaling indicates a communication failure has occurred and the Source Shall stop driving VCONN, Shall remove Rp from the VCONN pin and Shall drive VBUS to vSafe0V as shown in Figure 7-9. The USB connection May reset during a Hard Reset since the VBUS voltage will be less than vSafe5V for an extended period of time. After establishing the vSafe0V voltage condition on VBUS, the Source Shall wait tSrcRecover before re-applying VCONN and restoring VBUS to vSafe5V. A Source Shall conform to the VCONN timing as specified in [USB Type-C 1.3]." Signed-off-by: Badhri Jagan Sridharan Reviewed-by: Guenter Roeck --- Changes since V1 (Guenter's suggestion): - Bound SRC_HARD_RESET_VBUS_ON to accommodate tcpc drivers which doesn't update the vbus status. Changes since V2: - Reviewed-by: Guenter Roeck --- drivers/usb/typec/tcpm/tcpm.c | 28 +--- 1 file changed, 25 insertions(+), 3 deletions(-) diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c index 3ef37202ee37..a48e3f90d196 100644 --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -3372,13 +3372,31 @@ static void run_state_machine(struct tcpm_port *port) tcpm_set_state(port, SNK_HARD_RESET_SINK_OFF, 0); break; case SRC_HARD_RESET_VBUS_OFF: - tcpm_set_vconn(port, true); + /* +* 7.1.5 Response to Hard Resets +* Hard Reset Signaling indicates a communication failure has occurred and the +* Source Shall stop driving VCONN, Shall remove Rp from the VCONN pin and Shall +* drive VBUS to vSafe0V as shown in Figure 7-9. +*/ + tcpm_set_vconn(port, false); tcpm_set_vbus(port, false); tcpm_set_roles(port, port->self_powered, TYPEC_SOURCE, tcpm_data_role_for_source(port)); - tcpm_set_state(port, SRC_HARD_RESET_VBUS_ON, PD_T_SRC_RECOVER); + /* +* If tcpc fails to notify vbus off, TCPM will wait for PD_T_SAFE_0V + +* PD_T_SRC_RECOVER before turning vbus back on. +* From Table 7-12 Sequence Description for a Source Initiated Hard Reset: +* 4. Policy Engine waits tPSHardReset after sending Hard Reset Signaling and then +* tells the Device Policy Manager to instruct the power supply to perform a +* Hard Reset. The transition to vSafe0V Shall occur within tSafe0V (t2). +* 5. After tSrcRecover the Source applies power to VBUS in an attempt to +* re-establish communication with the Sink and resume USB Default Operation. +* The transition to vSafe5V Shall occur within tSrcTurnOn(t4). +*/ + tcpm_set_state(port, SRC_HARD_RESET_VBUS_ON, PD_T_SAFE_0V + PD_T_SRC_RECOVER); break; case SRC_HARD_RESET_VBUS_ON: + tcpm_set_vconn(port, true); tcpm_set_vbus(port, true); port->tcpc->set_pd_rx(port->tcpc, true); tcpm_set_attached_state(port, true); @@ -3944,7 +3962,11 @@ static void _tcpm_pd_vbus_off(struct tcpm_port *port) tcpm_set_state(port, SNK_HARD_RESET_WAIT_VBUS, 0); break; case SRC_HARD_RESET_VBUS_OFF: - tcpm_set_state(port, SRC_HARD_RESET_VBUS_ON, 0); + /* +* After establishing the vSafe0V voltage condition on VBUS, the Source Shall wait +* tSrcRecover before re-applying VCONN and restoring VBUS to vSafe5V. +*/ + tcpm_set_state(port, SRC_HARD_RESET_VBUS_ON, PD_T_SRC_RECOVER); break; case HARD_RESET_SEND: break; -- 2.28.0.236.gb10cc79966-goog
drivers/i2c/busses/i2c-mlxcpld.c:97:17: sparse: got void COPYING CREDITS Documentation Kbuild Kconfig LICENSES MAINTAINERS Makefile README arch block certs crypto drivers fs include init ipc kernel li
Hi Krzysztof, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: bb5baaa9238ecf8f13b112232c7bbe0d3d598ee8 commit: 4a2d5f663dab6614772d8e28ca190b127ba46d9d i2c: Enable compile testing for more drivers date: 7 months ago config: riscv-randconfig-s031-20200812 (attached as .config) compiler: riscv64-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.2-168-g9554805c-dirty git checkout 4a2d5f663dab6614772d8e28ca190b127ba46d9d # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=riscv If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) drivers/i2c/busses/i2c-mlxcpld.c:97:17: sparse: sparse: cast removes address space '' of expression drivers/i2c/busses/i2c-mlxcpld.c:97:17: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] *addr @@ got void * @@ drivers/i2c/busses/i2c-mlxcpld.c:97:17: sparse: expected void volatile [noderef] *addr >> drivers/i2c/busses/i2c-mlxcpld.c:97:17: sparse: got void * drivers/i2c/busses/i2c-mlxcpld.c:99:17: sparse: sparse: cast removes address space '' of expression drivers/i2c/busses/i2c-mlxcpld.c:99:17: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] *addr @@ got void * @@ drivers/i2c/busses/i2c-mlxcpld.c:99:17: sparse: expected void volatile [noderef] *addr drivers/i2c/busses/i2c-mlxcpld.c:99:17: sparse: got void * drivers/i2c/busses/i2c-mlxcpld.c:107:38: sparse: sparse: cast removes address space '' of expression drivers/i2c/busses/i2c-mlxcpld.c:107:38: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] *addr @@ got void * @@ drivers/i2c/busses/i2c-mlxcpld.c:107:38: sparse: expected void const volatile [noderef] *addr drivers/i2c/busses/i2c-mlxcpld.c:107:38: sparse: got void * drivers/i2c/busses/i2c-mlxcpld.c:109:31: sparse: sparse: cast removes address space '' of expression drivers/i2c/busses/i2c-mlxcpld.c:109:31: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] *addr @@ got void * @@ drivers/i2c/busses/i2c-mlxcpld.c:109:31: sparse: expected void const volatile [noderef] *addr drivers/i2c/busses/i2c-mlxcpld.c:109:31: sparse: got void * drivers/i2c/busses/i2c-mlxcpld.c:119:27: sparse: sparse: cast removes address space '' of expression drivers/i2c/busses/i2c-mlxcpld.c:119:27: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] *addr @@ got void * @@ drivers/i2c/busses/i2c-mlxcpld.c:119:27: sparse: expected void const volatile [noderef] *addr drivers/i2c/busses/i2c-mlxcpld.c:119:27: sparse: got void * drivers/i2c/busses/i2c-mlxcpld.c:122:34: sparse: sparse: cast removes address space '' of expression drivers/i2c/busses/i2c-mlxcpld.c:122:34: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] *addr @@ got void * @@ drivers/i2c/busses/i2c-mlxcpld.c:122:34: sparse: expected void const volatile [noderef] *addr drivers/i2c/busses/i2c-mlxcpld.c:122:34: sparse: got void * drivers/i2c/busses/i2c-mlxcpld.c:125:34: sparse: sparse: cast removes address space '' of expression drivers/i2c/busses/i2c-mlxcpld.c:125:34: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] *addr @@ got void * @@ drivers/i2c/busses/i2c-mlxcpld.c:125:34: sparse: expected void const volatile [noderef] *addr drivers/i2c/busses/i2c-mlxcpld.c:125:34: sparse: got void * drivers/i2c/busses/i2c-mlxcpld.c:126:31: sparse: sparse: cast removes address space '' of expression drivers/i2c/busses/i2c-mlxcpld.c:126:31: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] *addr @@ got void * @@ drivers/i2c/busses/i2c-mlxcpld.c:126:31: sparse: expected void const volatile [noderef] *addr drivers/i2c/busses/i2c-mlxcpld.c:126:31: sparse: got void * drivers/i2c/busses/i2c-mlxcpld.c:129:34: sparse: sparse: cast removes address space '' of expression drivers/i2c/busses/i2c-mlxcpld.c:129:34: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile
Re: KASAN: use-after-free Read in __io_req_task_submit
#syz dup: KASAN: use-after-free Read in io_async_task_func -- Jens Axboe
Re: [PATCH RFC v2 00/18] Add VFIO mediated device support and DEV-MSI support for the idxd driver
On Wed, 12 Aug 2020 01:58:00 + "Tian, Kevin" wrote: > > From: Alex Williamson > > Sent: Wednesday, August 12, 2020 1:01 AM > > > > On Mon, 10 Aug 2020 07:32:24 + > > "Tian, Kevin" wrote: > > > > > > From: Jason Gunthorpe > > > > Sent: Friday, August 7, 2020 8:20 PM > > > > > > > > On Wed, Aug 05, 2020 at 07:22:58PM -0600, Alex Williamson wrote: > > > > > > > > > If you see this as an abuse of the framework, then let's identify > > > > > those > > > > > specific issues and come up with a better approach. As we've > > > > > discussed > > > > > before, things like basic PCI config space emulation are acceptable > > > > > overhead and low risk (imo) and some degree of register emulation is > > > > > well within the territory of an mdev driver. > > > > > > > > What troubles me is that idxd already has a direct userspace interface > > > > to its HW, and does userspace DMA. The purpose of this mdev is to > > > > provide a second direct userspace interface that is a little different > > > > and trivially plugs into the virtualization stack. > > > > > > No. Userspace DMA and subdevice passthrough (what mdev provides) > > > are two distinct usages IMO (at least in idxd context). and this might > > > be the main divergence between us, thus let me put more words here. > > > If we could reach consensus in this matter, which direction to go > > > would be clearer. > > > > > > First, a passthrough interface requires some unique requirements > > > which are not commonly observed in an userspace DMA interface, e.g.: > > > > > > - Tracking DMA dirty pages for live migration; > > > - A set of interfaces for using SVA inside guest; > > > * PASID allocation/free (on some platforms); > > > * bind/unbind guest mm/page table (nested translation); > > > * invalidate IOMMU cache/iotlb for guest page table changes; > > > * report page request from device to guest; > > > * forward page response from guest to device; > > > - Configuring irqbypass for posted interrupt; > > > - ... > > > > > > Second, a passthrough interface requires delegating raw controllability > > > of subdevice to guest driver, while the same delegation might not be > > > required for implementing an userspace DMA interface (especially for > > > modern devices which support SVA). For example, idxd allows following > > > setting per wq (guest driver may configure them in any combination): > > > - put in dedicated or shared mode; > > > - enable/disable SVA; > > > - Associate guest-provided PASID to MSI/IMS entry; > > > - set threshold; > > > - allow/deny privileged access; > > > - allocate/free interrupt handle (enlightened for guest); > > > - collect error status; > > > - ... > > > > > > We plan to support idxd userspace DMA with SVA. The driver just needs > > > to prepare a wq with a predefined configuration (e.g. shared, SVA, > > > etc.), bind the process mm to IOMMU (non-nested) and then map > > > the portal to userspace. The goal that userspace can do DMA to > > > associated wq doesn't change the fact that the wq is still *owned* > > > and *controlled* by kernel driver. However as far as passthrough > > > is concerned, the wq is considered 'owned' by the guest driver thus > > > we need an interface which can support low-level *controllability* > > > from guest driver. It is sort of a mess in uAPI when mixing the > > > two together. > > > > > > Based on above two reasons, we see distinct requirements between > > > userspace DMA and passthrough interfaces, at least in idxd context > > > (though other devices may have less distinction in-between). Therefore, > > > we didn't see the value/necessity of reinventing the wheel that mdev > > > already handles well to evolve an simple application-oriented usespace > > > DMA interface to a complex guest-driver-oriented passthrough interface. > > > The complexity of doing so would incur far more kernel-side changes > > > than the portion of emulation code that you've been concerned about... > > > > > > > > > > > I don't think VFIO should be the only entry point to > > > > virtualization. If we say the universe of devices doing user space DMA > > > > must also implement a VFIO mdev to plug into virtualization then it > > > > will be alot of mdevs. > > > > > > Certainly VFIO will not be the only entry point. and This has to be a > > > case-by-case decision. If an userspace DMA interface can be easily > > > adapted to be a passthrough one, it might be the choice. But for idxd, > > > we see mdev a much better fit here, given the big difference between > > > what userspace DMA requires and what guest driver requires in this hw. > > > > > > > > > > > I would prefer to see that the existing userspace interface have the > > > > extra needed bits for virtualization (eg by having appropriate > > > > internal kernel APIs to make this easy) and all the emulation to build > > > > the synthetic PCI device be done in userspace. > > > > > > In the end what decides the direction
[GIT PULL] VFIO updates for v5.9-rc1
Hi Linus, The following changes since commit 92ed301919932f13b9172e525674157e983d: Linux 5.8-rc7 (2020-07-26 14:14:06 -0700) are available in the Git repository at: git://github.com/awilliam/linux-vfio.git tags/vfio-v5.9-rc1 for you to fetch changes up to ccd59dce1a21f473518bf273bdf5b182bab955b3: vfio/type1: Refactor vfio_iommu_type1_ioctl() (2020-07-27 13:46:13 -0600) VFIO updates for v5.9-rc1 - Inclusive naming updates (Alex Williamson) - Intel X550 INTx quirk (Alex Williamson) - Error path resched between unmaps (Xiang Zheng) - SPAPR IOMMU pin_user_pages() conversion (John Hubbard) - Trivial mutex simplification (Alex Williamson) - QAT device denylist (Giovanni Cabiddu) - type1 IOMMU ioctl refactor (Liu Yi L) Alex Williamson (3): vfio: Cleanup allowed driver naming vfio/pci: Add Intel X550 to hidden INTx devices vfio/pci: Hold igate across releasing eventfd contexts Giovanni Cabiddu (3): PCI: Add Intel QuickAssist device IDs vfio/pci: Add device denylist vfio/pci: Add QAT devices to denylist John Hubbard (1): vfio/spapr_tce: convert get_user_pages() --> pin_user_pages() Liu Yi L (1): vfio/type1: Refactor vfio_iommu_type1_ioctl() Xiang Zheng (1): vfio/type1: Add conditional rescheduling after iommu map failed drivers/vfio/pci/vfio_pci.c | 54 - drivers/vfio/vfio.c | 13 +- drivers/vfio/vfio_iommu_spapr_tce.c | 4 +- drivers/vfio/vfio_iommu_type1.c | 398 +++- include/linux/pci_ids.h | 6 + 5 files changed, 282 insertions(+), 193 deletions(-)
Re: [PATCH net] drivers/net/wan/x25_asy: Added needed_headroom and a skb->len check
On Tue, Aug 11, 2020 at 10:32 AM David Miller wrote: > > Applied, thank you. Thank you!
[PATCH 1/2 v3] tcpm: During PR_SWAP, source caps should be sent only after tSwapSourceStart
>From the spec: "6.6.8.1 SwapSourceStartTimer The SwapSourceStartTimer Shall be used by the new Source, after a Power Role Swap or Fast Role Swap, to ensure that it does not send Source_Capabilities Message before the new Sink is ready to receive the Source_Capabilities Message. The new Source Shall Not send the Source_Capabilities Message earlier than tSwapSourceStart after the last bit of the EOP of GoodCRC Message sent in response to the PS_RDY Message sent by the new Source indicating that its power supply is ready." This fixes TD.PD.CP.E3, TD.PD.CP.E4, TD.PD.CP.E5 failures Signed-off-by: Badhri Jagan Sridharan Reviewed-by: Guenter Roeck --- Changes since V1: - Comment on the permissible values of tSwapSourceStart Changes since V2: - Fixing alignment issue pointed out by Guenter. - Added Reviewed-by: Guenter Roeck --- drivers/usb/typec/tcpm/tcpm.c | 2 +- include/linux/usb/pd.h| 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c index 3ef37202ee37..d38347bd3335 100644 --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -3555,7 +3555,7 @@ static void run_state_machine(struct tcpm_port *port) */ tcpm_set_pwr_role(port, TYPEC_SOURCE); tcpm_pd_send_control(port, PD_CTRL_PS_RDY); - tcpm_set_state(port, SRC_STARTUP, 0); + tcpm_set_state(port, SRC_STARTUP, PD_T_SWAP_SRC_START); break; case VCONN_SWAP_ACCEPT: diff --git a/include/linux/usb/pd.h b/include/linux/usb/pd.h index b6c233e79bd4..1df895e4680b 100644 --- a/include/linux/usb/pd.h +++ b/include/linux/usb/pd.h @@ -473,6 +473,7 @@ static inline unsigned int rdo_max_power(u32 rdo) #define PD_T_ERROR_RECOVERY100 /* minimum 25 is insufficient */ #define PD_T_SRCSWAPSTDBY 625 /* Maximum of 650ms */ #define PD_T_NEWSRC250 /* Maximum of 275ms */ +#define PD_T_SWAP_SRC_START20 /* Minimum of 20ms */ #define PD_T_DRP_TRY 100 /* 75 - 150 ms */ #define PD_T_DRP_TRYWAIT 600 /* 400 - 800 ms */ -- 2.28.0.236.gb10cc79966-goog
[PATCH 2/2 v3] usb: typec: pd: Fix formatting in pd.h header
Replacing spaces with tabs for PD_T_* constants. Signed-off-by: Badhri Jagan Sridharan --- Change history: First version. Keeping the version number same as the parent. --- include/linux/usb/pd.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/linux/usb/pd.h b/include/linux/usb/pd.h index 1df895e4680b..f842e4589bd2 100644 --- a/include/linux/usb/pd.h +++ b/include/linux/usb/pd.h @@ -471,9 +471,10 @@ static inline unsigned int rdo_max_power(u32 rdo) #define PD_T_VCONN_SOURCE_ON 100 #define PD_T_SINK_REQUEST 100 /* 100 ms minimum */ #define PD_T_ERROR_RECOVERY100 /* minimum 25 is insufficient */ -#define PD_T_SRCSWAPSTDBY 625 /* Maximum of 650ms */ -#define PD_T_NEWSRC250 /* Maximum of 275ms */ +#define PD_T_SRCSWAPSTDBY 625 /* Maximum of 650ms */ +#define PD_T_NEWSRC250 /* Maximum of 275ms */ #define PD_T_SWAP_SRC_START20 /* Minimum of 20ms */ +#define PD_T_BIST_CONT_MODE50 /* 30 - 60 ms */ #define PD_T_DRP_TRY 100 /* 75 - 150 ms */ #define PD_T_DRP_TRYWAIT 600 /* 400 - 800 ms */ @@ -484,5 +485,4 @@ static inline unsigned int rdo_max_power(u32 rdo) #define PD_N_CAPS_COUNT(PD_T_NO_RESPONSE / PD_T_SEND_SOURCE_CAP) #define PD_N_HARD_RESET_COUNT 2 -#define PD_T_BIST_CONT_MODE50 /* 30 - 60 ms */ #endif /* __LINUX_USB_PD_H */ -- 2.28.0.236.gb10cc79966-goog
Re: [PATCH net] drivers/net/wan/x25_asy: Added needed_headroom and a skb->len check
On Tue, Aug 11, 2020 at 3:50 AM Willem de Bruijn wrote: > > > I became interested in X.25 when I was trying different address > > families that Linux supported. I tried AF_X25 sockets. And then I > > tried to use the X.25 link layer directly through AF_PACKET. I believe > > both AF_X25 sockets and AF_PACKET sockets need to work without > > problems with X.25 drivers - lapbether and x25_asy. There is another > > X.25 driver (hdlc_x25) in the kernel. I haven't been able to run that > > driver. But that driver seems to be the real driver which is really > > used, and I know Martin Schiller is an active user and > > developer of that driver. > > Great, sounds like we might have additional LAPB and X25 maintainers soon? :) :) I just want to fix any problems I see. I'll do this whenever I have time. > MAINTAINERS lists Andrew Hendry as maintainer for X.25. Please do CC them. OK. I'll surely do that. Thanks!
Re: [RFC v4 1/3] usb: dwc3: Resize TX FIFOs to meet EP bursting requirements
On Wed, Jun 24, 2020 at 10:31 AM Wesley Cheng wrote:
>
> Some devices have USB compositions which may require multiple endpoints
> that support EP bursting. HW defined TX FIFO sizes may not always be
> sufficient for these compositions. By utilizing flexible TX FIFO
> allocation, this allows for endpoints to request the required FIFO depth to
> achieve higher bandwidth. With some higher bMaxBurst configurations, using
> a larger TX FIFO size results in better TX throughput.
>
> Ensure that one TX FIFO is reserved for every IN endpoint. This allows for
> the FIFO logic to prevent running out of FIFO space.
>
You may do this for only allocated endpoints, but you need override
default .match_ep
API. See cdns3/gadget.c and cdns3/ep0.c as an example.
Peter
> Signed-off-by: Wesley Cheng
> ---
> drivers/usb/dwc3/core.c | 2 +
> drivers/usb/dwc3/core.h | 8 +++
> drivers/usb/dwc3/ep0.c| 37 +++-
> drivers/usb/dwc3/gadget.c | 115 ++
> 4 files changed, 161 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index edc17155cb2b..cca555493929 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -1304,6 +1304,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
> _thr_num_pkt_prd);
> device_property_read_u8(dev, "snps,tx-max-burst-prd",
> _max_burst_prd);
> + dwc->needs_fifo_resize = device_property_read_bool(dev,
> + "tx-fifo-resize");
>
> dwc->disable_scramble_quirk = device_property_read_bool(dev,
> "snps,disable_scramble_quirk");
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index 4c171a8e215f..ce0bf288b6ac 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -675,6 +675,7 @@ struct dwc3_event_buffer {
> * isochronous START TRANSFER command failure workaround
> * @start_cmd_status: the status of testing START TRANSFER command with
> * combo_num = 'b00
> + * @fifo_depth: allocated TXFIFO depth
> */
> struct dwc3_ep {
> struct usb_ep endpoint;
> @@ -727,6 +728,7 @@ struct dwc3_ep {
> /* For isochronous START TRANSFER workaround only */
> u8 combo_num;
> int start_cmd_status;
> + int fifo_depth;
> };
>
> enum dwc3_phy {
> @@ -1004,6 +1006,7 @@ struct dwc3_scratchpad_array {
> * 1 - utmi_l1_suspend_n
> * @is_fpga: true when we are using the FPGA board
> * @pending_events: true when we have pending IRQs to be handled
> + * @needs_fifo_resize: not all users might want fifo resizing, flag it
> * @pullups_connected: true when Run/Stop bit is set
> * @setup_packet_pending: true when there's a Setup Packet in FIFO.
> Workaround
> * @three_stage_setup: set if we perform a three phase setup
> @@ -1044,6 +1047,8 @@ struct dwc3_scratchpad_array {
> * @dis_metastability_quirk: set to disable metastability quirk.
> * @imod_interval: set the interrupt moderation interval in 250ns
> * increments or 0 to disable.
> + * @last_fifo_depth: total TXFIFO depth of all enabled USB IN/INT endpoints
> + * @num_ep_resized: the number of TX FIFOs that have already been resized
> */
> struct dwc3 {
> struct work_struct drd_work;
> @@ -1204,6 +1209,7 @@ struct dwc3 {
> unsignedis_utmi_l1_suspend:1;
> unsignedis_fpga:1;
> unsignedpending_events:1;
> + unsignedneeds_fifo_resize:1;
> unsignedpullups_connected:1;
> unsignedsetup_packet_pending:1;
> unsignedthree_stage_setup:1;
> @@ -1236,6 +1242,8 @@ struct dwc3 {
> unsigneddis_metastability_quirk:1;
>
> u16 imod_interval;
> + int last_fifo_depth;
> + int num_ep_resized;
> };
>
> #define INCRX_BURST_MODE 0
> diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
> index 6dee4dabc0a4..76db9b530861 100644
> --- a/drivers/usb/dwc3/ep0.c
> +++ b/drivers/usb/dwc3/ep0.c
> @@ -601,8 +601,9 @@ static int dwc3_ep0_set_config(struct dwc3 *dwc, struct
> usb_ctrlrequest *ctrl)
> {
> enum usb_device_state state = dwc->gadget.state;
> u32 cfg;
> - int ret;
> + int ret, num, size;
> u32 reg;
> + struct dwc3_ep *dep;
>
> cfg = le16_to_cpu(ctrl->wValue);
>
> @@ -611,6 +612,40 @@ static int dwc3_ep0_set_config(struct dwc3 *dwc, struct
> usb_ctrlrequest *ctrl)
> return -EINVAL;
>
> case USB_STATE_ADDRESS:
> + /*
> +* If tx-fifo-resize flag is not set for the controller, then
> +* do not clear
KASAN: use-after-free Read in __io_req_task_submit
Hello, syzbot found the following issue on: HEAD commit:00e4db51 Merge tag 'perf-tools-2020-08-10' of git://git.ke.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1382902290 kernel config: https://syzkaller.appspot.com/x/.config?x=64a3282e09356140 dashboard link: https://syzkaller.appspot.com/bug?extid=3c72ce3136524268d7af compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1612cee290 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14e3b1b290 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+3c72ce3136524268d...@syzkaller.appspotmail.com == BUG: KASAN: use-after-free in instrument_atomic_read include/linux/instrumented.h:56 [inline] BUG: KASAN: use-after-free in atomic64_read include/asm-generic/atomic-instrumented.h:837 [inline] BUG: KASAN: use-after-free in atomic_long_read include/asm-generic/atomic-long.h:29 [inline] BUG: KASAN: use-after-free in __mutex_unlock_slowpath+0x8e/0x610 kernel/locking/mutex.c:1237 Read of size 8 at addr 88809de9c3c0 by task syz-executor338/1394 CPU: 1 PID: 1394 Comm: syz-executor338 Not tainted 5.8.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x18f/0x20d lib/dump_stack.c:118 print_address_description.constprop.0.cold+0xae/0x497 mm/kasan/report.c:383 __kasan_report mm/kasan/report.c:513 [inline] kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530 check_memory_region_inline mm/kasan/generic.c:186 [inline] check_memory_region+0x13d/0x180 mm/kasan/generic.c:192 instrument_atomic_read include/linux/instrumented.h:56 [inline] atomic64_read include/asm-generic/atomic-instrumented.h:837 [inline] atomic_long_read include/asm-generic/atomic-long.h:29 [inline] __mutex_unlock_slowpath+0x8e/0x610 kernel/locking/mutex.c:1237 __io_req_task_submit+0x8a/0xe0 fs/io_uring.c:1760 task_work_run+0xdd/0x190 kernel/task_work.c:135 tracehook_notify_resume include/linux/tracehook.h:188 [inline] exit_to_user_mode_loop kernel/entry/common.c:139 [inline] exit_to_user_mode_prepare+0x1aa/0x1d0 kernel/entry/common.c:166 syscall_exit_to_user_mode+0x59/0x2b0 kernel/entry/common.c:241 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x449b99 Code: e8 3c e6 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 2b 06 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f4c0bec2cf8 EFLAGS: 0246 ORIG_RAX: 00ca RAX: RBX: 006e5a38 RCX: 00449b99 RDX: RSI: 0080 RDI: 006e5a38 RBP: 006e5a30 R08: R09: R10: R11: 0246 R12: 006e5a3c R13: 7ffdb6e3600f R14: 7f4c0bec39c0 R15: 20c49ba5e353f7cf Allocated by task 1347: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48 kasan_set_track mm/kasan/common.c:56 [inline] __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:461 kmem_cache_alloc_trace+0x16e/0x2c0 mm/slab.c:3550 kmalloc include/linux/slab.h:554 [inline] kzalloc include/linux/slab.h:666 [inline] io_ring_ctx_alloc fs/io_uring.c:1030 [inline] io_uring_create fs/io_uring.c:8308 [inline] io_uring_setup+0x4df/0x28c0 fs/io_uring.c:8401 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Freed by task 6838: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48 kasan_set_track+0x1c/0x30 mm/kasan/common.c:56 kasan_set_free_info+0x1b/0x30 mm/kasan/generic.c:355 __kasan_slab_free+0xd8/0x120 mm/kasan/common.c:422 __cache_free mm/slab.c:3418 [inline] kfree+0x103/0x2c0 mm/slab.c:3756 process_one_work+0x94c/0x1670 kernel/workqueue.c:2269 worker_thread+0x64c/0x1120 kernel/workqueue.c:2415 kthread+0x3b5/0x4a0 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 Last call_rcu(): kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48 kasan_record_aux_stack+0x82/0xb0 mm/kasan/generic.c:346 __call_rcu kernel/rcu/tree.c:2894 [inline] call_rcu+0x14f/0x7e0 kernel/rcu/tree.c:2968 __percpu_ref_switch_to_atomic lib/percpu-refcount.c:192 [inline] __percpu_ref_switch_mode+0x365/0x700 lib/percpu-refcount.c:237 percpu_ref_kill_and_confirm+0x94/0x350 lib/percpu-refcount.c:350 percpu_ref_kill include/linux/percpu-refcount.h:136 [inline] io_ring_ctx_wait_and_kill+0x38/0x600 fs/io_uring.c:7797 io_uring_release+0x3e/0x50 fs/io_uring.c:7829 __fput+0x285/0x920 fs/file_table.c:281 task_work_run+0xdd/0x190 kernel/task_work.c:135 tracehook_notify_resume include/linux/tracehook.h:188 [inline] exit_to_user_mode_loop kernel/entry/common.c:139 [inline] exit_to_user_mode_prepare+0x1aa/0x1d0 kernel/entry/common.c:166
Re: VDPA Debug/Statistics
On 2020/8/11 下午7:58, Eli Cohen wrote: On Tue, Aug 11, 2020 at 11:26:20AM +, Eli Cohen wrote: Hi All Currently, the only statistics we get for a VDPA instance comes from the virtio_net device instance. Since VDPA involves hardware acceleration, there can be quite a lot of information that can be fetched from the underlying device. Currently there is no generic method to fetch this information. One way of doing this can be to create a the host, a net device for each VDPA instance, and use it to get this information or do some configuration. Ethtool can be used in such a case The problems are: - vDPA is not net specific - vDPA should be transparent to host networking stack I would like to hear what you think about this or maybe you have some other ideas to address this topic. Thanks, Eli Something I'm not sure I understand is how are vdpa instances created on mellanox cards? There's a devlink command for that, is that right? Can that be extended for stats? Currently any VF will be probed as VDPA device. We're adding devlink support but I am not sure if devlink is suitable for displaying statistics. We will discuss internally but I wanted to know why you guys think. I agree with Michael, if it's possible, integrating stats with devlink should be the best. Having another interface with is just for stats looks not good. Thanks -- MST
Re: [PATCH v2 1/2] ASoC: q6afe-dai: mark all widgets registers as SND_SOC_NOPM
On Tue, Aug 11, 2020 at 5:02 AM Srinivas Kandagatla
wrote:
>
> Looks like the q6afe-dai dapm widget registers are set as "0",
> which is a not correct.
>
> As this registers will be read by ASoC core during startup
> which will throw up errors, Fix this by making the registers
> as SND_SOC_NOPM as these should be never used.
>
> With recent changes to ASoC core, every register read/write
> failures are reported very verbosely. Prior to this fails to reads
> are totally ignored, so we never saw any error messages.
>
> Reported-by: John Stultz
> Fixes: 24c4cbcfac09 ("ASoC: qdsp6: q6afe: Add q6afe dai driver")
> Signed-off-by: Srinivas Kandagatla
> ---
> Changes since v1:
> - replaced reg 0 with SND_SOC_NOPM and removed read callback
>
For both patches:
Tested-by: John Stultz
thanks!
-john
Re: [PATCH v1] usb: typec: tcpm: Fix TDA 2.2.1.1 and TDA 2.2.1.2 failures
On Tue, Aug 11, 2020 at 6:44 PM Guenter Roeck wrote: > > On 8/11/20 6:08 PM, Badhri Jagan Sridharan wrote: > > Yes I did ! https://lkml.org/lkml/2020/8/11/788 ! > > > > For me gmail is grouping V1 and V2 patches in the same thread so > > thought you saw the v2 patch :P > > > > You copied me on v1, but not on v2. I am not on any of the mailing lists > you sent v2 to, so I did not see it. > > Guenter My bad ! Apologies Guenter ! Screwed up while performing the git send-email command. Will make sure that I double check next time. Thanks, Badhri > > > Thanks, > > Badhri > > > > On Tue, Aug 11, 2020 at 5:36 PM Guenter Roeck wrote: > >> > >> On 8/11/20 4:21 PM, Badhri Jagan Sridharan wrote: > >>> Thanks Guenter ! However I don't see a reviewed-by tag :) > >>> > >> > >> Confused. Did you send a v2 with the changes we discussed ? > >> I didn't see that. > >> > >> Thanks, > >> Guenter > >> > >>> On Tue, Aug 11, 2020 at 1:18 PM Guenter Roeck wrote: > > On 8/11/20 12:39 PM, Badhri Jagan Sridharan wrote: > > On Tue, Aug 11, 2020 at 11:45 AM Guenter Roeck > > wrote: > >> > >> On Tue, Aug 11, 2020 at 11:24:07AM -0700, Badhri Jagan Sridharan wrote: > >>> On Mon, Aug 10, 2020 at 6:51 PM Guenter Roeck > >>> wrote: > > On 8/10/20 6:11 PM, Badhri Jagan Sridharan wrote: > > >From the spec: > > "7.1.5 Response to Hard Resets > > Hard Reset Signaling indicates a communication failure has occurred > > and > > the Source Shall stop driving VCONN, Shall remove Rp from the VCONN > > pin > > and Shall drive VBUS to vSafe0V as shown in Figure 7-9. The USB > > connection > > May reset during a Hard Reset since the VBUS voltage will be less > > than > > vSafe5V for an extended period of time. After establishing the > > vSafe0V > > voltage condition on VBUS, the Source Shall wait tSrcRecover before > > re-applying VCONN and restoring VBUS to vSafe5V. A Source Shall > > conform > > to the VCONN timing as specified in [USB Type-C 1.3]." > > > > Signed-off-by: Badhri Jagan Sridharan > > --- > > drivers/usb/typec/tcpm/tcpm.c | 16 +--- > > 1 file changed, 13 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/usb/typec/tcpm/tcpm.c > > b/drivers/usb/typec/tcpm/tcpm.c > > index 3ef37202ee37..e41c4e5d3c71 100644 > > --- a/drivers/usb/typec/tcpm/tcpm.c > > +++ b/drivers/usb/typec/tcpm/tcpm.c > > @@ -3372,13 +3372,19 @@ static void run_state_machine(struct > > tcpm_port *port) > > tcpm_set_state(port, SNK_HARD_RESET_SINK_OFF, > > 0); > > break; > > case SRC_HARD_RESET_VBUS_OFF: > > - tcpm_set_vconn(port, true); > > + /* > > + * 7.1.5 Response to Hard Resets > > + * Hard Reset Signaling indicates a communication > > failure has occurred and the > > + * Source Shall stop driving VCONN, Shall remove Rp > > from the VCONN pin and Shall > > + * drive VBUS to vSafe0V as shown in Figure 7-9. > > + */ > > + tcpm_set_vconn(port, false); > > tcpm_set_vbus(port, false); > > tcpm_set_roles(port, port->self_powered, TYPEC_SOURCE, > > tcpm_data_role_for_source(port)); > > - tcpm_set_state(port, SRC_HARD_RESET_VBUS_ON, > > PD_T_SRC_RECOVER); > > I am a bit concerned about this. If I understand correctly, it means > that > we won't turn VBUS back on unless a SRC_HARD_RESET_VBUS_OFF PD event > is received. > Is that correct ? What happens if that event is never received ? > > Thanks, > Guenter > >>> > >>> The term PD event is a little ambiguous to me. Trying to summarize > >>> the workflow. > >>> Lower level tcpc driver would have to call tcpm_vbus_change which > >>> would in-turn trigger TCPM_VBUS_EVENT > >>> and queries port->tcpc->get_vbus to get the vbus status. It is not > >>> really a PD protocol driven event hence the > >>> confusion. > >>> > >>> "What happens if that event is never received ?" > >>> Yeah TCPM would be in SRC_HARD_RESET_VBUS_OFF till the tcpc calls the > >>> tcpm_vbus_change. > >>> Do you suspect that existing tcpc would not have the capability to > >>> monitor vbus status while sourcing and call tcpm_vbus_change? > >>> > >> That, or the driver might be buggy, or the hardware does't signal a > >> status > >> update, or the update gets lost. I think we should have some backup, > >> to trigger if the
Re: [PATCH 1/4] vdpa: introduce config op to get valid iova range
On 2020/8/11 下午4:29, Michael S. Tsirkin wrote:
On Tue, Aug 11, 2020 at 10:53:09AM +0800, Jason Wang wrote:
On 2020/8/10 下午8:05, Michael S. Tsirkin wrote:
On Thu, Aug 06, 2020 at 03:43:54PM +0300, Eli Cohen wrote:
On Thu, Aug 06, 2020 at 08:29:22AM -0400, Michael S. Tsirkin wrote:
On Thu, Aug 06, 2020 at 03:03:55PM +0300, Eli Cohen wrote:
On Wed, Aug 05, 2020 at 08:51:56AM -0400, Michael S. Tsirkin wrote:
On Wed, Jun 17, 2020 at 11:29:44AM +0800, Jason Wang wrote:
This patch introduce a config op to get valid iova range from the vDPA
device.
Signed-off-by: Jason Wang
---
include/linux/vdpa.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
index 239db794357c..b7633ed2500c 100644
--- a/include/linux/vdpa.h
+++ b/include/linux/vdpa.h
@@ -41,6 +41,16 @@ struct vdpa_device {
unsigned int index;
};
+/**
+ * vDPA IOVA range - the IOVA range support by the device
+ * @start: start of the IOVA range
+ * @end: end of the IOVA range
+ */
+struct vdpa_iova_range {
+ u64 start;
+ u64 end;
+};
+
This is ambiguous. Is end in the range or just behind it?
How about first/last?
It is customary in the kernel to use start-end where end corresponds to
the byte following the last in the range. See struct vm_area_struct
vm_start and vm_end fields
Exactly my point:
include/linux/mm_types.h: unsigned long vm_end; /* The first
byte after our end address
in this case Jason wants it to be the last byte, not one behind.
Maybe start, size? Not ambiguous, and you don't need to do annoying
calculations like size = last - start + 1
Size has a bunch of issues: can overlap, can not cover the entire 64 bit
range. The requisite checks are arguably easier to get wrong than
getting the size if you need it.
Yes, so do you still prefer first/last or just begin/end which is consistent
with iommu_domain_geometry?
Thanks
I prefer first/last I think, these are unambiguous.
E.g.
dma_addr_t aperture_start; /* First address that can be mapped*/
dma_addr_t aperture_end; /* Last address that can be mapped */
instead of addressing ambiguity with a comment, let's just name the field well.
Ok, will do.
Thanks
Re: [PATCH v2] tcpm: During PR_SWAP, source caps should be sent only after tSwapSourceStart
On Tue, Aug 11, 2020 at 6:43 PM Guenter Roeck wrote: > > On Tue, Aug 11, 2020 at 05:14:39PM -0700, Badhri Jagan Sridharan wrote: > > From the spec: > > "6.6.8.1 SwapSourceStartTimer > > The SwapSourceStartTimer Shall be used by the new Source, after a Power > > Role Swap or Fast Role Swap, to ensure that it does not send > > Source_Capabilities Message before the new Sink is ready to receive the > > Source_Capabilities Message. The new Source Shall Not send the > > Source_Capabilities Message earlier than tSwapSourceStart after the > > last bit of the EOP of GoodCRC Message sent in response to the PS_RDY > > Message sent by the new Source indicating that its power supply is > > ready." > > > > This fixes TD.PD.CP.E3, TD.PD.CP.E4, TD.PD.CP.E5 failures > > > > Signed-off-by: Badhri Jagan Sridharan > > Nit below, otherwise > > Reviewed-by: Guenter Roeck > > Note that I wasn't copied on this patch and only noticed it accidentally. Apologies Guenter ! Error on my side while performing the git send-email command. Will make sure that I double check next time. > > Guenter > > > --- > > Changes since V1: > > - Comment on the permissible values of tSwapSourceStart > > --- > > drivers/usb/typec/tcpm/tcpm.c | 2 +- > > include/linux/usb/pd.h| 1 + > > 2 files changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c > > index 3ef37202ee37..d38347bd3335 100644 > > --- a/drivers/usb/typec/tcpm/tcpm.c > > +++ b/drivers/usb/typec/tcpm/tcpm.c > > @@ -3555,7 +3555,7 @@ static void run_state_machine(struct tcpm_port *port) > >*/ > > tcpm_set_pwr_role(port, TYPEC_SOURCE); > > tcpm_pd_send_control(port, PD_CTRL_PS_RDY); > > - tcpm_set_state(port, SRC_STARTUP, 0); > > + tcpm_set_state(port, SRC_STARTUP, PD_T_SWAP_SRC_START); > > break; > > > > case VCONN_SWAP_ACCEPT: > > diff --git a/include/linux/usb/pd.h b/include/linux/usb/pd.h > > index b6c233e79bd4..ed5eed73ccf8 100644 > > --- a/include/linux/usb/pd.h > > +++ b/include/linux/usb/pd.h > > @@ -473,6 +473,7 @@ static inline unsigned int rdo_max_power(u32 rdo) > > #define PD_T_ERROR_RECOVERY 100 /* minimum 25 is insufficient */ > > #define PD_T_SRCSWAPSTDBY 625 /* Maximum of 650ms */ > > #define PD_T_NEWSRC250 /* Maximum of 275ms */ > > +#define PD_T_SWAP_SRC_START 20 /* Minimum of 20ms */ > > Odd alignment. Same as with the previous two lines which don't use tabs > either. > > > > > #define PD_T_DRP_TRY 100 /* 75 - 150 ms */ > > #define PD_T_DRP_TRYWAIT 600 /* 400 - 800 ms */
Re: [PATCH] erofs: avoid duplicated permission check for "trusted." xattrs
On 2020/8/11 15:00, Gao Xiang wrote:
Don't recheck it since xattr_permission() already
checks CAP_SYS_ADMIN capability.
Just follow 5d3ce4f70172 ("f2fs: avoid duplicated permission check for "trusted."
xattrs")
Reported-by: Hongyu Jin
[ Gao Xiang: since it could cause some complex Android overlay
permission issue as well on android-5.4+, so it'd be better to
backport to 5.4+ rather than pure cleanup on mainline. ]
Cc: # 5.4+
Signed-off-by: Gao Xiang
Reviewed-by: Chao Yu
Thanks,
Re: [RFC PATCH 00/16] Core scheduling v6
Hi Joel,
On 2020/8/10 0:44, Joel Fernandes wrote:
> Hi Aubrey,
>
> Apologies for replying late as I was still looking into the details.
>
> On Wed, Aug 05, 2020 at 11:57:20AM +0800, Li, Aubrey wrote:
> [...]
>> +/*
>> + * Core scheduling policy:
>> + * - CORE_SCHED_DISABLED: core scheduling is disabled.
>> + * - CORE_COOKIE_MATCH: tasks with same cookie can run
>> + * on the same core concurrently.
>> + * - CORE_COOKIE_TRUST: trusted task can run with kernel
>> thread on the same core concurrently.
>> + * - CORE_COOKIE_LONELY: tasks with cookie can run only
>> + * with idle thread on the same core.
>> + */
>> +enum coresched_policy {
>> + CORE_SCHED_DISABLED,
>> + CORE_SCHED_COOKIE_MATCH,
>> +CORE_SCHED_COOKIE_TRUST,
>> + CORE_SCHED_COOKIE_LONELY,
>> +};
>>
>> We can set policy to CORE_COOKIE_TRUST of uperf cgroup and fix this kind
>> of performance regression. Not sure if this sounds attractive?
>
> Instead of this, I think it can be something simpler IMHO:
>
> 1. Consider all cookie-0 task as trusted. (Even right now, if you apply the
>core-scheduling patchset, such tasks will share a core and sniff on each
>other. So let us not pretend that such tasks are not trusted).
>
> 2. All kernel threads and idle task would have a cookie 0 (so that will cover
>ksoftirqd reported in your original issue).
>
> 3. Add a config option (CONFIG_SCHED_CORE_DEFAULT_TASKS_UNTRUSTED). Default
>enable it. Setting this option would tag all tasks that are forked from a
>cookie-0 task with their own cookie. Later on, such tasks can be added to
>a group. This cover's PeterZ's ask about having 'default untrusted').
>(Users like ChromeOS that don't want to userspace system processes to be
>tagged can disable this option so such tasks will be cookie-0).
>
> 4. Allow prctl/cgroup interfaces to create groups of tasks and override the
>above behaviors.
How does uperf in a cgroup work with ksoftirqd? Are you suggesting I set uperf's
cookie to be cookie-0 via prctl?
Thanks,
-Aubrey
>
> 5. Document everything clearly so the semantics are clear both to the
>developers of core scheduling and to system administrators.
>
> Note that, with the concept of "system trusted cookie", we can also do
> optimizations like:
> 1. Disable STIBP when switching into trusted tasks.
> 2. Disable L1D flushing / verw stuff for L1TF/MDS issues, when switching into
>trusted tasks.
>
> At least #1 seems to be biting enabling HT on ChromeOS right now, and one
> other engineer requested I do something like #2 already.
>
> Once we get full-syscall isolation working, threads belonging to a process
> can also share a core so those can just share a core with the task-group
> leader.
>
>>> Is the uperf throughput worse with SMT+core-scheduling versus no-SMT ?
>>
>> This is a good question, from the data we measured by uperf,
>> SMT+core-scheduling is 28.2% worse than no-SMT, :(
>
> This is worrying for sure. :-(. We ought to debug/profile it more to see what
> is causing the overhead. Me/Vineeth added it as a topic for LPC as well.
>
> Any other thoughts from others on this?
>
> thanks,
>
> - Joel
>
>
>>> thanks,
>>>
>>> - Joel
>>> PS: I am planning to write a patch behind a CONFIG option that tags
>>> all processes (default untrusted) so everything gets a cookie which
>>> some folks said was how they wanted (have a whitelist instead of
>>> blacklist).
>>>
>>
RE: [PATCH RFC v2 00/18] Add VFIO mediated device support and DEV-MSI support for the idxd driver
> From: Alex Williamson > Sent: Wednesday, August 12, 2020 1:01 AM > > On Mon, 10 Aug 2020 07:32:24 + > "Tian, Kevin" wrote: > > > > From: Jason Gunthorpe > > > Sent: Friday, August 7, 2020 8:20 PM > > > > > > On Wed, Aug 05, 2020 at 07:22:58PM -0600, Alex Williamson wrote: > > > > > > > If you see this as an abuse of the framework, then let's identify those > > > > specific issues and come up with a better approach. As we've discussed > > > > before, things like basic PCI config space emulation are acceptable > > > > overhead and low risk (imo) and some degree of register emulation is > > > > well within the territory of an mdev driver. > > > > > > What troubles me is that idxd already has a direct userspace interface > > > to its HW, and does userspace DMA. The purpose of this mdev is to > > > provide a second direct userspace interface that is a little different > > > and trivially plugs into the virtualization stack. > > > > No. Userspace DMA and subdevice passthrough (what mdev provides) > > are two distinct usages IMO (at least in idxd context). and this might > > be the main divergence between us, thus let me put more words here. > > If we could reach consensus in this matter, which direction to go > > would be clearer. > > > > First, a passthrough interface requires some unique requirements > > which are not commonly observed in an userspace DMA interface, e.g.: > > > > - Tracking DMA dirty pages for live migration; > > - A set of interfaces for using SVA inside guest; > > * PASID allocation/free (on some platforms); > > * bind/unbind guest mm/page table (nested translation); > > * invalidate IOMMU cache/iotlb for guest page table changes; > > * report page request from device to guest; > > * forward page response from guest to device; > > - Configuring irqbypass for posted interrupt; > > - ... > > > > Second, a passthrough interface requires delegating raw controllability > > of subdevice to guest driver, while the same delegation might not be > > required for implementing an userspace DMA interface (especially for > > modern devices which support SVA). For example, idxd allows following > > setting per wq (guest driver may configure them in any combination): > > - put in dedicated or shared mode; > > - enable/disable SVA; > > - Associate guest-provided PASID to MSI/IMS entry; > > - set threshold; > > - allow/deny privileged access; > > - allocate/free interrupt handle (enlightened for guest); > > - collect error status; > > - ... > > > > We plan to support idxd userspace DMA with SVA. The driver just needs > > to prepare a wq with a predefined configuration (e.g. shared, SVA, > > etc.), bind the process mm to IOMMU (non-nested) and then map > > the portal to userspace. The goal that userspace can do DMA to > > associated wq doesn't change the fact that the wq is still *owned* > > and *controlled* by kernel driver. However as far as passthrough > > is concerned, the wq is considered 'owned' by the guest driver thus > > we need an interface which can support low-level *controllability* > > from guest driver. It is sort of a mess in uAPI when mixing the > > two together. > > > > Based on above two reasons, we see distinct requirements between > > userspace DMA and passthrough interfaces, at least in idxd context > > (though other devices may have less distinction in-between). Therefore, > > we didn't see the value/necessity of reinventing the wheel that mdev > > already handles well to evolve an simple application-oriented usespace > > DMA interface to a complex guest-driver-oriented passthrough interface. > > The complexity of doing so would incur far more kernel-side changes > > than the portion of emulation code that you've been concerned about... > > > > > > > > I don't think VFIO should be the only entry point to > > > virtualization. If we say the universe of devices doing user space DMA > > > must also implement a VFIO mdev to plug into virtualization then it > > > will be alot of mdevs. > > > > Certainly VFIO will not be the only entry point. and This has to be a > > case-by-case decision. If an userspace DMA interface can be easily > > adapted to be a passthrough one, it might be the choice. But for idxd, > > we see mdev a much better fit here, given the big difference between > > what userspace DMA requires and what guest driver requires in this hw. > > > > > > > > I would prefer to see that the existing userspace interface have the > > > extra needed bits for virtualization (eg by having appropriate > > > internal kernel APIs to make this easy) and all the emulation to build > > > the synthetic PCI device be done in userspace. > > > > In the end what decides the direction is the amount of changes that > > we have to put in kernel, not whether we call it 'emulation'. For idxd, > > adding special passthrough requirements (guest SVA, dirty tracking, > > etc.) and raw controllability to the simple userspace DMA interface > > is
Re: [PATCH] riscv: Setup exception vector for K210 properly
On Wed, Aug 12, 2020 at 12:16 AM Atish Patra wrote:
>
> On Tue, Aug 11, 2020 at 1:41 AM Anup Patel wrote:
> >
> > On Tue, Aug 11, 2020 at 12:07 PM Qiu Wenbo wrote:
> > >
> > > Exception vector is missing on nommu platform and it is a big issue.
> > > This patch is tested in Sipeed MAIX Bit Dev Board.
> > >
> > > Fixes: 79b1feba5455 ("RISC-V: Setup exception vector early")
> > > Signed-off-by: Qiu Wenbo
>
> Thanks for testing it on the kendryte board.
>
> > > ---
> > > arch/riscv/kernel/smpboot.c | 1 +
> > > arch/riscv/kernel/traps.c | 11 ++-
> > > 2 files changed, 11 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/riscv/kernel/smpboot.c b/arch/riscv/kernel/smpboot.c
> > > index 356825a57551..23cde0ceb39d 100644
> > > --- a/arch/riscv/kernel/smpboot.c
> > > +++ b/arch/riscv/kernel/smpboot.c
> > > @@ -154,6 +154,7 @@ asmlinkage __visible void smp_callin(void)
> > > mmgrab(mm);
> > > current->active_mm = mm;
> > >
> > > + trap_init();
> > > notify_cpu_starting(curr_cpuid);
> > > update_siblings_masks(curr_cpuid);
> > > set_cpu_online(curr_cpuid, 1);
> > > diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c
> > > index ad14f4466d92..a390239818ae 100644
> > > --- a/arch/riscv/kernel/traps.c
> > > +++ b/arch/riscv/kernel/traps.c
> > > @@ -174,7 +174,16 @@ int is_valid_bugaddr(unsigned long pc)
> > > }
> > > #endif /* CONFIG_GENERIC_BUG */
> > >
> > > -/* stvec & scratch is already set from head.S */
> > > +/* stvec & scratch is already set from head.S when mmu is enabled */
> > > void trap_init(void)
> > > {
> > > +#ifndef CONFIG_MMU
> > > + /*
> > > +* Set sup0 scratch register to 0, indicating to exception vector
> > > +* that we are presently executing in the kernel
> > > +*/
> > > + csr_write(CSR_SCRATCH, 0);
> > > + /* Set the exception vector address */
> > > + csr_write(CSR_TVEC, _exception);
> > > +#endif
> > > }
> > > --
> > > 2.28.0
> > >
> >
> > This issue seems to be only on the latest master branch of
> > Linux stable tree so this fix need not be a stable fix.
> >
> > For MMU kernel, the CSR_TVEC is setup in relocate() function
> > called from secondary_start_common() function of head.S
> >
> > For NoMMU kernel, we should set CSR_TVEC directly in
> > secondary_start_common() function as "#else" case of the
> > "#ifdef CONFIG_MMU".
> >
>
> That would enable the trap only for secondary harts. But the exception
> vector on boot hart
> is still uninitialized. How about this change ?
>
> diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S
> index d0c5c316e9bb..7822054dbd88 100644
> --- a/arch/riscv/kernel/head.S
> +++ b/arch/riscv/kernel/head.S
> @@ -77,16 +77,6 @@ relocate:
> csrw CSR_SATP, a0
> .align 2
> 1:
> - /* Set trap vector to exception handler */
> - la a0, handle_exception
> - csrw CSR_TVEC, a0
> -
> - /*
> -* Set sup0 scratch register to 0, indicating to exception vector that
> -* we are presently executing in kernel.
> -*/
> - csrw CSR_SCRATCH, zero
> -
Instead of having no trap vector setup here, we should
at least have dummy trap vector (just like original code).
/* Set trap vector to spin forever to help debug */
la a0, .Lsecondary_park
csrw CSR_TVEC, a0
> /* Reload the global pointer */
> .option push
> .option norelax
> @@ -144,9 +134,23 @@ secondary_start_common:
> la a0, swapper_pg_dir
> call relocate
> #endif
> + call setup_trap_vector
> tail smp_callin
> #endif /* CONFIG_SMP */
>
> +.align 2
> +setup_trap_vector:
> + /* Set trap vector to exception handler */
> + la a0, handle_exception
> + csrw CSR_TVEC, a0
> +
> + /*
> +* Set sup0 scratch register to 0, indicating to exception vector that
> +* we are presently executing in kernel.
> +*/
> + csrw CSR_SCRATCH, zero
> + ret
> +
> .Lsecondary_park:
> /* We lack SMP support or have too many harts, so park this hart */
> wfi
> @@ -240,6 +244,7 @@ clear_bss_done:
> call relocate
> #endif /* CONFIG_MMU */
>
> + call setup_trap_vector
> /* Restore C environment */
> la tp, init_task
> sw zero, TASK_TI_CPU(tp)
Apart from above, this looks good.
Regards,
Anup
Re: [PATCH v3 02/18] gpio: uapi: define uAPI v2
On Tue, Aug 11, 2020 at 09:11:41PM +0200, Bartosz Golaszewski wrote: > On Sun, Aug 9, 2020 at 3:26 PM Kent Gibson wrote: > > [snip] > > > > +/* > > + * Maximum number of requested lines. > > + * > > + * Must be no greater than 64 as bitmaps are limited to 64-bits, and a > > + * multiple of 2 to ensure 32/64-bit alignment of structs. > > + */ > > +#define GPIO_V2_LINES_MAX 64 > > + > > If we refer to bitmaps for which helpers are defined in > include/linux/bitmap.h then they're not limited to 64-bits. I'd just > say here that we want to fit into 64-bit integers for simplicity. > Strictly speaking, userspace doesn't know about include/linux/bitmap.h, but I'm happy to remove any ambiguity. Does this work for you?: * Must be no greater than 64, as bitmaps are restricted here to 64-bits * for simplicity, and a multiple of 2 to ensure 32/64-bit alignment of * structs. Cheers, Kent.
Re: [f2fs-dev] [PATCH] f2fs: change virtual mapping way for compression pages
On 2020/8/11 19:31, Daeho Jeong wrote: Plus, differently from your testbed, in my pixel device, there seems to be much more contention in vmap() operation. If it's not there, I agree that there might not be a big difference between vmap() and vm_map_ram(). 2020년 8월 11일 (화) 오후 8:29, Gao Xiang 님이 작성: On Tue, Aug 11, 2020 at 08:21:23PM +0900, Daeho Jeong wrote: Sure, I'll update the test condition as you said in the commit message. FYI, the test is done with 16kb chunk and Pixel 3 (arm64) device. Yeah, anyway, it'd better to lock the freq and offline the little cores in your test as well (it'd make more sense). e.g. if 16k cluster I'm not against this commit, but could you please try to adjust cpufreq to fixed value and offline little or big core, so that we can supply fair test environment during test, I just wonder that in such environment, how much we can improve the performance with vm_map_ram(). is applied, even all data is zeroed, the count of vmap/vm_map_ram isn't hugeous (and as you said, "sometimes, it has a very long delay", it's much like another scheduling concern as well). Anyway, I'm not against your commit but the commit message is a bit of unclear. At least, if you think that is really the case, I'm ok with that. Thanks, Gao Xiang Thanks, 2020ë…„ 8ì›” 11ì�¼ (í™”) 오후 7:18, Gao Xiang 님ì�´ 작성: On Tue, Aug 11, 2020 at 06:33:26PM +0900, Daeho Jeong wrote: Plus, when we use vmap(), vmap() normally executes in a short time like vm_map_ram(). But, sometimes, it has a very long delay. 2020ë…„ 8ì›â€� 11� (Ãâ„¢â€�) 오Û„ 6:28, Daeho Jeong 님� 작성: Actually, as you can see, I use the whole zero data blocks in the test file. It can maximize the effect of changing virtual mapping. When I use normal files which can be compressed about 70% from the original file, The vm_map_ram() version is about 2x faster than vmap() version. What f2fs does is much similar to btrfs compression. Even if these blocks are all zeroed. In principle, the maximum compression ratio is determined (cluster sized blocks into one compressed block, e.g 16k cluster into one compressed block). So it'd be better to describe your configured cluster size (16k or 128k) and your hardware information in the commit message as well. Actually, I also tried with this patch as well on my x86 laptop just now with FIO (I didn't use zeroed block though), and I didn't notice much difference with turbo boost off and maxfreq. I'm not arguing this commit, just a note about this commit message. 1048576000 bytes (0.9 G) copied, 9.146217 s, 109 M/s 1048576000 bytes (0.9 G) copied, 9.997542 s, 100 M/s 1048576000 bytes (0.9 G) copied, 10.109727 s, 99 M/s IMHO, the above number is much like decompressing in the arm64 little cores. Thanks, Gao Xiang 2020ë…„ 8ì›â€� 11� (Ãâ„¢â€�) 오Û„ 4:55, Chao Yu 님� 작성: On 2020/8/11 15:15, Gao Xiang wrote: On Tue, Aug 11, 2020 at 12:37:53PM +0900, Daeho Jeong wrote: From: Daeho Jeong By profiling f2fs compression works, I've found vmap() callings are bottlenecks of f2fs decompression path. Changing these with vm_map_ram(), we can enhance f2fs decompression speed pretty much. [Verification] dd if=/dev/zero of=dummy bs=1m count=1000 echo 3 > /proc/sys/vm/drop_caches dd if=dummy of=/dev/zero bs=512k - w/o compression - 1048576000 bytes (0.9 G) copied, 1.999384 s, 500 M/s 1048576000 bytes (0.9 G) copied, 2.035988 s, 491 M/s 1048576000 bytes (0.9 G) copied, 2.039457 s, 490 M/s - before patch - 1048576000 bytes (0.9 G) copied, 9.146217 s, 109 M/s 1048576000 bytes (0.9 G) copied, 9.997542 s, 100 M/s 1048576000 bytes (0.9 G) copied, 10.109727 s, 99 M/s - after patch - 1048576000 bytes (0.9 G) copied, 2.253441 s, 444 M/s 1048576000 bytes (0.9 G) copied, 2.739764 s, 365 M/s 1048576000 bytes (0.9 G) copied, 2.185649 s, 458 M/s Indeed, vmap() approach has some impact on the whole workflow. But I don't think the gap is such significant, maybe it relates to unlocked cpufreq (and big little core difference if it's on some arm64 board). Agreed, I guess there should be other reason causing the large performance gap, scheduling, frequency, or something else. ___ Linux-f2fs-devel mailing list linux-f2fs-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel . .
arch/sparc/include/asm/cmpxchg_64.h:161:55: sparse: sparse: cast truncates bits from constant value (ffffffffe0f510cc becomes cc)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: fb893de323e2d39f7a1f6df425703a2edbdf56ea
commit: 47e4937a4a7ca4184fd282791dfee76c6799966a erofs: move erofs out of
staging
date: 12 months ago
config: sparc64-randconfig-s032-20200812 (attached as .config)
compiler: sparc64-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-168-g9554805c-dirty
git checkout 47e4937a4a7ca4184fd282791dfee76c6799966a
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=sparc64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
fs/erofs/utils.c: note: in included file (through
arch/sparc/include/asm/cmpxchg.h, arch/sparc/include/asm/atomic_64.h,
arch/sparc/include/asm/atomic.h, ...):
>> arch/sparc/include/asm/cmpxchg_64.h:161:55: sparse: sparse: cast truncates
>> bits from constant value (e0f510cc becomes cc)
--
fs/erofs/zdata.c: note: in included file (through
arch/sparc/include/asm/cmpxchg.h, arch/sparc/include/asm/atomic_64.h,
arch/sparc/include/asm/atomic.h, ...):
>> arch/sparc/include/asm/cmpxchg_64.h:161:55: sparse: sparse: cast truncates
>> bits from constant value (e0f510cc becomes cc)
arch/sparc/include/asm/cmpxchg_64.h:161:50: sparse: sparse: cast truncates
bits from constant value (5f0ecafe becomes fe)
arch/sparc/include/asm/cmpxchg_64.h:161:50: sparse: sparse: cast truncates
bits from constant value (5f0ecafe becomes fe)
arch/sparc/include/asm/cmpxchg_64.h:161:55: sparse: sparse: cast truncates
bits from constant value (5f0edead becomes ad)
vim +161 arch/sparc/include/asm/cmpxchg_64.h
d550bbd40c0e10 David Howells 2012-03-28 155
d550bbd40c0e10 David Howells 2012-03-28 156 static inline unsigned long
d550bbd40c0e10 David Howells 2012-03-28 157 __cmpxchg(volatile void *ptr,
unsigned long old, unsigned long new, int size)
d550bbd40c0e10 David Howells 2012-03-28 158 {
d550bbd40c0e10 David Howells 2012-03-28 159switch (size) {
a12ee2349312d7 Babu Moger2017-05-24 160case 1:
a12ee2349312d7 Babu Moger2017-05-24 @161return
__cmpxchg_u8(ptr, old, new);
d550bbd40c0e10 David Howells 2012-03-28 162case 4:
d550bbd40c0e10 David Howells 2012-03-28 163return
__cmpxchg_u32(ptr, old, new);
d550bbd40c0e10 David Howells 2012-03-28 164case 8:
d550bbd40c0e10 David Howells 2012-03-28 165return
__cmpxchg_u64(ptr, old, new);
d550bbd40c0e10 David Howells 2012-03-28 166}
d550bbd40c0e10 David Howells 2012-03-28 167
__cmpxchg_called_with_bad_pointer();
d550bbd40c0e10 David Howells 2012-03-28 168return old;
d550bbd40c0e10 David Howells 2012-03-28 169 }
d550bbd40c0e10 David Howells 2012-03-28 170
:: The code at line 161 was first introduced by commit
:: a12ee2349312d7112b9b7c6ac2e70c5ec2ca334e arch/sparc: Introduce
cmpxchg_u8 SPARC
:: TO: Babu Moger
:: CC: David S. Miller
---
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] sched/core: add unlikely in group_has_capacity()
On 2020/8/7 上午10:47, Qi Zheng wrote: Yeah, because of the following two points, I also think the probability is 0%: a) the sd is protected by rcu lock, and load_balance() func is between rcu_read_lock() and rcu_read_unlock(). b) the sgs is a local variable. So in the group_classify(), the env->sd->imbalance_pct and the sgs will not be changed. May I remove the duplicate check from group_has_capacity() and resubmit a patch? Yours, Qi Zheng On 2020/8/6 下午10:45, Ingo Molnar wrote: * Qi Zheng wrote: 1. The group_has_capacity() function is only called in group_classify(). 2. Before calling the group_has_capacity() function, group_is_overloaded() will first judge the following formula, if it holds, the group_classify() will directly return the group_overloaded. (sgs->group_capacity * imbalance_pct) < (sgs->group_runnable * 100) Therefore, when the group_has_capacity() is called, the probability that the above formalu holds is very small. Hint compilers about that. Signed-off-by: Qi Zheng --- kernel/sched/fair.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 2ba8f230feb9..9074fd5e23b2 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -8234,8 +8234,8 @@ group_has_capacity(unsigned int imbalance_pct, struct sg_lb_stats *sgs) if (sgs->sum_nr_running < sgs->group_weight) return true; - if ((sgs->group_capacity * imbalance_pct) < - (sgs->group_runnable * 100)) + if (unlikely((sgs->group_capacity * imbalance_pct) < + (sgs->group_runnable * 100))) return false; Isn't the probability that this second check will match around 0%? I.e. wouldn't the right fix be to remove the duplicate check from group_has_capacity(), because it's already been checked in group_classify()? Maybe while leaving a comment in place? Thanks, Ingo Hi, As Valentin and I discussed in the patch below, simply removing the check may not be completely harmless. [PATCH]sched/fair: Remove the duplicate check from group_has_capacity() : - if ((sgs->group_capacity * imbalance_pct) < - (sgs->group_runnable * 100)) - return false; If sum_nr_running < group_weight, we won't evaluate it. If sum_nr_running > group_weight, we either won't call into group_has_capacity() or we'll have checked it already in group_overloaded(). But in the case of sum_nr_running == group_weight, we can run to this check. Although I also think it is unlikely to cause the significant capacity pressure at the == case, but I'm not sure whether there are some special scenarios. such as some cpus in sg->cpumask are no longer active, or other scenarios? So adding the unlikely() in group_has_capacity() may be the safest way. Add Valentin Schneider . Yours, Qi Zheng
Re: [PATCH v1] usb: typec: tcpm: Fix TDA 2.2.1.1 and TDA 2.2.1.2 failures
On 8/11/20 6:08 PM, Badhri Jagan Sridharan wrote: > Yes I did ! https://lkml.org/lkml/2020/8/11/788 ! > > For me gmail is grouping V1 and V2 patches in the same thread so > thought you saw the v2 patch :P > You copied me on v1, but not on v2. I am not on any of the mailing lists you sent v2 to, so I did not see it. Guenter > Thanks, > Badhri > > On Tue, Aug 11, 2020 at 5:36 PM Guenter Roeck wrote: >> >> On 8/11/20 4:21 PM, Badhri Jagan Sridharan wrote: >>> Thanks Guenter ! However I don't see a reviewed-by tag :) >>> >> >> Confused. Did you send a v2 with the changes we discussed ? >> I didn't see that. >> >> Thanks, >> Guenter >> >>> On Tue, Aug 11, 2020 at 1:18 PM Guenter Roeck wrote: On 8/11/20 12:39 PM, Badhri Jagan Sridharan wrote: > On Tue, Aug 11, 2020 at 11:45 AM Guenter Roeck wrote: >> >> On Tue, Aug 11, 2020 at 11:24:07AM -0700, Badhri Jagan Sridharan wrote: >>> On Mon, Aug 10, 2020 at 6:51 PM Guenter Roeck >>> wrote: On 8/10/20 6:11 PM, Badhri Jagan Sridharan wrote: > >From the spec: > "7.1.5 Response to Hard Resets > Hard Reset Signaling indicates a communication failure has occurred > and > the Source Shall stop driving VCONN, Shall remove Rp from the VCONN > pin > and Shall drive VBUS to vSafe0V as shown in Figure 7-9. The USB > connection > May reset during a Hard Reset since the VBUS voltage will be less than > vSafe5V for an extended period of time. After establishing the vSafe0V > voltage condition on VBUS, the Source Shall wait tSrcRecover before > re-applying VCONN and restoring VBUS to vSafe5V. A Source Shall > conform > to the VCONN timing as specified in [USB Type-C 1.3]." > > Signed-off-by: Badhri Jagan Sridharan > --- > drivers/usb/typec/tcpm/tcpm.c | 16 +--- > 1 file changed, 13 insertions(+), 3 deletions(-) > > diff --git a/drivers/usb/typec/tcpm/tcpm.c > b/drivers/usb/typec/tcpm/tcpm.c > index 3ef37202ee37..e41c4e5d3c71 100644 > --- a/drivers/usb/typec/tcpm/tcpm.c > +++ b/drivers/usb/typec/tcpm/tcpm.c > @@ -3372,13 +3372,19 @@ static void run_state_machine(struct > tcpm_port *port) > tcpm_set_state(port, SNK_HARD_RESET_SINK_OFF, > 0); > break; > case SRC_HARD_RESET_VBUS_OFF: > - tcpm_set_vconn(port, true); > + /* > + * 7.1.5 Response to Hard Resets > + * Hard Reset Signaling indicates a communication > failure has occurred and the > + * Source Shall stop driving VCONN, Shall remove Rp > from the VCONN pin and Shall > + * drive VBUS to vSafe0V as shown in Figure 7-9. > + */ > + tcpm_set_vconn(port, false); > tcpm_set_vbus(port, false); > tcpm_set_roles(port, port->self_powered, TYPEC_SOURCE, > tcpm_data_role_for_source(port)); > - tcpm_set_state(port, SRC_HARD_RESET_VBUS_ON, > PD_T_SRC_RECOVER); I am a bit concerned about this. If I understand correctly, it means that we won't turn VBUS back on unless a SRC_HARD_RESET_VBUS_OFF PD event is received. Is that correct ? What happens if that event is never received ? Thanks, Guenter >>> >>> The term PD event is a little ambiguous to me. Trying to summarize the >>> workflow. >>> Lower level tcpc driver would have to call tcpm_vbus_change which >>> would in-turn trigger TCPM_VBUS_EVENT >>> and queries port->tcpc->get_vbus to get the vbus status. It is not >>> really a PD protocol driven event hence the >>> confusion. >>> >>> "What happens if that event is never received ?" >>> Yeah TCPM would be in SRC_HARD_RESET_VBUS_OFF till the tcpc calls the >>> tcpm_vbus_change. >>> Do you suspect that existing tcpc would not have the capability to >>> monitor vbus status while sourcing and call tcpm_vbus_change? >>> >> That, or the driver might be buggy, or the hardware does't signal a >> status >> update, or the update gets lost. I think we should have some backup, >> to trigger if the event is not received in a reasonable amout of time. >> I don't know if the specification has some kind of maximum limit. If >> not, we should still have something >> >> Thanks, >> Guenter > > Got it ! The specification actually has a bound for vbus off. > tSafe0V - Time to reach vSafe0V max - 650ms. (PD_T_SAFE_0V). > So I will bound it to that. > Excellent. Thanks a lot for looking into this!
Re: [PATCH v7] Add a "nosymfollow" mount option.
On 2020-08-11, Ross Zwisler wrote:
> From: Mattias Nissler
>
> For mounts that have the new "nosymfollow" option, don't follow symlinks
> when resolving paths. The new option is similar in spirit to the
> existing "nodev", "noexec", and "nosuid" options, as well as to the
> LOOKUP_NO_SYMLINKS resolve flag in the openat2(2) syscall. Various BSD
> variants have been supporting the "nosymfollow" mount option for a long
> time with equivalent implementations.
>
> Note that symlinks may still be created on file systems mounted with
> the "nosymfollow" option present. readlink() remains functional, so
> user space code that is aware of symlinks can still choose to follow
> them explicitly.
>
> Setting the "nosymfollow" mount option helps prevent privileged
> writers from modifying files unintentionally in case there is an
> unexpected link along the accessed path. The "nosymfollow" option is
> thus useful as a defensive measure for systems that need to deal with
> untrusted file systems in privileged contexts.
>
> More information on the history and motivation for this patch can be
> found here:
>
> https://sites.google.com/a/chromium.org/dev/chromium-os/chromiumos-design-docs/hardening-against-malicious-stateful-data#TOC-Restricting-symlink-traversal
Looks good. Did you plan to add an in-tree test for this (you could
shove it in tools/testing/selftests/mount)?
Reviewed-by: Aleksa Sarai
> Signed-off-by: Mattias Nissler
> Signed-off-by: Ross Zwisler
> ---
> Changes since v6 [1]:
> * Rebased onto v5.8.
> * Another round of testing including readlink(1), readlink(2),
>realpath(1), realpath(3), statfs(2) and mount(2) to make sure
>everything still works.
>
> After this lands I will upstream changes to util-linux[2] and man-pages
> [3].
>
> [1]: https://lkml.org/lkml/2020/3/4/770
> [2]:
> https://github.com/rzwisler/util-linux/commit/7f8771acd85edb70d97921c026c55e1e724d4e15
> [3]:
> https://github.com/rzwisler/man-pages/commit/b8fe8079f64b5068940c0144586e580399a71668
> ---
> fs/namei.c | 3 ++-
> fs/namespace.c | 2 ++
> fs/proc_namespace.c| 1 +
> fs/statfs.c| 2 ++
> include/linux/mount.h | 3 ++-
> include/linux/statfs.h | 1 +
> include/uapi/linux/mount.h | 1 +
> 7 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/fs/namei.c b/fs/namei.c
> index 72d4219c93acb..ed68478fb1fb6 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -1626,7 +1626,8 @@ static const char *pick_link(struct nameidata *nd,
> struct path *link,
> return ERR_PTR(error);
> }
>
> - if (unlikely(nd->flags & LOOKUP_NO_SYMLINKS))
> + if (unlikely(nd->flags & LOOKUP_NO_SYMLINKS) ||
> + unlikely(nd->path.mnt->mnt_flags & MNT_NOSYMFOLLOW))
> return ERR_PTR(-ELOOP);
>
> if (!(nd->flags & LOOKUP_RCU)) {
> diff --git a/fs/namespace.c b/fs/namespace.c
> index 4a0f600a33285..1cbbf5a9b954f 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -3167,6 +3167,8 @@ long do_mount(const char *dev_name, const char __user
> *dir_name,
> mnt_flags &= ~(MNT_RELATIME | MNT_NOATIME);
> if (flags & MS_RDONLY)
> mnt_flags |= MNT_READONLY;
> + if (flags & MS_NOSYMFOLLOW)
> + mnt_flags |= MNT_NOSYMFOLLOW;
>
> /* The default atime for remount is preservation */
> if ((flags & MS_REMOUNT) &&
> diff --git a/fs/proc_namespace.c b/fs/proc_namespace.c
> index 3059a9394c2d6..e59d4bb3a89e4 100644
> --- a/fs/proc_namespace.c
> +++ b/fs/proc_namespace.c
> @@ -70,6 +70,7 @@ static void show_mnt_opts(struct seq_file *m, struct
> vfsmount *mnt)
> { MNT_NOATIME, ",noatime" },
> { MNT_NODIRATIME, ",nodiratime" },
> { MNT_RELATIME, ",relatime" },
> + { MNT_NOSYMFOLLOW, ",nosymfollow" },
> { 0, NULL }
> };
> const struct proc_fs_opts *fs_infop;
> diff --git a/fs/statfs.c b/fs/statfs.c
> index 2616424012ea7..59f33752c1311 100644
> --- a/fs/statfs.c
> +++ b/fs/statfs.c
> @@ -29,6 +29,8 @@ static int flags_by_mnt(int mnt_flags)
> flags |= ST_NODIRATIME;
> if (mnt_flags & MNT_RELATIME)
> flags |= ST_RELATIME;
> + if (mnt_flags & MNT_NOSYMFOLLOW)
> + flags |= ST_NOSYMFOLLOW;
> return flags;
> }
>
> diff --git a/include/linux/mount.h b/include/linux/mount.h
> index de657bd211fa6..aaf343b38671c 100644
> --- a/include/linux/mount.h
> +++ b/include/linux/mount.h
> @@ -30,6 +30,7 @@ struct fs_context;
> #define MNT_NODIRATIME 0x10
> #define MNT_RELATIME 0x20
> #define MNT_READONLY 0x40/* does the user want this to be r/o? */
> +#define MNT_NOSYMFOLLOW 0x80
>
> #define MNT_SHRINKABLE 0x100
> #define MNT_WRITE_HOLD 0x200
> @@ -46,7 +47,7 @@ struct fs_context;
> #define MNT_SHARED_MASK (MNT_UNBINDABLE)
> #define MNT_USER_SETTABLE_MASK (MNT_NOSUID | MNT_NODEV | MNT_NOEXEC \
>
Re: [PATCH v2] tcpm: During PR_SWAP, source caps should be sent only after tSwapSourceStart
On Tue, Aug 11, 2020 at 05:14:39PM -0700, Badhri Jagan Sridharan wrote: > From the spec: > "6.6.8.1 SwapSourceStartTimer > The SwapSourceStartTimer Shall be used by the new Source, after a Power > Role Swap or Fast Role Swap, to ensure that it does not send > Source_Capabilities Message before the new Sink is ready to receive the > Source_Capabilities Message. The new Source Shall Not send the > Source_Capabilities Message earlier than tSwapSourceStart after the > last bit of the EOP of GoodCRC Message sent in response to the PS_RDY > Message sent by the new Source indicating that its power supply is > ready." > > This fixes TD.PD.CP.E3, TD.PD.CP.E4, TD.PD.CP.E5 failures > > Signed-off-by: Badhri Jagan Sridharan Nit below, otherwise Reviewed-by: Guenter Roeck Note that I wasn't copied on this patch and only noticed it accidentally. Guenter > --- > Changes since V1: > - Comment on the permissible values of tSwapSourceStart > --- > drivers/usb/typec/tcpm/tcpm.c | 2 +- > include/linux/usb/pd.h| 1 + > 2 files changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c > index 3ef37202ee37..d38347bd3335 100644 > --- a/drivers/usb/typec/tcpm/tcpm.c > +++ b/drivers/usb/typec/tcpm/tcpm.c > @@ -3555,7 +3555,7 @@ static void run_state_machine(struct tcpm_port *port) >*/ > tcpm_set_pwr_role(port, TYPEC_SOURCE); > tcpm_pd_send_control(port, PD_CTRL_PS_RDY); > - tcpm_set_state(port, SRC_STARTUP, 0); > + tcpm_set_state(port, SRC_STARTUP, PD_T_SWAP_SRC_START); > break; > > case VCONN_SWAP_ACCEPT: > diff --git a/include/linux/usb/pd.h b/include/linux/usb/pd.h > index b6c233e79bd4..ed5eed73ccf8 100644 > --- a/include/linux/usb/pd.h > +++ b/include/linux/usb/pd.h > @@ -473,6 +473,7 @@ static inline unsigned int rdo_max_power(u32 rdo) > #define PD_T_ERROR_RECOVERY 100 /* minimum 25 is insufficient */ > #define PD_T_SRCSWAPSTDBY 625 /* Maximum of 650ms */ > #define PD_T_NEWSRC250 /* Maximum of 275ms */ > +#define PD_T_SWAP_SRC_START 20 /* Minimum of 20ms */ Odd alignment. Same as with the previous two lines which don't use tabs either. > > #define PD_T_DRP_TRY 100 /* 75 - 150 ms */ > #define PD_T_DRP_TRYWAIT 600 /* 400 - 800 ms */
Re: [PATCH v2] usb: typec: tcpm: Fix TDA 2.2.1.1 and TDA 2.2.1.2 failures
On Tue, Aug 11, 2020 at 01:02:28PM -0700, Badhri Jagan Sridharan wrote: > From the spec: > "7.1.5 Response to Hard Resets > Hard Reset Signaling indicates a communication failure has occurred and > the Source Shall stop driving VCONN, Shall remove Rp from the VCONN pin > and Shall drive VBUS to vSafe0V as shown in Figure 7-9. The USB connection > May reset during a Hard Reset since the VBUS voltage will be less than > vSafe5V for an extended period of time. After establishing the vSafe0V > voltage condition on VBUS, the Source Shall wait tSrcRecover before > re-applying VCONN and restoring VBUS to vSafe5V. A Source Shall conform > to the VCONN timing as specified in [USB Type-C 1.3]." > > Signed-off-by: Badhri Jagan Sridharan Reviewed-by: Guenter Roeck Guenter > --- > Changes since V1 (Guenter's suggestion): > - Bound SRC_HARD_RESET_VBUS_ON to accommodate tcpc drivers which doesn't > update the vbus status. > --- > drivers/usb/typec/tcpm/tcpm.c | 28 +--- > 1 file changed, 25 insertions(+), 3 deletions(-) > > diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c > index 3ef37202ee37..a48e3f90d196 100644 > --- a/drivers/usb/typec/tcpm/tcpm.c > +++ b/drivers/usb/typec/tcpm/tcpm.c > @@ -3372,13 +3372,31 @@ static void run_state_machine(struct tcpm_port *port) > tcpm_set_state(port, SNK_HARD_RESET_SINK_OFF, 0); > break; > case SRC_HARD_RESET_VBUS_OFF: > - tcpm_set_vconn(port, true); > + /* > + * 7.1.5 Response to Hard Resets > + * Hard Reset Signaling indicates a communication failure has > occurred and the > + * Source Shall stop driving VCONN, Shall remove Rp from the > VCONN pin and Shall > + * drive VBUS to vSafe0V as shown in Figure 7-9. > + */ > + tcpm_set_vconn(port, false); > tcpm_set_vbus(port, false); > tcpm_set_roles(port, port->self_powered, TYPEC_SOURCE, > tcpm_data_role_for_source(port)); > - tcpm_set_state(port, SRC_HARD_RESET_VBUS_ON, PD_T_SRC_RECOVER); > + /* > + * If tcpc fails to notify vbus off, TCPM will wait for > PD_T_SAFE_0V + > + * PD_T_SRC_RECOVER before turning vbus back on. > + * From Table 7-12 Sequence Description for a Source Initiated > Hard Reset: > + * 4. Policy Engine waits tPSHardReset after sending Hard Reset > Signaling and then > + * tells the Device Policy Manager to instruct the power supply > to perform a > + * Hard Reset. The transition to vSafe0V Shall occur within > tSafe0V (t2). > + * 5. After tSrcRecover the Source applies power to VBUS in an > attempt to > + * re-establish communication with the Sink and resume USB > Default Operation. > + * The transition to vSafe5V Shall occur within tSrcTurnOn(t4). > + */ > + tcpm_set_state(port, SRC_HARD_RESET_VBUS_ON, PD_T_SAFE_0V + > PD_T_SRC_RECOVER); > break; > case SRC_HARD_RESET_VBUS_ON: > + tcpm_set_vconn(port, true); > tcpm_set_vbus(port, true); > port->tcpc->set_pd_rx(port->tcpc, true); > tcpm_set_attached_state(port, true); > @@ -3944,7 +3962,11 @@ static void _tcpm_pd_vbus_off(struct tcpm_port *port) > tcpm_set_state(port, SNK_HARD_RESET_WAIT_VBUS, 0); > break; > case SRC_HARD_RESET_VBUS_OFF: > - tcpm_set_state(port, SRC_HARD_RESET_VBUS_ON, 0); > + /* > + * After establishing the vSafe0V voltage condition on VBUS, > the Source Shall wait > + * tSrcRecover before re-applying VCONN and restoring VBUS to > vSafe5V. > + */ > + tcpm_set_state(port, SRC_HARD_RESET_VBUS_ON, PD_T_SRC_RECOVER); > break; > case HARD_RESET_SEND: > break;
Re: [RFC v2 03/11] tty: serial: qcom_geni_serial: Use OPP API to set clk/perf state
On Tue, Aug 11, 2020 at 4:11 PM John Stultz wrote: > > On Wed, Mar 20, 2019 at 2:49 AM Rajendra Nayak wrote: > > > > geni serial needs to express a perforamnce state requirement on CX > > depending on the frequency of the clock rates. Use OPP table from > > DT to register with OPP framework and use dev_pm_opp_set_rate() to > > set the clk/perf state. > > > > Signed-off-by: Rajendra Nayak > > Signed-off-by: Stephen Boyd > > --- > > drivers/tty/serial/qcom_geni_serial.c | 15 +-- > > 1 file changed, 13 insertions(+), 2 deletions(-) > > > > Hey, > I just wanted to follow up on this patch, as I've bisected it > (a5819b548af0) down as having broken qca bluetooth on the Dragonboard > 845c. > > I haven't yet had time to debug it yet, but wanted to raise the issue > in case anyone else has seen similar trouble. So I dug in a bit further, and this chunk seems to be causing the issue: > @@ -961,7 +963,7 @@ static void qcom_geni_serial_set_termios(struct uart_port > *uport, > goto out_restart_rx; > > uport->uartclk = clk_rate; > - clk_set_rate(port->se.clk, clk_rate); > + dev_pm_opp_set_rate(port->dev, clk_rate); > ser_clk_cfg = SER_CLK_EN; > ser_clk_cfg |= clk_div << CLK_DIV_SHFT; > With that applied, I see the following errors in dmesg and bluetooth fails to function: [4.763467] qcom_geni_serial 898000.serial: dev_pm_opp_set_rate: failed to find OPP for freq 10240 (-34) [4.773493] qcom_geni_serial 898000.serial: dev_pm_opp_set_rate: failed to find OPP for freq 10240 (-34) With just that chunk reverted on linus/HEAD, bluetooth seems to work ok. thanks -john
[PATCH v2 3/7] regulator: push allocations in create_regulator() outside of lock
Move all allocations outside of the regulator_lock()ed section.
==
WARNING: possible circular locking dependency detected
5.7.13+ #535 Not tainted
--
f2fs_discard-179:7/702 is trying to acquire lock:
c0e5d920 (regulator_list_mutex){+.+.}-{3:3}, at:
regulator_lock_dependent+0x54/0x2c0
but task is already holding lock:
cb95b080 (>cmd_lock){+.+.}-{3:3}, at: __issue_discard_cmd+0xec/0x5f8
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
[...]
-> #3 (fs_reclaim){+.+.}-{0:0}:
fs_reclaim_acquire.part.11+0x40/0x50
fs_reclaim_acquire+0x24/0x28
__kmalloc_track_caller+0x54/0x218
kstrdup+0x40/0x5c
create_regulator+0xf4/0x368
regulator_resolve_supply+0x1a0/0x200
regulator_register+0x9c8/0x163c
[...]
other info that might help us debug this:
Chain exists of:
regulator_list_mutex --> _i->sentry_lock --> >cmd_lock
[...]
Cc: sta...@vger.kernel.org
Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
Signed-off-by: Michał Mirosław
---
drivers/regulator/core.c | 53 +---
1 file changed, 28 insertions(+), 25 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 3dd4d4914075..c95397798275 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1553,44 +1553,53 @@ static struct regulator *create_regulator(struct
regulator_dev *rdev,
const char *supply_name)
{
struct regulator *regulator;
- char buf[REG_STR_SIZE];
- int err, size;
+ int err;
+
+ if (dev) {
+ char buf[REG_STR_SIZE];
+ int size;
+
+ size = snprintf(buf, REG_STR_SIZE, "%s-%s",
+ dev->kobj.name, supply_name);
+ if (size >= REG_STR_SIZE)
+ return NULL;
+
+ supply_name = kstrdup(buf, GFP_KERNEL);
+ if (supply_name == NULL)
+ return NULL;
+ } else {
+ supply_name = kstrdup_const(supply_name, GFP_KERNEL);
+ if (supply_name == NULL)
+ return NULL;
+ }
regulator = kzalloc(sizeof(*regulator), GFP_KERNEL);
- if (regulator == NULL)
+ if (regulator == NULL) {
+ kfree(supply_name);
return NULL;
+ }
- regulator_lock(rdev);
regulator->rdev = rdev;
+ regulator->supply_name = supply_name;
+
+ regulator_lock(rdev);
list_add(>list, >consumer_list);
+ regulator_unlock(rdev);
if (dev) {
regulator->dev = dev;
/* Add a link to the device sysfs entry */
- size = snprintf(buf, REG_STR_SIZE, "%s-%s",
- dev->kobj.name, supply_name);
- if (size >= REG_STR_SIZE)
- goto overflow_err;
-
- regulator->supply_name = kstrdup(buf, GFP_KERNEL);
- if (regulator->supply_name == NULL)
- goto overflow_err;
-
err = sysfs_create_link_nowarn(>dev.kobj, >kobj,
- buf);
+ supply_name);
if (err) {
rdev_dbg(rdev, "could not add device link %s err %d\n",
dev->kobj.name, err);
/* non-fatal */
}
- } else {
- regulator->supply_name = kstrdup_const(supply_name, GFP_KERNEL);
- if (regulator->supply_name == NULL)
- goto overflow_err;
}
- regulator->debugfs = debugfs_create_dir(regulator->supply_name,
+ regulator->debugfs = debugfs_create_dir(supply_name,
rdev->debugfs);
if (!regulator->debugfs) {
rdev_dbg(rdev, "Failed to create debugfs directory\n");
@@ -1615,13 +1624,7 @@ static struct regulator *create_regulator(struct
regulator_dev *rdev,
_regulator_is_enabled(rdev))
regulator->always_on = true;
- regulator_unlock(rdev);
return regulator;
-overflow_err:
- list_del(>list);
- kfree(regulator);
- regulator_unlock(rdev);
- return NULL;
}
static int _regulator_get_enable_time(struct regulator_dev *rdev)
--
2.20.1
[PATCH v2 6/7] regulator: cleanup regulator_ena_gpio_free()
Since only regulator_ena_gpio_request() allocates rdev->ena_pin, and it
guarantees that same gpiod gets same pin structure, it is enough to
compare just the pointers. Also we know there can be only one matching
entry on the list. Rework the code take advantage of the facts.
Signed-off-by: Michał Mirosław
---
drivers/regulator/core.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 448a267641df..bfd4114d6654 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2260,19 +2260,19 @@ static void regulator_ena_gpio_free(struct
regulator_dev *rdev)
/* Free the GPIO only in case of no use */
list_for_each_entry_safe(pin, n, _ena_gpio_list, list) {
- if (pin->gpiod == rdev->ena_pin->gpiod) {
- if (pin->request_count <= 1) {
- pin->request_count = 0;
- gpiod_put(pin->gpiod);
- list_del(>list);
- kfree(pin);
- rdev->ena_pin = NULL;
- return;
- } else {
- pin->request_count--;
- }
- }
+ if (pin != rdev->ena_pin)
+ continue;
+
+ if (--pin->request_count)
+ break;
+
+ gpiod_put(pin->gpiod);
+ list_del(>list);
+ kfree(pin);
+ break;
}
+
+ rdev->ena_pin = NULL;
}
/**
--
2.20.1
[PATCH v2 2/7] regulator: push allocation in regulator_ena_gpio_request() out of lock
Move another allocation out of regulator_list_mutex-protected region, as
reclaim might want to take the same lock.
WARNING: possible circular locking dependency detected
5.7.13+ #534 Not tainted
--
kswapd0/383 is trying to acquire lock:
c0e5d920 (regulator_list_mutex){+.+.}-{3:3}, at:
regulator_lock_dependent+0x54/0x2c0
but task is already holding lock:
c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (fs_reclaim){+.+.}-{0:0}:
fs_reclaim_acquire.part.11+0x40/0x50
fs_reclaim_acquire+0x24/0x28
kmem_cache_alloc_trace+0x40/0x1e8
regulator_register+0x384/0x1630
devm_regulator_register+0x50/0x84
reg_fixed_voltage_probe+0x248/0x35c
[...]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0CPU1
lock(fs_reclaim);
lock(regulator_list_mutex);
lock(fs_reclaim);
lock(regulator_list_mutex);
*** DEADLOCK ***
[...]
2 locks held by kswapd0/383:
#0: c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50
#1: cb70e5e0 (hctx->srcu){}-{0:0}, at: hctx_lock+0x60/0xb8
[...]
Fixes: 541d052d7215 ("regulator: core: Only support passing enable GPIO
descriptors")
[this commit only changes context]
Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
[this is when the regulator_list_mutex was introduced in reclaim locking path]
Signed-off-by: Michał Mirosław
---
drivers/regulator/core.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 510d234f6c46..3dd4d4914075 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2203,10 +2203,13 @@
EXPORT_SYMBOL_GPL(regulator_bulk_unregister_supply_alias);
static int regulator_ena_gpio_request(struct regulator_dev *rdev,
const struct regulator_config *config)
{
- struct regulator_enable_gpio *pin;
+ struct regulator_enable_gpio *pin, *new_pin;
struct gpio_desc *gpiod;
gpiod = config->ena_gpiod;
+ new_pin = kzalloc(sizeof(*new_pin), GFP_KERNEL);
+
+ mutex_lock(_list_mutex);
list_for_each_entry(pin, _ena_gpio_list, list) {
if (pin->gpiod == gpiod) {
@@ -2215,9 +2218,13 @@ static int regulator_ena_gpio_request(struct
regulator_dev *rdev,
}
}
- pin = kzalloc(sizeof(struct regulator_enable_gpio), GFP_KERNEL);
- if (pin == NULL)
+ if (new_pin == NULL) {
+ mutex_unlock(_list_mutex);
return -ENOMEM;
+ }
+
+ pin = new_pin;
+ new_pin = NULL;
pin->gpiod = gpiod;
list_add(>list, _ena_gpio_list);
@@ -2225,6 +2232,10 @@ static int regulator_ena_gpio_request(struct
regulator_dev *rdev,
update_ena_gpio_to_rdev:
pin->request_count++;
rdev->ena_pin = pin;
+
+ mutex_unlock(_list_mutex);
+ kfree(new_pin);
+
return 0;
}
@@ -5179,9 +5190,7 @@ regulator_register(const struct regulator_desc
*regulator_desc,
}
if (config->ena_gpiod) {
- mutex_lock(_list_mutex);
ret = regulator_ena_gpio_request(rdev, config);
- mutex_unlock(_list_mutex);
if (ret != 0) {
rdev_err(rdev, "Failed to request enable GPIO: %d\n",
ret);
--
2.20.1
[PATCH v2 4/7] regulator: push allocation in set_consumer_device_supply() out of lock
Pull regulator_list_mutex into set_consumer_device_supply() and keep
allocations outside of it. Fourth of the fs_reclaim deadlock case.
Cc: sta...@vger.kernel.org
Fixes: 45389c47526d ("regulator: core: Add early supply resolution for
regulators")
Signed-off-by: Michał Mirosław
---
v2: fix new node leak reported kernel test robot
---
drivers/regulator/core.c | 46 +++-
1 file changed, 26 insertions(+), 20 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index c95397798275..71749f48caee 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1434,7 +1434,7 @@ static int set_consumer_device_supply(struct
regulator_dev *rdev,
const char *consumer_dev_name,
const char *supply)
{
- struct regulator_map *node;
+ struct regulator_map *node, *new_node;
int has_dev;
if (supply == NULL)
@@ -1445,6 +1445,22 @@ static int set_consumer_device_supply(struct
regulator_dev *rdev,
else
has_dev = 0;
+ new_node = kzalloc(sizeof(struct regulator_map), GFP_KERNEL);
+ if (new_node == NULL)
+ return -ENOMEM;
+
+ new_node->regulator = rdev;
+ new_node->supply = supply;
+
+ if (has_dev) {
+ new_node->dev_name = kstrdup(consumer_dev_name, GFP_KERNEL);
+ if (new_node->dev_name == NULL) {
+ kfree(new_node);
+ return -ENOMEM;
+ }
+ }
+
+ mutex_lock(_list_mutex);
list_for_each_entry(node, _map_list, list) {
if (node->dev_name && consumer_dev_name) {
if (strcmp(node->dev_name, consumer_dev_name) != 0)
@@ -1462,26 +1478,19 @@ static int set_consumer_device_supply(struct
regulator_dev *rdev,
node->regulator->desc->name,
supply,
dev_name(>dev), rdev_get_name(rdev));
- return -EBUSY;
+ goto fail;
}
- node = kzalloc(sizeof(struct regulator_map), GFP_KERNEL);
- if (node == NULL)
- return -ENOMEM;
+ list_add(_node->list, _map_list);
+ mutex_unlock(_list_mutex);
- node->regulator = rdev;
- node->supply = supply;
-
- if (has_dev) {
- node->dev_name = kstrdup(consumer_dev_name, GFP_KERNEL);
- if (node->dev_name == NULL) {
- kfree(node);
- return -ENOMEM;
- }
- }
-
- list_add(>list, _map_list);
return 0;
+
+fail:
+ mutex_unlock(_list_mutex);
+ kfree(new_node->dev_name);
+ kfree(new_node);
+ return -EBUSY;
}
static void unset_regulator_supplies(struct regulator_dev *rdev)
@@ -5239,19 +5248,16 @@ regulator_register(const struct regulator_desc
*regulator_desc,
/* add consumers devices */
if (init_data) {
- mutex_lock(_list_mutex);
for (i = 0; i < init_data->num_consumer_supplies; i++) {
ret = set_consumer_device_supply(rdev,
init_data->consumer_supplies[i].dev_name,
init_data->consumer_supplies[i].supply);
if (ret < 0) {
- mutex_unlock(_list_mutex);
dev_err(dev, "Failed to set supply %s\n",
init_data->consumer_supplies[i].supply);
goto unset_supplies;
}
}
- mutex_unlock(_list_mutex);
}
if (!rdev->desc->ops->get_voltage &&
--
2.20.1
[PATCH v2 0/7] regulator: fix deadlock vs memory reclaim
For systems that have eg. eMMC storage using voltage regulator, memory reclaim path might call back into regulator subsystem. This means we have to make sure no allocations happen with a regulator or regulator list locked. After this series I see no more lockdep complaints on my test system, but please review and test further. First four patches move allocations out of locked regions, next three came as a drive-by cleanups. --- v2: fix bug in patch #4 spotted by kernel test robot reworded commit #7 description Michał Mirosław (7): regulator: push allocation in regulator_init_coupling() outside of lock regulator: push allocation in regulator_ena_gpio_request() out of lock regulator: push allocations in create_regulator() outside of lock regulator: push allocation in set_consumer_device_supply() out of lock regulator: plug of_node leak in regulator_register()'s error path regulator: cleanup regulator_ena_gpio_free() regulator: remove superfluous lock in regulator_resolve_coupling() drivers/regulator/core.c | 164 +-- 1 file changed, 87 insertions(+), 77 deletions(-) -- 2.20.1
[PATCH] MAINTAINERS: Add git tree for KVM/mips
There is no git tree for KVM/mips in MAINTAINERS, it is not convinent to rebase, add it. Signed-off-by: Tiezhu Yang --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index e627ed6..11c82c1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9546,6 +9546,7 @@ M:Aleksandar Markovic L: linux-m...@vger.kernel.org L: k...@vger.kernel.org S: Maintained +T: git git://git.kernel.org/pub/scm/virt/kvm/kvm.git F: arch/mips/include/asm/kvm* F: arch/mips/include/uapi/asm/kvm* F: arch/mips/kvm/ -- 2.1.0
[PATCH v2 7/7] regulator: remove superfluous lock in regulator_resolve_coupling()
The code modifies rdev, but locks c_rdev instead. Remove the lock
as this is held together by regulator_list_mutex taken in the caller.
Signed-off-by: Michał Mirosław
Reviewed-by: Dmitry Osipenko
Fixes: f9503385b187 ("regulator: core: Mutually resolve regulators coupling")
---
v2: reword commitmsg
---
drivers/regulator/core.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index bfd4114d6654..9ca89fee0d7e 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -4942,13 +4942,9 @@ static void regulator_resolve_coupling(struct
regulator_dev *rdev)
return;
}
- regulator_lock(c_rdev);
-
c_desc->coupled_rdevs[i] = c_rdev;
c_desc->n_resolved++;
- regulator_unlock(c_rdev);
-
regulator_resolve_coupling(c_rdev);
}
}
--
2.20.1
[PATCH v2 1/7] regulator: push allocation in regulator_init_coupling() outside of lock
Allocating memory with regulator_list_mutex held makes lockdep unhappy
when memory pressure makes the system do fs_reclaim on eg. eMMC using
a regulator. Push the lock inside regulator_init_coupling() after the
allocation.
==
WARNING: possible circular locking dependency detected
5.7.13+ #533 Not tainted
--
kswapd0/383 is trying to acquire lock:
cca78ca4 (>write_io[i][j].io_rwsem){}-{3:3}, at:
__submit_merged_write_cond+0x104/0x154
but task is already holding lock:
c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (fs_reclaim){+.+.}-{0:0}:
fs_reclaim_acquire.part.11+0x40/0x50
fs_reclaim_acquire+0x24/0x28
__kmalloc+0x54/0x218
regulator_register+0x860/0x1584
dummy_regulator_probe+0x60/0xa8
[...]
other info that might help us debug this:
Chain exists of:
>write_io[i][j].io_rwsem --> regulator_list_mutex --> fs_reclaim
Possible unsafe locking scenario:
CPU0CPU1
lock(fs_reclaim);
lock(regulator_list_mutex);
lock(fs_reclaim);
lock(>write_io[i][j].io_rwsem);
*** DEADLOCK ***
1 lock held by kswapd0/383:
#0: c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50
[...]
Cc: sta...@vger.kernel.org
Fixes: d8ca7d184b33 ("regulator: core: Introduce API for regulators coupling
customization")
Signed-off-by: Michał Mirosław
Reviewed-by: Dmitry Osipenko
---
drivers/regulator/core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 0a32c3da0e26..510d234f6c46 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -5010,7 +5010,10 @@ static int regulator_init_coupling(struct regulator_dev
*rdev)
if (!of_check_coupling_data(rdev))
return -EPERM;
+ mutex_lock(_list_mutex);
rdev->coupling_desc.coupler = regulator_find_coupler(rdev);
+ mutex_unlock(_list_mutex);
+
if (IS_ERR(rdev->coupling_desc.coupler)) {
err = PTR_ERR(rdev->coupling_desc.coupler);
rdev_err(rdev, "failed to get coupler: %d\n", err);
@@ -5218,9 +5221,7 @@ regulator_register(const struct regulator_desc
*regulator_desc,
if (ret < 0)
goto wash;
- mutex_lock(_list_mutex);
ret = regulator_init_coupling(rdev);
- mutex_unlock(_list_mutex);
if (ret < 0)
goto wash;
--
2.20.1
[PATCH v2 5/7] regulator: plug of_node leak in regulator_register()'s error path
By calling device_initialize() earlier and noting that kfree(NULL) is
ok, we can save a bit of code in error handling and plug of_node leak.
Fixed commit already did part of the work.
Cc: sta...@vger.kernel.org
Fixes: 9177514ce349 ("regulator: fix memory leak on error path of
regulator_register()")
Signed-off-by: Michał Mirosław
Acked-by: Vladimir Zapolskiy
---
drivers/regulator/core.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 71749f48caee..448a267641df 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -5137,6 +5137,7 @@ regulator_register(const struct regulator_desc
*regulator_desc,
ret = -ENOMEM;
goto rinse;
}
+ device_initialize(>dev);
/*
* Duplicate the config so the driver could override it after
@@ -5144,9 +5145,8 @@ regulator_register(const struct regulator_desc
*regulator_desc,
*/
config = kmemdup(cfg, sizeof(*cfg), GFP_KERNEL);
if (config == NULL) {
- kfree(rdev);
ret = -ENOMEM;
- goto rinse;
+ goto clean;
}
init_data = regulator_of_get_init_data(dev, regulator_desc, config,
@@ -5158,10 +5158,8 @@ regulator_register(const struct regulator_desc
*regulator_desc,
* from a gpio extender or something else.
*/
if (PTR_ERR(init_data) == -EPROBE_DEFER) {
- kfree(config);
- kfree(rdev);
ret = -EPROBE_DEFER;
- goto rinse;
+ goto clean;
}
/*
@@ -5214,7 +5212,6 @@ regulator_register(const struct regulator_desc
*regulator_desc,
}
/* register with sysfs */
- device_initialize(>dev);
rdev->dev.class = _class;
rdev->dev.parent = dev;
dev_set_name(>dev, "regulator.%lu",
@@ -5292,13 +5289,11 @@ regulator_register(const struct regulator_desc
*regulator_desc,
mutex_lock(_list_mutex);
regulator_ena_gpio_free(rdev);
mutex_unlock(_list_mutex);
- put_device(>dev);
- rdev = NULL;
clean:
if (dangling_of_gpiod)
gpiod_put(config->ena_gpiod);
- kfree(rdev);
kfree(config);
+ put_device(>dev);
rinse:
if (dangling_cfg_gpiod)
gpiod_put(cfg->ena_gpiod);
--
2.20.1
Re: [PATCH] usb: xhci-mtk: Fix typo
On Sat, 2020-08-08 at 14:49 +0200, Frank Wunderlich wrote:
> From: Frank Wunderlich
>
> fix this small typo u3_ports_disabed => u3_ports_disabled
>
> Fixes: 55ba6e9e25a6 (usb: xhci-mtk: support option to disable usb3 ports)
> Signed-off-by: Frank Wunderlich
> ---
> drivers/usb/host/xhci-mtk.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
> index 4311d4c9b68d..8f321f39ab96 100644
> --- a/drivers/usb/host/xhci-mtk.c
> +++ b/drivers/usb/host/xhci-mtk.c
> @@ -77,7 +77,7 @@ static int xhci_mtk_host_enable(struct xhci_hcd_mtk *mtk)
> {
> struct mu3c_ippc_regs __iomem *ippc = mtk->ippc_regs;
> u32 value, check_val;
> - int u3_ports_disabed = 0;
> + int u3_ports_disabled = 0;
> int ret;
> int i;
>
> @@ -92,7 +92,7 @@ static int xhci_mtk_host_enable(struct xhci_hcd_mtk *mtk)
> /* power on and enable u3 ports except skipped ones */
> for (i = 0; i < mtk->num_u3_ports; i++) {
> if ((0x1 << i) & mtk->u3p_dis_msk) {
> - u3_ports_disabed++;
> + u3_ports_disabled++;
> continue;
> }
>
> @@ -117,7 +117,7 @@ static int xhci_mtk_host_enable(struct xhci_hcd_mtk *mtk)
> check_val = STS1_SYSPLL_STABLE | STS1_REF_RST |
> STS1_SYS125_RST | STS1_XHCI_RST;
>
> - if (mtk->num_u3_ports > u3_ports_disabed)
> + if (mtk->num_u3_ports > u3_ports_disabled)
> check_val |= STS1_U3_MAC_RST;
>
> ret = readl_poll_timeout(>ip_pw_sts1, value,
Reviewed-by: Chunfeng Yun
Thanks
Re: [PATCH v7] Makefile: Add clang-tidy and static analyzer support to makefile
Sounds good. Do you think this patch is ready to land then?
On Thu, Aug 6, 2020 at 5:10 PM Masahiro Yamada wrote:
>
> On Fri, Aug 7, 2020 at 6:42 AM 'Nathan Huckleberry' via Clang Built
> Linux wrote:
> >
> > On Thu, Aug 6, 2020 at 3:44 AM Masahiro Yamada wrote:
> > >
> > > On Tue, Jul 28, 2020 at 9:47 AM Nathan Huckleberry
> > > wrote:
> > > >
> > > > This patch adds clang-tidy and the clang static-analyzer as make
> > > > targets. The goal of this patch is to make static analysis tools
> > > > usable and extendable by any developer or researcher who is familiar
> > > > with basic c++.
> > > >
> > > > The current static analysis tools require intimate knowledge of the
> > > > internal workings of the static analysis. Clang-tidy and the clang
> > > > static analyzers expose an easy to use api and allow users unfamiliar
> > > > with clang to write new checks with relative ease.
> > > >
> > > > ===Clang-tidy===
> > > >
> > > > Clang-tidy is an easily extendable 'linter' that runs on the AST.
> > > > Clang-tidy checks are easy to write and understand. A check consists of
> > > > two parts, a matcher and a checker. The matcher is created using a
> > > > domain specific language that acts on the AST
> > > > (https://clang.llvm.org/docs/LibASTMatchersReference.html). When AST
> > > > nodes are found by the matcher a callback is made to the checker. The
> > > > checker can then execute additional checks and issue warnings.
> > > >
> > > > Here is an example clang-tidy check to report functions that have calls
> > > > to local_irq_disable without calls to local_irq_enable and vice-versa.
> > > > Functions flagged with __attribute((annotation("ignore_irq_balancing")))
> > > > are ignored for analysis. (https://reviews.llvm.org/D65828)
> > > >
> > > > ===Clang static analyzer===
> > > >
> > > > The clang static analyzer is a more powerful static analysis tool that
> > > > uses symbolic execution to find bugs. Currently there is a check that
> > > > looks for potential security bugs from invalid uses of kmalloc and
> > > > kfree. There are several more general purpose checks that are useful for
> > > > the kernel.
> > > >
> > > > The clang static analyzer is well documented and designed to be
> > > > extensible.
> > > > (https://clang-analyzer.llvm.org/checker_dev_manual.html)
> > > > (https://github.com/haoNoQ/clang-analyzer-guide/releases/download/v0.1/clang-analyzer-guide-v0.1.pdf)
> > > >
> > > > The main draw of the clang tools is how accessible they are. The clang
> > > > documentation is very nice and these tools are built specifically to be
> > > > easily extendable by any developer. They provide an accessible method of
> > > > bug-finding and research to people who are not overly familiar with the
> > > > kernel codebase.
> > > >
> > > > Signed-off-by: Nathan Huckleberry
> > > > ---
> > > > Changes v6->v7
> > > > * Fix issues with relative paths
> > > > * Additional style fixes
> > > > MAINTAINERS | 1 +
> > > > Makefile | 3 +
> > > > scripts/clang-tools/Makefile.clang-tools | 23 ++
> > > > .../{ => clang-tools}/gen_compile_commands.py | 0
> > > > scripts/clang-tools/run-clang-tools.py| 74 +++
> > > > 5 files changed, 101 insertions(+)
> > > > create mode 100644 scripts/clang-tools/Makefile.clang-tools
> > > > rename scripts/{ => clang-tools}/gen_compile_commands.py (100%)
> > > > create mode 100755 scripts/clang-tools/run-clang-tools.py
> > > >
> > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > index 1d4aa7f942de..a444564e5572 100644
> > > > --- a/MAINTAINERS
> > > > +++ b/MAINTAINERS
> > > > @@ -4198,6 +4198,7 @@ W:https://clangbuiltlinux.github.io/
> > > > B: https://github.com/ClangBuiltLinux/linux/issues
> > > > C: irc://chat.freenode.net/clangbuiltlinux
> > > > F: Documentation/kbuild/llvm.rst
> > > > +F: scripts/clang-tools/
> > > > K: \b(?i:clang|llvm)\b
> > > >
> > > > CLEANCACHE API
> > > > diff --git a/Makefile b/Makefile
> > > > index fe0164a654c7..3e2df010b342 100644
> > > > --- a/Makefile
> > > > +++ b/Makefile
> > > > @@ -747,6 +747,7 @@ KBUILD_CFLAGS += $(call
> > > > cc-option,-fno-allow-store-data-races)
> > > >
> > > > include scripts/Makefile.kcov
> > > > include scripts/Makefile.gcc-plugins
> > > > +include scripts/clang-tools/Makefile.clang-tools
> > > >
> > > > ifdef CONFIG_READABLE_ASM
> > > > # Disable optimizations that make assembler listings hard to read.
> > > > @@ -1543,6 +1544,8 @@ help:
> > > > @echo ' export_report - List the usages of all exported
> > > > symbols'
> > > > @echo ' headerdep - Detect inclusion cycles in headers'
> > > > @echo ' coccicheck - Check with Coccinelle'
> > > > + @echo ' clang-analyzer - Check with clang static analyzer'
> > > > + @echo ' clang-tidy - Check with clang-tidy'
> > > > @echo ''
> > > >
Re: [PATCH v2 15/20] fuse, dax: Take ->i_mmap_sem lock during dax page fault
On Tue, Aug 11, 2020 at 01:55:30PM -0400, Vivek Goyal wrote:
> On Tue, Aug 11, 2020 at 08:22:38AM +1000, Dave Chinner wrote:
> > On Fri, Aug 07, 2020 at 03:55:21PM -0400, Vivek Goyal wrote:
> > > We need some kind of locking mechanism here. Normal file systems like
> > > ext4 and xfs seems to take their own semaphore to protect agains
> > > truncate while fault is going on.
> > >
> > > We have additional requirement to protect against fuse dax memory range
> > > reclaim. When a range has been selected for reclaim, we need to make sure
> > > no other read/write/fault can try to access that memory range while
> > > reclaim is in progress. Once reclaim is complete, lock will be released
> > > and read/write/fault will trigger allocation of fresh dax range.
> > >
> > > Taking inode_lock() is not an option in fault path as lockdep complains
> > > about circular dependencies. So define a new fuse_inode->i_mmap_sem.
> >
> > That's precisely why filesystems like ext4 and XFS define their own
> > rwsem.
> >
> > Note that this isn't a DAX requirement - the page fault
> > serialisation is actually a requirement of hole punching...
>
> Hi Dave,
>
> I noticed that fuse code currently does not seem to have a rwsem which
> can provide mutual exclusion between truncation/hole_punch path
> and page fault path. I am wondering does that mean there are issues
> with existing code or something else makes it unnecessary to provide
> this mutual exlusion.
I don't know enough about the fuse implementation to say. What I'm
saying is that nothing in the core mm/ or VFS serilises page cache
access to the data against direct filesystem manipulations of the
underlying filesystem structures.
i.e. nothing in the VFS or page fault IO path prevents this race
condition:
P0 P1
fallocate
page cache invalidation
page fault
read data
punch out data extents
That's where the ext4 and XFS internal rwsem come into play:
fallocate
down_write(mmaplock)
page cache invalidation
page fault
down_read(mmaplock)
punch out data
up_write(mmaplock)
And there's not stale data exposure to userspace.
It's the same reason that we use the i_rwsem to prevent concurrent
IO while a truncate or hole punch is in progress. The IO could map
the extent, then block in the IO path, while the filesytsem
re-allocates and writes new data or metadata to those blocks. That's
another potential non-owner data exposure problem.
And if you don't drain AIO+DIO before truncate/hole punch, the
i_rwsem does not protect you against concurrent IO as that gets
dropped after the AIO is submitted and returns EIOCBQUEUED to the
AIO layer. Hence there's IO in flight that isn't tracked by the
i_rwsem or the MMAPLOCK, and if you punch out the blocks and
reallocate them while the IO is in flight
> > > @@ -3849,9 +3856,11 @@ static long fuse_file_fallocate(struct file *file,
> > > int mode, loff_t offset,
> > > file_update_time(file);
> > > }
> > >
> > > - if (mode & FALLOC_FL_PUNCH_HOLE)
> > > + if (mode & FALLOC_FL_PUNCH_HOLE) {
> > > + down_write(>i_mmap_sem);
> > > truncate_pagecache_range(inode, offset, offset + length - 1);
> > > -
> > > + up_write(>i_mmap_sem);
> > > + }
> > > fuse_invalidate_attr(inode);
> >
> >
> > I'm not sure this is sufficient. You have to lock page faults out
> > for the entire time the hole punch is being performed, not just while
> > the mapping is being invalidated.
> >
> > That is, once you've taken the inode lock and written back the dirty
> > data over the range being punched, you can then take a page fault
> > and dirty the page again. Then after you punch the hole out,
> > you have a dirty page with non-zero data in it, and that can get
> > written out before the page cache is truncated.
>
> Just for my better udnerstanding of the issue, I am wondering what
> problem will it lead to.
> If one process is doing punch_hole and other is writing in the
> range being punched, end result could be anything. Either we will
> read zeroes from punched_hole pages or we will read the data
> written by process writing to mmaped page, depending on in what
> order it got executed.
>
> If that's the case, then holding fi->i_mmap_sem for the whole
> duration might not matter. What am I missing?
That it is safe to invalidate the page cache after the hole has been
punched.
There is nothing stopping, say, memory reclaim from reclaiming pages
over the range while the hole is being punched, then having the
application refault them while the backing store is being freed.
While the page fault read IO is in progress, there's nothing
stopping the filesystem
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
kernel/time/timekeeping.c
between commit:
025e82bcbc34 ("timekeeping: Use sequence counter with associated raw
spinlock")
from Linus' tree and commit:
19d0070a2792 ("timekeeping/vsyscall: Provide vdso_update_begin/end()")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc kernel/time/timekeeping.c
index 406306b33452,4c7212f3c603..
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@@ -39,8 -39,6 +39,8 @@@ enum timekeeping_adv_mode
TK_ADV_FREQ
};
- static DEFINE_RAW_SPINLOCK(timekeeper_lock);
++DEFINE_RAW_SPINLOCK(timekeeper_lock);
+
/*
* The most important data for readout fits into a single 64 byte
* cache line.
pgp5ITxPcZF6m.pgp
Description: OpenPGP digital signature
