On Mon, May 27, 2013 at 12:52:00PM +0200, Maarten Lankhorst wrote:
> The reason ttm needed it was because there was another lock that interacted
> with the ctx lock in a weird way. The ww lock it was using was inverted with
> another
> lock, so it had to grab that lock first, perform a trylock on
On Sun, 2011-08-28 at 07:36 +0200, Borislav Petkov wrote:
> > > With CONFIG_DRM_RADEON=y, the microcode is needed before it can be
> > > loaded from userspace, so it needs to be built into the kernel as well.
> >
> > How should I do that? I've tried to set all "m"s to "y" in .config and
> > still
On Mon, 2011-08-29 at 19:17 +0200, Borislav Petkov wrote:
> On Mon, Aug 29, 2011 at 12:10:45PM -0400, Arnaud Lacombe wrote:
> > do you want something ala:
> >
> > config EXTRA_FIRMWARE
> > string
> > default ""
> > append "FOO" if BAR
> > append "FOZ" if BAZ
> >
> > or maybe a new
On Mon, 2011-08-29 at 19:21 +0200, Borislav Petkov wrote:
>
> Yeah, sounds much better than Kconfig actually aiding and abetting
> firmware blobs in the kernel and users needing to do stuff.
>
I would very much like to retain that option.. and having to manually
figure out what blob goes with wha
On Mon, 2011-08-29 at 19:50 +0200, Peter Zijlstra wrote:
> On Mon, 2011-08-29 at 19:17 +0200, Borislav Petkov wrote:
> > On Mon, Aug 29, 2011 at 12:10:45PM -0400, Arnaud Lacombe wrote:
> > > do you want something ala:
> > >
> > > config EXTRA_FIRMWAR
On Mon, 2011-08-29 at 20:09 +0200, Peter Zijlstra wrote:
> > That would suck, suppose this radeon thing is the only console you've
> > got (ppc64/sparc64 don't have text mode iirc) and userspace doesn't come
> > up?
>
> Same is true for NICs and netcon
On Mon, 2011-08-29 at 23:08 -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 29 Aug 2011, Borislav Petkov wrote:
> > So, hypothetically speaking, hpa suggested then that we could pass
> > firmware blobs over the linked list setup_data thing in the real-mode
> > kernel header and parse_setup_data
On Tue, 2012-08-21 at 10:15 +0100, Alan Cox wrote:
> > So after much tracing with direct netconsole writes (printks
> > under console_lock not so useful), I think I found the race.
>
> Direct netconsole write would be a useful patch to have mainline I think
> 8)
could we make that use the earlyp
On Tue, 2012-08-21 at 16:40 +1000, Dave Airlie wrote:
> So after much tracing with direct netconsole writes (printks
> under console_lock not so useful)
I always use earlyprintk on serial..
--
Live Security Virtual Conf
On Sun, 2011-08-28 at 07:36 +0200, Borislav Petkov wrote:
> > > With CONFIG_DRM_RADEON=y, the microcode is needed before it can be
> > > loaded from userspace, so it needs to be built into the kernel as well.
> >
> > How should I do that? I've tried to set all "m"s to "y" in .config and
> > still
On Mon, 2011-08-29 at 19:17 +0200, Borislav Petkov wrote:
> On Mon, Aug 29, 2011 at 12:10:45PM -0400, Arnaud Lacombe wrote:
> > do you want something ala:
> >
> > config EXTRA_FIRMWARE
> > string
> > default ""
> > append "FOO" if BAR
> > append "FOZ" if BAZ
> >
> > or maybe a new
On Mon, 2011-08-29 at 19:21 +0200, Borislav Petkov wrote:
>
> Yeah, sounds much better than Kconfig actually aiding and abetting
> firmware blobs in the kernel and users needing to do stuff.
>
I would very much like to retain that option.. and having to manually
figure out what blob goes with wha
On Mon, 2011-08-29 at 19:50 +0200, Peter Zijlstra wrote:
> On Mon, 2011-08-29 at 19:17 +0200, Borislav Petkov wrote:
> > On Mon, Aug 29, 2011 at 12:10:45PM -0400, Arnaud Lacombe wrote:
> > > do you want something ala:
> > >
> > > config EXTRA_FIRMWAR
On Mon, 2011-08-29 at 20:09 +0200, Peter Zijlstra wrote:
> > That would suck, suppose this radeon thing is the only console you've
> > got (ppc64/sparc64 don't have text mode iirc) and userspace doesn't come
> > up?
>
> Same is true for NICs and netcon
On Mon, 2011-08-29 at 23:08 -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 29 Aug 2011, Borislav Petkov wrote:
> > So, hypothetically speaking, hpa suggested then that we could pass
> > firmware blobs over the linked list setup_data thing in the real-mode
> > kernel header and parse_setup_data
On Mon, 2012-09-24 at 14:17 +0200, Peter Zijlstra wrote:
> On Tue, 2012-09-18 at 01:03 +0200, Daniel Vetter wrote:
> > - In the printk code there's a special trylock, only used to kick off
> > the logbuffer printk'ing in console_unlock. But all that happens
> >
On Mon, 2012-09-24 at 14:54 +0200, Daniel Vetter wrote:
> I've read through the patches and I'm hoping you don't volunteer me to
> pick these up ... ;-)
Worth a try, right? :-)
> But there doesn't seem to be anything that would
> get worse through this lockdep annotation patch, right?
No indee
On Tue, 2012-09-18 at 01:03 +0200, Daniel Vetter wrote:
> - In the printk code there's a special trylock, only used to kick off
> the logbuffer printk'ing in console_unlock. But all that happens
> while lockdep is disable (since printk does a few other evil
> tricks). So no issue there, eithe
On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
> +struct ticket_mutex {
> + struct mutex base;
> + atomic_long_t reservation_id;
> +};
I'm not sure this is a good name, esp. due to the potential confusion
vs the ticket spinlocks we have.
On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
> +Reservation type mutexes
> +struct ticket_mutex {
> +extern int __must_check _mutex_reserve_lock(struct ticket_mutex *lock,
That's two different names and two different forms of one (for a total
of 3 variants) for the same scheme.
F
On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
> +The algorithm that TTM came up with for dealing with this problem is
> +quite simple. For each group of buffers (execbuf) that need to be
> +locked, the caller would be assigned a unique reservation_id, from a
> +global counter. In ca
On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
> +mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow:
> + Similar to mutex_reserve_lock, except it won't backoff with
> -EAGAIN.
> + This is useful when mutex_reserve_lock failed with -EAGAIN, and you
> + unreserved all reservati
On Tue, 2013-04-02 at 16:57 +0200, Maarten Lankhorst wrote:
> Hey,
>
> Thanks for reviewing.
Only partway through so far :-)
> Op 02-04-13 13:00, Peter Zijlstra schreef:
> > On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
> >> +Reservation type mutexe
I'm sorry, this email ended up quite a bit longer than I had hoped for;
please bear with me.
On Tue, 2013-04-02 at 18:59 +0200, Peter Zijlstra wrote:
> struct ww_mutex; /* wound/wait */
>
> int mutex_wound_lock(struct ww_mutex *); /* returns -EDEADLK */
> int mutex
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
> Hm, I guess your aim with the TASK_DEADLOCK wakeup is to bound the
> wait
> times of older task.
No, imagine the following:
struct ww_mutex A, B;
struct mutex C;
task-O task-Y task-X
A
B
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
> The trick with the current code is that the oldest task
> will never see an -EAGAIN ever and hence is guaranteed to make forward
> progress. If the task is really unlucky though it might be forced to
> wait
> for a younger task for every ww_
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
> The thing is now that you're not expected to hold these locks for a
> long
> time - if you need to synchronously stall while holding a lock
> performance
> will go down the gutters anyway. And since most current
> gpus/co-processors
> still
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
> Another big reason for having a start/end marker like you've describe
> is
> lockdep support.
Yeah, I saw how you did that.. but there's other ways of making it work
too, you could for instance create a new validation state for this type
of
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
> I'm a bit confused about the different classes you're talking about.
> Since
> the ticket queue is currently a global counter there's only one class
> of
> ww_mutexes.
Right, so that's not something that's going to fly.. we need to support
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
> We've discussed this approach of using (rt-prio, age) instead of just
> age
> to determine the the "oldness" of a task for deadlock-breaking with
> -EAGAIN. The problem is that through PI boosting or normal rt-prio
> changes
> while tasks ar
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
> Well, it was a good read and I'm rather happy that we agree on the
> ww_ctx
> thing (whatever it's called in the end), even though we have slightly
> different reasons for it.
Yeah, I tried various weirdness to get out from under it, but th
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
> We do add some form of owner tracking by storing the reservation
> ticket
> of the current holder into every ww_mutex. So when task-Y in your
> above
> example tries to acquire lock A it notices that it's behind in the
> global
> queue and i
On Thu, 2013-04-04 at 18:56 +0200, Daniel Vetter wrote:
> On Thu, Apr 4, 2013 at 3:31 PM, Daniel Vetter wrote:
> >> In this case when O blocks Y isn't actually blocked, so our
> >> TASK_DEADLOCK wakeup doesn't actually achieve anything.
> >>
> >> This means we also have to track (task) state so th
On Tue, 2013-04-09 at 18:42 -0400, Steven Rostedt wrote:
> What about setting an age as soon as it starts the process
> of grabbing one of these locks? And it keeps the age until it
> successfully grabs and releases all the locks again. It wont reset if
> it
> had to drop the locks and start over.
On Wed, Feb 26, 2014 at 02:57:16PM +0100, Rafael J. Wysocki wrote:
> On Monday, February 24, 2014 05:24:00 PM Borislav Petkov wrote:
> > This started happening this morning after booting -rc4+tip, let's
> > add *everybody* to CC :-)
>
> What about -rc4 without tip?
The driver causing this is new
On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
> As a asides, my SNB and HSW desktops with 3.14-rc4 are totally unstable.
> They hang if I type make in my kernel tree. Whereas 3.14-rc3 is stable. I am
> not so sure this is all related to the uncore IMC support, though.
Unstable
On Thu, Feb 27, 2014 at 11:32:58AM +0100, Stephane Eranian wrote:
> On Thu, Feb 27, 2014 at 11:30 AM, Peter Zijlstra
> wrote:
> > On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
> >> As a asides, my SNB and HSW desktops with 3.14-rc4 are totally unstable.
> Are there any issues left? I included the patch you wrote for injecting
> -EDEADLK too
> in my tree. The overwhelming silence makes me think there are either none, or
> nobody cared enough to review it. :(
It didn't manage to reach my inbox it seems,.. I can only find a debug
patch in this thre
On Wed, May 22, 2013 at 01:47:42PM +0200, Maarten Lankhorst wrote:
> Op 22-05-13 13:37, Peter Zijlstra schreef:
> >> Are there any issues left? I included the patch you wrote for injecting
> >> -EDEADLK too
> >> in my tree. The overwhelming silence makes me think t
On Wed, May 22, 2013 at 01:18:14PM +0200, Maarten Lankhorst wrote:
Lacking the actual msg atm, I'm going to paste in here...
> Subject: [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3
> From: Maarten Lankhorst
>
> Changes since RFC patch v1:
> - Updated to use atomic_long inst
On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote:
> >> +- Functions to only acquire a single w/w mutex, which results in the
> >> exact same
> >> + semantics as a normal mutex. These functions have the _single postfix.
> > This is missing rationale.
> trylock_single is useful wh
On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote:
> >> +static inline void ww_acquire_init(struct ww_acquire_ctx *ctx,
> >> + struct ww_class *ww_class)
> >> +{
> >> + ctx->task = current;
> >> + do {
> >> + ctx->stamp = atomic_long_inc_return
On Wed, May 22, 2013 at 06:49:04PM +0200, Daniel Vetter wrote:
> - _slow functions can check whether all acquire locks have been
> released and whether the caller is indeed blocking on the contending
> lock. Not doing so could either result in needless spinning instead of
> blocking (when blocking
On Mon, May 27, 2013 at 10:26:39AM +0200, Maarten Lankhorst wrote:
> Op 27-05-13 10:00, Peter Zijlstra schreef:
> > On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote:
> >>>> +- Functions to only acquire a single w/w mutex, which results in the
> >>
On Mon, May 27, 2013 at 12:01:50PM +0200, Maarten Lankhorst wrote:
> > Again, early.. monday.. would a trylock, even if successful still need
> > the ctx?
> No ctx for trylock is supported. You can still do a trylock while
> holding a context, but the mutex won't be a part of the context.
> Normal
On Mon, May 27, 2013 at 12:52:00PM +0200, Maarten Lankhorst wrote:
> The reason ttm needed it was because there was another lock that interacted
> with the ctx lock in a weird way. The ww lock it was using was inverted with
> another
> lock, so it had to grab that lock first, perform a trylock on
So I've not yet went through the entire series; but I'm wondering if its
at all possible to re-use some of this work:
lkml.kernel.org/r/1428453299-19121-1-git-send-email-sukadev at
linux.vnet.ibm.com
That's for a Power8 HV call that can basically return an array of
values; which on a superficia
On Thu, May 07, 2015 at 03:15:43PM +0100, Robert Bragg wrote:
> I've changed the uapi for configuring the i915_oa specific attributes
> when calling perf_event_open(2) whereby instead of cramming lots of
> bitfields into the perf_event_attr config members, I'm now
> daisy-chaining a drm_i915_oa_ev
On Tue, Sep 29, 2015 at 03:39:03PM +0100, Robert Bragg wrote:
> - We're bridging two complex architectures
>
> To review this work I think it will be relevant to have a good
> general familiarity with Gen graphics (e.g. thinking about the OA
> unit's interaction with the command stream
On Fri, Oct 16, 2015 at 12:02:28PM +0200, Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
> > > - We may be making some technical compromises a.t.m for the sake of
> > > using perf.
> > >
> > > perf_event_open() requires events to either rel
On Tue, Jul 30, 2013 at 10:13:41AM +0200, Maarten Lankhorst wrote:
> The check needs to be for > 1, because ctx->acquired is already incremented.
> This will prevent ww_mutex_lock_slow from returning -EDEADLK and not locking
> the mutex. It caused a lot of false gpu lockups on radeon with
> CONFIG_
On Mon, Oct 14, 2024 at 01:20:34PM -0500, Lucas De Marchi wrote:
> On Mon, Oct 14, 2024 at 07:32:46PM +0200, Peter Zijlstra wrote:
> > I'm confused.. probably because I still don't have any clue about
> > drivers and the above isn't really telling me much either.
&g
On Wed, Oct 09, 2024 at 11:20:31AM +0200, Thomas Hellström wrote:
> When using mutex_acquire_nest() with a nest_lock, lockdep refcounts the
> number of acquired lockdep_maps of mutexes of the same class, and also
> keeps a pointer to the first acquired lockdep_map of a class. That pointer
> is then
On Tue, Oct 08, 2024 at 01:34:57PM -0500, Lucas De Marchi wrote:
> +static int parse_device(const char __user *ubuf, size_t size, u32 *instance)
> +{
> + char buf[16];
> + ssize_t len;
> +
> + if (size > sizeof(buf) - 1)
> + return -E2BIG;
> +
> + len = strncpy_from_user
On Mon, Oct 14, 2024 at 09:25:19PM +0200, Peter Zijlstra wrote:
> Let me ponder that a little bit.
So I did the thing on top of the get/put thing that would allow you to
get rid of the ->closed thing, and before I was finished I already hated
all of it :-(
The thing is, if you're g
On Wed, Oct 02, 2024 at 02:56:11PM +0200, Thomas Hellström wrote:
> When using mutex_acquire_nest() with a nest_lock, lockdep refcounts the
> number of acquired lockdep_maps of mutexes of the same class, and also
> keeps a pointer to the first acquired lockdep_map of a class. That pointer
> is then
On Fri, Oct 18, 2024 at 02:46:31PM -0500, Lucas De Marchi wrote:
> I will give this a try with i915 and/or xe.
Less horrible version here:
git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git
perf/pmu-unregister
I've just pushed it out to the robots, but it builds, passes perf test
On Tue, Oct 08, 2024 at 01:34:59PM -0500, Lucas De Marchi wrote:
> If a pmu is unregistered while there's an active event, perf will still
> access the pmu via event->pmu, even after the event is destroyed. This
> makes it difficult for drivers like i915 that can be unbound from the
> HW.
>
>
On Thu, Oct 31, 2024 at 12:07:42AM -0500, Lucas De Marchi wrote:
> On Wed, Oct 23, 2024 at 12:07:58AM -0500, Lucas De Marchi wrote:
> > On Tue, Oct 22, 2024 at 11:52:10PM +0200, Peter Zijlstra wrote:
> > > On Fri, Oct 18, 2024 at 02:46:31PM -0500, Lucas De Marchi wrote:
> >
201 - 259 of 259 matches
Mail list logo
