Date: Thu, 17 May 2018 06:00:30 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 210316] panic after trying to r/w mount msdosfs on write protected media Message-ID: <bug-210316-3630-hZXjUGcmEG@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-210316-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-210316-3630@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=3D210316 --- Comment #15 from Andriy Gapon <avg@FreeBSD.org> --- (In reply to Konstantin Belousov from comment #9) This proposal looks like something that can help with the problem at hand i= n a generic way. I see that at present g_vfs_close() does not even check the return code of bufobj_invalbuf(). That looks dangerous? But not sure if the code can do better. E.g., if looping on an error would be okay. Then, there remains a question of when to use the proposed g_vfs_close(NOSA= VE). There are obvious cases like a failed mount. And that's what we want to address now, so that's good. But there can be a more complex situation. For example, we can mount a filesystem r/w and do some writes to it. But then the hardware suddenly decides to go to read-only mode (e.g., becau= se some internal counter crosses its threshold). So, we will get some failed writes and some dirty buffers that cannot possi= bly be made clean by writing out. Do we need to somehow handle them? And then we decide to unmount the filesystem. How do we handle those buffers? How do we know if we should call g_vfs_close(SAVE) or g_vfs_close(NOSAVE) ? --=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-210316-3630-hZXjUGcmEG>