Skip to contentSkip to conversation

mmotm 2010-04-05-16-09 uploaded

PATCH Applied [email protected] 8 participants 27 messages Apr 5, 2010 – Apr 12, 2010

Subsystems (5)
lore
Share & tools
lore
#0 lore raw

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

#1 lore raw

PATCH 1/1 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'

---
 drivers/hid/Kconfig |    1 +
 1 file changed, 1 insertion(+)
drivers/hid/Kconfig +1 -0
@@ -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
#2 lore raw

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

[ adding Bruno to CC ]

Quoted 17 lines · Randy Dunlap

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'

---
 drivers/hid/Kconfig |    1 +
 1 file changed, 1 insertion(+)

drivers/hid/Kconfig config HID_PETALYNX · line 271

Quoted 7 lines
drivers/hid/Kconfig +1 -0
@@ -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).

Signature · 2 lines
Jiri Kosina
SUSE Labs, Novell Inc.
maintainer
#3 lore raw

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

Quoted 13 lines · On Tue, 6 Apr 2010 10:40:06 +0200 Jiri Kosina <[email protected]> wrote:

[ adding Bruno to CC ]

Quoted 8 lines · Randy Dunlap

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

Quoted 19 lines
Quoted 8 lines
---
 drivers/hid/Kconfig |    1 +
 1 file changed, 1 insertion(+)

drivers/hid/Kconfig config HID_PETALYNX · line 271

Quoted 7 lines
drivers/hid/Kconfig +1 -0
@@ -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).

#4 lore raw

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

Quoted 23 lines · On Tue, 6 Apr 2010 10:56:35 +0200 Bruno Prémont wrote:
Quoted 13 lines · On Tue, 6 Apr 2010 10:40:06 +0200 Jiri Kosina <[email protected]> wrote:

[ adding Bruno to CC ]

Quoted 8 lines · Randy Dunlap

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

Quoted 4 lines

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.

Quoted 26 lines

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

Thanks,
Bruno

Quoted 5 lines
Quoted 5 lines
---
 drivers/hid/Kconfig |    1 +
 1 file changed, 1 insertion(+)
Quoted 13 lines

drivers/hid/Kconfig config HID_PETALYNX · line 271

Quoted 10 lines
drivers/hid/Kconfig +1 -0
@@ -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).

Quoted 1 line

--

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

maintainer
#5 lore raw

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

Quoted 25 lines · On Tue, 06 April 2010 Randy Dunlap <[email protected]> wrote:
Quoted 23 lines · On Tue, 6 Apr 2010 10:56:35 +0200 Bruno Prémont wrote:
Quoted 13 lines · On Tue, 6 Apr 2010 10:40:06 +0200 Jiri Kosina <[email protected]> wrote:

[ adding Bruno to CC ]

Quoted 8 lines · Randy Dunlap

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

Quoted 6 lines
Quoted 4 lines

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
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#6 lore raw

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

Quoted 33 lines · On Tue, 6 Apr 2010 18:35:35 +0200 Bruno Prémont wrote:
Quoted 25 lines · On Tue, 06 April 2010 Randy Dunlap <[email protected]> wrote:
Quoted 23 lines · On Tue, 6 Apr 2010 10:56:35 +0200 Bruno Prémont wrote:
Quoted 13 lines · On Tue, 6 Apr 2010 10:40:06 +0200 Jiri Kosina <[email protected]> wrote:

[ adding Bruno to CC ]

Quoted 8 lines · Randy Dunlap

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

Quoted 6 lines
Quoted 4 lines

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.

Quoted 8 lines

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.

Quoted 7 lines

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. :(

Quoted 3 lines

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

Quoted 11 lines

I had something like:

config HID_PICOLCD
tristate ...

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

Quoted 4 lines

...

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

---
~Randy
(re)read Documentation/ManagementStyle
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

maintainer
#7 lore raw

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

Quoted 4 lines · On Tue, 06 April 2010 Randy Dunlap <[email protected]> wrote:
Quoted 2 lines

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.

Quoted 8 lines
Quoted 7 lines

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)
Quoted 4 lines

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'

drivers/hid/Kconfig +29 -0
index a2ecd83..39df4f5 100644
@@ -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
drivers/hid/hid-picolcd.c +20 -20
index 0eacc6b..0fbc7d3 100644
@@ -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;

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#8 lore raw

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

Quoted 50 lines · On Tue, 6 Apr 2010 23:04:34 +0200 Bruno Prémont wrote:
Quoted 4 lines · On Tue, 06 April 2010 Randy Dunlap <[email protected]> wrote:
Quoted 2 lines

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.

Quoted 8 lines
Quoted 7 lines

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)
Quoted 4 lines

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'

drivers/hid/Kconfig +0 -0
index a2ecd83..39df4f5 100644

drivers/hid/Kconfig config HID_PICOLCD · line 287

Quoted 3 lines
drivers/hid/Kconfig +0 -0
@@ -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...

Quoted 22 lines
drivers/hid/Kconfig +22 -0
+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

drivers/hid/Kconfig config HID_PICOLCD · line 319

Quoted 10 lines
drivers/hid/Kconfig +7 -0
+
+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

maintainer
#9 lore raw

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.

---

Quoted 2 lines · 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(-)
drivers/hid/Kconfig +44 -9
index a2ecd83..782a34e 100644
@@ -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
drivers/hid/hid-picolcd.c +20 -20
index 0eacc6b..0fbc7d3 100644
@@ -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;
Signature · 6 lines
1.6.4.4

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#10 lore raw

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

Quoted 63 lines · Bruno Prémont

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.

---

Quoted 2 lines · 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(-)
drivers/hid/Kconfig +5 -9
index a2ecd83..782a34e 100644
@@ -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
 

drivers/hid/Kconfig config HID_PICOLCD · line 293

Quoted 10 lines
drivers/hid/Kconfig +10 -0
+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,

Signature · 6 lines
Jiri Kosina
SUSE Labs, Novell Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
maintainer
#11 lore raw

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.

---

Quoted 5 lines · On Thu, 08 April 2010 Jiri Kosina <[email protected]> wrote:
Quoted 5 lines
(quoted diff) +5 -0
+config HID_PICOLCD_FB
+	bool "Framebuffer support"
+	default !EMBEDDED
+	depends on HID_PICOLCD
+	depends on HID_PICOLCD=FB || FB=y
Quoted 8 lines

Review

Quoted 5 lines
(quoted diff) +5 -0
+	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(-)
drivers/hid/Kconfig +44 -9
index a2ecd83..621c52c 100644
@@ -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
drivers/hid/hid-picolcd.c +20 -20
index 0eacc6b..0fbc7d3 100644
@@ -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;
Signature · 6 lines
1.6.4.4

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Applied
#12 lore raw

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

Quoted 14 lines · Bruno Prémont
Quoted 5 lines
Quoted 5 lines
drivers/hid/Kconfig +5 -0
+config HID_PICOLCD_FB
+	bool "Framebuffer support"
+	default !EMBEDDED
+	depends on HID_PICOLCD
+	depends on HID_PICOLCD=FB || FB=y
Quoted 8 lines

drivers/hid/Kconfig config HID_PICOLCD · line 293

Quoted 5 lines
drivers/hid/Kconfig +5 -0
+	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?

Quoted 2 lines

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

Applied, thanks Bruno.

Signature · 6 lines
Jiri Kosina
SUSE Labs, Novell Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
maintainer
#13 lore raw

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

In reply to Randy Dunlap
Quoted 9 lines · On Tue, 06 April 2010 Randy Dunlap <[email protected]> wrote:
Quoted 3 lines

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?

drivers/hid/Kconfig +7 -4
index 782a34e..711c091 100644
@@ -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.
 
#14 lore raw

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

Quoted 11 lines · On Wed, 7 Apr 2010 20:44:04 +0200 Bruno Prémont wrote:
Quoted 9 lines · On Tue, 06 April 2010 Randy Dunlap <[email protected]> wrote:
Quoted 3 lines

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

Quoted 6 lines

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)

Quoted 5 lines

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)

drivers/hid/Kconfig config HID_PICOLCD_FB · line 288

Quoted 11 lines
drivers/hid/Kconfig +1 -1
index 782a34e..711c091 100644
@@ -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.

Quoted 24 lines
drivers/hid/Kconfig +4 -2
 	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.
 

drivers/hid/Kconfig config HID_PICOLCD_LEDS · line 324

Quoted 8 lines
drivers/hid/Kconfig +2 -1
@@ -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
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

maintainer
#15 lore raw

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

Quoted 31 lines · On Wed, 07 April 2010 Randy Dunlap <[email protected]> wrote:
Quoted 11 lines · On Wed, 7 Apr 2010 20:44:04 +0200 Bruno Prémont wrote:
Quoted 9 lines · On Tue, 06 April 2010 Randy Dunlap <[email protected]> wrote:
Quoted 3 lines

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

Quoted 6 lines

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)

Quoted 5 lines

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:

Quoted 10 lines

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.

Quoted 16 lines

(more below)

drivers/hid/Kconfig config HID_PICOLCD_FB · line 288

Quoted 11 lines
drivers/hid/Kconfig +1 -1
index 782a34e..711c091 100644
@@ -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

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#16 lore raw
In reply to [email protected]
Quoted 3 lines · 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
#17 lore raw
Quoted 9 lines · [email protected] wrote:
Quoted 3 lines · 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. ;)

Quoted 14 lines
[   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?

net/netfilter/nf_conntrack_ecache.c +4 -14
index d5a9bcd..849614a 100644
@@ -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);
 }
#18 lore raw
Quoted 25 lines · Patrick McHardy
Quoted 9 lines · [email protected] wrote:
Quoted 3 lines · 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. ;)

Quoted 14 lines
[   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] 
Quoted 4 lines

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
#19 lore raw
Quoted 6 lines · [email protected] wrote:
Quoted 5 lines · Patrick McHardy
Quoted 5 lines
[   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] 
Quoted 8 lines
Quoted 4 lines

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?

It appears that way, otherwise you should have seen a second warning in nf_conntrack_ecache the last time.

Quoted 2 lines

(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.

Quoted 7 lines
[    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] 
net/netfilter/nf_conntrack_ecache.c +4 -14
index d5a9bcd..849614a 100644
@@ -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);
 }
net/netfilter/nf_log.c +2 -6
index 015725a..908f599 100644
@@ -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]);
 	}
#20 lore raw
Quoted 9 lines · Patrick McHardy
Quoted 3 lines · [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.

Quoted 6 lines
Quoted 2 lines

(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...

Tested-by Valdis Kletnieks
#21 lore raw
Quoted 10 lines · [email protected] wrote:
Quoted 8 lines · Patrick McHardy
Quoted 3 lines · [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.

Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

(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...

Thanks. I've added the attached commit to the nf-next tree. I'll push it to Dave shortly so this can get included in the next tree.

Quoted 1 line

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.

---
 net/netfilter/nf_conntrack_ecache.c |   18 ++++--------------
 net/netfilter/nf_log.c              |    8 ++------
 2 files changed, 6 insertions(+), 20 deletions(-)
net/netfilter/nf_conntrack_ecache.c +4 -14
index d5a9bcd..849614a 100644
@@ -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);
 }
net/netfilter/nf_log.c +2 -6
index 015725a..908f599 100644
@@ -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]);
 	}
Signature · 1 line
1.7.0.4
#22 lore raw

mmotm 2010-04-05 - another RCU whinge (not network this time)

In reply to [email protected]
Quoted 3 lines · 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
#23 lore raw

Re: mmotm 2010-04-05 - another RCU whinge (not network this time)

Quoted 7 lines · On Thu, Apr 08, 2010 at 07:57:28PM -0400, [email protected] wrote:
Quoted 3 lines · 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...

Quoted 7 lines

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

Quoted 36 lines
[   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
#24 lore raw

Re: mmotm 2010-04-05 - another RCU whinge (not network this time)

Quoted 16 lines · Paul E. McKenney
Quoted 7 lines · On Thu, Apr 08, 2010 at 07:57:28PM -0400, [email protected] wrote:
Quoted 3 lines · 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...

Quoted 7 lines

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!
Quoted 4 lines

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.

#25 lore raw

Re: mmotm 2010-04-05 - another RCU whinge (not network this time)

Quoted 22 lines · On Fri, Apr 09, 2010 at 11:22:32PM -0400, [email protected] wrote:
Quoted 16 lines · Paul E. McKenney
Quoted 7 lines · On Thu, Apr 08, 2010 at 07:57:28PM -0400, [email protected] wrote:
Quoted 3 lines · 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...

Quoted 7 lines

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!
Quoted 4 lines

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:

Quoted 6 lines

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.

Quoted 9 lines

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!!!

Quoted 2 lines

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

#26 lore raw

Re: mmotm 2010-04-05 - another RCU whinge (not network this time)

Quoted 13 lines · Paul E. McKenney
Quoted 3 lines

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(&???));
Quoted 3 lines

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.