linux-kernel - Re: staging: ks7010: Replace three printk() calls by pr

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:	Sat, 13 Aug 2016 21:30:52 +0200
From:	SF Markus Elfring <elfring@...rs.sourceforge.net>
To:	Joe Perches <joe@...ches.com>
Cc:	devel@...verdev.osuosl.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Wolfram Sang <wsa@...-dreams.de>,
	LKML <linux-kernel@...r.kernel.org>,
	kernel-janitors@...r.kernel.org,
	Julia Lawall <julia.lawall@...6.fr>,
	Jean Delvare <jdelvare@...e.de>
Subject: Re: staging: ks7010: Replace three printk() calls by pr_err()

> I think pr_<level> is OK if reworking the code
> to support dev_<level> is not easy.

Thanks for this explanation. - It sounds more constructive than the previous short
feedback "Not correct".

>> Would you accept that another update will be appended to the discussed patch series?
> 
> No.  Patches should not knowingly introduce defects
> that are corrected in follow-on patches.

This view is fine in principle.

I am just curious on the preferred sequence to fix the affected implementation details.

1. I imagine that my questionable update suggestion "[PATCH v2 08/10] staging: ks7010:
   Replace three printk() calls by pr_err()" can be skipped and the remaining logging
   calls will be improved somehow a bit later.

Or:

2. Do you want a resend of this whole patch series?

>>> alloc_etherdev already does a dump_stack so the OOM isn't useful.
>> Does this information indicate that this printk() (or pr_err()) call
>> should be deleted?
> 
> Markus, I don't know if it's your lack of English
> comprehension or not, but it's fairly obvious from
> my reply that this line should be deleted,

I was unsure if this view fits to a consensus also by other developers.

It might be that I can occasionally become picky to check if other contributors
insist on the usage of a specific error message.

> either in this patch or a follow-on.

I would prefer another addition (or source code clean-up) later.
Could it happen that so many error messages are update candidates (for deletion)
so that no places remain where a pr_err() call would make sense in this
software module?

Regards,
Markus