From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 244651A9F9D for ; Tue, 18 Nov 2025 02:36:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763433405; cv=none; b=PZmOBfMMGiiOzkWZzEvLO2FD3kmw6cTiCmD+lrMnPHcMiZv1rObTuqUdahLiOH3UO8DiTHOJw60cGoN1BBre/0P0f/1RG5gD04iahiMwUHMnRy6AQ0d0c2f/ilWLiqpLf7y+w4jhKphxOqnG/zpQQYgUPHGbKki7SA9kktiIf7Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763433405; c=relaxed/simple; bh=HyHTejBwWJGPdD8XSjQiHnAkLEvlgk/pV6AX2k5qGgg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=WkjmVoa/QDxlrEBDXTF2qaR0/rNr1WScZRfcGg7XN2QkF4qxJfIwWaNRqDuO+2CNAYIN9vCN3esxgTn8U5J0Qk4VJXOI1DGmqSzLxVNir8baFBIwEmL6/vhpw0hkuneQPFULWkn8HfXlA9YAfushRttEKh2Jz6TMrq1wj/VKo5M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=2ZF7fhsm; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="2ZF7fhsm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 836B5C4AF0D; Tue, 18 Nov 2025 02:36:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1763433404; bh=HyHTejBwWJGPdD8XSjQiHnAkLEvlgk/pV6AX2k5qGgg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=2ZF7fhsmb+dhEG9cdFZeo8ZmikOzRLjPgKrDSlHOknchQiSkz9criN/lO4IQXWpMU GyNTpkF/2i7nQmQ8eB4ONwWyBG4UokbY7L5rXcBX1h/mZ8e4q5HC/zZu4E0F5F7f0w 2fePkTR/l+tIr3nnqXT/2GlBHaayCkVrFoqIzJRY= Date: Mon, 17 Nov 2025 21:36:43 -0500 From: Greg Kroah-Hartman To: Geert Uytterhoeven Cc: Rene Rebe , Christoph Hellwig , Jens Axboe , "Martin K. Petersen" , Geoff Levand , linux-kernel@vger.kernel.org Subject: Re: [RESEND PATCH] Fix ps3disk: use memcpy_{from,to}_bvec index Message-ID: <2025111708-badass-pope-38fe@gregkh> References: <20251114.153033.430439310885688884.rene@exactco.de> <2025111611-spinout-blabber-0ae2@gregkh> <2025111700-charbroil-freeness-d53d@gregkh> <2025111706-monkhood-snaking-f282@gregkh> 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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon, Nov 17, 2025 at 02:31:49PM +0100, Geert Uytterhoeven wrote: > Hi Greg, > > On Mon, 17 Nov 2025 at 14:13, Greg Kroah-Hartman > wrote: > > On Mon, Nov 17, 2025 at 02:05:33PM +0100, Geert Uytterhoeven wrote: > > > On Mon, 17 Nov 2025 at 13:39, Greg Kroah-Hartman > > > wrote: > > > > On Mon, Nov 17, 2025 at 10:47:49AM +0100, Geert Uytterhoeven wrote: > > > > > On Sun, 16 Nov 2025 at 13:14, Greg Kroah-Hartman > > > > > wrote: > > > > > > On Fri, Nov 14, 2025 at 03:30:33PM +0100, Rene Rebe wrote: > > > > > > > With 6e0a48552b8c (ps3disk: use memcpy_{from,to}_bvec) converting > > > > > > > ps3disk to new bvec helpers, incrementing the offset was accidently > > > > > > > lost, corrupting consecutive buffers. Restore index for non-corrupted > > > > > > > data transfers. > > > > > > > > > > > > > > Fixes: 6e0a48552b8c (ps3disk: use memcpy_{from,to}_bvec) > > > > > > > > > > > > > > Signed-off-by: René Rebe > > > > > > > > > > > > > > --- a/drivers/block/ps3disk.c 2023-08-07 17:40:55.200957746 +0200 > > > > > > > +++ b/drivers/block/ps3disk.c 2023-08-07 17:46:39.702964129 +0200 > > > > > > > @@ -85,10 +93,14 @@ > > > > > > > struct bio_vec bvec; > > > > > > > > > > > > > > rq_for_each_segment(bvec, req, iter) { > > > > > > > + dev_dbg(&dev->sbd.core, "%s:%u: %u sectors from %llu\n", > > > > > > > + __func__, __LINE__, bio_sectors(iter.bio), > > > > > > > > > > > > In the future, please note that all dev_dbg() calls have __func__ built > > > > > > into them, and I think __LINE__ as well, so there's no need to ever add > > > > > > that to the output. Take a look at the documentation for more details > > > > > > on how to see that in the log. > > > > > > > > > > That does not seem to be true in v6.18-rc6: the function name and line > > > > > number are not included. > > > > > > > > What changed to remove them? Look at > > > > Documentation/admin-guide/dynamic-debug-howto.rst for how to enable both > > > > of these for any dynamic debug message in the kernel. > > > > > > > > Does that not work properly here? > > > > > > Oh, dynamic debug, dunno ;-) > > > It does not work with #define DEBUG at the top of a source file. > > > > Nor should it, that's a really old scheme :) > > That method is still documented in > Documentation/admin-guide/dynamic-debug-howto.rst, and I use it a lot. > > It does mean "all dev_dbg() calls have __func__ built in to them" is false... But it's there, just set it from the debugfs api, right? > > > So perhaps lots of cleanup work to do? > > > > > > $ git grep -Ew "(pr_debug|dev_dbg).*__func__" v6.18-rc6 | wc -l > > > 4512 > > > > Huh? We want those to be used. > > You just said they should not print __func__ explicitly?? Yes, they should not. thanks, greg k-h