* man page mlock/munlock
@ 2015-05-06 8:49 Mehdi Aqadjani Memar
[not found] ` <87k2wm84eo.fsf-oe7qfRrRQfcprfpi5Sxi9A@public.gmane.org>
0 siblings, 1 reply; 3+ messages in thread
From: Mehdi Aqadjani Memar @ 2015-05-06 8:49 UTC (permalink / raw)
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w; +Cc: linux-man-u79uwXL29TY76Z2rM5mHXA
Dear Michael Kerrisk,
in my application I am using munlock() as described in the man page. munlock()
fails and returns ENOMEM. The man page for this error has not helped me to find
out what the problem was. I traced my code and discovered that this error
appears when "the process's maximum number of mappings would have been
exceeded", as it is mentioned at the man page of mmap(). This happens because
munlock() splits the vma's.
I believe that this information should be a part of the man page of munlock().
--
Met vriendelijke groet/Kind regards
Mehdi Aqadjani Memar
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 3+ messages in thread[parent not found: <87k2wm84eo.fsf-oe7qfRrRQfcprfpi5Sxi9A@public.gmane.org>]
* Re: man page mlock/munlock [not found] ` <87k2wm84eo.fsf-oe7qfRrRQfcprfpi5Sxi9A@public.gmane.org> @ 2015-07-21 18:50 ` Michael Kerrisk (man-pages) [not found] ` <CAKgNAkjMuMdu952zj_3kL7cmC-xeRzTzDo_2emxwjEoG+2YVFQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 3+ messages in thread From: Michael Kerrisk (man-pages) @ 2015-07-21 18:50 UTC (permalink / raw) To: Mehdi Aqadjani Memar; +Cc: linux-man Hello Mehdi On 6 May 2015 at 10:49, Mehdi Aqadjani Memar <m.aqadjanimemar-oe7qfRrRQfcprfpi5Sxi9A@public.gmane.org> wrote: > Dear Michael Kerrisk, > in my application I am using munlock() as described in the man page. munlock() > fails and returns ENOMEM. The man page for this error has not helped me to find > out what the problem was. I traced my code and discovered that this error > appears when "the process's maximum number of mappings would have been > exceeded", as it is mentioned at the man page of mmap(). This happens because > munlock() splits the vma's. > I believe that this information should be a part of the man page of munlock(). > -- > Met vriendelijke groet/Kind regards > Mehdi Aqadjani Memar Thanks for the report, and sorry for the delayed response. I've confirmed your point. How would the following text be: ENOMEM Locking or unlocking a region would result in the total number of mappings with distinct attributes (e.g., locked versus unlocked) exceeding the allowed maximum. (For example, unlocking a range in the middle of a currently locked mapping would result in three mappings: two locked mappings at each end and an unlocked mapping in the mid‐ dle.) ? Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3+ messages in thread
[parent not found: <CAKgNAkjMuMdu952zj_3kL7cmC-xeRzTzDo_2emxwjEoG+2YVFQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: man page mlock/munlock [not found] ` <CAKgNAkjMuMdu952zj_3kL7cmC-xeRzTzDo_2emxwjEoG+2YVFQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2015-07-22 6:17 ` Mehdi Aqadjani Memar 0 siblings, 0 replies; 3+ messages in thread From: Mehdi Aqadjani Memar @ 2015-07-22 6:17 UTC (permalink / raw) To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w; +Cc: linux-man Hello Michael, thank you for your reply! Your text has explained the effect of locking and unlocking very well. Regards, Mehdi Michael Kerrisk (man-pages) writes: > Hello Mehdi > > On 6 May 2015 at 10:49, Mehdi Aqadjani Memar > <m.aqadjanimemar-oe7qfRrRQfcprfpi5Sxi9A@public.gmane.org> wrote: >> Dear Michael Kerrisk, >> in my application I am using munlock() as described in the man page. munlock() >> fails and returns ENOMEM. The man page for this error has not helped me to find >> out what the problem was. I traced my code and discovered that this error >> appears when "the process's maximum number of mappings would have been >> exceeded", as it is mentioned at the man page of mmap(). This happens because >> munlock() splits the vma's. >> I believe that this information should be a part of the man page of munlock(). >> -- >> Met vriendelijke groet/Kind regards >> Mehdi Aqadjani Memar > > Thanks for the report, and sorry for the delayed response. I've > confirmed your point. How would the following text be: > > ENOMEM Locking or unlocking a region would result in the total > number of mappings with distinct attributes (e.g., locked > versus unlocked) exceeding the allowed maximum. (For > example, unlocking a range in the middle of a currently > locked mapping would result in three mappings: two locked > mappings at each end and an unlocked mapping in the mid‐ > dle.) > ? > > Thanks, > > Michael -- Met vriendelijke groet/Kind regards Mehdi Aqadjani Memar -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-07-22 6:17 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-05-06 8:49 man page mlock/munlock Mehdi Aqadjani Memar
[not found] ` <87k2wm84eo.fsf-oe7qfRrRQfcprfpi5Sxi9A@public.gmane.org>
2015-07-21 18:50 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkjMuMdu952zj_3kL7cmC-xeRzTzDo_2emxwjEoG+2YVFQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-07-22 6:17 ` Mehdi Aqadjani Memar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).