From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x226PDAF8Ed1r0bu8kGCCb8Gr7c3/o0dRtVgJy2pUp6U6S0d5S0IfSQcvtX5eiAxWBOBMr6Pl ARC-Seal: i=1; a=rsa-sha256; t=1517256659; cv=none; d=google.com; s=arc-20160816; b=M4k9KMZ243sTJDzsnIuRiEdSAdlP1kzD/lK/BLf9X7bdwPGD82i5C+BT3PGfvnTfMQ YuXkV86b7WcyYsg17XQ8WUBBCr5wEDBxD75JoyGTExwE0r6ArJpGMqvbPCDkDFtxXnOU NOCKzYa+G/DaKnVQnMu0oEB+pD1MCu8EIcba+ZiMr7JJeZDq8n/j8wtfpLLEgsPHoSgV FSuo98rQGMZtP4LPXPkZJKZaTMabkr1GOxFusJ/3xY4Zf85jTdq8PcgMn54KBpQGaADC RAi9G+lhm+Qb+gS8cKJ8aSnmyZiE+u9picNCxBKL817aRbb6jxrorPLaLq+YFxTn9Zxf xMvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:user-agent:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=gW7sb4JAkMkn4+UenwF+EXU2JCoWVAj1q84Y2/upTTY=; b=pt7EI5u3s88dS2/9q7vTS2umjDsclGTamxYHBIjC42zCkuqDAAq5mxyvFZdeRYTxzJ bKkaq1ZMUhPdLvcyr45i2U4cjD3zbFA3fdW3pfp8EToD01Plus5DOebHfnXVJ+4ubLgR BHtUnKzKwCeVMjQoMrnQ8OEDzT+BlnTpzVL1vEOEz8i1txe1oh0u7lgiX8XgmQzRX2EO NAhzVipiwyw1yB/6nqJueQdrWsDQxRyY6GAY4EQhZtZFYNuHl0mSBudGzY2xQD71ZLMn taf0iC0z7gWxXzT2FC8uGrJcjQ6FFO/UeUTvCR0O1YYh+X8co0bDA34irUZz7VpPMm8H lhJg== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning gregkh@linuxfoundation.org does not designate 90.92.71.90 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning gregkh@linuxfoundation.org does not designate 90.92.71.90 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Martin Brandenburg , Linus Torvalds Subject: [PATCH 4.9 03/66] orangefs: initialize op on loop restart in orangefs_devreq_read Date: Mon, 29 Jan 2018 13:56:27 +0100 Message-Id: <20180129123840.031212635@linuxfoundation.org> X-Mailer: git-send-email 2.16.1 In-Reply-To: <20180129123839.842860149@linuxfoundation.org> References: <20180129123839.842860149@linuxfoundation.org> User-Agent: quilt/0.65 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-LABELS: =?utf-8?b?IlxcU2VudCI=?= X-GMAIL-THRID: =?utf-8?q?1590958919837138217?= X-GMAIL-MSGID: =?utf-8?q?1590958919837138217?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: 4.9-stable review patch. If anyone has any objections, please let me know. ------------------ From: Martin Brandenburg commit a0ec1ded22e6a6bc41981fae22406835b006a66e upstream. In orangefs_devreq_read, there is a loop which picks an op off the list of pending ops. If the loop fails to find an op, there is nothing to read, and it returns EAGAIN. If the op has been given up on, the loop is restarted via a goto. The bug is that the variable which the found op is written to is not reinitialized, so if there are no more eligible ops on the list, the code runs again on the already handled op. This is triggered by interrupting a process while the op is being copied to the client-core. It's a fairly small window, but it's there. Signed-off-by: Martin Brandenburg Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- fs/orangefs/devorangefs-req.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/fs/orangefs/devorangefs-req.c +++ b/fs/orangefs/devorangefs-req.c @@ -161,7 +161,7 @@ static ssize_t orangefs_devreq_read(stru struct orangefs_kernel_op_s *op, *temp; __s32 proto_ver = ORANGEFS_KERNEL_PROTO_VERSION; static __s32 magic = ORANGEFS_DEVREQ_MAGIC; - struct orangefs_kernel_op_s *cur_op = NULL; + struct orangefs_kernel_op_s *cur_op; unsigned long ret; /* We do not support blocking IO. */ @@ -181,6 +181,7 @@ static ssize_t orangefs_devreq_read(stru } restart: + cur_op = NULL; /* Get next op (if any) from top of list. */ spin_lock(&orangefs_request_list_lock); list_for_each_entry_safe(op, temp, &orangefs_request_list, list) {