On Sat, Oct 2, 2021 at 5:17 AM Steven Rostedt wrote:
>
> On Sat, 2 Oct 2021 03:17:29 -0700 (PDT)
> Hugh Dickins wrote:
>
> > Yes (though bisection doesn't work right on this one): the fix
>
> Interesting, as it appeared to be very reliable. But I didn't do the
> "try before / after" on the patch.
[ Adding the proper people to the cc. ]
On Thu, 14 Jul 2016, Larry Finger wrote:
>
> To anyone keeping track of regressions in kernel 4.7, I call your attention to
> https://bugs.freedesktop.org/show_bug.cgi?id=96675.
>
> This bug causes driver i915 to fail to connect to the display, and results
On Thu, Sep 12, 2019 at 12:51 PM Martin Wilck wrote:
>
> Is there an alternative to reverting aa56a292ce62 ("drm/i915/userptr:
> Acquire the page lock around set_page_dirty()")? And if we do, what
> would be the consequences? Would other patches need to be reverted,
> too?
Looking at that commit,
On Sun, Feb 27, 2022 at 1:54 PM Arnd Bergmann wrote:
>
> Since the differences between gnu99, gnu11 and gnu17 are fairly minimal
> and mainly impact warnings at the -Wpedantic level that the kernel
> never enables, the easiest way is to just leave out the -std=gnu89
> argument entirely, and rely o
On Sun, Feb 27, 2022 at 3:04 PM Alex Elder wrote:
>
> Glancing at the Greybus code, I don't believe there's any
> reason it needs to shift a negative value. Such warnings
> could be fixed by making certain variables unsigned, for
> example.
As mentioned in the original thread, making things unsi
On Mon, Feb 28, 2022 at 3:37 AM Arnd Bergmann wrote:
>
> I think the KBUILD_USERCFLAGS portion and the modpost.c fix for it
> make sense regardless of the -std=gnu11 change
I do think they make sense, but I want to note again that people doing
cross builds obviously use different tools for user b
On Mon, Feb 28, 2022 at 4:19 AM Christian König
wrote:
>
> I don't think that using the extra variable makes the code in any way
> more reliable or easier to read.
So I think the next step is to do the attached patch (which requires
that "-std=gnu11" that was discussed in the original thread).
T
On Mon, Feb 28, 2022 at 11:56 AM Linus Torvalds
wrote:
>
> I do wish we could actually poison the 'pos' value after the loop
> somehow - but clearly the "might be uninitialized" I was hoping for
> isn't the way to do it.
Side note: we do need *some* way to d
On Mon, Feb 28, 2022 at 12:03 PM Linus Torvalds
wrote:
>
> Side note: we do need *some* way to do it.
Ooh.
This patch is a work of art.
And I mean that in the worst possible way.
We can do
typeof(pos) pos
in the 'for ()' loop, and never use __iter at all.
That means
On Mon, Feb 28, 2022 at 12:10 PM Linus Torvalds
wrote:
>
> We can do
>
> typeof(pos) pos
>
> in the 'for ()' loop, and never use __iter at all.
>
> That means that inside the for-loop, we use a _different_ 'pos' than outside.
The thing that ma
On Mon, Feb 28, 2022 at 12:16 PM Matthew Wilcox wrote:
>
> Then we can never use -Wshadow ;-( I'd love to be able to turn it on;
> it catches real bugs.
Oh, we already can never use -Wshadow regardless of things like this.
That bridge hasn't just been burned, it never existed in the first
place.
On Mon, Feb 28, 2022 at 12:29 PM Johannes Berg
wrote:
>
> If we're willing to change the API for the macro, we could do
>
> list_for_each_entry(type, pos, head, member)
>
> and then actually take advantage of -Wshadow?
See my reply to Willy. There is no way -Wshadow will ever happen.
I conside
On Mon, Feb 28, 2022 at 1:47 PM Jakob Koschel wrote:
>
> The goal of this is to get compiler warnings right? This would indeed be
> great.
Yes, so I don't mind having a one-time patch that has been gathered
using some automated checker tool, but I don't think that works from a
long-term maintena
On Mon, Feb 28, 2022 at 3:26 PM Matthew Wilcox wrote:
>
> #define ___PASTE(a, b) a##b
> #define __PASTE(a, b) ___PASTE(a, b)
> #define _min(a, b, u) ({ \
Yeah, except that's ugly beyond belief, plus it's literally not what
we do in the kernel.
Really. The "-Wshadow doesn't work on the k
On Mon, Feb 28, 2022 at 4:38 PM Segher Boessenkool
wrote:
>
> In C its scope is the rest of the declaration and the entire loop, not
> anything after it. This was the same in C++98 already, btw (but in
> pre-standard versions of C++ things were like you remember, yes, and it
> was painful).
Yeah
On Mon, Feb 28, 2022 at 4:45 PM Linus Torvalds
wrote:
>
> Yeah, except that's ugly beyond belief, plus it's literally not what
> we do in the kernel.
(Of course, I probably shouldn't have used 'min()' as an example,
because that is actually one of the few plac
On Tue, Mar 1, 2022 at 10:14 AM Kees Cook wrote:
>
> The first big glitch with -Wshadow was with shadowed global variables.
> GCC 4.8 fixed that, but it still yells about shadowed functions. What
> _almost_ works is -Wshadow=local.
Heh. Yeah, I just have long memories of "-Wshadow was a disaster"
On Mon, Feb 28, 2022 at 2:29 PM James Bottomley
wrote:
>
> However, if the desire is really to poison the loop variable then we
> can do
>
> #define list_for_each_entry(pos, head, member) \
> for (pos = list_first_entry(head, typeof(*pos), member);\
>
On Tue, Mar 1, 2022 at 11:06 AM Linus Torvalds
wrote:
>
> So instead of that simple "if (!entry)", we'd effectively have to
> continue to use something that still works with the old world order
> (ie that "if (list_entry_is_head())" model).
Just to prove my
So looking at this patch, I really reacted to the fact that quite
often the "use outside the loop" case is all kinds of just plain
unnecessary, but _used_ to be a convenience feature.
I'll just quote the first chunk in it's entirely as an example - not
because I think this chunk is particularly im
On Tue, Mar 1, 2022 at 2:58 PM David Laight wrote:
>
> Can it be resolved by making:
> #define list_entry_is_head(pos, head, member) ((pos) == NULL)
> and double-checking that it isn't used anywhere else (except in
> the list macros themselves).
Well, yes, except for the fact that then the name i
On Tue, Mar 1, 2022 at 3:19 PM David Laight wrote:
>
> Having said that there are so few users of list_entry_is_head()
> it is reasonable to generate two new names.
Well, the problem is that the users of list_entry_is_head() may be few
- but there are a number of _other_ ways to check "was that t
On Wed, Mar 2, 2022 at 12:07 PM Kees Cook wrote:
>
> I've long wanted to change kfree() to explicitly set pointers to NULL on
> free. https://github.com/KSPP/linux/issues/87
We've had this discussion with the gcc people in the past, and gcc
actually has some support for it, but it's sadly tied to
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
On Fri, Apr 3, 2020 at 12:21 AM Christophe Leroy
wrote:
>
> Now we have user_read_access_begin() and user_write_access_begin()
> in addition to user_access_begin().
I realize Al asked for this, but I don't think it really adds anything
to the series.
The "full" makes the names longer, but not re
On Tue, Apr 7, 2020 at 12:48 AM Pavel Machek wrote:
>
> >
> > Beyond the fix already submitted?
>
> I did not get that one, can I have a pointer?
What's the status of this one?
I'm assuming the fix is commit 721017cf4bd8 ("drm/i915/gem: Ignore
readonly failures when updating relics"), but didn't
On Mon, Apr 20, 2020 at 7:49 PM Al Viro wrote:
>
> The only source I'd been able to find speaks of >= 60 cycles
> (and possibly much more) for non-pipelined coprocessor instructions;
> the list of such does contain loads and stores to a bunch of registers.
> However, the register in questi
On Thu, Jan 14, 2021 at 2:01 PM Steven Rostedt wrote:
>
> Thanks, I take it, it will be going into mainline soon.
Just got merged - it might be a good idea to verify that your problem is solved.
Linus
___
Intel-gfx mailing list
Intel-gfx@li
Adding the right people.
It seems that the three commits that needed reverting are
f885056a48cc ("mm: simplify swapdev_block")
3e3126cf2a6d ("mm: only make map_swap_entry available for CONFIG_HIBERNATION")
48d15436fde6 ("mm: remove get_swap_bio")
and while they look very harmless to me, le
On Tue, Mar 2, 2021 at 3:38 PM Dave Airlie wrote:
>
> Looks like Jens saw it at least, he posted this on twitter a few mins
> ago so I assume it'll be incoming soon.
>
> https://git.kernel.dk/cgit/linux-block/commit/?h=swap-fix
Ahh. You use a swap file. This might be the same thing that I think
t
On Tue, Mar 2, 2021 at 4:36 PM Jens Axboe wrote:
>
> Or if you want a pull, just let me know. Have another misc patch to
> flush out anyway that doesn't belong in any of my usual branches.
Ok, if you have something else pending anyway, let's do that. Send me
the pull request, and I'll take it asa
Ok, slightly delayed by dinner, but commit caf6912f3f4a ("swap: fix
swapfile read/write offset") is out in my tree now.
Dave - can you check that the current -git works for your CI people?
Thanks,
Linus
On Tue, Mar 2, 2021 at 5:18 PM Jens Axboe wrote:
>
> On 3/2/2
On Tue, Nov 3, 2020 at 2:33 AM Thomas Gleixner wrote:
>
> +static inline void *kmap(struct page *page)
> +{
> + void *addr;
> +
> + might_sleep();
> + if (!PageHighMem(page))
> + addr = page_address(page);
> + else
> + addr = kmap_high(page);
> +
On Wed, Jul 29, 2020 at 5:24 AM Daniel Vetter wrote:
>
> Do we have a access_ok_array or so? Instead of duplicating overflow checks
> everywhere and getting it all wrong ...
I really really think you should get away from access_ok() entirely.
Please just get rid of it, and use "copy_from_user()"
Ping on this?
The code disassembles to
24: 8b 85 d0 fd ff ffmov-0x230(%ebp),%eax
2a:* c7 03 01 00 40 10movl $0x1041,(%ebx) <-- trapping instruction
30: 89 43 04 mov%eax,0x4(%ebx)
33: 8b 85 b4 fd ff ffmov-0x24c(%ebp),%eax
39: 89 43 08
On Tue, Aug 18, 2020 at 6:13 PM Dave Airlie wrote:
>
> I think there's been some discussion about reverting that change for
> other reasons, but it's quite likely the culprit.
Hmm. It reverts cleanly, but the end result doesn't work, because of
other changes.
Reverting all of
763fedd6a216 ("
On Thu, Aug 20, 2020 at 2:23 AM Pavel Machek wrote:
>
> Yes, it seems they make things work. (Chris asked for new patch to be
> tested, so I am switching to his kernel, but it survived longer than
> it usually does.)
Ok, so at worst we know how to solve it, at best the reverts won't be
needed bec
On Fri, Aug 21, 2020 at 1:50 AM Chris Wilson wrote:
>
> Since synchronising the PTE after assignment is a manual step, use the
> newly exported interface to flush the PTE after assigning via
> alloc_vm_area().
This commit message doesn't make much sense to me.
Are you talking about synchronizing
On Fri, Aug 21, 2020 at 5:38 AM Joerg Roedel wrote:
>
> From: Joerg Roedel
>
> The __apply_to_page_range() function is also used to change and/or
> allocate page-table pages in the vmalloc area of the address space.
> Make sure these changes get synchronized to other page-tables in the
> system b
On Tue, Aug 25, 2020 at 9:32 AM Harald Arnesen wrote:
>
> > For posterity, I'm told the fix is [1].
> >
> > [1]
> > https://lore.kernel.org/intel-gfx/20200821123746.16904-1-j...@8bytes.org/
>
> Doesn't fix it for me. As soon as I start XFCE, the mouse and keyboard
> freeezes. I can still ssh into
On Wed, Aug 26, 2020 at 2:30 AM Harald Arnesen wrote:
>
> Somehow related to lightdm or xfce4? However, it is a regression, since
> kernel 5.8 works.
Yeah, apparently there's something else wrong with the relocation changes too.
That said, does that patch at
https://lore.kernel.org/intel-gfx/
On Wed, Aug 26, 2020 at 1:53 PM Harald Arnesen wrote:
>
> It's a Thinkpad T520.
Oh, so this is a 64-bit machine? Yeah, that patch to flush vmalloc
ranges won't make any difference on x86-64.
Or are you for some reason running a 32-bit kernel on that thing? Have
you tried building a 64-bit one (u
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
> tha
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 mor
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;
>
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 cach
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 p
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
alwa
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
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 su
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 me
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 th
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" pa
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.
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
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 maybe
Let's add in some of the i915 people and list.
Everything quoted below for the new participants.
Linus
On Mon, Feb 24, 2020 at 2:52 AM Jörg Otte wrote:
>
> In v5.6-rcx I sporadically see a hanging GPU.
>
> [ 640.919302] i915 :00:02.0: Resetting chip for stopped heartbeat on r
On Thu, Dec 14, 2017 at 6:50 AM, Daniel Vetter wrote:
>
> Imo that's enough that I figured better not delay until Dave is back.
> Linus, can you pls apply?
Pulled.
Linus
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.f
On Sun, Dec 17, 2017 at 11:11 PM, Daniel Vetter wrote:
>
> This didn't seem to have made it into -rc4. Anything needed to get it
> going?
Do you actually see the problem in -rc4?
Because we ended up removing the cross-release checking due to other
developers complaining. It seemed to need a lot
On Sun, Oct 28, 2018 at 10:24 AM Kees Cook wrote:
>
> Please pull these VLA removal changes for v4.20-rc1.
Pulled,
Linus
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-
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 SLAB_TY
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
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 di
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 just
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_
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
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
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
__
On Thu, Nov 19, 2015 at 8:07 PM, Dave Airlie wrote:
>
> core: Atomic fixes and Atomic helper fixes
> i915: Revert for the backlight regression along with a bunch of fixes.
So I have no idea if the GPU updates are my problem, but my main
desktop machine has been hanging silently a few times lately
On Sun, Nov 29, 2015 at 11:33 PM, Daniel Vetter wrote:
>
> Yeah I just hunted down a test infrastructure failure on my Haswell the
> past few days with various loads and output configs. Seemed very happy.
> And not aware of anything else blowing up (bdw/skl would be less
> surprising).
So I'm cur
On Thu, Mar 3, 2016 at 8:53 AM, Bjorn Helgaas wrote:
> The purpose of this series is to:
> [ .. ]
The patches look ok to me and seem to make sense.
Of course, let's see what they break. Hopefully nothing, but any time
the PCI resource code changes I get a bit worried. PTSD, I guess.
On Fri, Mar 11, 2016 at 4:49 PM, Andy Lutomirski wrote:
>
> FWIW, if I disable all the checks in pci_get_rom_size, I learn that my
> video ROM consists entirely of 0xff bytes. Maybe there just isn't a
> ROM shadow on my laptop.
I think most laptops end up having the graphics ROM be part of the
r
This isn't new, but I thought I'd report it since it doesn't seem to
get fixed on its own..
[drm] Initialized i915 1.6.0 20161121 for :00:02.0 on minor 0
[ cut here ]
WARNING: CPU: 1 PID: 130 at drivers/gpu/drm/i915/intel_dp.c:4018
intel_dp_check_link_status+0x1db
On Tue, Dec 13, 2016 at 11:54 AM, Daniel Vetter wrote:
>
> Feel free to apply directly in case it annoys too much and you don't
> want to wait for your presents ;-)
I'll wait for the proper unboxing of presents. Once I've rattled them
and know what to expect, I can be very patient.
thing
there looks very obvious.
And once again, I'd like to note that other users of
i915_gem_object_to_ggtt() do seem to check for a NULL vma, while
intel_unpin_fb_obj() simply passes any potential NULL vma to
i915_vma_unpin_fence().
Guys?
Linus
On Sun, Jan 8, 2017
On Tue, Jan 31, 2017 at 1:21 AM, Maarten Lankhorst
wrote:
>
> This is marked for rc6 because it seems the issue is triggerable on
> mainline and resulting in an oops.
So I did apply my obvious "avoid the oops and just warn about it"
patch: commit 39cb2c9a316e ("drm/i915: Check for NULL i915_vma i
On Wed, Dec 23, 2015 at 2:40 AM, Jani Nikula wrote:
>
> Hi Dave (and/or Linus, depending on the new arrival and eggnog
> schedules) -
I'll pull it directly. Dave just sent me his pending drm fixes, he may
or may not be around any more, it's already christmas eve down under.
Linus
___
On Wed, Dec 23, 2015 at 2:40 AM, Jani Nikula wrote:
>
>
> git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-12-23
Btw, since you're already using tags, mind using *signed* tags
instead? It's just good housekeeping..
Linus
_
On Jan 3, 2016 18:06, "Dave Airlie" wrote:
>
> can you pull this directly, baby has arrived, but I'm not back at work
yet.
Assumed so, and already did. It's in rc8,
Linus
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.free
So there's something wrong with the memory allocation changes since
4.11, which seem to be mostly credited to Chris Wilson.
In particular, I got this earlier today:
Xorg: page allocation failure: order:0,
mode:0x14210d2(GFP_HIGHUSER|__GFP_NORETRY|__GFP_RECLAIMABLE),
nodemask=(null)
and then so
On Mon, Oct 30, 2017 at 12:00 AM, Fengguang Wu wrote:
> CC intel-gfx.
Thanks, these are all interesting (even if some of them seem to be
from random kernels).
Fengguang, is this a new script that you started running? Because I'm
*hoping* it's not that rc6 suddenly seems so flaky, and it's really
On Thu, Jan 5, 2017 at 3:19 AM, Jani Nikula wrote:
>
> Hi Dave, or Linus if Dave's on vacation, I'm a bit unsure,
I'm going to ignore this on the assumption that Dave is around. But if
nothing happens for a few days, ping me again and I'll pull it
directly. Ok?
Linus
__
This has so far only happened once, so I don't know how repeatable it
is, but here goes..
My nice stable XPS13 just oopsed on shutdown. It is possibly related
to the X server SIGSEGV'ing too, although honestly, I am not sure
which caused which. Maybe the kernel oops caused the X problem. They
defi
I didn't notice this until now, because my laptop still *works*, but
there seems to be a locking issue wth the drm connector list in the
i915 driver init path.
See appended call trace.
I don't know what part of the trace is supposed to get the mode_config
locks - maybe it's the generic drm kms he
On Wed, Jan 25, 2017 at 12:13 PM, Linus Torvalds
wrote:
>
> Is nobody else seeing this? This is on my bog-standard intel laptop
> (Dell XPS13 as you can see in the warning).
Actually, it's on my desktop as well. So I'm assuming pretty much any
i915 config shows it. It's b
On Wed, 25 Oct 2023 at 02:01, Christian Brauner wrote:
>
> rcu_read_lock();
> - file = get_file_rcu(&i915->gem.mmap_singleton);
> + file = get_file_rcu_once(&i915->gem.mmap_singleton);
> rcu_read_unlock();
> if (file)
> return file;
Honestly, th
On Wed, 25 Oct 2023 at 10:36, Christian Brauner wrote:
>
> I did think that the loop didn't really matter for this case but since
> it seemingly does paper over the weird semantics here let's drop it.
> Anyway, pushed to:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git/commit/?h=vf
On Sun, 19 Nov 2023 at 23:11, kernel test robot wrote:
>
> kernel test robot noticed a -2.9% regression of will-it-scale.per_thread_ops
> on:
>
> commit: 0ede61d8589cc2d93aa78230d74ac58b5b8d0244 ("file: convert to
> SLAB_TYPESAFE_BY_RCU")
Ok, so __fget_light() is one of our more performance-cri
On Sun, 26 Nov 2023 at 12:23, Linus Torvalds
wrote:
>
> IOW, I might have messed up some "trivial cleanup" when prepping for
> sending it out...
Bah. Famous last words. One of the "trivial cleanups" made the code
more "obvious" by renaming the nospec mask a
On Mon, 27 Nov 2023 at 02:27, Christian Brauner wrote:
>
> So I've picked up your patch (vfs.misc). It's clever alright so thanks
> for the comments in there otherwise I would've stared at this for far
> too long.
Note that I should probably have commented on one other thing: that
whole "just loa
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 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, 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 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 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 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
1 - 100 of 164 matches
Mail list logo
