#ifndef _OMFS_FS_H #define _OMFS_FS_H /* OMFS On-disk structures */ #define OMFS_MAGIC 0xC2993D87 #define OMFS_IMAGIC 0xD2 #define OMFS_DIR 'D' #define OMFS_FILE 'F' #define OMFS_INODE_NORMAL 'e' #define OMFS_INODE_CONTINUATION 'c' #define OMFS_INODE_SYSTEM 's' #define OMFS_NAMELEN 256 #define OMFS_DIR_START 0x1b8 #define OMFS_EXTENT_START 0x1d0 #define OMFS_EXTENT_CONT 0x40 #define OMFS_XOR_COUNT 19 #define OMFS_MAX_BLOCK_SIZE 8192 #define OMFS_MAX_CLUSTER_SIZE 8 #define OMFS_MAX_BLOCKS (1ul << 31) struct omfs_super_block { char s_fill1[256]; __be64 s_root_block; /* block number of omfs_root_block */ __be64 s_num_blocks; /* total number of FS blocks */ __be32 s_magic; /* OMFS_MAGIC */ __be32 s_blocksize; /* size of a block */ __be32 s_mirrors; /* # of mirrors of system blocks */ __be32 s_sys_blocksize; /* size of non-data blocks */ }; struct omfs_header { __be64 h_self; /* FS block where this is located */ __be32 h_body_size; /* size of useful data after header */ __be16 h_crc; /* crc-ccitt of body_size bytes */ char h_fill1[2]; u8 h_version; /* version, always 1 */ char h_type; /* OMFS_INODE_X */ u8 h_magic; /* OMFS_IMAGIC */ u8 h_check_xor; /* XOR of header bytes before this */ __be32 h_fill2; }; struct omfs_root_block { struct omfs_header r_head; /* header */ __be64 r_fill1; __be64 r_num_blocks; /* total number of FS blocks */ __be64 r_root_dir; /* block # of root directory */ __be64 r_bitmap; /* block # of free space bitmap */ __be32 r_blocksize; /* size of a block */ __be32 r_clustersize; /* size allocated for data blocks */ __be64 r_mirrors; /* # of mirrors of system blocks */ char r_name[OMFS_NAMELEN]; /* partition label */ }; struct omfs_inode { struct omfs_header i_head; /* header */ __be64 i_parent; /* parent containing this inode */ __be64 i_sibling; /* next inode in hash bucket */ __be64 i_ctime; /* ctime, in milliseconds */ char i_fill1[35]; char i_type; /* OMFS_[DIR,FILE] */ __be32 i_fill2; char i_fill3[64]; char i_name[OMFS_NAMELEN]; /* filename */ __be64 i_size; /* size of file, in bytes */ }; struct omfs_extent_entry { __be64 e_cluster; /* start location of a set of blocks */ __be64 e_blocks; /* number of blocks after e_cluster */ }; struct omfs_extent { __be64 e_next; /* next extent table location */ __be32 e_extent_count; /* total # extents in this table */ __be32 e_fill; struct omfs_extent_entry e_entry; /* start of extent entries */ }; #endif qt'>
path: root/include/dt-bindings/power/r8a7791-sysc.h
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2017-01-29 13:50:06 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2017-01-29 13:50:06 -0800
commit39cb2c9a316e77f6dfba96c543e55b6672d5a37e (patch)
tree98fe974ee4e20121253de7f61fc8d01bdb3821c1 /include/dt-bindings/power/r8a7791-sysc.h
parent2c5d9555d6d937966d79d4c6529a5f7b9206e405 (diff)
drm/i915: Check for NULL i915_vma in intel_unpin_fb_obj()
I've seen this trigger twice now, where the i915_gem_object_to_ggtt() call in intel_unpin_fb_obj() returns NULL, resulting in an oops immediately afterwards as the (inlined) call to i915_vma_unpin_fence() tries to dereference it. It seems to be some race condition where the object is going away at shutdown time, since both times happened when shutting down the X server. The call chains were different: - VT ioctl(KDSETMODE, KD_TEXT): intel_cleanup_plane_fb+0x5b/0xa0 [i915] drm_atomic_helper_cleanup_planes+0x6f/0x90 [drm_kms_helper] intel_atomic_commit_tail+0x749/0xfe0 [i915] intel_atomic_commit+0x3cb/0x4f0 [i915] drm_atomic_commit+0x4b/0x50 [drm] restore_fbdev_mode+0x14c/0x2a0 [drm_kms_helper] drm_fb_helper_restore_fbdev_mode_unlocked+0x34/0x80 [drm_kms_helper] drm_fb_helper_set_par+0x2d/0x60 [drm_kms_helper] intel_fbdev_set_par+0x18/0x70 [i915] fb_set_var+0x236/0x460 fbcon_blank+0x30f/0x350 do_unblank_screen+0xd2/0x1a0 vt_ioctl+0x507/0x12a0 tty_ioctl+0x355/0xc30 do_vfs_ioctl+0xa3/0x5e0 SyS_ioctl+0x79/0x90 entry_SYSCALL_64_fastpath+0x13/0x94 - i915 unpin_work workqueue: intel_unpin_work_fn+0x58/0x140 [i915] process_one_work+0x1f1/0x480 worker_thread+0x48/0x4d0 kthread+0x101/0x140 and this patch purely papers over the issue by adding a NULL pointer check and a WARN_ON_ONCE() to avoid the oops that would then generally make the machine unresponsive. Other callers of i915_gem_object_to_ggtt() seem to also check for the returned pointer being NULL and warn about it, so this clearly has happened before in other places. [ Reported it originally to the i915 developers on Jan 8, applying the ugly workaround on my own now after triggering the problem for the second time with no feedback. This is likely to be the same bug reported as https://bugs.freedesktop.org/show_bug.cgi?id=98829 https://bugs.freedesktop.org/show_bug.cgi?id=99134 which has a patch for the underlying problem, but it hasn't gotten to me, so I'm applying the workaround. ] Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'include/dt-bindings/power/r8a7791-sysc.h')