Re: [PATCH libibverbs] memory: use SCNxPTR format to read uintptr_t values

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Le mercredi 11 juillet 2012 à 08:47 -0700, Roland Dreier a écrit :
> On Wed, Jul 11, 2012 at 8:10 AM, Yann Droneaud <ydroneaud@xxxxxxxxxx> wrote:
> > @@ -116,7 +117,7 @@ static unsigned long get_page_size(void *base)
> >                 int n;
> >                 uintptr_t range_start, range_end;
> >
> > -               n = sscanf(buf, "%lx-%lx", &range_start, &range_end);
> > +               n = sscanf(buf, "%" SCNxPTR "-%" SCNxPTR, &range_start, &range_end);
> >
> >                 if (n < 2)
> >                         continue;
> 
> Looks fine in itself, and I don't necessarily expect you to be the one
> to answer, but:
> 
>  - what does /proc/<pid>/maps show when running a 32-bit process on a 64-bit
>    kernel?  Should we be using uint64_t / SCNx64?  (but surely 32-bit processes
>    are guaranteed to have all their mappings fit into 32 bits)
> 

"maps" file is presented to 32bits process as a 32bits mapping.

>  - earlier in this function, why do we do /proc/%d/maps, getpid()?  Why doesn't
>    /proc/self/maps always work?
> 

I think /proc/self/maps would always work here.

Using explicitly the pid could be of use for the child to read its
parent mapping.

Regards

-- 
Yann Droneaud
OPTEYA


--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux