lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 27 Apr 2015 17:09:22 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Petr Mladek <pmladek@...e.cz>
Cc:	akpm@...ux-foundation.org, davem@...emloft.net,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	Kay Sievers <kay@...y.org>
Subject: Re: [PATCH 04/16] printk: implement support for extended console
 drivers

Hello, Petr.

Sorry about the delay.

On Mon, Apr 20, 2015 at 05:43:07PM +0200, Petr Mladek wrote:
...
> > * Extended message formatting for console drivers is enabled iff there
> 
> s/iff/if/

if and only if

> I was afraid that there might be a potential buffer overflow because
> the user-provided dict need not be limited by '\0'. But LOG_DICT_META
> is used only with the internal data that are safe. We might document
> this as well.
> 
> BTW: Do you want to print the internal dict when calling this function
> in devkmsg_read()?

No, plesae see below.

> > +		scnprintf(fragid_buf, sizeof(fragid_buf),
> > +			  ",fragid=%llu", fragid);
> > +	return scnprintf(buf, size, "%u,%llu,%llu,%c%s;",
> > +			 (msg->facility << 3) | msg->level, seq, ts_usec, cont,
> > +			 fragid_buf);
> 
> The above comment suggests that  "cont" and "fragid_buf" are delimited
> by a comma but it is not used here. Is it by intention.

Hmm... how is it not?  The fragid printf has preceding comma.

> > +		dict_len = scnprintf(dict_buf, sizeof(dict_buf), "FRAGID=%llu",
> > +				     cont.fragid);
> > +		log_store(cont.facility, cont.level,
> > +			  flags | LOG_NOCONS | LOG_DICT_META,
> > +			  cont.ts_nsec, dict_buf, dict_len, cont.buf, cont.len);
> 
> I wonder if it would make sense to restart fragid here. Another line
> will get distinguished by "seqnum".

That'd assume that there can only ever be a single continuation
buffer, which is true now but it's possible that we may want to make
it per-cpu in the future.

> Sigh, the whole mess is caused by the fact that we could not extend
> struct printk_log easily. It would be much better if we could put
> fragid there. I finally understand why you need to reuse the dict.

I've been thinking about it and using dict area for internal metadata
is indeed quite messy.  I think a better way to do it is declaring
dict_len as a union w/ fragid.  This'd limit the fragid to 16bit but
that should be more than enough and we can do away with the string
formatting and reading back.

> Another solution would be to allow to disable the continuous buffer
> via some boot option or /sys/kernel/debug entry if you want to debug
> such a problem and have problem with the partial flushing.

It isn't really about debugging partial flushing itself but rather
always being able to push out the messages before the printk
invocation finishes.

Thanks.

-- 
tejun
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ