Received: by 10.192.165.148 with SMTP id m20csp5155777imm; Tue, 8 May 2018 23:42:33 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpI66a0YFuBJRilLQ7PZzumaSlM5VvnRhnOp4DVbKGDGASJfUM7ItBLvt+YAvYBDgMHpivO X-Received: by 2002:a17:902:ab83:: with SMTP id f3-v6mr43668776plr.344.1525848152976; Tue, 08 May 2018 23:42:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525848152; cv=none; d=google.com; s=arc-20160816; b=vQdLbQIeQevFlZbt8duSV08bciPCe1TXPBJzkc1exFUqAH8QV+oS9XY3DgRxZBE2co 4/L8C03eODuf7UUd07PGSvIp9vLH/bOdxownZrXAwaXJroSx3H+ApVOYL1P+Jqv9C5Qk nopMsD1zL2I4Yhm94gpIh9Ge5GPE/sQlazom/qMo2I0TknygUMjebZGh2VxleibQYMl9 X/FCuzny8ihxobBQMDvQO0hqr4s0vUJ0THiXyeeKzIdStDlt34F2O8bbuzQcV/jW0NfR 5LV1ZZdLOSoq/2Ww/ukGex3kvTNDlar/hGWMuT71Qt/VMx0A/cAjZj+YqE95sVWCXan3 /b1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=jmT6t/ypt9+N0gocVV4oi3406yefm0WeWZGciTKVSj8=; b=TNVusArhOVY0UUppvXMSjTbmhnXhbY/fJpMYoy0oPf1hHaaTJlrF7yPHnw1Tyqer4P naKSbQ5+QjOZhqsjQ6M8L67eSCv5ayYdOy1kc9zMa2g6AdLRVAXmqcrSbhax6CYxC4Qn iwAtMxAxK+5v70JmDamPnbEYcjZoghPImptMrZt2wz32eSj9Dk6qEHKmHsnfZjXkaGUN QM6H8tapxYOc73j2oxIDwv0AlwcXM1jwuBtL6VPMOyjQv88YRfk/1gzNn24cbyMwR6lc RXw5Rwx6Np6CL3cXxMU0+4Y9ZKf9y4p1tqFCYrrKRXpmR1qqyjvygr32ZV5TJnmNkQmU 1Gpw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=RzYP1mFx; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a12-v6si25791364plp.225.2018.05.08.23.42.18; Tue, 08 May 2018 23:42:32 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=RzYP1mFx; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933715AbeEIGkb (ORCPT + 99 others); Wed, 9 May 2018 02:40:31 -0400 Received: from mail-pl0-f65.google.com ([209.85.160.65]:37520 "EHLO mail-pl0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933305AbeEIGka (ORCPT ); Wed, 9 May 2018 02:40:30 -0400 Received: by mail-pl0-f65.google.com with SMTP id f7-v6so3713145plr.4 for ; Tue, 08 May 2018 23:40:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=jmT6t/ypt9+N0gocVV4oi3406yefm0WeWZGciTKVSj8=; b=RzYP1mFxD98ggEFyiF46zHW/qMYb8AEscXYvHW69y7ulIUkJK1vJEWWCD6IfyANU7p DKHTvsovqZ32kz29F6xtNCptMDstSnDBMLAwaW13rNQRvPvkgf1uDcKnJfpKHC0JfyGa D4eVi3cbEurje2Dihzx3uXS+ZCD5alUnt98szf+4psd76ELQbm6ndFNGyVy8zKW8AQBi OC6Smb+DuaUMzRBAEseByaCKR9oPJ4eVbLL7WGiDulUzeZqNz9dybc4/cIvvsU1GF3XE VEZhhbC+UCXQju7fw/GumnVbU6o/KiH5tMojCWOddKt/sZlovPEXma5T8le933uqJ3CM Ourg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=jmT6t/ypt9+N0gocVV4oi3406yefm0WeWZGciTKVSj8=; b=h8rxdZ0YEwGXrCA7hNngdjFm6oOhB+NGMXYCsjl8PrpvcNuLWA63ctLb5bJkK+e1H1 ipqs/yFPPm2nxcmZENen7ZE7lSQftO6VzfK+U5J7vGKu98iaCX5ED7G/6sYGaQORx0bf hZN4IYwECR2/oYRsUS/J/aFyijEF4TVjFxlVxsRTfUAqUrN0VQWb7AtBaXIRs1uA/UFN q59Tym97M7WcSgcGTxTtesbmOrJL9pyyZScLAFvGcfkG2E+HkumeLvconmrLBfjy2HVS WoeU37uW16vIByVH9RkenNSr4hjHhLTO67Pe9Z/ftzwv+6t3uTrWmA9cpZNxDut0Gynz O2Dg== X-Gm-Message-State: ALQs6tDokI5tGuDOpin1VCvaK+PY2VwMmzqZH0Ep3CkzEGIKsUdGOPSF xHQhBLyMTIk9q8iNyUVGKWg= X-Received: by 2002:a17:902:a986:: with SMTP id bh6-v6mr38814553plb.245.1525848029576; Tue, 08 May 2018 23:40:29 -0700 (PDT) Received: from rodete-desktop-imager.corp.google.com ([2401:fa00:d:10:affa:813f:5380:6613]) by smtp.gmail.com with ESMTPSA id s7sm45488640pfm.114.2018.05.08.23.40.25 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 08 May 2018 23:40:27 -0700 (PDT) Date: Wed, 9 May 2018 15:40:23 +0900 From: Minchan Kim To: Joel Fernandes Cc: LKML , Ganesh Mahendran , Joe Perches , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Todd Kjos , Greg Kroah-Hartman , Martijn Coenen Subject: Re: [PATCH v6] ANDROID: binder: change down_write to down_read Message-ID: <20180509064023.GD8209@rodete-desktop-imager.corp.google.com> References: <20180507141537.4855-1-minchan@kernel.org> <20180507172829.GA66161@joelaf.mtv.corp.google.com> <20180508105101.GB8209@rodete-desktop-imager.corp.google.com> <20180508230813.GA102094@joelaf.mtv.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180508230813.GA102094@joelaf.mtv.corp.google.com> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 08, 2018 at 04:08:13PM -0700, Joel Fernandes wrote: > On Tue, May 08, 2018 at 07:51:01PM +0900, Minchan Kim wrote: > > On Mon, May 07, 2018 at 10:28:29AM -0700, Joel Fernandes wrote: > > > On Mon, May 07, 2018 at 11:15:37PM +0900, Minchan Kim wrote: > > > > binder_update_page_range needs down_write of mmap_sem because > > > > vm_insert_page need to change vma->vm_flags to VM_MIXEDMAP unless > > > > it is set. However, when I profile binder working, it seems > > > > every binder buffers should be mapped in advance by binder_mmap. > > > > It means we could set VM_MIXEDMAP in binder_mmap time which is > > > > already hold a mmap_sem as down_write so binder_update_page_range > > > > doesn't need to hold a mmap_sem as down_write. > > > > Please use proper API down_read. It would help mmap_sem contention > > > > problem as well as fixing down_write abuse. > > > > > > > > Ganesh Mahendran tested app launching and binder throughput test > > > > and he said he couldn't find any problem and I did binder latency > > > > test per Greg KH request(Thanks Martijn to teach me how I can do) > > > > I cannot find any problem, too. > > > > > > > > Cc: Ganesh Mahendran > > > > Cc: Joe Perches > > > > Cc: Arve Hj?nnev?g > > > > Cc: Todd Kjos > > > > Cc: Greg Kroah-Hartman > > > > Reviewed-by: Martijn Coenen > > > > Signed-off-by: Minchan Kim > > > > --- > > > > drivers/android/binder.c | 4 +++- > > > > drivers/android/binder_alloc.c | 6 +++--- > > > > 2 files changed, 6 insertions(+), 4 deletions(-) > > > > > > > > diff --git a/drivers/android/binder.c b/drivers/android/binder.c > > > > index 4eab5be3d00f..7b8e96f60719 100644 > > > > --- a/drivers/android/binder.c > > > > +++ b/drivers/android/binder.c > > > > @@ -4730,7 +4730,9 @@ static int binder_mmap(struct file *filp, struct vm_area_struct *vma) > > > > failure_string = "bad vm_flags"; > > > > goto err_bad_arg; > > > > } > > > > - vma->vm_flags = (vma->vm_flags | VM_DONTCOPY) & ~VM_MAYWRITE; > > > > + vma->vm_flags |= VM_DONTCOPY | VM_MIXEDMAP; > > > > + vma->vm_flags &= ~VM_MAYWRITE; > > > > + > > > > vma->vm_ops = &binder_vm_ops; > > > > vma->vm_private_data = proc; > > > > > > > > diff --git a/drivers/android/binder_alloc.c b/drivers/android/binder_alloc.c > > > > index 5a426c877dfb..4f382d51def1 100644 > > > > --- a/drivers/android/binder_alloc.c > > > > +++ b/drivers/android/binder_alloc.c > > > > @@ -219,7 +219,7 @@ static int binder_update_page_range(struct binder_alloc *alloc, int allocate, > > > > mm = alloc->vma_vm_mm; > > > > > > > > if (mm) { > > > > - down_write(&mm->mmap_sem); > > > > + down_read(&mm->mmap_sem); > > > > > > > > > Nice. Is there a need to hold the reader-lock at all here? Just curious what > > > else is it protecting (here or in vm_insert_page). > > > > It should protect vm_area_struct. IOW, when we try insert page into virtual address area, > > vma shouldn't be changed(ie, unmap/collapse/split). > > When you say unmap, are you talking about pages being unmapped from the VMA > or something else? I mean to destroy vm_area_struct itself as well as unmap pages. > > For the collapse/split part, the binder VMA (vm_area_struct) itself isn't > changed after the initial mmap (AFAIK) so I don't see a need for protection > there. There is no way to unmap in runtime? What happens if some buggy applications do unmap by mistake? Cannot we access those B's vma from A context? If B process is exiting, the VMA would be gone while A is accessing. > > Again, I'm not against the patch but thought its good to clarify for myself > what the usage of the lock is, here. I know. :)