Re: svn commit: r1887497 - in /apr/apr/branches/1.7.x: ./ CHANGES mmap/unix/mmap.c test/data/mmap_large_datafile.txt test/testfnmatch.c test/testmmap.c

2022-06-30 Thread William A Rowe Jr
IMNSO opinion, this seems like a somewhat safe 1.8 change. What you
want to ask is how someone who "discovers" apr.so.1 (.8) would react
with 1.7 code, and if that's clean and using only public API's, it
makes sense to me. That's not the case for other changes, but for this
one it shouldn't shock anyone who doesn't explicitly ask for -lapr
against libapr.so.1.7

On Thu, Jun 30, 2022 at 7:39 AM Yann Ylavic  wrote:
>
> On Wed, Jun 29, 2022 at 4:49 PM William A Rowe Jr  wrote:
> >
> > The eventual change still is present for apr
> > 1.8 adopters.
> >
> > Thoughts? ylavic are you willing to revert?
>
> It seems that no one is using apr_mmap_create() with an offset != 0 or
> the bug would have been reported (PR 65158 proved to be a cifs
> filesystem bug finally). Well, apr_bucket_file reads can use an mmap
> offset if planets misalign still, and that's possibly why we had quite
> some issues for "EnableMMap on" in httpd (IIRC), but since it was
> never nailed to this bug it usually ends with "please EnableMMap =>
> off"..
> So let's revert, if something comes up around this, it's probably
> another case where I'll first ask: can you reproduce with apr-1.8?
>
> For 1.8.x then (we can fix it there right?), I'd rather we revert this
> change and r1887508 to merge trunk's r1887060 and r1887506 directly
> (i.e. without the API workaround-try of this 1.7.x merge).
> That is, add the "poffset" field to (the end of) apr_mmap_t and be
> done with no tricks. But since I'm not sure what we can or not do with
> a minor bump I'll ask, can we do that?
>
> Regards;
> Yann.


Re: svn commit: r1887497 - in /apr/apr/branches/1.7.x: ./ CHANGES mmap/unix/mmap.c test/data/mmap_large_datafile.txt test/testfnmatch.c test/testmmap.c

2022-06-30 Thread Yann Ylavic
On Wed, Jun 29, 2022 at 4:49 PM William A Rowe Jr  wrote:
>
> The eventual change still is present for apr
> 1.8 adopters.
>
> Thoughts? ylavic are you willing to revert?

It seems that no one is using apr_mmap_create() with an offset != 0 or
the bug would have been reported (PR 65158 proved to be a cifs
filesystem bug finally). Well, apr_bucket_file reads can use an mmap
offset if planets misalign still, and that's possibly why we had quite
some issues for "EnableMMap on" in httpd (IIRC), but since it was
never nailed to this bug it usually ends with "please EnableMMap =>
off"..
So let's revert, if something comes up around this, it's probably
another case where I'll first ask: can you reproduce with apr-1.8?

For 1.8.x then (we can fix it there right?), I'd rather we revert this
change and r1887508 to merge trunk's r1887060 and r1887506 directly
(i.e. without the API workaround-try of this 1.7.x merge).
That is, add the "poffset" field to (the end of) apr_mmap_t and be
done with no tricks. But since I'm not sure what we can or not do with
a minor bump I'll ask, can we do that?

Regards;
Yann.


Re: svn commit: r1887497 - in /apr/apr/branches/1.7.x: ./ CHANGES mmap/unix/mmap.c test/data/mmap_large_datafile.txt test/testfnmatch.c test/testmmap.c

2022-06-29 Thread William A Rowe Jr
This change does introduce an API change, and a somewhat possibly dangerous
structure size alteration, and seems to be out of bounds for apr 1.7.x
branch, as
identified in the commit message.

Anyone using a build crossing runtimes between apr 1.7.0 and 1.7.1 may
experience
unintended side-effects. The eventual change still is present for apr
1.8 adopters.

Thoughts? ylavic are you willing to revert?

On Thu, Mar 11, 2021 at 10:21 AM  wrote:
>
> Author: ylavic
> Date: Thu Mar 11 16:21:07 2021
> New Revision: 1887497
>
> URL: http://svn.apache.org/viewvc?rev=1887497=rev
> Log:
> Merge r1887060 from trunk:
>
> Align apr_mmap()ing offset to a page boundary.  PR 65158.
>
> This is requirement for unix systems, and otherwise can cause failures or
> undefined behaviour with some filesystems.
>
> Add apr_mmap_t->poffset on unixes to track the offset to the previous page,
> relative to the user requested/actual offset. This allows ->mm and ->size to
> still point to the actual data, while munmap() now deletes the full range
> from the start of the page.
>
> Tests updated accordingly.
>
>
> * Changes between r1887060 and this 1.7.x backport
>
> Since the layout of struct apr_mmap_t cannot change (non opaque), the poffset
> is over-allocated in mmap/unix/mmap.cmmap.c which uses this layout internally:
> struct mm_layout {
> apr_mmap_t mm;
> apr_off_t poffset;
> };
>
> This works for all the apr_mmap_t created by apr_mmap_create() with which any
> apr_mmap_*() function can then be called.
>
> If a user creates an apr_mmap_t "by hand", with this change it cannot be 
> passed
> to apr_mmap_dup() without causing an out-of-bound read. This is hardly a new
> limitation though, the refcounting which is the point of apr_mmap_dup() and
> apr_mmap_delete() comes from the private function mmap_cleanup() anyway, so
> there is no point in using these two functions with hand made apr_mmap_t (if
> there ever was a point in the first place to create an hand made 
> apr_mmap_t..).
>
>
> Submitted by: ylavic
>
> Added:
> apr/apr/branches/1.7.x/test/data/mmap_large_datafile.txt
>   - copied unchanged from r1887060, 
> apr/apr/trunk/test/data/mmap_large_datafile.txt
> Modified:
> apr/apr/branches/1.7.x/   (props changed)
> apr/apr/branches/1.7.x/CHANGES
> apr/apr/branches/1.7.x/mmap/unix/mmap.c
> apr/apr/branches/1.7.x/test/testfnmatch.c
> apr/apr/branches/1.7.x/test/testmmap.c
>
> Propchange: apr/apr/branches/1.7.x/
> --
>   Merged /apr/apr/trunk:r1887060
>
> Modified: apr/apr/branches/1.7.x/CHANGES
> URL: 
> http://svn.apache.org/viewvc/apr/apr/branches/1.7.x/CHANGES?rev=1887497=1887496=1887497=diff
> ==
> --- apr/apr/branches/1.7.x/CHANGES [utf-8] (original)
> +++ apr/apr/branches/1.7.x/CHANGES [utf-8] Thu Mar 11 16:21:07 2021
> @@ -1,6 +1,8 @@
>   -*- coding: utf-8 -*-
>  Changes for APR 1.7.1
>
> +  *) Align apr_mmap()ing offset to a page boundary.  PR 65158.  [Yann Ylavic]
> +
>*) Don't silently set APR_FOPEN_NOCLEANUP for apr_file_mktemp() created 
> file
>   to avoid a fd and inode leak when/if later passed to 
> apr_file_setaside().
>   [Yann Ylavic]
>
> Modified: apr/apr/branches/1.7.x/mmap/unix/mmap.c
> URL: 
> http://svn.apache.org/viewvc/apr/apr/branches/1.7.x/mmap/unix/mmap.c?rev=1887497=1887496=1887497=diff
> ==
> --- apr/apr/branches/1.7.x/mmap/unix/mmap.c (original)
> +++ apr/apr/branches/1.7.x/mmap/unix/mmap.c Thu Mar 11 16:21:07 2021
> @@ -14,6 +14,8 @@
>   * limitations under the License.
>   */
>
> +#include 
> +
>  #include "apr.h"
>  #include "apr_private.h"
>  #include "apr_general.h"
> @@ -33,6 +35,9 @@
>  #if APR_HAVE_STDIO_H
>  #include 
>  #endif
> +#if APR_HAVE_UNISTD_H
> +#include   /* for sysconf() */
> +#endif
>  #ifdef HAVE_SYS_STAT_H
>  #include 
>  #endif
> @@ -42,6 +47,34 @@
>
>  #if APR_HAS_MMAP || defined(BEOS)
>
> +#ifndef BEOS
> +struct mm_layout {
> +apr_mmap_t mm;
> +apr_off_t poffset;
> +};
> +
> +static APR_INLINE
> +apr_mmap_t *alloc_with_poffset(apr_pool_t *p)
> +{
> +struct mm_layout *layout = apr_pcalloc(p, sizeof(*layout));
> +return >mm;
> +}
> +
> +static APR_INLINE
> +void set_poffset(apr_mmap_t *mm, apr_off_t poffset)
> +{
> +struct mm_layout *layout = (struct mm_layout *)mm;
> +layout->poffset = poffset;
> +}
> +
> +static APR_INLINE
> +apr_off_t get_poffset(apr_mmap_t *mm)
> +{
> +struct mm_layout *layout = (struct mm_layout *)mm;
> +return layout->poffset;
> +}
> +#endif
> +
>  static apr_status_t mmap_cleanup(void *themmap)
>  {
>  apr_mmap_t *mm = themmap;
> @@ -61,7 +94,7 @@ static apr_status_t mmap_cleanup(void *t
>  #ifdef BEOS
>  rv = delete_area(mm->area);
>  #else
> -rv = munmap(mm->mm,