From 8ef968a23dffb2e1c1518f7489d4ab0b14a71118 Mon Sep 17 00:00:00 2001 From: Volker Lendecke Date: Tue, 17 Jul 2012 22:43:06 +0200 Subject: s3-aio: Panic if we try to close a fsp with outstanding aio requests The core smbd must have taken care of this. If we don't do this properly, we have a race of the close(2) against a pwrite(2). We might end up writing to the wrong file. Signed-off-by: Jeremy Allison Autobuild-User(master): Jeremy Allison Autobuild-Date(master): Thu Jul 19 03:40:17 CEST 2012 on sn-devel-104 --- source3/smbd/close.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) (limited to 'source3/smbd/close.c') diff --git a/source3/smbd/close.c b/source3/smbd/close.c index 720ffa7b64..3c5b6d74eb 100644 --- a/source3/smbd/close.c +++ b/source3/smbd/close.c @@ -707,7 +707,21 @@ static NTSTATUS close_normal_file(struct smb_request *req, files_struct *fsp, NTSTATUS tmp; connection_struct *conn = fsp->conn; - aio_fsp_close(fsp); + if (fsp->num_aio_requests != 0) { + char *str; + /* + * reply_close and the smb2 close must have taken care of + * this. No other callers of close_file should ever have + * created async I/O. + * + * We need to panic here because if we close() the fd while we + * have outstanding async I/O requests, in the worst case we + * could end up writing to the wrong file. + */ + DEBUG(0, ("fsp->num_aio_requests=%u\n", + fsp->num_aio_requests)); + smb_panic("can not close with outstanding aio requests"); + } /* * If we're flushing on a close we can get a write -- cgit