Jens Axboe writes: > On 2010-08-06 12:42, Dmitry Monakhov wrote: >> Hi Jens, >> Seems that my first mail was missed somewhere. >> I've found couple of trivial issues in blkdev_issue_zeroout() >> implementation. Unfortunately I've miss during initial testing phase >> because always called it with BARRIER|WAIT flags. > > BTW, this: > > @@ -218,15 +222,18 @@ submit: > /* One of bios in the batch was completed with error.*/ > ret = -EIO; > > - if (ret) > + if (ret && ret != -ENOMEM) > goto out; > > if (test_bit(BIO_EOPNOTSUPP, &bb.flags)) { > ret = -EOPNOTSUPP; > goto out; > } > - if (nr_sects != 0) > + if (nr_sects != 0) { > + if (ret == -ENOMEM) > + io_schedule(); > goto submit; > + } > out: > return ret; > } > > is broken. Either the caller sets __GFP_WAIT and then bio_alloc() will > not fail, or GFP_ATOMIC is used knowing that the call can fail and > return ENOMEM. Don't code in retry logic like this. Ok, my fault and in fact i've done in explicitly. I just thought that blk-layer is some times an exception from general GFP_ATOMIC rule because in some places in blk-layer we stick to GFP_NOFAIL semantics regardless to actual gfp flags. New version attached.