On Mon, Jul 15, 2019 at 10:37 AM Linus Torvalds
wrote:
>
> I'm not pulling this. Why did you merge it into your tree, when
> apparently you were aware of how questionable it is judging by the drm
> pull request.
Looking at some of the fallout, I also see that you then a
[ Ugh, I have three different threads about the drm pull because of
the subject / html confusion. So now I'm replying in separate threads
and I'm hoping the people involved have better threading than gmail
does ;/ ]
On Mon, Jul 15, 2019 at 5:29 AM Jason Gunthorpe wrote:
>
> The 'hmm' tree is some
On Mon, Jul 15, 2019 at 11:29 AM Dave Airlie wrote:
>
> Not that I want to defend that code, but the mm patch that conflicts
> already shows that removing the token is fine as nobody needs or
> requires it. So the fixup patch in my tree was just a bridge to that patch,
> which reduces conflicts. R
On Mon, Jul 15, 2019 at 11:16 AM Linus Torvalds
wrote:
>
> On Mon, Jul 15, 2019 at 5:29 AM Jason Gunthorpe wrote:
> >
> > The 'hmm' tree is something I ran to try and help workflow issues like
> > this, as it could be merged to DRM as a topic branch - mayb
On Mon, Jul 15, 2019 at 12:17 PM Jason Gunthorpe wrote:
>
> About the only thing I could concretely suggest for working with -mm
> is if there was some way the -mm quilt patches could participate in
> 'git merge' resolution at your level.
Andrew did make noises about having multiple git branches.
On Mon, Jul 15, 2019 at 12:36 PM Thomas Hellström (VMware)
wrote:
>
> - I've never had any kernel code more reviewed than this.
Hmm. It may have been reviewed, but that wasn't visible in the commits
themselves, so when I look at the pull request, I don't see that.
> - The combined callback / arg
On Mon, Jul 15, 2019 at 1:07 PM Linus Torvalds
wrote:
>
> The mm_walk struct is indeed a bit similar, and is in fact a bit
> problematic exactly because it mixes function pointers with non-const
> data.
This made me look at how nasty that would be to fix.
Not too bad.
The attache
On Mon, Jul 15, 2019 at 11:38 AM Dave Airlie wrote:
>
> The reason I was waiting for the HMM tree to land, is a single silent
> merge conflict needs to be resolved after merging this as below.
There's more than that there.
For example, the DRM_AMDGPU_USERPTR config has a
depends on ARCH
On Fri, Jul 19, 2019 at 8:43 AM Daniel Vetter wrote:
>
> drm fixes for -rc1:
>
> nouveau:
> - bugfixes + TU116 enabling (minor iteration):w
Asking the important question:
- WTH is that ":w" thing?
I have a theory that it's just a "I'm confused by 'vi'" marker. Very
understandable.
But I'm al
On Sun, Jul 21, 2019 at 1:20 PM Daniel Vetter wrote:
>
> It's dead code ever since
Lovely. Ack.
Linus
On Tue, Jun 7, 2022 at 3:23 AM Geert Uytterhoeven wrote:
>
> These header files are heavy users of large constants lacking the "U"
> suffix e.g.:
>
> #define NB_ADAPTER_ID__SUBSYSTEM_ID_MASK 0xL
As Andreas says, this is not undefined behavior.
A hexadecimal integer constant will alwa
On Tue, Feb 15, 2022 at 10:37 PM Damien Le Moal
wrote:
>
> On 2/16/22 13:16, Byungchul Park wrote:
> > [2.051040] ===
> > [2.051406] DEPT: Circular dependency has been detected.
> > [2.051730] 5.17.0-rc1-00014-gcf3441bb2012 #2 Tainted: G
On Wed, May 4, 2022 at 1:19 AM Byungchul Park wrote:
>
> Hi Linus and folks,
>
> 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.
So what is the actual status of reports
On Tue, Aug 2, 2022 at 10:38 PM Dave Airlie wrote:
>
> This is a conflicty one. The late revert in 5.19 of the amdgpu buddy
> allocator causes major conflict fallout. The buddy allocator code in
> this one works, so the resolutions are usually just to take stuff from
> this. It might actually be c
On Wed, Aug 3, 2022 at 7:46 PM Linus Torvalds
wrote:
>
> I think I have it resolved, am still doing a full build test, and will
> then compare against what your suggested merge is.
Hmm.
I end up with *almost* the same thing.
Except I ended up with a
select DRM_BUDDY
On Wed, Aug 3, 2022 at 8:37 PM Dave Airlie wrote:
>
> Actually I did miss that so that looks good.
.. I wish it did, but I just actually test-booted my desktop with the
result, and it crashes the X server. This seems to be the splat in
Xorg.0.log:
(II) Initializing extension DRI2
(II) AMDGP
On Wed, Aug 3, 2022 at 8:53 PM Dave Airlie wrote:
>
> > It works on my intel laptop, so it's amdgpu somewhere.
>
> I'll spin my ryzen up to see if I can reproduce, and test against the
> drm-next pre-merge tree as well.
So it's not my merge - I've had a bad result in the middle of the DRM
history
On Wed, Aug 3, 2022 at 9:24 PM Dave Airlie wrote:
>
> I've reproduced it, I'll send you a revert pile when I confirm it is
> the buddy allocator.
I've bisected it to 86bd6706c404..074293dd9f61 and don't see "buddy"
in any of those commits.
I'll do a few more. It's close enough already that it sh
On Wed, Aug 3, 2022 at 9:27 PM Linus Torvalds
wrote:
>
> I'll do a few more. It's close enough already that it should be just
> four more reboots to pinpoint exactly which commit breaks.
commit 5d945cbcd4b16a29d6470a80dfb19738f9a4319f is the first bad commit.
I think it&#x
On Thu, Aug 4, 2022 at 12:35 AM Sudip Mukherjee (Codethink)
wrote:
>
> I will be happy to test any patch or provide any extra log if needed.
It sounds like that file just needs to get a
#include
there, and for some reason architectures other than alpha and mips end
up getting it accidental
On Wed, Aug 3, 2022 at 10:50 PM Dave Airlie wrote:
>
> With this applied, I get gdm back.
I can confirm that it makes thing work again for me too. Applied.
Linus
On Thu, Aug 4, 2022 at 11:37 AM Sudip Mukherjee (Codethink)
wrote:
>
> git bisect points to 3876a8b5e241 ("drm/amd/display: Enable building new
> display engine with KCOV enabled").
Ahh. So that was presumably why it was disabled before - because it
presumably does disgusting things that make KC
On Thu, Aug 4, 2022 at 1:43 PM Nathan Chancellor wrote:
>
> I do note that commit 1b54a0121dba ("drm/amd/display: Reduce stack size
> in the mode support function") did have a workaround for GCC. It appears
> clang will still inline mode_support_configuration(). If I mark it as
> 'noinline', the w
On Sun, Aug 7, 2022 at 10:36 AM David Laight wrote:
>
> Or just shoot the software engineer who thinks 100 arguments
> is sane. :-)
I suspect the issue is that it's not primarily a software engineer who
wrote that code.
Hardware people writing code are about as scary as software engineers
with a
On Thu, May 5, 2022 at 9:07 PM Dave Airlie wrote:
>
> pretty quiet week, one fbdev, msm, kconfig, and 2 amdgpu fixes, about
> what I'd expect for rc6.
You're not getting the automated pr-tracker-bot response, because your
subject line was missing...
Just a "how did that happen" together with a "
On Tue, May 10, 2022 at 10:07 PM Dave Airlie wrote:
>
> > And use it to store expectations about what the drm/msm driver is
> > supposed to pass in the IGT test suite.
>
> I wanted to loop in Linus/Greg to see if there are any issues raised
> by adding CI results file to the tree in their minds, o
On Wed, May 11, 2022 at 11:40 AM Rob Clark wrote:
>
> It is missing in this revision of the RFC, but the intention is to
> have the gitlab-ci.yml point to a specific commit SHA in the
> gfx-ci/drm-ci[1] tree, to solve the problem of keeping the results in
> sync with the expectations. Ie. a kerne
On Wed, May 11, 2022 at 12:08 PM Linus Torvalds
wrote:
>
> The kernel tree might have just the expected *failures* listed, if
> there are any. Presumably the ci tree has to have the expected results
> anyway, so what's the advantage of listing non-failures?
.. put another way:
On Tue, May 24, 2022 at 11:07 PM Dave Airlie wrote:
>
> AMD has started some new GPU support [...]
Oh Christ. Which means another set of auto-generated monster headers. Lovely.
Linus
On Fri, May 27, 2022 at 2:07 AM Sudip Mukherjee
wrote:
>
> declared with attribute error: BUILD_BUG_ON failed: sizeof(*edid) !=
> EDID_LENGTH
>
> And, reverting it on top of mainline branch has fixed the build failure.
Hmm. That BUILD_BUG_ON() looks entirely correct, and if that sizeof()
On Fri, May 27, 2022 at 4:41 PM Sudip Mukherjee
wrote:
>
> I just tested with various values, sizeof(*edid) is 144 bytes at that place.
Hmm. What compiler do you have? Because it seems very broken.
You don't actually have to try with various sizes, you could have just
done something like
int s
On Sat, May 28, 2022 at 5:13 AM Sudip Mukherjee
wrote:
>
> just tried this with
> make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- drivers/gpu/drm/drm_edid.s
>
> size_of_edid:
> mov r0, #144@,
> ldmfd sp, {fp, sp, pc}@
So digging a bit deeper - since I have am
On Sat, May 28, 2022 at 10:40 AM Linus Torvalds
wrote:
>
> So digging a bit deeper - since I have am arm compiler after all - I
> note that 'sizeof(detailed_timings)' is 88.
Hmm.
sizeof() both
detailed_timings[0].data.other_data.data.range.formula.gtf2
and
On Sat, May 28, 2022 at 11:59 AM Arnd Bergmann wrote:
>
> It's CONFIG_ARM_AEABI, which is normally set everywhere. Without this
> option, you the kernel is built for the old 'OABI' that forces all non-packed
> struct members to be at least 16-bit aligned.
Looks like forced word (32 bit) alignment
On Tue, May 31, 2022 at 1:04 AM Arnd Bergmann wrote:
>
> As an experiment: what kind of results would we get when looking
> for packed structures and unions that contain any of these:
Yeah, any atomics or locks should always be aligned, and won't even
work (or might be *very* slow) on multiple ar
On Wed, Jun 1, 2022 at 3:28 PM Keisuke Nishimura
wrote:
>
>
> I found 13 definitions of packed structure that contains:
> > - spinlock_t
> > - atomic_t
> > - dma_addr_t
> > - phys_addr_t
> > - size_t
> > - struct mutex
> > - struct device
>
> - raw_spinlock_t
Ok, so I don't think dma_addr_
So this has been going on for a while, and it's quite annoying.
At bootup, my main desktop (Threadripper 3970X with radeon graphics)
now complains about
resource sanity check: requesting [mem 0xd000-0xdfff], which
spans more than BOOTFB [mem 0xd000-0xd02f]
and then gives me a n
On Mon, Jun 27, 2022 at 1:02 AM Javier Martinez Canillas
wrote:
>
> The flag was dropped because it was causing drivers that requested their
> memory resource with pci_request_region() to fail with -EBUSY (e.g: the
> vmwgfx driver):
>
> https://www.spinics.net/lists/dri-devel/msg329672.html
See,
On Thu, Apr 7, 2022 at 2:20 PM Dave Airlie wrote:
>
> I think this should fix the amdgpu splat you have been seeing since rc1.
Not the machine I'm currently traveling with, but I'll double-check
when I'm back home.
Thanks,
Linus
On Thu, Apr 14, 2022 at 2:33 PM Dave Airlie wrote:
>
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-04-15
.. and since I'm now back home, I can confirm that my boot-time splat
I saw before is all gone.
It presumably went away with the previous pull request already, but I
hadn't r
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
On Fri, Jul 15, 2022 at 2:09 PM Nathan Chancellor wrote:
>
> On Fri, Jul 15, 2022 at 01:36:17PM +1000, Dave Airlie wrote:
> > Matthew Auld (1):
> > drm/i915/ttm: fix sg_table construction
>
> This patch breaks i386_defconfig with both GCC and clang:
>
> ld: drivers/gpu/drm/i915/i915_scatte
On Sat, Jul 16, 2022 at 2:35 PM Linus Torvalds
wrote:
>
> That said, even those type simplifications do not fix the fundamental
> issue. That "DIV_ROUND_UP()" still ends up being a 64-bit divide,
> although now it's at least a "64-by-32" bit divide.
Hmm
On Wed, Dec 18, 2019 at 6:59 AM Jason Gunthorpe wrote:
>
> Do you think calling it 'mmn_subscriptions' is clear?
Why do you want that "mmn"?
Guys, the "mmn" part is clear from the _context_. The function name is
When the function name is something like "mmu_interval_read_begin()",
and the filen
On Wed, Dec 18, 2019 at 10:37 AM Jason Gunthorpe wrote:
>
> I think this is what you are looking for?
I think that with these names, I would have had an easier time reading
the original patch that made me go "Eww", yes.
Of course, now that it's just a rename patch, it's not like the patch
is all
On Fri, Oct 4, 2019 at 2:39 PM Theodore Y. Ts'o wrote:
>
> This question is primarily directed at Shuah and Linus
>
> What's the current status of the kunit series now that Brendan has
> moved it out of the top-level kunit directory as Linus has requested?
We seemed to decide to just wait for
On Sun, Oct 6, 2019 at 9:55 AM Theodore Y. Ts'o wrote:
>
> Well, one thing we *can* do is if (a) if we can create a kselftest
> branch which we know is stable and won't change, and (b) we can get
> assurances that Linus *will* accept that branch during the next merge
> window, those subsystems whi
On Fri, Mar 6, 2020 at 4:38 AM Daniel Vetter wrote:
>
> Linus, since this missed the -fixes pull from Dave maybe double check I'm
> not grossly wrong here and apply directly?
Hmm. I don't have the original email, mind just sending it to me (with
the proper added sign-off chain)?
It does strike m
On Fri, Mar 6, 2020 at 7:12 AM Daniel Vetter wrote:
>
> I'll stuff it into a pull and throw that your way, that's simplest.
Thanks.
> btw we did add dri-devel to lore a while back, so should be there:
Indeed. I tried (incompetently) to look up your message ID, but I
didn't put the dri-devel par
Dave, Alex,
there's an odd bugreport on bugzilla, where Artem is seeing an odd
early-boot failure.
That one almost certainly has nothing to do with you guys, but see the
later odd (and apparently unrelated) report about some AMD graphics
firmware issue and a black screen.
Li
On Thu, Jan 23, 2020 at 4:59 AM Christophe Leroy
wrote:
>
> On 32 bits powerPC (book3s/32), only write accesses to user are
> protected and there is no point spending time on unlocking for reads.
Honestly, I'm starting to think that 32-bit ppc just needs to look
more like everybody else, than mak
On Thu, Jan 23, 2020 at 11:47 AM christophe leroy
wrote:
>
> I'm going to leave it aside, at least for the time being, and do it as a
> second step later after evaluating the real performance impact. I'll
> respin tomorrow in that way.
Ok, good.
>From a "narrow the access window type" standpoint
On Wed, Jan 29, 2020 at 9:58 PM Dave Airlie wrote:
>
> It has two known conflicts, one in i915_gem_gtt, where you should juat
> take what's in the pull (it looks messier than it is),
That doesn't seem right. If I do that, I lose the added GEM_BUG_ON()'s.
I think the proper merge resolution does
On Thu, Jan 30, 2020 at 8:13 AM Linus Torvalds
wrote:
>
> That doesn't seem right. If I do that, I lose the added GEM_BUG_ON()'s.
Just for your ref: see commit ecc4d2a52df6 ("drm/i915/userptr: fix
size calculation") for the source of those debug statements, and then
2
On Thu, Sep 12, 2019 at 8:56 AM Dave Airlie wrote:
>
> Hey Linus,
>
> From the maintainer summit, just some last minute fixes for final,
> details in the tag.
So because my mailbox was more unruly than normal (because of same
maintainer summit travel), I almost missed this email entirely.
Why? B
On Sun, Sep 15, 2019 at 8:12 AM Dave Airlie wrote:
>
> I've been manually writing the subject lines, seems I need to fix my brain.
Note that my "find git pull requests" logic doesn't need it in the
subject line at all, so if you just change whatever script you use to
generate the email body to ha
On Thu, Sep 19, 2019 at 12:09 PM Dave Airlie wrote:
>
> There are a few merge conflicts across the board, we have a shared
> rerere cache which meant I hadn't noticed them until I avoided the
> cache.
> https://cgit.freedesktop.org/drm/drm/log/?h=drm-5.4-merge
> contains what we've done, none of t
On Thu, Sep 26, 2019 at 5:03 AM Thomas Hellström (VMware)
wrote:
>
> I wonder if I can get an ack from an mm maintainer to merge this through
> DRM along with the vmwgfx patches? Andrew? Matthew?
It would have helped to actually point to the patch itself, instead of
just quoting the commit messag
On Thu, Sep 26, 2019 at 1:09 PM Thomas Hellström (VMware)
wrote:
>
> That said, if people are OK with me modifying the assert in
> pud_trans_huge_lock() and make __walk_page_range non-static, it should
> probably be possible to make it work, yes.
I don't think you need to modify that assert at al
On Thu, Sep 26, 2019 at 1:55 PM Thomas Hellström (VMware)
wrote:
>
> Well, we're working on supporting huge puds and pmds in the graphics
> VMAs, although in the write-notify cases we're looking at here, we would
> probably want to split them down to PTE level.
Well, that's what the existing walk
On Fri, Sep 27, 2019 at 5:17 AM Kirill A. Shutemov wrote:
>
> > Call it "walk_page_mapping()". And talk extensively about how the
> > locking differs a lot from the usual "walk_page_vma()" things.
>
> Walking mappings of a page is what rmap does. This code thas to be
> integrated there.
Well, tha
On Mon, Sep 30, 2019 at 6:04 AM Kirill A. Shutemov wrote:
>
> Have you seen page_vma_mapped_walk()? I made it specifically for rmap code
> to cover cases when a THP is mapped with PTEs. To me it's not a big
> stretch to make it cover multiple pages too.
I agree that is closer, but it does make fo
On Wed, Nov 27, 2019 at 4:59 PM Dave Airlie wrote:
>
> my sample merge is here:
> https://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next-5.5-merged
Hmm. I think you missed a couple: you left a duplicate
intel_update_rawclk() around (it got moved into
intel_power_domains_init_hw() by commit 2
On Thu, Nov 28, 2019 at 5:15 PM Dave Airlie wrote:
>
> This is just a separated pull for the mm pagewalking + drm/vmwgfx work
> Thomas did and you were involved in, I've left it separate in case you
> don't feel as comfortable with it as the other stuff.
Thanks, pulled (and the delay wasn't becau
On Mon, Nov 25, 2019 at 12:42 PM Jason Gunthorpe wrote:
>
> You will probably be most interested in the patch "mm/mmu_notifier: add an
> interval tree notifier".
I'm trying to read that patch, and I'm completely unable to by the
absolutely *horrid* variable names.
There are zero excuses for name
On Sat, Nov 30, 2019 at 10:03 AM Linus Torvalds
wrote:
>
> I'll try to figure the code out, but my initial reaction was "yeah,
> not in my VM".
Why is it ok to sometimes do
WRITE_ONCE(mni->invalidate_seq, cur_seq);
(to pair with the unlocked READ_ONCE), and
On Mon, Nov 25, 2019 at 12:42 PM Jason Gunthorpe wrote:
>
> Here is this batch of hmm updates, I think we are nearing the end of this
> project for now, although I suspect there will be some more patches related to
> hmm_range_fault() in the next cycle.
I've ended up pulling this, but I'm not ent
On Tue, Aug 6, 2019 at 12:38 AM Christoph Hellwig wrote:
>
> Seems like no one took this up. Below is a version which I think is
> slightly better by also moving the mm_walk structure initialization
> into the helpers, with an outcome of just a handful of added lines.
Ack. Agreed, I think that's
On Tue, Aug 6, 2019 at 11:40 PM Christoph Hellwig wrote:
>
> I'm not an all that huge fan of super magic macro loops. But in this
> case I don't see how it could even work, as we get special callbacks
> for huge pages and holes, and people are trying to add a few more ops
> as well.
Yeah, in thi
On Thu, Jun 10, 2021 at 8:41 PM Dave Airlie wrote:
>
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-06-11
I think anongit.freedesktop.org is sick. Can you ask somebody to give
it some tender loving? It's just disconnecting immediately..
Linus
On Fri, Jun 11, 2021 at 10:07 AM Linus Torvalds
wrote:
>
> I think anongit.freedesktop.org is sick. Can you ask somebody to give
> it some tender loving? It's just disconnecting immediately..
Either somebody gave the site a hug, or it decided to just get better
on its own. It
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 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 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 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 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 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 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 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 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 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 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 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 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 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, 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 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 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 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 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 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 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.
(
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, 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];
> | ^~~~
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 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 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 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: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
101 - 200 of 743 matches
Mail list logo
