Since commit 1eace8344c02 ("i2c: add param sanity check to
i2c_transfer()") and b7f625840267 ("i2c: add quirk checks to core"), the
I2C core does this check now. We can remove it here.
Signed-off-by: Wolfram Sang
---
Only build tested.
drivers/i2c/busses/i2c-opal.c | 4
1 file changed, 4
The core does it now, we can simplify drivers.
Wolfram Sang (2):
i2c: ibm_iic: don't check number of messages in the driver
i2c: opal: don't check number of messages in the driver
drivers/i2c/busses/i2c-ibm_iic.c | 3 ---
drivers/i2c/busses/i2c-opal.c| 4
2 files changed, 7 deletion
tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
topic/kbuild
head: 023eff0e59052c52bc4f077e66e82d68be486d7f
commit: 023eff0e59052c52bc4f077e66e82d68be486d7f [4/4] powerpc/kbuild: Move
-mprofile-kernel check to Kconfig
config: powerpc-asp8347_defconfig
compiler: powerpc
On Sat, May 19, 2018 at 11:04 PM Ram Pai wrote:
> On Sat, May 19, 2018 at 04:47:23PM -0700, Andy Lutomirski wrote: > On
Sat, May 19, 2018 at 1:28 PM Ram Pai wrote:
> ...snip...
> >
> > So is it possible for two threads to each call pkey_alloc() and end up
with
> > the same key? If so, it seems
On Sat, May 19, 2018 at 04:47:23PM -0700, Andy Lutomirski wrote: > On Sat, May
19, 2018 at 1:28 PM Ram Pai wrote:
...snip...
>
> So is it possible for two threads to each call pkey_alloc() and end up with
> the same key? If so, it seems entirely broken.
No. Two threads cannot allocate the sa
The ISA suggests ptesync after setting a pte, to prevent a table walk
initiated by a subsequent access from missing that store and causing a
spurious fault. This is an architectual allowance that allows an
implementation's page table walker to be incoherent with the store
queue.
However there is n
Prefetch the faulting address in update_mmu_cache to give the page
table walker perhaps 100 cycles head start as locks are dropped and
the interrupt completed.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/mm/mem.c | 4 +++-
arch/powerpc/mm/pgtable-book3s64.c | 3 ++-
2 files chan
Implementing pte_update with pte_xchg (which uses cmpxchg) is
inefficient. A single larx/stcx. works fine, no need for the less
efficient cmpxchg sequence.
Then remove the memory barriers from the operation. There is a
requirement for TLB flushing to load mm_cpumask after the store
that reduces pt
This matches other architectures, when we know there will be no
further accesses to the address (e.g., for teardown), page table
entries can be cleared non-atomically.
The comments about NMMU are bogus: all MMU notifiers (including NMMU)
are released at this point, with their TLBs flushed. An NMMU
Go one step further, if we're going to put a tlbie on the bus at all,
make it count. Make any global invalidation from a single threaded mm
do a full PID flush so the mm_cpumask can be reset.
The tradeoff is that it will over-flush one time the local CPU's TLB
if there was a small number of pages
When a single-threaded process has a non-local mm_cpumask and requires
a full PID tlbie invalidation, use that as an opportunity to reset the
cpumask back to the current CPU we're running on.
No other thread can concurrently switch to this mm, because it must
have been given a reference to mm_user
In the case of a spurious fault (which can happen due to a race with
another thread that changes the page table), the default Linux mm code
calls flush_tlb_page for that address. This is not required because
the pte will be re-fetched. Hash does not wire this up to a hardware
TLB flush for this rea
I've posted most of these separately at one time or another but I
will send them as a series, there have been some bug fixes and
changelog and comment improvements, and got some more numbers.
Most of the patches are logically independent (except 2 and 3 AFAIKS).
Thanks,
Nick
Nicholas Piggin (7):
On Sat, May 19, 2018 at 1:28 PM Ram Pai wrote:
> You got it mostly right. Filling in some more details below for
> completeness.
> [...]
Okay, so I guess I was correct as to what the functionality was but not as
to the encoding or the name of UAMOR.
Can you also confirm that mprotect_key() aff
On Fri, May 18, 2018 at 06:50:39PM -0700, Andy Lutomirski wrote:
> On Fri, May 18, 2018 at 6:19 PM Ram Pai wrote:
>
> > However the fundamental issue is still the same, as mentioned in the
> > other thread.
>
> > "Should the permissions on a key be allowed to be changed, if the key
> > is not al
On 05/19/2018 03:19 AM, Ram Pai wrote:
The issue you may be talking about here is that --
"when you set the AMR register to 0x, it
just sets it to 0x0c00."
To me it looks like, exec/fork are not related to the issue.
Or are they also somehow connected to the issue?
16 matches
Mail list logo