[ARM_LINUX] ioremap() allowing to map system memory...
Hi All I am using ARM based board. In mine, i did the following... void __iomem *tcpm_base = ioremap_nocache(0x03B00000, 10*SZ_3MB); Actually i didnt reserve the 30MB memory @ 0x3B00000. But still the call is succesful and i am able to read the memory. In the logs it is just showing a warning, to fix my driver as i am calling ioremap() on system memory. However if i try to write something on that memory, then only it is calling panic().. Don't you think it should throw panic()while calling the ioremap() itself. Because this sounds like a serious violation... What say? -- With regards, Sandeep Kumar Anantapalli,
On Fri, Mar 1, 2013 at 4:48 PM, sandeep kumar <coolsandyforyou@gmail.com>wrote:
Hi All I am using ARM based board. In mine, i did the following...
void __iomem *tcpm_base = ioremap_nocache(0x03B00000, 10*SZ_3MB);
Actually i didnt reserve the 30MB memory @ 0x3B00000. But still the call is succesful and i am able to read the memory.
In the logs it is just showing a warning, to fix my driver as i am calling ioremap() on system memory.
However if i try to write something on that memory, then only it is calling panic()..
Don't you think it should throw panic()while calling the ioremap() itself. Because this sounds like a serious violation...
What say?
To my knowledge, ioremap is used only to map the device related physical address to kernel virtual address. i.e. this function will only map either device registers or device memory to kernel virtual address. Looks like you are trying to pass the address of physical memory to this function as a parameter and it is screwing up. Please verify. Regards, Prabhu --
With regards, Sandeep Kumar Anantapalli,
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Looks like you are trying to pass the address of physical memory to this function as a parameter and it is screwing up. Yes, i intentionally gave some physical address which is part of system memory. My problem infact is, it is not screwing up. It is allowing me to do that. Its not 'panic'ing
On Fri, Mar 1, 2013 at 4:58 PM, Prabhu nath <gprabhunath@gmail.com> wrote:
On Fri, Mar 1, 2013 at 4:48 PM, sandeep kumar <coolsandyforyou@gmail.com>wrote:
Hi All I am using ARM based board. In mine, i did the following...
void __iomem *tcpm_base = ioremap_nocache(0x03B00000, 10*SZ_3MB);
Actually i didnt reserve the 30MB memory @ 0x3B00000. But still the call is succesful and i am able to read the memory.
In the logs it is just showing a warning, to fix my driver as i am calling ioremap() on system memory.
However if i try to write something on that memory, then only it is calling panic()..
Don't you think it should throw panic()while calling the ioremap() itself. Because this sounds like a serious violation...
What say?
To my knowledge, ioremap is used only to map the device related physical address to kernel virtual address. i.e. this function will only map either device registers or device memory to kernel virtual address.
Looks like you are trying to pass the address of physical memory to this function as a parameter and it is screwing up.
Please verify.
Regards, Prabhu
--
With regards, Sandeep Kumar Anantapalli,
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- With regards, Sandeep Kumar Anantapalli,
In principle, ioremap() will return 0x00000000 if the physical address passed is of memory. I just want you to double check the address you have passed to ioremap(). In my experiment on x86 Desktop machine with 2GB RAM. I passed a physical address 0x63ACD000. As expected it returned 0x00000000. I am running linux version 3.5.1. Regards, Prabhunath G Linux Trainer Bangalore On Fri, Mar 1, 2013 at 5:57 PM, sandeep kumar <coolsandyforyou@gmail.com>wrote:
Looks like you are trying to pass the address of physical memory to this function as a parameter and it is screwing up. Yes, i intentionally gave some physical address which is part of system memory. My problem infact is, it is not screwing up. It is allowing me to do that. Its not 'panic'ing
On Fri, Mar 1, 2013 at 4:58 PM, Prabhu nath <gprabhunath@gmail.com> wrote:
On Fri, Mar 1, 2013 at 4:48 PM, sandeep kumar <coolsandyforyou@gmail.com>wrote:
Hi All I am using ARM based board. In mine, i did the following...
void __iomem *tcpm_base = ioremap_nocache(0x03B00000, 10*SZ_3MB);
Actually i didnt reserve the 30MB memory @ 0x3B00000. But still the call is succesful and i am able to read the memory.
In the logs it is just showing a warning, to fix my driver as i am calling ioremap() on system memory.
However if i try to write something on that memory, then only it is calling panic()..
Don't you think it should throw panic()while calling the ioremap() itself. Because this sounds like a serious violation...
What say?
To my knowledge, ioremap is used only to map the device related physical address to kernel virtual address. i.e. this function will only map either device registers or device memory to kernel virtual address.
Looks like you are trying to pass the address of physical memory to this function as a parameter and it is screwing up.
Please verify.
Regards, Prabhu
--
With regards, Sandeep Kumar Anantapalli,
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- With regards, Sandeep Kumar Anantapalli,
I passed a physical address 0x63ACD000. As expected it returned 0x00000000. I am running linux version 3.5.1. Mine is ARM, i donno about x86. In my case ioremap is successfule and giving an address in ioremap() range of virtual memory map as in http://www.arm.linux.org.uk/developer/memory.txt.
On Sat, Mar 2, 2013 at 4:52 PM, Prabhu nath <gprabhunath@gmail.com> wrote:
In principle, ioremap() will return 0x00000000 if the physical address passed is of memory. I just want you to double check the address you have passed to ioremap(). In my experiment on x86 Desktop machine with 2GB RAM. I passed a physical address 0x63ACD000. As expected it returned 0x00000000. I am running linux version 3.5.1.
Regards, Prabhunath G Linux Trainer Bangalore
On Fri, Mar 1, 2013 at 5:57 PM, sandeep kumar <coolsandyforyou@gmail.com>wrote:
Looks like you are trying to pass the address of physical memory to this function as a parameter and it is screwing up. Yes, i intentionally gave some physical address which is part of system memory. My problem infact is, it is not screwing up. It is allowing me to do that. Its not 'panic'ing
On Fri, Mar 1, 2013 at 4:58 PM, Prabhu nath <gprabhunath@gmail.com>wrote:
On Fri, Mar 1, 2013 at 4:48 PM, sandeep kumar <coolsandyforyou@gmail.com
wrote:
Hi All I am using ARM based board. In mine, i did the following...
void __iomem *tcpm_base = ioremap_nocache(0x03B00000, 10*SZ_3MB);
Actually i didnt reserve the 30MB memory @ 0x3B00000. But still the call is succesful and i am able to read the memory.
In the logs it is just showing a warning, to fix my driver as i am calling ioremap() on system memory.
However if i try to write something on that memory, then only it is calling panic()..
Don't you think it should throw panic()while calling the ioremap() itself. Because this sounds like a serious violation...
What say?
To my knowledge, ioremap is used only to map the device related physical address to kernel virtual address. i.e. this function will only map either device registers or device memory to kernel virtual address.
Looks like you are trying to pass the address of physical memory to this function as a parameter and it is screwing up.
Please verify.
Regards, Prabhu
--
With regards, Sandeep Kumar Anantapalli,
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- With regards, Sandeep Kumar Anantapalli,
-- With regards, Sandeep Kumar Anantapalli,
________________________________
From: coolsandyforyou@gmail.com Date: Sat, 2 Mar 2013 22:48:34 +0530 Subject: Re: [ARM_LINUX] ioremap() allowing to map system memory... To: gprabhunath@gmail.com CC: kernelnewbies@kernelnewbies.org
I passed a physical address 0x63ACD000. As expected it returned 0x00000000. I am running linux version 3.5.1. Mine is ARM, i donno about x86. In my case ioremap is successfule and giving an address in ioremap() range of virtual memory map as in http://www.arm.linux.org.uk/developer/memory.txt.
please give your detail calling example, it is weired that you did not get 0x0 returned. maybe your platform overwirte the arch_ioremap_caller? please double check this. the default implementation for arch_ioremap_caller is as below: void __iomem * (*arch_ioremap_caller)(unsigned long, size_t, unsigned int, void *) = __arm_ioremap_caller; in \arch\arm\mm\ioremap.c, in function __arm_ioremap_pfn_caller: /* * Don't allow RAM to be mapped - this causes problems with ARMv6+ */ if (WARN_ON(pfn_valid(pfn))) return NULL; you should get NULL if you are asking convert a valid memory.
On Sat, Mar 2, 2013 at 4:52 PM, Prabhu nath <gprabhunath@gmail.com<mailto:gprabhunath@gmail.com>> wrote: In principle, ioremap() will return 0x00000000 if the physical address passed is of memory. I just want you to double check the address you have passed to ioremap(). In my experiment on x86 Desktop machine with 2GB RAM. I passed a physical address 0x63ACD000. As expected it returned 0x00000000. I am running linux version 3.5.1.
Regards, Prabhunath G Linux Trainer Bangalore
On Fri, Mar 1, 2013 at 5:57 PM, sandeep kumar <coolsandyforyou@gmail.com<mailto:coolsandyforyou@gmail.com>> wrote:
Looks like you are trying to pass the address of physical memory to this function as a parameter and it is screwing up. Yes, i intentionally gave some physical address which is part of system memory. My problem infact is, it is not screwing up. It is allowing me to do that. Its not 'panic'ing
On Fri, Mar 1, 2013 at 4:58 PM, Prabhu nath <gprabhunath@gmail.com<mailto:gprabhunath@gmail.com>> wrote:
On Fri, Mar 1, 2013 at 4:48 PM, sandeep kumar <coolsandyforyou@gmail.com<mailto:coolsandyforyou@gmail.com>> wrote: Hi All I am using ARM based board. In mine, i did the following...
void __iomem *tcpm_base = ioremap_nocache(0x03B00000, 10*SZ_3MB);
Actually i didnt reserve the 30MB memory @ 0x3B00000. But still the call is succesful and i am able to read the memory.
In the logs it is just showing a warning, to fix my driver as i am calling ioremap() on system memory.
However if i try to write something on that memory, then only it is calling panic()..
Don't you think it should throw panic()while calling the ioremap() itself. Because this sounds like a serious violation...
What say?
To my knowledge, ioremap is used only to map the device related physical address to kernel virtual address. i.e. this function will only map either device registers or device memory to kernel virtual address.
Looks like you are trying to pass the address of physical memory to this function as a parameter and it is screwing up.
Please verify.
Regards, Prabhu
-- With regards, Sandeep Kumar Anantapalli,
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org<mailto:Kernelnewbies@kernelnewbies.org> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- With regards, Sandeep Kumar Anantapalli,
-- With regards, Sandeep Kumar Anantapalli,
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
please give your detail calling example, it is weired that you did not get 0x0 returned.
I have the following code like below. In my case it is not returning NULL. /* * Don't allow RAM to be mapped - this causes problems with ARMv6+ */ if (pfn_valid(pfn)) { printk(KERN_WARNING "BUG: Your driver calls ioremap() on system memory. This leads\n" KERN_WARNING "to architecturally unpredictable behaviour on ARMv6+, and ioremap()\n" KERN_WARNING "will fail in the next kernel release. Please fix your driver.\n"); WARN_ON(1); } Thanks Sandeep On Mon, Mar 4, 2013 at 1:32 PM, buyitian <buyit@live.cn> wrote:
________________________________
From: coolsandyforyou@gmail.com Date: Sat, 2 Mar 2013 22:48:34 +0530 Subject: Re: [ARM_LINUX] ioremap() allowing to map system memory... To: gprabhunath@gmail.com CC: kernelnewbies@kernelnewbies.org
I passed a physical address 0x63ACD000. As expected it returned 0x00000000. I am running linux version 3.5.1. Mine is ARM, i donno about x86. In my case ioremap is successfule and giving an address in ioremap() range of virtual memory map as in http://www.arm.linux.org.uk/developer/memory.txt.
please give your detail calling example, it is weired that you did not get 0x0 returned.
maybe your platform overwirte the arch_ioremap_caller? please double check this. the default implementation for arch_ioremap_caller is as below: void __iomem * (*arch_ioremap_caller)(unsigned long, size_t, unsigned int, void *) = __arm_ioremap_caller;
in \arch\arm\mm\ioremap.c, in function __arm_ioremap_pfn_caller:
/* * Don't allow RAM to be mapped - this causes problems with ARMv6+ */ if (WARN_ON(pfn_valid(pfn))) return NULL;
you should get NULL if you are asking convert a valid memory.
On Sat, Mar 2, 2013 at 4:52 PM, Prabhu nath <gprabhunath@gmail.com<mailto:gprabhunath@gmail.com>> wrote: In principle, ioremap() will return 0x00000000 if the physical address passed is of memory. I just want you to double check the address you have passed to ioremap(). In my experiment on x86 Desktop machine with 2GB RAM. I passed a physical address 0x63ACD000. As expected it returned 0x00000000. I am running linux version 3.5.1.
Regards, Prabhunath G Linux Trainer Bangalore
On Fri, Mar 1, 2013 at 5:57 PM, sandeep kumar <coolsandyforyou@gmail.com<mailto:coolsandyforyou@gmail.com>> wrote:
Looks like you are trying to pass the address of physical memory to this function as a parameter and it is screwing up. Yes, i intentionally gave some physical address which is part of system memory. My problem infact is, it is not screwing up. It is allowing me to do that. Its not 'panic'ing
On Fri, Mar 1, 2013 at 4:58 PM, Prabhu nath <gprabhunath@gmail.com<mailto:gprabhunath@gmail.com>> wrote:
On Fri, Mar 1, 2013 at 4:48 PM, sandeep kumar <coolsandyforyou@gmail.com<mailto:coolsandyforyou@gmail.com>> wrote: Hi All I am using ARM based board. In mine, i did the following...
void __iomem *tcpm_base = ioremap_nocache(0x03B00000, 10*SZ_3MB);
Actually i didnt reserve the 30MB memory @ 0x3B00000. But still the call is succesful and i am able to read the memory.
In the logs it is just showing a warning, to fix my driver as i am calling ioremap() on system memory.
However if i try to write something on that memory, then only it is calling panic()..
Don't you think it should throw panic()while calling the ioremap() itself. Because this sounds like a serious violation...
What say?
To my knowledge, ioremap is used only to map the device related physical address to kernel virtual address. i.e. this function will only map either device registers or device memory to kernel virtual address.
Looks like you are trying to pass the address of physical memory to this function as a parameter and it is screwing up.
Please verify.
Regards, Prabhu
-- With regards, Sandeep Kumar Anantapalli,
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org<mailto:Kernelnewbies@kernelnewbies.org> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- With regards, Sandeep Kumar Anantapalli,
-- With regards, Sandeep Kumar Anantapalli,
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- With regards, Sandeep Kumar Anantapalli,
On Fri, 01 Mar 2013 16:48:12 +0530, sandeep kumar said:
Don't you think it should throw panic()while calling the ioremap() itself. Because this sounds like a serious violation...
As you noted, it does give you a warning. That's a kernel design philosophy - to reserve the panic() and BUG() calls for cases where it is *known* that proceeding further is unsafe or impossible. So the kernel does a panic() if it can't start /sbin/init at system boot-up - because without that, further progress is impossible. But once the system is up, we don't panic if PID 1 goes away - because it's possible that the user has an open window, and can su and at least do an orderly shutdown. Similarly, if a device driver gets confused, the driver code may do a BUG_ON() and end up locking up that device because to do anything else may scramble the disk further. But we don't panic() because that will basically wedge the system - and the user loses any chance at dumping the dmesg buffer for debugging or other attempts at an orderly shutdown (in particular, panic() won't sync the filesystems. So even though a BUG() often kills a thread while it holds an important lock, which often leads to the system eventually deadlocking one process at a time, it's still a net win if it doesn't panic but lets the user at least try to run sync. And even BUG_ON() is frowned upon if further progress in a degraded mode is possible (for instance, a networking error that totally locks up one TCP connection, but other connections are still working) - at that point, warn() is the correct thing to do. As in this case - it *is* a serious violation, but the kernel (a) can at least possibly keep going and (b) it's at least possible that the user can recover from it. There's a *very* good chance that if the kernel just does a warn(), the user will say "*facepalm* Stupid typo in the address", fix the typo, and re-try with the correct address. So that's the design philosophy of why it gives you a warning rather than a panic.
On Mar 01 2013, Valdis.Kletnieks@vt.edu wrote:
X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.4-dev
On Fri, 01 Mar 2013 16:48:12 +0530, sandeep kumar said:
Don't you think it should throw panic()while calling the ioremap() itself. Because this sounds like a serious violation...
As you noted, it does give you a warning.
That's a kernel design philosophy - to reserve the panic() and BUG() calls for cases where it is *known* that proceeding further is unsafe or impossible. So the kernel does a panic() if it can't start /sbin/init at system boot-up - because without that, further progress is impossible. But once the system is up, we don't panic if PID 1 goes away - because it's possible that the user has an open window, and can su and at least do an orderly shutdown.
[snippage]
So that's the design philosophy of why it gives you a warning rather than a panic.
Great explanation. Thank you. I figured it would be something vaguely like this, but I'm very new to the *linux* kernel, so I wasn't going to try to answer. -- Arlie (Arlie Stephens arlie@worldash.org)
participants (5)
-
Arlie Stephens -
buyitian -
Prabhu nath -
sandeep kumar -
Valdis.Kletnieks＠vt.edu