> On Jul 8, 2022, at 8:58 AM, Luis Chamberlain <mcgrof@xxxxxxxxxx> wrote: > > On Fri, Jul 08, 2022 at 01:36:25AM +0000, Song Liu wrote: >> >> >>> On Jul 7, 2022, at 5:53 PM, Luis Chamberlain <mcgrof@xxxxxxxxxx> wrote: >>> >>> On Thu, Jul 07, 2022 at 11:52:58PM +0000, Song Liu wrote: >>>>> On Jul 7, 2022, at 3:59 PM, Luis Chamberlain <mcgrof@xxxxxxxxxx> wrote: >>>>> >>>>> On Thu, Jul 07, 2022 at 03:35:41PM -0700, Song Liu wrote: >>>>>> This set is the second half of v4 [1]. >>>>>> >>>>>> Changes v5 => v6: >>>>>> 1. Rebase and extend CC list. >>>>> >>>>> Why post a new iteration so soon without completing the discussion we >>>>> had? It seems like we were at least going somewhere. If it's just >>>>> to include mm as I requested, sure, that's fine, but this does not >>>>> provide context as to what we last were talking about. >>>> >>>> Sorry for sending v6 too soon. The primary reason was to extend the CC >>>> list and add it back to patchwork (v5 somehow got archived). >>>> >>>> Also, I think vmalloc_exec_ work would be a separate project, while this >>>> set is the followup work of bpf_prog_pack. Does this make sense? >>>> >>>> Btw, vmalloc_exec_ work could be a good topic for LPC. It will be much >>>> more efficient to discuss this in person. >>> >>> What we need is input from mm / arch folks. What is not done here is >>> what that stuff we're talking about is and so mm folks can't guess. My >>> preference is to address that. >>> >>> I don't think in person discussion is needed if the only folks >>> discussing this topic so far is just you and me. >> >> How about we start a thread with mm / arch folks for the vmalloc_exec_* >> topic? I will summarize previous discussions and include pointers to >> these discussions. If necessary, we can continue the discussion at LPC. > > This sounds like a nice thread to use as this is why we are talking > about that topic. > >> OTOH, I guess the outcome of that discussion should not change this set? > > If the above is done right then actually I think it would show similar > considerations for a respective free for module_alloc_huge(). > >> If we have concern about module_alloc_huge(), maybe we can have bpf code >> call vmalloc directly (until we have vmalloc_exec_)? > > You'd need to then still open code in a similar way the same things > which we are trying to reach consensus on. >> What do you think about this plan? > > I think we should strive to not be lazy and sloppy, and prevent growth > of sloppy code. So long as we do that I think this is all reasoanble. Let me try to understand your concerns here. Say if we want module code to be a temporary home for module_alloc_huge before we move it to mm code. Would you think it is ready to ship if we: 1) Rename module_alloc_huge as module_alloc_text_huge(); 2) Add module_free_text_huge(); 3) Move set_memory_* and fill_ill_insn logic into module_alloc_text_huge() and module_free_text_huge(). Are these on the right direction? Did I miss anything important? Thanks, Song
