Re: [PATCH] sparc64: mem mmap

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: Bob Picco <bpicco@xxxxxxxxxx>
Date: Wed, 10 Sep 2014 10:30:10 -0400

> In a common part for DTLB/ITLB "BAD RA" check TSTATE_PRIV. Should we not
> be privileged raise a bus error with SIGBUS and BUS_ADRERR for the task.

The kernel could be accessing userspace via copy_from_user() or one of
the other asm/uaccess.h accessors.

So you'll need the full context of the fault to make this decision, just
like do_sparc64_fault() does.

Actually, kernel TLB misses go via separate path and validate the RA
already before trying to load the entry into the TLB.  So you will
contextually know if we are dealing with a user mapping or not.

You could add a new thread fault code (FAULT_CODE_BAD_RA) to set in
this situation and then vector to do_sparc64_fault() when this
happens.

Probably do_sparc64_fault() should just immediately do a
do_fault_siginfo().  Suggested logic is:

	if (!down_read_trylock(&mm->mmap_sem)) {
 ...
		down_read(&mm->mmap_sem);
	}

	if (fault_code & FAULT_CODE_BAD_RA)
		goto do_sigbus;

	vma = find_vma(mm, address);

I would not try to do anything clever like seeing if this is a
non-faulting load or anything like that.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Kernel Development]     [DCCP]     [Linux ARM Development]     [Linux]     [Photo]     [Yosemite Help]     [Linux ARM Kernel]     [Linux SCSI]     [Linux x86_64]     [Linux Hams]

  Powered by Linux