From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from elvis.franken.de (elvis.franken.de [193.175.24.41]) by smtp.subspace.kernel.org (Postfix) with ESMTP id E34622367CE; Sun, 27 Apr 2025 08:48:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.175.24.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745743714; cv=none; b=Pv+E4fsakENSDuGwj3QFmL0Pn24IcCm+k+PBIdg0honeUz0dxRHuZ2BCDY7vcbZkJvgg/6/y6+IUGIVGGwVR8bMe2bcufm4fghwv792g3ziVqHanStnTFVy2Vx4tfaj4ubSxKJ34qcrcxuV2o7qBmHJ0ZxwfDmzDtDqLNXzOBr8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745743714; c=relaxed/simple; bh=gOu7wvGasAAJsNqfTmva3ihx1xGo8COx25Vwcxlk800=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=bzoZyr6CbicZxG5xJcaFZHwaODRlBmqFt6zy435PnmoZxgtHPvk7DMN8Le4Kv8YAxWnXScpUQDehfC4iVc4+Q0TFsZ5giVtu6CbWtSojdc5kfeEtVnAiUdJmlNPRsbK44PC1tzucOg92sG6aGF/zoVft6Ie6A3STE/DY8YqRNio= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=alpha.franken.de; spf=pass smtp.mailfrom=alpha.franken.de; arc=none smtp.client-ip=193.175.24.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=alpha.franken.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=alpha.franken.de Received: from uucp by elvis.franken.de with local-rmail (Exim 3.36 #1) id 1u8wsd-0007Ke-00; Sun, 27 Apr 2025 09:56:51 +0200 Received: by alpha.franken.de (Postfix, from userid 1000) id 96D69C0895; Sun, 27 Apr 2025 09:12:49 +0200 (CEST) Date: Sun, 27 Apr 2025 09:12:49 +0200 From: Thomas Bogendoerfer To: Thorsten Blum Cc: "Maciej W. Rozycki" , Oleg Nesterov , linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] MIPS: Fix MAX_REG_OFFSET and remove zero-length struct member Message-ID: References: <20250417174712.69292-2-thorsten.blum@linux.dev> <9F6CA7CB-B36A-4F79-B78C-7ED63E39260D@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Apr 18, 2025 at 10:21:22PM +0200, Thorsten Blum wrote: > On 18. Apr 2025, at 22:18, Thorsten Blum wrote: > > On 18. Apr 2025, at 17:14, Maciej W. Rozycki wrote: > >> On Fri, 18 Apr 2025, Thorsten Blum wrote: > >>>>> Does regs_get_register() even work for CPU_CAVIUM_OCTEON when accessing > >>>>> the last two registers because they're both ULL, not UL? (independent of > >>>>> my patch) > >>>> > >>>> Or rather two arrays of registers. With 32-bit configurations their > >>>> contents have to be retrieved by pieces. I don't know if it's handled by > >>>> the caller(s) though as I'm not familiar with this interface. > >>> > >>> Ah, CPU_CAVIUM_OCTEON seems to be 64-bit only, so there's no difference > >>> between UL and ULL. Then both my patch and your suggestion: > >> > >> So it seems odd to use `long long int' here, but I can't be bothered to > >> check history. There could be a valid reason or it could be just sloppy > >> coding. > >> > >>> I still prefer my approach without '__last[0]' because it also silences > >>> the following false-positive Coccinelle warning, which is how I stumbled > >>> upon this in the first place: > >>> > >>> ./ptrace.h:51:15-21: WARNING use flexible-array member instead > >> > >> So make `__last' a flexible array instead? With a separate patch. > > > > No, '__last[0]' is a fake flexible array and the Coccinelle warning is > > wrong. We should either ignore the warning or silence it by removing the > > marker, but turning it into a real flexible array doesn't make sense. > > I'd prefer to just remove it from the struct. > > > > Stefan or Oleg, do you have any preference? > > Sorry, I meant Thomas, not Stefan. I don't like the #ifdefery, so please keep __last Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea. [ RFC1925, 2.3 ]