Re: SRPt oops with 4.5-rc3-ish

[Doug Ledford <dledford@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2226 bytes --]

On 02/28/2016 12:00 AM, Nicholas A. Bellinger wrote:
> On Sat, 2016-02-27 at 20:49 -0800, Bart Van Assche wrote:
>> On 02/27/16 20:47, Nicholas A. Bellinger wrote:
>>> On Sat, 2016-02-27 at 20:18 -0800, Bart Van Assche wrote:
>>>> On 02/27/16 19:37, Nicholas A. Bellinger wrote:
>>>>> This is a fairly recent srpt shutdown regression, right..?
>>>>
>>>> Hi Nic,
>>>>
>>>> My patch series to make TMR handling synchronous fixes what Doug
>>>> reported. If you want I can rebase and repost that patch series.
>>>>
>>>
>>> There aren't even any TMRs being processed, so I don't see how that has
>>> anything to do with it.
>>>
>>> >From the logs, this OOPsen is related to some manner of recent srpt
>>> configfs se_node_acl + se_session active I/O shutdown regression.
>>>
>>> So short of sitting down and reproducing myself on v4.5-rc code,
>>> commit 59fae4de's removal of ib_create_cq() + ib_comp_handler callback
>>> usage look like a good place to start the investigation.
>>>
>>> It would be useful to first find out what changes introduced this
>>> regression, and how far back Doug is able to reproduce.
>>
>> As I wrote before, this patch series works 100% stable on top of my most 
>> recent LIO core patch series, a patch series I have also made available 
>> on github. So what Doug ran into is a LIO core bug and not an ib_srpt bug.
>>
> 
> Active I/O shutdown with srpt has not always triggered this OOPs.
> 
> There is a reason why this is happening now, and it needs to be
> identified.
> 
> Either you can help out doing that, or not.  Either way, I'm certainly
> not going to let you hack up LIO TMR code, when there even aren't signs
> ABORT_TASK and friends are occuring in Doug's particular shutdown case.
> 

Sorry I didn't notice this thread had picked back up, I was off on other
stuff.

I can't say if this is new or not.  We added some new testing, that had
considerably more luns in use and more transfers taking place, and while
I was rebooting some actively used servers, I saw this issue.  It might
exist on earlier kernels, I would have to try them to know for sure.

-- 
Doug Ledford <dledford@redhat.com>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]