On 14.07.2019 14:46, Chris Wilson wrote:
> Quoting Heiner Kallweit (2019-07-14 13:39:15)
>> On 14.07.2019 14:34, Chris Wilson wrote:
>>> Quoting Heiner Kallweit (2019-07-13 12:12:56)
>>>> I debugged a little bit and remount_fs isn't set in sb->s_op.
>>>> The following at least avoids the NPE, not sure whether it's the correct fix.
>>>
>>> I take it you don't have CONFIG_TMPFS set?
>>>
>> This option is set:
>>
>> [root@zotac linux-next]# grep TMPFS .config
>> CONFIG_DEVTMPFS=y
>> CONFIG_DEVTMPFS_MOUNT=y
>> CONFIG_TMPFS=y
>> CONFIG_TMPFS_POSIX_ACL=y
>> CONFIG_TMPFS_XATTR=y
>
> Now that's weird, as
>
> static const struct super_operations shmem_ops = {
> .alloc_inode = shmem_alloc_inode,
> .free_inode = shmem_free_in_core_inode,
> .destroy_inode = shmem_destroy_inode,
> #ifdef CONFIG_TMPFS
> .statfs = shmem_statfs,
> .remount_fs = shmem_remount_fs,
> .show_options = shmem_show_options,
> #endif
> .evict_inode = shmem_evict_inode,
> .drop_inode = generic_delete_inode,
> .put_super = shmem_put_super,
> #ifdef CONFIG_TRANSPARENT_HUGE_PAGECACHE
> .nr_cached_objects = shmem_unused_huge_count,
> .free_cached_objects = shmem_unused_huge_scan,
> #endif
> };
>
> the only way it should be unset was if !CONFIG_TMPFS.
>
> Hmm, we even select TMPFS so it should never be absent.
>
> So the question is what mount did we get if it was not a shmemfs one?
> -Chris
>
I think that's the reason:
144df3b288c4 ("vfs: Convert ramfs, shmem, tmpfs, devtmpfs, rootfs to use the new mount API")
@@ -3736,7 +3849,6 @@ static const struct super_operations shmem_ops = {
.destroy_inode = shmem_destroy_inode,
#ifdef CONFIG_TMPFS
.statfs = shmem_statfs,
- .remount_fs = shmem_remount_fs,
.show_options = shmem_show_options,
#endif
.evict_inode = shmem_evict_inode,
Most likely this "new mount API" impacts your code.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
