2010-04-05 23:37:19

by Andrew Morton

[permalink] [raw]
Subject: mmotm 2010-04-05-16-09 uploaded

The mm-of-the-moment snapshot 2010-04-05-16-09 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.34-rc3:

origin.patch
rmap-fix-anon_vma_fork-memory-leak.patch
bitops-remove-temporary-for_each_bit.patch
linux-next.patch
linux-next-git-rejects.patch
next-remove-localversion.patch
i-need-old-gcc.patch
arch-x86-crypto-aesni-intel_asms-still-busted.patch
include-linux-fsh-complete-hexification-of-fmode_-constants.patch
exit-fix-oops-in-sync_mm_rss.patch
exit-fix-oops-in-sync_mm_rss-fix.patch
include-linux-kfifoh-fix-init_kfifo.patch
vesafb-use-platform_driver_probe-instead-of-platform_driver_register.patch
fbdev-rename-imacfbtxt-to-efifbtxt-and-change-imacfb-to-efifb.patch
drivers-char-amiserialc-add-missing-local_irq_restore.patch
drivers-gpio-timbgpioc-add-missing-unlock.patch
omap-hsmmc-fix-a-bug-in-card-remove-scenario.patch
initramfs-prevent-buffer-overflow-when-unpacking-to-rootfs.patch
mxser-spin_lock-=-spin_lock_irq.patch
mxser-spin_lock-=-spin_lock_irq-fix.patch
cciss-unlock-on-error-path.patch
drivers-thermal-thermal_sysc-fix-key-f70f4b50-not-in-data-in-thermal_sys.patch
device_attributes-add-sysfs_attr_init-for-dynamic-attributes.patch
readahead-fix-null-filp-dereference.patch
devmem-handle-class_create-failure.patch
mm-revert-vmscan-get_scan_ratio-cleanup.patch
mb862xxfb-fix-acceleration-module-license.patch
mb862xxfb-update-valentins-email-address.patch
raw-fsync-method-is-now-required.patch
bsdacct-use-del_timer_sync-in-acct_exit_ns.patch
fbdev-fix-kconfig-breakage-in-drivers-video.patch
ratelimit-annotate-___ratelimit.patch
ratelimit-annotate-___ratelimit-fix.patch
kernelh-fix-wrong-usage-of-__ratelimit.patch
ratelimit-fix-the-return-value-when-__ratelimit-fails-to-acquire-the-lock.patch
pagemap-fix-pfn-calculation-for-hugepage-v3.patch
memcg-fix-race-in-file_mapped-accounting.patch
rtc-mxc-multiple-fixes-in-rtc-mxc-probe-method.patch
rtc-mxc-multiple-fixes-in-rtc-mxc-probe-method-checkpatch-fixes.patch
frv-hide-uncached_access-when-pgprot_noncached-is-not-defined.patch
frv-fix-kernel-user-segment-handling-in-nommu-mode.patch
frv-extend-gdbstub-to-support-more-features-of-gdb.patch
frv-extend-gdbstub-to-support-more-features-of-gdb-fix.patch
fs-cache-order-the-debugfs-stats-correctly.patch
it8761e_gpio-fix-bug-in-gpio-numbering.patch
power_meter-acpi_device_class-power_meter_resource-too-long.patch
block-elevatorc-fix-block-elevatorc-elevator_get-off-by-one-error.patch
drivers-base-cpuc-fix-the-output-from-sys-devices-system-cpu-offline.patch
intel-agpc-fix-crash-when-accessing-nonexistent-gtt-entries-in-i915.patch
intel-agpc-fix-crash-when-accessing-nonexistent-gtt-entries-in-i915-checkpatch-fixes.patch
inotify-dont-leak-user-struct-on-inotify-release.patch
oprofile-remove-double-ring-buffering.patch
arch-powerpc-kernel-vioc-add-missing-unlock.patch
drivers-macintosh-macio-adbc-add-missing-unlock.patch
sched-prevent-compiler-from-optimising-sched_avg_update-loop.patch
dpt_i20-several-use-after-free-issues.patch
scsi-be2iscsi-fix-lock-imbalance.patch
scsi-lpfc-fix-lock-imbalances.patch
scsi-qla2xxx-fix-lock-imbalance.patch
drivers-scsi-qla2xxx-qla_attrc-add-missing-unlock.patch
keys-dont-need-to-use-rcu-in-keyring_read-as-semaphore-is-held.patch
drivers-serial-pmac_zilogc-add-missing-unlock.patch
drivers-usb-gadget-s3c-hsotgc-add-missing-unlock.patch
x86-handle-overlapping-mptables.patch
acerhdf-add-new-bios-versions.patch
drivers-acpi-use-kasprintf.patch
drivers-acpi-use-kasprintf-fix.patch
sbshc-acpi_device_class-smbus_host_controller-too-long.patch
acpi_pad-processor_aggregator-name-too-long.patch
acpi-map-pxms-to-low-node-ids.patch
arch-x86-kernel-hpetc-fix-bug-in-rtc-emulation.patch
x86-apic-ack-all-pending-irqs-when-crashed-on-kexec-v5.patch
arch-x86-pci-use-kasprintf.patch
x86-nosmp-command-line-option-should-force-the-system-into-up-mode.patch
arch-x86-kernel-setupcl-phoenix-bios-fixup-is-needed-on-dell-inspiron-mini-1012.patch
agp-amd64-fix-pci-reference-leaks.patch
arm-convert-proc-cpu-aligment-to-seq_file.patch
arch-arm-plat-pxa-dmac-correct-null-test.patch
arch-arm-include-asm-elfh-forward-declare-the-task-struct.patch
cifs-provide-user-with-a-hint-when-name-resolution-fails.patch
cifs-provide-user-with-a-hint-when-name-resolution-fails-fix.patch
dmaengine-support-for-st-ericssons-dma40-block-v3.patch
dmaengine-dma40-u8500-platform-configuration-v3.patch
powerpc-sky-cpu-redundant-or-incorrect-tests-on-unsigned.patch
arch-powerpc-platforms-pseries-use-kasprintf.patch
gpu-vga_switcheroo-fix-lock-imbalance.patch
drivers-gpu-drm-via-via_videoc-fix-off-by-one-issue.patch
drivers-gpu-drm-radeon-radeon_atombiosc-range-check-issues.patch
drivers-gpu-drm-drm_sysfsc-sysfs-files-error-handling.patch
drivers-gpu-drm-drm_memoryc-fix-check-for-end-of-loop.patch
dib3000mc-reduce-large-stack-usage.patch
dib7000p-reduce-large-stack-usage.patch
dvb-usb-gp8psk-fix-potential-null-derefernce.patch
drivers-media-video-avoid-null-dereference.patch
drivers-media-video-au0828-au0828-videoc-off-by-one-bug.patch
drivers-media-video-zc0301-zc0301_corec-improve-error-handling.patch
drivers-media-video-et61x251-et61x251_corec-improve-error-handling.patch
drivers-media-video-sn9c102-sn9c102_corec-improve-error-handling.patch
cx88-improve-error-handling.patch
ir-keytable-avoid-double-lock.patch
fs-fscache-object-listc-fix-warning-on-32-bit.patch
intel-iommu-use-for_each_set_bit.patch
gpiolib-introduce-chip-addition-removal-notifier.patch
of-gpio-add-support-for-two-stage-registration-for-the-of_gpio_chips.patch
of-gpio-implement-gpiolib-notifier-hooks.patch
of-gpio-implement-gpiolib-notifier-hooks-fix.patch
of-gpio-implement-gpiolib-notifier-hooks-fix-fix2.patch
powerpc-mcu_mpc8349emitx-remove-of-gpio-handling-stuff.patch
gpiolib-cosmetic-improvements-for-error-handling-in-gpiochip_add.patch
timers-introduce-the-concept-of-timer-slack-for-legacy-timers.patch
cpu-timers-simplify-rlimit_cpu-handling.patch
cpu-timers-cleanup-arm_timer.patch
cpu-timers-return-correct-previous-timer-reload-value.patch
cpu-timers-change-sigev_none-timer-implementation.patch
cpu-timers-assure-to-not-iterate-over-all-threads-in-fastpath_timer_check.patch
cpu-timers-optimize-run_posix_cpu_timers.patch
cs5535-clockevt-free-timer-in-irq-setup-error-path.patch
timer-print-function-name-for-timer-callbacks-modifying-preemption-count.patch
time-clean-up-warp_clock.patch
time-clean-up-direct-xtime-usage-in-xen.patch
ntp-make-time_adjust-static.patch
ntp-remove-tickadj.patch
ati_remote-add-some-missing-devices-from-lirc_atiusb.patch
usbtouchscreen-support-bigger-inexio-touchscreens.patch
matrix_keypad-allow-platform-to-disable-key-autorepeat.patch
markup_oops-fix-perlcritic-warnings.patch
led-driver-for-the-soekris-net5501-board.patch
led-driver-for-the-soekris-net5501-board-checkpatch-fixes.patch
led-driver-for-the-soekris-net5501-board-fix-2.patch
leds-route-kbd-leds-through-the-generic-leds-layer.patch
leds-route-kbd-leds-through-the-generic-leds-layer-leds-input-depends-on-input.patch
leds-route-kbd-leds-through-the-generic-leds-layer-fix.patch
drivers-mfd-pcf50633-corec-off-by-one-issue.patch
mfd-add-support-for-janz-cmod-io-pci-modulbus-carrier-board.patch
can-add-support-for-janz-vmod-ican3-intelligent-can-module.patch
gpio-add-support-for-janz-vmod-ttl-digital-io-module.patch
gpio-add-support-for-janz-vmod-ttl-digital-io-module-fix.patch
hrtimer-provide-schedule_hrtimeout-for-wallclock.patch
ipc-mqueuec-let-message-queue-timeout-use-hrtimers.patch
ipc-mqueuec-let-message-queue-timeout-use-hrtimers-checkpatch-fixes.patch
bitops-rename-for_each_bit-to-for_each_set_bit-mtd.patch
mtd-nandsim-fix-typo-struct-nandsin_geometry.patch
mtd-nand-remove-stray-endchoice-from-kconfig-help-text.patch
ntfs-clean-up-ntfs_attr_extend_initialized.patch
ntfs-use-add_to_page_cache_lru.patch
score-fix-dereference-of-null-pointer-in-local_flush_tlb_page.patch
x25-attempts-to-negotiate-invalid-throughput.patch
3x59x-fix-pci-resource-management.patch
mbp_nvidia_bl-add-support-for-older-macbookpro-and-macbook-61.patch
backlight-backlight_device_register-return-err_ptr.patch
backlight-add-s6e63m0-amoled-lcd-panel-driver.patch
backlight-add-s6e63m0-amoled-lcd-panel-driver-checkpatch-fixes.patch
sunrpc-use-formatting-of-module-name-in-sunrpc.patch
serial-two-branches-the-same-in-timbuart_set_mctrl.patch
serial-timbuart-make-sure-last-byte-is-sent-when-port-is-closed.patch
serial-timbuart-make-sure-last-byte-is-sent-when-port-is-closed-fix.patch
serial-8250_pnp-add-fujitsu-wacom-device.patch
kernel-irq-managec-add-raise_threaded_irq.patch
kernel-irq-managec-add-raise_threaded_irq-fix.patch
max3100-move-to-threaded-interrupt.patch
max3100-add-console-support-for-max3100.patch
max3100-to_max3100_port-small-style-fixes.patch
max3100-to_max3100_port-small-style-fixes-fix.patch
serial-add-driver-for-the-altera-jtag-uart.patch
serial-add-driver-for-the-altera-uart.patch
serial-add-driver-for-the-altera-uart-update.patch
s390-potential-buffer-overflow.patch
kernel-irq-procc-expose-the-irq_desc-node-in-proc-irq.patch
lockdep-add-novalidate-class-for-dev-mutex-conversion.patch
rcu-remove-init_rcu_head-rcu_head_init-rcu_head.patch
scsi-add-__init-__exit-macros-to-ibmvstgtc.patch
drivers-scsi-fnic-fnic_scsic-clean-up.patch
drivers-scsi-gdthc-fix-buffer-overflow.patch
drivers-scsi-lpfc-lpfc_vportc-fix-read-buffer-overflow.patch
osst-fix-read-buffer-overflow.patch
gdth-unmap-ccb_phys-when-scsi_add_host-fails-in-gdth_eisa_probe_one.patch
drivers-scsi-libsas-use-sam_good.patch
ncr5380-bit-mr_dma_mode-set-twice-in-ncr5380_transfer_dma.patch
drivers-scsi-remove-unnecessary-null-test.patch
drivers-message-move-dereference-after-null-test.patch
scsi-pmcraid-redundant-check-in-pmcraid_check_ioctl_buffer.patch
mpt-fusion-convert-to-seq_file.patch
g_ncr5380-remove-misleading-pnp-error-message.patch
g_ncr5380-fix-broken-mmio-compilation.patch
g_ncr5380-fix-missing-pnp_device_detach-and-scsi_unregister-on-rmmod.patch
dc395x-decrease-iteration-for-tag_number-of-max_command-in-start_scsi.patch
drivers-scsi-correct-the-size-argument-to-kmalloc.patch
scsi-remove-superfluous-null-pointer-check-from-scsi_kill_request.patch
mpt2sas-fix-confusion-in-_scsih_sas_device_status_change_event.patch
scsi-sdc-quiet-all-sparse-noise.patch
drivers-scsi-bfa-bfad_imc-eliminate-useless-code.patch
lpfc-positive-error-return-into-negative.patch
drivers-scsi-qla2xxx-qla_osc-fix-continuation-line-formats.patch
scsi-bfa-correct-onstack-wait_queue_head-declaration.patch
mptscsih-fix-first-line-of-kernel-doc-for-a-few-functions.patch
drivers-scsi-chc-dont-use-vprintk-as-macro.patch
iscsi-change-to.patch
scsi-fix-convert-scsi_scanc-kernel-doc.patch
scsi-update-drivers-tools-url-references.patch
bfa-wrong-fcport-h2i-message-tested-in-bfa_fcport_isr.patch
wd7000-typo-spin_unlock_irq-=-spin_lock_irq.patch
fs-splicec-fix-mapping_gfp_mask-usage.patch
iio-iio_get_new_idr_val-return-negative-value-on-failure.patch
iio-iio_get_new_idr_val-return-negative-value-on-failure-fix.patch
vt6655-cgi-csi-confusion-in-device_ioctl.patch
drivers-staging-otus-hal-hpanic-using-the-wrong-variable.patch
drivers-staging-comedi-drivers-dt2801c-off-by-one-issue.patch
musb-potential-use-after-free.patch
kaweth-new-usb-id-07c9-b010-allied-telesyn-at-usb10.patch
usb-fix-serial-build-when-sysrq-is-disabled.patch
usb-oxu210hp-release-spinlock-on-error-path.patch
9p-return-on-mutex_lock_interruptible.patch
9p-saving-negative-to-unsigned-char.patch
vfs-fix-vfs_rename_dir-for-fs_rename_does_d_move-filesystems.patch
vfs-improve-comment-describing-fget_light.patch
ecryptfs-another-lockdep-issue.patch
vfs-o_-bit-numbers-uniqueness-check.patch
vfs-o_-bit-numbers-uniqueness-check-update.patch
vfs-o_-bit-numbers-uniqueness-check-fix.patch
vfs-o_-bit-numbers-uniqueness-check-fix-2.patch
vfs-introduce-fmode_neg_offset-for-allowing-negative-f_pos.patch
vfs-clarify-that-nonseekable_open-will-never-fail.patch
watchdog-docs-fix-use-of-wdioc_setoptions-ioctl.patch
xtensa-convert-to-asm-generic-hardirqh.patch
xtensa-includecheck-fix-vectorss.patch
xtensa-fix-unnecessary-setting-of-xtime.patch
modpost-support-objects-with-more-than-64k-sections.patch
mm.patch
page-allocator-reduce-fragmentation-in-buddy-allocator-by-adding-buddies-that-are-merging-to-the-tail-of-the-free-lists.patch
sparsemem-on-no-vmemmap-path-put-mem_map-on-node-high-too.patch
shmem-remove-redundant-code.patch
define-madv_hugepage.patch
mm-remove-return-value-of-putback_lru_pages.patch
mempolicy-remove-redundant-code.patch
oom-filter-tasks-not-sharing-the-same-cpuset.patch
oom-sacrifice-child-with-highest-badness-score-for-parent.patch
oom-select-task-from-tasklist-for-mempolicy-ooms.patch
oom-remove-special-handling-for-pagefault-ooms.patch
oom-badness-heuristic-rewrite.patch
oom-deprecate-oom_adj-tunable.patch
oom-replace-sysctls-with-quick-mode.patch
oom-avoid-oom-killer-for-lowmem-allocations.patch
oom-remove-unnecessary-code-and-cleanup.patch
oom-default-to-killing-current-for-pagefault-ooms.patch
oom-avoid-race-for-oom-killed-tasks-detaching-mm-prior-to-exit.patch
oom-select_bad_process-check-pf_kthread-instead-of-mm-to-skip-kthreads.patch
oom-select_bad_process-pf_exiting-check-should-take-mm-into-account.patch
oom-introduce-find_lock_task_mm-to-fix-mm-false-positives.patch
oom-oom_forkbomb_penalty-move-thread_group_cputime-out-of-task_lock.patch
oom-hold-tasklist_lock-when-dumping-tasks.patch
oom-give-current-access-to-memory-reserves-if-it-has-been-killed.patch
oom-avoid-sending-exiting-tasks-a-sigkill.patch
oom-clean-up-oom_kill_task.patch
oom-clean-up-oom_badness.patch
mempolicy-remove-case-mpol_interleave-from-policy_zonelist.patch
mempolicy-remove-redundant-check.patch
mempolicy-dont-call-mpol_set_nodemask-when-no_context.patch
mempolicy-lose-unnecessary-loop-variable-in-mpol_parse_str.patch
mempolicy-rename-policy_types-and-cleanup-initialization.patch
mempolicy-factor-mpol_shared_policy_init-return-paths.patch
mempolicy-document-cpuset-interaction-with-tmpfs-mpol-mount-option.patch
mincore-cleanups.patch
mincore-break-do_mincore-into-logical-pieces.patch
mincore-pass-ranges-as-startend-address-pairs.patch
mincore-do-nested-page-table-walks.patch
pagemap-add-ifdefs-config_hugetlb_page-on-code-walking-hugetlb-vma.patch
mm-default-to-node-zonelist-ordering-when-nodes-have-only-lowmem.patch
oom-move-sysctl-declarations-to-oomh.patch
fs-writebackc-bitfields-should-be-unsigned.patch
frv-duplicate-output_buffer-of-e03.patch
frv-duplicate-output_buffer-of-e03-checkpatch-fixes.patch
nommu-allow-private-mappings-of-read-only-devices.patch
errh-add-__must_check-to-error-pointer-handlers.patch
kernel-user-remove-unreachable-code.patch
endian-define-__byte_order.patch
bitops-optimize-hweight-by-making-use-of-compile-time-evaluation.patch
x86-add-optimized-popcnt-variants.patch
hangcheck-timer-fix-x86_32-bugs.patch
improve-sys_personality-for-compat-architectures.patch
vsprintfc-use-noinline_for_stack.patch
dynamic_debug-small-cleanup-in-ddebug_proc_write.patch
lib-hexdumpc-reduce-stack-variable-size-and-cleanups.patch
firmware-loader-use-statically-initialized-data-attribute.patch
firmware-loader-use-statically-initialized-data-attribute-fix.patch
firmware-loader-use-statically-initialized-data-attribute-fix-fix.patch
davinci-mmc-pass-number-of-sg-segments-as-platform-data.patch
mmc-omap-add-support-for-16-bit-and-32-bit-registers.patch
sdhci-implement-cap_clock_base_broken-quirk.patch
sdhci-pltfm-implement-platform-data-passing.patch
sdhci-pltfm-do-not-print-errors-in-case-of-an-extended-iomem-size.patch
davinci-mmc-add-a-function-to-control-reset-state-of-the-controller.patch
davinci-mmc-updates-to-suspend-resume-implementation.patch
davinci-mmc-updates-to-suspend-resume-implementation-checkpatch-fixes.patch
checkpatch-add-check-for-too-short-kconfig-descriptions.patch
checkpatch-add-check-for-too-short-kconfig-descriptions-checkpatch-fixes.patch
hwmon-driver-for-ti-tmp102-temperature-sensor.patch
hwmon-driver-for-ti-tmp102-temperature-sensor-fix.patch
xen-fix-build-when-sysrq-is-disabled.patch
s3c-rtc-driver-add-support-for-s3c64xx.patch
rtc-mxc-remove-unnecessary-clock-source-for-rtc-subsystem.patch
gpio-add-interrupt-handling-capability-to-max732x.patch
gpiolib-make-names-array-and-its-values-const.patch
gpiolib-make-names-array-and-its-values-const-fix.patch
gpiolib-a-gpio-is-unsigned-so-use-%u-to-print-it.patch
gpiolib-document-that-names-can-contain-printk-format-specifiers.patch
fbdev-bfin-lq035q1-fb-respect-new-ppi-mode-platform-field.patch
sis-strcpy-=-strlcpy.patch
fbdev-section-cleanup-in-arcfb.patch
fbdev-section-cleanup-in-hgafb.patch
fbdev-section-cleanup-in-vfb.patch
fbdev-section-cleanup-in-vga16fb.patch
fbdev-section-cleanup-in-w100fb.patch
cobalt_lcdfb-fix-section-mismatch-cobalt_lcdfb_fix.patch
auxdisplay-section-cleanup-in-cfag12864bfb-driver.patch
ext3-fixup-rb_root-initializations-to-use-rb_root.patch
hfsplus-identify-journal-info-block-in-volume-header.patch
hfsplus-fix-journal-detection.patch
memcg-oom-wakeup-filter.patch
memcg-oom-wakeup-filter-update.patch
memcg-oom-notifier.patch
memcg-oom-notifier-update.patch
memcg-oom-kill-disable-and-oom-status.patch
memcg-oom-kill-disable-and-oom-status-update.patch
memcg-oom-kill-disable-and-oom-status-update-checkpatch-fixes.patch
kmod-add-init-function-to-usermodehelper.patch
exec-replace-call_usermodehelper_pipe-with-use-of-umh-init-function-and-resolve-limit.patch
umh-creds-convert-call_usermodehelper_keys-to-use-subprocess_info-init.patch
umh-creds-kill-subprocess_info-cred-logic.patch
call_usermodehelper-no-need-to-unblock-signals.patch
wait_for_helper-sigchld-from-user-space-can-lead-to-use-after-free.patch
call_usermodehelper-simplify-fix-umh_no_wait-case.patch
call_usermodehelper-umh_wait_exec-ignores-kernel_thread-failure.patch
coredump-factor-out-the-not-ispipe-file-checks.patch
coredump-cleanup-ispipe-code.patch
coredump-factor-out-put_cred-calls.patch
coredump-shift-down_writemmap_sem-into-coredump_wait.patch
exit-exit_notify-can-trust-signal-notify_count-0.patch
exit-change-zap_other_threads-to-count-sub-threads.patch
exit-avoid-sig-count-in-de_thread-__exit_signal-synchronization.patch
exit-avoid-sig-count-in-__exit_signal-to-detect-the-group-dead-case.patch
posix-cpu-timers-avoid-task-signal-=-null-checks.patch
ia64-ptrace_attach_sync_user_rbs-avoid-task-signal-=-null-checks.patch
fork-exit-move-tty_kref_put-outside-of-__cleanup_signal.patch
signals-make-task_struct-signal-immutable-refcountable.patch
signals-clear-signal-tty-when-the-last-thread-exits.patch
signals-clear-signal-tty-when-the-last-thread-exits-fix.patch
signals-kill-the-awful-task_rq_unlock_wait-hack.patch
exit-__exit_signal-use-thread_group_leader-consistently.patch
kill-the-obsolete-thread_group_cputime_free-and-taskstats_tgid_init-helpers.patch
exit-move-taskstats_tgid_free-from-__exit_signal-to-free_signal_struct.patch
check_unshare_flags-kill-the-bogus-clone_sighand-sig-count-check.patch
proc-get_nr_threads-doesnt-need-siglock-any-longer.patch
proc-make-collect_sigign_sigcatch-rcu-safe.patch
proc-make-task_sig-lockless.patch
proc_sched_show_task-use-get_nr_threads.patch
keyctl_session_to_parent-use-thread_group_empty-to-check-singlethreadness.patch
proc-turn-signal_struct-count-into-int-nr_threads.patch
proc-turn-signal_struct-count-into-int-nr_threads-checkpatch-fixes.patch
proc-cleanup-remove-unused-assignments.patch
cpu-hotplug-introduce-cpu_notify-__cpu_notify-cpu_notify_nofail.patch
cpu-hotplug-return-better-errno-on-cpu-hotplug-failure.patch
notifier-change-notifier_from_errno0-to-return-notify_ok.patch
x86-convert-cpu-notifier-to-return-encapsulate-errno-value.patch
topology-convert-cpu-notifier-to-return-encapsulate-errno-value.patch
kernel-convert-cpu-notifier-to-return-encapsulate-errno-value.patch
slab-convert-cpu-notifier-to-return-encapsulate-errno-value.patch
iucv-convert-cpu-notifier-to-return-encapsulate-errno-value.patch
ehca-convert-cpu-notifier-to-return-encapsulate-errno-value.patch
s390-convert-cpu-notifier-to-return-encapsulate-errno-value.patch
md-convert-cpu-notifier-to-return-encapsulate-errno-value.patch
fault-injection-add-cpu-notifier-error-injection-module.patch
fault-injection-add-cpu-notifier-error-injection-module-fix.patch
cpuhotplug-do-not-need-cpu_hotplug_begin-when-config_hotplug_cpu=n.patch
ipmi-raise-precedence-of-pnp-based-discovery-mechanisms-acpi-pci.patch
ipmi-convert-tracking-of-the-acpi-device-pointer-to-a-pnp-device.patch
ipmi-update-driver-to-use-dev_printk-and-its-constructs.patch
char-drivers-ram-oops-panic-logger.patch
char-drivers-ram-oops-panic-logger-update.patch
drivers-char-ppdevc-use-kasprintf.patch
delay-accounting-re-implement-c-for-getdelaysc-to-report-information-on-a-target-command.patch
delay-accounting-re-implement-c-for-getdelaysc-to-report-information-on-a-target-command-checkpatch-fixes.patch
delayacct-align-to-8-byte-boundary-on-64-bit-systems.patch
lib-random32-export-pseudo-random-number-generator-for-modules.patch
drivers-edac-introduce-missing-kfree.patch
edac-add-__init-to-i7core_xeon_pci_fixup.patch
ssb-add-dma_dev-to-ssb_device-structure.patch
b43legacy-replace-the-ssb_dma-api-with-the-generic-dma-api.patch
b43-replace-the-ssb_dma-api-with-the-generic-dma-api.patch
b44-replace-the-ssb_dma-api-with-the-generic-dma-api.patch
ssb-remove-the-ssb-dma-api.patch
panic-allow-taint-flag-for-warnings-to-be-changed-from-taint_warn.patch
panic-allow-taint-flag-for-warnings-to-be-changed-from-taint_warn-checkpatch-fixes.patch
panic-add-taint-flag-taint_firmware_workaround-i.patch
pci-dmar-combine-the-bios-dmar-table-warning-messages.patch
pci-dmar-tone-down-warnings-about-invalid-bios-dmar-tables.patch
kfifo-kfifo_is_fullempty-should-return-bools-not-ints.patch
time-kill-off-config_generic_time.patch
asm-generic-remove-isa_dma_threshold-in-scatterlisth.patch
asm-generic-add-need_sg_dma_length-to-define-sg_dma_len.patch
asm-generic-add-need_sg_dma_length-to-define-sg_dma_len-fix.patch
powerpc-use-asm-generic-scatterlisth.patch
arm-use-asm-generic-scatterlisth.patch
alpha-use-asm-generic-scatterlisth.patch
vfs-add-super-operation-writeback_inodes.patch
vfs-take-2add-set_page_dirty_notag.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-writeback_inodes-implementation.patch
reiser4-writeback_inodes-implementation-fix.patch
reiser4-fixup-checkin-checkout-jnodes-for-entd.patch
reiser4-fixups.patch
reiser4-broke.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-add-missing-header-file.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
getblk-handle-2tb-devices.patch
getblk-handle-2tb-devices-fix.patch
notify_change-callers-must-hold-i_mutex.patch


2010-04-06 05:05:47

by Randy Dunlap

[permalink] [raw]
Subject: [PATCH mmotm] hid-picolcd: depends on LCD_CLASS_DEVICE

From: Randy Dunlap <[email protected]>

HID_PICOLCD should depend on LCD_CLASS_DEVICE, otherwise the
build fails when HID_PICOLCD=y and LCD_CLASS_DEVICE=m:

hid-picolcd.c:(.text+0x84523f): undefined reference to `lcd_device_unregister'
hid-picolcd.c:(.text+0x8478ab): undefined reference to `lcd_device_register'
hid-picolcd.c:(.text+0x84c15f): undefined reference to `lcd_device_unregister'

Signed-off-by: Randy Dunlap <[email protected]>
---
drivers/hid/Kconfig | 1 +
1 file changed, 1 insertion(+)

--- mmotm-2010-0405-1609.orig/drivers/hid/Kconfig
+++ mmotm-2010-0405-1609/drivers/hid/Kconfig
@@ -265,6 +265,7 @@ config HID_PETALYNX
config HID_PICOLCD
tristate "PicoLCD (graphic version)"
depends on USB_HID
+ depends on LCD_CLASS_DEVICE
select FB_DEFERRED_IO if FB
select FB_SYS_FILLRECT if FB
select FB_SYS_COPYAREA if FB

2010-04-06 08:40:12

by Jiri Kosina

[permalink] [raw]
Subject: Re: [PATCH mmotm] hid-picolcd: depends on LCD_CLASS_DEVICE


[ adding Bruno to CC ]

On Mon, 5 Apr 2010, Randy Dunlap wrote:

> From: Randy Dunlap <[email protected]>
>
> HID_PICOLCD should depend on LCD_CLASS_DEVICE, otherwise the
> build fails when HID_PICOLCD=y and LCD_CLASS_DEVICE=m:
>
> hid-picolcd.c:(.text+0x84523f): undefined reference to `lcd_device_unregister'
> hid-picolcd.c:(.text+0x8478ab): undefined reference to `lcd_device_register'
> hid-picolcd.c:(.text+0x84c15f): undefined reference to `lcd_device_unregister'
>
> Signed-off-by: Randy Dunlap <[email protected]>
> ---
> drivers/hid/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> --- mmotm-2010-0405-1609.orig/drivers/hid/Kconfig
> +++ mmotm-2010-0405-1609/drivers/hid/Kconfig
> @@ -265,6 +265,7 @@ config HID_PETALYNX
> config HID_PICOLCD
> tristate "PicoLCD (graphic version)"
> depends on USB_HID
> + depends on LCD_CLASS_DEVICE
> select FB_DEFERRED_IO if FB
> select FB_SYS_FILLRECT if FB
> select FB_SYS_COPYAREA if FB

Thanks Randy. We'll have to take care of the other dependencies as well
though (CONFIG_LCD_CLASS_DEVICE, CONFIG_LEDS_CLASS).

--
Jiri Kosina
SUSE Labs, Novell Inc.

2010-04-06 08:56:43

by Bruno Prémont

[permalink] [raw]
Subject: Re: [PATCH mmotm] hid-picolcd: depends on LCD_CLASS_DEVICE

On Tue, 6 Apr 2010 10:40:06 +0200 Jiri Kosina <[email protected]> wrote:
>
> [ adding Bruno to CC ]
>
> On Mon, 5 Apr 2010, Randy Dunlap wrote:
>
> > From: Randy Dunlap <[email protected]>
> >
> > HID_PICOLCD should depend on LCD_CLASS_DEVICE, otherwise the
> > build fails when HID_PICOLCD=y and LCD_CLASS_DEVICE=m:
> >
> > hid-picolcd.c:(.text+0x84523f): undefined reference to `lcd_device_unregister'
> > hid-picolcd.c:(.text+0x8478ab): undefined reference to `lcd_device_register'
> > hid-picolcd.c:(.text+0x84c15f): undefined reference to `lcd_device_unregister'

That is weird, the

#if defined(CONFIG_LCD_CLASS_DEVICE) || defined(CONFIG_LCD_CLASS_DEVICE_MODULE)
feature support code
#else
empty stubs
#endif

blocks should have prevented LCD_CLASS support from being built if it
was not enabled in configuration.

Do you have the .config matching your build?

When I did my test-build with LCD support enabled/disabled I didn't get
any linker errors as those mentioned above.


Thanks,
Bruno


> > Signed-off-by: Randy Dunlap <[email protected]>
> > ---
> > drivers/hid/Kconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > --- mmotm-2010-0405-1609.orig/drivers/hid/Kconfig
> > +++ mmotm-2010-0405-1609/drivers/hid/Kconfig
> > @@ -265,6 +265,7 @@ config HID_PETALYNX
> > config HID_PICOLCD
> > tristate "PicoLCD (graphic version)"
> > depends on USB_HID
> > + depends on LCD_CLASS_DEVICE
> > select FB_DEFERRED_IO if FB
> > select FB_SYS_FILLRECT if FB
> > select FB_SYS_COPYAREA if FB
>
> Thanks Randy. We'll have to take care of the other dependencies as well
> though (CONFIG_LCD_CLASS_DEVICE, CONFIG_LEDS_CLASS).
>

2010-04-06 15:28:58

by Randy Dunlap

[permalink] [raw]
Subject: Re: [PATCH mmotm] hid-picolcd: depends on LCD_CLASS_DEVICE

On Tue, 6 Apr 2010 10:56:35 +0200 Bruno Pr?mont wrote:

> On Tue, 6 Apr 2010 10:40:06 +0200 Jiri Kosina <[email protected]> wrote:
> >
> > [ adding Bruno to CC ]
> >
> > On Mon, 5 Apr 2010, Randy Dunlap wrote:
> >
> > > From: Randy Dunlap <[email protected]>
> > >
> > > HID_PICOLCD should depend on LCD_CLASS_DEVICE, otherwise the
> > > build fails when HID_PICOLCD=y and LCD_CLASS_DEVICE=m:
> > >
> > > hid-picolcd.c:(.text+0x84523f): undefined reference to `lcd_device_unregister'
> > > hid-picolcd.c:(.text+0x8478ab): undefined reference to `lcd_device_register'
> > > hid-picolcd.c:(.text+0x84c15f): undefined reference to `lcd_device_unregister'
>
> That is weird, the
>
> #if defined(CONFIG_LCD_CLASS_DEVICE) || defined(CONFIG_LCD_CLASS_DEVICE_MODULE)
> feature support code
> #else
> empty stubs
> #endif
>
> blocks should have prevented LCD_CLASS support from being built if it
> was not enabled in configuration.
>
> Do you have the .config matching your build?

Yes, it's attached.


> When I did my test-build with LCD support enabled/disabled I didn't get
> any linker errors as those mentioned above.
>
>
> Thanks,
> Bruno
>
>
> > > Signed-off-by: Randy Dunlap <[email protected]>
> > > ---
> > > drivers/hid/Kconfig | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > --- mmotm-2010-0405-1609.orig/drivers/hid/Kconfig
> > > +++ mmotm-2010-0405-1609/drivers/hid/Kconfig
> > > @@ -265,6 +265,7 @@ config HID_PETALYNX
> > > config HID_PICOLCD
> > > tristate "PicoLCD (graphic version)"
> > > depends on USB_HID
> > > + depends on LCD_CLASS_DEVICE
> > > select FB_DEFERRED_IO if FB
> > > select FB_SYS_FILLRECT if FB
> > > select FB_SYS_COPYAREA if FB
> >
> > Thanks Randy. We'll have to take care of the other dependencies as well
> > though (CONFIG_LCD_CLASS_DEVICE, CONFIG_LEDS_CLASS).
> --


---
~Randy
(re)read Documentation/ManagementStyle


Attachments:
config-r9463 (76.46 kB)

2010-04-06 16:35:49

by Bruno Prémont

[permalink] [raw]
Subject: Re: [PATCH mmotm] hid-picolcd: depends on LCD_CLASS_DEVICE

On Tue, 06 April 2010 Randy Dunlap <[email protected]> wrote:
> On Tue, 6 Apr 2010 10:56:35 +0200 Bruno Prémont wrote:
>
> > On Tue, 6 Apr 2010 10:40:06 +0200 Jiri Kosina <[email protected]> wrote:
> > >
> > > [ adding Bruno to CC ]
> > >
> > > On Mon, 5 Apr 2010, Randy Dunlap wrote:
> > >
> > > > From: Randy Dunlap <[email protected]>
> > > >
> > > > HID_PICOLCD should depend on LCD_CLASS_DEVICE, otherwise the
> > > > build fails when HID_PICOLCD=y and LCD_CLASS_DEVICE=m:
> > > >
> > > > hid-picolcd.c:(.text+0x84523f): undefined reference to `lcd_device_unregister'
> > > > hid-picolcd.c:(.text+0x8478ab): undefined reference to `lcd_device_register'
> > > > hid-picolcd.c:(.text+0x84c15f): undefined reference to `lcd_device_unregister'
> >
> > That is weird, the
> >
> > #if defined(CONFIG_LCD_CLASS_DEVICE) || defined(CONFIG_LCD_CLASS_DEVICE_MODULE)
> > feature support code
> > #else
> > empty stubs
> > #endif
> >
> > blocks should have prevented LCD_CLASS support from being built if it
> > was not enabled in configuration.
> >
> > Do you have the .config matching your build?
>
> Yes, it's attached.

Thanks, here is the extract (only the pertinent items):
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=m
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_HID_PICOLCD=y

It triggers the issue by having PicoLCD built-in while one of the
optional dependencies as a module.

Any idea of how this can be solved with kbuild in order to keep the
dependencies optional?

Something that would satisfy the following pseudocode:
if CONFIG_HID_PICOLCD == y
assert(CONFIG_LCD_CLASS_DEVICE != m)


One of my attempts did end up with a circular loop with regard to FB
(some of the FB drivers did select INPUT)?

I had something like:

config HID_PICOLCD
tristate ...

config HID_PICOLCD_FB
bool ...
depends on HID_PICOLCD
select FB
select FB_...

...

Then in the code I checked for CONFIG_HID_PICOLCD_FB instead of
(CONFIG_FB or CONFIG_FB_MODULE).

Thanks,
Bruno

2010-04-06 16:57:18

by Randy Dunlap

[permalink] [raw]
Subject: Re: [PATCH mmotm] hid-picolcd: depends on LCD_CLASS_DEVICE

On Tue, 6 Apr 2010 18:35:35 +0200 Bruno Pr?mont wrote:

> On Tue, 06 April 2010 Randy Dunlap <[email protected]> wrote:
> > On Tue, 6 Apr 2010 10:56:35 +0200 Bruno Pr?mont wrote:
> >
> > > On Tue, 6 Apr 2010 10:40:06 +0200 Jiri Kosina <[email protected]> wrote:
> > > >
> > > > [ adding Bruno to CC ]
> > > >
> > > > On Mon, 5 Apr 2010, Randy Dunlap wrote:
> > > >
> > > > > From: Randy Dunlap <[email protected]>
> > > > >
> > > > > HID_PICOLCD should depend on LCD_CLASS_DEVICE, otherwise the
> > > > > build fails when HID_PICOLCD=y and LCD_CLASS_DEVICE=m:
> > > > >
> > > > > hid-picolcd.c:(.text+0x84523f): undefined reference to `lcd_device_unregister'
> > > > > hid-picolcd.c:(.text+0x8478ab): undefined reference to `lcd_device_register'
> > > > > hid-picolcd.c:(.text+0x84c15f): undefined reference to `lcd_device_unregister'
> > >
> > > That is weird, the
> > >
> > > #if defined(CONFIG_LCD_CLASS_DEVICE) || defined(CONFIG_LCD_CLASS_DEVICE_MODULE)
> > > feature support code
> > > #else
> > > empty stubs
> > > #endif
> > >
> > > blocks should have prevented LCD_CLASS support from being built if it
> > > was not enabled in configuration.
> > >
> > > Do you have the .config matching your build?
> >
> > Yes, it's attached.
>
> Thanks, here is the extract (only the pertinent items):
> CONFIG_BACKLIGHT_LCD_SUPPORT=y
> CONFIG_LCD_CLASS_DEVICE=m
> CONFIG_BACKLIGHT_CLASS_DEVICE=y
> CONFIG_HID_PICOLCD=y
>
> It triggers the issue by having PicoLCD built-in while one of the
> optional dependencies as a module.

Yes, basically what the patch description said.

> Any idea of how this can be solved with kbuild in order to keep the
> dependencies optional?
>
> Something that would satisfy the following pseudocode:
> if CONFIG_HID_PICOLCD == y
> assert(CONFIG_LCD_CLASS_DEVICE != m)
>

If you don't want the kconfig machinery to do that (it appears that you don't),
then I guess that you'll need to expand the source code to handle
CONFIG_LCD_CLASS_DEVICE=y and CONFIG_LCD_CLASS_DEVICE=m differently.
Or only handle them differently if HID_PICOLCD=y. :(


>
> One of my attempts did end up with a circular loop with regard to FB
> (some of the FB drivers did select INPUT)?

(not that I can find)

CONFIG_VT does select INPUT
and CONFIG_DRM_I915 does
select INPUT if ACPI


> I had something like:
>
> config HID_PICOLCD
> tristate ...
>
> config HID_PICOLCD_FB
> bool ...
> depends on HID_PICOLCD
> select FB
> select FB_...
>
> ...
>
> Then in the code I checked for CONFIG_HID_PICOLCD_FB instead of
> (CONFIG_FB or CONFIG_FB_MODULE).



---
~Randy
(re)read Documentation/ManagementStyle

2010-04-06 21:04:48

by Bruno Prémont

[permalink] [raw]
Subject: Re: [PATCH mmotm] hid-picolcd: depends on LCD_CLASS_DEVICE

On Tue, 06 April 2010 Randy Dunlap <[email protected]> wrote:
> > It triggers the issue by having PicoLCD built-in while one of the
> > optional dependencies as a module.
>
> Yes, basically what the patch description said.

Oops, sorry I didn't completely read the patch description.

> > Any idea of how this can be solved with kbuild in order to keep the
> > dependencies optional?
> >
> > Something that would satisfy the following pseudocode:
> > if CONFIG_HID_PICOLCD == y
> > assert(CONFIG_LCD_CLASS_DEVICE != m)
> >
>
> If you don't want the kconfig machinery to do that (it appears that you don't),
> then I guess that you'll need to expand the source code to handle
> CONFIG_LCD_CLASS_DEVICE=y and CONFIG_LCD_CLASS_DEVICE=m differently.
> Or only handle them differently if HID_PICOLCD=y. :(

Below a patch (against 2.6.34-rc3 + Jiri's picolcd branch) which
should fix above issue keeping the deps optional.

With it it's not yet possible to select the deps from HID menu.

I did a few oldconfig and compile-tests with PICOLCD=y/m and same for
the deps (not switched FB for those tests).

Bruno





HID_PICOLCD should depend on LCD_CLASS_DEVICE, otherwise the
build fails when HID_PICOLCD=y and LCD_CLASS_DEVICE=m:

hid-picolcd.c:(.text+0x84523f): undefined reference to `lcd_device_unregister'
hid-picolcd.c:(.text+0x8478ab): undefined reference to `lcd_device_register'
hid-picolcd.c:(.text+0x84c15f): undefined reference to `lcd_device_unregister'

Reported-by: Randy Dunlap <[email protected]>
Signed-off-by: Bruno Prémont <[email protected]>

diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index a2ecd83..39df4f5 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -285,6 +285,35 @@ config HID_PICOLCD
Features that are not (yet) supported:
- IR

+config HID_PICOLCD_FB
+ bool "Framebuffer support"
+ default !EMBEDDED
+ depends on HID_PICOLCD
+ depends on HID_PICOLCD=FB || FB=y
+ select FB_DEFERRED_IO
+ select FB_SYS_FILLRECT
+ select FB_SYS_COPYAREA
+ select FB_SYS_IMAGEBLIT
+ select FB_SYS_FOPS
+
+config HID_PICOLCD_BACKLIGHT
+ bool "Backlight control"
+ default !EMBEDDED
+ depends on HID_PICOLCD
+ depends on HID_PICOLCD=BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=y
+
+config HID_PICOLCD_LCD
+ bool "Contrast control"
+ default !EMBEDDED
+ depends on HID_PICOLCD
+ depends on HID_PICOLCD=LCD_CLASS_DEVICE || LCD_CLASS_DEVICE=y
+
+config HID_PICOLCD_LEDS
+ bool "GPO via leds class"
+ default !EMBEDDED
+ depends on HID_PICOLCD
+ depends on HID_PICOLCD=LEDS_CLASS || LEDS_CLASS=y
+
config HID_QUANTA
tristate "Quanta Optical Touch"
depends on USB_HID
diff --git a/drivers/hid/hid-picolcd.c b/drivers/hid/hid-picolcd.c
index 0eacc6b..0fbc7d3 100644
--- a/drivers/hid/hid-picolcd.c
+++ b/drivers/hid/hid-picolcd.c
@@ -77,7 +77,7 @@
#define REPORT_HOOK_VERSION 0xf7 /* LCD: IN[2], OUT[1] */
#define REPORT_EXIT_FLASHER 0xff /* Bootloader: OUT[2] */

-#if defined(CONFIG_FB) || defined(CONFIG_FB_MODULE)
+#ifdef CONFIG_HID_PICOLCD_FB
/* Framebuffer
*
* The PicoLCD use a Topway LCD module of 256x64 pixel
@@ -128,7 +128,7 @@ static const struct fb_var_screeninfo picolcdfb_var = {
.bits_per_pixel = 1,
.grayscale = 1,
};
-#endif /* CONFIG_FB */
+#endif /* CONFIG_HID_PICOLCD_FB */

/* Input device
*
@@ -183,7 +183,7 @@ struct picolcd_data {
struct input_dev *input_cir;
unsigned short keycode[PICOLCD_KEYS];

-#if defined(CONFIG_FB) || defined(CONFIG_FB_MODULE)
+#ifdef CONFIG_HID_PICOLCD_FB
/* Framebuffer stuff */
u8 fb_update_rate;
u8 fb_bpp;
@@ -191,21 +191,21 @@ struct picolcd_data {
u8 *fb_bitmap; /* framebuffer */
struct fb_info *fb_info;
struct fb_deferred_io fb_defio;
-#endif /* CONFIG_FB */
-#if defined(CONFIG_LCD_CLASS_DEVICE) || defined(CONFIG_LCD_CLASS_DEVICE_MODULE)
+#endif /* CONFIG_HID_PICOLCD_FB */
+#ifdef CONFIG_HID_PICOLCD_LCD
struct lcd_device *lcd;
u8 lcd_contrast;
-#endif
-#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) || defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE)
+#endif /* CONFIG_HID_PICOLCD_LCD */
+#ifdef CONFIG_HID_PICOLCD_BACKLIGHT
struct backlight_device *backlight;
u8 lcd_brightness;
u8 lcd_power;
-#endif /* CONFIG_BACKLIGHT_CLASS_DEVICE */
-#if defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE)
+#endif /* CONFIG_HID_PICOLCD_BACKLIGHT */
+#ifdef CONFIG_HID_PICOLCD_LEDS
/* LED stuff */
u8 led_state;
struct led_classdev *led[8];
-#endif /* CONFIG_LEDS_CLASS */
+#endif /* CONFIG_HID_PICOLCD_LEDS */

/* Housekeeping stuff */
spinlock_t lock;
@@ -287,7 +287,7 @@ static struct picolcd_pending *picolcd_send_and_wait(struct hid_device *hdev,
return work;
}

-#if defined(CONFIG_FB) || defined(CONFIG_FB_MODULE)
+#ifdef CONFIG_HID_PICOLCD_FB
/* Send a given tile to PicoLCD */
static int picolcd_fb_send_tile(struct hid_device *hdev, int chip, int tile)
{
@@ -766,9 +766,9 @@ static void picolcd_exit_framebuffer(struct picolcd_data *data)
{
}
#define picolcd_fbinfo(d) NULL
-#endif /* CONFIG_FB */
+#endif /* CONFIG_HID_PICOLCD_FB */

-#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) || defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE)
+#ifdef CONFIG_HID_PICOLCD_BACKLIGHT
/*
* backlight class device
*/
@@ -864,9 +864,9 @@ static inline int picolcd_resume_backlight(struct picolcd_data *data)
{
return 0;
}
-#endif /* CONFIG_BACKLIGHT_CLASS_DEVICE */
+#endif /* CONFIG_HID_PICOLCD_BACKLIGHT */

-#if defined(CONFIG_LCD_CLASS_DEVICE) || defined(CONFIG_LCD_CLASS_DEVICE_MODULE)
+#ifdef CONFIG_HID_PICOLCD_LCD
/*
* lcd class device
*/
@@ -957,9 +957,9 @@ static inline int picolcd_resume_lcd(struct picolcd_data *data)
{
return 0;
}
-#endif /* CONFIG_LCD_CLASS_DEVICE */
+#endif /* CONFIG_HID_PICOLCD_LCD */

-#if defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE)
+#ifdef CONFIG_HID_PICOLCD_LEDS
/**
* LED class device
*/
@@ -1104,7 +1104,7 @@ static inline int picolcd_leds_set(struct picolcd_data *data)
{
return 0;
}
-#endif /* CONFIG_LEDS_CLASS */
+#endif /* CONFIG_HID_PICOLCD_LEDS */

/*
* input class device
@@ -1243,10 +1243,10 @@ static int picolcd_reset(struct hid_device *hdev)

picolcd_resume_lcd(data);
picolcd_resume_backlight(data);
-#if defined(CONFIG_FB) || defined(CONFIG_FB_MODULE)
+#ifdef CONFIG_HID_PICOLCD_FB
if (data->fb_info)
schedule_delayed_work(&data->fb_info->deferred_work, 0);
-#endif /* CONFIG_FB */
+#endif /* CONFIG_HID_PICOLCD_FB */

picolcd_leds_set(data);
return 0;

2010-04-07 16:31:31

by Randy Dunlap

[permalink] [raw]
Subject: Re: [PATCH mmotm] hid-picolcd: depends on LCD_CLASS_DEVICE

On Tue, 6 Apr 2010 23:04:34 +0200 Bruno Pr?mont wrote:

> On Tue, 06 April 2010 Randy Dunlap <[email protected]> wrote:
> > > It triggers the issue by having PicoLCD built-in while one of the
> > > optional dependencies as a module.
> >
> > Yes, basically what the patch description said.
>
> Oops, sorry I didn't completely read the patch description.
>
> > > Any idea of how this can be solved with kbuild in order to keep the
> > > dependencies optional?
> > >
> > > Something that would satisfy the following pseudocode:
> > > if CONFIG_HID_PICOLCD == y
> > > assert(CONFIG_LCD_CLASS_DEVICE != m)
> > >
> >
> > If you don't want the kconfig machinery to do that (it appears that you don't),
> > then I guess that you'll need to expand the source code to handle
> > CONFIG_LCD_CLASS_DEVICE=y and CONFIG_LCD_CLASS_DEVICE=m differently.
> > Or only handle them differently if HID_PICOLCD=y. :(
>
> Below a patch (against 2.6.34-rc3 + Jiri's picolcd branch) which
> should fix above issue keeping the deps optional.
>
> With it it's not yet possible to select the deps from HID menu.
>
> I did a few oldconfig and compile-tests with PICOLCD=y/m and same for
> the deps (not switched FB for those tests).
>
> Bruno
>
>
>
>
>
> HID_PICOLCD should depend on LCD_CLASS_DEVICE, otherwise the
> build fails when HID_PICOLCD=y and LCD_CLASS_DEVICE=m:
>
> hid-picolcd.c:(.text+0x84523f): undefined reference to `lcd_device_unregister'
> hid-picolcd.c:(.text+0x8478ab): undefined reference to `lcd_device_register'
> hid-picolcd.c:(.text+0x84c15f): undefined reference to `lcd_device_unregister'
>
> Reported-by: Randy Dunlap <[email protected]>
> Signed-off-by: Bruno Pr?mont <[email protected]>
>
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index a2ecd83..39df4f5 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -285,6 +285,35 @@ config HID_PICOLCD
> Features that are not (yet) supported:
> - IR
>

All of these user-visible kconfig options need help text also...

> +config HID_PICOLCD_FB
> + bool "Framebuffer support"
> + default !EMBEDDED
> + depends on HID_PICOLCD
> + depends on HID_PICOLCD=FB || FB=y
> + select FB_DEFERRED_IO
> + select FB_SYS_FILLRECT
> + select FB_SYS_COPYAREA
> + select FB_SYS_IMAGEBLIT
> + select FB_SYS_FOPS
> +
> +config HID_PICOLCD_BACKLIGHT
> + bool "Backlight control"
> + default !EMBEDDED
> + depends on HID_PICOLCD
> + depends on HID_PICOLCD=BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=y
> +
> +config HID_PICOLCD_LCD
> + bool "Contrast control"
> + default !EMBEDDED
> + depends on HID_PICOLCD
> + depends on HID_PICOLCD=LCD_CLASS_DEVICE || LCD_CLASS_DEVICE=y
> +
> +config HID_PICOLCD_LEDS
> + bool "GPO via leds class"
> + default !EMBEDDED
> + depends on HID_PICOLCD
> + depends on HID_PICOLCD=LEDS_CLASS || LEDS_CLASS=y
> +
> config HID_QUANTA
> tristate "Quanta Optical Touch"
> depends on USB_HID


---
~Randy

2010-04-07 18:03:50

by Valdis Klētnieks

[permalink] [raw]
Subject: Re: mmotm 2010-04-05-16-09 uploaded

On Mon, 05 Apr 2010 16:09:45 PDT, [email protected] said:
> The mm-of-the-moment snapshot 2010-04-05-16-09 has been uploaded to
>
> http://userweb.kernel.org/~akpm/mmotm/

Seen in dmesg, 2.6.34-rc2-mmotm0323 didn't do this. Tossing it at all the
likely suspects, hopefully somebody will recognize it and save me the
bisecting. ;)

[ 11.488535] ctnetlink v0.93: registering with nfnetlink.
[ 11.488579]
[ 11.488579] ===================================================
[ 11.489529] [ INFO: suspicious rcu_dereference_check() usage. ]
[ 11.489988] ---------------------------------------------------
[ 11.490494] net/netfilter/nf_conntrack_ecache.c:88 invoked rcu_dereference_check() without protection!
[ 11.491024]
[ 11.491024] other info that might help us debug this:
[ 11.491025]
[ 11.492834]
[ 11.492835] rcu_scheduler_active = 1, debug_locks = 0
[ 11.494124] 1 lock held by swapper/1:
[ 11.494776] #0: (nf_ct_ecache_mutex){+.+...}, at: [<ffffffff8148c606>] nf_conntrack_register_notifier+0x1a/0x76
[ 11.495505]
[ 11.495506] stack backtrace:
[ 11.496927] Pid: 1, comm: swapper Not tainted 2.6.34-rc3-mmotm0405 #1
[ 11.497668] Call Trace:
[ 11.498419] [<ffffffff810638c5>] lockdep_rcu_dereference+0xaa/0xb2
[ 11.499185] [<ffffffff8148c629>] nf_conntrack_register_notifier+0x3d/0x76
[ 11.499967] [<ffffffff81b5dd7b>] ctnetlink_init+0x71/0xd5
[ 11.500775] [<ffffffff81b5dd0a>] ? ctnetlink_init+0x0/0xd5
[ 11.501579] [<ffffffff810001ef>] do_one_initcall+0x59/0x14e
[ 11.502396] [<ffffffff81b3268a>] kernel_init+0x144/0x1ce
[ 11.503218] [<ffffffff81003514>] kernel_thread_helper+0x4/0x10
[ 11.504047] [<ffffffff8159cc00>] ? restore_args+0x0/0x30
[ 11.504882] [<ffffffff81b32546>] ? kernel_init+0x0/0x1ce
[ 11.505715] [<ffffffff81003510>] ? kernel_thread_helper+0x0/0x10
[ 11.506636] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 11.507372] TCP bic registered


Attachments:
(No filename) (227.00 B)

2010-04-07 18:31:42

by Bruno Prémont

[permalink] [raw]
Subject: Re: [PATCH mmotm] hid-picolcd: depends on LCD_CLASS_DEVICE

HID_PICOLCD should depend on LCD_CLASS_DEVICE, otherwise the
build fails when HID_PICOLCD=y and LCD_CLASS_DEVICE=m:

hid-picolcd.c:(.text+0x84523f): undefined reference to `lcd_device_unregister'
hid-picolcd.c:(.text+0x8478ab): undefined reference to `lcd_device_register'
hid-picolcd.c:(.text+0x84c15f): undefined reference to `lcd_device_unregister'

Same applies to FB, BACKLIGHT_CLASS_DEVICE and LEDS_CLASS.

Add suboptions for those features to handle the deps on kbuild side
and just check HID_PICOLCD_* in the code.

Reported-by: Randy Dunlap <[email protected]>
Signed-off-by: Bruno Prémont <[email protected]>
---

On Wed, 07 April 2010 Randy Dunlap <[email protected]> wrote:
> All of these user-visible kconfig options need help text also...
>

Here is a better patch, with added documentation and stripped
select clauses under HID_PICOLCD as they are handled by HID_PICOLCD_FB.




drivers/hid/Kconfig | 53 +++++++++++++++++++++++++++++++++++++-------
drivers/hid/hid-picolcd.c | 40 +++++++++++++++++-----------------
2 files changed, 64 insertions(+), 29 deletions(-)

diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index a2ecd83..782a34e 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -265,11 +265,6 @@ config HID_PETALYNX
config HID_PICOLCD
tristate "PicoLCD (graphic version)"
depends on USB_HID
- select FB_DEFERRED_IO if FB
- select FB_SYS_FILLRECT if FB
- select FB_SYS_COPYAREA if FB
- select FB_SYS_IMAGEBLIT if FB
- select FB_SYS_FOPS if FB
---help---
This provides support for Minibox PicoLCD devices, currently
only the graphical ones are supported.
@@ -277,14 +272,54 @@ config HID_PICOLCD
This includes support for the following device features:
- Keypad
- Switching between Firmware and Flash mode
- - Framebuffer for monochrome 256x64 display
- - Backlight control (needs CONFIG_BACKLIGHT_CLASS_DEVICE)
- - Contrast control (needs CONFIG_LCD_CLASS_DEVICE)
- - General purpose outputs (needs CONFIG_LEDS_CLASS)
- EEProm / Flash access (via debugfs)
+ Features to selectively enable:
+ - Framebuffer for monochrome 256x64 display
+ - Backlight control
+ - Contrast control
+ - General purpose outputs
Features that are not (yet) supported:
- IR

+config HID_PICOLCD_FB
+ bool "Framebuffer support"
+ default !EMBEDDED
+ depends on HID_PICOLCD
+ depends on HID_PICOLCD=FB || FB=y
+ select FB_DEFERRED_IO
+ select FB_SYS_FILLRECT
+ select FB_SYS_COPYAREA
+ select FB_SYS_IMAGEBLIT
+ select FB_SYS_FOPS
+ ---help---
+ Provide access to PicoLCD's 256x64 monochrome display via a
+ frambuffer device.
+
+config HID_PICOLCD_BACKLIGHT
+ bool "Backlight control"
+ default !EMBEDDED
+ depends on HID_PICOLCD
+ depends on HID_PICOLCD=BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=y
+ ---help---
+ Provide access to PicoLCD's backlight control via backlight
+ class.
+
+config HID_PICOLCD_LCD
+ bool "Contrast control"
+ default !EMBEDDED
+ depends on HID_PICOLCD
+ depends on HID_PICOLCD=LCD_CLASS_DEVICE || LCD_CLASS_DEVICE=y
+ ---help---
+ Provide access to PicoLCD's LCD contrast via lcd class.
+
+config HID_PICOLCD_LEDS
+ bool "GPO via leds class"
+ default !EMBEDDED
+ depends on HID_PICOLCD
+ depends on HID_PICOLCD=LEDS_CLASS || LEDS_CLASS=y
+ ---help---
+ Provide access to PicoLCD's GPO pins via leds class.
+
config HID_QUANTA
tristate "Quanta Optical Touch"
depends on USB_HID
diff --git a/drivers/hid/hid-picolcd.c b/drivers/hid/hid-picolcd.c
index 0eacc6b..0fbc7d3 100644
--- a/drivers/hid/hid-picolcd.c
+++ b/drivers/hid/hid-picolcd.c
@@ -77,7 +77,7 @@
#define REPORT_HOOK_VERSION 0xf7 /* LCD: IN[2], OUT[1] */
#define REPORT_EXIT_FLASHER 0xff /* Bootloader: OUT[2] */

-#if defined(CONFIG_FB) || defined(CONFIG_FB_MODULE)
+#ifdef CONFIG_HID_PICOLCD_FB
/* Framebuffer
*
* The PicoLCD use a Topway LCD module of 256x64 pixel
@@ -128,7 +128,7 @@ static const struct fb_var_screeninfo picolcdfb_var = {
.bits_per_pixel = 1,
.grayscale = 1,
};
-#endif /* CONFIG_FB */
+#endif /* CONFIG_HID_PICOLCD_FB */

/* Input device
*
@@ -183,7 +183,7 @@ struct picolcd_data {
struct input_dev *input_cir;
unsigned short keycode[PICOLCD_KEYS];

-#if defined(CONFIG_FB) || defined(CONFIG_FB_MODULE)
+#ifdef CONFIG_HID_PICOLCD_FB
/* Framebuffer stuff */
u8 fb_update_rate;
u8 fb_bpp;
@@ -191,21 +191,21 @@ struct picolcd_data {
u8 *fb_bitmap; /* framebuffer */
struct fb_info *fb_info;
struct fb_deferred_io fb_defio;
-#endif /* CONFIG_FB */
-#if defined(CONFIG_LCD_CLASS_DEVICE) || defined(CONFIG_LCD_CLASS_DEVICE_MODULE)
+#endif /* CONFIG_HID_PICOLCD_FB */
+#ifdef CONFIG_HID_PICOLCD_LCD
struct lcd_device *lcd;
u8 lcd_contrast;
-#endif
-#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) || defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE)
+#endif /* CONFIG_HID_PICOLCD_LCD */
+#ifdef CONFIG_HID_PICOLCD_BACKLIGHT
struct backlight_device *backlight;
u8 lcd_brightness;
u8 lcd_power;
-#endif /* CONFIG_BACKLIGHT_CLASS_DEVICE */
-#if defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE)
+#endif /* CONFIG_HID_PICOLCD_BACKLIGHT */
+#ifdef CONFIG_HID_PICOLCD_LEDS
/* LED stuff */
u8 led_state;
struct led_classdev *led[8];
-#endif /* CONFIG_LEDS_CLASS */
+#endif /* CONFIG_HID_PICOLCD_LEDS */

/* Housekeeping stuff */
spinlock_t lock;
@@ -287,7 +287,7 @@ static struct picolcd_pending *picolcd_send_and_wait(struct hid_device *hdev,
return work;
}

-#if defined(CONFIG_FB) || defined(CONFIG_FB_MODULE)
+#ifdef CONFIG_HID_PICOLCD_FB
/* Send a given tile to PicoLCD */
static int picolcd_fb_send_tile(struct hid_device *hdev, int chip, int tile)
{
@@ -766,9 +766,9 @@ static void picolcd_exit_framebuffer(struct picolcd_data *data)
{
}
#define picolcd_fbinfo(d) NULL
-#endif /* CONFIG_FB */
+#endif /* CONFIG_HID_PICOLCD_FB */

-#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) || defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE)
+#ifdef CONFIG_HID_PICOLCD_BACKLIGHT
/*
* backlight class device
*/
@@ -864,9 +864,9 @@ static inline int picolcd_resume_backlight(struct picolcd_data *data)
{
return 0;
}
-#endif /* CONFIG_BACKLIGHT_CLASS_DEVICE */
+#endif /* CONFIG_HID_PICOLCD_BACKLIGHT */

-#if defined(CONFIG_LCD_CLASS_DEVICE) || defined(CONFIG_LCD_CLASS_DEVICE_MODULE)
+#ifdef CONFIG_HID_PICOLCD_LCD
/*
* lcd class device
*/
@@ -957,9 +957,9 @@ static inline int picolcd_resume_lcd(struct picolcd_data *data)
{
return 0;
}
-#endif /* CONFIG_LCD_CLASS_DEVICE */
+#endif /* CONFIG_HID_PICOLCD_LCD */

-#if defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE)
+#ifdef CONFIG_HID_PICOLCD_LEDS
/**
* LED class device
*/
@@ -1104,7 +1104,7 @@ static inline int picolcd_leds_set(struct picolcd_data *data)
{
return 0;
}
-#endif /* CONFIG_LEDS_CLASS */
+#endif /* CONFIG_HID_PICOLCD_LEDS */

/*
* input class device
@@ -1243,10 +1243,10 @@ static int picolcd_reset(struct hid_device *hdev)

picolcd_resume_lcd(data);
picolcd_resume_backlight(data);
-#if defined(CONFIG_FB) || defined(CONFIG_FB_MODULE)
+#ifdef CONFIG_HID_PICOLCD_FB
if (data->fb_info)
schedule_delayed_work(&data->fb_info->deferred_work, 0);
-#endif /* CONFIG_FB */
+#endif /* CONFIG_HID_PICOLCD_FB */

picolcd_leds_set(data);
return 0;
--
1.6.4.4

2010-04-07 18:44:13

by Bruno Prémont

[permalink] [raw]
Subject: Re: [PATCH mmotm] hid-picolcd: depends on LCD_CLASS_DEVICE

On Tue, 06 April 2010 Randy Dunlap <[email protected]> wrote:
> >
> > One of my attempts did end up with a circular loop with regard to FB
> > (some of the FB drivers did select INPUT)?
>
> (not that I can find)
>
> CONFIG_VT does select INPUT
> and CONFIG_DRM_I915 does
> select INPUT if ACPI

A newer attempt still produces the same result:

drivers/input/Kconfig:9:error: found recursive dependency: INPUT ->
HID_SUPPORT -> HID_PICOLCD_FB -> FB -> FB_STI -> VT -> INPUT

(it's only FB which causes the loop, LEDS, LCD and BACKLIGHT are fine)

This is with following patch on top of the improved deps patch I sent
a few minutes ago deeper in this thread.

Is there a way around this?


diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 782a34e..711c091 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -285,7 +285,7 @@ config HID_PICOLCD_FB
bool "Framebuffer support"
default !EMBEDDED
depends on HID_PICOLCD
- depends on HID_PICOLCD=FB || FB=y
+ select FB
select FB_DEFERRED_IO
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
@@ -299,7 +299,8 @@ config HID_PICOLCD_BACKLIGHT
bool "Backlight control"
default !EMBEDDED
depends on HID_PICOLCD
- depends on HID_PICOLCD=BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=y
+ select BACKLIGHT_LCD_SUPPORT
+ select BACKLIGHT_CLASS_DEVICE
---help---
Provide access to PicoLCD's backlight control via backlight
class.
@@ -308,7 +309,8 @@ config HID_PICOLCD_LCD
bool "Contrast control"
default !EMBEDDED
depends on HID_PICOLCD
- depends on HID_PICOLCD=LCD_CLASS_DEVICE || LCD_CLASS_DEVICE=y
+ select BACKLIGHT_LCD_SUPPORT
+ select LCD_CLASS_DEVICE
---help---
Provide access to PicoLCD's LCD contrast via lcd class.

@@ -316,7 +318,8 @@ config HID_PICOLCD_LEDS
bool "GPO via leds class"
default !EMBEDDED
depends on HID_PICOLCD
- depends on HID_PICOLCD=LEDS_CLASS || LEDS_CLASS=y
+ select NEW_LEDS
+ select LEDS_CLASS
---help---
Provide access to PicoLCD's GPO pins via leds class.

2010-04-07 20:13:15

by Randy Dunlap

[permalink] [raw]
Subject: Re: [PATCH mmotm] hid-picolcd: depends on LCD_CLASS_DEVICE

On Wed, 7 Apr 2010 20:44:04 +0200 Bruno Pr?mont wrote:

> On Tue, 06 April 2010 Randy Dunlap <[email protected]> wrote:
> > >
> > > One of my attempts did end up with a circular loop with regard to FB
> > > (some of the FB drivers did select INPUT)?
> >
> > (not that I can find)
> >
> > CONFIG_VT does select INPUT
> > and CONFIG_DRM_I915 does
> > select INPUT if ACPI
>
> A newer attempt still produces the same result:
>
> drivers/input/Kconfig:9:error: found recursive dependency: INPUT ->
> HID_SUPPORT -> HID_PICOLCD_FB -> FB -> FB_STI -> VT -> INPUT
>
> (it's only FB which causes the loop, LEDS, LCD and BACKLIGHT are fine)

(yes, so I see)

> This is with following patch on top of the improved deps patch I sent
> a few minutes ago deeper in this thread.
>
> Is there a way around this?
>

Well, lesson #1 is that select is evil^W^W should only be used to enable
library-like code, or as Documentation/kbuild/kconfig-language.txt says:

Note:
select should be used with care. select will force
a symbol to a value without visiting the dependencies.
By abusing select you are able to select a symbol FOO even
if FOO depends on BAR that is not set.
In general use select only for non-visible symbols
(no prompts anywhere) and for symbols with no dependencies.
That will limit the usefulness but on the other hand avoid
the illegal configurations all over.
kconfig should one day warn about such things.



(more below)

>
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index 782a34e..711c091 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -285,7 +285,7 @@ config HID_PICOLCD_FB
> bool "Framebuffer support"
> default !EMBEDDED
> depends on HID_PICOLCD
> - depends on HID_PICOLCD=FB || FB=y
> + select FB

If you'll go back to the unpatched (by this patch) version here,
it seems to work OK.

> select FB_DEFERRED_IO
> select FB_SYS_FILLRECT
> select FB_SYS_COPYAREA
> @@ -299,7 +299,8 @@ config HID_PICOLCD_BACKLIGHT
> bool "Backlight control"
> default !EMBEDDED
> depends on HID_PICOLCD
> - depends on HID_PICOLCD=BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=y
> + select BACKLIGHT_LCD_SUPPORT
> + select BACKLIGHT_CLASS_DEVICE
> ---help---
> Provide access to PicoLCD's backlight control via backlight
> class.
> @@ -308,7 +309,8 @@ config HID_PICOLCD_LCD
> bool "Contrast control"
> default !EMBEDDED
> depends on HID_PICOLCD
> - depends on HID_PICOLCD=LCD_CLASS_DEVICE || LCD_CLASS_DEVICE=y
> + select BACKLIGHT_LCD_SUPPORT
> + select LCD_CLASS_DEVICE
> ---help---
> Provide access to PicoLCD's LCD contrast via lcd class.
>
> @@ -316,7 +318,8 @@ config HID_PICOLCD_LEDS
> bool "GPO via leds class"
> default !EMBEDDED
> depends on HID_PICOLCD
> - depends on HID_PICOLCD=LEDS_CLASS || LEDS_CLASS=y
> + select NEW_LEDS
> + select LEDS_CLASS
> ---help---
> Provide access to PicoLCD's GPO pins via leds class.


---
~Randy

2010-04-07 20:29:45

by Bruno Prémont

[permalink] [raw]
Subject: Re: [PATCH mmotm] hid-picolcd: depends on LCD_CLASS_DEVICE

On Wed, 07 April 2010 Randy Dunlap <[email protected]> wrote:
> On Wed, 7 Apr 2010 20:44:04 +0200 Bruno Prémont wrote:
>
> > On Tue, 06 April 2010 Randy Dunlap <[email protected]> wrote:
> > > >
> > > > One of my attempts did end up with a circular loop with regard to FB
> > > > (some of the FB drivers did select INPUT)?
> > >
> > > (not that I can find)
> > >
> > > CONFIG_VT does select INPUT
> > > and CONFIG_DRM_I915 does
> > > select INPUT if ACPI
> >
> > A newer attempt still produces the same result:
> >
> > drivers/input/Kconfig:9:error: found recursive dependency: INPUT ->
> > HID_SUPPORT -> HID_PICOLCD_FB -> FB -> FB_STI -> VT -> INPUT
> >
> > (it's only FB which causes the loop, LEDS, LCD and BACKLIGHT are fine)
>
> (yes, so I see)
>
> > This is with following patch on top of the improved deps patch I sent
> > a few minutes ago deeper in this thread.
> >
> > Is there a way around this?
> >
>
> Well, lesson #1 is that select is evil^W^W should only be used to enable
> library-like code, or as Documentation/kbuild/kconfig-language.txt says:
>
> Note:
> select should be used with care. select will force
> a symbol to a value without visiting the dependencies.
> By abusing select you are able to select a symbol FOO even
> if FOO depends on BAR that is not set.
> In general use select only for non-visible symbols
> (no prompts anywhere) and for symbols with no dependencies.
> That will limit the usefulness but on the other hand avoid
> the illegal configurations all over.
> kconfig should one day warn about such things.

I've read that paragraph and I would definitely prefer not to have to
use select for what this patch should achieve!

It should really be a helper for the user going through menuconfig like
"please check all what is needed to satisfy this item's dependencies"
A "try-select-deep" or whatever it could be called.

A well-behaved "GUI" implementation of this would show what would get newly
checked and give the user the opportunity to not proceed or fine-tune
y/m choices.

> (more below)
>
> >
> > diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> > index 782a34e..711c091 100644
> > --- a/drivers/hid/Kconfig
> > +++ b/drivers/hid/Kconfig
> > @@ -285,7 +285,7 @@ config HID_PICOLCD_FB
> > bool "Framebuffer support"
> > default !EMBEDDED
> > depends on HID_PICOLCD
> > - depends on HID_PICOLCD=FB || FB=y
> > + select FB
>
> If you'll go back to the unpatched (by this patch) version here,
> it seems to work OK.

So best is probably to just forget about all of this non-leaf select
usage for now. (and not have one half doing one way and the other half
doing it the other way)

Thanks,
Bruno

2010-04-08 11:41:07

by Patrick McHardy

[permalink] [raw]
Subject: Re: mmotm 2010-04-05-16-09 uploaded

diff --git a/net/netfilter/nf_conntrack_ecache.c b/net/netfilter/nf_conntrack_ecache.c
index d5a9bcd..849614a 100644
--- a/net/netfilter/nf_conntrack_ecache.c
+++ b/net/netfilter/nf_conntrack_ecache.c
@@ -81,11 +81,9 @@ EXPORT_SYMBOL_GPL(nf_ct_deliver_cached_events);
int nf_conntrack_register_notifier(struct nf_ct_event_notifier *new)
{
int ret = 0;
- struct nf_ct_event_notifier *notify;

mutex_lock(&nf_ct_ecache_mutex);
- notify = rcu_dereference(nf_conntrack_event_cb);
- if (notify != NULL) {
+ if (nf_conntrack_event_cb != NULL) {
ret = -EBUSY;
goto out_unlock;
}
@@ -101,11 +99,8 @@ EXPORT_SYMBOL_GPL(nf_conntrack_register_notifier);

void nf_conntrack_unregister_notifier(struct nf_ct_event_notifier *new)
{
- struct nf_ct_event_notifier *notify;
-
mutex_lock(&nf_ct_ecache_mutex);
- notify = rcu_dereference(nf_conntrack_event_cb);
- BUG_ON(notify != new);
+ BUG_ON(nf_conntrack_event_cb != new);
rcu_assign_pointer(nf_conntrack_event_cb, NULL);
mutex_unlock(&nf_ct_ecache_mutex);
}
@@ -114,11 +109,9 @@ EXPORT_SYMBOL_GPL(nf_conntrack_unregister_notifier);
int nf_ct_expect_register_notifier(struct nf_exp_event_notifier *new)
{
int ret = 0;
- struct nf_exp_event_notifier *notify;

mutex_lock(&nf_ct_ecache_mutex);
- notify = rcu_dereference(nf_expect_event_cb);
- if (notify != NULL) {
+ if (nf_expect_event_cb != NULL) {
ret = -EBUSY;
goto out_unlock;
}
@@ -134,11 +127,8 @@ EXPORT_SYMBOL_GPL(nf_ct_expect_register_notifier);

void nf_ct_expect_unregister_notifier(struct nf_exp_event_notifier *new)
{
- struct nf_exp_event_notifier *notify;
-
mutex_lock(&nf_ct_ecache_mutex);
- notify = rcu_dereference(nf_expect_event_cb);
- BUG_ON(notify != new);
+ BUG_ON(nf_expect_event_cb != new);
rcu_assign_pointer(nf_expect_event_cb, NULL);
mutex_unlock(&nf_ct_ecache_mutex);
}


Attachments:
x (1.79 kB)

2010-04-08 12:42:58

by Jiri Kosina

[permalink] [raw]
Subject: Re: [PATCH mmotm] hid-picolcd: depends on LCD_CLASS_DEVICE

On Wed, 7 Apr 2010, Bruno Prémont wrote:

> HID_PICOLCD should depend on LCD_CLASS_DEVICE, otherwise the
> build fails when HID_PICOLCD=y and LCD_CLASS_DEVICE=m:
>
> hid-picolcd.c:(.text+0x84523f): undefined reference to `lcd_device_unregister'
> hid-picolcd.c:(.text+0x8478ab): undefined reference to `lcd_device_register'
> hid-picolcd.c:(.text+0x84c15f): undefined reference to `lcd_device_unregister'
>
> Same applies to FB, BACKLIGHT_CLASS_DEVICE and LEDS_CLASS.
>
> Add suboptions for those features to handle the deps on kbuild side
> and just check HID_PICOLCD_* in the code.
>
> Reported-by: Randy Dunlap <[email protected]>
> Signed-off-by: Bruno Prémont <[email protected]>
> ---
>
> On Wed, 07 April 2010 Randy Dunlap <[email protected]> wrote:
> > All of these user-visible kconfig options need help text also...
> >
>
> Here is a better patch, with added documentation and stripped
> select clauses under HID_PICOLCD as they are handled by HID_PICOLCD_FB.
>
>
>
>
> drivers/hid/Kconfig | 53 +++++++++++++++++++++++++++++++++++++-------
> drivers/hid/hid-picolcd.c | 40 +++++++++++++++++-----------------
> 2 files changed, 64 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index a2ecd83..782a34e 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -265,11 +265,6 @@ config HID_PETALYNX
> config HID_PICOLCD
> tristate "PicoLCD (graphic version)"
> depends on USB_HID
> - select FB_DEFERRED_IO if FB
> - select FB_SYS_FILLRECT if FB
> - select FB_SYS_COPYAREA if FB
> - select FB_SYS_IMAGEBLIT if FB
> - select FB_SYS_FOPS if FB
> ---help---
> This provides support for Minibox PicoLCD devices, currently
> only the graphical ones are supported.
> @@ -277,14 +272,54 @@ config HID_PICOLCD
> This includes support for the following device features:
> - Keypad
> - Switching between Firmware and Flash mode
> - - Framebuffer for monochrome 256x64 display
> - - Backlight control (needs CONFIG_BACKLIGHT_CLASS_DEVICE)
> - - Contrast control (needs CONFIG_LCD_CLASS_DEVICE)
> - - General purpose outputs (needs CONFIG_LEDS_CLASS)
> - EEProm / Flash access (via debugfs)
> + Features to selectively enable:
> + - Framebuffer for monochrome 256x64 display
> + - Backlight control
> + - Contrast control
> + - General purpose outputs
> Features that are not (yet) supported:
> - IR
>
> +config HID_PICOLCD_FB
> + bool "Framebuffer support"
> + default !EMBEDDED
> + depends on HID_PICOLCD
> + depends on HID_PICOLCD=FB || FB=y
> + select FB_DEFERRED_IO
> + select FB_SYS_FILLRECT
> + select FB_SYS_COPYAREA
> + select FB_SYS_IMAGEBLIT
> + select FB_SYS_FOPS

Could we perhaps also make the sub-choices for individual features
availabel only if !EMBEDDED as well?

It's probably too much to ask for a single device during oldconfig run,
for example ...

Thanks,

--
Jiri Kosina
SUSE Labs, Novell Inc.

2010-04-08 15:25:16

by Valdis Klētnieks

[permalink] [raw]
Subject: Re: mmotm 2010-04-05-16-09 uploaded

On Thu, 08 Apr 2010 13:41:00 +0200, Patrick McHardy said:

> [email protected] wrote:
> > On Mon, 05 Apr 2010 16:09:45 PDT, [email protected] said:
> >> The mm-of-the-moment snapshot 2010-04-05-16-09 has been uploaded to
> >>
> >> http://userweb.kernel.org/~akpm/mmotm/
> >
> > Seen in dmesg, 2.6.34-rc2-mmotm0323 didn't do this. Tossing it at all the
> > likely suspects, hopefully somebody will recognize it and save me the
> > bisecting. ;)
> >
> > [ 11.488535] ctnetlink v0.93: registering with nfnetlink.
> > [ 11.488579]
> > [ 11.488579] ===================================================
> > [ 11.489529] [ INFO: suspicious rcu_dereference_check() usage. ]
> > [ 11.489988] ---------------------------------------------------
> > [ 11.490494] net/netfilter/nf_conntrack_ecache.c:88 invoked rcu_dereference_check() without protection!
> > [ 11.491024]
> > [ 11.491024] other info that might help us debug this:
> > [ 11.491025]
> > [ 11.492834]
> > [ 11.492835] rcu_scheduler_active = 1, debug_locks = 0
> > [ 11.494124] 1 lock held by swapper/1:
> > [ 11.494776] #0: (nf_ct_ecache_mutex){+.+...}, at: [<ffffffff8148c606>] nf_conntrack_register_notifier+0x1a/0x76
> > [ 11.495505]
>
> There are some unnecessary rcu_dereference() calls in the conntrack
> notifier registration and unregistration functions.
>
> Does this fix it?

Well, it *changed* it. Does the rcu_defererence_check() only fire on the
first time it hits something, so we've fixed the first one and now we get to
see the second one?

(For what it's worth, if this is going to be one-at-a-time whack-a-mole, I'm
OK on that, just want to know up front.)

[ 9.299425] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 9.299486]
[ 9.299486] ===================================================
[ 9.300499] [ INFO: suspicious rcu_dereference_check() usage. ]
[ 9.301001] ---------------------------------------------------
[ 9.301523] net/netfilter/nf_log.c:55 invoked rcu_dereference_check() without protection!
[ 9.302066]
[ 9.302066] other info that might help us debug this:
[ 9.302067]
[ 9.303748]
[ 9.303748] rcu_scheduler_active = 1, debug_locks = 0
[ 9.304990] 1 lock held by swapper/1:
[ 9.305645] #0: (nf_log_mutex){+.+...}, at: [<ffffffff8148427a>] nf_log_register+0x57/0x111
[ 9.306342]
[ 9.306343] stack backtrace:
[ 9.307729] Pid: 1, comm: swapper Not tainted 2.6.34-rc3-mmotm0405 #2
[ 9.308447] Call Trace:
[ 9.309170] [<ffffffff810638c5>] lockdep_rcu_dereference+0xaa/0xb2
[ 9.309935] [<ffffffff81484301>] nf_log_register+0xde/0x111
[ 9.310688] [<ffffffff81b6064b>] ? log_tg_init+0x0/0x29
[ 9.311465] [<ffffffff81b60670>] log_tg_init+0x25/0x29
[ 9.312233] [<ffffffff810001ef>] do_one_initcall+0x59/0x14e
[ 9.313030] [<ffffffff81b3268a>] kernel_init+0x144/0x1ce
[ 9.313819] [<ffffffff81003514>] kernel_thread_helper+0x4/0x10
[ 9.314625] [<ffffffff8159cb80>] ? restore_args+0x0/0x30
[ 9.315434] [<ffffffff81b32546>] ? kernel_init+0x0/0x1ce
[ 9.316224] [<ffffffff81003510>] ? kernel_thread_helper+0x0/0x10
[ 9.317037] TCP bic registered


Attachments:
(No filename) (227.00 B)

2010-04-08 15:36:13

by Patrick McHardy

[permalink] [raw]
Subject: Re: mmotm 2010-04-05-16-09 uploaded

diff --git a/net/netfilter/nf_conntrack_ecache.c b/net/netfilter/nf_conntrack_ecache.c
index d5a9bcd..849614a 100644
--- a/net/netfilter/nf_conntrack_ecache.c
+++ b/net/netfilter/nf_conntrack_ecache.c
@@ -81,11 +81,9 @@ EXPORT_SYMBOL_GPL(nf_ct_deliver_cached_events);
int nf_conntrack_register_notifier(struct nf_ct_event_notifier *new)
{
int ret = 0;
- struct nf_ct_event_notifier *notify;

mutex_lock(&nf_ct_ecache_mutex);
- notify = rcu_dereference(nf_conntrack_event_cb);
- if (notify != NULL) {
+ if (nf_conntrack_event_cb != NULL) {
ret = -EBUSY;
goto out_unlock;
}
@@ -101,11 +99,8 @@ EXPORT_SYMBOL_GPL(nf_conntrack_register_notifier);

void nf_conntrack_unregister_notifier(struct nf_ct_event_notifier *new)
{
- struct nf_ct_event_notifier *notify;
-
mutex_lock(&nf_ct_ecache_mutex);
- notify = rcu_dereference(nf_conntrack_event_cb);
- BUG_ON(notify != new);
+ BUG_ON(nf_conntrack_event_cb != new);
rcu_assign_pointer(nf_conntrack_event_cb, NULL);
mutex_unlock(&nf_ct_ecache_mutex);
}
@@ -114,11 +109,9 @@ EXPORT_SYMBOL_GPL(nf_conntrack_unregister_notifier);
int nf_ct_expect_register_notifier(struct nf_exp_event_notifier *new)
{
int ret = 0;
- struct nf_exp_event_notifier *notify;

mutex_lock(&nf_ct_ecache_mutex);
- notify = rcu_dereference(nf_expect_event_cb);
- if (notify != NULL) {
+ if (nf_expect_event_cb != NULL) {
ret = -EBUSY;
goto out_unlock;
}
@@ -134,11 +127,8 @@ EXPORT_SYMBOL_GPL(nf_ct_expect_register_notifier);

void nf_ct_expect_unregister_notifier(struct nf_exp_event_notifier *new)
{
- struct nf_exp_event_notifier *notify;
-
mutex_lock(&nf_ct_ecache_mutex);
- notify = rcu_dereference(nf_expect_event_cb);
- BUG_ON(notify != new);
+ BUG_ON(nf_expect_event_cb != new);
rcu_assign_pointer(nf_expect_event_cb, NULL);
mutex_unlock(&nf_ct_ecache_mutex);
}
diff --git a/net/netfilter/nf_log.c b/net/netfilter/nf_log.c
index 015725a..908f599 100644
--- a/net/netfilter/nf_log.c
+++ b/net/netfilter/nf_log.c
@@ -35,7 +35,6 @@ static struct nf_logger *__find_logger(int pf, const char *str_logger)
/* return EEXIST if the same logger is registred, 0 on success. */
int nf_log_register(u_int8_t pf, struct nf_logger *logger)
{
- const struct nf_logger *llog;
int i;

if (pf >= ARRAY_SIZE(nf_loggers))
@@ -52,8 +51,7 @@ int nf_log_register(u_int8_t pf, struct nf_logger *logger)
} else {
/* register at end of list to honor first register win */
list_add_tail(&logger->list[pf], &nf_loggers_l[pf]);
- llog = rcu_dereference(nf_loggers[pf]);
- if (llog == NULL)
+ if (nf_loggers[pf] == NULL)
rcu_assign_pointer(nf_loggers[pf], logger);
}

@@ -65,13 +63,11 @@ EXPORT_SYMBOL(nf_log_register);

void nf_log_unregister(struct nf_logger *logger)
{
- const struct nf_logger *c_logger;
int i;

mutex_lock(&nf_log_mutex);
for (i = 0; i < ARRAY_SIZE(nf_loggers); i++) {
- c_logger = rcu_dereference(nf_loggers[i]);
- if (c_logger == logger)
+ if (nf_loggers[i] == logger)
rcu_assign_pointer(nf_loggers[i], NULL);
list_del(&logger->list[i]);
}


Attachments:
x (2.98 kB)

2010-04-08 23:58:07

by Valdis Klētnieks

[permalink] [raw]
Subject: mmotm 2010-04-05 - another RCU whinge (not network this time)

On Mon, 05 Apr 2010 16:09:45 PDT, [email protected] said:
> The mm-of-the-moment snapshot 2010-04-05-16-09 has been uploaded to
>
> http://userweb.kernel.org/~akpm/mmotm/

Hit another one. I seem to be on a roll...

Seen in dmesg, happened near end of the initrd..

[ 26.756864]
[ 26.756866] ===================================================
[ 26.756869] [ INFO: suspicious rcu_dereference_check() usage. ]
[ 26.756871] ---------------------------------------------------
[ 26.756874] fs/proc/array.c:241 invoked rcu_dereference_check() without protection!
[ 26.756876]
[ 26.756877] other info that might help us debug this:
[ 26.756877]
[ 26.756879]
[ 26.756880] rcu_scheduler_active = 1, debug_locks = 0
[ 26.756883] 2 locks held by pidof/2197:
[ 26.756884] #0: (&p->lock){+.+.+.}, at: [<ffffffff810f4c2a>] seq_read+0x3a/0x42d
[ 26.756894] #1: (&(&sighand->siglock)->rlock){......}, at: [<ffffffff81047eff>] lock_task_sighand+0x79/0xcf
[ 26.756903]
[ 26.756903] stack backtrace:
[ 26.756906] Pid: 2197, comm: pidof Not tainted 2.6.34-rc3-mmotm0405 #3
[ 26.756909] Call Trace:
[ 26.756914] [<ffffffff810638c5>] lockdep_rcu_dereference+0xaa/0xb2
[ 26.756919] [<ffffffff8112ed88>] collect_sigign_sigcatch+0x37/0xa0
[ 26.756923] [<ffffffff8112f066>] do_task_stat+0x275/0x837
[ 26.756927] [<ffffffff81063f83>] ? mark_held_locks+0x52/0x70
[ 26.756931] [<ffffffff810af6be>] ? get_page_from_freelist+0x390/0x5ab
[ 26.756935] [<ffffffff81062e7b>] ? register_lock_class+0x1e/0x325
[ 26.756938] [<ffffffff8106421a>] ? trace_hardirqs_on+0xd/0xf
[ 26.756942] [<ffffffff810af742>] ? get_page_from_freelist+0x414/0x5ab
[ 26.756946] [<ffffffff81063d32>] ? mark_lock+0x2d/0x22c
[ 26.756949] [<ffffffff81063d32>] ? mark_lock+0x2d/0x22c
[ 26.756953] [<ffffffff81064fe7>] ? __lock_acquire+0x391/0xcfc
[ 26.756956] [<ffffffff810b006f>] ? __alloc_pages_nodemask+0x796/0x823
[ 26.756961] [<ffffffff810d4e60>] ? ____cache_alloc+0x10a/0x5cb
[ 26.756964] [<ffffffff810d4e60>] ? ____cache_alloc+0x10a/0x5cb
[ 26.756969] [<ffffffff8159f84c>] ? sub_preempt_count+0x35/0x49
[ 26.756973] [<ffffffff8112f637>] proc_tgid_stat+0xf/0x11
[ 26.756977] [<ffffffff8112c005>] proc_single_show+0x57/0x74
[ 26.756980] [<ffffffff810f4ca1>] ? seq_read+0xb1/0x42d
[ 26.756983] [<ffffffff810f4dc3>] seq_read+0x1d3/0x42d
[ 26.756988] [<ffffffff810da357>] vfs_read+0xe0/0x140
[ 26.756991] [<ffffffff810da46d>] sys_read+0x45/0x69
[ 26.756996] [<ffffffff810026eb>] system_call_fastpath+0x16/0x1b
[ 26.788544] dracut: Switching root


Attachments:
(No filename) (227.00 B)

2010-04-09 00:51:43

by Valdis Klētnieks

[permalink] [raw]
Subject: Re: mmotm 2010-04-05-16-09 uploaded

On Thu, 08 Apr 2010 17:36:07 +0200, Patrick McHardy said:

> [email protected] wrote:

> > Well, it *changed* it. Does the rcu_defererence_check() only fire on the
> > first time it hits something, so we've fixed the first one and now we get to
> > see the second one?
>
> It appears that way, otherwise you should have seen a second warning in
> nf_conntrack_ecache the last time.
>
> > (For what it's worth, if this is going to be one-at-a-time whack-a-mole, I'm
> > OK on that, just want to know up front.)
>
> I went through the other files and I believe this should be it.
> We already removed most of these incorrect rcu_dereference()
> calls a while back.

Confirming - the second version of the patch fixes all the network-related
RCU complaints I've been able to trigger...


Attachments:
(No filename) (227.00 B)

2010-04-09 14:49:19

by Patrick McHardy

[permalink] [raw]
Subject: Re: mmotm 2010-04-05-16-09 uploaded

>From ed86308f6179d8fa6151c2d0f652aad0091548e2 Mon Sep 17 00:00:00 2001
From: Patrick McHardy <[email protected]>
Date: Fri, 9 Apr 2010 16:42:15 +0200
Subject: [PATCH] netfilter: remove invalid rcu_dereference() calls

The CONFIG_PROVE_RCU option discovered a few invalid uses of
rcu_dereference() in netfilter. In all these cases, the code code
intends to check whether a pointer is already assigned when
performing registration or whether the assigned pointer matches
when performing unregistration. The entire registration/
unregistration is protected by a mutex, so we don't need the
rcu_dereference() calls.

Reported-by: Valdis Kletnieks <[email protected]>
Tested-by: Valdis Kletnieks <[email protected]>
Signed-off-by: Patrick McHardy <[email protected]>
---
net/netfilter/nf_conntrack_ecache.c | 18 ++++--------------
net/netfilter/nf_log.c | 8 ++------
2 files changed, 6 insertions(+), 20 deletions(-)

diff --git a/net/netfilter/nf_conntrack_ecache.c b/net/netfilter/nf_conntrack_ecache.c
index d5a9bcd..849614a 100644
--- a/net/netfilter/nf_conntrack_ecache.c
+++ b/net/netfilter/nf_conntrack_ecache.c
@@ -81,11 +81,9 @@ EXPORT_SYMBOL_GPL(nf_ct_deliver_cached_events);
int nf_conntrack_register_notifier(struct nf_ct_event_notifier *new)
{
int ret = 0;
- struct nf_ct_event_notifier *notify;

mutex_lock(&nf_ct_ecache_mutex);
- notify = rcu_dereference(nf_conntrack_event_cb);
- if (notify != NULL) {
+ if (nf_conntrack_event_cb != NULL) {
ret = -EBUSY;
goto out_unlock;
}
@@ -101,11 +99,8 @@ EXPORT_SYMBOL_GPL(nf_conntrack_register_notifier);

void nf_conntrack_unregister_notifier(struct nf_ct_event_notifier *new)
{
- struct nf_ct_event_notifier *notify;
-
mutex_lock(&nf_ct_ecache_mutex);
- notify = rcu_dereference(nf_conntrack_event_cb);
- BUG_ON(notify != new);
+ BUG_ON(nf_conntrack_event_cb != new);
rcu_assign_pointer(nf_conntrack_event_cb, NULL);
mutex_unlock(&nf_ct_ecache_mutex);
}
@@ -114,11 +109,9 @@ EXPORT_SYMBOL_GPL(nf_conntrack_unregister_notifier);
int nf_ct_expect_register_notifier(struct nf_exp_event_notifier *new)
{
int ret = 0;
- struct nf_exp_event_notifier *notify;

mutex_lock(&nf_ct_ecache_mutex);
- notify = rcu_dereference(nf_expect_event_cb);
- if (notify != NULL) {
+ if (nf_expect_event_cb != NULL) {
ret = -EBUSY;
goto out_unlock;
}
@@ -134,11 +127,8 @@ EXPORT_SYMBOL_GPL(nf_ct_expect_register_notifier);

void nf_ct_expect_unregister_notifier(struct nf_exp_event_notifier *new)
{
- struct nf_exp_event_notifier *notify;
-
mutex_lock(&nf_ct_ecache_mutex);
- notify = rcu_dereference(nf_expect_event_cb);
- BUG_ON(notify != new);
+ BUG_ON(nf_expect_event_cb != new);
rcu_assign_pointer(nf_expect_event_cb, NULL);
mutex_unlock(&nf_ct_ecache_mutex);
}
diff --git a/net/netfilter/nf_log.c b/net/netfilter/nf_log.c
index 015725a..908f599 100644
--- a/net/netfilter/nf_log.c
+++ b/net/netfilter/nf_log.c
@@ -35,7 +35,6 @@ static struct nf_logger *__find_logger(int pf, const char *str_logger)
/* return EEXIST if the same logger is registred, 0 on success. */
int nf_log_register(u_int8_t pf, struct nf_logger *logger)
{
- const struct nf_logger *llog;
int i;

if (pf >= ARRAY_SIZE(nf_loggers))
@@ -52,8 +51,7 @@ int nf_log_register(u_int8_t pf, struct nf_logger *logger)
} else {
/* register at end of list to honor first register win */
list_add_tail(&logger->list[pf], &nf_loggers_l[pf]);
- llog = rcu_dereference(nf_loggers[pf]);
- if (llog == NULL)
+ if (nf_loggers[pf] == NULL)
rcu_assign_pointer(nf_loggers[pf], logger);
}

@@ -65,13 +63,11 @@ EXPORT_SYMBOL(nf_log_register);

void nf_log_unregister(struct nf_logger *logger)
{
- const struct nf_logger *c_logger;
int i;

mutex_lock(&nf_log_mutex);
for (i = 0; i < ARRAY_SIZE(nf_loggers); i++) {
- c_logger = rcu_dereference(nf_loggers[i]);
- if (c_logger == logger)
+ if (nf_loggers[i] == logger)
rcu_assign_pointer(nf_loggers[i], NULL);
list_del(&logger->list[i]);
}
--
1.7.0.4


Attachments:
x (3.92 kB)

2010-04-09 23:16:24

by Paul E. McKenney

[permalink] [raw]
Subject: Re: mmotm 2010-04-05 - another RCU whinge (not network this time)

On Thu, Apr 08, 2010 at 07:57:28PM -0400, [email protected] wrote:
> On Mon, 05 Apr 2010 16:09:45 PDT, [email protected] said:
> > The mm-of-the-moment snapshot 2010-04-05-16-09 has been uploaded to
> >
> > http://userweb.kernel.org/~akpm/mmotm/
>
> Hit another one. I seem to be on a roll...
>
> Seen in dmesg, happened near end of the initrd..
>
> [ 26.756864]
> [ 26.756866] ===================================================
> [ 26.756869] [ INFO: suspicious rcu_dereference_check() usage. ]
> [ 26.756871] ---------------------------------------------------
> [ 26.756874] fs/proc/array.c:241 invoked rcu_dereference_check() without protection!

Color me confused. I cloned James Toy's git repository at
git://zen-kernel.org/kernel/mmotm.git, and gitk claims that I am on tag
2010-04-05-16-09, which matches the string above. But when I look at
fs/proc/array.c near line 241, I see:

238 static void collect_sigign_sigcatch(struct task_struct *p, sigset_t *ign,
239 sigset_t *catch)
240 {
241 struct k_sigaction *k;
242 int i;
243
244 k = p->sighand->action;
245 for (i = 1; i <= _NSIG; ++i, ++k) {
246 if (k->sa.sa_handler == SIG_IGN)
247 sigaddset(ign, i);
248 else if (k->sa.sa_handler != SIG_DFL)
249 sigaddset(catch, i);
250 }
251 }

It seems unlikely that line 241 generated the above error.

Am I on the wrong version? Or do the git tags not mean what I think
that they mean?

Thanx, Paul

> [ 26.756876]
> [ 26.756877] other info that might help us debug this:
> [ 26.756877]
> [ 26.756879]
> [ 26.756880] rcu_scheduler_active = 1, debug_locks = 0
> [ 26.756883] 2 locks held by pidof/2197:
> [ 26.756884] #0: (&p->lock){+.+.+.}, at: [<ffffffff810f4c2a>] seq_read+0x3a/0x42d
> [ 26.756894] #1: (&(&sighand->siglock)->rlock){......}, at: [<ffffffff81047eff>] lock_task_sighand+0x79/0xcf
> [ 26.756903]
> [ 26.756903] stack backtrace:
> [ 26.756906] Pid: 2197, comm: pidof Not tainted 2.6.34-rc3-mmotm0405 #3
> [ 26.756909] Call Trace:
> [ 26.756914] [<ffffffff810638c5>] lockdep_rcu_dereference+0xaa/0xb2
> [ 26.756919] [<ffffffff8112ed88>] collect_sigign_sigcatch+0x37/0xa0
> [ 26.756923] [<ffffffff8112f066>] do_task_stat+0x275/0x837
> [ 26.756927] [<ffffffff81063f83>] ? mark_held_locks+0x52/0x70
> [ 26.756931] [<ffffffff810af6be>] ? get_page_from_freelist+0x390/0x5ab
> [ 26.756935] [<ffffffff81062e7b>] ? register_lock_class+0x1e/0x325
> [ 26.756938] [<ffffffff8106421a>] ? trace_hardirqs_on+0xd/0xf
> [ 26.756942] [<ffffffff810af742>] ? get_page_from_freelist+0x414/0x5ab
> [ 26.756946] [<ffffffff81063d32>] ? mark_lock+0x2d/0x22c
> [ 26.756949] [<ffffffff81063d32>] ? mark_lock+0x2d/0x22c
> [ 26.756953] [<ffffffff81064fe7>] ? __lock_acquire+0x391/0xcfc
> [ 26.756956] [<ffffffff810b006f>] ? __alloc_pages_nodemask+0x796/0x823
> [ 26.756961] [<ffffffff810d4e60>] ? ____cache_alloc+0x10a/0x5cb
> [ 26.756964] [<ffffffff810d4e60>] ? ____cache_alloc+0x10a/0x5cb
> [ 26.756969] [<ffffffff8159f84c>] ? sub_preempt_count+0x35/0x49
> [ 26.756973] [<ffffffff8112f637>] proc_tgid_stat+0xf/0x11
> [ 26.756977] [<ffffffff8112c005>] proc_single_show+0x57/0x74
> [ 26.756980] [<ffffffff810f4ca1>] ? seq_read+0xb1/0x42d
> [ 26.756983] [<ffffffff810f4dc3>] seq_read+0x1d3/0x42d
> [ 26.756988] [<ffffffff810da357>] vfs_read+0xe0/0x140
> [ 26.756991] [<ffffffff810da46d>] sys_read+0x45/0x69
> [ 26.756996] [<ffffffff810026eb>] system_call_fastpath+0x16/0x1b
> [ 26.788544] dracut: Switching root
>

2010-04-10 03:23:10

by Valdis Klētnieks

[permalink] [raw]
Subject: Re: mmotm 2010-04-05 - another RCU whinge (not network this time)

On Fri, 09 Apr 2010 16:16:14 PDT, "Paul E. McKenney" said:
> On Thu, Apr 08, 2010 at 07:57:28PM -0400, [email protected] wrote:
> > On Mon, 05 Apr 2010 16:09:45 PDT, [email protected] said:
> > > The mm-of-the-moment snapshot 2010-04-05-16-09 has been uploaded to
> > >
> > > http://userweb.kernel.org/~akpm/mmotm/
> >
> > Hit another one. I seem to be on a roll...
> >
> > Seen in dmesg, happened near end of the initrd..
> >
> > [ 26.756864]
> > [ 26.756866] ===================================================
> > [ 26.756869] [ INFO: suspicious rcu_dereference_check() usage. ]
> > [ 26.756871] ---------------------------------------------------
> > [ 26.756874] fs/proc/array.c:241 invoked rcu_dereference_check() without protection!
>
> Color me confused. I cloned James Toy's git repository at
> git://zen-kernel.org/kernel/mmotm.git, and gitk claims that I am on tag
> 2010-04-05-16-09, which matches the string above. But when I look at
> fs/proc/array.c near line 241, I see:

Andrew's -mm tree has 3 patches from Oleg Nesterov that hit that file, so the
code is different from what you show. Color *me* confused why your clone of
mmotm.git doesn't seem to contain them - I'm not sure how James Toy builds
that git tree. Perhaps the tag is applied before those patches are - the
'mm.patch' that updates the Makefile with the version is usually in the
*middle* of the 'series' file. What does HEAD of that tree look like?

My tree has:

/* needs ->siglock or rcu_read_lock() */
static void collect_sigign_sigcatch(struct task_struct *p, sigset_t *ign,
sigset_t *catch)
{
struct sighand_struct *sighand = rcu_dereference(p->sighand);

And that rcu_dereference() does it.

Oleg, looks like proc-make-collect_sigign_sigcatch-rcu-safe.patch is the
offender here, it added the line that causes the whinge.



Attachments:
(No filename) (227.00 B)

2010-04-10 05:15:15

by Paul E. McKenney

[permalink] [raw]
Subject: Re: mmotm 2010-04-05 - another RCU whinge (not network this time)

On Fri, Apr 09, 2010 at 11:22:32PM -0400, [email protected] wrote:
> On Fri, 09 Apr 2010 16:16:14 PDT, "Paul E. McKenney" said:
> > On Thu, Apr 08, 2010 at 07:57:28PM -0400, [email protected] wrote:
> > > On Mon, 05 Apr 2010 16:09:45 PDT, [email protected] said:
> > > > The mm-of-the-moment snapshot 2010-04-05-16-09 has been uploaded to
> > > >
> > > > http://userweb.kernel.org/~akpm/mmotm/
> > >
> > > Hit another one. I seem to be on a roll...
> > >
> > > Seen in dmesg, happened near end of the initrd..
> > >
> > > [ 26.756864]
> > > [ 26.756866] ===================================================
> > > [ 26.756869] [ INFO: suspicious rcu_dereference_check() usage. ]
> > > [ 26.756871] ---------------------------------------------------
> > > [ 26.756874] fs/proc/array.c:241 invoked rcu_dereference_check() without protection!
> >
> > Color me confused. I cloned James Toy's git repository at
> > git://zen-kernel.org/kernel/mmotm.git, and gitk claims that I am on tag
> > 2010-04-05-16-09, which matches the string above. But when I look at
> > fs/proc/array.c near line 241, I see:
>
> Andrew's -mm tree has 3 patches from Oleg Nesterov that hit that file, so the
> code is different from what you show. Color *me* confused why your clone of
> mmotm.git doesn't seem to contain them - I'm not sure how James Toy builds
> that git tree. Perhaps the tag is applied before those patches are - the
> 'mm.patch' that updates the Makefile with the version is usually in the
> *middle* of the 'series' file. What does HEAD of that tree look like?

Good point... The last commit is branch "master" and tagged
2010-04-05-16-09, but the commit line is "Linux 2.6.34-rc3", which seems
unlikely to me.

> My tree has:
>
> /* needs ->siglock or rcu_read_lock() */
> static void collect_sigign_sigcatch(struct task_struct *p, sigset_t *ign,
> sigset_t *catch)
> {
> struct sighand_struct *sighand = rcu_dereference(p->sighand);
>
> And that rcu_dereference() does it.

Thank you!!!

> Oleg, looks like proc-make-collect_sigign_sigcatch-rcu-safe.patch is the
> offender here, it added the line that causes the whinge.

If collect_sigign_sigcatch() is OK to call by updaters as well as
readers, we need something like:

struct sighand_struct *sighand;

sighand = rcu_dereference_check(p->sighand,
rcu_read_lock_held() ||
lockdep_is_held(&???));

Where the "???" is replaced with whichever of the two locks is protecting
updates. My guess would be the sighand lock, but I would not rely on
my guesses in this case. ;-)

Thanx, Paul

2010-04-11 10:18:02

by Bruno Prémont

[permalink] [raw]
Subject: Re: [PATCH mmotm] hid-picolcd: depends on LCD_CLASS_DEVICE

HID_PICOLCD should depend on LCD_CLASS_DEVICE, otherwise the
build fails when HID_PICOLCD=y and LCD_CLASS_DEVICE=m:

hid-picolcd.c:(.text+0x84523f): undefined reference to `lcd_device_unregister'
hid-picolcd.c:(.text+0x8478ab): undefined reference to `lcd_device_register'
hid-picolcd.c:(.text+0x84c15f): undefined reference to `lcd_device_unregister'

Same applies to FB, BACKLIGHT_CLASS_DEVICE and LEDS_CLASS.

Add suboptions for those features to handle the deps on kbuild side
and just check HID_PICOLCD_* in the code.

Reported-by: Randy Dunlap <[email protected]>
Signed-off-by: Bruno Prémont <[email protected]>
---

On Thu, 08 April 2010 Jiri Kosina <[email protected]> wrote:
> > +config HID_PICOLCD_FB
> > + bool "Framebuffer support"
> > + default !EMBEDDED
> > + depends on HID_PICOLCD
> > + depends on HID_PICOLCD=FB || FB=y
> > + select FB_DEFERRED_IO
> > + select FB_SYS_FILLRECT
> > + select FB_SYS_COPYAREA
> > + select FB_SYS_IMAGEBLIT
> > + select FB_SYS_FOPS
>
> Could we perhaps also make the sub-choices for individual features
> availabel only if !EMBEDDED as well?

Here is an updated patch to make the sub-choices visible only in
EMBEDDED case.

Thanks,
Bruno



drivers/hid/Kconfig | 53 +++++++++++++++++++++++++++++++++++++-------
drivers/hid/hid-picolcd.c | 40 +++++++++++++++++-----------------
2 files changed, 64 insertions(+), 29 deletions(-)

diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index a2ecd83..621c52c 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -265,11 +265,6 @@ config HID_PETALYNX
config HID_PICOLCD
tristate "PicoLCD (graphic version)"
depends on USB_HID
- select FB_DEFERRED_IO if FB
- select FB_SYS_FILLRECT if FB
- select FB_SYS_COPYAREA if FB
- select FB_SYS_IMAGEBLIT if FB
- select FB_SYS_FOPS if FB
---help---
This provides support for Minibox PicoLCD devices, currently
only the graphical ones are supported.
@@ -277,14 +272,54 @@ config HID_PICOLCD
This includes support for the following device features:
- Keypad
- Switching between Firmware and Flash mode
- - Framebuffer for monochrome 256x64 display
- - Backlight control (needs CONFIG_BACKLIGHT_CLASS_DEVICE)
- - Contrast control (needs CONFIG_LCD_CLASS_DEVICE)
- - General purpose outputs (needs CONFIG_LEDS_CLASS)
- EEProm / Flash access (via debugfs)
+ Features selectively enabled:
+ - Framebuffer for monochrome 256x64 display
+ - Backlight control
+ - Contrast control
+ - General purpose outputs
Features that are not (yet) supported:
- IR

+config HID_PICOLCD_FB
+ bool "Framebuffer support" if EMBEDDED
+ default !EMBEDDED
+ depends on HID_PICOLCD
+ depends on HID_PICOLCD=FB || FB=y
+ select FB_DEFERRED_IO
+ select FB_SYS_FILLRECT
+ select FB_SYS_COPYAREA
+ select FB_SYS_IMAGEBLIT
+ select FB_SYS_FOPS
+ ---help---
+ Provide access to PicoLCD's 256x64 monochrome display via a
+ frambuffer device.
+
+config HID_PICOLCD_BACKLIGHT
+ bool "Backlight control" if EMBEDDED
+ default !EMBEDDED
+ depends on HID_PICOLCD
+ depends on HID_PICOLCD=BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=y
+ ---help---
+ Provide access to PicoLCD's backlight control via backlight
+ class.
+
+config HID_PICOLCD_LCD
+ bool "Contrast control" if EMBEDDED
+ default !EMBEDDED
+ depends on HID_PICOLCD
+ depends on HID_PICOLCD=LCD_CLASS_DEVICE || LCD_CLASS_DEVICE=y
+ ---help---
+ Provide access to PicoLCD's LCD contrast via lcd class.
+
+config HID_PICOLCD_LEDS
+ bool "GPO via leds class" if EMBEDDED
+ default !EMBEDDED
+ depends on HID_PICOLCD
+ depends on HID_PICOLCD=LEDS_CLASS || LEDS_CLASS=y
+ ---help---
+ Provide access to PicoLCD's GPO pins via leds class.
+
config HID_QUANTA
tristate "Quanta Optical Touch"
depends on USB_HID
diff --git a/drivers/hid/hid-picolcd.c b/drivers/hid/hid-picolcd.c
index 0eacc6b..0fbc7d3 100644
--- a/drivers/hid/hid-picolcd.c
+++ b/drivers/hid/hid-picolcd.c
@@ -77,7 +77,7 @@
#define REPORT_HOOK_VERSION 0xf7 /* LCD: IN[2], OUT[1] */
#define REPORT_EXIT_FLASHER 0xff /* Bootloader: OUT[2] */

-#if defined(CONFIG_FB) || defined(CONFIG_FB_MODULE)
+#ifdef CONFIG_HID_PICOLCD_FB
/* Framebuffer
*
* The PicoLCD use a Topway LCD module of 256x64 pixel
@@ -128,7 +128,7 @@ static const struct fb_var_screeninfo picolcdfb_var = {
.bits_per_pixel = 1,
.grayscale = 1,
};
-#endif /* CONFIG_FB */
+#endif /* CONFIG_HID_PICOLCD_FB */

/* Input device
*
@@ -183,7 +183,7 @@ struct picolcd_data {
struct input_dev *input_cir;
unsigned short keycode[PICOLCD_KEYS];

-#if defined(CONFIG_FB) || defined(CONFIG_FB_MODULE)
+#ifdef CONFIG_HID_PICOLCD_FB
/* Framebuffer stuff */
u8 fb_update_rate;
u8 fb_bpp;
@@ -191,21 +191,21 @@ struct picolcd_data {
u8 *fb_bitmap; /* framebuffer */
struct fb_info *fb_info;
struct fb_deferred_io fb_defio;
-#endif /* CONFIG_FB */
-#if defined(CONFIG_LCD_CLASS_DEVICE) || defined(CONFIG_LCD_CLASS_DEVICE_MODULE)
+#endif /* CONFIG_HID_PICOLCD_FB */
+#ifdef CONFIG_HID_PICOLCD_LCD
struct lcd_device *lcd;
u8 lcd_contrast;
-#endif
-#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) || defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE)
+#endif /* CONFIG_HID_PICOLCD_LCD */
+#ifdef CONFIG_HID_PICOLCD_BACKLIGHT
struct backlight_device *backlight;
u8 lcd_brightness;
u8 lcd_power;
-#endif /* CONFIG_BACKLIGHT_CLASS_DEVICE */
-#if defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE)
+#endif /* CONFIG_HID_PICOLCD_BACKLIGHT */
+#ifdef CONFIG_HID_PICOLCD_LEDS
/* LED stuff */
u8 led_state;
struct led_classdev *led[8];
-#endif /* CONFIG_LEDS_CLASS */
+#endif /* CONFIG_HID_PICOLCD_LEDS */

/* Housekeeping stuff */
spinlock_t lock;
@@ -287,7 +287,7 @@ static struct picolcd_pending *picolcd_send_and_wait(struct hid_device *hdev,
return work;
}

-#if defined(CONFIG_FB) || defined(CONFIG_FB_MODULE)
+#ifdef CONFIG_HID_PICOLCD_FB
/* Send a given tile to PicoLCD */
static int picolcd_fb_send_tile(struct hid_device *hdev, int chip, int tile)
{
@@ -766,9 +766,9 @@ static void picolcd_exit_framebuffer(struct picolcd_data *data)
{
}
#define picolcd_fbinfo(d) NULL
-#endif /* CONFIG_FB */
+#endif /* CONFIG_HID_PICOLCD_FB */

-#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) || defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE)
+#ifdef CONFIG_HID_PICOLCD_BACKLIGHT
/*
* backlight class device
*/
@@ -864,9 +864,9 @@ static inline int picolcd_resume_backlight(struct picolcd_data *data)
{
return 0;
}
-#endif /* CONFIG_BACKLIGHT_CLASS_DEVICE */
+#endif /* CONFIG_HID_PICOLCD_BACKLIGHT */

-#if defined(CONFIG_LCD_CLASS_DEVICE) || defined(CONFIG_LCD_CLASS_DEVICE_MODULE)
+#ifdef CONFIG_HID_PICOLCD_LCD
/*
* lcd class device
*/
@@ -957,9 +957,9 @@ static inline int picolcd_resume_lcd(struct picolcd_data *data)
{
return 0;
}
-#endif /* CONFIG_LCD_CLASS_DEVICE */
+#endif /* CONFIG_HID_PICOLCD_LCD */

-#if defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE)
+#ifdef CONFIG_HID_PICOLCD_LEDS
/**
* LED class device
*/
@@ -1104,7 +1104,7 @@ static inline int picolcd_leds_set(struct picolcd_data *data)
{
return 0;
}
-#endif /* CONFIG_LEDS_CLASS */
+#endif /* CONFIG_HID_PICOLCD_LEDS */

/*
* input class device
@@ -1243,10 +1243,10 @@ static int picolcd_reset(struct hid_device *hdev)

picolcd_resume_lcd(data);
picolcd_resume_backlight(data);
-#if defined(CONFIG_FB) || defined(CONFIG_FB_MODULE)
+#ifdef CONFIG_HID_PICOLCD_FB
if (data->fb_info)
schedule_delayed_work(&data->fb_info->deferred_work, 0);
-#endif /* CONFIG_FB */
+#endif /* CONFIG_HID_PICOLCD_FB */

picolcd_leds_set(data);
return 0;
--
1.6.4.4

2010-04-11 18:28:46

by Jiri Kosina

[permalink] [raw]
Subject: Re: [PATCH mmotm] hid-picolcd: depends on LCD_CLASS_DEVICE

On Sun, 11 Apr 2010, Bruno Prémont wrote:

> > > +config HID_PICOLCD_FB
> > > + bool "Framebuffer support"
> > > + default !EMBEDDED
> > > + depends on HID_PICOLCD
> > > + depends on HID_PICOLCD=FB || FB=y
> > > + select FB_DEFERRED_IO
> > > + select FB_SYS_FILLRECT
> > > + select FB_SYS_COPYAREA
> > > + select FB_SYS_IMAGEBLIT
> > > + select FB_SYS_FOPS
> >
> > Could we perhaps also make the sub-choices for individual features
> > availabel only if !EMBEDDED as well?
>
> Here is an updated patch to make the sub-choices visible only in
> EMBEDDED case.

Applied, thanks Bruno.

--
Jiri Kosina
SUSE Labs, Novell Inc.

2010-04-12 18:35:27

by Oleg Nesterov

[permalink] [raw]
Subject: Re: mmotm 2010-04-05 - another RCU whinge (not network this time)

On 04/09, Paul E. McKenney wrote:
>
> > Oleg, looks like proc-make-collect_sigign_sigcatch-rcu-safe.patch is the
> > offender here, it added the line that causes the whinge.
>
> If collect_sigign_sigcatch() is OK to call by updaters as well as
> readers, we need something like:
>
> struct sighand_struct *sighand;
>
> sighand = rcu_dereference_check(p->sighand,
> rcu_read_lock_held() ||
> lockdep_is_held(&???));
>
> Where the "???" is replaced with whichever of the two locks is protecting
> updates. My guess would be the sighand lock, but I would not rely on
> my guesses in this case. ;-)

Yes, it should be p->sighand->siglock.

Actually, I was going to change another caller, do_task_stat(), to call
collect_sigign_sigcatch() without ->siglock too, but now I am not sure
when/if this will happen.

OK, thanks, I'll send the patch to make rcu_dereference_check() happy.




While we are here... __exit_signal() does

sighand = rcu_dereference_check(tsk->sighand,
rcu_read_lock_held() ||
lockdep_tasklist_lock_is_held());

What is the point? We know that the single caller must hold tasklist,
otherwise everything is broken. Perhaps it would be better to
use rcu_dereference_raw() ?

In fact, I don't really understand why __exit_signal() needs
rcu_dereference() at all.

Oleg.