diff options
author | Thorsten Leemhuis <fedora@leemhuis.info> | 2017-10-12 07:21:33 +0200 |
---|---|---|
committer | Thorsten Leemhuis <fedora@leemhuis.info> | 2017-10-12 07:21:33 +0200 |
commit | a61cb6893506b1eac135da923ed2db58c5338986 (patch) | |
tree | f031cfd1668dfc417bf4b3768b6e8c94b31ba1e7 | |
parent | 7e3c26973862c2e602bb21076177f0c39d819676 (diff) | |
parent | 1c7a442bc63ebda0d6bbfbb2e4f2c8823cb30cf7 (diff) | |
download | kernel-4.14.0-0.rc4.git2.1.vanilla.knurd.1.fc28.tar.gz kernel-4.14.0-0.rc4.git2.1.vanilla.knurd.1.fc28.tar.xz kernel-4.14.0-0.rc4.git2.1.vanilla.knurd.1.fc28.zip |
Merge remote-tracking branch 'origin/master' into rawhide-user-thl-vanilla-fedorakernel-4.14.0-0.rc4.git2.1.vanilla.knurd.1.fc28kernel-4.14.0-0.rc4.git2.1.vanilla.knurd.1.fc27kernel-4.14.0-0.rc4.git2.1.vanilla.knurd.1.fc26kernel-4.14.0-0.rc4.git2.1.vanilla.knurd.1.fc25
-rw-r--r-- | KEYS-don-t-let-add_key-update-an-uninstantiated-key.patch | 130 | ||||
-rw-r--r-- | KEYS-fix-race-between-updating-and-finding-negative-.patch | 258 | ||||
-rw-r--r-- | drm-cma-reduce-dmesg-logs.patch | 96 | ||||
-rw-r--r-- | gitrev | 2 | ||||
-rw-r--r-- | kernel.spec | 17 | ||||
-rw-r--r-- | sources | 2 |
6 files changed, 502 insertions, 3 deletions
diff --git a/KEYS-don-t-let-add_key-update-an-uninstantiated-key.patch b/KEYS-don-t-let-add_key-update-an-uninstantiated-key.patch new file mode 100644 index 000000000..af7478ee5 --- /dev/null +++ b/KEYS-don-t-let-add_key-update-an-uninstantiated-key.patch @@ -0,0 +1,130 @@ +From 7289bfaee2a42bdb56eecab0625907c045d080ba Mon Sep 17 00:00:00 2001 +From: Eric Biggers <ebiggers@google.com> +Date: Wed, 27 Sep 2017 12:50:41 -0700 +Subject: [PATCH] KEYS: don't let add_key() update an uninstantiated key + +Currently, add_key() will, when passed a key that already exists, call +the key's ->update() method. But this is heavily broken in the case +where the key is uninstantiated because it doesn't call +__key_instantiate_and_link(). Consequently, it doesn't do most of the +things that are supposed to happen when the key is instantiated, such as +setting KEY_FLAG_INSTANTIATED, clearing KEY_FLAG_USER_CONSTRUCT and +awakening tasks waiting on it, and incrementing key->user->nikeys. + +It also never takes key_construction_mutex, which means that +->instantiate() can run concurrently with ->update() on the same key. +In the case of the "user" and "logon" key types this causes a memory +leak, at best. Maybe even worse, the ->update() methods of the +"encrypted" and "trusted" key types actually just dereference a NULL +pointer when passed an uninstantiated key. + +Therefore, change find_key_to_update() to return NULL if the found key +is uninstantiated, so that add_key() replaces the key rather than +instantiating it. This seems to be better than fixing __key_update() to +call __key_instantiate_and_link(), since given all the bugs noted above +as well as that the existing behavior was undocumented and +keyctl_instantiate() is supposed to be used instead, I doubt anyone was +relying on the existing behavior. + +This patch only affects *uninstantiated* keys. For now we still allow a +negatively instantiated key to be updated (thereby positively +instantiating it), although that's broken too (the next patch fixes it) +and I'm not sure that anyone actually uses that functionality either. + +Here is a simple reproducer for the bug using the "encrypted" key type +(requires CONFIG_ENCRYPTED_KEYS=y), though as noted above the bug +pertained to more than just the "encrypted" key type: + + #include <stdlib.h> + #include <unistd.h> + #include <keyutils.h> + + int main(void) + { + int ringid = keyctl_join_session_keyring(NULL); + + if (fork()) { + for (;;) { + const char payload[] = "update user:foo 32"; + + usleep(rand() % 10000); + add_key("encrypted", "desc", payload, sizeof(payload), ringid); + keyctl_clear(ringid); + } + } else { + for (;;) + request_key("encrypted", "desc", "callout_info", ringid); + } + } + +It causes: + + BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 + IP: encrypted_update+0xb0/0x170 + PGD 7a178067 P4D 7a178067 PUD 77269067 PMD 0 + PREEMPT SMP + CPU: 0 PID: 340 Comm: reproduce Tainted: G D 4.14.0-rc1-00025-g428490e38b2e #796 + Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 + task: ffff8a467a39a340 task.stack: ffffb15c40770000 + RIP: 0010:encrypted_update+0xb0/0x170 + RSP: 0018:ffffb15c40773de8 EFLAGS: 00010246 + RAX: 0000000000000000 RBX: ffff8a467a275b00 RCX: 0000000000000000 + RDX: 0000000000000005 RSI: ffff8a467a275b14 RDI: ffffffffb742f303 + RBP: ffffb15c40773e20 R08: 0000000000000000 R09: ffff8a467a275b17 + R10: 0000000000000020 R11: 0000000000000000 R12: 0000000000000000 + R13: 0000000000000000 R14: ffff8a4677057180 R15: ffff8a467a275b0f + FS: 00007f5d7fb08700(0000) GS:ffff8a467f200000(0000) knlGS:0000000000000000 + CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 + CR2: 0000000000000018 CR3: 0000000077262005 CR4: 00000000001606f0 + Call Trace: + key_create_or_update+0x2bc/0x460 + SyS_add_key+0x10c/0x1d0 + entry_SYSCALL_64_fastpath+0x1f/0xbe + RIP: 0033:0x7f5d7f211259 + RSP: 002b:00007ffed03904c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000f8 + RAX: ffffffffffffffda RBX: 000000003b2a7955 RCX: 00007f5d7f211259 + RDX: 00000000004009e4 RSI: 00000000004009ff RDI: 0000000000400a04 + RBP: 0000000068db8bad R08: 000000003b2a7955 R09: 0000000000000004 + R10: 000000000000001a R11: 0000000000000246 R12: 0000000000400868 + R13: 00007ffed03905d0 R14: 0000000000000000 R15: 0000000000000000 + Code: 77 28 e8 64 34 1f 00 45 31 c0 31 c9 48 8d 55 c8 48 89 df 48 8d 75 d0 e8 ff f9 ff ff 85 c0 41 89 c4 0f 88 84 00 00 00 4c 8b 7d c8 <49> 8b 75 18 4c 89 ff e8 24 f8 ff ff 85 c0 41 89 c4 78 6d 49 8b + RIP: encrypted_update+0xb0/0x170 RSP: ffffb15c40773de8 + CR2: 0000000000000018 + +Cc: <stable@vger.kernel.org> [v2.6.12+] +Signed-off-by: Eric Biggers <ebiggers@google.com> +--- + security/keys/keyring.c | 10 ++++++---- + 1 file changed, 6 insertions(+), 4 deletions(-) + +diff --git a/security/keys/keyring.c b/security/keys/keyring.c +index 4fa82a8a9c0e..129a4175760b 100644 +--- a/security/keys/keyring.c ++++ b/security/keys/keyring.c +@@ -1056,8 +1056,8 @@ EXPORT_SYMBOL(keyring_restrict); + * caller must also hold a lock on the keyring semaphore. + * + * Returns a pointer to the found key with usage count incremented if +- * successful and returns NULL if not found. Revoked and invalidated keys are +- * skipped over. ++ * successful and returns NULL if not found. Revoked, invalidated, and ++ * uninstantiated keys are skipped over. (But negative keys are not!) + * + * If successful, the possession indicator is propagated from the keyring ref + * to the returned key reference. +@@ -1084,8 +1084,10 @@ key_ref_t find_key_to_update(key_ref_t keyring_ref, + + found: + key = keyring_ptr_to_key(object); +- if (key->flags & ((1 << KEY_FLAG_INVALIDATED) | +- (1 << KEY_FLAG_REVOKED))) { ++ if ((key->flags & ((1 << KEY_FLAG_INVALIDATED) | ++ (1 << KEY_FLAG_REVOKED) | ++ (1 << KEY_FLAG_INSTANTIATED))) != ++ (1 << KEY_FLAG_INSTANTIATED)) { + kleave(" = NULL [x]"); + return NULL; + } +-- +2.13.6 + diff --git a/KEYS-fix-race-between-updating-and-finding-negative-.patch b/KEYS-fix-race-between-updating-and-finding-negative-.patch new file mode 100644 index 000000000..e72cdaf4a --- /dev/null +++ b/KEYS-fix-race-between-updating-and-finding-negative-.patch @@ -0,0 +1,258 @@ +From 4b244721c11c2f66052ceadd8ef6c48a53290e10 Mon Sep 17 00:00:00 2001 +From: Eric Biggers <ebiggers@google.com> +Date: Wed, 27 Sep 2017 12:50:42 -0700 +Subject: [PATCH] KEYS: fix race between updating and finding negative key + +In keyring_search_iterator() and in wait_for_key_construction(), we +check whether the key has been negatively instantiated, and if so return +the key's ->reject_error. + +However, no lock is held during this, and ->reject_error is in union +with ->payload. And it's impossible for KEY_FLAG_NEGATIVE to be updated +atomically with respect to ->reject_error and ->payload. + +Most problematically, when a negative key is positively instantiated via +__key_update() (via sys_add_key()), ->payload is initialized first, then +KEY_FLAG_NEGATIVE is cleared. But that means that ->reject_error can be +observed to have a bogus value, having been overwritten with ->payload, +while the key still appears to be "negative". Clearing +KEY_FLAG_NEGATIVE first wouldn't work either, since then anyone who +accesses the payload under rcu_read_lock() rather than the key semaphore +might observe an uninitialized ->payload. Nor can we just always take +the key's semaphore when checking whether the key is negative, since +keyring searches happen under rcu_read_lock(). + +Therefore, fix the bug by moving ->reject_error into the high bits of +->flags so that we can read and write it atomically with respect to +KEY_FLAG_NEGATIVE and KEY_FLAG_INSTANTIATED. + +This will also allow KEY_FLAG_NEGATIVE to be removed, since tests for +KEY_FLAG_NEGATIVE can be replaced with tests for nonzero reject_error. +But for ease of backporting this fix, that is left for a later patch. + +This fixes a kernel crash caused by the following program: + + #include <stdlib.h> + #include <unistd.h> + #include <keyutils.h> + + int main(void) + { + int ringid = keyctl_join_session_keyring(NULL); + + if (fork()) { + for (;;) { + usleep(rand() % 4096); + add_key("user", "desc", "x", 1, ringid); + keyctl_clear(ringid); + } + } else { + for (;;) + request_key("user", "desc", "", ringid); + } + } + +Here is the crash: + + BUG: unable to handle kernel paging request at fffffffffd39a6b0 + IP: __key_link_begin+0x0/0x100 + PGD 7a0a067 P4D 7a0a067 PUD 7a0c067 PMD 0 + Oops: 0000 [#1] SMP + CPU: 1 PID: 165 Comm: keyctl_negate_r Not tainted 4.14.0-rc1 #377 + Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-20170228_101828-anatol 04/01/2014 + task: ffff9791fd809140 task.stack: ffffacba402bc000 + RIP: 0010:__key_link_begin+0x0/0x100 + RSP: 0018:ffffacba402bfdc8 EFLAGS: 00010282 + RAX: ffff9791fd809140 RBX: fffffffffd39a620 RCX: 0000000000000008 + RDX: ffffacba402bfdd0 RSI: fffffffffd39a6a0 RDI: ffff9791fd810600 + RBP: ffffacba402bfdf8 R08: 0000000000000063 R09: ffffffff94845620 + R10: 8080808080808080 R11: 0000000000000004 R12: ffff9791fd810600 + R13: ffff9791fd39a940 R14: fffffffffd39a6a0 R15: 0000000000000000 + FS: 00007fbf14a90740(0000) GS:ffff9791ffd00000(0000) knlGS:0000000000000000 + CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 + CR2: fffffffffd39a6b0 CR3: 000000003b910003 CR4: 00000000003606e0 + Call Trace: + ? key_link+0x28/0xb0 + ? search_process_keyrings+0x13/0x100 + request_key_and_link+0xcb/0x550 + ? keyring_instantiate+0x110/0x110 + ? key_default_cmp+0x20/0x20 + SyS_request_key+0xc0/0x160 + ? exit_to_usermode_loop+0x5e/0x80 + entry_SYSCALL_64_fastpath+0x1a/0xa5 + RIP: 0033:0x7fbf14190bb9 + RSP: 002b:00007ffd8e4fe6c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000f9 + RAX: ffffffffffffffda RBX: 0000000036cc28fb RCX: 00007fbf14190bb9 + RDX: 000055748b56ca4a RSI: 000055748b56ca46 RDI: 000055748b56ca4b + RBP: 000055748b56ca4a R08: 0000000000000001 R09: 0000000000000001 + R10: 0000000036cc28fb R11: 0000000000000246 R12: 000055748b56c8b0 + R13: 00007ffd8e4fe7d0 R14: 0000000000000000 R15: 0000000000000000 + Code: c5 0f 85 69 ff ff ff 48 c7 c3 82 ff ff ff eb ab 45 31 ed e9 18 ff ff ff 85 c0 75 8d eb d2 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 <48> 83 7e 10 00 0f 84 c5 00 00 00 55 48 89 e5 41 57 41 56 41 55 + RIP: __key_link_begin+0x0/0x100 RSP: ffffacba402bfdc8 + CR2: fffffffffd39a6b0 + +Fixes: 146aa8b1453b ("KEYS: Merge the type-specific data with the payload data") +Cc: <stable@vger.kernel.org> [v4.4+] +Signed-off-by: Eric Biggers <ebiggers@google.com> +--- + include/linux/key.h | 12 +++++++++++- + security/keys/key.c | 26 +++++++++++++++++++------- + security/keys/keyctl.c | 3 +++ + security/keys/keyring.c | 4 ++-- + security/keys/request_key.c | 11 +++++++---- + 5 files changed, 42 insertions(+), 14 deletions(-) + +diff --git a/include/linux/key.h b/include/linux/key.h +index e315e16b6ff8..b7b590d7c480 100644 +--- a/include/linux/key.h ++++ b/include/linux/key.h +@@ -189,6 +189,17 @@ struct key { + #define KEY_FLAG_KEEP 10 /* set if key should not be removed */ + #define KEY_FLAG_UID_KEYRING 11 /* set if key is a user or user session keyring */ + ++ /* ++ * If the key is negatively instantiated, then bits 20-31 hold the error ++ * code which should be returned when someone tries to use the key ++ * (unless they allow negative keys). The error code is stored as a ++ * positive number, so it must be negated before being returned. ++ * ++ * Note that a key can go from negative to positive but not vice versa. ++ */ ++#define KEY_FLAGS_REJECT_ERROR_SHIFT 20 ++#define KEY_FLAGS_REJECT_ERROR_MASK 0xFFF00000 ++ + /* the key type and key description string + * - the desc is used to match a key against search criteria + * - it should be a printable string +@@ -213,7 +224,6 @@ struct key { + struct list_head name_link; + struct assoc_array keys; + }; +- int reject_error; + }; + + /* This is set on a keyring to restrict the addition of a link to a key +diff --git a/security/keys/key.c b/security/keys/key.c +index eb914a838840..786158d3442e 100644 +--- a/security/keys/key.c ++++ b/security/keys/key.c +@@ -401,6 +401,20 @@ int key_payload_reserve(struct key *key, size_t datalen) + } + EXPORT_SYMBOL(key_payload_reserve); + ++static void mark_key_instantiated(struct key *key, unsigned int reject_error) ++{ ++ unsigned long old, new; ++ ++ do { ++ old = READ_ONCE(key->flags); ++ new = (old & ~((1 << KEY_FLAG_NEGATIVE) | ++ KEY_FLAGS_REJECT_ERROR_MASK)) | ++ (1 << KEY_FLAG_INSTANTIATED) | ++ (reject_error ? (1 << KEY_FLAG_NEGATIVE) : 0) | ++ (reject_error << KEY_FLAGS_REJECT_ERROR_SHIFT); ++ } while (cmpxchg_release(&key->flags, old, new) != old); ++} ++ + /* + * Instantiate a key and link it into the target keyring atomically. Must be + * called with the target keyring's semaphore writelocked. The target key's +@@ -431,7 +445,7 @@ static int __key_instantiate_and_link(struct key *key, + if (ret == 0) { + /* mark the key as being instantiated */ + atomic_inc(&key->user->nikeys); +- set_bit(KEY_FLAG_INSTANTIATED, &key->flags); ++ mark_key_instantiated(key, 0); + + if (test_and_clear_bit(KEY_FLAG_USER_CONSTRUCT, &key->flags)) + awaken = 1; +@@ -580,10 +594,8 @@ int key_reject_and_link(struct key *key, + if (!test_bit(KEY_FLAG_INSTANTIATED, &key->flags)) { + /* mark the key as being negatively instantiated */ + atomic_inc(&key->user->nikeys); +- key->reject_error = -error; +- smp_wmb(); +- set_bit(KEY_FLAG_NEGATIVE, &key->flags); +- set_bit(KEY_FLAG_INSTANTIATED, &key->flags); ++ mark_key_instantiated(key, error); ++ + now = current_kernel_time(); + key->expiry = now.tv_sec + timeout; + key_schedule_gc(key->expiry + key_gc_delay); +@@ -753,7 +765,7 @@ static inline key_ref_t __key_update(key_ref_t key_ref, + ret = key->type->update(key, prep); + if (ret == 0) + /* updating a negative key instantiates it */ +- clear_bit(KEY_FLAG_NEGATIVE, &key->flags); ++ mark_key_instantiated(key, 0); + + up_write(&key->sem); + +@@ -987,7 +999,7 @@ int key_update(key_ref_t key_ref, const void *payload, size_t plen) + ret = key->type->update(key, &prep); + if (ret == 0) + /* updating a negative key instantiates it */ +- clear_bit(KEY_FLAG_NEGATIVE, &key->flags); ++ mark_key_instantiated(key, 0); + + up_write(&key->sem); + +diff --git a/security/keys/keyctl.c b/security/keys/keyctl.c +index 365ff85d7e27..19a09e121089 100644 +--- a/security/keys/keyctl.c ++++ b/security/keys/keyctl.c +@@ -1223,6 +1223,9 @@ long keyctl_reject_key(key_serial_t id, unsigned timeout, unsigned error, + error == ERESTART_RESTARTBLOCK) + return -EINVAL; + ++ BUILD_BUG_ON(MAX_ERRNO > (KEY_FLAGS_REJECT_ERROR_MASK >> ++ KEY_FLAGS_REJECT_ERROR_SHIFT)); ++ + /* the appropriate instantiation authorisation key must have been + * assumed before calling this */ + ret = -EPERM; +diff --git a/security/keys/keyring.c b/security/keys/keyring.c +index 129a4175760b..e54ad0ed7aa4 100644 +--- a/security/keys/keyring.c ++++ b/security/keys/keyring.c +@@ -598,8 +598,8 @@ static int keyring_search_iterator(const void *object, void *iterator_data) + if (ctx->flags & KEYRING_SEARCH_DO_STATE_CHECK) { + /* we set a different error code if we pass a negative key */ + if (kflags & (1 << KEY_FLAG_NEGATIVE)) { +- smp_rmb(); +- ctx->result = ERR_PTR(key->reject_error); ++ ctx->result = ERR_PTR(-(int)(kflags >> ++ KEY_FLAGS_REJECT_ERROR_SHIFT)); + kleave(" = %d [neg]", ctx->skipped_ret); + goto skipped; + } +diff --git a/security/keys/request_key.c b/security/keys/request_key.c +index 63e63a42db3c..0aab68344837 100644 +--- a/security/keys/request_key.c ++++ b/security/keys/request_key.c +@@ -590,15 +590,18 @@ struct key *request_key_and_link(struct key_type *type, + int wait_for_key_construction(struct key *key, bool intr) + { + int ret; ++ unsigned long flags; + + ret = wait_on_bit(&key->flags, KEY_FLAG_USER_CONSTRUCT, + intr ? TASK_INTERRUPTIBLE : TASK_UNINTERRUPTIBLE); + if (ret) + return -ERESTARTSYS; +- if (test_bit(KEY_FLAG_NEGATIVE, &key->flags)) { +- smp_rmb(); +- return key->reject_error; +- } ++ ++ /* Pairs with RELEASE in mark_key_instantiated() */ ++ flags = smp_load_acquire(&key->flags); ++ if (flags & (1 << KEY_FLAG_NEGATIVE)) ++ return -(int)(flags >> KEY_FLAGS_REJECT_ERROR_SHIFT); ++ + return key_validate(key); + } + EXPORT_SYMBOL(wait_for_key_construction); +-- +2.13.6 + diff --git a/drm-cma-reduce-dmesg-logs.patch b/drm-cma-reduce-dmesg-logs.patch new file mode 100644 index 000000000..2e39d6e70 --- /dev/null +++ b/drm-cma-reduce-dmesg-logs.patch @@ -0,0 +1,96 @@ +From patchwork Thu Oct 5 11:29:17 2017 +Content-Type: text/plain; charset="utf-8" +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +Subject: [v2] drm/gem-cma-helper: Change the level of the allocation failure + message +From: Boris Brezillon <boris.brezillon@free-electrons.com> +X-Patchwork-Id: 180737 +Message-Id: <20171005112917.15949-1-boris.brezillon@free-electrons.com> +To: David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>, + dri-devel@lists.freedesktop.org +Cc: Boris Brezillon <boris.brezillon@free-electrons.com> +Date: Thu, 5 Oct 2017 13:29:17 +0200 + +drm_gem_cma_create() prints an error message when dma_alloc_wc() fails to +allocate the amount of memory we requested. This can lead to annoying +error messages when CMA is only one possible source of memory for the BO +allocation. Turn this error message into a debug one. + +Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> +Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> +Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> +Reviewed-by: Eric Anholt <eric@anholt.net> +--- +Changes in v2: +- Remove __must_check attribute +--- + drivers/gpu/drm/drm_gem_cma_helper.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c b/drivers/gpu/drm/drm_gem_cma_helper.c +index 373e33f22be4..020e7668dfab 100644 +--- a/drivers/gpu/drm/drm_gem_cma_helper.c ++++ b/drivers/gpu/drm/drm_gem_cma_helper.c +@@ -112,7 +112,7 @@ struct drm_gem_cma_object *drm_gem_cma_create(struct drm_device *drm, + cma_obj->vaddr = dma_alloc_wc(drm->dev, size, &cma_obj->paddr, + GFP_KERNEL | __GFP_NOWARN); + if (!cma_obj->vaddr) { +- dev_err(drm->dev, "failed to allocate buffer with size %zu\n", ++ dev_dbg(drm->dev, "failed to allocate buffer with size %zu\n", + size); + ret = -ENOMEM; + goto error; +From patchwork Wed Oct 4 12:54:47 2017 +Content-Type: text/plain; charset="utf-8" +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +Subject: cma: Take __GFP_NOWARN into account in cma_alloc() +From: Boris Brezillon <boris.brezillon@free-electrons.com> +X-Patchwork-Id: 180554 +Message-Id: <20171004125447.15195-1-boris.brezillon@free-electrons.com> +To: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, + Laura Abbott <labbott@redhat.com> +Cc: Boris Brezillon <boris.brezillon@free-electrons.com>, + Jaewon Kim <jaewon31.kim@samsung.com>, dri-devel@lists.freedesktop.org +Date: Wed, 4 Oct 2017 14:54:47 +0200 + +cma_alloc() unconditionally prints an INFO message when the CMA +allocation fails. Make this message conditional on the non-presence of +__GFP_NOWARN in gfp_mask. + +Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> +Acked-by: Laura Abbott <labbott@redhat.com> +--- +Hello, + +This patch aims at removing INFO messages that are displayed when the +VC4 driver tries to allocate buffer objects. From the driver perspective +an allocation failure is acceptable, and the driver can possibly do +something to make following allocation succeed (like flushing the VC4 +internal cache). + +Also, I don't understand why this message is only an INFO message, and +not a WARN (pr_warn()). Please let me know if you have good reasons to +keep it as an unconditional pr_info(). + +Thanks, + +Boris +--- + mm/cma.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/mm/cma.c b/mm/cma.c +index c0da318c020e..022e52bd8370 100644 +--- a/mm/cma.c ++++ b/mm/cma.c +@@ -460,7 +460,7 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align, + + trace_cma_alloc(pfn, page, count, align); + +- if (ret) { ++ if (ret && !(gfp_mask & __GFP_NOWARN)) { + pr_info("%s: alloc failed, req-size: %zu pages, ret: %d\n", + __func__, count, ret); + cma_debug_show_areas(cma); @@ -1 +1 @@ -529a86e063e9ff625c4ff247d8aa17d8072444fb +56ae414e9d2718bcbfda9ba3797c39005e2f90fb diff --git a/kernel.spec b/kernel.spec index d324e45a5..16850c993 100644 --- a/kernel.spec +++ b/kernel.spec @@ -77,7 +77,7 @@ Summary: The Linux kernel # The rc snapshot level %global rcrev 4 # The git snapshot level -%define gitrev 1 +%define gitrev 2 # Set rpm version accordingly %define rpmversion 4.%{upstream_sublevel}.0 %endif @@ -594,6 +594,11 @@ Patch211: drm-i915-hush-check-crtc-state.patch # 300 - ARM patches +# Reduces a number of primarily info logs to dmesg +# https://patchwork.freedesktop.org/patch/180737/ +# https://patchwork.freedesktop.org/patch/180554/ +Patch300: drm-cma-reduce-dmesg-logs.patch + # http://www.spinics.net/lists/linux-tegra/msg26029.html Patch301: usb-phy-tegra-Add-38.4MHz-clock-table-entry.patch @@ -648,6 +653,10 @@ Patch332: arm64-socionext-96b-enablement.patch # CVE-2017-7477 rhbz 1445207 1445208 Patch502: CVE-2017-7477.patch +# rhbz 1498016 1498017 +Patch503: KEYS-don-t-let-add_key-update-an-uninstantiated-key.patch +Patch504: KEYS-fix-race-between-updating-and-finding-negative-.patch + # 600 - Patches for improved Bay and Cherry Trail device support # Below patches are submitted upstream, awaiting review / merging Patch601: 0001-Input-gpio_keys-Allow-suppression-of-input-events-fo.patch @@ -2217,6 +2226,12 @@ fi # # %changelog +* Wed Oct 11 2017 Jeremy Cline <jeremy@jcline.org> +- Fix incorrect updates of uninstantiated keys crash the kernel (rhbz 1498016 1498017) + +* Wed Oct 11 2017 Justin M. Forbes <jforbes@fedoraproject.org> - 4.14.0-0.rc4.git2.1 +- Linux v4.14-rc4-77-g56ae414e9d27 + * Tue Oct 10 2017 Justin M. Forbes <jforbes@fedoraproject.org> - 4.14.0-0.rc4.git1.1 - Linux v4.14-rc4-52-g529a86e063e9 - Reenable debugging options. @@ -1,4 +1,4 @@ SHA512 (linux-4.13.tar.xz) = a557c2f0303ae618910b7106ff63d9978afddf470f03cb72aa748213e099a0ecd5f3119aea6cbd7b61df30ca6ef3ec57044d524b7babbaabddf8b08b8bafa7d2 SHA512 (perf-man-4.13.tar.gz) = 9bcc2cd8e56ec583ed2d8e0b0c88e7a94035a1915e40b3177bb02d6c0f10ddd4df9b097b1f5af59efc624226b613e240ddba8ddc2156f3682f992d5455fc5c03 SHA512 (patch-4.14-rc4.xz) = 11edc0714c9b7ff34986d1534c490987f5977940afc5b176a424a23e437d572d83f8d689b4505128371bf6d4c5956a2042c9c4d222eb72363b977b69c819b3e3 -SHA512 (patch-4.14-rc4-git1.xz) = 5d48cd3028d1207c2d2df298fcb5b42c83eb3b55641a117506b9d0a90d45c9bea49b6aa46136d8bc0d47914afdb930eca500e9abcf7779e0e6fea6ef8598f499 +SHA512 (patch-4.14-rc4-git2.xz) = 96a5bbce69897d0a280dd0c86e95e9874c9062770f51b313b5838e690c8019482b8310a0c8614ad3bebf51d54b9ca5916fdc8f2e3527b434c364a023bbbc2719 |