1. 18 11月, 2020 2 次提交
  2. 03 11月, 2020 1 次提交
  3. 27 10月, 2020 1 次提交
  4. 28 9月, 2020 9 次提交
  5. 26 9月, 2020 1 次提交
    • J
      drivers/net/ethernet: rid ethernet of no-prototype warnings · 553aca1c
      Jesse Brandeburg 提交于
      The W=1 builds showed a few files exporting functions
      (non-static) that were not prototyped. What actually happened is
      that there were prototypes, but the include file was forgotten in
      the implementation file.
      
      Add the include file and remove the warnings.
      
      Fixed Warnings:
      drivers/net/ethernet/cavium/liquidio/cn68xx_device.c:124:5: warning: no previous prototype for ‘lio_setup_cn68xx_octeon_device’ [-Wmissing-prototypes]
      drivers/net/ethernet/cavium/liquidio/octeon_mem_ops.c:159:1: warning: no previous prototype for ‘octeon_pci_read_core_mem’ [-Wmissing-prototypes]
      drivers/net/ethernet/cavium/liquidio/octeon_mem_ops.c:168:1: warning: no previous prototype for ‘octeon_pci_write_core_mem’ [-Wmissing-prototypes]
      drivers/net/ethernet/cavium/liquidio/octeon_mem_ops.c:176:5: warning: no previous prototype for ‘octeon_read_device_mem64’ [-Wmissing-prototypes]
      drivers/net/ethernet/cavium/liquidio/octeon_mem_ops.c:185:5: warning: no previous prototype for ‘octeon_read_device_mem32’ [-Wmissing-prototypes]
      drivers/net/ethernet/cavium/liquidio/octeon_mem_ops.c:194:6: warning: no previous prototype for ‘octeon_write_device_mem32’ [-Wmissing-prototypes]
      drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c:453:6: warning: no previous prototype for ‘hclge_dcb_ops_set’ [-Wmissing-prototypes]
      Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      553aca1c
  6. 25 9月, 2020 5 次提交
  7. 24 9月, 2020 1 次提交
    • R
      net: hns3: Constify static structs · e4b91468
      Rikard Falkeborn 提交于
      A number of static variables were not modified. Make them const to allow
      the compiler to put them in read-only memory. In order to do so,
      constify a couple of input pointers as well as some local pointers.
      This moves about 35Kb to read-only memory as seen by the output of the
      size command.
      
      Before:
         text    data     bss     dec     hex filename
       404938  111534     640  517112   7e3f8 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge.ko
      
      After:
         text    data     bss     dec     hex filename
       439499   76974     640  517113   7e3f9 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge.ko
      Signed-off-by: NRikard Falkeborn <rikard.falkeborn@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e4b91468
  8. 19 9月, 2020 1 次提交
  9. 09 9月, 2020 3 次提交
  10. 24 8月, 2020 1 次提交
  11. 08 8月, 2020 1 次提交
    • W
      mm, treewide: rename kzfree() to kfree_sensitive() · 453431a5
      Waiman Long 提交于
      As said by Linus:
      
        A symmetric naming is only helpful if it implies symmetries in use.
        Otherwise it's actively misleading.
      
        In "kzalloc()", the z is meaningful and an important part of what the
        caller wants.
      
        In "kzfree()", the z is actively detrimental, because maybe in the
        future we really _might_ want to use that "memfill(0xdeadbeef)" or
        something. The "zero" part of the interface isn't even _relevant_.
      
      The main reason that kzfree() exists is to clear sensitive information
      that should not be leaked to other future users of the same memory
      objects.
      
      Rename kzfree() to kfree_sensitive() to follow the example of the recently
      added kvfree_sensitive() and make the intention of the API more explicit.
      In addition, memzero_explicit() is used to clear the memory to make sure
      that it won't get optimized away by the compiler.
      
      The renaming is done by using the command sequence:
      
        git grep -w --name-only kzfree |\
        xargs sed -i 's/kzfree/kfree_sensitive/'
      
      followed by some editing of the kfree_sensitive() kerneldoc and adding
      a kzfree backward compatibility macro in slab.h.
      
      [akpm@linux-foundation.org: fs/crypto/inline_crypt.c needs linux/slab.h]
      [akpm@linux-foundation.org: fix fs/crypto/inline_crypt.c some more]
      Suggested-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NWaiman Long <longman@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Acked-by: NDavid Howells <dhowells@redhat.com>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
      Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Cc: James Morris <jmorris@namei.org>
      Cc: "Serge E. Hallyn" <serge@hallyn.com>
      Cc: Joe Perches <joe@perches.com>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Cc: "Jason A . Donenfeld" <Jason@zx2c4.com>
      Link: http://lkml.kernel.org/r/20200616154311.12314-3-longman@redhat.comSigned-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      453431a5
  12. 29 7月, 2020 2 次提交
  13. 22 7月, 2020 1 次提交
  14. 07 7月, 2020 1 次提交
  15. 31 5月, 2020 2 次提交
  16. 29 5月, 2020 7 次提交
  17. 28 5月, 2020 1 次提交