Wiadomość napisana przez Alan Cox a...@rice.edu w dniu 30 lip 2013, o godz.
19:40:
On Jul 21, 2013, at 2:50 PM, Jeremie Le Hen wrote:
Also, a wired mapping can be destroyed by calling munmap(2) without
first calling munlock(2), in which case, RACCT_MEMLOCK will be
incorrect.
So I think
On Jul 21, 2013, at 2:50 PM, Jeremie Le Hen wrote:
On Sat, Jul 20, 2013 at 08:33:35PM -0700, Alan Cox wrote:
On Jul 20, 2013, at 4:22 AM, Jeremie Le Hen wrote:
Hi Edward, Alan,
I plan to commit the following patch:
http://people.freebsd.org/~jlh/racct_munlock.diff
This solves the
On Sat, Jul 20, 2013 at 08:33:35PM -0700, Alan Cox wrote:
On Jul 20, 2013, at 4:22 AM, Jeremie Le Hen wrote:
Hi Edward, Alan,
I plan to commit the following patch:
http://people.freebsd.org/~jlh/racct_munlock.diff
This solves the following panic:
panic: racct_sub: freeing
Hi Edward, Alan,
I plan to commit the following patch:
http://people.freebsd.org/~jlh/racct_munlock.diff
This solves the following panic:
panic: racct_sub: freeing 301989888 of resource 5, which is more than allocated
73728 for pwsafe (pid 4177)
The problem is that the racct code in
On Jul 20, 2013, at 4:22 AM, Jeremie Le Hen wrote:
Hi Edward, Alan,
I plan to commit the following patch:
http://people.freebsd.org/~jlh/racct_munlock.diff
This solves the following panic:
panic: racct_sub: freeing 301989888 of resource 5, which is more than
allocated 73728 for