Re: [PATCH] ata_piix: minor typo fixes and threading fix

[Levente Kurusa <levex@linux.com>]

2013-09-26 19:57 keltezéssel, Kay Sievers írta:
> On Thu, Sep 26, 2013 at 4:09 PM, Tejun Heo <tj@kernel.org> wrote:
>> (cc'ing Kay)
>>
>> On Wed, Sep 25, 2013 at 04:40:30PM +0200, Levente Kurusa wrote:
>>> I am getting the following output:
>>> [    2.236379] ata_piix 0000:00:1f.2: MAP [
>>> [    2.236492]  P0 P2 -- -- ]
>>> Instead of the expected:
>>> [    2.236379] ata_piix 0000:00:1f.2: MAP [ P0 P2 -- -- ]
>>>
>>> This might be a minor problem, but I think it is better the second way.
>>> Of course, now that I better understand the code, I see that my fix to this,
>>> is not the best. I will make a new patch, if you think this should be fixed.
>>
>> Hmmm... so, you're saying pr_cont() is misbehaving after dev_info()?
>> If so, we don't want to paper over that from a low level driver like
>> ata_piix.  Let's find out what's going on with pr_cont().
>>
>> Kay, Levente is seeing the above output from
>> drivers/ata/ata_piix.c::piix_init_sata_map().  Any ideas?
>
> Yes, the dev_printk() versions are "atomic lines", cannot be
> concatenated with other invocations of printk() like the normal
> printks can. The reason is that the dev_* versions carry structured
> data to userspace, and there, the logs are indexed by device.
>
> We don't want to allow the convenient but very racy and
> non-thread-safe concatenation lines for dev_* versions, they might
> pick up unrelated text fragments from other threads into the logged
> text line; userspace (non-human tools) can not really cope with that.
>
> So, the printk should not use the dev_* version, or print all in one
> call, if a single line is expected.
>
> Kay
>

Thank you Kay for clarifying this! I think I will go with
creating a buffer, and printing this all in one line.

Tejun, during this weekend I will create a patch that
hopefully fixes this. However, if you think that setting
up a temporary buffer is inappropriate, please comment.


Thank you,
Levente Kurusa