[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55DF97E6.9050108@plumgrid.com>
Date: Thu, 27 Aug 2015 16:06:14 -0700
From: Alexei Starovoitov <ast@...mgrid.com>
To: David Miller <davem@...emloft.net>
Cc: mingo@...nel.org, rostedt@...dmis.org, wangnan0@...wei.com,
hekuang@...wei.com, daniel@...earbox.net,
brendan.d.gregg@...il.com, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next] bpf: add support for %s specifier to
bpf_trace_printk()
On 8/27/15 3:34 PM, David Miller wrote:
> From: Alexei Starovoitov <ast@...mgrid.com>
> Date: Wed, 26 Aug 2015 23:26:59 -0700
>
>> +/* similar to strncpy_from_user() but with extra checks */
>> +static void probe_read_string(char *buf, int size, long unsafe_ptr)
>> +{
>> + char dst[4];
>> + int i = 0;
>> +
>> + size--;
>> + for (;;) {
>> + if (probe_kernel_read(dst, (void *) unsafe_ptr, 4))
>> + break;
>
> I don't think this does the right thing when the string is not a multiple
> of 3 and ends at the last byte of a page that ends a valid region of
> kernel memory.
>
> Seeing this kind of error makes me skeptical to the overall value of
> optimizing this :-/
I've considered the case when first two bytes are valid, but the
other two are in a different page. In such case the probe_read_string()
will trim the string and won't be printing these two valid bytes.
I think that's very rare, so I'm picking higher performance for common
case. The strings over > 64 bytes also will be trimmed to 64.
It's a debugging facility, so I felt that's ok.
Fair or you still think it should be per byte copy?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists