From: Steven Rostedt <rostedt@goodmis.org> To: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Carlos O'Donell <carlos@redhat.com>, linux-api@vger.kernel.org, Thorsten Leemhuis <linux@leemhuis.info>, ksummit-discuss@lists.linuxfoundation.org, Shuah Khan <shuahkh@osg.samsung.com> Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] & [TECH TOPIC] Improve regression tracking Date: Wed, 5 Jul 2017 13:07:24 -0400 [thread overview] Message-ID: <20170705130724.66637518@gandalf.local.home> (raw) In-Reply-To: <1499273908.3668.30.camel@HansenPartnership.com> On Wed, 05 Jul 2017 09:58:28 -0700 James Bottomley <James.Bottomley@HansenPartnership.com> wrote: > On Wed, 2017-07-05 at 12:04 -0400, Steven Rostedt wrote: > > On Wed, 05 Jul 2017 08:36:55 -0700 > > James Bottomley <James.Bottomley@HansenPartnership.com> wrote: > > > > > > > > > > > > > Are we tracking regressions or just simply bugs? > > > > > > A lot of device driver regressions are bugs that previously existed > > > in the code but which didn't manifest until something else > > > happened. A huge number of locking and timing issues are like > > > this. The irony is that a lot of them go from race always being > > > won (so bug never noticed) to race being lost often enough to make > > > something unusable. To a user that ends up being a kernel > > > regression because it's a bug in the current kernel which they > > > didn't see previously which makes it unusable for them. > > > > > > I've got to vote with my users here: that's a regression not a > > > "feature". > > > > Let's take a step back. What exactly is the problem? > > You mean what question was I answering? It was your "is your problem a > regression?" one. No that's not what I meant. I mean that we are going off tangent to the original topic. > > > The regressions that we want to track? Why are they not fixed? Is it > > because they are hard to reproduce? If so, how do we know they are a > > regression or just some hard to hit bug? If it's hard to hit, how do > > we know we fixed it? > > Usually for the exposed races we develop a theoretical model which > tells us what the problem is and also the solution. I think the problem is that the regressions that are not being fixed happen to be where we have no model to create, as the problem may be too hard to hit, and it could just be a "works for me" issue. > > > What exactly are the questions we want solved. > > In the context of this subthread? Tracking and fixing of regressions > meaning behaviour that damages or destroys usability of version k+1 > that wasn't present in version k. Agreed with this part. And I believe this is also in the context of the entire thread. > > > Granted, I used this thread to push more use of kselftests, and I > > don't see any SCSI tests there at all! > > It would be an interesting question for another thread to consider > whether that's a problem or not. It's not a problem for me, but it begs the question of whether it would be useful or not. But I agree, that's for another thread. -- Steve
WARNING: multiple messages have this Message-ID (diff)
From: Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org> To: James Bottomley <James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> Cc: ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I@public.gmane.org, Carlos O'Donell <carlos-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Thorsten Leemhuis <linux-rCxcAJFjeRkk+I/owrrOrA@public.gmane.org>, Shuah Khan <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] & [TECH TOPIC] Improve regression tracking Date: Wed, 5 Jul 2017 13:07:24 -0400 [thread overview] Message-ID: <20170705130724.66637518@gandalf.local.home> (raw) In-Reply-To: <1499273908.3668.30.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> On Wed, 05 Jul 2017 09:58:28 -0700 James Bottomley <James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> wrote: > On Wed, 2017-07-05 at 12:04 -0400, Steven Rostedt wrote: > > On Wed, 05 Jul 2017 08:36:55 -0700 > > James Bottomley <James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> wrote: > > > > > > > > > > > > > Are we tracking regressions or just simply bugs? > > > > > > A lot of device driver regressions are bugs that previously existed > > > in the code but which didn't manifest until something else > > > happened. A huge number of locking and timing issues are like > > > this. The irony is that a lot of them go from race always being > > > won (so bug never noticed) to race being lost often enough to make > > > something unusable. To a user that ends up being a kernel > > > regression because it's a bug in the current kernel which they > > > didn't see previously which makes it unusable for them. > > > > > > I've got to vote with my users here: that's a regression not a > > > "feature". > > > > Let's take a step back. What exactly is the problem? > > You mean what question was I answering? It was your "is your problem a > regression?" one. No that's not what I meant. I mean that we are going off tangent to the original topic. > > > The regressions that we want to track? Why are they not fixed? Is it > > because they are hard to reproduce? If so, how do we know they are a > > regression or just some hard to hit bug? If it's hard to hit, how do > > we know we fixed it? > > Usually for the exposed races we develop a theoretical model which > tells us what the problem is and also the solution. I think the problem is that the regressions that are not being fixed happen to be where we have no model to create, as the problem may be too hard to hit, and it could just be a "works for me" issue. > > > What exactly are the questions we want solved. > > In the context of this subthread? Tracking and fixing of regressions > meaning behaviour that damages or destroys usability of version k+1 > that wasn't present in version k. Agreed with this part. And I believe this is also in the context of the entire thread. > > > Granted, I used this thread to push more use of kselftests, and I > > don't see any SCSI tests there at all! > > It would be an interesting question for another thread to consider > whether that's a problem or not. It's not a problem for me, but it begs the question of whether it would be useful or not. But I agree, that's for another thread. -- Steve
next prev parent reply other threads:[~2017-07-05 17:07 UTC|newest] Thread overview: 144+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-07-02 17:51 [Ksummit-discuss] [MAINTAINERS SUMMIT] & [TECH TOPIC] Improve regression tracking Thorsten Leemhuis 2017-07-03 16:30 ` Steven Rostedt 2017-07-03 16:30 ` Steven Rostedt 2017-07-03 18:50 ` Dan Williams 2017-07-03 18:50 ` Dan Williams 2017-07-04 19:03 ` Thorsten Leemhuis 2017-07-04 19:03 ` Thorsten Leemhuis 2017-07-05 12:45 ` Steven Rostedt 2017-07-05 12:45 ` Steven Rostedt 2017-07-05 13:09 ` Carlos O'Donell 2017-07-05 13:09 ` Carlos O'Donell 2017-07-05 13:27 ` Steven Rostedt 2017-07-05 13:27 ` Steven Rostedt 2017-07-05 14:06 ` Greg KH 2017-07-05 14:06 ` Greg KH 2017-07-05 14:28 ` Carlos O'Donell 2017-07-05 14:28 ` Carlos O'Donell 2017-07-05 14:33 ` Steven Rostedt 2017-07-05 14:33 ` Steven Rostedt 2017-07-05 14:52 ` Mark Brown 2017-07-05 14:52 ` Mark Brown 2017-07-05 15:08 ` Carlos O'Donell 2017-07-05 15:08 ` Carlos O'Donell 2017-07-05 16:10 ` Steven Rostedt 2017-07-05 16:10 ` Steven Rostedt 2017-07-06 11:34 ` Laurent Pinchart 2017-07-06 11:34 ` Laurent Pinchart 2017-07-09 13:46 ` Thorsten Leemhuis 2017-07-09 13:46 ` Thorsten Leemhuis 2017-07-05 14:33 ` Mark Brown 2017-07-05 14:33 ` Mark Brown 2017-07-05 14:36 ` Steven Rostedt 2017-07-05 14:36 ` Steven Rostedt 2017-07-05 14:50 ` James Bottomley 2017-07-05 14:50 ` James Bottomley 2017-07-05 14:56 ` Steven Rostedt 2017-07-05 14:56 ` Steven Rostedt 2017-07-05 15:09 ` James Bottomley 2017-07-05 15:09 ` James Bottomley 2017-07-05 15:20 ` Mark Brown 2017-07-05 15:20 ` Mark Brown 2017-07-05 15:40 ` Geert Uytterhoeven 2017-07-05 15:40 ` Geert Uytterhoeven 2017-07-05 15:20 ` Steven Rostedt 2017-07-05 15:20 ` Steven Rostedt 2017-07-05 15:32 ` James Bottomley 2017-07-05 15:32 ` James Bottomley 2017-07-05 15:43 ` Steven Rostedt 2017-07-05 15:43 ` Steven Rostedt 2017-07-05 18:24 ` Daniel Vetter 2017-07-05 18:24 ` Daniel Vetter 2017-07-05 18:17 ` Daniel Vetter 2017-07-05 18:17 ` Daniel Vetter 2017-07-05 15:16 ` Guenter Roeck 2017-07-05 15:16 ` Guenter Roeck 2017-07-05 15:27 ` Steven Rostedt 2017-07-05 15:27 ` Steven Rostedt 2017-07-05 15:36 ` James Bottomley 2017-07-05 15:36 ` James Bottomley 2017-07-05 16:04 ` Steven Rostedt 2017-07-05 16:04 ` Steven Rostedt 2017-07-05 16:58 ` James Bottomley 2017-07-05 16:58 ` James Bottomley 2017-07-05 17:07 ` Steven Rostedt [this message] 2017-07-05 17:07 ` Steven Rostedt 2017-07-05 16:48 ` Guenter Roeck 2017-07-05 16:48 ` Guenter Roeck 2017-07-05 16:58 ` Dan Williams 2017-07-05 16:58 ` Dan Williams 2017-07-05 17:02 ` Steven Rostedt 2017-07-05 17:02 ` Steven Rostedt 2017-07-06 9:28 ` Mark Brown 2017-07-06 9:28 ` Mark Brown 2017-07-06 9:41 ` Daniel Vetter 2017-07-06 9:41 ` Daniel Vetter 2017-07-06 14:53 ` Theodore Ts'o 2017-07-06 14:53 ` Theodore Ts'o 2017-07-06 21:28 ` Daniel Vetter 2017-07-06 21:28 ` Daniel Vetter 2017-07-06 14:48 ` James Bottomley 2017-07-06 14:48 ` James Bottomley 2017-07-07 10:03 ` Mark Brown 2017-07-07 10:03 ` Mark Brown 2017-07-31 16:54 ` Eric W. Biederman 2017-07-31 16:54 ` Eric W. Biederman 2017-07-31 20:11 ` Steven Rostedt 2017-07-31 20:11 ` Steven Rostedt 2017-07-31 20:12 ` Eric W. Biederman 2017-07-31 20:12 ` Eric W. Biederman 2017-08-02 16:53 ` Shuah Khan 2017-08-02 16:53 ` Shuah Khan 2017-08-02 17:33 ` Eric W. Biederman 2017-08-02 17:33 ` Eric W. Biederman 2017-08-02 17:46 ` Shuah Khan 2017-08-02 17:46 ` Shuah Khan 2017-08-02 17:58 ` Shuah Khan 2017-08-02 17:58 ` Shuah Khan 2017-08-02 18:04 ` Eric W. Biederman 2017-08-02 18:04 ` Eric W. Biederman 2017-08-02 18:23 ` Randy Dunlap 2017-08-02 18:23 ` Randy Dunlap 2017-08-02 18:42 ` Shuah Khan 2017-08-02 18:42 ` Shuah Khan 2017-08-03 3:03 ` Theodore Ts'o 2017-08-03 3:03 ` Theodore Ts'o 2017-08-03 17:42 ` Bird, Timothy 2017-08-03 17:42 ` Bird, Timothy 2017-08-03 22:11 ` Shuah Khan 2017-08-03 22:11 ` Shuah Khan 2017-08-03 18:51 ` Shuah Khan 2017-08-03 18:51 ` Shuah Khan 2017-08-04 1:15 ` Theodore Ts'o 2017-08-04 1:15 ` Theodore Ts'o 2017-07-07 3:33 ` Fengguang Wu 2017-07-07 3:33 ` Fengguang Wu 2017-07-07 4:52 ` Frank Rowand 2017-07-07 4:52 ` Frank Rowand 2017-07-05 15:32 ` Greg KH 2017-07-05 15:32 ` Greg KH 2017-07-05 15:36 ` Carlos O'Donell 2017-07-05 15:36 ` Carlos O'Donell 2017-07-05 15:52 ` Steven Rostedt 2017-07-05 15:52 ` Steven Rostedt 2017-07-05 18:42 ` Greg KH 2017-07-05 18:42 ` Greg KH 2017-07-05 18:29 ` Daniel Vetter 2017-07-05 18:29 ` Daniel Vetter 2017-07-06 22:24 ` Shuah Khan 2017-07-06 22:24 ` Shuah Khan 2017-07-06 22:32 ` Steven Rostedt 2017-07-06 22:32 ` Steven Rostedt 2017-07-06 22:40 ` Shuah Khan 2017-07-06 22:40 ` Shuah Khan 2017-07-05 16:54 ` Dan Williams 2017-07-05 16:54 ` Dan Williams 2017-07-05 18:45 ` Greg KH 2017-07-05 18:45 ` Greg KH 2017-07-05 19:47 ` Dan Williams 2017-07-05 19:47 ` Dan Williams 2017-07-05 14:06 ` Carlos O'Donell 2017-07-05 14:06 ` Carlos O'Donell 2017-07-05 15:47 ` Mark Brown 2017-07-05 15:47 ` Mark Brown 2017-07-07 6:15 ` Andrei Vagin
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=20170705130724.66637518@gandalf.local.home \ --to=rostedt@goodmis.org \ --cc=James.Bottomley@HansenPartnership.com \ --cc=carlos@redhat.com \ --cc=ksummit-discuss@lists.linuxfoundation.org \ --cc=linux-api@vger.kernel.org \ --cc=linux@leemhuis.info \ --cc=shuahkh@osg.samsung.com \ /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: linkBe 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.