From: Sven Schnelle <svens@linux.ibm.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Heiko Carstens <hca@linux.ibm.com>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
linux-s390@vger.kernel.org
Subject: Re: [PATCH 2/2] s390: convert to GENERIC_VDSO
Date: Tue, 04 Aug 2020 11:22:20 +0200 [thread overview]
Message-ID: <yt9d5z9yhik3.fsf@linux.ibm.com> (raw)
In-Reply-To: <873653mswn.fsf@nanos.tec.linutronix.de> (Thomas Gleixner's message of "Mon, 03 Aug 2020 21:27:36 +0200")
Hi,
Thomas Gleixner <tglx@linutronix.de> writes:
> Heiko Carstens <hca@linux.ibm.com> writes:
>
>> On Mon, Aug 03, 2020 at 06:05:24PM +0200, Thomas Gleixner wrote:
>>> +/**
>>> + * vdso_update_begin - Start of a VDSO update section
>>> + *
>>> + * Allows architecture code to safely update the architecture specific VDSO
>>> + * data.
>>> + */
>>> +void vdso_update_begin(void)
>>> +{
>>> + struct vdso_data *vdata = __arch_get_k_vdso_data();
>>> +
>>> + raw_spin_lock(&timekeeper_lock);
>>> + vdso_write_begin(vdata);
>>> +}
>>
>> I would assume that this only works if vdso_update_begin() is called
>> with irqs disabled, otherwise it could deadlock, no?
>
> Yes.
>
>> Maybe something like:
>>
>> void vdso_update_begin(unsigned long *flags)
>> {
>> struct vdso_data *vdata = __arch_get_k_vdso_data();
>>
>> raw_spin_lock_irqsave(&timekeeper_lock, *flags);
>> vdso_write_begin(vdata);
>
> Shudder. Why not returning flags?
>
>> }
>>
>> void vdso_update_end(unsigned long *flags)
>
> Ditto, why pointer and not value?
>
>> {
>> struct vdso_data *vdata = __arch_get_k_vdso_data();
>>
>> vdso_write_end(vdata);
>> __arch_sync_vdso_data(vdata);
>> raw_spin_unlock_irqrestore(&timekeeper_lock, *flags);
>> }
>>
>> ? Just wondering.
>
> Thought about that briefly, but then hated the flags thing and delegated
> it to the caller. Lockdep will yell if that lock is taken with
> interrupts enabled :)
>
> But aside of the pointer vs. value thing, I'm fine with doing it in the
> functions.
Thanks Thomas & Heiko. I'll incorporate the changes into my patchset and
send an updated version. Thomas, i think it's fine if i update your
patch and we take it through the s390 tree?
Regards
Sven
prev parent reply other threads:[~2020-08-04 9:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-03 5:56 [PATCH RFC] s390: convert to GENERIC_VDSO Sven Schnelle
2020-08-03 5:56 ` [PATCH 1/2] vdso: allow to add architecture-specific vdso data Sven Schnelle
2020-08-03 12:13 ` Thomas Gleixner
2020-08-03 14:01 ` Sven Schnelle
2020-08-03 5:56 ` [PATCH 2/2] s390: convert to GENERIC_VDSO Sven Schnelle
2020-08-03 12:29 ` Thomas Gleixner
2020-08-03 12:29 ` Thomas Gleixner
2020-08-03 14:09 ` Sven Schnelle
2020-08-03 16:05 ` Thomas Gleixner
2020-08-03 18:44 ` Heiko Carstens
2020-08-03 19:27 ` Thomas Gleixner
2020-08-03 20:12 ` Heiko Carstens
2020-08-04 9:22 ` Sven Schnelle [this message]
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=yt9d5z9yhik3.fsf@linux.ibm.com \
--to=svens@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=vincenzo.frascino@arm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.