No need to check bio_alloc(GFP_NOIO, ) returns.

[thegreatgazoo]

It looks like bio_alloc(GFP_NOIO, ) will never return NULL:
https://lkml.org/lkml/2009/4/14/499

So there's no need for the error handling code in module/zfs/vdev_disk.c for NULL returns from bio_alloc(GFP_NOIO, ). Some assertions should suffice.

But it made me wonder whether GFP_NOIO is the right flag. I saw that GFP_NOIO was used due to a deadlock when a zvol is used for swap. It made sense. But on a system where ZFS is running, the ARC is most likely the best place to reclaim memory. With GFP_NOIO, would the arc_shrinker be called upon to free up memory? My understanding is that the ARC can free up cold buffers without doing any IO.

I'm interested because I'm troubleshooting a Lustre IO timeout where I saw:

z_ioctl_iss/0 S 0000000000000001 0 3996 2 0x00000080
ffff880079dc9e20 0000000000000046 ffff880079dc9da0 ffffffffa024aa46
ffff880079dc9de0 ffffc900192865f8 ffff880079a76000 0000000000000200
ffff8800730c8638 ffff880079dc9fd8 000000000000fbc8 ffff8800730c8638
Call Trace:
[<ffffffffa024aa46>] ? vdev_disk_io_start+0x156/0x1b0 [zfs]
[<ffffffffa013f686>] taskq_thread+0x3c6/0x3f0 [spl]

Likely it's really stuck in vdev_disk_io_flush() which is probably inlined. It seemed like the syncing txg is about to complete and a WRITE_FLUSH_FUA is to be issued after the uberblocks have been updated. There's also other threads waiting for the txg to be synced.
The only place it could get stuck in vdev_disk_io_flush() seemed to be in bio_alloc(), which indicated a deadlock under memory pressure.

The z_ioctl_iss thread got stuck there for more than a minute, which indicated that no memory was freed up during the wait.

[thegreatgazoo]

Actually the WRITE_FLUSH_FUA had been submitted and vdev_disk_io_start had returned, so txg_sync was likely stuck waiting for WRITE_FLUSH_FUA to complete. But it's relevant here.

[behlendorf]

@thegreatgazoo GFP_NOIO must be used in bio_alloc() otherwise bio_alloc() could enter the direct reclaim call path when memory is low. Since bio_alloc() can be called in the context of the txg_sync thread that would introduce a possible deadlock. Effectively the txg_sync thread could end up blocked in reclaim waiting on IO to be written which it is responsible for writing.

Do you have a full stack trace for where the z_ioctl_iss thread was stuck? Normally when you see a stack like you posted above it's just an idle taskq thread waiting to receive some work. For example,

cat /proc/582/stack 
[<ffffffffa0043b61>] taskq_thread+0x3c1/0x4b0 [spl]
[<ffffffff8108b96c>] kthread+0x8c/0xa0
[<ffffffff8166e3b4>] kernel_thread_helper+0x4/0x10