Sync ext4 encryption as of commit dffd334e4d7134
[ext4-patch-queue.git] / remove-block_device_ejected
blob9bdda6e571375cfbb68607090f58ac985019f5fe
1 ext4: remove block_device_ejected
3 From: Christoph Hellwig <hch@lst.de>
5 bdi->dev now never goes away, so this function became useless.
7 Signed-off-by: Christoph Hellwig <hch@lst.de>
8 Signed-off-by: Theodore Ts'o <tytso@mit.edu>
9 ---
10  fs/ext4/super.c | 18 +-----------------
11  1 file changed, 1 insertion(+), 17 deletions(-)
13 diff --git a/fs/ext4/super.c b/fs/ext4/super.c
14 index ad88e60..826cb66 100644
15 --- a/fs/ext4/super.c
16 +++ b/fs/ext4/super.c
17 @@ -323,22 +323,6 @@ static void save_error_info(struct super_block *sb, const char *func,
18         ext4_commit_super(sb, 1);
19  }
21 -/*
22 - * The del_gendisk() function uninitializes the disk-specific data
23 - * structures, including the bdi structure, without telling anyone
24 - * else.  Once this happens, any attempt to call mark_buffer_dirty()
25 - * (for example, by ext4_commit_super), will cause a kernel OOPS.
26 - * This is a kludge to prevent these oops until we can put in a proper
27 - * hook in del_gendisk() to inform the VFS and file system layers.
28 - */
29 -static int block_device_ejected(struct super_block *sb)
31 -       struct inode *bd_inode = sb->s_bdev->bd_inode;
32 -       struct backing_dev_info *bdi = inode_to_bdi(bd_inode);
34 -       return bdi->dev == NULL;
37  static void ext4_journal_commit_callback(journal_t *journal, transaction_t *txn)
38  {
39         struct super_block              *sb = journal->j_private;
40 @@ -4544,7 +4528,7 @@ static int ext4_commit_super(struct super_block *sb, int sync)
41         struct buffer_head *sbh = EXT4_SB(sb)->s_sbh;
42         int error = 0;
44 -       if (!sbh || block_device_ejected(sb))
45 +       if (!sbh)
46                 return error;
47         if (buffer_write_io_error(sbh)) {
48                 /*
49 -- 
50 1.9.1
53 To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
54 the body of a message to majordomo@vger.kernel.org
55 More majordomo info at  http://vger.kernel.org/majordomo-info.html