On Tue, Mar 07, 2023 at 09:14:27AM +0100, Hannes Reinecke wrote: > On 3/7/23 08:30, Matthew Wilcox wrote: > > On Tue, Mar 07, 2023 at 07:55:32AM +0100, Hannes Reinecke wrote: > > > On 3/6/23 18:37, Matthew Wilcox wrote: > > > > On Mon, Mar 06, 2023 at 01:01:23PM +0100, Hannes Reinecke wrote: > > > > > - page = alloc_page(gfp | __GFP_ZERO | __GFP_HIGHMEM); > > > > > - if (!page) > > > > > + folio = folio_alloc(gfp | __GFP_ZERO, 0); > > > > > + if (!folio) > > > > > > > > Did you drop HIGHMEM support on purpose? > > > > > > No; I thought that folios would be doing that implicitely. > > > Will be re-adding. > > > > We can't ... not all filesystems want to allocate every folio from > > HIGHMEM. eg for superblocks, it often makes more sense to allocate the > > folio from lowmem than allocate it from highmem and keep it kmapped. > > The only GFP flag that folios force-set is __GFP_COMP because folios by > > definition are compound pages. > > Oh well. > > However, when playing with the modified brd and setting the logical&physical > blocksize to 16k the whole thing crashes > (not unexpectedly). > It does crash, however, in block_read_full_folio(), which rather > surprisingly (at least for me) is using create_page_buffers(); > I would have expected something like create_folio_buffers(). > Is this work in progress or what is the plan here? Supporting folios > PAGE_SIZE in blockdev is definitely still WIP. I know of at least one bug, which is: #define bh_offset(bh) ((unsigned long)(bh)->b_data & ~PAGE_MASK) That needs to be something like static size_t bh_offset(const struct buffer_head *bh) { return (unsigned long)bh->b_data & (folio_size(bh->b_folio) - 1); } I haven't done a thorough scan for folio-size problems in the block layer; I've just been fixing up things as I notice them. Yes, create_page_buffers() should now be create_folio_buffers(). Just didn't get round to it yet.