Re: Kernel Oops while closing iSCSI connection [transport_free_dev_tasks]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Am Dienstag, 10. April 2012, 23:54:06 schrieb Nicholas A. Bellinger:
> On Mon, 2012-04-09 at 23:26 +0200, Henning Becker wrote:
> > Am Mittwoch, 4. April 2012, 14:08:36 schrieb Nicholas A. Bellinger:
> > > On Tue, 2012-04-03 at 08:56 +0200, Henning Becker wrote:
> > > > Am Montag, 2. April 2012, 19:27:25 schrieben Sie:
> > > > > On Sat, 2012-03-31 at 21:49 +0200, Henning Becker wrote:
> > > > > > Hello,
> > > > > > I'm using LIO iSCSI target on top of a pacemaker cluster, to
> > > > > > provide a
> > > > > > redundant replicated storage.
> > > > > > 
> > > > > > I randomly get Kernel Oops in transport_free_dev_tasks, while
> > > > > > moving
> > > > > > the
> > > > > > target from one node to the other.
> > > > > > 
> > > > > > Kernel log says the following (Kernel 3.3.0-rc6):
> > > > > > http://pastebin.com/tvm3tK7Z Another log (Kernel 3.2.0):
> > > > > > http://pastebin.com/wMNER3We
> > > > > > 
> > > > > > Distribution is Debian and it seems only to happen, if there is an
> > > > > > iscsi
> > > > > > connection.
> > > > > > 
> > > > > > Any hints?
> > > > > 
> > > > > Hello Henning,
> > > > > 
> > > > > It would be helpful to know a bit more about the target
> > > > > configuration
> > > > > that is triggering this bug, and what the cluster resource callbacks
> > > > > are
> > > > > being invoked to individual /sys/kernel/config/target/iscsi/
> > > > > endpoint
> > > > > shutdown to perform the move..
> > > > 
> > > > Hello Nicholas,
> > > > I've written an inotify log of /sys/kernel/config for you. It's here:
> > > > http://pastebin.com/vNEe6vR5
> > > 
> > > Hi again Henning,
> > > 
> > > Thanks for the setup info and the nice inotify log.
> > > 
> > > > It seems, the Oops happens while disabling target (writing "0" to
> > > > tpgt_1/enable)
> > > 
> > > Ok, please verify if this session is attached to an explicit fabric
> > > initiator NodeACL (iSCSI InitiatorName) configfs group, or attached to a
> > > dynamically generated se_node_acl->acl_group using the TPG attrib
> > > generate_node_acl=1 to allow 'demo mode' operation (eg: all initiators
> > > can login to the endpoint)..?
> > 
> > Hi Nicholas,
> > thanks for your fast answer and sorry, that it took so long for me.
> > 
> > I'm currently using demo mode without any NodeACL. Portal group is
> > initiated with lio_node --permissive and write protection is disabled by
> > writing 0 to attrib/demo_mode_write_protect. And yes, generate_node_acl
> > is '1'.
> Hi Henning,
> 
> Thanks additional for the feedback on your setup.
> 
> > Should I test with ACLs enabled?
> 
> At this point I'm still thinking it's something to do with active I/O
> shutdown with sessions attached to dynamic ACLs with demo-mode
> (generate_node_acls=1) enabled..

Hi Nicholas,
I have bad news. The problem just occured also with generate_node_acls=0.

The Oops happend twice this time with slighty different stack traces. Perhaps, 
it can help you: http://pastebin.com/jpnuYxqV

Henning
> 
> Being able to verify if the issue is reproducible with Explict NodeACLs
> for your setup would help me further isolate down the problem space.
> 
> Thanks,
> 
> --nab
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Linux SCSI]     [Kernel Newbies]     [Linux SCSI Target Infrastructure]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Photos]     [Yosemite]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

Add to Google Powered by Linux