1. 01 12月, 2016 1 次提交
    • A
      fs: configfs: don't return anything from drop_link · e16769d4
      Andrzej Pietrasiewicz 提交于
      Documentation/filesystems/configfs/configfs.txt says:
      
      "When unlink(2) is called on the symbolic link, the source item is
      notified via the ->drop_link() method.  Like the ->drop_item() method,
      this is a void function and cannot return failure."
      
      The ->drop_item() is indeed a void function, the ->drop_link() is
      actually not. This, together with the fact that the value of ->drop_link()
      is silently ignored suggests, that it is the ->drop_link() return
      type that should be corrected and changed to void.
      
      This patch changes drop_link() signature and all its users.
      Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
      [hch: reverted reformatting of some code]
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      e16769d4
  2. 22 11月, 2016 1 次提交
  3. 19 11月, 2016 1 次提交
  4. 01 11月, 2016 1 次提交
  5. 28 10月, 2016 3 次提交
    • J
      genetlink: mark families as __ro_after_init · 56989f6d
      Johannes Berg 提交于
      Now genl_register_family() is the only thing (other than the
      users themselves, perhaps, but I didn't find any doing that)
      writing to the family struct.
      
      In all families that I found, genl_register_family() is only
      called from __init functions (some indirectly, in which case
      I've add __init annotations to clarifly things), so all can
      actually be marked __ro_after_init.
      
      This protects the data structure from accidental corruption.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      56989f6d
    • J
      genetlink: statically initialize families · 489111e5
      Johannes Berg 提交于
      Instead of providing macros/inline functions to initialize
      the families, make all users initialize them statically and
      get rid of the macros.
      
      This reduces the kernel code size by about 1.6k on x86-64
      (with allyesconfig).
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      489111e5
    • J
      genetlink: no longer support using static family IDs · a07ea4d9
      Johannes Berg 提交于
      Static family IDs have never really been used, the only
      use case was the workaround I introduced for those users
      that assumed their family ID was also their multicast
      group ID.
      
      Additionally, because static family IDs would never be
      reserved by the generic netlink code, using a relatively
      low ID would only work for built-in families that can be
      registered immediately after generic netlink is started,
      which is basically only the control family (apart from
      the workaround code, which I also had to add code for so
      it would reserve those IDs)
      
      Thus, anything other than GENL_ID_GENERATE is flawed and
      luckily not used except in the cases I mentioned. Move
      those workarounds into a few lines of code, and then get
      rid of GENL_ID_GENERATE entirely, making it more robust.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a07ea4d9
  6. 21 10月, 2016 5 次提交
  7. 20 10月, 2016 9 次提交
  8. 19 9月, 2016 1 次提交
  9. 16 9月, 2016 11 次提交
  10. 08 8月, 2016 1 次提交
  11. 26 7月, 2016 2 次提交
  12. 24 7月, 2016 2 次提交
  13. 21 7月, 2016 2 次提交