On 2020-05-11 18:42, Damien Le Moal wrote: > The patch looks good to me. However, I have one concern regarding the > performance impact of this. When nullblk is used to benchmark the block IO stack > overhead, doing this zeroing unconditionally will likely significantly impact > measured performance. So may be this zeroing feature should be driven by a > modprobe/configfs option ? Doing so, we can keep it off by default, preserving > performance, and turn it on when needed as in Alexander use case. > > Thoughts ? Hi Damien, Does the current implementation of null_blk allow one process to access data that was generated by another process? If so, does that behavior count as a security bug? I am aware of the performance impact of the patch attached to my previous email. I have not made the zeroing behavior optional because I'm concerned about the security implications of doing that. Bart.
