search for: 163f72e0

...ith this? > > Rusty. > > Sorry Rusty, I'm back as of today. I applied your patch series and did some testing... Removing a disk while reading from it mostly still ends up in hangs as of below: PID: 13 TASK: 163f8000 CPU: 0 COMMAND: "kworker/u128:1" #0 [163f72e0] __schedule at 6aa22c #1 [163f7428] io_schedule at 6aab6c #2 [163f7448] sleep_on_page at 22cbb2 #3 [163f7460] __wait_on_bit at 6ab394 #4 [163f74b0] wait_on_page_bit at 22cef4 #5 [163f7508] filemap_fdatawait_range at 22d0a6 #6 [163f75e8] filemap_write_and_wait at 22de62 #7 [163f7618] f...

...ith this? > > Rusty. > > Sorry Rusty, I'm back as of today. I applied your patch series and did some testing... Removing a disk while reading from it mostly still ends up in hangs as of below: PID: 13 TASK: 163f8000 CPU: 0 COMMAND: "kworker/u128:1" #0 [163f72e0] __schedule at 6aa22c #1 [163f7428] io_schedule at 6aab6c #2 [163f7448] sleep_on_page at 22cbb2 #3 [163f7460] __wait_on_bit at 6ab394 #4 [163f74b0] wait_on_page_bit at 22cef4 #5 [163f7508] filemap_fdatawait_range at 22d0a6 #6 [163f75e8] filemap_write_and_wait at 22de62 #7 [163f7618] f...

...Your previous patch did nothing in that path, which I suspect may leak memory. That may be acceptable given that this Shouldn't Happen (often). At this point, I ask Jens :) Cheers, Rusty. > > PID: 13 TASK: 163f8000 CPU: 0 COMMAND: "kworker/u128:1" > #0 [163f72e0] __schedule at 6aa22c > #1 [163f7428] io_schedule at 6aab6c > #2 [163f7448] sleep_on_page at 22cbb2 > #3 [163f7460] __wait_on_bit at 6ab394 > #4 [163f74b0] wait_on_page_bit at 22cef4 > #5 [163f7508] filemap_fdatawait_range at 22d0a6 > #6 [163f75e8] filemap_write_and_wa...

...this Shouldn't Happen (often). > > At this point, I ask Jens :) > waiting for requests (e.g. in-flight requests) in blk_cleanup_queue() that > Cheers, > Rusty. > >> >> PID: 13 TASK: 163f8000 CPU: 0 COMMAND: "kworker/u128:1" >> #0 [163f72e0] __schedule at 6aa22c >> #1 [163f7428] io_schedule at 6aab6c >> #2 [163f7448] sleep_on_page at 22cbb2 >> #3 [163f7460] __wait_on_bit at 6ab394 >> #4 [163f74b0] wait_on_page_bit at 22cef4 >> #5 [163f7508] filemap_fdatawait_range at 22d0a6 >> #6 [...

...this Shouldn't Happen (often). > > At this point, I ask Jens :) > waiting for requests (e.g. in-flight requests) in blk_cleanup_queue() that > Cheers, > Rusty. > >> >> PID: 13 TASK: 163f8000 CPU: 0 COMMAND: "kworker/u128:1" >> #0 [163f72e0] __schedule at 6aa22c >> #1 [163f7428] io_schedule at 6aab6c >> #2 [163f7448] sleep_on_page at 22cbb2 >> #3 [163f7460] __wait_on_bit at 6ab394 >> #4 [163f74b0] wait_on_page_bit at 22cef4 >> #5 [163f7508] filemap_fdatawait_range at 22d0a6 >> #6 [...

Hi, here is my v4 patch-set update to the v3 RFC submitted on Nov 27th. When an active virtio block device is hot-unplugged from a KVM guest, affected guest user applications are not aware of any errors that occur due to the lost device. This patch-set adds code to avoid further request queueing when a lost block device is detected, resulting in appropriate error info. Additionally a potential

Hi, here is my v4 patch-set update to the v3 RFC submitted on Nov 27th. When an active virtio block device is hot-unplugged from a KVM guest, affected guest user applications are not aware of any errors that occur due to the lost device. This patch-set adds code to avoid further request queueing when a lost block device is detected, resulting in appropriate error info. Additionally a potential