On Fri, 25 Oct 2024 at 12:36, Helge Deller wrote:
>
> Do you want me to send a revert for this specific patch?
No, it's in now, more churn this time around just makes it worse. I
just don't want to see these kinds of non-fixes in the future.
Linus
On Fri, 25 Oct 2024 at 09:04, Helge Deller wrote:
>
> It's mostly about build warning fixes with cornercase CONFIG settings
> and one big patch which removes the now unused da8xx fbdev driver.
So I pulled this, but only later noticed that some of the Kconfig
"fixes" are anything but.
At least co
On Thu, 19 Sept 2024 at 09:48, Dave Airlie wrote:
>
> There are some minor conflicts with your tree but none seemed too
> difficult to solve, let me know if there is any problems on your end.
Christ. One of them is due to you guys being horrible at merging.
Your tree had
drm/xe/gt: Remove d
On Mon, 2 Sept 2024 at 03:34, Christian König wrote:
>
> Am 02.09.24 um 11:32 schrieb Thomas Hellström:
> >
> > The remap_pfn_range was last tried, at least in the context of the i915
> > driver IIRC by Christoph Hellwig but had to be ripped out since it
> > requires the mmap_lock in write mode. H
On Fri, 30 Aug 2024 at 14:08, Dave Airlie wrote:
>
> The TTM revert is due to some stuttering graphical apps probably due
> to longer stalls while prefaulting.
Yeah, trying to pre-fault a PMD worth of pages in one go is just crazy talk.
Now, if it was PMD-aligned and you faulted in a single PMD,
On Sat, 17 Aug 2024 at 01:48, Alejandro Colomar wrote:
>
> I would compact the above to:
>
> len = strlen(s);
> buf = kmalloc_track_caller(len + 1, gfp);
> if (buf)
> strcpy(mempcpy(buf, s, len), "");
No, we're not doing this kind of horror.
If _FORTIFY_SO
On Mon, 5 Aug 2024 at 20:01, Yafang Shao wrote:
>
> One concern about removing the BUILD_BUG_ON() is that if we extend
> TASK_COMM_LEN to a larger size, such as 24, the caller with a
> hardcoded 16-byte buffer may overflow.
No, not at all. Because get_task_comm() - and the replacements - would
ne
On Sun, 4 Aug 2024 at 00:56, Yafang Shao wrote:
>
> There is a BUILD_BUG_ON() inside get_task_comm(), so when you use
> get_task_comm(), it implies that the BUILD_BUG_ON() is necessary.
Let's just remove that silly BUILD_BUG_ON(). I don't think it adds any
value, and honestly, it really only make
On Wed, 19 Jun 2024 at 03:44, Pavel Machek wrote:
>
> Ok, so machine is ready to be thrown out of window, again. Trying to
> play 29C3 video should not make machine completely unusable ... as in
> keyboard looses keystrokes in terminal.
Well, that at least sounds like you can bisect it with a ver
On Fri, 14 Jun 2024 at 09:21, Linus Torvalds
wrote:
>
> Let's bring in the actual gpu people.. Dave/Jani/others - does any of
> this sound familiar? Pavel says things have gotten much slower in
> 6.10: "something was very wrong with the performance, likely to do
> with g
On Fri, 14 Jun 2024 at 02:02, Pavel Machek wrote:
>
> If I can get at least basic metric on the gpu (%idle? which process
> use how much time?), it might be feasible. Is there tool similar for
> top?
Let's bring in the actual gpu people.. Dave/Jani/others - does any of
this sound familiar? Pavel
On Thu, 13 Jun 2024 at 14:14, Andrew Morton wrote:
>
> The concept sounds a little strange. If some code takes a copy of a
> string while some other code is altering it, yes, the result will be a
> mess. This is why get_task_comm() exists, and why it uses locking.
The thing is, get_task_comm()
On Tue, 4 Jun 2024 at 11:25, Rodrigo Vivi wrote:
>
> (I believe that the new _match_string(str1, size, str2) deserves a better
> name,
> but since I'm bad with naming stuff, I don't have any good suggestion)
I hated the enormous cc list, so I didn't reply to all. But clearly
everybody else is ju
On Fri, 17 May 2024 at 06:55, Alex Deucher wrote:
>
> Can you try this patch?
> https://patchwork.freedesktop.org/patch/594539/
Ack. This seems to fix it for me - unless the problem is random and
only happens sometimes, and I've just been *very* unlucky until now.
Linus
On Thu, 16 May 2024 at 18:08, Dave Airlie wrote:
>
> Linus, do you see it a boot straight away?
Ok, back at that computer now, and yes, I see those messages right
away. In fact, they seem to happen before gnome even starts up, ie I
see those messages long before the first messages from gnome-sess
On Wed, 15 May 2024 at 19:54, Dave Airlie wrote:
>
> Here is the buddy allocator fix I picked up from the list, please apply.
So I removed my reverts, and am running a kernel that includes the
merge 972a2543e3dd ("Merge tag 'drm-next-2024-05-16' of
https://gitlab.freedesktop.org/drm/kernel";) but
On Wed, 15 May 2024 at 16:51, Dave Airlie wrote:
>
> > Let's see if the machine ends up being stable now. It took several
> > hours for the "scary messages" state to turn into the "hung machine"
> > state, so they *could* have been independent issues, but it seems a
> > bit unlikely.
>
> This worr
On Wed, 15 May 2024 at 16:17, Dave Airlie wrote:
>
> It's also possible it's just that hey there's a few others in the tree
>
> KVM_WERROR not tied to it
> PPC_WERROR (why does CXL uses this?)
Yeah, that should be fixed too, but at least KVM_WERROR predates the
whole-kernel WERROR.
And PPC_WERRO
On Wed, 15 May 2024 at 15:45, Dave Airlie wrote:
>
> The drm subsystem enables more warnings than the kernel default, so
> this config option is disabled by default.
Irrelevant.
If the *main* CONFIG_WERROR is on, then it does NOT MATTER if somebody
sets CONFIG_DRM_WERROR or n
On Tue, 14 May 2024 at 23:21, Dave Airlie wrote:
>
> This is the main pull request for the drm subsystems for 6.10.
.. and now that I look more at this pull request, I find other things wrong.
Why is the DRM code asking if I want to enable -Werror? I have Werror
enabled *already*.
I hate stupid
On Wed, 15 May 2024 at 13:24, Linus Torvalds
wrote:
>
> I have to revert both
>
> a68c7eaa7a8f ("drm/amdgpu: Enable clear page functionality")
> e362b7c8f8c7 ("drm/amdgpu: Modify the contiguous flags behaviour")
>
> to make things build cleanly.
On Wed, 15 May 2024 at 13:21, Linus Torvalds
wrote:
>
> I guess I'll try to revert the later commit that enables it for amdgpu
> (commit a68c7eaa7a8f) and see if it at least makes the horrendous
> messages go away.
I have to revert both
a68c7eaa7a8f ("drm/amd
On Wed, 15 May 2024 at 13:06, Linus Torvalds
wrote:
>
> Hmm. There's something seriously wrong with amdgpu.
>
> I'm getting a ton of__force_merge warnings:
>
> WARNING: CPU: 0 PID: 1069 at drivers/gpu/drm/drm_buddy.c:199
> __force_merge+0x14f/0x180 [drm_buddy]
On Tue, 14 May 2024 at 23:21, Dave Airlie wrote:
>
> In drivers the main thing is a new driver for ARM Mali firmware based
> GPUs, otherwise there are a lot of changes to amdgpu/xe/i915/msm and
> scattered changes to everything else.
Hmm. There's something seriously wrong with amdgpu.
I'm gettin
On Thu, 9 May 2024 at 04:39, Christian Brauner wrote:
>
> Not worth it without someone explaining in detail why imho. First pass
> should be to try and replace kcmp() in scenarios where it's obviously
> not needed or overkill.
Ack.
> I've added a CLASS(fd_raw) in a preliminary patch since we'll
On Wed, 8 May 2024 at 09:19, Linus Torvalds
wrote:
>
> So since we already have two versions of F_DUPFD (the other being
> F_DUPFD_CLOEXEC) I decided that the best thing to do is to just extend
> on that existing naming pattern, and called it F_DUPFD_QUERY instead.
>
> I'm
On Tue, 7 May 2024 at 12:07, Linus Torvalds
wrote:
>
> That example thing shows that we shouldn't make it a FISAME ioctl - we
> should make it a fcntl() instead, and it would just be a companion to
> F_DUPFD.
>
> Doesn't that strike everybody as a *much* cleaner interf
On Tue, 7 May 2024 at 11:04, Daniel Vetter wrote:
>
> On Tue, May 07, 2024 at 09:46:31AM -0700, Linus Torvalds wrote:
>
> > I'd be perfectly ok with adding a generic "FISAME" VFS level ioctl
> > too, if this is possibly a more common thing. and not just DRM w
On Tue, 7 May 2024 at 04:03, Daniel Vetter wrote:
>
> It's really annoying that on some distros/builds we don't have that, and
> for gpu driver stack reasons we _really_ need to know whether a fd is the
> same as another, due to some messy uniqueness requirements on buffer
> objects various driver
On Mon, 6 May 2024 at 10:46, Stefan Metzmacher wrote:
>
> I think it's a very important detail that epoll does not take
> real references. Otherwise an application level 'close()' on a socket
> would not trigger a tcp disconnect, when an fd is still registered with
> epoll.
Yes, exactly.
epoll()
On Sun, 5 May 2024 at 13:30, Al Viro wrote:
>
> 0. special-cased ->f_count rule for ->poll() is a wart and it's
> better to get rid of it.
>
> 1. fs/eventpoll.c is a steaming pile of shit and I'd be glad to see
> git rm taken to it. Short of that, by all means, let's grab reference
> in
On Sun, 5 May 2024 at 13:02, David Laight wrote:
>
> How much is the extra pair of atomics going to hurt performance?
> IIRC a lot of work was done to (try to) make epoll lockless.
If this makes people walk away from epoll, that would be absolutely
*lovely*. Maybe they'd start using io_uring inst
On Sun, 5 May 2024 at 12:46, Al Viro wrote:
>
> I've no problem with having epoll grab a reference, but if we make that
> a universal requirement ->poll() instances can rely upon,
Al, we're note "making that a requirement".
It always has been.
Otgherwise, the docs should have shouted out DAMN L
om/
Reported-by: syzbot+045b454ab35fd82a3...@syzkaller.appspotmail.com
Reviewed-by: Jens Axboe
Signed-off-by: Linus Torvalds
---
Changes since v1:
- add Link, Reported-by, and Jens' reviewed-by. And sign off on it
because it looks fine to me and we have some testing now.
- move epi_fget()
On Sun, 5 May 2024 at 03:50, Christian Brauner wrote:
>
> And I agree with you that for some instances it's valid to take another
> reference to a file from f_op->poll() but then they need to use
> get_file_active() imho and simply handle the case where f_count is zero.
I think this is
(a) prac
On Sat, 4 May 2024 at 08:32, Linus Torvalds
wrote:
>
> Lookie here, the fundamental issue is that epoll can call '->poll()'
> on a file descriptor that is being closed concurrently.
Thinking some more about this, and replying to myself...
Actually, I wonder if we coul
On Sat, 4 May 2024 at 08:40, Linus Torvalds
wrote:
>
> And maybe it's even *only* dma-buf that does that fget() in its
> ->poll() function. Even *then* it's not a dma-buf.c bug.
They all do in the sense that they do
poll_wait
-> __pollwait
-> get_file (*
On Sat, 4 May 2024 at 08:32, Linus Torvalds
wrote:
>
> Now, during this TOTALLY INNOCENT sock_poll(), in another thread, the
> file closing completes, eventpoll_release() finishes [..]
Actually, Al is right that ep_item_poll() should be holding the
ep->mtx, so event
On Sat, 4 May 2024 at 02:37, Christian Brauner wrote:
>
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -244,13 +244,18 @@ static __poll_t dma_buf_poll(struct file *file,
> poll_table *poll)
> if (!dmabuf || !dmabuf->resv)
> return EPOLLERR;
>
> +
On Fri, 3 May 2024 at 16:39, Al Viro wrote:
>
> *IF* those files are on purely internal filesystem, that's probably
> OK; do that with something on something mountable (char device,
> sysfs file, etc.) and you have a problem with filesystem staying
> busy.
Yeah, I agree, it's a bit annoying in ge
On Fri, 3 May 2024 at 16:23, Kees Cook wrote:
>
> static bool __must_check get_dma_buf_unless_doomed(struct dma_buf *dmabuf)
> {
> return atomic_long_inc_not_zero(&dmabuf->file->f_count) != 0L;
> }
>
> If we end up adding epi_fget(), we'll have 2 cases of using
> "atomic_long_inc_not_zero"
On Fri, 3 May 2024 at 15:07, Al Viro wrote:
>
> Suppose your program calls select() on a pipe and dmabuf, sees data to be read
> from pipe, reads it, closes both pipe and dmabuf and exits.
>
> Would you expect that dmabuf file would stick around for hell knows how long
> after that? I would certa
On Fri, 3 May 2024 at 14:45, Al Viro wrote:
>
> How do you get through eventpoll_release_file() while someone
> has entered ep_item_poll()?
Doesn't matter.
Look, it's enough that the file count has gone down to zero. You may
not even have gotten to eventpoll_release_file() yet - the important
pa
On Fri, 3 May 2024 at 14:36, Al Viro wrote:
>
> ... the last part is no-go - poll_wait() must be able to grab a reference
> (well, the callback in it must)
Yeah. I really think that *poll* itself is doing everything right. It
knows that it's called with a file pointer with a reference, and it
add
On Fri, 3 May 2024 at 14:24, Al Viro wrote:
>
> Can we get to ep_item_poll(epi, ...) after eventpoll_release_file()
> got past __ep_remove()? Because if we can, we have a worse problem -
> epi freed under us.
Look at the hack in __ep_remove(): if it is concurrent with
eventpoll_release_file(), i
On Fri, 3 May 2024 at 14:11, Al Viro wrote:
>
> What we need is
> * promise that ep_item_poll() won't happen after
> eventpoll_release_file().
> AFAICS, we do have that.
> * ->poll() not playing silly buggers.
No. That is not enough at all.
Because even with perfectly normal "->
epoll is a mess, and does various invalid things in the name of
performance.
Let's try to rein it in a bit. Something like this, perhaps?
Not-yet-signed-off-by: Linus Torvalds
---
This is entirely untested, thus the "Not-yet-signed-off-by". But I
think this may be kind of
On Tue, 12 Mar 2024 at 21:07, Dave Airlie wrote:
>
> I've done a trial merge into your tree from a few hours ago, there
> are definitely some slighty messy conflicts, I've pushed a sample
> branch here:
I appreciate your sample merges since I like verifying my end result,
but I think your merge i
On Fri, 1 Mar 2024 at 02:27, Nikolai Kondrashov wrote:
>
> I agree, it's hard to imagine even a simple majority agreeing on how GitLab CI
> should be done. Still, we would like to help people, who are interested in
> this kind of thing, to set it up. How about we reframe this contribution as a
> s
On Thu, 29 Feb 2024 at 01:23, Nikolai Kondrashov wrote:
>
> However, I think a better approach would be *not* to add the .gitlab-ci.yaml
> file in the root of the source tree, but instead change the very same repo
> setting to point to a particular entry YAML, *inside* the repo (somewhere
> under
On Sun, 25 Feb 2024 at 08:53, David Laight wrote:
>
> The expansions of min() and max() contain statement expressions so are
> not valid for static intialisers.
> min_const() and max_const() are expressions so can be used for static
> initialisers.
I hate the name.
Naming shouldn't be about an i
On Thu, 22 Feb 2024 at 09:36, Daniel Latypov wrote:
>
> Copying the line for context, it's about `p-r` where
> p = memchr_inv(&r[1], 0, sizeof(r) - sizeof(r[0]));
> `p-r` should never be negative unless something has gone horribly
> horribly wrong.
Sure it would - if 'p' is NULL.
Of course, th
On Wed, 21 Feb 2024 at 21:05, Lucas De Marchi wrote:
>
> this has a potential to cause conflicts with upcoming work, so I think
> it's better to apply this through drm-xe-next. Let me know if you agree.
I disagree. Violently.
For this to be fixed, we need to have the printf format checking enabl
On Sun, 28 Jan 2024 at 14:22, David Laight wrote:
>
> H blame gcc :-)
I do agree that the gcc warning quoting is unnecessarily ugly (even
just visually), but..
> The error message displays as '0' but is e2:80:98 30 e2:80:99
> I HATE UTF-8, it wouldn't be as bad if it were a bijection.
No, t
On Sun, 28 Jan 2024 at 11:36, David Laight wrote:
>
> However it generates:
> error: comparison of constant ‘0’ with boolean expression is always true
> [-Werror=bool-compare]
> inside the signedness check that max() does unless a '+ 0' is added.
Please fix your locale. You have random garba
On Mon, 22 Jan 2024 at 16:56, Bhardwaj, Rajneesh
wrote:
>
> I think a fix might already be in flight. Please see Linux-Kernel Archive:
> Re: [PATCH] drm/ttm: fix ttm pool initialization for no-dma-device drivers
> (iu.edu)
Please use lore.kernel.org that doesn't corrupt whitespace in patches
o
On Mon, 22 Jan 2024 at 15:17, Steven Rostedt wrote:
>
> Perhaps this is the real fix?
If you send a signed-off version, I'll apply it asap.
Thanks,
Linus
On Wed, 10 Jan 2024 at 11:49, Dave Airlie wrote:
>
> Let me know if there are any issues,
Your testing is seriously lacking.
This doesn't even build. The reason seems to be that commit
b49e894c3fd8 ("drm/i915: Replace custom intel runtime_pm tracker with
ref_tracker library") changed the 'intel_
On Wed, 3 Jan 2024 at 18:30, Dave Airlie wrote:
>
> These were from over the holiday period, mainly i915, a couple of
> qaic, bridge and an mgag200.
>
> I have a set of nouveau fixes that I'll send after this, that might be
> too rich for you at this point.
>
> I expect there might also be some mo
On Sat, 25 Nov 2023 at 22:58, Helge Deller wrote:
>
> please pull some small fbdev fixes for 6.7-rc3.
These all seem to be pure cleanups, not bug fixes.
Please resend during the merge window.
Linus
So every time I push to my github mirror, github now ends up having a
'dependabot' thing that warns about some of the CI version
requirements for the gitlab automated testing file.
It wants to update the pip requirements from 23.2.1 to 23.3
- When installing a package from a Mercurial VCS URL, e
On Wed, 13 Sept 2023 at 07:21, Tetsuo Handa
wrote:
>
> Hello. A deadlock was reported in drivers/gpu/drm/vkms/ .
> It looks like this locking pattern remains as of 6.6-rc1. Please fix.
>
> void drm_crtc_vblank_off(struct drm_crtc *crtc) {
> spin_lock_irq(&dev->event_lock);
> drm_vblank_disable
On Wed, 30 Aug 2023 at 18:00, Dave Airlie wrote:
>
> This is a PR to add drm-ci support files to the upstream tree.
So I finally had no other pull requests pending, and spent some time
looking at this, and I see nothing offensive.
I did wonder how this then expands to having more than one subsys
On Thu, 7 Sept 2023 at 19:45, Dave Airlie wrote:
>
> Just a poke about the outstanding drm CI support pull request since I
> haven't see any movement on that in the week, hopefully it's not as
> difficult a problem as bcachefs :-)
I was assuming that it wouldn't interfere with anything else... an
On Thu, 31 Aug 2023 at 11:48, Sudip Mukherjee (Codethink)
wrote:
> The latest mainline kernel branch fails to build mips jazz_defconfig with
> the error:
>
> drivers/video/fbdev/g364fb.c:115:9: error: 'FB_DEFAULT_IOMEM_HELPERS'
> undeclared here (not in a function); did you mean 'FB_DEFAULT_IOMEM
On Thu, 27 Jul 2023 at 19:20, Dave Airlie wrote:
>
> Regular scheduled fixes, msm and amdgpu leading the way, with some
> i915 and a single misc fbdev, all seems fine.
Pulled.
Tangentially related: where do you keep your pgp key? The one I have
is long expired, and doing a refresh doesn't get an
On Fri, 23 Jun 2023 at 14:18, Alex Deucher wrote:
>
> are available in the Git repository at:
>
> https://gitlab.freedesktop.org/agd5f/linux.git
> tags/amd-drm-fixes-6.4-2023-06-23
That's not a valid signed tag.
Yes, it's a tag. But it doesn't actually have any cryptographic
signing, and I'm
On Wed, Apr 26, 2023 at 10:44 AM Sudip Mukherjee (Codethink)
wrote:
>
> drivers/gpu/drm/ttm/ttm_pool.c:73:29: error: variably modified
> 'global_write_combined' at file scope
>73 | static struct ttm_pool_type global_write_combined[TTM_DIM_ORDER];
> | ^~~~
Kees,
I made the mistake of upgrading my M2 Macbook Air to Fedora-38, and
in the process I got gcc-13 which is not WERROR-clean because we only
limited the 'array-bounds' warning to gcc-11 and gcc-12. But gcc-13
has all the same issues.
And I want to be able to do my arm64 builds with WERROR on
On Wed, Mar 22, 2023 at 9:40 AM Sedat Dilek wrote:
>
> You have to pass `make LLVM=1` in any case... to `oldconfig` or when
> adding any MAKEFLAGS like -j${number-of-available-cpus}.
I actually think we should look (again) at just making the compiler
choice (and the prefix) be a Kconfig option.
On Mon, Mar 20, 2023 at 3:06 PM Nathan Chancellor wrote:
>
> Right, this seems like a subtle difference in semantics between
> -Wuninitialized between clang and GCC.
I guess it's a bit ambiguous whether it's
"X may be USED uninitialized"
or whether it is
"X may BE uninitialized"
and then de
On Mon, Mar 20, 2023 at 1:05 PM Guenter Roeck wrote:
>
> I have noticed that gcc doesn't always warn about uninitialized variables
> in most architectures.
Yeah, I'm getting the feeling that when the gcc people were trying to
make -Wmaybe-uninitialized work better (when moving it into "-Wall"),
t
On Mon, Mar 20, 2023 at 11:56 AM Nathan Chancellor wrote:
>
> I did see a patch fly by to fix that:
>
> https://lore.kernel.org/20230316082035.567520-3-christian.koe...@amd.com/
>
> It seems like the DRM_TEGRA half of it is broken though:
>
> https://lore.kernel.org/202303170635.a2rsq1wu-...@intel
On Mon, Mar 20, 2023 at 11:26 AM Linus Torvalds
wrote:
>
> Hmm. I do my arm64 allmodconfig builds with gcc, and I'm surprised
> that gcc doesn't warn about this.
Side note: I'm also wondering why that TEGRA_HOST1X config has that
ARM dependency in
depen
On Mon, Mar 20, 2023 at 11:05 AM Nathan Chancellor wrote:
>
> On the clang front, I am still seeing the following warning turned error
> for arm64 allmodconfig at least:
>
> drivers/gpu/host1x/dev.c:520:6: error: variable 'syncpt_irq' is
> uninitialized when used here [-Werror,-Wuninitialized]
On Wed, Mar 15, 2023 at 5:22 PM Steven Rostedt wrote:
>
> I hope that this gets in by -rc3, as I want to start basing my next branch
> on that tag.
My tree should have it now as commit c00133a9e87e ("drm/ttm: drop
extra ttm_bo_put in ttm_bo_cleanup_refs").
Linus
On Thu, Mar 16, 2023 at 4:43 AM Matthieu Baerts
wrote:
>
> @Linus: in short, we would like to continue using the "Closes:" tag (or
> similar, see below) with a URL in commit messages. They are useful to
> have public bug trackers doing automated actions like closing a specific
> ticket. Any object
On Fri, Feb 24, 2023 at 5:30 PM Dave Airlie wrote:
>
> Any issues with this? I get nervous around 48hrs :-)
It was merged on Wednesday evening. See commit a5c95ca18a98.
If you were waiting for a pr-tracker-bot reply, I think you need to
put "{GIT PULL]" in the subject line for the automation to
[ 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/event rather than lock(?) acquisition order to try to
> cover all synchonization machanisms.
On Wed, Dec 14, 2022 at 12:05 AM Christian König
wrote:
>
> Anyway we need to re-apply b09d6acba1d9 which should be trivial.
Note that my resolution did exactly that (*), it's just that when I
double-checked against Dave's suggested merge that I noticed I'd done
things differently than he did.
(
On Mon, Dec 12, 2022 at 6:56 PM Dave Airlie wrote:
>
> There are a bunch of conflicts, one in amdgpu is a bit nasty, I've
> cc'ed Christian/Alex to make sure they know to check whatever
> resolution you find. The one I have is what we have in drm-tip tree.
Hmm. My merge resolution is slightly dif
On Tue, Nov 22, 2022 at 4:25 AM Hans Verkuil wrote:
>
> I tracked the use of 'force' all the way back to the first git commit
> (2.6.12-rc1) in the very old video-buf.c. So it is very, very old and the
> reason is lost in the mists of time.
Well, not entirely.
For archaeology reasons, I went bac
On Thu, Nov 17, 2022 at 2:58 PM Kees Cook wrote:
>
> Oh, er, why does get_arg_page() even need FOLL_FORCE? This is writing the
> new stack contents to the nascent brpm->vma, which was newly allocated
> with VM_STACK_FLAGS, which an arch can override, but they all appear to
> include
> VM_WRITE |
On Wed, Nov 16, 2022 at 2:30 AM David Hildenbrand wrote:
>
> Let's make it clearer that functionality provided by FOLL_FORCE is
> really only for ptrace access.
I'm not super-happy about this one.
I do understand the "let's rename the bit so that no new user shows up".
And it's true that the ma
On Mon, Nov 7, 2022 at 8:18 AM David Hildenbrand wrote:
>
> So instead, make R/O long-term pinning work as expected, by breaking COW
> in a COW mapping early, such that we can remove any FOLL_FORCE usage from
> drivers.
Nothing makes me unhappy from a quick scan through these patches.
And I'd re
On Sat, Nov 5, 2022 at 2:03 PM Jason A. Donenfeld wrote:
>
> Something that might help here is changing the `...` into
> `... when exists` or into `... when != ptr` or similar.
I actually tried that.
You don't want "when exists", you'd want "when forall", but that seems
to be the default.
And t
On Sat, Nov 5, 2022 at 11:04 AM Steven Rostedt wrote:
>
> Here's the changes I made after running the script
Please. No.
What part of "I don't want extra crud" was I unclear on?
I'm not interested in converting everything. That's clearly a 6.,2
issue, possibly even longer considering how compli
On Fri, Nov 4, 2022 at 11:01 PM Steven Rostedt wrote:
>
> Patch 1 fixes an issue with sunrpc/xprt where it incorrectly uses
> del_singleshot_timer_sync() for something that is not a oneshot timer. As this
> will be converted to shutdown, this needs to be fixed first.
So this is the kind of thing
On Fri, Nov 4, 2022 at 12:42 PM Steven Rostedt wrote:
>
> Linus, should I also add any patches that has already been acked by the
> respective maintainer?
No, I'd prefer to keep only the ones that are 100% unambiguously not
changing any semantics.
Linus
On Thu, Nov 3, 2022 at 10:48 PM Steven Rostedt wrote:
>
> Ideally, I would have the first patch go into this rc cycle, which is mostly
> non functional as it will allow the other patches to come in via the
> respective
> subsystems in the next merge window.
Ack.
I also wonder if we could do the
On Fri, Oct 14, 2022 at 8:22 AM Nathan Chancellor wrote:
>
> After commit 8799c0be89eb ("drm/amd/display: Fix vblank refcount in vrr
> transition"), a build with CONFIG_DEBUG_FS=n is broken due to a
> misplaced brace, along the lines of:
Thanks, applied.
Linus
On Thu, Oct 13, 2022 at 5:29 PM Dave Airlie wrote:
>
> Round of fixes for the merge window stuff, bunch of amdgpu and i915
> changes, this should have the gcc11 warning fix, amongst other
> changes.
Some of those amd changes aren't "fixes". They are some major code changes.
We're still in the me
On Thu, Oct 6, 2022 at 1:50 PM Sudip Mukherjee
wrote:
>
> > And it looks like Sudip's proposed fix for this particular code is
> > additionally fixing unsigned vs signed as well. I think -Warray-bounds
> > did its job (though, with quite a confusing index range in the report).
>
> Not my. Linus's.
On Thu, Oct 6, 2022 at 1:25 PM Dave Airlie wrote:
>
>
> [ 1234.778760] BUG: kernel NULL pointer dereference, address: 0088
> [ 1234.778813] RIP: 0010:drm_sched_job_done.isra.0+0xc/0x140 [gpu_sched]
As far as I can tell, that's the line
struct drm_gpu_scheduler *sched = s_fenc
On Thu, Oct 6, 2022 at 12:28 PM Alex Deucher wrote:
>
> Maybe you are seeing this which is an issue with GPU TLB flushes which
> is kind of sporadic:
> https://gitlab.freedesktop.org/drm/amd/-/issues/2113
Well, that seems to be 5.19, and while timing changes (or whatever
other software updates) c
On Thu, Oct 6, 2022 at 12:30 PM Dave Airlie wrote:
>
> netconsole?
I've never been really successful with that in the past, and haven't
used it for decades. I guess I could try if nothing else works.
Linus
On Thu, Oct 6, 2022 at 1:51 AM Sudip Mukherjee (Codethink)
wrote:
>
> This is only seen with gcc-11, gcc-12 builds are ok.
Hmm. This seems to be some odd gcc issue.
I *think* that what is going on is that the test
j = 0 ; j < MAX_DWB_PIPES
makes gcc decide that "hey, j is in the range
On Tue, Oct 4, 2022 at 8:42 PM Dave Airlie wrote:
>
> Lots of stuff all over, some new AMD IP support and gang
> submit support [..]
Hmm.
I have now had my main desktop lock up twice after pulling this.
Nothing in the dmesg after a reboot, and nothing in particular that
seems to trigger it, so I
On Tue, Oct 4, 2022 at 8:42 PM Dave Airlie wrote:
>
> This is very conflict heavy, mostly the correct answer is picking
> the version from drm-next.
Ugh, yes, that was a bit annoying.
I get the same end result as you did, but I do wonder if the drm
people should try to keep some kind of separate
On Wed, Sep 28, 2022 at 1:15 AM Gwan-gyeong Mun
wrote:
>
> + if (check_assign(obj->base.size >> PAGE_SHIFT, &npages))
> + return -E2BIG;
I have to say, I find that new "check_assign()" macro use to be disgusting.
It's one thing to check for overflows.
It's another thing enti
1 - 100 of 745 matches
Mail list logo
