From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751578AbdE0DYq (ORCPT ); Fri, 26 May 2017 23:24:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58882 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750973AbdE0DYn (ORCPT ); Fri, 26 May 2017 23:24:43 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com C70BA61B9D Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=mchristi@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com C70BA61B9D Subject: Re: [PATCH] iscsi-target: Fix initial login PDU asynchronous socket close OOPs To: "Nicholas A. Bellinger" , target-devel References: <1495776751-4746-1-git-send-email-nab@linux-iscsi.org> Cc: linux-scsi , lkml , Hannes Reinecke , Sagi Grimberg , Varun Prakash From: Mike Christie Message-ID: <5928EF2C.6090609@redhat.com> Date: Fri, 26 May 2017 22:14:52 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <1495776751-4746-1-git-send-email-nab@linux-iscsi.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Sat, 27 May 2017 03:14:54 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thanks for the patch. On 05/26/2017 12:32 AM, Nicholas A. Bellinger wrote: > > - state = iscsi_target_sk_state_check(sk); > - write_unlock_bh(&sk->sk_callback_lock); > - > - pr_debug("iscsi_target_sk_state_change: state: %d\n", state); > + orig_state_change(sk); > > - if (!state) { > - pr_debug("iscsi_target_sk_state_change got failed state\n"); > - schedule_delayed_work(&conn->login_cleanup_work, 0); I think login_cleanup_work is no longer used so you can also remove it and its code. The patch fixes the crash for me. However, is there a possible regression where if the initiator attempts new relogins we could run out of memory? With the old code, we would free the login attempts resources at this time, but with the new code the initiator will send more login attempts and so we just keep allocating more memory for each attempt until we run out or the login is finally able to complete.