On Thu, Jul 22, 2021 at 12:38:10PM +0200, Daniel Vetter wrote:
> On Thu, Jul 22, 2021 at 05:29:27PM +0800, Desmond Cheong Zhi Xi wrote:
> > Inside drm_is_current_master, using the outer drm_device.master_mutex
> > to protect reads of drm_file.master makes the function prone to creating
> > lock hie
On Thu, Jul 22, 2021 at 09:02:41PM +0200, Daniel Vetter wrote:
> On Thu, Jul 22, 2021 at 6:00 PM Boqun Feng wrote:
> >
> > On Thu, Jul 22, 2021 at 12:38:10PM +0200, Daniel Vetter wrote:
> > > On Thu, Jul 22, 2021 at 05:29:27PM +0800, Desmond Cheong Zhi
On Fri, Jul 30, 2021 at 12:15:15PM +0800, Desmond Cheong Zhi Xi wrote:
> In drm_is_current_master_locked, accessing drm_file.master should be
> protected by either drm_file.master_lookup_lock or
> drm_device.master_mutex. This was previously awkward to assert with
> lockdep.
>
> Following patch ("
On Fri, Jul 30, 2021 at 04:06:44PM +0800, Desmond Cheong Zhi Xi wrote:
> On 30/7/21 2:08 pm, Boqun Feng wrote:
> > On Fri, Jul 30, 2021 at 12:15:15PM +0800, Desmond Cheong Zhi Xi wrote:
> > > In drm_is_current_master_locked, accessing drm_file.master should be
> &g
> Fixes: d21987d709e8 ("video: hyperv: hyperv_fb: Support deferred IO for
> Hyper-V frame buffer driver")
> Fixes: 3a6fb6c4255c ("video: hyperv: hyperv_fb: Use physical memory for fb on
> HyperV Gen 1 VMs.")
> Cc: Wei Hu
> Cc: Boqun Feng
> Signed-off-by: Dexuan
On Thu, Dec 17, 2020 at 07:21:18AM -0800, Paul E. McKenney wrote:
> On Thu, Dec 17, 2020 at 11:03:20AM +0100, Daniel Vetter wrote:
> > On Wed, Dec 16, 2020 at 5:16 PM Paul E. McKenney wrote:
> > >
> > > On Wed, Dec 16, 2020 at 10:52:06AM +0100, Daniel Vetter wrote:
> > > > On Wed, Dec 16, 2020 at
Hi Dmitry,
On Fri, Dec 18, 2020 at 12:27:04PM +0100, Dmitry Vyukov wrote:
> On Fri, Dec 18, 2020 at 2:30 AM Boqun Feng wrote:
> >
> > On Thu, Dec 17, 2020 at 07:21:18AM -0800, Paul E. McKenney wrote:
> > > On Thu, Dec 17, 2020 at 11:03:20AM +0100, Daniel Vetter wrote
[Cc Waiman]
On Mon, Jan 16, 2023 at 10:00:52AM -0800, Linus Torvalds wrote:
> [ Back from travel, so trying to make sense of this series.. ]
>
> On Sun, Jan 8, 2023 at 7:33 PM Byungchul Park wrote:
> >
> > I've been developing a tool for detecting deadlock possibilities by
> > tracking wait/even
On Thu, Jan 19, 2023 at 01:33:58PM +, Matthew Wilcox wrote:
> On Thu, Jan 19, 2023 at 03:23:08PM +0900, Byungchul Park wrote:
> > Boqun wrote:
> > > * Looks like the DEPT dependency graph doesn't handle the
> > > fair/unfair readers as lockdep current does. Which bring the
> > > next questi
On Fri, Jan 20, 2023 at 10:51:45AM +0900, Byungchul Park wrote:
> Boqun wrote:
> > On Thu, Jan 19, 2023 at 01:33:58PM +, Matthew Wilcox wrote:
> > > On Thu, Jan 19, 2023 at 03:23:08PM +0900, Byungchul Park wrote:
> > > > Boqun wrote:
> > > > > *Looks like the DEPT dependency graph doesn't handl
On Thu, Jan 19, 2023 at 06:23:49PM -0800, Boqun Feng wrote:
> On Fri, Jan 20, 2023 at 10:51:45AM +0900, Byungchul Park wrote:
> > Boqun wrote:
> > > On Thu, Jan 19, 2023 at 01:33:58PM +, Matthew Wilcox wrote:
> > > > On Thu, Jan 19, 2023 at 03:23:08
On Thu, Jan 19, 2023 at 07:07:59PM -0800, Boqun Feng wrote:
> On Thu, Jan 19, 2023 at 06:23:49PM -0800, Boqun Feng wrote:
> > On Fri, Jan 20, 2023 at 10:51:45AM +0900, Byungchul Park wrote:
> > > Boqun wrote:
> > > > On Thu, Jan 19, 2023 at 01:33:58PM +, Matthew
On Sat, Jan 21, 2023 at 12:28:14PM +0900, Byungchul Park wrote:
> On Thu, Jan 19, 2023 at 07:07:59PM -0800, Boqun Feng wrote:
> > On Thu, Jan 19, 2023 at 06:23:49PM -0800, Boqun Feng wrote:
> > > On Fri, Jan 20, 2023 at 10:51:45AM +0900, Byungchul Park wrote:
>
On Tue, Mar 07, 2023 at 11:25:27PM +0900, Asahi Lina wrote:
[...]
> +
> +// SAFETY: `Device` only holds a pointer to a C device, which is safe to be
> used from any thread.
> +unsafe impl Send for Device {}
> +
> +// SAFETY: `Device` only holds a pointer to a C device, references to which
> are s
On Tue, Mar 07, 2023 at 11:25:27PM +0900, Asahi Lina wrote:
> Add the initial abstractions for DRM drivers and devices. These go
> together in one commit since they are fairly tightly coupled types.
>
> A few things have been stubbed out, to be implemented as further bits of
> the DRM subsystem ar
On Mon, Mar 13, 2023 at 12:49:57PM -0500, Faith Ekstrand wrote:
> On Fri, 2023-03-10 at 07:16 +0900, Asahi Lina wrote:
> > On 10/03/2023 06.16, Faith Ekstrand wrote:
> > > On Tue, 2023-03-07 at 23:25 +0900, Asahi Lina wrote:
> > > > A DRM File is the DRM counterpart to a kernel file structure,
> >
On Thu, May 23, 2024 at 08:15:13AM +0900, FUJITA Tomonori wrote:
> Hi,
>
> On Wed, 22 May 2024 09:37:30 +0200
> Philipp Stanner wrote:
>
> >> > +/// Abstraction around a C firmware struct.
> >> > +///
> >> > +/// This is a simple abstraction around the C firmware API. Just
> >> > like with the C
lock_dep_map, 0, 0, &ctx->dep_map,
_RET_IP_);
#endif
A v3 with all these fixed would look good to me, and I can add a
Tested-by tag to it. Thanks!
Regards,
Boqun
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: Will Deacon
> Cc: Waiman Long
> Cc: Boqun Feng
> Cc: Maarten
ock():
__mutex_lock_common():
mutex_acquire_nest(...);
in the test case, these two mutex_acquire_nest()s use different
lockdep_maps but share the same key, therefore whoever call
mutex_acquire_nest() registers the lock class with its wait types.
So even though first_loc
On Wed, Oct 16, 2024 at 08:17:50AM +0200, Thomas Hellström wrote:
[...]
> >
> > So even though first_lock_dep_map is a fake lock, it has to have the
> > same wait types as a real mutex.
>
> Understood.
> >
> > Does this make sense?
>
> Yes it does. I'll update to a v3, and add a Tested-by: tag.
t overflowing lockdep held lock
> references.
>
> v3:
> - Adjust the ww_test_normal locking-api selftest to avoid
> recursive locking (Boqun Feng)
> - Initialize the dummy lock map with LD_WAIT_SLEEP to agree with
> how the corresponding ww_mutex lockmaps are initialized
&
On Sat, Dec 28, 2024 at 01:52:28AM -0800, Boqun Feng wrote:
> On Fri, Dec 27, 2024 at 06:03:45PM -0800, Suren Baghdasaryan wrote:
> > On Fri, Dec 27, 2024 at 4:19 PM Hillf Danton wrote:
> > >
> > > On Fri, 27 Dec 2024 04:59:22 -0800
> > > > Hello,
> >
On Wed, Apr 16, 2025 at 01:36:06PM -0400, Tamir Duberstein wrote:
> In Rust 1.72.0, Clippy introduced the `ptr_cast_constness` lint [1]:
>
> > Though `as` casts between raw pointers are not terrible,
> > `pointer::cast_mut` and `pointer::cast_const` are safer because they
> > cannot accidentally c
nge and enable the lint -- no functional change intended.
>
> Link:
> https://rust-lang.github.io/rust-clippy/master/index.html#as_ptr_cast_mut [1]
> Reviewed-by: Benno Lossin
> Signed-off-by: Tamir Duberstein
Reviewed-by: Boqun Feng
Regards,
Boqun
> ---
> Makefile
On Thu, Apr 17, 2025 at 03:26:14PM -0400, Tamir Duberstein wrote:
[...]
> >
> > > Ok(())
> > > }
> > > diff --git a/rust/kernel/device_id.rs b/rust/kernel/device_id.rs
> > > index e5859217a579..4063f09d76d9 100644
> > > --- a/rust/kernel/device_id.rs
> > > +++ b/rust/kernel/device_id.
On Fri, Apr 18, 2025 at 08:08:02AM -0400, Tamir Duberstein wrote:
> On Thu, Apr 17, 2025 at 4:12 PM Boqun Feng wrote:
> >
> > On Thu, Apr 17, 2025 at 03:26:14PM -0400, Tamir Duberstein wrote:
> > [...]
> > > >
> > > > > Ok(())
>
On Wed, Apr 16, 2025 at 01:36:09PM -0400, Tamir Duberstein wrote:
> Before Rust 1.29.0, Clippy introduced the `cast_lossless` lint [1]:
>
> > Rust’s `as` keyword will perform many kinds of conversions, including
> > silently lossy conversions. Conversion functions such as `i32::from`
> > will only
On Wed, Apr 16, 2025 at 01:36:08PM -0400, Tamir Duberstein wrote:
> In Rust 1.63.0, Clippy introduced the `as_underscore` lint [1]:
>
> > The conversion might include lossy conversion or a dangerous cast that
> > might go undetected due to the type being inferred.
> >
> > The lint is allowed by de
s and enable the lint -- no functional change
> intended.
>
> Link: https://rust-lang.github.io/rust-clippy/master/index.html#ptr_as_ptr [1]
> Reviewed-by: Benno Lossin
> Signed-off-by: Tamir Duberstein
Reviewed-by: Boqun Feng
A few nits below though...
> ---
> Makefil
On Wed, Apr 16, 2025 at 01:53:34PM -0400, Tamir Duberstein wrote:
> On Wed, Apr 16, 2025 at 1:51 PM Boqun Feng wrote:
> >
> > On Wed, Apr 16, 2025 at 01:36:10PM -0400, Tamir Duberstein wrote:
> > > In Rust 1.78.0, Clippy introduced the `ref_as_ptr` lint [1]:
> >
s_ptr [1]
> Suggested-by: Benno Lossin
> Link: https://lore.kernel.org/all/d8pgg7ntwb6u.3ss3a5ln4x...@proton.me/
> Reviewed-by: Benno Lossin
> Signed-off-by: Tamir Duberstein
Reviewed-by: Boqun Feng
Thanks!
Regards,
Boqun
> ---
> Makefile | 1 +
> rus
On Wed, Apr 09, 2025 at 10:47:23AM -0400, Tamir Duberstein wrote:
> In Rust 1.78.0, Clippy introduced the `ref_as_ptr` lint [1]:
>
> > Using `as` casts may result in silently changing mutability or type.
>
> While this doesn't eliminate unchecked `as` conversions, it makes such
> conversions easi
On Tue, Apr 15, 2025 at 01:58:41PM -0400, Tamir Duberstein wrote:
> Hi Boqun, thanks for having a look!
>
> On Tue, Apr 15, 2025 at 1:37 PM Boqun Feng wrote:
> >
> > On Wed, Apr 09, 2025 at 10:47:23AM -0400, Tamir Duberstein wrote:
> > > In Rust 1.78.0, Clippy intro
On Tue, Apr 15, 2025 at 04:10:01PM -0400, Tamir Duberstein wrote:
> On Tue, Apr 15, 2025 at 2:18 PM Boqun Feng wrote:
> >
> > On Tue, Apr 15, 2025 at 01:58:41PM -0400, Tamir Duberstein wrote:
> > > Hi Boqun, thanks for having a look!
> > >
> > > On Tue,
On Tue, Apr 15, 2025 at 04:59:01PM -0400, Tamir Duberstein wrote:
[...]
> > > > > > > diff --git a/rust/kernel/device_id.rs b/rust/kernel/device_id.rs
> > > > > > > index 4063f09d76d9..37cc03d1df4c 100644
> > > > > > > --- a/rust/kernel/device_id.rs
> > > > > > > +++ b/rust/kernel/device_id.rs
> >
On Tue, Apr 15, 2025 at 07:08:42PM -0400, Tamir Duberstein wrote:
[...]
> > > >
> > > > > > also from the link document you shared, looks like the suggestion
> > > > > > is to
> > > > > > use core::ptr::from_{ref,mut}(), was this ever considered?
> > > > >
> > > > > I considered it, but I thought
`as` conversions, it makes such
> conversions easier to scrutinize. It also has the slight benefit of
> removing a degree of freedom on which to bikeshed. Thus apply the
> changes and enable the lint -- no functional change intended.
>
> Link: https://rust-lang.github.io/rust-clippy/m
ps://rust-lang.github.io/rust-clippy/master/index.html#cast_lossless
> [1]
> Suggested-by: Benno Lossin
> Link: https://lore.kernel.org/all/d8ortxsutkgl.1kojagbm8f...@proton.me/
> Reviewed-by: Benno Lossin
Reviewed-by: Boqun Feng
Regards,
Boqun
> Signed-off-by: Tamir Duberstein
anges and enable the lint -- no functional change
> intended.
>
> Link:
> https://rust-lang.github.io/rust-clippy/master/index.html#ptr_cast_constness
> [1]
> Reviewed-by: Benno Lossin
> Signed-off-by: Tamir Duberstein
Reviewed-by: Boqun Feng
Regards,
Boqun
> ---
>
On Thu, Feb 27, 2025 at 05:02:02PM +, Alice Ryhl wrote:
> This validates at compile time that the signatures match what is in the
> header file. It highlights one annoyance with the compile-time check,
> which is that it can only be used with functions marked unsafe.
>
> If the function is not
On Thu, Feb 27, 2025 at 03:23:21PM -0400, Jason Gunthorpe wrote:
> On Thu, Feb 27, 2025 at 06:32:15PM +0100, Danilo Krummrich wrote:
> > On Thu, Feb 27, 2025 at 08:55:09AM -0800, Boqun Feng wrote:
> > > On Thu, Feb 27, 2025 at 12:17:33PM -0400, Jason Gunthorpe wrote:
> > &
On Thu, Feb 27, 2025 at 10:46:18AM -0400, Jason Gunthorpe wrote:
> On Wed, Feb 26, 2025 at 04:41:08PM -0800, Boqun Feng wrote:
> > And if you don't store the HrTimerHandle anywhere, like you drop() it
> > right after start a hrtimer, it will immediately stop the timer. Does
On Thu, Feb 27, 2025 at 12:17:33PM -0400, Jason Gunthorpe wrote:
> On Thu, Feb 27, 2025 at 07:18:02AM -0800, Boqun Feng wrote:
> > On Thu, Feb 27, 2025 at 10:46:18AM -0400, Jason Gunthorpe wrote:
> > > On Wed, Feb 26, 2025 at 04:41:08PM -0800, Boqun Feng wrote:
> > > &
On Wed, Feb 26, 2025 at 07:47:30PM -0400, Jason Gunthorpe wrote:
[...]
>
> > Other abstractions do consider this though, e.g. the upcoming hrtimer work.
> > [1]
>
> Does it??? hrtimer uses function pointers. Any time you take a
> function pointer you have to reason about how does the .text lifet
Hi Alexandre,
On Thu, Mar 20, 2025 at 10:39:14PM +0900, Alexandre Courbot wrote:
> Add a basic timer device and exercise it during device probing. This
> first draft is probably very questionable.
>
> One point in particular which should IMHO receive attention: the generic
> wait_on() method aims
On Wed, May 21, 2025 at 03:44:58PM +0900, Alexandre Courbot wrote:
> nova-core will need to use SZ_1M, so make the remaining constants
> available.
>
> Signed-off-by: Alexandre Courbot
Reviewed-by: Boqun Feng
Regards,
Boqun
> ---
> rust/kernel/sizes.rs | 24 +++
On Wed, May 21, 2025 at 03:44:56PM +0900, Alexandre Courbot wrote:
> These properties are very useful to have and should be accessible.
>
> Signed-off-by: Alexandre Courbot
> ---
> rust/kernel/dma.rs | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/rust/kernel/dma.rs
On Thu, Jun 19, 2025 at 03:17:31PM +0200, Benno Lossin wrote:
> On Thu Jun 19, 2025 at 2:26 PM CEST, Daniel Almeida wrote:
> > Hi Benno,
> >
> >> On 19 Jun 2025, at 08:01, Benno Lossin wrote:
> >>
> >> On Thu Jun 19, 2025 at 12:55 PM CEST, Danilo Krummrich wrote:
> >>> On Thu, Jun 19, 2025 at 12:
t;
> To help catch this kind of mistake, add a new Opaque::cast_from that
> wraps a raw pointer in Opaque without changing the inner type. Also
> rename raw_get() to cast_into() for naming consistency.
>
> Signed-off-by: Alice Ryhl
Acked-by: Boqun Feng
Thanks!
Regards,
Boqun
On Fri, Jun 13, 2025 at 11:16:10PM +0900, Alexandre Courbot wrote:
[...]
> >> +#[repr(transparent)]
> >> +pub struct PowerOfTwo(T);
> >> +
> >> +macro_rules! power_of_two_impl {
> >> +($($t:ty),+) => {
> >> +$(
> >> +impl PowerOfTwo<$t> {
> >> +/// Validates
On Mon, Jun 23, 2025 at 05:14:37PM +0200, Benno Lossin wrote:
> On Mon Jun 23, 2025 at 4:47 PM CEST, Boqun Feng wrote:
> > On Mon, Jun 23, 2025 at 03:44:58PM +0200, Benno Lossin wrote:
> >> I didn't have a concrete API in mind, but after having read the
> >> ab
On Fri, Jun 13, 2025 at 11:16:10PM +0900, Alexandre Courbot wrote:
[...]
> >> +/// Aligns `self` down to `alignment`.
> >> +///
> >> +/// # Examples
> >> +///
> >> +/// ```
> >> +/// use kernel::num::Pow
On Thu, Jun 12, 2025 at 11:01:32PM +0900, Alexandre Courbot wrote:
[...]
> +/// An unsigned integer which is guaranteed to be a power of 2.
> +#[derive(Debug, Clone, Copy)]
> +#[repr(transparent)]
> +pub struct PowerOfTwo(T);
> +
[...]
> +impl Deref for PowerOfTwo {
Why do we need `impl Deref` (an
unsafe {
> -&*(raw_data as *const
> $crate::types::Opaque<$crate::uapi::$struct>)
> -};
> + // The `ioctl` argument is exclusively owned by
> the handler
> +
On Thu, Jun 12, 2025 at 01:00:12PM -0700, John Hubbard wrote:
> On 6/12/25 8:07 AM, Boqun Feng wrote:
> > On Thu, Jun 12, 2025 at 11:01:32PM +0900, Alexandre Courbot wrote:
> ...
> >> +#[inline(always)]
> >> +pub const fn ali
On Thu, Jun 12, 2025 at 01:08:25PM -0700, John Hubbard wrote:
> On 6/12/25 1:05 PM, Boqun Feng wrote:
> > On Thu, Jun 12, 2025 at 01:00:12PM -0700, John Hubbard wrote:
> >> On 6/12/25 8:07 AM, Boqun Feng wrote:
> >>> On Thu, Jun 12, 2025 at 11:01:32PM
On Thu, Jun 12, 2025 at 11:01:32PM +0900, Alexandre Courbot wrote:
> Introduce the `num` module, featuring the `PowerOfTwo` unsigned wrapper
> that guarantees (at build-time or runtime) that a value is a power of
> two.
>
> Such a property is often useful to maintain. In the context of the
> kerne
On Fri, Jun 27, 2025 at 07:34:04PM -0300, Daniel Almeida wrote:
[...]
> +#[pin_data]
> +pub(crate) struct TyrData {
> +pub(crate) pdev: ARef,
> +
> +#[pin]
> +clks: Mutex,
> +
> +#[pin]
> +regulators: Mutex,
> +
> +// Some inforation on the GPU. This is mainly queried by use
On Fri, Jun 27, 2025 at 07:36:33PM -0300, Daniel Almeida wrote:
> I´ll fix the missing "rust: drm:" tags on a v2.
>
No worries. For a second I thought you meant to write "Introduce Tyrion"
;-)
Regards,
Boqun
> - Daniel
e: register: add the missing space in register!()
Otherwise my fear is we're going to end up with a few "fix typo" commits
in the future.
Anyway
Reviewed-by: Boqun Feng
Regards,
Boqun
> Signed-off-by: Alexandre Courbot
> ---
> drivers/gpu/nova-core/regs/macros.rs |
60 matches
Mail list logo
