PROBLEM: kernel memory subsystem incorrectly invokes OOM killer under certain situations

2007-10-14 Thread Chris Drake 
Bus: Intel Corporation 82801CA/CAM SMBus Controller (rev 02)
Subsystem: Intel Corporation: Unknown device 3424
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- SERR- TAbort- SERR- TAbort- 
Reset- FastB2B-
Capabilities: [50] PCI-X bridge device.
Secondary Status: 64bit+, 133MHz+, SCD-, USC-, SCO-, SRD- 
Freq=conv
Status: Bus=2 Dev=29 Func=0 64bit+ 133MHz+ SCD- USC-, SCO-, SRD-
: Upstream: Capacity=65535, Commitment Limit=65535
: Downstream: Capacity=65535, Commitment Limit=65535

02:1e.0 PIC: Intel Corporation 82870P2 P64H2 I/OxAPIC (rev 04) (prog-if 20 
[IO(X)-APIC])
Subsystem: Intel Corporation: Unknown device 3424
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- 
Reset- FastB2B-
Capabilities: [50] PCI-X bridge device.
Secondary Status: 64bit+, 133MHz+, SCD-, USC-, SCO-, SRD- 
Freq=100MHz
Status: Bus=2 Dev=31 Func=0 64bit+ 133MHz+ SCD- USC-, SCO-, SRD-
: Upstream: Capacity=65535, Commitment Limit=65535
: Downstream: Capacity=65535, Commitment Limit=65535

03:04.0 SCSI storage controller: Adaptec AIC-7902 U320 (rev 03)
Subsystem: Intel Corporation: Unknown device 3424
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR-  /proc/sys/vm/oom-kill

Obviously - it's a better idea to hunt down the reason for the
unwarranted call rather than simply making the call do nothing...

At least one Internet posting I found through google suggested this
bug can be used by unprivileged users to kill random privileged
processes on a local machine, so there may be security implications if
this can be verified.



Kind Regards,
Chris Drake

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

PROBLEM: kernel memory subsystem incorrectly invokes OOM killer under certain situations

2007-10-14 Thread Chris Drake 
-
Address:   Data: 

[EMAIL PROTECTED] bin]#

[7.6.] SCSI information (from /proc/scsi/scsi)

[EMAIL PROTECTED] bin]# cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: SONY Model: SDT-11000Rev: 0200
  Type:   Sequential-AccessANSI SCSI revision: 02
Host: scsi2 Channel: 00 Id: 00 Lun: 00
  Vendor: AMCC Model: 9500S-8MI  DISK  Rev: 2.08
  Type:   Direct-AccessANSI SCSI revision: 03
[EMAIL PROTECTED] bin]#


[7.7.] Other information that might be relevant to the problem
   (please look in /proc and include all information that you
   think to be relevant):

[X.] Other notes, patches, fixes, workarounds:

This seems to fix the problem with no side effects:
echo 0  /proc/sys/vm/oom-kill

Obviously - it's a better idea to hunt down the reason for the
unwarranted call rather than simply making the call do nothing...

At least one Internet posting I found through google suggested this
bug can be used by unprivileged users to kill random privileged
processes on a local machine, so there may be security implications if
this can be verified.



Kind Regards,
Chris Drake

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/