On Tue, Jan 16, 2024 at 10:01:47AM +0200, Nikolay Borisov wrote: > > > On 16.01.24 г. 9:28 ч., Kirill A. Shutemov wrote: > > <snip> > > > > > @@ -41,6 +44,9 @@ > > > > static atomic_long_t nr_shared; > > > > +static atomic_t conversions_in_progress; > > > > +static bool conversion_allowed = true; > > > > > > Given the usage model of this variable, shouldn't it be simply accessed via > > > READ/WRITE_ONCE macros? > > > > What do you see it changing? > > > Serving as documentation that you are accessing a shared variable without an > explicit lock (unless I'm missing something). conversion_allowed can be read > by multiple threads, no ? And it's written by a single thread? I don't think READ_ONCE()/WRITE_ONCE() have documentation sense you imply. I would argue adding them will add more confusion as they serve no purpose in this context: issuing multiple loads/stores for the variable have no impact on outcome. > > kexec on AMD will not work without them, I think. But noops makes sense > > anyway. Will fix. > > I'm not disputing whether those are needed for AMD or not, that way I see it > you make those callbacks mandatory in the case of CC_ATTR_GUEST_MEM_ENCRYPT > being present, yet only implement them for TDX. So in the case of AMD they > will be NULL and so AMD with kexec enabled (albeit erroneously) will crash, > no ? As I said, I will fix it. -- Kiryl Shutsemau / Kirill A. Shutemov _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
