Re: [PATCH] DSPBRIDGE:Fix Kernel memory poison overwritten after DSP_MMUFAULT
On Thu, May 13, 2010 at 2:39 PM, Felipe Contreras wrote: > On Thu, May 13, 2010 at 12:09 AM, Guzman Lugo, Fernando > wrote: >>> If you are referring to this patch: >>> http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap- >>> 2.6.git;a=commit;h=26ad62f03578a12e942d8bb86d0e52ef1afdee22 >> >> Yes, that's the patch. Could you make sure that the GPT8 interrupt is >> generated before acking MMU fault interrupt? > > I'll try tomorrow when I have access to the hw. I should see "GPTimer interrupt failed" if it doesn't... right? Then yes, the GPT8 interrupt is generated. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] DSPBRIDGE:Fix Kernel memory poison overwritten after DSP_MMUFAULT
On Fri, May 14, 2010 at 12:15 AM, Guzman Lugo, Fernando
wrote:
>> But the DSP is not dumping the stack there, from what I can see
>> bridge_brd_read() is used to read DSP internal memory.
>
> DSP is dumping the stack after the MMUFault and mmu let DSP to continue.
>
> Let's see what happens in successful case, so that the mmu fault
> Mechanics can be understood better:
>
> 1.- DSP wants to write some virtual address which is not found by the
> Mmu.
>
> 2.- MMU module does not allow to the DSP continue executing and
> Generates MMUfault interrupt which is attached to MPU side.
>
> 3.- MPU side allocates a dummy address, so that it can be mapped to
> The DSP fault address.
>
> dummy_va_addr = kzalloc(sizeof(char) * 0x1000, GFP_ATOMIC);
>
>
> 3.- MPU dumps the DLL loaded
> At the moment of the crash, at this point we don't need anything from
> DSP because MPU has the information of DLL's loaded.
>
>
> print_dsp_trace_buffer(dev_context);
> dump_dl_modules(dev_context);
>
>
> 4.- MPU maps the physical address of the dummy address to the fault address
> So that, if the DSP want to write into the fault address it will
> Be writing into the dummy buffer revered previously.
>
> hw_mmu_tlb_add(resources->dw_dmmu_base,
> mem_physical, fault_addr,
> HW_PAGE_SIZE4KB, 1,
> &map_attrs, HW_SET, HW_SET);
>
> 5.- MPU generates a GPT8 overflow interrupt.
>
> while (!(omap_dm_timer_read_status(timer) &
> GPTIMER_IRQ_OVERFLOW)) {
> if (cnt++ >= GPTIMER_IRQ_WAIT_MAX_CNT) {
> pr_err("%s: GPTimer interrupt
> failed\n",
> __func__);
> break;
> }
> }
>
>
> 6.- MPU acked mmufault interrupt.
>
>
> hw_mmu_event_ack(resources->dw_dmmu_base,
> HW_MMU_TRANSLATION_FAULT);
>
>
> 7.- MMU module tries to get the physical address of the DSP fault address
> A now it can, the address is the page of the dummy address + the
> Offset of the fault address.
>
> 8.- MMU module lets DSP to continue. But at that moment DSP has to attend
> The GPT8 hw interrupt so that it change the context to the GTP8
> overflow ISR and then dumps all the stack information in the same
> shared memory area which is use for SYS_printf traces.
>
> 9.- After doing the acked of the MMUfault interrupt MPU call
> dump_dsp_stack function
>
> /* Clear MMU interrupt */
> hw_mmu_event_ack(resources->dw_dmmu_base,
> HW_MMU_TRANSLATION_FAULT);
> dump_dsp_stack(deh_mgr->hwmd_context);
>
> 10. Inside dump_dsp_stack we wait until DSP writes the special value
> MMU_FAULT_HEAD1 and MMU_FAULT_HEAD2 into tracing area, which
> States the DSP completed the stack dump.
>
> while ((mmu_fault_dbg_info.head[0] != MMU_FAULT_HEAD1 ||
> mmu_fault_dbg_info.head[1] != MMU_FAULT_HEAD2) &&
> poll_cnt < POLL_MAX) {
>
> /* Read DSP dump size from the DSP trace buffer... */
> status = (*intf_fxns->pfn_brd_read)(wmd_context,
> (u8 *)&mmu_fault_dbg_info, (u32)trace_begin,
> sizeof(mmu_fault_dbg_info), 0);
>
> if (DSP_FAILED(status))
> break;
>
> poll_cnt++;
> }
>
>
> 11 .- After writing the heads values, DSP just does an infinite while
>
> 12.- MPU then prints the information sent by DSP.
>
>
> Please let me know if you have any doubt.
You repeated step 3 twice. So let's assume the first one is 3.1.
1) What happens if you skip step 3.1 and 4?
You are assuming that the MMU unit would not let the DSP continue
running, but I fail to see why. Then the stack information would not
be available.
First of all, I don't see any stack information anyway:
dump_dsp_stack:No DSP MMU-Fault information available. Now Deepak has
used 0 in hw_mmu_tlb_add() and he is able to see the stack just fine.
>> If I'm understanding things correctly, then we shouldn't map the
>> faulty address again (through hw_mmu_tlb_add), and we shouldn't clear
>> the interrupt either (HW_MMU_TRANSLATION_FAULT). (I haven't tested
>> this yet).
>
> If we do that, DSP would be able to dump the DSP stack.
You mean we _woudn't_? First, I'm not really worried about loosing a
feature that doesn't seem to be working anyway. And second, we assume
we actually want that feature. For development purposes, sure, bu
RE: [PATCH] DSPBRIDGE:Fix Kernel memory poison overwritten after DSP_MMUFAULT
Hi,
> -Original Message-
> From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
> Sent: Thursday, May 13, 2010 1:30 PM
> To: Guzman Lugo, Fernando
> Cc: Chitriki Rudramuni, Deepak; linux-omap; Ameya Palande; Felipe
> Contreras; Hiroshi Doyu; Ramirez Luna, Omar; Menon, Nishanth
> Subject: Re: [PATCH] DSPBRIDGE:Fix Kernel memory poison overwritten after
> DSP_MMUFAULT
>
> On Thu, May 13, 2010 at 8:29 PM, Guzman Lugo, Fernando
> wrote:
> >> First of all, what is the DSP supposed to do with that memory? Do we
> >> really need to call hw_mmu_tlb_add at all?
> >
> > Once DSP MMUfault happens iva mmu module prevents DSP continue executing
> until mmu module is able get some physical address for the virtual address
> that the dsp wanted to access. Once mmu fault interrupt is acked the mmu
> module tries to translate the virtual address again and if it gets the
> physical address DSP continue executing.
>
> This is if we want the DSP to continue executing, which all the code
> assumes we don't. If we wanted to do that, then we would need to know
> how to get the data that the DSP code was trying to access, but we
> don't. We always provide the data beforehand, and if the DSP code
> tries to access something else, there's nothing else to do.
>
> > So in order to DSP can dumps its stack we need to map some physical
> address to that virtual address, so that mmu release DSP and it can dumps
> the stack.
>
> But the DSP is not dumping the stack there, from what I can see
> bridge_brd_read() is used to read DSP internal memory.
DSP is dumping the stack after the MMUFault and mmu let DSP to continue.
Let's see what happens in successful case, so that the mmu fault
Mechanics can be understood better:
1.- DSP wants to write some virtual address which is not found by the
Mmu.
2.- MMU module does not allow to the DSP continue executing and
Generates MMUfault interrupt which is attached to MPU side.
3.- MPU side allocates a dummy address, so that it can be mapped to
The DSP fault address.
dummy_va_addr = kzalloc(sizeof(char) * 0x1000, GFP_ATOMIC);
3.- MPU dumps the DLL loaded
At the moment of the crash, at this point we don't need anything from
DSP because MPU has the information of DLL's loaded.
print_dsp_trace_buffer(dev_context);
dump_dl_modules(dev_context);
4.- MPU maps the physical address of the dummy address to the fault address
So that, if the DSP want to write into the fault address it will
Be writing into the dummy buffer revered previously.
hw_mmu_tlb_add(resources->dw_dmmu_base,
mem_physical, fault_addr,
HW_PAGE_SIZE4KB, 1,
&map_attrs, HW_SET, HW_SET);
5.- MPU generates a GPT8 overflow interrupt.
while (!(omap_dm_timer_read_status(timer) &
GPTIMER_IRQ_OVERFLOW)) {
if (cnt++ >= GPTIMER_IRQ_WAIT_MAX_CNT) {
pr_err("%s: GPTimer interrupt failed\n",
__func__);
break;
}
}
6.- MPU acked mmufault interrupt.
hw_mmu_event_ack(resources->dw_dmmu_base,
HW_MMU_TRANSLATION_FAULT);
7.- MMU module tries to get the physical address of the DSP fault address
A now it can, the address is the page of the dummy address + the
Offset of the fault address.
8.- MMU module lets DSP to continue. But at that moment DSP has to attend
The GPT8 hw interrupt so that it change the context to the GTP8
overflow ISR and then dumps all the stack information in the same
shared memory area which is use for SYS_printf traces.
9.- After doing the acked of the MMUfault interrupt MPU call
dump_dsp_stack function
/* Clear MMU interrupt */
hw_mmu_event_ack(resources->dw_dmmu_base,
HW_MMU_TRANSLATION_FAULT);
dump_dsp_stack(deh_mgr->hwmd_context);
10. Inside dump_dsp_stack we wait until DSP writes the special value
MMU_FAULT_HEAD1 and MMU_FAULT_HEAD2 into tracing area, which
States the DSP completed the stack dump.
while ((mmu_fault_dbg_info.head[0] != MMU_FAULT_HEAD1 ||
mmu_fault_dbg_info.head[1] != MMU_FAULT_HEAD2) &&
poll_cnt < POLL_MAX) {
/* Read DSP dump size from the DSP trace buffer... */
Re: [PATCH] DSPBRIDGE:Fix Kernel memory poison overwritten after DSP_MMUFAULT
On Thu, May 13, 2010 at 8:29 PM, Guzman Lugo, Fernando wrote: >> First of all, what is the DSP supposed to do with that memory? Do we >> really need to call hw_mmu_tlb_add at all? > > Once DSP MMUfault happens iva mmu module prevents DSP continue executing > until mmu module is able get some physical address for the virtual address > that the dsp wanted to access. Once mmu fault interrupt is acked the mmu > module tries to translate the virtual address again and if it gets the > physical address DSP continue executing. This is if we want the DSP to continue executing, which all the code assumes we don't. If we wanted to do that, then we would need to know how to get the data that the DSP code was trying to access, but we don't. We always provide the data beforehand, and if the DSP code tries to access something else, there's nothing else to do. > So in order to DSP can dumps its stack we need to map some physical address > to that virtual address, so that mmu release DSP and it can dumps the stack. But the DSP is not dumping the stack there, from what I can see bridge_brd_read() is used to read DSP internal memory. You said yourself that you could pass a totally dummy address like 0, and the stack will still be printed. > Therefore we allocate some dummy buffer of one 4K page and get the physical > address of that buffer and use that physical address to fill the tbl on the > mmu module using hw_mmu_tlb_add function. I think that's wrong. We should not give the DSP hopes that it will be able to read data from that fault address... it's over. > However the address returned by kmalloc is not page aling, that's means this > mpu virtual address has some offset, for examples in the log that were send > the dummy address had an offset of 0x080 and the DSP side virtual memory had > an offset of 0x040. base on the offset of the MPU side and as we allocate one > page that means we can access from 0x080 - 0xfff of the first page and from > 0x000 - 0x080 if the second page, but we always allocate the first page to > the DSP side, then DSP access to the address it wanted to access and now > there is no mmufault but it is accessing (actually writing because reading > not cause corruption) to that page but with a offset of 0x040 causing the > corruption. > > Using get_user_pages fixes that case because as it returns address page > aligned the DSP side can access from 0x000 - 0xfff of that page. You mean __get_free_pages? > However this is not the right solution because lets suppose if DSP side > virtual address offset is 0xfff. So we map a page and DSP can access that > page from 0x000 - 0xfff, however is the DSP is able to continue executing it > will reach the following page and maybe that page is already mapped but it > only can access from an specific offset like for example 0x100, in this ca > DSP will still corrupt from 0x000 to 0x0ff of the next page. >From what I understand it's impossible for the DSP to access memory that wasn't mapped. So if we map only that page, when the DSP tries to write to 0x100, another MMU fault will happen. If I'm understanding things correctly, then we shouldn't map the faulty address again (through hw_mmu_tlb_add), and we shouldn't clear the interrupt either (HW_MMU_TRANSLATION_FAULT). (I haven't tested this yet). Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] DSPBRIDGE:Fix Kernel memory poison overwritten after DSP_MMUFAULT
> -Original Message-
> From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
> Sent: Thursday, May 13, 2010 6:39 AM
> To: Guzman Lugo, Fernando
> Cc: Chitriki Rudramuni, Deepak; linux-omap; Ameya Palande; Felipe
> Contreras; Hiroshi Doyu; Ramirez Luna, Omar; Menon, Nishanth
> Subject: Re: [PATCH] DSPBRIDGE:Fix Kernel memory poison overwritten after
> DSP_MMUFAULT
>
> On Thu, May 13, 2010 at 12:09 AM, Guzman Lugo, Fernando
> wrote:
> >> If you are referring to this patch:
> >> http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-
> >> 2.6.git;a=commit;h=26ad62f03578a12e942d8bb86d0e52ef1afdee22
> >
> > Yes, that's the patch. Could you make sure that the GPT8 interrupt is
> generated before acking MMU fault interrupt?
>
> I'll try tomorrow when I have access to the hw.
>
> >> I tried to backport it to minimize the changes to a reproducible
> >> test-case. I guess in the l-o branch the commit would be dd1fd0b.
> >> Unfortunately that didn't fix the corruption. So I don't by that GPT8
> >> theory.
> >>
> >> > - we don't need allocate memory for dummy_va_addr, if some patch
> should
> >> be created should be the patch to remove dummy_va_addr allocation and
> >> deletion.
> >>
> >> I tried that, and that actually fixes the corruption for me (passing 0
> >> to hw_mmu_tlb_add).
> >
> > I think first page DSP side memory is never mapped to MPU side, so even
> if the DSP corrupts that page it does not affect MPU side. However the
> right solution is the one explained before: avoid DSP continues executing
> after MMUfault.
>
> First of all, what is the DSP supposed to do with that memory? Do we
> really need to call hw_mmu_tlb_add at all?
Once DSP MMUfault happens iva mmu module prevents DSP continue executing until
mmu module is able get some physical address for the virtual address that the
dsp wanted to access. Once mmu fault interrupt is acked the mmu module tries to
translate the virtual address again and if it gets the physical address DSP
continue executing. So in order to DSP can dumps its stack we need to map some
physical address to that virtual address, so that mmu release DSP and it can
dumps the stack. Therefore we allocate some dummy buffer of one 4K page and get
the physical address of that buffer and use that physical address to fill the
tbl on the mmu module using hw_mmu_tlb_add function.
However the address returned by kmalloc is not page aling, that's means this
mpu virtual address has some offset, for examples in the log that were send the
dummy address had an offset of 0x080 and the DSP side virtual memory had an
offset of 0x040. base on the offset of the MPU side and as we allocate one page
that means we can access from 0x080 - 0xfff of the first page and from 0x000 -
0x080 if the second page, but we always allocate the first page to the DSP
side, then DSP access to the address it wanted to access and now there is no
mmufault but it is accessing (actually writing because reading not cause
corruption) to that page but with a offset of 0x040 causing the corruption.
Using get_user_pages fixes that case because as it returns address page aligned
the DSP side can access from 0x000 - 0xfff of that page.
However this is not the right solution because lets suppose if DSP side virtual
address offset is 0xfff. So we map a page and DSP can access that page from
0x000 - 0xfff, however is the DSP is able to continue executing it will reach
the following page and maybe that page is already mapped but it only can access
from an specific offset like for example 0x100, in this ca DSP will still
corrupt from 0x000 to 0x0ff of the next page.
Let me recheck the changes I and will let you my findings.
Regards,
Fernando.
>
> We really, absolutely want the DSP to don't corrupt memory on ARM
> side, so if we pass something, it should be full pages.
>
> Sure, it would be nice to wait for the DSP to stop, but if for some
> reason it doesn't, we need to know that the DSP doesn't have the power
> to corrupt memory.
>
> Now, I went back to commit 72110f1 and tried the patch you mentioned.
> There's no GPT8 involved, and I cannot reproduce any corruption on a
> beagleboard.
>
> --- a/drivers/dsp/bridge/wmd/ue_deh.c
> +++ b/drivers/dsp/bridge/wmd/ue_deh.c
> @@ -193,6 +193,7 @@ void bridge_deh_notify(struct deh_mgr *hdeh_mgr,
> u32 ulEventMask, u32 dwErrInfo)
> &resources);
>
> if (MEM_IS_VALID_HANDLE(deh_mgr_obj, SIGNATURE)) {
> + void *temp1, *temp2;
> printk(KERN_INFO
>"bridge_deh_notify: ** DEVICE EXCEPTION &qu
Re: [PATCH] DSPBRIDGE:Fix Kernel memory poison overwritten after DSP_MMUFAULT
On Thu, May 13, 2010 at 12:09 AM, Guzman Lugo, Fernando
wrote:
>> If you are referring to this patch:
>> http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-
>> 2.6.git;a=commit;h=26ad62f03578a12e942d8bb86d0e52ef1afdee22
>
> Yes, that's the patch. Could you make sure that the GPT8 interrupt is
> generated before acking MMU fault interrupt?
I'll try tomorrow when I have access to the hw.
>> I tried to backport it to minimize the changes to a reproducible
>> test-case. I guess in the l-o branch the commit would be dd1fd0b.
>> Unfortunately that didn't fix the corruption. So I don't by that GPT8
>> theory.
>>
>> > - we don't need allocate memory for dummy_va_addr, if some patch should
>> be created should be the patch to remove dummy_va_addr allocation and
>> deletion.
>>
>> I tried that, and that actually fixes the corruption for me (passing 0
>> to hw_mmu_tlb_add).
>
> I think first page DSP side memory is never mapped to MPU side, so even if
> the DSP corrupts that page it does not affect MPU side. However the right
> solution is the one explained before: avoid DSP continues executing after
> MMUfault.
First of all, what is the DSP supposed to do with that memory? Do we
really need to call hw_mmu_tlb_add at all?
We really, absolutely want the DSP to don't corrupt memory on ARM
side, so if we pass something, it should be full pages.
Sure, it would be nice to wait for the DSP to stop, but if for some
reason it doesn't, we need to know that the DSP doesn't have the power
to corrupt memory.
Now, I went back to commit 72110f1 and tried the patch you mentioned.
There's no GPT8 involved, and I cannot reproduce any corruption on a
beagleboard.
--- a/drivers/dsp/bridge/wmd/ue_deh.c
+++ b/drivers/dsp/bridge/wmd/ue_deh.c
@@ -193,6 +193,7 @@ void bridge_deh_notify(struct deh_mgr *hdeh_mgr,
u32 ulEventMask, u32 dwErrInfo)
&resources);
if (MEM_IS_VALID_HANDLE(deh_mgr_obj, SIGNATURE)) {
+ void *temp1, *temp2;
printk(KERN_INFO
"bridge_deh_notify: ** DEVICE EXCEPTION "
"**\n");
@@ -227,8 +228,11 @@ void bridge_deh_notify(struct deh_mgr *hdeh_mgr,
u32 ulEventMask, u32 dwErrInfo)
printk(KERN_INFO
"bridge_deh_notify: DSP_MMUFAULT, fault "
"address = 0x%x\n", (unsigned int)fault_addr);
- dummy_va_addr =
- (u32) mem_calloc(sizeof(char) * 0x1000, MEM_PAGED);
+ temp1 = kmalloc(0x10, GFP_ATOMIC);
+ temp2 = kmalloc(0x1000, GFP_ATOMIC);
+ kfree(temp1);
+ kfree(temp2);
+ dummy_va_addr = (u32) kmalloc(0x1000, GFP_ATOMIC);
mem_physical =
VIRT_TO_PHYS(PG_ALIGN_LOW
((u32) dummy_va_addr, PG_SIZE4K));
Is there anything special I should do?
Also, wouldn't it be easier to trigger this by doing:
printk(KERN_INFO
"bridge_deh_notify: DSP_MMUFAULT, fault "
"address = 0x%x\n", (unsigned int)fault_addr);
- dummy_va_addr =
- (u32) mem_calloc(sizeof(char) * 0x1000, MEM_PAGED);
+ temp1 = kmalloc(0x10, GFP_ATOMIC);
+ temp2 = kmalloc(0x1000, GFP_ATOMIC);
+ kfree(temp1);
mem_physical =
VIRT_TO_PHYS(PG_ALIGN_LOW
-((u32) dummy_va_addr, PG_SIZE4K));
+((u32) temp2, PG_SIZE4K));
+ kfree(temp2);
dev_context = (struct wmd_dev_context *)
deh_mgr_obj->hwmd_context;
/* Reset the dynamic mmu index to fixed count if it
Cheers.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] DSPBRIDGE:Fix Kernel memory poison overwritten after DSP_MMUFAULT
Hi, > -Original Message- > From: Felipe Contreras [mailto:felipe.contre...@gmail.com] > Sent: Wednesday, May 12, 2010 2:39 PM > To: Guzman Lugo, Fernando > Cc: Chitriki Rudramuni, Deepak; linux-omap; Ameya Palande; Felipe > Contreras; Hiroshi Doyu; Ramirez Luna, Omar; Menon, Nishanth > Subject: Re: [PATCH] DSPBRIDGE:Fix Kernel memory poison overwritten after > DSP_MMUFAULT > > Hi, > > I didn't touch this issue in the hopes that it would be fixed, but > seems it hasn't. > > On Mon, Apr 19, 2010 at 9:25 PM, Guzman Lugo, Fernando > wrote: > > To sum up: > > > > - "DSPBRIDGE:Fix Kernel memory poison overwritten after DSP_MMUFAULT" is > only hidden the problem, we don't need aligned memory in this point, that > patch should be removed if it is already apply. > > > > - There is no need to create a patch for the issue because it is already > indirectly fix with "DSPBRIDGE: MMU-Fault debugging enhancements". > > If you are referring to this patch: > http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap- > 2.6.git;a=commit;h=26ad62f03578a12e942d8bb86d0e52ef1afdee22 Yes, that's the patch. Could you make sure that the GPT8 interrupt is generated before acking MMU fault interrupt? > > I tried to backport it to minimize the changes to a reproducible > test-case. I guess in the l-o branch the commit would be dd1fd0b. > Unfortunately that didn't fix the corruption. So I don't by that GPT8 > theory. > > > - we don't need allocate memory for dummy_va_addr, if some patch should > be created should be the patch to remove dummy_va_addr allocation and > deletion. > > I tried that, and that actually fixes the corruption for me (passing 0 > to hw_mmu_tlb_add). I think first page DSP side memory is never mapped to MPU side, so even if the DSP corrupts that page it does not affect MPU side. However the right solution is the one explained before: avoid DSP continues executing after MMUfault. Regards, Fernando. > > -- > Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] DSPBRIDGE:Fix Kernel memory poison overwritten after DSP_MMUFAULT
Hi, I didn't touch this issue in the hopes that it would be fixed, but seems it hasn't. On Mon, Apr 19, 2010 at 9:25 PM, Guzman Lugo, Fernando wrote: > To sum up: > > - "DSPBRIDGE:Fix Kernel memory poison overwritten after DSP_MMUFAULT" is only > hidden the problem, we don't need aligned memory in this point, that patch > should be removed if it is already apply. > > - There is no need to create a patch for the issue because it is already > indirectly fix with "DSPBRIDGE: MMU-Fault debugging enhancements". If you are referring to this patch: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=26ad62f03578a12e942d8bb86d0e52ef1afdee22 I tried to backport it to minimize the changes to a reproducible test-case. I guess in the l-o branch the commit would be dd1fd0b. Unfortunately that didn't fix the corruption. So I don't by that GPT8 theory. > - we don't need allocate memory for dummy_va_addr, if some patch should be > created should be the patch to remove dummy_va_addr allocation and deletion. I tried that, and that actually fixes the corruption for me (passing 0 to hw_mmu_tlb_add). -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] DSPBRIDGE:Fix Kernel memory poison overwritten after DSP_MMUFAULT
Hi all,
I have found the really issue here:
The problem here is that after MMUFault the DSP is allowed to continue
executing until here revices the message informing about the MMUFault and this
problem since the patches for mailbox migration.
Previous code:
if (DSP_SUCCEEDED(status)) {
hwStatus = HW_MMU_TLBAdd(resources.dwDmmuBase,
memPhysical, faultAddr,
HW_PAGE_SIZE_4KB, 1, &mapAttrs,
HW_SET, HW_SET);
<<>>
}
/* send an interrupt to DSP */
HW_MBOX_MsgWrite(resources.dwMboxBase, MBOX_ARM2DSP,
MBX_DEH_CLASS | MBX_DEH_EMMU);
<<>>
/* Clear MMU interrupt */
HW_MMU_EventAck(resources.dwDmmuBase,
HW_MMU_TRANSLATION_FAULT);
<<>>
However after mailbox migration patches the code looks like:
if (DSP_SUCCEEDED(status)) {
hw_status_obj =
hw_mmu_tlb_add(resources.dw_dmmu_base,
mem_physical, fault_addr,
HW_PAGE_SIZE4KB, 1,
&map_attrs, HW_SET, HW_SET);
}
/* send an interrupt to DSP */
omap_mbox_msg_send(dev_context->mbox,
MBX_DEH_CLASS | MBX_DEH_EMMU);
<<>>
/* Clear MMU interrupt */
hw_mmu_event_ack(resources.dw_dmmu_base,
HW_MMU_TRANSLATION_FAULT);
<<>>
The patch send to linux-omap list (DSPBRIDGE:Fix Kernel memory poison
overwritten after DSP_MMUFAULT) is just hidden the problem. Because in case the
MPU had a lot of work the workqueue execution will be delay even more and the
DSP side could reach the limit of the dummy page allocated and corrupt memory,
or write memory in a downward way and corrupt preview memory maybe already map
but not allowed to DSP write the entry page.
Also the way we are using the dummymemory to allow DSP write/read from that is
not correct. Because the offset of the dummymemory and the offset of the DSP
fault address should be match.
These values are taken from nokia logs:
Fault address: 0x21fa0040
dmm_va_addr: 0xdf16d140
mem_physical: 0x9f16d000
The address returned by kmalloc is 0xccbd2080, so we can write I this buffer
from 0xdf16d140 until the end of the page and in physical memory from
0x9f16d140 until the end of the page. And in the DSP we map 0x9f16d000 <=>
0x21fa and when it tries to write into 0x21fa0040 it is actually writing to
0x9f16d040 corrupting the memory. But in the previous code we did not allowed
to the DSP do anything more after the MMU fault, that why we did not see that
problem before.
The patch "DSPBRIDGE: MMU-Fault debugging enhancements" already sent to
linux-omap list fix this problem indirectly. Now the way to inform about the
MMUFault is not using a mailbox message, instead of we the GTP8 overflow
interrupt.
omap_dm_timer_set_load_start(timer, 0,
0xfffe);
<<>>
/* Wait 80us for timer to overflow */
udelay(80);
/*
* Check interrupt status and
* wait for interrupt
*/
cnt = 0;
while (!(omap_dm_timer_read_status(timer) &
GPTIMER_IRQ_OVERFLOW)) {
if (cnt++ >=
GPTIMER_IRQ_WAIT_MAX_CNT) {
pr_err("%s: GPTimer interrupt"
" failed\n", __func__);
break;
}
}
<<>>>
}
hw_mmu_event_ack(resources->dw_dmmu_base,
HW_MMU_TRANSLATION_FAULT);
<<>>
dump_dsp_stack(deh_mgr_obj->hwmd_context);
omap_dm_timer_disable(timer);
I could reproduce the issue doing some change in the top of "DSPBRIDGE:
MMU-Fault debugging enhancements":
temp1 = kmalloc(0x10, GFP_ATOMIC);
temp2 = kmalloc(0x1000, G
Re: [PATCH] DSPBRIDGE:Fix Kernel memory poison overwritten after DSP_MMUFAULT
Please ignore this patch.
Thanks,
Deepak
Chitriki Rudramuni, Deepak wrote:
kmalloc() does not guarantee page aligned memory always,hence
resulting in virtual addresses not getting aligned to page boundary.
This patch replaces kmalloc() with __get_free_pages() which
allocates kernel memory in terms of PAGES fixing the Kernel
memory corruption after DSP_MMUFAULT.
Signed-off-by: Deepak Chitriki
---
drivers/dsp/bridge/wmd/ue_deh.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/ue_deh.c b/drivers/dsp/bridge/wmd/ue_deh.c
index 14dd8ae..7ed5f60 100644
--- a/drivers/dsp/bridge/wmd/ue_deh.c
+++ b/drivers/dsp/bridge/wmd/ue_deh.c
@@ -239,7 +239,8 @@ void bridge_deh_notify(struct deh_mgr *hdeh_mgr, u32
ulEventMask, u32 dwErrInfo)
"bridge_deh_notify: DSP_MMUFAULT, fault "
"address = 0x%x\n", (unsigned int)fault_addr);
dummy_va_addr =
- (u32) mem_calloc(sizeof(char) * 0x1000, MEM_PAGED);
+ (void *)__get_free_pages(GFP_ATOMIC | __GFP_ZERO,
+0);
mem_physical =
VIRT_TO_PHYS(PG_ALIGN_LOW
((u32) dummy_va_addr, PG_SIZE4K));
@@ -338,6 +339,6 @@ dsp_status bridge_deh_get_info(struct deh_mgr *hdeh_mgr,
*/
void bridge_deh_release_dummy_mem(void)
{
- kfree((void *)dummy_va_addr);
+ free_pages((void *)dummy_va_addr, 0);
dummy_va_addr = 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
