1. 08 9月, 2016 12 次提交
    • C
      f2fs: fix to detect temporary name of multimedia file · 7732c26a
      Chao Yu 提交于
      Some applications may create multimeida file with temporary name like
      '*.jpg.tmp' or '*.mp4.tmp', then rename to '*.jpg' or '*.mp4'.
      
      Now, f2fs can only detect multimedia filename with specified format:
      "filename + '.' + extension", so it will make f2fs missing to detect
      multimedia file with special temporary name, result in failing to set
      cold flag on file.
      
      This patch enhances detection flow for enabling lookup extension in the
      middle of temporary filename.
      Reported-by: NXue Liu <liuxueliu.liu@huawei.com>
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      7732c26a
    • C
      f2fs: fix minor typo · 6ab2a308
      Chao Yu 提交于
      Correct typo from 'destory' to 'destroy'.
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      6ab2a308
    • J
      f2fs: set dentry bits on random location in memory · 6bf6b267
      Jaegeuk Kim 提交于
      This fixes pointer panic when using inline_dentry, which was triggered when
      backporting to 3.10.
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      6bf6b267
    • C
      f2fs: fix to set superblock dirty correctly · c2a080ae
      Chao Yu 提交于
      tests/generic/251 of fstest suit complains us with below message:
      
      ------------[ cut here ]------------
      invalid opcode: 0000 [#1] PREEMPT SMP
      CPU: 2 PID: 7698 Comm: fstrim Tainted: G           O    4.7.0+ #21
      task: e9f4e000 task.stack: e7262000
      EIP: 0060:[<f89fcefe>] EFLAGS: 00010202 CPU: 2
      EIP is at write_checkpoint+0xfde/0x1020 [f2fs]
      EAX: f33eb300 EBX: eecac310 ECX: 00000001 EDX: ffff0001
      ESI: eecac000 EDI: eecac5f0 EBP: e7263dec ESP: e7263d18
       DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
      CR0: 80050033 CR2: b76ab01c CR3: 2eb89de0 CR4: 000406f0
      Stack:
       00000001 a220fb7b e9f4e000 00000002 419ff2d3 b3a05151 00000002 e9f4e5d8
       e9f4e000 419ff2d3 b3a05151 eecac310 c10b8154 b3a05151 419ff2d3 c10b78bd
       e9f4e000 e9f4e000 e9f4e5d8 00000001 e9f4e000 ec409000 eecac2cc eecac288
      Call Trace:
       [<c10b8154>] ? __lock_acquire+0x3c4/0x760
       [<c10b78bd>] ? mark_held_locks+0x5d/0x80
       [<f8a10632>] f2fs_trim_fs+0x1c2/0x2e0 [f2fs]
       [<f89e9f56>] f2fs_ioctl+0x6b6/0x10b0 [f2fs]
       [<c13d51df>] ? __this_cpu_preempt_check+0xf/0x20
       [<c10b4281>] ? trace_hardirqs_off_caller+0x91/0x120
       [<f89e98a0>] ? __exchange_data_block+0xd30/0xd30 [f2fs]
       [<c120b2e1>] do_vfs_ioctl+0x81/0x7f0
       [<c11d57c5>] ? kmem_cache_free+0x245/0x2e0
       [<c1217840>] ? get_unused_fd_flags+0x40/0x40
       [<c1206eec>] ? putname+0x4c/0x50
       [<c11f631e>] ? do_sys_open+0x16e/0x1d0
       [<c1001990>] ? do_fast_syscall_32+0x30/0x1c0
       [<c13d51df>] ? __this_cpu_preempt_check+0xf/0x20
       [<c120baa8>] SyS_ioctl+0x58/0x80
       [<c1001a01>] do_fast_syscall_32+0xa1/0x1c0
       [<c178cc54>] sysenter_past_esp+0x45/0x74
      EIP: [<f89fcefe>] write_checkpoint+0xfde/0x1020 [f2fs] SS:ESP 0068:e7263d18
      ---[ end trace 4de95d7e6b3aa7c6 ]---
      
      The reason is: with below call stack, we will encounter BUG_ON during
      doing fstrim.
      
      Thread A				Thread B
      - write_checkpoint
       - do_checkpoint
      					- f2fs_write_inode
      					 - update_inode_page
      					  - update_inode
      					   - set_page_dirty
      					    - f2fs_set_node_page_dirty
      					     - inc_page_count
      					      - percpu_counter_inc
      					      - set_sbi_flag(SBI_IS_DIRTY)
        - clear_sbi_flag(SBI_IS_DIRTY)
      
      Thread C				Thread D
      - f2fs_write_node_page
       - set_node_addr
        - __set_nat_cache_dirty
         - nm_i->dirty_nat_cnt++
      					- do_vfs_ioctl
      					 - f2fs_ioctl
      					  - f2fs_trim_fs
      					   - write_checkpoint
      					    - f2fs_bug_on(nm_i->dirty_nat_cnt)
      
      Fix it by setting superblock dirty correctly in do_checkpoint and
      f2fs_write_node_page.
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      c2a080ae
    • S
      f2fs: add roll-forward recovery process for encrypted dentry · e7ba108a
      Shuoran Liu 提交于
      Add roll-forward recovery process for encrypted dentry, so the first fsync
      issued to an encrypted file does not need writing checkpoint.
      
      This improves the performance of the following test at thousands of small
      files: open -> write -> fsync -> close
      Signed-off-by: NShuoran Liu <liushuoran@huawei.com>
      Acked-by: NChao Yu <yuchao0@huawei.com>
      [Jaegeuk Kim: modify kernel message to show encrypted names]
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      e7ba108a
    • J
      f2fs: fix lost xattrs of directories · bbf156f7
      Jaegeuk Kim 提交于
      This patch enhances the xattr consistency of dirs from suddern power-cuts.
      
      Possible scenario would be:
      1. dir->setxattr used by per-file encryption
      2. file->setxattr goes into inline_xattr
      3. file->fsync
      
      In that case, we should do checkpoint for #1.
      Otherwise we'd lose dir's key information for the file given #2.
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      bbf156f7
    • C
      f2fs: support async discard · 275b66b0
      Chao Yu 提交于
      Like most filesystems, f2fs will issue discard command synchronously, so
      when user trigger fstrim through ioctl, multiple discard commands will be
      issued serially with sync mode, which makes poor performance.
      
      In this patch we try to support async discard, so that all discard
      commands can be issued and be waited for endio in batch to improve
      performance.
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      275b66b0
    • S
      f2fs: set encryption name flag in add inline entry path · 167451ef
      Shuoran Liu 提交于
      This patch sets encryption name flag in the add inline entry path
      if filename is encrypted.
      Signed-off-by: NShuoran Liu <liushuoran@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      167451ef
    • C
      f2fs crypto: avoid unneeded memory allocation in ->readdir · e06f86e6
      Chao Yu 提交于
      When decrypting dirents in ->readdir, fscrypt_fname_disk_to_usr won't
      change content of original encrypted dirent, we don't need to allocate
      additional buffer for storing mirror of it, so get rid of it.
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      e06f86e6
    • C
      f2fs: fix to do security initialization of encrypted inode with original filename · 9421d570
      Chao Yu 提交于
      When creating new inode, security_inode_init_security will be called for
      initializing security info related to the inode, and filename is passed to
      security module, it helps security module such as SElinux to know which
      rule or label could be applied for the inode with specified name.
      
      Previously, if new inode is created as an encrypted one, f2fs will transfer
      encrypted filename to security module which may fail the check of security
      policy belong to the inode. So in order to this issue, alter to transfer
      original unencrypted filename instead.
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      9421d570
    • C
      f2fs: do in batch synchronously readahead during GC · 7ea984b0
      Chao Yu 提交于
      In order to enhance performance, we try to readahead node page during
      GC, but before loading node page we should get block address of node page
      which is stored in NAT table, so synchronously read of single NAT page
      block our readahead flow.
      
      f2fs_submit_page_bio: dev = (251,0), ino = 2, page_index = 0xa1e, oldaddr = 0xa1e, newaddr = 0xa1e, rw = READ_SYNC(MP), type = META
      f2fs_submit_page_bio: dev = (251,0), ino = 1, page_index = 0x35e9, oldaddr = 0x72d7a, newaddr = 0x72d7a, rw = READAHEAD ^H, type = NODE
      f2fs_submit_page_bio: dev = (251,0), ino = 2, page_index = 0xc1f, oldaddr = 0xc1f, newaddr = 0xc1f, rw = READ_SYNC(MP), type = META
      f2fs_submit_page_bio: dev = (251,0), ino = 1, page_index = 0x389d, oldaddr = 0x72d7d, newaddr = 0x72d7d, rw = READAHEAD ^H, type = NODE
      f2fs_submit_page_bio: dev = (251,0), ino = 1, page_index = 0x3a82, oldaddr = 0x72d7f, newaddr = 0x72d7f, rw = READAHEAD ^H, type = NODE
      f2fs_submit_page_bio: dev = (251,0), ino = 1, page_index = 0x3bfa, oldaddr = 0x72d86, newaddr = 0x72d86, rw = READAHEAD ^H, type = NODE
      
      This patch adds one phase that do readahead NAT pages in batch before
      readahead node page for more effeciently.
      
      f2fs_submit_page_bio: dev = (251,0), ino = 2, page_index = 0x1952, oldaddr = 0x1952, newaddr = 0x1952, rw = READ_SYNC(MP), type = META
      f2fs_submit_page_mbio: dev = (251,0), ino = 2, page_index = 0xc34, oldaddr = 0xc34, newaddr = 0xc34, rw = READ_SYNC(MP), type = META
      f2fs_submit_page_mbio: dev = (251,0), ino = 2, page_index = 0xa33, oldaddr = 0xa33, newaddr = 0xa33, rw = READ_SYNC(MP), type = META
      f2fs_submit_page_mbio: dev = (251,0), ino = 2, page_index = 0xc30, oldaddr = 0xc30, newaddr = 0xc30, rw = READ_SYNC(MP), type = META
      f2fs_submit_page_mbio: dev = (251,0), ino = 2, page_index = 0xc32, oldaddr = 0xc32, newaddr = 0xc32, rw = READ_SYNC(MP), type = META
      f2fs_submit_page_mbio: dev = (251,0), ino = 2, page_index = 0xc26, oldaddr = 0xc26, newaddr = 0xc26, rw = READ_SYNC(MP), type = META
      f2fs_submit_page_mbio: dev = (251,0), ino = 2, page_index = 0xa2b, oldaddr = 0xa2b, newaddr = 0xa2b, rw = READ_SYNC(MP), type = META
      f2fs_submit_page_mbio: dev = (251,0), ino = 2, page_index = 0xc23, oldaddr = 0xc23, newaddr = 0xc23, rw = READ_SYNC(MP), type = META
      f2fs_submit_page_mbio: dev = (251,0), ino = 2, page_index = 0xc24, oldaddr = 0xc24, newaddr = 0xc24, rw = READ_SYNC(MP), type = META
      f2fs_submit_page_mbio: dev = (251,0), ino = 2, page_index = 0xa10, oldaddr = 0xa10, newaddr = 0xa10, rw = READ_SYNC(MP), type = META
      f2fs_submit_page_mbio: dev = (251,0), ino = 2, page_index = 0xc2c, oldaddr = 0xc2c, newaddr = 0xc2c, rw = READ_SYNC(MP), type = META
      f2fs_submit_page_bio: dev = (251,0), ino = 1, page_index = 0x5db7, oldaddr = 0x6be00, newaddr = 0x6be00, rw = READAHEAD ^H, type = NODE
      f2fs_submit_page_bio: dev = (251,0), ino = 1, page_index = 0x5db9, oldaddr = 0x6be17, newaddr = 0x6be17, rw = READAHEAD ^H, type = NODE
      f2fs_submit_page_bio: dev = (251,0), ino = 1, page_index = 0x5dbc, oldaddr = 0x6be1a, newaddr = 0x6be1a, rw = READAHEAD ^H, type = NODE
      f2fs_submit_page_bio: dev = (251,0), ino = 1, page_index = 0x5dc3, oldaddr = 0x6be20, newaddr = 0x6be20, rw = READAHEAD ^H, type = NODE
      f2fs_submit_page_bio: dev = (251,0), ino = 1, page_index = 0x5dc7, oldaddr = 0x6be24, newaddr = 0x6be24, rw = READAHEAD ^H, type = NODE
      f2fs_submit_page_bio: dev = (251,0), ino = 1, page_index = 0x5dc9, oldaddr = 0x6be25, newaddr = 0x6be25, rw = READAHEAD ^H, type = NODE
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      7ea984b0
    • C
      f2fs: schedule in between two continous batch discards · 74fa5f3d
      Chao Yu 提交于
      In batch discard approach of fstrim will grab/release gc_mutex lock
      repeatly, it makes contention of the lock becoming more intensive.
      
      So after one batch discards were issued in checkpoint and the lock
      was released, it's better to do schedule() to increase opportunity
      of grabbing gc_mutex lock for other competitors.
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      74fa5f3d
  2. 30 8月, 2016 14 次提交
  3. 25 8月, 2016 3 次提交
    • C
      f2fs: clean up bio cache trace · 44819a76
      Chao Yu 提交于
      Trace info related to bio cache operation is out of format, clean up it.
      
      Before:
             <...>-28308 [002] ....  4781.052703: f2fs_submit_write_bio: dev = (251,1), WRITEWRITE_SYNC ^H, DATA, sector = 271424, size = 126976
             <...>-28308 [002] ....  4781.052820: f2fs_submit_page_mbio: dev = (251,1), ino = 103, page_index = 0x1f, oldaddr = 0xffffffff, newaddr = 0x84a7 rw = WRITEWRITE_SYNCi ^H, type = DATA
      kworker/u8:2-29988 [001] ....  5549.293877: f2fs_submit_page_mbio: dev = (251,1), ino = 91, page_index = 0xd, oldaddr = 0xffffffff, newaddr = 0x782f rw = WRITE0x0i ^H type = DATA
      
      After:
      kworker/u8:2-8678  [000] ....  7945.124459: f2fs_submit_write_bio: dev = (251,1), rw = WRITE_SYNC, DATA, sector = 74080, size = 53248
      kworker/u8:2-8678  [000] ....  7945.124551: f2fs_submit_page_mbio: dev = (251,1), ino = 11, page_index = 0xec, oldaddr = 0xffffffff, newaddr = 0x243a, rw = WRITE, type = DATA
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      44819a76
    • J
      f2fs: do not use discard_map for hard disks · 3e025740
      Jaegeuk Kim 提交于
      We don't need to keep discard_map, if disk does not support discard command.
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      3e025740
    • Y
      f2fs: not allow to write illegal blkaddr · bb413d6a
      Yunlei He 提交于
      we came across an error as below:
      
      [build_nat_area_bitmap:1710] nid[0x    1718] addr[0x         1c18ddc] ino[0x    1718]
      [build_nat_area_bitmap:1710] nid[0x    1719] addr[0x         1c193d5] ino[0x    1719]
      [build_nat_area_bitmap:1710] nid[0x    171a] addr[0x         1c1736e] ino[0x    171a]
      [build_nat_area_bitmap:1710] nid[0x    171b] addr[0x        58b3ee8f] ino[0x815f92ed]
      [build_nat_area_bitmap:1710] nid[0x    171c] addr[0x         fcdc94b] ino[0x49366377]
      [build_nat_area_bitmap:1710] nid[0x    171d] addr[0x        7cd2facf] ino[0xb3c55300]
      [build_nat_area_bitmap:1710] nid[0x    171e] addr[0x        bd4e25d0] ino[0x77c34c09]
      
      ... ...
      
      [build_nat_area_bitmap:1710] nid[0x    1718] addr[0x         1c18ddc] ino[0x    1718]
      [build_nat_area_bitmap:1710] nid[0x    1719] addr[0x         1c193d5] ino[0x    1719]
      [build_nat_area_bitmap:1710] nid[0x    171a] addr[0x         1c1736e] ino[0x    171a]
      [build_nat_area_bitmap:1710] nid[0x    171b] addr[0x        58b3ee8f] ino[0x815f92ed]
      [build_nat_area_bitmap:1710] nid[0x    171c] addr[0x         fcdc94b] ino[0x49366377]
      [build_nat_area_bitmap:1710] nid[0x    171d] addr[0x        7cd2facf] ino[0xb3c55300]
      [build_nat_area_bitmap:1710] nid[0x    171e] addr[0x        bd4e25d0] ino[0x77c34c09]
      
      One nat block may be stepped by a data block, so this patch forbid to
      write if the blkaddr is illegal
      Signed-off-by: NYunlei He <heyunlei@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      bb413d6a
  4. 24 8月, 2016 4 次提交
  5. 23 8月, 2016 5 次提交
    • B
      vhost/scsi: fix reuse of &vq->iov[out] in response · a77ec83a
      Benjamin Coddington 提交于
      The address of the iovec &vq->iov[out] is not guaranteed to contain the scsi
      command's response iovec throughout the lifetime of the command.  Rather, it
      is more likely to contain an iovec from an immediately following command
      after looping back around to vhost_get_vq_desc().  Pass along the iovec
      entirely instead.
      
      Fixes: 79c14141 ("vhost/scsi: Convert completion path to use copy_to_iter")
      Cc: stable@vger.kernel.org
      Signed-off-by: NBenjamin Coddington <bcodding@redhat.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      a77ec83a
    • J
      usercopy: fix overlap check for kernel text · 94cd97af
      Josh Poimboeuf 提交于
      When running with a local patch which moves the '_stext' symbol to the
      very beginning of the kernel text area, I got the following panic with
      CONFIG_HARDENED_USERCOPY:
      
        usercopy: kernel memory exposure attempt detected from ffff88103dfff000 (<linear kernel text>) (4096 bytes)
        ------------[ cut here ]------------
        kernel BUG at mm/usercopy.c:79!
        invalid opcode: 0000 [#1] SMP
        ...
        CPU: 0 PID: 4800 Comm: cp Not tainted 4.8.0-rc3.after+ #1
        Hardware name: Dell Inc. PowerEdge R720/0X3D66, BIOS 2.5.4 01/22/2016
        task: ffff880817444140 task.stack: ffff880816274000
        RIP: 0010:[<ffffffff8121c796>] __check_object_size+0x76/0x413
        RSP: 0018:ffff880816277c40 EFLAGS: 00010246
        RAX: 000000000000006b RBX: ffff88103dfff000 RCX: 0000000000000000
        RDX: 0000000000000000 RSI: ffff88081f80dfa8 RDI: ffff88081f80dfa8
        RBP: ffff880816277c90 R08: 000000000000054c R09: 0000000000000000
        R10: 0000000000000005 R11: 0000000000000006 R12: 0000000000001000
        R13: ffff88103e000000 R14: ffff88103dffffff R15: 0000000000000001
        FS:  00007fb9d1750800(0000) GS:ffff88081f800000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 00000000021d2000 CR3: 000000081a08f000 CR4: 00000000001406f0
        Stack:
         ffff880816277cc8 0000000000010000 000000043de07000 0000000000000000
         0000000000001000 ffff880816277e60 0000000000001000 ffff880816277e28
         000000000000c000 0000000000001000 ffff880816277ce8 ffffffff8136c3a6
        Call Trace:
         [<ffffffff8136c3a6>] copy_page_to_iter_iovec+0xa6/0x1c0
         [<ffffffff8136e766>] copy_page_to_iter+0x16/0x90
         [<ffffffff811970e3>] generic_file_read_iter+0x3e3/0x7c0
         [<ffffffffa06a738d>] ? xfs_file_buffered_aio_write+0xad/0x260 [xfs]
         [<ffffffff816e6262>] ? down_read+0x12/0x40
         [<ffffffffa06a61b1>] xfs_file_buffered_aio_read+0x51/0xc0 [xfs]
         [<ffffffffa06a6692>] xfs_file_read_iter+0x62/0xb0 [xfs]
         [<ffffffff812224cf>] __vfs_read+0xdf/0x130
         [<ffffffff81222c9e>] vfs_read+0x8e/0x140
         [<ffffffff81224195>] SyS_read+0x55/0xc0
         [<ffffffff81003a47>] do_syscall_64+0x67/0x160
         [<ffffffff816e8421>] entry_SYSCALL64_slow_path+0x25/0x25
        RIP: 0033:[<00007fb9d0c33c00>] 0x7fb9d0c33c00
        RSP: 002b:00007ffc9c262f28 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
        RAX: ffffffffffffffda RBX: fffffffffff8ffff RCX: 00007fb9d0c33c00
        RDX: 0000000000010000 RSI: 00000000021c3000 RDI: 0000000000000004
        RBP: 00000000021c3000 R08: 0000000000000000 R09: 00007ffc9c264d6c
        R10: 00007ffc9c262c50 R11: 0000000000000246 R12: 0000000000010000
        R13: 00007ffc9c2630b0 R14: 0000000000000004 R15: 0000000000010000
        Code: 81 48 0f 44 d0 48 c7 c6 90 4d a3 81 48 c7 c0 bb b3 a2 81 48 0f 44 f0 4d 89 e1 48 89 d9 48 c7 c7 68 16 a3 81 31 c0 e8 f4 57 f7 ff <0f> 0b 48 8d 90 00 40 00 00 48 39 d3 0f 83 22 01 00 00 48 39 c3
        RIP  [<ffffffff8121c796>] __check_object_size+0x76/0x413
         RSP <ffff880816277c40>
      
      The checked object's range [ffff88103dfff000, ffff88103e000000) is
      valid, so there shouldn't have been a BUG.  The hardened usercopy code
      got confused because the range's ending address is the same as the
      kernel's text starting address at 0xffff88103e000000.  The overlap check
      is slightly off.
      
      Fixes: f5509cc1 ("mm: Hardened usercopy")
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: NKees Cook <keescook@chromium.org>
      94cd97af
    • E
      usercopy: avoid potentially undefined behavior in pointer math · 7329a655
      Eric Biggers 提交于
      check_bogus_address() checked for pointer overflow using this expression,
      where 'ptr' has type 'const void *':
      
      	ptr + n < ptr
      
      Since pointer wraparound is undefined behavior, gcc at -O2 by default
      treats it like the following, which would not behave as intended:
      
      	(long)n < 0
      
      Fortunately, this doesn't currently happen for kernel code because kernel
      code is compiled with -fno-strict-overflow.  But the expression should be
      fixed anyway to use well-defined integer arithmetic, since it could be
      treated differently by different compilers in the future or could be
      reported by tools checking for undefined behavior.
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NKees Cook <keescook@chromium.org>
      7329a655
    • L
      Merge tag 'arc-4.8-rc4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc · ef0e1ea8
      Linus Torvalds 提交于
      Pull ARC fixes from Vineet Gupta:
      
       - support for Syscall ABI v4 with upstream gcc 6.x
      
       - lockdep fix (Daniel Mentz)
      
       - gdb register clobber (Liav Rehana)
      
       - couple of missing exports for modules
      
       - other fixes here and there
      
      * tag 'arc-4.8-rc4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
        ARC: export __udivdi3 for modules
        ARC: mm: fix build breakage with STRICT_MM_TYPECHECKS
        ARC: export kmap
        ARC: Support syscall ABI v4
        ARC: use correct offset in pt_regs for saving/restoring user mode r25
        ARC: Elide redundant setup of DMA callbacks
        ARC: Call trace_hardirqs_on() before enabling irqs
      ef0e1ea8
    • L
      Merge tag 'gpio-v4.8-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio · 37c669b2
      Linus Torvalds 提交于
      Pull GPIO fixes from Linus Walleij:
       "Here are a few GPIO fixes for v4.8.
      
        I was expecting some fallout from the new chardev rework but nothing
        like that turned up att all.  Instead a Kconfig confusion that I think
        I have finally nailed, then some ordinary driver noise and trivia.
      
        This fixes a Kconfig issue with UM: when I made GPIOLIB available to
        all archs, that included UM, but the OF part of GPIOLIB requires
        HAS_IOMEM, so we add HAS_IOMEM as a dependency to OF_GPIO.
      
        This in turn exposed the fact that a few GPIO drivers were implicitly
        assuming OF_GPIO as their dependency but instead depended on OF alone
        (the typical problem being a pointer inside gpio_chip not existing
        unless OF_GPIO is selected) and then UM would fail to compile with
        these drivers instead.  Then I lost patience and made any GPIO driver
        depending on just OF depend on OF_GPIO instead, that is certainly what
        they meant and the only thing that makes sense anyway.  GPIO with just
        OF but !OF_GPIO does not make sense.
      
        Also a fix for the max730x driver data pointer, and a minor comment
        fix for the GPIO tools"
      
      * tag 'gpio-v4.8-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
        gpio: make any OF dependent driver depend on OF_GPIO
        gpio: Fix OF build problem on UM
        gpio: max730x: set gpiochip data pointer before using it
        tools/gpio: fix gpio-event-mon header comment
      37c669b2
  6. 22 8月, 2016 2 次提交