Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

Arnaldo Carvalho de Melo writes: > Em Wed, Aug 26, 2015 at 07:56:47PM +0300, Alexander Shishkin escreveu: >> So I hacked stuff a bit [1] to accomodate some of the above >> ideas. The below diff shows how these ideas integrate with perf. The >> rest is in my github tree. >> >> - this exterr

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

Arnaldo Carvalho de Melo writes: > Em Wed, Aug 26, 2015 at 07:56:47PM +0300, Alexander Shishkin escreveu: >> So I hacked stuff a bit [1] to accomodate some of the above >> ideas. The below diff shows how these ideas integrate with perf. The >> rest is in my github tree. >> >>

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

* Andrew Morton wrote: > On Wed, 26 Aug 2015 22:05:13 +0200 Peter Zijlstra > wrote: > > > > Is this whole thing overkill? As far as I can see, the problem which is > > > being addressed only occurs in a couple of places (perf, wifi netlink > > > handling) and could be addressed with some

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

* Andrew Morton a...@linux-foundation.org wrote: On Wed, 26 Aug 2015 22:05:13 +0200 Peter Zijlstra pet...@infradead.org wrote: Is this whole thing overkill? As far as I can see, the problem which is being addressed only occurs in a couple of places (perf, wifi netlink handling)

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

On Wed, 26 Aug 2015, Andrew Morton wrote: > On Wed, 26 Aug 2015 16:50:33 -0400 (EDT) Vince Weaver > wrote: > > I often have to resort to sprinkling the kernel with printks to find the > > source of errors, which is a pain. It's even more fun when the user's > > setup is slightly different

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

Em Wed, Aug 26, 2015 at 11:41:11AM -0700, Andrew Morton escreveu: > On Wed, 26 Aug 2015 09:26:56 +0200 Ingo Molnar wrote: > > * Ingo Molnar wrote: > > > > > ... but back then I didn't feel like complicating an error recovery ABI > > > for the > > > needs of the 1%, robust error handling is

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

Em Wed, Aug 26, 2015 at 07:56:47PM +0300, Alexander Shishkin escreveu: > Ingo Molnar writes: > > > * Ingo Molnar wrote: > > > >> ... but back then I didn't feel like complicating an error recovery ABI > >> for the > >> needs of the 1%, robust error handling is all about simplicity: if it's >

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

On Wed, 26 Aug 2015, Andrew Morton wrote: > On Wed, 26 Aug 2015 22:05:13 +0200 Peter Zijlstra > wrote: > > > > Is this whole thing overkill? As far as I can see, the problem which is > > > being addressed only occurs in a couple of places (perf, wifi netlink > > > handling) and could be

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

On Wed, 26 Aug 2015 16:50:33 -0400 (EDT) Vince Weaver wrote: > On Wed, 26 Aug 2015, Andrew Morton wrote: > > > On Wed, 26 Aug 2015 22:05:13 +0200 Peter Zijlstra > > wrote: > > > > > > Is this whole thing overkill? As far as I can see, the problem which is > > > > being addressed only occurs

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

On Wed, 26 Aug 2015 22:05:13 +0200 Peter Zijlstra wrote: > > Is this whole thing overkill? As far as I can see, the problem which is > > being addressed only occurs in a couple of places (perf, wifi netlink > > handling) and could be addressed with some local pr_debug statements. ie, > > > >

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

On Wed, Aug 26, 2015 at 11:41:11AM -0700, Andrew Morton wrote: > On Wed, 26 Aug 2015 09:26:56 +0200 Ingo Molnar wrote: > > > > > * Ingo Molnar wrote: > > > > > ... but back then I didn't feel like complicating an error recovery ABI > > > for the > > > needs of the 1%, robust error handling

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

On Wed, 26 Aug 2015 09:26:56 +0200 Ingo Molnar wrote: > > * Ingo Molnar wrote: > > > ... but back then I didn't feel like complicating an error recovery ABI for > > the > > needs of the 1%, robust error handling is all about simplicity: if it's not > > simple, tools won't use it. > > And

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

Ingo Molnar writes: > * Ingo Molnar wrote: > >> ... but back then I didn't feel like complicating an error recovery ABI for >> the >> needs of the 1%, robust error handling is all about simplicity: if it's not >> simple, tools won't use it. > > And note that it needs to be 'simple' in two

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

Ingo Molnar writes: > * Ingo Molnar wrote: > >> >> * Johannes Berg wrote: >> >> > On Mon, 2015-08-24 at 17:32 +0300, Alexander Shishkin wrote: >> > >> > > This time around, I employed a linker trick to convert the structures >> > > containing extended error information into integers, which

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

On Wed, 2015-08-26 at 09:20 +0200, Ingo Molnar wrote: > > That's a good point, and think that least in the netlink case it'd be much > > better to say which attribute was the one that had an issue, and that has > > an > > obvious binary encoding rather than encoding that in a string. > > So in

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

* Ingo Molnar wrote: > ... but back then I didn't feel like complicating an error recovery ABI for > the > needs of the 1%, robust error handling is all about simplicity: if it's not > simple, tools won't use it. And note that it needs to be 'simple' in two places for usage to grow

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

* Johannes Berg wrote: > On Tue, 2015-08-25 at 22:07 -0700, Linus Torvalds wrote: > > > > No, the current MAX_ERRNO is probably not big enough if this scheme is > > > successful, > > > and I don't see any reason why it wouldn't be successful: I think this > > > feature > > > would be the

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

On Tue, 2015-08-25 at 22:07 -0700, Linus Torvalds wrote: > > No, the current MAX_ERRNO is probably not big enough if this scheme is > > successful, > > and I don't see any reason why it wouldn't be successful: I think this > > feature > > would be the biggest usability feature added to Linux

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

* Linus Torvalds wrote: > On Aug 25, 2015 21:49, "Ingo Molnar" wrote: > > > > No, the current MAX_ERRNO is probably not big enough if this scheme is > > successful, and I don't see any reason why it wouldn't be successful: I > > think > > this feature would be the biggest usability feature

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

On Wed, Aug 26, 2015 at 11:41:11AM -0700, Andrew Morton wrote: On Wed, 26 Aug 2015 09:26:56 +0200 Ingo Molnar mi...@kernel.org wrote: * Ingo Molnar mi...@kernel.org wrote: ... but back then I didn't feel like complicating an error recovery ABI for the needs of the 1%, robust

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

On Wed, 26 Aug 2015 09:26:56 +0200 Ingo Molnar mi...@kernel.org wrote: * Ingo Molnar mi...@kernel.org wrote: ... but back then I didn't feel like complicating an error recovery ABI for the needs of the 1%, robust error handling is all about simplicity: if it's not simple, tools

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

* Linus Torvalds torva...@linux-foundation.org wrote: On Aug 25, 2015 21:49, Ingo Molnar mi...@kernel.org wrote: No, the current MAX_ERRNO is probably not big enough if this scheme is successful, and I don't see any reason why it wouldn't be successful: I think this feature would

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

On Tue, 2015-08-25 at 22:07 -0700, Linus Torvalds wrote: No, the current MAX_ERRNO is probably not big enough if this scheme is successful, and I don't see any reason why it wouldn't be successful: I think this feature would be the biggest usability feature added to Linux system calls

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

Ingo Molnar mi...@kernel.org writes: * Ingo Molnar mi...@kernel.org wrote: ... but back then I didn't feel like complicating an error recovery ABI for the needs of the 1%, robust error handling is all about simplicity: if it's not simple, tools won't use it. And note that it needs to

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

On Wed, 26 Aug 2015 16:50:33 -0400 (EDT) Vince Weaver vi...@deater.net wrote: On Wed, 26 Aug 2015, Andrew Morton wrote: On Wed, 26 Aug 2015 22:05:13 +0200 Peter Zijlstra pet...@infradead.org wrote: Is this whole thing overkill? As far as I can see, the problem which is being

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

On Wed, 26 Aug 2015, Andrew Morton wrote: On Wed, 26 Aug 2015 22:05:13 +0200 Peter Zijlstra pet...@infradead.org wrote: Is this whole thing overkill? As far as I can see, the problem which is being addressed only occurs in a couple of places (perf, wifi netlink handling) and could

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

Em Wed, Aug 26, 2015 at 11:41:11AM -0700, Andrew Morton escreveu: On Wed, 26 Aug 2015 09:26:56 +0200 Ingo Molnar mi...@kernel.org wrote: * Ingo Molnar mi...@kernel.org wrote: ... but back then I didn't feel like complicating an error recovery ABI for the needs of the 1%, robust

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

Em Wed, Aug 26, 2015 at 07:56:47PM +0300, Alexander Shishkin escreveu: Ingo Molnar mi...@kernel.org writes: * Ingo Molnar mi...@kernel.org wrote: ... but back then I didn't feel like complicating an error recovery ABI for the needs of the 1%, robust error handling is all about

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

On Wed, 26 Aug 2015, Andrew Morton wrote: On Wed, 26 Aug 2015 16:50:33 -0400 (EDT) Vince Weaver vi...@deater.net wrote: I often have to resort to sprinkling the kernel with printks to find the source of errors, which is a pain. It's even more fun when the user's setup is slightly

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

* Ingo Molnar mi...@kernel.org wrote: ... but back then I didn't feel like complicating an error recovery ABI for the needs of the 1%, robust error handling is all about simplicity: if it's not simple, tools won't use it. And note that it needs to be 'simple' in two places for usage to

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

* Johannes Berg johan...@sipsolutions.net wrote: On Tue, 2015-08-25 at 22:07 -0700, Linus Torvalds wrote: No, the current MAX_ERRNO is probably not big enough if this scheme is successful, and I don't see any reason why it wouldn't be successful: I think this feature would be

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

On Wed, 2015-08-26 at 09:20 +0200, Ingo Molnar wrote: That's a good point, and think that least in the netlink case it'd be much better to say which attribute was the one that had an issue, and that has an obvious binary encoding rather than encoding that in a string. So in older

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

Ingo Molnar mi...@kernel.org writes: * Ingo Molnar mi...@kernel.org wrote: * Johannes Berg johan...@sipsolutions.net wrote: On Mon, 2015-08-24 at 17:32 +0300, Alexander Shishkin wrote: This time around, I employed a linker trick to convert the structures containing extended

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

On Wed, 26 Aug 2015 22:05:13 +0200 Peter Zijlstra pet...@infradead.org wrote: Is this whole thing overkill? As far as I can see, the problem which is being addressed only occurs in a couple of places (perf, wifi netlink handling) and could be addressed with some local pr_debug statements.

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

* Johannes Berg wrote: > On Tue, 2015-08-25 at 12:07 +0200, Ingo Molnar wrote: > > Having a separate syscall has two (big!) appeals: > > > > - we wouldn't have to touch existing system calls at all. > > > > - extended error reporting would be available for any system call that > > opts to

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

On Tue, 2015-08-25 at 12:07 +0200, Ingo Molnar wrote: > Having a separate syscall has two (big!) appeals: > > - we wouldn't have to touch existing system calls at all. > > - extended error reporting would be available for any system call that opts > to >use it. (The current scheme as

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

* Johannes Berg wrote: > On Tue, 2015-08-25 at 11:17 +0200, Ingo Molnar wrote: > > > > If we do that then we don't even have to introduce per system call error > > code > > conversion, but could unconditionally save the last extended error info in > > the > > task struct and continue -

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

On Tue, 2015-08-25 at 11:17 +0200, Ingo Molnar wrote: > > If we do that then we don't even have to introduce per system call error code > conversion, but could unconditionally save the last extended error info in > the > task struct and continue - this could be done very cheaply with the

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

* Ingo Molnar wrote: > > * Johannes Berg wrote: > > > On Mon, 2015-08-24 at 17:32 +0300, Alexander Shishkin wrote: > > > > > This time around, I employed a linker trick to convert the structures > > > containing extended error information into integers, which are then made > > > to > > >

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

* Johannes Berg wrote: > On Mon, 2015-08-24 at 17:32 +0300, Alexander Shishkin wrote: > > > This time around, I employed a linker trick to convert the structures > > containing extended error information into integers, which are then > > made to look just like normal error codes so that

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

On Mon, 2015-08-24 at 17:32 +0300, Alexander Shishkin wrote: > This time around, I employed a linker trick to convert the structures > containing extended error information into integers, which are then > made to look just like normal error codes so that IS_ERR_VALUE() and > friends would still

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

* Alexander Shishkin wrote: > Hi Peter and Ingo and everybody, > > Here's an update of my extended error reporting patchset, addressing > review comments and adding a few more error messages to PT and BTS > drivers. > > Changes since v1: > * addressed Peter's comments, > * added

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

* Johannes Berg johan...@sipsolutions.net wrote: On Tue, 2015-08-25 at 12:07 +0200, Ingo Molnar wrote: Having a separate syscall has two (big!) appeals: - we wouldn't have to touch existing system calls at all. - extended error reporting would be available for any system call that

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

* Johannes Berg johan...@sipsolutions.net wrote: On Mon, 2015-08-24 at 17:32 +0300, Alexander Shishkin wrote: This time around, I employed a linker trick to convert the structures containing extended error information into integers, which are then made to look just like normal error

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

* Alexander Shishkin alexander.shish...@linux.intel.com wrote: Hi Peter and Ingo and everybody, Here's an update of my extended error reporting patchset, addressing review comments and adding a few more error messages to PT and BTS drivers. Changes since v1: * addressed Peter's

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

On Mon, 2015-08-24 at 17:32 +0300, Alexander Shishkin wrote: This time around, I employed a linker trick to convert the structures containing extended error information into integers, which are then made to look just like normal error codes so that IS_ERR_VALUE() and friends would still work

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

On Tue, 2015-08-25 at 12:07 +0200, Ingo Molnar wrote: Having a separate syscall has two (big!) appeals: - we wouldn't have to touch existing system calls at all. - extended error reporting would be available for any system call that opts to use it. (The current scheme as submitted

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

On Tue, 2015-08-25 at 11:17 +0200, Ingo Molnar wrote: If we do that then we don't even have to introduce per system call error code conversion, but could unconditionally save the last extended error info in the task struct and continue - this could be done very cheaply with the linker

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

* Johannes Berg johan...@sipsolutions.net wrote: On Tue, 2015-08-25 at 11:17 +0200, Ingo Molnar wrote: If we do that then we don't even have to introduce per system call error code conversion, but could unconditionally save the last extended error info in the task struct and

Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

* Ingo Molnar mi...@kernel.org wrote: * Johannes Berg johan...@sipsolutions.net wrote: On Mon, 2015-08-24 at 17:32 +0300, Alexander Shishkin wrote: This time around, I employed a linker trick to convert the structures containing extended error information into integers, which

[PATCH v2 0/6] perf: Introduce extended syscall error reporting

Hi Peter and Ingo and everybody, Here's an update of my extended error reporting patchset, addressing review comments and adding a few more error messages to PT and BTS drivers. Changes since v1: * addressed Peter's comments, * added perf_err() annotation to intel_pt and intel_bts drivers;

[PATCH v2 0/6] perf: Introduce extended syscall error reporting

Hi Peter and Ingo and everybody, Here's an update of my extended error reporting patchset, addressing review comments and adding a few more error messages to PT and BTS drivers. Changes since v1: * addressed Peter's comments, * added perf_err() annotation to intel_pt and intel_bts drivers;