Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 16 3月, 2012 1 次提交
  3. 05 1月, 2012 1 次提交
    • Z
      tty: Fix memory leak in virtual console when enable unicode translation · 106b5fa7
      由 Zeng Zhaoming 提交于 
      Virtual console unicode translation map leaks with following
message when enable kmemleak:

unreferenced object 0xeb5ec450 (size 192):
  comm "setfont", pid 665, jiffies 4294899028 (age 3696.220s)
  hex dump (first 32 bytes):
    e0 5b 9d eb 00 00 00 00 00 00 00 00 80 b9 ea eb  .[..............
    b0 5a 9d eb 00 00 00 00 00 00 00 00 00 00 00 00  .Z..............
  backtrace:
    [<c1533f8c>] kmemleak_alloc+0x3c/0xa0
    [<c114acc2>] kmem_cache_alloc_trace+0xe2/0x250
    [<c13498e8>] con_clear_unimap+0x78/0xd0
    [<c1345552>] vt_ioctl+0x1562/0x1d00
    [<c133aa00>] tty_ioctl+0x230/0x7c0
    [<c1171519>] do_vfs_ioctl+0x79/0x2d0
    [<c11717df>] sys_ioctl+0x6f/0x80
    [<c156601f>] sysenter_do_call+0x12/0x38
    [<ffffffff>] 0xffffffff
unreferenced object 0xeb9d5be0 (size 128):
  comm "setfont", pid 660, jiffies 4294899030 (age 3696.212s)
  hex dump (first 32 bytes):
    60 c2 a6 eb 50 c8 a6 eb c0 54 9d eb 80 59 9d eb  `...P....T...Y..
    90 53 9d eb 60 52 9d eb 60 92 9b eb 00 00 00 00  .S..`R..`.......
  backtrace:
    [<c1533f8c>] kmemleak_alloc+0x3c/0xa0
    [<c114acc2>] kmem_cache_alloc_trace+0xe2/0x250
    [<c134938c>] con_insert_unipair+0x7c/0x150
    [<c1349f8c>] con_set_unimap+0x15c/0x1f0
    [<c13456fb>] vt_ioctl+0x170b/0x1d00
    [<c133aa00>] tty_ioctl+0x230/0x7c0
    [<c1171519>] do_vfs_ioctl+0x79/0x2d0
    [<c11717df>] sys_ioctl+0x6f/0x80
    [<c156601f>] sysenter_do_call+0x12/0x38
    [<ffffffff>] 0xffffffff

The leak caused by con_set_default_unimap() not correct free the old map.
Signed-off-by: NZeng Zhaoming <zengzm.kernel@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      106b5fa7
  5. 05 11月, 2010 1 次提交
  7. 07 1月, 2009 1 次提交
  9. 30 4月, 2008 1 次提交
  11. 17 10月, 2007 2 次提交
  13. 17 7月, 2007 1 次提交
  15. 09 5月, 2007 1 次提交
    • E
      console UTF-8 fixes · 2f1a2ccb
      由 Egmont Koblinger 提交于 
      The UTF-8 part of the vt driver suffers from the following issues which are
addressed in my patch:

1) If there's no glyph found for a particular valid UTF-8 character, we try
   to display U+FFFD. However if this one is not found either, here's what
   the current kernel does:

   - First, if the Unicode value is less than the number of glyphs, use the
     glyph directly from that position of the glyph table. While it may be a
     good idea in the 8-bit world, it has absolutely no sense with Unicode
     in mind. For example, if a Latin-2 font is loaded and an application
     prints U+00FB ("u with circumflex", not present in Latin-2) then as a
     fallback solution the glyph from the 0xFB position of the Latin-2
     fontset (which is an "u with double accent" - a different character) is
     displayed.

   - Second, if this fallback fails too, a simple ASCII question mark is
     printed, which is visually undistinguishable from a real question mark.

   I changed the code to skip the first step (except if in non-UTF-8 mode),
   and changed the second step to print the question mark with inverse color
   attributes, so it is visually clear that it's not a real question mark,
   and resembles more to the common glyph of U+FFFD.

2) The UTF-8 decoder is buggy in many ways:

   - Lone continuation bytes (section 3.1 of Markus Kuhn's UTF-8 stress
     test) are not caught, they are displayed as some "random" (taken
     directly form the font table, see above) glyphs instead the replacement
     character.

   - Incomplete sequences (sections 3.2 and 3.3 of the stress test) emit no
     replacement character, but rather cause the subsequent valid character
     to be displayed more times(!).

   - The decoder is not safe: overlong sequences are not caught currently,
     they are displayed as if these were valid representations. This may
     even have security impacts.

   - The decoder does not handle D800..DFFF and FFFE..FFFF specially, it
     just emits these code points and lets it be looked up in the glyph
     table. Since these are invalid code points, I replace them by U+FFFD
     and hence give no chance for them to be looked up in the glyph table.
     (Assuming no font ships glyphs for these code points, this change is
     not visible to the users since the glyph shown will be the same.)

   With my fixes to the decoder it now behaves exactly as Markus Kuhn's
   stress test recommends.

3) It has no concept of double-width (CJK) characters. It's way beyond the
   scope of my patch to try to display them, but at least I think it's
   important for the cursor to jump two positions when printing such
   characters, since this is what applications (such as text editors)
   expect. Currently the cursor only jumps one position, and hence
   applications suffer from displaying and refreshing problems, and editing
   some English letters that are preceded by some CJK characters in the same
   line is a nightmare. With my patch an additional space is inserted after
   the CJK character has been printed (which usually means a replacement
   symbol of course). (If U+FFFD isn't availble and hence an inverse
   question mark is displayed in the first cell, I keep the inverted state
   for the space in the 2nd column so it's quite easy to see that they are
   tied together.)

4) There is a small built-in table of zero-width spaces that are not to be
   printed but silently skipped. U+200A is included there, but it's not a
   zero-width character, so I remove it from there.
Signed-off-by: NEgmont Koblinger <egmont@uhulinux.hu>
Cc: Jan Engelhardt <jengelh@linux01.gwdg.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2f1a2ccb
  17. 14 12月, 2006 1 次提交
    • R
      [PATCH] getting rid of all casts of k[cmz]alloc() calls · 5cbded58
      由 Robert P. J. Day 提交于 
      Run this:

	#!/bin/sh
	for f in $(grep -Erl "\([^\)]*\) *k[cmz]alloc" *) ; do
	  echo "De-casting $f..."
	  perl -pi -e "s/ ?= ?\([^\)]*\) *(k[cmz]alloc) *\(/ = \1\(/" $f
	done

And then go through and reinstate those cases where code is casting pointers
to non-pointers.

And then drop a few hunks which conflicted with outstanding work.

Cc: Russell King <rmk@arm.linux.org.uk>, Ian Molton <spyro@f2s.com>
Cc: Mikael Starvik <starvik@axis.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Roman Zippel <zippel@linux-m68k.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Kyle McMartin <kyle@mcmartin.ca>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Greg KH <greg@kroah.com>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: Paul Fulghum <paulkf@microgate.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Karsten Keil <kkeil@suse.de>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: James Bottomley <James.Bottomley@steeleye.com>
Cc: Ian Kent <raven@themaw.net>
Cc: Steven French <sfrench@us.ibm.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Neil Brown <neilb@cse.unsw.edu.au>
Cc: Jaroslav Kysela <perex@suse.cz>
Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5cbded58
  19. 01 7月, 2006 1 次提交
  21. 07 11月, 2005 1 次提交
  23. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      由 Linus Torvalds 提交于 
      Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
      1da177e4