Date: Sun, 03 Dec 2017 17:33:51 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-scsi@FreeBSD.org Subject: [Bug 224037] Kernel crashes when trying to mount certain USB keys reported as WriteProtected Message-ID: <bug-224037-5312-7mCWZH81FW@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-224037-5312@https.bugs.freebsd.org/bugzilla/> References: <bug-224037-5312@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224037 --- Comment #18 from Conrad Meyer <cem@freebsd.org> --- (In reply to Andriy Gapon from comment #17) > I think that we need to fix a bug that leads to the geom_vfs / buffer-cache > crash in any case. Agreed. That's my focus with this chain of duplicated bugs. > It might be also nice to add the r/o mount fallback mechanism. Yes, although that is an orthogonal enhancement, IMO, and met some resistance in the earlier attempt. If mount fails with EROFS or EACCES or whatever and dmesg contains the same CAM errors they do now, I think sysamdmins will figure it out. > But on top of those things we could modify g_disk_access() to prevent the write > access altogether if a disk is in the write-protected mode. Yeah, that makes sense too. It would reduce the complexity required in higher level layers. Instead of having to wait for the first IO to fail (probably whatever sets the dirty flag on a superblock), filesystems that rely on the underlying device to be a GEOM object (e.g., msdosfs) will encounter an error trying to g_access() (via g_vfs_open(..., 1)) the underlying disk writable. That would also solve the initial bug without having to change the filesystem level at all. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-224037-5312-7mCWZH81FW>