mmotm 2009-06-30-12-50 uploaded

mmotm 2009-06-30-12-50 uploaded

[akpm]

The mm-of-the-moment snapshot 2009-06-30-12-50 has been uploaded to

   http://userweb.kernel.org/~akpm/mmotm/

and will soon be available at

   git://git.zen-sources.org/zen/mmotm.git

It contains the following patches against 2.6.31-rc1:

origin.patch
eventfd-revised-interface-and-cleanups-4th-rev.patch
gcov-fix-__ctors_start-alignment.patch
maintainers-update-edac-i82975x.patch
fbdev-work-around-old-compiler-bug.patch
alpha-fix-percpu-build-breakage.patch
gcov-fix-documentation.patch
parport-serial-add-support-for-netmos-9901-multi-io-card.patch
edac-add-ddr3-memory-type-for-mpc85xx-edac.patch
elf-limit-max-map-count-to-safe-value.patch
ext2-return-eio-not-estale-on-directory-traversal-through-deleted-inode.patch
dmapools-protect-page_list-walk-in-show_pools.patch
spi-new-spi-mode-bits.patch
spi-add-spi_master-flag-word.patch
fbdev-add-mutex-for-fb_mmap-locking.patch
spi-bitbang-bugfix-in-message-setup.patch
kernel-resourcec-fix-sign-extension-in-reserve_setup.patch
maintainers-starfire-duralan-update.patch
bsdacct-fix-access-to-invalid-filp-in-acct_on.patch
cpusets-document-adding-removing-cpus-to-cpuset-elaborately.patch
x86-only-clear-node_states-for-64bit.patch
gpio-pl061-fix-probe-error-handling-code.patch
gpio-pl061-fix-irq-handling-for-gpios-=-pl061_gpio_nr.patch
atyfb-fix-hp-omnibook-500-reboot-hang.patch
atyfb-fix-alignment-for-block-writes.patch
bfin-delay-irq-registration-until-driver-is-ready.patch
floppy-fix-lock-imbalance.patch
hostfs-set-maximum-filesize-in-superblock-for-proper-lfs-support.patch
repeatable-slab-corruption-with-ltp-msgctl08.patch
linux-next.patch
next-remove-localversion.patch
i-need-old-gcc.patch
kernel-core-add-smp_call_function_any.patch
kernel-core-add-smp_call_function_any-update.patch
arch-x86-kernel-cpu-cpufreq-acpi-cpufreqc-avoid-cross-cpu-interrupts-by-using-smp_call_function_any.patch
s3c-fix-check-of-index-into-s3c_gpios.patch
pcmcia-yenta-add-missing-__devexit-marking.patch
pcmcia-pccard-deadlock-fix.patch
powerpc-sky-cpu-redundant-or-incorrect-tests-on-unsigned.patch
video-initial-support-for-adv7180.patch
media-remove-redundant-tests-on-unsigned.patch
posix_cpu_timers_exit_group-do-not-use-thread_group_cputimer.patch
input-drivers-input-xpadc-improve-xbox-360-wireless-support-and-add-sysfs-interface.patch
input-documentation-input-xpadtxt-update-for-new-driver-functionality.patch
input-more-i8042-reset-quirks-for-msi-wind-clone-netbooks.patch
input-tsc2007-remove-hr-timer.patch
input-tsc2007-make-platform-callbacks-optional.patch
mmc-in-mmc_power_up-use-previously-selected-ocr-if-available.patch
omap-hsmmc-do-not-enable-buffer-ready-interrupt-if-using-dma.patch
jffs2-move-jffs2_gcd_mtd-threads-to-the-new-kthread-api.patch
mtd-sst25l-non-jedec-spi-flash-driver.patch
mtd-sst25l-non-jedec-spi-flash-driver-update.patch
mtd-sst25l-non-jedec-spi-flash-driver-fix.patch
drivers-mtd-mtdcorec-make-symbols-static.patch
3x59x-fix-pci-resource-management.patch
3x59x-fix-pci-resource-management-checkpatch-fixes.patch
ext4-remove-redundant-test-on-unsigned.patch
sunrpc-use-formatting-of-module-name-in-sunrpc.patch
parisc-remove-obsolete-hw_interrupt_type.patch
serial_txx9-use-container_of-instead-of-direct-cast.patch
icom-converting-space-to-tabs.patch
drivers-serial-bfin_sport_uartc-remove-wrong-and-unneeded-memset.patch
serial-add-parameter-to-force-skipping-the-test-for-the-txen-bug.patch
hypfs-remove-useless-variable-qname.patch
scsi-use-the-common-hex_asc-array-rather-than-a-private-one.patch
scsi-gdthc-use-unaligned-access-helpers.patch
scsi-annotate-gdth_rdcap_data-gdth_rdcap16_data-endianness.patch
scsi-add-__init-__exit-macros-to-ibmvstgtc.patch
comedi-jr3_pcic-add-required-includes.patch
drivers-usb-gadget-s3c2410_udcc-fix.patch
drivers-usb-serial-ti_usb_3410_5052c-fix-uninitialied-var-warning.patch
vfs-fix-vfs_rename_dir-for-fs_rename_does_d_move-filesystems.patch
raw-fix-rawctl-compat-ioctls-breakage-on-amd64-and-itanic.patch
vfs-improve-comment-describing-fget_light.patch
libfs-make-simple_read_from_buffer-conventional.patch
fs-inodec-add-dev-id-and-inode-number-for-debugging-in-init_special_inode.patch
vfs-split-generic_forget_inode-so-that-hugetlbfs-does-not-have-to-copy-it.patch
seq_file-return-a-negative-error-code-when-seq_path_root-fails.patch
fs-fix-overflow-in-sys_mount-for-in-kernel-calls.patch
fs-fix-overflow-in-sys_mount-for-in-kernel-calls-fix.patch
wireless-remove-redundant-tests-on-unsigned.patch
xtensa-variant-specific-code.patch
mm.patch
genirq-do-not-disable-irq_wakeup-marked-irqs-on-suspend.patch
cred_guard_mutex-do-not-return-eintr-to-user-space.patch
page-allocator-ensure-that-processes-that-have-been-oom-killed-exit-the-page-allocator.patch
cciss-fix-the-termination-of-the-scanning-thread.patch
dm-fix-exstore-lookup-error.patch
dm-table-pass-devices-data-start-to-blk_stack_limits-in-bytes.patch
kernel-doc-move-ignoring-kmemcheck.patch
maintainers-update-atlx-contact-info.patch
arch-x86-oprofile-op_model_amdc-fix-op_amd_handle_ibs-return-type.patch
drivers-rtc-rtc-cmosc-cmos_init-dont-ignore-pnp_register_driver-return-value.patch
serial-bfin_5xx-fix-building-as-module-when-early-printk-is-enabled.patch
oom-move-oom_adj-value-from-task_struct-to-mm_struct-fix.patch
clocksource-save-mult_orig-in-clocksource_disable.patch
usbconsole-fix-regression-in-usb-console-on-kernel-boot.patch
usb-serial-regression-fix-to-move-sysrq-from-hot-path.patch
mm-make-swap-token-dummies-static-inlines.patch
mm-make-swap-token-dummies-static-inlines-fix.patch
mm-make-swap-token-dummies-static-inlines-fix-2.patch
mm-remove-obsoleted-alloc_pages-cpuset-comment.patch
readahead-add-blk_run_backing_dev.patch
readahead-add-blk_run_backing_dev-fix.patch
readahead-add-blk_run_backing_dev-fix-fix-2.patch
memory-hotplug-update-zone-pcp-at-memory-online.patch
memory-hotplug-update-zone-pcp-at-memory-online-fix.patch
memory-hotplug-exclude-isolated-page-from-pco-page-alloc.patch
memory-hotplug-make-pages-from-movable-zone-always-isolatable.patch
memory-hotplug-alloc-page-from-other-node-in-memory-online.patch
memory-hotplug-migrate-swap-cache-page.patch
vmscan-dont-attempt-to-reclaim-anon-page-in-lumpy-reclaim-when-no-swap-space-is-available.patch
page_alloc-fix-kernel-doc-warning.patch
hugetlb-balance-freeing-of-huge-pages-across-nodes.patch
hugetlb-use-free_pool_huge_page-to-return-unused-surplus-pages.patch
hugetlb-clean-up-and-update-huge-pages-documentation.patch
mm-prevent-balance_dirty_pages-from-doing-too-much-work.patch
frv-duplicate-output_buffer-of-e03.patch
frv-duplicate-output_buffer-of-e03-checkpatch-fixes.patch
m32r-remove-redundant-tests-on-unsigned.patch
m68k-count-can-reach-51-not-50.patch
m68k-cnt-reaches-1-not-0.patch
arch-m68k-include-asm-motorola_pgalloch-fix-kunmap-arg.patch
rework-fix-is_single_threaded.patch
printk-boot_delay-rename-printk_delay_msec-to-loops_per_msec.patch
printk-boot_delay-rename-printk_delay_msec-to-loops_per_msec-fix.patch
printk-boot_delay-rename-printk_delay_msec-to-loops_per_msec-fix-2.patch
printk-add-printk_delay-to-make-messages-readable-for-some-scenarios.patch
printk-add-printk_delay-to-make-messages-readable-for-some-scenarios-fix.patch
printk-add-printk_delay-to-make-messages-readable-for-some-scenarios-cleanup.patch
move-magic-numbers-into-magich.patch
move-magic-numbers-into-magich-update.patch
getrusage-fill-ru_maxrss-value.patch
getrusage-fill-ru_maxrss-value-update.patch
asm-sections-add-text-data-checking-functions-for-arches-to-override.patch
kallsyms-use-new-arch_is_kernel_text.patch
lockdep-use-new-arch_is_kernel_data.patch
blackfin-override-text-data-checking-functions.patch
drivers-hwmon-coretempc-enable-the-intel-atom.patch
lis3-fix-typo.patch
lis3-add-free-fall-wakeup-function-via-platform_data.patch
lis3-add-power-management-functions.patch
lis3_spi-code-cleanups.patch
proc-connector-add-event-for-process-becoming-session-leader.patch
proc-connector-add-event-for-process-becoming-session-leader-checkpatch-fixes.patch
procfs-provide-stack-information-for-threads-v08.patch
spi-remove-imx-spi-driver.patch
spi-add-spi-driver-for-most-known-imx-socs.patch
rtc-add-driver-for-mxcs-internal-rtc-module.patch
rtc-add-driver-for-mxcs-internal-rtc-module-fix.patch
rtc-u300-coh-901-331-rtc-driver-v3.patch
rtc-update-documentation-wrt-rtc_pie-irq_set_state.patch
rtc-bfin-do-not-share-rtc-irq.patch
rtc-add-freescale-stmp37xx-378x-driver.patch
rtc-philips-nxp-pcf2123-driver.patch
rtc-philips-nxp-pcf2123-driver-v03.patch
rtc-philips-nxp-pcf2123-driver-v03-fix.patch
rtc-reorder-makefile.patch
rtc-driver-for-pcap2-pmic.patch
rtc-driver-for-pcap2-pmic-update.patch
gpiolib-allow-exported-gpio-nodes-to-be-named-using-sysfs-links.patch
gpio-add-mc33880-driver.patch
gpio-update-vr41xx-gpio-driver-to-use-gpiolib.patch
omapfb-add-support-for-the-apollon-lcd.patch
omapfb-add-support-for-mipi-dcs-compatible-lcds.patch
omapfb-add-support-for-the-amstrad-delta-lcd.patch
omapfb-add-support-for-the-2430sdp-lcd.patch
omapfb-add-support-for-the-omap2evm-lcd.patch
omapfb-add-support-for-the-3430sdp-lcd.patch
omapfb-add-support-for-the-omap3-evm-lcd.patch
omapfb-add-support-for-the-omap3-beagle-dvi-output.patch
omapfb-add-support-for-the-gumstix-overo-lcd.patch
omapfb-add-support-for-the-zoom-mdk-lcd.patch
omapfb-add-support-for-rotation-on-the-blizzard-lcd-ctrl.patch
n770-enable-lcd-mipi-dcs-in-kconfig.patch
omapfb-dispc-various-typo-fixes.patch
omapfb-dispc-disable-iface-clocks-along-with-func-clocks.patch
omapfb-dispc-enable-wake-up-capability.patch
omapfb-dispc-allow-multiple-external-irq-handlers.patch
omapfb-suspend-resume-only-if-fb-device-is-already-initialized.patch
omapfb-fix-coding-style-remove-dead-line.patch
omapfb-add-fb-manual-update-option-to-kconfig.patch
omapfb-hwa742-fix-pointer-to-be-const.patch
atyfb-coding-style-cleanup.patch
framebuffer-support-for-htc-dream.patch
framebuffer-support-for-htc-dream-checkpatch-fixes.patch
platinumfb-misplaced-parenthesis.patch
intelfb-fix-setting-of-active-pipe-with-lvds-displays.patch
hfsplus-identify-journal-info-block-in-volume-header.patch
hfsplus-fix-journal-detection.patch
memcg-remove-the-overhead-associated-with-the-root-cgroup.patch
memcg-remove-the-overhead-associated-with-the-root-cgroup-fix.patch
memcg-remove-the-overhead-associated-with-the-root-cgroup-fix-2.patch
memcg-add-comments-explaining-memory-barriers.patch
memcg-add-comments-explaining-memory-barriers-checkpatch-fixes.patch
signals-shift-security_task_wait-from-eligible_child-to-wait_consider_task.patch
signals-change-__wake_up_parent-to-use-filtered-wakeup.patch
signals-tracehook_notify_jctl-change.patch
utrace-core.patch
n_hdlc-add-buffer-flushing-checkpatch-fixes.patch
asm-generic-remove-calling-flush_write_buffers-in-dma_sync__for_cpu.patch
adfs-remove-redundant-test-on-unsigned.patch
aio-ifdef-fields-in-mm_struct.patch
bzip2-lzma-gzip-fix-comments-describing-decompressor-api.patch
bzip2-lzma-remove-nasty-uncompressed-size-hack-in-pre-boot-environment.patch
lzma-gzip-fix-potential-oops-when-input-data-is-truncated.patch
sound-core-pcm_timerc-use-lib-gcdc.patch
net-netfilter-ipvs-ip_vs_wrrc-use-lib-gcdc.patch
net-netfilter-ipvs-ip_vs_wrrc-use-lib-gcdc-fix.patch
vfs-take-2add-set_page_dirty_notag.patch
reiser4-vfs-add-super_operationssync_inodes-2.patch
reiser4-export-remove_from_page_cache.patch
reiser4-export-remove_from_page_cache-fix.patch
reiser4-export-find_get_pages.patch
reiser4.patch
reiser4-adjust-to-the-new-aops.patch
reiser4-adjust-to-the-new-aops-fixup.patch
reiser4-remove-simple_prepare_write-usage.patch
reiser4-remove-simple_prepare_write-usage-checkpatch-fixes.patch
fs-symlink-write_begin-allocation-context-fix-reiser4-fix.patch
reiser4-handling-error-returned-by-d_obtain_alias-fixup.patch
reiser4-update-names-of-quota-methods.patch
reiser4-use-set_page_dirty_notag.patch
fs-reiser4-contextc-current_is_pdflush-got-removed.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
slab-leaks3-default-y.patch
put_bh-debug.patch
add-debugging-aid-for-memory-initialisation-problems.patch
keep-track-of-network-interface-renaming.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
getblk-handle-2tb-devices.patch
getblk-handle-2tb-devices-fix.patch
undeprecate-pci_find_device.patch
notify_change-callers-must-hold-i_mutex.patch

Re: mmotm 2009-06-30-12-50 uploaded

[Valdis.Kletnieks]

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

On Tue, 30 Jun 2009 12:51:30 PDT, akpm@linux-foundation.org said:
> The mm-of-the-moment snapshot 2009-06-30-12-50 has been uploaded to

This dies with quilt 0.44, thusly:

Applying patch procfs-provide-stack-information-for-threads-v08.patch
can't find file to patch at input line 20
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|From: Stefani Seibold <stefani@seibold.net>
|
|A patch to give a better overview of the userland application stack usage,
|especially for embedded linux.
|
|Currently you are only able to dump the main process/thread stack usage
|which is showed in /proc/pid/status by the "VmStk" Value.  But you get no
|information about the consumed stack memory of the the threads.
|
|There is an enhancement in the /proc/<pid>/{task/*,}/*maps and which marks
|the vm mapping where the thread stack pointer reside with "[thread stack
|xxxxxxxx]".  xxxxxxxx is the maximum size of stack.  This is a value
|information, because libpthread doesn't set the start of the stack to the
|top of the mapped area, depending of the pthread usage.
|
|A sample output of /proc/<pid>/task/<tid>/maps looks like:
|
|08048000-08049000 r-xp 00000000 03:00 8312       /opt/z
|08049000-0804a000 rw-p 00001000 03:00 8312       /opt/z
--------------------------
No file to patch.  Skipping patch.
patch: **** /tmp/poPjWncl : No such file or directory
Patch procfs-provide-stack-information-for-threads-v08.patch does not apply (enforce with -f)

Yowza.  Not sure what makes it think there's an issue at line 20, looks to
*me* like the actual patch starts on line 77.

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

Re: mmotm 2009-06-30-12-50 uploaded

[Randy Dunlap]

Valdis.Kletnieks@vt.edu wrote:
> On Tue, 30 Jun 2009 12:51:30 PDT, akpm@linux-foundation.org said:
>> The mm-of-the-moment snapshot 2009-06-30-12-50 has been uploaded to
> 
> This dies with quilt 0.44, thusly:
> 
> Applying patch procfs-provide-stack-information-for-threads-v08.patch
> can't find file to patch at input line 20
> Perhaps you used the wrong -p or --strip option?
> The text leading up to this was:
> --------------------------
> |From: Stefani Seibold <stefani@seibold.net>
> |
> |A patch to give a better overview of the userland application stack usage,
> |especially for embedded linux.
> |
> |Currently you are only able to dump the main process/thread stack usage
> |which is showed in /proc/pid/status by the "VmStk" Value.  But you get no
> |information about the consumed stack memory of the the threads.
> |
> |There is an enhancement in the /proc/<pid>/{task/*,}/*maps and which marks
> |the vm mapping where the thread stack pointer reside with "[thread stack
> |xxxxxxxx]".  xxxxxxxx is the maximum size of stack.  This is a value
> |information, because libpthread doesn't set the start of the stack to the
> |top of the mapped area, depending of the pthread usage.
> |
> |A sample output of /proc/<pid>/task/<tid>/maps looks like:
> |
> |08048000-08049000 r-xp 00000000 03:00 8312       /opt/z
> |08049000-0804a000 rw-p 00001000 03:00 8312       /opt/z
> --------------------------
> No file to patch.  Skipping patch.
> patch: **** /tmp/poPjWncl : No such file or directory
> Patch procfs-provide-stack-information-for-threads-v08.patch does not apply (enforce with -f)
> 
> Yowza.  Not sure what makes it think there's an issue at line 20, looks to
> *me* like the actual patch starts on line 77.

patch version problem?  I'm not seeing an error there.

Applying patch procfs-provide-stack-information-for-threads-v08.patch
patching file Documentation/filesystems/proc.txt
patching file fs/exec.c
Hunk #1 succeeded at 1340 (^[[33moffset -4 lines^[[00m).
patching file fs/proc/array.c
patching file fs/proc/task_mmu.c
patching file include/linux/sched.h
Hunk #1 succeeded at 1486 (^[[33moffset 26 lines^[[00m).
patching file kernel/fork.c
Hunk #1 succeeded at 1094 (^[[33moffset -1 lines^[[00m).


> patch --version
patch 2.5.9

-- 
~Randy
LPC 2009, Sept. 23-25, Portland, Oregon
http://linuxplumbersconf.org/2009/

Re: mmotm 2009-06-30-12-50 uploaded

[Valdis.Kletnieks]

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

On Tue, 30 Jun 2009 16:15:52 EDT, Valdis.Kletnieks@vt.edu said:
>
> Yowza.  Not sure what makes it think there's an issue at line 20, looks to
> *me* like the actual patch starts on line 77.

>From the patch:

A sample output of /proc/<pid>/task/<tid>/maps looks like:

08048000-08049000 r-xp 00000000 03:00 8312       /opt/z
08049000-0804a000 rw-p 00001000 03:00 8312       /opt/z
0804a000-0806b000 rw-p 00000000 00:00 0          [heap]
a7d12000-a7d13000 ---p 00000000 00:00 0
a7d13000-a7f13000 rw-p 00000000 00:00 0          [thread stack: 001ff4b4]
a7f13000-a7f14000 ---p 00000000 00:00 0

The line with '[heap]' gives it the indigestion - deleting that line and
we get:

% quilt push procfs-provide-stack-information-for-threads-v08.patch
Applying patch procfs-provide-stack-information-for-threads-v08.patch
patching file Documentation/filesystems/proc.txt
patching file fs/exec.c
Hunk #1 succeeded at 1340 (offset -4 lines).
patching file fs/proc/array.c
patching file fs/proc/task_mmu.c
patching file include/linux/sched.h
Hunk #1 succeeded at 1486 (offset 26 lines).
patching file kernel/fork.c
Hunk #1 succeeded at 1094 (offset -1 lines).

Now at patch procfs-provide-stack-information-for-threads-v08.patch

Not sure why that line did it.  Repeated truncate-and-try shows that if the
line contained just the 4 chars '0804', it applied fine, but '0804a' dies.

<Cue twilight zone theme>,


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

Re: mmotm 2009-06-30-12-50 uploaded

[Andrew Morton]

On Tue, 30 Jun 2009 13:19:48 -0700
Randy Dunlap <randy.dunlap@oracle.com> wrote:

> Valdis.Kletnieks@vt.edu wrote:

(I wasn't cc'ed?)

> > On Tue, 30 Jun 2009 12:51:30 PDT, akpm@linux-foundation.org said:
> >> The mm-of-the-moment snapshot 2009-06-30-12-50 has been uploaded to
> > 
> > This dies with quilt 0.44, thusly:
> > 
> > Applying patch procfs-provide-stack-information-for-threads-v08.patch
> > can't find file to patch at input line 20
> > Perhaps you used the wrong -p or --strip option?
> > The text leading up to this was:
> > --------------------------
> > |From: Stefani Seibold <stefani@seibold.net>
> > |
> > |A patch to give a better overview of the userland application stack usage,
> > |especially for embedded linux.
> > |
> > |Currently you are only able to dump the main process/thread stack usage
> > |which is showed in /proc/pid/status by the "VmStk" Value.  But you get no
> > |information about the consumed stack memory of the the threads.
> > |
> > |There is an enhancement in the /proc/<pid>/{task/*,}/*maps and which marks
> > |the vm mapping where the thread stack pointer reside with "[thread stack
> > |xxxxxxxx]".  xxxxxxxx is the maximum size of stack.  This is a value
> > |information, because libpthread doesn't set the start of the stack to the
> > |top of the mapped area, depending of the pthread usage.
> > |
> > |A sample output of /proc/<pid>/task/<tid>/maps looks like:
> > |
> > |08048000-08049000 r-xp 00000000 03:00 8312       /opt/z
> > |08049000-0804a000 rw-p 00001000 03:00 8312       /opt/z

The next line is:

a7d12000-a7d13000 ---p 00000000 00:00 0

And I bet stupid patch(1) saw that "---" and decided that it was the
start of a diff.

Try adding `-u' to the patch(1) command?

I use something like

	patch -u -f -p1 --fuzz=1 -s

Re: mmotm 2009-06-30-12-50 uploaded

[Andrew Morton]

On Tue, 30 Jun 2009 16:27:01 -0400
Valdis.Kletnieks@vt.edu wrote:

> Not sure why that line did it.  Repeated truncate-and-try shows that if the
> line contained just the 4 chars '0804', it applied fine, but '0804a' dies.

That's patch(1) thinking it's a regular diff:

akpm:/usr/src/25> diff Makefile Makefile~linux-next
4c4
< EXTRAVERSION = -rc1-mm1
---
> EXTRAVERSION = -rc1
142a143,144
> TOPDIR                := $(srctree)
> # FIXME - TOPDIR is obsolete, use srctree/objtree
149c151
< export srctree objtree VPATH
---
> export srctree objtree VPATH TOPDIR
328c330
< LDFLAGS_MODULE  = -T $(srctree)/scripts/module-common.lds
---
> LDFLAGS_MODULE  =
345,346c347
<                  -Werror-implicit-function-declaration \
<                  -Wno-format-security
---
>                  -Werror-implicit-function-declaration


So the "0804a" means "at line 804, start appending stuff", or something
like that.

Use -u.

Re: mmotm 2009-06-30-12-50 uploaded

[Randy Dunlap]

Andrew Morton wrote:
> On Tue, 30 Jun 2009 13:19:48 -0700
> Randy Dunlap <randy.dunlap@oracle.com> wrote:
> 
>> Valdis.Kletnieks@vt.edu wrote:
> 
> (I wasn't cc'ed?)

mm-commits but not you... (from Valdis)

>>> On Tue, 30 Jun 2009 12:51:30 PDT, akpm@linux-foundation.org said:
>>>> The mm-of-the-moment snapshot 2009-06-30-12-50 has been uploaded to
>>> This dies with quilt 0.44, thusly:
>>>
>>> Applying patch procfs-provide-stack-information-for-threads-v08.patch
>>> can't find file to patch at input line 20
>>> Perhaps you used the wrong -p or --strip option?
>>> The text leading up to this was:
>>> --------------------------
>>> |From: Stefani Seibold <stefani@seibold.net>
>>> |
>>> |A patch to give a better overview of the userland application stack usage,
>>> |especially for embedded linux.
>>> |
>>> |Currently you are only able to dump the main process/thread stack usage
>>> |which is showed in /proc/pid/status by the "VmStk" Value.  But you get no
>>> |information about the consumed stack memory of the the threads.
>>> |
>>> |There is an enhancement in the /proc/<pid>/{task/*,}/*maps and which marks
>>> |the vm mapping where the thread stack pointer reside with "[thread stack
>>> |xxxxxxxx]".  xxxxxxxx is the maximum size of stack.  This is a value
>>> |information, because libpthread doesn't set the start of the stack to the
>>> |top of the mapped area, depending of the pthread usage.
>>> |
>>> |A sample output of /proc/<pid>/task/<tid>/maps looks like:
>>> |
>>> |08048000-08049000 r-xp 00000000 03:00 8312       /opt/z
>>> |08049000-0804a000 rw-p 00001000 03:00 8312       /opt/z
> 
> The next line is:
> 
> a7d12000-a7d13000 ---p 00000000 00:00 0
> 
> And I bet stupid patch(1) saw that "---" and decided that it was the
> start of a diff.
> 
> Try adding `-u' to the patch(1) command?
> 
> I use something like
> 
> 	patch -u -f -p1 --fuzz=1 -s

Yes, my .quiltrc file contains -u for QUILT_PATCH_OPTS.

-- 
~Randy
LPC 2009, Sept. 23-25, Portland, Oregon
http://linuxplumbersconf.org/2009/

[PATCH mmotm] hwmon: fix lis3-spi for CONFIG_PM=n

[Randy Dunlap]

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

Fix build error when CONFIG_PM=n:

The suspend & resume function names are incorrect for the
PM=n case.

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
 drivers/hwmon/lis3lv02d_spi.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- mmotm-2009-0630-1250.orig/drivers/hwmon/lis3lv02d_spi.c
+++ mmotm-2009-0630-1250/drivers/hwmon/lis3lv02d_spi.c
@@ -108,8 +108,8 @@ static int lis3lv02d_spi_resume(struct s
 }
 
 #else
-#define lis3_spi_suspend	NULL
-#define lis3_spi_resume		NULL
+#define lis3lv02d_spi_suspend	NULL
+#define lis3lv02d_spi_resume	NULL
 #endif
 
 static struct spi_driver lis302dl_spi_driver = {


---
~Randy
LPC 2009, Sept. 23-25, Portland, Oregon
http://linuxplumbersconf.org/2009/

Re: mmotm 2009-06-30-12-50 uploaded

[KOSAKI Motohiro]

just dumb question.

> So the "0804a" means "at line 804, start appending stuff", or something
> like that.
> 
> Use -u.

afaik, 99% quilt user use -u. so, Why quilt don't turn on -u by default?

Re: mmotm 2009-06-30-12-50 uploaded

[Valdis.Kletnieks]

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

On Tue, 30 Jun 2009 13:38:16 PDT, Andrew Morton said:
> On Tue, 30 Jun 2009 16:27:01 -0400
> Valdis.Kletnieks@vt.edu wrote:
> 
> > Not sure why that line did it.  Repeated truncate-and-try shows that if the
> > line contained just the 4 chars '0804', it applied fine, but '0804a' dies.
> 
> That's patch(1) thinking it's a regular diff:
> 
> akpm:/usr/src/25> diff Makefile Makefile~linux-next
> 4c4
...
> So the "0804a" means "at line 804, start appending stuff", or something
> like that.
> 
> Use -u.

Yep, that was it, thanks.  Added to .quiltrc.

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

Re: mmotm 2009-06-30-12-50 uploaded

[Valdis.Kletnieks]

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

On Tue, 30 Jun 2009 12:51:30 PDT, akpm@linux-foundation.org said:
> The mm-of-the-moment snapshot 2009-06-30-12-50 has been uploaded to
> 
>    http://userweb.kernel.org/~akpm/mmotm/

This whinges at me during early startup:

[    0.654180] ACPI: Video Device [VID] (multi-head: yes  rom: no  post: no)
[    0.655101] ACPI: SSDT 000000007fe82138 00244 (v01  PmRef  Cpu0Ist 00003000 INTL 20050624)
[    0.655547] power_supply AC: prop ONLINE=1
[    0.655984] ACPI: SSDT 000000007fe81eed 001C6 (v01  PmRef  Cpu0Cst 00003001 INTL 20050624)
[    0.657061] ------------[ cut here ]------------
[    0.657296] WARNING: at kernel/lockdep.c:2143 trace_hardirqs_on_caller+0xc7/0x145()
[    0.657664] Hardware name: Latitude D820
[    0.657933] Modules linked in:
[    0.658056] Pid: 0, comm: swapper Not tainted 2.6.31-rc1-mmotm0630 #1
[    0.658056] Call Trace:
[    0.658056]  <IRQ>  [<ffffffff8103ef3d>] warn_slowpath_common+0x77/0x8f
[    0.658056]  [<ffffffff8120a76a>] ? acpi_processor_get_throttling_fadt+0x81/0x8c
[    0.658056]  [<ffffffff8103ef64>] warn_slowpath_null+0xf/0x11
[    0.658056]  [<ffffffff81065ba9>] trace_hardirqs_on_caller+0xc7/0x145
[    0.658056]  [<ffffffff81065c34>] trace_hardirqs_on+0xd/0xf
[    0.658056]  [<ffffffff8120a76a>] acpi_processor_get_throttling_fadt+0x81/0x8c
[    0.658056]  [<ffffffff8120a3c4>] get_throttling+0x18/0x1f
[    0.658056]  [<ffffffff8106dbbf>] generic_smp_call_function_single_interrupt+0x73/0x95
[    0.658056]  [<ffffffff8101e9bf>] smp_call_function_single_interrupt+0x13/0x23
[    0.658056]  [<ffffffff8100c093>] call_function_single_interrupt+0x13/0x20
[    0.658056]  <EOI>  [<ffffffff81012a52>] ? mwait_idle+0x7a/0x95
[    0.658056]  [<ffffffff81012a49>] ? mwait_idle+0x71/0x95
[    0.658056]  [<ffffffff814a8d49>] ? atomic_notifier_call_chain+0xf/0x11
[    0.658056]  [<ffffffff8100a4aa>] ? enter_idle+0x20/0x22
[    0.658056]  [<ffffffff8100a521>] ? cpu_idle+0x75/0xfd
[    0.658056]  [<ffffffff8148bc41>] ? rest_init+0x75/0x77
[    0.658056]  [<ffffffff81801c53>] ? start_kernel+0x36e/0x379
[    0.658056]  [<ffffffff8180129c>] ? x86_64_start_reservations+0xac/0xb0
[    0.658056]  [<ffffffff81801384>] ? x86_64_start_kernel+0xe4/0xeb
[    0.658056] ---[ end trace a7919e7f17c0a725 ]---
[    0.803166] ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
[    0.814078] processor LNXCPU:00: registered as cooling_device0
[    0.825244] ACPI: Processor [CPU0] (supports 8 throttling states)



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

Re: mmotm 2009-06-30-12-50 uploaded

[Andrew Morton]

On Thu, 02 Jul 2009 15:16:03 -0400
Valdis.Kletnieks@vt.edu wrote:

> On Tue, 30 Jun 2009 12:51:30 PDT, akpm@linux-foundation.org said:
> > The mm-of-the-moment snapshot 2009-06-30-12-50 has been uploaded to
> > 
> >    http://userweb.kernel.org/~akpm/mmotm/
> 
> This whinges at me during early startup:
> 
> [    0.654180] ACPI: Video Device [VID] (multi-head: yes  rom: no  post: no)
> [    0.655101] ACPI: SSDT 000000007fe82138 00244 (v01  PmRef  Cpu0Ist 00003000 INTL 20050624)
> [    0.655547] power_supply AC: prop ONLINE=1
> [    0.655984] ACPI: SSDT 000000007fe81eed 001C6 (v01  PmRef  Cpu0Cst 00003001 INTL 20050624)
> [    0.657061] ------------[ cut here ]------------
> [    0.657296] WARNING: at kernel/lockdep.c:2143 trace_hardirqs_on_caller+0xc7/0x145()
> [    0.657664] Hardware name: Latitude D820
> [    0.657933] Modules linked in:
> [    0.658056] Pid: 0, comm: swapper Not tainted 2.6.31-rc1-mmotm0630 #1
> [    0.658056] Call Trace:
> [    0.658056]  <IRQ>  [<ffffffff8103ef3d>] warn_slowpath_common+0x77/0x8f
> [    0.658056]  [<ffffffff8120a76a>] ? acpi_processor_get_throttling_fadt+0x81/0x8c
> [    0.658056]  [<ffffffff8103ef64>] warn_slowpath_null+0xf/0x11
> [    0.658056]  [<ffffffff81065ba9>] trace_hardirqs_on_caller+0xc7/0x145
> [    0.658056]  [<ffffffff81065c34>] trace_hardirqs_on+0xd/0xf
> [    0.658056]  [<ffffffff8120a76a>] acpi_processor_get_throttling_fadt+0x81/0x8c
> [    0.658056]  [<ffffffff8120a3c4>] get_throttling+0x18/0x1f
> [    0.658056]  [<ffffffff8106dbbf>] generic_smp_call_function_single_interrupt+0x73/0x95
> [    0.658056]  [<ffffffff8101e9bf>] smp_call_function_single_interrupt+0x13/0x23
> [    0.658056]  [<ffffffff8100c093>] call_function_single_interrupt+0x13/0x20
> [    0.658056]  <EOI>  [<ffffffff81012a52>] ? mwait_idle+0x7a/0x95
> [    0.658056]  [<ffffffff81012a49>] ? mwait_idle+0x71/0x95
> [    0.658056]  [<ffffffff814a8d49>] ? atomic_notifier_call_chain+0xf/0x11
> [    0.658056]  [<ffffffff8100a4aa>] ? enter_idle+0x20/0x22
> [    0.658056]  [<ffffffff8100a521>] ? cpu_idle+0x75/0xfd
> [    0.658056]  [<ffffffff8148bc41>] ? rest_init+0x75/0x77
> [    0.658056]  [<ffffffff81801c53>] ? start_kernel+0x36e/0x379
> [    0.658056]  [<ffffffff8180129c>] ? x86_64_start_reservations+0xac/0xb0
> [    0.658056]  [<ffffffff81801384>] ? x86_64_start_kernel+0xe4/0xeb
> [    0.658056] ---[ end trace a7919e7f17c0a725 ]---
> [    0.803166] ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
> [    0.814078] processor LNXCPU:00: registered as cooling_device0
> [    0.825244] ACPI: Processor [CPU0] (supports 8 throttling states)

apart from having a crappy title, linux-next's

: commit f29876421ec11f7d66f3d982219ef3af9bcccf32
: Author: Rusty Russell <rusty@rustcorp.com.au>
: AuthorDate: Wed Jul 1 12:37:19 2009 +1000
: Commit: Stephen Rothwell <sfr@canb.auug.org.au>
: CommitDate: Wed Jul 1 12:37:19 2009 +1000
:
: misc:work_on_cpu-acpi
:

causes get_throttling() to newly be called from an IPI, and lockdep doesn't
like irq-disabled interrupt handlers doing local_irq_enable().


If we rely upon these functions only ever being called from
smp_call_function_single(), and if smp_call_function_single() is
correctly implemented, we should be able to do this:

--- a/drivers/acpi/processor_throttling.c~a
+++ a/drivers/acpi/processor_throttling.c
@@ -616,6 +616,8 @@ static int acpi_processor_get_throttling
 	u32 duty_mask = 0;
 	u32 duty_value = 0;
 
+	WARN_ON_ONCE(!irqs_disabled());
+
 	if (!pr)
 		return -EINVAL;
 
@@ -628,8 +630,6 @@ static int acpi_processor_get_throttling
 
 	duty_mask <<= pr->throttling.duty_offset;
 
-	local_irq_disable();
-
 	value = inl(pr->throttling.address);
 
 	/*
@@ -646,8 +646,6 @@ static int acpi_processor_get_throttling
 
 	pr->throttling.state = state;
 
-	local_irq_enable();
-
 	ACPI_DEBUG_PRINT((ACPI_DB_INFO,
 			  "Throttling state is T%d (%d%% throttling applied)\n",
 			  state, pr->throttling.states[state].performance));
@@ -919,6 +917,8 @@ static int acpi_processor_set_throttling
 	u32 duty_mask = 0;
 	u32 duty_value = 0;
 
+	WARN_ON_ONCE(!irqs_disabled());
+
 	if (!pr)
 		return -EINVAL;
 
@@ -948,8 +948,6 @@ static int acpi_processor_set_throttling
 		duty_mask = ~duty_mask;
 	}
 
-	local_irq_disable();
-
 	/*
 	 * Disable throttling by writing a 0 to bit 4.  Note that we must
 	 * turn it off before you can change the duty_value.
@@ -975,8 +973,6 @@ static int acpi_processor_set_throttling
 
 	pr->throttling.state = state;
 
-	local_irq_enable();
-
 	ACPI_DEBUG_PRINT((ACPI_DB_INFO,
 			  "Throttling state set to T%d (%d%%)\n", state,
 			  (pr->throttling.states[state].performance ? pr->
_

Re: mmotm 2009-06-30-12-50 uploaded

[Valdis.Kletnieks]

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

On Thu, 02 Jul 2009 12:47:26 PDT, Andrew Morton said:

> apart from having a crappy title, linux-next's
> 
> : commit f29876421ec11f7d66f3d982219ef3af9bcccf32
> : Author: Rusty Russell <rusty@rustcorp.com.au>
> : AuthorDate: Wed Jul 1 12:37:19 2009 +1000
> : Commit: Stephen Rothwell <sfr@canb.auug.org.au>
> : CommitDate: Wed Jul 1 12:37:19 2009 +1000
> :
> : misc:work_on_cpu-acpi
> :
> 
> causes get_throttling() to newly be called from an IPI, and lockdep doesn't
> like irq-disabled interrupt handlers doing local_irq_enable().
> 
> 
> If we rely upon these functions only ever being called from
> smp_call_function_single(), and if smp_call_function_single() is
> correctly implemented, we should be able to do this:

I'll take a leap of faith on the "correctly implemented" part.  However,
I admit I'm probably going to wait till Len or somebody agrees on the
"only calledf from function_single()" part being correct before test-driving
the patch...

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

mmotm 2009-06-30-12-50 dies during early boot

[Valdis.Kletnieks]

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

On Tue, 30 Jun 2009 12:51:30 PDT, akpm@linux-foundation.org said:
> The mm-of-the-moment snapshot 2009-06-30-12-50 has been uploaded to
> 
>    http://userweb.kernel.org/~akpm/mmotm/

(Would have gotten this out the door earlier, but I got confused about what
that 'G' in the 'Tainted' meant, and put off reporting till I could reproduce
it without the NVidia driver. Turns out it was untainted except for the
warning I already reported...)

Dies fairly early during boot, somewhere in the first few lines of rc.sysinit.

It *looks* like it dies in this call:

	wake_up_interruptible(&current->real_parent->signal->wait_chldexit);

in selinux_bprm_committed_creds().  Not sure which part of that is the duff
pointer, though...

[   16.829082] hub 1-2:1.0: hub_suspend
[   16.848165] usb 1-2: unlink qh256-0001/ffff88007e053140 start 1 [1/0 us]
[   16.867813] usb 1-2: usb auto-suspend
[   17.827106] cat used greatest stack depth: 4280 bytes left
[   17.846392] Oops: 0000 [#1] PREEMPT SMP 
[   17.847007] last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda2/dev
[   17.847007] CPU 0 
[   17.847007] Modules linked in:
[   17.847007] Pid: 887, comm: mount Tainted: G        W  2.6.31-rc1-mmotm0630 #1 Latitude D820                   
[   17.847007] RIP: 0010:[<ffffffff81040873>]  [<ffffffff81040873>] child_wait_callback+0x3d/0x5f
[   17.847007] RSP: 0018:ffff88007f051c28  EFLAGS: 00010046
[   17.847007] RAX: 000000000000000e RBX: 0000000000000001 RCX: 0000000000000000
[   17.847007] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff88007eb9bf20
[   17.847007] RBP: ffff88007f051c28 R08: 0000000000000000 R09: 0000000000000001
[   17.847007] R10: ffff88007f051c68 R11: ffff88007f051c68 R12: 0000000000000001
[   17.847007] R13: ffff88007f9965e0 R14: 0000000000000000 R15: 0000000000000000
[   17.847007] FS:  00007fa8f6c646f0(0000) GS:ffff880002121000(0000) knlGS:0000000000000000
[   17.847007] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[   17.847007] CR2: 0000000000000270 CR3: 000000007fb3f000 CR4: 00000000000006f0
[   17.847007] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   17.847007] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[   17.847007] Process mount (pid: 887, threadinfo ffff88007f050000, task ffff88007eb96a80)
[   17.847007] Stack:
[   17.847007]  ffff88007f051c78 ffffffff8102df4a 0000000000000000 ffff88007f9965f8
[   17.847007] <0> ffff88007f051c78 ffff88007f9965c8 0000000000000282 ffff88007e3acbc0
[   17.847007] <0> ffff88007f051f58 00007fd172b0faf0 ffff88007f051cb8 ffffffff810305d8
[   17.847007] Call Trace:
[   17.847007]  [<ffffffff8102df4a>] __wake_up_common+0x49/0x7f
[   17.847007]  [<ffffffff810305d8>] __wake_up+0x34/0x48
[   17.847007]  [<ffffffff81176a19>] selinux_bprm_committed_creds+0x11d/0x132
[   17.847007]  [<ffffffff8105be4d>] ? commit_creds+0x1d5/0x1df
[   17.847007]  [<ffffffff8116dc46>] security_bprm_committed_creds+0x11/0x13
[   17.847007]  [<ffffffff810d5420>] install_exec_creds+0x30/0x35
[   17.847007]  [<ffffffff81110de5>] load_elf_binary+0x10d1/0x1990
[   17.847007]  [<ffffffff814a8bc0>] ? sub_preempt_count+0x35/0x48
[   17.847007]  [<ffffffff810d5101>] search_binary_handler+0xbd/0x2cc
[   17.847007]  [<ffffffff8110fd14>] ? load_elf_binary+0x0/0x1990
[   17.847007]  [<ffffffff810d69e8>] do_execve+0x26e/0x3c2
[   17.847007]  [<ffffffff81009b15>] sys_execve+0x5b/0x78
[   17.847007]  [<ffffffff8100b7ca>] stub_execve+0x6a/0xc0
[   17.847007] Code: 81 00 03 00 00 eb 14 89 c0 48 6b c0 18 48 03 81 c0 02 00 00 48 8b 80 00 03 00 00 48 3b 47 e0 75 21 8b 47 dc 41 89 c0 41 c1 e8 1f <83> b9 70 02 00 00 11 41 0f 95 c1 45 38 c1 74 0b a9 00 00 00 40 
[   17.847007] RIP  [<ffffffff81040873>] child_wait_callback+0x3d/0x5f
[   17.847007]  RSP <ffff88007f051c28>
[   17.847007] CR2: 0000000000000270
[   17.847007] ---[ end trace a7919e7f17c0a727 ]---
[   17.847007] note: mount[887] exited with preempt_count 2
[   27.655913] usb 1-8.3: khubd timed out on ep0in len=0/64
[   27.655958] BUG: scheduling while atomic: mount/887/0x10000003
[   27.655960] INFO: lockdep is turned off.
[   27.655962] Modules linked in:
[   27.655965] Pid: 887, comm: mount Tainted: G      D W  2.6.31-rc1-mmotm0630 #1
[   27.655967] Call Trace:
[   27.655973]  [<ffffffff81065361>] ? __debug_show_held_locks+0x1b/0x24
[   27.655978]  [<ffffffff81034afb>] __schedule_bug+0x6d/0x72
[   27.655982]  [<ffffffff814a339e>] schedule+0xf0/0x934
[   27.655987]  [<ffffffff810e73ef>] ? mntput_no_expire+0x24/0x145
[   27.655991]  [<ffffffff810cb61d>] ? __cache_free+0x45/0xf1
[   27.655996]  [<ffffffff81035abf>] __cond_resched+0x24/0x39
[   27.655999]  [<ffffffff814a3dad>] _cond_resched+0x2d/0x38
[   27.656017]  [<ffffffff81040ca0>] put_files_struct+0x6c/0xbe
[   27.656020]  [<ffffffff81040d38>] exit_files+0x46/0x4f
[   27.656024]  [<ffffffff81042a58>] do_exit+0x3a6/0x97d
[   27.656028]  [<ffffffff814a732e>] oops_end+0x89/0x8e
[   27.656032]  [<ffffffff81025a6c>] no_context+0x1f1/0x200
[   27.656036]  [<ffffffff81025c21>] __bad_area_nosemaphore+0x1a6/0x1ef
[   27.656040]  [<ffffffff81065b01>] ? trace_hardirqs_on_caller+0x1f/0x145
[   27.656044]  [<ffffffff81064e9f>] ? trace_hardirqs_off_caller+0x1f/0xa2
[   27.656047]  [<ffffffff81064f2f>] ? trace_hardirqs_off+0xd/0xf
[   27.656051]  [<ffffffff81064e9f>] ? trace_hardirqs_off_caller+0x1f/0xa2
[   27.656055]  [<ffffffff81034117>] ? get_parent_ip+0x11/0x41
[   27.656058]  [<ffffffff81025c78>] bad_area_nosemaphore+0xe/0x10
[   27.656062]  [<ffffffff814a8913>] do_page_fault+0x204/0x47c
[   27.656066]  [<ffffffff814a5739>] ? trace_hardirqs_off_thunk+0x3a/0x3c
[   27.656070]  [<ffffffff814a674f>] page_fault+0x1f/0x30
[   27.656074]  [<ffffffff81040873>] ? child_wait_callback+0x3d/0x5f
[   27.656079]  [<ffffffff811bca7e>] ? _raw_spin_lock+0xe3/0x196
[   27.656083]  [<ffffffff8102df4a>] __wake_up_common+0x49/0x7f
[   27.656087]  [<ffffffff810305d8>] __wake_up+0x34/0x48
[   27.656091]  [<ffffffff81176a19>] selinux_bprm_committed_creds+0x11d/0x132
[   27.656095]  [<ffffffff8105be4d>] ? commit_creds+0x1d5/0x1df
[   27.656098]  [<ffffffff8116dc46>] security_bprm_committed_creds+0x11/0x13
[   27.656102]  [<ffffffff810d5420>] install_exec_creds+0x30/0x35
[   27.656106]  [<ffffffff81110de5>] load_elf_binary+0x10d1/0x1990
[   27.656111]  [<ffffffff814a8bc0>] ? sub_preempt_count+0x35/0x48
[   27.656114]  [<ffffffff810d5101>] search_binary_handler+0xbd/0x2cc
[   27.656118]  [<ffffffff8110fd14>] ? load_elf_binary+0x0/0x1990
[   27.656122]  [<ffffffff810d69e8>] do_execve+0x26e/0x3c2
[   27.656126]  [<ffffffff81009b15>] sys_execve+0x5b/0x78
[   27.656130]  [<ffffffff8100b7ca>] stub_execve+0x6a/0xc0
[   27.656157] mount used greatest stack depth: 3920 bytes left


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

Re: mmotm 2009-06-30-12-50 dies during early boot

[Andrew Morton]

On Thu, 02 Jul 2009 21:52:28 -0400 Valdis.Kletnieks@vt.edu wrote:

> On Tue, 30 Jun 2009 12:51:30 PDT, akpm@linux-foundation.org said:
> > The mm-of-the-moment snapshot 2009-06-30-12-50 has been uploaded to
> > 
> >    http://userweb.kernel.org/~akpm/mmotm/
> 
> (Would have gotten this out the door earlier, but I got confused about what
> that 'G' in the 'Tainted' meant, and put off reporting till I could reproduce
> it without the NVidia driver. Turns out it was untainted except for the
> warning I already reported...)
> 
> Dies fairly early during boot, somewhere in the first few lines of rc.sysinit.
> 
> It *looks* like it dies in this call:
> 
> 	wake_up_interruptible(&current->real_parent->signal->wait_chldexit);
> 
> in selinux_bprm_committed_creds().  Not sure which part of that is the duff
> pointer, though...
> 
> [   16.829082] hub 1-2:1.0: hub_suspend
> [   16.848165] usb 1-2: unlink qh256-0001/ffff88007e053140 start 1 [1/0 us]
> [   16.867813] usb 1-2: usb auto-suspend
> [   17.827106] cat used greatest stack depth: 4280 bytes left
> [   17.846392] Oops: 0000 [#1] PREEMPT SMP 
> [   17.847007] last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda2/dev
> [   17.847007] CPU 0 
> [   17.847007] Modules linked in:
> [   17.847007] Pid: 887, comm: mount Tainted: G        W  2.6.31-rc1-mmotm0630 #1 Latitude D820                   
> [   17.847007] RIP: 0010:[<ffffffff81040873>]  [<ffffffff81040873>] child_wait_callback+0x3d/0x5f
> [   17.847007] RSP: 0018:ffff88007f051c28  EFLAGS: 00010046
> [   17.847007] RAX: 000000000000000e RBX: 0000000000000001 RCX: 0000000000000000
> [   17.847007] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff88007eb9bf20
> [   17.847007] RBP: ffff88007f051c28 R08: 0000000000000000 R09: 0000000000000001
> [   17.847007] R10: ffff88007f051c68 R11: ffff88007f051c68 R12: 0000000000000001
> [   17.847007] R13: ffff88007f9965e0 R14: 0000000000000000 R15: 0000000000000000
> [   17.847007] FS:  00007fa8f6c646f0(0000) GS:ffff880002121000(0000) knlGS:0000000000000000
> [   17.847007] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [   17.847007] CR2: 0000000000000270 CR3: 000000007fb3f000 CR4: 00000000000006f0
> [   17.847007] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [   17.847007] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [   17.847007] Process mount (pid: 887, threadinfo ffff88007f050000, task ffff88007eb96a80)
> [   17.847007] Stack:
> [   17.847007]  ffff88007f051c78 ffffffff8102df4a 0000000000000000 ffff88007f9965f8
> [   17.847007] <0> ffff88007f051c78 ffff88007f9965c8 0000000000000282 ffff88007e3acbc0
> [   17.847007] <0> ffff88007f051f58 00007fd172b0faf0 ffff88007f051cb8 ffffffff810305d8
> [   17.847007] Call Trace:
> [   17.847007]  [<ffffffff8102df4a>] __wake_up_common+0x49/0x7f
> [   17.847007]  [<ffffffff810305d8>] __wake_up+0x34/0x48
> [   17.847007]  [<ffffffff81176a19>] selinux_bprm_committed_creds+0x11d/0x132
> [   17.847007]  [<ffffffff8105be4d>] ? commit_creds+0x1d5/0x1df
> [   17.847007]  [<ffffffff8116dc46>] security_bprm_committed_creds+0x11/0x13
> [   17.847007]  [<ffffffff810d5420>] install_exec_creds+0x30/0x35
> [   17.847007]  [<ffffffff81110de5>] load_elf_binary+0x10d1/0x1990
> [   17.847007]  [<ffffffff814a8bc0>] ? sub_preempt_count+0x35/0x48
> [   17.847007]  [<ffffffff810d5101>] search_binary_handler+0xbd/0x2cc
> [   17.847007]  [<ffffffff8110fd14>] ? load_elf_binary+0x0/0x1990
> [   17.847007]  [<ffffffff810d69e8>] do_execve+0x26e/0x3c2
> [   17.847007]  [<ffffffff81009b15>] sys_execve+0x5b/0x78
> [   17.847007]  [<ffffffff8100b7ca>] stub_execve+0x6a/0xc0
> [   17.847007] Code: 81 00 03 00 00 eb 14 89 c0 48 6b c0 18 48 03 81 c0 02 00 00 48 8b 80 00 03 00 00 48 3b 47 e0 75 21 8b 47 dc 41 89 c0 41 c1 e8 1f <83> b9 70 02 00 00 11 41 0f 95 c1 45 38 c1 74 0b a9 00 00 00 40 
> [   17.847007] RIP  [<ffffffff81040873>] child_wait_callback+0x3d/0x5f
> [   17.847007]  RSP <ffff88007f051c28>
> [   17.847007] CR2: 0000000000000270
> [   17.847007] ---[ end trace a7919e7f17c0a727 ]---

Well I'm not seeing any significant changes to security/selinux/hooks.c
in ages.  Perhaps this was a result of some Oleg changes, or some
credentials changes elsewhere.



Something's gone wrong with your oops output - it did't actually tell
us why it oopsed.  Perhaps because we've screwed up the printk facility
levels in there and at your loglevel some messages are being
suppressed.

Anyway, scripts/decodecode says

[ 17.847007] Code: 81 00 03 00 00 eb 14 89 c0 48 6b c0 18 48 03 81 c0 02 00 00 48 8b 80 00 03 00 00 48 3b 47 e0 75 21 8b 47 dc 41 89 c0 41 c1 e8 1f <83> b9 70 02 00 00 11 41 0f 95 c1 45 38 c1 74 0b a9 00 00 00 40
All code
========
   0:	81 00 03 00 00 eb    	addl   $0xeb000003,(%rax)
   6:	14 89                	adc    $0x89,%al
   8:	c0 48 6b c0          	rorb   $0xc0,0x6b(%rax)
   c:	18 48 03             	sbb    %cl,0x3(%rax)
   f:	81 c0 02 00 00 48    	add    $0x48000002,%eax
  15:	8b 80 00 03 00 00    	mov    0x300(%rax),%eax
  1b:	48 3b 47 e0          	cmp    -0x20(%rdi),%rax
  1f:	75 21                	jne    0x42
  21:	8b 47 dc             	mov    -0x24(%rdi),%eax
  24:	41 89 c0             	mov    %eax,%r8d
  27:	41 c1 e8 1f          	shr    $0x1f,%r8d
  2b:*	83 b9 70 02 00 00 11 	cmpl   $0x11,0x270(%rcx)     <-- trapping instruction
  32:	41 0f 95 c1          	setne  %r9b
  36:	45 38 c1             	cmp    %r8b,%r9b
  39:	74 0b                	je     0x46
  3b:	a9 00 00 00 40       	test   $0x40000000,%eax

Code starting with the faulting instruction
===========================================
   0:	83 b9 70 02 00 00 11 	cmpl   $0x11,0x270(%rcx)
   7:	41 0f 95 c1          	setne  %r9b
   b:	45 38 c1             	cmp    %r8b,%r9b
   e:	74 0b                	je     0x1b
  10:	a9 00 00 00 40       	test   $0x40000000,%eax


and your %rcx is zero, so it's a null-pointer deref.

Let me see if I can do another mmotm - perhaps we magically fixed it.

Re: mmotm 2009-06-30-12-50 dies during early boot

[Oleg Nesterov]

On 07/02, Andrew Morton wrote:
>
> On Thu, 02 Jul 2009 21:52:28 -0400 Valdis.Kletnieks@vt.edu wrote:
> 
> > On Tue, 30 Jun 2009 12:51:30 PDT, akpm@linux-foundation.org said:
> > > The mm-of-the-moment snapshot 2009-06-30-12-50 has been uploaded to
> > > 
> > >    http://userweb.kernel.org/~akpm/mmotm/
> > 
> > (Would have gotten this out the door earlier, but I got confused about what
> > that 'G' in the 'Tainted' meant, and put off reporting till I could reproduce
> > it without the NVidia driver. Turns out it was untainted except for the
> > warning I already reported...)
> > 
> > Dies fairly early during boot, somewhere in the first few lines of rc.sysinit.
> > 
> > It *looks* like it dies in this call:
> > 
> > 	wake_up_interruptible(&current->real_parent->signal->wait_chldexit);

Thanks! I'll send the patch soon.

selinux_commited_creds() should use __wake_up_parent(), it should not play
with ->wait_cldexit directly.


I wanted to fix this before,  but __wake_up_parent() was not exported.
And now I forgot to do this when added child_wait_callback().

My fault.

Oleg.

[PATCH] selinux_bprm_committed_creds: use __wake_up_parent()

[Oleg Nesterov]

(depends on ptrace-__ptrace_detach-do-__wake_up_parent-if-we-reap-the-tracee.patch
 which exports __wake_up_parent)

Spotted by Valdis.Kletnieks@vt.edu.

selinux_bprm_committed_creds() should not play with ->wait_chldexit, now
that __wake_up_parent() is exported change the code to use this helper.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>

--- WAIT/security/selinux/hooks.c~SEL_WAKE_PARENT	2009-06-16 17:01:42.000000000 +0200
+++ WAIT/security/selinux/hooks.c	2009-07-03 11:15:08.000000000 +0200
@@ -2404,7 +2404,7 @@ static void selinux_bprm_committed_creds
 	/* Wake up the parent if it is waiting so that it can recheck
 	 * wait permission to the new task SID. */
 	read_lock(&tasklist_lock);
-	wake_up_interruptible(&current->real_parent->signal->wait_chldexit);
+	__wake_up_parent(current, current->real_parent);
 	read_unlock(&tasklist_lock);
 }
 

Re: [PATCH] selinux_bprm_committed_creds: use __wake_up_parent()

[James Morris]

On Fri, 3 Jul 2009, Oleg Nesterov wrote:

> (depends on ptrace-__ptrace_detach-do-__wake_up_parent-if-we-reap-the-tracee.patch
>  which exports __wake_up_parent)
> 
> Spotted by Valdis.Kletnieks@vt.edu.
> 
> selinux_bprm_committed_creds() should not play with ->wait_chldexit, now
> that __wake_up_parent() is exported change the code to use this helper.
> 
> Signed-off-by: Oleg Nesterov <oleg@redhat.com>


Acked-by: James Morris <jmorris@namei.org>

> 
> --- WAIT/security/selinux/hooks.c~SEL_WAKE_PARENT	2009-06-16 17:01:42.000000000 +0200
> +++ WAIT/security/selinux/hooks.c	2009-07-03 11:15:08.000000000 +0200
> @@ -2404,7 +2404,7 @@ static void selinux_bprm_committed_creds
>  	/* Wake up the parent if it is waiting so that it can recheck
>  	 * wait permission to the new task SID. */
>  	read_lock(&tasklist_lock);
> -	wake_up_interruptible(&current->real_parent->signal->wait_chldexit);
> +	__wake_up_parent(current, current->real_parent);
>  	read_unlock(&tasklist_lock);
>  }
>  
> 

-- 
James Morris
<jmorris@namei.org>

Re: [PATCH] selinux_bprm_committed_creds: use __wake_up_parent()

[Valdis.Kletnieks]

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

On Fri, 03 Jul 2009 11:23:11 +0200, Oleg Nesterov said:
> (depends on ptrace-__ptrace_detach-do-__wake_up_parent-if-we-reap-the-tracee.patch
>  which exports __wake_up_parent)
> 
> Spotted by Valdis.Kletnieks@vt.edu.
> 
> selinux_bprm_committed_creds() should not play with ->wait_chldexit, now
> that __wake_up_parent() is exported change the code to use this helper.
> 
> Signed-off-by: Oleg Nesterov <oleg@redhat.com>
> 
> --- WAIT/security/selinux/hooks.c~SEL_WAKE_PARENT	2009-06-16 17:01:42.000000000 +0200
> +++ WAIT/security/selinux/hooks.c	2009-07-03 11:15:08.000000000 +0200

Oleg: Thanks muchly - I applied the patch, reverted the mm/vmscan.c patch that
was giving others trouble, and 31-rc1-mmotm0702 is up and running

Feel free to stick a

Tested-By: Valdis Kletnieks <valdis.kletnieks@vt.edu>

on it as it goes upstream...


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

Re: [PATCH] selinux_bprm_committed_creds: use __wake_up_parent()

[David Howells]

Oleg Nesterov <oleg@redhat.com> wrote:

> (depends on ptrace-__ptrace_detach-do-__wake_up_parent-if-we-reap-the-tracee.patch
>  which exports __wake_up_parent)
> 
> Spotted by Valdis.Kletnieks@vt.edu.

You probably want to add this as a 'Reported-by' tag.

> selinux_bprm_committed_creds() should not play with ->wait_chldexit, now
> that __wake_up_parent() is exported change the code to use this helper.
> 
> Signed-off-by: Oleg Nesterov <oleg@redhat.com>

Acked-by: David Howells <dhowells@redhat.com>

Re: mmotm 2009-06-30-12-50 uploaded

[Valdis.Kletnieks]

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

On Thu, 02 Jul 2009 12:47:26 PDT, Andrew Morton said:
> On Thu, 02 Jul 2009 15:16:03 -0400
> Valdis.Kletnieks@vt.edu wrote:

> > [    0.657296] WARNING: at kernel/lockdep.c:2143 trace_hardirqs_on_caller+0xc7/0x145()

> If we rely upon these functions only ever being called from
> smp_call_function_single(), and if smp_call_function_single() is
> correctly implemented, we should be able to do this:
> 
> --- a/drivers/acpi/processor_throttling.c~a
> +++ a/drivers/acpi/processor_throttling.c

That does seem to have scared the warning into hiding - I'm not seeing it
anymore in -mmotm0702.  Thanks.

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

Re: [PATCH] selinux_bprm_committed_creds: use __wake_up_parent()

[Oleg Nesterov]

On 07/03, Valdis.Kletnieks@vt.edu wrote:
>
> Feel free to stick a
>
> Tested-By: Valdis Kletnieks <valdis.kletnieks@vt.edu>

Yes, thanks a lot Valdis!

Oleg.

Re: [PATCH] selinux_bprm_committed_creds: use __wake_up_parent()

[Andrew Morton]

On Fri, 3 Jul 2009 11:23:11 +0200 Oleg Nesterov <oleg@redhat.com> wrote:

> (depends on ptrace-__ptrace_detach-do-__wake_up_parent-if-we-reap-the-tracee.patch
>  which exports __wake_up_parent)
> 
> Spotted by Valdis.Kletnieks@vt.edu.
> 
> selinux_bprm_committed_creds() should not play with ->wait_chldexit, now
> that __wake_up_parent() is exported change the code to use this helper.

That's a bit vague.  Why shouldn't it play with wait_chldexit?  What
changed to make that wrong?

Is this a -mm fix?  If so, which -mm patch introduced the problem?

If not, how come the crash isn't being reported in mainline?

Confused.

> Signed-off-by: Oleg Nesterov <oleg@redhat.com>
> 
> --- WAIT/security/selinux/hooks.c~SEL_WAKE_PARENT	2009-06-16 17:01:42.000000000 +0200
> +++ WAIT/security/selinux/hooks.c	2009-07-03 11:15:08.000000000 +0200
> @@ -2404,7 +2404,7 @@ static void selinux_bprm_committed_creds
>  	/* Wake up the parent if it is waiting so that it can recheck
>  	 * wait permission to the new task SID. */
>  	read_lock(&tasklist_lock);
> -	wake_up_interruptible(&current->real_parent->signal->wait_chldexit);
> +	__wake_up_parent(current, current->real_parent);
>  	read_unlock(&tasklist_lock);
>  }
>  

Re: [PATCH] selinux_bprm_committed_creds: use __wake_up_parent()

[Oleg Nesterov]

On 07/03, Andrew Morton wrote:
>
> On Fri, 3 Jul 2009 11:23:11 +0200 Oleg Nesterov <oleg@redhat.com> wrote:
>
> > (depends on ptrace-__ptrace_detach-do-__wake_up_parent-if-we-reap-the-tracee.patch
> >  which exports __wake_up_parent)
> >
> > Spotted by Valdis.Kletnieks@vt.edu.
> >
> > selinux_bprm_committed_creds() should not play with ->wait_chldexit, now
> > that __wake_up_parent() is exported change the code to use this helper.
>
> That's a bit vague.  Why shouldn't it play with wait_chldexit?  What
> changed to make that wrong?

The code was correct (btw, sorry if my message looked as if it is not).

But we should not play with "internal" structures outside of signal/exit
code. So this change is imho good regardless, __wake_up_parent() should
be used to notify threads sleeping in do_wait().

However, __wake_up_parent() was not exported, that is why _committed_creds()
does wake_up by hand.

> Is this a -mm fix?  If so, which -mm patch introduced the problem?

Yes, my fault.

	do_wait-wakeup-optimization-change-__wake_up_parent-to-use-filtered-wakeup.patch

assumes that __wake_up_parent() should be always used.

Oleg.