On Mon, Apr 25, 2022, 3:49 AM Jan Beulich <[email protected]> wrote: > On 22.04.2022 16:07, Tamas K Lengyel wrote: > > On Wed, Apr 13, 2022 at 9:43 AM Tamas K Lengyel <[email protected]> > wrote: > >> > >> Allow specify distinct parts of the fork VM to be reset. This is useful > when a > >> fuzzing operation involves mapping in only a handful of pages that are > known > >> ahead of time. Throwing these pages away just to be re-copied > immediately is > >> expensive, thus allowing to specify partial resets can speed things up. > >> > >> Also allow resetting to be initiated from vm_event responses as an > >> optimization. > >> > >> Signed-off-by: Tamas K Lengyel <[email protected]> > > > > Patch ping. Could I get a Reviewed-by if there are no objections? > > Hmm, this is a little difficult. I'd be willing to give an ack, but that's > meaningless for most of the code here. Besides a stylistic issue I did > point out which I'm not happy with, I'm afraid I'm not good enough at > mem-sharing and forking. Therefore I wouldn't want to offer an R-b. > Considering the VM event interaction, maybe the BitDefender guys could > take a stab? > > Of course you'd then still need a tool stack side ack. >
So my take is that noone cares about mem_sharing, which is fine, its an obscure experiment subsystem. But the only path I see as maintainer to get anything in-tree is if I hand the task of writing the patch to a coworker who then sends it in so that I can ack it. This is clearly disfunctional and is to the detriment of the project overall. We need to get some rules in place to avoid situations like this that clearly lead to no development and no improvement and a huge incentive to forgot about upstreaming. With no substantive objections but no acks a maintainer should be able to get changes in-tree. That's part of what I would consider maintaining a codebase to be! Anyway, to be realistic I don't expect that option to materialize so I'm very close to just stop all contributions to the project. It's dishartening. Tamas
