Skip site navigation (1)Skip section navigation (2)
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=3D224037

--- 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-cac=
he
> 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 resistan=
ce
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 fig=
ure
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 hig=
her
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 err=
or
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 filesyst=
em
level at all.

--=20
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>