Re: What's tha KOBJ_MAX action used for?
Thanks for your replies. Also, thanks greg for your thorough review on my
corresponding patch (https://lkml.org/lkml/2020/7/14/84), I learned a lot!
I have been digging around about Kobjects a bit. They are nicely documented.
Still, no documentation exists about this KOBJ_MAX action.
This post on stackoverflow mentions that it's a "special" field that marks the
end of the enum (if I understand correctly):
https://stackoverflow.com/a/23149574/9046809
This lead me to think that this is a convention I'm not aware of, but
I could not find any
resources that described such a thing, so I discarded that idea.
If I understand correctly, this action can in fact be passed to userspace by the
kobject_uevent function, so it would be a bad idea to remove it. Is my
reasoning correct?
regards,
Garrit
Am Di., 14. Juli 2020 um 04:15 Uhr schrieb Valdis Klētnieks
:
>
> On Mon, 13 Jul 2020 14:35:23 +0200, Greg KH said:
> > On Mon, Jul 13, 2020 at 01:17:25PM +0200, Garrit Franke wrote:
> > > Hi all,
> > >
> > > I was wondering, what the KOBJ_MAX action in the kobject.h file does.
> > > It is self explainatory what KOBJ_ADD, KOBJ_REMOVE etc. are used for, but
> > > KOBJ_MAX puzzles me.
>
> > > Can it maybe even be removed?
> >
> > Maybe it can, try it and see!
>
> I suspect that this line:
> for (action = 0; action < ARRAY_SIZE(kobject_actions); action++) {
> in lib/kobject_uenvent.c:kobject_action_type() combined with the fact that
> kobject_actions[] does *not* actually match the enum regardless of the comment
> above it, result in it being superfluous.
>
> Figuring out why is left as an exercise for the student.
>
> Oh, and if I had a dollar for every time I've been surprised by creative
> abuse of
> the cpp ## operator... :)
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: What's tha KOBJ_MAX action used for?
A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
A: No.
Q: Should I include quotations after my reply?
http://daringfireball.net/2007/07/on_top
On Tue, Jul 14, 2020 at 04:36:15PM +0200, Garrit Franke wrote:
> Thanks for your replies. Also, thanks greg for your thorough review on my
> corresponding patch (https://lkml.org/lkml/2020/7/14/84), I learned a lot!
>
> I have been digging around about Kobjects a bit. They are nicely documented.
> Still, no documentation exists about this KOBJ_MAX action.
Please look at commit 60a96a59569b ("Driver core: accept all valid
action-strings in uevent-trigger") in the tree. That's when it was
added, and it was used.
Then a short bit later, 5c5daf657cb5 ("Driver core: exclude
kobject_uevent.c for !CONFIG_HOTPLUG") stopped using it in the .c files,
and no one noticed that it should have been removed.
> This post on stackoverflow mentions that it's a "special" field that marks the
> end of the enum (if I understand correctly):
> https://stackoverflow.com/a/23149574/9046809
> This lead me to think that this is a convention I'm not aware of, but
> I could not find any
> resources that described such a thing, so I discarded that idea.
>
> If I understand correctly, this action can in fact be passed to userspace by
> the
> kobject_uevent function, so it would be a bad idea to remove it. Is my
> reasoning correct?
Yes, if it did get passed to userspace. But it doesn't, as you can see
by the last commit I referenced above. We pass strings to userspace for
the kobject events and we take that same string sent to us from
userspace to send "fake" kobject uevents as well.
Also, the loop that we checked for KOBJ_MAX is no longer present, we do
a much more sane ARRAY_SIZE() check, right? So I don't think it's
needed.
Can you rewrite your changelog text with all of this new information and
resend it? I'll be glad to take the patch then.
thanks,
greg k-h
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Turn private hugetlb mapping into VM_SHARED
> Hello, list, > > I am working on a tool to introspect live memory of KVM machines, and > mmapping its memory, instead of calling process_vm_readv on every read, would > increase its performance significantly. Understandably, almost all virtual > machine monitors (like QEMU) create private mappings for the memory. So, > trying to understand the memory managment subsystem I am hoping to write a > kernel module to do the remappings, and conversion from private, to shared > mappings. > > My current focus is on hugetlb pages. At first, I remapped the pages using > remap_pfn_range, but there is a memory safety risk when the VM shuts off, and > that memory gets used elsewhere. Now, I am trying to turn the underlying > mapping into a shared one, so that the kernel can keep track of the memory > used. What would be the best way to do so? > > I noticed there is resv_map that stores represented mappings, and while on > private mappings it's on vma, on the shared ones - it is in the inode, but > making the inode point to the VMAs map leads to a bus error in userspace. I > must be missing some key pieces. > > Does anyone know how to best achieve what I am trying to? Or is it something > fundamentally wrong to do? > > Many thanks, > Auri B. It appears I have been mistaken when it came to remap_pfn_range being memory unsafe, I just haven't read get_user_pages_remote documentation attentively enough. Sorry for that, this whole unshared -> shared mapping change is very much not the right thing to do. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
