Re: httpd 2.4.25, mpm_event, ssl: segfaults

side ACKs that packet. On Mon, Feb 27, 2017 at 2:25 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Mon, Feb 27, 2017 at 12:16 PM, Jacob Champion <champio...@gmail.com> > wrote: > > > > On 02/23/2017 04:48 PM, Yann Ylavic wrote: > >> On Wed, Feb 22,

Re: httpd 2.4.25, mpm_event, ssl: segfaults

On Thu, Feb 23, 2017 at 7:48 PM, Yann Ylavic <ylavic@gmail.com> wrote: > On Wed, Feb 22, 2017 at 8:55 PM, Daniel Lescohier wrote: > > > > IOW: > > read():Three copies: copy from filesystem cache to httpd read() buffer to > > encrypted-data buffer to kernel soc

Re: httpd 2.4.25, mpm_event, ssl: segfaults

Why would high-order memory allocations be a problem in userspace code, which is using virtual memory? I thought high-order allocations is a big problem in kernel space, which has to deal with physical pages. But when you write to a socket, doesn't the kernel scatter the userspace buffer into

Re: httpd 2.4.25, mpm_event, ssl: segfaults

On Wed, Feb 22, 2017 at 2:42 PM, Jacob Champion wrote: > Ah, but they *do*, as Yann pointed out earlier. We can't just deliver the > disk cache to OpenSSL for encryption; it has to be copied into some > addressable buffer somewhere. That seems to be a major reason for the >

Re: httpd 2.4.25, mpm_event, ssl: segfaults

Is the high-level issue that: for serving static content over HTTP, you can use sendfile() from the OS filesystem cache, avoiding extra userspace copying; but if it's SSL, or any other dynamic filtering of content, you have to do extra work in userspace? On Thu, Feb 16, 2017 at 6:01 PM, Yann

Re: httpd 2.4.25, mpm_event, ssl: segfaults

Here is how cache page replacement is done in Linux: https://linux-mm.org/PageReplacementDesign On Tue, Feb 7, 2017 at 5:32 AM, Niklas Edmundsson wrote: > On Mon, 6 Feb 2017, Jacob Champion wrote: > > > > Considering the massive amount of caching that's built into the entire

Re: allow newlines in T_ESCAPE_LOGITEM?

Of course, if you use "reliable piped logging" then if you also write more than PIPE_BUF bytes (4kiB on Linux) in a log line, it's not guaranteed to be atomic. I have been thinking of how to work around that limit, by logging to an Apache Flume Thrift RPC port. But to avoid the 4kiB limit you'd

Re: allow newlines in T_ESCAPE_LOGITEM?

Doing this in the httpd server will prevent use-cases of programmatically parsing the log files. I think the data in the file should support both use-cases - Parsing the log file data for data analysis. - Humans reading the logs. So, the raw data should support both use-cases. For a

Re: allow newlines in T_ESCAPE_LOGITEM?

, Yann Ylavic <ylavic@gmail.com> wrote: > On Wed, Apr 13, 2016 at 11:08 PM, Eric Covener <cove...@gmail.com> wrote: > > On Wed, Apr 13, 2016 at 5:05 PM, Daniel Lescohier > > <daniel.lescoh...@cbsi.com> wrote: > >> Isn't T_ESCAPE_LOGITEM also used by mod_

Re: allow newlines in T_ESCAPE_LOGITEM?

Isn't T_ESCAPE_LOGITEM also used by mod_log_config's use of ap_escape_logitem? We rely on the API that data from HTTP requests that are logged in our mod_log_config logfiles are newline-escaped, so that one line in the logfile is parsed as one log entry. Our parsers first split on newline to get

Re: Do pools lead to bad programming?

%{formatstring2}t. On Fri, Dec 13, 2013 at 10:14 AM, Yann Ylavic ylavic@gmail.com wrote: On Fri, Dec 13, 2013 at 5:06 AM, Daniel Lescohier daniel.lescoh...@cbsi.com wrote: Here is my draft replacement: static const char *log_request_time_custom(request_rec *r, char

Re: Do pools lead to bad programming?

We can also save stack space by changing: char server_portstr[32]; to: char server_portstr[6]; Or if we want to future-proof against the small possibility of a new TCP standard that has larger port numbers and negative port numbers: char server_portstr[sizeof(apr_port_t)*241/100+3]; /*

Re: time caching in util_time.c and mod_log_config.c

On Wed, Dec 4, 2013 at 7:47 AM, Jim Jagielski j...@jagunet.com wrote: Also, IMO, the default should be non-portable atomics. Yes: that is the purpose of APR: having a portable API on top of non-portable implementations for each platform.

Re: time caching in util_time.c and mod_log_config.c

://trac.mcs.anl.gov/projects/openpa/wiki/FAQ). Also, IMO, the default should be non-portable atomics. On Dec 3, 2013, at 7:41 PM, Daniel Lescohier daniel.lescoh...@cbsi.com wrote: So I think we should reach a consensus on what approach to take. My goal was to implement an algorithm

Re: time caching in util_time.c and mod_log_config.c

function calls were really really expensive. Does the decreased clarity (and debugging capability) really offset the saved cycles? Agreed that it's not fully applicable below. On Dec 2, 2013, at 6:13 PM, Daniel Lescohier daniel.lescoh...@cbsinteractive.com wrote: The current time caching

Re: time caching in util_time.c and mod_log_config.c

( apr_time_exp_t * value, apr_time_t t) { TIME_CACHE_FUNCTION( sizeof(apr_time_exp_t), explode_time_cache_t, explode_time_lt_cache, TIME_CACHE_SIZE_POWER, apr_time_exp_lt, value-tm_usec = (apr_int32_t) apr_time_usec(t)) } On Tue, Dec 3, 2013 at 10:53 AM, Daniel Lescohier daniel.lescoh

Re: time caching in util_time.c and mod_log_config.c

). Hence with USE_ATOMICS_GENERIC, apr_thread_mutex_trylock() may be a better solution than the apr_thread_mutex_lock()... On Tue, Dec 3, 2013 at 6:01 PM, Daniel Lescohier daniel.lescoh...@cbsi.com wrote: If the developers list is OK using apr_atomic in the server core, there would be lots

Re: time caching in util_time.c and mod_log_config.c

(continued, hit send too early) %ix86 i386 i486 i586 i686 pentium3 pentium4 athlon geode However, I looked at the CentOS 6 apr.spec, and it's not overriding the default.

Re: time caching in util_time.c and mod_log_config.c

on fixing this because of these systems? If we go forward, should there be something in the release notes warning of this APR configuration issue? On Tue, Dec 3, 2013 at 7:15 PM, Daniel Lescohier daniel.lescoh...@cbsi.comwrote: (continued, hit send too early) %ix86 i386 i486 i586 i686

time caching in util_time.c and mod_log_config.c

The current time caching implementation in util_time.c and mod_log_config.c is not guaranteed to work with all compilers and cpu architectures. I have some proposed code I've written, that I want to get input from the mailing list on, before continuing on to compile and test it. The old

Re: mod_autoindex string pluggability

output_directories seems html-specific code. Why not implement a brand-new output_directories_json, and have index_directories() function choose which function to call based on query args? Anyway, index_directories() has to change to send the correct content-type header, and to skip emit_head and

Re: Decrypting mod_session-created cookie

Looking at the code, the encoded data block does not have a version number field in it, so the data format and general algorithm cannot be easily changed in the future. The encoded data seems to be comprised of: base64 encode of: - salt (fixed length of sizeof(apr_uuid_t)) - the

Re: Decrypting mod_session-created cookie

https://httpd.apache.org/docs/2.4/mod/mod_session.html#sessionprivacy The session will be automatically decrypted on load, and encrypted on save by Apache, the underlying application using the session need have no knowledge that encryption is taking place. On Mon, Jul 8, 2013 at 6:58 PM,

Re: Decrypting mod_session-created cookie

, at 00:11, Daniel Lescohier daniel.lescoh...@cbsi.com wrote: https://httpd.apache.org/docs/2.4/mod/mod_session.html#sessionprivacy The session will be automatically decrypted on load, and encrypted on save by Apache, the underlying application using the session need have no knowledge

Re: Decrypting mod_session-created cookie

You could perhaps also setup Apache as a reverse-proxy to the other application, so Apache will decrypt it before proxying it to the other application. On Mon, Jul 8, 2013 at 7:33 PM, Daniel Lescohier daniel.lescoh...@cbsi.comwrote: The mod_session_crypto.c adds a salt (from calling

Re: [PATCH] mod_unique_id: use ap_random_insecure_bytes() to get unique ID

initialized by the child in root+counter will be used to make different ids. On Sat, Jul 6, 2013 at 9:38 AM, Daniel Lescohier daniel.lescoh...@cbsi.comwrote: Ah, I missed that. I see it's in the doxygen docs for the random module. However, the sources aren't under random/, they're under misc/. I

Re: [PATCH] mod_unique_id: use ap_random_insecure_bytes() to get unique ID

Actually, for stamp_fraction, one should choose either: r-request_time 0x /* microseconds modulus 65536 */ apr_uint16_t ui16; htons(ui16 = apr_time_usec(r-request_time) 4) /* fraction of a second with denominator 62500 */ On Sun, Jul 7, 2013 at 7:32 AM, Daniel Lescohier daniel.lescoh

Re: [PATCH] mod_unique_id: use ap_random_insecure_bytes() to get unique ID

, 2013 at 8:04 PM, Stefan Fritsch s...@sfritsch.de wrote: On Wednesday 26 June 2013, Daniel Lescohier wrote: When I looked into the ap random functions, I didn't like the implementation, because I didn't see anywhere in the httpd codebase that entropy is periodically added to the entropy pool

Re: [PATCH] mod_unique_id: use ap_random_insecure_bytes() to get unique ID

We have an internal custom Apache module that generates UUIDs; it's using a legacy format that we need for our application. A few months ago, I was upgrading it to Apache 2.4, and I worked on modifying the UUID generator function, so that some of the bytes are random (including replacing the 4

Re: Time for 2.4.5 ??

+ is not used in url-encoding. + is used in application/x-www-form-urlencoded encoding. So I assume this function has implemented unescaping application/x-www-form-urlencoded. For regular URL-encoding, space is encoded as %20. On Fri, May 24, 2013 at 11:46 PM, Guenter Knauf fua...@apache.org

Re: thread-safety of time conversion caches in util_time.c and mod_log_config.c

Fritsch s...@sfritsch.de wrote: On Sunday 06 January 2013, Daniel Lescohier wrote: I'm not sure we should include memory barriers inside the apr_atomic_read32 and apr_atomic_set32 functions, because you don't necessarily need a full memory barrier on each read or set. Instead, perhaps we

Re: thread-safety of time conversion caches in util_time.c and mod_log_config.c

:50 PM, Daniel Lescohier daniel.lescoh...@cbsi.comwrote: It looks like apr_atomic is not in good-enough shape to be used for lock-free algorithms. It's probably good enough for the use-cases that the event mpm uses it for, because the event mpm is not using it for protecting memory besides

Re: event mpm and mod_status

I see that event mpm uses a worker queue that uses a condition variable, and it does a condition variable signal when something is pushed onto it. If all of the cpu cores are doing useful work, the signal is not going to force a context switch out of a thread doing useful work, the thread will

Re: thread-safety of time conversion caches in util_time.c and mod_log_config.c

I'd have to go back and review the Intel documentation to be sure, but for this particular algorithm, an explicit memory barrier may be required on Intel architecture, also. If I remember correctly, without a memory barrier, Intel arch only guarantees total memory ordering within one cache line.

Re: thread-safety of time conversion caches in util_time.c and mod_log_config.c

(cache_element-key, seconds); } On Sat, Jan 5, 2013 at 8:40 AM, Daniel Lescohier daniel.lescoh...@cbsi.comwrote: I'd have to go back and review the Intel documentation to be sure, but for this particular algorithm, an explicit memory barrier may be required on Intel architecture, also. If I

thread-safety of time conversion caches in util_time.c and mod_log_config.c

in detail in the bug? Thanks, Daniel Lescohier

Re: event mpm and mod_status

I just saw this from last month from Stefan Fritsch and Niklas Edmundsson: The fact that the client ip shows up on all threads points to some potential optimization: Recently active threads should be preferred, because their memory is more likely to be in the cpu caches. Right now, the thread

Re: thread-safety of time conversion caches in util_time.c and mod_log_config.c

in order to implement lock-free and wait-free algorithms. On Fri, Jan 4, 2013 at 7:58 PM, Stefan Fritsch s...@sfritsch.de wrote: On Friday 04 January 2013, Daniel Lescohier wrote: I entered a bug on the thread-safety of the time conversion caches in server/util_time.c and modules/loggers