From patchwork Mon Dec 5 20:10:29 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Linus Torvalds X-Patchwork-Id: 9461475 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id DF9056022E for ; Mon, 5 Dec 2016 20:10:48 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D464127FAC for ; Mon, 5 Dec 2016 20:10:48 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id C8F4627FB1; Mon, 5 Dec 2016 20:10:48 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.3 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,RCVD_IN_SORBS_SPAM,T_DKIM_INVALID,T_TVD_MIME_EPI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 78FCD27FAC for ; Mon, 5 Dec 2016 20:10:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752255AbcLEUKd (ORCPT ); Mon, 5 Dec 2016 15:10:33 -0500 Received: from mail-io0-f196.google.com ([209.85.223.196]:36637 "EHLO mail-io0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751590AbcLEUKb (ORCPT ); Mon, 5 Dec 2016 15:10:31 -0500 Received: by mail-io0-f196.google.com with SMTP id s82so2185071ioi.3; Mon, 05 Dec 2016 12:10:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Mc80r7cfGSi6l6QPzuS/W6K11LDXKRJ8o3MCU13XEeQ=; b=ByufdOQyrDeYkfqAAuzzbpjIRzb6G5cE2u0xw0EEmtG3ur81SYtxIorvnHQs1KjwK9 LRNyf3isrcnnX8yASV2wHxdW5azR3ywWumoXS2FsoVIMVj9rLs/QhALAOa7TPD8a/Mff N28uUdeGazEBMqLei1C3T6V89NFHMmfjUdFwpzfz0ibLSsxttwPYSdg6Oa7SQzj2eOgR U+1ONfGaspRojjeOcnBjxlXbZjHI/ycTAAK/09QYEXV3ht9juPnWaFeeqv67mZjAYX6P HirCPPFFHo6gSunl3TRgbwbwXF6vWPRdVCJEKEqu49U9hi7ZEDetdbuVB1SSysJ3N4CV Wnyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Mc80r7cfGSi6l6QPzuS/W6K11LDXKRJ8o3MCU13XEeQ=; b=hDjTT5Zys1PJBAlBQApT/1EjRNoaBlOck0zVlbVGneEY0vj2As58gN0rM0SkdeVHWv flXil4g6bFHpalsWI2nfHBFaBeQicM/pqHw8jWLl6shWkRdWr1YFWAjFJIeWRaO3uoCr FnaOyVFvCUjgrJDNZOakdgIcUb04AXu2lguJSzi6b69SsE3461tPoXhxtIDJzdUhuuPW PLVOjfXVhPos3J3pWZbkVtuIALAa8g9kXDQhQVXRWqQ85lr/+tIWh+lXTUDJKer73nbN ePXY3ygz+YZo6aUYWB6AybSHA5yFVCweXVtIjHVLSZGKZ72j8dNjyMAYuglcUx4QDpT8 Qt0Q== X-Gm-Message-State: AKaTC02tT4nEgERvClTtlvXLoFxDM385lPoiyF3uu6RQAtnW3bT6BoexSHCXgW3fg42zUjgcHsvwfZFDuQNI+Q== X-Received: by 10.107.5.81 with SMTP id 78mr4416380iof.189.1480968630064; Mon, 05 Dec 2016 12:10:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.146.65 with HTTP; Mon, 5 Dec 2016 12:10:29 -0800 (PST) In-Reply-To: References: <2bdc068d-afd5-7a78-f334-26970c91aaca@fb.com> <203e0319-bc9b-245c-e162-709267540d22@fb.com> <20161026233808.GC15247@clm-mbp.thefacebook.com> <20161026234751.e66xyzjiwifvbuha@codemonkey.org.uk> <20161031185514.b22zvbxvga4xcinz@codemonkey.org.uk> <20161031194454.GA49877@clm-mbp.thefacebook.com> <20161123193419.pq7adje2eanky2wx@codemonkey.org.uk> <20161123195845.iphzr7ac4mu5ewjt@codemonkey.org.uk> From: Linus Torvalds Date: Mon, 5 Dec 2016 12:10:29 -0800 X-Google-Sender-Auth: owszg8D4CnsocFZvEzMkFCLV4RQ Message-ID: Subject: Re: bio linked list corruption. To: Vegard Nossum Cc: Dave Jones , Chris Mason , Jens Axboe , Andy Lutomirski , Andy Lutomirski , Al Viro , Josef Bacik , David Sterba , linux-btrfs , Linux Kernel , Dave Chinner Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Mon, Dec 5, 2016 at 11:11 AM, Vegard Nossum wrote: > > ------------[ cut here ]------------ > WARNING: CPU: 22 PID: 14012 at mm/shmem.c:2668 shmem_fallocate+0x9a7/0xac0 Ok, good. So that's confirmed as the cause of this problem. And the call chain that I wanted is obviously completely uninteresting, because it's call cghain on the other side (the page fault side) that would show the nested wake queue behavior. I was just being stupid about it. I wonder if we have any other places where we just blithely assume that "wake_up_all()" will actually empty the whole wait queue. It's _usually_ true, but as noted, nested waiting does happen. Anyway, can you try this patch instead? It should actually cause the wake_up_all() to always remove all entries, and thus the WARN_ON() should no longer happen (and I removed the "list_del()" hackery). Linus diff --git a/mm/shmem.c b/mm/shmem.c index 166ebf5d2bce..17beb44e9f4f 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -1848,6 +1848,19 @@ alloc_nohuge: page = shmem_alloc_and_acct_page(gfp, info, sbinfo, return error; } +/* + * This is like autoremove_wake_function, but it removes the wait queue + * entry unconditionally - even if something else had already woken the + * target. + */ +static int synchronous_wake_function(wait_queue_t *wait, unsigned mode, int sync, void *key) +{ + int ret = default_wake_function(wait, mode, sync, key); + list_del_init(&wait->task_list); + return ret; +} + + static int shmem_fault(struct vm_area_struct *vma, struct vm_fault *vmf) { struct inode *inode = file_inode(vma->vm_file); @@ -1883,7 +1896,7 @@ static int shmem_fault(struct vm_area_struct *vma, struct vm_fault *vmf) vmf->pgoff >= shmem_falloc->start && vmf->pgoff < shmem_falloc->next) { wait_queue_head_t *shmem_falloc_waitq; - DEFINE_WAIT(shmem_fault_wait); + DEFINE_WAIT_FUNC(shmem_fault_wait, synchronous_wake_function); ret = VM_FAULT_NOPAGE; if ((vmf->flags & FAULT_FLAG_ALLOW_RETRY) && @@ -2665,6 +2678,7 @@ static long shmem_fallocate(struct file *file, int mode, loff_t offset, spin_lock(&inode->i_lock); inode->i_private = NULL; wake_up_all(&shmem_falloc_waitq); + WARN_ON_ONCE(!list_empty(&shmem_falloc_waitq.task_list)); spin_unlock(&inode->i_lock); error = 0; goto out;