The 10/21/2020 16:07, Matthew Wilcox wrote: > On Wed, Oct 21, 2020 at 03:55:55PM +0300, Sergei Shtepa wrote: > > The 10/21/2020 14:44, Matthew Wilcox wrote: > > > I don't understand why O_DIRECT gets to bypass the block filter. Nor do > > > I understand why anybody would place a block filter on the swap device. > > > But if somebody did place a filter on the swap device, why should swap > > > be able to bypass the filter? > > > > Yes, intercepting the swap partition is absurd. But we can't guarantee > > that the filter won't intercept swap. > > > > Swap operation is related to the memory allocation logic. If a swap on > > the block device are accessed during memory allocation from filter, > > a deadlock occurs. We can allow filters to occasionally shoot off their > > feet, especially under high load. But I think it's better not to do it. > > We already have logic to prevent this in Linux. Filters need to > call memalloc_noio_save() while they might cause swap to happen and > memalloc_noio_restore() once it's safe for them to cause swap again. Yes, I looked at this function, it can really be useful for the filter. Then I don't need to enter the submit_bio_direct() function and the wait loop associated with the queue polling function blk_mq_poll() will have to be rewritten. > > > "directly access" - it is not O_DIRECT. This means (I think) direct > > reading from the device file, like "dd if=/dev/sda1". > > As for intercepting direct reading, I don't know how to do the right thing. > > > > The problem here is that in fs/block_dev.c in function __blkdev_direct_IO() > > uses the qc - value returned by the submit_bio() function. > > This value is used below when calling > > blk_poll(bdev_get_queue(dev), qc, true). > > The filter cannot return a meaningful value of the blk_qc_t type when > > intercepting a request, because at that time it does not know which queue > > the request will fall into. > > > > If function submit_bio() will always return BLK_QC_T_NONE - I think the > > algorithm of the __blk dev_direct_IO() will not work correctly. > > If we need to intercept direct access to a block device, we need to at > > least redo the __blkdev_direct_IO function, getting rid of blk_pool. > > I'm not sure it's necessary yet. > > This isn't part of the block layer that I'm familiar with, so I can't > help solve this problem, but allowing O_DIRECT to bypass the block filter > is a hole that needs to be fixed before these patches can be considered. I think there is no such problem, but I will check, of course. -- Sergei Shtepa Veeam Software developer.
