. This is needed in
> order to properly wait for a vblank event in the generic drm code.
>
> See https://bugs.freedesktop.org/show_bug.cgi?id=74195
>
> Reported-by: Jan Janecek
> Signed-off-by: Ilia Mirkin
> Cc: stable at vger.kernel.org # 3.10+
> ---
>
> TBH, not su
On Thu, Apr 22, 2021 at 02:39:41PM +0200, Christian König wrote:
> Am 22.04.21 um 14:27 schrieb Jan Harkes:
> > Looks good to me.
> >
> > I'm also maintaining an out of tree coda module build that people sometimes
> > use, which has workarounds for differ
le to find it. Is this mmap_region change
expected to be backported to any lts kernels?
Jan
On April 21, 2021 9:20:11 AM EDT, "Christian König"
wrote:
>mmap_region() now calls fput() on the vma->vm_file.
>
>So we need to drop the extra reference on the coda file instead of
ot;ing
the dummy one.
Signed-off-by: Jan Beulich
--- a/drivers/gpu/drm/xen/Kconfig
+++ b/drivers/gpu/drm/xen/Kconfig
@@ -1,15 +1,11 @@
# SPDX-License-Identifier: GPL-2.0-only
config DRM_XEN
- bool "DRM Support for Xen guest OS"
- depends on XEN
- help
- Cho
declarations can be turned off using a cmdline
switch but that remains to be implemented in the libclc build system.
manually adding '-cl-no-stdinc' should work as a workaround.
Jan
On Thu, Mar 4, 2021 at 10:27 PM Dieter Nützel wrote:
> Hello Marek,
>
> can't compile anyt
hi,
sorry the option is actually -cl-no-stdinc. you can add it to
'target_compiler_options'.
I should have a patch ready soon(tm), but time is scarce.
Jan
On Sun, Mar 7, 2021 at 9:51 PM Dieter Nützel wrote:
> Hello Jan,
>
> I very much appreciate your advice.
>
One more update. without changing any cmake files the following cmdline
should work:
cmake ../llvm-project/libclc/
-DLLVM_CONFIG=/usr/local/llvm-git/bin/llvm-config
-DCMAKE_LLAsm_FLAGS=-cl-no-stdinc -DCMAKE_CLC_FLAGS=-cl-no-stdinc
Jan
On Wed, Mar 10, 2021 at 1:20 AM Jan Vesely wrote:
>
l/dependency/dept.c:241 kernel/dependency/dept.c:999
> kernel/dependency/dept.c:1043 kernel/dependency/dept.c:1843)
> [9.008389] ? _raw_spin_unlock_irqrestore
> (./arch/x86/include/asm/irqflags.h:45 ./arch/x86/include/asm/irqflags.h:80
> ./arch/x86/include/asm/irqflags.h:138 ./include/linux/spinlock_api_smp.h:151
> kernel/locking/spinlock.c:194)
> [9.008392] ? _raw_spin_unlock_irqrestore
> (./arch/x86/include/asm/preempt.h:103 ./include/linux/spinlock_api_smp.h:152
> kernel/locking/spinlock.c:194)
> [9.008394] ? try_to_del_timer_sync (kernel/time/timer.c:1239)
> [9.008396] kjournald2 (fs/jbd2/journal.c:214 (discriminator 3))
> [9.008398] ? prepare_to_wait_exclusive (kernel/sched/wait.c:431)
> [9.008400] ? commit_timeout (fs/jbd2/journal.c:173)
> [9.008402] kthread (kernel/kthread.c:377)
> [9.008404] ? kthread_complete_and_exit (kernel/kthread.c:332)
> [9.008407] ret_from_fork (arch/x86/entry/entry_64.S:301)
> [9.008410]
--
Jan Kara
SUSE Labs, CR
ased
on what the block is used for). Similarly how we e.g. annotate i_rwsem for
different inodes.
Honza
--
Jan Kara
SUSE Labs, CR
On Wed 23-02-22 09:35:34, Byungchul Park wrote:
> On Mon, Feb 21, 2022 at 08:02:04PM +0100, Jan Kara wrote:
> > On Thu 17-02-22 20:10:04, Byungchul Park wrote:
> > > [9.008161] ===
> > > [9.008163] DEPT: Circular d
On Thu 24-02-22 10:11:02, Byungchul Park wrote:
> On Wed, Feb 23, 2022 at 03:48:59PM +0100, Jan Kara wrote:
> > > KJOURNALD2(kthread) TASK1(ksys_write) TASK2(ksys_write)
> > >
> > > wait A
> > > --- stuck
> > >
On Mon 28-02-22 18:28:26, Byungchul Park wrote:
> On Thu, Feb 24, 2022 at 11:22:39AM +0100, Jan Kara wrote:
> > On Thu 24-02-22 10:11:02, Byungchul Park wrote:
> > > On Wed, Feb 23, 2022 at 03:48:59PM +0100, Jan Kara wrote:
> > > > > KJOURNALD2(kthread) TASK1(k
On Thu 03-03-22 10:00:33, Byungchul Park wrote:
> On Mon, Feb 28, 2022 at 11:14:44AM +0100, Jan Kara wrote:
> > On Mon 28-02-22 18:28:26, Byungchul Park wrote:
> > > case 1. Code with an actual circular dependency, but not deadlock.
> > >
> > >A circular
us_driver.
I'm wondering whether it wouldn't better be the other way around: The
(hopefully few) essential ones get flagged, thus also making it more
prominent during patch review that a flag gets added (and justification
provided), instead of having to spot the lack of a flag getting set.
Jan
roc_handler = proc_dointvec,
> },
> #endif
> -#ifdef CONFIG_INOTIFY_USER
> - {
> - .procname = "inotify",
> - .mode = 0555,
> - .child = inotify_table,
> - },
> -#endif
> -#ifdef CONFIG_FANOTIFY
> - {
> - .procname = "fanotify",
> - .mode = 0555,
> - .child = fanotify_table,
> - },
> -#endif
> #ifdef CONFIG_EPOLL
> {
> .procname = "epoll",
> --
> 2.33.0
>
--
Jan Kara
SUSE Labs, CR
sctl-subdir-register-sysctl-simplify.cocci PATH
Heh, nice example of using Coccinelle. The result looks good. Feel free to
add:
Reviewed-by: Jan Kara
Honza
>
> @c1@
> expression E1;
> identifier subdir, sysctls;
> @@
On 03.12.20 22:30, Alex Deucher wrote:
> On Tue, Sep 29, 2020 at 4:04 PM Alex Deucher wrote:
>>
>> On Tue, Sep 29, 2020 at 8:31 AM Jan Kiszka wrote:
>>>
>>> On 10.09.20 20:18, Deucher, Alexander wrote:
>>>> [AMD Public Use]
>>>>
>>&
).
>
> I will be posting a the extra patch as an RFC, but in the meantime
> i wanted to know what was the status for this.
>
> Jan, Christian does your previous ACK still holds for this ?
Yes, I still think the approach makes sense. Dan's concern about in tree
users is valid
impose.
And I also would like to help you providing testing to fix the errors.
Many thanks for your kind support.
--
Met vriendelijke groet,
*dr. Jan Vlietland*, namens
spin-off
Nederlands Instituut voor de Software Industrie
_j.vlietland@nisi.nl_| 06 – 20 411 834 | 030 – 268 53 98
efs using
put_page()) but I suppose it would be a high enough barrier for missed
conversions... Thoughts?
Honza
--
Jan Kara
SUSE Labs, CR
___
dri-devel mailing list
dri-devel@lists.freed
On Fri 02-08-19 07:24:43, Matthew Wilcox wrote:
> On Fri, Aug 02, 2019 at 02:41:46PM +0200, Jan Kara wrote:
> > On Fri 02-08-19 11:12:44, Michal Hocko wrote:
> > > On Thu 01-08-19 19:19:31, john.hubb...@gmail.com wrote:
> > > [...]
> > > > 2) Convert all of t
hy I started off with a proposal that avoids changing the
> names of put_user_page*() APIs). But OTOH, the amount of churn is proportional
> to the change in direction here, and it's really only 10 or 20 lines changed,
> in the end.
>
> So I'm open to changing to that naming. It would be nice to hear what others
> prefer, too...
FWIW I'd find unpin_user_page() also better than put_user_page() as a
counterpart to pin_user_pages().
Honza
--
Jan Kara
SUSE Labs, CR
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
cs, should call a
> get_user_pages()-like wrapper call that sets FOLL_PIN. These wrappers
> will:
> * Start with "pin_user_pages" instead of "get_user_pages". That
> makes it easy to find and audit the call sites.
> * Set FOLL_PIN
>
periments.
> Since then, Jérôme Glisse suggested the refactoring described above.
>
> Suggested-by: Jérôme Glisse
> Signed-off-by: Ira Weiny
> Signed-off-by: John Hubbard
Looks good to me. You can add:
Reviewed-by: Jan Kara
On Tue 12-11-19 20:26:50, John Hubbard wrote:
> An upcoming patch uses try_get_compound_head() more widely,
> so move it to the top of gup.c.
>
> Also fix a tiny spelling error and a checkpatch.pl warning.
>
> Signed-off-by: John Hubbard
Looks good. You can add:
Rev
ewed-by: Ira Weiny
> Cc: Kirill A. Shutemov
> Signed-off-by: John Hubbard
Looks good! You can add:
Reviewed-by: Jan Kara
Honza
> ---
> mm/gup.c | 28 ++--
> 1 file changed, 18 insertions(+
> + SetPageReferenced(head);
> +}
I don't find this last helper very useful. It seems to muddy water more
than necessary...
Other than that the cleanup looks nice to me.
Honza
--
Jan Kara
SUSE Labs, CR
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
is left to later
> patchsets. There is discussion about this in [1].
^^ missing this reference
in the changelog...
> This also changes a BUG_ON(), to a WARN_ON(), in follow_page_mask().
>
> Suggested-by: Jan Kara
> Suggested-by: Jé
user_pages() to pin_user_pages().
>
> Signed-off-by: John Hubbard
Looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/io_uring.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
ere usages which are transient.
^^^ when you touch this, please fix also the
second sentense. It doesn't quite make sense to me... I'd probably write
there "whose usages are transient" but maybe you can come up with something
even better.
Otherwise the patch looks good
surrounded
> by get_page()/put_page().
>
> Also, further simplify (slightly), by waiting until the the successful
> end of each routine, to increment *nr.
>
> Reviewed-by: Jérôme Glisse
> Cc: Jan Kara
> Cc: Ira Weiny
> Cc: Christoph Hellwig
> Cc: Aneesh
153640.gb...@lst.de
>
> Reviewed-by: Ira Weiny
> Signed-off-by: John Hubbard
Looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> drivers/platform/goldfish/goldfish_pipe.c | 17 +++-
> 1 file changed, 15 insertions(+), 13 deletions(-)
The patch looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
--
Jan Kara
SUSE Labs, CR
___
dri-devel mailing l
: Jérôme Glisse
> Reviewed-by: Ira Weiny
> Signed-off-by: John Hubbard
Looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> drivers/platform/goldfish/goldfish_pipe.c | 18 +-
> 1 file ch
ewed-by: Ira Weiny
> Signed-off-by: John Hubbard
Looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> drivers/infiniband/core/umem.c | 17 ++---
> 1 file changed, 6 insertions(+), 11 deletion
On Tue 10-12-19 18:53:13, John Hubbard wrote:
> 1. Convert from get_user_pages() to pin_user_pages().
>
> 2. As required by pin_user_pages(), release these pages via
> put_user_page().
>
> Cc: Jan Kara
> Signed-off-by: John Hubbard
The patch looks good to me. You can a
d get_user_pages() (LPC: Dec 12, 2018):
> https://lwn.net/Articles/774411/
> [3] The trouble with get_user_pages() (Apr 30, 2018):
> https://lwn.net/Articles/753027/
The patch looks mostly good to me now. Just a few smaller comments below.
> Suggested-by: Jan Kara
> Suggested-by
d get_user_pages() (LPC: Dec 12, 2018):
> https://lwn.net/Articles/774411/
> [3] The trouble with get_user_pages() (Apr 30, 2018):
> https://lwn.net/Articles/753027/
>
> Suggested-by: Jan Kara
> Suggested-by: Jérôme Glisse
> Cc: Kirill A. Shutemov
> Signed-off-by: J
d get_user_pages() (LPC: Dec 12, 2018):
> https://lwn.net/Articles/774411/
> [3] The trouble with get_user_pages() (Apr 30, 2018):
> https://lwn.net/Articles/753027/
>
> Suggested-by: Jan Kara
> Suggested-by: Jérôme Glisse
> Cc: Kirill A. Shutemov
> Signed-off-b
On Mon 16-12-19 14:18:59, John Hubbard wrote:
> On 12/16/19 4:53 AM, Jan Kara wrote:
> > With this fixed, the patch looks good to me so you can then add:
> >
> > Reviewed-by: Jan Kara
> >
> > Ho
er testing exposure and is
prepared for the next merge window.
Honza
--
Jan Kara
SUSE Labs, CR
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
st would work... And I don't think
making all GUP users huge page aware is realistic (effort-wise) or even
wanted (maintenance overhead in all those places).
I believe there might be also a different solution for this: For
transparent huge pages, we could find a space in '
ches.
>
>If that's too much trouble, then I'd have to fall back to submitting a few
>patches at a time and working my way up to the tracking patch...
It could also be that an ordinary page reference is dropped with 'unpin'
thus underflowing the page refcount...
Honza
--
Jan Kara
SUSE Labs, CR
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Friday 2020-02-28 08:59, Daniel Stone wrote:
>
>I believe that in January, we had $2082 of network cost (almost
>entirely egress; ingress is basically free) and $1750 of
>cloud-storage cost (almost all of which was download). That's based
>on 16TB of cloud-storage (CI artifacts, container image
surrounded
> by get_page()/put_page().
>
> Also, further simplify (slightly), by waiting until the the successful
> end of each routine, to increment *nr.
>
> Reviewed-by: Jérôme Glisse
> Cc: Jan Kara
> Cc: Ira Weiny
> Cc: Christoph Hellwig
> Cc: Aneesh Kumar K.V
'd add a helper grab_page(page,
flags) doing
if (flags & FOLL_GET)
get_page(page);
else if (flags & FOLL_PIN)
return try_pin_page(page);
return true;
Otherwise the patch looks good to me now.
igned-off-by: John Hubbard
Looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> Documentation/core-api/pin_user_pages.rst | 2 +-
> arch/powerpc/mm/book3s64/iommu_api.c| 6 +--
> drivers/gpu/drm/vi
ser_pages() (LPC: Dec 12, 2018):
> https://lwn.net/Articles/774411/
> [3] The trouble with get_user_pages() (Apr 30, 2018):
> https://lwn.net/Articles/753027/
>
> Suggested-by: Jan Kara
> Suggested-by: Jérôme Glisse
> Signed-off-by: Jo
them as we do now because
ideally in 4 weeks we should have them ready with all the reviews so that
they can be picked up and integrated into linux-next.
Honza
--
Jan Kara
SUSE Labs, CR
___
with), it would probably make sense to push also the
put_user_pages() -> unpin_user_pages() renaming so that that inconsistency
in naming does not exist in the released upstream kernel.
Honza
--
Jan Kara
SUSE Labs, CR
__
On Thu 21-11-19 18:54:02, John Hubbard wrote:
> On 11/21/19 1:54 AM, Jan Kara wrote:
> > On Thu 21-11-19 00:29:59, John Hubbard wrote:
> > > >
> > > > Otherwise this looks fine and might be a worthwhile cleanup to feed
> > > > Andrew
rty(page);
> + put_user_pages_dirty_lock(&mem->hpages[i], 1,
> + MM_IOMMU_TABLE_GROUP_PAGE_DIRTY);
And the dirtying condition is wrong here as well. Currently it is always
true.
Honza
--
Jan Kara
SUSE Labs, CR
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
ere we have reference on the inode it
> hangs off." [1]
>
> [1] https://lore.kernel.org/r/20190723153640.gb...@lst.de
>
> Cc: Jan Kara
> Signed-off-by: John Hubbard
> ---
> arch/powerpc/mm/book3s64/iommu_api.c | 12 +---
> 1 file changed, 5 insertions(+
t; avoid writing to the pages. So it appears to have been an oversight.
>
> Fix by allowing FOLL_FORCE to be set for get_user_pages_fast().
>
> Fixes: 817be129e6f2 ("mm: validate get_user_pages_fast flags")
> Cc: Christoph Hellwig
> Reviewed-by: Leon Romanovsky
>
before the video HW
stored data in the page) and the page then gets evicted from the page cache.
Honza
--
Jan Kara
SUSE Labs, CR
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
into the patch the uses
> the gup flags arguments.
You should probably implement this TODO? :)
Honza
>
> Reviewed-by: Jan Kara
> Reviewed-by: Jérôme Glisse
> Reviewed-by: Ira Weiny
> Cc: Kirill A. Shu
d get_user_pages() (LPC: Dec 12, 2018):
> https://lwn.net/Articles/774411/
> [3] The trouble with get_user_pages() (Apr 30, 2018):
> https://lwn.net/Articles/753027/
>
> Suggested-by: Jan Kara
> Suggested-by: Jérôme Glisse
> Signed-off-by: John Hubbard
Looks nice,
On Fri 02-08-19 12:14:09, John Hubbard wrote:
> On 8/2/19 7:52 AM, Jan Kara wrote:
> > On Fri 02-08-19 07:24:43, Matthew Wilcox wrote:
> > > On Fri, Aug 02, 2019 at 02:41:46PM +0200, Jan Kara wrote:
> > > > On Fri 02-08-19 11:12:44, Michal Hocko wrote:
> > >
like to say that the "imbalance" of get_user_pages()
> and put_page() bothers me from a purist standpoint... However, since this
> discussion cropped up I went ahead and ported my work to Linus' current master
> (5.3-rc3+) and in doing so I only had to steal a bit of Johns
m now
> touching mm, procfs, rdma, ext4, and xfs.
MM tree would be one candidate for routing but there are other options that
would make sense as well - Dan's tree, VFS tree, or even I can pickup the
patches to my tree if needed. But let's worry about the routing after
sumably we didn't want to use modulo here because EXT4_MMP_SEQ_MAX
is rather big and so the resulting 'new_seq' would be seriously
non-uniform.
Honza
--
Jan Kara
SUSE Labs, CR
d-by: Kees Cook
> Reviewed-by: KP Singh
> Reviewed-by: Christoph Böhmwalder
> Signed-off-by: Jason A. Donenfeld
Feel free to add:
Reviewed-by: Jan Kara
for the ext2, ext4, and lib/sbitmap.c bits.
Honza
--
Jan Kara
SUSE Labs, CR
eal function.
>
> Reviewed-by: Kees Cook
> Signed-off-by: Jason A. Donenfeld
Looks good. Feel free to add:
Reviewed-by: Jan Kara
for the ext4 bits.
Honza
--
Jan Kara
SUSE Labs, CR
;
> }
Shouldn't this then be xen_pv_domain() that you use here, and - if you
really want IS_ENABLED() in addition - CONFIG_XEN_PV?
Jan
On 18.10.2022 13:02, Christoph Hellwig wrote:
> On Tue, Oct 18, 2022 at 10:57:37AM +0200, Jan Beulich wrote:
>> Shouldn't this then be xen_pv_domain() that you use here, and - if you
>> really want IS_ENABLED() in addition - CONFIG_XEN_PV?
>
> I'll need help from pe
no way (yet) to drive the IOMMU, so how can it get
away without resorting to swiotlb in certain cases (like I/O to an
address-restricted device)?
Jan
On 15.03.2023 01:52, Stefano Stabellini wrote:
> On Mon, 13 Mar 2023, Jan Beulich wrote:
>> On 12.03.2023 13:01, Huang Rui wrote:
>>> Xen PVH is the paravirtualized mode and takes advantage of hardware
>>> virtualization support when possible. It will using the hardwar
On 15.03.2023 05:14, Huang Rui wrote:
> On Wed, Mar 15, 2023 at 08:52:30AM +0800, Stefano Stabellini wrote:
>> On Mon, 13 Mar 2023, Jan Beulich wrote:
>>> On 12.03.2023 13:01, Huang Rui wrote:
>>>> Xen PVH is the paravirtualized mode and takes advantage of hardware
&g
On 16.03.2023 00:25, Stefano Stabellini wrote:
> On Wed, 15 Mar 2023, Jan Beulich wrote:
>> On 15.03.2023 01:52, Stefano Stabellini wrote:
>>> On Mon, 13 Mar 2023, Jan Beulich wrote:
>>>> On 12.03.2023 13:01, Huang Rui wrote:
>>>>> Xen PVH is th
On 16.03.2023 14:53, Alex Deucher wrote:
> On Thu, Mar 16, 2023 at 9:48 AM Juergen Gross wrote:
>>
>> On 16.03.23 14:45, Alex Deucher wrote:
>>> On Thu, Mar 16, 2023 at 3:50 AM Jan Beulich wrote:
>>>>
>>>> On 16.03.2023 00:25, Stefano Stabelli
> - but WITHOUT ANY WARRANTY; without even the implied warranty of
> - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> - Library General Public License for more details.
> -
> - You should have received a copy of the GNU Library General Public
> - License along with the GNU C Library; see the file COPYING.LIB. If not,
> - write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
> - Boston, MA 02111-1307, USA. */
> +/* SPDX-License-Identifier: GPL-2.0-only */
>
> /*
> * dgb 10/02/98: ripped this from glibc source to help convert timestamps
> diff --git a/fs/udf/unicode.c b/fs/udf/unicode.c
> index 622569007b530b..5d6b66e15fcded 100644
> --- a/fs/udf/unicode.c
> +++ b/fs/udf/unicode.c
> @@ -1,3 +1,4 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> /*
> * unicode.c
> *
> @@ -11,11 +12,6 @@
> * UTF-8 is explained in the IETF RFC .
> * ftp://ftp.internic.net/rfc/rfc.txt
> *
> - * COPYRIGHT
> - * This file is distributed under the terms of the GNU General Public
> - * License (GPL). Copies of the GPL can be obtained from:
> - * ftp://prep.ai.mit.edu/pub/gnu/GPL
> - * Each contributing author retains all rights to their own work.
> */
>
> #include "udfdecl.h"
> --
> An old man doll... just what I always wanted! - Clara
>
--
Jan Kara
SUSE Labs, CR
Xueshi Hu
Yeah, looks sensible to me but for some callbacks we are oscilating between
all users having to provide some callback and providing some default
behavior for NULL callback. I don't have a strong opinion either way so
feel free to add:
Reviewed-by: Jan Kara
But I guess let's
he mm subsystem.
>
> Signed-off-by: Lorenzo Stoakes
Looks good. You can add:
Reviewed-by: Jan Kara
Honza
--
Jan Kara
SUSE Labs, CR
> mm subsystem.
>
> Signed-off-by: Lorenzo Stoakes
The patch looks good. You can add:
Reviewed-by: Jan Kara
Honza
--
Jan Kara
SUSE Labs, CR
s second but I don't care that much. But it definitely should be
consistent...
Honza
--
Jan Kara
SUSE Labs, CR
iour
> (and
> hence bugs) within the mm subsystem.
>
> Signed-off-by: Lorenzo Stoakes
Looks good. You can add:
Reviewed-by: Jan Kara
Honza
--
Jan Kara
SUSE Labs, CR
r
> (and
> hence bugs) within the mm subsystem.
>
> Signed-off-by: Lorenzo Stoakes
After our discussion the patch looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
--
Jan Kara
SUSE Labs, CR
r (and hence
> bugs) within the mm subsystem.
>
> Signed-off-by: Lorenzo Stoakes
Looks good. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> drivers/gpu/drm/exynos/exynos_drm_g2d.c| 3 ++-
> drivers/media/pla
addr, buf, len, write);
> + return __access_remote_vm(NULL, mm, addr, buf, len,
> + write ? FOLL_WRITE : 0);
> }
>
> /*
> @@ -1871,7 +1873,8 @@ int access_process_vm(struct task_struct *tsk, unsigned
> long addr, void *buf, in
> if (!mm)
> return 0;
>
> - len = __access_remote_vm(tsk, mm, addr, buf, len, write);
> + len = __access_remote_vm(tsk, mm, addr, buf, len,
> + write ? FOLL_WRITE : 0);
>
> mmput(mm);
> return len;
> --
> 2.10.0
>
--
Jan Kara
SUSE Labs, CR
hence
> bugs) within the mm subsystem.
>
> Signed-off-by: Lorenzo Stoakes
The patch looks good. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> arch/cris/arch-v32/drivers/cryptocop.c |
On Tue 18-10-16 14:56:09, Lorenzo Stoakes wrote:
> On Tue, Oct 18, 2016 at 02:54:25PM +0200, Jan Kara wrote:
> > > @@ -1282,7 +1282,7 @@ long get_user_pages(unsigned long start, unsigned
> > > long nr_pages,
> > > int write,
r
> (and
> hence bugs) within the mm subsystem.
>
> Signed-off-by: Lorenzo Stoakes
Looks good. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gem.c | 7 +--
> drivers/g
aging-next branch.
The used hardware is:
HP T630 Thin Client
CPU: AMD Embedded G-Series GX-420GI Radeon R7E
GPU: Advanced Micro Devices, Inc. [AMD/ATI] Carrizo (rev 88)
Regards,
Jan Burgmeier
___
dri-devel mailing list
dri-devel@lists.freedesktop
Signed-off-by: Jan Burgmeier
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 99424cb8020b..583d22974e14 100644
--- a/drivers/gpu/drm/amd/amdgpu
db138b9ba12a0de5d6140832c0679c2418e3e7e0
Author: Michel Dänzer
Date: Thu Jan 21 18:08:49 2016 +0900
radeon: Pass radeon_bo_open flags to the DRM_RADEON_GEM_CREATE
ioctl
Not doing so makes it impossible for radeon_bo_open callers to set
any
RADEON_GEM_* flags for the newly created BO.
Reviewed-by
Hi,
the error only occurs with wmv, h264 works.
I created a bug report:
https://bugs.freedesktop.org/show_bug.cgi?id=100510
Regards,
Jan
On Fri, 2017-03-31 at 09:13 +0200, Christian König wrote:
> Hi Jan,
>
> very interesting. Sounds like we somehow mess up the buffer placement
>
lized
> environments"
I may have overlooked a different fix dealing with the problem; if
so, I'd appreciate that fix being pointed out.
Thanks, Jan
> Signed-off-by: Jan Beulich
> ---
> drivers/gpu/drm/radeon/radeon_device.c |3 ++-
> 1 file changed, 2 insertions(+
>>> On 04.11.16 at 15:32, wrote:
> On Fri, Nov 4, 2016 at 6:44 AM, Jan Beulich wrote:
>>>>> On 13.09.16 at 17:54, wrote:
>>> While a hard hang in atom_asic_init() likely points at a deeper problem
>>> in the driver, restore the capability to boot a X
This test cements behaviour set in
3b2ee2b5bfc0d68525fee936e51297a9b6c629f1 drmSL: Fix neighbor lookup (2015-02-27)
Signed-off-by: Jan Vesely
---
tests/drmsl.c | 28
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/tests/drmsl.c b/tests/drmsl.c
index
further investigation, lspci for the
offending device says:
ATI Technologies Inc RS480 [Radeon Xpress 200G Series] [1002:5954]
Fixes: 05082b8bbd "drm/radeon: fix asic initialization for virtualized
environments"
Signed-off-by: Jan Beulich
---
drivers/gpu/drm/radeon/radeon_device.c |
familiar
with the design than just reading the code (like I did)
regards,
jan
>
> Since the drmSetServerInfo is seldom used, maybe we can just do the 'int'
> cast at this moment. I will send v2 for this.
>
> Regards,
> Jammy
>
> -Original Messa
Add a quirk for the Oculus Rift S OVR0012 display so
it shows up as a non-desktop display.
Signed-off-by: Jan Schmidt
---
drivers/gpu/drm/drm_edid.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 116451101426
On 10.09.20 20:18, Deucher, Alexander wrote:
> [AMD Public Use]
>
>
>
>> -Original Message-
>> From: amd-gfx On Behalf Of
>> Daniel Vetter
>> Sent: Monday, September 7, 2020 3:15 AM
>> To: Jan Kiszka ; amd-gfx list > g...@lists.freedesktop.or
ivers are supposed to
work.
Anyway, if you can make this go away, sure go ahead :)
Honza
--
Jan Kara
SUSE Labs, CR
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
27;d exit the loop (to out: label) anyway due to the loop termination
condition and why not return the frames we already have? Furthermore
find_vma_intersection() can return NULL which would oops in your check
then. What am I missing?
Honza
>
f 1f 44 00 00 48 89
f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 8b 0d 07 6f 0c 00 f7 d8 64 89 01 48
[ 14.033842] RSP: 002b:7ffd03534438 EFLAGS: 0246 ORIG_RAX:
0139
[ 1
On Tuesday 2020-05-19 22:36, Sasha Levin wrote:
>
>> - Why DX12 on linux? Looking at this feels like classic divide and
>
> There is a single usecase for this: WSL2 developer who wants to run
> machine learning on his GPU. The developer is working on his laptop,
> which is running Windows and tha
On Fri 08-05-15 15:49:22, Mel Gorman wrote:
> On Wed, May 06, 2015 at 09:28:09AM +0200, Jan Kara wrote:
> > Provide new function get_vaddr_frames(). This function maps virtual
> > addresses from given start and fills given array with page frame numbers of
> > the correspo
r 30 08:50:29 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler
[i915]] *ERROR* PCH transcoder A FIFO underrun
Jan
Hello,
I'm sending the fifth version of my patch series to abstract vma handling
from the various media drivers. The patches got some review from mm people and
testing from device driver guys so unless someone objects, patches will be
queued in media tree for the next merge window.
After this p
1 - 100 of 361 matches
Mail list logo
