Re: Linux 2.6.38-rc4 (target_core: rmmod GP fault)

Re: Linux 2.6.38-rc4 (target_core: rmmod GP fault)

[Randy Dunlap]

x86_64, nearly allmodconfig.  No target hardware.


[  144.508473] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC
[  144.509901] last sysfs file: /sys/devices/pci0000:00/0000:00:1d.1/usb6/6-1/6-1.3/devnum
[  144.512026] CPU 1 
[  144.512026] Modules linked in: target_core_mod(-) configfs af_packet nfsd lockd nfs_acl auth_rpcgss exportfs sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables x_tables ipv6 cpufreq_ondemand acpi_cpufreq freq_table mperf binfmt_misc dm_mirror dm_region_hash dm_log dm_multipath scsi_dh dm_mod mousedev joydev evdev mac_hid snd_hda_codec_analog usbmouse snd_hda_intel snd_hda_codec usbkbd usbhid hid snd_hwdep snd_seq 8250_pnp snd_seq_device dcdbas pcspkr sr_mod i2c_i801 cdrom tg3 sg iTCO_wdt snd_pcm 8250 iTCO_vendor_support rtc_cmos serial_core rtc_core snd_timer rtc_lib snd processor button thermal_sys soundcore intel_agp hwmon snd_page_alloc intel_gtt unix ide_p
 ci_generic ide_core ata_generic pata_acpi ata_piix sd_mod crc_t10dif ext3 jbd mbcache uhci_hcd ohci_hcd ssb mmc_core pcmcia pcmcia_core firmware_class ehci_hcd usbcore nls_base [last unload!
 ed: microcode]
[  144.512026] 
[  144.512026] Pid: 2597, comm: rmmod Not tainted 2.6.38-rc4 #1 0TY565/OptiPlex 745                 
[  144.512026] RIP: 0010:[<ffffffff810c3e5f>]  [<ffffffff810c3e5f>] __lock_acquire+0xd8/0x4e8
[  144.512026] RSP: 0018:ffff88006df1bb78  EFLAGS: 00010006
[  144.512026] RAX: 0000000000000002 RBX: 6b6b6b6b6b6b6be3 RCX: 0000000000000000
[  144.512026] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 6b6b6b6b6b6b6be3
[  144.512026] RBP: ffff88006df1bbd8 R08: 0000000000000001 R09: 0000000000000000
[  144.512026] R10: 0000000000000006 R11: ffffffffa06ab0ef R12: 0000000000000000
[  144.512026] R13: ffff88006dec3000 R14: 0000000000000000 R15: 0000000000000000
[  144.512026] FS:  00007fe0320d36f0(0000) GS:ffff88007c600000(0000) knlGS:0000000000000000
[  144.512026] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  144.512026] CR2: 0000003fadc7bf20 CR3: 000000006de4f000 CR4: 00000000000006e0
[  144.512026] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  144.512026] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  144.512026] Process rmmod (pid: 2597, threadinfo ffff88006df1a000, task ffff88006dec3000)
[  144.512026] Stack:
[  144.512026]  0000000000000118 ffff8800000003a7 0000000000000005 00000000810b175b
[  144.512026]  ffff88006df1bba8 0000000000000000 ffff88006dec3000 0000000000000000
[  144.512026]  ffff88006dec3000 ffffffffa06ab0ef 0000000000000001 0000000000000000
[  144.512026] Call Trace:
[  144.512026]  [<ffffffffa06ab0ef>] ? spin_lock+0x15/0x1e [configfs]
[  144.512026]  [<ffffffff810c436f>] lock_acquire+0x100/0x150
[  144.512026]  [<ffffffffa06ab0ef>] ? spin_lock+0x15/0x1e [configfs]
[  144.512026]  [<ffffffffa06ac40f>] ? detach_groups+0x91/0x12e [configfs]
[  144.512026]  [<ffffffffa06ac40f>] ? detach_groups+0x91/0x12e [configfs]
[  144.512026]  [<ffffffff81556300>] _raw_spin_lock+0x44/0xaf
[  144.512026]  [<ffffffffa06ab0ef>] ? spin_lock+0x15/0x1e [configfs]
[  144.512026]  [<ffffffff810c47db>] ? lock_release_nested+0xfb/0x133
[  144.512026]  [<ffffffffa06ab0ef>] spin_lock+0x15/0x1e [configfs]
[  144.512026]  [<ffffffffa06ab144>] dget+0x2e/0x56 [configfs]
[  144.512026]  [<ffffffffa06ac3a4>] detach_groups+0x26/0x12e [configfs]
[  144.512026]  [<ffffffffa06ac363>] configfs_detach_group+0x2d/0x48 [configfs]
[  144.512026]  [<ffffffffa06ac41f>] detach_groups+0xa1/0x12e [configfs]
[  144.512026]  [<ffffffffa06ac363>] configfs_detach_group+0x2d/0x48 [configfs]
[  144.512026]  [<ffffffffa06ac41f>] detach_groups+0xa1/0x12e [configfs]
[  144.512026]  [<ffffffffa06ac363>] configfs_detach_group+0x2d/0x48 [configfs]
[  144.512026]  [<ffffffffa06ac41f>] detach_groups+0xa1/0x12e [configfs]
[  144.512026]  [<ffffffffa06ac363>] configfs_detach_group+0x2d/0x48 [configfs]
[  144.512026]  [<ffffffffa06ac41f>] detach_groups+0xa1/0x12e [configfs]
[  144.512026]  [<ffffffffa06ac363>] configfs_detach_group+0x2d/0x48 [configfs]
[  144.512026]  [<ffffffffa06ace26>] configfs_unregister_subsystem+0x105/0x194 [configfs]
[  144.512026]  [<ffffffffa06baf55>] target_core_exit_configfs+0x185/0x1eb [target_core_mod]
[  144.512026]  [<ffffffff810d46a8>] sys_delete_module+0x2d6/0x368
[  144.512026]  [<ffffffff8155602d>] ? lockdep_sys_exit_thunk+0x35/0x67
[  144.512026]  [<ffffffff81555fb7>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[  144.512026]  [<ffffffff8100e942>] system_call_fastpath+0x16/0x1b
[  144.512026] Code: 05 8f 32 8d 01 e8 6c b1 fb ff 48 ff 05 8b 32 8d 01 48 ff 05 8c 32 8d 01 48 ff 05 95 32 8d 01 e9 e3 03 00 00 48 ff 05 81 32 8d 01 <48> 81 3b 40 5f 26 82 75 07 48 ff 05 81 32 8d 01 83 fe 01 77 13 
[  144.512026] RIP  [<ffffffff810c3e5f>] __lock_acquire+0xd8/0x4e8
[  144.512026]  RSP <ffff88006df1bb78>
[  144.512026] ---[ end trace 37e0ba5347875330 ]---

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: Linux 2.6.38-rc4 (target_core: rmmod GP fault)

[Linus Torvalds]

On Wed, Feb 9, 2011 at 9:28 AM, Randy Dunlap <randy.dunlap@oracle.com> wrote:
> x86_64, nearly allmodconfig.  No target hardware.
>
>
> [  144.508473] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC
> [  144.509901] last sysfs file: /sys/devices/pci0000:00/0000:00:1d.1/usb6/6-1/6-1.3/devnum
> [  144.512026] CPU 1
> [  144.512026]
> [  144.512026] Pid: 2597, comm: rmmod Not tainted 2.6.38-rc4 #1 0TY565/OptiPlex 745
> [  144.512026] RIP: 0010:[<ffffffff810c3e5f>]  [<ffffffff810c3e5f>] __lock_acquire+0xd8/0x4e8
> [  144.512026] RSP: 0018:ffff88006df1bb78  EFLAGS: 00010006
> [  144.512026] RAX: 0000000000000002 RBX: 6b6b6b6b6b6b6be3 RCX: 0000000000000000

The code disassembles to

   0:	8d 01                	lea    (%rcx),%eax
   2:	e8 6c b1 fb ff       	callq  0xfffffffffffbb173
   7:	48 ff 05 8b 32 8d 01 	incq   0x18d328b(%rip)        # 0x18d3299
   e:	48 ff 05 8c 32 8d 01 	incq   0x18d328c(%rip)        # 0x18d32a1
  15:	48 ff 05 95 32 8d 01 	incq   0x18d3295(%rip)        # 0x18d32b1
  1c:	e9 e3 03 00 00       	jmpq   0x404
  21:	48 ff 05 81 32 8d 01 	incq   0x18d3281(%rip)        # 0x18d32a9
  28:*	48 81 3b 40 5f 26 82 	cmpq   $0xffffffff82265f40,(%rbx)     <--
trapping instruction
  2f:	75 07                	jne    0x38
  31:	48 ff 05 81 32 8d 01 	incq   0x18d3281(%rip)        # 0x18d32b9
  38:	83 fe 01             	cmp    $0x1,%esi

and %rbx (and %rdi) contains the poison pattern for free'd memory (0x6b6b6b..).

> [  144.512026] Process rmmod (pid: 2597, threadinfo ffff88006df1a000, task ffff88006dec3000)

.. and that's likely not a very commonly tested case.

> [  144.512026]  [<ffffffffa06ace26>] configfs_unregister_subsystem+0x105/0x194 [configfs]
> [  144.512026]  [<ffffffffa06baf55>] target_core_exit_configfs+0x185/0x1eb [target_core_mod]
> [  144.512026]  [<ffffffff810d46a8>] sys_delete_module+0x2d6/0x368

The target_core_exit_configfs() code looks _very_ broken. It looks
broken for two reasons:

 - it's very different from the cleanup code for the "failed to init"
case in target_core_init_configfs, which does a lot less (see the
"out:" code there)

 - it seems to do a lot of manual freeing of the
"su_group.default_groups" stuff etc, which is all internal configfs
stuff, and seems to be used by the register/unregister phases.

So somebody show knows configfs better should really check that
cleanup, but it looks like target-core is just totally broken for the
rmmod case.

Added more people to the cc. Nicholas, Joel and James. Guys: please
check the insmod/rmmod case with
 (a) spinlock debugging and lockdep enabled
 (b) SLUB poisoning enabled.
ie all of these should be on:

  CONFIG_SLUB_DEBUG_ON=y
  CONFIG_DEBUG_SPINLOCK=y
  CONFIG_DEBUG_MUTEXES=y
  CONFIG_DEBUG_LOCK_ALLOC=y
  CONFIG_PROVE_LOCKING=y
  CONFIG_LOCKDEP=y
  CONFIG_DEBUG_LOCKDEP=y
  CONFIG_TRACE_IRQFLAGS=y
  CONFIG_DEBUG_SPINLOCK_SLEEP=y
  CONFIG_STACKTRACE=y

and you might also want to add CONFIG_DEBUG_PAGEALLOC to the mix.

                        Linus

Re: Linux 2.6.38-rc4 (target_core: rmmod GP fault)

[Nicholas A. Bellinger]

On Wed, 2011-02-09 at 11:00 -0800, Linus Torvalds wrote:
> On Wed, Feb 9, 2011 at 9:28 AM, Randy Dunlap <randy.dunlap@oracle.com> wrote:
> > x86_64, nearly allmodconfig.  No target hardware.
> >
> >
> > [  144.508473] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC
> > [  144.509901] last sysfs file: /sys/devices/pci0000:00/0000:00:1d.1/usb6/6-1/6-1.3/devnum
> > [  144.512026] CPU 1
> > [  144.512026]
> > [  144.512026] Pid: 2597, comm: rmmod Not tainted 2.6.38-rc4 #1 0TY565/OptiPlex 745
> > [  144.512026] RIP: 0010:[<ffffffff810c3e5f>]  [<ffffffff810c3e5f>] __lock_acquire+0xd8/0x4e8
> > [  144.512026] RSP: 0018:ffff88006df1bb78  EFLAGS: 00010006
> > [  144.512026] RAX: 0000000000000002 RBX: 6b6b6b6b6b6b6be3 RCX: 0000000000000000
> 
> The code disassembles to
> 
>    0:	8d 01                	lea    (%rcx),%eax
>    2:	e8 6c b1 fb ff       	callq  0xfffffffffffbb173
>    7:	48 ff 05 8b 32 8d 01 	incq   0x18d328b(%rip)        # 0x18d3299
>    e:	48 ff 05 8c 32 8d 01 	incq   0x18d328c(%rip)        # 0x18d32a1
>   15:	48 ff 05 95 32 8d 01 	incq   0x18d3295(%rip)        # 0x18d32b1
>   1c:	e9 e3 03 00 00       	jmpq   0x404
>   21:	48 ff 05 81 32 8d 01 	incq   0x18d3281(%rip)        # 0x18d32a9
>   28:*	48 81 3b 40 5f 26 82 	cmpq   $0xffffffff82265f40,(%rbx)     <--
> trapping instruction
>   2f:	75 07                	jne    0x38
>   31:	48 ff 05 81 32 8d 01 	incq   0x18d3281(%rip)        # 0x18d32b9
>   38:	83 fe 01             	cmp    $0x1,%esi
> 
> and %rbx (and %rdi) contains the poison pattern for free'd memory (0x6b6b6b..).
> 
> > [  144.512026] Process rmmod (pid: 2597, threadinfo ffff88006df1a000, task ffff88006dec3000)
> 
> .. and that's likely not a very commonly tested case.
> 
> > [  144.512026]  [<ffffffffa06ace26>] configfs_unregister_subsystem+0x105/0x194 [configfs]
> > [  144.512026]  [<ffffffffa06baf55>] target_core_exit_configfs+0x185/0x1eb [target_core_mod]
> > [  144.512026]  [<ffffffff810d46a8>] sys_delete_module+0x2d6/0x368
> 
> The target_core_exit_configfs() code looks _very_ broken. It looks
> broken for two reasons:
> 
>  - it's very different from the cleanup code for the "failed to init"
> case in target_core_init_configfs, which does a lot less (see the
> "out:" code there)
> 

When registering a top level struct configfs_subsystem to appear under

	/sys/kernel/config/$SUBSYSTEM

the releasing of the top-level default group via
configfs_unregister_subsystem() during a failure in
target_core_init_configfs() is done for us, but we are still missing the
extra config_item_put()'s on the sub top-level groups (Joel, please
correct me)

The original 'out:' failure path code does not call config_item_put() on
these default groups, because config_group_init_type_name() has only
initialized struct config_group until configfs_register_subsystem() is
called to register the top level struct config_subsystem.

With the current 'out:' path being broken, to address the first point I
think moving the following code chunk in target_core_init_configfs to
before the configfs_register_subsystem() would make sense so that
configfs_register_subsystem() will fail last:

        /*
         * Register built-in RAMDISK subsystem logic for virtual LUN 0
         */
        ret = rd_module_init();
        if (ret < 0)
                goto out;

        if (core_dev_setup_virtual_lun0() < 0)
                goto out;

        return 0;

However looking at fs/configfs/dir.c:configfs_register_subsystem(), I
think the caller is still expected to release any sub top-level struct
config_group->default_groups[] w/ config_item_put() even though
unlink_group() is called from the configfs_attach_group() failure path..
(Joel..?)

>  - it seems to do a lot of manual freeing of the
> "su_group.default_groups" stuff etc, which is all internal configfs
> stuff, and seems to be used by the register/unregister phases.
> 

The specific issue rmmod with SLUB poisioning had been reported by Fubo
Chen to linux-scsi in the last weeks.  The patch to address the proper
release of the top-level + sub top-level struct configfs_subsystem's
default_groups in target_core_exit_configfs() has been committed into
the upstream tree in lio-core-2.6.git/linus-38-rc3 and sent out to
linux-scsi here:

[PATCH] target: Fix top-level configfs_subsystem default_group shutdown breakage
http://marc.info/?l=linux-scsi&m=129662389218924&w=2

> So somebody show knows configfs better should really check that
> cleanup, but it looks like target-core is just totally broken for the
> rmmod case.
> 
> Added more people to the cc. Nicholas, Joel and James. Guys: please
> check the insmod/rmmod case with
>  (a) spinlock debugging and lockdep enabled
>  (b) SLUB poisoning enabled.
> ie all of these should be on:
> 
>   CONFIG_SLUB_DEBUG_ON=y
>   CONFIG_DEBUG_SPINLOCK=y
>   CONFIG_DEBUG_MUTEXES=y
>   CONFIG_DEBUG_LOCK_ALLOC=y
>   CONFIG_PROVE_LOCKING=y
>   CONFIG_LOCKDEP=y
>   CONFIG_DEBUG_LOCKDEP=y
>   CONFIG_TRACE_IRQFLAGS=y
>   CONFIG_DEBUG_SPINLOCK_SLEEP=y
>   CONFIG_STACKTRACE=y
> 
> and you might also want to add CONFIG_DEBUG_PAGEALLOC to the mix.
> 

<nod>  I believe the above patch resolves the specific rmmod issue.
However, during SLUB poisioning testing we also came across errors with
the incorrect use of struct config_item_operations->release() in
target_core_configfs.c and target_core_fabric_configfs.c code.  The
series to address these was included in the last series to James here:

[PATCH 00/12] target: Updates for .38-rc4
http://marc.info/?l=linux-scsi&m=129680191624837&w=2

Note that this series for-38 mainline needs to be applied on top of the
original update series after the drivers/target/ mainline merge:

[PATCH 00/24] target updates for .38-rc3 (v2)
http://marc.info/?l=linux-scsi&m=129632617326015&w=2

The entire series is available from
     
   git://git.kernel.org/pub/scm/linux/kernel/git/nab/scsi-post-merge-2.6.git for-38-rc4

James, please review + sign-off so we can get these updates into mainline.

Re: Linux 2.6.38-rc4 (target_core: rmmod GP fault)

[James Bottomley]

On Wed, 2011-02-09 at 12:02 -0800, Nicholas A. Bellinger wrote:
> On Wed, 2011-02-09 at 11:00 -0800, Linus Torvalds wrote:
> > On Wed, Feb 9, 2011 at 9:28 AM, Randy Dunlap <randy.dunlap@oracle.com> wrote:
> > > x86_64, nearly allmodconfig.  No target hardware.
> > >
> > >
> > > [  144.508473] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC
> > > [  144.509901] last sysfs file: /sys/devices/pci0000:00/0000:00:1d.1/usb6/6-1/6-1.3/devnum
> > > [  144.512026] CPU 1
> > > [  144.512026]
> > > [  144.512026] Pid: 2597, comm: rmmod Not tainted 2.6.38-rc4 #1 0TY565/OptiPlex 745
> > > [  144.512026] RIP: 0010:[<ffffffff810c3e5f>]  [<ffffffff810c3e5f>] __lock_acquire+0xd8/0x4e8
> > > [  144.512026] RSP: 0018:ffff88006df1bb78  EFLAGS: 00010006
> > > [  144.512026] RAX: 0000000000000002 RBX: 6b6b6b6b6b6b6be3 RCX: 0000000000000000
> > 
> > The code disassembles to
> > 
> >    0:	8d 01                	lea    (%rcx),%eax
> >    2:	e8 6c b1 fb ff       	callq  0xfffffffffffbb173
> >    7:	48 ff 05 8b 32 8d 01 	incq   0x18d328b(%rip)        # 0x18d3299
> >    e:	48 ff 05 8c 32 8d 01 	incq   0x18d328c(%rip)        # 0x18d32a1
> >   15:	48 ff 05 95 32 8d 01 	incq   0x18d3295(%rip)        # 0x18d32b1
> >   1c:	e9 e3 03 00 00       	jmpq   0x404
> >   21:	48 ff 05 81 32 8d 01 	incq   0x18d3281(%rip)        # 0x18d32a9
> >   28:*	48 81 3b 40 5f 26 82 	cmpq   $0xffffffff82265f40,(%rbx)     <--
> > trapping instruction
> >   2f:	75 07                	jne    0x38
> >   31:	48 ff 05 81 32 8d 01 	incq   0x18d3281(%rip)        # 0x18d32b9
> >   38:	83 fe 01             	cmp    $0x1,%esi
> > 
> > and %rbx (and %rdi) contains the poison pattern for free'd memory (0x6b6b6b..).
> > 
> > > [  144.512026] Process rmmod (pid: 2597, threadinfo ffff88006df1a000, task ffff88006dec3000)
> > 
> > .. and that's likely not a very commonly tested case.
> > 
> > > [  144.512026]  [<ffffffffa06ace26>] configfs_unregister_subsystem+0x105/0x194 [configfs]
> > > [  144.512026]  [<ffffffffa06baf55>] target_core_exit_configfs+0x185/0x1eb [target_core_mod]
> > > [  144.512026]  [<ffffffff810d46a8>] sys_delete_module+0x2d6/0x368
> > 
> > The target_core_exit_configfs() code looks _very_ broken. It looks
> > broken for two reasons:
> > 
> >  - it's very different from the cleanup code for the "failed to init"
> > case in target_core_init_configfs, which does a lot less (see the
> > "out:" code there)
> > 
> 
> When registering a top level struct configfs_subsystem to appear under
> 
> 	/sys/kernel/config/$SUBSYSTEM
> 
> the releasing of the top-level default group via
> configfs_unregister_subsystem() during a failure in
> target_core_init_configfs() is done for us, but we are still missing the
> extra config_item_put()'s on the sub top-level groups (Joel, please
> correct me)
> 
> The original 'out:' failure path code does not call config_item_put() on
> these default groups, because config_group_init_type_name() has only
> initialized struct config_group until configfs_register_subsystem() is
> called to register the top level struct config_subsystem.
> 
> With the current 'out:' path being broken, to address the first point I
> think moving the following code chunk in target_core_init_configfs to
> before the configfs_register_subsystem() would make sense so that
> configfs_register_subsystem() will fail last:
> 
>         /*
>          * Register built-in RAMDISK subsystem logic for virtual LUN 0
>          */
>         ret = rd_module_init();
>         if (ret < 0)
>                 goto out;
> 
>         if (core_dev_setup_virtual_lun0() < 0)
>                 goto out;
> 
>         return 0;
> 
> However looking at fs/configfs/dir.c:configfs_register_subsystem(), I
> think the caller is still expected to release any sub top-level struct
> config_group->default_groups[] w/ config_item_put() even though
> unlink_group() is called from the configfs_attach_group() failure path..
> (Joel..?)
> 
> >  - it seems to do a lot of manual freeing of the
> > "su_group.default_groups" stuff etc, which is all internal configfs
> > stuff, and seems to be used by the register/unregister phases.
> > 
> 
> The specific issue rmmod with SLUB poisioning had been reported by Fubo
> Chen to linux-scsi in the last weeks.  The patch to address the proper
> release of the top-level + sub top-level struct configfs_subsystem's
> default_groups in target_core_exit_configfs() has been committed into
> the upstream tree in lio-core-2.6.git/linus-38-rc3 and sent out to
> linux-scsi here:
> 
> [PATCH] target: Fix top-level configfs_subsystem default_group shutdown breakage
> http://marc.info/?l=linux-scsi&m=129662389218924&w=2
> 
> > So somebody show knows configfs better should really check that
> > cleanup, but it looks like target-core is just totally broken for the
> > rmmod case.
> > 
> > Added more people to the cc. Nicholas, Joel and James. Guys: please
> > check the insmod/rmmod case with
> >  (a) spinlock debugging and lockdep enabled
> >  (b) SLUB poisoning enabled.
> > ie all of these should be on:
> > 
> >   CONFIG_SLUB_DEBUG_ON=y
> >   CONFIG_DEBUG_SPINLOCK=y
> >   CONFIG_DEBUG_MUTEXES=y
> >   CONFIG_DEBUG_LOCK_ALLOC=y
> >   CONFIG_PROVE_LOCKING=y
> >   CONFIG_LOCKDEP=y
> >   CONFIG_DEBUG_LOCKDEP=y
> >   CONFIG_TRACE_IRQFLAGS=y
> >   CONFIG_DEBUG_SPINLOCK_SLEEP=y
> >   CONFIG_STACKTRACE=y
> > 
> > and you might also want to add CONFIG_DEBUG_PAGEALLOC to the mix.
> > 
> 
> <nod>  I believe the above patch resolves the specific rmmod issue.
> However, during SLUB poisioning testing we also came across errors with
> the incorrect use of struct config_item_operations->release() in
> target_core_configfs.c and target_core_fabric_configfs.c code.  The
> series to address these was included in the last series to James here:
> 
> [PATCH 00/12] target: Updates for .38-rc4
> http://marc.info/?l=linux-scsi&m=129680191624837&w=2
> 
> Note that this series for-38 mainline needs to be applied on top of the
> original update series after the drivers/target/ mainline merge:
> 
> [PATCH 00/24] target updates for .38-rc3 (v2)
> http://marc.info/?l=linux-scsi&m=129632617326015&w=2
> 
> The entire series is available from
>      
>    git://git.kernel.org/pub/scm/linux/kernel/git/nab/scsi-post-merge-2.6.git for-38-rc4
> 
> James, please review + sign-off so we can get these updates into mainline.

Firstly, could we get the serious bug fixes identified and separated
from the general enhancement updates, so they can go in a fixes tree
without depending on enhancements?  The former category would include
the /proc interface removal, since we don't want the legacy interface to
be in a released kernel.

James

Re: Linux 2.6.38-rc4 (target_core: rmmod GP fault)

[Nicholas A. Bellinger]

On Wed, 2011-02-09 at 14:13 -0600, James Bottomley wrote:
> On Wed, 2011-02-09 at 12:02 -0800, Nicholas A. Bellinger wrote:
> > On Wed, 2011-02-09 at 11:00 -0800, Linus Torvalds wrote:
> > > On Wed, Feb 9, 2011 at 9:28 AM, Randy Dunlap <randy.dunlap@oracle.com> wrote:
> > > > x86_64, nearly allmodconfig.  No target hardware.

<SNIP>

> > <nod>  I believe the above patch resolves the specific rmmod issue.
> > However, during SLUB poisioning testing we also came across errors with
> > the incorrect use of struct config_item_operations->release() in
> > target_core_configfs.c and target_core_fabric_configfs.c code.  The
> > series to address these was included in the last series to James here:
> > 
> > [PATCH 00/12] target: Updates for .38-rc4
> > http://marc.info/?l=linux-scsi&m=129680191624837&w=2
> > 
> > Note that this series for-38 mainline needs to be applied on top of the
> > original update series after the drivers/target/ mainline merge:
> > 
> > [PATCH 00/24] target updates for .38-rc3 (v2)
> > http://marc.info/?l=linux-scsi&m=129632617326015&w=2
> > 
> > The entire series is available from
> >      
> >    git://git.kernel.org/pub/scm/linux/kernel/git/nab/scsi-post-merge-2.6.git for-38-rc4
> > 
> > James, please review + sign-off so we can get these updates into mainline.
> 
> Firstly, could we get the serious bug fixes identified and separated
> from the general enhancement updates, so they can go in a fixes tree
> without depending on enhancements?  The former category would include
> the /proc interface removal, since we don't want the legacy interface to
> be in a released kernel.
> 

Everything in those two series should be considered bug fixes and
immediate for-38 mainline material.

The target_core_mib.c statistics logic using procfs seq_list() has been
removed in [PATCH 12/12] of the most recent series above.

Thanks,

--nab

Re: Linux 2.6.38-rc4 (target_core: rmmod GP fault)

[James Bottomley]

On Wed, 2011-02-09 at 12:20 -0800, Nicholas A. Bellinger wrote:
> On Wed, 2011-02-09 at 14:13 -0600, James Bottomley wrote:
> > Firstly, could we get the serious bug fixes identified and separated
> > from the general enhancement updates, so they can go in a fixes tree
> > without depending on enhancements?  The former category would include
> > the /proc interface removal, since we don't want the legacy interface to
> > be in a released kernel.
> > 
> 
> Everything in those two series should be considered bug fixes and
> immediate for-38 mainline material.

Things like this:

target: remove EXTRA_CFLAGS
target: Remove unnecessary container_of() pointer check
target: Remove unnecessary se_clear_dev_ports legacy code
target: Remove spurious double cast from structure macro accessors
target: Convert TMR REQ/RSP definitions to target namespace
target: Minor sparse warning fixes and annotations
target: Remove unneeded test of se_cmd

Are not serious bug fixes.  I could go either way on some of the error path changes.

James

Re: Linux 2.6.38-rc4 (target_core: rmmod GP fault)

[Nicholas A. Bellinger]

On Wed, 2011-02-09 at 14:28 -0600, James Bottomley wrote:
> On Wed, 2011-02-09 at 12:20 -0800, Nicholas A. Bellinger wrote:
> > On Wed, 2011-02-09 at 14:13 -0600, James Bottomley wrote:
> > > Firstly, could we get the serious bug fixes identified and separated
> > > from the general enhancement updates, so they can go in a fixes tree
> > > without depending on enhancements?  The former category would include
> > > the /proc interface removal, since we don't want the legacy interface to
> > > be in a released kernel.
> > > 
> > 
> > Everything in those two series should be considered bug fixes and
> > immediate for-38 mainline material.
> 
> Things like this:
> 
> target: remove EXTRA_CFLAGS
> target: Remove unnecessary container_of() pointer check
> target: Remove unnecessary se_clear_dev_ports legacy code
> target: Remove spurious double cast from structure macro accessors
> target: Convert TMR REQ/RSP definitions to target namespace

This is an important one, as using w/o TMR_* prefixed definitions for
task management response/response defs, we run into problems with
existing include/scsi/scsi.h message codes.

> target: Minor sparse warning fixes and annotations
> target: Remove unneeded test of se_cmd
> 
> Are not serious bug fixes.  I could go either way on some of the error path changes.
> 

Yes, these others are minor items that have been submitted by people
(hch, roland, jesper, danc) who have been reviewing target code since it
was merged for .38-rc1.

Considering how minor these are I would prefer to have these merged,
than deferring for-39.  If not, then I will need to respin tree w/o
their cleanups if what you prefer to be sent to Linus for-38, there are
3 other bugfix patches in the upstream LIO tree that I have been saving
for-38-rc5 since for-38-rc4 was cut(considering the two outstanding
series).  I would like to have these included as well.

Do you want me to send them all to the linux-scsi list again...?

--nab

  



> James
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html