Skip to content
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

Closed
srcshelton opened this issue May 8, 2013 · 17 comments
Closed

Branch 3.9.y - 'enable_whitelist' undeclared #292

srcshelton opened this issue May 8, 2013 · 17 comments

Comments

@srcshelton
Copy link

  CC      drivers/usb/core/hub.o - due to: arch/arm/include/generated/asm/bitsperlong.h arch/arm/include/generated/asm/errno.h include/config/uidgid/strict/type/checks.h include/config/user/ns.h include/generated/bounds.h arch/arm/include/generated/asm/percpu.h arch/arm/include/generated/asm/auxvec.h arch/arm/include/generated/asm/cputime.h arch/arm/include/generated/asm/siginfo.h include/config/seccomp/filter.h arch/arm/include/generated/asm/resource.h arch/arm/include/generated/asm/ioctl.h
In file included from raspberrypi/src/kernel-3.9.y/drivers/usb/core/hub.c:2097:0:
raspberrypi/src/kernel-3.9.y/drivers/usb/core/otg_whitelist.h: In function 'is_targeted':
raspberrypi/src/kernel-3.9.y/drivers/usb/core/otg_whitelist.h:110:14: error: 'enable_whitelist' undeclared (first use in this function)
raspberrypi/src/kernel-3.9.y/drivers/usb/core/otg_whitelist.h:110:14: note: each undeclared identifier is reported only once for each function it appears in
raspberrypi/src/kernel-3.9.y/drivers/usb/core/otg_whitelist.h:185:1: warning: control reaches end of non-void function [-Wreturn-type]
make[6]: *** [drivers/usb/core/hub.o] Error 1
make[5]: *** [drivers/usb/core] Error 2
make[4]: *** [drivers/usb] Error 2
make[3]: *** [drivers] Error 2
make[2]: *** [sub-make] Error 2
make[1]: *** [vmlinux] Error 2
make: *** [sub-make] Error 2

raspberrypi kernel-3.9.y # grep -R enable_whitelist .
./drivers/usb/core/otg_whitelist.h:     } else if (!enable_whitelist) {
./drivers/usb/core/otg_whitelist.h:     if (enable_whitelist) {
raspberrypi kernel-3.9.y # grep -i white .config
# CONFIG_USB_OTG_WHITELIST is not set
# CONFIG_USB_SERIAL_WHITEHEAT is not set
@hvenzke
Copy link

hvenzke commented May 8, 2013

Kconfig Bug for CONFIG_USB_OTG as i assume , must be not tristate as most of the RPI stuff.
Had the same error here.
reqire both to be "y"

@popcornmix
Copy link
Collaborator

Have you enabled CONFIG_USB_OTG?
That's not something that's ever been tested.

@hvenzke
Copy link

hvenzke commented May 8, 2013

... testing compile it on fresh 3.8.12 ..
.. will report soon.. what happen.
in ~22h we know it... my Pi´s was busy past days with samba 404..

Testcompile oldconfig changes against my "stable" 3.8.7 tested .config
( http://www.raspberrypi.org/phpBB3/download/file.php?id=3174 )

 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
Thats the onboard Hub staff, don´t it .-)

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

@hvenzke
Copy link

hvenzke commented May 8, 2013

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
if Module not pushed to initrd.img

So that CONFIG_USB_OTG* Kconfigs shuold be bolean rather then tristate.

@srcshelton
Copy link
Author

$ grep OTG .config
CONFIG_USB_OTG=y
# CONFIG_USB_OTG_WHITELIST is not set
# CONFIG_USB_OTG_BLACKLIST_HUB is not set
CONFIG_USB_DWCOTG=y
# OTG and related infrastructure

I note that the official kernel.org 3.9.0 release contains no references to 'enable_whitelist'...

@hvenzke
Copy link

hvenzke commented May 9, 2013

3.8.y( 3.8.12) compiled well as normal.
Thus this was´t changed in 3.9.y its the same there.

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

@popcornmix
Copy link
Collaborator

I'm not following:

config USB_OTG
    bool "OTG support"
...
config USB_OTG_WHITELIST
    bool "Rely on OTG Targeted Peripherals List"
...

config USB_OTG_BLACKLIST_HUB
    bool "Disable external hubs"
...

They all seem to be bool anyway. What option would like to be changed to bool?

@hvenzke
Copy link

hvenzke commented May 25, 2013

from today stressttest with 3.9.y ( git from 24.05.2013 )

Its still the same - its an Code BUG .
@popcornmix try out yourself and fix it .
Please tell me where to search for the symbol ( what header file, libary ..)

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#

@ghollingworth
Copy link

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 .
@popcornmixhttps://github.com/popcornmix try out yourself and fix it .
Please tell me where to search for the symbol ( what header file, libary ..)

@hvenzke
Copy link

hvenzke commented May 25, 2013

@ghollingworth -
Gordon , please reply in an readable text .
If you reply by email this seems to cause at current remove the carriage returns and your msgs are near unreadable

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.

@ghollingworth
Copy link

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 -
Gordon , please reply in an readable text .
If you reply by email this seems to cause at current remove the carriage returns and your msgs.

And well that was an FRESH compile try .

Reply to this email directly or view it on GitHubhttps://github.com//issues/292#issuecomment-18442963.

@ghollingworth
Copy link

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

@hvenzke
Copy link

hvenzke commented May 25, 2013

Gordon ,

Just removed CONFIG_USB_OTG_UTILS USB_OTG_WHITELIST from my .config
and started the compile ON RPI ( no crosscompile ) again.

and anyhow , Brocken code shuold be removed or fixed somehow .

@ghollingworth
Copy link

Nobody is stopping you!

@hvenzke
Copy link

hvenzke commented May 25, 2013

Godon , that is not realy make the view.
I am NOT an Coder.

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#

@popcornmix
Copy link
Collaborator

Looks like enable_whitelist is no longer present in 3.18 kernel (which we are moving to).
Anyway this is not an issue with the recommended configuration. Closing.

@hvenzke
Copy link

hvenzke commented Jan 12, 2015

Thats fine - as the code cleanup at OTG closed this .

popcornmix pushed a commit that referenced this issue Dec 16, 2021
…_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
popcornmix pushed a commit that referenced this issue Dec 17, 2021
…_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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants