2.6.17-rc6-mm1

2.6.17-rc6-mm1

[Andrew Morton]

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc6/2.6.17-rc6-mm1/

- Many more lockdep updates



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.




Changes since 2.6.17-rc5-mm3:


 git-acpi.patch
 git-agpgart.patch
 git-alsa.patch
 git-audit-master.patch
 git-block.patch
 git-cifs.patch
 git-cpufreq.patch
 git-dvb.patch
 git-gfs2.patch
 git-ia64.patch
 git-infiniband.patch
 git-input.patch
 git-intelfb.patch
 git-jfs.patch
 git-klibc.patch
 git-hdrcleanup.patch
 git-hdrinstall.patch
 git-libata-all.patch
 git-mips.patch
 git-mtd.patch
 git-mtd-fixup.patch
 git-netdev-all.patch
 git-net.patch
 git-nfs.patch
 git-powerpc.patch
 git-rbtree.patch
 git-sas.patch
 git-pcmcia.patch
 git-scsi-target.patch
 git-supertrak.patch
 git-watchdog.patch
 git-cryptodev.patch

 git trees

-nmclan_cs-dereferencing-skb-after-netif_rx.patch
-s390-irb-memcpy-argument-swap.patch
-s390-cio-non-unique-path-group-ids.patch
-sparsemem-build-fix.patch
-selinux-fix-sb_lock-sb_security_lock-nesting-was.patch
-alpha-smp-irq-routing-fix.patch
-fs-nameic-call-to-file_permission-under-a-spinlock-in-do_lookup_path.patch
-fs-nameic-call-to-file_permission-under-a-spinlock-in-do_lookup_path-fix.patch
-pmf_register_irq_client-gives-sleep-with-locks-held-warning.patch
-implement-get--set-tso-for-forcedeth-driver.patch
-maintainers-add-entries-for-bnx2-and-tg3.patch
-sbp2-fix-check-of-return-value-of.patch
-sata_sil24-sii3124-sata-driver-endian-problem.patch
-m48t86-ia64-build-fix.patch
-m68k-get_user-build-fix.patch
-uml-add-asm-irqflagsh.patch
-uml-fix-wall_to_monotonic-initialization.patch
-uml-fix-a-typo-in-do_uml_initcalls.patch
-uml-__user-annotation-in-arch_prctl.patch
-uml-more-__user-annotations.patch
-uml-add-ffreestanding-to-cflags.patch
-blk_start_queue-must-be-called-with-irq-disabled-add-warning.patch
-blktrace_apih-endian-annotations.patch
-dprintk-adjustments-to-cpufreq-nforce2.patch
-dprintk-adjustments-to-cpufreq-speedstep-centrino.patch
-cpufreq-dprintk-adjustments.patch
-mm-constify-drivers-char-keyboardc.patch
-input-fix-accuracy-of-fixp-arithh.patch
-input-use-enospc-instead-of-enomem-in-iforce-when-device-full.patch
-for_each_possible_cpu-mips.patch
-prevent-au1xmmcc-breakage-on-non-au1200-alchemy.patch
-clean-up-initcall-warning-for-netconsole.patch
-remove-dead-entry-in-net-wan-kconfig.patch
-eliminate-unused-proc-sys-net-ethernet.patch
-irda-missing-allocation-result-check-in-irlap_change_speed.patch
-pppoe-missing-result-check-in-__pppoe_xmit.patch
-lock-validator-netlinkc-netlink_table_grab-fix.patch
-x86_64-unexport-ia32_sys_call_table.patch
-x86_64-dont-warn-for-overflow-in-nommu-case-when-dma_mask-is-32bit-fix.patch

 Merged into mainline or a subsystem tree.

-fix-hpet-operation-on-32-bit-nvidia-platforms-build-fix.patch

 Folded into fix-hpet-operation-on-32-bit-nvidia-platforms.patch

+ep93xx-build-fix.patch
+fix-mempolicyh-build-error.patch
+fbcon-fix-limited-scroll-in-scroll_pan_redraw-mode.patch

 2.6.17 queue

+acpi-dock-driver-acpi_get_device-fix.patch

 Fix acpi-dock-driver.patch

+fix-possible-oops-in-cs4281-irq-handler.patch

 ALSA might-fix.

+zoran-strncpy-cleanup.patch

 zoran fix

+ieee1394-hl_irqs_lock-is-taken-in-hardware.patch
+ieee1394-adjust-code-formatting-in.patch

 More 1394 updates

-input-powermac-cleanup-of-mac_hid-and-support-for-ctrlclick-and-commandclick.patch

 Dropped.

+input-fix-comments-and-blank-lines-in-new-ff-code.patch

 input force-feedback cleanup

+kinit-convert--in-block-device-names-to-not.patch
+klibc-ia64-fix.patch

 Fix git-klibc.patch

+sata_sil24-endian-anotations.patch

 libata tweak

+lock-validator-fix-ns83820c-irq-flags-bug.patch
+lock-validator-fix-ns83820c-irq-flags-bug-part.patch
+lock-validator-fix-ns83820c-irq-flags-part-3.patch
+ipw2200-locking-fix.patch

 net driver fixes

+bugfix-pci-legacy-i-o-port-free-driver.patch
+msi-k8t-neo2-fir-run-only-where-needed.patch

 PCI fixes

+pcmcia-fix-kernel-doc-function-name.patch

 pcmcia kerneldoc fix

+gregkh-usb-usb-sisusbvga-possible-cleanups-fix.patch

 USB fix

+add-apple-macbook-product-ids-to-usbhid.patch

 new device IDs

+x86_64-mm-optimize-bitmap-weight.patch
+x86_64-mm-check_addr-cleanups.patch
+x86_64-mm-remove-redzone-comment.patch
+x86_64-mm-spinlock-short.patch

 x86_64 udpates

+revert-x86_64-mm-spinlock-short.patch

 Fix it

+x86-nmi-fix.patch
+x86-nmi-fix-2.patch

 Fix it some more, maybe

-swapless-pm-add-r-w-migration-entries-fix-2.patch
+swapless-pm-add-r-w-migration-entries-fix.patch

 Better mm fix

+initialise-total_memory-earlier.patch
+update-vm_total_pages-at-memory-hotadd.patch

 Avoid early oops in kswapd.

+i386-print-stack-size-in-oops-messages.patch

 Enhance x86 oops output.

+m68k-clean-up-uaccessh.patch

 m68k build fix

+powerpc-implement-support-for-setting.patch
+powerpc-implement-pr_et_unalign-prctls-for-powerpc.patch

 powerpc set-endianness prctl

+poison-add-use-more-constants.patch

 use poison.h some more.

-fix-kbuild-dependencies-for-synclink-drivers.patch

 Dropped.

-remove-dead-entry-in-net-wan-makefile.patch
+remove-dead-entry-in-net-wan-kconfig.patch

 Updated

+load_module-cleanup.patch

 cleanup

+radixtree-normalize-radix_tree_tag_get-return-value.patch
+#fix-irqpoll-to-honor-disable_irq.patch
+printk-time-parameter.patch
+correct-sak-description-in-sysrqtxt.patch
+add-v3020-rtc-support.patch
+add-v3020-rtc-support-tidy.patch
+correct-tty-doc.patch
+block-layer-early-detection-of-medium-not-present.patch
+scsi-core-and-sd-early-detection-of-medium-not-present.patch
+sd-early-detection-of-medium-not-present.patch

 Misc

+fix-typo-in-drivers-isdn-hisax-q931c.patch

 ISDN fix

+sched-mc-smt-power-savings-sched-policy.patch

 multicore/SMT scheduler features

+fix-rt-mutex-defaults-and-dependencies.patch

 rt-mutex Kconfig fixes

+readahead-call-scheme-fix-fastcall.patch

 readahead fix

+hpt3x7-merge-speedproc-handlers.patch
+fix-ide-deadlock-in-error-reporting-code.patch

 IDE updates

+gxfb-get-the-frambuffer-size-from-the-bios.patch
+detaching-fbcon-fix-vgacon-to-allow-retaking-of-the.patch
+detaching-fbcon-fix-give_up_console.patch
+detaching-fbcon-remove-calls-to-pci_disable_device.patch
+detaching-fbcon-add-sysfs-class-device-entry-for-fbcon.patch
+detaching-fbcon-clean-up-exit-code.patch
+detaching-fbcon-add-capability-to-attach-detach-fbcon.patch
+detaching-fbcon-update-documentation.patch

 fbdev/fbcon updates

+genirq-add-irq-chip-support-misroute-irq-dont-call-desc-chip-end.patch

 IRQ oops fix

+lock-validator-sparc64-sparc-m68k-alpha-cris-build-fix.patch
+lock-validator-floppyc-irq-release-fix-fix-fix.patch
+lock-validator-core-early_boot_irqs_-build-fix-sparc64-sparc-m68k-alpha-cris-irqtrace-build-fix.patch
+lock-validator-core-add-config_debug_non_nested_unlocks.patch
+better-lock-debugging-remove-mutex-deadlock-checking-code.patch
+lock-validator-special-locking-bdev-fix.patch
+lock-validator-special-locking-genirq-lock-validator-early_init_irq_lock_type-build-fix.patch
+lock-validator-special-locking-sctp.patch
+lock-validator-special-locking-reiser4-false-positive.patch
+lockdep-annotate-the-quota-code.patch
+lock-validator-enable-lock-validator-in-kconfig-add-config_debug_non_nested_unlocks-kconfig.patch
+lock-validator-v3.patch
+lockdep-x86-only.patch
+lockdep-really-x86-only.patch
+lockdep-really-really-x86-only.patch

 Locking validator updates

+acpi-identify-which-device-is-not-power-manageable-fix.patch

 Fix acpi-identify-which-device-is-not-power-manageable.patch



All 1526 patches:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc6/2.6.17-rc6-mm1/patch-list

Re: 2.6.17-rc6-mm1

[J.A. Magallón]

On Wed, 7 Jun 2006 10:47:24 -0700, Andrew Morton <akpm@osdl.org> wrote:

> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc6/2.6.17-rc6-mm1/
> 
> - Many more lockdep updates
> 

One missing ;)

============================
[ BUG: illegal lock usage! ]
----------------------------
illegal {in-hardirq-W} -> {hardirq-on-W} usage.
idle/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
 (&list->lock){++..}, at: [<c02f194f>] packet_rcv+0x1b1/0x2fe
{in-hardirq-W} state was registered at:
  [<c0134b9b>] lock_acquire+0x54/0x6a
  [<c02f5447>] _spin_lock_irqsave+0x3f/0x4f
  [<c02a5249>] skb_dequeue+0x12/0x50
  [<f88349d3>] hpsb_bus_reset+0x62/0xa6 [ieee1394]
  [<f884fd96>] ohci_irq_handler+0x82f/0x995 [ohci1394]
  [<c013de72>] handle_IRQ_event+0x2e/0x63
  [<c013efb3>] handle_fasteoi_irq+0x6b/0xac
  [<c0104dd7>] do_IRQ+0x6c/0xa5
irq event stamp: 547564
hardirqs last  enabled at (547564): [<c015c4cc>] kmem_cache_alloc+0x56/0x67
hardirqs last disabled at (547563): [<c015c488>] kmem_cache_alloc+0x12/0x67
softirqs last  enabled at (547552): [<c011fdd4>] __do_softirq+0xe6/0xf7
softirqs last disabled at (547557): [<c0104cfc>] do_softirq+0x5a/0xc9

other info that might help us debug this:
no locks held by idle/0.

stack backtrace:
 [<c01034ba>] show_trace+0x12/0x14
 [<c0103b9f>] dump_stack+0x19/0x1b
 [<c0132ad0>] print_usage_bug+0x20b/0x215
 [<c01333c9>] mark_lock+0x450/0x5bd
 [<c0133e56>] __lock_acquire+0x1ca/0xbee
 [<c0134b9b>] lock_acquire+0x54/0x6a
 [<c02f56de>] _spin_lock+0x36/0x43
 [<c02f194f>] packet_rcv+0x1b1/0x2fe
 [<c02aa61d>] netif_receive_skb+0x185/0x2bc
 [<c02ac01c>] process_backlog+0x9d/0x14d
 [<c02ac1eb>] net_rx_action+0xd2/0x281
 [<c011fd72>] __do_softirq+0x84/0xf7
 [<c0104cfc>] do_softirq+0x5a/0xc9
 =======================
 [<c011fe30>] irq_exit+0x4b/0x4d
 [<c0104dde>] do_IRQ+0x73/0xa5
 [<c0102ec1>] common_interrupt+0x25/0x2c
 [<c010164e>] cpu_idle+0x63/0x80
 [<c0100598>] rest_init+0x33/0x3b
 [<c03dc7af>] start_kernel+0x339/0x3aa
 [<c0100210>] 0xc0100210

--
J.A. Magallon <jamagallon()ono!com>     \               Software is like sex:
                                         \         It's better when it's free
Mandriva Linux release 2007.0 (Cooker) for i586
Linux 2.6.16-jam20 (gcc 4.1.1 20060518 (prerelease)) #1 SMP PREEMPT Wed

Re: 2.6.17-rc6-mm1

[Ingo Molnar]

* J.A. Magallón <jamagallon@ono.com> wrote:

> > - Many more lockdep updates
> 
> One missing ;)

ok, could you try the annotation patch below? ieee1394 uses skb-queues 
in a nontraditional way which collides with the customal skb-queue 
locking observed by the lock validator in the networking code. So i've 
split the affected ieee1394 skb-queue's lock type from the networking 
lock type. This way the validator will still fully validate the ieee1394 
locking rules, but separates them from the other skb-queue rules.

	Ingo

----------
Subject: lock validator: annotate ieee1394 skb-head locking
From: Ingo Molnar <mingo@elte.hu>

ieee1394 reuses the skb infrastructure of the networking code,
and uses two skb-head queues: ->pending_packet_queue and
hpsbpkt_queue. The latter is used in the usual fashion: processed
from a kernel thread. The other one, ->pending_packet_queue is also
processed from hardirq context (f.e. in hpsb_bus_reset()), which is
not what the networking code usually does (which completes from
softirq or process context). This locking assymetry can be totally
correct if done carefully, but it can also be dangerous if
networking helper functions are reused, which could assume
traditional networking use.

It would probably be more robust to push this completion into
a workqueue - but technically the code can be 100% correct, and
lockdep has to be taught about it. The solution is to split the
->pending_packet_queue skb-head->lock type from the networking
lock-type by using a private lock-validator key.

This way the validator will still fully validate the ieee1394 locking 
rules, but separates them from the other skb-queue rules.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 drivers/ieee1394/hosts.c |   11 ++++++++++-
 include/linux/skbuff.h   |    3 +++
 net/core/skbuff.c        |   13 +++++++++++++
 3 files changed, 26 insertions(+), 1 deletion(-)

Index: linux/drivers/ieee1394/hosts.c
===================================================================
--- linux.orig/drivers/ieee1394/hosts.c
+++ linux/drivers/ieee1394/hosts.c
@@ -108,6 +108,14 @@ static int alloc_hostnum_cb(struct hpsb_
  */
 static DEFINE_MUTEX(host_num_alloc);
 
+/*
+ * The pending_packet_queue is special in that it's processed
+ * from hardirq context too (such as hpsb_bus_reset()). Hence
+ * split the lock type from the usual networking skb-head
+ * lock type by using a separate key for it:
+ */
+static struct lockdep_type_key pending_packet_queue_key;
+
 struct hpsb_host *hpsb_alloc_host(struct hpsb_host_driver *drv, size_t extra,
 				  struct device *dev)
 {
@@ -128,7 +136,8 @@ struct hpsb_host *hpsb_alloc_host(struct
 	h->hostdata = h + 1;
 	h->driver = drv;
 
-	skb_queue_head_init(&h->pending_packet_queue);
+	skb_queue_head_init_key(&h->pending_packet_queue,
+				&pending_packet_queue_key);
 	INIT_LIST_HEAD(&h->addr_space);
 
 	for (i = 2; i < 16; i++)
Index: linux/include/linux/skbuff.h
===================================================================
--- linux.orig/include/linux/skbuff.h
+++ linux/include/linux/skbuff.h
@@ -18,6 +18,7 @@
 #include <linux/compiler.h>
 #include <linux/time.h>
 #include <linux/cache.h>
+#include <linux/lockdep.h>
 
 #include <asm/atomic.h>
 #include <asm/types.h>
@@ -589,6 +590,8 @@ static inline __u32 skb_queue_len(const 
 }
 
 extern void skb_queue_head_init(struct sk_buff_head *list);
+extern void skb_queue_head_init_key(struct sk_buff_head *list,
+				    struct lockdep_type_key *key);
 
 /*
  *	Insert an sk_buff at the start of a list.
Index: linux/net/core/skbuff.c
===================================================================
--- linux.orig/net/core/skbuff.c
+++ linux/net/core/skbuff.c
@@ -80,6 +80,19 @@ void skb_queue_head_init(struct sk_buff_
 EXPORT_SYMBOL(skb_queue_head_init);
 
 /*
+ * Use this to initialize your skb-heads if you have special locking
+ * rules for skb queues and process them from say hardirq contexts:
+ */
+void skb_queue_head_init_key(struct sk_buff_head *list,
+			     struct lockdep_type_key *key)
+{
+	spin_lock_init_key(&list->lock, key);
+	list->prev = list->next = (struct sk_buff *)list;
+	list->qlen = 0;
+}
+EXPORT_SYMBOL(skb_queue_head_init_key);
+
+/*
  *	Keep out-of-line to prevent kernel bloat.
  *	__builtin_return_address is not used because it is not always
  *	reliable.

Re: 2.6.17-rc6-mm1

[J.A. Magallón]

On Thu, 8 Jun 2006 00:07:04 +0200, Ingo Molnar <mingo@elte.hu> wrote:

> 
> * J.A. Magallón <jamagallon@ono.com> wrote:
> 
> > > - Many more lockdep updates
> > 
> > One missing ;)
> 
> ok, could you try the annotation patch below?

Trace gone, congrats !!

--
J.A. Magallon <jamagallon()ono!com>     \               Software is like sex:
                                         \         It's better when it's free
Mandriva Linux release 2007.0 (Cooker) for i586
Linux 2.6.16-jam20 (gcc 4.1.1 20060518 (prerelease)) #2 SMP PREEMPT Thu

Re: 2.6.17-rc6-mm1

[Stefan Richter]

Ingo Molnar wrote:
...
> ieee1394 reuses the skb infrastructure of the networking code,
> and uses two skb-head queues: ->pending_packet_queue and
> hpsbpkt_queue. The latter is used in the usual fashion: processed
> from a kernel thread. The other one, ->pending_packet_queue is also
> processed from hardirq context (f.e. in hpsb_bus_reset()), which is
> not what the networking code usually does (which completes from
> softirq or process context). This locking assymetry can be totally
> correct if done carefully, but it can also be dangerous if
> networking helper functions are reused, which could assume
> traditional networking use.
...

The pending_packet_queue is only accessed from within 
drivers/ieee1394/ieee1394_core.c, and only via net/core/skbuff.c's 
access functions for queueing/ dequeueing/ queuewalking. Or am I missing 
something?
-- 
Stefan Richter
-=====-=-==- -==- -=---
http://arcgraph.de/sr/

Re: 2.6.17-rc6-mm1

[Chris Wright]

* Stefan Richter (stefanr@s5r6.in-berlin.de) wrote:
> The pending_packet_queue is only accessed from within 
> drivers/ieee1394/ieee1394_core.c, and only via net/core/skbuff.c's 
> access functions for queueing/ dequeueing/ queuewalking. Or am I missing 
> something?

Quick grep show following two irq handlers as examples:

ohci_irq_handler() | lynx_irq_handler()
  hpsb_bus_reset()
    abort_requests()
      skb_dequeue()
        spin_lock_irqsave()
    
That spin_lock is called directly from within irq handler.

thanks,
-chris

Re: 2.6.17-rc6-mm1

[Stefan Richter]

Chris Wright wrote:
> * Stefan Richter (stefanr@s5r6.in-berlin.de) wrote:
>>The pending_packet_queue is only accessed from within 
>>drivers/ieee1394/ieee1394_core.c, and only via net/core/skbuff.c's 
>>access functions for queueing/ dequeueing/ queuewalking. Or am I missing 
>>something?
> 
> Quick grep show following two irq handlers as examples:
> 
> ohci_irq_handler() | lynx_irq_handler()
>   hpsb_bus_reset()
>     abort_requests()
>       skb_dequeue()
>         spin_lock_irqsave()
>     
> That spin_lock is called directly from within irq handler.

Yes, definitely. What I wanted to reassure myself about was rather that 
no other net/ code besides skbuff.c's touches this queue. IOW only the 
ieee1394 low and mid layer control the contexts within which the queue 
lock is used.
-- 
Stefan Richter
-=====-=-==- -==- -=---
http://arcgraph.de/sr/

Re: 2.6.17-rc6-mm1

[Ingo Molnar]

* Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:

> The pending_packet_queue is only accessed from within 
> drivers/ieee1394/ieee1394_core.c, and only via net/core/skbuff.c's 
> access functions for queueing/ dequeueing/ queuewalking. Or am I 
> missing something? [...]

yes, and it looks safe at the moment.

	Ingo

Re: 2.6.17-rc6-mm1

[Rafael J. Wysocki]

On Wednesday 07 June 2006 19:47, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc6/2.6.17-rc6-mm1/
> 
> - Many more lockdep updates

Well, I've got this one (Asus L5D, x86_64 kernel):

============================
[ BUG: illegal lock usage! ]
----------------------------
illegal {in-hardirq-W} -> {hardirq-on-W} usage.
hwinfo/3398 [HC0[0]:SC0[1]:HE1:SE0] takes:
 (&list->lock){++..}, at: [<ffffffff8046d301>] unix_stream_connect+0x371/0x440
{in-hardirq-W} state was registered at:
  [<ffffffff8024bdaa>] lock_acquire+0x8a/0xc0
  [<ffffffff8047347f>] _spin_lock_irqsave+0x3f/0x60
  [<ffffffff80406e72>] skb_dequeue+0x22/0x70
  [<ffffffff881c97b1>] hpsb_bus_reset+0x61/0xb0 [ieee1394]
  [<ffffffff8822e986>] ohci_irq_handler+0x416/0x830 [ohci1394]
  [<ffffffff8026208b>] handle_IRQ_event+0x2b/0x70
  [<ffffffff80263a03>] handle_level_irq+0xb3/0x120
  [<ffffffff8020c6ec>] do_IRQ+0x5c/0x80
  [<ffffffff80209d60>] common_interrupt+0x64/0x65
irq event stamp: 29916
hardirqs last  enabled at (29915): [<ffffffff802893f5>] kmem_cache_free+0xb5/0xd0
hardirqs last disabled at (29914): [<ffffffff802893d0>] kmem_cache_free+0x90/0xd0
softirqs last  enabled at (29912): [<ffffffff802342fe>] __do_softirq+0xbe/0xd0
softirqs last disabled at (29916): [<ffffffff80472ac1>] _spin_lock_bh+0x11/0x50

other info that might help us debug this:
1 lock held by hwinfo/3398:
 #0:  (&u->lock){--..}, at: [<ffffffff8046d093>] unix_stream_connect+0x103/0x440

stack backtrace:

Call Trace:
 [<ffffffff8020abd6>] show_trace+0xa6/0x220
 [<ffffffff8020af85>] dump_stack+0x15/0x20
 [<ffffffff8024a64c>] print_usage_bug+0x23c/0x250
 [<ffffffff8024a94f>] mark_lock+0x2ef/0x6a0
 [<ffffffff8024b1e6>] __lock_acquire+0x4e6/0xc80
 [<ffffffff8024bdab>] lock_acquire+0x8b/0xc0
 [<ffffffff80472ae4>] _spin_lock_bh+0x34/0x50
 [<ffffffff8046d301>] unix_stream_connect+0x371/0x440
 [<ffffffff80402077>] sys_connect+0x87/0xc0
 [<ffffffff8020982a>] system_call+0x7e/0x83
 [<00002ab066fc6472>]


Greetings,
Rafael

Re: 2.6.17-rc6-mm1

[Ingo Molnar]

* Rafael J. Wysocki <rjw@sisk.pl> wrote:

> On Wednesday 07 June 2006 19:47, Andrew Morton wrote:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc6/2.6.17-rc6-mm1/
> > 
> > - Many more lockdep updates
> 
> Well, I've got this one (Asus L5D, x86_64 kernel):

could you try the current lock validator combo patch from:

  http://redhat.com/~mingo/lockdep-patches/lockdep-combo-2.6.17-rc6-mm1.patch

does that fix this for you?

	Ingo

Re: 2.6.17-rc6-mm1

[Valdis.Kletnieks]

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

On Thu, 08 Jun 2006 00:11:42 +0200, Ingo Molnar said:
> > On Wednesday 07 June 2006 19:47, Andrew Morton wrote:
> > > 
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc6/2.6.17-rc6-mm1/
> > > 
> > > - Many more lockdep updates
> could you try the current lock validator combo patch from:
> 
>   http://redhat.com/~mingo/lockdep-patches/lockdep-combo-2.6.17-rc6-mm1.patch

Seems to be making progress.  With this lockdep-combo, I've been up for
40 minutes without a peep.

(I admit I didn't check the base rc6-mm1 version, because I knew my config
trips on the same unix_stream_connect that Rafael hit, and Rafael and
Ingo posted while I was off doing other stuff...)


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

lockdep wierdness - was Re: 2.6.17-rc6-mm1

[Valdis.Kletnieks]

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

On Wed, 07 Jun 2006 23:19:57 EDT, Valdis.Kletnieks@vt.edu said:
> >   http://redhat.com/~mingo/lockdep-patches/lockdep-combo-2.6.17-rc6-mm1.patch
> 
> Seems to be making progress.  With this lockdep-combo, I've been up for
> 40 minutes without a peep.

Looks like I spoke too soon.  Caught this while the system was coming
down for a reboot (fortunately syslogd was still running):

[10155.405000] stopped custom tracer.
[10155.405000] BUG: warning at kernel/lockdep.c:2431/check_flags()
[10155.405000]  [<c010316f>] show_trace_log_lvl+0x54/0xfd
[10155.405000]  [<c01036e0>] show_trace+0xd/0x10
[10155.405000]  [<c010377d>] dump_stack+0x19/0x1b
[10155.405000]  [<c0129a70>] check_flags+0x98/0x1f1
[10155.405000]  [<c012c3a4>] lock_release+0x1e/0x369
[10155.405000]  [<c036ddbf>] _spin_unlock_bh+0x16/0x32
[10155.405000]  [<c0324f2e>] igmpv3_clear_delrec+0x9e/0xc6
[10155.405000]  [<c03268ca>] ip_mc_down+0x8e/0xa1
[10155.405000]  [<c032253b>] inetdev_event+0x137/0x289
[10155.405000]  [<c036fb17>] notifier_call_chain+0x20/0x31
[10155.405000]  [<c0120547>] raw_notifier_call_chain+0x8/0xa
[10155.405000]  [<c02ed984>] dev_close+0x5f/0x64
[10155.405000]  [<c02ed187>] dev_change_flags+0x51/0xf1
[10155.405000]  [<c0322c47>] devinet_ioctl+0x23a/0x557
[10155.405000]  [<c03235d6>] inet_ioctl+0x73/0x91
[10155.405000]  [<c02e475d>] sock_ioctl+0x1a7/0x1cc
[10155.405000]  [<c016d642>] do_ioctl+0x22/0x67
[10155.405000]  [<c016d8db>] vfs_ioctl+0x254/0x267
[10155.405000]  [<c016d935>] sys_ioctl+0x47/0x72
[10155.405000]  [<c036e5c3>] syscall_call+0x7/0xb
[10155.405000] irq event stamp: 3577
[10155.405000] hardirqs last  enabled at (3575): [<c0118ebc>] local_bh_enable_ip+0xd7/0x104
[10155.405000] hardirqs last disabled at (3577): [<c036e485>] ret_from_exception+0x9/0xc
[10155.405000] softirqs last  enabled at (3574): [<c0324ebc>] igmpv3_clear_delrec+0x2c/0xc6
[10155.405000] softirqs last disabled at (3576): [<c036db93>] _spin_lock_bh+0xb/0x37


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

NTFS possible circular locking deadlock (Was: Re: 2.6.17-rc6-mm1)

[Duncan Sands]

> could you try the current lock validator combo patch from:
> 
>   http://redhat.com/~mingo/lockdep-patches/lockdep-combo-2.6.17-rc6-mm1.patch
> 
> does that fix this for you?

With the combo patch applied:

[   58.778002] NTFS driver 2.1.27 [Flags: R/W MODULE].
[   58.891035]
[   58.891039] =====================================================
[   58.913817] [ BUG: possible circular locking deadlock detected! ]
[   58.932102] -----------------------------------------------------
[   58.950388] mount/2175 is trying to acquire lock:
[   58.964491]  (&ni->mrec_lock){--..}, at: [<c0292700>] mutex_lock+0x21/0x24
[   58.985426]
[   58.985428] but task is already holding lock:
[   59.002985]  (&rl->lock){----}, at: [<e0b274d2>] ntfs_map_runlist+0x0/0xb5 [ntfs]
[   59.025738]
[   59.025739] which lock already depends on the new lock,
[   59.045892] which could lead to circular deadlocks!
[   59.060516]
[   59.060517] the existing dependency chain (in reverse order) is:
[   59.083009]
[   59.083010] -> #1 (&rl->lock){----}:
[   59.098464]        [<c012a6b0>] lock_acquire+0x58/0x74
[   59.114489]        [<e0b23c81>] ntfs_readpage+0x344/0x8f1 [ntfs]
[   59.133137]        [<c013642f>] read_cache_page+0x8e/0x137
[   59.150229]        [<e0b32cdf>] map_mft_record+0xda/0x1e5 [ntfs]
[   59.168878]        [<e0b31081>] ntfs_read_locked_inode+0x74/0xeca [ntfs]
[   59.189605]        [<e0b32527>] ntfs_read_inode_mount+0x650/0x88a [ntfs]
[   59.210332]        [<e0b3e923>] ntfs_fill_super+0x9d7/0xe86 [ntfs]
[   59.229500]        [<c0156fee>] get_sb_bdev+0xed/0x14e
[   59.245526]        [<e0b3b49e>] ntfs_get_sb+0x10/0x12 [ntfs]
[   59.263136]        [<c01564b4>] vfs_kern_mount+0x30/0x9e
[   59.279682]        [<c015655b>] do_kern_mount+0x29/0x3d
[   59.295968]        [<c0169cfe>] do_mount+0x6c4/0x702
[   59.311475]        [<c0169d9b>] sys_mount+0x5f/0x96
[   59.326720]        [<c0293dbd>] sysenter_past_esp+0x56/0x8d
[   59.344045]
[   59.344046] -> #0 (&ni->mrec_lock){--..}:
[   59.360797]        [<c012a6b0>] lock_acquire+0x58/0x74
[   59.376822]        [<c0292569>] __mutex_lock_slowpath+0xa7/0x21d
[   59.395447]        [<c0292700>] mutex_lock+0x21/0x24
[   59.411785]        [<e0b32c1e>] map_mft_record+0x19/0x1e5 [ntfs]
[   59.430433]        [<e0b26cc7>] ntfs_map_runlist_nolock+0x48/0x443 [ntfs]
[   59.451420]        [<e0b27559>] ntfs_map_runlist+0x87/0xb5 [ntfs]
[   59.470329]        [<e0b23da7>] ntfs_readpage+0x46a/0x8f1 [ntfs]
[   59.488977]        [<c013642f>] read_cache_page+0x8e/0x137
[   59.506042]        [<e0b3c918>] load_system_files+0x1da/0x180e [ntfs]
[   59.525989]        [<e0b3e9c8>] ntfs_fill_super+0xa7c/0xe86 [ntfs]
[   59.545160]        [<c0156fee>] get_sb_bdev+0xed/0x14e
[   59.561186]        [<e0b3b49e>] ntfs_get_sb+0x10/0x12 [ntfs]
[   59.578795]        [<c01564b4>] vfs_kern_mount+0x30/0x9e
[   59.595341]        [<c015655b>] do_kern_mount+0x29/0x3d
[   59.611625]        [<c0169cfe>] do_mount+0x6c4/0x702
[   59.627133]        [<c0169d9b>] sys_mount+0x5f/0x96
[   59.642379]        [<c0293dbd>] sysenter_past_esp+0x56/0x8d
[   59.659703]
[   59.659704] other info that might help us debug this:
[   59.659706]
[   59.683833] 2 locks held by mount/2175:
[   59.695340]  #0:  (&s->s_umount#17){--..}, at: [<c0156bd7>] sget+0x173/0x384
[   59.716923]  #1:  (&rl->lock){----}, at: [<e0b274d2>] ntfs_map_runlist+0x0/0xb5 [ntfs]
[   59.741054]
[   59.741056] stack backtrace:
[   59.754432]  [<c0102fef>] show_trace_log_lvl+0x54/0xfd
[   59.769927]  [<c0104078>] show_trace+0xd/0x10
[   59.783096]  [<c0104092>] dump_stack+0x17/0x19
[   59.796525]  [<c012892b>] print_circular_bug_tail+0x59/0x64
[   59.813451]  [<c012a1b2>] __lock_acquire+0x7c6/0x97e
[   59.828548]  [<c012a6b0>] lock_acquire+0x58/0x74
[   59.842622]  [<c0292569>] __mutex_lock_slowpath+0xa7/0x21d
[   59.859261]  [<c0292700>] mutex_lock+0x21/0x24
[   59.872792]  [<e0b32c1e>] map_mft_record+0x19/0x1e5 [ntfs]
[   59.889363]  [<e0b26cc7>] ntfs_map_runlist_nolock+0x48/0x443 [ntfs]
[   59.908250]  [<e0b27559>] ntfs_map_runlist+0x87/0xb5 [ntfs]
[   59.925056]  [<e0b23da7>] ntfs_readpage+0x46a/0x8f1 [ntfs]
[   59.941599]  [<c013642f>] read_cache_page+0x8e/0x137
[   59.956736]  [<e0b3c918>] load_system_files+0x1da/0x180e [ntfs]
[   59.974601]  [<e0b3e9c8>] ntfs_fill_super+0xa7c/0xe86 [ntfs]
[   59.991693]  [<c0156fee>] get_sb_bdev+0xed/0x14e
[   60.005897]  [<e0b3b49e>] ntfs_get_sb+0x10/0x12 [ntfs]
[   60.021427]  [<c01564b4>] vfs_kern_mount+0x30/0x9e
[   60.036128]  [<c015655b>] do_kern_mount+0x29/0x3d
[   60.050569]  [<c0169cfe>] do_mount+0x6c4/0x702
[   60.064291]  [<c0169d9b>] sys_mount+0x5f/0x96
[   60.077732]  [<c0293dbd>] sysenter_past_esp+0x56/0x8d
[   60.144343] NTFS volume version 3.1.
[   60.155117] NTFS-fs warning (device hda1): load_system_files(): Unsupported volume flags 0x4000 encountered.
[   60.184594] NTFS-fs error (device hda1): load_system_files(): Volume has unsupported flags set.  Mounting read-only.  Run chkdsk and mount in Windows.

Re: NTFS possible circular locking deadlock (Was: Re: 2.6.17-rc6-mm1)

[Ingo Molnar]

* Duncan Sands <baldrick@free.fr> wrote:

> With the combo patch applied:
> 
> [   58.778002] NTFS driver 2.1.27 [Flags: R/W MODULE].
> [   58.891035]
> [   58.891039] =====================================================
> [   58.913817] [ BUG: possible circular locking deadlock detected! ]

this should be fixed in the latest combo patch ontop of -rc6-mm2:

  http://redhat.com/~mingo/lockdep-patches/lockdep-combo-2.6.17-rc6-mm2.patch

	Ingo

Re: 2.6.17-rc6-mm1

[Rafael J. Wysocki]

On Thursday 08 June 2006 00:11, Ingo Molnar wrote:
> * Rafael J. Wysocki <rjw@sisk.pl> wrote:
> 
> > On Wednesday 07 June 2006 19:47, Andrew Morton wrote:
> > > 
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc6/2.6.17-rc6-mm1/
> > > 
> > > - Many more lockdep updates
> > 
> > Well, I've got this one (Asus L5D, x86_64 kernel):
> 
> could you try the current lock validator combo patch from:
> 
>   http://redhat.com/~mingo/lockdep-patches/lockdep-combo-2.6.17-rc6-mm1.patch
> 
> does that fix this for you?

Yes, it does.

Thanks,
Rafael

Re: 2.6.17-rc6-mm1

[J.A. Magallón]

On Wed, 7 Jun 2006 10:47:24 -0700, Andrew Morton <akpm@osdl.org> wrote:

> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc6/2.6.17-rc6-mm1/
> 
> - Many more lockdep updates
> 

I did not realize this the first time:

Root device is (8, 1)
Boot sector 512 bytes.
Setup is 6927 bytes.
System is 1610 kB
Kernel: arch/i386/boot/bzImage is ready  (#2)
  MODPOST
WARNING: drivers/block/floppy.o - Section mismatch: reference to .init.text: from .smp_locks after '' (at offset 0x3c)
WARNING: drivers/block/floppy.o - Section mismatch: reference to .init.text: from .smp_locks after '' (at offset 0x40)
WARNING: drivers/block/floppy.o - Section mismatch: reference to .init.text: from .smp_locks after '' (at offset 0x44)

--
J.A. Magallon <jamagallon()ono!com>     \               Software is like sex:
                                         \         It's better when it's free
Mandriva Linux release 2007.0 (Cooker) for i586
Linux 2.6.16-jam20 (gcc 4.1.1 20060518 (prerelease)) #1 SMP PREEMPT Wed

Re: 2.6.17-rc6-mm1

[Andrew Morton]

On Thu, 8 Jun 2006 00:31:53 +0200
"J.A. Magallón" <jamagallon@ono.com> wrote:

> WARNING: drivers/block/floppy.o - Section mismatch: reference to .init.text: from .smp_locks after '' (at offset 0x3c)
> WARNING: drivers/block/floppy.o - Section mismatch: reference to .init.text: from .smp_locks after '' (at offset 0x40)
> WARNING: drivers/block/floppy.o - Section mismatch: reference to .init.text: from .smp_locks after '' (at offset 0x44)

Yes, that's a false positive - doing locking from within an __init section.
We need to shut that up somehow.

[PATCH] ignore smp_locks section warnings from init/exit code

[Randy.Dunlap]

On Wed, 7 Jun 2006 15:40:54 -0700 Andrew Morton wrote:

> On Thu, 8 Jun 2006 00:31:53 +0200
> "J.A. Magallón" <jamagallon@ono.com> wrote:
> 
> > WARNING: drivers/block/floppy.o - Section mismatch: reference to .init.text: from .smp_locks after '' (at offset 0x3c)
> > WARNING: drivers/block/floppy.o - Section mismatch: reference to .init.text: from .smp_locks after '' (at offset 0x40)
> > WARNING: drivers/block/floppy.o - Section mismatch: reference to .init.text: from .smp_locks after '' (at offset 0x44)
> 
> Yes, that's a false positive - doing locking from within an __init section.
> We need to shut that up somehow.

I currently only see this in an __exit section.
Here is a patch that fixes it for me.
J.A., can you test it?

---
From: Randy Dunlap <rdunlap@xenotime.net>

Add ".smp_locks" section to whitelist as being safe from
init and exit sections.

Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
---
 scripts/mod/modpost.c |    2 ++
 1 files changed, 2 insertions(+)

--- linux-2617-rc6mm1.orig/scripts/mod/modpost.c
+++ linux-2617-rc6mm1/scripts/mod/modpost.c
@@ -852,6 +852,7 @@ static int init_section_ref_ok(const cha
 		".pci_fixup_final",
 		".pdr",
 		"__param",
+		".smp_locks",
 		NULL
 	};
 	/* Start of section names */
@@ -923,6 +924,7 @@ static int exit_section_ref_ok(const cha
 		".exitcall.exit",
 		".eh_frame",
 		".stab",
+		".smp_locks",
 		NULL
 	};
 	/* Start of section names */

Re: [PATCH] ignore smp_locks section warnings from init/exit code

[Randy.Dunlap]

On Wed, 7 Jun 2006 16:23:26 -0700 Randy.Dunlap wrote:

> On Wed, 7 Jun 2006 15:40:54 -0700 Andrew Morton wrote:
> 
> > On Thu, 8 Jun 2006 00:31:53 +0200
> > "J.A. Magallón" <jamagallon@ono.com> wrote:
> > 
> > > WARNING: drivers/block/floppy.o - Section mismatch: reference to .init.text: from .smp_locks after '' (at offset 0x3c)
> > > WARNING: drivers/block/floppy.o - Section mismatch: reference to .init.text: from .smp_locks after '' (at offset 0x40)
> > > WARNING: drivers/block/floppy.o - Section mismatch: reference to .init.text: from .smp_locks after '' (at offset 0x44)
> > 
> > Yes, that's a false positive - doing locking from within an __init section.
> > We need to shut that up somehow.
> 
> I currently only see this in an __exit section.
> Here is a patch that fixes it for me.
> J.A., can you test it?

This patch fixes 67 such warnings in allmodconfig for me (x86_64).


> ---
> From: Randy Dunlap <rdunlap@xenotime.net>
> 
> Add ".smp_locks" section to whitelist as being safe from
> init and exit sections.
> 
> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
> ---
>  scripts/mod/modpost.c |    2 ++
>  1 files changed, 2 insertions(+)
> 
> --- linux-2617-rc6mm1.orig/scripts/mod/modpost.c
> +++ linux-2617-rc6mm1/scripts/mod/modpost.c
> @@ -852,6 +852,7 @@ static int init_section_ref_ok(const cha
>  		".pci_fixup_final",
>  		".pdr",
>  		"__param",
> +		".smp_locks",
>  		NULL
>  	};
>  	/* Start of section names */
> @@ -923,6 +924,7 @@ static int exit_section_ref_ok(const cha
>  		".exitcall.exit",
>  		".eh_frame",
>  		".stab",
> +		".smp_locks",
>  		NULL
>  	};
>  	/* Start of section names */
> -


---
~Randy

Re: [PATCH] ignore smp_locks section warnings from init/exit code

[Jeff Dike]

On Wed, Jun 07, 2006 at 04:23:26PM -0700, Randy.Dunlap wrote:
> I currently only see this in an __exit section.
> Here is a patch that fixes it for me.

Cool, something equivalent makes the UML link a lot quieter.  I had to
add ".plt" and ".bss".  I'm guessing mine are false positives as well,
but have no idea how to check that.

I also think that adding these two sections would be UML-specific, but
that probably shouldn't hurt other arches.

				Jeff

Re: [PATCH] ignore smp_locks section warnings from init/exit code

[Randy.Dunlap]

On Wed, 7 Jun 2006 22:11:49 -0400 Jeff Dike wrote:

> On Wed, Jun 07, 2006 at 04:23:26PM -0700, Randy.Dunlap wrote:
> > I currently only see this in an __exit section.
> > Here is a patch that fixes it for me.
> 
> Cool, something equivalent makes the UML link a lot quieter.  I had to
> add ".plt" and ".bss".  I'm guessing mine are false positives as well,
> but have no idea how to check that.
> 
> I also think that adding these two sections would be UML-specific, but
> that probably shouldn't hurt other arches.

I could look, but:

> make ARCH=um allmodconfig
/var/linsrc/linux-2617-rc6mm1/arch/um/Makefile:113: *** missing separator.  Stop.

is that known/fixed?

---
~Randy

Re: [PATCH] ignore smp_locks section warnings from init/exit code

[Jeff Dike]

On Wed, Jun 07, 2006 at 07:32:25PM -0700, Randy.Dunlap wrote:
> > make ARCH=um allmodconfig
> /var/linsrc/linux-2617-rc6mm1/arch/um/Makefile:113: *** missing separator.  Stop.
> 
> is that known/fixed?

No.  rc6-mm1 builds fine here.  I just checked with a fresh tree.

Are you sure you have a clean tree?

				Jeff

Re: [PATCH] ignore smp_locks section warnings from init/exit code

[Randy.Dunlap]

On Thu, 8 Jun 2006 00:21:09 -0400 Jeff Dike wrote:

> On Wed, Jun 07, 2006 at 07:32:25PM -0700, Randy.Dunlap wrote:
> > > make ARCH=um allmodconfig
> > /var/linsrc/linux-2617-rc6mm1/arch/um/Makefile:113: *** missing separator.  Stop.
> > 
> > is that known/fixed?
> 
> No.  rc6-mm1 builds fine here.  I just checked with a fresh tree.
> 
> Are you sure you have a clean tree?

Yes, must be some toolchain problem.
I'll look at it more, but it's somewhat low priority for me.

---
~Randy

Re: [PATCH] ignore smp_locks section warnings from init/exit code

[Randy.Dunlap]

On Wed, 7 Jun 2006 21:29:58 -0700 Randy.Dunlap wrote:

> On Thu, 8 Jun 2006 00:21:09 -0400 Jeff Dike wrote:
> 
> > On Wed, Jun 07, 2006 at 07:32:25PM -0700, Randy.Dunlap wrote:
> > > > make ARCH=um allmodconfig
> > > /var/linsrc/linux-2617-rc6mm1/arch/um/Makefile:113: *** missing separator.  Stop.
> > > 
> > > is that known/fixed?
> > 
> > No.  rc6-mm1 builds fine here.  I just checked with a fresh tree.
> > 
> > Are you sure you have a clean tree?
> 
> Yes, must be some toolchain problem.
> I'll look at it more, but it's somewhat low priority for me.

FWIW, I get this same error on 2 different systems,
x86_64 + distro1 vs. i386 + distro2.  Odd.

---
~Randy

Re: [PATCH] ignore smp_locks section warnings from init/exit code

[Sam Ravnborg]

On Wed, Jun 07, 2006 at 10:11:49PM -0400, Jeff Dike wrote:
> On Wed, Jun 07, 2006 at 04:23:26PM -0700, Randy.Dunlap wrote:
> > I currently only see this in an __exit section.
> > Here is a patch that fixes it for me.
> 
> Cool, something equivalent makes the UML link a lot quieter.  I had to
> add ".plt" and ".bss".  I'm guessing mine are false positives as well,
> but have no idea how to check that.

The check is there to catch situations where a function is marked
__init but referenced after a potential discard of the it sections.
So if there is no-one discarding the .plt section then we should be all
safe.

Browsing the um code I could not see how .plt was thought used so I
added it to the ignorelist in modpost.

diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 94047bc..a70f5dd 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -822,6 +822,7 @@ static int init_section_ref_ok(const cha
 		".pdr",
 		"__param",
 		".smp_locks",
+		".plt",  /* seen on ARCH=um build on x86_64. Harmless */
 		NULL
 	};
 	/* Start of section names */
@@ -894,6 +895,7 @@ static int exit_section_ref_ok(const cha
 		".eh_frame",
 		".stab",
 		".smp_locks",
+		".plt",  /* seen on ARCH=um build on x86_64. Harmless */
 		NULL
 	};
 	/* Start of section names */

As for .bss this is a much more generic section - so for now this is not
added. Can you explain why there is a reference to do_mount_root from
.bss or is this a bug in modpost pointing out something wrong?

With the above patch we are down to two section mismatch warnings for
a defconfig build on x86_64.

	Sam

Re: [PATCH] ignore smp_locks section warnings from init/exit code

[Jeff Dike]

On Thu, Jun 08, 2006 at 08:35:49PM +0200, Sam Ravnborg wrote:
> As for .bss this is a much more generic section - so for now this is not
> added. Can you explain why there is a reference to do_mount_root from
> .bss or is this a bug in modpost pointing out something wrong?

For me, the ld complaints are completely opaque.  Can you give me a
clue how you go about figuring out where the complaint is coming from?

This is what I get with UML/x86_64 with rc6-mm2:
	WARNING: vmlinux - Section mismatch: reference to .init.text:huft_free from .bss between 'stdout@@GLIBC_2.2.5' (at offset 0x6027b748) and 'completed.6111'

gdb tells me:
	(gdb) x/4xa 0x6027b748
	0x6027b748 <stdout@@GLIBC_2.2.5>:       0x0     0x0
	0x6027b758 <completed.6111+8>:  0x0     0x0

So, with stdout@@GLIBC_2.2.5 at 0x6027b748 and completed.6111 at
0x6027b750 - right next to each other - there would seem to be nothing
between them to reference anything.

In any case, with bss containing zero-initialized stuff, I don't see
how anything here can refer to anything anywhere else.

> With the above patch we are down to two section mismatch warnings for
> a defconfig build on x86_64.

I see one (the one quoted above).  Thanks for adding .plt - that made
the build much more pleasant.

				Jeff

Re: [PATCH] ignore smp_locks section warnings from init/exit code

[Randy.Dunlap]

On Sun, 11 Jun 2006 19:25:58 -0400 Jeff Dike wrote:

> On Thu, Jun 08, 2006 at 08:35:49PM +0200, Sam Ravnborg wrote:
> > As for .bss this is a much more generic section - so for now this is not
> > added. Can you explain why there is a reference to do_mount_root from
> > .bss or is this a bug in modpost pointing out something wrong?
> 
> For me, the ld complaints are completely opaque.  Can you give me a
> clue how you go about figuring out where the complaint is coming from?
> 
> This is what I get with UML/x86_64 with rc6-mm2:
> 	WARNING: vmlinux - Section mismatch: reference to .init.text:huft_free from .bss between 'stdout@@GLIBC_2.2.5' (at offset 0x6027b748) and 'completed.6111'
> 
> gdb tells me:
> 	(gdb) x/4xa 0x6027b748
> 	0x6027b748 <stdout@@GLIBC_2.2.5>:       0x0     0x0
> 	0x6027b758 <completed.6111+8>:  0x0     0x0
> 
> So, with stdout@@GLIBC_2.2.5 at 0x6027b748 and completed.6111 at
> 0x6027b750 - right next to each other - there would seem to be nothing
> between them to reference anything.

gdb says 0x6027b758 for <completed.6111>, not 0x6027b750 as you
wrote, so there's 8 more bytes for gunk there.  ;)
Anyway, since I can't build UML, I'm willing to look at the
file if you can put it on a web page along with its System.map file.


> In any case, with bss containing zero-initialized stuff, I don't see
> how anything here can refer to anything anywhere else.
> 
> > With the above patch we are down to two section mismatch warnings for
> > a defconfig build on x86_64.
> 
> I see one (the one quoted above).  Thanks for adding .plt - that made
> the build much more pleasant.


---
~Randy

Re: [PATCH] ignore smp_locks section warnings from init/exit code

[Jeff Dike]

On Sun, Jun 11, 2006 at 05:17:40PM -0700, Randy.Dunlap wrote:
> > gdb tells me:
> > 	(gdb) x/4xa 0x6027b748
> > 	0x6027b748 <stdout@@GLIBC_2.2.5>:       0x0     0x0
> > 	0x6027b758 <completed.6111+8>:  0x0     0x0
> > 
> > So, with stdout@@GLIBC_2.2.5 at 0x6027b748 and completed.6111 at
> > 0x6027b750 - right next to each other - there would seem to be nothing
> > between them to reference anything.
> 
> gdb says 0x6027b758 for <completed.6111>, not 0x6027b750 as you
> wrote, so there's 8 more bytes for gunk there.  ;)
> Anyway, since I can't build UML, I'm willing to look at the

gdb says 0x6027b758 for <completed.6111+8>, making
completed.6111 = 0x6027b750, leaving 0 bytes for gunk.

				Jeff

Re: [PATCH] ignore smp_locks section warnings from init/exit code

[Randy.Dunlap]

On Sun, 11 Jun 2006 22:29:58 -0400 Jeff Dike wrote:

> On Sun, Jun 11, 2006 at 05:17:40PM -0700, Randy.Dunlap wrote:
> > > gdb tells me:
> > > 	(gdb) x/4xa 0x6027b748
> > > 	0x6027b748 <stdout@@GLIBC_2.2.5>:       0x0     0x0
> > > 	0x6027b758 <completed.6111+8>:  0x0     0x0
> > > 
> > > So, with stdout@@GLIBC_2.2.5 at 0x6027b748 and completed.6111 at
> > > 0x6027b750 - right next to each other - there would seem to be nothing
> > > between them to reference anything.
> > 
> > gdb says 0x6027b758 for <completed.6111>, not 0x6027b750 as you
> > wrote, so there's 8 more bytes for gunk there.  ;)
> > Anyway, since I can't build UML, I'm willing to look at the
> 
> gdb says 0x6027b758 for <completed.6111+8>, making
> completed.6111 = 0x6027b750, leaving 0 bytes for gunk.

um. ack.

---
~Randy

Re: 2.6.17-rc6-mm1

[Andi Kleen]

Andrew Morton <akpm@osdl.org> writes:

> On Thu, 8 Jun 2006 00:31:53 +0200
> "J.A. Magallón" <jamagallon@ono.com> wrote:
> 
> > WARNING: drivers/block/floppy.o - Section mismatch: reference to .init.text: from .smp_locks after '' (at offset 0x3c)
> > WARNING: drivers/block/floppy.o - Section mismatch: reference to .init.text: from .smp_locks after '' (at offset 0x40)
> > WARNING: drivers/block/floppy.o - Section mismatch: reference to .init.text: from .smp_locks after '' (at offset 0x44)
> 
> Yes, that's a false positive - doing locking from within an __init section.
> We need to shut that up somehow.

Are you sure it's false? 

I don't see an explicit check in alternatives.c for the main kernel
vs init sections and with CPU hotplug the alternatives can be applied
arbitarily after the system has booted.  So it would just stomp
over the init text pages which are used for something else now.

I guess to make it safe you would need to teach alternative.c to
ignore init sections.

-Andi

Re: 2.6.17-rc6-mm1

[Randy.Dunlap]

On 08 Jun 2006 04:25:39 +0200 Andi Kleen wrote:

> Andrew Morton <akpm@osdl.org> writes:
> 
> > On Thu, 8 Jun 2006 00:31:53 +0200
> > "J.A. Magallón" <jamagallon@ono.com> wrote:
> > 
> > > WARNING: drivers/block/floppy.o - Section mismatch: reference to .init.text: from .smp_locks after '' (at offset 0x3c)
> > > WARNING: drivers/block/floppy.o - Section mismatch: reference to .init.text: from .smp_locks after '' (at offset 0x40)
> > > WARNING: drivers/block/floppy.o - Section mismatch: reference to .init.text: from .smp_locks after '' (at offset 0x44)
> > 
> > Yes, that's a false positive - doing locking from within an __init section.
> > We need to shut that up somehow.
> 
> Are you sure it's false? 
> 
> I don't see an explicit check in alternatives.c for the main kernel
> vs init sections and with CPU hotplug the alternatives can be applied
> arbitarily after the system has booted.  So it would just stomp
> over the init text pages which are used for something else now.
> 
> I guess to make it safe you would need to teach alternative.c to
> ignore init sections.

for i386 (arch/i386/alternative.c and module.c):

static void alternatives_smp_lock(u8 **start, u8 **end, u8 *text, u8 *text_end)
{...}

only replaces code between text and text_end.

I've cced Gerd on this before.  Maybe you can get her to repsond
to confirm or deny.

---
~Randy

Re: 2.6.17-rc6-mm1

[Andi Kleen]

On Thursday 08 June 2006 04:46, Randy.Dunlap wrote:
> On 08 Jun 2006 04:25:39 +0200 Andi Kleen wrote:
> 
> > Andrew Morton <akpm@osdl.org> writes:
> > 
> > > On Thu, 8 Jun 2006 00:31:53 +0200
> > > "J.A. Magallón" <jamagallon@ono.com> wrote:
> > > 
> > > > WARNING: drivers/block/floppy.o - Section mismatch: reference to .init.text: from .smp_locks after '' (at offset 0x3c)
> > > > WARNING: drivers/block/floppy.o - Section mismatch: reference to .init.text: from .smp_locks after '' (at offset 0x40)
> > > > WARNING: drivers/block/floppy.o - Section mismatch: reference to .init.text: from .smp_locks after '' (at offset 0x44)
> > > 
> > > Yes, that's a false positive - doing locking from within an __init section.
> > > We need to shut that up somehow.
> > 
> > Are you sure it's false? 
> > 
> > I don't see an explicit check in alternatives.c for the main kernel
> > vs init sections and with CPU hotplug the alternatives can be applied
> > arbitarily after the system has booted.  So it would just stomp
> > over the init text pages which are used for something else now.
> > 
> > I guess to make it safe you would need to teach alternative.c to
> > ignore init sections.
> 
> for i386 (arch/i386/alternative.c and module.c):
> 
> static void alternatives_smp_lock(u8 **start, u8 **end, u8 *text, u8 *text_end)
> {...}
> 
> only replaces code between text and text_end.


You're right - for smp_lock it should be ok, but for other alternatives() 
there is no such check. But then they are ok because they shouldn't change
after bootup.

I retract the objection.

> I've cced Gerd on this before.  Maybe you can get her to repsond
> to confirm or deny.

Him.

-Andi
 

Re: 2.6.17-rc6-mm1

[Gerd Hoffmann]

Andi Kleen wrote:
> I don't see an explicit check in alternatives.c for the main kernel
> vs init sections and with CPU hotplug the alternatives can be applied
> arbitarily after the system has booted.  So it would just stomp
> over the init text pages which are used for something else now.

very close to the end of the file:

  alternatives_smp_module_add(NULL, "core kernel",
                              __smp_locks, __smp_locks_end,
                              _text, _etext);

The core kernel is just a "special" module (where we keep track of the
.text section boundaries too), and LOCKs outside the _text -> _etext
range are never ever patched.

cheers,

  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg

Re: 2.6.17-rc6-mm1

[Martin Bligh]

Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc6/2.6.17-rc6-mm1/



Build failures on everything but x86_64 (possibly different distro
or something)

   GEN     usr/klibc/syscalls/SYSCALLS.i
/usr/local/autobench/var/tmp/build/usr/klibc/SYSCALLS.def:30:26: missing 
terminating ' character
make[3]: *** [usr/klibc/syscalls/SYSCALLS.i] Error 1
make[2]: *** [usr/klibc/syscalls] Error 2
make[1]: *** [_usr_klibc] Error 2
make: *** [usr] Error 2
06/07/06-18:23:44 Build the kernel. Failed rc = 2
06/07/06-18:23:44 build: kernel build Failed rc = 1
06/07/06-18:23:44 command complete: (2) rc=126
Failed and terminated the run
  Fatal error, aborting autorun

Full example here:
	http://test.kernel.org/abat/35106/debug/test.log.0

Re: 2.6.17-rc6-mm1

[Andrew Morton]

On Wed, 07 Jun 2006 16:14:08 -0700
Martin Bligh <mbligh@mbligh.org> wrote:

> Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc6/2.6.17-rc6-mm1/
> 
> 
> 
> Build failures on everything but x86_64 (possibly different distro
> or something)
> 
>    GEN     usr/klibc/syscalls/SYSCALLS.i
> /usr/local/autobench/var/tmp/build/usr/klibc/SYSCALLS.def:30:26: missing 
> terminating ' character
> make[3]: *** [usr/klibc/syscalls/SYSCALLS.i] Error 1
> make[2]: *** [usr/klibc/syscalls] Error 2
> make[1]: *** [_usr_klibc] Error 2
> make: *** [usr] Error 2
> 06/07/06-18:23:44 Build the kernel. Failed rc = 2
> 06/07/06-18:23:44 build: kernel build Failed rc = 1
> 06/07/06-18:23:44 command complete: (2) rc=126
> Failed and terminated the run
>   Fatal error, aborting autorun

dammit, I fixed that and then didn't manage to include the fix in the rollup.

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc6/2.6.17-rc6-mm1/broken-out/klibc-ia64-fix.patch

Re: 2.6.17-rc6-mm1

[Grant Coady]

On Wed, 7 Jun 2006 16:55:21 -0700, Andrew Morton <akpm@osdl.org> wrote:

>On Wed, 07 Jun 2006 16:14:08 -0700
>Martin Bligh <mbligh@mbligh.org> wrote:
>
>> Andrew Morton wrote:
>> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc6/2.6.17-rc6-mm1/
>> 
>> 
>> 
>> Build failures on everything but x86_64 (possibly different distro
>> or something)
>> 
>>    GEN     usr/klibc/syscalls/SYSCALLS.i
>> /usr/local/autobench/var/tmp/build/usr/klibc/SYSCALLS.def:30:26: missing 
>> terminating ' character
>> make[3]: *** [usr/klibc/syscalls/SYSCALLS.i] Error 1
>> make[2]: *** [usr/klibc/syscalls] Error 2
>> make[1]: *** [_usr_klibc] Error 2
>> make: *** [usr] Error 2
>> 06/07/06-18:23:44 Build the kernel. Failed rc = 2
>> 06/07/06-18:23:44 build: kernel build Failed rc = 1
>> 06/07/06-18:23:44 command complete: (2) rc=126
>> Failed and terminated the run
>>   Fatal error, aborting autorun
>
>dammit, I fixed that and then didn't manage to include the fix in the rollup.
>
>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc6/2.6.17-rc6-mm1/broken-out/klibc-ia64-fix.patch

Thanks, Andrew -- perhaps you could copy this patch to 
.../2.6.17-rc6-mm1/hot-fixes ?  I was caught too and checked 
for hot-fixes, empty.

Grant.

Re: 2.6.17-rc6-mm1

[Dave Jones]

On Wed, Jun 07, 2006 at 10:47:24AM -0700, Andrew Morton wrote:
 > 
 > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc6/2.6.17-rc6-mm1/
 > 
 > - Many more lockdep updates

Needs more.

====================================
[ BUG: possible deadlock detected! ]
------------------------------------
nfsd/11429 is trying to acquire lock:
 (&inode->i_mutex){--..}, at: [<c032286a>] mutex_lock+0x21/0x24

but task is already holding lock:
 (&inode->i_mutex){--..}, at: [<c032286a>] mutex_lock+0x21/0x24

which could potentially lead to deadlocks!

other info that might help us debug this:
2 locks held by nfsd/11429:
 #0:  (hash_sem){----}, at: [<d10d0364>] exp_readlock+0x0/0x3e [nfsd]
 #1:  (&inode->i_mutex){--..}, at: [<c032286a>] mutex_lock+0x21/0x24

stack backtrace:
 [<c0104966>] show_trace_log_lvl+0x54/0xfd
 [<c0104f1a>] show_trace+0xd/0x10
 [<c010502f>] dump_stack+0x19/0x1b
 [<c013b2d4>] __lockdep_acquire+0x8f6/0x912
 [<c013b346>] lockdep_acquire+0x56/0x6f
 [<c03226cf>] __mutex_lock_slowpath+0xae/0x228
 [<c032286a>] mutex_lock+0x21/0x24
 [<d10cdb64>] nfsd_setattr+0x2d3/0x49f [nfsd]
 [<d10ceecd>] nfsd_create_v3+0x319/0x4aa [nfsd]
 [<d10d413e>] nfsd3_proc_create+0x125/0x135 [nfsd]
 [<d10ca0d4>] nfsd_dispatch+0xc0/0x178 [nfsd]
 [<d0ee89e9>] svc_process+0x38d/0x5d5 [sunrpc]
 [<d10ca581>] nfsd+0x18b/0x302 [nfsd]
 [<c0102005>] kernel_thread_helper+0x5/0xb


It's too close to bedtime for me, and on a cursory examination,
I don't even see where nfsd_setattr touches a mutex.

This was triggered by a simple 'touch foo' over an nfs v3 mount.

		Dave

-- 
http://www.codemonkey.org.uk

Re: 2.6.17-rc6-mm1

[Arjan van de Ven]

On Thu, 2006-06-08 at 01:00 -0400, Dave Jones wrote:
> On Wed, Jun 07, 2006 at 10:47:24AM -0700, Andrew Morton wrote:
>  > 
>  > ftp://ftp.kernel.org/pub/linux/kernel/peopleD/akpm/patches/2.6/2.6.17-rc6/2.6.17-rc6-mm1/
>  > 
>  > - Many more lockdep updates
> 
> Needs more.
> 
> ====================================
> [ BUG: possible deadlock detected! ]
> ------------------------------------
> nfsd/11429 is trying to acquire lock:
>  (&inode->i_mutex){--..}, at: [<c032286a>] mutex_lock+0x21/0x24
> 
> but task is already holding lock:
>  (&inode->i_mutex){--..}, at: [<c032286a>] mutex_lock+0x21/0x24
> 
> which could potentially lead to deadlocks!

Does this fix it for you? (it fixes the case for me)

---
 fs/nfsd/vfs.c              |   10 +++++-----
 include/linux/nfsd/nfsd.h  |    1 -
 include/linux/nfsd/nfsfh.h |   31 +++++++++++++++++++++++++++++++
 3 files changed, 36 insertions(+), 6 deletions(-)

Index: linux-2.6.17-rc6-mm2/fs/nfsd/vfs.c
===================================================================
--- linux-2.6.17-rc6-mm2.orig/fs/nfsd/vfs.c
+++ linux-2.6.17-rc6-mm2/fs/nfsd/vfs.c
@@ -1115,7 +1115,7 @@ nfsd_create(struct svc_rqst *rqstp, stru
 	 */
 	if (!resfhp->fh_dentry) {
 		/* called from nfsd_proc_mkdir, or possibly nfsd3_proc_create */
-		fh_lock(fhp);
+		fh_lock_parent(fhp);
 		dchild = lookup_one_len(fname, dentry, flen);
 		err = PTR_ERR(dchild);
 		if (IS_ERR(dchild))
@@ -1241,7 +1241,7 @@ nfsd_create_v3(struct svc_rqst *rqstp, s
 	err = nfserr_notdir;
 	if(!dirp->i_op || !dirp->i_op->lookup)
 		goto out;
-	fh_lock(fhp);
+	fh_lock_parent(fhp);
 
 	/*
 	 * Compose the response file handle.
@@ -1426,7 +1426,7 @@ nfsd_symlink(struct svc_rqst *rqstp, str
 	err = fh_verify(rqstp, fhp, S_IFDIR, MAY_CREATE);
 	if (err)
 		goto out;
-	fh_lock(fhp);
+	fh_lock_parent(fhp);
 	dentry = fhp->fh_dentry;
 	dnew = lookup_one_len(fname, dentry, flen);
 	err = PTR_ERR(dnew);
@@ -1495,7 +1495,7 @@ nfsd_link(struct svc_rqst *rqstp, struct
 	if (isdotent(name, len))
 		goto out;
 
-	fh_lock(ffhp);
+	fh_lock_parent(ffhp);
 	ddir = ffhp->fh_dentry;
 	dirp = ddir->d_inode;
 
@@ -1644,7 +1644,7 @@ nfsd_unlink(struct svc_rqst *rqstp, stru
 	if (err)
 		goto out;
 
-	fh_lock(fhp);
+	fh_lock_parent(fhp);
 	dentry = fhp->fh_dentry;
 	dirp = dentry->d_inode;
 
Index: linux-2.6.17-rc6-mm2/include/linux/nfsd/nfsd.h
===================================================================
--- linux-2.6.17-rc6-mm2.orig/include/linux/nfsd/nfsd.h
+++ linux-2.6.17-rc6-mm2/include/linux/nfsd/nfsd.h
@@ -67,7 +67,6 @@ int		nfsd_svc(unsigned short port, int n
 int		nfsd_dispatch(struct svc_rqst *rqstp, u32 *statp);
 
 /* nfsd/vfs.c */
-int		fh_lock_parent(struct svc_fh *, struct dentry *);
 int		nfsd_racache_init(int);
 void		nfsd_racache_shutdown(void);
 int		nfsd_cross_mnt(struct svc_rqst *rqstp, struct dentry **dpp,
Index: linux-2.6.17-rc6-mm2/include/linux/nfsd/nfsfh.h
===================================================================
--- linux-2.6.17-rc6-mm2.orig/include/linux/nfsd/nfsfh.h
+++ linux-2.6.17-rc6-mm2/include/linux/nfsd/nfsfh.h
@@ -322,6 +322,37 @@ fh_lock(struct svc_fh *fhp)
 }
 
 /*
+ * Lock a file handle/inode to be used as parent dir for another
+ * NOTE: both fh_lock and fh_unlock are done "by hand" in
+ * vfs.c:nfsd_rename as it needs to grab 2 i_mutex's at once
+ * so, any changes here should be reflected there.
+ */
+static inline void
+fh_lock_parent(struct svc_fh *fhp)
+{
+	struct dentry	*dentry = fhp->fh_dentry;
+	struct inode	*inode;
+
+	dfprintk(FILEOP, "nfsd: fh_lock(%s) locked = %d\n",
+			SVCFH_fmt(fhp), fhp->fh_locked);
+
+	if (!fhp->fh_dentry) {
+		printk(KERN_ERR "fh_lock: fh not verified!\n");
+		return;
+	}
+	if (fhp->fh_locked) {
+		printk(KERN_WARNING "fh_lock: %s/%s already locked!\n",
+			dentry->d_parent->d_name.name, dentry->d_name.name);
+		return;
+	}
+
+	inode = dentry->d_inode;
+	mutex_lock_nested(&inode->i_mutex, I_MUTEX_PARENT);
+	fill_pre_wcc(fhp);
+	fhp->fh_locked = 1;
+}
+
+/*
  * Unlock a file handle/inode
  */
 static inline void

Re: 2.6.17-rc6-mm1

[Andrew Morton]

On Tue, 20 Jun 2006 19:42:29 +0200
Arjan van de Ven <arjan@infradead.org> wrote:

>  /*
> + * Lock a file handle/inode to be used as parent dir for another
> + * NOTE: both fh_lock and fh_unlock are done "by hand" in
> + * vfs.c:nfsd_rename as it needs to grab 2 i_mutex's at once
> + * so, any changes here should be reflected there.
> + */
> +static inline void
> +fh_lock_parent(struct svc_fh *fhp)
> +{
> +	struct dentry	*dentry = fhp->fh_dentry;
> +	struct inode	*inode;
> +
> +	dfprintk(FILEOP, "nfsd: fh_lock(%s) locked = %d\n",
> +			SVCFH_fmt(fhp), fhp->fh_locked);
> +
> +	if (!fhp->fh_dentry) {
> +		printk(KERN_ERR "fh_lock: fh not verified!\n");
> +		return;
> +	}
> +	if (fhp->fh_locked) {
> +		printk(KERN_WARNING "fh_lock: %s/%s already locked!\n",
> +			dentry->d_parent->d_name.name, dentry->d_name.name);
> +		return;
> +	}
> +
> +	inode = dentry->d_inode;
> +	mutex_lock_nested(&inode->i_mutex, I_MUTEX_PARENT);
> +	fill_pre_wcc(fhp);
> +	fhp->fh_locked = 1;
> +}

yikes, five callsites, and fill_pre_wcc() is inlined too.

This is all farily intrusive.

Re: 2.6.17-rc6-mm1

[Arjan van de Ven]

On Tue, 2006-06-20 at 13:24 -0700, Andrew Morton wrote:
> On Tue, 20 Jun 2006 19:42:29 +0200
> Arjan van de Ven <arjan@infradead.org> wrote:
> 
> >  /*
> > + * Lock a file handle/inode to be used as parent dir for another
> > + * NOTE: both fh_lock and fh_unlock are done "by hand" in
> > + * vfs.c:nfsd_rename as it needs to grab 2 i_mutex's at once
> > + * so, any changes here should be reflected there.
> > + */
> > +static inline void
> > +fh_lock_parent(struct svc_fh *fhp)
> > +{
> > +	struct dentry	*dentry = fhp->fh_dentry;
> > +	struct inode	*inode;
> > +
> > +	dfprintk(FILEOP, "nfsd: fh_lock(%s) locked = %d\n",
> > +			SVCFH_fmt(fhp), fhp->fh_locked);
> > +
> > +	if (!fhp->fh_dentry) {
> > +		printk(KERN_ERR "fh_lock: fh not verified!\n");
> > +		return;
> > +	}
> > +	if (fhp->fh_locked) {
> > +		printk(KERN_WARNING "fh_lock: %s/%s already locked!\n",
> > +			dentry->d_parent->d_name.name, dentry->d_name.name);
> > +		return;
> > +	}
> > +
> > +	inode = dentry->d_inode;
> > +	mutex_lock_nested(&inode->i_mutex, I_MUTEX_PARENT);
> > +	fill_pre_wcc(fhp);
> > +	fhp->fh_locked = 1;
> > +}
> 
> yikes, five callsites, and fill_pre_wcc() is inlined too.

if this patch works for Dave I'll make one that just inlines this (and
the other one) as well; as you said.. 5+ call sites...
(and in fact there used to be an out-of-line function for this at some
point so.. it's not unheard of)

Re: 2.6.17-rc6-mm1

[Dave Jones]

On Tue, Jun 20, 2006 at 07:42:29PM +0200, Arjan van de Ven wrote:
 > On Thu, 2006-06-08 at 01:00 -0400, Dave Jones wrote:
 > > On Wed, Jun 07, 2006 at 10:47:24AM -0700, Andrew Morton wrote:
 > >  > 
 > >  > ftp://ftp.kernel.org/pub/linux/kernel/peopleD/akpm/patches/2.6/2.6.17-rc6/2.6.17-rc6-mm1/
 > >  > 
 > >  > - Many more lockdep updates
 > > 
 > > Needs more.
 > > 
 > > ====================================
 > > [ BUG: possible deadlock detected! ]
 > > ------------------------------------
 > > nfsd/11429 is trying to acquire lock:
 > >  (&inode->i_mutex){--..}, at: [<c032286a>] mutex_lock+0x21/0x24
 > > 
 > > but task is already holding lock:
 > >  (&inode->i_mutex){--..}, at: [<c032286a>] mutex_lock+0x21/0x24
 > > 
 > > which could potentially lead to deadlocks!
 > 
 > Does this fix it for you? (it fixes the case for me)

Hmm. This makes things drastically worse for me. Now it hangs during NFS startup.

$ sudo service nfs start
Starting NFS services:                                     [  OK  ]
Starting NFS quotas:

and that's all she wrote.

ps axf..

 2757 pts/0    S+     0:00  |           \_ /bin/sh /sbin/service nfs start
 2760 pts/0    S+     0:00  |               \_ /bin/sh /etc/init.d/nfs start
 2771 pts/0    S+     0:00  |                   \_ /bin/bash -c ulimit -S -c 0 >/dev/null 2>&1 ; rpc.rquotad
 2772 pts/0    S+     0:00  |                       \_ rpc.rquotad
	

If I ssh into the box, and get sysrq-t output, I see..
http://people.redhat.com/davej/nfs

I've kicked off a clean build that I'll leave running overnight, as I'm not
100% sure that was a clean tree I built from. Odd behaviour for a miscompile though.

		Dave

-- 
http://www.codemonkey.org.uk

Re: 2.6.17-rc6-mm1

[Arjan van de Ven]

On Wed, 2006-06-21 at 02:23 -0400, Dave Jones wrote:
> On Tue, Jun 20, 2006 at 07:42:29PM +0200, Arjan van de Ven wrote:
>  > On Thu, 2006-06-08 at 01:00 -0400, Dave Jones wrote:
>  > > On Wed, Jun 07, 2006 at 10:47:24AM -0700, Andrew Morton wrote:
>  > >  > 
>  > >  > ftp://ftp.kernel.org/pub/linux/kernel/peopleD/akpm/patches/2.6/2.6.17-rc6/2.6.17-rc6-mm1/
>  > >  > 
>  > >  > - Many more lockdep updates
>  > > 
>  > > Needs more.
>  > > 
>  > > ====================================
>  > > [ BUG: possible deadlock detected! ]
>  > > ------------------------------------
>  > > nfsd/11429 is trying to acquire lock:
>  > >  (&inode->i_mutex){--..}, at: [<c032286a>] mutex_lock+0x21/0x24
>  > > 
>  > > but task is already holding lock:
>  > >  (&inode->i_mutex){--..}, at: [<c032286a>] mutex_lock+0x21/0x24
>  > > 
>  > > which could potentially lead to deadlocks!
>  > 
>  > Does this fix it for you? (it fixes the case for me)
> 
> Hmm. This makes things drastically worse for me. Now it hangs during NFS startup.

hmm that's highly unexpected

Re: 2.6.17-rc6-mm1

[Dave Jones]

On Wed, Jun 21, 2006 at 10:15:33AM +0200, Arjan van de Ven wrote:

 > >  > Does this fix it for you? (it fixes the case for me)
 > > 
 > > Hmm. This makes things drastically worse for me. Now it hangs during NFS startup.
 > 
 > hmm that's highly unexpected

It did the same thing with your diff backed out.
I think my testbox needs a reinstall.
Probably won't happen for a few days though.

		Dave

-- 
http://www.codemonkey.org.uk