On Thu, Sep 10, 2015 at 10:53:43PM +0200, Robert Jarzmik wrote:
> Russell King - ARM Linux writes:
>
> > I've been wondering whether we can teach GCC that set_domain modifies
> > the value that get_domain returns, rather than throwing a volatile
> > onto the asm in get_domain. The issue with a v
Russell King - ARM Linux writes:
> I've been wondering whether we can teach GCC that set_domain modifies
> the value that get_domain returns, rather than throwing a volatile
> onto the asm in get_domain. The issue with a volatile there is that
> even if the result is unused, but the code is reac
On Thu, Sep 10, 2015 at 09:01:41PM +0200, Robert Jarzmik wrote:
> And I have the proof of gcc optimization, which I'll add to the commit message
> if you want :
> 0728 :
> ...
> 770: ee134f10mrc 15, 0, r4, cr3, cr0, {0}
> ... no r4 or mrc/mcr usage
> 788:
Robert Jarzmik writes:
> Russell King - ARM Linux writes:
>
>> On Tue, Sep 08, 2015 at 07:01:00PM +0200, Robert Jarzmik wrote:
>>> Russell King - ARM Linux writes:
>> At the point we call into this code, the DACR should be 0x75, which
>> should allow us to read the instruction at 0xbf00202c. B
Russell King - ARM Linux writes:
> On Tue, Sep 08, 2015 at 07:01:00PM +0200, Robert Jarzmik wrote:
>> Russell King - ARM Linux writes:
> At the point we call into this code, the DACR should be 0x75, which
> should allow us to read the instruction at 0xbf00202c. But this is
> failing with a perm
Russell King - ARM Linux writes:
> What should happen is:
Thanks very much for the explanation, hopefully I have enough material to fly on
my own now.
> Now, when you get the fault inside arm_copy_from_user(), you can
> print the DACR value saved at the time the fault was generated by
> printing
On Tue, Sep 08, 2015 at 07:01:00PM +0200, Robert Jarzmik wrote:
> Russell King - ARM Linux writes:
>
> >> Gah, silly me. But even with [1], I still get an error [2]. I have a
> >> confirmation that I have a "Page Permission" fault on the
> >> probe_kernel_address().
> >
> > Hmm, that's not right.
Russell King - ARM Linux writes:
>> Gah, silly me. But even with [1], I still get an error [2]. I have a
>> confirmation that I have a "Page Permission" fault on the
>> probe_kernel_address().
>
> Hmm, that's not right. If it's the DACR, then it should be a page domain
> fault, not a page permis
On Sun, Sep 06, 2015 at 11:31:34PM +0200, Robert Jarzmik wrote:
> Russell King - ARM Linux writes:
>
> >> [1] Approach 1 : translation table sync
> >> ===
> ...
> > The important place is in arch/arm/include/asm/domain.h, which is where
> > we manipulate the DA
Russell King - ARM Linux writes:
>> [1] Approach 1 : translation table sync
>> ===
...
> The important place is in arch/arm/include/asm/domain.h, which is where
> we manipulate the DACR within probe_kernel_address().
Gah, silly me. But even with [1], I still g
On Sun, Sep 06, 2015 at 07:25:01PM +0200, Robert Jarzmik wrote:
> Russell King - ARM Linux writes:
>
> > On Sat, Sep 05, 2015 at 07:10:49PM +0200, Robert Jarzmik wrote:
> >> Russell King - ARM Linux writes:
> >> So the issue is around this SW_DOMAIN_PAN, at least on PXA.
> >
> > If so, you may n
Russell King - ARM Linux writes:
> On Sat, Sep 05, 2015 at 07:10:49PM +0200, Robert Jarzmik wrote:
>> Russell King - ARM Linux writes:
>> So the issue is around this SW_DOMAIN_PAN, at least on PXA.
>
> If so, you may need to add:
>
> mrc p15, 0, \rd, c2, c0, 0
> mov \rd, \rd
>
Russell King - ARM Linux writes:
>> Moreover, this is consistent with the fact that this commit is in linux-next
>> but
>> not in v4.1 :
>> a5e090acbf54 ("ARM: software-based priviledged-no-access support")
>>
>> So the issue is around this SW_DOMAIN_PAN, at least on PXA.
>
> Is it only PXA
On Sat, Sep 05, 2015 at 07:10:49PM +0200, Robert Jarzmik wrote:
> Russell King - ARM Linux writes:
>
> > On Sat, Sep 05, 2015 at 03:48:38PM +0200, Robert Jarzmik wrote:
> >> This time I took my JTAG to have a look at the flow, in
> >> arch/arm/mm/alignment.c,
> >> where I added the small chunk i
Russell King - ARM Linux writes:
> On Sat, Sep 05, 2015 at 03:48:38PM +0200, Robert Jarzmik wrote:
>> This time I took my JTAG to have a look at the flow, in
>> arch/arm/mm/alignment.c,
>> where I added the small chunk in [2], which gave in my case :
>> RJK: fault=4 instr=0x instrptr
On Sat, Sep 05, 2015 at 03:48:38PM +0200, Robert Jarzmik wrote:
> Dave Martin writes:
>
> > On Wed, Sep 02, 2015 at 08:23:29AM +0200, Robert Jarzmik wrote:
> >> On old ARM chips, unaligned accesses to memory are not trapped and
> >> fixed. On module load, symbols are relocated, and the relocatio
Dave Martin writes:
> On Wed, Sep 02, 2015 at 08:23:29AM +0200, Robert Jarzmik wrote:
>> On old ARM chips, unaligned accesses to memory are not trapped and
>> fixed. On module load, symbols are relocated, and the relocation of
>> __bug_table symbols is done on a u32 basis. Yet the section is not
On Wed, Sep 02, 2015 at 08:23:29AM +0200, Robert Jarzmik wrote:
> On old ARM chips, unaligned accesses to memory are not trapped and
> fixed. On module load, symbols are relocated, and the relocation of
> __bug_table symbols is done on a u32 basis. Yet the section is not
> aligned to a multiple of
18 matches
Mail list logo
