Great! So the problem might have existed for some time, but we never
saw it due to default over commit values? Were you using these values
for over commit even before?
Linux Technology Center
[Balbir Singh - Sun, Aug 12, 2007 at 02:55:32PM +0530]
| WU Fengguang wrote:
| > On Sun, Aug 12, 2007 at 01:48:31PM +0800, WU Fengguang wrote:
| >> On Sat, Aug 11, 2007 at 11:31:09PM +0530, Balbir Singh wrote:
| >>> Andrew Morton wrote:
| >>>> On Sat, 11 Aug 2007 20:00:12 +0530 "Balbir Singh" <email@example.com> wrote:
| >>>>> Shouldn't we just not stop vm accounting for kernel threads?
| >>>> Could be. It'd help heaps if we knew which patch in -mm caused
| >>>> this, but from a quick peek it seems to me that mainline should be
| >>>> vulnerable as well.
| >>> Thats a valid point. It would be interesting to see what the overcommit
| >>> setting was, when the panic occurred.
| >> FYI, I do have nondefault overcommit settings:
| >> vm.overcommit_memory = 2
| >> vm.lowmem_reserve_ratio = 1 1
| > Yes, the bug disappears when changing to default overcommit_memory!
| Great! So the problem might have existed for some time, but we never
| saw it due to default over commit values? Were you using these values
| for over commit even before?
| Warm Regards,
| Balbir Singh
| Linux Technology Center
| IBM, ISTL
So the problem is that __vm_enough_memory is just _not_ capable
to be called from a thread with OVERCOMMIT_NEVER and Fengguang's
patch does fix it. The scenario Fengguang show us is growing
from keventd that starts a new user task. So Fengguang's patch
seems right to me ;)