Thank you so much for taking care of this. Hi Greg,
Could you please cherry-pick the below commit in -stable? 38fb6d0ea34299d97b031ed64fe994158b6f8eb3 f2fs: use EINVAL for superblock with invalid magic Thanks, On 10/13, Pavel Machek wrote: > On Sat 2019-10-12 21:55:24, Andrew Macks wrote: > > Sorry for version typo in the previous message. > > > > In addition to 4.19, the issue was also backported to 4.14 and 5.2. > > > > 4.14, 4.19 and 5.2 are all missing the EINVAL fix from 5.3. > > Ouch. > > Well, when I seen the patch, I thought "looks like the bug is not > serious enough for -stable". I guess I should have spoken up. > > Anyway, I guess we need to either revert 59a5cea41dd0a or backport > 38fb6d0ea34299d97b too.... > > So I guess Greg and lists need to be cc-ed... and > > Thanks for the report and sorry for the trouble.... > > Pavel > > > > Andrew. > > > > On Sat, 12 Oct 2019 at 21:39, Andrew Macks <[email protected]> wrote: > > > > > Hi - there is a nasty regression which was recently introduced into > > > longterm 4.19.76. > > > > > > 59a5cea41dd0ae706ab83f8ecd64199aadefb493 was committed to 4.19, however it > > > introduces a regression that filesystems no longer mount if do_mounts > > > iterates through them after F2FS. This surfaced on one of my servers as > > > F2FS superblock check happens before btrfs mount is attempted. > > > > > > With this code, my server panicked after kernel upgrade as btrfs mount > > > wasn't attempted. > > > > > > This issue has already been fixed in 5.3 with this patch in July, but it > > > was missed from the 4.19 backport. > > > > > > 38fb6d0ea34299d97b031ed64fe994158b6f8eb3 > > > f2fs: use EINVAL for superblock with invalid magic > > > > > > Andypoo. > > > > > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
