Re: [git pull] drm for v4.15

On Fri, Nov 17, 2017 at 10:14 AM, Christian König wrote: > > Taking an example from the AMD headers why this automation is more tricky > than it sounds in the first place: Look at the > mmVM_CONTEXT*_PAGE_TABLE_BASE_ADDR registers for example. > > Register 0-7 are

Re: [git pull] drm for v4.15

On Fri, Nov 17, 2017 at 9:19 AM, Lukas Wunner wrote: >> and tell me that there isn't any room for making these things smarter. > > ... or deduplicate them. :-) You could even - wait for it - have _automation_ that does it. Yeah, it's easier to write a stupid sed-script or

Re: [git pull] drm for v4.15

On Fri, Nov 17, 2017 at 4:51 AM, Nicolai Hähnle wrote: > > This raises the question of how people feel about putting the source > database into the kernel (most likely as XML in our case) and > auto-generating the headers from there instead. I suspect that at least in some

Re: [git pull] drm for v4.15

On Thu, Nov 16, 2017 at 12:57 PM, Dave Airlie wrote: > > This sounds more like a Monty Python sketch than a serious question. It's a serious question when the files start appearing in random places where they don't belong. There's a place for automatically generated files.

Re: [git pull] drm for v4.15

On Wed, Nov 15, 2017 at 6:34 PM, Dave Airlie wrote: > > There is some code touched on sound/soc, but I think the sound tree > should have the same commits from the same base,so this may luck different > if you pulled it as I generated my pull request a couple of days ago. >

Re: [git pull] drm fixes for v4.15-rc3

On Thu, Dec 7, 2017 at 5:20 PM, Dave Airlie wrote: > > This pull is a bit larger than I'd like but a large bunch of it is > license fixes, AMD wanted to fix the licenses for a bunch of files > that were missing them, Oh Christ, couldn't they have just added the one-liner SPDX

Re: Kernel and ADM hardware roulette ( was AMD graphics performance regression in 4.15 and later )

On Mon, Jun 11, 2018 at 12:07 AM Christoph Hellwig wrote: > > For now I'd say revert this commit for 4.17/4.18-rc and I'll look into > addressing these issues properly. Ok, reverted in my tree, and marked for stable (for 4.17). Thanks, Linus

Re: [git pull] drm for v4.18-rc1

On Tue, Jun 5, 2018 at 8:50 PM Dave Airlie wrote: > > First up I've moved the drm tree to a new location on freedesktop.org. The > main > reason was to explore using Daniel's maintainer tools (dim-tools) to manage > pull requests and possibly open the drm to having co-maintainers at the top >

Re: [git pull] drm pull for v4.16-rc1

On Thu, Feb 1, 2018 at 4:40 PM, Dave Airlie wrote: > > This seems to have been a comparatively quieter merge window, I assume > due to holidays etc. Hmm. I pulled, and then noticed that there's no diffstat to compare my end result with. Then I was going to at least compare

Re: [git pull] drm pull for v4.16-rc1

On Thu, Feb 1, 2018 at 6:22 PM, Dave Airlie wrote: > > Turned out I was running on wayland instead of X.org and my cut-n-paste from > gedit to firefox got truncated, wierd. I'll go annoy some people, and make > sure > it doesn't happen again. Heh, so there's some Wayland

Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)

On Tue, Jul 31, 2018 at 10:49 AM Linus Torvalds wrote: > > So the re-use might initialize the fields lazily, not necessarily using a > ctor. In particular, the pattern that nf_conntrack uses looks like it is safe. If you have a well-defined refcount, and use "atomic_inc_not_ze

Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)

On Tue, Jul 31, 2018 at 10:36 AM Christopher Lameter wrote: > > If there is refcounting going on then why use SLAB_TYPESAFE_BY_RCU? .. because the object can be accessed (by RCU) after the refcount has gone down to zero, and the thing has been released. That's the whole and only point of

Re: Possible use_mm() mis-uses

On Wed, Aug 22, 2018 at 12:37 PM Oded Gabbay wrote: > > Having said that, I think we *are* protected by the mmu_notifier > release because if the process suddenly dies, we will gracefully clean > the process's data in our driver and on the H/W before returning to > the mm core code. And before we

Re: Possible use_mm() mis-uses

On Wed, Aug 22, 2018 at 11:16 PM Zhenyu Wang wrote: > > yeah, that's the clear way to fix this imo. We only depend on guest > life cycle to access guest memory properly. Here's proposed fix, will > verify and integrate it later. Thanks, this looks sane to me, Linus

Re: Possible use_mm() mis-uses

On Wed, Aug 22, 2018 at 12:44 PM Felix Kuehling wrote: > > You're right, but that's a bit fragile and convoluted. I'll fix KFD to > handle this more robustly. See the attached (untested) patch. Yes, this patch that makes the whole "has to use current mm" or uses "get_task_mm()" looks good from a

Possible use_mm() mis-uses

Guys and gals, this is a *very* random list of people on the recipients list, but we had a subtle TLB shootdown issue in the VM, and that brought up some issues when people then went through the code more carefully. I think we have a handle on the TLB shootdown bug itself. But when people were

Re: Possible use_mm() mis-uses

On Wed, Aug 22, 2018 at 11:21 AM Paolo Bonzini wrote: > > Yes, KVM is correct but the i915 bits are at least fishy. It's probably > as simple as adding a mmget/mmput pair respectively in kvmgt_guest_init > and kvmgt_guest_exit, or maybe mmget_not_zero. Definitely mmget_not_zero(). If it was

Re: Possible use_mm() mis-uses

On Wed, Aug 22, 2018 at 11:33 AM Linus Torvalds wrote: > > On Wed, Aug 22, 2018 at 11:21 AM Paolo Bonzini wrote: > > > > Yes, KVM is correct but the i915 bits are at least fishy. It's probably > > as simple as adding a mmget/mmput pair respectively in kvmgt_guest_init

Re: [GIT PULL] VLA removal for v4.20-rc1

On Sun, Oct 28, 2018 at 10:24 AM Kees Cook wrote: > > Please pull these VLA removal changes for v4.20-rc1. Pulled, Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org

Re: [git pull] drm pull for 4.20-rc1

On Sun, Oct 28, 2018 at 4:47 PM Dave Airlie wrote: > > This is the main drm pull request for 4.20-rc1. .. pulled. I'm not sure I love the new list helper, but it's not wrong. I think it would probably have been cleaner to do this as a "cut out first->last" followed by "splice to tail" pair (we

Re: [git pull] drm pull for 4.20-rc1

On Sun, Oct 28, 2018 at 4:47 PM Dave Airlie wrote: > > I was just about to ask if I'd gotten a reply that require Linus > filtering, then I realised I hadn't sent this to you, but the mailing > list by mistake. Heh. And _I_ was just about to send you a query about where the pull request was,

Re: [GIT PULL] fbdev changes for v4.20

On Wed, Oct 31, 2018 at 7:31 AM Bartlomiej Zolnierkiewicz wrote: > > Please pull fbdev changes for v4.20. No major changes to the subsystem > itself, mainly fb drivers fixes & cleanups (atyfb & udlfb updates stand > out from the rest) + removal of no longer needed old clps711xfb driver. Pulled,

Re: [git pull] drm next fixes for 4.20-rc1

On Thu, Nov 1, 2018 at 10:32 PM Dave Airlie wrote: > > Pretty much a normal fixes pull pre-rc1, mostly amdgpu fixes, one i915 > link training regression fix, and a couple of minor panel/bridge fixes > and a panel quirk. Pulled, Linus

Re: [git pull] drm fixes for 5.0-rc3

On Fri, Jan 18, 2019 at 12:43 PM Dave Airlie wrote: > > Going to be at LCA next week in Christchurch, but should be fine for > normal pulls. .. hey, me too. > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-01-18 Pulled, Linus

Re: [git pull] drm fixes for v5.2-rc4 (v2)

On Fri, Jun 7, 2019 at 12:24 AM Dave Airlie wrote: > > I sent this out earlier, but I forgot the subject, and then Ben asked > about some nouveau firmware fixes. Well, the first one at least had the address to pull from, and the diffstat. The second one has the subject, and mentions nouveau,

Re: [git pull] drm fixes for v5.2-rc4 (v2)

On Fri, Jun 7, 2019 at 10:20 AM Linus Torvalds wrote: > > The second one has the subject, and mentions nouveau, but doesn't > actually have the tag name or the expected diffstat and shortlog. Hmm. I'm guessing you meant for me to pull the 'tags/drm-fixes-2019-06-07-1' thing, wh

Re: [git pull] drm fixes for 5.2-rc6

On Thu, Jun 20, 2019 at 9:21 PM Dave Airlie wrote: > > Just catching up on the week since back from holidays, everything > seems quite sane. .. well, except for anongit.freedesktop.org itself, which seems very sick indeed. Does it work for you? I'm getting a connection reset, no data.

Re: [git pull] drm fixes for 5.2-rc6

On Fri, Jun 21, 2019 at 10:06 AM Daniel Stone wrote: > > > Does it work for you? I'm getting a connection reset, no data. > > It is quite sick indeed; it's fallen down an NFS hole and is being > restarted. Should be back in a few minutes. Thanks, everything does indeed look good again now,

Re: [RFC][PATCH] kernel.h: Add generic roundup_64() macro

On Thu, May 23, 2019 at 7:00 AM Steven Rostedt wrote: > > +# define roundup_64(x, y) (\ > +{ \ > + typeof(y) __y = y; \ > + typeof(x) __x = (x) + (__y - 1);\ >

Re: [RFC][PATCH] kernel.h: Add generic roundup_64() macro

On Thu, May 23, 2019 at 8:27 AM Steven Rostedt wrote: > > I haven't yet tested this, but what about something like the following: So that at least handles the constant case that the normal "roundup()" case also handles. At the same time, in the case you are talking about, I really do suspect

Re: [RFC][PATCH] kernel.h: Add generic roundup_64() macro

On Thu, May 23, 2019 at 10:36 AM Steven Rostedt wrote: > > > > > Of course, you probably want the usual "at least use 'int'" semantics, > > in which case the "type" should be "(x)+0": > > > > #define round_up(x, y) size_fn((x)+0, round_up_size, x, y) > > > > and the 8-bit and 16-bit cases

Re: [git pull] drm for 5.2-rc1

Dave, On Wed, May 8, 2019 at 8:28 PM Dave Airlie wrote: > > This is the main drm pull request for 5.2. Thanks. I've merged it, but I got a couple of conflicts with fixes (reverts) to mainline in the meantime. The one to the i915 driver you seem to have applied again (after the function was

Re: [GIT PULL] Please pull hmm changes

On Tue, Jul 9, 2019 at 12:24 PM Jason Gunthorpe wrote: > > I'm sending it early as it is now a dependency for several patches in > mm's quilt. .. but I waited to merge it until I had time to review it more closely, because I expected the review to be painful. I'm happy to say that I was overly

Re: drm fixes for 5.3-rc9

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?

Re: drm fixes for 5.3-rc9

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

Re: drm pull for v5.3-rc1

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

Re: drm pull for v5.3-rc1

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

Re: [PATCH] fbdev: Ditch fb_edid_add_monspecs

On Sun, Jul 21, 2019 at 1:20 PM Daniel Vetter wrote: > > It's dead code ever since Lovely. Ack. Linus

Re: [PULL] drm-next fixes for -rc1

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

Re: DRM pull for v5.3-rc1

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 - maybe consider

Re: drm pull for v5.3-rc1

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 added

Re: DRM pull for v5.3-rc1

[ 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

Re: drm pull for v5.3-rc1

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.

Re: drm pull for v5.3-rc1

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

Re: [git pull] drm pull for 5.3-rc1

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

Re: drm pull for v5.3-rc1

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 /

Re: DRM pull for v5.3-rc1

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

Re: drm pull for v5.3-rc1

On Mon, Jul 15, 2019 at 12:08 AM Dave Airlie wrote: > > VMware had some mm helpers go in via my tree (looking back I'm not > sure Thomas really secured enough acks on these, but I'm going with it > for now until I get push back). Yeah, this is the kind of completely unacceptable stuff that I was

Re: [git pull] drm tree for 5.4-rc1

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

Re: Ack to merge through DRM? WAS Re: [PATCH v2 1/5] mm: Add write-protect and clean utilities for address space ranges

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

Re: Ack to merge through DRM? WAS Re: [PATCH v2 1/5] mm: Add write-protect and clean utilities for address space ranges

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

Re: Ack to merge through DRM? WAS Re: [PATCH v2 1/5] mm: Add write-protect and clean utilities for address space ranges

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

Re: Ack to merge through DRM? WAS Re: [PATCH v2 1/5] mm: Add write-protect and clean utilities for address space ranges

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,

Re: Ack to merge through DRM? WAS Re: [PATCH v2 1/5] mm: Add write-protect and clean utilities for address space ranges

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

Re: [GIT PULL] Please pull hmm changes

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 some

Re: [git pull] mm + drm vmwgfx coherent

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

Re: [GIT PULL] Please pull hmm changes

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

Re: [GIT PULL] Please pull hmm changes

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

Re: [git pull] drm for 5.5-rc1

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

Re: [PATCH v18 00/19] kunit: introduce KUnit, the Linux kernel unit testing framework

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

Re: [PATCH v18 00/19] kunit: introduce KUnit, the Linux kernel unit testing framework

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

Re: [GIT PULL] Please pull hmm changes

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

Re: [GIT PULL] Please pull hmm changes

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

Re: [v4] vgacon: Fix a UAF in vgacon_invert_region

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

Re: [v4] vgacon: Fix a UAF in vgacon_invert_region

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

Re: [git pull] drm for 5.6-rc1

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

Re: [git pull] drm for 5.6-rc1

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 2c86e55d2ab

Re: [PATCH v3 2/7] uaccess: Tell user_access_begin() if it's for a write or not

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

Re: [PATCH v3 2/7] uaccess: Tell user_access_begin() if it's for a write or not

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"

Re: [Bug 206175] Fedora >= 5.4 kernels instantly freeze on boot without producing any display output

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.

Re: [git pull] drm fixes for 5.7-rc2

On Fri, Apr 17, 2020 at 9:24 PM Dave Airlie wrote: > > amdgpu: > - Fix a regression in a previous s/r fix Side note: if I hadn't been cc'd on the problem, I'd never have had a clue what s/r stood for. I'd have assumed that it's some special amdgpu term. And the language in the actual commit

Re: [git pull] drm for 5.7-rc1

On Thu, Apr 2, 2020 at 1:33 PM Nathan Chancellor wrote: > > This fixes it but I am not sure if it is proper or not (could be > problematic if CONFIG_PHYS_ADDR_T_64BIT is set but > CONFIG_ARCH_DMA_ADDR_T_64BIT is not, not sure if that is possible) so I > figured I'd report it and let you guys deal

Re: [PATCH] drm/legacy: Fix type for drm_local_map.offset

On Fri, Apr 3, 2020 at 1:29 AM Daniel Vetter wrote: > > > Tested-by: Nathan Chancellor # build > > This works too, missed it when replying to Linus > > Reviewed-by: Daniel Vetter > > Linus I guess this one is better, but like I explained it really > doesn't matter what we do with drm legacy

Re: [PATCH 00/16] x86, crypto: remove always-defined CONFIG_AS_* and cosolidate Kconfig/Makefiles

On Tue, Mar 24, 2020 at 1:49 AM Masahiro Yamada wrote: > > If it is OK to queue this up to Kbuild tree, > I will send a pull request to Linus. Looks fine to me, assuming we didn't now get some confusion due to duplicate patches (I think Jason got his tree added to -next already). And yeah, that

Re: [git pull] drm fixes for 5.9-rc4

On Fri, Sep 4, 2020 at 2:51 PM Harald Arnesen wrote: > > Still doesn't work without the three reverts > (763fedd6a216, 9e0f9464e2ab, 7ac2d2536dfa)... So this didn't make rc4, but it's in my tree now. Harald, I'm assuming things work for you again now with the current git tree, but it is always

Re: [patch 00/13] preempt: Make preempt count unconditional

On Mon, Sep 14, 2020 at 11:24 PM Herbert Xu wrote: > > On Tue, Sep 15, 2020 at 09:20:59AM +0300, Ard Biesheuvel wrote: > > > > The documentation of kmap_atomic() states the following: > > > > * The use of kmap_atomic/kunmap_atomic is discouraged - kmap/kunmap > > * gives a more generic (and

Re: [patch 00/13] preempt: Make preempt count unconditional

On Tue, Sep 15, 2020 at 1:39 AM Thomas Gleixner wrote: > > OTOH, having a working 'preemptible()' or maybe better named > 'can_schedule()' check makes tons of sense to make decisions about > allocation modes or other things. No. I think that those kinds of decisions about actual behavior are

Re: [patch 00/13] preempt: Make preempt count unconditional

On Tue, Sep 15, 2020 at 12:24 AM Thomas Gleixner wrote: > > Alternatively we just make highmem a bit more expensive by making these > maps preemptible. RT is doing this for a long time and it's not that > horrible. Ack. In fact, I've wanted to start just removing kmap support entirely. At some

Re: [patch 00/13] preempt: Make preempt count unconditional

On Mon, Sep 14, 2020 at 1:45 PM Thomas Gleixner wrote: > > Recently merged code does: > > gfp = preemptible() ? GFP_KERNEL : GFP_ATOMIC; > > Looks obviously correct, except for the fact that preemptible() is > unconditionally false for CONFIF_PREEMPT_COUNT=n, i.e. all allocations in >

Re: [patch 00/13] preempt: Make preempt count unconditional

On Mon, Sep 14, 2020 at 3:24 PM Linus Torvalds wrote: > > Ard and Herbert added to participants: see > chacha20poly1305_crypt_sg_inplace(), which does > > flags = SG_MITER_TO_SG; > if (!preemptible()) > flags |= SG_MITER_ATOMIC; >

Re: [patch 00/13] preempt: Make preempt count unconditional

On Mon, Sep 14, 2020 at 2:55 PM Thomas Gleixner wrote: > > Yes it does generate better code, but I tried hard to spot a difference > in various metrics exposed by perf. It's all in the noise and I only > can spot a difference when the actual preemption check after the > decrement I'm somewhat

Re: [git pull] drm fixes for 5.9-rc4

On Thu, Sep 3, 2020 at 8:53 PM Dave Airlie wrote: > > Not much going on this week, nouveau has a display hw bug workaround, > amdgpu has some PM fixes and CIK regression fixes, one single radeon > PLL fix, and a couple of i915 display fixes. Any movement on the i915 relocation issue? I've only

Re: [git pull] drm next pull for 5.10-rc1

On Wed, Oct 14, 2020 at 6:33 PM Dave Airlie wrote: > > There are a bunch of conflicts but none of them seemed overly scary, > and sfr has provided resolutions for them all. I've put a tree up with > my merge results, so you can tell me I did it wrong here: >

Re: [git pull] drm next pull for 5.10-rc1

On Thu, Oct 15, 2020 at 10:51 AM Linus Torvalds wrote: > > Thanks, looks good to me [..] Uhhuh. I already pushed things out, but my clang build (which I don't do between each merge) shows a problem: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:650:8: w

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Mon, Sep 21, 2020 at 12:39 AM Thomas Gleixner wrote: > > If a task is migrated to a different CPU then the mapping address will > change which will explode in colourful ways. Heh. Right you are. Maybe we really *could* call this new kmap functionality something like "kmap_percpu()" (or

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Sat, Sep 19, 2020 at 2:50 AM Thomas Gleixner wrote: > > this provides a preemptible variant of kmap_atomic & related > interfaces. This is achieved by: Ack. This looks really nice, even apart from the new capability. The only thing I really reacted to is that the name doesn't make sense to

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Sat, Sep 19, 2020 at 10:39 AM Matthew Wilcox wrote: > > My concern with that is people might use kmap() and then pass the address > to a different task. So we need to audit the current users of kmap() > and convert any that do that into using vmap() instead. Ahh. Yes, I guess they might do

Re: [git pull] drm fixes for 5.7-rc8/final

On Thu, May 28, 2020 at 5:21 PM Dave Airlie wrote: > > Seems to have wound down nicely, a couple of i915 fixes, amdgpu fixes > and minor ingenic fixes. Dave, this doesn't even build. WTF? In drivers/gpu/drm/i915/gt/selftest_lrc.c, there's a engine_heartbeat_disable() function that takes two

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Sun, Sep 20, 2020 at 10:42 AM Linus Torvalds wrote: > > Yeah, that looks much easier to explain. Ack. Btw, one thing that might be a good idea at least initially is to add a check for p->kmap_ctrl.idx being zero at fork, exit and maybe syscall return time (but that last one m

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Sun, Sep 20, 2020 at 10:40 AM Thomas Gleixner wrote: > > I think the more obvious solution is to split the whole exercise: > > schedule() > prepare_switch() > unmap() > > switch_to() > > finish_switch() > map() Yeah, that looks much easier to explain. Ack.

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Sun, Sep 20, 2020 at 1:49 AM Thomas Gleixner wrote: > > Actually most usage sites of kmap atomic do not need page faults to be > disabled at all. Right. I think the pagefault disabling has (almost) nothing at all to do with the kmap() itself - it comes from the "atomic" part, not the "kmap"

Re: [patch 00/13] preempt: Make preempt count unconditional

On Tue, Sep 15, 2020 at 12:57 PM Thomas Gleixner wrote: > > You wish. I just found a 7 year old bug in a 10G network driver which > surely would have been found if people would enable debug configs and > not just run the crap on their PREEMPT_NONE, all debug off kernel. And > that driver is not

Re: [patch 00/13] preempt: Make preempt count unconditional

On Wed, Sep 16, 2020 at 8:29 AM Paul E. McKenney wrote: > > All fair, but some of us need to write code that must handle being > invoked from a wide variety of contexts. Note that I think that core functionality is different from random drivers. Of course core code can (and will) look at things

Re: [git pull] drm fixes for 5.8-rc8

On Tue, Jul 28, 2020 at 9:44 PM Dave Airlie wrote: > > If you feel this is too much I'm happy to respin with the > core/drm_fb_helper and nouveau fixes. we have one outstanding nouveau > regression fix, that I'll follow this up with in the next day or so > once Ben and James get it reviewed.

Re: [git pull] drm for 5.8-rc1

On Tue, Jun 2, 2020 at 2:21 PM Linus Torvalds wrote: > > Hmm. Some of them are due to your previous mis-merges. > > Your commit 937eea297e26 ("Merge tag 'amd-drm-next-5.8-2020-04-24' of > git://people.freedesktop.org/~agd5f/linux into drm-next") seems to > have mi

Re: [git pull] drm for 5.8-rc1

On Tue, Jun 2, 2020 at 2:21 PM Linus Torvalds wrote: > > I'm still working through the rest of the merge, so far that was the > only one that made me go "Whaa?". Hmm. I'm also ending up effectively reverting the drm commit b28ad7deb2f2 ("drm/tidss: Use simple

Re: [git pull] drm for 5.8-rc1

On Mon, Jun 1, 2020 at 11:06 PM Dave Airlie wrote: > > I've pushed a merged by me tree here, which I think gets them all > correct, but please let me know if you think different. > https://cgit.freedesktop.org/~airlied/linux/log/?h=drm-5.8-merged Ok, I get the same result, except my resolution

Re: [git pull] drm for 5.8-rc1

On Mon, Jun 1, 2020 at 11:06 PM Dave Airlie wrote: > > This tree is a bit conflicty, the i915 ones are probably the hairy > ones, but amdgpu has a bunch as well, along with smattering of others. Hmm. Some of them are due to your previous mis-merges. Your commit 937eea297e26 ("Merge tag

Re: [git pull] drm fixes for 5.11-rc1

On Wed, Dec 23, 2020 at 6:29 PM Dave Airlie wrote: > > Xmas eve pull request present. Just some fixes that trickled in this > past week. Mostly amdgpu fixes, with a dma-buf/mips build fix and some > misc komeda fixes. Well, I already pulled and pushed out my merge, but only noticed afterwards

Re: [git pull] drm for 5.11-rc1

On Mon, Dec 14, 2020 at 2:29 PM Alex Deucher wrote: > > The relevant fixes are: Ok, I can confirm that applying those two patches gets my workstation working properly again. Would it be possible to get those submitted properly (or I can just take them as-is, but would like to get a "please just

<    1   2   3   4   5   6   7   8   >