All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiggers3@gmail.com (Eric Biggers)
To: linux-security-module@vger.kernel.org
Subject: [LTP] [lkp-robot] [KEYS]  bdf7c0f8bf: ltp.add_key02.fail
Date: Thu, 20 Apr 2017 21:43:04 -0700	[thread overview]
Message-ID: <20170421044304.GB626@zzz> (raw)
In-Reply-To: <20170420125750.GD10246@rei.lan>

Hi Cyril,

On Thu, Apr 20, 2017 at 02:57:50PM +0200, Cyril Hrubis wrote:
> > 
> > In my opinion this is a valid behavior, and the test is just weird; it's passing
> > in *both* an unaddressable payload and an invalid description, so it's not clear
> > which case it's meant to be testing.  (Generally, if a syscall will fail for
> > more than one reason, it's not guaranteed which error code you'll get.)
> 
> That is quite common problem with LTP testcases. Do you care to send a
> patch or should I fix that?
> 

I'll plan to send a patch.  Also, it looks like the testing that LTP does of
add_key() is very sparse, so I'll try to extend it a bit.

> > In any case, once we have a fix merged, it would be nice for there to be an ltp
> > test added for the "NULL payload with nonzero length" case with one of the key
> > types that crashed the kernel.
> 
> Here as well, feel free to send a patch or at least point us to a
> reproducer that could be turned into a testcase.
> 

I'll plan to send a patch for that as well.

Thanks,

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers3@gmail.com>
To: ltp@lists.linux.it
Subject: [LTP] [lkp-robot] [KEYS]  bdf7c0f8bf: ltp.add_key02.fail
Date: Thu, 20 Apr 2017 21:43:04 -0700	[thread overview]
Message-ID: <20170421044304.GB626@zzz> (raw)
In-Reply-To: <20170420125750.GD10246@rei.lan>

Hi Cyril,

On Thu, Apr 20, 2017 at 02:57:50PM +0200, Cyril Hrubis wrote:
> > 
> > In my opinion this is a valid behavior, and the test is just weird; it's passing
> > in *both* an unaddressable payload and an invalid description, so it's not clear
> > which case it's meant to be testing.  (Generally, if a syscall will fail for
> > more than one reason, it's not guaranteed which error code you'll get.)
> 
> That is quite common problem with LTP testcases. Do you care to send a
> patch or should I fix that?
> 

I'll plan to send a patch.  Also, it looks like the testing that LTP does of
add_key() is very sparse, so I'll try to extend it a bit.

> > In any case, once we have a fix merged, it would be nice for there to be an ltp
> > test added for the "NULL payload with nonzero length" case with one of the key
> > types that crashed the kernel.
> 
> Here as well, feel free to send a patch or at least point us to a
> reproducer that could be turned into a testcase.
> 

I'll plan to send a patch for that as well.

Thanks,

Eric

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers3@gmail.com>
To: lkp@lists.01.org
Subject: Re: [LTP] [lkp-robot] [KEYS] bdf7c0f8bf: ltp.add_key02.fail
Date: Thu, 20 Apr 2017 21:43:04 -0700	[thread overview]
Message-ID: <20170421044304.GB626@zzz> (raw)
In-Reply-To: <20170420125750.GD10246@rei.lan>

[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]

Hi Cyril,

On Thu, Apr 20, 2017 at 02:57:50PM +0200, Cyril Hrubis wrote:
> > 
> > In my opinion this is a valid behavior, and the test is just weird; it's passing
> > in *both* an unaddressable payload and an invalid description, so it's not clear
> > which case it's meant to be testing.  (Generally, if a syscall will fail for
> > more than one reason, it's not guaranteed which error code you'll get.)
> 
> That is quite common problem with LTP testcases. Do you care to send a
> patch or should I fix that?
> 

I'll plan to send a patch.  Also, it looks like the testing that LTP does of
add_key() is very sparse, so I'll try to extend it a bit.

> > In any case, once we have a fix merged, it would be nice for there to be an ltp
> > test added for the "NULL payload with nonzero length" case with one of the key
> > types that crashed the kernel.
> 
> Here as well, feel free to send a patch or at least point us to a
> reproducer that could be turned into a testcase.
> 

I'll plan to send a patch for that as well.

Thanks,

Eric

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers3@gmail.com>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: kernel test robot <xiaolong.ye@intel.com>,
	Eric Biggers <ebiggers@google.com>,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org,
	David Howells <dhowells@redhat.com>,
	linux-security-module@vger.kernel.org, keyrings@vger.kernel.org,
	lkp@01.org, ltp@lists.linux.it
Subject: Re: [LTP] [lkp-robot] [KEYS]  bdf7c0f8bf: ltp.add_key02.fail
Date: Thu, 20 Apr 2017 21:43:04 -0700	[thread overview]
Message-ID: <20170421044304.GB626@zzz> (raw)
In-Reply-To: <20170420125750.GD10246@rei.lan>

Hi Cyril,

On Thu, Apr 20, 2017 at 02:57:50PM +0200, Cyril Hrubis wrote:
> > 
> > In my opinion this is a valid behavior, and the test is just weird; it's passing
> > in *both* an unaddressable payload and an invalid description, so it's not clear
> > which case it's meant to be testing.  (Generally, if a syscall will fail for
> > more than one reason, it's not guaranteed which error code you'll get.)
> 
> That is quite common problem with LTP testcases. Do you care to send a
> patch or should I fix that?
> 

I'll plan to send a patch.  Also, it looks like the testing that LTP does of
add_key() is very sparse, so I'll try to extend it a bit.

> > In any case, once we have a fix merged, it would be nice for there to be an ltp
> > test added for the "NULL payload with nonzero length" case with one of the key
> > types that crashed the kernel.
> 
> Here as well, feel free to send a patch or at least point us to a
> reproducer that could be turned into a testcase.
> 

I'll plan to send a patch for that as well.

Thanks,

Eric

  reply	other threads:[~2017-04-21  4:43 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-01 21:34 [PATCH] KEYS: fix dereferencing NULL payload with nonzero length Eric Biggers
2017-04-01 21:34 ` Eric Biggers
2017-04-03 15:46 ` David Howells
2017-04-03 15:46   ` David Howells
2017-04-03 17:59   ` Eric Biggers
2017-04-03 17:59     ` Eric Biggers
2017-04-03 19:20     ` David Howells
2017-04-03 19:20       ` David Howells
2017-04-03 21:30       ` Eric Biggers
2017-04-03 21:30         ` Eric Biggers
2017-05-31 19:11         ` Eric Biggers
2017-05-31 19:11           ` Eric Biggers
2017-05-31 19:11           ` Eric Biggers
2017-04-17  6:26 ` [LTP] [lkp-robot] [KEYS] bdf7c0f8bf: ltp.add_key02.fail kernel test robot
2017-04-17  6:26   ` kernel test robot
2017-04-17  6:26   ` kernel test robot
2017-04-17 17:29   ` Eric Biggers
2017-04-17 17:29     ` Eric Biggers
2017-04-17 17:29     ` Eric Biggers
2017-04-17 17:29     ` [LTP] " Eric Biggers
2017-04-20 12:57     ` Cyril Hrubis
2017-04-20 12:57       ` Cyril Hrubis
2017-04-20 12:57       ` Cyril Hrubis
2017-04-20 12:57       ` Cyril Hrubis
2017-04-21  4:43       ` Eric Biggers [this message]
2017-04-21  4:43         ` Eric Biggers
2017-04-21  4:43         ` Eric Biggers
2017-04-21  4:43         ` Eric Biggers
2017-06-02 13:43         ` David Howells
2017-06-02 13:43           ` David Howells
2017-06-02 13:43           ` David Howells
2017-06-02 13:43           ` David Howells
2017-06-02 13:43           ` David Howells

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=20170421044304.GB626@zzz \
    --to=ebiggers3@gmail.com \
    --cc=linux-security-module@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.