Linux-Next discussions
 help / color / mirror / Atom feed
* Re: linux-next: manual merge of the ttydev tree with the usb.current tree
From: Greg KH @ 2009-07-28 16:32 UTC (permalink / raw)
  To: Alan Cox; +Cc: Stephen Rothwell, Oliver Neukum, linux-next, linux-kernel
In-Reply-To: <20090728141740.44d53b68@lxorguk.ukuu.org.uk>

On Tue, Jul 28, 2009 at 02:17:40PM +0100, Alan Cox wrote:
> On Tue, 28 Jul 2009 22:35:04 +1000
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Hi Alan,
> > 
> > On Tue, 28 Jul 2009 13:29:11 +0100 Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > >
> > > I need to look at the actual diff, but the combination looks completely
> > > bogus unless I'm misreading the fixup which is possible.
> > 
> > Below is the actual patch from the usb.current tree.
> 
> Thanks - ok that is probably safe. The change I was worried about (the
> error paths not adjusting port->count are ok as it gets zeroed within the
> mutex)
> 
> Not sure its safe versus hangup but neither was the old code 8)
> 
> Oliver: I'll send you an alternative patch later today/tomorrow that uses
> the ASYNC flags.

Should I just drop Oliver's existing patch from my tree for now then?

thanks,

greg k-h

^ permalink raw reply

* Re: linux-next: manual merge of the ttydev tree with the usb.current tree
From: Alan Cox @ 2009-07-28 13:17 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Oliver Neukum, linux-next, linux-kernel, Greg KH
In-Reply-To: <20090728223504.6a6ae8e7.sfr@canb.auug.org.au>

On Tue, 28 Jul 2009 22:35:04 +1000
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Alan,
> 
> On Tue, 28 Jul 2009 13:29:11 +0100 Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> >
> > I need to look at the actual diff, but the combination looks completely
> > bogus unless I'm misreading the fixup which is possible.
> 
> Below is the actual patch from the usb.current tree.

Thanks - ok that is probably safe. The change I was worried about (the
error paths not adjusting port->count are ok as it gets zeroed within the
mutex)

Not sure its safe versus hangup but neither was the old code 8)

Oliver: I'll send you an alternative patch later today/tomorrow that uses
the ASYNC flags.

Alan

^ permalink raw reply

* Re: linux-next: manual merge of the ttydev tree with the usb.current tree
From: Stephen Rothwell @ 2009-07-28 12:35 UTC (permalink / raw)
  To: Alan Cox; +Cc: Oliver Neukum, linux-next, linux-kernel, Greg KH
In-Reply-To: <20090728132911.03ff78ea@lxorguk.ukuu.org.uk>

Hi Alan,

On Tue, 28 Jul 2009 13:29:11 +0100 Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> I need to look at the actual diff, but the combination looks completely
> bogus unless I'm misreading the fixup which is possible.

Below is the actual patch from the usb.current tree.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

>From oliver@neukum.org  Sat Jul 18 15:45:44 2009
From: Oliver Neukum <oliver@neukum.org>
Date: Sat, 18 Jul 2009 15:47:17 +0200
Subject: USB: fix usage count in usb serial generic open regarding autoresume
To: Matthew Garrett <mjg59@srcf.ucam.org>, Greg KH <greg@kroah.com>, Alan Stern <stern@rowland.harvard.edu>, linux-usb@vger.kernel.org
Message-ID: <200907181547.17813.oliver@neukum.org>
Content-Disposition: inline


The resume handler has to resubmit the reading URBs if the device is
resumed while opened. But the open() method bumps the counter before
it resumes a device. The fix is to increment the counter only after
the resumption or if no resumption is attempted.

Signed-off-by: Oliver Neukum <oliver@neukum.org>
Tested-by: Matthew Garrett <mjg@redhat.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>


---
 drivers/usb/serial/usb-serial.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial/usb-serial.c
@@ -214,15 +214,13 @@ static int serial_open (struct tty_struc
 		goto bailout_port_put;
 	}
 
-	++port->port.count;
-
 	/* set up our port structure making the tty driver
 	 * remember our port object, and us it */
 	tty->driver_data = port;
 	tty_port_tty_set(&port->port, tty);
 
 	/* If the console is attached, the device is already open */
-	if (port->port.count == 1 && !port->console) {
+	if (!port->port.count && !port->console) {
 
 		/* lock this module before we call it
 		 * this may fail, which means we must bail out,
@@ -240,12 +238,16 @@ static int serial_open (struct tty_struc
 		if (retval)
 			goto bailout_module_put;
 
+		++port->port.count;
+
 		/* only call the device specific open if this
 		 * is the first time the port is opened */
 		retval = serial->type->open(tty, port, filp);
 		if (retval)
 			goto bailout_interface_put;
 		mutex_unlock(&serial->disc_mutex);
+	} else {
+		++port->port.count;
 	}
 	mutex_unlock(&port->mutex);
 	/* Now do the correct tty layer semantics */

^ permalink raw reply

* Re: linux-next: manual merge of the ttydev tree with the usb.current tree
From: Alan Cox @ 2009-07-28 12:29 UTC (permalink / raw)
  To: Oliver Neukum; +Cc: Stephen Rothwell, linux-next, linux-kernel, Greg KH
In-Reply-To: <200907281410.41449.oliver@neukum.org>

> As serial_open() takes the lock, resume() must not do so.
> If however, remote wakeup is used a lock must be taken
> to look at port->count reliably. As this is impossible, the patch
> implementing use of remote wakeup for the option driver
> implements a private flag for opened ports.

I need to look at the actual diff, but the combination looks completely
bogus unless I'm misreading the fixup which is possible.

The way the core serial code and most other drivers do this is to keep
track of the port ASYNC_INITIALIZED flag, which indicates (in the non USB
cases but trivially fixable for the USB cases) that the port hardware is
initialized. We now set it on an open but we don't clear it on
serial_do_down() finishing.

^ permalink raw reply

* Re: linux-next: manual merge of the ttydev tree with the usb.current tree
From: Oliver Neukum @ 2009-07-28 12:10 UTC (permalink / raw)
  To: Alan Cox; +Cc: Stephen Rothwell, linux-next, linux-kernel, Greg KH
In-Reply-To: <20090728112608.09a494e0@lxorguk.ukuu.org.uk>

Am Dienstag, 28. Juli 2009 12:26:08 schrieb Alan Cox:
> On Tue, 28 Jul 2009 14:01:10 +1000
>
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Hi Alan,
> >
> > Today's linux-next merge of the ttydev tree got a conflict in
> > drivers/usb/serial/usb-serial.c between commit
> > a00b8d98aca97bfb6fa983f41dae25b424058592 ("USB: fix usage count in usb
> > serial generic open regarding autoresume") from the usb.current tree	
>
> That looks wrong. The extra fiddling with port.count looks both unsafe
> and incorrect. I've never seen the "autoresume" patch referred to so I've
> no idea what it is trying to do

The problem is subdrivers looking at port->count to determine
whether URBs have to be resubmitted. That must happen once.
Therefore if serial_open() needs to do it itself it must make sure
resume() runs without port->count already incremented.

As serial_open() takes the lock, resume() must not do so.
If however, remote wakeup is used a lock must be taken
to look at port->count reliably. As this is impossible, the patch
implementing use of remote wakeup for the option driver
implements a private flag for opened ports.

This code from option_resume():

for (i = 0; i < serial->num_ports; i++) {
		/* walk all ports */
		port = serial->port[i];
		portdata = usb_get_serial_port_data(port);
		mutex_lock(&port->mutex);

		/* skip closed ports */
		if (!port->port.count) {
			mutex_unlock(&port->mutex);
			continue;
		}

		for (j = 0; j < N_IN_URB; j++) {
			urb = portdata->in_urbs[j];
			err = usb_submit_urb(urb, GFP_NOIO);
			if (err < 0) {
				mutex_unlock(&port->mutex);
				err("%s: Error %d for bulk URB %d",
					 __func__, err, i);
				return err;
			}
		}
		mutex_unlock(&port->mutex);

must not take the port->mutex.

Unfortunately I have no access to my trees today and yesterday.

	Regards
		Oliver

^ permalink raw reply

* Re: Merge request for kmemleak patches
From: Stephen Rothwell @ 2009-07-28 11:00 UTC (permalink / raw)
  To: Catalin Marinas; +Cc: linux-next
In-Reply-To: <1248772559.17665.12.camel@pc1117.cambridge.arm.com>

[-- Attachment #1: Type: text/plain, Size: 991 bytes --]

Hi Catalin,

On Tue, 28 Jul 2009 10:15:59 +0100 Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> There are a few more kmemleak patches for the upcoming merging window
> (the first one will be pushed before). Could you please pull them into
> the -next tree? Thanks.
> 
>   git://linux-arm.org/linux-2.6.git kmemleak

I have added the tree back for tomorrow.

What I tell everyone: all patches/commits in the tree/series must
have been:

	posted to a relevant mailing list
	reviewed
	unit tested
	destined for the next merge window (or the current release)

*before* they are included.  The linux-next tree is for integration
testing and to lower the impact of conflicts between subsystems in the
next merge window.

Basically, this should be just what you would send to Linus (or ask him
to fetch).  It is allowed to be rebased if you deem it necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply

* Re: linux-next: manual merge of the ttydev tree with the usb.current tree
From: Alan Cox @ 2009-07-28 10:26 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Oliver Neukum, Greg KH
In-Reply-To: <20090728140110.7cfe7c22.sfr@canb.auug.org.au>

On Tue, 28 Jul 2009 14:01:10 +1000
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Alan,
> 
> Today's linux-next merge of the ttydev tree got a conflict in
> drivers/usb/serial/usb-serial.c between commit
> a00b8d98aca97bfb6fa983f41dae25b424058592 ("USB: fix usage count in usb
> serial generic open regarding autoresume") from the usb.current tree

That looks wrong. The extra fiddling with port.count looks both unsafe
and incorrect. I've never seen the "autoresume" patch referred to so I've
no idea what it is trying to do

Greg ?

^ permalink raw reply

* Merge request for kmemleak patches
From: Catalin Marinas @ 2009-07-28  9:15 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next

Hi Stephen,

There are a few more kmemleak patches for the upcoming merging window
(the first one will be pushed before). Could you please pull them into
the -next tree? Thanks.


The following changes since commit 4be3bd7849165e7efa6b0b35a23d6a3598d97465:
  Linus Torvalds (1):
        Linux 2.6.31-rc4

are available in the git repository at:

  git://linux-arm.org/linux-2.6.git kmemleak

Catalin Marinas (8):
      kmemleak: Protect the seq start/next/stop sequence by rcu_read_lock()
      kmemleak: Dump object information on request
      kmemleak: Allow rescheduling during an object scanning
      kmemleak: Mark the early log buffer as __initdata
      kmemleak: Save the stack trace for early allocations
      kmemleak: Do not report alloc_bootmem blocks as leaks
      kmemleak: Inform kmemleak about kernel stack allocation
      kmemleak: Always scan the task stacks

Sergey Senozhatsky (1):
      kmemleak: Printing of the objects hex dump

 Documentation/kmemleak.txt         |   12 +-
 arch/x86/include/asm/thread_info.h |    7 +-
 arch/x86/kernel/process.c          |    1 +
 include/linux/kmemleak.h           |   18 ++--
 kernel/fork.c                      |    7 +-
 mm/bootmem.c                       |    6 +-
 mm/kmemleak.c                      |  199 ++++++++++++++++++++++++++----------
 7 files changed, 179 insertions(+), 71 deletions(-)

-- 
Catalin

^ permalink raw reply

* linux-next: Tree for July 28
From: Stephen Rothwell @ 2009-07-28  7:42 UTC (permalink / raw)
  To: linux-next; +Cc: LKML

[-- Attachment #1: Type: text/plain, Size: 8036 bytes --]

Hi all,

Changes since 20090727:

Removed tree:	benh-mm (merged into Linus' tree).

This tree fails to build for powerpc allyesconfig (final link problem).

The net tree lost its build failure but gained 2 conflicts against the
wireless-current tree.

The ttydev tree gained a conflict against the usb.current tree.

The drbd tree lost its build failures.

I merged an update of Linus' tree to get a couple of fixes.

----------------------------------------------------------------------------

I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
(patches at
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES) and i386, sparc and sparc64 defconfig.
These builds also have CONFIG_ENABLE_WARN_DEPRECATED,
CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 135 trees (counting Linus' and 19 trees of patches pending for
Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Jan Dittmer for adding the linux-next tree to his build tests
at http://l4x.org/k/ , the guys at http://test.kernel.org/ and Randy
Dunlap for doing many randconfig builds.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging fixes/fixes
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/master
Merging quilt/driver-core.current
Merging quilt/usb.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
Merging crypto-current/master
Merging dwmw2/master
Merging arm/devel
Merging davinci/for-next
Merging pxa/for-next
Merging thumb-2/thumb-2
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging microblaze/next
Merging mips/mips-for-linux-next
CONFLICT (content): Merge conflict in arch/mips/cavium-octeon/dma-octeon.c
CONFLICT (add/add): Merge conflict in arch/mips/cavium-octeon/executive/cvmx-helper-errata.c
CONFLICT (content): Merge conflict in arch/mips/mm/tlbex.c
CONFLICT (content): Merge conflict in arch/mips/sibyte/swarm/setup.c
CONFLICT (content): Merge conflict in drivers/char/hw_random/Kconfig
CONFLICT (content): Merge conflict in drivers/char/hw_random/Makefile
CONFLICT (add/add): Merge conflict in drivers/dma/txx9dmac.c
Merging parisc/master
Merging powerpc/next
Merging 4xx/next
Merging galak/next
Merging s390/features
Merging sh/master
Merging sparc/master
Merging xtensa/master
Merging cifs/master
Merging configfs/linux-next
CONFLICT (content): Merge conflict in fs/configfs/dir.c
Merging ecryptfs/next
Merging ext3/for_next
Merging ext4/next
Merging fatfs/master
Merging fuse/for-next
Merging gfs2/master
Merging jfs/next
Merging nfs/linux-next
Merging nfsd/nfsd-next
Merging nilfs2/for-next
Merging ocfs2/linux-next
Merging squashfs/master
Merging v9fs/for-next
Merging ubifs/linux-next
Merging xfs/master
Merging reiserfs-bkl/reiserfs/kill-bkl-rc6
CONFLICT (content): Merge conflict in fs/reiserfs/journal.c
CONFLICT (content): Merge conflict in fs/reiserfs/super.c
Merging vfs/for-next
Merging pci/linux-next
Merging hid/for-next
Merging quilt/i2c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/master
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/board-dm646x-evm.c
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/dm355.c
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/dm644x.c
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/dm646x.c
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/include/mach/dm355.h
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/include/mach/dm644x.h
CONFLICT (content): Merge conflict in drivers/media/dvb/b2c2/flexcop-fe-tuner.c
Merging quota/for_next
Merging kbuild/master
Merging ide/master
Merging libata/NEXT
Merging infiniband/for-next
Merging acpi/test
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/master
Merging dlm/next
Merging scsi/master
Merging async_tx/next
Merging udf/for_next
Merging net/master
CONFLICT (content): Merge conflict in drivers/net/wireless/iwlwifi/iwl-3945.h
CONFLICT (content): Merge conflict in drivers/net/wireless/iwlwifi/iwl-tx.c
CONFLICT (content): Merge conflict in drivers/net/wireless/iwlwifi/iwl3945-base.c
Merging wireless/master
Merging mtd/master
Merging crypto/master
Merging sound/for-next
Merging cpufreq/next
Merging quilt/rr
Merging mmc/next
Merging input/next
Merging lsm/for-next
Merging block/for-next
Merging quilt/device-mapper
Merging embedded/master
Merging firmware/master
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging kgdb/kgdb-next
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
Merging mfd/for-next
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging voltage/for-next
Merging security-testing/next
Merging lblnet/master
Merging quilt/ttydev
CONFLICT (content): Merge conflict in drivers/usb/serial/usb-serial.c
Merging agp/agp-next
Merging uwb/for-upstream
Merging watchdog/master
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
Merging osd/linux-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
Merging audit/for-next
Merging omap/for-next
Merging quilt/aoe
Merging suspend/linux-next
Merging bluetooth/master
Merging edac-amd/for-next
Merging fsnotify/for-next
CONFLICT (content): Merge conflict in fs/notify/inotify/inotify_user.c
Merging irda/for-next
Merging hwlat/for-linus
Merging drbd/drbd
Merging tip/auto-latest
CONFLICT (content): Merge conflict in arch/x86/include/asm/termios.h
CONFLICT (content): Merge conflict in drivers/oprofile/oprofile_stats.c
CONFLICT (content): Merge conflict in include/linux/rcupdate.h
Merging percpu/for-next
CONFLICT (content): Merge conflict in arch/sh/kernel/vmlinux.lds.S
CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/perf_counter.c
CONFLICT (content): Merge conflict in drivers/cpufreq/cpufreq_ondemand.c
Merging sfi/sfi-test
Merging asm-generic/next
Merging quilt/driver-core
CONFLICT (content): Merge conflict in init/main.c
Merging quilt/usb
CONFLICT (content): Merge conflict in drivers/usb/gadget/m66592-udc.c
Merging quilt/staging
Merging scsi-post-merge/master
Merging updated origin/master
CONFLICT (content): Merge conflict in drivers/usb/serial/usb-serial.c

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply

* Re: linux-next: Tree for July 15 (bdi warning)
From: Jens Axboe @ 2009-07-28  7:14 UTC (permalink / raw)
  To: Bartlomiej Zolnierkiewicz; +Cc: Stephen Rothwell, linux-next, LKML
In-Reply-To: <200907152041.08025.bzolnier@gmail.com>

On Wed, Jul 15 2009, Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 15 July 2009 08:18:41 Stephen Rothwell wrote:
> > Hi all,
> > 
> > Changes since 20090714:
> 
> Jens, I see the following warning sometimes during disconnect
> of usb-storage device, is this anything to be worried about?

Yeah, that should not trigger. It essentially means that the device is
gone, with dirty data still present....

> ------------[ cut here ]------------
> WARNING: at mm/backing-dev.c:787 bdi_destroy+0x1e/0x4d()
> Hardware name: Extensa 2900
> Modules linked in: nls_iso8859_1 nls_cp437 vfat fat usb_storage radeon sco bnep l2cap bluetooth rfkill lib80211_crypt_tkip xt_state ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 acerhk binfmt_misc uinput snd_intel8x0m snd_intel8x0 snd_ac97_codec ipw2200 ac97_bus snd_pcm snd_timer libipw snd soundcore uhci_hcd ehci_hcd parport_pc snd_page_alloc lib80211 parport [last unloaded: scsi_wait_scan]
> Pid: 183, comm: khubd Tainted: G   M       2.6.31-rc3-next-20090715-03649-g2a49c7b #23
> Call Trace:
>  [<c0129db9>] warn_slowpath_common+0x65/0x7c
>  [<c01705c7>] ? bdi_destroy+0x1e/0x4d
>  [<c0129ddd>] warn_slowpath_null+0xd/0x10
>  [<c01705c7>] bdi_destroy+0x1e/0x4d
>  [<c0229d3d>] blk_release_queue+0x38/0x47
>  [<c0233f10>] kobject_release+0x3f/0x4f
>  [<c0233ed1>] ? kobject_release+0x0/0x4f
>  [<c02349c1>] kref_put+0x39/0x42
>  [<c0233e4d>] kobject_put+0x37/0x3c
>  [<c02285cb>] blk_put_queue+0xd/0xf
>  [<c0228747>] blk_cleanup_queue+0x3d/0x41
>  [<c02b9713>] scsi_free_queue+0x8/0xa
>  [<c02bd0f9>] scsi_device_dev_release_usercontext+0xf6/0x12c
>  [<c02bd003>] ? scsi_device_dev_release_usercontext+0x0/0x12c
>  [<c0137c3c>] execute_in_process_context+0x1d/0x5b
>  [<c02bd001>] scsi_device_dev_release+0x13/0x15
>  [<c02ae690>] device_release+0x35/0x5a
>  [<c0233f10>] kobject_release+0x3f/0x4f
>  [<c0233ed1>] ? kobject_release+0x0/0x4f
>  [<c02349c1>] kref_put+0x39/0x42
>  [<c0233e4d>] kobject_put+0x37/0x3c
>  [<c02ae459>] put_device+0xf/0x11
>  [<c02bd3df>] __scsi_remove_device+0x61/0x65
>  [<c02bb3a8>] scsi_forget_host+0x35/0x51
>  [<c02b6544>] scsi_remove_host+0x69/0xcd
>  [<e0833684>] quiesce_and_remove_host+0x4c/0x7e [usb_storage]
>  [<e083376a>] usb_stor_disconnect+0x13/0x1d [usb_storage]
>  [<c02e039f>] usb_unbind_interface+0x3b/0xa0
>  [<c02b0c84>] __device_release_driver+0x47/0x7f
>  [<c02b0d59>] device_release_driver+0x18/0x23
>  [<c02b04bb>] bus_remove_device+0x7f/0x8c
>  [<c02af04a>] device_del+0xf0/0x127
>  [<c02de6a3>] usb_disable_device+0x61/0xbf
>  [<c02dab52>] usb_disconnect+0x7e/0xda
>  [<c02db666>] hub_thread+0x30f/0xad5
>  [<c013a52d>] ? autoremove_wake_function+0x0/0x2f
>  [<c011eca9>] ? complete+0x34/0x3e
>  [<c02db357>] ? hub_thread+0x0/0xad5
>  [<c013a2f3>] kthread+0x66/0x6b
>  [<c013a28d>] ? kthread+0x0/0x6b
>  [<c01034eb>] kernel_thread_helper+0x7/0x10
> ---[ end trace d1600192f6c800d2 ]---

-- 
Jens Axboe

^ permalink raw reply

* linux-next: wireless tree build warning
From: Stephen Rothwell @ 2009-07-28  4:31 UTC (permalink / raw)
  To: John W. Linville; +Cc: linux-next, linux-kernel, Vivek Natarajan

[-- Attachment #1: Type: text/plain, Size: 502 bytes --]

Hi John,

Today's linux-next build (x86_64 allmodconfig) produced this warning:

drivers/net/wireless/ath/ath9k/eeprom.c: In function 'ath9k_hw_AR9287_check_eeprom':
drivers/net/wireless/ath/ath9k/eeprom.c:2866: warning: comparison of distinct pointer types lacks a cast

Introduced by commit ac88b6ecdfa629fd1261dab1504d78a56fd4cabf ("ath9k:
Add support for AR9287 based chipsets").

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply

* Re: linux-next: tree build failure
From: Stephen Rothwell @ 2009-07-28  4:22 UTC (permalink / raw)
  To: David Miller; +Cc: keil, linux-next, linux-kernel
In-Reply-To: <20090727.080617.30802851.davem@davemloft.net>

[-- Attachment #1: Type: text/plain, Size: 527 bytes --]

Hi Dave, Karsten,

On Mon, 27 Jul 2009 08:06:17 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
>
> From: Karsten Keil <keil@b1-systems.de>
> Date: Mon, 27 Jul 2009 11:21:33 +0200
> 
> > Sorry for that, yes this fix is correct - I really should test allyesconfig 
> > more times by myself  :-(.

I don't really expect people to do allyesconfig build very often.

> > ACK.
> 
> Applied.

Thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply

* Re: linux-next: drbd tree build failure
From: Stephen Rothwell @ 2009-07-28  4:20 UTC (permalink / raw)
  To: Philipp Reisner; +Cc: Lars Ellenberg, linux-next, linux-kernel, Rusty Russell
In-Reply-To: <200907271917.56148.philipp.reisner@linbit.com>

[-- Attachment #1: Type: text/plain, Size: 346 bytes --]

Hi Philipp, Lars,

On Mon, 27 Jul 2009 19:17:55 +0200 Philipp Reisner <philipp.reisner@linbit.com> wrote:
>
> Ok. Lars' patch is now complete and arrived in the git tree...
> 
> It should build now with Rusty's paches.

Thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply

* Re: linux-next: drbd tree build failure
From: Stephen Rothwell @ 2009-07-28  4:20 UTC (permalink / raw)
  To: Philipp Reisner; +Cc: linux-next, linux-kernel
In-Reply-To: <200907271109.33271.philipp.reisner@linbit.com>

[-- Attachment #1: Type: text/plain, Size: 2219 bytes --]

Hi Philipp,

On Mon, 27 Jul 2009 11:09:32 +0200 Philipp Reisner <philipp.reisner@linbit.com> wrote:
>
> On Monday 27 July 2009 09:37:54 Stephen Rothwell wrote:
> >
> > Today's linux-next build (powerpc allyesconfig) failed like this:
> >
> > drivers/block/drbd/drbd_trace.o: In function `.roles_to_name':
> > (.text+0x64): multiple definition of `.roles_to_name'
> > drivers/block/drbd/drbd.o:(.text+0x28eb8): first defined here
> > drivers/block/drbd/drbd_trace.o: In function `disks_to_name':
> > (.opd+0x30): multiple definition of `disks_to_name'
> > drivers/block/drbd/drbd.o:(.opd+0x1b78): first defined here
> > drivers/block/drbd/drbd_trace.o: In function `roles_to_name':
> > (.opd+0x18): multiple definition of `roles_to_name'
> > drivers/block/drbd/drbd.o:(.opd+0x1b60): first defined here
> > drivers/block/drbd/drbd_trace.o: In function `.conns_to_name':
> > (.text+0x0): multiple definition of `.conns_to_name'
> > drivers/block/drbd/drbd.o:(.text+0x28e54): first defined here
> > drivers/block/drbd/drbd_trace.o: In function `set_st_err_name':
> > (.opd+0x48): multiple definition of `set_st_err_name'
> > drivers/block/drbd/drbd.o:(.opd+0x1b90): first defined here
> > drivers/block/drbd/drbd_trace.o: In function `.disks_to_name':
> > (.text+0xcc): multiple definition of `.disks_to_name'
> > drivers/block/drbd/drbd.o:(.text+0x28f20): first defined here
> > drivers/block/drbd/drbd_trace.o: In function `conns_to_name':
> > (.opd+0x0): multiple definition of `conns_to_name'
> > drivers/block/drbd/drbd.o:(.opd+0x1b48): first defined here
> > drivers/block/drbd/drbd_trace.o: In function `.set_st_err_name':
> > (.text+0x134): multiple definition of `.set_st_err_name'
> > drivers/block/drbd/drbd.o:(.text+0x28f88): first defined here
> >
> > I applied the following patch to mark DRBD_TRACE broken for now.
> 
> I have fixed that issue. With the next pull, drbd_tracing should
> compile on PPC. 

Thanks.

> BTW, we are working on making our stuff compatible with Rusty's
> cpu set changes. I expect that this will be finished soon...

Excellent.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply

* Re: linux-next: drbd tree build failure
From: Stephen Rothwell @ 2009-07-28  4:19 UTC (permalink / raw)
  To: Philipp Reisner; +Cc: Alexander Beregalov, linux-next, linux-kernel
In-Reply-To: <200907271707.58733.philipp.reisner@linbit.com>

[-- Attachment #1: Type: text/plain, Size: 605 bytes --]

Hi Philipp,

On Mon, 27 Jul 2009 17:07:58 +0200 Philipp Reisner <philipp.reisner@linbit.com> wrote:
>
> On Monday 27 July 2009 13:38:44 Alexander Beregalov wrote:
> > One more issue
> >
> > drivers/block/drbd/drbd_main.c: In function 'drbd_buildtag':
> > drivers/block/drbd/drbd_main.c:3738: error: dereferencing pointer to
> > incomplete type
> 
> Ohh, right. I have never tried to build a kernel with the DRBD patch
> without CONFIG_MODULES set.
> 
> It is fixed now.

Thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply

* linux-next: manual merge of the ttydev tree with the usb.current tree
From: Stephen Rothwell @ 2009-07-28  4:01 UTC (permalink / raw)
  To: Alan Cox; +Cc: linux-next, linux-kernel, Oliver Neukum, Greg KH

Hi Alan,

Today's linux-next merge of the ttydev tree got a conflict in
drivers/usb/serial/usb-serial.c between commit
a00b8d98aca97bfb6fa983f41dae25b424058592 ("USB: fix usage count in usb
serial generic open regarding autoresume") from the usb.current tree and
commit 73fed8403623653560cc2f35c9b62891adaf6b4b
("tty-usb-error-unlock-fix") from the ttydev tree.

Just context changes.  I have fixed it up (see below) and can carry the
fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/usb/serial/usb-serial.c
index 06579a8,99188c9..0000000
--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial/usb-serial.c
@@@ -220,8 -224,8 +222,8 @@@ static int serial_open (struct tty_stru
  	tty_port_tty_set(&port->port, tty);
  
  	/* If the console is attached, the device is already open */
 -	if (port->port.count == 1 && !port->console) {
 +	if (!port->port.count && !port->console) {
- 
+ 		first = 1;
  		/* lock this module before we call it
  		 * this may fail, which means we must bail out,
  		 * safe because we are called with BKL held */
@@@ -246,8 -248,7 +248,9 @@@
  		if (retval)
  			goto bailout_interface_put;
  		mutex_unlock(&serial->disc_mutex);
+ 		set_bit(ASYNCB_INITIALIZED, &port->port.flags);
 +	} else {
 +		++port->port.count;
  	}
  	mutex_unlock(&port->mutex);
  	/* Now do the correct tty layer semantics */

^ permalink raw reply

* linux-next: manual merge of the net tree with the wireless-current tree
From: Stephen Rothwell @ 2009-07-28  1:59 UTC (permalink / raw)
  To: David Miller
  Cc: linux-next, linux-kernel, Johannes Berg, John W. Linville,
	Reinette Chatre

Hi David,

Today's linux-next merge of the net tree got a conflict in
drivers/net/wireless/iwlwifi/iwl-tx.c between commit
3995bd9332a51b626237d6671cfeb7235e6c1305 ("iwlwifi: fix TX queue race")
from the wireless-current tree and commit
45af81956e990440fe78d6d41f847664cb620609 ("iwlwifi: make software queue
assignment more efficient") from the net tree.

Just overlapping context.  I fixed it up (see below) and can carry the
fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/net/wireless/iwlwifi/iwl-tx.c
index 2e89040,0912987..0000000
--- a/drivers/net/wireless/iwlwifi/iwl-tx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-tx.c
@@@ -744,21 -749,16 +747,19 @@@ int iwl_tx_skb(struct iwl_priv *priv, s
  		hdr->seq_ctrl |= cpu_to_le16(seq_number);
  		seq_number += 0x10;
  		/* aggregation is on for this <sta,tid> */
- 		if (info->flags & IEEE80211_TX_CTL_AMPDU) {
+ 		if (info->flags & IEEE80211_TX_CTL_AMPDU)
  			txq_id = priv->stations[sta_id].tid[tid].agg.txq_id;
  	}
  
  	txq = &priv->txq[txq_id];
+ 	swq_id = txq->swq_id;
  	q = &txq->q;
- 	txq->swq_id = swq_id;
  
 -	spin_lock_irqsave(&priv->lock, flags);
 +	if (unlikely(iwl_queue_space(q) < q->high_mark))
 +		goto drop_unlock;
 +
 +	if (ieee80211_is_data_qos(fc))
 +		priv->stations[sta_id].tid[tid].tfds_in_queue++;
  
  	/* Set up driver data for this TFD */
  	memset(&(txq->txb[q->write_ptr]), 0, sizeof(struct iwl_tx_info));

^ permalink raw reply

* linux-next: manual merge of the net tree with the wireless-current tree
From: Stephen Rothwell @ 2009-07-28  1:53 UTC (permalink / raw)
  To: David Miller; +Cc: linux-next, linux-kernel, reinette chatre, John W. Linville

[-- Attachment #1: Type: text/plain, Size: 631 bytes --]

Hi David,

Today's linux-next merge of the net tree got a conflicts in
drivers/net/wireless/iwlwifi/iwl-3945.h and
drivers/net/wireless/iwlwifi/iwl3945-base.c between commit
45f5fa32b130b2a59f9b726be45ce7fa73fb834c ("iwlagn: fix minimum number of
queues setting") from the wireless-current tree and commit
5905a1aa71488b5f78822100c865ed7c4f9fcd8f ("iwl3945: cleanup number of
queues settings") from the net tree.

The latter just removes the code that the former modifies.  I used the
version from the net tree.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply

* Re: linux-next: Tree for July 27 (tty locking)
From: Alan Cox @ 2009-07-27 21:34 UTC (permalink / raw)
  To: Bartlomiej Zolnierkiewicz; +Cc: Stephen Rothwell, linux-next, LKML
In-Reply-To: <200907272235.08319.bzolnier@gmail.com>

On Mon, 27 Jul 2009 22:35:08 +0200
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:

> 
> Hi,
> 
> On Monday 27 July 2009 10:05:52 Stephen Rothwell wrote:
> > Hi all,
> > 
> > Changes since 20090724:
> 
> Alan, it seems that tty still needs some polishing,
> I'm getting the following warning on boot:

Oh the -next tty patches need quite a bit of polishing yet. I've been
flat out dealing with fallout from the current kernel though so haven't
got time to deal with -next bugs just yet.

I know which diff that is however so I'll drop it out and push a new
-next tree.

^ permalink raw reply

* Re: linux-next: Tree for July 27 (tty locking)
From: Bartlomiej Zolnierkiewicz @ 2009-07-27 20:35 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, LKML, Alan Cox
In-Reply-To: <20090727180552.eb32515b.sfr@canb.auug.org.au>


Hi,

On Monday 27 July 2009 10:05:52 Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20090724:

Alan, it seems that tty still needs some polishing,
I'm getting the following warning on boot:

INFO: task hald-probe-seri:1779 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
hald-probe-se D 0000000b     0  1779   1734 0x00000004
 daf8cde0 00000046 b829e804 0000000b daf95a04 00000000 c054832c c054bec0
 daf95a04 00000000 c054bec0 c054bec0 00000001 00000000 00000000 00094e71
 00000000 b8209993 0000000b daf95780 00000246 00000000 00000002 00000000
Call Trace:
 [<c029b327>] ? tty_port_block_til_ready+0x1f/0x3c
 [<c0397be3>] mutex_lock_nested+0x167/0x28e
 [<c029b327>] tty_port_block_til_ready+0x1f/0x3c
 [<c02bdcdc>] uart_open+0x12a/0x1e9
 [<c0296742>] tty_open+0x291/0x38f
 [<c018b8bf>] chrdev_open+0x156/0x16d
 [<c0187f02>] __dentry_open+0x131/0x21b
 [<c019b5a5>] ? mntput_no_expire+0x19/0xb4
 [<c018808a>] nameidata_to_filp+0x2d/0x42
 [<c018b769>] ? chrdev_open+0x0/0x16d
 [<c01928d7>] do_filp_open+0x3dc/0x6dc
 [<c019a161>] ? alloc_fd+0xbd/0xca
 [<c0187cd6>] do_sys_open+0x48/0xe4
 [<c01191fb>] ? do_page_fault+0x262/0x290
 [<c0187db4>] sys_open+0x1e/0x26
 [<c0102948>] sysenter_do_call+0x12/0x36
INFO: lockdep is turned off.

with LOCKDEP=y:

=============================================
[ INFO: possible recursive locking detected ]
2.6.31-rc4-next-20090727-04601-g24690ff #43
---------------------------------------------
hald-probe-seri/1580 is trying to acquire lock:
 (&port->mutex){+.+.+.}, at: [<c029b327>] tty_port_block_til_ready+0x1f/0x3c

but task is already holding lock:
 (&port->mutex){+.+.+.}, at: [<c02bdc03>] uart_open+0x51/0x1e9

other info that might help us debug this:
1 lock held by hald-probe-seri/1580:
 #0:  (&port->mutex){+.+.+.}, at: [<c02bdc03>] uart_open+0x51/0x1e9

stack backtrace:
Pid: 1580, comm: hald-probe-seri Not tainted 2.6.31-rc4-next-20090727-04601-g24690ff #43
Call Trace:
 [<c0396406>] ? printk+0xf/0x11
 [<c014b29b>] __lock_acquire+0xc21/0x12b5
 [<c029b327>] ? tty_port_block_til_ready+0x1f/0x3c
 [<c014b975>] lock_acquire+0x46/0x62
 [<c029b327>] ? tty_port_block_til_ready+0x1f/0x3c
 [<c0397abf>] mutex_lock_nested+0x43/0x28e
 [<c029b327>] ? tty_port_block_til_ready+0x1f/0x3c
 [<c0149c14>] ? trace_hardirqs_on_caller+0x100/0x121
 [<c0149c40>] ? trace_hardirqs_on+0xb/0xd
 [<c029b327>] tty_port_block_til_ready+0x1f/0x3c
 [<c02bdcdc>] uart_open+0x12a/0x1e9
 [<c0296742>] tty_open+0x291/0x38f
 [<c018b8bf>] chrdev_open+0x156/0x16d
 [<c0187f02>] __dentry_open+0x131/0x21b
 [<c019b5a5>] ? mntput_no_expire+0x19/0xb4
 [<c018808a>] nameidata_to_filp+0x2d/0x42
 [<c018b769>] ? chrdev_open+0x0/0x16d
 [<c01928d7>] do_filp_open+0x3dc/0x6dc
 [<c019a161>] ? alloc_fd+0xbd/0xca
 [<c0187cd6>] do_sys_open+0x48/0xe4
 [<c01029fc>] ? restore_all_notrace+0x0/0x18
 [<c0187db4>] sys_open+0x1e/0x26
 [<c0102948>] sysenter_do_call+0x12/0x36

^ permalink raw reply

* Re: linux-next: drbd tree build failure
From: Philipp Reisner @ 2009-07-27 17:17 UTC (permalink / raw)
  To: Lars Ellenberg; +Cc: Stephen Rothwell, linux-next, linux-kernel, Rusty Russell
In-Reply-To: <20090727080957.GA8046@barkeeper1-xen.linbit>

On Monday 27 July 2009 10:09:57 Lars Ellenberg wrote:
> On Mon, Jul 27, 2009 at 03:48:16PM +1000, Stephen Rothwell wrote:
> > Hi Philipp,
> >
> > Today's linux-next build (x86_64 allmodconfig) failed like this:
> >
> > drivers/block/drbd/drbd_main.c: In function
> > 'drbd_thread_current_set_cpu': drivers/block/drbd/drbd_main.c:1592:
> > error: implicit declaration of function 'set_cpus_allowed'
> >
> > Introduced by commit 8a4ebc3fbd90072ac870064a930fe612eea6d9a1 ("DRBD:
> > main") from the drbd interacting with commit
> > 84cf7f02712e3491fb9776f950a8c4f413204c8b
> > ("cpumask:remove-set_cpus_allowed") from the rr tree.
> >
> > I am not sure what the transformation to the new infrastructure is here -
> > maybe Rusty can help?
> >
> > For today, I have reverted the rr tree commit above but we need a better
> > solution.
>
> I think we can easily use set_cpus_allowed_ptr() instead,
> as in fact, we do not have the cpu mask on the stack.
> But embeded in struct drbd_conf.

Ok. Lars' patch is now complete and arrived in the git tree...

It should build now with Rusty's paches.

-phil
-- 
: Dipl-Ing Philipp Reisner
: LINBIT | Your Way to High Availability
: Tel: +43-1-8178292-50, Fax: +43-1-8178292-82
: http://www.linbit.com

DRBD(R) and LINBIT(R) are registered trademarks of LINBIT, Austria.

^ permalink raw reply

* Re: linux-next: drbd tree build failure
From: Philipp Reisner @ 2009-07-27 15:07 UTC (permalink / raw)
  To: Alexander Beregalov; +Cc: Stephen Rothwell, linux-next, linux-kernel
In-Reply-To: <a4423d670907270438n3e8f07caoa45124b1bd7b2386@mail.gmail.com>

On Monday 27 July 2009 13:38:44 Alexander Beregalov wrote:
> One more issue
>
> drivers/block/drbd/drbd_main.c: In function 'drbd_buildtag':
> drivers/block/drbd/drbd_main.c:3738: error: dereferencing pointer to
> incomplete type

Ohh, right. I have never tried to build a kernel with the DRBD patch
without CONFIG_MODULES set.

It is fixed now.

-Phil
-- 
: Dipl-Ing Philipp Reisner
: LINBIT | Your Way to High Availability
: Tel: +43-1-8178292-50, Fax: +43-1-8178292-82
: http://www.linbit.com

DRBD(R) and LINBIT(R) are registered trademarks of LINBIT, Austria.

^ permalink raw reply

* Re: linux-next: tree build failure
From: David Miller @ 2009-07-27 15:06 UTC (permalink / raw)
  To: keil; +Cc: sfr, linux-next, linux-kernel
In-Reply-To: <200907271121.34348.keil@b1-systems.de>

From: Karsten Keil <keil@b1-systems.de>
Date: Mon, 27 Jul 2009 11:21:33 +0200

> On Montag, 27. Juli 2009 09:53:28 you wrote:
>> Hi Dave,
>>
>> Today's linux-next build (powerpc allyesconfig) failed like this:
>>
>> drivers/isdn/hisax/built-in.o: In function `setup_w6692':
>> (.opd+0x4a28): multiple definition of `setup_w6692'
>> drivers/isdn/hardware/built-in.o:(.opd+0x4e90): first defined here
>> drivers/isdn/hisax/built-in.o: In function `.setup_w6692':
>> (.devinit.text+0x5b14): multiple definition of `.setup_w6692'
>> drivers/isdn/hardware/built-in.o:(.text+0x8b75c): first defined here
>>
>> Caused by commit 707b2ce6c1f4f1261788f2ff09ad82c35e0e6240
>> ("mISDN: Add driver for Winbond cards").
>>
>> setup_w6692 appears in drivers/isdn/hardware/mISDN/w6692.c and
>> drivers/isdn/hisax/w6692.c.  I applied the patch below for today (this
>> may not be correct).
>>
> 
> Sorry for that, yes this fix is correct - I really should test allyesconfig 
> more times by myself  :-(.
> 
> ACK.

Applied.

^ permalink raw reply

* [PATCH] drbd: fix build when CONFIG_MODULES=n
From: Randy Dunlap @ 2009-07-27 14:55 UTC (permalink / raw)
  To: Stephen Rothwell, drbd-dev; +Cc: linux-next, LKML, akpm
In-Reply-To: <20090727180552.eb32515b.sfr@canb.auug.org.au>

On Mon, 27 Jul 2009 18:05:52 +1000 Stephen Rothwell wrote:

> Hi all,
> 
> Changes since 20090724:
> 
> New trees:
> 	drbd
> 
> The drbd tree gained two build failures for which I reverted a commit from
> the rr tree and applied a patch.
> ----------------------------------------------------------------------------


(already fixed?)

---
From: Randy Dunlap <randy.dunlap@oracle.com>

Fix drbd build when CONFIG_MODULES=n:
drivers/block/drbd/drbd_main.c:3738: error: dereferencing pointer to incomplete type

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: drbd-dev@lists.linbit.com
---
 drivers/block/drbd/drbd_main.c |    4 ++++
 1 file changed, 4 insertions(+)

--- linux-next-20090727.orig/drivers/block/drbd/drbd_main.c
+++ linux-next-20090727/drivers/block/drbd/drbd_main.c
@@ -3733,12 +3733,16 @@ const char *drbd_buildtag(void)
 
 	static char buildtag[38] = "\0uilt-in";
 
+#ifdef CONFIG_MODULES
 	if (buildtag[0] == 0) {
 		if (THIS_MODULE != NULL)
 			sprintf(buildtag, "srcversion: %-24s", THIS_MODULE->srcversion);
 		else
 			buildtag[0] = 'b';
 	}
+#else
+	buildtag[0] = 'b';
+#endif
 
 	return buildtag;
 }

^ permalink raw reply

* Re: linux-next: drbd tree build failure
From: Alexander Beregalov @ 2009-07-27 11:38 UTC (permalink / raw)
  To: Philipp Reisner; +Cc: Stephen Rothwell, linux-next, linux-kernel
In-Reply-To: <200907271109.33271.philipp.reisner@linbit.com>

One more issue

drivers/block/drbd/drbd_main.c: In function 'drbd_buildtag':
drivers/block/drbd/drbd_main.c:3738: error: dereferencing pointer to
incomplete type

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox