The mm-of-the-moment snapshot 2011-03-31-14-48 has been uploaded to
http://userweb.kernel.org/~akpm/mmotm/
and will soon be available at
git://zen-kernel.org/kernel/mmotm.git
It contains the following patches against 2.6.39-rc1:
origin.patch
memcg-fix-mem_cgroup_rotate_reclaimable_page.patch
mm-optimize-pfn-calculation-in-online_page.patch
backlight-new-driver-for-the-adp8870-backlight-devices.patch
linux-next.patch
next-remove-localversion.patch
i-need-old-gcc.patch
arch-alpha-kernel-systblss-remove-debug-check.patch
include-asm-generic-vmlinuxldsh-fix-__modver-section-warnings.patch
drivers-i2c-busses-i2c-designware-corec-needs-delayh.patch
sound-soc-codecs-sn95031c-needs-delayh.patch
fs-partitions-ldmc-fix-oops-caused-by-corrupted-partition-table.patch
fs-partitions-ldmc-fix-oops-caused-by-corrupted-partition-table-checkpatch-fixes.patch
mm-page_allocc-silence-build_all_zonelists-section-mismatch.patch
vmstat-update-comment-regarding-stat_threshold.patch
leds-leds-regulatorc-fix-handling-of-already-enabled-regulators.patch
kstrtox-fix-compile-warnings-in-test.patch
kstrtox-simpler-code-in-_kstrtoull.patch
maintainers-add-arm-ts78xx-setup-platform-maintainer.patch
maintainers-update-m68knommu-patterns.patch
maintainers-update-various-tty-patterns.patch
mm-add-vm-counters-for-transparent-hugepages.patch
acerhdf-add-support-for-aspire-1410-bios-v13314.patch
arch-x86-include-asm-delayh-fix-udelay-and-ndelay-for-8-bit-args.patch
x86-fix-mmap-random-address-range.patch
x86-stop-including-linux-delayh-in-two-asm-header-files.patch
msm-timer-migrate-to-timer-based-__delay.patch
arch-arm-mach-ux500-mbox-db5500c-world-writable-sysfs-fifo-file.patch
audit-always-follow-va_copy-with-va_end.patch
fs-btrfs-inodec-eliminate-memory-leak.patch
btrfs-dont-dereference-extent_mapping-if-null.patch
drivers-gpu-drm-radeon-atomc-fix-warning.patch
fb-fix-potential-deadlock-between-lock_fb_info-and-console_lock.patch
cyber2000fb-avoid-palette-corruption-at-higher-clocks.patch
bitmap-irq-add-smp_affinity_list-interface-to-proc-irq.patch
drivers-leds-leds-pca9532c-add-gpio-capability.patch
leds-route-kbd-leds-through-the-generic-leds-layer.patch
net-irda-convert-bfin_sir-to-common-blackfin-uart-header.patch
net-convert-%p-usage-to-%pk.patch
backlight-add-backlight-type-fix.patch
backlight-add-backlight-type-fix-fix.patch
i915-add-native-backlight-control.patch
btusb-patch-add_apple_macbookpro62.patch
drivers-message-fusion-mptsasc-fix-warning.patch
scsi-fix-a-header-to-include-linux-typesh.patch
aic94xx-world-writable-sysfs-update_bios-file.patch
drbd-fix-warning.patch
usb-yurex-recognize-generalkeys-wireless-presenter-as-generic-hid.patch
mm.patch
arch-mm-filter-disallowed-nodes-from-arch-specific-show_mem-functions.patch
mmap-add-alignment-for-some-variables.patch
mmap-avoid-unnecessary-anon_vma-lock.patch
mmap-avoid-merging-cloned-vmas.patch
mm-remove-unused-zone_idx-variable-from-set_migratetype_isolate.patch
mm-nommu-sort-mm-mmap-list-properly.patch
mm-nommu-sort-mm-mmap-list-properly-fix.patch
mm-nommu-dont-scan-the-vma-list-when-deleting.patch
mm-nommu-find-vma-using-the-sorted-vma-list.patch
mm-nommu-check-the-vma-list-when-unmapping-file-mapped-vma.patch
mm-nommu-fix-a-potential-memory-leak-in-do_mmap_private.patch
mm-nommu-fix-a-compile-warning-in-do_mmap_pgoff.patch
mm-remove-unused-token-argument-from-apply_to_page_range-callback.patch
mm-add-apply_to_page_range_batch.patch
ioremap-use-apply_to_page_range_batch-for-ioremap_page_range.patch
vmalloc-use-plain-pte_clear-for-unmaps.patch
vmalloc-use-apply_to_page_range_batch-for-vunmap_page_range.patch
vmalloc-use-apply_to_page_range_batch-for-vmap_page_range_noflush.patch
vmalloc-use-apply_to_page_range_batch-in-alloc_vm_area.patch
xen-mmu-use-apply_to_page_range_batch-in-xen_remap_domain_mfn_range.patch
xen-grant-table-use-apply_to_page_range_batch.patch
memsw-remove-noswapaccount-kernel-parameter.patch
mm-batch-activate_page-to-reduce-lock-contention.patch
xattrh-expose-string-defines-to-userspace.patch
frv-duplicate-output_buffer-of-e03.patch
frv-duplicate-output_buffer-of-e03-checkpatch-fixes.patch
hpet-factor-timer-allocate-from-open.patch
arch-alpha-include-asm-ioh-s-extern-inline-static-inline.patch
lib-vsprintfc-fix-interaction-of-kasprintf-and-vsnprintf-when-using-%pv.patch
lib-hexdumpc-make-hex2bin-return-the-updated-src-address.patch
fs-binfmt_miscc-use-kernels-hex_to_bin-method.patch
fs-binfmt_miscc-use-kernels-hex_to_bin-method-fix.patch
fs-binfmt_miscc-use-kernels-hex_to_bin-method-fix-fix.patch
rtc-add-support-for-the-rtc-in-via-vt8500-and-compatibles.patch
rtc-add-em3027-rtc-driver.patch
rtc-add-rv3029c2-rtc-support.patch
rtc-driver-for-pt7c4338-chip.patch
rtc-driver-for-pt7c4338-chip-checkpatch-fixes.patch
rtc-driver-for-pt7c4338-chip-fix.patch
gpio-add-new-altera-pio-driver.patch
gpio-add-new-altera-pio-driver-update.patch
gpio-make-gpio_requestfree_array-gpio-array-parameter-const.patch
jbd-remove-dependency-on-__gfp_nofail.patch
documentation-atomic_opstxt-avoid-volatile-in-sample-code.patch
cgroup-remove-the-ns_cgroup.patch
mm-move-enum-vm_event_item-into-a-standalone-header-file.patch
memcg-count-the-soft_limit-reclaim-in-global-background-reclaim.patch
memcg-add-stats-to-monitor-soft_limit-reclaim.patch
add-the-pagefault-count-into-memcg-stats.patch
add-the-pagefault-count-into-memcg-stats-fix.patch
memcg-remove-pointless-next_mz-nullification-in-mem_cgroup_soft_limit_reclaim.patch
kstrtox-convert-fs-proc.patch
proc-constify-status-array.patch
proc-stat-use-defined-macro-kmalloc_max_size.patch
sysctl-add-proc_dointvec_bool-handler.patch
sysctl-use-proc_dointvec_bool-where-appropriate.patch
sysctl-add-proc_dointvec_unsigned-handler.patch
sysctl-use-proc_dointvec_unsigned-where-appropriate.patch
pid-fix-typo-in-function-description.patch
fs-execc-provide-the-correct-process-pid-to-the-pipe-helper.patch
scatterlist-new-helper-functions.patch
scatterlist-new-helper-functions-update.patch
scatterlist-new-helper-functions-update-fix.patch
memstick-add-support-for-legacy-memorysticks.patch
memstick-add-support-for-legacy-memorysticks-update-2.patch
kexec-remove-kmsg_dump_kexec.patch
kexec-remove-kmsg_dump_kexec-fix.patch
make-sure-nobodys-leaking-resources.patch
journal_add_journal_head-debug.patch
releasing-resources-with-children.patch
make-frame_pointer-default=y.patch
mutex-subsystem-synchro-test-module.patch
mutex-subsystem-synchro-test-module-fix.patch
slab-leaks3-default-y.patch
put_bh-debug.patch
add-debugging-aid-for-memory-initialisation-problems.patch
workaround-for-a-pci-restoring-bug.patch
prio_tree-debugging-patch.patch
single_open-seq_release-leak-diagnostics.patch
add-a-refcount-check-in-dput.patch
memblock-add-input-size-checking-to-memblock_find_region.patch
memblock-add-input-size-checking-to-memblock_find_region-fix.patch
From: Randy Dunlap <[email protected]>
Fix build error, needs delay.h:
drivers/staging/olpc_dcon/olpc_dcon_xo_1.c:168: error: implicit declaration of function 'udelay'
Signed-off-by: Randy Dunlap <[email protected]>
Cc: Andres Salomon <[email protected]>
---
drivers/staging/olpc_dcon/olpc_dcon_xo_1.c | 1 +
1 file changed, 1 insertion(+)
Can we get something in MAINTAINERS for OLPC, please?
--- mmotm-2011-0331-1448.orig/drivers/staging/olpc_dcon/olpc_dcon_xo_1.c
+++ mmotm-2011-0331-1448/drivers/staging/olpc_dcon/olpc_dcon_xo_1.c
@@ -11,6 +11,7 @@
* License as published by the Free Software Foundation.
*/
#include <linux/cs5535.h>
+#include <linux/delay.h>
#include <linux/gpio.h>
#include <asm/olpc.h>
From: Randy Dunlap <[email protected]>
Fix build when GPIOLIB is not enabled:
drivers/leds/leds-pca9532.c:39: error: field 'gpio' has incomplete type
for: drivers-leds-leds-pca9532c-add-gpio-capability.patch
Signed-off-by: Randy Dunlap <[email protected]>
Cc: Joachim Eastwood <[email protected]>
---
drivers/leds/leds-pca9532.c | 2 ++
1 file changed, 2 insertions(+)
--- mmotm-2011-0331-1448.orig/drivers/leds/leds-pca9532.c
+++ mmotm-2011-0331-1448/drivers/leds/leds-pca9532.c
@@ -36,7 +36,9 @@ struct pca9532_data {
struct mutex update_lock;
struct input_dev *idev;
struct work_struct work;
+#ifdef CONFIG_LEDS_PCA9532_GPIO
struct gpio_chip gpio;
+#endif
u8 pwm[2];
u8 psc[2];
};
On 03/31/2011 11:48 PM, [email protected] wrote:
> The mm-of-the-moment snapshot 2011-03-31-14-48 has been uploaded to
Hi, nfs client is defunct in this kernel. Tcpdump says:
10:51:55.489717 IP 10.20.11.33.759945860 > 10.20.3.2.2049: 132 getattr
fh 0,0/24
10:51:55.515927 IP 10.20.3.2.2049 > 10.20.11.33.759945860: reply ok 44
getattr ERROR: Operation not permitted
10:51:55.515949 IP 10.20.11.33.921 > 10.20.3.2.2049: Flags [.], ack
3569361440, win 115, options [nop,nop,TS val 599750 ecr 255058541], length 0
10:52:04.130310 IP 10.20.11.33.793500292 > 10.20.3.2.2049: 76 getattr fh
0,0/24
10:52:04.152178 IP 10.20.3.2.2049 > 10.20.11.33.793500292: reply ok 44
getattr ERROR: Operation not permitted
If I run the same mount command (mount -oro,intr host:dir mountpoint)
from within a virtual machine with 2.6.38.2 there, everything mounts OK.
thanks,
--
js
suse labs
> The mm-of-the-moment snapshot 2011-03-31-14-48 has been uploaded to
>
> http://userweb.kernel.org/~akpm/mmotm/
>
> and will soon be available at
>
> git://zen-kernel.org/kernel/mmotm.git
>
This doesn't boot.
.config attached.
Ingo, Perter, Is this known issue?
=======================================================================
[ 0.169037] divide error: 0000 [#1] SMP
[ 0.169982] last sysfs file:
[ 0.169982] CPU 0
[ 0.169982] Modules linked in:
[ 0.169982]
[ 0.169982] Pid: 1, comm: swapper Not tainted 2.6.39-rc1-mm1+ #2 FUJITSU-SV PRIMERGY /D2559-A1
[ 0.169982] RIP: 0010:[<ffffffff8104ad4c>] [<ffffffff8104ad4c>] find_busiest_group+0x38c/0xd30
[ 0.169982] RSP: 0018:ffff88003c133830 EFLAGS: 00010046
[ 0.169982] RAX: 0000000000000000 RBX: 00000000001d3a00 RCX: 0000000000000000
[ 0.169982] RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000000
[ 0.169982] RBP: ffff88003c1339e0 R08: 0000000000000000 R09: 0000000000000000
[ 0.169982] R10: 0000000000000001 R11: 0000000000000001 R12: 00000000001d3a00
[ 0.169982] R13: 00000000ffffffff R14: ffff88003c113980 R15: 0000000000000001
[ 0.169982] FS: 0000000000000000(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
[ 0.169982] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 0.169982] CR2: 0000000000000000 CR3: 0000000001a03000 CR4: 00000000000006f0
[ 0.169982] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 0.169982] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 0.169982] Process swapper (pid: 1, threadinfo ffff88003c132000, task ffff88003c134040)
[ 0.169982] Stack:
[ 0.169982] ffff88003c133840 ffff88003c133970 ffffffff81086aff ffff88003fc00000
[ 0.169982] ffff88003c133a60 0100000000000002 ffff88003c133acc 00ffffff81009fd5
[ 0.169982] ffff88003fc0e9e0 000000003c134040 0000000000000000 0000000000000000
[ 0.169982] Call Trace:
[ 0.169982] [<ffffffff81086aff>] ? local_clock+0x6f/0x80
[ 0.169982] [<ffffffff81050533>] load_balance+0xa3/0x600
[ 0.169982] [<ffffffff81050f53>] idle_balance+0xf3/0x180
[ 0.169982] [<ffffffff81550092>] schedule+0x722/0x7d0
[ 0.169982] [<ffffffff81550538>] ? wait_for_common+0x128/0x190
[ 0.169982] [<ffffffff81550a65>] schedule_timeout+0x265/0x320
[ 0.169982] [<ffffffff81095815>] ? lock_release_holdtime+0x35/0x1a0
[ 0.169982] [<ffffffff81550538>] ? wait_for_common+0x128/0x190
[ 0.169982] [<ffffffff8109bb6c>] ? __lock_release+0x9c/0x1d0
[ 0.169982] [<ffffffff815534e0>] ? _raw_spin_unlock_irq+0x30/0x40
[ 0.169982] [<ffffffff815534e0>] ? _raw_spin_unlock_irq+0x30/0x40
[ 0.169982] [<ffffffff81550540>] wait_for_common+0x130/0x190
[ 0.169982] [<ffffffff81051920>] ? try_to_wake_up+0x510/0x510
[ 0.169982] [<ffffffff8155067d>] wait_for_completion+0x1d/0x20
[ 0.169982] [<ffffffff8107f36c>] kthread_create_on_node+0xac/0x150
[ 0.169982] [<ffffffff81077bb0>] ? process_scheduled_works+0x40/0x40
[ 0.169982] [<ffffffff8155045f>] ? wait_for_common+0x4f/0x190
[ 0.169982] [<ffffffff8107a283>] __alloc_workqueue_key+0x1a3/0x590
[ 0.169982] [<ffffffff81e0cce2>] cpuset_init_smp+0x6b/0x7b
[ 0.169982] [<ffffffff81df3d07>] kernel_init+0xc3/0x182
[ 0.169982] [<ffffffff8155d5e4>] kernel_thread_helper+0x4/0x10
[ 0.169982] [<ffffffff81553cd4>] ? retint_restore_args+0x13/0x13
[ 0.169982] [<ffffffff81df3c44>] ? start_kernel+0x400/0x400
[ 0.169982] [<ffffffff8155d5e0>] ? gs_change+0x13/0x13
[ 0.169982] Code: fe ff ff 48 8b bd 90 fe ff ff e8 60 fb ff ff 48 8b 95 b0 fe ff ff 48 8b 7d 98 48 8b 4d a0 44 8b 42 08 48 89 f8 31 d2 48 c1 e0 0a
[ 0.169982] f7 f0 48 85 c9 48 89 c6 49 89 c1 48 89 45 90 74 1f 48 8b 45
[ 0.169982] RIP [<ffffffff8104ad4c>] find_busiest_group+0x38c/0xd30
[ 0.169982] RSP <ffff88003c133830>
[ 0.169982] divide error: 0000 [#2]
[ 0.169982] ---[ end trace 93d72a36b9146f22 ]---
[ 0.169997] swapper used greatest stack depth: 3576 bytes left
[ 0.170007] Kernel panic - not syncing: Attempted to kill init!
[ 0.170009] Pid: 1, comm: swapper Tainted: G D 2.6.39-rc1-mm1+ #2
[ 0.170010] Call Trace:
[ 0.170013] [<ffffffff8154f6df>] panic+0x91/0x1ab
[ 0.170015] [<ffffffff81553520>] ? _raw_write_unlock_irq+0x30/0x40
[ 0.170018] [<ffffffff8105df60>] ? forget_original_parent+0x330/0x380
[ 0.170021] [<ffffffff8105dfab>] forget_original_parent+0x37b/0x380
[ 0.170023] [<ffffffff8105dfc7>] exit_notify+0x17/0x170
[ 0.170026] [<ffffffff8105ea74>] do_exit+0x224/0x4c0
[ 0.170028] [<ffffffff81554d20>] oops_end+0xb0/0xf0
[ 0.170031] [<ffffffff8100610b>] die+0x5b/0x90
[ 0.170033] [<ffffffff815543e4>] do_trap+0xc4/0x170
[ 0.170036] [<ffffffff81002f2f>] do_divide_error+0x8f/0xb0
[ 0.170038] [<ffffffff8104ad4c>] ? find_busiest_group+0x38c/0xd30
[ 0.170041] [<ffffffff812d44dd>] ? trace_hardirqs_off_thunk+0x3a/0x3c
[ 0.170044] [<ffffffff81553d04>] ? restore_args+0x30/0x30
[ 0.170046] [<ffffffff8155d3fb>] divide_error+0x1b/0x20
[ 0.170048] [<ffffffff8104ad4c>] ? find_busiest_group+0x38c/0xd30
[ 0.170051] [<ffffffff81086aff>] ? local_clock+0x6f/0x80
[ 0.170054] [<ffffffff81050533>] load_balance+0xa3/0x600
[ 0.170056] [<ffffffff81050f53>] idle_balance+0xf3/0x180
[ 0.170058] [<ffffffff81550092>] schedule+0x722/0x7d0
[ 0.170061] [<ffffffff81550538>] ? wait_for_common+0x128/0x190
[ 0.170063] [<ffffffff81550a65>] schedule_timeout+0x265/0x320
[ 0.170065] [<ffffffff81095815>] ? lock_release_holdtime+0x35/0x1a0
[ 0.170068] [<ffffffff81550538>] ? wait_for_common+0x128/0x190
[ 0.170070] [<ffffffff8109bb6c>] ? __lock_release+0x9c/0x1d0
[ 0.170072] [<ffffffff815534e0>] ? _raw_spin_unlock_irq+0x30/0x40
[ 0.170074] [<ffffffff815534e0>] ? _raw_spin_unlock_irq+0x30/0x40
[ 0.170077] [<ffffffff81550540>] wait_for_common+0x130/0x190
[ 0.170079] [<ffffffff81051920>] ? try_to_wake_up+0x510/0x510
[ 0.170081] [<ffffffff8155067d>] wait_for_completion+0x1d/0x20
[ 0.170084] [<ffffffff8107f36c>] kthread_create_on_node+0xac/0x150
[ 0.170086] [<ffffffff81077bb0>] ? process_scheduled_works+0x40/0x40
[ 0.170089] [<ffffffff8155045f>] ? wait_for_common+0x4f/0x190
[ 0.170091] [<ffffffff8107a283>] __alloc_workqueue_key+0x1a3/0x590
[ 0.170094] [<ffffffff81e0cce2>] cpuset_init_smp+0x6b/0x7b
[ 0.170096] [<ffffffff81df3d07>] kernel_init+0xc3/0x182
[ 0.170098] [<ffffffff8155d5e4>] kernel_thread_helper+0x4/0x10
[ 0.170101] [<ffffffff81553cd4>] ? retint_restore_args+0x13/0x13
[ 0.170103] [<ffffffff81df3c44>] ? start_kernel+0x400/0x400
[ 0.170105] [<ffffffff8155d5e0>] ? gs_change+0x13/0x13
[ 0.169982] SMP
[ 0.169982] last sysfs file:
[ 0.169982] CPU 1
[ 0.169982] Modules linked in:
[ 0.169982]
[ 0.169982] Pid: 2, comm: kthreadd Tainted: G D 2.6.39-rc1-mm1+ #2 FUJITSU-SV PRIMERGY /D2559-A1
[ 0.169982] RIP: 0010:[<ffffffff8104558d>] [<ffffffff8104558d>] find_idlest_group.clone.103+0x13d/0x200
[ 0.169982] RSP: 0000:ffff88003c13db60 EFLAGS: 00010046
[ 0.169982] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 0.169982] RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000002
[ 0.169982] RBP: ffff88003c13dbe0 R08: ffff88007ab22db8 R09: 0000000000000000
[ 0.169982] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
[ 0.169982] R13: ffff88007ab22db8 R14: ffff88007ab22da0 R15: 0000000000000000
[ 0.169982] FS: 0000000000000000(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000
[ 0.169982] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 0.169982] CR2: 0000000000000000 CR3: 0000000001a03000 CR4: 00000000000006e0
[ 0.169982] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 0.169982] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 0.169982] Process kthreadd (pid: 2, threadinfo ffff88003c13c000, task ffff88003c138080)
[ 0.169982] Stack:
[ 0.169982] ffff88003c138080 ffff880000000002 ffff880000000000 0000007d81041782
[ 0.169982] 0000000000000000 0000000000000200 ffffffffffffffff 0000000100000046
[ 0.169982] ffff88007fc0e9f0 ffff88007ab542e0 ffff880000000000 ffff88007fc0e9e0
[ 0.169982] Call Trace:
[ 0.169982] [<ffffffff81049b5e>] select_task_rq_fair+0x30e/0x480
[ 0.169982] [<ffffffff81051d61>] wake_up_new_task+0x41/0x1b0
[ 0.169982] [<ffffffff8107b050>] ? __task_pid_nr_ns+0xc0/0x100
[ 0.169982] [<ffffffff8107af90>] ? cpumask_weight+0x20/0x20
[ 0.169982] [<ffffffff81058942>] do_fork+0xe2/0x3a0
[ 0.169982] [<ffffffff8109b099>] ? __lock_acquire+0x519/0xba0
[ 0.169982] [<ffffffff81009fd5>] ? native_sched_clock+0x15/0x70
[ 0.169982] [<ffffffff81086aff>] ? local_clock+0x6f/0x80
[ 0.169982] [<ffffffff8107f574>] ? kthreadd+0x114/0x170
[ 0.169982] [<ffffffff810956a9>] ? trace_hardirqs_off_caller+0x29/0x150
[ 0.169982] [<ffffffff8100ad06>] kernel_thread+0x76/0x80
[ 0.169982] [<ffffffff8107f070>] ? __init_kthread_worker+0x70/0x70
[ 0.169982] [<ffffffff8155d5e0>] ? gs_change+0x13/0x13
[ 0.169982] [<ffffffff8107f593>] kthreadd+0x133/0x170
[ 0.169982] [<ffffffff8155d5e4>] kernel_thread_helper+0x4/0x10
[ 0.169982] [<ffffffff81553cd4>] ? retint_restore_args+0x13/0x13
[ 0.169982] [<ffffffff8107f460>] ? tsk_fork_get_node+0x30/0x30
[ 0.169982] [<ffffffff8155d5e0>] ? gs_change+0x13/0x13
[ 0.169982] Code: 66 0f 1f 44 00 00 89 de 89 c7 89 55 90 89 4d 88 e8 79 4d ff ff 8b 4d 88 8b 55 90 eb a8 90 41 8b 4e 08 4c 89 e0 31 d2 48 c1 e0 0a
[ 0.169982] f7 f1 45 85 ff 75 7b 48 3b 45 b0 0f 83 01 ff ff ff 48 8b 4d
[ 0.169982] RIP [<ffffffff8104558d>] find_idlest_group.clone.103+0x13d/0x200
[ 0.169982] RSP <ffff88003c13db60>
[ 0.169982] ---[ end trace 93d72a36b9146f23 ]---
On Sun, 2011-04-03 at 18:11 +0900, KOSAKI Motohiro wrote:
> Ingo, Perter, Is this known issue?
>
>
> =======================================================================
> [ 0.169037] divide error: 0000 [#1] SMP
> [ 0.169982] last sysfs file:
> [ 0.169982] CPU 0
> [ 0.169982] Modules linked in:
> [ 0.169982]
> [ 0.169982] Pid: 1, comm: swapper Not tainted 2.6.39-rc1-mm1+ #2 FUJITSU-SV PRIMERGY /D2559-A1
> [ 0.169982] RIP: 0010:[<ffffffff8104ad4c>] [<ffffffff8104ad4c>] find_busiest_group+0x38c/0xd30
Not something I've recently seen, so no.
> On Sun, 2011-04-03 at 18:11 +0900, KOSAKI Motohiro wrote:
> > Ingo, Perter, Is this known issue?
> >
> >
> > =======================================================================
> > [ 0.169037] divide error: 0000 [#1] SMP
> > [ 0.169982] last sysfs file:
> > [ 0.169982] CPU 0
> > [ 0.169982] Modules linked in:
> > [ 0.169982]
> > [ 0.169982] Pid: 1, comm: swapper Not tainted 2.6.39-rc1-mm1+ #2 FUJITSU-SV PRIMERGY /D2559-A1
> > [ 0.169982] RIP: 0010:[<ffffffff8104ad4c>] [<ffffffff8104ad4c>] find_busiest_group+0x38c/0xd30
>
> Not something I've recently seen, so no.
OK, I'll digg it later.
Thanks.
On 04/06/2011 10:44 PM, Myklebust, Trond wrote:
> On Sat, 2011-04-02 at 10:56 +0200, Jiri Slaby wrote:
>> On 03/31/2011 11:48 PM, [email protected] wrote:
>> > The mm-of-the-moment snapshot 2011-03-31-14-48 has been uploaded to
>>
>> Hi, nfs client is defunct in this kernel. Tcpdump says:
>> 10:51:55.489717 IP 10.20.11.33.759945860 > 10.20.3.2.2049: 132 getattr
>> fh 0,0/24
>> 10:51:55.515927 IP 10.20.3.2.2049 > 10.20.11.33.759945860: reply ok 44
>> getattr ERROR: Operation not permitted
>> 10:51:55.515949 IP 10.20.11.33.921 > 10.20.3.2.2049: Flags [.], ack
>> 3569361440, win 115, options [nop,nop,TS val 599750 ecr 255058541],
> length 0
>> 10:52:04.130310 IP 10.20.11.33.793500292 > 10.20.3.2.2049: 76 getattr fh
>> 0,0/24
>> 10:52:04.152178 IP 10.20.3.2.2049 > 10.20.11.33.793500292: reply ok 44
>> getattr ERROR: Operation not permitted
>>
>> If I run the same mount command (mount -oro,intr host:dir mountpoint)
>> from within a virtual machine with 2.6.38.2 there, everything mounts OK.
>
> Does the attached patch help?
No, still the operation not permitted in the tcpdump output and no mount.
thanks,
--
js
suse labs
> > The mm-of-the-moment snapshot 2011-03-31-14-48 has been uploaded to
> >
> > http://userweb.kernel.org/~akpm/mmotm/
> >
> > and will soon be available at
> >
> > git://zen-kernel.org/kernel/mmotm.git
> >
>
> This doesn't boot.
>
> =======================================================================
> [ 0.169037] divide error: 0000 [#1] SMP
> [ 0.169982] last sysfs file:
> [ 0.169982] CPU 0
> [ 0.169982] Modules linked in:
> [ 0.169982]
> [ 0.169982] Pid: 1, comm: swapper Not tainted 2.6.39-rc1-mm1+ #2 FUJITSU-SV PRIMERGY /D2559-A1
> [ 0.169982] RIP: 0010:[<ffffffff8104ad4c>] [<ffffffff8104ad4c>] find_busiest_group+0x38c/0xd30
Please don't worry. This is not -mm problem. The breakage is in linus-tree.
Now fake numa feature doesn't work correctly and I and Tejun are discussing
about a fix.
On 04/07/2011 08:42 AM, Jiri Slaby wrote:
> On 04/06/2011 10:44 PM, Myklebust, Trond wrote:
>> On Sat, 2011-04-02 at 10:56 +0200, Jiri Slaby wrote:
>>> On 03/31/2011 11:48 PM, [email protected] wrote:
>>>> The mm-of-the-moment snapshot 2011-03-31-14-48 has been uploaded to
>>>
>>> Hi, nfs client is defunct in this kernel. Tcpdump says:
>>> 10:51:55.489717 IP 10.20.11.33.759945860 > 10.20.3.2.2049: 132 getattr
>>> fh 0,0/24
>>> 10:51:55.515927 IP 10.20.3.2.2049 > 10.20.11.33.759945860: reply ok 44
>>> getattr ERROR: Operation not permitted
>>> 10:51:55.515949 IP 10.20.11.33.921 > 10.20.3.2.2049: Flags [.], ack
>>> 3569361440, win 115, options [nop,nop,TS val 599750 ecr 255058541],
>> length 0
>>> 10:52:04.130310 IP 10.20.11.33.793500292 > 10.20.3.2.2049: 76 getattr fh
>>> 0,0/24
>>> 10:52:04.152178 IP 10.20.3.2.2049 > 10.20.11.33.793500292: reply ok 44
>>> getattr ERROR: Operation not permitted
>>>
>>> If I run the same mount command (mount -oro,intr host:dir mountpoint)
>>> from within a virtual machine with 2.6.38.2 there, everything mounts OK.
>>
>> Does the attached patch help?
>
> No, still the operation not permitted in the tcpdump output and no mount.
The next tree from 20110411 still doesn't work. The topmost commit in
fs/nfs/namespace.c is:
commit 418875900e3de4831c84f86ae4756690dac5be77
Author: Bryan Schumaker <[email protected]>
Date: Wed Apr 6 14:33:28 2011 -0400
NFS: Fix a signed vs. unsigned secinfo bug
I bisected it to (in vanilla already):
8f70e95f9f4159184f557a1db60c909d7c1bd2e3 is the first bad commit
commit 8f70e95f9f4159184f557a1db60c909d7c1bd2e3
Author: Bryan Schumaker <[email protected]>
Date: Thu Mar 24 17:12:31 2011 +0000
NFS: Determine initial mount security
When sec=<something> is not presented as a mount option,
we should attempt to determine what security flavor the
server is using.
Signed-off-by: Bryan Schumaker <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
:040000 040000 8e5a640b37e00f0df21e1d9cd9aff160df2d5938
0152daa67bc8d12e32cda5f4a036807d2e380392 M fs
:040000 040000 f74aa33f8597cb82cd0fd7d90d84e0660b7f5804
527bc0ca6975cedc7e684b45dc9961f8aaf1207a M include
:040000 040000 87559d2f211ea905343a86c8551b6610dd239891
7e4ee0e5eddf12474b6de9e7fdb6218b6165bdb2 M net
thanks,
--
js
suse labs
Ccing Bryan
On 04/11/2011 10:40 PM, Jiri Slaby wrote:
> On 04/07/2011 08:42 AM, Jiri Slaby wrote:
>> On 04/06/2011 10:44 PM, Myklebust, Trond wrote:
>>> On Sat, 2011-04-02 at 10:56 +0200, Jiri Slaby wrote:
>>>> On 03/31/2011 11:48 PM, [email protected] wrote:
>>>>> The mm-of-the-moment snapshot 2011-03-31-14-48 has been uploaded to
>>>>
>>>> Hi, nfs client is defunct in this kernel. Tcpdump says:
>>>> 10:51:55.489717 IP 10.20.11.33.759945860 > 10.20.3.2.2049: 132 getattr
>>>> fh 0,0/24
>>>> 10:51:55.515927 IP 10.20.3.2.2049 > 10.20.11.33.759945860: reply ok 44
>>>> getattr ERROR: Operation not permitted
>>>> 10:51:55.515949 IP 10.20.11.33.921 > 10.20.3.2.2049: Flags [.], ack
>>>> 3569361440, win 115, options [nop,nop,TS val 599750 ecr 255058541],
>>> length 0
>>>> 10:52:04.130310 IP 10.20.11.33.793500292 > 10.20.3.2.2049: 76 getattr fh
>>>> 0,0/24
>>>> 10:52:04.152178 IP 10.20.3.2.2049 > 10.20.11.33.793500292: reply ok 44
>>>> getattr ERROR: Operation not permitted
>>>>
>>>> If I run the same mount command (mount -oro,intr host:dir mountpoint)
>>>> from within a virtual machine with 2.6.38.2 there, everything mounts OK.
>>>
>>> Does the attached patch help?
>>
>> No, still the operation not permitted in the tcpdump output and no mount.
>
> The next tree from 20110411 still doesn't work. The topmost commit in
> fs/nfs/namespace.c is:
> commit 418875900e3de4831c84f86ae4756690dac5be77
> Author: Bryan Schumaker <[email protected]>
> Date: Wed Apr 6 14:33:28 2011 -0400
>
> NFS: Fix a signed vs. unsigned secinfo bug
>
>
> I bisected it to (in vanilla already):
>
> 8f70e95f9f4159184f557a1db60c909d7c1bd2e3 is the first bad commit
> commit 8f70e95f9f4159184f557a1db60c909d7c1bd2e3
> Author: Bryan Schumaker <[email protected]>
> Date: Thu Mar 24 17:12:31 2011 +0000
>
> NFS: Determine initial mount security
>
> When sec=<something> is not presented as a mount option,
> we should attempt to determine what security flavor the
> server is using.
>
> Signed-off-by: Bryan Schumaker <[email protected]>
> Signed-off-by: Trond Myklebust <[email protected]>
>
> :040000 040000 8e5a640b37e00f0df21e1d9cd9aff160df2d5938
> 0152daa67bc8d12e32cda5f4a036807d2e380392 M fs
> :040000 040000 f74aa33f8597cb82cd0fd7d90d84e0660b7f5804
> 527bc0ca6975cedc7e684b45dc9961f8aaf1207a M include
> :040000 040000 87559d2f211ea905343a86c8551b6610dd239891
> 7e4ee0e5eddf12474b6de9e7fdb6218b6165bdb2 M net
>
> thanks,
--
js
suse labs
On 04/11/2011 04:40 PM, Jiri Slaby wrote:
> On 04/07/2011 08:42 AM, Jiri Slaby wrote:
>> On 04/06/2011 10:44 PM, Myklebust, Trond wrote:
>>> On Sat, 2011-04-02 at 10:56 +0200, Jiri Slaby wrote:
>>>> On 03/31/2011 11:48 PM, [email protected] wrote:
>>>>> The mm-of-the-moment snapshot 2011-03-31-14-48 has been uploaded to
>>>>
>>>> Hi, nfs client is defunct in this kernel. Tcpdump says:
>>>> 10:51:55.489717 IP 10.20.11.33.759945860 > 10.20.3.2.2049: 132 getattr
>>>> fh 0,0/24
>>>> 10:51:55.515927 IP 10.20.3.2.2049 > 10.20.11.33.759945860: reply ok 44
>>>> getattr ERROR: Operation not permitted
>>>> 10:51:55.515949 IP 10.20.11.33.921 > 10.20.3.2.2049: Flags [.], ack
>>>> 3569361440, win 115, options [nop,nop,TS val 599750 ecr 255058541],
>>> length 0
>>>> 10:52:04.130310 IP 10.20.11.33.793500292 > 10.20.3.2.2049: 76 getattr fh
>>>> 0,0/24
>>>> 10:52:04.152178 IP 10.20.3.2.2049 > 10.20.11.33.793500292: reply ok 44
>>>> getattr ERROR: Operation not permitted
>>>>
>>>> If I run the same mount command (mount -oro,intr host:dir mountpoint)
>>>> from within a virtual machine with 2.6.38.2 there, everything mounts OK.
>>>
>>> Does the attached patch help?
>>
>> No, still the operation not permitted in the tcpdump output and no mount.
Does this patch help?
- Bryan
When attempting an initial mount, we should only attempt other
authflavors if AUTH_UNIX receives a NFS4ERR_WRONGSEC error.
This allows other errors to be passed back to userspace programs.
Signed-off-by: Bryan Schumaker <[email protected]>
---
diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index dfd1e6d..9bf41ea 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -2204,8 +2204,6 @@ static int nfs4_lookup_root_sec(struct nfs_server *server, struct nfs_fh *fhandl
goto out;
}
ret = nfs4_lookup_root(server, fhandle, info);
- if (ret < 0)
- ret = -EAGAIN;
out:
return ret;
}
@@ -2226,7 +2224,7 @@ static int nfs4_proc_get_root(struct nfs_server *server, struct nfs_fh *fhandle,
for (i = 0; i < len; i++) {
status = nfs4_lookup_root_sec(server, fhandle, info, flav_array[i]);
- if (status == 0)
+ if (status != -EPERM)
break;
}
if (status == 0)
>
> The next tree from 20110411 still doesn't work. The topmost commit in
> fs/nfs/namespace.c is:
> commit 418875900e3de4831c84f86ae4756690dac5be77
> Author: Bryan Schumaker <[email protected]>
> Date: Wed Apr 6 14:33:28 2011 -0400
>
> NFS: Fix a signed vs. unsigned secinfo bug
>
>
> I bisected it to (in vanilla already):
>
> 8f70e95f9f4159184f557a1db60c909d7c1bd2e3 is the first bad commit
> commit 8f70e95f9f4159184f557a1db60c909d7c1bd2e3
> Author: Bryan Schumaker <[email protected]>
> Date: Thu Mar 24 17:12:31 2011 +0000
>
> NFS: Determine initial mount security
>
> When sec=<something> is not presented as a mount option,
> we should attempt to determine what security flavor the
> server is using.
>
> Signed-off-by: Bryan Schumaker <[email protected]>
> Signed-off-by: Trond Myklebust <[email protected]>
>
> :040000 040000 8e5a640b37e00f0df21e1d9cd9aff160df2d5938
> 0152daa67bc8d12e32cda5f4a036807d2e380392 M fs
> :040000 040000 f74aa33f8597cb82cd0fd7d90d84e0660b7f5804
> 527bc0ca6975cedc7e684b45dc9961f8aaf1207a M include
> :040000 040000 87559d2f211ea905343a86c8551b6610dd239891
> 7e4ee0e5eddf12474b6de9e7fdb6218b6165bdb2 M net
>
> thanks,
On 04/11/2011 10:40 PM, Jiri Slaby wrote:
> Ccing Bryan
>
> On 04/11/2011 10:40 PM, Jiri Slaby wrote:
>> On 04/07/2011 08:42 AM, Jiri Slaby wrote:
>>> On 04/06/2011 10:44 PM, Myklebust, Trond wrote:
>>>> On Sat, 2011-04-02 at 10:56 +0200, Jiri Slaby wrote:
>>>>> On 03/31/2011 11:48 PM, [email protected] wrote:
>>>>>> The mm-of-the-moment snapshot 2011-03-31-14-48 has been uploaded to
>>>>>
>>>>> Hi, nfs client is defunct in this kernel. Tcpdump says:
>>>>> 10:51:55.489717 IP 10.20.11.33.759945860 > 10.20.3.2.2049: 132 getattr
>>>>> fh 0,0/24
>>>>> 10:51:55.515927 IP 10.20.3.2.2049 > 10.20.11.33.759945860: reply ok 44
>>>>> getattr ERROR: Operation not permitted
>>>>> 10:51:55.515949 IP 10.20.11.33.921 > 10.20.3.2.2049: Flags [.], ack
>>>>> 3569361440, win 115, options [nop,nop,TS val 599750 ecr 255058541],
>>>> length 0
>>>>> 10:52:04.130310 IP 10.20.11.33.793500292 > 10.20.3.2.2049: 76 getattr fh
>>>>> 0,0/24
>>>>> 10:52:04.152178 IP 10.20.3.2.2049 > 10.20.11.33.793500292: reply ok 44
>>>>> getattr ERROR: Operation not permitted
>>>>>
>>>>> If I run the same mount command (mount -oro,intr host:dir mountpoint)
>>>>> from within a virtual machine with 2.6.38.2 there, everything mounts OK.
>>>>
>>>> Does the attached patch help?
>>>
>>> No, still the operation not permitted in the tcpdump output and no mount.
>>
>> The next tree from 20110411 still doesn't work. The topmost commit in
>> fs/nfs/namespace.c is:
>> commit 418875900e3de4831c84f86ae4756690dac5be77
>> Author: Bryan Schumaker <[email protected]>
>> Date: Wed Apr 6 14:33:28 2011 -0400
>>
>> NFS: Fix a signed vs. unsigned secinfo bug
>>
>>
>> I bisected it to (in vanilla already):
>>
>> 8f70e95f9f4159184f557a1db60c909d7c1bd2e3 is the first bad commit
>> commit 8f70e95f9f4159184f557a1db60c909d7c1bd2e3
>> Author: Bryan Schumaker <[email protected]>
>> Date: Thu Mar 24 17:12:31 2011 +0000
>>
>> NFS: Determine initial mount security
>>
>> When sec=<something> is not presented as a mount option,
>> we should attempt to determine what security flavor the
>> server is using.
>>
>> Signed-off-by: Bryan Schumaker <[email protected]>
>> Signed-off-by: Trond Myklebust <[email protected]>
>>
>> :040000 040000 8e5a640b37e00f0df21e1d9cd9aff160df2d5938
>> 0152daa67bc8d12e32cda5f4a036807d2e380392 M fs
>> :040000 040000 f74aa33f8597cb82cd0fd7d90d84e0660b7f5804
>> 527bc0ca6975cedc7e684b45dc9961f8aaf1207a M include
>> :040000 040000 87559d2f211ea905343a86c8551b6610dd239891
>> 7e4ee0e5eddf12474b6de9e7fdb6218b6165bdb2 M net
Sorry for an extra message. I've just found out that there appears
messages in dmesg:
[ 58.656048] RPC: AUTH_GSS upcall timed out.
[ 58.656050] Please check user daemon is running.
[ 88.656065] RPC: AUTH_GSS upcall timed out.
[ 88.656068] Please check user daemon is running.
[ 118.656077] RPC: AUTH_GSS upcall timed out.
[ 118.656080] Please check user daemon is running.
[ 148.656049] RPC: AUTH_GSS upcall timed out.
[ 148.656052] Please check user daemon is running.
[ 178.656046] RPC: AUTH_GSS upcall timed out.
[ 178.656049] Please check user daemon is running.
I instrumented the code and it's stuck with trying RPC_AUTH_GSS_KRB5.
I don't use GSS at all.
regards,
--
js
suse labs
On 04/11/2011 10:56 PM, Bryan Schumaker wrote:
> On 04/11/2011 04:40 PM, Jiri Slaby wrote:
>> On 04/07/2011 08:42 AM, Jiri Slaby wrote:
>>> On 04/06/2011 10:44 PM, Myklebust, Trond wrote:
>>>> On Sat, 2011-04-02 at 10:56 +0200, Jiri Slaby wrote:
>>>>> On 03/31/2011 11:48 PM, [email protected] wrote:
>>>>>> The mm-of-the-moment snapshot 2011-03-31-14-48 has been uploaded to
>>>>>
>>>>> Hi, nfs client is defunct in this kernel. Tcpdump says:
>>>>> 10:51:55.489717 IP 10.20.11.33.759945860 > 10.20.3.2.2049: 132 getattr
>>>>> fh 0,0/24
>>>>> 10:51:55.515927 IP 10.20.3.2.2049 > 10.20.11.33.759945860: reply ok 44
>>>>> getattr ERROR: Operation not permitted
>>>>> 10:51:55.515949 IP 10.20.11.33.921 > 10.20.3.2.2049: Flags [.], ack
>>>>> 3569361440, win 115, options [nop,nop,TS val 599750 ecr 255058541],
>>>> length 0
>>>>> 10:52:04.130310 IP 10.20.11.33.793500292 > 10.20.3.2.2049: 76 getattr fh
>>>>> 0,0/24
>>>>> 10:52:04.152178 IP 10.20.3.2.2049 > 10.20.11.33.793500292: reply ok 44
>>>>> getattr ERROR: Operation not permitted
>>>>>
>>>>> If I run the same mount command (mount -oro,intr host:dir mountpoint)
>>>>> from within a virtual machine with 2.6.38.2 there, everything mounts OK.
>>>>
>>>> Does the attached patch help?
>>>
>>> No, still the operation not permitted in the tcpdump output and no mount.
>
> Does this patch help?
>
> - Bryan
>
> When attempting an initial mount, we should only attempt other
> authflavors if AUTH_UNIX receives a NFS4ERR_WRONGSEC error.
> This allows other errors to be passed back to userspace programs.
>
> Signed-off-by: Bryan Schumaker <[email protected]>
> ---
> diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
> index dfd1e6d..9bf41ea 100644
> --- a/fs/nfs/nfs4proc.c
> +++ b/fs/nfs/nfs4proc.c
> @@ -2204,8 +2204,6 @@ static int nfs4_lookup_root_sec(struct nfs_server *server, struct nfs_fh *fhandl
> goto out;
> }
> ret = nfs4_lookup_root(server, fhandle, info);
> - if (ret < 0)
> - ret = -EAGAIN;
> out:
> return ret;
> }
> @@ -2226,7 +2224,7 @@ static int nfs4_proc_get_root(struct nfs_server *server, struct nfs_fh *fhandle,
>
> for (i = 0; i < len; i++) {
No, the patch fixes a problem I have after I add the following test here:
if (flav_array[i] > 100)
continue;
Without this test it still loops inside gss auth create function with:
RPC: AUTH_GSS upcall timed out.
> status = nfs4_lookup_root_sec(server, fhandle, info, flav_array[i]);
> - if (status == 0)
> + if (status != -EPERM)
> break;
> }
> if (status == 0)
thanks,
--
js
suse labs
On 04/11/2011 05:08 PM, Jiri Slaby wrote:
>
> Sorry for an extra message. I've just found out that there appears
> messages in dmesg:
> [ 58.656048] RPC: AUTH_GSS upcall timed out.
> [ 58.656050] Please check user daemon is running.
> [ 88.656065] RPC: AUTH_GSS upcall timed out.
> [ 88.656068] Please check user daemon is running.
> [ 118.656077] RPC: AUTH_GSS upcall timed out.
> [ 118.656080] Please check user daemon is running.
> [ 148.656049] RPC: AUTH_GSS upcall timed out.
> [ 148.656052] Please check user daemon is running.
> [ 178.656046] RPC: AUTH_GSS upcall timed out.
> [ 178.656049] Please check user daemon is running.
>
>
> I instrumented the code and it's stuck with trying RPC_AUTH_GSS_KRB5.
>
> I don't use GSS at all.
>
> regards,
Does this patch help?
- Bryan
There can be an infinite loop if gss_create_upcall() is called without
the userspace program running. To prevent this, we return -EACCES if
we notice that pipe_version hasn't changed (indicating that the pipe
has not been opened).
Signed-off-by: Bryan Schumaker <[email protected]>
--
diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index 9bf41ea..8a03ee0 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -2224,8 +2224,9 @@ static int nfs4_proc_get_root(struct nfs_server *server, struct nfs_fh *fhandle,
for (i = 0; i < len; i++) {
status = nfs4_lookup_root_sec(server, fhandle, info, flav_array[i]);
- if (status != -EPERM)
- break;
+ if (status == -EPERM || status == -EACCES)
+ continue;
+ break;
}
if (status == 0)
status = nfs4_server_capabilities(server, fhandle);
diff --git a/net/sunrpc/auth_gss/auth_gss.c b/net/sunrpc/auth_gss/auth_gss.c
index f3914d0..339ba64 100644
--- a/net/sunrpc/auth_gss/auth_gss.c
+++ b/net/sunrpc/auth_gss/auth_gss.c
@@ -520,7 +520,7 @@ gss_refresh_upcall(struct rpc_task *task)
warn_gssd();
task->tk_timeout = 15*HZ;
rpc_sleep_on(&pipe_version_rpc_waitqueue, task, NULL);
- return 0;
+ return -EAGAIN;
}
if (IS_ERR(gss_msg)) {
err = PTR_ERR(gss_msg);
@@ -563,10 +563,12 @@ retry:
if (PTR_ERR(gss_msg) == -EAGAIN) {
err = wait_event_interruptible_timeout(pipe_version_waitqueue,
pipe_version >= 0, 15*HZ);
+ if (pipe_version < 0) {
+ warn_gssd();
+ err = -EACCES;
+ }
if (err)
goto out;
- if (pipe_version < 0)
- warn_gssd();
goto retry;
}
if (IS_ERR(gss_msg)) {
On 04/12/2011 07:41 PM, Bryan Schumaker wrote:
> On 04/11/2011 05:08 PM, Jiri Slaby wrote:
>>
>> Sorry for an extra message. I've just found out that there appears
>> messages in dmesg:
>> [ 58.656048] RPC: AUTH_GSS upcall timed out.
>> [ 58.656050] Please check user daemon is running.
>> [ 88.656065] RPC: AUTH_GSS upcall timed out.
>> [ 88.656068] Please check user daemon is running.
>> [ 118.656077] RPC: AUTH_GSS upcall timed out.
>> [ 118.656080] Please check user daemon is running.
>> [ 148.656049] RPC: AUTH_GSS upcall timed out.
>> [ 148.656052] Please check user daemon is running.
>> [ 178.656046] RPC: AUTH_GSS upcall timed out.
>> [ 178.656049] Please check user daemon is running.
>>
>>
>> I instrumented the code and it's stuck with trying RPC_AUTH_GSS_KRB5.
>>
>> I don't use GSS at all.
>>
>> regards,
>
> Does this patch help?
>
> - Bryan
>
>
>
> There can be an infinite loop if gss_create_upcall() is called without
> the userspace program running. To prevent this, we return -EACCES if
> we notice that pipe_version hasn't changed (indicating that the pipe
> has not been opened).
Yes, it fixes the problem. But it waits 15s before it times out. This is
inacceptable for automounted NFS dirs.
thanks,
--
js
suse labs
On Tue, 2011-04-12 at 20:05 +0200, Jiri Slaby wrote:
> On 04/12/2011 07:41 PM, Bryan Schumaker wrote:
> > On 04/11/2011 05:08 PM, Jiri Slaby wrote:
> >>
> >> Sorry for an extra message. I've just found out that there appears
> >> messages in dmesg:
> >> [ 58.656048] RPC: AUTH_GSS upcall timed out.
> >> [ 58.656050] Please check user daemon is running.
> >> [ 88.656065] RPC: AUTH_GSS upcall timed out.
> >> [ 88.656068] Please check user daemon is running.
> >> [ 118.656077] RPC: AUTH_GSS upcall timed out.
> >> [ 118.656080] Please check user daemon is running.
> >> [ 148.656049] RPC: AUTH_GSS upcall timed out.
> >> [ 148.656052] Please check user daemon is running.
> >> [ 178.656046] RPC: AUTH_GSS upcall timed out.
> >> [ 178.656049] Please check user daemon is running.
> >>
> >>
> >> I instrumented the code and it's stuck with trying RPC_AUTH_GSS_KRB5.
> >>
> >> I don't use GSS at all.
> >>
> >> regards,
> >
> > Does this patch help?
> >
> > - Bryan
> >
> >
> >
> > There can be an infinite loop if gss_create_upcall() is called without
> > the userspace program running. To prevent this, we return -EACCES if
> > we notice that pipe_version hasn't changed (indicating that the pipe
> > has not been opened).
>
> Yes, it fixes the problem. But it waits 15s before it times out. This is
> inacceptable for automounted NFS dirs.
I'm still confused as to why you are hitting it at all. In the normal
autonegotiation case, the client should be trying to use AUTH_SYS first
and then trying rpcsec_gss if and only if that fails.
Are you really exporting a filesystem using AUTH_NULL as the only
supported flavour?
--
Trond Myklebust
Linux NFS client maintainer
NetApp
[email protected]
http://www.netapp.com
On 04/12/2011 08:31 PM, Trond Myklebust wrote:
>> Yes, it fixes the problem. But it waits 15s before it times out. This is
>> inacceptable for automounted NFS dirs.
>
> I'm still confused as to why you are hitting it at all. In the normal
> autonegotiation case, the client should be trying to use AUTH_SYS first
> and then trying rpcsec_gss if and only if that fails.
>
> Are you really exporting a filesystem using AUTH_NULL as the only
> supported flavour?
I don't know, I connect to a nfs server which is not maintained by me.
It looks like that. How can I find out?
thanks,
--
js
suse labs
On Tue, 2011-04-12 at 20:34 +0200, Jiri Slaby wrote:
> On 04/12/2011 08:31 PM, Trond Myklebust wrote:
> >> Yes, it fixes the problem. But it waits 15s before it times out. This is
> >> inacceptable for automounted NFS dirs.
> >
> > I'm still confused as to why you are hitting it at all. In the normal
> > autonegotiation case, the client should be trying to use AUTH_SYS first
> > and then trying rpcsec_gss if and only if that fails.
> >
> > Are you really exporting a filesystem using AUTH_NULL as the only
> > supported flavour?
>
> I don't know, I connect to a nfs server which is not maintained by me.
> It looks like that. How can I find out?
A wireshark trace of a successful mount would help.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
[email protected]
http://www.netapp.com
On 04/12/2011 02:34 PM, Jiri Slaby wrote:
> On 04/12/2011 08:31 PM, Trond Myklebust wrote:
>>> Yes, it fixes the problem. But it waits 15s before it times out. This is
>>> inacceptable for automounted NFS dirs.
>>
>> I'm still confused as to why you are hitting it at all. In the normal
>> autonegotiation case, the client should be trying to use AUTH_SYS first
>> and then trying rpcsec_gss if and only if that fails.
>>
>> Are you really exporting a filesystem using AUTH_NULL as the only
>> supported flavour?
>
> I don't know, I connect to a nfs server which is not maintained by me.
> It looks like that. How can I find out?
If you're not using gss for anything, you could try rmmod-ing rpcsec_gss_krb5 (and other rpcsec_gss_* modules).
- Bryan
>
> thanks,
On 04/12/2011 08:43 PM, Bryan Schumaker wrote:
> On 04/12/2011 02:34 PM, Jiri Slaby wrote:
>> On 04/12/2011 08:31 PM, Trond Myklebust wrote:
>>>> Yes, it fixes the problem. But it waits 15s before it times out. This is
>>>> inacceptable for automounted NFS dirs.
>>>
>>> I'm still confused as to why you are hitting it at all. In the normal
>>> autonegotiation case, the client should be trying to use AUTH_SYS first
>>> and then trying rpcsec_gss if and only if that fails.
>>>
>>> Are you really exporting a filesystem using AUTH_NULL as the only
>>> supported flavour?
>>
>> I don't know, I connect to a nfs server which is not maintained by me.
>> It looks like that. How can I find out?
>
> If you're not using gss for anything, you could try rmmod-ing rpcsec_gss_krb5 (and other rpcsec_gss_* modules).
I don't have NFS in modules. It's all built-in. And this one is
unconditionally selected because of CONFIG_NFS_V4.
regards,
--
js
suse labs
On 04/12/2011 02:52 PM, Jiri Slaby wrote:
> On 04/12/2011 08:43 PM, Bryan Schumaker wrote:
>> On 04/12/2011 02:34 PM, Jiri Slaby wrote:
>>> On 04/12/2011 08:31 PM, Trond Myklebust wrote:
>>>>> Yes, it fixes the problem. But it waits 15s before it times out. This is
>>>>> inacceptable for automounted NFS dirs.
>>>>
>>>> I'm still confused as to why you are hitting it at all. In the normal
>>>> autonegotiation case, the client should be trying to use AUTH_SYS first
>>>> and then trying rpcsec_gss if and only if that fails.
>>>>
>>>> Are you really exporting a filesystem using AUTH_NULL as the only
>>>> supported flavour?
>>>
>>> I don't know, I connect to a nfs server which is not maintained by me.
>>> It looks like that. How can I find out?
>>
>> If you're not using gss for anything, you could try rmmod-ing rpcsec_gss_krb5 (and other rpcsec_gss_* modules).
>
> I don't have NFS in modules. It's all built-in. And this one is
> unconditionally selected because of CONFIG_NFS_V4.
Does this patch help?
- Bryan
We should attempt an AUTH_NULL style mount before
trying gss flavors. This should prevent a hang if
gss modules are loaded but the userspace program
isn't running.
diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index 9bf41ea..4e3c16b 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -2218,8 +2218,8 @@ static int nfs4_proc_get_root(struct nfs_server *server, struct nfs_fh *fhandle,
rpc_authflavor_t flav_array[NFS_MAX_SECFLAVORS + 2];
flav_array[0] = RPC_AUTH_UNIX;
- len = gss_mech_list_pseudoflavors(&flav_array[1]);
- flav_array[1+len] = RPC_AUTH_NULL;
+ flav_array[1] = RPC_AUTH_NULL;
+ len = gss_mech_list_pseudoflavors(&flav_array[2]);
len += 2;
for (i = 0; i < len; i++) {
>
> regards,
On 04/13/2011 10:42 PM, Bryan Schumaker wrote:
> On 04/12/2011 02:52 PM, Jiri Slaby wrote:
>> On 04/12/2011 08:43 PM, Bryan Schumaker wrote:
>>> On 04/12/2011 02:34 PM, Jiri Slaby wrote:
>>>> On 04/12/2011 08:31 PM, Trond Myklebust wrote:
>>>>>> Yes, it fixes the problem. But it waits 15s before it times out. This is
>>>>>> inacceptable for automounted NFS dirs.
>>>>>
>>>>> I'm still confused as to why you are hitting it at all. In the normal
>>>>> autonegotiation case, the client should be trying to use AUTH_SYS first
>>>>> and then trying rpcsec_gss if and only if that fails.
>>>>>
>>>>> Are you really exporting a filesystem using AUTH_NULL as the only
>>>>> supported flavour?
>>>>
>>>> I don't know, I connect to a nfs server which is not maintained by me.
>>>> It looks like that. How can I find out?
>>>
>>> If you're not using gss for anything, you could try rmmod-ing rpcsec_gss_krb5 (and other rpcsec_gss_* modules).
>>
>> I don't have NFS in modules. It's all built-in. And this one is
>> unconditionally selected because of CONFIG_NFS_V4.
>
> Does this patch help?
Nope, it makes things even worse:
# mount -oro,intr XXX:/yyy /mnt/c/
<15s delay here>
mount.nfs: access denied by server while mounting XXX:/yyy
So in nfs4_proc_get_root I do:
printk("%s: %d %u\n", __func__, i, flav_array[i]);
status = nfs4_lookup_root_sec(server, fhandle, info, flav_array[i]);
printk("%s: res=%d\n", __func__, status);
and get:
[ 18.159818] nfs4_proc_get_root: 0 1
[ 18.214872] nfs4_proc_get_root: res=-1
[ 18.214875] nfs4_proc_get_root: 1 0
[ 18.254636] nfs4_proc_get_root: res=-1
[ 18.254639] nfs4_proc_get_root: 2 390003
[ 33.252174] RPC: AUTH_GSS upcall timed out.
[ 33.252177] Please check user daemon is running.
[ 33.252192] nfs4_proc_get_root: res=-13
If I revert that back and do the same:
[ 28.275569] nfs4_proc_get_root: 0 1
[ 28.296545] nfs4_proc_get_root: res=-1
[ 28.296548] nfs4_proc_get_root: 1 390003
[ 43.296107] RPC: AUTH_GSS upcall timed out.
[ 43.296108] Please check user daemon is running.
[ 43.296121] nfs4_proc_get_root: res=-13
[ 43.296122] nfs4_proc_get_root: 2 0
[ 43.318201] nfs4_proc_get_root: res=-1
I.e. all methods fail. And what matters is the last retval. From NULL it
is EPERM, from GSS it is EACCESS. For EPERM, mount(8) falls back to
nfs3, for EACCESS it dies terrible death.
linux-b984:~ # strace -fe mount -s 1000 mount -oro,intr XXX:/yyy /mnt/c/
Process 2396 attached
Process 2395 suspended
[pid 2396] mount("XXX:/yyy", "/mnt/c", "nfs", MS_RDONLY,
"intr,vers=4,addr=10.20.3.2,clientaddr=10.0.2.15") = -1 EPERM (Operation
not permitted)
[pid 2396] mount("XXX:/yyy", "/mnt/c", "nfs", MS_RDONLY,
"intr,addr=10.20.3.2,vers=3,proto=tcp,mountvers=3,mountproto=udp,mountport=709")
= 0
Process 2395 resumed
Process 2396 detached
--- SIGCHLD (Child exited) @ 0 (0) ---
thanks,
--
js
suse labs
On Thu, 2011-04-14 at 22:37 +0200, Jiri Slaby wrote:
> On 04/13/2011 10:42 PM, Bryan Schumaker wrote:
> > On 04/12/2011 02:52 PM, Jiri Slaby wrote:
> >> On 04/12/2011 08:43 PM, Bryan Schumaker wrote:
> >>> On 04/12/2011 02:34 PM, Jiri Slaby wrote:
> >>>> On 04/12/2011 08:31 PM, Trond Myklebust wrote:
> >>>>>> Yes, it fixes the problem. But it waits 15s before it times out. This is
> >>>>>> inacceptable for automounted NFS dirs.
> >>>>>
> >>>>> I'm still confused as to why you are hitting it at all. In the normal
> >>>>> autonegotiation case, the client should be trying to use AUTH_SYS first
> >>>>> and then trying rpcsec_gss if and only if that fails.
> >>>>>
> >>>>> Are you really exporting a filesystem using AUTH_NULL as the only
> >>>>> supported flavour?
> >>>>
> >>>> I don't know, I connect to a nfs server which is not maintained by me.
> >>>> It looks like that. How can I find out?
> >>>
> >>> If you're not using gss for anything, you could try rmmod-ing rpcsec_gss_krb5 (and other rpcsec_gss_* modules).
> >>
> >> I don't have NFS in modules. It's all built-in. And this one is
> >> unconditionally selected because of CONFIG_NFS_V4.
> >
> > Does this patch help?
>
> Nope, it makes things even worse:
> # mount -oro,intr XXX:/yyy /mnt/c/
> <15s delay here>
> mount.nfs: access denied by server while mounting XXX:/yyy
>
> So in nfs4_proc_get_root I do:
> printk("%s: %d %u\n", __func__, i, flav_array[i]);
> status = nfs4_lookup_root_sec(server, fhandle, info, flav_array[i]);
> printk("%s: res=%d\n", __func__, status);
> and get:
> [ 18.159818] nfs4_proc_get_root: 0 1
> [ 18.214872] nfs4_proc_get_root: res=-1
> [ 18.214875] nfs4_proc_get_root: 1 0
> [ 18.254636] nfs4_proc_get_root: res=-1
> [ 18.254639] nfs4_proc_get_root: 2 390003
> [ 33.252174] RPC: AUTH_GSS upcall timed out.
> [ 33.252177] Please check user daemon is running.
> [ 33.252192] nfs4_proc_get_root: res=-13
>
> If I revert that back and do the same:
> [ 28.275569] nfs4_proc_get_root: 0 1
> [ 28.296545] nfs4_proc_get_root: res=-1
> [ 28.296548] nfs4_proc_get_root: 1 390003
> [ 43.296107] RPC: AUTH_GSS upcall timed out.
> [ 43.296108] Please check user daemon is running.
> [ 43.296121] nfs4_proc_get_root: res=-13
> [ 43.296122] nfs4_proc_get_root: 2 0
> [ 43.318201] nfs4_proc_get_root: res=-1
>
> I.e. all methods fail. And what matters is the last retval. From NULL it
> is EPERM, from GSS it is EACCESS. For EPERM, mount(8) falls back to
> nfs3, for EACCESS it dies terrible death.
OK. That's good information. Thanks for testing!
I'm still curious as to why that NFS server is refusing all NFSv4 mounts
with NFS4ERR_WRONGSEC. Unless NFSv4 really is configured only to export
the root filesystem with RPCSEC_GSS, then that definitely sounds like a
bug...
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
[email protected]
http://www.netapp.com
On 04/14/2011 11:21 PM, Trond Myklebust wrote:
> On Thu, 2011-04-14 at 22:37 +0200, Jiri Slaby wrote:
>> On 04/13/2011 10:42 PM, Bryan Schumaker wrote:
>>> On 04/12/2011 02:52 PM, Jiri Slaby wrote:
>>>> On 04/12/2011 08:43 PM, Bryan Schumaker wrote:
>>>>> On 04/12/2011 02:34 PM, Jiri Slaby wrote:
>>>>>> On 04/12/2011 08:31 PM, Trond Myklebust wrote:
>>>>>>>> Yes, it fixes the problem. But it waits 15s before it times out. This is
>>>>>>>> inacceptable for automounted NFS dirs.
>>>>>>>
>>>>>>> I'm still confused as to why you are hitting it at all. In the normal
>>>>>>> autonegotiation case, the client should be trying to use AUTH_SYS first
>>>>>>> and then trying rpcsec_gss if and only if that fails.
>>>>>>>
>>>>>>> Are you really exporting a filesystem using AUTH_NULL as the only
>>>>>>> supported flavour?
>>>>>>
>>>>>> I don't know, I connect to a nfs server which is not maintained by me.
>>>>>> It looks like that. How can I find out?
>>>>>
>>>>> If you're not using gss for anything, you could try rmmod-ing rpcsec_gss_krb5 (and other rpcsec_gss_* modules).
>>>>
>>>> I don't have NFS in modules. It's all built-in. And this one is
>>>> unconditionally selected because of CONFIG_NFS_V4.
>>>
>>> Does this patch help?
>>
>> Nope, it makes things even worse:
>> # mount -oro,intr XXX:/yyy /mnt/c/
>> <15s delay here>
>> mount.nfs: access denied by server while mounting XXX:/yyy
>>
>> So in nfs4_proc_get_root I do:
>> printk("%s: %d %u\n", __func__, i, flav_array[i]);
>> status = nfs4_lookup_root_sec(server, fhandle, info, flav_array[i]);
>> printk("%s: res=%d\n", __func__, status);
>> and get:
>> [ 18.159818] nfs4_proc_get_root: 0 1
>> [ 18.214872] nfs4_proc_get_root: res=-1
>> [ 18.214875] nfs4_proc_get_root: 1 0
>> [ 18.254636] nfs4_proc_get_root: res=-1
>> [ 18.254639] nfs4_proc_get_root: 2 390003
>> [ 33.252174] RPC: AUTH_GSS upcall timed out.
>> [ 33.252177] Please check user daemon is running.
>> [ 33.252192] nfs4_proc_get_root: res=-13
>>
>> If I revert that back and do the same:
>> [ 28.275569] nfs4_proc_get_root: 0 1
>> [ 28.296545] nfs4_proc_get_root: res=-1
>> [ 28.296548] nfs4_proc_get_root: 1 390003
>> [ 43.296107] RPC: AUTH_GSS upcall timed out.
>> [ 43.296108] Please check user daemon is running.
>> [ 43.296121] nfs4_proc_get_root: res=-13
>> [ 43.296122] nfs4_proc_get_root: 2 0
>> [ 43.318201] nfs4_proc_get_root: res=-1
>>
>> I.e. all methods fail. And what matters is the last retval. From NULL it
>> is EPERM, from GSS it is EACCESS. For EPERM, mount(8) falls back to
>> nfs3, for EACCESS it dies terrible death.
>
> OK. That's good information. Thanks for testing!
>
> I'm still curious as to why that NFS server is refusing all NFSv4 mounts
> with NFS4ERR_WRONGSEC. Unless NFSv4 really is configured only to export
> the root filesystem with RPCSEC_GSS, then that definitely sounds like a
> bug...
With gssd running if that helps:
[ 229.806528] nfs4_proc_get_root: 0 1
[ 229.828491] nfs4_proc_get_root: res=-1
[ 229.828494] nfs4_proc_get_root: 1 390003
[ 229.896994] nfs4_proc_get_root: res=-13
[ 229.896997] nfs4_proc_get_root: 2 0
[ 229.920344] nfs4_proc_get_root: res=-1
thanks,
--
js
suse labs