Messages in this thread | | | Date | Tue, 16 Sep 2003 14:03:58 +0200 | From | Andries Brouwer <> | Subject | Re: [CHECKER] 32 Memory Leaks on Error Paths |
| |
On Mon, Sep 15, 2003 at 09:35:46PM -0700, David Yu Chen wrote:
> I'm with the Stanford Meta-level Compilation research group, and I > have a set of memory leaks on error paths for the 2.6.0-test5 kernel.
There is no memory leak in the below:
> --------------------------------------------------------- > > [FILE: 2.6.0-test5/drivers/char/vt_ioctl.c] > [FUNC: do_kdsk_ioctl] > [LINES: 133-150] > [VAR: key_map] > 128: > 129: if (keymap_count >= MAX_NR_OF_USER_KEYMAPS && > 130: !capable(CAP_SYS_RESOURCE)) > 131: return -EPERM; > 132: > START --> > 133: key_map = (ushort *) kmalloc(sizeof(plain_map), > 134: GFP_KERNEL); > 135: if (!key_map) > 136: return -ENOMEM; > 137: key_maps[s] = key_map; > 138: key_map[0] = U(K_ALLOCATED); > ... DELETED 6 lines ... > 145: break; /* nothing to do */ > 146: /* > 147: * Attention Key. > 148: */ > 149: if (((ov == K_SAK) || (v == K_SAK)) && !capable(CAP_SYS_ADMIN)) > END --> > 150: return -EPERM; > 151: key_map[i] = U(v); > 152: if (!s && (KTYP(ov) == KT_SHIFT || KTYP(v) == KT_SHIFT)) > 153: compute_shiftstate(); > 154: break; > 155: }
Explanation: The user may have up to 256 keymaps, namely the plain map and various maps for (combinations of) modifier keys. In order to save memory, most of these keymaps will not be allocated. If one sets an entry on a keymap, then first the keymap itself is allocated in case it did not exist yet. Then the entry is filled, assuming one has permission. On the error path the memory is not lost: the pointer was stored in the array key_maps[], so also am automatic checker could see that. (And indeed, it is also possible to deallocate keymaps.)
Andries
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |