All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sven Schnelle <svens@linux.ibm.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>
Cc: linux-kernel@vger.kernel.org
Subject: autofs crash with latest linux-next
Date: Mon, 12 Oct 2020 09:54:39 +0200	[thread overview]
Message-ID: <yt9d1ri3nakg.fsf@linux.ibm.com> (raw)

Hi,

on s390 i see the following crash with linux-next:

[ 4525.432605] Unable to handle kernel pointer dereference in virtual kernel address space
[ 4525.432612] Failing address: 0000000000000000 TEID: 0000000000000483
[ 4525.432613] Fault in home space mode while using kernel ASCE.
[ 4525.432616] AS:00000000cf048007 R3:00000001fffec007 S:00000001ffff1800 P:000000000000003d 
[ 4525.432640] Oops: 0004 ilc:3 [#1] SMP 
[ 4525.432644] Modules linked in: dm_crypt encrypted_keys lcs ctcm fsm nfsv3 nfs_acl nfs lockd grace quota_v2 quota_tree tun overlay ntfs exfat vfat fat sctp vfio_pci irqbypass vfio_virqfd scsi_debug vhost_vsock vmw_vsock_virtio_transport_common vsock vhost vhost_iotlb vfio_ap kvm loop nft_counter bridge stp llc dm_service_time nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables nfnetlink sunrpc dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua s390_trng vfio_ccw vfio_mdev mdev vfio_iommu_type1 vfio zcrypt_cex4 eadm_sch sch_fq_codel ip_tables x_tables ghash_s390 prng aes_s390 des_s390 libdes sha3_512_s390 sha3_256_s390 sha512_s390 sha256_s390 sha1_s390 sha_common pkey zcrypt rng_core autofs4 [last unloaded: dummy_del_mod]
[ 4525.432691] CPU: 9 PID: 1050921 Comm: find Tainted: G           OE     5.9.0-20201011.rc8.git0.d67bc7812221.300.fc32.s390x+next #1
[ 4525.432693] Hardware name: IBM 3906 M04 704 (LPAR)
[ 4525.432694] Krnl PSW : 0704d00180000000 00000000cde29f70 (__kernel_write+0x1a0/0x2a0)
[ 4525.432702]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3
[ 4525.432704] Krnl GPRS: 0000000100067343 0000000000000000 0000000000000130 0000000000000001
[ 4525.432705]            0000000000000006 000000005f82be2f 0000000000000130 000000008c6ab568
[ 4525.432728]            0000000084441f00 0000000000000000 0000000000000130 0000000084441f00
[ 4525.432729]            0000000081476000 0000000000000001 00000000cde29ef4 000003e002f5b6f0
[ 4525.432735] Krnl Code: 00000000cde29f62: a7280000		lhi	%r2,0
                          00000000cde29f66: a7f4ff9d		brc	15,00000000cde29ea0
                         #00000000cde29f6a: e310f0f00004	lg	%r1,240(%r15)
                         >00000000cde29f70: e31090000024	stg	%r1,0(%r9)
                          00000000cde29f76: 9104b044		tm	68(%r11),4
                          00000000cde29f7a: a784000f		brc	8,00000000cde29f98
                          00000000cde29f7e: e31003400004	lg	%r1,832
                          00000000cde29f84: b904002a		lgr	%r2,%r10
[ 4525.432748] Call Trace:
[ 4525.432750]  [<00000000cde29f70>] __kernel_write+0x1a0/0x2a0 
[ 4525.432752] ([<00000000cde29ef4>] __kernel_write+0x124/0x2a0)
[ 4525.432756]  [<000003ff80004cfa>] autofs_write+0x5a/0x140 [autofs4] 
[ 4525.432758]  [<000003ff80005262>] autofs_notify_daemon.constprop.0+0x10a/0x1c8 [autofs4] 
[ 4525.432760]  [<000003ff80005872>] autofs_wait+0x552/0x718 [autofs4] 
[ 4525.432762]  [<000003ff800033ca>] autofs_mount_wait+0x5a/0xb0 [autofs4] 
[ 4525.432764]  [<000003ff800048b2>] autofs_d_automount+0x102/0x278 [autofs4] 
[ 4525.432766]  [<00000000cde398fe>] __traverse_mounts+0x9e/0x270 
[ 4525.432768]  [<00000000cde3e7ee>] step_into+0x1de/0x280 
[ 4525.432770]  [<00000000cde3f000>] open_last_lookups+0xb8/0x3f8 
[ 4525.432772]  [<00000000cde3f726>] path_openat+0x86/0x1d0 
[ 4525.432773]  [<00000000cde425b0>] do_filp_open+0x78/0x118 
[ 4525.432776]  [<00000000cde278d0>] do_sys_openat2+0xa8/0x168 
[ 4525.432778]  [<00000000cde27cfa>] __s390x_sys_openat+0x6a/0x98 
[ 4525.432781]  [<00000000ce64f2e8>] system_call+0xdc/0x2a4 
[ 4525.432782] Last Breaking-Event-Address:
[ 4525.432783]  [<00000000cde29efc>] __kernel_write+0x12c/0x2a0

This seems to be caused by the result of merging 0fb702791bf ("autofs:
use __kernel_write() for the autofs pipe writing") and 4d03e3cc5982
("fs: don't allow kernel reads and writes without iter
ops"). __kernel_write() gets now called with a NULL pointer as pos
argument, but __kernel_write expects a valid pointer as it
fetches/stores the pos value there. Is there a fix pending somewhere?

Thanks
Sven

             reply	other threads:[~2020-10-12  7:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-12  7:54 Sven Schnelle [this message]
2020-10-13  7:20 ` autofs crash with latest linux-next Christian Borntraeger
2020-10-14  7:15   ` Krzysztof Kozlowski
2020-10-15 19:28     ` Kees Cook
2020-10-15 19:58       ` Krzysztof Kozlowski
2020-10-16  5:44       ` Sven Schnelle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=yt9d1ri3nakg.fsf@linux.ibm.com \
    --to=svens@linux.ibm.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.