[ARM_LINUX] ioremap() allowing to map system memory...

[ARM_LINUX] ioremap() allowing to map system memory...

[sandeep kumar]

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,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130301/47ae0267/attachment.html 

[ARM_LINUX] ioremap() allowing to map system memory...

[Prabhu nath]

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 at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130301/baef5c85/attachment.html 

[ARM_LINUX] ioremap() allowing to map system memory...

[sandeep kumar]

>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 at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>>
>


-- 
With regards,
Sandeep Kumar Anantapalli,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130301/e472ab16/attachment-0001.html 

[ARM_LINUX] ioremap() allowing to map system memory...

[Valdis.Kletnieks at vt.edu]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130301/88ae50b7/attachment.bin 

[ARM_LINUX] ioremap() allowing to map system memory...

[Arlie Stephens]

On Mar 01 2013, Valdis.Kletnieks at 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 at worldash.org)

[ARM_LINUX] ioremap() allowing to map system memory...

[Prabhu nath]

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 at kernelnewbies.org
>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>
>>>
>>
>
>
> --
> With regards,
> Sandeep Kumar Anantapalli,
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130302/15d2391b/attachment.html 

[ARM_LINUX] ioremap() allowing to map system memory...

[sandeep kumar]

>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 at kernelnewbies.org
>>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>>
>>>>
>>>
>>
>>
>> --
>> With regards,
>> Sandeep Kumar Anantapalli,
>>
>
>


-- 
With regards,
Sandeep Kumar Anantapalli,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130302/67f2aab9/attachment.html 

[ARM_LINUX] ioremap() allowing to map system memory...

[buyitian]

________________________________
> From: coolsandyforyou at gmail.com 
> Date: Sat, 2 Mar 2013 22:48:34 +0530 
> Subject: Re: [ARM_LINUX] ioremap() allowing to map system memory... 
> To: gprabhunath at gmail.com 
> CC: kernelnewbies at 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 at 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 at 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 at gmail.com<mailto:gprabhunath@gmail.com>> wrote: 
> 
> 
> On Fri, Mar 1, 2013 at 4:48 PM, sandeep kumar 
> <coolsandyforyou at 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 at 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 at kernelnewbies.org 
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies 		 	   		  

[ARM_LINUX] ioremap() allowing to map system memory...

[sandeep kumar]

>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 at gmail.com
> > Date: Sat, 2 Mar 2013 22:48:34 +0530
> > Subject: Re: [ARM_LINUX] ioremap() allowing to map system memory...
> > To: gprabhunath at gmail.com
> > CC: kernelnewbies at 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 at 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 at 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 at gmail.com<mailto:gprabhunath@gmail.com>> wrote:
> >
> >
> > On Fri, Mar 1, 2013 at 4:48 PM, sandeep kumar
> > <coolsandyforyou at 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 at 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 at kernelnewbies.org
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>



-- 
With regards,
Sandeep Kumar Anantapalli,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130304/ee081dcf/attachment-0001.html