On Mon, Jan 30, 2023 at 09:44:11PM +0530, Ritesh Harjani (IBM) wrote: > The problem is that commit[1] moved iop creation later i.e. after checking for > whether the folio is uptodate. And if the folio is uptodate, it simply > returns and doesn't allocate a iop. > Now what can happen is that during __iomap_write_begin() for bs < ps, > there can be a folio which is marked uptodate but does not have a iomap_page > structure allocated. > (I think one of the reason it can happen is due to memory pressure, we > can end up freeing folio->private resource). > > Thus the iop structure will only gets allocated at the time of writeback > in iomap_writepage_map(). This I think, was a not problem till now since > we anyway only track uptodate status in iop (no support of tracking > dirty bitmap status which later patches will add), and we also end up > setting all the bits in iomap_page_create(), if the page is uptodate. delayed iop allocation is a feature and not a bug. We might have to refine the criteria for sub-page dirty tracking, but in general having the iop allocates is a memory and performance overhead and should be avoided as much as possible. In fact I still have some unfinished work to allocate it even more lazily.
