[{"id":1767814,"web_url":"http://patchwork.ozlabs.org/comment/1767814/","msgid":"<20170913115354.GA7756@jagdpanzerIV.localdomain>","date":"2017-09-13T11:53:54","subject":"Re: [PATCH v3 04/20] mm: VMA sequence count","submitter":{"id":67261,"url":"http://patchwork.ozlabs.org/api/people/67261/","name":"Sergey Senozhatsky","email":"sergey.senozhatsky.work@gmail.com"},"content":"Hi,\n\nOn (09/08/17 20:06), Laurent Dufour wrote:\n[..]\n> @@ -903,6 +910,7 @@ int __vma_adjust(struct vm_area_struct *vma, unsigned long start,\n> \t\tmm->map_count--;\n> \t\tmpol_put(vma_policy(next));\n> \t\tkmem_cache_free(vm_area_cachep, next);\n> +\t\twrite_seqcount_end(&next->vm_sequence);\n> \t\t/*\n> \t\t * In mprotect's case 6 (see comments on vma_merge),\n> \t\t * we must remove another next too. It would clutter\n> @@ -932,11 +940,14 @@ int __vma_adjust(struct vm_area_struct *vma, unsigned long start,\n> \t\tif (remove_next == 2) {\n> \t\t\tremove_next = 1;\n> \t\t\tend = next->vm_end;\n> +\t\t\twrite_seqcount_end(&vma->vm_sequence);\n> \t\t\tgoto again;\n> -\t\t}\n> -\t\telse if (next)\n> +\t\t} else if (next) {\n> +\t\t\tif (next != vma)\n> +\t\t\t\twrite_seqcount_begin_nested(&next->vm_sequence,\n> +\t\t\t\t\t\t\t SINGLE_DEPTH_NESTING);\n> \t\t\tvma_gap_update(next);\n> -\t\telse {\n> +\t\t} else {\n> \t\t\t/*\n> \t\t\t * If remove_next == 2 we obviously can't\n> \t\t\t * reach this path.\n> @@ -962,6 +973,10 @@ int __vma_adjust(struct vm_area_struct *vma, unsigned long start,\n> \tif (insert && file)\n> \t\tuprobe_mmap(insert);\n> \n> +\tif (next && next != vma)\n> +\t\twrite_seqcount_end(&next->vm_sequence);\n> +\twrite_seqcount_end(&vma->vm_sequence);\n\n\nok, so what I got on my box is:\n\nvm_munmap() -> down_write_killable(&mm->mmap_sem)\n do_munmap()\n __split_vma()\n __vma_adjust() -> write_seqcount_begin(&vma->vm_sequence)\n -> write_seqcount_begin_nested(&next->vm_sequence, SINGLE_DEPTH_NESTING)\n\nso this gives 3 dependencies ->mmap_sem -> ->vm_seq\n ->vm_seq -> ->vm_seq/1\n ->mmap_sem -> ->vm_seq/1\n\n\nSyS_mremap() -> down_write_killable(¤t->mm->mmap_sem)\n move_vma() -> write_seqcount_begin(&vma->vm_sequence)\n -> write_seqcount_begin_nested(&new_vma->vm_sequence, SINGLE_DEPTH_NESTING);\n move_page_tables()\n __pte_alloc()\n pte_alloc_one()\n __alloc_pages_nodemask()\n fs_reclaim_acquire()\n\n\nI think here we have prepare_alloc_pages() call, that does\n\n -> fs_reclaim_acquire(gfp_mask)\n -> fs_reclaim_release(gfp_mask)\n\nso that adds one more dependency ->mmap_sem -> ->vm_seq -> fs_reclaim\n ->mmap_sem -> ->vm_seq/1 -> fs_reclaim\n\n\nnow, under memory pressure we hit the slow path and perform direct\nreclaim. direct reclaim is done under fs_reclaim lock, so we end up\nwith the following call chain\n\n__alloc_pages_nodemask()\n __alloc_pages_slowpath()\n __perform_reclaim() -> fs_reclaim_acquire(gfp_mask);\n try_to_free_pages()\n shrink_node()\n shrink_active_list()\n rmap_walk_file() -> i_mmap_lock_read(mapping);\n\n\nand this break the existing dependency. since we now take the leaf lock\n(fs_reclaim) first and the the root lock (->mmap_sem).\n\n\nwell, seems to be the case.\n\n\t-ss","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xsg8t6kpwz9sNV\n\tfor ;\n\tWed, 13 Sep 2017 21:55:42 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xsg8t5ZTdzDr46\n\tfor ;\n\tWed, 13 Sep 2017 21:55:42 +1000 (AEST)","from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com\n\t[IPv6:2607:f8b0:400e:c00::22d])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3xsg6x35XfzDqjt\n\tfor ;\n\tWed, 13 Sep 2017 21:54:01 +1000 (AEST)","by mail-pf0-x22d.google.com with SMTP id e1so23064159pfk.1\n\tfor ;\n\tWed, 13 Sep 2017 04:54:01 -0700 (PDT)","from localhost ([39.7.47.223]) by smtp.gmail.com with ESMTPSA id\n\tj1sm23518346pfc.169.2017.09.13.04.53.57\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tWed, 13 Sep 2017 04:53:58 -0700 (PDT)"],"Authentication-Results":["ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"C4COhwWB\"; dkim-atps=neutral","lists.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"C4COhwWB\"; dkim-atps=neutral","ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=gmail.com\n\t(client-ip=2607:f8b0:400e:c00::22d; helo=mail-pf0-x22d.google.com;\n\tenvelope-from=sergey.senozhatsky.work@gmail.com; receiver=)","lists.ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"C4COhwWB\"; dkim-atps=neutral"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=NfLcEo1Ee4VsHishNMnggZ5cxqWkcufg7avyg0VT6Ns=;\n\tb=C4COhwWB4yOFBqNUGjMQ1QPjTqJzms06zQVW0XOJGppNV9DvCqjLMQgcWThOCPGsH5\n\tdGgqPtUhKAtmtI7vYXyHEmGM7DWO9/zte84hYfo0qeEDWRppbO2wPBPsmaVAgAFcb8XX\n\tsbUaIxL3e0X6p6RnLH5GNQ/CHhkZ4gfbgjCcBHfE1xolmev9HNGQSxZXTkOVKGQex7Sh\n\tQJJtCS2L/i3yfEfVU28RkOk7mZVD8ANJNL3s7F7ZPBszwOd5FGieGhYNUTimSkdlVZSP\n\tKINIrOeAUBoU8rvQCpccKENoCGs+9iNnNerhVauMfPICLKz3yLUWd3lXgjT2iFMZxRq7\n\t+InQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=NfLcEo1Ee4VsHishNMnggZ5cxqWkcufg7avyg0VT6Ns=;\n\tb=Qt+naMhx228tJypnXYZGKPTh9gGfUgpD7lsezOdWddCX0HgJtyhTfypf5HfTIeWzGc\n\tiTWiBRsJ9wx/7plWlLOX/KD4Q0UyrQ2Md6d638AF3fL4KMCBeZoqTwd+8vNOF1zkMOiy\n\tWuzJP3JG78LDuJZA3gJABoEUR75VSFJnzbZM6F+qpTJAsNCmT/1X8/auZ8XojiPh6eCB\n\tIyNDFSKFF2/h4zHO19nrdPvxOCpvLbS9E6M74M2NjZGlSN73tlw6n5rJwYZUlsUlyICy\n\t1KREWbr7n9o6M68laXj9QmWU0yhSLiVygnb8aQWj2EKqUrEN+N55+tdLYE38DpyxTCN4\n\tA3qA==","X-Gm-Message-State":"AHPjjUiaWiFocJ3CVS6JA5B0rQv8T4MnYZeGGcSjJ3aYa+06S6AVuL6l\n\tRw9SyCdwJfB4kA==","X-Google-Smtp-Source":"ADKCNb4zWw/QD/mWaElEvqcg6yGfnX9sAa+AcSPWEXaCKltT2B7p9Ahetni3OcvQYzBKnc1FQ0yHag==","X-Received":"by 10.99.121.129 with SMTP id\n\tu123mr18141947pgc.246.1505303638817; \n\tWed, 13 Sep 2017 04:53:58 -0700 (PDT)","Date":"Wed, 13 Sep 2017 20:53:54 +0900","From":"Sergey Senozhatsky ","To":"Laurent Dufour ","Subject":"Re: [PATCH v3 04/20] mm: VMA sequence count","Message-ID":"<20170913115354.GA7756@jagdpanzerIV.localdomain>","References":"<1504894024-2750-1-git-send-email-ldufour@linux.vnet.ibm.com>\n\t<1504894024-2750-5-git-send-email-ldufour@linux.vnet.ibm.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<1504894024-2750-5-git-send-email-ldufour@linux.vnet.ibm.com>","User-Agent":"Mutt/1.9.0 (2017-09-02)","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"jack@suse.cz, peterz@infradead.org, Will Deacon ,\n\tmhocko@kernel.org, linux-mm@kvack.org, paulus@samba.org, hpa@zytor.com,\n\tkhandual@linux.vnet.ibm.com, ak@linux.intel.com, x86@kernel.org,\n\tMatthew Wilcox , Ingo Molnar , \n\tpaulmck@linux.vnet.ibm.com, npiggin@gmail.com, dave@stgolabs.net,\n\tkirill@shutemov.name, Thomas Gleixner ,\n\tlinuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,\n\tSergey Senozhatsky ,\n\takpm@linux-foundation.org, \n\tTim Chen , haren@linux.vnet.ibm.com","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1768024,"web_url":"http://patchwork.ozlabs.org/comment/1768024/","msgid":"<44849c10-bc67-b55e-5788-d3c6bb5e7ad1@linux.vnet.ibm.com>","date":"2017-09-13T16:56:25","subject":"Re: [PATCH v3 04/20] mm: VMA sequence count","submitter":{"id":40248,"url":"http://patchwork.ozlabs.org/api/people/40248/","name":"Laurent Dufour","email":"ldufour@linux.vnet.ibm.com"},"content":"Hi Sergey,\n\nOn 13/09/2017 13:53, Sergey Senozhatsky wrote:\n> Hi,\n> \n> On (09/08/17 20:06), Laurent Dufour wrote:\n> [..]\n>> @@ -903,6 +910,7 @@ int __vma_adjust(struct vm_area_struct *vma, unsigned long start,\n>> \t\tmm->map_count--;\n>> \t\tmpol_put(vma_policy(next));\n>> \t\tkmem_cache_free(vm_area_cachep, next);\n>> +\t\twrite_seqcount_end(&next->vm_sequence);\n>> \t\t/*\n>> \t\t * In mprotect's case 6 (see comments on vma_merge),\n>> \t\t * we must remove another next too. It would clutter\n>> @@ -932,11 +940,14 @@ int __vma_adjust(struct vm_area_struct *vma, unsigned long start,\n>> \t\tif (remove_next == 2) {\n>> \t\t\tremove_next = 1;\n>> \t\t\tend = next->vm_end;\n>> +\t\t\twrite_seqcount_end(&vma->vm_sequence);\n>> \t\t\tgoto again;\n>> -\t\t}\n>> -\t\telse if (next)\n>> +\t\t} else if (next) {\n>> +\t\t\tif (next != vma)\n>> +\t\t\t\twrite_seqcount_begin_nested(&next->vm_sequence,\n>> +\t\t\t\t\t\t\t SINGLE_DEPTH_NESTING);\n>> \t\t\tvma_gap_update(next);\n>> -\t\telse {\n>> +\t\t} else {\n>> \t\t\t/*\n>> \t\t\t * If remove_next == 2 we obviously can't\n>> \t\t\t * reach this path.\n>> @@ -962,6 +973,10 @@ int __vma_adjust(struct vm_area_struct *vma, unsigned long start,\n>> \tif (insert && file)\n>> \t\tuprobe_mmap(insert);\n>> \n>> +\tif (next && next != vma)\n>> +\t\twrite_seqcount_end(&next->vm_sequence);\n>> +\twrite_seqcount_end(&vma->vm_sequence);\n> \n> \n> ok, so what I got on my box is:\n> \n> vm_munmap() -> down_write_killable(&mm->mmap_sem)\n> do_munmap()\n> __split_vma()\n> __vma_adjust() -> write_seqcount_begin(&vma->vm_sequence)\n> -> write_seqcount_begin_nested(&next->vm_sequence, SINGLE_DEPTH_NESTING)\n> \n> so this gives 3 dependencies ->mmap_sem -> ->vm_seq\n> ->vm_seq -> ->vm_seq/1\n> ->mmap_sem -> ->vm_seq/1\n> \n> \n> SyS_mremap() -> down_write_killable(¤t->mm->mmap_sem)\n> move_vma() -> write_seqcount_begin(&vma->vm_sequence)\n> -> write_seqcount_begin_nested(&new_vma->vm_sequence, SINGLE_DEPTH_NESTING);\n> move_page_tables()\n> __pte_alloc()\n> pte_alloc_one()\n> __alloc_pages_nodemask()\n> fs_reclaim_acquire()\n> \n> \n> I think here we have prepare_alloc_pages() call, that does\n> \n> -> fs_reclaim_acquire(gfp_mask)\n> -> fs_reclaim_release(gfp_mask)\n> \n> so that adds one more dependency ->mmap_sem -> ->vm_seq -> fs_reclaim\n> ->mmap_sem -> ->vm_seq/1 -> fs_reclaim\n> \n> \n> now, under memory pressure we hit the slow path and perform direct\n> reclaim. direct reclaim is done under fs_reclaim lock, so we end up\n> with the following call chain\n> \n> __alloc_pages_nodemask()\n> __alloc_pages_slowpath()\n> __perform_reclaim() -> fs_reclaim_acquire(gfp_mask);\n> try_to_free_pages()\n> shrink_node()\n> shrink_active_list()\n> rmap_walk_file() -> i_mmap_lock_read(mapping);\n> \n> \n> and this break the existing dependency. since we now take the leaf lock\n> (fs_reclaim) first and the the root lock (->mmap_sem).\n\nThanks for looking at this.\nI'm sorry, I should have miss something.\n\nMy understanding is that there are 2 chains of locks:\n 1. from __vma_adjust() mmap_sem -> i_mmap_rwsem -> vm_seq\n 2. from move_vmap() mmap_sem -> vm_seq -> fs_reclaim\n 2. from __alloc_pages_nodemask() fs_reclaim -> i_mmap_rwsem\n\nSo the solution would be to have in __vma_adjust()\n mmap_sem -> vm_seq -> i_mmap_rwsem\n\nBut this will raised the following dependency from unmap_mapping_range()\nunmap_mapping_range() \t\t-> i_mmap_rwsem\n unmap_mapping_range_tree()\n unmap_mapping_range_vma()\n zap_page_range_single()\n unmap_single_vma()\n unmap_page_range()\t \t-> vm_seq\n\nAnd there is no way to get rid of it easily as in unmap_mapping_range()\nthere is no VMA identified yet.\n\nThat's being said I can't see any clear way to get lock dependency cleaned\nhere.\nFurthermore, this is not clear to me how a deadlock could happen as vm_seq\nis a sequence lock, and there is no way to get blocked here.\n\nCheers,\nLaurent.\n\n> \n> well, seems to be the case.\n> \n> \t-ss\n>","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xsnsT4PSmz9s9Y\n\tfor ;\n\tThu, 14 Sep 2017 02:57:49 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xsnsT3Y51zDrWX\n\tfor ;\n\tThu, 14 Sep 2017 02:57:49 +1000 (AEST)","from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com\n\t[148.163.156.1])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3xsnrB0N10zDrKj\n\tfor ;\n\tThu, 14 Sep 2017 02:56:41 +1000 (AEST)","from pps.filterd (m0098393.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv8DGthZL070161\n\tfor ; Wed, 13 Sep 2017 12:56:39 -0400","from e06smtp14.uk.ibm.com (e06smtp14.uk.ibm.com [195.75.94.110])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2cy58jk098-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Wed, 13 Sep 2017 12:56:38 -0400","from localhost\n\tby e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tWed, 13 Sep 2017 17:56:34 +0100","from b06cxnps4076.portsmouth.uk.ibm.com (9.149.109.198)\n\tby e06smtp14.uk.ibm.com (192.168.101.144) with IBM ESMTP SMTP\n\tGateway: Authorized Use Only! Violators will be prosecuted; \n\tWed, 13 Sep 2017 17:56:27 +0100","from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com\n\t[9.149.105.232])\n\tby b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v8DGuR7613041748; Wed, 13 Sep 2017 16:56:27 GMT","from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id CF1645203F;\n\tWed, 13 Sep 2017 16:51:34 +0100 (BST)","from [9.145.35.107] (unknown [9.145.35.107])\n\tby d06av21.portsmouth.uk.ibm.com (Postfix) with ESMTP id 0DAA752043; \n\tWed, 13 Sep 2017 16:51:32 +0100 (BST)"],"Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=linux.vnet.ibm.com\n\t(client-ip=148.163.156.1; helo=mx0a-001b2d01.pphosted.com;\n\tenvelope-from=ldufour@linux.vnet.ibm.com; receiver=)","From":"Laurent Dufour ","Subject":"Re: [PATCH v3 04/20] mm: VMA sequence count","To":"Sergey Senozhatsky ","References":"<1504894024-2750-1-git-send-email-ldufour@linux.vnet.ibm.com>\n\t<1504894024-2750-5-git-send-email-ldufour@linux.vnet.ibm.com>\n\t<20170913115354.GA7756@jagdpanzerIV.localdomain>","Date":"Wed, 13 Sep 2017 18:56:25 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<20170913115354.GA7756@jagdpanzerIV.localdomain>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-TM-AS-GCONF":"00","x-cbid":"17091316-0016-0000-0000-000004ECBA47","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17091316-0017-0000-0000-00002826D78B","Message-Id":"<44849c10-bc67-b55e-5788-d3c6bb5e7ad1@linux.vnet.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-13_05:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=2\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709130264","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"jack@suse.cz, peterz@infradead.org, Will Deacon ,\n\tmhocko@kernel.org, linux-mm@kvack.org, paulus@samba.org, hpa@zytor.com,\n\tkhandual@linux.vnet.ibm.com, ak@linux.intel.com, x86@kernel.org,\n\tMatthew Wilcox , Ingo Molnar , \n\tpaulmck@linux.vnet.ibm.com, npiggin@gmail.com, dave@stgolabs.net,\n\tkirill@shutemov.name, Thomas Gleixner ,\n\tlinuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,\n\tSergey Senozhatsky ,\n\takpm@linux-foundation.org, \n\tTim Chen , haren@linux.vnet.ibm.com","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1768257,"web_url":"http://patchwork.ozlabs.org/comment/1768257/","msgid":"<20170914003116.GA599@jagdpanzerIV.localdomain>","date":"2017-09-14T00:31:16","subject":"Re: [PATCH v3 04/20] mm: VMA sequence count","submitter":{"id":67261,"url":"http://patchwork.ozlabs.org/api/people/67261/","name":"Sergey Senozhatsky","email":"sergey.senozhatsky.work@gmail.com"},"content":"Hi,\n\nOn (09/13/17 18:56), Laurent Dufour wrote:\n> Hi Sergey,\n> \n> On 13/09/2017 13:53, Sergey Senozhatsky wrote:\n> > Hi,\n> > \n> > On (09/08/17 20:06), Laurent Dufour wrote:\n[..]\n> > ok, so what I got on my box is:\n> > \n> > vm_munmap() -> down_write_killable(&mm->mmap_sem)\n> > do_munmap()\n> > __split_vma()\n> > __vma_adjust() -> write_seqcount_begin(&vma->vm_sequence)\n> > -> write_seqcount_begin_nested(&next->vm_sequence, SINGLE_DEPTH_NESTING)\n> > \n> > so this gives 3 dependencies ->mmap_sem -> ->vm_seq\n> > ->vm_seq -> ->vm_seq/1\n> > ->mmap_sem -> ->vm_seq/1\n> > \n> > \n> > SyS_mremap() -> down_write_killable(¤t->mm->mmap_sem)\n> > move_vma() -> write_seqcount_begin(&vma->vm_sequence)\n> > -> write_seqcount_begin_nested(&new_vma->vm_sequence, SINGLE_DEPTH_NESTING);\n> > move_page_tables()\n> > __pte_alloc()\n> > pte_alloc_one()\n> > __alloc_pages_nodemask()\n> > fs_reclaim_acquire()\n> > \n> > \n> > I think here we have prepare_alloc_pages() call, that does\n> > \n> > -> fs_reclaim_acquire(gfp_mask)\n> > -> fs_reclaim_release(gfp_mask)\n> > \n> > so that adds one more dependency ->mmap_sem -> ->vm_seq -> fs_reclaim\n> > ->mmap_sem -> ->vm_seq/1 -> fs_reclaim\n> > \n> > \n> > now, under memory pressure we hit the slow path and perform direct\n> > reclaim. direct reclaim is done under fs_reclaim lock, so we end up\n> > with the following call chain\n> > \n> > __alloc_pages_nodemask()\n> > __alloc_pages_slowpath()\n> > __perform_reclaim() -> fs_reclaim_acquire(gfp_mask);\n> > try_to_free_pages()\n> > shrink_node()\n> > shrink_active_list()\n> > rmap_walk_file() -> i_mmap_lock_read(mapping);\n> > \n> > \n> > and this break the existing dependency. since we now take the leaf lock\n> > (fs_reclaim) first and the the root lock (->mmap_sem).\n> \n> Thanks for looking at this.\n> I'm sorry, I should have miss something.\n\nno prob :)\n\n\n> My understanding is that there are 2 chains of locks:\n> 1. from __vma_adjust() mmap_sem -> i_mmap_rwsem -> vm_seq\n> 2. from move_vmap() mmap_sem -> vm_seq -> fs_reclaim\n> 2. from __alloc_pages_nodemask() fs_reclaim -> i_mmap_rwsem\n\nyes, as far as lockdep warning suggests.\n\n> So the solution would be to have in __vma_adjust()\n> mmap_sem -> vm_seq -> i_mmap_rwsem\n> \n> But this will raised the following dependency from unmap_mapping_range()\n> unmap_mapping_range() \t\t-> i_mmap_rwsem\n> unmap_mapping_range_tree()\n> unmap_mapping_range_vma()\n> zap_page_range_single()\n> unmap_single_vma()\n> unmap_page_range()\t \t-> vm_seq\n> \n> And there is no way to get rid of it easily as in unmap_mapping_range()\n> there is no VMA identified yet.\n> \n> That's being said I can't see any clear way to get lock dependency cleaned\n> here.\n> Furthermore, this is not clear to me how a deadlock could happen as vm_seq\n> is a sequence lock, and there is no way to get blocked here.\n\nas far as I understand,\n seq locks can deadlock, technically. not on the write() side, but on\nthe read() side:\n\nread_seqcount_begin()\n raw_read_seqcount_begin()\n __read_seqcount_begin()\n\nand __read_seqcount_begin() spins for ever\n\n __read_seqcount_begin()\n {\n repeat:\n ret = READ_ONCE(s->sequence);\n if (unlikely(ret & 1)) {\n cpu_relax();\n goto repeat;\n }\n return ret;\n }\n\n\nso if there are two CPUs, one doing write_seqcount() and the other one\ndoing read_seqcount() then what can happen is something like this\n\n\tCPU0\t\t\t\t\tCPU1\n\n\t\t\t\t\t\tfs_reclaim_acquire()\n\twrite_seqcount_begin()\n\tfs_reclaim_acquire()\t\t\tread_seqcount_begin()\n\twrite_seqcount_end()\n\nCPU0 can't write_seqcount_end() because of fs_reclaim_acquire() from\nCPU1, CPU1 can't read_seqcount_begin() because CPU0 did write_seqcount_begin()\nand now waits for fs_reclaim_acquire(). makes sense?\n\n\t-ss","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xszyY0THvz9t2f\n\tfor ;\n\tThu, 14 Sep 2017 10:32:53 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xszyX6QxdzDqw8\n\tfor ;\n\tThu, 14 Sep 2017 10:32:52 +1000 (AEST)","from mail-pg0-x232.google.com (mail-pg0-x232.google.com\n\t[IPv6:2607:f8b0:400e:c05::232])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3xszwp2wFjzDqjS\n\tfor ;\n\tThu, 14 Sep 2017 10:31:22 +1000 (AEST)","by mail-pg0-x232.google.com with SMTP id j16so3396923pga.1\n\tfor ;\n\tWed, 13 Sep 2017 17:31:22 -0700 (PDT)","from localhost ([175.223.49.171]) by smtp.gmail.com with ESMTPSA id\n\ti12sm11124885pgr.21.2017.09.13.17.31.18\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tWed, 13 Sep 2017 17:31:19 -0700 (PDT)"],"Authentication-Results":["ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"LBSFEpdE\"; dkim-atps=neutral","lists.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"LBSFEpdE\"; dkim-atps=neutral","ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=gmail.com\n\t(client-ip=2607:f8b0:400e:c05::232; helo=mail-pg0-x232.google.com;\n\tenvelope-from=sergey.senozhatsky.work@gmail.com; receiver=)","lists.ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"LBSFEpdE\"; dkim-atps=neutral"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=DJnvZ9URjWgQHKkJ4v8IM5VMCpIwmidftoObCctUR0M=;\n\tb=LBSFEpdE7E5U4PyPSVnPb1bPfLPdI8+g85ZOQr85Bz9WZdlK1GcU78QkrBPfbBholn\n\tVz1hTVKCjiiSYTDoG2TyUvLxX3JLDkvwdnamZs3AxfVs/Pes57RNfFqy39nj9fUnyGMe\n\tHEhz2CVKTGnwyM3sPmro0JOA5jUohJJUowRMFnAn/WMv76Y4k6x4QfCXCLQErVd5ae1Q\n\tDKlCxtezTNSFp9oC8/kYKacGJQpVyV+tMR3CKk4gJap9cImWxC1D8KbpKL7EAT4NwKnx\n\t735vhdORGuxITHc3zJcpDu44jlnYmzSb+fj3u461q/cysekeLxgv41U+gDuW3EIFfuEf\n\tiV7A==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=DJnvZ9URjWgQHKkJ4v8IM5VMCpIwmidftoObCctUR0M=;\n\tb=Fl7ITni+C11GtLZV2C5Q4i8AdaVo55RHbV5rxW3Z9I1zxmwD+mI6NWdfOa9wptOsqz\n\t/exeNC3PWfG3RAm1/zTjo1L+GbSonBlB2Edv7fLiOmASmFSjrVRFO6F5EuhGxI6S573W\n\tJnkdP7RylG434AKjHty8zhptECiB/2TC+Af0w0PAJoZ4W57Z2qPYuV8QsRFnXy8SjH+j\n\tH1QzkUIXxz7gmxu9BbssQJPYfVZ/gxilueCCJf2xCWbAsnky7l0QGLnxYmW6IcSxRyEN\n\toMdnczy+6M952nn0cspQba/ufIeCFsgrpVUtjIIKez33rArtzn9rHaiwONcKJghJojfa\n\tEYmQ==","X-Gm-Message-State":"AHPjjUh59MXgzceUBZacR1p4NgWp8HgRM7BaXN9PgdpaqEh5FjD4uyTQ\n\t6v8lJoZdFmqJKQ==","X-Google-Smtp-Source":"ADKCNb4JYTQPBqaSj9Sb+qFsW0h2DtUkcHGAruXjxgp9OHW86LJkqVjSHULJA21eQ94lrsGCWRjL6Q==","X-Received":"by 10.84.138.193 with SMTP id 59mr23084495plp.128.1505349079802; \n\tWed, 13 Sep 2017 17:31:19 -0700 (PDT)","Date":"Thu, 14 Sep 2017 09:31:16 +0900","From":"Sergey Senozhatsky ","To":"Laurent Dufour ","Subject":"Re: [PATCH v3 04/20] mm: VMA sequence count","Message-ID":"<20170914003116.GA599@jagdpanzerIV.localdomain>","References":"<1504894024-2750-1-git-send-email-ldufour@linux.vnet.ibm.com>\n\t<1504894024-2750-5-git-send-email-ldufour@linux.vnet.ibm.com>\n\t<20170913115354.GA7756@jagdpanzerIV.localdomain>\n\t<44849c10-bc67-b55e-5788-d3c6bb5e7ad1@linux.vnet.ibm.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<44849c10-bc67-b55e-5788-d3c6bb5e7ad1@linux.vnet.ibm.com>","User-Agent":"Mutt/1.9.0 (2017-09-02)","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"jack@suse.cz, Sergey Senozhatsky ,\n\tpeterz@infradead.org, Will Deacon ,\n\tmhocko@kernel.org, linux-mm@kvack.org, paulus@samba.org, hpa@zytor.com,\n\tkhandual@linux.vnet.ibm.com, ak@linux.intel.com, x86@kernel.org,\n\tMatthew Wilcox , Ingo Molnar , \n\tpaulmck@linux.vnet.ibm.com, npiggin@gmail.com, dave@stgolabs.net,\n\tkirill@shutemov.name, Thomas Gleixner ,\n\tlinuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,\n\tSergey Senozhatsky ,\n\takpm@linux-foundation.org, \n\tTim Chen , haren@linux.vnet.ibm.com","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1768391,"web_url":"http://patchwork.ozlabs.org/comment/1768391/","msgid":"<441ff1c6-72a7-5d96-02c8-063578affb62@linux.vnet.ibm.com>","date":"2017-09-14T07:55:13","subject":"Re: [PATCH v3 04/20] mm: VMA sequence count","submitter":{"id":40248,"url":"http://patchwork.ozlabs.org/api/people/40248/","name":"Laurent Dufour","email":"ldufour@linux.vnet.ibm.com"},"content":"Hi,\n\nOn 14/09/2017 02:31, Sergey Senozhatsky wrote:\n> Hi,\n> \n> On (09/13/17 18:56), Laurent Dufour wrote:\n>> Hi Sergey,\n>>\n>> On 13/09/2017 13:53, Sergey Senozhatsky wrote:\n>>> Hi,\n>>>\n>>> On (09/08/17 20:06), Laurent Dufour wrote:\n> [..]\n>>> ok, so what I got on my box is:\n>>>\n>>> vm_munmap() -> down_write_killable(&mm->mmap_sem)\n>>> do_munmap()\n>>> __split_vma()\n>>> __vma_adjust() -> write_seqcount_begin(&vma->vm_sequence)\n>>> -> write_seqcount_begin_nested(&next->vm_sequence, SINGLE_DEPTH_NESTING)\n>>>\n>>> so this gives 3 dependencies ->mmap_sem -> ->vm_seq\n>>> ->vm_seq -> ->vm_seq/1\n>>> ->mmap_sem -> ->vm_seq/1\n>>>\n>>>\n>>> SyS_mremap() -> down_write_killable(¤t->mm->mmap_sem)\n>>> move_vma() -> write_seqcount_begin(&vma->vm_sequence)\n>>> -> write_seqcount_begin_nested(&new_vma->vm_sequence, SINGLE_DEPTH_NESTING);\n>>> move_page_tables()\n>>> __pte_alloc()\n>>> pte_alloc_one()\n>>> __alloc_pages_nodemask()\n>>> fs_reclaim_acquire()\n>>>\n>>>\n>>> I think here we have prepare_alloc_pages() call, that does\n>>>\n>>> -> fs_reclaim_acquire(gfp_mask)\n>>> -> fs_reclaim_release(gfp_mask)\n>>>\n>>> so that adds one more dependency ->mmap_sem -> ->vm_seq -> fs_reclaim\n>>> ->mmap_sem -> ->vm_seq/1 -> fs_reclaim\n>>>\n>>>\n>>> now, under memory pressure we hit the slow path and perform direct\n>>> reclaim. direct reclaim is done under fs_reclaim lock, so we end up\n>>> with the following call chain\n>>>\n>>> __alloc_pages_nodemask()\n>>> __alloc_pages_slowpath()\n>>> __perform_reclaim() -> fs_reclaim_acquire(gfp_mask);\n>>> try_to_free_pages()\n>>> shrink_node()\n>>> shrink_active_list()\n>>> rmap_walk_file() -> i_mmap_lock_read(mapping);\n>>>\n>>>\n>>> and this break the existing dependency. since we now take the leaf lock\n>>> (fs_reclaim) first and the the root lock (->mmap_sem).\n>>\n>> Thanks for looking at this.\n>> I'm sorry, I should have miss something.\n> \n> no prob :)\n> \n> \n>> My understanding is that there are 2 chains of locks:\n>> 1. from __vma_adjust() mmap_sem -> i_mmap_rwsem -> vm_seq\n>> 2. from move_vmap() mmap_sem -> vm_seq -> fs_reclaim\n>> 2. from __alloc_pages_nodemask() fs_reclaim -> i_mmap_rwsem\n> \n> yes, as far as lockdep warning suggests.\n> \n>> So the solution would be to have in __vma_adjust()\n>> mmap_sem -> vm_seq -> i_mmap_rwsem\n>>\n>> But this will raised the following dependency from unmap_mapping_range()\n>> unmap_mapping_range() \t\t-> i_mmap_rwsem\n>> unmap_mapping_range_tree()\n>> unmap_mapping_range_vma()\n>> zap_page_range_single()\n>> unmap_single_vma()\n>> unmap_page_range()\t \t-> vm_seq\n>>\n>> And there is no way to get rid of it easily as in unmap_mapping_range()\n>> there is no VMA identified yet.\n>>\n>> That's being said I can't see any clear way to get lock dependency cleaned\n>> here.\n>> Furthermore, this is not clear to me how a deadlock could happen as vm_seq\n>> is a sequence lock, and there is no way to get blocked here.\n> \n> as far as I understand,\n> seq locks can deadlock, technically. not on the write() side, but on\n> the read() side:\n> \n> read_seqcount_begin()\n> raw_read_seqcount_begin()\n> __read_seqcount_begin()\n> \n> and __read_seqcount_begin() spins for ever\n> \n> __read_seqcount_begin()\n> {\n> repeat:\n> ret = READ_ONCE(s->sequence);\n> if (unlikely(ret & 1)) {\n> cpu_relax();\n> goto repeat;\n> }\n> return ret;\n> }\n> \n> \n> so if there are two CPUs, one doing write_seqcount() and the other one\n> doing read_seqcount() then what can happen is something like this\n> \n> \tCPU0\t\t\t\t\tCPU1\n> \n> \t\t\t\t\t\tfs_reclaim_acquire()\n> \twrite_seqcount_begin()\n> \tfs_reclaim_acquire()\t\t\tread_seqcount_begin()\n> \twrite_seqcount_end()\n> \n> CPU0 can't write_seqcount_end() because of fs_reclaim_acquire() from\n> CPU1, CPU1 can't read_seqcount_begin() because CPU0 did write_seqcount_begin()\n> and now waits for fs_reclaim_acquire(). makes sense?\n\nYes, this makes sense.\n\nBut in the case of this series, there is no call to\n__read_seqcount_begin(), and the reader (the speculative page fault\nhandler), is just checking for (vm_seq & 1) and if this is true, simply\nexit the speculative path without waiting.\nSo there is no deadlock possibility.\n\nThe bad case would be to have 2 concurrent threads calling\nwrite_seqcount_begin() on the same VMA, leading a wrongly freed sequence\nlock but this can't happen because of the mmap_sem holding for write in\nsuch a case.\n\nCheers,\nLaurent.","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xt9ph1gQQz9sRm\n\tfor ;\n\tThu, 14 Sep 2017 17:56:44 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xt9pg74vszDrW6\n\tfor ;\n\tThu, 14 Sep 2017 17:56:43 +1000 (AEST)","from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com\n\t[148.163.158.5])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3xt9nF11d7zDrJg\n\tfor ;\n\tThu, 14 Sep 2017 17:55:28 +1000 (AEST)","from pps.filterd (m0098420.ppops.net [127.0.0.1])\n\tby mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv8E7riDN092428\n\tfor ; Thu, 14 Sep 2017 03:55:26 -0400","from e06smtp14.uk.ibm.com (e06smtp14.uk.ibm.com [195.75.94.110])\n\tby mx0b-001b2d01.pphosted.com with ESMTP id 2cygdudhgm-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Thu, 14 Sep 2017 03:55:25 -0400","from localhost\n\tby e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tThu, 14 Sep 2017 08:55:22 +0100","from b06cxnps4075.portsmouth.uk.ibm.com (9.149.109.197)\n\tby e06smtp14.uk.ibm.com (192.168.101.144) with IBM ESMTP SMTP\n\tGateway: Authorized Use Only! Violators will be prosecuted; \n\tThu, 14 Sep 2017 08:55:16 +0100","from d06av25.portsmouth.uk.ibm.com (d06av25.portsmouth.uk.ibm.com\n\t[9.149.105.61])\n\tby b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v8E7tFKd22151246; Thu, 14 Sep 2017 07:55:15 GMT","from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 5DEF011C04C;\n\tThu, 14 Sep 2017 08:51:26 +0100 (BST)","from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id A58DF11C04A;\n\tThu, 14 Sep 2017 08:51:24 +0100 (BST)","from [9.145.48.160] (unknown [9.145.48.160])\n\tby d06av25.portsmouth.uk.ibm.com (Postfix) with ESMTP;\n\tThu, 14 Sep 2017 08:51:24 +0100 (BST)"],"Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=linux.vnet.ibm.com\n\t(client-ip=148.163.158.5; helo=mx0a-001b2d01.pphosted.com;\n\tenvelope-from=ldufour@linux.vnet.ibm.com; receiver=)","Subject":"Re: [PATCH v3 04/20] mm: VMA sequence count","To":"Sergey Senozhatsky ","References":"<1504894024-2750-1-git-send-email-ldufour@linux.vnet.ibm.com>\n\t<1504894024-2750-5-git-send-email-ldufour@linux.vnet.ibm.com>\n\t<20170913115354.GA7756@jagdpanzerIV.localdomain>\n\t<44849c10-bc67-b55e-5788-d3c6bb5e7ad1@linux.vnet.ibm.com>\n\t<20170914003116.GA599@jagdpanzerIV.localdomain>","From":"Laurent Dufour ","Date":"Thu, 14 Sep 2017 09:55:13 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<20170914003116.GA599@jagdpanzerIV.localdomain>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-TM-AS-GCONF":"00","x-cbid":"17091407-0016-0000-0000-000004ECDF01","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17091407-0017-0000-0000-00002826FEAA","Message-Id":"<441ff1c6-72a7-5d96-02c8-063578affb62@linux.vnet.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-14_02:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=2\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709140118","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"jack@suse.cz, peterz@infradead.org, Will Deacon ,\n\tmhocko@kernel.org, linux-mm@kvack.org, paulus@samba.org, hpa@zytor.com,\n\tkhandual@linux.vnet.ibm.com, ak@linux.intel.com, x86@kernel.org,\n\tMatthew Wilcox , Ingo Molnar , \n\tpaulmck@linux.vnet.ibm.com, npiggin@gmail.com, dave@stgolabs.net,\n\tkirill@shutemov.name, Thomas Gleixner ,\n\tlinuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,\n\tSergey Senozhatsky ,\n\takpm@linux-foundation.org, \n\tTim Chen , haren@linux.vnet.ibm.com","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1768409,"web_url":"http://patchwork.ozlabs.org/comment/1768409/","msgid":"<20170914081358.GG599@jagdpanzerIV.localdomain>","date":"2017-09-14T08:13:58","subject":"Re: [PATCH v3 04/20] mm: VMA sequence count","submitter":{"id":67261,"url":"http://patchwork.ozlabs.org/api/people/67261/","name":"Sergey Senozhatsky","email":"sergey.senozhatsky.work@gmail.com"},"content":"Hi,\n\nOn (09/14/17 09:55), Laurent Dufour wrote:\n[..]\n> > so if there are two CPUs, one doing write_seqcount() and the other one\n> > doing read_seqcount() then what can happen is something like this\n> > \n> > \tCPU0\t\t\t\t\tCPU1\n> > \n> > \t\t\t\t\t\tfs_reclaim_acquire()\n> > \twrite_seqcount_begin()\n> > \tfs_reclaim_acquire()\t\t\tread_seqcount_begin()\n> > \twrite_seqcount_end()\n> > \n> > CPU0 can't write_seqcount_end() because of fs_reclaim_acquire() from\n> > CPU1, CPU1 can't read_seqcount_begin() because CPU0 did write_seqcount_begin()\n> > and now waits for fs_reclaim_acquire(). makes sense?\n> \n> Yes, this makes sense.\n> \n> But in the case of this series, there is no call to\n> __read_seqcount_begin(), and the reader (the speculative page fault\n> handler), is just checking for (vm_seq & 1) and if this is true, simply\n> exit the speculative path without waiting.\n> So there is no deadlock possibility.\n\nprobably lockdep just knows that those locks interleave at some\npoint.\n\n\nby the way, I think there is one path that can spin\n\nfind_vma_srcu()\n read_seqbegin()\n read_seqcount_begin()\n raw_read_seqcount_begin()\n __read_seqcount_begin()\n\n\t-ss","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xtBDY4bpFz9s7v\n\tfor ;\n\tThu, 14 Sep 2017 18:15:41 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xtBDY3LF6zDrJm\n\tfor ;\n\tThu, 14 Sep 2017 18:15:41 +1000 (AEST)","from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com\n\t[IPv6:2607:f8b0:400e:c00::22d])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3xtBBh6pf4zDqXp\n\tfor ;\n\tThu, 14 Sep 2017 18:14:04 +1000 (AEST)","by mail-pf0-x22d.google.com with SMTP id e1so3971671pfk.1\n\tfor ;\n\tThu, 14 Sep 2017 01:14:04 -0700 (PDT)","from localhost ([175.223.49.171]) by smtp.gmail.com with ESMTPSA id\n\tn12sm29644571pfb.131.2017.09.14.01.14.01\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tThu, 14 Sep 2017 01:14:01 -0700 (PDT)"],"Authentication-Results":["ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"FmbYViFR\"; dkim-atps=neutral","lists.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"FmbYViFR\"; dkim-atps=neutral","ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=gmail.com\n\t(client-ip=2607:f8b0:400e:c00::22d; helo=mail-pf0-x22d.google.com;\n\tenvelope-from=sergey.senozhatsky.work@gmail.com; receiver=)","lists.ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"FmbYViFR\"; dkim-atps=neutral"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=atuQJVmzZz2WmLBr+Neh159J3rpPIPtIeKvxpzabK5E=;\n\tb=FmbYViFRKeHnAZzehEoZbs494mS6gp8EONDg3Y4/qby0Gi9PL+4Cu6wlQLYk03bMoG\n\tKfXJhvzTV8u/zqo07FFKPPNXagEXPydfD0OxBXSIjYy8zmNW6mshbZ7r5nFzzYFVIFzI\n\tJ94/VXr3ypsZdWgU8uKeNRqPaKZ6AwN4PFlkzf5FGz88JSrUUnQLkqQWVpVU7ijq7+nn\n\t1fW0NM8PeLmPkUU2QQfqpFIi43xkNSZH3EldwqYAFiZiPfoJUA58yJFnbItIKwGlrsyl\n\tIFMXWCbTh7RgsHOaBJWjB1Hy9n7L4jPuYSBPBQLj91A1nlNWNmWylZyjhOu20KGpuPOf\n\tJfWg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=atuQJVmzZz2WmLBr+Neh159J3rpPIPtIeKvxpzabK5E=;\n\tb=eKHNmeCe8BGy7gRkqa7/E+r+bSbAJk9cI1QAPqB8YkCMHu86j2ZkgL3Mw1D2rgSF6R\n\tEp/DOSbYS15THevTCU5Tr1Z5Pyt483H48VL6j61V8Q/zgJsxWFnr4rkP/jPE8rMSQ9Os\n\tk+3idM1uTGvNZrytDzyTJ6Vgk6hlLNoA/M4wwMhlTcDAcOPjdDmpN8/K/geD6MHIKHhe\n\tuXiG17+Dg9TGBs2HQGAIohfIdLLZm+W11szykT+dug6IBl1dMAA7JE0HpHSURHwFuec7\n\tT7eWqgAdv1ueqZf6K84ahNz4Hfd+kPfYohrzfLQLCqkOS4CUAuZv1sIqwnsMG+jnQyS5\n\tNSAA==","X-Gm-Message-State":"AHPjjUiqNcLlbyYvt4IsEYNHfk4z1Z5IclxoHh1Qn44fJZ7PMem010R5\n\t+FC2NoQoQPs38g==","X-Google-Smtp-Source":"ADKCNb4Kz7bFesAqL3TTcxIcSsMNueu1kcOBFYKjnGWmJ3MY/yQTM1SUzv+Mp9tJKC5bj7moQnnH8Q==","X-Received":"by 10.84.252.130 with SMTP id y2mr22557138pll.68.1505376842971; \n\tThu, 14 Sep 2017 01:14:02 -0700 (PDT)","Date":"Thu, 14 Sep 2017 17:13:58 +0900","From":"Sergey Senozhatsky ","To":"Laurent Dufour ","Subject":"Re: [PATCH v3 04/20] mm: VMA sequence count","Message-ID":"<20170914081358.GG599@jagdpanzerIV.localdomain>","References":"<1504894024-2750-1-git-send-email-ldufour@linux.vnet.ibm.com>\n\t<1504894024-2750-5-git-send-email-ldufour@linux.vnet.ibm.com>\n\t<20170913115354.GA7756@jagdpanzerIV.localdomain>\n\t<44849c10-bc67-b55e-5788-d3c6bb5e7ad1@linux.vnet.ibm.com>\n\t<20170914003116.GA599@jagdpanzerIV.localdomain>\n\t<441ff1c6-72a7-5d96-02c8-063578affb62@linux.vnet.ibm.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<441ff1c6-72a7-5d96-02c8-063578affb62@linux.vnet.ibm.com>","User-Agent":"Mutt/1.9.0 (2017-09-02)","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"jack@suse.cz, Sergey Senozhatsky ,\n\tpeterz@infradead.org, Will Deacon ,\n\tmhocko@kernel.org, linux-mm@kvack.org, paulus@samba.org, hpa@zytor.com,\n\tkhandual@linux.vnet.ibm.com, ak@linux.intel.com, x86@kernel.org,\n\tMatthew Wilcox , Ingo Molnar , \n\tpaulmck@linux.vnet.ibm.com, npiggin@gmail.com, dave@stgolabs.net,\n\tkirill@shutemov.name, Thomas Gleixner ,\n\tlinuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,\n\tSergey Senozhatsky ,\n\takpm@linux-foundation.org, \n\tTim Chen , haren@linux.vnet.ibm.com","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1768427,"web_url":"http://patchwork.ozlabs.org/comment/1768427/","msgid":"<26fa0b71-4053-5af7-baa0-e5fff9babf41@linux.vnet.ibm.com>","date":"2017-09-14T08:58:16","subject":"Re: [PATCH v3 04/20] mm: VMA sequence count","submitter":{"id":40248,"url":"http://patchwork.ozlabs.org/api/people/40248/","name":"Laurent Dufour","email":"ldufour@linux.vnet.ibm.com"},"content":"On 14/09/2017 10:13, Sergey Senozhatsky wrote:\n> Hi,\n> \n> On (09/14/17 09:55), Laurent Dufour wrote:\n> [..]\n>>> so if there are two CPUs, one doing write_seqcount() and the other one\n>>> doing read_seqcount() then what can happen is something like this\n>>>\n>>> \tCPU0\t\t\t\t\tCPU1\n>>>\n>>> \t\t\t\t\t\tfs_reclaim_acquire()\n>>> \twrite_seqcount_begin()\n>>> \tfs_reclaim_acquire()\t\t\tread_seqcount_begin()\n>>> \twrite_seqcount_end()\n>>>\n>>> CPU0 can't write_seqcount_end() because of fs_reclaim_acquire() from\n>>> CPU1, CPU1 can't read_seqcount_begin() because CPU0 did write_seqcount_begin()\n>>> and now waits for fs_reclaim_acquire(). makes sense?\n>>\n>> Yes, this makes sense.\n>>\n>> But in the case of this series, there is no call to\n>> __read_seqcount_begin(), and the reader (the speculative page fault\n>> handler), is just checking for (vm_seq & 1) and if this is true, simply\n>> exit the speculative path without waiting.\n>> So there is no deadlock possibility.\n> \n> probably lockdep just knows that those locks interleave at some\n> point.\n> \n> \n> by the way, I think there is one path that can spin\n> \n> find_vma_srcu()\n> read_seqbegin()\n> read_seqcount_begin()\n> raw_read_seqcount_begin()\n> __read_seqcount_begin()\n\n\nThat's right, but here this is the sequence counter mm->mm_seq, not the\nvm_seq one.\n\nThis one is held to protect walking the VMA list \"locklessly\"...\n\nCheers,\nLaurent.","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xtCCH67g6z9sPt\n\tfor ;\n\tThu, 14 Sep 2017 18:59:39 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xtCCH52j2zDrYd\n\tfor ;\n\tThu, 14 Sep 2017 18:59:39 +1000 (AEST)","from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com\n\t[148.163.158.5])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3xtCB14H3pzDrFp\n\tfor ;\n\tThu, 14 Sep 2017 18:58:33 +1000 (AEST)","from pps.filterd (m0098421.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv8E8rtAq138890\n\tfor ; Thu, 14 Sep 2017 04:58:30 -0400","from e06smtp14.uk.ibm.com (e06smtp14.uk.ibm.com [195.75.94.110])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2cyp6rsuq3-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Thu, 14 Sep 2017 04:58:29 -0400","from localhost\n\tby e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tThu, 14 Sep 2017 09:58:27 +0100","from b06cxnps3074.portsmouth.uk.ibm.com (9.149.109.194)\n\tby e06smtp14.uk.ibm.com (192.168.101.144) with IBM ESMTP SMTP\n\tGateway: Authorized Use Only! Violators will be prosecuted; \n\tThu, 14 Sep 2017 09:58:19 +0100","from d06av25.portsmouth.uk.ibm.com (d06av25.portsmouth.uk.ibm.com\n\t[9.149.105.61])\n\tby b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v8E8wJVd19005552; Thu, 14 Sep 2017 08:58:19 GMT","from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id BE95611C04A;\n\tThu, 14 Sep 2017 09:54:29 +0100 (BST)","from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 1096B11C04C;\n\tThu, 14 Sep 2017 09:54:28 +0100 (BST)","from [9.145.48.160] (unknown [9.145.48.160])\n\tby d06av25.portsmouth.uk.ibm.com (Postfix) with ESMTP;\n\tThu, 14 Sep 2017 09:54:27 +0100 (BST)"],"Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=linux.vnet.ibm.com\n\t(client-ip=148.163.158.5; helo=mx0a-001b2d01.pphosted.com;\n\tenvelope-from=ldufour@linux.vnet.ibm.com; receiver=)","Subject":"Re: [PATCH v3 04/20] mm: VMA sequence count","To":"Sergey Senozhatsky ","References":"<1504894024-2750-1-git-send-email-ldufour@linux.vnet.ibm.com>\n\t<1504894024-2750-5-git-send-email-ldufour@linux.vnet.ibm.com>\n\t<20170913115354.GA7756@jagdpanzerIV.localdomain>\n\t<44849c10-bc67-b55e-5788-d3c6bb5e7ad1@linux.vnet.ibm.com>\n\t<20170914003116.GA599@jagdpanzerIV.localdomain>\n\t<441ff1c6-72a7-5d96-02c8-063578affb62@linux.vnet.ibm.com>\n\t<20170914081358.GG599@jagdpanzerIV.localdomain>","From":"Laurent Dufour ","Date":"Thu, 14 Sep 2017 10:58:16 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<20170914081358.GG599@jagdpanzerIV.localdomain>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-TM-AS-GCONF":"00","x-cbid":"17091408-0016-0000-0000-000004ECE36B","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17091408-0017-0000-0000-00002827036D","Message-Id":"<26fa0b71-4053-5af7-baa0-e5fff9babf41@linux.vnet.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-14_02:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=0\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709140134","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"jack@suse.cz, peterz@infradead.org, Will Deacon ,\n\tmhocko@kernel.org, linux-mm@kvack.org, paulus@samba.org, hpa@zytor.com,\n\tkhandual@linux.vnet.ibm.com, ak@linux.intel.com, x86@kernel.org,\n\tMatthew Wilcox , Ingo Molnar , \n\tpaulmck@linux.vnet.ibm.com, npiggin@gmail.com, dave@stgolabs.net,\n\tkirill@shutemov.name, Thomas Gleixner ,\n\tlinuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,\n\tSergey Senozhatsky ,\n\takpm@linux-foundation.org, \n\tTim Chen , haren@linux.vnet.ibm.com","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1768438,"web_url":"http://patchwork.ozlabs.org/comment/1768438/","msgid":"<20170914091101.GH599@jagdpanzerIV.localdomain>","date":"2017-09-14T09:11:01","subject":"Re: [PATCH v3 04/20] mm: VMA sequence count","submitter":{"id":67261,"url":"http://patchwork.ozlabs.org/api/people/67261/","name":"Sergey Senozhatsky","email":"sergey.senozhatsky.work@gmail.com"},"content":"On (09/14/17 10:58), Laurent Dufour wrote:\n[..]\n> That's right, but here this is the sequence counter mm->mm_seq, not the\n> vm_seq one.\n\nd'oh... you are right.\n\n\t-ss","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xtCVC6Bc6z9sBZ\n\tfor ;\n\tThu, 14 Sep 2017 19:12:35 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xtCVC4mQHzDrSM\n\tfor ;\n\tThu, 14 Sep 2017 19:12:35 +1000 (AEST)","from mail-pg0-x232.google.com (mail-pg0-x232.google.com\n\t[IPv6:2607:f8b0:400e:c05::232])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3xtCSW73bWzDrJg\n\tfor ;\n\tThu, 14 Sep 2017 19:11:07 +1000 (AEST)","by mail-pg0-x232.google.com with SMTP id j16so5228694pga.1\n\tfor ;\n\tThu, 14 Sep 2017 02:11:07 -0700 (PDT)","from localhost ([175.223.49.171]) by smtp.gmail.com with ESMTPSA id\n\tu66sm3862666pfd.33.2017.09.14.02.11.03\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tThu, 14 Sep 2017 02:11:04 -0700 (PDT)"],"Authentication-Results":["ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"NEPUh+tC\"; dkim-atps=neutral","lists.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"NEPUh+tC\"; dkim-atps=neutral","ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=gmail.com\n\t(client-ip=2607:f8b0:400e:c05::232; helo=mail-pg0-x232.google.com;\n\tenvelope-from=sergey.senozhatsky.work@gmail.com; receiver=)","lists.ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"NEPUh+tC\"; dkim-atps=neutral"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=VnJ7jICMCLMx7y8zDzRlpLPiu/KVr8SR2zTU/iO+Pt8=;\n\tb=NEPUh+tCDeuspgBoncv9zdqhB0He2OiCBJ3O7ZBH0UB8BFzjC0ltr781zPXvmhtNSw\n\tY92MKks9oDiaSnYPqscVQzawuYtuUOtOeV+S/ShlYx+XfJovvVSbLSQEnOzuZO3NMASo\n\tj01XloVjRmC/9pOD+7ZTM2Rf4mkG28aaJuBHuOp2bVTgZYoZAuT0Ho5mwWILLeb9fxat\n\tmZiQJmLaRIX0jV3AvUniaVpmtCTjxktCN2GhcWBhv7D0694rlpqJKo6u7y90lHnCqJDE\n\tXk2lJVegWvFoiPmXBe+QEs+dgwcgTEKQ8otB4azNlPF9biObKxWGHroRlfytP7t4Qsr6\n\tKwqw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=VnJ7jICMCLMx7y8zDzRlpLPiu/KVr8SR2zTU/iO+Pt8=;\n\tb=R5snz0iZNT4fVsoug6d3+k00lydo3xMJzo1UEgyTdcz5865HSS8K6RqJ/Cu4wb7b5z\n\tl459MS1bm/Tk0mgGxBdrVpfGartcf+u/2KZENPn/tXxDiGk1Hfm7C9lFMa1WCJxAZs6b\n\tGmTURy8HQ8mKVFoec8Y0ba2J96vAgtbX6TRYBxDnSNLB81VOxIp8f/waRlbWbzLl1Kbl\n\tiHYEaSFcnYgjfneX+eYJw7PQj5y7AekvzrqgdjjDU2eJp4IOFzq2CUqAs6QN/OhPAMa8\n\t1tanzQo7B5ftN6cTnnhdnD4M+nfIkBZnJWrVdB34wQvK/KAXpDv4+71+9DXGWDDivPbw\n\tVhwQ==","X-Gm-Message-State":"AHPjjUhqOO3mY9Y+1FJXw3q4LuEM/dGb4u+6XLmMW6drs2f6RsDjJQhu\n\tF1Yx9ioYuG7DiA==","X-Google-Smtp-Source":"ADKCNb7QlgpKoq05p3SIfzJ5Q4HrWX6x1vJQDyRw+fHohmGz2Vh4REyw82694Vg+OfERvGubjhQN6g==","X-Received":"by 10.98.57.18 with SMTP id g18mr20790563pfa.271.1505380265808; \n\tThu, 14 Sep 2017 02:11:05 -0700 (PDT)","Date":"Thu, 14 Sep 2017 18:11:01 +0900","From":"Sergey Senozhatsky ","To":"Laurent Dufour ","Subject":"Re: [PATCH v3 04/20] mm: VMA sequence count","Message-ID":"<20170914091101.GH599@jagdpanzerIV.localdomain>","References":"<1504894024-2750-1-git-send-email-ldufour@linux.vnet.ibm.com>\n\t<1504894024-2750-5-git-send-email-ldufour@linux.vnet.ibm.com>\n\t<20170913115354.GA7756@jagdpanzerIV.localdomain>\n\t<44849c10-bc67-b55e-5788-d3c6bb5e7ad1@linux.vnet.ibm.com>\n\t<20170914003116.GA599@jagdpanzerIV.localdomain>\n\t<441ff1c6-72a7-5d96-02c8-063578affb62@linux.vnet.ibm.com>\n\t<20170914081358.GG599@jagdpanzerIV.localdomain>\n\t<26fa0b71-4053-5af7-baa0-e5fff9babf41@linux.vnet.ibm.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<26fa0b71-4053-5af7-baa0-e5fff9babf41@linux.vnet.ibm.com>","User-Agent":"Mutt/1.9.0 (2017-09-02)","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"jack@suse.cz, Sergey Senozhatsky ,\n\tpeterz@infradead.org, Will Deacon ,\n\tmhocko@kernel.org, linux-mm@kvack.org, paulus@samba.org, hpa@zytor.com,\n\tkhandual@linux.vnet.ibm.com, ak@linux.intel.com, x86@kernel.org,\n\tMatthew Wilcox , Ingo Molnar , \n\tpaulmck@linux.vnet.ibm.com, npiggin@gmail.com, dave@stgolabs.net,\n\tkirill@shutemov.name, Thomas Gleixner ,\n\tlinuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,\n\tSergey Senozhatsky ,\n\takpm@linux-foundation.org, \n\tTim Chen , haren@linux.vnet.ibm.com","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1768443,"web_url":"http://patchwork.ozlabs.org/comment/1768443/","msgid":"<9605ce43-0f61-48d7-88e2-88220b773494@linux.vnet.ibm.com>","date":"2017-09-14T09:15:27","subject":"Re: [PATCH v3 04/20] mm: VMA sequence count","submitter":{"id":40248,"url":"http://patchwork.ozlabs.org/api/people/40248/","name":"Laurent Dufour","email":"ldufour@linux.vnet.ibm.com"},"content":"On 14/09/2017 11:11, Sergey Senozhatsky wrote:\n> On (09/14/17 10:58), Laurent Dufour wrote:\n> [..]\n>> That's right, but here this is the sequence counter mm->mm_seq, not the\n>> vm_seq one.\n> \n> d'oh... you are right.\n\nSo I'm doubting about the probability of a deadlock here, but I don't like\nto see lockdep complaining. Is there an easy way to make it happy ?","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xtCbl0vRpz9sRW\n\tfor ;\n\tThu, 14 Sep 2017 19:17:23 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xtCbk72MmzDqhL\n\tfor ;\n\tThu, 14 Sep 2017 19:17:22 +1000 (AEST)","from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com\n\t[148.163.158.5])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3xtCYp15n8zDrJg\n\tfor ;\n\tThu, 14 Sep 2017 19:15:41 +1000 (AEST)","from pps.filterd (m0098413.ppops.net [127.0.0.1])\n\tby mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv8E9Est3108152\n\tfor ; Thu, 14 Sep 2017 05:15:39 -0400","from e06smtp12.uk.ibm.com (e06smtp12.uk.ibm.com [195.75.94.108])\n\tby mx0b-001b2d01.pphosted.com with ESMTP id 2cypskgs8b-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Thu, 14 Sep 2017 05:15:39 -0400","from localhost\n\tby e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tThu, 14 Sep 2017 10:15:36 +0100","from b06cxnps4074.portsmouth.uk.ibm.com (9.149.109.196)\n\tby e06smtp12.uk.ibm.com (192.168.101.142) with IBM ESMTP SMTP\n\tGateway: Authorized Use Only! Violators will be prosecuted; \n\tThu, 14 Sep 2017 10:15:30 +0100","from d06av25.portsmouth.uk.ibm.com (d06av25.portsmouth.uk.ibm.com\n\t[9.149.105.61])\n\tby b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v8E9FUMS27459590; Thu, 14 Sep 2017 09:15:30 GMT","from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id BA72B11C04C;\n\tThu, 14 Sep 2017 10:11:40 +0100 (BST)","from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 1057811C04A;\n\tThu, 14 Sep 2017 10:11:39 +0100 (BST)","from [9.145.48.160] (unknown [9.145.48.160])\n\tby d06av25.portsmouth.uk.ibm.com (Postfix) with ESMTP;\n\tThu, 14 Sep 2017 10:11:38 +0100 (BST)"],"Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=linux.vnet.ibm.com\n\t(client-ip=148.163.158.5; helo=mx0a-001b2d01.pphosted.com;\n\tenvelope-from=ldufour@linux.vnet.ibm.com; receiver=)","Subject":"Re: [PATCH v3 04/20] mm: VMA sequence count","To":"Sergey Senozhatsky ","References":"<1504894024-2750-1-git-send-email-ldufour@linux.vnet.ibm.com>\n\t<1504894024-2750-5-git-send-email-ldufour@linux.vnet.ibm.com>\n\t<20170913115354.GA7756@jagdpanzerIV.localdomain>\n\t<44849c10-bc67-b55e-5788-d3c6bb5e7ad1@linux.vnet.ibm.com>\n\t<20170914003116.GA599@jagdpanzerIV.localdomain>\n\t<441ff1c6-72a7-5d96-02c8-063578affb62@linux.vnet.ibm.com>\n\t<20170914081358.GG599@jagdpanzerIV.localdomain>\n\t<26fa0b71-4053-5af7-baa0-e5fff9babf41@linux.vnet.ibm.com>\n\t<20170914091101.GH599@jagdpanzerIV.localdomain>","From":"Laurent Dufour ","Date":"Thu, 14 Sep 2017 11:15:27 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<20170914091101.GH599@jagdpanzerIV.localdomain>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-TM-AS-GCONF":"00","x-cbid":"17091409-0008-0000-0000-00000496E233","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17091409-0009-0000-0000-00001E28012A","Message-Id":"<9605ce43-0f61-48d7-88e2-88220b773494@linux.vnet.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-14_02:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=0\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709140137","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"jack@suse.cz, peterz@infradead.org, Will Deacon ,\n\tmhocko@kernel.org, linux-mm@kvack.org, paulus@samba.org, hpa@zytor.com,\n\tkhandual@linux.vnet.ibm.com, ak@linux.intel.com, x86@kernel.org,\n\tMatthew Wilcox , Ingo Molnar , \n\tpaulmck@linux.vnet.ibm.com, npiggin@gmail.com, dave@stgolabs.net,\n\tkirill@shutemov.name, Thomas Gleixner ,\n\tlinuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,\n\tSergey Senozhatsky ,\n\takpm@linux-foundation.org, \n\tTim Chen , haren@linux.vnet.ibm.com","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1768471,"web_url":"http://patchwork.ozlabs.org/comment/1768471/","msgid":"<20170914094043.GJ599@jagdpanzerIV.localdomain>","date":"2017-09-14T09:40:43","subject":"Re: [PATCH v3 04/20] mm: VMA sequence count","submitter":{"id":67261,"url":"http://patchwork.ozlabs.org/api/people/67261/","name":"Sergey Senozhatsky","email":"sergey.senozhatsky.work@gmail.com"},"content":"On (09/14/17 11:15), Laurent Dufour wrote:\n> On 14/09/2017 11:11, Sergey Senozhatsky wrote:\n> > On (09/14/17 10:58), Laurent Dufour wrote:\n> > [..]\n> >> That's right, but here this is the sequence counter mm->mm_seq, not the\n> >> vm_seq one.\n> > \n> > d'oh... you are right.\n> \n> So I'm doubting about the probability of a deadlock here, but I don't like\n> to see lockdep complaining. Is there an easy way to make it happy ?\n\n\n /*\n * well... answering your question - it seems raw versions of seqcount\n * functions don't call lockdep's lock_acquire/lock_release...\n *\n * but I have never told you that. never.\n */\n\n\nlockdep, perhaps, can be wrong sometimes, and may be it's one of those\ncases. may be not... I'm not a MM guy myself.\n\nbelow is a lockdep splat I got yesterday. that's v3 of SPF patch set.\n\n\n[ 2763.365898] ======================================================\n[ 2763.365899] WARNING: possible circular locking dependency detected\n[ 2763.365902] 4.13.0-next-20170913-dbg-00039-ge3c06ea4b028-dirty #1837 Not tainted\n[ 2763.365903] ------------------------------------------------------\n[ 2763.365905] khugepaged/42 is trying to acquire lock:\n[ 2763.365906] (&mapping->i_mmap_rwsem){++++}, at: [] rmap_walk_file+0x5a/0x142\n[ 2763.365913] \n but task is already holding lock:\n[ 2763.365915] (fs_reclaim){+.+.}, at: [] fs_reclaim_acquire+0x12/0x35\n[ 2763.365920] \n which lock already depends on the new lock.\n\n[ 2763.365922] \n the existing dependency chain (in reverse order) is:\n[ 2763.365924] \n -> #3 (fs_reclaim){+.+.}:\n[ 2763.365930] lock_acquire+0x176/0x19e\n[ 2763.365932] fs_reclaim_acquire+0x32/0x35\n[ 2763.365934] __alloc_pages_nodemask+0x6d/0x1f9\n[ 2763.365937] pte_alloc_one+0x17/0x62\n[ 2763.365940] __pte_alloc+0x1f/0x83\n[ 2763.365943] move_page_tables+0x2c3/0x5a2\n[ 2763.365944] move_vma.isra.25+0xff/0x29f\n[ 2763.365946] SyS_mremap+0x41b/0x49e\n[ 2763.365949] entry_SYSCALL_64_fastpath+0x18/0xad\n[ 2763.365951] \n -> #2 (&vma->vm_sequence/1){+.+.}:\n[ 2763.365955] lock_acquire+0x176/0x19e\n[ 2763.365958] write_seqcount_begin_nested+0x1b/0x1d\n[ 2763.365959] __vma_adjust+0x1c4/0x5f1\n[ 2763.365961] __split_vma+0x12c/0x181\n[ 2763.365963] do_munmap+0x128/0x2af\n[ 2763.365965] vm_munmap+0x5a/0x73\n[ 2763.365968] elf_map+0xb1/0xce\n[ 2763.365970] load_elf_binary+0x91e/0x137a\n[ 2763.365973] search_binary_handler+0x70/0x1f3\n[ 2763.365974] do_execveat_common+0x45e/0x68e\n[ 2763.365978] call_usermodehelper_exec_async+0xf7/0x11f\n[ 2763.365980] ret_from_fork+0x27/0x40\n[ 2763.365981] \n -> #1 (&vma->vm_sequence){+.+.}:\n[ 2763.365985] lock_acquire+0x176/0x19e\n[ 2763.365987] write_seqcount_begin_nested+0x1b/0x1d\n[ 2763.365989] __vma_adjust+0x1a9/0x5f1\n[ 2763.365991] __split_vma+0x12c/0x181\n[ 2763.365993] do_munmap+0x128/0x2af\n[ 2763.365994] vm_munmap+0x5a/0x73\n[ 2763.365996] elf_map+0xb1/0xce\n[ 2763.365998] load_elf_binary+0x91e/0x137a\n[ 2763.365999] search_binary_handler+0x70/0x1f3\n[ 2763.366001] do_execveat_common+0x45e/0x68e\n[ 2763.366003] call_usermodehelper_exec_async+0xf7/0x11f\n[ 2763.366005] ret_from_fork+0x27/0x40\n[ 2763.366006] \n -> #0 (&mapping->i_mmap_rwsem){++++}:\n[ 2763.366010] __lock_acquire+0xa72/0xca0\n[ 2763.366012] lock_acquire+0x176/0x19e\n[ 2763.366015] down_read+0x3b/0x55\n[ 2763.366017] rmap_walk_file+0x5a/0x142\n[ 2763.366018] page_referenced+0xfc/0x134\n[ 2763.366022] shrink_active_list+0x1ac/0x37d\n[ 2763.366024] shrink_node_memcg.constprop.72+0x3ca/0x567\n[ 2763.366026] shrink_node+0x3f/0x14c\n[ 2763.366028] try_to_free_pages+0x288/0x47a\n[ 2763.366030] __alloc_pages_slowpath+0x3a7/0xa49\n[ 2763.366032] __alloc_pages_nodemask+0xf1/0x1f9\n[ 2763.366035] khugepaged+0xc8/0x167c\n[ 2763.366037] kthread+0x133/0x13b\n[ 2763.366039] ret_from_fork+0x27/0x40\n[ 2763.366040] \n other info that might help us debug this:\n\n[ 2763.366042] Chain exists of:\n &mapping->i_mmap_rwsem --> &vma->vm_sequence/1 --> fs_reclaim\n\n[ 2763.366048] Possible unsafe locking scenario:\n\n[ 2763.366049] CPU0 CPU1\n[ 2763.366050] ---- ----\n[ 2763.366051] lock(fs_reclaim);\n[ 2763.366054] lock(&vma->vm_sequence/1);\n[ 2763.366056] lock(fs_reclaim);\n[ 2763.366058] lock(&mapping->i_mmap_rwsem);\n[ 2763.366061] \n *** DEADLOCK ***\n\n[ 2763.366063] 1 lock held by khugepaged/42:\n[ 2763.366064] #0: (fs_reclaim){+.+.}, at: [] fs_reclaim_acquire+0x12/0x35\n[ 2763.366068] \n stack backtrace:\n[ 2763.366071] CPU: 2 PID: 42 Comm: khugepaged Not tainted 4.13.0-next-20170913-dbg-00039-ge3c06ea4b028-dirty #1837\n[ 2763.366073] Call Trace:\n[ 2763.366077] dump_stack+0x67/0x8e\n[ 2763.366080] print_circular_bug+0x2a1/0x2af\n[ 2763.366083] ? graph_unlock+0x69/0x69\n[ 2763.366085] check_prev_add+0x76/0x20d\n[ 2763.366087] ? graph_unlock+0x69/0x69\n[ 2763.366090] __lock_acquire+0xa72/0xca0\n[ 2763.366093] ? __save_stack_trace+0xa3/0xbf\n[ 2763.366096] lock_acquire+0x176/0x19e\n[ 2763.366098] ? rmap_walk_file+0x5a/0x142\n[ 2763.366100] down_read+0x3b/0x55\n[ 2763.366102] ? rmap_walk_file+0x5a/0x142\n[ 2763.366103] rmap_walk_file+0x5a/0x142\n[ 2763.366106] page_referenced+0xfc/0x134\n[ 2763.366108] ? page_vma_mapped_walk_done.isra.17+0xb/0xb\n[ 2763.366109] ? page_get_anon_vma+0x6d/0x6d\n[ 2763.366112] shrink_active_list+0x1ac/0x37d\n[ 2763.366115] shrink_node_memcg.constprop.72+0x3ca/0x567\n[ 2763.366118] ? ___might_sleep+0xd5/0x234\n[ 2763.366121] shrink_node+0x3f/0x14c\n[ 2763.366123] try_to_free_pages+0x288/0x47a\n[ 2763.366126] __alloc_pages_slowpath+0x3a7/0xa49\n[ 2763.366128] ? ___might_sleep+0xd5/0x234\n[ 2763.366131] __alloc_pages_nodemask+0xf1/0x1f9\n[ 2763.366133] khugepaged+0xc8/0x167c\n[ 2763.366138] ? remove_wait_queue+0x47/0x47\n[ 2763.366140] ? collapse_shmem.isra.45+0x828/0x828\n[ 2763.366142] kthread+0x133/0x13b\n[ 2763.366145] ? __list_del_entry+0x1d/0x1d\n[ 2763.366147] ret_from_fork+0x27/0x40\n\n\t-ss","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xtD8k5TcJz9s0g\n\tfor ;\n\tThu, 14 Sep 2017 19:42:30 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xtD8k4HX0zDrT1\n\tfor ;\n\tThu, 14 Sep 2017 19:42:30 +1000 (AEST)","from mail-pg0-x232.google.com (mail-pg0-x232.google.com\n\t[IPv6:2607:f8b0:400e:c05::232])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3xtD6q4zm6zDqJq\n\tfor ;\n\tThu, 14 Sep 2017 19:40:51 +1000 (AEST)","by mail-pg0-x232.google.com with SMTP id j16so5331588pga.1\n\tfor ;\n\tThu, 14 Sep 2017 02:40:51 -0700 (PDT)","from localhost ([175.223.49.171]) by smtp.gmail.com with ESMTPSA id\n\tt73sm27984014pgb.84.2017.09.14.02.40.46\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tThu, 14 Sep 2017 02:40:47 -0700 (PDT)"],"Authentication-Results":["ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"mdmHzhWO\"; dkim-atps=neutral","lists.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"mdmHzhWO\"; dkim-atps=neutral","ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=gmail.com\n\t(client-ip=2607:f8b0:400e:c05::232; helo=mail-pg0-x232.google.com;\n\tenvelope-from=sergey.senozhatsky.work@gmail.com; receiver=)","lists.ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"mdmHzhWO\"; dkim-atps=neutral"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=9mk3MVz1fkjUiGckM0zjHBoNnery6CEpIJsc16hhPOY=;\n\tb=mdmHzhWO3ccZHMctfgFD2qIKKEd+/0kRq1qbV/uSOwap+VDNy7ERYpFotPtbjwgbTa\n\tQVHEyuJoWNL84Ype227oubux6Js/XCctSOeyBkddM+t3LaiJWM0QO3jh1zPsL4/yTLY+\n\tzD/KefmHYDqVhmXGCgRQJ9nfoHZaE+B2SgC2w5/0iIM50qn5arTSXIp2oUt1s5zjag80\n\tzYd4nMdoEYw2tPO62mIES4a0LAWt4i/B+WUbq9Xi+kvbTqgaogq46pzSbAizEDSWeVJU\n\to47eY5r/aTg9AdjVku53W/Ml+nf/NG+iqS6gO4nAIAjS9p+JXwUvPGkVoAeagCKnr42U\n\tFfBw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=9mk3MVz1fkjUiGckM0zjHBoNnery6CEpIJsc16hhPOY=;\n\tb=ZIHwlMtKIhTzT4qcGx3n5o3jZKhpQ7f5WXHE9J8Rs0GTjNlikQ2U0Pt/FxbyIOnXbO\n\tVI0iu9F8y1X73rNb9yBYHk0XdRHeaqg8zUiPZOdGlTY5sGCQjx0CkZ4OctDcnY3AQ4Xl\n\tXjMjOpmr48k88ng+iB0NK9u+xFMmX55G0bakXY00XrNTVovkpc1OoLxOgNeNLsCMLWL7\n\tsovOphwFgmuTrFFWvYbdakBDEccDJ5VRM3b1IObn2oHe3lSAP3ABPcFgEhez7WIFWdin\n\t7+/N85v7u7UdKznZ+4CymeQ1kleEUjKLGQQZns2Kp2QromrS2KWo48imgB5Qboa5kAWh\n\t3xaw==","X-Gm-Message-State":"AHPjjUjEaYufJ3ziRq2I1t+aWvvrBP5iwkJrDpUk5uSO8nKHUVzgc2io\n\tZDgcZb7byCSFKA==","X-Google-Smtp-Source":"ADKCNb7TZQxlly/jIFo7wlvzy1ClWcsecPk7EGqf0OqUMrk2hPZGkk5O0d77oqtoWsEaMNIxLNrGYw==","X-Received":"by 10.99.126.84 with SMTP id o20mr20949287pgn.137.1505382048833; \n\tThu, 14 Sep 2017 02:40:48 -0700 (PDT)","Date":"Thu, 14 Sep 2017 18:40:43 +0900","From":"Sergey Senozhatsky ","To":"Laurent Dufour ","Subject":"Re: [PATCH v3 04/20] mm: VMA sequence count","Message-ID":"<20170914094043.GJ599@jagdpanzerIV.localdomain>","References":"<1504894024-2750-1-git-send-email-ldufour@linux.vnet.ibm.com>\n\t<1504894024-2750-5-git-send-email-ldufour@linux.vnet.ibm.com>\n\t<20170913115354.GA7756@jagdpanzerIV.localdomain>\n\t<44849c10-bc67-b55e-5788-d3c6bb5e7ad1@linux.vnet.ibm.com>\n\t<20170914003116.GA599@jagdpanzerIV.localdomain>\n\t<441ff1c6-72a7-5d96-02c8-063578affb62@linux.vnet.ibm.com>\n\t<20170914081358.GG599@jagdpanzerIV.localdomain>\n\t<26fa0b71-4053-5af7-baa0-e5fff9babf41@linux.vnet.ibm.com>\n\t<20170914091101.GH599@jagdpanzerIV.localdomain>\n\t<9605ce43-0f61-48d7-88e2-88220b773494@linux.vnet.ibm.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<9605ce43-0f61-48d7-88e2-88220b773494@linux.vnet.ibm.com>","User-Agent":"Mutt/1.9.0 (2017-09-02)","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"jack@suse.cz, Sergey Senozhatsky ,\n\tpeterz@infradead.org, Will Deacon ,\n\tmhocko@kernel.org, linux-mm@kvack.org, paulus@samba.org, hpa@zytor.com,\n\tkhandual@linux.vnet.ibm.com, ak@linux.intel.com, x86@kernel.org,\n\tMatthew Wilcox , Ingo Molnar , \n\tpaulmck@linux.vnet.ibm.com, npiggin@gmail.com, dave@stgolabs.net,\n\tkirill@shutemov.name, Thomas Gleixner ,\n\tlinuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,\n\tSergey Senozhatsky ,\n\takpm@linux-foundation.org, \n\tTim Chen , haren@linux.vnet.ibm.com","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1769156,"web_url":"http://patchwork.ozlabs.org/comment/1769156/","msgid":"<4e6c4e45-bbd6-3fd8-ee96-216892c797b3@linux.vnet.ibm.com>","date":"2017-09-15T12:38:51","subject":"Re: [PATCH v3 04/20] mm: VMA sequence count","submitter":{"id":40248,"url":"http://patchwork.ozlabs.org/api/people/40248/","name":"Laurent Dufour","email":"ldufour@linux.vnet.ibm.com"},"content":"Hi,\n\nOn 14/09/2017 11:40, Sergey Senozhatsky wrote:\n> On (09/14/17 11:15), Laurent Dufour wrote:\n>> On 14/09/2017 11:11, Sergey Senozhatsky wrote:\n>>> On (09/14/17 10:58), Laurent Dufour wrote:\n>>> [..]\n>>>> That's right, but here this is the sequence counter mm->mm_seq, not the\n>>>> vm_seq one.\n>>>\n>>> d'oh... you are right.\n>>\n>> So I'm doubting about the probability of a deadlock here, but I don't like\n>> to see lockdep complaining. Is there an easy way to make it happy ?\n> \n> \n> /*\n> * well... answering your question - it seems raw versions of seqcount\n> * functions don't call lockdep's lock_acquire/lock_release...\n> *\n> * but I have never told you that. never.\n> */\n\nHum... I'm not sure that would be the best way since in other case lockdep\nchecks are valid, but if getting rid of locked's warning is required to get\nthis series upstream, I'd use raw versions... Please advice...\n\n> \n> lockdep, perhaps, can be wrong sometimes, and may be it's one of those\n> cases. may be not... I'm not a MM guy myself.\n\nFrom the code reading I can't see any valid reason for a circular lock\ndependency.\n\n> below is a lockdep splat I got yesterday. that's v3 of SPF patch set.\n\nThis is exactly the same you got previously, and I still can't see how the\nchain \"&mapping->i_mmap_rwsem --> &vma->vm_sequence/1 --> fs_reclaim\" could\nhappen.\n\nCheers,\nLaurent.\n\n> \n> [ 2763.365898] ======================================================\n> [ 2763.365899] WARNING: possible circular locking dependency detected\n> [ 2763.365902] 4.13.0-next-20170913-dbg-00039-ge3c06ea4b028-dirty #1837 Not tainted\n> [ 2763.365903] ------------------------------------------------------\n> [ 2763.365905] khugepaged/42 is trying to acquire lock:\n> [ 2763.365906] (&mapping->i_mmap_rwsem){++++}, at: [] rmap_walk_file+0x5a/0x142\n> [ 2763.365913] \n> but task is already holding lock:\n> [ 2763.365915] (fs_reclaim){+.+.}, at: [] fs_reclaim_acquire+0x12/0x35\n> [ 2763.365920] \n> which lock already depends on the new lock.\n> \n> [ 2763.365922] \n> the existing dependency chain (in reverse order) is:\n> [ 2763.365924] \n> -> #3 (fs_reclaim){+.+.}:\n> [ 2763.365930] lock_acquire+0x176/0x19e\n> [ 2763.365932] fs_reclaim_acquire+0x32/0x35\n> [ 2763.365934] __alloc_pages_nodemask+0x6d/0x1f9\n> [ 2763.365937] pte_alloc_one+0x17/0x62\n> [ 2763.365940] __pte_alloc+0x1f/0x83\n> [ 2763.365943] move_page_tables+0x2c3/0x5a2\n> [ 2763.365944] move_vma.isra.25+0xff/0x29f\n> [ 2763.365946] SyS_mremap+0x41b/0x49e\n> [ 2763.365949] entry_SYSCALL_64_fastpath+0x18/0xad\n> [ 2763.365951] \n> -> #2 (&vma->vm_sequence/1){+.+.}:\n> [ 2763.365955] lock_acquire+0x176/0x19e\n> [ 2763.365958] write_seqcount_begin_nested+0x1b/0x1d\n> [ 2763.365959] __vma_adjust+0x1c4/0x5f1\n> [ 2763.365961] __split_vma+0x12c/0x181\n> [ 2763.365963] do_munmap+0x128/0x2af\n> [ 2763.365965] vm_munmap+0x5a/0x73\n> [ 2763.365968] elf_map+0xb1/0xce\n> [ 2763.365970] load_elf_binary+0x91e/0x137a\n> [ 2763.365973] search_binary_handler+0x70/0x1f3\n> [ 2763.365974] do_execveat_common+0x45e/0x68e\n> [ 2763.365978] call_usermodehelper_exec_async+0xf7/0x11f\n> [ 2763.365980] ret_from_fork+0x27/0x40\n> [ 2763.365981] \n> -> #1 (&vma->vm_sequence){+.+.}:\n> [ 2763.365985] lock_acquire+0x176/0x19e\n> [ 2763.365987] write_seqcount_begin_nested+0x1b/0x1d\n> [ 2763.365989] __vma_adjust+0x1a9/0x5f1\n> [ 2763.365991] __split_vma+0x12c/0x181\n> [ 2763.365993] do_munmap+0x128/0x2af\n> [ 2763.365994] vm_munmap+0x5a/0x73\n> [ 2763.365996] elf_map+0xb1/0xce\n> [ 2763.365998] load_elf_binary+0x91e/0x137a\n> [ 2763.365999] search_binary_handler+0x70/0x1f3\n> [ 2763.366001] do_execveat_common+0x45e/0x68e\n> [ 2763.366003] call_usermodehelper_exec_async+0xf7/0x11f\n> [ 2763.366005] ret_from_fork+0x27/0x40\n> [ 2763.366006] \n> -> #0 (&mapping->i_mmap_rwsem){++++}:\n> [ 2763.366010] __lock_acquire+0xa72/0xca0\n> [ 2763.366012] lock_acquire+0x176/0x19e\n> [ 2763.366015] down_read+0x3b/0x55\n> [ 2763.366017] rmap_walk_file+0x5a/0x142\n> [ 2763.366018] page_referenced+0xfc/0x134\n> [ 2763.366022] shrink_active_list+0x1ac/0x37d\n> [ 2763.366024] shrink_node_memcg.constprop.72+0x3ca/0x567\n> [ 2763.366026] shrink_node+0x3f/0x14c\n> [ 2763.366028] try_to_free_pages+0x288/0x47a\n> [ 2763.366030] __alloc_pages_slowpath+0x3a7/0xa49\n> [ 2763.366032] __alloc_pages_nodemask+0xf1/0x1f9\n> [ 2763.366035] khugepaged+0xc8/0x167c\n> [ 2763.366037] kthread+0x133/0x13b\n> [ 2763.366039] ret_from_fork+0x27/0x40\n> [ 2763.366040] \n> other info that might help us debug this:\n> \n> [ 2763.366042] Chain exists of:\n> &mapping->i_mmap_rwsem --> &vma->vm_sequence/1 --> fs_reclaim\n> \n> [ 2763.366048] Possible unsafe locking scenario:\n> \n> [ 2763.366049] CPU0 CPU1\n> [ 2763.366050] ---- ----\n> [ 2763.366051] lock(fs_reclaim);\n> [ 2763.366054] lock(&vma->vm_sequence/1);\n> [ 2763.366056] lock(fs_reclaim);\n> [ 2763.366058] lock(&mapping->i_mmap_rwsem);\n> [ 2763.366061] \n> *** DEADLOCK ***\n> \n> [ 2763.366063] 1 lock held by khugepaged/42:\n> [ 2763.366064] #0: (fs_reclaim){+.+.}, at: [] fs_reclaim_acquire+0x12/0x35\n> [ 2763.366068] \n> stack backtrace:\n> [ 2763.366071] CPU: 2 PID: 42 Comm: khugepaged Not tainted 4.13.0-next-20170913-dbg-00039-ge3c06ea4b028-dirty #1837\n> [ 2763.366073] Call Trace:\n> [ 2763.366077] dump_stack+0x67/0x8e\n> [ 2763.366080] print_circular_bug+0x2a1/0x2af\n> [ 2763.366083] ? graph_unlock+0x69/0x69\n> [ 2763.366085] check_prev_add+0x76/0x20d\n> [ 2763.366087] ? graph_unlock+0x69/0x69\n> [ 2763.366090] __lock_acquire+0xa72/0xca0\n> [ 2763.366093] ? __save_stack_trace+0xa3/0xbf\n> [ 2763.366096] lock_acquire+0x176/0x19e\n> [ 2763.366098] ? rmap_walk_file+0x5a/0x142\n> [ 2763.366100] down_read+0x3b/0x55\n> [ 2763.366102] ? rmap_walk_file+0x5a/0x142\n> [ 2763.366103] rmap_walk_file+0x5a/0x142\n> [ 2763.366106] page_referenced+0xfc/0x134\n> [ 2763.366108] ? page_vma_mapped_walk_done.isra.17+0xb/0xb\n> [ 2763.366109] ? page_get_anon_vma+0x6d/0x6d\n> [ 2763.366112] shrink_active_list+0x1ac/0x37d\n> [ 2763.366115] shrink_node_memcg.constprop.72+0x3ca/0x567\n> [ 2763.366118] ? ___might_sleep+0xd5/0x234\n> [ 2763.366121] shrink_node+0x3f/0x14c\n> [ 2763.366123] try_to_free_pages+0x288/0x47a\n> [ 2763.366126] __alloc_pages_slowpath+0x3a7/0xa49\n> [ 2763.366128] ? ___might_sleep+0xd5/0x234\n> [ 2763.366131] __alloc_pages_nodemask+0xf1/0x1f9\n> [ 2763.366133] khugepaged+0xc8/0x167c\n> [ 2763.366138] ? remove_wait_queue+0x47/0x47\n> [ 2763.366140] ? collapse_shmem.isra.45+0x828/0x828\n> [ 2763.366142] kthread+0x133/0x13b\n> [ 2763.366145] ? __list_del_entry+0x1d/0x1d\n> [ 2763.366147] ret_from_fork+0x27/0x40\n> \n> \t-ss\n>","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xtw3d1Wv0z9s7C\n\tfor ;\n\tFri, 15 Sep 2017 22:40:29 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xtw3d0dYRzDrZ7\n\tfor ;\n\tFri, 15 Sep 2017 22:40:29 +1000 (AEST)","from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com\n\t[148.163.156.1])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3xtw2F2kV6zDqff\n\tfor ;\n\tFri, 15 Sep 2017 22:39:17 +1000 (AEST)","from pps.filterd (m0098399.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv8FCdBk1113793\n\tfor ; Fri, 15 Sep 2017 08:39:15 -0400","from e06smtp11.uk.ibm.com (e06smtp11.uk.ibm.com [195.75.94.107])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2d0drybrha-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Fri, 15 Sep 2017 08:39:13 -0400","from localhost\n\tby e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tFri, 15 Sep 2017 13:39:07 +0100","from b06cxnps4074.portsmouth.uk.ibm.com (9.149.109.196)\n\tby e06smtp11.uk.ibm.com (192.168.101.141) with IBM ESMTP SMTP\n\tGateway: Authorized Use Only! Violators will be prosecuted; \n\tFri, 15 Sep 2017 13:38:59 +0100","from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com\n\t[9.149.105.59])\n\tby b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v8FCcxQf17694858; Fri, 15 Sep 2017 12:38:59 GMT","from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 9A532A4053;\n\tFri, 15 Sep 2017 13:35:06 +0100 (BST)","from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id C3AC9A4040;\n\tFri, 15 Sep 2017 13:35:04 +0100 (BST)","from [9.145.2.178] (unknown [9.145.2.178])\n\tby d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTP;\n\tFri, 15 Sep 2017 13:35:04 +0100 (BST)"],"Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=linux.vnet.ibm.com\n\t(client-ip=148.163.156.1; helo=mx0a-001b2d01.pphosted.com;\n\tenvelope-from=ldufour@linux.vnet.ibm.com; receiver=)","Subject":"Re: [PATCH v3 04/20] mm: VMA sequence count","To":"Sergey Senozhatsky ","References":"<1504894024-2750-1-git-send-email-ldufour@linux.vnet.ibm.com>\n\t<1504894024-2750-5-git-send-email-ldufour@linux.vnet.ibm.com>\n\t<20170913115354.GA7756@jagdpanzerIV.localdomain>\n\t<44849c10-bc67-b55e-5788-d3c6bb5e7ad1@linux.vnet.ibm.com>\n\t<20170914003116.GA599@jagdpanzerIV.localdomain>\n\t<441ff1c6-72a7-5d96-02c8-063578affb62@linux.vnet.ibm.com>\n\t<20170914081358.GG599@jagdpanzerIV.localdomain>\n\t<26fa0b71-4053-5af7-baa0-e5fff9babf41@linux.vnet.ibm.com>\n\t<20170914091101.GH599@jagdpanzerIV.localdomain>\n\t<9605ce43-0f61-48d7-88e2-88220b773494@linux.vnet.ibm.com>\n\t<20170914094043.GJ599@jagdpanzerIV.localdomain>","From":"Laurent Dufour ","Date":"Fri, 15 Sep 2017 14:38:51 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<20170914094043.GJ599@jagdpanzerIV.localdomain>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-TM-AS-GCONF":"00","x-cbid":"17091512-0040-0000-0000-000003FA3E23","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17091512-0041-0000-0000-0000209B6289","Message-Id":"<4e6c4e45-bbd6-3fd8-ee96-216892c797b3@linux.vnet.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-15_05:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=2\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709150184","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"jack@suse.cz, peterz@infradead.org, Will Deacon ,\n\tmhocko@kernel.org, linux-mm@kvack.org, paulus@samba.org, hpa@zytor.com,\n\tkhandual@linux.vnet.ibm.com, ak@linux.intel.com, x86@kernel.org,\n\tMatthew Wilcox , Ingo Molnar , \n\tpaulmck@linux.vnet.ibm.com, npiggin@gmail.com, dave@stgolabs.net,\n\tkirill@shutemov.name, Thomas Gleixner ,\n\tlinuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,\n\tSergey Senozhatsky ,\n\takpm@linux-foundation.org, \n\tTim Chen , haren@linux.vnet.ibm.com","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1774691,"web_url":"http://patchwork.ozlabs.org/comment/1774691/","msgid":"<20170925122219.ia6cmz2tng65fhoe@hirez.programming.kicks-ass.net>","date":"2017-09-25T12:22:19","subject":"Re: [PATCH v3 04/20] mm: VMA sequence count","submitter":{"id":493,"url":"http://patchwork.ozlabs.org/api/people/493/","name":"Peter Zijlstra","email":"peterz@infradead.org"},"content":"On Fri, Sep 15, 2017 at 02:38:51PM +0200, Laurent Dufour wrote:\n> > /*\n> > * well... answering your question - it seems raw versions of seqcount\n> > * functions don't call lockdep's lock_acquire/lock_release...\n> > *\n> > * but I have never told you that. never.\n> > */\n> \n> Hum... I'm not sure that would be the best way since in other case lockdep\n> checks are valid, but if getting rid of locked's warning is required to get\n> this series upstream, I'd use raw versions... Please advice...\n\nNo sensible other way to shut it up come to mind though. Might be best\nto use the raw primitives with a comment explaining why.","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y13DK5Tfpz9t62\n\tfor ;\n\tMon, 25 Sep 2017 22:24:17 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3y13DK4Q54zDsNH\n\tfor ;\n\tMon, 25 Sep 2017 22:24:17 +1000 (AEST)","from merlin.infradead.org (merlin.infradead.org\n\t[IPv6:2001:8b0:10b:1231::1])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3y13BW26pGzDsN9\n\tfor ;\n\tMon, 25 Sep 2017 22:22:43 +1000 (AEST)","from j217100.upc-j.chello.nl ([24.132.217.100]\n\thelo=hirez.programming.kicks-ass.net)\n\tby merlin.infradead.org with esmtpsa (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dwSOy-0001vU-MQ; Mon, 25 Sep 2017 12:22:21 +0000","by hirez.programming.kicks-ass.net (Postfix, from userid 1000)\n\tid 76FCC2013504E; Mon, 25 Sep 2017 14:22:19 +0200 (CEST)"],"Authentication-Results":["ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=infradead.org header.i=@infradead.org\n\theader.b=\"OcKzC4Bd\"; dkim-atps=neutral","lists.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=infradead.org header.i=@infradead.org\n\theader.b=\"OcKzC4Bd\"; dkim-atps=neutral","ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=infradead.org\n\t(client-ip=2001:8b0:10b:1231::1; helo=merlin.infradead.org;\n\tenvelope-from=peterz@infradead.org; receiver=)","lists.ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=infradead.org header.i=@infradead.org\n\theader.b=\"OcKzC4Bd\"; dkim-atps=neutral"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=infradead.org; s=merlin.20170209;\n\th=In-Reply-To:Content-Type:MIME-Version:\n\tReferences:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:\n\tContent-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:\n\tResent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:\n\tList-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;\n\tbh=jzzNEnxCYUSzbSMySt5SguHfw83krFsUgr3kvHCHZjQ=;\n\tb=OcKzC4BdDFlJAGMO2vQq/ItoP\n\tjItHzYOA2KEeITehlzqDfze+j5PfWqTOXwNlDO7P+LwdkcbnLQHkYojtyF23xrLsbsC75714v2hF4\n\taRmqicBwNmZ3th0E8I0tVs/s4v/Yy6i1+besaewd8KGdeYJ12nUs3F7LHzeeA0XTKB9bTBoJC/m8n\n\tOVLq0GC46Fmbic+Fmw+0ldtApbdJiuw75/t79oG0TzFpXz3CdTpMDtDCVZb1GnmlqpxxX7Kps/87f\n\tl2w7H9vqqnfWKeqUkeesoVnyQmSrE2/d1XSEbx1kEUZk0+7QiwR9wrxT1ChamnFFfUdvKwPDYU3rK\n\tV7terZQrw==;","Date":"Mon, 25 Sep 2017 14:22:19 +0200","From":"Peter Zijlstra ","To":"Laurent Dufour ","Subject":"Re: [PATCH v3 04/20] mm: VMA sequence count","Message-ID":"<20170925122219.ia6cmz2tng65fhoe@hirez.programming.kicks-ass.net>","References":"<20170913115354.GA7756@jagdpanzerIV.localdomain>\n\t<44849c10-bc67-b55e-5788-d3c6bb5e7ad1@linux.vnet.ibm.com>\n\t<20170914003116.GA599@jagdpanzerIV.localdomain>\n\t<441ff1c6-72a7-5d96-02c8-063578affb62@linux.vnet.ibm.com>\n\t<20170914081358.GG599@jagdpanzerIV.localdomain>\n\t<26fa0b71-4053-5af7-baa0-e5fff9babf41@linux.vnet.ibm.com>\n\t<20170914091101.GH599@jagdpanzerIV.localdomain>\n\t<9605ce43-0f61-48d7-88e2-88220b773494@linux.vnet.ibm.com>\n\t<20170914094043.GJ599@jagdpanzerIV.localdomain>\n\t<4e6c4e45-bbd6-3fd8-ee96-216892c797b3@linux.vnet.ibm.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<4e6c4e45-bbd6-3fd8-ee96-216892c797b3@linux.vnet.ibm.com>","User-Agent":"NeoMutt/20170609 (1.8.3)","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"jack@suse.cz, Sergey Senozhatsky ,\n\tWill Deacon , mhocko@kernel.org,\n\tlinux-mm@kvack.org, \n\tpaulus@samba.org, hpa@zytor.com, khandual@linux.vnet.ibm.com,\n\tak@linux.intel.com, x86@kernel.org,\n\tMatthew Wilcox , \n\tIngo Molnar , paulmck@linux.vnet.ibm.com,\n\tnpiggin@gmail.com, dave@stgolabs.net, kirill@shutemov.name,\n\tThomas Gleixner , \n\tlinuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,\n\tSergey Senozhatsky ,\n\takpm@linux-foundation.org, \n\tTim Chen , haren@linux.vnet.ibm.com","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}}]