1. 02 2月, 2010 2 次提交
  2. 31 1月, 2010 1 次提交
  3. 27 1月, 2010 1 次提交
  4. 21 1月, 2010 2 次提交
    • G
      tty: fix race in tty_fasync · 70362511
      Greg Kroah-Hartman 提交于
      We need to keep the lock held over the call to __f_setown() to
      prevent a PID race.
      
      Thanks to Al Viro for pointing out the problem, and to Travis for
      making us look here in the first place.
      
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Al Viro <viro@ZenIV.linux.org.uk>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Tavis Ormandy <taviso@google.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Julien Tinnes <jln@google.com>
      Cc: Matt Mackall <mpm@selenic.com>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      70362511
    • A
      nozomi: quick fix for the close/close bug · eeec32a7
      Alan Cox 提交于
      Nozomi goes wrong if you get the sequence
      
      	open
      	open
      	close
      
      	[stuff]
      	close
      
      which turns out to occur on some ppp type setups.
      
      This is a quick patch up for the problem. It's not really fixing Nozomi
      which completely fails to implement tty open/close semantics and all the
      other needed stuff. Doing it right is a rather more invasive patch set and
      not one that will backport.
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      eeec32a7
  5. 17 1月, 2010 1 次提交
  6. 16 1月, 2010 1 次提交
  7. 15 1月, 2010 1 次提交
  8. 13 1月, 2010 1 次提交
  9. 11 1月, 2010 3 次提交
  10. 05 1月, 2010 2 次提交
  11. 30 12月, 2009 2 次提交
    • F
      x86/agp: Fix agp_amd64_init() initialization with CONFIG_GART_IOMMU enabled · f405d2c0
      FUJITA Tomonori 提交于
      with CONFIG_GART_IOMMU enabled drivers/char/agp/amd64-agp.c has:
      
       #ifndef CONFIG_GART_IOMMU
       module_init(agp_amd64_init);
       module_exit(agp_amd64_cleanup);
       #endif
      
      agp_amd64_init() was called via gart_iommu_init with
      CONFIG_GART_IOMMU=y agp_amd64_init() was called via module_init
      with CONFIG_GART_IOMMU=n
      
      The commit 75f1cdf1 changes the
      x86 dma initialization routine: gart_iommu_init() is called only
      when GART IOMMU is detected. So when GART IOMMU isn't detected,
      agp_amd64_init isn't called.
      
      Marin Mitov reported this issue:
      
       http://marc.info/?l=linux-kernel&m=126192729110083&w=2
      
      With this patch, agp_amd64_init() is always called via
      module_init (the above ifndef is removed). If agp_amd64_init()
      is called via gart_iommu_init() earlier, agp_amd64_init()
      finishes without doing anything (when it is called via
      module_init).
      Reported-by: NMarin Mitov <mitov@issp.bas.bg>
      Tested-by: NMarin Mitov <mitov@issp.bas.bg>
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: davej@redhat.com
      LKML-Reference: <20091228181118C.fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f405d2c0
    • I
      ACPI: fix ACPI=n allmodconfig build · 27d0567a
      Ingo Molnar 提交于
      Today's -tip failed to build because commit
      9e368fa0 ("ipmi: add PNP discovery (ACPI
      namespace via PNPACPI)") from today's upstream kernel causes the following
      build failure on x86, for CONFIG_ACPI=n && CONFIG_IPMI_SI=y:
      
       drivers/char/ipmi/ipmi_si_intf.c:3208: error: 'ipmi_pnp_driver' undeclared (first use in this function)
       drivers/char/ipmi/ipmi_si_intf.c:3208: error: (Each undeclared identifier is reported only once
       drivers/char/ipmi/ipmi_si_intf.c:3208: error: for each function it appears in.)
       drivers/char/ipmi/ipmi_si_intf.c:3334: error: 'ipmi_pnp_driver' undeclared (first use in this function)
      
      The reason is that the ipmi_pnp_driver depends on ACPI facilities and is only
      made available under ACPI - while the registration and unregistration is made
      dependent on CONFIG_PNP:
      
       #ifdef CONFIG_PNP
       	pnp_register_driver(&ipmi_pnp_driver);
       #endif
      
      The solution is to only register this driver under ACPI. (Also, the CONFIG_PNP
      dependency is not needed because pnp_register_driver() is stubbed out in the
      !CONFIG_PNP case.)
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NMyron Stowe <myron.stowe@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      27d0567a
  12. 23 12月, 2009 6 次提交
  13. 20 12月, 2009 1 次提交
  14. 16 12月, 2009 16 次提交