08 Aug, 2020

2 commits

  • …kernel/git/sre/linux-power-supply") into android-mainline

    Merges along the way to 5.9-rc1

    resolves conflicts in:
    Documentation/ABI/testing/sysfs-class-power
    drivers/power/supply/power_supply_sysfs.c
    fs/crypto/inline_crypt.c

    Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
    Change-Id: Ia087834f54fb4e5269d68c3c404747ceed240701

    Greg Kroah-Hartman
     
  • 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: Joe Perches
    Signed-off-by: Waiman Long
    Signed-off-by: Andrew Morton
    Acked-by: David Howells
    Acked-by: Michal Hocko
    Acked-by: Johannes Weiner
    Cc: Jarkko Sakkinen
    Cc: James Morris
    Cc: "Serge E. Hallyn"
    Cc: Joe Perches
    Cc: Matthew Wilcox
    Cc: David Rientjes
    Cc: Dan Carpenter
    Cc: "Jason A . Donenfeld"
    Link: http://lkml.kernel.org/r/20200616154311.12314-3-longman@redhat.com
    Signed-off-by: Linus Torvalds

    Waiman Long
     

12 Jun, 2020

1 commit


05 Jun, 2020

1 commit


02 Jun, 2020

1 commit

  • Pull documentation updates from Jonathan Corbet:
    "A fair amount of stuff this time around, dominated by yet another
    massive set from Mauro toward the completion of the RST conversion. I
    *really* hope we are getting close to the end of this. Meanwhile,
    those patches reach pretty far afield to update document references
    around the tree; there should be no actual code changes there. There
    will be, alas, more of the usual trivial merge conflicts.

    Beyond that we have more translations, improvements to the sphinx
    scripting, a number of additions to the sysctl documentation, and lots
    of fixes"

    * tag 'docs-5.8' of git://git.lwn.net/linux: (130 commits)
    Documentation: fixes to the maintainer-entry-profile template
    zswap: docs/vm: Fix typo accept_threshold_percent in zswap.rst
    tracing: Fix events.rst section numbering
    docs: acpi: fix old http link and improve document format
    docs: filesystems: add info about efivars content
    Documentation: LSM: Correct the basic LSM description
    mailmap: change email for Ricardo Ribalda
    docs: sysctl/kernel: document unaligned controls
    Documentation: admin-guide: update bug-hunting.rst
    docs: sysctl/kernel: document ngroups_max
    nvdimm: fixes to maintainter-entry-profile
    Documentation/features: Correct RISC-V kprobes support entry
    Documentation/features: Refresh the arch support status files
    Revert "docs: sysctl/kernel: document ngroups_max"
    docs: move locking-specific documents to locking/
    docs: move digsig docs to the security book
    docs: move the kref doc into the core-api book
    docs: add IRQ documentation at the core-api book
    docs: debugging-via-ohci1394.txt: add it to the core-api book
    docs: fix references for ipmi.rst file
    ...

    Linus Torvalds
     

08 May, 2020

1 commit

  • Instead of manually allocating a 'struct shash_desc' on the stack and
    calling crypto_shash_digest(), switch to using the new helper function
    crypto_shash_tfm_digest() which does this for us.

    Cc: ecryptfs@vger.kernel.org
    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers
     

21 Apr, 2020

1 commit

  • Some filesystem references got broken by a previous patch
    series I submitted. Address those.

    Signed-off-by: Mauro Carvalho Chehab
    Acked-by: David Sterba # fs/affs/Kconfig
    Link: https://lore.kernel.org/r/57318c53008dbda7f6f4a5a9e5787f4d37e8565a.1586881715.git.mchehab+huawei@kernel.org
    Signed-off-by: Jonathan Corbet

    Mauro Carvalho Chehab
     

24 Feb, 2020

1 commit


18 Feb, 2020

1 commit

  • Pull eCryptfs fixes from Tyler Hicks:

    - downgrade the eCryptfs maintenance status to "Odd Fixes"

    - change my email address

    - fix a couple memory leaks in error paths

    - stability improvement to avoid a needless BUG_ON()

    * tag 'ecryptfs-5.6-rc3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs:
    ecryptfs: replace BUG_ON with error handling code
    eCryptfs: Replace deactivated email address
    MAINTAINERS: eCryptfs: Update maintainer address and downgrade status
    ecryptfs: fix a memory leak bug in ecryptfs_init_messaging()
    ecryptfs: fix a memory leak bug in parse_tag_1_packet()

    Linus Torvalds
     

15 Feb, 2020

2 commits


10 Feb, 2020

1 commit


09 Feb, 2020

1 commit

  • Pull misc vfs updates from Al Viro:

    - bmap series from cmaiolino

    - getting rid of convolutions in copy_mount_options() (use a couple of
    copy_from_user() instead of the __get_user() crap)

    * 'work.misc' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
    saner copy_mount_options()
    fibmap: Reject negative block numbers
    fibmap: Use bmap instead of ->bmap method in ioctl_fibmap
    ecryptfs: drop direct calls to ->bmap
    cachefiles: drop direct usage of ->bmap method.
    fs: Enable bmap() function to properly return errors

    Linus Torvalds
     

03 Feb, 2020

1 commit


31 Jan, 2020

1 commit


11 Dec, 2019

1 commit

  • Due to the removal of the blkcipher and ablkcipher algorithm types,
    crypto_skcipher::keysize is now redundant since it always equals
    crypto_skcipher_alg(tfm)->max_keysize.

    Remove it and update crypto_skcipher_default_keysize() accordingly.

    Also rename crypto_skcipher_default_keysize() to
    crypto_skcipher_max_keysize() to clarify that it specifically returns
    the maximum key size, not some unspecified "default".

    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers
     

09 Dec, 2019

1 commit


02 Dec, 2019

1 commit

  • Pull removal of most of fs/compat_ioctl.c from Arnd Bergmann:
    "As part of the cleanup of some remaining y2038 issues, I came to
    fs/compat_ioctl.c, which still has a couple of commands that need
    support for time64_t.

    In completely unrelated work, I spent time on cleaning up parts of
    this file in the past, moving things out into drivers instead.

    After Al Viro reviewed an earlier version of this series and did a lot
    more of that cleanup, I decided to try to completely eliminate the
    rest of it and move it all into drivers.

    This series incorporates some of Al's work and many patches of my own,
    but in the end stops short of actually removing the last part, which
    is the scsi ioctl handlers. I have patches for those as well, but they
    need more testing or possibly a rewrite"

    * tag 'compat-ioctl-5.5' of git://git.kernel.org:/pub/scm/linux/kernel/git/arnd/playground: (42 commits)
    scsi: sd: enable compat ioctls for sed-opal
    pktcdvd: add compat_ioctl handler
    compat_ioctl: move SG_GET_REQUEST_TABLE handling
    compat_ioctl: ppp: move simple commands into ppp_generic.c
    compat_ioctl: handle PPPIOCGIDLE for 64-bit time_t
    compat_ioctl: move PPPIOCSCOMPRESS to ppp_generic
    compat_ioctl: unify copy-in of ppp filters
    tty: handle compat PPP ioctls
    compat_ioctl: move SIOCOUTQ out of compat_ioctl.c
    compat_ioctl: handle SIOCOUTQNSD
    af_unix: add compat_ioctl support
    compat_ioctl: reimplement SG_IO handling
    compat_ioctl: move WDIOC handling into wdt drivers
    fs: compat_ioctl: move FITRIM emulation into file systems
    gfs2: add compat_ioctl support
    compat_ioctl: remove unused convert_in_user macro
    compat_ioctl: remove last RAID handling code
    compat_ioctl: remove /dev/raw ioctl translation
    compat_ioctl: remove PCI ioctl translation
    compat_ioctl: remove joystick ioctl translation
    ...

    Linus Torvalds
     

18 Nov, 2019

1 commit


11 Nov, 2019

3 commits

  • We need to get the underlying dentry of parent; sure, absent the races
    it is the parent of underlying dentry, but there's nothing to prevent
    losing a timeslice to preemtion in the middle of evaluation of
    lower_dentry->d_parent->d_inode, having another process move lower_dentry
    around and have its (ex)parent not pinned anymore and freed on memory
    pressure. Then we regain CPU and try to fetch ->d_inode from memory
    that is freed by that point.

    dentry->d_parent *is* stable here - it's an argument of ->lookup() and
    we are guaranteed that it won't be moved anywhere until we feed it
    to d_add/d_splice_alias. So we safely go that way to get to its
    underlying dentry.

    Cc: stable@vger.kernel.org # since 2009 or so
    Signed-off-by: Al Viro

    Al Viro
     
  • lower_dentry can't go from positive to negative (we have it pinned),
    but it *can* go from negative to positive. So fetching ->d_inode
    into a local variable, doing a blocking allocation, checking that
    now ->d_inode is non-NULL and feeding the value we'd fetched
    earlier to a function that won't accept NULL is not a good idea.

    Cc: stable@vger.kernel.org
    Signed-off-by: Al Viro

    Al Viro
     
  • A problem similar to the one caught in commit 74dd7c97ea2a ("ecryptfs_rename():
    verify that lower dentries are still OK after lock_rename()") exists for
    unlink/rmdir as well.

    Instead of playing with dget_parent() of underlying dentry of victim
    and hoping it's the same as underlying dentry of our directory,
    do the following:
    * find the underlying dentry of victim
    * find the underlying directory of victim's parent (stable
    since the victim is ecryptfs dentry and inode of its parent is
    held exclusive by the caller).
    * lock the inode of dentry underlying the victim's parent
    * check that underlying dentry of victim is still hashed and
    has the right parent - it can be moved, but it can't be moved to/from
    the directory we are holding exclusive. So while ->d_parent itself
    might not be stable, the result of comparison is.

    If the check passes, everything is fine - underlying directory is locked,
    underlying victim is still a child of that directory and we can go ahead
    and feed them to vfs_unlink(). As in the current mainline we need to
    pin the underlying dentry of victim, so that it wouldn't go negative under
    us, but that's the only temporary reference that needs to be grabbed there.
    Underlying dentry of parent won't go away (it's pinned by the parent,
    which is held by caller), so there's no need to grab it.

    The same problem (with the same solution) exists for rmdir. Moreover,
    rename gets simpler and more robust with the same "don't bother with
    dget_parent()" approach.

    Fixes: 74dd7c97ea2 "ecryptfs_rename(): verify that lower dentries are still OK after lock_rename()"
    Signed-off-by: Al Viro

    Al Viro
     

06 Nov, 2019

1 commit

  • Add a flag option to get xattr method that could have a bit flag of
    XATTR_NOSECURITY passed to it. XATTR_NOSECURITY is generally then
    set in the __vfs_getxattr path when called by security
    infrastructure.

    This handles the case of a union filesystem driver that is being
    requested by the security layer to report back the xattr data.

    For the use case where access is to be blocked by the security layer.

    The path then could be security(dentry) ->
    __vfs_getxattr(dentry...XATTR_NOSECURITY) ->
    handler->get(dentry...XATTR_NOSECURITY) ->
    __vfs_getxattr(lower_dentry...XATTR_NOSECURITY) ->
    lower_handler->get(lower_dentry...XATTR_NOSECURITY)
    which would report back through the chain data and success as
    expected, the logging security layer at the top would have the
    data to determine the access permissions and report back the target
    context that was blocked.

    Without the get handler flag, the path on a union filesystem would be
    the errant security(dentry) -> __vfs_getxattr(dentry) ->
    handler->get(dentry) -> vfs_getxattr(lower_dentry) -> nested ->
    security(lower_dentry, log off) -> lower_handler->get(lower_dentry)
    which would report back through the chain no data, and -EACCES.

    For selinux for both cases, this would translate to a correctly
    determined blocked access. In the first case with this change a correct avc
    log would be reported, in the second legacy case an incorrect avc log
    would be reported against an uninitialized u:object_r:unlabeled:s0
    context making the logs cosmetically useless for audit2allow.

    This patch series is inert and is the wide-spread addition of the
    flags option for xattr functions, and a replacement of __vfs_getxattr
    with __vfs_getxattr(...XATTR_NOSECURITY).

    Signed-off-by: Mark Salyzyn
    Reviewed-by: Jan Kara
    Acked-by: Jan Kara
    Acked-by: Jeff Layton
    Acked-by: David Sterba
    Acked-by: Darrick J. Wong
    Acked-by: Mike Marshall
    Cc: Stephen Smalley
    Cc: linux-kernel@vger.kernel.org
    Cc: kernel-team@android.com
    Cc: linux-security-module@vger.kernel.org

    (cherry picked from (rejected from archive because of too many recipients))
    Signed-off-by: Mark Salyzyn
    Bug: 133515582
    Bug: 136124883
    Bug: 129319403
    Change-Id: Iabbb8771939d5f66667a26bb23ddf4c562c349a1

    Mark Salyzyn
     

23 Oct, 2019

1 commit


20 Aug, 2019

2 commits

  • In ecryptfs_init_messaging(), if the allocation for 'ecryptfs_msg_ctx_arr'
    fails, the previously allocated 'ecryptfs_daemon_hash' is not deallocated,
    leading to a memory leak bug. To fix this issue, free
    'ecryptfs_daemon_hash' before returning the error.

    Cc: stable@vger.kernel.org
    Fixes: 88b4a07e6610 ("[PATCH] eCryptfs: Public key transport mechanism")
    Signed-off-by: Wenwen Wang
    Signed-off-by: Tyler Hicks

    Wenwen Wang
     
  • In parse_tag_1_packet(), if tag 1 packet contains a key larger than
    ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES, no cleanup is executed, leading to a
    memory leak on the allocated 'auth_tok_list_item'. To fix this issue, go to
    the label 'out_free' to perform the cleanup work.

    Cc: stable@vger.kernel.org
    Fixes: dddfa461fc89 ("[PATCH] eCryptfs: Public key; packet management")
    Signed-off-by: Wenwen Wang
    Signed-off-by: Tyler Hicks

    Wenwen Wang
     

15 Jul, 2019

1 commit

  • Pull eCryptfs updates from Tyler Hicks:

    - Fix error handling when ecryptfs_read_lower() encounters an error

    - Fix read-only file creation when the eCryptfs mount is configured to
    store metadata in xattrs

    - Minor code cleanups

    * tag 'ecryptfs-5.3-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs:
    ecryptfs: Change return type of ecryptfs_process_flags
    ecryptfs: Make ecryptfs_xattr_handler static
    ecryptfs: remove unnessesary null check in ecryptfs_keyring_auth_tok_for_sig
    ecryptfs: use print_hex_dump_bytes for hexdump
    eCryptfs: fix permission denied with ecryptfs_xattr mount option when create readonly file
    ecryptfs: re-order a condition for static checkers
    eCryptfs: fix a couple type promotion bugs

    Linus Torvalds
     

11 Jul, 2019

1 commit

  • …el/git/dhowells/linux-fs"

    This reverts merge 0f75ef6a9cff49ff612f7ce0578bced9d0b38325 (and thus
    effectively commits

    7a1ade847596 ("keys: Provide KEYCTL_GRANT_PERMISSION")
    2e12256b9a76 ("keys: Replace uid/gid/perm permissions checking with an ACL")

    that the merge brought in).

    It turns out that it breaks booting with an encrypted volume, and Eric
    biggers reports that it also breaks the fscrypt tests [1] and loading of
    in-kernel X.509 certificates [2].

    The root cause of all the breakage is likely the same, but David Howells
    is off email so rather than try to work it out it's getting reverted in
    order to not impact the rest of the merge window.

    [1] https://lore.kernel.org/lkml/20190710011559.GA7973@sol.localdomain/
    [2] https://lore.kernel.org/lkml/20190710013225.GB7973@sol.localdomain/

    Link: https://lore.kernel.org/lkml/CAHk-=wjxoeMJfeBahnWH=9zShKp2bsVy527vo3_y8HfOdhwAAw@mail.gmail.com/
    Reported-by: Eric Biggers <ebiggers@kernel.org>
    Cc: David Howells <dhowells@redhat.com>
    Cc: James Morris <jmorris@namei.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

    Linus Torvalds
     

09 Jul, 2019

1 commit

  • Pull keyring ACL support from David Howells:
    "This changes the permissions model used by keys and keyrings to be
    based on an internal ACL by the following means:

    - Replace the permissions mask internally with an ACL that contains a
    list of ACEs, each with a specific subject with a permissions mask.
    Potted default ACLs are available for new keys and keyrings.

    ACE subjects can be macroised to indicate the UID and GID specified
    on the key (which remain). Future commits will be able to add
    additional subject types, such as specific UIDs or domain
    tags/namespaces.

    Also split a number of permissions to give finer control. Examples
    include splitting the revocation permit from the change-attributes
    permit, thereby allowing someone to be granted permission to revoke
    a key without allowing them to change the owner; also the ability
    to join a keyring is split from the ability to link to it, thereby
    stopping a process accessing a keyring by joining it and thus
    acquiring use of possessor permits.

    - Provide a keyctl to allow the granting or denial of one or more
    permits to a specific subject. Direct access to the ACL is not
    granted, and the ACL cannot be viewed"

    * tag 'keys-acl-20190703' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs:
    keys: Provide KEYCTL_GRANT_PERMISSION
    keys: Replace uid/gid/perm permissions checking with an ACL

    Linus Torvalds
     

03 Jul, 2019

1 commit

  • Change return type of ecryptfs_process_flags from int to void as it
    never fails.

    fixes below issue reported by coccicheck

    s/ecryptfs/crypto.c:870:5-7: Unneeded variable: "rc". Return "0" on line
    883

    Signed-off-by: Hariprasad Kelam
    [tyhicks: Remove the return value line from the function documentation]
    Signed-off-by: Tyler Hicks

    Hariprasad Kelam
     

28 Jun, 2019

1 commit

  • Replace the uid/gid/perm permissions checking on a key with an ACL to allow
    the SETATTR and SEARCH permissions to be split. This will also allow a
    greater range of subjects to represented.

    ============
    WHY DO THIS?
    ============

    The problem is that SETATTR and SEARCH cover a slew of actions, not all of
    which should be grouped together.

    For SETATTR, this includes actions that are about controlling access to a
    key:

    (1) Changing a key's ownership.

    (2) Changing a key's security information.

    (3) Setting a keyring's restriction.

    And actions that are about managing a key's lifetime:

    (4) Setting an expiry time.

    (5) Revoking a key.

    and (proposed) managing a key as part of a cache:

    (6) Invalidating a key.

    Managing a key's lifetime doesn't really have anything to do with
    controlling access to that key.

    Expiry time is awkward since it's more about the lifetime of the content
    and so, in some ways goes better with WRITE permission. It can, however,
    be set unconditionally by a process with an appropriate authorisation token
    for instantiating a key, and can also be set by the key type driver when a
    key is instantiated, so lumping it with the access-controlling actions is
    probably okay.

    As for SEARCH permission, that currently covers:

    (1) Finding keys in a keyring tree during a search.

    (2) Permitting keyrings to be joined.

    (3) Invalidation.

    But these don't really belong together either, since these actions really
    need to be controlled separately.

    Finally, there are number of special cases to do with granting the
    administrator special rights to invalidate or clear keys that I would like
    to handle with the ACL rather than key flags and special checks.

    ===============
    WHAT IS CHANGED
    ===============

    The SETATTR permission is split to create two new permissions:

    (1) SET_SECURITY - which allows the key's owner, group and ACL to be
    changed and a restriction to be placed on a keyring.

    (2) REVOKE - which allows a key to be revoked.

    The SEARCH permission is split to create:

    (1) SEARCH - which allows a keyring to be search and a key to be found.

    (2) JOIN - which allows a keyring to be joined as a session keyring.

    (3) INVAL - which allows a key to be invalidated.

    The WRITE permission is also split to create:

    (1) WRITE - which allows a key's content to be altered and links to be
    added, removed and replaced in a keyring.

    (2) CLEAR - which allows a keyring to be cleared completely. This is
    split out to make it possible to give just this to an administrator.

    (3) REVOKE - see above.

    Keys acquire ACLs which consist of a series of ACEs, and all that apply are
    unioned together. An ACE specifies a subject, such as:

    (*) Possessor - permitted to anyone who 'possesses' a key
    (*) Owner - permitted to the key owner
    (*) Group - permitted to the key group
    (*) Everyone - permitted to everyone

    Note that 'Other' has been replaced with 'Everyone' on the assumption that
    you wouldn't grant a permit to 'Other' that you wouldn't also grant to
    everyone else.

    Further subjects may be made available by later patches.

    The ACE also specifies a permissions mask. The set of permissions is now:

    VIEW Can view the key metadata
    READ Can read the key content
    WRITE Can update/modify the key content
    SEARCH Can find the key by searching/requesting
    LINK Can make a link to the key
    SET_SECURITY Can change owner, ACL, expiry
    INVAL Can invalidate
    REVOKE Can revoke
    JOIN Can join this keyring
    CLEAR Can clear this keyring

    The KEYCTL_SETPERM function is then deprecated.

    The KEYCTL_SET_TIMEOUT function then is permitted if SET_SECURITY is set,
    or if the caller has a valid instantiation auth token.

    The KEYCTL_INVALIDATE function then requires INVAL.

    The KEYCTL_REVOKE function then requires REVOKE.

    The KEYCTL_JOIN_SESSION_KEYRING function then requires JOIN to join an
    existing keyring.

    The JOIN permission is enabled by default for session keyrings and manually
    created keyrings only.

    ======================
    BACKWARD COMPATIBILITY
    ======================

    To maintain backward compatibility, KEYCTL_SETPERM will translate the
    permissions mask it is given into a new ACL for a key - unless
    KEYCTL_SET_ACL has been called on that key, in which case an error will be
    returned.

    It will convert possessor, owner, group and other permissions into separate
    ACEs, if each portion of the mask is non-zero.

    SETATTR permission turns on all of INVAL, REVOKE and SET_SECURITY. WRITE
    permission turns on WRITE, REVOKE and, if a keyring, CLEAR. JOIN is turned
    on if a keyring is being altered.

    The KEYCTL_DESCRIBE function translates the ACL back into a permissions
    mask to return depending on possessor, owner, group and everyone ACEs.

    It will make the following mappings:

    (1) INVAL, JOIN -> SEARCH

    (2) SET_SECURITY -> SETATTR

    (3) REVOKE -> WRITE if SETATTR isn't already set

    (4) CLEAR -> WRITE

    Note that the value subsequently returned by KEYCTL_DESCRIBE may not match
    the value set with KEYCTL_SETATTR.

    =======
    TESTING
    =======

    This passes the keyutils testsuite for all but a couple of tests:

    (1) tests/keyctl/dh_compute/badargs: The first wrong-key-type test now
    returns EOPNOTSUPP rather than ENOKEY as READ permission isn't removed
    if the type doesn't have ->read(). You still can't actually read the
    key.

    (2) tests/keyctl/permitting/valid: The view-other-permissions test doesn't
    work as Other has been replaced with Everyone in the ACL.

    Signed-off-by: David Howells

    David Howells
     

19 Jun, 2019

3 commits


05 Jun, 2019

1 commit

  • Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license version 2 as
    published by the free software foundation this program is
    distributed in the hope that it will be useful but without any
    warranty without even the implied warranty of merchantability or
    fitness for a particular purpose see the gnu general public license
    for more details you should have received a copy of the gnu general
    public license along with this program if not write to the free
    software foundation inc 59 temple place suite 330 boston ma 02111
    1307 usa

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-only

    has been chosen to replace the boilerplate/reference in 136 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Alexios Zavras
    Reviewed-by: Allison Randal
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190530000436.384967451@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

31 May, 2019

1 commit

  • Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation either version 2 of the license or at
    your option any later version this program is distributed in the
    hope that it will be useful but without any warranty without even
    the implied warranty of merchantability or fitness for a particular
    purpose see the gnu general public license for more details you
    should have received a copy of the gnu general public license along
    with this program if not write to the free software foundation inc
    59 temple place suite 330 boston ma 02111 1307 usa

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-or-later

    has been chosen to replace the boilerplate/reference in 1334 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Allison Randal
    Reviewed-by: Richard Fontana
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190527070033.113240726@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

21 May, 2019

1 commit


08 May, 2019

1 commit

  • Pull vfs inode freeing updates from Al Viro:
    "Introduction of separate method for RCU-delayed part of
    ->destroy_inode() (if any).

    Pretty much as posted, except that destroy_inode() stashes
    ->free_inode into the victim (anon-unioned with ->i_fops) before
    scheduling i_callback() and the last two patches (sockfs conversion
    and folding struct socket_wq into struct socket) are excluded - that
    pair should go through netdev once davem reopens his tree"

    * 'work.icache' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (58 commits)
    orangefs: make use of ->free_inode()
    shmem: make use of ->free_inode()
    hugetlb: make use of ->free_inode()
    overlayfs: make use of ->free_inode()
    jfs: switch to ->free_inode()
    fuse: switch to ->free_inode()
    ext4: make use of ->free_inode()
    ecryptfs: make use of ->free_inode()
    ceph: use ->free_inode()
    btrfs: use ->free_inode()
    afs: switch to use of ->free_inode()
    dax: make use of ->free_inode()
    ntfs: switch to ->free_inode()
    securityfs: switch to ->free_inode()
    apparmor: switch to ->free_inode()
    rpcpipe: switch to ->free_inode()
    bpf: switch to ->free_inode()
    mqueue: switch to ->free_inode()
    ufs: switch to ->free_inode()
    coda: switch to ->free_inode()
    ...

    Linus Torvalds
     

02 May, 2019

1 commit


25 Apr, 2019

1 commit

  • The flags field in 'struct shash_desc' never actually does anything.
    The only ostensibly supported flag is CRYPTO_TFM_REQ_MAY_SLEEP.
    However, no shash algorithm ever sleeps, making this flag a no-op.

    With this being the case, inevitably some users who can't sleep wrongly
    pass MAY_SLEEP. These would all need to be fixed if any shash algorithm
    actually started sleeping. For example, the shash_ahash_*() functions,
    which wrap a shash algorithm with the ahash API, pass through MAY_SLEEP
    from the ahash API to the shash API. However, the shash functions are
    called under kmap_atomic(), so actually they're assumed to never sleep.

    Even if it turns out that some users do need preemption points while
    hashing large buffers, we could easily provide a helper function
    crypto_shash_update_large() which divides the data into smaller chunks
    and calls crypto_shash_update() and cond_resched() for each chunk. It's
    not necessary to have a flag in 'struct shash_desc', nor is it necessary
    to make individual shash algorithms aware of this at all.

    Therefore, remove shash_desc::flags, and document that the
    crypto_shash_*() functions can be called from any context.

    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers