[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 1/2] x86/mem_sharing: make fork_reset more configurable


  • To: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 25 Apr 2022 13:41:24 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8xGJB3x6bOt4UkRisDTcheFJuZGP02K2KtsvDqZG4Tk=; b=kiWd0DyHrFurKjGbkiHalw1EVg9jFoYOy2SsyqpQTLVGJ0Kf6xA7NNDNO4nE+4fgbjMrEVMDEgqeCcjIaXu5dh+PJOQ8KJSUUvkltBEx+6q1UoKimC4ppFjWx88VxIcbOI9EtnXwsHg9RU+tDZ3SZ6KK5OwCnycuU4yFCloU91nz72XFfSoNSZNsd+3jITiL9m9PrACzfmnL8bWARmjdyKMM2Mr/jP41FrO2OgMMOj3vgw022br3cyp8oBDAvFUz44IWoAb2W7VTPB4W/GbciH6KRgmCodXlfw02Ugz4OaHDNUgrQipvz3ZptQZEWbRQ/SKUjMmu6RAJcc6dUTv/Dg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gmUpvrUGu03NWH9cOFoa1IWFyW14wg4GhEgEFlQXPV3qWt5NocWtJFIh5ibr0hpFdGXBj4UCrMxCM3hmMxagsO2mSBNU1MpGUpHUvb8nF0jfv5zBueDc+ziCrEl1X7ReceEXm7O8YQC7rT0yx9CHXMjiiGPtbbPyK32CVQDIBxh4yWLhTxLI3kUjhIByHieDJXtuaiLIsVzIyicxWKyX0RRscQz//mKRbGcEGzzb0cOAlb5GYfHOYQ4BNRhDpE/OUwppj5n/WTVlzMjmxRc3Te+HXotyiSaSSNneLBlmGkZFyjcgiijvCNSHS4GoR2wYfC/Bq/upEIeDlzCJ1SQYzQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Tamas K Lengyel <tamas.lengyel@xxxxxxxxx>, Alexandru Isaila <aisaila@xxxxxxxxxxxxxxx>, Petre Pircalabu <ppircalabu@xxxxxxxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>
  • Delivery-date: Mon, 25 Apr 2022 11:41:40 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 25.04.2022 13:29, Tamas K Lengyel wrote:
> On Mon, Apr 25, 2022, 3:49 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
> 
>> On 22.04.2022 16:07, Tamas K Lengyel wrote:
>>> On Wed, Apr 13, 2022 at 9:43 AM Tamas K Lengyel <tamas.lengyel@xxxxxxxxx>
>> 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 <tamas.lengyel@xxxxxxxxx>
>>>
>>> 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




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.