-
Notifications
You must be signed in to change notification settings - Fork 5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Branch 3.9.y - 'enable_whitelist' undeclared #292
Comments
Kconfig Bug for CONFIG_USB_OTG as i assume , must be not tristate as most of the RPI stuff. |
Have you enabled CONFIG_USB_OTG? |
... testing compile it on fresh 3.8.12 .. Testcompile oldconfig changes against my "stable" 3.8.7 tested .config CONFIG_USB_DYNAMIC_MINORS=y CONFIG_USB_SUSPEND=y CONFIG_USB_OTG=y CONFIG_USB_OTG_WHITELIST=y CONFIG_USB_OTG_BLACKLIST_HUB=y CONFIG_USB_MON=y @popcornmix CONFIG_USB_OTG shuold be allways ON for RPI´s msgs from 3.8.11 ( rpi-update kernel ) dmesg | grep otg [ 0.000000] Kernel command line: dma.dmachans=0x7f35 bcm2708_fb.fbwidth=800 bcm2708_fb.fbheight=600 bcm2708.boardrev=0xf bcm2708.serial=0x7c978107 smsc95xx.macaddr=B8:27:EB:97:81:07 sdhci-bcm2708.emmc_clock_freq=100000000 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 vga=normal highres=off rootfstype=ext4 elevator=deadline rootwait [ 1.321921] dwc_otg: version 3.00a 10-AUG-2012 (platform bus) [ 1.788946] dwc_otg: Microframe scheduler enabled [ 1.789146] dwc_otg bcm2708_usb: DWC OTG Controller [ 1.796778] dwc_otg bcm2708_usb: new USB bus registered, assigned bus number 1 [ 1.806779] dwc_otg bcm2708_usb: irq 32, io mem 0x00000000 [ 1.854083] usb usb1: Manufacturer: Linux 3.8.11+ dwc_otg_hcd [ 1.883807] dwc_otg: FIQ enabled [ 1.883825] dwc_otg: NAK holdoff enabled [ 2.350736] usb 1-1: new high-speed USB device number 2 using dwc_otg [ 2.910987] usb 1-1.1: new high-speed USB device number 3 using dwc_otg |
HMM as i remember due my past plenty compiles , just remind my self if one of this options was set like that CONFIG_USB_OTG_WHITELIST=m CONFIG_USB_OTG_BLACKLIST_HUB=m CONFIG_USB_OTG=m OTG failed if m while compiled on PI and My PI failed to boot from without CONFIG_USB_OTG=m So that CONFIG_USB_OTG* Kconfigs shuold be bolean rather then tristate. |
I note that the official kernel.org 3.9.0 release contains no references to 'enable_whitelist'... |
3.8.y( 3.8.12) compiled well as normal. CONFIG_USB_OTG_WHITELIST=y CONFIG_USB_OTG_BLACKLIST_HUB=y CONFIG_USB_OTG=y @popcornmix : must changed to Kconfig bolean rather then tristate @srcshelton issue solved - Kconfig error :- |
I'm not following:
They all seem to be bool anyway. What option would like to be changed to bool? |
from today stressttest with 3.9.y ( git from 24.05.2013 ) Its still the same - its an Code BUG . In file included from drivers/usb/core/hub.c:2097:0: drivers/usb/core/otg_whitelist.h: In function 'is_targeted': drivers/usb/core/otg_whitelist.h:110:14: error: 'enable_whitelist' undeclared (first use in this function) drivers/usb/core/otg_whitelist.h:110:14: note: each undeclared identifier is reported only once for each function it appears in make[3]: *** [drivers/usb/core/hub.o] Fehler 1 make[2]: *** [drivers/usb/core] Fehler 2 make[1]: *** [drivers/usb] Fehler 2 make: *** [drivers] Fehler 2 ~ :/usr/src/linux# grep -i otg_whitelist .config CONFIG_USB_OTG_WHITELIST=y ~ :/usr/src/linux# |
You should search in drivers/USB grep -r enable_whitelist * Should do it... Are you sure you cleaned the tree after adding the config option? Gordon On 25 May 2013, at 09:06, "Remsnet LTD," <notifications@git.luolix.topmailto:notifications@github.com> wrote: from today stressttest with 3.9.y ( 3.9.1 ): Its still the same - its an Code BUG . |
@ghollingworth - And well that was an FRESH compile try . i may assume it has todo with the removal of CONFIG_USB_OTG_UTILS see i.e https://lkml.org/lkml/2013/5/13/105 , https://patchwork.kernel.org/patch/2230741 http://marc.info/?t=136266748400001&r=1&w=3 and some more. |
Does it compile correctly upstream? On 25 May 2013, at 09:29, "Remsnet LTD," <notifications@git.luolix.topmailto:notifications@github.com> wrote: @ghollingworthhttps://github.com/ghollingworth - And well that was an FRESH compile try . Reply to this email directly or view it on GitHubhttps://github.com//issues/292#issuecomment-18442963. |
No you don't need config OTG this just enables the otg functionality which looks broken although I do believe someone had got it working before. The driver is otg capable which is why it's called dwc_otg but the host doesn't need the config option Gordon |
Gordon , Just removed CONFIG_USB_OTG_UTILS USB_OTG_WHITELIST from my .config and anyhow , Brocken code shuold be removed or fixed somehow . |
Nobody is stopping you! |
Godon , that is not realy make the view. the 3.9.y failed to compile . In file included from drivers/usb/core/hub.c:2097:0: drivers/usb/core/otg_whitelist.h: In function 'is_targeted': drivers/usb/core/otg_whitelist.h:110:14: error: 'enable_whitelist' undeclared (first use in this function) drivers/usb/core/otg_whitelist.h:110:14: note: each undeclared identifier is reported only once for each function it appears in drivers/usb/core/otg_whitelist.h:185:1: warning: control reaches end of non-void function [-Wreturn-type] make[3]: *** [drivers/usb/core/hub.o] Fehler 1 make[2]: *** [drivers/usb/core] Fehler 2 make[1]: *** [drivers/usb] Fehler 2 make: *** [drivers] Fehler 2 ~ #:/usr/src/linux# grep -i otg_whitelist .config # CONFIG_USB_OTG_WHITELIST is not set # vi .config ~ #:/usr/src/linux# make scripts/kconfig/conf --silentoldconfig Kconfig CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h make[1]: »include/generated/mach-types.h« ist bereits aktualisiert. CALL scripts/checksyscalls.sh CC scripts/mod/devicetable-offsets.s GEN scripts/mod/devicetable-offsets.h HOSTCC scripts/mod/file2alias.o HOSTLD scripts/mod/modpost CHK include/generated/compile.h GZIP kernel/config_data.gz CHK kernel/config_data.h UPD kernel/config_data.h CC kernel/configs.o LD kernel/built-in.o CC drivers/usb/core/hub.o In file included from drivers/usb/core/hub.c:2097:0: drivers/usb/core/otg_whitelist.h: In function 'is_targeted': drivers/usb/core/otg_whitelist.h:110:14: error: 'enable_whitelist' undeclared (first use in this function) drivers/usb/core/otg_whitelist.h:110:14: note: each undeclared identifier is reported only once for each function it appears in make[3]: *** [drivers/usb/core/hub.o] Fehler 1 make[2]: *** [drivers/usb/core] Fehler 2 make[1]: *** [drivers/usb] Fehler 2 make: *** [drivers] Fehler 2 ~ #:/usr/src/linux# grep -i otg_whitelist .config CONFIG_USB_OTG_WHITELIST=y ~ #:/usr/src/linux# |
Looks like enable_whitelist is no longer present in 3.18 kernel (which we are moving to). |
Thats fine - as the code cleanup at OTG closed this . |
…_lock Taking sb_writers whilst holding mmap_lock isn't allowed and will result in a lockdep warning like that below. The problem comes from cachefiles needing to take the sb_writers lock in order to do a write to the cache, but being asked to do this by netfslib called from readpage, readahead or write_begin[1]. Fix this by always offloading the write to the cache off to a worker thread. The main thread doesn't need to wait for it, so deadlock can be avoided. This can be tested by running the quick xfstests on something like afs or ceph with lockdep enabled. WARNING: possible circular locking dependency detected 5.15.0-rc1-build2+ #292 Not tainted ------------------------------------------------------ holetest/65517 is trying to acquire lock: ffff88810c81d730 (mapping.invalidate_lock#3){.+.+}-{3:3}, at: filemap_fault+0x276/0x7a5 but task is already holding lock: ffff8881595b53e8 (&mm->mmap_lock#2){++++}-{3:3}, at: do_user_addr_fault+0x28d/0x59c which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&mm->mmap_lock#2){++++}-{3:3}: validate_chain+0x3c4/0x4a8 __lock_acquire+0x89d/0x949 lock_acquire+0x2dc/0x34b __might_fault+0x87/0xb1 strncpy_from_user+0x25/0x18c removexattr+0x7c/0xe5 __do_sys_fremovexattr+0x73/0x96 do_syscall_64+0x67/0x7a entry_SYSCALL_64_after_hwframe+0x44/0xae -> #1 (sb_writers#10){.+.+}-{0:0}: validate_chain+0x3c4/0x4a8 __lock_acquire+0x89d/0x949 lock_acquire+0x2dc/0x34b cachefiles_write+0x2b3/0x4bb netfs_rreq_do_write_to_cache+0x3b5/0x432 netfs_readpage+0x2de/0x39d filemap_read_page+0x51/0x94 filemap_get_pages+0x26f/0x413 filemap_read+0x182/0x427 new_sync_read+0xf0/0x161 vfs_read+0x118/0x16e ksys_read+0xb8/0x12e do_syscall_64+0x67/0x7a entry_SYSCALL_64_after_hwframe+0x44/0xae -> #0 (mapping.invalidate_lock#3){.+.+}-{3:3}: check_noncircular+0xe4/0x129 check_prev_add+0x16b/0x3a4 validate_chain+0x3c4/0x4a8 __lock_acquire+0x89d/0x949 lock_acquire+0x2dc/0x34b down_read+0x40/0x4a filemap_fault+0x276/0x7a5 __do_fault+0x96/0xbf do_fault+0x262/0x35a __handle_mm_fault+0x171/0x1b5 handle_mm_fault+0x12a/0x233 do_user_addr_fault+0x3d2/0x59c exc_page_fault+0x85/0xa5 asm_exc_page_fault+0x1e/0x30 other info that might help us debug this: Chain exists of: mapping.invalidate_lock#3 --> sb_writers#10 --> &mm->mmap_lock#2 Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&mm->mmap_lock#2); lock(sb_writers#10); lock(&mm->mmap_lock#2); lock(mapping.invalidate_lock#3); *** DEADLOCK *** 1 lock held by holetest/65517: #0: ffff8881595b53e8 (&mm->mmap_lock#2){++++}-{3:3}, at: do_user_addr_fault+0x28d/0x59c stack backtrace: CPU: 0 PID: 65517 Comm: holetest Not tainted 5.15.0-rc1-build2+ #292 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: dump_stack_lvl+0x45/0x59 check_noncircular+0xe4/0x129 ? print_circular_bug+0x207/0x207 ? validate_chain+0x461/0x4a8 ? add_chain_block+0x88/0xd9 ? hlist_add_head_rcu+0x49/0x53 check_prev_add+0x16b/0x3a4 validate_chain+0x3c4/0x4a8 ? check_prev_add+0x3a4/0x3a4 ? mark_lock+0xa5/0x1c6 __lock_acquire+0x89d/0x949 lock_acquire+0x2dc/0x34b ? filemap_fault+0x276/0x7a5 ? rcu_read_unlock+0x59/0x59 ? add_to_page_cache_lru+0x13c/0x13c ? lock_is_held_type+0x7b/0xd3 down_read+0x40/0x4a ? filemap_fault+0x276/0x7a5 filemap_fault+0x276/0x7a5 ? pagecache_get_page+0x2dd/0x2dd ? __lock_acquire+0x8bc/0x949 ? pte_offset_kernel.isra.0+0x6d/0xc3 __do_fault+0x96/0xbf ? do_fault+0x124/0x35a do_fault+0x262/0x35a ? handle_pte_fault+0x1c1/0x20d __handle_mm_fault+0x171/0x1b5 ? handle_pte_fault+0x20d/0x20d ? __lock_release+0x151/0x254 ? mark_held_locks+0x1f/0x78 ? rcu_read_unlock+0x3a/0x59 handle_mm_fault+0x12a/0x233 do_user_addr_fault+0x3d2/0x59c ? pgtable_bad+0x70/0x70 ? rcu_read_lock_bh_held+0xab/0xab exc_page_fault+0x85/0xa5 ? asm_exc_page_fault+0x8/0x30 asm_exc_page_fault+0x1e/0x30 RIP: 0033:0x40192f Code: ff 48 89 c3 48 8b 05 50 28 00 00 48 85 ed 7e 23 31 d2 4b 8d 0c 2f eb 0a 0f 1f 00 48 8b 05 39 28 00 00 48 0f af c2 48 83 c2 01 <48> 89 1c 01 48 39 d5 7f e8 8b 0d f2 27 00 00 31 c0 85 c9 74 0e 8b RSP: 002b:00007f9931867eb0 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 00007f9931868700 RCX: 00007f993206ac00 RDX: 0000000000000001 RSI: 0000000000000000 RDI: 00007ffc13e06ee0 RBP: 0000000000000100 R08: 0000000000000000 R09: 00007f9931868700 R10: 00007f99318689d0 R11: 0000000000000202 R12: 00007ffc13e06ee0 R13: 0000000000000c00 R14: 00007ffc13e06e00 R15: 00007f993206a000 Fixes: 726218f ("netfs: Define an interface to talk to a cache") Signed-off-by: David Howells <dhowells@redhat.com> Tested-by: Jeff Layton <jlayton@kernel.org> cc: Jan Kara <jack@suse.cz> cc: linux-cachefs@redhat.com cc: linux-fsdevel@vger.kernel.org Link: https://lore.kernel.org/r/20210922110420.GA21576@quack2.suse.cz/ [1] Link: https://lore.kernel.org/r/163887597541.1596626.2668163316598972956.stgit@warthog.procyon.org.uk/ # v1
…_lock [ Upstream commit 598ad0b ] Taking sb_writers whilst holding mmap_lock isn't allowed and will result in a lockdep warning like that below. The problem comes from cachefiles needing to take the sb_writers lock in order to do a write to the cache, but being asked to do this by netfslib called from readpage, readahead or write_begin[1]. Fix this by always offloading the write to the cache off to a worker thread. The main thread doesn't need to wait for it, so deadlock can be avoided. This can be tested by running the quick xfstests on something like afs or ceph with lockdep enabled. WARNING: possible circular locking dependency detected 5.15.0-rc1-build2+ #292 Not tainted ------------------------------------------------------ holetest/65517 is trying to acquire lock: ffff88810c81d730 (mapping.invalidate_lock#3){.+.+}-{3:3}, at: filemap_fault+0x276/0x7a5 but task is already holding lock: ffff8881595b53e8 (&mm->mmap_lock#2){++++}-{3:3}, at: do_user_addr_fault+0x28d/0x59c which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&mm->mmap_lock#2){++++}-{3:3}: validate_chain+0x3c4/0x4a8 __lock_acquire+0x89d/0x949 lock_acquire+0x2dc/0x34b __might_fault+0x87/0xb1 strncpy_from_user+0x25/0x18c removexattr+0x7c/0xe5 __do_sys_fremovexattr+0x73/0x96 do_syscall_64+0x67/0x7a entry_SYSCALL_64_after_hwframe+0x44/0xae -> #1 (sb_writers#10){.+.+}-{0:0}: validate_chain+0x3c4/0x4a8 __lock_acquire+0x89d/0x949 lock_acquire+0x2dc/0x34b cachefiles_write+0x2b3/0x4bb netfs_rreq_do_write_to_cache+0x3b5/0x432 netfs_readpage+0x2de/0x39d filemap_read_page+0x51/0x94 filemap_get_pages+0x26f/0x413 filemap_read+0x182/0x427 new_sync_read+0xf0/0x161 vfs_read+0x118/0x16e ksys_read+0xb8/0x12e do_syscall_64+0x67/0x7a entry_SYSCALL_64_after_hwframe+0x44/0xae -> #0 (mapping.invalidate_lock#3){.+.+}-{3:3}: check_noncircular+0xe4/0x129 check_prev_add+0x16b/0x3a4 validate_chain+0x3c4/0x4a8 __lock_acquire+0x89d/0x949 lock_acquire+0x2dc/0x34b down_read+0x40/0x4a filemap_fault+0x276/0x7a5 __do_fault+0x96/0xbf do_fault+0x262/0x35a __handle_mm_fault+0x171/0x1b5 handle_mm_fault+0x12a/0x233 do_user_addr_fault+0x3d2/0x59c exc_page_fault+0x85/0xa5 asm_exc_page_fault+0x1e/0x30 other info that might help us debug this: Chain exists of: mapping.invalidate_lock#3 --> sb_writers#10 --> &mm->mmap_lock#2 Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&mm->mmap_lock#2); lock(sb_writers#10); lock(&mm->mmap_lock#2); lock(mapping.invalidate_lock#3); *** DEADLOCK *** 1 lock held by holetest/65517: #0: ffff8881595b53e8 (&mm->mmap_lock#2){++++}-{3:3}, at: do_user_addr_fault+0x28d/0x59c stack backtrace: CPU: 0 PID: 65517 Comm: holetest Not tainted 5.15.0-rc1-build2+ #292 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: dump_stack_lvl+0x45/0x59 check_noncircular+0xe4/0x129 ? print_circular_bug+0x207/0x207 ? validate_chain+0x461/0x4a8 ? add_chain_block+0x88/0xd9 ? hlist_add_head_rcu+0x49/0x53 check_prev_add+0x16b/0x3a4 validate_chain+0x3c4/0x4a8 ? check_prev_add+0x3a4/0x3a4 ? mark_lock+0xa5/0x1c6 __lock_acquire+0x89d/0x949 lock_acquire+0x2dc/0x34b ? filemap_fault+0x276/0x7a5 ? rcu_read_unlock+0x59/0x59 ? add_to_page_cache_lru+0x13c/0x13c ? lock_is_held_type+0x7b/0xd3 down_read+0x40/0x4a ? filemap_fault+0x276/0x7a5 filemap_fault+0x276/0x7a5 ? pagecache_get_page+0x2dd/0x2dd ? __lock_acquire+0x8bc/0x949 ? pte_offset_kernel.isra.0+0x6d/0xc3 __do_fault+0x96/0xbf ? do_fault+0x124/0x35a do_fault+0x262/0x35a ? handle_pte_fault+0x1c1/0x20d __handle_mm_fault+0x171/0x1b5 ? handle_pte_fault+0x20d/0x20d ? __lock_release+0x151/0x254 ? mark_held_locks+0x1f/0x78 ? rcu_read_unlock+0x3a/0x59 handle_mm_fault+0x12a/0x233 do_user_addr_fault+0x3d2/0x59c ? pgtable_bad+0x70/0x70 ? rcu_read_lock_bh_held+0xab/0xab exc_page_fault+0x85/0xa5 ? asm_exc_page_fault+0x8/0x30 asm_exc_page_fault+0x1e/0x30 RIP: 0033:0x40192f Code: ff 48 89 c3 48 8b 05 50 28 00 00 48 85 ed 7e 23 31 d2 4b 8d 0c 2f eb 0a 0f 1f 00 48 8b 05 39 28 00 00 48 0f af c2 48 83 c2 01 <48> 89 1c 01 48 39 d5 7f e8 8b 0d f2 27 00 00 31 c0 85 c9 74 0e 8b RSP: 002b:00007f9931867eb0 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 00007f9931868700 RCX: 00007f993206ac00 RDX: 0000000000000001 RSI: 0000000000000000 RDI: 00007ffc13e06ee0 RBP: 0000000000000100 R08: 0000000000000000 R09: 00007f9931868700 R10: 00007f99318689d0 R11: 0000000000000202 R12: 00007ffc13e06ee0 R13: 0000000000000c00 R14: 00007ffc13e06e00 R15: 00007f993206a000 Fixes: 726218f ("netfs: Define an interface to talk to a cache") Signed-off-by: David Howells <dhowells@redhat.com> Tested-by: Jeff Layton <jlayton@kernel.org> cc: Jan Kara <jack@suse.cz> cc: linux-cachefs@redhat.com cc: linux-fsdevel@vger.kernel.org Link: https://lore.kernel.org/r/20210922110420.GA21576@quack2.suse.cz/ [1] Link: https://lore.kernel.org/r/163887597541.1596626.2668163316598972956.stgit@warthog.procyon.org.uk/ # v1 Signed-off-by: Sasha Levin <sashal@kernel.org>
The text was updated successfully, but these errors were encountered: