Soft lockup due to lin_tape driver getting stuck in a loop

Issue

• One of our backup server crashes frequently
• System crashes with this message:

BUG: soft lockup - CPU#0 stuck for 67s! [udisks-daemon:5829]
Modules linked in: fuse lin_tape(U) sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf bonding 8021q garp stp llc ipv6 mppVhba(U) uinput osst st ch bnx2 cdc_ether usbnet mii microcode serio_raw i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support ioatdma dca i7core_edac edac_core shpchp ext4 mbcache jbd2 sr_mod cdrom lpfc scsi_transport_fc scsi_tgt pata_acpi ata_generic ata_piix megaraid_sas mppUpper(U) sg sd_mod crc_t10dif dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan]
CPU 0 
Modules linked in: fuse lin_tape(U) sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf bonding 8021q garp stp llc ipv6 mppVhba(U) uinput osst st ch bnx2 cdc_ether usbnet mii microcode serio_raw i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support ioatdma dca i7core_edac edac_core shpchp ext4 mbcache jbd2 sr_mod cdrom lpfc scsi_transport_fc scsi_tgt pata_acpi ata_generic ata_piix megaraid_sas mppUpper(U) sg sd_mod crc_t10dif dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan]

Pid: 5829, comm: udisks-daemon Not tainted 2.6.32-279.el6.x86_64 #1 IBM System x3550 M3 -[7944D4A]-/00D4062
RIP: 0010:[<ffffffff8150038e>]  [<ffffffff8150038e>] lock_kernel+0x2e/0x50
RSP: 0018:ffff880239c9fca8  EFLAGS: 00000297
RAX: 0000000000000000 RBX: ffff880239c9fca8 RCX: 000000000000d337
RDX: 000000000000d338 RSI: 0000000000000004 RDI: ffff88047609ae80
RBP: ffffffff8100bc0e R08: 0000000000000004 R09: ffff88047609aee0
R10: 0000000000000000 R11: ffffffff81abd9b8 R12: ffff880239c9fe28
R13: ffff880239c9fc38 R14: ffff880239c9fd08 R15: 0000000000000003
FS:  00007ffff7fe37a0(0000) GS:ffff880036600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffff7ff3000 CR3: 0000000239c19000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process udisks-daemon (pid: 5829, threadinfo ffff880239c9e000, task ffff88024f8b1500)
Stack:
 ffff880239c9fd08 ffffffff811b4940 ffff8804731400a0 000000004f8b1500
<d> ffff88024f8b1500 ffff88024f8b1500 ffff880239c9fce8 ffff88047342a140
<d> 00000000fffffff4 ffff880473140080 ffffffff811b4cd0 ffff88046f9b2758
Call Trace:
 [<ffffffff811b4940>] ? __blkdev_get+0x50/0x3c0
 [<ffffffff811b4cd0>] ? blkdev_open+0x0/0xc0
 [<ffffffff811b4cc0>] ? blkdev_get+0x10/0x20
 [<ffffffff811b4d41>] ? blkdev_open+0x71/0xc0
 [<ffffffff8117888a>] ? __dentry_open+0x10a/0x360
 [<ffffffff8121429f>] ? security_inode_permission+0x1f/0x30
 [<ffffffff81178bf4>] ? nameidata_to_filp+0x54/0x70
 [<ffffffff8118c100>] ? do_filp_open+0x6c0/0xd60
 [<ffffffff810d4c52>] ? audit_alloc_name+0x62/0x100
 [<ffffffff8119a330>] ? mntput_no_expire+0x30/0x110
 [<ffffffff81198182>] ? alloc_fd+0x92/0x160
 [<ffffffff81178639>] ? do_sys_open+0x69/0x140
 [<ffffffff8100c5b5>] ? math_state_restore+0x45/0x60
 [<ffffffff81178750>] ? sys_open+0x20/0x30
 [<ffffffff8100b0f2>] ? system_call_fastpath+0x16/0x1b