* Re: [PATCH] media: mediatek: vcodec: Handle invalid decoder vsi
From: Irui Wang (王瑞) @ 2024-03-23 1:45 UTC (permalink / raw)
To: matthias.bgg@gmail.com, mchehab@kernel.org,
sebastian.fricke@collabora.com,
angelogioacchino.delregno@collabora.com,
nicolas.dufresne@collabora.com, hverkuil-cisco@xs4all.nl,
Yunfei Dong (董云飞)
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
Maoguang Meng (孟毛广),
linux-mediatek@lists.infradead.org,
Longfei Wang (王龙飞),
Project_Global_Chrome_Upstream_Group
In-Reply-To: <6420a5c39e0a6f85d4fd5a85643d601bd1e2fb05.camel@collabora.com>
Dear Nicolas,
Thanks for your reviewing.
On Fri, 2024-03-22 at 10:44 -0400, Nicolas Dufresne wrote:
> Hi,
>
> Le mercredi 20 mars 2024 à 14:13 +0800, Irui Wang a écrit :
> > Handle invalid decoder vsi in vpu_dec_init to ensure the decoder
> > vsi is
> > valid for future use.
> >
> > Signed-off-by: Irui Wang <irui.wang@mediatek.com>
> > ---
> > .../media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c | 6
> > ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git
> > a/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c
> > b/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c
> > index 82e57ae983d5..17770993fe5a 100644
> > --- a/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c
> > +++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c
> > @@ -231,6 +231,12 @@ int vpu_dec_init(struct vdec_vpu_inst *vpu)
> > mtk_vdec_debug(vpu->ctx, "vdec_inst=%p", vpu);
> >
> > err = vcodec_vpu_send_msg(vpu, (void *)&msg, sizeof(msg));
> > +
> > + if (IS_ERR_OR_NULL(vpu->vsi)) {
> > + mtk_vdec_err(vpu->ctx, "invalid vdec vsi, status=%d",
> > err);
> > + return -EINVAL;
> > + }
> > +
>
> Make sense, though on the cosmetic side, were is the err value from
> if the vsi
> pointer is NULL ?
Do you mean the returned 'err'?, it's the status value returned by
'send message'. Even if the 'vsi' is NULL, the returned status value
'err' may still be 'NO_ERROR', there is no direct relationship between
them.
If I misunderstood your question, please correct me. Thank you very
much.
>
> Nicolas
>
> > mtk_vdec_debug(vpu->ctx, "- ret=%d", err);
> > return err;
> > }
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [WIP 0/3] Memory model and atomic API in Rust
From: Kent Overstreet @ 2024-03-23 1:42 UTC (permalink / raw)
To: Boqun Feng
Cc: rust-for-linux, linux-kernel, linux-arch, llvm, Miguel Ojeda,
Alex Gaynor, Wedson Almeida Filho, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Alan Stern,
Andrea Parri, Will Deacon, Peter Zijlstra, Nicholas Piggin,
David Howells, Jade Alglave, Luc Maranget, Paul E. McKenney,
Akira Yokosawa, Daniel Lustig, Joel Fernandes, Nathan Chancellor,
Nick Desaulniers, kent.overstreet, Greg Kroah-Hartman, elver,
Mark Rutland, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Catalin Marinas, torvalds,
linux-arm-kernel, linux-fsdevel
In-Reply-To: <Zf4nE_AvHPx9F2nQ@boqun-archlinux>
On Fri, Mar 22, 2024 at 05:49:23PM -0700, Boqun Feng wrote:
> On Fri, Mar 22, 2024 at 05:15:08PM -0700, Boqun Feng wrote:
> [...]
> > >
> > > I wonder about that. The disadvantage of only supporting LKMM atomics is
> > > that we'll be incompatible with third party code, and we don't want to
> > > be rolling all of our own data structures forever.
> > >
> >
> > A possible solution to that is a set of C++ memory model atomics
> > implemented by LKMM atomics. That should be possible.
> >
>
> Another possible "solution" works in the opposite direction, since the
> folder rust/kernel/sync/atomic is quite stand-alone, we can export that
> as a Rust crate (library), and third party code can support using LKMM
> atomics instead of Rust own atomics ;-) Of course if the project is
> supposed to work with Linux kernel.
Not just from the Rust side, the C side would be useful as well. I've
got a quicky, dirty, hacky version of that in bcachefs-tools, and I
would switch immediately if someone took that over and made it a real
project, and I'm quite sure other projects would as well.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 03/12] mm: Make HPAGE_PXD_* macros even if !THP
From: SeongJae Park @ 2024-03-23 1:05 UTC (permalink / raw)
To: Peter Xu
Cc: SeongJae Park, linux-mm, linux-kernel, linuxppc-dev,
Michael Ellerman, Christophe Leroy, Matthew Wilcox, Rik van Riel,
Lorenzo Stoakes, Axel Rasmussen, Yang Shi, John Hubbard,
linux-arm-kernel, Kirill A . Shutemov, Andrew Jones,
Vlastimil Babka, Mike Rapoport, Andrew Morton, Muchun Song,
Christoph Hellwig, linux-riscv, James Houghton, David Hildenbrand,
Jason Gunthorpe, Andrea Arcangeli, Aneesh Kumar K . V,
Mike Kravetz
In-Reply-To: <Zf4ioDkuSNJ0f1vR@x1n>
Hi Peter,
On Fri, 22 Mar 2024 20:30:24 -0400 Peter Xu <peterx@redhat.com> wrote:
> On Fri, Mar 22, 2024 at 10:14:56AM -0700, SeongJae Park wrote:
> > Hi Peter,
>
> Hi, SeongJae,
>
> >
> > On Thu, 21 Mar 2024 18:07:53 -0400 peterx@redhat.com wrote:
> >
> > > From: Peter Xu <peterx@redhat.com>
> > >
> > > These macros can be helpful when we plan to merge hugetlb code into generic
> > > code. Move them out and define them even if !THP.
> > >
> > > We actually already defined HPAGE_PMD_NR for other reasons even if !THP.
> > > Reorganize these macros.
> > >
> > > Reviewed-by: Christoph Hellwig <hch@infradead.org>
> > > Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
> > > Signed-off-by: Peter Xu <peterx@redhat.com>
> > > ---
> > > include/linux/huge_mm.h | 17 ++++++-----------
> > > 1 file changed, 6 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> > > index de0c89105076..3bcdfc7e5d57 100644
> > > --- a/include/linux/huge_mm.h
> > > +++ b/include/linux/huge_mm.h
> > > @@ -64,9 +64,6 @@ ssize_t single_hugepage_flag_show(struct kobject *kobj,
> > > enum transparent_hugepage_flag flag);
> > > extern struct kobj_attribute shmem_enabled_attr;
> > >
> > > -#define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT)
> > > -#define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
> > > -
> > > /*
> > > * Mask of all large folio orders supported for anonymous THP; all orders up to
> > > * and including PMD_ORDER, except order-0 (which is not "huge") and order-1
> > > @@ -87,14 +84,19 @@ extern struct kobj_attribute shmem_enabled_attr;
> > > #define thp_vma_allowable_order(vma, vm_flags, smaps, in_pf, enforce_sysfs, order) \
> > > (!!thp_vma_allowable_orders(vma, vm_flags, smaps, in_pf, enforce_sysfs, BIT(order)))
> > >
> > > -#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> > > #define HPAGE_PMD_SHIFT PMD_SHIFT
> > > #define HPAGE_PMD_SIZE ((1UL) << HPAGE_PMD_SHIFT)
> > > #define HPAGE_PMD_MASK (~(HPAGE_PMD_SIZE - 1))
> > > +#define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT)
> > > +#define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
> > >
> > > #define HPAGE_PUD_SHIFT PUD_SHIFT
> > > #define HPAGE_PUD_SIZE ((1UL) << HPAGE_PUD_SHIFT)
> > > #define HPAGE_PUD_MASK (~(HPAGE_PUD_SIZE - 1))
> > > +#define HPAGE_PUD_ORDER (HPAGE_PUD_SHIFT-PAGE_SHIFT)
> > > +#define HPAGE_PUD_NR (1<<HPAGE_PUD_ORDER)
> >
> > I just found latest mm-unstable fails one of my build configurations[1] with
> > below error. 'git bisect' says this is the first patch set started the
> > failure. I haven't looked in deep, but just reporting first.
> >
> > In file included from .../include/linux/mm.h:1115,
> > from .../mm/vmstat.c:14:
> > .../mm/vmstat.c: In function 'zoneinfo_show_print':
> > .../include/linux/huge_mm.h:87:25: error: 'PMD_SHIFT' undeclared (first use in this function); did you mean 'PUD_SHIFT'?
> > 87 | #define HPAGE_PMD_SHIFT PMD_SHIFT
> > | ^~~~~~~~~
> >
> > [1] https://github.com/awslabs/damon-tests/blob/next/corr/tests/build_m68k.sh
>
> Apologies for the issue.
No problem at all, this blocks nothing in real :)
> This is caused by !CONFIG_MMU, I think.
>
> I thought this would be fairly easy to fix by putting these macros under
> CONFIG_PGTABLE_HAS_HUGE_LEAVES, however when doing this I could have found
> some other issue that violates this rule.. mm/vmstat.c has referenced
> HPAGE_PMD_NR even if vmstat_item_print_in_thp() wanted to guard it only
> with CONFIG_THP.
>
> /home/peterx/git/linux/mm/vmstat.c: In function 'zoneinfo_show_print':
> /home/peterx/git/linux/mm/vmstat.c:1689:42: error: 'HPAGE_PMD_NR' undeclared (first use in this function)
> 1689 | pages /= HPAGE_PMD_NR;
> | ^~~~~~~~~~~~
> /home/peterx/git/linux/mm/vmstat.c:1689:42: note: each undeclared identifier is reported only once for each function it appears in
> CC drivers/tty/tty_port.o
> /home/peterx/git/linux/mm/vmstat.c: In function 'vmstat_start':
> /home/peterx/git/linux/mm/vmstat.c:1822:33: error: 'HPAGE_PMD_NR' undeclared (first use in this function)
> 1822 | v[i] /= HPAGE_PMD_NR;
> | ^~~~~~~~~~~~
> make[4]: *** [/home/peterx/git/linux/scripts/Makefile.build:243: mm/vmstat.o] Error 1
>
> static __always_inline bool vmstat_item_print_in_thp(enum node_stat_item item)
> {
> if (!IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE))
> return false;
> ...
> }
>
> I think the problem is vmstat_item_print_in_thp() uses IS_ENABLED() however
> that won't stop compiler from looking into the "if".. so it'll still try to
> find the HPAGE_PMD_NR macro.
>
> It means, I may need to further change vmstat_item_print_in_thp() to make
> this work in the clean way.. by properly switching to a #ifdef.
>
> For that I'll need to post a formal patch and add people to review. I'll
> keep you posted.
Thank you for this kind explanation, all makes sense to me. Looking forward to
the patch.
>
> Side note: thank you for your script, just to mention make.cross has been
> moved to kbuild/, and it'll also need kbuild.sh now to work. So you may
> want to fix your test script (and it worked for you because you kept the
> old make.cross around), like:
>
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/kbuild/make.cross -O ./bin/make.cross
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/kbuild/kbuild.sh -O ./bin/kbuild.sh
And thank you so much for this nice suggestion. I'll revisit the script soon.
Thanks,
SJ
>
> Thanks,
>
> --
> Peter Xu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [WIP 0/3] Memory model and atomic API in Rust
From: Boqun Feng @ 2024-03-23 0:49 UTC (permalink / raw)
To: Kent Overstreet
Cc: rust-for-linux, linux-kernel, linux-arch, llvm, Miguel Ojeda,
Alex Gaynor, Wedson Almeida Filho, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Alan Stern,
Andrea Parri, Will Deacon, Peter Zijlstra, Nicholas Piggin,
David Howells, Jade Alglave, Luc Maranget, Paul E. McKenney,
Akira Yokosawa, Daniel Lustig, Joel Fernandes, Nathan Chancellor,
Nick Desaulniers, kent.overstreet, Greg Kroah-Hartman, elver,
Mark Rutland, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Catalin Marinas, torvalds,
linux-arm-kernel, linux-fsdevel
In-Reply-To: <Zf4fDJNBeRN5HOYo@boqun-archlinux>
On Fri, Mar 22, 2024 at 05:15:08PM -0700, Boqun Feng wrote:
[...]
> >
> > I wonder about that. The disadvantage of only supporting LKMM atomics is
> > that we'll be incompatible with third party code, and we don't want to
> > be rolling all of our own data structures forever.
> >
>
> A possible solution to that is a set of C++ memory model atomics
> implemented by LKMM atomics. That should be possible.
>
Another possible "solution" works in the opposite direction, since the
folder rust/kernel/sync/atomic is quite stand-alone, we can export that
as a Rust crate (library), and third party code can support using LKMM
atomics instead of Rust own atomics ;-) Of course if the project is
supposed to work with Linux kernel.
Regards,
Boqun
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 12/12] mm/gup: Handle hugetlb in the generic follow_page_mask code
From: Peter Xu @ 2024-03-23 0:45 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-mm, linux-kernel, linuxppc-dev, Michael Ellerman,
Christophe Leroy, Matthew Wilcox, Rik van Riel, Lorenzo Stoakes,
Axel Rasmussen, Yang Shi, John Hubbard, linux-arm-kernel,
Kirill A . Shutemov, Andrew Jones, Vlastimil Babka, Mike Rapoport,
Muchun Song, Christoph Hellwig, linux-riscv, James Houghton,
David Hildenbrand, Jason Gunthorpe, Andrea Arcangeli,
Aneesh Kumar K . V, Mike Kravetz
In-Reply-To: <20240322134818.9b312f77629f79fcf1564b6f@linux-foundation.org>
On Fri, Mar 22, 2024 at 01:48:18PM -0700, Andrew Morton wrote:
> On Thu, 21 Mar 2024 18:08:02 -0400 peterx@redhat.com wrote:
>
> > From: Peter Xu <peterx@redhat.com>
> >
> > Now follow_page() is ready to handle hugetlb pages in whatever form, and
> > over all architectures. Switch to the generic code path.
> >
> > Time to retire hugetlb_follow_page_mask(), following the previous
> > retirement of follow_hugetlb_page() in 4849807114b8.
> >
> > There may be a slight difference of how the loops run when processing slow
> > GUP over a large hugetlb range on cont_pte/cont_pmd supported archs: each
> > loop of __get_user_pages() will resolve one pgtable entry with the patch
> > applied, rather than relying on the size of hugetlb hstate, the latter may
> > cover multiple entries in one loop.
> >
> > A quick performance test on an aarch64 VM on M1 chip shows 15% degrade over
> > a tight loop of slow gup after the path switched. That shouldn't be a
> > problem because slow-gup should not be a hot path for GUP in general: when
> > page is commonly present, fast-gup will already succeed, while when the
> > page is indeed missing and require a follow up page fault, the slow gup
> > degrade will probably buried in the fault paths anyway. It also explains
> > why slow gup for THP used to be very slow before 57edfcfd3419 ("mm/gup:
> > accelerate thp gup even for "pages != NULL"") lands, the latter not part of
> > a performance analysis but a side benefit. If the performance will be a
> > concern, we can consider handle CONT_PTE in follow_page().
> >
> > Before that is justified to be necessary, keep everything clean and simple.
> >
>
> mm/gup.c:33:21: warning: 'follow_hugepd' declared 'static' but never defined [-Wunused-function]
> 33 | static struct page *follow_hugepd(struct vm_area_struct *vma, hugepd_t hugepd,
> | ^~~~~~~~~~~~~
>
> --- a/mm/gup.c~mm-gup-handle-hugepd-for-follow_page-fix
> +++ a/mm/gup.c
> @@ -30,10 +30,12 @@ struct follow_page_context {
> unsigned int page_mask;
> };
>
> +#ifdef CONFIG_HAVE_FAST_GUP
> static struct page *follow_hugepd(struct vm_area_struct *vma, hugepd_t hugepd,
> unsigned long addr, unsigned int pdshift,
> unsigned int flags,
> struct follow_page_context *ctx);
> +#endif
>
> static inline void sanity_check_pinned_pages(struct page **pages,
> unsigned long npages)
> _
>
>
> This looks inelegant.
>
> That's two build issues so far. Please be more expansive in the
> Kconfig variations when testing. Especially when mucking with pgtable
> macros.
Andrew,
Apologies for that, and also for a slightly late response. Yeah it's time
I'll need my set of things to do serious build tests, and I'll at least
start to cover a few error prone configs/archs in with that.
I was trying to rely on the build bot in many of previous such cases, as
that was quite useful to me to cover many build issues without investing my
own test setups, but I think for some reason it retired and stopped working
for a while. Maybe I shouldn't have relied on it at all.
For this specific issue, I'm not sure if CONFIG_HAVE_FAST_GUP is proper?
As follow_hugepd() is used in slow gup not fast. So maybe we can put that
under CONFIG_MMU below that code (and I think we can drop "static" too as I
don't think it's anything useful). My version of fixup attached at the end
of email, and I verified it on m68k build.
I do plan to post a small fixup series to fix these issues (so far it may
contain 1 formal patch to touch up vmstat_item_print_in_thp, and 2 fixups
where I'll mark the subject with "fixup!" properly). Either you can pick
up below or you can wait for my small patchset, should be there either
today or tomorrow.
Thanks,
===8<===
diff --git a/mm/gup.c b/mm/gup.c
index 4cd349390477..a2ed8203495a 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -30,11 +30,6 @@ struct follow_page_context {
unsigned int page_mask;
};
-static struct page *follow_hugepd(struct vm_area_struct *vma, hugepd_t hugepd,
- unsigned long addr, unsigned int pdshift,
- unsigned int flags,
- struct follow_page_context *ctx);
-
static inline void sanity_check_pinned_pages(struct page **pages,
unsigned long npages)
{
@@ -505,6 +500,12 @@ static inline void mm_set_has_pinned_flag(unsigned long *mm_flags)
}
#ifdef CONFIG_MMU
+
+struct page *follow_hugepd(struct vm_area_struct *vma, hugepd_t hugepd,
+ unsigned long addr, unsigned int pdshift,
+ unsigned int flags,
+ struct follow_page_context *ctx);
+
static struct page *no_page_table(struct vm_area_struct *vma,
unsigned int flags, unsigned long address)
{
===8<===
--
Peter Xu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [WIP 0/3] Memory model and atomic API in Rust
From: Linus Torvalds @ 2024-03-23 0:36 UTC (permalink / raw)
To: Kent Overstreet
Cc: Boqun Feng, rust-for-linux, linux-kernel, linux-arch, llvm,
Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Alan Stern, Andrea Parri, Will Deacon, Peter Zijlstra,
Nicholas Piggin, David Howells, Jade Alglave, Luc Maranget,
Paul E. McKenney, Akira Yokosawa, Daniel Lustig, Joel Fernandes,
Nathan Chancellor, Nick Desaulniers, kent.overstreet,
Greg Kroah-Hartman, elver, Mark Rutland, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Catalin Marinas, linux-arm-kernel, linux-fsdevel
In-Reply-To: <u2suttqa4c423q4ojehbucaxsm6wguqtgouj7vudp55jmuivq3@okzfgryarwnv>
On Fri, 22 Mar 2024 at 17:21, Kent Overstreet <kent.overstreet@linux.dev> wrote:
>
> Besides that there's cross arch support to think about - it's hard to
> imagine us ever ditching our own atomics.
Well, that's one of the advantages of using compiler builtins -
projects that do want cross-architecture support, but that aren't
actually maintaining their _own_ architecture support.
So I very much see the lure of compiler support for that kind of
situation - to write portable code without having to know or care
about architecture details.
This is one reason I think the kernel is kind of odd and special -
because in the kernel, we obviously very fundamentally have to care
about the architecture details _anyway_, so then having the
architecture also define things like atomics is just a pretty small
(and relatively straightforward) detail.
The same argument goes for compiler builtins vs inline asm. In the
kernel, we have to have people who are intimately familiar with the
architecture _anyway_, so inline asms and architecture-specific header
files aren't some big pain-point: they'd be needed _anyway_.
But in some random user level program, where all you want is an
efficient way to do "find first bit"? Then using a compiler intrinsic
makes a lot more sense.
> I was thinking about something more incremental - just an optional mode
> where our atomics were C atomics underneath. It'd probably give the
> compiler people a much more effective way to test their stuff than
> anything they have now.
I suspect it might be painful, and some compiler people would throw
their hands up in horror, because the C++ atomics model is based
fairly solidly on atomic types, and the kernel memory model is much
more fluid.
Boqun already mentioned the "mixing access sizes", which is actually
quite fundamental in the kernel, where we play lots of games with that
(typically around locking, where you find patterns line unlock writing
a zero to a single byte, even though the whole lock data structure is
a word). And sometimes the access size games are very explicit (eg
lib/lockref.c).
But it actually goes deeper than that. While we do have "atomic_t" etc
for arithmetic atomics, and that probably would map fairly well to C++
atomics, in other cases we simply base our atomics not on _types_, but
on code.
IOW, we do things like "cmpxchg()", and the target of that atomic
access is just a regular data structure field.
It's kind of like our "volatile" usage. If you read the C (and C++)
standards, you'll find that you should use "volatile" on data types.
That's almost *never* what the kernel does. The kernel uses "volatile"
in _code_ (ie READ_ONCE() etc), and uses it by casting etc.
Compiler people don't tend to really like those kinds of things.
Linus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 03/12] mm: Make HPAGE_PXD_* macros even if !THP
From: Peter Xu @ 2024-03-23 0:30 UTC (permalink / raw)
To: SeongJae Park
Cc: linux-mm, linux-kernel, linuxppc-dev, Michael Ellerman,
Christophe Leroy, Matthew Wilcox, Rik van Riel, Lorenzo Stoakes,
Axel Rasmussen, Yang Shi, John Hubbard, linux-arm-kernel,
Kirill A . Shutemov, Andrew Jones, Vlastimil Babka, Mike Rapoport,
Andrew Morton, Muchun Song, Christoph Hellwig, linux-riscv,
James Houghton, David Hildenbrand, Jason Gunthorpe,
Andrea Arcangeli, Aneesh Kumar K . V, Mike Kravetz
In-Reply-To: <20240322171456.118997-1-sj@kernel.org>
On Fri, Mar 22, 2024 at 10:14:56AM -0700, SeongJae Park wrote:
> Hi Peter,
Hi, SeongJae,
>
> On Thu, 21 Mar 2024 18:07:53 -0400 peterx@redhat.com wrote:
>
> > From: Peter Xu <peterx@redhat.com>
> >
> > These macros can be helpful when we plan to merge hugetlb code into generic
> > code. Move them out and define them even if !THP.
> >
> > We actually already defined HPAGE_PMD_NR for other reasons even if !THP.
> > Reorganize these macros.
> >
> > Reviewed-by: Christoph Hellwig <hch@infradead.org>
> > Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
> > Signed-off-by: Peter Xu <peterx@redhat.com>
> > ---
> > include/linux/huge_mm.h | 17 ++++++-----------
> > 1 file changed, 6 insertions(+), 11 deletions(-)
> >
> > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> > index de0c89105076..3bcdfc7e5d57 100644
> > --- a/include/linux/huge_mm.h
> > +++ b/include/linux/huge_mm.h
> > @@ -64,9 +64,6 @@ ssize_t single_hugepage_flag_show(struct kobject *kobj,
> > enum transparent_hugepage_flag flag);
> > extern struct kobj_attribute shmem_enabled_attr;
> >
> > -#define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT)
> > -#define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
> > -
> > /*
> > * Mask of all large folio orders supported for anonymous THP; all orders up to
> > * and including PMD_ORDER, except order-0 (which is not "huge") and order-1
> > @@ -87,14 +84,19 @@ extern struct kobj_attribute shmem_enabled_attr;
> > #define thp_vma_allowable_order(vma, vm_flags, smaps, in_pf, enforce_sysfs, order) \
> > (!!thp_vma_allowable_orders(vma, vm_flags, smaps, in_pf, enforce_sysfs, BIT(order)))
> >
> > -#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> > #define HPAGE_PMD_SHIFT PMD_SHIFT
> > #define HPAGE_PMD_SIZE ((1UL) << HPAGE_PMD_SHIFT)
> > #define HPAGE_PMD_MASK (~(HPAGE_PMD_SIZE - 1))
> > +#define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT)
> > +#define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
> >
> > #define HPAGE_PUD_SHIFT PUD_SHIFT
> > #define HPAGE_PUD_SIZE ((1UL) << HPAGE_PUD_SHIFT)
> > #define HPAGE_PUD_MASK (~(HPAGE_PUD_SIZE - 1))
> > +#define HPAGE_PUD_ORDER (HPAGE_PUD_SHIFT-PAGE_SHIFT)
> > +#define HPAGE_PUD_NR (1<<HPAGE_PUD_ORDER)
>
> I just found latest mm-unstable fails one of my build configurations[1] with
> below error. 'git bisect' says this is the first patch set started the
> failure. I haven't looked in deep, but just reporting first.
>
> In file included from .../include/linux/mm.h:1115,
> from .../mm/vmstat.c:14:
> .../mm/vmstat.c: In function 'zoneinfo_show_print':
> .../include/linux/huge_mm.h:87:25: error: 'PMD_SHIFT' undeclared (first use in this function); did you mean 'PUD_SHIFT'?
> 87 | #define HPAGE_PMD_SHIFT PMD_SHIFT
> | ^~~~~~~~~
>
> [1] https://github.com/awslabs/damon-tests/blob/next/corr/tests/build_m68k.sh
Apologies for the issue. This is caused by !CONFIG_MMU, I think.
I thought this would be fairly easy to fix by putting these macros under
CONFIG_PGTABLE_HAS_HUGE_LEAVES, however when doing this I could have found
some other issue that violates this rule.. mm/vmstat.c has referenced
HPAGE_PMD_NR even if vmstat_item_print_in_thp() wanted to guard it only
with CONFIG_THP.
/home/peterx/git/linux/mm/vmstat.c: In function 'zoneinfo_show_print':
/home/peterx/git/linux/mm/vmstat.c:1689:42: error: 'HPAGE_PMD_NR' undeclared (first use in this function)
1689 | pages /= HPAGE_PMD_NR;
| ^~~~~~~~~~~~
/home/peterx/git/linux/mm/vmstat.c:1689:42: note: each undeclared identifier is reported only once for each function it appears in
CC drivers/tty/tty_port.o
/home/peterx/git/linux/mm/vmstat.c: In function 'vmstat_start':
/home/peterx/git/linux/mm/vmstat.c:1822:33: error: 'HPAGE_PMD_NR' undeclared (first use in this function)
1822 | v[i] /= HPAGE_PMD_NR;
| ^~~~~~~~~~~~
make[4]: *** [/home/peterx/git/linux/scripts/Makefile.build:243: mm/vmstat.o] Error 1
static __always_inline bool vmstat_item_print_in_thp(enum node_stat_item item)
{
if (!IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE))
return false;
...
}
I think the problem is vmstat_item_print_in_thp() uses IS_ENABLED() however
that won't stop compiler from looking into the "if".. so it'll still try to
find the HPAGE_PMD_NR macro.
It means, I may need to further change vmstat_item_print_in_thp() to make
this work in the clean way.. by properly switching to a #ifdef.
For that I'll need to post a formal patch and add people to review. I'll
keep you posted.
Side note: thank you for your script, just to mention make.cross has been
moved to kbuild/, and it'll also need kbuild.sh now to work. So you may
want to fix your test script (and it worked for you because you kept the
old make.cross around), like:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/kbuild/make.cross -O ./bin/make.cross
wget https://raw.githubusercontent.com/intel/lkp-tests/master/kbuild/kbuild.sh -O ./bin/kbuild.sh
Thanks,
--
Peter Xu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [WIP 0/3] Memory model and atomic API in Rust
From: Kent Overstreet @ 2024-03-23 0:21 UTC (permalink / raw)
To: Linus Torvalds
Cc: Boqun Feng, rust-for-linux, linux-kernel, linux-arch, llvm,
Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Alan Stern, Andrea Parri, Will Deacon, Peter Zijlstra,
Nicholas Piggin, David Howells, Jade Alglave, Luc Maranget,
Paul E. McKenney, Akira Yokosawa, Daniel Lustig, Joel Fernandes,
Nathan Chancellor, Nick Desaulniers, kent.overstreet,
Greg Kroah-Hartman, elver, Mark Rutland, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Catalin Marinas, linux-arm-kernel, linux-fsdevel
In-Reply-To: <CAHk-=whY5A=S=bLwCFL=043DoR0TTgSDUmfPDx2rXhkk3KANPQ@mail.gmail.com>
On Fri, Mar 22, 2024 at 05:12:29PM -0700, Linus Torvalds wrote:
> On Fri, 22 Mar 2024 at 16:57, Kent Overstreet <kent.overstreet@linux.dev> wrote:
> >
> > I wonder about that. The disadvantage of only supporting LKMM atomics is
> > that we'll be incompatible with third party code, and we don't want to
> > be rolling all of our own data structures forever.
>
> Honestly, having seen the shit-show that is language standards bodies
> and incomplete compiler support, I do not understand why people think
> that we wouldn't want to roll our own.
>
> The C++ memory model may be reliable in another decade. And then a
> decade after *that*, we can drop support for the pre-reliable
> compilers.
>
> People who think that compilers do things right just because they are
> automated simply don't know what they are talking about.
>
> It was just a couple of days ago that I was pointed at
>
> https://github.com/llvm/llvm-project/issues/64188
Besides that there's cross arch support to think about - it's hard to
imagine us ever ditching our own atomics.
I was thinking about something more incremental - just an optional mode
where our atomics were C atomics underneath. It'd probably give the
compiler people a much more effective way to test their stuff than
anything they have now.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [WIP 0/3] Memory model and atomic API in Rust
From: Linus Torvalds @ 2024-03-23 0:12 UTC (permalink / raw)
To: Kent Overstreet
Cc: Boqun Feng, rust-for-linux, linux-kernel, linux-arch, llvm,
Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Alan Stern, Andrea Parri, Will Deacon, Peter Zijlstra,
Nicholas Piggin, David Howells, Jade Alglave, Luc Maranget,
Paul E. McKenney, Akira Yokosawa, Daniel Lustig, Joel Fernandes,
Nathan Chancellor, Nick Desaulniers, kent.overstreet,
Greg Kroah-Hartman, elver, Mark Rutland, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Catalin Marinas, linux-arm-kernel, linux-fsdevel
In-Reply-To: <s2jeqq22n5ef5jknaps37mfdjvuqrns4w7i22qp2r7r4bzjqs2@my3eyxoa3pl3>
On Fri, 22 Mar 2024 at 16:57, Kent Overstreet <kent.overstreet@linux.dev> wrote:
>
> I wonder about that. The disadvantage of only supporting LKMM atomics is
> that we'll be incompatible with third party code, and we don't want to
> be rolling all of our own data structures forever.
Honestly, having seen the shit-show that is language standards bodies
and incomplete compiler support, I do not understand why people think
that we wouldn't want to roll our own.
The C++ memory model may be reliable in another decade. And then a
decade after *that*, we can drop support for the pre-reliable
compilers.
People who think that compilers do things right just because they are
automated simply don't know what they are talking about.
It was just a couple of days ago that I was pointed at
https://github.com/llvm/llvm-project/issues/64188
which is literally the compiler completely missing a C++ memory barrier.
And when the compiler itself is fundamentally buggy, you're kind of
screwed. When you roll your own, you can work around the bugs in
compilers.
And this is all doubly true when it is something that the kernel does,
and very few other projects do. For example, we're often better off
using inline asm over dubious builtins that have "native" compiler
support for them, but little actual real coverage. It really is often
a "ok, this builtin has actually been used for a decade, so it's
hopefully stable now".
We have years of examples of builtins either being completely broken
(as in "immediate crash" broken), or simply generating crap code that
is actively worse than using the inline asm.
The memory ordering isn't going to be at all different. Moving it into
the compiler doesn't solve problems. It creates them.
Linus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [WIP 0/3] Memory model and atomic API in Rust
From: Boqun Feng @ 2024-03-23 0:15 UTC (permalink / raw)
To: Kent Overstreet
Cc: rust-for-linux, linux-kernel, linux-arch, llvm, Miguel Ojeda,
Alex Gaynor, Wedson Almeida Filho, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Alan Stern,
Andrea Parri, Will Deacon, Peter Zijlstra, Nicholas Piggin,
David Howells, Jade Alglave, Luc Maranget, Paul E. McKenney,
Akira Yokosawa, Daniel Lustig, Joel Fernandes, Nathan Chancellor,
Nick Desaulniers, kent.overstreet, Greg Kroah-Hartman, elver,
Mark Rutland, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Catalin Marinas, torvalds,
linux-arm-kernel, linux-fsdevel
In-Reply-To: <s2jeqq22n5ef5jknaps37mfdjvuqrns4w7i22qp2r7r4bzjqs2@my3eyxoa3pl3>
On Fri, Mar 22, 2024 at 07:57:41PM -0400, Kent Overstreet wrote:
> On Fri, Mar 22, 2024 at 04:38:35PM -0700, Boqun Feng wrote:
> > Hi,
> >
> > Since I see more and more Rust code is comming in, I feel like this
> > should be sent sooner rather than later, so here is a WIP to open the
> > discussion and get feedback.
> >
> > One of the most important questions we need to answer is: which
> > memory (ordering) model we should use when developing Rust in Linux
> > kernel, given Rust has its own memory ordering model[1]. I had some
> > discussion with Rust language community to understand their position
> > on this:
> >
> > https://github.com/rust-lang/unsafe-code-guidelines/issues/348#issuecomment-1218407557
> > https://github.com/rust-lang/unsafe-code-guidelines/issues/476#issue-2001382992
> >
> > My takeaway from these discussions, along with other offline discussion
> > is that supporting two memory models is challenging for both correctness
> > reasoning (some one needs to provide a model) and implementation (one
> > model needs to be aware of the other model). So that's not wise to do
> > (at least at the beginning). So the most reasonable option to me is:
> >
> > we only use LKMM for Rust code in kernel (i.e. avoid using
> > Rust's own atomic).
> >
> > Because kernel developers are more familiar with LKMM and when Rust code
> > interacts with C code, it has to use the model that C code uses.
>
> I wonder about that. The disadvantage of only supporting LKMM atomics is
> that we'll be incompatible with third party code, and we don't want to
> be rolling all of our own data structures forever.
>
A possible solution to that is a set of C++ memory model atomics
implemented by LKMM atomics. That should be possible.
> Do we see a path towards eventually supporting the standard Rust model?
>
Things that Rust/C++ memory model don't suppor but we use are at least:
mixed size atomics (cmpxchg a u64, but read a u8 from another thread),
dependencies (we used a lot in fast path), so it's not trivial.
There are also issues like where one Rust thread does a store(..,
RELEASE), and a C thread does a rcu_deference(), in practice, it
probably works but no one works out (and no one would work out) a model
to describe such an interaction.
Regards,
Boqun
> Perhaps LKMM atomics could be reworked to be a layer on top of C/C++
> atomics. When I last looked, they didn't look completely incompatible;
> rather, there is a common subset that both support with the same
> semantics, and either has some things that it supports and the other
> doesn't (i.e., LKMLL atomics have smp_mb__after_atomic(); this is just a
> straightforward optimization to avoid an unnecessary barrier on
> architectures where the atomic already provided it).
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [WIP 1/3] rust: Introduce atomic module
From: Boqun Feng @ 2024-03-23 0:03 UTC (permalink / raw)
To: Andrew Lunn
Cc: rust-for-linux, linux-kernel, linux-arch, llvm, Miguel Ojeda,
Alex Gaynor, Wedson Almeida Filho, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Alan Stern,
Andrea Parri, Will Deacon, Peter Zijlstra, Nicholas Piggin,
David Howells, Jade Alglave, Luc Maranget, Paul E. McKenney,
Akira Yokosawa, Daniel Lustig, Joel Fernandes, Nathan Chancellor,
Nick Desaulniers, kent.overstreet, Greg Kroah-Hartman, elver,
Mark Rutland, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Catalin Marinas, torvalds,
linux-arm-kernel, linux-fsdevel
In-Reply-To: <068a5983-8216-48a5-9eb5-784a42026836@lunn.ch>
On Sat, Mar 23, 2024 at 12:52:08AM +0100, Andrew Lunn wrote:
> > +//! These primitives should have the same semantics as their C counterparts, for precise definitions
> > +//! of the semantics, please refer to tools/memory-model. Note that Linux Kernel Memory
> > +//! (Consistency) Model is the only model for Rust development in kernel right now, please avoid to
> > +//! use Rust's own atomics.
>
> Is it possible to somehow poison rusts own atomics? I would not be
I can continue to look an elegant way, now since we compile our own
`core` crate (where Rust atomic library locates), we can certain do a
sed trick to exclude the atomic code from Rust. It's pretty hacky, but
maybe others know how to teach linter to help.
Regards,
Boqun
> too surprised if somebody with good Rust knowledge but new to the
> kernel tries using Rusts atomics. Either getting the compiler to fail
> the build, or it throws an Opps on first invocation would be good.
>
> Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [WIP 0/3] Memory model and atomic API in Rust
From: Kent Overstreet @ 2024-03-22 23:57 UTC (permalink / raw)
To: Boqun Feng
Cc: rust-for-linux, linux-kernel, linux-arch, llvm, Miguel Ojeda,
Alex Gaynor, Wedson Almeida Filho, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Alan Stern,
Andrea Parri, Will Deacon, Peter Zijlstra, Nicholas Piggin,
David Howells, Jade Alglave, Luc Maranget, Paul E. McKenney,
Akira Yokosawa, Daniel Lustig, Joel Fernandes, Nathan Chancellor,
Nick Desaulniers, kent.overstreet, Greg Kroah-Hartman, elver,
Mark Rutland, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Catalin Marinas, torvalds,
linux-arm-kernel, linux-fsdevel
In-Reply-To: <20240322233838.868874-1-boqun.feng@gmail.com>
On Fri, Mar 22, 2024 at 04:38:35PM -0700, Boqun Feng wrote:
> Hi,
>
> Since I see more and more Rust code is comming in, I feel like this
> should be sent sooner rather than later, so here is a WIP to open the
> discussion and get feedback.
>
> One of the most important questions we need to answer is: which
> memory (ordering) model we should use when developing Rust in Linux
> kernel, given Rust has its own memory ordering model[1]. I had some
> discussion with Rust language community to understand their position
> on this:
>
> https://github.com/rust-lang/unsafe-code-guidelines/issues/348#issuecomment-1218407557
> https://github.com/rust-lang/unsafe-code-guidelines/issues/476#issue-2001382992
>
> My takeaway from these discussions, along with other offline discussion
> is that supporting two memory models is challenging for both correctness
> reasoning (some one needs to provide a model) and implementation (one
> model needs to be aware of the other model). So that's not wise to do
> (at least at the beginning). So the most reasonable option to me is:
>
> we only use LKMM for Rust code in kernel (i.e. avoid using
> Rust's own atomic).
>
> Because kernel developers are more familiar with LKMM and when Rust code
> interacts with C code, it has to use the model that C code uses.
I wonder about that. The disadvantage of only supporting LKMM atomics is
that we'll be incompatible with third party code, and we don't want to
be rolling all of our own data structures forever.
Do we see a path towards eventually supporting the standard Rust model?
Perhaps LKMM atomics could be reworked to be a layer on top of C/C++
atomics. When I last looked, they didn't look completely incompatible;
rather, there is a common subset that both support with the same
semantics, and either has some things that it supports and the other
doesn't (i.e., LKMLL atomics have smp_mb__after_atomic(); this is just a
straightforward optimization to avoid an unnecessary barrier on
architectures where the atomic already provided it).
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [WIP 1/3] rust: Introduce atomic module
From: Andrew Lunn @ 2024-03-22 23:52 UTC (permalink / raw)
To: Boqun Feng
Cc: rust-for-linux, linux-kernel, linux-arch, llvm, Miguel Ojeda,
Alex Gaynor, Wedson Almeida Filho, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Alan Stern,
Andrea Parri, Will Deacon, Peter Zijlstra, Nicholas Piggin,
David Howells, Jade Alglave, Luc Maranget, Paul E. McKenney,
Akira Yokosawa, Daniel Lustig, Joel Fernandes, Nathan Chancellor,
Nick Desaulniers, kent.overstreet, Greg Kroah-Hartman, elver,
Mark Rutland, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Catalin Marinas, torvalds,
linux-arm-kernel, linux-fsdevel
In-Reply-To: <20240322233838.868874-2-boqun.feng@gmail.com>
> +//! These primitives should have the same semantics as their C counterparts, for precise definitions
> +//! of the semantics, please refer to tools/memory-model. Note that Linux Kernel Memory
> +//! (Consistency) Model is the only model for Rust development in kernel right now, please avoid to
> +//! use Rust's own atomics.
Is it possible to somehow poison rusts own atomics? I would not be
too surprised if somebody with good Rust knowledge but new to the
kernel tries using Rusts atomics. Either getting the compiler to fail
the build, or it throws an Opps on first invocation would be good.
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] arm64: syscall: Direct PRNG kstack randomization
From: Jeremy Linton @ 2024-03-22 23:40 UTC (permalink / raw)
To: Arnd Bergmann, Kees Cook
Cc: linux-arm-kernel, Catalin Marinas, Will Deacon,
Jason A . Donenfeld, Gustavo A. R. Silva, Mark Rutland,
Steven Rostedt, Mark Brown, Guo Hui, Manoj.Iyer, linux-kernel,
linux-hardening, James Yang, Shiyou Huang
In-Reply-To: <acfc522a-5162-4b33-9d6c-1e25d0c44a71@app.fastmail.com>
Hi,
Sorry about the delay here, PTO and I actually wanted to verify my
assumptions.
On 3/8/24 14:29, Arnd Bergmann wrote:
> On Fri, Mar 8, 2024, at 17:49, Jeremy Linton wrote:
>> On 3/7/24 05:10, Arnd Bergmann wrote:
>>>
>>> I'm not sure I understand the logic. Do you mean that accessing
>>> CNTVCT itself is slow, or that reseeding based on CNTVCT is slow
>>> because of the overhead of reseeding?
>>
>> Slow, as in, its running at a much lower frequency than a cycle counter.
>
> Ok, I see. Would it be possible to use PMEVCNTR0 instead?
So, I presume you actually mean PMCCNTR_EL0 because I don't see the
point of a dedicated event, although maybe...
So, the first and maybe largest problem is the PMxxx registers are all
optional because the PMU is optional! Although, they are strongly
recommended and most (AFAIK) machines do implement them. So, maybe if
its just using a cycle counter to dump some entropy into rnd_state it
becomes a statement that kstack randomization is slower or unsupported
if there isn't a PMU?
But then we have to basically enable the PMU cycle counter globally,
which requires reworking how it works, because the cycle counter is
enabled/disabled and reset on the fly depending on whether the user is
trying to profile something. So, I have hacked that up, and it appears
to be working, although i'm not sure what kind of interaction will
happen with KVM yet.
But I guess the larger question is whether its worth changing the PMU
behavior for this?
Thanks,
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [WIP 3/3] rust: atomic: Add fetch_sub_release()
From: Boqun Feng @ 2024-03-22 23:38 UTC (permalink / raw)
To: rust-for-linux, linux-kernel, linux-arch, llvm
Cc: Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Alan Stern, Andrea Parri, Will Deacon, Peter Zijlstra,
Nicholas Piggin, David Howells, Jade Alglave, Luc Maranget,
Paul E. McKenney, Akira Yokosawa, Daniel Lustig, Joel Fernandes,
Nathan Chancellor, Nick Desaulniers, kent.overstreet,
Greg Kroah-Hartman, elver, Mark Rutland, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Catalin Marinas, torvalds, linux-arm-kernel, linux-fsdevel
In-Reply-To: <20240322233838.868874-1-boqun.feng@gmail.com>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
---
rust/kernel/sync/atomic.rs | 23 +++++++++++++++++++++++
rust/kernel/sync/atomic/arch/arm64.rs | 20 ++++++++++++++++++++
rust/kernel/sync/atomic/arch/x86.rs | 5 +++++
3 files changed, 48 insertions(+)
diff --git a/rust/kernel/sync/atomic.rs b/rust/kernel/sync/atomic.rs
index 280040705fb0..c3cae0d25e88 100644
--- a/rust/kernel/sync/atomic.rs
+++ b/rust/kernel/sync/atomic.rs
@@ -39,4 +39,27 @@ pub fn new(v: i32) -> Self {
pub fn fetch_add_relaxed(&self, i: i32) -> i32 {
arch::i32_fetch_add_relaxed(&self.0, i)
}
+
+ /// Subs `i` to the atomic variable with RELEASE ordering.
+ ///
+ /// Returns the old value before the sub.
+ ///
+ /// # Example
+ ///
+ /// ```rust
+ /// use kernel::sync::atomic::AtomicI32;
+ ///
+ /// let a = AtomicI32::new(1);
+ /// let b = a.fetch_sub_release(1);
+ /// let c = a.fetch_sub_release(2);
+ /// let d = a.fetch_sub_release(3);
+ /// let e = a.fetch_sub_release(core::i32::MIN);
+ ///
+ /// assert_eq!(b, 1);
+ /// assert_eq!(c, 0);
+ /// assert_eq!(d, -2);
+ /// ```
+ pub fn fetch_sub_release(&self, i: i32) -> i32 {
+ arch::i32_fetch_sub_release(&self.0, i)
+ }
}
diff --git a/rust/kernel/sync/atomic/arch/arm64.rs b/rust/kernel/sync/atomic/arch/arm64.rs
index 438f37cf7df6..beea77ecdb20 100644
--- a/rust/kernel/sync/atomic/arch/arm64.rs
+++ b/rust/kernel/sync/atomic/arch/arm64.rs
@@ -24,3 +24,23 @@ pub(crate) fn i32_fetch_add_relaxed(v: &UnsafeCell<i32>, i: i32) -> i32 {
result
}
+
+pub(crate) fn i32_fetch_sub_release(v: &UnsafeCell<i32>, i: i32) -> i32 {
+ let mut result;
+ unsafe {
+ asm!(
+ "prfm pstl1strm, [{v}]",
+ "1: ldxr {result:w}, [{v}]",
+ "sub {val:w}, {result:w}, {i:w}",
+ "stlxr {tmp:w}, {val:w}, [{v}]",
+ "cbnz {tmp:w}, 1b",
+ result = out(reg) result,
+ tmp = out(reg) _,
+ val = out(reg) _,
+ v = in(reg) v.get(),
+ i = in(reg) i,
+ )
+ }
+
+ result
+}
diff --git a/rust/kernel/sync/atomic/arch/x86.rs b/rust/kernel/sync/atomic/arch/x86.rs
index 2d715f740b22..7f764cde4576 100644
--- a/rust/kernel/sync/atomic/arch/x86.rs
+++ b/rust/kernel/sync/atomic/arch/x86.rs
@@ -41,3 +41,8 @@ pub(crate) fn i32_fetch_add_relaxed(v: &UnsafeCell<i32>, i: i32) -> i32 {
// SAFETY: `v.get()` points to a valid `i32`.
unsafe { i32_xadd(v.get(), i) }
}
+
+pub(crate) fn i32_fetch_sub_release(v: &UnsafeCell<i32>, i: i32) -> i32 {
+ // SAFETY: `v.get()` points to a valid `i32`.
+ unsafe { i32_xadd(v.get(), i.wrapping_neg()) }
+}
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [WIP 1/3] rust: Introduce atomic module
From: Boqun Feng @ 2024-03-22 23:38 UTC (permalink / raw)
To: rust-for-linux, linux-kernel, linux-arch, llvm
Cc: Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Alan Stern, Andrea Parri, Will Deacon, Peter Zijlstra,
Nicholas Piggin, David Howells, Jade Alglave, Luc Maranget,
Paul E. McKenney, Akira Yokosawa, Daniel Lustig, Joel Fernandes,
Nathan Chancellor, Nick Desaulniers, kent.overstreet,
Greg Kroah-Hartman, elver, Mark Rutland, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Catalin Marinas, torvalds, linux-arm-kernel, linux-fsdevel
In-Reply-To: <20240322233838.868874-1-boqun.feng@gmail.com>
Although Rust has its own memory ordering model (in the standard C++
memory model), having two models is not wise to start with: it increases
the difficulty for correctness reasoning. Since we use Linux Kernel
Memory Model for C code in kernel, it makes sense that Rust code also
uses LKMM, therefore introduce a module to provide LKMM atomic
primitives.
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
---
rust/kernel/sync.rs | 1 +
rust/kernel/sync/atomic.rs | 42 ++++++++++++++++++++++++++++
rust/kernel/sync/atomic/arch.rs | 9 ++++++
rust/kernel/sync/atomic/arch/x86.rs | 43 +++++++++++++++++++++++++++++
4 files changed, 95 insertions(+)
create mode 100644 rust/kernel/sync/atomic.rs
create mode 100644 rust/kernel/sync/atomic/arch.rs
create mode 100644 rust/kernel/sync/atomic/arch/x86.rs
diff --git a/rust/kernel/sync.rs b/rust/kernel/sync.rs
index c983f63fd56e..dc2d26712f26 100644
--- a/rust/kernel/sync.rs
+++ b/rust/kernel/sync.rs
@@ -8,6 +8,7 @@
use crate::types::Opaque;
mod arc;
+pub mod atomic;
mod condvar;
pub mod lock;
mod locked_by;
diff --git a/rust/kernel/sync/atomic.rs b/rust/kernel/sync/atomic.rs
new file mode 100644
index 000000000000..280040705fb0
--- /dev/null
+++ b/rust/kernel/sync/atomic.rs
@@ -0,0 +1,42 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! Atomic and barrier primitives.
+//!
+//! These primitives should have the same semantics as their C counterparts, for precise definitions
+//! of the semantics, please refer to tools/memory-model. Note that Linux Kernel Memory
+//! (Consistency) Model is the only model for Rust development in kernel right now, please avoid to
+//! use Rust's own atomics.
+
+use core::cell::UnsafeCell;
+
+mod arch;
+
+/// An atomic `i32`.
+pub struct AtomicI32(pub(crate) UnsafeCell<i32>);
+
+impl AtomicI32 {
+ /// Creates a new atomic value.
+ pub fn new(v: i32) -> Self {
+ Self(UnsafeCell::new(v))
+ }
+
+ /// Adds `i` to the atomic variable with RELAXED ordering.
+ ///
+ /// Returns the old value before the add.
+ ///
+ /// # Example
+ ///
+ /// ```rust
+ /// use kernel::sync::atomic::AtomicI32;
+ ///
+ /// let a = AtomicI32::new(0);
+ /// let b = a.fetch_add_relaxed(1);
+ /// let c = a.fetch_add_relaxed(2);
+ ///
+ /// assert_eq!(b, 0);
+ /// assert_eq!(c, 1);
+ /// ```
+ pub fn fetch_add_relaxed(&self, i: i32) -> i32 {
+ arch::i32_fetch_add_relaxed(&self.0, i)
+ }
+}
diff --git a/rust/kernel/sync/atomic/arch.rs b/rust/kernel/sync/atomic/arch.rs
new file mode 100644
index 000000000000..3eb5a103a69a
--- /dev/null
+++ b/rust/kernel/sync/atomic/arch.rs
@@ -0,0 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! Architectural atomic and barrier primitives.
+
+#[cfg(CONFIG_X86)]
+pub(crate) use x86::*;
+
+#[cfg(CONFIG_X86)]
+pub(crate) mod x86;
diff --git a/rust/kernel/sync/atomic/arch/x86.rs b/rust/kernel/sync/atomic/arch/x86.rs
new file mode 100644
index 000000000000..2d715f740b22
--- /dev/null
+++ b/rust/kernel/sync/atomic/arch/x86.rs
@@ -0,0 +1,43 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! x86 implementation for atomic and barrier primitives.
+
+use core::arch::asm;
+use core::cell::UnsafeCell;
+
+/// Generates an instruction with "lock" prefix.
+#[cfg(CONFIG_SMP)]
+macro_rules! lock_instr {
+ ($i:literal) => { concat!("lock; ", $i) }
+}
+
+#[cfg(not(CONFIG_SMP))]
+macro_rules! lock_instr {
+ ($i:literal) => { $i }
+}
+
+/// Atomically exchanges and adds `i` to `*v` in a wrapping way.
+///
+/// Return the old value before the addition.
+///
+/// # Safety
+///
+/// The caller need to make sure `v` points to a valid `i32`.
+unsafe fn i32_xadd(v: *mut i32, mut i: i32) -> i32 {
+ // SAFETY: Per function safety requirement, the address of `v` is valid for "xadd".
+ unsafe {
+ asm!(
+ lock_instr!("xaddl {i:e}, ({v})"),
+ i = inout(reg) i,
+ v = in(reg) v,
+ options(att_syntax, preserves_flags),
+ );
+ }
+
+ i
+}
+
+pub(crate) fn i32_fetch_add_relaxed(v: &UnsafeCell<i32>, i: i32) -> i32 {
+ // SAFETY: `v.get()` points to a valid `i32`.
+ unsafe { i32_xadd(v.get(), i) }
+}
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [WIP 0/3] Memory model and atomic API in Rust
From: Boqun Feng @ 2024-03-22 23:38 UTC (permalink / raw)
To: rust-for-linux, linux-kernel, linux-arch, llvm
Cc: Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Alan Stern, Andrea Parri, Will Deacon, Peter Zijlstra,
Nicholas Piggin, David Howells, Jade Alglave, Luc Maranget,
Paul E. McKenney, Akira Yokosawa, Daniel Lustig, Joel Fernandes,
Nathan Chancellor, Nick Desaulniers, kent.overstreet,
Greg Kroah-Hartman, elver, Mark Rutland, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Catalin Marinas, torvalds, linux-arm-kernel, linux-fsdevel
Hi,
Since I see more and more Rust code is comming in, I feel like this
should be sent sooner rather than later, so here is a WIP to open the
discussion and get feedback.
One of the most important questions we need to answer is: which
memory (ordering) model we should use when developing Rust in Linux
kernel, given Rust has its own memory ordering model[1]. I had some
discussion with Rust language community to understand their position
on this:
https://github.com/rust-lang/unsafe-code-guidelines/issues/348#issuecomment-1218407557
https://github.com/rust-lang/unsafe-code-guidelines/issues/476#issue-2001382992
My takeaway from these discussions, along with other offline discussion
is that supporting two memory models is challenging for both correctness
reasoning (some one needs to provide a model) and implementation (one
model needs to be aware of the other model). So that's not wise to do
(at least at the beginning). So the most reasonable option to me is:
we only use LKMM for Rust code in kernel (i.e. avoid using
Rust's own atomic).
Because kernel developers are more familiar with LKMM and when Rust code
interacts with C code, it has to use the model that C code uses.
And this patchset is the result of that option. I introduced an atomic
library to wrap and implement LKMM atomics (of course, given it's a WIP,
so it's unfinished). Things to notice:
* I know I could use Rust macro to generate the whole set of atomics,
but I choose not to in the beginning, as I want to make it easier to
review.
* Very likely, we will only have AtomicI32, AtomicI64 and AtomicUsize
(i.e no atomic for bool, u8, u16, etc), with limited support for
atomic load and store on 8/16 bits.
* I choose to re-implement atomics in Rust `asm` because we are still
figuring out how we can make it easy and maintainable for Rust to call
a C function _inlinely_ (Gary makes some progress [2]). Otherwise,
atomic primitives would be function calls, and that can be performance
bottleneck in a few cases.
* I only have two API implemented and two architecture supported yet,
the complete support surely can be added when everyone is on the same
page.
Any suggestion, question, review, help is welcome!
Regards,
Boqun
[1]: https://doc.rust-lang.org/std/sync/atomic/#memory-model-for-atomic-accesses
[2]: https://rust-for-linux.zulipchat.com/#narrow/stream/288089-General/topic/LTO.20Rust.20modules.20with.20C.20helpers/near/425361365
Boqun Feng (3):
rust: Introduce atomic module
rust: atomic: Add ARM64 fetch_add_relaxed()
rust: atomic: Add fetch_sub_release()
rust/kernel/sync.rs | 1 +
rust/kernel/sync/atomic.rs | 65 +++++++++++++++++++++++++++
rust/kernel/sync/atomic/arch.rs | 15 +++++++
rust/kernel/sync/atomic/arch/arm64.rs | 46 +++++++++++++++++++
rust/kernel/sync/atomic/arch/x86.rs | 48 ++++++++++++++++++++
5 files changed, 175 insertions(+)
create mode 100644 rust/kernel/sync/atomic.rs
create mode 100644 rust/kernel/sync/atomic/arch.rs
create mode 100644 rust/kernel/sync/atomic/arch/arm64.rs
create mode 100644 rust/kernel/sync/atomic/arch/x86.rs
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [WIP 2/3] rust: atomic: Add ARM64 fetch_add_relaxed()
From: Boqun Feng @ 2024-03-22 23:38 UTC (permalink / raw)
To: rust-for-linux, linux-kernel, linux-arch, llvm
Cc: Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Alan Stern, Andrea Parri, Will Deacon, Peter Zijlstra,
Nicholas Piggin, David Howells, Jade Alglave, Luc Maranget,
Paul E. McKenney, Akira Yokosawa, Daniel Lustig, Joel Fernandes,
Nathan Chancellor, Nick Desaulniers, kent.overstreet,
Greg Kroah-Hartman, elver, Mark Rutland, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Catalin Marinas, torvalds, linux-arm-kernel, linux-fsdevel
In-Reply-To: <20240322233838.868874-1-boqun.feng@gmail.com>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
---
rust/kernel/sync/atomic/arch.rs | 6 ++++++
rust/kernel/sync/atomic/arch/arm64.rs | 26 ++++++++++++++++++++++++++
2 files changed, 32 insertions(+)
create mode 100644 rust/kernel/sync/atomic/arch/arm64.rs
diff --git a/rust/kernel/sync/atomic/arch.rs b/rust/kernel/sync/atomic/arch.rs
index 3eb5a103a69a..fc280f229237 100644
--- a/rust/kernel/sync/atomic/arch.rs
+++ b/rust/kernel/sync/atomic/arch.rs
@@ -5,5 +5,11 @@
#[cfg(CONFIG_X86)]
pub(crate) use x86::*;
+#[cfg(CONFIG_ARM64)]
+pub(crate) use arm64::*;
+
#[cfg(CONFIG_X86)]
pub(crate) mod x86;
+
+#[cfg(CONFIG_ARM64)]
+pub(crate) mod arm64;
diff --git a/rust/kernel/sync/atomic/arch/arm64.rs b/rust/kernel/sync/atomic/arch/arm64.rs
new file mode 100644
index 000000000000..438f37cf7df6
--- /dev/null
+++ b/rust/kernel/sync/atomic/arch/arm64.rs
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! ARM64 implementation for atomic and barrier primitives.
+
+use core::arch::asm;
+use core::cell::UnsafeCell;
+
+pub(crate) fn i32_fetch_add_relaxed(v: &UnsafeCell<i32>, i: i32) -> i32 {
+ let mut result;
+ unsafe {
+ asm!(
+ "prfm pstl1strm, [{v}]",
+ "1: ldxr {result:w}, [{v}]",
+ "add {val:w}, {result:w}, {i:w}",
+ "stxr {tmp:w}, {val:w}, [{v}]",
+ "cbnz {tmp:w}, 1b",
+ result = out(reg) result,
+ tmp = out(reg) _,
+ val = out(reg) _,
+ v = in(reg) v.get(),
+ i = in(reg) i,
+ )
+ }
+
+ result
+}
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 2/5] mfd: rk8xx: Add RK816 support
From: kernel test robot @ 2024-03-22 21:45 UTC (permalink / raw)
To: Alex Bee, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, Linus Walleij, Liam Girdwood,
Mark Brown
Cc: llvm, oe-kbuild-all, Chris Zhong, Zhang Qing, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, linux-gpio,
Alex Bee
In-Reply-To: <20240321143911.90210-5-knaerzche@gmail.com>
Hi Alex,
kernel test robot noticed the following build errors:
[auto build test ERROR on lee-mfd/for-mfd-next]
[also build test ERROR on lee-mfd/for-mfd-fixes broonie-regulator/for-next robh/for-next linus/master v6.8 next-20240322]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Alex-Bee/dt-bindings-mfd-Add-rk816-binding/20240321-224318
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
patch link: https://lore.kernel.org/r/20240321143911.90210-5-knaerzche%40gmail.com
patch subject: [PATCH 2/5] mfd: rk8xx: Add RK816 support
config: arm-randconfig-002-20240322 (https://download.01.org/0day-ci/archive/20240323/202403230551.Vc1eaxTr-lkp@intel.com/config)
compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project 23de3862dce582ce91c1aa914467d982cb1a73b4)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240323/202403230551.Vc1eaxTr-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202403230551.Vc1eaxTr-lkp@intel.com/
All error/warnings (new ones prefixed by >>):
In file included from drivers/mfd/rk8xx-core.c:14:
In file included from include/linux/mfd/rk808.h:18:
In file included from include/linux/regulator/machine.h:15:
In file included from include/linux/regulator/consumer.h:35:
In file included from include/linux/suspend.h:5:
In file included from include/linux/swap.h:9:
In file included from include/linux/memcontrol.h:20:
In file included from include/linux/mm.h:2188:
include/linux/vmstat.h:522:36: warning: arithmetic between different enumeration types ('enum node_stat_item' and 'enum lru_list') [-Wenum-enum-conversion]
522 | return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_"
| ~~~~~~~~~~~ ^ ~~~
>> drivers/mfd/rk8xx-core.c:395:8: warning: 'const' type qualifier on return type has no effect [-Wignored-qualifiers]
395 | static const unsigned int rk816_get_irq_reg(struct regmap_irq_chip_data *data,
| ^~~~~
>> drivers/mfd/rk8xx-core.c:573:17: error: incompatible function pointer types initializing 'unsigned int (*)(struct regmap_irq_chip_data *, unsigned int, int)' with an expression of type 'const unsigned int (struct regmap_irq_chip_data *, unsigned int, int)' [-Wincompatible-function-pointer-types]
573 | .get_irq_reg = rk816_get_irq_reg,
| ^~~~~~~~~~~~~~~~~
2 warnings and 1 error generated.
vim +573 drivers/mfd/rk8xx-core.c
394
> 395 static const unsigned int rk816_get_irq_reg(struct regmap_irq_chip_data *data,
396 unsigned int base, int index)
397 {
398 unsigned int irq_reg = base;
399
400 switch (base) {
401 case RK816_INT_STS_REG1:
402 irq_reg += rk816_irq_status_offsets[index];
403 break;
404 case RK816_INT_STS_MSK_REG1:
405 irq_reg += rk816_irq_mask_offsets[index];
406 break;
407 }
408
409 return irq_reg;
410 };
411
412 static const struct regmap_irq rk816_irqs[] = {
413 /* INT_STS_REG1 IRQs */
414 REGMAP_IRQ_REG(RK816_IRQ_PWRON_FALL, 0, RK816_INT_STS_PWRON_FALL),
415 REGMAP_IRQ_REG(RK816_IRQ_PWRON_RISE, 0, RK816_INT_STS_PWRON_RISE),
416
417 /* INT_STS_REG2 IRQs */
418 REGMAP_IRQ_REG(RK816_IRQ_VB_LOW, 1, RK816_INT_STS_VB_LOW),
419 REGMAP_IRQ_REG(RK816_IRQ_PWRON, 1, RK816_INT_STS_PWRON),
420 REGMAP_IRQ_REG(RK816_IRQ_PWRON_LP, 1, RK816_INT_STS_PWRON_LP),
421 REGMAP_IRQ_REG(RK816_IRQ_HOTDIE, 1, RK816_INT_STS_HOTDIE),
422 REGMAP_IRQ_REG(RK816_IRQ_RTC_ALARM, 1, RK816_INT_STS_RTC_ALARM),
423 REGMAP_IRQ_REG(RK816_IRQ_RTC_PERIOD, 1, RK816_INT_STS_RTC_PERIOD),
424 REGMAP_IRQ_REG(RK816_IRQ_USB_OV, 1, RK816_INT_STS_USB_OV),
425
426 /* INT_STS3 IRQs */
427 REGMAP_IRQ_REG(RK816_IRQ_PLUG_IN, 2, RK816_INT_STS_PLUG_IN),
428 REGMAP_IRQ_REG(RK816_IRQ_PLUG_OUT, 2, RK816_INT_STS_PLUG_OUT),
429 REGMAP_IRQ_REG(RK816_IRQ_CHG_OK, 2, RK816_INT_STS_CHG_OK),
430 REGMAP_IRQ_REG(RK816_IRQ_CHG_TE, 2, RK816_INT_STS_CHG_TE),
431 REGMAP_IRQ_REG(RK816_IRQ_CHG_TS, 2, RK816_INT_STS_CHG_TS),
432 REGMAP_IRQ_REG(RK816_IRQ_CHG_CVTLIM, 2, RK816_INT_STS_CHG_CVTLIM),
433 REGMAP_IRQ_REG(RK816_IRQ_DISCHG_ILIM, 2, RK816_INT_STS_DISCHG_ILIM),
434 };
435
436 static const struct regmap_irq rk818_irqs[] = {
437 /* INT_STS */
438 [RK818_IRQ_VOUT_LO] = {
439 .mask = RK818_IRQ_VOUT_LO_MSK,
440 .reg_offset = 0,
441 },
442 [RK818_IRQ_VB_LO] = {
443 .mask = RK818_IRQ_VB_LO_MSK,
444 .reg_offset = 0,
445 },
446 [RK818_IRQ_PWRON] = {
447 .mask = RK818_IRQ_PWRON_MSK,
448 .reg_offset = 0,
449 },
450 [RK818_IRQ_PWRON_LP] = {
451 .mask = RK818_IRQ_PWRON_LP_MSK,
452 .reg_offset = 0,
453 },
454 [RK818_IRQ_HOTDIE] = {
455 .mask = RK818_IRQ_HOTDIE_MSK,
456 .reg_offset = 0,
457 },
458 [RK818_IRQ_RTC_ALARM] = {
459 .mask = RK818_IRQ_RTC_ALARM_MSK,
460 .reg_offset = 0,
461 },
462 [RK818_IRQ_RTC_PERIOD] = {
463 .mask = RK818_IRQ_RTC_PERIOD_MSK,
464 .reg_offset = 0,
465 },
466 [RK818_IRQ_USB_OV] = {
467 .mask = RK818_IRQ_USB_OV_MSK,
468 .reg_offset = 0,
469 },
470
471 /* INT_STS2 */
472 [RK818_IRQ_PLUG_IN] = {
473 .mask = RK818_IRQ_PLUG_IN_MSK,
474 .reg_offset = 1,
475 },
476 [RK818_IRQ_PLUG_OUT] = {
477 .mask = RK818_IRQ_PLUG_OUT_MSK,
478 .reg_offset = 1,
479 },
480 [RK818_IRQ_CHG_OK] = {
481 .mask = RK818_IRQ_CHG_OK_MSK,
482 .reg_offset = 1,
483 },
484 [RK818_IRQ_CHG_TE] = {
485 .mask = RK818_IRQ_CHG_TE_MSK,
486 .reg_offset = 1,
487 },
488 [RK818_IRQ_CHG_TS1] = {
489 .mask = RK818_IRQ_CHG_TS1_MSK,
490 .reg_offset = 1,
491 },
492 [RK818_IRQ_TS2] = {
493 .mask = RK818_IRQ_TS2_MSK,
494 .reg_offset = 1,
495 },
496 [RK818_IRQ_CHG_CVTLIM] = {
497 .mask = RK818_IRQ_CHG_CVTLIM_MSK,
498 .reg_offset = 1,
499 },
500 [RK818_IRQ_DISCHG_ILIM] = {
501 .mask = RK818_IRQ_DISCHG_ILIM_MSK,
502 .reg_offset = 1,
503 },
504 };
505
506 static const struct regmap_irq rk817_irqs[RK817_IRQ_END] = {
507 REGMAP_IRQ_REG_LINE(0, 8),
508 REGMAP_IRQ_REG_LINE(1, 8),
509 REGMAP_IRQ_REG_LINE(2, 8),
510 REGMAP_IRQ_REG_LINE(3, 8),
511 REGMAP_IRQ_REG_LINE(4, 8),
512 REGMAP_IRQ_REG_LINE(5, 8),
513 REGMAP_IRQ_REG_LINE(6, 8),
514 REGMAP_IRQ_REG_LINE(7, 8),
515 REGMAP_IRQ_REG_LINE(8, 8),
516 REGMAP_IRQ_REG_LINE(9, 8),
517 REGMAP_IRQ_REG_LINE(10, 8),
518 REGMAP_IRQ_REG_LINE(11, 8),
519 REGMAP_IRQ_REG_LINE(12, 8),
520 REGMAP_IRQ_REG_LINE(13, 8),
521 REGMAP_IRQ_REG_LINE(14, 8),
522 REGMAP_IRQ_REG_LINE(15, 8),
523 REGMAP_IRQ_REG_LINE(16, 8),
524 REGMAP_IRQ_REG_LINE(17, 8),
525 REGMAP_IRQ_REG_LINE(18, 8),
526 REGMAP_IRQ_REG_LINE(19, 8),
527 REGMAP_IRQ_REG_LINE(20, 8),
528 REGMAP_IRQ_REG_LINE(21, 8),
529 REGMAP_IRQ_REG_LINE(22, 8),
530 REGMAP_IRQ_REG_LINE(23, 8)
531 };
532
533 static struct regmap_irq_chip rk805_irq_chip = {
534 .name = "rk805",
535 .irqs = rk805_irqs,
536 .num_irqs = ARRAY_SIZE(rk805_irqs),
537 .num_regs = 1,
538 .status_base = RK805_INT_STS_REG,
539 .mask_base = RK805_INT_STS_MSK_REG,
540 .ack_base = RK805_INT_STS_REG,
541 .init_ack_masked = true,
542 };
543
544 static struct regmap_irq_chip rk806_irq_chip = {
545 .name = "rk806",
546 .irqs = rk806_irqs,
547 .num_irqs = ARRAY_SIZE(rk806_irqs),
548 .num_regs = 2,
549 .irq_reg_stride = 2,
550 .mask_base = RK806_INT_MSK0,
551 .status_base = RK806_INT_STS0,
552 .ack_base = RK806_INT_STS0,
553 .init_ack_masked = true,
554 };
555
556 static const struct regmap_irq_chip rk808_irq_chip = {
557 .name = "rk808",
558 .irqs = rk808_irqs,
559 .num_irqs = ARRAY_SIZE(rk808_irqs),
560 .num_regs = 2,
561 .irq_reg_stride = 2,
562 .status_base = RK808_INT_STS_REG1,
563 .mask_base = RK808_INT_STS_MSK_REG1,
564 .ack_base = RK808_INT_STS_REG1,
565 .init_ack_masked = true,
566 };
567
568 static const struct regmap_irq_chip rk816_irq_chip = {
569 .name = "rk816",
570 .irqs = rk816_irqs,
571 .num_irqs = ARRAY_SIZE(rk816_irqs),
572 .num_regs = 3,
> 573 .get_irq_reg = rk816_get_irq_reg,
574 .status_base = RK816_INT_STS_REG1,
575 .mask_base = RK816_INT_STS_MSK_REG1,
576 .ack_base = RK816_INT_STS_REG1,
577 .init_ack_masked = true,
578 };
579
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 5/8] drm: zynqmp_dp: Don't retrain the link in our IRQ
From: Sean Anderson @ 2024-03-22 21:22 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Michal Simek, David Airlie, linux-kernel, Daniel Vetter,
linux-arm-kernel, Laurent Pinchart, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, dri-devel
In-Reply-To: <305a8e43-4d65-490c-9f83-afce6490bc83@ideasonboard.com>
On 3/22/24 14:09, Tomi Valkeinen wrote:
> On 22/03/2024 18:18, Sean Anderson wrote:
>> On 3/22/24 01:32, Tomi Valkeinen wrote:
>>> On 21/03/2024 21:17, Sean Anderson wrote:
>>>> On 3/21/24 15:08, Tomi Valkeinen wrote:
>>>>> On 21/03/2024 20:01, Sean Anderson wrote:
>>>>>> On 3/21/24 13:25, Tomi Valkeinen wrote:
>>>>>>> On 21/03/2024 17:52, Sean Anderson wrote:
>>>>>>>> On 3/20/24 02:53, Tomi Valkeinen wrote:
>>>>>>>>> On 20/03/2024 00:51, Sean Anderson wrote:
>>>>>>>>> Do we need to handle interrupts while either delayed work is being done?
>>>>>>>>
>>>>>>>> Probably not.
>>>>>>>>
>>>>>>>>> If we do need a delayed work, would just one work be enough which
>>>>>>>>> handles both HPD_EVENT and HPD_IRQ, instead of two?
>>>>>>>>
>>>>>>>> Maybe, but then we need to determine which pending events we need to
>>>>>>>> handle. I think since we have only two events it will be easier to just
>>>>>>>> have separate workqueues.
>>>>>>>
>>>>>>> The less concurrency, the better...Which is why it would be nice to do it all in the threaded irq.
>>>>>>
>>>>>> Yeah, but we can use a mutex for this which means there is not too much
>>>>>> interesting going on.
>>>>>
>>>>> Ok. Yep, if we get (hopefully) a single mutex with clearly defined fields that it protects, I'm ok with workqueues.
>>>>>
>>>>> I'd still prefer just one workqueue, though...
>>>>
>>>> Yeah, but then we need a spinlock or something to tell the workqueue what it should do.
>>>
>>> Yep. We could also always look at the HPD (if we drop the big sleeps) in the wq, and have a flag for the HPD IRQ, which would reduce the state to a single bit.
>>
>> How about something like
>>
>> zynqmp_dp_irq_handler(...)
>> {
>> /* Read status and handle underflow/overflow/vblank */
>>
>> status &= ZYNQMP_DP_INT_HPD_EVENT | ZYNQMP_DP_INT_HPD_IRQ;
>> if (status) {
>> atomic_or(status, &dp->status);
>> return IRQ_WAKE_THREAD;
>> }
>>
>> return IRQ_HANDLED;
>> }
>>
>> zynqmp_dp_thread_handler(...)
>> {
>> status = atomic_xchg(&dp->status, 0);
>> /* process HPD stuff */
>> }
>>
>> which gets rid of the workqueue too.
>
> I like it. We can't use IRQF_ONESHOT, as that would keep the irq masked while the threaded handler is being ran. I don't think that's a problem, but just something to keep in mind that both handlers can run concurrently.
Actually, I'm not sure we can do it like this. Imagine we have something
like
CPU 0 CPU 1
zynqmp_dp_thread_handler()
atomic_xchg()
__handle_irq_event_percpu
zynqmp_dp_irq_handler()
atomic_or()
return IRQ_WAIT_THREAD
__irq_wake_thread()
test_and_set_bit(IRQTF_RUNTHREAD, ...)
return
return IRQ_HANDLED
and whoops we now have bits set in dp->status but the thread isn't
running. I don't think there's a way to fix this without locking (or two
works). TBH I am leaning towards just having two works; it is a clean
implementation. We can also convert to use work_struct instead of
delayed_work, since we never set a delay.
--Sean
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 12/12] mm/gup: Handle hugetlb in the generic follow_page_mask code
From: Andrew Morton @ 2024-03-22 20:48 UTC (permalink / raw)
To: peterx
Cc: linux-mm, linux-kernel, linuxppc-dev, Michael Ellerman,
Christophe Leroy, Matthew Wilcox, Rik van Riel, Lorenzo Stoakes,
Axel Rasmussen, Yang Shi, John Hubbard, linux-arm-kernel,
Kirill A . Shutemov, Andrew Jones, Vlastimil Babka, Mike Rapoport,
Muchun Song, Christoph Hellwig, linux-riscv, James Houghton,
David Hildenbrand, Jason Gunthorpe, Andrea Arcangeli,
Aneesh Kumar K . V, Mike Kravetz
In-Reply-To: <20240321220802.679544-13-peterx@redhat.com>
On Thu, 21 Mar 2024 18:08:02 -0400 peterx@redhat.com wrote:
> From: Peter Xu <peterx@redhat.com>
>
> Now follow_page() is ready to handle hugetlb pages in whatever form, and
> over all architectures. Switch to the generic code path.
>
> Time to retire hugetlb_follow_page_mask(), following the previous
> retirement of follow_hugetlb_page() in 4849807114b8.
>
> There may be a slight difference of how the loops run when processing slow
> GUP over a large hugetlb range on cont_pte/cont_pmd supported archs: each
> loop of __get_user_pages() will resolve one pgtable entry with the patch
> applied, rather than relying on the size of hugetlb hstate, the latter may
> cover multiple entries in one loop.
>
> A quick performance test on an aarch64 VM on M1 chip shows 15% degrade over
> a tight loop of slow gup after the path switched. That shouldn't be a
> problem because slow-gup should not be a hot path for GUP in general: when
> page is commonly present, fast-gup will already succeed, while when the
> page is indeed missing and require a follow up page fault, the slow gup
> degrade will probably buried in the fault paths anyway. It also explains
> why slow gup for THP used to be very slow before 57edfcfd3419 ("mm/gup:
> accelerate thp gup even for "pages != NULL"") lands, the latter not part of
> a performance analysis but a side benefit. If the performance will be a
> concern, we can consider handle CONT_PTE in follow_page().
>
> Before that is justified to be necessary, keep everything clean and simple.
>
mm/gup.c:33:21: warning: 'follow_hugepd' declared 'static' but never defined [-Wunused-function]
33 | static struct page *follow_hugepd(struct vm_area_struct *vma, hugepd_t hugepd,
| ^~~~~~~~~~~~~
--- a/mm/gup.c~mm-gup-handle-hugepd-for-follow_page-fix
+++ a/mm/gup.c
@@ -30,10 +30,12 @@ struct follow_page_context {
unsigned int page_mask;
};
+#ifdef CONFIG_HAVE_FAST_GUP
static struct page *follow_hugepd(struct vm_area_struct *vma, hugepd_t hugepd,
unsigned long addr, unsigned int pdshift,
unsigned int flags,
struct follow_page_context *ctx);
+#endif
static inline void sanity_check_pinned_pages(struct page **pages,
unsigned long npages)
_
This looks inelegant.
That's two build issues so far. Please be more expansive in the
Kconfig variations when testing. Especially when mucking with pgtable
macros.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Why is the ARM SMMU v1/v2 put into bypass mode on kexec?
From: Tyler Hicks @ 2024-03-22 19:52 UTC (permalink / raw)
To: Will Deacon
Cc: Jason Gunthorpe, Robin Murphy, Jerry Snitselaar, linux-arm-kernel,
iommu, linux-kernel, Dexuan Cui, Easwar Hariharan
In-Reply-To: <20240322155529.GE5634@willie-the-truck>
On 2024-03-22 15:55:29, Will Deacon wrote:
> Hey Jason,
>
> On Tue, Mar 19, 2024 at 02:50:07PM -0300, Jason Gunthorpe wrote:
> > On Tue, Mar 19, 2024 at 03:47:56PM +0000, Will Deacon wrote:
> >
> > > Right, it's hard to win if DMA-active devices weren't quiesced properly
> > > by the outgoing kernel. Either the SMMU was left in abort (leading to the
> > > problems you list above) or the SMMU is left in bypass (leading to possible
> > > data corruption). Which is better?
> >
> > For whatever reason (and I really don't like this design) alot of work
> > was done on x86 so that device continues to work as-was right up until
> > the crash kernel does the first DMA operation. Including having the
> > crash kernel non disruptively inherit and retain the IOMMU
> > configuration. (eg see translation_pre_enabled() stuff in intel
> > driver)
>
> Right, I'm also not thrilled about trying to implement that :)
> What we have at the moment seems to be good enough to avoid folks
> complaining about it.
>
> For the case Tyler is reporting, though, I _think_ it's just a standard
> kexec() rather than a crashkernel.
That's correct.
Tyler
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v3 7/9] drm/atomic-helper: Add select_output_bus_format callback
From: Klymenko, Anatoliy @ 2024-03-22 19:15 UTC (permalink / raw)
To: Maxime Ripard
Cc: Laurent Pinchart, Maarten Lankhorst, Thomas Zimmermann,
David Airlie, Daniel Vetter, Simek, Michal, Andrzej Hajda,
Neil Armstrong, Robert Foss, Jonas Karlman, Jernej Skrabec,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Mauro Carvalho Chehab, Tomi Valkeinen,
dri-devel@lists.freedesktop.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-media@vger.kernel.org
In-Reply-To: <20240322-passionate-lyrebird-of-trust-819718@houat>
Hi Maxime,
Thank you for the review.
> -----Original Message-----
> From: Maxime Ripard <mripard@kernel.org>
> Sent: Friday, March 22, 2024 2:45 AM
> To: Klymenko, Anatoliy <Anatoliy.Klymenko@amd.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>; Maarten Lankhorst
> <maarten.lankhorst@linux.intel.com>; Thomas Zimmermann
> <tzimmermann@suse.de>; David Airlie <airlied@gmail.com>; Daniel Vetter
> <daniel@ffwll.ch>; Simek, Michal <michal.simek@amd.com>; Andrzej Hajda
> <andrzej.hajda@intel.com>; Neil Armstrong <neil.armstrong@linaro.org>; Robert
> Foss <rfoss@kernel.org>; Jonas Karlman <jonas@kwiboo.se>; Jernej Skrabec
> <jernej.skrabec@gmail.com>; Rob Herring <robh+dt@kernel.org>; Krzysztof
> Kozlowski <krzysztof.kozlowski+dt@linaro.org>; Conor Dooley
> <conor+dt@kernel.org>; Mauro Carvalho Chehab <mchehab@kernel.org>; Tomi
> Valkeinen <tomi.valkeinen@ideasonboard.com>; dri-devel@lists.freedesktop.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> devicetree@vger.kernel.org; linux-media@vger.kernel.org
> Subject: Re: [PATCH v3 7/9] drm/atomic-helper: Add select_output_bus_format
> callback
>
> On Thu, Mar 21, 2024 at 01:43:45PM -0700, Anatoliy Klymenko wrote:
> > diff --git a/drivers/gpu/drm/drm_crtc_helper.c
> > b/drivers/gpu/drm/drm_crtc_helper.c
> > index 2dafc39a27cb..f2e12a3c4e5f 100644
> > --- a/drivers/gpu/drm/drm_crtc_helper.c
> > +++ b/drivers/gpu/drm/drm_crtc_helper.c
> > @@ -1055,3 +1055,39 @@ int drm_helper_force_disable_all(struct
> drm_device *dev)
> > return ret;
> > }
> > EXPORT_SYMBOL(drm_helper_force_disable_all);
> > +
> > +/**
> > + * drm_helper_crtc_select_output_bus_format - Select output media bus
> > +format
> > + * @crtc: The CRTC to query
> > + * @crtc_state: The new CRTC state
> > + * @supported_fmts: List of media bus format options to pick from
> > + * @num_supported_fmts: Number of media bus formats in
> > +@supported_fmts list
> > + *
> > + * Encoder drivers may call this helper to give the connected CRTC a
> > +chance to
> > + * select compatible or preffered media bus format to use over the
> > +CRTC encoder
> > + * link. Encoders should provide list of supported input
> > +MEDIA_BUS_FMT_* for
> > + * CRTC to pick from. CRTC driver is expected to select preferred
> > +media bus
> > + * format from the list and, once enabled, generate the signal accordingly.
> > + *
> > + * Returns:
> > + * Selected preferred media bus format or 0 if CRTC does not support
> > +any from
> > + * @supported_fmts list.
> > + */
> > +u32 drm_helper_crtc_select_output_bus_format(struct drm_crtc *crtc,
> > + struct drm_crtc_state *crtc_state,
> > + const u32 *supported_fmts,
> > + unsigned int num_supported_fmts) {
> > + if (!crtc || !supported_fmts || !num_supported_fmts)
> > + return 0;
> > +
> > + if (!crtc->helper_private ||
> > + !crtc->helper_private->select_output_bus_format)
> > + return supported_fmts[0];
> > +
> > + return crtc->helper_private->select_output_bus_format(crtc,
> > + crtc_state,
> > + supported_fmts,
> > + num_supported_fmts);
> > +}
>
> Again, the output of that selection must be found in the CRTC state, otherwise
> CRTCs have no way to know which have been selected.
>
Yes, now I got it - thank you. I'll fix this in the next version.
> Maxime
Thank you,
Anatoliy
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 09/27] iommu/arm-smmu-v3: Allocate the CD table entry in advance
From: Mostafa Saleh @ 2024-03-22 19:15 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: iommu, Joerg Roedel, linux-arm-kernel, Robin Murphy, Will Deacon,
Eric Auger, Jean-Philippe Brucker, Moritz Fischer, Michael Shavit,
Nicolin Chen, patches, Shameerali Kolothum Thodi
In-Reply-To: <9-v5-9a37e0c884ce+31e3-smmuv3_newapi_p2_jgg@nvidia.com>
Hi Jason,
On Mon, Mar 04, 2024 at 07:43:57PM -0400, Jason Gunthorpe wrote:
> Avoid arm_smmu_attach_dev() having to undo the changes to the
> smmu_domain->devices list, acquire the cdptr earlier so we don't need to
> handle that error.
>
> Now there is a clear break in arm_smmu_attach_dev() where all the
> prep-work has been done non-disruptively and we commit to making the HW
> change, which cannot fail.
>
> This completes transforming arm_smmu_attach_dev() so that it does not
> disturb the HW if it fails.
>
> Tested-by: Nicolin Chen <nicolinc@nvidia.com>
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 24 +++++++--------------
> 1 file changed, 8 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index 2dd6cb17112e98..39081d828a2132 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -2676,6 +2676,7 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
> struct arm_smmu_device *smmu;
> struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
> struct arm_smmu_master *master;
> + struct arm_smmu_cd *cdptr;
>
> if (!fwspec)
> return -ENOENT;
> @@ -2704,6 +2705,12 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
> if (ret)
> return ret;
>
> + if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1) {
> + cdptr = arm_smmu_get_cd_ptr(master, IOMMU_NO_PASID);
> + if (!cdptr)
> + return -ENOMEM;
> + }
> +
> /*
> * Prevent arm_smmu_share_asid() from trying to change the ASID
> * of either the old or new domain while we are working on it.
> @@ -2723,13 +2730,6 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
> switch (smmu_domain->stage) {
> case ARM_SMMU_DOMAIN_S1: {
> struct arm_smmu_cd target_cd;
> - struct arm_smmu_cd *cdptr;
> -
> - cdptr = arm_smmu_get_cd_ptr(master, IOMMU_NO_PASID);
> - if (!cdptr) {
> - ret = -ENOMEM;
> - goto out_list_del;
> - }
>
> arm_smmu_make_s1_cd(&target_cd, master, smmu_domain);
> arm_smmu_write_cd_entry(master, IOMMU_NO_PASID, cdptr,
> @@ -2746,16 +2746,8 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
> }
>
> arm_smmu_enable_ats(master, smmu_domain);
> - goto out_unlock;
> -
> -out_list_del:
> - spin_lock_irqsave(&smmu_domain->devices_lock, flags);
> - list_del_init(&master->domain_head);
> - spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
> -
> -out_unlock:
> mutex_unlock(&arm_smmu_asid_lock);
> - return ret;
> + return 0;
> }
>
> static int arm_smmu_attach_dev_ste(struct device *dev,
> --
> 2.43.2
>
I believe this is fine, I couldn’t break it. With the comment on the previous
patch, where we explicitly allocate the CD here and not inside
arm_smmu_get_cd_ptr().
Reviewed-by: Mostafa Saleh <smostafa@google.com>
Thanks,
Mostafa
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v3 8/9] dt-bindings: xlnx: Add VTC and TPG bindings
From: Klymenko, Anatoliy @ 2024-03-22 19:12 UTC (permalink / raw)
To: Krzysztof Kozlowski, Laurent Pinchart, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Daniel Vetter,
Simek, Michal, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Mauro Carvalho Chehab
Cc: Tomi Valkeinen, dri-devel@lists.freedesktop.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-media@vger.kernel.org
In-Reply-To: <a82d525c-737a-4ac4-9d71-e88f4ba69ea1@linaro.org>
Hi Krzysztof,
Thanks a lot for the review.
> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Sent: Thursday, March 21, 2024 10:59 PM
> To: Klymenko, Anatoliy <Anatoliy.Klymenko@amd.com>; Laurent Pinchart
> <laurent.pinchart@ideasonboard.com>; Maarten Lankhorst
> <maarten.lankhorst@linux.intel.com>; Maxime Ripard <mripard@kernel.org>;
> Thomas Zimmermann <tzimmermann@suse.de>; David Airlie
> <airlied@gmail.com>; Daniel Vetter <daniel@ffwll.ch>; Simek, Michal
> <michal.simek@amd.com>; Andrzej Hajda <andrzej.hajda@intel.com>; Neil
> Armstrong <neil.armstrong@linaro.org>; Robert Foss <rfoss@kernel.org>; Jonas
> Karlman <jonas@kwiboo.se>; Jernej Skrabec <jernej.skrabec@gmail.com>; Rob
> Herring <robh+dt@kernel.org>; Krzysztof Kozlowski
> <krzysztof.kozlowski+dt@linaro.org>; Conor Dooley <conor+dt@kernel.org>;
> Mauro Carvalho Chehab <mchehab@kernel.org>
> Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>; dri-
> devel@lists.freedesktop.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; devicetree@vger.kernel.org; linux-
> media@vger.kernel.org
> Subject: Re: [PATCH v3 8/9] dt-bindings: xlnx: Add VTC and TPG bindings
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On 21/03/2024 21:43, Anatoliy Klymenko wrote:
> > diff --git a/include/dt-bindings/media/media-bus-format.h b/include/dt-
> bindings/media/media-bus-format.h
> > new file mode 100644
> > index 000000000000..60fc6e11dabc
> > --- /dev/null
> > +++ b/include/dt-bindings/media/media-bus-format.h
> > @@ -0,0 +1,177 @@
> > +/* SPDX-License-Identifier: (GPL-2.0-only OR MIT) */
> > +/*
> > + * Media Bus API header
> > + *
> > + * Copyright (C) 2009, Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
>
> That's not true. Your SPDX tells something entirely different.
>
Thank you - I'll see how to fix it.
> Anyway, you did not explain why you need to copy anything anywhere.
>
> Specifically, random hex values *are not bindings*.
>
The same media bus format values are being used by the reference driver in patch #9. And, as far as I know, we cannot use headers from Linux API headers directly (at least I noticed the same pattern in ../dt-bindings/sdtv-standarts.h for instance). What would be the best approach to reusing the same defines on DT and driver sides from your point of view? Symlink maybe?
> Best regards,
> Krzysztof
Thank you,
Anatoliy
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox