On Wed, 24 Jan 2024 02:15:21 -0800
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:615d30064886 Merge tag 'trace-v6.8-rc1' of git://git.kerne..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=167456f7e8
> kernel config: https://syz
On Wed, 17 Jan 2024 04:12:10 +0100 Erico Nunes
>
> @@ -401,9 +399,33 @@ static enum drm_gpu_sched_stat
> lima_sched_timedout_job(struct drm_sched_job *job
> struct lima_sched_pipe *pipe = to_lima_pipe(job->sched);
> struct lima_sched_task *task = to_lima_task(job);
> struct li
On Wed, 12 Apr 2023 10:15:29 +0100 Rui Salvaterra
> Hi, everyone,
>
> I apologise in advance if I've sent this to {too many, the wrong}
> people. For some time now, I've been getting sporadic (in about one
> out of five boots) DRM-related RCU complaints on an Ivy Bridge-based
> (Core i7-3720QM) M
On 3 Apr 2023 17:47:50 +0200 Paul Cercueil
> This function can be used to initiate a scatter-gather DMA transfer
> where the DMA addresses and lengths are located inside arrays.
>
> The major difference with dmaengine_prep_slave_sg() is that it supports
> specifying the lengths of each DMA transf
On 9 Jan 2023 21:38:06 + T.J. Mercier
>
> @@ -2275,6 +2276,26 @@ static int binder_translate_fd(u32 fd, binder_size_t
> fd_offset,
> goto err_security;
> }
>
> + if (IS_ENABLED(CONFIG_MEMCG) && (flags & BINDER_FD_FLAG_XFER_CHARGE)) {
> + struct dma_buf
On 1 Nov 2022 15:33:10 -0700 Rob Clark
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -500,6 +500,21 @@ static void hangcheck_timer_reset(struct msm_gpu *gpu)
> round_jiffies_up(jiffies +
> msecs_to_jiffies(priv->hangcheck_period)));
> }
>
On Thu, 17 Mar 2022 14:07:45 -0700 Rob Clark wrote:
> On Thu, Mar 17, 2022 at 1:45 PM Akhil P Oommen
> wrote:
> >
> > On 3/11/2022 5:16 AM, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > The mutex wasn't really protecting anything before. Before the previous
> > > patch we could still be ra
On Fri, 17 Sep 2021 14:59:43 +0200 Alexandre Bailon wrote:
> +static DEFINE_IDA(req_ida);
> +static LIST_HEAD(complete_node);
I see accesses to complete_node in apu_drm_callback(), apu_job_timedout()
and ioctl_gem_dequeue() without working out the serialization to avoid
list corruption. Can you ad
On Wed, 10 Mar 2021 19:01:01 + Paul Cercueil wrote:
>Le lun. 8 mars 2021 � 11:47, Hillf Danton a �crit :
>> On Sun, 7 Mar 2021 20:28:35 + Paul Cercueil wrote:
>>> With the module parameter ingenic-drm.cached_gem_buffers, it is
>>> possible
>>>
On Sun, 7 Mar 2021 20:28:35 + Paul Cercueil wrote:
> With the module parameter ingenic-drm.cached_gem_buffers, it is possible
> to specify that we want GEM buffers backed by non-coherent memory.
>
> This dramatically speeds up software rendering on Ingenic SoCs, even for
> tasks where write-
On Thu, 31 Dec 2020 11:40:20 +0100 Borislav Petkov wrote:
> Hi folks,
>
> got this when trying to suspend my workstation to disk, it was still
> responsive so I could catch the splat:
>
> [22020.334381] [ cut here ]
> [22020.339057] list_del corruption. next->prev should b
On Thu, 29 Oct 2020 12:34:51 -0700 John Stultz wrote:
>
> As for your comment on HPAGE_PMD_ORDER (9 on arm64/arm) and
> PAGE_ALLOC_COSTLY_ORDER(3), I'm not totally sure I understand your
> question? Are you suggesting those values would be more natural orders
> to choose from?
The numbers, 9 and
On Thu, 29 Oct 2020 15:28:34 -0700 John Stultz wrote:
> On Thu, Oct 29, 2020 at 12:10 AM Hillf Danton wrote:
> > On Thu, 29 Oct 2020 00:16:24 + John Stultz wrote:
> > > @@ -194,6 +210,9 @@ static int system_heap_mmap(struct dma_buf *dmabuf,
> > >
On Thu, 29 Oct 2020 21:04:30 -0700 John Stultz wrote:
>
> But I'll try to share my thoughts:
>
> So the system heap allows for allocation of non-contiguous buffers
> (currently allocated from page_alloc), which we keep track using
> sglists.
> Since the resulting dmabufs are shared between multip
On Thu, 29 Oct 2020 00:16:22 + John Stultz wrote:
>
> +#define HIGH_ORDER_GFP (((GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN \
> + | __GFP_NORETRY) & ~__GFP_RECLAIM) \
> + | __GFP_COMP)
> +#define LOW_ORDER_GFP (GFP_HIGHUSER | __GFP_ZERO |
On Thu, 29 Oct 2020 00:16:24 + John Stultz wrote:
>
> This adds a heap that allocates non-contiguous buffers that are
> marked as writecombined, so they are not cached by the CPU.
>
> This is useful, as most graphics buffers are usually not touched
> by the CPU or only written into once by th
On Mon, 5 Oct 2020 20:40:12 Rob Clark wrote:
> On Mon, Oct 5, 2020 at 5:44 PM Hillf Danton wrote:
> > On Mon, 5 Oct 2020 18:17:01 Kristian H. Kristensen wrote:
> > > On Mon, Oct 5, 2020 at 4:02 PM Daniel Vetter wrote:
> > > >
> > > > On Mon, Oct
On Mon, 5 Oct 2020 18:17:01 Kristian H. Kristensen wrote:
> On Mon, Oct 5, 2020 at 4:02 PM Daniel Vetter wrote:
> >
> > On Mon, Oct 05, 2020 at 05:24:19PM +0800, Hillf Danton wrote:
> > >
> > > On Sun, 4 Oct 2020 12:21:45
> > > > From: Rob Clark
On Sun, 4 Oct 2020 12:21:45
> From: Rob Clark
>
> Now that the inactive_list is protected by mm_lock, and everything
> else on per-obj basis is protected by obj->lock, we no longer depend
> on struct_mutex.
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_gem.c | 1 -
>
Sat, 19 Sep 2020 12:37:25 -0700 Rob Clark wrote:
>
> @@ -1797,6 +1797,7 @@ int drm_atomic_helper_commit(struct drm_device *dev,
>struct drm_atomic_state *state,
>bool nonblock)
> {
> + struct kthread_worker *worker = NULL;
> int
On Sat, 19 Sep 2020 12:37:26 -0700 Rob Clark wrote:
> +/**
> + * drm_crtc_set_sched_mode:
> + * @dev: DRM device
> + * @mode: one of DRM_CLIENT_CAP_SCHED_x
> + *
> + * Set the scheduling mode for per-CRTC kthread workers. This controls
> + * whether nonblocking atomic commits will run with SCHED
Sun, 26 Apr 2020 20:48:12 -0700
> syzbot found the following crash on:
>
> HEAD commit:c578ddb3 Merge tag 'linux-kselftest-5.7-rc3' of git://git...
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=10fbf0d810
> kernel config: https://syzkaller.appspo
On Sat, 11 Apr 2020 00:51:48 +0500 Mikhail Gavrilov wrote:
> Hi folks.
> After upgrade kernel to 5.7 I see every boot in kernel log following
> error messages:
>
> [2.569513] [drm] Found UVD firmware ENC: 1.2 DEC: .43 Family ID: 19
> [2.569538] [drm] PSP loading UVD firmware
> [2.570
On Wed, 8 Apr 2020 13:59:00 +0200
>
> vm_map_ram can keep mappings around after the vm_unmap_ram. Using that
> with non-PAGE_KERNEL mappings can lead to all kinds of aliasing issues.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/staging/android/ion/ion_heap.c | 4 ++--
> 1 file chang
On Fri, 06 Mar 2020 21:41:13 -0800
> syzbot found the following crash on:
>
> HEAD commit:63623fd4 Merge tag 'for-linus' of git://git.kernel.org/pub..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=11653ac3e0
> kernel config: https://syzkaller.app
On Thu, 20 Feb 2020 13:27:15 +0100 Thomas Hellstrom wrote:
> +
> +static vm_fault_t ttm_bo_vm_huge_fault(struct vm_fault *vmf,
> +enum page_entry_size pe_size)
> +{
> + struct vm_area_struct *vma = vmf->vma;
> + pgprot_t prot;
> + struct ttm_buffer_
On Sat, 1 Feb 2020 09:17:57 +0300 Dan Carpenter wrote:
> On Sat, Feb 01, 2020 at 12:32:09PM +0800, Hillf Danton wrote:
> >
> > Release obj in error path.
> >
> > --- a/drivers/gpu/drm/vgem/vgem_drv.c
> > +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> &
Fri, 31 Jan 2020 14:28:10 -0800 (PST)
> syzbot found the following crash on:
>
> HEAD commit:39bed42d Merge tag 'for-linus-hmm' of git://git.kernel.org..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=179465bee0
> kernel config: https://syzkaller.
On Sun, 15 Dec 2019 12:35:09 -0800
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:07c4b9e9 Merge tag 'scsi-fixes' of git://git.kernel.org/pu..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=14b61f41e0
> kernel config: https://s
On Sat, 07 Dec 2019 02:05:08 -0800
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:7ada90eb Merge tag 'drm-next-2019-12-06' of git://anongit...
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=16997c82e0
> kernel config: https://sy
On Thu, 3 Oct 2019 09:45:55 +0300 Jaak Ristioja wrote:
> On 30.09.19 16:29, Frediano Ziglio wrote:
> > Why didn't you update bug at
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1813620?
> > I know it can seem tedious but would help tracking it.
>
> I suppose the lack on centralized
On Mon, 30 Sep 2019 11:17:45 +0200 Neil Armstrong wrote:
>
> Did a new run from 5.3:
>
> [ 35.971972] Call trace:
> [ 35.974391] drm_sched_increase_karma+0x5c/0xf0
> 10667f3810667F94
> drivers/gpu/drm/scheduler/sched_main.c
On Fri, 6 Sep 2019 18:47:09 + John Stultz wrote:
>
> +static int system_heap_allocate(struct dma_heap *heap,
> + unsigned long len,
> + unsigned long fd_flags,
> + unsigned long heap_flags)
> +{
> + struc
On Fri, 6 Sep 2019 18:47:09 + John Stultz wrote:
>
> + cma_pages = cma_alloc(cma_heap->cma, nr_pages, align, false);
> + if (!cma_pages)
> + goto free_buf;
> +
> + if (PageHighMem(cma_pages)) {
> + unsigned long nr_clear_pages = nr_pages;
> + s
On Fri, 6 Sep 2019 18:47:08 + John Stultz wrote:
> +/**
> + * dma_heap_get_data() - get per-heap driver data
> + * @heap: DMA-Heap to retrieve private data for
> + *
> + * Returns:
> + * The per-heap data for the heap.
> + */
> +void *dma_heap_get_data(struct dma_heap *heap);
> +
It will hel
On Fri, 13 Sep 2019 11:32:06 +0200
>
> The mm patch page walk interface has been reworked to be similar to the
> reworked page-walk code (mm/pagewalk.c). There have been two other solutions
> to consider:
> 1) Using the page-walk code. That is currently not possible since it requires
> the mmap-s
On Fri, 13 Sep 2019 11:32:09 +0200
>
> err = ttm_mem_io_lock(man, true);
> - if (unlikely(err != 0)) {
> - ret = VM_FAULT_NOPAGE;
> - goto out_unlock;
> - }
> + if (unlikely(err != 0))
> + return VM_FAULT_NOPAGE;
> err = ttm_mem_io_reser
On Mon, 9 Sep 2019 from Gerd Hoffmann
>
> Hmm, I think the patch is wrong.
Hmm...it should have added change only in the error path, leaving locks
for drivers to release if job is done with no error returned.
> As far I know it is the qxl drivers's
> job to call ttm_eu_backoff_reservation().
L
Hi,
On Mon, 9 Sep 2019 from Gerd Hoffmann
>
> Hmm, I think the patch is wrong. As far I know it is the qxl drivers's
> job to call ttm_eu_backoff_reservation(). Doing that automatically in
> ttm will most likely break other ttm users.
>
Perhaps.
>So I guess the call is missing in the qxl drive
>From Frediano Ziglio
>
> Where does it came this patch?
My fingers tapping the keyboard.
> Is it already somewhere?
No idea yet.
> Is it supposed to fix this issue?
It may do nothing else as far as I can tell.
> Does it affect some other card beside QXL?
Perhaps.
On Tue, 6 Aug 2019 21:00:10 +0300 From: Jaak Ristioja
> Hello!
>
> I'm writing to report a crash in the QXL / DRM code in the Linux kernel.
> I originally filed the issue on LaunchPad and more details can be found
> there, although I doubt whether these details are useful.
>
> https://bugs.
On Tue, 3 Sep 2019 11:48:12 +0500 From: Mikhail Gavrilov
> On Fri, 30 Aug 2019 at 08:30, Hillf Danton wrote:
> >
> > Add a warning to show if it makes sense in field: neither regression nor
> > problem will have been observed with the warning printed.
>
Daniel Vetter
>>
>> Now 11:01pm and "gnome shell stuck warning" not appear since 19:17. So
>> looks like issue happens only when computer blocked and monitor in
>> power save mode.
>
> I'd bet on runtime pm or some other power saving feature in amdgpu
> shutting the interrupt handling down before
On Fri, 30 Aug 2019 06:04:06 +0800 Mikhail Gavrilov wrote:
> On Sun, Aug 25, 2019 at 10:13:05PM +0800, Hillf Danton wrote:
> > Can we try to add the fallback timer manually?
> >
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/a
On Sun, 25 Aug 2019 04:28:01 -0700 Mikhail Gavrilov wrote:
> Hi folks,
> I left unblocked gnome-shell at noon, and when I returned at the
> evening I discovered than monitor not sleeping and show open gnome
> activity. At first, I thought that some application did not let fall
> asleep the system.
On Thu, 8 Aug 2019 13:32:06 +0800 Alex Deucher wrote:
>
> On Wed, Aug 7, 2019 at 11:49 PM Mikhail Gavrilov wrote:
> >
> > Unfortunately error "gnome-shell: page allocation failure: order:4,
> > mode:0x40cc0(GFP_KERNEL|__GFP_COMP),
> > nodemask=(null),cpuset=/,mems_allowed=0" still happens even wi
On Tue, 6 Aug 2019 01:15:01 +0800 Mikhail Gavrilov wrote:
>
> Unfortunately couldn't check this patch because, with the patch, the
> kernel did not compile.
> Here is compile error messages:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c: In function
> 'dc_create_state':
> drivers/gpu/drm/
Hello Thomas
On Wed, 12 Jun 2019 08:42:39 +0200 Thomas Hellstrom wrote:
> From: Thomas Hellstrom
>
> With the vmwgfx dirty tracking, the default TTM fault handler is not
> completely sufficient (vmwgfx need to modify the vma->vm_flags member,
> and also needs to restrict the number of prefaults
On Mon, 27 May 2019 18:56:20 +0800 Christian Koenig wrote:
> Thanks for the comments, but you are looking at a completely outdated
> patchset.
>
> If you are interested in the newest one please ping me and I'm going to CC you
> when I send out the next version.
>
Ping...
Thanks
Hillf
On Tue, 16 Apr 2019 20:38:35 +0200 Christian König wrote:
> @ -331,14 +282,19 @@ EXPORT_SYMBOL(drm_gem_map_dma_buf);
> * @sgt: scatterlist info of the buffer to unmap
> * @dir: direction of DMA transfer
> *
> - * Not implemented. The unmap is done at drm_gem_map_detach(). This can be
> - *
On Tue, 16 Apr 2019 20:38:32 +0200 Christian König wrote:
> @@ -688,9 +689,9 @@ struct sg_table *dma_buf_map_attachment(struct
> dma_buf_attachment *attach,
> if (attach->sgt)
> return attach->sgt;
>
> - sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
> -
On Tue, 16 Apr 2019 20:38:34 +0200 Christian König wrote:
> + /**
> + * @unpin_dma_buf:
> + *
> + * This is called by dma_buf_unpin and lets the exporter know that an
> + * importer doesn't need to the DMA-buf to stay were it is any more.
> + *
s/need to/need/ s/were/
Simply complain if the combined result of start_page and num_pages goes over
the pages bo has. Let me know if the added warning is too heavy a hammer.
Cc: Christian Koenig
Cc: Huang Rui
Cc: Junwei Zhang
Signed-off-by: Hillf Danton
---
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c 2019-04-02 09:27
On March 03, 2017 5:45 AM Laura Abbott wrote:
>
> +static struct sg_table *dup_sg_table(struct sg_table *table)
> +{
> + struct sg_table *new_table;
> + int ret, i;
> + struct scatterlist *sg, *new_sg;
> +
> + new_table = kzalloc(sizeof(*new_table), GFP_KERNEL);
> + if (!new_
On Wednesday, October 12, 2016 7:50 AM Ruchi Kandoi wrote:
> +/**
> + * struct ion_fd_data - metadata passed from userspace for a handle
s/fd/tag/ ?
> + * @handle: a handle
> + * @tag: a string describing the buffer
> + *
> + * For ION_IOC_TAG userspace populates the handle field with
> + * the
On Wed, Mar 13, 2013 at 11:44 PM, Borislav Petkov wrote:
> + dri-devel.
>
> On Wed, Mar 13, 2013 at 02:34:31PM +0100, Rolf Offermanns wrote:
>> Hi,
>>
>> I get a kernel oops / panic with a 3.9.0rc2+ kernel (git from 2h ago) on my
>> Sony
>> Vaio laptop. It happened with rc1, too.
>>
>> Unfortunat
On Wed, Mar 13, 2013 at 11:44 PM, Borislav Petkov wrote:
> + dri-devel.
>
> On Wed, Mar 13, 2013 at 02:34:31PM +0100, Rolf Offermanns wrote:
>> Hi,
>>
>> I get a kernel oops / panic with a 3.9.0rc2+ kernel (git from 2h ago) on my
>> Sony
>> Vaio laptop. It happened with rc1, too.
>>
>> Unfortunat
On Thu, Feb 16, 2012 at 8:01 PM, Daniel Vetter wrote:
> @@ -416,17 +417,20 @@ static inline int fault_in_pages_writeable(char __user
> *uaddr, int size)
> * Writing zeroes into userspace here is OK, because we know that if
> * the zero gets there, we'll be overwriting it.
>
On Thu, Feb 16, 2012 at 8:01 PM, Daniel Vetter
wrote:
> @@ -416,17 +417,20 @@ static inline int fault_in_pages_writeable(char __user
> *uaddr, int size)
> ? ? ? ? * Writing zeroes into userspace here is OK, because we know that if
> ? ? ? ? * the zero gets there, we'll be overwriting it.
> ? ? ?
commit ea4039a34c4c206d015d34a49d0b00868e37db1d upstream.
If we fail to prepare an anon_vma, the {new, old}_page should be released,
or they will leak.
Signed-off-by: Hillf Danton
Reviewed-by: Andrea Arcangeli
Cc: Hugh Dickins
Cc: Johannes Weiner
Signed-off-by: Andrew Morton
Signed-off-by
60 matches
Mail list logo
