On Fri, 8 Dec 2017, Geert Uytterhoeven wrote:
> Hi Alan,
>
> On Thu, Dec 7, 2017 at 10:26 PM, Alan Stern wrote:
> > On Thu, 7 Dec 2017, Dan Carpenter wrote:
> >> The standard is to treat them like errors and try press forward in a
> >> degraded mode but don't print a
On Wed, Dec 06, 2017 at 09:20:05PM +0100, Geert Uytterhoeven wrote:
> Hi Markus,
>
> On Wed, Dec 6, 2017 at 6:51 PM, SF Markus Elfring
> wrote:
> >> The system will come to a grinding halt anyway if it can't allocate 24 or
> >> 40 bytes.
> >
> > Maybe.
>
> Since
Hi Alan,
On Thu, Dec 7, 2017 at 10:26 PM, Alan Stern wrote:
> On Thu, 7 Dec 2017, Dan Carpenter wrote:
>> The standard is to treat them like errors and try press forward in a
>> degraded mode but don't print a message. Checkpatch.pl complains if you
>> print a warning
On Thu, 7 Dec 2017, Dan Carpenter wrote:
> On Thu, Dec 07, 2017 at 10:12:27AM -0500, Alan Stern wrote:
> > The real problem is that the kernel development community doesn't have
> > a fixed policy on how to handle memory allocation errors. There are
> > several possibilities:
> >
> > Ignore
On Thu, Dec 07, 2017 at 10:12:27AM -0500, Alan Stern wrote:
> The real problem is that the kernel development community doesn't have
> a fixed policy on how to handle memory allocation errors. There are
> several possibilities:
>
> Ignore them on the grounds that they will never happen.
>
On Thu, 2017-12-07 at 10:12 -0500, Alan Stern wrote:
> The real problem is that the kernel development community doesn't have
> a fixed policy on how to handle memory allocation errors.
[]
> If there was one agreed-upon policy, then we could definitively point
> to old code and say "That's wrong,
On Thu, 7 Dec 2017, Geert Uytterhoeven wrote:
> Hi Alan,
>
> On Wed, Dec 6, 2017 at 11:02 PM, Alan Stern wrote:
> > On Wed, 6 Dec 2017, SF Markus Elfring wrote:
> >> >>> Does the existing memory allocation error message include the
> >> >>> >dev device name and driver
OOM does a dump_stack() so this function's call tree is shown.
>>>
>>> A call stack doesn't tell you which device was being handled.
>>
>> Do you find a default Linux allocation failure report insufficient then?
>>
>> Would you like to to achieve that the requested information can be
On Thu, Dec 07, 2017 at 09:45:38AM +0100, Geert Uytterhoeven wrote:
> >
> > Small allocations never fail in the current kernel.
>
> A few comments (this is in response to a patch from Markus, so there have
> to be lots of questions and uncertainties ;-)
> 1. In the current kernel. What about the
Am Donnerstag, den 07.12.2017, 09:56 +0100 schrieb Greg Kroah-Hartman:
> On Thu, Dec 07, 2017 at 09:45:38AM +0100, Geert Uytterhoeven wrote:
> >
> > A few comments (this is in response to a patch from Markus, so there have
> > to be lots of questions and uncertainties ;-)
>
> Note, because of
On Thu, Dec 07, 2017 at 09:45:38AM +0100, Geert Uytterhoeven wrote:
> A few comments (this is in response to a patch from Markus, so there have
> to be lots of questions and uncertainties ;-)
Note, because of the patch author, I'm not applying it no matter what,
so this discussion is really going
Hi Dan,
On Thu, Dec 7, 2017 at 9:35 AM, Dan Carpenter wrote:
> On Thu, Dec 07, 2017 at 08:40:07AM +0100, Geert Uytterhoeven wrote:
>> On Wed, Dec 6, 2017 at 11:02 PM, Alan Stern
>> wrote:
>> > On Wed, 6 Dec 2017, SF Markus Elfring wrote:
>>
On Thu, Dec 07, 2017 at 08:40:07AM +0100, Geert Uytterhoeven wrote:
> Hi Alan,
>
> On Wed, Dec 6, 2017 at 11:02 PM, Alan Stern wrote:
> > On Wed, 6 Dec 2017, SF Markus Elfring wrote:
> >> >>> Does the existing memory allocation error message include the
> >> >>> >dev
Hi Alan,
On Wed, Dec 6, 2017 at 11:02 PM, Alan Stern wrote:
> On Wed, 6 Dec 2017, SF Markus Elfring wrote:
>> >>> Does the existing memory allocation error message include the
>> >>> >dev device name and driver name? If it doesn't, there will be
>> >>> no way for the
On Wed, 6 Dec 2017, SF Markus Elfring wrote:
> >>> Does the existing memory allocation error message include the
> >>> >dev device name and driver name? If it doesn't, there will be
> >>> no way for the user to tell that the error message is related to the
> >>> device failure.
> >>
> >> No,
>>> Does the existing memory allocation error message include the
>>> >dev device name and driver name? If it doesn't, there will be
>>> no way for the user to tell that the error message is related to the
>>> device failure.
>>
>> No, but the effect is similar.
>>
>> OOM does a dump_stack()
On Wed, 6 Dec 2017, Joe Perches wrote:
> On Wed, 2017-12-06 at 11:45 -0500, Alan Stern wrote:
> > On Wed, 6 Dec 2017, SF Markus Elfring wrote:
> > > Omit an extra message for a memory allocation failure in this function.
>
> Markus' typical terrible commit message.
>
> > > diff --git
Hi Markus,
On Wed, Dec 6, 2017 at 6:51 PM, SF Markus Elfring
wrote:
>> The system will come to a grinding halt anyway if it can't allocate 24 or 40
>> bytes.
>
> Maybe.
Since you've been sending zillions of patches for this, perhaps the time
is ripe to actually
On Wed, 2017-12-06 at 11:45 -0500, Alan Stern wrote:
> On Wed, 6 Dec 2017, SF Markus Elfring wrote:
> > Omit an extra message for a memory allocation failure in this function.
Markus' typical terrible commit message.
> > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
[]
> > @@
> The system will come to a grinding halt anyway if it can't allocate 24 or 40
> bytes.
Maybe.
> Which is BTW more or less the amount of memory saved by killing
> the useless (error) message.
Would you dare to resend this update suggestion after such a view?
Regards,
Markus
--
To unsubscribe
Hi Alan,
On Wed, Dec 6, 2017 at 5:45 PM, Alan Stern wrote:
> On Wed, 6 Dec 2017, SF Markus Elfring wrote:
>
>> From: Markus Elfring
>> Date: Wed, 6 Dec 2017 17:00:18 +0100
>>
>> Omit an extra message for a memory allocation failure in
On Wed, Dec 06, 2017 at 11:45:31AM -0500, Alan Stern wrote:
> On Wed, 6 Dec 2017, SF Markus Elfring wrote:
>
> > From: Markus Elfring
> > Date: Wed, 6 Dec 2017 17:00:18 +0100
> >
> > Omit an extra message for a memory allocation failure in this function.
> >
> >
On Wed, 6 Dec 2017, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Wed, 6 Dec 2017 17:00:18 +0100
>
> Omit an extra message for a memory allocation failure in this function.
>
> This issue was detected by using the Coccinelle software.
>
>
From: Markus Elfring
Date: Wed, 6 Dec 2017 17:00:18 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
24 matches
Mail list logo