Bug 4481 - writing to a read-locked file fails silently
writing to a read-locked file fails silently
Status: RESOLVED FIXED
Product: CifsVFS
Classification: Unclassified
Component: kernel fs
2.6
x86 Linux
: P3 normal
: ---
Assigned To: Steve French
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-30 13:15 UTC by Marien Zwart
Modified: 2010-03-31 11:47 UTC (History)
1 user (show)

See Also:


Attachments
part of the server log (19.79 KB, text/plain)
2007-03-30 13:15 UTC, Marien Zwart
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marien Zwart 2007-03-30 13:15:16 UTC
Using the cifs version from the 2.6.20.4 kernel and a 3.0.24 samba server, linux extensions enabled on both ends as far as I can tell, the following python code:

import fcntl
open('bork', 'w').write('borkborkbork')
fro = open('bork', 'rb')
frw = open('bork', 'rb+')
fcntl.lockf(frw, fcntl.LOCK_SH)
frw.write('lalala')
frw.truncate()
frw.close()
fro.close()

runs "successfully" and leaves "borkbo" in the file: the truncate succeeded but the write before it did not actually change the file. If oplocks are disabled on the server the second fd ("fro") is not necessary to trigger the bug. If an "exclusive" lock (LOCK_EX instead of LOCK_SH) is used it works (leaves "lalala" in the file).

dmesg on the client has "CIFS VFS: Write2 ret -13, written = 0". Possibly relevant lines in the server log (I'll attach a more complete log snippet) include:

[2007/03/29 00:32:00, 3] smbd/process.c:switch_message(914)
  switch message SMBwriteX (pid 2769) conn 0x803defa0
[2007/03/29 00:32:00, 4] smbd/uid.c:change_to_user(170)
  change_to_user: Skipping user change - already user
[2007/03/29 00:32:00, 3] smbd/error.c:error_packet(146)
  error packet at smbd/reply.c(3098) cmd=47 (SMBwriteX) NT_STATUS_FILE_LOCK_CONF
LICT

and

[2007/03/29 00:32:00, 3] smbd/process.c:switch_message(914)
  switch message SMBtrans2 (pid 2769) conn 0x803defa0
[2007/03/29 00:32:00, 4] smbd/uid.c:change_to_user(170)
  change_to_user: Skipping user change - already user
[2007/03/29 00:32:00, 3] smbd/trans2.c:call_trans2setfilepathinfo(3850)
  call_trans2setfilepathinfo(8) bork (fnum 11976) info_level=1020 totdata=8

so as far as I can tell the attempt to write triggers an explicit locking check inside samba, while the truncate does not trigger such a check and there is no underlying fs lock stopping the truncate.

I'm not sure if this is a server bug, a client bug or both. It looks like the client is not dealing with the server rejecting the write request gracefully (no error reported to userspace) but I'm not sure if the server is supposed to deny the write and/or truncate or not.

If more information or a way to reproduce this without using python are needed please ask.
Comment 1 Marien Zwart 2007-03-30 13:15:44 UTC
Created attachment 2354 [details]
part of the server log
Comment 2 Shirish S. Pargaonkar 2009-10-30 14:05:48 UTC
Yes, can you provide a testcase (that can be used without using python)
to reproduce this problem?
Comment 3 Shirish S. Pargaonkar 2009-11-09 21:41:43 UTC
This works as expected with LOCK_SH.

I just ran this script as and the file is left with 'lalala'

cat /tmp/test.py

#!/usr/bin/env python
import sys

import fcntl
open('bork', 'w').write('borkborkbork')
fro = open('bork', 'rb')
frw = open('bork', 'rb+')
fcntl.lockf(frw, fcntl.LOCK_SH)
frw.write('lalala')
frw.truncate()
frw.close()
fro.close()

/mnt/smb_b # more bork
lalala
Comment 4 Steve French 2010-03-31 11:47:12 UTC
Seems like it works based on descriptions below - if that is not the case re-open.