All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Peng Tao <bergwolf@gmail.com>
Cc: linux-kernel@vger.kernel.org,
	Amir Shehata <amir.shehata@intel.com>,
	Andreas Dilger <andreas.dilger@intel.com>
Subject: Re: [PATCH 4/9] staging/lustre/lnet: Fix assert on empty group in selftest module
Date: Tue, 19 Nov 2013 10:37:14 -0800	[thread overview]
Message-ID: <20131119183714.GA26216@kroah.com> (raw)
In-Reply-To: <1384867428-8395-5-git-send-email-bergwolf@gmail.com>

On Tue, Nov 19, 2013 at 09:23:43PM +0800, Peng Tao wrote:
> From: Amir Shehata <amir.shehata@intel.com>
> 
> The core of the issue is that the selftest module doesn't sanitize its
> own API, but it depends on lst utility to do such checks.  As a result
> this issue manifests itself in this particular LU through an assert
> on an empty group.  If the NID is misspelled then an empty group is
> added.  An error output is provided, but if that's never checked in a
> batch script, as is the case with this issue, then the script will try
> to add an empty group to a test to run in a batch, and that will cause
> an assert
> 
> The fix is two fold.  Ensure that lst utility checks that a group is
> added with at least one node.  If not the group is subsequently
> deleted.  And the add_test command would fail, since the group no
> longer exists.
> 
> The second fix is to ensure that the kernel module itself sanitizes
> its own API in this particular case, so that if a different utility is
> used other than lst to communicate with the selftest kernel module
> then this error would be caught.  This fix looks up the batch and the
> groups, src and dst, in the ioctl handle and sanitizes that input at
> this point.  If the group looked up either doesn't exist or doesn't
> have at least one ACTIVE node, then the command fails.
> 
> NOTE:there are many other cases in the code where the selftest kernel
> module doesn't check for sanity of the input, but depends totally on
> the lst module to do such checks.  Particularly around length of
> strings passed in.  Thus it is possible to crash the selftest module
> if someone tries to create another userspace app to communicate with
> the selftest kernel module without ensuring sanity of the params sent
> to the kernel module.  In effect, it's always assumed that lst is the
> front end for selftest and no other front end is to be used.

This patch adds build warnings to the kernel build process, so I can't
apply it, sorry.  Please fix that up before sending it again.

greg k-h

  reply	other threads:[~2013-11-19 18:36 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-19 13:23 [PATCH 0/9] staging/lustre: sync with exernal tree Peng Tao
2013-11-19 13:23 ` [PATCH 1/9] staging/lustre/llite: Access to released file trigs a restore Peng Tao
2013-11-19 18:29   ` Greg Kroah-Hartman
2013-11-20  7:35     ` Peng Tao
2013-11-20  9:40       ` Peng Tao
2013-11-19 13:23 ` [PATCH 2/9] staging/lustre/hsm: Implementation of exclusive open Peng Tao
2013-11-19 13:23 ` [PATCH 3/9] drivers/staging/lustre: indent lustre_ldlm_flags_vals Peng Tao
2013-11-19 13:23 ` [PATCH 4/9] staging/lustre/lnet: Fix assert on empty group in selftest module Peng Tao
2013-11-19 18:37   ` Greg Kroah-Hartman [this message]
2013-11-20  9:26     ` Peng Tao
2013-11-20 16:27       ` Greg Kroah-Hartman
2013-11-20 17:34         ` Peng Tao
2013-11-19 13:23 ` [PATCH 5/9] staging/lustre/lnet: coding style fix for lst_test_add_ioctl Peng Tao
2013-11-19 13:23 ` [PATCH 6/9] staging/lustre/lnet: remove extra space in lstcon_rpc_trans_abort Peng Tao
2013-11-19 13:23 ` [PATCH 7/9] staging/lustre/lnet: constify name argument of lstcon_group_find/lstcon_batch_find Peng Tao
2013-11-19 13:23 ` [PATCH 8/9] staging/lustre/lnet: coding style fix for lstcon_test_add Peng Tao
2013-11-19 13:23 ` [PATCH 9/9] staging/lustre/ldlm: fix resource/fid check, use DLDLMRES Peng Tao
2013-11-19 18:40   ` Greg Kroah-Hartman
2013-11-19 18:41 ` [PATCH 0/9] staging/lustre: sync with exernal tree Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131119183714.GA26216@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=amir.shehata@intel.com \
    --cc=andreas.dilger@intel.com \
    --cc=bergwolf@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.