Skip to contentSkip to conversation

BZ#101951, Overlayfs on top of btrfs causes kernel oops + freeze

DISCUSSION Colin Ian King 2 participants 5 messages Feb 16, 2016 Btrfs file system

lore
Share & tools
lore

Colin Ian King

author
#0 lore raw

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

#1 lore raw
Quoted 14 lines · Colin Ian King

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():

Quoted 8 lines
        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/[email protected]/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.

Quoted 9 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Signature · 5 lines
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."
author
#2 lore raw
Quoted 25 lines · Filipe Manana
Quoted 14 lines · Colin Ian King

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():

Quoted 8 lines
        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.

Quoted 7 lines

See the discussion at
https://www.mail-archive.com/[email protected]/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?

Quoted 13 lines
Quoted 10 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#3 lore raw
Quoted 29 lines · Colin Ian King
Quoted 28 lines · Filipe Manana
Quoted 14 lines · Colin Ian King

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():

Quoted 8 lines
        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/[email protected]/msg48131.html

Quoted 6 lines
Quoted 4 lines

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.

Quoted 15 lines
Quoted 14 lines
Quoted 11 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Signature · 5 lines
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."
author
#4 lore raw
Quoted 31 lines · Filipe Manana
Quoted 29 lines · Colin Ian King
Quoted 28 lines · Filipe Manana
Quoted 14 lines · Colin Ian King

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():

Quoted 8 lines
        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/[email protected]/msg48131.html

Quoted 9 lines
Quoted 6 lines
Quoted 4 lines

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 :-/

Quoted 18 lines
Quoted 15 lines
Quoted 14 lines
Quoted 11 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html