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
`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
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 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 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 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
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
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 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
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 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
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 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 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 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
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 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 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 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 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 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
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,
> >
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 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.
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
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
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
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 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 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 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 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 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 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 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
[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 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
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 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 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
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
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
> 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
45 matches
Mail list logo
