1. 13 5月, 2015 1 次提交
  2. 10 5月, 2015 1 次提交
  3. 06 5月, 2015 6 次提交
  4. 30 4月, 2015 1 次提交
  5. 17 4月, 2015 1 次提交
    • M
      cxgb4: drop __GFP_NOFAIL allocation · f72f116a
      Michal Hocko 提交于
      set_filter_wr is requesting __GFP_NOFAIL allocation although it can return
      ENOMEM without any problems obviously (t4_l2t_set_switching does that
      already).  So the non-failing requirement is too strong without any
      obvious reason.  Drop __GFP_NOFAIL and reorganize the code to have the
      failure paths easier.
      
      The same applies to _c4iw_write_mem_dma_aligned which uses __GFP_NOFAIL
      and then checks the return value and returns -ENOMEM on failure.  This
      doesn't make any sense what so ever.  Either the allocation cannot fail or
      it can.
      
      del_filter_wr seems to be safe as well because the filter entry is not
      marked as pending and the return value is propagated up the stack up to
      c4iw_destroy_listen.
      Signed-off-by: NMichal Hocko <mhocko@suse.cz>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Dave Chinner <david@fromorbit.com>
      Cc: "Theodore Ts'o" <tytso@mit.edu>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Hariprasad S <hariprasad@chelsio.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f72f116a
  6. 16 4月, 2015 1 次提交
  7. 15 4月, 2015 5 次提交
  8. 10 4月, 2015 1 次提交
  9. 08 4月, 2015 1 次提交
  10. 02 4月, 2015 3 次提交
  11. 30 3月, 2015 4 次提交
  12. 25 3月, 2015 4 次提交
  13. 20 3月, 2015 2 次提交
  14. 11 3月, 2015 1 次提交
  15. 09 3月, 2015 1 次提交
  16. 06 3月, 2015 2 次提交
  17. 28 2月, 2015 1 次提交
  18. 21 2月, 2015 1 次提交
  19. 18 2月, 2015 1 次提交
  20. 10 2月, 2015 1 次提交
  21. 09 2月, 2015 1 次提交
    • H
      cxgb4: Fix trace observed while dumping clip_tbl · acde2c2d
      Hariprasad Shenai 提交于
      Handle clip_tbl debugfs entry, when clip_tbl isn't allocated.
      In commit b5a02f50 ("cxgb4: Update ipv6 address handling api") wrong
      argument was passed for single_open for clip_tbl debugfs entry, which led to
      below trace. Fixing it.
      
      ======
      call Trace:
       [<ffffffffa073c606>] clip_tbl_open+0x16/0x30 [cxgb4]
       [<ffffffff8119e2fa>] do_dentry_open+0x21a/0x370
       [<ffffffff8119e499>] vfs_open+0x49/0x50
       [<ffffffff811b0d0e>] do_last+0x21e/0x800
       [<ffffffff811b1382>] path_openat+0x92/0x470
       [<ffffffff8110569f>] ? rb_reserve_next_event+0xaf/0x380
       [<ffffffff8110569f>] ? rb_reserve_next_event+0xaf/0x380
       [<ffffffff811b189a>] do_filp_open+0x4a/0xa0
       [<ffffffff811bdc5d>] ? __alloc_fd+0xcd/0x140
       [<ffffffff8119fa4a>] do_sys_open+0x11a/0x230
       [<ffffffff8101219f>] ? syscall_trace_enter_phase2+0xaf/0x1b0
       [<ffffffff8119fb9e>] SyS_open+0x1e/0x20
       [<ffffffff815bf6f0>] tracesys_phase2+0xd4/0xd9
      Code: 89 e5 66 66 66 66 90 48 8b 47 e0 48 8b 40 30 48 8b 40 58 c9 c3 66 0f 1f
      84 00 00 00 00 00 55 48 89 e5 66 66 66 66 90 48 8b 47 e0 <48> 8b 40 58 c9 c3 66
      66 66 66 2e 0f 1f 84 00 00 00 00 00 55 48
      RIP  [<ffffffff8120898d>] PDE_DATA+0xd/0x20
       RSP <ffff8800b08c3c48>
      CR2: 0000000000000058
      
      =====
      Signed-off-by: NHariprasad Shenai <hariprasad@chelsio.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      acde2c2d