diff mbox

[1/1] drm/i915: shorten i915_next_seqno debugfs output

Message ID 1365686532-6682-1-git-send-email-mika.kuoppala@intel.com (mailing list archive)
State New, archived
Headers show

Commit Message

Mika Kuoppala April 11, 2013, 1:22 p.m. UTC
commit 647416f9eefe7699754b01b9fc82758fde83248c
Author: Kees Cook <keescook@chromium.org>
Date:   Sun Mar 10 14:10:06 2013 -0700

    drm/i915: use simple attribute in debugfs routines

made i915_next_seqno debugfs entry to crop it's output
if returned value was large enough. Using simple_attr
will limit the output to 24 bytes. Fix this by returning
only the value and nothing else.

Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
---
 drivers/gpu/drm/i915/i915_debugfs.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Kees Cook April 11, 2013, 4:02 p.m. UTC | #1
On Thu, Apr 11, 2013 at 6:22 AM, Mika Kuoppala
<mika.kuoppala@linux.intel.com> wrote:
> commit 647416f9eefe7699754b01b9fc82758fde83248c
> Author: Kees Cook <keescook@chromium.org>
> Date:   Sun Mar 10 14:10:06 2013 -0700
>
>     drm/i915: use simple attribute in debugfs routines
>
> made i915_next_seqno debugfs entry to crop it's output
> if returned value was large enough. Using simple_attr
> will limit the output to 24 bytes. Fix this by returning
> only the value and nothing else.
>
> Cc: Kees Cook <keescook@chromium.org>
> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>

Oh! Thanks for catching that. What a weird limitation.

What about max freq, min freq, and wedged? Do those run the risk of
truncation too?

-Kees

> ---
>  drivers/gpu/drm/i915/i915_debugfs.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
> index be88532..afe9421 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -901,7 +901,7 @@ i915_next_seqno_set(void *data, u64 val)
>
>  DEFINE_SIMPLE_ATTRIBUTE(i915_next_seqno_fops,
>                         i915_next_seqno_get, i915_next_seqno_set,
> -                       "next_seqno :  0x%llx\n");
> +                       "0x%llx\n");
>
>  static int i915_rstdby_delays(struct seq_file *m, void *unused)
>  {
> --
> 1.7.9.5
>



--
Kees Cook
Chrome OS Security
Mika Kuoppala April 11, 2013, 4:15 p.m. UTC | #2
Kees Cook <keescook@chromium.org> writes:

> On Thu, Apr 11, 2013 at 6:22 AM, Mika Kuoppala
> <mika.kuoppala@linux.intel.com> wrote:
>> commit 647416f9eefe7699754b01b9fc82758fde83248c
>> Author: Kees Cook <keescook@chromium.org>
>> Date:   Sun Mar 10 14:10:06 2013 -0700
>>
>>     drm/i915: use simple attribute in debugfs routines
>>
>> made i915_next_seqno debugfs entry to crop it's output
>> if returned value was large enough. Using simple_attr
>> will limit the output to 24 bytes. Fix this by returning
>> only the value and nothing else.
>>
>> Cc: Kees Cook <keescook@chromium.org>
>> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
>
> Oh! Thanks for catching that. What a weird limitation.
>
> What about max freq, min freq, and wedged? Do those run the risk of
> truncation too?

max and min freq should be safe, and wedged too on 32bit platforms.
But if gpu is declared wedged on host with 64bit atomic_t,
it will crop the output.

-Mika
Kees Cook April 11, 2013, 4:42 p.m. UTC | #3
On Thu, Apr 11, 2013 at 9:15 AM, Mika Kuoppala
<mika.kuoppala@linux.intel.com> wrote:
> Kees Cook <keescook@chromium.org> writes:
>
>> On Thu, Apr 11, 2013 at 6:22 AM, Mika Kuoppala
>> <mika.kuoppala@linux.intel.com> wrote:
>>> commit 647416f9eefe7699754b01b9fc82758fde83248c
>>> Author: Kees Cook <keescook@chromium.org>
>>> Date:   Sun Mar 10 14:10:06 2013 -0700
>>>
>>>     drm/i915: use simple attribute in debugfs routines
>>>
>>> made i915_next_seqno debugfs entry to crop it's output
>>> if returned value was large enough. Using simple_attr
>>> will limit the output to 24 bytes. Fix this by returning
>>> only the value and nothing else.
>>>
>>> Cc: Kees Cook <keescook@chromium.org>
>>> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
>>
>> Oh! Thanks for catching that. What a weird limitation.
>>
>> What about max freq, min freq, and wedged? Do those run the risk of
>> truncation too?
>
> max and min freq should be safe, and wedged too on 32bit platforms.
> But if gpu is declared wedged on host with 64bit atomic_t,
> it will crop the output.

Should we consider proposing an increase in the size of the simple
attr buffer? It seems silly to provide an arbitrary format string but
leave the buffer so small.

-Kees

--
Kees Cook
Chrome OS Security
Mika Kuoppala April 12, 2013, 9:15 a.m. UTC | #4
Kees Cook <keescook@chromium.org> writes:

> On Thu, Apr 11, 2013 at 9:15 AM, Mika Kuoppala
> <mika.kuoppala@linux.intel.com> wrote:
>> Kees Cook <keescook@chromium.org> writes:
>>
>>> On Thu, Apr 11, 2013 at 6:22 AM, Mika Kuoppala
>>> <mika.kuoppala@linux.intel.com> wrote:
>>>> commit 647416f9eefe7699754b01b9fc82758fde83248c
>>>> Author: Kees Cook <keescook@chromium.org>
>>>> Date:   Sun Mar 10 14:10:06 2013 -0700
>>>>
>>>>     drm/i915: use simple attribute in debugfs routines
>>>>
>>>> made i915_next_seqno debugfs entry to crop it's output
>>>> if returned value was large enough. Using simple_attr
>>>> will limit the output to 24 bytes. Fix this by returning
>>>> only the value and nothing else.
>>>>
>>>> Cc: Kees Cook <keescook@chromium.org>
>>>> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
>>>
>>> Oh! Thanks for catching that. What a weird limitation.
>>>
>>> What about max freq, min freq, and wedged? Do those run the risk of
>>> truncation too?
>>
>> max and min freq should be safe, and wedged too on 32bit platforms.
>> But if gpu is declared wedged on host with 64bit atomic_t,
>> it will crop the output.
>
> Should we consider proposing an increase in the size of the simple
> attr buffer? It seems silly to provide an arbitrary format string but
> leave the buffer so small.

That or dynamic allocation to attr->get_buf. But that would need
extra pass with snprintf and I don't know if that qualifies as 'simple'
anymore.

I have posted a patch which fixes all i915 debugfs simple attributes
to fit into the simple_attr by removing everything except the fmt to
value. I didn't find any testcases which would rely on preample
being there.

--Mika
Kees Cook April 12, 2013, 5:57 p.m. UTC | #5
On Fri, Apr 12, 2013 at 2:15 AM, Mika Kuoppala
<mika.kuoppala@linux.intel.com> wrote:
> Kees Cook <keescook@chromium.org> writes:
>
>> On Thu, Apr 11, 2013 at 9:15 AM, Mika Kuoppala
>> <mika.kuoppala@linux.intel.com> wrote:
>>> Kees Cook <keescook@chromium.org> writes:
>>>
>>>> On Thu, Apr 11, 2013 at 6:22 AM, Mika Kuoppala
>>>> <mika.kuoppala@linux.intel.com> wrote:
>>>>> commit 647416f9eefe7699754b01b9fc82758fde83248c
>>>>> Author: Kees Cook <keescook@chromium.org>
>>>>> Date:   Sun Mar 10 14:10:06 2013 -0700
>>>>>
>>>>>     drm/i915: use simple attribute in debugfs routines
>>>>>
>>>>> made i915_next_seqno debugfs entry to crop it's output
>>>>> if returned value was large enough. Using simple_attr
>>>>> will limit the output to 24 bytes. Fix this by returning
>>>>> only the value and nothing else.
>>>>>
>>>>> Cc: Kees Cook <keescook@chromium.org>
>>>>> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
>>>>
>>>> Oh! Thanks for catching that. What a weird limitation.
>>>>
>>>> What about max freq, min freq, and wedged? Do those run the risk of
>>>> truncation too?
>>>
>>> max and min freq should be safe, and wedged too on 32bit platforms.
>>> But if gpu is declared wedged on host with 64bit atomic_t,
>>> it will crop the output.
>>
>> Should we consider proposing an increase in the size of the simple
>> attr buffer? It seems silly to provide an arbitrary format string but
>> leave the buffer so small.
>
> That or dynamic allocation to attr->get_buf. But that would need
> extra pass with snprintf and I don't know if that qualifies as 'simple'
> anymore.
>
> I have posted a patch which fixes all i915 debugfs simple attributes
> to fit into the simple_attr by removing everything except the fmt to
> value. I didn't find any testcases which would rely on preample
> being there.

That works too. :) If you want, consider them:

Acked-by: Kees Cook <keescook@chromium.org>

:)

Thanks!

-Kees

--
Kees Cook
Chrome OS Security
diff mbox

Patch

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
index be88532..afe9421 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -901,7 +901,7 @@  i915_next_seqno_set(void *data, u64 val)
 
 DEFINE_SIMPLE_ATTRIBUTE(i915_next_seqno_fops,
 			i915_next_seqno_get, i915_next_seqno_set,
-			"next_seqno :  0x%llx\n");
+			"0x%llx\n");
 
 static int i915_rstdby_delays(struct seq_file *m, void *unused)
 {