summaryrefslogtreecommitdiffstats
path: root/init/initramfs.c
diff options
context:
space:
mode:
authorPeter Staubach <staubach@redhat.com>2005-09-13 01:25:12 -0700
committerLinus Torvalds <torvalds@g5.osdl.org>2005-09-13 08:22:28 -0700
commita1a5b3d93ca45613ec1d920fdb131b69b6553882 (patch)
tree19b5a05aca27f3f2ef1dc2169ce6c521ddfa8468 /init/initramfs.c
parent873d3469db66ea08e94b0d04a96b1a4507684824 (diff)
downloadop-kernel-dev-a1a5b3d93ca45613ec1d920fdb131b69b6553882.zip
op-kernel-dev-a1a5b3d93ca45613ec1d920fdb131b69b6553882.tar.gz
[PATCH] open returns ENFILE but creates file anyway
When open(O_CREAT) is called and the error, ENFILE, is returned, the file may be created anyway. This is counter intuitive, against the SUS V3 specification, and may cause applications to misbehave if they are not coded correctly to handle this semantic. The SUS V3 specification explicitly states "No files shall be created or modified if the function returns -1.". The error, ENFILE, is used to indicate the system wide open file table is full and no more file structs can be allocated. This is due to an ordering problem. The entry in the directory is created before the file struct is allocated. If the allocation for the file struct fails, then the system call must return an error, but the directory entry was already created and can not be safely removed. The solution to this situation is relatively easy. The file struct should be allocated before the directory entry is created. If the allocation fails, then the error can be returned directly. If the creation of the directory entry fails, then the file struct can be easily freed. Signed-off-by: Peter Staubach <staubach@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'init/initramfs.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud