Skip to content

L
linux
Switch branch/tag
  1. 26 Nov, 2007 2 commits
    • Pavel Emelyanov's avatar
      [IPV4]: Fix memory leak in inet_hashtables.h when NUMA is on · 218ad12f
      Pavel Emelyanov authored 
      The inet_ehash_locks_alloc() looks like this:

#ifdef CONFIG_NUMA
	if (size > PAGE_SIZE)
		x = vmalloc(...);
	else
#endif
		x = kmalloc(...);

Unlike it, the inet_ehash_locks_alloc() looks like this:

#ifdef CONFIG_NUMA
	if (size > PAGE_SIZE)
		vfree(x);
	else
#else
		kfree(x);
#endif

The error is obvious - if the NUMA is on and the size
is less than the PAGE_SIZE we leak the pointer (kfree is
inside the #else branch).

Compiler doesn't warn us because after the kfree(x) there's
a "x = NULL" assignment, so here's another (minor?) bug: we 
don't set x to NULL under certain circumstances.

Boring explanation, I know... Patch explains it better.
Signed-off-by: default avatarPavel Emelyanov <xemul@openvz.org>
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      218ad12f
    • Herbert Xu's avatar
      [IPSEC]: Temporarily remove locks around copying of non-atomic fields · 8053fc3d
      Herbert Xu authored 
      The change 050f009e

	[IPSEC]: Lock state when copying non-atomic fields to user-space

caused a regression.

Ingo Molnar reports that it causes a potential dead-lock found by the
lock validator as it tries to take x->lock within xfrm_state_lock while
numerous other sites take the locks in opposite order.

For 2.6.24, the best fix is to simply remove the added locks as that puts
us back in the same state as we've been in for years.  For later kernels
a proper fix would be to reverse the locking order for every xfrm state
user such that if x->lock is taken together with xfrm_state_lock then
it is to be taken within it.
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      8053fc3d
  3. 23 Nov, 2007 2 commits
  5. 22 Nov, 2007 5 commits
  7. 21 Nov, 2007 7 commits
  9. 20 Nov, 2007 19 commits
  11. 19 Nov, 2007 3 commits
    • Herbert Xu's avatar
      [TCP]: Fix TCP header misalignment · 21df56c6
      Herbert Xu authored 
      Indeed my previous change to alloc_pskb has made it possible
for the TCP header to be misaligned iff the MTU is not a multiple
of 4 (and less than a page).  So I suspect the optimised IPsec
MTU calculation is giving you just such an MTU :)

This patch fixes it by changing alloc_pskb to make sure that
the size is at least 32-bit aligned.  This does not cause the
problem fixed by the previous patch because max_header is always
32-bit aligned which means that in the SG/NOTSO case this will
be a no-op.

I thought about putting this in the callers but all the current
callers are from TCP.  If and when we get a non-TCP caller we
can always create a TCP wrapper for this function and move the
alignment over there.
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      21df56c6
    • Eric Dumazet's avatar
      [NET]: Corrects a bug in ip_rt_acct_read() · 483b23ff
      Eric Dumazet authored 
      It seems that stats of cpu 0 are counted twice, since
for_each_possible_cpu() is looping on all possible cpus, including 0

Before percpu conversion of ip_rt_acct, we should also remove the
assumption that CPU 0 is online (or even possible)
Signed-off-by: default avatarEric Dumazet <dada1@cosmosbay.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      483b23ff
    • Ivo van Doorn's avatar
      rt2x00: Request usb_maxpacket() once · b242e891
      Ivo van Doorn authored 
      The usb max packet size won't change during the
device's presence. We should store it in a
variable inside rt2x00dev and use that.
This should also fix a division error when the
device is being hot-unplugged while a frame is
being send out.
Signed-off-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      b242e891
  13. 17 Nov, 2007 2 commits
    • Linus Torvalds's avatar
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86 · 2ffbb837
      Linus Torvalds authored 
      * 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86:
  x86: simplify "make ARCH=x86" and fix kconfig all.config
  x86: reboot fixup for wrap2c board
  x86: check boundary in count setup resource
  x86: fix reboot with no keyboard attached
  x86: add hpet sanity checks
  x86: on x86_64, correct reading of PC RTC when update in progress in time_64.c
  x86: fix freeze in x86_64 RTC update code in time_64.c
  ntp: fix typo that makes sync_cmos_clock erratic
  Remove x86 merge artifact from top Makefile
  x86: fixup cpu_info array conversion
  x86: show cpuinfo only for online CPUs
  x86: fix cpu-hotplug regression
  x86: ignore the sys_getcpu() tcache parameter
  x86: voyager use correct header file name
  x86: fix smp init sections
  x86: fix voyager_cat_init section
  x86: fix bogus memcpy in es7000_check_dsdt()
      2ffbb837
    • Sam Ravnborg's avatar
      x86: simplify "make ARCH=x86" and fix kconfig all.config · 6840999b
      Sam Ravnborg authored 
      Simplify "make ARCH=x86" and fix kconfig so we again can set 64BIT in
all.config.

For a fix the diffstat is nice:
 6 files changed, 3 insertions(+), 36 deletions(-)

The patch reverts these commits:
 - 0f855aa6 ("kconfig: add helper to set
   config symbol from environment variable")
 - 2a113281 ("kconfig: use $K64BIT to
   set 64BIT with all*config targets")

Roman Zippel pointed out that kconfig supported string compares so
the additional complexity introduced by the above two patches were
not needed.

With this patch we have following behaviour:

  # make {allno,allyes,allmod,rand}config [ARCH=...]
  option \ host arch      | 32bit         | 64bit
  =====================================================
  ./.                     | 32bit         | 64bit
  ARCH=x86                | 32bit         | 32bit
  ARCH=i386               | 32bit         | 32bit
  ARCH=x86_64             | 64bit         | 64bit

The general rule are that ARCH= and native architecture takes
precedence over the configuration.

So make ARCH=i386 [whatever] will always build a 32-bit kernel
no matter what the configuration says.  The configuration will
be updated to 32-bit if it was configured to 64-bit and the
other way around.

This behaviour is consistent with previous behaviour so no
suprises here.

make ARCH=x86 will per default result in a 32-bit kernel but as
the only ARCH= value x86 allow the user to select between 32-bit
and 64-bit using menuconfig.
Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
Cc: Roman Zippel <zippel@linux-m68k.org>
Cc: Andreas Herrmann <aherrman@arcor.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      6840999b
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7