All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Pitre <nicolas.pitre@linaro.org>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org, linux-embedded@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Chris Brandt <Chris.Brandt@renesas.com>
Subject: Re: [PATCH v2 4/5] cramfs: add mmap support
Date: Mon, 28 Aug 2017 09:29:58 -0400 (EDT)	[thread overview]
Message-ID: <nycvar.YSQ.7.76.1708280914260.2606@knanqh.ubzr> (raw)
In-Reply-To: <20170828064632.GA26136@ZenIV.linux.org.uk>

On Mon, 28 Aug 2017, Al Viro wrote:

> On Wed, Aug 16, 2017 at 01:35:35PM -0400, Nicolas Pitre wrote:
> 
> > +static const struct vm_operations_struct cramfs_vmasplit_ops;
> > +static int cramfs_vmasplit_fault(struct vm_fault *vmf)
> > +{
> > +	struct mm_struct *mm = vmf->vma->vm_mm;
> > +	struct vm_area_struct *vma, *new_vma;
> > +	unsigned long split_val, split_addr;
> > +	unsigned int split_pgoff, split_page;
> > +	int ret;
> > +
> > +	/* Retrieve the vma split address and validate it */
> > +	vma = vmf->vma;
> > +	split_val = (unsigned long)vma->vm_private_data;
> > +	split_pgoff = split_val & 0xffff;
> > +	split_page = split_val >> 16;
> > +	split_addr = vma->vm_start + split_page * PAGE_SIZE;
> > +	pr_debug("fault: addr=%#lx vma=%#lx-%#lx split=%#lx\n",
> > +		 vmf->address, vma->vm_start, vma->vm_end, split_addr);
> > +	if (!split_val || split_addr >= vma->vm_end || vmf->address < split_addr)
> > +		return VM_FAULT_SIGSEGV;
> > +
> > +	/* We have some vma surgery to do and need the write lock. */
> > +	up_read(&mm->mmap_sem);
> > +	if (down_write_killable(&mm->mmap_sem))
> > +		return VM_FAULT_RETRY;
> > +
> > +	/* Make sure the vma didn't change between the locks */
> > +	vma = find_vma(mm, vmf->address);
> > +	if (vma->vm_ops != &cramfs_vmasplit_ops) {
> > +		/*
> > +		 * Someone else raced with us and could have handled the fault.
> > +		 * Let it go back to user space and fault again if necessary.
> > +		 */
> > +		downgrade_write(&mm->mmap_sem);
> > +		return VM_FAULT_NOPAGE;
> > +	}
> > +
> > +	/* Split the vma between the directly mapped area and the rest */
> > +	ret = split_vma(mm, vma, split_addr, 0);
> 
> Egads...  Everything else aside, who said that your split_... will have
> anything to do with the vma you get from find_vma()?

When vma->vm_ops == &cramfs_vmasplit_ops it is guaranteed that the vma 
is not fully populated and that the unpopulated area starts at 
split_addr. That split_addr was stored in vma->vm_private_data at the 
same time as vma->vm_ops. Given that mm->mmap_sem is held all along 
across find_vma(), split_vma() and the second find_vma() I hope that I 
can trust that things will be related.


Nicolas

  reply	other threads:[~2017-08-28 13:30 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-16 17:35 [PATCH v2 0/5] cramfs refresh for embedded usage Nicolas Pitre
2017-08-16 17:35 ` [PATCH v2 1/5] cramfs: direct memory access support Nicolas Pitre
2017-08-16 18:28   ` Chris Brandt
2017-08-16 19:44     ` Nicolas Pitre
2017-08-16 17:35 ` [PATCH v2 2/5] cramfs: make cramfs_physmem usable as root fs Nicolas Pitre
2017-08-16 17:35 ` [PATCH v2 3/5] cramfs: implement uncompressed and arbitrary data block positioning Nicolas Pitre
2017-08-16 18:28   ` Chris Brandt
2017-08-16 17:35 ` [PATCH v2 4/5] cramfs: add mmap support Nicolas Pitre
2017-08-16 18:28   ` Chris Brandt
2017-08-28  6:46   ` Al Viro
2017-08-28 13:29     ` Nicolas Pitre [this message]
2017-08-28 14:23       ` Al Viro
2017-08-28 19:17         ` Nicolas Pitre
2017-08-29 19:38           ` Chris Brandt
2017-08-29 20:00             ` Nicolas Pitre
2017-08-29 20:11               ` Chris Brandt
2017-08-31  2:29               ` Chris Brandt
2017-08-16 17:35 ` [PATCH v2 5/5] cramfs: rehabilitate it Nicolas Pitre
2017-08-31  2:30 ` [PATCH v2 0/5] cramfs refresh for embedded usage Chris Brandt
2017-08-31  3:03   ` Nicolas Pitre

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=nycvar.YSQ.7.76.1708280914260.2606@knanqh.ubzr \
    --to=nicolas.pitre@linaro.org \
    --cc=Chris.Brandt@renesas.com \
    --cc=linux-embedded@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@ZenIV.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.