linux-kernel - Re: v5.4.289 failed to boot with error megasas_build_io_fusion 3219 sge

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5a7d969b-b2ab-4fac-b95e-4a536e2c8d5c@suse.com>
Date: Thu, 30 Jan 2025 13:35:12 +0100
From: Jürgen Groß <jgross@...e.com>
To: Harshvardhan Jha <harshvardhan.j.jha@...cle.com>,
 Greg KH <gregkh@...uxfoundation.org>
Cc: Konrad Wilk <konrad.wilk@...cle.com>,
 Boris Ostrovsky <boris.ostrovsky@...cle.com>,
 "sstabellini@...nel.org" <sstabellini@...nel.org>,
 "xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 Harshit Mogalapalli <harshit.m.mogalapalli@...cle.com>,
 stable@...r.kernel.org
Subject: Re: v5.4.289 failed to boot with error megasas_build_io_fusion 3219
 sge_count (-12) is out of range

On 29.01.25 19:46, Harshvardhan Jha wrote:
> 
> On 30/01/25 12:13 AM, Jürgen Groß wrote:
>> On 29.01.25 19:35, Harshvardhan Jha wrote:
>>>
>>> On 29/01/25 4:52 PM, Juergen Gross wrote:
>>>> On 29.01.25 10:15, Harshvardhan Jha wrote:
>>>>>
>>>>> On 29/01/25 2:34 PM, Greg KH wrote:
>>>>>> On Wed, Jan 29, 2025 at 02:29:48PM +0530, Harshvardhan Jha wrote:
>>>>>>> Hi Greg,
>>>>>>>
>>>>>>> On 29/01/25 2:18 PM, Greg KH wrote:
>>>>>>>> On Wed, Jan 29, 2025 at 02:13:34PM +0530, Harshvardhan Jha wrote:
>>>>>>>>> Hi there,
>>>>>>>>>
>>>>>>>>> On 29/01/25 2:05 PM, Greg KH wrote:
>>>>>>>>>> On Wed, Jan 29, 2025 at 02:03:51PM +0530, Harshvardhan Jha wrote:
>>>>>>>>>>> Hi All,
>>>>>>>>>>>
>>>>>>>>>>> +stable
>>>>>>>>>>>
>>>>>>>>>>> There seems to be some formatting issues in my log output. I
>>>>>>>>>>> have
>>>>>>>>>>> attached it as a file.
>>>>>>>>>> Confused, what are you wanting us to do here in the stable tree?
>>>>>>>>>>
>>>>>>>>>> thanks,
>>>>>>>>>>
>>>>>>>>>> greg k-h
>>>>>>>>> Since, this is reproducible on 5.4.y I have added stable. The
>>>>>>>>> culprit
>>>>>>>>> commit which upon getting reverted fixes this issue is also
>>>>>>>>> present in
>>>>>>>>> 5.4.y stable.
>>>>>>>> What culprit commit?  I see no information here :(
>>>>>>>>
>>>>>>>> Remember, top-posting is evil...
>>>>>>> My apologies,
>>>>>>>
>>>>>>> The stable tag v5.4.289 seems to fail to boot with the following
>>>>>>> prompt in an infinite loop:
>>>>>>> [   24.427217] megaraid_sas 0000:65:00.0: megasas_build_io_fusion
>>>>>>> 3273 sge_count (-12) is out of range. Range is:  0-256
>>>>>>>
>>>>>>> Reverting the following patch seems to fix the issue:
>>>>>>>
>>>>>>> stable-5.4      : v5.4.285             - 5df29a445f3a
>>>>>>> xen/swiotlb: add
>>>>>>> alignment check for dma buffers
>>>>>>>
>>>>>>> I tried changing swiotlb grub command line arguments but that didn't
>>>>>>> seem to help much unfortunately and the error was seen again.
>>>>>>>
>>>>>> Ok, can you submit this revert with the information about why it
>>>>>> should
>>>>>> not be included in the 5.4.y tree and cc: everyone involved and
>>>>>> then we
>>>>>> will be glad to queue it up.
>>>>>>
>>>>>> thanks,
>>>>>>
>>>>>> greg k-h
>>>>>
>>>>> This might be reproducible on other stable trees and mainline as
>>>>> well so
>>>>> we will get it fixed there and I will submit the necessary fix to
>>>>> stable
>>>>> when everything is sorted out on mainline.
>>>>
>>>> Right. Just reverting my patch will trade one error with another one
>>>> (the
>>>> one which triggered me to write the patch).
>>>>
>>>> There are two possible ways to fix the issue:
>>>>
>>>> - allow larger DMA buffers in xen/swiotlb (today 2MB are the max.
>>>> supported
>>>>     size, the megaraid_sas driver seems to effectively request 4MB)
>>>
>>> This seems relatively simpler to implement but I'm not sure whether it's
>>> the most optimal approach
>>
>> Just making the static array larger used to hold the frame numbers for
>> the
>> buffer seems to be a waste of memory for most configurations.
> Yep definitely not required in most cases.
>>
>> I'm thinking of an allocated array using the max needed size (replace a
>> former buffer with a larger one if needed).
> 
> This seems like the right way to go.

Can you try the attached patch, please? I don't have a system at hand
showing the problem.


Juergen

View attachment "0001-x86-xen-allow-larger-contiguous-memory-regions-in-PV.patch" of type "text/x-patch" (4191 bytes)

Download attachment "OpenPGP_0xB0DE9DD628BF132F.asc" of type "application/pgp-keys" (3684 bytes)

Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (496 bytes)