From patchwork Tue Apr 11 00:45:48 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Moon X-Patchwork-Id: 67596 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E58B03858C36 for ; Tue, 11 Apr 2023 00:45:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E58B03858C36 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1681173958; bh=lBXbxqNr9AZREH2dbFOTAW6/G3mZ1ptAdaB2PzEsYYY=; h=Date:To:CC:Subject:List-Id:List-Unsubscribe:List-Archive: List-Help:List-Subscribe:From:Reply-To:From; b=fE0629sX0Ck+DejmSheaIymUH423prN5tKfuwWAVK5oeG8QrPFlHfC+Ce2nRNKv29 BOq5pwSweyT153/Fa/4aR9fVT0A0Eqs7+r6umpgULNKY6WqYg3NE6QehF2kLK+SY6X WpC/qMZWDsVfp1NCB3ZCpD5qwWjyU40E6e0qA2jw= X-Original-To: libabigail@sourceware.org Delivered-To: libabigail@sourceware.org Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by sourceware.org (Postfix) with ESMTPS id EFDD33858D38 for ; Tue, 11 Apr 2023 00:45:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EFDD33858D38 Received: from pps.filterd (m0279868.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 33B0frO5027095; Tue, 11 Apr 2023 00:45:50 GMT Received: from nalasppmta01.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3pvm97h1qj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 11 Apr 2023 00:45:50 +0000 Received: from nalasex01c.na.qualcomm.com (nalasex01c.na.qualcomm.com [10.47.97.35]) by NALASPPMTA01.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 33B0jnoZ015289 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 11 Apr 2023 00:45:49 GMT Received: from [10.110.49.239] (10.80.80.8) by nalasex01c.na.qualcomm.com (10.47.97.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.42; Mon, 10 Apr 2023 17:45:48 -0700 Message-ID: <5363161d-8167-284e-e35d-9a8ef20adea9@quicinc.com> Date: Mon, 10 Apr 2023 17:45:48 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Content-Language: en-US To: , CC: Trilok Soni , Satya Durga Srinivasu Prabhala Subject: abidiff improvements for kernel UAPI checker X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nalasex01c.na.qualcomm.com (10.47.97.35) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: 8SQcrk5UMt_NDgXBdNjwbcEKnN3aDMoI X-Proofpoint-ORIG-GUID: 8SQcrk5UMt_NDgXBdNjwbcEKnN3aDMoI X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22 definitions=2023-04-10_18,2023-04-06_03,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 malwarescore=0 adultscore=0 mlxlogscore=999 lowpriorityscore=0 mlxscore=0 clxscore=1011 priorityscore=1501 impostorscore=0 suspectscore=0 spamscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2303200000 definitions=main-2304110004 X-Spam-Status: No, score=-11.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libabigail@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list of the Libabigail project List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-Patchwork-Original-From: John Moon via Libabigail From: John Moon Reply-To: John Moon Errors-To: libabigail-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libabigail" Hi all, As you may be aware from the Linux kernel mailing list threads I've been CC'ing you on, we're in the process of upstreaming a shell script that uses abidiff to compare Linux kernel userspace APIs between revisions. Linux UAPIs are supposed to be stable forever, so we're trying to detect when a patch breaks a UAPI. If you haven't been following, the latest thread is here: https://lore.kernel.org/lkml/20230407203456.27141-1-quic_johmoo@quicinc.com/ At a high level, we're taking the header file before/after the patch, building it in a dummy C file, then taking advantage of abidiff's "--non-reachable-types" argument to compare all the symbols. This method works great! However, there are a couple of classes of ABI differences that are detected but don't qualify as UAPI-breaking. By far the most common class of differences occur with enum expansions. For example, this change triggers finding: https://github.com/torvalds/linux/commit/622f1b2fae2eea28a80b04f130e3bb54227699f8#diff-a7f82b68b3459e13934c123bda4c3a9be20eadebe938a376e39a395e5ffa825a Specifically this change to include/uapi/linux/dbcnl.h: abidiff correctly reports there's an ABI difference: [C] 'enum ieee_attrs' changed: type size hasn't changed 1 enumerator insertion: 'ieee_attrs::DCB_ATTR_DCB_REWR_TABLE' value '12' 1 enumerator change: 'ieee_attrs::__DCB_ATTR_IEEE_MAX' from value '12' to '13' at dcbnl.h:416:1 It's quite common in the kernel to have the last variant in your enum be *_MAX, then define the max value of the enum based on that variant. However, just adding a variant to this enum doesn't break userspace (unless you have a program that does something silly like this): if (DCB_ATTR_IEEE_MAX > 12) { // crash the program } Assuming that programs will use the MAX value in a reasonable way, we can consider this change safe for userspace backwards-compatibility if it meets the following criteria: 1. No variants are removed/renamed 2. No variants have a changed value (unless it's the last one) Technically, we could parse the stdout of abidiff to see if these conditions are met, but that'd be quite complicated and fragile. It seems a better choice to detect them when the data structures are available. Do you have any ideas on how these condition could be detected from abidiff? We could spend some time to implement the logic, but I'm not sure if this kind of specific use case is within the scope of your project. If so, could something be added like "--ignore-enum-expansion" (or some other flag)? There are other similar "false positives" discussed in the LKML thread, but this first one is the largest and probably the easiest to detect algorithmically, so I figure it's a good starting point. Thank you in advance for any help! - John Moon diff --git a/include/uapi/linux/dcbnl.h b/include/uapi/linux/dcbnl.h index 99047223ab26..7e15214aa5dd 100644 --- a/include/uapi/linux/dcbnl.h +++ b/include/uapi/linux/dcbnl.h @@ -411,6 +411,7 @@ enum dcbnl_attrs { * @DCB_ATTR_IEEE_PEER_PFC: peer PFC configuration - get only * @DCB_ATTR_IEEE_PEER_APP: peer APP tlv - get only * @DCB_ATTR_DCB_APP_TRUST_TABLE: selector trust table + * @DCB_ATTR_DCB_REWR_TABLE: rewrite configuration */ enum ieee_attrs { DCB_ATTR_IEEE_UNSPEC, @@ -425,6 +426,7 @@ enum ieee_attrs { DCB_ATTR_IEEE_QCN_STATS, DCB_ATTR_DCB_BUFFER, DCB_ATTR_DCB_APP_TRUST_TABLE, + DCB_ATTR_DCB_REWR_TABLE, __DCB_ATTR_IEEE_MAX };