Messages in this thread | | | Subject | Re: [PATCH V5 7/7] x86/jump_label: Batch jump label updates | From | Daniel Bristot de Oliveira <> | Date | Thu, 2 May 2019 22:18:12 +0200 |
| |
On 4/15/19 1:54 PM, Peter Zijlstra wrote: > So how about we do something like: > > +static struct bp_patching_desc { > + int nr_entries; > + struct text_patch_loc vec[PAGE_SIZE / sizeof(struct text_patch_loc)]; > +} bp_patching; > > and call it a day? > > Then we have static storage, no allocation, no fail paths. > > Also note that I removed that whole in_progress thing, as that is > completely redudant vs !!nr_entries.
Hi Peter,
I am finishing the next version, but now I am in a dilemma.
If I use:
static struct bp_patching_desc { int nr_entries; struct text_patch_loc vec[PAGE_SIZE / sizeof(struct text_patch_loc)]; } bp_patching;
The in_progress is still needed because nr_entries will increase while queuing... and so we would enter in the int3 before we actually need.
It will also need a new function on alternative.c to queue each entry into the vector and change the text_poke_bp_batch() to a text_poke_bp_apply() without arguments, +- replicating the arch_jump_label_transform_queue() and arch_jump_label_transform_apply().
[ and probably also take the text_mutex while queuing... and release in the apply ]
OR
I can declare a vector and a counter in arch/x86/jump_label.c, like this:
#define TP_VEC_MAX (PAGE_SIZE / sizeof(struct text_patch_loc)) static struct text_patch_loc tp_vec[TP_VEC_MAX]; int tp_nr_entries = 0;
and use the arch_jump_label_transform_batch() as it is now, i.e:
void text_poke_bp_batch(struct text_patch_loc *tp, unsigned int nr_entries)
In this case, we do not need the in_progress because the bp_patching_desc.nr_entries is filled only when in progress.
so, which path should I take?
Thanks -- Daniel
| |