> -----Original Message-----
> From: Stephen Smalley [mailto:s...@tycho.nsa.gov]
> Sent: Tuesday, September 20, 2016 5:56 AM
> To: Roberts, William C <william.c.robe...@intel.com>; selinux@tycho.nsa.gov;
> seandroid-l...@tycho.nsa.gov; jda...@google.com
> Subject: Re: [RFC] mmap file_contexts and property_contexts:
> 
> On 09/19/2016 05:45 PM, william.c.robe...@intel.com wrote:
> > From: William Roberts <william.c.robe...@intel.com>
> >
> > THIS IS WIP...
> >
> > Rather than using stdio and making copies, just mmap the files and use
> > the pointers in place. The affect of this change, is that text file

s/affect/effect

> > load time is now faster than binary load time by 4.7% when testing
> > with a file_contexts file from the Android tree. Note that the Android
> > doesn't use monstrous regexs.
> >
> > Times are the average of 3 runs.
> >
> > BEFORE:
> > Text file allocs: 114803
> > Text file load time: 0.266101
> > Bin file allocs: 93073
> > Bin file load time: 0.248757667
> >
> > AFTER:
> > Text file allocs: 103933
> > Text file load time: 0.236192667
> > Bin file allocs: 87645
> > Bin file load time: .247607333
> >
> > THINGS TO DO:
> > 1. What's arm performance like?
> > 2. What interfaces to backends are busted by this (if any)?
> > 3. Test Android Properties
> > 4. Im pretty sure this breaks sefcontext_compile, fix.
> > 5. Test with PCRE2 enabled.
> > 6. Spell check this message!
> > 7. Run checkpatch
> >
> > Signed-off-by: William Roberts <william.c.robe...@intel.com>
> > ---
> >  libselinux/src/label.c                  |   2 -
> >  libselinux/src/label_android_property.c |  22 ++---
> >  libselinux/src/label_file.c             | 140 
> > +++++++++++++++++++-------------
> >  libselinux/src/label_file.h             |  66 +++++++++------
> >  libselinux/src/label_internal.h         |   3 +-
> >  libselinux/src/label_support.c          |  79 ++++++++----------
> >  6 files changed, 172 insertions(+), 140 deletions(-)
> >
> 
> > diff --git a/libselinux/src/label_file.c b/libselinux/src/label_file.c
> > index 7156825..4dc440e 100644
> > --- a/libselinux/src/label_file.c
> > +++ b/libselinux/src/label_file.c
> > @@ -96,43 +96,64 @@ static int nodups_specs(struct saved_data *data, const
> char *path)
> >     return rc;
> >  }
> >
> > -static int process_text_file(FILE *fp, const char *prefix,
> > -                        struct selabel_handle *rec, const char *path)
> > +static inline struct saved_data *rec_to_data(struct selabel_handle
> > +*rec) {
> > +   return (struct saved_data *)rec->data; }
> > +
> > +static char *mmap_area_get_line(struct mmap_area *area) {
> > +   size_t len = area->next_len;
> > +   if (!len)
> > +           return NULL;
> > +
> > +   char *start = area->next_addr;
> > +   char *end = memchr(start, '\n', len);
> > +
> > +   /* the file may not end with a newline */
> > +   if (!end)
> > +           end = (char *)area->next_addr + len - 1;
> > +
> > +   *end = '\0';
> 
> Couldn't this clobber the last character in the file if the file does not end 
> with a
> newline?

Yeah I guess I really can't handle this case without increasing the mapping 
size or allocating
A new buffer to copy into. Considering, that the only time a file not ending 
with a newline
was my own stupid mistake, I am not too worried about the not ending newline, 
especially
considering that the Android build process handles it if it's missing.

Perhaps I could always add a terminating \0 to the mapping by growing it by one 
during mmap
And explicitly setting the byte.

> 
> > +   /* len includes null byte */
> > +   len = end - start;
> > +
> > +   area->next_len -= len + 1;
> > +   area->next_addr = ++end;
> > +   return start;
> > +}
> > +
> > +static int process_text_file(const char *path, const char *prefix,
> > +           struct selabel_handle *rec)
> >  {
> >     int rc;
> > -   size_t line_len;
> >     unsigned int lineno = 0;
> > -   char *line_buf = NULL;
> > +   char *line_buf;
> > +   struct mmap_area *areas = rec_to_data(rec)->mmap_areas;
> > +
> > +   /* mmap_area_get_line() and process_line() require mutable string
> pointers */
> > +   rc = mprotect(areas->addr, areas->len, PROT_READ | PROT_WRITE);
> 
> Just map it with PROT_READ|PROT_WRITE in the beginning.

Yep.


_______________________________________________
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Reply via email to