Re: 2.6.18-rc6-mm2

Re: 2.6.18-rc6-mm2

[Andy Whitcroft]

Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm2/
> 
> - autofs4 mounting remains busted.
> 
> - CONFIG_BLOCK=n doesn't (quite) work.  Will fix later.
> 
> - CONFIG_MSI=y is probably broken - try disabling it before reporting
>   interrupt-related oopses.  Then please report it whether or not that fixed
>   it.
> 
> - Could I point out the fifth bullet-point in the "Boilerplate" section,
>   below?
> 
> - git-cryptodev.patch is dropped due to my continuing inability to pull a
>   clean git diff (there is hope, but more work is needed)
> 
>   - Ditto git-sas.patch
> 
>   - And git-audit-master.patch (I think).
> 
>   Things will improve around the 2.6.19-rc1 timeframe.
> 
> - 1,915 patches breaks the previous record by ~200.
> 
> - This kernel includes the patch to sort the PCI devices breadth-first. 
>   This might cause strange things to happen (particular devices get assigned
>   to different /dev nodes, for example).  If this is suspected, please try
>   reverting gregkh-pci-pci-sort-device-lists-breadth-first.patch then send a
>   report.
> 
> 
> 
> Boilerplate:
> 
> - See the `hot-fixes' directory for any important updates to this patchset.
> 
> - To fetch an -mm tree using git, use (for example)
> 
>   git fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git v2.6.16-rc2-mm1
> 
> - -mm kernel commit activity can be reviewed by subscribing to the
>   mm-commits mailing list.
> 
>         echo "subscribe mm-commits" | mail majordomo@vger.kernel.org
> 
> - If you hit a bug in -mm and it is not obvious which patch caused it, it is
>   most valuable if you can perform a bisection search to identify which patch
>   introduced the bug.  Instructions for this process are at
> 
>         http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt
> 
>   But beware that this process takes some time (around ten rebuilds and
>   reboots), so consider reporting the bug first and if we cannot immediately
>   identify the faulty patch, then perform the bisection search.
> 
> - When reporting bugs, please try to Cc: the relevant maintainer and mailing
>   list on any email.
> 
> - When reporting bugs in this kernel via email, please also rewrite the
>   email Subject: in some manner to reflect the nature of the bug.  Some
>   developers filter by Subject: when looking for messages to read.
> 
> - Semi-daily snapshots of the -mm lineup are uploaded to
>   ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on
>   the mm-commits list.
> 
> 
> 
> 
> Changes since 2.6.18-rc6-mm1:
> 
> 
>  origin.patch
>  git-acpi.patch
>  git-alsa.patch
>  git-agpgart.patch
>  git-block.patch
>  git-cifs.patch
>  git-cpufreq.patch
>  git-drm.patch
>  git-dvb.patch
>  git-geode.patch
>  git-gfs2.patch
>  git-ia64.patch
>  git-ieee1394.patch
>  git-infiniband.patch
>  git-input.patch
>  git-intelfb.patch
>  git-kbuild.patch
>  git-libata-all.patch
>  git-lxdialog.patch
>  git-mtd.patch
>  git-netdev-all.patch
>  git-net.patch
>  git-nfs.patch
>  git-ocfs2.patch
>  git-parisc.patch
>  git-pcmcia.patch
>  git-powerpc.patch
>  git-r8169.patch
>  git-s390.patch
>  git-scsi-misc.patch

Seems that the module unload bug in scsi.c (details below) is still
there...  I'll follow up with the work around patch I am using.

-apw

Seems that -mm fails to compile when CONFIG_MODULES is set but
CONFIG_MODULE_UNLOAD is not.

   LD      .tmp_vmlinux1
  drivers/built-in.o(.text+0x47724): In function `scsi_device_put':
  drivers/scsi/scsi.c:887: undefined reference to `module_refcount'

Config fragment:
  CONFIG_MODULES=y
  # CONFIG_MODULE_UNLOAD is not set
  # CONFIG_MODULE_SRCVERSION_ALL is not set

This seems to be caused by changes in the scsi-misc git tree, from the
changes in the two commits below:

  [SCSI] sd: fix cache flushing on module removal
				(and individual device removal)
  [SCSI] fix up non-modular SCSI

  85b6c720b0931101c8bcc3a5abdc2b8514b0fb4b
  f479ab87936563a286b8aa0e39003c40fa31c6da

It looks very much like module_refcount is really not meant to be an
external interface, cirtainly its not available in all module
'load/unload modes'.

[PATCH] BODGE scsi misc module reference count checks with no MODULE_UNLOAD

[Andy Whitcroft]

BODGE scsi misc module reference count checks with no MODULE_UNLOAD

A quick bodge to try and get this to compile for testing.

Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index 20d2cdf..2acc0cb 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -884,7 +884,11 @@ void scsi_device_put(struct scsi_device 
 
 	/* The module refcount will be zero if scsi_device_get()
 	 * was called from a module removal routine */
-	if (module && module_refcount(module) != 0)
+	if (module
+#ifdef CONFIG_MODULE_UNLOAD
+			&& module_refcount(module) != 0
+#endif
+			)
 		module_put(module);
 	put_device(&sdev->sdev_gendev);
 }

Re: [PATCH] BODGE scsi misc module reference count checks with no MODULE_UNLOAD

[Helge Hafting]

Andy Whitcroft wrote:
> BODGE scsi misc module reference count checks with no MODULE_UNLOAD
>
> A quick bodge to try and get this to compile for testing.
>
> Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Thanks, this was necessary to compile a non-modular kernel.

Helge Hafting