Re: DMA direct mapping fix for 5.4 and earlier stable branches
Thanks Greg for your response. On Tue, 9 Feb 2021 at 12:28, Greg Kroah-Hartman wrote: > > On Tue, Feb 09, 2021 at 11:39:25AM +0530, Sumit Garg wrote: > > Hi Christoph, Greg, > > > > Currently we are observing an incorrect address translation > > corresponding to DMA direct mapping methods on 5.4 stable kernel while > > sharing dmabuf from one device to another where both devices have > > their own coherent DMA memory pools. > > What devices have this problem? The problem is seen with V4L2 device drivers which are currently under development for UniPhier PXs3 Reference Board from Socionext [1]. Following is brief description of the test framework: The issue is observed while trying to construct a Gstreamer pipeline leveraging hardware video converter engine (VPE device) and hardware video encode/decode engine (CODEC device) where we use dmabuf framework for Zero-Copy. Example GStreamer pipeline is: gst-launch-1.0 -v -e videotestsrc \ > ! video/x-raw, width=480, height=270, format=NV15 \ > ! v4l2convert device=/dev/vpe0 capture-io-mode=dmabuf-import \ > ! video/x-raw, width=480, height=270, format=NV12 \ > ! v4l2h265enc device=/dev/codec0 output-io-mode=dmabuf \ > ! video/x-h265, format=byte-stream, width=480, height=270 \ > ! filesink location=out.hevc Using GStreamer's V4L2 plugin, - v4l2convert controls VPE driver, - v4l2h265enc controls CODEC driver. In the above pipeline, VPE driver imports CODEC driver's DMABUF for Zero-Copy. [1] arch/arm64/boot/dts/socionext/uniphier-pxs3-ref.dts > And why can't then just use 5.10 to > solve this issue as that problem has always been present for them, > right? As the drivers are currently under development and Socionext has chosen 5.4 stable kernel for their development. So I will let Obayashi-san answer this if it's possible for them to migrate to 5.10 instead? BTW, this problem belongs to the common code, so others may experience this issue as well. > > > I am able to root cause this issue which is caused by incorrect virt > > to phys translation for addresses belonging to vmalloc space using > > virt_to_page(). But while looking at the mainline kernel, this patch > > [1] changes address translation from virt->to->phys to dma->to->phys > > which fixes the issue observed on 5.4 stable kernel as well (minimal > > fix [2]). > > > > So I would like to seek your suggestion for backport to stable kernels > > (5.4 or earlier) as to whether we should backport the complete > > mainline commit [1] or we should just apply the minimal fix [2]? > > Whenever you try to create a "minimal" fix, 90% of the time it is wrong > and does not work and I end up having to deal with the mess. I agree with your concerns for having to apply a non-mainline commit onto a stable kernel. > What > prevents you from doing the real thing here? Are the patches to big? > IMHO, yes the mainline patch is big enough to touch multiple architectures. But if that's the only way preferred then I can backport the mainline patch instead. > And again, why not just use 5.10 for this hardware? What hardware is > it? > Please see my response above. -Sumit > thanks, > > greg k-h
Re: [PATCH v3] brcmfmac: add support for CQM RSSI notifications
Alvin Šipraga wrote: > Add support for CQM RSSI measurement reporting and advertise the > NL80211_EXT_FEATURE_CQM_RSSI_LIST feature. This enables a userspace > supplicant such as iwd to be notified of changes in the RSSI for roaming > and signal monitoring purposes. > > Signed-off-by: Alvin Šipraga > Reviewed-by: Arend van Spriel Patch applied to wireless-drivers-next.git, thanks. 7dd56ea45a66 brcmfmac: add support for CQM RSSI notifications -- https://patchwork.kernel.org/project/linux-wireless/patch/20210208125738.3546557-1-a...@bang-olufsen.dk/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [Intel-gfx] [FYI PATCH] i915: kvmgt: the KVM mmu_lock is now an rwlock
Hi Paolo,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on linux/master drm-tip/drm-tip linus/master v5.11-rc6
next-20210125]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Paolo-Bonzini/i915-kvmgt-the-KVM-mmu_lock-is-now-an-rwlock/20210209-070812
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
#
https://github.com/0day-ci/linux/commit/e1625dbf5fa4aea9c53da01a04bfb55443375c30
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Paolo-Bonzini/i915-kvmgt-the-KVM-mmu_lock-is-now-an-rwlock/20210209-070812
git checkout e1625dbf5fa4aea9c53da01a04bfb55443375c30
# save the attached .config to linux build tree
make W=1 ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
In file included from include/linux/spinlock.h:312,
from include/linux/wait.h:9,
from include/linux/pid.h:6,
from include/linux/sched.h:14,
from include/linux/ratelimit.h:6,
from include/linux/dev_printk.h:16,
from include/linux/device.h:15,
from drivers/gpu/drm/i915/gvt/kvmgt.c:32:
drivers/gpu/drm/i915/gvt/kvmgt.c: In function 'kvmgt_page_track_add':
>> drivers/gpu/drm/i915/gvt/kvmgt.c:1706:13: error: passing argument 1 of
>> '_raw_write_lock' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
1706 | write_lock(&kvm->mmu_lock);
| ^~
| |
| spinlock_t * {aka struct spinlock *}
include/linux/rwlock.h:70:42: note: in definition of macro 'write_lock'
70 | #define write_lock(lock) _raw_write_lock(lock)
| ^~~~
In file included from include/linux/spinlock_api_smp.h:190,
from include/linux/spinlock.h:318,
from include/linux/wait.h:9,
from include/linux/pid.h:6,
from include/linux/sched.h:14,
from include/linux/ratelimit.h:6,
from include/linux/dev_printk.h:16,
from include/linux/device.h:15,
from drivers/gpu/drm/i915/gvt/kvmgt.c:32:
include/linux/rwlock_api_smp.h:19:43: note: expected 'rwlock_t *' {aka
'struct *'} but argument is of type 'spinlock_t *' {aka 'struct
spinlock *'}
19 | void __lockfunc _raw_write_lock(rwlock_t *lock) __acquires(lock);
| ~~^~~~
In file included from include/linux/spinlock.h:312,
from include/linux/wait.h:9,
from include/linux/pid.h:6,
from include/linux/sched.h:14,
from include/linux/ratelimit.h:6,
from include/linux/dev_printk.h:16,
from include/linux/device.h:15,
from drivers/gpu/drm/i915/gvt/kvmgt.c:32:
>> drivers/gpu/drm/i915/gvt/kvmgt.c:1715:15: error: passing argument 1 of
>> '_raw_write_unlock' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
1715 | write_unlock(&kvm->mmu_lock);
| ^~
| |
| spinlock_t * {aka struct spinlock *}
include/linux/rwlock.h:106:47: note: in definition of macro 'write_unlock'
106 | #define write_unlock(lock) _raw_write_unlock(lock)
| ^~~~
In file included from include/linux/spinlock_api_smp.h:190,
from include/linux/spinlock.h:318,
from include/linux/wait.h:9,
from include/linux/pid.h:6,
from include/linux/sched.h:14,
from include/linux/ratelimit.h:6,
from include/linux/dev_printk.h:16,
from include/linux/device.h:15,
from drivers/gpu/drm/i915/gvt/kvmgt.c:32:
include/linux/rwlock_api_smp.h:31:45: note: expected 'rwlock_t *' {aka
'struct *'} but argument is of type 'spinlock_t *' {aka 'struct
spinlock *'}
31 | void __lockfunc _raw_write_unlock(rwlock_t *lock) __releases(lock);
| ~~^~~~
In file included from include/linux/spinlock.h:312,
from include/linux/wait.h:9,
from include/linux/pid.h:6,
from inclu
Re: [PATCH v5 17/22] powerpc/syscall: Do not check unsupported scv vector on PPC32
Excerpts from Christophe Leroy's message of February 9, 2021 4:13 pm:
>
>
> Le 09/02/2021 à 03:00, Nicholas Piggin a écrit :
>> Excerpts from Christophe Leroy's message of February 9, 2021 1:10 am:
>>> Only PPC64 has scv. No need to check the 0x7ff0 trap on PPC32.
>>> For that, add a helper trap_is_unsupported_scv() similar to
>>> trap_is_scv().
>>>
>>> And ignore the scv parameter in syscall_exit_prepare (Save 14 cycles
>>> 346 => 332 cycles)
>>>
>>> Signed-off-by: Christophe Leroy
>>> ---
>>> v5: Added a helper trap_is_unsupported_scv()
>>> ---
>>> arch/powerpc/include/asm/ptrace.h | 5 +
>>> arch/powerpc/kernel/entry_32.S| 1 -
>>> arch/powerpc/kernel/interrupt.c | 7 +--
>>> 3 files changed, 10 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/powerpc/include/asm/ptrace.h
>>> b/arch/powerpc/include/asm/ptrace.h
>>> index 58f9dc060a7b..2c842b11a924 100644
>>> --- a/arch/powerpc/include/asm/ptrace.h
>>> +++ b/arch/powerpc/include/asm/ptrace.h
>>> @@ -229,6 +229,11 @@ static inline bool trap_is_scv(struct pt_regs *regs)
>>> return (IS_ENABLED(CONFIG_PPC_BOOK3S_64) && TRAP(regs) == 0x3000);
>>> }
>>>
>>> +static inline bool trap_is_unsupported_scv(struct pt_regs *regs)
>>> +{
>>> + return (IS_ENABLED(CONFIG_PPC_BOOK3S_64) && TRAP(regs) == 0x7ff0);
>>> +}
>>
>> This change is good.
>>
>>> +
>>> static inline bool trap_is_syscall(struct pt_regs *regs)
>>> {
>>> return (trap_is_scv(regs) || TRAP(regs) == 0xc00);
>>> diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
>>> index cffe58e63356..7c824e8928d0 100644
>>> --- a/arch/powerpc/kernel/entry_32.S
>>> +++ b/arch/powerpc/kernel/entry_32.S
>>> @@ -344,7 +344,6 @@ transfer_to_syscall:
>>>
>>> ret_from_syscall:
>>> addir4,r1,STACK_FRAME_OVERHEAD
>>> - li r5,0
>>> bl syscall_exit_prepare
>>
>> For this one, I think it would be nice to do the "right" thing and make
>> the function prototypes different on !64S. They could then declare a
>> local const bool scv = 0.
>>
>> We could have syscall_exit_prepare and syscall_exit_prepare_maybe_scv
>> or something like that, 64s can use the latter one and the former can be
>> a wrapper that passes constant 0 for scv. Then we don't have different
>> prototypes for the same function, but you just have to make the 32-bit
>> version static inline and the 64-bit version exported to asm.
>
> You can't call a static inline function from ASM, I don't understand you.
I mean
#ifdef CONFIG_PPC_BOOK3S_64
notrace unsigned long syscall_exit_prepare_scv(unsigned long r3,
struct pt_regs *regs,
long scv)
#else
static inline long syscall_exit_prepare_scv(unsigned long r3,
struct pt_regs *regs,
long scv)
#endif
#ifndef CONFIG_PPC_BOOK3S_64
notrace unsigned long syscall_exit_prepare(unsigned long r3,
struct pt_regs *regs)
{
return syscall_exit_prepare_scv(r3, regs, 0);
}
#endif
>
> What is wrong for you really here ? Is that the fact we leave scv random, or
> is that the below
> IS_ENABLED() ?
That scv arg is random. I know generated code essentially would be no
different and no possibility of tracing, but would just prefer to call
the C "correctly" if possible.
> I don't mind keeping the 'li r5,0' before calling the function if you find it
> cleaner, the real
> performance gain is with setting scv to 0 below for PPC32 (and maybe it
> should be set to zero for
> book3e/64 too ?).
Yes 64e would like this optimisation.
Thanks,
Nick
Re: [PATCH] clk: at91: sama5d2: Mark device OF_POPULATED after setup
Quoting Saravana Kannan (2021-01-28 09:01:41)
> On Thu, Jan 28, 2021 at 2:45 AM Tudor Ambarus
> wrote:
> >
> > The sama5d2 requires the clock provider initialized before timers.
> > We can't use a platform driver for the sama5d2-pmc driver, as the
> > platform_bus_init() is called later on, after time_init().
> >
> > As fw_devlink considers only devices, it does not know that the
> > pmc is ready. Hence probing of devices that depend on it fail:
> > probe deferral - supplier f0014000.pmc not ready
> >
> > Fix this by setting the OF_POPULATED flag for the sama5d2_pmc
> > device node after successful setup. This will make
> > of_link_to_phandle() ignore the sama5d2_pmc device node as a
> > dependency, and consumer devices will be probed again.
> >
> > Fixes: e590474768f1cc04 ("driver core: Set fw_devlink=on by default")
> > Signed-off-by: Tudor Ambarus
> > ---
> > I'll be out of office, will check the rest of the at91 SoCs
> > at the begining of next week.
> >
> > drivers/clk/at91/sama5d2.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/clk/at91/sama5d2.c b/drivers/clk/at91/sama5d2.c
> > index 9a5cbc7cd55a..5eea2b4a63dd 100644
> > --- a/drivers/clk/at91/sama5d2.c
> > +++ b/drivers/clk/at91/sama5d2.c
> > @@ -367,6 +367,8 @@ static void __init sama5d2_pmc_setup(struct device_node
> > *np)
> >
> > of_clk_add_hw_provider(np, of_clk_hw_pmc_get, sama5d2_pmc);
> >
> > + of_node_set_flag(np, OF_POPULATED);
> > +
> > return;
>
> Hi Tudor,
>
> Thanks for looking into this.
>
> I already accounted for early clocks like this when I designed
> fw_devlink. Each driver shouldn't need to set OF_POPULATED.
> drivers/clk/clk.c already does this for you.
>
> I think the problem is that your driver is using
> CLK_OF_DECLARE_DRIVER() instead of CLK_OF_DECLARE(). The comments for
> CLK_OF_DECLARE_DRIVER() says:
> /*
> * Use this macro when you have a driver that requires two initialization
> * routines, one at of_clk_init(), and one at platform device probe
> */
>
> In your case, you are explicitly NOT having a driver bind to this
> clock later. So you shouldn't be using CLK_OF_DECLARE() instead.
>
I see
drivers/power/reset/at91-sama5d2_shdwc.c: { .compatible =
"atmel,sama5d2-pmc" },
so isn't that the driver that wants to bind to the same device node
again? First at of_clk_init() time here and then second for the reset
driver?
Re: [PATCH 1/1] kernel/smp: Split call_single_queue into 3 queues
On Mon, Feb 08, 2021 at 02:03:47PM -0300, Leonardo Bras wrote: > > with the patch at the bottom of the mail. This shows that in my > > smoke test at least, the number of items in the individual list is low. > > Yes, but depending on workload this list may get longer. Get a median number of entries on the list, if you can get your median anywhere near large enough to any of this to matter I'd be very surprised. This needs lots of numbers..
Re: [PATCH v5 09/22] powerpc/syscall: Make interrupt.c buildable on PPC32
Excerpts from Christophe Leroy's message of February 9, 2021 4:02 pm:
>
>
> Le 09/02/2021 à 02:27, Nicholas Piggin a écrit :
>> Excerpts from Christophe Leroy's message of February 9, 2021 1:10 am:
>>> To allow building interrupt.c on PPC32, ifdef out specific PPC64
>>> code or use helpers which are available on both PP32 and PPC64
>>>
>>> Modify Makefile to always build interrupt.o
>>>
>>> Signed-off-by: Christophe Leroy
>>> ---
>>> v5:
>>> - Also for interrupt exit preparation
>>> - Opted out kuap related code, ppc32 keeps it in ASM for the time being
>>> ---
>>> arch/powerpc/kernel/Makefile| 4 ++--
>>> arch/powerpc/kernel/interrupt.c | 31 ---
>>> 2 files changed, 26 insertions(+), 9 deletions(-)
>>>
>
>>> diff --git a/arch/powerpc/kernel/interrupt.c
>>> b/arch/powerpc/kernel/interrupt.c
>>> index d6be4f9a67e5..2dac4d2bb1cf 100644
>>> --- a/arch/powerpc/kernel/interrupt.c
>>> +++ b/arch/powerpc/kernel/interrupt.c
>>> @@ -39,7 +39,7 @@ notrace long system_call_exception(long r3, long r4, long
>>> r5,
>>> BUG_ON(!(regs->msr & MSR_RI));
>>> BUG_ON(!(regs->msr & MSR_PR));
>>> BUG_ON(!FULL_REGS(regs));
>>> - BUG_ON(regs->softe != IRQS_ENABLED);
>>> + BUG_ON(arch_irq_disabled_regs(regs));
>>>
>>> #ifdef CONFIG_PPC_PKEY
>>> if (mmu_has_feature(MMU_FTR_PKEY)) {
>>> @@ -65,7 +65,9 @@ notrace long system_call_exception(long r3, long r4, long
>>> r5,
>>> isync();
>>> } else
>>> #endif
>>> +#ifdef CONFIG_PPC64
>>> kuap_check_amr();
>>> +#endif
>>
>> Wouldn't mind trying to get rid of these ifdefs at some point, but
>> there's some kuap / keys changes going on recently so I'm happy enough
>> to let this settle then look at whether we can refactor.
>
> I have a follow up series that implements interrupts entries/exits in C and
> that removes all kuap
> assembly, I will likely release it as RFC later today.
>
>>
>>>
>>> account_cpu_user_entry();
>>>
>>> @@ -318,7 +323,7 @@ notrace unsigned long syscall_exit_prepare(unsigned
>>> long r3,
>>> return ret;
>>> }
>>>
>>> -#ifdef CONFIG_PPC_BOOK3S /* BOOK3E not yet using this */
>>> +#ifndef CONFIG_PPC_BOOK3E_64 /* BOOK3E not yet using this */
>>> notrace unsigned long interrupt_exit_user_prepare(struct pt_regs *regs,
>>> unsigned long msr)
>>> {
>>> #ifdef CONFIG_PPC_BOOK3E
>>
>> Why are you building this for 32? I don't mind if it's just to keep
>> things similar and make it build for now, but you're not using it yet,
>> right?
>
> The series using that will follow, I thought it would be worth doing this at
> once.
Yeah that's fine by me then.
Thanks,
Nick
Re: [PATCH v3] clk: exynos7: Keep aclk_fsys1_200 enabled
Quoting (2021-01-31 09:04:28) > This clock must be always enabled to allow access to any registers in > fsys1 CMU. Until proper solution based on runtime PM is applied > (similar to what was done for Exynos5433), fix this by calling > clk_prepare_enable() directly from clock provider driver. > > It was observed on Samsung Galaxy S6 device (based on Exynos7420), where > UFS module is probed before pmic used to power that device. > In this case defer probe was happening and that clock was disabled by > UFS driver, causing whole boot to hang on next CMU access. > Does this need a Fixes tag?
Re: [PATCH v5 05/22] powerpc/irq: Add helper to set regs->softe
Excerpts from Christophe Leroy's message of February 9, 2021 3:57 pm:
>
>
> Le 09/02/2021 à 02:11, Nicholas Piggin a écrit :
>> Excerpts from Christophe Leroy's message of February 9, 2021 1:10 am:
>>> regs->softe doesn't exist on PPC32.
>>>
>>> Add irq_soft_mask_regs_set_state() helper to set regs->softe.
>>> This helper will void on PPC32.
>>>
>>> Signed-off-by: Christophe Leroy
>>> ---
>>> arch/powerpc/include/asm/hw_irq.h | 11 +--
>>> 1 file changed, 9 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/powerpc/include/asm/hw_irq.h
>>> b/arch/powerpc/include/asm/hw_irq.h
>>> index 614957f74cee..ed0c3b049dfd 100644
>>> --- a/arch/powerpc/include/asm/hw_irq.h
>>> +++ b/arch/powerpc/include/asm/hw_irq.h
>>> @@ -38,6 +38,8 @@
>>> #define PACA_IRQ_MUST_HARD_MASK (PACA_IRQ_EE)
>>> #endif
>>>
>>> +#endif /* CONFIG_PPC64 */
>>> +
>>> /*
>>>* flags for paca->irq_soft_mask
>>>*/
>>> @@ -46,8 +48,6 @@
>>> #define IRQS_PMI_DISABLED 2
>>> #define IRQS_ALL_DISABLED (IRQS_DISABLED | IRQS_PMI_DISABLED)
>>>
>>> -#endif /* CONFIG_PPC64 */
>>> -
>>> #ifndef __ASSEMBLY__
>>>
>>> #ifdef CONFIG_PPC64
>>> @@ -287,6 +287,10 @@ extern void irq_set_pending_from_srr1(unsigned long
>>> srr1);
>>>
>>> extern void force_external_irq_replay(void);
>>>
>>> +static inline void irq_soft_mask_regs_set_state(struct pt_regs *regs,
>>> unsigned long val)
>>> +{
>>> + regs->softe = val;
>>> +}
>>> #else /* CONFIG_PPC64 */
>>>
>>> static inline unsigned long arch_local_save_flags(void)
>>> @@ -355,6 +359,9 @@ static inline bool arch_irq_disabled_regs(struct
>>> pt_regs *regs)
>>>
>>> static inline void may_hard_irq_enable(void) { }
>>>
>>> +static inline void irq_soft_mask_regs_set_state(struct pt_regs *regs,
>>> unsigned long val)
>>> +{
>>> +}
>>> #endif /* CONFIG_PPC64 */
>>>
>>> #define ARCH_IRQ_INIT_FLAGS IRQ_NOREQUEST
>>
>> What I don't like about this where you use it is it kind of pollutes
>> the ppc32 path with this function which is not valid to use.
>>
>> I would prefer if you had this purely so it could compile with:
>>
>>if (IS_ENABLED(CONFIG_PPC64)))
>>irq_soft_mask_regs_set_state(regs, blah);
>>
>> And then you could make the ppc32 cause a link error if it did not
>> get eliminated at compile time (e.g., call an undefined function).
>>
>> You could do the same with the kuap_ functions to change some ifdefs
>> to IS_ENABLED.
>>
>> That's just my preference but if you prefer this way I guess that's
>> okay.
>
> I see you didn't change your mind since last April :)
>
> I'll see what I can do.
If you have more patches in the works and will do some cleanup passes I
don't mind so much.
Thanks,
Nick
Re: [PATCH v5 05/22] powerpc/irq: Add helper to set regs->softe
Excerpts from Christophe Leroy's message of February 9, 2021 4:18 pm: > > > Le 09/02/2021 à 02:11, Nicholas Piggin a écrit : >> Excerpts from Christophe Leroy's message of February 9, 2021 1:10 am: >>> regs->softe doesn't exist on PPC32. >>> >>> Add irq_soft_mask_regs_set_state() helper to set regs->softe. >>> This helper will void on PPC32. >>> >>> Signed-off-by: Christophe Leroy >>> --- >> >> You could do the same with the kuap_ functions to change some ifdefs >> to IS_ENABLED. >> >> That's just my preference but if you prefer this way I guess that's >> okay. >> > > > That's also my preference on the long term. > > Here it is ephemeral, I have a follow up series implementing interrupt > exit/entry in C and getting > rid of all the assembly kuap hence getting rid of those ifdefs. I thought it might have been because you hate ifdef more tha most :) > The issue I see when using IS_ENABLED() is that you have to indent to the > right, then you interfere > with the file history and 'git blame' Valid point if it's just going to indent back the other way in your next series. > Thanks for reviewing my series and looking forward to your feedback on my > series on the interrupt > entry/exit that I will likely release later today. Cool, I'm eager to see them. Thanks, Nick
Re: [PATCH v2] KVM: x86/MMU: Do not check unsync status for root SP.
On 09/02/21 04:33, Yu Zhang wrote: On Mon, Feb 08, 2021 at 05:47:22PM +0100, Paolo Bonzini wrote: On 08/02/21 14:49, Yu Zhang wrote: On Mon, Feb 08, 2021 at 12:36:57PM +0100, Paolo Bonzini wrote: On 07/02/21 13:22, Yu Zhang wrote: In shadow page table, only leaf SPs may be marked as unsync. And for non-leaf SPs, we use unsync_children to keep the number of the unsynced children. In kvm_mmu_sync_root(), sp->unsync shall always be zero for the root SP, , hence no need to check it. Instead, a warning inside mmu_sync_children() is added, in case someone incorrectly used it. Also, clarify the mmu_need_write_protect(), by moving the warning into kvm_unsync_page(). Signed-off-by: Yu Zhang Signed-off-by: Sean Christopherson This should really be more of a Co-developed-by, and there are a couple adjustments that could be made in the commit message. I've queued the patch and I'll fix it up later. Indeed. Thanks for the remind, and I'll pay attention in the future. :) Also: arch/x86/kvm/mmu/mmu.c: In function ‘mmu_sync_children’: arch/x86/kvm/mmu/mmu.c:2002:17: error: ‘sp’ is used uninitialized in this function [-Werror=uninitialized] WARN_ON_ONCE(sp->unsync); Oops. This is wrong. Should be WARN_ON_ONCE(parent->unsync); so how was this tested? I ran access test in kvm-unit-test for previous version, which hasn't this code(also in my local repo "enable_ept" was explicitly set to 0 in order to test the shadow mode). But I did not test this one. I'm truely sorry for the negligence - even trying to compile should make this happen! Should we submit another version? Any suggestions on the test cases? Yes, please send v3. The commit message can be: In shadow page table, only leaf SPs may be marked as unsync; instead, for non-leaf SPs, we store the number of unsynced children in unsync_children. Therefore, in kvm_mmu_sync_root(), sp->unsync shall always be zero for the root SP and there is no need to check it. Remove the check, and add a warning inside mmu_sync_children() to assert that the flags are used properly. While at it, move the warning from mmu_need_write_protect() to kvm_unsync_page(). Paolo
Re: [PATCH] clk: mediatek: Select all the MT8183 clocks by default
Quoting Enric Balletbo i Serra (2021-02-03 02:54:23) > If MT8183 SoC support is enabled, almost all machines will use topckgen, > apmixedsys, infracfg, mcucfg and subsystem clocks, so it feels wrong to > require each one to select that symbols manually. > > Instead, enable it whenever COMMON_CLK_MT8183_* is disabled as > a simplification. This would add few KB in the kernel image size but > will make the life a bit easier to the users, anyway you'll need to probably > enable all of them if you want to have proper support for that SoC. > > Signed-off-by: Enric Balletbo i Serra > --- Applied to clk-next
Re: [PATCH v12 3/7] kasan: Add report for async mode
Hi Vincenzo,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20210125]
[cannot apply to arm64/for-next/core xlnx/master arm/for-next soc/for-next
kvmarm/next linus/master hnaz-linux-mm/master v5.11-rc6 v5.11-rc5 v5.11-rc4
v5.11-rc6]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Vincenzo-Frascino/arm64-ARMv8-5-A-MTE-Add-async-mode-support/20210209-080907
base:59fa6a163ffabc1bf25c5e0e33899e268a96d3cc
config: x86_64-randconfig-s021-20210209 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.3-215-g0fb77bb6-dirty
#
https://github.com/0day-ci/linux/commit/93bd347e4877e3616f7db64f488ebb469718dd68
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Vincenzo-Frascino/arm64-ARMv8-5-A-MTE-Add-async-mode-support/20210209-080907
git checkout 93bd347e4877e3616f7db64f488ebb469718dd68
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' 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 >>):
ld: mm/kasan/report.o: in function `end_report':
>> mm/kasan/report.c:90: undefined reference to `kasan_flag_async'
>> ld: mm/kasan/report.c:90: undefined reference to `kasan_flag_async'
vim +90 mm/kasan/report.c
87
88 static void end_report(unsigned long *flags, unsigned long addr)
89 {
> 90 if (!kasan_flag_async)
91 trace_error_report_end(ERROR_DETECTOR_KASAN, addr);
92
pr_err("==\n");
93 add_taint(TAINT_BAD_PAGE, LOCKDEP_NOW_UNRELIABLE);
94 spin_unlock_irqrestore(&report_lock, *flags);
95 if (panic_on_warn && !test_bit(KASAN_BIT_MULTI_SHOT,
&kasan_flags)) {
96 /*
97 * This thread may hit another WARN() in the panic path.
98 * Resetting this prevents additional WARN() from
panicking the
99 * system on this thread. Other threads are blocked by
the
100 * panic_mutex in panic().
101 */
102 panic_on_warn = 0;
103 panic("panic_on_warn set ...\n");
104 }
105 #ifdef CONFIG_KASAN_HW_TAGS
106 if (kasan_flag_panic)
107 panic("kasan.fault=panic set ...\n");
108 #endif
109 kasan_enable_current();
110 }
111
---
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] ASoC: soc-pcm: change error message to debug message
On Tue, Feb 9, 2021 at 12:39 AM Pierre-Louis Bossart
wrote:
>
>
>
> On 2/8/21 2:12 AM, Shengjiu Wang wrote:
> > This log message should be a debug message, because it
> > doesn't return directly but continue next loop.
> >
> > Signed-off-by: Shengjiu Wang
> > ---
> > sound/soc/soc-pcm.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c
> > index 605acec48971..cd9e919d7b99 100644
> > --- a/sound/soc/soc-pcm.c
> > +++ b/sound/soc/soc-pcm.c
> > @@ -1344,8 +1344,8 @@ static int dpcm_add_paths(struct snd_soc_pcm_runtime
> > *fe, int stream,
> > /* is there a valid BE rtd for this widget */
> > be = dpcm_get_be(card, widget, stream);
> > if (!be) {
> > - dev_err(fe->dev, "ASoC: no BE found for %s\n",
> > - widget->name);
> > + dev_dbg(fe->dev, "ASoC: no BE found for %s\n",
> > + widget->name);
>
> Do we really want to do this?
>
> This error message has historically been the means by which we detect
> that userspace didn't set the right mixers (e.g. on Intel Baytrail) or
> the topology was incorrect. And it's really an error in the sense that
> you will not get audio in or out.
>
> If you demote this to dev_dbg, we'll have to ask every single user who
> reports 'sound is broken' to enable dynamic debug traces. I really don't
> see the benefit, this is a clear case of 'fail big and fail early',
> partly concealing the problem doesn't make it go away but harder to
> diagnose.
Thanks for the explanation, it seems I misunderstood this error message.
Best regards
Wang shengjiu
Re: [PATCH net 1/2] bridge: mrp: Fix the usage of br_mrp_port_switchdev_set_state
On 06/02/2021 22.47, Horatiu Vultur wrote:
> The function br_mrp_port_switchdev_set_state was called both with MRP
> port state and STP port state, which is an issue because they don't
> match exactly.
>
> Therefore, update the function to be used only with STP port state and
> use the id SWITCHDEV_ATTR_ID_PORT_STP_STATE.
>
> The choice of using STP over MRP is that the drivers already implement
> SWITCHDEV_ATTR_ID_PORT_STP_STATE and already in SW we update the port
> STP state.
>
> Fixes: 9a9f26e8f7ea30 ("bridge: mrp: Connect MRP API with the switchdev API")
> Fixes: fadd409136f0f2 ("bridge: switchdev: mrp: Implement MRP API for
> switchdev")
> Fixes: 2f1a11ae11d222 ("bridge: mrp: Add MRP interface.")
> Reported-by: Rasmus Villemoes
> Signed-off-by: Horatiu Vultur
> ---
Tested-by: Rasmus Villemoes
Re: [PATCH net 2/2] switchdev: mrp: Remove SWITCHDEV_ATTR_ID_MRP_PORT_STAT
On 06/02/2021 22.47, Horatiu Vultur wrote:
> Now that MRP started to use also SWITCHDEV_ATTR_ID_PORT_STP_STATE to
> notify HW, then SWITCHDEV_ATTR_ID_MRP_PORT_STAT is not used anywhere
> else, therefore we can remove it.
>
> Fixes: c284b545900830 ("switchdev: mrp: Extend switchdev API to offload MRP")
> Signed-off-by: Horatiu Vultur
Acked-by: Rasmus Villemoes
Re: KMSAN: uninit-value in bpf_iter_prog_supported
On Sun, Feb 7, 2021 at 1:20 PM syzbot wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit:73d62e81 kmsan: random: prevent boot-time reports in _mix_.. > git tree: https://github.com/google/kmsan.git master > console output: https://syzkaller.appspot.com/x/log.txt?x=17ac5f64d0 > kernel config: https://syzkaller.appspot.com/x/.config?x=df698232b2ac45c9 > dashboard link: https://syzkaller.appspot.com/bug?extid=580f4f2a272e452d55cb > compiler: Debian clang version 11.0.1-2 > userspace arch: i386 > > Unfortunately, I don't have any reproducer for this issue yet. > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+580f4f2a272e452d5...@syzkaller.appspotmail.com +BPF maintainers > = > BUG: KMSAN: uninit-value in bpf_iter_prog_supported+0x3dd/0x6a0 > syzkaller/managers/upstream-kmsan-gce-386/kernel/kernel/bpf/bpf_iter.c:329 > CPU: 0 PID: 18494 Comm: bpf_preload Not tainted 5.10.0-rc4-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack > syzkaller/managers/upstream-kmsan-gce-386/kernel/lib/dump_stack.c:77 [inline] > dump_stack+0x21c/0x280 > syzkaller/managers/upstream-kmsan-gce-386/kernel/lib/dump_stack.c:118 > kmsan_report+0xfb/0x1e0 > syzkaller/managers/upstream-kmsan-gce-386/kernel/mm/kmsan/kmsan_report.c:118 > __msan_warning+0x5f/0xa0 > syzkaller/managers/upstream-kmsan-gce-386/kernel/mm/kmsan/kmsan_instr.c:197 > bpf_iter_prog_supported+0x3dd/0x6a0 > syzkaller/managers/upstream-kmsan-gce-386/kernel/kernel/bpf/bpf_iter.c:329 > check_attach_btf_id > syzkaller/managers/upstream-kmsan-gce-386/kernel/kernel/bpf/verifier.c:11772 > [inline] > bpf_check+0x11872/0x1c380 > syzkaller/managers/upstream-kmsan-gce-386/kernel/kernel/bpf/verifier.c:11900 > bpf_prog_load > syzkaller/managers/upstream-kmsan-gce-386/kernel/kernel/bpf/syscall.c:2210 > [inline] > __do_sys_bpf+0x17483/0x1aee0 > syzkaller/managers/upstream-kmsan-gce-386/kernel/kernel/bpf/syscall.c:4399 > __se_sys_bpf+0x8e/0xa0 > syzkaller/managers/upstream-kmsan-gce-386/kernel/kernel/bpf/syscall.c:4357 > __x64_sys_bpf+0x4a/0x70 > syzkaller/managers/upstream-kmsan-gce-386/kernel/kernel/bpf/syscall.c:4357 > do_syscall_64+0x9f/0x140 > syzkaller/managers/upstream-kmsan-gce-386/kernel/arch/x86/entry/common.c:48 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > RIP: 0033:0x7fb70b5ab469 > Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 73 > 01 c3 48 8b 0d ff 49 2b 00 f7 d8 64 89 01 48 > RSP: 002b:7ffdbb4cde38 EFLAGS: 0246 ORIG_RAX: 0141 > RAX: ffda RBX: 0065b110 RCX: 7fb70b5ab469 > RDX: 0078 RSI: 7ffdbb4cdef0 RDI: 0005 > RBP: 7ffdbb4cdef0 R08: 00100017 R09: > R10: 7ffdbb4ce0e8 R11: 0246 R12: > R13: 7ffdbb4cdf20 R14: R15: > > Uninit was created at: > kmsan_save_stack_with_flags > syzkaller/managers/upstream-kmsan-gce-386/kernel/mm/kmsan/kmsan.c:121 [inline] > kmsan_internal_poison_shadow+0x5c/0xf0 > syzkaller/managers/upstream-kmsan-gce-386/kernel/mm/kmsan/kmsan.c:104 > kmsan_slab_alloc+0x8d/0xe0 > syzkaller/managers/upstream-kmsan-gce-386/kernel/mm/kmsan/kmsan_hooks.c:76 > slab_alloc_node > syzkaller/managers/upstream-kmsan-gce-386/kernel/mm/slub.c:2906 [inline] > slab_alloc syzkaller/managers/upstream-kmsan-gce-386/kernel/mm/slub.c:2915 > [inline] > kmem_cache_alloc_trace+0x893/0x1000 > syzkaller/managers/upstream-kmsan-gce-386/kernel/mm/slub.c:2932 > kmalloc > syzkaller/managers/upstream-kmsan-gce-386/kernel/./include/linux/slab.h:552 > [inline] > bpf_iter_reg_target+0x81/0x3f0 > syzkaller/managers/upstream-kmsan-gce-386/kernel/kernel/bpf/bpf_iter.c:276 > bpf_sk_storage_map_iter_init+0x6a/0x85 > syzkaller/managers/upstream-kmsan-gce-386/kernel/net/core/bpf_sk_storage.c:870 > do_one_initcall+0x362/0x8d0 > syzkaller/managers/upstream-kmsan-gce-386/kernel/init/main.c:1220 > do_initcall_level+0x1e7/0x35a > syzkaller/managers/upstream-kmsan-gce-386/kernel/init/main.c:1293 > do_initcalls+0x127/0x1cb > syzkaller/managers/upstream-kmsan-gce-386/kernel/init/main.c:1309 > do_basic_setup+0x33/0x36 > syzkaller/managers/upstream-kmsan-gce-386/kernel/init/main.c:1329 > kernel_init_freeable+0x238/0x38b > syzkaller/managers/upstream-kmsan-gce-386/kernel/init/main.c:1529 > kernel_init+0x1f/0x840 > syzkaller/managers/upstream-kmsan-gce-386/kernel/init/main.c:1418 > ret_from_fork+0x1f/0x30 > syzkaller/managers/upstream-kmsan-gce-386/kernel/arch/x86/entry/entry_64.S:296 > = > > > --- > This report is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more in
Re: KMSAN: uninit-value in ext4_inode_journal_mode
On Sun, Feb 7, 2021 at 1:20 PM syzbot wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit:73d62e81 kmsan: random: prevent boot-time reports in _mix_.. > git tree: https://github.com/google/kmsan.git master > console output: https://syzkaller.appspot.com/x/log.txt?x=152188c4d0 > kernel config: https://syzkaller.appspot.com/x/.config?x=df698232b2ac45c9 > dashboard link: https://syzkaller.appspot.com/bug?extid=b2ffafb709f9a29ec5b4 > compiler: Debian clang version 11.0.1-2 > userspace arch: i386 > > Unfortunately, I don't have any reproducer for this issue yet. > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+b2ffafb709f9a29ec...@syzkaller.appspotmail.com +ext4 maintainers > = > BUG: KMSAN: uninit-value in ext4_inode_journal_mode+0x28b/0x4f0 > syzkaller/managers/upstream-kmsan-gce-386/kernel/fs/ext4/ext4_jbd2.c:16 > CPU: 1 PID: 8577 Comm: syz-executor.0 Not tainted 5.10.0-rc4-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack > syzkaller/managers/upstream-kmsan-gce-386/kernel/lib/dump_stack.c:77 [inline] > dump_stack+0x21c/0x280 > syzkaller/managers/upstream-kmsan-gce-386/kernel/lib/dump_stack.c:118 > kmsan_report+0xfb/0x1e0 > syzkaller/managers/upstream-kmsan-gce-386/kernel/mm/kmsan/kmsan_report.c:118 > __msan_warning+0x5f/0xa0 > syzkaller/managers/upstream-kmsan-gce-386/kernel/mm/kmsan/kmsan_instr.c:197 > ext4_inode_journal_mode+0x28b/0x4f0 > syzkaller/managers/upstream-kmsan-gce-386/kernel/fs/ext4/ext4_jbd2.c:16 > ext4_should_journal_data > syzkaller/managers/upstream-kmsan-gce-386/kernel/fs/ext4/ext4_jbd2.h:467 > [inline] > ext4_evict_inode+0x1bb/0x2b30 > syzkaller/managers/upstream-kmsan-gce-386/kernel/fs/ext4/inode.c:201 > evict+0x4b5/0xec0 > syzkaller/managers/upstream-kmsan-gce-386/kernel/fs/inode.c:578 > iput_final syzkaller/managers/upstream-kmsan-gce-386/kernel/fs/inode.c:1654 > [inline] > iput+0xb06/0xec0 > syzkaller/managers/upstream-kmsan-gce-386/kernel/fs/inode.c:1680 > __ext4_new_inode+0x3dd2/0x9c70 > syzkaller/managers/upstream-kmsan-gce-386/kernel/fs/ext4/ialloc.c:1354 > ext4_create+0x47e/0x960 > syzkaller/managers/upstream-kmsan-gce-386/kernel/fs/ext4/namei.c:2619 > lookup_open syzkaller/managers/upstream-kmsan-gce-386/kernel/fs/namei.c:3104 > [inline] > open_last_lookups > syzkaller/managers/upstream-kmsan-gce-386/kernel/fs/namei.c:3178 [inline] > path_openat+0x2b71/0x6a30 > syzkaller/managers/upstream-kmsan-gce-386/kernel/fs/namei.c:3366 > do_filp_open+0x2b8/0x710 > syzkaller/managers/upstream-kmsan-gce-386/kernel/fs/namei.c:3396 > do_sys_openat2+0xa92/0x1150 > syzkaller/managers/upstream-kmsan-gce-386/kernel/fs/open.c:1168 > do_sys_open syzkaller/managers/upstream-kmsan-gce-386/kernel/fs/open.c:1184 > [inline] > __do_compat_sys_openat > syzkaller/managers/upstream-kmsan-gce-386/kernel/fs/open.c:1242 [inline] > __se_compat_sys_openat+0x2ae/0x310 > syzkaller/managers/upstream-kmsan-gce-386/kernel/fs/open.c:1240 > __ia32_compat_sys_openat+0x56/0x70 > syzkaller/managers/upstream-kmsan-gce-386/kernel/fs/open.c:1240 > do_syscall_32_irqs_on > syzkaller/managers/upstream-kmsan-gce-386/kernel/arch/x86/entry/common.c:80 > [inline] > __do_fast_syscall_32+0x102/0x160 > syzkaller/managers/upstream-kmsan-gce-386/kernel/arch/x86/entry/common.c:139 > do_fast_syscall_32+0x6a/0xc0 > syzkaller/managers/upstream-kmsan-gce-386/kernel/arch/x86/entry/common.c:162 > do_SYSENTER_32+0x73/0x90 > syzkaller/managers/upstream-kmsan-gce-386/kernel/arch/x86/entry/common.c:205 > entry_SYSENTER_compat_after_hwframe+0x4d/0x5c > RIP: 0023:0xf7f79549 > Code: 03 74 c0 01 10 05 03 74 b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 > 03 74 d8 01 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 > 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 > RSP: 002b:f55525fc EFLAGS: 0296 ORIG_RAX: 0127 > RAX: ffda RBX: ff9c RCX: 24c0 > RDX: 0042 RSI: 0180 RDI: > RBP: R08: R09: > R10: R11: R12: > R13: R14: R15: > > Uninit was created at: > kmsan_save_stack_with_flags+0x3c/0x90 > syzkaller/managers/upstream-kmsan-gce-386/kernel/mm/kmsan/kmsan.c:121 > kmsan_alloc_page+0xd3/0x1f0 > syzkaller/managers/upstream-kmsan-gce-386/kernel/mm/kmsan/kmsan_shadow.c:274 > __alloc_pages_nodemask+0x827/0xf90 > syzkaller/managers/upstream-kmsan-gce-386/kernel/mm/page_alloc.c:4989 > alloc_pages_current+0x7b6/0xb60 > syzkaller/managers/upstream-kmsan-gce-386/kernel/mm/mempolicy.c:2271 > alloc_pages > syzkaller/managers/upstream-kmsan-gce-386/kernel/./include/linux/gfp.h:547 > [inline] > alloc_slab_
KASAN: use-after-free Read in powermate_config_complete
Hello, syzbot found the following issue on: HEAD commit:5c279c4c Revert "x86/setup: don't remove E820_TYPE_RAM for.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=16aa751b50 kernel config: https://syzkaller.appspot.com/x/.config?x=e83e68d0a6aba5f6 dashboard link: https://syzkaller.appspot.com/bug?extid=cd1a880b2232c9b2c3e2 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+cd1a880b2232c9b2c...@syzkaller.appspotmail.com BUG: MAX_LOCKDEP_CHAINS too low! turning off the locking correctness validator. CPU: 1 PID: 27518 Comm: syz-executor.2 Not tainted 5.11.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x107/0x163 lib/dump_stack.c:120 add_chain_cache kernel/locking/lockdep.c:3456 [inline] lookup_chain_cache_add kernel/locking/lockdep.c:3555 [inline] validate_chain kernel/locking/lockdep.c:3576 [inline] __lock_acquire.cold+0x36f/0x39e kernel/locking/lockdep.c:4832 lock_acquire kernel/locking/lockdep.c:5442 [inline] lock_acquire+0x1a8/0x720 kernel/locking/lockdep.c:5407 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x39/0x50 kernel/locking/spinlock.c:159 stack_depot_save+0x1c9/0x4e0 lib/stackdepot.c:283 kasan_save_stack+0x32/0x40 mm/kasan/common.c:40 kasan_set_track mm/kasan/common.c:46 [inline] set_alloc_info mm/kasan/common.c:401 [inline] kasan_kmalloc.constprop.0+0x7f/0xa0 mm/kasan/common.c:429 kasan_slab_alloc include/linux/kasan.h:209 [inline] slab_post_alloc_hook mm/slab.h:512 [inline] slab_alloc mm/slab.c:3315 [inline] kmem_cache_alloc_trace+0x1b1/0x400 mm/slab.c:3552 kmalloc include/linux/slab.h:552 [inline] dummy_urb_enqueue+0x8a/0x8b0 drivers/usb/gadget/udc/dummy_hcd.c:1253 usb_hcd_submit_urb+0x2b2/0x22d0 drivers/usb/core/hcd.c:1548 usb_submit_urb+0x6e4/0x1540 drivers/usb/core/urb.c:585 powermate_sync_state+0x494/0xac0 drivers/input/misc/powermate.c:189 powermate_config_complete+0x84/0xb0 drivers/input/misc/powermate.c:203 __usb_hcd_giveback_urb+0x2b0/0x5c0 drivers/usb/core/hcd.c:1656 usb_hcd_giveback_urb+0x367/0x410 drivers/usb/core/hcd.c:1726 dummy_timer+0x11f4/0x32a0 drivers/usb/gadget/udc/dummy_hcd.c:1971 call_timer_fn+0x1a5/0x6b0 kernel/time/timer.c:1417 expire_timers kernel/time/timer.c:1462 [inline] __run_timers.part.0+0x67c/0xa50 kernel/time/timer.c:1731 __run_timers kernel/time/timer.c:1712 [inline] run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1744 __do_softirq+0x29b/0x9f6 kernel/softirq.c:343 asm_call_irq_on_stack+0xf/0x20 __run_on_irqstack arch/x86/include/asm/irq_stack.h:26 [inline] run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:77 [inline] do_softirq_own_stack+0xaa/0xd0 arch/x86/kernel/irq_64.c:77 invoke_softirq kernel/softirq.c:226 [inline] __irq_exit_rcu kernel/softirq.c:420 [inline] irq_exit_rcu+0x134/0x200 kernel/softirq.c:432 sysvec_apic_timer_interrupt+0x4d/0x100 arch/x86/kernel/apic/apic.c:1096 asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:629 RIP: 0010:kmem_cache_free+0x75/0x1c0 mm/slab.c:3700 Code: 00 00 4c 89 e6 48 89 ef e8 b8 20 00 00 84 c0 75 0e 4c 89 f2 4c 89 e6 48 89 ef e8 86 c3 ff ff 4d 85 ed 0f 85 ac 00 00 00 53 9d <48> 8b 74 24 28 0f 1f 44 00 00 65 8b 05 6a 5e 4c 7e 83 f8 07 0f 87 RSP: 0018:c9000302f8d8 EFLAGS: 0286 RAX: 85a7 RBX: 0286 RCX: 11b46f39 RDX: RSI: RDI: RBP: 888010c4fc00 R08: 0001 R09: 0001 R10: 8178a708 R11: R12: 888019eaed20 R13: 0200 R14: 8132c949 R15: pgtable_pte_page_dtor include/linux/mm.h:2215 [inline] ___pte_free_tlb+0x19/0x150 arch/x86/mm/pgtable.c:55 __pte_free_tlb arch/x86/include/asm/pgalloc.h:61 [inline] free_pte_range mm/memory.c:220 [inline] free_pmd_range mm/memory.c:238 [inline] free_pud_range mm/memory.c:272 [inline] free_p4d_range mm/memory.c:306 [inline] free_pgd_range+0x498/0xc10 mm/memory.c:386 free_pgtables+0x230/0x2f0 mm/memory.c:418 exit_mmap+0x2c0/0x5a0 mm/mmap.c:3221 __mmput+0x122/0x470 kernel/fork.c:1082 mmput+0x53/0x60 kernel/fork.c:1103 exit_mm kernel/exit.c:501 [inline] do_exit+0xb6a/0x2ae0 kernel/exit.c:812 do_group_exit+0x125/0x310 kernel/exit.c:922 get_signal+0x427/0x20f0 kernel/signal.c:2773 arch_do_signal_or_restart+0x2a8/0x1eb0 arch/x86/kernel/signal.c:811 handle_signal_work kernel/entry/common.c:147 [inline] exit_to_user_mode_loop kernel/entry/common.c:171 [inline] exit_to_user_mode_prepare+0x148/0x250 kernel/entry/common.c:201 __syscall_exit_to_user_mode_work kernel/entry/common.c:291 [inline] syscall_exit_to_user_mode+0x19/0x50 kernel/entry/common.c:302 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0
Re: [PATCH v6 3/3] drm/fourcc: Switch to %p4cc format modifier
On Mon, Feb 8, 2021 at 9:20 PM Sakari Ailus
wrote:
>
> Instead of constructing the FourCC code manually, use the %p4cc printk
> modifier to print it. Also leave a message to avoid using this function.
>
> The next step would be to convert the users to use %p4cc directly instead
> and removing the function.
>
> Signed-off-by: Sakari Ailus
> ---
> drivers/gpu/drm/drm_fourcc.c | 16 +++-
> 1 file changed, 3 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 03262472059c..4ff40f2f27c0 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -30,11 +30,6 @@
> #include
> #include
>
> -static char printable_char(int c)
> -{
> - return isascii(c) && isprint(c) ? c : '?';
> -}
> -
> /**
> * drm_mode_legacy_fb_format - compute drm fourcc code from legacy
> description
> * @bpp: bits per pixels
> @@ -134,17 +129,12 @@ EXPORT_SYMBOL(drm_driver_legacy_fb_format);
> * drm_get_format_name - fill a string with a drm fourcc format's name
> * @format: format to compute name of
> * @buf: caller-supplied buffer
> + *
> + * Please use %p4cc printk format modifier instead of this function.
I think would be nice if we could roll this out and outright delete
this one here ... Quick git grep says there's not that many, and %p4cc
is quite a bit shorter than what we have now.
-Daniel
> */
> const char *drm_get_format_name(uint32_t format, struct drm_format_name_buf
> *buf)
> {
> - snprintf(buf->str, sizeof(buf->str),
> -"%c%c%c%c %s-endian (0x%08x)",
> -printable_char(format & 0xff),
> -printable_char((format >> 8) & 0xff),
> -printable_char((format >> 16) & 0xff),
> -printable_char((format >> 24) & 0x7f),
> -format & DRM_FORMAT_BIG_ENDIAN ? "big" : "little",
> -format);
> + snprintf(buf->str, sizeof(buf->str), "%p4cc", &format);
>
> return buf->str;
> }
> --
> 2.29.2
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v2] ARM: dts: sun5i: Add dts for inet86v_rev2
On Wed, Feb 03, 2021 at 10:21:03AM +0100, Maxime Ripard wrote:
> On Mon, Feb 01, 2021 at 06:18:18PM +0100, agriveaux wrote:
> > On Thu, Jan 28, 2021 at 06:23:29PM +0100, Maxime Ripard wrote:
> > > Hi,
> > Hi,
Hello,
> > >
> > > On Sun, Jan 24, 2021 at 08:39:03PM +0100, Alexandre GRIVEAUX wrote:
> > > > Add Inet 86V Rev 2 support, based upon Inet 86VS.
> > > >
> > > > The Inet 86V use SL1536 touchpanel controller, the Inet 86VS a GSL1680,
> > > > which make them both incompatible.
> > > >
> > > > Missing things:
> > > > - Accelerometer (MXC6225X)
> > > > - Touchpanel (Sitronix SL1536)
> > > > - Nand (29F32G08CBACA)
> > > > - Camera (HCWY0308)
> > > >
> > > > Signed-off-by: Alexandre GRIVEAUX
> > > > ---
> > > > arch/arm/boot/dts/sun5i-a13-inet-86v-rev2.dts | 17 +
> > >
> > > You have to add it to the Makefile
> > >
> > Ok.
> > > > 1 file changed, 17 insertions(+)
> > > > create mode 100644 arch/arm/boot/dts/sun5i-a13-inet-86v-rev2.dts
> > > >
> > > > diff --git a/arch/arm/boot/dts/sun5i-a13-inet-86v-rev2.dts
> > > > b/arch/arm/boot/dts/sun5i-a13-inet-86v-rev2.dts
> > > > new file mode 100644
> > > > index ..581083e932d8
> > > > --- /dev/null
> > > > +++ b/arch/arm/boot/dts/sun5i-a13-inet-86v-rev2.dts
> > > > @@ -0,0 +1,17 @@
> > > > +// SPDX-License-Identifier: GPL-2.0+
> > > > +/*
> > > > + * Copyright 2021 Alexandre Griveaux
> > > > + *
> > > > + * Minimal dts file for the iNet 86V
> > > > + */
> > > > +
> > > > +/dts-v1/;
> > > > +
> > > > +#include "sun5i-a13.dtsi"
> > > > +#include "sun5i-reference-design-tablet.dtsi"
> > > > +
> > > > +/ {
> > > > + model = "iNET 86V Rev 02";
> > > > + compatible = "inet,86v-rev2", "allwinner,sun5i-a13";
> > >
> > > inet should be documented in the vendor prefixes, and that compatible
> > > should be documented in Documentation/devicetree/bindings/arm/sunxi.yaml
> > >
> >
> > I forgot, but should be:
> >
> > - description: iNet-86V Rev 02
> > items:
> > - const: primux,inet86v-rev2
> > - const: allwinner,sun5i-a13
> >
> > > Having the first rev compatible would be good too
> >
> > Unfortunatly, I didn't find inet86v rev1 on FCC website and on
> > linux-sunxi.
> >
> > >
> > > > +
> > > > +};
> > >
> > > But I'm wondering. If there's nothing here to add, why would we need
> > > that DT in the first place?
> > >
> > I prefer to add often instead of bulk adding, and to show there are some
> > board to add missing things like those above.
>
> Yeah, I get that, but the point really is that you're not really adding
> anything here except an empty device tree.
>
> Maxime
In this case, I keep this patch to send it when I have more to add .
Thanks.
Re: [PATCH v1 1/2] irqchip/gic-v3-its: don't set bitmap for LPI which user didn't allocate
On 2021/2/8 19:59, Marc Zyngier wrote:
On 2021-02-08 10:58, Luo Jiaxing wrote:
The driver sets the LPI bitmap of device based on
get_count_order(nvecs).
This means that when the number of LPI interrupts does not meet the
power
of two, redundant bits are set in the LPI bitmap. However, when free
interrupt, these redundant bits is not cleared. As a result, device will
fails to allocate the same numbers of interrupts next time.
Therefore, clear the redundant bits set in LPI bitmap.
Fixes: 4615fbc3788d ("genirq/irqdomain: Don't try to free an interrupt
that has no mapping")
Signed-off-by: Luo Jiaxing
---
drivers/irqchip/irq-gic-v3-its.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/irqchip/irq-gic-v3-its.c
b/drivers/irqchip/irq-gic-v3-its.c
index ed46e60..027f7ef 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -3435,6 +3435,10 @@ static int its_alloc_device_irq(struct
its_device *dev, int nvecs, irq_hw_number
*hwirq = dev->event_map.lpi_base + idx;
+ bitmap_clear(dev->event_map.lpi_map,
+ idx + nvecs,
+ roundup_pow_of_two(nvecs) - nvecs);
+
return 0;
}
What makes you think that the remaining LPIs are free to be released?
I think that the LPI bitmap is used to mark the valid LPI interrupts
allocated to the PCIe device.
Therefore, for the remaining LPIs, the ITS can reserve entries in the
ITT table, but the bitmap does not need to be set.
Maybe my understanding is wrong, and I'm a little confused about the
function of this bitmap.
Even if the end-point has request a non-po2 number of MSIs, it could
very well rely on the the rest of it to be available (specially in the
case of PCI Multi-MSI).
yes, you are right. But for Multi-MSI, does it mean that one PCIE device
can own several MSI interrupts?
Another question, is it possible for module driver to use these
remaining LPIs?
For example, in my case
I allcoate 32 MSI with 16 affi-IRQ in it.
MSI can only offer 20 MSIs because online CPU number is 4 and it create
20 msi desc then.
ITS create a its device for this PCIe device and generate a ITT tabel
for 32 MSIs.
so in MSI, it provide 20 valid MSIs, but in ITS, lpi bitmap show that 32
MSI is allocated.
This logic is a bit strange and a little incomprehensible.
Have a look at the thread pointed out by John for a potential fix.
Sorry for missing that, I think it can fix my issue too, let me test it
later.
Thanks
jiaxing
Thanks,
M.
Re: [PATCH] carl9170: fix struct alignment conflict
Arnd Bergmann wrote: > Multiple structures in the carl9170 driver have alignment > impossible alignment constraints that gcc warns about when > building with 'make W=1': > > drivers/net/wireless/ath/carl9170/fwcmd.h:243:2: warning: alignment 1 of > 'union ' is less than 4 [-Wpacked-not-aligned] > drivers/net/wireless/ath/carl9170/wlan.h:373:1: warning: alignment 1 of > 'struct ar9170_rx_frame_single' is less than 2 [-Wpacked-not-aligned] > > In the carl9170_cmd structure, multiple members that have an explicit > alignment requirement of four bytes are added into a union with explicit > byte alignment, but this in turn is part of a structure that also has > four-byte alignment. > > In the wlan.h header, multiple structures contain a ieee80211_hdr member > that is required to be two-byte aligned to avoid alignmnet faults when > processing network headers, but all members are forced to be byte-aligned > using the __packed tag at the end of the struct definition. > > In both cases, leaving out the packing does not change the internal > layout of the structure but changes the alignment constraint of the > structure itself. > > Change all affected structures to only apply packing where it does > not violate the alignment requirement of the contained structure. > > Signed-off-by: Arnd Bergmann > Acked-by: Christian Lamparter > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. ca9ad549e404 carl9170: fix struct alignment conflict -- https://patchwork.kernel.org/project/linux-wireless/patch/20210204162926.3262598-1-a...@kernel.org/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [RFC PATCH 2/2] KVM: selftests: Add a test for kvm page table code
Hi Ben, On 2021/2/9 4:29, Ben Gardon wrote: On Mon, Feb 8, 2021 at 1:08 AM Yanan Wang wrote: This test serves as a performance tester and a bug reproducer for kvm page table code (GPA->HPA mappings), so it gives guidance for people trying to make some improvement for kvm. The function guest_code() is designed to cover conditions where a single vcpu or multiple vcpus access guest pages within the same memory range, in three VM stages(before dirty-logging, during dirty-logging, after dirty-logging). Besides, the backing source memory type(ANONYMOUS/THP/HUGETLB) of the tested memory region can be specified by users, which means normal page mappings or block mappings can be chosen by users to be created in the test. If use of ANONYMOUS memory is specified, kvm will create page mappings for the tested memory region before dirty-logging, and update attributes of the page mappings from RO to RW during dirty-logging. If use of THP/HUGETLB memory is specified, kvm will create block mappings for the tested memory region before dirty-logging, and split the blcok mappings into page mappings during dirty-logging, and coalesce the page mappings back into block mappings after dirty-logging is stopped. So in summary, as a performance tester, this test can present the performance of kvm creating/updating normal page mappings, or the performance of kvm creating/splitting/recovering block mappings, through execution time. When we need to coalesce the page mappings back to block mappings after dirty logging is stopped, we have to firstly invalidate *all* the TLB entries for the page mappings right before installation of the block entry, because a TLB conflict abort error could occur if we can't invalidate the TLB entries fully. We have hit this TLB conflict twice on aarch64 software implementation and fixed it. As this test can imulate process from dirty-logging enabled to dirty-logging stopped of a VM with block mappings, so it can also reproduce this TLB conflict abort due to inadequate TLB invalidation when coalescing tables. Signed-off-by: Yanan Wang Thanks for sending this! Happy to see more tests for weird TLB flushing edge cases and races. Just out of curiosity, were you unable to replicate the bug with the dirty_log_perf_test and setting the wr_fract option? With "KVM: selftests: Disable dirty logging with vCPUs running" (https://lkml.org/lkml/2021/2/2/1431), the dirty_log_perf_test has most of the same features as this one. Please correct me if I'm wrong, but it seems like the major difference here is a more careful pattern of which pages are dirtied when. Actually the procedures in KVM_UPDATE_MAPPINGS stage are specially designed for reproduce of the TLB conflict bug. The following explains why. In x86 implementation, the related page mappings will be all destroyed in advance when stopping dirty logging while vcpus are still running. So after dirty logging is successfully stopped, there will certainly be page faults when accessing memory, and KVM will handle the faults and create block mappings once again. (Is this right?) So in this case, dirty_log_perf_test can replicate the bug theoretically. But there is difference in ARM implementation. The related page mappings will not be destroyed immediately when stopping dirty logging and will be kept instead. And after dirty logging, KVM will destroy these mappings together with creation of block mappings when handling a guest fault (page fault or permission fault). So based on guest_code() in dirty_log_perf_test, there will not be any page faults after dirty logging because all the page mappings have been created and KVM has no chance to recover block mappings at all. So this is why I left half of the pages clean and another half dirtied. Within Google we have a system for pre-specifying sets of arguments to e.g. the dirty_log_perf_test. I wonder if something similar, even as simple as a script that just runs dirty_log_perf_test several times would be helpful for cases where different arguments are needed for the test to cover different specific cases. Even with this test, for I not sure I have got your point :), but it depends on what exactly the specific cases are, and sometimes we have to use different arguments. Is this right? example, I assume the test doesn't work very well with just 1 vCPU, but it's still a good default in the test, so having some kind of configuration (lite) file would be useful. Actually it's only with 1 vCPU that the real efficiency of KVM page table code path can be tested, such as efficiency of creating new mappings or efficiency of updating existing mappings. And with numerous vCPUs, efficiency of KVM handling concurrent conditions can be tested. --- tools/testing/selftests/kvm/Makefile | 3 + .../selftests/kvm/kvm_page_table_test.c | 518 ++ 2 files changed, 521 insertions(+) create mode 100644 tools/testing/selftests/kvm/kvm_page_table_test.c diff --git a/tools
Re: [PATCH] ath10k: Fix lockdep assertion warning in ath10k_sta_statistics
Anand K Mistry wrote:
> ath10k_debug_fw_stats_request just be called with conf_mutex held,
> otherwise the following warning is seen when lock debugging is enabled:
>
> WARNING: CPU: 0 PID: 793 at drivers/net/wireless/ath/ath10k/debug.c:357
> ath10k_debug_fw_stats_request+0x12c/0x133 [ath10k_core]
> Modules linked in: snd_hda_codec_hdmi designware_i2s snd_hda_intel
> snd_intel_dspcfg snd_hda_codec i2c_piix4 snd_hwdep snd_hda_core acpi_als
> kfifo_buf industrialio snd_soc_max98357a snd_soc_adau7002
> snd_soc_acp_da7219mx98357_mach snd_soc_da7219 acp_audio_dma ccm xt_MASQUERADE
> fuse ath10k_pci ath10k_core lzo_rle ath lzo_compress mac80211 zram cfg80211
> r8152 mii joydev
> CPU: 0 PID: 793 Comm: wpa_supplicant Tainted: GW 5.10.9 #5
> Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.104.0 09/05/2019
> RIP: 0010:ath10k_debug_fw_stats_request+0x12c/0x133 [ath10k_core]
> Code: 1e bb a1 ff ff ff 4c 89 ef 48 c7 c6 d3 31 2e c0 89 da 31 c0 e8 bd f8 ff
> ff 89 d8 eb 02 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 <0f> 0b e9 04 ff ff ff
> 0f 1f 44 00 00 55 48 89 e5 41 56 53 48 89 fb
> RSP: 0018:b2478099f7d0 EFLAGS: 00010246
> RAX: RBX: 9e432700cce0 RCX: 11c85cfd6b8e3b00
> RDX: 9e432700cce0 RSI: 9e43127c5668 RDI: 9e4318deddf0
> RBP: b2478099f7f8 R08: 0002 R09: 0003fd7068cc
> R10: c01b2749 R11: c029efaf R12: 9e432700c000
> R13: 9e43127c33e0 R14: b2478099f918 R15: 9e43127c33e0
> FS: 7f7ea48e2740() GS:9e432aa0() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 59aa799ddf38 CR3: 000118de2000 CR4: 001506f0
> Call Trace:
> ath10k_sta_statistics+0x4d/0x270 [ath10k_core]
> sta_set_sinfo+0x1be/0xaec [mac80211]
> ieee80211_get_station+0x58/0x76 [mac80211]
> rdev_get_station+0xf1/0x11e [cfg80211]
> nl80211_get_station+0x7f/0x146 [cfg80211]
> genl_rcv_msg+0x32e/0x35e
> ? nl80211_stop_ap+0x19/0x19 [cfg80211]
> ? nl80211_get_station+0x146/0x146 [cfg80211]
> ? genl_rcv+0x19/0x36
> ? genl_rcv+0x36/0x36
> netlink_rcv_skb+0x89/0xfb
> genl_rcv+0x28/0x36
> netlink_unicast+0x169/0x23b
> netlink_sendmsg+0x38a/0x402
> sock_sendmsg+0x72/0x76
> sys_sendmsg+0x153/0x1cc
> ? copy_msghdr_from_user+0x5d/0x85
> ___sys_sendmsg+0x7c/0xb5
> ? lock_acquire+0x181/0x23d
> ? syscall_trace_enter+0x15e/0x160
> ? find_held_lock+0x3d/0xb2
> ? syscall_trace_enter+0x15e/0x160
> ? sched_clock_cpu+0x15/0xc6
> __sys_sendmsg+0x62/0x9a
> do_syscall_64+0x43/0x55
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> Fixes: 4913e675630e ("ath10k: enable rx duration report default for wmi tlv")
> Signed-off-by: Anand K Mistry
> Signed-off-by: Kalle Valo
Patch applied to ath-next branch of ath.git, thanks.
7df28718928d ath10k: Fix lockdep assertion warning in ath10k_sta_statistics
--
https://patchwork.kernel.org/project/linux-wireless/patch/20210202144033.1.I9e556f9fb1110d58c31d04a8a1293995fb8bb678@changeid/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] ath10k: Fix suspicious RCU usage warning in ath10k_wmi_tlv_parse_peer_stats_info()
Anand K Mistry wrote:
> The ieee80211_find_sta_by_ifaddr call in
> ath10k_wmi_tlv_parse_peer_stats_info must be called while holding the
> RCU read lock. Otherwise, the following warning will be seen when RCU
> usage checking is enabled:
>
> =
> WARNING: suspicious RCU usage
> 5.10.3 #8 Tainted: GW
> -
> include/linux/rhashtable.h:594 suspicious rcu_dereference_check() usage!
>
> other info that might help us debug this:
>
> rcu_scheduler_active = 2, debug_locks = 1
> no locks held by ksoftirqd/1/16.
>
> stack backtrace:
> CPU: 1 PID: 16 Comm: ksoftirqd/1 Tainted: GW 5.10.3 #8
> Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.104.0 09/05/2019
> Call Trace:
> dump_stack+0xab/0x115
> sta_info_hash_lookup+0x71/0x1e9 [mac80211]
> ? lock_is_held_type+0xe6/0x12f
> ? __kasan_kmalloc+0xfb/0x112
> ieee80211_find_sta_by_ifaddr+0x12/0x61 [mac80211]
> ath10k_wmi_tlv_parse_peer_stats_info+0xbd/0x10b [ath10k_core]
> ath10k_wmi_tlv_iter+0x8b/0x1a1 [ath10k_core]
> ? ath10k_wmi_tlv_iter+0x1a1/0x1a1 [ath10k_core]
> ath10k_wmi_tlv_event_peer_stats_info+0x103/0x13b [ath10k_core]
> ath10k_wmi_tlv_op_rx+0x722/0x80d [ath10k_core]
> ath10k_htc_rx_completion_handler+0x16e/0x1d7 [ath10k_core]
> ath10k_pci_process_rx_cb+0x116/0x22c [ath10k_pci]
> ? ath10k_htc_process_trailer+0x332/0x332 [ath10k_core]
> ? _raw_spin_unlock_irqrestore+0x34/0x61
> ? lockdep_hardirqs_on+0x8e/0x12e
> ath10k_ce_per_engine_service+0x55/0x74 [ath10k_core]
> ath10k_ce_per_engine_service_any+0x76/0x84 [ath10k_core]
> ath10k_pci_napi_poll+0x49/0x141 [ath10k_pci]
> net_rx_action+0x11a/0x347
> __do_softirq+0x2d3/0x539
> run_ksoftirqd+0x4b/0x86
> smpboot_thread_fn+0x1d0/0x2ab
> ? cpu_report_death+0x7f/0x7f
> kthread+0x189/0x191
> ? cpu_report_death+0x7f/0x7f
> ? kthread_blkcg+0x31/0x31
> ret_from_fork+0x22/0x30
>
> Fixes: 0f7cb26830a6e ("ath10k: add rx bitrate report for SDIO")
> Signed-off-by: Anand K Mistry
> Signed-off-by: Kalle Valo
Patch applied to ath-next branch of ath.git, thanks.
2615e3cdbd9c ath10k: Fix suspicious RCU usage warning in
ath10k_wmi_tlv_parse_peer_stats_info()
--
https://patchwork.kernel.org/project/linux-wireless/patch/20210202134451.1.I0d2e83c42755671b7143504b62787fd06cd914ed@changeid/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: Migration to trusted keys: sealing user-provided key?
On Mon, 2021-02-08 at 16:50 -0500, Mimi Zohar wrote: > On Mon, 2021-02-08 at 15:38 +0100, Jan Lübbe wrote: > > > As it seems that this feature would not be appropriate for all use-cases and > > threat models, I wonder if making it optional would be acceptable. Something > > like: > > > > config TRUSTED_KEYS_IMPORT > > To me "IMPORT" implies from a trusted source, which this is not. > Perhaps "UNSAFE_IMPORT", "DEBUGGING_IMPORT, "DEVELOPMENT_IMPORT", ... > > Defining a Kconfig with any of these names and the other changes below, > makes it very clear using predefined key data is not recommended. My > concern with extending trusted keys to new trust sources is the > implication that the security/integrity is equivalent to the existing > discrete TPM. > > > bool "Allow creating TRUSTED KEYS from existing key material" > > depends on TRUSTED_KEYS > > Missing "default n" According to Documentation/kbuild/kconfig-language.rst: "The default value deliberately defaults to 'n' in order to avoid bloating the build.". So an explicit "default n" should not be needed. I'll add it though, for now. > > help > > This option adds support for creating new trusted keys from > > existing > > key material supplied by userspace, instead of using random > > numbers. > > As with random trusted keys, userspace cannot extract the plain- > > text > > Once defined, as with random trusted keys, userspace cannot ... > > > key material again and will only ever see encrypted blobs. > > > > > > This option should *only* be enabled for use in a trusted > > environment (such as during debugging/development or in a secured > > factory). Also, consider using 'keyctl padd' instead of 'keyctl > > add' > > Even the "secured factory" is not a good idea. Please limit the usage > to debugging/development. > > > to avoid exposing the plain-text key on the process command line. > > > > If you are unsure as to whether this is required, answer N. > > The above would be fine. OK, that would result in: config TRUSTED_KEYS_DEVELOPMENT_IMPORT bool "Allow creating TRUSTED KEYS from existing key material for development" depends on TRUSTED_KEYS default n help This option adds support for creating new trusted keys from existing key material supplied by userspace, instead of using random numbers. Once defined, as with random trusted keys, userspace cannot extract the plain-text key material again and will only ever see encrypted blobs. This option should *only* be enabled for debugging/development. Also, consider using 'keyctl padd' instead of 'keyctl add' to avoid exposing the plain-text key on the process command line. If you are unsure as to whether this is required, answer N. Thanks, Jan -- 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- |
[PATCH] psi: Optimize task switch inside shared cgroups
The commit 36b238d57172 ("psi: Optimize switching tasks inside shared
cgroups") only update cgroups whose state actually changes during a
task switch only in task preempt case, not in task sleep case.
We actually don't need to clear and set TSK_ONCPU state for common cgroups
of next and prev task in sleep case, that can save many psi_group_change
especially when most activity comes from one leaf cgroup.
Signed-off-by: Muchun Song
Signed-off-by: Chengming Zhou
---
kernel/sched/psi.c | 27 +--
kernel/sched/stats.h | 17 +++--
2 files changed, 20 insertions(+), 24 deletions(-)
diff --git a/kernel/sched/psi.c b/kernel/sched/psi.c
index 6e46d9eb279b..6061e87089ac 100644
--- a/kernel/sched/psi.c
+++ b/kernel/sched/psi.c
@@ -836,20 +836,27 @@ void psi_task_switch(struct task_struct *prev, struct
task_struct *next,
}
}
- /*
-* If this is a voluntary sleep, dequeue will have taken care
-* of the outgoing TSK_ONCPU alongside TSK_RUNNING already. We
-* only need to deal with it during preemption.
-*/
- if (sleep)
- return;
-
if (prev->pid) {
- psi_flags_change(prev, TSK_ONCPU, 0);
+ int clear = 0, set = 0;
+
+ if (sleep) {
+ clear |= TSK_RUNNING;
+ if (prev->in_iowait)
+ set |= TSK_IOWAIT;
+ }
+
+ psi_flags_change(prev, clear | TSK_ONCPU, set);
iter = NULL;
while ((group = iterate_groups(prev, &iter)) && group != common)
- psi_group_change(group, cpu, TSK_ONCPU, 0, true);
+ psi_group_change(group, cpu, clear | TSK_ONCPU, set,
true);
+
+ if (sleep) {
+ while (group) {
+ psi_group_change(group, cpu, clear, set, true);
+ group = iterate_groups(prev, &iter);
+ }
+ }
}
}
diff --git a/kernel/sched/stats.h b/kernel/sched/stats.h
index 9e4e67a94731..2d92c8467678 100644
--- a/kernel/sched/stats.h
+++ b/kernel/sched/stats.h
@@ -84,28 +84,17 @@ static inline void psi_enqueue(struct task_struct *p, bool
wakeup)
static inline void psi_dequeue(struct task_struct *p, bool sleep)
{
- int clear = TSK_RUNNING, set = 0;
-
if (static_branch_likely(&psi_disabled))
return;
if (!sleep) {
+ int clear = TSK_RUNNING;
+
if (p->in_memstall)
clear |= TSK_MEMSTALL;
- } else {
- /*
-* When a task sleeps, schedule() dequeues it before
-* switching to the next one. Merge the clearing of
-* TSK_RUNNING and TSK_ONCPU to save an unnecessary
-* psi_task_change() call in psi_sched_switch().
-*/
- clear |= TSK_ONCPU;
- if (p->in_iowait)
- set |= TSK_IOWAIT;
+ psi_task_change(p, clear, 0);
}
-
- psi_task_change(p, clear, set);
}
static inline void psi_ttwu_dequeue(struct task_struct *p)
--
2.11.0
[PATCH v2] mm/hugetlb: Remove unnecessary VM_BUG_ON_PAGE on putback_active_hugepage()
All callers know they are operating on a hugetlb head page. So this
VM_BUG_ON_PAGE can not catch anything useful.
Signed-off-by: Miaohe Lin
---
mm/hugetlb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 06719fdf9fd6..cfa06fd1b8d7 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -5577,7 +5577,6 @@ bool isolate_huge_page(struct page *page, struct
list_head *list)
void putback_active_hugepage(struct page *page)
{
- VM_BUG_ON_PAGE(!PageHead(page), page);
spin_lock(&hugetlb_lock);
SetHPageMigratable(page);
list_move_tail(&page->lru, &(page_hstate(page))->hugepage_activelist);
--
2.19.1
[PATCH v2] psi: Remove the redundant psi_task_tick
When the current task in a cgroup is in_memstall, the corresponding groupc
on that cpu is in PSI_MEM_FULL state, so we can exploit that to remove the
redundant psi_task_tick from scheduler_tick to save this periodic cost.
Signed-off-by: Muchun Song
Signed-off-by: Chengming Zhou
---
include/linux/psi.h | 1 -
kernel/sched/core.c | 1 -
kernel/sched/psi.c | 49 ++---
kernel/sched/stats.h | 9 -
4 files changed, 14 insertions(+), 46 deletions(-)
diff --git a/include/linux/psi.h b/include/linux/psi.h
index 7361023f3fdd..65eb1476ac70 100644
--- a/include/linux/psi.h
+++ b/include/linux/psi.h
@@ -20,7 +20,6 @@ void psi_task_change(struct task_struct *task, int clear, int
set);
void psi_task_switch(struct task_struct *prev, struct task_struct *next,
bool sleep);
-void psi_memstall_tick(struct task_struct *task, int cpu);
void psi_memstall_enter(unsigned long *flags);
void psi_memstall_leave(unsigned long *flags);
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 15d2562118d1..31788a9b335b 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4533,7 +4533,6 @@ void scheduler_tick(void)
update_thermal_load_avg(rq_clock_thermal(rq), rq, thermal_pressure);
curr->sched_class->task_tick(rq, curr, 0);
calc_global_load_tick(rq);
- psi_task_tick(rq);
rq_unlock(rq, &rf);
diff --git a/kernel/sched/psi.c b/kernel/sched/psi.c
index 2293c45d289d..6e46d9eb279b 100644
--- a/kernel/sched/psi.c
+++ b/kernel/sched/psi.c
@@ -644,8 +644,7 @@ static void poll_timer_fn(struct timer_list *t)
wake_up_interruptible(&group->poll_wait);
}
-static void record_times(struct psi_group_cpu *groupc, int cpu,
-bool memstall_tick)
+static void record_times(struct psi_group_cpu *groupc, int cpu)
{
u32 delta;
u64 now;
@@ -664,23 +663,6 @@ static void record_times(struct psi_group_cpu *groupc, int
cpu,
groupc->times[PSI_MEM_SOME] += delta;
if (groupc->state_mask & (1 << PSI_MEM_FULL))
groupc->times[PSI_MEM_FULL] += delta;
- else if (memstall_tick) {
- u32 sample;
- /*
-* Since we care about lost potential, a
-* memstall is FULL when there are no other
-* working tasks, but also when the CPU is
-* actively reclaiming and nothing productive
-* could run even if it were runnable.
-*
-* When the timer tick sees a reclaiming CPU,
-* regardless of runnable tasks, sample a FULL
-* tick (or less if it hasn't been a full tick
-* since the last state change).
-*/
- sample = min(delta, (u32)jiffies_to_nsecs(1));
- groupc->times[PSI_MEM_FULL] += sample;
- }
}
if (groupc->state_mask & (1 << PSI_CPU_SOME)) {
@@ -714,7 +696,7 @@ static void psi_group_change(struct psi_group *group, int
cpu,
*/
write_seqcount_begin(&groupc->seq);
- record_times(groupc, cpu, false);
+ record_times(groupc, cpu);
for (t = 0, m = clear; m; m &= ~(1 << t), t++) {
if (!(m & (1 << t)))
@@ -738,6 +720,18 @@ static void psi_group_change(struct psi_group *group, int
cpu,
if (test_state(groupc->tasks, s))
state_mask |= (1 << s);
}
+
+ /*
+* Since we care about lost potential, a memstall is FULL
+* when there are no other working tasks, but also when
+* the CPU is actively reclaiming and nothing productive
+* could run even if it were runnable. So when the current
+* task in a cgroup is in_memstall, the corresponding groupc
+* on that cpu is in PSI_MEM_FULL state.
+*/
+ if (groupc->tasks[NR_ONCPU] && cpu_curr(cpu)->in_memstall)
+ state_mask |= (1 << PSI_MEM_FULL);
+
groupc->state_mask = state_mask;
write_seqcount_end(&groupc->seq);
@@ -859,21 +853,6 @@ void psi_task_switch(struct task_struct *prev, struct
task_struct *next,
}
}
-void psi_memstall_tick(struct task_struct *task, int cpu)
-{
- struct psi_group *group;
- void *iter = NULL;
-
- while ((group = iterate_groups(task, &iter))) {
- struct psi_group_cpu *groupc;
-
- groupc = per_cpu_ptr(group->pcpu, cpu);
- write_seqcount_begin(&groupc->seq);
- record_times(groupc, cpu, true);
- write_seqcount_end(&groupc->seq);
- }
-}
-
/**
* psi_memstall_enter - mark the beginning of a memory stall section
* @flags: flags to handle nested sections
diff --git a/kernel/sched/stats.h b/kernel/sch
Re: [PATCH 5.10 000/120] 5.10.15-rc1 review
On Tue, 9 Feb 2021 at 12:22, Rolf Eike Beer wrote: > > Am Dienstag, 9. Februar 2021, 03:31:44 CET schrieb Naresh Kamboju: > > On Mon, 8 Feb 2021 at 20:44, Greg Kroah-Hartman > > > > wrote: > > > This is the start of the stable review cycle for the 5.10.15 release. > > > There are 120 patches in this series, all will be posted as a response > > > to this one. If anyone has any issues with these being applied, please > > > let me know. > > > > > > Responses should be made by Wed, 10 Feb 2021 14:57:55 +. > > > Anything received after that time might be too late. > > > > > > The whole patch series can be found in one patch at: > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5 > > > .10.15-rc1.gz> > > > or in the git tree and branch at: > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable- > > > rc.git linux-5.10.y> > > > and the diffstat can be found below. > > > > > > thanks, > > > > > > greg k-h > > > > Due to the patch below, the x86_64 build breaks with gcc 7.3.x > > This issue is specific to openembedded kernel builder. > > > > We have also noticed on mainline, Linux next and now on stable-rc 5.10. > > > > collect2: error: ld returned 1 exit status > > make[2]: *** [scripts/Makefile.host:95: scripts/extract-cert] Error 1 > > > > ref: > > Build failure link, > > https://ci.linaro.org/view/lkft/job/openembedded-lkft-linux-stable-rc-5.10/D > > ISTRO=lkft,MACHINE=intel-corei7-64,label=docker-buster-lkft/64/consoleText > > Is this part relevant or does that always happen with your builder. > > | /srv/oe/build/tmp-lkft-glibc/hosttools/ld: cannot find /lib/libc.so.6 inside > / > | /srv/oe/build/tmp-lkft-glibc/hosttools/ld: cannot find /usr/lib/ > libc_nonshared.a inside / > | /srv/oe/build/tmp-lkft-glibc/hosttools/ld: cannot find /lib/ld-linux- > x86-64.so.2 inside / > > Can you provide a log with V=1 where we can see what actually is going on? Daniel Díaz sent a fix patch on the stable mailing list. [PATCH] scripts: Fix linking extract-cert against libcrypto https://lore.kernel.org/stable/20210209050047.1958473-1-daniel.d...@linaro.org/T/#u - Naresh
[PATCH] kunit: tool: Disable PAGE_POISONING under --alltests
kunit_tool maintains a list of config options which are broken under
UML, which we exclude from an otherwise 'make ARCH=um allyesconfig'
build used to run all tests with the --alltests option.
Something in UML allyesconfig is causing segfaults when page poisining
is enabled (and is poisoning with a non-zero value). Previously, this
didn't occur, as allyesconfig enabled the CONFIG_PAGE_POISONING_ZERO
option, which worked around the problem by zeroing memory. This option
has since been removed, and memory is now poisoned with 0xAA, which
triggers segfaults in many different codepaths, preventing UML from
booting.
Note that we have to disable both CONFIG_PAGE_POISONING and
CONFIG_DEBUG_PAGEALLOC, as the latter will 'select' the former on
architectures (such as UML) which don't implement __kernel_map_pages().
Ideally, we'd fix this properly by tracking down the real root cause,
but since this is breaking KUnit's --alltests feature, it's worth
disabling there in the meantime so the kernel can boot to the point
where tests can actually run.
Fixes: f289041ed4 ("mm, page_poison: remove CONFIG_PAGE_POISONING_ZERO")
Signed-off-by: David Gow
---
As described above, 'make ARCH=um allyesconfig' is broken. KUnit has
been maintaining a list of configs to force-disable for this in
tools/testing/kunit/configs/broken_on_uml.config. The kernels we've
built with this have broken since CONFIG_PAGE_POISONING_ZERO was
removed, panic-ing on startup with:
<0>[0.10][ T11] Kernel panic - not syncing: Segfault with no mm
<4>[0.10][ T11] CPU: 0 PID: 11 Comm: kdevtmpfs Not tainted
5.11.0-rc7-3-g63381dc6f5f1-dirty #4
<4>[0.10][ T11] Stack:
<4>[0.10][ T11] 677d3d40 677d3f10 000e 600c0bc0
<4>[0.10][ T11] 677d3d90 603c99be 677d3d90 62529b93
<4>[0.10][ T11] 603c9ac0 677d3f10 62529b00 603c98a0
<4>[0.10][ T11] Call Trace:
<4>[0.10][ T11] [<600c0bc0>] ? set_signals+0x0/0x60
<4>[0.10][ T11] [<603c99be>] lookup_mnt+0x11e/0x220
<4>[0.10][ T11] [<62529b93>] ? down_write+0x93/0x180
<4>[0.10][ T11] [<603c9ac0>] ? lock_mount+0x0/0x160
<4>[0.10][ T11] [<62529b00>] ? down_write+0x0/0x180
<4>[0.10][ T11] [<603c98a0>] ? lookup_mnt+0x0/0x220
<4>[0.10][ T11] [<603c8160>] ? namespace_unlock+0x0/0x1a0
<4>[0.10][ T11] [<603c9b25>] lock_mount+0x65/0x160
<4>[0.10][ T11] [<6012f360>] ? up_write+0x0/0x40
<4>[0.10][ T11] [<603cbbd2>] do_new_mount_fc+0xd2/0x220
<4>[0.10][ T11] [<603eb560>] ? vfs_parse_fs_string+0x0/0xa0
<4>[0.10][ T11] [<603cbf04>] do_new_mount+0x1e4/0x260
<4>[0.10][ T11] [<603ccae9>] path_mount+0x1c9/0x6e0
<4>[0.10][ T11] [<603a9f4f>] ? getname_kernel+0xaf/0x1a0
<4>[0.10][ T11] [<603ab280>] ? kern_path+0x0/0x60
<4>[0.10][ T11] [<600238ee>] 0x600238ee
<4>[0.10][ T11] [<62523baa>] devtmpfsd+0x52/0xb8
<4>[0.10][ T11] [<62523b58>] ? devtmpfsd+0x0/0xb8
<4>[0.10][ T11] [<600fffd8>] kthread+0x1d8/0x200
<4>[0.10][ T11] [<600a4ea6>] new_thread_handler+0x86/0xc0
Disabling PAGE_POISONING fixes this. The issue can't be repoduced with
just PAGE_POISONING, there's clearly something (or several things) also
enabled by allyesconfig which contribute. Ideally, we'd track these down
and fix this at its root cause, but in the meantime it'd be nice to
disable PAGE_POISONING so we can at least get the kernel to boot. One
way would be to add a 'depends on !UML' or similar, but since
PAGE_POISONING does seem to work in the non-allyesconfig case, adding it
to our list of broken configs seemed the better choice.
Thoughts?
(Note that to reproduce this, you'll want to run
./tools/testing/kunit/kunit.py run --alltests --raw_output
It also depends on a couple of other fixes which are not upstream yet:
https://www.spinics.net/lists/linux-rtc/msg08294.html
https://lore.kernel.org/linux-i3c/20210127040636.1535722-1-david...@google.com/
Cheers,
-- David
tools/testing/kunit/configs/broken_on_uml.config | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/testing/kunit/configs/broken_on_uml.config
b/tools/testing/kunit/configs/broken_on_uml.config
index a7f0603d33f6..690870043ac0 100644
--- a/tools/testing/kunit/configs/broken_on_uml.config
+++ b/tools/testing/kunit/configs/broken_on_uml.config
@@ -40,3 +40,5 @@
# CONFIG_RESET_BRCMSTB_RESCAL is not set
# CONFIG_RESET_INTEL_GW is not set
# CONFIG_ADI_AXI_ADC is not set
+# CONFIG_DEBUG_PAGEALLOC is not set
+# CONFIG_PAGE_POISONING is not set
--
2.30.0.478.g8a0d178c01-goog
Re: [PATCH v2] printk: Userspace format enumeration support
On Tue, Feb 09, 2021 at 04:37:19AM +, Chris Down wrote:
> +
> + file = debugfs_create_file(ps_get_module_name(ps), 0444, dfs_formats,
> +mod, &dfs_formats_fops);
> +
> + if (IS_ERR_OR_NULL(file))
How can file ever be NULL?
And if it is an error, what is the problem here? You can always feed
the output of a debugfs_* call back into debugfs, and you never need to
check the return values.
> + ps->file = NULL;
> + else
> + ps->file = file;
> +}
> +
> +#ifdef CONFIG_MODULES
> +static void remove_printk_fmt_sec(struct module *mod)
> +{
> + struct printk_fmt_sec *ps = NULL;
> +
> + if (WARN_ON_ONCE(!mod))
> + return;
> +
> + mutex_lock(&printk_fmts_mutex);
> +
> + ps = find_printk_fmt_sec(mod);
> + if (!ps) {
> + mutex_unlock(&printk_fmts_mutex);
> + return;
> + }
> +
> + hash_del(&ps->hnode);
> +
> + mutex_unlock(&printk_fmts_mutex);
> +
> + debugfs_remove(ps->file);
> + kfree(ps);
> +}
> +
> +static int module_printk_fmts_notify(struct notifier_block *self,
> + unsigned long val, void *data)
> +{
> + struct module *mod = data;
> +
> + if (mod->printk_fmts_sec_size) {
> + switch (val) {
> + case MODULE_STATE_COMING:
> + store_printk_fmt_sec(mod, mod->printk_fmts_start,
> + mod->printk_fmts_start +
> + mod->printk_fmts_sec_size);
> + break;
> +
> + case MODULE_STATE_GOING:
> + remove_printk_fmt_sec(mod);
> + break;
> + }
> + }
> +
> + return NOTIFY_OK;
> +}
> +
> +static const char *ps_get_module_name(const struct printk_fmt_sec *ps)
> +{
> + return ps->module ? ps->module->name : "vmlinux";
> +}
> +
> +static struct notifier_block module_printk_fmts_nb = {
> + .notifier_call = module_printk_fmts_notify,
> +};
> +
> +static int __init module_printk_fmts_init(void)
> +{
> + return register_module_notifier(&module_printk_fmts_nb);
> +}
> +
> +core_initcall(module_printk_fmts_init);
> +
> +#else /* !CONFIG_MODULES */
> +static const char *ps_get_module_name(const struct printk_fmt_sec *ps)
> +{
> + return "vmlinux";
> +}
> +#endif /* CONFIG_MODULES */
> +
> +static int debugfs_pf_show(struct seq_file *s, void *v)
> +{
> + struct module *mod = s->file->f_inode->i_private;
> + struct printk_fmt_sec *ps = NULL;
> + const char **fptr = NULL;
> + int ret = 0;
> +
> + mutex_lock(&printk_fmts_mutex);
> +
> + /*
> + * The entry might have been invalidated in the hlist between _open and
> + * _show, which is we need to eyeball the entries under
> + * printk_fmts_mutex again.
> + */
> + ps = find_printk_fmt_sec(mod);
> + if (unlikely(!ps)) {
> + ret = -ENOENT;
> + goto out_unlock;
> + }
> +
> + for (fptr = ps->start; fptr < ps->end; fptr++) {
> + /* For callsites without facility/level preamble. */
> + if (unlikely(*fptr[0] != KERN_SOH_ASCII))
> + seq_printf(s, "%c%d", KERN_SOH_ASCII,
> +MESSAGE_LOGLEVEL_DEFAULT);
> + seq_printf(s, "%s%c", *fptr, '\0');
> + }
> +
> +out_unlock:
> + mutex_unlock(&printk_fmts_mutex);
> + return ret;
> +}
> +
> +static int debugfs_pf_open(struct inode *inode, struct file *file)
> +{
> + struct module *mod = inode->i_private;
> + struct printk_fmt_sec *ps = NULL;
> + int ret;
> +
> + /*
> + * We can't pass around the printk_fmt_sec because it might be freed
> + * before we enter the mutex. Do the hash table lookup each time to
> + * check.
> + */
> + mutex_lock(&printk_fmts_mutex);
> +
> + ps = find_printk_fmt_sec(mod);
> + if (unlikely(!ps)) {
> + ret = -ENOENT;
> + goto out_unlock;
> + }
> +
> + ret = single_open_size(file, debugfs_pf_show, NULL, ps->output_size);
> +
> +out_unlock:
> + mutex_unlock(&printk_fmts_mutex);
> +
> + return ret;
> +}
> +
> +static int __init init_printk_fmts(void)
> +{
> + struct dentry *dfs_root = debugfs_create_dir("printk", NULL);
> + struct dentry *tmp = NULL;
> +
> + if (IS_ERR_OR_NULL(dfs_root))
Again, how can dfs_root be NULL?
And why care about any error? No kernel code should ever work
differently if debugfs is acting up or not.
> + return -ENOMEM;
> +
> + tmp = debugfs_create_dir("formats", dfs_root);
> +
> + if (IS_ERR_OR_NULL(tmp))
Again, NULL can never happen. Where did you copy this logic from? I
need to go fix that...
thanks,
greg k-h
Re: DMA direct mapping fix for 5.4 and earlier stable branches
On Tue, Feb 09, 2021 at 11:39:25AM +0530, Sumit Garg wrote: > Hi Christoph, Greg, > > Currently we are observing an incorrect address translation > corresponding to DMA direct mapping methods on 5.4 stable kernel while > sharing dmabuf from one device to another where both devices have > their own coherent DMA memory pools. What devices have this problem? And why can't then just use 5.10 to solve this issue as that problem has always been present for them, right? > I am able to root cause this issue which is caused by incorrect virt > to phys translation for addresses belonging to vmalloc space using > virt_to_page(). But while looking at the mainline kernel, this patch > [1] changes address translation from virt->to->phys to dma->to->phys > which fixes the issue observed on 5.4 stable kernel as well (minimal > fix [2]). > > So I would like to seek your suggestion for backport to stable kernels > (5.4 or earlier) as to whether we should backport the complete > mainline commit [1] or we should just apply the minimal fix [2]? Whenever you try to create a "minimal" fix, 90% of the time it is wrong and does not work and I end up having to deal with the mess. What prevents you from doing the real thing here? Are the patches to big? And again, why not just use 5.10 for this hardware? What hardware is it? thanks, greg k-h
Re: [PATCH v2] mm: cma: support sysfs
On Mon, Feb 08, 2021 at 10:34:51PM -0800, John Hubbard wrote: > On 2/8/21 10:27 PM, John Hubbard wrote: > > On 2/8/21 10:13 PM, Greg KH wrote: > > > On Mon, Feb 08, 2021 at 05:57:17PM -0800, John Hubbard wrote: > > > > On 2/8/21 3:36 PM, Minchan Kim wrote: > > > > ... > > > > > > > char name[CMA_MAX_NAME]; > > > > > > > +#ifdef CONFIG_CMA_SYSFS > > > > > > > + struct cma_stat *stat; > > > > > > > > > > > > This should not be a pointer. By making it a pointer, you've added > > > > > > a bunch of pointless > > > > > > extra code to the implementation. > > > > > > > > > > Originally, I went with the object lifetime with struct cma as you > > > > > suggested to make code simple. However, Greg KH wanted to have > > > > > release for kobj_type since it is consistent with other kboject > > > > > handling. > > > > > > > > Are you talking about the kobj in your new struct cma_stat? That seems > > > > like circular logic if so. I'm guessing Greg just wanted kobj methods > > > > to be used *if* you are dealing with kobjects. That's a narrower point. > > > > > > > > I can't imagine that he would have insisted on having additional > > > > allocations just so that kobj freeing methods could be used. :) > > > > > > Um, yes, I was :) > > > > > > You can not add a kobject to a structure and then somehow think you can > > > just ignore the reference counting issues involved. If a kobject is > > > part of a structure then the kobject is responsible for controling the > > > lifespan of the memory, nothing else can be. > > > > > > So by making the kobject dynamic, you properly handle that memory > > > lifespan of the object, instead of having to worry about the lifespan of > > > the larger object (which the original patch was not doing.) > > > > > > Does that make sense? > > > > > That part makes sense, yes, thanks. The part that I'm trying to straighten > > out is, why was kobject even added to the struct cma_stat in the first > > place? Why not just leave .stat as a static member variable, without > > a kobject in it, and done? > > > > Sorry, I think I get it now: this is in order to allow a separate lifetime > for the .stat member. I was sort of implicitly assuming that the "right" > way to do it is just have the whole object use one lifetime management, > but as you say, there is no kobject being added to the parent. > > I still feel odd about the allocation and freeing of something that seems > to be logically the same lifetime (other than perhaps a few, briefly pending > sysfs reads, at the end of life). So I'd still think that the kobject should > be added to the parent... That's fine if you want to add it to the parent. If so, then the kobject controls the lifetime of the structure, nothing else can. Either is fine with me, what is "forbidden" is having a kobject and somehow thinking that it does not control the lifetime of the structure. thanks, greg k-h
Re: [PATCH]: drivers: staging: most: Fixed styling issue.
On Tue, Feb 09, 2021 at 11:53:11AM +0530, Mukul Mehar wrote: > >From 29bcaf0066003983da29b1e026b985c0727b091a Mon Sep 17 00:00:00 2001 > From: Mukul Mehar > Date: Mon, 8 Feb 2021 01:03:06 +0530 > Subject: [PATCH] Drivers: staging: most: sound: Fixed style issue. Why is this still an attached file? These lines should not show up in the body of the email. Look at the thousands of examples on the mailing list as what needs to be done here. thanks, greg k-h
Re: [PATCH net-next v2] net: phy: broadcom: remove BCM5482 1000Base-BX support
On 09.02.2021 02:30, Andrew Lunn wrote: > On Tue, Feb 09, 2021 at 12:17:06AM +0100, Michael Walle wrote: >> It is nowhere used in the kernel. It also seems to be lacking the >> proper fiber advertise flags. Remove it. > > Maybe also remove the #define for PHY_BCM_FLAGS_MODE_1000BX? Maybe > there is an out of tree driver using this? By removing the #define, it > will fail at compile time, making it obvious the support has been > removed? > AFAICS this flag is still used in BCM54616S PHY driver code.
Re: [PATCH 5.10 000/120] 5.10.15-rc1 review
Am Dienstag, 9. Februar 2021, 03:31:44 CET schrieb Naresh Kamboju: > On Mon, 8 Feb 2021 at 20:44, Greg Kroah-Hartman > > wrote: > > This is the start of the stable review cycle for the 5.10.15 release. > > There are 120 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Wed, 10 Feb 2021 14:57:55 +. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5 > > .10.15-rc1.gz> > > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable- > > rc.git linux-5.10.y> > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > Due to the patch below, the x86_64 build breaks with gcc 7.3.x > This issue is specific to openembedded kernel builder. > > We have also noticed on mainline, Linux next and now on stable-rc 5.10. > > collect2: error: ld returned 1 exit status > make[2]: *** [scripts/Makefile.host:95: scripts/extract-cert] Error 1 > > ref: > Build failure link, > https://ci.linaro.org/view/lkft/job/openembedded-lkft-linux-stable-rc-5.10/D > ISTRO=lkft,MACHINE=intel-corei7-64,label=docker-buster-lkft/64/consoleText Is this part relevant or does that always happen with your builder. | /srv/oe/build/tmp-lkft-glibc/hosttools/ld: cannot find /lib/libc.so.6 inside / | /srv/oe/build/tmp-lkft-glibc/hosttools/ld: cannot find /usr/lib/ libc_nonshared.a inside / | /srv/oe/build/tmp-lkft-glibc/hosttools/ld: cannot find /lib/ld-linux- x86-64.so.2 inside / Can you provide a log with V=1 where we can see what actually is going on? Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
Re: [PATCH v1] vdpa/mlx5: Restore the hardware used index after change map
On 2021/2/9 下午2:12, Eli Cohen wrote:
On Tue, Feb 09, 2021 at 11:20:14AM +0800, Jason Wang wrote:
On 2021/2/8 下午6:04, Eli Cohen wrote:
On Mon, Feb 08, 2021 at 05:04:27PM +0800, Jason Wang wrote:
On 2021/2/8 下午2:37, Eli Cohen wrote:
On Mon, Feb 08, 2021 at 12:27:18PM +0800, Jason Wang wrote:
On 2021/2/6 上午7:07, Si-Wei Liu wrote:
On 2/3/2021 11:36 PM, Eli Cohen wrote:
When a change of memory map occurs, the hardware resources are destroyed
and then re-created again with the new memory map. In such case, we need
to restore the hardware available and used indices. The driver failed to
restore the used index which is added here.
Also, since the driver also fails to reset the available and used
indices upon device reset, fix this here to avoid regression caused by
the fact that used index may not be zero upon device reset.
Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5
devices")
Signed-off-by: Eli Cohen
---
v0 -> v1:
Clear indices upon device reset
drivers/vdpa/mlx5/net/mlx5_vnet.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
b/drivers/vdpa/mlx5/net/mlx5_vnet.c
index 88dde3455bfd..b5fe6d2ad22f 100644
--- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
+++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
@@ -87,6 +87,7 @@ struct mlx5_vq_restore_info {
u64 device_addr;
u64 driver_addr;
u16 avail_index;
+ u16 used_index;
bool ready;
struct vdpa_callback cb;
bool restore;
@@ -121,6 +122,7 @@ struct mlx5_vdpa_virtqueue {
u32 virtq_id;
struct mlx5_vdpa_net *ndev;
u16 avail_idx;
+ u16 used_idx;
int fw_state;
/* keep last in the struct */
@@ -804,6 +806,7 @@ static int create_virtqueue(struct mlx5_vdpa_net
*ndev, struct mlx5_vdpa_virtque
obj_context = MLX5_ADDR_OF(create_virtio_net_q_in, in,
obj_context);
MLX5_SET(virtio_net_q_object, obj_context, hw_available_index,
mvq->avail_idx);
+ MLX5_SET(virtio_net_q_object, obj_context, hw_used_index,
mvq->used_idx);
MLX5_SET(virtio_net_q_object, obj_context,
queue_feature_bit_mask_12_3,
get_features_12_3(ndev->mvdev.actual_features));
vq_ctx = MLX5_ADDR_OF(virtio_net_q_object, obj_context,
virtio_q_context);
@@ -1022,6 +1025,7 @@ static int connect_qps(struct mlx5_vdpa_net
*ndev, struct mlx5_vdpa_virtqueue *m
struct mlx5_virtq_attr {
u8 state;
u16 available_index;
+ u16 used_index;
};
static int query_virtqueue(struct mlx5_vdpa_net *ndev, struct
mlx5_vdpa_virtqueue *mvq,
@@ -1052,6 +1056,7 @@ static int query_virtqueue(struct
mlx5_vdpa_net *ndev, struct mlx5_vdpa_virtqueu
memset(attr, 0, sizeof(*attr));
attr->state = MLX5_GET(virtio_net_q_object, obj_context, state);
attr->available_index = MLX5_GET(virtio_net_q_object,
obj_context, hw_available_index);
+ attr->used_index = MLX5_GET(virtio_net_q_object, obj_context,
hw_used_index);
kfree(out);
return 0;
@@ -1535,6 +1540,16 @@ static void teardown_virtqueues(struct
mlx5_vdpa_net *ndev)
}
}
+static void clear_virtqueues(struct mlx5_vdpa_net *ndev)
+{
+ int i;
+
+ for (i = ndev->mvdev.max_vqs - 1; i >= 0; i--) {
+ ndev->vqs[i].avail_idx = 0;
+ ndev->vqs[i].used_idx = 0;
+ }
+}
+
/* TODO: cross-endian support */
static inline bool mlx5_vdpa_is_little_endian(struct mlx5_vdpa_dev
*mvdev)
{
@@ -1610,6 +1625,7 @@ static int save_channel_info(struct
mlx5_vdpa_net *ndev, struct mlx5_vdpa_virtqu
return err;
ri->avail_index = attr.available_index;
+ ri->used_index = attr.used_index;
ri->ready = mvq->ready;
ri->num_ent = mvq->num_ent;
ri->desc_addr = mvq->desc_addr;
@@ -1654,6 +1670,7 @@ static void restore_channels_info(struct
mlx5_vdpa_net *ndev)
continue;
mvq->avail_idx = ri->avail_index;
+ mvq->used_idx = ri->used_index;
mvq->ready = ri->ready;
mvq->num_ent = ri->num_ent;
mvq->desc_addr = ri->desc_addr;
@@ -1768,6 +1785,7 @@ static void mlx5_vdpa_set_status(struct
vdpa_device *vdev, u8 status)
if (!status) {
mlx5_vdpa_info(mvdev, "performing device reset\n");
teardown_driver(ndev);
+ clear_virtqueues(ndev);
The clearing looks fine at the first glance, as it aligns with the other
state cleanups floating around at the same place. However, the thing is
get_vq_state() is supposed to be called right after to get sync'ed with
the latest internal avail_index from device while vq is stopped. The
index was saved in the driver software at vq suspension, but before the
virtq object is destroyed. We shouldn't clear the avail_index too early.
Good point.
There's a limitation on the virtio spec and vDPA framework that we can not
simply differ device suspending from device reset.
Are you talkin
Re: [PATCH v2] mm: cma: support sysfs
On 2/8/21 10:27 PM, John Hubbard wrote: On 2/8/21 10:13 PM, Greg KH wrote: On Mon, Feb 08, 2021 at 05:57:17PM -0800, John Hubbard wrote: On 2/8/21 3:36 PM, Minchan Kim wrote: ... char name[CMA_MAX_NAME]; +#ifdef CONFIG_CMA_SYSFS + struct cma_stat *stat; This should not be a pointer. By making it a pointer, you've added a bunch of pointless extra code to the implementation. Originally, I went with the object lifetime with struct cma as you suggested to make code simple. However, Greg KH wanted to have release for kobj_type since it is consistent with other kboject handling. Are you talking about the kobj in your new struct cma_stat? That seems like circular logic if so. I'm guessing Greg just wanted kobj methods to be used *if* you are dealing with kobjects. That's a narrower point. I can't imagine that he would have insisted on having additional allocations just so that kobj freeing methods could be used. :) Um, yes, I was :) You can not add a kobject to a structure and then somehow think you can just ignore the reference counting issues involved. If a kobject is part of a structure then the kobject is responsible for controling the lifespan of the memory, nothing else can be. So by making the kobject dynamic, you properly handle that memory lifespan of the object, instead of having to worry about the lifespan of the larger object (which the original patch was not doing.) Does that make sense? That part makes sense, yes, thanks. The part that I'm trying to straighten out is, why was kobject even added to the struct cma_stat in the first place? Why not just leave .stat as a static member variable, without a kobject in it, and done? Sorry, I think I get it now: this is in order to allow a separate lifetime for the .stat member. I was sort of implicitly assuming that the "right" way to do it is just have the whole object use one lifetime management, but as you say, there is no kobject being added to the parent. I still feel odd about the allocation and freeing of something that seems to be logically the same lifetime (other than perhaps a few, briefly pending sysfs reads, at the end of life). So I'd still think that the kobject should be added to the parent... thanks, -- John Hubbard NVIDIA
Re: [PATCH v2 3/7] ASoC: codec: lpass-rx-macro: add dapm widgets and route
Hi Srinivas,
I love your patch! Perhaps something to improve:
[auto build test WARNING on asoc/for-next]
[also build test WARNING on v5.11-rc6 next-20210125]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Srinivas-Kandagatla/ASoC-codecs-add-support-for-LPASS-Codec-TX-and-RX-macros/20210209-084643
base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
for-next
config: arm64-randconfig-r013-20210209 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
c9439ca36342fb6013187d0a69aef92736951476)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
#
https://github.com/0day-ci/linux/commit/bac854a0c3da12f3b44c7b2f3e89843adb6e585e
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Srinivas-Kandagatla/ASoC-codecs-add-support-for-LPASS-Codec-TX-and-RX-macros/20210209-084643
git checkout bac854a0c3da12f3b44c7b2f3e89843adb6e585e
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> sound/soc/codecs/lpass-rx-macro.c:2439:2: warning: variable
>> 'hph_lut_bypass_reg' is used uninitialized whenever switch default is taken
>> [-Wsometimes-uninitialized]
default:
^~~
sound/soc/codecs/lpass-rx-macro.c:2443:6: note: uninitialized use occurs here
if (hph_lut_bypass_reg && SND_SOC_DAPM_EVENT_ON(event)) {
^~
sound/soc/codecs/lpass-rx-macro.c:2427:24: note: initialize the variable
'hph_lut_bypass_reg' to silence this warning
u16 hph_lut_bypass_reg;
^
= 0
1 warning generated.
vim +/hph_lut_bypass_reg +2439 sound/soc/codecs/lpass-rx-macro.c
2422
2423 static void rx_macro_hphdelay_lutbypass(struct snd_soc_component
*component,
2424 struct rx_macro *rx,
2425 u16 interp_idx, int event)
2426 {
2427 u16 hph_lut_bypass_reg;
2428 u16 hph_comp_ctrl7;
2429
2430 switch (interp_idx) {
2431 case INTERP_HPHL:
2432 hph_lut_bypass_reg = CDC_RX_TOP_HPHL_COMP_LUT;
2433 hph_comp_ctrl7 = CDC_RX_COMPANDER0_CTL7;
2434 break;
2435 case INTERP_HPHR:
2436 hph_lut_bypass_reg = CDC_RX_TOP_HPHR_COMP_LUT;
2437 hph_comp_ctrl7 = CDC_RX_COMPANDER1_CTL7;
2438 break;
> 2439 default:
2440 break;
2441 }
2442
2443 if (hph_lut_bypass_reg && SND_SOC_DAPM_EVENT_ON(event)) {
2444 if (interp_idx == INTERP_HPHL) {
2445 if (rx->is_ear_mode_on)
2446 snd_soc_component_write_field(component,
2447 CDC_RX_RX0_RX_PATH_CFG1,
2448 CDC_RX_RX0_HPH_L_EAR_SEL_MASK,
0x1);
2449 else
2450 snd_soc_component_write_field(component,
2451 hph_lut_bypass_reg,
2452 CDC_RX_TOP_HPH_LUT_BYPASS_MASK,
1);
2453 } else {
2454 snd_soc_component_write_field(component,
hph_lut_bypass_reg,
2455 CDC_RX_TOP_HPH_LUT_BYPASS_MASK,
1);
2456 }
2457 if (rx->hph_pwr_mode)
2458 snd_soc_component_write_field(component,
hph_comp_ctrl7,
2459
CDC_RX_COMPANDER1_HPH_LOW_PWR_MODE_MASK, 0x0);
2460 }
2461
2462 if (hph_lut_bypass_reg && SND_SOC_DAPM_EVENT_OFF(event)) {
2463 snd_soc_component_write_field(component,
2464 CDC_RX_RX0_RX_PATH_CFG1,
2465 CDC_RX_RX0_HPH_L_EAR_SEL_MASK,
0x0);
2466 snd_soc_component_update_bits(component,
hph_lut_bypass_reg,
2467 CDC_RX_TOP_HPH_LUT_BYPASS_MASK,
0);
2468 snd_soc_component_write_field(component, hph_comp_ctrl7,
2469
Re: [PATCH v12 7/7] kasan: don't run tests in async mode
Hi Vincenzo, I love your patch! Yet something to improve: [auto build test ERROR on next-20210125] [cannot apply to arm64/for-next/core xlnx/master arm/for-next soc/for-next kvmarm/next linus/master hnaz-linux-mm/master v5.11-rc6 v5.11-rc5 v5.11-rc4 v5.11-rc6] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Vincenzo-Frascino/arm64-ARMv8-5-A-MTE-Add-async-mode-support/20210209-080907 base:59fa6a163ffabc1bf25c5e0e33899e268a96d3cc config: powerpc64-randconfig-r033-20210209 (attached as .config) compiler: powerpc-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/0day-ci/linux/commit/53907a0b15724b414ddd9201356f92e09571ef90 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Vincenzo-Frascino/arm64-ARMv8-5-A-MTE-Add-async-mode-support/20210209-080907 git checkout 53907a0b15724b414ddd9201356f92e09571ef90 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=powerpc64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): powerpc-linux-ld: lib/test_kasan.o: in function `kasan_test_init': test_kasan.c:(.text+0x849a): undefined reference to `kasan_flag_async' >> powerpc-linux-ld: test_kasan.c:(.text+0x84a2): undefined reference to >> `kasan_flag_async' powerpc-linux-ld: test_kasan.c:(.text+0x84e2): undefined reference to `kasan_flag_async' --- 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 PATCH v3 0/6] Restricted DMA
v4 here: https://lore.kernel.org/patchwork/cover/1378113/
Re: [PATCH] checkpatch: do not apply "initialise globals to 0" check to BPF progs
On Mon, 2021-02-08 at 15:40 -0800, Song Liu wrote:
> BPF programs explicitly initialise global variables to 0 to make sure
> clang (v10 or older) do not put the variables in the common section.
> Skip "initialise globals to 0" check for BPF programs to elimiate error
> messages like:
>
> ERROR: do not initialise globals to 0
> #19: FILE: samples/bpf/tracex1_kern.c:21:
Another possible option is simply to add --ignore=GLOBAL_INITIALISERS
to the checkpatch command line for these files.
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> @@ -4323,7 +4323,11 @@ sub process {
> }
>
>
> # check for global initialisers.
> - if ($line =~
> /^\+$Type\s*$Ident(?:\s+$Modifier)*\s*=\s*($zero_initializer)\s*;/) {
> +# Do not apply to BPF programs (tools/testing/selftests/bpf/progs/*.c,
> samples/bpf/*_kern.c, *.bpf.c).
> + if ($line =~
> /^\+$Type\s*$Ident(?:\s+$Modifier)*\s*=\s*($zero_initializer)\s*;/ &&
> + $realfile !~
> /^tools\/testing\/selftests\/bpf\/progs\/.*\.c/ &&
> + $realfile !~ /^samples\/bpf\/.*_kern.c/ &&
> + $realfile !~ /.bpf.c$/) {
> if (ERROR("GLOBAL_INITIALISERS",
> "do not initialise globals to $1\n" .
> $herecurr) &&
> $fix) {
Re: [PATCH] checkpatch: do not apply "initialise globals to 0" check to BPF progs
On Mon, 2021-02-08 at 15:40 -0800, Song Liu wrote:
> BPF programs explicitly initialise global variables to 0 to make sure
> clang (v10 or older) do not put the variables in the common section.
> Skip "initialise globals to 0" check for BPF programs to elimiate error
> messages like:
>
> ERROR: do not initialise globals to 0
> #19: FILE: samples/bpf/tracex1_kern.c:21:
[]
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> @@ -4323,7 +4323,11 @@ sub process {
> }
>
>
> # check for global initialisers.
> - if ($line =~
> /^\+$Type\s*$Ident(?:\s+$Modifier)*\s*=\s*($zero_initializer)\s*;/) {
> +# Do not apply to BPF programs (tools/testing/selftests/bpf/progs/*.c,
> samples/bpf/*_kern.c, *.bpf.c).
> + if ($line =~
> /^\+$Type\s*$Ident(?:\s+$Modifier)*\s*=\s*($zero_initializer)\s*;/ &&
> + $realfile !~
> /^tools\/testing\/selftests\/bpf\/progs\/.*\.c/ &&
> + $realfile !~ /^samples\/bpf\/.*_kern.c/ &&
> + $realfile !~ /.bpf.c$/) {
probably better to make this a function so when additional files are
added it'd be easier to update this and it will not look as complex.
if ($line =~ /.../ &&
!exclude_global_initialisers($realfile))
> if (ERROR("GLOBAL_INITIALISERS",
> "do not initialise globals to $1\n" .
> $herecurr) &&
> $fix) {
Re: [PATCH v4 01/15] dmaengine: dw-edma: Add writeq() and readq() for 64 bits architectures
Hi Gustavo,
I love your patch! Perhaps something to improve:
[auto build test WARNING on vkoul-dmaengine/next]
[also build test WARNING on pci/next linux/master linus/master v5.11-rc6
next-20210125]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Gustavo-Pimentel/dmaengine-dw-edma-HDMA-support/20210204-061341
base: https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine.git next
config: i386-randconfig-m021-20210209 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
New smatch warnings:
drivers/dma/dw-edma/dw-edma-v0-core.c:328 dw_edma_v0_core_write_chunk() warn:
inconsistent indenting
drivers/dma/dw-edma/dw-edma-v0-core.c:385 dw_edma_v0_core_start() warn:
inconsistent indenting
Old smatch warnings:
drivers/dma/dw-edma/dw-edma-v0-core.c:352 dw_edma_v0_core_write_chunk() warn:
inconsistent indenting
vim +328 drivers/dma/dw-edma/dw-edma-v0-core.c
300
301 static void dw_edma_v0_core_write_chunk(struct dw_edma_chunk *chunk)
302 {
303 struct dw_edma_burst *child;
304 struct dw_edma_v0_lli __iomem *lli;
305 struct dw_edma_v0_llp __iomem *llp;
306 u32 control = 0, i = 0;
307 int j;
308
309 lli = chunk->ll_region.vaddr;
310
311 if (chunk->cb)
312 control = DW_EDMA_V0_CB;
313
314 j = chunk->bursts_alloc;
315 list_for_each_entry(child, &chunk->burst->list, list) {
316 j--;
317 if (!j)
318 control |= (DW_EDMA_V0_LIE | DW_EDMA_V0_RIE);
319
320 /* Channel control */
321 SET_LL_32(&lli[i].control, control);
322 /* Transfer size */
323 SET_LL_32(&lli[i].transfer_size, child->sz);
324 /* SAR */
325 #ifdef CONFIG_64BIT
326 SET_LL_64(&lli[i].sar.reg, child->sar);
327 #else /* CONFIG_64BIT */
> 328 SET_LL_32(&lli[i].sar.lsb,
> lower_32_bits(child->sar));
329 SET_LL_32(&lli[i].sar.msb,
upper_32_bits(child->sar));
330 #endif /* CONFIG_64BIT */
331 /* DAR */
332 #ifdef CONFIG_64BIT
333 SET_LL_64(&lli[i].dar.reg, child->dar);
334 #else /* CONFIG_64BIT */
335 SET_LL_32(&lli[i].dar.lsb,
lower_32_bits(child->dar));
336 SET_LL_32(&lli[i].dar.msb,
upper_32_bits(child->dar));
337 #endif /* CONFIG_64BIT */
338 i++;
339 }
340
341 llp = (void __iomem *)&lli[i];
342 control = DW_EDMA_V0_LLP | DW_EDMA_V0_TCB;
343 if (!chunk->cb)
344 control |= DW_EDMA_V0_CB;
345
346 /* Channel control */
347 SET_LL_32(&llp->control, control);
348 /* Linked list */
349 #ifdef CONFIG_64BIT
350 SET_LL_64(&llp->llp.reg, chunk->ll_region.paddr);
351 #else /* CONFIG_64BIT */
352 SET_LL_32(&llp->llp.lsb,
lower_32_bits(chunk->ll_region.paddr));
353 SET_LL_32(&llp->llp.msb,
upper_32_bits(chunk->ll_region.paddr));
354 #endif /* CONFIG_64BIT */
355 }
356
357 void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first)
358 {
359 struct dw_edma_chan *chan = chunk->chan;
360 struct dw_edma *dw = chan->chip->dw;
361 u32 tmp;
362
363 dw_edma_v0_core_write_chunk(chunk);
364
365 if (first) {
366 /* Enable engine */
367 SET_RW_32(dw, chan->dir, engine_en, BIT(0));
368 /* Interrupt unmask - done, abort */
369 tmp = GET_RW_32(dw, chan->dir, int_mask);
370 tmp &= ~FIELD_PREP(EDMA_V0_DONE_INT_MASK,
BIT(chan->id));
371 tmp &= ~FIELD_PREP(EDMA_V0_ABORT_INT_MASK,
BIT(chan->id));
372 SET_RW_32(dw, chan->dir, int_mask, tmp);
373 /* Linked list error */
374 tmp = GET_RW_32(dw, chan->dir, linked_list_err_en);
375 tmp |= FIELD_PREP(EDMA_V0_LINKED_LIST_ERR_MASK,
BIT(chan->id));
376 SET_RW_32(dw, chan->dir, linked_list_err_en, tmp);
377 /* Channel control */
378 SET_CH_32(dw, chan->dir, chan->id, ch_control1,
379(DW_EDMA_V0_CCS | DW_EDMA_V0_LLE
Re: [PATCH v2] mm: cma: support sysfs
On 2/8/21 10:13 PM, Greg KH wrote: On Mon, Feb 08, 2021 at 05:57:17PM -0800, John Hubbard wrote: On 2/8/21 3:36 PM, Minchan Kim wrote: ... char name[CMA_MAX_NAME]; +#ifdef CONFIG_CMA_SYSFS + struct cma_stat *stat; This should not be a pointer. By making it a pointer, you've added a bunch of pointless extra code to the implementation. Originally, I went with the object lifetime with struct cma as you suggested to make code simple. However, Greg KH wanted to have release for kobj_type since it is consistent with other kboject handling. Are you talking about the kobj in your new struct cma_stat? That seems like circular logic if so. I'm guessing Greg just wanted kobj methods to be used *if* you are dealing with kobjects. That's a narrower point. I can't imagine that he would have insisted on having additional allocations just so that kobj freeing methods could be used. :) Um, yes, I was :) You can not add a kobject to a structure and then somehow think you can just ignore the reference counting issues involved. If a kobject is part of a structure then the kobject is responsible for controling the lifespan of the memory, nothing else can be. So by making the kobject dynamic, you properly handle that memory lifespan of the object, instead of having to worry about the lifespan of the larger object (which the original patch was not doing.) Does that make sense? That part makes sense, yes, thanks. The part that I'm trying to straighten out is, why was kobject even added to the struct cma_stat in the first place? Why not just leave .stat as a static member variable, without a kobject in it, and done? thanks, -- John Hubbard NVIDIA
[PATCH V2 3/4] scsi: ufs-debugfs: Add user-defined exception_event_mask
Allow users to enable specific exception events via debugfs.
The bits enabled by the driver ee_drv_ctrl are separated from the bits
enabled by the user ee_usr_ctrl. The control mask ee_mask_ctrl is the
logical-or of those two. A mutex is needed to ensure that the masks match
what was written to the device.
Signed-off-by: Adrian Hunter
---
drivers/scsi/ufs/ufs-debugfs.c | 46 ++
drivers/scsi/ufs/ufshcd.c | 86 +-
drivers/scsi/ufs/ufshcd.h | 22 -
3 files changed, 120 insertions(+), 34 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-debugfs.c b/drivers/scsi/ufs/ufs-debugfs.c
index dee98dc72d29..59729073b569 100644
--- a/drivers/scsi/ufs/ufs-debugfs.c
+++ b/drivers/scsi/ufs/ufs-debugfs.c
@@ -44,10 +44,56 @@ static int ufs_debugfs_stats_show(struct seq_file *s, void
*data)
}
DEFINE_SHOW_ATTRIBUTE(ufs_debugfs_stats);
+static int ee_usr_mask_get(void *data, u64 *val)
+{
+ struct ufs_hba *hba = data;
+
+ *val = hba->ee_usr_mask;
+ return 0;
+}
+
+static int ufs_debugfs_get_user_access(struct ufs_hba *hba)
+__acquires(&hba->host_sem)
+{
+ down(&hba->host_sem);
+ if (!ufshcd_is_user_access_allowed(hba)) {
+ up(&hba->host_sem);
+ return -EBUSY;
+ }
+ pm_runtime_get_sync(hba->dev);
+ return 0;
+}
+
+static void ufs_debugfs_put_user_access(struct ufs_hba *hba)
+__releases(&hba->host_sem)
+{
+ pm_runtime_put_sync(hba->dev);
+ up(&hba->host_sem);
+}
+
+static int ee_usr_mask_set(void *data, u64 val)
+{
+ struct ufs_hba *hba = data;
+ int err;
+
+ if (val & ~(u64)MASK_EE_STATUS)
+ return -EINVAL;
+ err = ufs_debugfs_get_user_access(hba);
+ if (err)
+ return err;
+ err = ufshcd_update_ee_usr_mask(hba, val, MASK_EE_STATUS);
+ ufs_debugfs_put_user_access(hba);
+ return err;
+}
+
+DEFINE_DEBUGFS_ATTRIBUTE(ee_usr_mask_fops, ee_usr_mask_get, ee_usr_mask_set,
"%#llx\n");
+
void ufs_debugfs_hba_init(struct ufs_hba *hba)
{
hba->debugfs_root = debugfs_create_dir(dev_name(hba->dev),
ufs_debugfs_root);
debugfs_create_file("stats", 0400, hba->debugfs_root, hba,
&ufs_debugfs_stats_fops);
+ debugfs_create_file("exception_event_mask", 0600, hba->debugfs_root,
+ hba, &ee_usr_mask_fops);
}
void ufs_debugfs_hba_exit(struct ufs_hba *hba)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index d6fdce655388..065a662e7886 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5160,6 +5160,46 @@ static irqreturn_t ufshcd_transfer_req_compl(struct
ufs_hba *hba)
}
}
+static int __ufshcd_write_ee_control(struct ufs_hba *hba, u32 ee_ctrl_mask)
+{
+ return ufshcd_query_attr_retry(hba, UPIU_QUERY_OPCODE_WRITE_ATTR,
+ QUERY_ATTR_IDN_EE_CONTROL, 0, 0,
+ &ee_ctrl_mask);
+}
+
+static int ufshcd_write_ee_control(struct ufs_hba *hba)
+{
+ int err;
+
+ mutex_lock(&hba->ee_ctrl_mutex);
+ err = __ufshcd_write_ee_control(hba, hba->ee_ctrl_mask);
+ mutex_unlock(&hba->ee_ctrl_mutex);
+ if (err)
+ dev_err(hba->dev, "%s: failed to write ee control %d\n",
+ __func__, err);
+ return err;
+}
+
+int ufshcd_update_ee_control(struct ufs_hba *hba, u16 *mask, u16 *other_mask,
+u16 set, u16 clr)
+{
+ u16 new_mask, ee_ctrl_mask;
+ int err = 0;
+
+ mutex_lock(&hba->ee_ctrl_mutex);
+ new_mask = (*mask & ~clr) | set;
+ ee_ctrl_mask = new_mask | *other_mask;
+ if (ee_ctrl_mask != hba->ee_ctrl_mask)
+ err = __ufshcd_write_ee_control(hba, ee_ctrl_mask);
+ /* Still need to update 'mask' even if 'ee_ctrl_mask' was unchanged */
+ if (!err) {
+ hba->ee_ctrl_mask = ee_ctrl_mask;
+ *mask = new_mask;
+ }
+ mutex_unlock(&hba->ee_ctrl_mutex);
+ return err;
+}
+
/**
* ufshcd_disable_ee - disable exception event
* @hba: per-adapter instance
@@ -5170,22 +5210,9 @@ static irqreturn_t ufshcd_transfer_req_compl(struct
ufs_hba *hba)
*
* Returns zero on success, non-zero error value on failure.
*/
-static int ufshcd_disable_ee(struct ufs_hba *hba, u16 mask)
+static inline int ufshcd_disable_ee(struct ufs_hba *hba, u16 mask)
{
- int err = 0;
- u32 val;
-
- if (!(hba->ee_ctrl_mask & mask))
- goto out;
-
- val = hba->ee_ctrl_mask & ~mask;
- val &= MASK_EE_STATUS;
- err = ufshcd_query_attr_retry(hba, UPIU_QUERY_OPCODE_WRITE_ATTR,
- QUERY_ATTR_IDN_EE_CONTROL, 0, 0, &val);
- if (!err)
- hba->ee_ctrl_mask &= ~mask;
-out:
- return err;
+ return ufshcd_update_ee_drv_mask(hba, 0, mask);
}
/**
@@ -5198,22 +5225,9 @@ static int ufshcd_disable_ee(struct ufs_hba *hba, u1
[PATCH V2 4/4] scsi: ufs-debugfs: Add user-defined exception event rate limiting
An enabled user-specified exception event that does not clear quickly will
repeatedly cause the handler to run. That could unduly disturb the driver
behaviour being tested or debugged. To prevent that add debugfs file
exception_event_rate_limit_ms. When a exception event happens, it is
disabled, and then after a period of time (default 20ms) the exception
event is enabled again.
Note that if the driver also has that exception event enabled, it will not
be disabled.
Signed-off-by: Adrian Hunter
---
drivers/scsi/ufs/ufs-debugfs.c | 44 ++
drivers/scsi/ufs/ufs-debugfs.h | 2 ++
drivers/scsi/ufs/ufshcd.c | 5 ++--
drivers/scsi/ufs/ufshcd.h | 4
4 files changed, 53 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-debugfs.c b/drivers/scsi/ufs/ufs-debugfs.c
index 59729073b569..ced9ef4d7c78 100644
--- a/drivers/scsi/ufs/ufs-debugfs.c
+++ b/drivers/scsi/ufs/ufs-debugfs.c
@@ -88,15 +88,59 @@ static int ee_usr_mask_set(void *data, u64 val)
DEFINE_DEBUGFS_ATTRIBUTE(ee_usr_mask_fops, ee_usr_mask_get, ee_usr_mask_set,
"%#llx\n");
+void ufs_debugfs_exception_event(struct ufs_hba *hba, u16 status)
+{
+ bool chgd = false;
+ u16 ee_ctrl_mask;
+ int err = 0;
+
+ if (!hba->debugfs_ee_rate_limit_ms || !status)
+ return;
+
+ mutex_lock(&hba->ee_ctrl_mutex);
+ ee_ctrl_mask = hba->ee_drv_mask | (hba->ee_usr_mask & ~status);
+ chgd = ee_ctrl_mask != hba->ee_ctrl_mask;
+ if (chgd) {
+ err = __ufshcd_write_ee_control(hba, ee_ctrl_mask);
+ if (err)
+ dev_err(hba->dev, "%s: failed to write ee control %d\n",
+ __func__, err);
+ }
+ mutex_unlock(&hba->ee_ctrl_mutex);
+
+ if (chgd && !err) {
+ unsigned long delay =
msecs_to_jiffies(hba->debugfs_ee_rate_limit_ms);
+
+ queue_delayed_work(system_freezable_wq, &hba->debugfs_ee_work,
delay);
+ }
+}
+
+static void ufs_debugfs_restart_ee(struct work_struct *work)
+{
+ struct ufs_hba *hba = container_of(work, struct ufs_hba,
debugfs_ee_work.work);
+
+ if (!hba->ee_usr_mask || pm_runtime_suspended(hba->dev) ||
+ ufs_debugfs_get_user_access(hba))
+ return;
+ ufshcd_write_ee_control(hba);
+ ufs_debugfs_put_user_access(hba);
+}
+
void ufs_debugfs_hba_init(struct ufs_hba *hba)
{
+ /* Set default exception event rate limit period to 20ms */
+ hba->debugfs_ee_rate_limit_ms = 20;
+ INIT_DELAYED_WORK(&hba->debugfs_ee_work, ufs_debugfs_restart_ee);
hba->debugfs_root = debugfs_create_dir(dev_name(hba->dev),
ufs_debugfs_root);
debugfs_create_file("stats", 0400, hba->debugfs_root, hba,
&ufs_debugfs_stats_fops);
debugfs_create_file("exception_event_mask", 0600, hba->debugfs_root,
hba, &ee_usr_mask_fops);
+ debugfs_create_u32("exception_event_rate_limit_ms", 0600,
hba->debugfs_root,
+ &hba->debugfs_ee_rate_limit_ms);
}
void ufs_debugfs_hba_exit(struct ufs_hba *hba)
{
debugfs_remove_recursive(hba->debugfs_root);
+ cancel_delayed_work_sync(&hba->debugfs_ee_work);
}
diff --git a/drivers/scsi/ufs/ufs-debugfs.h b/drivers/scsi/ufs/ufs-debugfs.h
index f35b39c4b4f5..3ca29d30460a 100644
--- a/drivers/scsi/ufs/ufs-debugfs.h
+++ b/drivers/scsi/ufs/ufs-debugfs.h
@@ -12,11 +12,13 @@ void __init ufs_debugfs_init(void);
void __exit ufs_debugfs_exit(void);
void ufs_debugfs_hba_init(struct ufs_hba *hba);
void ufs_debugfs_hba_exit(struct ufs_hba *hba);
+void ufs_debugfs_exception_event(struct ufs_hba *hba, u16 status);
#else
static inline void ufs_debugfs_init(void) {}
static inline void ufs_debugfs_exit(void) {}
static inline void ufs_debugfs_hba_init(struct ufs_hba *hba) {}
static inline void ufs_debugfs_hba_exit(struct ufs_hba *hba) {}
+static inline void ufs_debugfs_exception_event(struct ufs_hba *hba, u16
status) {}
#endif
#endif
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 065a662e7886..42d9a96a5721 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5160,14 +5160,14 @@ static irqreturn_t ufshcd_transfer_req_compl(struct
ufs_hba *hba)
}
}
-static int __ufshcd_write_ee_control(struct ufs_hba *hba, u32 ee_ctrl_mask)
+int __ufshcd_write_ee_control(struct ufs_hba *hba, u32 ee_ctrl_mask)
{
return ufshcd_query_attr_retry(hba, UPIU_QUERY_OPCODE_WRITE_ATTR,
QUERY_ATTR_IDN_EE_CONTROL, 0, 0,
&ee_ctrl_mask);
}
-static int ufshcd_write_ee_control(struct ufs_hba *hba)
+int ufshcd_write_ee_control(struct ufs_hba *hba)
{
int err;
@@ -5635,6 +5635,7 @@ static void ufshcd_exception_event_handler(struct
work_struct *work)
if (status & hba->ee_drv_mask & MASK_EE_URGENT_BKOPS)
ufshcd_bkops_exception_event
drivers/rtc/rtc-pcf8523.c:35: warning: "REG_OFFSET" redefined
Hi Thomas, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 61556703b610a104de324e4f061dc6cf7b218b46 commit: 7fd70c65faacd39628ba5f670be6490010c8132f ARM: irqstat: Get rid of duplicated declaration date: 3 months ago config: arm-randconfig-r026-20210209 (attached as .config) compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7fd70c65faacd39628ba5f670be6490010c8132f git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 7fd70c65faacd39628ba5f670be6490010c8132f # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): >> drivers/rtc/rtc-pcf8523.c:35: warning: "REG_OFFSET" redefined 35 | #define REG_OFFSET 0x0e | In file included from arch/arm/mach-ixp4xx/include/mach/hardware.h:30, from arch/arm/mach-ixp4xx/include/mach/io.h:15, from arch/arm/include/asm/io.h:198, from include/linux/io.h:13, from include/linux/irq.h:20, from include/asm-generic/hardirq.h:13, from arch/arm/include/asm/hardirq.h:10, from include/linux/hardirq.h:10, from include/linux/interrupt.h:11, from include/linux/rtc.h:17, from drivers/rtc/rtc-pcf8523.c:9: arch/arm/mach-ixp4xx/include/mach/platform.h:25: note: this is the location of the previous definition 25 | #define REG_OFFSET 3 | vim +/REG_OFFSET +35 drivers/rtc/rtc-pcf8523.c f803f0d079ded4 Thierry Reding 2012-12-17 34 bc3bee02527252 Russell King 2017-09-29 @35 #define REG_OFFSET 0x0e bc3bee02527252 Russell King 2017-09-29 36 #define REG_OFFSET_MODE BIT(7) bc3bee02527252 Russell King 2017-09-29 37 :: The code at line 35 was first introduced by commit :: bc3bee0252725240ffa62180d387cc245179c549 rtc: pcf8523: add support for trimming the RTC oscillator :: TO: Russell King :: CC: Alexandre Belloni --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
[PATCH V2 1/4] scsi: ufs: Add exception event tracepoint
Currently, exception event status can be read from wExceptionEventStatus
attribute (sysfs file attributes/exception_event_status under the UFS host
controller device directory). Polling that attribute to track UFS exception
events is impractical, so add a tracepoint to track exception events for
testing and debugging purposes.
Note, by the time the exception event status is read, the exception event
may have cleared, so the value can be zero - see example below.
Note also, only enabled exception events can be reported. A subsequent
patch adds the ability for users to enable selected exception events via
debugfs.
Example with driver instrumented to enable all exception events:
# echo 1 > /sys/kernel/debug/tracing/events/ufs/ufshcd_exception_event/enable
... do some I/O ...
# cat /sys/kernel/debug/tracing/trace
# tracer: nop
#
# entries-in-buffer/entries-written: 3/3 #P:5
#
#_-=> irqs-off
# / _=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / delay
# TASK-PID CPU# TIMESTAMP FUNCTION
# | | | | |
kworker/2:2-173 [002] 731.486419: ufshcd_exception_event:
:00:12.5: status 0x0
kworker/2:2-173 [002] 732.608918: ufshcd_exception_event:
:00:12.5: status 0x4
kworker/2:2-173 [002] 732.609312: ufshcd_exception_event:
:00:12.5: status 0x4
Signed-off-by: Adrian Hunter
---
drivers/scsi/ufs/ufshcd.c | 2 ++
include/trace/events/ufs.h | 21 +
2 files changed, 23 insertions(+)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 721f55db181f..d6fdce655388 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5616,6 +5616,8 @@ static void ufshcd_exception_event_handler(struct
work_struct *work)
goto out;
}
+ trace_ufshcd_exception_event(dev_name(hba->dev), status);
+
status &= hba->ee_ctrl_mask;
if (status & MASK_EE_URGENT_BKOPS)
diff --git a/include/trace/events/ufs.h b/include/trace/events/ufs.h
index e151477d645c..1cb6f1afba0e 100644
--- a/include/trace/events/ufs.h
+++ b/include/trace/events/ufs.h
@@ -349,6 +349,27 @@ TRACE_EVENT(ufshcd_upiu,
)
);
+TRACE_EVENT(ufshcd_exception_event,
+
+ TP_PROTO(const char *dev_name, u16 status),
+
+ TP_ARGS(dev_name, status),
+
+ TP_STRUCT__entry(
+ __string(dev_name, dev_name)
+ __field(u16, status)
+ ),
+
+ TP_fast_assign(
+ __assign_str(dev_name, dev_name);
+ __entry->status = status;
+ ),
+
+ TP_printk("%s: status 0x%x",
+ __get_str(dev_name), __entry->status
+ )
+);
+
#endif /* if !defined(_TRACE_UFS_H) || defined(TRACE_HEADER_MULTI_READ) */
/* This part must be outside protection */
--
2.17.1
[PATCH V2 2/4] scsi: ufs: Add exception event definitions
For readability and completeness, add exception event definitions.
Signed-off-by: Adrian Hunter
Reviewed-by: Bean Huo
---
drivers/scsi/ufs/ufs.h | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
index bf1897a72532..cb80b9670bfe 100644
--- a/drivers/scsi/ufs/ufs.h
+++ b/drivers/scsi/ufs/ufs.h
@@ -348,8 +348,14 @@ enum power_desc_param_offset {
/* Exception event mask values */
enum {
- MASK_EE_STATUS = 0x,
- MASK_EE_URGENT_BKOPS= (1 << 2),
+ MASK_EE_STATUS = 0x,
+ MASK_EE_DYNCAP_EVENT= BIT(0),
+ MASK_EE_SYSPOOL_EVENT = BIT(1),
+ MASK_EE_URGENT_BKOPS= BIT(2),
+ MASK_EE_TOO_HIGH_TEMP = BIT(3),
+ MASK_EE_TOO_LOW_TEMP= BIT(4),
+ MASK_EE_WRITEBOOSTER_EVENT = BIT(5),
+ MASK_EE_PERFORMANCE_THROTTLING = BIT(6),
};
/* Background operation status */
--
2.17.1
[PATCH V2 0/4] scsi: ufs-debugfs: Add UFS Exception Event reporting
Hi Here are V2 patches to add a tracepoint for UFS Exception Events and to allow users to enable specific exception events without affecting the driver's use of exception events. Changes in V2: scsi: ufs: Add exception event tracepoint Change status field from "exception event status" to "status" scsi: ufs: Add exception event definitions Add Reviewed-by: Bean Huo Adrian Hunter (4): scsi: ufs: Add exception event tracepoint scsi: ufs: Add exception event definitions scsi: ufs-debugfs: Add user-defined exception_event_mask scsi: ufs-debugfs: Add user-defined exception event rate limiting drivers/scsi/ufs/ufs-debugfs.c | 90 ++ drivers/scsi/ufs/ufs-debugfs.h | 2 + drivers/scsi/ufs/ufs.h | 10 - drivers/scsi/ufs/ufshcd.c | 87 +--- drivers/scsi/ufs/ufshcd.h | 26 +++- include/trace/events/ufs.h | 21 ++ 6 files changed, 201 insertions(+), 35 deletions(-) Regards Adrian
[PATCH v4 14/14] of: Add plumbing for restricted DMA pool
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
---
drivers/of/address.c| 25 +
drivers/of/device.c | 3 +++
drivers/of/of_private.h | 5 +
3 files changed, 33 insertions(+)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 73ddf2540f3f..b6093c9b135d 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1094,3 +1095,27 @@ bool of_dma_is_coherent(struct device_node *np)
return false;
}
EXPORT_SYMBOL_GPL(of_dma_is_coherent);
+
+int of_dma_set_restricted_buffer(struct device *dev)
+{
+ struct device_node *node;
+ int count, i;
+
+ if (!dev->of_node)
+ return 0;
+
+ count = of_property_count_elems_of_size(dev->of_node, "memory-region",
+ sizeof(phandle));
+ for (i = 0; i < count; i++) {
+ node = of_parse_phandle(dev->of_node, "memory-region", i);
+ /* There might be multiple memory regions, but only one
+* restriced-dma-pool region is allowed.
+*/
+ if (of_device_is_compatible(node, "restricted-dma-pool") &&
+ of_device_is_available(node))
+ return of_reserved_mem_device_init_by_idx(
+ dev, dev->of_node, i);
+ }
+
+ return 0;
+}
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 1122daa8e273..38c631f1fafa 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -186,6 +186,9 @@ int of_dma_configure_id(struct device *dev, struct
device_node *np,
arch_setup_dma_ops(dev, dma_start, size, iommu, coherent);
+ if (!iommu)
+ return of_dma_set_restricted_buffer(dev);
+
return 0;
}
EXPORT_SYMBOL_GPL(of_dma_configure_id);
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index d9e6a324de0a..28a2dfa197ba 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -161,12 +161,17 @@ struct bus_dma_region;
#if defined(CONFIG_OF_ADDRESS) && defined(CONFIG_HAS_DMA)
int of_dma_get_range(struct device_node *np,
const struct bus_dma_region **map);
+int of_dma_set_restricted_buffer(struct device *dev);
#else
static inline int of_dma_get_range(struct device_node *np,
const struct bus_dma_region **map)
{
return -ENODEV;
}
+static inline int of_dma_get_restricted_buffer(struct device *dev)
+{
+ return -ENODEV;
+}
#endif
#endif /* _LINUX_OF_PRIVATE_H */
--
2.30.0.478.g8a0d178c01-goog
[PATCH]: drivers: staging: most: Fixed styling issue.
>From 29bcaf0066003983da29b1e026b985c0727b091a Mon Sep 17 00:00:00 2001
From: Mukul Mehar
Date: Mon, 8 Feb 2021 01:03:06 +0530
Subject: [PATCH] Drivers: staging: most: sound: Fixed style issue.
This patch fixes a warning, of the line ending with a '(',
generated by checkpatch.pl.
Signed-off-by: Mukul Mehar
---
drivers/staging/most/sound/sound.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/most/sound/sound.c b/drivers/staging/most/sound/sound.c
index 3a1a59058042..4dd1bf95d1ce 100644
--- a/drivers/staging/most/sound/sound.c
+++ b/drivers/staging/most/sound/sound.c
@@ -228,12 +228,12 @@ static int playback_thread(void *data)
struct mbo *mbo = NULL;
bool period_elapsed = false;
- wait_event_interruptible(
- channel->playback_waitq,
- kthread_should_stop() ||
- (channel->is_stream_running &&
- (mbo = most_get_mbo(channel->iface, channel->id,
- ∁
+ wait_event_interruptible(channel->playback_waitq,
+ kthread_should_stop() ||
+ (channel->is_stream_running &&
+ (mbo = most_get_mbo(channel->iface,
+ channel->id,
+ ∁
if (!mbo)
continue;
--
2.25.1
[PATCH v4 12/14] swiotlb: Add restricted DMA alloc/free support.
Add the functions, dev_swiotlb_{alloc,free} to support the memory
allocation from restricted DMA pool.
Signed-off-by: Claire Chang
---
include/linux/swiotlb.h | 2 ++
kernel/dma/direct.c | 30 ++
kernel/dma/swiotlb.c| 34 ++
3 files changed, 58 insertions(+), 8 deletions(-)
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index b9f2a250c8da..2cd39e102915 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -74,6 +74,8 @@ extern enum swiotlb_force swiotlb_force;
#ifdef CONFIG_DMA_RESTRICTED_POOL
bool is_swiotlb_force(struct device *dev);
bool is_dev_swiotlb_force(struct device *dev);
+struct page *dev_swiotlb_alloc(struct device *dev, size_t size, gfp_t gfp);
+bool dev_swiotlb_free(struct device *dev, struct page *page, size_t size);
#else
static inline bool is_swiotlb_force(struct device *dev)
{
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index a76a1a2f24da..f9a9321f7559 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include "direct.h"
@@ -77,6 +78,10 @@ static bool dma_coherent_ok(struct device *dev, phys_addr_t
phys, size_t size)
static void __dma_direct_free_pages(struct device *dev, struct page *page,
size_t size)
{
+#ifdef CONFIG_DMA_RESTRICTED_POOL
+ if (dev_swiotlb_free(dev, page, size))
+ return;
+#endif
dma_free_contiguous(dev, page, size);
}
@@ -89,6 +94,12 @@ static struct page *__dma_direct_alloc_pages(struct device
*dev, size_t size,
WARN_ON_ONCE(!PAGE_ALIGNED(size));
+#ifdef CONFIG_DMA_RESTRICTED_POOL
+ page = dev_swiotlb_alloc(dev, size, gfp);
+ if (page)
+ return page;
+#endif
+
gfp |= dma_direct_optimal_gfp_mask(dev, dev->coherent_dma_mask,
&phys_limit);
page = dma_alloc_contiguous(dev, size, gfp);
@@ -147,7 +158,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
gfp |= __GFP_NOWARN;
if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&
- !force_dma_unencrypted(dev)) {
+ !force_dma_unencrypted(dev) && !is_dev_swiotlb_force(dev)) {
page = __dma_direct_alloc_pages(dev, size, gfp & ~__GFP_ZERO);
if (!page)
return NULL;
@@ -160,8 +171,8 @@ void *dma_direct_alloc(struct device *dev, size_t size,
}
if (!IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) &&
- !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
- !dev_is_dma_coherent(dev))
+ !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) && !dev_is_dma_coherent(dev) &&
+ !is_dev_swiotlb_force(dev))
return arch_dma_alloc(dev, size, dma_handle, gfp, attrs);
/*
@@ -171,7 +182,9 @@ void *dma_direct_alloc(struct device *dev, size_t size,
if (IS_ENABLED(CONFIG_DMA_COHERENT_POOL) &&
!gfpflags_allow_blocking(gfp) &&
(force_dma_unencrypted(dev) ||
-(IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
!dev_is_dma_coherent(dev
+(IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
+ !dev_is_dma_coherent(dev))) &&
+ !is_dev_swiotlb_force(dev))
return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);
/* we always manually zero the memory once we are done */
@@ -252,15 +265,15 @@ void dma_direct_free(struct device *dev, size_t size,
unsigned int page_order = get_order(size);
if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&
- !force_dma_unencrypted(dev)) {
+ !force_dma_unencrypted(dev) && !is_dev_swiotlb_force(dev)) {
/* cpu_addr is a struct page cookie, not a kernel address */
dma_free_contiguous(dev, cpu_addr, size);
return;
}
if (!IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) &&
- !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
- !dev_is_dma_coherent(dev)) {
+ !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) && !dev_is_dma_coherent(dev) &&
+ !is_dev_swiotlb_force(dev)) {
arch_dma_free(dev, size, cpu_addr, dma_addr, attrs);
return;
}
@@ -288,7 +301,8 @@ struct page *dma_direct_alloc_pages(struct device *dev,
size_t size,
void *ret;
if (IS_ENABLED(CONFIG_DMA_COHERENT_POOL) &&
- force_dma_unencrypted(dev) && !gfpflags_allow_blocking(gfp))
+ force_dma_unencrypted(dev) && !gfpflags_allow_blocking(gfp) &&
+ !is_dev_swiotlb_force(dev))
return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);
page = __dma_direct_alloc_pages(dev, size, gfp);
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index fd9c1bd183ac..8b77fd64199e 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -836,6 +836,40 @@ late_initcall(swiotlb_create_default_debugfs
[PATCH v4 11/14] swiotlb: Add is_dev_swiotlb_force()
Add is_dev_swiotlb_force() which returns true if the device has
restricted DMA pool (e.g. dev->dev_swiotlb is set).
Signed-off-by: Claire Chang
---
include/linux/swiotlb.h | 9 +
kernel/dma/swiotlb.c| 5 +
2 files changed, 14 insertions(+)
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 76f86c684524..b9f2a250c8da 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -73,11 +73,16 @@ extern enum swiotlb_force swiotlb_force;
#ifdef CONFIG_DMA_RESTRICTED_POOL
bool is_swiotlb_force(struct device *dev);
+bool is_dev_swiotlb_force(struct device *dev);
#else
static inline bool is_swiotlb_force(struct device *dev)
{
return unlikely(swiotlb_force == SWIOTLB_FORCE);
}
+static inline bool is_dev_swiotlb_force(struct device *dev)
+{
+ return false;
+}
#endif /* CONFIG_DMA_RESTRICTED_POOL */
bool is_swiotlb_buffer(struct device *dev, phys_addr_t paddr);
@@ -93,6 +98,10 @@ static inline bool is_swiotlb_force(struct device *dev)
{
return false;
}
+static inline bool is_dev_swiotlb_force(struct device *dev)
+{
+ return false;
+}
static inline bool is_swiotlb_buffer(struct device *dev, phys_addr_t paddr)
{
return false;
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index f64cbe6e84cc..fd9c1bd183ac 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -841,6 +841,11 @@ bool is_swiotlb_force(struct device *dev)
return unlikely(swiotlb_force == SWIOTLB_FORCE) || dev->dev_swiotlb;
}
+bool is_dev_swiotlb_force(struct device *dev)
+{
+ return dev->dev_swiotlb;
+}
+
static int rmem_swiotlb_device_init(struct reserved_mem *rmem,
struct device *dev)
{
--
2.30.0.478.g8a0d178c01-goog
[PATCH v4 08/14] swiotlb: Use restricted DMA pool if available
Regardless of swiotlb setting, the restricted DMA pool is preferred if
available.
The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at unexpected times. However, to protect
against general data leakage and system memory corruption, the system
needs to provide a way to lock down the memory access, e.g., MPU.
Signed-off-by: Claire Chang
---
include/linux/swiotlb.h | 13 +
kernel/dma/direct.h | 2 +-
kernel/dma/swiotlb.c| 20 +---
3 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index f13a52a97382..76f86c684524 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -71,6 +71,15 @@ dma_addr_t swiotlb_map(struct device *dev, phys_addr_t phys,
#ifdef CONFIG_SWIOTLB
extern enum swiotlb_force swiotlb_force;
+#ifdef CONFIG_DMA_RESTRICTED_POOL
+bool is_swiotlb_force(struct device *dev);
+#else
+static inline bool is_swiotlb_force(struct device *dev)
+{
+ return unlikely(swiotlb_force == SWIOTLB_FORCE);
+}
+#endif /* CONFIG_DMA_RESTRICTED_POOL */
+
bool is_swiotlb_buffer(struct device *dev, phys_addr_t paddr);
void __init swiotlb_exit(void);
unsigned int swiotlb_max_segment(void);
@@ -80,6 +89,10 @@ phys_addr_t get_swiotlb_start(struct device *dev);
void __init swiotlb_adjust_size(unsigned long new_size);
#else
#define swiotlb_force SWIOTLB_NO_FORCE
+static inline bool is_swiotlb_force(struct device *dev)
+{
+ return false;
+}
static inline bool is_swiotlb_buffer(struct device *dev, phys_addr_t paddr)
{
return false;
diff --git a/kernel/dma/direct.h b/kernel/dma/direct.h
index 7b83b1595989..b011db1b625d 100644
--- a/kernel/dma/direct.h
+++ b/kernel/dma/direct.h
@@ -87,7 +87,7 @@ static inline dma_addr_t dma_direct_map_page(struct device
*dev,
phys_addr_t phys = page_to_phys(page) + offset;
dma_addr_t dma_addr = phys_to_dma(dev, phys);
- if (unlikely(swiotlb_force == SWIOTLB_FORCE))
+ if (is_swiotlb_force(dev))
return swiotlb_map(dev, phys, size, dir, attrs);
if (unlikely(!dma_capable(dev, dma_addr, size, true))) {
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index e22e7ae75f1c..6fdebde8fb1f 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -40,6 +40,7 @@
#include
#endif
#ifdef CONFIG_DMA_RESTRICTED_POOL
+#include
#include
#include
#include
@@ -109,6 +110,10 @@ static struct swiotlb default_swiotlb;
static inline struct swiotlb *get_swiotlb(struct device *dev)
{
+#ifdef CONFIG_DMA_RESTRICTED_POOL
+ if (dev && dev->dev_swiotlb)
+ return dev->dev_swiotlb;
+#endif
return &default_swiotlb;
}
@@ -508,7 +513,7 @@ phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
phys_addr_t orig_addr,
size_t mapping_size, size_t alloc_size,
enum dma_data_direction dir, unsigned long attrs)
{
- struct swiotlb *swiotlb = &default_swiotlb;
+ struct swiotlb *swiotlb = get_swiotlb(hwdev);
dma_addr_t tbl_dma_addr = phys_to_dma_unencrypted(hwdev,
swiotlb->start);
unsigned long flags;
phys_addr_t tlb_addr;
@@ -519,7 +524,11 @@ phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
phys_addr_t orig_addr,
unsigned long max_slots;
unsigned long tmp_io_tlb_used;
+#ifdef CONFIG_DMA_RESTRICTED_POOL
+ if (no_iotlb_memory && !hwdev->dev_swiotlb)
+#else
if (no_iotlb_memory)
+#endif
panic("Can not allocate SWIOTLB buffer earlier and can't now
provide you with the DMA bounce buffer");
if (mem_encrypt_active())
@@ -641,7 +650,7 @@ void swiotlb_tbl_unmap_single(struct device *hwdev,
phys_addr_t tlb_addr,
size_t mapping_size, size_t alloc_size,
enum dma_data_direction dir, unsigned long attrs)
{
- struct swiotlb *swiotlb = &default_swiotlb;
+ struct swiotlb *swiotlb = get_swiotlb(hwdev);
unsigned long flags;
int i, count, nslots = ALIGN(alloc_size, 1 << IO_TLB_SHIFT) >>
IO_TLB_SHIFT;
int index = (tlb_addr - swiotlb->start) >> IO_TLB_SHIFT;
@@ -689,7 +698,7 @@ void swiotlb_tbl_sync_single(struct device *hwdev,
phys_addr_t tlb_addr,
size_t size, enum dma_data_direction dir,
enum dma_sync_target target)
{
- struct swiotlb *swiotlb = &default_swiotlb;
+ struct swiotlb *swiotlb = get_swiotlb(hwdev);
int index = (tlb_addr - swiotlb->start) >> IO_TLB_SHIFT;
phys_addr_t orig_addr = swiotlb->orig_addr[index];
@@ -801,6 +810,11 @@ late_initcall(swiotlb_create_default_debugfs);
#endif
#ifdef CONFIG_DMA_RESTRICTED_POOL
+bool is_swiotlb_force(struct device *dev)
+{
+ return unlikely(swiotlb_force == SWIOTLB_FORCE) || dev->dev_swiotlb;
+}
+
static int rmem_swiotlb_device_init(struct reserved_mem *rmem,
[PATCH v4 09/14] swiotlb: Refactor swiotlb_tbl_{map,unmap}_single
Refactor swiotlb_tbl_{map,unmap}_single to make the code reusable for
dev_swiotlb_{alloc,free}.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 116 ++-
1 file changed, 71 insertions(+), 45 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 6fdebde8fb1f..f64cbe6e84cc 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -509,14 +509,12 @@ static void swiotlb_bounce(phys_addr_t orig_addr,
phys_addr_t tlb_addr,
}
}
-phys_addr_t swiotlb_tbl_map_single(struct device *hwdev, phys_addr_t orig_addr,
- size_t mapping_size, size_t alloc_size,
- enum dma_data_direction dir, unsigned long attrs)
+static int swiotlb_tbl_find_free_region(struct device *hwdev,
+ dma_addr_t tbl_dma_addr,
+ size_t alloc_size, unsigned long attrs)
{
struct swiotlb *swiotlb = get_swiotlb(hwdev);
- dma_addr_t tbl_dma_addr = phys_to_dma_unencrypted(hwdev,
swiotlb->start);
unsigned long flags;
- phys_addr_t tlb_addr;
unsigned int nslots, stride, index, wrap;
int i;
unsigned long mask;
@@ -531,15 +529,6 @@ phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
phys_addr_t orig_addr,
#endif
panic("Can not allocate SWIOTLB buffer earlier and can't now
provide you with the DMA bounce buffer");
- if (mem_encrypt_active())
- pr_warn_once("Memory encryption is active and system is using
DMA bounce buffers\n");
-
- if (mapping_size > alloc_size) {
- dev_warn_once(hwdev, "Invalid sizes (mapping: %zd bytes, alloc:
%zd bytes)",
- mapping_size, alloc_size);
- return (phys_addr_t)DMA_MAPPING_ERROR;
- }
-
mask = dma_get_seg_boundary(hwdev);
tbl_dma_addr &= mask;
@@ -601,7 +590,6 @@ phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
phys_addr_t orig_addr,
swiotlb->list[i] = 0;
for (i = index - 1; (OFFSET(i, IO_TLB_SEGSIZE) !=
IO_TLB_SEGSIZE - 1) && swiotlb->list[i]; i--)
swiotlb->list[i] = ++count;
- tlb_addr = swiotlb->start + (index << IO_TLB_SHIFT);
/*
* Update the indices to avoid searching in the next
@@ -624,45 +612,20 @@ phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
phys_addr_t orig_addr,
if (!(attrs & DMA_ATTR_NO_WARN) && printk_ratelimit())
dev_warn(hwdev, "swiotlb buffer is full (sz: %zd bytes), total
%lu (slots), used %lu (slots)\n",
alloc_size, swiotlb->nslabs, tmp_io_tlb_used);
- return (phys_addr_t)DMA_MAPPING_ERROR;
+ return -ENOMEM;
+
found:
swiotlb->used += nslots;
spin_unlock_irqrestore(&swiotlb->lock, flags);
- /*
-* Save away the mapping from the original address to the DMA address.
-* This is needed when we sync the memory. Then we sync the buffer if
-* needed.
-*/
- for (i = 0; i < nslots; i++)
- swiotlb->orig_addr[index+i] = orig_addr + (i << IO_TLB_SHIFT);
- if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC) &&
- (dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL))
- swiotlb_bounce(orig_addr, tlb_addr, mapping_size,
DMA_TO_DEVICE);
-
- return tlb_addr;
+ return index;
}
-/*
- * tlb_addr is the physical address of the bounce buffer to unmap.
- */
-void swiotlb_tbl_unmap_single(struct device *hwdev, phys_addr_t tlb_addr,
- size_t mapping_size, size_t alloc_size,
- enum dma_data_direction dir, unsigned long attrs)
+static void swiotlb_tbl_release_region(struct device *hwdev, int index, size_t
size)
{
struct swiotlb *swiotlb = get_swiotlb(hwdev);
unsigned long flags;
- int i, count, nslots = ALIGN(alloc_size, 1 << IO_TLB_SHIFT) >>
IO_TLB_SHIFT;
- int index = (tlb_addr - swiotlb->start) >> IO_TLB_SHIFT;
- phys_addr_t orig_addr = swiotlb->orig_addr[index];
-
- /*
-* First, sync the memory before unmapping the entry
-*/
- if (orig_addr != INVALID_PHYS_ADDR &&
- !(attrs & DMA_ATTR_SKIP_CPU_SYNC) &&
- ((dir == DMA_FROM_DEVICE) || (dir == DMA_BIDIRECTIONAL)))
- swiotlb_bounce(orig_addr, tlb_addr, mapping_size,
DMA_FROM_DEVICE);
+ int i, count, nslots = ALIGN(size, 1 << IO_TLB_SHIFT) >> IO_TLB_SHIFT;
/*
* Return the buffer to the free list by setting the corresponding
@@ -694,6 +657,69 @@ void swiotlb_tbl_unmap_single(struct device *hwdev,
phys_addr_t tlb_addr,
spin_unlock_irqrestore(&swiotlb->lock, flags);
}
+phys_addr_t swiotlb_tbl_map_single(struct device *hwdev, phys_addr_t orig_addr,
+ size_t
[PATCH v4 10/14] dma-direct: Add a new wrapper __dma_direct_free_pages()
Add a new wrapper __dma_direct_free_pages() that will be useful later
for dev_swiotlb_free().
Signed-off-by: Claire Chang
---
kernel/dma/direct.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 30ccbc08e229..a76a1a2f24da 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -75,6 +75,11 @@ static bool dma_coherent_ok(struct device *dev, phys_addr_t
phys, size_t size)
min_not_zero(dev->coherent_dma_mask, dev->bus_dma_limit);
}
+static void __dma_direct_free_pages(struct device *dev, struct page *page,
size_t size)
+{
+ dma_free_contiguous(dev, page, size);
+}
+
static struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
gfp_t gfp)
{
@@ -237,7 +242,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
return NULL;
}
out_free_pages:
- dma_free_contiguous(dev, page, size);
+ __dma_direct_free_pages(dev, page, size);
return NULL;
}
@@ -273,7 +278,7 @@ void dma_direct_free(struct device *dev, size_t size,
else if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_CLEAR_UNCACHED))
arch_dma_clear_uncached(cpu_addr, size);
- dma_free_contiguous(dev, dma_direct_to_page(dev, dma_addr), size);
+ __dma_direct_free_pages(dev, dma_direct_to_page(dev, dma_addr), size);
}
struct page *dma_direct_alloc_pages(struct device *dev, size_t size,
@@ -310,7 +315,7 @@ struct page *dma_direct_alloc_pages(struct device *dev,
size_t size,
*dma_handle = phys_to_dma_direct(dev, page_to_phys(page));
return page;
out_free_pages:
- dma_free_contiguous(dev, page, size);
+ __dma_direct_free_pages(dev, page, size);
return NULL;
}
@@ -329,7 +334,7 @@ void dma_direct_free_pages(struct device *dev, size_t size,
if (force_dma_unencrypted(dev))
set_memory_encrypted((unsigned long)vaddr, 1 << page_order);
- dma_free_contiguous(dev, page, size);
+ __dma_direct_free_pages(dev, page, size);
}
#if defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE) || \
--
2.30.0.478.g8a0d178c01-goog
[PATCH v4 13/14] dt-bindings: of: Add restricted DMA pool
Introduce the new compatible string, restricted-dma-pool, for restricted
DMA. One can specify the address and length of the restricted DMA memory
region by restricted-dma-pool in the reserved-memory node.
Signed-off-by: Claire Chang
---
.../reserved-memory/reserved-memory.txt | 24 +++
1 file changed, 24 insertions(+)
diff --git
a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
index e8d3096d922c..fc9a12c2f679 100644
--- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
+++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
@@ -51,6 +51,20 @@ compatible (optional) - standard definition
used as a shared pool of DMA buffers for a set of devices. It can
be used by an operating system to instantiate the necessary pool
management subsystem if necessary.
+- restricted-dma-pool: This indicates a region of memory meant to be
+ used as a pool of restricted DMA buffers for a set of devices. The
+ memory region would be the only region accessible to those devices.
+ When using this, the no-map and reusable properties must not be set,
+ so the operating system can create a virtual mapping that will be
used
+ for synchronization. The main purpose for restricted DMA is to
+ mitigate the lack of DMA access control on systems without an IOMMU,
+ which could result in the DMA accessing the system memory at
+ unexpected times and/or unexpected addresses, possibly leading to
data
+ leakage or corruption. The feature on its own provides a basic level
+ of protection against the DMA overwriting buffer contents at
+ unexpected times. However, to protect against general data leakage
and
+ system memory corruption, the system needs to provide way to lock
down
+ the memory access, e.g., MPU.
- vendor specific string in the form ,[-]
no-map (optional) - empty property
- Indicates the operating system must not create a virtual mapping
@@ -120,6 +134,11 @@ one for multimedia processing (named
multimedia-memory@7700, 64MiB).
compatible = "acme,multimedia-memory";
reg = <0x7700 0x400>;
};
+
+ restricted_dma_mem_reserved: restricted_dma_mem_reserved {
+ compatible = "restricted-dma-pool";
+ reg = <0x5000 0x40>;
+ };
};
/* ... */
@@ -138,4 +157,9 @@ one for multimedia processing (named
multimedia-memory@7700, 64MiB).
memory-region = <&multimedia_reserved>;
/* ... */
};
+
+ pcie_device: pcie_device@0,0 {
+ memory-region = <&restricted_dma_mem_reserved>;
+ /* ... */
+ };
};
--
2.30.0.478.g8a0d178c01-goog
[PATCH v4 07/14] swiotlb: Update swiotlb API to gain a struct device argument
Introduce the get_swiotlb() getter and update all callers of
is_swiotlb_active(), is_swiotlb_buffer() and get_swiotlb_start() to gain
a struct device argument.
Signed-off-by: Claire Chang
---
drivers/iommu/dma-iommu.c | 12 ++--
drivers/xen/swiotlb-xen.c | 4 ++--
include/linux/swiotlb.h | 10 +-
kernel/dma/direct.c | 8
kernel/dma/direct.h | 6 +++---
kernel/dma/swiotlb.c | 23 +--
6 files changed, 37 insertions(+), 26 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index f659395e7959..abdbe14472cc 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -503,7 +503,7 @@ static void __iommu_dma_unmap_swiotlb(struct device *dev,
dma_addr_t dma_addr,
__iommu_dma_unmap(dev, dma_addr, size);
- if (unlikely(is_swiotlb_buffer(phys)))
+ if (unlikely(is_swiotlb_buffer(dev, phys)))
swiotlb_tbl_unmap_single(dev, phys, size,
iova_align(iovad, size), dir, attrs);
}
@@ -580,7 +580,7 @@ static dma_addr_t __iommu_dma_map_swiotlb(struct device
*dev, phys_addr_t phys,
}
iova = __iommu_dma_map(dev, phys, aligned_size, prot, dma_mask);
- if ((iova == DMA_MAPPING_ERROR) && is_swiotlb_buffer(phys))
+ if ((iova == DMA_MAPPING_ERROR) && is_swiotlb_buffer(dev, phys))
swiotlb_tbl_unmap_single(dev, phys, org_size,
aligned_size, dir, attrs);
@@ -753,7 +753,7 @@ static void iommu_dma_sync_single_for_cpu(struct device
*dev,
if (!dev_is_dma_coherent(dev))
arch_sync_dma_for_cpu(phys, size, dir);
- if (is_swiotlb_buffer(phys))
+ if (is_swiotlb_buffer(dev, phys))
swiotlb_tbl_sync_single(dev, phys, size, dir, SYNC_FOR_CPU);
}
@@ -766,7 +766,7 @@ static void iommu_dma_sync_single_for_device(struct device
*dev,
return;
phys = iommu_iova_to_phys(iommu_get_dma_domain(dev), dma_handle);
- if (is_swiotlb_buffer(phys))
+ if (is_swiotlb_buffer(dev, phys))
swiotlb_tbl_sync_single(dev, phys, size, dir, SYNC_FOR_DEVICE);
if (!dev_is_dma_coherent(dev))
@@ -787,7 +787,7 @@ static void iommu_dma_sync_sg_for_cpu(struct device *dev,
if (!dev_is_dma_coherent(dev))
arch_sync_dma_for_cpu(sg_phys(sg), sg->length, dir);
- if (is_swiotlb_buffer(sg_phys(sg)))
+ if (is_swiotlb_buffer(dev, sg_phys(sg)))
swiotlb_tbl_sync_single(dev, sg_phys(sg), sg->length,
dir, SYNC_FOR_CPU);
}
@@ -804,7 +804,7 @@ static void iommu_dma_sync_sg_for_device(struct device *dev,
return;
for_each_sg(sgl, sg, nelems, i) {
- if (is_swiotlb_buffer(sg_phys(sg)))
+ if (is_swiotlb_buffer(dev, sg_phys(sg)))
swiotlb_tbl_sync_single(dev, sg_phys(sg), sg->length,
dir, SYNC_FOR_DEVICE);
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 91f8c68d1a9b..f424d46756b1 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -192,8 +192,8 @@ int __ref xen_swiotlb_init(int verbose, bool early)
/*
* IO TLB memory already allocated. Just use it.
*/
- if (is_swiotlb_active()) {
- xen_io_tlb_start = phys_to_virt(get_swiotlb_start());
+ if (is_swiotlb_active(NULL)) {
+ xen_io_tlb_start = phys_to_virt(get_swiotlb_start(NULL));
goto end;
}
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 041611bf3c2a..f13a52a97382 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -71,16 +71,16 @@ dma_addr_t swiotlb_map(struct device *dev, phys_addr_t phys,
#ifdef CONFIG_SWIOTLB
extern enum swiotlb_force swiotlb_force;
-bool is_swiotlb_buffer(phys_addr_t paddr);
+bool is_swiotlb_buffer(struct device *dev, phys_addr_t paddr);
void __init swiotlb_exit(void);
unsigned int swiotlb_max_segment(void);
size_t swiotlb_max_mapping_size(struct device *dev);
-bool is_swiotlb_active(void);
-phys_addr_t get_swiotlb_start(void);
+bool is_swiotlb_active(struct device *dev);
+phys_addr_t get_swiotlb_start(struct device *dev);
void __init swiotlb_adjust_size(unsigned long new_size);
#else
#define swiotlb_force SWIOTLB_NO_FORCE
-static inline bool is_swiotlb_buffer(phys_addr_t paddr)
+static inline bool is_swiotlb_buffer(struct device *dev, phys_addr_t paddr)
{
return false;
}
@@ -96,7 +96,7 @@ static inline size_t swiotlb_max_mapping_size(struct device
*dev)
return SIZE_MAX;
}
-static inline bool is_swiotlb_active(void)
+static inline bool is_swiotlb_active(struct device *dev)
{
return false;
}
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 002268262c9a..30cc
[PATCH v4 06/14] swiotlb: Add restricted DMA pool
Add the initialization function to create restricted DMA pools from
matching reserved-memory nodes.
Signed-off-by: Claire Chang
---
include/linux/device.h | 4 ++
kernel/dma/swiotlb.c | 94 +-
2 files changed, 97 insertions(+), 1 deletion(-)
diff --git a/include/linux/device.h b/include/linux/device.h
index 7619a84f8ce4..08d440627b93 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -415,6 +415,7 @@ struct dev_links_info {
* @dma_pools: Dma pools (if dma'ble device).
* @dma_mem: Internal for coherent mem override.
* @cma_area: Contiguous memory area for dma allocations
+ * @dev_swiotlb: Internal for swiotlb override.
* @archdata: For arch-specific additions.
* @of_node: Associated device tree node.
* @fwnode:Associated device node supplied by platform firmware.
@@ -517,6 +518,9 @@ struct device {
#ifdef CONFIG_DMA_CMA
struct cma *cma_area; /* contiguous memory area for dma
allocations */
+#endif
+#ifdef CONFIG_DMA_RESTRICTED_POOL
+ struct swiotlb *dev_swiotlb;
#endif
/* arch specific additions */
struct dev_archdata archdata;
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index dc37951c6924..3a17451c5981 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -39,6 +39,13 @@
#ifdef CONFIG_DEBUG_FS
#include
#endif
+#ifdef CONFIG_DMA_RESTRICTED_POOL
+#include
+#include
+#include
+#include
+#include
+#endif
#include
#include
@@ -75,7 +82,8 @@ enum swiotlb_force swiotlb_force;
* range check to see if the memory was in fact allocated by this
* API.
* @nslabs: The number of IO TLB blocks (in groups of 64) between @start
and
- * @end. This is command line adjustable via setup_io_tlb_npages.
+ * @end. For default swiotlb, this is command line adjustable via
+ * setup_io_tlb_npages.
* @used: The number of used IO TLB block.
* @list: The free list describing the number of free entries available
* from each index.
@@ -780,3 +788,87 @@ static int __init swiotlb_create_default_debugfs(void)
late_initcall(swiotlb_create_default_debugfs);
#endif
+
+#ifdef CONFIG_DMA_RESTRICTED_POOL
+static int rmem_swiotlb_device_init(struct reserved_mem *rmem,
+ struct device *dev)
+{
+ struct swiotlb *swiotlb = rmem->priv;
+ int ret;
+
+ if (dev->dev_swiotlb)
+ return -EBUSY;
+
+ /* Since multiple devices can share the same pool, the private data,
+* swiotlb struct, will be initialized by the first device attached
+* to it.
+*/
+ if (!swiotlb) {
+ swiotlb = kzalloc(sizeof(*swiotlb), GFP_KERNEL);
+ if (!swiotlb)
+ return -ENOMEM;
+#ifdef CONFIG_ARM
+ unsigned long pfn = PHYS_PFN(reme->base);
+
+ if (!PageHighMem(pfn_to_page(pfn))) {
+ ret = -EINVAL;
+ goto cleanup;
+ }
+#endif /* CONFIG_ARM */
+
+ ret = swiotlb_init_tlb_pool(swiotlb, rmem->base, rmem->size);
+ if (ret)
+ goto cleanup;
+
+ rmem->priv = swiotlb;
+ }
+
+#ifdef CONFIG_DEBUG_FS
+ swiotlb_create_debugfs(swiotlb, rmem->name, default_swiotlb.debugfs);
+#endif /* CONFIG_DEBUG_FS */
+
+ dev->dev_swiotlb = swiotlb;
+
+ return 0;
+
+cleanup:
+ kfree(swiotlb);
+
+ return ret;
+}
+
+static void rmem_swiotlb_device_release(struct reserved_mem *rmem,
+ struct device *dev)
+{
+ if (!dev)
+ return;
+
+#ifdef CONFIG_DEBUG_FS
+ debugfs_remove_recursive(dev->dev_swiotlb->debugfs);
+#endif /* CONFIG_DEBUG_FS */
+ dev->dev_swiotlb = NULL;
+}
+
+static const struct reserved_mem_ops rmem_swiotlb_ops = {
+ .device_init = rmem_swiotlb_device_init,
+ .device_release = rmem_swiotlb_device_release,
+};
+
+static int __init rmem_swiotlb_setup(struct reserved_mem *rmem)
+{
+ unsigned long node = rmem->fdt_node;
+
+ if (of_get_flat_dt_prop(node, "reusable", NULL) ||
+ of_get_flat_dt_prop(node, "linux,cma-default", NULL) ||
+ of_get_flat_dt_prop(node, "linux,dma-default", NULL) ||
+ of_get_flat_dt_prop(node, "no-map", NULL))
+ return -EINVAL;
+
+ rmem->ops = &rmem_swiotlb_ops;
+ pr_info("Reserved memory: created device swiotlb memory pool at %pa,
size %ld MiB\n",
+ &rmem->base, (unsigned long)rmem->size / SZ_1M);
+ return 0;
+}
+
+RESERVEDMEM_OF_DECLARE(dma, "restricted-dma-pool", rmem_swiotlb_setup);
+#endif /* CONFIG_DMA_RESTRICTED_POOL */
--
2.30.0.478.g8a0d178c01-goog
[PATCH v4 05/14] swiotlb: Add DMA_RESTRICTED_POOL
Add a new kconfig symbol, DMA_RESTRICTED_POOL, for restricted DMA pool. Signed-off-by: Claire Chang --- kernel/dma/Kconfig | 14 ++ 1 file changed, 14 insertions(+) diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig index 479fc145acfc..97ff9f8dd3c8 100644 --- a/kernel/dma/Kconfig +++ b/kernel/dma/Kconfig @@ -83,6 +83,20 @@ config SWIOTLB bool select NEED_DMA_MAP_STATE +config DMA_RESTRICTED_POOL + bool "DMA Restricted Pool" + depends on OF && OF_RESERVED_MEM + select SWIOTLB + help + This enables support for restricted DMA pools which provide a level of + DMA memory protection on systems with limited hardware protection + capabilities, such as those lacking an IOMMU. + + For more information see + + and . + If unsure, say "n". + # # Should be selected if we can mmap non-coherent mappings to userspace. # The only thing that is really required is a way to set an uncached bit -- 2.30.0.478.g8a0d178c01-goog
[PATCH v4 03/14] swiotlb: Add struct swiotlb
Added a new struct, swiotlb, as the IO TLB memory pool descriptor and
moved relevant global variables into that struct.
This will be useful later to allow for restricted DMA pool.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 327 +++
1 file changed, 172 insertions(+), 155 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 678490d39e55..28b7bfe7a2a8 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -61,33 +61,43 @@
* allocate a contiguous 1MB, we're probably in trouble anyway.
*/
#define IO_TLB_MIN_SLABS ((1<<20) >> IO_TLB_SHIFT)
+#define INVALID_PHYS_ADDR (~(phys_addr_t)0)
enum swiotlb_force swiotlb_force;
/*
- * Used to do a quick range check in swiotlb_tbl_unmap_single and
- * swiotlb_tbl_sync_single_*, to see if the memory was in fact allocated by
this
- * API.
- */
-static phys_addr_t io_tlb_start, io_tlb_end;
-
-/*
- * The number of IO TLB blocks (in groups of 64) between io_tlb_start and
- * io_tlb_end. This is command line adjustable via setup_io_tlb_npages.
- */
-static unsigned long io_tlb_nslabs;
-
-/*
- * The number of used IO TLB block
- */
-static unsigned long io_tlb_used;
-
-/*
- * This is a free list describing the number of free entries available from
- * each index
+ * struct swiotlb - Software IO TLB Memory Pool Descriptor
+ *
+ * @start: The start address of the swiotlb memory pool. Used to do a
quick
+ * range check to see if the memory was in fact allocated by this
+ * API.
+ * @end:The end address of the swiotlb memory pool. Used to do a quick
+ * range check to see if the memory was in fact allocated by this
+ * API.
+ * @nslabs: The number of IO TLB blocks (in groups of 64) between @start
and
+ * @end. This is command line adjustable via setup_io_tlb_npages.
+ * @used: The number of used IO TLB block.
+ * @list: The free list describing the number of free entries available
+ * from each index.
+ * @index: The index to start searching in the next round.
+ * @orig_addr: The original address corresponding to a mapped entry for the
+ * sync operations.
+ * @lock: The lock to protect the above data structures in the map and
+ * unmap calls.
+ * @debugfs:The dentry to debugfs.
*/
-static unsigned int *io_tlb_list;
-static unsigned int io_tlb_index;
+struct swiotlb {
+ phys_addr_t start;
+ phys_addr_t end;
+ unsigned long nslabs;
+ unsigned long used;
+ unsigned int *list;
+ unsigned int index;
+ phys_addr_t *orig_addr;
+ spinlock_t lock;
+ struct dentry *debugfs;
+};
+static struct swiotlb default_swiotlb;
/*
* Max segment that we can provide which (if pages are contingous) will
@@ -95,27 +105,17 @@ static unsigned int io_tlb_index;
*/
static unsigned int max_segment;
-/*
- * We need to save away the original address corresponding to a mapped entry
- * for the sync operations.
- */
-#define INVALID_PHYS_ADDR (~(phys_addr_t)0)
-static phys_addr_t *io_tlb_orig_addr;
-
-/*
- * Protect the above data structures in the map and unmap calls
- */
-static DEFINE_SPINLOCK(io_tlb_lock);
-
static int late_alloc;
static int __init
setup_io_tlb_npages(char *str)
{
+ struct swiotlb *swiotlb = &default_swiotlb;
+
if (isdigit(*str)) {
- io_tlb_nslabs = simple_strtoul(str, &str, 0);
+ swiotlb->nslabs = simple_strtoul(str, &str, 0);
/* avoid tail segment of size < IO_TLB_SEGSIZE */
- io_tlb_nslabs = ALIGN(io_tlb_nslabs, IO_TLB_SEGSIZE);
+ swiotlb->nslabs = ALIGN(swiotlb->nslabs, IO_TLB_SEGSIZE);
}
if (*str == ',')
++str;
@@ -123,7 +123,7 @@ setup_io_tlb_npages(char *str)
swiotlb_force = SWIOTLB_FORCE;
} else if (!strcmp(str, "noforce")) {
swiotlb_force = SWIOTLB_NO_FORCE;
- io_tlb_nslabs = 1;
+ swiotlb->nslabs = 1;
}
return 0;
@@ -134,7 +134,7 @@ static bool no_iotlb_memory;
unsigned long swiotlb_nr_tbl(void)
{
- return unlikely(no_iotlb_memory) ? 0 : io_tlb_nslabs;
+ return unlikely(no_iotlb_memory) ? 0 : default_swiotlb.nslabs;
}
EXPORT_SYMBOL_GPL(swiotlb_nr_tbl);
@@ -156,13 +156,14 @@ unsigned long swiotlb_size_or_default(void)
{
unsigned long size;
- size = io_tlb_nslabs << IO_TLB_SHIFT;
+ size = default_swiotlb.nslabs << IO_TLB_SHIFT;
return size ? size : (IO_TLB_DEFAULT_SIZE);
}
void __init swiotlb_adjust_size(unsigned long new_size)
{
+ struct swiotlb *swiotlb = &default_swiotlb;
unsigned long size;
/*
@@ -170,10 +171,10 @@ void __init swiotlb_adjust_size(unsigned long new_size)
* architectures such as those supporting memory encryption to
* adjust/expand SWIOTLB size for their
[PATCH v4 04/14] swiotlb: Refactor swiotlb_late_init_with_tbl
Refactor swiotlb_late_init_with_tbl to make the code reusable for
restricted DMA pool initialization.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 65
1 file changed, 42 insertions(+), 23 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 28b7bfe7a2a8..dc37951c6924 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -353,20 +353,21 @@ static void swiotlb_cleanup(void)
max_segment = 0;
}
-int
-swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs)
+static int swiotlb_init_tlb_pool(struct swiotlb *swiotlb, phys_addr_t start,
+ size_t size)
{
- struct swiotlb *swiotlb = &default_swiotlb;
- unsigned long i, bytes;
+ unsigned long i;
+ void *vaddr = phys_to_virt(start);
- bytes = nslabs << IO_TLB_SHIFT;
+ size = ALIGN(size, 1 << IO_TLB_SHIFT);
+ swiotlb->nslabs = size >> IO_TLB_SHIFT;
+ swiotlb->nslabs = ALIGN(swiotlb->nslabs, IO_TLB_SEGSIZE);
- swiotlb->nslabs = nslabs;
- swiotlb->start = virt_to_phys(tlb);
- swiotlb->end = swiotlb->start + bytes;
+ swiotlb->start = start;
+ swiotlb->end = swiotlb->start + size;
- set_memory_decrypted((unsigned long)tlb, bytes >> PAGE_SHIFT);
- memset(tlb, 0, bytes);
+ set_memory_decrypted((unsigned long)vaddr, size >> PAGE_SHIFT);
+ memset(vaddr, 0, size);
/*
* Allocate and initialize the free list array. This array is used
@@ -390,13 +391,7 @@ swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs)
swiotlb->orig_addr[i] = INVALID_PHYS_ADDR;
}
swiotlb->index = 0;
- no_iotlb_memory = false;
-
- swiotlb_print_info();
- late_alloc = 1;
-
- swiotlb_set_max_segment(swiotlb->nslabs << IO_TLB_SHIFT);
spin_lock_init(&swiotlb->lock);
return 0;
@@ -410,6 +405,27 @@ swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs)
return -ENOMEM;
}
+int swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs)
+{
+ struct swiotlb *swiotlb = &default_swiotlb;
+ unsigned long bytes = nslabs << IO_TLB_SHIFT;
+ int ret;
+
+ ret = swiotlb_init_tlb_pool(swiotlb, virt_to_phys(tlb), bytes);
+ if (ret)
+ return ret;
+
+ no_iotlb_memory = false;
+
+ swiotlb_print_info();
+
+ late_alloc = 1;
+
+ swiotlb_set_max_segment(bytes);
+
+ return 0;
+}
+
void __init swiotlb_exit(void)
{
struct swiotlb *swiotlb = &default_swiotlb;
@@ -747,17 +763,20 @@ phys_addr_t get_swiotlb_start(void)
}
#ifdef CONFIG_DEBUG_FS
-
-static int __init swiotlb_create_debugfs(void)
+static void swiotlb_create_debugfs(struct swiotlb *swiotlb, const char *name,
+ struct dentry *node)
{
- struct swiotlb *swiotlb = &default_swiotlb;
-
- swiotlb->debugfs = debugfs_create_dir("swiotlb", NULL);
+ swiotlb->debugfs = debugfs_create_dir(name, node);
debugfs_create_ulong("io_tlb_nslabs", 0400, swiotlb->debugfs,
&swiotlb->nslabs);
debugfs_create_ulong("io_tlb_used", 0400, swiotlb->debugfs,
&swiotlb->used);
- return 0;
}
-late_initcall(swiotlb_create_debugfs);
+static int __init swiotlb_create_default_debugfs(void)
+{
+ swiotlb_create_debugfs(&default_swiotlb, "swiotlb", NULL);
+
+ return 0;
+}
+late_initcall(swiotlb_create_default_debugfs);
#endif
--
2.30.0.478.g8a0d178c01-goog
[PATCH v4 02/14] swiotlb: Move is_swiotlb_buffer() to swiotlb.c
Move is_swiotlb_buffer() to swiotlb.c and make io_tlb_{start,end}
static, so we can entirely hide struct swiotlb inside of swiotlb.c in
the following patches.
Signed-off-by: Claire Chang
---
include/linux/swiotlb.h | 7 +--
kernel/dma/swiotlb.c| 7 ++-
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 83200f3b042a..041611bf3c2a 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -70,13 +70,8 @@ dma_addr_t swiotlb_map(struct device *dev, phys_addr_t phys,
#ifdef CONFIG_SWIOTLB
extern enum swiotlb_force swiotlb_force;
-extern phys_addr_t io_tlb_start, io_tlb_end;
-
-static inline bool is_swiotlb_buffer(phys_addr_t paddr)
-{
- return paddr >= io_tlb_start && paddr < io_tlb_end;
-}
+bool is_swiotlb_buffer(phys_addr_t paddr);
void __init swiotlb_exit(void);
unsigned int swiotlb_max_segment(void);
size_t swiotlb_max_mapping_size(struct device *dev);
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index e180211f6ad9..678490d39e55 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -69,7 +69,7 @@ enum swiotlb_force swiotlb_force;
* swiotlb_tbl_sync_single_*, to see if the memory was in fact allocated by
this
* API.
*/
-phys_addr_t io_tlb_start, io_tlb_end;
+static phys_addr_t io_tlb_start, io_tlb_end;
/*
* The number of IO TLB blocks (in groups of 64) between io_tlb_start and
@@ -719,6 +719,11 @@ bool is_swiotlb_active(void)
return io_tlb_end != 0;
}
+bool is_swiotlb_buffer(phys_addr_t paddr)
+{
+ return paddr >= io_tlb_start && paddr < io_tlb_end;
+}
+
phys_addr_t get_swiotlb_start(void)
{
return io_tlb_start;
--
2.30.0.478.g8a0d178c01-goog
[PATCH v1] mm, hwpoison: enable error handling on shmem thp
From: Naoya Horiguchi
Currently hwpoison code checks PageAnon() for thp and refuses to handle
errors on non-anonymous thps (just for historical reason). We now
support non-anonymou thp like shmem one, so this patch suggests to enable
to handle shmem thps. Fortunately, we already have can_split_huge_page()
to check if a give thp is splittable, so this patch relies on it.
Signed-off-by: Naoya Horiguchi
---
mm/memory-failure.c | 34 +-
1 file changed, 9 insertions(+), 25 deletions(-)
diff --git v5.11-rc6/mm/memory-failure.c v5.11-rc6_patched/mm/memory-failure.c
index e9481632fcd1..8c1575de0507 100644
--- v5.11-rc6/mm/memory-failure.c
+++ v5.11-rc6_patched/mm/memory-failure.c
@@ -956,20 +956,6 @@ static int __get_hwpoison_page(struct page *page)
{
struct page *head = compound_head(page);
- if (!PageHuge(head) && PageTransHuge(head)) {
- /*
-* Non anonymous thp exists only in allocation/free time. We
-* can't handle such a case correctly, so let's give it up.
-* This should be better than triggering BUG_ON when kernel
-* tries to touch the "partially handled" page.
-*/
- if (!PageAnon(head)) {
- pr_err("Memory failure: %#lx: non anonymous thp\n",
- page_to_pfn(page));
- return 0;
- }
- }
-
if (get_page_unless_zero(head)) {
if (head == compound_head(page))
return 1;
@@ -1197,21 +1183,19 @@ static int identify_page_state(unsigned long pfn,
struct page *p,
static int try_to_split_thp_page(struct page *page, const char *msg)
{
- lock_page(page);
- if (!PageAnon(page) || unlikely(split_huge_page(page))) {
- unsigned long pfn = page_to_pfn(page);
+ struct page *head;
+ lock_page(page);
+ head = compound_head(page);
+ if (PageTransHuge(head) && can_split_huge_page(head, NULL) &&
+ !split_huge_page(page)) {
unlock_page(page);
- if (!PageAnon(page))
- pr_info("%s: %#lx: non anonymous thp\n", msg, pfn);
- else
- pr_info("%s: %#lx: thp split failed\n", msg, pfn);
- put_page(page);
- return -EBUSY;
+ return 0;
}
+ pr_info("%s: %#lx: thp split failed\n", msg, page_to_pfn(page));
unlock_page(page);
-
- return 0;
+ put_page(page);
+ return -EBUSY;
}
static int memory_failure_hugetlb(unsigned long pfn, int flags)
--
2.25.1
[PATCH v4 00/14] Restricted DMA
This series implements mitigations for lack of DMA access control on
systems without an IOMMU, which could result in the DMA accessing the
system memory at unexpected times and/or unexpected addresses, possibly
leading to data leakage or corruption.
For example, we plan to use the PCI-e bus for Wi-Fi and that PCI-e bus is
not behind an IOMMU. As PCI-e, by design, gives the device full access to
system memory, a vulnerability in the Wi-Fi firmware could easily escalate
to a full system exploit (remote wifi exploits: [1a], [1b] that shows a
full chain of exploits; [2], [3]).
To mitigate the security concerns, we introduce restricted DMA. Restricted
DMA utilizes the existing swiotlb to bounce streaming DMA in and out of a
specially allocated region and does memory allocation from the same region.
The feature on its own provides a basic level of protection against the DMA
overwriting buffer contents at unexpected times. However, to protect
against general data leakage and system memory corruption, the system needs
to provide a way to restrict the DMA to a predefined memory region (this is
usually done at firmware level, e.g. MPU in ATF on some ARM platforms [4]).
[1a]
https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html
[1b]
https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_11.html
[2] https://blade.tencent.com/en/advisories/qualpwn/
[3]
https://www.bleepingcomputer.com/news/security/vulnerabilities-found-in-highly-popular-firmware-for-wifi-chips/
[4]
https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/mediatek/mt8183/drivers/emi_mpu/emi_mpu.c#L132
Claire Chang (14):
swiotlb: Remove external access to io_tlb_start
swiotlb: Move is_swiotlb_buffer() to swiotlb.c
swiotlb: Add struct swiotlb
swiotlb: Refactor swiotlb_late_init_with_tbl
swiotlb: Add DMA_RESTRICTED_POOL
swiotlb: Add restricted DMA pool
swiotlb: Update swiotlb API to gain a struct device argument
swiotlb: Use restricted DMA pool if available
swiotlb: Refactor swiotlb_tbl_{map,unmap}_single
dma-direct: Add a new wrapper __dma_direct_free_pages()
swiotlb: Add is_dev_swiotlb_force()
swiotlb: Add restricted DMA alloc/free support.
dt-bindings: of: Add restricted DMA pool
of: Add plumbing for restricted DMA pool
.../reserved-memory/reserved-memory.txt | 24 +
arch/powerpc/platforms/pseries/svm.c | 4 +-
drivers/iommu/dma-iommu.c | 12 +-
drivers/of/address.c | 25 +
drivers/of/device.c | 3 +
drivers/of/of_private.h | 5 +
drivers/xen/swiotlb-xen.c | 4 +-
include/linux/device.h| 4 +
include/linux/swiotlb.h | 32 +-
kernel/dma/Kconfig| 14 +
kernel/dma/direct.c | 51 +-
kernel/dma/direct.h | 8 +-
kernel/dma/swiotlb.c | 636 --
13 files changed, 582 insertions(+), 240 deletions(-)
--
v4:
- Fix spinlock bad magic
- Use rmem->name for debugfs entry
- Address the comments in v3
v3:
Using only one reserved memory region for both streaming DMA and memory
allocation.
https://lore.kernel.org/patchwork/cover/1360992/
v2:
Building on top of swiotlb.
https://lore.kernel.org/patchwork/cover/1280705/
v1:
Using dma_map_ops.
https://lore.kernel.org/patchwork/cover/1271660/
2.30.0.478.g8a0d178c01-goog
[PATCH v4 01/14] swiotlb: Remove external access to io_tlb_start
Add a new function, get_swiotlb_start(), and remove external access to
io_tlb_start, so we can entirely hide struct swiotlb inside of swiotlb.c
in the following patches.
Signed-off-by: Claire Chang
---
arch/powerpc/platforms/pseries/svm.c | 4 ++--
drivers/xen/swiotlb-xen.c| 4 ++--
include/linux/swiotlb.h | 1 +
kernel/dma/swiotlb.c | 5 +
4 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/svm.c
b/arch/powerpc/platforms/pseries/svm.c
index 7b739cc7a8a9..c10c51d49f3d 100644
--- a/arch/powerpc/platforms/pseries/svm.c
+++ b/arch/powerpc/platforms/pseries/svm.c
@@ -55,8 +55,8 @@ void __init svm_swiotlb_init(void)
if (vstart && !swiotlb_init_with_tbl(vstart, io_tlb_nslabs, false))
return;
- if (io_tlb_start)
- memblock_free_early(io_tlb_start,
+ if (vstart)
+ memblock_free_early(vstart,
PAGE_ALIGN(io_tlb_nslabs << IO_TLB_SHIFT));
panic("SVM: Cannot allocate SWIOTLB buffer");
}
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 2b385c1b4a99..91f8c68d1a9b 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -192,8 +192,8 @@ int __ref xen_swiotlb_init(int verbose, bool early)
/*
* IO TLB memory already allocated. Just use it.
*/
- if (io_tlb_start != 0) {
- xen_io_tlb_start = phys_to_virt(io_tlb_start);
+ if (is_swiotlb_active()) {
+ xen_io_tlb_start = phys_to_virt(get_swiotlb_start());
goto end;
}
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index d9c9fc9ca5d2..83200f3b042a 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -81,6 +81,7 @@ void __init swiotlb_exit(void);
unsigned int swiotlb_max_segment(void);
size_t swiotlb_max_mapping_size(struct device *dev);
bool is_swiotlb_active(void);
+phys_addr_t get_swiotlb_start(void);
void __init swiotlb_adjust_size(unsigned long new_size);
#else
#define swiotlb_force SWIOTLB_NO_FORCE
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 7c42df6e6100..e180211f6ad9 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -719,6 +719,11 @@ bool is_swiotlb_active(void)
return io_tlb_end != 0;
}
+phys_addr_t get_swiotlb_start(void)
+{
+ return io_tlb_start;
+}
+
#ifdef CONFIG_DEBUG_FS
static int __init swiotlb_create_debugfs(void)
--
This can be dropped if Christoph's swiotlb cleanups are landed.
https://lore.kernel.org/linux-iommu/20210207160934.2955931-1-...@lst.de/T/#m7124f29b6076d462101fcff6433295157621da09
2.30.0.478.g8a0d178c01-goog
Re: [PATCH 15/18] irqchip/apple-aic: Add support for the Apple Interrupt Controller
On 08/02/2021 18.25, Marc Zyngier wrote:
I really do not want to expose IPIs in the DT. The OS defines what
IPIs are used for, not the firmware/HW. No other platform requires
this either, so is there any reason to do so?
This is used internally by the chained IPI driver (patch #16), but it
does not need to be ever used in the DT. I guess it would be appropriate
to just not document it in the bindings, and also use a higher type than
2 (e.g. 0xff), so that if we ever have to add another type to the
binding (e.g. the timer on older SoCs) it doesn't have to skip the
number 2 to avoid breaking compat between newer DTs and older drivers.
See irq-bcm2836.c for the same approach: a chained IPI controller using
an otherwise undocumented IRQ binding.
Another approach is to do what irq-armada-370-xp.c does: just ditch the
chained irqchip and call handle_domain_irq into the IPI domain directly
from the main IRQ handler function.
+#include
There isn't any chained interrupt controller here, AFAICT.
This goes with patch #16, I'll move it there.
If these functions have no impact on the per-CPU interrupts, then
maybe these interrupts should be given a different irqchip.
Same IRQ domain, different irqchip? That sounds reasonable and gets rid
of the bounds check on the mask/unmask calls, I'll do it for v2. This
chip would apply for both IPIs (where a different register set in AIC
for masking/unmasking applies, but that is handled at the chained
irqchip level in #16) and FIQs (which have no masking).
+static void aic_irq_eoi(struct irq_data *d)
+{
+ /*
+* Reading the interrupt reason automatically acknowledges and masks
+* the IRQ, so we just unmask it here if needed.
+*/
+ if (!irqd_irq_disabled(d) && !irqd_irq_masked(d))
+ aic_irq_unmask(d);
This doesn't apply to per-CPU interrupts, right? Or does it?
The auto-masking does apply to IPIs, but this code doesn't do the
unmasking. That is handled in the chained IPI domain in #16
*Strictly speaking* if we separate the responsibility at AIC for the
root handler and say the chained handler should purely be a multiplexer
for IPIs that doesn't touch the hardware at all, then the
masking/unmasking should move here (into another irqchip) and the IPI
domain code should just call into the root domain to mask/unmask the
sole used hardware IPI; the current approach is a minor layering
violation but... I'm not sure how useful it is to keep the layering
pristine when both drivers live in the same file and are instantiated
together anyway.
If I switch to the irq-armada-370-xp.c model where there is no logical
chaining, then this would be fine as-is as both domains would logically
represent driving different parts of AIC in parallel, with no nesting
relationship.
+ u32 type = event >> 16, irq = event & 0x;
Nit: please consider introducing masks and using the bitfield macros
to extract the various fields.
Ack, will do.
+ /* AIC_EVENT is read-sensitive, ensure it happens before we
proceed */
+ isb();
You seem to have a data dependency after this, so I can't see how the
ISB influences the read from AIC_EVENT. However you need to order it
with the read from the timer registers, and I believe it'd be better
to move the barrier there.
(Keeping the barrier story in the other thread)
+ if (type == AIC_EVENT_TYPE_HW) {
+ handle_domain_irq(aic_irqc->hw_domain, irq, regs);
+ } else if (type == AIC_EVENT_TYPE_IPI) {
+ handle_domain_irq(aic_irqc->hw_domain,
+ ic->nr_hw + AIC_NR_FIQ + irq - 1,
regs);
nit: it would be slightly less cumbersome to compute the hwirq in a
switch, and have a single call to handle_domain_irq().
I also wonder whether using two top-level domains would be better. Not
a big deal though.
Exactly :) I can certainly switch to that if you have no objection. It
should have lower overhead for IPIs anyway, and removes the fwspec step
to glue it all together.
+ } else {
+ pr_err("spurious IRQ event %d, %d\n", type, irq);
Spurious interrupts aren't an error, in general. If you really want to
keep this, at the very least make it rate-limited.
In this case it's more like "unknown IRQ event", which better be an
error because it means the chip is doing something we don't know about -
*except* the zero case, that's just a spurious IRQ which indeed isn't an
error (peripheral asserted and deasserted IRQ before we could handle it;
I need to check but I believe AIC would just withdraw the event in that
case).
So the zero case should be ignored and the unknown case should be fine
without rate limiting, because it really shouldn't happen, ever. I'll
fix the zero case for v2.
Consider turning the whole thing into a do{}while() so that there is
only a single read of A
Re: [PATCH] mm/hugetlb: Remove redundant VM_BUG_ON_PAGE on putback_active_hugepage()
Hi: On 2021/2/9 11:39, Mike Kravetz wrote: > On 2/8/21 6:10 PM, Miaohe Lin wrote: >> Hi: >> On 2021/2/9 9:26, Mike Kravetz wrote: >>> On 2/8/21 12:37 AM, Miaohe Lin wrote: PageHead(page) is implicitly checked in set_page_huge_active() via the PageHeadHuge(page) check. So remove this explicit one. >>> >>> I do not disagree with the code change. However, this commit message >>> is not accurate. set_page_huge_active() no longer exists in the tree >>> you are changing. It was replaced with SetHPageMigratable. Also, the >>> VM_BUG_ON_PAGE(!PageHeadHuge(page), page) was removed in the process. >>> So, there is no redundant check. >>> >>> However, a quick audit of calling code reveals that all callers know they >>> are operating on a hugetlb head page. >>> >> >> So I should change the commit log like: >> >> All callers know they are operating on a hugetlb head page. So this >> VM_BUG_ON_PAGE >> can't catch anything useful. >> >> and send a v2. Right? > > Correct, > Will do. Thanks a lot.
Re: [PATCH v5 05/22] powerpc/irq: Add helper to set regs->softe
Le 09/02/2021 à 02:11, Nicholas Piggin a écrit : Excerpts from Christophe Leroy's message of February 9, 2021 1:10 am: regs->softe doesn't exist on PPC32. Add irq_soft_mask_regs_set_state() helper to set regs->softe. This helper will void on PPC32. Signed-off-by: Christophe Leroy --- You could do the same with the kuap_ functions to change some ifdefs to IS_ENABLED. That's just my preference but if you prefer this way I guess that's okay. That's also my preference on the long term. Here it is ephemeral, I have a follow up series implementing interrupt exit/entry in C and getting rid of all the assembly kuap hence getting rid of those ifdefs. The issue I see when using IS_ENABLED() is that you have to indent to the right, then you interfere with the file history and 'git blame' Thanks for reviewing my series and looking forward to your feedback on my series on the interrupt entry/exit that I will likely release later today. Christophe
Re: [PATCH v2] mm: cma: support sysfs
On Mon, Feb 08, 2021 at 05:57:17PM -0800, John Hubbard wrote: > On 2/8/21 3:36 PM, Minchan Kim wrote: > ... > > > > char name[CMA_MAX_NAME]; > > > > +#ifdef CONFIG_CMA_SYSFS > > > > + struct cma_stat *stat; > > > > > > This should not be a pointer. By making it a pointer, you've added a > > > bunch of pointless > > > extra code to the implementation. > > > > Originally, I went with the object lifetime with struct cma as you > > suggested to make code simple. However, Greg KH wanted to have > > release for kobj_type since it is consistent with other kboject > > handling. > > Are you talking about the kobj in your new struct cma_stat? That seems > like circular logic if so. I'm guessing Greg just wanted kobj methods > to be used *if* you are dealing with kobjects. That's a narrower point. > > I can't imagine that he would have insisted on having additional > allocations just so that kobj freeing methods could be used. :) Um, yes, I was :) You can not add a kobject to a structure and then somehow think you can just ignore the reference counting issues involved. If a kobject is part of a structure then the kobject is responsible for controling the lifespan of the memory, nothing else can be. So by making the kobject dynamic, you properly handle that memory lifespan of the object, instead of having to worry about the lifespan of the larger object (which the original patch was not doing.) Does that make sense? thanks, greg k-h
Re: [PATCH v5 17/22] powerpc/syscall: Do not check unsupported scv vector on PPC32
Le 09/02/2021 à 03:00, Nicholas Piggin a écrit :
Excerpts from Christophe Leroy's message of February 9, 2021 1:10 am:
Only PPC64 has scv. No need to check the 0x7ff0 trap on PPC32.
For that, add a helper trap_is_unsupported_scv() similar to
trap_is_scv().
And ignore the scv parameter in syscall_exit_prepare (Save 14 cycles
346 => 332 cycles)
Signed-off-by: Christophe Leroy
---
v5: Added a helper trap_is_unsupported_scv()
---
arch/powerpc/include/asm/ptrace.h | 5 +
arch/powerpc/kernel/entry_32.S| 1 -
arch/powerpc/kernel/interrupt.c | 7 +--
3 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/ptrace.h
b/arch/powerpc/include/asm/ptrace.h
index 58f9dc060a7b..2c842b11a924 100644
--- a/arch/powerpc/include/asm/ptrace.h
+++ b/arch/powerpc/include/asm/ptrace.h
@@ -229,6 +229,11 @@ static inline bool trap_is_scv(struct pt_regs *regs)
return (IS_ENABLED(CONFIG_PPC_BOOK3S_64) && TRAP(regs) == 0x3000);
}
+static inline bool trap_is_unsupported_scv(struct pt_regs *regs)
+{
+ return (IS_ENABLED(CONFIG_PPC_BOOK3S_64) && TRAP(regs) == 0x7ff0);
+}
This change is good.
+
static inline bool trap_is_syscall(struct pt_regs *regs)
{
return (trap_is_scv(regs) || TRAP(regs) == 0xc00);
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index cffe58e63356..7c824e8928d0 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -344,7 +344,6 @@ transfer_to_syscall:
ret_from_syscall:
addir4,r1,STACK_FRAME_OVERHEAD
- li r5,0
bl syscall_exit_prepare
For this one, I think it would be nice to do the "right" thing and make
the function prototypes different on !64S. They could then declare a
local const bool scv = 0.
We could have syscall_exit_prepare and syscall_exit_prepare_maybe_scv
or something like that, 64s can use the latter one and the former can be
a wrapper that passes constant 0 for scv. Then we don't have different
prototypes for the same function, but you just have to make the 32-bit
version static inline and the 64-bit version exported to asm.
You can't call a static inline function from ASM, I don't understand you.
What is wrong for you really here ? Is that the fact we leave scv random, or is that the below
IS_ENABLED() ?
I don't mind keeping the 'li r5,0' before calling the function if you find it cleaner, the real
performance gain is with setting scv to 0 below for PPC32 (and maybe it should be set to zero for
book3e/64 too ?).
Other solution would be to do replace (!scv) by (!scv || !IS_ENABLED(CONFIG_PPC_BOOK3S_64)) in the
two places it is used in syscall_exit_prepare().
Any preference ?
Thanks
Christophe
@@ -224,6 +224,9 @@ notrace unsigned long syscall_exit_prepare(unsigned long r3,
unsigned long ti_flags;
unsigned long ret = 0;
+ if (IS_ENABLED(CONFIG_PPC32))
+ scv = 0;
+
CT_WARN_ON(ct_state() == CONTEXT_USER);
#ifdef CONFIG_PPC64
--
2.25.0
Re: [PATCH v1] vdpa/mlx5: Restore the hardware used index after change map
On Tue, Feb 09, 2021 at 11:20:14AM +0800, Jason Wang wrote:
>
> On 2021/2/8 下午6:04, Eli Cohen wrote:
> > On Mon, Feb 08, 2021 at 05:04:27PM +0800, Jason Wang wrote:
> > > On 2021/2/8 下午2:37, Eli Cohen wrote:
> > > > On Mon, Feb 08, 2021 at 12:27:18PM +0800, Jason Wang wrote:
> > > > > On 2021/2/6 上午7:07, Si-Wei Liu wrote:
> > > > > > On 2/3/2021 11:36 PM, Eli Cohen wrote:
> > > > > > > When a change of memory map occurs, the hardware resources are
> > > > > > > destroyed
> > > > > > > and then re-created again with the new memory map. In such case,
> > > > > > > we need
> > > > > > > to restore the hardware available and used indices. The driver
> > > > > > > failed to
> > > > > > > restore the used index which is added here.
> > > > > > >
> > > > > > > Also, since the driver also fails to reset the available and used
> > > > > > > indices upon device reset, fix this here to avoid regression
> > > > > > > caused by
> > > > > > > the fact that used index may not be zero upon device reset.
> > > > > > >
> > > > > > > Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported
> > > > > > > mlx5
> > > > > > > devices")
> > > > > > > Signed-off-by: Eli Cohen
> > > > > > > ---
> > > > > > > v0 -> v1:
> > > > > > > Clear indices upon device reset
> > > > > > >
> > > > > > > drivers/vdpa/mlx5/net/mlx5_vnet.c | 18 ++
> > > > > > > 1 file changed, 18 insertions(+)
> > > > > > >
> > > > > > > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > > > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > > > index 88dde3455bfd..b5fe6d2ad22f 100644
> > > > > > > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > > > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > > > @@ -87,6 +87,7 @@ struct mlx5_vq_restore_info {
> > > > > > > u64 device_addr;
> > > > > > > u64 driver_addr;
> > > > > > > u16 avail_index;
> > > > > > > + u16 used_index;
> > > > > > > bool ready;
> > > > > > > struct vdpa_callback cb;
> > > > > > > bool restore;
> > > > > > > @@ -121,6 +122,7 @@ struct mlx5_vdpa_virtqueue {
> > > > > > > u32 virtq_id;
> > > > > > > struct mlx5_vdpa_net *ndev;
> > > > > > > u16 avail_idx;
> > > > > > > + u16 used_idx;
> > > > > > > int fw_state;
> > > > > > > /* keep last in the struct */
> > > > > > > @@ -804,6 +806,7 @@ static int create_virtqueue(struct
> > > > > > > mlx5_vdpa_net
> > > > > > > *ndev, struct mlx5_vdpa_virtque
> > > > > > > obj_context = MLX5_ADDR_OF(create_virtio_net_q_in, in,
> > > > > > > obj_context);
> > > > > > > MLX5_SET(virtio_net_q_object, obj_context,
> > > > > > > hw_available_index,
> > > > > > > mvq->avail_idx);
> > > > > > > + MLX5_SET(virtio_net_q_object, obj_context, hw_used_index,
> > > > > > > mvq->used_idx);
> > > > > > > MLX5_SET(virtio_net_q_object, obj_context,
> > > > > > > queue_feature_bit_mask_12_3,
> > > > > > > get_features_12_3(ndev->mvdev.actual_features));
> > > > > > > vq_ctx = MLX5_ADDR_OF(virtio_net_q_object, obj_context,
> > > > > > > virtio_q_context);
> > > > > > > @@ -1022,6 +1025,7 @@ static int connect_qps(struct mlx5_vdpa_net
> > > > > > > *ndev, struct mlx5_vdpa_virtqueue *m
> > > > > > > struct mlx5_virtq_attr {
> > > > > > > u8 state;
> > > > > > > u16 available_index;
> > > > > > > + u16 used_index;
> > > > > > > };
> > > > > > > static int query_virtqueue(struct mlx5_vdpa_net *ndev,
> > > > > > > struct
> > > > > > > mlx5_vdpa_virtqueue *mvq,
> > > > > > > @@ -1052,6 +1056,7 @@ static int query_virtqueue(struct
> > > > > > > mlx5_vdpa_net *ndev, struct mlx5_vdpa_virtqueu
> > > > > > > memset(attr, 0, sizeof(*attr));
> > > > > > > attr->state = MLX5_GET(virtio_net_q_object, obj_context,
> > > > > > > state);
> > > > > > > attr->available_index = MLX5_GET(virtio_net_q_object,
> > > > > > > obj_context, hw_available_index);
> > > > > > > + attr->used_index = MLX5_GET(virtio_net_q_object, obj_context,
> > > > > > > hw_used_index);
> > > > > > > kfree(out);
> > > > > > > return 0;
> > > > > > > @@ -1535,6 +1540,16 @@ static void teardown_virtqueues(struct
> > > > > > > mlx5_vdpa_net *ndev)
> > > > > > > }
> > > > > > > }
> > > > > > > +static void clear_virtqueues(struct mlx5_vdpa_net *ndev)
> > > > > > > +{
> > > > > > > + int i;
> > > > > > > +
> > > > > > > + for (i = ndev->mvdev.max_vqs - 1; i >= 0; i--) {
> > > > > > > + ndev->vqs[i].avail_idx = 0;
> > > > > > > + ndev->vqs[i].used_idx = 0;
> > > > > > > + }
> > > > > > > +}
> > > > > > > +
> > > > > > > /* TODO: cross-endian support */
> > > > > > > static inline bool mlx5_vdpa_is_little_endian(struct
> > > > > > > mlx5_vdpa_dev
> > > > > > > *mvdev)
> > > > > > > {
> > > > > > > @@ -1610,6 +1625,7 @@ static int save_channel_info(struct
> > > > > > > mlx5_vdpa_net *ndev, struct mlx5_vdpa_virtqu
>
DMA direct mapping fix for 5.4 and earlier stable branches
Hi Christoph, Greg,
Currently we are observing an incorrect address translation
corresponding to DMA direct mapping methods on 5.4 stable kernel while
sharing dmabuf from one device to another where both devices have
their own coherent DMA memory pools.
I am able to root cause this issue which is caused by incorrect virt
to phys translation for addresses belonging to vmalloc space using
virt_to_page(). But while looking at the mainline kernel, this patch
[1] changes address translation from virt->to->phys to dma->to->phys
which fixes the issue observed on 5.4 stable kernel as well (minimal
fix [2]).
So I would like to seek your suggestion for backport to stable kernels
(5.4 or earlier) as to whether we should backport the complete
mainline commit [1] or we should just apply the minimal fix [2]?
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34dc0ea6bc960f1f57b2148f01a3f4da23f87013
[2] minimal fix required for 5.4 stable kernel:
commit bb0b3ff6e54d78370b6b0c04426f0d9192f31795
Author: Sumit Garg
Date: Wed Feb 3 13:08:37 2021 +0530
dma-mapping: Fix common get_sgtable and mmap methods
Currently common get_sgtable and mmap methods can only handle normal
kernel addresses leading to incorrect handling of vmalloc addresses which
is common means for DMA coherent memory mapping.
So instead of cpu_addr, directly decode the physical address from
dma_addr and
hence decode corresponding page and pfn values. In this way we can handle
normal kernel addresses as well as vmalloc addresses.
This fix is inspired from following mainline commit:
34dc0ea6bc96 ("dma-direct: provide mmap and get_sgtable method overrides")
This fixes an issue observed during dmabuf sharing from one device to
another where both devices have their own coherent DMA memory pools.
Signed-off-by: Sumit Garg
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index 8682a53..034bbae 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -127,7 +127,7 @@ int dma_common_get_sgtable(struct device *dev,
struct sg_table *sgt,
return -ENXIO;
page = pfn_to_page(pfn);
} else {
- page = virt_to_page(cpu_addr);
+ page = pfn_to_page(PHYS_PFN(dma_to_phys(dev, dma_addr)));
}
ret = sg_alloc_table(sgt, 1, GFP_KERNEL);
@@ -214,7 +214,7 @@ int dma_common_mmap(struct device *dev, struct
vm_area_struct *vma,
if (!pfn_valid(pfn))
return -ENXIO;
} else {
- pfn = page_to_pfn(virt_to_page(cpu_addr));
+ pfn = PHYS_PFN(dma_to_phys(dev, dma_addr));
}
return remap_pfn_range(vma, vma->vm_start, pfn + vma->vm_pgoff,
Re: [PATCH] staging: hikey9xx: fix checkpatch error and warning
On Tue, Feb 09, 2021 at 11:27:04AM +0530, Atul Gopinathan wrote: > Fix the following types of checkpatch error and warning: > > ERROR: code indent should use tabs where possible > WARNING: struct phy_ops should normally be const That is 2 different things, which means this should be 2 different patches. Please make this a patch series and resend. thanks, greg k-h
Re: [RFC][PATCH 2/2] dma-buf: heaps: Fix the name used when exporting dmabufs to be the actual heap name
On Mon, Feb 8, 2021 at 10:03 PM Sumit Semwal wrote: > > Hi Daniel, > > On Tue, 9 Feb 2021 at 02:36, Daniel Vetter wrote: > > > > On Mon, Feb 8, 2021 at 9:51 PM John Stultz wrote: > > > On Mon, Feb 8, 2021 at 2:08 AM Daniel Vetter wrote: > > > > On Sat, Feb 06, 2021 at 05:47:48AM +, John Stultz wrote: > > > > > By default dma_buf_export() sets the exporter name to be > > > > > KBUILD_MODNAME. Unfortunately this may not be identical to the > > > > > string used as the heap name (ie: "system" vs "system_heap"). > > > > > > > > > > This can cause some minor confusion with tooling, and there is > > > > > the future potential where multiple heap types may be exported > > > > > by the same module (but would all have the same name). > > > > > > > > > > So to avoid all this, set the exporter exp_name to the heap name. > > > > > > > > > > Cc: Daniel Vetter > > > > > Cc: Sumit Semwal > > > > > Cc: Liam Mark > > > > > Cc: Chris Goldsworthy > > > > > Cc: Laura Abbott > > > > > Cc: Brian Starkey > > > > > Cc: Hridya Valsaraju > > > > > Cc: Suren Baghdasaryan > > > > > Cc: Sandeep Patil > > > > > Cc: Daniel Mentz > > > > > Cc: Ørjan Eide > > > > > Cc: Robin Murphy > > > > > Cc: Ezequiel Garcia > > > > > Cc: Simon Ser > > > > > Cc: James Jones > > > > > Cc: linux-me...@vger.kernel.org > > > > > Cc: dri-de...@lists.freedesktop.org > > > > > Signed-off-by: John Stultz > > > > > > > > Looks reasonable to me. > > > > > > > > I guess the main worry is "does this mean heap names become uapi", in > > > > which case I'm maybe not so sure anymore how this will tie into the > > > > overall gpu memory accounting story. > > > > > > > > Since for dma-buf heaps one name per buffer is perfectly fine, since > > > > dma-buf heaps aren't very dynamic. But on discrete gpu drivers buffers > > > > move, so baking in the assumption that "exporter name = resource usage > > > > for > > > > this buffer" is broken. > > > > > > I suspect I'm missing a subtlety in what you're describing. My sense > > > of the exporter name doesn't account for a buffer's usage, it just > > > describes what code allocated it and implicitly which dmabuf_ops > > > handles it. Maybe could you give a more specific example of what > > > you're hoping to avoid? > > > > Just paranoia really - on the linux side where we allocate most > > buffers (even shared ones) with the driver, that allocator info isn't > > that meaningful, it really just tells you which code > > allocated/exported that dma-buf. > > > > But on Android, where all shared buffers come from specific heaps, it > > is rather meaningful information. So I wondered whether e.g. the > > android dmabuf debug tool uses that to collect per-heap stats, but > > sounds like no right now. Plus with the chat we've had I think we have > > a long-term plan for how to expose that information properly. > > > > > To me this patch is mostly just a consistency/least-surprise thing, so > > > the heaps exporter name matches the string used for the heap's chardev > > > device (the interface used to allocate it) in output like > > > debugfs/dma_buf/bufinfo. > > > > Yeah for debug this makes sense. a-b: me if you want that somewhere on > > the patches. > > Great that this got sorted; I'll apply both the patches of this series > to drm-misc-next, with your a-b. Before you do, let me spin a v2 as I got some minor tweaks needed (using const char*) to fix the kbuild bot errors. thanks -john
Re: [RFC][PATCH 2/2] dma-buf: heaps: Fix the name used when exporting dmabufs to be the actual heap name
Hi Daniel, On Tue, 9 Feb 2021 at 02:36, Daniel Vetter wrote: > > On Mon, Feb 8, 2021 at 9:51 PM John Stultz wrote: > > On Mon, Feb 8, 2021 at 2:08 AM Daniel Vetter wrote: > > > On Sat, Feb 06, 2021 at 05:47:48AM +, John Stultz wrote: > > > > By default dma_buf_export() sets the exporter name to be > > > > KBUILD_MODNAME. Unfortunately this may not be identical to the > > > > string used as the heap name (ie: "system" vs "system_heap"). > > > > > > > > This can cause some minor confusion with tooling, and there is > > > > the future potential where multiple heap types may be exported > > > > by the same module (but would all have the same name). > > > > > > > > So to avoid all this, set the exporter exp_name to the heap name. > > > > > > > > Cc: Daniel Vetter > > > > Cc: Sumit Semwal > > > > Cc: Liam Mark > > > > Cc: Chris Goldsworthy > > > > Cc: Laura Abbott > > > > Cc: Brian Starkey > > > > Cc: Hridya Valsaraju > > > > Cc: Suren Baghdasaryan > > > > Cc: Sandeep Patil > > > > Cc: Daniel Mentz > > > > Cc: Ørjan Eide > > > > Cc: Robin Murphy > > > > Cc: Ezequiel Garcia > > > > Cc: Simon Ser > > > > Cc: James Jones > > > > Cc: linux-me...@vger.kernel.org > > > > Cc: dri-de...@lists.freedesktop.org > > > > Signed-off-by: John Stultz > > > > > > Looks reasonable to me. > > > > > > I guess the main worry is "does this mean heap names become uapi", in > > > which case I'm maybe not so sure anymore how this will tie into the > > > overall gpu memory accounting story. > > > > > > Since for dma-buf heaps one name per buffer is perfectly fine, since > > > dma-buf heaps aren't very dynamic. But on discrete gpu drivers buffers > > > move, so baking in the assumption that "exporter name = resource usage for > > > this buffer" is broken. > > > > I suspect I'm missing a subtlety in what you're describing. My sense > > of the exporter name doesn't account for a buffer's usage, it just > > describes what code allocated it and implicitly which dmabuf_ops > > handles it. Maybe could you give a more specific example of what > > you're hoping to avoid? > > Just paranoia really - on the linux side where we allocate most > buffers (even shared ones) with the driver, that allocator info isn't > that meaningful, it really just tells you which code > allocated/exported that dma-buf. > > But on Android, where all shared buffers come from specific heaps, it > is rather meaningful information. So I wondered whether e.g. the > android dmabuf debug tool uses that to collect per-heap stats, but > sounds like no right now. Plus with the chat we've had I think we have > a long-term plan for how to expose that information properly. > > > To me this patch is mostly just a consistency/least-surprise thing, so > > the heaps exporter name matches the string used for the heap's chardev > > device (the interface used to allocate it) in output like > > debugfs/dma_buf/bufinfo. > > Yeah for debug this makes sense. a-b: me if you want that somewhere on > the patches. Great that this got sorted; I'll apply both the patches of this series to drm-misc-next, with your a-b. > -Daniel Best Sumit. > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- Thanks and regards, Sumit Semwal Linaro Consumer Group - Tech Lead Linaro.org │ Open source software for ARM SoCs
RE: [RESEND PATCH v3 2/2] usb: dwc3: Add driver for Xilinx platforms
Hi Michael,
> -Original Message-
> From: Michael Grzeschik
> Sent: Tuesday, February 9, 2021 5:26 AM
> To: Manish Narani
> Cc: devicet...@vger.kernel.org; p.za...@pengutronix.de; ba...@kernel.org;
> gre...@linuxfoundation.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; robh...@kernel.org; Michal Simek
> ; git ; ker...@pengutronix.de; linux-
> arm-ker...@lists.infradead.org
> Subject: Re: [RESEND PATCH v3 2/2] usb: dwc3: Add driver for Xilinx
> platforms
>
> Hi Manish!
>
> On Thu, Jan 28, 2021 at 12:36:07AM +0100, Michael Grzeschik wrote:
> >On Fri, Jan 22, 2021 at 02:34:52PM +0100, Michael Grzeschik wrote:
> >>On Fri, Jan 22, 2021 at 01:06:22PM +, Manish Narani wrote:
> >>>Hi Michael,
> >>>
> -Original Message-
> From: Michael Grzeschik
> Sent: Friday, January 22, 2021 1:39 PM
> To: Manish Narani
> Cc: devicet...@vger.kernel.org; ker...@pengutronix.de;
> ba...@kernel.org;
> gre...@linuxfoundation.org; linux-...@vger.kernel.org; Michal Simek
> ; linux-kernel@vger.kernel.org;
> robh...@kernel.org;
> git ; p.za...@pengutronix.de; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [RESEND PATCH v3 2/2] usb: dwc3: Add driver for Xilinx
> platforms
>
> Hello!
>
> On Mon, Jan 18, 2021 at 02:42:24PM +0100, Michael Grzeschik wrote:
> >Hi!
> >
> >On Tue, Dec 15, 2020 at 12:24:51PM +0530, Manish Narani wrote:
> >>Add a new driver for supporting Xilinx platforms. This driver is used
> >>for some sequence of operations required for Xilinx USB controllers.
> >>This driver is also used to choose between PIPE clock coming from
> SerDes
> >>and the Suspend Clock. Before the controller is out of reset, the clock
> >>selection should be changed to PIPE clock in order to make the USB
> >>controller work. There is a register added in Xilinx USB controller
> >>register space for the same.
> >
> >I tried out this driver with the vanilla kernel on an zynqmp. Without
> >this patch the USB-Gadget is already acting buggy. In the gadget mode,
> >some iterations of plug/unplug results to an stalled gadget which will
> >never come back without a reboot.
> >
> >With the corresponding code of this driver (reset assert, clk modify,
> >reset deassert) in the downstream kernels phy driver we found out it is
> >totaly stable. But using this exact glue driver which should do the same
> >as the downstream code, the gadget still was buggy the way described
> >above.
> >
> >I suspect the difference lays in the different order of operations.
> >While the downstream code is runing the resets inside the phy driver
> >which is powered and initialized in the dwc3-core itself. With this glue
> >layser approach of this patch the whole phy init is done before even
> >touching dwc3-core in any way. It seems not to have the same effect,
> >though.
> >
> >If really the order of operations is limiting us, we probably need
> >another solution than this glue layer. Any Ideas?
>
> I found out what the difference between the Downstream and this
> Glue is. When using vanilla with this Glue code we may not set
> the following bit:
>
> https://www.xilinx.com/html_docs/registers/ug1087/ug1087-zynq-
> ultrascale-registers.html#usb3_regs___fpd_power_prsnt.html
>
> >>+ /* Set PIPE Power Present signal in FPD Power Present
> Register*/
> >>+ writel(PIPE_POWER_ON, priv_data->regs +
> XLNX_USB_FPD_POWER_PRSNT);
>
> When I comment this out, the link stays stable. This is different in
> the Downstream Xilinx Kernel, where the bit is also set but has no
> negativ effect.
>
> Manish, can you give me a pointer what to look for?
> So setting this will also work with mainline?
> >>>I am looking further on this but from what I see here is that,
> >>>In order to make USB function properly, there are some dt changes
> needed in mainline for
> >>>USB node which include defining clocks coming from serdes.
> >>>The DT changes are pending to be sent to mainline.
> >>
> >>Can you push that state somewhere, so I could test it?
> >>Or is in the downstream kernel some things to copy?
> >>
> >>>Can you share the DT settings for USB node on your side?
> >>
> >>Here is my current configuration for the device node at usb0:
> >>
> >>zynqmp.dtsi
> >>
> >>zynqmp_reset: reset-controller {
> >>compatible = "xlnx,zynqmp-reset";
> >>#reset-cells = <1>;
> >>};
> >>
> >>usb0: usb@ff9d {
> >>#address-cells = <2>;
> >>#size-cells = <2>;
> >>status = "disabled";
> >>compatible = "xlnx,zynqmp-dwc3";
> >>reg = <0x0 0xff9d 0x0 0x100>;
> >>clock-names = "bus_clk", "ref_clk";
> >>power-domains = <&zynqmp_firmware PD_USB_0>;
> >>ranges;
> >>resets = <&zynqmp_reset ZYNQMP_RESET_USB0_CORERESET>,
> >><&zynqmp_reset ZYNQMP_RESET_USB0_
Re: [PATCH v5 09/22] powerpc/syscall: Make interrupt.c buildable on PPC32
Le 09/02/2021 à 02:27, Nicholas Piggin a écrit :
Excerpts from Christophe Leroy's message of February 9, 2021 1:10 am:
To allow building interrupt.c on PPC32, ifdef out specific PPC64
code or use helpers which are available on both PP32 and PPC64
Modify Makefile to always build interrupt.o
Signed-off-by: Christophe Leroy
---
v5:
- Also for interrupt exit preparation
- Opted out kuap related code, ppc32 keeps it in ASM for the time being
---
arch/powerpc/kernel/Makefile| 4 ++--
arch/powerpc/kernel/interrupt.c | 31 ---
2 files changed, 26 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kernel/interrupt.c b/arch/powerpc/kernel/interrupt.c
index d6be4f9a67e5..2dac4d2bb1cf 100644
--- a/arch/powerpc/kernel/interrupt.c
+++ b/arch/powerpc/kernel/interrupt.c
@@ -39,7 +39,7 @@ notrace long system_call_exception(long r3, long r4, long r5,
BUG_ON(!(regs->msr & MSR_RI));
BUG_ON(!(regs->msr & MSR_PR));
BUG_ON(!FULL_REGS(regs));
- BUG_ON(regs->softe != IRQS_ENABLED);
+ BUG_ON(arch_irq_disabled_regs(regs));
#ifdef CONFIG_PPC_PKEY
if (mmu_has_feature(MMU_FTR_PKEY)) {
@@ -65,7 +65,9 @@ notrace long system_call_exception(long r3, long r4, long r5,
isync();
} else
#endif
+#ifdef CONFIG_PPC64
kuap_check_amr();
+#endif
Wouldn't mind trying to get rid of these ifdefs at some point, but
there's some kuap / keys changes going on recently so I'm happy enough
to let this settle then look at whether we can refactor.
I have a follow up series that implements interrupts entries/exits in C and that removes all kuap
assembly, I will likely release it as RFC later today.
account_cpu_user_entry();
@@ -318,7 +323,7 @@ notrace unsigned long syscall_exit_prepare(unsigned long r3,
return ret;
}
-#ifdef CONFIG_PPC_BOOK3S /* BOOK3E not yet using this */
+#ifndef CONFIG_PPC_BOOK3E_64 /* BOOK3E not yet using this */
notrace unsigned long interrupt_exit_user_prepare(struct pt_regs *regs,
unsigned long msr)
{
#ifdef CONFIG_PPC_BOOK3E
Why are you building this for 32? I don't mind if it's just to keep
things similar and make it build for now, but you're not using it yet,
right?
The series using that will follow, I thought it would be worth doing this at
once.
Reviewed-by: Nicholas Piggin
[PATCH] staging: hikey9xx: fix checkpatch error and warning
Fix the following types of checkpatch error and warning:
ERROR: code indent should use tabs where possible
WARNING: struct phy_ops should normally be const
Signed-off-by: Atul Gopinathan
---
drivers/staging/hikey9xx/hi6421-spmi-pmic.c | 2 +-
drivers/staging/hikey9xx/hi6421v600-regulator.c | 2 +-
drivers/staging/hikey9xx/phy-hi3670-usb3.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/hikey9xx/hi6421-spmi-pmic.c
b/drivers/staging/hikey9xx/hi6421-spmi-pmic.c
index 2301f4fcd48d..9c5e113e1a81 100644
--- a/drivers/staging/hikey9xx/hi6421-spmi-pmic.c
+++ b/drivers/staging/hikey9xx/hi6421-spmi-pmic.c
@@ -177,7 +177,7 @@ static void hi6421_spmi_pmic_irq_init(struct
hi6421_spmi_pmic *ddata)
for (i = 0; i < HISI_IRQ_ARRAY; i++)
regmap_write(ddata->regmap, SOC_PMIC_IRQ_MASK_0_ADDR + i,
- HISI_MASK);
+ HISI_MASK);
for (i = 0; i < HISI_IRQ_ARRAY; i++) {
regmap_read(ddata->regmap, SOC_PMIC_IRQ0_ADDR + i, &pending);
diff --git a/drivers/staging/hikey9xx/hi6421v600-regulator.c
b/drivers/staging/hikey9xx/hi6421v600-regulator.c
index c801bb840962..f6a14e9c3cbf 100644
--- a/drivers/staging/hikey9xx/hi6421v600-regulator.c
+++ b/drivers/staging/hikey9xx/hi6421v600-regulator.c
@@ -106,7 +106,7 @@ static int hi6421_spmi_regulator_enable(struct
regulator_dev *rdev)
ret = regmap_update_bits(pmic->regmap, rdev->desc->enable_reg,
rdev->desc->enable_mask,
-rdev->desc->enable_mask);
+rdev->desc->enable_mask);
/* Avoid powering up multiple devices at the same time */
usleep_range(rdev->desc->off_on_delay, rdev->desc->off_on_delay + 60);
diff --git a/drivers/staging/hikey9xx/phy-hi3670-usb3.c
b/drivers/staging/hikey9xx/phy-hi3670-usb3.c
index 8918f3665f8e..e7e579ce0302 100644
--- a/drivers/staging/hikey9xx/phy-hi3670-usb3.c
+++ b/drivers/staging/hikey9xx/phy-hi3670-usb3.c
@@ -585,7 +585,7 @@ static int hi3670_phy_exit(struct phy *phy)
return ret;
}
-static struct phy_ops hi3670_phy_ops = {
+static const struct phy_ops hi3670_phy_ops = {
.init = hi3670_phy_init,
.exit = hi3670_phy_exit,
.owner = THIS_MODULE,
--
2.27.0
Re: [PATCH v5 05/22] powerpc/irq: Add helper to set regs->softe
Le 09/02/2021 à 02:11, Nicholas Piggin a écrit :
Excerpts from Christophe Leroy's message of February 9, 2021 1:10 am:
regs->softe doesn't exist on PPC32.
Add irq_soft_mask_regs_set_state() helper to set regs->softe.
This helper will void on PPC32.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/hw_irq.h | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/hw_irq.h
b/arch/powerpc/include/asm/hw_irq.h
index 614957f74cee..ed0c3b049dfd 100644
--- a/arch/powerpc/include/asm/hw_irq.h
+++ b/arch/powerpc/include/asm/hw_irq.h
@@ -38,6 +38,8 @@
#define PACA_IRQ_MUST_HARD_MASK (PACA_IRQ_EE)
#endif
+#endif /* CONFIG_PPC64 */
+
/*
* flags for paca->irq_soft_mask
*/
@@ -46,8 +48,6 @@
#define IRQS_PMI_DISABLED 2
#define IRQS_ALL_DISABLED (IRQS_DISABLED | IRQS_PMI_DISABLED)
-#endif /* CONFIG_PPC64 */
-
#ifndef __ASSEMBLY__
#ifdef CONFIG_PPC64
@@ -287,6 +287,10 @@ extern void irq_set_pending_from_srr1(unsigned long srr1);
extern void force_external_irq_replay(void);
+static inline void irq_soft_mask_regs_set_state(struct pt_regs *regs, unsigned long val)
+{
+ regs->softe = val;
+}
#else /* CONFIG_PPC64 */
static inline unsigned long arch_local_save_flags(void)
@@ -355,6 +359,9 @@ static inline bool arch_irq_disabled_regs(struct pt_regs
*regs)
static inline void may_hard_irq_enable(void) { }
+static inline void irq_soft_mask_regs_set_state(struct pt_regs *regs, unsigned long val)
+{
+}
#endif /* CONFIG_PPC64 */
#define ARCH_IRQ_INIT_FLAGS IRQ_NOREQUEST
What I don't like about this where you use it is it kind of pollutes
the ppc32 path with this function which is not valid to use.
I would prefer if you had this purely so it could compile with:
if (IS_ENABLED(CONFIG_PPC64)))
irq_soft_mask_regs_set_state(regs, blah);
And then you could make the ppc32 cause a link error if it did not
get eliminated at compile time (e.g., call an undefined function).
You could do the same with the kuap_ functions to change some ifdefs
to IS_ENABLED.
That's just my preference but if you prefer this way I guess that's
okay.
I see you didn't change your mind since last April :)
I'll see what I can do.
Christophe
Re: [PATCH 5.4 00/65] 5.4.97-rc1 review
On Mon, 8 Feb 2021 at 20:41, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.4.97 release. > There are 65 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed, 10 Feb 2021 14:57:55 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.97-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.4.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing Summary kernel: 5.4.97-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.4.y git commit: 7b6a7cd488bf6be0b5d83709c148c3d69c737a15 git describe: v5.4.96-66-g7b6a7cd488bf Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.96-66-g7b6a7cd488bf No regressions (compared to build v5.4.96) No fixes (compared to build v5.4.96) Ran 50496 total tests in the following environments and test suites. Environments -- - arc - arm - arm64 - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - juno-r2-compat - juno-r2-kasan - mips - nxp-ls2088 - nxp-ls2088-64k_page_size - parisc - powerpc - qemu-arm-clang - qemu-arm64-clang - qemu-arm64-kasan - qemu-x86_64-clang - qemu-x86_64-kasan - qemu-x86_64-kcsan - qemu_arm - qemu_arm64 - qemu_arm64-compat - qemu_i386 - qemu_x86_64 - qemu_x86_64-compat - riscv - s390 - sh - sparc - x15 - x86 - x86-kasan - x86_64 Test Suites --- * build * linux-log-parser * libhugetlbfs * ltp-commands-tests * ltp-cve-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-securebits-tests * v4l2-compliance * fwts * install-android-platform-tools-r2600 * kselftest-android * kselftest-bpf * kselftest-capabilities * kselftest-cgroup * kselftest-clone3 * kselftest-core * kselftest-cpu-hotplug * kselftest-cpufreq * kselftest-efivarfs * kselftest-filesystems * kselftest-firmware * kselftest-fpu * kselftest-futex * kselftest-gpio * kselftest-intel_pstate * kselftest-ipc * kselftest-ir * kselftest-kcmp * kselftest-kvm * kselftest-lib * kselftest-livepatch * kselftest-lkdtm * kselftest-membarrier * kselftest-memfd * kselftest-memory-hotplug * kselftest-mincore * kselftest-mount * kselftest-mqueue * kselftest-net * kselftest-netfilter * kselftest-nsfs * kselftest-openat2 * kselftest-pid_namespace * kselftest-pidfd * kselftest-proc * kselftest-pstore * kselftest-ptrace * kselftest-rseq * kselftest-rtc * kselftest-seccomp * kselftest-sigaltstack * kselftest-size * kselftest-splice * kselftest-static_keys * kselftest-sync * kselftest-sysctl * kselftest-tc-testing * kselftest-timens * kselftest-timers * kselftest-tmpfs * kselftest-tpm2 * kselftest-user * kselftest-zram * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-mm-tests * ltp-sched-tests * ltp-tracing-tests * network-basic-tests * perf * kselftest-kexec * kselftest-vm * kselftest-x86 * ltp-controllers-tests * ltp-dio-tests * ltp-io-tests * ltp-open-posix-tests * ltp-syscalls-tests * kvm-unit-tests * rcutorture * kselftest-vsyscall-mode-none- * ssuite -- Linaro LKFT https://lkft.linaro.org
[PATCH] RISC-V: Enable CPU Hotplug in defconfigs
The CPU hotplug support has been tested on QEMU, Spike, and SiFive Unleashed so let's enable it by default in RV32 and RV64 defconfigs. Signed-off-by: Anup Patel --- arch/riscv/configs/defconfig | 1 + arch/riscv/configs/rv32_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig index 8c3d1e451703..6c0625aa96c7 100644 --- a/arch/riscv/configs/defconfig +++ b/arch/riscv/configs/defconfig @@ -17,6 +17,7 @@ CONFIG_BPF_SYSCALL=y CONFIG_SOC_SIFIVE=y CONFIG_SOC_VIRT=y CONFIG_SMP=y +CONFIG_HOTPLUG_CPU=y CONFIG_JUMP_LABEL=y CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y diff --git a/arch/riscv/configs/rv32_defconfig b/arch/riscv/configs/rv32_defconfig index 2c2cda6cc1c5..8dd02b842fef 100644 --- a/arch/riscv/configs/rv32_defconfig +++ b/arch/riscv/configs/rv32_defconfig @@ -18,6 +18,7 @@ CONFIG_SOC_SIFIVE=y CONFIG_SOC_VIRT=y CONFIG_ARCH_RV32I=y CONFIG_SMP=y +CONFIG_HOTPLUG_CPU=y CONFIG_JUMP_LABEL=y CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y -- 2.25.1
RE: [Linuxarm] Re: [PATCH for-next 00/32] spin lock usage optimization for SCSI drivers
> -Original Message- > From: Song Bao Hua (Barry Song) > Sent: Tuesday, February 9, 2021 6:28 PM > To: 'Finn Thain' > Cc: tanxiaofei ; j...@linux.ibm.com; > martin.peter...@oracle.com; linux-s...@vger.kernel.org; > linux-kernel@vger.kernel.org; linux...@openeuler.org; > linux-m...@vger.kernel.org > Subject: RE: [Linuxarm] Re: [PATCH for-next 00/32] spin lock usage > optimization > for SCSI drivers > > > > > -Original Message- > > From: Finn Thain [mailto:fth...@telegraphics.com.au] > > Sent: Tuesday, February 9, 2021 6:06 PM > > To: Song Bao Hua (Barry Song) > > Cc: tanxiaofei ; j...@linux.ibm.com; > > martin.peter...@oracle.com; linux-s...@vger.kernel.org; > > linux-kernel@vger.kernel.org; linux...@openeuler.org; > > linux-m...@vger.kernel.org > > Subject: RE: [Linuxarm] Re: [PATCH for-next 00/32] spin lock usage > > optimization > > for SCSI drivers > > > > On Tue, 9 Feb 2021, Song Bao Hua (Barry Song) wrote: > > > > > > -Original Message- > > > > From: Finn Thain [mailto:fth...@telegraphics.com.au] > > > > Sent: Monday, February 8, 2021 8:57 PM > > > > To: tanxiaofei > > > > Cc: j...@linux.ibm.com; martin.peter...@oracle.com; > > > > linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org; > > > > linux...@openeuler.org > > > > Subject: [Linuxarm] Re: [PATCH for-next 00/32] spin lock usage > > > > optimization > > > > for SCSI drivers > > > > > > > > On Sun, 7 Feb 2021, Xiaofei Tan wrote: > > > > > > > > > Replace spin_lock_irqsave with spin_lock in hard IRQ of SCSI drivers. > > > > > There are no function changes, but may speed up if interrupt happen > too > > > > > often. > > > > > > > > This change doesn't necessarily work on platforms that support nested > > > > interrupts. > > > > > > > > Were you able to measure any benefit from this change on some other > > > > platform? > > > > > > I think the code disabling irq in hardIRQ is simply wrong. > > > Since this commit > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ > > ?id=e58aa3d2d0cc > > > genirq: Run irq handlers with interrupts disabled > > > > > > interrupt handlers are definitely running in a irq-disabled context > > > unless irq handlers enable them explicitly in the handler to permit > > > other interrupts. > > > > > > > Repeating the same claim does not somehow make it true. If you put your > > Sorry for I didn't realize xiaofei had replied. > > > claim to the test, you'll see that that interrupts are not disabled on > > m68k when interrupt handlers execute. > > Sounds like an implementation issue of m68k since IRQF_DISABLED has > been totally removed. > > > > > The Interrupt Priority Level (IPL) can prevent any given irq handler from > > being re-entered, but an irq with a higher priority level may be handled > > during execution of a lower priority irq handler. > > > > We used to have IRQF_DISABLED to support so-called "fast interrupt" to avoid > this. But the concept has been totally removed. That is interesting if m68k > still has this issue. > > > sonic_interrupt() uses an irq lock within an interrupt handler to avoid > > issues relating to this. This kind of locking may be needed in the drivers > > you are trying to patch. Or it might not. Apparently, no-one has looked. Is the comment in sonic_interrupt() outdated according to this: m68k: irq: Remove IRQF_DISABLED https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=77a4279 http://lkml.iu.edu/hypermail/linux/kernel/1109.2/01687.html and this: genirq: Warn when handler enables interrupts https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b738a50a wouldn't genirq report a warning on m68k? > > Thanks > Barry Thanks Barry
Re: [PATCH] vdpa/mlx5: fix param validation in mlx5_vdpa_get_config()
On Mon, Feb 08, 2021 at 05:17:41PM +0100, Stefano Garzarella wrote:
> It's legal to have 'offset + len' equal to
> sizeof(struct virtio_net_config), since 'ndev->config' is a
> 'struct virtio_net_config', so we can safely copy its content under
> this condition.
>
> Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Stefano Garzarella
Acked-by: Eli Cohen
BTW, same error in vdpa_sim you may want to fix.
> ---
> drivers/vdpa/mlx5/net/mlx5_vnet.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> index dc88559a8d49..10e9b09932eb 100644
> --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> @@ -1820,7 +1820,7 @@ static void mlx5_vdpa_get_config(struct vdpa_device
> *vdev, unsigned int offset,
> struct mlx5_vdpa_dev *mvdev = to_mvdev(vdev);
> struct mlx5_vdpa_net *ndev = to_mlx5_vdpa_ndev(mvdev);
>
> - if (offset + len < sizeof(struct virtio_net_config))
> + if (offset + len <= sizeof(struct virtio_net_config))
> memcpy(buf, (u8 *)&ndev->config + offset, len);
> }
>
> --
> 2.29.2
>
RE: [Linuxarm] Re: [PATCH for-next 00/32] spin lock usage optimization for SCSI drivers
> -Original Message- > From: Finn Thain [mailto:fth...@telegraphics.com.au] > Sent: Tuesday, February 9, 2021 6:06 PM > To: Song Bao Hua (Barry Song) > Cc: tanxiaofei ; j...@linux.ibm.com; > martin.peter...@oracle.com; linux-s...@vger.kernel.org; > linux-kernel@vger.kernel.org; linux...@openeuler.org; > linux-m...@vger.kernel.org > Subject: RE: [Linuxarm] Re: [PATCH for-next 00/32] spin lock usage > optimization > for SCSI drivers > > On Tue, 9 Feb 2021, Song Bao Hua (Barry Song) wrote: > > > > -Original Message- > > > From: Finn Thain [mailto:fth...@telegraphics.com.au] > > > Sent: Monday, February 8, 2021 8:57 PM > > > To: tanxiaofei > > > Cc: j...@linux.ibm.com; martin.peter...@oracle.com; > > > linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org; > > > linux...@openeuler.org > > > Subject: [Linuxarm] Re: [PATCH for-next 00/32] spin lock usage > > > optimization > > > for SCSI drivers > > > > > > On Sun, 7 Feb 2021, Xiaofei Tan wrote: > > > > > > > Replace spin_lock_irqsave with spin_lock in hard IRQ of SCSI drivers. > > > > There are no function changes, but may speed up if interrupt happen too > > > > often. > > > > > > This change doesn't necessarily work on platforms that support nested > > > interrupts. > > > > > > Were you able to measure any benefit from this change on some other > > > platform? > > > > I think the code disabling irq in hardIRQ is simply wrong. > > Since this commit > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ > ?id=e58aa3d2d0cc > > genirq: Run irq handlers with interrupts disabled > > > > interrupt handlers are definitely running in a irq-disabled context > > unless irq handlers enable them explicitly in the handler to permit > > other interrupts. > > > > Repeating the same claim does not somehow make it true. If you put your Sorry for I didn't realize xiaofei had replied. > claim to the test, you'll see that that interrupts are not disabled on > m68k when interrupt handlers execute. Sounds like an implementation issue of m68k since IRQF_DISABLED has been totally removed. > > The Interrupt Priority Level (IPL) can prevent any given irq handler from > being re-entered, but an irq with a higher priority level may be handled > during execution of a lower priority irq handler. > We used to have IRQF_DISABLED to support so-called "fast interrupt" to avoid this. But the concept has been totally removed. That is interesting if m68k still has this issue. > sonic_interrupt() uses an irq lock within an interrupt handler to avoid > issues relating to this. This kind of locking may be needed in the drivers > you are trying to patch. Or it might not. Apparently, no-one has looked. Thanks Barry
Re: [PATCH v2] mm: cma: support sysfs
On 2/8/21 9:18 PM, John Hubbard wrote: On 2/8/21 8:19 PM, Minchan Kim wrote: On Mon, Feb 08, 2021 at 05:57:17PM -0800, John Hubbard wrote: On 2/8/21 3:36 PM, Minchan Kim wrote: ... char name[CMA_MAX_NAME]; +#ifdef CONFIG_CMA_SYSFS + struct cma_stat *stat; This should not be a pointer. By making it a pointer, you've added a bunch of pointless extra code to the implementation. Originally, I went with the object lifetime with struct cma as you suggested to make code simple. However, Greg KH wanted to have release for kobj_type since it is consistent with other kboject handling. Are you talking about the kobj in your new struct cma_stat? That seems like circular logic if so. I'm guessing Greg just wanted kobj methods to be used *if* you are dealing with kobjects. That's a narrower point. I can't imagine that he would have insisted on having additional allocations just so that kobj freeing methods could be used. :) I have no objection if Greg agree static kobject is okay in this case. Greg? What I meant is, no kobject at all in the struct cma_stat member variable. The lifetime of the cma_stat member is the same as the containing struct, so no point in putting a kobject into it. ...unless...are you actually *wanting* to keep the lifetimes separate? Hmmm, given the short nature of sysfs reads, though, I'd be inclined to just let the parent object own the lifetime. But maybe I'm missing some design point here? thanks, -- John Hubbard NVIDIA
[PATCH] mm/mlock: minor coding style tweaks
This patch move the pointer location to fix coding style issues,
improve code reading.
Signed-off-by: Zhiyuan Dai
---
mm/mlock.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/mlock.c b/mm/mlock.c
index 55b3b36..f6e26c2 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -560,7 +560,7 @@ static int apply_vma_lock_flags(unsigned long start, size_t
len,
vm_flags_t flags)
{
unsigned long nstart, end, tmp;
- struct vm_area_struct * vma, * prev;
+ struct vm_area_struct *vma, *prev;
int error;
VM_BUG_ON(offset_in_page(start));
@@ -738,7 +738,7 @@ static __must_check int do_mlock(unsigned long start,
size_t len, vm_flags_t fla
*/
static int apply_mlockall_flags(int flags)
{
- struct vm_area_struct * vma, * prev = NULL;
+ struct vm_area_struct *vma, *prev = NULL;
vm_flags_t to_add = 0;
current->mm->def_flags &= VM_LOCKED_CLEAR_MASK;
--
1.8.3.1
Re: [PATCH 25/49] perf/x86/rapl: Add support for Intel Alder Lake
Hi,
I love your patch! Yet something to improve:
[auto build test ERROR on tip/perf/core]
[cannot apply to tip/master linus/master tip/x86/core v5.11-rc6 next-20210125]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/kan-liang-linux-intel-com/Add-Alder-Lake-support-for-perf/20210209-070642
base: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
32451614da2a9cf4296f90d3606ac77814fb519d
config: x86_64-randconfig-a014-20210209 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
c9439ca36342fb6013187d0a69aef92736951476)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
#
https://github.com/0day-ci/linux/commit/f02aa47253758867fa7f74a286fde01ed042ac42
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
kan-liang-linux-intel-com/Add-Alder-Lake-support-for-perf/20210209-070642
git checkout f02aa47253758867fa7f74a286fde01ed042ac42
# 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 >>):
>> arch/x86/events/rapl.c:804:2: error: use of undeclared identifier
>> 'INTEL_FAM6_ALDERLAKE_L'
X86_MATCH_INTEL_FAM6_MODEL(ALDERLAKE_L, &model_skl),
^
arch/x86/include/asm/cpu_device_id.h:161:39: note: expanded from macro
'X86_MATCH_INTEL_FAM6_MODEL'
X86_MATCH_VENDOR_FAM_MODEL(INTEL, 6, INTEL_FAM6_##model, data)
^
:149:1: note: expanded from here
INTEL_FAM6_ALDERLAKE_L
^
1 error generated.
vim +/INTEL_FAM6_ALDERLAKE_L +804 arch/x86/events/rapl.c
772
773 static const struct x86_cpu_id rapl_model_match[] __initconst = {
774 X86_MATCH_INTEL_FAM6_MODEL(SANDYBRIDGE, &model_snb),
775 X86_MATCH_INTEL_FAM6_MODEL(SANDYBRIDGE_X, &model_snbep),
776 X86_MATCH_INTEL_FAM6_MODEL(IVYBRIDGE, &model_snb),
777 X86_MATCH_INTEL_FAM6_MODEL(IVYBRIDGE_X, &model_snbep),
778 X86_MATCH_INTEL_FAM6_MODEL(HASWELL, &model_hsw),
779 X86_MATCH_INTEL_FAM6_MODEL(HASWELL_X, &model_hsx),
780 X86_MATCH_INTEL_FAM6_MODEL(HASWELL_L, &model_hsw),
781 X86_MATCH_INTEL_FAM6_MODEL(HASWELL_G, &model_hsw),
782 X86_MATCH_INTEL_FAM6_MODEL(BROADWELL, &model_hsw),
783 X86_MATCH_INTEL_FAM6_MODEL(BROADWELL_G, &model_hsw),
784 X86_MATCH_INTEL_FAM6_MODEL(BROADWELL_X, &model_hsx),
785 X86_MATCH_INTEL_FAM6_MODEL(BROADWELL_D, &model_hsx),
786 X86_MATCH_INTEL_FAM6_MODEL(XEON_PHI_KNL,&model_knl),
787 X86_MATCH_INTEL_FAM6_MODEL(XEON_PHI_KNM,&model_knl),
788 X86_MATCH_INTEL_FAM6_MODEL(SKYLAKE_L, &model_skl),
789 X86_MATCH_INTEL_FAM6_MODEL(SKYLAKE, &model_skl),
790 X86_MATCH_INTEL_FAM6_MODEL(SKYLAKE_X, &model_hsx),
791 X86_MATCH_INTEL_FAM6_MODEL(KABYLAKE_L, &model_skl),
792 X86_MATCH_INTEL_FAM6_MODEL(KABYLAKE,&model_skl),
793 X86_MATCH_INTEL_FAM6_MODEL(CANNONLAKE_L,&model_skl),
794 X86_MATCH_INTEL_FAM6_MODEL(ATOM_GOLDMONT, &model_hsw),
795 X86_MATCH_INTEL_FAM6_MODEL(ATOM_GOLDMONT_D, &model_hsw),
796 X86_MATCH_INTEL_FAM6_MODEL(ATOM_GOLDMONT_PLUS, &model_hsw),
797 X86_MATCH_INTEL_FAM6_MODEL(ICELAKE_L, &model_skl),
798 X86_MATCH_INTEL_FAM6_MODEL(ICELAKE, &model_skl),
799 X86_MATCH_INTEL_FAM6_MODEL(ICELAKE_D, &model_hsx),
800 X86_MATCH_INTEL_FAM6_MODEL(ICELAKE_X, &model_hsx),
801 X86_MATCH_INTEL_FAM6_MODEL(COMETLAKE_L, &model_skl),
802 X86_MATCH_INTEL_FAM6_MODEL(COMETLAKE, &model_skl),
803 X86_MATCH_INTEL_FAM6_MODEL(ALDERLAKE, &model_skl),
> 804 X86_MATCH_INTEL_FAM6_MODEL(ALDERLAKE_L, &model_skl),
805 X86_MATCH_INTEL_FAM6_MODEL(SAPPHIRERAPIDS_X,&model_spr),
806 X86_MATCH_VENDOR_FAM(AMD, 0x17,
&model_amd_fam17h),
807 X86_MATCH_VENDOR_FAM(HYGON, 0x18,
&model_amd_fam17h),
808 X86_MATCH_VENDOR_FAM(AMD, 0x19,
Re: [PATCH] selftests/bpf: Simplify the calculation of variables
On Thu, Feb 4, 2021 at 10:27 PM Jiapeng Chong
wrote:
>
> Fix the following coccicheck warnings:
>
> ./tools/testing/selftests/bpf/xdpxceiver.c:954:28-30: WARNING !A || A &&
> B is equivalent to !A || B.
>
> ./tools/testing/selftests/bpf/xdpxceiver.c:932:28-30: WARNING !A || A &&
> B is equivalent to !A || B.
>
> ./tools/testing/selftests/bpf/xdpxceiver.c:909:28-30: WARNING !A || A &&
> B is equivalent to !A || B.
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong
> ---
This doesn't apply cleanly onto bpf-next anymore. Please rebase and
re-submit. Make sure to include [PATCH bpf-next] prefix in your email
subject. Thanks!
> tools/testing/selftests/bpf/xdpxceiver.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/tools/testing/selftests/bpf/xdpxceiver.c
> b/tools/testing/selftests/bpf/xdpxceiver.c
> index 1e722ee..98ad4a2 100644
> --- a/tools/testing/selftests/bpf/xdpxceiver.c
> +++ b/tools/testing/selftests/bpf/xdpxceiver.c
> @@ -906,7 +906,7 @@ static void *worker_testapp_validate(void *arg)
> ksft_print_msg("Destroying socket\n");
> }
>
> - if (!opt_bidi || (opt_bidi && bidi_pass)) {
> + if (!opt_bidi || bidi_pass) {
> xsk_socket__delete(((struct ifobject *)arg)->xsk->xsk);
> (void)xsk_umem__delete(((struct ifobject *)arg)->umem->umem);
> }
> @@ -929,7 +929,7 @@ static void testapp_validate(void)
> pthread_mutex_lock(&sync_mutex);
>
> /*Spawn RX thread */
> - if (!opt_bidi || (opt_bidi && !bidi_pass)) {
> + if (!opt_bidi || !bidi_pass) {
> if (pthread_create(&t0, &attr, worker_testapp_validate, (void
> *)ifdict[1]))
> exit_with_error(errno);
> } else if (opt_bidi && bidi_pass) {
> @@ -951,7 +951,7 @@ static void testapp_validate(void)
> pthread_mutex_unlock(&sync_mutex);
>
> /*Spawn TX thread */
> - if (!opt_bidi || (opt_bidi && !bidi_pass)) {
> + if (!opt_bidi || !bidi_pass) {
> if (pthread_create(&t1, &attr, worker_testapp_validate, (void
> *)ifdict[0]))
> exit_with_error(errno);
> } else if (opt_bidi && bidi_pass) {
> --
> 1.8.3.1
>
Re: [PATCH v2] mm: cma: support sysfs
On 2/8/21 8:19 PM, Minchan Kim wrote: On Mon, Feb 08, 2021 at 05:57:17PM -0800, John Hubbard wrote: On 2/8/21 3:36 PM, Minchan Kim wrote: ... char name[CMA_MAX_NAME]; +#ifdef CONFIG_CMA_SYSFS + struct cma_stat *stat; This should not be a pointer. By making it a pointer, you've added a bunch of pointless extra code to the implementation. Originally, I went with the object lifetime with struct cma as you suggested to make code simple. However, Greg KH wanted to have release for kobj_type since it is consistent with other kboject handling. Are you talking about the kobj in your new struct cma_stat? That seems like circular logic if so. I'm guessing Greg just wanted kobj methods to be used *if* you are dealing with kobjects. That's a narrower point. I can't imagine that he would have insisted on having additional allocations just so that kobj freeing methods could be used. :) I have no objection if Greg agree static kobject is okay in this case. Greg? What I meant is, no kobject at all in the struct cma_stat member variable. The lifetime of the cma_stat member is the same as the containing struct, so no point in putting a kobject into it. thanks, -- John Hubbard NVIDIA
Re: [PATCH 23/49] perf/x86/msr: Add Alder Lake CPU support
Hi,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on tip/perf/core]
[cannot apply to tip/master linus/master tip/x86/core v5.11-rc6 next-20210125]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/kan-liang-linux-intel-com/Add-Alder-Lake-support-for-perf/20210209-070642
base: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
32451614da2a9cf4296f90d3606ac77814fb519d
config: x86_64-randconfig-a013-20210209 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
c9439ca36342fb6013187d0a69aef92736951476)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
#
https://github.com/0day-ci/linux/commit/ef3d3e5028f5f70a78fa37d642e8e7e65c60dee7
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
kan-liang-linux-intel-com/Add-Alder-Lake-support-for-perf/20210209-070642
git checkout ef3d3e5028f5f70a78fa37d642e8e7e65c60dee7
# 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 >>):
>> arch/x86/events/msr.c:104:7: error: use of undeclared identifier
>> 'INTEL_FAM6_ALDERLAKE_L'
case INTEL_FAM6_ALDERLAKE_L:
^
1 error generated.
vim +/INTEL_FAM6_ALDERLAKE_L +104 arch/x86/events/msr.c
39
40 static bool test_intel(int idx, void *data)
41 {
42 if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL ||
43 boot_cpu_data.x86 != 6)
44 return false;
45
46 switch (boot_cpu_data.x86_model) {
47 case INTEL_FAM6_NEHALEM:
48 case INTEL_FAM6_NEHALEM_G:
49 case INTEL_FAM6_NEHALEM_EP:
50 case INTEL_FAM6_NEHALEM_EX:
51
52 case INTEL_FAM6_WESTMERE:
53 case INTEL_FAM6_WESTMERE_EP:
54 case INTEL_FAM6_WESTMERE_EX:
55
56 case INTEL_FAM6_SANDYBRIDGE:
57 case INTEL_FAM6_SANDYBRIDGE_X:
58
59 case INTEL_FAM6_IVYBRIDGE:
60 case INTEL_FAM6_IVYBRIDGE_X:
61
62 case INTEL_FAM6_HASWELL:
63 case INTEL_FAM6_HASWELL_X:
64 case INTEL_FAM6_HASWELL_L:
65 case INTEL_FAM6_HASWELL_G:
66
67 case INTEL_FAM6_BROADWELL:
68 case INTEL_FAM6_BROADWELL_D:
69 case INTEL_FAM6_BROADWELL_G:
70 case INTEL_FAM6_BROADWELL_X:
71
72 case INTEL_FAM6_ATOM_SILVERMONT:
73 case INTEL_FAM6_ATOM_SILVERMONT_D:
74 case INTEL_FAM6_ATOM_AIRMONT:
75
76 case INTEL_FAM6_ATOM_GOLDMONT:
77 case INTEL_FAM6_ATOM_GOLDMONT_D:
78 case INTEL_FAM6_ATOM_GOLDMONT_PLUS:
79 case INTEL_FAM6_ATOM_TREMONT_D:
80 case INTEL_FAM6_ATOM_TREMONT:
81 case INTEL_FAM6_ATOM_TREMONT_L:
82
83 case INTEL_FAM6_XEON_PHI_KNL:
84 case INTEL_FAM6_XEON_PHI_KNM:
85 if (idx == PERF_MSR_SMI)
86 return true;
87 break;
88
89 case INTEL_FAM6_SKYLAKE_L:
90 case INTEL_FAM6_SKYLAKE:
91 case INTEL_FAM6_SKYLAKE_X:
92 case INTEL_FAM6_KABYLAKE_L:
93 case INTEL_FAM6_KABYLAKE:
94 case INTEL_FAM6_COMETLAKE_L:
95 case INTEL_FAM6_COMETLAKE:
96 case INTEL_FAM6_ICELAKE_L:
97 case INTEL_FAM6_ICELAKE:
98 case INTEL_FAM6_ICELAKE_X:
99 case INTEL_FAM6_ICELAKE_D:
100 case INTEL_FAM6_TIGERLAKE_L:
101 case INTEL_FAM6_TIGERLAKE:
102 case INTEL_FAM6_ROCKETLAKE:
103 case INTEL_FAM6_ALDERLAKE:
> 104 case INTEL_FAM6_ALDERLAKE_L:
105 if (idx == PERF_MSR_SMI || idx == PERF_MSR_PPERF)
106 return true;
107 break;
108 }
109
110 return false;
111 }
112
---
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 for-next 00/32] spin lock usage optimization for SCSI drivers
On Tue, 9 Feb 2021, tanxiaofei wrote: > Hi Finn, > Thanks for reviewing the patch set. > > On 2021/2/8 15:57, Finn Thain wrote: > > On Sun, 7 Feb 2021, Xiaofei Tan wrote: > > > > > Replace spin_lock_irqsave with spin_lock in hard IRQ of SCSI drivers. > > > There are no function changes, but may speed up if interrupt happen too > > > often. > > > > This change doesn't necessarily work on platforms that support nested > > interrupts. > > > > Linux doesn't support nested interrupts anymore after the following > patch, so please don't worry this. > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e58aa3d2d0cc > Clearly that patch did not disable interrupts. It removed a statement that enabled them. > > Were you able to measure any benefit from this change on some other > > platform? > > > > It's hard to measure the benefit of this change. It's hard to see any benefit. But it's easy to see risk, when there's no indication that you've confirmed that the affected drivers do not rely on the irq lock, nor tested them for regressions, nor checked whether the affected platforms meet your assumuptions. > Hmm, you could take this patch set as cleanup. thanks. > A "cleanup" does not change program behaviour. Can you demonstrate that program behaviour is unchanged? > > Please see also, > > https://lore.kernel.org/linux-scsi/89c5cb05cb844939ae684db0077f6...@h3c.com/ > > > > . > > > >
[PATCH] mm/slub: minor coding style tweaks
This patch adds whitespace to fix coding style issues, improve code reading. Signed-off-by: Zhiyuan Dai --- mm/slub.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/slub.c b/mm/slub.c index 7ecbbbe..3313897 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -3266,7 +3266,7 @@ void kmem_cache_free_bulk(struct kmem_cache *s, size_t size, void **p) if (!df.page) continue; - slab_free(df.s, df.page, df.freelist, df.tail, df.cnt,_RET_IP_); + slab_free(df.s, df.page, df.freelist, df.tail, df.cnt, _RET_IP_); } while (likely(size)); } EXPORT_SYMBOL(kmem_cache_free_bulk); -- 1.8.3.1
[PATCH v2 17/17] KVM: arm64: Add async PF document
This adds document to explain the interface for asynchronous page fault and how it works in general. Signed-off-by: Gavin Shan --- Documentation/virt/kvm/arm/apf.rst | 143 +++ Documentation/virt/kvm/arm/index.rst | 1 + 2 files changed, 144 insertions(+) create mode 100644 Documentation/virt/kvm/arm/apf.rst diff --git a/Documentation/virt/kvm/arm/apf.rst b/Documentation/virt/kvm/arm/apf.rst new file mode 100644 index ..4f5c01b6699f --- /dev/null +++ b/Documentation/virt/kvm/arm/apf.rst @@ -0,0 +1,143 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Asynchronous Page Fault Support for arm64 += + +There are two stages of page faults when KVM module is enabled as accelerator +to the guest. The guest is responsible for handling the stage-1 page faults, +while the host handles the stage-2 page faults. During the period of handling +the stage-2 page faults, the guest is suspended until the requested page is +ready. It could take several milliseconds, even hundreds of milliseconds in +extreme situations because I/O might be required to move the requested page +from disk to DRAM. The guest does not do any work when it is suspended. The +feature (Asynchronous Page Fault) is introduced to take advantage of the +suspending period and to improve the overall performance. + +There are two paths in order to fulfil the asynchronous page fault, called +as control path and data path. The control path allows the VMM or guest to +configure the functionality, while the notifications are delivered in data +path. The notifications are classified into page-not-present and page-ready +notifications. + +Data Path +- + +There are two types of notifications delivered from host to guest in the +data path: page-not-present and page-ready notification. They are delivered +through SDEI event and (PPI) interrupt separately. Besides, there is a shared +buffer between host and guest to indicate the reason and sequential token, +which is used to identify the asynchronous page fault. The reason and token +resident in the shared buffer is written by host, read and cleared by guest. +An asynchronous page fault is delivered and completed as below. + +(1) When an asynchronous page fault starts, a (workqueue) worker is created +and queued to the vCPU's pending queue. The worker makes the requested +page ready and resident to DRAM in the background. The shared buffer is +updated with reason and sequential token. After that, SDEI event is sent +to guest as page-not-present notification. + +(2) When the SDEI event is received on guest, the current process is tagged +with TIF_ASYNC_PF and associated with a wait queue. The process is ready +to keep rescheduling itself on switching from kernel to user mode. After +that, a reschedule IPI is sent to current CPU and the received SDEI event +is acknowledged. Note that the IPI is delivered when the acknowledgment +on the SDEI event is received on host. + +(3) On the host, the worker is dequeued from the vCPU's pending queue and +enqueued to its completion queue when the requested page becomes ready. +In the mean while, KVM_REQ_ASYNC_PF request is sent the vCPU if the +worker is the first element enqueued to the completion queue. + +(4) With pending KVM_REQ_ASYNC_PF request, the first worker in the completion +queue is dequeued and destroyed. In the mean while, a (PPI) interrupt is +sent to guest with updated reason and token in the shared buffer. + +(5) When the (PPI) interrupt is received on guest, the affected process is +located using the token and waken up after its TIF_ASYNC_PF tag is cleared. +After that, the interrupt is acknowledged through SMCCC interface. The +workers in the completion queue is dequeued and destroyed if any workers +exist, and another (PPI) interrupt is sent to the guest. + +Control Path + + +The configurations are passed through SMCCC or ioctl interface. The SDEI +event and (PPI) interrupt are owned by VMM, so the SDEI event and interrupt +numbers are configured through ioctl command on per-vCPU basis. Besides, +the functionality might be enabled and configured through ioctl interface +by VMM during migration: + + * KVM_ARM_ASYNC_PF_CMD_GET_VERSION + + Returns the current version of the feature, supported by the host. It is + made up of major, minor and revision fields. Each field is one byte in + length. + + * KVM_ARM_ASYNC_PF_CMD_GET_SDEI: + + Retrieve the SDEI event number, used for page-not-present notification, + so that it can be configured on destination VM in the scenario of + migration. + + * KVM_ARM_ASYNC_PF_GET_IRQ: + + Retrieve the IRQ (PPI) number, used for page-ready notification, so that + it can be configured on destination VM in the scenario of migration. + + * KVM_ARM_ASYNC_PF_CMD_GET_CONTROL + + Retrieve the address of control block, so that it can
[PATCH v2 15/17] arm64: Reschedule process on aync PF
The page-not-present notification is delivered by SDEI event. The
guest reschedules current process to another one when the SDEI event
is received. It's not safe to do so in the SDEI event handler because
the SDEI event should be acknowledged as soon as possible.
So the rescheduling is postponed until the current process switches
from kernel to user mode. In order to trigger the switch, the SDEI
event handler sends (reschedule) IPI to current CPU and it's delivered
in time after the SDEI event is acknowledged.
A new thread flag (TIF_ASYNC_PF) is introduced in order to track the
state for the process, to be rescheduled. With the flag is set, there
is a head of wait-queue is associated with the process. The process
keeps rescheduling itself until the flag is cleared when page-ready
notification is received through (PPI) interrupt.
Signed-off-by: Gavin Shan
---
arch/arm64/include/asm/processor.h | 1 +
arch/arm64/include/asm/thread_info.h | 4 +++-
arch/arm64/kernel/signal.c | 17 +
3 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/processor.h
b/arch/arm64/include/asm/processor.h
index ca2cd75d3286..2176c88c77a7 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -154,6 +154,7 @@ struct thread_struct {
u64 sctlr_tcf0;
u64 gcr_user_excl;
#endif
+ void*data;
};
static inline void arch_thread_struct_whitelist(unsigned long *offset,
diff --git a/arch/arm64/include/asm/thread_info.h
b/arch/arm64/include/asm/thread_info.h
index 9f4e3b266f21..939beb3c7723 100644
--- a/arch/arm64/include/asm/thread_info.h
+++ b/arch/arm64/include/asm/thread_info.h
@@ -65,6 +65,7 @@ void arch_release_task_struct(struct task_struct *tsk);
#define TIF_UPROBE 4 /* uprobe breakpoint or singlestep */
#define TIF_MTE_ASYNC_FAULT5 /* MTE Asynchronous Tag Check Fault */
#define TIF_NOTIFY_SIGNAL 6 /* signal notifications exist */
+#define TIF_ASYNC_PF 7 /* Asynchronous page fault */
#define TIF_SYSCALL_TRACE 8 /* syscall trace active */
#define TIF_SYSCALL_AUDIT 9 /* syscall auditing */
#define TIF_SYSCALL_TRACEPOINT 10 /* syscall tracepoint for ftrace */
@@ -95,11 +96,12 @@ void arch_release_task_struct(struct task_struct *tsk);
#define _TIF_SVE (1 << TIF_SVE)
#define _TIF_MTE_ASYNC_FAULT (1 << TIF_MTE_ASYNC_FAULT)
#define _TIF_NOTIFY_SIGNAL (1 << TIF_NOTIFY_SIGNAL)
+#define _TIF_ASYNC_PF (1 << TIF_ASYNC_PF)
#define _TIF_WORK_MASK (_TIF_NEED_RESCHED | _TIF_SIGPENDING | \
_TIF_NOTIFY_RESUME | _TIF_FOREIGN_FPSTATE | \
_TIF_UPROBE | _TIF_MTE_ASYNC_FAULT | \
-_TIF_NOTIFY_SIGNAL)
+_TIF_NOTIFY_SIGNAL | _TIF_ASYNC_PF)
#define _TIF_SYSCALL_WORK (_TIF_SYSCALL_TRACE | _TIF_SYSCALL_AUDIT | \
_TIF_SYSCALL_TRACEPOINT | _TIF_SECCOMP | \
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index 6237486ff6bb..2cd2d13aa905 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -915,6 +915,23 @@ asmlinkage void do_notify_resume(struct pt_regs *regs,
unsigned long thread_flags)
{
do {
+ if (thread_flags & _TIF_ASYNC_PF) {
+ struct swait_queue_head *wq =
+ READ_ONCE(current->thread.data);
+ DECLARE_SWAITQUEUE(wait);
+
+ local_daif_restore(DAIF_PROCCTX_NOIRQ);
+
+ do {
+ prepare_to_swait_exclusive(wq,
+ &wait, TASK_UNINTERRUPTIBLE);
+ if (!test_thread_flag(TIF_ASYNC_PF))
+ break;
+
+ schedule();
+ } while (test_thread_flag(TIF_ASYNC_PF));
+ }
+
if (thread_flags & _TIF_NEED_RESCHED) {
/* Unmask Debug and SError for the next task */
local_daif_restore(DAIF_PROCCTX_NOIRQ);
--
2.23.0
RE: [Linuxarm] Re: [PATCH for-next 00/32] spin lock usage optimization for SCSI drivers
On Tue, 9 Feb 2021, Song Bao Hua (Barry Song) wrote: > > -Original Message- > > From: Finn Thain [mailto:fth...@telegraphics.com.au] > > Sent: Monday, February 8, 2021 8:57 PM > > To: tanxiaofei > > Cc: j...@linux.ibm.com; martin.peter...@oracle.com; > > linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org; > > linux...@openeuler.org > > Subject: [Linuxarm] Re: [PATCH for-next 00/32] spin lock usage optimization > > for SCSI drivers > > > > On Sun, 7 Feb 2021, Xiaofei Tan wrote: > > > > > Replace spin_lock_irqsave with spin_lock in hard IRQ of SCSI drivers. > > > There are no function changes, but may speed up if interrupt happen too > > > often. > > > > This change doesn't necessarily work on platforms that support nested > > interrupts. > > > > Were you able to measure any benefit from this change on some other > > platform? > > I think the code disabling irq in hardIRQ is simply wrong. > Since this commit > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e58aa3d2d0cc > genirq: Run irq handlers with interrupts disabled > > interrupt handlers are definitely running in a irq-disabled context > unless irq handlers enable them explicitly in the handler to permit > other interrupts. > Repeating the same claim does not somehow make it true. If you put your claim to the test, you'll see that that interrupts are not disabled on m68k when interrupt handlers execute. The Interrupt Priority Level (IPL) can prevent any given irq handler from being re-entered, but an irq with a higher priority level may be handled during execution of a lower priority irq handler. sonic_interrupt() uses an irq lock within an interrupt handler to avoid issues relating to this. This kind of locking may be needed in the drivers you are trying to patch. Or it might not. Apparently, no-one has looked.
