Re: BZ#101951, Overlayfs on top of btrfs causes kernel oops + freeze
On Tue, Feb 16, 2016 at 4:08 PM, Colin Ian King wrote: > On 16/02/16 15:51, Filipe Manana wrote: >> On Tue, Feb 16, 2016 at 3:38 PM, Colin Ian King >> wrote: >>> Hi there, >>> >>> bug: https://bugzilla.kernel.org/show_bug.cgi?id=101951 and also >>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1532145 >>> >>> Commit 4bacc9c9234c7c8eec44f5ed4e960d9f96fa0f01 ("overlayfs: Make f_path >>> always point to the overlay and f_inode to the underlay") resulted in an >>> issue when using a combination of btrfs and overlayfs. This is >>> noticeable when doing a fsync() on a file in a chroot with overlayfs on >>> top of btrfs; we hit a kernel oops in btrfs_sync_file() on >>> atomic_inc(&root->log_batch) because root is NULL. >>> >>> I've debugged this further and found that in btrfs_sync_file(): >>> >>> struct inode *inode = d_inode(dentry); >>> >>> does not return the inode I expected when using the stacked overlay fs, >>> where as: >>> >>> struct inode *inode = file_inode(file); >>> >>> does. >> >> See the discussion at >> https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg48131.html >> >> You can get along with file_inode() in btrfs_sync_file(), but not >> later the fsync code path where we traverse the hierarchy up using >> dentries. >> More details on that thread. > > Ah, good. So was there any resolution on a way forward for a fix? Nop. > >> >>> >>> However, I'm not well at all well versed in btrfs, so I am not confident >>> this is a actually correct. Any comments? >>> >>> Colin >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in >>> the body of a message to majord...@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> >> > -- Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BZ#101951, Overlayfs on top of btrfs causes kernel oops + freeze
On 16/02/16 16:11, Filipe Manana wrote: > On Tue, Feb 16, 2016 at 4:08 PM, Colin Ian King > wrote: >> On 16/02/16 15:51, Filipe Manana wrote: >>> On Tue, Feb 16, 2016 at 3:38 PM, Colin Ian King >>> wrote: Hi there, bug: https://bugzilla.kernel.org/show_bug.cgi?id=101951 and also https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1532145 Commit 4bacc9c9234c7c8eec44f5ed4e960d9f96fa0f01 ("overlayfs: Make f_path always point to the overlay and f_inode to the underlay") resulted in an issue when using a combination of btrfs and overlayfs. This is noticeable when doing a fsync() on a file in a chroot with overlayfs on top of btrfs; we hit a kernel oops in btrfs_sync_file() on atomic_inc(&root->log_batch) because root is NULL. I've debugged this further and found that in btrfs_sync_file(): struct inode *inode = d_inode(dentry); does not return the inode I expected when using the stacked overlay fs, where as: struct inode *inode = file_inode(file); does. >>> >>> See the discussion at >>> https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg48131.html >>> >>> You can get along with file_inode() in btrfs_sync_file(), but not >>> later the fsync code path where we traverse the hierarchy up using >>> dentries. >>> More details on that thread. >> >> Ah, good. So was there any resolution on a way forward for a fix? > > Nop. > OK, so chroots don't work, that's a bit of a show stopper :-/ >> >>> However, I'm not well at all well versed in btrfs, so I am not confident this is a actually correct. Any comments? Colin -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >>> >>> >> > > > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BZ#101951, Overlayfs on top of btrfs causes kernel oops + freeze
On 16/02/16 15:51, Filipe Manana wrote: > On Tue, Feb 16, 2016 at 3:38 PM, Colin Ian King > wrote: >> Hi there, >> >> bug: https://bugzilla.kernel.org/show_bug.cgi?id=101951 and also >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1532145 >> >> Commit 4bacc9c9234c7c8eec44f5ed4e960d9f96fa0f01 ("overlayfs: Make f_path >> always point to the overlay and f_inode to the underlay") resulted in an >> issue when using a combination of btrfs and overlayfs. This is >> noticeable when doing a fsync() on a file in a chroot with overlayfs on >> top of btrfs; we hit a kernel oops in btrfs_sync_file() on >> atomic_inc(&root->log_batch) because root is NULL. >> >> I've debugged this further and found that in btrfs_sync_file(): >> >> struct inode *inode = d_inode(dentry); >> >> does not return the inode I expected when using the stacked overlay fs, >> where as: >> >> struct inode *inode = file_inode(file); >> >> does. > > See the discussion at > https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg48131.html > > You can get along with file_inode() in btrfs_sync_file(), but not > later the fsync code path where we traverse the hierarchy up using > dentries. > More details on that thread. Ah, good. So was there any resolution on a way forward for a fix? > >> >> However, I'm not well at all well versed in btrfs, so I am not confident >> this is a actually correct. Any comments? >> >> Colin >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BZ#101951, Overlayfs on top of btrfs causes kernel oops + freeze
On Tue, Feb 16, 2016 at 3:38 PM, Colin Ian King wrote: > Hi there, > > bug: https://bugzilla.kernel.org/show_bug.cgi?id=101951 and also > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1532145 > > Commit 4bacc9c9234c7c8eec44f5ed4e960d9f96fa0f01 ("overlayfs: Make f_path > always point to the overlay and f_inode to the underlay") resulted in an > issue when using a combination of btrfs and overlayfs. This is > noticeable when doing a fsync() on a file in a chroot with overlayfs on > top of btrfs; we hit a kernel oops in btrfs_sync_file() on > atomic_inc(&root->log_batch) because root is NULL. > > I've debugged this further and found that in btrfs_sync_file(): > > struct inode *inode = d_inode(dentry); > > does not return the inode I expected when using the stacked overlay fs, > where as: > > struct inode *inode = file_inode(file); > > does. See the discussion at https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg48131.html You can get along with file_inode() in btrfs_sync_file(), but not later the fsync code path where we traverse the hierarchy up using dentries. More details on that thread. > > However, I'm not well at all well versed in btrfs, so I am not confident > this is a actually correct. Any comments? > > Colin > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
BZ#101951, Overlayfs on top of btrfs causes kernel oops + freeze
Hi there, bug: https://bugzilla.kernel.org/show_bug.cgi?id=101951 and also https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1532145 Commit 4bacc9c9234c7c8eec44f5ed4e960d9f96fa0f01 ("overlayfs: Make f_path always point to the overlay and f_inode to the underlay") resulted in an issue when using a combination of btrfs and overlayfs. This is noticeable when doing a fsync() on a file in a chroot with overlayfs on top of btrfs; we hit a kernel oops in btrfs_sync_file() on atomic_inc(&root->log_batch) because root is NULL. I've debugged this further and found that in btrfs_sync_file(): struct inode *inode = d_inode(dentry); does not return the inode I expected when using the stacked overlay fs, where as: struct inode *inode = file_inode(file); does. However, I'm not well at all well versed in btrfs, so I am not confident this is a actually correct. Any comments? Colin -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html