Received: by 10.192.165.156 with SMTP id m28csp1153590imm; Wed, 11 Apr 2018 13:27:26 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+GVHv61EyMIwZC71C5kZLJiHY473FJ2jEc8rg6/taNnleQKa604JLrGSd9YSyQLnkja1Fp X-Received: by 2002:a17:902:6103:: with SMTP id t3-v6mr6636196plj.76.1523478446239; Wed, 11 Apr 2018 13:27:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523478446; cv=none; d=google.com; s=arc-20160816; b=R/XybbacA+Z9L4HYMQclNGZFBZtUiwgdr0hZ5vWR2qX87iS6guf5IvTlzmDl9l87jL j1hZX2Fxtodb0XPPc2adnWCRyVcYYNdYTopUERMu8cSk4kpO0ze9QWQ/DPMPrYhRDRRR UwPisQ9fWCibT98qB8dm7LqVdERJ6fmHdGgULZTsmuF58q+yfnZr5FkBtfmE86KnLChS fUeAorBcXU31/ECFmIdkGPDaD1cWjtSvIHauc7SzWrwizupmlXS2gdn91Wddry4FIY3O 7k5JDcvRnQb3Bu4vfaOqRGpzqY1fXZ6kv8txQ4GlmYhQRef30nlD1LC3G63WiaTNIE0B hm5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=H05EQZPR7qzYIXCW8TzU+uxdsWl5OpvLWDTOd6uMJAU=; b=GBq/1fHBa0WxqXqgbXMY2tHMroSL19cMRQIVzY4uubtZNTUszDNZIKSbv2Ey/WQ3Dv 69eF/VpUUiK1+nzg3lFeEFsg8PN0O+cTheFi3RB1omRkLtg4NC6DxNYckTsISSdsWnfE P935KXTTYOAbDnrDEwpwBUyjsYVsIIB4Pj/af+9kvhApJ0ossAKZcNu9J9YkmurXVB1R ZDrQOU9aRMDaBOlRUE9Z79OaBm44Wxo147hPV6DG0jRG5k22dpXjAb24Y8jJ+9ntrrHS ZvJ+N6okHJ9+QNQepwLAOtqtOOLFAFkhpzkxD0H7+BHA2Fh7tfOqUsaGntDPkT33KbA8 JZXg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s189si1208907pgb.126.2018.04.11.13.26.49; Wed, 11 Apr 2018 13:27:26 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757495AbeDKUWA (ORCPT + 99 others); Wed, 11 Apr 2018 16:22:00 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:58957 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756709AbeDKUV5 (ORCPT ); Wed, 11 Apr 2018 16:21:57 -0400 Received: from p5492e61e.dip0.t-ipconnect.de ([84.146.230.30] helo=nanos.glx-home) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1f6MFN-0002v6-V7; Wed, 11 Apr 2018 22:21:38 +0200 Date: Wed, 11 Apr 2018 22:21:37 +0200 (CEST) From: Thomas Gleixner To: Dou Liyang cc: peterz@infradead.org, lirongqing@baidu.com, linux-kernel@vger.kernel.org, mingo@kernel.org, hpa@zytor.com, linux-tip-commits@vger.kernel.org Subject: Re: [tip:x86/urgent] x86/apic: Fix signedness bug in APIC ID validity checks In-Reply-To: Message-ID: References: <1523322966-10296-1-git-send-email-lirongqing@baidu.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1987243463-1523478097=:1564" X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1987243463-1523478097=:1564 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT On Wed, 11 Apr 2018, Dou Liyang wrote: > Hi Thomas, > > At 04/10/2018 10:51 PM, tip-bot for Li RongQing wrote: > [...] > > > x86/apic: Fix signedness bug in APIC ID validity checks > > > > The APIC ID as parsed from ACPI MADT is validity checked with the > > apic->apic_id_valid() callback, which depends on the selected APIC type. > > > > For non X2APIC types APIC IDs >= 0xFF are invalid, but values > 0x7FFFFFFF > > Today when I am reading "IntelĀ® 64 Architecture x2APIC Specification", I > find that below in chapter 2.4.1: > > The APIC ID value of FFFF_FFFFH and the highest value corresponding to > the imple-mented bit-width of the local APIC ID register in the system > are reserved and cannot be assigned to any logical processor. > > Seems, FFFF_FFFFH is also invalid for X2APIC types, Shall we also do the > validity check for X2APIC ID? > > acpi_parse_x2apic() > ... > /* Ignore invalid ID */ > if (apic_id == 0xffffffff) > return 0; Yes. I noticed that as well and just did not come around to write the patch. Thanks, tglx --8323329-1987243463-1523478097=:1564--