Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <a1bf6f05-9be3-3bd8-7878-abfa3ff5dbe8@undermydesk.org>
Date:   Fri, 9 Jun 2023 22:54:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.2
Subject: Re: memcpy: detected field-spanning write (size 128) of single field
 "&r1_cmd->io_request->SGL" at
 drivers/scsi/megaraid/megaraid_sas_fusion.c:3326 (size 16)
Content-Language: en-US
To:     Holger Kiehl <Holger.Kiehl@dwd.de>,
        Kashyap Desai <kashyap.desai@broadcom.com>,
        Sumit Saxena <sumit.saxena@broadcom.com>,
        Shivasharan S <shivasharan.srikanteshwara@broadcom.com>,
        "James E.J. Bottomley" <jejb@linux.ibm.com>,
        "Martin K. Petersen" <martin.petersen@oracle.com>,
        megaraidlinux.pdl@broadcom.com, linux-scsi@vger.kernel.org,
        linux-kernel <linux-kernel@vger.kernel.org>
References: <88de8faa-56c4-693d-2d3-67152ee72057@diagnostix.dwd.de>
From:   Frank Reppin <frank@undermydesk.org>
In-Reply-To: <88de8faa-56c4-693d-2d3-67152ee72057@diagnostix.dwd.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

Dear all,

at first - my apologies to bring this up again here.

But may I please ask/request to have this fix committed
to longterm 6.1 too?

Reason: Upcoming Debian Bookworm (currently RC4) comes with 6.1 but
does not include this fix yet - as it is only present in 6.3. - and
probably nobody noticed this one yet.

We do encounter this issue on brand new test machines (which should go
live once Bookworm is released) and this is a real showstopper
when it comes to show logs to QA audit people... ;)

Another reason: I see vanished /dev/disk/by-uuid/ entries when
this issue hits us

For example...

cryptsetup -v -y luksFormat 
/dev/disk/by-uuid/926943a2-8e40-445f-aad4-2ee96807cd32
-> this command should succeed - but returns with error because
somehow this (some seconds earlier perfectly valid and existing)
by-uuid entry vanished during the issue.
Other entries pointing to the same virtual drive are not affected.
(by-id,by-path,by-diskseq)

Last but not least... is this really a warning only?!
While I don't think that something on our brand new servers is broken
(it affects all btw - same observation as Holger mentioned here earlier)
it is really disturbing to see vanishing /dev/disk/by-uuid/ entries
since they might be used somewhere else and their sudden disappearance
might cause severe havoc for other daemons looking for them (server 
monitoring comes to mind ... nagios... zabbix)

Thankyou all!
cheers
Frank Reppin


-- 
43rd Law of Computing:
         Anything that can go wr
fortune: Segmentation violation -- Core dumped