[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [XEN PATCH v3] xen/mm: address violations of MISRA C:2012 Rules 8.2 and 8.3
- To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Thu, 19 Oct 2023 08:54:02 +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=a8NhRa60bkS4jIzHQs9OrZ7ps371BjrXqvSA4SO6bPc=; b=Q/b0IFHScvzAqGOgCPGuxQADh/ORnhUkymtJATgXNcFWs2OLh4CVHyBkErta5NOklvekqvBSAExV/5t1mJ7GXA1F88Mssn2bcYfRKcof+PtLXPFl6UpZVYqv0kw433YFjPF7cJH718ravT5EIFnJsr7h4ppcHxghRt75M4U+3FTEWt/WWduOKD2elLg9cSJ5ZwLsG+v2eeAwLIqNAaqN1OzIIpUIWoET8feWPZN4LIXhAtzG3nWH5DfdoFZGxf9mG5xXNPHr7YVxphOnJJJVCOZqviNgUA6t8y8y1IPY/Ms1uW9OVyfqF49jcoUbowpA9H45xuinRsdiCHPOm9HI2Q==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RL1KCdA4yS9vgJcgFcxUTdmcABKKnZGFw3P50iXdAekmQA0Jut5QGa1fC3OYoE40I1Cg5tpwEKIUlncE32BzfPXdHUmWvvV4ehsQ5gQ+DIUgaQd5hx5oAoOBMTUiPYNEMcwrFZNWsCeqVO6+698WImctzgoz/5SV+LcNcTqVxKMuyaRTiWcqDMcZOHIkViP2CRWoUz+XSEBMA2sm3ZUrsyQAPNwx66Nk3ssKUd0hHrn4q9MQ4x/X1G1FKZf0TQSoE+br4NjLRzR32qATQ8VLCstbP8NgY8ZLSnqEsfHKeJs571fjL4VevbZeod9OVMgle7Q4Md1/TFCHGl2CxzDUPQ==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Federico Serafini <federico.serafini@xxxxxxxxxxx>, consulting@xxxxxxxxxxx, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Shawn Anastasio <sanastasio@xxxxxxxxxxxxxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Henry Wang <henry.wang@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Thu, 19 Oct 2023 06:54:11 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 19.10.2023 00:43, Stefano Stabellini wrote:
> On Mon, 16 Oct 2023, Jan Beulich wrote:
>> On 03.10.2023 17:24, Federico Serafini wrote:
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -5901,17 +5901,17 @@ int destroy_xen_mappings(unsigned long s, unsigned
>>> long e)
>>> * a problem.
>>> */
>>> void init_or_livepatch modify_xen_mappings_lite(
>>> - unsigned long s, unsigned long e, unsigned int _nf)
>>> + unsigned long s, unsigned long e, unsigned int nf)
>>> {
>>> - unsigned long v = s, fm, nf;
>>> + unsigned long v = s, fm, flags;
>>
>> While it looks correct, I consider this an unacceptably dangerous
>> change: What if by the time this is to be committed some new use of
>> the local "nf" appears, without resulting in fuzz while applying the
>> patch? Imo this needs doing in two steps: First nf -> flags, then
>> _nf -> nf.
>
> Wouldn't it be sufficient for the committer to pay special attention
> when committing this patch? We are in code freeze anyway, the rate of
> changes affecting staging is low.
Any kind of risk excludes a patch from being a 4.18 candidate, imo.
That was the case in early RCs already, and is even more so now. Paying
special attention is generally a possibility, yet may I remind you that
committing in general is intended to be a purely mechanical operation?
Jan
|
