4.14.81-stable review
Subsystems (8)
Greg Kroah-Hartman
maintainerPATCH 164/222 smb3: allow stats which track session and share reconnects to be reset
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steve French <[email protected]>
commit 2c887635cd6ab3af619dc2be94e5bf8f2e172b78 upstream.
Currently, "echo 0 > /proc/fs/cifs/Stats" resets all of the stats except the session and share reconnect counts. Fix it to reset those as well.
--- fs/cifs/cifs_debug.c | 3 +++ 1 file changed, 3 insertions(+)
fs/cifs/cifs_debug.c +3 -0
@@ -289,6 +289,9 @@ static ssize_t cifs_stats_proc_write(stratomic_set (&totBufAllocCount,0 );atomic_set (&totSmBufAllocCount,0 );#endif /* CONFIG_CIFS_STATS2 */ +atomic_set (&tcpSesReconnectCount,0 ); +atomic_set (&tconInfoReconnectCount,0 ); +spin_lock (&GlobalMid_Lock); GlobalMaxActiveXid =0 ; GlobalCurrentXid =0 ;
Greg Kroah-Hartman
maintainerPATCH 165/222 smb3: do not attempt cifs operation in smb3 query info error path
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steve French <[email protected]>
commit 1e77a8c204c9d1b655c61751b8ad0fde22421dbb upstream.
If backupuid mount option is sent, we can incorrectly retry (on access denied on query info) with a cifs (FindFirst) operation on an smb3 mount which causes the server to force the session close.
We set backup intent on open so no need for this fallback.
See kernel bugzilla 201435
--- fs/cifs/inode.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
fs/cifs/inode.c +9 -1
@@ -776,7 +776,15 @@ cifs_get_inode_info(struct inode **inode }else if (rc == -EREMOTE ) {cifs_create_dfs_fattr (&fattr, sb); rc =0 ; - }else if (rc == -EACCES &&backup_cred (cifs_sb)) { + }else if ((rc == -EACCES ) &&backup_cred (cifs_sb) && + (strcmp (server->vals->version_string,SMB1_VERSION_STRING ) + ==0 )) { +/* +* For SMB2 and later the backup intent flag is already +* sent if needed on open and there is no path based +* FindFirst operation to use to retry with +*/ + srchinf =kzalloc (sizeof (struct cifs_search_info ),GFP_KERNEL );if (srchinf ==NULL ) {
Greg Kroah-Hartman
maintainerPATCH 166/222 smb3: on kerberos mount if server doesnt specify auth type use krb5
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steve French <[email protected]>
commit 926674de6705f0f1dbf29a62fd758d0977f535d6 upstream.
Some servers (e.g. Azure) do not include a spnego blob in the SMB3 negotiate protocol response, so on kerberos mounts ("sec=krb5") we can fail, as we expected the server to list its supported auth types (OIDs in the spnego blob in the negprot response). Change this so that on krb5 mounts we default to trying krb5 if the server doesn't list its supported protocol mechanisms.
--- fs/cifs/cifs_spnego.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
fs/cifs/cifs_spnego.c +4 -2
@@ -147,8 +147,10 @@ cifs_get_spnego_key(struct cifs_ses *sessprintf (dp,";sec=krb5" ); else if (server->sec_mskerberos) sprintf(dp, ";sec=mskrb5"); - else - goto out; + else { +cifs_dbg (VFS ,"unknown or missing server auth type, use krb5\n" ); +sprintf (dp,";sec=krb5" ); + } dp = description +strlen (description); sprintf(dp, ";uid=0x%x",
Greg Kroah-Hartman
maintainerPATCH 167/222 printk: Fix panic caused by passing log_buf_len to command line
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: He Zhe <[email protected]>
commit 277fcdb2cfee38ccdbe07e705dbd4896ba0c9930 upstream.
log_buf_len_setup does not check input argument before passing it to simple_strtoull. The argument would be a NULL pointer if "log_buf_len", without its value, is set in command line and thus causes the following panic.
PANIC: early exception 0xe3 IP 10:ffffffffaaeacd0d error 0 cr2 0x0
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.0-rc4-yocto-standard+ #1 [ 0.000000] RIP: 0010:_parse_integer_fixup_radix+0xd/0x70 ... [ 0.000000] Call Trace: [ 0.000000] simple_strtoull+0x29/0x70 [ 0.000000] memparse+0x26/0x90 [ 0.000000] log_buf_len_setup+0x17/0x22 [ 0.000000] do_early_param+0x57/0x8e [ 0.000000] parse_args+0x208/0x320 [ 0.000000] ? rdinit_setup+0x30/0x30 [ 0.000000] parse_early_options+0x29/0x2d [ 0.000000] ? rdinit_setup+0x30/0x30 [ 0.000000] parse_early_param+0x36/0x4d [ 0.000000] setup_arch+0x336/0x99e [ 0.000000] start_kernel+0x6f/0x4ee [ 0.000000] x86_64_start_reservations+0x24/0x26 [ 0.000000] x86_64_start_kernel+0x6f/0x72 [ 0.000000] secondary_startup_64+0xa4/0xb0
This patch adds a check to prevent the panic.
--- kernel/printk/printk.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
kernel/printk/printk.c +6 -1
@@ -1043,7 +1043,12 @@ static void __init log_buf_len_update(un/* save requested log_buf_len since it's too early to process it */ static int __init log_buf_len_setup (char *str) { -unsigned size =memparse (str, &str); +unsigned int size; + +if (!str) +return -EINVAL ; + + size =memparse (str, &str);log_buf_len_update (size);
Greg Kroah-Hartman
maintainerPATCH 168/222 genirq: Fix race on spurious interrupt detection
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lukas Wunner <[email protected]>
commit 746a923b863a1065ef77324e1e43f19b1a3eab5c upstream.
Commit 1e77d0a1ed74 ("genirq: Sanitize spurious interrupt detection of threaded irqs") made detection of spurious interrupts work for threaded handlers by:
a) incrementing a counter every time the thread returns IRQ_HANDLED, and
b) checking whether that counter has increased every time the thread is woken.
However for oneshot interrupts, the commit unmasks the interrupt before incrementing the counter. If another interrupt occurs right after unmasking but before the counter is incremented, that interrupt is incorrectly considered spurious:
time
| irq_thread() | irq_thread_fn() | action->thread_fn() | irq_finalize_oneshot() | unmask_threaded_irq() /* interrupt is unmasked */ | | /* interrupt fires, incorrectly deemed spurious */ | | atomic_inc(&desc->threads_handled); /* counter is incremented */
v
This is observed with a hi3110 CAN controller receiving data at high volume (from a separate machine sending with "cangen -g 0 -i -x"): The controller signals a huge number of interrupts (hundreds of millions per day) and every second there are about a dozen which are deemed spurious.
In theory with high CPU load and the presence of higher priority tasks, the number of incorrectly detected spurious interrupts might increase beyond the 99,900 threshold and cause disablement of the interrupt.
In practice it just increments the spurious interrupt count. But that can cause people to waste time investigating it over and over.
Fix it by moving the accounting before the invocation of irq_finalize_oneshot().
[ tglx: Folded change log update ]
--- kernel/irq/manage.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
kernel/irq/manage.c +6 -2
@@ -882,6 +882,9 @@ irq_forced_thread_fn(struct irq_desc *delocal_bh_disable (); ret = action->thread_fn (action->irq, action->dev_id); +if (ret ==IRQ_HANDLED ) +atomic_inc (&desc->threads_handled); +irq_finalize_oneshot (desc, action);local_bh_enable ();return ret;
@@ -898,6 +901,9 @@ static irqreturn_t irq_thread_fn(structirqreturn_t ret; ret = action->thread_fn (action->irq, action->dev_id); +if (ret ==IRQ_HANDLED ) +atomic_inc (&desc->threads_handled); +irq_finalize_oneshot (desc, action);return ret; }
@@ -975,8 +981,6 @@ static int irq_thread(void *data)irq_thread_check_affinity (desc, action); action_ret =handler_fn (desc, action); -if (action_ret ==IRQ_HANDLED ) -atomic_inc (&desc->threads_handled);if (action_ret ==IRQ_WAKE_THREAD )irq_wake_secondary (desc, action);
Greg Kroah-Hartman
maintainerPATCH 169/222 NFSv4.1: Fix the r/wsize checking
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Trond Myklebust <[email protected]>
commit 943cff67b842839f4f35364ba2db5c2d3f025d94 upstream.
The intention of nfs4_session_set_rwsize() was to cap the r/wsize to the buffer sizes negotiated by the CREATE_SESSION. The initial code had a bug whereby we would not check the values negotiated by nfs_probe_fsinfo() (the assumption being that CREATE_SESSION will always negotiate buffer values that are sane w.r.t. the server's preferred r/wsizes) but would only check values set by the user in the 'mount' command.
The code was changed in 4.11 to _always_ set the r/wsize, meaning that we now never use the server preferred r/wsizes. This is the regression that this patch fixes.
Also rename the function to nfs4_session_limit_rwsize() in order to avoid future confusion.
--- fs/nfs/nfs4client.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-)
fs/nfs/nfs4client.c +9 -7
@@ -925,10 +925,10 @@ EXPORT_SYMBOL_GPL(nfs4_set_ds_client);/* * Session has been established, and the client marked ready. -* Set the mount rsize and wsize with negotiated fore channel -* attributes which will be bound checked in nfs_server_set_fsinfo. +* Limit the mount rsize, wsize and dtsize using negotiated fore +* channel attributes. */ -static void nfs4_session_set_rwsize (struct nfs_server *server) +static void nfs4_session_limit_rwsize (struct nfs_server *server) {#ifdef CONFIG_NFS_V4_1 struct nfs4_session *sess;
@@ -941,9 +941,11 @@ static void nfs4_session_set_rwsize(stru server_resp_sz = sess->fc_attrs.max_resp_sz - nfs41_maxread_overhead; server_rqst_sz = sess->fc_attrs.max_rqst_sz - nfs41_maxwrite_overhead; -if (!server->rsize || server->rsize > server_resp_sz) +if (server->dtsize > server_resp_sz) + server->dtsize = server_resp_sz; +if (server->rsize > server_resp_sz) server->rsize = server_resp_sz; -if (!server->wsize || server->wsize > server_rqst_sz) +if (server->wsize > server_rqst_sz) server->wsize = server_rqst_sz;#endif /* CONFIG_NFS_V4_1 */ }
@@ -990,12 +992,12 @@ static int nfs4_server_common_setup(stru (unsigned long long) server->fsid.minor);nfs_display_fhandle (mntfh,"Pseudo-fs root FH" ); -nfs4_session_set_rwsize (server); - error =nfs_probe_fsinfo (server, mntfh, fattr);if (error <0 ) goto out; +nfs4_session_limit_rwsize (server); +if (server->namelen ==0 || server->namelen >NFS4_MAXNAMLEN ) server->namelen =NFS4_MAXNAMLEN ;
Greg Kroah-Hartman
maintainerPATCH 170/222 nfs: Fix a missed page unlock after pg_doio()
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Benjamin Coddington <[email protected]>
commit fdbd1a2e4a71adcb1ae219fcfd964930d77a7f84 upstream.
We must check pg_error and call error_cleanup after any call to pg_doio. Currently, we are skipping the unlock of a page if we encounter an error in nfs_pageio_complete() before handing off the work to the RPC layer.
--- fs/nfs/pagelist.c | 40 +++++++++++++++++++++------------------- 1 file changed, 21 insertions(+), 19 deletions(-)
fs/nfs/pagelist.c +21 -19
@@ -1110,6 +1110,20 @@ static int nfs_pageio_add_request_mirrorreturn ret; } +static void nfs_pageio_error_cleanup (struct nfs_pageio_descriptor *desc) +{ +u32 midx; +struct nfs_pgio_mirror *mirror; + +if (!desc->pg_error) +return ; + +for (midx =0 ; midx < desc->pg_mirror_count; midx++) { + mirror = &desc->pg_mirrors[midx]; + desc->pg_completion_ops->error_cleanup (&mirror->pg_list); + } +} +int nfs_pageio_add_request (struct nfs_pageio_descriptor *desc,struct nfs_page *req) {
@@ -1160,25 +1174,11 @@ int nfs_pageio_add_request(struct nfs_pareturn 1 ; out_failed: -/* -* We might have failed before sending any reqs over wire. -* Clean up rest of the reqs in mirror pg_list. -*/ -if (desc->pg_error) { -struct nfs_pgio_mirror *mirror; -void (*func)(struct list_head *); - -/* remember fatal errors */ -if (nfs_error_is_fatal (desc->pg_error)) -nfs_context_set_write_error (req->wb_context, - desc->pg_error); - - func = desc->pg_completion_ops->error_cleanup; -for (midx =0 ; midx < desc->pg_mirror_count; midx++) { - mirror = &desc->pg_mirrors[midx]; -func (&mirror->pg_list); - } - } +/* remember fatal errors */ +if (nfs_error_is_fatal (desc->pg_error)) +nfs_context_set_write_error (req->wb_context, + desc->pg_error); +nfs_pageio_error_cleanup (desc);return 0 ; }
@@ -1250,6 +1250,8 @@ void nfs_pageio_complete(struct nfs_pagefor (midx =0 ; midx < desc->pg_mirror_count; midx++)nfs_pageio_complete_mirror (desc, midx); +if (desc->pg_error <0 ) +nfs_pageio_error_cleanup (desc);if (desc->pg_ops->pg_cleanup) desc->pg_ops->pg_cleanup (desc);nfs_pageio_cleanup_mirroring (desc);
Greg Kroah-Hartman
maintainerPATCH 171/222 nfsd: Fix an Oops in free_session()
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Trond Myklebust <[email protected]>
commit bb6ad5572c0022e17e846b382d7413cdcf8055be upstream.
In call_xpt_users(), we delete the entry from the list, but we do not reinitialise it. This triggers the list poisoning when we later call unregister_xpt_user() in nfsd4_del_conns().
--- net/sunrpc/svc_xprt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/sunrpc/svc_xprt.c +1 -1
@@ -1040,7 +1040,7 @@ static void call_xpt_users(struct svc_xpspin_lock (&xprt->xpt_lock);while (!list_empty (&xprt->xpt_users)) { u = list_first_entry(&xprt->xpt_users, struct svc_xpt_user, list); -list_del (&u->list); +list_del_init (&u->list); u->callback (u); }spin_unlock (&xprt->xpt_lock);
Greg Kroah-Hartman
maintainerPATCH 172/222 lockd: fix access beyond unterminated strings in prints
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Amir Goldstein <[email protected]>
commit 93f38b6fae0ea8987e22d9e6c38f8dfdccd867ee upstream.
printk format used %*s instead of %.*s, so hostname_len does not limit the number of bytes accessed from hostname.
--- fs/lockd/host.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/lockd/host.c +1 -1
@@ -341,7 +341,7 @@ struct nlm_host *nlmsvc_lookup_host(cons };struct lockd_net *ln =net_generic (net, lockd_net_id); -dprintk ("lockd: %s(host='%*s', vers=%u, proto=%s)\n" , __func__, +dprintk ("lockd: %s(host='%.*s', vers=%u, proto=%s)\n" , __func__, (int )hostname_len, hostname, rqstp->rq_vers, (rqstp->rq_prot ==IPPROTO_UDP ?"udp" :"tcp" ));
Greg Kroah-Hartman
maintainerPATCH 173/222 dm ioctl: harden copy_params()s copy_from_user() from malicious users
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wenwen Wang <[email protected]>
commit 800a7340ab7dd667edf95e74d8e4f23a17e87076 upstream.
In copy_params(), the struct 'dm_ioctl' is first copied from the user space buffer 'user' to 'param_kernel' and the field 'data_size' is checked against 'minimum_data_size' (size of 'struct dm_ioctl' payload up to its 'data' member). If the check fails, an error code EINVAL will be returned. Otherwise, param_kernel->data_size is used to do a second copy, which copies from the same user-space buffer to 'dmi'. After the second copy, only 'dmi->data_size' is checked against 'param_kernel->data_size'. Given that the buffer 'user' resides in the user space, a malicious user-space process can race to change the content in the buffer between the two copies. This way, the attacker can inject inconsistent data into 'dmi' (versus previously validated 'param_kernel').
Fix redundant copying of 'minimum_data_size' from user-space buffer by using the first copy stored in 'param_kernel'. Also remove the 'data_size' check after the second copy because it is now unnecessary.
--- drivers/md/dm-ioctl.c | 18 ++++++------------ 1 file changed, 6 insertions(+), 12 deletions(-)
drivers/md/dm-ioctl.c +6 -12
@@ -1719,8 +1719,7 @@ static void free_params(struct dm_ioctl }static int copy_params (struct dm_ioctl __user *user,struct dm_ioctl *param_kernel, -int ioctl_flags, -struct dm_ioctl **param,int *param_flags) +int ioctl_flags,struct dm_ioctl **param,int *param_flags) {struct dm_ioctl *dmi;int secure_data;
@@ -1761,18 +1760,13 @@ static int copy_params(struct dm_ioctl _ *param_flags |=DM_PARAMS_MALLOC ; -if (copy_from_user (dmi, user, param_kernel->data_size)) - goto bad; +/* Copy from param_kernel (which was already copied from user) */ +memcpy (dmi, param_kernel, minimum_data_size); -data_copied: -/* -* Abort if something changed the ioctl data while it was being copied. -*/ -if (dmi->data_size != param_kernel->data_size) { -DMERR ("rejecting ioctl: data size modified while processing parameters" ); +if (copy_from_user (&dmi->data, (char __user *)user + minimum_data_size, + param_kernel->data_size - minimum_data_size)) goto bad; - } - +data_copied:/* Wipe the user buffer so we do not return it to userspace */ if (secure_data &&clear_user (user, param_kernel->data_size)) goto bad;
Greg Kroah-Hartman
maintainerPATCH 174/222 dm zoned: fix metadata block ref counting
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Damien Le Moal <[email protected]>
commit 33c2865f8d011a2ca9f67124ddab9dc89382e9f1 upstream.
Since the ref field of struct dmz_mblock is always used with the spinlock of struct dmz_metadata locked, there is no need to use an atomic_t type. Change the type of the ref field to an unsigne integer.
--- drivers/md/dm-zoned-metadata.c | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-)
drivers/md/dm-zoned-metadata.c +11 -9
@@ -99,7 +99,7 @@ struct dmz_mblock {struct rb_node node;struct list_head link;sector_t no; -atomic_t ref; +unsigned int ref;unsigned long state;struct page *page;void *data;
@@ -296,7 +296,7 @@ static struct dmz_mblock *dmz_alloc_mbloRB_CLEAR_NODE (&mblk->node);INIT_LIST_HEAD (&mblk->link); -atomic_set (&mblk->ref,0 ); + mblk->ref =0 ; mblk->state =0 ; mblk->no = mblk_no; mblk->data =page_address (mblk->page);
@@ -397,7 +397,7 @@ static struct dmz_mblock *dmz_fetch_mbloreturn NULL ;spin_lock (&zmd->mblk_lock); -atomic_inc (&mblk->ref); + mblk->ref++;set_bit (DMZ_META_READING , &mblk->state);dmz_insert_mblock (zmd, mblk);spin_unlock (&zmd->mblk_lock);
@@ -484,7 +484,8 @@ static void dmz_release_mblock(struct dmspin_lock (&zmd->mblk_lock); -if (atomic_dec_and_test (&mblk->ref)) { + mblk->ref--; +if (mblk->ref ==0 ) {if (test_bit (DMZ_META_ERROR , &mblk->state)) {rb_erase (&mblk->node, &zmd->mblk_rbtree);dmz_free_mblock (zmd, mblk);
@@ -511,7 +512,8 @@ static struct dmz_mblock *dmz_get_mblock mblk =dmz_lookup_mblock (zmd, mblk_no);if (mblk) {/* Cache hit: remove block from LRU list */ -if (atomic_inc_return (&mblk->ref) ==1 && + mblk->ref++; +if (mblk->ref ==1 && !test_bit (DMZ_META_DIRTY , &mblk->state))list_del_init (&mblk->link); }
@@ -753,7 +755,7 @@ int dmz_flush_metadata(struct dmz_metadaspin_lock (&zmd->mblk_lock);clear_bit (DMZ_META_DIRTY , &mblk->state); -if (atomic_read (&mblk->ref) ==0 ) +if (mblk->ref ==0 )list_add_tail (&mblk->link, &zmd->mblk_lru_list);spin_unlock (&zmd->mblk_lock); }
@@ -2308,7 +2310,7 @@ static void dmz_cleanup_metadata(struct mblk =list_first_entry (&zmd->mblk_dirty_list, struct dmz_mblock, link);dmz_dev_warn (zmd->dev,"mblock %llu still in dirty list (ref %u)" , - (u64 )mblk->no,atomic_read (&mblk->ref)); + (u64 )mblk->no, mblk->ref);list_del_init (&mblk->link);rb_erase (&mblk->node, &zmd->mblk_rbtree);dmz_free_mblock (zmd, mblk);
@@ -2326,8 +2328,8 @@ static void dmz_cleanup_metadata(struct root = &zmd->mblk_rbtree;rbtree_postorder_for_each_entry_safe (mblk, next, root, node) {dmz_dev_warn (zmd->dev,"mblock %llu ref %u still in rbtree" , - (u64 )mblk->no,atomic_read (&mblk->ref)); -atomic_set (&mblk->ref,0 ); + (u64 )mblk->no, mblk->ref); + mblk->ref =0 ;dmz_free_mblock (zmd, mblk); }
Greg Kroah-Hartman
maintainerPATCH 175/222 dm zoned: fix various dmz_get_mblock() issues
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Damien Le Moal <[email protected]>
commit 3d4e738311327bc4ba1d55fbe2f1da3de4a475f9 upstream.
dmz_fetch_mblock() called from dmz_get_mblock() has a race since the allocation of the new metadata block descriptor and its insertion in the cache rbtree with the READING state is not atomic. Two different contexts requesting the same block may end up each adding two different descriptors of the same block to the cache.
Another problem for this function is that the BIO for processing the block read is allocated after the metadata block descriptor is inserted in the cache rbtree. If the BIO allocation fails, the metadata block descriptor is freed without first being removed from the rbtree.
Fix the first problem by checking again if the requested block is not in the cache right before inserting the newly allocated descriptor, atomically under the mblk_lock spinlock. The second problem is fixed by simply allocating the BIO before inserting the new block in the cache.
Finally, since dmz_fetch_mblock() also increments a block reference counter, rename the function to dmz_get_mblock_slow(). To be symmetric and clear, also rename dmz_lookup_mblock() to dmz_get_mblock_fast() and increment the block reference counter directly in that function rather than in dmz_get_mblock().
--- drivers/md/dm-zoned-metadata.c | 66 ++++++++++++++++++++++++++--------------- 1 file changed, 42 insertions(+), 24 deletions(-)
drivers/md/dm-zoned-metadata.c +42 -24
@@ -339,10 +339,11 @@ static void dmz_insert_mblock(struct dmz }/* -* Lookup a metadata block in the rbtree. +* Lookup a metadata block in the rbtree. If the block is found, increment +* its reference count. */ -static struct dmz_mblock *dmz_lookup_mblock (struct dmz_metadata *zmd, -sector_t mblk_no) +static struct dmz_mblock *dmz_get_mblock_fast (struct dmz_metadata *zmd, +sector_t mblk_no) {struct rb_root *root = &zmd->mblk_rbtree;struct rb_node *node = root->rb_node;
@@ -350,8 +351,17 @@ static struct dmz_mblock *dmz_lookup_mblwhile (node) { mblk = container_of(node, struct dmz_mblock, node); -if (mblk->no == mblk_no) +if (mblk->no == mblk_no) { +/* +* If this is the first reference to the block, +* remove it from the LRU list. +*/ + mblk->ref++; +if (mblk->ref ==1 && + !test_bit (DMZ_META_DIRTY , &mblk->state)) +list_del_init (&mblk->link);return mblk; + } node = (mblk->no < mblk_no) ? node->rb_left : node->rb_right; }
@@ -382,32 +392,47 @@ static void dmz_mblock_bio_end_io(struct }/* -* Read a metadata block from disk. +* Read an uncached metadata block from disk and add it to the cache. */ -static struct dmz_mblock *dmz_fetch_mblock (struct dmz_metadata *zmd, -sector_t mblk_no) +static struct dmz_mblock *dmz_get_mblock_slow (struct dmz_metadata *zmd, +sector_t mblk_no) { -struct dmz_mblock *mblk; +struct dmz_mblock *mblk, *m;sector_t block = zmd->sb[zmd->mblk_primary].block + mblk_no;struct bio *bio; -/* Get block and insert it */ +/* Get a new block and a BIO to read it */ mblk =dmz_alloc_mblock (zmd, mblk_no);if (!mblk)return NULL ; -spin_lock (&zmd->mblk_lock); - mblk->ref++; -set_bit (DMZ_META_READING , &mblk->state); -dmz_insert_mblock (zmd, mblk); -spin_unlock (&zmd->mblk_lock); - bio =bio_alloc (GFP_NOIO ,1 );if (!bio) {dmz_free_mblock (zmd, mblk);return NULL ; } +spin_lock (&zmd->mblk_lock); + +/* +* Make sure that another context did not start reading +* the block already. +*/ + m =dmz_get_mblock_fast (zmd, mblk_no); +if (m) { +spin_unlock (&zmd->mblk_lock); +dmz_free_mblock (zmd, mblk); +bio_put (bio); +return m; + } + + mblk->ref++; +set_bit (DMZ_META_READING , &mblk->state); +dmz_insert_mblock (zmd, mblk); + +spin_unlock (&zmd->mblk_lock); + +/* Submit read BIO */ bio->bi_iter.bi_sector =dmz_blk2sect (block);bio_set_dev (bio, zmd->dev->bdev); bio->bi_private = mblk;
@@ -509,19 +534,12 @@ static struct dmz_mblock *dmz_get_mblock/* Check rbtree */ spin_lock (&zmd->mblk_lock); - mblk =dmz_lookup_mblock (zmd, mblk_no); -if (mblk) { -/* Cache hit: remove block from LRU list */ - mblk->ref++; -if (mblk->ref ==1 && - !test_bit (DMZ_META_DIRTY , &mblk->state)) -list_del_init (&mblk->link); - } + mblk =dmz_get_mblock_fast (zmd, mblk_no);spin_unlock (&zmd->mblk_lock);if (!mblk) {/* Cache miss: read the block from disk */ - mblk =dmz_fetch_mblock (zmd, mblk_no); + mblk =dmz_get_mblock_slow (zmd, mblk_no);if (!mblk)return ERR_PTR (-ENOMEM ); }
Greg Kroah-Hartman
maintainerPATCH 176/222 powerpc/msi: Fix compile error on mpc83xx
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe Leroy <[email protected]>
commit 0f99153def98134403c9149128e59d3e1786cf04 upstream.
mpic_get_primary_version() is not defined when not using MPIC. The compile error log like:
arch/powerpc/sysdev/built-in.o: In function `fsl_of_msi_probe':
fsl_msi.c:(.text+0x150c): undefined reference to `fsl_mpic_primary_get_version'
--- arch/powerpc/include/asm/mpic.h | 7 +++++++ 1 file changed, 7 insertions(+)
arch/powerpc/include/asm/mpic.h +7 -0
@@ -393,7 +393,14 @@ extern struct bus_type mpic_subsys;#define MPIC_REGSET_TSI108 MPIC_REGSET(1)/* Tsi108/109 PIC */ /* Get the version of primary MPIC */ +#ifdef CONFIG_MPIC extern u32 fsl_mpic_primary_get_version (void ); +#else +static inline u32 fsl_mpic_primary_get_version (void ) +{ +return 0 ; +} +#endif /* Allocate the controller structure and setup the linux irq descs * for the range if interrupts passed in. No HW initialization is
Greg Kroah-Hartman
maintainerPATCH 177/222 MIPS: OCTEON: fix out of bounds array access on CN68XX
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aaro Koskinen <[email protected]>
commit c0fae7e2452b90c31edd2d25eb3baf0c76b400ca upstream.
The maximum number of interfaces is returned by cvmx_helper_get_number_of_interfaces(), and the value is used to access interface_port_count[]. When CN68XX support was added, we forgot to increase the array size. Fix that.
Patchwork: https://patchwork.linux-mips.org/patch/20949/
--- arch/mips/cavium-octeon/executive/cvmx-helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/mips/cavium-octeon/executive/cvmx-helper.c +1 -1
@@ -67,7 +67,7 @@ void (*cvmx_override_pko_queue_priority)void (*cvmx_override_ipd_port_setup) (int ipd_port);/* Port count per interface */ -static int interface_port_count[5 ]; +static int interface_port_count[9 ];/** * Return the number of interfaces the chip has. Each interface
Greg Kroah-Hartman
maintainerPATCH 178/222 iommu/arm-smmu: Ensure that page-table updates are visible before TLBI
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Will Deacon <[email protected]>
commit 7d321bd3542500caf125249f44dc37cb4e738013 upstream.
The IO-pgtable code relies on the driver TLB invalidation callbacks to ensure that all page-table updates are visible to the IOMMU page-table walker.
In the case that the page-table walker is cache-coherent, we cannot rely on an implicit DSB from the DMA-mapping code, so we must ensure that we execute a DSB in our tlb_add_flush() callback prior to triggering the invalidation.
--- drivers/iommu/arm-smmu.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/iommu/arm-smmu.c +6 -0
@@ -475,6 +475,9 @@ static void arm_smmu_tlb_inv_range_nosynbool stage1 = cfg->cbar !=CBAR_TYPE_S2_TRANS ;void __iomem *reg =ARM_SMMU_CB (smmu_domain->smmu, cfg->cbndx); +if (smmu_domain->smmu->features &ARM_SMMU_FEAT_COHERENT_WALK ) +wmb (); +if (stage1) { reg += leaf ?ARM_SMMU_CB_S1_TLBIVAL :ARM_SMMU_CB_S1_TLBIVA ;
@@ -516,6 +519,9 @@ static void arm_smmu_tlb_inv_vmid_nosyncstruct arm_smmu_domain *smmu_domain = cookie;void __iomem *base =ARM_SMMU_GR0 (smmu_domain->smmu); +if (smmu_domain->smmu->features &ARM_SMMU_FEAT_COHERENT_WALK ) +wmb (); +writel_relaxed (smmu_domain->cfg.vmid, base +ARM_SMMU_GR0_TLBIVMID ); }
Greg Kroah-Hartman
maintainerPATCH 179/222 TC: Set DMA masks for devices
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maciej W. Rozycki <[email protected]>
commit 3f2aa244ee1a0d17ed5b6c86564d2c1b24d1c96b upstream.
Fix a TURBOchannel support regression with commit 205e1b7f51e4 ("dma-mapping: warn when there is no coherent_dma_mask") that caused coherent DMA allocations to produce a warning such as:
defxx: v1.11 2014/07/01 Lawrence V. Stefani and others
tc1: DEFTA at MMIO addr = 0x1e900000, IRQ = 20, Hardware addr = 08-00-2b-a3-a3-29
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 dfx_dev_register+0x670/0x678
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.19.0-rc6 #2
Stack : ffffffff8009ffc0 fffffffffffffec0 0000000000000000 ffffffff80647650
0000000000000000 0000000000000000 ffffffff806f5f80 ffffffffffffffff
0000000000000000 0000000000000000 0000000000000001 ffffffff8065d4e8
98000000031b6300 ffffffff80563478 ffffffff805685b0 ffffffffffffffff
0000000000000000 ffffffff805d6720 0000000000000204 ffffffff80388df8
0000000000000000 0000000000000009 ffffffff8053efd0 ffffffff806657d0
0000000000000000 ffffffff803177f8 0000000000000000 ffffffff806d0000
9800000003078000 980000000307b9e0 000000001e900000 ffffffff80067940
0000000000000000 ffffffff805d6720 0000000000000204 ffffffff80388df8
ffffffff805176c0 ffffffff8004dc78 0000000000000000 ffffffff80067940
...
Call Trace:
[<ffffffff8004dc78>] show_stack+0xa0/0x130
[<ffffffff80067940>] __warn+0x128/0x170
---[ end trace b1d1e094f67f3bb2 ]---This is because the TURBOchannel bus driver fails to set the coherent DMA mask for devices enumerated.
Set the regular and coherent DMA masks for TURBOchannel devices then, observing that the bus protocol supports a 34-bit (16GiB) DMA address space, by interpreting the value presented in the address cycle across the 32 `ad' lines as a 32-bit word rather than byte address[1]. The architectural size of the TURBOchannel DMA address space exceeds the maximum amount of RAM any actual TURBOchannel system in existence may have, hence both masks are the same.
This removes the warning shown above.
References:
[1] "TURBOchannel Hardware Specification", EK-369AA-OD-007B, Digital
Equipment Corporation, January 1993, Section "DMA", pp. 1-15 -- 1-17
Patchwork: https://patchwork.linux-mips.org/patch/20835/
--- drivers/tc/tc.c | 8 +++++++- include/linux/tc.h | 1 + 2 files changed, 8 insertions(+), 1 deletion(-)
drivers/tc/tc.c +7 -1
@@ -2,7 +2,7 @@* TURBOchannel bus services. * * Copyright (c) Harald Koerfgen, 1998 -* Copyright (c) 2001, 2003, 2005, 2006 Maciej W. Rozycki +* Copyright (c) 2001, 2003, 2005, 2006, 2018 Maciej W. Rozycki * Copyright (c) 2005 James Simmons * * This file is subject to the terms and conditions of the GNU
@@ -10,6 +10,7 @@* directory of this archive for more details. */ #include <linux/compiler.h> +#include <linux/dma-mapping.h> #include <linux/errno.h> #include <linux/init.h> #include <linux/ioport.h>
@@ -92,6 +93,11 @@ static void __init tc_bus_add_devices(st tdev->dev.bus = &tc_bus_type; tdev->slot = slot; +/* TURBOchannel has 34-bit DMA addressing (16GiB space). */ + tdev->dma_mask =DMA_BIT_MASK (34 ); + tdev->dev.dma_mask = &tdev->dma_mask; + tdev->dev.coherent_dma_mask =DMA_BIT_MASK (34 ); +for (i =0 ; i <8 ; i++) { tdev->firmware[i] =readb (module + offset +TC_FIRM_VER +4 * i);
include/linux/tc.h +1 -0
@@ -84,6 +84,7 @@ struct tc_dev {device. */ struct device dev;/* Generic device interface. */ struct resource resource;/* Address space of this device. */ +u64 dma_mask;/* DMA addressable range. */ char vendor[9 ];char name[9 ];char firmware[9 ];
Greg Kroah-Hartman
maintainerPATCH 180/222 media: v4l2-tpg: fix kernel oops when enabling HFLIP and OSD
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans Verkuil <[email protected]>
commit 250854eed5d45a73d81e4137dfd85180af6f2ec3 upstream.
When the OSD is on (i.e. vivid displays text on top of the test pattern), and you enable hflip, then the driver crashes.
The cause turned out to be a division of a negative number by an unsigned value. You expect that -8 / 2U would be -4, but in reality it is 2147483644 :-(
--- drivers/media/common/v4l2-tpg/v4l2-tpg-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/media/common/v4l2-tpg/v4l2-tpg-core.c +1 -1
@@ -1765,7 +1765,7 @@ typedef struct { u16 __; u8 _; } __packe pos[7 ] = (chr & (0x01 <<0 ) ? fg : bg); \ } \ \ - pos += (tpg->hflip ?-8 :8 ) / hdiv; \ + pos += (tpg->hflip ?-8 :8 ) / (int )hdiv; \ } \ } \ }while (0 )
Greg Kroah-Hartman
maintainerPATCH 181/222 kgdboc: Passing ekgdboc to command line causes panic
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: He Zhe <[email protected]>
commit 1bd54d851f50dea6af30c3e6ff4f3e9aab5558f9 upstream.
kgdboc_option_setup does not check input argument before passing it to strlen. The argument would be a NULL pointer if "ekgdboc", without its value, is set in command line and thus cause the following panic.
PANIC: early exception 0xe3 IP 10:ffffffff8fbbb620 error 0 cr2 0x0
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.18-rc8+ #1 [ 0.000000] RIP: 0010:strlen+0x0/0x20 ... [ 0.000000] Call Trace [ 0.000000] ? kgdboc_option_setup+0x9/0xa0 [ 0.000000] ? kgdboc_early_init+0x6/0x1b [ 0.000000] ? do_early_param+0x4d/0x82 [ 0.000000] ? parse_args+0x212/0x330 [ 0.000000] ? rdinit_setup+0x26/0x26 [ 0.000000] ? parse_early_options+0x20/0x23 [ 0.000000] ? rdinit_setup+0x26/0x26 [ 0.000000] ? parse_early_param+0x2d/0x39 [ 0.000000] ? setup_arch+0x2f7/0xbf4 [ 0.000000] ? start_kernel+0x5e/0x4c2 [ 0.000000] ? load_ucode_bsp+0x113/0x12f [ 0.000000] ? secondary_startup_64+0xa5/0xb0
This patch adds a check to prevent the panic.
--- drivers/tty/serial/kgdboc.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/tty/serial/kgdboc.c +5 -0
@@ -133,6 +133,11 @@ static void kgdboc_unregister_kbd(void)static int kgdboc_option_setup (char *opt) { +if (!opt) { +pr_err ("kgdboc: config string not provided\n" ); +return -EINVAL ; + } +if (strlen (opt) >=MAX_CONFIG_LEN ) {printk (KERN_ERR "kgdboc: config string too long\n" );return -ENOSPC ;
Greg Kroah-Hartman
maintainerPATCH 182/222 xen: fix xen_qlock_wait()
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Juergen Gross <[email protected]>
commit d3132b3860f6cf35ff7609a76bbcdbb814bd027c upstream.
Commit a856531951dc80 ("xen: make xen_qlock_wait() nestable") introduced a regression for Xen guests running fully virtualized (HVM or PVH mode). The Xen hypervisor wouldn't return from the poll hypercall with interrupts disabled in case of an interrupt (for PV guests it does).
So instead of disabling interrupts in xen_qlock_wait() use a nesting counter to avoid calling xen_clear_irq_pending() in case xen_qlock_wait() is nested.
--- arch/x86/xen/spinlock.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-)
arch/x86/xen/spinlock.c +8 -6
@@ -9,6 +9,7 @@#include <linux/log2.h> #include <linux/gfp.h> #include <linux/slab.h> +#include <linux/atomic.h> #include <asm/paravirt.h>
@@ -20,6 +21,7 @@ static DEFINE_PER_CPU(int, lock_kicker_irq) = -1; static DEFINE_PER_CPU(char *, irq_name); +static DEFINE_PER_CPU(atomic_t, xen_qlock_wait_nest);static bool xen_pvspin = true;#include <asm/qspinlock.h>
@@ -40,25 +42,25 @@ static void xen_qlock_kick(int cpu)*/ static void xen_qlock_wait (u8 *byte,u8 val) { -unsigned long flags;int irq =__this_cpu_read (lock_kicker_irq); +atomic_t *nest_cnt =this_cpu_ptr (&xen_qlock_wait_nest);/* If kicker interrupts not initialized yet, just spin */ if (irq ==-1 ||in_nmi ())return ; -/* Guard against reentry. */ -local_irq_save (flags); +/* Detect reentry. */ +atomic_inc (nest_cnt); -/* If irq pending already clear it. */ -if (xen_test_irq_pending (irq)) { +/* If irq pending already and no nested call clear it. */ +if (atomic_read (nest_cnt) ==1 &&xen_test_irq_pending (irq)) {xen_clear_irq_pending (irq); }else if (READ_ONCE (*byte) == val) {/* Block until irq becomes pending (or a spurious wakeup) */ xen_poll_irq (irq); } -local_irq_restore (flags); +atomic_dec (nest_cnt); }static irqreturn_t dummy_handler (int irq,void *dev_id)
Greg Kroah-Hartman
maintainerPATCH 183/222 xen-blkfront: fix kernel panic with negotiate_mq error path
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Manjunath Patil <[email protected]>
commit 6cc4a0863c9709c512280c64e698d68443ac8053 upstream.
info->nr_rings isn't adjusted in case of ENOMEM error from negotiate_mq(). This leads to kernel panic in error path.
Typical call stack involving panic -
#8 page_fault at ffffffff8175936f
[exception RIP: blkif_free_ring+33]
RIP: ffffffffa0149491 RSP: ffff8804f7673c08 RFLAGS: 00010292
...
#9 blkif_free at ffffffffa0149aaa [xen_blkfront]
#10 talk_to_blkback at ffffffffa014c8cd [xen_blkfront] #11 blkback_changed at ffffffffa014ea8b [xen_blkfront] #12 xenbus_otherend_changed at ffffffff81424670
#13 backend_changed at ffffffff81426dc3
#14 xenwatch_thread at ffffffff81422f29
#15 kthread at ffffffff810abe6a
#16 ret_from_fork at ffffffff81754078
--- drivers/block/xen-blkfront.c | 1 + 1 file changed, 1 insertion(+)
drivers/block/xen-blkfront.c +1 -0
@@ -1910,6 +1910,7 @@ static int negotiate_mq(struct blkfront_ info->rinfo =kzalloc (sizeof (struct blkfront_ring_info ) * info->nr_rings,GFP_KERNEL );if (!info->rinfo) {xenbus_dev_fatal (info->xbdev, -ENOMEM ,"allocating ring_info structure" ); + info->nr_rings =0 ;return -ENOMEM ; }
Greg Kroah-Hartman
maintainerPATCH 184/222 media: em28xx: use a default format if TRY_FMT fails
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mauro Carvalho Chehab <[email protected]>
commit f823ce2a1202d47110a7ef86b65839f0be8adc38 upstream.
Follow the V4L2 spec, as warned by v4l2-compliance:
warn: v4l2-test-formats.cpp(732): TRY_FMT cannot handle an invalid pixelformat.
warn: v4l2-test-formats.cpp(733): This may or may not be a problem. For more information see:
warn: v4l2-test-formats.cpp(734): http://www.mail-archive.com/[email protected]/msg56550.html
--- drivers/media/usb/em28xx/em28xx-video.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/media/usb/em28xx/em28xx-video.c +3 -3
@@ -1445,9 +1445,9 @@ static int vidioc_try_fmt_vid_cap(struct fmt =format_by_fourcc (f->fmt.pix.pixelformat);if (!fmt) { -em28xx_videodbg ("Fourcc format (%08x) invalid.\n" , - f->fmt.pix.pixelformat); -return -EINVAL ; + fmt = &format[0 ]; +em28xx_videodbg ("Fourcc format (%08x) invalid. Using default (%08x).\n" , + f->fmt.pix.pixelformat, fmt->fourcc); }if (dev->board.is_em2800) {
Greg Kroah-Hartman
maintainerPATCH 185/222 media: tvp5150: avoid going past array on v4l2_querymenu()
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mauro Carvalho Chehab <[email protected]>
commit 5c4c4505b716cb782ad7263091edc466c4d1fbd4 upstream.
The parameters of v4l2_ctrl_new_std_menu_items() are tricky: instead of the number of possible values, it requires the number of the maximum value. In other words, the ARRAY_SIZE() value should be decremented, otherwise it will go past the array bounds, as warned by KASAN:
[ 279.839688] BUG: KASAN: global-out-of-bounds in v4l2_querymenu+0x10d/0x180 [videodev] [ 279.839709] Read of size 8 at addr ffffffffc10a4cb0 by task v4l2-compliance/16676
[ 279.839736] CPU: 1 PID: 16676 Comm: v4l2-compliance Not tainted 4.18.0-rc2+ #120 [ 279.839741] Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0364.2017.0511.0949 05/11/2017 [ 279.839743] Call Trace: [ 279.839758] dump_stack+0x71/0xab [ 279.839807] ? v4l2_querymenu+0x10d/0x180 [videodev] [ 279.839817] print_address_description+0x1c9/0x270 [ 279.839863] ? v4l2_querymenu+0x10d/0x180 [videodev] [ 279.839871] kasan_report+0x237/0x360 [ 279.839918] v4l2_querymenu+0x10d/0x180 [videodev] [ 279.839964] __video_do_ioctl+0x2c8/0x590 [videodev] [ 279.840011] ? copy_overflow+0x20/0x20 [videodev] [ 279.840020] ? avc_ss_reset+0xa0/0xa0 [ 279.840028] ? check_stack_object+0x21/0x60 [ 279.840036] ? __check_object_size+0xe7/0x240 [ 279.840080] video_usercopy+0xed/0x730 [videodev] [ 279.840123] ? copy_overflow+0x20/0x20 [videodev] [ 279.840167] ? v4l_enumstd+0x40/0x40 [videodev] [ 279.840177] ? __handle_mm_fault+0x9f9/0x1ba0 [ 279.840186] ? __pmd_alloc+0x2c0/0x2c0 [ 279.840193] ? __vfs_write+0xb6/0x350 [ 279.840200] ? kernel_read+0xa0/0xa0 [ 279.840244] ? video_usercopy+0x730/0x730 [videodev] [ 279.840284] v4l2_ioctl+0xa1/0xb0 [videodev] [ 279.840295] do_vfs_ioctl+0x117/0x8a0 [ 279.840303] ? selinux_file_ioctl+0x211/0x2f0 [ 279.840313] ? ioctl_preallocate+0x120/0x120 [ 279.840319] ? selinux_capable+0x20/0x20 [ 279.840332] ksys_ioctl+0x70/0x80 [ 279.840342] __x64_sys_ioctl+0x3d/0x50 [ 279.840351] do_syscall_64+0x6d/0x1c0 [ 279.840361] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 279.840367] RIP: 0033:0x7fdfb46275d7 [ 279.840369] Code: b3 66 90 48 8b 05 b1 48 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 81 48 2d 00 f7 d8 64 89 01 48 [ 279.840474] RSP: 002b:00007ffee1179038 EFLAGS: 00000202 ORIG_RAX: 0000000000000010 [ 279.840483] RAX: ffffffffffffffda RBX: 00007ffee1179180 RCX: 00007fdfb46275d7 [ 279.840488] RDX: 00007ffee11790c0 RSI: 00000000c02c5625 RDI: 0000000000000003 [ 279.840493] RBP: 0000000000000002 R08: 0000000000000020 R09: 00000000009f0902 [ 279.840497] R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffee117a5a0 [ 279.840501] R13: 00007ffee11790c0 R14: 0000000000000002 R15: 0000000000000000
[ 279.840515] The buggy address belongs to the variable: [ 279.840535] tvp5150_test_patterns+0x10/0xffffffffffffe360 [tvp5150]
--- drivers/media/i2c/tvp5150.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/media/i2c/tvp5150.c +1 -1
@@ -1530,7 +1530,7 @@ static int tvp5150_probe(struct i2c_clie 27000000, 1, 27000000);v4l2_ctrl_new_std_menu_items (&core->hdl, &tvp5150_ctrl_ops,V4L2_CID_TEST_PATTERN , -ARRAY_SIZE (tvp5150_test_patterns), +ARRAY_SIZE (tvp5150_test_patterns) -1 ,0 ,0 , tvp5150_test_patterns); sd->ctrl_handler = &core->hdl;if (core->hdl.error) {
Greg Kroah-Hartman
maintainerPATCH 186/222 media: em28xx: fix input name for Terratec AV 350
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mauro Carvalho Chehab <[email protected]>
commit 15644bfa195bd166d0a5ed76ae2d587f719c3dac upstream.
Instead of using a register value, use an AMUX name, as otherwise VIDIOC_G_AUDIO would fail.
--- drivers/media/usb/em28xx/em28xx-cards.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/media/usb/em28xx/em28xx-cards.c +2 -2
@@ -2112,13 +2112,13 @@ struct em28xx_board em28xx_boards[] = { .input = { { .type = EM28XX_VMUX_COMPOSITE, .vmux = TVP5150_COMPOSITE1, - .amux = EM28XX_AUDIO_SRC_LINE, + .amux = EM28XX_AMUX_LINE_IN, .gpio = terratec_av350_unmute_gpio, }, { .type = EM28XX_VMUX_SVIDEO, .vmux = TVP5150_SVIDEO, - .amux = EM28XX_AUDIO_SRC_LINE, + .amux = EM28XX_AMUX_LINE_IN, .gpio = terratec_av350_unmute_gpio, } }, },
Greg Kroah-Hartman
maintainerPATCH 187/222 media: em28xx: make v4l2-compliance happier by starting sequence on zero
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mauro Carvalho Chehab <[email protected]>
commit afeaade90db4c5dab93f326d9582be1d5954a198 upstream.
The v4l2-compliance tool complains if a video doesn't start with a zero sequence number.
While this shouldn't cause any real problem for apps, let's make it happier, in order to better check the v4l2-compliance differences before and after patchsets.
This is actually an old issue. It is there since at least its videobuf2 conversion, e. g. changeset 3829fadc461 ("[media]
em28xx: convert to videobuf2"), if VB1 wouldn't suffer from the same issue.
--- drivers/media/usb/em28xx/em28xx-video.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/media/usb/em28xx/em28xx-video.c +2 -0
@@ -900,6 +900,8 @@ static int em28xx_enable_analog_tuner(stif (!mdev || !v4l2->decoder)return 0 ; + dev->v4l2->field_count =0 ; +/* * This will find the tuner that is connected into the decoder. * Technically, this is not 100% correct, as the device may be
Greg Kroah-Hartman
maintainerPATCH 188/222 media: media colorspaces*.rst: rename AdobeRGB to opRGB
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans Verkuil <[email protected]>
commit a58c37978cf02f6d35d05ee4e9288cb8455f1401 upstream.
Drop all Adobe references and use the official opRGB standard instead.
--- Documentation/media/uapi/v4l/biblio.rst | 10 ---------- Documentation/media/uapi/v4l/colorspaces-defs.rst | 8 ++++---- Documentation/media/uapi/v4l/colorspaces-details.rst | 13 ++++++------- 3 files changed, 10 insertions(+), 21 deletions(-)
Documentation/media/uapi/v4l/biblio.rst +0 -10
@@ -226,16 +226,6 @@ xvYCC :author: International Electrotechnical Commission (http://www.iec.ch) -.. _adobergb: - -AdobeRGB -======== - - -:title: Adobe© RGB (1998) Color Image Encoding Version 2005-05 - -:author: Adobe Systems Incorporated (http://www.adobe.com) - .. _oprgb: opRGB
Documentation/media/uapi/v4l/colorspaces-defs.rst +4 -4
@@ -51,8 +51,8 @@ whole range, 0-255, dividing the angular - See :ref:`col-rec709`. * - ``V4L2_COLORSPACE_SRGB`` - See :ref:`col-srgb`. - * - ``V4L2_COLORSPACE_ADOBERGB`` - - See :ref:`col-adobergb`. + * - ``V4L2_COLORSPACE_OPRGB`` + - See :ref:`col-oprgb`. * - ``V4L2_COLORSPACE_BT2020`` - See :ref:`col-bt2020`. * - ``V4L2_COLORSPACE_DCI_P3``
@@ -90,8 +90,8 @@ whole range, 0-255, dividing the angular - Use the Rec. 709 transfer function. * - ``V4L2_XFER_FUNC_SRGB`` - Use the sRGB transfer function. - * - ``V4L2_XFER_FUNC_ADOBERGB`` - - Use the AdobeRGB transfer function. + * - ``V4L2_XFER_FUNC_OPRGB`` + - Use the opRGB transfer function. * - ``V4L2_XFER_FUNC_SMPTE240M`` - Use the SMPTE 240M transfer function. * - ``V4L2_XFER_FUNC_NONE``
Documentation/media/uapi/v4l/colorspaces-details.rst +6 -7
@@ -290,15 +290,14 @@ Y' is clamped to the range [0…1] and C 170M/BT.601. The Y'CbCr quantization is limited range. -.. _col-adobergb: +.. _col-oprgb: -Colorspace Adobe RGB (V4L2_COLORSPACE_ADOBERGB) +Colorspace opRGB (V4L2_COLORSPACE_OPRGB) =============================================== -The :ref:`adobergb` standard defines the colorspace used by computer -graphics that use the AdobeRGB colorspace. This is also known as the -:ref:`oprgb` standard. The default transfer function is -``V4L2_XFER_FUNC_ADOBERGB``. The default Y'CbCr encoding is +The :ref:`oprgb` standard defines the colorspace used by computer +graphics that use the opRGB colorspace. The default transfer function is +``V4L2_XFER_FUNC_OPRGB``. The default Y'CbCr encoding is ``V4L2_YCBCR_ENC_601``. The default Y'CbCr quantization is limited range.
@@ -312,7 +311,7 @@ The chromaticities of the primary colors .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}| -.. flat-table:: Adobe RGB Chromaticities +.. flat-table:: opRGB Chromaticities :header-rows: 1 :stub-columns: 0 :widths: 1 1 2
Greg Kroah-Hartman
maintainerPATCH 189/222 arm64: lse: remove -fcall-used-x0 flag
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tri Vo <[email protected]>
commit 2a6c7c367de82951c98a290a21156770f6f82c84 upstream.
x0 is not callee-saved in the PCS. So there is no need to specify -fcall-used-x0.
Clang doesn't currently support -fcall-used flags. This patch will help building the kernel with clang.
--- arch/arm64/lib/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/lib/Makefile +1 -1
@@ -12,7 +12,7 @@ lib-y := bitops.o clear_user.o delay.o # when supported by the CPU. Result and argument registers are handled # correctly, based on the function prototype. lib-$(CONFIG_ARM64_LSE_ATOMICS) += atomic_ll_sc.o -CFLAGS_atomic_ll_sc.o := -fcall-used-x0 -ffixed-x1 -ffixed-x2 \ +CFLAGS_atomic_ll_sc.o := -ffixed-x1 -ffixed-x2 \ -ffixed-x3 -ffixed-x4 -ffixed-x5 -ffixed-x6 \ -ffixed-x7 -fcall-saved-x8 -fcall-saved-x9 \ -fcall-saved-x10 -fcall-saved-x11 -fcall-saved-x12 \
Greg Kroah-Hartman
maintainerPATCH 190/222 rpmsg: smd: fix memory leak on channel create
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Colin Ian King <[email protected]>
commit 940c620d6af8fca7d115de40f19870fba415efac upstream.
Currently a failed allocation of channel->name leads to an immediate return without freeing channel. Fix this by setting ret to -ENOMEM and jumping to an exit path that kfree's channel.
Detected by CoverityScan, CID#1473692 ("Resource Leak")
--- drivers/rpmsg/qcom_smd.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/rpmsg/qcom_smd.c +5 -2
@@ -1049,8 +1049,10 @@ static struct qcom_smd_channel *qcom_smd channel->edge = edge; channel->name =kstrdup (name,GFP_KERNEL ); -if (!channel->name) -return ERR_PTR (-ENOMEM ); +if (!channel->name) { + ret = -ENOMEM ; + goto free_channel; + }mutex_init (&channel->tx_lock);spin_lock_init (&channel->recv_lock);
@@ -1099,6 +1101,7 @@ static struct qcom_smd_channel *qcom_smd free_name_and_channel:kfree (channel->name); +free_channel:kfree (channel);return ERR_PTR (ret);
Greg Kroah-Hartman
maintainerPATCH 191/222 Cramfs: fix abad comparison when wrap-arounds occur
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicolas Pitre <[email protected]>
commit 672ca9dd13f1aca0c17516f76fc5b0e8344b3e46 upstream.
It is possible for corrupted filesystem images to produce very large block offsets that may wrap when a length is added, and wrongly pass the buffer size test.
--- fs/cramfs/inode.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
fs/cramfs/inode.c +2 -1
@@ -186,7 +186,8 @@ static void *cramfs_read(struct super_blcontinue ; blk_offset = (blocknr - buffer_blocknr[i]) <<PAGE_SHIFT ; blk_offset += offset; -if (blk_offset + len >BUFFER_SIZE ) +if (blk_offset >BUFFER_SIZE || + blk_offset + len >BUFFER_SIZE )continue ;return read_buffers[i] + blk_offset; }
Greg Kroah-Hartman
maintainerPATCH 192/222 ARM: dts: socfpga: Fix SDRAM node address for Arria10
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thor Thayer <[email protected]>
commit ce3bf934f919a7d675c5b7fa4cc233ded9c6256e upstream.
The address in the SDRAM node was incorrect. Fix this to agree with the correct address and to match the reg definition block.
--- arch/arm/boot/dts/socfpga_arria10.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/socfpga_arria10.dtsi +1 -1
@@ -601,7 +601,7 @@ status = "disabled"; }; - sdr: sdr@ffc25000 { + sdr: sdr@ffcfb100 { compatible = "altr,sdr-ctl", "syscon"; reg = <0xffcfb100 0x80>; };
Greg Kroah-Hartman
maintainerPATCH 193/222 arm64: dts: stratix10: Correct System Manager register size
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thor Thayer <[email protected]>
commit 74121b9aa3cd571ddfff014a9f47db36cae3cda9 upstream.
Correct the register size of the System Manager node.
--- arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi +1 -1
@@ -249,7 +249,7 @@ sysmgr: sysmgr@ffd12000 { compatible = "altr,sys-mgr", "syscon"; - reg = <0xffd12000 0x1000>; + reg = <0xffd12000 0x228>; }; /* Local timer */
Greg Kroah-Hartman
maintainerPATCH 194/222 soc/tegra: pmc: Fix child-node lookup
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit 1dc6bd5e39a29453bdcc17348dd2a89f1aa4004e upstream.
Fix child-node lookup during probe, which ended up searching the whole device tree depth-first starting at the parent rather than just matching on its children.
To make things worse, the parent pmc node could end up being prematurely freed as of_find_node_by_name() drops a reference to its first argument.
--- drivers/soc/tegra/pmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/soc/tegra/pmc.c +1 -1
@@ -1321,7 +1321,7 @@ static void tegra_pmc_init_tsense_reset(if (!pmc->soc->has_tsense_reset)return ; - np =of_find_node_by_name (pmc->dev->of_node,"i2c-thermtrip" ); + np =of_get_child_by_name (pmc->dev->of_node,"i2c-thermtrip" );if (!np) {dev_warn (dev,"i2c-thermtrip node not found, %s.\n" , disabled);return ;
Greg Kroah-Hartman
maintainerPATCH 195/222 selftests/powerpc: Fix ptrace tm failure
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Breno Leitao <[email protected]>
commit 48dc0ef19044bfb69193302fbe3a834e3331b7ae upstream.
Test ptrace-tm-spd-gpr fails on current kernel (4.19) due to a segmentation fault that happens on the child process prior to setting cptr[2] = 1. This causes the parent process to wait forever at 'while (!pptr[2])' and the test to be killed by the test harness framework by timeout, thus, failing.
The segmentation fault happens because of a inline assembly being generated as:
0x10000355c <tm_spd_gpr+492> lfs f0, 0(0)
This is reading memory position 0x0 and causing the segmentation fault.
This code is being generated by ASM_LOAD_FPR_SINGLE_PRECISION(flt_4), where flt_4 is passed to the inline assembly block as:
[flt_4] "r" (&d)
Since the inline assembly 'r' constraint means any GPR, gpr0 is being chosen, thus causing this issue when issuing a Load Floating-Point Single instruction.
This patch simply changes the constraint to 'b', which specify that this register will be used as base, and r0 is not allowed to be used, avoiding this issue.
Other than that, removing flt_2 register from the input operands, since it is not used by the inline assembly code at all.
--- tools/testing/selftests/powerpc/ptrace/ptrace-tm-spd-gpr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
tools/testing/selftests/powerpc/ptrace/ptrace-tm-spd-gpr.c +2 -2
@@ -67,8 +67,8 @@ trans:"3: ;" : [res] "=r" (result), [texasr] "=r" (texasr) : [gpr_1]"i"(GPR_1), [gpr_2]"i"(GPR_2), [gpr_4]"i"(GPR_4), - [sprn_texasr] "i" (SPRN_TEXASR), [flt_1] "r" (&a), - [flt_2] "r" (&b), [flt_4] "r" (&d) + [sprn_texasr] "i" (SPRN_TEXASR), [flt_1] "b" (&a), + [flt_4] "b" (&d) : "memory", "r5", "r6", "r7","r8" ,"r9" ,"r10" ,"r11" ,"r12" ,"r13" ,"r14" ,"r15" , "r16", "r17", "r18", "r19", "r20", "r21", "r22", "r23",
Greg Kroah-Hartman
maintainerPATCH 196/222 btrfs: qgroup: Avoid calling qgroup functions if qgroup is not enabled
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qu Wenruo <[email protected]>
commit 3628b4ca64f24a4ec55055597d0cb1c814729f8b upstream.
Some qgroup trace events like btrfs_qgroup_release_data() and btrfs_qgroup_free_delayed_ref() can still be triggered even if qgroup is not enabled.
This is caused by the lack of qgroup status check before calling some qgroup functions. Thankfully the functions can handle quota disabled case well and just do nothing for qgroup disabled case.
This patch will do earlier check before triggering related trace events.
And for enabled <-> disabled race case:
1) For enabled->disabled case
Disable will wipe out all qgroups data including reservation and excl/rfer. Even if we leak some reservation or numbers, it will still be cleared, so nothing will go wrong.
2) For disabled -> enabled case
Current btrfs_qgroup_release_data() will use extent_io tree to ensure we won't underflow reservation. And for delayed_ref we use head->qgroup_reserved to record the reserved space, so in that case head->qgroup_reserved should be 0 and we won't underflow.
--- fs/btrfs/qgroup.c | 4 ++++ fs/btrfs/qgroup.h | 2 ++ 2 files changed, 6 insertions(+)
fs/btrfs/qgroup.c +4 -0
@@ -2972,6 +2972,10 @@ static int __btrfs_qgroup_release_data(sint trace_op =QGROUP_RELEASE ;int ret; +if (!test_bit (BTRFS_FS_QUOTA_ENABLED , + &BTRFS_I (inode)->root->fs_info->flags)) +return 0 ; +/* In release case, we shouldn't have @reserved */ WARN_ON (!free && reserved);if (free && reserved)
fs/btrfs/qgroup.h +2 -0
@@ -232,6 +232,8 @@ void btrfs_qgroup_free_refroot(struct btstatic inline void btrfs_qgroup_free_delayed_ref (struct btrfs_fs_info *fs_info,u64 ref_root,u64 num_bytes) { +if (!test_bit (BTRFS_FS_QUOTA_ENABLED , &fs_info->flags)) +return ;trace_btrfs_qgroup_free_delayed_ref (fs_info, ref_root, num_bytes);btrfs_qgroup_free_refroot (fs_info, ref_root, num_bytes); }
Greg Kroah-Hartman
maintainerPATCH 197/222 btrfs: Handle owner mismatch gracefully when walking up tree
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qu Wenruo <[email protected]>
commit 65c6e82becec33731f48786e5a30f98662c86b16 upstream.
[BUG]
When mounting certain crafted image, btrfs will trigger kernel BUG_ON() when trying to recover balance:
kernel BUG at fs/btrfs/extent-tree.c:8956!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 1 PID: 662 Comm: mount Not tainted 4.18.0-rc1-custom+ #10 RIP: 0010:walk_up_proc+0x336/0x480 [btrfs] RSP: 0018:ffffb53540c9b890 EFLAGS: 00010202 Call Trace: walk_up_tree+0x172/0x1f0 [btrfs] btrfs_drop_snapshot+0x3a4/0x830 [btrfs] merge_reloc_roots+0xe1/0x1d0 [btrfs] btrfs_recover_relocation+0x3ea/0x420 [btrfs] open_ctree+0x1af3/0x1dd0 [btrfs] btrfs_mount_root+0x66b/0x740 [btrfs] mount_fs+0x3b/0x16a vfs_kern_mount.part.9+0x54/0x140 btrfs_mount+0x16d/0x890 [btrfs] mount_fs+0x3b/0x16a vfs_kern_mount.part.9+0x54/0x140 do_mount+0x1fd/0xda0 ksys_mount+0xba/0xd0 __x64_sys_mount+0x21/0x30 do_syscall_64+0x60/0x210 entry_SYSCALL_64_after_hwframe+0x49/0xbe
[CAUSE]
Extent tree corruption. In this particular case, reloc tree root's owner is DATA_RELOC_TREE (should be TREE_RELOC), thus its backref is corrupted and we failed the owner check in walk_up_tree().
[FIX]
It's pretty hard to take care of every extent tree corruption, but at least we can remove such BUG_ON() and exit more gracefully.
And since in this particular image, DATA_RELOC_TREE and TREE_RELOC share the same root (which is obviously invalid), we needs to make __del_reloc_root() more robust to detect such invalid sharing to avoid possible NULL dereference as root->node can be NULL in this case.
--- fs/btrfs/extent-tree.c | 18 ++++++++++++------ fs/btrfs/relocation.c | 2 +- 2 files changed, 13 insertions(+), 7 deletions(-)
fs/btrfs/extent-tree.c +12 -6
@@ -9028,15 +9028,14 @@ static noinline int walk_up_proc(structif (eb == root->node) {if (wc->flags[level] &BTRFS_BLOCK_FLAG_FULL_BACKREF ) parent = eb->start; -else -BUG_ON (root->root_key.objectid != -btrfs_header_owner (eb)); +else if (root->root_key.objectid !=btrfs_header_owner (eb)) + goto owner_mismatch; }else {if (wc->flags[level +1 ] &BTRFS_BLOCK_FLAG_FULL_BACKREF ) parent = path->nodes[level +1 ]->start; -else -BUG_ON (root->root_key.objectid != -btrfs_header_owner (path->nodes[level +1 ])); +else if (root->root_key.objectid != +btrfs_header_owner (path->nodes[level +1 ])) + goto owner_mismatch; }btrfs_free_tree_block (trans, root, eb, parent, wc->refs[level] ==1 );
@@ -9044,6 +9043,11 @@ out: wc->refs[level] =0 ; wc->flags[level] =0 ;return 0 ; + +owner_mismatch: +btrfs_err_rl (fs_info,"unexpected tree owner, have %llu expect %llu" , +btrfs_header_owner (eb), root->root_key.objectid); +return -EUCLEAN ; } static noinline int walk_down_tree(struct btrfs_trans_handle *trans,
@@ -9097,6 +9101,8 @@ static noinline int walk_up_tree(struct ret =walk_up_proc (trans, root, path, wc);if (ret >0 )return 0 ; +if (ret <0 ) +return ret;if (path->locks[level]) { btrfs_tree_unlock_rw(path->nodes[level],
fs/btrfs/relocation.c +1 -1
@@ -1334,7 +1334,7 @@ static void __del_reloc_root(struct btrfstruct mapping_node *node =NULL ;struct reloc_control *rc = fs_info->reloc_ctl; -if (rc) { +if (rc && root->node) {spin_lock (&rc->reloc_root_tree.lock); rb_node =tree_search (&rc->reloc_root_tree.rb_root, root->node->start);
Greg Kroah-Hartman
maintainerPATCH 198/222 btrfs: locking: Add extra check in btrfs_init_new_buffer() to avoid deadlock
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qu Wenruo <[email protected]>
commit b72c3aba09a53fc7c1824250d71180ca154517a7 upstream.
[BUG]
For certain crafted image, whose csum root leaf has missing backref, if we try to trigger write with data csum, it could cause deadlock with the following kernel WARN_ON():
WARNING: CPU: 1 PID: 41 at fs/btrfs/locking.c:230 btrfs_tree_lock+0x3e2/0x400 CPU: 1 PID: 41 Comm: kworker/u4:1 Not tainted 4.18.0-rc1+ #8 Workqueue: btrfs-endio-write btrfs_endio_write_helper RIP: 0010:btrfs_tree_lock+0x3e2/0x400 Call Trace: btrfs_alloc_tree_block+0x39f/0x770 __btrfs_cow_block+0x285/0x9e0 btrfs_cow_block+0x191/0x2e0 btrfs_search_slot+0x492/0x1160 btrfs_lookup_csum+0xec/0x280 btrfs_csum_file_blocks+0x2be/0xa60 add_pending_csums+0xaf/0xf0 btrfs_finish_ordered_io+0x74b/0xc90 finish_ordered_fn+0x15/0x20 normal_work_helper+0xf6/0x500 btrfs_endio_write_helper+0x12/0x20 process_one_work+0x302/0x770 worker_thread+0x81/0x6d0 kthread+0x180/0x1d0 ret_from_fork+0x35/0x40
[CAUSE]
That crafted image has missing backref for csum tree root leaf. And when we try to allocate new tree block, since there is no EXTENT/METADATA_ITEM for csum tree root, btrfs consider it's free slot and use it.
The extent tree of the image looks like:
Normal image | This fuzzed image
----------------------------------+--------------------------------
BG 29360128 | BG 29360128 One empty slot | One empty slot 29364224: backref to UUID tree | 29364224: backref to UUID tree Two empty slots | Two empty slots 29376512: backref to CSUM tree | One empty slot (bad type) <<< 29380608: backref to D_RELOC tree | 29380608: backref to D_RELOC tree ... | ...
Since bytenr 29376512 has no METADATA/EXTENT_ITEM, when btrfs try to alloc tree block, it's an valid slot for btrfs.
And for finish_ordered_write, when we need to insert csum, we try to CoW csum tree root.
By accident, empty slots at bytenr BG_OFFSET, BG_OFFSET + 8K, BG_OFFSET + 12K is already used by tree block COW for other trees, the next empty slot is BG_OFFSET + 16K, which should be the backref for CSUM tree.
But due to the bad type, btrfs can recognize it and still consider it as an empty slot, and will try to use it for csum tree CoW.
Then in the following call trace, we will try to lock the new tree block, which turns out to be the old csum tree root which is already locked:
btrfs_search_slot() called on csum tree root, which is at 29376512 |- btrfs_cow_block()
|- btrfs_set_lock_block()
| |- Now locks tree block 29376512 (old csum tree root)
|- __btrfs_cow_block()
|- btrfs_alloc_tree_block()
|- btrfs_reserve_extent()
| Now it returns tree block 29376512, which extent tree
| shows its empty slot, but it's already hold by csum tree
|- btrfs_init_new_buffer()
|- btrfs_tree_lock()
| Triggers WARN_ON(eb->lock_owner == current->pid)
|- wait_event()
Wait lock owner to release the lock, but it's
locked by ourself, so it will deadlock[FIX]
This patch will do the lock_owner and current->pid check at btrfs_init_new_buffer().
So above deadlock can be avoided.
Since such problem can only happen in crafted image, we will still trigger kernel warning for later aborted transaction, but with a little more meaningful warning message.
--- fs/btrfs/extent-tree.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
fs/btrfs/extent-tree.c +13 -0
@@ -8398,6 +8398,19 @@ btrfs_init_new_buffer(struct btrfs_transif (IS_ERR (buf))return buf; +/* +* Extra safety check in case the extent tree is corrupted and extent +* allocator chooses to use a tree block which is already used and +* locked. +*/ +if (buf->lock_owner == current->pid) { +btrfs_err_rl (fs_info, +"tree block %llu owner %llu already locked by pid=%d, extent tree corruption detected" , + buf->start,btrfs_header_owner (buf), current->pid); +free_extent_buffer (buf); +return ERR_PTR (-EUCLEAN ); + } +btrfs_set_header_generation (buf, trans->transid);btrfs_set_buffer_lockdep_class (root->root_key.objectid, buf, level);btrfs_tree_lock (buf);
Greg Kroah-Hartman
maintainerPATCH 199/222 btrfs: fix error handling in free_log_tree
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jeff Mahoney <[email protected]>
commit 374b0e2d6ba5da7fd1cadb3247731ff27d011f6f upstream.
When we hit an I/O error in free_log_tree->walk_log_tree during file system shutdown we can crash due to there not being a valid transaction handle.
Use btrfs_handle_fs_error when there's no transaction handle to use.
BUG: unable to handle kernel NULL pointer dereference at 0000000000000060 IP: free_log_tree+0xd2/0x140 [btrfs] PGD 0 P4D 0 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC PTI Modules linked in: <modules> CPU: 2 PID: 23544 Comm: umount Tainted: G W 4.12.14-kvmsmall #9 SLE15 (unreleased) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 task: ffff96bfd3478880 task.stack: ffffa7cf40d78000 RIP: 0010:free_log_tree+0xd2/0x140 [btrfs] RSP: 0018:ffffa7cf40d7bd10 EFLAGS: 00010282 RAX: 00000000fffffffb RBX: 00000000fffffffb RCX: 0000000000000002 RDX: 0000000000000000 RSI: ffff96c02f07d4c8 RDI: 0000000000000282 RBP: ffff96c013cf1000 R08: ffff96c02f07d4c8 R09: ffff96c02f07d4d0 R10: 0000000000000000 R11: 0000000000000002 R12: 0000000000000000 R13: ffff96c005e800c0 R14: ffffa7cf40d7bdb8 R15: 0000000000000000 FS: 00007f17856bcfc0(0000) GS:ffff96c03f600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000060 CR3: 0000000045ed6002 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? wait_for_writer+0xb0/0xb0 [btrfs] btrfs_free_log+0x17/0x30 [btrfs] btrfs_drop_and_free_fs_root+0x9a/0xe0 [btrfs] btrfs_free_fs_roots+0xc0/0x130 [btrfs] ? wait_for_completion+0xf2/0x100 close_ctree+0xea/0x2e0 [btrfs] ? kthread_stop+0x161/0x260 generic_shutdown_super+0x6c/0x120 kill_anon_super+0xe/0x20 btrfs_kill_super+0x13/0x100 [btrfs] deactivate_locked_super+0x3f/0x70 cleanup_mnt+0x3b/0x70 task_work_run+0x78/0x90 exit_to_usermode_loop+0x77/0xa6 do_syscall_64+0x1c5/0x1e0 entry_SYSCALL_64_after_hwframe+0x42/0xb7 RIP: 0033:0x7f1784f90827 RSP: 002b:00007ffdeeb03118 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 RAX: 0000000000000000 RBX: 0000556a60c62970 RCX: 00007f1784f90827 RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000556a60c62b50 RBP: 0000000000000000 R08: 0000000000000005 R09: 00000000ffffffff R10: 0000556a60c63900 R11: 0000000000000246 R12: 0000556a60c62b50 R13: 00007f17854a81c4 R14: 0000000000000000 R15: 0000000000000000 RIP: free_log_tree+0xd2/0x140 [btrfs] RSP: ffffa7cf40d7bd10 CR2: 0000000000000060
--- fs/btrfs/tree-log.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
fs/btrfs/tree-log.c +6 -3
@@ -3078,9 +3078,12 @@ static void free_log_tree(struct btrfs_t }; ret =walk_log_tree (trans, log, &wc); -/* I don't think this can happen but just in case */ -if (ret) -btrfs_abort_transaction (trans, ret); +if (ret) { +if (trans) +btrfs_abort_transaction (trans, ret); +else +btrfs_handle_fs_error (log->fs_info, ret,NULL ); + }while (1 ) { ret = find_first_extent_bit(&log->dirty_log_pages,
Greg Kroah-Hartman
maintainerPATCH 200/222 btrfs: Enhance btrfs_trim_fs function to handle error better
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qu Wenruo <[email protected]>
commit 93bba24d4b5ad1e5cd8b43f64e66ff9d6355dd20 upstream.
Function btrfs_trim_fs() doesn't handle errors in a consistent way. If error happens when trimming existing block groups, it will skip the remaining blocks and continue to trim unallocated space for each device.
The return value will only reflect the final error from device trimming.
This patch will fix such behavior by:
1) Recording the last error from block group or device trimming The return value will also reflect the last error during trimming. Make developer more aware of the problem.
2) Continuing trimming if possible
If we failed to trim one block group or device, we could still try the next block group or device.
3) Report number of failures during block group and device trimming It would be less noisy, but still gives user a brief summary of what's going wrong.
Such behavior can avoid confusion for cases like failure to trim the first block group and then only unallocated space is trimmed.
--- fs/btrfs/extent-tree.c | 49 ++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 38 insertions(+), 11 deletions(-)
fs/btrfs/extent-tree.c +38 -11
@@ -11037,6 +11037,15 @@ static int btrfs_trim_free_extents(strucreturn ret; } +/* +* Trim the whole filesystem by: +* 1) trimming the free space in each block group +* 2) trimming the unallocated space on each device +* +* This will also continue trimming even if a block group or device encounters +* an error. The return value will be the last error, or 0 if nothing bad +* happens. +*/ int btrfs_trim_fs (struct btrfs_fs_info *fs_info,struct fstrim_range *range) {struct btrfs_block_group_cache *cache =NULL ;
@@ -11047,6 +11056,10 @@ int btrfs_trim_fs(struct btrfs_fs_info *u64 end;u64 trimmed =0 ;u64 total_bytes =btrfs_super_total_bytes (fs_info->super_copy); +u64 bg_failed =0 ; +u64 dev_failed =0 ; +int bg_ret =0 ; +int dev_ret =0 ;int ret =0 ;/*
@@ -11057,7 +11070,7 @@ int btrfs_trim_fs(struct btrfs_fs_info *else cache =btrfs_lookup_block_group (fs_info, range->start); -while (cache) { +for (; cache; cache =next_block_group (fs_info, cache)) {if (cache->key.objectid >= (range->start + range->len)) {btrfs_put_block_group (cache);break ;
@@ -11071,13 +11084,15 @@ int btrfs_trim_fs(struct btrfs_fs_info *if (!block_group_cache_done (cache)) { ret =cache_block_group (cache,0 );if (ret) { -btrfs_put_block_group (cache); -break ; + bg_failed++; + bg_ret = ret; +continue ; } ret =wait_block_group_cache_done (cache);if (ret) { -btrfs_put_block_group (cache); -break ; + bg_failed++; + bg_ret = ret; +continue ; } } ret = btrfs_trim_block_group(cache,
@@ -11088,28 +11103,40 @@ int btrfs_trim_fs(struct btrfs_fs_info * trimmed += group_trimmed;if (ret) { -btrfs_put_block_group (cache); -break ; + bg_failed++; + bg_ret = ret; +continue ; } } - - cache =next_block_group (fs_info, cache); } +if (bg_failed) +btrfs_warn (fs_info, +"failed to trim %llu block group(s), last error %d" , + bg_failed, bg_ret);mutex_lock (&fs_info->fs_devices->device_list_mutex); devices = &fs_info->fs_devices->alloc_list;list_for_each_entry (device, devices, dev_alloc_list) { ret =btrfs_trim_free_extents (device, range->minlen, &group_trimmed); -if (ret) +if (ret) { + dev_failed++; + dev_ret = ret;break ; + } trimmed += group_trimmed; }mutex_unlock (&fs_info->fs_devices->device_list_mutex); +if (dev_failed) +btrfs_warn (fs_info, +"failed to trim %llu device(s), last error %d" , + dev_failed, dev_ret); range->len = trimmed; -return ret; +if (bg_ret) +return bg_ret; +return dev_ret; }/*
Greg Kroah-Hartman
maintainerPATCH 201/222 btrfs: Ensure btrfs_trim_fs can trim the whole filesystem
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qu Wenruo <[email protected]>
commit 6ba9fc8e628becf0e3ec94083450d089b0dec5f5 upstream.
[BUG]
fstrim on some btrfs only trims the unallocated space, not trimming any space in existing block groups.
[CAUSE]
Before fstrim_range passed to btrfs_trim_fs(), it gets truncated to range [0, super->total_bytes). So later btrfs_trim_fs() will only be able to trim block groups in range [0, super->total_bytes).
While for btrfs, any bytenr aligned to sectorsize is valid, since btrfs uses its logical address space, there is nothing limiting the location where we put block groups.
For filesystem with frequent balance, it's quite easy to relocate all block groups and bytenr of block groups will start beyond super->total_bytes.
In that case, btrfs will not trim existing block groups.
[FIX]
Just remove the truncation in btrfs_ioctl_fitrim(), so btrfs_trim_fs() can get the unmodified range, which is normally set to [0, U64_MAX].
--- fs/btrfs/extent-tree.c | 10 +--------- fs/btrfs/ioctl.c | 11 +++++++---- 2 files changed, 8 insertions(+), 13 deletions(-)
fs/btrfs/extent-tree.c +1 -9
@@ -11055,21 +11055,13 @@ int btrfs_trim_fs(struct btrfs_fs_info *u64 start;u64 end;u64 trimmed =0 ; -u64 total_bytes =btrfs_super_total_bytes (fs_info->super_copy);u64 bg_failed =0 ;u64 dev_failed =0 ;int bg_ret =0 ;int dev_ret =0 ;int ret =0 ; -/* -* try to trim all FS space, our block group may start from non-zero. -*/ -if (range->len == total_bytes) - cache =btrfs_lookup_first_block_group (fs_info, range->start); -else - cache =btrfs_lookup_block_group (fs_info, range->start); - + cache =btrfs_lookup_first_block_group (fs_info, range->start);for (; cache; cache =next_block_group (fs_info, cache)) {if (cache->key.objectid >= (range->start + range->len)) {btrfs_put_block_group (cache);
fs/btrfs/ioctl.c +7 -4
@@ -352,7 +352,6 @@ static noinline int btrfs_ioctl_fitrim(sstruct fstrim_range range;u64 minlen =ULLONG_MAX ;u64 num_devices =0 ; -u64 total_bytes =btrfs_super_total_bytes (fs_info->super_copy);int ret;if (!capable (CAP_SYS_ADMIN ))
@@ -376,11 +375,15 @@ static noinline int btrfs_ioctl_fitrim(sreturn -EOPNOTSUPP ;if (copy_from_user (&range, arg,sizeof (range)))return -EFAULT ; -if (range.start > total_bytes || - range.len < fs_info->sb->s_blocksize) + +/* +* NOTE: Don't truncate the range using super->total_bytes. Bytenr of +* block group is in the logical address space, which can be any +* sectorsize aligned bytenr in the range [0, U64_MAX]. +*/ +if (range.len < fs_info->sb->s_blocksize)return -EINVAL ; - range.len =min (range.len, total_bytes - range.start); range.minlen =max (range.minlen, minlen); ret =btrfs_trim_fs (fs_info, &range);if (ret <0 )
Greg Kroah-Hartman
maintainerPATCH 202/222 btrfs: iterate all devices during trim, instead of fs_devices::alloc_list
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jeff Mahoney <[email protected]>
commit d4e329de5e5e21594df2e0dd59da9acee71f133b upstream.
btrfs_trim_fs iterates over the fs_devices->alloc_list while holding the device_list_mutex. The problem is that ->alloc_list is protected by the chunk mutex. We don't want to hold the chunk mutex over the trim of the entire file system. Fortunately, the ->dev_list list is protected by the dev_list mutex and while it will give us all devices, including read-only devices, we already just skip the read-only devices. Then we can continue to take and release the chunk mutex while scanning each device.
--- fs/btrfs/extent-tree.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
fs/btrfs/extent-tree.c +2 -2
@@ -11107,8 +11107,8 @@ int btrfs_trim_fs(struct btrfs_fs_info *"failed to trim %llu block group(s), last error %d" , bg_failed, bg_ret);mutex_lock (&fs_info->fs_devices->device_list_mutex); - devices = &fs_info->fs_devices->alloc_list; -list_for_each_entry (device, devices, dev_alloc_list) { + devices = &fs_info->fs_devices->devices; +list_for_each_entry (device, devices, dev_list) { ret =btrfs_trim_free_extents (device, range->minlen, &group_trimmed);if (ret) {
Greg Kroah-Hartman
maintainerPATCH 203/222 btrfs: dont attempt to trim devices that dont support it
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jeff Mahoney <[email protected]>
commit 0be88e367fd8fbdb45257615d691f4675dda062f upstream.
We check whether any device the file system is using supports discard in the ioctl call, but then we attempt to trim free extents on every device regardless of whether discard is supported. Due to the way we mask off EOPNOTSUPP, we can end up issuing the trim operations on each free range on devices that don't support it, just wasting time.
--- fs/btrfs/extent-tree.c | 4 ++++ 1 file changed, 4 insertions(+)
fs/btrfs/extent-tree.c +4 -0
@@ -10976,6 +10976,10 @@ static int btrfs_trim_free_extents(struc *trimmed =0 ; +/* Discard not supported = nothing to do. */ +if (!blk_queue_discard (bdev_get_queue (device->bdev))) +return 0 ; +/* Not writeable = nothing to do. */ if (!device->writeable)return 0 ;
Greg Kroah-Hartman
maintainerPATCH 204/222 btrfs: wait on caching when putting the bg cache
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Josef Bacik <[email protected]>
commit 3aa7c7a31c26321696b92841d5103461c6f3f517 upstream.
While testing my backport I noticed there was a panic if I ran generic/416 generic/417 generic/418 all in a row. This just happened to uncover a race where we had outstanding IO after we destroy all of our workqueues, and then we'd go to queue the endio work on those free'd workqueues.
This is because we aren't waiting for the caching threads to be done before freeing everything up, so to fix this make sure we wait on any outstanding caching that's being done before we free up the block group, so we're sure to be done with all IO by the time we get to btrfs_stop_all_workers(). This fixes the panic I was seeing consistently in testing.
------------[ cut here ]------------ kernel BUG at fs/btrfs/volumes.c:6112! SMP PTI Modules linked in: CPU: 1 PID: 27165 Comm: kworker/u4:7 Not tainted 4.16.0-02155-g3553e54a578d-dirty #875 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Workqueue: btrfs-cache btrfs_cache_helper RIP: 0010:btrfs_map_bio+0x346/0x370 RSP: 0000:ffffc900061e79d0 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff880071542e00 RCX: 0000000000533000 RDX: ffff88006bb74380 RSI: 0000000000000008 RDI: ffff880078160000 RBP: 0000000000000001 R08: ffff8800781cd200 R09: 0000000000503000 R10: ffff88006cd21200 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: ffff8800781cd200 R15: ffff880071542e00 FS: 0000000000000000(0000) GS:ffff88007fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000817ffc4 CR3: 0000000078314000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: btree_submit_bio_hook+0x8a/0xd0 submit_one_bio+0x5d/0x80 read_extent_buffer_pages+0x18a/0x320 btree_read_extent_buffer_pages+0xbc/0x200 ? alloc_extent_buffer+0x359/0x3e0 read_tree_block+0x3d/0x60 read_block_for_search.isra.30+0x1a5/0x360 btrfs_search_slot+0x41b/0xa10 btrfs_next_old_leaf+0x212/0x470 caching_thread+0x323/0x490 normal_work_helper+0xc5/0x310 process_one_work+0x141/0x340 worker_thread+0x44/0x3c0 kthread+0xf8/0x130 ? process_one_work+0x340/0x340 ? kthread_bind+0x10/0x10 ret_from_fork+0x35/0x40 RIP: btrfs_map_bio+0x346/0x370 RSP: ffffc900061e79d0 ---[ end trace 827eb13e50846033 ]--- Kernel panic - not syncing: Fatal exception Kernel Offset: disabled ---[ end Kernel panic - not syncing: Fatal exception
--- fs/btrfs/extent-tree.c | 1 + 1 file changed, 1 insertion(+)
fs/btrfs/extent-tree.c +1 -0
@@ -9881,6 +9881,7 @@ void btrfs_put_block_group_cache(struct block_group =btrfs_lookup_first_block_group (info, last);while (block_group) { +wait_block_group_cache_done (block_group);spin_lock (&block_group->lock);if (block_group->iref)break ;
Greg Kroah-Hartman
maintainerPATCH 205/222 btrfs: protect space cache inode alloc with GFP_NOFS
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Josef Bacik <[email protected]>
commit 84de76a2fb217dc1b6bc2965cc397d1648aa1404 upstream.
If we're allocating a new space cache inode it's likely going to be under a transaction handle, so we need to use memalloc_nofs_save() in order to avoid deadlocks, and more importantly lockdep messages that make xfstests fail.
--- fs/btrfs/free-space-cache.c | 8 ++++++++ 1 file changed, 8 insertions(+)
fs/btrfs/free-space-cache.c +8 -0
@@ -22,6 +22,7 @@#include <linux/slab.h> #include <linux/math64.h> #include <linux/ratelimit.h> +#include <linux/sched/mm.h> #include "ctree.h" #include "free-space-cache.h" #include "transaction.h"
@@ -59,6 +60,7 @@ static struct inode *__lookup_free_spacestruct btrfs_free_space_header *header;struct extent_buffer *leaf;struct inode *inode =NULL ; +unsigned nofs_flag;int ret; key.objectid =BTRFS_FREE_SPACE_OBJECTID ;
@@ -80,7 +82,13 @@ static struct inode *__lookup_free_spacebtrfs_disk_key_to_cpu (&location, &disk_key);btrfs_release_path (path); +/* +* We are often under a trans handle at this point, so we need to make +* sure NOFS is set to keep us from deadlocking. +*/ + nofs_flag =memalloc_nofs_save (); inode =btrfs_iget (fs_info->sb, &location, root,NULL ); +memalloc_nofs_restore (nofs_flag);if (IS_ERR (inode))return inode;if (is_bad_inode (inode)) {
Greg Kroah-Hartman
maintainerPATCH 206/222 btrfs: reset max_extent_size on clear in a bitmap
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Josef Bacik <[email protected]>
commit 553cceb49681d60975d00892877d4c871bf220f9 upstream.
We need to clear the max_extent_size when we clear bits from a bitmap since it could have been from the range that contains the max_extent_size.
--- fs/btrfs/free-space-cache.c | 2 ++ 1 file changed, 2 insertions(+)
fs/btrfs/free-space-cache.c +2 -0
@@ -1710,6 +1710,8 @@ static inline void __bitmap_clear_bits(sbitmap_clear (info->bitmap, start, count); info->bytes -= bytes; +if (info->max_extent_size > ctl->unit) + info->max_extent_size =0 ; } static void bitmap_clear_bits(struct btrfs_free_space_ctl *ctl,
Greg Kroah-Hartman
maintainerPATCH 207/222 btrfs: make sure we create all new block groups
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Josef Bacik <[email protected]>
commit 545e3366db823dc3342ca9d7fea803f829c9062f upstream.
Allocating new chunks modifies both the extent and chunk tree, which can trigger new chunk allocations. So instead of doing list_for_each_safe, just do while (!list_empty()) so we make sure we don't exit with other pending bg's still on our list.
--- fs/btrfs/extent-tree.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
fs/btrfs/extent-tree.c +5 -2
@@ -10270,7 +10270,7 @@ error:void btrfs_create_pending_block_groups (struct btrfs_trans_handle *trans,struct btrfs_fs_info *fs_info) { -struct btrfs_block_group_cache *block_group, *tmp; +struct btrfs_block_group_cache *block_group;struct btrfs_root *extent_root = fs_info->extent_root;struct btrfs_block_group_item item;struct btrfs_key key;
@@ -10278,7 +10278,10 @@ void btrfs_create_pending_block_groups(sbool can_flush_pending_bgs = trans->can_flush_pending_bgs; trans->can_flush_pending_bgs = false; -list_for_each_entry_safe (block_group, tmp, &trans->new_bgs, bg_list) { +while (!list_empty (&trans->new_bgs)) { + block_group =list_first_entry (&trans->new_bgs, + struct btrfs_block_group_cache, + bg_list);if (ret) goto next;
Greg Kroah-Hartman
maintainerPATCH 208/222 Btrfs: fix warning when replaying log after fsync of a tmpfile
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <[email protected]>
commit f2d72f42d5fa3bf33761d9e47201745f624fcff5 upstream.
When replaying a log which contains a tmpfile (which necessarily has a link count of 0) we end up calling inc_nlink(), at fs/btrfs/tree-log.c:replay_one_buffer(), which produces a warning like the following:
[195191.943673] WARNING: CPU: 0 PID: 6924 at fs/inode.c:342 inc_nlink+0x33/0x40 [195191.943723] CPU: 0 PID: 6924 Comm: mount Not tainted 4.19.0-rc6-btrfs-next-38 #1 [195191.943724] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.2-0-gf9626ccb91-prebuilt.qemu-project.org 04/01/2014 [195191.943726] RIP: 0010:inc_nlink+0x33/0x40 [195191.943728] RSP: 0018:ffffb96e425e3870 EFLAGS: 00010246 [195191.943730] RAX: 0000000000000000 RBX: ffff8c0d1e6af4f0 RCX: 0000000000000006 [195191.943731] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8c0d1e6af4f0 [195191.943731] RBP: 0000000000000097 R08: 0000000000000001 R09: 0000000000000000 [195191.943732] R10: 0000000000000000 R11: 0000000000000000 R12: ffffb96e425e3a60 [195191.943733] R13: ffff8c0d10cff0c8 R14: ffff8c0d0d515348 R15: ffff8c0d78a1b3f8 [195191.943735] FS: 00007f570ee24480(0000) GS:ffff8c0dfb200000(0000) knlGS:0000000000000000 [195191.943736] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [195191.943737] CR2: 00005593286277c8 CR3: 00000000bb8f2006 CR4: 00000000003606f0 [195191.943739] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [195191.943740] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [195191.943741] Call Trace: [195191.943778] replay_one_buffer+0x797/0x7d0 [btrfs] [195191.943802] walk_up_log_tree+0x1c1/0x250 [btrfs] [195191.943809] ? rcu_read_lock_sched_held+0x3f/0x70 [195191.943825] walk_log_tree+0xae/0x1d0 [btrfs] [195191.943840] btrfs_recover_log_trees+0x1d7/0x4d0 [btrfs] [195191.943856] ? replay_dir_deletes+0x280/0x280 [btrfs] [195191.943870] open_ctree+0x1c3b/0x22a0 [btrfs] [195191.943887] btrfs_mount_root+0x6b4/0x800 [btrfs] [195191.943894] ? rcu_read_lock_sched_held+0x3f/0x70 [195191.943899] ? pcpu_alloc+0x55b/0x7c0 [195191.943906] ? mount_fs+0x3b/0x140 [195191.943908] mount_fs+0x3b/0x140 [195191.943912] ? __init_waitqueue_head+0x36/0x50 [195191.943916] vfs_kern_mount+0x62/0x160 [195191.943927] btrfs_mount+0x134/0x890 [btrfs] [195191.943936] ? rcu_read_lock_sched_held+0x3f/0x70 [195191.943938] ? pcpu_alloc+0x55b/0x7c0 [195191.943943] ? mount_fs+0x3b/0x140 [195191.943952] ? btrfs_remount+0x570/0x570 [btrfs] [195191.943954] mount_fs+0x3b/0x140 [195191.943956] ? __init_waitqueue_head+0x36/0x50 [195191.943960] vfs_kern_mount+0x62/0x160 [195191.943963] do_mount+0x1f9/0xd40 [195191.943967] ? memdup_user+0x4b/0x70 [195191.943971] ksys_mount+0x7e/0xd0 [195191.943974] __x64_sys_mount+0x21/0x30 [195191.943977] do_syscall_64+0x60/0x1b0 [195191.943980] entry_SYSCALL_64_after_hwframe+0x49/0xbe [195191.943983] RIP: 0033:0x7f570e4e524a [195191.943986] RSP: 002b:00007ffd83589478 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5 [195191.943989] RAX: ffffffffffffffda RBX: 0000563f335b2060 RCX: 00007f570e4e524a [195191.943990] RDX: 0000563f335b2240 RSI: 0000563f335b2280 RDI: 0000563f335b2260 [195191.943992] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000020 [195191.943993] R10: 00000000c0ed0000 R11: 0000000000000206 R12: 0000563f335b2260 [195191.943994] R13: 0000563f335b2240 R14: 0000000000000000 R15: 00000000ffffffff [195191.944002] irq event stamp: 8688 [195191.944010] hardirqs last enabled at (8687): [<ffffffff9cb004c3>] console_unlock+0x503/0x640 [195191.944012] hardirqs last disabled at (8688): [<ffffffff9ca037dd>] trace_hardirqs_off_thunk+0x1a/0x1c [195191.944018] softirqs last enabled at (8638): [<ffffffff9cc0a5d1>] __set_page_dirty_nobuffers+0x101/0x150 [195191.944020] softirqs last disabled at (8634): [<ffffffff9cc26bbe>] wb_wakeup_delayed+0x2e/0x60 [195191.944022] ---[ end trace 5d6e873a9a0b811a ]---
This happens because the inode does not have the flag I_LINKABLE set, which is a runtime only flag, not meant to be persisted, set when the inode is created through open(2) if the flag O_EXCL is not passed to it. Except for the warning, there are no other consequences (like corruptions or metadata inconsistencies).
Since it's pointless to replay a tmpfile as it would be deleted in a later phase of the log replay procedure (it has a link count of 0), fix this by not logging tmpfiles and if a tmpfile is found in a log (created by a kernel without this change), skip the replay of the inode.
A test case for fstests follows soon.
--- fs/btrfs/tree-log.c | 42 ++++++++++++++++++++++++++++++++---------- 1 file changed, 32 insertions(+), 10 deletions(-)
fs/btrfs/tree-log.c +32 -10
@@ -273,6 +273,13 @@ struct walk_control {/* what stage of the replay code we're currently in */ int stage; +/* +* Ignore any items from the inode currently being processed. Needs +* to be set every time we find a BTRFS_INODE_ITEM_KEY and we are in +* the LOG_WALK_REPLAY_INODES stage. +*/ +bool ignore_cur_inode; +/* the root we are currently replaying */ struct btrfs_root *replay_dest;
@@ -2363,6 +2370,20 @@ static int replay_one_buffer(struct btrf inode_item =btrfs_item_ptr (eb, i, struct btrfs_inode_item); +/* +* If we have a tmpfile (O_TMPFILE) that got fsync'ed +* and never got linked before the fsync, skip it, as +* replaying it is pointless since it would be deleted +* later. We skip logging tmpfiles, but it's always +* possible we are replaying a log created with a kernel +* that used to log tmpfiles. +*/ +if (btrfs_inode_nlink (eb, inode_item) ==0 ) { + wc->ignore_cur_inode = true; +continue ; + }else { + wc->ignore_cur_inode = false; + } ret =replay_xattr_deletes (wc->trans, root, log, path, key.objectid);if (ret)
@@ -2400,16 +2421,8 @@ static int replay_one_buffer(struct btrf root->fs_info->sectorsize); ret =btrfs_drop_extents (wc->trans, root, inode, from, (u64)-1 ,1 ); -/* -* If the nlink count is zero here, the iput -* will free the inode. We bump it to make -* sure it doesn't get freed until the link -* count fixup is done. -*/ if (!ret) { -if (inode->i_nlink ==0 ) -inc_nlink (inode); -/* Update link count and nbytes. */ +/* Update the inode's nbytes. */ ret =btrfs_update_inode (wc->trans, root, inode); }
@@ -2424,6 +2437,9 @@ static int replay_one_buffer(struct btrfbreak ; } +if (wc->ignore_cur_inode) +continue ; +if (key.type ==BTRFS_DIR_INDEX_KEY && wc->stage ==LOG_WALK_REPLAY_DIR_INDEX ) { ret = replay_one_dir_item(wc->trans, root, path,
@@ -5644,7 +5660,13 @@ static int btrfs_log_inode_parent(structif (ret) goto end_no_trans; -if (btrfs_inode_in_log (inode, trans->transid)) { +/* +* Skip already logged inodes or inodes corresponding to tmpfiles +* (since logging them is pointless, a link count of 0 means they +* will never be accessible). +*/ +if (btrfs_inode_in_log (inode, trans->transid) || + inode->vfs_inode.i_nlink ==0 ) { ret =BTRFS_NO_LOG_SYNC ; goto end_no_trans; }
Greg Kroah-Hartman
maintainerPATCH 209/222 Btrfs: fix wrong dentries after fsync of file that got its parent replaced
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <[email protected]>
commit 0f375eed92b5a407657532637ed9652611a682f5 upstream.
In a scenario like the following:
mkdir /mnt/A # inode 258 mkdir /mnt/B # inode 259 touch /mnt/B/bar # inode 260
sync
mv /mnt/B/bar /mnt/A/bar
mv -T /mnt/A /mnt/B
fsync /mnt/B/bar
<power fail>
After replaying the log we end up with file bar having 2 hard links, both with the name 'bar' and one in the directory with inode number 258 and the other in the directory with inode number 259. Also, we end up with the directory inode 259 still existing and with the directory inode 258 still named as 'A', instead of 'B'. In this scenario, file 'bar' should only have one hard link, located at directory inode 258, the directory inode 259 should not exist anymore and the name for directory inode 258 should be 'B'.
This incorrect behaviour happens because when attempting to log the old parents of an inode, we skip any parents that no longer exist. Fix this by forcing a full commit if an old parent no longer exists.
A test case for fstests follows soon.
--- fs/btrfs/tree-log.c | 30 +++++++++++++++++++++++++++--- 1 file changed, 27 insertions(+), 3 deletions(-)
fs/btrfs/tree-log.c +27 -3
@@ -5583,9 +5583,33 @@ static int btrfs_log_all_parents(struct dir_inode =btrfs_iget (fs_info->sb, &inode_key, root,NULL ); -/* If parent inode was deleted, skip it. */ -if (IS_ERR (dir_inode)) -continue ; +/* +* If the parent inode was deleted, return an error to +* fallback to a transaction commit. This is to prevent +* getting an inode that was moved from one parent A to +* a parent B, got its former parent A deleted and then +* it got fsync'ed, from existing at both parents after +* a log replay (and the old parent still existing). +* Example: +* +* mkdir /mnt/A +* mkdir /mnt/B +* touch /mnt/B/bar +* sync +* mv /mnt/B/bar /mnt/A/bar +* mv -T /mnt/A /mnt/B +* fsync /mnt/B/bar +* <power fail> +* +* If we ignore the old parent B which got deleted, +* after a log replay we would have file bar linked +* at both parents and the old parent B would still +* exist. +*/ +if (IS_ERR (dir_inode)) { + ret =PTR_ERR (dir_inode); + goto out; + }if (ctx) ctx->log_new_dentries = false;
Greg Kroah-Hartman
maintainerPATCH 210/222 btrfs: qgroup: Dirty all qgroups before rescan
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qu Wenruo <[email protected]>
commit 9c7b0c2e8dbfbcd80a71e2cbfe02704f26c185c6 upstream.
[BUG]
In the following case, rescan won't zero out the number of qgroup 1/0:
$ mkfs.btrfs -fq $DEV $ mount $DEV /mnt
$ btrfs quota enable /mnt $ btrfs qgroup create 1/0 /mnt $ btrfs sub create /mnt/sub $ btrfs qgroup assign 0/257 1/0 /mnt
$ dd if=/dev/urandom of=/mnt/sub/file bs=1k count=1000 $ btrfs sub snap /mnt/sub /mnt/snap $ btrfs quota rescan -w /mnt $ btrfs qgroup show -pcre /mnt qgroupid rfer excl max_rfer max_excl parent child -------- ---- ---- -------- -------- ------ ----- 0/5 16.00KiB 16.00KiB none none --- --- 0/257 1016.00KiB 16.00KiB none none 1/0 --- 0/258 1016.00KiB 16.00KiB none none --- --- 1/0 1016.00KiB 16.00KiB none none --- 0/257
So far so good, but:
$ btrfs qgroup remove 0/257 1/0 /mnt WARNING: quotas may be inconsistent, rescan needed $ btrfs quota rescan -w /mnt $ btrfs qgroup show -pcre /mnt qgoupid rfer excl max_rfer max_excl parent child -------- ---- ---- -------- -------- ------ ----- 0/5 16.00KiB 16.00KiB none none --- --- 0/257 1016.00KiB 16.00KiB none none --- --- 0/258 1016.00KiB 16.00KiB none none --- --- 1/0 1016.00KiB 16.00KiB none none --- --- ^^^^^^^^^^ ^^^^^^^^ not cleared
[CAUSE]
Before rescan we call qgroup_rescan_zero_tracking() to zero out all qgroups' accounting numbers.
However we don't mark all qgroups dirty, but rely on rescan to do so.
If we have any high level qgroup without children, it won't be marked dirty during rescan, since we cannot reach that qgroup.
This will cause QGROUP_INFO items of childless qgroups never get updated in the quota tree, thus their numbers will stay the same in "btrfs qgroup show" output.
[FIX]
Just mark all qgroups dirty in qgroup_rescan_zero_tracking(), so even if we have childless qgroups, their QGROUP_INFO items will still get updated during rescan.
--- fs/btrfs/qgroup.c | 1 + 1 file changed, 1 insertion(+)
fs/btrfs/qgroup.c +1 -0
@@ -2763,6 +2763,7 @@ qgroup_rescan_zero_tracking(struct btrfs qgroup->rfer_cmpr =0 ; qgroup->excl =0 ; qgroup->excl_cmpr =0 ; +qgroup_dirty (fs_info, qgroup); }spin_unlock (&fs_info->qgroup_lock); }
Greg Kroah-Hartman
maintainerPATCH 211/222 Btrfs: fix null pointer dereference on compressed write path error
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <[email protected]>
commit 3527a018c00e5dbada2f9d7ed5576437b6dd5cfb upstream.
At inode.c:compress_file_range(), under the "free_pages_out" label, we can end up dereferencing the "pages" pointer when it has a NULL value. This case happens when "start" has a value of 0 and we fail to allocate memory for the "pages" pointer. When that happens we jump to the "cont" label and then enter the "if (start == 0)" branch where we immediately call the cow_file_range_inline() function. If that function returns 0 (success creating an inline extent) or an error (like -ENOMEM for example) we jump to the "free_pages_out" label and then access "pages[i]" leading to a NULL pointer dereference, since "nr_pages" has a value greater than zero at that point.
Fix this by setting "nr_pages" to 0 when we fail to allocate memory for the "pages" pointer.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201119
--- fs/btrfs/inode.c | 1 + 1 file changed, 1 insertion(+)
fs/btrfs/inode.c +1 -0
@@ -524,6 +524,7 @@ again: pages =kcalloc (nr_pages,sizeof (struct page *),GFP_NOFS );if (!pages) {/* just bail out to the uncompressed code */ + nr_pages =0 ; goto cont; }
Greg Kroah-Hartman
maintainerPATCH 212/222 Btrfs: fix assertion on fsync of regular file when using no-holes feature
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <[email protected]>
commit 7ed586d0a8241e81d58c656c5b315f781fa6fc97 upstream.
When using the NO_HOLES feature and logging a regular file, we were expecting that if we find an inline extent, that either its size in RAM (uncompressed and unenconded) matches the size of the file or if it does not, that it matches the sector size and it represents compressed data. This assertion does not cover a case where the length of the inline extent is smaller than the sector size and also smaller the file's size, such case is possible through fallocate. Example:
$ mkfs.btrfs -f -O no-holes /dev/sdb $ mount /dev/sdb /mnt
$ xfs_io -f -c "pwrite -S 0xb60 0 21" /mnt/foobar $ xfs_io -c "falloc 40 40" /mnt/foobar $ xfs_io -c "fsync" /mnt/foobar
In the above example we trigger the assertion because the inline extent's length is 21 bytes while the file size is 80 bytes. The fallocate() call merely updated the file's size and did not touch the existing inline extent, as expected.
So fix this by adjusting the assertion so that an inline extent length smaller than the file size is valid if the file size is smaller than the filesystem's sector size.
A test case for fstests follows soon.
--- fs/btrfs/tree-log.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
fs/btrfs/tree-log.c +2 -1
@@ -4641,7 +4641,8 @@ static int btrfs_log_trailing_hole(strucASSERT (len == i_size || (len == fs_info->sectorsize &&btrfs_file_extent_compression (leaf, extent) != -BTRFS_COMPRESS_NONE )); +BTRFS_COMPRESS_NONE ) || + (len < i_size && i_size < fs_info->sectorsize));return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 213/222 btrfs: set max_extent_size properly
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Josef Bacik <[email protected]>
commit ad22cf6ea47fa20fbe11ac324a0a15c0a9a4a2a9 upstream.
We can't use entry->bytes if our entry is a bitmap entry, we need to use entry->max_extent_size in that case. Fix up all the logic to make this consistent.
--- fs/btrfs/free-space-cache.c | 30 ++++++++++++++++++++---------- 1 file changed, 20 insertions(+), 10 deletions(-)
fs/btrfs/free-space-cache.c +20 -10
@@ -1795,6 +1795,13 @@ static int search_bitmap(struct btrfs_frreturn -1 ; } +static inline u64 get_max_extent_size (struct btrfs_free_space *entry) +{ +if (entry->bitmap) +return entry->max_extent_size; +return entry->bytes; +} +/* Cache the size of the max extent in bytes */ static struct btrfs_free_space * find_free_space(struct btrfs_free_space_ctl *ctl, u64 *offset, u64 *bytes,
@@ -1816,8 +1823,8 @@ find_free_space(struct btrfs_free_space_for (node = &entry->offset_index; node; node =rb_next (node)) { entry = rb_entry(node, struct btrfs_free_space, offset_index);if (entry->bytes < *bytes) { -if (entry->bytes > *max_extent_size) - *max_extent_size = entry->bytes; + *max_extent_size =max (get_max_extent_size (entry), + *max_extent_size);continue ; }
@@ -1835,8 +1842,8 @@ find_free_space(struct btrfs_free_space_ }if (entry->bytes < *bytes + align_off) { -if (entry->bytes > *max_extent_size) - *max_extent_size = entry->bytes; + *max_extent_size =max (get_max_extent_size (entry), + *max_extent_size);continue ; }
@@ -1848,8 +1855,10 @@ find_free_space(struct btrfs_free_space_ *offset = tmp; *bytes = size;return entry; - }else if (size > *max_extent_size) { - *max_extent_size = size; + }else { + *max_extent_size = +max (get_max_extent_size (entry), + *max_extent_size); }continue ; }
@@ -2709,8 +2718,8 @@ static u64 btrfs_alloc_from_bitmap(struc err =search_bitmap (ctl, entry, &search_start, &search_bytes, true);if (err) { -if (search_bytes > *max_extent_size) - *max_extent_size = search_bytes; + *max_extent_size =max (get_max_extent_size (entry), + *max_extent_size);return 0 ; }
@@ -2747,8 +2756,9 @@ u64 btrfs_alloc_from_cluster(struct btrf entry = rb_entry(node, struct btrfs_free_space, offset_index);while (1 ) { -if (entry->bytes < bytes && entry->bytes > *max_extent_size) - *max_extent_size = entry->bytes; +if (entry->bytes < bytes) + *max_extent_size =max (get_max_extent_size (entry), + *max_extent_size);if (entry->bytes < bytes || (!entry->bitmap && entry->offset < min_start)) {
Greg Kroah-Hartman
maintainerPATCH 214/222 btrfs: dont use ctl->free_space for max_extent_size
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Josef Bacik <[email protected]>
commit fb5c39d7a887108087de6ff93d3f326b01b4ef41 upstream.
max_extent_size is supposed to be the largest contiguous range for the space info, and ctl->free_space is the total free space in the block group. We need to keep track of these separately and _only_ use the max_free_space if we don't have a max_extent_size, as that means our original request was too large to search any of the block groups for and therefore wouldn't have a max_extent_size set.
--- fs/btrfs/extent-tree.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
fs/btrfs/extent-tree.c +5 -2
@@ -7573,6 +7573,7 @@ static noinline int find_free_extent(strstruct btrfs_block_group_cache *block_group =NULL ;u64 search_start =0 ;u64 max_extent_size =0 ; +u64 max_free_space =0 ;u64 empty_cluster =0 ;struct btrfs_space_info *space_info;int loop =0 ;
@@ -7867,8 +7868,8 @@ unclustered_alloc:spin_lock (&ctl->tree_lock);if (ctl->free_space < num_bytes + empty_cluster + empty_size) { -if (ctl->free_space > max_extent_size) - max_extent_size = ctl->free_space; + max_free_space =max (max_free_space, + ctl->free_space);spin_unlock (&ctl->tree_lock); goto loop; }
@@ -8037,6 +8038,8 @@ loop: } out:if (ret == -ENOSPC ) { +if (!max_extent_size) + max_extent_size = max_free_space;spin_lock (&space_info->lock); space_info->max_extent_size = max_extent_size;spin_unlock (&space_info->lock);
Greg Kroah-Hartman
maintainerPATCH 215/222 btrfs: only free reserved extent if we didnt insert it
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Josef Bacik <[email protected]>
commit 49940bdd57779c78462da7aa5a8650b2fea8c2ff upstream.
When we insert the file extent once the ordered extent completes we free the reserved extent reservation as it'll have been migrated to the bytes_used counter. However if we error out after this step we'll still clear the reserved extent reservation, resulting in a negative accounting of the reserved bytes for the block group and space info. Fix this by only doing the free if we didn't successfully insert a file extent for this extent.
--- fs/btrfs/inode.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
fs/btrfs/inode.c +9 -1
@@ -2966,6 +2966,7 @@ static int btrfs_finish_ordered_io(strucbool truncated = false;bool range_locked = false;bool clear_new_delalloc_bytes = false; +bool clear_reserved_extent = true; if (!test_bit(BTRFS_ORDERED_NOCOW, &ordered_extent->flags) && !test_bit(BTRFS_ORDERED_PREALLOC, &ordered_extent->flags) &&
@@ -3069,10 +3070,12 @@ static int btrfs_finish_ordered_io(struc logical_len, logical_len, compress_type,0 ,0 , BTRFS_FILE_EXTENT_REG); -if (!ret) +if (!ret) { + clear_reserved_extent = false;btrfs_release_delalloc_bytes (fs_info, ordered_extent->start, ordered_extent->disk_len); + } } unpin_extent_cache(&BTRFS_I(inode)->extent_tree, ordered_extent->file_offset, ordered_extent->len,
@@ -3132,8 +3135,13 @@ out:* wrong we need to return the space for this ordered extent * back to the allocator. We only free the extent in the * truncated case if we didn't write out the extent at all. +* +* If we made it past insert_reserved_file_extent before we +* errored out then we don't need to do this as the accounting +* has already been done. */ if ((ret || !logical_len) && + clear_reserved_extent && !test_bit (BTRFS_ORDERED_NOCOW , &ordered_extent->flags) && !test_bit (BTRFS_ORDERED_PREALLOC , &ordered_extent->flags)) btrfs_free_reserved_extent(fs_info,
Greg Kroah-Hartman
maintainerPATCH 216/222 btrfs: dont run delayed_iputs in commit
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Josef Bacik <[email protected]>
commit 30928e9baac238a7330085a1c5747f0b5df444b4 upstream.
This could result in a really bad case where we do something like
evict
evict_refill_and_join
btrfs_commit_transaction
btrfs_run_delayed_iputs
evict
evict_refill_and_join
btrfs_commit_transaction
... forever
We have plenty of other places where we run delayed iputs that are much safer, let those do the work.
--- fs/btrfs/transaction.c | 9 --------- 1 file changed, 9 deletions(-)
fs/btrfs/transaction.c +0 -9
@@ -2307,15 +2307,6 @@ int btrfs_commit_transaction(struct btrfkmem_cache_free (btrfs_trans_handle_cachep, trans); -/* -* If fs has been frozen, we can not handle delayed iputs, otherwise -* it'll result in deadlock about SB_FREEZE_FS. -*/ -if (current != fs_info->transaction_kthread && - current != fs_info->cleaner_kthread && - !test_bit (BTRFS_FS_FROZEN , &fs_info->flags)) -btrfs_run_delayed_iputs (fs_info); -return ret; scrub_continue:
Greg Kroah-Hartman
maintainerPATCH 217/222 btrfs: move the dio_sem higher up the callchain
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Josef Bacik <[email protected]>
commit c495144bc6962186feae31d687596d2472000e45 upstream.
We're getting a lockdep splat because we take the dio_sem under the log_mutex. What we really need is to protect fsync() from logging an extent map for an extent we never waited on higher up, so just guard the whole thing with dio_sem.
======================================================
WARNING: possible circular locking dependency detected 4.18.0-rc4-xfstests-00025-g5de5edbaf1d4 #411 Not tainted
------------------------------------------------------
aio-dio-invalid/30928 is trying to acquire lock:0000000092621cfd (&mm->mmap_sem){++++}, at: get_user_pages_unlocked+0x5a/0x1e0
but task is already holding lock:00000000cefe6b35 (&ei->dio_sem){++++}, at: btrfs_direct_IO+0x3be/0x400
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #5 (&ei->dio_sem){++++}:
lock_acquire+0xbd/0x220
down_write+0x51/0xb0
btrfs_log_changed_extents+0x80/0xa40
btrfs_log_inode+0xbaf/0x1000
btrfs_log_inode_parent+0x26f/0xa80
btrfs_log_dentry_safe+0x50/0x70
btrfs_sync_file+0x357/0x540
do_fsync+0x38/0x60
__ia32_sys_fdatasync+0x12/0x20
do_fast_syscall_32+0x9a/0x2f0
entry_SYSENTER_compat+0x84/0x96-> #4 (&ei->log_mutex){+.+.}:
lock_acquire+0xbd/0x220
__mutex_lock+0x86/0xa10
btrfs_record_unlink_dir+0x2a/0xa0
btrfs_unlink+0x5a/0xc0
vfs_unlink+0xb1/0x1a0
do_unlinkat+0x264/0x2b0
do_fast_syscall_32+0x9a/0x2f0
entry_SYSENTER_compat+0x84/0x96-> #3 (sb_internal#2){.+.+}:
lock_acquire+0xbd/0x220
__sb_start_write+0x14d/0x230
start_transaction+0x3e6/0x590
btrfs_evict_inode+0x475/0x640
evict+0xbf/0x1b0
btrfs_run_delayed_iputs+0x6c/0x90
cleaner_kthread+0x124/0x1a0
kthread+0x106/0x140
ret_from_fork+0x3a/0x50-> #2 (&fs_info->cleaner_delayed_iput_mutex){+.+.}:
lock_acquire+0xbd/0x220
__mutex_lock+0x86/0xa10
btrfs_alloc_data_chunk_ondemand+0x197/0x530
btrfs_check_data_free_space+0x4c/0x90
btrfs_delalloc_reserve_space+0x20/0x60
btrfs_page_mkwrite+0x87/0x520
do_page_mkwrite+0x31/0xa0
__handle_mm_fault+0x799/0xb00
handle_mm_fault+0x7c/0xe0
__do_page_fault+0x1d3/0x4a0
async_page_fault+0x1e/0x30-> #1 (sb_pagefaults){.+.+}:
lock_acquire+0xbd/0x220
__sb_start_write+0x14d/0x230
btrfs_page_mkwrite+0x6a/0x520
do_page_mkwrite+0x31/0xa0
__handle_mm_fault+0x799/0xb00
handle_mm_fault+0x7c/0xe0
__do_page_fault+0x1d3/0x4a0
async_page_fault+0x1e/0x30-> #0 (&mm->mmap_sem){++++}:
__lock_acquire+0x42e/0x7a0
lock_acquire+0xbd/0x220
down_read+0x48/0xb0
get_user_pages_unlocked+0x5a/0x1e0
get_user_pages_fast+0xa4/0x150
iov_iter_get_pages+0xc3/0x340
do_direct_IO+0xf93/0x1d70
__blockdev_direct_IO+0x32d/0x1c20
btrfs_direct_IO+0x227/0x400
generic_file_direct_write+0xcf/0x180
btrfs_file_write_iter+0x308/0x58c
aio_write+0xf8/0x1d0
io_submit_one+0x3a9/0x620
__ia32_compat_sys_io_submit+0xb2/0x270
do_int80_syscall_32+0x5b/0x1a0
entry_INT80_compat+0x88/0xa0other info that might help us debug this:
Chain exists of: &mm->mmap_sem --> &ei->log_mutex --> &ei->dio_sem Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&ei->dio_sem);
lock(&ei->log_mutex);
lock(&ei->dio_sem); lock(&mm->mmap_sem);
*** DEADLOCK ***
1 lock held by aio-dio-invalid/30928:
#0: 00000000cefe6b35 (&ei->dio_sem){++++}, at: btrfs_direct_IO+0x3be/0x400
stack backtrace: CPU: 0 PID: 30928 Comm: aio-dio-invalid Not tainted 4.18.0-rc4-xfstests-00025-g5de5edbaf1d4 #411 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Call Trace: dump_stack+0x7c/0xbb print_circular_bug.isra.37+0x297/0x2a4 check_prev_add.constprop.45+0x781/0x7a0 ? __lock_acquire+0x42e/0x7a0 validate_chain.isra.41+0x7f0/0xb00 __lock_acquire+0x42e/0x7a0 lock_acquire+0xbd/0x220 ? get_user_pages_unlocked+0x5a/0x1e0 down_read+0x48/0xb0 ? get_user_pages_unlocked+0x5a/0x1e0 get_user_pages_unlocked+0x5a/0x1e0 get_user_pages_fast+0xa4/0x150 iov_iter_get_pages+0xc3/0x340 do_direct_IO+0xf93/0x1d70 ? __alloc_workqueue_key+0x358/0x490 ? __blockdev_direct_IO+0x14b/0x1c20 __blockdev_direct_IO+0x32d/0x1c20 ? btrfs_run_delalloc_work+0x40/0x40 ? can_nocow_extent+0x490/0x490 ? kvm_clock_read+0x1f/0x30 ? can_nocow_extent+0x490/0x490 ? btrfs_run_delalloc_work+0x40/0x40 btrfs_direct_IO+0x227/0x400 ? btrfs_run_delalloc_work+0x40/0x40 generic_file_direct_write+0xcf/0x180 btrfs_file_write_iter+0x308/0x58c aio_write+0xf8/0x1d0 ? kvm_clock_read+0x1f/0x30 ? __might_fault+0x3e/0x90 io_submit_one+0x3a9/0x620 ? io_submit_one+0xe5/0x620 __ia32_compat_sys_io_submit+0xb2/0x270 do_int80_syscall_32+0x5b/0x1a0 entry_INT80_compat+0x88/0xa0
--- fs/btrfs/file.c | 12 ++++++++++++ fs/btrfs/tree-log.c | 2 -- 2 files changed, 12 insertions(+), 2 deletions(-)
fs/btrfs/file.c +12 -0
@@ -2078,6 +2078,14 @@ int btrfs_sync_file(struct file *file, l goto out;inode_lock (inode); + +/* +* We take the dio_sem here because the tree log stuff can race with +* lockless dio writes and get an extent map logged for an extent we +* never waited on. We need it this high up for lockdep reasons. +*/ +down_write (&BTRFS_I (inode)->dio_sem); +atomic_inc (&root->log_batch); full_sync =test_bit (BTRFS_INODE_NEEDS_FULL_SYNC , &BTRFS_I (inode)->runtime_flags);
@@ -2129,6 +2137,7 @@ int btrfs_sync_file(struct file *file, l ret =start_ordered_ops (inode, start, end); }if (ret) { +up_write (&BTRFS_I (inode)->dio_sem);inode_unlock (inode); goto out; }
@@ -2184,6 +2193,7 @@ int btrfs_sync_file(struct file *file, l* checked called fsync. */ ret =filemap_check_wb_err (inode->i_mapping, file->f_wb_err); +up_write (&BTRFS_I (inode)->dio_sem);inode_unlock (inode); goto out; }
@@ -2208,6 +2218,7 @@ int btrfs_sync_file(struct file *file, l trans =btrfs_start_transaction (root,0 );if (IS_ERR (trans)) { ret =PTR_ERR (trans); +up_write (&BTRFS_I (inode)->dio_sem);inode_unlock (inode); goto out; }
@@ -2229,6 +2240,7 @@ int btrfs_sync_file(struct file *file, l* file again, but that will end up using the synchronization * inside btrfs_sync_log to keep things safe. */ +up_write (&BTRFS_I (inode)->dio_sem);inode_unlock (inode);/*
fs/btrfs/tree-log.c +0 -2
@@ -4362,7 +4362,6 @@ static int btrfs_log_changed_extents(strINIT_LIST_HEAD (&extents); -down_write (&inode->dio_sem);write_lock (&tree->lock); test_gen = root->fs_info->last_trans_committed; logged_start = start;
@@ -4443,7 +4442,6 @@ process: }WARN_ON (!list_empty (&extents));write_unlock (&tree->lock); -up_write (&inode->dio_sem);btrfs_release_path (path);if (!ret)
Greg Kroah-Hartman
maintainerPATCH 218/222 Btrfs: fix use-after-free during inode eviction
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <[email protected]>
commit 421f0922a2cfb0c75acd9746454aaa576c711a65 upstream.
At inode.c:evict_inode_truncate_pages(), when we iterate over the inode's extent states, we access an extent state record's "state" field after we unlocked the inode's io tree lock. This can lead to a use-after-free issue because after we unlock the io tree that extent state record might have been freed due to being merged into another adjacent extent state record (a previous inflight bio for a read operation finished in the meanwhile which unlocked a range in the io tree and cause a merge of extent state records, as explained in the comment before the while loop added in commit 6ca0709756710 ("Btrfs: fix hang during inode eviction due to concurrent readahead")).
Fix this by keeping a copy of the extent state's flags in a local variable and using it after unlocking the io tree.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201189
--- fs/btrfs/inode.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
fs/btrfs/inode.c +3 -1
@@ -5335,11 +5335,13 @@ static void evict_inode_truncate_pages(sstruct extent_state *cached_state =NULL ;u64 start;u64 end; +unsigned state_flags; node =rb_first (&io_tree->state); state = rb_entry(node, struct extent_state, rb_node); start = state->start; end = state->end; + state_flags = state->state;spin_unlock (&io_tree->lock);lock_extent_bits (io_tree, start, end, &cached_state);
@@ -5352,7 +5354,7 @@ static void evict_inode_truncate_pages(s* * Note, end is the bytenr of last byte, so we need + 1 here. */ -if (state->state &EXTENT_DELALLOC ) +if (state_flags &EXTENT_DELALLOC )btrfs_qgroup_free_data (inode,NULL , start, end - start +1 ); clear_extent_bit(io_tree, start, end,
Greg Kroah-Hartman
maintainerPATCH 219/222 Btrfs: fix use-after-free when dumping free space
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <[email protected]>
commit 9084cb6a24bf5838a665af92ded1af8363f9e563 upstream.
We were iterating a block group's free space cache rbtree without locking first the lock that protects it (the free_space_ctl->free_space_offset rbtree is protected by the free_space_ctl->tree_lock spinlock).
KASAN reported an use-after-free problem when iterating such a rbtree due to a concurrent rbtree delete:
[ 9520.359168] ==================================================================
[ 9520.359656] BUG: KASAN: use-after-free in rb_next+0x13/0x90
[ 9520.359949] Read of size 8 at addr ffff8800b7ada500 by task btrfs-transacti/1721
[ 9520.360357]
[ 9520.360530] CPU: 4 PID: 1721 Comm: btrfs-transacti Tainted: G L 4.19.0-rc8-nbor #555
[ 9520.360990] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
[ 9520.362682] Call Trace:
[ 9520.362887] dump_stack+0xa4/0xf5
[ 9520.363146] print_address_description+0x78/0x280
[ 9520.363412] kasan_report+0x263/0x390
[ 9520.363650] ? rb_next+0x13/0x90
[ 9520.363873] __asan_load8+0x54/0x90
[ 9520.364102] rb_next+0x13/0x90
[ 9520.364380] btrfs_dump_free_space+0x146/0x160 [btrfs]
[ 9520.364697] dump_space_info+0x2cd/0x310 [btrfs]
[ 9520.364997] btrfs_reserve_extent+0x1ee/0x1f0 [btrfs]
[ 9520.365310] __btrfs_prealloc_file_range+0x1cc/0x620 [btrfs]
[ 9520.365646] ? btrfs_update_time+0x180/0x180 [btrfs]
[ 9520.365923] ? _raw_spin_unlock+0x27/0x40
[ 9520.366204] ? btrfs_alloc_data_chunk_ondemand+0x2c0/0x5c0 [btrfs]
[ 9520.366549] btrfs_prealloc_file_range_trans+0x23/0x30 [btrfs]
[ 9520.366880] cache_save_setup+0x42e/0x580 [btrfs]
[ 9520.367220] ? btrfs_check_data_free_space+0xd0/0xd0 [btrfs]
[ 9520.367518] ? lock_downgrade+0x2f0/0x2f0
[ 9520.367799] ? btrfs_write_dirty_block_groups+0x11f/0x6e0 [btrfs]
[ 9520.368104] ? kasan_check_read+0x11/0x20
[ 9520.368349] ? do_raw_spin_unlock+0xa8/0x140
[ 9520.368638] btrfs_write_dirty_block_groups+0x2af/0x6e0 [btrfs]
[ 9520.368978] ? btrfs_start_dirty_block_groups+0x870/0x870 [btrfs]
[ 9520.369282] ? do_raw_spin_unlock+0xa8/0x140
[ 9520.369534] ? _raw_spin_unlock+0x27/0x40
[ 9520.369811] ? btrfs_run_delayed_refs+0x1b8/0x230 [btrfs]
[ 9520.370137] commit_cowonly_roots+0x4b9/0x610 [btrfs]
[ 9520.370560] ? commit_fs_roots+0x350/0x350 [btrfs]
[ 9520.370926] ? btrfs_run_delayed_refs+0x1b8/0x230 [btrfs]
[ 9520.371285] btrfs_commit_transaction+0x5e5/0x10e0 [btrfs]
[ 9520.371612] ? btrfs_apply_pending_changes+0x90/0x90 [btrfs]
[ 9520.371943] ? start_transaction+0x168/0x6c0 [btrfs]
[ 9520.372257] transaction_kthread+0x21c/0x240 [btrfs]
[ 9520.372537] kthread+0x1d2/0x1f0
[ 9520.372793] ? btrfs_cleanup_transaction+0xb50/0xb50 [btrfs]
[ 9520.373090] ? kthread_park+0xb0/0xb0
[ 9520.373329] ret_from_fork+0x3a/0x50
[ 9520.373567]
[ 9520.373738] Allocated by task 1804:
[ 9520.373974] kasan_kmalloc+0xff/0x180
[ 9520.374208] kasan_slab_alloc+0x11/0x20
[ 9520.374447] kmem_cache_alloc+0xfc/0x2d0
[ 9520.374731] __btrfs_add_free_space+0x40/0x580 [btrfs]
[ 9520.375044] unpin_extent_range+0x4f7/0x7a0 [btrfs]
[ 9520.375383] btrfs_finish_extent_commit+0x15f/0x4d0 [btrfs]
[ 9520.375707] btrfs_commit_transaction+0xb06/0x10e0 [btrfs]
[ 9520.376027] btrfs_alloc_data_chunk_ondemand+0x237/0x5c0 [btrfs]
[ 9520.376365] btrfs_check_data_free_space+0x81/0xd0 [btrfs]
[ 9520.376689] btrfs_delalloc_reserve_space+0x25/0x80 [btrfs]
[ 9520.377018] btrfs_direct_IO+0x42e/0x6d0 [btrfs]
[ 9520.377284] generic_file_direct_write+0x11e/0x220
[ 9520.377587] btrfs_file_write_iter+0x472/0xac0 [btrfs]
[ 9520.377875] aio_write+0x25c/0x360
[ 9520.378106] io_submit_one+0xaa0/0xdc0
[ 9520.378343] __se_sys_io_submit+0xfa/0x2f0
[ 9520.378589] __x64_sys_io_submit+0x43/0x50
[ 9520.378840] do_syscall_64+0x7d/0x240
[ 9520.379081] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 9520.379387]
[ 9520.379557] Freed by task 1802:
[ 9520.379782] __kasan_slab_free+0x173/0x260
[ 9520.380028] kasan_slab_free+0xe/0x10
[ 9520.380262] kmem_cache_free+0xc1/0x2c0
[ 9520.380544] btrfs_find_space_for_alloc+0x4cd/0x4e0 [btrfs]
[ 9520.380866] find_free_extent+0xa99/0x17e0 [btrfs]
[ 9520.381166] btrfs_reserve_extent+0xd5/0x1f0 [btrfs]
[ 9520.381474] btrfs_get_blocks_direct+0x60b/0xbd0 [btrfs]
[ 9520.381761] __blockdev_direct_IO+0x10ee/0x58a1
[ 9520.382059] btrfs_direct_IO+0x25a/0x6d0 [btrfs]
[ 9520.382321] generic_file_direct_write+0x11e/0x220
[ 9520.382623] btrfs_file_write_iter+0x472/0xac0 [btrfs]
[ 9520.382904] aio_write+0x25c/0x360
[ 9520.383172] io_submit_one+0xaa0/0xdc0
[ 9520.383416] __se_sys_io_submit+0xfa/0x2f0
[ 9520.383678] __x64_sys_io_submit+0x43/0x50
[ 9520.383927] do_syscall_64+0x7d/0x240
[ 9520.384165] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 9520.384439]
[ 9520.384610] The buggy address belongs to the object at ffff8800b7ada500
which belongs to the cache btrfs_free_space of size 72
[ 9520.385175] The buggy address is located 0 bytes inside of
72-byte region [ffff8800b7ada500, ffff8800b7ada548)
[ 9520.385691] The buggy address belongs to the page:
[ 9520.385957] page:ffffea0002deb680 count:1 mapcount:0 mapping:ffff880108a1d700 index:0x0 compound_mapcount: 0
[ 9520.388030] flags: 0x8100(slab|head)
[ 9520.388281] raw: 0000000000008100 ffffea0002deb608 ffffea0002728808 ffff880108a1d700
[ 9520.388722] raw: 0000000000000000 0000000000130013 00000001ffffffff 0000000000000000
[ 9520.389169] page dumped because: kasan: bad access detected
[ 9520.389473]
[ 9520.389658] Memory state around the buggy address:
[ 9520.389943] ffff8800b7ada400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 9520.390368] ffff8800b7ada480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 9520.390796] >ffff8800b7ada500: fb fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc
[ 9520.391223] ^
[ 9520.391461] ffff8800b7ada580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 9520.391885] ffff8800b7ada600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 9520.392313] ==================================================================
[ 9520.392772] BTRFS critical (device vdc): entry offset 2258497536, bytes 131072, bitmap no
[ 9520.393247] BUG: unable to handle kernel NULL pointer dereference at 0000000000000011
[ 9520.393705] PGD 800000010dbab067 P4D 800000010dbab067 PUD 107551067 PMD 0
[ 9520.394059] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
[ 9520.394378] CPU: 4 PID: 1721 Comm: btrfs-transacti Tainted: G B L 4.19.0-rc8-nbor #555
[ 9520.394858] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
[ 9520.395350] RIP: 0010:rb_next+0x3c/0x90
[ 9520.396461] RSP: 0018:ffff8801074ff780 EFLAGS: 00010292
[ 9520.396762] RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffffffff81b5ac4c
[ 9520.397115] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 0000000000000011
[ 9520.397468] RBP: ffff8801074ff7a0 R08: ffffed0021d64ccc R09: ffffed0021d64ccc
[ 9520.397821] R10: 0000000000000001 R11: ffffed0021d64ccb R12: ffff8800b91e0000
[ 9520.398188] R13: ffff8800a3ceba48 R14: ffff8800b627bf80 R15: 0000000000020000
[ 9520.398555] FS: 0000000000000000(0000) GS:ffff88010eb00000(0000) knlGS:0000000000000000
[ 9520.399007] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 9520.399335] CR2: 0000000000000011 CR3: 0000000106b52000 CR4: 00000000000006a0
[ 9520.399679] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 9520.400023] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 9520.400400] Call Trace:
[ 9520.400648] btrfs_dump_free_space+0x146/0x160 [btrfs]
[ 9520.400974] dump_space_info+0x2cd/0x310 [btrfs]
[ 9520.401287] btrfs_reserve_extent+0x1ee/0x1f0 [btrfs]
[ 9520.401609] __btrfs_prealloc_file_range+0x1cc/0x620 [btrfs]
[ 9520.401952] ? btrfs_update_time+0x180/0x180 [btrfs]
[ 9520.402232] ? _raw_spin_unlock+0x27/0x40
[ 9520.402522] ? btrfs_alloc_data_chunk_ondemand+0x2c0/0x5c0 [btrfs]
[ 9520.402882] btrfs_prealloc_file_range_trans+0x23/0x30 [btrfs]
[ 9520.403261] cache_save_setup+0x42e/0x580 [btrfs]
[ 9520.403570] ? btrfs_check_data_free_space+0xd0/0xd0 [btrfs]
[ 9520.403871] ? lock_downgrade+0x2f0/0x2f0
[ 9520.404161] ? btrfs_write_dirty_block_groups+0x11f/0x6e0 [btrfs]
[ 9520.404481] ? kasan_check_read+0x11/0x20
[ 9520.404732] ? do_raw_spin_unlock+0xa8/0x140
[ 9520.405026] btrfs_write_dirty_block_groups+0x2af/0x6e0 [btrfs]
[ 9520.405375] ? btrfs_start_dirty_block_groups+0x870/0x870 [btrfs]
[ 9520.405694] ? do_raw_spin_unlock+0xa8/0x140
[ 9520.405958] ? _raw_spin_unlock+0x27/0x40
[ 9520.406243] ? btrfs_run_delayed_refs+0x1b8/0x230 [btrfs]
[ 9520.406574] commit_cowonly_roots+0x4b9/0x610 [btrfs]
[ 9520.406899] ? commit_fs_roots+0x350/0x350 [btrfs]
[ 9520.407253] ? btrfs_run_delayed_refs+0x1b8/0x230 [btrfs]
[ 9520.407589] btrfs_commit_transaction+0x5e5/0x10e0 [btrfs]
[ 9520.407925] ? btrfs_apply_pending_changes+0x90/0x90 [btrfs]
[ 9520.408262] ? start_transaction+0x168/0x6c0 [btrfs]
[ 9520.408582] transaction_kthread+0x21c/0x240 [btrfs]
[ 9520.408870] kthread+0x1d2/0x1f0
[ 9520.409138] ? btrfs_cleanup_transaction+0xb50/0xb50 [btrfs]
[ 9520.409440] ? kthread_park+0xb0/0xb0
[ 9520.409682] ret_from_fork+0x3a/0x50
[ 9520.410508] Dumping ftrace buffer:
[ 9520.410764] (ftrace buffer empty)
[ 9520.411007] CR2: 0000000000000011
[ 9520.411297] ---[ end trace 01a0863445cf360a ]---
[ 9520.411568] RIP: 0010:rb_next+0x3c/0x90
[ 9520.412644] RSP: 0018:ffff8801074ff780 EFLAGS: 00010292
[ 9520.412932] RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffffffff81b5ac4c
[ 9520.413274] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 0000000000000011
[ 9520.413616] RBP: ffff8801074ff7a0 R08: ffffed0021d64ccc R09: ffffed0021d64ccc
[ 9520.414007] R10: 0000000000000001 R11: ffffed0021d64ccb R12: ffff8800b91e0000
[ 9520.414349] R13: ffff8800a3ceba48 R14: ffff8800b627bf80 R15: 0000000000020000
[ 9520.416074] FS: 0000000000000000(0000) GS:ffff88010eb00000(0000) knlGS:0000000000000000
[ 9520.416536] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 9520.416848] CR2: 0000000000000011 CR3: 0000000106b52000 CR4: 00000000000006a0
[ 9520.418477] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 9520.418846] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 9520.419204] Kernel panic - not syncing: Fatal exception
[ 9520.419666] Dumping ftrace buffer:
[ 9520.419930] (ftrace buffer empty)
[ 9520.420168] Kernel Offset: disabled
[ 9520.420406] ---[ end Kernel panic - not syncing: Fatal exception ]---Fix this by acquiring the respective lock before iterating the rbtree.
--- fs/btrfs/free-space-cache.c | 2 ++ 1 file changed, 2 insertions(+)
fs/btrfs/free-space-cache.c +2 -0
@@ -2482,6 +2482,7 @@ void btrfs_dump_free_space(struct btrfs_struct rb_node *n;int count =0 ; +spin_lock (&ctl->tree_lock);for (n =rb_first (&ctl->free_space_offset); n; n =rb_next (n)) { info = rb_entry(n, struct btrfs_free_space, offset_index);if (info->bytes >= bytes && !block_group->ro)
@@ -2490,6 +2491,7 @@ void btrfs_dump_free_space(struct btrfs_ info->offset, info->bytes, (info->bitmap) ? "yes" : "no"); } +spin_unlock (&ctl->tree_lock);btrfs_info (fs_info,"block group has cluster?: %s" ,list_empty (&block_group->cluster_list) ?"no" :"yes" ); btrfs_info(fs_info,
Greg Kroah-Hartman
maintainerPATCH 220/222 Btrfs: fix fsync after hole punching when using no-holes feature
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <[email protected]>
commit 4ee3fad34a9cc2cf33303dfbd0cf554248651c86 upstream.
When we have the no-holes mode enabled and fsync a file after punching a hole in it, we can end up not logging the whole hole range in the log tree. This happens if the file has extent items that span more than one leaf and we punch a hole that covers a range that starts in a leaf but does not go beyond the offset of the first extent in the next leaf.
Example:
$ mkfs.btrfs -f -O no-holes -n 65536 /dev/sdb
$ mount /dev/sdb /mnt
$ for ((i = 0; i <= 831; i++)); do
offset=$((i * 2 * 256 * 1024))
xfs_io -f -c "pwrite -S 0xab -b 256K $offset 256K" \
/mnt/foobar >/dev/null
done
$ sync# We now have 2 leafs in our filesystem fs tree, the first leaf has an
# item corresponding the extent at file offset 216530944 and the second # leaf has a first item corresponding to the extent at offset 217055232. # Now we punch a hole that partially covers the range of the extent at # offset 216530944 but does go beyond the offset 217055232.
$ xfs_io -c "fpunch $((216530944 + 128 * 1024 - 4000)) 256K" /mnt/foobar $ xfs_io -c "fsync" /mnt/foobar
<power fail>
# mount to replay the log $ mount /dev/sdb /mnt
# Before this patch, only the subrange [216658016, 216662016[ (length of # 4000 bytes) was logged, leaving an incorrect file layout after log
# replay.
Fix this by checking if there is a hole between the last extent item that we processed and the first extent item in the next leaf, and if there is one, log an explicit hole extent item.
--- fs/btrfs/tree-log.c | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)
fs/btrfs/tree-log.c +30 -0
@@ -3978,6 +3978,36 @@ fill_holes:break ; *last_extent = extent_end; } + +/* +* Check if there is a hole between the last extent found in our leaf +* and the first extent in the next leaf. If there is one, we need to +* log an explicit hole so that at replay time we can punch the hole. +*/ +if (ret ==0 && + key.objectid ==btrfs_ino (inode) && + key.type ==BTRFS_EXTENT_DATA_KEY && + i ==btrfs_header_nritems (src_path->nodes[0 ])) { + ret =btrfs_next_leaf (inode->root, src_path); + need_find_last_extent = true; +if (ret >0 ) { + ret =0 ; + }else if (ret ==0 ) { +btrfs_item_key_to_cpu (src_path->nodes[0 ], &key, + src_path->slots[0 ]); +if (key.objectid ==btrfs_ino (inode) && + key.type ==BTRFS_EXTENT_DATA_KEY && + *last_extent < key.offset) { +const u64 len = key.offset - *last_extent; + + ret =btrfs_insert_file_extent (trans, log, +btrfs_ino (inode), + *last_extent,0 , +0 , len,0 , len, +0 ,0 ,0 ); + } + } + }/* * Need to let the callers know we dropped the path so they should * re-search.
Greg Kroah-Hartman
maintainerPATCH 221/222 net: sched: Remove TCA_OPTIONS from policy
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Ahern <[email protected]>
commit e72bde6b66299602087c8c2350d36a525e75d06e upstream.
Marco reported an error with hfsc:
root@Calimero:~# tc qdisc add dev eth0 root handle 1:0 hfsc default 1 Error: Attribute failed policy validation.
Apparently a few implementations pass TCA_OPTIONS as a binary instead of nested attribute, so drop TCA_OPTIONS from the policy.
--- net/sched/sch_api.c | 1 - 1 file changed, 1 deletion(-)
net/sched/sch_api.c +0 -1
@@ -1218,7 +1218,6 @@ check_loop_fn(struct Qdisc *q, unsignedconst struct nla_policy rtm_tca_policy[TCA_MAX +1 ] = { [TCA_KIND ] = { .type =NLA_STRING }, - [TCA_OPTIONS ] = { .type =NLA_NESTED }, [TCA_RATE ] = { .type =NLA_BINARY , .len =sizeof (struct tc_estimator ) }, [TCA_STAB ] = { .type =NLA_NESTED },
Greg Kroah-Hartman
maintainerPATCH 222/222 bpf: wait for running BPF programs when updating map-in-map
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Colascione <[email protected]>
commit 1ae80cf31938c8f77c37a29bbe29e7f1cd492be8 upstream.
The map-in-map frequently serves as a mechanism for atomic snapshotting of state that a BPF program might record. The current implementation is dangerous to use in this way, however, since userspace has no way of knowing when all programs that might have retrieved the "old" value of the map may have completed.
This change ensures that map update operations on map-in-map map types always wait for all references to the old map to drop before returning to userspace.
--- kernel/bpf/syscall.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
kernel/bpf/syscall.c +13 -0
@@ -519,6 +519,17 @@ err_put:return err; } +static void maybe_wait_bpf_programs (struct bpf_map *map) +{ +/* Wait for any running BPF programs to complete so that +* userspace, when we return to it, knows that all programs +* that could be running use the new map value. +*/ +if (map->map_type ==BPF_MAP_TYPE_HASH_OF_MAPS || + map->map_type ==BPF_MAP_TYPE_ARRAY_OF_MAPS ) +synchronize_rcu (); +} +#define BPF_MAP_UPDATE_ELEM_LAST_FIELD flagsstatic int map_update_elem (union bpf_attr *attr)
@@ -592,6 +603,7 @@ static int map_update_elem(union bpf_att }__this_cpu_dec (bpf_prog_active);preempt_enable (); +maybe_wait_bpf_programs (map);if (!err)trace_bpf_map_update_elem (map, ufd, key, value);
@@ -636,6 +648,7 @@ static int map_delete_elem(union bpf_attrcu_read_unlock ();__this_cpu_dec (bpf_prog_active);preempt_enable (); +maybe_wait_bpf_programs (map);if (!err)trace_bpf_map_delete_elem (map, ufd, key);
stable-rc/linux-4.14.y boot: 94 boots: 4 failed, 66 passed with 16 offline, 8 conflicts (v4.14.80-223-gaa871c61a152)
stable-rc/linux-4.14.y boot: 94 boots: 4 failed, 66 passed with 16 offline, 8 conflicts (v4.14.80-223-gaa871c61a152)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.14.80-223-gaa871c61a152/
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.80-223-gaa871c61a152/
Tree: stable-rc
Branch: linux-4.14.y
Git Describe: v4.14.80-223-gaa871c61a152
Git Commit: aa871c61a15249c475462be9156df7a359395ecf
Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 54 unique boards, 21 SoC families, 15 builds out of 185
Boot Regressions Detected:
arm:
bcm2835_defconfig:
bcm2837-rpi-3-b:
lab-baylibre: failing since 1 day (last pass: v4.14.79-32-g24f453c41e18 - first fail: v4.14.80)
multi_v7_defconfig:
imx6q-sabrelite:
lab-baylibre: failing since 1 day (last pass: v4.14.79 - first fail: v4.14.80)
meson8b-odroidc1:
lab-baylibre: failing since 1 day (last pass: v4.14.79 - first fail: v4.14.80)
qemu:
lab-baylibre: failing since 1 day (last pass: v4.14.79 - first fail: v4.14.80)
vexpress_defconfig:
qemu:
lab-baylibre: failing since 1 day (last pass: v4.14.79 - first fail: v4.14.80)arm64:
defconfig:
bcm2837-rpi-3-b:
lab-baylibre: failing since 1 day (last pass: v4.14.79 - first fail: v4.14.80)
meson-gxbb-nanopi-k2:
lab-baylibre: failing since 1 day (last pass: v4.14.79 - first fail: v4.14.80)
meson-gxbb-p200:
lab-baylibre: failing since 1 day (last pass: v4.14.79 - first fail: v4.14.80)
meson-gxl-s905x-khadas-vim:
lab-baylibre: failing since 1 day (last pass: v4.14.79 - first fail: v4.14.80)
meson-gxl-s905x-libretech-cc:
lab-baylibre: failing since 1 day (last pass: v4.14.79 - first fail: v4.14.80)
qemu:
lab-baylibre: failing since 1 day (last pass: v4.14.79 - first fail: v4.14.80)x86:
x86_64_defconfig:
qemu:
lab-baylibre: failing since 1 day (last pass: v4.14.79-32-g24f453c41e18 - first fail: v4.14.80)Boot Failures Detected:
arm:
bcm2835_defconfig
bcm2837-rpi-3-b: 1 failed lab
multi_v7_defconfig
imx6q-sabrelite: 1 failed labarm64:
defconfig
meson-gxbb-nanopi-k2: 1 failed lab meson-gxl-s905x-libretech-cc: 1 failed lab
Offline Platforms:
arm:
omap2plus_defconfig:
am335x-boneblack: 1 offline lab
sunxi_defconfig:
sun5i-r8-chip: 1 offline lab
tegra_defconfig:
tegra124-jetson-tk1: 1 offline lab
bcm2835_defconfig:
bcm2835-rpi-b: 1 offline lab
sama5_defconfig:
at91-sama5d4_xplained: 1 offline lab
multi_v7_defconfig:
alpine-db: 1 offline lab
am335x-boneblack: 1 offline lab
at91-sama5d4_xplained: 1 offline lab socfpga_cyclone5_de0_sockit: 1 offline lab
sun5i-r8-chip: 1 offline lab
tegra124-jetson-tk1: 1 offline lab
arm64:
defconfig:
apq8016-sbc: 1 offline lab
juno-r2: 1 offline lab
meson-gxl-s905d-p230: 1 offline lab
meson-gxl-s905x-p212: 1 offline lab
mt7622-rfb1: 1 offline labConflicting Boot Failures Detected: (These likely are not failures as other labs are reporting PASS. Needs review.)
arm:
multi_v7_defconfig:
meson8b-odroidc1:
lab-baylibre: FAIL
lab-baylibre-seattle: PASS
qemu:
lab-baylibre: FAIL
lab-mhart: PASS
vexpress_defconfig:
qemu:
lab-baylibre: FAIL
lab-mhart: PASS
arm64:
defconfig:
meson-gxl-s905x-khadas-vim:
lab-baylibre: FAIL
lab-baylibre-seattle: PASS
qemu:
lab-baylibre: FAIL
lab-mhart: PASS
meson-gxbb-p200:
lab-baylibre: FAIL
lab-baylibre-seattle: PASS
bcm2837-rpi-3-b:
lab-baylibre: FAIL
lab-mhart: PASSx86:
x86_64_defconfig:
qemu:
lab-baylibre: FAIL
lab-mhart: PASS---
For more info write to <[email protected]>
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.81 release. There are 222 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue Nov 13 22:15:32 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.81-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Summary
------------------------------------------------------------------------
kernel: 4.14.81-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: 8ea94372bf0017762d8c4f9e2a53800304820e0e
git describe: v4.14.80-223-g8ea94372bf00
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.80-223-g8ea94372bf00
No regressions (compared to build v4.14.80)
Ran 21309 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64
Test Suites
-----------
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* ltp-containers-tests
* ltp-filecaps-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
--
Linaro LKFT
https://lkft.linaro.org
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.81 release. There are 222 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue Nov 13 22:15:32 UTC 2018. Anything received after that time might be too late.
Build results:
total: 150 pass: 150 fail: 0 Qemu test results: total: 293 pass: 293 fail: 0
Details are available at https://kerneltests.org/builders/.
Guenter
Jon Hunter
maintainerQuoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.81 release. There are 222 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue Nov 13 22:15:32 UTC 2018. Anything received after that time might be too late.
All tests are passing for Tegra ...
Test results for stable-v4.14:
8 builds: 8 pass, 0 fail
16 boots: 16 pass, 0 fail
14 tests: 14 pass, 0 failLinux version: 4.14.81-rc1-g8ea9437
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04
Cheers
Jon
Signature · 1 line
nvpublic
Greg Kroah-Hartman
maintainerQuoted 11 lines · Jon Hunter
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.81 release. There are 222 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue Nov 13 22:15:32 UTC 2018. Anything received after that time might be too late.
All tests are passing for Tegra ...
Quoted 9 lines
Test results for stable-v4.14:
8 builds: 8 pass, 0 fail 16 boots: 16 pass, 0 fail 14 tests: 14 pass, 0 failLinux version: 4.14.81-rc1-g8ea9437
Boards tested: tegra124-jetson-tk1, tegra20-ventana,tegra210-p2371-2180, tegra30-cardhu-a04
Thanks for testing and letting me know.
greg k-h