Previously steam_open.cocci was treating only wait_event_.* - e.g.
wait_event_interruptible - as a blocking operation. However e.g.
wait_for_completion_interruptible is also blocking, and so from this
point of view it would be more logical to treat all wait_.* as a
blocking point.
The logic of this change actually came up for real when
drivers/pci/switch/switchtec.c changed from using
wait_event_interruptible to wait_for_completion_interruptible:
https://lore.kernel.org/linux-pci/
20190413170056.GA11293@deco.navytux.spb.ru/
https://lore.kernel.org/linux-pci/
20190415145456.GA15280@deco.navytux.spb.ru/
https://lore.kernel.org/linux-pci/
20190415154102.GB17661@deco.navytux.spb.ru/
For a driver that uses nonseekable_open with read/write having stream
semantic and read also calling e.g. wait_for_completion_interruptible,
running stream_open.cocci before this patch would produce:
WARNING: <driver>_fops: .read() and .write() have stream semantic; safe to change nonseekable_open -> stream_open.
while after this patch it will report:
ERROR: <driver>_fops: .read() can deadlock .write(); change nonseekable_open -> stream_open to fix.
Signed-off-by: Kirill Smelkov <kirr@nexedi.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
// a function that blocks
@ blocks @
identifier block_f;
-identifier wait_event =~ "^wait_event_.*";
+identifier wait =~ "^wait_.*";
@@
block_f(...) {
... when exists
- wait_event(...)
+ wait(...)
... when exists
}
// XXX currently reader_blocks supports only direct and 1-level indirect cases.
@ reader_blocks_direct @
identifier stream_reader.readstream;
-identifier wait_event =~ "^wait_event_.*";
+identifier wait =~ "^wait_.*";
@@
readstream(...)
{
... when exists
- wait_event(...)
+ wait(...)
... when exists
}