linux-kernel - [QUESTION] I need advice for writing .suspend/.resume functions

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <200710110513.10753.maximlevitsky@gmail.com>
Date:	Thu, 11 Oct 2007 05:13:10 +0200
From:	Maxim Levitsky <maximlevitsky@...il.com>
To:	linux-kernel@...r.kernel.org
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>, Pavel Machek <pavel@....cz>
Subject: [QUESTION] I need advice for writing .suspend/.resume functions

Hi,

I have few questions about .suspend()/.resume() driver functions and how best to write them.

I have written a support for suspend/resume for saa7134 v4l driver.
Now looking at code again and again, I found few problems, and I am seeking your advice how to fix them.

First of all the .suspend() function:

Looking at various drivers (including v4l ones) it seems that in general the function:

1) tells upper layers that it is suspended
2) saves the state of device
(generally there is nothing to save, since the driver maintains a copy of device state in memory)

3) disables the device (including DMA)
4) does usual pci_save_state+pci_set_power_state(pci_dev, pci_choose_state(pci_dev, state))
(I am talking about pci devices of course)

But there is one problem that my .suspend() function have together with quite a lot of drivers:
It can race with IRQ handler. Suppose the handler is called just before .suspend(), and thus .suspend() literally 
pulls the hadware from that handler.

I was told that I should use synchronize_irq(), and it looks exactly like the solution.
But I was surprised to see that very few drivers use it in their .suspend() routines.

Another issue, even bigger happens during the resume:
Suppose the IRQ line is shared with some other device and it gets resumed first.
And my IRQ handler is called because of the other device.
Now my IRQ handler can't determine whenever the IRQ for the device, since the hardware is still powered off.

Probably I can fix the following issues doing this:

1) do free_irq() in .suspend(), and request_irq() in .resume
this solves both problems since free_irq()  calls synchronize_irq()
Few drivers do that this way. I would like to know if this is the right way.

2) Disable the card's IRQ register , then call synchronize_irq(), at that point I can be sure that no IRQ handler is running and will run
then set some per device flag say dev->insuspend

let IRQ handler check this flag, and bail out if set, so false interrupts are caught on resume
Probably not a good idea, since I didn't find such implementation in kernel

Best regards,
	Maxim levitsky

-
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/