linux-kernel - Re: [PATCH] drm/nouveau: Remove interrupt handler around suspend/resume

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 28 Apr 2011 06:48:56 -0600
From:	Alex Williamson <alex.williamson@...hat.com>
To:	Dave Airlie <airlied@...hat.com>
Cc:	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/nouveau: Remove interrupt handler around
 suspend/resume

On Thu, 2011-04-28 at 15:54 +1000, Dave Airlie wrote:
> On Wed, 2011-04-27 at 23:20 -0600, Alex Williamson wrote:
> > We're often using a shared interrupt line for nouveau, so we have
> > to be prepared that it could be called at any point in time.  If
> > we've suspended the device via vga switcheroo and get a stray
> > interrupt on the line from another device, we'll read back -1 from
> > the device and head down all sorts of strange paths, most of which
> > eventually lock the system.
> > 
> > On my system (Asus UL30VT) the interrupt line is shared with USB.
> > Attempting to disable the USB bluetooth device seems to trigger
> > a stray interrupt that ends up in nv04_fifo_isr() where we
> > eventually hit the "PFIFO still angry after 100 spins, halt",
> > which kills the system.
> > 
> > Using free_irq/request_irq around the suspend seems to be a
> > reliable fix.  Attempting to flag the device state in
> > nouvea_irq_handler(), similar to the intel_lid_notify() fix
> > is too racy since we can power off the device as an interrupt
> > is being processed.
> 
> The actual solution is to check if we read back all Fs and return from
> the irq handler. Robust irq handlers are generally considered a good
> idea esp around race conditions at suspend/resume time.

The trouble I found in trying to do that is that we can still race,
having the device be disabled while and interrupt is still being
processed.  It seems impractical to check every device read through the
interrupt path for -1 and back out.  Adding a spinlock to the interrupt
handler seemed expensive, while this has no additional runtime interrupt
overhead.  Thanks,

Alex



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/