From: SF Markus Elfring <elfring@users.sourceforge.net>
To: Ladislav Michl <ladis@linux-mips.org>, linux-omap@vger.kernel.org
Cc: Lee Jones <lee.jones@linaro.org>,
Tony Lindgren <tony@atomide.com>,
LKML <linux-kernel@vger.kernel.org>,
kernel-janitors@vger.kernel.org
Subject: Re: [1/3] mfd/omap-usb-tll: Delete two error messages for a failed memory allocation in usbtll_omap_probe()
Date: Mon, 15 Jan 2018 18:06:20 +0100 [thread overview]
Message-ID: <ead577ac-a36b-dfc4-9f2c-3d5f34495d78@users.sourceforge.net> (raw)
In-Reply-To: <20180115163543.GA10657@lenoch>
>>> Now, if probe function calls devm_kzalloc two times and one of them fails,
>>> you cannot easily say which one without looking at assembly listing.
>>
>> Will this situation change with any other implementation for such backtraces?
>
> How much that situation changes depends mainly on that very person who is
> sending bugreport and his/her ability and willigness to eventually change
> said implementation.
Have you got any more influence on the selection?
Which variant was applied for your example?
> In the other words your question (presumably) expects a world of
> ideal backtraces, which is (so far) rarely the case.
I assume that further software evolution will matter.
Does an article like “The ORCs are coming” (by Jonathan Corbet from 2017-07-20)
point information out which is also useful for this issue here?
https://lwn.net/Articles/728339/
> Anyway, if we agree to change the way we allocate driver data here,
> the issue this debate is about will no longer exist.
Does your update suggestion contain still any additional error messages for
memory allocation failures?
Regards,
Markus
next prev parent reply other threads:[~2018-01-15 17:06 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-15 13:14 [PATCH 0/3] mfd/omap-usb-tll: Adjustments for usbtll_omap_probe() SF Markus Elfring
2018-01-15 13:15 ` [PATCH 1/3] mfd/omap-usb-tll: Delete two error messages for a failed memory allocation in usbtll_omap_probe() SF Markus Elfring
2018-01-15 13:41 ` Ladislav Michl
2018-01-15 15:34 ` Roger Quadros
2018-01-15 15:38 ` SF Markus Elfring
2018-01-15 16:05 ` Ladislav Michl
2018-01-15 16:21 ` [1/3] " SF Markus Elfring
2018-01-15 16:35 ` Ladislav Michl
2018-01-15 17:06 ` SF Markus Elfring [this message]
2018-01-15 17:41 ` Ladislav Michl
2018-01-15 18:12 ` SF Markus Elfring
2018-01-15 18:30 ` Ladislav Michl
2018-01-15 19:04 ` mfd/omap-usb-tll: Allocate driver data at once " SF Markus Elfring
2018-01-15 19:23 ` Ladislav Michl
2018-01-15 19:40 ` SF Markus Elfring
2018-01-15 19:26 ` SF Markus Elfring
2018-01-15 19:33 ` Ladislav Michl
2018-01-15 13:16 ` [PATCH 2/3] mfd/omap-usb-tll: Improve a size determination " SF Markus Elfring
2018-01-22 15:50 ` Lee Jones
2018-01-15 13:17 ` [PATCH 3/3] mfd/omap-usb-tll: Return an error code only as a constant " SF Markus Elfring
2018-01-22 15:50 ` Lee Jones
2018-01-23 13:04 ` Lee Jones
2018-01-23 14:43 ` [3/3] " SF Markus Elfring
2018-01-23 15:04 ` Lee Jones
2018-01-23 17:13 ` Ladislav Michl
2018-01-24 15:16 ` Lee Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ead577ac-a36b-dfc4-9f2c-3d5f34495d78@users.sourceforge.net \
--to=elfring@users.sourceforge.net \
--cc=kernel-janitors@vger.kernel.org \
--cc=ladis@linux-mips.org \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).