Re: [Qemu-devel] [PATCH 03/10] pseries: Clean up hash page table allocation error handling

[Alexey Kardashevskiy <aik@ozlabs.ru>]

On 01/18/2016 04:35 PM, David Gibson wrote:
> On Mon, Jan 18, 2016 at 04:17:08PM +1100, Alexey Kardashevskiy wrote:
>> On 01/18/2016 03:42 PM, David Gibson wrote:
>>> On Mon, Jan 18, 2016 at 01:44:00PM +1100, Alexey Kardashevskiy wrote:
>>>> On 01/15/2016 11:00 PM, David Gibson wrote:
>>>>> The spapr_alloc_htab() and spapr_reset_htab() functions currently handle
>>>>> all errors with error_setg(&error_abort, ...).
>>>>>
>>>>> But really, the callers are really better placed to decide on the error
>>>>> handling.  So, instead make the functions use the error propagation
>>>>> infrastructure.
>>>>>
>>>>> In the callers we change to &error_fatal instead of &error_abort, since
>>>>> this can be triggered by a bad configuration or kernel error rather than
>>>>> indicating a programming error in qemu.
>>>>>
>>>>> While we're at it improve the messages themselves a bit, and clean up the
>>>>> indentation a little.
>>>>>
>>>>> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>>>>> ---
>>>>>   hw/ppc/spapr.c | 24 ++++++++++++++++--------
>>>>>   1 file changed, 16 insertions(+), 8 deletions(-)
>>>>>
>>>>> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
>>>>> index b7fd09a..d28e349 100644
>>>>> --- a/hw/ppc/spapr.c
>>>>> +++ b/hw/ppc/spapr.c
>>>>> @@ -1016,7 +1016,7 @@ static void emulate_spapr_hypercall(PowerPCCPU *cpu)
>>>>>   #define CLEAN_HPTE(_hpte)  ((*(uint64_t *)(_hpte)) &= tswap64(~HPTE64_V_HPTE_DIRTY))
>>>>>   #define DIRTY_HPTE(_hpte)  ((*(uint64_t *)(_hpte)) |= tswap64(HPTE64_V_HPTE_DIRTY))
>>>>>
>>>>> -static void spapr_alloc_htab(sPAPRMachineState *spapr)
>>>>> +static void spapr_alloc_htab(sPAPRMachineState *spapr, Error **errp)
>>>>>   {
>>>>>       long shift;
>>>>>       int index;
>>>>> @@ -1031,7 +1031,8 @@ static void spapr_alloc_htab(sPAPRMachineState *spapr)
>>>>>            * For HV KVM, host kernel will return -ENOMEM when requested
>>>>>            * HTAB size can't be allocated.
>>>>>            */
>>>>> -        error_setg(&error_abort, "Failed to allocate HTAB of requested size, try with smaller maxmem");
>>>>> +        error_setg_errno(errp, -shift,
>>>>> +                         "Error allocating KVM hash page table, try smaller maxmem");
>>>>>       } else if (shift > 0) {
>>>>>           /*
>>>>>            * Kernel handles htab, we don't need to allocate one
>>>>> @@ -1040,7 +1041,10 @@ static void spapr_alloc_htab(sPAPRMachineState *spapr)
>>>>>            * but we don't allow booting of such guests.
>>>>>            */
>>>>>           if (shift != spapr->htab_shift) {
>>>>> -            error_setg(&error_abort, "Failed to allocate HTAB of requested size, try with smaller maxmem");
>>>>> +            error_setg(errp,
>>>>> +                "Small allocation for KVM hash page table (%ld < %"
>>>>> +                PRIu32 "), try smaller maxmem",
>>>>
>>>>
>>>>
>>>> Even though it is not in the CODING_STYLE, I have not seen anyone objecting
>>>> the very good kernel's "never break user-visible strings" rule or rejecting
>>>> patches with user-visible strings failing to fit 80 chars limit.
>>>
>>> I'm not.  Or rather, the string is already broken by the PRIu32, so
>>> the newline doesn't make it any less greppable.
>>
>>
>> "KVM hash page table.*smaller maxmem" stopped working. Not a big deal but I
>> do not see any win in breaking strings anyway.
>
> The problem is that the current pre-commit hooks don't agree with
> you.  They seem to allow long unbroken strings, but if there's a break
> like the PRIu32, they won't permit the commit.


checkpatch.pl reports it as "WARNING: line over 80 characters", not an 
ERROR, so I'd say the hook has a problem.



-- 
Alexey