On Thu, Feb 13, 2025 at 10:13 PM Hou Tao <houtao@xxxxxxxxxxxxxxx> wrote: > > Hi, > > On 2/14/2025 2:02 AM, Alexei Starovoitov wrote: > > On Sat, Jan 25, 2025 at 2:59 AM Hou Tao <houtao@xxxxxxxxxxxxxxx> wrote: > >> From: Hou Tao <houtao1@xxxxxxxxxx> > >> > >> For map with dynptr key support, it needs to use map_extra to specify > >> the maximum data length of these dynptrs. The implementation of the map > >> will check whether map_extra is smaller than the limitation imposed by > >> memory allocation during map creation. It may also use map_extra to > >> optimize the memory allocation for dynptr. > > Why limit it? > > The only piece of code I could find is: > > > > uptr->size > map->map_extra > > > > and it doesn't look necessary. > > Let it consume whatever necessary ? > > . > > It will be usable when trying to iterate keys through ->get_next_key() > in kernel (e.g., support map_seq_show_elem in v3), because for now the > data memory for dynptr in the map key is allocated by the caller > (because the callee hold a rcu read lock). If the max length of dynptr > data is unknown, map_iter_alloc()/map_seq_next() may need some logic to > probe the max length of dynptr data during the traversal of keys. Will > check whether or not it is feasible in v3. It doesn't have to be: next_key = kvmalloc(map->key_size, GFP_USER); the internal interface can be different. It's not a good idea to impose uapi restrictions, because of implementation details.
