On Thursday, 27 May 2021 5:28:32 AM AEST Peter Xu wrote:
> On Mon, May 24, 2021 at 11:27:22PM +1000, Alistair Popple wrote:
> > Some devices require exclusive write access to shared virtual
> > memory (SVM) ranges to perform atomic operations on that memory. This
> > requires CPU page tables to be
On Thursday, 27 May 2021 5:50:05 AM AEST Peter Xu wrote:
> On Mon, May 24, 2021 at 11:27:21PM +1000, Alistair Popple wrote:
> > Currently if copy_nonpresent_pte() returns a non-zero value it is
> > assumed to be a swap entry which requires further processing outside the
> > loop in
On Thursday, 27 May 2021 12:04:59 AM AEST Colin King wrote:
> The call to make_device_exclusive_range can potentially fail leaving
> pointer page not initialized that leads to an uninitialized pointer
> read issue. Fix this by adding a check to see if the call failed and
> returning the error
On Mon, May 24, 2021 at 11:27:21PM +1000, Alistair Popple wrote:
> Currently if copy_nonpresent_pte() returns a non-zero value it is
> assumed to be a swap entry which requires further processing outside the
> loop in copy_pte_range() after dropping locks. This prevents other
> values being
On Mon, May 24, 2021 at 11:27:20PM +1000, Alistair Popple wrote:
> @@ -521,14 +521,14 @@ static inline void mmu_notifier_range_init(struct
> mmu_notifier_range *range,
> range->flags = flags;
> }
>
> -static inline void mmu_notifier_range_init_migrate(
> - struct
On Mon, May 24, 2021 at 11:27:22PM +1000, Alistair Popple wrote:
> Some devices require exclusive write access to shared virtual
> memory (SVM) ranges to perform atomic operations on that memory. This
> requires CPU page tables to be updated to deny access whilst atomic
> operations are occurring.
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
Lee Jones (34):
drm/amd/pm/inc/smu_v13_0: Move table into the only source file that
uses it
drm/amd/pm/swsmu/smu13/aldebaran_ppt: Remove
From: Colin Ian King
The call to make_device_exclusive_range can potentially fail leaving
pointer page not initialized that leads to an uninitialized pointer
read issue. Fix this by adding a check to see if the call failed and
returning the error code.
Addresses-Coverity: ("Uninitialized
On Wednesday, 26 May 2021 5:17:18 PM AEST John Hubbard wrote:
> On 5/25/21 4:51 AM, Balbir Singh wrote:
> ...
>
> >> How beneficial is this code to nouveau users? I see that it permits a
> >> part of OpenCL to be implemented, but how useful/important is this in
> >> the real world?
> >
> > That
Patches #1-#4 are Reviewed-by: Christian König
Patches #5 and #6 are Acked-by: Christian König
Patch #7 already has my rb.
I would say push that to drm-misc-next ASAP.
Regards,
Christian.
Am 25.05.21 um 17:10 schrieb Thomas Zimmermann:
Implement mmap via struct
On Wed, May 26, 2021 at 10:47 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nvkm/subdev/mc/tu102.c:50:1: warning: no previous
> prototype for ‘tu102_mc_intr_unarm’ [-Wmissing-prototypes]
>
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/nvkm/subdev/mc/tu102.c:50:1: warning: no previous
prototype for ‘tu102_mc_intr_unarm’ [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/mc/tu102.c:62:1: warning: no previous
prototype for ‘tu102_mc_intr_rearm’
On 5/25/21 4:51 AM, Balbir Singh wrote:
...
How beneficial is this code to nouveau users? I see that it permits a
part of OpenCL to be implemented, but how useful/important is this in
the real world?
That is a very good question! I've not reviewed the code, but a sample
program with the
13 matches
Mail list logo
