[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <555F2E7C.4090707@samsung.com>
Date: Fri, 22 May 2015 15:26:20 +0200
From: Marcin Jabrzyk <m.jabrzyk@...sung.com>
To: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc: minchan@...nel.org, ngupta@...are.org,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
kyungmin.park@...sung.com
Subject: Re: [PATCH] zram: check compressor name before setting it
On 22/05/15 14:44, Sergey Senozhatsky wrote:
> On (05/22/15 11:12), Marcin Jabrzyk wrote:
>>>
>>> no.
>>>
>>> zram already complains about failed comp backend creation.
>>> it's in dmesg (or syslog, etc.):
>>>
>>> "zram: Cannot initialise %s compressing backend"
>>>
>> OK, now I see that. Sorry for the noise.
>>
>>> second, there is not much value in exposing zcomp internals,
>>> especially when the result is just another line in dmesg output.
>>
>> From the other hand, the only valid values that can be written are
>> in 'comp_algorithm'.
>> So when writing other one, returning -EINVAL seems to be reasonable.
>> The user would get immediately information that he can't do that,
>> now the information can be very deferred in time.
>
> it's not.
> the error message appears in syslog right before we return -EINVAL
> back to user.
Yes I've read up the code more detailed and I saw that error message
just before returning to user with error value.
But this happens when 'disksize' is wirtten, not when 'comp_algorithm'.
I understood, the error message in dmesg is clear there is no such
algorithm.
But this is not an immediate error, when setting the 'comp_algorithm',
where we already know that it's wrong, not existing etc.
Anything after that moment would be wrong and would not work at all.
From what I saw 'comp_algorithm_store' is the only *_store in zram that
believes user that he writes proper value and just makes strlcpy.
So what I've ing mind is to provide direct feedback, you have
written wrong name of compressor, you got -EINVAL, please write
correct value. This would be very useful when scripting.
Sorry for being so confusing.
Best regards,
Marcin Jabrzyk
>
> -ss
>
>> I'm not for exposing more internals, but getting -EINVAL would be nice I
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists