On 25.04.2022 13:29, Tamas K Lengyel wrote: > 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!
I certainly understand your frustration, the more that I'm similarly affected with a much larger pile of patches. The check-in policy (see ./MAINTAINERS) is - I'm tempted to say "unfortunately" - quite clear about there being a need for a 2nd party to be involved. In this case though I've pointed out a possible route to unblock these two patches - let's give Petre and Alexandru at least a few days to possibly react to the ping. Apart from this I can only suggest to put this on the agenda of the next Community Call; I'm afraid I won't myself, as I've had this topic there already way too often. Jan
