1. 22 Oct, 2016 1 commit
    • Linus Torvalds's avatar
      mm: remove gup_flags FOLL_WRITE games from __get_user_pages() · 16aa2763
      Linus Torvalds authored
      This is an ancient bug that was actually attempted to be fixed once
      (badly) by me eleven years ago in commit 4ceb5db9 ("Fix
      get_user_pages() race for write access") but that was then undone due to
      problems on s390 by commit f33ea7f4
      
       ("fix get_user_pages bug").
      
      In the meantime, the s390 situation has long been fixed, and we can now
      fix it by checking the pte_dirty() bit properly (and do it better).  The
      s390 dirty bit was implemented in abf09bed3cce ("s390/mm: implement
      software dirty bits") which made it into v3.9.  Earlier kernels will
      have to look at the page state itself.
      
      Also, the VM has become more scalable, and what used a purely
      theoretical race back then has become easier to trigger.
      
      To fix it, we introduce a new internal FOLL_COW flag to mark the "yes,
      we already did a COW" rather than play racy games with FOLL_WRITE that
      is very fundamental, and then use the pte dirty flag to validate that
      the FOLL_COW flag is still valid.
      
      Change-Id: Id9bec3722797dff7d0ff0d9f6097c4229e31fd62
      Reported-and-tested-by: default avatarPhil "not Paul" Oester <kernel@linuxace.com>
      Acked-by: default avatarHugh Dickins <hughd@google.com>
      Reviewed-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Willy Tarreau <w@1wt.eu>
      Cc: Nick Piggin <npiggin@gmail.com>
      Cc: Greg Thelen <gthelen@google.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [wt: s/gup.c/memory.c; s/follow_page_pte/follow_page_mask;
           s/faultin_page/__get_user_page]
      Signed-off-by: Willy Tarreau's avatarWilly Tarreau <w@1wt.eu>
      Signed-off-by: default avatarsndnvaps <sndnvaps@gmail.com>
      16aa2763
  2. 23 Sep, 2012 1 commit
    • Eric Dumazet's avatar
      Set default mtu to 64K · 86c32be4
      Eric Dumazet authored
      
      
      loopback current mtu of 16436 bytes allows no more than 3 MSS TCP
      segments per frame, or 48 Kbytes. Changing mtu to 64K allows TCP
      stack to build large frames and significantly reduces stack overhead.
      
      Performance boost on bulk TCP transferts can be up to 30 %, partly
      because we now have one ACK message for two 64KB segments, and a lower
      probability of hitting /proc/sys/net/ipv4/tcp_reordering default limit.
      
      Change-Id: I3064aa4d0cfaf1ad3ec04501fe6061d21e5f6a34
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: Aaron Segaert (flar2)'s avatarflar2 <asegaert@gmail.com>
      Signed-off-by: engstk's avatarengstk <eng.stk@sapo.pt>
      86c32be4
  3. 29 Apr, 2013 1 commit
    • Davidlohr Bueso's avatar
      Optimize square root algorithm · 0d3de9e0
      Davidlohr Bueso authored
      Optimize the current version of the shift-and-subtract (hardware)
      algorithm, described by John von Newmann[1] and Guy L Steele.
      
      Iterating 1,000,000 times, perf shows for the current version:
      
       Performance counter stats for './sqrt-curr' (10 runs):
      
               27.170996 task-clock                #    0.979 CPUs utilized            ( +-  3.19% )
                       3 context-switches          #    0.103 K/sec                    ( +-  4.76% )
                       0 cpu-migrations            #    0.004 K/sec                    ( +-100.00% )
                     104 page-faults               #    0.004 M/sec                    ( +-  0.16% )
              64,921,199 cycles                    #    2.389 GHz                      ( +-  0.03% )
              28,967,789 stalled-cycles-frontend   #   44.62% frontend cycles idle     ( +-  0.18% )
         <not supported> stalled-cycles-backend
             104,502,623 instructions              #    1.61  insns per cycle
                                                   #    0.28  stalled cycles per insn  ( +-  0.00% )
              34,088,368 branches                  # 1254.587 M/sec                    ( +-  0.00% )
                   4,901 branch-misses             #    0.01% of all branches          ( +-  1.32% )
      
             0.027763015 seconds time elapsed                                          ( +-  3.22% )
      
      And for the new version:
      
      Performance counter stats for './sqrt-new' (10 runs):
      
                0.496869 task-clock                #    0.519 CPUs utilized            ( +-  2.38% )
                       0 context-switches          #    0.000 K/sec
                       0 cpu-migrations            #    0.403 K/sec                    ( +-100.00% )
                     104 page-faults               #    0.209 M/sec                    ( +-  0.15% )
                 590,760 cycles                    #    1.189 GHz                      ( +-  2.35% )
                 395,053 stalled-cycles-frontend   #   66.87% frontend cycles idle     ( +-  3.67% )
         <not supported> stalled-cycles-backend
                 398,963 instructions              #    0.68  insns per cycle
                                                   #    0.99  stalled cycles per insn  ( +-  0.39% )
                  70,228 branches                  #  141.341 M/sec                    ( +-  0.36% )
                   3,364 branch-misses             #    4.79% of all branches          ( +-  5.45% )
      
             0.000957440 seconds time elapsed                                          ( +-  2.42% )
      
      Furthermore, this saves space in instruction text:
      
         text    data     bss     dec     hex filename
          111       0       0     111      6f lib/int_sqrt-baseline.o
           89       0       0      89      59 lib/int_sqrt.o
      
      [1] http://en.wikipedia.org/wiki/First_Draft_of_a_Report_on_the_EDVAC
      
      
      
      Change-Id: Ia3bce6e841d051b7409b4c8ebeee3c78b8446e6c
      Signed-off-by: default avatarDavidlohr Bueso <davidlohr.bueso@hp.com>
      Reviewed-by: default avatarJonathan Gonzalez <jgonzlez@linets.cl>
      Tested-by: default avatarJonathan Gonzalez <jgonzlez@linets.cl>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: Francisco Franco's avatarFrancisco Franco <franciscofranco.1990@gmail.com>
      Signed-off-by: engstk's avatarengstk <eng.stk@sapo.pt>
      0d3de9e0
  4. 26 Feb, 2015 1 commit
    • Ard Biesheuvel's avatar
      crypto: Update NEON AES module to latest OpenSSL version · 3c2ec8d6
      Ard Biesheuvel authored
      
      
      [ Upstream commit 001eabfd54c0cbf9d7d16264ddc8cc0bee67e3ed ]
      
      This updates the bit sliced AES module to the latest version in the
      upstream OpenSSL repository (e620e5ae37bc). This is needed to fix a
      bug in the XTS decryption path, where data chunked in a certain way
      could trigger the ciphertext stealing code, which is not supposed to
      be active in the kernel build (The kernel implementation of XTS only
      supports round multiples of the AES block size of 16 bytes, whereas
      the conformant OpenSSL implementation of XTS supports inputs of
      arbitrary size by applying ciphertext stealing). This is fixed in
      the upstream version by adding the missing #ifndef XTS_CHAIN_TWEAK
      around the offending instructions.
      
      The upstream code also contains the change applied by Russell to
      build the code unconditionally, i.e., even if __LINUX_ARM_ARCH__ < 7,
      but implemented slightly differently.
      
      Change-Id: Ie3ddc3a2be4686673ae77618f2896127b3385a4f
      Cc: stable@vger.kernel.org
      Fixes: e4e7f10bfc40 ("ARM: add support for bit sliced AES using NEON instructions")
      Reported-by: default avatarAdrian Kotelba <adrian.kotelba@gmail.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Tested-by: Milan Broz's avatarMilan Broz <gmazyland@gmail.com>
      Signed-off-by: Herbert Xu's avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      Signed-off-by: engstk's avatarengstk <eng.stk@sapo.pt>
      3c2ec8d6
  5. 02 Sep, 2016 1 commit
  6. 30 Aug, 2016 1 commit
  7. 26 Jul, 2014 1 commit
    • Linus Torvalds's avatar
      Fix gcc-4.9.0 miscompilation of load_balance() in scheduler · 2768baf6
      Linus Torvalds authored
      commit 2062afb4f804afef61cbe62a30cac9a46e58e067 upstream.
      
      Michel Dänzer and a couple of other people reported inexplicable random
      oopses in the scheduler, and the cause turns out to be gcc mis-compiling
      the load_balance() function when debugging is enabled.  The gcc bug
      apparently goes back to gcc-4.5, but slight optimization changes means
      that it now showed up as a problem in 4.9.0 and 4.9.1.
      
      The instruction scheduling problem causes gcc to schedule a spill
      operation to before the stack frame has been created, which in turn can
      corrupt the spilled value if an interrupt comes in.  There may be other
      effects of this bug too, but that's the code generation problem seen in
      Michel's case.
      
      This is fixed in current gcc HEAD, but the workaround as suggested by
      Markus Trippelsdorf is pretty simple: use -fno-var-tracking-assignments
      when compiling the kernel, which disables the gcc code that causes the
      problem.  This can result in slightly worse debug information for
      variable accesses, but that is infinitely preferable to actual code
      generation problems.
      
      Doing this unconditionally (not just for CONFIG_DEBUG_INFO) also allows
      non-debug builds to verify that the debug build would be identical: we
      can do
      
          export GCC_COMPARE_DEBUG=1
      
      to make gcc internally verify that the result of the build is
      independent of the "-g" flag (it will make the compiler build everything
      twice, toggling the debug flag, and compare the results).
      
      Without the "-fno-var-tracking-assignments" option, the build would fail
      (even with 4.8.3 that didn't show the actual stack frame bug) with a gcc
      compare failure.
      
      See also gcc bugzilla:
      
        https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801
      
      Reported-by: Michel Dänzer's avatarMichel Dänzer <michel@daenzer.net>
      Suggested-by: default avatarMarkus Trippelsdorf <markus@trippelsdorf.de>
      Cc: Jakub Jelinek <jakub@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2768baf6
  8. 28 Oct, 2015 1 commit
  9. 29 Aug, 2016 1 commit
    • BuGi's avatar
      Build modules with -fno-pic · a339f350
      BuGi authored
      Wifi/Radio is not turning on
      
      after swithcing to gcc 4.9 version wifi is not turning on due to
      relocation issue with symbols. to fix this issue gcc flags are added.
      a339f350
  10. 28 Aug, 2016 3 commits
  11. 14 Feb, 2014 1 commit
  12. 15 Aug, 2016 2 commits
    • BuGi's avatar
      msm: thermal: Revert simplified driver · cdf521a8
      BuGi authored
      The current simplified thermal driver is way too simplified,
      which leads to bad thermal control decisions.
      
      Some of the main flaws are:
       - Lack of a hysteresis for temperature determination
       - Lack of per-cpu sensor polling
      
      Switch back to the recommended configuration - thermal-engine
      in userspace + msm_thermal in kernel.
      
      This reverts commit fbcb232ee595521f748c951397bec810ce60d7fa.
      cdf521a8
    • BuGi's avatar
      Revert "msm_thermal: Recalculate Frequencies for JF" · 4ae9d2cf
      BuGi authored
      This reverts commit a52dd9417c28a71cee1a9fa78f75ad0635af577b.
      4ae9d2cf
  13. 22 Feb, 2016 1 commit
  14. 28 Jul, 2016 1 commit
  15. 22 Jul, 2016 2 commits
    • Jaegeuk Kim's avatar
      f2fs: adjust other changes · a801e224
      Jaegeuk Kim authored
      
      
      This patch changes:
      - d_inode
      - file_dentry
      - inode_nohighmem
      - ...
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      a801e224
    • Yunlei He's avatar
      f2fs: get victim segment again after new cp · a6df7d1a
      Yunlei He authored
      
      
      Previous selected segment may become free after write_checkpoint,
      if we do garbage collect on this segment, and then new_curseg happen
      to reuse it, it may cause f2fs_bug_on as below.
      
      	panic+0x154/0x29c
      	do_garbage_collect+0x15c/0xaf4
      	f2fs_gc+0x2dc/0x444
      	f2fs_balance_fs.part.22+0xcc/0x14c
      	f2fs_balance_fs+0x28/0x34
      	f2fs_map_blocks+0x5ec/0x790
      	f2fs_preallocate_blocks+0xe0/0x100
      	f2fs_file_write_iter+0x64/0x11c
      	new_sync_write+0xac/0x11c
      	vfs_write+0x144/0x1e4
      	SyS_write+0x60/0xc0
      
      Here, maybe we check sit and ssa type during reset_curseg. So, we check
      segment is stale or not, and select a new victim to avoid this.
      Signed-off-by: default avatarYunlei He <heyunlei@huawei.com>
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      a6df7d1a
  16. 20 Jul, 2016 2 commits
    • Jaegeuk Kim's avatar
      f2fs: handle error case with f2fs_bug_on · d2df5fee
      Jaegeuk Kim authored
      
      
      It's enough to show BUG or WARN by f2fs_bug_on for error case.
      Then, we don't need to remain corrupted filesystem.
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      d2df5fee
    • Jaegeuk Kim's avatar
      f2fs: avoid data race when deciding checkpoin in f2fs_sync_file · 08ecf2d5
      Jaegeuk Kim authored
      
      
      When fs utilization is almost full, f2fs_sync_file should do checkpoint if
      there is not enough space for roll-forward later. (i.e. space_for_roll_forward)
      So, currently we have no lock for sbi->alloc_valid_block_count, resulting in
      race condition.
      
      In rare case, we can get -ENOSPC when doing roll-forward which triggers
      
      	if (is_valid_blkaddr(sbi, dest, META_POR)) {
      		if (src == NULL_ADDR) {
      			err = reserve_new_block(&dn);
      			f2fs_bug_on(sbi, err);
      			...
      		}
      		...
      	}
      in do_recover_data.
      
      So, this patch avoids that situation in advance.
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      08ecf2d5
  17. 19 Jul, 2016 1 commit
  18. 17 Jul, 2016 1 commit
  19. 15 Jul, 2016 1 commit
    • Chao Yu's avatar
      f2fs: reset default idle interval value · c3193f70
      Chao Yu authored
      
      
      The default value of idle interval is 2 mins, but for most time when
      screen shutdown, there are still operations during the 2 mins interval,
      and gc's sleep time is about 30 secs to 60 secs, so there is almost no
      chance for GC thread to do garbage collecting.
      
      Set default value of idle interval value from 2 mins to 5 secs for
      fixing.
      Signed-off-by: default avatarChao Yu <yuchao0@huawei.com>
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      c3193f70
  20. 14 Jul, 2016 1 commit
  21. 13 Jul, 2016 1 commit
    • Chao Yu's avatar
      f2fs: fix to avoid data update racing between GC and DIO · 2d019890
      Chao Yu authored
      
      
      Datas in file can be operated by GC and DIO simultaneously, so we will
      face race case as below:
      
      For write case:
      Thread A				Thread B
      - generic_file_direct_write
       - invalidate_inode_pages2_range
       - f2fs_direct_IO
        - do_blockdev_direct_IO
         - do_direct_IO
          - get_more_blocks
      					- f2fs_gc
      					 - do_garbage_collect
      					  - gc_data_segment
      					   - move_data_page
      					    - do_write_data_page
      					    migrate data block to new block address
         - dio_bio_submit
         update user data to old block address
      
      For read case:
      Thread A                                Thread B
      - generic_file_direct_write
       - invalidate_inode_pages2_range
       - f2fs_direct_IO
        - do_blockdev_direct_IO
         - do_direct_IO
          - get_more_blocks
      					- f2fs_balance_fs
      					 - f2fs_gc
      					  - do_garbage_collect
      					   - gc_data_segment
      					    - move_data_page
      					     - do_write_data_page
      					     migrate data block to new block address
      					  - write_checkpoint
      					   - do_checkpoint
      					    - clear_prefree_segments
      					     - f2fs_issue_discard
                                                   discard old block adress
         - dio_bio_submit
         update user buffer from obsolete block address
      
      In order to fix this, for one file, we should let DIO and GC getting exclusion
      against with each other.
      Signed-off-by: default avatarChao Yu <yuchao0@huawei.com>
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      
       Conflicts:
      	fs/f2fs/data.c
      2d019890
  22. 14 Jul, 2016 1 commit
  23. 12 Jul, 2016 1 commit
  24. 09 Jul, 2016 1 commit
  25. 12 Jul, 2016 1 commit
  26. 01 Jul, 2016 1 commit
  27. 07 Jul, 2016 3 commits
    • Jaegeuk Kim's avatar
      f2fs: move i_size_write in f2fs_write_end · f22b1c1e
      Jaegeuk Kim authored
      
      
      We don't need to do i_size_write under page lock.
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      f22b1c1e
    • Chao Yu's avatar
      f2fs: fix to avoid redundant discard during fstrim · 778057fe
      Chao Yu authored
      
      
      With below test steps, f2fs will issue redundant discard when doing fstrim,
      the reason is that we issue discards for both prefree segments and
      consecutive freed region user wants to trim, part regions they covered are
      overlapped, here, we change to do not to issue any discards for prefree
      segments in trimmed range.
      
      1. mount -t f2fs -o discard /dev/zram0 /mnt/f2fs
      2. fstrim -o 0 -l 3221225472 -m 2097152 -v /mnt/f2fs/
      3. dd if=/dev/zero  of=/mnt/f2fs/a bs=2M count=1
      4. dd if=/dev/zero  of=/mnt/f2fs/b bs=1M count=1
      5. sync
      6. rm /mnt/f2fs/a /mnt/f2fs/b
      7. fstrim -o 0 -l 3221225472 -m 2097152 -v /mnt/f2fs/
      
      Before:
      <...>-5428  [001] ...1  9511.052125: f2fs_issue_discard: dev = (251,0), blkstart = 0x2200, blklen = 0x200
      <...>-5428  [001] ...1  9511.052787: f2fs_issue_discard: dev = (251,0), blkstart = 0x2200, blklen = 0x300
      
      After:
      <...>-6764  [000] ...1  9720.382504: f2fs_issue_discard: dev = (251,0), blkstart = 0x2200, blklen = 0x300
      Signed-off-by: default avatarChao Yu <yuchao0@huawei.com>
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      778057fe
    • Yunlei He's avatar
      f2fs: avoid mismatching block range for discard · 8f94066c
      Yunlei He authored
      
      
      This patch skip discard block range smaller than trim_minlen,
      and can not be merged by neighbour
      Signed-off-by: default avatarYunlei He <heyunlei@huawei.com>
      Reviewed-by: default avatarChao Yu <yuchao0@huawei.com>
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      8f94066c
  28. 06 Jul, 2016 1 commit
  29. 01 Jul, 2016 4 commits
  30. 27 Jun, 2016 1 commit